embedded linux - Building kernel uImage using LOADADDR

Question

While building the kernel I am giving LOADADDR as "0x80008000":

make uImage LOADADDR=0x80008000

Can you please help to understand what is the use of this? Can I change the LOADADDR, is there any restriction on the length of the LOADADDR?

Answer 1

(I'm assuming that you're using ARM based on the mention of U-Boot and the value of LOADADDR.)

Can you please help to understand what is the use of this?

LOADADDR specifies the address where the kernel image will be located by the linker. (This is true for a few architectures (e.g. Blackfin), but not for ARM.

LOADADDR specifies the address where the kernel image will be located by U-Boot and is stored in the U-Boot header by the mkimage utility. Typically the load address (for placement in memory) is also the start address (for execution). Note that the uImage file is typically just the (self-extracting, compressed) zImage file with the U-Boot wrapper.

Can I change the LOADADDR,

Yes, but according to (Vincent Sanders') Booting ARM Linux that would be contrary to ARM convention:

• Despite the ability to place zImage anywhere within memory, convention has it that it is loaded at the base of physical RAM plus an offset of 0x8000 (32K). This leaves space for the parameter block usually placed at offset 0x100, zero page exception vectors and page tables. This convention is very common.

(The uImage mentioned in your question is probably just a zImage with the U-Boot wrapper, so the quotation does apply.)

is there any restriction on the length of the LOADADDR?

The "length"? If you're using a 32-bit processor, then the length of this address would be 32 bits.

---

ADDENDUM

arch/arm/boot/Makefile only uses LOADADDR for building the uImage from the zImage.

From (Russel King's) Booting ARM Linux the constraints on this LOADADDR are:

The kernel should be placed in the first 128MiB of RAM. It is recommended that it is loaded above 32MiB in order to avoid the need to relocate prior to decompression, which will make the boot process slightly faster.

When booting a raw (non-zImage) kernel the constraints are tighter. In this case the kernel must be loaded at an offset into system equal to TEXT_OFFSET - PAGE_OFFSET.

The expected locations for the Device Tree or ATAGs or an initramfs can add more constraints on this LOADADDR.