ROC-RK3399-PC (Renegade Elite)

[Panzerknacker]

1 hour ago, a16bitsysop said:

I tried 20.02 with kernel 5.5.6 to see if my m2 ssd would be recognised, it’s powered by POE and the switch is saying it is powering it at 52v.  I changed the dtb file to the mezzanine one and now I get (when doing a dmesg | grep pci)

[    1.527318] vcc3v3_pcie: supplied by dc_12v

[    2.751978] rockchip-pcie f8000000.pcie: no vpcie12v regulator found

[    2.752081] rockchip-pcie f8000000.pcie: f8000000.pcie supply vpcie0v9 not found, using dummy regulator

[    3.305332] rockchip-pcie f8000000.pcie: PCIe link training gen1 timeout!

[    3.305577] rockchip-pcie: probe of f8000000.pcie failed with error -110

 

maybe it’s the same cause?

Probably not.

The 0.9V regulator will come with 5.6 :-) but missing it causes no failure.

Link training can time out when no NVME device is connected or a connected one is not powered.

 

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dtsi?h=v5.6-rc3

Edited February 25, 2020 by Panzerknacker
Added link to kernel v5.6 dev

[a16bitsysop]

Probably not.
The 0.9V regulator will come with 5.6 :-) but missing it causes no failure.
Link training can time out when no NVME device is connected or a connected one is not powered.
 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dtsi?h=v5.6-rc3

I hope it's because it not powered, it's a western digital "green" M2 SSD. It's supposed to be a low power usage one.

Sent from my moto g(7) power using Tapatalk

[Panzerknacker]

29 minutes ago, a16bitsysop said:

I hope it's because it not powered, it's a western digital "green" M2 SSD. It's supposed to be a low power usage one.

Sent from my moto g(7) power using Tapatalk
 

You need an NVME not a SATA type.

[a16bitsysop]

You need an NVME not a SATA type.

Thanks, didn't actually realize there was 2 kinds of M2 devices! Think I will put that in an enclosure and look for NVME then.

Sent from my moto g(7) power using Tapatalk

[a16bitsysop]

You need an NVME not a SATA type.

I got an NVME one now, and it is recognized! Did a dd speed test and got 370mb/s on the nvme drive and 13.8mb/s on the SD card.

I created an ext4 filesystem on the already existing single partition it had as if I do:
sudo fdisk /dev/nvme0
I get the error Illegal seek and it exits.

If I try:
sudo parted /dev/nvme0
I get
Error: The device /dev/nvme0 is so small it cannot possibly store a filesystem or partition table. Perhaps you are using the wrong device.

But I can create a filesystem on /dev/nvmen1 mount it and dd a1gb file without errors.

Sent from my moto g(7) power using Tapatalk

[frauhottelmann]

1 hour ago, a16bitsysop said:

I got an NVME one now, and it is recognized! Did a dd speed test and got 370mb/s on the nvme drive and 13.8mb/s on the SD card.

I created an ext4 filesystem on the already existing single partition it had as if I do:
sudo fdisk /dev/nvme0
I get the error Illegal seek and it exits.

If I try:
sudo parted /dev/nvme0
I get
Error: The device /dev/nvme0 is so small it cannot possibly store a filesystem or partition table. Perhaps you are using the wrong device.

But I can create a filesystem on /dev/nvmen1 mount it and dd a1gb file without errors.

Sent from my moto g(7) power using Tapatalk
 

What does lspci and lsblk say?

[Panzerknacker]

2 hours ago, a16bitsysop said:

But I can create a filesystem on /dev/nvmen1 mount it and dd a1gb file without errors.

Perfect.

[a16bitsysop]

What does lspci and lsblk say?

lspci has:
00:00.0 PCI bridge: Fuzhou Rockchip Electronic Co., Ltd RK3399 PCI Express Root Port
01:00.0 Non-Volatile memory controller: Philson Electronics Corporation E12 NVMe Controller (rev 01)

