[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