Hi @ericwoud. Thanks for supporting this and for your feedback. I have been working my way through your scripts (e.g., PKGBUILDs, bpir-writefip, build.sh) hoping to figure out how to adapt things for my needs: an SDCARD with your ATF which automatically loads my kernel from a NVME, FAT32 boot partition.
I have so far managed to build a kernel based on your repo (thanks for maintaining a rolling update for that) and have figured out how to manually build bpir3-atf-sdmmc-atf.bin. I do however have a few question about the remainder of the process. I am going to list these here now, but I am happy to ask future questions offline (via DMs) if my questions clutter the thread.
Your guide referes to a partition that starts at 256MiB [1]. My current layout is:
Model: Samsung SSD 980 1TB (nvme)
Disk /dev/nvme0n1: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 106MB 105MB fat32 EFI system partition boot, esp
2 106MB 10.8GB 10.7GB ext4 Linux ARM64 root (/)
3 10.8GB 1000GB 989GB ext4 Linux /srv
What would I need to modify to be able to point ATF to load the kernel from my fat32 partition? Also related, how is the kernel called from the ATF, for example if I want to edit the kernel command-line.
I am currently using an .itb image for my kernel. Does your ATF work with this format or just Image and Image.gz (also which of these 2 is the one used)?
Is the bpir-kexec script used in the ATF->kernel boot configuration?
P.S. You don’t seem to have issue reporting active on your kernel repo, but I did notice a small bug:
Not yet. When the u-boot pcie support is mainline, I will update my uboot package, so that this is also an option.
Having different options is ok here I think. I see there are many quirks around for supporting all the different nvme drives. Who knows which quirks are available in u-boot…
On the plus side I did manage to figure it out the scripts and give the method a try. Seems to work well on my bpi-r3. However, functionality-wise it is still similar to what I had before, ATF and u-boot on sdcard and rootfs on NVME (atf w/o u-boot is a little bit faster though).
OpenWrtOne> pci enum
OpenWrtOne> pci
BusDevFun VendorId DeviceId Device Class Sub-Class
00.00.00 0x14c3 0x1f32 Bridge device 0x04
01.00.00 0x144d 0xa80b Mass storage controller 0x08
OpenWrtOne> nvme scan
OpenWrtOne> nvme info
Device 0: Vendor: 0x144d Rev: 7L1QHXC7 Prod: S67PNF0W854510
Type: Hard Disk
Capacity: 244198.3 MB = 238.4 GB (500118192 x 512)
For debugging purposes you can load u-boot.bin from usb/tftp and use go command on the loadaddr. This way you don’t need built with atf everytime and flash it…but i guess your current uboot does not have go command yet,so you have to do it once…ah you using erics image and loading uboot from atf? Then you will not need atf compile around uboot i guess
Had to change the constant patch a little bit (see attached) but other than that it worked perfectly. I now have u-boot on my sdcard and everything else on my nvme. No more messy backup restores for me. Thanks for all the help.
Btw, if anyone is interested, my nvme is a Samsung 980 1TB.
So we got PCIe support in U-Boot and we also got lots of on-board SPI-NOR flash and want to boot from NVMe. What I would do is what every PC or Apple mainboard is doing: store system firmware (“BIOS”) in the SPI-NOR and have that use some generic method to boot from the NVMe (e.g. UEFI or U-Boot’s distro standard boot).
In case of the R3 (or R3 mini or R4) this means that TF-A and U-Boot should be in SPI-NOR, and U-Boot can be configured to carry out UEFI Standard boot and consider both USB and NVMe according to EFI boot variables, just like on a PC. That would put an end to writing endless how-tos for each and every board, and would allow standard installers of most Linux distributions with sufficient kernel driver support to just work.
Maybe porting Tow-Boot for the R3 (and the R4 and esp. also the R2 and R2Pro!) would be a worthwhile idea for that use-case. I’m using that every day on the PineBook Pro… https://tow-boot.org/
For OpenWrt (and hence for me) this is not so attractive: OpenWrt is headless and fits in a couple of megabytes of flash; the userland is tightly tied to the kernel – no need for even a EFI boot filesystem to chose which kernel to load as kernel and userland are inseparable anyway, all in one uImage.FIT.
But I was kinda betting that all other (more storage intense) distros would jump on the Standard Boot train to rid themselves of per-board custom installer images and all the maintenance effort associated with that.
Finally got to testing eMMC installation from Openwrt (in NAND).
Downloaded pre-made AP image.gz from http://www.woudstra.mywire.org/images/bpir3-emmc-ap.img.gz and prepared to sda1 USB as instructed…
Managed to install all necessary packages to openwrt and run the commands:
After few minutes all was done, but after switching DIPS to eMMC(LHHL) and PowerOn I can’t access AP on 192.168.1.33 and no WIFI24 on air.
Seems something is not working as expected…
Is the ’ bootpart enable 7 1 /dev/mmcblk0’ still valid for the latest image?