lsblock has it as:
nvme0n1 259:0 0 931.5G 0 disk /mnt

Sent from my moto g(7) power using Tapatalk

[piter75]

4 hours ago, a16bitsysop said:

sudo fdisk /dev/nvme0

Shouldn't you actually be partitioning a /dev/nvme0n1 device as /dev/nvme0 is simply a controller?

https://serverfault.com/questions/892134/why-is-there-both-character-device-and-block-device-for-nvme

https://metebalci.com/blog/a-quick-tour-of-nvm-express-nvme/

[a16bitsysop]

Shouldn't you actually be partitioning a /dev/nvme0n1 device as /dev/nvme0 is simply a controller?
https://serverfault.com/questions/892134/why-is-there-both-character-device-and-block-device-for-nvme
https://metebalci.com/blog/a-quick-tour-of-nvm-express-nvme/

Yes that worked, with fdisk /dev/nvme0n1 I created a partition which is now /dev/nvme0n1p1

Thought it was like sata with sda being the first drive etc.

Thanks

Sent from my moto g(7) power using Tapatalk

[Bitschubser]

With help of this patch I have been able to build a mainline U-Boot which can load the kernel from nvme. Now I want to flash this build into the onboard spi flash. But it is not working, no leds lighten up, no output on serial terminal. I did search for spi builds for rk3399 but I could not find anything that was helpful. Does anybody here on the list have experience how to build an U-Boot for spi flash? Any hint is welcome.

[Fred St-Pierre]

On 3/1/2020 at 9:02 AM, Bitschubser said:

With help of this patch I have been able to build a mainline U-Boot which can load the kernel from nvme. Now I want to flash this build into the onboard spi flash. But it is not working, no leds lighten up, no output on serial terminal. I did search for spi builds for rk3399 but I could not find anything that was helpful. Does anybody here on the list have experience how to build an U-Boot for spi flash? Any hint is welcome.

 

Man, this is all I'm waiting for to make this board usable: Boot nvme from u-boot. loverpi.com has a preliminary u-boot package, but beyond that, I'm not sure how the format should be... I'm also pretty much ignored on the forum.loverpi.com forums for harrassing them considering they never completed fulfilment of the Renegade Elite campaign (I'm out a 100$ emmc and wifi/bt module). Maybe you can sign up to their forum and ask? Otherwise, try @librecomputer on twitter

[Fred St-Pierre]

On 3/1/2020 at 9:02 AM, Bitschubser said:

With help of this patch I have been able to build a mainline U-Boot which can load the kernel from nvme. Now I want to flash this build into the onboard spi flash. But it is not working, no leds lighten up, no output on serial terminal. I did search for spi builds for rk3399 but I could not find anything that was helpful. Does anybody here on the list have experience how to build an U-Boot for spi flash? Any hint is welcome.

 

https://linux-sunxi.org/Bootable_SPI_flash#The_SPL Found this reference on u-boot saying you might need to edit the board's defconfig to enable it? 

 

http://wiki.t-firefly.com/en/ROC-RK3399-PC/ - There's always the firefly wiki for more info... I honestly have very little experience with compiling any code, so I'm just trying to find things to help out. 

 

Have you tried to compile without the patch and flash to see if it works? 

[Fred St-Pierre]

Trying to compile u-boot and I always get an SPL is too large error... Hm. When you haven't built anything in a while, you realize how rusty you are.

 

**edit** Why exactly did the maintainer of this board name the u-boot board as roc-pc-rk3399 instead of roc-rk3399-pc? Confusing... :O

[Panzerknacker]

On 3/9/2020 at 11:07 PM, Fred St-Pierre said:

Trying to compile u-boot and I always get an SPL is too large error... Hm. When you haven't built anything in a while, you realize how rusty you are.

 

**edit** Why exactly did the maintainer of this board name the u-boot board as roc-pc-rk3399 instead of roc-rk3399-pc? Confusing... :O

