<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7652.24">
<TITLE>RE: Xilinx devicetrees</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>
<BR>
<BR>
<P><FONT SIZE=2>-----Original Message-----<BR>
From: Koss, Mike (Mission Systems) [<A HREF="mailto:mike.koss@ngc.com">mailto:mike.koss@ngc.com</A>]<BR>
Sent: Mon 11/26/2007 7:31 AM<BR>
To: Stephen Neuendorffer; David H. Lynch Jr.; Grant Likely; linuxppc-embedded<BR>
Subject: RE: Xilinx devicetrees<BR>
<BR>
Time for my $.02, since I am heavily weighting my future designs on the<BR>
use of the device trees. :) (and b/c I don't check my work e-mail from<BR>
home ;P)<BR>
<BR>
________________________________<BR>
<BR>
<BR>
SN> As Grant says, the dynamic detection doesn't have to be done in the<BR>
boot loader, it could be done in the platform code. You can largely<BR>
ignore<BR>
SN> the device trees, or always boot with a core device tree and figure<BR>
it all out later (perhaps using version registers). I anticipate that<BR>
SN> the 'standard flow' will have standard platform code for any board<BR>
that uses a complete device tree. If you have the need to do something<BR>
SN> extraordinary, then you should feel free to hack away... However,<BR>
It doesn't seem to me to be really necessary in your case, assuming that<BR>
<BR>
SN> the device tree is packaged (somehow, TBD) along with the bitstream.<BR>
<BR>
> I don't know if packaging the device tree with the bitstream is the best<BR>
> way to go. It's possible that it could lead to headaches for certain<BR>
> systems that have security restrictions. The same could be said for<BR>
> using it w/ the SystemACE to load it into RAM after the image. (which is<BR>
> what I'm currently doing for my 2 linux images in lieu of a true on-chip<BR>
> bootloader). I am already taking the security concerns into account for<BR>
> future revisions of the hardware wrt to using a SystemACE, and am<BR>
> planning on moving the device trees into NV storage like FLASH.<BR>
<BR>
'with' not 'in'. either using SystemAce, or a flash image.<BR>
<BR>
> One solution I've been thinking through (in lieu of direct support from<BR>
> EDK) is to use a tcl script with xps to traverse the hardware tree and<BR>
> generate the device tree. It seems like it should be relatively trivial<BR>
> to obtain the information. It's just going to be a pain to write all the<BR>
> handlers for each different linux driver: temac, interrupt controller,<BR>
> DMA controller, etc.<BR>
> In reality the best way to handle this would be to have EDK generate the<BR>
> device tree as part of the library/bsp build process.<BR>
We have a python script to do this. The main problem with just looking at the mhs file is that you lose all the defaults for each IP. Hence, we've also written a BSP generator to do this. both are at git://git.xilinx.com/gen-mhs-devtree.py<BR>
Once I can verify that they work in the mainline tree, I'll be sending out the patches that make this all work.<BR>
<BR>
> Now, what I'd like<BR>
> to see with regards to this is the ability to change the handler for the<BR>
> generating a specific device information. An example could be the temac.<BR>
> If at some point in the future the temac needs new/more information to<BR>
> support its configuration/run-time then having to get a patch from<BR>
> Xilinx for a EDK is way too slow. The developers should be giving the<BR>
> opportunity to inject a new handler into the various parts of the device<BR>
> tree generation. That way when the kernel patch is submitted, an EDK<BR>
> device generator patch will be submitted at the same time to keep<BR>
> everything in sync.<BR>
<BR>
Interesting idea.. I've been trying to figure out how to architect this better, but it requires some information passing within EDK that isnot today supported. I don't see at all how to synchronize this with patches to the kernel, tho. My approach is to describe the hardware as completely and faithfully as we can (given the information in EDK), and let the drivers do whatever with it that they want to.<BR>
<BR>
Steve<BR>
<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>