Write MB1 without affecting other data?

[riz94107]

We were having some issues with changes in carrier boards that necessitated making changes to the pinmux at boot time; those changes were successful and when we flash new devices they properly take effect.

However, we have a large number of devices which we have already flashed with the old pinmux, and they are in various stages of production deployment; I’m hoping I can find the MB1 image which is flashed successfully and just write that to the appropriate partition to fix the problem we’re having - ideally, from the device itself booted under Ubuntu. I’m fairly sure it’s just a matter of combing the flash logs to find the data which was generated, then writing that data to the correct partition on mmcblk0 - however, the flash logs are huge and cryptic, and I’m hoping someone can point me to the generated data blob and which partition it should be written to.

Our Jetson Xavier NXs are running R35.4.1, in case it matters, and I used the NVidia-provided tools/kernel_flash/l4t_initrd_flash.sh script for flashing. I’ll keep digging, but if someone knows the answer, it’ll likely save me some time. :)

Thanks,
+j

[riz94107]

Poking around a little more, it looks like it’s no longer possible to access the QSPI flash from a booted system, is that correct? So what I’m hoping to do is actually impossible, since MB1 and friends need to be written to /dev/mtd0 - and a modprobe qspi_mtd does not actually appear to cause that device to be mounted.

[KevinFFF]

Hi riz94107,

@riz94107

We were having some issues with changes in carrier boards

Are you using the custom board for Xavier NX?

@riz94107

we have a large number of devices which we have already flashed with the old pinmux, and they are in various stages of production deployment;

Do you want to perform something like OTA for those remote devices?
If so, you can consider to perform capsule update or image-based OTA for this use case.