Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Ard Biesheuvel]

On Thu, 4 Jan 2024 at 18:53, Chiu, Chasel  wrote:
>
>
>
> > -Original Message-
> > From: Ard Biesheuvel 
> > Sent: Thursday, January 4, 2024 12:43 AM
> > To: Chiu, Chasel 
> > Cc: Simon Glass ; devicet...@vger.kernel.org; Mark 
> > Rutland
> > ; Rob Herring ; Tan, Lean Sheng
> > ; lkml ; Dhaval
> > Sharma ; Brune, Maximilian
> > ; Yunhui Cui ;
> > Dong, Guo ; Tom Rini ; ron minnich
> > ; Guo, Gua ; linux-
> > a...@vger.kernel.org; U-Boot Mailing List 
> > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory
> > usages
> >
> > On Thu, 4 Jan 2024 at 01:25, Chiu, Chasel  wrote:
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Ard Biesheuvel 
> > > > Sent: Wednesday, January 3, 2024 7:22 AM
> > > > To: Chiu, Chasel 
> > > > Cc: Simon Glass ; devicet...@vger.kernel.org; Mark
> > > > Rutland ; Rob Herring ; Tan,
> > > > Lean Sheng ; lkml
> > > > ; Dhaval Sharma ;
> > > > Brune, Maximilian ; Yunhui Cui
> > > > ; Dong, Guo ; Tom Rini
> > > > ; ron minnich ; Guo, Gua
> > > > ; linux- a...@vger.kernel.org; U-Boot Mailing
> > > > List 
> > > > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory
> > > > usages
> > > >
> > > > On Fri, 22 Dec 2023 at 20:52, Chiu, Chasel  
> > > > wrote:
> > > > >
> > > > >
> > > > > Please see my reply below inline.
> > > > >
> > > > > Thanks,
> > > > > Chasel
> > > > >
> > > > ...
> > > > > > > > The gEfiMemoryTypeInformationGuid HOB typically carries
> > > > > > > > platform defaults, and the actual memory type information is
> > > > > > > > kept in a non-volatile EFI variable, which gets updated when
> > > > > > > > the memory usage changes. Is this different for UefiPayloadPkg?
> > > > > > > >
> > > > > > > > (For those among the cc'ees less versed in EFI/EDK2: when
> > > > > > > > you get the 'config changed -rebooting' message from the
> > > > > > > > boot firmware, it typically means that this memory type
> > > > > > > > table has changed, and a reboot is necessary.)
> > > > > > > >
> > > > > > > > So the platform init needs to read this variable, or get the
> > > > > > > > information in a different way. I assume it is the payload,
> > > > > > > > not the platform init that updates the variable when
> > > > > > > > necessary. This means the information flows from payload(n)
> > > > > > > > to platform init(n+1), where n is a monotonic index tracking
> > > > > > > > consecutive boots of the
> > > > system.
> > > > > > > >
> > > > > > > > Can you explain how the DT fits into this? How are the
> > > > > > > > runtime-code and runtime-data memory reservation nodes under
> > > > > > > > /reserved-memory used to implement this information exchange
> > > > > > > > between platform init and payload? And how do the HOB and
> > > > > > > > the EFI
> > > > variable fit into this picture?
> > > > > > >
> > > > > > >
> > > > > > > 1. With some offline discussion, we would move
> > > > > > > gEfiMemoryTypeInformationGuid usage to FDT->upl-custom node.
> > > > > > > This is because it is edk2 implementation choice and non-edk2
> > > > > > > PlatformInit or Payload may not have such memory optimization
> > > > > > > implementation. (not a generic usage/requirement for
> > > > > > > PlatformInit and Payload)
> > > > > > >
> > > > > > > The edk2 example flow will be like below:
> > > > > > >
> > > > > > > PlatformInit to GetVariable of gEfiMemoryTypeInformationGuid
> > > > > > > and create Hob-
> > > > > > >
> > > > > > >   PlatformInit to initialize FDT->upl-custom node to report
> > > > > > gEfiMemoryTypeInformationGuid HOB information ->
> > > > > > > UefiPayload entry t

RE: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Chiu, Chasel]

> -Original Message-
> From: Ard Biesheuvel 
> Sent: Thursday, January 4, 2024 12:43 AM
> To: Chiu, Chasel 
> Cc: Simon Glass ; devicet...@vger.kernel.org; Mark Rutland
> ; Rob Herring ; Tan, Lean Sheng
> ; lkml ; Dhaval
> Sharma ; Brune, Maximilian
> ; Yunhui Cui ;
> Dong, Guo ; Tom Rini ; ron minnich
> ; Guo, Gua ; linux-
> a...@vger.kernel.org; U-Boot Mailing List 
> Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory
> usages
> 
> On Thu, 4 Jan 2024 at 01:25, Chiu, Chasel  wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Ard Biesheuvel 
> > > Sent: Wednesday, January 3, 2024 7:22 AM
> > > To: Chiu, Chasel 
> > > Cc: Simon Glass ; devicet...@vger.kernel.org; Mark
> > > Rutland ; Rob Herring ; Tan,
> > > Lean Sheng ; lkml
> > > ; Dhaval Sharma ;
> > > Brune, Maximilian ; Yunhui Cui
> > > ; Dong, Guo ; Tom Rini
> > > ; ron minnich ; Guo, Gua
> > > ; linux- a...@vger.kernel.org; U-Boot Mailing
> > > List 
> > > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory
> > > usages
> > >
> > > On Fri, 22 Dec 2023 at 20:52, Chiu, Chasel  wrote:
> > > >
> > > >
> > > > Please see my reply below inline.
> > > >
> > > > Thanks,
> > > > Chasel
> > > >
> > > ...
> > > > > > > The gEfiMemoryTypeInformationGuid HOB typically carries
> > > > > > > platform defaults, and the actual memory type information is
> > > > > > > kept in a non-volatile EFI variable, which gets updated when
> > > > > > > the memory usage changes. Is this different for UefiPayloadPkg?
> > > > > > >
> > > > > > > (For those among the cc'ees less versed in EFI/EDK2: when
> > > > > > > you get the 'config changed -rebooting' message from the
> > > > > > > boot firmware, it typically means that this memory type
> > > > > > > table has changed, and a reboot is necessary.)
> > > > > > >
> > > > > > > So the platform init needs to read this variable, or get the
> > > > > > > information in a different way. I assume it is the payload,
> > > > > > > not the platform init that updates the variable when
> > > > > > > necessary. This means the information flows from payload(n)
> > > > > > > to platform init(n+1), where n is a monotonic index tracking
> > > > > > > consecutive boots of the
> > > system.
> > > > > > >
> > > > > > > Can you explain how the DT fits into this? How are the
> > > > > > > runtime-code and runtime-data memory reservation nodes under
> > > > > > > /reserved-memory used to implement this information exchange
> > > > > > > between platform init and payload? And how do the HOB and
> > > > > > > the EFI
> > > variable fit into this picture?
> > > > > >
> > > > > >
> > > > > > 1. With some offline discussion, we would move
> > > > > > gEfiMemoryTypeInformationGuid usage to FDT->upl-custom node.
> > > > > > This is because it is edk2 implementation choice and non-edk2
> > > > > > PlatformInit or Payload may not have such memory optimization
> > > > > > implementation. (not a generic usage/requirement for
> > > > > > PlatformInit and Payload)
> > > > > >
> > > > > > The edk2 example flow will be like below:
> > > > > >
> > > > > > PlatformInit to GetVariable of gEfiMemoryTypeInformationGuid
> > > > > > and create Hob-
> > > > > >
> > > > > >   PlatformInit to initialize FDT->upl-custom node to report
> > > > > gEfiMemoryTypeInformationGuid HOB information ->
> > > > > > UefiPayload entry to re-create
> > > > > > gEfiMemoryTypeInformationGuid HOB basing
> > > > > on FDT input (instead of the default MemoryType inside
> > > > > UefiPayload)
> > > > > ->
> > > > > >   UefiPayload DxeMain/Gcd will consume
> > > > > > gEfiMemoryTypeInformationGuid
> > > > > Hob for memory type information ->
> > > > > > UefiPayload to initialize UEFI environment (ma

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Ard Biesheuvel]

On Thu, 4 Jan 2024 at 01:25, Chiu, Chasel  wrote:
>
>
>
> > -Original Message-
> > From: Ard Biesheuvel 
> > Sent: Wednesday, January 3, 2024 7:22 AM
> > To: Chiu, Chasel 
> > Cc: Simon Glass ; devicet...@vger.kernel.org; Mark 
> > Rutland
> > ; Rob Herring ; Tan, Lean Sheng
> > ; lkml ; Dhaval
> > Sharma ; Brune, Maximilian
> > ; Yunhui Cui ;
> > Dong, Guo ; Tom Rini ; ron minnich
> > ; Guo, Gua ; linux-
> > a...@vger.kernel.org; U-Boot Mailing List 
> > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory
> > usages
> >
> > On Fri, 22 Dec 2023 at 20:52, Chiu, Chasel  wrote:
> > >
> > >
> > > Please see my reply below inline.
> > >
> > > Thanks,
> > > Chasel
> > >
> > ...
> > > > > > The gEfiMemoryTypeInformationGuid HOB typically carries platform
> > > > > > defaults, and the actual memory type information is kept in a
> > > > > > non-volatile EFI variable, which gets updated when the memory
> > > > > > usage changes. Is this different for UefiPayloadPkg?
> > > > > >
> > > > > > (For those among the cc'ees less versed in EFI/EDK2: when you
> > > > > > get the 'config changed -rebooting' message from the boot
> > > > > > firmware, it typically means that this memory type table has
> > > > > > changed, and a reboot is necessary.)
> > > > > >
> > > > > > So the platform init needs to read this variable, or get the
> > > > > > information in a different way. I assume it is the payload, not
> > > > > > the platform init that updates the variable when necessary. This
> > > > > > means the information flows from payload(n) to platform
> > > > > > init(n+1), where n is a monotonic index tracking consecutive boots 
> > > > > > of the
> > system.
> > > > > >
> > > > > > Can you explain how the DT fits into this? How are the
> > > > > > runtime-code and runtime-data memory reservation nodes under
> > > > > > /reserved-memory used to implement this information exchange
> > > > > > between platform init and payload? And how do the HOB and the EFI
> > variable fit into this picture?
> > > > >
> > > > >
> > > > > 1. With some offline discussion, we would move
> > > > > gEfiMemoryTypeInformationGuid usage to FDT->upl-custom node. This
> > > > > is because it is edk2 implementation choice and non-edk2
> > > > > PlatformInit or Payload may not have such memory optimization
> > > > > implementation. (not a generic usage/requirement for PlatformInit
> > > > > and Payload)
> > > > >
> > > > > The edk2 example flow will be like below:
> > > > >
> > > > > PlatformInit to GetVariable of gEfiMemoryTypeInformationGuid and
> > > > > create Hob-
> > > > >
> > > > >   PlatformInit to initialize FDT->upl-custom node to report
> > > > gEfiMemoryTypeInformationGuid HOB information ->
> > > > > UefiPayload entry to re-create gEfiMemoryTypeInformationGuid
> > > > > HOB basing
> > > > on FDT input (instead of the default MemoryType inside UefiPayload)
> > > > ->
> > > > >   UefiPayload DxeMain/Gcd will consume
> > > > > gEfiMemoryTypeInformationGuid
> > > > Hob for memory type information ->
> > > > > UefiPayload to initialize UEFI environment (mainly DXE 
> > > > > dispatcher) ->
> > > > >   (additional FV binary appended to common UefiPayload
> > > > > binary)
> > > > PlatformPayload to provide VariableService which is platform
> > > > specific ->
> > > > > UefiPayload UefiBootManager will SetVariable if memory
> > > > > type change
> > > > needed and request a warm reset ->
> > > > >   Back to PlatformInit ...
> > > > >
> > > >
> > > > OK so the upl-custom node can do whatever it needs to. I imagine
> > > > these will include the memory descriptor attribute field, and other
> > > > parts that may be missing from the /reserved-memory DT node 
> > > > specification?
> > >
> > >
> > > Yes, if neede

RE: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Chiu, Chasel]

> -Original Message-
> From: Ard Biesheuvel 
> Sent: Wednesday, January 3, 2024 7:22 AM
> To: Chiu, Chasel 
> Cc: Simon Glass ; devicet...@vger.kernel.org; Mark Rutland
> ; Rob Herring ; Tan, Lean Sheng
> ; lkml ; Dhaval
> Sharma ; Brune, Maximilian
> ; Yunhui Cui ;
> Dong, Guo ; Tom Rini ; ron minnich
> ; Guo, Gua ; linux-
> a...@vger.kernel.org; U-Boot Mailing List 
> Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory
> usages
> 
> On Fri, 22 Dec 2023 at 20:52, Chiu, Chasel  wrote:
> >
> >
> > Please see my reply below inline.
> >
> > Thanks,
> > Chasel
> >
> ...
> > > > > The gEfiMemoryTypeInformationGuid HOB typically carries platform
> > > > > defaults, and the actual memory type information is kept in a
> > > > > non-volatile EFI variable, which gets updated when the memory
> > > > > usage changes. Is this different for UefiPayloadPkg?
> > > > >
> > > > > (For those among the cc'ees less versed in EFI/EDK2: when you
> > > > > get the 'config changed -rebooting' message from the boot
> > > > > firmware, it typically means that this memory type table has
> > > > > changed, and a reboot is necessary.)
> > > > >
> > > > > So the platform init needs to read this variable, or get the
> > > > > information in a different way. I assume it is the payload, not
> > > > > the platform init that updates the variable when necessary. This
> > > > > means the information flows from payload(n) to platform
> > > > > init(n+1), where n is a monotonic index tracking consecutive boots of 
> > > > > the
> system.
> > > > >
> > > > > Can you explain how the DT fits into this? How are the
> > > > > runtime-code and runtime-data memory reservation nodes under
> > > > > /reserved-memory used to implement this information exchange
> > > > > between platform init and payload? And how do the HOB and the EFI
> variable fit into this picture?
> > > >
> > > >
> > > > 1. With some offline discussion, we would move
> > > > gEfiMemoryTypeInformationGuid usage to FDT->upl-custom node. This
> > > > is because it is edk2 implementation choice and non-edk2
> > > > PlatformInit or Payload may not have such memory optimization
> > > > implementation. (not a generic usage/requirement for PlatformInit
> > > > and Payload)
> > > >
> > > > The edk2 example flow will be like below:
> > > >
> > > > PlatformInit to GetVariable of gEfiMemoryTypeInformationGuid and
> > > > create Hob-
> > > >
> > > >   PlatformInit to initialize FDT->upl-custom node to report
> > > gEfiMemoryTypeInformationGuid HOB information ->
> > > > UefiPayload entry to re-create gEfiMemoryTypeInformationGuid
> > > > HOB basing
> > > on FDT input (instead of the default MemoryType inside UefiPayload)
> > > ->
> > > >   UefiPayload DxeMain/Gcd will consume
> > > > gEfiMemoryTypeInformationGuid
> > > Hob for memory type information ->
> > > > UefiPayload to initialize UEFI environment (mainly DXE 
> > > > dispatcher) ->
> > > >   (additional FV binary appended to common UefiPayload
> > > > binary)
> > > PlatformPayload to provide VariableService which is platform
> > > specific ->
> > > > UefiPayload UefiBootManager will SetVariable if memory
> > > > type change
> > > needed and request a warm reset ->
> > > >   Back to PlatformInit ...
> > > >
> > >
> > > OK so the upl-custom node can do whatever it needs to. I imagine
> > > these will include the memory descriptor attribute field, and other
> > > parts that may be missing from the /reserved-memory DT node specification?
> >
> >
> > Yes, if needed by edk2 specific implementation, not generic enough, we may
> consider to use upl-custom node to pass those data.
> >
> >
> > >
> > > >
> > > > 2. Now the proposed reserved-memory node usages will be for
> > > > PlatformInit to
> > > provide data which may be used by Payload or OS. This is not edk2
> > > specific and any PlatformInit/Payload could have same support.
> > > > Note: all of below are optional and PlatformInit may choose to
> > 

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Simon Glass]

