On Mon, 20 Nov 2023 at 21:12, Simon Glass <s...@chromium.org> wrote: > > Hi, > > On Mon, 13 Nov 2023 at 11:09, Chiu, Chasel <chasel.c...@intel.com> wrote: > > > > > > Hi Ard, > > > > Please see my reply below inline. > > > > Thanks, > > Chasel > > > > > > > -----Original Message----- > > > From: Ard Biesheuvel <a...@kernel.org> > > > Sent: Saturday, November 11, 2023 3:04 AM > > > To: Chiu, Chasel <chasel.c...@intel.com> > > > Cc: Simon Glass <s...@chromium.org>; devicet...@vger.kernel.org; Mark > > > Rutland > > > <mark.rutl...@arm.com>; Rob Herring <r...@kernel.org>; Tan, Lean Sheng > > > <sheng....@9elements.com>; lkml <linux-ker...@vger.kernel.org>; Dhaval > > > Sharma <dha...@rivosinc.com>; Brune, Maximilian > > > <maximilian.br...@9elements.com>; Yunhui Cui <cuiyun...@bytedance.com>; > > > Dong, Guo <guo.d...@intel.com>; Tom Rini <tr...@konsulko.com>; ron minnich > > > <rminn...@gmail.com>; Guo, Gua <gua....@intel.com>; linux- > > > a...@vger.kernel.org; U-Boot Mailing List <u-boot@lists.denx.de> > > > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory > > > usages > > > > > > On Sat, 11 Nov 2023 at 04:20, Chiu, Chasel <chasel.c...@intel.com> wrote: > > > > > > > > > > > > Just sharing some usage examples from UEFI/EDK2 scenario. > > > > To support ACPI S4/Hibernation, memory map must be consistent before > > > > entering and after resuming from S4, in this case payload may need to > > > > know previous memory map from bootloader (currently generic payload > > > > cannot access platform/bootloader specific non-volatile data, thus > > > > could not save/restore memory map information) > > > > > > So how would EDK2 reconstruct the entire EFI memory map from just these > > > unannotated /reserved-memory nodes? The EFI memory map contains much > > > more information than that, and all of it has to match the pre-hibernate > > > situation, > > > right? Can you given an example? > > > > > > Here we listed only typically memory types that may change cross different > > platforms. > > Reserved memory type already can be handled by reserved-memory node, and > > rest of the types usually no need to change cross platforms thus currently > > we could rely on default in generic payload. > > In the future if we see a need to add new memory types we will discuss and > > add it to FDT schema. > > > > > > > > > > > > > Another usage is to support binary model which generic payload is a > > > > prebuilt > > > binary compatible for all platforms/configurations, however the payload > > > default > > > memory map might not always work for all the configurations and we want to > > > allow bootloader to override payload default memory map without > > > recompiling. > > > > > > > > > > Agreed. But can you explain how a EDK2 payload might make meaningful use > > > of > > > 'runtime-code' regions provided via DT by the non-EDK2 platform init? > > > Can you > > > give an example? > > > > > > Runtime-code/data is used by UEFI payload for booting UEFI OS which > > required UEFI runtime services. > > Platform Init will select some regions from the usable memory and assign it > > to runtime-code/data for UPL to consume. Or assign same runtime-code/data > > from previous boot. > > If UEFI OS is not supported, PlatformInit may not need to provide > > runtime-code/data regions to payload. (always providing runtime-code/data > > should be supported too) > > > > > > > > > > > Under below assumption: > > > > FDT OS impact has been evaluated and taken care by relevant > > > experts/stakeholders. > > > > Reviewed-by: Chasel Chiu <chasel.c...@intel.com> > > > > > > > > > > I am sorry but I don't know what 'FDT OS impact' means. We are talking > > > about a > > > firmware-to-firmware abstraction that has the potential to leak into the > > > OS > > > visible interface. > > > > > > I am a maintainer in the Tianocore project myself, so it would help if > > > you could > > > explain who these relevant experts and stakeholders are. Was this > > > discussed on > > > the edk2-devel mailing list? If so, apologies for missing it but I may > > > not have been > > > cc'ed perhaps? > > > > > > > > > > I'm not familiar with FDT OS, also I do not know if who from edk2-devel > > were supporting FDT OS, I think Simon might be able to connect FDT OS > > experts/stakeholders. > > We are mostly focusing on payload firmware phase implementation in edk2 > > (and other payloads too), however, since we have aligned the payload FDT > > and OS FDT months ago, I'm assuming FDT OS impact must be there and we need > > (or already done?) FDT OS experts to support it. (again, maybe Simon could > > share more information about FDT OS) > > > > In edk2 such FDT schema is UefiPayloadPkg internal usage only and payload > > entry will convert FDT into HOB thus we expected the most of the edk2 > > generic code are no-touch/no impact, that's why we only had small group > > (UefiPayloadPkg) discussion. > > Ard, if you are aware of any edk2 code that's for supporting FDT OS, please > > let us know and we can discuss if those code were impacted or not. > > We discussed this and just to clarify, 'FDT OS' is not a special OS, > it is just Linux. > > So, with the above, are we all on the same page? Can the patch be > applied, perhaps? If not, what other discussion is needed? >
An example of how a platform-init/payload combination would make meaningful use of such runtime-code/data regions.
