Hi TI folks, I guess things have been busy on your end, so I went ahead and secured an SK-AM62 board (GP variant) to verify the patch[1] myself. I've tested it against the latest U-Boot master, and as far as I can tell, it boots without issues[2].
Could you please take a look when you have a moment? If you’re happy with the changes, would you prefer I open a PR on the TI GitHub repo[3], or should I submit this directly to the U-Boot upstream mailing list? [1] https://github.com/open-source-firmware/flat-image-tree/issues/32#issuecomment-3948419217 [2] https://github.com/open-source-firmware/flat-image-tree/issues/32#issuecomment-4344362533 [3] https://github.com/TexasInstruments/ti-u-boot Best regards, Aristo Bryan Brattlof <[email protected]> 於 2026年3月9日週一 下午2:08寫道： > > On March 9, 2026 thus sayeth Aristo Chen: > > Hi TI folks, > > > > I have put some thoughts in the github issue[1] that we are discussing > > FIT image spec, could you please take a look when you have time? > > > > Absolutely. Sorry for the delay. I think I have a github filter set long > ago which probably needs adjusting. > > ~Bryan > > > Best regards, > > Aristo > > > > [1] https://github.com/open-source-firmware/flat-image-tree/issues/32 > > > > Aristo Chen <[email protected]> 於 2026年2月10日週二 下午4:16寫道： > > > > > > Hi E Shattow and all, > > > > > > E Shattow <[email protected]> 於 2026年1月14日週三 上午1:29寫道： > > > > > > > > Hi Aristo, > > > > > > > > On 1/13/26 07:09, Aristo Chen wrote: > > > > > Hi E Shattow, > > > > > > > > > > Aristo Chen <[email protected]> 於 2025年11月5日週三 下午8:21寫道： > > > > >> > > > > >> Hi E Shattow, > > > > >> > > > > >> E Shattow <[email protected]> 於 2025年9月24日 週三 下午9:31寫道： > > > > >>> > > > > >>> Hi Aristo, > > > > >>> > > > > >>> On 9/24/25 04:43, Nishanth Menon wrote: > > > > >>>> On 06:37-20250924, Nishanth Menon wrote: > > > > >>>>> On 10:59-20250914, Aristo Chen wrote: > > > > >>>>>> This patch series enhances FIT image robustness by adding > > > > >>>>>> **memory > > > > >>>>>> region overlap detection** to `mkimage` and fixing existing > > > > >>>>>> overlaps > > > > >>>>>> in DTS files and `binman` tests. > > > > >>>> > > > > >>>> [...] > > > > >>>>>> > > > > >>>>> > > > > >>>>> Looks like i see a build regression in linux-next after this > > > > >>>>> series. > > > > >>>> > > > > >>>> I fat fingered that one.. sorry, I meant u-boot next. > > > > >>>> > > > > >>>> > > > > >>>> Fails at commit 4d84fa1261eb, last pass was on commit d81c1118580f > > > > >>>> > > > > >>>>> > > > > >>>>> https://gist.github.com/nmenon/b2fc9e7680cc296062c7dced94105f76 > > > > >>>> > > > > >>>> I believe there are outstanding comments on V1 that have'nt been > > > > >>>> addressed either. Can we revert/drop this series for now while the > > > > >>>> comments are addressed? > > > > >>>> > > > > >>> > > > > >>> Similar to Nishanth, I am seeing a build regression, itb.map: > > > > >>> > > > > >>> ImagePos Offset Size Name > > > > >>> <none> 00000000 <none> itb > > > > >>> <none> 00000000 <none> fit > > > > >>> <none> 00000000 000c1698 uboot > > > > >>> <none> 00000000 000c1698 u-boot-nodtb > > > > >>> <none> 000c1698 00202128 opensbi > > > > >>> <none> 00000000 00202128 opensbi > > > > >>> > > > > >>> Yields this error: > > > > >>> ... > > > > >>> MKIMAGE fit-dtb.blob > > > > >>> Warning: not able to get `load` of node 'fdt-1' > > > > >>> Warning: not able to get `load` of node 'fdt-2' > > > > >>> Warning: not able to get `load` of node 'fdt-3' > > > > >>> Warning: not able to get `load` of node 'fdt-4' > > > > >>> Warning: not able to get `load` of node 'fdt-5' > > > > >>> Warning: not able to get `load` of node 'fdt-6' > > > > >>> Warning: not able to get `load` of node 'fdt-7' > > > > >>> CAT u-boot-fit-dtb.bin > > > > >>> ... > > > > >>> MKIMAGE u-boot.img > > > > >>> Warning: not able to get `load` of node 'fdt-1' > > > > >>> Warning: not able to get `load` of node 'fdt-2' > > > > >>> Warning: not able to get `load` of node 'fdt-3' > > > > >>> Warning: not able to get `load` of node 'fdt-4' > > > > >>> Warning: not able to get `load` of node 'fdt-5' > > > > >>> Warning: not able to get `load` of node 'fdt-6' > > > > >>> Warning: not able to get `load` of node 'fdt-7' > > > > >>> COPY u-boot.dtb > > > > >>> MKIMAGE u-boot-dtb.img > > > > >>> Warning: not able to get `load` of node 'fdt-1' > > > > >>> Warning: not able to get `load` of node 'fdt-2' > > > > >>> Warning: not able to get `load` of node 'fdt-3' > > > > >>> Warning: not able to get `load` of node 'fdt-4' > > > > >>> Warning: not able to get `load` of node 'fdt-5' > > > > >>> Warning: not able to get `load` of node 'fdt-6' > > > > >>> Warning: not able to get `load` of node 'fdt-7' > > > > >>> BINMAN .binman_stamp > > > > >>> Wrote map file './itb.map' to show errors > > > > >>> binman: Error 1 running 'mkimage -t -F ./itb.fit.fit': Warning: not > > > > >>> able > > > > >>> to get `load` of node 'fdt-1' > > > > >>> [Config: conf-1] Error: Overlap detected: > > > > >>> - uboot: [0x40200000 - 0x402c1698] > > > > >>> - opensbi: [0x40000000 - 0x40202128] > > > > >>> > > > > >>> make[1]: *** [/tmp/u-boot.2.git/Makefile:1339: .binman_stamp] Error > > > > >>> 1 > > > > >>> make[1]: Leaving directory '/home/es/build/u-boot' > > > > >>> make: *** [Makefile:198: sub-make] Error 2 > > > > >>> make: Leaving directory '/tmp/u-boot.2.git' > > > > >>> > > > > >>> If you would like to reproduce the issue, use config > > > > >>> starfive_visionfive2_defconfig and pass to OPENSBI env variable the > > > > >>> path > > > > >>> of opensbi object 'fw_dynamic.bin' built using PLATFORM=generic, > > > > >>> with > > > > >>> the ordinary gcc riscv64 toolchain. The starfive visionfive2 board > > > > >>> target in U-Boot supports multiple vendors and boards selected at > > > > >>> runtime and is an example of a more complex FIT usage that you may > > > > >>> be > > > > >>> interested in for comparison and testing. > > > > >>> > > > > >>> Best regards, > > > > >>> > > > > >>> -E > > > > >> > > > > >> Sorry that I didn't noticed that my previous email sent to you was > > > > >> not > > > > >> including other people > > > > >> > > > > >> Long story short, I am now able to reproduce the overlap issue that > > > > >> you have encountered, and > > > > >> I spent some time trying to understand what is opensbi, please > > > > >> correct > > > > >> me if I am wrong > > > > >> > > > > >> AFAICT, there will be 2 types of firmware built, one is > > > > >> `fw_payload.bin`, and the other is > > > > >> `fw_dynamic.bin` > > > > >> - fw_payload.bin: contains the next-stage binary, so the file size > > > > >> will be bigger > > > > >> - fw_dynamic.bin: provides information about the next boot stage at > > > > >> runtime, so the size is smaller > > > > >> > > > > >> and here are the size of these 2 files built in my environment > > > > >> ``` > > > > >> -rw-rw-r-- 1 ubuntu ubuntu 273048 Oct 25 14:49 fw_dynamic.bin > > > > >> -rw-rw-r-- 1 ubuntu ubuntu 2105656 Oct 25 14:49 fw_payload.bin > > > > >> ``` > > > > >> > > > > >> When using my overlap checking mechanism, and passing the > > > > >> fw_dynamic.bin to build U-Boot, > > > > >> there is no overlap issue. However, when using fw_payload.bin, there > > > > >> will be an overlap issue. > > > > >> > > > > >> AFAICT, the SPL will load the opensbi firmware(assuming > > > > >> fw_payload.bin > > > > >> here) first, then load > > > > >> U-Boot into memory, and then jump to opensbi firmware, so I was a bit > > > > >> confused why the > > > > >> overlapped opensbi still works? > > > > >> > > > > >> I will find some time to figure out how the whole loading/booting > > > > >> process looks like, but it would > > > > >> be greatly appreciated if you can share some insight, thanks! > > > > > > > > > > I finally had some time to revisit this and managed to get a > > > > > VisionFive2 > > > > > board for local testing. > > > > > > > > > > While trying to make it bootable I noticed the following docs: > > > > > - > > > > > https://docs.u-boot.org/en/latest/board/starfive/visionfive2.html#second-stage-bootloader-opensbi-fw-dynamic-bin-u-boot-main > > > > > - > > > > > https://wiki.gentoo.org/wiki/StarFive_VisionFive_2#Building_OpenSBI > > > > > > > > > > Both appear to recommend using OpenSBI’s fw_dynamic.bin when building > > > > > U‑Boot. I couldn’t find any guidance on using fw_payload.bin together > > > > > with U‑Boot, which made me wonder why fw_payload.bin was used in your > > > > > earlier report. > > > > > > > > > > > > > Likely I mixed up the filenames when writing in conversation, as I did > > > > when writing on the opensbi mailing list about a dependency tracking bug > > > > in opensbi build system: > > > > > > > > https://lore.kernel.org/opensbi/[email protected]/ > > > > > > > > and > > > > > > > > https://lore.kernel.org/opensbi/[email protected]/ > > > > > > > > ...which is clearly a mistake to write "OPENSBI=/path/to/fw_payload.bin" > > > > when it should instead be "OPENSBI=/path/to/fw_dynamic.bin", > > > > acknowledged in the follow-up message: > > > > > > > > https://lore.kernel.org/opensbi/[email protected]/ > > > > > > > > > Could you clarify whether there is documentation (or a specific > > > > > requirement) that calls for fw_payload.bin in this flow? If the > > > > > intended > > > > > path is fw_dynamic.bin, then the overlap issue disappears for me > > > > > > > > > > > > > For the VisionFive2 and derivative boards, I intended to refer to > > > > fw_dynamic.bin only. If I mention otherwise it was in error or for not > > > > knowing what I'm looking at and reporting more information than > > > > required. There are RISC-V boards not related to VisionFive2 or its > > > > StarFive JH-7110 SoC that do use the fw_payload.bin approach but I think > > > > I just didn't notice the difference when transcribing to e-mail. > > > > > > > > > Thanks for your help and guidance. > > > > >> > > > > >> Best regards, > > > > >> Aristo > > > > > > > > > > Best regards, > > > > > Aristo > > > > > > > > Thanks very much for the follow-up, > > > Thanks for letting me know that StarFive VisionFive2 is not affected > > > by my patch! > > > > > > > > > > > -E > > > > > > We’re currently discussing a new proposal[1] for handling TI platforms > > > in the FIT image spec. Ahmad Fatoum has a few questions about > > > TI-specific implementations—could the TI folks on this thread please > > > take a look when you have a moment? > > > > > > Best regards, > > > Aristo > > > > > > [1] https://github.com/open-source-firmware/flat-image-tree/issues/32
