[meta-xilinx] Bitstream/Boot.bin/etc - Providers/Virtual targets

[andrey]

Michal,

I  admit that my ezynq code has some flaws (it is my first program in Python), but I'm sure it can do the job, especially with the help of others (we had access to only 3 boards - Microzed, our camera and  Xilinx ZC706). Usually in my work I prefer GUI tools - as I wrote you earlier I'm now working on a replacement to Vivado GUI with Eclipse-based software more convenient for myself (and I hope to some other developers too). But in the case of bootloader generation I do not see much advantage of fancier GUI - all the commercial boards (like Zedboard) can come with ready to use include files, and for hardware developers (as myself) it is not a big hassle to go through every single line of the hardware-specific configuration and make sure is what I need for the new design. This is an extra pre-flight test that can save from costly re-spins of the new boards.

As for incompatibility of GPLv3+ we used with U-Boot GPLv2 - I understand that U-Boot needs the same license as Linux kernel, so we probably can re-license it under that older version.

Andrey

---- On Thu, 13 Feb 2014 04:05:34 -0800 Michal Simek<monstr at monstr.eu> wrote ---- 


Hi guys, 
 
nice discussing and maybe good time to jump into. 
 
On 02/13/2014 08:15 AM, Cjw X wrote: 
> We should unequivocally throw the FSBL into the fires of Mount Doom. 
> 
> I've been working with u-boot-spl running on my microzed for about a month 
> now, and I'm already considerably happier with it. 
 
spl is nice and it will be supported in mainline u-boot soon. 
My patches have been already reviewed and waiting for adding to arm custodian 
tree. 
It means u-boot spl will be available for everybody. 
 
> The spl design is derived from ezynq from elphel, so it should be pretty 
> extensible to different platforms. I'll have a zedboard to play with next 
> week, so I'll get it up and running then. 
 
Andrey has done great work on this but how this all fit together 
is not the best. That's why currently I have used ps7_init files 
instead of ezynq project. 
I was discussing this with Andrey and meybe in future Andrey will 
change ezynq just for lowlevel setup generation because this is 
that difference. 
 
> I've considered trying to get u-boot to generate an spl build from the 
> ps_init code that xilinx spits out of the sdk. It is nice on some level, 
> but somewhat contrary to my end goal. My goal is to completely divorce Zynq 
> software development from Xilinx 
 
Not everybody is able to generate by hand configuration for their design. 
Not everybody wants to do it by hand when they have to do the same in design tools. 
Using projects like ezynq for generation is nice and definitely it is nice 
to see it but I don't believe that anybody will be able to invest time 
to maintain this in long term. 
 
As I told to Andrey will be good to change ezynq just to generate private 
ps7_init.c file because it is that thing you are asking for. 
 
I am not quite sure what you mean by "My goal is to completely divorce Zynq 
software development from Xilinx" but feel free to start writing all drivers/ 
support for zynq from scratch without any xilinx help. None can stop you 
to do so. 
 
> Next on my list is some updates to the kernel 
> 1) Fix the mmc writing bug (probably a hack because I think it is a 
> hardware flaw, but I haven't looked into it) 
 
If you mean dma allocation below kernel start address then fix is on way 
to mainline kernel. 
 
> 2) Fix the xdevcfg driver to be a misc driver so that udev recognizes it 
> properly 
 
there will be much more changes than just this. 
 
Thanks, 
Michal 
 
-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 
w: www.monstr.eu p: +42-0-721842854 
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ 
Maintainer of Linux kernel - Xilinx Zynq ARM architecture 
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform 
 
 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-xilinx/attachments/20140213/da7b8c06/attachment.html>