dunfell-l4t-r32.5.0: nv_update_engine doesn't work if TNSPEC is too long

[nielsavonds]

In our setup, the TNSPEC was 64 bytes long. Apparently, nv_update_engine is unable to cope with a TNSPEC longer than 63 bytes, probably due to some buffer overflow. This translates in failed updates showing the following log:

Device TN Spec: 3668-300-0000-B.0-1-2-jetson-xavier-nx-nobi-revision-a-mmcblk0p1
Can't find matching TN Spec in OTA Blob!

To Reproduce Steps to reproduce the behavior:

1. Create a MACHINE named jetson-xavier-nx-nobi-revision-a (or anything with similar or longer length)
2. Create a build based on the meta-tegra dunfell-l4t-r32.5.0 branch
3. Try to run nv_update_engine -i --no-reboot
4. See error "Can't find matching TN SPEC in OTA Blob!"

Suggestion I assume this is something out of your control, so I would suggest including a warning or error when building using a machine name that is too long, to avoid anyone else spending a lot of time trying to figure out what is going on. I would either create a separate function for this or put it in tegraflash_generate_bupgen_script. Something along the lines of:

    tnspeclen=$(expr length ${TNSPEC})
    if [ $tnspeclen -ge 64 ];
    then
        bbfatal "TNSPEC too long: ${TNSPEC} ($tnspeclen characters - max 63 characters)"
    fi

[ichergui]

Hey @nielsavonds Thanks for sharing this. I think we can add this check in the build time for safety, however, we are using the same/similar machine names as Nvidia have in Jetpack.

[madisongh]

We could issue a warning on any MACHINE name longer than 31 characters, since the rest of the fields+separators shouldn't be more than 32 characters; an earlier warning would be better, I think. But also including a check on the total length of the spec during BUP generation is also a good idea, just in case.

[madisongh]

I've also added a note about machine name length to the wiki page about creating a custom machine definition.