FDT and RAM information

NXP LX2160
1

I am still struggling with passing the patched FDT from u-boot with the updated RAM information to the OS. I have the board working just fine with the hard-coded values, but it won’t work for someone else who has a different configuration.

As far as I can tell u-boot has the code to update the FDT with the information on the RAM banks and reserved ranges in ft_board_setup(). That code seems to run only if using the bootm command to start a kernel image that’s advertised as “Linux” (not that u-boot cares about the OS, it’s just the protocol).

What I did then is wrap the raw OS image with a u-boot header that claims to be Linux, and ran the following commands:

=> fatload mmc 0:2 0x80200000 honeycomb.img
16143280 bytes read in 714 ms (21.6 MiB/s)
=> fatload mmc 0:2 0x80100000 fsl-lx2160a-clearfog-cx.dtb
45111 bytes read in 21 ms (2 MiB/s)
=> bootm 0x80200000 - 0x80100000

This seems to be what u-boot is expecting, but then it crashes.

## Booting kernel from Legacy Image at 80200000 ...
   Image Name:   
   Created:      2022-08-01  23:21:01 UTC
   Image Type:   AArch64 Linux Kernel Image (uncompressed)
   Data Size:    16143216 Bytes = 15.4 MiB
   Load Address: 80200000
   Entry Point:  80200000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 80100000
   Booting using the fdt blob at 0x80100000
   Loading Kernel Image
   Loading Device Tree to 000000009fff1000, end 000000009ffff036 ... OK
Releasing fan controller full speed gpio
fsl-mc: DPL not deployed, DPAA2 ethernet not work

Starting kernel ...

"Synchronous Abort" handler, esr 0x02000000

Before I spend more time on debugging this, am I in the right direction? Should the FDT blob be loaded from the SD card, or is it already available somewhere? Are there any restrictions on where the OS image is located?

Note that the same image boots just fine if it is not advertised as “Linux”, but in that case the FDT is not patched and is not passed as an argument to the OS.

–Elad

2

These questions are generally better to be asked on NXP’s forums. They may already have solved these issues for other customers.

3

Turns out that the u-boot image doesn’t automatically set the entry point from the ELF information in the OS image (I noticed that the ELR register value in the u-boot crash report was the load address instead of the entry point). Manually setting the entry point fixes the problem. I can see that patched FDT in the OS now.

–Elad