L4t_generate_soc_bup.sh missing FAB value '000' for NX production SOM

We did an early production build where NX production SOMs had a FAB value of ‘000’. l4t_generate_soc_bup.sh does not contain an entry with this FAB value for the jetson-xavier-nx-devkit-emmc section in the t19x_spec.

FAB=100 BOARDID=3668

Use this.

We are using a custom distribution with a yocto build utilizing meta-tegra. If we do not include the ‘000’ FAB value in the bup gen specs we get this error when running tegra-bootloader-update from our swupdate OTA update process:

Installing NVIDIA bootloader update payload
Status: 4 message: ERROR : Error: missing entries for partitions: bpmp-fw-dtb, bootloader-dtb, VER, mb1, BCT, MB1_BCT, MEM_BCT, kernel-dtb
Status: 4 message: ERROR :        for TNSPEC 3668-000-0001-F.0-1-2-jetson-xavier-nx-devkit-emmc-mmcblk0p1
Status: 4 message: ERROR : ERR: bootloader update failed

We’ve modified our build to include this additional FAB value so we’re not stuck on anything. Just passing along in case this should have been added to l4t_generate_soc_bup.sh in the L4T release and to confirm that it is expected and OK to have seen this FAB value in production modules.

What is the exact error you have here?

It sounds like you have modified lots of things. Can you summarize all the modifications you have done?

Did you even change the partition layout?

Sorry, I forgot that tegra-bootloader-update is not an NVIDIA tool and comes from here:

It replaces nv_update_engine. All the ‘missing entries for partitions’ is because it didn’t find a matching TNSPEC for the ‘000’ FAB value which is corrected by updating our build with the missing FAB value. If I were to use the standard NVIDIA tooling and distribution I’m not sure whether a similar error would have been encountered. Our partitioning is standard although we have modified it to include a redundant rootfs partition.

The intent of the original post is just to highlight that there appears to be an early production FAB value floating around out there which was not included in the tooling in the L4T release.

Actually, I am not able to change anything and check your issue if you are using a non-NV tool shared by other developers.

If you are talking about you have some modules with FAB 000, may I ask how did you know that module has FAB 000?

Did you ever check the eeprom value inside module for that?

tegra-eeprom-tool reports the following for the part number:

partnumber[nvidia]: 699-13668-0001-000 F.0

Actually, here is a hexdump straight from the eeprom driver:

00000000  01 00 fc 00 54 0e 01 00  00 46 00 00 00 00 00 00  |....T....F......|
00000010  00 00 00 00 36 39 39 2d  31 33 36 36 38 2d 30 30  |....699-13668-00|
00000020  30 31 2d 30 30 30 20 46  2e 30 00 00 00 00 00 00  |01-000 F.0......|
00000030  00 00 ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000040  ff ff ff ff 57 15 3b 2d  b0 48 31 35 36 30 39 32  |....W.;-.H156092|
00000050  31 30 30 30 36 33 37 00  00 00 00 00 00 00 00 00  |1000637.........|
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000090  00 00 00 00 00 00 4e 56  43 42 1c 00 4d 31 00 00  |......NVCB..M1..|
000000a0  ff ff ff ff ff ff ff ff  ff ff ff ff 57 15 3b 2d  |............W.;-|
000000b0  b0 48 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |.H..............|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000000f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 5b  |...............[|

Hi,

We’ve confirmed that such module shall not have problem in doing BUP update if it is official system (>=32.5.1) and with official tool.

OK, thank you!