- boot-architecture - lists.linaro.org

Devicetree Evolution conference call time, al poll

by Bill Mills

All who participate or wish to participate in the DTE call, Please fill in this pool before you go out for the holidays: https://doodle.com/poll/fup2swsb9yi2u5u4?utm_source=poll&utm_medium=link The current meeting time does not work well for people on the west coast of North America as it is 6am Pacific time. I have selected the following times: 7 am PT, 15:00 UTC 8 am PT, 16:00 UTC 9 am PT, 17:00 UTC I have found options for Monday, Wednesday, Thursday, and Friday. Tuesday does not work at all for me at any reasonable time for the EU. All meeting times will repeat every two weeks except for the Wednesday 7am & 8am slots. These will normally be the 2nd and 4th Wednesdays of the month but in January will be the 6th and 27th. (This is to avoid the Linaro TSC calls that a good number us participate in.) If you want me to insert new times into the poll please respond to this message. Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

5 years, 9 months

1
0
0 0

DTE: UEFI protocol for device-tree fix-ups

by Heinrich Schuchardt

Dear all, we have discussed that a protocol is needed to fix-up device trees loaded by GRUB or other boot managers. In the U-Boot code we have actually the following actions for device-trees: * load the device-tree to memory * copy the device-tree to an allocated memory region which has 12 KiB free space for device-tree fix-ups * do the actual fix-ups, i.e. add new nodes or change properties * reserve memory according to the /reserved-memory node and the memory reservation block as EfiBootServicesData or as EfiReservedMemoryType for no-map regions * install the device-tree as configuration table So I think the usage of a DT fix-up protocol could take the following steps: * GRUB loads the device-tree allocating sufficient memory for fix-ups * GRUB calls the protocol a fist time to add extra nodes and properties * GRUB applies its own device-tree fix-ups * GRUB calls the protocol a second time which - reserves memory according to the /reserved-memory node - installs the device-tree as configuration table One could join both service calls if GRUB applies its own fix-ups first. But maybe GRUB wants to analyze U-Boot's fix-ups before committing its own ones. So lets define a bit-field to pass to the fix-up protocol: /* Add nodes and update properties */ #define EFI_DT_APPLY_FIXUPS 0x00000001 /* * Reserve memory according to the /reserved-memory node * and the memory reservation block */ #define EFI_DT_RESERVE_MEMORY 0x00000002 /* Install the device-tree as configuration table */ #define EFI_DT_INSTALL_TABLE 0x00000004 Here is the rest of the proposed protocol definition: #define EFI_DT_FIXUP_PROTOCOL_GUID \ { 0xe617d64c, 0xfe08, 0x46da, \ { 0xf4, 0xdc, 0xbb, 0xd5, 0x87, 0x0c, 0x73, 0x00 } } typedef struct _EFI_DT_FIXUP_PROTOCOL { EFI_DT_FIXUP fixup; } EFI_DT_FIXUP_PROTOCOL; typedef EFI_STATUS (EFIAPI *EFI_DT_FIXUP) ( IN EFI_DT_FIXUP_PROTOCOL *This, IN VOID *Fdt, IN OUT UINTN *BufferSize, IN UINT32 Flags, ); This: Pointer to the protocol Fdt: Buffer with the device-tree. This shall be memory of type EfiACPIReclaimMemory if Flags contains EFI_DT_INSTALL_TABLE. BufferSize: Pointer to the size of the buffer including trailing unused bytes for fix-ups. If the buffer size is too small, the required buffer size is returned. Flags: Bitmap containing at least one of the values EFI_DT_APPLY_FIXUPS, EFI_DT_RESERVE_MEMORY, EFI_DT_INSTALL_TABLE. Indicates the actions to be applied to the device-tree. The selected actions indicated in Flags are applied in the sequence: * Add nodes and update properties. * Reserve memory according to the /reserved-memory node and the memory reservation block * Install the device-tree as configuration table Memory is reserved as EfiBootServicesData if the reservation does not carry the no-map property and as EfiReservedMemoryType if it is marked as no-map. If *BufferSize exceeds the value of the totalsize field header of device-tree header upon entry to the service, the totalsize field is set to *BufferSize. Return values: EFI_INVALID_PARAMETER - This is NULL or does not point to a valid EFI_DT_FIXUP_PROTOCOL implementation. EFI_INVALID_PARAMETER - Fdt or BufferSize is NULL EFI_INVALID_PARAMETER - *Fdt is not a valid device-tree (e.g. incorrect value of magic) EFI_INVALID_PARAMETER - Invalid value of Flags (zero or unknown bit) EFI_BUFFER_TOO_SMALL - The buffer is too small to apply the fix-ups. EFI_SUCCESS - All steps succeeded If EFI_BUFFER_TOO_SMALL is returned, the device-tree is unmodified and *BufferSize is updated with the required buffer size for the provided device-tree. The required buffer size when called with EFI_DT_APPLY_FIXUPS should enforce at least 4 KiB unused space for additional fix-ups by the operating system or the caller. The available space in the device-tree shall be determined using the device-tree header fields: Available = header->totalsize - header->off_dt_strings - header->size_dt_strings; (The strings block is always last in the flattened device-tree. There might be more space between blocks but not all device-tree libraries can use it.) The required buffer size when called without EFI_DT_APPLY_FIXUPS shall be the value of the totalsize field of the flattened device tree header. If any other error code is returned, the state of the device-tree is undefined. The caller should discard the buffer content. The extent to which the validity of the device-tree is checked is implementation dependent. But a buffer without the correct value of the magic field of the flattened device tree header should always be rejected. The protocol implementation is not required to check if the device-tree is in memory of type EfiACPIReclaimMemory. Looking forward to your feedback. Best regards Heinrich

