________________________________ From: Stephen Neuendorffer [mailto:[EMAIL PROTECTED] 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
_______________________________________________ Linuxppc-embedded mailing list [email protected] https://ozlabs.org/mailman/listinfo/linuxppc-embedded
