ROC-RK3399-PC (Renegade Elite)

[davtur19]

@Fred St-Pierre if you want to use roc-rk3399-pc you could try using this image: https://www.armbian.com/firefly-rk3399/
The versions with the 4.4 kernel works on mine roc-rk3399-pc, however the usb ports and some gpio don't work.
Versions with the 5.4 kernel do not boot.
Also I don't think nvme works, I have the extension but I don't have a nvme to try it.

Also, I leave here my "armbianmonitor -u" in case someone more experienced than me wants to make an armbian build for roc-rk3399-pc.

Edit: you can compile the image for roc-rk3399-pc by following this guide: https://docs.armbian.com/Developer-Guide_Build-Preparation/

Edited March 29, 2020 by davtur19

[Fred St-Pierre]

4 hours ago, davtur19 said:

@Fred St-Pierre if you want to use roc-rk3399-pc you could try using this image: https://www.armbian.com/firefly-rk3399/
The versions with the 4.4 kernel works on mine roc-rk3399-pc, however the usb ports and some gpio don't work.
Versions with the 5.4 kernel do not boot.
Also I don't think nvme works, I have the extension but I don't have a nvme to try it.

Also, I leave here my "armbianmonitor -u" in case someone more experienced than me wants to make an armbian build for roc-rk3399-pc.

Edit: you can compile the image for roc-rk3399-pc by following this guide: https://docs.armbian.com/Developer-Guide_Build-Preparation/

 

Thanks for the info, but it's not compiling the image that's an issue, it's getting a functional u-boot off the SPI NOR with nvme support... I have most of the parts in place, it just does not boot when flashed to SPI. I built an Armbian build just fine and it works on SD, that's not an issue... 

 

There's a lot of info in this thread about progress, as in I'm able to compile a u-boot version with mainline code, I'm able to patch with the files supplied to add nvme support, but none of those u-boot compiled versions end up working when flashed on SPI. There's conflicting information as to what offsets to flash. For example, the package supplied by loverpi flashed idbloader.img at offset 0x00, which is over 900k as opposed to the compiled one which is 236k. Then the package flashes the u-boot.itb at offset 0x4000. I've seen references of offset 0x40000 and 0x200, but none of those combinations work. 

 

Then there's the latest doc supplied by loverpi, which offers NO help whatsoever, as their codebase is almost identical to mainline, which just doesn't work. They do provide an image which covers the entire SPI's 16MB with initramfs and boots.  However, it gives little hindsight about what is required to make a bootable image from mainline, just their fork of the u-boot code. 

 

So again, Libre/loverpi/firefly provides little to no support to get this hardware working with mainline, which is what they keep saying they were aiming to do. This board has INSANE potential if only mainline code could be easily used with ALL their hardware without jumping through hoops. The biggest missing part/irritant right now is nvme support for the mezzanine board and SPI NOR booting. If someone, anyone, is able to figure that part out, then this board will have all that's necessary to serve its intended purpose and we won't ever need support from the board designers/supporters.  This is my goal, as they are in no way helpful.  

 

**edit** upon hex viewing roc-rk3399-pc-spinor.img from the package supplied by Loverpi, seems like u-boot.itb is in the image at 0x40000 as recommended earlier in the thread. Where it gets complicated is flashing idbloader.img so it works. The image seems to have a bunch of padding I can't make sense of.

[a16bitsysop]

4 hours ago, Fred St-Pierre said:

 

Thanks for the info, but it's not compiling the image that's an issue, it's getting a functional u-boot off the SPI NOR with nvme support... I have most of the parts in place, it just does not boot when flashed to SPI. I built an Armbian build just fine and it works on SD, that's not an issue... 

 

There's a lot of info in this thread about progress, as in I'm able to compile a u-boot version with mainline code, I'm able to patch with the files supplied to add nvme support, but none of those u-boot compiled versions end up working when flashed on SPI. There's conflicting information as to what offsets to flash. For example, the package supplied by loverpi flashed idbloader.img at offset 0x00, which is over 900k as opposed to the compiled one which is 236k. Then the package flashes the u-boot.itb at offset 0x4000. I've seen references of offset 0x40000 and 0x200, but none of those combinations work. 

 

Then there's the latest doc supplied by loverpi, which offers NO help whatsoever, as their codebase is almost identical to mainline, which just doesn't work. They do provide an image which covers the entire SPI's 16MB with initramfs and boots.  However, it gives little hindsight about what is required to make a bootable image from mainline, just their fork of the u-boot code. 

 

