Tesla Model S/X raken 'bricked' door worn-out SSD

[MadMarky]

Thralas schreef op woensdag 16 oktober 2019 @ 19:44:
[...]


Zo simpel is het niet. eMMC heeft twee keer zoveel datalijnen als een SD-kaartje. Throughput van eMMC is (daardoor, neem ik aan) in het algemeen hoger.

Zo simpel is het niet. UFS heeft veel minder datalijnen dan eMMC (serieel vs parallel) maar is 5x sneller

Het heeft in de basis allemaal te maken met kosten. Het ene type geheugen is duurder dan het andere en voor sommigen (zoals UFS) is nog weer een aparte geheugencontroller nodig.

[timberleek]

MadMarky schreef op donderdag 17 oktober 2019 @ 17:36:
[...]

Zo simpel is het niet. UFS heeft veel minder datalijnen dan eMMC (serieel vs parallel) maar is 5x sneller

Het heeft in de basis allemaal te maken met kosten. Het ene type geheugen is duurder dan het andere en voor sommigen (zoals UFS) is nog weer een aparte geheugencontroller nodig.

UFS is inderdaad sneller met minder datalijnen. Maar een Sd card en eMMC zijn hetzelfde ding (grofweg). met de helft van de datalijnen is het dan grofweg de helft zo snel (bij eenzelfde geheugentype).

UFS is veel nieuwer (kan een issue zijn op de cpu die je gebruikt), duurder en ja, sneller. Een permanente balans.

[dmantione]

Het is ext4 inderdaad.

Wablief?!

EMMC is flashgeheugen zonder controller die de levensduur maximaliseert. Dat betekent dat het maximaliseren van de levensduur in software moet gebeuren. Ext4 is geen bestandssysteem die dat soort intelligentie ingebouwd heeft. Linux heeft voor flasgeheugen zonder controller speciale bestandssystemen zoals Jffs2 en Ubifs die de wear-leveling afhandelen.

Heb je specificaties van die EMMC-chip ergens? Om te dubbelchecken dat die EMMC-chip geen wear-leveling heeft?

Ander is dit wel een JOEKEL van een ontwerpfout.

[timberleek]

Emmc heeft wel een controller, met wear levelling en alles (iig alle chips die ik gebruikt heb).

Het is alleen geen externe controller.

[MadMarky]

dmantione schreef op donderdag 17 oktober 2019 @ 21:05:
[...]


Wablief?!

EMMC is flashgeheugen zonder controller die de levensduur maximaliseert. Dat betekent dat het maximaliseren van de levensduur in software moet gebeuren. Ext4 is geen bestandssysteem die dat soort intelligentie ingebouwd heeft. Linux heeft voor flasgeheugen zonder controller speciale bestandssystemen zoals Jffs2 en Ubifs die de wear-leveling afhandelen.

Wat dacht je van tmpfs? Kun je mooi naar geheugen loggen ipv vaste opslag, ideaal voor het minder belangrijke werk en scheelt kostbare schrijfacties op je flash.

Heb je specificaties van die EMMC-chip ergens? Om te dubbelchecken dat die EMMC-chip geen wear-leveling heeft?

Ander is dit wel een JOEKEL van een ontwerpfout.

eMMC heeft geen controller, het is simpele data opslag. Wear-leveling is alleen mogelijk als je een bestandssysteem gebruikt zoals UBIFS dat daar rekening mee kan houden.

[jesselioce]

Kan er iemand mij uitleggen waarom ze bij zo een high tech auto het nodig vinden om te besparen door cheape emmc te gebruiken ipv een volwaardige ssd? En dan nog 1 die zo klein is plus het feit dat er langs de software kant geen maatregelen zijn om de levensduur te maximaliseren gezien er geen controller chip is.

[ Voor 35% gewijzigd door jesselioce op 17-10-2019 21:24 ]

[MikeyMan]

@TwOkkie er wordt in die titel met geen woord gerept over de accu

[timberleek]

MadMarky schreef op donderdag 17 oktober 2019 @ 21:14:
[...]
eMMC heeft geen controller, het is simpele data opslag.

code:

The embedded flash management software or FTL(Flash Transition Layer) of eMMC manages Wear Leveling, Bad Block Management and ECC. 
The FTL supports all features of the Samsung NAND flash and achieves optimal performance.

