What happened before entering u-boot

Technical Support
1

What exactly happened before entering u-boot?

2

Hi,

first, the SoC loads the BL1 (first lever bootloader) from maskrom, then depending on state described by the flowchart in the S912 datasheet, BL1 loads and authenticates BL2 from external storage.

BL2 is mainly in charge of setting up DDR and clocks, then it loads and authenticates BL30 from the same storage as itself.

BL30 is in charge of various things like setting up (undisclosed) security stuff and loading the firmware of the cortex-M3 core that handles power-management and CPU cores DVFS (also known as SCPI in ARM terminology).

BL2 also loads/authenticates BL31, also called the secure monitor, running in trustzone and in charge of providing secure services to the main OS, and finally BL33, which is u-boot.

1 Like
3

I did some further research and clarify here.

The u-boot.bin is constructed with bl2, bl30, bl31, bl32, bl33(u-boot itself).

It is written to mmcblk0p1 (which is also called bootloader), starting at offset 512 bytes (1 block). bootloader partition starts at offset 0 of mmcblk0.

Meanwhile two special partitions mmcblk0boot0 and mmcblk0boot1 are also written the same content.

4

bl30, bl31 and bl33 are stored in a FIP image on eMMC.
you can see that along with the flash offsets in the serial console traces output by BL2 just before u-boot starts.

eg. on the kvim2 pro:

Load fip header from eMMC, src: 0x0000c200, des: 0x01400000, size: 0x00004000
New fip structure!
Load bl30 from eMMC, src: 0x00010200, des: 0x01100000, size: 0x0000d600
Load bl31 from eMMC, src: 0x00020200, des: 0x05100000, size: 0x0002c600
Load bl33 from eMMC, src: 0x00050200, des: 0x01000000, size: 0x00055000

the ‘src’ values are offset in eMMC (probably bytes, because all values are aligned to 0x200, which is standard sector size), and ‘des’ are RAM addresses.

1 Like
5

by the way, FIP stands for “Firmware Image Package” and comes from ARM Trusted Firmware, as described here

9

the following command will show you that:

dmesg | grep mmcblk0p
10

[ 2.849364@2] [mmcblk0p01] bootloader offset 0x000000000000, size 0x000000400000
[ 2.849511@1] [mmcblk0p02] reserved offset 0x000002400000, size 0x000004000000
[ 2.849645@2] [mmcblk0p03] cache offset 0x000006c00000, size 0x000020000000
[ 2.849773@1] [mmcblk0p04] env offset 0x000027400000, size 0x000000800000
[ 2.849897@2] [mmcblk0p05] logo offset 0x000028400000, size 0x000002000000
[ 2.850021@1] [mmcblk0p06] recovery offset 0x00002ac00000, size 0x000002000000
[ 2.850156@2] [mmcblk0p07] rsv offset 0x00002d400000, size 0x000000800000
[ 2.850290@1] [mmcblk0p08] tee offset 0x00002e400000, size 0x000000800000
[ 2.850422@2] [mmcblk0p09] crypt offset 0x00002f400000, size 0x000002000000
[ 2.850559@1] [mmcblk0p10] misc offset 0x000031c00000, size 0x000002000000
[ 2.850691@2] [mmcblk0p11] boot offset 0x000034400000, size 0x000002000000
[ 2.850830@1] [mmcblk0p12] system offset 0x000036c00000, size 0x000080000000
[ 2.850959@2] [mmcblk0p13] data offset 0x0000b7400000, size 0x000dd8400000

12

you can also look around in /sys/class/mmc_host/emmc/emmc:0001/block/mmcblk0/

14

this source code might also provide you some hints: https://github.com/khadas/linux/blob/khadas-vim-4.9.y/drivers/amlogic/mmc/emmc_partitions.c

also here: https://github.com/khadas/u-boot/blob/ubuntu/common/store_interface.c#L1174

16

I don’t know if the FIP format has a human-readable specification, however you can take a look at fiptool’s source to see how it’s working: https://github.com/ARM-software/arm-trusted-firmware/tree/master/tools/fiptool and https://github.com/ARM-software/arm-trusted-firmware/blob/master/include/tools_share/firmware_image_package.h

note also that some of the items in the amlogic boot images may be encrypted, so you may not read them directly (check the calls to aml_encrypt_$(SOC) in u-boot’s Makefile for that)

17

Could you please explain what is BL32 or refer me to a document/link ?

I don’t see such a file in khadas github but in makefiles there are references to it!

18

the bl.* terminology comes from ARM Trusted Firmware: https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/image-terminology.html#trusted-firmware-images

in this case, BL32 is a trusted OS (such as OP-TEE: https://github.com/OP-TEE/optee_os) and is not mandatory to run Linux

note that ARM-T-F recently changed its terminology, and what amlogic calls BL30/BL301 is now referred to as SCP_BL2 in the documentation I linked above
(SCP meaning “System Control Processor” in ARM terminology)

1 Like