search

Freescale / meta-freescale

Layer containing NXP hardware support metadata
Other
166 stars 252 forks source link

Restore default bootloader to untagged version #1791

Open thochstein opened 4 months ago

thochstein commented 4 months ago

The introduction of the UUU-tagged bootloader causes problems for the non-wic case, as reported here [1] and here [2].

[1] https://github.com/Freescale/meta-freescale/pull/1762 [2] https://github.com/nxp-imx/mfgtools/issues/416

This PR is an attempt to improve the original feature by limiting the use of the tagged file to the wic case, while restoring the default file back to the untagged version. This does effectively revert [1] as no longer needed.

thochstein commented 4 months ago

Hi @hiagofranco, this PR does revert the addition of UUU_BOOTLOADER_UNTAGGED as no longer needed. Does this break you? Can you adjust?

hiagofranco commented 4 months ago

Hi @hiagofranco, this PR does revert the addition of UUU_BOOTLOADER_UNTAGGED as no longer needed. Does this break you? Can you adjust?

Hi @thochstein, thanks for letting me know, this will break our one of our layers where we are using ${IMX_BOOT}-untagged binary, but I can fix it on our side to get the imx-boot instead once this PR is merged. Please let me know if you want to backport this to kirkstone as well, so I will have to fix our kirsktone branch too.

hiagofranco commented 22 hours ago

Hi @thochstein and @otavio, sorry for the delay here, I was out last week.

So, the whole issue happens when we are using UUU to download the binary directly into RAM, as we do here at Toradex with Tezi. We put the SoC into recovery mode and then download the boot container and jump to it. UUU sends 40 bytes size packages if I am not wrong, therefore if we are unlucky enough (which happened to us) to have the binary size at an specific value (more info below), the last package will contain only the TAG and, because of that, U-Boot will start before the last package is transmitted, causing UUU to hang forever.

Here is the full issue we described to mfgtool repo: https://github.com/nxp-imx/mfgtools/issues/416

NXP reported they opened a ticket internally, but I am not sure what it is the status here.

Anyway, if we are going to do changes, we need to make sure the untagged binary is deployed, and we can choose between them, because this tag will cause issues. And about upstream/downstream, actually this tag is only add here at uuu_bootloader_tag.bbclass file, so if you compile u-boot manually it should always work with UUU as far as I remember.

Thanks!

thochstein commented 18 hours ago

NXP reported they opened a ticket internally, but I am not sure what it is the status here.

This is the result of that ticket ;-)

Anyway, if we are going to do changes, we need to make sure the untagged binary is deployed, and we can choose between them, because this tag will cause issues.

I believe this PR satisfies this by restoring the default binary to be the untagged one.

Will the user wonder though which version to use and perhaps still make a mistake by selecting the tagged one? I wonder if uuu can detect the trailing UUUBURN tag and handle the potential problem better?

hiagofranco commented 1 hour ago

This is the result of that ticket ;-)

Ah cool, thanks =)

I believe this PR satisfies this by restoring the default binary to be the untagged one.

All right, with the untagged binary being deployed, we can simply use it, so no problems for us.

Will the user wonder though which version to use and perhaps still make a mistake by selecting the tagged one? I wonder if uuu can detect the trailing UUUBURN tag and handle the potential problem better?

Hmmm, what happens if there is no tag and you want to flash this binary? IOW, is this tag really needed by UUU? Or is this something the boot ROM needs?