5 years, 9 months

1
1
0 0

DT Evolution call for Dev 9th

by Bill Mills

All, Sorry for the late notice. We will have our normal DTE call at 2PM GMT today. My suggested topic for today is the open items in the DTB ABI slides here: https://docs.google.com/presentation/d/1Hq7-42EfM4xC_1N1HMO20vXVKSpkA_S-Los… This will be the last call for 2020. My suggestion for the DTE calls after this is to start in January with either: Option 1: 2nd & 4th Wednesday @ 4 PM GMT / 11 AM US Eastern Option 2: Alternate weeks with the EBBR call, Mondays at 4 PM GMT Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

5 years, 9 months

1
0
0 0

EBBR: RISC-V handoff to OS

by Heinrich Schuchardt

Hello Atish, the UEFI spec has this sentence: "When UEFI firmware handoff control to OS, the RISC-V is operated in machine-mode privilege." (M-mode is the equivalent to EL3 in ARM). This does not make any sense to me when using a secure execution environement (SEE) like OpenSBI. The hand-off should occur in S-Mode if the CPU supports it and only in M-Mode when the CPU only supports M-mode. We should prescribe this in the EBBR and somehow get the UEFI spec fixed afterwards. An other issue is the calling convention. Chapter "2.3.7.3 Detailed Calling Convention" does not describe which registers are saved by the UEFI payload's entry point and restored by the payload before calling the UEFI API or returning to the UEFI payload. This concerns especially registers gp (x3) and tp (x4). Into the EBBR or UEFI spec we should put a link to the "RISC-V ELF psABI specification" https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md which is referenced by "The RISC-V Instruction Set Manual". >From the "RISC-V ELF psABI specification" one might conclude that the UEFI payload should not be allowed to change gp and tp before calling ExitBootServices() or SetVirtualAddressMap() whichever occurs last. Due to this missing clarification U-Boot is currently saving gp before calling the entry point of the payload and restores it on reentry or on entry of an API call. Nothing is done for tp. Best regards Heinrich

5 years, 9 months

4
30
0 0

EBBR Biweekly (Postponed to 14th Dec)

by Grant Likely

I have a conflict this week and need to cancel. I propose pushing out to next week (Dec 14th), and cancelling the meeting on the 21st when many people will be on holiday anyway. Let me know if you want anything added to the meeting agenda before next week. Draft agenda: * Action item review * EBBR Testing Efforts (SCT, FWTS, etc) * UEFI Exception text changes * Next release schedule * Other business Time: This is a recurring meeting Meet anytime 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, 9 months