Hi Rob, Ard,

On Wed, Jan 3, 2024 at 9:01 AM Rob Herring  wrote:
>
> On Fri, Dec 22, 2023 at 5:48 AM Ard Biesheuvel  wrote:
> >
> > On Thu, 21 Dec 2023 at 17:50, Chiu, Chasel  wrote:
> > >
> > >
> > > Hi Ard,
> > >
> > > Please see my reply below inline and let me know your thoughts.
> > >
> > > Thanks,
> > > Chasel
> > >
> > >
> > > > -Original Message-
> > > > From: Ard Biesheuvel 
> > > > Sent: Thursday, December 21, 2023 6:31 AM
> > > > To: Chiu, Chasel 
> > > > Cc: Simon Glass ; devicet...@vger.kernel.org; Mark 
> > > > Rutland
> > > > ; Rob Herring ; Tan, Lean Sheng
> > > > ; lkml ; Dhaval
> > > > Sharma ; Brune, Maximilian
> > > > ; Yunhui Cui ;
> > > > Dong, Guo ; Tom Rini ; ron 
> > > > minnich
> > > > ; Guo, Gua ; linux-
> > > > a...@vger.kernel.org; U-Boot Mailing List 
> > > > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory
> > > > usages
> > > >
> > > > On Tue, 28 Nov 2023 at 21:31, Chiu, Chasel  
> > > > wrote:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: Ard Biesheuvel 
> > > > > > Sent: Tuesday, November 28, 2023 10:08 AM
> > > > > > To: Chiu, Chasel 
> > > > > > Cc: Simon Glass ; devicet...@vger.kernel.org; 
> > > > > > Mark
> > > > > > Rutland ; Rob Herring ; Tan,
> > > > > > Lean Sheng ; lkml
> > > > > > ; Dhaval Sharma ;
> > > > > > Brune, Maximilian ; Yunhui Cui
> > > > > > ; Dong, Guo ; Tom Rini
> > > > > > ; ron minnich ; Guo, Gua
> > > > > > ; linux- a...@vger.kernel.org; U-Boot Mailing
> > > > > > List 
> > > > > > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory
> > > > > > usages
> > > > > >
> > > > > > You are referring to a 2000 line patch so it is not 100% clear 
> > > > > > where to look tbh.
> > > > > >
> > > > > >
> > > > > > On Tue, 21 Nov 2023 at 19:37, Chiu, Chasel  
> > > > > > wrote:
> > > > > > >
> > > > > > >
> > > > > > > In PR, UefiPayloadPkg/Library/FdtParserLib/FdtParserLib.c, line
> > > > > > > 268 is for
> > > > > > related example code.
> > > > > > >
> > > > > >
> > > > > > That refers to a 'memory-allocation' node, right? How does that
> > > > > > relate to the 'reserved-memory' node?
> > > > > >
> > > > > > And crucially, how does this clarify in which way "runtime-code" and
> > > > > > "runtime- data" reservations are being used?
> > > > > >
> > > > > > Since the very beginning of this discussion, I have been asking
> > > > > > repeatedly for examples that describe the wider context in which 
> > > > > > these
> > > > reservations are used.
> > > > > > The "runtime" into runtime-code and runtime-data means that these
> > > > > > regions have a special significance to the operating system, not
> > > > > > just to the next bootloader stage. So I want to understand exactly
> > > > > > why it is necessary to describe these regions in a way where the
> > > > > > operating system might be expected to interpret this information 
> > > > > > and act
> > > > upon it.
> > > > > >
> > > > >
> > > > >
> > > > > I think runtime code and data today are mainly for supporting UEFI 
> > > > > runtime
> > > > services - some BIOS functions for OS to utilize, OS may follow below 
> > > > ACPI spec to
> > > > treat them as reserved range:
> > > > > https://uefi.org/specs/ACPI/6.5/15_System_Address_Map_Interfaces.html#
> > > > > uefi-memory-types-and-mapping-to-acpi-address-range-types
> > > > >
> > > > > Like I mentioned earlier, that PR is still in early phase and has not 
> > > > > reflected all
&g

RE: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Chiu, Chasel]

> -Original Message-
> From: Rob Herring 
> Sent: Wednesday, January 3, 2024 8:01 AM
> To: Ard Biesheuvel 
> Cc: Chiu, Chasel ; Simon Glass ;
> devicet...@vger.kernel.org; Mark Rutland ; Tan, Lean
> Sheng ; lkml ;
> Dhaval Sharma ; Brune, Maximilian
> ; Yunhui Cui ;
> Dong, Guo ; Tom Rini ; ron minnich
> ; Guo, Gua ; linux-
> a...@vger.kernel.org; U-Boot Mailing List 
> Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory
> usages
> 
> On Fri, Dec 22, 2023 at 5:48 AM Ard Biesheuvel  wrote:
> >
> > On Thu, 21 Dec 2023 at 17:50, Chiu, Chasel  wrote:
> > >
> > >
> > > Hi Ard,
> > >
> > > Please see my reply below inline and let me know your thoughts.
> > >
> > > Thanks,
> > > Chasel
> > >
> > >
> > > > -Original Message-
> > > > From: Ard Biesheuvel 
> > > > Sent: Thursday, December 21, 2023 6:31 AM
> > > > To: Chiu, Chasel 
> > > > Cc: Simon Glass ; devicet...@vger.kernel.org;
> > > > Mark Rutland ; Rob Herring
> > > > ; Tan, Lean Sheng ; lkml
> > > > ; Dhaval Sharma
> > > > ; Brune, Maximilian
> > > > ; Yunhui Cui
> > > > ; Dong, Guo ; Tom
> > > > Rini ; ron minnich ; Guo,
> > > > Gua ; linux- a...@vger.kernel.org; U-Boot
> > > > Mailing List 
> > > > Subject: Re: [PATCH v7 2/2] schemas: Add some common
> > > > reserved-memory usages
> > > >
> > > > On Tue, 28 Nov 2023 at 21:31, Chiu, Chasel  
> > > > wrote:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: Ard Biesheuvel 
> > > > > > Sent: Tuesday, November 28, 2023 10:08 AM
> > > > > > To: Chiu, Chasel 
> > > > > > Cc: Simon Glass ;
> > > > > > devicet...@vger.kernel.org; Mark Rutland
> > > > > > ; Rob Herring ; Tan,
> > > > > > Lean Sheng ; lkml
> > > > > > ; Dhaval Sharma
> > > > > > ; Brune, Maximilian
> > > > > > ; Yunhui Cui
> > > > > > ; Dong, Guo ; Tom
> > > > > > Rini ; ron minnich ;
> > > > > > Guo, Gua ; linux- a...@vger.kernel.org;
> > > > > > U-Boot Mailing List 
> > > > > > Subject: Re: [PATCH v7 2/2] schemas: Add some common
> > > > > > reserved-memory usages
> > > > > >
> > > > > > You are referring to a 2000 line patch so it is not 100% clear 
> > > > > > where to
> look tbh.
> > > > > >
> > > > > >
> > > > > > On Tue, 21 Nov 2023 at 19:37, Chiu, Chasel 
> wrote:
> > > > > > >
> > > > > > >
> > > > > > > In PR, UefiPayloadPkg/Library/FdtParserLib/FdtParserLib.c,
> > > > > > > line
> > > > > > > 268 is for
> > > > > > related example code.
> > > > > > >
> > > > > >
> > > > > > That refers to a 'memory-allocation' node, right? How does
> > > > > > that relate to the 'reserved-memory' node?
> > > > > >
> > > > > > And crucially, how does this clarify in which way
> > > > > > "runtime-code" and
> > > > > > "runtime- data" reservations are being used?
> > > > > >
> > > > > > Since the very beginning of this discussion, I have been
> > > > > > asking repeatedly for examples that describe the wider context
> > > > > > in which these
> > > > reservations are used.
> > > > > > The "runtime" into runtime-code and runtime-data means that
> > > > > > these regions have a special significance to the operating
> > > > > > system, not just to the next bootloader stage. So I want to
> > > > > > understand exactly why it is necessary to describe these
> > > > > > regions in a way where the operating system might be expected
> > > > > > to interpret this information and act
> > > > upon it.
> > > > > >
> > > > >
> > > > >
> > > > > I think runtime code and data today are mainly for supporting
> > > > > UEFI runtime
> > > > services - some BIOS func

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Rob Herring]

On Fri, Dec 22, 2023 at 5:48 AM Ard Biesheuvel  wrote:
>
> On Thu, 21 Dec 2023 at 17:50, Chiu, Chasel  wrote:
> >
> >
> > Hi Ard,
> >
> > Please see my reply below inline and let me know your thoughts.
> >
> > Thanks,
> > Chasel
> >
> >
> > > -Original Message-
> > > From: Ard Biesheuvel 
> > > Sent: Thursday, December 21, 2023 6:31 AM
> > > To: Chiu, Chasel 
> > > Cc: Simon Glass ; devicet...@vger.kernel.org; Mark 
> > > Rutland
> > > ; Rob Herring ; Tan, Lean Sheng
> > > ; lkml ; Dhaval
> > > Sharma ; Brune, Maximilian
> > > ; Yunhui Cui ;
> > > Dong, Guo ; Tom Rini ; ron minnich
> > > ; Guo, Gua ; linux-
> > > a...@vger.kernel.org; U-Boot Mailing List 
> > > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory
> > > usages
> > >
> > > On Tue, 28 Nov 2023 at 21:31, Chiu, Chasel  wrote:
> > > >
> > > >
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Ard Biesheuvel 
> > > > > Sent: Tuesday, November 28, 2023 10:08 AM
> > > > > To: Chiu, Chasel 
> > > > > Cc: Simon Glass ; devicet...@vger.kernel.org; Mark
> > > > > Rutland ; Rob Herring ; Tan,
> > > > > Lean Sheng ; lkml
> > > > > ; Dhaval Sharma ;
> > > > > Brune, Maximilian ; Yunhui Cui
> > > > > ; Dong, Guo ; Tom Rini
> > > > > ; ron minnich ; Guo, Gua
> > > > > ; linux- a...@vger.kernel.org; U-Boot Mailing
> > > > > List 
> > > > > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory
> > > > > usages
> > > > >
> > > > > You are referring to a 2000 line patch so it is not 100% clear where 
> > > > > to look tbh.
> > > > >
> > > > >
> > > > > On Tue, 21 Nov 2023 at 19:37, Chiu, Chasel  
> > > > > wrote:
> > > > > >
> > > > > >
> > > > > > In PR, UefiPayloadPkg/Library/FdtParserLib/FdtParserLib.c, line
> > > > > > 268 is for
> > > > > related example code.
> > > > > >
> > > > >
> > > > > That refers to a 'memory-allocation' node, right? How does that
> > > > > relate to the 'reserved-memory' node?
> > > > >
> > > > > And crucially, how does this clarify in which way "runtime-code" and
> > > > > "runtime- data" reservations are being used?
> > > > >
> > > > > Since the very beginning of this discussion, I have been asking
> > > > > repeatedly for examples that describe the wider context in which these
> > > reservations are used.
> > > > > The "runtime" into runtime-code and runtime-data means that these
> > > > > regions have a special significance to the operating system, not
> > > > > just to the next bootloader stage. So I want to understand exactly
> > > > > why it is necessary to describe these regions in a way where the
> > > > > operating system might be expected to interpret this information and 
> > > > > act
> > > upon it.
> > > > >
> > > >
> > > >
> > > > I think runtime code and data today are mainly for supporting UEFI 
> > > > runtime
> > > services - some BIOS functions for OS to utilize, OS may follow below 
> > > ACPI spec to
> > > treat them as reserved range:
> > > > https://uefi.org/specs/ACPI/6.5/15_System_Address_Map_Interfaces.html#
> > > > uefi-memory-types-and-mapping-to-acpi-address-range-types
> > > >
> > > > Like I mentioned earlier, that PR is still in early phase and has not 
> > > > reflected all
> > > the required changes yet, but the idea is to build
> > > gEfiMemoryTypeInformationGuid HOB from FDT reserved-memory nodes.
> > > > UEFI generic Payload has DxeMain integrated, however Memory Types are
> > > platform-specific, for example, some platforms may need bigger runtime 
> > > memory
> > > for their implementation, that's why we want such FDT reserved-memory 
> > > node to
> > > tell DxeMain.
> > > >
> > >
> > > > The Payload flow will be like this:
> > > >   Payload creates built-in default MemoryTypes table ->
> > > >

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Ard Biesheuvel]

