Device Tree tool [was RE: [PATCH] Consolidate XILINX_VIRTEXboardsupport]

[Grant Likely]

On 8/14/07, Stephen Neuendorffer <stephen.neuendorffer at 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 at secretlab.ca
(403) 399-0195