Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
Hi Ilias, On Tue, 2 Nov 2021 at 09:38, Ilias Apalodimas wrote: > > Hi Simon, > > [...] > > > > > > > > > > > > > > > > Why me? Perhaps Linaro could take this on instead of working in a > > > > > > separate tool and domain? You guys could really pull things together > > > > > > and reduce the fragmentation, if you took it on. > > > > > > > > > > > > Honestly it is hard enough to even get Linaro people to write a test > > > > > > for code they have written. What gives? > > > > > > > > > > That's completely inaccurate. We've added selftests for *every* > > > > > single feature we've sent for EFI up to now. Functionality wise the > > > > > past 2 years we've added > > > > > - EFI variables > > > > > - EFI secure boot > > > > > - capsule updates > > > > > - initrd loading > > > > > - efi TCG protocol > > > > > - ESRT tables > > > > > - RNG protocol > > > > > > > > > > 5a24239c951e8 efi_loader: selftest: enable APPEND_WRITE tests > > > > > 3fc2b16335721 cmd: bootefi: carve out efi_selftest code from > > > > > do_bootefi() > > > > > 1170fee695197 efi_selftest: fix variables test for > > > > > GetNextVariableName() > > > > > ce62b0f8f45f1 test/py: Fix efidebug related tests > > > > > 450596f2ac3fd test/py: efi_capsule: test for FIT image capsule > > > > > de489d82e3189 test: test the ESRT creation > > > > > 57be8cdce35 test/py: efi_secboot: small rework for adding a new test > > > > > e1174c566a61c test/py: efi_secboot: add test for intermediate > > > > > certificates > > > > > 479ab6c17eda7 efi_selftest: add selftests for loadfile2 used to load > > > > > initramfs > > > > > > > > > > and I am pretty sure I am forgetting more on functionality and > > > > > selftests. > > > > > > > > > > So basically we've either contributed new selftests for *everything* > > > > > we've or fixed the existing ones. The only thing that's not merged is > > > > > the TCG selftests which are on upstream review. > > > > > > > > Er, I didn't say or mean that no tests were written, just that there > > > > is too much push-back on it. Heinrich put a huge amount of effort into > > > > > > There's no pushback at all, apart from the TPM one. (and for a very good > > > reason I've explained over and over again). In fact we add the sefltests > > > as part of our patchsets. > > > > > > > the tests and basically created a strong base for it. Congrats and > > > > huge kudos to him. As to Linaro, no offence intended, and it is great > > > > that all these tests have been added. Thank you for your efforts and > > > > it is very helpful. But I think you miss my point. Or perhaps you > > > > don't even agree with it? I sent an email about this on one patch just > > > > a day or two ago. > > > > > > I guess you mean [1]. I've lost count of how many times I responded to > > > this. Threads [2], [3] and [4] are just a few examples, so I just got > > > tired or replying the same thing over and over. > > > > > > So bottom line, we are contributing selftests as always, we just don't > > > agree > > > with the way *you* want this specific TPM test, trying to force us into > > > sandbox. > > > So instead of respecting what we have (which btw is acceptable from > > > u-boot's > > > perspective and cleans up a lot of the TPM crud along the way), you went > > > ahead > > > making misleading statements on the selftests we contribute, in general. > > > What's > > > even more annoying is that, as I showed you, we pretty much add a selftest > > > for *every* feature we add. Excellent ... that's certainly ... > > > encouraging ... and > > > very productive. > > > > > > > > > > > As to the leadership side (my bigger point), Linaro is leading us all > > > > down this fragmented path, with TF-A, FIP, more and more binaries and > > > > larger firmware diagrams. Or do you disagree with that too? > > > > > > > > > > Of course I disagree. People decided not to use SPL for their own > > > reasons. > > > I am certainly not qualified to answer why Arm choose to do that, but it > > > seems > > > to be common nowdays (risc-v/OpenSBI). All Linaro is doing is making sure > > > U-Boot is compatible and remains the de-facto choice for embedded boot > > > loaders playing nicely with all the new FSBLs come up with. If you > > > cosinder SPL and U-Boot the center of the known universe, we certainly > > > view > > > things differently. FWIW it's *our* work mostly that made U-Boot > > > SystemReady > > > compliant, which is something Arm pushes for [5]. > > > > > > > I'm sorry if you find this a bit sharp. > > > > > > Which part? The first one wrt to selftests is not sharp. It's > > > manipulative and utterly unacceptable for me, not to mention entirely > > > fabricated. > > > > > > The latter on bootloading fragmentation, I am always happy to discuss. > > > > My comment was about the push-back I feel I have received when > > requesting tests. It was a poor choice of words since it suggests this > > is an ongoing problem when in fact many tests have been w
Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
Hi Simon, [...] > > > > > > > > > > > > Why me? Perhaps Linaro could take this on instead of working in a > > > > > separate tool and domain? You guys could really pull things together > > > > > and reduce the fragmentation, if you took it on. > > > > > > > > > > Honestly it is hard enough to even get Linaro people to write a test > > > > > for code they have written. What gives? > > > > > > > > That's completely inaccurate. We've added selftests for *every* > > > > single feature we've sent for EFI up to now. Functionality wise the > > > > past 2 years we've added > > > > - EFI variables > > > > - EFI secure boot > > > > - capsule updates > > > > - initrd loading > > > > - efi TCG protocol > > > > - ESRT tables > > > > - RNG protocol > > > > > > > > 5a24239c951e8 efi_loader: selftest: enable APPEND_WRITE tests > > > > 3fc2b16335721 cmd: bootefi: carve out efi_selftest code from > > > > do_bootefi() > > > > 1170fee695197 efi_selftest: fix variables test for GetNextVariableName() > > > > ce62b0f8f45f1 test/py: Fix efidebug related tests > > > > 450596f2ac3fd test/py: efi_capsule: test for FIT image capsule > > > > de489d82e3189 test: test the ESRT creation > > > > 57be8cdce35 test/py: efi_secboot: small rework for adding a new test > > > > e1174c566a61c test/py: efi_secboot: add test for intermediate > > > > certificates > > > > 479ab6c17eda7 efi_selftest: add selftests for loadfile2 used to load > > > > initramfs > > > > > > > > and I am pretty sure I am forgetting more on functionality and > > > > selftests. > > > > > > > > So basically we've either contributed new selftests for *everything* > > > > we've or fixed the existing ones. The only thing that's not merged is > > > > the TCG selftests which are on upstream review. > > > > > > Er, I didn't say or mean that no tests were written, just that there > > > is too much push-back on it. Heinrich put a huge amount of effort into > > > > There's no pushback at all, apart from the TPM one. (and for a very good > > reason I've explained over and over again). In fact we add the sefltests > > as part of our patchsets. > > > > > the tests and basically created a strong base for it. Congrats and > > > huge kudos to him. As to Linaro, no offence intended, and it is great > > > that all these tests have been added. Thank you for your efforts and > > > it is very helpful. But I think you miss my point. Or perhaps you > > > don't even agree with it? I sent an email about this on one patch just > > > a day or two ago. > > > > I guess you mean [1]. I've lost count of how many times I responded to > > this. Threads [2], [3] and [4] are just a few examples, so I just got > > tired or replying the same thing over and over. > > > > So bottom line, we are contributing selftests as always, we just don't agree > > with the way *you* want this specific TPM test, trying to force us into > > sandbox. > > So instead of respecting what we have (which btw is acceptable from u-boot's > > perspective and cleans up a lot of the TPM crud along the way), you went > > ahead > > making misleading statements on the selftests we contribute, in general. > > What's > > even more annoying is that, as I showed you, we pretty much add a selftest > > for *every* feature we add. Excellent ... that's certainly ... > > encouraging ... and > > very productive. > > > > > > > > As to the leadership side (my bigger point), Linaro is leading us all > > > down this fragmented path, with TF-A, FIP, more and more binaries and > > > larger firmware diagrams. Or do you disagree with that too? > > > > > > > Of course I disagree. People decided not to use SPL for their own reasons. > > I am certainly not qualified to answer why Arm choose to do that, but it > > seems > > to be common nowdays (risc-v/OpenSBI). All Linaro is doing is making sure > > U-Boot is compatible and remains the de-facto choice for embedded boot > > loaders playing nicely with all the new FSBLs come up with. If you > > cosinder SPL and U-Boot the center of the known universe, we certainly view > > things differently. FWIW it's *our* work mostly that made U-Boot > > SystemReady > > compliant, which is something Arm pushes for [5]. > > > > > I'm sorry if you find this a bit sharp. > > > > Which part? The first one wrt to selftests is not sharp. It's > > manipulative and utterly unacceptable for me, not to mention entirely > > fabricated. > > > > The latter on bootloading fragmentation, I am always happy to discuss. > > My comment was about the push-back I feel I have received when > requesting tests. It was a poor choice of words since it suggests this > is an ongoing problem when in fact many tests have been written. So I > would like to withdraw that and I am sorry for saying that and for > upsetting you. I certainly agree that Linaro has written lots of tests > and this is great. Thank you to you and Linaro for that. The business > of how the tests are written can be handled in other threads. Thanks, I appreci
Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
Hi François, On Fri, 29 Oct 2021 at 11:07, François Ozog wrote: > > Hi Simon > > (I keep getting messages about delivery problems so I don't know what > went through or not) > > I got this one, anyway. > On Wed, 27 Oct 2021 at 21:52, Simon Glass wrote: > > > > Hi Ilias, > > > > On Wed, 27 Oct 2021 at 13:13, Ilias Apalodimas > > wrote: > > > > > > On Wed, 27 Oct 2021 at 21:33, Simon Glass wrote: > > > > > > > > Hi François, > > > > > > > > On Wed, 27 Oct 2021 at 09:38, François Ozog > > > > wrote: > > > > > > > > > > Hi Simon, > > > > > > > > > > On Wed, 27 Oct 2021 at 16:13, Simon Glass wrote: > > > > >> > > > > >> Hi François, > > > > >> > > > > >> On Tue, 26 Oct 2021 at 09:57, François Ozog > > > > >> wrote: > > > > >> > > > > > >> > > > > > >> > > > > > >> > On Tue, 26 Oct 2021 at 17:27, Simon Glass > > > > >> > wrote: > > > > >> >> > > > > >> >> Hi François, > > > > >> >> > > > > >> >> On Tue, 26 Oct 2021 at 08:31, François Ozog > > > > >> >> wrote: > > > > >> >> > > > > > >> >> > Hi Simon, > > > > >> >> > > > > > >> >> > On Tue, 26 Oct 2021 at 02:25, Simon Glass > > > > >> >> > wrote: > > > > >> >> >> > > > > >> >> >> At present some of the ideas and techniques behind devicetree > > > > >> >> >> in U-Boot > > > > >> >> >> are assumed, implied or unsaid. Add some documentation to > > > > >> >> >> cover how > > > > >> >> >> devicetree is build, how it can be modified and the rules > > > > >> >> >> about using > > > > >> >> >> the various CONFIG_OF_... options. > > > > >> >> >> > > > > >> > > > > >> [..] > > > > >> > > > > >> >> >> +Why not have two devicetrees? > > > > >> >> >> +- > > > > >> >> >> + > > > > >> >> >> +Setting aside the argument for restricting U-Boot from having > > > > >> >> >> its own nodes and > > > > >> >> >> +properties, another idea proposed is to have two devicetrees, > > > > >> >> >> one for the > > > > >> >> >> +U-Boot-specific bits (here called `special`) and one for > > > > >> >> >> everything else (here > > > > >> >> >> +called `linux`). > > > > >> >> >> + > > > > >> >> >> +On the positive side, it might quieten the discussion alluded > > > > >> >> >> to in the section > > > > >> >> >> +above. But there are many negatives to consider and many open > > > > >> >> >> questions to > > > > >> >> >> +resolve. > > > > >> >> >> + > > > > >> >> >> +- **Bindings** - Presumably the special devicetree would have > > > > >> >> >> its own bindings. > > > > >> >> >> + It would not be necessary to put a `u-boot,` prefix on > > > > >> >> >> anything. People coming > > > > >> >> >> + across the devicetree source would wonder how it fits in > > > > >> >> >> with the Linux > > > > >> >> >> + devicetree. > > > > >> >> >> + > > > > >> >> >> +- **Access** - U-Boot has a nice `ofnode` API for accessing > > > > >> >> >> the devicetree. This > > > > >> >> >> + would need to be expanded to support two trees. Features > > > > >> >> >> which need to access > > > > >> >> >> + both (such as a device driver which reads the special > > > > >> >> >> devicetree to get some > > > > >> >> >> + configuration info) could become quite confusing to read > > > > >> >> >> and write. > > > > >> >> >> + > > > > >> >> >> +- **Merging** - Can the two devicetree be merged if a > > > > >> >> >> platform desires it? If > > > > >> >> >> + so, how is this managed in tooling? Does it happen during > > > > >> >> >> the build, in which > > > > >> >> >> + case they are not really separate at all. Or does U-Boot > > > > >> >> >> merge them at > > > > >> >> >> + runtime, in which case this adds time and memory? > > > > >> >> >> + > > > > >> >> >> +- **Efficiency** - A second device tree adds more code and > > > > >> >> >> more code paths. It > > > > >> >> >> + requires that both be made available to the code in U-Boot, > > > > >> >> >> e.g. via a > > > > >> >> >> + separate pointer or argument or API. Overall the separation > > > > >> >> >> would certainly > > > > >> >> >> + not speed up U-Boot, nor decrease its size. > > > > >> >> >> + > > > > >> >> >> +- **Source code** - At present `u-boot.dtsi` files provide > > > > >> >> >> the pieces needed for > > > > >> >> >> + U-Boot for a particular board. Would we use these same > > > > >> >> >> files for the special > > > > >> >> >> + devicetree? > > > > >> >> >> + > > > > >> >> >> +- **Complexity** - Two devicetrees complicates the build > > > > >> >> >> system since it must > > > > >> >> >> + build and package them both. Errors must be reported in > > > > >> >> >> such a way that it > > > > >> >> >> + is obvious which one is failing. > > > > >> >> >> + > > > > >> >> >> +- **Referencing each other** - The `u-boot,dm-xxx` tags used > > > > >> >> >> by driver model > > > > >> >> >> + are currently placed in the nodes they relate to. How would > > > > >> >> >> these tags > > > > >> >> >> + reference a node that is in a separate devicetree? What > > > > >> >> >> extra validation would > > > > >> >> >
Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
Hi Ilias, On Fri, 29 Oct 2021 at 04:20, Ilias Apalodimas wrote: > > Hi Simon, > > [...] > > > > > > > > > Why me? Perhaps Linaro could take this on instead of working in a > > > > separate tool and domain? You guys could really pull things together > > > > and reduce the fragmentation, if you took it on. > > > > > > > > Honestly it is hard enough to even get Linaro people to write a test > > > > for code they have written. What gives? > > > > > > That's completely inaccurate. We've added selftests for *every* > > > single feature we've sent for EFI up to now. Functionality wise the > > > past 2 years we've added > > > - EFI variables > > > - EFI secure boot > > > - capsule updates > > > - initrd loading > > > - efi TCG protocol > > > - ESRT tables > > > - RNG protocol > > > > > > 5a24239c951e8 efi_loader: selftest: enable APPEND_WRITE tests > > > 3fc2b16335721 cmd: bootefi: carve out efi_selftest code from do_bootefi() > > > 1170fee695197 efi_selftest: fix variables test for GetNextVariableName() > > > ce62b0f8f45f1 test/py: Fix efidebug related tests > > > 450596f2ac3fd test/py: efi_capsule: test for FIT image capsule > > > de489d82e3189 test: test the ESRT creation > > > 57be8cdce35 test/py: efi_secboot: small rework for adding a new test > > > e1174c566a61c test/py: efi_secboot: add test for intermediate certificates > > > 479ab6c17eda7 efi_selftest: add selftests for loadfile2 used to load > > > initramfs > > > > > > and I am pretty sure I am forgetting more on functionality and selftests. > > > > > > So basically we've either contributed new selftests for *everything* > > > we've or fixed the existing ones. The only thing that's not merged is > > > the TCG selftests which are on upstream review. > > > > Er, I didn't say or mean that no tests were written, just that there > > is too much push-back on it. Heinrich put a huge amount of effort into > > There's no pushback at all, apart from the TPM one. (and for a very good > reason I've explained over and over again). In fact we add the sefltests > as part of our patchsets. > > > the tests and basically created a strong base for it. Congrats and > > huge kudos to him. As to Linaro, no offence intended, and it is great > > that all these tests have been added. Thank you for your efforts and > > it is very helpful. But I think you miss my point. Or perhaps you > > don't even agree with it? I sent an email about this on one patch just > > a day or two ago. > > I guess you mean [1]. I've lost count of how many times I responded to > this. Threads [2], [3] and [4] are just a few examples, so I just got > tired or replying the same thing over and over. > > So bottom line, we are contributing selftests as always, we just don't agree > with the way *you* want this specific TPM test, trying to force us into > sandbox. > So instead of respecting what we have (which btw is acceptable from u-boot's > perspective and cleans up a lot of the TPM crud along the way), you went ahead > making misleading statements on the selftests we contribute, in general. > What's > even more annoying is that, as I showed you, we pretty much add a selftest > for *every* feature we add. Excellent ... that's certainly ... encouraging > ... and > very productive. > > > > > As to the leadership side (my bigger point), Linaro is leading us all > > down this fragmented path, with TF-A, FIP, more and more binaries and > > larger firmware diagrams. Or do you disagree with that too? > > > > Of course I disagree. People decided not to use SPL for their own reasons. > I am certainly not qualified to answer why Arm choose to do that, but it seems > to be common nowdays (risc-v/OpenSBI). All Linaro is doing is making sure > U-Boot is compatible and remains the de-facto choice for embedded boot > loaders playing nicely with all the new FSBLs come up with. If you > cosinder SPL and U-Boot the center of the known universe, we certainly view > things differently. FWIW it's *our* work mostly that made U-Boot SystemReady > compliant, which is something Arm pushes for [5]. > > > I'm sorry if you find this a bit sharp. > > Which part? The first one wrt to selftests is not sharp. It's > manipulative and utterly unacceptable for me, not to mention entirely > fabricated. > > The latter on bootloading fragmentation, I am always happy to discuss. My comment was about the push-back I feel I have received when requesting tests. It was a poor choice of words since it suggests this is an ongoing problem when in fact many tests have been written. So I would like to withdraw that and I am sorry for saying that and for upsetting you. I certainly agree that Linaro has written lots of tests and this is great. Thank you to you and Linaro for that. The business of how the tests are written can be handled in other threads. > > > But someone needs to be > > pointing these things out. I don't know who else is doing so. ARM > > firmware has got noticeably more complicated and fragmented in the > > last f
Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
On Fri, Oct 29, 2021 at 01:20:52PM +0300, Ilias Apalodimas wrote: > Hi Simon, > > [...] > > > > > > > > > Why me? Perhaps Linaro could take this on instead of working in a > > > > separate tool and domain? You guys could really pull things together > > > > and reduce the fragmentation, if you took it on. > > > > > > > > Honestly it is hard enough to even get Linaro people to write a test > > > > for code they have written. What gives? > > > > > > That's completely inaccurate. We've added selftests for *every* > > > single feature we've sent for EFI up to now. Functionality wise the > > > past 2 years we've added > > > - EFI variables > > > - EFI secure boot > > > - capsule updates > > > - initrd loading > > > - efi TCG protocol > > > - ESRT tables > > > - RNG protocol > > > > > > 5a24239c951e8 efi_loader: selftest: enable APPEND_WRITE tests > > > 3fc2b16335721 cmd: bootefi: carve out efi_selftest code from do_bootefi() > > > 1170fee695197 efi_selftest: fix variables test for GetNextVariableName() > > > ce62b0f8f45f1 test/py: Fix efidebug related tests > > > 450596f2ac3fd test/py: efi_capsule: test for FIT image capsule > > > de489d82e3189 test: test the ESRT creation > > > 57be8cdce35 test/py: efi_secboot: small rework for adding a new test > > > e1174c566a61c test/py: efi_secboot: add test for intermediate certificates > > > 479ab6c17eda7 efi_selftest: add selftests for loadfile2 used to load > > > initramfs > > > > > > and I am pretty sure I am forgetting more on functionality and selftests. > > > > > > So basically we've either contributed new selftests for *everything* > > > we've or fixed the existing ones. The only thing that's not merged is > > > the TCG selftests which are on upstream review. > > > > Er, I didn't say or mean that no tests were written, just that there > > is too much push-back on it. Heinrich put a huge amount of effort into > > There's no pushback at all, apart from the TPM one. (and for a very good > reason I've explained over and over again). In fact we add the sefltests > as part of our patchsets. And, for that set of TPM things, I agree with NOT making sandbox the requirement there. As QEMU is able to provide a TPM that will see real world usage, that's what we need to validate against primarily. > > the tests and basically created a strong base for it. Congrats and > > huge kudos to him. As to Linaro, no offence intended, and it is great > > that all these tests have been added. Thank you for your efforts and > > it is very helpful. But I think you miss my point. Or perhaps you > > don't even agree with it? I sent an email about this on one patch just > > a day or two ago. > > I guess you mean [1]. I've lost count of how many times I responded to > this. Threads [2], [3] and [4] are just a few examples, so I just got > tired or replying the same thing over and over. > > So bottom line, we are contributing selftests as always, we just don't agree > with the way *you* want this specific TPM test, trying to force us into > sandbox. > So instead of respecting what we have (which btw is acceptable from u-boot's > perspective and cleans up a lot of the TPM crud along the way), you went ahead > making misleading statements on the selftests we contribute, in general. > What's > even more annoying is that, as I showed you, we pretty much add a selftest > for *every* feature we add. Excellent ... that's certainly ... encouraging > ... and > very productive. > > > > > As to the leadership side (my bigger point), Linaro is leading us all > > down this fragmented path, with TF-A, FIP, more and more binaries and > > larger firmware diagrams. Or do you disagree with that too? > > > > Of course I disagree. People decided not to use SPL for their own reasons. > I am certainly not qualified to answer why Arm choose to do that, but it seems > to be common nowdays (risc-v/OpenSBI). All Linaro is doing is making sure > U-Boot is compatible and remains the de-facto choice for embedded boot > loaders playing nicely with all the new FSBLs come up with. If you > cosinder SPL and U-Boot the center of the known universe, we certainly view > things differently. FWIW it's *our* work mostly that made U-Boot SystemReady > compliant, which is something Arm pushes for [5]. Let me say for the record that I am appreciative of the fact the Linaro has been putting so much effort in to U-Boot, both in terms of tests and also in general SystemReady compliance work. -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
Hi Simon (I keep getting messages about delivery problems so I don't know what went through or not) On Wed, 27 Oct 2021 at 21:52, Simon Glass wrote: > > Hi Ilias, > > On Wed, 27 Oct 2021 at 13:13, Ilias Apalodimas > wrote: > > > > On Wed, 27 Oct 2021 at 21:33, Simon Glass wrote: > > > > > > Hi François, > > > > > > On Wed, 27 Oct 2021 at 09:38, François Ozog > > > wrote: > > > > > > > > Hi Simon, > > > > > > > > On Wed, 27 Oct 2021 at 16:13, Simon Glass wrote: > > > >> > > > >> Hi François, > > > >> > > > >> On Tue, 26 Oct 2021 at 09:57, François Ozog > > > >> wrote: > > > >> > > > > >> > > > > >> > > > > >> > On Tue, 26 Oct 2021 at 17:27, Simon Glass wrote: > > > >> >> > > > >> >> Hi François, > > > >> >> > > > >> >> On Tue, 26 Oct 2021 at 08:31, François Ozog > > > >> >> wrote: > > > >> >> > > > > >> >> > Hi Simon, > > > >> >> > > > > >> >> > On Tue, 26 Oct 2021 at 02:25, Simon Glass > > > >> >> > wrote: > > > >> >> >> > > > >> >> >> At present some of the ideas and techniques behind devicetree in > > > >> >> >> U-Boot > > > >> >> >> are assumed, implied or unsaid. Add some documentation to cover > > > >> >> >> how > > > >> >> >> devicetree is build, how it can be modified and the rules about > > > >> >> >> using > > > >> >> >> the various CONFIG_OF_... options. > > > >> >> >> > > > >> > > > >> [..] > > > >> > > > >> >> >> +Why not have two devicetrees? > > > >> >> >> +- > > > >> >> >> + > > > >> >> >> +Setting aside the argument for restricting U-Boot from having > > > >> >> >> its own nodes and > > > >> >> >> +properties, another idea proposed is to have two devicetrees, > > > >> >> >> one for the > > > >> >> >> +U-Boot-specific bits (here called `special`) and one for > > > >> >> >> everything else (here > > > >> >> >> +called `linux`). > > > >> >> >> + > > > >> >> >> +On the positive side, it might quieten the discussion alluded > > > >> >> >> to in the section > > > >> >> >> +above. But there are many negatives to consider and many open > > > >> >> >> questions to > > > >> >> >> +resolve. > > > >> >> >> + > > > >> >> >> +- **Bindings** - Presumably the special devicetree would have > > > >> >> >> its own bindings. > > > >> >> >> + It would not be necessary to put a `u-boot,` prefix on > > > >> >> >> anything. People coming > > > >> >> >> + across the devicetree source would wonder how it fits in with > > > >> >> >> the Linux > > > >> >> >> + devicetree. > > > >> >> >> + > > > >> >> >> +- **Access** - U-Boot has a nice `ofnode` API for accessing the > > > >> >> >> devicetree. This > > > >> >> >> + would need to be expanded to support two trees. Features > > > >> >> >> which need to access > > > >> >> >> + both (such as a device driver which reads the special > > > >> >> >> devicetree to get some > > > >> >> >> + configuration info) could become quite confusing to read and > > > >> >> >> write. > > > >> >> >> + > > > >> >> >> +- **Merging** - Can the two devicetree be merged if a platform > > > >> >> >> desires it? If > > > >> >> >> + so, how is this managed in tooling? Does it happen during the > > > >> >> >> build, in which > > > >> >> >> + case they are not really separate at all. Or does U-Boot > > > >> >> >> merge them at > > > >> >> >> + runtime, in which case this adds time and memory? > > > >> >> >> + > > > >> >> >> +- **Efficiency** - A second device tree adds more code and more > > > >> >> >> code paths. It > > > >> >> >> + requires that both be made available to the code in U-Boot, > > > >> >> >> e.g. via a > > > >> >> >> + separate pointer or argument or API. Overall the separation > > > >> >> >> would certainly > > > >> >> >> + not speed up U-Boot, nor decrease its size. > > > >> >> >> + > > > >> >> >> +- **Source code** - At present `u-boot.dtsi` files provide the > > > >> >> >> pieces needed for > > > >> >> >> + U-Boot for a particular board. Would we use these same files > > > >> >> >> for the special > > > >> >> >> + devicetree? > > > >> >> >> + > > > >> >> >> +- **Complexity** - Two devicetrees complicates the build system > > > >> >> >> since it must > > > >> >> >> + build and package them both. Errors must be reported in such > > > >> >> >> a way that it > > > >> >> >> + is obvious which one is failing. > > > >> >> >> + > > > >> >> >> +- **Referencing each other** - The `u-boot,dm-xxx` tags used by > > > >> >> >> driver model > > > >> >> >> + are currently placed in the nodes they relate to. How would > > > >> >> >> these tags > > > >> >> >> + reference a node that is in a separate devicetree? What extra > > > >> >> >> validation would > > > >> >> >> + be needed? > > > >> >> >> + > > > >> >> >> +- **Storage** - How would the two devicetrees be stored in the > > > >> >> >> image? At present > > > >> >> >> + we simply concatenate the U-Boot binary and the devicetree. > > > >> >> >> We could add the > > > >> >> >> + special devicetree before the Linux one, so two are > > > >> >> >> concaten
Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
Hi Simon, [...] > > > > > > Why me? Perhaps Linaro could take this on instead of working in a > > > separate tool and domain? You guys could really pull things together > > > and reduce the fragmentation, if you took it on. > > > > > > Honestly it is hard enough to even get Linaro people to write a test > > > for code they have written. What gives? > > > > That's completely inaccurate. We've added selftests for *every* > > single feature we've sent for EFI up to now. Functionality wise the > > past 2 years we've added > > - EFI variables > > - EFI secure boot > > - capsule updates > > - initrd loading > > - efi TCG protocol > > - ESRT tables > > - RNG protocol > > > > 5a24239c951e8 efi_loader: selftest: enable APPEND_WRITE tests > > 3fc2b16335721 cmd: bootefi: carve out efi_selftest code from do_bootefi() > > 1170fee695197 efi_selftest: fix variables test for GetNextVariableName() > > ce62b0f8f45f1 test/py: Fix efidebug related tests > > 450596f2ac3fd test/py: efi_capsule: test for FIT image capsule > > de489d82e3189 test: test the ESRT creation > > 57be8cdce35 test/py: efi_secboot: small rework for adding a new test > > e1174c566a61c test/py: efi_secboot: add test for intermediate certificates > > 479ab6c17eda7 efi_selftest: add selftests for loadfile2 used to load > > initramfs > > > > and I am pretty sure I am forgetting more on functionality and selftests. > > > > So basically we've either contributed new selftests for *everything* > > we've or fixed the existing ones. The only thing that's not merged is > > the TCG selftests which are on upstream review. > > Er, I didn't say or mean that no tests were written, just that there > is too much push-back on it. Heinrich put a huge amount of effort into There's no pushback at all, apart from the TPM one. (and for a very good reason I've explained over and over again). In fact we add the sefltests as part of our patchsets. > the tests and basically created a strong base for it. Congrats and > huge kudos to him. As to Linaro, no offence intended, and it is great > that all these tests have been added. Thank you for your efforts and > it is very helpful. But I think you miss my point. Or perhaps you > don't even agree with it? I sent an email about this on one patch just > a day or two ago. I guess you mean [1]. I've lost count of how many times I responded to this. Threads [2], [3] and [4] are just a few examples, so I just got tired or replying the same thing over and over. So bottom line, we are contributing selftests as always, we just don't agree with the way *you* want this specific TPM test, trying to force us into sandbox. So instead of respecting what we have (which btw is acceptable from u-boot's perspective and cleans up a lot of the TPM crud along the way), you went ahead making misleading statements on the selftests we contribute, in general. What's even more annoying is that, as I showed you, we pretty much add a selftest for *every* feature we add. Excellent ... that's certainly ... encouraging ... and very productive. > > As to the leadership side (my bigger point), Linaro is leading us all > down this fragmented path, with TF-A, FIP, more and more binaries and > larger firmware diagrams. Or do you disagree with that too? > Of course I disagree. People decided not to use SPL for their own reasons. I am certainly not qualified to answer why Arm choose to do that, but it seems to be common nowdays (risc-v/OpenSBI). All Linaro is doing is making sure U-Boot is compatible and remains the de-facto choice for embedded boot loaders playing nicely with all the new FSBLs come up with. If you cosinder SPL and U-Boot the center of the known universe, we certainly view things differently. FWIW it's *our* work mostly that made U-Boot SystemReady compliant, which is something Arm pushes for [5]. > I'm sorry if you find this a bit sharp. Which part? The first one wrt to selftests is not sharp. It's manipulative and utterly unacceptable for me, not to mention entirely fabricated. The latter on bootloading fragmentation, I am always happy to discuss. > But someone needs to be > pointing these things out. I don't know who else is doing so. ARM > firmware has got noticeably more complicated and fragmented in the > last five years, hasn't it? What can Linaro do to address that? I am > very happy to help and provide part of the solution, but it needs a > shared vision. There's a TF-A mailing list, we can certainly engage there and try to align our ideas/designs. > > It's not even just a Linaro/ARM problem. On the x86 side it is fast > becoming a living nightmare. > > Perhaps the problem here is just the pandemic response and the > inability for people to get into a room and brainstorm / collaborate / > hack on ideas? I know you have made big efforts to engage, Ilias. We > have spoken many times and I'm sure f2f would be easier. > > > It's not even just a Linaro/ARM problem. On the x86 side it is fast > becoming a living
Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
Hi Tom Le mer. 27 oct. 2021 à 21:48, Tom Rini a écrit : > On Wed, Oct 27, 2021 at 05:38:28PM +0200, François Ozog wrote: > > Hi Simon, > > > > On Wed, 27 Oct 2021 at 16:13, Simon Glass wrote: > > > > > Hi François, > > > > > > On Tue, 26 Oct 2021 at 09:57, François Ozog > > > wrote: > > > > > > > > > > > > > > > > On Tue, 26 Oct 2021 at 17:27, Simon Glass wrote: > > > >> > > > >> Hi François, > > > >> > > > >> On Tue, 26 Oct 2021 at 08:31, François Ozog < > francois.o...@linaro.org> > > > wrote: > > > >> > > > > >> > Hi Simon, > > > >> > > > > >> > On Tue, 26 Oct 2021 at 02:25, Simon Glass > wrote: > > > >> >> > > > >> >> At present some of the ideas and techniques behind devicetree in > > > U-Boot > > > >> >> are assumed, implied or unsaid. Add some documentation to cover > how > > > >> >> devicetree is build, how it can be modified and the rules about > using > > > >> >> the various CONFIG_OF_... options. > > > >> >> > > > > > > [..] > > > > > > >> >> +Why not have two devicetrees? > > > >> >> +- > > > >> >> + > > > >> >> +Setting aside the argument for restricting U-Boot from having > its > > > own nodes and > > > >> >> +properties, another idea proposed is to have two devicetrees, > one > > > for the > > > >> >> +U-Boot-specific bits (here called `special`) and one for > everything > > > else (here > > > >> >> +called `linux`). > > > >> >> + > > > >> >> +On the positive side, it might quieten the discussion alluded > to in > > > the section > > > >> >> +above. But there are many negatives to consider and many open > > > questions to > > > >> >> +resolve. > > > >> >> + > > > >> >> +- **Bindings** - Presumably the special devicetree would have > its > > > own bindings. > > > >> >> + It would not be necessary to put a `u-boot,` prefix on > anything. > > > People coming > > > >> >> + across the devicetree source would wonder how it fits in with > the > > > Linux > > > >> >> + devicetree. > > > >> >> + > > > >> >> +- **Access** - U-Boot has a nice `ofnode` API for accessing the > > > devicetree. This > > > >> >> + would need to be expanded to support two trees. Features which > > > need to access > > > >> >> + both (such as a device driver which reads the special > devicetree > > > to get some > > > >> >> + configuration info) could become quite confusing to read and > > > write. > > > >> >> + > > > >> >> +- **Merging** - Can the two devicetree be merged if a platform > > > desires it? If > > > >> >> + so, how is this managed in tooling? Does it happen during the > > > build, in which > > > >> >> + case they are not really separate at all. Or does U-Boot merge > > > them at > > > >> >> + runtime, in which case this adds time and memory? > > > >> >> + > > > >> >> +- **Efficiency** - A second device tree adds more code and more > > > code paths. It > > > >> >> + requires that both be made available to the code in U-Boot, > e.g. > > > via a > > > >> >> + separate pointer or argument or API. Overall the separation > would > > > certainly > > > >> >> + not speed up U-Boot, nor decrease its size. > > > >> >> + > > > >> >> +- **Source code** - At present `u-boot.dtsi` files provide the > > > pieces needed for > > > >> >> + U-Boot for a particular board. Would we use these same files > for > > > the special > > > >> >> + devicetree? > > > >> >> + > > > >> >> +- **Complexity** - Two devicetrees complicates the build system > > > since it must > > > >> >> + build and package them both. Errors must be reported in such a > > > way that it > > > >> >> + is obvious which one is failing. > > > >> >> + > > > >> >> +- **Referencing each other** - The `u-boot,dm-xxx` tags used by > > > driver model > > > >> >> + are currently placed in the nodes they relate to. How would > these > > > tags > > > >> >> + reference a node that is in a separate devicetree? What extra > > > validation would > > > >> >> + be needed? > > > >> >> + > > > >> >> +- **Storage** - How would the two devicetrees be stored in the > > > image? At present > > > >> >> + we simply concatenate the U-Boot binary and the devicetree. We > > > could add the > > > >> >> + special devicetree before the Linux one, so two are > concatenated, > > > but it is > > > >> >> + not pretty. We could use binman to support more complex > > > arrangements, but only > > > >> >> + some boards use this at present, so it would be a big change. > > > >> >> + > > > >> >> +- **API** - How would another project provide two devicetree > files > > > to U-Boot at > > > >> >> + runtime? Presumably this would just be too painful. But if it > > > doesn't, it > > > >> >> + would be unable to configure run-time features of U-Boot > during > > > the boot. > > > >> >> + > > > >> >> +- **Confusion** - No other project has two devicetrees. U-Boot > > > would be in the > > > >> >> + unfortunate position of having to describe this fact to new > > > users, along with > > > >> >> + the (arguably contrived) reason for the arrangement. > > > >
Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
Hi Ilias, On Wed, 27 Oct 2021 at 13:13, Ilias Apalodimas wrote: > > On Wed, 27 Oct 2021 at 21:33, Simon Glass wrote: > > > > Hi François, > > > > On Wed, 27 Oct 2021 at 09:38, François Ozog > > wrote: > > > > > > Hi Simon, > > > > > > On Wed, 27 Oct 2021 at 16:13, Simon Glass wrote: > > >> > > >> Hi François, > > >> > > >> On Tue, 26 Oct 2021 at 09:57, François Ozog > > >> wrote: > > >> > > > >> > > > >> > > > >> > On Tue, 26 Oct 2021 at 17:27, Simon Glass wrote: > > >> >> > > >> >> Hi François, > > >> >> > > >> >> On Tue, 26 Oct 2021 at 08:31, François Ozog > > >> >> wrote: > > >> >> > > > >> >> > Hi Simon, > > >> >> > > > >> >> > On Tue, 26 Oct 2021 at 02:25, Simon Glass wrote: > > >> >> >> > > >> >> >> At present some of the ideas and techniques behind devicetree in > > >> >> >> U-Boot > > >> >> >> are assumed, implied or unsaid. Add some documentation to cover how > > >> >> >> devicetree is build, how it can be modified and the rules about > > >> >> >> using > > >> >> >> the various CONFIG_OF_... options. > > >> >> >> > > >> > > >> [..] > > >> > > >> >> >> +Why not have two devicetrees? > > >> >> >> +- > > >> >> >> + > > >> >> >> +Setting aside the argument for restricting U-Boot from having its > > >> >> >> own nodes and > > >> >> >> +properties, another idea proposed is to have two devicetrees, one > > >> >> >> for the > > >> >> >> +U-Boot-specific bits (here called `special`) and one for > > >> >> >> everything else (here > > >> >> >> +called `linux`). > > >> >> >> + > > >> >> >> +On the positive side, it might quieten the discussion alluded to > > >> >> >> in the section > > >> >> >> +above. But there are many negatives to consider and many open > > >> >> >> questions to > > >> >> >> +resolve. > > >> >> >> + > > >> >> >> +- **Bindings** - Presumably the special devicetree would have its > > >> >> >> own bindings. > > >> >> >> + It would not be necessary to put a `u-boot,` prefix on > > >> >> >> anything. People coming > > >> >> >> + across the devicetree source would wonder how it fits in with > > >> >> >> the Linux > > >> >> >> + devicetree. > > >> >> >> + > > >> >> >> +- **Access** - U-Boot has a nice `ofnode` API for accessing the > > >> >> >> devicetree. This > > >> >> >> + would need to be expanded to support two trees. Features which > > >> >> >> need to access > > >> >> >> + both (such as a device driver which reads the special > > >> >> >> devicetree to get some > > >> >> >> + configuration info) could become quite confusing to read and > > >> >> >> write. > > >> >> >> + > > >> >> >> +- **Merging** - Can the two devicetree be merged if a platform > > >> >> >> desires it? If > > >> >> >> + so, how is this managed in tooling? Does it happen during the > > >> >> >> build, in which > > >> >> >> + case they are not really separate at all. Or does U-Boot merge > > >> >> >> them at > > >> >> >> + runtime, in which case this adds time and memory? > > >> >> >> + > > >> >> >> +- **Efficiency** - A second device tree adds more code and more > > >> >> >> code paths. It > > >> >> >> + requires that both be made available to the code in U-Boot, > > >> >> >> e.g. via a > > >> >> >> + separate pointer or argument or API. Overall the separation > > >> >> >> would certainly > > >> >> >> + not speed up U-Boot, nor decrease its size. > > >> >> >> + > > >> >> >> +- **Source code** - At present `u-boot.dtsi` files provide the > > >> >> >> pieces needed for > > >> >> >> + U-Boot for a particular board. Would we use these same files > > >> >> >> for the special > > >> >> >> + devicetree? > > >> >> >> + > > >> >> >> +- **Complexity** - Two devicetrees complicates the build system > > >> >> >> since it must > > >> >> >> + build and package them both. Errors must be reported in such a > > >> >> >> way that it > > >> >> >> + is obvious which one is failing. > > >> >> >> + > > >> >> >> +- **Referencing each other** - The `u-boot,dm-xxx` tags used by > > >> >> >> driver model > > >> >> >> + are currently placed in the nodes they relate to. How would > > >> >> >> these tags > > >> >> >> + reference a node that is in a separate devicetree? What extra > > >> >> >> validation would > > >> >> >> + be needed? > > >> >> >> + > > >> >> >> +- **Storage** - How would the two devicetrees be stored in the > > >> >> >> image? At present > > >> >> >> + we simply concatenate the U-Boot binary and the devicetree. We > > >> >> >> could add the > > >> >> >> + special devicetree before the Linux one, so two are > > >> >> >> concatenated, but it is > > >> >> >> + not pretty. We could use binman to support more complex > > >> >> >> arrangements, but only > > >> >> >> + some boards use this at present, so it would be a big change. > > >> >> >> + > > >> >> >> +- **API** - How would another project provide two devicetree > > >> >> >> files to U-Boot at > > >> >> >> + runtime? Presumably this would just be too painful. But if it > > >> >> >> doesn't
Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
On Wed, Oct 27, 2021 at 05:38:28PM +0200, François Ozog wrote: > Hi Simon, > > On Wed, 27 Oct 2021 at 16:13, Simon Glass wrote: > > > Hi François, > > > > On Tue, 26 Oct 2021 at 09:57, François Ozog > > wrote: > > > > > > > > > > > > On Tue, 26 Oct 2021 at 17:27, Simon Glass wrote: > > >> > > >> Hi François, > > >> > > >> On Tue, 26 Oct 2021 at 08:31, François Ozog > > wrote: > > >> > > > >> > Hi Simon, > > >> > > > >> > On Tue, 26 Oct 2021 at 02:25, Simon Glass wrote: > > >> >> > > >> >> At present some of the ideas and techniques behind devicetree in > > U-Boot > > >> >> are assumed, implied or unsaid. Add some documentation to cover how > > >> >> devicetree is build, how it can be modified and the rules about using > > >> >> the various CONFIG_OF_... options. > > >> >> > > > > [..] > > > > >> >> +Why not have two devicetrees? > > >> >> +- > > >> >> + > > >> >> +Setting aside the argument for restricting U-Boot from having its > > own nodes and > > >> >> +properties, another idea proposed is to have two devicetrees, one > > for the > > >> >> +U-Boot-specific bits (here called `special`) and one for everything > > else (here > > >> >> +called `linux`). > > >> >> + > > >> >> +On the positive side, it might quieten the discussion alluded to in > > the section > > >> >> +above. But there are many negatives to consider and many open > > questions to > > >> >> +resolve. > > >> >> + > > >> >> +- **Bindings** - Presumably the special devicetree would have its > > own bindings. > > >> >> + It would not be necessary to put a `u-boot,` prefix on anything. > > People coming > > >> >> + across the devicetree source would wonder how it fits in with the > > Linux > > >> >> + devicetree. > > >> >> + > > >> >> +- **Access** - U-Boot has a nice `ofnode` API for accessing the > > devicetree. This > > >> >> + would need to be expanded to support two trees. Features which > > need to access > > >> >> + both (such as a device driver which reads the special devicetree > > to get some > > >> >> + configuration info) could become quite confusing to read and > > write. > > >> >> + > > >> >> +- **Merging** - Can the two devicetree be merged if a platform > > desires it? If > > >> >> + so, how is this managed in tooling? Does it happen during the > > build, in which > > >> >> + case they are not really separate at all. Or does U-Boot merge > > them at > > >> >> + runtime, in which case this adds time and memory? > > >> >> + > > >> >> +- **Efficiency** - A second device tree adds more code and more > > code paths. It > > >> >> + requires that both be made available to the code in U-Boot, e.g. > > via a > > >> >> + separate pointer or argument or API. Overall the separation would > > certainly > > >> >> + not speed up U-Boot, nor decrease its size. > > >> >> + > > >> >> +- **Source code** - At present `u-boot.dtsi` files provide the > > pieces needed for > > >> >> + U-Boot for a particular board. Would we use these same files for > > the special > > >> >> + devicetree? > > >> >> + > > >> >> +- **Complexity** - Two devicetrees complicates the build system > > since it must > > >> >> + build and package them both. Errors must be reported in such a > > way that it > > >> >> + is obvious which one is failing. > > >> >> + > > >> >> +- **Referencing each other** - The `u-boot,dm-xxx` tags used by > > driver model > > >> >> + are currently placed in the nodes they relate to. How would these > > tags > > >> >> + reference a node that is in a separate devicetree? What extra > > validation would > > >> >> + be needed? > > >> >> + > > >> >> +- **Storage** - How would the two devicetrees be stored in the > > image? At present > > >> >> + we simply concatenate the U-Boot binary and the devicetree. We > > could add the > > >> >> + special devicetree before the Linux one, so two are concatenated, > > but it is > > >> >> + not pretty. We could use binman to support more complex > > arrangements, but only > > >> >> + some boards use this at present, so it would be a big change. > > >> >> + > > >> >> +- **API** - How would another project provide two devicetree files > > to U-Boot at > > >> >> + runtime? Presumably this would just be too painful. But if it > > doesn't, it > > >> >> + would be unable to configure run-time features of U-Boot during > > the boot. > > >> >> + > > >> >> +- **Confusion** - No other project has two devicetrees. U-Boot > > would be in the > > >> >> + unfortunate position of having to describe this fact to new > > users, along with > > >> >> + the (arguably contrived) reason for the arrangement. > > >> >> + > > >> > > > >> > False: > > >> > 1) projects in trustedfirmware.org are built to have multiple FDT > > objects, some for "dynamic" configuration purposes. > > >> > > >> Can you provided a link and I can update this. > > > > > > > > https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html > > > Bindings: > > > for FCONF: > > https://trustedf
Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
Hi Simon, Le mer. 27 oct. 2021 à 20:33, Simon Glass a écrit : > Hi François, > > On Wed, 27 Oct 2021 at 09:38, François Ozog > wrote: > > > > Hi Simon, > > > > On Wed, 27 Oct 2021 at 16:13, Simon Glass wrote: > >> > >> Hi François, > >> > >> On Tue, 26 Oct 2021 at 09:57, François Ozog > wrote: > >> > > >> > > >> > > >> > On Tue, 26 Oct 2021 at 17:27, Simon Glass wrote: > >> >> > >> >> Hi François, > >> >> > >> >> On Tue, 26 Oct 2021 at 08:31, François Ozog < > francois.o...@linaro.org> wrote: > >> >> > > >> >> > Hi Simon, > >> >> > > >> >> > On Tue, 26 Oct 2021 at 02:25, Simon Glass > wrote: > >> >> >> > >> >> >> At present some of the ideas and techniques behind devicetree in > U-Boot > >> >> >> are assumed, implied or unsaid. Add some documentation to cover > how > >> >> >> devicetree is build, how it can be modified and the rules about > using > >> >> >> the various CONFIG_OF_... options. > >> >> >> > >> > >> [..] > >> > >> >> >> +Why not have two devicetrees? > >> >> >> +- > >> >> >> + > >> >> >> +Setting aside the argument for restricting U-Boot from having > its own nodes and > >> >> >> +properties, another idea proposed is to have two devicetrees, > one for the > >> >> >> +U-Boot-specific bits (here called `special`) and one for > everything else (here > >> >> >> +called `linux`). > >> >> >> + > >> >> >> +On the positive side, it might quieten the discussion alluded to > in the section > >> >> >> +above. But there are many negatives to consider and many open > questions to > >> >> >> +resolve. > >> >> >> + > >> >> >> +- **Bindings** - Presumably the special devicetree would have > its own bindings. > >> >> >> + It would not be necessary to put a `u-boot,` prefix on > anything. People coming > >> >> >> + across the devicetree source would wonder how it fits in with > the Linux > >> >> >> + devicetree. > >> >> >> + > >> >> >> +- **Access** - U-Boot has a nice `ofnode` API for accessing the > devicetree. This > >> >> >> + would need to be expanded to support two trees. Features which > need to access > >> >> >> + both (such as a device driver which reads the special > devicetree to get some > >> >> >> + configuration info) could become quite confusing to read and > write. > >> >> >> + > >> >> >> +- **Merging** - Can the two devicetree be merged if a platform > desires it? If > >> >> >> + so, how is this managed in tooling? Does it happen during the > build, in which > >> >> >> + case they are not really separate at all. Or does U-Boot merge > them at > >> >> >> + runtime, in which case this adds time and memory? > >> >> >> + > >> >> >> +- **Efficiency** - A second device tree adds more code and more > code paths. It > >> >> >> + requires that both be made available to the code in U-Boot, > e.g. via a > >> >> >> + separate pointer or argument or API. Overall the separation > would certainly > >> >> >> + not speed up U-Boot, nor decrease its size. > >> >> >> + > >> >> >> +- **Source code** - At present `u-boot.dtsi` files provide the > pieces needed for > >> >> >> + U-Boot for a particular board. Would we use these same files > for the special > >> >> >> + devicetree? > >> >> >> + > >> >> >> +- **Complexity** - Two devicetrees complicates the build system > since it must > >> >> >> + build and package them both. Errors must be reported in such a > way that it > >> >> >> + is obvious which one is failing. > >> >> >> + > >> >> >> +- **Referencing each other** - The `u-boot,dm-xxx` tags used by > driver model > >> >> >> + are currently placed in the nodes they relate to. How would > these tags > >> >> >> + reference a node that is in a separate devicetree? What extra > validation would > >> >> >> + be needed? > >> >> >> + > >> >> >> +- **Storage** - How would the two devicetrees be stored in the > image? At present > >> >> >> + we simply concatenate the U-Boot binary and the devicetree. We > could add the > >> >> >> + special devicetree before the Linux one, so two are > concatenated, but it is > >> >> >> + not pretty. We could use binman to support more complex > arrangements, but only > >> >> >> + some boards use this at present, so it would be a big change. > >> >> >> + > >> >> >> +- **API** - How would another project provide two devicetree > files to U-Boot at > >> >> >> + runtime? Presumably this would just be too painful. But if it > doesn't, it > >> >> >> + would be unable to configure run-time features of U-Boot > during the boot. > >> >> >> + > >> >> >> +- **Confusion** - No other project has two devicetrees. U-Boot > would be in the > >> >> >> + unfortunate position of having to describe this fact to new > users, along with > >> >> >> + the (arguably contrived) reason for the arrangement. > >> >> >> + > >> >> > > >> >> > False: > >> >> > 1) projects in trustedfirmware.org are built to have multiple FDT > objects, some for "dynamic" configuration purposes. > >> >> > >> >> Can you provided a link and I can update this. > >> > > >> > > h
Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
On Wed, 27 Oct 2021 at 21:33, Simon Glass wrote: > > Hi François, > > On Wed, 27 Oct 2021 at 09:38, François Ozog wrote: > > > > Hi Simon, > > > > On Wed, 27 Oct 2021 at 16:13, Simon Glass wrote: > >> > >> Hi François, > >> > >> On Tue, 26 Oct 2021 at 09:57, François Ozog > >> wrote: > >> > > >> > > >> > > >> > On Tue, 26 Oct 2021 at 17:27, Simon Glass wrote: > >> >> > >> >> Hi François, > >> >> > >> >> On Tue, 26 Oct 2021 at 08:31, François Ozog > >> >> wrote: > >> >> > > >> >> > Hi Simon, > >> >> > > >> >> > On Tue, 26 Oct 2021 at 02:25, Simon Glass wrote: > >> >> >> > >> >> >> At present some of the ideas and techniques behind devicetree in > >> >> >> U-Boot > >> >> >> are assumed, implied or unsaid. Add some documentation to cover how > >> >> >> devicetree is build, how it can be modified and the rules about using > >> >> >> the various CONFIG_OF_... options. > >> >> >> > >> > >> [..] > >> > >> >> >> +Why not have two devicetrees? > >> >> >> +- > >> >> >> + > >> >> >> +Setting aside the argument for restricting U-Boot from having its > >> >> >> own nodes and > >> >> >> +properties, another idea proposed is to have two devicetrees, one > >> >> >> for the > >> >> >> +U-Boot-specific bits (here called `special`) and one for everything > >> >> >> else (here > >> >> >> +called `linux`). > >> >> >> + > >> >> >> +On the positive side, it might quieten the discussion alluded to in > >> >> >> the section > >> >> >> +above. But there are many negatives to consider and many open > >> >> >> questions to > >> >> >> +resolve. > >> >> >> + > >> >> >> +- **Bindings** - Presumably the special devicetree would have its > >> >> >> own bindings. > >> >> >> + It would not be necessary to put a `u-boot,` prefix on anything. > >> >> >> People coming > >> >> >> + across the devicetree source would wonder how it fits in with the > >> >> >> Linux > >> >> >> + devicetree. > >> >> >> + > >> >> >> +- **Access** - U-Boot has a nice `ofnode` API for accessing the > >> >> >> devicetree. This > >> >> >> + would need to be expanded to support two trees. Features which > >> >> >> need to access > >> >> >> + both (such as a device driver which reads the special devicetree > >> >> >> to get some > >> >> >> + configuration info) could become quite confusing to read and > >> >> >> write. > >> >> >> + > >> >> >> +- **Merging** - Can the two devicetree be merged if a platform > >> >> >> desires it? If > >> >> >> + so, how is this managed in tooling? Does it happen during the > >> >> >> build, in which > >> >> >> + case they are not really separate at all. Or does U-Boot merge > >> >> >> them at > >> >> >> + runtime, in which case this adds time and memory? > >> >> >> + > >> >> >> +- **Efficiency** - A second device tree adds more code and more > >> >> >> code paths. It > >> >> >> + requires that both be made available to the code in U-Boot, e.g. > >> >> >> via a > >> >> >> + separate pointer or argument or API. Overall the separation would > >> >> >> certainly > >> >> >> + not speed up U-Boot, nor decrease its size. > >> >> >> + > >> >> >> +- **Source code** - At present `u-boot.dtsi` files provide the > >> >> >> pieces needed for > >> >> >> + U-Boot for a particular board. Would we use these same files for > >> >> >> the special > >> >> >> + devicetree? > >> >> >> + > >> >> >> +- **Complexity** - Two devicetrees complicates the build system > >> >> >> since it must > >> >> >> + build and package them both. Errors must be reported in such a > >> >> >> way that it > >> >> >> + is obvious which one is failing. > >> >> >> + > >> >> >> +- **Referencing each other** - The `u-boot,dm-xxx` tags used by > >> >> >> driver model > >> >> >> + are currently placed in the nodes they relate to. How would these > >> >> >> tags > >> >> >> + reference a node that is in a separate devicetree? What extra > >> >> >> validation would > >> >> >> + be needed? > >> >> >> + > >> >> >> +- **Storage** - How would the two devicetrees be stored in the > >> >> >> image? At present > >> >> >> + we simply concatenate the U-Boot binary and the devicetree. We > >> >> >> could add the > >> >> >> + special devicetree before the Linux one, so two are concatenated, > >> >> >> but it is > >> >> >> + not pretty. We could use binman to support more complex > >> >> >> arrangements, but only > >> >> >> + some boards use this at present, so it would be a big change. > >> >> >> + > >> >> >> +- **API** - How would another project provide two devicetree files > >> >> >> to U-Boot at > >> >> >> + runtime? Presumably this would just be too painful. But if it > >> >> >> doesn't, it > >> >> >> + would be unable to configure run-time features of U-Boot during > >> >> >> the boot. > >> >> >> + > >> >> >> +- **Confusion** - No other project has two devicetrees. U-Boot > >> >> >> would be in the > >> >> >> + unfortunate position of having to describe this fact to new > >> >> >> users, along with > >>
Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
Hi François, On Wed, 27 Oct 2021 at 09:38, François Ozog wrote: > > Hi Simon, > > On Wed, 27 Oct 2021 at 16:13, Simon Glass wrote: >> >> Hi François, >> >> On Tue, 26 Oct 2021 at 09:57, François Ozog wrote: >> > >> > >> > >> > On Tue, 26 Oct 2021 at 17:27, Simon Glass wrote: >> >> >> >> Hi François, >> >> >> >> On Tue, 26 Oct 2021 at 08:31, François Ozog >> >> wrote: >> >> > >> >> > Hi Simon, >> >> > >> >> > On Tue, 26 Oct 2021 at 02:25, Simon Glass wrote: >> >> >> >> >> >> At present some of the ideas and techniques behind devicetree in U-Boot >> >> >> are assumed, implied or unsaid. Add some documentation to cover how >> >> >> devicetree is build, how it can be modified and the rules about using >> >> >> the various CONFIG_OF_... options. >> >> >> >> >> [..] >> >> >> >> +Why not have two devicetrees? >> >> >> +- >> >> >> + >> >> >> +Setting aside the argument for restricting U-Boot from having its own >> >> >> nodes and >> >> >> +properties, another idea proposed is to have two devicetrees, one for >> >> >> the >> >> >> +U-Boot-specific bits (here called `special`) and one for everything >> >> >> else (here >> >> >> +called `linux`). >> >> >> + >> >> >> +On the positive side, it might quieten the discussion alluded to in >> >> >> the section >> >> >> +above. But there are many negatives to consider and many open >> >> >> questions to >> >> >> +resolve. >> >> >> + >> >> >> +- **Bindings** - Presumably the special devicetree would have its own >> >> >> bindings. >> >> >> + It would not be necessary to put a `u-boot,` prefix on anything. >> >> >> People coming >> >> >> + across the devicetree source would wonder how it fits in with the >> >> >> Linux >> >> >> + devicetree. >> >> >> + >> >> >> +- **Access** - U-Boot has a nice `ofnode` API for accessing the >> >> >> devicetree. This >> >> >> + would need to be expanded to support two trees. Features which need >> >> >> to access >> >> >> + both (such as a device driver which reads the special devicetree to >> >> >> get some >> >> >> + configuration info) could become quite confusing to read and write. >> >> >> + >> >> >> +- **Merging** - Can the two devicetree be merged if a platform >> >> >> desires it? If >> >> >> + so, how is this managed in tooling? Does it happen during the >> >> >> build, in which >> >> >> + case they are not really separate at all. Or does U-Boot merge them >> >> >> at >> >> >> + runtime, in which case this adds time and memory? >> >> >> + >> >> >> +- **Efficiency** - A second device tree adds more code and more code >> >> >> paths. It >> >> >> + requires that both be made available to the code in U-Boot, e.g. >> >> >> via a >> >> >> + separate pointer or argument or API. Overall the separation would >> >> >> certainly >> >> >> + not speed up U-Boot, nor decrease its size. >> >> >> + >> >> >> +- **Source code** - At present `u-boot.dtsi` files provide the pieces >> >> >> needed for >> >> >> + U-Boot for a particular board. Would we use these same files for >> >> >> the special >> >> >> + devicetree? >> >> >> + >> >> >> +- **Complexity** - Two devicetrees complicates the build system since >> >> >> it must >> >> >> + build and package them both. Errors must be reported in such a way >> >> >> that it >> >> >> + is obvious which one is failing. >> >> >> + >> >> >> +- **Referencing each other** - The `u-boot,dm-xxx` tags used by >> >> >> driver model >> >> >> + are currently placed in the nodes they relate to. How would these >> >> >> tags >> >> >> + reference a node that is in a separate devicetree? What extra >> >> >> validation would >> >> >> + be needed? >> >> >> + >> >> >> +- **Storage** - How would the two devicetrees be stored in the image? >> >> >> At present >> >> >> + we simply concatenate the U-Boot binary and the devicetree. We >> >> >> could add the >> >> >> + special devicetree before the Linux one, so two are concatenated, >> >> >> but it is >> >> >> + not pretty. We could use binman to support more complex >> >> >> arrangements, but only >> >> >> + some boards use this at present, so it would be a big change. >> >> >> + >> >> >> +- **API** - How would another project provide two devicetree files to >> >> >> U-Boot at >> >> >> + runtime? Presumably this would just be too painful. But if it >> >> >> doesn't, it >> >> >> + would be unable to configure run-time features of U-Boot during the >> >> >> boot. >> >> >> + >> >> >> +- **Confusion** - No other project has two devicetrees. U-Boot would >> >> >> be in the >> >> >> + unfortunate position of having to describe this fact to new users, >> >> >> along with >> >> >> + the (arguably contrived) reason for the arrangement. >> >> >> + >> >> > >> >> > False: >> >> > 1) projects in trustedfirmware.org are built to have multiple FDT >> >> > objects, some for "dynamic" configuration purposes. >> >> >> >> Can you provided a link and I can update this. >> > >> > https://trustedfirmware-a.re
Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
Hi Simon, On Wed, 27 Oct 2021 at 16:13, Simon Glass wrote: > Hi François, > > On Tue, 26 Oct 2021 at 09:57, François Ozog > wrote: > > > > > > > > On Tue, 26 Oct 2021 at 17:27, Simon Glass wrote: > >> > >> Hi François, > >> > >> On Tue, 26 Oct 2021 at 08:31, François Ozog > wrote: > >> > > >> > Hi Simon, > >> > > >> > On Tue, 26 Oct 2021 at 02:25, Simon Glass wrote: > >> >> > >> >> At present some of the ideas and techniques behind devicetree in > U-Boot > >> >> are assumed, implied or unsaid. Add some documentation to cover how > >> >> devicetree is build, how it can be modified and the rules about using > >> >> the various CONFIG_OF_... options. > >> >> > > [..] > > >> >> +Why not have two devicetrees? > >> >> +- > >> >> + > >> >> +Setting aside the argument for restricting U-Boot from having its > own nodes and > >> >> +properties, another idea proposed is to have two devicetrees, one > for the > >> >> +U-Boot-specific bits (here called `special`) and one for everything > else (here > >> >> +called `linux`). > >> >> + > >> >> +On the positive side, it might quieten the discussion alluded to in > the section > >> >> +above. But there are many negatives to consider and many open > questions to > >> >> +resolve. > >> >> + > >> >> +- **Bindings** - Presumably the special devicetree would have its > own bindings. > >> >> + It would not be necessary to put a `u-boot,` prefix on anything. > People coming > >> >> + across the devicetree source would wonder how it fits in with the > Linux > >> >> + devicetree. > >> >> + > >> >> +- **Access** - U-Boot has a nice `ofnode` API for accessing the > devicetree. This > >> >> + would need to be expanded to support two trees. Features which > need to access > >> >> + both (such as a device driver which reads the special devicetree > to get some > >> >> + configuration info) could become quite confusing to read and > write. > >> >> + > >> >> +- **Merging** - Can the two devicetree be merged if a platform > desires it? If > >> >> + so, how is this managed in tooling? Does it happen during the > build, in which > >> >> + case they are not really separate at all. Or does U-Boot merge > them at > >> >> + runtime, in which case this adds time and memory? > >> >> + > >> >> +- **Efficiency** - A second device tree adds more code and more > code paths. It > >> >> + requires that both be made available to the code in U-Boot, e.g. > via a > >> >> + separate pointer or argument or API. Overall the separation would > certainly > >> >> + not speed up U-Boot, nor decrease its size. > >> >> + > >> >> +- **Source code** - At present `u-boot.dtsi` files provide the > pieces needed for > >> >> + U-Boot for a particular board. Would we use these same files for > the special > >> >> + devicetree? > >> >> + > >> >> +- **Complexity** - Two devicetrees complicates the build system > since it must > >> >> + build and package them both. Errors must be reported in such a > way that it > >> >> + is obvious which one is failing. > >> >> + > >> >> +- **Referencing each other** - The `u-boot,dm-xxx` tags used by > driver model > >> >> + are currently placed in the nodes they relate to. How would these > tags > >> >> + reference a node that is in a separate devicetree? What extra > validation would > >> >> + be needed? > >> >> + > >> >> +- **Storage** - How would the two devicetrees be stored in the > image? At present > >> >> + we simply concatenate the U-Boot binary and the devicetree. We > could add the > >> >> + special devicetree before the Linux one, so two are concatenated, > but it is > >> >> + not pretty. We could use binman to support more complex > arrangements, but only > >> >> + some boards use this at present, so it would be a big change. > >> >> + > >> >> +- **API** - How would another project provide two devicetree files > to U-Boot at > >> >> + runtime? Presumably this would just be too painful. But if it > doesn't, it > >> >> + would be unable to configure run-time features of U-Boot during > the boot. > >> >> + > >> >> +- **Confusion** - No other project has two devicetrees. U-Boot > would be in the > >> >> + unfortunate position of having to describe this fact to new > users, along with > >> >> + the (arguably contrived) reason for the arrangement. > >> >> + > >> > > >> > False: > >> > 1) projects in trustedfirmware.org are built to have multiple FDT > objects, some for "dynamic" configuration purposes. > >> > >> Can you provided a link and I can update this. > > > > > https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html > > Bindings: > > for FCONF: > https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/fconf_properties.html > > for FF-A: > https://trustedfirmware-a.readthedocs.io/en/latest/components/ffa-manifest-binding.html > > For chain-of-trust: > https://trustedfirmware-a.readthedocs.io/en/latest/components/cot-binding.html > > > > For some code: > > > https://github.com/ARM-
Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
Hi François, On Tue, 26 Oct 2021 at 09:57, François Ozog wrote: > > > > On Tue, 26 Oct 2021 at 17:27, Simon Glass wrote: >> >> Hi François, >> >> On Tue, 26 Oct 2021 at 08:31, François Ozog wrote: >> > >> > Hi Simon, >> > >> > On Tue, 26 Oct 2021 at 02:25, Simon Glass wrote: >> >> >> >> At present some of the ideas and techniques behind devicetree in U-Boot >> >> are assumed, implied or unsaid. Add some documentation to cover how >> >> devicetree is build, how it can be modified and the rules about using >> >> the various CONFIG_OF_... options. >> >> [..] >> >> +Why not have two devicetrees? >> >> +- >> >> + >> >> +Setting aside the argument for restricting U-Boot from having its own >> >> nodes and >> >> +properties, another idea proposed is to have two devicetrees, one for the >> >> +U-Boot-specific bits (here called `special`) and one for everything else >> >> (here >> >> +called `linux`). >> >> + >> >> +On the positive side, it might quieten the discussion alluded to in the >> >> section >> >> +above. But there are many negatives to consider and many open questions >> >> to >> >> +resolve. >> >> + >> >> +- **Bindings** - Presumably the special devicetree would have its own >> >> bindings. >> >> + It would not be necessary to put a `u-boot,` prefix on anything. >> >> People coming >> >> + across the devicetree source would wonder how it fits in with the Linux >> >> + devicetree. >> >> + >> >> +- **Access** - U-Boot has a nice `ofnode` API for accessing the >> >> devicetree. This >> >> + would need to be expanded to support two trees. Features which need to >> >> access >> >> + both (such as a device driver which reads the special devicetree to >> >> get some >> >> + configuration info) could become quite confusing to read and write. >> >> + >> >> +- **Merging** - Can the two devicetree be merged if a platform desires >> >> it? If >> >> + so, how is this managed in tooling? Does it happen during the build, >> >> in which >> >> + case they are not really separate at all. Or does U-Boot merge them at >> >> + runtime, in which case this adds time and memory? >> >> + >> >> +- **Efficiency** - A second device tree adds more code and more code >> >> paths. It >> >> + requires that both be made available to the code in U-Boot, e.g. via a >> >> + separate pointer or argument or API. Overall the separation would >> >> certainly >> >> + not speed up U-Boot, nor decrease its size. >> >> + >> >> +- **Source code** - At present `u-boot.dtsi` files provide the pieces >> >> needed for >> >> + U-Boot for a particular board. Would we use these same files for the >> >> special >> >> + devicetree? >> >> + >> >> +- **Complexity** - Two devicetrees complicates the build system since it >> >> must >> >> + build and package them both. Errors must be reported in such a way >> >> that it >> >> + is obvious which one is failing. >> >> + >> >> +- **Referencing each other** - The `u-boot,dm-xxx` tags used by driver >> >> model >> >> + are currently placed in the nodes they relate to. How would these tags >> >> + reference a node that is in a separate devicetree? What extra >> >> validation would >> >> + be needed? >> >> + >> >> +- **Storage** - How would the two devicetrees be stored in the image? At >> >> present >> >> + we simply concatenate the U-Boot binary and the devicetree. We could >> >> add the >> >> + special devicetree before the Linux one, so two are concatenated, but >> >> it is >> >> + not pretty. We could use binman to support more complex arrangements, >> >> but only >> >> + some boards use this at present, so it would be a big change. >> >> + >> >> +- **API** - How would another project provide two devicetree files to >> >> U-Boot at >> >> + runtime? Presumably this would just be too painful. But if it doesn't, >> >> it >> >> + would be unable to configure run-time features of U-Boot during the >> >> boot. >> >> + >> >> +- **Confusion** - No other project has two devicetrees. U-Boot would be >> >> in the >> >> + unfortunate position of having to describe this fact to new users, >> >> along with >> >> + the (arguably contrived) reason for the arrangement. >> >> + >> > >> > False: >> > 1) projects in trustedfirmware.org are built to have multiple FDT objects, >> > some for "dynamic" configuration purposes. >> >> Can you provided a link and I can update this. > > https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html > Bindings: > for FCONF: > https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/fconf_properties.html > for FF-A: > https://trustedfirmware-a.readthedocs.io/en/latest/components/ffa-manifest-binding.html > For chain-of-trust: > https://trustedfirmware-a.readthedocs.io/en/latest/components/cot-binding.html > > For some code: > https://github.com/ARM-software/arm-trusted-firmware/blob/master/tools/fiptool/tbbr_config.c > From there you can wander and see how dynamic config sec
Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
On Tue, 26 Oct 2021 at 18:27, Simon Glass wrote: > > Hi Ilias, > > On Tue, 26 Oct 2021 at 08:06, Ilias Apalodimas > wrote: > > > > Hi Simon, > > > > > + > > > > [...] > > > > > +This is why `CONFIG_OF_SEPARATE` should always be used when building > > > U-Boot. > > > +The `CONFIG_OF_EMBED` option embeds the devicetree somewhere in the > > > U-Boot ELF > > > +image as rodata, meaning that it is hard to find it and it cannot > > > increase in > > > +size. > > > + > > > +When modifying the devicetree, the different cases to consider are as > > > follows: > > > + > > > +- CONFIG_OF_SEPARATE > > > +This is easy, described above. Just change, replace or rebuild the > > > +devicetree so it suits your needs, then rerun binman or redo the > > > `cat` > > > +operation to join `u-boot-nodtb.bin` and the new `u-boot.dtb` > > > + > > > +- CONFIG_OF_EMBED > > > +This is tricky, since the devicetree cannot easily be located. If > > > the EFL > > > +file is available, then the _dtb_dt_begin and __dtb_dt_end symbols > > > can be > > > +examined to find it. While it is possible to contract the file, it > > > is not > > > +possible to expand the file since that would involve re-linking > > > + > > > +- CONFIG_OF_BOARD > > > +This is a board-specific situation, so needs to be considered on a > > > +case-by-case base. The devicetree must be modified so that the > > > correct > > > +one is provided to U-Boot. How this is done depends entirely on the > > > +implementation of this option for the board. It might require > > > injecting the > > > +changes into a different project somehow using tooling available > > > there, or > > > +it might involve merging an overlay file at runtime to obtain the > > > desired > > > +result. > > > > I thought this document was trying to describe the current situation in > > U-Boot. If so, the current CONFIG_OF_BOARD usage is far from what we have > > here. > > Can you be more specific? What is the difference here? Also see the > doc update later in the series, after OF_BOARD becomes a bool option. The doc you sent says "devicetree must be modified so that the correct one is provided to U-Boot. By this I assume you mean the 'config/' node etc right? If that's the case this is *not* what is currently happening. We simply replace the entire device tree with whatever was configured. Regards /Ilias > > Regards, > SImon
Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
On Tue, 26 Oct 2021 at 17:27, Simon Glass wrote: > Hi François, > > On Tue, 26 Oct 2021 at 08:31, François Ozog > wrote: > > > > Hi Simon, > > > > On Tue, 26 Oct 2021 at 02:25, Simon Glass wrote: > >> > >> At present some of the ideas and techniques behind devicetree in U-Boot > >> are assumed, implied or unsaid. Add some documentation to cover how > >> devicetree is build, how it can be modified and the rules about using > >> the various CONFIG_OF_... options. > >> > >> Signed-off-by: Simon Glass > >> Reviewed-by: Marcel Ziswiler > >> --- > >> This patch attracted quite a bit of discussion here: > >> > >> > https://patchwork.ozlabs.org/project/uboot/patch/20210909201033.755713-4-...@chromium.org/ > >> > >> I have not included the text suggested by François. While I agree that > >> it would be useful to have an introduction in this space, I do not agree > >> that we should have two devicetrees or that U-Boot should not have its > own > >> things in the devicetree, so it is not clear to me what we should > actually > >> write. > >> > >> The 'Devicetree Control in U-Boot' docs were recently merged and these > >> provide some base info, for now. > >> > >> Changes in v5: > >> - Bring into the OF_BOARD series > >> - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed > >> - Refer to the 'control' DTB in the first paragraph > >> - Use QEMU instead of qemu > >> > >> Changes in v3: > >> - Clarify the 'bug' refered to at the top > >> - Reword 'This means that there' paragraph to explain U-Boot-specific > things > >> - Move to doc/develop/devicetree now that OF_CONTROL is in the docs > >> > >> Changes in v2: > >> - Fix typos per Sean (thank you!) and a few others > >> - Add a 'Use of U-Boot /config node' section > >> - Drop mention of dm-verity since that actually uses the kernel cmdline > >> - Explain that OF_BOARD will still work after these changes (in > >> 'Once this bug is fixed...' paragraph) > >> - Expand a bit on the reason why the 'Current situation' is bad > >> - Clarify in a second place that Linux and U-Boot use the same > devicetree > >> in 'To be clear, while U-Boot...' > >> - Expand on why we should have rules for other projects in > >> 'Devicetree in another project' > >> - Add a comment as to why devicetree in U-Boot is not 'bad design' > >> - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' > >> - Rewrite 'Devicetree generated on-the-fly in another project' to cover > >> points raised on v1 > >> - Add 'Why does U-Boot have its nodes and properties?' > >> - Add 'Why not have two devicetrees?' > >> > >> doc/develop/devicetree/dt_update.rst | 556 +++ > >> doc/develop/devicetree/index.rst | 1 + > >> 2 files changed, 557 insertions(+) > >> create mode 100644 doc/develop/devicetree/dt_update.rst > >> > >> diff --git a/doc/develop/devicetree/dt_update.rst > b/doc/develop/devicetree/dt_update.rst > >> new file mode 100644 > >> index 000..3d4902e3592 > >> --- /dev/null > >> +++ b/doc/develop/devicetree/dt_update.rst > >> @@ -0,0 +1,556 @@ > >> +.. SPDX-License-Identifier: GPL-2.0+ > >> + > >> +Updating the devicetree > >> +=== > >> + > >> +U-Boot uses devicetree for runtime configuration and storing required > blobs or > >> +any other information it needs to operate. This is called the 'control' > >> +devicetree since it controls U-Boot. It is possible to update the > control > >> +devicetree separately from actually building U-Boot. This provides a > good degree > >> +of control and flexibility for firmware that uses U-Boot in > conjunction with > >> +other project. > >> + > >> +There are many reasons why it is useful to modify the devicetree after > building > >> +it: > >> + > >> +- Configuration can be changed, e.g. which UART to use > >> +- A serial number can be added > >> +- Public keys can be added to allow image verification > >> +- Console output can be changed (e.g. to select serial or vidconsole) > >> + > >> +This section describes how to work with devicetree to accomplish your > goals. > >> + > >> +See also :doc:`../devicetree/control` for a basic summary of the > available > >> +features. > >> + > >> + > >> +Devicetree source > >> +- > >> + > >> +Every board in U-Boot must include a devicetree sufficient to build > and boot > >> +that board on suitable hardware (or emulation). This is specified > using the > >> +`CONFIG DEFAULT_DEVICE_TREE` option. > >> + > >> + > >> +Current situation (October 2021) > >> +~~ > >> + > >> +As an aside, at present U-Boot allows `CONFIG_DEFAULT_DEVICE_TREE` to > be empty, > >> +e.g. if `CONFIG_OF_BOARD` is used. This has unfortunately created an > enormous > >> +amount of confusion and some wasted effort. This was not intended. > Support for > >> +an empty `CONFIG_DEFAULT_DEVICE_TREE` will be dropped soon. > >> + > >> +Some of the problems created are: > >> + > >> +- It is not obvious that the devicetree is c
Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
Hi François, On Tue, 26 Oct 2021 at 08:31, François Ozog wrote: > > Hi Simon, > > On Tue, 26 Oct 2021 at 02:25, Simon Glass wrote: >> >> At present some of the ideas and techniques behind devicetree in U-Boot >> are assumed, implied or unsaid. Add some documentation to cover how >> devicetree is build, how it can be modified and the rules about using >> the various CONFIG_OF_... options. >> >> Signed-off-by: Simon Glass >> Reviewed-by: Marcel Ziswiler >> --- >> This patch attracted quite a bit of discussion here: >> >> https://patchwork.ozlabs.org/project/uboot/patch/20210909201033.755713-4-...@chromium.org/ >> >> I have not included the text suggested by François. While I agree that >> it would be useful to have an introduction in this space, I do not agree >> that we should have two devicetrees or that U-Boot should not have its own >> things in the devicetree, so it is not clear to me what we should actually >> write. >> >> The 'Devicetree Control in U-Boot' docs were recently merged and these >> provide some base info, for now. >> >> Changes in v5: >> - Bring into the OF_BOARD series >> - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed >> - Refer to the 'control' DTB in the first paragraph >> - Use QEMU instead of qemu >> >> Changes in v3: >> - Clarify the 'bug' refered to at the top >> - Reword 'This means that there' paragraph to explain U-Boot-specific things >> - Move to doc/develop/devicetree now that OF_CONTROL is in the docs >> >> Changes in v2: >> - Fix typos per Sean (thank you!) and a few others >> - Add a 'Use of U-Boot /config node' section >> - Drop mention of dm-verity since that actually uses the kernel cmdline >> - Explain that OF_BOARD will still work after these changes (in >> 'Once this bug is fixed...' paragraph) >> - Expand a bit on the reason why the 'Current situation' is bad >> - Clarify in a second place that Linux and U-Boot use the same devicetree >> in 'To be clear, while U-Boot...' >> - Expand on why we should have rules for other projects in >> 'Devicetree in another project' >> - Add a comment as to why devicetree in U-Boot is not 'bad design' >> - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' >> - Rewrite 'Devicetree generated on-the-fly in another project' to cover >> points raised on v1 >> - Add 'Why does U-Boot have its nodes and properties?' >> - Add 'Why not have two devicetrees?' >> >> doc/develop/devicetree/dt_update.rst | 556 +++ >> doc/develop/devicetree/index.rst | 1 + >> 2 files changed, 557 insertions(+) >> create mode 100644 doc/develop/devicetree/dt_update.rst >> >> diff --git a/doc/develop/devicetree/dt_update.rst >> b/doc/develop/devicetree/dt_update.rst >> new file mode 100644 >> index 000..3d4902e3592 >> --- /dev/null >> +++ b/doc/develop/devicetree/dt_update.rst >> @@ -0,0 +1,556 @@ >> +.. SPDX-License-Identifier: GPL-2.0+ >> + >> +Updating the devicetree >> +=== >> + >> +U-Boot uses devicetree for runtime configuration and storing required blobs >> or >> +any other information it needs to operate. This is called the 'control' >> +devicetree since it controls U-Boot. It is possible to update the control >> +devicetree separately from actually building U-Boot. This provides a good >> degree >> +of control and flexibility for firmware that uses U-Boot in conjunction with >> +other project. >> + >> +There are many reasons why it is useful to modify the devicetree after >> building >> +it: >> + >> +- Configuration can be changed, e.g. which UART to use >> +- A serial number can be added >> +- Public keys can be added to allow image verification >> +- Console output can be changed (e.g. to select serial or vidconsole) >> + >> +This section describes how to work with devicetree to accomplish your goals. >> + >> +See also :doc:`../devicetree/control` for a basic summary of the available >> +features. >> + >> + >> +Devicetree source >> +- >> + >> +Every board in U-Boot must include a devicetree sufficient to build and boot >> +that board on suitable hardware (or emulation). This is specified using the >> +`CONFIG DEFAULT_DEVICE_TREE` option. >> + >> + >> +Current situation (October 2021) >> +~~ >> + >> +As an aside, at present U-Boot allows `CONFIG_DEFAULT_DEVICE_TREE` to be >> empty, >> +e.g. if `CONFIG_OF_BOARD` is used. This has unfortunately created an >> enormous >> +amount of confusion and some wasted effort. This was not intended. Support >> for >> +an empty `CONFIG_DEFAULT_DEVICE_TREE` will be dropped soon. >> + >> +Some of the problems created are: >> + >> +- It is not obvious that the devicetree is coming from another project >> + >> +- There is no way to see even a sample devicetree for these platform in >> U-Boot, >> + so it is hard to know what is going on, e.g. which devices are typically >> + present >> + >> +- The other project may not provide a way to support U-Boot's requ
Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
Hi Ilias, On Tue, 26 Oct 2021 at 08:06, Ilias Apalodimas wrote: > > Hi Simon, > > > + > > [...] > > > +This is why `CONFIG_OF_SEPARATE` should always be used when building > > U-Boot. > > +The `CONFIG_OF_EMBED` option embeds the devicetree somewhere in the U-Boot > > ELF > > +image as rodata, meaning that it is hard to find it and it cannot increase > > in > > +size. > > + > > +When modifying the devicetree, the different cases to consider are as > > follows: > > + > > +- CONFIG_OF_SEPARATE > > +This is easy, described above. Just change, replace or rebuild the > > +devicetree so it suits your needs, then rerun binman or redo the `cat` > > +operation to join `u-boot-nodtb.bin` and the new `u-boot.dtb` > > + > > +- CONFIG_OF_EMBED > > +This is tricky, since the devicetree cannot easily be located. If the > > EFL > > +file is available, then the _dtb_dt_begin and __dtb_dt_end symbols can > > be > > +examined to find it. While it is possible to contract the file, it is > > not > > +possible to expand the file since that would involve re-linking > > + > > +- CONFIG_OF_BOARD > > +This is a board-specific situation, so needs to be considered on a > > +case-by-case base. The devicetree must be modified so that the correct > > +one is provided to U-Boot. How this is done depends entirely on the > > +implementation of this option for the board. It might require > > injecting the > > +changes into a different project somehow using tooling available > > there, or > > +it might involve merging an overlay file at runtime to obtain the > > desired > > +result. > > I thought this document was trying to describe the current situation in > U-Boot. If so, the current CONFIG_OF_BOARD usage is far from what we have > here. Can you be more specific? What is the difference here? Also see the doc update later in the series, after OF_BOARD becomes a bool option. Regards, SImon
Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
Hi Simon, On Tue, 26 Oct 2021 at 02:25, Simon Glass wrote: > At present some of the ideas and techniques behind devicetree in U-Boot > are assumed, implied or unsaid. Add some documentation to cover how > devicetree is build, how it can be modified and the rules about using > the various CONFIG_OF_... options. > > Signed-off-by: Simon Glass > Reviewed-by: Marcel Ziswiler > --- > This patch attracted quite a bit of discussion here: > > > https://patchwork.ozlabs.org/project/uboot/patch/20210909201033.755713-4-...@chromium.org/ > > I have not included the text suggested by François. While I agree that > it would be useful to have an introduction in this space, I do not agree > that we should have two devicetrees or that U-Boot should not have its own > things in the devicetree, so it is not clear to me what we should actually > write. > > The 'Devicetree Control in U-Boot' docs were recently merged and these > provide some base info, for now. > > Changes in v5: > - Bring into the OF_BOARD series > - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed > - Refer to the 'control' DTB in the first paragraph > - Use QEMU instead of qemu > > Changes in v3: > - Clarify the 'bug' refered to at the top > - Reword 'This means that there' paragraph to explain U-Boot-specific > things > - Move to doc/develop/devicetree now that OF_CONTROL is in the docs > > Changes in v2: > - Fix typos per Sean (thank you!) and a few others > - Add a 'Use of U-Boot /config node' section > - Drop mention of dm-verity since that actually uses the kernel cmdline > - Explain that OF_BOARD will still work after these changes (in > 'Once this bug is fixed...' paragraph) > - Expand a bit on the reason why the 'Current situation' is bad > - Clarify in a second place that Linux and U-Boot use the same devicetree > in 'To be clear, while U-Boot...' > - Expand on why we should have rules for other projects in > 'Devicetree in another project' > - Add a comment as to why devicetree in U-Boot is not 'bad design' > - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' > - Rewrite 'Devicetree generated on-the-fly in another project' to cover > points raised on v1 > - Add 'Why does U-Boot have its nodes and properties?' > - Add 'Why not have two devicetrees?' > > doc/develop/devicetree/dt_update.rst | 556 +++ > doc/develop/devicetree/index.rst | 1 + > 2 files changed, 557 insertions(+) > create mode 100644 doc/develop/devicetree/dt_update.rst > > diff --git a/doc/develop/devicetree/dt_update.rst > b/doc/develop/devicetree/dt_update.rst > new file mode 100644 > index 000..3d4902e3592 > --- /dev/null > +++ b/doc/develop/devicetree/dt_update.rst > @@ -0,0 +1,556 @@ > +.. SPDX-License-Identifier: GPL-2.0+ > + > +Updating the devicetree > +=== > + > +U-Boot uses devicetree for runtime configuration and storing required > blobs or > +any other information it needs to operate. This is called the 'control' > +devicetree since it controls U-Boot. It is possible to update the control > +devicetree separately from actually building U-Boot. This provides a good > degree > +of control and flexibility for firmware that uses U-Boot in conjunction > with > +other project. > + > +There are many reasons why it is useful to modify the devicetree after > building > +it: > + > +- Configuration can be changed, e.g. which UART to use > +- A serial number can be added > +- Public keys can be added to allow image verification > +- Console output can be changed (e.g. to select serial or vidconsole) > + > +This section describes how to work with devicetree to accomplish your > goals. > + > +See also :doc:`../devicetree/control` for a basic summary of the available > +features. > + > + > +Devicetree source > +- > + > +Every board in U-Boot must include a devicetree sufficient to build and > boot > +that board on suitable hardware (or emulation). This is specified using > the > +`CONFIG DEFAULT_DEVICE_TREE` option. > + > + > +Current situation (October 2021) > +~~ > + > +As an aside, at present U-Boot allows `CONFIG_DEFAULT_DEVICE_TREE` to be > empty, > +e.g. if `CONFIG_OF_BOARD` is used. This has unfortunately created an > enormous > +amount of confusion and some wasted effort. This was not intended. > Support for > +an empty `CONFIG_DEFAULT_DEVICE_TREE` will be dropped soon. > + > +Some of the problems created are: > + > +- It is not obvious that the devicetree is coming from another project > + > +- There is no way to see even a sample devicetree for these platform in > U-Boot, > + so it is hard to know what is going on, e.g. which devices are typically > + present > + > +- The other project may not provide a way to support U-Boot's > requirements for > + devicetree, such as the /config node. Note: On the U-Boot mailing > linst, this > + was only discovered after weeks of discussion and confusion > + > +- For QEMU specific
Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
Hi Simon, > + [...] > +This is why `CONFIG_OF_SEPARATE` should always be used when building U-Boot. > +The `CONFIG_OF_EMBED` option embeds the devicetree somewhere in the U-Boot > ELF > +image as rodata, meaning that it is hard to find it and it cannot increase in > +size. > + > +When modifying the devicetree, the different cases to consider are as > follows: > + > +- CONFIG_OF_SEPARATE > +This is easy, described above. Just change, replace or rebuild the > +devicetree so it suits your needs, then rerun binman or redo the `cat` > +operation to join `u-boot-nodtb.bin` and the new `u-boot.dtb` > + > +- CONFIG_OF_EMBED > +This is tricky, since the devicetree cannot easily be located. If the EFL > +file is available, then the _dtb_dt_begin and __dtb_dt_end symbols can be > +examined to find it. While it is possible to contract the file, it is not > +possible to expand the file since that would involve re-linking > + > +- CONFIG_OF_BOARD > +This is a board-specific situation, so needs to be considered on a > +case-by-case base. The devicetree must be modified so that the correct > +one is provided to U-Boot. How this is done depends entirely on the > +implementation of this option for the board. It might require injecting > the > +changes into a different project somehow using tooling available there, > or > +it might involve merging an overlay file at runtime to obtain the desired > +result. I thought this document was trying to describe the current situation in U-Boot. If so, the current CONFIG_OF_BOARD usage is far from what we have here. [...] Regards /Ilias
[PATCH v5 02/26] doc: Add documentation about devicetree usage
At present some of the ideas and techniques behind devicetree in U-Boot are assumed, implied or unsaid. Add some documentation to cover how devicetree is build, how it can be modified and the rules about using the various CONFIG_OF_... options. Signed-off-by: Simon Glass Reviewed-by: Marcel Ziswiler --- This patch attracted quite a bit of discussion here: https://patchwork.ozlabs.org/project/uboot/patch/20210909201033.755713-4-...@chromium.org/ I have not included the text suggested by François. While I agree that it would be useful to have an introduction in this space, I do not agree that we should have two devicetrees or that U-Boot should not have its own things in the devicetree, so it is not clear to me what we should actually write. The 'Devicetree Control in U-Boot' docs were recently merged and these provide some base info, for now. Changes in v5: - Bring into the OF_BOARD series - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed - Refer to the 'control' DTB in the first paragraph - Use QEMU instead of qemu Changes in v3: - Clarify the 'bug' refered to at the top - Reword 'This means that there' paragraph to explain U-Boot-specific things - Move to doc/develop/devicetree now that OF_CONTROL is in the docs Changes in v2: - Fix typos per Sean (thank you!) and a few others - Add a 'Use of U-Boot /config node' section - Drop mention of dm-verity since that actually uses the kernel cmdline - Explain that OF_BOARD will still work after these changes (in 'Once this bug is fixed...' paragraph) - Expand a bit on the reason why the 'Current situation' is bad - Clarify in a second place that Linux and U-Boot use the same devicetree in 'To be clear, while U-Boot...' - Expand on why we should have rules for other projects in 'Devicetree in another project' - Add a comment as to why devicetree in U-Boot is not 'bad design' - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' - Rewrite 'Devicetree generated on-the-fly in another project' to cover points raised on v1 - Add 'Why does U-Boot have its nodes and properties?' - Add 'Why not have two devicetrees?' doc/develop/devicetree/dt_update.rst | 556 +++ doc/develop/devicetree/index.rst | 1 + 2 files changed, 557 insertions(+) create mode 100644 doc/develop/devicetree/dt_update.rst diff --git a/doc/develop/devicetree/dt_update.rst b/doc/develop/devicetree/dt_update.rst new file mode 100644 index 000..3d4902e3592 --- /dev/null +++ b/doc/develop/devicetree/dt_update.rst @@ -0,0 +1,556 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Updating the devicetree +=== + +U-Boot uses devicetree for runtime configuration and storing required blobs or +any other information it needs to operate. This is called the 'control' +devicetree since it controls U-Boot. It is possible to update the control +devicetree separately from actually building U-Boot. This provides a good degree +of control and flexibility for firmware that uses U-Boot in conjunction with +other project. + +There are many reasons why it is useful to modify the devicetree after building +it: + +- Configuration can be changed, e.g. which UART to use +- A serial number can be added +- Public keys can be added to allow image verification +- Console output can be changed (e.g. to select serial or vidconsole) + +This section describes how to work with devicetree to accomplish your goals. + +See also :doc:`../devicetree/control` for a basic summary of the available +features. + + +Devicetree source +- + +Every board in U-Boot must include a devicetree sufficient to build and boot +that board on suitable hardware (or emulation). This is specified using the +`CONFIG DEFAULT_DEVICE_TREE` option. + + +Current situation (October 2021) +~~ + +As an aside, at present U-Boot allows `CONFIG_DEFAULT_DEVICE_TREE` to be empty, +e.g. if `CONFIG_OF_BOARD` is used. This has unfortunately created an enormous +amount of confusion and some wasted effort. This was not intended. Support for +an empty `CONFIG_DEFAULT_DEVICE_TREE` will be dropped soon. + +Some of the problems created are: + +- It is not obvious that the devicetree is coming from another project + +- There is no way to see even a sample devicetree for these platform in U-Boot, + so it is hard to know what is going on, e.g. which devices are typically + present + +- The other project may not provide a way to support U-Boot's requirements for + devicetree, such as the /config node. Note: On the U-Boot mailing linst, this + was only discovered after weeks of discussion and confusion + +- For QEMU specifically, consulting two QEMU source files is required, for which + there are no references in U-Boot documentation. The code is generating a + devicetree, but it is not clear what controls affect this generation. + +Specifically on the changes in U-Bootm `CONFIG_OF_BOARD` was added in +rpi_patch_ for Raspberry Pi,
