Hello Francois,
in a previous post I already mentioned some device tree fix-ups that U-Boot is applying.
One new fix-up I found is the "cpu-release-addr" property in CPU nodes if the "enable-method" is "spin-table". - Before seeing this I never imagined CPU nodes to be dynamically filled.
I think for our DTE discussion on signed device trees it would be valuable to know which parts of the device-tree are dynamically created. Where would be a good location to collect this information?
Would the topic of dynamic parts of device trees deserve two slides on our next meeting?
Best regards
Heinrich
Le ven. 15 mai 2020 à 01:45, Heinrich Schuchardt xypron.glpk@gmx.de a écrit :
Hello Francois,
in a previous post I already mentioned some device tree fix-ups that U-Boot is applying.
One new fix-up I found is the "cpu-release-addr" property in CPU nodes if the "enable-method" is "spin-table". - Before seeing this I never imagined CPU nodes to be dynamically filled.
I think for our DTE discussion on signed device trees it would be valuable to know which parts of the device-tree are dynamically created. Where would be a good location to collect this information?
there is a Collaborate space dedicated to DTE project. In principle it is fully open. Let’s organize the information here. I say in principle because Simon Glass reports issues accessing it. Let’s get the help from Linaro IT to get it solved.
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 .
Best regards
Heinrich
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...
Best regards
Heinrich
On Sat, 16 May 2020 at 15:46, Heinrich Schuchardt xypron.glpk@gmx.de 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...
Great presentation! looking forward you talk to it.
If we were to define a UML sequence diagram with regards to firmware, what would be the actors and the classes?
From all past discussions, I am trying to find a name for the function
that U-Boot does. I would like to avoid "boot loader" because it may mean too many things. Thinking about areas of responsibility, I distinguish "firmware" and "operating system" (loosely defined). U-Boot becomes the pivot function between "firmware" and "OS".
I thus see two domains for DT manipulations (fixups, overlay merge or list-add): - what happens between firmware components (SMM, Trusted OS, Secure partitions...) -- what happens in the hand off between firmware and OS (and conversely)
Do you think you could add some slides to present your ideas around the above topics?
Best regards
Heinrich
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:
https://elinux.org/Device_tree_plumbers_2016_etherpad
-Frank
Best regards
Heinrich _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
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. '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.
Regards, Simon
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.
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.
On Wed, 20 May 2020 at 09:45, François Ozog francois.ozog@linaro.org wrote:
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.
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 francois.ozog@linaro.org | Skype: ffozog
Hi Francois,
On 5/15/20 12:10 AM, François Ozog wrote:
Le ven. 15 mai 2020 à 01:45, Heinrich Schuchardt xypron.glpk@gmx.de a écrit :
Hello Francois,
in a previous post I already mentioned some device tree fix-ups that U-Boot is applying.
One new fix-up I found is the "cpu-release-addr" property in CPU nodes if the "enable-method" is "spin-table". - Before seeing this I never imagined CPU nodes to be dynamically filled.
I think for our DTE discussion on signed device trees it would be valuable to know which parts of the device-tree are dynamically created. Where would be a good location to collect this information?
there is a Collaborate space dedicated to DTE project. In principle it is fully open. Let’s organize the information here. I say in principle because Simon Glass reports issues accessing it. Let’s get the help from Linaro IT to get it solved.
Where is the Collaborate space? How do I get access to it?
-Frank
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 .
Best regards
Heinrich
Hi Frank,
DTE is one of the projects that Linaro voted to fully open. I am still in the process of making that happen and working with IT.
I’ll post links ASAP
Cheers
FF
Le mar. 19 mai 2020 à 04:54, Frank Rowand frowand.list@gmail.com a écrit :
Hi Francois,
On 5/15/20 12:10 AM, François Ozog wrote:
Le ven. 15 mai 2020 à 01:45, Heinrich Schuchardt xypron.glpk@gmx.de a écrit :
Hello Francois,
in a previous post I already mentioned some device tree fix-ups that U-Boot is applying.
One new fix-up I found is the "cpu-release-addr" property in CPU nodes if the "enable-method" is "spin-table". - Before seeing this I never imagined CPU nodes to be dynamically filled.
I think for our DTE discussion on signed device trees it would be valuable to know which parts of the device-tree are dynamically created. Where would be a good location to collect this information?
there is a Collaborate space dedicated to DTE project. In principle it is fully open. Let’s organize the information here. I say in principle
because
Simon Glass reports issues accessing it. Let’s get the help from Linaro
IT
to get it solved.
Where is the Collaborate space? How do I get access to it?
-Frank
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 .
Best regards
Heinrich
--
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
boot-architecture@lists.linaro.org
-
Daniel Thompson -
Frank Rowand -
François Ozog -
Heinrich Schuchardt -
Simon Glass