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.