On Wed, 20 May 2020 at 09:45, François Ozog <[email protected]> wrote:
> > > Le mer. 20 mai 2020 à 17:37, Daniel Thompson <[email protected]> > a écrit : > >> On Wed, May 20, 2020 at 08:59:04AM -0600, Simon Glass wrote: >> > Hi, >> > >> > On Tue, 19 May 2020 at 20:34, Frank Rowand <[email protected]> >> wrote: >> > > >> > > Hi Heinrich, >> > > >> > > On 5/16/20 8:46 AM, Heinrich Schuchardt wrote: >> > > > On 5/15/20 7:10 AM, François Ozog wrote: >> > > > <snip> >> > > >> Would the topic of dynamic parts of device trees deserve two >> slides on >> > > >> our next meeting? >> > > >> >> > > >> This is a key topic that probably deserves more than two slides. >> Please >> > > >> prepare a presentation as you deem fit . >> > > >> >> > > > >> > > > You can find my ideas about why device trees are not static here: >> > > > >> > > > >> https://github.com/xypron/dte/blob/master/Device%20Trees%20Are%20Not%20Static.pdf >> > > >> > > There is some useful information on what you highlight in the >> "Conclusion" slide at >> > > the 2016 Linux Plumbers conference. The slides that were used in the >> specific >> > > session are at: >> > > >> > > https://elinux.org/images/9/99/Dt_hw_config_policy.pdf >> > > >> > > The discussion of the slides was captured on etherpad in the section >> labeled >> > > "Device Tree: Hardware Description vs. Configuration vs. Policy by >> Frank Rowand" >> > > at: >> > > >> > > https://elinux.org/Device_tree_plumbers_2016_etherpad >> > >> > Good to see these slides, and Heinrich's are a good cover of the >> > problem I think. >> > >> > I don't have anything much to say but look forward to the discussion. >> > It seems that the 'hard line' about describing 'only hardware' in the >> > DT might be softening, and if so, that it all to the good IMO. >> > >> > I like the term bootloader as it is well understood and it is what >> > U-Boot does. >> >> The big problem with the term bootloader is that is also the B in >> GRUB. >> > I started to use the term “pivot function” (from what is considered > firmware and whatever payload). The pivot function can be offered by > U-Boot, LinuxBoot, Xen when they are BL33 payload. BL33 is TF-A specific so > that’s why I sought another term. The booted payload can be an > EFIBootloader (EFIbootguard), à generic boot loader (grub), shim, directly > Linux. > Sounds reasonable. > >> In other words when we talk about bootloaders (without some prefix) then >> it is ambiguous whether we describe part of the system firmware or an >> EFI payload provided by the OS. >> > I hadn't thought of that. But even U-Boot can operate as a payload of something else - e.g. Slim bootloader. U-Boot is generally described as a bootloader. It's just that it can extend from the reset vector to the OS start, or not, depending on the circumstances. So by Francois' definition, the U-Boot bootloader is both firmware and a payload, which seems a bit confusing. But I suppose it is accurate. - Simon > >> >> > 'Firmware' is so generic that it could apply to the >> > touchscreen firmware. But I suppose I use the term 'firmware' for all >> > the firmware in the device, including the whole AP firmware image - >> > bootloader, signatures, binary blobs, etc. Perhaps that is what you >> > are saying. >> >> I guess the major benefit of firmware is that at least most people know >> that it is ambiguous! Thus when the distinction really matters people >> typically adopt the "system firmware" terminology often found in the >> UEFI spec. > > >> >> As it happens the EBBR spec is pretty relaxed and makes heavy use of >> firmware without any prefix. Perhaps it might benefit from defining >> it (the UEFI Glossary definition of "firmware" makes little sense >> on many embedded systems). >> >> >> Daniel. >> > -- > François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* > T: +33.67221.6485 > [email protected] | Skype: ffozog > > _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
