[PATCH v4 5/6] riscv: Copy the reserved-memory nodes to final DT

[Atish Patra <atishp@atishpatra.org>]

On Mon, Mar 23, 2020 at 11:23 PM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
> On 3/24/20 5:16 AM, Atish Patra wrote:
> > The DT used by U-Boot may be different from the DT being passed to
> > the OS if the DT is loaded from external media such as network or
> > mmc. In that case, the reserved-memory node needs to be copied to
> > the DT passed to the OS.
>
> The bootefi command works in the following sequence:
>
> * copy the passed fdt of if none is passed the internal fdt
> * call image_setup_libfdt() for the copy
> * create memory reservations in the UEFI memory map
>
> Cf.
> fef907b2e440 ("efi_loader: create reservations after ft_board_setup")
> 7be64b885a36 ("cmd: bootefi: Parse reserved-memory node from DT")
>
> image_setup_libfdt() executes among others:
>
> * fdt_chosen()
> * arch_fixup_fdt()
>
> Please, explain why you need to copy memory reservations, if
> arch_fixup_fdt() is executed inside the bootefi command:
>

As per my understanding, there can be two different DTs in U-Boot.
1. Internal device tree or DT passed from previous stage (gd->fdt_blob). This
    device tree is being used to boot OS as well.
2. User can load the DT from MMC/network to any valid address and use
that address in bootefi/booti command line to boot OS.

efi_install_fdt copies DT from the given user address (via cmdline) and copies
to the efi memory.

There is no need to 2nd copy for case 1 as the DT already contains the
reserved-memory node. In case 2, the DT loaded from external media may not
have the reserved memory regions set by the firmware. That's why we need to
copy the reserved-memory nodes. Now, arch_fixup_fdt() is the last place to edit
the DT passed to OS. The copy operation has to be done in arch_fixup_fdt.
For case 1, fdtdec_add_reserved_memory will simply return without
modifying the DT.

> What would be the source of memory reservation that you would otherwise
> miss in the final device tree? Do you expect that the Linux device tree
> would lack reservation that are generated on the fly before U-Boot?
>
> Best regards
>
> Heinrich
>
> >
> > Signed-off-by: Atish Patra <atish.patra@wdc.com>
> > Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
> > ---
> >   arch/riscv/lib/bootm.c | 8 +++++++-
> >   1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c
> > index 87cadad5016d..8ff8db6bf533 100644
> > --- a/arch/riscv/lib/bootm.c
> > +++ b/arch/riscv/lib/bootm.c
> > @@ -28,8 +28,8 @@ __weak void board_quiesce_devices(void)
> >
> >   int arch_fixup_fdt(void *blob)
> >   {
> > -#ifdef CONFIG_EFI_LOADER
> >       int err;
> > +#ifdef CONFIG_EFI_LOADER
> >       u32 size;
> >       int chosen_offset;
> >
> > @@ -50,6 +50,12 @@ int arch_fixup_fdt(void *blob)
> >       /* Overwrite the boot-hartid as U-Boot is the last stage BL */
> >       fdt_setprop_u32(blob, chosen_offset, "boot-hartid", gd->arch.boot_hart);
> >   #endif
> > +
> > +     /* Copy the reserved-memory node to the DT used by OS */
> > +     err = riscv_fdt_copy_resv_mem_node(gd->fdt_blob, blob);
> > +     if (err < 0)
> > +             return err;
> > +
> >       return 0;
> >   }
> >
> >
>


-- 
Regards,
Atish