Imx-usb-loader broken on IMX8MP/v2022.09.0

Imx-usb-loader broken on IMX8MP/v2022.09.0

[Hans Christian Lønstad]

This is observed using straight out of the box v2022.09.0 on NXP IMX8MP Eval kit:

---------

$ sudo ../drimx8/scripts/imx/imx-usb-loader ../drimx8/images/barebox-nxp-imx8mp-evk.img 
[sudo] password for hcl: 
found i.MX8MP USB device [1fc9:0146]
4 in err=-9, last_trans=0  00 00 00 00
status failed

————

Stripping off the header gap (32K) allows the binary to load using the standard NXP uuu (Ubuntu 22.04) utility,.

This further raises the question: Why have a header gap at all?

The makes sense for SD card loading, but not for eMMC boot partitions where ROM expects code to start at 0.
Maybe better just use a seek to put the code at the relevant position on the SD card?

For instance, I am using the Rauc boot loader slot update mechanism expecting no gap thus  requiring me to shave of 32k
prior to shipping.

Comments??

Hans Christian

Re: Imx-usb-loader broken on IMX8MP/v2022.09.0

[Ahmad Fatoum]

Hello Hans,

On 17.09.22 13:04, Hans Christian Lønstad wrote:
> This is observed using straight out of the box v2022.09.0 on NXP IMX8MP Eval kit:
> 
> ---------
> 
> $ sudo ../drimx8/scripts/imx/imx-usb-loader ../drimx8/images/barebox-nxp-imx8mp-evk.img 
> [sudo] password for hcl: 
> found i.MX8MP USB device [1fc9:0146]
> 4 in err=-9, last_trans=0  00 00 00 00
> status failed

I just tested and have the same issue on i.MX8M Nano, which uses
the same new SDPS protocol. I've just sent out a potential fix.

> ————
> 
> Stripping off the header gap (32K) allows the binary to load using the standard NXP uuu (Ubuntu 22.04) utility,.
> 
> This further raises the question: Why have a header gap at all?
> 
> The makes sense for SD card loading, but not for eMMC boot partitions where ROM expects code to start at 0.

The realization that the eMMC boot partition usually lacks an on-disk partition
table came quite late to the NXP BootROM authors. On i.MX8M Mini, we still have
an offset for both SD-Card and eMMC boot partition.

> Maybe better just use a seek to put the code at the relevant position on the SD card?

imx-usb-loader does the correct thing and skips to the relevant position.
barebox_update should do the correct thing and skip over the header.

> For instance, I am using the Rauc boot loader slot update mechanism expecting no gap thus  requiring me to shave of 32k
> prior to shipping.

This is unfortunate, but I don't think this is something we should address at the
barebox side. barebox images for i.MX are always meant to be directly written
to an SD-Card at offset 0.

For RAUC integration, you may consider having your build system shave off the
bytes transparently. See for example:

https://github.com/rauc/meta-rauc/commit/8e049699f05483b694e6c5a3e260cd9e0fe58d2e

which does the inverse operation: pad U-Boot for older i.MX, so they are install-able
into an eMMC boot partition.

Cheers,
Ahmad

> 
> Comments??
> 
> Hans Christian
> 


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: Imx-usb-loader broken on IMX8MP/v2022.09.0

[Info Skymem]

Hi,
thank you for your information.

On our website you can find email addresses of companies and people.
https://www.skymem.info

In short, it’s like Google for emails.

Best regards,
Robert,
Skymem team

On Tue, Sep 27, 2022 at 7:45 PM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>
> Hello Hans,
>
> On 17.09.22 13:04, Hans Christian Lønstad wrote:
> > This is observed using straight out of the box v2022.09.0 on NXP IMX8MP Eval kit:
> >
> > ---------
> >
> > $ sudo ../drimx8/scripts/imx/imx-usb-loader ../drimx8/images/barebox-nxp-imx8mp-evk.img
> > [sudo] password for hcl:
> > found i.MX8MP USB device [1fc9:0146]
> > 4 in err=-9, last_trans=0  00 00 00 00
> > status failed
>
> I just tested and have the same issue on i.MX8M Nano, which uses
> the same new SDPS protocol. I've just sent out a potential fix.
>
> > ————
> >
> > Stripping off the header gap (32K) allows the binary to load using the standard NXP uuu (Ubuntu 22.04) utility,.
> >
> > This further raises the question: Why have a header gap at all?
> >
> > The makes sense for SD card loading, but not for eMMC boot partitions where ROM expects code to start at 0.
>
> The realization that the eMMC boot partition usually lacks an on-disk partition
> table came quite late to the NXP BootROM authors. On i.MX8M Mini, we still have
> an offset for both SD-Card and eMMC boot partition.
>
> > Maybe better just use a seek to put the code at the relevant position on the SD card?
>
> imx-usb-loader does the correct thing and skips to the relevant position.
> barebox_update should do the correct thing and skip over the header.
>
> > For instance, I am using the Rauc boot loader slot update mechanism expecting no gap thus  requiring me to shave of 32k
> > prior to shipping.
>
> This is unfortunate, but I don't think this is something we should address at the
> barebox side. barebox images for i.MX are always meant to be directly written
> to an SD-Card at offset 0.
>
> For RAUC integration, you may consider having your build system shave off the
> bytes transparently. See for example:
>
> https://github.com/rauc/meta-rauc/commit/8e049699f05483b694e6c5a3e260cd9e0fe58d2e
>
> which does the inverse operation: pad U-Boot for older i.MX, so they are install-able
> into an eMMC boot partition.
>
> Cheers,
> Ahmad
>
> >
> > Comments??
> >
> > Hans Christian
> >
>
>
> --
> Pengutronix e.K.                           |                             |
> Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
>