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

[Atish Patra]

On Thu, Apr 16, 2020 at 7:27 PM Bin Meng <bmeng.cn at gmail.com> wrote:
>
> 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.
>

Strange. Not sure how did it happened.
> Could you please resend the v5 of this series?
>

Done. I have resent the series. Thanks for taking a look.

> Regards,
> Bin



-- 
Regards,
Atish