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
