Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Successful data recovery of broken eMMC chip MCU1

This site may earn commission on affiliate links.
Looks like I can't edit previous posts, so I am sorry for the double post here.

Rooter said I stole his "method"

Here is the first communication we had together..

eVyEYCI.png



Without ever speaking to him, I apparently stole his idea to "downgrade." Then had it working with payloads before he managed to figure out where the USB port is...

Yet, I stole his work?
 
  • Helpful
Reactions: GWord
Well, now you have outed yourself. I have never given your nick. Nobody knew who you are until now.

And what you say here is in anger. My rooting and other methods are my original work because I was alone. I had to figure it out all by myself just like anyone else would have had to if I hadn't posted my articles, and no one does it like me. Your assertion about my hacking skills is made in anger; I've done and run enterprise systems infosec engagements for decades. Smears are beneath you (unless I misjudge you).

Your work on OpenPilot is unparalleled and superb. Unfortunately I can't use it because I already have Tesla's Autopilot. You're the only one to have worked out the Tesla-specific payload for FG. But, FG is useless without that custom payload and you know it.

Oh we all learn as we go along and the above post hardly indicts me. I was trying to learn -your- work in that post, and I'd never had a need to remove the mainboard. Oh sure I have the Fusee Gelee crack, and have said so recently... but it is useless without the payload specific to Tesla. That is what I do not have and is what you have declined to release. Fine, your choice.

But I've been talking about using FG for downgrade since it was first released by Kate. No, not as rooter, I've been banned here four times. And Yes it was my original idea, I've just never had the time to develop the payload. You say you don't have an arrangement with TonyT? Again you say this in anger because he told me otherwise. I depended on TonyT's very recent word that you are working with him on doing FG for downgrade but that you will not release it to him. So it was to be a cooperative service by you two. (maybe no more) Look, nobody has anything against you making money from your work. It would be a valuable service to some.

But yours is the tantrum, Sid. Don't go and be a Phil. (Or are you a Phil? Tell us now...) Think I'm just trying to talk you out of the payload? I don't need it and it would cost me time. Of course you would have gotten attribution as I told you so I wouldn't have gotten any credit. My interest is in broadening knowledge of the platform, and if I've offended you in the process, that's a shame. But now look at what you've done.

These facts remain incontrovertible:
- I am the first and only one to have shared rooting (and other significant) information which would never have been otherwise available to most. And no one has or uses the scripts I've posted unless they got them from my articles. My work is my original.

- I am in fact the first one to have worked out the eMMC repair. Way back when Phil had a stack of 20 or so MCUs with bad eMMC that he didn't know how to fix until I told him. (Is he working at Wendy's now?)

- I have never never released other peoples' private information or work without their specific permission, and will never.

So turn away from me if you like Sid. It's just a loss for everyone if you do. But like I told you in backchannel, I don't care whether you share with me or not, nor how this turns out. The only thing I care about is doing my housing development.
 
Last edited:
PS - Sid, I hope you will feel free to rebut the technical accuracy of anything I've written, anywhere.

But you can not just go flicking through saying I'm wrong. (unless you're just an angry/controlling person) You must provide alternate detailed information.

I am more interested in Truth, than selfish pride. I'm trying to do science here, and I think most others are too. Politics has no use for facts, and science has no use for politics..
 
But I've been talking about using FG for downgrade since it was first released by Kate. No, not as rooter, I've been banned here four times. And Yes it was my original idea, I've just never had the time to develop the payload. You say you don't have an arrangement with TonyT? Again you say this in anger because he told me otherwise. I depended on TonyT's very recent word that you are working with him on doing FG for downgrade but that you will not release it to him. So it was to be a cooperative service by you two.

If two people build the same thing independently, one did not steal the idea from the other. I worked on the original FG with the switch hacking group, so I would actually predate you there too..

Also, FG does not "just work" on a tesla MCU. It required almost a complete re-write and quite a few changes to backport it from the switch's processor - not just the payloads. This just goes to show your naivety on the matter as a whole.

TonyT is the the same root discussion group as I am, I talk about my work in there and bounce Ideas off people in it. Funnily enough, you were in it too at one point and left, and have been invited several times back as well. I "work with" plenty of people on FG if that's the metric you are going by and you could have been one of them!

But as he has told you.. He also has no access, so how am I providing a service to him or a cooperative service for others between us? Your logic doesn't add up.

Lastly, the reason why I don't take money is because I do this for fun and help people when they need help and everyone else wants to charge them thousands. It is purely at-will, and I don't want to turn people into customers and having them expect support and a level of service I don't feel like providing over my current job of running a start up - it will be too much work.

