Hi
It looks real strange to ignore the authoritative entity and try to patch a
wrong DTB embedded in U-Boot.
Arm SystemReady is definitively aligning to the authoritative entities in
the platform to give U-Boot the right basis on which it can apply
additional overlays (providing it has a way to verify origin and integrity).
Couldn’t you find a cleaner way to just leverage the previous boot DTB ?
There is another discussion thread on similar thing with RISCV.
Le mer. 29 sept. 2021 à 13:30, K900 <m...@0upti.me> a écrit :
> We need this to boot with a custom DTB on BCM2711C0-based Pi 4s
>
> Signed-off-by: Ilya Katsnelson <m...@0upti.me>
> ---
> board/raspberrypi/rpi/rpi.c | 63 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 63 insertions(+)
>
> diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
> index 372b26b6f2..f074540091 100644
> --- a/board/raspberrypi/rpi/rpi.c
> +++ b/board/raspberrypi/rpi/rpi.c
> @@ -495,6 +495,67 @@ void *board_fdt_blob_setup(void)
> return (void *)fw_dtb_pointer;
> }
>
> +void copy_emmc_config(void *our_fdt)
> +{
> + /*
> + * As of 2021-09-28, the Pi 4 has two different revisions, one
> using a
> + * B0 stepping of the BCM2711 SoC, and one using a C0 stepping.
> + *
> + * The two SoC versions have different, incompatible DMA mappings
> for
> + * the on-board eMMC controller, which would normally make them
> require
> + * two different DTs.
> + *
> + * Unfortunately for us, the different revisions don't actually
> _use_
> + * different DTs - instead, the proprietary stage0 bootloader
> reads the DT,
> + * patches it in-memory, then passes the corrected DT to the OS.
> + *
> + * In our case, the OS is actually U-Boot, and U-Boot can choose to
> + * completely disregard the firmware-supplied DT and load a custom
> one
> + * instead, which is used by, e.g., NixOS.
> + *
> + * When that happens, the DT patches applied by the firmware are
> also
> + * thrown out, which leads to BCM2711C0 boards being unable to boot
> + * due to them trying to use the hardcoded DMA mappings in the DT
> + * (which are for the B0 revision).
> + *
> + * Work around that by manually copying the DMA region setup from
> the
> + * firmware-provided DT into whatever DT we're actually being asked
> + * to load.
> + A*/
> + void *fw_fdt = (void *)fw_dtb_pointer;
> + int fw_emmc_node;
> + int our_emmc_node;
> + int length;
> + const void *fw_value;
> + int result;
> +
> + fw_emmc_node = fdt_path_offset(fw_fdt, "emmc2bus");
> + if (fw_emmc_node < 0) {
> + printf("RPi: Failed to find EMMC config in FW DT: %d\n",
> fw_emmc_node);
> + return;
> + }
> +
> + our_emmc_node = fdt_path_offset(our_fdt, "emmc2bus");
> + if (our_emmc_node < 0) {
> + printf("RPi: Failed to find EMMC config in our DT: %d\n",
> our_emmc_node);
> + return;
> + }
> +
> + *fw_value = fdt_getprop(fw_fdt, fw_emmc_node, "dma-ranges",
> &length);
> + if (!fw_value) {
> + printf("RPi: Failed to get EMMC DMA ranges property from
> FW DT: %d\n", length);
> + return;
> + }
> +
> + result = fdt_setprop(our_fdt, our_emmc_node, "dma-ranges",
> fw_value, length);
> + if (result != 0) {
> + printf("RPi: Failed to set EMMC DMA ranges property in our
> DT: %d\n", result);
> + return;
> + }
> +
> + printf("RPi: successfully copied FW DT EMMC configuration to our
> DT!\n");
> +}
> +
> int ft_board_setup(void *blob, struct bd_info *bd)
> {
> int node;
> @@ -509,5 +570,7 @@ int ft_board_setup(void *blob, struct bd_info *bd)
> EFI_RESERVED_MEMORY_TYPE);
> #endif
>
> + copy_emmc_config(blob);
> +
> return 0;
> }
> --
> 2.33.0
>
> --
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.o...@linaro.org | Skype: ffozog
