Fred St-Pierre

Yeah, that's what I thought. I'll recompile everything again and reattempt loading the kernel from nvme

Well correct me if I'm wrong, but if it doesn't initialize pcie, it won't boot off the nvme drive?

That could explain why I couldn't boot the kernel a couple of weeks ago. I'll probably pull another attempt later this week, so I don't have to mess with initramfs off SPI.

Power it with POE for now, before I was using a 60W PD power brick during staging

Normal message on first boot. Just enter u-boot without a boot drive, type saveen. If you want, you can use printenv to see your environment variables and modify them to your liking (for example edit boot_targets) and then type saveen. CRC error should dissapear.

I dirty modified the config code to include this... Booting from nvme doesn't seem like it's an issue, it's more the fact the initramfs on the amarula image is part of their SPI image, while the other needs to be added to the armbian image to boot properly. I don't have much time to play around with it lately, so I'll give it some time before I try it again. But the SPI image from Amarula boots the armbian latest compiled image without issues, so I'll keep this for now and play around with it further when I have time. Thanks!

So further trying to get the board to boot, I tried to compile Linux-next, copied all files to the /boot folder, flashed spi.img as recommended and the board is dead in the water again. The u-boot from the amarula release seems to have initramfs built in to the image... So... More attempts required to get the board to boot with self-compiled u-boot and initramfs, I guess.

Ok, so progress: flashed u-boot from this release: https://github.com/amarula/bsp-rockchip/releases/tag/v1.3-roc-rk3399-pc and board boots into Armbian with a freshly compiled Armbian build. HUZZAH! Boots off nvme too... Now I'm kind of afraid to see what will happen if I update the board, as I think this is u-boot 5.5... At least it's a step in the right direction.

Yeah, just flashed SD card and tested, seems like my build does not work... It doesn't even fetch extlinux.conf to begin boot. More digging to figure it all out. Baby steps and progress. Learning how to compile slowly.

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.

Thanks for this, I just tried it yesterday and I actually get a post from SPI. It's a step in the right direction! I made a build environment in a Vmware player VM, which lets me manipulate the board as well. Compiling Armbian right now. My issue is that I still have no keyboard input. I only have Unifying wireless keyboards, both do not work. I checked the config file and CONFIG_USB_KEYBOARD is set. I'm at a loss why it would not work. In the meantime, I'll flash to a USB stick to test and then migrate that to the nvme drive...

The last pre-compiled u-boot I tried worked from SPI, but I couldn't interact with it. It didn't accept any keyboard input.

The project was closed off by the support team. They didn't complete sending of hardware (I am out 100$ of gear which they are ignoring me on) and the last update on their IGG is they completed upstreaming all code and have effectively ended the project. To be honest, I never got u-boot to work on this board other than their horrible pre-compiled images which are just used to flash to SD, never got the nvme to work to boot the device. So effectively, this thing is a huge, expensive paperweight for me and just gathering dust in a drawer. This board had so much potential, but Libre and loverpi's horrible after """sales""" support made me just chuck this one up to experience that little indie projects should be overlooked until they mature.

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.

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

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.

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

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

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

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.

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.

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.

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

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.