Preventive eMMC replacement on MCU1

[borowanlan]

Read with Easy Jtag possible?

 

[tga]

My MCU1 still works fine, car is 2017 year, but I want to back it up just in case. Can anyone direct me to the proper and tested tool/equipment to read the eMMC while still soldered on. This can be done, right? Don't want to risk desoldering it before backing up even tho I have a reflow station!
I will appreciate a pinout pic/schematic on the tegra board to read the eMMC.

Someone correct me if I'm wrong, but I believe the eMMC backup without a NAND bootflash backup may have limited usefulness in the future, unless you reject any new updates after taking the backup. IIRC, the boot flash and eMMC versions must match. So a future update to both, followed by an eMMC failure and replacement with a part programmed with your old backup will leave you SOL with an unbootable MCU, unless you can find and burn a matching boot flash.

Are European cars not under an eMMC recall like US cars? If they are, I'd ignore it until it fails, then have Tesla fix.

 

[cloneguru]

Someone correct me if I'm wrong, but I believe the eMMC backup without a NAND bootflash backup may have limited usefulness in the future, unless you reject any new updates after taking the backup. IIRC, the boot flash and eMMC versions must match. So a future update to both, followed by an eMMC failure and replacement with a part programmed with your old backup will leave you SOL with an unbootable MCU, unless you can find and burn a matching boot flash.

Are European cars not under an eMMC recall like US cars? If they are, I'd ignore it until it fails, then have Tesla fix.

64mb nor flash can be backed up too… or ask someone here for a copy of a compatible version. While it needs to match versions, it’s not tied to a vin.

That being said… if you’re backing up your keys, you should probably back up the firmware (/dev/mmcblk0p1/2) and the nor flash (/dev/mtd0)

 

[cloneguru]

On a related topic... has anyone really dug into the 64mb NAND flash partitions and determined the layout of the environment partition #6 ?

 

[Zeemo]

On a related topic... has anyone really dug into the 64mb NAND flash partitions and determined the layout of the environment partition #6 ?

nice question i didnt know it has partitions xD

 

[cloneguru]

I think I have it mostly figured out

I’ll have to find my notes

From memory so don’t quote exactly:
Every update … it moved deadbeef to a new 4k block. Holds the boot partition, signature of the firmware on said partition, some size info, and I forget what else.

But if you do a hexdump and break it into chunks so the patterns repeat… it’ll make more sense. An image from a unit that has gone though a bunch of updates in its life will have more data points.

 

[cloneguru]

root@cid-5Yxxxxxxxx# cat /dev/mtd7 | xxd -p -c 128 | grep -v '^f*$' | sed 's/f*$//g' | grep '^efbeadde'
efbeadde02000000ff1f00ffffffffff40e01f3e40e01f3e78303700

0 Whole Device (all 64MB)
1 262144@0(bct)
2 131072@262144(pt)
3 1966080@393216(stage1_recovery)
4 1048576@2359296(stage2_recovery)
5 1966080@3407872(stage1_primary)
6 1048576@5373952(stage2_primary)
7 393216@6422528(env)
8 5242880@6815744(recovery)
9 27525120@12058624(kernel_a)
10 27525120@39583744(kernel_b)

efbeadde designates the active boot config... there should only be one line with that string.
02 says it's booting to the second firmware partition aka /dev/mmcblk0p2
ff1f00 I'm iffy on but believe it has to do with the verification status of the two firmware partitions and the map partition
40e01f3e40e01f3e78303700 relates to the verified firmware signature stored on /dev/mmcblk0p2

Please let me know if you find any of this to be inaccurate and/or can provide additional info.