# HowTo Tesla - Repairing the Black MCU Screen



## Quantum` (Jan 10, 2019)

So, I am now locked out of my CID, and all streaming radio is just static as are turn signals and all bongs. I thought Tesla had done it. But someone who would know told me they had never heard of Tesla doing this, and that it's more likely that Ingineer (Phil) has done this to me. It's a serious problem.

Ok so I appealed for help from some old friends: ce2078, verygreen, and appleguru. We used to share information. But for some reason each in his turn has gone into radio silence.


None will help me with this. No idea why. I am alone.

I notice that even with my repeated encouragement none of them has posted any sort of howto like the ones I've posted here. So it seems that this is what we are doing -- not helping anyone. 

As a result I've taken down my howtos. I'm sorry about this but there is some kind of political problem which I don't understand.

Of course this action will not make any of them more likely to help me, I am sure quite the opposite. But at this point I have nothing to lose. Why should I help others when NO ONE will help me in an emergency? Life in the Big City.


----------



## swoozle (Nov 13, 2011)

What is with these posts edited to stick ads in the middle of them?


----------



## JRP3 (Mar 7, 2008)

I think that was just an example of the type of service to look for.


----------



## Quantum` (Jan 10, 2019)

..........


----------



## Doncrew (Jan 14, 2019)

Thank you for this valuable info. However I am curious about just disabling logging to avoid disassembling a (for now) working mcu. It seems it would be easier to put the tegra into apx mode and use nvFlash to fix the firmware. I wonder if this can be done via Ethernet or somehow via the car's built in Wi-Fi..


----------



## Quantum` (Jan 10, 2019)

..........


----------



## chicowoodhill (Apr 15, 2014)

@Quantum - Great post, great insight into the Tesla system. Wish it were more open (especially the audio system UI, which I hate and would love to rewrite). 

I checked the TMC forum for posts by Quantum --- didn't find any. What username do you post under?


----------



## JRP3 (Mar 7, 2008)

He's rooter on TMC.


----------



## Quantum` (Jan 10, 2019)

..........


----------



## Quantum` (Jan 10, 2019)

..........


----------



## floydian5 (Feb 14, 2019)

Great content! Thanks everyone for sharing.

Correct me if I'm wrong but even though IC and CID eMMC partitions are not the same per-se, they both contain the car specific files right? So one theoretically could;

- Take out the p3 & p4 of any other car (which have the correct file system and complete files) Say it is /randomcid for example purposes
- Take their own IC p3 & p4 images (which have the car specific files) Say it is /myic for example purposes
- Extract them all on linux on separate directories
- use rsync -a /randomcid /myic 
so it copies everything and still keeps car specific files.

Then you can use gparted to recreate p3 & p4 extfs3 partitions. Put them back on to an eMMC with p1&p2 partitions you can find which have to be the same version as Spansion.

Bob's your uncle! No?


----------



## Quantum` (Jan 10, 2019)

..........


----------



## laurynas (Jan 25, 2019)

Quantum` said:


> I've never needed to look at files on the IC, but have heard that some things are different. /var may be close enough, Idk.
> 
> Only /var (mmcblk0p3) is likely to ever be damaged as that's what gets hammered by Tesla's (justified) logging. But /var holds some mighty crucial files. This is why you should always try and dump the chip before it fails... and rest assured cowboys, it will fail.
> 
> ...


/var and /home partitions can be empty. Tesla will re-create everything you need on first boot.


----------



## Quantum` (Jan 10, 2019)

..........


----------



## laurynas (Jan 25, 2019)

Quantum` said:


> laurynas are you talking about just a generic Linux system or about the Tesla system specifically? Have you actually tried this or seen it done?


I did it myself. Was not able to recover any data from my MCU, so I copied mmc from IC, then wiped /var and /home partitions, extended /home partition and tesla created everything on first boot.

Edit:
almost everything.
I see this message in syslog:
2019-02-23T09:48:19.841473-08:00 cid QtCarNetManager[2451]: [SierraCellModem] INFO Cannot open /home/tesla/.Tesla/car/cell_apn 
Anybody know the content of this file?


----------



## EVfromUS (Oct 22, 2017)

laurynas said:


> I did it myself. Was not able to recover any data from my MCU, so I copied mmc from IC, then wiped /var and /home partitions, extended /home partition and tesla created everything on first boot.
> 
> Edit:
> almost everything.
> ...



cell_apn file contains this line



> tesla01.com.attz


----------



## laurynas (Jan 25, 2019)

EVfromUS said:


> cell_apn file contains this line


Thanks. I see no error message in the logs, but mobile internet does not work anyway. Probably cause of it US tesla in Europe. Have to replace sim card.

I see some other errors in the logs. Apart from it, everything seems to work as expected. Don't know if I should worry about it.


```
2019-02-24T15:03:14.236923-08:00 cid QtCarVehicle[613]: [ServiceDataListenManager] INFO created ServiceDataListenManager TMServer : 4401 frequency: high 
2019-02-24T15:03:14.284608-08:00 cid QtCarVehicle[613]: [ServiceDataListenManager] INFO Now listening for data broadcasts from service TMServer on port 4401 (all interfaces) 
2019-02-24T15:03:21.884562-08:00 cid QtCar[869]: [ServiceDataListenManager] INFO created ServiceDataListenManager TMServer : 4401 frequency: high 
2019-02-24T15:03:21.886510-08:00 cid QtCar[869]: [ServiceDataListenManager] INFO Now listening for data broadcasts from service TMServer on port 4401 (all interfaces) 
2019-02-24T15:03:44.729614-08:00 cid QtCarNetManager[1932]: [ServiceDataListenManager] INFO created ServiceDataListenManager TMServer : 4401 frequency: high 
2019-02-24T15:03:44.755770-08:00 cid QtCarNetManager[1932]: [ServiceDataListenManager] INFO Now listening for data broadcasts from service TMServer on port 4401 (all interfaces) 
2019-02-24T15:03:45.787778-08:00 cid QtCarGpsManager[1938]: [ServiceDataListenManager] INFO created ServiceDataListenManager TMServer : 4401 frequency: high 
2019-02-24T15:03:45.799184-08:00 cid QtCarGpsManager[1938]: [ServiceDataListenManager] INFO Now listening for data broadcasts from service TMServer on port 4401 (all interfaces) 
2019-02-24T15:03:46.012725-08:00 cid QtCarServer[1927]: [ServiceDataListenManager] INFO created ServiceDataListenManager TMServer : 4401 frequency: high 
2019-02-24T15:03:46.069373-08:00 cid QtCarServer[1927]: [ServiceDataListenManager] INFO Now listening for data broadcasts from service TMServer on port 4401 (all interfaces) 
2019-02-24T15:03:49.894553-08:00 cid qtcar-tmserver: QtCarTMServer starting
2019-02-24T15:03:50.770327-08:00 cid qtcar-tmserver: QtCarTMServer has stopped
2019-02-24T15:04:29.979760-08:00 cid QtCarServer[1927]: [ServiceTransportPool] ERROR Unable to connect to TMServer at [] 192.168.90.100:4400 within 50 msecs 
2019-02-24T15:04:47.206514-08:00 cid QtCarServer[1927]: [LogAggregator] INFO 1 repeated instances of [ServiceTransportPool] ERROR Unable to connect to TMServer at [] 192.168.90.100:4400 within 50 msecs  
2019-02-24T15:05:47.206126-08:00 cid QtCarServer[1927]: [LogAggregator] INFO 3 repeated instances of [ServiceTransportPool] ERROR Unable to connect to TMServer at [] 192.168.90.100:4400 within 50 msecs  

