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

Reply via email to