- boot-architecture - lists.linaro.org

EBBR Biweekly is ON today - 17th January

by Grant Likely

Hi all, Just a quick note that the EBBR meeting scheduled for today is indeed on. Ilias and Jose will be presenting the work done on A/B updates which should be interesting to the EBBR audience. Here's the agenda and dial in details: Agenda: - A/B Update Presentation (Ilias & Jose) - Requirement to disable or remove command line when secure (Ilias) Zoom details: 17th Jan 2022, 15: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) 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.

3 years, 11 months

2
1
0 0

DT Evolution call in ~45 min

by Bill Mills

Hello all, We have the first DT evolution call of the year in ~45 min. 3PM UTC, 10 am US East https://linaro-org.zoom.us/j/96170428801?pwd=elBJNFdVMFJub0UzanFUcVQxTHBqdz… Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

3 years, 12 months

1
0
0 0

EBBR Biweekly - 6 Dec 2021

by Grant Likely

Just a reminder, the EBBR biweekly is on today (about 15 minutes from now). I try to send these reminders out the week before, but it fell off my radar last week. Here is what I have on the agenda for today: Agenda * Requirements on A/B update (Ilias) * Can the OS be responsible for firmware update? (Ilias) - e.g., via fwupd or similar to stage UpdateCapsule() * Requirement to disable or remove command line when secure (Ilias) --- 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.

4 years, 1 month

4
5
0 0

Reminder EBBR biweekly today at 15:00 GMT

by Grant Likely

Hi everyone, This is just a reminder that the next EBBR biweekly is today at 15:00 GMT. Zoom details are below, and here is today's agenda: Agenda: - UEFI EBBR Conformance profile (Jose) https://bugzilla.tianocore.org/show_bug.cgi?id=3591 - Requirements for measured boot (Ilias) - Any other business I'm also keeping track of agenda items on the EBBR wiki which you can find here: https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings Join Zoom Meeting https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09 Meeting ID: 920 8136 5511 Password: 490324 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.

4 years, 1 month

1
0
0 0

No Devicetree call for Nov 15

by Bill Mills

All, Sorry but I have to cancel the call for tomorrow. See you in two weeks. Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

4 years, 1 month

1
0
0 0

EBBR Biweekly - Monday, 8 Nov 2021

by Grant Likely

Hi all, EBBR Biweekly meetings will resume next week on Monday at 15:00GMT. This is a new time to line up with the same slot as the Devicetree Evolution meeting being run by Linaro. Details for joining are below, and can also be found on the EBBR wiki. https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings Here is the agenda so far: - Update on Arm's SystemReady IR program - Issue review - Plans for next iteration of EBBR - List of potential new requirements - Other business As always please email me if you want to add items to the agenda. --- Topic: EBBR Biweekly Time: This is a recurring meeting Meet anytime Join Zoom Meeting https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09 Meeting ID: 920 8136 5511 Passcode: 490324 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.

4 years, 2 months

1
0
0 0

DTE call today at 15 UTC/UK (US: LOOKS LIKE OLD TIME!)

by Bill Mills

All, We have our normal DTE call today at the new time of 15 UK. HOWEVER, the UK has come off daylight savings time while the US and others have not. This means that in the US it looks like the old time. 11 AM Eastern 10 AM Central 9 AM Mountain 8 AM Pacific This is a single week issue that occurs once in the fall and in the once spring. It _should_ appear correct on you calendar. We said we would discuss devicetree lifecycle at the source level. We will use the second half of the slides from last time: https://fileserver.linaro.org/s/FqT2JcTxCWStTNY Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

4 years, 2 months

1
0
0 0

SystemReady and OCP Checklist

by François Ozog

Hi back in April we had a workshop on firmware sustainability. Since then a number of discussions related concerns on closed source components in TF-A and U-Boot communities. We are also approaching a technical maturity level on SystemReady that it looks timely to revisit this aspect. Would it be a good move to adopt the Open System Firmware check list <https://www.opencompute.org/wiki/Open_System_Firmware/Checklist> as part of SystemReady? *NOTE1: believe SystemReady is at right level as it addresses compliance of platforms. EBBR is a technical recipe to make it work for a particular environment (like SBBR) and so not the best place to deal with redistribution license of binary blobs and other platform owernship aspects.* *NOTE2/ Adoption could come in different forms: referring to it, crafting a similar one for SystemReady scope, any other smart ways of doing it.* Cheers FF -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.ozog(a)linaro.org | Skype: ffozog