Om een willekeurig voorbeeld te geven (samsung klm4g1fete)

emmc is juist zo populair omdat het al die shit wel heeft. raw nand (waar je denk ik mee in de war bent) is namelijk goedkoper, maar dan moet je het zelf fixen.

jesselioce schreef op donderdag 17 oktober 2019 @ 21:18:
Kan er iemand mij uitleggen waarom ze bij zo een high tech auto het nodig vinden om te besparen door cheape emmc te gebruiken ipv een volwaardige ssd? En dan nog 1 die zo klein is plus het feit dat er langs de software kant geen maatregelen zijn om de levensduur te maximaliseren gezien er geen controller chip is.

waarom denkt iedereen dat emmc enkel een cheape optie is? Het is ongeveer de standaard in embedded electronica. Een ssd is op vele vlakken duurder, onhandiger in productie en totaal onnodig.

8Gb is daarnaast redelijk wat gezien de toepassing, ze hebben enkel de fout gemaakt de logging niet te fixen. Als dat niet was gebeurd was het waarschijnlijk nooit een issue geweest

[ Voor 52% gewijzigd door timberleek op 17-10-2019 21:28 ]

[TwOkkie]

MikeyMan schreef op donderdag 17 oktober 2019 @ 21:19:
@TwOkkie er wordt in die titel met geen woord gerept over de accu

Waar denk jij aan als het gaat over een Tesla die niet kan opladen?

[MikeyMan]

TwOkkie schreef op donderdag 17 oktober 2019 @ 21:44:
[...]


Waar denk jij aan als het gaat over een Tesla die niet kan opladen?

Bij deze titel eerder aan het laadcircuit dan aan de accu

Dit heeft werkelijk helemaal niets met framing te maken...

[ Voor 10% gewijzigd door MikeyMan op 17-10-2019 21:52 ]

[TwOkkie]

@MikeyMan En waar denk je dat het grote publiek aan denkt?

Kom op, zo dom ben je niet. Snap je echt niet wat ik bedoel of zit je gewoon een beetje te trollen?

---

@hieronder, duimpje voor jou hoor. Jij kan door de toonzetting heen de neutrale informatie lezen.

"Worst case scenario", "fear come true". Helemaal zonder lading gekozen woorden.

In het artikel is de daad van het schrijven naar /var/log omschreven als "data hoarding". Het artikel wordt ook nog eens geopend met een volle alinea waar de spot wordt gedreven met "fanboys" die geen kritiek dulden, maar nu toch een serieus probleem moeten erkennen.

Misschien moet je de definitie van Framing nog maar eens aan me uitleggen, maar volgens mij is dit het.

[ Voor 72% gewijzigd door TwOkkie op 17-10-2019 22:02 . Reden: Geen zin om een interessant topic te vervuilen met slow-chat semantisch geneuzel. ]

[MikeyMan]

Nee zo dom ben ik zeker niet... Je bent spijkers op laag water aan het zoeken. Je beschuldigt een titel van framing terwijl het een prima weergave van het probleem is.

[Snow_King]

likewise schreef op woensdag 16 oktober 2019 @ 17:26:
[...]


Kun je het filesystem (image) nog read-only mounten?

sudo mount /dev/sda3 /tmp/tesla -o ro

en dan zou je zoiets kunnen zien:

cat /sys/fs/ext4/sda3/lifetime_write_kbytes
1915628269

Als we dat delen op de eMMC size weten we hoe vaak de eMMC rond is geschreven, we kunnen de write amplication factor zelf ongeveer raden.

Ik ben met dumpe2fs gaan kijken, maar de waardes die er uit komen lijken niet te kloppen.

Staat 1888kB bij, dus dat lijkt mij niet te kloppen.

Thralas schreef op woensdag 16 oktober 2019 @ 18:45:
[...]


Hoeft niet. dumpe2fs laat 't ook zien.

# dumpe2fs -h /dev/sda1 | grep wri
dumpe2fs 1.43.4 (31-Jan-2017)
Last write time:          Fri Nov 10 22:49:24 2017
Lifetime writes:          129 GB

(Geen Tesla, enkel illustratie)

Dank! Zie dus hier boven. Ik krijg er maar weinig uit.

Image staat als loop device op mijn laptop:

code:

$ sudo dumpe2fs /dev/mapper/loop14p3|grep -i write
dumpe2fs 1.44.1 (24-Mar-2018)
Last write time:          Wed Oct 16 17:41:41 2019
Lifetime writes:          1888 kB

MikeyMan schreef op woensdag 16 oktober 2019 @ 21:34:
Hoe zeker ben je van de kwaliteit van de nieuwe soldeerverbindingen? Heb je een inschatting van de nieuwe verwachte levensduur? 8x zo groot dus 8x zo lang?

Ik heb daar wel aardig vertrouwen in. Mocht het écht kapot gaan dan kan ik altijd nog een nieuwe MCU bij Tesla kopen. Maar liever niet eigenlijk.

Het vervelende is ook dat er een levendige handel is in MCU's die je helemaal kan wipen. Maar Tesla weigert mee te werken deze weer te voorzien van de juiste software. Hun Service Centers hebben hier wel alle mogelijkheden voor, maar ze weigeren het.

dmantione schreef op donderdag 17 oktober 2019 @ 21:05:
[...]


Wablief?!

EMMC is flashgeheugen zonder controller die de levensduur maximaliseert. Dat betekent dat het maximaliseren van de levensduur in software moet gebeuren. Ext4 is geen bestandssysteem die dat soort intelligentie ingebouwd heeft. Linux heeft voor flasgeheugen zonder controller speciale bestandssystemen zoals Jffs2 en Ubifs die de wear-leveling afhandelen.

Heb je specificaties van die EMMC-chip ergens? Om te dubbelchecken dat die EMMC-chip geen wear-leveling heeft?

Ander is dit wel een JOEKEL van een ontwerpfout.

Ik vergiste mij even. Het is ext3 en niet ext4. Maar dat komt op het zelfde neer wat dat betreft.

De betreffende chip is een Hynix H26M42001FMR 8GB. Deze heb ik vervangen door een Swissbit SFEM064GB1EA1TO 64GB eMMC. Partitie laytout heb ik het zelfde gehouden.

jesselioce schreef op donderdag 17 oktober 2019 @ 21:18:
Kan er iemand mij uitleggen waarom ze bij zo een high tech auto het nodig vinden om te besparen door cheape emmc te gebruiken ipv een volwaardige ssd? En dan nog 1 die zo klein is plus het feit dat er langs de software kant geen maatregelen zijn om de levensduur te maximaliseren gezien er geen controller chip is.

Onwetendheid? Het kan zijn dat ze hier gewoon nooit aan gedacht hebben.

[timberleek]

De betreffende chip is een Hynix H26M42001FMR 8GB. Deze heb ik vervangen door een Swissbit SFEM064GB1EA1TO 64GB eMMC. Partitie laytout heb ik het zelfde gehouden.

eMMC 4.41 zat er ook nog op. Dan konden ze de slijtage iig niet monitoren, zelfs al zouden ze het willen. wear en pre-eol registers zijn pas gestandaardiseerd vanaf eMMC 5.0.

[jeroen3]

jesselioce schreef op donderdag 17 oktober 2019 @ 21:18:
Kan er iemand mij uitleggen waarom ze bij zo een high tech auto het nodig vinden om te besparen door cheape emmc te gebruiken ipv een volwaardige ssd? En dan nog 1 die zo klein is plus het feit dat er langs de software kant geen maatregelen zijn om de levensduur te maximaliseren gezien er geen controller chip is.

eMMC is helemaal niet zo goedkoop.
32 Gb zit rond een €10, schaalt misschien nog terug naar 5 als je veel reels koopt.
Gewoon parallel NAND flash kost de helft. Maar daar zit geen controller in, dus moet je wear leveling zelf oplossen.
eMMC is een prima keuze van Tesla. Een beter alternatief was een m.2 module, maar dat vereist een processor die dat ondersteund.
Volgens mij kan de SOC dat niet.
https://developer.nvidia.com/embedded/develop/hardware

[TwOkkie]

Zijn de partities op die chip te benaderen zonder soldeerwerk?

Zou het dan niet mogelijk zijn om preventief de syslogconfig aan te passen of die hele /var/log naar een tmpfs te laten wijzen?

En als wij dat niet kunnen, kan Tesla dat dan niet regelen bij een update? Of is dat nou precies wat Musk bedoelt met zijn "should be better now"?

---

