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
next prev 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).