All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David H. Lynch Jr." <dhlii@dlasys.net>
To: linuxppc-embedded <linuxppc-embedded@ozlabs.org>
Subject: Xilinx devicetrees
Date: Sat, 24 Nov 2007 06:37:20 -0500	[thread overview]
Message-ID: <47480CF0.7090105@dlasys.net> (raw)

    I am following developments regarding device trees for xilinx boards
both here and on the microblaze list.

    I am trying to get a grasp on what they will really do for me and
what using them will demand.

    Please correct any misperceptions:

     As I understand it devicetrees are basically just a tree structured
binary  database describing the hardware.
    They have some heritage in OpenFirmware.
    There are tools to convert  some human readable representations into
the binary form.
    There appear to be tools to take xilinx firmware projects and create
a devicetree database from it
    A BSP using devicetree's configures its hardware, drivers etc, by
querying the devicetree database.  
    It it possible to pass the device tree database independent of the
kernel itself some what similar to the way many bootloaders pass initrd
filesystems.
   
    So in the end I write a BSP that could support a wide variety of
hardware and compile a single kernel that could be passed different
devicetree databases representing different xilinx firmware, and still
hope to work.
    But in return for making the BSP more generic (sort of), I now have
to somehow get the correct devicetree database passed for each different
firmware set that I load.

    I am having some difficulty grasping the significant advantages to
this.
    If the firmware for a given target is not fairly static - and I load
different firmware depending on what I am doing all the time, then I
know have to manage both a bit file for the firmware, and a devicetree
file describing it to the kernel.
    Currently for base hardware we maintain as much design consistancy
as possible accross all our different cards/firmware.
    particular hardware/firmware blocks/IP's may or may not be present -
but if present they are always the same - the Same Uartlite at the same
location, on the same irq, same for PIC's, TEMAC's ...
    For the most part it makes the most sense for us to use code to
detect the presence/absence of specific baseline hardware and then to
load non-base custom drivers after boot.

    What am  missing about devicetrees that would make me more
interested in them ?
      
  




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

             reply	other threads:[~2007-11-24 11:39 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-24 11:37 David H. Lynch Jr. [this message]
2007-11-24 17:12 ` Xilinx devicetrees Grant Likely
2007-11-25  5:24   ` Stephen Neuendorffer
2007-11-25  9:37     ` David H. Lynch Jr.
2007-11-25 18:15       ` Stephen Neuendorffer
2007-11-27 23:55         ` John Williams
2007-11-28  0:27           ` Grant Likely
2007-11-28  0:28           ` Stephen Neuendorffer
2007-11-28  0:52             ` John Williams
2007-11-28 14:33               ` Jon Loeliger
2007-11-28 17:28               ` Stephen Neuendorffer
2007-11-28 18:12                 ` Grant Likely
2007-11-29 10:56               ` David H. Lynch Jr.
2007-11-25  9:15   ` David H. Lynch Jr.
2007-11-25 22:21     ` Grant Likely
2007-11-25 22:55       ` David H. Lynch Jr.
2007-11-25 23:58         ` Stephen Neuendorffer
2007-11-26 21:36           ` David H. Lynch Jr.
2007-12-13  2:40           ` Koss, Mike (Mission Systems)
2007-11-26 16:30             ` Grant Likely
2007-11-26 20:28               ` David H. Lynch Jr.
2007-11-26 21:16             ` David H. Lynch Jr.
2007-11-26 21:55               ` Stephen Neuendorffer
2007-11-26 22:09                 ` Grant Likely
2007-11-26 22:19               ` Koss, Mike (Mission Systems)
2007-12-13  4:52             ` Stephen Neuendorffer
2007-12-13 13:49               ` Koss, Mike (Mission Systems)
2007-12-13 17:36                 ` Stephen Neuendorffer

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=47480CF0.7090105@dlasys.net \
    --to=dhlii@dlasys.net \
    --cc=linuxppc-embedded@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.