Successful data recovery of broken eMMC chip MCU1

[rooter]

Thank you TMC.

Use info from my site all you like, all that's needed is attribution, going to the ethos of open-source.

whitex, you'd exposed not only yourself to civil and criminal penalties, but also potentially TMC as well. You're lucky I noticed them first.

 

[CR3P]

Here is another (and less expensive) alternative to the Multi-Com people :
Tesla Model S damaged eMMC / MCU files recovery service, certificates and keys. | eBay

 

[elmachin]

Does anyone in the Phoenix area have an eMMC reader that I could borrow? I can't find a reader with less than 3 week lead-time for delivery

 

[elmachin]

What are the advantages/disadvantages of reading the eMMC as MMCBLK* vs SD*?

Are there more tools to fix major issues with eMMC corruption if it is enumerated as eMMC or is a SCSI SD* backup and write to the new chip an invalid method altogether using @rooter instructions because the kernel handles the dd differently for MMCBLK* vs SD*?

 

[rooter]

elmachin, the only reason you'd see the device as a scsi device as opposed to an NVM device is if your operating system has that inclination. I run CentOS exclusively so it's an mmcblk device.

There is no difference in the operation of the tools and they'll work either way.

 

[stiffler]

The smartest way to get eMMC dump would be to put tegra in USB recovery (RCM/APX) mode and send a payload.

Hi. I have been searching for information about downloading tegra in recovery mode for a long time, but there is too little information. Did you do this?
Or did anyone run it in recovery mode? I'm willing to pay for information and help.
Thanks.

 

[rooter]

Sid (not his real name, aka FuzzyBabyDucks) has done it but it's not stable. He once agreed to let me publish, but then reconsidered and decided to sell retail (TonyT) once stabilized. Both now deny this happened, but take it for what you will.

I believe that the Fusee Gelee endeavor was dropped once it was discovered that the boot flash can be accessed directly, but I don't have any details on that since I have to figure out everything on my own. Just no time for that.

 

[stiffler]

Sid (not his real name, aka FuzzyBabyDucks) has done it but it's not stable. He once agreed to let me publish, but then reconsidered and decided to sell retail (TonyT) once stabilized. Both now deny this happened, but take it for what you will.

I believe that the Fusee Gelee endeavor was dropped once it was discovered that the boot flash can be accessed directly, but I don't have any details on that since I have to figure out everything on my own. Just no time for that.

I read your wiki, a lot of work has been done, it's cool!

 

[Plasmid_Boy]

Sid (not his real name, aka FuzzyBabyDucks) has done it but it's not stable. He once agreed to let me publish, but then reconsidered and decided to sell retail (TonyT) once stabilized. Both now deny this happened, but take it for what you will.

I believe that the Fusee Gelee endeavor was dropped once it was discovered that the boot flash can be accessed directly, but I don't have any details on that since I have to figure out everything on my own. Just no time for that.

This story reminds me of the bulletin boards where we used to share computer codes as kids. Then People tried to make money from the it. Not judging, but it was fun when everyone was trying to figure things out and sharing what they have found.

 

[rooter]

This story reminds me of the bulletin boards where we used to share computer codes as kids. Then People tried to make money from the it. Not judging, but it was fun when everyone was trying to figure things out and sharing what they have found.

Yup, I remember those days. And that's what Open Source is all about.

Check that, Open Source is about Science.

I don't care what the Cool Kids are doing. I share. And learn.

 

[whitex]

What are the advantages/disadvantages of reading the eMMC as MMCBLK* vs SD*?

Are there more tools to fix major issues with eMMC corruption if it is enumerated as eMMC or is a SCSI SD* backup and write to the new chip an invalid method altogether using @rooter instructions because the kernel handles the dd differently for MMCBLK* vs SD*?

If you have a USB reader like the Allsocket USB3, it presents the eMMC chip to your OS (regardless of which OS - Windows, Linux, Mac, other). This limits you to only be able to read and write blocks because the OS just sees it as a block device (Linux will show it as a SCSI device). If you have an SD Allsocket reader and you plug it to an MMC slot (SD slot which is SDIO capable usually is a native MMC controller), the OS sees the chip as an eMMC device, therefore you can issue raw MMC commands, read/write MMC registers, access boot partition and/or RPMB partition, enable/disable block size emulation or write protect, access any controller-firmware-specific functionality, or even perform one time programmable operations such as reconfigure the chip to "reliable mode" (a.k.a. pSLC mode). If you have an eMMC reader with SD interface but sill just see a SCSI device, the SD reader you are using is likely abstracting MMC as a generic storage device. Typically USB SD readers will do that. Look for SDIO capable reader (often PCIe card, or built-in laptop SD readers) if you want to access MMC specific functionality.

dd should work the same on MMC or scsi device.

 

[stiffler]

