From mboxrd@z Thu Jan 1 00:00:00 1970 From: Atish Patra Date: Tue, 14 Apr 2020 16:18:15 -0700 Subject: [PATCH v5 0/6] RISC-V DT related fixes for reserved memory & UEFI In-Reply-To: References: <20200406204453.231945-1-atish.patra@wdc.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Mon, Apr 13, 2020 at 3:42 PM Bin Meng wrote: > > Hi Atish, > > On Tue, Apr 14, 2020 at 6:02 AM Atish Patra wrote: > > > > On Tue, Apr 7, 2020 at 10:35 AM Atish Patra wrote: > > > > > > On Mon, Apr 6, 2020 at 11:51 PM Ard Biesheuvel > > > wrote: > > > > > > > > On Tue, 7 Apr 2020 at 08:46, Heinrich Schuchardt wrote: > > > > > > > > > > On 4/6/20 11:01 PM, Ard Biesheuvel wrote: > > > > > > On Mon, 6 Apr 2020 at 22:45, Atish Patra 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. > Regards, > Bin -- Regards, Atish