iMX8MP: SDPS LIBUSB_ERROR_TIMEOUT due to UUUBURNXXOEUZX7 tag

[eghidoli]

We experienced failures of SDPS boot command for some sizes of binaries. It fails to load if the tag added by bitbake recipe meta-freescale/classes/uuu_bootloader_tag.bbclass to the bootloader binary is the only part sent by the last USB transmission. We think that the bootloader (U-Boot) is already started before the last transmission and the SDPS endpoint is no longer present (ROM is no longer executing) thus uuu fails. We solved it by keeping an untagged version of the binary and we use it for uuu.

I guess: since uuu already copes with this footer, probably to handle WIC images, should we use ScanTerm function to detect this footer at the end of binary and just remove it in ALL cases, in libuuu? As a side note: we already know that since MX8QXP uses a different approach to get container (flag ROM_INFO_HID_ROMAPI missing) and transmit size, it is not affected by this issue.

[eghidoli]

Relevant pull request in meta-freescale: https://github.com/Freescale/meta-freescale/pull/1764

[dolcini]

The issue can be reproduced with NXP i.MX8M Plus, when the loaded binary size is a multiple of 1020 bytes plus the UUUBURNXXOEUZX7 tag trailer that is added at the end.

[nxpfrankli]

Supposed default flash.bin should not have UUUBURNXXOEUZX7 tag. We want to keep " uuu flash.bin " as simple as possible.

[dolcini]

Supposed default flash.bin should not have UUUBURNXXOEUZX7 tag. We want to keep " uuu flash.bin " as simple as possible.

At the same time, we should ensure a good user experience IMO.

We did invest quite a lot of resources to debug this issue, because what is happening is that you do a code change in U-Boot, you rebuild, and suddenly, if you are unlucky, uuu start fails in very unexpected ways loading the new binary.

And this is happening exclusively on i.MX8MP (we tested i.MX8MM, i.MX8QM, i.MX8QXP, .... and those are not affected).

The trailer (or tag, whatever you want to call it), was initially added in meta-freescale [1] by your colleague @thochstein. Maybe you can have a sync between the two of you?

[1] https://github.com/Freescale/meta-freescale/commit/92acf99a6124df0d2e10bf10f296962ab9383ba1

[nxpfrankli]

Strange!, why our internal daily build have not such problem.

[dolcini]

Strange!, why our internal daily build have not such problem.

@nxpfrankli: the binary size needs to be a multiple of 1020 bytes plus the UUUBURNXXOEUZX7 tag, as I wrote in my previous comment.

[eghidoli]

I agree with @dolcini. Exactly, since the full tag is around 40 bytes it fails when: binarysize % 1020 <= 40 (sizeof tag starting from the first U)

[nxpfrankli]

Thanks. I submit tickt to internal yocto team to fix this problem.