How to use the 'dd' command to rewrite the BCT partition


We have the two kinds of TK1 board that with the different DDR type.
But those two DDR were made by Samsung.

For convenience, we define those boards as below:

board#1 : The TK1 with Samsung DDR#1
board#2 : The TK1 with Samsung DDR#2

My question is that if I used the configuration file of board#2 to re-flash the board#1 by NVIDIA’s flash tool, could we revert these changes at runtime?
Is it possible to write the good data in the system partition to repair the wrong flash?
We have an idea is that we access the partition at runtime and use ‘dd’ command to correct data. (i.e. : Use the ‘dd’ command on the device’s OS to rewrite the BCT partition)
But we don’t know which partition should be written.


Best Regards,

Something you might be interested in to help answer this is how the clone system works. On a TK1 the system is much more flexible than on the SoCs which come after this. You can clone and install individual partitions, or the eMMC as a whole. I don’t know which partition contains the RAM timing setup, but look closely at this, which was written for the TK1:

The TK1 has clone and restore operations available to it which the TX1 and newer do not have. In particular, understand this:

sudo ./nvflash --rawdeviceread 0 3849216 all.img --bl ardbeg/fastboot.bin --go

“fastboot.bin” is just used to create a bit of a micro support environment in the 3p server, e.g., it provides serial communications drivers, and does not remain after done with cloning.

Note that this uses raw bits from eMMC based on offsets and has no requirement for partitioning or file system types. This does what dd does, but does not require the TK1 to be bootable…it only requires recovery mode.

From this look at how partition naming can also be used. “all” is the entire eMMC, and if you were to clone “all”, and then use dd from your host on the “all” clone using the offsets where the partition table says a given partition exists, then clone of the individual partition would be a 100% bit-for-bit exact match of the dd of that part of “all”.

So the question is not whether the mechanism exists to fix the issue, the question is what do you have for a replacement partition? If you can determine that, then you can put it in place.

One complication is if the partition to be replaced is a different size. This can easily be worked around if you don’t mind some extra time required to do so.

Of particular importance is that you can have a backup copy before you experiment. If your partition to be tested is the same size as the partition to be replaced, then you can use dd or cloning to both read and write anywhere in eMMC you are interested in. Just make sure you have a copy of whatever you are altering, and that you protect that copy in case it isn’t what you want. If something goes wrong, then you can restore even if the Jetson won’t boot to Linux. Be sure to also clone the partition table (this is human readable text).

Hello linuxdev,

Because our customer flashed many devices with wrong configuration file and then sent those devices to their customer.

They do not like to use the NVIDIA flash tool to change the BCT partition data and prefer provide a simple way for the customer. So, we think maybe could use the dd command to copy the good data form BCT partition in ubuntu and then put the data into those devices with wrong configuration file.

But the most important thing is that we do not know where is BCT partition in ubuntu…
Or do you have another way to change BCT partition data without the flash tool?

Best Regards,

Looking at a flash log I see BCT is at least partially designated by “bootloader/flash.cfg”, and that in my R21.6 case the actual file used was:


Unfortunately I don’t know of a particular partition for the BCT. There is a chance it is stored in the starting bytes of the mmcblk0 disk and not within a specific partition.

The “bootloader/flash.cfg” tends to imply mmcblk0p2, but I’m uncertain as to whether I am interpreting the file correctly (the actual label under R21.6 is “DTB”, but the TK1 device tree ceased use within a partition after converting to U-Boot and dropping fastboot…that label may just be old baggage).

Would you happen to have a TK1 which you could purposely update incorrectly just like the customer did to experiment with? Being able to recreate what they did might help.

Would someone from NVIDIA be able to confirm if the BCT exists in a particular partition, or if instead it is in the leading bytes preceding the first partition?

I believe the following thread might answer this:
– Nicolas