Steps for building native on the board, boot from mmc or SD:

 

Get https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git

make -j6 PLAT=rk3399 bl31
cp build/rk3399/release/bl31/bl31.elf ../u-boot

 

cd ../u-boot

 

make roc-pc-rk3399_defconfig
make -j6

 

dd if=idbloader.img of=/dev/mmcblkX seek=64
dd if=u-boot.itb of=/dev/mmcblkX seek=16384

 

If this works, you can try SPI.

 

[Panzerknacker]

Presently you have to press power button when booting with mainline uboot.

If you don't want this patch here:

 

diff --git a/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c b/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c
index de9185a7ce..6410fe377a 100644
--- a/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c
+++ b/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c
@@ -51,7 +51,7 @@ int board_early_init_f(void)
        spl_gpio_output(gpio0, GPIO(BANK_A, 2), 1);
 
        spl_gpio_set_pull(&pmugrf->gpio0_p, GPIO(BANK_A, 5), GPIO_PULL_NORMAL);
-       while (readl(&gpio0->ext_port) & 0x20);
+//     while (readl(&gpio0->ext_port) & 0x20);
 
        spl_gpio_output(gpio0, GPIO(BANK_A, 2), 0);
        spl_gpio_output(gpio0, GPIO(BANK_B, 5), 1);

 

[Fred St-Pierre]

Ah crap. I compiled the image and now I can't flash it because I only have a build image in WSL...  Time to find my USB key. 

[Fred St-Pierre]

Yeah, there's clearly something not working to boot it from SPI... If I look at the mainline compiled by Loverpi, the mainline files that they use are: idbload_spi.img sized 980992, the other one is u-boot.itb sized 940856.  The fact the idbload_spi.img is almost as big as u-boot.itb makes me believe they are manipulating it in a specific way, as my idbloader is 151754 or 81920 depending on my compilation scenarios. 

 

Sigh... I hate the support from this board's manufacturer. W

[Bitschubser]

Booting from spi into nvme is now working for me ™. It is a hack but if anybody want to try it be aware that you may brick your device.    

 

Most of the needed stuff is already there.  But you have to power the pci regulator manually.    

 

To build u-boot from scratch you have to checkout u-boot@50be9f0e1ccc0909e65132cff216743a49046f97 and apply the attached patches. After that follow the usual way:   

$ make roc-pc-rk3399-spi-nvme_defconfig

$ make all

 

and flash   

idbloader.img at offset 0x00   

u-boot.itb at offset 0x200 (0x40000)  

 

NOTE: 0x40000 is the offset in bytes, use 0x200 for the rockchip flash tool

 

Happy hacking

 

0004-roc-pc-mezzaine-add-defconfig-to-boot-from-spi-and-n.patch0003-hack-nvme-support-into-bootcmd.patch0002-Rk3399-roc-pc-mezziane-boot-from-nvme.patch0001-roc-pc-boot-from-spi.patch

[Fred St-Pierre]

18 hours ago, Bitschubser said:

Booting from spi into nvme is now working for me ™. It is a hack but if anybody want to try it be aware that you may brick your device.    

 

Most of the needed stuff is already there.  But you have to power the pci regulator manually.    

 

To build u-boot from scratch you have to checkout u-boot@50be9f0e1ccc0909e65132cff216743a49046f97 and apply the attached patches. After that follow the usual way:   

$ make roc-pc-rk3399-spi-nvme_defconfig

$ make all

 

and flash   

idbloader.img at offset 0x00   

u-boot.itb at offset 0x200 (0x40000)  

 

NOTE: 0x40000 is the offset in bytes, use 0x200 for the rockchip flash tool

 

Happy hacking

 

0004-roc-pc-mezzaine-add-defconfig-to-boot-from-spi-and-n.patch 43.57 kB · 2 downloads 0003-hack-nvme-support-into-bootcmd.patch 1.46 kB · 1 download 0002-Rk3399-roc-pc-mezziane-boot-from-nvme.patch 20.13 kB · 1 download 0001-roc-pc-boot-from-spi.patch 2.94 kB · 1 download

 

