Xilinx devicetrees

[Stephen Neuendorffer]

> -----Original Message-----
> From: Koss, Mike (Mission Systems) [mailto:mike.koss at ngc.com] 
> Sent: Thursday, December 13, 2007 5:49 AM
> To: Stephen Neuendorffer; David H. Lynch Jr.; Grant Likely; 
> linuxppc-embedded
> Subject: RE: Xilinx devicetrees
> 
> 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.

This seems like alot of work, for relatively little benefit.  :)
Instead, I think it is safer to just describe the IP as completely as we
can up front.  Everything else should be done by the Linux driver.  Now
today there is a problem, which is that there isn't a standard way of
having a device describe itself, in the format of a device tree.  This
is something that we'll likely have to add hooks for in the future.

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

I can't imagine that generating this file is the bottleneck in getting
to a bitstream (or at least, I really hope it isn't!) 

Steve