On 11/02/2016 12:06 PM, Cédric Schieli wrote:
If the fw_boot_param saved at an early stage points to a valid FDT
blob, let's expose it in ${fw_fdt_addr}.
I'd suggest naming the variable dtb_addr not fw_fdt_addr. Both names are
just as easy to use from custom U-Boot scripts, however certain parts of
U-Boot (such as the extlinux.conf interpreter) automatically use the
value stored in $fdt_addr if not DTB statement is found in
extlinux.conf. That will make it much easier for people to actually pass
this FW-supplied DTB to the kernel automatically.
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
+/*
+ * If the firmware provided us with a valid FDT at boot time, let's expose it
+ * in ${fw_fdt_addr} so it may be passed unmodified to the kernel.
+ */
+static void set_fw_fdt_addr(void)
+{
+ char s[3 + 2 * sizeof(fw_boot_param)];
+
+ if (getenv("fw_fdt_addr"))
+ return;
+
+ if (fdt_magic(fw_boot_param) != FDT_MAGIC)
+ return;
+
+ snprintf(s, sizeof(s), "0x%X", (unsigned int)fw_boot_param);
+ setenv("fw_fdt_addr", s);
If you use setenv_hex(), that will simplify the code here.
Also, for this to work, you probably want to implement
board_get_usable_ram_top(). Doing so will guarantee that when U-Boot
relocates to the top of RAM, it won't over-write the FW-supplied DTB
content. For an example (only partially tested, and that will only
build/run on a subset of supported RPi models), see:
https://github.com/swarren/u-boot/commit/8097d58931b42e88c74c1e88819f67b2e3cfb6bf#diff-e3f2f2e4eec27fe7837b4853cb5be10bR292
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
