[BPI-R3] & {BPI-R64] ATF with FAT32 load capabilities

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

I Added FAT32 functionality to my branch of Arm Trusted Firmware. (still need to test it on R64 also, but should work)

https://github.com/ericwoud/arm-trusted-firmware/commits/bpir

Set partition partlabel with:

parted ${DEVICE} name ${PARTITION_NUMBER} boot

Format the boot partition with:

mkfs.vfat -v -F 32 -S 512 -s 16 -n "BPI-BOOT" ${DEVICEpX}

With 16 sectors per cluster, it will load faster. Default is 1, which is significantly slower.

Now:

When ATF starts, if there is a partition with partlabel fip, it will use it as it would normally. If there is no partition with partlabel fip, but there is one with partlabel boot, then ATF will try to load u-boot.bin from the boot partition.

If it is not there, it will examine the bootcfg directory on the boot partition. The files in this directory contain the path of the files to load, in ascii format. They may, but not have to, start with / or /boot/.

bootcfg/bl31      (optional as it is already buildin)
bootcfg/linux
bootcfg/initrd    (only used if 'linux' is a linux kernel)
bootcfg/atfdtb    (only used if 'linux' is a linux kernel)

The file bootcfg/linux may contain the path of a u-boot.bin file instead if you want to use this option.

To test the fat32 library, I have a userspace tool that can use the very same library to extract a file from a fat32 image. This tool can also list the entire contents of the image. Because the function is recursive, this list fuction cannot be used in ATF. It uses too much stack. It is however a good test if all entries can be searched through correctly.

The tool and same library are here:

2

This sounds like a good way to support both bootchains…maybe you want to upstream your work?

3

Indeed, I keep the ATF functioning as normal, with extra options. The R3 also looks for the fip partition at any offset, where the original version does not. I also have xz and nmbm support removed. Trimming the source to the minimum solved the issue of reboot from linux hanging the R64. For now sdmmc and emmc supported, maybe later also nor (no fat32 support there). It is meant only to be used for BPI-R64 and BPI-R3. ATF version v2.8 and can easily be rebased to latest.

These are extra:

  • boot kernel (loading dtb and initrd if bl33 = kernel)
  • use bl31 built-in image (if supplied it will be loaded instead)
  • use fat32 boot partition instead of fip (if fip partition not present)
  • possibility to build emmc version with sdmmc BROM_HEADER_TYPE (usefull for R3)