On Fri, 22 Dec 2023 at 20:52, Chiu, Chasel  wrote:
>
>
> Please see my reply below inline.
>
> Thanks,
> Chasel
>
...
> > > > The gEfiMemoryTypeInformationGuid HOB typically carries platform
> > > > defaults, and the actual memory type information is kept in a
> > > > non-volatile EFI variable, which gets updated when the memory usage
> > > > changes. Is this different for UefiPayloadPkg?
> > > >
> > > > (For those among the cc'ees less versed in EFI/EDK2: when you get
> > > > the 'config changed -rebooting' message from the boot firmware, it
> > > > typically means that this memory type table has changed, and a
> > > > reboot is necessary.)
> > > >
> > > > So the platform init needs to read this variable, or get the
> > > > information in a different way. I assume it is the payload, not the
> > > > platform init that updates the variable when necessary. This means
> > > > the information flows from payload(n) to platform init(n+1), where n
> > > > is a monotonic index tracking consecutive boots of the system.
> > > >
> > > > Can you explain how the DT fits into this? How are the runtime-code
> > > > and runtime-data memory reservation nodes under /reserved-memory
> > > > used to implement this information exchange between platform init
> > > > and payload? And how do the HOB and the EFI variable fit into this 
> > > > picture?
> > >
> > >
> > > 1. With some offline discussion, we would move
> > > gEfiMemoryTypeInformationGuid usage to FDT->upl-custom node. This is
> > > because it is edk2 implementation choice and non-edk2 PlatformInit or
> > > Payload may not have such memory optimization implementation. (not a
> > > generic usage/requirement for PlatformInit and Payload)
> > >
> > > The edk2 example flow will be like below:
> > >
> > > PlatformInit to GetVariable of gEfiMemoryTypeInformationGuid and create 
> > > Hob-
> > >
> > >   PlatformInit to initialize FDT->upl-custom node to report
> > gEfiMemoryTypeInformationGuid HOB information ->
> > > UefiPayload entry to re-create gEfiMemoryTypeInformationGuid HOB 
> > > basing
> > on FDT input (instead of the default MemoryType inside UefiPayload) ->
> > >   UefiPayload DxeMain/Gcd will consume gEfiMemoryTypeInformationGuid
> > Hob for memory type information ->
> > > UefiPayload to initialize UEFI environment (mainly DXE 
> > > dispatcher) ->
> > >   (additional FV binary appended to common UefiPayload binary)
> > PlatformPayload to provide VariableService which is platform specific ->
> > > UefiPayload UefiBootManager will SetVariable if memory type 
> > > change
> > needed and request a warm reset ->
> > >   Back to PlatformInit ...
> > >
> >
> > OK so the upl-custom node can do whatever it needs to. I imagine these will
> > include the memory descriptor attribute field, and other parts that may be 
> > missing
> > from the /reserved-memory DT node specification?
>
>
> Yes, if needed by edk2 specific implementation, not generic enough, we may 
> consider to use upl-custom node to pass those data.
>
>
> >
> > >
> > > 2. Now the proposed reserved-memory node usages will be for PlatformInit 
> > > to
> > provide data which may be used by Payload or OS. This is not edk2 specific 
> > and
> > any PlatformInit/Payload could have same support.
> > > Note: all of below are optional and PlatformInit may choose to implement 
> > > some
> > of them or not.
> > >
> > >   - acpi
> > > If PlatformInit created some ACPI tables, this will report a memory 
> > > region which
> > contains all the tables to Payload and Payload may base on this to add some 
> > more
> > tables if required.
> > >
> > >   - acpi-nvs
> > > If PlatformInit has created some ACPI tables which having ACPI NVS memory
> > dependency, this will be that nvs region.
> > >
> >
> > These make sense.
> >
> > >   - boot-code
> > > When PlatformInit having some FW boot phase code that could be freed
> > > for OS to use when payload transferring control to UEFI OS
> > >
> > >   - boot-data
> > > When PlatformInit having some FW boot phase data that could be freed for 
> > > OS
> > to use when payload transferring control to UEFI OS.
> > >
> > >   - runtime-code
> > > PlatformInit may provide some services code that can be used for Payload 
> > > to
> > initialize UEFI Runtime Services for supporting UEFI OS.
> > >
> > >   - runtime-data
> > > PlatformInit may provide some services data that can be used for Payload 
> > > to
> > Initialize UEFI Runtime Services for supporting UEFI OS.
> > >
> >
> > A UEFI OS must consume this information from the UEFI memory map, not from
> > the /reserved-memory nodes. So these nodes must either not be visible to 
> > the OS
> > at all, or carry an annotation that the OS must ignore them.
> >
> > Would it be possible to include a restriction in the DT schema that these 
> > are only
> > valid in the firmware boot phase?
>
>
> 

RE: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Chiu, Chasel]

Please see my reply below inline.

Thanks,
Chasel


> -Original Message-
> From: Ard Biesheuvel 
> Sent: Friday, December 22, 2023 4:48 AM
> To: Chiu, Chasel 
> Cc: Simon Glass ; devicet...@vger.kernel.org; Mark Rutland
> ; Rob Herring ; Tan, Lean Sheng
> ; lkml ; Dhaval
> Sharma ; Brune, Maximilian
> ; Yunhui Cui ;
> Dong, Guo ; Tom Rini ; ron minnich
> ; Guo, Gua ; linux-
> a...@vger.kernel.org; U-Boot Mailing List 
> Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory
> usages
> 
> On Thu, 21 Dec 2023 at 17:50, Chiu, Chasel  wrote:
> >
> >
> > Hi Ard,
> >
> > Please see my reply below inline and let me know your thoughts.
> >
> > Thanks,
> > Chasel
> >
> >
> > > -Original Message-
> > > From: Ard Biesheuvel 
> > > Sent: Thursday, December 21, 2023 6:31 AM
> > > To: Chiu, Chasel 
> > > Cc: Simon Glass ; devicet...@vger.kernel.org; Mark
> > > Rutland ; Rob Herring ; Tan,
> > > Lean Sheng ; lkml
> > > ; Dhaval Sharma ;
> > > Brune, Maximilian ; Yunhui Cui
> > > ; Dong, Guo ; Tom Rini
> > > ; ron minnich ; Guo, Gua
> > > ; linux- a...@vger.kernel.org; U-Boot Mailing
> > > List 
> > > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory
> > > usages
> > >
> > > On Tue, 28 Nov 2023 at 21:31, Chiu, Chasel  wrote:
> > > >
> > > >
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Ard Biesheuvel 
> > > > > Sent: Tuesday, November 28, 2023 10:08 AM
> > > > > To: Chiu, Chasel 
> > > > > Cc: Simon Glass ; devicet...@vger.kernel.org;
> > > > > Mark Rutland ; Rob Herring
> > > > > ; Tan, Lean Sheng ;
> > > > > lkml ; Dhaval Sharma
> > > > > ; Brune, Maximilian
> > > > > ; Yunhui Cui
> > > > > ; Dong, Guo ; Tom
> > > > > Rini ; ron minnich ;
> > > > > Guo, Gua ; linux- a...@vger.kernel.org;
> > > > > U-Boot Mailing List 
> > > > > Subject: Re: [PATCH v7 2/2] schemas: Add some common
> > > > > reserved-memory usages
> > > > >
> > > > > You are referring to a 2000 line patch so it is not 100% clear where 
> > > > > to look
> tbh.
> > > > >
> > > > >
> > > > > On Tue, 21 Nov 2023 at 19:37, Chiu, Chasel 
> wrote:
> > > > > >
> > > > > >
> > > > > > In PR, UefiPayloadPkg/Library/FdtParserLib/FdtParserLib.c,
> > > > > > line
> > > > > > 268 is for
> > > > > related example code.
> > > > > >
> > > > >
> > > > > That refers to a 'memory-allocation' node, right? How does that
> > > > > relate to the 'reserved-memory' node?
> > > > >
> > > > > And crucially, how does this clarify in which way "runtime-code"
> > > > > and
> > > > > "runtime- data" reservations are being used?
> > > > >
> > > > > Since the very beginning of this discussion, I have been asking
> > > > > repeatedly for examples that describe the wider context in which
> > > > > these
> > > reservations are used.
> > > > > The "runtime" into runtime-code and runtime-data means that
> > > > > these regions have a special significance to the operating
> > > > > system, not just to the next bootloader stage. So I want to
> > > > > understand exactly why it is necessary to describe these regions
> > > > > in a way where the operating system might be expected to
> > > > > interpret this information and act
> > > upon it.
> > > > >
> > > >
> > > >
> > > > I think runtime code and data today are mainly for supporting UEFI
> > > > runtime
> > > services - some BIOS functions for OS to utilize, OS may follow
> > > below ACPI spec to treat them as reserved range:
> > > > https://uefi.org/specs/ACPI/6.5/15_System_Address_Map_Interfaces.h
> > > > tml# uefi-memory-types-and-mapping-to-acpi-address-range-types
> > > >
> > > > Like I mentioned earlier, that PR is still in early phase and has
> > > > not reflected all
> > > the required changes yet, but the idea is to build
> > > gEfiMemoryTypeInformatio

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Ard Biesheuvel]

On Thu, 21 Dec 2023 at 17:50, Chiu, Chasel  wrote:
>
>
> Hi Ard,
>
> Please see my reply below inline and let me know your thoughts.
>
> Thanks,
> Chasel
>
>
> > -Original Message-
> > From: Ard Biesheuvel 
> > Sent: Thursday, December 21, 2023 6:31 AM
> > To: Chiu, Chasel 
> > Cc: Simon Glass ; devicet...@vger.kernel.org; Mark 
> > Rutland
> > ; Rob Herring ; Tan, Lean Sheng
> > ; lkml ; Dhaval
> > Sharma ; Brune, Maximilian
> > ; Yunhui Cui ;
> > Dong, Guo ; Tom Rini ; ron minnich
> > ; Guo, Gua ; linux-
> > a...@vger.kernel.org; U-Boot Mailing List 
> > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory
> > usages
> >
> > On Tue, 28 Nov 2023 at 21:31, Chiu, Chasel  wrote:
> > >
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Ard Biesheuvel 
> > > > Sent: Tuesday, November 28, 2023 10:08 AM
> > > > To: Chiu, Chasel 
> > > > Cc: Simon Glass ; devicet...@vger.kernel.org; Mark
> > > > Rutland ; Rob Herring ; Tan,
> > > > Lean Sheng ; lkml
> > > > ; Dhaval Sharma ;
> > > > Brune, Maximilian ; Yunhui Cui
> > > > ; Dong, Guo ; Tom Rini
> > > > ; ron minnich ; Guo, Gua
> > > > ; linux- a...@vger.kernel.org; U-Boot Mailing
> > > > List 
> > > > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory
> > > > usages
> > > >
> > > > You are referring to a 2000 line patch so it is not 100% clear where to 
> > > > look tbh.
> > > >
> > > >
> > > > On Tue, 21 Nov 2023 at 19:37, Chiu, Chasel  
> > > > wrote:
> > > > >
> > > > >
> > > > > In PR, UefiPayloadPkg/Library/FdtParserLib/FdtParserLib.c, line
> > > > > 268 is for
> > > > related example code.
> > > > >
> > > >
> > > > That refers to a 'memory-allocation' node, right? How does that
> > > > relate to the 'reserved-memory' node?
> > > >
> > > > And crucially, how does this clarify in which way "runtime-code" and
> > > > "runtime- data" reservations are being used?
> > > >
> > > > Since the very beginning of this discussion, I have been asking
> > > > repeatedly for examples that describe the wider context in which these
> > reservations are used.
> > > > The "runtime" into runtime-code and runtime-data means that these
> > > > regions have a special significance to the operating system, not
> > > > just to the next bootloader stage. So I want to understand exactly
> > > > why it is necessary to describe these regions in a way where the
> > > > operating system might be expected to interpret this information and act
> > upon it.
> > > >
> > >
> > >
> > > I think runtime code and data today are mainly for supporting UEFI runtime
> > services - some BIOS functions for OS to utilize, OS may follow below ACPI 
> > spec to
> > treat them as reserved range:
> > > https://uefi.org/specs/ACPI/6.5/15_System_Address_Map_Interfaces.html#
> > > uefi-memory-types-and-mapping-to-acpi-address-range-types
> > >
> > > Like I mentioned earlier, that PR is still in early phase and has not 
> > > reflected all
> > the required changes yet, but the idea is to build
> > gEfiMemoryTypeInformationGuid HOB from FDT reserved-memory nodes.
> > > UEFI generic Payload has DxeMain integrated, however Memory Types are
> > platform-specific, for example, some platforms may need bigger runtime 
> > memory
> > for their implementation, that's why we want such FDT reserved-memory node 
> > to
> > tell DxeMain.
> > >
> >
> > > The Payload flow will be like this:
> > >   Payload creates built-in default MemoryTypes table ->
> > > FDT reserved-memory node to override if required (this also ensures 
> > > the
> > same memory map cross boots so ACPI S4 works) ->
> > >   Build gEfiMemoryTypeInformationGuid HOB by "platfom specific"
> > MemoryTypes Table ->
> > > DxeMain/GCD to consume this MemoryTypes table and setup memory
> > service ->
> > >   Install memory types table to UEFI system table.Configuration 
> > > table...
> > >
> > > Note: if Payload built-in default MemoryTypes table works fine for the
>

RE: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Chiu, Chasel]

Hi Ard,

Please see my reply below inline and let me know your thoughts.

Thanks,
Chasel