4 years, 2 months

4
8
0 0

Re: SystemReady and OCP Checklist

by François Ozog

Hi Tom Le lun. 25 oct. 2021 à 18:59, Tom Rini <trini(a)konsulko.com> a écrit : > On Mon, Oct 25, 2021 at 05:41:44PM +0100, Daniel Thompson wrote: > > On Mon, Oct 25, 2021 at 03:59:49PM +0200, Heinrich Schuchardt wrote: > > > On 10/25/21 15:32, Daniel Thompson wrote: > > > > On Mon, Oct 25, 2021 at 01:51:34PM +0200, Heinrich Schuchardt wrote: > > > > > On 10/25/21 12:43, François Ozog wrote: > > > > > > Hi > > > > > > > > > > > > back in April we had a workshop on firmware sustainability. > Since then a > > > > > > number of discussions related concerns on closed source > components in TF-A > > > > > > and U-Boot communities. We are also approaching a technical > maturity level > > > > > > > > > > U-Boot is licenced under GPL. You must not include any code which > is not > > > > > licensed under GPL or a compatible license (cf. > > > > > https://www.gnu.org/licenses/license-list.html) into U-Boot. This > > > > > disqualifies any closed source component but also open source > which is not > > > > > GPL compatible like OpenSSL. > > > > > > > > > > The BSD-3 license of TF-A is compatible with GPL. > > > > > > > > > > For closed source TF-A components distributed with U-Boot the > following GPL > > > > > exception *MIGHT* apply in some cases: > > > > > > > > > > "However, as a special exception, the source code distributed need > not > > > > > include anything that is normally distributed (in either source or > binary > > > > > form) with the major components (compiler, kernel, and so on) of > the > > > > > operating system on which the executable runs, unless that > component itself > > > > > accompanies the executable." > > > > > > > > The GNU GPLv2 "mere aggregation" language must also be mentioned when > > > > looking at the license effects here. > > > > > > > > If TF-A and u-boot were merely aggregated together on the same > storage > > > > media then the license of one would not influence the licensing of > > > > the other. > > > > > > > > I am doubtful that one component being responsible for copying the > other > > > > into memory would change this. > > > > > > Think of U-Boot's UEFI variables managed by an OP-TEE module > (Standalone > > > MM), or U-Boot (or Linux) invoking PSCI. These are not cases of mere > > > aggregation but come close to the operating system case. But TF-A is > not an > > > operating system. > > > > This is very much an example of "each case turns on its own facts". > > > > PSCI is a generic protocol. It is based on traps. Its primary purpose is > > to decouple components that run at different trust levels. TF-A is not > > the only implementation. U-boot is not the only client. > > > > Such facts make it unlikely that TF-A would become a derived work of > > u-boot simply because u-boot gets PSCI services from TF-A. > > > > To be clear I agree there are definitely circumstances that could lead > > an OP-TEE TA, OP-TEE itself or TF-A being combined with u-boot (rather > > than aggregated alongside). A OP-TEE TA to assist with variable storage > > could certainly reach this level, especially if it's interfaces were > > specifically designed to match the u-boot driver model (although this > > still may not impact TF-A). > > So, this might be an unpopular opinion here, but perhaps the Canonical > or Linaro lawyers could chime in with some non-binding thoughts? > Engineers arguing about the law tends to not be productive. i agree. From my standpoint, there are products on the market that assemble firmware components such as TF-A , U-Boot and OP-TEE in various ways : so lawyers have done their job and it is possible. My question is: can we further characterize the distributed firmware with regards to parameters described in the checklist? If there are binary components in the mix, how much a platform owner (in the checklist sense) can rebuild the open source portion, include the binaries and redistribute the result? > > > -- > Tom > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.ozog(a)linaro.org | Skype: ffozog

4 years, 2 months

2
2
0 0

Devicetree Evo call today at 2PM UTC / 10am US eastern

by Bill Mills

All, We have our DT evo call today one hour earlier than normal. 2 PM UTC / 3PM UK / 10 AM US East (NY) (in 48 min as I write this.) Today we will talk about DTB life cycle in firmware at run time. We might get an update from Simon of DTB signatures. Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

4 years, 2 months

1
1
0 0

Re: Poll for new time for DT Evo call

by Bill Mills

Yep I see your info. Thanks for the bug report :) -- Bill On 10/5/21 12:02 PM, Simon Glass wrote: > OK that worked, I think. > > - Simon > > On Mon, 4 Oct 2021 at 19:19, Bill Mills <bill.mills(a)linaro.org> wrote: >> >> Sorry wrong link. >> Please try this one: >> https://doodle.com/meeting/participate/id/mepQEZNa >> >> On 10/4/21 6:19 PM, Bill Mills wrote: >>> All, >>> >>> If you normally attend the Devicetree evolution call, >>> Please fill out this poll: >>> https://doodle.com/meeting/organize/id/mepQEZNa >>> >>> Thanks, >>> Bill >>> >>> -- >>> Bill Mills >>> Principal Technical Consultant, Linaro >>> +1-240-643-0836 >>> TZ: US Eastern >>> Work Schedule: Tues/Wed/Thur >> >> -- >> Bill Mills >> Principal Technical Consultant, Linaro >> +1-240-643-0836 >> TZ: US Eastern >> Work Schedule: Tues/Wed/Thur -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

