All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: linuxppc-dev@ozlabs.org, "David H. Lynch Jr." <dhlii@dlasys.net>
Subject: Re: device trees.
Date: Tue, 12 May 2009 11:12:19 +1000	[thread overview]
Message-ID: <20090512011219.GB18223@yookeroo.seuss> (raw)
In-Reply-To: <fa686aa40905111609l3feaf555taadf048714030a1@mail.gmail.com>

On Mon, May 11, 2009 at 05:09:27PM -0600, Grant Likely wrote:
> On Mon, May 11, 2009 at 3:38 PM, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
> > Grant Likely wrote:
> >>
> >> What do you mean by "one size fits all solution?"
> >>
> >> The kernel doesn't care where the device tree comes from.  All it
> >> cares about is that by the time the kernel is started the device tree
> >> must be fully formed and populated.  It can be completely pre-canned
> >> (like simpleImage), it can be modified by firmware (like u-boot), or
> >> it can be generated from scratch (like with real OpenFirmware).  There
> >> is lots of flexibility on how to handle it.
> >>
> >>
> > First device trees are now the ONLY means of  passing information to the
> > kernel.
> > By definition that means it is a one size fits all solution.
> > While there is nothing inherently wrong with that, solutions intended to
> > meet all circumstances need to be
> > simple, powerful, and flexible. They need to work well 100% of the time
> > not 98%.
> >
> > Not only is the device tree expected to pass static hardware
> > configuration information, but it is the sole means of passing anything.
> > As an example Command lines are to be in the device tree.
> > Everything is supposed to be in the device tree, whether that
> > information is static or dynamic, whether it is hardware information,
> > or user choices.
> 
> It is the sole means of passing anything *to the kernel*.  You can
> pass whatever you like to the bootwrapper.  :-)
> 
> >    That means that whether you are in a Sun or Apple Desktop or a
> > system with the no flash and barely enough resources to run Linux,
> > you still may have to manipulate the device tree.
> 
> ...or if you really are constrained, then define a format for the data
> you want to pass, pass it to the bootwrapper along with the device
> tree, and use the bootwrapper (which already has libfdt) to update the
> device tree.  cuImage targets do this to support older u-boots which
> don't understand device trees.  You are not forced to put device tree
> support in your firmware.
> 
> In other words; having your bootloader support FDT is preferred, but
> not required.

I wouldn't even go so far as to say it's preferred.  IMO, people have
gone a bit prematurely keen on moving devtree handling into the
firmware.  Putting it in the firmware has a number of advantages, but
it also has a number of non-trivial disadvantages.

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

  reply	other threads:[~2009-05-12  1:12 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-08 16:03 device trees David H. Lynch Jr.
2009-05-08 17:15 ` Timur Tabi
2009-05-08 18:43 ` Kumar Gala
2009-05-09 20:51 ` Grant Likely
2009-05-11  2:00   ` Michael Ellerman
2009-05-11  4:08     ` Grant Likely
2009-05-11  6:32       ` David H. Lynch Jr.
2009-05-11 13:51         ` Grant Likely
2009-05-11 15:52           ` Stephen Neuendorffer
2009-05-11 16:58             ` David H. Lynch Jr.
     [not found]               ` <20090511183638.F07C01438054@mail184-wa4.bigfish.com>
     [not found]                 ` <4A08C599.2030100@dlasys.net>
     [not found]                   ` <20090512005554.EEE1019D009B@mail129-dub.bigfish.com>
2009-05-12  2:34                     ` David H. Lynch Jr.
2009-05-12  4:27                       ` Stephen Neuendorffer
2009-05-12  5:30                         ` Grant Likely
2009-05-13  0:10                           ` Stephen Neuendorffer
2009-05-13  2:36                             ` David Gibson
2009-05-13  4:03                               ` Grant Likely
2009-05-13  6:11                               ` David H. Lynch Jr.
2009-05-13  6:21                                 ` David Gibson
2009-05-13 18:11                                   ` David H. Lynch Jr.
2009-05-14  3:08                                     ` David Gibson
2009-05-14 12:51                                       ` David H. Lynch Jr.
2009-05-13  6:58                                 ` Stephen Neuendorffer
2009-05-11 16:45           ` David H. Lynch Jr.
2009-05-11 17:47             ` Grant Likely
2009-05-11 21:38               ` David H. Lynch Jr.
2009-05-11 22:29                 ` Benjamin Herrenschmidt
2009-05-11 22:56                 ` David Gibson
2009-05-12  2:37                   ` Michael Ellerman
2009-05-11 23:09                 ` Grant Likely
2009-05-12  1:12                   ` David Gibson [this message]
2009-05-12  5:22                     ` Grant Likely
2009-05-12 23:24                       ` David Gibson
2009-05-13  0:01                         ` Grant Likely
2009-05-13  0:13                         ` David H. Lynch Jr.
2009-05-13  1:15                           ` Grant Likely
2009-05-13  2:32                           ` David Gibson
2009-05-11 23:19                 ` Stephen Neuendorffer
2009-05-12  0:04                   ` Grant Likely
2009-05-12  7:38                     ` Wolfram Sang
2009-05-11 14:58         ` Timur Tabi
2009-05-11 16:54           ` David H. Lynch Jr.
2009-05-11 23:27             ` David Gibson
2009-05-11 22:25       ` Benjamin Herrenschmidt
     [not found] <20110703222042.19386c7wy7zfn4g8@webmail.huji.ac.il>
     [not found] ` <20110703222042.19386c7wy7zfn4g8-2RFepEojUI0+8gVPFGsyePqBs+8SCbDb@public.gmane.org>
2011-07-03 21:01   ` Device Trees Grant Likely

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=20090512011219.GB18223@yookeroo.seuss \
    --to=david@gibson.dropbear.id.au \
    --cc=dhlii@dlasys.net \
    --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.