Xilinx devicetrees

[Koss, Mike (Mission Systems)]

________________________________

From: Stephen Neuendorffer [mailto:stephen.neuendorffer at xilinx.com] 
Sent: Wednesday, December 12, 2007 11:52 PM
To: Koss, Mike (Mission Systems); David H. Lynch Jr.; Grant Likely;
linuxppc-embedded
Subject: RE: Xilinx devicetrees

SN> As Grant says, the dynamic detection doesn't have to be done in the
boot loader, it could be done in the platform code.  You can largely
ignore
SN> the device trees, or always boot with a core device tree and figure
it all out later (perhaps using version registers).  I anticipate that
SN> the 'standard flow' will have standard platform code for any board
that uses a complete device tree.  If you have the need to do something
SN> extraordinary, then you should feel free to hack away...  However,
It doesn't seem to me to be really necessary in your case, assuming that

SN> the device tree is packaged (somehow, TBD) along with the bitstream.

> I don't know if packaging the device tree with the bitstream is the
best
> way to go. It's possible that it could lead to headaches for certain
> systems that have security restrictions. The same could be said for
> using it w/ the SystemACE to load it into RAM after the image. (which
is
> what I'm currently doing for my 2 linux images in lieu of a true
on-chip
> bootloader). I am already taking the security concerns into account
for
> future revisions of the hardware wrt to using a SystemACE, and am
> planning on moving the device trees into NV storage like FLASH.

SN> 'with' not 'in'. either using SystemAce, or a flash image.
 
Ah! See, I though that there was the mention of trying to put it into
the bitstream and that is what I was worried about since retrieval of
that from the bitstream file is doable but if it was being stored in the
FPGA somehow and being retrieved there (????) that could lead to
problems for some systems. 

> One solution I've been thinking through (in lieu of direct support
from
> EDK) is to use a tcl script with xps to traverse the hardware tree and
> generate the device tree. It seems like it should be relatively
trivial
> to obtain the information. It's just going to be a pain to write all
the
> handlers for each different linux driver: temac, interrupt controller,
> DMA controller, etc.
> In reality the best way to handle this would be to have EDK generate
the
> device tree as part of the library/bsp build process.
 
SN> We have a python script to do this.  The main problem with just
looking 
SN> at the mhs file is that you lose all the defaults for each IP.
Hence, we've 
SN> also written a BSP generator to do this.  both are at 
SN> git://git.xilinx.com/gen-mhs-devtree.py
SN> Once I can verify that they work in the mainline tree, I'll be
sending out 
SN> the patches that make this all work.

> Now, what I'd like
> to see with regards to this is the ability to change the handler for
the
> generating a specific device information. An example could be the
temac.
> If at some point in the future the temac needs new/more information to
> support its configuration/run-time then having to get a patch from
> Xilinx for a EDK is way too slow. The developers should be giving the
> opportunity to inject a new handler into the various parts of the
device
> tree generation. That way when the kernel patch is submitted, an EDK
> device generator patch will be submitted at the same time to keep
> everything in sync.

SN> Interesting idea..  I've been trying to figure out how to architect
this 
SN> better, but it requires some information passing within EDK that
isnot 
SN> today supported.  I don't see at all how to synchronize this with 
SN> patches to the kernel, tho.  My approach is to describe the hardware

SN> as completely and faithfully as we can (given the information in
EDK), 
SN> and let the drivers do whatever with it that they want to.

You'll have to correct if I'm wrong here, but from what I've been
reading up about EDK and its built-in Tcl interface, one can load their
system.xmp with corresponding mhs and then use Tcl to traverse the
device information to create the same information as found using the
generated BSP. This would allow for a Tcl system that could be setup
such that a main (unchanging, or slowly changing) Tcl script that would
start the EDK definition traversal and upon finding a new device it
would use a registered 'handler' Tcl function. These handlers could be
stored as seperate script/files and would be registered at the start of
the main script either via a config file or by searching a directory and
looking for tags stored at the top of the Tcl files in comments. These
driver handlers would be passed the handle to the system definition and
then know how to gather the information they need to create their entry
in the device tree. This approach gets around the issue of losing
defaults found in the mhs file.

I originally looked at trying to perform the same thing using just
device drivers in EDK, but I think I found some pitfall.  Oh, I think it
was that I would have to choose the OS for the processor and EDK wants
to build the library, but there isn't anything to compile for Linux (or
I wasn't compiling anything for the linux BSP) and that was adding extra
time to the download.bit generation and that is already a long build
process.
 
-- Mike 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20071213/bbdcf6aa/attachment-0001.htm