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. > > 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. > > > > '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
