Request review of device tree documentation

[jamie@shareable.org (Jamie Lokier)]

Nicolas Pitre wrote:
> On Mon, 14 Jun 2010, David Gibson wrote:
> 
> > On Sun, Jun 13, 2010 at 11:02:15PM -0600, Grant Likely wrote:
> > [sni]
> > > > That's sort of a self-fulfilling prophecy. ?If the OS doesn't trust the
> > > > firmware, there is no pressure for the firmware to "get it right".
> > > 
> > > Firmware will not get it right.  Period.  There will always be
> > > something wrong.  It is never right on PCs.  It will never be right on
> > > the other architectures.
> > 
> > Yes, yes, yes.  And there is a great deal of empirical evidence to
> > back that assertion.
> > 
> > >  That goes for OSes too, but upgrading an OS
> > > isn't as risky as upgrading firmware.  That isn't to say that it can't
> > > be close, but every firmware feature that the OS depends on is a
> > > feature that could force a risky firmware upgrade when the bug in it
> > > is discovered.
> > 
> > Indeed.  In fact, the general rule of thumb is really "put as much as
> > possible into the most easily replaced layer of the stack".  This is,
> > incidentally, why I've always been dubious about simple firmwares
> > supplying a flattened device tree rather than including the device
> > tree template in the kernel, cuboot style.
> 
> The biggest advantage, IMHO, for adding DT to ARM, is actually to 
> decouple the hardware config information and the kernel.  If in the end 
> the DT has to be shipped in the kernel then we're losing all this 
> advantage over the current state of things on ARM which still works 
> pretty well otherwise.
> 
> In the best case, the simple firmware simply has to retrieve the 
> flattened device tree from flash, and pass it to the kernel just like 
> some anonymous blob.  And the simple firmware only needs to provide a 
> way for that DT blob to be updatable, like through an upload of a 
> replacement blob that was prepared offline.  Just like a ramdisk image 
> or the like.
> 
> That doesn't need to be fancier than that, and the goal of having the DT 
> data tied to the hardware instead of the kernel is achieved.

Imho that puts the DT in a similar category as initrd/initramfs, from
the bootloader's point of view.  It's another blob whose address is
passed to the kernel, just like initrd.

Some bootloaders can't update blobs independently for technical
reasons, or to be minimal.

A device I'm using does kernel updates by updating the whole romfs
boot image, which contains the kernel and other auxiliary blobs used
for booting (splash screen, early irq handlers etc.) as well as the
root filesystem.

It is done that way to pack everything together in the small flash,
and because the NOR flash eraseblocks are too large relative to the
whole flash size to use separate partitions for kernel, boot
filesystem and other blobs for booting.

Dedicating a 64kiB eraseblock out of 2MB just for a small DT would be
quite wasteful.  Dedicating two to make it powerfail-safe would be
even worse.

So requiring that a bootloader can update the DT _independently_ of
everything else is a bit much for some devices.

But requiring that it's generally treated like other separate blob,
i.e. in a similar way to initrd, and the kernel image itself, seems
not unreasonable.

Like initrd, some people will find they need to compile it in to the
kernel image to fit some bootloader they can't change, or daren't risk
changing in already rolled out devices that they want to update to a
DT-using kernel.

I won't be surprised if I see some vendor SDK containing a kernel
patch to early-parse the bootloader-supplied ROMFS image to extract
"devicetree.bin.gz" at some point :-)

We can discourage that sort of thing (but not prevent it) by ensuring
the open source bootloaders support a DT blob as easily as possible.

-- Jamie