Re: [RFC] Best practices for hardware shipping device trees

[Tom Rini <trini@ti.com>]

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

-- 
Tom