> -Original Message-
> From: Ard Biesheuvel 
> Sent: Thursday, December 21, 2023 6:31 AM
> To: Chiu, Chasel 
> Cc: Simon Glass ; devicet...@vger.kernel.org; Mark Rutland
> ; Rob Herring ; Tan, Lean Sheng
> ; lkml ; Dhaval
> Sharma ; Brune, Maximilian
> ; Yunhui Cui ;
> Dong, Guo ; Tom Rini ; ron minnich
> ; Guo, Gua ; linux-
> a...@vger.kernel.org; U-Boot Mailing List 
> Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory
> usages
> 
> On Tue, 28 Nov 2023 at 21:31, Chiu, Chasel  wrote:
> >
> >
> >
> >
> > > -Original Message-
> > > From: Ard Biesheuvel 
> > > Sent: Tuesday, November 28, 2023 10:08 AM
> > > To: Chiu, Chasel 
> > > Cc: Simon Glass ; devicet...@vger.kernel.org; Mark
> > > Rutland ; Rob Herring ; Tan,
> > > Lean Sheng ; lkml
> > > ; Dhaval Sharma ;
> > > Brune, Maximilian ; Yunhui Cui
> > > ; Dong, Guo ; Tom Rini
> > > ; ron minnich ; Guo, Gua
> > > ; linux- a...@vger.kernel.org; U-Boot Mailing
> > > List 
> > > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory
> > > usages
> > >
> > > You are referring to a 2000 line patch so it is not 100% clear where to 
> > > look tbh.
> > >
> > >
> > > On Tue, 21 Nov 2023 at 19:37, Chiu, Chasel  wrote:
> > > >
> > > >
> > > > In PR, UefiPayloadPkg/Library/FdtParserLib/FdtParserLib.c, line
> > > > 268 is for
> > > related example code.
> > > >
> > >
> > > That refers to a 'memory-allocation' node, right? How does that
> > > relate to the 'reserved-memory' node?
> > >
> > > And crucially, how does this clarify in which way "runtime-code" and
> > > "runtime- data" reservations are being used?
> > >
> > > Since the very beginning of this discussion, I have been asking
> > > repeatedly for examples that describe the wider context in which these
> reservations are used.
> > > The "runtime" into runtime-code and runtime-data means that these
> > > regions have a special significance to the operating system, not
> > > just to the next bootloader stage. So I want to understand exactly
> > > why it is necessary to describe these regions in a way where the
> > > operating system might be expected to interpret this information and act
> upon it.
> > >
> >
> >
> > I think runtime code and data today are mainly for supporting UEFI runtime
> services - some BIOS functions for OS to utilize, OS may follow below ACPI 
> spec to
> treat them as reserved range:
> > https://uefi.org/specs/ACPI/6.5/15_System_Address_Map_Interfaces.html#
> > uefi-memory-types-and-mapping-to-acpi-address-range-types
> >
> > Like I mentioned earlier, that PR is still in early phase and has not 
> > reflected all
> the required changes yet, but the idea is to build
> gEfiMemoryTypeInformationGuid HOB from FDT reserved-memory nodes.
> > UEFI generic Payload has DxeMain integrated, however Memory Types are
> platform-specific, for example, some platforms may need bigger runtime memory
> for their implementation, that's why we want such FDT reserved-memory node to
> tell DxeMain.
> >
> 
> > The Payload flow will be like this:
> >   Payload creates built-in default MemoryTypes table ->
> > FDT reserved-memory node to override if required (this also ensures the
> same memory map cross boots so ACPI S4 works) ->
> >   Build gEfiMemoryTypeInformationGuid HOB by "platfom specific"
> MemoryTypes Table ->
> > DxeMain/GCD to consume this MemoryTypes table and setup memory
> service ->
> >   Install memory types table to UEFI system table.Configuration 
> > table...
> >
> > Note: if Payload built-in default MemoryTypes table works fine for the
> > platform, then FDT reserved-memory node does not need to provide such
> 'usage' compatible strings. (optional) This FDT node could allow
> flexibility/compatibility without rebuilding Payload binary.
> >
> > Not sure if I answered all your questions, please highlight which area you 
> > need
> more information.
> >
> 
> The gEfiMemoryTypeInformationGuid HOB typically carries platform defaults, and
> the actual memory type information is kept in a non-volatile EFI variable, 
> which
> gets updated when the memory usage changes. Is this different for
> UefiPayloadPkg?
> 

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Ard Biesheuvel]

On Tue, 28 Nov 2023 at 21:31, Chiu, Chasel  wrote:
>
>
>
>
> > -Original Message-
> > From: Ard Biesheuvel 
> > Sent: Tuesday, November 28, 2023 10:08 AM
> > To: Chiu, Chasel 
> > Cc: Simon Glass ; devicet...@vger.kernel.org; Mark 
> > Rutland
> > ; Rob Herring ; Tan, Lean Sheng
> > ; lkml ; Dhaval
> > Sharma ; Brune, Maximilian
> > ; Yunhui Cui ;
> > Dong, Guo ; Tom Rini ; ron minnich
> > ; Guo, Gua ; linux-
> > a...@vger.kernel.org; U-Boot Mailing List 
> > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory
> > usages
> >
> > You are referring to a 2000 line patch so it is not 100% clear where to 
> > look tbh.
> >
> >
> > On Tue, 21 Nov 2023 at 19:37, Chiu, Chasel  wrote:
> > >
> > >
> > > In PR, UefiPayloadPkg/Library/FdtParserLib/FdtParserLib.c, line 268 is for
> > related example code.
> > >
> >
> > That refers to a 'memory-allocation' node, right? How does that relate to 
> > the
> > 'reserved-memory' node?
> >
> > And crucially, how does this clarify in which way "runtime-code" and 
> > "runtime-
> > data" reservations are being used?
> >
> > Since the very beginning of this discussion, I have been asking repeatedly 
> > for
> > examples that describe the wider context in which these reservations are 
> > used.
> > The "runtime" into runtime-code and runtime-data means that these regions 
> > have
> > a special significance to the operating system, not just to the next 
> > bootloader
> > stage. So I want to understand exactly why it is necessary to describe these
> > regions in a way where the operating system might be expected to interpret 
> > this
> > information and act upon it.
> >
>
>
> I think runtime code and data today are mainly for supporting UEFI runtime 
> services - some BIOS functions for OS to utilize, OS may follow below ACPI 
> spec to treat them as reserved range:
> https://uefi.org/specs/ACPI/6.5/15_System_Address_Map_Interfaces.html#uefi-memory-types-and-mapping-to-acpi-address-range-types
>
> Like I mentioned earlier, that PR is still in early phase and has not 
> reflected all the required changes yet, but the idea is to build 
> gEfiMemoryTypeInformationGuid HOB from FDT reserved-memory nodes.
> UEFI generic Payload has DxeMain integrated, however Memory Types are 
> platform-specific, for example, some platforms may need bigger runtime memory 
> for their implementation, that's why we want such FDT reserved-memory node to 
> tell DxeMain.
>

> The Payload flow will be like this:
>   Payload creates built-in default MemoryTypes table ->
> FDT reserved-memory node to override if required (this also ensures the 
> same memory map cross boots so ACPI S4 works) ->
>   Build gEfiMemoryTypeInformationGuid HOB by "platfom specific" 
> MemoryTypes Table ->
> DxeMain/GCD to consume this MemoryTypes table and setup memory 
> service ->
>   Install memory types table to UEFI system table.Configuration 
> table...
>
> Note: if Payload built-in default MemoryTypes table works fine for the 
> platform, then FDT reserved-memory node does not need to provide such 'usage' 
> compatible strings. (optional)
> This FDT node could allow flexibility/compatibility without rebuilding 
> Payload binary.
>
> Not sure if I answered all your questions, please highlight which area you 
> need more information.
>

The gEfiMemoryTypeInformationGuid HOB typically carries platform
defaults, and the actual memory type information is kept in a
non-volatile EFI variable, which gets updated when the memory usage
changes. Is this different for UefiPayloadPkg?

(For those among the cc'ees less versed in EFI/EDK2: when you get the
'config changed -rebooting' message from the boot firmware, it
typically means that this memory type table has changed, and a reboot
is necessary.)

So the platform init needs to read this variable, or get the
information in a different way. I assume it is the payload, not the
platform init that updates the variable when necessary. This means the
information flows from payload(n) to platform init(n+1), where n is a
monotonic index tracking consecutive boots of the system.

Can you explain how the DT fits into this? How are the runtime-code
and runtime-data memory reservation nodes under /reserved-memory used
to implement this information exchange between platform init and
payload? And how do the HOB and the EFI variable fit into this
picture?

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Simon Glass]

Hi,

On Mon, 11 Dec 2023 at 10:52, Simon Glass  wrote:
>
> Hi,
>
> On Tue, 28 Nov 2023 at 13:31, Chiu, Chasel  wrote:
> >
> >
> >
> >
> > > -Original Message-
> > > From: Ard Biesheuvel 
> > > Sent: Tuesday, November 28, 2023 10:08 AM
> > > To: Chiu, Chasel 
> > > Cc: Simon Glass ; devicet...@vger.kernel.org; Mark 
> > > Rutland
> > > ; Rob Herring ; Tan, Lean Sheng
> > > ; lkml ; Dhaval
> > > Sharma ; Brune, Maximilian
> > > ; Yunhui Cui ;
> > > Dong, Guo ; Tom Rini ; ron minnich
> > > ; Guo, Gua ; linux-
> > > a...@vger.kernel.org; U-Boot Mailing List 
> > > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory
> > > usages
> > >
> > > You are referring to a 2000 line patch so it is not 100% clear where to 
> > > look tbh.
> > >
> > >
> > > On Tue, 21 Nov 2023 at 19:37, Chiu, Chasel  wrote:
> > > >
> > > >
> > > > In PR, UefiPayloadPkg/Library/FdtParserLib/FdtParserLib.c, line 268 is 
> > > > for
> > > related example code.
> > > >
> > >
> > > That refers to a 'memory-allocation' node, right? How does that relate to 
> > > the
> > > 'reserved-memory' node?
> > >
> > > And crucially, how does this clarify in which way "runtime-code" and 
> > > "runtime-
> > > data" reservations are being used?
> > >
> > > Since the very beginning of this discussion, I have been asking 
> > > repeatedly for
> > > examples that describe the wider context in which these reservations are 
> > > used.
> > > The "runtime" into runtime-code and runtime-data means that these regions 
> > > have
> > > a special significance to the operating system, not just to the next 
> > > bootloader
> > > stage. So I want to understand exactly why it is necessary to describe 
> > > these
> > > regions in a way where the operating system might be expected to 
> > > interpret this
> > > information and act upon it.
> > >
> >
> >
> > I think runtime code and data today are mainly for supporting UEFI runtime 
> > services - some BIOS functions for OS to utilize, OS may follow below ACPI 
> > spec to treat them as reserved range:
> > https://uefi.org/specs/ACPI/6.5/15_System_Address_Map_Interfaces.html#uefi-memory-types-and-mapping-to-acpi-address-range-types
> >
> > Like I mentioned earlier, that PR is still in early phase and has not 
> > reflected all the required changes yet, but the idea is to build 
> > gEfiMemoryTypeInformationGuid HOB from FDT reserved-memory nodes.
> > UEFI generic Payload has DxeMain integrated, however Memory Types are 
> > platform-specific, for example, some platforms may need bigger runtime 
> > memory for their implementation, that's why we want such FDT 
> > reserved-memory node to tell DxeMain.
> >
> > The Payload flow will be like this:
> >   Payload creates built-in default MemoryTypes table ->
> > FDT reserved-memory node to override if required (this also ensures the 
> > same memory map cross boots so ACPI S4 works) ->
> >   Build gEfiMemoryTypeInformationGuid HOB by "platfom specific" 
> > MemoryTypes Table ->
> > DxeMain/GCD to consume this MemoryTypes table and setup memory 
> > service ->
> >   Install memory types table to UEFI system table.Configuration 
> > table...
> >
> > Note: if Payload built-in default MemoryTypes table works fine for the 
> > platform, then FDT reserved-memory node does not need to provide such 
> > 'usage' compatible strings. (optional)
> > This FDT node could allow flexibility/compatibility without rebuilding 
> > Payload binary.
> >
> > Not sure if I answered all your questions, please highlight which area you 
> > need more information.
>
> Any more thoughts on this? If not, I would like to see this patch
> applied, please.

I am really not sure who or what is holding this up, so far.

Can we perhaps get this applied in time for Christmas? It would be a
nice end to the year.

Regards,
Simon

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Simon Glass]

Hi,

On Tue, 28 Nov 2023 at 13:31, Chiu, Chasel  wrote:
>
>
>
>
> > -Original Message-
> > From: Ard Biesheuvel 
> > Sent: Tuesday, November 28, 2023 10:08 AM
> > To: Chiu, Chasel 
> > Cc: Simon Glass ; devicet...@vger.kernel.org; Mark 
> > Rutland
> > ; Rob Herring ; Tan, Lean Sheng
> > ; lkml ; Dhaval
> > Sharma ; Brune, Maximilian
> > ; Yunhui Cui ;
> > Dong, Guo ; Tom Rini ; ron minnich
> > ; Guo, Gua ; linux-
> > a...@vger.kernel.org; U-Boot Mailing List 
> > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory
> > usages
> >
> > You are referring to a 2000 line patch so it is not 100% clear where to 
> > look tbh.
> >
> >
> > On Tue, 21 Nov 2023 at 19:37, Chiu, Chasel  wrote:
> > >
> > >
> > > In PR, UefiPayloadPkg/Library/FdtParserLib/FdtParserLib.c, line 268 is for
> > related example code.
> > >
> >
> > That refers to a 'memory-allocation' node, right? How does that relate to 
> > the
> > 'reserved-memory' node?
> >
> > And crucially, how does this clarify in which way "runtime-code" and 
> > "runtime-
> > data" reservations are being used?
> >
> > Since the very beginning of this discussion, I have been asking repeatedly 
> > for
> > examples that describe the wider context in which these reservations are 
> > used.
> > The "runtime" into runtime-code and runtime-data means that these regions 
> > have
> > a special significance to the operating system, not just to the next 
> > bootloader
> > stage. So I want to understand exactly why it is necessary to describe these
> > regions in a way where the operating system might be expected to interpret 
> > this
> > information and act upon it.
> >
>
>
> I think runtime code and data today are mainly for supporting UEFI runtime 
> services - some BIOS functions for OS to utilize, OS may follow below ACPI 
> spec to treat them as reserved range:
> https://uefi.org/specs/ACPI/6.5/15_System_Address_Map_Interfaces.html#uefi-memory-types-and-mapping-to-acpi-address-range-types
>
> Like I mentioned earlier, that PR is still in early phase and has not 
> reflected all the required changes yet, but the idea is to build 
> gEfiMemoryTypeInformationGuid HOB from FDT reserved-memory nodes.
> UEFI generic Payload has DxeMain integrated, however Memory Types are 
> platform-specific, for example, some platforms may need bigger runtime memory 
> for their implementation, that's why we want such FDT reserved-memory node to 
> tell DxeMain.
>
> The Payload flow will be like this:
>   Payload creates built-in default MemoryTypes table ->
> FDT reserved-memory node to override if required (this also ensures the 
> same memory map cross boots so ACPI S4 works) ->
>   Build gEfiMemoryTypeInformationGuid HOB by "platfom specific" 
> MemoryTypes Table ->
> DxeMain/GCD to consume this MemoryTypes table and setup memory 
> service ->
>   Install memory types table to UEFI system table.Configuration 
> table...
>
> Note: if Payload built-in default MemoryTypes table works fine for the 
> platform, then FDT reserved-memory node does not need to provide such 'usage' 
> compatible strings. (optional)
> This FDT node could allow flexibility/compatibility without rebuilding 
> Payload binary.
>
> Not sure if I answered all your questions, please highlight which area you 
> need more information.

