Le mer. 20 mai 2020 à 17:37, Daniel Thompson daniel.thompson@linaro.org 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 frowand.list@gmail.com
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%20Stati...
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:
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.