linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "Grant Likely" <grant.likely@secretlab.ca>
To: "Stephen Neuendorffer" <stephen.neuendorffer@xilinx.com>
Cc: microblaze-uclinux@itee.uq.edu.au, linuxppc-embedded@ozlabs.org
Subject: Re: Device Tree tool [was RE: [PATCH] Consolidate XILINX_VIRTEXboardsupport]
Date: Wed, 15 Aug 2007 08:03:57 -0600	[thread overview]
Message-ID: <fa686aa40708150703h375cc250uc9ec447574c91d1d@mail.gmail.com> (raw)
In-Reply-To: <20070814215438.3C7AA1B7006C@mail148-cpk.bigfish.com>

On 8/14/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
>
> > BTW: I'm currently hacking away to see if I can get a
> > microblaze system
> > booting
> > using a flat device tree...  I haven't decided if it's worth it to go
> > that
> > route in the end yet, but...
> >
> > Steve
>
> I've managed to get the first step working: a microblaze system
> advertising of_devices in 2.6 using a flat device tree.  The next task
> is to
> reimplement probe() for a driver or two (probably the xilinx_emac driver
> first).   My plan is to have the driver advertise both through
> of_platform_bus, and
> through the regular platform bus, and have a config option that either
> advertises
> the devices through of and links in the device tree, or using the
> exising
> platform_device mechanism.

That's fantastic.  Yes, I think that is the right approach to have
both platform_bus and of_platform bus bindings in the drivers.

>
> Grant:  Does this make sense (in terms of dealing with drivers) with
> your plans for
> moving Virtex platforms to arch/powerpc?  I'd like to avoid duplicating
> work on the
> drivers, if possible.

Absolutely

>
> Is there a concensus on how microblaze systems should get booted?
> Currently,
> I'm linking the device tree directly into the kernel itself, loading the
> whole
> mess using SystemAce and the start address jumps directly into the
> kernel, which
> is quite a bit different than the way powerpc works.  It's certainly
> simpler:
> maybe too simple.  At the same time, replicating
> the complexity of arch/powerpc with separate boot code may or may not be
> worth it...
> Any thoughts?

It is a good starting point, and I think it is important that this
remain an option (ie. for boards without a bootloader).  However, it
is a really good idea to support the notion of passing in a device
tree from a bootloader (u-boot).  As Michal mentioned, u-boot already
has the code to support this, and u-boot is able to update the device
tree directly.  The key feature here is being able to support multiple
FPGA designs from a single kernel image because the device tree gives
us some level of abstraction on the hardware design.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

  parent reply	other threads:[~2007-08-15 14:04 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-06 22:57 [PATCH] Consolidate XILINX_VIRTEX board support Wolfgang Reissnegger
2007-08-06 23:24 ` Arnd Bergmann
2007-08-06 23:36   ` Stephen Neuendorffer
2007-08-06 23:41     ` Grant Likely
2007-08-09 18:54   ` Grant Likely
2007-08-10 12:22     ` Device Tree tool [was RE: [PATCH] Consolidate XILINX_VIRTEX board support] Koss, Mike (Mission Systems)
2007-08-10 13:48       ` Grant Likely
2007-08-10 15:36         ` Device Tree tool [was RE: [PATCH] Consolidate XILINX_VIRTEX boardsupport] Stephen Neuendorffer
2007-08-14 21:54           ` Device Tree tool [was RE: [PATCH] Consolidate XILINX_VIRTEXboardsupport] Stephen Neuendorffer
2007-08-15  6:41             ` Michal Simek
2007-08-15 16:14               ` Stephen Neuendorffer
2007-08-15 14:03             ` Grant Likely [this message]
2007-08-10 14:37     ` [PATCH] Consolidate XILINX_VIRTEX board support Kumar Gala
2007-08-11  4:35       ` Grant Likely
2007-08-07  7:01 ` Peter Korsgaard
2007-08-07  7:17 ` Peter Korsgaard
2007-08-09 18:57   ` Grant Likely
2007-08-10  7:17     ` Peter Korsgaard
2007-08-10 14:28       ` Grant Likely
2007-08-19  1:34   ` David H. Lynch Jr.
2007-08-19  1:57     ` Josh Boyer
2007-08-23  6:43       ` David H. Lynch Jr.
2007-08-09 18:42 ` Grant Likely
2007-08-11  4:37   ` Grant Likely
2007-08-14  2:47     ` Best Linux tree for Xilinx support Leonid
2007-08-14  5:07       ` Wolfgang Reissnegger
2007-08-14 17:28         ` Leonid
2007-08-14 17:53           ` Grant Likely
2007-08-14 20:43           ` Wolfgang Reissnegger
2007-08-14 20:47             ` Leonid
2007-08-19  1:29           ` David H. Lynch Jr.

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=fa686aa40708150703h375cc250uc9ec447574c91d1d@mail.gmail.com \
    --to=grant.likely@secretlab.ca \
    --cc=linuxppc-embedded@ozlabs.org \
    --cc=microblaze-uclinux@itee.uq.edu.au \
    --cc=stephen.neuendorffer@xilinx.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).