Overigens heeft Autovisie ook lucht gekregen van de zaak: Tesla-monteurs: 'oudere Tesla's laden niet meer op door falende chip'. Ik zal maar niet meer zeggen wat ik van het artikel vind, maar die reacties op facebook verbazen mij niets.

[ Voor 8% gewijzigd door TwOkkie op 18-10-2019 10:52 . Reden: Media-aandacht voor dit probleem, is dat nou on- of off-topic? ]

[Snow_King]

TwOkkie schreef op vrijdag 18 oktober 2019 @ 10:46:
Zijn de partities op die chip te benaderen zonder soldeerwerk?

Zou het dan niet mogelijk zijn om preventief de syslogconfig aan te passen of die hele /var/log naar een tmpfs te laten wijzen?

Inmiddels wel, maar dat is pas een paar weken bekend. Deze 'jailbreak' methode ga ik hier niet bekend maken omdat Tesla daar anders weer een stokje voor gaat steken.

Maar het is wel te gebruiken om eerst veilig een backup te maken van je eMMC alvorens je hem vervangt.

TwOkkie schreef op vrijdag 18 oktober 2019 @ 10:46:
En als wij dat niet kunnen, kan Tesla dat dan niet regelen bij een update? Of is dat nou precies wat Musk bedoelt met zijn "should be better now"?

Ik zie in de huidige firmware nog geen verbetering. Kan zijn dat ze nu een iets betere chip er op zetten, maar syslog staat nog steeds aan.

[deepbass909]

jeroen3 schreef op vrijdag 18 oktober 2019 @ 10:23:
[...]

eMMC is helemaal niet zo goedkoop.
32 Gb zit rond een €10, schaalt misschien nog terug naar 5 als je veel reels koopt.
Gewoon parallel NAND flash kost de helft. Maar daar zit geen controller in, dus moet je wear leveling zelf oplossen.
eMMC is een prima keuze van Tesla. Een beter alternatief was een m.2 module, maar dat vereist een processor die dat ondersteund.
Volgens mij kan de SOC dat niet.
https://developer.nvidia.com/embedded/develop/hardware

Dat een SOC dat niet kan, is een kwestie van een custom soc gebruiken (waar Tesla echt de afname wel voor heeft) die het wel kan. Juist die ARM-soc's zijn tegenwoordig vrij makkelijk aan te passen.

Ik kan me wel voorstellen dat er voor een vaste chip is gekozen. Mechanische belasting is een serieus punt in iedere auto. Automotive grade onderdelen zijn ook echt van een andere orde dan voor normale elektronica geldt. De extra kosten van een microSD-slot en en het plaatsen van een microSD is geen verdediging om het niet te doen. Er zijn apparaten die in veel grotere aantallen worden geproduceerd waar intern ook een microSD in een slot zit. Maar het risico op contact verliezen onder invloed van trillingen is te groot bij die dingen.

Ik kan me, gezien de complexe systemen, wel voorstellen dat er een zekere mate van logging plaats moet blijven vinden (ik weet uit contacten met Tesla dat die logs in sommige gevallen gebruikt worden om bepaalde defecte te achterhalen). Maar er zijn prima oplossingen om overmatige slijtage te voorkomen. Een standaard dingetje is bijv. om een tmpfs aan te maken en deze eens per x-tijd naar de flash te laten wegschrijven. Of, als je ook met aanvullende hardware aan de slag gaat, een lokale batterij-backup die zorgt dat bij uitval er nog genoeg vermogen is om een geheugendump naar de eMMC te maken.

En natuurlijk de loglevels tot een absoluut minimum te beperken.

Anoniem: 1248170 schreef op woensdag 16 oktober 2019 @ 19:13:
[...]


En dat begrijp ik dus niet, het is prima dat vanuit het entertainmentsysteem op het dashboard allerlei auto functies te bedienen. Prima, want er worden fysieke knoppen uitgespaard.

Maar cruciale systemen zoals opladen, autopilot etc horen niet via dit systeem te lopen. Dit bewijst dat Tesla alles op hun eigen manier doet. Bij de gevestigde autofabrikanten is het entertainmentsysteem gescheiden van de cruciale auto systemen, ook in canbus is dit zichtbaar deze scheiding.

Ben benieuwd of Tesla uberhaupt canbus heeft, betwijfel het en dit zou eigenlijk gewoon noodzakelijk zijn.