Any more thoughts on this? If not, I would like to see this patch
applied, please.

Regards,
Simon


>
> Thanks,
> Chasel
>
>
> >
> > >
> > > > -----Original Message-
> > > > From: Chiu, Chasel
> > > > Sent: Tuesday, November 21, 2023 10:34 AM
> > > > To: Ard Biesheuvel ; Simon Glass 
> > > > Cc: devicet...@vger.kernel.org; Mark Rutland ;
> > > > Rob Herring ; Tan, Lean Sheng
> > > > ; lkml ;
> > > > Dhaval Sharma ; Brune, Maximilian
> > > > ; Yunhui Cui
> > > > ; Dong, Guo ; Tom Rini
> > > > ; ron minnich ; Guo, Gua
> > > > ; linux-a...@vger.kernel.org; U-Boot Mailing List
> > > > ; Chiu, Chasel 
> > > > Subject: RE: [PATCH v7 2/2] schemas: Add some common reserved-memory
> > > > usages
> > > >
> > > >
> > > > Hi Ard,
> > > >
> > > > Here is the POC PR for your reference:
> > > > https://github.com/tianocore/edk2/pull/4969/files#diff-
> > > >
> > ccebabae5274b21634723

RE: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Chiu, Chasel]

> -Original Message-
> From: Ard Biesheuvel 
> Sent: Tuesday, November 28, 2023 10:08 AM
> To: Chiu, Chasel 
> Cc: Simon Glass ; devicet...@vger.kernel.org; Mark Rutland
> ; Rob Herring ; Tan, Lean Sheng
> ; lkml ; Dhaval
> Sharma ; Brune, Maximilian
> ; Yunhui Cui ;
> Dong, Guo ; Tom Rini ; ron minnich
> ; Guo, Gua ; linux-
> a...@vger.kernel.org; U-Boot Mailing List 
> Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory
> usages
> 
> You are referring to a 2000 line patch so it is not 100% clear where to look 
> tbh.
> 
> 
> On Tue, 21 Nov 2023 at 19:37, Chiu, Chasel  wrote:
> >
> >
> > In PR, UefiPayloadPkg/Library/FdtParserLib/FdtParserLib.c, line 268 is for
> related example code.
> >
> 
> That refers to a 'memory-allocation' node, right? How does that relate to the
> 'reserved-memory' node?
> 
> And crucially, how does this clarify in which way "runtime-code" and "runtime-
> data" reservations are being used?
> 
> Since the very beginning of this discussion, I have been asking repeatedly for
> examples that describe the wider context in which these reservations are used.
> The "runtime" into runtime-code and runtime-data means that these regions have
> a special significance to the operating system, not just to the next 
> bootloader
> stage. So I want to understand exactly why it is necessary to describe these
> regions in a way where the operating system might be expected to interpret 
> this
> information and act upon it.
> 


I think runtime code and data today are mainly for supporting UEFI runtime 
services - some BIOS functions for OS to utilize, OS may follow below ACPI spec 
to treat them as reserved range:
https://uefi.org/specs/ACPI/6.5/15_System_Address_Map_Interfaces.html#uefi-memory-types-and-mapping-to-acpi-address-range-types

Like I mentioned earlier, that PR is still in early phase and has not reflected 
all the required changes yet, but the idea is to build 
gEfiMemoryTypeInformationGuid HOB from FDT reserved-memory nodes.
UEFI generic Payload has DxeMain integrated, however Memory Types are 
platform-specific, for example, some platforms may need bigger runtime memory 
for their implementation, that's why we want such FDT reserved-memory node to 
tell DxeMain.

The Payload flow will be like this:
  Payload creates built-in default MemoryTypes table ->
FDT reserved-memory node to override if required (this also ensures the 
same memory map cross boots so ACPI S4 works) ->
  Build gEfiMemoryTypeInformationGuid HOB by "platfom specific" MemoryTypes 
Table ->
DxeMain/GCD to consume this MemoryTypes table and setup memory service 
->
  Install memory types table to UEFI system table.Configuration table...

Note: if Payload built-in default MemoryTypes table works fine for the 
platform, then FDT reserved-memory node does not need to provide such 'usage' 
compatible strings. (optional)
This FDT node could allow flexibility/compatibility without rebuilding Payload 
binary.

Not sure if I answered all your questions, please highlight which area you need 
more information.

Thanks,
Chasel


> 
> >
> > > -Original Message-
> > > From: Chiu, Chasel
> > > Sent: Tuesday, November 21, 2023 10:34 AM
> > > To: Ard Biesheuvel ; Simon Glass 
> > > Cc: devicet...@vger.kernel.org; Mark Rutland ;
> > > Rob Herring ; Tan, Lean Sheng
> > > ; lkml ;
> > > Dhaval Sharma ; Brune, Maximilian
> > > ; Yunhui Cui
> > > ; Dong, Guo ; Tom Rini
> > > ; ron minnich ; Guo, Gua
> > > ; linux-a...@vger.kernel.org; U-Boot Mailing List
> > > ; Chiu, Chasel 
> > > Subject: RE: [PATCH v7 2/2] schemas: Add some common reserved-memory
> > > usages
> > >
> > >
> > > Hi Ard,
> > >
> > > Here is the POC PR for your reference:
> > > https://github.com/tianocore/edk2/pull/4969/files#diff-
> > >
> ccebabae5274b21634723a2111ee0de11bed6cfe8cb206ef9e263d9c5f926a9cR26
> > > 8
> > > Please note that this PR is still in early phase and expected to
> > > have significant changes.
> > >
> > > The idea is that payload entry will create
> > > gEfiMemoryTypeInformationGuid HOB with payload default memory types
> > > and allow FDT to override if correspond node present.
> > > Please let me know if you have questions or suggestions.
> > >
> > > Thanks,
> > > Chasel
> > >
> > >
> > > > -Original Message-
> > > > From: Ard Biesheuvel 
> > > > Sent: Tuesday, November 21, 2023 8:42 AM
> > > > To: Simon Glass 
> &g

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Ard Biesheuvel]

You are referring to a 2000 line patch so it is not 100% clear where
to look tbh.


On Tue, 21 Nov 2023 at 19:37, Chiu, Chasel  wrote:
>
>
> In PR, UefiPayloadPkg/Library/FdtParserLib/FdtParserLib.c, line 268 is for 
> related example code.
>

That refers to a 'memory-allocation' node, right? How does that relate
to the 'reserved-memory' node?

And crucially, how does this clarify in which way "runtime-code" and
"runtime-data" reservations are being used?

Since the very beginning of this discussion, I have been asking
repeatedly for examples that describe the wider context in which these
reservations are used. The "runtime" into runtime-code and
runtime-data means that these regions have a special significance to
the operating system, not just to the next bootloader stage. So I want
to understand exactly why it is necessary to describe these regions in
a way where the operating system might be expected to interpret this
information and act upon it.


>
> > -Original Message-
> > From: Chiu, Chasel
> > Sent: Tuesday, November 21, 2023 10:34 AM
> > To: Ard Biesheuvel ; Simon Glass 
> > Cc: devicet...@vger.kernel.org; Mark Rutland ; Rob
> > Herring ; Tan, Lean Sheng ; lkml
> > ; Dhaval Sharma ; Brune,
> > Maximilian ; Yunhui Cui
> > ; Dong, Guo ; Tom Rini
> > ; ron minnich ; Guo, Gua
> > ; linux-a...@vger.kernel.org; U-Boot Mailing List  > b...@lists.denx.de>; Chiu, Chasel 
> > Subject: RE: [PATCH v7 2/2] schemas: Add some common reserved-memory
> > usages
> >
> >
> > Hi Ard,
> >
> > Here is the POC PR for your reference:
> > https://github.com/tianocore/edk2/pull/4969/files#diff-
> > ccebabae5274b21634723a2111ee0de11bed6cfe8cb206ef9e263d9c5f926a9cR26
> > 8
> > Please note that this PR is still in early phase and expected to have 
> > significant
> > changes.
> >
> > The idea is that payload entry will create gEfiMemoryTypeInformationGuid HOB
> > with payload default memory types and allow FDT to override if correspond 
> > node
> > present.
> > Please let me know if you have questions or suggestions.
> >
> > Thanks,
> > Chasel
> >
> >
> > > -Original Message-
> > > From: Ard Biesheuvel 
> > > Sent: Tuesday, November 21, 2023 8:42 AM
> > > To: Simon Glass 
> > > Cc: Chiu, Chasel ; devicet...@vger.kernel.org;
> > > Mark Rutland ; Rob Herring ;
> > > Tan, Lean Sheng ; lkml
> > > ; Dhaval Sharma ;
> > > Brune, Maximilian ; Yunhui Cui
> > > ; Dong, Guo ; Tom Rini
> > > ; ron minnich ; Guo, Gua
> > > ; linux- a...@vger.kernel.org; U-Boot Mailing List
> > > 
> > > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory
> > > usages
> > >
> > > On Mon, 20 Nov 2023 at 21:12, Simon Glass  wrote:
> > > >
> > > > Hi,
> > > >
> > > > On Mon, 13 Nov 2023 at 11:09, Chiu, Chasel  
> > > > wrote:
> > > > >
> > > > >
> > > > > Hi Ard,
> > > > >
> > > > > Please see my reply below inline.
> > > > >
> > > > > Thanks,
> > > > > Chasel
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: Ard Biesheuvel 
> > > > > > Sent: Saturday, November 11, 2023 3:04 AM
> > > > > > To: Chiu, Chasel 
> > > > > > Cc: Simon Glass ; devicet...@vger.kernel.org;
> > > > > > Mark Rutland ; Rob Herring
> > > > > > ; Tan, Lean Sheng ;
> > > > > > lkml ; Dhaval Sharma
> > > > > > ; Brune, Maximilian
> > > > > > ; Yunhui Cui
> > > > > > ; Dong, Guo ; Tom
> > > > > > Rini ; ron minnich ;
> > > > > > Guo, Gua ; linux- a...@vger.kernel.org;
> > > > > > U-Boot Mailing List 
> > > > > > Subject: Re: [PATCH v7 2/2] schemas: Add some common
> > > > > > reserved-memory usages
> > > > > >
> > > > > > On Sat, 11 Nov 2023 at 04:20, Chiu, Chasel 
> > 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
> > > >

RE: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Chiu, Chasel]

In PR, UefiPayloadPkg/Library/FdtParserLib/FdtParserLib.c, line 268 is for 
related example code.

Thanks,
Chasel


> -Original Message-
> From: Chiu, Chasel
> Sent: Tuesday, November 21, 2023 10:34 AM
> To: Ard Biesheuvel ; Simon Glass 
> Cc: devicet...@vger.kernel.org; Mark Rutland ; Rob
> Herring ; Tan, Lean Sheng ; lkml
> ; Dhaval Sharma ; Brune,
> Maximilian ; Yunhui Cui
> ; Dong, Guo ; Tom Rini
> ; ron minnich ; Guo, Gua
> ; linux-a...@vger.kernel.org; U-Boot Mailing List  b...@lists.denx.de>; Chiu, Chasel 
> Subject: RE: [PATCH v7 2/2] schemas: Add some common reserved-memory
> usages
> 
> 
> Hi Ard,
> 
> Here is the POC PR for your reference:
> https://github.com/tianocore/edk2/pull/4969/files#diff-
> ccebabae5274b21634723a2111ee0de11bed6cfe8cb206ef9e263d9c5f926a9cR26
> 8
> Please note that this PR is still in early phase and expected to have 
> significant
> changes.
> 
> The idea is that payload entry will create gEfiMemoryTypeInformationGuid HOB
> with payload default memory types and allow FDT to override if correspond node
> present.
> Please let me know if you have questions or suggestions.
> 
> Thanks,
> Chasel
> 
> 
> > -Original Message-
> > From: Ard Biesheuvel 
> > Sent: Tuesday, November 21, 2023 8:42 AM
> > To: Simon Glass 
> > Cc: Chiu, Chasel ; devicet...@vger.kernel.org;
> > Mark Rutland ; Rob Herring ;
> > Tan, Lean Sheng ; lkml
> > ; Dhaval Sharma ;
> > Brune, Maximilian ; Yunhui Cui
> > ; Dong, Guo ; Tom Rini
> > ; ron minnich ; Guo, Gua
> > ; linux- a...@vger.kernel.org; U-Boot Mailing List
> > 
> > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory
> > usages
> >
> > On Mon, 20 Nov 2023 at 21:12, Simon Glass  wrote:
> > >
> > > Hi,
> > >
> > > On Mon, 13 Nov 2023 at 11:09, Chiu, Chasel  wrote:
> > > >
> > > >
> > > > Hi Ard,
> > > >
> > > > Please see my reply below inline.
> > > >
> > > > Thanks,
> > > > Chasel
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Ard Biesheuvel 
> > > > > Sent: Saturday, November 11, 2023 3:04 AM
> > > > > To: Chiu, Chasel 
> > > > > Cc: Simon Glass ; devicet...@vger.kernel.org;
> > > > > Mark Rutland ; Rob Herring
> > > > > ; Tan, Lean Sheng ;
> > > > > lkml ; Dhaval Sharma
> > > > > ; Brune, Maximilian
> > > > > ; Yunhui Cui
> > > > > ; Dong, Guo ; Tom
> > > > > Rini ; ron minnich ;
> > > > > Guo, Gua ; linux- a...@vger.kernel.org;
> > > > > U-Boot Mailing List 
> > > > > Subject: Re: [PATCH v7 2/2] schemas: Add some common
> > > > > reserved-memory usages
> > > > >
> > > > > On Sat, 11 Nov 2023 at 04:20, Chiu, Chasel 
> 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 u

