Xilinx-tools independent boot with new u-boot

[imrehg]

[tnt]

Well, the U-Boot SPL still requires to generate the ps7_init_gpl.{c,h} AFAIK and this is done with the Xilinx tools.

However you can get rid of the FSBL which I guess is already a good step

There is a small complication though is that the parallella requires the PL bitstream to be loaded very early because during u-boot init, it needs to talk to the PMIC to properly setup all the voltage rails and this currently relies on the FSBL to do it.

Not impossible to overcome by any mean, but it's not as simple as enabling the SPL option in U-boot.

[imrehg]

[tnt]

Yeah, they have copied the ps7_init_gpl.{c,h} for some of the reference board inside the repo, but theses still have been generated by the Xilinx tools and they are heavily dependent of the hardware configuration (since they contain such very specific info as the DDR trace length delay to compensate for board layout ...).

Some "default" files can definitely be generated once for the parallella, but when you want to customize stuff, you might need to regenerate them. For instance, I just regenerated mine to use much better DDR timing to boost memory performance, and also enabled the I2C1 controller and enabled the fabric clock 1 to 200 MHz ... all of theses are done by those files and so I needed Xilinx to regenerate them.

One very nice thing though is that they are generated by vivado when customizing the PS7 block, so there is no need to "export hardware" then use the "SDK". (so you don't even need a SDK license).

[imrehg]

I see, it does make sense, thanks! I haven't used the Xilinx tools yet, but do work with the u-boot on many different boards, and got excited. Interesting to know how much more there is. Thanks a lot for the details!

If I understand it correctly, it's a bit like the device tree files in the kernel. The vendor might put out one, while the community might converge on another version for the same board (e.g. different devices enabled, different video settings, that sort of thing). Just these ps7_init files are much more sensitive to specifics, as you say.

In this case, wouldn't it make sense to generate a base or official Parallella version, something that's okay in general and have that in u-boot? (there had to be something already to be able to boot Parallella already, just move it into u-boot based on the gpl generated files). Besides that there could be (should be, hope there is) more community developed specialized files, just like for example you boosted yours? Then everyone who wants to build things from scratch just selects their choice of the files, and still don't need Xilinx to get all the binaries, as long as they don't modify their hardware optimizations.

Did I get the gist of it?

[tnt]

Yeah, it's kind of the other side of the device tree. Since the DT configures the OS for the hardware that exists, but in this case, it kind of selects which hardware you want to exist for the way you designed your board.

Some "default" file can definitely be generated. The reference PS7 configuration is included in the parallella-hw repository (in the fpga/vivado/releases/parallella_7020_headless.xpr.zip archive). And this should be what's been flashed in the QSPI of all of the boards. When doing customization, you pretty much always have to restart from that point so that you don't have to enter all the params from scratch.

That's one thing that's tricky about all of this is that it's in the QSPI, and so if you screw up (or if something goes wrong), JTAG is going to be the only way to recover. (and so far I pretty much screwed up everytime and always had to recover with jtag )

[piotr5]

quick question in that context: since you need jtag whenever flashing goes wrong, wouldn't it be better to create a 2-step bootup with step1 being run from flashed rom and 2nd step will completely reprogram fpga programmable logic from scratch again and boot the next step? then no more flashing is needed for programming fpga and if you made a mistake it's only a matter of replacing the sd-card...

[aolofsson]

[tnt]

The programmable logic (PL) isn't the issue here. This can even be reprogrammed from linux in live ...

The issue is the FSBL and bootloader and those init some stuff that _has_ to be done very very early and can only be done once.

[piotr5]

since aolofsson doesn't want to go into that direction, let's leave it at that.
just for the protocol: my idea was that unlike other zync-boards parallella has the epiphany, in addition to some off-chip flash. i.e. program fpga in a way that it can boot from epiphany and put data from sd-card to epiphany. only then from epiphany perform all the First Stage Boot Loader stuff, and once linux is loaded program all the epiphany-stuff from the arm processor. guess it could be possible that zync is so inflexible that First Stage Boot Loader is only allowed from flash and not from any other chip, but maybe in future this could be changed? or maybe it already is possible to program the flash for initializing some upload of data loaded from sd, to be performed by epiphany, and the tricky part would be to kind of reset zync into boot-state while maintaining its ability to read from eLink...