Ja, ook een Tesla heeft CANBUS, dat is namelijk een verplichting vanuit het OBD-II/eOBD-protocol. Iedere auto moet dat hebben om typegoedkeuring te krijgen.

Op een aantal vastgelegde verplichtingen, is de CANBUS verder vrij in te richten. Vroeger was er inderdaad scheiding tussen essentiële en aanvullende functies, mede vanwege beperkte bandbreedte op de canbus. (je had een traag en snel netwerk, waarbij het trage netwerk voor zaken als de ECU wordt gebruikt). Maar inmiddels is dat geen issue meer.

@Josefien
Tot op zekere hoogte ben ik het met je eens, maar je moet niet vergeten dat een deel van al die nieuwe systemen voor de veiligheid zijn, maar ook om de auto (als hij nog op benzine of diesel rijdt) schoner te maken. Het motormanagement systeem (wat al sinds de jaren 80 een MCU is) is heel robuust opgezet, maar die wordt gevoegd met sensoren en andere data op basis waarvan andere tabellen gekozen worden voor ontsteking en brandstof injectie. Vroeger waren het alleen sensoren, maar tegenwoordig wordt die ECU steeds meer actief van buitenaf aangestuurd. En dat geldt voor heel veel systemen in een auto.

Zelfs mijn 20 jaar oude BMW heeft al 6 ECU's (dan negeer ik de eenvoudige modules die puur op basis van input werken, dit zijn de min of meer zelfstandige units). Naar huidige maatstaven zijn het trage, zwakke machines, maar toen was het de top, zeker de motorcomputer.

Maar ik vind het ook wel tricky dat tellerbakken steeds vaker LCD's worden e.d. Het ziet er prachtig uit en biedt ongelooflijk veel vrijheid, maar LCD's gaan geen 50 jaar mee.
Ik verwacht dat auto's zoals mijn cabrio uit de jaren 90, de laatste generatie zal zijn die nog echt oud kan worden zonder onbruikbaar te worden. Vanaf 2000 is de hoeveelheid elektronica zo hard toegenomen dat die auto's te kwetsbaar worden.

[Tijgert]

Noem mij een N00b, maar waarom wordt er niet naar RAM gelogd en bij uitzetten van de auto de logs pas weggeschreven naar SSD?

[Dutchneon]

Via het tesla owners forum inmiddels al gewezen op 2 adressen waar je terecht kunt om dit voor een fractie van wat Tesla rekent op te lossen.

Verstandig is om dit preventief te doen, omdat er twee unieke certificaten op de eMMC staan die overgezet moeten worden naar de nieuwe te plaatsen chip. Als mcu niet meer werkt is de kans groot dat de bestanden niet meer eenvoudig over te zetten zijn. Dan moet je dus hopen dat een data recovery specialist je nog kan helpen, ofwel alsnog bij Tesla aankloppen om de 3500 euro af te tikken

[Orion84]

Tijgert schreef op maandag 21 oktober 2019 @ 13:50:
Noem mij een N00b, maar waarom wordt er niet naar RAM gelogd en bij uitzetten van de auto de logs pas weggeschreven naar SSD?

Omdat het voor dit probleem niet uitmaakt of je continue naar de 'disk' logt, of dat aan het eind van de rit in één keer doet. Tenminste, als je in beide gevallen dezelfde hoeveelheid data opslaat.

Als je in RAM een ringbuffer aanhoudt en alleen de laatste x minuten aan logs naar disk schrijft dan helpt het. Maar dan mis je dus een boel logging (voor zover dat relevant is).

[Rmg]

Tijgert schreef op maandag 21 oktober 2019 @ 13:50:
Noem mij een N00b, maar waarom wordt er niet naar RAM gelogd en bij uitzetten van de auto de logs pas weggeschreven naar SSD?

Ze zullen ook wel logging willen hebben bij een eventueel ongeluk vd auto. En dan kan je, ondanks dat er verschillende powerbussen zijn, niet iets garanderen over stroom en kan je dus logging kwijtraken als je logged naar ram.

[The Zep Man]

