[Binman] Question regarding SPL symbol offsets generation
Adam Ford
aford173 at gmail.com
Mon Nov 4 04:35:24 CET 2024
On Sun, Nov 3, 2024 at 8:00 PM Adam Ford <aford173 at gmail.com> wrote:
>
> On Sun, Nov 3, 2024 at 7:41 PM Adam Ford <aford173 at gmail.com> wrote:
> >
> > On Thu, Sep 5, 2024 at 8:54 AM Lukasz Majewski <lukma at denx.de> wrote:
> > >
> > > Hi Adam,
> > >
> > > > On Wed, Aug 28, 2024 at 3:04 AM Lukasz Majewski <lukma at denx.de> wrote:
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > On Tue, 27 Aug 2024 at 12:47, Fabio Estevam <festevam at gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > Hi Lukasz,
> > > > > > >
> > > > > > > On Thu, Aug 15, 2024 at 5:14 PM Lukasz Majewski <lukma at denx.de>
> > > > > > > wrote:
> > > > > > > > Unfortunately not - this change is only for properly setting
> > > > > > > > start address of the u-boot.
> > > > > > > >
> > > > > > > > The _real_ problem here is the symbol placement generated by
> > > > > > > > binman when we try to define the image as a single one.
> > > > > > > >
> > > > > > > > Moreover, this change follows other boards with imx8mm
> > > > > > > > processor - ./configs/imx8mm_beacon_fspi_defconfig to be
> > > > > > > > specific.
> > > > > > > >
> > > > > > > > The "fix" (for which I'd been now probably opt) for this issue
> > > > > > > > would be to generate two images with binman - one for
> > > > > > > > u-boot-spl-ddr.bin and the final flash.bin with the former one
> > > > > > > > included (as it was before SHA1:
> > > > > > > > 37e50627efacd8dae18b564e9d8886a033e181bc)
> > > > > > >
> > > > > > > Is QSPI boot broken on i.MX8MM?
> > > > > > >
> > > > > > > I am adding Adam and Mamta who have tested QSPI booting on
> > > > > > > imx8mm_beacon and imx8mm_evk, respectively.
> > > > > >
> > > > > > Note also that I sent a series[1] which allows the symbols-base
> > > > > > to be adjusted, if that helps.
> > > > >
> > > > > I've seen them - but not yet tested.
> > > > >
> > > > > Thanks Simon for the patch series.
> > > >
> > > > Is it still broken with this patch series? I have been traveling and
> > > > haven't had much time to test.
> > >
> > > Yes, I can confirm that it is still broken.
> >
> > Sorry for the delay. I had to return my 8MM to Beacon, and I was
> > waiting for a replacement.
> >
> > To not prolong it anymore, I decided to try it with an 8M Nano, and I
> > got a boot failure on master. I was able to successfully boot
> > 2024.01-rc5, but I haven't had time to bisect it yet. I'll try to do
> > that this week. I think once we can bisect the error, it might become
> > more apparent.
>
> Git bisect narrowed down the git which broke the build:
>
> commit 37e50627efacd8dae18b564e9d8886a033e181bc (HEAD)
> Author: Marek Vasut <marex at denx.de>
> Date: Fri Apr 26 01:00:37 2024 +0200
>
> ARM: dts: imx: Convert i.MX8M flash.bin image generation to binman
>
> I am guessing the binman isn't prepending the header stuff. I'll try
> to investigate it this week.
Despite being tired (and having a little wine), I couldn't put this down.
The working version appears to have a sequence that starts at 0x1000:
00001000 d1 00 20 41 00 20 91 00 00 00 00 00 00 00 00 00
The same sequence on the non-working version has the same sequence at
a different offset:
000005c0 d1 00 20 41 00 20 91 00 00 00 00 00 00 00 00 00
I think the offset needs to be fixed. I tried the following patch,
but I am now getting some i2c clock failures, so I need to investigate
further:
diff --git a/arch/arm/dts/imx8mn-u-boot.dtsi b/arch/arm/dts/imx8mn-u-boot.dtsi
index 6875c6d44f..91fc67099c 100644
--- a/arch/arm/dts/imx8mn-u-boot.dtsi
+++ b/arch/arm/dts/imx8mn-u-boot.dtsi
@@ -117,7 +117,9 @@
nxp,rom-version = <2>;
nxp,loader-address = <CONFIG_SPL_TEXT_BASE>;
args; /* Needed by mkimage etype superclass */
-
+#ifdef CONFIG_FSPI_CONF_HEADER
+ offset = <0x1000>;
+#endif
section {
filename = "u-boot-spl-ddr.bin";
pad-byte = <0xff>;
Wtih the above patch, SPL tries to execute:
U-Boot SPL 2025.01-rc1-g6ebfafe8c532-dirty (Nov 03 2024 - 21:23:04 -0600)
Failed to get i2c clk
Once I can figure out the i2c clk issue, I can further test and/or
submit a patch with a fixes-tag.
adam
>
> adam
>
> >
> > adam
> >
> > >
> > > I've applied:
> > > https://patchwork.ozlabs.org/project/uboot/cover/20240826191143.426387-1-sjg@chromium.org/
> > >
> > > on top of mainline:
> > > SHA1: 1630ff26cc960439b5949b80cfc604a2c8aa47dd
> > >
> > > Adding symbols-base = <0>; to imx8mm-u-boot.dtsi did not help.
> > >
> > > >
> > > > adam
> > > > >
> > > > > >
> > > > > > Regards,
> > > > > > Simon
> > > > > >
> > > > > > [1]
> > > > > > https://patchwork.ozlabs.org/project/uboot/list/?series=421010
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Best regards,
> > > > >
> > > > > Lukasz Majewski
> > > > >
> > > > > --
> > > > >
> > > > > DENX Software Engineering GmbH, Managing Director: Erika Unter
> > > > > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> > > > > Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> > > > > lukma at denx.de
> > >
> > >
> > >
> > >
> > > Best regards,
> > >
> > > Lukasz Majewski
> > >
> > > --
> > >
> > > DENX Software Engineering GmbH, Managing Director: Erika Unter
> > > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> > > Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma at denx.de
More information about the U-Boot
mailing list