Re: [PATCH v3 1/2] schemas: Add a schema for memory map

From: Mark Rutland
Date: Wed Aug 23 2023 - 05:07:18 EST


On Tue, Aug 22, 2023 at 02:34:42PM -0600, Simon Glass wrote:
> The Devicetree specification skips over handling of a logical view of
> the memory map, pointing users to the UEFI specification.
>
> 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.

Today Linux does that by passing:

/chosen/linux,uefi-mmap-start
/chosen/linux,uefi-mmap-size
/chosen/linux,uefi-mmap-desc-size
/chosen/linux,uefi-mmap-desc-ver

... or /chosen/xen,* variants of those.

Can't we document / genericise that?

Pointing to that rather than re-encoding it in DT means that it stays in-sync
with the EFI spec and we won't back ourselves into a corner where we cannot
encode something due to a structural difference. I don't think it's a good idea
to try to re-encode it, or we're just setting ourselves up for futher pain.

Thanks,
Mark.

>
> This aims to provide an initial schema for this mapping.
>
> Note that this is separate from the existing /memory and /reserved-memory
> nodes, since it is mostly concerned with what the memory is used for. It
> may cover only a small fraction of available memory.
>
> For now, no attempt is made to create an exhaustive binding, so there are
> some example types listed. This can be completed once this has passed
> initial review.
>
> This binding does not include a binding for the memory 'attribute'
> property, defined by EFI_BOOT_SERVICES.GetMemoryMap(). It may be useful
> to have that as well, but perhaps not as a bit mask.
>
> Signed-off-by: Simon Glass <sjg@xxxxxxxxxxxx>
> ---
>
> 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
>
> dtschema/schemas/memory-map.yaml | 61 ++++++++++++++++++++++++++++++++
> 1 file changed, 61 insertions(+)
> create mode 100644 dtschema/schemas/memory-map.yaml
>
> diff --git a/dtschema/schemas/memory-map.yaml b/dtschema/schemas/memory-map.yaml
> new file mode 100644
> index 0000000..4b06583
> --- /dev/null
> +++ b/dtschema/schemas/memory-map.yaml
> @@ -0,0 +1,61 @@
> +# SPDX-License-Identifier: BSD-2-Clause
> +# Copyright 2023 Google LLC
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/memory-map.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: /memory-map nodes
> +description: |
> + Common properties always required in /memory-map nodes. These nodes are
> + intended to resolve the nonchalant clause 3.4.1 ("/memory node and UEFI")
> + in the Devicetree Specification.
> +
> +maintainers:
> + - Simon Glass <sjg@xxxxxxxxxxxx>
> +
> +properties:
> + $nodename:
> + const: 'memory-map'
> +
> +patternProperties:
> + "^([a-z][a-z0-9\\-]+@[0-9a-f]+)?$":
> + type: object
> + additionalProperties: false
> +
> + properties:
> + reg:
> + minItems: 1
> + maxItems: 1024
> +
> + usage:
> + $ref: /schemas/types.yaml#/definitions/string
> + description: |
> + Describes the usage of the memory region, e.g.:
> +
> + "acpi-reclaim", "acpi-nvs", "bootcode", "bootdata", "bootdata",
> + "runtime-code", "runtime-data".
> +
> + See enum EFI_MEMORY_TYPE in "Unified Extensible Firmware Interface
> + (UEFI) Specification" for all the types. For now there are not
> + listed here.
> +
> + required:
> + - reg
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + memory-map {
> + acpi@f0000 {
> + reg = <0xf0000 0x4000>;
> + usage = "acpi-reclaim";
> + };
> +
> + runtime@12300000 {
> + reg = <0x12300000 0x28000>;
> + usage = "runtime-code";
> + };
> + };
> +...
> --
> 2.42.0.rc1.204.g551eb34607-goog
>