4 years, 3 months

1
0
0 0

Poll for new time for DT Evo call

by Bill Mills

All, If you normally attend the Devicetree evolution call, Please fill out this poll: https://doodle.com/meeting/organize/id/mepQEZNa Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

4 years, 3 months

1
2
0 0

Making recordings of DT Evo meetings public

by Bill Mills

All, I have recordings and automated transcripts of all the meetings in 2021. So far I have not made these public. *** Is there any objection to making them public? *** I don't imagine many people will go back and look but it is sometimes nice to know that you could. Please let me know if you have any concern. I will take no action until next week. Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

4 years, 3 months

1
0
0 0

Notes and slides from today's DT Evo call

by Bill Mills

All, Today we discussed Simon's slides [1] about DTB signatures. Simmons points (as I understand them) * U-boot has used signatures in FIT format for years * The technique used for FIT is actually generic to any DTB * Such a signed DTB could still be passed to kernel * even an old one like 4.4 * Suggest we adopt this for signing individual DTBs Discussion: * General interest in idea, no strong objections * multiple people want to see the worked example to know for sure * Which nodes do we want to sign? * Should we sign in a way that allows the kernel to recheck the signature? * would require we exclude from hashing anything that will get fixed up by u-boot at run time, such as mac addrs and chosen * If u-boot applies any non-trivial DTBO's, the kernel won't be able to check the result, is it worth the effort for the simple case? * If we really want the kernel to verify, we should pass on a set of dtbs: a base and set of overlays, one overlay would be the fixup data. kernel could check each dtb and then verify that fixup data only touches the stuff that it should * Joakim worked with a student to do things very similar to what Simon is talking about. see [2] Other comments: * verifying 10 rsa signatures on 10 hashes is more expensive than verifying 1 rsa signature of 10 strong hashes. (RSA signatures on the actual data itself would be VERY expensive.) * We should be careful about boot time in all these discussions. * If all the DTB data is internal to u-boot, just use FIT and have one signature for all the various hashes. * Is it OK to use the "exploded" rsa public key data in all cases? * Is the exploded for faster or just less code? * Can we supply the plan/std pub key AND the exploded version? * implementations that care about speed and code size can use the exploded ver, while things that need to standard key structure can use that. We would need a offline tool to verify both. * UEFI secure boot will have public keys installed. Can we explode the key on install for internal storage? Actions: * Simon to work up an example of signing just one dtb We also introduced the topics of DT lifecycle at firmware level: A) Source level lifecycle, keeping things in sync A1) Golden source repo A2: Golden source for platforms that opt-in A3) auto checker but manual fixup A4) remove DT from sub projects and rely on B2 model Pretty sure this is a NOPE! A5) do nothing and trust platforms maintainers to do the right thing (despite evidence that many are not currently). B) runtime life-cycle B1) each component has its own DTB B2) DTB is only present in "first" firmware and is passed along from there B3) mixture of B1 & B2 at different firmware stages Actions: * Bill to make slides so we can discuss properly on Oct 18. [1] https://drive.google.com/file/d/1PA5aQ2rISOrdNbqElfIWXaSrCG28Rqx4/view?usp=… [2] https://github.com/marianomarciello/Device_Tree_Verification/tree/e0b2fc989… Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

4 years, 3 months

1
0
0 0

DT Evo call today at 4PM UTC (30 min)

by Bill Mills

