| Message ID | 20230919100017.43523-1-rasmus.villemoes@prevas.dk |
|---|---|
| State | Superseded |
| Delegated to: | Stefano Babic |
| Headers | show |
| Series | mx8m: csf.sh: pad csf blob for u-boot.itb to CSF_SIZE minus IVT header | expand |
On 9/19/23 12:00, Rasmus Villemoes wrote: > When built with CONFIG_IMX_HAB, the full FIT image, including stuff > tacked on beyond the end of the fdt structure, is expected to be (fdt > size rounded up to 0x1000 boundary)+CONFIG_CSF_SIZE. > > Now, when the FIT image is loaded from a storage device, it doesn't > really matter that the flash.bin that gets written to target isn't > quite that big - we will just load some garbage bytes that are never > read or used for anything. But when flash.bin is uploaded via uuu, > it's important that we actually serve at least as many bytes as the > target expects, or we will hang in rom_api_download_image(). > > Extend the logic in the csf.sh script so that the csf blob is padded > to CONFIG_CSF_SIZE minus the size of the IVT header. On which SoC do you trigger this stuff ? (or rather, which bootrom version, v1 or v2? they each use SDP or SDPS respectively) > Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> > --- > doc/imx/habv4/csf_examples/mx8m/csf.sh | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/doc/imx/habv4/csf_examples/mx8m/csf.sh b/doc/imx/habv4/csf_examples/mx8m/csf.sh > index 65c143073c..80edc94aeb 100644 > --- a/doc/imx/habv4/csf_examples/mx8m/csf.sh > +++ b/doc/imx/habv4/csf_examples/mx8m/csf.sh > @@ -75,5 +75,13 @@ dd if=ivt.bin of=flash.bin bs=1 seek=${ivt_block_offset} conv=notrunc > > # Generate CSF blob > cst -i csf_fit.tmp -o csf_fit.bin > + > +# When loading flash.bin via USB, we must ensure that the file being > +# served is as large as the target expects (see > +# board_spl_fit_size_align()), otherwise the target will hang in > +# rom_api_download_image() waiting for the remaining bytes. > +CSF_SIZE=$(sed -n "/CONFIG_CSF_SIZE=/ s@.*=@@p" .config) > +truncate -s $((CSF_SIZE - 0x20)) csf_fit.bin Can you use dd(1) instead ? I think dd(1) is more portable than truncate(1) , at least I cannot find truncate(1) in opengroup specs.
On 19/09/2023 20.27, Marek Vasut wrote: > On 9/19/23 12:00, Rasmus Villemoes wrote: >> When built with CONFIG_IMX_HAB, the full FIT image, including stuff >> tacked on beyond the end of the fdt structure, is expected to be (fdt >> size rounded up to 0x1000 boundary)+CONFIG_CSF_SIZE. >> >> Now, when the FIT image is loaded from a storage device, it doesn't >> really matter that the flash.bin that gets written to target isn't >> quite that big - we will just load some garbage bytes that are never >> read or used for anything. But when flash.bin is uploaded via uuu, >> it's important that we actually serve at least as many bytes as the >> target expects, or we will hang in rom_api_download_image(). >> >> Extend the logic in the csf.sh script so that the csf blob is padded >> to CONFIG_CSF_SIZE minus the size of the IVT header. > > On which SoC do you trigger this stuff ? imx8mp > (or rather, which bootrom version, v1 or v2? they each use SDP or SDPS > respectively) Absolutely no idea. I just do "uuu flash.bin", which seems to DTRT automatically, I've never figured out the esoteric uuu language, and I've never found any actual documentation for it. It also doesn't work without https://lore.kernel.org/u-boot/20230919134932.134678-1-rasmus.villemoes@prevas.dk/ due to the spl_load_simple_fit() abuse. >> + >> +# When loading flash.bin via USB, we must ensure that the file being >> +# served is as large as the target expects (see >> +# board_spl_fit_size_align()), otherwise the target will hang in >> +# rom_api_download_image() waiting for the remaining bytes. >> +CSF_SIZE=$(sed -n "/CONFIG_CSF_SIZE=/ s@.*=@@p" .config) >> +truncate -s $((CSF_SIZE - 0x20)) csf_fit.bin > > Can you use dd(1) instead ? I think dd(1) is more portable than > truncate(1) , at least I cannot find truncate(1) in opengroup specs. Certainly. Rasmus
On 9/19/23 21:15, Rasmus Villemoes wrote: > On 19/09/2023 20.27, Marek Vasut wrote: >> On 9/19/23 12:00, Rasmus Villemoes wrote: >>> When built with CONFIG_IMX_HAB, the full FIT image, including stuff >>> tacked on beyond the end of the fdt structure, is expected to be (fdt >>> size rounded up to 0x1000 boundary)+CONFIG_CSF_SIZE. >>> >>> Now, when the FIT image is loaded from a storage device, it doesn't >>> really matter that the flash.bin that gets written to target isn't >>> quite that big - we will just load some garbage bytes that are never >>> read or used for anything. But when flash.bin is uploaded via uuu, >>> it's important that we actually serve at least as many bytes as the >>> target expects, or we will hang in rom_api_download_image(). >>> >>> Extend the logic in the csf.sh script so that the csf blob is padded >>> to CONFIG_CSF_SIZE minus the size of the IVT header. >> >> On which SoC do you trigger this stuff ? > > imx8mp > >> (or rather, which bootrom version, v1 or v2? they each use SDP or SDPS >> respectively) > > Absolutely no idea. I just do "uuu flash.bin", which seems to DTRT > automatically, I've never figured out the esoteric uuu language, and > I've never found any actual documentation for it. So yeah, MX8MP is SDPS (streaming). > It also doesn't work without > https://lore.kernel.org/u-boot/20230919134932.134678-1-rasmus.villemoes@prevas.dk/ > due to the spl_load_simple_fit() abuse. > >>> + >>> +# When loading flash.bin via USB, we must ensure that the file being >>> +# served is as large as the target expects (see >>> +# board_spl_fit_size_align()), otherwise the target will hang in >>> +# rom_api_download_image() waiting for the remaining bytes. >>> +CSF_SIZE=$(sed -n "/CONFIG_CSF_SIZE=/ s@.*=@@p" .config) >>> +truncate -s $((CSF_SIZE - 0x20)) csf_fit.bin >> >> Can you use dd(1) instead ? I think dd(1) is more portable than >> truncate(1) , at least I cannot find truncate(1) in opengroup specs. > > Certainly. Please do v2 with dd and then we should be all fine, thanks.
diff --git a/doc/imx/habv4/csf_examples/mx8m/csf.sh b/doc/imx/habv4/csf_examples/mx8m/csf.sh index 65c143073c..80edc94aeb 100644 --- a/doc/imx/habv4/csf_examples/mx8m/csf.sh +++ b/doc/imx/habv4/csf_examples/mx8m/csf.sh @@ -75,5 +75,13 @@ dd if=ivt.bin of=flash.bin bs=1 seek=${ivt_block_offset} conv=notrunc # Generate CSF blob cst -i csf_fit.tmp -o csf_fit.bin + +# When loading flash.bin via USB, we must ensure that the file being +# served is as large as the target expects (see +# board_spl_fit_size_align()), otherwise the target will hang in +# rom_api_download_image() waiting for the remaining bytes. +CSF_SIZE=$(sed -n "/CONFIG_CSF_SIZE=/ s@.*=@@p" .config) +truncate -s $((CSF_SIZE - 0x20)) csf_fit.bin + # Patch CSF blob into flash.bin dd if=csf_fit.bin of=flash.bin bs=1 seek=${csf_block_offset} conv=notrunc
When built with CONFIG_IMX_HAB, the full FIT image, including stuff tacked on beyond the end of the fdt structure, is expected to be (fdt size rounded up to 0x1000 boundary)+CONFIG_CSF_SIZE. Now, when the FIT image is loaded from a storage device, it doesn't really matter that the flash.bin that gets written to target isn't quite that big - we will just load some garbage bytes that are never read or used for anything. But when flash.bin is uploaded via uuu, it's important that we actually serve at least as many bytes as the target expects, or we will hang in rom_api_download_image(). Extend the logic in the csf.sh script so that the csf blob is padded to CONFIG_CSF_SIZE minus the size of the IVT header. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> --- doc/imx/habv4/csf_examples/mx8m/csf.sh | 8 ++++++++ 1 file changed, 8 insertions(+)