what’s the difference between ‘load mmc’ and ‘load addr’?
And it stuck. what’s the difference between the 42000000 and the 70008000? Should the two be the same?
Do you really think answers to your questions are going to solve the real issue of «it stuck»? Why not provide the details of your board, the typical boot sequence, and what’s different that it is now failing? FWIW your uImage loaded at 0x42000000 seems to be unable to decompress (assuming that there’s a zImage within that uImage, which is typical for an ARM kernel).
1 Answer 1
Booting kernel from Legacy Image at 42000000 . - This first address is the one where u-boot will look for the (probably compressed) linux kernel image.
Entry Point: 70008000 — linux kernel entry point address
- Once the linux image has been decompressed and copied to the load address location, the entry point is the address where to start executing the kernel image, that in this case is exactly the start of the memory area where the kernel has been copied.
You can find further detail @ below link:
This is what really confused me: the uImage is on the file system, why u-boot trying to find it on some where in the memory? 42000000 is a memory address, right?
«This first address is the one where u-boot will look for the (probably compressed) linux kernel image.» — U-Boot isn’t «looking» for anything. That output line «## Booting kernel from Legacy Image at 42000000 . « is the direct consequence of a bootm 0x42000000 command. In other words you (or the bootcmd environment variable) explicitly told U-Boot that it should boot the uImage at that specific memory address.
Building kernel uImage using LOADADDR
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?
2 Answers 2
(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.
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.
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.
How do we Load Linux Image to appropiate location in Memory
We are trying to load a linux image into our DRAM at a specific location ,DRAM end address is 0x80000000 which we come to know from boot log which says «mem device ending address is 0x80000000».We are loading our image at address «0x5000000» and before that variuos section in image getting loaded at some address which is greater than «0x80000000»,for eaxmple again from boot logs
loading section to address 0xc5000000 from file position 0x1000, size is 0x5ac13e Whats meaning of «from file position 0x1000» in above line.
first section that loaded is .text section ,below is our vmlinux image dump of section header
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .text PROGBITS c5000000 001000 5ac13e 00 AX 0 0 4096 [ 2] .notes NOTE c55ac140 5ad140 000168 00 AX 0 0 4 [ 3] __ex_table PROGBITS c55ac2b0 5ad2b0 000fe0 00 A 0 0 4 [ 4] .rodata PROGBITS c55ae000 5af000 20a930 00 A 0 0 64 [ 5] __bug_table PROGBITS c57b8930 7b9930 0075fc 00 A 0 0 1 [ 6] .pci_fixup PROGBITS c57bff2c 7c0f2c 001a90 00 A 0 0 4 [ 7] .builtin_fw PROGBITS c57c19bc 7c29bc 0000cc 00 A 0 0 4 Its quite a big list, so didn’t post full .But one thing we can see here .text section is greater than DRAM end address ,so image should not be loded properly though we are not getting any error after loading first section it keeps on loading other sections but after this message it hangs.
program load complete, entry point: 0x5000000, size: 0x92e7fc My question is how can I align these different sections address to our DRAM address, Is objcopy utility could be used here to change address of these Different sections.
Is there any way to set these section addresses before compilation?? Second thing what could be reason for this Hang afer program load complete.
asked Mar 20 ’13 16:03
Amit Singh Tomar
People also ask
Linux-based operating systems use a virtual memory system. Any address referenced by a user-space application must be translated into a physical address. This is achieved through a combination of page tables and address translation hardware in the underlying computer system.
Linux uses demand paging to load executable images into a processes virtual memory. Whenever a command is executed, the file containing it is opened and its contents are mapped into the processes virtual memory.
Memory-mapping is a mechanism that maps a portion of a file, or an entire file, on disk to a range of addresses within an application’s address space. The application can then access files on disk in the same way it accesses dynamic memory.
mmap works by manipulating your process’s page table, a data structure your CPU uses to map address spaces. The CPU will translate «virtual» addresses to «physical» ones, and does so according to the page table set up by your kernel. When you access the mapped memory for the first time, your CPU generates a page fault.
1 Answers
from file position 0x1000 means what it says. You have it in the dump:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al . [ 1] .text PROGBITS c5000000 001000 5ac13e 00 AX 0 0 4096 It’s where the .text section starts in the file, at offset 0x1000 .
But one thing we can see here .text section is greater than DRAM end address
Nope, it’s not greater (not in the sense of bigger, at least), it’s compiled in the expectation that it’ll be loaded at address 0xc5000000 in the memory.
so image should not be loded properly though we are not getting any error after loading first section it keeps on loading other sections
The image can be loaded anywhere, it’s just data for the purpose of loading.
OTOH, if loading section to address 0xc5000000 means what it says, the file gets loaded into nowhere since your RAM ends at 0x7fffffff .
but after this message it hangs.
And that’s expected. Machine code is rarely position-independent and so if you load it at a location different from where it’s supposed to be loaded, it’ll not work. Or if it doesn’t even get loaded, then what are you going to execute? Garbage.
Is there any way to set these section addresses before compilation??
Depending on the system you may have one of the two below options or both:
- set up page translation in such a way that virtual addresses from 0xc5000000 and up map to physical addresses from 0x5000000 and up for the entire program
- find the linker script that your compiler is using and change the initial section address from 0xc5000000 to 0x5000000 , google this up, see compiler/linker documentation
Also, it’s a bit odd that the entry point is at 0x5000000 . Not that this is necessarily wrong, it’s just that it’s rarely the case. I’d make sure that the start label (or _start or whatever it is) indeed receives the same address as the beginning of the .text section. If, for some reason, it’s not the case, there’s something wrong either with the linker script or the compiler/linker command-line options or with the loader.
How do we Load Linux Image to appropiate location in Memory
We are trying to load a linux image into our DRAM at a specific location ,DRAM end address is 0x80000000 which we come to know from boot log which says «mem device ending address is 0x80000000».We are loading our image at address «0x5000000» and before that variuos section in image getting loaded at some address which is greater than «0x80000000»,for eaxmple again from boot logs
loading section to address 0xc5000000 from file position 0x1000, size is 0x5ac13e Whats meaning of «from file position 0x1000» in above line. first section that loaded is .text section ,below is our vmlinux image dump of section header
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .text PROGBITS c5000000 001000 5ac13e 00 AX 0 0 4096 [ 2] .notes NOTE c55ac140 5ad140 000168 00 AX 0 0 4 [ 3] __ex_table PROGBITS c55ac2b0 5ad2b0 000fe0 00 A 0 0 4 [ 4] .rodata PROGBITS c55ae000 5af000 20a930 00 A 0 0 64 [ 5] __bug_table PROGBITS c57b8930 7b9930 0075fc 00 A 0 0 1 [ 6] .pci_fixup PROGBITS c57bff2c 7c0f2c 001a90 00 A 0 0 4 [ 7] .builtin_fw PROGBITS c57c19bc 7c29bc 0000cc 00 A 0 0 4 Its quite a big list, so didn’t post full .But one thing we can see here .text section is greater than DRAM end address ,so image should not be loded properly though we are not getting any error after loading first section it keeps on loading other sections but after this message it hangs.
program load complete, entry point: 0x5000000, size: 0x92e7fc My question is how can I align these different sections address to our DRAM address, Is objcopy utility could be used here to change address of these Different sections. Is there any way to set these section addresses before compilation?? Second thing what could be reason for this Hang afer program load complete.