Dutchneon schreef op maandag 21 oktober 2019 @ 15:34:
Verstandig is om dit preventief te doen, omdat er twee unieke certificaten op de eMMC staan die overgezet moeten worden naar de nieuwe te plaatsen chip. Als mcu niet meer werkt is de kans groot dat de bestanden niet meer eenvoudig over te zetten zijn. Dan moet je dus hopen dat een data recovery specialist je nog kan helpen, ofwel alsnog bij Tesla aankloppen om de 3500 euro af te tikken

Heerlijk, die eigenaarschap over Tesla's auto...

[Giesber]

Rmg schreef op maandag 21 oktober 2019 @ 16:03:
[...]


Ze zullen ook wel logging willen hebben bij een eventueel ongeluk vd auto. En dan kan je, ondanks dat er verschillende powerbussen zijn, niet iets garanderen over stroom en kan je dus logging kwijtraken als je logged naar ram.

Logging willen ze misschien wel hebben ja, maar of er uit de Linux syslog veel nuttige informatie gaat komen betwijfel ik toch.

Ik zou denken dat men voor logging van zaken als de stand van het gaspedaal, of de status van Autopilot, wel andere logkanalen hebben opgezet, zodat die zaken niet tussen de kernel logging staan. En als dat het geval is kan de syslog gewoon uitgezet worden op productieauto's.

Als dat niet zo is hadden ze op zijn minst kunnen bedenken dat ze de SSD kapot gingen schrijven en een duurzamer exemplaar gebruiken.

De werkelijk heeft er alle schijn van dat er gewoon niemand bij Tesla stilgestaan heeft dat dit verhaal zou kunnen gebeuren.

[deepbass909]

Rmg schreef op maandag 21 oktober 2019 @ 16:03:
[...]


Ze zullen ook wel logging willen hebben bij een eventueel ongeluk vd auto. En dan kan je, ondanks dat er verschillende powerbussen zijn, niet iets garanderen over stroom en kan je dus logging kwijtraken als je logged naar ram.

Op zich kan dat wel met een zekerheid die hoog genoeg is. Met powercaps die lokaal op de print geplaatst zijn met een stukje powermanagement zodat in geval van nood een geheugendump gemaakt wordt (dat hoeft niet netjes conform regels van het OS, een 1:1 dump naar stukje dedicated flash is genoeg, zolang de tools om het uit te lezen maar beschikbaar zijn) is dat wel haalbaar.

Giesber schreef op dinsdag 22 oktober 2019 @ 09:56:
[...]

Logging willen ze misschien wel hebben ja, maar of er uit de Linux syslog veel nuttige informatie gaat komen betwijfel ik toch.

Ik zou denken dat men voor logging van zaken als de stand van het gaspedaal, of de status van Autopilot, wel andere logkanalen hebben opgezet, zodat die zaken niet tussen de kernel logging staan. En als dat het geval is kan de syslog gewoon uitgezet worden op productieauto's.

Als dat niet zo is hadden ze op zijn minst kunnen bedenken dat ze de SSD kapot gingen schrijven en een duurzamer exemplaar gebruiken.

De werkelijk heeft er alle schijn van dat er gewoon niemand bij Tesla stilgestaan heeft dat dit verhaal zou kunnen gebeuren.

Ook de syslog kan heel waardevolle informatie bevatten over de staat van de hardware (computerzijde), dus die wil je niet zomaar weg knikkeren normaal. Maar je kan wel log-levels beperken tot bijv. alleen errors.

Overigens lijkt iedereen nu over Tesla te vallen, maar dit is echt niet een uniek probleem. Ik heb thuis routers en telefoons liggen die ook niet meer werken door vergelijkbare problemen. Verschil is alleen dat bij die apparaten de MTBF doorgaans langer is dan de te verwachten levensduur van het apparaat (7 jaar is meer dan lang genoeg voor een router of telefoon), maar ze bij Tesla dit wel over het hoofd hebben gezien. Ik ben ook wel benieuwd hoe andere fabrikanten dit hebben opgelost. Tesla zal echt niet de eerste zijn die een Linux-kernel gebruikt voor de embedded systemen (Linux wordt al 15 jaar of hiervoor gebruikt). Zo'n beetje ieder infotaiment-systeem zal met een Linux-kernel op een ARM-soc draaien, dus ook van BMW, Mercedes, VW/Audi, etc.

