<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: Xilinx devicetrees</TITLE>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.3199" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=745091714-26112007><FONT face=Arial
color=#0000ff size=2>Time for my $.02, since I am heavily weighting my future
designs on the use of the device trees. :) (and b/c I don't check my work e-mail
from home ;P)</FONT></SPAN></DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
</DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT face=Tahoma
size=2><B>From:</B> Stephen Neuendorffer
[mailto:stephen.neuendorffer@xilinx.com] <BR><B>Sent:</B> Sunday, November 25,
2007 6:59 PM<BR><B>To:</B> David H. Lynch Jr.; Grant Likely;
linuxppc-embedded<BR><B>Subject:</B> RE: Xilinx devicetrees<BR></FONT><FONT
size=2><BR><SPAN class=745091714-26112007>DL</SPAN>> I am
not expert on this, but at Pico we already store our boot<SPAN
class=745091714-26112007> </SPAN>monitor in the .bit files in
BRAM.<BR><SPAN class=745091714-26112007>DL</SPAN>>
But that is not free. It is one of the reasons we do not use u-boot.
Our boot monitor must fit into 16K of BRAM.<BR><SPAN
class=745091714-26112007>DL</SPAN>> Must be able to
perform selftests on critical hardware, support a flash file system, load
bit files from flash to the FGA, load and exectute elf files, allow a small
set of user commands, <BR><SPAN
class=745091714-26112007>DL> </SPAN>and handle hosted vs.
standalone operation.<BR><SPAN
class=745091714-26112007>DL</SPAN>> And aparently
extract the devicetree from a bit file and pass it to a linux
kernel.<BR><BR><SPAN class=745091714-26112007>SN> </SPAN>Once you can
load a bitstream from flash, loading the device tree from flash<BR><SPAN
class=745091714-26112007>SN> </SPAN>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><SPAN class=745091714-26112007> </SPAN><BR><SPAN
class=745091714-26112007>This is the approach that I am currently taking with
our future design. In our system, we actually have 2 physical systems running
Linux inside the V4 (that's why there are 2 PowerPCs :) ). My
current plan would be to have the device trees stored in FLASH along w/ a single
linux image. Our bootloader on the board would then copy that information from
FLASH to RAM for both systems. This allows us to have two physically different
systems setup with different hardware, but have one linux image with two
different device trees. With a standard linux kernel weighing it at ~ 3-5MB
(including initramfs) that's a hefty savings in FLASH for us. Plus it can
considerably lower boot time instead of having to verify multiple large
images.</SPAN><BR><BR><SPAN class=745091714-26112007>DL</SPAN>> In
static or fairly static hardware, that's fine. Even in somewhat<SPAN
class=745091714-26112007> </SPAN>dynamic hardware with large quantities of
startup resources - like a PC.<BR><SPAN
class=745091714-26112007>DL</SPAN>> But in highly dynamic hardware with
fairly limited resources it<SPAN class=745091714-26112007> </SPAN>starts to
become an issue.<BR><BR><SPAN class=745091714-26112007>SN> </SPAN>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 <BR><SPAN
class=745091714-26112007>SN> </SPAN>the device trees, or always boot with a
core device tree and figure it all out later (perhaps using version
registers). I anticipate that <BR><SPAN class=745091714-26112007>SN>
</SPAN>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
<BR><SPAN class=745091714-26112007>SN> </SPAN>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 <BR><SPAN class=745091714-26112007>SN>
</SPAN>the device tree is packaged (somehow, TBD) along with the
bitstream.<BR><SPAN class=745091714-26112007> </SPAN><BR><SPAN
class=745091714-26112007>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.</SPAN><BR><BR><SPAN
class=745091714-26112007>GL</SPAN>> No, unfortunately they don't deal with
the problem you're facing<BR><SPAN class=745091714-26112007>GL</SPAN>> (which
I'm facing also). But it will be solved if we figure out a<BR><SPAN
class=745091714-26112007>GL</SPAN>> sane way to bind the device tree up with
the FPGA bitstream without<BR><SPAN class=745091714-26112007>GL</SPAN>>
consuming FPGA resources.<BR> <BR><SPAN
class=745091714-26112007>DL</SPAN>> Note to
Xilinx:<BR><SPAN
class=745091714-26112007>DL</SPAN>> There
MUST be some way of binding a device description to a bit file.<BR><SPAN
class=745091714-26112007>DL</SPAN>> neither building it
into the FPGA fabric nor appending it to the end<BR><SPAN
class=745091714-26112007>DL</SPAN>> of the bit file are perfect
solutions,<BR><SPAN class=745091714-26112007>DL</SPAN>> The
former is more powerfull and flexible but wastes precious<BR><SPAN
class=745091714-26112007>DL</SPAN>> resources. The later is more complex and
puts more burdens on<BR><SPAN
class=745091714-26112007>DL</SPAN>> software developers,
and may be completely unfeasible in some<BR><SPAN
class=745091714-26112007>DL</SPAN>> environments - not mine
fortunately.<BR><BR><SPAN class=745091714-26112007>SN> </SPAN>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><SPAN
class=745091714-26112007>SN> </SPAN>1) I need several KB additional non
volatile storage. Given the size of the FPGA bitstream, this can't be a
huge constraint.<BR><SPAN class=745091714-26112007>SN> </SPAN>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><SPAN
class=745091714-26112007>SN> </SPAN>3) Some additional boot time.
However, again, this seems marginal.<BR><SPAN
class=745091714-26112007> </SPAN><BR><SPAN class=745091714-26112007>I do
agree that using more FPGA resources is not a solution to the problem. I'm
already hitting 80% usage on a FX60 and trying to squeeze more real estate
for storage of the device tree seems silly. Especially since that would require
that every image have this extra hardware built into it just to support booting
a Linux kernel. Why should I have to have different hardware to boot linux,
versus non-kernel, xilkernel, or other (GHS, LynxOS, etc..)?</SPAN><BR><BR><SPAN
class=745091714-26112007>DL</SPAN>> Regardless, something
must be done. An odd collection of devicetree<BR><SPAN
class=745091714-26112007>DL</SPAN>> files co-mingled with a collection of bit
files, is little better than<BR><SPAN class=745091714-26112007>DL</SPAN>>
xparameter files all over the place.<BR><BR><SPAN
class=745091714-26112007>SN> </SPAN>Certainly.. But in a sense, these
are all intermediate files on the path to the image on the board. That
<BR><SPAN class=745091714-26112007>SN> </SPAN>(and how it is interpreted by
the platform code) should be generated in a consistent fashion by EDK.
<BR><SPAN class=745091714-26112007>SN> </SPAN>See my other email for some of
the possibilities. Are there specific reasons why you think those
<BR><SPAN class=745091714-26112007>SN> </SPAN>proposals are inadequate?
Now is the time when we can take criticism, with the goal towards making
<BR><SPAN class=745091714-26112007>SN> </SPAN>a good end solution.<BR><SPAN
class=745091714-26112007> </SPAN><BR><SPAN class=745091714-26112007>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.</SPAN></FONT></DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><SPAN
class=745091714-26112007></SPAN><BR><FONT size=2><SPAN
class=745091714-26112007>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. 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.</SPAN><BR><BR><SPAN
class=745091714-26112007>DL</SPAN>> And once again a plea
to ALWAYS make version/capabilities registers<BR><SPAN
class=745091714-26112007>DL</SPAN>> atleast an optional part of every
design.<BR><SPAN class=745091714-26112007>DL</SPAN>>
Embeddeding a device tree into a design might be fairly expensive. a<BR><SPAN
class=745091714-26112007>DL</SPAN>> pair of read only 32 bit registers is
damn near free - basically the<BR><SPAN class=745091714-26112007>DL</SPAN>>
FPGA equivalent of atmost 64 diodes or resistors.<BR><BR><SPAN
class=745091714-26112007>SN> </SPAN>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><SPAN class=745091714-26112007><FONT
face=Arial color=#0000ff> </FONT></SPAN><BR><SPAN
class=745091714-26112007>The issue here is that the hardware changed and the
driver doesn't support it. I think this would be fixed by having
information passed to the driver in the platform_device struct to
specify information, since its not able to be discerned by the physical
hardware information: version registers,
etc.</SPAN><BR></FONT></DIV></BODY></HTML>