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: Freescale/meta-freescale#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] Freescale/meta-freescale@92acf99

[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.

[hiagofranco]

Hi @nxpfrankli, I have a few questions about this u-boot tag. Is this really necessary to make the binary work with UUU or this is only for performance? In other words, could we drop this tag and add it only to increase the write performance with the .wic image?

Right now this tag ins only being added inside meta-freescale layer, therefore if we manually build this binary and use it, it will not have the tag. This is not an ideal case, since the Yocto binary and should be as close as possible to the manually build binary. My proposal would be to drop this tag for all binaries and, in case we need to increase performance, we document how to add this tag and the user decides if they want to add the tag or not.

[nxpfrankli]

u-boot tag was only used for extract boot-image from wic file. wic is raw image, layout like [MBR boot-image UUUTAG FAT EXT3(ROOTFS). uuu need tag information to get boot-image from big wic file. Some system have SPL or some pad data, which have not indicated in header meta information of boot-image. Yocto should only add UUUTAG after write boot-image into wic image. Yocto should have patch to fix your problem.