Xilinx devicetrees

[John Williams]

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,

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 :)

> 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.

> Personally, I think the easiest way out of all this is to just have less
> configurability.  For microblaze in general, this is too much of a
> restriction, but microblaze used as a control processor running linux,
> there are probably just a few design points that really make sense
> (probably size optimized: no options except maybe msrset/msrclr, and the
> kitchen sink).  If we go that far, we don't really need people to ever
> run autoconfig, or kernels, or anything.  Especially considering there
> is no easy way of selecting which of the 2^N design points I want
> *anyway*. :)

My experience tells me that if the microblaze can be configured in a 
particular way, *someone* will want to do it (and still boot linux on 
it!)  We still have people building MicroBlaze 3.00 in Spartan2E, with 
EDK 6.3.  And autoconfig works!  Exceptions on/off, MMU on/off (runtime 
configurable on that?).

Our ability to plug into the backend design database of EDK presents a 
great opportunity - truly automatically configured kernels.  I think we 
have a responsibility to leverage that power.    We are already there 
with the static approach, I think we just need to make sure that 
persists into the dynamic approach, and that we find a good mix of the two.

There are of course some semantic issues that the EDK cannot 
automatically resolve - relative ordering and priority of multiple 
peripheral instances for example.

>>One compromise approach might be to have a script in 
>>arch/microblaze/scripts, called by the arch Makefile, that 
>>cracks open 
>>the DT at build time and extracts appropriate cpu flags.
> 
> Hmm... interesting idea, although parsing the source is likely
> difficult...  It's probably not worth it to go this far, I think.   As
> you say, why doesn't autoconfig of today work fine for this.

Well, copying multiple configuration files into the kernel is not ideal. 
  Surely a little perl or python script would do the trick?  DTS syntax 
is pretty clean, just find the CPU node and off we go.  Multiple CPU, 
well... :)

>>Finally, what is the LKML position on DT files going into the kernel 
>>source tree?
> 
> 
> Source .dts go in and get compiled to binary blobs at compile time.  The
> 'big' recent controversy is whether the source->binary compiler dtc
> should be mirrored in the Linux tree or not.

OK.

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/

John