Hello, We have our DT evo call in just a bit. Today I would like to talk about DT lifecycle and flow "with in" firmware. Up till this point we have focused on firmware to "OS layer" hand off. That topic is not done but I think we need to start exploring the flow within firmware as people seem to have very different views. We need to figure out what models are valid (2 seems plenty) and how we can talk about them. I don't have slides today but we can start the discussion. Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

4 years, 3 months

1
0
0 0

Of capsules, signatures and device trees, TGTBTU

by François Ozog

Hi, Following the EFI capsule revert, here* is a contribution to understand the context in which we designed the patch set. (everyone is a commenter, please be mindful). The presentation explores booting, with more details for the Arm context, pre and post U-Boot. On Arm, pre-U-Boot is shaped after Firmware Framework-A and other interfaces. There is a similar approach in RISC-V with OpenSBI. There is nothing to agree on: many elements of the presentation are specifications for the Arm ecosystem. The purpose is to reach common understanding of those for rest of the journey. Careful reading is required because as we all know very well the topic, we may skip over stuff and miss key elements that may have changed since you last checked. So I'll attract your attention on: Slide 9: there can be multiple device trees in a Trusted Firmware FIP (nothing to agree on...) Slide 11: roles and responsibilities of firmware go far beyond booting and OTA. CoreBoot and SPL will have to take those into account in the future. Slide 17: there is a new boot flow based on "give-me-my-initrd" UEFI protocol Slide 24: when the firmware is stored on Secure Storage which is a common case for products, U-Boot/Linux have absolutely no means to perform the update (see notes for details). Slide 28: there are plenty of keys needed, the U-Boot and U-Boot updater can be different; as well as all firmware components. I acknowledge that the presentation is hard to read without enough speaker notes or myself talking to it. Let's say that I prefer to keep the ball rolling before we can actually program a call: could you send me in private message your preferred day of the week and best time (with TZ) for such a thing? Cordially, -- François-Frédéric Ozog *) https://docs.google.com/presentation/d/1AHTf9xMNqPXbiDLkBpoKt45UTjV8s34Jdtm…

4 years, 3 months

1
0
0 0

Re: Question about extension board used in U-boot

by François Ozog

Hi Paul Too posting because I think we also need to address this at a higher level. i think we discussed this topic quite a while back. I may be wrong but it may be Bill Mills who proposed to have an eeprom on the extensions that the carrier board can use to detect and fetch proper overlay. Another way would be that the contract between the extension board and the carrier board includes an i2c accessible storage to fetch an overlay that would identify the board and give all details. Bottom line, a software only solution seems not entirely satisfying. In that suboptimal case, U-Boot shall be able to assemble a DT for itself and another for OS (may be same in some cases) through scripting. And in this case, come your questions below . Le sam. 18 sept. 2021 à 01:21, Ying-Chun Liu (PaulLiu) <paulliu(a)debian.org> a écrit : > Hi all, > > > I have some questions about how to implement extension board usage. > My case is on imx8mm-cl-iot-gate. It can add three different types of > extension boards. > One of the extension boards is SPI extension which have 3 empty slots. > And you can add > some small boards onto it. One of them is a "TPM2" module. > > > My first question is if I want to use tpm2 in U-boot for measured boot. > How to implement this right? Currently I just modify the dts used by > U-boot to let it drive > the extension board. And let it drive the TPM. But it is not good for > upstreaming because > when other types of extension boards installed then it is not working. > Where to implement this? What is the best practice of this? > The second question is about extension manager. > I have read the extension.rst. I think I'll implement this anyway > because then > I can have a command to query what type of extension boards I have. > And if the extension board is the 3 slots one. I can then detect which > slot is the TPM. > I'll implement this anyway because the "extension" command is convenient > for users. > But it seems to me that it only solves the problem for Linux kernel. > It can apply a DTB Overlay to Linux DTB to let Linux knows we have that > extension board. > But it is too late for U-boot itself, right? > > > The third question is I'm also dong SystemReady IR certificate. That means > the dtb for Linux is directly provided by U-boot. We use U-boot dtb > directly to Linux > kernel. In this case, how to modify that dts dynamically to feed to the > Linux kernel by > the extension manager? > What is the best practice if I want to use U-boot dts for Linux in > implementation? > > > Thanks a lot. > > > Yours, > Paul > > > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.ozog(a)linaro.org | Skype: ffozog

4 years, 3 months

3
4
0 0

Today's Devicetree call

