<!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>
<P><FONT SIZE=2>I understand that you're trying to be somewhat of a devil's advocate here, but (as I mentioned in my other email), alot of these are issues we're attempting to tackle.<BR>
More comments below.<BR>
<BR>
-----Original Message-----<BR>
From: linuxppc-embedded-bounces+stephen=neuendorffer.name@ozlabs.org on behalf of David H. Lynch Jr.<BR>
Sent: Sun 11/25/2007 2:55 PM<BR>
To: Grant Likely; linuxppc-embedded<BR>
Subject: Re: Xilinx devicetrees<BR>
<BR>
Grant Likely wrote:<BR>
> I am not expert on this, but at Pico we already store our boot<BR>
> monitor in the .bit files in BRAM.<BR>
> But that is not free. It is one of the reasons we do not use<BR>
> u-boot. Our boot monitor must fit into 16K of BRAM.<BR>
> Must be able to perform selftests on critical hardware, support a<BR>
> flash file system, load bit files from flash to the FGA, load and<BR>
> exectute elf files, allow a small set of user commands, and handle<BR>
> hosted vs. standalone operation.<BR>
> And aparently extract the devicetree from a bit file and pass it to<BR>
> a linux kernel.<BR>
<BR>
Once you can load a bitstream from flash, loading the device tree from flash<BR>
should be practically free. In any event, why do you do this rather than just run out of the flash (or a ram copy of the flash?)<BR>
<BR>
> In static or fairly static hardware, that's fine. Even in somewhat<BR>
> dynamic hardware with large quantities of startup resources - like a PC.<BR>
> But in highly dynamic hardware with fairly limited resources it<BR>
> starts to become an issue.<BR>
<BR>
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 the device trees, or always boot with a core device tree and figure it all out later (perhaps using version registers). I anticipate that 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 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 the device tree is packaged (somehow, TBD) along with the bitstream.<BR>
<BR>
>> No, unfortunately they don't deal with the problem you're facing<BR>
>> (which I'm facing also). But it will be solved if we figure out a<BR>
>> sane way to bind the device tree up with the FPGA bitstream without<BR>
>> consuming FPGA resources.<BR>
>> <BR>
> Note to Xilinx:<BR>
><BR>
> There MUST be some way of binding a device description to a bit file.<BR>
><BR>
> neither building it into the FPGA fabric nor appending it to the end<BR>
> of the bit file are perfect solutions,<BR>
> The former is more powerfull and flexible but wastes precious<BR>
> resources. The later is more complex and puts more burdens on<BR>
> software developers, and may be completely unfeasible in some<BR>
> environments - not mine fortunately.<BR>
<BR>
I don't understand the 'burden on software developers'. The code to do this will just be standard code. The worst that one can say is:<BR>
1) I need several KB additional non volatile storage. Given the size of the FPGA bitstream, this can't be a huge constraint.<BR>
2) I can't use compile time optimization based on xparameters as easily. Anyone want to implement the alternatives mechanism on ppc and microblaze?<BR>
3) Some additional boot time. However, again, this seems marginal.<BR>
<BR>
> Regardless, something must be done. An odd collection of devicetree<BR>
> files co-mingled with a collection of bit files, is little better than<BR>
> xparameter files all over the place.<BR>
<BR>
Certainly.. But in a sense, these are all intermediate files on the path to the image on the board. That (and how it is interpreted by the platform code) should be generated in a consistent fashion by EDK. See my other email for some of the possibilities. Are there specific reasons why you think those proposals are inadequate? Now is the time when we can take criticism, with the goal towards making a good end solution.<BR>
<BR>
> And once again a plea to ALWAYS make version/capabilities registers<BR>
> atleast an optional part of every design.<BR>
> Embeddeding a device tree into a design might be fairly expensive. a<BR>
> pair of read only 32 bit registers is damn near free - basically the<BR>
> FPGA equivalent of atmost 64 diodes or resistors.<BR>
<BR>
Actually, device trees actually seem to be cheaper (in the whole system sense) than such registers. Unless there is something I don't understand?<BR>
<BR>
Steve<BR>
</FONT>
</P>
</BODY>
</HTML>