So again, Libre/loverpi/firefly provides little to no support to get this hardware working with mainline, which is what they keep saying they were aiming to do. This board has INSANE potential if only mainline code could be easily used with ALL their hardware without jumping through hoops. The biggest missing part/irritant right now is nvme support for the mezzanine board and SPI NOR booting. If someone, anyone, is able to figure that part out, then this board will have all that's necessary to serve its intended purpose and we won't ever need support from the board designers/supporters.  This is my goal, as they are in no way helpful.  

 

**edit** upon hex viewing roc-rk3399-pc-spinor.img from the package supplied by Loverpi, seems like u-boot.itb is in the image at 0x40000 as recommended earlier in the thread. Where it gets complicated is flashing idbloader.img so it works. The image seems to have a bunch of padding I can't make sense of.

nvme support works now, you need a 5.5 kernel and the mezzanine dtb file.  There are two dtb files for the rk3399 now. 

[Fred St-Pierre]

12 hours ago, a16bitsysop said:

nvme support works now, you need a 5.5 kernel and the mezzanine dtb file.  There are two dtb files for the rk3399 now. 

 

For the kernel and OS, but what about u-boot support? This is what matters to me, using this board with its intended purpose: u-boot off SPI with nvme support and I am unable to get this going.

[a16bitsysop]

 
For the kernel and OS, but what about u-boot support? This is what matters to me, using this board with its intended purpose: u-boot off SPI with nvme support and I am unable to get this going.

On the u-boot website it says the custodian for Rockchip support is:
philipp.tomsich {AT} theobroma-systems {DOT} com

Have you tried them?

Sent from my moto g(7) power using Tapatalk

[Fred St-Pierre]

5 minutes ago, a16bitsysop said:

On the u-boot website it says the custodian for Rockchip support is:
philipp.tomsich {AT} theobroma-systems {DOT} com

Have you tried them?

Sent from my moto g(7) power using Tapatalk
 

 

Nope, but potentially a next step, if firefly doesn't get back to me. 

[strongtz]

Ubuntu 20.04 daily iso build works with 5.6.2 kernel (deb package) from https://kernel.ubuntu.com/

Issues:

  1.device tree from mainline doesn't work, currently using dts from 5.4 (5.5?)

  2."modprobe.blacklist=fusb302" is needed if you use a PD power supply

  3.USB2 in u-boot is not stable, USB3(type-c) in u-boot is not usable

  4.directly booting the iso without modification is not possible since you need to provide it with a device tree

  5.you won't get USB3 working if you take step 2

  6.to get correct display using efi boot, append "video=efifb:off"

 

u-boot.log kernel.log

[balbes150]

Perhaps this information will be useful here. Ready-made Armbian images are available for quick launch on Renegade Elite by regular users.

 

 

 

[balbes150]

Added in the latest version 20200423 installation of the system in eMMC for Renegade Elite (rk3399) and now perezalivayu images on the site. I checked with myself, everything works. Now I have Armbian installed on EMMC in Renegade and a new feature has appeared-direct launch of other systems immediately from USB media (the connectors on the front line work).

[Fred St-Pierre]

I'd really like to know if you compiled that yourself (uboot) or just pulled that from the amarula forum?

[balbes150]

5 minutes ago, Fred St-Pierre said:

I'd really like to know if you compiled that yourself (uboot) or just pulled that from the amarula forum?

Compiled in the Armbian build system ( with patches added).

[Fred St-Pierre]

2 hours ago, balbes150 said:

Compiled in the Armbian build system ( with patches added).

 

Ah. And have you tried booting that u-boot image from SPI? I'll have to see how the armbian build system pads its u-boot image...

[balbes150]

33 minutes ago, Fred St-Pierre said:

 

Ah. And have you tried booting that u-boot image from SPI? I'll have to see how the armbian build system pads its u-boot image...

No, I haven't tried putting it in SPI yet (I don't have exact instructions on how to do this).

[Fred St-Pierre]

4 hours ago, balbes150 said:

No, I haven't tried putting it in SPI yet (I don't have exact instructions on how to do this).

 

I knew it wouldn't boot, but I attempted anyway... It does not indeed boot, as it's probably just built for SD/EMMC and does not have SPI configs... However, I'm massively intrigued at how they pad their u-boot image. I'll have to dig through their makefile to see how they piece everything together. I might be able to make a proper image that boots off SPI with nvme support. 

