boot-architecture

boot-architecture@lists.linaro.org

675 discussions

by Grant Likely

Hi folks, Very sorry, but I'm going to postpone this week's EBBR meeting to next week. Arm has an internal quarterly meeting that conflicts. I'm going to reschedule to the same slot next week. g. 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.

5 years, 2 months

EBBR Biweekly for 26 Oct 2020

by Grant Likely

Reminder: Next EBBR Biweekly meeting is today at 16:00 UTC. Please note, UK daylight savings time ended yesterday, so this will be an hour later for everyone in the US or otherwise still on DST. Please reply if you want to add an item to the agenda. Notes will be collected on Etherpad. Please help take notes if you can. Here is the link: https://etherpad.opendev.org/p/EBBR Time: Every second Monday starting 31 Aug at 16:00BST, 08:00PST Join Zoom Meeting https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09 Meeting ID: 920 8136 5511 Password: 490324 One tap mobile +14086380968,,92081365511#,,#,490324# US (San Jose) +16465189805,,92081365511#,,#,490324# US (New York) Dial by your location +1 408 638 0968 US (San Jose) +1 646 518 9805 US (New York) +1 346 248 7799 US (Houston) Meeting ID: 920 8136 5511 Password: 490324 Find your local number: https://armltd.zoom.us/u/adYiWaDyys

5 years, 3 months

[PATCH 0/2]

by Atish Patra

This patch series adds RISC-V compatibility content to EBBR. The additional content is not a lot given that we just need to update the architecture specific sections for RISC-V. Rest of the document is ISA agnostic anyways. I am not sure about the copyrights though. There are two places where copyrights are present. I have added Western Digital copyright for the index.rst but I have not added it for conf.py as it goes into the first page of the EBBR specification. Should we add multiple lines of copyrights or just keep copyrights at one place ? I am open to any other suggestions as well. The series is also available in my github repo. https://github.com/atishp04/ebbr/tree/riscv_update Atish Patra (2): Add Western Digital copyright Add RISC-V support content to the EBBR specification source/chapter1-about.rst | 42 +++++++++++++++++++++++++++++++-- source/chapter2-uefi.rst | 10 +++++++- source/chapter3-secureworld.rst | 13 ++++++++++ source/index.rst | 3 +++ source/references.rst | 4 ++++ 5 files changed, 69 insertions(+), 3 deletions(-) -- 2.28.0

5 years, 3 months

Fit images and EFI_LOAD_FILE2_PROTOCOL

by Heinrich Schuchardt

Hello Ilias, hello Christian, with commit ec80b4735a59 ("efi_loader: Implement FileLoad2 for initramfs loading") Ilias provided the possibility to specify a device path (CONFIG_EFI_INITRD_FILESPEC) from which an initial RAM disk can be served via the EFI_FILE_LOAD2_PROTOCOL. Ard extended the Linux EFI stub to allow loading the initial RAM disk via the EFI_FILE_LOAD2_PROTOCOL with the utmost priority. With commit ecc7fdaa9ef1 ("bootm: Add a bootm command for type IH_OS_EFI") Cristian enabled signed FIT images that contain a device tree and a UEFI binary (enabled by CONFIG_BOOTM_EFI=y). In the DTE calls we have discussed that it is unfortunate that we do not have a method to validate initial RAM images in the UEFI context. To me it would look like a good path forward to combine the two ideas: * Let the signed FIT image (of type IH_OS_EFI) contain a RAM disk * Pass location and size to the UEFI subsystem and serve them via the EFI_FILE_LOAD2_PROTOCOL. We could also extend the bootefi command to be callable as bootefi $kernel_addr_r $ramdisk_addr_r:$filesize $fdt_addr_r like the booti command to serve an initial RAM disk. What are your thoughts? Best regards Heinrich

5 years, 3 months

EBBR Biweekly for 14-Sep-2020

by Grant Likely

