[PATCH 0/2] Zynq7000 series device configuration driver

[Chris Johns]

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