Grootste fout is eigenlijk dat kritische data (zoals die certificaten) op dezelfde eMMC in blijkbaar dezelfde partitie staan als waarnaar veel data wordt weggeschreven. Wat je ziet bij bijv. routers en gsm's, die ook vaak certificaten aan boord hebben, dat dergelijke data in een eigen, read-only partitie staan die ook bij falen van het werk gedeelte actief blijven.

Dit probleem maakt wel pijnlijk duidelijk dat met steeds geavanceerdere systemen in o.a. auto's het tegelijkertijd ook steeds meer een wegwerpproduct begint te worden (als er niet een goed vervangingssysteem voor computers opgezet wordt).

[MadMarky]

deepbass909 schreef op dinsdag 22 oktober 2019 @ 14:02:

[...]


Ook de syslog kan heel waardevolle informatie bevatten over de staat van de hardware (computerzijde), dus die wil je niet zomaar weg knikkeren normaal. Maar je kan wel log-levels beperken tot bijv. alleen errors.

Overigens lijkt iedereen nu over Tesla te vallen, maar dit is echt niet een uniek probleem. Ik heb thuis routers en telefoons liggen die ook niet meer werken door vergelijkbare problemen. Verschil is alleen dat bij die apparaten de MTBF doorgaans langer is dan de te verwachten levensduur van het apparaat (7 jaar is meer dan lang genoeg voor een router of telefoon), maar ze bij Tesla dit wel over het hoofd hebben gezien. Ik ben ook wel benieuwd hoe andere fabrikanten dit hebben opgelost. Tesla zal echt niet de eerste zijn die een Linux-kernel gebruikt voor de embedded systemen (Linux wordt al 15 jaar of hiervoor gebruikt). Zo'n beetje ieder infotaiment-systeem zal met een Linux-kernel op een ARM-soc draaien, dus ook van BMW, Mercedes, VW/Audi, etc.

Grootste fout is eigenlijk dat kritische data (zoals die certificaten) op dezelfde eMMC in blijkbaar dezelfde partitie staan als waarnaar veel data wordt weggeschreven. Wat je ziet bij bijv. routers en gsm's, die ook vaak certificaten aan boord hebben, dat dergelijke data in een eigen, read-only partitie staan die ook bij falen van het werk gedeelte actief blijven.

Dit probleem maakt wel pijnlijk duidelijk dat met steeds geavanceerdere systemen in o.a. auto's het tegelijkertijd ook steeds meer een wegwerpproduct begint te worden (als er niet een goed vervangingssysteem voor computers opgezet wordt).

Linux wordt overal om je heen gebruikt, al wordt er vaak gekozen voor een embedded (bijv Busybox) of enterprise (RHEL) distro ipv Ubuntu. Nu kun je natuurlijk ook Ubuntu helemaal customizen zodat het fatsoenlijk draait op een embedded-achtig systeem maar dan moet je niet vergeten om het aantal schijfacties naar storage flink te beperken. En als je daar geen zin in hebt, kun je altijd nog niet bedrijfskritische dingen als logging naar werkgeheugen (tmpfs) te laten schrijven.

Maargoed bij Tesla zijn wel meer dingen erg kort door de bocht gegaan bij productie en ontwikkeling. Dit is imho gewoon weer zo'n voorbeeld.

[Giesber]

deepbass909 schreef op dinsdag 22 oktober 2019 @ 14:02:
[...]
Tesla zal echt niet de eerste zijn die een Linux-kernel gebruikt voor de embedded systemen (Linux wordt al 15 jaar of hiervoor gebruikt). Zo'n beetje ieder infotaiment-systeem zal met een Linux-kernel op een ARM-soc draaien, dus ook van BMW, Mercedes, VW/Audi, etc.

Ik was eens benieuwd waarop andere fabrikanten hun systemen baseren, en kom uit op deze (zeer beperkte) lijst:
Audi, BMW, Ford, General Motors: een systeem gebaseerd op QNX.
Toyota: sinds 2017 een systeem gebaseerd op Linux, daarvoor QNX. De Linux distributie die ze gebruiken is Automotive Grade Linux, wat overigens pas bestaat sinds 2014, toen Tesla's al vrolijk rondreden.

Linux staat bij de meeste fabrikanten nog in de kinderschoenen (nu ja, bij de meeste fabrikanten nog niet eens in de kinderschoenen blijkbaar), alhoewel het volgens mij wel al lang stabiel genoeg moet zijn om zo'n systeem mee te maken. Ik vermoed dat de meeste merken voor zekerheid gaan, in plaats van kostenbesparing en spitstechnologie.