Reminder: the next EBBR regular meeting is later today at 16:00BST/08:00PDT. Draft agenda below. Right now the agenda is very light. I'll keep the meeting short if we don't have anything to discuss. Agenda - Report on DT reserved-memory discussion - issue & PR review Send me an email if you want to add an item to the agenda, or add an issue to the github page. Also email me if you want me to send you a calendar invite for the meeting series. https://github.com/arm-software/ebbr/issues g. ---- Time: Every second Monday starting 31 Aug at 16:00BST, 08:00PST Join Zoom Meeting https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09 Meeting ID: 920 8136 5511 Password: 490324 One tap mobile +14086380968,,92081365511#,,#,490324# US (San Jose) +16465189805,,92081365511#,,#,490324# US (New York) Dial by your location +1 408 638 0968 US (San Jose) +1 646 518 9805 US (New York) +1 346 248 7799 US (Houston) Meeting ID: 920 8136 5511 Password: 490324 Find your local number: https://armltd.zoom.us/u/adYiWaDyys 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.

5 years, 4 months

Tomorrow’s DTE call

by François Ozog

Hi As we are organizing Linaro Connect and many people are involved or attending it has been difficult to settle an agenda. I propose we have an open floor to discuss any topic. Cordially François Frédéric -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog(a)linaro.org | Skype: ffozog

5 years, 4 months

DTE last call minutes

by François Ozog

Please find below the meeting minutes for the last call. (all project documentation, meeting notes and slides, reference material can be found on the DTE portal <https://collaborate.linaro.org/display/DTE>) - François-Frédéric Ozog (Linaro) - Joakim Bech (Linaro) - Atish Patra (Western Digital) - Loic Pallardy (ST) - Matthias Brugger - Ilias Apalodimas (Linaro) - Don (Harbin?) - CVS - Simon Glass (Google) - Bill Mills (Linaro) - Mark Brown (Arm) - Mike Holmes (Linaro) - Poonam (NXP) - Ruchika Gupta (Linaro) - Etienne Carriere (ST) - Stefano Stabellini (Xilinx) Notes: - Linaro slides <https://docs.google.com/presentation/d/1iCi8i7zAfYrXEXmQ0DfGB8DT3nPksX7zFJ7…> for 9th September meeting - Atish presentation on Risc-V boot process - SBI - Supervisor Binary Interface - Side note: - Privilege level defines what the running software can do during its execution. Common usage of each privilege level is as follows: - U-mode: user processes - S-mode: kernel (including kernel modules and device drivers), hypervisor - M-mode: bootloader, firmware - SBI call looks like SMC call - Actually SMC or HVC ? - OpenSBI: Open source implementation of the RISC-V SBI specification (BSD-2 clause). - RISC-V Boot flow - - OpenSBI here is equivalent to TF-A in the Arm world, however, there is no security implemented at this point. - The Linux kernel is booted by a single hardware thread identified by HART ID (HART = HARdware Thread) - Then Linux can bring up other cores with HART SBI State Management (~ PSCI) - - DT stuff - Generate DT from RTL - HART ID of boot core needs to be in chosen node - Reuses topology DT node as defined by Arm64 - Still work to do on standard IRQ controllers - Platform level interrupt controller PLIC is SiFive specific - Core Level Interrupt Controller (CLINT) - Future - Grub support - EBBR compliance - LinuxBoot support (was discussed last year but no more activity) - SecureBoot (still drafting) -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog(a)linaro.org | Skype: ffozog

5 years, 4 months

HARTID in DT

by François Ozog

Hi Atish, Is the HARTID in DT used to *define* which thread should used as the booted payload (Linux) or is it used to *inform* Linux that it was started on this particular HARTID? If we assume two DTs are used: one for OpenSBI and one for Linux, which one (or both) is used to contain the HARTID? Cheers FF

5 years, 4 months

[dtspec PATCH] Import /reserved-memory specification text

by Grant Likely

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.

5 years, 4 months

[PATCH 1/1] GetMemoryMap(), handling of no-map DT property

by Heinrich Schuchardt

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

5 years, 4 months

← Newer
1
...
25
26
27
28
29
30
31
...
68
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

boot-architecture