RE: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Chiu, Chasel]

Hi Ard,

Here is the POC PR for your reference: 
https://github.com/tianocore/edk2/pull/4969/files#diff-ccebabae5274b21634723a2111ee0de11bed6cfe8cb206ef9e263d9c5f926a9cR268
Please note that this PR is still in early phase and expected to have 
significant changes.

The idea is that payload entry will create gEfiMemoryTypeInformationGuid HOB 
with payload default memory types and allow FDT to override if correspond node 
present.
Please let me know if you have questions or suggestions.

Thanks,
Chasel


> -Original Message-
> From: Ard Biesheuvel 
> Sent: Tuesday, November 21, 2023 8:42 AM
> To: Simon Glass 
> Cc: Chiu, Chasel ; devicet...@vger.kernel.org; Mark
> Rutland ; Rob Herring ; Tan, Lean
> Sheng ; lkml ;
> Dhaval Sharma ; Brune, Maximilian
> ; Yunhui Cui ;
> Dong, Guo ; Tom Rini ; ron minnich
> ; Guo, Gua ; linux-
> a...@vger.kernel.org; U-Boot Mailing List 
> Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory
> usages
> 
> On Mon, 20 Nov 2023 at 21:12, Simon Glass  wrote:
> >
> > Hi,
> >
> > On Mon, 13 Nov 2023 at 11:09, Chiu, Chasel  wrote:
> > >
> > >
> > > Hi Ard,
> > >
> > > Please see my reply below inline.
> > >
> > > Thanks,
> > > Chasel
> > >
> > >
> > > > -Original Message-
> > > > From: Ard Biesheuvel 
> > > > Sent: Saturday, November 11, 2023 3:04 AM
> > > > To: Chiu, Chasel 
> > > > Cc: Simon Glass ; devicet...@vger.kernel.org;
> > > > Mark Rutland ; Rob Herring
> > > > ; Tan, Lean Sheng ; lkml
> > > > ; Dhaval Sharma
> > > > ; Brune, Maximilian
> > > > ; Yunhui Cui
> > > > ; Dong, Guo ; Tom
> > > > Rini ; ron minnich ; Guo,
> > > > Gua ; linux- a...@vger.kernel.org; U-Boot
> > > > Mailing List 
> > > > Subject: Re: [PATCH v7 2/2] schemas: Add some common
> > > > reserved-memory usages
> > > >
> > > > On Sat, 11 Nov 2023 at 04:20, Chiu, Chasel  
> > > > 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
> > > run

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Ard Biesheuvel]

On Mon, 20 Nov 2023 at 21:12, Simon Glass  wrote:
>
> Hi,
>
> On Mon, 13 Nov 2023 at 11:09, Chiu, Chasel  wrote:
> >
> >
> > Hi Ard,
> >
> > Please see my reply below inline.
> >
> > Thanks,
> > Chasel
> >
> >
> > > -Original Message-
> > > From: Ard Biesheuvel 
> > > Sent: Saturday, November 11, 2023 3:04 AM
> > > To: Chiu, Chasel 
> > > Cc: Simon Glass ; devicet...@vger.kernel.org; Mark 
> > > Rutland
> > > ; Rob Herring ; Tan, Lean Sheng
> > > ; lkml ; Dhaval
> > > Sharma ; Brune, Maximilian
> > > ; Yunhui Cui ;
> > > Dong, Guo ; Tom Rini ; ron minnich
> > > ; Guo, Gua ; linux-
> > > a...@vger.kernel.org; U-Boot Mailing List 
> > > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory
> > > usages
> > >
> > > On Sat, 11 Nov 2023 at 04:20, Chiu, Chasel  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 
> > > >
> > >
> > > 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 

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Simon Glass]

Hi,

On Mon, 13 Nov 2023 at 11:09, Chiu, Chasel  wrote:
>
>
> Hi Ard,
>
> Please see my reply below inline.
>
> Thanks,
> Chasel
>
>
> > -Original Message-
> > From: Ard Biesheuvel 
> > Sent: Saturday, November 11, 2023 3:04 AM
> > To: Chiu, Chasel 
> > Cc: Simon Glass ; devicet...@vger.kernel.org; Mark 
> > Rutland
> > ; Rob Herring ; Tan, Lean Sheng
> > ; lkml ; Dhaval
> > Sharma ; Brune, Maximilian
> > ; Yunhui Cui ;
> > Dong, Guo ; Tom Rini ; ron minnich
> > ; Guo, Gua ; linux-
> > a...@vger.kernel.org; U-Boot Mailing List 
> > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory
> > usages
> >
> > On Sat, 11 Nov 2023 at 04:20, Chiu, Chasel  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 
> > >
> >
> > 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 discusse

RE: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Chiu, Chasel]

Hi Ard,

Please see my reply below inline.

Thanks,
Chasel


> -Original Message-
> From: Ard Biesheuvel 
> Sent: Saturday, November 11, 2023 3:04 AM
> To: Chiu, Chasel 
> Cc: Simon Glass ; devicet...@vger.kernel.org; Mark Rutland
> ; Rob Herring ; Tan, Lean Sheng
> ; lkml ; Dhaval
> Sharma ; Brune, Maximilian
> ; Yunhui Cui ;
> Dong, Guo ; Tom Rini ; ron minnich
> ; Guo, Gua ; linux-
> a...@vger.kernel.org; U-Boot Mailing List 
> Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory
> usages
> 
> On Sat, 11 Nov 2023 at 04:20, Chiu, Chasel  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 
> >
> 
> 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.




> 
> 
> >
> > > -Original Message-
> > > From: Simon Glass 
> > > Sent: Tuesday, September 26, 2023 12:43 PM
> > > To: devicet...@vger.kernel.org
> > > Cc: Mark Rutland ; Rob Herring
> > > ; Tan, Lean Sheng ; lkml
> > > ; Dhaval Sharma
> > > ; Brune, Maximilian
> > > ; Yunhui Cui
> > > ; Dong, Guo ; Tom Rini
> > > ; ron minnich ; Guo, Gua
> > > ; Chiu, Chasel ; linux-
> > > a...@vger.kernel.org; U-Boot Mailing List ;
> > > Ard Biesheuvel ; Simon Glass 
> > > Subject: [PATCH v7 2/2] 

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Ard Biesheuvel]

On Sat, 11 Nov 2023 at 04:20, Chiu, Chasel  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 
>

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 
> > Sent: Tuesday, September 26, 2023 12:43 PM
> > To: devicet...@vger.kernel.org
> > Cc: Mark Rutland ; Rob Herring ;
> > Tan, Lean Sheng ; lkml  > ker...@vger.kernel.org>; Dhaval Sharma ; Brune,
> > Maximilian ; Yunhui Cui
> > ; Dong, Guo ; Tom Rini
> > ; ron minnich ; Guo, Gua
> > ; Chiu, Chasel ; linux-
> > a...@vger.kernel.org; U-Boot Mailing List ; Ard
> > Biesheuvel ; Simon Glass 
> > 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 
> > ---
> >
> > 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 000..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 
> > +
> > +allOf:
> > +  - $ref: reserved-memory.yaml
> > +
> > +properties:
> > +  compatible:
> > +description: |
> > +  This describes some common memory reservations, with the compatible
> > +  string indicating what it is used 

RE: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Chiu, Chasel]

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)
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.

Under below assumption:
FDT OS impact has been evaluated and taken care by relevant 
experts/stakeholders.
Reviewed-by: Chasel Chiu 

Thanks,
Chasel


> -Original Message-
> From: Simon Glass 
> Sent: Tuesday, September 26, 2023 12:43 PM
> To: devicet...@vger.kernel.org
> Cc: Mark Rutland ; Rob Herring ;
> Tan, Lean Sheng ; lkml  ker...@vger.kernel.org>; Dhaval Sharma ; Brune,
> Maximilian ; Yunhui Cui
> ; Dong, Guo ; Tom Rini
> ; ron minnich ; Guo, Gua
> ; Chiu, Chasel ; linux-
> a...@vger.kernel.org; U-Boot Mailing List ; Ard
> Biesheuvel ; Simon Glass 
> 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 
> ---
> 
> 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 000..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 
> +
> +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>;
> +

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Lean Sheng Tan]

Hi Rob,
Sure, I will ask if the edk2 developers who work together for UPL spec
could help to respond here.

Hi Ard,
Regarding this part:
*However, there is no scoping in DT schema as far as I am aware, which
means that the OS may be forced/expected to interpret these regions beyond
simply disregarding them and treating them as reserved memory, and *that*
is something I strongly object to.*

I think that is one of good perspective to look into this, however please
also consider this situation: that everyone is just starting to develop
their own DT schemas (e.g. RISC-V), and there is no way to stop OS to also
pick up those DT nodes. in that case, if we do not maintain a more unified
DT schema, then OS might end up with more conflicting and
possibly contracting DT nodes/ properties (e.g. RISC-V with own DT schemas
using U-Boot (another DT schema) + edk2 payload (another DT schema, like
UPL) to boot to OS. So personally I still prefer a unified DT schema, even
if the OS never uses them, but that would be very beneficial and in control
in the long term if more people are using DT.

For now, the DT does serve as the purpose of communication vehicle in
between platform init and payload, which is still within Firmware stack.
However from edk2 stand point, there is more people want to roll out DT for
more internal usage within edk2 itself, for example:
https://uefi.org/sites/default/files/resources/Embracing%20Modularity%20and%20Boot-Time%20Configuration%20Faster%20TTM%20with%20Tiano-based%20Solutions_Warkentin.pdf

For sure, it is much easier for us (and time saving as well) to just
maintain DT schema/ format within our own UPL spec, but as mentioned, for
better long term maintenance and community collaborations, we decided to
upstream our implementation back to the main DT schema :)

Thanks!

Best Regards,
*Lean Sheng Tan*



9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany
Email: sheng@9elements.com
Phone: *+49 234 68 94 188 <+492346894188>*
Mobile: *+49 176 76 113842 <+4917676113842>*

Registered office: Bochum
Commercial register: Amtsgericht Bochum, HRB 17519
Management: Sebastian German, Eray Bazaar

Data protection information according to Art. 13 GDPR



On Wed, 8 Nov 2023 at 15:20, Ard Biesheuvel  wrote:

> On Wed, 8 Nov 2023 at 14:57, Rob Herring  wrote:
> >
> > On Wed, Nov 8, 2023 at 5:38 AM Ard Biesheuvel  wrote:
> > >
> > > On Tue, 7 Nov 2023 at 19:07, Rob Herring  wrote:
> > > >
> > > >
> > > > All of this:
> > > >
> > >
> > > > > On Mon, 16 Oct 2023 at 15:54, Simon Glass 
> wrote:
> > > > > >
> > > > > > It is not specific to EDK2. Imagine this boot sequence:
> > > > > >
> > > > > > - Platform Init (U-Boot) starts up
> > > > > > - U-Boot uses its platform knowledge to sets some ACPI tables
> and put
> > > > > > various things in memory
> > > > > > - U-Boot sets up some runtime code and data for the OS
> > > > > > - U-Boot jumps to the Tianocore payload **
> > > > > > - Payload (Tianocore) wants to know where the ACPI tables are,
> for example
> > > > > > - Tianocore needs to provide boot services to the OS, so needs
> to know
> > > > > > the memory map, etc.
> > > > > >
> > > > > > ** At this point we want to use DT to pass the required
> information.
> > > > > >
> > > > > > Of course, Platform Init could be coreboot or Tianocore or some
> > > > > > strange private binary. Payload could be U-Boot or something
> else.
> > > > > > That is the point of this effort, to build interoperability.
> > > >
> > > > [...]
> > > >
> > > > > > Perhaps the problem here is that Linux has tied itself up in
> knots
> > > > > > with its EFI stuff and DT fixups and what-not. But this is not
> that.
> > > > > > It is a simple handoff between two pieces of firmware, Platform
> Init
> > > > > > and Payload. It has nothing to do with the OS. With Tianocore
> they are
> > > > > > typically combined, but with this usage they are split, and we
> can
> > > > > > swap out one project for another on either side of the DT
> interface.
> > > >
> > > > Is perhaps the clearest description of the problem you want to solve.
> > > > It's clearly related to EFI though not the interface to the OS. IIRC,
> > > > "platform init" and "payload" are terms in the UEFI spec, right?
> > >
> > > No they are not. This is from the universal payload specification that
> > > is being drafted here
> > >
> > > https://universalpayload.github.io/spec/index.html
> > >
> > > but the UEFI specification does not use this terminology.
> >
> > Then I'm confused as to what this is:
> >
> > https://uefi.org/specs/PI/1.8/index.html
> >
>
> The PI and UEFI specifications are both maintained by the UEFI forum.
>
> The UEFI specification covers external APIs for firmware
> implementations, i.e., the OS visible interface and the public API for
> UEFI device drivers that are not tightly integrated with system
> firmware (for example, the GPU boot time driver in the ROM of an
> add-in card)
>
> The UEFI forum's PI spec 

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Ard Biesheuvel]