[martinayotte]

31 minutes ago, balbes150 said:

No, I haven't tried putting it in SPI yet (I don't have exact instructions on how to do this).

I've done a small SPI module attached on my Pine64, and I'm using a user-patch for U-Boot Pine64 DTS, along with an DT overlay for the kernel that provide MTD partition, which I can then push the U-Boot image on the SPI flash.

 

[Fred St-Pierre]

On 4/23/2020 at 2:31 PM, martinayotte said:

I've done a small SPI module attached on my Pine64, and I'm using a user-patch for U-Boot Pine64 DTS, along with an DT overlay for the kernel that provide MTD partition, which I can then push the U-Boot image on the SPI flash.

 

 

You have more info on how to achieve this? I'd love to be able to use the SPI chip on this board...

[martinayotte]

15 hours ago, Fred St-Pierre said:

You have more info on how to achieve this? I'd love to be able to use the SPI chip on this board...

I've use a small proto pcb, soldered a female header along with a SMT to DIP adaptor where I soldered the SPI-NOR flash, connect SPI signals to header.

Then, I've compile a Armbian image with user-patch for U-Boot Pine64 DTS, along with an DT overlay for the kernel that provide MTD partition.

To push U-Boot to the flash, I've used "flashcp" from "mtd-utils" package to /dev/mtd0 partition.

[a16bitsysop]

I have a POE mezzanine and the last dtb that works with is 5.5.11 I think, someone else posted this issue before. Just tried 5.6.10 and it doesn't boot, on my poe switch a normal boot is Ethernet interface up, then down, then up again and that's when networking comes up. The current draw is also around 80mA when running. With a newer dtb it shows interface up, it never goes down and networking doesn't come up. The current draw stays around 40mA after initially going up and down a bit.

If I turn it off and remove the SD card and remove the dtb link in /boot and point it back to 5.5.11 as other post suggested it boots the newer kernel, and nvme is working on mezzanine.

Sent from my moto g(7) power using Tapatalk

[Panzerknacker]

14 minutes ago, a16bitsysop said:

I have a POE mezzanine and the last dtb that works with is 5.5.11 I think, someone else posted this issue before. Just tried 5.6.10 and it doesn't boot, on my poe switch a normal boot is Ethernet interface up, then down, then up again and that's when networking comes up. The current draw is also around 80mA when running. With a newer dtb it shows interface up, it never goes down and networking doesn't come up. The current draw stays around 40mA after initially going up and down a bit.

If I turn it off and remove the SD card and remove the dtb link in /boot and point it back to 5.5.11 as other post suggested it boots the newer kernel, and nvme is working on mezzanine.

Sent from my moto g(7) power using Tapatalk
 

Which power supply and cable do you use?

Can you log the output from the serial debug port?

[a16bitsysop]

Which power supply and cable do you use?
Can you log the output from the serial debug port?

It's a mikrotik crs326-24g Poe switch, and a cat5e cable I crimped myself. I am not using USBC to power it.

Probably going to be very tricky to access the serial pins with the mezzanine on, I will have a look later and see if they can be accessed.

Sent from my moto g(7) power using Tapatalk

[a16bitsysop]

17 hours ago, Panzerknacker said:

Which power supply and cable do you use?

Can you log the output from the serial debug port?

I tried with my usb ttl serial lead and just got question marks with terminal on macOS with 1500000 and 115200, I don't think my lead supports 1.5mbs so have ordered another one.

[a16bitsysop]

Which power supply and cable do you use?
Can you log the output from the serial debug port?

Still waiting for my usb ttl serial dongle, tried 5.6.11 and it successfully booted with the 5.6.11 dtb. Upgraded to 5.6.12 and now after it is powered on a get a 2 blink pulse from the mezzanine green led for approx 20 secs then no LEDs and network is down still. Like previous unsuccessful versions the ethernet interface only comes up once, no change when LEDs stop

Sent from my moto g(7) power using Tapatalk

[a16bitsysop]

Renegade Elite fails to boot with mezzanine and dtb > 5.5.11

 

I finally got my serial dongle working and got some output while booting.

U-Boot TPL 2019.10-armbian (Dec 11 2019 - 19:53:44)
Trying to boot from BOOTROM
Returning to boot ROM...

U-Boot SPL 2019.10-armbian (Dec 11 2019 - 19:53:44 +0000)
Trying to boot from MMC1
NOTICE:  BL31: v2.2(release):a04808c-dirty
NOTICE:  BL31: Built : 19:53:30, Dec 11 2019


