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>,
	David Gibson <david@gibson.dropbear.id.au>,
	linuxppc-dev@ozlabs.org
Subject: Re: device trees.
Date: Tue, 12 May 2009 20:13:19 -0400	[thread overview]
Message-ID: <4A0A109F.7070803@dlasys.net> (raw)
In-Reply-To: <20090512232446.GB24338@yookeroo.seuss>



    Are we all using the same meaning of firmware ?

    While firmware == BIOS is the norm for PC's
     atleast in the embedded FPGA space firmware could mean the FPGA
programing that creates the hardware.
    For an FPGA based system a dtb generated by the same software that
created the "firmware" for the FPGA,
    had better match the "hardware" exactly.  Literally welding the
"firmware" to the dtb makes alot of sense.

    FPGA "firmware" is typically created with hardware programming
languages like Verilog, and VHDL.
    It is still "programmed" and like all programming quality varies.
   
David Gibson wrote:
> On Mon, May 11, 2009 at 11:22:21PM -0600, Grant Likely wrote:
>   
>> On Mon, May 11, 2009 at 7:12 PM, David Gibson
>> <david@gibson.dropbear.id.au> wrote:
>>     
>>> On Mon, May 11, 2009 at 05:09:27PM -0600, Grant Likely wrote:
>>>       
>>>> 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.
>>>       
>> I disagree.  The more I work with it, the more I appreciate the
>> advantage of decoupling the kernel image file from the hardware
>> description.  It is valuable being able to build a single image file
>> that boots on a wide range of boards because the device tree passed in
>> by firmware.
>>     
>
> Heh, where all my work in the embedded space has led me to more and
> more appreciate the fact that firmware is almost invariably crap, and
> that it's therefore best not to trust anything it tells you.
>
>   
>> I'm not downplaying the disadvantages and problems, but I still hold
>> the view that the striving for generic multiplatform kernel images is
>> worth the effort.
>>
>> ... but I do agree that hard linking the .dtb into firmware, or making
>> the .dtb hard to upgrade is the way of madness.
>>     
>
> Ah, we're talking at cross purposes a bit then.  Yeah, I'm talking
> about the situation where the dtb is part of the firmware, or at least
> as difficult / inconvenient to update as the firmware.  If the dtb is
> separate from the kernel, but as easy to update / switch as the
> kernel, that is indeed a very nice setup.
>
>   


-- 
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-13  0:20 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
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. [this message]
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=4A0A109F.7070803@dlasys.net \
    --to=dhlii@dlasys.net \
    --cc=david@gibson.dropbear.id.au \
    --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.