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