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:[EMAIL PROTECTED] 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.
_______________________________________________ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded