On 22/04/2017 01:44, Patrick Gauvin wrote:
I'll plan on storing a few bitfiles for common platforms, like the MicroZed (7Z010) and the ZedBoard (7Z020), with the test. I do have a simple bitfile, but it currently targets the ZedBoard. If you'd like, I can send a version for the MicroZed when I send the updated patches next week (should I attach it to the mailing list? I'm not sure what the etiquette is for large attachments).
Send me the files directly and I can upload them to the ftp server. We can figure out how to integrate them into the build after that.
I worry about the processing system initialization (such as FCLK frequency) being mismatched with the bitstream.
I have code to control some of the clocks and set them. Further to this for a project I have been adding pre and post load metadata to a bitfile wrapper to manage this issue. The pre-load metadata can hold configurations that update the Zynq before a load, for example FCLK. This moves the role of the FSBL initialise to being a default and for example specific bitfiles can be built at different AXI clock speeds. In the case of the Zedboard you could have a bitfile that has a completely difference set up to the Zedboard's default.
I think the SDK generates a GPLed FSBL source now, so maybe including that will do.
I do not think the SDK FSBL is GPL. It use to be restrictive but I think recent versions have a better license. I have not checked lately.
If there is an alternative I'd love to hear it, I dislike being tied to the SDK for initialization.
I prefer to have no dependency on the SDK because of the complexity it creates, for example the FPGA team want a later release because it is a faster or better build, while the matching SDK break software, or the compiler is broken, or some other reason.
The only solutions I know of are the SDK, uboot or some code I have. My solution needs some work to make public.
Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
