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

Banana Pi Router design
1

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

Commits · ericwoud/arm-trusted-firmware · GitHub

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)
4

I’ve added the ability for ATF to use preloaded images.

In a sense, this could be used as a function similar to kexec, as kexec itself it not supported fully by the hardware. Because a real soft reset is used and the boot-sequence is not altered, the preloaded image should boot exactly the same as a normal reboot.

It is kept very simple, which does have a downside. The memory needs to be allocated contiguous, so it can only be allocated at boot time.

5

Hello Eric

can you help me?

i have done

wget --no-check-certificate https://www.woudstra.mywire.org/images/bpir64-sdmmc-rt.img.gz
gunzip -c bpir64-sdmmc-rt.img.gz | sudo dd status=progress of=/dev/sdb

and got the error

image

what is wrong?

6

Hi Krantic

I have done little testing on R64 lately. Looks like you’re doing nothing wrong there.

I will look in to this and come back to it tomorrow…

Thanks for reporting

Edit:

@Krantic : Does it stop there?

7

yes, it does not start at all

8

@Krantic

I’ve changed the code for copying bl31 back to using memcpy().

It seems the R64 has trouble using memcpy16(), at least in copying builtin bl31 image.

I’ve updated the R64 images, but have not gotten to test them yet…

9

Thank you Eric. When i can test it ?

10

You can test it any time you like.

11

does this mean that it is already ready ? )

where can i downlod it ?

a… https://www.woudstra.mywire.org/images/

thank you Eric )

12

It is the same download, it is updated with newer atf version.