by Bill Mills

All, Today is the first day of the Linux Plumbers Conference. I suspect we will not have quorum. However since I did not cancel before now, I will be on the bridge. Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

4 years, 3 months

1
0
0 0

Native PE/COFF support for aarch64

by François Ozog

Hi, this mail just to inform you that there is a plan to support native building of PE/COFF for aarch64 and in particular to support SBAT for shim.efi. It is seen possible to deliver this by the end of October (this is just an early estimate). Cordially FF -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.ozog(a)linaro.org | Skype: ffozog

4 years, 3 months

4
7
0 0

No DT Evo call Sept 6

by Bill Mills

All, Monday Sept 6 is a US Holiday so I am canceling the call this week. Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

4 years, 4 months

1
0
0 0

incompatible device trees between u-boot and linux

by François Ozog

Hi, Trying to respond to a U-Boot digest manually, please accept apologies as I don't know how to do it properly... >On Wed, Aug 25, 2021 at 06:43:23PM +0300, Vladimir Oltean wrote: >> On Wed, Aug 25, 2021 at 11:24:08AM -0400, Tom Rini wrote: >> > On Wed, Aug 25, 2021 at 06:12:20PM +0300, Vladimir Oltean wrote: >> > > On Wed, Aug 25, 2021 at 10:26:10AM -0400, Tom Rini wrote: >> > > > On Wed, Aug 25, 2021 at 05:18:16PM +0300, Vladimir Oltean wrote: >> > > > > On Wed, Aug 25, 2021 at 10:00:45AM -0400, Tom Rini wrote: >> > > > > > On Wed, Aug 25, 2021 at 03:58:10PM +0200, Michael Walle wrote: >> > > > > > >> > > > > > > Hi, >> > > > > > > >> > > > > > > I noticed that there is a fallback to the u-boot device tree for linux >> > > > > > > (esp. EFI boot) if no other device tree was found, see [1]. It seems this >> > > > > > > is working fine for imx devices, for example, where you can just boot a >> > > > > > > stock installer iso via EFI. It will just work and it is quite a nice >> > > > > > > feature as a fallback. >> > > > > > > >> > > > > > > Now for the layerscape architecture, the ls1028a in my case, things are >> > > > > > > more difficult because the bindings differ between u-boot and linux - one >> > > > > > > which comes to mind is DSA and ethernet. >> > > > > > > >> > > > > > > Which begs the general question, is it encouraged to have both bindings >> > > > > > > diverge? To me it seems, that most bindings in u-boot are ad-hoc and there >> > > > > > > is no real review or alignment but just added as needed, which is ok if >> > > > > > > they are local to u-boot. But since they are nowadays passed to linux >> > > > > > > (by default!) I'm not so sure anymore. >> > > > > > > >> > > > > > > OTOH The whole structure around a .dts{,i} and -u-boot.dtsi looks like >> > > > > > > they should (could?) be shared between linux and u-boot. >> > > > > > > >> > > > > > > -michael >> > > > > > > >> > > > > > > [1] >> > > > > > > https://elixir.bootlin.com/u-boot/v2021.10-rc2/source/common/board_r.c#L471 >> > > > > > >> > > > > > The U-Boot device tree is supposed to be able to be passed on to Linux >> > > > > > and Just Work. The bindings are not supposed to be different between >> > > > > > the two (except for when we take the binding while it's being hashed out >> > > > > > upstream BUT THEN RESYNCED). >> > > > > >> > > > > You might need to spell that out a bit clearer. >> > > > > >> > > > > You are saying that both U-Boot and Linux are allowed to have their own >> > > > > custom properties (like 'u-boot,dm-spl' for U-Boot, and 'managed = "in-band-status"' >> > > > > for Linux), as long as the device tree files themselves are in sync, and >> > > > > the subset of the device tree blob understood by Linux (i.e. the U-Boot >> > > > > blob sans the U-Boot specifics) is compatible with the Linux DT blob? >> > > > >> > > > I don't know what about the Linux example makes it Linux specific. But >> > > > yes, 'u-boot,dm-spl' is clearly in our namespace and should be ignored >> > > > by Linux. The whole reason we have the -u-boot.dtsi automatic drop-in >> > > > logic (as much as it can be used is that device trees are device trees >> > > ^ >> > > I don't think this parenthesis ever closes... >> > >> > Ah, whoops. Should have been "(as much as it can be used)" because it >> > does get #included instead in some cases, for reasons. >> > >> > > >> > > > and describe the hardware and developers don't need to write a device >> > > > tree for Linux and a device tree for U-Boot and a device tree for >> > > > FreeBSD and ... So yes, you're supposed to use the device tree for a >> > > ^ >> > > so I never get the answer to "the whole reason is...". >> > > >> > > > platform and it works here and there and every where. >> > > >> > > The fact that only Linux uses it makes it Linux specific. >> > > >> > > > > To expand even further on that, it means we should put 'managed = "in-band-status"' >> > > > > in U-Boot, which is a Linux phylink device tree property, even if U-Boot >> > > > > does not use phylink? >> > > > >> > > > We should be able to drop in the device trees from Linux and use them. >> > > > Custodians should be re-syncing them periodically. Some are, even. >> > > >> > > Are you ready to take up device tree bindings for PTP timers, PCIe root >> > > complex event collectors, cascaded interrupt controllers, things which >> > > U-Boot will never ever need to support? >> > > >> > > At least in Linux there is a policy to not add device tree nodes that do >> > > not have drivers. Is the same policy not true for U-Boot? At least your >> > > ./scripts/checkpatch.pl does have the same "check for DT compatible >> > > documentation" section as Linux. You might consider removing it if you >> > > want people to not strip the DTs they submit to U-Boot. >> > > >> > > And why do we even maintain the device tree bindings in Linux at all? >> > > It seems rather counter-productive for both ends to do that, if it is >> > > expected that the kernel works with DT blobs provided by third parties too, >> > > and if all third parties need to resync with it (there are other boot >> > > loaders too beyond U-Boot, and other kernels beyond Linux). Somehow it >> > > doesn't feel right for the reference to be the Linux kernel. Maybe this >> > > is something that needs to be brought up with higher-level Linux maintainers. >> > > >> > > I have no problem at all with structuring the device tree in the same >> > > way in U-Boot as in Linux, as long as that proves to not be a foolish >> > > endeavor. >> > >> > DT is ABI is hardware description and OS-agnostic has been the rule for >> > 10+ years. If that's no longer the case, can someone please tell me? >> >> So if Michael's board with DT provided by U-Boot doesn't work for some >> stupid reason like "Linux expects the pcie node to be under /soc", or >> "Linux wants all PCIe BARs of a RCIEP ECAM to be spelled out in the >> 'ranges' property, because it's too dumb to detect them itself", or >> something like that, I've got no argument against that, let's go ahead >> and resync U-Boot with Linux. >> >> But "DT is ABI is hardware description" is a pretty vague truism that >> does not actually help here. > >I'm saying that because it's what's been said for what feels like 10+ >years. I don't want to think how many countless hours have been spent >on that point at conferences over the years. It's not even a Linux >thing. I would swear you can (or could, unless it got broken) take the >same DTB for some platforms and boot Linux or FreeBSD or some other BSD >or maybe even VxWorks and it works. > > I cannot agree more. For historical reasons in the embedded market, the product maker was the board maker, the distro producer and the firmware producer. That led to a situation where the Linux kernel developper was stating the hardware description and that led to...problems. The best analogy I have to describe how wrong this is: As a French driver, my Device Tree description about the car is that the steering wheel is on the left hand side of the car; when entering an English car, I just complain that the wheel is not where it should be. Now the value chain is going more "mature" and your may end up booting a Fedora IoT edition on a bunch of platforms that have been designed to boot any distro; and the Trusted Applications may come from the OEM and not the board maker. Organizing the software value chain along side of the hardware value chain (Silicon provider, SoM provider, Carrier provider, Integrator, Car manufacturer for instance) need DT technology and lifecycle re-boot. (softwsystem up firmware such as Trusted Firmware, boot firmware such as U-Boot and operating systems) Some elements of discussion can be found here: https://linaro.atlassian.net/wiki/spaces/DTE/overview https://docs.google.com/document/d/1CLkhLRaz_zcCq44DLGmPZQFPbYHOC6nzPowaL0X… If we take the https://www.solid-run.com/arm-servers-networking-platforms/honeycomb-workst… board as an example to stay on NXP SoCs: what is the ideal way to deal with device tree should we start from a blank sheet? A key element are SerDes pins: from a SoC perspective they can be made PCI lanes or Ethernet lanes. This is chosen by the board vendor. An operating system should never manage the SerDes, it will see either the PCI lanes or the Ethernet port (not exactly true yet because of DPAA2 - but let's keep it high level). It is the responsibility of the firmware to actually match the SoC configuration with board layout (PCI slot, PCI device, Ethernet port). In my mind, the ideal situation is: The board vendor takes the SoC DT as input and applies fixups (at design time or runtime) to produce the board DT. The board DT should be independent from the firmware stack (Coreboot, TF-A+U-Boot, TF-A + LinuxBoot) and the booted OS: it is just describing the hardware!!! Firmware elements can still apply fixes at runtime: TF-A role is to pass detected DRAM, U-Boot may have a parameter (saved as U-Boot variable) to define active cores and ensures the DT is fixed up to match that desire, OP-TEE can expose the amount of Secure DRAM it has carved out through FF-A API. >> Will you accept device trees with devices for which a driver will never >> probe in U-Boot, > >Yes, I will absolutely take device trees that have devices we don't need >in U-Boot since the point is, and many SoC vendors are doing (and the >ones that aren't are, I am not happy about / with) right now. > >> and will you remove the checkpatch warnings about those, >> to not discourage people from submitting them prior to the actual public >> review? > >With respect to checkpatch.pl, maybe I'm just missing the line in >question? Or maybe it's a kernel-related warning we need to disable in >our .checkpatch.conf. But I don't want to side-track over this part. > >> If a U-Boot driver will be written for a device that does not have a >> driver yet in Linux, then the Linux driver will be written but with >> DT bindings incompatible with what was established in U-Boot, will you >> wake up the U-Boot developer from the grave and ask them to resync the >> driver to follow Linux? Or will you accept drivers at all for hardware >> that is not supported by Linux? > >What I've said for years (but yes, I've missed changes, maybe the yaml >dt binding stuff would help so I could make CI fail or at least require >manual override?) is that U-Boot will take immature bindings but it's on >the developer to re-sync once the bindings are fully reviewed. This is >to help with the chicken-and-egg problem. But old bindings are not >intended to be supported, once it's finalized. That is part of the >bargain. > >> I also think there are various degrees of what it means "to work" with a >> device tree provided directly by U-Boot. Distros like Arch Linux ARM >> have a package for device tree blobs, and it is expected that these are >> updated by the distro, and U-Boot just loads them. As Michael points out, >> the DT provided by U-Boot is just a fallback. The OS should boot to >> prompt and have a network connection to set itself up properly again. >> But we need to draw a harder line on what we _actually_ desire to work >> beyond that. > >Every distribution has a package for device tree binaries, because >that's how you get a device tree on the still vast majority of platforms >that don't ship one in-flash (RPis being the modern exception) and to my >knowledge none of them are happy about having to build and pass and make >sure the right one is used on a given board at boot. So yes, U-Boot >being able to pass a device tree on to the next stage is one of those >things to help everything Just Work and be boring. > >-- >Tom

