Mikrotik RouterBoard 333

Mikrotik RouterBoard 333

[David Gibson]

Does anyone on this list have contacts with the makers of this board?

Its firmware apparently provides a flattened device tree to the OS.
And while this step towards world domination is flattering, it's an
example of what I feared when people first got enthusiastic about the
idea of including flattened device trees in firmwares.  The tree has
not, AFAIK, been past this list, and has apparently not been reviewed
by someone knowledgeable about device trees.  In short, it's crap, and
now that it's embedded in the firware we can't really fix it.

So, to any embedded hardware/firmware vendors doing Linux ports out
there.  I certainly encourage you to use flattened device trees, but
can I please suggest you put the blob into your kernel image (in the
bootwrapper strictly speaking), rather than into the flashed firmware.
It's a lot easier to fix mistakes that way.

There are situations where it's nice to have the device tree in
firmware, but there are many others where it buys little to nothing.
People seem to be a bit overenthusaistic on the concept at the moment.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: Mikrotik RouterBoard 333

[Grant Likely]

On Tue, Jul 08, 2008 at 02:26:32PM +1000, David Gibson wrote:
> Does anyone on this list have contacts with the makers of this board?
> 
> Its firmware apparently provides a flattened device tree to the OS.
> And while this step towards world domination is flattering, it's an
> example of what I feared when people first got enthusiastic about the
> idea of including flattened device trees in firmwares.  The tree has
> not, AFAIK, been past this list, and has apparently not been reviewed
> by someone knowledgeable about device trees.  In short, it's crap, and
> now that it's embedded in the firware we can't really fix it.
> 
> So, to any embedded hardware/firmware vendors doing Linux ports out
> there.  I certainly encourage you to use flattened device trees, but
> can I please suggest you put the blob into your kernel image (in the
> bootwrapper strictly speaking), rather than into the flashed firmware.
> It's a lot easier to fix mistakes that way.
> 
> There are situations where it's nice to have the device tree in
> firmware, but there are many others where it buys little to nothing.
> People seem to be a bit overenthusaistic on the concept at the moment.

Total Ack!  Allow me second that opinion.

g.

Re: Mikrotik RouterBoard 333

[Jerry Van Baren]

Grant Likely wrote:
> On Tue, Jul 08, 2008 at 02:26:32PM +1000, David Gibson wrote:
>> Does anyone on this list have contacts with the makers of this board?
>>
>> Its firmware apparently provides a flattened device tree to the OS.
>> And while this step towards world domination is flattering, it's an
>> example of what I feared when people first got enthusiastic about the
>> idea of including flattened device trees in firmwares.  The tree has
>> not, AFAIK, been past this list, and has apparently not been reviewed
>> by someone knowledgeable about device trees.  In short, it's crap, and
>> now that it's embedded in the firware we can't really fix it.
>>
>> So, to any embedded hardware/firmware vendors doing Linux ports out
>> there.  I certainly encourage you to use flattened device trees, but
>> can I please suggest you put the blob into your kernel image (in the
>> bootwrapper strictly speaking), rather than into the flashed firmware.
>> It's a lot easier to fix mistakes that way.
>>
>> There are situations where it's nice to have the device tree in
>> firmware, but there are many others where it buys little to nothing.
>> People seem to be a bit overenthusaistic on the concept at the moment.
> 
> Total Ack!  Allow me second that opinion.
> 
> g.

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.  The usual implementation is 
to burn it into a block of flash separate from u-boot itself or use tftp 
to load it from the server.

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.

Best regards,
gvb

Re: Mikrotik RouterBoard 333

[Scott Wood]

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?

> 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

Re: Mikrotik RouterBoard 333

[Segher Boessenkool]

>> 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?

Sure.  But in the case where the firmware just passes the
kernel some fixed blob, it is easier for everyone to include
that blob with the kernel instead.


Segher

Re: Mikrotik RouterBoard 333

[Jerry Van Baren]

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

Re: Mikrotik RouterBoard 333

[David Gibson]

