Preventive eMMC replacement on MCU1

[scaesare]

Follow-up from All Socket: Their engineer is going to test specifically with the H26M42001FMR to see what the deal is.

 

[itDied]

Hi guys!
I guess I'm the other one who has been in contact with Allsocket. (I'm in pretty much the same situation as you Sceasare)
I have asked them to test specifically for that chip, and if they are not able to read anything from it, try to figure out a way to make the Allsocket compatible with it.

I have also asked them if they are able to make something like this for the Tesla Nvidia board.

That would make any future operation a lot easier to handle, and I guess you could also save each new firmware iteration to your pc incase someone else might need it (like McMetric needed earlier).

They might need an actual Tesla Nvidia board in order to make a solution, so I looking at salvage yards to find one (or if that proves unsuccessful, I will ship the one from my car).

Terrific thread by the way

 

[KLuuppo]

I also got some bad news from data recovery: eMMC interface logic is toast. They offered to recover what they could by directly reading the nand for 400eur. I'm not sure how my chances are that identity files would be recoverable.

Btw, has anyone asked tesla if they could/would reflash a mcu that has just a new blank emmc installed?

Also got yet another car to try this on. This time going to do desoldering myself.

 

[LuckyLuke]

@KLuuppo what Hynix chip model is yours?

 

[MP3Mike]

Btw, has anyone asked tesla if they could/would reflash a mcu that has just a new blank emmc installed?

In the past Tesla had refused to even reprogram an MCU that was installed from another car. But they have opened up the policy on salvaged cars some so maybe they would now. (Assuming the tools SCs have are capable of doing it on a blank MCU.)

 

[scaesare]

Hi guys!
I guess I'm the other one who has been in contact with Allsocket. (I'm in pretty much the same situation as you Sceasare)
I have asked them to test specifically for that chip, and if they are not able to read anything from it, try to figure out a way to make the Allsocket compatible with it.

I have also asked them if they are able to make something like this for the Tesla Nvidia board.

That would make any future operation a lot easier to handle, and I guess you could also save each new firmware iteration to your pc incase someone else might need it (like McMetric needed earlier).

They might need an actual Tesla Nvidia board in order to make a solution, so I looking at salvage yards to find one (or if that proves unsuccessful, I will ship the one from my car).

Terrific thread by the way

Ah.... sorry to hear you are in the same boat, but glad to have someone else pressing the matter.

That socket solution would be great... I asked earlier upthread if there was a surface mount carrier/socket of any sort... the solution you picture would be ideal.

Thanks...

 

[KLuuppo]

@KLuuppo what Hynix chip model is yours?

It's H26M42001FMR1 as well. Btw, I believe the pin #1 marking dot is next to the serial number.

