I can explain what happened above in the update process from the recovery.txt log.
The new NBoot and new U-Boot are downloaded via UUU-Tool to RAM and are started. There in U-Boot, the same (new) NBoot and U-Boot are loaded to RAM again and also saved to eMMC. This is successful. So at this moment, the system is in a stable state and should be capable of restarting.
Please note that in this version, U-Boot is still stored in the User partition of eMMC. This is important because it is the reason why the next step fails.
Now the update command is started. This loads the emmc-fsimx8mp.sysimg and writes it to the User-Partition of eMMC. This also includes the section in the partition where U-Boot is located. So if sysimg either does not contain an U-Boot at all or if it holds a different version of U-Boot, then U-Boot is now overwritten by zeroes or with the different (old) copy of U-Boot, which does not match the installed NBoot. So when the update command ends, U-Boot is already corrupted in eMMC and restarting the system would already fail. But as you are in a working U-Boot in RAM, you do not see this right now. So booting Linux actually succeeds. But when trying to reboot later, NBoot (SPL) does not find a matching U-Boot version (or any U-Boot image at all) and fails to boot.
You could do the same restoration procedure again, just NBoot and U-Boot, not Linux! Then the system should be working again, because then the new U-Boot is again saved. But the main problem is that you must use the same U-Boot in your sysimg. Otherwise you will always kill U-Boot when saving the sysimg.
In the past, we sometimes changed some stuff in the boot process, either in NBoot or in U-Boot, so unfortunately NBoot and U-Boot were rather dependent on each other, so they needed to be more or less in sync. And the idea of storing U-Boot in the User partition also proved as problematic.
In the meantime, we have optimized the whole NBoot/U-Boot boot process quite considerably. Starting with the release in September 2023, U-Boot is now stored in the Boot partitions of eMMC, too, and is not part of the User-Partition anymore. Thus writing a new sysimg can not corrupt U-Boot anymore. There are also many other improvements in NBoot and the fsimage command in U-Boot, so we strongly recommend switching to the new release. From now on, NBoot and U-Boot are rather independend of each other, and updating NBoot will only be necessary in very rare cases.
Your F&S Support Team