On Fri, 2018-11-23 at 13:40 +0100, Marek Vasut wrote:
On 11/23/2018 10:54 AM, Chee, Tien Fong wrote:
On Wed, 2018-11-21 at 15:21 +0100, Marek Vasut wrote:
On 11/21/2018 11:41 AM, tien.fong.chee@intel.com wrote:
From: Tien Fong Chee tien.fong.chee@intel.com
Did you change Author:ship of the patch ?
I believe you did, so please fix that.
Very sorry. I din't realize the author name was changed.
Bundle U-Boot fitImage containing U-Boot and FPGA bitstream into the u-boot-with-spl.sfp on Arria10. This lets U-Boot operate in a very similar fashion to Gen5, where the U-Boot binary got loaded by the SPL from a uImage concatenated at the end of the SPL SFP image. On Gen10, the U-Boot is in fitImage which contains the FPGA bitstream as well. In this case, the SPL can load the FPGA bitstream first and load the U-Boot afterward in the same manner. This is nonetheless a stopgap measure until there is a proper firmware loader in U- Boot.
Right, this is a stopgap measure until FW loader is present. Why is this patch needed at all in this series ?
This patch is cherry picked from the sdmmc_next custodian, so this patch is required for generating FIT image. I can remove the stopgap comment to avoid confusing.
But why is this patch needed at all ? You use the firmware loader to load the FPGA bitstream. Where does the fitImage come into play ?
The fitImage was used to circumvent the missing FW loader, when I needed to load multiple files (bitstream and u-boot binary). Now there is no such requirement anymore, so the entire fitImage machinery is probably not needed ?
Loading issue is not the reason we choose the fitImage. We choose it because it allows more flexibility in handling various type images, especially it allows user more choices to enhance integrity and security protection.
Although we plan to use fitImage as our default implementation, but this series of patches are still allow fw loading individual bitstream image in filesystem partition. So, it is up to user to made the choice.