About this suggested allsocket-adapter: I wonder if mmcplus-card would work? That has at least all the data lines, but don't know if the interface is compatible. To make a BGA153-mmcplus adapter shouldn't be too complicated (and I don't really see leaving the allsocket module inside the mcu).

Anyway, I have a spare tegra board (with emmc desoldered) that can be sacrificed for reasearch.

EDIT: I scheduled a service appointment for reprogramming a blank chip. They even sent me an automated confirmation, so I'm SURE that they will do it =).

 

[itDied]

@KLuppo : That's great (concerning the spare tegra board), I will pass that on immidiately.
Given the flex cable, I suppose placement of the Allsocket could be pretty liberal, so might work.

If Tesla SC is not willing/able to help, what would really be needed in order to program a blank chip?
Firmware obviously (we could collaborate on a repository for all versions, so in theory we don't really need Tesla for that).
Then everything that is specific to your car: configuration & keys (anything else?).
Has anyone figured out any other way to gain access to that information? (Alternatively, might Tesla give us that information if we ask for it?)

 

[itDied]

I'm guessing this already well-known, but the img src for your Tesla when logging in, seems to reveal at least some of your cars configuration:
Source="https://static-assets.tesla.com/v1/...amp;view=STUD_SIDE&size=1920&options=CH00,DRLH,FG00,COL3-PPMR,RFPO,TP01,WT19,X019,X024&bkba_opt=1&context=dashboard"

 

[scaesare]

@KLuppo : That's great (concerning the spare tegra board), I will pass that on immidiately.
Given the flex cable, I suppose placement of the Allsocket could be pretty liberal, so might work.

If Tesla SC is not willing/able to help, what would really be needed in order to program a blank chip?
Firmware obviously (we could collaborate on a repository for all versions, so in theory we don't really need Tesla for that).
Then everything that is specific to your car: configuration & keys (anything else?).
Has anyone figured out any other way to gain access to that information? (Alternatively, might Tesla give us that information if we ask for it?)

I haven't seen what's actually in P3 (/var) yet, but from the discussion I've seen, that seems about right. I suppose other volatile stuff would be nice to be able to recover/set (odometer, trip counters).

I think the other issue would be determining which of the 2 boot partitions (P1 or P2) is active and needs to match what's on the Spansion chip....

 

[itDied]

@KLuuppo : The folks at Allsocket would very much like to have a look at your board. -So if it would be ok for you, you could package it and ship it to them (using their DHL account), and they bill me for the shipping charges.
Unfortunately, I just signed up to this forum, so I'm not allowed to PM you yet, but I'm sure that will be sorted out in the near future.

@scaesare: Good points.
Concerning the P1 or P2 issue, what would happen if we get it wrong?
I suppose if Allsocket is successful in creating this "flex cable" solution, or some other way to facilitate easy access to the chip,
it would just be a small inconvenience to try both options (given that opting for the wrong one doesn't cause any damage)

 

[scaesare]

@scaesare: Good points.
Concerning the P1 or P2 issue, what would happen if we get it wrong?
I suppose if Allsocket is successful in creating this "flex cable" solution, or some other way to facilitate easy access to the chip,
it would just be a small inconvenience to try both options (given that opting for the wrong one doesn't cause any damage)

From what I've found online about this:

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.

 

[itDied]

@Scaesare Thank you for the information
Maybe I am getting this wrong, but it seems to me that the import thing is that the firmware version in the active partition matches the one in the Spansion chip. If both partition 1 and 2 has the same firmware version, and that matches the one in the Spansion chip, you would´t really need to know which is active right? Or am I missing something?

Any chance we could get some input from you @rooter (I believe you originally provided that information above right) on this?

 

[scaesare]

@Scaesare Thank you for the information
Maybe I am getting this wrong, but it seems to me that the import thing is that the firmware version in the active partition matches the one in the Spansion chip. If both partition 1 and 2 has the same firmware version, and that matches the one in the Spansion chip, you would´t really need to know which is active right? Or am I missing something?

Any chance we could get some input from you @rooter (I believe you originally provided that information above right) on this?

I'd assume so... but I'd guess the trick is knowing which is which. I suppose you'd be relatively safe if you could determine which boot partition had the latest firmware revision, as that would ostensibly be the last success version installed. Unless the system had staged a new version in a partition that had not yet became active...

 

[scaesare]

Response #1 from All Socket:

We tried H26M42001FMR here. The reader can find the chip . Just cannot format it.

My response: "Thanks. If you have any other writers that are capable of formatting and writing to the chip, can you then read it?"

 

[scaesare]

And their other response when I mentioned the issue of needing a iuF cap on Vddi:

our engineer confirm that the BGA153/169-SD Adapter is with the 0.1uf capacitor, but it can be changed to 1uf by setting the C2(capacitor) on the SD Adapter, please view this screenshot:

So I'm considering soldering a 0.9uF cap in parallel (and perhaps making it switchable), to see if that does the trick...

 

[LuckyLuke]

I have a programmer (easy jtag plus) ordered, hope it will arrive soon and that it can read this bloody 42001 chip and get that car up and running again. I will report here when I have been able to test this.

About the p1/p2 firmware versions:
If you know what firmware your car was on it is perfectly safe to flash that firmware file (you can't find those files online, but there are some ppl sharing these privately if you ask kindly) to both p1 and p2.

p4 can be left empty afaik, it's just the home folder which holds all the secondary stuff like cache, favorites, nav history, etc.
What happens if you leave p3 empty I don't know exactly, I have not tested this myself (yet). But at least your car should be driveable, maybe without full functionality like Tesla vpn/api access. Like said: I'm not sure.

If you want to partition your fresh/empty emmc from your Linux pc with Allsocket adapter you can use this command, please replace mmcblk0 with the proper device name.

fdisk -b 512 -C 947200 -H 1 /dev/mmcblk0 < fdisk.txt

The .fdisk file is included.

 

[scaesare]

So according to All Socket, their USB based version was able to work with our Hynix chip:

DS3000-USB3.0-EMMC153

I'm going to see about exchanging mine and give it a shot.... I almost bought that one initially anyway, as it seemed preferable to having to have a seperate SD card adapter.

 

[KLuuppo]

DS3000-USB3.0-EMMC153

I have that unit, but didn't work. Then again, my chips were likely toast anyway.

I'm sending the tegra board to allsocket in the next few days. I'm a bit sceptical how well that socket solution could work in actual use with vibrations, temp changes and such... Regarding that mmc+ idea, I couldn't find any large enough cards, so guess they are too old tech already. I wonder how much effort it would take to make an emmc emulator using sd card(s) as removable media.

SC cancelled my appointment and said that they are not willing to try blank chip flashing. Had to bit the bullet and get a new mcu cluster for my own car. Approx 3k EUR here installed.

 

[scaesare]

I have that unit, but didn't work. Then again, my chips were likely toast anyway.

I'm sending the tegra board to allsocket in the next few days. I'm a bit sceptical how well that socket solution could work in actual use with vibrations, temp changes and such... Regarding that mmc+ idea, I couldn't find any large enough cards, so guess they are too old tech already. I wonder how much effort it would take to make an emmc emulator using sd card(s) as removable media.

SC cancelled my appointment and said that they are not willing to try blank chip flashing. Had to bit the bullet and get a new mcu cluster for my own car. Approx 3k EUR here installed.

Hmm... interesting that All Socket said they tested and it worked, but yours didn't. I wonder indeed if a reader or ship problem.

Does that reader work under Linux?