i.MX6ULL, where does U-Boot end up in RAM?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX6ULL, where does U-Boot end up in RAM?

1,676 Views
jdepedro
Contributor IV

I am working with a i.MX6ULL based board. The U-Boot image that I am using has the following IVT table:

00000000 d1 00 20 40 00 00 80 87 00 00 00 00 2c f4 7f 87 |.. @........,...|
00000010 20 f4 7f 87 00 f4 7f 87 00 00 88 87 00 00 00 00 | ...............|

Which I believe means:

Header: 0x402000d1
Start: 0x87800000
dcd: 0x877ff42c
bootd: 0x877ff420
self: 0x877ff400
csf: 0x87880000

If I am not mistaken that should mean that U-Boot binary gets loaded to 0x87800000. That is also what is defined in the U-Boot source code:

#define CONFIG_SYS_TEXT_BASE   0x87800000

However, when I boot my board, that region of memory is empty:

U-Boot 2016.03-21152-ga57b13b942d5-dirty (Apr 26 2019 - 00:22:27 +0200)

CPU: Freescale i.MX6ULL rev1.0 528 MHz (running at 396 MHz)
CPU: Commercial temperature grade (0C to 95C) at 52C
Reset cause: WDOG
Board: Digi Connect IT Mini
Watchdog enabled
I2C: ready
DRAM: 128 MiB
NAND: 256 MiB
In: serial
Out: serial
Err: serial
Net: FEC0 [PRIME]
Normal Boot
Hit any key to stop autoboot: 0
=>
=>
=>
=> md.b 0x87800000
87800000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
87800010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
87800020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
87800030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

Also, investigating the problem I found out that:

* The IVT + Boot data + DCD section of U-Boot is copied to OCRAM @0x907400

* the U-Boot binary (u-boot.bin) is actually being copied to 0x87F2D000 (which seems to be some computation like END_MEMORY_REGION - U_BOOT_SIZE).

Can anyone help me understand this behaviour, and specifically where is U-Boot copied? The copy that I located @0x87F2D000 seems to be incomplete. I am trying to get secure boot working, and I am not able to find the CSF at the device memory (the CSF block is in the .imx file, but not in the device memory block starting @87f2d000).

Thanks

Labels (4)
0 Kudos
Reply
3 Replies

1,434 Views
weidong_sun
NXP TechSupport
NXP TechSupport

Dear Jose,

  See below, please!

------------------------------

IVT header
entry: Absolute address of the first instruction to execute from the image
reserved1: Reserved and should be zero
dcd: Absolute address of the image DCD. The DCD is optional so this field may be set to NULL if no DCD is required. See Device Configuration Data (DCD) for further details on DCD.
boot data: Absolute address of the Boot Data
self: Absolute address of the IVT. Used internally by the ROM
csf: Absolute address of Command Sequence File (CSF) used by the HAB library. See High Assurance Boot (HAB) for details on secure boot using HAB. This field must be set to NULL when not performing a secure boot
reserved2: Reserved and should be zero

------------------------------

Hope above information is helpful for you.

Have a nice day!

BR,

NXP TIC Weidong Sun

0 Kudos
Reply

1,434 Views
jdepedro
Contributor IV

To be fair that doesn't help too much. It doesn't explain why U-Boot is not present in ivt->self.

Anyway I was able to get secure boot working, so you can close this thread.

Thanks

0 Kudos
Reply

1,434 Views
weidong_sun
NXP TechSupport
NXP TechSupport

OK, good job!

I close the case now!

Have a nice day!

Best regards,

weidong

0 Kudos
Reply