[BPI-R3][BPI-R4] uboot design and portable images


There has been discussion on various threads about uboot, so I thought I would bring it to a single thread.

Description of problem:

One wishes to have a single image that one can put on an SD card (or emmc) that will work(boot linux) on the BPI-R3 and BPI-R4.

Problems to overcome:

To boot an arm64 platform, one needs board specific parts, and then a general part that will work on both BPI-R3 and BPI-R4.

Specific parts:
1) uboot
2) uboot environment
3) device tree
4) ethernet mac addresses   (Commonly put this in a uboot environment variable or in the device tree)
General Parts:
5) Linux kernel  (Image.gz)
6) initrd   (initrd.gz or squashfs)
7) Linux file system.

Suggested solution:

Place 1,2,3,4 on the SPI NAND that is present on the BPI-R3/R4 (but could be SPI NOR for BPI-R3) and place 5,6,7 on the either SD Card, eMMC, or NVME. The user generally only needs to change 5,6,7 and very rarely needs to touch 1,2,3,4.

UBOOT boot menu becomes:

1) Boot from SD Card
2) Boot from eMMC
3) Boot from NVME
4) Boot from USB
5) Boot from Network
6) Boot from Serial Port
7) Boot from recovery  (uploads the image via http / browser)
8) Boot from file

The uboot menu then remembers which way it booted last time, and repeats that automatically after a menu timeout.

Maybe store the “last-boot-method” in the eeprom.

Maybe have a chainboot, to chainboot the OpenWrt U-Boot if needed. We could probably do this by just making our u-boot able to load the OpenWrt itb if the user had put the .itb on a SD Card or similar.

I think it is best to first agree on the user interface and where each part is stored, e.g. like the above, before we actually go and do it.

For example, the above works for Linux, but does it work for the other stakeholders? e.g. openwrt and android.


SW1-A and SW1-B is for boot strap selecting;
SW1-C is that SPI-Nand or SPI-Nor Device is connected to CPU’s SPI bus; They both share the same SPI bus.
SW1-D is that SD Card or EMMC device is connected tp CPU’s EMMC bus. They both share the same EMMC bus.

Switch A selects boot from SPI or eMMC device.
SD card and EMMC device share one eMMC CPU controller. Switch B selects which device.
The BPI-R4 only has the SPI-Nand device, so no sharing of SPI device needed.

On the BPI-R4, is seems that we might be able to use GPIO66 to override switch B after boot, so after booting the NAND, we can use GPIO66 to select SD Card or EMMC.  (This needs testing)

So, we might wish to hide menu items depending on dip switch settings.

The “8) Boot from file” would have to ask the user for which device, it would then list the files on the selected device, then ask the user for a filename to boot from that device. This is analogous to the “boot from file” option in some x86 BIOS / UEFI boot menus and also similar to the current BPI-R4 uboot boot option.

Nice, thanks for picking up my and others’ suggestion.

My thoughts:

  • for the R3 I would use the NOR instead of NAND. It’s big enough and in contrast to NAND it’s always error free
  • usb boot should also be supported, should behave similar to an SD card I guess
  • additional recovery option for web failsafe as used in mediatek’s custom uboot (I think it basically allows you to upload the image via http / browser)
  • could store the last / default boot device either with the uboot env on an ubi volume/partition (what’s the right term?), or use the eeprom you and Frank played around with. Because that’s byte addressable/writable, no need to do a full sector write on NAND each time the user picks a different device (though no idea how serious NAND wear is in that regard)

Since OpenWrt ships with its own U-Boot, I wouldn’t try to interfere here. Just chain from this U-Boot to their U-Boot, if that works in a generic way without having to set specific adresses for emmc, sd, nvme etc.

Nand/nor and sdmmc/emmc should be only 1 menu entry as they depend on hw switches…so “boot from mmc” and “boot from spi”

The spi option should include a recovery (linux kernel with initrd).

Boot from serial imho is the ramboot option which happens before uboot is displayed and used for bricked devices without external changable bootdevice (sdmmc).

File is a bit confusing…where is the file loaded?