On Wed, 8 Nov 2023 at 14:57, Rob Herring  wrote:
>
> On Wed, Nov 8, 2023 at 5:38 AM Ard Biesheuvel  wrote:
> >
> > On Tue, 7 Nov 2023 at 19:07, Rob Herring  wrote:
> > >
> > >
> > > All of this:
> > >
> >
> > > > On Mon, 16 Oct 2023 at 15:54, Simon Glass  wrote:
> > > > >
> > > > > It is not specific to EDK2. Imagine this boot sequence:
> > > > >
> > > > > - Platform Init (U-Boot) starts up
> > > > > - U-Boot uses its platform knowledge to sets some ACPI tables and put
> > > > > various things in memory
> > > > > - U-Boot sets up some runtime code and data for the OS
> > > > > - U-Boot jumps to the Tianocore payload **
> > > > > - Payload (Tianocore) wants to know where the ACPI tables are, for 
> > > > > example
> > > > > - Tianocore needs to provide boot services to the OS, so needs to know
> > > > > the memory map, etc.
> > > > >
> > > > > ** At this point we want to use DT to pass the required information.
> > > > >
> > > > > Of course, Platform Init could be coreboot or Tianocore or some
> > > > > strange private binary. Payload could be U-Boot or something else.
> > > > > That is the point of this effort, to build interoperability.
> > >
> > > [...]
> > >
> > > > > Perhaps the problem here is that Linux has tied itself up in knots
> > > > > with its EFI stuff and DT fixups and what-not. But this is not that.
> > > > > It is a simple handoff between two pieces of firmware, Platform Init
> > > > > and Payload. It has nothing to do with the OS. With Tianocore they are
> > > > > typically combined, but with this usage they are split, and we can
> > > > > swap out one project for another on either side of the DT interface.
> > >
> > > Is perhaps the clearest description of the problem you want to solve.
> > > It's clearly related to EFI though not the interface to the OS. IIRC,
> > > "platform init" and "payload" are terms in the UEFI spec, right?
> >
> > No they are not. This is from the universal payload specification that
> > is being drafted here
> >
> > https://universalpayload.github.io/spec/index.html
> >
> > but the UEFI specification does not use this terminology.
>
> Then I'm confused as to what this is:
>
> https://uefi.org/specs/PI/1.8/index.html
>

The PI and UEFI specifications are both maintained by the UEFI forum.

The UEFI specification covers external APIs for firmware
implementations, i.e., the OS visible interface and the public API for
UEFI device drivers that are not tightly integrated with system
firmware (for example, the GPU boot time driver in the ROM of an
add-in card)

The UEFI forum's PI spec describes system firmware internals, and
defines the SEC, PEI DXE and BDS boot phases, among other things.

It is possible to implement UEFI without PI (which is what uboot does,
for instance), but Tianocore/EDK2 is the reference implementation for
both PI and UEFI, and sadly, there is no discernible distinction
between the two (e.g., both PI and UEFI use identifiers with EFI_ type
and enum identifier prefixes)

'platform init' in the context of this discussion is something
completely separate, and has zero bearing on the PI<->UEFI handover in
Tianocore (which is not really a handover to begin with).

There is code in Tianocore which allows it to run as a 'payload',
which means [presumably] that only the DXE and subsequent phases are
launched from a 'platform init' component that describes the platform
using some of the DT bindings that are under discussion here. In this
case, I can see how some of the ACPI descriptions provided by the
'platform init' might be inherited by the 'payload'. However, I don't
see how such a Tianocore payload would make meaningful use of
boot/runtime code/data described in general terms using this proposed
binding, which is why I keep asking for an example scenario.

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Rob Herring]

On Wed, Nov 8, 2023 at 5:38 AM Ard Biesheuvel  wrote:
>
> On Tue, 7 Nov 2023 at 19:07, Rob Herring  wrote:
> >
> >
> > All of this:
> >
>
> > > On Mon, 16 Oct 2023 at 15:54, Simon Glass  wrote:
> > > >
> > > > It is not specific to EDK2. Imagine this boot sequence:
> > > >
> > > > - Platform Init (U-Boot) starts up
> > > > - U-Boot uses its platform knowledge to sets some ACPI tables and put
> > > > various things in memory
> > > > - U-Boot sets up some runtime code and data for the OS
> > > > - U-Boot jumps to the Tianocore payload **
> > > > - Payload (Tianocore) wants to know where the ACPI tables are, for 
> > > > example
> > > > - Tianocore needs to provide boot services to the OS, so needs to know
> > > > the memory map, etc.
> > > >
> > > > ** At this point we want to use DT to pass the required information.
> > > >
> > > > Of course, Platform Init could be coreboot or Tianocore or some
> > > > strange private binary. Payload could be U-Boot or something else.
> > > > That is the point of this effort, to build interoperability.
> >
> > [...]
> >
> > > > Perhaps the problem here is that Linux has tied itself up in knots
> > > > with its EFI stuff and DT fixups and what-not. But this is not that.
> > > > It is a simple handoff between two pieces of firmware, Platform Init
> > > > and Payload. It has nothing to do with the OS. With Tianocore they are
> > > > typically combined, but with this usage they are split, and we can
> > > > swap out one project for another on either side of the DT interface.
> >
> > Is perhaps the clearest description of the problem you want to solve.
> > It's clearly related to EFI though not the interface to the OS. IIRC,
> > "platform init" and "payload" are terms in the UEFI spec, right?
>
> No they are not. This is from the universal payload specification that
> is being drafted here
>
> https://universalpayload.github.io/spec/index.html
>
> but the UEFI specification does not use this terminology.

Then I'm confused as to what this is:

https://uefi.org/specs/PI/1.8/index.html

Rob

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Ard Biesheuvel]

On Tue, 7 Nov 2023 at 19:07, Rob Herring  wrote:
>
>
> All of this:
>

> > On Mon, 16 Oct 2023 at 15:54, Simon Glass  wrote:
> > >
> > > It is not specific to EDK2. Imagine this boot sequence:
> > >
> > > - Platform Init (U-Boot) starts up
> > > - U-Boot uses its platform knowledge to sets some ACPI tables and put
> > > various things in memory
> > > - U-Boot sets up some runtime code and data for the OS
> > > - U-Boot jumps to the Tianocore payload **
> > > - Payload (Tianocore) wants to know where the ACPI tables are, for example
> > > - Tianocore needs to provide boot services to the OS, so needs to know
> > > the memory map, etc.
> > >
> > > ** At this point we want to use DT to pass the required information.
> > >
> > > Of course, Platform Init could be coreboot or Tianocore or some
> > > strange private binary. Payload could be U-Boot or something else.
> > > That is the point of this effort, to build interoperability.
>
> [...]
>
> > > Perhaps the problem here is that Linux has tied itself up in knots
> > > with its EFI stuff and DT fixups and what-not. But this is not that.
> > > It is a simple handoff between two pieces of firmware, Platform Init
> > > and Payload. It has nothing to do with the OS. With Tianocore they are
> > > typically combined, but with this usage they are split, and we can
> > > swap out one project for another on either side of the DT interface.
>
> Is perhaps the clearest description of the problem you want to solve.
> It's clearly related to EFI though not the interface to the OS. IIRC,
> "platform init" and "payload" are terms in the UEFI spec, right?

No they are not. This is from the universal payload specification that
is being drafted here

https://universalpayload.github.io/spec/index.html

but the UEFI specification does not use this terminology.

> I don't recall how well defined those are vs. just abstract concepts.
>
> Is it only for this interface or any firmware to firmware handoff. If
> the former, then I'm looking for folks involved with EFI/Tianocore to
> have some buy-in. If the latter, then this should be part of the
> firmware handoff efforts and have buy-in there.
>

I still haven't seen any example of how platform init would make
meaningful use of 'boot-code' and 'runtime-code' regions to inform a
payload about executable regions in memory. Especially 'runtime code'
is interesting here, as it presumably means that the OS must map such
regions as executable in some way. This is why I mentioned phandles in
a previous reply: there /must/ be some additional context provided
elsewhere, or the distinction between boot code/data and runtime
code/data is meaningless.

So again, can we *please* have an example of how these regions will be
used in practice?

> > > I do have views on the 'EFI' opt-out with reserved-memory, if you are
> > > interested, but that relates to the OS. If you are wanting to place
> > > some constraints on /reserved-memory and /memory we could do that
> > > e.g. that the DT and the map returned by EFI boot services must be
> > > consistent. But as it is, the nodes are ignored by the OS when booting
> > > with EFI, aren't they?
> >
> > Can this be applied, please? If there are further comments, please let me 
> > know.
>
> I really have limited knowledge and interest in this. I don't mind
> hosting something like this in dtschema, but I'm not taking it without
> buy-in from multiple parties which I haven't seen.
>

I will state again that I do not object to these bindings as long as
they are restricted to use in the context of firmware. However, there
is no scoping in DT schema as far as I am aware, which means that the
OS may be forced/expected to interpret these regions beyond simply
disregarding them and treating them as reserved memory, and *that* is
something I strongly object to.

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Rob Herring]

On Tue, Oct 31, 2023 at 10:56 AM Simon Glass  wrote:
>
> Hi Rob,
>
> On Mon, 16 Oct 2023 at 15:54, Simon Glass  wrote:
> >
> > Hi Rob,
> >
> > On Mon, 16 Oct 2023 at 10:50, Rob Herring  wrote:
> > >
> > > On Fri, Oct 13, 2023 at 4:09 PM Simon Glass  wrote:
> > > >
> > > > Hi Rob,
> > > >
> > > > On Fri, 13 Oct 2023 at 13:42, Rob Herring  wrote:
> > > > >
> > > > > On Fri, Oct 6, 2023 at 7:03 PM Simon Glass  wrote:
> > > > > >
> > > > > > Hi Ard,
> > > > > >
> > > > > > On Fri, 6 Oct 2023 at 17:00, Ard Biesheuvel  wrote:
> > > > > > >
> > > > > > > On Fri, 6 Oct 2023 at 20:17, Simon Glass  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hi Ard,
> > > > > > > >
> > > > > > > > On Fri, 6 Oct 2023 at 11:33, Ard Biesheuvel  
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > On Mon, 2 Oct 2023 at 19:54, Simon Glass  
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Rob,
> > > > > > > > > >
> > > > > > > > > > On Tue, 26 Sept 2023 at 13:42, Simon Glass 
> > > > > > > > > >  wrote:
> > > > > > > > > > >
> > > > > > > > > > > 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 
> > > > > > > > > > > ---
> > > > > > > > > > >
> > > > > > > > > > > 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)
> > > > > > > > > >
> > > > > > > > > > I am again checking on this series. Can it be applied, 
> > > > > > > > > > please?
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Apologies for the delay in response. I have been away.
> > > > > > > >
> > > > > > > > OK, I hope you had a nice trip.
> > > > > > > >
> > > > > > >
> > > > > > > Thanks, it was wonderful!
> > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 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 000..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 

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Simon Glass]

Hi,


On Tue, 31 Oct 2023 at 09:56, Simon Glass  wrote:
>
> Hi Rob,
>
> On Mon, 16 Oct 2023 at 15:54, Simon Glass  wrote:
> >
> > Hi Rob,
> >
> > On Mon, 16 Oct 2023 at 10:50, Rob Herring  wrote:
> > >
> > > On Fri, Oct 13, 2023 at 4:09 PM Simon Glass  wrote:
> > > >
> > > > Hi Rob,
> > > >
> > > > On Fri, 13 Oct 2023 at 13:42, Rob Herring  wrote:
> > > > >
> > > > > On Fri, Oct 6, 2023 at 7:03 PM Simon Glass  wrote:
> > > > > >
> > > > > > Hi Ard,
> > > > > >
> > > > > > On Fri, 6 Oct 2023 at 17:00, Ard Biesheuvel  wrote:
> > > > > > >
> > > > > > > On Fri, 6 Oct 2023 at 20:17, Simon Glass  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hi Ard,
> > > > > > > >
> > > > > > > > On Fri, 6 Oct 2023 at 11:33, Ard Biesheuvel  
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > On Mon, 2 Oct 2023 at 19:54, Simon Glass  
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Rob,
> > > > > > > > > >
> > > > > > > > > > On Tue, 26 Sept 2023 at 13:42, Simon Glass 
> > > > > > > > > >  wrote:
> > > > > > > > > > >
> > > > > > > > > > > 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 
> > > > > > > > > > > ---
> > > > > > > > > > >
> > > > > > > > > > > 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)
> > > > > > > > > >
> > > > > > > > > > I am again checking on this series. Can it be applied, 
> > > > > > > > > > please?
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Apologies for the delay in response. I have been away.
> > > > > > > >
> > > > > > > > OK, I hope you had a nice trip.
> > > > > > > >
> > > > > > >
> > > > > > > Thanks, it was wonderful!
> > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 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 000..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 

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Simon Glass]

Hi Rob,

On Mon, 16 Oct 2023 at 15:54, Simon Glass  wrote:
>
> Hi Rob,
>
> On Mon, 16 Oct 2023 at 10:50, Rob Herring  wrote:
> >
> > On Fri, Oct 13, 2023 at 4:09 PM Simon Glass  wrote:
> > >
> > > Hi Rob,
> > >
> > > On Fri, 13 Oct 2023 at 13:42, Rob Herring  wrote:
> > > >
> > > > On Fri, Oct 6, 2023 at 7:03 PM Simon Glass  wrote:
> > > > >
> > > > > Hi Ard,
> > > > >
> > > > > On Fri, 6 Oct 2023 at 17:00, Ard Biesheuvel  wrote:
> > > > > >
> > > > > > On Fri, 6 Oct 2023 at 20:17, Simon Glass  wrote:
> > > > > > >
> > > > > > > Hi Ard,
> > > > > > >
> > > > > > > On Fri, 6 Oct 2023 at 11:33, Ard Biesheuvel  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Mon, 2 Oct 2023 at 19:54, Simon Glass  
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Hi Rob,
> > > > > > > > >
> > > > > > > > > On Tue, 26 Sept 2023 at 13:42, Simon Glass 
> > > > > > > > >  wrote:
> > > > > > > > > >
> > > > > > > > > > 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 
> > > > > > > > > > ---
> > > > > > > > > >
> > > > > > > > > > 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)
> > > > > > > > >
> > > > > > > > > I am again checking on this series. Can it be applied, please?
> > > > > > > > >
> > > > > > > >
> > > > > > > > Apologies for the delay in response. I have been away.
> > > > > > >
> > > > > > > OK, I hope you had a nice trip.
> > > > > > >
> > > > > >
> > > > > > Thanks, it was wonderful!
> > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 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 000..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.
> > > > > > > > > > +
> > > > > > > 

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Simon Glass]

