Hello,
I have created a Linux image with a huge amount of project specific tweaks & modifications for a customer. Now that customer runs into the problem that newer Jeton TX2 (regular 8GB model) seem to have a different memory chip which isn’t supported by the bootloader from L4T 32.2.1. Can I solve the problem by simply copying the bootloader from 32.4.4 over the bootloader 32.2.1?
Upgrading the entire package would involve a huge amount of work which doesn’t add any value to the customer so I have to keep the amount of work to get the newer modules going to an absolute minimum.
I don’t know if the one version would work with the other. However, direct copy would not work since there is a signature for the bootloader partition, and I doubt the signature on one partition of a different TX2 would work when applied to the other TX2 (the non-rootfs partitions started being signed in the R32.x series).
Someone else would have to answer about the memory chip. It is true that early boot stages “train” RAM during boot, but this starts prior to U-Boot. The RAM would be part of the module, and not the carrier board, and so I’d think any flash software provided by NVIDIA would work with any of the R32.x boot content. It seems more likely there is a device tree problem, especially if this is for a third party carrier board. Are you using the dev kit carrier board?
If you have any way of posting a serial console boot log it would help since only the serial console can show boot stage logs prior to the Linux kernel running. If not possible, then you should provide any detail you can about what the boot error is.
With copying the bootloader I mean copying the bootloader directory from the newer L4T package to the older L4T package (and rebuild image / flash after that).
Meanwhile I have tried that but it doesn’t work. I get an error saying ‘Stat for RECFILE failed’ when I try to flash the image (after building a new image). As an alternative I simply copied the binaries from the newer bootloader directory and memory configuration file from BCT into the existing bootloader. That seems to work OK for an older module; my customer is going to test a newer module.
The situation is that my customer bought a new batch of TX2 modules for an existing product (using a custom carrier board) and suddenly they can no longer flash the modules like they used to do. According to their supplier the new batch of TX2 modules contains a different type of DRAM memory which is not supported by an older bootloader version. When checking the files I noticed there is a new memory chip defined in the BCT configuration file for the TX2.