On 10/23/24 10:10 PM, Lothar Rubusch wrote:
Hi,
sorry for the late reply.
Can this be generated using binman instead ?
This would a oportunity for me to learn the binman tool. Great idea! I
need to read a bit more on binman to get a better understanding. I'll
give it a try and let you know. Thank you.
This commit might help:
5fccc2891e28 ("ARM: dts: stm32: Generate u-boot.itb using binman on DH
STM32 DHSOM")
I face a problem here. First, to apply binman stances in the .dtsi and
integrating it as -u-boot.dtsi is very interesting and I actually like
the solution to bind everything togerther in this way.
But, I face the situation where the very design specific bitstream(s)
for the FPGA are actually not supposed to be upstreamed. Having u-boot
binaries and bitstream as .itb separate, allows to build the u-boot
part even w/o the bitstream, i.e. the u-boot setup can be quite
generic, can be tested and verified building. Is this still possible
if binman requires it as binary blob?
I believe so, U-Boot CI does use binman to build e.g. imx8m targets
which do require extra firmware, but during the CI build that extra
firmware is replaced by blank empty files by binman. It does print some
sort of warning that the files are missing ... try e.g. 'make
imx8mp_dhcom_pdk3_defconfig ; make' and you should see the behavior
locally too.
On the otherhand it allows to
wrap the FPGA logic and exchange the .itb separately when developing a
design w/o the need to modify the bootloader.
So, I'd like to hear your opinion on that. Would the .itb appraoch be
acceptable in this case? Is there still a better way? Does it make
sense to make a separate binman setup instead?
The SPL .its handling was dropped now that the last user was switched to
the binman method, but I hope the above will let you switch to the
binman method too ?
8efc954fc77e ("Makefile: Drop SPL_FIT_SOURCE support")