2019-02-24T15:51:48.469502-08:00 cid QtCarServer[1927]: [LogAggregator] INFO 2 repeated instances of [ServiceTransportPool] ERROR Unable to connect to TMServer at [] 192.168.90.100:4400 within 50 msecs  
2019-02-24T15:51:48.469667-08:00 cid QtCarServer[1927]: [LogAggregator] INFO 2 repeated instances of [ServiceTransportPool] ERROR Unable to connect to Horizon at [] 192.168.90.100:4180 within 50 msecs  
2019-02-24T15:51:48.470222-08:00 cid QtCarServer[1927]: [LogAggregator] INFO 2 repeated instances of [ServiceTransportPool] ERROR Unable to connect to EbServerIC at [ic] 192.168.90.101:4304 within 50 msecs  
2019-02-24T15:51:48.470606-08:00 cid QtCarServer[1927]: [LogAggregator] INFO 2 repeated instances of [ServiceTransportPool] ERROR Unable to connect to GpsDasDebug at [] 192.168.90.100:4162 within 50 msecs  
2019-02-24T15:51:48.470980-08:00 cid QtCarServer[1927]: [LogAggregator] INFO 2 repeated instances of [ServiceTransportPool] ERROR Unable to connect to EbServer at [] 192.168.90.100:4104 within 50 msecs  
2019-02-24T15:51:48.472474-08:00 cid QtCarServer[1927]: [LogAggregator] INFO 2 repeated instances of [ServiceTransportPool] ERROR Unable to connect to Media at [] 192.168.90.100:4145 within 50 msecs  
2019-02-24T15:51:48.472951-08:00 cid QtCarServer[1927]: [LogAggregator] INFO 2 repeated instances of [ServiceTransportPool] ERROR Unable to connect to ICSystemInfo at [ic] 192.168.90.101:0 within 50 msecs  
2019-02-24T15:51:48.475396-08:00 cid QtCarServer[1927]: [LogAggregator] INFO 2 repeated instances of [ServiceTransportPool] ERROR Unable to connect to ICNavServer at [ic] 192.168.90.101:4300 within 50 msecs  
2019-02-24T15:51:48.475831-08:00 cid QtCarServer[1927]: [LogAggregator] INFO 2 repeated instances of [ServiceTransportPool] ERROR Unable to connect to ICMapState at [ic] 192.168.90.101:4050 within 50 msecs  
2019-02-24T15:51:48.476403-08:00 cid QtCarServer[1927]: [LogAggregator] INFO 2 repeated instances of [ServiceTransportPool] ERROR Unable to connect to NavServer at [ic] 192.168.90.101:4200 within 50 msecs  
2019-02-24T15:51:48.476903-08:00 cid QtCarServer[1927]: [LogAggregator] INFO 2 repeated instances of [ServiceTransportPool] ERROR Unable to connect to VehicleVolatile at [] 192.168.90.100:0 within 50 msecs
```


```
2019-02-24T15:50:30.633320-08:00 cid QtCarAudiod[637]: [] WARN ASSERTION FAILED Starting timer outside of owner thread! at ../../../utils/TimerAudit.cpp:25
2019-02-24T15:50:30.672629-08:00 cid QtCar[869]: [] WARN ASSERTION FAILED Starting timer outside of owner thread! at ../../../utils/TimerAudit.cpp:25
```


----------



## Martii (Jan 17, 2018)

in EU content of this file (APN name) is:


tesla.m2m





laurynas said:


> Thanks. I see no error message in the logs, but mobile internet does not work anyway. Probably cause of it US tesla in Europe. Have to replace sim card.
> 
> I see some other errors in the logs. Apart from it, everything seems to work as expected. Don't know if I should worry about it.
> 
> ...


----------



## floydian5 (Feb 14, 2019)

laurynas said:


> I did it myself. Was not able to recover any data from my MCU, so I copied mmc from IC, then wiped /var and /home partitions, extended /home partition and tesla created everything on first boot.
> 
> Edit:
> almost everything.
> ...


Oh great work you actually did it?! How though? I don't understand. I thought keys, shadow, vpn, VIN, mileage and every other car specific crucial info was on p3 & p4. So if you take dump of IC and just keep p1&2 and delete the contents of p3&p4 on a blank new MCU eMMC where does it get the data from?

I have a backup of another car's full eMMC dump but I guess if I do that then app access would be lost alongside VIN, mileage and VPN info. Could someone explain the files and their workings?


----------



## MSLaaf (May 14, 2019)

While having a bigger eMMC like 64GB instead of 8GB will give you an approx 8x life span, there is even a better way (IMHO) to increase the lifespan of an eMMC device by 10x. (Any modern eMMC device should support it)

You'd need the spec from
https://www.jedec.org/system/files/docs/JESD84-A441.pdf 

(free to download after registration)
This describes a feature called 'Partitions - item 7.2.3, and what needs to be configured is the 'Enhanced User Data Area' (one time irreversible operation)
That will reduce the effective size by half, but it will transition the chip in a PseudoSLC mode, and yield a 10x lifespan. Chip will not wear out anymore, so a 64GB eMMC will become 32GB with a 40x lifespan. Car will be scrap before this eMMC device fails.


----------



## floydian5 (Feb 14, 2019)

So I have a similar issue now but I don’t think it is related to the eMMc. 

I had a malfunctioning wifi/bluetooth car due to the CID motherboard. It is a Model S P100D 2017. So I got a motherboard of another 2017 S 75. S75 is still functioning so it will only be a swap.

Donor car; 2017 S75, runs 2018.50, on factory mode so seceth is disabled. Backed up gateway config files with my perl script. Removed the MCU and took the motherboard out.

Recepient car; 2017 S P100D, runs 2019.4. Even though I’ve put factory mode on I couldn’t backup gateway config. So just removed the MCU, connected to the port going directly to IC. SSH’d into IC and reached gateway config under /var/etc/

Swapped the motherboards without an issue. Put donor car’s MCU back on, thought it was a P100D. I set its gateway config file with my perl script and redeployed. No problems, runs and drives fine. Bluetooth isn’t working of course but that was expected.

Put recipient car’s MCU back on, it thought it was a S75 with donor’s VIN, had a laugh. When it first turned on it could finally scan wifi networks so hardware issue was solved. However I still couldn’t access the diagnostic port so I couldn’t use my script to replace gateway config. It was still on factory mode on 2019.4 so while pinging CID I saw 9 on/9off replies from it so tried to make my perl script work and tried sending the gateway config. Then, everything shut down. Everything regarding the 12V battery works fine incl. lift gate and door handles but CID and IC doesn’t turn on and no hard reset works. Unplugging and plugging back in the CID power cables make them turn on, this time it knows it is a P100D both on CID and IC but they turn off immediately. When I press the T logo it doesn’t know its own VIN. Reads something like #NOVIN. I can’t remember exactly. I can ping CID through the port going from IC to CID when it is on but even with IC disconnected it turns off after a minute or so. So I removed the Tegra board, I’ll desolder it, mount it and get to the passwords for CID access. However car can’t even stay on to access CID, send gateway config and redeploy. So what do I do?

I’ll also investigate crash logs once I look into the Tegra board but does anyone think this is a lack of gateway config on the car? If so could I send one to the gateway with a tesla1 account password before everything shuts down? If not, what do I do?

Thanks a ton. Appreciate it.


----------



## Danish (Jun 1, 2019)

Hi.
My old 2013 S MCDU is getting slower and needs restarting allmost everyday to connect to the internet.
Anywhere to get it fixed, (Change chip, and clone info), for a better/more realistic price than Tesla's priceidea?

Best regards,

The Dane.


----------



## Quantum` (Jan 10, 2019)

