On Mon, 14 Jun 2010, Jamie Lokier wrote:

Nicolas Pitre wrote:

quoted

On Mon, 14 Jun 2010, David Gibson wrote:

quoted

On Sun, Jun 13, 2010 at 11:02:15PM -0600, Grant Likely wrote:
[sni]

quoted

quoted

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.

quoted

 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.

Exact.

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.

If you already have to update everything at once already anyway, then 
the DT blob just has to be in that update.  No need to do otherwise if 
you can't do better than that for the kernel alone.

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.

I hardly see how you can be power fail safe with your 
update-everything-at-once condition above anyway.

Furthermore, if the DT is updated by the bootloader, then that means 
you're not running a live system at that point.  If power fails during 
the DT update, then you simply have to re-update it when power is back 
to allow a successful boot of the kernel afterwards.

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

In my opinion, this use case you're illustrating above simply could 
continue to _not_ use DT at all.  If your NOR flash is so small that you 
cannot spare some extra erase blocks, then this is a deeply embedded 
profile the current DT-on-ARM push is not really meant for.  You would 
be much better with a minimally configured kernel with all the hardware 
info statically compiled into the kernel and get away without all the DT 
parsing code altogether, like you're already doing today.

While I think DT for ARM has advantages, I don't see us dropping the 
legacy ARM methods anytime soon, especially for existing or extremely 
constrained targets.


Nicolas