Fred St-Pierre

This board is doing its best to drive me totally bonkers. Still can't boot anything...  It sees NVME, it sees my USB, able to see all files are there, but it just doesn't fire up anything. More digging required, I guess. Used Armbian compiler for most, compiled initramfs with linux-next instructions, followed most recommendations here. 
 
At least I figured out that having the board plugged into my laptop to power it, if I type ums 0 nvme 0 from u-boot, I can access the nvme drive from my Ubuntu VM and fully manipulate it from there. Learning experience

Yep, I had a previous bl31.elf built, that was not the issue. I had to enable CONFIG_DM_KEYBOARD=y in my defconfig... Keyboard now works. Thanks for the help! Next step, boot from nvme.

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.

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'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.
 

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).

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.

Loverpi FINALLY answered me. Here is the documentation to compile u-boot for SPI: 
 
https://github.com/amarula/bsp-rockchip/releases

Loverpi FINALLY answered me. Here is the documentation to compile u-boot for SPI: 
 
https://github.com/amarula/bsp-rockchip/releases

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.

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.

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

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.
 

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);  

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.

I wrote to the firefly team so they could help in fixing USB-C power upstream and received a response on Feb 12th saying they were all remote working due to Corona virus... But the request to get the proper code base would be forwarded to an engineer. No reply on this yet.

Only OT post I'll post, as to not mine the thread with this, but yeah, quite possibly. La frite is missing fulfilment of mezzanine boards and wifi modules, while Renegade Elite has 10 people missing emmc modules (including me) and wifi modules. They've been vague and sketchy, saying they need a minimum order quantity to fulfill missing perks and that we have no reason to complain. 
 
Back OT: ever since kernel 5.4 has been dropped, we got one post from them saying that around christmas, we'd see something released by them in regards to u-boot and I BELIEVE OS. But their communication skills are very lacking. I'm wondering if contacting the Firefly team might yield better results to get the PD issue fixed.

Only OT post I'll post, as to not mine the thread with this, but yeah, quite possibly. La frite is missing fulfilment of mezzanine boards and wifi modules, while Renegade Elite has 10 people missing emmc modules (including me) and wifi modules. They've been vague and sketchy, saying they need a minimum order quantity to fulfill missing perks and that we have no reason to complain. 
 
Back OT: ever since kernel 5.4 has been dropped, we got one post from them saying that around christmas, we'd see something released by them in regards to u-boot and I BELIEVE OS. But their communication skills are very lacking. I'm wondering if contacting the Firefly team might yield better results to get the PD issue fixed.

They have been really quiet, they still have 2 or 3 boards they were going to launch last year that never launched on Indiegogo or Kickstarter. Maybe because of problems/negative feedback from the renegade elite, and long delays on la frite as well?

Sent from my moto g(7) power using Tapatalk

If only firefly/loverpi/libre were of any help. I'll post it on their forum and hope for the best.

Mezzanine is powered by the mainboard's USB-C through its connection on the board's GPIO. Otherwise, the mezzanine does offer an m.2 key slot for a wifi module. Sadly, Libre/loverpi is jerking around backers of the board and not delivering missing parts like the wifi module and emmc, so I wouldn't rely on them for these parts.

@piter75 Are you planning to send the ATF "switch power domains on before reset" patch upstream to https://review.trustedfirmware.org/ ? It fixes the issue with mainline ATF + Linux where Linux will hang after rebooting; I have tested the patch with my own custom build of Debian and it now reboots 100% successfully. It would be really useful for all mainline distros if it was applied to mainline ATF.

We work on Armbian every day, not just when Linus change kernel version.
 
This
https://github.com/armbian/build/pull/1614
and this
https://docs.armbian.com/Release_Changelog/
(5.3.y for this board is out, 5.4.y will follow when this will make sense. Sooner if you help somehow)
is relevant for your board which is sadly not getting our dedicated attention.

 

A huge kudos to @piter75 who commited a csc for this board 👍😍 Did not have the time or energy get my efforts to bear fruit. Was probably to focused on getting the U-Boot TPL+SPL combo working. Maybe this board finally gets the love it so desperately needs. Once again. Thank you for Armbian and all the work everyone puts in! 

The kudos belong to Levin Du of T-Firefly team who did the heavy lifting.
I merely paved the path with my u-boot PR and helped make the reboot work in mainline ATF for rk3399.
 
Oh and BTW... this is the first rk3399 board in Armbian which boots with full and fresh OSS combo: mainline u-boot's TPL/SPL + mainline ATF.