4 years, 4 months

1
0
0 0

systemd's sd-boot: devicetree command using EFI_DT_FIXUP_PROTOCOL

by Heinrich Schuchardt

For systemd's GRUB replacement sd-boot there is a pull request for adding a devicetree command. The command calls the EFI_DT_FIXUP_PROTOCOL implemented in U-Boot for fixing up device-trees. Best regards Heinrich sd-boot: Support installing new devicetree https://github.com/systemd/systemd/pull/19417/commits/3c717de49ec35c2684653… EFI_DT_FIXUP_PROTOCOL specification https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL

4 years, 4 months

1
0
0 0

No DT Evo call for Aug 23

by Bill Mills

All, I am on vacation this week and will not host the DT Evo call. See you in 2 weeks. BIll -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

4 years, 4 months

1
0
0 0

EBBR Cancelled for 16th Aug 2021

by Grant Likely

Hi all, Sorry for the last minute notice, but I need to cancel the EBBR meeting due to a conflict that I cannot move. 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.

4 years, 4 months

1
0
0 0

eBPF as replacement for UEFi EBC and ACPI AML

by François Ozog

This: https://linuxfoundation.org/press-release/facebook-google-isovalent-microso… Following earlier addition of eBPF in Windows kernel: https://github.com/microsoft/ebpf-for-windows Makes me think that the crazy idea I talked about a couple of months ago (subject of the mail) may not be that crazy…. Cheers FF -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.ozog(a)linaro.org | Skype: ffozog

4 years, 4 months

3
6
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

boot-architecture