Scott Wood wrote:
On Sun, Jul 13, 2008 at 08:44:46PM -0400, Jerry Van Baren wrote:
I'm a half-ack. ;-) I'm partial to u-boot's implementation rather than
using a bootwrapper for obvious reasons. The u-boot implementation
takes the blob as a boot parameter and passes it along to the kernel
after doing appropriate (optional) fixups.
And if those fixups expect a malformed device tree?
Oops, very bad choice of terms on my part. :-( The fixups I referred
to are mostly "fill in the blank" things like setting the various
clocks, MAC information, PCI information, etc. to the correct values
based on hardware probing or a priori knowledge. U-boot does not
(should not / will not!) fix broken device trees. A broken tree w/ the
u-boot methodology is fixed by loading a corrected one, not requiring a
full rebuild and reload of the firmware.
Note that the blobs are (should be) made from the *.dts files that are
part of the linux kernel source, so having correct ones has not been a
problem. Since replacement ones are easily loaded, broken blobs are
fixed by replacement, not by contorted fixups a'la the start of this
thread. Since blobs are well defined, even if some boneheaded company
didn't release their blob source, it is trivial to dump it (e.g. "fdt
print /"), fixed, and then replaced.
Other than that quibble, I agree that burning the blob into the firmware
so that the firmware must be recompiled and reburned to change the blob
is very undesirable.
I thought the device tree was *supposed* to be an interface between the
firmware and the kernel? What if the firmware produces the tree
dynamically? What if the firmware itself depends on having the device tree
in order to operate?
-Scott
Well, yes and no on dynamically generated blobs. There isn't much point
"dynamically" generating the static parts of the blob - if you have
static code "dynamically" generating the static parts of the blob, is it
dynamic or static? That is probably exactly where Mikrotik has
problems. The truly dynamic parts are a small part of the blob.
If all else fails, u-boot is GPLed and the user is able to get the
source and fix it (well, at least for 3 years after purchasing the
hardware).
There are advantages and disadvantages to u-boot and boot-wrapper
methods. There are nothing but disadvantages to having the blob
physically a part of the firmware (with a double whammy if the firmware
source is not readily available).
Best regards,
gvb
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
