Xilinx devicetrees

[Koss, Mike (Mission Systems)]

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)

________________________________

From: Stephen Neuendorffer [mailto:stephen.neuendorffer at xilinx.com] 
Sent: Sunday, November 25, 2007 6:59 PM
To: David H. Lynch Jr.; Grant Likely; linuxppc-embedded
Subject: RE: Xilinx devicetrees

DL>    I am not expert on this, but at Pico we already store our boot
monitor in the .bit files in BRAM.
DL>     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.
DL>     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, 
DL>  and handle hosted vs. standalone operation.
DL>     And aparently extract the devicetree from a bit file and pass it
to a linux kernel.

SN> Once you can load a bitstream from flash, loading the device tree
from flash
SN> 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?)
 
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.

DL>  In static or fairly static hardware, that's fine. Even in somewhat
dynamic hardware with large quantities of startup resources - like a PC.
DL>  But in highly dynamic hardware with fairly limited resources it
starts to become an issue.

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.

GL> No, unfortunately they don't deal with the problem you're facing
GL> (which I'm facing also).  But it will be solved if we figure out a
GL> sane way to bind the device tree up with the FPGA bitstream without
GL> consuming FPGA resources.
  
DL>    Note to Xilinx:
DL>       There MUST be some way of binding a device description to a
bit file.
DL>    neither building it into the FPGA fabric nor appending it to the
end
DL> of the bit file are perfect solutions,
DL>    The former is more powerfull and flexible but wastes precious
DL> resources. The later is more complex and puts more burdens on
DL>    software developers, and may be completely unfeasible in some
DL> environments - not mine fortunately.

SN> 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:
SN> 1) I need several KB additional non volatile storage.  Given the
size of the FPGA bitstream, this can't be a huge constraint.
SN> 2) I can't use compile time optimization based on xparameters as
easily.  Anyone want to implement the alternatives mechanism on ppc and
microblaze?
SN> 3) Some additional boot time.  However, again, this seems marginal.
 
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..)?

DL>    Regardless, something must be done. An odd collection of
devicetree
DL> files co-mingled with a collection of bit files, is little better
than
DL> xparameter files all over the place.

SN> Certainly..  But in a sense, these are all intermediate files on the
path to the image on the board.  That 
SN> (and how it is interpreted by the platform code) should be generated
in a consistent fashion by EDK.  
SN> See my other email for some of the possibilities.  Are there
specific reasons why you think those 
SN> proposals are inadequate?  Now is the time when we can take
criticism, with the goal towards making 
SN> a good end solution.
 
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. 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.

DL>    And once again a plea to ALWAYS make version/capabilities
registers
DL> atleast an optional part of every design.
DL>    Embeddeding a device tree into a design might be fairly
expensive. a
DL> pair of read only 32 bit registers is damn near free - basically the
DL> FPGA equivalent of atmost 64 diodes or resistors.

SN> Actually, device trees actually seem to be cheaper (in the whole
system sense) than such registers.  Unless there is something I don't
understand?
 
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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20071213/9595f2ca/attachment.htm