On Mon, Jul 21, 2008 at 10:54:58PM -0400, Jerry Van Baren wrote:
> 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.

Well.. they often are, particularly for embedded boards.

If there really is a large part of the tree which is dynamic, then
certainly it makes sense for the firmware to generate it and supply a
blob to the kernel.  Of course in this sort of situation it would also
make sense to have a full OF firmware.  Likewise, if the firmware is
sufficiently complex to want to make substantial internal use of the
device tree, it makes sense for it to pass it to the kernel.  If you
have a firmware of this sort of sophistication, though, please, please
try to get the tree *right*.

A lot of firmwares however, as gvb says just take a skeleton device
tree and do nothing more than poke a few integers into specific places
into it.  Maybe either leave in or remove a subtree representing an
optional peripheral.

This is the common case for embedded systems where something in the
installed software stack has to Just Know what the hardware looks
like.  In this case, in theory, it's pretty much arbitrary whether the
the devtree is bundled into the piece of the stack labelled
"firmware"/"bootloader", or the piece labelled "kernel", or even (as
with u-boot) yet another "device tree" section.

In practice however, it makes sense for the tree to be bundled with
the most-easily-updated section of the stack, because that way it's
easier to correct errors in it.  And usually, that means putting it
with the kernel (using the zImage wrapper).  In particular this makes
sense because the kernel is the only real user of the device tree, and
this way platform specific bugs can just be fixed in the device tree,
without needing code to deal with both broken device trees from old
firmwares and fixed device trees from newer firmwares.

> 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).

Well, "nothing but disadvantages" isn't strictly true.  In theory
boards with this arrangement which are sufficiently similar to
existing systems could run a generic kernel without any porting work.
In practice, board firmwares get things right so exceedingly rarely
that the kernel will need workarounds anyway, so it might as well just
include the device tree itself.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: Mikrotik RouterBoard 333

[Scott Wood]

Jerry Van Baren wrote:
> 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.

No, I understand what you meant -- I mean cases where u-boot expects the 
"blanks" to be somewhere other than where they are.  This has happened 
in the past, with mac-address v. local-mac-address, finding the SOC 
node, duplicate /chosen nodes, etc.

> 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).

Regardless of that, if all else fails, one can ignore the firmware's 
tree and use a bootwrapper-provided tree.

> 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).

The advantage is that the firmware will be kept in sync with the tree 
it's trying to patch.

-Scott

Re: Mikrotik RouterBoard 333

[Segher Boessenkool]

> Its firmware apparently provides a flattened device tree to the OS.
> And while this step towards world domination is flattering, it's an
> example of what I feared when people first got enthusiastic about the
> idea of including flattened device trees in firmwares.  The tree has
> not, AFAIK, been past this list, and has apparently not been reviewed
> by someone knowledgeable about device trees.  In short, it's crap, and
> now that it's embedded in the firware we can't really fix it.

Can't you build a kernel with a blob that overrides the 
firmware-provided
blob?


Segher

Re: Mikrotik RouterBoard 333

[David Gibson]

On Tue, Jul 15, 2008 at 02:17:36AM +0200, Segher Boessenkool wrote:
>> Its firmware apparently provides a flattened device tree to the OS.
>> And while this step towards world domination is flattering, it's an
>> example of what I feared when people first got enthusiastic about the
>> idea of including flattened device trees in firmwares.  The tree has
>> not, AFAIK, been past this list, and has apparently not been reviewed
>> by someone knowledgeable about device trees.  In short, it's crap, and
>> now that it's embedded in the firware we can't really fix it.
>
> Can't you build a kernel with a blob that overrides the
> firmware-provided blob?

Sorry, my phrasing was slightly unclear.  Certainly we can work around
a firmware with a crap device tree by replacing it, if necessary.
Basically that's just treating the firmware as though it's one of
these old-style jobs which provides its tiny handful of necessary bits
of information (memory size, maybe a few others) in a format that
happens to resemble a device tree.

But it seems kind of silly for firmware to go to the trouble of
providing a device tree just for us to ignore it and substitute our
own.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson