[meta-xilinx] [PATCH 0/5] Updates to u-boot-xlnx

[Mike Looijmans]

On 17-01-16 09:59, Nathan Rossi wrote:
> On Sat, Jan 16, 2016 at 4:19 AM, andrey <andrey at 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