On 17-01-16 09:59, Nathan Rossi wrote:
On Sat, Jan 16, 2016 at 4:19 AM, andrey <and...@elphel.com> wrote:
Hello Nathan,
We are now starting production of our Zynq-based product and are trying to
update a 2-year old software to the current state of Yocto. We do not use
Vivado to manage the project, for the FPGA development we use alternative
Eclipse-based integration that remotely launches specific Vivado tools. We
had to replace some of the Xilinx primitives models (such as
https://github.com/Elphel/gtxe2_gpl ) to be able to simulate the complete
project (it is now above 80% utilization) with the GPL-ed tools
(Icarus+GTKWave). In 2013 we made a replacement for Xilinx FSBL that at
that time was violating the GNU GPL of the U-Boot. Later Xilinx had to
comply with GPL and modified the license for the generated files, but we
would still like to avoid Vivado for FSBL generation - it is extra work for
us and is inconvenient to learn new GUI, re-enter the project data just to
be able to generate boot loader.
It was you guys that got the ball rolling for the ps7_init_gpl files,
thanks for that :).
At the moment I do not think it is possible to completely avoid Vivado
for generating SPL/FSBL. Essentially the way that the upstream U-Boot
handles the FSBL equivalent parts is by relying on the
ps7_init_gpl.[ch] files that Vivado generates from a Zynq design. For
some specific boards the ps7_init files are in the U-Boot source repo,
this is what allows for generating those bootloaders without needing
Vivado.
I suppose if you changed nothing on the PS you could do the same for
your board, have static ps7_init_gpl files stored in your source
control. Although keep in mind that it is only the Zynq configuration
that is needed by Vivado to generate the ps7_init files, so it might
be possible to write a tcl script of some such to automate Vivado to
generate the ps7_init files without needing to have your actual design
in Vivado.
The question is - does the current upstream U-Boot have all what is needed
to create an alternative bootloader for Zynq (by updating our
https://github.com/Elphel/meta-ezynq ) or there are still some important
functionality (common to all boards, not specific to particular ones and/or
Vivado releases) in u-boot-xlnx that is not yet in available in the
upstream?
Apart from the ps7_init stuff, everything else is pretty much there in
U-Boot to have SPL start in local ram, call ps7_init and then load the
full U-Boot from any device (or 'falcon' boot the kernel directly).
However my understanding is that ezynq doesn't need the ps7_init files
from Vivado, and has its own configuration/setup for those values. I
imagine if there is nothing against updating the ezynq codebase to be
a replacement for the ps7_init code?, it would be a great way to go if
the Vivado route is not reasonable. I have always been curious as to
how much of the early register setup could be done by U-Boot itself as
well as additional device tree properties at different levels
(U-Boot/Kernel) via e.g. pinmuxing. Unfortunately since ps7_init files
got GPL'd that has been the easiest solution.
Pinmuxing works just fine in the 4.x kernel. I used it to do a combined
NOR/NAND boot. U-boot loads from QSPI flash and loads the kernel from
QSPI as well. When the kernel boots, it re-muxes the pins for the QSPI
and activates the NAND pins, so it can load the rootfs from NAND flash.
All you need is to fill in the devicetree, no coding required.
(In theory it should be possible to make the kernel do runtime switches
between the two on demand. But that would require quite some coding.)
As for the ps7_init files, I tend to hand-craft them. Vivado is too
limited (and too buggy) to get it right.
This can be taken further by having u-boot only set the barest
necessities, that is, only pinmux devices that it might want to boot
from, and leave the rest for the kernel to configure. That also makes
for a much more sensible flow.
I haven't checked recently, but SPL boot was broken last year for QSPI,
so I stuck with a slightly older version.
As for the ezynq, I tried but couldn't really get that code path to work
properly. Which is a pity, because that just filled in the register
table data that the ROM would directly apply, making for a quicker and
more efficient boot than the method the ps7_init appears to use.
--
Mike Looijmans
--
_______________________________________________
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx
