Xilinx devicetrees

[Stephen Neuendorffer]

> -----Original Message-----
> From: 
> linuxppc-embedded-bounces+stephen=neuendorffer.name at ozlabs.org
>  
> [mailto:linuxppc-embedded-bounces+stephen=neuendorffer.name at oz
labs.org] On Behalf Of John Williams
> Sent: Tuesday, November 27, 2007 4:53 PM
> To: Stephen Neuendorffer
> Cc: Michal Simek; linuxppc-embedded
> Subject: Re: Xilinx devicetrees
> 
> Stephen Neuendorffer wrote:
> 
> >>From: John Williams [mailto:jwilliams at itee.uq.edu.au] 
> 
> >>MicroBlaze is a highly configurable CPU in terms of its 
> >>instruction set, 
> >>features and so on.  To make use of this, it is essential that each 
> >>kernel image be compiled to match the CPU configuration.  While a 
> >>generic kernel, making use of no features (MUL, DIV, Shift, 
> >>MSR ops etc) 
> >>would run on any CPU, performance would be abysmal.
> > 
> > I think the userspace is actually much more critical than 
> the kernel for
> > most of these things (with the exception of msrset/msrclr, and the
> > barrel shifter perhaps).  Unfortunately, even if you implement an
> > alternatives-style mechanism for the kernel, you're still hosed for
> > userspace.  
> 
> I haven't benchmarks each option on the kernel - you are right that 
> shift is a big one, but mul I think is also important, given 
> that every 
> array access generates an integer multiply,

Good point.

> 
> Once I a big enough system, it's just unfeasible to
> > recompile everything anyway.  I think this is where 
> autoconfig starts to
> > break down.
> 
> I'm not sure I agree, here, given that most people building 
> MicroBlaze 
> systems are doing so with uClinux-dist (or PetaLinux), you 
> can do a full 
> rebuilt, kernel libs apps, in a couple of minutes.  Much shorter than 
> sythnesis and P&R, that's for sure (and runtime is linear in size, 
> unlike P&R :)

Let's not bash the P&R guys too much...  You try working on a problem
that is known to be insolvable, and where no matter how many people you
make happier, you'll always get bashed by the guy whose design no longer
meets timing. :)

> > It's not nice, I agree.  I think the key principle should be that I
> > should be able to get a system working as quickly as possible, and I
> > might optimize things later.  One thing that device trees 
> will allow is
> > for *all* the drivers to get compiled in to the kernel, and 
> only as a
> > late stage operation does a designer need to start throwing 
> things away.
> > Using traps I can easily start with a 'kitchen sink' 
> design, and start
> > discarding processor features, relying on the traps.  When I get low
> > enough down on the performance curve, I can uas an autoconfig-type
> > mechanism to regain a little of what I lost by optimizing 
> away the trap
> > overhead. 
> 
> OK, but now we have a kernel dependent on *3* files - a DTS, a 
> Kconfig.auto, and (indirectly) the bitstream itself.

The kernel might be generated from them, but it is not *dependent* on
them.  The same kernel can run on other hardware, with other dts's.  If
there was a traps mechanism (or alternatives), then it could also run on
other designs with different processor features.

> Another thing I suggested to Michal recently, perhaps we need 
> kernel/lib/libof to store common OF / DT handling code.  Much better 
> than duplicating it accross microblaze and PPC, and maybe 
> other arch's 
> would also see the light..  That would also add a claim for 
> the DTC to 
> go in scripts/

There's some shared code in 2.6.24-rc in drivers/of.  Now that things
are settling down in terms of bugs, I'll probably transition to pushing
a 2.6.24-rc branch soon.  However, the few brief conversations I've had
suggest that what microblaze might need or want has very little
influence until it is visible in mainline.  Once that happens, I think
it will be easy to justify putting code like libfdt and some of the
kernel of/dt code in a common place.  

So, John: would you care to make a goal (for say 2.6.25 or 26) of
working with me to get the microblaze into mainline?  I think the
community exists to keep things maintained, but I'm guessing that it
would help to have an existing LKMLer or two take a look over the code.
Given the move towards device trees, getting someone from powerpc would
seem to be natural.  Anybody interested?

Steve