Re: [PATCH v5 0/6] RISC-V DT related fixes for reserved memory & UEFI
rick@andestech.com 於 2020年4月17日 週五 上午8:39寫道：
-----Original Message----- From: Atish Patra [mailto:atishp@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@gmail.com wrote:
Hi Atish,
On Tue, Apr 14, 2020 at 6:02 AM Atish Patra atishp@atishpatra.org wrote:
On Tue, Apr 7, 2020 at 10:35 AM Atish Patra atishp@atishpatra.org wrote:
On Mon, Apr 6, 2020 at 11:51 PM Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
On Tue, 7 Apr 2020 at 08:46, Heinrich Schuchardt xypron.glpk@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@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.
Thanks, Rick
Hi Rick,
On Fri, Apr 17, 2020 at 8:51 AM Rick Chen rickchen36@gmail.com wrote:
rick@andestech.com 於 2020年4月17日 週五 上午8:39寫道：
-----Original Message----- From: Atish Patra [mailto:atishp@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@gmail.com wrote:
Hi Atish,
On Tue, Apr 14, 2020 at 6:02 AM Atish Patra atishp@atishpatra.org wrote:
On Tue, Apr 7, 2020 at 10:35 AM Atish Patra atishp@atishpatra.org wrote:
On Mon, Apr 6, 2020 at 11:51 PM Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
On Tue, 7 Apr 2020 at 08:46, Heinrich Schuchardt xypron.glpk@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@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.
Regards, Bin
Hi Bin
Hi Rick,
On Fri, Apr 17, 2020 at 8:51 AM Rick Chen rickchen36@gmail.com wrote:
rick@andestech.com 於 2020年4月17日 週五 上午8:39寫道：
-----Original Message----- From: Atish Patra [mailto:atishp@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@gmail.com wrote:
Hi Atish,
On Tue, Apr 14, 2020 at 6:02 AM Atish Patra atishp@atishpatra.org wrote:
On Tue, Apr 7, 2020 at 10:35 AM Atish Patra atishp@atishpatra.org wrote:
On Mon, Apr 6, 2020 at 11:51 PM Ard Biesheuvel ard.biesheuvel@linaro.org wrote: > > On Tue, 7 Apr 2020 at 08:46, Heinrich Schuchardt xypron.glpk@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@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 :)
Thanks, Rick
Regards, Bin
Hi Rick,
On Fri, Apr 17, 2020 at 9:12 AM Rick Chen rickchen36@gmail.com wrote:
Hi Bin
Hi Rick,
On Fri, Apr 17, 2020 at 8:51 AM Rick Chen rickchen36@gmail.com wrote:
rick@andestech.com 於 2020年4月17日 週五 上午8:39寫道：
-----Original Message----- From: Atish Patra [mailto:atishp@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@gmail.com wrote:
Hi Atish,
On Tue, Apr 14, 2020 at 6:02 AM Atish Patra atishp@atishpatra.org wrote:
On Tue, Apr 7, 2020 at 10:35 AM Atish Patra atishp@atishpatra.org wrote: > > On Mon, Apr 6, 2020 at 11:51 PM Ard Biesheuvel > ard.biesheuvel@linaro.org wrote: > > > > On Tue, 7 Apr 2020 at 08:46, Heinrich Schuchardt xypron.glpk@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@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?
Regards, Bin
Correct Palmer's email address
On Fri, Apr 17, 2020 at 10:12 AM Bin Meng bmeng.cn@gmail.com wrote:
Hi Rick,
On Fri, Apr 17, 2020 at 9:12 AM Rick Chen rickchen36@gmail.com wrote:
Hi Bin
Hi Rick,
On Fri, Apr 17, 2020 at 8:51 AM Rick Chen rickchen36@gmail.com wrote:
rick@andestech.com 於 2020年4月17日 週五 上午8:39寫道：
-----Original Message----- From: Atish Patra [mailto:atishp@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@gmail.com wrote:
Hi Atish,
On Tue, Apr 14, 2020 at 6:02 AM Atish Patra atishp@atishpatra.org wrote: > > On Tue, Apr 7, 2020 at 10:35 AM Atish Patra atishp@atishpatra.org wrote: > > > > On Mon, Apr 6, 2020 at 11:51 PM Ard Biesheuvel > > ard.biesheuvel@linaro.org wrote: > > > > > > On Tue, 7 Apr 2020 at 08:46, Heinrich Schuchardt xypron.glpk@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@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
Regards, Bin
Hi Atish,
On Fri, Apr 17, 2020 at 10:14 AM Bin Meng bmeng.cn@gmail.com wrote:
Correct Palmer's email address
On Fri, Apr 17, 2020 at 10:12 AM Bin Meng bmeng.cn@gmail.com wrote:
Hi Rick,
On Fri, Apr 17, 2020 at 9:12 AM Rick Chen rickchen36@gmail.com wrote:
Hi Bin
Hi Rick,
On Fri, Apr 17, 2020 at 8:51 AM Rick Chen rickchen36@gmail.com wrote:
rick@andestech.com 於 2020年4月17日 週五 上午8:39寫道：
-----Original Message----- From: Atish Patra [mailto:atishp@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@gmail.com wrote: > > Hi Atish, > > On Tue, Apr 14, 2020 at 6:02 AM Atish Patra atishp@atishpatra.org wrote: > > > > On Tue, Apr 7, 2020 at 10:35 AM Atish Patra atishp@atishpatra.org wrote: > > > > > > On Mon, Apr 6, 2020 at 11:51 PM Ard Biesheuvel > > > ard.biesheuvel@linaro.org wrote: > > > > > > > > On Tue, 7 Apr 2020 at 08:46, Heinrich Schuchardt xypron.glpk@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@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
On Thu, Apr 16, 2020 at 7:27 PM Bin Meng bmeng.cn@gmail.com wrote:
Hi Atish,
On Fri, Apr 17, 2020 at 10:14 AM Bin Meng bmeng.cn@gmail.com wrote:
Correct Palmer's email address
On Fri, Apr 17, 2020 at 10:12 AM Bin Meng bmeng.cn@gmail.com wrote:
Hi Rick,
On Fri, Apr 17, 2020 at 9:12 AM Rick Chen rickchen36@gmail.com wrote:
Hi Bin
Hi Rick,
On Fri, Apr 17, 2020 at 8:51 AM Rick Chen rickchen36@gmail.com wrote:
rick@andestech.com 於 2020年4月17日 週五 上午8:39寫道： > > > > -----Original Message----- > From: Atish Patra [mailto:atishp@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@gmail.com wrote: > > > > Hi Atish, > > > > On Tue, Apr 14, 2020 at 6:02 AM Atish Patra atishp@atishpatra.org wrote: > > > > > > On Tue, Apr 7, 2020 at 10:35 AM Atish Patra atishp@atishpatra.org wrote: > > > > > > > > On Mon, Apr 6, 2020 at 11:51 PM Ard Biesheuvel > > > > ard.biesheuvel@linaro.org wrote: > > > > > > > > > > On Tue, 7 Apr 2020 at 08:46, Heinrich Schuchardt xypron.glpk@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@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
participants (3)
-
Atish Patra -
Bin Meng -
Rick Chen