I also don't know how pride has anything to do with this, seeing how 99.999999% of people didn't know who I was before my last post. It wasn't until you dragged me through the mud that I decided to say something.

I built Fusee as a hobby, I have built many things as a hobby which I have not shared. My payloads are unstable and bricked several MCUs and I know if they were to be released, many more would be bricked because my gpio pinouts are not perfect & I would be blamed in addition to other, safer, root methods would get patched.

You have Fusee, You have full read/write/exec through fusee for whatever payload you want, you have a (safe) sample payload for dumping the SBK. Why not instead of crying about how I won't release unsafe payloads, you just sit down and build your own and release it publicly?
 
Last edited:
Thank you for the reasoned response.

No doubt that you had worked on FG early-on. When I was in the group you hadn't said a word though about using it to downgrade, and I did. Maybe it was something you had in mind so Ok.

I didn't know the work that had gone on to adapt FG per se but I tried to learn of it from you. What I remember is that you were tight-lipped, and sometimes verbally punished some of us who 'got out of line'. Well you're not always that way and I of anyone know the self-discipline needed, and the lack of respect I have for lazy and sloppy people. You mention yourself yelling at TonyT and I understand it... but when it becomes about power that is just not open-source. Rules are necessary, but are only effective with consent.

Yes I was grateful to be invited to the group and enjoyed the discussions, but dropped out with the move from Comma because I simply could not keep up with the volume of conversation and work. It is a pleasure to work with professionals, but I have a full-time job and a development business on the side. Y'all are doing good work; I tried to influence the ethos to sharing non-sensitive info but had little effect, so published some of what I've done. I've done alot more but just don't have time. We're all busy.

As to whether or how you're planning a downgrade service I only had the barest of details. And it's really none of my business. I regret bringing it up. But friend those bricks can be fixed. It likely involves unsoldering (or soldering wires around) the Spansion chip which holds the code for the boot coprocessor.

My mention of 'foolish pride' was not intended to be about you. Often to learn we have to look at extremes, and I was trying to illustrate my point clearly this way. You do have a dictatorial streak... but then so do I. It takes ten times the effort to move forward, as it does to stand still as most do.

Finally, I'm not 'crying' about anything. I am trying to move the needle. For example it would be nice if one of the group volunteered to provide firmware from the repository to civilian requests. Another example, I know nothing about MCU2 and above; I get requests all the time on MCU2 and above but nothing's been published. If someone bought me a car I'd do it, lol.

But I do know that when you have control over the hardware you have everything. This means that these should have the same faults and opportunities as MCU1. There is only one way I can think of that we could be locked out, and my history in satellite hacking indicates ways through that.

Whatever. Do what you like. I hope we can remain friends. Wish you the best with your enterprise.

Crap, I have 432 posts now. Past time for me to be banned...
 

Attachments

  • Spansion GL512S nvram.pdf
    1.5 MB · Views: 257
Last edited:
Sid has worked with me and helped me with many things however @rooter some of the things I said to you were taken out of context based on some of your own assumptions.

None of my eMMC work has been with Sid.

Downgrading is not been proven safe yet and that was not something I worked with Sid either.

Some of my ideas get a bit crazy when I test things with my car, Sid has always been helpful.
 
Thank you for the reasoned response.

What I remember is that you were tight-lipped, and sometimes verbally punished some of us who 'got out of line'. Well you're not always that way and I of anyone know the self-discipline needed, and the lack of respect I have for lazy and sloppy people. You mention yourself yelling at TonyT and I understand it...

...

But friend those bricks can be fixed. It likely involves unsoldering (or soldering wires around) the Spansion chip which holds the code for the boot coprocessor.
...
You do have a dictatorial streak... but then so do I.

Responding to these 3 parts.

1) One of the privileges I get from not accepting money and doing this in my spare time is that I can be honest, blunt, and myself. I will tell you if something is dumb. And I will definitely get upset at you if I tell you how to do something, and then you take shortcuts and **** it all up (looking at you Tony! Although you don't do that much anymore.)

2) Those bricks can't be fixed, they are GPIO pinout errors, and end up releasing the magic smoke that makes electronics work (It provides the wrong voltage and turns things on in the wrong order). Within FG, you have full read/write/exec, but you don't know anything about the system, and Tesla doesn't publish any datasheets on how they set things up.. So I killed 2 displays alone trying to get the monitor to turn on.

3) I'm far from a dictator, the only thing I get upset about is people wasting my time.
 
Yeah, I'm far from a dictator too. {smirk} But gotta keep that magic smoke from getting out the chips.

No idea what area you're working in but as it's GPIO may be as simple as replacing a driver chip. Surprised though that you could burn out GPIO unless you'd applied 12v externally. Even shorting, they should have adequate crowbar protection.