Ik merk in mijn zoektocht ook dat verschillende merken de boel gewoon uitbesteden in plaats van er zelf aan te beginnen. Ik begrijp dat Tesla zoveel mogelijk zelf wil doen, maar dat heeft als beginnend bedrijf (in automotive termen) dus ook serieuze nadelen en risico's.

[Dutchneon]

The Zep Man schreef op maandag 21 oktober 2019 @ 16:17:
[...]
Heerlijk, die eigenaarschap over Tesla's auto...

ja op zich wel ja, mijn 6 jaar oude S met 260k op de teller heeft nog een werkend scherm en ik heb dit jaar enkel een handgreep moeten reparen en een set achterbanden vervangen.
De auto die ik voor de Tesla had, was ik voor enkel de brandstof al 4500 euro duurder uit geweest, en hadden drie kleine beurten voor de kleine 60.000km die ik gereden heb toch zeker 1500 euro gekost...

Als ik dus de MCU gewoon bij tesla laat vervangen als hij kapot gaat, ben ik nogsteeds voordeliger uit dan blijven rijden met mijn oude diesel.....

[Snow_King]

Dutchneon schreef op dinsdag 22 oktober 2019 @ 23:33:
[...]


ja op zich wel ja, mijn 6 jaar oude S met 260k op de teller heeft nog een werkend scherm en ik heb dit jaar enkel een handgreep moeten reparen en een set achterbanden vervangen.
De auto die ik voor de Tesla had, was ik voor enkel de brandstof al 4500 euro duurder uit geweest, en hadden drie kleine beurten voor de kleine 60.000km die ik gereden heb toch zeker 1500 euro gekost...

Als ik dus de MCU gewoon bij tesla laat vervangen als hij kapot gaat, ben ik nogsteeds voordeliger uit dan blijven rijden met mijn oude diesel.....

Ik zou je wel aanraden de eMMC nu te vervangen. In Eindhoven zit iemand die dit zo voor je kan doen: https://www.laadkabelwink...-emmc-vervangen-reparatie

[Dutchneon]

Snow_King schreef op woensdag 23 oktober 2019 @ 08:17:
[...]

Ik zou je wel aanraden de eMMC nu te vervangen. In Eindhoven zit iemand die dit zo voor je kan doen: https://www.laadkabelwink...-emmc-vervangen-reparatie

ik was al van plan hem te bellen

[Snow_King]

Om een update te geven. Mijn situatie was dat vóór we wisten hoe we de VPN certificaten konden lezen van de chip die van mij overleed.

Ik heb toen wel een nieuwe eMMC geplaatst met daar op de juiste firmware, maar mijn auto was zijn VPN credentials kwijt. De Tesla app deed het dus niet meer.

Sinds 5 September 2019 was mijn auto niet meer online omdat er geen VPN verbinding was.

Mijn oude 8GB Hynix chip heb ik toen gestuurd naar: https://multi-com.eu/

Zij hebben vervolgens maandenlang geprobeerd data van deze chip af te krijgen. Uiteindelijk hebben ze een donor chip (exact zelfde type) besteld en mijn oude chip naar -30C gekoeld.

Door direct het NAND uit te lezen en ECC correctie met de nieuwe chip toe te passen hebben ze de volgende files kunnen lezen:

- car.crt
- car.key
- ta.key
- ca.crt

Via SSH heb ik deze files weer terug geplaatst in mijn auto en daarna een reboot gegeven. De VPN tunnel met Tesla is weer online!

Tesla weigerde op elke manier mee te werken aan mijn verzoek tot herstel van de VPN certificaten. Ze wilden alleen de gehele MCU vervangen voor EUR 2500. Mails, brieven, telefoontjes, Tesla weigerde mee te werken.

Deze data recovery ging voor een flat-fee van EUR 250 en nog een donor chip van EUR 30. Een stuk goedkoper (en ook leuker!) dan bij Tesla een nieuwe MCU kopen.

Mijn auto heeft nu een 64GB Swissbit chip en de MCU is ook merkbaar sneller.

Mocht je ooit voor een chip datarecovery nodig hebben, dan raad ik deze partij in Polen echt aan: https://multi-com.eu/