All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.