Hi Rob,

On Mon, 16 Oct 2023 at 10:50, Rob Herring  wrote:
>
> On Fri, Oct 13, 2023 at 4:09 PM Simon Glass  wrote:
> >
> > Hi Rob,
> >
> > On Fri, 13 Oct 2023 at 13:42, Rob Herring  wrote:
> > >
> > > On Fri, Oct 6, 2023 at 7:03 PM Simon Glass  wrote:
> > > >
> > > > Hi Ard,
> > > >
> > > > On Fri, 6 Oct 2023 at 17:00, Ard Biesheuvel  wrote:
> > > > >
> > > > > On Fri, 6 Oct 2023 at 20:17, Simon Glass  wrote:
> > > > > >
> > > > > > Hi Ard,
> > > > > >
> > > > > > On Fri, 6 Oct 2023 at 11:33, Ard Biesheuvel  wrote:
> > > > > > >
> > > > > > > On Mon, 2 Oct 2023 at 19:54, Simon Glass  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hi Rob,
> > > > > > > >
> > > > > > > > On Tue, 26 Sept 2023 at 13:42, Simon Glass  
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > 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 
> > > > > > > > > ---
> > > > > > > > >
> > > > > > > > > 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)
> > > > > > > >
> > > > > > > > I am again checking on this series. Can it be applied, please?
> > > > > > > >
> > > > > > >
> > > > > > > Apologies for the delay in response. I have been away.
> > > > > >
> > > > > > OK, I hope you had a nice trip.
> > > > > >
> > > > >
> > > > > Thanks, it was wonderful!
> > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > 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 000..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 
> > > > > > > > > +
> > > > > > > > > +allOf:
> > > > > > > > > +  - $ref: reserved-memory.yaml
> > > > > > > > > +
> > > > > > > > > +properties:
> > > > > > > > > +  compatible:
> > > > > > > > > +description: |
> > > > > > > > > +  This describes some 

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Rob Herring]

On Fri, Oct 13, 2023 at 4:09 PM Simon Glass  wrote:
>
> Hi Rob,
>
> On Fri, 13 Oct 2023 at 13:42, Rob Herring  wrote:
> >
> > On Fri, Oct 6, 2023 at 7:03 PM Simon Glass  wrote:
> > >
> > > Hi Ard,
> > >
> > > On Fri, 6 Oct 2023 at 17:00, Ard Biesheuvel  wrote:
> > > >
> > > > On Fri, 6 Oct 2023 at 20:17, Simon Glass  wrote:
> > > > >
> > > > > Hi Ard,
> > > > >
> > > > > On Fri, 6 Oct 2023 at 11:33, Ard Biesheuvel  wrote:
> > > > > >
> > > > > > On Mon, 2 Oct 2023 at 19:54, Simon Glass  wrote:
> > > > > > >
> > > > > > > Hi Rob,
> > > > > > >
> > > > > > > On Tue, 26 Sept 2023 at 13:42, Simon Glass  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > 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 
> > > > > > > > ---
> > > > > > > >
> > > > > > > > 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)
> > > > > > >
> > > > > > > I am again checking on this series. Can it be applied, please?
> > > > > > >
> > > > > >
> > > > > > Apologies for the delay in response. I have been away.
> > > > >
> > > > > OK, I hope you had a nice trip.
> > > > >
> > > >
> > > > Thanks, it was wonderful!
> > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > 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 000..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 
> > > > > > > > +
> > > > > > > > +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

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Simon Glass]

Hi Rob,

On Fri, 13 Oct 2023 at 13:42, Rob Herring  wrote:
>
> On Fri, Oct 6, 2023 at 7:03 PM Simon Glass  wrote:
> >
> > Hi Ard,
> >
> > On Fri, 6 Oct 2023 at 17:00, Ard Biesheuvel  wrote:
> > >
> > > On Fri, 6 Oct 2023 at 20:17, Simon Glass  wrote:
> > > >
> > > > Hi Ard,
> > > >
> > > > On Fri, 6 Oct 2023 at 11:33, Ard Biesheuvel  wrote:
> > > > >
> > > > > On Mon, 2 Oct 2023 at 19:54, Simon Glass  wrote:
> > > > > >
> > > > > > Hi Rob,
> > > > > >
> > > > > > On Tue, 26 Sept 2023 at 13:42, Simon Glass  
> > > > > > wrote:
> > > > > > >
> > > > > > > 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 
> > > > > > > ---
> > > > > > >
> > > > > > > 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)
> > > > > >
> > > > > > I am again checking on this series. Can it be applied, please?
> > > > > >
> > > > >
> > > > > Apologies for the delay in response. I have been away.
> > > >
> > > > OK, I hope you had a nice trip.
> > > >
> > >
> > > Thanks, it was wonderful!
> > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > 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 000..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 
> > > > > > > +
> > > > > > > +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 

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Rob Herring]

On Fri, Oct 6, 2023 at 7:03 PM Simon Glass  wrote:
>
> Hi Ard,
>
> On Fri, 6 Oct 2023 at 17:00, Ard Biesheuvel  wrote:
> >
> > On Fri, 6 Oct 2023 at 20:17, Simon Glass  wrote:
> > >
> > > Hi Ard,
> > >
> > > On Fri, 6 Oct 2023 at 11:33, Ard Biesheuvel  wrote:
> > > >
> > > > On Mon, 2 Oct 2023 at 19:54, Simon Glass  wrote:
> > > > >
> > > > > Hi Rob,
> > > > >
> > > > > On Tue, 26 Sept 2023 at 13:42, Simon Glass  wrote:
> > > > > >
> > > > > > 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 
> > > > > > ---
> > > > > >
> > > > > > 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)
> > > > >
> > > > > I am again checking on this series. Can it be applied, please?
> > > > >
> > > >
> > > > Apologies for the delay in response. I have been away.
> > >
> > > OK, I hope you had a nice trip.
> > >
> >
> > Thanks, it was wonderful!
> >
> > > >
> > > > >
> > > > > >
> > > > > > 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 000..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 
> > > > > > +
> > > > > > +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:
> > 

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Ard Biesheuvel]

On Sat, 7 Oct 2023 at 02:03, Simon Glass  wrote:
>
> Hi Ard,
>
> On Fri, 6 Oct 2023 at 17:00, Ard Biesheuvel  wrote:
> >
> > On Fri, 6 Oct 2023 at 20:17, Simon Glass  wrote:
> > >
> > > Hi Ard,
> > >
> > > On Fri, 6 Oct 2023 at 11:33, Ard Biesheuvel  wrote:
> > > >
> > > > On Mon, 2 Oct 2023 at 19:54, Simon Glass  wrote:
> > > > >
> > > > > Hi Rob,
> > > > >
> > > > > On Tue, 26 Sept 2023 at 13:42, Simon Glass  wrote:
> > > > > >
> > > > > > 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 
> > > > > > ---
> > > > > >
> > > > > > 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)
> > > > >
> > > > > I am again checking on this series. Can it be applied, please?
> > > > >
> > > >
> > > > Apologies for the delay in response. I have been away.
> > >
> > > OK, I hope you had a nice trip.
> > >
> >
> > Thanks, it was wonderful!
> >
> > > >
> > > > >
> > > > > >
> > > > > > 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 000..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 
> > > > > > +
> > > > > > +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:
> > > 

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Simon Glass]

Hi all,

On Fri, 6 Oct 2023 at 18:03, Simon Glass  wrote:
>
> Hi Ard,
>
> On Fri, 6 Oct 2023 at 17:00, Ard Biesheuvel  wrote:
> >
> > On Fri, 6 Oct 2023 at 20:17, Simon Glass  wrote:
> > >
> > > Hi Ard,
> > >
> > > On Fri, 6 Oct 2023 at 11:33, Ard Biesheuvel  wrote:
> > > >
> > > > On Mon, 2 Oct 2023 at 19:54, Simon Glass  wrote:
> > > > >
> > > > > Hi Rob,
> > > > >
> > > > > On Tue, 26 Sept 2023 at 13:42, Simon Glass  wrote:
> > > > > >
> > > > > > 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 
> > > > > > ---
> > > > > >
> > > > > > 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)
> > > > >
> > > > > I am again checking on this series. Can it be applied, please?
> > > > >
> > > >
> > > > Apologies for the delay in response. I have been away.
> > >
> > > OK, I hope you had a nice trip.
> > >
> >
> > Thanks, it was wonderful!
> >
> > > >
> > > > >
> > > > > >
> > > > > > 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 000..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 
> > > > > > +
> > > > > > +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
> > > > > > +
> > > > > > +

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Simon Glass]

Hi Ard,

On Fri, 6 Oct 2023 at 17:00, Ard Biesheuvel  wrote:
>
> On Fri, 6 Oct 2023 at 20:17, Simon Glass  wrote:
> >
> > Hi Ard,
> >
> > On Fri, 6 Oct 2023 at 11:33, Ard Biesheuvel  wrote:
> > >
> > > On Mon, 2 Oct 2023 at 19:54, Simon Glass  wrote:
> > > >
> > > > Hi Rob,
> > > >
> > > > On Tue, 26 Sept 2023 at 13:42, Simon Glass  wrote:
> > > > >
> > > > > 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 
> > > > > ---
> > > > >
> > > > > 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)
> > > >
> > > > I am again checking on this series. Can it be applied, please?
> > > >
> > >
> > > Apologies for the delay in response. I have been away.
> >
> > OK, I hope you had a nice trip.
> >
>
> Thanks, it was wonderful!
>
> > >
> > > >
> > > > >
> > > > > 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 000..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 
> > > > > +
> > > > > +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
> > > > > +
> > >
> > > As I mentioned a few times already, I don't think these compatibles
> > > should be introduced here.
> > >
> > > A reserved region has a 

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Ard Biesheuvel]

On Fri, 6 Oct 2023 at 20:17, Simon Glass  wrote:
>
> Hi Ard,
>
> On Fri, 6 Oct 2023 at 11:33, Ard Biesheuvel  wrote:
> >
> > On Mon, 2 Oct 2023 at 19:54, Simon Glass  wrote:
> > >
> > > Hi Rob,
> > >
> > > On Tue, 26 Sept 2023 at 13:42, Simon Glass  wrote:
> > > >
> > > > 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 
> > > > ---
> > > >
> > > > 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)
> > >
> > > I am again checking on this series. Can it be applied, please?
> > >
> >
> > Apologies for the delay in response. I have been away.
>
> OK, I hope you had a nice trip.
>

Thanks, it was wonderful!

> >
> > >
> > > >
> > > > 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 000..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 
> > > > +
> > > > +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
> > > > +
> >
> > As I mentioned a few times already, I don't think these compatibles
> > should be introduced here.
> >
> > A reserved region has a specific purpose, and the compatible should be
> > more descriptive than the enum above. If the consumer does not
> > understand this purpose, it should simply treat the memory as reserved
> > and not touch it. Alternatively, these regions can be referenced from
> > other DT nodes using phandles if needed.
>
> We still need some description of what these regions are used for, 

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Simon Glass]

Hi Ard,

On Fri, 6 Oct 2023 at 11:33, Ard Biesheuvel  wrote:
>
> On Mon, 2 Oct 2023 at 19:54, Simon Glass  wrote:
> >
> > Hi Rob,
> >
> > On Tue, 26 Sept 2023 at 13:42, Simon Glass  wrote:
> > >
> > > 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 
> > > ---
> > >
> > > 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)
> >
> > I am again checking on this series. Can it be applied, please?
> >
>
> Apologies for the delay in response. I have been away.

OK, I hope you had a nice trip.

>
> >
> > >
> > > 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 000..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 
> > > +
> > > +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
> > > +
>
> As I mentioned a few times already, I don't think these compatibles
> should be introduced here.
>
> A reserved region has a specific purpose, and the compatible should be
> more descriptive than the enum above. If the consumer does not
> understand this purpose, it should simply treat the memory as reserved
> and not touch it. Alternatively, these regions can be referenced from
> other DT nodes using phandles if needed.

We still need some description of what these regions are used for, so
that the payload can use the correct regions. I do not have any other
solution to this problem. We are in v7 at present. At least explain
where you want the compatible strings to be introduced.

What sort of extra detail are you looking for? Please be specific and
preferably add some suggestions so I can close this out ASAP.

>
>
> > > +  reg:
> > > +description: 

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Ard Biesheuvel]

On Mon, 2 Oct 2023 at 19:54, Simon Glass  wrote:
>
> Hi Rob,
>
> On Tue, 26 Sept 2023 at 13:42, Simon Glass  wrote:
> >
> > 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 
> > ---
> >
> > 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)
>
> I am again checking on this series. Can it be applied, please?
>

Apologies for the delay in response. I have been away.

>
> >
> > 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 000..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 
> > +
> > +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
> > +

As I mentioned a few times already, I don't think these compatibles
should be introduced here.

A reserved region has a specific purpose, and the compatible should be
more descriptive than the enum above. If the consumer does not
understand this purpose, it should simply treat the memory as reserved
and not touch it. Alternatively, these regions can be referenced from
other DT nodes using phandles if needed.


> > +  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@1234 {
> > +compatible = "boot-code";
> > +reg = <0x1234 0x0080>;
> > +};
> > +
> > +reserved@4321 {
> > +compatible = "boot-data";
> > +reg = <0x4321 0x0080>;
> > +};
> > +};
> > --
> > 2.42.0.515.g380fc7ccd1-goog
> >
>
> Regards,
> Simon

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Simon Glass]

Hi Rob,

On Tue, 26 Sept 2023 at 13:42, Simon Glass  wrote:
>
> 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 
> ---
>
> 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)

I am again checking on this series. Can it be applied, please?


>
> 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 000..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 
> +
> +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@1234 {
> +compatible = "boot-code";
> +reg = <0x1234 0x0080>;
> +};
> +
> +reserved@4321 {
> +compatible = "boot-data";
> +reg = <0x4321 0x0080>;
> +};
> +};
> --
> 2.42.0.515.g380fc7ccd1-goog
>

Regards,
Simon