View previous topic :: View next topic |
Author |
Message |
TJNII l33t
Joined: 09 Nov 2003 Posts: 648 Location: for(;;);
|
Posted: Sun Jun 16, 2024 2:45 pm Post subject: [Solved] Kernel and DTS address requirements |
|
|
I'm trying to understand the requirements for the load address used in u-boot when booting the kernel, beyond just being a address in ram.
I have a OrangePi Zero H2+ booting using:
uImage: 0x4200:0000
DTB: 0x4300:0000
For the Allwinner H2+ (H3) the DDR RAM is mapped to 0x4000:0000 - 0xBFFF:FFFF.
So using the 0x4000:0000 range makes sense that the load command is loading the files into memory to be booted. However, I don't understand any address offset requirements within the RAM address space.
- For uImage I got 0x4200:0000 from Armbian U-Boot messages, I've been using a Armbian boot as a reference.
- I also used 0x4200:0000 for LOADADDR passed to the kernel `make uimage` command. I assume this should be the same as uses in U-Boot but that's an assumption.
- For the DTB file I just picked 0x4300:0000 as another address in RAM past the end of the kernel.
In searching I've been mostly finding examples of addresses, but no explanation of the offsets used within the ram space. Are there requirements that should be followed with these or does the kernel relocate off somewhere else and take over, such that the initial offsets don't matter? Why does the kernel uImage need the address baked in?
Last edited by TJNII on Thu Jun 20, 2024 2:26 pm; edited 1 time in total |
|
Back to top |
|
|
pingtoo Veteran
Joined: 10 Sep 2021 Posts: 1225 Location: Richmond Hill, Canada
|
Posted: Sun Jun 16, 2024 7:05 pm Post subject: |
|
|
TJNII,
Can you translate those 0xAAAA:BBBB notion into where in u-boot you set them? I am under impression that usually it is just a straight 0xAAAAA notion.
the LOADADDR in kernel build usually point to where the entry point to the kernel code. it is use to let u-boot know when u-boot finish load kernel into memory where to jump to transfer the execution.
DTB is kernel specific parameter, it is u-boot let kernel know where to find DT (device tree) so kernel can initialize. you can set it to anywhere as long as it is not overlapping with kernel address. usually is in lower address space. (kernel usually relocate itself to high address space) |
|
Back to top |
|
|
TJNII l33t
Joined: 09 Nov 2003 Posts: 648 Location: for(;;);
|
Posted: Thu Jun 20, 2024 2:26 pm Post subject: |
|
|
> Can you translate those 0xAAAA:BBBB notion into where in u-boot you set them?
Those are the addresses, the 0x and : are just sugar for human readability.
Code: |
ext2load mmc 0:1 42000000 boot/uImage
ext2load mmc 0:1 43000000 boot/sun8i-h2-plus-orangepi-zero.dtb
bootm 42000000 - 43000000
|
Doing a bit more digging and reading I've learned a bit more:
- UBoot reserves 8MB of memory at the start of the range, so BASE_ADDRESS + 0x00 to BASE_ADDRESS + 0x007f:ffff is reserved.
- This SOC reserves an address range of 2GB, but the board only has 512MB. So the real usable address range is 0x4000:0000 - 0x5fff:ffff. Taking the U-Boot reservation into consideration that narrows to 0x4080:0000 - 0x5fff:ffff
This guide does into how the kernel boots on ARM: https://people.kernel.org/linusw/how-the-arm32-linux-kernel-decompresses
I didn't find too much high level info on where the kernel decompresses, I got the impression the majority of users don't need to know or care, so there isn't much surface level discussion. There's several options on how the kernel might relocate, so there isn't a fixed & superficial "Relocate to within this range" setting. As for where the kernel relocates to I think I'm going to accept "It's complicated, involves multiple factors, and I don't have time to do the deep dive necessary to understand them right now." I think the spirit of my question has been answered, these addresses aren't critical as long as they're outside the U-Boot reserved range and reasonably low. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|