..........


----------



## IBZ (Jun 2, 2019)

floydian5 said:


> I can ping CID through the port going from IC to CID when it is on but even with IC disconnected it turns off after a minute or so.


I had the exact thing happening and in my case it was the 12V running low. Disconnected the 12V, measured at 12.1V, put on a 12V battery charger, waited some hours and then systems stayed up. 
Not sure if this is what happened to you, but I would love to hear if your swap project worked out.

Right now I'm in the process of trying to swap my car's dead emmc mcu1 with a donor mcu from a salvage car. Lucky I was able to retrieve p3 partition with the car/openvpn keys and gw config file from my old mcu.
Tried to read p1/p2 off chip but when I unsquash them they do output some valid files but also some files fail to extract. 
I was able to root the donor mcu (lucky it had old fw on it!).
The donor mcu has really ancient 2016 firmware on it (v8.0 2.40.21), while my car had 2018.50 on it. 

When I power on my car with the donor mcu in it it boots up, it has my gw config loaded on it, and thinks it is my car. It will not drive or charge though, probably because of the large number of ecu version mismatches.

A redeploy would solve this I guess but I am very hesitant to do a redeploy on my car since it will require a massive downgrade of all ecu's. And possibly it would get flagged/banned as soon as it tries to connect to vpn as a "downgraded" car.

Also: I have tried updating the donor mcu on the bench by hosting the 2018.50 image file on my laptop and using cid updater to install it but I cannot get it to update at all. Vpn also fails. Not sure why but might be blocked/flagged after the original car crashed years ago?

So either I have to redeploy in car (possibly unsafe or risk of banning) or force a firmware update on the bench somehow.

If anyone can chime in please reply here or pm me. If you can really help me some compensation for your time is no problem.


----------



## IBZ (Jun 2, 2019)

I have replaced the emmc chip with the 16GB Swissbit mentioned, but it will not boot.
When I connect to serial from gw I can see this:


```
waiting on /sys/devices/platform/sdhci-tegra.3/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p1...
rm: can't remove '/dev/usr-partition': No such file or directory
touch: error while loading shared libraries: /lib/libpthread.so.0: cannot read file data: Input/output error
touch: error while loading shared libraries: /lib/libpthread.so.0: cannot read file data: Input/output error
touch: error while loading shared libraries: /lib/libpthread.so.0: cannot read file data: Input/output error
touch: error while loading shared libraries: /lib/libpthread.so.0: cannot read file data: Input/output error
touch: error while loading shared libraries: /lib/libpthread.so.0: cannot read file data: Input/output error
/sbin/init: error while loading shar[    4.017667] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00
```
Then it reboots, and start over again, this repeats every 3-5 seconds or so.

When I boot tegra to recovery mode it boots to cid-updater fine, and i can get to the command line as well which is a basic busybox environment with limited commands.
dmesg from recovery shows the following error message:


```
mmc0: unrecognised EXT_CSD revision 7
mmc0: error -22 whilst initialising MMC card
```
This tells me that the chip is soldered and functioning correctly because it is indeed a rev 7 emmc chip, mmc spec v5.0. 

Kernels with older mmc.c driver error out when they encounter anything above rev 6, so I guess that is what is happening now.

I'm not sure how I'm going to fix this, either by trying to set the version byte in emmc ext_csd from busybox or by desoldering the chip again.

Have others experienced something similar?


----------



## Quantum` (Jan 10, 2019)

..........


----------



## IBZ (Jun 2, 2019)

This is a sad day. I really don't know what happened to your car, maybe it is just bad luck or coincidence (tuner/amp gone bad?) or your car was really hacked from outside who knows. 

But taking down all the (very) helpful info you posted is not the right thing to do imho, and it hurts the diy community.
Please reconsider putting your posts back up, many readers here depend on this kind of information because very few of this seems to be shared outside some inner circle of Tesla hackers.
Best of luck to you, and thanks for all the fish


----------



## laurynas (Jan 25, 2019)

My IC died two moths ago. Was a busy time. Only today have managed to check 
the logs. Seems like mmc issues. Replaced chip with 16GB Swissbit, but IC still doesn't work. Black screen, no ping to 192.168.90.101. Any ideas for debuging? Any serial port on IC? Don't want to unsolder chip again.


