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!