Hi Atish, On Fri, Apr 17, 2020 at 10:14 AM Bin Meng <[email protected]> wrote: > > Correct Palmer's email address > > On Fri, Apr 17, 2020 at 10:12 AM Bin Meng <[email protected]> wrote: > > > > Hi Rick, > > > > On Fri, Apr 17, 2020 at 9:12 AM Rick Chen <[email protected]> wrote: > > > > > > Hi Bin > > > > > > > Hi Rick, > > > > > > > > On Fri, Apr 17, 2020 at 8:51 AM Rick Chen <[email protected]> wrote: > > > > > > > > > > <[email protected]> 於 2020年4月17日 週五 上午8:39寫道： > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Atish Patra [mailto:[email protected]] > > > > > > 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 <[email protected]> wrote: > > > > > > > > > > > > > > Hi Atish, > > > > > > > > > > > > > > On Tue, Apr 14, 2020 at 6:02 AM Atish Patra > > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > On Tue, Apr 7, 2020 at 10:35 AM Atish Patra > > > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > > > On Mon, Apr 6, 2020 at 11:51 PM Ard Biesheuvel > > > > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > > > > > On Tue, 7 Apr 2020 at 08:46, Heinrich Schuchardt > > > > > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > > On 4/6/20 11:01 PM, Ard Biesheuvel wrote: > > > > > > > > > > > > On Mon, 6 Apr 2020 at 22:45, Atish Patra > > > > > > > > > > > > <[email protected]> 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