On the monitor I'd normally expect to see an LVDS pair going to a row/column demultiplexer at the monitor, but in this case 30 conductors (ribbon cable) is way too many for LVDS. And the display is clearly run by an Altera Cyclone IV FPGA, probably on the mainboard's PCIe buss.

But looking closer at the MCU mainboard there are 10 pairs of traces going from the Cyclone to the connector (on the front side anyway), with care given to equal line lengths, which implies that Tesla is using multiple parallel LVDS to the monitor. Hazzah, amazing approach, designed for max speed and no flicker.

The Cyclone will have the mux and LVDS drivers programmed in, and on init will download its config binary from a nearby flash. I'm not disassembling my bench monitor, but it will have a demux and drivers for the display. Backlight is likely driven from the monitor's power board.

Easy to find whether problem is in the display or mainboard by substitution, which I'm sure you know. If mainboard it'll be the FPGA, and I don't see any reason why it would have any internal custom e-fuses blown, so you should be able to order free engineering samples.
 
Last edited:
Anybody have a preference of emmc adapters? Looking at the allsocket with USB: https://amzn.to/3bXtAAo vs the Allsocket with the SD adapter: https://amzn.to/32jeUHB
Your thoughts?
Disclaimer: I'm not an engineer, but I have a failed chip and love learning.
I used the SD card version and worked for my new chip.

it could not read my old chip. See the topic start.
 
Hello i have questions, do i have to use linux to recover data from emmc?
i tried this wires soldered on nvida daugterboard and i know that i have working solution whit sd card but it does not see eMMC on nvidia board. I think i have issue whit that Nvidia chip wakes up and locks eMMC.
Is there solution to disable Nvidia chip, perhaps a pullup resistor to move ? Thank you for help
IMAG0264.jpg
 
Awesome. Thanks for the info. I was going to x window on mu Macbook Pro, since it didn’t work for you, I will install Linux on a PC then.
Well, it basically did work, I just had to restart a couple of times on the big partitions. Could very well have been an issue with the "el-cheapo" kind of card-reader. The USB device would simply bail and be rediscovered again.
I did multiple readouts on Linux and macOS (using ddrescue) and compared the results to be sure no garbage was read. What I learned from that was, that when the USB reader failed, there were read-errors that were not marked as such by ddrescue. Anyway, I was able to read the important partition 3 without interruptions on both Linux and macOS.
The (uninterrupted) dumps optained using Linux matched except for a handful bytes on partition 4, that would change with every read (probably already early signs of chip-wearout there).
 
  • Like
Reactions: TonyT
Anybody have a preference of emmc adapters? Looking at the allsocket with USB: https://amzn.to/3bXtAAo vs the Allsocket with the SD adapter: https://amzn.to/32jeUHB
Your thoughts?
Disclaimer: I'm not an engineer, but I have a failed chip and love learning.

For doing the onBoard/in-System readout I used this kind of Device:
%product-title% kaufen
and did some soldering:
sd-reader-modified.jpgtegra_in-system-con.jpg impro_in-system_setup.jpg solder_microscope2.jpg solder_microscope1.jpg

This was the setup I wrote earlier about which gave me a good read-out of a non-defective (!) eMMC.

For writing the new eMMC chip, I thought about the Allsocket Adapter but then (because of faster shipping) went to buy a combo of a Moorc E-Mate v1 and the matching SD-Adapter (SD-EMMC Plus Adapter - Model SE-P1):
Moorc E-Mate V1 EMMC BGA 153/169, 162/186, 221, 529 (7in1)
SD-EMMC Plus Adapter - Model SE-P1
Moorc_eMMC_readout.jpg
I'm going to use the shown combo during the course of next week to try to access a defective eMMC in order to get my P3 data...
 
  • Like
Reactions: scaesare
I use the SD version. It seems to be picky about SD readers. The usb one may work better?
I suppose it's a matter of signal integrity and power-delivery.
Normally (in-system) there are capacitors close to the eMMC (and every other IC in the system) to buffer the power rails (VCC & VCCQ in this case) and the eMMCs connection to ground are short and in high numbers (and thus posess low inductance).
When using an adapter, the connections (signal, power and ground) tend to get much longer and thus have more resistance and especially inductance. This in turn leads to a lot of undesired effects, e.g. to small power drop-outs when the chip draws (instantaneously) more current (because a signal line changes state). These short-time drops in the power line may "confuse" the eMMC and lead to data-corruption or non-working setups. Other errors might stem from an improper ground connections between chip(-carrier) and reader. So it's a good idea to spend more copper(wires) on the ground connection.