```
2019-05-01T04:23:00.634348-07:00 ic kernel: [ 2263.150253] mmc2: refresh for Hynix f26
2019-05-01T04:23:00.639607-07:00 ic kernel: [ 2263.150394] mmc2: ADMA error
2019-05-01T04:23:00.639869-07:00 ic kernel: [ 2263.153283] ------------[ cut here ]------------
2019-05-01T04:23:00.640012-07:00 ic kernel: [ 2263.153321] WARNING: at /scratch/workspace/workspace1/firmware/tegra-os/dynamic-work-directory/builduser-firmware/ic-tegra-2/work_tegra-glib
c-452.toolchain_tegra-4.4.1-nv-eabi.toolchain_tools.localhost_PATH/linux-2.6.36.2-ac388a3/linux-2.6.36.2/drivers/mmc/host/sdhci.c:886 sdhci_send_command+0x38/0x910()
2019-05-01T04:23:00.640179-07:00 ic kernel: [ 2263.153353] Modules linked in:
2019-05-01T04:23:00.640318-07:00 ic kernel: [ 2263.153397] [<8043f014>] (unwind_backtrace+0x0/0xf0) from [<80798d60>] (dump_stack+0x20/0x24)
2019-05-01T04:23:00.640475-07:00 ic kernel: [ 2263.153429] [<80798d60>] (dump_stack+0x20/0x24) from [<8047cb20>] (warn_slowpath_common+0x5c/0x74)
2019-05-01T04:23:00.640686-07:00 ic kernel: [ 2263.153454] [<8047cb20>] (warn_slowpath_common+0x5c/0x74) from [<8047cb64>] (warn_slowpath_null+0x2c/0x34)
2019-05-01T04:23:00.640830-07:00 ic kernel: [ 2263.153480] [<8047cb64>] (warn_slowpath_null+0x2c/0x34) from [<806f2eb0>] (sdhci_send_command+0x38/0x910)
2019-05-01T04:23:00.640972-07:00 ic kernel: [ 2263.153507] [<806f2eb0>] (sdhci_send_command+0x38/0x910) from [<806f3a84>] (sdhci_finish_data+0x1c0/0x1e4)
2019-05-01T04:23:00.641114-07:00 ic kernel: [ 2263.153532] [<806f3a84>] (sdhci_finish_data+0x1c0/0x1e4) from [<806f41c8>] (sdhci_irq+0x558/0x65c)
2019-05-01T04:23:00.641254-07:00 ic kernel: [ 2263.153569] [<806f41c8>] (sdhci_irq+0x558/0x65c) from [<804bdc9c>] (handle_IRQ_event+0xb0/0x1d4)
2019-05-01T04:23:00.641396-07:00 ic kernel: [ 2263.153594] [<804bdc9c>] (handle_IRQ_event+0xb0/0x1d4) from [<804bfb10>] (handle_level_irq+0xcc/0x148)
2019-05-01T04:23:00.641782-07:00 ic kernel: [ 2263.153622] [<804bfb10>] (handle_level_irq+0xcc/0x148) from [<80438098>] (asm_do_IRQ+0x98/0xd8)
2019-05-01T04:23:00.641926-07:00 ic kernel: [ 2263.153646] [<80438098>] (asm_do_IRQ+0x98/0xd8) from [<80438cec>] (__irq_svc+0x4c/0xe0)
2019-05-01T04:23:00.642064-07:00 ic kernel: [ 2263.153662] Exception stack(0x96833ba0 to 0x96833be8)
2019-05-01T04:23:00.642184-07:00 ic kernel: [ 2263.153679] 3ba0: 96833bec 60000013 00000000 806f3788 96833ccc 968b9400 96833bec 96833ca0
2019-05-01T04:23:00.642291-07:00 ic kernel: [ 2263.153698] 3bc0: 00000000 80957908 96833ccc 96833c1c 8079c1dc 96833be8 806e7984 807992bc
2019-05-01T04:23:00.642353-07:00 ic kernel: [ 2263.153713] 3be0: 60000013 ffffffff
2019-05-01T04:23:00.642660-07:00 ic kernel: [ 2263.153735] [<80438cec>] (__irq_svc+0x4c/0xe0) from [<807992bc>] (wait_for_completion+0x0/0x24)
2019-05-01T04:23:00.642694-07:00 ic kernel: [ 2263.153759] [<807992bc>] (wait_for_completion+0x0/0x24) from [<806eb1c4>] (mmc_gen_cmd+0x1ec/0x238)
2019-05-01T04:23:00.642777-07:00 ic kernel: [ 2263.153783] [<806eb1c4>] (mmc_gen_cmd+0x1ec/0x238) from [<806e8288>] (mmc_refresh_work+0x110/0x150)
2019-05-01T04:23:00.642807-07:00 ic kernel: [ 2263.153811] [<806e8288>] (mmc_refresh_work+0x110/0x150) from [<80494a78>] (process_one_work+0x28c/0x458)
2019-05-01T04:23:00.642968-07:00 ic kernel: [ 2263.153837] [<80494a78>] (process_one_work+0x28c/0x458) from [<80496814>] (worker_thread+0x1dc/0x2f8)
2019-05-01T04:23:00.643085-07:00 ic kernel: [ 2263.153867] [<80496814>] (worker_thread+0x1dc/0x2f8) from [<8049a8f8>] (kthread+0x94/0x9c)
2019-05-01T04:23:00.643115-07:00 ic kernel: [ 2263.153894] [<8049a8f8>] (kthread+0x94/0x9c) from [<80439cc8>] (kernel_thread_exit+0x0/0x8)
2019-05-01T04:23:00.643138-07:00 ic kernel: [ 2263.153910] ---[ end trace d038a55b9758fb32 ]---
2019-05-01T04:23:00.643242-07:00 ic kernel: [ 2263.154411] mmc_refresh_work: command response has error: -110
2019-05-01T04:23:11.832422-07:00 ic kernel: [ 2274.349864] mmcblk3: error -110 sending read/write command, response 0x0, card status 0x900
2019-05-01T04:23:11.891038-07:00 ic kernel: [ 2274.362649] end_request: I/O error, dev mmcblk3, sector 5517360
2019-05-01T04:23:11.893772-07:00 ic kernel: [ 2274.368578] end_request: I/O error, dev mmcblk3, sector 5517368
2019-05-01T04:23:11.896821-07:00 ic kernel: [ 2274.374500] end_request: I/O error, dev mmcblk3, sector 5517376
2019-05-01T04:23:11.897028-07:00 ic kernel: [ 2274.380420] end_request: I/O error, dev mmcblk3, sector 5517384
2019-05-01T04:23:11.897054-07:00 ic kernel: [ 2274.386340] end_request: I/O error, dev mmcblk3, sector 5517392
2019-05-01T04:23:11.897076-07:00 ic kernel: [ 2274.392259] end_request: I/O error, dev mmcblk3, sector 5517400
2019-05-01T04:23:11.897098-07:00 ic kernel: [ 2274.398179] end_request: I/O error, dev mmcblk3, sector 5517408
2019-05-01T04:23:11.897119-07:00 ic kernel: [ 2274.404099] end_request: I/O error, dev mmcblk3, sector 5517416
2019-05-01T04:23:11.897265-07:00 ic kernel: [ 2274.410955] Aborting journal on device mmcblk3p4.
2019-05-01T04:23:23.421070-07:00 ic QtCarCluster[749]: [SysMonitor] INFO Video carveout usage: 61 MB / 52 %
2019-05-01T04:23:23.511421-07:00 ic QtCarCluster[749]: [] INFO SysMonitorLogger System:23%,185m Cluster:30.8%,80m Startup:0.0%,8.4m NavServer:0.0%,60m
2019-05-01T04:23:43.857017-07:00 ic kernel: [ 2306.348443] mmcblk3: error -110 sending read/write command, response 0x0, card status 0x800900
2019-05-01T04:23:43.861266-07:00 ic kernel: [ 2306.357350] end_request: I/O error, dev mmcblk3, sector 4287776
2019-05-01T04:23:43.864146-07:00 ic kernel: [ 2306.363275] Buffer I/O error on device mmcblk3p3, logical block 11428
2019-05-01T04:23:43.864241-07:00 ic kernel: [ 2306.369715] lost page write due to I/O error on mmcblk3p3
2019-05-01T04:23:43.864269-07:00 ic kernel: [ 2306.369731] end_request: I/O error, dev mmcblk3, sector 4287784
2019-05-01T04:23:43.864294-07:00 ic kernel: [ 2306.375650] Buffer I/O error on device mmcblk3p3, logical block 11429
2019-05-01T04:23:43.864316-07:00 ic kernel: [ 2306.382088] lost page write due to I/O error on mmcblk3p3
2019-05-01T04:23:43.872424-07:00 ic kernel: [ 2306.393301] JBD: Detected IO errors while flushing file data on mmcblk3p3
2019-05-01T04:23:52.136975-07:00 ic QtCarCluster[749]: [ModelSVehicleLink] INFO AggregateLinkLogger r: 24603 l: 0 l_ms: 0 l_ms_max: 0 l_pkt: 0 l_pkt_max: 0 w: 180 c_pkt: 0 c_msg: 0
2019-05-01T04:23:53.509429-07:00 ic QtCarCluster[749]: [] INFO SysMonitorLogger System:18%,185m Cluster:31.3%,80m NavServer:4.5%,60m Startup:0.0%,8.4m
2019-05-01T04:24:00.753549-07:00 ic kernel: [ 2323.267720] mmc2: refresh for Hynix f26
2019-05-01T04:24:00.753816-07:00 ic kernel: [ 2323.267790] mmc_refresh_work: command response has error: -110
2019-05-01T04:24:03.872875-07:00 ic kernel: [ 2326.387731] mmcblk3: error -110 sending read/write command, response 0x0, card status 0x800900
```


