All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David H. Lynch Jr." <dhlii@dlasys.net>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: device trees.
Date: Mon, 11 May 2009 12:45:06 -0400	[thread overview]
Message-ID: <4A085612.9050602@dlasys.net> (raw)
In-Reply-To: <fa686aa40905110651r1c18b78bpe8ffebe041726695@mail.gmail.com>

Grant Likely wrote:
>   
>>    We are very actively headed in the opposite direction. It is my/our
>> intention to have a single linux executable that works accross
>>    everyone of our cards and everyone of our bitfiles.
>>     
>
> That is the direction we are already going in.  U-Boot supports this.
> In fact, I can build a single kernel image which will boot on all of
> my MPC5200 boards, and my MPC83xx boards.  Similarly, if I have u-boot
> running on a Virtex board, I can build a single image which will boot
> all of them if the correct .dtb is passed to it.
>   
    I was not aware that u-boot was currently doing that, but I was
aware that was possible.
    It is the most useful alternative to simple image.
    I was not specifically trying to criticize simple image.
    My problem is not with specific means of handling device trees.
    It is that it is a one size fits all solution, and it is not
sufficiently flexible for that.


> You *could* generate the device tree dynamically, but I think that is
> a path of diminishing returns considering that generating a .dts at
> the same time as bitstream creation time is cheap and it is small.  At
> one time Steven Neuendorffer was playing with a scheme to preload a
> section of BRAM with a gzipped .dtb so that the correct device tree is
> always present.  I really liked the idea, and I'd like to try to
> pursue it.
>   
    I would prefer not to waste bram by filling it with a device tree.
    The best alternative to creating the device tree dynamically would
be to
    append the devicetree to the bitimage in a way the boot loader could
always find it.

    But ultimately the problem still exists.

    Device trees are the ONLY legitimate way to pass information post
2.6.26.
    That means that if there is a single peice of dynamic information
that needs to be passed to linux,
    at a minimum the device tree must be edited.
    It is my understanding that u-boot already does some of this to
manage command lines, and maybe a few other items.

    Regardless it still makes my point.  The problem with devicetrees as
they are is that they handle probably 98% of all cases well.
    The remaining 2% are a mess.

    lots of .dtb files lying arround is only a better solution than
simpleimage.
    I will guarantee that unless they are welded together the wrong
device tree will get used with the wrong bit file.
    Inevitably I will make that mistake myself occasionally and waste
hours or possibly days trying to debug it.
    And if I will do it rarely clients will do it frequently.

    In my expereince if you create a situation where confusion can exist
it will.

    It is also my expereince that time spend coding a solution to a
common client problem is well spent.
    If it takes me a week to work out dynamically creating a device
tree, that ill likely save many weeks of
    support headaches.

    Even if I do not end up creating the device tree dynamically, I am
likely to end up at a minimum doing some validation on it.
    i.e. once the bitfile is loaded scanning the device tree and probing
to ascertain that the hardware that I am supposed to expect
    it really present.

    ultimately devicetrees are supposed to be a database not a black box.

    Anyway, all I was looking for was a leg up on figuring out how to do
what I want with them. Rather than starting from scratch.
    I am not looking to be convinced that I am approaching this all wrong.
    If you are happy with what you have - great. I am not.
    While I was not looking to restart a great debate over device trees
- I do not actually think they are a bad idea.
   

> g.
>
>   


-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii@dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein

  parent reply	other threads:[~2009-05-11 16:51 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. [this message]
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
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=4A085612.9050602@dlasys.net \
    --to=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.