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).
I worry about the processing system initialization (such as FCLK frequency) being mismatched with the bitstream. I think the SDK generates a GPLed FSBL source now, so maybe including that will do. If there is an alternative I'd love to hear it, I dislike being tied to the SDK for initialization. -Patrick On Thu, Apr 20, 2017 at 6:37 PM, Chris Johns <chr...@rtems.org> wrote: > On 21/04/2017 07:55, Patrick Gauvin wrote: > >> Gedare, >> >> >> if the test programs are specific to the Zynq BSP, then we don't >> currently have a very good mechanism for maintaining them. Probably >> submitting them as "example programs" in the >> git.rtems.org/examples-v2.git <http://git.rtems.org/examples-v2.git> >> is the best place to look at integrating >> application/bsp-level tests. This is an area in need of longer-term >> solutions. >> >> >> OK, I will plan on putting them there. >> >> > What happens with bitfiles? For example I have a MicroZed with a 7Z010 and > I am not sure what a Zedboard has? > > Do you have a simple bitfile we can load? > > A bitfile that is not secured can compress well. Once this driver is in > RTEMS it would be nice to add another layer to load compressed files. > > Chris >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
