On Mon, Jun 14, 2010 at 10:02 AM, Jamie Lokier [off-list ref] 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. =A0If the OS doesn't tr=

ust the

quoted

quoted

quoted

quoted

firmware, there is no pressure for the firmware to "get it right".

Firmware will not get it right. =A0Period. =A0There will always be
something wrong. =A0It is never right on PCs. =A0It will never be ri=

ght on

quoted

quoted

quoted

the other architectures.

Yes, yes, yes. =A0And there is a great deal of empirical evidence to
back that assertion.

quoted

=A0That goes for OSes too, but upgrading an OS
isn't as risky as upgrading firmware. =A0That isn't to say that it c=

an't

quoted

quoted

quoted

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. =A0In fact, the general rule of thumb is really "put as much a=

s

quoted

quoted

possible into the most easily replaced layer of the stack". =A0This is=

,

quoted

quoted

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. =A0If in the en=

d

quoted

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. =A0And 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. =A0Just 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. =A0It'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.

This is totally fine.  I've got no problem with a specific firmware
requiring everything (kernel,dt,rootfs) packed into a single image
file.  Packing the image can be done at OS install time (instead of
prebuilding it) if the system builder want to retain the independent
hardware configuration aspects of using the device tree.

Dedicating a 64kiB eraseblock out of 2MB just for a small DT would be
quite wasteful. =A0Dedicating 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.

Independent update of the DT is a useful feature, but it is certainly
not a hard requirement.  It's a far more likely use-case if the kernel
and DT is stored on a filesystem instead of bare NOR flash.

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.

Yes, I fully expect that.  Fortunately the situation is better than it
was with powerpc.  Since the machine id is being retained, a
DT-enabled kernel can continue to support non-DT systems.  There will
not be a flag day to cut everything over to a new boot interface.

g.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.