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? > 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? > 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? > > > -----Original Message----- > > From: Simon Glass <s...@chromium.org> > > Sent: Tuesday, September 26, 2023 12:43 PM > > To: devicet...@vger.kernel.org > > Cc: 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>; Chiu, Chasel <chasel.c...@intel.com>; linux- > > a...@vger.kernel.org; U-Boot Mailing List <u-boot@lists.denx.de>; Ard > > Biesheuvel <a...@kernel.org>; Simon Glass <s...@chromium.org> > > Subject: [PATCH v7 2/2] schemas: Add some common reserved-memory usages > > > > It is common to split firmware into 'Platform Init', which does the initial > > hardware > > setup and a "Payload" which selects the OS to be booted. > > Thus an handover interface is required between these two pieces. > > > > Where UEFI boot-time services are not available, but UEFI firmware is > > present on > > either side of this interface, information about memory usage and > > attributes must > > be presented to the "Payload" in some form. > > > > This aims to provide an small schema addition for the memory mapping needed > > to keep these two pieces working together well. > > > > Signed-off-by: Simon Glass <s...@chromium.org> > > --- > > > > Changes in v7: > > - Rename acpi-reclaim to acpi > > - Drop individual mention of when memory can be reclaimed > > - Rewrite the item descriptions > > - Add back the UEFI text (with trepidation) > > > > Changes in v6: > > - Drop mention of UEFI > > - Use compatible strings instead of node names > > > > Changes in v5: > > - Drop the memory-map node (should have done that in v4) > > - Tidy up schema a bit > > > > Changes in v4: > > - Make use of the reserved-memory node instead of creating a new one > > > > Changes in v3: > > - Reword commit message again > > - cc a lot more people, from the FFI patch > > - Split out the attributes into the /memory nodes > > > > Changes in v2: > > - Reword commit message > > > > .../reserved-memory/common-reserved.yaml | 71 +++++++++++++++++++ > > 1 file changed, 71 insertions(+) > > create mode 100644 dtschema/schemas/reserved-memory/common- > > reserved.yaml > > > > diff --git a/dtschema/schemas/reserved-memory/common-reserved.yaml > > b/dtschema/schemas/reserved-memory/common-reserved.yaml > > new file mode 100644 > > index 0000000..f7fbdfd > > --- /dev/null > > +++ b/dtschema/schemas/reserved-memory/common-reserved.yaml > > @@ -0,0 +1,71 @@ > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 > > +--- > > +$id: > > +http://devicetree.org/schemas/reserved-memory/common-reserved.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Common memory reservations > > + > > +description: | > > + Specifies that the reserved memory region can be used for the purpose > > + indicated by its compatible string. > > + > > + Clients may reuse this reserved memory if they understand what it is > > + for, subject to the notes below. > > + > > +maintainers: > > + - Simon Glass <s...@chromium.org> > > + > > +allOf: > > + - $ref: reserved-memory.yaml > > + > > +properties: > > + compatible: > > + description: | > > + This describes some common memory reservations, with the compatible > > + string indicating what it is used for: > > + > > + acpi: Advanced Configuration and Power Interface (ACPI) tables > > + acpi-nvs: ACPI Non-Volatile-Sleeping Memory (NVS). This is > > reserved by > > + the firmware for its use and is required to be saved and > > restored > > + across an NVS sleep > > + boot-code: Contains code used for booting which is not needed by > > the OS > > + boot-code: Contains data used for booting which is not needed by > > the OS > > + runtime-code: Contains code used for interacting with the system > > when > > + running the OS > > + runtime-data: Contains data used for interacting with the system > > when > > + running the OS > > + > > + enum: > > + - acpi > > + - acpi-nvs > > + - boot-code > > + - boot-data > > + - runtime-code > > + - runtime-data > > + > > + reg: > > + description: region of memory that is reserved for the purpose > > indicated > > + by the compatible string. > > + > > +required: > > + - reg > > + > > +unevaluatedProperties: false > > + > > +examples: > > + - | > > + reserved-memory { > > + #address-cells = <1>; > > + #size-cells = <1>; > > + > > + reserved@12340000 { > > + compatible = "boot-code"; > > + reg = <0x12340000 0x00800000>; > > + }; > > + > > + reserved@43210000 { > > + compatible = "boot-data"; > > + reg = <0x43210000 0x00800000>; > > + }; > > + }; > > -- > > 2.42.0.515.g380fc7ccd1-goog >
