On Wed, Aug 14, 2013 at 10:44:22AM -0600, Stephen Warren wrote:
On 08/14/2013 09:13 AM, Tom Rini wrote:
Hey all,
Do we have a document yet talking about the best practices for how we would like a hardware vendor to ship, store and possibly update a device tree, on the hardware? "However they like" seems likely to invite problems down the line with everyone trying their own thing. Thanks!
I don't believe there's any written guidance, no.
The initial guidance Grant gave (IIRC at the first Linaro Connect last year, or perhaps the ARM workshop in Prague, or perhaps also in various ARM kernel list threads?) was that the DTBs should be stored/accessed in exactly the same way as the kernel, which on many systems implies it's a file in /boot (although MTD partitions, ... are also possible kernel locations). The idea here was to explicitly make upgrading the DTB as easy as upgrading the kernel, and explicitly without having to upgrade any firmware, since that's a more dangerous process in most cases.
Now perhaps that advice was only intended to apply very early on when DT was really new on ARM, and has "aged out" by now? If so, I don't recall that every being explicitly mentioned or communicated later.
[snip out a bit more of Stephen's answer]
Yes, this notion certainly is the opposite of what was suggested on the cross-distro list, both as part of a "what should a bootloader provide to get commodity distros to support the board" thread and the "where should a device tree live in the filesystem" thread. Cc'ing them now because this is one of those things that feels like it needs solving, solving soon, and done in a way the least number of folks get surprised about it.
On Wed, 14 Aug 2013, Tom Rini wrote:
On Wed, Aug 14, 2013 at 10:44:22AM -0600, Stephen Warren wrote:
On 08/14/2013 09:13 AM, Tom Rini wrote:
Hey all,
Do we have a document yet talking about the best practices for how we would like a hardware vendor to ship, store and possibly update a device tree, on the hardware? "However they like" seems likely to invite problems down the line with everyone trying their own thing. Thanks!
I don't believe there's any written guidance, no.
The initial guidance Grant gave (IIRC at the first Linaro Connect last year, or perhaps the ARM workshop in Prague, or perhaps also in various ARM kernel list threads?) was that the DTBs should be stored/accessed in exactly the same way as the kernel, which on many systems implies it's a file in /boot (although MTD partitions, ... are also possible kernel locations). The idea here was to explicitly make upgrading the DTB as easy as upgrading the kernel, and explicitly without having to upgrade any firmware, since that's a more dangerous process in most cases.
Now perhaps that advice was only intended to apply very early on when DT was really new on ARM, and has "aged out" by now? If so, I don't recall that every being explicitly mentioned or communicated later.
[snip out a bit more of Stephen's answer]
Yes, this notion certainly is the opposite of what was suggested on the cross-distro list, both as part of a "what should a bootloader provide to get commodity distros to support the board" thread and the "where should a device tree live in the filesystem" thread. Cc'ing them now because this is one of those things that feels like it needs solving, solving soon, and done in a way the least number of folks get surprised about it.
I don't think the "however they like" approach is that bad. It is certainly less of a problem than "exactly the same way as the kernel" is.
Using /boot implies a distro filesystem and we'd rather wish for DT to be independent from a distro or even Linux. The DTB should therefore be stored and accessed in a way which is hardware/bootloader specific. The distro being installed on top shouldn't have to care.
Nicolas
On 08/14/2013 08:37 PM, Nicolas Pitre wrote:
On Wed, 14 Aug 2013, Tom Rini wrote:
On Wed, Aug 14, 2013 at 10:44:22AM -0600, Stephen Warren wrote:
On 08/14/2013 09:13 AM, Tom Rini wrote:
Hey all,
Do we have a document yet talking about the best practices for how we would like a hardware vendor to ship, store and possibly update a device tree, on the hardware? "However they like" seems likely to invite problems down the line with everyone trying their own thing. Thanks!
I don't believe there's any written guidance, no.
The initial guidance Grant gave (IIRC at the first Linaro Connect last year, or perhaps the ARM workshop in Prague, or perhaps also in various ARM kernel list threads?) was that the DTBs should be stored/accessed in exactly the same way as the kernel, which on many systems implies it's a file in /boot (although MTD partitions, ... are also possible kernel locations). The idea here was to explicitly make upgrading the DTB as easy as upgrading the kernel, and explicitly without having to upgrade any firmware, since that's a more dangerous process in most cases.
Now perhaps that advice was only intended to apply very early on when DT was really new on ARM, and has "aged out" by now? If so, I don't recall that every being explicitly mentioned or communicated later.
[snip out a bit more of Stephen's answer]
Yes, this notion certainly is the opposite of what was suggested on the cross-distro list, both as part of a "what should a bootloader provide to get commodity distros to support the board" thread and the "where should a device tree live in the filesystem" thread. Cc'ing them now because this is one of those things that feels like it needs solving, solving soon, and done in a way the least number of folks get surprised about it.
I don't think the "however they like" approach is that bad. It is certainly less of a problem than "exactly the same way as the kernel" is.
Using /boot implies a distro filesystem and we'd rather wish for DT to be independent from a distro or even Linux. The DTB should therefore be stored and accessed in a way which is hardware/bootloader specific. The distro being installed on top shouldn't have to care.
Right, the expectation has been set that the DT isn't supposed to be tied to the kernel and I don't wish to re-hash that. I'm asking, should we provide some expectations / guidance on how to store the DT? Should quirks be expected to be worked around at the DT consumer level (kernel, bootloader, whatever) or in updating the stored copy? That there rules out, or not, certain choices.
On Wed, 14 Aug 2013, Tom Rini wrote:
On 08/14/2013 08:37 PM, Nicolas Pitre wrote:
On Wed, 14 Aug 2013, Tom Rini wrote:
On Wed, Aug 14, 2013 at 10:44:22AM -0600, Stephen Warren wrote:
On 08/14/2013 09:13 AM, Tom Rini wrote:
Hey all,
Do we have a document yet talking about the best practices for how we would like a hardware vendor to ship, store and possibly update a device tree, on the hardware? "However they like" seems likely to invite problems down the line with everyone trying their own thing. Thanks!
I don't believe there's any written guidance, no.
The initial guidance Grant gave (IIRC at the first Linaro Connect last year, or perhaps the ARM workshop in Prague, or perhaps also in various ARM kernel list threads?) was that the DTBs should be stored/accessed in exactly the same way as the kernel, which on many systems implies it's a file in /boot (although MTD partitions, ... are also possible kernel locations). The idea here was to explicitly make upgrading the DTB as easy as upgrading the kernel, and explicitly without having to upgrade any firmware, since that's a more dangerous process in most cases.
Now perhaps that advice was only intended to apply very early on when DT was really new on ARM, and has "aged out" by now? If so, I don't recall that every being explicitly mentioned or communicated later.
[snip out a bit more of Stephen's answer]
Yes, this notion certainly is the opposite of what was suggested on the cross-distro list, both as part of a "what should a bootloader provide to get commodity distros to support the board" thread and the "where should a device tree live in the filesystem" thread. Cc'ing them now because this is one of those things that feels like it needs solving, solving soon, and done in a way the least number of folks get surprised about it.
I don't think the "however they like" approach is that bad. It is certainly less of a problem than "exactly the same way as the kernel" is.
Using /boot implies a distro filesystem and we'd rather wish for DT to be independent from a distro or even Linux. The DTB should therefore be stored and accessed in a way which is hardware/bootloader specific. The distro being installed on top shouldn't have to care.
Right, the expectation has been set that the DT isn't supposed to be tied to the kernel and I don't wish to re-hash that. I'm asking, should we provide some expectations / guidance on how to store the DT? Should quirks be expected to be worked around at the DT consumer level (kernel, bootloader, whatever) or in updating the stored copy? That there rules out, or not, certain choices.
Well, the hard guideline should require that the DTB be updateable and not linked with nor generated by the bootloader or firmware. That implies some storage separate from the bootloader but this doesn't need to be a filesystem.
And the DTB should be updated far less often than the kernel. So that might be acceptable to have a special bootloader-specific procedure to update it.
I expect that the kernel will have to deal with quirks from a bad DTB that has already been deployed. But those quirks workarounds only have to make things minimally work while the optimal state would come from an updated DTB. Same story as with bad BIOSes on a X86 system.
More importantly, a DTB update is likely to be useful in providing new data the previous DTB didn't include e.g. if some bindings weren't finalized when the initial deployment took place.
Nicolas
On Wed, Aug 14, 2013 at 10:57:36PM -0400, Nicolas Pitre wrote:
On Wed, 14 Aug 2013, Tom Rini wrote:
On 08/14/2013 08:37 PM, Nicolas Pitre wrote:
On Wed, 14 Aug 2013, Tom Rini wrote:
On Wed, Aug 14, 2013 at 10:44:22AM -0600, Stephen Warren wrote:
On 08/14/2013 09:13 AM, Tom Rini wrote:
Hey all,
Do we have a document yet talking about the best practices for how we would like a hardware vendor to ship, store and possibly update a device tree, on the hardware? "However they like" seems likely to invite problems down the line with everyone trying their own thing. Thanks!
I don't believe there's any written guidance, no.
The initial guidance Grant gave (IIRC at the first Linaro Connect last year, or perhaps the ARM workshop in Prague, or perhaps also in various ARM kernel list threads?) was that the DTBs should be stored/accessed in exactly the same way as the kernel, which on many systems implies it's a file in /boot (although MTD partitions, ... are also possible kernel locations). The idea here was to explicitly make upgrading the DTB as easy as upgrading the kernel, and explicitly without having to upgrade any firmware, since that's a more dangerous process in most cases.
Now perhaps that advice was only intended to apply very early on when DT was really new on ARM, and has "aged out" by now? If so, I don't recall that every being explicitly mentioned or communicated later.
[snip out a bit more of Stephen's answer]
Yes, this notion certainly is the opposite of what was suggested on the cross-distro list, both as part of a "what should a bootloader provide to get commodity distros to support the board" thread and the "where should a device tree live in the filesystem" thread. Cc'ing them now because this is one of those things that feels like it needs solving, solving soon, and done in a way the least number of folks get surprised about it.
I don't think the "however they like" approach is that bad. It is certainly less of a problem than "exactly the same way as the kernel" is.
Using /boot implies a distro filesystem and we'd rather wish for DT to be independent from a distro or even Linux. The DTB should therefore be stored and accessed in a way which is hardware/bootloader specific. The distro being installed on top shouldn't have to care.
Right, the expectation has been set that the DT isn't supposed to be tied to the kernel and I don't wish to re-hash that. I'm asking, should we provide some expectations / guidance on how to store the DT? Should quirks be expected to be worked around at the DT consumer level (kernel, bootloader, whatever) or in updating the stored copy? That there rules out, or not, certain choices.
Well, the hard guideline should require that the DTB be updateable and not linked with nor generated by the bootloader or firmware. That implies some storage separate from the bootloader but this doesn't need to be a filesystem.
I assume generated doesn't mean not updated. Do we want to limit the nodes that can be touched here? For example, a number of platforms have incorrect memory size (and on PowerPC, intentionally zero) so that the bootloader can correct them. And not linked with the bootloader may (or may not, Stephen, can you comment on what Tegra is doing at the moment?) make it harder to use in those cases.
And the DTB should be updated far less often than the kernel. So that might be acceptable to have a special bootloader-specific procedure to update it.
Right. But you wouldn't want it to be a hardware mod to make things be writable again (thinking the EEPROM I mentioned before).
I expect that the kernel will have to deal with quirks from a bad DTB that has already been deployed. But those quirks workarounds only have to make things minimally work while the optimal state would come from an updated DTB. Same story as with bad BIOSes on a X86 system.
More importantly, a DTB update is likely to be useful in providing new data the previous DTB didn't include e.g. if some bindings weren't finalized when the initial deployment took place.
And what bindings it should use in the interm depends on the general outcome of when bindings get locked in and how all of that. But does this mean that the expectation, on the kernel side, would be that a developer should use the latest published bindings for a platform, or the bindings that shipped the very first time? For bootloaders the rule is "whatever shipped on the hardware shouldn't be touched".
On 08/15/2013 08:53 AM, Tom Rini wrote:
On Wed, Aug 14, 2013 at 10:57:36PM -0400, Nicolas Pitre wrote:
On Wed, 14 Aug 2013, Tom Rini wrote:
On 08/14/2013 08:37 PM, Nicolas Pitre wrote:
On Wed, 14 Aug 2013, Tom Rini wrote:
On Wed, Aug 14, 2013 at 10:44:22AM -0600, Stephen Warren wrote:
On 08/14/2013 09:13 AM, Tom Rini wrote: > Hey all, > > Do we have a document yet talking about the best practices for how we > would like a hardware vendor to ship, store and possibly update a device > tree, on the hardware? "However they like" seems likely to invite > problems down the line with everyone trying their own thing. Thanks!
I don't believe there's any written guidance, no.
The initial guidance Grant gave (IIRC at the first Linaro Connect last year, or perhaps the ARM workshop in Prague, or perhaps also in various ARM kernel list threads?) was that the DTBs should be stored/accessed in exactly the same way as the kernel, which on many systems implies it's a file in /boot (although MTD partitions, ... are also possible kernel locations). The idea here was to explicitly make upgrading the DTB as easy as upgrading the kernel, and explicitly without having to upgrade any firmware, since that's a more dangerous process in most cases.
Now perhaps that advice was only intended to apply very early on when DT was really new on ARM, and has "aged out" by now? If so, I don't recall that every being explicitly mentioned or communicated later.
[snip out a bit more of Stephen's answer]
Yes, this notion certainly is the opposite of what was suggested on the cross-distro list, both as part of a "what should a bootloader provide to get commodity distros to support the board" thread and the "where should a device tree live in the filesystem" thread. Cc'ing them now because this is one of those things that feels like it needs solving, solving soon, and done in a way the least number of folks get surprised about it.
I don't think the "however they like" approach is that bad. It is certainly less of a problem than "exactly the same way as the kernel" is.
Using /boot implies a distro filesystem and we'd rather wish for DT to be independent from a distro or even Linux. The DTB should therefore be stored and accessed in a way which is hardware/bootloader specific. The distro being installed on top shouldn't have to care.
Right, the expectation has been set that the DT isn't supposed to be tied to the kernel and I don't wish to re-hash that. I'm asking, should we provide some expectations / guidance on how to store the DT? Should quirks be expected to be worked around at the DT consumer level (kernel, bootloader, whatever) or in updating the stored copy? That there rules out, or not, certain choices.
Well, the hard guideline should require that the DTB be updateable and not linked with nor generated by the bootloader or firmware. That implies some storage separate from the bootloader but this doesn't need to be a filesystem.
I assume generated doesn't mean not updated. Do we want to limit the nodes that can be touched here? For example, a number of platforms have incorrect memory size (and on PowerPC, intentionally zero) so that the bootloader can correct them. And not linked with the bootloader may (or may not, Stephen, can you comment on what Tegra is doing at the moment?) make it harder to use in those cases.
On Tegra, there are two DTBs:
The first is attached to the U-Boot image, and parameterizes U-Boot itself. The bindings used in this are often quite different from the kernel:-(
The second is the DTB passed to the kernel. Right now, we're using the model of putting this in /boot on the root filesystem and having the U-Boot boot script load it (with filename generated as ${soc}-${board}.dtb) and pass it to the kernel. Moving this into boot flash at some well-known location rather than the filesystem might be possible in the long term.
Perhaps the two should be unified, although there isn't much interest in bringing the U-Boot DT content up to scratch, it seems:-( I would just ignore the U-Boot copy for now, and treat it as an internal implementation detail of U-Boot.
We certainly expect U-Boot to update the DT that's passed to the kernel, for:
* Memory size (although it's typically already correct in all the DTBs anyway) * Command-line * Possibly to add a "simplefb" node, until the kernel has LCD panel support (CDF).
On Thu, Aug 15, 2013 at 09:30:01AM -0600, Stephen Warren wrote:
On 08/15/2013 08:53 AM, Tom Rini wrote:
On Wed, Aug 14, 2013 at 10:57:36PM -0400, Nicolas Pitre wrote:
On Wed, 14 Aug 2013, Tom Rini wrote:
On 08/14/2013 08:37 PM, Nicolas Pitre wrote:
On Wed, 14 Aug 2013, Tom Rini wrote:
On Wed, Aug 14, 2013 at 10:44:22AM -0600, Stephen Warren wrote: > On 08/14/2013 09:13 AM, Tom Rini wrote: >> Hey all, >> >> Do we have a document yet talking about the best practices for how we >> would like a hardware vendor to ship, store and possibly update a device >> tree, on the hardware? "However they like" seems likely to invite >> problems down the line with everyone trying their own thing. Thanks! > > I don't believe there's any written guidance, no. > > The initial guidance Grant gave (IIRC at the first Linaro Connect last > year, or perhaps the ARM workshop in Prague, or perhaps also in various > ARM kernel list threads?) was that the DTBs should be stored/accessed in > exactly the same way as the kernel, which on many systems implies it's a > file in /boot (although MTD partitions, ... are also possible kernel > locations). The idea here was to explicitly make upgrading the DTB as > easy as upgrading the kernel, and explicitly without having to upgrade > any firmware, since that's a more dangerous process in most cases. > > Now perhaps that advice was only intended to apply very early on when DT > was really new on ARM, and has "aged out" by now? If so, I don't recall > that every being explicitly mentioned or communicated later. [snip out a bit more of Stephen's answer]
Yes, this notion certainly is the opposite of what was suggested on the cross-distro list, both as part of a "what should a bootloader provide to get commodity distros to support the board" thread and the "where should a device tree live in the filesystem" thread. Cc'ing them now because this is one of those things that feels like it needs solving, solving soon, and done in a way the least number of folks get surprised about it.
I don't think the "however they like" approach is that bad. It is certainly less of a problem than "exactly the same way as the kernel" is.
Using /boot implies a distro filesystem and we'd rather wish for DT to be independent from a distro or even Linux. The DTB should therefore be stored and accessed in a way which is hardware/bootloader specific. The distro being installed on top shouldn't have to care.
Right, the expectation has been set that the DT isn't supposed to be tied to the kernel and I don't wish to re-hash that. I'm asking, should we provide some expectations / guidance on how to store the DT? Should quirks be expected to be worked around at the DT consumer level (kernel, bootloader, whatever) or in updating the stored copy? That there rules out, or not, certain choices.
Well, the hard guideline should require that the DTB be updateable and not linked with nor generated by the bootloader or firmware. That implies some storage separate from the bootloader but this doesn't need to be a filesystem.
I assume generated doesn't mean not updated. Do we want to limit the nodes that can be touched here? For example, a number of platforms have incorrect memory size (and on PowerPC, intentionally zero) so that the bootloader can correct them. And not linked with the bootloader may (or may not, Stephen, can you comment on what Tegra is doing at the moment?) make it harder to use in those cases.
On Tegra, there are two DTBs:
The first is attached to the U-Boot image, and parameterizes U-Boot itself. The bindings used in this are often quite different from the kernel:-(
[snip]
Perhaps the two should be unified, although there isn't much interest in bringing the U-Boot DT content up to scratch, it seems:-( I would just ignore the U-Boot copy for now, and treat it as an internal implementation detail of U-Boot.
I would very much like to see them unified and used more in U-Boot. Most U-Boot development is about scratching ones own itch, is the biggest hurdle towards mass conversion to DTs (followed by the number of platforms that aren't being updated to DT in the kernel, followed by needing more conversion done in the kernel, bindings finalized, etc).
But that's why I bring up "not attached to bootloader/firmware" as a question here. If we get the bindings in-sync, and make it easy to trim down a tree, we could still attach what the firmware needs to know to know about the rest of the system and have the full DT somewhere.
We certainly expect U-Boot to update the DT that's passed to the kernel, for:
- Memory size (although it's typically already correct in all the DTBs
anyway)
... for Tegra (for clarity).
- Command-line
- Possibly to add a "simplefb" node, until the kernel has LCD panel
support (CDF).
Can we talk about that last one more? That sounds like some sort of temporary binding. Or am I using the terms wrong? But, it sounds like we're saying add whatever nodes might be missing?
On 08/15/2013 10:37 AM, Tom Rini wrote:
On Thu, Aug 15, 2013 at 09:30:01AM -0600, Stephen Warren wrote:
...
On Tegra, there are two DTBs:
The first is attached to the U-Boot image, and parameterizes U-Boot itself. The bindings used in this are often quite different from the kernel:-(
[snip]
Perhaps the two should be unified, although there isn't much interest in bringing the U-Boot DT content up to scratch, it seems:-( I would just ignore the U-Boot copy for now, and treat it as an internal implementation detail of U-Boot.
I would very much like to see them unified and used more in U-Boot. Most U-Boot development is about scratching ones own itch, is the biggest hurdle towards mass conversion to DTs (followed by the number of platforms that aren't being updated to DT in the kernel, followed by needing more conversion done in the kernel, bindings finalized, etc).
I was mainly talking about the people specifically working on Tegra support in U-Boot rather than U-Boot as a generality.
...
We certainly expect U-Boot to update the DT that's passed to the kernel, for:
...
- Possibly to add a "simplefb" node, until the kernel has LCD panel
support (CDF).
Can we talk about that last one more? That sounds like some sort of temporary binding. Or am I using the terms wrong? But, it sounds like we're saying add whatever nodes might be missing?
For Tegra, this should be temporary, although temporary will probably be a long time! For other SoCs, it may be a reasonable long-term solution.
The simplefb DT binding and associated Linux driver simply defines a memory region as being the frame-buffer, so that the OS can just write pixels to the memory region, and they'll be displayed. It's assumed that the HW to do the scanout is already set up before the OS starts.
For Tegra, this is useful on some platforms that have built-in LCDs, since the kernel support for LCDs, which has to be the CDF (Common Display Framework) under the new DT and common driver regime, is perpetually missing. Having U-Boot create a simplefb node in DT and enabling the simplefb driver in the kernel is a way of getting useful display support prior to CDF getting merged.
The same argument applies to upstream kernel support for the Samsung Exynos CPU used in the ARM ChromeBook.
For the Raspberry Pi, I wanted to avoid defining DT bindings for the RPC communication channel out to the VideoCore co-processor which controls the display path. Relying on simplefb for the display allowed me to defer creating bindings/drivers for the RPC channel etc.
On other HW, the display HW may be so simple that it's just not worth writing an OS driver; the best way to support the HW may always be to have a simplefb node in DT and have a single driver in the bootloader that's already initialized the HW, rather than writing an OS driver just to re-do what the bootloader already did.
simplefb information could get into DT in a couple ways:
1) The DTB for the platform could include the simplefb node right from the start.
This model would be appropriate for more permanent use of simplefb, since the node appears in the orignial DT.
In this case, the bootloader would at least have to fill in the physical memory address of the frame-buffer that it allocated. If the display is device with variable resolution, rather than a fixed built-in LCD, the bootloader would also have to fill in the resolution properties.
2) The DTB for the platform doesn't include the simplefb node.
This would be appropriate for platforms that use simplefb as a temporary step until complete OS support for the display HW is present, so a real driver can be used. This prevents DTBs from ever having the soon-to-be-removed simplefb node encoded into them.
In this case, the bootloader would have to add a completely new simplefb node to the DT, and fill in all the properties.
On Thu, Aug 15, 2013 at 11:31:54AM -0600, Stephen Warren wrote:
On 08/15/2013 10:37 AM, Tom Rini wrote:
On Thu, Aug 15, 2013 at 09:30:01AM -0600, Stephen Warren wrote:
...
On Tegra, there are two DTBs:
The first is attached to the U-Boot image, and parameterizes U-Boot itself. The bindings used in this are often quite different from the kernel:-(
[snip]
Perhaps the two should be unified, although there isn't much interest in bringing the U-Boot DT content up to scratch, it seems:-( I would just ignore the U-Boot copy for now, and treat it as an internal implementation detail of U-Boot.
I would very much like to see them unified and used more in U-Boot. Most U-Boot development is about scratching ones own itch, is the biggest hurdle towards mass conversion to DTs (followed by the number of platforms that aren't being updated to DT in the kernel, followed by needing more conversion done in the kernel, bindings finalized, etc).
I was mainly talking about the people specifically working on Tegra support in U-Boot rather than U-Boot as a generality.
Right. And with my U-Boot guy hat on, I want to be clear that this is a direction I want to see the project move in, once things have settled down a bit with the kernel side of things (since we'll have our own headaches like "how little of the system can we hard-code" and "how can we merge device trees, or do we discard that first one?").
...
We certainly expect U-Boot to update the DT that's passed to the kernel, for:
...
- Possibly to add a "simplefb" node, until the kernel has LCD panel
support (CDF).
Can we talk about that last one more? That sounds like some sort of temporary binding. Or am I using the terms wrong? But, it sounds like we're saying add whatever nodes might be missing?
[snip useful explanation of what simplefb is]
simplefb information could get into DT in a couple ways:
- The DTB for the platform could include the simplefb node right from
the start.
This model would be appropriate for more permanent use of simplefb, since the node appears in the orignial DT.
In this case, the bootloader would at least have to fill in the physical memory address of the frame-buffer that it allocated. If the display is device with variable resolution, rather than a fixed built-in LCD, the bootloader would also have to fill in the resolution properties.
- The DTB for the platform doesn't include the simplefb node.
This would be appropriate for platforms that use simplefb as a temporary step until complete OS support for the display HW is present, so a real driver can be used. This prevents DTBs from ever having the soon-to-be-removed simplefb node encoded into them.
In this case, the bootloader would have to add a completely new simplefb node to the DT, and fill in all the properties.
OK, now why wouldn't the right thing to do here be to #1 and later in time, the DT is updated when the better drivers are merged in?
I don't think it's strictly a bad thing to say that firmware/bootloader is allowed to construct temporary nodes, but we should make it clear when that's an OK practice. Yes?
On 08/15/2013 12:56 PM, Tom Rini wrote:
On Thu, Aug 15, 2013 at 11:31:54AM -0600, Stephen Warren wrote:
On 08/15/2013 10:37 AM, Tom Rini wrote:
On Thu, Aug 15, 2013 at 09:30:01AM -0600, Stephen Warren wrote:
...
We certainly expect U-Boot to update the DT that's passed to the kernel, for:
...
- Possibly to add a "simplefb" node, until the kernel has LCD panel
support (CDF).
Can we talk about that last one more? That sounds like some sort of temporary binding. Or am I using the terms wrong? But, it sounds like we're saying add whatever nodes might be missing?
[snip useful explanation of what simplefb is]
simplefb information could get into DT in a couple ways:
- The DTB for the platform could include the simplefb node right from
the start.
This model would be appropriate for more permanent use of simplefb, since the node appears in the orignial DT.
In this case, the bootloader would at least have to fill in the physical memory address of the frame-buffer that it allocated. If the display is device with variable resolution, rather than a fixed built-in LCD, the bootloader would also have to fill in the resolution properties.
- The DTB for the platform doesn't include the simplefb node.
This would be appropriate for platforms that use simplefb as a temporary step until complete OS support for the display HW is present, so a real driver can be used. This prevents DTBs from ever having the soon-to-be-removed simplefb node encoded into them.
In this case, the bootloader would have to add a completely new simplefb node to the DT, and fill in all the properties.
OK, now why wouldn't the right thing to do here be to #1 and later in time, the DT is updated when the better drivers are merged in?
I don't think it's strictly a bad thing to say that firmware/bootloader is allowed to construct temporary nodes, but we should make it clear when that's an OK practice. Yes?
For systems where simplefb is a transitional measure (i.e. where it would eventually make sense to define a complete binding for the HW), I'd prefer to avoid churn in the *.dts files by never including the simplefb node in them, but rather adding it dynamically. In other words, we don't add something to the file just to take it away later.
That's the logic behind why I wrote separate "add node" and "fill in node" functions for the simplefb in U-Boot.
One thing that's slightly different about simplefb is that the node isn't useful without the bootloader filling in some information, which generally isn't true of DT content.
It'd certainly be technically possible to just add the simplefb node into DT in all cases, then swap it out later when something else came along.
On Thu, 15 Aug 2013, Tom Rini wrote:
On Wed, Aug 14, 2013 at 10:57:36PM -0400, Nicolas Pitre wrote:
On Wed, 14 Aug 2013, Tom Rini wrote:
On 08/14/2013 08:37 PM, Nicolas Pitre wrote:
I don't think the "however they like" approach is that bad. It is certainly less of a problem than "exactly the same way as the kernel" is.
Using /boot implies a distro filesystem and we'd rather wish for DT to be independent from a distro or even Linux. The DTB should therefore be stored and accessed in a way which is hardware/bootloader specific. The distro being installed on top shouldn't have to care.
Right, the expectation has been set that the DT isn't supposed to be tied to the kernel and I don't wish to re-hash that. I'm asking, should we provide some expectations / guidance on how to store the DT? Should quirks be expected to be worked around at the DT consumer level (kernel, bootloader, whatever) or in updating the stored copy? That there rules out, or not, certain choices.
Well, the hard guideline should require that the DTB be updateable and not linked with nor generated by the bootloader or firmware. That implies some storage separate from the bootloader but this doesn't need to be a filesystem.
I assume generated doesn't mean not updated.
Indeed. For instance, the bootloader is likely to update it with some user provided kernel cmdline string, and possibly ethernet MAC addresses and/or some board serial number, etc.
BTW providing a unique serial number via DT to the kernel would help a lot in the seeding of the kernel's random pool.
Do we want to limit the nodes that can be touched here? For example, a number of platforms have incorrect memory size (and on PowerPC, intentionally zero) so that the bootloader can correct them. And not linked with the bootloader may (or may not, Stephen, can you comment on what Tegra is doing at the moment?) make it harder to use in those cases.
U-Boot let you update any node you want once you've told it where in memory the DTB is. I suppose such thing can be scripted or even added to the board specific U-Boot support easily. As long as people are not overriding every nodes I suppose this is reasonable.
Especially if the hardware may accommodate different amount of RAM, in that case there is no other way than runtime probing of that RAM and the DTB must be updated accordingly.
And the DTB should be updated far less often than the kernel. So that might be acceptable to have a special bootloader-specific procedure to update it.
Right. But you wouldn't want it to be a hardware mod to make things be writable again (thinking the EEPROM I mentioned before).
No.
It must be end user updatable, even if the bootloader itself might not always be.
I expect that the kernel will have to deal with quirks from a bad DTB that has already been deployed. But those quirks workarounds only have to make things minimally work while the optimal state would come from an updated DTB. Same story as with bad BIOSes on a X86 system.
More importantly, a DTB update is likely to be useful in providing new data the previous DTB didn't include e.g. if some bindings weren't finalized when the initial deployment took place.
And what bindings it should use in the interm depends on the general outcome of when bindings get locked in and how all of that. But does this mean that the expectation, on the kernel side, would be that a developer should use the latest published bindings for a platform, or the bindings that shipped the very first time? For bootloaders the rule is "whatever shipped on the hardware shouldn't be touched".
I think the debate on this very topic is still ongoing.
Nicolas
On Thu, Aug 15, 2013 at 11:45:57AM -0400, Nicolas Pitre wrote:
On Thu, 15 Aug 2013, Tom Rini wrote:
On Wed, Aug 14, 2013 at 10:57:36PM -0400, Nicolas Pitre wrote:
On Wed, 14 Aug 2013, Tom Rini wrote:
On 08/14/2013 08:37 PM, Nicolas Pitre wrote:
I don't think the "however they like" approach is that bad. It is certainly less of a problem than "exactly the same way as the kernel" is.
Using /boot implies a distro filesystem and we'd rather wish for DT to be independent from a distro or even Linux. The DTB should therefore be stored and accessed in a way which is hardware/bootloader specific. The distro being installed on top shouldn't have to care.
Right, the expectation has been set that the DT isn't supposed to be tied to the kernel and I don't wish to re-hash that. I'm asking, should we provide some expectations / guidance on how to store the DT? Should quirks be expected to be worked around at the DT consumer level (kernel, bootloader, whatever) or in updating the stored copy? That there rules out, or not, certain choices.
Well, the hard guideline should require that the DTB be updateable and not linked with nor generated by the bootloader or firmware. That implies some storage separate from the bootloader but this doesn't need to be a filesystem.
I assume generated doesn't mean not updated.
Indeed. For instance, the bootloader is likely to update it with some user provided kernel cmdline string, and possibly ethernet MAC addresses and/or some board serial number, etc.
Right, command line, memory and mac addresses are what U-Boot does today. Is there a standard binding for board serial number? If so we could update that too, if set.
BTW providing a unique serial number via DT to the kernel would help a lot in the seeding of the kernel's random pool.
Do we want to limit the nodes that can be touched here? For example, a number of platforms have incorrect memory size (and on PowerPC, intentionally zero) so that the bootloader can correct them. And not linked with the bootloader may (or may not, Stephen, can you comment on what Tegra is doing at the moment?) make it harder to use in those cases.
U-Boot let you update any node you want once you've told it where in memory the DTB is. I suppose such thing can be scripted or even added to the board specific U-Boot support easily. As long as people are not overriding every nodes I suppose this is reasonable.
Right, U-Boot has a 'fdt' command for fiddling with the in-memory DT as well as updating certain nodes as part of booting the kernel. This could be used to "hotfix" the stored device tree if desired. Today this is used more (or at least, so it seems) while developing your DT, or simply functionality people didn't widely know was there.
Especially if the hardware may accommodate different amount of RAM, in that case there is no other way than runtime probing of that RAM and the DTB must be updated accordingly.
This is probably why many PowerPC platforms have a zero size memory node, yes. At one point I was talking about saying the standard should be zero, and then we assume that a non-zero value must be correct (for platforms with lots and lots of memory where U-Boot is setting things wrong now).
And the DTB should be updated far less often than the kernel. So that might be acceptable to have a special bootloader-specific procedure to update it.
Right. But you wouldn't want it to be a hardware mod to make things be writable again (thinking the EEPROM I mentioned before).
No.
It must be end user updatable, even if the bootloader itself might not always be.
So one of the rules for the guidelines :)
I expect that the kernel will have to deal with quirks from a bad DTB that has already been deployed. But those quirks workarounds only have to make things minimally work while the optimal state would come from an updated DTB. Same story as with bad BIOSes on a X86 system.
More importantly, a DTB update is likely to be useful in providing new data the previous DTB didn't include e.g. if some bindings weren't finalized when the initial deployment took place.
And what bindings it should use in the interm depends on the general outcome of when bindings get locked in and how all of that. But does this mean that the expectation, on the kernel side, would be that a developer should use the latest published bindings for a platform, or the bindings that shipped the very first time? For bootloaders the rule is "whatever shipped on the hardware shouldn't be touched".
I think the debate on this very topic is still ongoing.
Right. And that's part of why I brought the topic up. Using my magic VPN-based crystal ball, I can see when for example TI plans to release platforms, think a little about timelines and go "Gee, if we want the device tree included with the hardware when it ships, I need to know what's expected somewhere between a month from now and 3 months ago, crap.".
On Wed, Aug 14, 2013 at 10:57:36PM -0400, Nicolas Pitre wrote:
On Wed, 14 Aug 2013, Tom Rini wrote:
On 08/14/2013 08:37 PM, Nicolas Pitre wrote:
On Wed, 14 Aug 2013, Tom Rini wrote:
[snip]
Well, the hard guideline should require that the DTB be updateable and not linked with nor generated by the bootloader or firmware. That implies some storage separate from the bootloader but this doesn't need to be a filesystem.
Wait, what!?
Much as I think a bunch of the current problems have been caused by being overly keen to push the dtb into firmware, we shouldn't *ban* the original Open Firmware model of the device tree, where it is generated by the firmware and consumed by the OS.
On Fri, 16 Aug 2013, David Gibson wrote:
On Wed, Aug 14, 2013 at 10:57:36PM -0400, Nicolas Pitre wrote:
On Wed, 14 Aug 2013, Tom Rini wrote:
On 08/14/2013 08:37 PM, Nicolas Pitre wrote:
On Wed, 14 Aug 2013, Tom Rini wrote:
[snip]
Well, the hard guideline should require that the DTB be updateable and not linked with nor generated by the bootloader or firmware. That implies some storage separate from the bootloader but this doesn't need to be a filesystem.
Wait, what!?
Much as I think a bunch of the current problems have been caused by being overly keen to push the dtb into firmware, we shouldn't *ban* the original Open Firmware model of the device tree, where it is generated by the firmware and consumed by the OS.
If the DTB generating firmware can be updated by the end user just as easily and safely as a standalone DTB then that's probably fine. But we do know that many people/organizations are not willing to let end users upgrade bootloaders due to the risks associated with such an operation. So in that case we may not suggest the DTB be tied to the bootloader/firmware.
Nicolas
On Thu, Aug 15, 2013 at 10:51:18PM -0400, Nicolas Pitre wrote:
On Fri, 16 Aug 2013, David Gibson wrote:
On Wed, Aug 14, 2013 at 10:57:36PM -0400, Nicolas Pitre wrote:
On Wed, 14 Aug 2013, Tom Rini wrote:
On 08/14/2013 08:37 PM, Nicolas Pitre wrote:
On Wed, 14 Aug 2013, Tom Rini wrote:
[snip]
Well, the hard guideline should require that the DTB be updateable and not linked with nor generated by the bootloader or firmware. That implies some storage separate from the bootloader but this doesn't need to be a filesystem.
Wait, what!?
Much as I think a bunch of the current problems have been caused by being overly keen to push the dtb into firmware, we shouldn't *ban* the original Open Firmware model of the device tree, where it is generated by the firmware and consumed by the OS.
If the DTB generating firmware can be updated by the end user just as easily and safely as a standalone DTB then that's probably fine. But we do know that many people/organizations are not willing to let end users upgrade bootloaders due to the risks associated with such an operation. So in that case we may not suggest the DTB be tied to the bootloader/firmware.
No, even then. I really don't think trying to ban the actual, original Open Firmware model of device tree usage is sensible.
On Mon, 19 Aug 2013, David Gibson wrote:
On Thu, Aug 15, 2013 at 10:51:18PM -0400, Nicolas Pitre wrote:
On Fri, 16 Aug 2013, David Gibson wrote:
On Wed, Aug 14, 2013 at 10:57:36PM -0400, Nicolas Pitre wrote:
On Wed, 14 Aug 2013, Tom Rini wrote:
On 08/14/2013 08:37 PM, Nicolas Pitre wrote:
On Wed, 14 Aug 2013, Tom Rini wrote:
[snip]
Well, the hard guideline should require that the DTB be updateable and not linked with nor generated by the bootloader or firmware. That implies some storage separate from the bootloader but this doesn't need to be a filesystem.
Wait, what!?
Much as I think a bunch of the current problems have been caused by being overly keen to push the dtb into firmware, we shouldn't *ban* the original Open Firmware model of the device tree, where it is generated by the firmware and consumed by the OS.
If the DTB generating firmware can be updated by the end user just as easily and safely as a standalone DTB then that's probably fine. But we do know that many people/organizations are not willing to let end users upgrade bootloaders due to the risks associated with such an operation. So in that case we may not suggest the DTB be tied to the bootloader/firmware.
No, even then. I really don't think trying to ban the actual, original Open Firmware model of device tree usage is sensible.
I don't think we should *ban* anything. This is rather about recommending best practice to people.
And if your bootloader produces a bad DTB and you cannot let end users upgrade the bootloader then this is certainly against best practice.
Nicolas
On 19.08.2013, at 19:43, Nicolas Pitre wrote:
On Mon, 19 Aug 2013, David Gibson wrote:
On Thu, Aug 15, 2013 at 10:51:18PM -0400, Nicolas Pitre wrote:
On Fri, 16 Aug 2013, David Gibson wrote:
On Wed, Aug 14, 2013 at 10:57:36PM -0400, Nicolas Pitre wrote:
On Wed, 14 Aug 2013, Tom Rini wrote:
On 08/14/2013 08:37 PM, Nicolas Pitre wrote: > On Wed, 14 Aug 2013, Tom Rini wrote:
[snip]
Well, the hard guideline should require that the DTB be updateable and not linked with nor generated by the bootloader or firmware. That implies some storage separate from the bootloader but this doesn't need to be a filesystem.
Wait, what!?
Much as I think a bunch of the current problems have been caused by being overly keen to push the dtb into firmware, we shouldn't *ban* the original Open Firmware model of the device tree, where it is generated by the firmware and consumed by the OS.
If the DTB generating firmware can be updated by the end user just as easily and safely as a standalone DTB then that's probably fine. But we do know that many people/organizations are not willing to let end users upgrade bootloaders due to the risks associated with such an operation. So in that case we may not suggest the DTB be tied to the bootloader/firmware.
No, even then. I really don't think trying to ban the actual, original Open Firmware model of device tree usage is sensible.
I don't think we should *ban* anything. This is rather about recommending best practice to people.
And if your bootloader produces a bad DTB and you cannot let end users upgrade the bootloader then this is certainly against best practice.
But that's exactly how everyone else works. On x86 you get your ACPI tables from firmware, on PPC you get your device tree from firmware and you really don't update your firmware just because your OS thinks the tables are wrong.
Of course, this means that we get a bunch of quirks in Linux to support partially broken device description facilities, but it at least gives you a proper split between "firmware developer" as someone who knows the hardware and "kernel developer" as someone who tries to be as agnostic as possible.
Long story short, with UEFI coming I'm pretty sure things on ARM will move to the firmware delivered description tables anyway. So what exactly are we discussing here?
Alex
On Tue, 20 Aug 2013, Alexander Graf wrote:
On 19.08.2013, at 19:43, Nicolas Pitre wrote:
On Mon, 19 Aug 2013, David Gibson wrote:
On Thu, Aug 15, 2013 at 10:51:18PM -0400, Nicolas Pitre wrote:
On Fri, 16 Aug 2013, David Gibson wrote:
On Wed, Aug 14, 2013 at 10:57:36PM -0400, Nicolas Pitre wrote:
On Wed, 14 Aug 2013, Tom Rini wrote: > On 08/14/2013 08:37 PM, Nicolas Pitre wrote: >> On Wed, 14 Aug 2013, Tom Rini wrote:
[snip]
Well, the hard guideline should require that the DTB be updateable and not linked with nor generated by the bootloader or firmware. That implies some storage separate from the bootloader but this doesn't need to be a filesystem.
Wait, what!?
Much as I think a bunch of the current problems have been caused by being overly keen to push the dtb into firmware, we shouldn't *ban* the original Open Firmware model of the device tree, where it is generated by the firmware and consumed by the OS.
If the DTB generating firmware can be updated by the end user just as easily and safely as a standalone DTB then that's probably fine. But we do know that many people/organizations are not willing to let end users upgrade bootloaders due to the risks associated with such an operation. So in that case we may not suggest the DTB be tied to the bootloader/firmware.
No, even then. I really don't think trying to ban the actual, original Open Firmware model of device tree usage is sensible.
I don't think we should *ban* anything. This is rather about recommending best practice to people.
And if your bootloader produces a bad DTB and you cannot let end users upgrade the bootloader then this is certainly against best practice.
But that's exactly how everyone else works. On x86 you get your ACPI tables from firmware, on PPC you get your device tree from firmware and you really don't update your firmware just because your OS thinks the tables are wrong.
And everyone, except maybe yourself, despise that state of affair.
Sorry but we ought to push for something better when we can. As device tree is being established on ARM, now is the time to learn from past mistakes and break away from the broken legacy methods.
Nicolas
On Tue, Aug 20, 2013 at 7:02 AM, Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Tue, 20 Aug 2013, Alexander Graf wrote:
And if your bootloader produces a bad DTB and you cannot let end users upgrade the bootloader then this is certainly against best practice.
But that's exactly how everyone else works. On x86 you get your ACPI tables from firmware, on PPC you get your device tree from firmware and you really don't update your firmware just because your OS thinks the tables are wrong.
And everyone, except maybe yourself, despise that state of affair.
Sorry but we ought to push for something better when we can. As device tree is being established on ARM, now is the time to learn from past mistakes and break away from the broken legacy methods.
Well, provide support for real OpenFirmware or firmware-provided DTB, and allow people to append DTBs to their kernels if they need to update them.
The better state of affairs is that vendors who wish to support Linux on the systems they ship would allow the firmware to be upgraded and collaborate in the process. If they do not wish this or wish to cooperate with this procedure, you can vote with your wallet; don't buy their systems.
The idea that you could say "we accept some device trees but not all" even if they follow standards at the time and the standards changed is not going to fly, simply because what you're pushing is device trees, and yes.. sometimes things change, and bindings move on, and they may not be compatible.
In the case of a real OpenFirmware implementation it is ridiculously easy to either patch the device tree in the firmware (load a Forth script - I can point at two examples for this) or do it in the kernel via CIF.
In the case of other bootloaders like U-Boot, libfdt provides the ability to modify and insert loaded device trees to match (in which case, the DTB bundled in the flash of some board is just a starting point).
The worst case scenario is that it would be completely hosed, and in this case an appended (or overridden by loading from filesystem or other flash location) DTB is the solution - just like you can load ACPI tables for some systems where the vendor shipped version is totally broken.
There isn't a way around this, it's a fact of life in an imperfect world. What you can do is keep Linux clean and move all device tree modification/fixup crap to the vendor/bootloader responsibility where it should be. If any of the above is not possible then it's going to be incredibly difficult - to the point that insisting on complete simplification and standardization of bootloader configurations and "sanity" of device trees doesn't apply anyway. Sometimes vendors will do what they want to do and not what you want to do; Linux no work, and that is that.
On Tue, 20 Aug 2013, Matt Sealey wrote:
On Tue, Aug 20, 2013 at 7:02 AM, Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Tue, 20 Aug 2013, Alexander Graf wrote:
And if your bootloader produces a bad DTB and you cannot let end users upgrade the bootloader then this is certainly against best practice.
But that's exactly how everyone else works. On x86 you get your ACPI tables from firmware, on PPC you get your device tree from firmware and you really don't update your firmware just because your OS thinks the tables are wrong.
And everyone, except maybe yourself, despise that state of affair.
Sorry but we ought to push for something better when we can. As device tree is being established on ARM, now is the time to learn from past mistakes and break away from the broken legacy methods.
Well, provide support for real OpenFirmware or firmware-provided DTB, and allow people to append DTBs to their kernels if they need to update them.
Forget about appending DTBs to the kernel. That's only a temporary hack which would add more maintenance work into distro people's plate if that was to be promoted as a recommended practice.
The better state of affairs is that vendors who wish to support Linux on the systems they ship would allow the firmware to be upgraded and collaborate in the process.
That's what I've been saying all along. Either the firmware is fixable by anyone (meaning source code is available) and upgradeable by end users, or the firmware allows for easy update by end users of the DTB it passes to the kernel if the OEM is too nervous about firmware upgrades or unwilling to publish the source for it.
If they do not wish this or wish to cooperate with this procedure, you can vote with your wallet; don't buy their systems.
This thread is about providing them with good guidelines they can follow _before_ they make bad decisions, most of the time out of ignorance rather than malice, about their firmware implementation.
In the case of a real OpenFirmware implementation it is ridiculously easy to either patch the device tree in the firmware (load a Forth script - I can point at two examples for this) or do it in the kernel via CIF.
In the case of other bootloaders like U-Boot, libfdt provides the ability to modify and insert loaded device trees to match (in which case, the DTB bundled in the flash of some board is just a starting point).
The worst case scenario is that it would be completely hosed, and in this case an appended (or overridden by loading from filesystem or other flash location) DTB is the solution - just like you can load ACPI tables for some systems where the vendor shipped version is totally broken.
Sure. But that's not what "best practices for hardware shipping device trees" should be about. Working around a broken one is always possible, but if we pass the message to OEMs that we're happy to paper over their mistakes with a side channel they might decide not to care about providing a method allowing the unavoidable mistakes to be fixed at its source.
We want the DTB to live with the firmware or bootloader, and the ability to fix a broken DTB at that level. That's all.
Nicolas
On 08/20/2013 02:40 AM, Alexander Graf wrote:
On 19.08.2013, at 19:43, Nicolas Pitre wrote:
On Mon, 19 Aug 2013, David Gibson wrote:
On Thu, Aug 15, 2013 at 10:51:18PM -0400, Nicolas Pitre wrote:
On Fri, 16 Aug 2013, David Gibson wrote:
On Wed, Aug 14, 2013 at 10:57:36PM -0400, Nicolas Pitre wrote:
On Wed, 14 Aug 2013, Tom Rini wrote: > On 08/14/2013 08:37 PM, Nicolas Pitre wrote: >> On Wed, 14 Aug 2013, Tom Rini wrote:
[snip]
Well, the hard guideline should require that the DTB be updateable and not linked with nor generated by the bootloader or firmware. That implies some storage separate from the bootloader but this doesn't need to be a filesystem.
Wait, what!?
Much as I think a bunch of the current problems have been caused by being overly keen to push the dtb into firmware, we shouldn't *ban* the original Open Firmware model of the device tree, where it is generated by the firmware and consumed by the OS.
If the DTB generating firmware can be updated by the end user just as easily and safely as a standalone DTB then that's probably fine. But we do know that many people/organizations are not willing to let end users upgrade bootloaders due to the risks associated with such an operation. So in that case we may not suggest the DTB be tied to the bootloader/firmware.
No, even then. I really don't think trying to ban the actual, original Open Firmware model of device tree usage is sensible.
I don't think we should *ban* anything. This is rather about recommending best practice to people.
And if your bootloader produces a bad DTB and you cannot let end users upgrade the bootloader then this is certainly against best practice.
But that's exactly how everyone else works. On x86 you get your ACPI tables from firmware, on PPC you get your device tree from firmware and you really don't update your firmware just because your OS thinks the tables are wrong.
I think others have pointed out elsewhere that it's not "OS thinks the tables are wrong" but "ACPI tables are wrong, update your firmware" and there are firmware updates to fix these problems required.
Of course, this means that we get a bunch of quirks in Linux to support partially broken device description facilities, but it at least gives you a proper split between "firmware developer" as someone who knows the hardware and "kernel developer" as someone who tries to be as agnostic as possible.
Long story short, with UEFI coming I'm pretty sure things on ARM will move to the firmware delivered description tables anyway. So what exactly are we discussing here?
ARMv8 is moving towards having 3 combinations available, yes. UEFI+ACPI, UEFI+Device Tree and not-UEFI+Device Tree. And we're also talking about ARMv7 and so on that while people are pushing UEFI in places will probably be like x86 and UEFI, possible but not recommended (and still end up being device trees, not ACPI).
On 08/14/2013 05:37 PM, Nicolas Pitre wrote:
Using /boot implies a distro filesystem and we'd rather wish for DT to be independent from a distro or even Linux. The DTB should therefore be stored and accessed in a way which is hardware/bootloader specific. The distro being installed on top shouldn't have to care.
Yes. As a distro provider I would like to see the following from uBoot-using hardware:
1. Every device ships with a DTB embedded in non-volatile storage. Basically, if it ships with uBoot it includes a device tree sufficiently accurate to boot a kernel configured to support the SoC.
2. Standard environment variables telling me where that DTB is located. Today this is often fdt_addr_r or fdt_addr.
3. Standard environment variables telling me what a replacement DTB would be named. Today ${soc}-${board} is almost reliable.
4. A method by which to update the DTB stored in nonvolatile memory without updating uBoot itself. This could be done via management controller or within u-boot (Again, using the variables from 2 and 3 above).
The core idea is that the device provide all the information necessary to boot the device. In the event that information becomes inaccurate relative to the needs of later kernels there needs to be a way to update that information, either per-boot or permanently.
On 08/15/2013 12:02 PM, Brendan Conoboy wrote:
On 08/14/2013 05:37 PM, Nicolas Pitre wrote:
Using /boot implies a distro filesystem and we'd rather wish for DT to be independent from a distro or even Linux. The DTB should therefore be stored and accessed in a way which is hardware/bootloader specific. The distro being installed on top shouldn't have to care.
Yes. As a distro provider I would like to see the following from uBoot-using hardware:
- Every device ships with a DTB embedded in non-volatile storage.
Basically, if it ships with uBoot it includes a device tree sufficiently accurate to boot a kernel configured to support the SoC.
- Standard environment variables telling me where that DTB is located.
Today this is often fdt_addr_r or fdt_addr.
- Standard environment variables telling me what a replacement DTB
would be named. Today ${soc}-${board} is almost reliable.
- A method by which to update the DTB stored in nonvolatile memory
without updating uBoot itself. This could be done via management controller or within u-boot (Again, using the variables from 2 and 3 above).
The core idea is that the device provide all the information necessary to boot the device. In the event that information becomes inaccurate relative to the needs of later kernels there needs to be a way to update that information, either per-boot or permanently.
What I don't see above is something about loading the full DTB from non-volatile storage and into memory.
The only problem I see is you're not dealing with platforms that don't include non-volatile storage on the board itself (Beaglebone White, Pandaboard, RPi, Allwinner boards without eMMC/NAND, etc). Or are you including somehow stored on SD card in the list?
It otherwise sounds reasonable to me, thanks.
On Thu, Aug 15, 2013 at 6:07 PM, Tom Rini trini@ti.com wrote:
On 08/15/2013 12:02 PM, Brendan Conoboy wrote:
On 08/14/2013 05:37 PM, Nicolas Pitre wrote:
Using /boot implies a distro filesystem and we'd rather wish for DT to be independent from a distro or even Linux. The DTB should therefore be stored and accessed in a way which is hardware/bootloader specific. The distro being installed on top shouldn't have to care.
Yes. As a distro provider I would like to see the following from uBoot-using hardware:
- Every device ships with a DTB embedded in non-volatile storage.
Basically, if it ships with uBoot it includes a device tree sufficiently accurate to boot a kernel configured to support the SoC.
- Standard environment variables telling me where that DTB is located.
Today this is often fdt_addr_r or fdt_addr.
- Standard environment variables telling me what a replacement DTB
would be named. Today ${soc}-${board} is almost reliable.
- A method by which to update the DTB stored in nonvolatile memory
without updating uBoot itself. This could be done via management controller or within u-boot (Again, using the variables from 2 and 3 above).
The core idea is that the device provide all the information necessary to boot the device. In the event that information becomes inaccurate relative to the needs of later kernels there needs to be a way to update that information, either per-boot or permanently.
What I don't see above is something about loading the full DTB from non-volatile storage and into memory.
I believe he alluded to that in section 2 in the standard location to load it from.
The only problem I see is you're not dealing with platforms that don't include non-volatile storage on the board itself (Beaglebone White, Pandaboard, RPi, Allwinner boards without eMMC/NAND, etc). Or are you including somehow stored on SD card in the list?
In this case for Fedora at least we're shipping our own built binaries with the options we need. If upstream uboot includes the dtbs as part of the uboot we'd likely build them as part of the the various uboots we ship but in the interim we're using the ones we ship with the kernel.
Ultimately a DT shipped within a firmware will some what depend on the DT being abi stable so that people know that it should always be able to boot with the shipped DT no matter what the kernel is even if the ABI is extended with time.
Peter
On 08/16/2013 11:40 AM, Peter Robinson wrote:
On Thu, Aug 15, 2013 at 6:07 PM, Tom Rini trini@ti.com wrote:
On 08/15/2013 12:02 PM, Brendan Conoboy wrote:
On 08/14/2013 05:37 PM, Nicolas Pitre wrote:
Using /boot implies a distro filesystem and we'd rather wish for DT to be independent from a distro or even Linux. The DTB should therefore be stored and accessed in a way which is hardware/bootloader specific. The distro being installed on top shouldn't have to care.
Yes. As a distro provider I would like to see the following from uBoot-using hardware:
- Every device ships with a DTB embedded in non-volatile storage.
Basically, if it ships with uBoot it includes a device tree sufficiently accurate to boot a kernel configured to support the SoC.
- Standard environment variables telling me where that DTB is located.
Today this is often fdt_addr_r or fdt_addr.
- Standard environment variables telling me what a replacement DTB
would be named. Today ${soc}-${board} is almost reliable.
- A method by which to update the DTB stored in nonvolatile memory
without updating uBoot itself. This could be done via management controller or within u-boot (Again, using the variables from 2 and 3 above).
The core idea is that the device provide all the information necessary to boot the device. In the event that information becomes inaccurate relative to the needs of later kernels there needs to be a way to update that information, either per-boot or permanently.
What I don't see above is something about loading the full DTB from non-volatile storage and into memory.
I believe he alluded to that in section 2 in the standard location to load it from.
Being nit-picky since it's important for this to be clear (as we're talking about things that will be done by people just reading this later), section 2 is a location in memory. fdt_addr_r is where "device tree coming from somewhere will now reside in memory at this location" and "fdt_addr" is "a device tree currently lives in memory at this location". Arguably, if we expect firmware/bootloader to know where a device tree is (because it came with the hardware) it should load it to fdt_addr, and fdt_addr_r is for a user-specified (in their extlinux.conf or whatever) tree, rather than how it's often used today (fdtaddr or fdt_addr or fdt_addr_r all around, with very few using both fdt_addr and fdt_addr_r).
The only problem I see is you're not dealing with platforms that don't include non-volatile storage on the board itself (Beaglebone White, Pandaboard, RPi, Allwinner boards without eMMC/NAND, etc). Or are you including somehow stored on SD card in the list?
In this case for Fedora at least we're shipping our own built binaries with the options we need. If upstream uboot includes the dtbs as part of the uboot we'd likely build them as part of the the various uboots we ship but in the interim we're using the ones we ship with the kernel.
I'm sorry, but I don't see the answer to my question here. The long term plan is that DTs are not bundled with the kernel nor with U-Boot but live on their own. So I guess I'm thinking / asking, is a file in the SD card good enough for the non-volatile storage side of things (and U-Boot looks for, loads the 'master' DT into fdt_addr and then user/distro can override into fdt_addr_r however they like).
Ultimately a DT shipped within a firmware will some what depend on the DT being abi stable so that people know that it should always be able to boot with the shipped DT no matter what the kernel is even if the ABI is extended with time.
Agreed.
On 08/16/2013 09:14 AM, Tom Rini wrote:
On 08/16/2013 11:40 AM, Peter Robinson wrote: Arguably, if we expect firmware/bootloader to know where a device tree is (because it came with the hardware) it should load it to fdt_addr, and fdt_addr_r is for a user-specified (in their extlinux.conf or whatever) tree, rather than how it's often used today (fdtaddr or fdt_addr or fdt_addr_r all around, with very few using both fdt_addr and fdt_addr_r).
That's exactly the sort of argument I would make. Correctly describing the platform to the kernel is first and foremost the firmware's business. History tells us that it is useful for the OS to be able to override that information, but this should only be looked at as a backup plan when what's shipped is incompatible with the OS's needs.
I'm sorry, but I don't see the answer to my question here. The long term plan is that DTs are not bundled with the kernel nor with U-Boot but live on their own. So I guess I'm thinking / asking, is a file in the SD card good enough for the non-volatile storage side of things (and U-Boot looks for, loads the 'master' DT into fdt_addr and then user/distro can override into fdt_addr_r however they like).
If they're separate from the firmware and separate from the kernel what are they attached to? Since I'm take the position that DTB informations is uBoot's problem to solve I would say it's up to the provider of uBoot to ensure the right DTB is loaded whether or not it is part of upstream uBoot. In Fedora's case that means we would add a DTB package that our uBoot package depends upon. Hopefully there will be a centralized site for DTBs in this scenario.
On 08/16/2013 02:43 PM, Brendan Conoboy wrote:
On 08/16/2013 09:14 AM, Tom Rini wrote:
On 08/16/2013 11:40 AM, Peter Robinson wrote: Arguably, if we expect firmware/bootloader to know where a device tree is (because it came with the hardware) it should load it to fdt_addr, and fdt_addr_r is for a user-specified (in their extlinux.conf or whatever) tree, rather than how it's often used today (fdtaddr or fdt_addr or fdt_addr_r all around, with very few using both fdt_addr and fdt_addr_r).
That's exactly the sort of argument I would make. Correctly describing the platform to the kernel is first and foremost the firmware's business. History tells us that it is useful for the OS to be able to override that information, but this should only be looked at as a backup plan when what's shipped is incompatible with the OS's needs.
I'll just note there's debate on if DT should be allowed to be generated, ala OpenFirmware or must be stored as a DT and passed in. But yes, so long as it's possible, the firmware should put DT somewhere for the kernel to use.
I'm sorry, but I don't see the answer to my question here. The long term plan is that DTs are not bundled with the kernel nor with U-Boot but live on their own. So I guess I'm thinking / asking, is a file in the SD card good enough for the non-volatile storage side of things (and U-Boot looks for, loads the 'master' DT into fdt_addr and then user/distro can override into fdt_addr_r however they like).
If they're separate from the firmware and separate from the kernel what are they attached to? Since I'm take the position that DTB informations is uBoot's problem to solve I would say it's up to the provider of uBoot to ensure the right DTB is loaded whether or not it is part of upstream uBoot. In Fedora's case that means we would add a DTB package that our uBoot package depends upon. Hopefully there will be a centralized site for DTBs in this scenario.
The argument being put forth over in the devicetrees@vger thread and elsewhere I believe is that the device tree isn't attached to anything.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, 16 Aug 2013 12:14:45 -0400 Tom Rini trini@ti.com wrote:
On 08/16/2013 11:40 AM, Peter Robinson wrote:
On Thu, Aug 15, 2013 at 6:07 PM, Tom Rini trini@ti.com wrote:
On 08/15/2013 12:02 PM, Brendan Conoboy wrote:
On 08/14/2013 05:37 PM, Nicolas Pitre wrote:
Using /boot implies a distro filesystem and we'd rather wish for DT to be independent from a distro or even Linux. The DTB should therefore be stored and accessed in a way which is hardware/bootloader specific. The distro being installed on top shouldn't have to care.
Yes. As a distro provider I would like to see the following from uBoot-using hardware:
- Every device ships with a DTB embedded in non-volatile storage.
Basically, if it ships with uBoot it includes a device tree sufficiently accurate to boot a kernel configured to support the SoC.
- Standard environment variables telling me where that DTB is
located. Today this is often fdt_addr_r or fdt_addr.
- Standard environment variables telling me what a replacement
DTB would be named. Today ${soc}-${board} is almost reliable.
- A method by which to update the DTB stored in nonvolatile
memory without updating uBoot itself. This could be done via management controller or within u-boot (Again, using the variables from 2 and 3 above).
The core idea is that the device provide all the information necessary to boot the device. In the event that information becomes inaccurate relative to the needs of later kernels there needs to be a way to update that information, either per-boot or permanently.
What I don't see above is something about loading the full DTB from non-volatile storage and into memory.
I believe he alluded to that in section 2 in the standard location to load it from.
Being nit-picky since it's important for this to be clear (as we're talking about things that will be done by people just reading this later), section 2 is a location in memory. fdt_addr_r is where "device tree coming from somewhere will now reside in memory at this location" and "fdt_addr" is "a device tree currently lives in memory at this location". Arguably, if we expect firmware/bootloader to know where a device tree is (because it came with the hardware) it should load it to fdt_addr, and fdt_addr_r is for a user-specified (in their extlinux.conf or whatever) tree, rather than how it's often used today (fdtaddr or fdt_addr or fdt_addr_r all around, with very few using both fdt_addr and fdt_addr_r).
my opinion is that any dtb loaded by the firmware should be loaded to fdt_addr its up to the vendor if they provide the dtb in non-volatile storage or they load from a known location i.e. local disk at /boot/dtb/<dtbfile> /dtb/<dtbfile> or they tftp load it from /dtb/<dtbfile> to me it is a must that u-boot load a dtb to fdt_addr
the user can override the vendors dtb by loading one to fdt_addr_r
while in the patch i sent upstream for u-boot fdt_addr and fdt_addr_r are different pointers to the same address, on further reflection they really should be separate.
The only problem I see is you're not dealing with platforms that don't include non-volatile storage on the board itself (Beaglebone White, Pandaboard, RPi, Allwinner boards without eMMC/NAND, etc). Or are you including somehow stored on SD card in the list?
In this case for Fedora at least we're shipping our own built binaries with the options we need. If upstream uboot includes the dtbs as part of the uboot we'd likely build them as part of the the various uboots we ship but in the interim we're using the ones we ship with the kernel.
I'm sorry, but I don't see the answer to my question here. The long term plan is that DTs are not bundled with the kernel nor with U-Boot but live on their own. So I guess I'm thinking / asking, is a file in the SD card good enough for the non-volatile storage side of things (and U-Boot looks for, loads the 'master' DT into fdt_addr and then user/distro can override into fdt_addr_r however they like).
the answer is that we as distros will put the dtb files into a known location /boot/dtb/<dtbfile> or /dtb/<dtbfile> and u-boot will load them for us to fdt_addr. we could also support putting the dtb into some raw space where it could be loaded from also.
Ultimately a DT shipped within a firmware will some what depend on the DT being abi stable so that people know that it should always be able to boot with the shipped DT no matter what the kernel is even if the ABI is extended with time.
Agreed.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/16/2013 04:13 PM, Dennis Gilmore wrote:
On Fri, 16 Aug 2013 12:14:45 -0400 Tom Rini trini@ti.com wrote:
On 08/16/2013 11:40 AM, Peter Robinson wrote:
On Thu, Aug 15, 2013 at 6:07 PM, Tom Rini trini@ti.com wrote:
On 08/15/2013 12:02 PM, Brendan Conoboy wrote:
On 08/14/2013 05:37 PM, Nicolas Pitre wrote:
Using /boot implies a distro filesystem and we'd rather wish for DT to be independent from a distro or even Linux. The DTB should therefore be stored and accessed in a way which is hardware/bootloader specific. The distro being installed on top shouldn't have to care.
Yes. As a distro provider I would like to see the following from uBoot-using hardware:
- Every device ships with a DTB embedded in non-volatile
storage. Basically, if it ships with uBoot it includes a device tree sufficiently accurate to boot a kernel configured to support the SoC.
- Standard environment variables telling me where that DTB
is located. Today this is often fdt_addr_r or fdt_addr.
- Standard environment variables telling me what a
replacement DTB would be named. Today ${soc}-${board} is almost reliable.
- A method by which to update the DTB stored in
nonvolatile memory without updating uBoot itself. This could be done via management controller or within u-boot (Again, using the variables from 2 and 3 above).
The core idea is that the device provide all the information necessary to boot the device. In the event that information becomes inaccurate relative to the needs of later kernels there needs to be a way to update that information, either per-boot or permanently.
What I don't see above is something about loading the full DTB from non-volatile storage and into memory.
I believe he alluded to that in section 2 in the standard location to load it from.
Being nit-picky since it's important for this to be clear (as we're talking about things that will be done by people just reading this later), section 2 is a location in memory. fdt_addr_r is where "device tree coming from somewhere will now reside in memory at this location" and "fdt_addr" is "a device tree currently lives in memory at this location". Arguably, if we expect firmware/bootloader to know where a device tree is (because it came with the hardware) it should load it to fdt_addr, and fdt_addr_r is for a user-specified (in their extlinux.conf or whatever) tree, rather than how it's often used today (fdtaddr or fdt_addr or fdt_addr_r all around, with very few using both fdt_addr and fdt_addr_r).
my opinion is that any dtb loaded by the firmware should be loaded to fdt_addr its up to the vendor if they provide the dtb in non-volatile storage or they load from a known location i.e. local disk at /boot/dtb/<dtbfile> /dtb/<dtbfile> or they tftp load it from /dtb/<dtbfile> to me it is a must that u-boot load a dtb to fdt_addr
the user can override the vendors dtb by loading one to fdt_addr_r
while in the patch i sent upstream for u-boot fdt_addr and fdt_addr_r are different pointers to the same address, on further reflection they really should be separate.
I agree as well.
The only problem I see is you're not dealing with platforms that don't include non-volatile storage on the board itself (Beaglebone White, Pandaboard, RPi, Allwinner boards without eMMC/NAND, etc). Or are you including somehow stored on SD card in the list?
In this case for Fedora at least we're shipping our own built binaries with the options we need. If upstream uboot includes the dtbs as part of the uboot we'd likely build them as part of the the various uboots we ship but in the interim we're using the ones we ship with the kernel.
I'm sorry, but I don't see the answer to my question here. The long term plan is that DTs are not bundled with the kernel nor with U-Boot but live on their own. So I guess I'm thinking / asking, is a file in the SD card good enough for the non-volatile storage side of things (and U-Boot looks for, loads the 'master' DT into fdt_addr and then user/distro can override into fdt_addr_r however they like).
the answer is that we as distros will put the dtb files into a known location /boot/dtb/<dtbfile> or /dtb/<dtbfile> and u-boot will load them for us to fdt_addr. we could also support putting the dtb into some raw space where it could be loaded from also.
I would say whatever we get from the user (be it distro or individual) goes to fdt_addr_r and fdt_addr is for the provided dtb. And I would punt the logic of finding it from where to the distro-created but still board-agnostic boot whatever-you-wish-to-call it.
- -- Tom
On 08/15/2013 10:07 AM, Tom Rini wrote:
What I don't see above is something about loading the full DTB from non-volatile storage and into memory.
Implicit assumption: When the bootloader comes up it has already put the DTB into place.
The only problem I see is you're not dealing with platforms that don't include non-volatile storage on the board itself (Beaglebone White, Pandaboard, RPi, Allwinner boards without eMMC/NAND, etc). Or are you including somehow stored on SD card in the list?
Yeah, this is a something of a pain point, but more for OS vendors needing to provide a suitable uBoot. DTB is just a subset of that problem. If the platform itself doesn't provide non volatile storage I think it's reasonable to ask that the boot loader still automatically retrieve a known-good DTB by whatever means make sense for the device. The only reason the OS should be involved in the DTB equation is when the supplied DTB content is in some way deficient relative to the needs of the kernel interpreting it.
It otherwise sounds reasonable to me, thanks.
Thanks!
On 08/16/2013 02:30 PM, Brendan Conoboy wrote:
On 08/15/2013 10:07 AM, Tom Rini wrote:
What I don't see above is something about loading the full DTB from non-volatile storage and into memory.
Implicit assumption: When the bootloader comes up it has already put the DTB into place.
OK, lets spell that out.
The only problem I see is you're not dealing with platforms that don't include non-volatile storage on the board itself (Beaglebone White, Pandaboard, RPi, Allwinner boards without eMMC/NAND, etc). Or are you including somehow stored on SD card in the list?
Yeah, this is a something of a pain point, but more for OS vendors needing to provide a suitable uBoot. DTB is just a subset of that problem. If the platform itself doesn't provide non volatile storage I think it's reasonable to ask that the boot loader still automatically retrieve a known-good DTB by whatever means make sense for the device. The only reason the OS should be involved in the DTB equation is when the supplied DTB content is in some way deficient relative to the needs of the kernel interpreting it.
OK, I think I can go with this, with the constraint / understanding that it also means the DT lives somewhere firmware-happy. Using TI platforms as an example, the SD card would have the FAT partition with MLO/u-boot.img/foo.dtb on it, since ROM groks FAT.
-
Alexander Graf -
Brendan Conoboy -
David Gibson -
Dennis Gilmore -
Matt Sealey -
Nicolas Pitre -
Peter Robinson -
Stephen Warren -
Tom Rini -
Tom Rini