My setup currently loads uboot and the kernel from the sd-card (or eMMC, usb) and the kernel modules and the rest of the rootfs from the nvme. I would prefer to have just uboot on the sd-card. For me this makes more sense because I like to keep my kernel/fs fairly updated whereas I don’t feel the same about u-boot.
A more important issue though is about backup/restore and failures where you have a clear separation between uboot and the rest, which is not true if the kernel is on one drive (sd) and the kernel modules (and rootfs) are in a different place (nvme).
I think having nvme support in uboot would definitely make the bpi-r3 platform more reliable and maintainable as it would be more modular, but I admit my issues are mostly quality-of-life related.
Thanks @ericwoud for your suggestion. I don’t immediately see the benefits of using kexec in my situation (because it introduces another layer of complexity and a secondary kernel to keep track of) but I’m sure people with different requirements will find it usefull (e.g. sd-card wear and tear related concerns)
So, I am assuming PCIE and NVME u-boot support is still not coming for the BPI-R3. A bit of a shame really…
@ericwoud, do you have a repo link, and/or can you provide some instructions on how to set up the kexec chainloading setup you mentioned? I would be willing to give that a try.
I am quite fed up with having my kernel and rootfs (i.e
kernel modules) on separate storage devices. Makes restoring the system from backups a real pain.
We will use M.2 with M-key for NVMe storage. There is a work-in-progress patch to make PCIe work inside the U-Boot bootloader. This will allow booting other Linux distributions such as Debian and Alpine directly from NVMe.
If I understand that correctly, that would benefit every board using U-Boot?
I know that there is some work on mt7986 pcie support,but currently there are problems on recognizing nvme. Each soc needs a matching driver for pcie so this is a board specific feature
This will be the way to install my archlinuxarm image to have it chainloading. I still have to add the code to the initrd, but I need a few days to develop/test this part.
Wow, these are some nice updates. Thanks @ericwoud for setting up the tutorial. I am also a big fan of Archlinux so this is quite fortuitous. Definitely saves me a lot of time migrating things.
So anyway, the kexec experiment stranded at pcie not initializing correctly. Although a have a custom ‘hack’ / feature in mind of arm trusted firmware, to do something similar as kexec. But more of a proof of concept and for my own use and anyone interested
Hi @ericwoud. I had a look at your guide and I’d like to try the “2. ATF - KERNEL using boot partition.” boot method. However I do have three questions before I start and mess up my system.
I would like to attempt this first on a sd-card. I feel like that is easier to swap-in/out while I test out things. Do you think your guide will work with that? (I plan to run the commands manually first to figure out what happens, and can swap emmc references with the sd-card).
I am building my own kernel and would like to keep using that if possible. Do I need any specific config enabled in the kernel to support the ATF - KERNEL method or your method will work with any kernel itb image (assuming things are configured correctly)?
@frank-w you might also add something along the lines of the patch attached in the uEnv_r3.
u3dev.patch (1.5 KB)
Also, going a bit off-topic here, but I think the NOR memory would be perfect for this. I have been trying to follow your tutorial at en:bpi-r3:uboot [FW-WEB Wiki] but can’t seem to get a bootable NOR setup. Do you think I need to change anything from the linked tutorial, or it should work as is?
If i not miss anything it should work as such,make sure you use the bl2.img to have the bootrom header. What happens when you try to boot nor? Make sure all bootswitches are right.
And you have to erase the parts written later.
Why have you changed useinitrd in your patch? It then misses the “root=/dev/ram rw”