I believe that the Fusee Gelee endeavor was dropped once it was discovered that the boot flash can be accessed directly, but I don't have any details on that since I have to figure out everything on my own. Just no time for that.

Is there a tegra t30 on Board the mcu? I have met internal recovery tools from nvidia L4T or Txx Recovery Mode (taradex). Is this the right way or am I looking for the wrong?

 

[rooter]

It's a Tegra 3 daughtercard on the MCU mainboard. (the "CID", no, not the FSB) The CID daughtercard started life as a VCM module, but signals and power were moved around specifically for Tesla's custom card.

It's pretty easy to get the Tegra into normal recovery mode... the trick though is to get it into pre-recovery mode during the boot co-processor's init phase, essentially the boot coprocessor's 'BIOS'. Fusee Gelee injects a payload to smash the stack, which drops the coprocessor into this mode. You can include in the payload a shell if you like.

The idea is to get into this mode, to turn off code-signing. Code-signing checks the firmware of every ECM in the car except the gateway. Init code in the CID's Spansion chip absolutely must match the firmware in the eMMC, or else black screen -- the T3 fails to boot due to code-signing.

The goal is to be able to change the firmware in the Spansion chip, which would allow backdating firmware to any version you want. It appears though that there is an easy way to get at the Spansion's firmware, eliminating the need for Fusee Gelee. I'm not in a position to say more as it's not my work.

 

[Zuikkis]

Hi!

has anyone tried if it's possible to program the chip "on board", using same wire connections as shown here for reading?

The reading part looks really easy, and also I have access to BGA rework soldering station so I think I could successfully replace the chip as well. But cheapest BGA153 programmer costs ~$100 and for one time use that seems a bit unnecessary investment. So can I just solder the new eMMC chip without programming, and then write the contents on board?

 

[whitex]

Hi!

has anyone tried if it's possible to program the chip "on board", using same wire connections as shown here for reading?

The reading part looks really easy, and also I have access to BGA rework soldering station so I think I could successfully replace the chip as well. But cheapest BGA153 programmer costs ~$100 and for one time use that seems a bit unnecessary investment. So can I just solder the new eMMC chip without programming, and then write the contents on board?

If you can read it in-system, you should be able to write it using the very same setup - the physical interface is shared for reading and writing.

 

[Zuikkis]

If you can read it in-system, you should be able to write it using the very same setup - the physical interface is shared for reading and writing.

That's what I figured. Yet it seems that most people just read the chip that way, then program the new one in programmer before soldering..

 

[whitex]

That's what I figured. Yet it seems that most people just read the chip that way, then program the new one in programmer before soldering..

Probably because it's faster that way. First, when putting on a BGA, your wires for in-system will likely have to be re-soldered. Second, often the in-system programming is a slower rate, due to signal integrity (loose hanging wires), and possibly not the entire data bus wired out (the chip can work using narrower data bus, but it's proportionally slower). If you have it working via the USB 2.0 recovery port (requires some more advanced hacking), it would still be slower than a write through a programmer (half speed or less for a performance chip) but it would avoid soldering fly-wires and playing with voltages to power up the emmc chip but not the Tegra. If you're doing a one-off, it may be worth the $100 saved to spend the extra time, when doing more than one, probably not. Personally I went with the programmer because I wanted to skip the in-system hacking (probably lost some data during desoldering though ) - see some of my lessons learned here.

 

[Zuikkis]

Probably because it's faster that way. First, when putting on a BGA, your wires for in-system will likely have to be re-soldered. Second, often the in-system programming is a slower rate, due to signal integrity (loose hanging wires), and possibly not the entire data bus wired out (the chip can work using narrower data bus, but it's proportionally slower). If you have it working via the USB 2.0 recovery port (requires some more advanced hacking), it would still be slower than a write through a programmer (half speed or less for a performance chip) but it would avoid soldering fly-wires and playing with voltages to power up the emmc chip but not the Tegra. If you're doing a one-off, it may be worth the $100 saved to spend the extra time, when doing more than one, probably not. Personally I went with the programmer because I wanted to skip the in-system hacking (probably lost some data during desoldering though ) - see some of my lessons learned here.

Thanks for you reply! You are probably right. Also in-system seems to be a bit unreliable, you will have to re-read the data to make sure it was written ok, which then makes it even slower.

I don't have big eMMC problems yet, but the car is 2013 and the chip is original so it's likely to fail. I thought I'd at least try to backup the current data (vpn keys) before it fails..

 

[requin]

Init code in the CID's Spansion chip absolutely must match the firmware in the eMMC, or else black screen -- the T3 fails to boot due to code-signing.

Several times I installed the firmware in eMMC different from Spansion chip. The screen worked and started up. Sometimes a alert - "software required". After the redeploy - ok.

 

[requin]

Several times I installed the firmware in eMMC different from Spansion chip.

above version