+boot-architecture
On Mon, Feb 6, 2023 at 3:25 PM Simon Glass <sjg(a)chromium.org> wrote:
>
> Hi Rob,
>
> On Mon, 6 Feb 2023 at 10:15, Rob Herring <robh(a)kernel.org> wrote:
> >
> > On Sat, Feb 4, 2023 at 6:04 AM Simon Glass <sjg(a)chromium.org> wrote:
> > >
> > > Hi Peter,
> > >
> > > On Sat, 4 Feb 2023 at 02:36, Peter Robinson <pbrobinson(a)gmail.com> wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > Does it make sense to devise something that is compatible with the
> > > > kernel's pstore [1] mechanism?
> > >
> > > Possibly...can you please be a little more specific?
> >
> > Peter is talking about the same thing I suggested on IRC.
> >
> > pstore == ramoops
>
> Oh, I only looked at the DT binding as I thought that was what you
> were talking about on irc.
The binding is called ramoops as it's for the RAM backend for pstore.
My suggestion was either using/extending ramoops or following its
design as a reserved memory region. All you would need to extend the
ramoops binding is a new property to define the size of your data.
> For pstore, isn't the point that Linux wants to save stuff to allow
> debugging or collection on reboot? What does that have to do with
> console logs from firmware? That seems like a different thing. Or are
> you suggesting that we add a pstore driver into U-Boot? It is quite a
> lot of code, including compression, etc. It might be easier for Linux
> to write the data into pstore when it starts up?
Originally ramoops was just what you described. It has grown to
multiple backends and types of records (hence the rename to pstore).
If you just add a new subsection within the pstore region, then I
think the existing kernel infrastructure will support reading it from
userspace. Maybe new types have to be explicitly supported, IDK.
U-boot being able to read pstore wouldn't be a terrible feature to
have anyways if your boot crashes before anything else is up to get
the output. Note I'd guess the ram backend doesn't do compression as
supporting slightly corrupted ram is a feature which wouldn't work.
I think any new DT binding is premature and pstore/ramoops was just a
suggestion to consider. This needs wider consideration of how to
handle all the various (boot) firmware logs. I've added the
boot-architecture list for a bit more visibility.
Rob
Hi
Anyone knows what is the status of standardizing firmware handoff (when starting BL33) ?
Here is a reference to the topic:
https://github.com/FirmwareHandoff/firmware_handoff
I would be interested in both standard text and standard implementation in TFA.
The context is portability of type-1 hypervisors that need to be fully in control of security and thus execute BL33 in an ad hoc "VM".
The rationale is to isolate everything that deals with devices or IO (at its core, a hypervisor deals only with CPU, RAM, MMU, SMMU, GIC).
Cheers
FF
PS: To explore how easy it is to boot a hypervisor with either booti, bootefi or BL33 I published a Rust tool (barekit) that can do precisely that (and much more as it can be used to create BL32 or even a Rust based FF-A implementation):
https://www.linkedin.com/posts/fozog_github-fozogbarekit-rust-base-code-to-…https://github.com/fozog/barekit
All,
I have not received any ideas for agenda for today.
I will cancel this meeting.
A heads up:
Meetings on Monday no longer fit for me.
We will need to make some change going forward.
I will talk thing over with others and get back to the list.
Thanks,
Bill
--
Bill Mills
Principal Technical Consultant, Linaro
+1-240-643-0836
TZ: US Eastern
Work Schedule: Tues/Wed/Thur
Hi,
We do not have an agenda[2] for the EBBR call today Jan 30 therefore let us
cancel this call.
Next EBBR call will be on Feb 13; feel free to propose topics on the wiki or by
e-mail.
Best regards,
Vincent Stehlé
System Architect - Arm
[2]: https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings
All,
We do not have a topic for today so I will cancel today's meeting.
If you have a suggestion for the Feb 6 meeting please reply to this email.
Thanks,
Bill
--
Bill Mills
Principal Technical Consultant, Linaro
+1-240-643-0836
TZ: US Eastern
Work Schedule: Tues/Wed/Thur
All,
Sorry but I have a conflict for Monday's meeting so I am going to cancel.
Thanks,
Bill
--
Bill Mills
Principal Technical Consultant, Linaro
+1-240-643-0836
TZ: US Eastern
Work Schedule: Tues/Wed/Thur
Hi,
EBBR v2.1.0 is now available.
This is a minor release of the EBBR specification.
Compared to v2.0.1, this release adds requirements on ESRT, EFI Conformance
Profile and DTB, and updates the RISC-V boot requirements.
https://github.com/ARM-software/ebbr/releases/tag/v2.1.0
Thanks to all the contributors.
Best regards,
Vincent Stehlé
System Architect - Arm
All,
Next Monday the US will still be recovering/traveling from the holiday
extended weekend. So we will cancel the call.
Happy Thanksgiving to everyone that celebrates.
Thanks,
Bill
--
Bill Mills
Principal Technical Consultant, Linaro
+1-240-643-0836
TZ: US Eastern
Work Schedule: Tues/Wed/Thur
Hi Varun
Yes, I think the GitHub issue tracker can be used for all those things. Also, the TF-A list can be used for general questions/discussion - that has more visibility.
Cheers
Dan.
> -----Original Message-----
> From: Varun Wadekar <vwadekar(a)nvidia.com>
> Sent: 15 November 2022 15:29
> To: Jose Marinho <Jose.Marinho(a)arm.com>; Simon Glass
> <sjg(a)chromium.org>; Dan Handley <Dan.Handley(a)arm.com>
> Cc: tf-a(a)lists.trustedfirmware.org; u-boot(a)lists.denx.de; boot-
> architecture(a)lists.linaro.org; nd <nd(a)arm.com>
> Subject: RE: [TF-A] Re: [RFC] Proposed location to host the firmware handoff
> specification.
>
> Hi,
>
> Thanks for the email. Jose, how do we create bugs, provide ideas, or ask
> questions? Do you suggest creating issues for all of these?
>
> -Varun
>
> -----Original Message-----
> From: Jose Marinho via TF-A <tf-a(a)lists.trustedfirmware.org>
> Sent: Monday, 14 November 2022 3:30 PM
> To: Simon Glass <sjg(a)chromium.org>; Dan Handley
> <Dan.Handley(a)arm.com>
> Cc: tf-a(a)lists.trustedfirmware.org; u-boot(a)lists.denx.de; boot-
> architecture(a)lists.linaro.org; nd <nd(a)arm.com>
> Subject: [TF-A] Re: [RFC] Proposed location to host the firmware handoff
> specification.
>
> External email: Use caution opening links or attachments
>
>
> Hi,
>
> We're glad to announce that the Firmware Handoff document sources are
> now available publicly from:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2FFirmwareHandoff%2Ffirmware_handoff&data=05%7C01%7
> Cvwadekar%40nvidia.com%7C1802d934994a45de3f4f08dac655668a%7C43083
> d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638040367718884340%7CUnkn
> own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
> 1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=G1T9ndA4NlbTJ
> vQ%2BuWVu1S%2FQNjGkA6HicXD%2FS%2FuaG8Q%3D&reserved=0
>
> Note that this does not constitute a full "1.0" release of the document.
> There are still some topics raised in the ML that need to be aligned on before
> the full release -- I'll follow up on those with a separate e-mail.
>
> Having the document hosted in a public repo allows for all discussions about
> the document to progress in the open more easily.
>
> Regards,
> Jose
>
> -----Original Message-----
> From: Simon Glass <sjg(a)chromium.org>
> Sent: Sunday, September 18, 2022 4:05 AM
> To: Dan Handley <Dan.Handley(a)arm.com>
> Cc: tf-a(a)lists.trustedfirmware.org; u-boot(a)lists.denx.de; boot-
> architecture(a)lists.linaro.org; nd <nd(a)arm.com>
> Subject: Re: [TF-A] Re: [RFC] Proposed location to host the firmware handoff
> specification.
>
> Hi,
>
> I discussed this with Jose a white back. I am OK with this as an interim
> measure to get the initial doc agreed, so long as we move it to a more
> independent place when available.
>
> Regards,
> Simon
>
>
>
> On Tue, 13 Sept 2022 at 09:48, Dan Handley <Dan.Handley(a)arm.com> wrote:
> >
> > Hi all
> >
> > Just picking up this old thread again...
> >
> > There seemed to be general agreement to host the firmware hand-off
> spec in a separate repo with separate maintainers at TrustedFirmware.org, at
> least initially. Arm intends to progress with the initial population of this repo.
> We intend to use the CC-BY-SA-4.0
> (https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fspd
> x.org%2Flicenses%2FCC-BY-SA-
> 4.0.html&data=05%7C01%7Cvwadekar%40nvidia.com%7C1802d934994a
> 45de3f4f08dac655668a%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%
> 7C638040367718884340%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
> MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%
> 7C&sdata=eB3APd46h8VOPyIPSd1XtIiAziKVr6GMTX3T2UAT39c%3D&am
> p;reserved=0) license, the same as used for EBBR
> (https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2FARM-
> software%2Febbr&data=05%7C01%7Cvwadekar%40nvidia.com%7C1802
> d934994a45de3f4f08dac655668a%7C43083d15727340c1b7db39efd9ccc17a%7
> C0%7C0%7C638040367719040563%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300
> 0%7C%7C%7C&sdata=w%2FKV4fHrVWZKkDjtQOAFhkUr6axGHLnKhGCp
> 2fcbb74%3D&reserved=0). Please say if you have any objections to this.
> We will also seek approval from the TrustedFirmware.org board.
> >
> > Regards
> >
> > Dan.
> >
> > _______________________________________________
> > boot-architecture mailing list -- boot-architecture(a)lists.linaro.org
> > To unsubscribe send an email to
> > boot-architecture-leave(a)lists.linaro.org
> _______________________________________________
> boot-architecture mailing list -- boot-architecture(a)lists.linaro.org
> To unsubscribe send an email to boot-architecture-leave(a)lists.linaro.org
> --
> TF-A mailing list -- tf-a(a)lists.trustedfirmware.org To unsubscribe send an
> email to tf-a-leave(a)lists.trustedfirmware.org
Hi all
Just picking up this old thread again...
There seemed to be general agreement to host the firmware hand-off spec in a separate repo with separate maintainers at TrustedFirmware.org, at least initially. Arm intends to progress with the initial population of this repo. We intend to use the CC-BY-SA-4.0 (https://spdx.org/licenses/CC-BY-SA-4.0.html) license, the same as used for EBBR (https://github.com/ARM-software/ebbr). Please say if you have any objections to this. We will also seek approval from the TrustedFirmware.org board.
Regards
Dan.
All,
We will have the Devicetree call tomorrow.
The topic will be DT best practice in U-boot.
Simon will only be able to join for the first 30 minutes so lets start
on time please.
Thanks,
Bill
Topic: Devicetree Evolution
Time: Oct 18, 2021 3pm UK time
Every 2 weeks on Mon
Please download and import the following iCalendar (.ics) files to your
calendar system.
Weekly:
https://linaro-org.zoom.us/meeting/tJIscOmsrDMiGtWio_TMUjXFfAk0Ivr_fr03/ics…
Join Zoom Meeting
https://linaro-org.zoom.us/j/96170428801?pwd=elBJNFdVMFJub0UzanFUcVQxTHBqdz…
Meeting ID: 961 7042 8801
Passcode: 8250
One tap mobile
+13017158592,,96170428801# US (Washington DC)
+16465588656,,96170428801# US (New York)
Find your local number: https://linaro-org.zoom.us/u/acQEZ30MEP
--
Bill Mills
Principal Technical Consultant, Linaro
+1-240-643-0836
TZ: US Eastern
Work Schedule: Tues/Wed/Thur
Hi,
For the moment we have no topic for the EBBR call today[1]. Let's give people
until noon (UTC) to propose topics, otherwise we can skip this call.
Best regards,
Vincent Stehlé
System Architect - Arm
[1]: https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings
All,
There will be a DT call today. For the US it will occur 1 hour later
than normal due to UK timezone shift. It will be back to normal on Nov 14.
(But you all must have figured that out as there is no one on zoom right
now.)
Thanks,
Bill
--
Bill Mills
Principal Technical Consultant, Linaro
+1-240-643-0836
TZ: US Eastern
Work Schedule: Tues/Wed/Thur
Hi,
We do not have an agenda for the EBBR today's call[1] for the moment. Let's wait
until noon (UTC) for people to propose topics, then I think we can skip this
call.
Best regards,
Vincent Stehlé
System Architect - Arm
[1]: https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings
All,
Sorry of the late notice but I will not be able to host this meeting today.
Thanks,
Bill
--
Bill Mills
Principal Technical Consultant, Linaro
+1-240-643-0836
TZ: US Eastern
Work Schedule: Tues/Wed/Thur
Dear boot architecture community,
and in particular the people involved with System Device Tree,
The hypervisor portability tiger team of the SOAFEE group (Arm initiated automotive group) is going to have a kick off meeting as per the below invitation to discuss how to make device assignment with type-1 hypervisors much simpler for the hypervisor vendors and for the product makers. Attendees range from car OEM, Tier'1s, hypervisor providers (open source or commercial), silicon providers.
There are great chances that a solution will rely on System Device Tree. For instance we expect that the planned SCMI information introduction will allow to get just enough information to understand clock dependencies aspect of the device assignment.
We would greatly appreciate your active contributions.
Should you want to attend, you have all the information below to connect. Please contact me to be added to the formal invite roaster.
Cordially
Francois-Frederic
De : François Ozog <francois.ozog(a)soafee.io>
Date : mardi 11 octobre 2022 à 11:39
À : "tsc(a)soafee.io" <tsc(a)soafee.io>
Cc : Matt Spencer <Matt.Spencer(a)arm.com>, Robert Day <Robert.Day(a)arm.com>, "Estela Rey Ramos (via Google Docs)" <estela.reyramos(a)soafee.io>
Objet : [SOAFEE] Hypervisor Portability tiger team meeting
Hi,
As per the Doodle, the best date to organize the meeting on device assignment is on October 31st , 6pm-7pm CET.
There will be additional meetings and this one should be considered as the kickoff, and I will trim the distribution list shortly after this first instance.
You should have received the calendar invite in parallel on this mail.
The meeting link is: https://meet.google.com/vkj-zzue-vqb
I created an open folder to share your contributions on the topic:
https://drive.google.com/drive/folders/1KD4mySbduyN4BFRfpPNj7cOZxeJpRzDg?us…
You may want to drop here a few notes about what problems you faced and how they may be resolved. Those contributions can be in any or multiple forms (you can post a document and or a presentation to share during the meeting). I’ll post some later this week.
Cordially,
FF
PS: sorry to spam you with both a calendar invite and a mail.
[resend from correct email this time.]
All,
On yesterday's call we brainstormed about what topics we want to talk
about on this call going forward. We also said we will continue with
the bi-weekly cadence for a few meetings and then reassess if we should
go monthly instead.
Attending:
* Loic
* Mark
* Etienne
* Arnaud
* Rob
* Ilias
* Bill
* Joakim
Here is the topic list in no specific order:
* New DT format
* Overlays in kernel
* overlays for PCI or USB devices (in an ACPI based system)
* DT for other OSes
* Zephyr DT schema conformance
* ABI stability & testing
* source code sync
* U-boot DT handling
We discussed the ABI issue a bit:
Rob: SystemReady IR 2.0 requires schema conformance
* There are still open questions
+ what version of schema
+ how many warnings allowed
* discussion mostly inside ARM
* 2.0 will come out this fall
Bill: But you can have two DTBs that full conform to schema and are
still ABI breaking
* Example: ST moving from direct kernel Power/clk control to SCMI
* Current recommendation from this group is make new kernels work both
ways until all firmware will have been updated
* The switch over time could be a couple of years for a GP platform.
Loic: It is very difficult to make a kernel that works both ways
* Not all customers see the benefit, (mostly security)
* Some want to keep doing things the old way
Bill: Even if everyone agrees to switch the transition period is hard to
handle in anything except a vertical OS.
We discussed recent status of U-boot DT handling a bit but need a more
structured discussion / investigation.
Bill
--
Bill Mills
Principal Technical Consultant, Linaro
+1-240-643-0836
TZ: US Eastern
Work Schedule: Tues/Wed/Thur
All,
This is to confirm that we will have a meeting today at 2pm UTC, 10 am
US Eastern, which is about 30 min from now.
It has been a good number of months since we meet.
I want to collect topics and we can catch up on what has been happening.
Thanks,
Bill
--
Bill Mills
Principal Technical Consultant, Linaro
+1-240-643-0836
TZ: US Eastern
Work Schedule: Tues/Wed/Thur
Hi,
Here is a quick follow up to our last EBBR call[1] and the discussion we had on
the DT fixup protocol[2].
After consulting with Samer (in Cc:), he has suggested that submitting an ECR to
the UEFI forum would be the way to go. There is a specific template for that,
but Samer is experienced in the process and has kindly offered to help.
Heinrich, would you be ok to work with Samer on an ECR, please?
Best regards,
Vincent Stehlé
System Architect - Arm
[1]: https://github.com/ARM-software/ebbr/wiki/EBBR-Notes-2022.09.26
[2]: https://github.com/ARM-software/ebbr/issues/68
Hi,
I hope everybody had a nice summer.
Could we please resume the EBBR bi-weekly calls?
Let us have our next call on Sep. 26.
Here is the list of proposed topics:
- EFI_CONFORMANCE_PROFILE_TABLE
- EFI_DT_FIXUP_PROTOCOL
- ESRT
- Authenticated capsules
- Bump UEFI specification version to 2.10
This is also captured on the wiki[1] with links. Feel free to add topics.
I would also like to take this opportunity to thank Grant for his work on EBBR.
Best regards,
Vincent Stehlé
System Architect - Arm
[1]: https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings
