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

On Mon, May 11, 2009 at 12:32 AM, David H. Lynch Jr. <dhlii@dlasys.net> wro=
te:
> =A0 =A0But partial reconfiguration is not the only way to encounter a
> dynamic environment.
> =A0 =A0A typical pico system has multiple bit files and multiple
> executables stored in its flash file system.
> =A0 =A0Power up and soft resets might each run through a different sequen=
ce
> of bit files and executables.
>
> =A0 =A0My issue is that post 2.6.26 unless I can dynamically create the
> device tree inside our monitor/bootloader
> =A0 =A0we must at minimum have a different device tree for each bitfile,

This is true

> or worse if we wrap the device tree into the executable,
>    a different linux executable for each bit file.

As you say, this is undesirable.  simpleImage does this, but it it
intended for the least common denominator case where there is no
firmware support at all available and the kernel needs to be
completely contained.  simpleImage is not intended to be the ideal.

> =A0 =A0We are very actively headed in the opposite direction. It is my/ou=
r
> intention to have a single linux executable that works accross
> =A0 =A0everyone 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.

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.

g.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

  reply	other threads:[~2009-05-11 13: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 [this message]
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.
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=fa686aa40905110651r1c18b78bpe8ffebe041726695@mail.gmail.com \
    --to=grant.likely@secretlab.ca \
    --cc=dhlii@dlasys.net \
    --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.