Backing Up the Firmware

From Unofficial Tesla Tech
Revision as of 17:22, 26 April 2020 by Carl (talk | contribs) (→‎Foreward)
Jump to navigation Jump to search


So now you've successfully rooted your firmware and have access to your CID either through an Arduino Yun or whatever in the car from a switch, or over a VPN.

It is highly recommended to back up your firmware, either to the car's nanocomputer, your home LAN, or both. It is especially important to back up partitions 3 and 4 since they are specific to your car, and partition 3 is destined to wear out due to system logging.

I recommend backing up each partition, 1, 2, 3, 4, and then especially the whole flash. This latter is important as partition 1 does not start at the beginning of the flash. When you have to replace a burned-out flash it is necessary to lay down the whole image.

Needless to say, as you update firmware be sure to back it up. Never change firmware revs fro what you have using dd. If you restore a lower- or higher-rev partition 1 or 2, it will not match the boot flash (Spansion chip on the obverse of the CID) and the CID will not boot due to code-signing.


The first thing you should know is which is currently the -active- partition, 1 or 2? When logged in to the CID:

# cat /proc/mounts

... Either mmcblk0p1 or 2 will be mounted, and so that is your current active one. They switch with each firmware -update-.

The second thing you'll want to know is what is your current software version? (Hat tip to verygreen)

# cat /tesla/UI/bin/customerVersion.txt

This is on partitions 1 and 2.

Backing up is easy. I prefer to compress the backups to save bandwidth and disk space, but it's not necessary.

  • Log in as root to the CID.
  • Make sure the CID doesn't go to sleep. (Hat tip to wk057)

# sdv GUI_neverSleep true

# sdv GUI_sleepAtNight false

# sdv GUI_enableSleep false

# while :; do sleep 120 ; sdv GUI_lastTouchTime `date +%s` ; done &

  • Keep cid-updater out of the way:

# while true; do pkill cid-updater; sleep .5; done &

  • Now go to another terminal and log in to the CID, and you're free to make image copies:

# dd if=/dev/mmcblk0p1 bs=4M | gzip -1 - | ssh {user}@{dest. IP} dd of={dest. path}/mmcblk0p1.gz

# dd if=/dev/mmcblk0p2 bs=4M | gzip -1 - | ssh {user}@{dest. IP} dd of={dest. path}/mmcblk0p2.gz

# dd if=/dev/mmcblk0p3 bs=4M | gzip -1 - | ssh {user}@{dest. IP} dd of={dest. path}/mmcblk0p3.gz

# dd if=/dev/mmcblk0p4 bs=4M | gzip -1 - | ssh {user}@{dest. IP} dd of={dest. path}/mmcblk0p4.gz

# dd if=/dev/mmcblk0 bs=4M | gzip -1 - | ssh {user}@{dest. IP} dd of={dest. path}/mmcblk0.gz

Errors reading? Go here.

CAUTION: If you are doing this over VPN it will take forever and a day, and it could well glitch. Best to do this via wifi or hardwire. For the whole image I always pull at least two copies and do a sha256sum on each to make sure they're identical.

  • Properly reboot the CID to clear all your interference. (Hat tip to ce2078)

# emit-reboot-gateway

Exploring Your Images

Excellent, now you have the good backups you need. Let's examine them.

The individual partitions are easiest to mount so we'll start with them:
# mount mmcblk0p1.img /mnt

Then cd to /mnt and look around Remember that partitions 1 and 2 are the OS (in Tesla's peculiar configuration) and these partitions are uploaded to RAM (where the running OS is located) and mounted /usr in the running system. The various root directories are constructed from the cid-slash- directories. deploy is particularly interesting as it has the seed_artifacts_v2 subdir, which contains every firmware image for every Tesla car made. As part of the upgrade process to a new firmware, these subdirs are picked through to select the ones appropriate to your particular car, and staged in /var/cid-updater/staged.

Now umount /mnt and
# mount mmcblk0p3.img /mnt

This partition is mounted in the running system as /var. It's important to note that although the actual running OS is in RAM, partitions 3 and 4 are actually mounted to the non-volatile flash in the eMMC. So these partitions are where you keep persistent info like specifics of the particular car and so on. You'll notice many vital files in /var/etc, and of course /var/spool is where the firmware for the (16 or so) ECMs in your particular car are staged.

Now umount /mnt and
# mount mmcblk0p4.img /mnt

This partition is mounted /home in the running system, and again is persistent as it's mounted directly to the eMMC. Here is cid-updater/gateway-staging-work which has some interesting files. And your own user is here if you took measures to create one. If you'd expanded space in the eMMC for partition 4 as I recommend, here is where all that space is. Lots of room to play around.

Alternative to Having the Full Image


Use Wido's Image Building Script

widodh has made a script which will build a Tesla eMMC image for you. You must provide the firmware image for partitions 1 and 2 as the second argument, and then once his script is done, dd your own partitions 3 and 4 to the new image. Be sure that you first trim your firmware image. (the second argument)

# ./ ./{destination}.img ./{firmware saveset for parts 1 & 2}.img

The script will populate p1 and p2 of the total image with the firmware you specify, but p3 and p4 will be blank, so you must populate those with something like:
# dd if=mmcblk0p3.image of=/dev/mmcblk0p3 bs=4M
# dd if=mmcblk0p4.image of=/dev/mmcblk0p4 bs=4M

This works folks. I've used it.

There is a library of all known Tesla firmware versions. Maybe someone can front you your version from it if you need. But DO NOT TRY to change firmware versions from the one you originally had. Code-signing will bust you, and black screen as the Tegra won't boot. You can set partitions 1 and 2 to the same version, as long as it matches your last known version, as the Tegra boot coprocessor will check against what it has recorded in the Spansion flash chip.

Carl A. Cook