U-boot load address and kernel's LOADADDR overlap?

[Grodriguez]

Hi all,

The file include/configs/stm32mp1.h in U-boot defines CONFIG_LOADADDR to 0xc2000000. I understand this is the address in RAM where u-boot puts the uImage loaded from persistent storage (SD, NAND, etc).

At the same time, according to [2], the kernel uImage is built with LOADADDR set to 0xc2000040. I understand this is the address where the kernel is relocated.

Wouldn't this be a problem, as the address of the loaded uImage and the address used for relocation seem to overlap?

Also, I think that common convention for ARM is to use <base RAM address> + 0x8000 for relocating the kernel; what is the reason to use 0xc2000040 here?

[1]: https://github.com/STMicroelectronics/u-boot/blob/v2020.01-stm32mp/include/configs/stm32mp1.h

[2]: https://github.com/STMicroelectronics/meta-st-stm32mp/blob/dunfell/recipes-kernel/linux/linux-stm32mp/README.HOW_TO.txt

[JeanPhilippeR · Accepted solution]

Dear @Grodriguez​ 

U-Boot is loading a uImage which is composed of U-Boot header of 64B (0x40) and a zImage (compressed).

As zImage is compressed, kernel have to uncompress it at execution, and it will be uncompressed to final execution address 0xC0000000.

In order to avoid a U-Boot relocation of the zImage, before uncompression, it is better to put it at an address upper than the final full kernel lenght, so it is the reason why we select an address over 0xC20000000.

To resume, U-Boot copy the uImage @ 0xC2000000; in that way the zImage is @ 0xC2000040, which is a good address to execute the uncompression in place. When uncompression, the final kernel @ is @ 0xC0000000.

For reminder, 0xC000000, is the CONFIG_PAGE_OFFSET defined for Arm in:

See arch/arm/Kconfig

config PAGE_OFFSET

              hex

              default PHYS_OFFSET if !MMU

              default 0x40000000 if VMSPLIT_1G

              default 0x80000000 if VMSPLIT_2G

              default 0xB0000000 if VMSPLIT_3G_OPT

              default 0xC0000000

Best regards

Jean-Philippe

[Grodriguez]

Hi @JeanPhilippeR​ 

Thank you for your answer.

I think in my original question I mixed up the load / entry address of the zImage (executable image with embedded decompressor) with the final location of the uncompressed kernel.

Your answer explains this perfectly; only one minor comment: If I am correct the final address of the kernel after decompression is not 0xC0000000 but 0xC0008000 (i.e. start of RAM + TEXT_OFFSET).

Thank you,

Guilllermo