[PATCH v5 0/6] RISC-V DT related fixes for reserved memory & UEFI

[Atish Patra]

On Mon, Apr 6, 2020 at 11:51 PM Ard Biesheuvel
<ard.biesheuvel at linaro.org> wrote:
>
> On Tue, 7 Apr 2020 at 08:46, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> >
> > On 4/6/20 11:01 PM, Ard Biesheuvel wrote:
> > > On Mon, 6 Apr 2020 at 22:45, Atish Patra <atish.patra at wdc.com> wrote:
> > >>
> > >> This series adds few DT related fixes required for Linux EFI stub to work
> > >> on RISC-V.
> > >>
> > >
> > > I'm not sure how this is supposed to work, since DT reserved memory
> > > regions are not used by EFI. If you want to reserve memory on a UEFI
> > > system, you have to reserve it in the UEFI memory map from firmware.
> > > The DT reserved-memory node is taken into account too late, the
> > > /memreserve/ entries are ignored entirely.
> >
> > Hello Ard,
> >
> > thanks for reviewing.
> >
> > What do you mean by "The DT reserved-memory node is taken into account
> > too late"?
> >
> > Cf. commit 7be64b885a36 ("cmd: bootefi: Parse reserved-memory node from DT")
> >
>
> What I mean is that the EFI stub in Linux uses memory allocation
> functions, expecting the firmware to ensure that those allocations do
> not conflict with memory descriptions and reservations in DT. So if
> the firmware wants to express this redundantly, by passing
> reservations in both reserved-memory and in the EFI memory map, that
> is probably fine.
>
> Also, I must sheepishly admit that I only realize now that this patch
> set is against u-boot not Linux :-)
>
:)

> So if fixed reserved-memory regions are only being used to seed the
> reserved regions in the EFI memory map, you can safely ignore me.

Yeah. That's the purpose. Having reserved memory nodes in the final DT
used by linux
also ensures that proper Linux adds a reserved memory block or removes
it from memblock
entries depending on "no-map" property.

> Apologies for the noise.



-- 
Regards,
Atish