
Hi Michal,
On Thu, Jul 19, 2018 at 2:23 AM Michal Simek michal.simek@xilinx.com wrote:
On 18.7.2018 20:02, Luis Araneda wrote:
[...] I didn't send them because just changing the defconfig isn't enough,
It should be enough. It is configuration option and just enabling that feature. You should still be able to use just u-boot.img in legacy or fit format without any issue.
Ok. Should I send a patch only for the Zybo or all zynq boards? Also, for than one board, should I create one patch per board or only one big patch for all of them?
I think it will be good if you can look at my patch and also compare boot up time when you setup compression to gzip. I expect some changes in connection to this code.
if (IS_ENABLED(CONFIG_SPL_OS_BOOT) && IS_ENABLED(CONFIG_SPL_GZIP) && image_comp == IH_COMP_GZIP && type == IH_TYPE_KERNEL) {
And I would expect that copying smaller fit with unziping bitstream will be faster then what you have now. Especially on boards which bigger fpga.
I made some modifications to make gzip work, and another one dirty (non-upstremeable) to make external data work. Additionally, I added time reporting on three places. The modifications are attached.
I tested several bitstreams, with different compression levels:
gzip -c -n <comp_level> <bin_file> > <out_file>
The results, for a fit image with embedded data, are: file size (bytes) time1 time2 time3 uncompressed 2,434,112 567 597 623 compressed -1 446,028 208 1165 1190 compressed -4 407,764 205 1063 1088 compressed -5 398,346 203 1094 1119 compressed -9 376,821 200 1141 1166
The time for a fit image with external data (-E option for mkimage) is ~100 time units (ms?) less, and time1 remains constant at ~12 time units.
At least on my setup (Zybo Z7-20), gzip just increase the boot time.
I have an idea to automate the FIT generation. The build system could scan for the existence of a file, for example "board/xilinx/zynq/<board>/preboot.bin", and add the fpga node automatically (to .its) if the file exists. Because I think that storing .bin files in the U-Boot repository is infeasible. That will require additions and modifications to the current way the build system works, and I'm still thinking how to implement them.
Take a look at pmufw handling for zynqmp for inspiration.
Will do, thanks for the heads up.
Thanks,
Luis Araneda.