U-Boot 2019.10-armbian (Dec 11 2019 - 19:53:44 +0000)

Model: Firefly ROC-RK3399-PC Board
DRAM:  3.9 GiB
MMC:   dwmmc@fe320000: 1, sdhci@fe330000: 0
Loading Environment from EXT4... Card did not respond to voltage select!
In:    serial@ff1a0000
Out:   serial@ff1a0000
Err:   serial@ff1a0000
Model: Firefly ROC-RK3399-PC Board
rockchip_dnl_key_pressed: adc_channel_single_shot fail!
Net:   eth0: ethernet@fe300000
Hit any key to stop autoboot:  0
Card did not respond to voltage select!
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:1...
Found U-Boot script /boot/boot.scr
2949 bytes read in 5 ms (575.2 KiB/s)
## Executing script at 00500000
Boot script loaded from mmc 1
211 bytes read in 4 ms (50.8 KiB/s)
10529111 bytes read in 450 ms (22.3 MiB/s)
20505088 bytes read in 871 ms (22.5 MiB/s)
76102 bytes read in 12 ms (6 MiB/s)
2698 bytes read in 9 ms (292 KiB/s)
Applying kernel provided DT fixup script (rockchip-fixup.scr)
## Executing script at 39000000
## Loading init Ramdisk from Legacy Image at 04000000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    10529047 Bytes = 10 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 01f00000
   Booting using the fdt blob at 0x1f00000
   Loading Ramdisk to f5514000, end f5f1e917 ... OK
   Loading Device Tree to 00000000f5499000, end 00000000f5513fff ... OK

Starting kernel ...

Loading, please wait...
Starting version 245.4-4ubuntu3.1
Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... done.
Begin: Waiting for root file system ... Begin: Running /scripts/local-block ... done.
done.
Gave up waiting for root file system device.  Common problems:
- Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
- Missing modules (cat /proc/modules; ls /dev)
ALERT!  UUID=b68dafc4-9fb4-477a-bc71-d03817baf081 does not exist.  Dropping to a shell!
Rebooting automatically due to panic= boot argument
[   49.287360] reboot: Restarting system

 UUID=b68dafc4-9fb4-477a-bc71-d03817baf081 is the ext4 / partition on the microSD card

[a16bitsysop]

I searched and thought updating uboot might help, searching on my system it says:

linux-u-boot-roc-rk3399-pc-dev/now 20.05.0-trunk arm64 [installed,local]
  Uboot loader 2020.01

 

but message above says:

Quote

2019.10-armbian

 

[xiaobao80]

Armbian_20.05.0-trunk_Roc-rk3399-pc_stretch_dev_5.5.19_minimal.img  

 It's basically working 

[a16bitsysop]

8 hours ago, xiaobao80 said:

Armbian_20.05.0-trunk_Roc-rk3399-pc_stretch_dev_5.5.19_minimal.img  

 It's basically working 

Is that one you compiled yourself, or downloaded?

[Fred St-Pierre]

https://github.com/amarula/bsp-rockchip/releases

 

Finally. PCIE support mainlined in u-boot, 4k support, USB fixes, etc etc etc. This board will now be usable the way I intended to use it.  Time to play around with NVMe boot and SPI flash.

[Zaf9670]

23 hours ago, Fred St-Pierre said:

https://github.com/amarula/bsp-rockchip/releases

 

Finally. PCIE support mainlined in u-boot, 4k support, USB fixes, etc etc etc. This board will now be usable the way I intended to use it.  Time to play around with NVMe boot and SPI flash.

 

I was just coming here to see if anyone had updated for their recent update. I just finished moving and unpacked mine. So this is pretty good timing.

[xiaobao80]

@a16bitsysop   compile

[frauhottelmann]

Has anybody tried to build an image recently? I get a working image out of 20.05 with focal and dev kernel. It stops booting after an upgrade. It hangs on "starting kernel" (console).

And if I try to build one on master with dev it doesn't boot at all. Over HDMI it shows the following. First I thought it was the HDMI-boot problem of rk3399 ( @piter75 ), but it doesn't change without HDMI cable. The green LED just keeps flashing and nothing happens.

 

 

 

 

 

 

 

 

 

EDIT: Oh and with master and current it boots, but ethernet doesn't come up and open ssh server keeps crashing

 

And it's not a power supply problem since I power via 12V-headers.