PCN 206440 states that
In order to support the new Micron DRAM and Hynix eMMC, the software image flashed to the Jetson TX2 must include:
• Appropriate BCT and DVFS changes required by the Micron memory device
• Updated bootloader implementing updated OCR register polling timeout per JEDEC specification
We are using JP3.3.3 L4T28.4 to clone TX2 with part number ending in D00 with the following cmds for production.
sudo ./flash.sh -r -k APP -G system.img jetson-tx2 mmcblk0p1
sudo ./flash.sh -r jetson-tx2 mmcblk0p1
Recently we were made aware of the D02 and D12 part numbers, and before we realised it, we were cloning —>from a D00 TX2 to a D02 TX2 and subsequently
from D02 TX2 to a D12 TX2 and
from D12 TX2 to a D02 TX2.
As a result some of the TX2, the V4L2 video images are corrupted after running the tx2 and it happens randomly. In one particular tx2, we were able to replicate the issue reliably when the cpu temperature crosses 50 degrees Celcius.
My question is whether the cloning cmds we used would actually apply the changes required by the PCN 206440 for D02 TX2. If it doesn’t, it is probably the reason why we are facing corrupted images from V4L2. What should I do if this is the case?
The other reason could be cloning D12 TX2 to D02 TX2 since D12 TX2 requires JP4.6.3 as mentioned in PCN 209140.
-max
Sorry that I don’t get your question. So where did you clone it out and where do you back up it?
Couple of years back, I prepared a TX2 (699-83310-1000-D00) flashed with JP3.3.3 L4T28.4 and I downloaded the image (lets call this img_A) using cmd >sudo ./flash.sh -r -k APP -G system.img jetson-tx2 mmcblk0p1.
This is the master copy and i use it to clone using cmd >sudo ./flash.sh -r jetson-tx2 mmcblk0p1 it to other TX2s (699-83310-1000-D00).
As mentioned, I have gotten some of the 699-83310-1000-D02 and 699-83310-1000-D12. I cloned them with the same image done couple of years back. This is how i ended up with with D02 and D12 TX2s with an image (img_A) downloaded from a D00 TX2.
I was also setting up a new PC to perform the cloning procedure, and i used this D12 TX2 to download a new image (lets call this img_B). Using this PC I cloned a couple more TX2 which is how i ended up with a D02 TX2 with an image downloaded from D12 TX2.
So now i have this mixed bag of img_A and img_B on D02 TX2s, i wonder if this could have caused the V4L2 image corruption issue i am facing now.
When i checked the TX2s (D00,D02,D12) with the cmd cat /etc/nv_boot_control.conf
All of them reported D00.
-max
So which modules have the V4L2 issue now? D02 only? D12 only? or both ?
Have you tried direct flash instead of doing cloning to confirm if this issue really related to clone?
The PCN change actually happened in bootloader part and bpmp. APP partition clone shall not get affected.
I have not tried direct flash to D02. I will try this suggestion.
I found this post Clone TX2 with custom kernel
where sudo ./flash.sh -r -k APP jetson-tx2 mmcblk0p1 was used instead of sudo ./flash.sh -r jetson-tx2 mmcblk0p1. does the -k APP do anything different?
-max
The whole flash process flashes many partitions.
-k means you only want to flash that specific partition.
-k APP here means you only flash the APP partition and APP partition only has the rootfs /system.img.
Other partitions have bootloader related software and they didn’t get flashed here.
You would notice if you run with -k then the flash process is faster because it didn’t flash the whole board.
Hi Wayne,
I found the cause to be not related to the cloning. As mention only the APP partition is copied during cloning.
In my custom hardware, the HDMI circuit was unpopulated in a production change to reduce cost. This caused the TX2 HPD pin to be floating. I think this caused the TX2 to think that an HDMI cable is being connected or disconnected as the temperature crosses 50 degree Celsius, and the i2c error messages appeared in dmesg.
[ 144.466899] tegra-i2c 3190000.i2c: rx dma timeout txlen:28 rxlen:128
[ 144.466912] tegra-i2c 3190000.i2c: — register dump for debugging ----
[ 144.466926] tegra-i2c 3190000.i2c: I2C_CNFG - 0x22c00
[ 144.466937] tegra-i2c 3190000.i2c: I2C_PACKET_TRANSFER_STATUS - 0x10001
[ 144.466949] tegra-i2c 3190000.i2c: I2C_FIFO_CONTROL - 0x1c
[ 144.466959] tegra-i2c 3190000.i2c: I2C_FIFO_STATUS - 0x800040
[ 144.466970] tegra-i2c 3190000.i2c: I2C_INT_MASK - 0x6c
[ 144.466981] tegra-i2c 3190000.i2c: I2C_INT_STATUS - 0x2
[ 144.467025] tegra-i2c 3190000.i2c: i2c transfer timed out addr: 0x50
Once i tied the pin to logic high 1.8V i managed to stop the i2c errors and solved the issue i have been experiencing all along.
Maybe it was just coincidence, that the D00 was worked ok with the HDMI circuit unpopulated, but the D02 had issues.
-max