Re: Mikrotik RouterBoard 333

[Jerry Van Baren <gvb.linuxppc.dev@gmail.com>]

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