[BPI-R2] current uboot-support

Banana Pi BPI-R4/BPI-R3 Mini/BPI-R3/BPI-R64/BPI-R2
21

have now tested it…i have uboot 2020-04-rc2 currently installed on my sdcard

BPI-R2> version
U-Boot 2020.04-rc2-bpi-pwm (Feb 24 2020 - 18:04:12 +0100)

arm-linux-gnueabihf-gcc (Ubuntu 8.3.0-6ubuntu1~18.04.1) 8.3.0
GNU ld (GNU Binutils for Ubuntu) 2.30
BPI-R2> pci enum
Port0 link down

hangs till watchdog-reset

22

Both “PHY Core” and “MediaTek T-PHY Driver” are enabled. Actually I was using @frank-w’s default config when hit this problem for the first time. Since then I had tried multiple config changes but I bet this problem is not a software one as hang happens when trying to readw() from PCI config space. Well, to be more precise, problem seem to be not a “pure software one” but it is obviously is a consequence of the software stack doing something wrong - either performing a bus/memory access at the moment when it’s not OK from hardware PoV or misconfiguring hardware in a way that it hangs when trying to access PCI config space for a non-existent device.

23

I had been asked in another thread if there’s a way to use a EFI boot style with R2. Answer is yes, it is possible using u-boot’s bare minimum EFI implementation and distro_bootcmd. Here is a link to the branch with additional changes required to get it properly working on R2:

Also some changes are needed compared to defconfig:

+CONFIG_BOOTM_EFI=y
+CONFIG_CMD_BOOTEFI=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_SYSBOOT=y
+CONFIG_EFI_DEVICE_PATH_TO_TEXT=y
+CONFIG_EFI_LOADER_HII=y
+CONFIG_EFI_LOADER=y
+CONFIG_FS_EXT4=y
+CONFIG_GENERATE_SMBIOS_TABLE=y
-CONFIG_ENV_IS_IN_MMC=y
+CONFIG_ENV_IS_NOWHERE=y
+CONFIG_SMBIOS_MANUFACTURER="mediatek"
+CONFIG_SMBIOS_PRODUCT_NAME="mt7623"
-CONFIG_USE_DEFAULT_ENV_FILE=y

Main points for changes above:

  • Disable use of external default env file (we want to rely on default u-boot distro_bootcmd behavior);
  • Disable storing/reading environment to/from eMMC at some offset (default is 0x100000). Having it disabled ensures that user can’t spoil environment in any way so u-boot will always use distro_bootcmd. Also it prevents data corruption on eMMC in case some partition overlap with an offset to which environment is stored.
  • Enable efiboot support (bootefi command; support for EFI-stubbed kernels for bootm; several other things like SMBIOS tables generation, e.t.c.).
  • Enable support for ext2/3/4 - just in case, not really required.

With all of these in place it is possible to auto-boot board using PC-like EFI boot scheme. Typical approach would be to use GPT partitioning scheme on any of attached SATA disks or on SD or eMMC, create EFI system partition and place EFI bootloader (usually GRUB2 arm-efi core image) named bootarm.efi to the EFI/BOOT/ subdirectory. For linux kernel images it is important to build kernel with CONFIG_EFI_STUB=y and CONFIG_EFI=y - there would be problems booting using EFI grub2 otherwise.

It should be noted that distro_bootcmd is not limited to booting with EFI. It also searches for “extlinux/extlinux.conf”, “boot.scr.uimg” and “boot.scr” on any partition that is marked as bootable (via the MBR bootable flag or GPT legacy_bios_bootable attribute) either under “/boot” directory or directly at the root of the partition.

This behavior is a rough approximation of what is defined/expected by the The Boot Loader Specification. It allows to manage board boot with nearly the same tools and approach as it done on generic PC.

1 Like