13

I'm trying to understand embedded Linux principles and can't figure out addresses at u-boot output.

For example, I have UDOO board based on i.MX6 quad processor and I got following output from U-Boot:

U-Boot 2013.10-rc3 (Jan 20 2014 - 13:33:34)

CPU:   Freescale i.MX6Q rev1.2 at 792 MHz
Reset cause: POR
Board: UDOO
DRAM:  1 GiB
MMC:   FSL_SDHC: 0
No panel detected: default to LDB-WVGA
Display: LDB-WVGA (800x480)
In:    serial
Out:   serial
Err:   serial
Net:   using phy at 6
FEC [PRIME]
Warning: FEC MAC addresses don't match:
Address in SROM is         00:c0:08:88:a5:e6
Address in environment is  00:c0:08:88:9c:ce

Hit any key to stop autoboot:  0 
Booting from mmc ...
4788388 bytes read in 303 ms (15.1 MiB/s)
## Booting kernel from Legacy Image at 12000000 ...
   Image Name:   Linux-3.0.35
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    4788324 Bytes = 4.6 MiB
   Load Address: 10008000
   Entry Point:  10008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK

Starting kernel ...

I don't understand the value of Load address 0x10008000. According to documentation for this particular processor, at address zone 0x10000000 - 0xffffffff is mapped main memory. But what is 0x8000 offset? I can't figure out reason for this value.

I also don't understand address 0x12000000, where the kernel image is loaded from. Is there mapped memory region for SD card?

Please, can you give me some explanation for these addresses or even better, some references to resources about this topic. My goal is to learn how to port u-boot and Linux kernel to another boards.

Thank you!

jww
  • 97,681
  • 90
  • 411
  • 885
Ivo Slanina
  • 131
  • 1
  • 1
  • 3
  • 1
    The kernel boot requirements are documented in [Documentation/arm/Booting](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm/Booting). I can't remember offhand precisely _why_ TEXT_OFFSET is a thing, but it is. – Notlikethat Jan 24 '15 at 19:00
  • 1
    Typical is start of RAM + 0x8000 as 'ATAGS' are stored at the lowest address. Download the iMX6 reference manual from Freescale and all of the addresses will be in one of the first few chapters. – artless noise Jan 25 '15 at 02:41
  • 2
    *"I also don't understand address 0x12000000, where the kernel image is loaded from."* -- U-Boot uses the variable **loadaddr** to store this value. It's a somewhat arbitrary value in upper memory, but still well below where U-Boot is executing. This address is where the kernel uImage or zImage file is temporarily stored in main memory when read from nonvolatile memory (e.g. NAND or SDcard) or loaded from the network. This **loadaddr** for the uImage or zImage must be different from the actual kernel's "load address" of 0x10008000 to allow for decompression of the kernel image. – sawdust Jan 26 '15 at 08:42
  • 1
    *"Is there mapped memory region for SD card?"* -- No. There would be a command to read the SDcard (such as `fatload mmc 0:1 0x12000000 uImage`), and its only output is its result of *"4788388 bytes read in 303 ms (15.1 MiB/s)"*. You need to get the output of the **printenv** command to fully reveal & understand how autoboot works on your board. The salient environment variable is **bootcmd**. – sawdust Jan 26 '15 at 08:59
  • @sawdust _"of 0x10008000 to allow for decompression of the kernel image"_ not in this case since the image is uncompressed. The kernel will perform at least two things when u-boot transfers control to it. 1) uncompress itself if needed, and 2) relocate itself. In the case of the OP, when u-boot transfers control to the kernel, no uncompression is performed BUT the relocation is performed. The kernel relocates/copies itself to the start of RAM (HW address). – sessyargc.jp Jan 27 '15 at 02:39
  • @sessyargc.jp - *"not in this case since the image is uncompressed"* -- You don't know that. A zImage file with a uImage wrapper will always be reported as *"uncompressed" even though it is compressed. The *"uncompressed" "image type" as reported by the **iminfo** (or **bootm**) command is unreliable and often misleading. See http://stackoverflow.com/questions/22322304/image-vs-zimage-vs-uimage/22338835#22338835 – sawdust Jan 27 '15 at 06:11
  • @sawdust I stand by the output of u-boot. If it is misleading then you probably should try to submit a patch to u-boot to fix it. – sessyargc.jp Jan 27 '15 at 07:07
  • @sessyargc.jp -- The size of the OP's kernel image is *"4.6 MiB"*. A (compressed) zImage for my i.MX6Q board is only 3.6 MiB, but the uncompressed Image file is 10.6 megabytes. So what is the likelihood that this 4.6 MiB is also an uncompressed image? – sawdust Jan 27 '15 at 23:51
  • @sawdust ... submit a patch to u-boot to fix it. – sessyargc.jp Feb 02 '15 at 00:53
  • @sessyargc.jp how can a compressed kernel "uncompress itself if needed". Is it correct to say uncompression of the kernel must always be done by u-boot ? – user1502776 Jul 13 '18 at 07:14

2 Answers2

14

If you check the environment variables of the u-boot, you will find that kernel image is copied from boot device to the RAM location(Here, 12000000) through command like fatload.

Now, This is not the LOADADDRESS. You give LOADADDRESS to command line while compiling the kernel, This address is mostly at 32K offset from start of the RAM in Physical address space of the processor.

Your RAM is mapped at 10000000 and kernel LOADADDRESS is 10008000(32K offset). bootm command uncompress the kernel image from 12000000 to 10008000 address and then calls the kernel entry point.

Jagdish
  • 1,848
  • 3
  • 22
  • 33
  • well, i would add the 0x12000000 and 0x80008000 must be both in physical DDR address space. So 0x12000000 is only a preliminary place where to store the kernel, before decompression from u-boot, that will put the uncompressed binary into 0x80008000 that must also be set as load_addr in the kernel build. – Angelo Dureghello Feb 21 '20 at 11:17
1

check out include/configs folder. It contains all the board definitions

i.MX uboot include/configs

To port uboot to another port, base on a very similar board and modify from there.

alex
  • 53
  • 1
  • 4