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

[Bin Meng]

Hi Atish,

On Fri, Apr 17, 2020 at 10:14 AM Bin Meng <bmeng.cn at gmail.com> wrote:
>
> Correct Palmer's email address
>
> On Fri, Apr 17, 2020 at 10:12 AM Bin Meng <bmeng.cn at gmail.com> wrote:
> >
> > Hi Rick,
> >
> > On Fri, Apr 17, 2020 at 9:12 AM Rick Chen <rickchen36 at gmail.com> wrote:
> > >
> > > Hi Bin
> > >
> > > > Hi Rick,
> > > >
> > > > On Fri, Apr 17, 2020 at 8:51 AM Rick Chen <rickchen36 at gmail.com> wrote:
> > > > >
> > > > > <rick at andestech.com> 於 2020年4月17日 週五 上午8:39寫道：
> > > > > >
> > > > > >
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Atish Patra [mailto:atishp at atishpatra.org]
> > > > > > Sent: Wednesday, April 15, 2020 7:18 AM
> > > > > > To: Bin Meng
> > > > > > Cc: Ard Biesheuvel; Heinrich Schuchardt; U-Boot Mailing List; Anup Patel; Lukas Auer; Alexander Graf; Rick Jian-Zhi Chen(陳建志); Palmer Dabbelt
> > > > > > Subject: Re: [PATCH v5 0/6] RISC-V DT related fixes for reserved memory & UEFI
> > > > > >
> > > > > > On Mon, Apr 13, 2020 at 3:42 PM Bin Meng <bmeng.cn at gmail.com> wrote:
> > > > > > >
> > > > > > > Hi Atish,
> > > > > > >
> > > > > > > On Tue, Apr 14, 2020 at 6:02 AM Atish Patra <atishp at atishpatra.org> wrote:
> > > > > > > >
> > > > > > > > On Tue, Apr 7, 2020 at 10:35 AM Atish Patra <atishp at atishpatra.org> wrote:
> > > > > > > > >
> > > > > > > > > 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
> > > > > > > >
> > > > > > > > Any other comments on the series ? It would be great if this series
> > > > > > > > could be merged before
> > > > > > > > v2020.07 release.
> > > > > > >
> > > > > > > I hope so if no one objects the proposed solution here in U-Boot vs.
> > > > > > > the PMP SBI extension. I need have another look at the latest version
> > > > > > > of patches though.
> > > > > > >
> > > > > >
> > > > > > Thanks. As far as I know, there is no opposition to the current approach adopted in U-Boot.
> > > > > > I am hoping EFI stub series can be merged before 5.8. If this series can go in v2020.07, RISC-V will have all required support to boot via EFI from Linux kernel v5.8 and U-Boot v2020.07.
> > > > >
> > > > > OK!
> > > > > I will pull and send a PR ASAP.
> > > >
> > > > I will need have a look and test today. Please wait for some time.
> > > >
> > >
> > > OK
> > > No problem :)
> >
> > Do you know what happened to this series?
> >
> > I only see patch 3, 5, 6 showing up on the patchwork. Are other
> > patches already applied somewhere?
>
> I am referring to http://patchwork.ozlabs.org/project/uboot/list/?series=168858

I checked on patchwork, and the mailing list archive. It looks to me
that the other patches did not arrive on the mailing list and both
patchwork and the archive did not see them.

Could you please resend the v5 of this series?

Regards,
Bin