From: Jerry Van Baren <gvb.linuxppc.dev@gmail.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: Mikrotik RouterBoard 333
Date: Sun, 13 Jul 2008 20:44:46 -0400 [thread overview]
Message-ID: <487AA17E.6000808@gmail.com> (raw)
In-Reply-To: <20080709040925.GA13810@secretlab.ca>
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
next prev parent reply other threads:[~2008-07-14 0:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-08 4:26 Mikrotik RouterBoard 333 David Gibson
2008-07-09 4:09 ` Grant Likely
2008-07-14 0:44 ` Jerry Van Baren [this message]
2008-07-21 21:13 ` Scott Wood
2008-07-21 22:13 ` Segher Boessenkool
2008-07-22 2:54 ` Jerry Van Baren
2008-07-22 3:48 ` David Gibson
2008-07-22 14:56 ` Scott Wood
2008-07-15 0:17 ` Segher Boessenkool
2008-07-15 1:41 ` David Gibson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=487AA17E.6000808@gmail.com \
--to=gvb.linuxppc.dev@gmail.com \
--cc=grant.likely@secretlab.ca \
--cc=linuxppc-dev@ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).