GREAT news! I was getting annoyed with messing around with this Thanks for the files! 

[Fred St-Pierre]

On 3/15/2020 at 2:32 PM, Bitschubser said:

and flash   

idbloader.img at offset 0x00   

u-boot.itb at offset 0x200 (0x40000)  

 

NOTE: 0x40000 is the offset in bytes, use 0x200 for the rockchip flash tool

 

Happy hacking

 

 

I managed to compile the image and flash according to your specs, but still doesn't work... I can't load the loader in rkdeveloptool for some reason, so I used the flash tool supplied by loverpi. If I flash u-boot.itb to any offset (0x200, 0x4000 or 0x40000), it just doesn't post on HDMI (No signal). Is it supposed to post? Because loverpi's mainline u-boot posts when there's no bootable disk (SD/EMMC/NVMe)

[Bitschubser]

3 hours ago, Fred St-Pierre said:

 

I managed to compile the image and flash according to your specs, but still doesn't work... I can't load the loader in rkdeveloptool for some reason, so I used the flash tool supplied by loverpi. If I flash u-boot.itb to any offset (0x200, 0x4000 or 0x40000), it just doesn't post on HDMI (No signal). Is it supposed to post? Because loverpi's mainline u-boot posts when there's no bootable disk (SD/EMMC/NVMe)

what you can try

- check the debug serial output

- remove all sd/mmc card(s)

- check if spl is loaded by attaching the bord via usb-c (the same which deliver power) to you pc and check if the 1st stage bootloader is aktive with lsusb.

 

if this doesn't help you can debrick the board with help of this post from Da Xue. Inside of the tar archive is a picture which shows how to force the SOC into usb download mode. Create an all zero file of 4kB and flash it to offset 0x0.

[Fred St-Pierre]

36 minutes ago, Bitschubser said:

what you can try

- check the debug serial output

- remove all sd/mmc card(s)

- check if spl is loaded by attaching the bord via usb-c (the same which deliver power) to you pc and check if the 1st stage bootloader is aktive with lsusb.

 

if this doesn't help you can debrick the board with help of this post from Da Xue. Inside of the tar archive is a picture which shows how to force the SOC into usb download mode. Create an all zero file of 4kB and flash it to offset 0x0.

 

Yeah, resetting the SPI NOR isn't an issue, I've become skilled at that in the last months. I did remove all bootable drives, SD and NVMe... I'll check if SPL is loaded through lsusb and try and debug to see... Might be my build environment also, who knows.

 

Where are you building u-boot from? Are you using any cross compilers? If ever you can share your compiled u-boot and loader, I'd be curious to see if it works on my board.

 

Thanks! 

 

**edit** Ok, I can confirm spl is not loaded properly, so clearly there's something wrong with how I compile... I'll have to troubleshoot.

[Bitschubser]

Take this as a guess, but as long as you use a (cross-)compiler from an up to date linux distribution you should get a working result. 

 

Although I did not mention it explicitly, but you have to provide the BL31!

 

You can check the output of:

$ hexdump -C idbloader.img | grep RK33
00001000  52 4b 33 33 09 10 00 14  00 00 00 00 00 00 00 00  |RK33............|
000340d0  52 4f 43 2d 52 4b 33 33  39 39 2d 50 43 20 4d 65  |ROC-RK3399-PC Me|

 

The Magic at 0x1000 is a good sign you build is made for SPI flash.

[Fred St-Pierre]

49 minutes ago, Bitschubser said:

Although I did not mention it explicitly, but you have to provide the BL31!

 

The Magic at 0x1000 is a good sign you build is made for SPI flash.

 

I built BL31 from scratch and tried, I used the one supplied by rkbin's git repo and tried... So that's been explored. And hexdump gives me the same info for 0x1000. I'm really at a loss, honestly. Thanks for the help, I appreciate it, but I think this thing is going back in the drawer for now...  Just wondering if I'm gonna sell it. 

 

[Bitschubser]

I have to take back my statement that any recent compiler shout be able to build a working u-boot, spl combo. To be self contained I build u-boot, spl on my roc-pc and flashed the result to the spi flash and it doesn't work! Bummer.

 

I had to debrick the board with the version I have cross-compiled on my Arch Linux PC. At the moment on the distribution my board is a Manjaro Arm Linux.

 

I am baffled and have to think how to continue.

[a16bitsysop]

I have to take back my statement that any recent compiler shout be able to build a working u-boot, spl combo. To be self contained I build u-boot, spl on my roc-pc and flashed the result to the spi flash and it doesn't work! Bummer.
 
I had to debrick the board with the version I have cross-compiled on my Arch Linux PC. At the moment on the distribution my board is a Manjaro Arm Linux.
 
I am baffled and have to think how to continue.

If you want to try lots of different versions and distros docker is great for that, you can spin up a container with your source directory mounted into it and install versions of packages you need. Then when you quit your host computer is unchanged.

Sent from my moto g(7) power using Tapatalk

[Fred St-Pierre]

On 3/22/2020 at 2:22 AM, Bitschubser said:

I have to take back my statement that any recent compiler shout be able to build a working u-boot, spl combo. To be self contained I build u-boot, spl on my roc-pc and flashed the result to the spi flash and it doesn't work! Bummer.

 

I had to debrick the board with the version I have cross-compiled on my Arch Linux PC. At the moment on the distribution my board is a Manjaro Arm Linux.

 

I am baffled and have to think how to continue.

 

Tried a debian distro and an ubuntu distro, same result. I did see in the thread some people mentioning you needed an image with SPL and TPL, noticed TPL doesn't get compiled in mainline.

 

Also saw some other reference about image padding being required for SPI like in this example below. Tried to use that to build a custom idbloader with no success. Otherwise, I noticed idbloader is purely built with SPL with the mkimage command: cmd_idbloader.img := ./tools/mkimage -n "rk3399" -T rkspi -d spl/u-boot-spl.bin idbloader.img >/dev/null

 

However, in the spoiler example below and on http://opensource.rock-chips.com/wiki_Boot_option - They seem to build the image quite differently. 

 

I've contacted loverpi, they just don't answer back. Firefly is my next option to stop trying to figure out their design.

 

 

 

 

Spoiler

 

Booting from SPI
================

To write an image that boots from SPI flash (e.g. for the Haier Chromebook or
Bob):

   ./chromebook_jerry/tools/mkimage -n rk3288 -T rkspi \
    -d chromebook_jerry/spl/u-boot-spl-dtb.bin spl.bin && \
   dd if=spl.bin of=spl-out.bin bs=128K conv=sync && \
   cat spl-out.bin chromebook_jerry/u-boot-dtb.img >out.bin && \
   dd if=out.bin of=out.bin.pad bs=4M conv=sync

This converts the SPL image to the required SPI format by adding the Rockchip
header and skipping every second 2KB block. Then the U-Boot image is written at
offset 128KB and the whole image is padded to 4MB which is the SPI flash size.
The position of U-Boot is controlled with this setting in U-Boot:

   #define CONFIG_SYS_SPI_U_BOOT_OFFS    0x20000

 

 

 

[Fred St-Pierre]

Loverpi FINALLY answered me. Here is the documentation to compile u-boot for SPI: 

 

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

[Fred St-Pierre]

22 hours ago, Fred St-Pierre said:

Loverpi FINALLY answered me. Here is the documentation to compile u-boot for SPI: 

 

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

 

And still can't boot their image... Nor is any of their text helpful, except the fact they supply a prebuilt image which boots, but goes nowhere and ends up just not working. Am I the problem? It seems so... Guess I'll make another build environment than on WSL2.