----------



## IBZ (Jun 2, 2019)

I assume you have the p1/p2 backups? Have you tried to unsquashfs them to see if it gives any errors?


----------



## getroot (Jul 12, 2019)

I had a feeling he would take his rooting posts down so I saved them just in case. There's no reason to keep this information private considering it is a hardware hack that Tesla cannot patch (although they did patch the crontab persistence approach I believe). Here you go:

Ok, you've gotten access to your eMMC (Hynix) chip and it is time to modify the filesystem to root it. This post will describe AP1 cars and all earlier non-AP cars, as I've had to figure this all out myself (which I don't appreciate) and my car is an AP1 car. I welcome all comments and corrections, although my time is very limited so I can't spoon-feed or hold hands.

There are methods of rooting which don't involve soldering of course, through software vulns. But these are always very difficult to find, and always very easy to patch, so are carefully guarded. These are not my work and I have no right to release them, and would never do so in any case. If you'd rather this then please prepare your $1k+ for your (unfriendly) neighborhood commercial rooter, and give up any idea of having privacy and root for yourself. My method can never be patched.

As a reminder to my prior post, the CID is the daughterboard on the MCU mainboard. The CID is made by nVidia for Tesla, and although it seems to be an MMX formfactor (of the Qseven persuasion), it is not, it's a VCM, a special OEM custom for Tesla. A check of the 5v pinouts (on the opposite end) will confirm this. (Ask me how I know...)

As it's made by nVidia, they've used the typical system on their high-end video cards, that is a firmware update goes alternately to partition 1 or 2 whichever is not currently active, the new firmware is verified as a good write, then the car reboots to the new firmware and deploys staged components to the ECMs in the rest of the car. 

A boot coprocessor lives in the Tegra 3 chip, distinct from the actual T3 processor, and on reset this coprocessor initializes to the first address in the Spansion chip on the obverse of the CID. You'll notice that this is a rather large-capacity chip for an embedded device (512MB), and the reason is that it keeps track of which partition in the eMMC is the active one, and then builds the OS from that, in RAM at each boot. Once complete, the coprocessor chain-boots to the T3 processor, which boots to the filesystem in RAM, and mounts eMMC partition 3 as /var and 4 as /home.

So it's likely that partitions 1 and 2 will have different versions of the firmware. Everything is checked real-time by the boot coprocessor using code-signing (started very early in its init process in what is effectively its BIOS), and so it is very important that the active eMMC partition's firmware match the version in the Spansion chip. If you unilaterally upgrade the active partition to a different version, or change the eMMC chip to one from another CID, boot will fail (due to code-signing) and black screen. (Ask me how I know...)

Firmware updates must only be written to the inactive partition. Then you will deploy (using a Tesla script), the system will determine what kind of car you have and stage the correct modules (from 1or2/deploy/seed_artifacts_v2 which holds all modules for all cars) to 4/cid-updater/gateway-staging-work/gwrelease*, which holds only the ECM ('Electronic Control Module') files which are specific to your car. Once staged, the update clock will come up on your MCU and you choose when to initiate it.

I wouldn’t normally expect the staged modules to be in /home. (Note to Tesla: Under Posix standards, /var/spool is the proper place for stuff like this, not /home) The manifest file there holds the name and version of each .hex file, in the apparent order that they should be applied.

First Step
If you haven't already, dd you the whole original eMMC image off the chip and individual partitions, and set aside as your Golden ones, as I'd described in the earlier thread.

Second Step
It is important to know which is the current active part, 1 or 2.

Now the nice thing with the chip out is you can mount partitions 1 and 2 with no problem, even though they are squashfs. They're even read/write.
# mount -o loop /dev/mmcblk0p1 /media/1
# mount -o loop /dev/mmcblk0p2 /media/2
# mount /dev/mmcblk0p3 /media/3
# mount /dev/mmcblk0p4 /media/4
(Needless to say, create your mount dirs under /media first)
# touch /media/1/1
# touch /media/2/2
... then later see which one ends up in /usr after boot. Of course this flag file will be overwritten on the next firmware update, but you can recreate it on the eMMC since you will have root. (Hint: mount -o remount,rw)

<SafetyGlassesWarning>It's important to note that anytime you are working as root you can easily damage your filesystem, to uselessness. So remain conscious and don't work on this too drunk.</SafetyGlassesWarning>

Reconnaissance
Now our filesystem. Interesting directories and files, IMHO:
1-2/deploy/ - the complete update mechanism for the car. boot.img is there, and all it should take is a dd of that to the 512MB flash chip. (If you can get to it) version_map2.tsv contains all the file versions for different configs of cars, for example RearDrive type ?, and 4WD type ?, etc. So the reason for staging these files is to sort out the only ones which are applicable to this particular car.
1-2/etc/openvpn/teslavpn.conf.prod
1-2/local/bin/
1-2/local/bin/get-vitals
1-2/share/openssl-blacklist, openvpn, openvpn-blacklist
1-2/tesla/UI/
3/spool/cron/crontabs/root
4/tesla/.crashlogs/QtCar-crash-*.txt
1-2/local/bin/gwxfer perl script allows transfer of the gateway config from gw to cid filesystem and back.
Templates of the openvpn config files (teslavpn.conf.dev and teslavpn.conf.prod) in 1-2/etc/openvpn folder.
3 on-screen browser config and cache files, .bashrc and friends, my radio config with my internet and OTA stations (SQLite database), crashlogs (187 files!), QtCar, QtCarGpsManager, QtCarMediaServerV2, QtCarNetManager, QtCarParrot, QtCarServer -yikes-, QtCarSpeedRecognizer, QtCarVehicle -yikes-, and unknown, gstreamer config files, .ssh (with only authorized_keys), and cached map tiles of my area (http & https .cache type).
Notice that there is an /etc directory in partitions 1 and 2, but the only things in it are a log mask file for the Sierra GSM card, and an openvpn directory — hello. In it are:
a script that updates resolv.conf on connexion of VPN, and
the openvpn.conf file, which points to the car’s cert, car key (a cert), the CA cert, and the (depreciated) TLS remote option to authorize the remote host. (which is who we might expect) The certs belong in this directory but are not in partition 1 or 2, likely added when the OS is built in RAM since they are car-specific.
Where is passwd? Oh, in 1(&2)/share/base-passwd/passwd.master and also there is group.master. Nothing special here, just the usual. 

So remember, the basics of the VPN and the passwd file are in partitions 1 and 2 which get overwritten at updates. IOW you can not add users nor VPNs without special cron scripts.

Where is shadow? A quick mlocate and: 3/etc/. Ok this is good news, it's in a non-volatile partition so we can modify passwords etc, and our work will be remembered in perpetuum. Also there are birthday, car keys, vin, gateway.cfg, etc, and openvpn which contains the certs we’ve learned about.


----------



## getroot (Jul 12, 2019)

For some reason I get a message saying that I've been blocked when trying to post the rest of the instructions. I actually remember Quantum saying something about this message popping up thinking he was blacklisted from this site by people who were out to get him, lol. Pretty sure some part of the text is triggering a security layer that blocks my post.


----------



## laurynas (Jan 25, 2019)

I made my IC working today. Have tried to replace mmc with Swissbit 16GB (SFEM016GB1EA1TO-I-GE-111-STD), then with 32 GB (SFEM032GB1EA1TO-I-LF-111-STD). None of these chips were working. 
Not sure if it is because of IC is using old linux kernel 2.6.36.2-pdk19.0068-Tesla-core-2016.1 or some other issues. Haven't had a possibility to connect to serial.

Then fixed partitions with fsck on original 4GB Hynix mmc and soldered it back. IC is working now, but not for long probably.
Any ideas for better replacement?


----------



## McMetric (Aug 9, 2019)

Ordered a 16gig Swissbit from Mouser 3 weeks ago.
SFEM016GB1EA1TO-I-GE-111-STD
Had it installed in my MCU board yesterday and it works

MCU booted up, all fine


----------



## scaesare (Jan 9, 2019)

Looks like I'm joining the club.... May 2013 Model S w/ 145K miles (and commensurate hours on the MCU).

I had read h the failing eMMC threads previously, and figured I'd tackle this pre-emptively. Time didn't allow, coupled with the fact that my screen started developing bubbles. Rumor had it a revised LCD screen was coming soon, so I thought I'd kill 2 birds with one stone and do the eMMC replacement and LCD at the same time. Looks like I waited too long. 

I thought I'd see some obvious signs (map loading issues, etc...) that might tell me failure was imminent, but nothing major until yesterday. My A/C condenser fans seemed to be running for no reason, even after parked. Did a scroll-wheel reboot and got out of the car. Came back a few hours later and black MCU. No soft-reboots possible. Pulled the 12v battery, and still no go. In retrospect I did notice a few days ago that my browser was locked up even after a reboot. But it was hung on TeslaWaze, which the browser struggles with anyway, and with Tesla's last "oopsie" of inadvertently killing browser functionality with a software update (the traffic polling interval bug), I didn't give it enough thought.

Incidentally, while the car was initially drivable with the MCU dead, it now no longer is after pulling the 12v. It now wants authentication from either the fob or the phone app, and neither work.

As this thread mentions, it's unfortunate that it seems there's been some effort to squash information sharing on this matter. Thanks for those who have (past or present). And it sucks if you've suffered some retribution as a result. That having been said, some of the info is still available online from several sources.... especially those that were once posted to static web pages, as opposed to on forums (hint hint).

Current plan of action:

1- Order Allsocket MMC programmer and replacement Swissbit eMMC chip

2- Kill 12V, disassemble dash, remove MCU

3- Have local phone repair shop de-solder original eMMC chip

4- Use ddrescue on Linux to (hopefully) read partitions 1-4 on original Hynix eMMC

5- Write partitions to new eMMC. Check for errors. Expand partitions, check for errors again

6- Consider adding some secret-sauce in /var and /home in order to facilitate expanded logical access increase reliability by reducing log writes (see question below)

7- Install new eMMC (see question below)

8- Reinstall MCU, reconnect 12v, boot

9- Rejoice


Any thoughts/concerns/suggestions on the above?


Questions:

Anybody have a good phone repair shop they want to recommend in either the NoVA or Rockville/Bethesda MD areas?
Does anybody have some secret-sauce recipes they are interested in sharing via PM?
Has anybody successfully found a board-mount eMMC socket/carrier to use on the Tesla PCB? I'd like to avoid multiple un-soldering/re-soldering if I don't get it right the 1st (or 8th) time.
Any other flash-chip-rescue pointers appreciated...

In order to help give back: I've been collecting a private cache of the info I've found online... I'm happy to share via PM for those in the same predicament.

Thanks...


----------



## scaesare (Jan 9, 2019)

Looks like I'm joining the club.... May 2013 Model S w/ 145K miles (and commensurate hours on the MCU).

I had read the failing eMMC threads previously, and figured I'd tackle this pre-emptively. Time didn't allow, coupled with the fact that my screen started developing bubbles. Rumor had it a revised LCD screen was coming soon, so I thought I'd kill 2 birds with one stone and do the eMMC replacement and LCD at the same time. Looks like I waited too long. 

I thought I'd see some obvious signs (map loading issues, etc...) that might tell me failure was imminent, but nothing major until yesterday. My A/C condenser fans seemed to be running for no reason, even after parked. Did a scroll-wheel reboot and got out of the car. Came back a few hours later and black MCU. No soft-reboots possible. Pulled the 12v battery, and still no go. In retrospect I did notice a few days ago that my browser was locked up even after a reboot. But it was hung on TeslaWaze, which the browser struggles with anyway, and with Tesla's last "oopsie" of inadvertently killing browser functionality with a software update (the traffic polling interval bug), I didn't give it enough thought.

Incidentally, while the car was initially drivable with the MCU dead, it now no longer is after pulling the 12v. It now wants authentication from either the fob or the phone app, and neither work.

As this thread mentions, it's unfortunate that it seems there's been some effort to squash information sharing on this matter. Thanks for those who have (past or present). And it sucks if you've suffered some retribution as a result. That having been said, some of the info is still available online from several sources.... especially those that were once posted to static web pages, as opposed to on forums (hint hint).

Current plan of action:

1- Order Allsocket MMC programmer and replacement Swissbit eMMC chip

2- Kill 12V, disassemble dash, remove MCU

3- Have local phone repair shop de-solder original eMMC chip

4- Use ddrescue on Linux to (hopefully) read partitions 1-4 on original Hynix eMMC

5- Write partitions to new eMMC. Check for errors. Expand partitions, check for errors again

6- Consider adding some secret-sauce in /var and /home in order increase reliability by reducing log writes (see question below)

7- Install new eMMC (see question below)

8- Reinstall MCU, reconnect 12v, boot

9- Rejoice


Any thoughts/concerns/suggestions on the above?


Questions:

Anybody have a good phone repair shop they want to recommend in either the NoVA or Bethesda MD areas?
Does anybody have some secret-sauce recipes they are interested in sharing via PM?
Has anybody successfully found a board-mount eMMC socket/carrier to use on the Tesla PCB? I'd like to avoid multiple un-soldering/re-soldering if I don't get it right the 1st (or 8th) time.
Any other flash-chip-rescue pointers appreciated...

In order to help give back: I've been collecting a private cache of the info I've found online... I'm happy to share via PM for those in the same predicament.

Thanks...


----------



## McMetric (Aug 9, 2019)

My car was driving, no issues, I thought
P1 was damaged, needed a fresh image of the system.
P3 /var was damaged and fsck deletet all files in /var/etc 
So no key files and nothing, car runs but no connection to the Tesla server.
Was able to pull the missing files from the image previous the fsck.
P4 was damaged too, so I made mkfs etx3 in P4, clean with no errros

The system will recreate P4 /home when its empty. It only needs a few empty folders with correct permissions and the apn file. Easy to set up, PM me.

Next try is a 64GB Swissbit chip

Check Lunars/Tesla on GitHub


----------



## scaesare (Jan 9, 2019)

Thanks, your suggestions in line with what I've seen/heard thus far.

Were you ever able to get your keys and get back online?


----------



## McMetric (Aug 9, 2019)

Yes, car is running again, had to replace the chip a second time.
Car keys are now in /var/etc (were deleted by fsck)
System bootet up, all fine, got the Tesla connection back

Today I learned how to get into the MCU and how to unlock the diag port if the car keys are not on the emmc. There is a way, so next time no soldering required.

2018.50.6 is still on it, no plan to update. No battery limitation in range and charge speed with 2018.50
2nd emmc is now a 64gig Swissbit


----------



## scaesare (Jan 9, 2019)

Ah cool... how'd you recover the deleted keys? Did you still have them on your dd partition image and just not realize that the had been deleted?


----------



## scaesare (Jan 9, 2019)

Progress:


----------



## McMetric (Aug 9, 2019)

scaesare said:


> Ah cool... how'd you recover the deleted keys? Did you still have them on your dd partition image and just not realize that the had been deleted?


Yes, all files are in the first image taken from the org. emmc (dd or ddrescue gave same file results)
Forgot to look into /var/etc after fsck ran

Plan B was to get all data from the IC, I was told that there is a copy of the car key file.


----------



## scaesare (Jan 9, 2019)

Gotcha.

Are you all mounting the image files and operating on those before writing back to the new eMMC, or are you fsck'ing, modifying chrontabs, etc... directly on the new flash?


----------



## McMetric (Aug 9, 2019)

I did both, but primarily on the new chip.
But please ask someone who is really comfortable with Linux. 
I cant give any advice on linux.
But the whole operation can be so simple that even I managed to do this.


----------



## scaesare (Jan 9, 2019)

Well, crap. I can't read from my eMMC at all. The block device shows up, but I couldn't dd from it, and ddrescue has been chewing on it for 15 minutes, and midway through the second pass it's managed to recover 0.00%

Not what I had hoped for.


----------



## kennybobby (Aug 10, 2012)

Is it possible, or how is it done, to verify that all the solder joints of the ball-grid array are intact and none are shorted together? 

i have a hard time just with tiny surface mount solder joints that i can barely see without a microscope.


----------



## McMetric (Aug 9, 2019)

Did you try another chip before to see if your setup is working ?
A wrong SD card reader can cause a problem (when using the Allsocket SD)
Does it show up as sdX only ? Or not even as a sdX device ? What does dmesg say ?
Is your chip very very clean ? Reballing it can help. I read 2 chips which were unsoldered and cleaned, very clean, no problem.

Try to access the IC and get all the data from it. Again, I havent done this, but there should be a copy of you car data.
You can get the car running without any car keys if needed. What is the current software version of your car ?

I made a fresh image without any of my car data and the S85 was driving and charging (AC), hat INet access, but no Tesla connection. I only had to fill in my keys (all files in /var/etc) and its now like new. All works.
You can create a fresh image for the emmc if needed. The Tesla installer will recreate P4, thats easy.
I was told (again I did not try) that P3 /var with your car keys will also be recreated if empty. Dont know if any folders have to be made before (like in P4)
I can post the procedure to set up P4 /home fresh if needed


----------



## scaesare (Jan 9, 2019)

My replacement flash reads just fine, so I don't think I have any SD card reader or carrier problems.

So now I have to decide if I want to disassemble my IC, and try and read that.

While I've heard that the IC has a copy of the boot partitions, does it also have the car keys/etc... from P3 /var? I was under the impression it did not.

Has anybody successfully done this?


----------



## scaesare (Jan 9, 2019)

So it appears the IC board only has a 4GB eMMC, as opposed the MCU's 8GB. 

I wonder if this implies not having a full copy of all of the partitions that exist on the MCU, and if so what's missing. I'd expect that the system logs, odometer counter, media player favorites, etc... wouldn't be written to the IC.

But does it have static car data such as the VIN, SSH keys, etc?


----------



## scaesare (Jan 9, 2019)

Well, I've been advised by @Lucky Luke that the Hynix H26M42001FMR from my 2013 car has issues with the All Socket reader I have... and his unit from a different manufacturer as well. The list of readers that do have support are rather expensive commercial units. That's not to say others may not work, we just don't know.

I've contacted the microsoldering shop that pulled my chip for me and seeing if we can give their reader a try (and/or see what model they have). Either way, I'll post the reader/programmer make/model info I get so we can build a list of what does/doesn't work.

If it doesn't work, I may send the chip off to a place that has a known compatible reader.

Also, I emailed All Socket to see what they say.


----------



## scaesare (Jan 9, 2019)

I tweeted Elon about this in case anybody wants to re-tweet:

https://twitter.com/OriginalFantom/status/1163481701240266753?s=20


----------



## floydian5 (Feb 14, 2019)

I'm also dealing with the same issue but my parition table is not readable from emmc. I've been looking around on the inside of IC emmc but even though;

- gateway config
- vin
- tesla.env

is there.

- vdt.config.json
- carkeys.tar
- birthday
- muc commands key

is not there.

So I need to rebuild from IC but how? Without losing connectivity of course. Anyone know how to do it? are those the only cruical files we need that are car specific? (ones in /var/etc inside CID)


----------



## scaesare (Jan 9, 2019)

floydian5 said:


> I'm also dealing with the same issue but my parition table is not readable from emmc. I've been looking around on the inside of IC emmc but even though;
> 
> - gateway config
> - vin
> ...


If you can't recover those, I don't know of any other source to get them than from Tesla...


----------



## scaesare (Jan 9, 2019)

I ordered an All Socket DS3000-USB3.0-emmc153+emmc169 programmer today in order to see if I can see anything on my Hynix chip, based on the communication from their engineer that, although they could not read the H26M42001FMR with their SD-based programmer, they could with this model.

I'll report back when I've had a chance to give it a shot...


----------



## scaesare (Jan 9, 2019)

No dice reading my chip... even with the new reader. To far gone it appears.

So I've now programmed my replacement flash without the car-specific info, so I can get it back on the road.

I'll worry about trying to get the other data later.


----------



## laurynas (Jan 25, 2019)

@getroot, can you write more details on how to access Spansion chip?
I have to change active partition from p1 to p2. Is it enough to dd /deploy/seed_artifacts_v2/boot.img to Spansion chip?


----------



## Bizteam (Oct 21, 2019)

Quantum` said:


> So, I am now locked out of my CID, and all streaming radio is just static as are turn signals and all bongs. I thought Tesla had done it. But someone who would know told me they had never heard of Tesla doing this, and that it's more likely that Ingineer (Phil) has done this to me. It's a serious problem.
> 
> Ok so I appealed for help from some old friends: ce2078, verygreen, and appleguru. We used to share information. But for some reason each in his turn has gone into radio silence.
> 
> ...



This is how it should be repaired.

https://youtu.be/BzmkXvkc9Uw

Contact me i need partner. Cheers


----------



## Bizteam (Oct 21, 2019)

https://youtu.be/BzmkXvkc9Uw


This is how it should be repaired.

Rooter contact me


----------



## Dameon (Sep 19, 2011)

scaesare said:


> So I've now programmed my replacement flash without the car-specific info, so I can get it back on the road.


So I assume the DS3000 working on the replacement chip? That should likely be an indicator that the DS3000 would also work on a functioning original MMC...


I need to replace my old reader and the DS3000 looks like a nice unit.


----------



## Bizteam (Oct 21, 2019)

This is how it should be done 
https://www.youtube.com/watch?v=BzmkXvkc9Uw
Automotive Swissbit MLC 16gb


----------



## scaesare (Jan 9, 2019)

Dameon said:


> So I assume the DS3000 working on the replacement chip? That should likely be an indicator that the DS3000 would also work on a functioning original MMC...
> 
> 
> I need to replace my old reader and the DS3000 looks like a nice unit.


Yes it does... sorry for late reply.. haven't gotten back here much.


----------



## Quantum` (Jan 10, 2019)

@Bizteam Sorry, but you show absolutely no awareness of anti-static precautions in your video. Placing the CID on the table? On *EPS*, of all things?! Handling the chip with your fingers? One zap or zing will ruin someone's CID or chip.

Additionally do you not know what effect oils from your fingers can have on BGA rework?


----------



## cloneguru (7 mo ago)

My eMMC replacement has gone well all except it doesn't create the OpenVPN connection anymore... syslog reports
RESOLVE: Cannot resolve host address: vpn.vn.teslamotors.com: [HOST_NOT_FOUND] The specified host is unknown.


----------



## Martii (Jan 17, 2018)

cloneguru said:


> My eMMC replacement has gone well all except it doesn't create the OpenVPN connection anymore... syslog reports
> RESOLVE: Cannot resolve host address: vpn.vn.teslamotors.com: [HOST_NOT_FOUND] The specified host is unknown.


OpenVPN is long gone


----------

