Imported from linux kernel source:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Doc…
Very minor editorial changes made while importing, with one exception.
Added clause that the 'no-map' and 'reusable' properties are mutually
exclusive.
Signed-off-by: Grant Likely <grant.likely(a)arm.com>
Cc: Rob Herring <robh(a)kernel.org>
Cc: Heinrich Schuchardt <xypron.glpk(a)gmx.de>
Cc: Ard Biesheuvel <ardb(a)kernel.org>
---
source/chapter3-devicenodes.rst | 199 ++++++++++++++++++++++++++++++++
1 file changed, 199 insertions(+)
diff --git a/source/chapter3-devicenodes.rst b/source/chapter3-devicenodes.rst
index 3aa4650..1c1149a 100644
--- a/source/chapter3-devicenodes.rst
+++ b/source/chapter3-devicenodes.rst
@@ -200,6 +200,205 @@ memory ranges. The 2 GB I/O region is skipped. Note that the
value of 2, which means that two 32-bit cells are required to define the
address and length for the ``reg`` property of the memory node.
+``/reserved-memory`` Node
+-------------------------
+
+Reserved memory is specified as a node under the ``/reserved-memory`` node.
+The operating system shall exclude reserved memory from normal usage
+one can create child nodes describing particular reserved (excluded from
+normal use) memory regions.
+Such memory regions are usually designed for the special usage by various
+device drivers.
+
+Parameters for each memory region can be encoded into the device tree
+with the following nodes:
+
+/reserved-memory parent node
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. tabularcolumns:: | p{4cm} p{0.75cm} p{4cm} p{6.5cm} |
+.. table:: /reserved-memory Parent Node Properties
+
+ =================== ===== ================= ===============================================
+ Property Name Usage Value Type Definition
+ =================== ===== ================= ===============================================
+ ``#address-cells`` R ``<u32>`` Specifies the number of ``<u32>`` cells to
+ represent the address in the ``reg`` property in
+ children of root.
+ ``#size-cells`` R ``<u32>`` Specifies the number of ``<u32>`` cells to
+ represent the size in the ``reg`` property in
+ children of root.
+ ``ranges`` R ``<prop encoded This property represents the mapping between
+ array>`` parent address to child address spaces (see
+ section :ref:`sect-standard-properties-ranges`,
+ ranges).
+ Usage legend: R=Required, O=Optional, OR=Optional but Recommended, SD=See Definition
+ ===========================================================================================
+
+``#address-cells`` and ``#size-cells`` should use the same values as for the root node,
+and ``ranges`` should be empty so that address translation logic works correctly.
+
+/reserved-memory/ child nodes
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Each child of the reserved-memory node specifies one or more regions of
+reserved memory. Each child node may either use a ``reg`` property to
+specify a specific range of reserved memory, or a ``size`` property with
+optional constraints to request a dynamically allocated block of memory.
+
+Following the generic-names recommended practice, node names should
+reflect the purpose of the node (ie. "*framebuffer*" or "*dma-pool*").
+Unit address (``@<address>``) should be appended to the name if the node
+is a static allocation.
+
+A reserved memory node requires either a ``reg`` property for static
+allocations, or a ``size`` property for dynamics allocations.
+Dynamic allocations may use ``alignment`` and ``alloc-ranges`` properties
+to constrain where the memory is allocated from.
+If both ``reg`` and ``size`` are present, then the region is treated as a
+static allocation with the ``reg`` property taking precedence and ``size``
+is ignored.
+
+.. tabularcolumns:: | p{4cm} p{0.75cm} p{4cm} p{6.5cm} |
+.. table:: ``/reserved-memory/`` Child Node Properties
+
+ ======================= ===== ========================= ===============================================
+ Property Name Usage Value Type Definition
+ ======================= ===== ========================= ===============================================
+ ``reg`` O ``<prop-encoded-array>`` Consists of an arbitrary number of address and
+ size pairs that specify the physical address
+ and size of the memory ranges.
+ ``size`` O ``<prop-encoded-array>`` Size in bytes of memory to reserve for
+ dynamically allocated regions.
+ Size of this property is based on parent node's
+ ``#size-cells`` property.
+ ``alignment`` O ``<prop-encoded-array>`` Address boundary for alignment of allocation.
+ Size of this property is based on parent node's
+ ``#size-cells`` property.
+ ``alloc-ranges`` O ``<prop-encoded-array>`` Specifies regions of memory that are acceptable
+ to allocate from.
+ Format is (address, length pairs) tuples in
+ same format as for ``reg`` properties.
+ ``compatible`` O ``<stringlist>`` May contain the following strings:
+
+ - ``shared-dma-pool``: This indicates a region of
+ memory meant to be used as a shared pool of DMA
+ buffers for a set of devices.
+ It can be used by an operating system to
+ instantiate the necessary pool management
+ subsystem if necessary.
+
+ - vendor specific string in the form
+ ``<vendor>,[<device>-]<usage>``
+ ``no-map`` O ``<empty>`` If present, indicates the operating system must
+ not create a virtual mapping of the region as
+ part of its standard mapping of system memory,
+ nor permit speculative access to it under any
+ circumstances other than under the control of
+ the device driver using the region.
+ ``reusable`` O ``<empty>`` The operating system can use the memory in this
+ region with the limitation that the device
+ driver(s) owning the region need to be able to
+ reclaim it back.
+ Typically that means that the operating system
+ can use that region to store volatile or cached
+ data that can be otherwise regenerated or
+ migrated elsewhere.
+ Usage legend: R=Required, O=Optional, OR=Optional but Recommended, SD=See Definition
+ =======================================================================================================
+
+.. note:: All other standard properties (section
+ :ref:`sect-standard-properties`) are allowed but are optional.
+
+The ``no-map`` and ``reusable`` properties are mutually exclusive and both must
+not be used together in the same node.
+
+Linux implementation notes:
+
+- If a ``linux,cma-default`` property is present, then Linux will use the
+ region for the default pool of the contiguous memory allocator.
+
+- If a ``linux,dma-default`` property is present, then Linux will use the
+ region for the default pool of the consistent DMA allocator.
+
+Device node references to reserved memory
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Regions in the ``/reserved-memory`` node may be referenced by other device
+nodes by adding a ``memory-region`` property to the device node.
+
+.. tabularcolumns:: | p{4cm} p{0.75cm} p{4cm} p{6.5cm} |
+.. table:: ``Properties for referencing reserved-memory regions
+
+ ======================= ===== ========================= ===============================================
+ Property Name Usage Value Type Definition
+ ======================= ===== ========================= ===============================================
+ ``memory-region`` O ``<prop-encoded-array>`` phandle, specifier pairs to children of
+ ``/reserved-memory``
+ ``memory-region-names`` O ``<stringlist>>`` A list of names, one for each corresponding
+ entry in the ``memory-region`` property
+ =======================================================================================================
+
+Example
+~~~~~~~
+
+This example defines 3 contiguous regions are defined for Linux kernel:
+one default of all device drivers (named ``linux,cma@72000000`` and 64MiB in size),
+one dedicated to the framebuffer device (named ``framebuffer@78000000``, 8MiB), and
+one for multimedia processing (named ``multimedia-memory@77000000``, 64MiB).
+
+.. code-block:: dts
+
+ / {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ memory {
+ reg = <0x40000000 0x40000000>;
+ };
+
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ /* global autoconfigured region for contiguous allocations */
+ linux,cma {
+ compatible = "shared-dma-pool";
+ reusable;
+ size = <0x4000000>;
+ alignment = <0x2000>;
+ linux,cma-default;
+ };
+
+ display_reserved: framebuffer@78000000 {
+ reg = <0x78000000 0x800000>;
+ };
+
+ multimedia_reserved: multimedia@77000000 {
+ compatible = "acme,multimedia-memory";
+ reg = <0x77000000 0x4000000>;
+ };
+ };
+
+ /* ... */
+
+ fb0: video@12300000 {
+ memory-region = <&display_reserved>;
+ /* ... */
+ };
+
+ scaler: scaler@12500000 {
+ memory-region = <&multimedia_reserved>;
+ /* ... */
+ };
+
+ codec: codec@12600000 {
+ memory-region = <&multimedia_reserved>;
+ /* ... */
+ };
+ };
+
``/chosen`` Node
----------------
--
2.20.1
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Closes: #52
The no-map property of the /reserved-memory device tree nodes is used to
signal that a memory region shall not be accessed by the operating system,
even not via speculative access.
/reserved-memory nodes without the no-map property describe memory that
have special usage by the operating system.
This difference has to be reflected in the memory map returned by
GetMemoryMap().
Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de>
---
source/chapter2-uefi.rst | 13 +++++++++++++
source/references.rst | 4 ++++
2 files changed, 17 insertions(+)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
index 74ef70e..f410c57 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -74,6 +74,19 @@ that virtual addresses must equal physical addresses.
The default RAM allocated attribute must be EFI_MEMORY_WB.
+In the device tree reserved memory in modelled as a /reserved-memory nodes
+[RESMEM]_. The reserved-memory node MAY carry either the no-map or the resue
+property. It MUST NOT carry both properties as this would be contradictary.
+
+A 'no-map' reserved memory node describes memory that the UEFI payload MUST NOT
+access. It MUST be modelled as a EfiReservedMemoryType entry in the memory map.
+
+A reserved memory without the 'no-map' describes memory that MAY be used by the
+UEFI payload after ExitBootServices(). It MUST be modelled as a memory map entry
+that can only be used by the UEFI payload after ExitBootServices(). It
+is recommended to use EfiBootServicesData. The node MUST NOT be modelled as
+EfiReservedMemoryType and NOT as EfiConventionalMemory.
+
Configuration Tables
--------------------
diff --git a/source/references.rst b/source/references.rst
index 1eb0509..2434137 100644
--- a/source/references.rst
+++ b/source/references.rst
@@ -16,6 +16,10 @@
<https://static.docs.arm.com/den0022/c/DEN0022C_Power_State_Coordination_Int…>`_
30 January 2015, `Arm Limited <http://arm.com>`_
+.. [RESMEM] `Reserved memory regions
+ <https://www.kernel.org/doc/Documentation/devicetree/bindings/reserved-memor…>`_,
+ 21 July 2020, Linux kernel
+
.. [SBBR] `Arm Server Base Boot Requirements specification Issue B (v1.0)
<https://static.docs.arm.com/den0044/b/DEN0044B_Server_Base_Boot_Requirement…>`_
8 March 2016, `Arm Limited <http://arm.com>`_
--
2.28.0
The existing language around how firmware and an OS can share a storage
device doesn't go into sufficient detail on how the firmware should
protect firmware data on the device. Add language for both the GPT and
MBR partitioning schemes on how firmware images should be described in
the partition table.
Signed-off-by: Grant Likely <grant.likely(a)arm.com>
---
I posted this patch before the v1.0.1 release, but didn't merge it at
that time because it needs a little more due diligence than can be give
on a minor point release. Posting it now for proper review.
source/chapter4-firmware-media.rst | 67 +++++++++++++++++++++++-------
1 file changed, 51 insertions(+), 16 deletions(-)
diff --git a/source/chapter4-firmware-media.rst b/source/chapter4-firmware-media.rst
index fc71274..65da603 100644
--- a/source/chapter4-firmware-media.rst
+++ b/source/chapter4-firmware-media.rst
@@ -47,13 +47,19 @@ conflict with normal usage of the media by an OS.
Partitioning of Shared Storage
==============================
-A shared storage device shall use GPT partitioning unless it is incompatible
-with the platform boot sequence.
-In which case, MBR partitioning shall be used. [#MBRReqExample]_
-
-.. [#MBRReqExample] For example, if the boot ROM doesn't understand GPT
- partitioning, and will only work with an MBR, then the storage must be
- partitioned using an MBR.
+The shared storage device must use the GUID Partition Table (GPT) disk
+layout as defined in [UEFI]_ § 5.3, unless the platform boot sequence is
+fundamentally incompatible with the GPT disk layout.
+In which case, a legacy Master Boot Recored (MBR) must be used.
+[#MBRReqExample]_
+
+.. [#MBRReqExample] For example, if the SoC boot ROM requires an MBR to
+ find the next stage firmware image, then it is incompatible with
+ the GPT boot layout.
+ Similarly, if the boot ROM expects the next stage firmware to be located
+ at LBA1 (the location of the GPT Header), then it is incompatible with
+ the GPT disk layout.
+ In both cases the shared storage device must use legacy MBR partitioning.
.. warning::
@@ -71,15 +77,14 @@ the partition(s) containing firmware.
However, some SoCs load firmware from a fixed offset into the storage media.
In this case, to protect against partitioning tools overwriting firmware, the
-firmware image shall either reside entirely within the first 1MiB of storage,
-or should be covered by a protective partition entry in the partition table as
+partition table must be formed in a way to protect the firmware image(s) as
described in sections :ref:`section-gpt-parts` and :ref:`section-mbr-parts`.
-Automatic partitioning tools (e.g. an OS installer) must not create
-partitions within the first 1MiB of storage, or delete, move, or modify
-protective partition entries.
+Automatic partitioning tools (e.g. an OS installer) must not
+delete the protective information in the partition table, or
+delete, move, or modify protective partition entries.
Manual partitioning tools should provide warnings when modifying
-protective partitions or creating partitions within the first 1MiB.
+protective partitions.
.. warning::
@@ -95,19 +100,49 @@ GPT partitioning
----------------
The partition table must strictly conform to the UEFI specification and include
-a protective MBR authored exactly as described in [UEFI]_ § 5 (hybrid
+a protective MBR authored exactly as described in [UEFI]_ § 5.3 (hybrid
partitioning schemes are not permitted).
-Protective partitions must have the Platform Required Attribute Flag set.
+Fixed-location firmware images must be protected by creating protective
+partition entries, or by placing GPT data structures away from the LBAs
+occupied by firmware,
+
+Protective partitions are entries in the partition table that cover the
+LBA region occupied by firmware and have the 'Required Partition' attribute
+set.
+A protective partition must use a `PartitionTypeGUID` that identifies it
+as a firmware protective partition. (e.g., don't reuse a GUID used by
+non-protective partitions).
+There are no requirements on the contents or layout of the firmware
+protective partition.
+
+Placing GPT data structures away from firmware images can be accomplished by
+adjusting the GUID Partition Entry array location
+(adjusting the values of `PartitionEntryLBA` and `NumberOfPartitionEntries`,
+and `SizeOfPartitionEntry`),
+or by specifying the usable LBAs (Choosing `FirstUsableLBA`/`LastUsableLBA`
+to not overlap the fixed firmware location).
+See [UEFI]_ § 5.3.2.
+
+Given the choice, platforms should use protective partitions over
+adjusting the placement of GPT data structures because protective partitions
+provide explicit information about the protected region.
.. _section-mbr-parts:
MBR partitioning
^^^^^^^^^^^^^^^^
-Protective partitions should have a partition type of 0xF8 unless some
+If firmware is at a fixed location entirely within the first 1MiB of
+storage (<= LBA2047) then no protective partitions are required.
+If firmware resides in a fixed location outside the first 1MiB,
+then a protective partition must be used to cover the firmware LBAs.
+Protective partitions should have a partition type of 0xF8 unless an
immutable feature of the platform makes this impossible.
+OS partitioning tools must not create partitions in the first 1MiB
+of the storage device, and must not remove protective partitions.
+
.. _section-fw-partition-fs:
Firmware Partition Filesystem
--
2.20.1
Define the meanings of "MUST" and similar language for clarity.
Fixes: #46
Signed-off-by: Daniel Thompson <daniel.thompson(a)linaro.org>
---
source/chapter1-about.rst | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst
index 3744d8a14086..3b5339a9c202 100644
--- a/source/chapter1-about.rst
+++ b/source/chapter1-about.rst
@@ -171,6 +171,10 @@ UEFI § 6.1 - Reference to the UEFI specification [UEFI]_ section 6.1
Terms and abbreviations
=======================
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+document are to be interpreted as described in :rfc:`2119`.
+
This document uses the following terms and abbreviations.
.. glossary::
--
2.25.4
Closes: #52
The no-map property of the /reserved-memory DT node is used by Linux to
signal that a memory region shall not be mapped and that speculative access
shall not be permitted.
The memory map returned by GetMemoryMap() does not have a flag
corresponding to no-map. So the closest thing we can do is not to include
no-map reserved memory into the map returned by GetMemoryMap().
Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de>
---
source/chapter2-uefi.rst | 4 ++++
source/references.rst | 4 ++++
2 files changed, 8 insertions(+)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
index 2add2de..1e57164 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -74,6 +74,10 @@ that virtual addresses must equal physical addresses.
The default RAM allocated attribute must be EFI_MEMORY_WB.
+Reserved memory with property no-map [RESMEM]_ in the /reserved-memory
+device-tree node shall not be included in the memory map returned by
+GetMemoryMap().
+
Configuration Tables
--------------------
diff --git a/source/references.rst b/source/references.rst
index 1eb0509..2434137 100644
--- a/source/references.rst
+++ b/source/references.rst
@@ -16,6 +16,10 @@
<https://static.docs.arm.com/den0022/c/DEN0022C_Power_State_Coordination_Int…>`_
30 January 2015, `Arm Limited <http://arm.com>`_
+.. [RESMEM] `Reserved memory regions
+ <https://www.kernel.org/doc/Documentation/devicetree/bindings/reserved-memor…>`_,
+ 21 July 2020, Linux kernel
+
.. [SBBR] `Arm Server Base Boot Requirements specification Issue B (v1.0)
<https://static.docs.arm.com/den0044/b/DEN0044B_Server_Base_Boot_Requirement…>`_
8 March 2016, `Arm Limited <http://arm.com>`_
--
2.28.0
Early in EBBR discussions the decision was made that firmware should not
provide both DT and ACPI at the same time. The reasoning had been that
we didn't want to encourage 'hybrid' approaches where the OS tries to
consume both DT and ACPI descriptions.
However, this fear has not so-far born out, and feedback has been that
requiring a boot-time switch to select either DT or ACPI is a support
issue for OS vendors. They would rather see ACPI (or DT) always turned
on if it is an option and the OS can choose to use it or not.
Thoughts? Can the exclusive or be relaxed here?
Signed-off-by: Grant Likely <grant.likely(a)arm.com>
---
source/chapter2-uefi.rst | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
index 066fefb..e0e71d6 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -80,18 +80,12 @@ Configuration Tables
A UEFI system that complies with this specification may provide the additional
tables via the EFI Configuration Table.
-Compliant systems are required to provide one, but not both, of the following
+Compliant systems are required to provide at least one of the following
tables:
- an Advanced Configuration and Power Interface [ACPI]_ table, or
- a Devicetree [DTSPEC]_ system description
-EBBR systems must not provide both ACPI and Devicetree
-tables at the same time.
-Systems that support both interfaces must provide a configuration
-mechanism to select either ACPI or Devicetree,
-and must ensure only the selected interface is provided to the OS loader.
-
Devicetree
^^^^^^^^^^
--
2.20.1
On Tue, 1 Sep 2020, François Ozog via System-dt wrote:
> On Tue, 1 Sep 2020 at 14:49, Tomas Evensen <tomase(a)xilinx.com> wrote:
> Here are some brief notes from the meeting.
>
> If nothing else as a showcase on how much we miss Nathalie when she is on vacation 😉
>
> Krzysztof Kepa – GE
> Mathieu Poirier – Linaro
> Etsam Anjum – Mentor
> Anrnoud Pouliquen – ST
> Loic Pallardy - ST
> Suman Anna - TI
> Dan Milea – Wind River
> Mark Dapoz – Wind River
> Tomas Evensen – Xilinx
> Stefano Stabellini – Xilinx
> Bruce Ashfield – Xilinx
> Ed Mooring – Xilinx
> Ben Levinsky - Xilinx
>
> Stefano went through slides.
> Overall idea:
>
> 1. Specify remoteproc channels with minimal information in System-DT in a way that is as common as possible for all vendors.
> In particular, we are avoiding to have to specify the same memory regions in more than one place. A resource group is specially
> marked to contain most information.
> 2. Use Lopper to create the vendor specific remoteproc specification
> Generating reserved-memory, etc. information that has duplicate information.
> For the time being, no plans to unify the vendor specific information that goes into the traditional device tree for Linux
> 3. Later (or in parallel), but without making it a gating item, start discussions on what we can do to unify the vendor
> specific information in the traditional DT
>
> Discussion about how TI and ST might generate their specific information from this specification.
>
> Stefano to send out examples and slides.
> Ben: Xilinx backend to Lopper is upstreamed and available as an example. Might change as upstreaming continues.
>
> Question:
> * How do we configure VirtIO?
>
> Could you describe more the VirtIO question so that relationship with Linaro project Stratos is assessed?
I think this point refers to various vdev<x> buffers described under
/reserved-memory which are linked from RemoteProc. From the Xilinx
bindings:
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
ranges;
rpu0vdev0vring0: rpu0vdev0vring0@3ed40000 {
compatible = "xilinx,openamp-ipc-1.0";
no-map;
reg = <0x3ed40000 0x4000>;
};
rpu0vdev0vring1: rpu0vdev0vring1@3ed44000 {
compatible = "xilinx,openamp-ipc-1.0";
no-map;
reg = <0x3ed44000 0x4000>;
};
rpu0vdev0buffer: rpu0vdev0buffer@3ed48000 {
compatible = "xilinx,openamp-ipc-1.0";
no-map;
reg = <0x3ed48000 0x100000>;
};
rproc_0_reserved: rproc@3ed000000 {
compatible = "xilinx,openamp-ipc-1.0";
no-map;
reg = <0x3ed00000 0x40000>;
};
};
hi,
I am currently working on adding support for the capsule authentication in
the SetImage function of the efi firmware management protocol in u-boot.
This work is part of adding functionality in u-boot for firmware updates
using the uefi capsule format.
The capsule authentication is done using a public key stored as a pkcs7
certificate. The uefi specification does not have any mention of how this
certificate needs to be stored. This is unlike the case of the certificates
used for image authentication when UEFI secure boot feature is enabled,
where the certificates and hash values are stored as part of the
authenticated variables like KEK, db, dbx.
Can we use an authenticated variable like KEK to store the certificate used
for authentication of the capsule payload. Would it make sense to have this
mentioned in EBBR, or even the UEFI specification. Please let me know your
thoughts. Thanks.
-sughosh
Here are some brief notes from the meeting.
If nothing else as a showcase on how much we miss Nathalie when she is on vacation 😉
Krzysztof Kepa – GE
Mathieu Poirier – Linaro
Etsam Anjum – Mentor
Anrnoud Pouliquen – ST
Loic Pallardy - ST
Suman Anna - TI
Dan Milea – Wind River
Mark Dapoz – Wind River
Tomas Evensen – Xilinx
Stefano Stabellini – Xilinx
Bruce Ashfield – Xilinx
Ed Mooring – Xilinx
Ben Levinsky - Xilinx
Stefano went through slides.
Overall idea:
1. Specify remoteproc channels with minimal information in System-DT in a way that is as common as possible for all vendors.
In particular, we are avoiding to have to specify the same memory regions in more than one place. A resource group is specially marked to contain most information.
2. Use Lopper to create the vendor specific remoteproc specification
Generating reserved-memory, etc. information that has duplicate information.
For the time being, no plans to unify the vendor specific information that goes into the traditional device tree for Linux
3. Later (or in parallel), but without making it a gating item, start discussions on what we can do to unify the vendor specific information in the traditional DT
Discussion about how TI and ST might generate their specific information from this specification.
Stefano to send out examples and slides.
Ben: Xilinx backend to Lopper is upstreamed and available as an example. Might change as upstreaming continues.
Question:
* How do we configure VirtIO?
From: nathalie(a)xilinx.com
When: 8:00 AM - 9:00 AM August 31, 2020
Subject: [System-dt] System DT call: OpenAMP bindings
Location: webex
CAUTION: This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email.
Hi all,
The OpenAMP-remoteproc working group is looking forward to discuss OpenAMP bindings with the System DT working group & all others interested in System DT.
Best regards,
Nathalie C. Chan King Choy
Program Manager focused on Open Source & Community
Meeting number (access code): 145 853 2028
Meeting password: NgTwf4r8R$3
Monday, August 31, 2020
8:00 am | (UTC-07:00) Pacific Time (US & Canada) | 1 hr
Join meeting<https://xilinx.webex.com/xilinx/j.php?MTID=mcd4ad9bca009dfef38671c26d5a1d301>
Canada toll free 1-844-426-4405
France toll free 0800-912-485
India toll free 000-800-040-1016
Sweden toll free 020-033-6721
UK toll free 08000315372
United States Toll Free 1-844-621-3956
Global call-in numbers<https://xilinx.webex.com/xilinx/globalcallin.php?MTID=m370fae0984a8792a3592…> | Toll-free calling restrictions<https://www.webex.com/pdf/tollfree_restrictions.pdf>
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
Closes: #50
ResetSystem() has return type void. So it cannot return EFI_UNSUPPORTED.
Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de>
---
source/chapter2-uefi.rst | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
index 2add2de..74ef70e 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -209,9 +209,10 @@ ResetSystem() is required to be implemented in boot services, but it is
optional for runtime services.
During runtime services, the operating system should first attempt to
use ResetSystem() to reset the system.
-If firmware doesn't support ResetSystem() during runtime services,
-then the call will immediately return EFI_UNSUPPORTED, and the OS should
-fall back to an architecture or platform specific reset mechanism.
+
+If firmware doesn't support ResetSystem() during runtime services, then the call
+will immediately return, and the OS should fall back to an architecture or
+platform specific reset mechanism.
On AArch64 platforms implementing [PSCI]_,
if ResetSystem() is not implemented then the Operating System should fall
--
2.28.0