[U-Boot] [PATCH 2/2] rpi: expose the firmware provided FDT blob in ${fw_fdt_addr}
Stephen Warren
swarren at wwwdotorg.org
Sun Nov 6 03:55:01 CET 2016
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
More information about the U-Boot
mailing list