Hi
I assume this needs to be analyzed from System Device Tree perspective:
https://trustedfirmware-a.readthedocs.io/en/latest/components/psa-ffa-manif…
And this is to be included in the DT Technical Report.
Cheers
FF
--
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group*
T: +33.67221.6485
francois.ozog(a)linaro.org | Skype: ffozog
Hi everyone.
I have to do this, but I have another unexpected conflict for the EBBR biweekly on the 14th.
Rather than cancelling outright, does anyone else want to chair the meeting? The major planned orientatio item on the agenda was to talk about EBBR testing, with Heinrich sharing what he is currently doing.
If I don't hear anything by about 1pm GMT tomorrow then I'll just cancel. Our next meeting will be in January as I believe most of us will already be on Christmas holiday on the 21st
g.
Get Outlook for Android<https://aka.ms/ghei36>
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.
EFI_UPDATE_CAPSULE is the industry standard method for applying firmware
updates. Make it a requirement in EBBR so that fwupd, Windows Update,
and any other generic firmware update service can support EBBR platforms.
This is made required because the ability to update firmware is a
critical part of building secure platforms.
Fixes: #69
Signed-off-by: Grant Likely <grant.likely(a)arm.com>
---
source/chapter2-uefi.rst | 32 +++++++++++++++++++++++++++++++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
index 7b5eb24..b1182a8 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -167,7 +167,10 @@ are required to be implemented during boot services and runtime services.
EFI_SET_VARIABLE Required Optional
EFI_GET_NEXT_HIGH_MONO_COUNT N/A Optional
EFI_RESET_SYSTEM Required Optional
- EFI_UPDATE_CAPSULE Optional Optional
+ EFI_UPDATE_CAPSULE Required Optional
+ for in-band
+ firmware
+ update
EFI_QUERY_CAPSULE_CAPABILITIES Optional Optional
EFI_QUERY_VARIABLE_INFO Optional Optional
============================== ============= ================
@@ -243,6 +246,25 @@ Even when SetVariable() is not supported during runtime services, firmware
should cache variable names and values in EfiRuntimeServicesData memory so
that GetVariable() and GetNextVeriableName() can behave as specified.
+Firmware Update
+---------------
+
+Being able to update firmware to address security issues is a key feature of secure platforms.
+EBBR platforms are required to implement either an in-band or an out-of-band firmware update mechanism.
+
+If firmware update is performed in-band (firmware on the application processor updates itself),
+then the firmware shall implement EFI_UPDATE_CAPSULE and accept updates in the
+"Firmware Management Protocol Data Capsule Structure" format as described in [UEFI]_ § 23.3,
+"Delivering Capsules Containing Updates to Firmware Management Protocol. [#FMPNote]_
+Firmware is also required to provide an EFI System Resource Table (ESRT). [UEFI]_ § 23.4
+Every firmware image that is updated in-band must be described in the ESRT.
+
+If firmware update is performed out-of-band (e.g., by an independent Board Management Controller,
+or firmware is provided by a hypervisor), then the platform is not required to implement EFI_UPDATE_CAPSULE.
+
+EFI_UPDATE_CAPSULE is only required before ExitBootServices() is called.
+
+
.. [#OPTEESupplicant] It is worth noting that OP-TEE has a similar problem
regarding secure storage.
OP-TEE's chosen solution is to rely on an OS supplicant agent to perform
@@ -253,3 +275,11 @@ that GetVariable() and GetNextVeriableName() can behave as specified.
during runtime services.
https://optee.readthedocs.io/en/latest/architecture/secure_storage.html
+
+.. [#FMPNote] The `EFI_UPDATE_CAPSULE` implementation is expected to be suitable
+ for use by generic firmware update services like fwupd and Windows Update.
+ Both fwupd and Windows Update read the ESRT table to determine what firmware
+ can be updated, and use an EFI helper application to call `EFI_UPDATE_CAPSULE`
+ before ExitBootServices() is called.
+
+ https://fwupd.org/
--
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.
Hi,
I thought perhaps it might be worth starting a thread on this, as
despite Grant and Heinrich kinding spending a bit of time talking
about this, I am still very much in the dark about how 'embedded' and
distro/other boot flows are going to come together with EBBR. Of
course this would be easier f2f.
Case 1:
Firmware loads the kernel to a particular address, selects DT and
boots it. The kernel may require EFI boot services, or may not, but in
the general case the firmware provides them.
Case 2:
Firmware loads EFI app and provides EFI boot services to it. How the
system actually boots is under control of the app.
I feel that a lot of the confusion about verified boot, DT selections,
boot menus, etc. is coming from the introduction of an EFI app which
has no specification (it can be grub, shim or something else, as I
understand it). Certainly this is very flexible and future-proof, but
it is also arbitrarily complex, unpredictable and hard to secure.
I am wondering if we can come up with a way to deterministically
specify how a system will boot and how to make it boot a different way
(i.e. with a different kernel, initrd, DT).
Heinrich mentioned EFI variables as a way of selecting
kernel/initrd/DT. Then the problem becomes just a case of being able
to change those variables from Linux userspace. Is that right?
We are talking about having a 'secure' part of EBBR, which allows for
secure boot. Should we have a 'defined boot' part of EBBR, that
defines how the kernel/DT/initrd are selected, based on EFI variables?
Unfortunately I just don't know enough about all the different boot
flows used by the different distros. It seems like crazy town. Does
anyone have some pointers so I can do some study?
Regards,
SImon
All,
On the Devicetree evolution call Wednesday I promised to finish my
comparison of u-boot DT vs kernel DT.
The script is not perfect but the results are still interesting.
For each dts and dtsi file in the tip of the u-boot tree, it tries to
correlate it to the kernel tip.
It compares git SHA1 signatures or falls back to filenames.
The results were surprising to me but perhaps they should not have been.
I have checked in the script[1] and the full results here [2]
The full file lists (with some diff stats) are in the root dir.
Example [3]
I also looked at the line count of the u-boot override files.
Even though we don't expect these to correlate, we do expect reasonable
usage to result in small files. Big files are an indication of possible
abuse of the system. (I don't think the idea was to have wholesale new
versions of the DTS as an override.)
I plan to redo the script in python. It will be much easier to be more
precise and to look deeper. (For example figure out how old the u-boot
version is in number of change sets and number of days. Or if no
content sync now were they ever synced?)
Here is the scripts output: (from summary.txt)
Devicetree sync status for u-boot v2021.01-rc5-7-gb8c725e736
Compared to kernel v5.11-rc2-156-g71c061d24438
14% (255) are completely synced
253 arm
2 riscv
0 mips
0 powerpc
0 x86
0 68k
0 microblaze
0 sh
0 arc
23% (416) content has appeared in the kernel but is not up to date
411 arm
0 riscv
1 mips
0 powerpc
1 x86
0 68k
0 microblaze
0 sh
1 arc
33% (584) filename appears in kernel but content never has
467 arm
1 riscv
12 mips
91 powerpc
0 x86
0 68k
0 microblaze
0 sh
8 arc
28% (510) neither filename nor content appears in kernel
305 arm
4 riscv
48 mips
35 powerpc
44 x86
0 68k
1 microblaze
1 sh
6 arc
n/a (510) U-Boot specific, no correlation expected
7 sandbox
358 override
211 test
histogram of override size (in raw lines)
10 61
20 53
30 38
40 33
50 23
60 14
70 12
80 7
90 5
100 4
110 4
120 5
130 6
140 4
150 0
160 2
170 0
180 0
190 4
200 0
210 2
220 2
230 1
240 2
250 1
260 1
270 1
280 0
290 0
300 0
310 0
320 1
[1]
https://github.com/wmamills/devicetree-source/blob/master/scripts/correlate…
[2] https://github.com/wmamills/devicetree-source
[3]
https://github.com/wmamills/devicetree-source/blob/master/dts-somewhere.txt
--
Bill Mills
Principal Technical Consultant, Linaro
+1-240-643-0836
TZ: US Eastern
Work Schedule: Tues/Wed/Thur
Hello,
Thanks to all that have participated in the doodle poll. We don't yet
have all key stakeholders so please add your info if you have not.
As expected there is no perfect time but the current leader is
Wednesdays at 4PM UK, 11 AM US Eastern.
I have scheduled a meeting for tomorrow as this first one.
Possible topics for tomorrow include:
* More Conformance testing of DT source
* Keeping multiple DT projects in sync (w/o moving the DT source)
* DT overlay source in the kernel source tree (for bootloader applied
overlays)
If we stay with Wednesdays the meeting after this one would be Jan 27.
(Wednesdays require working around Linaro TSC calls)
Thanks,
Bill
***
Bill Mills is inviting you to a scheduled Zoom meeting.
Topic: DT Evolution
Time: Jan 6, 2021 04:00 PM London
Join Zoom Meeting
https://linaro-org.zoom.us/j/94413146152?pwd=NEs1Ym1xbnRBS0U4ZWNsaXFzbm1Ndz…
Meeting ID: 944 1314 6152
Passcode: 8250
One tap mobile
+13017158592,,94413146152# US (Washington D.C)
+13126266799,,94413146152# US (Chicago)
Dial by your location
+1 301 715 8592 US (Washington D.C)
+1 312 626 6799 US (Chicago)
+1 646 558 8656 US (New York)
+1 669 900 9128 US (San Jose)
+1 253 215 8782 US (Tacoma)
+1 346 248 7799 US (Houston)
877 853 5247 US Toll-free
888 788 0099 US Toll-free
Meeting ID: 944 1314 6152
Find your local number: https://linaro-org.zoom.us/u/aesZr3aPDG
--
Bill Mills
Principal Technical Consultant, Linaro
+1-240-643-0836
TZ: US Eastern
Work Schedule: Tues/Wed/Thur
Hi,
As I am thinking about conformance testing for SystemReady and Trusted
Substrate, I'd like to get your feedback on the following.
There are 7 values in the reg entry of interrupt-controller@210000 from the
below DT. This corresponds to 3 valid {address,size} plus a single
{address}.
The spec does not state anything on incomplete {address,size} pairs... I
understand that #size-cell can be zero, indicating that the reg will
contain only {address} "tuples" and not {address,size} tuples. But that
should be for all reg tuples, not just one.
In this case, I assume the driver will get what it wants, but from a
certification perspective:
- I would reject this DT.
- I would document proper tuple forming in the spec (no incomplete pairs)
Last, I would also add some "notes" in the spec about where to get the
"#*-cells" for the reg property of a device. If you think "hardware" it is
obvious that the information must be retrieved from the immediate parent
and "inheritance" does not make sense. But as I Googled the topic, I have
seen a number of discussions and wrong patches around that. So I would add
a non normative text (properly identified as such) to describe that in the
spec.
Thank you for your help
Cheers
FF
config-space@f0000000 {
#address-cells = <0x01>;
#size-cells = <0x01>;
compatible = "simple-bus";
ranges = <0x00 0x00 0xf0000000 0x1000000>;
interrupt-controller@210000 {
compatible = "arm,gic-400";
#interrupt-cells = <0x03>;
#address-cells = <0x01>;
#size-cells = <0x01>;
ranges;
interrupt-controller;
interrupts = <0x01 0x09 0xf04>;
reg = <0x210000 0x10000 0x220000 0x20000 0x240000 0 0x20000>;
phandle = <0x01>;
v2m@280000 {
compatible = "arm,gic-v2m-frame";
msi-controller;
reg = <0x280000 0x1000>;
arm,msi-base-spi = <0xa0>;
arm,msi-num-spis = <0x20>;
phandle = <0x03>;
};
--
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group*
T: +33.67221.6485
francois.ozog(a)linaro.org | Skype: ffozog
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
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
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
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
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.
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.
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
[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.
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
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.
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
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
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
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.
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
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
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
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.
