Hi,
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.
Caveats:
BPI-R3:
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.
BPI-R4:
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.