> -----Original Message----- > From: Koss, Mike (Mission Systems) [mailto:[EMAIL PROTECTED] > 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 _______________________________________________ Linuxppc-embedded mailing list [email protected] https://ozlabs.org/mailman/listinfo/linuxppc-embedded