3
6
0 0

EBBR Biweekly today

by Grant Likely

Hi all, Here is the draft agenda for the EBBR biweekly today. As always, let me know if there is anything you want to add. Notes will be taken in Etherpad[1]. Draft agenda: - Issue & PR review - Draft EBBR text for tailoring UEFI section 2.6 base requirements[2] - Roundtable - Any other business [1] https://etherpad.opendev.org/p/EBBR [2] https://github.com/ARM-software/ebbr/wiki/Required-EFI-protocols --- Monday 23 November 16:00 GMT 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, 10 months

1
1
0 0

DT Evolution calls for November 4 and 18

by Bill Mills

All, We had a DTE call last week that was poorly attended. We decided to try again this week. Nov 11 would be our next normal call but it is a holiday for many of us so Francois will cancel it. Here I am suggesting we also meet on Nov 18. so to recap: Nov 4: YES Nov 11: NO Nov 18: YES On one of these calls we will figure out what we want to do going forward for meeting time. (Go back to old schedule, Keep new schedule, alternate weeks with EBBR in the same slot) For anyone that wants a real calendar invite, you can import the link below. Topic: DT Evolution (special case for Nov) Time: Nov 4, 2020 02:00 PM London Every 2 weeks on Wed, 2 occurrence(s) Nov 4, 2020 02:00 PM Nov 18, 2020 02:00 PM Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://linaro-org.zoom.us/meeting/tJwkc-2qrzgrHtVXvrcFXQ6fHonAqq_w1BZo/ics… Join Zoom Meeting https://linaro-org.zoom.us/j/98944213141?pwd=Ukg0T0hsTGp6OXFFMEpUZGZGVEUrdz… Meeting ID: 989 4421 3141 Passcode: 8250 One tap mobile +13017158592,,98944213141# US (Germantown) +16465588656,,98944213141# US (New York) Dial by your location +1 301 715 8592 US (Germantown) +1 646 558 8656 US (New York) +1 312 626 6799 US (Chicago) +1 669 900 9128 US (San Jose) +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 989 4421 3141 Find your local number: https://linaro-org.zoom.us/u/abpCUvVWcd Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

5 years, 10 months

1
1
0 0

EBBR Biweekly for 16 Nov 2020

by Grant Likely

[Note to self: I really should start sending out this email on Friday instead of Monday afternoon] Reminder; next EBBR meeting is today at 16:00 GMT. Dial in details are below. Let me know if there is anything you want added to the agenda Agenda: - Action item review - UEFI Exceptions Chapter - Any other business --- 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, 10 months

1
0
0 0

[PATCH v2 0/2] Add RISC-V specific content

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 Changes from v1->v2: 1. Added ACPI todo list. 2. Removed efistub requirements as that is linux specific. 3. Fix typos. 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 | 14 +++++++++++ source/index.rst | 3 +++ source/references.rst | 4 ++++ 5 files changed, 70 insertions(+), 3 deletions(-) -- 2.28.0

5 years, 10 months

5
11
0 0

EBBR Biweekly: Postponed to next week

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, 10 months

1
0
0 0

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, 11 months

1
0
0 0

[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, 11 months

4
11
0 0

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, 12 months

7
37
0 0

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.

6 years

1
4
0 0

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

6 years

1
0
0 0

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

6 years

1
0
0 0

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

6 years

4
3
0 0

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

6 years

2
2
0 0

[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

6 years

4
22
0 0

[PATCH] Refine firmware shared storage requirements.

by Grant Likely

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

6 years

4
12
0 0

[PATCH] Add a reference to RFC 2119

by Daniel Thompson

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

6 years

2
2
0 0

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

by Heinrich Schuchardt

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

6 years

4
13
0 0

[EBBR RFC] Remove the exclusive-or language around DT or ACPI

by Grant Likely

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

6 years, 1 month

6
13
0 0

Re: [System-dt] Notes (brief) from System DT call: OpenAMP bindings

by Stefano Stabellini

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>; }; };

6 years, 1 month

3
2
0 0

Storage of public key certificates for capsule authentication

by Sughosh Ganu

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

6 years, 1 month

6
13
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

boot-architecture