Philips 49PUS7909/12 Bootloop - eMMC - rewrite een optie?

Hallo forumleden.
Op de werktafel: een 49PUS7909/12 met ruim 30.000 (!) draai-uren. Helaas: de TV komt niet meer in de benen, hij blijft hangen in een bootloop. Hoewel ruim 10 jaar oud verdient deze TV wat mij betreft een tweede leven. Bijzonder mooi beeld (als hij het doet).
Over de bootloop: in de Serv-U log zie ik regelmatig "fsck" meldingen die erop lijken te duiden dat er problemen zijn met de eMMC (Toshiba THGBMAG5A1JBAIR).
In normaal bedrijf wordt de eMMC over acht datalijnen parallel beschreven en gelezen. En treden er dus problemen op. Als ik de eMMC daarentegen "in circuit" uitlees (over één datalijn (D0)) met mijn RT809H dan gaat dat zonder problemen. De files met extenties .BOOT1, .BOOT2, .EXT_C, .RPMB en .BIN heb ik op die manier kunnen veilig stellen.
De enige goede manier om met een versleten eMMC om te gaan is natuurlijk om deze te vervangen. Maar nu mijn vraag: heeft er iemand ervaring met een aanpak waarbij de eMMC in-circuit gewist wordt, en de eerder veilig gestelde files er weer worden opgeschreven? Mijn hoop is namelijk dat de boekhouding van de eMMC bij dit opnieuw beschrijven van de eMMC rekening houdt met de bad sectors. Maar misschien is die hoop onterecht. Kan iemand hier iets over zeggen vanuit zijn/haar eigen ervaring?

Een EMMC hergebruiken met al bad sectors geeft weinig hoop, dit is net russisch roulette en verhoogt bedrijfszekerheid niet..

Is het niet verstandiger om dat SSB te laten voor wat het is en te vervangen door zo'n recenter Android moederbord? William heeft die nog dacht ik.

Allereerste Android van Philips, absoluut niet meer bruikbaar en zo instabiel als de pest.

Met het vernieuwd SSB heb je toch al een stabielere tv die een even mooi beeld geeft.

Helaas Gert, de sets zijn op.

@pa3fun, de EMMC inhoud die je hebt geladen is niet meer goed, het is niet zo dat als je alle files kunt laden uit de EMMC dat deze ook goed zijn, was het maar zo'n feest. De EMMC moet vervangen worden en die moet je laden met software afkomstig uit een werkende tv, die is meestal wel te vinden op Russische websites , je hebt dan wel het probleem dat er enkele keys niet meer werken.

Toen ik mijn 42pfl8404 weg deed, stond de urenteller op 641 (eigenlijk in de 33000)...
Schijnbaar gaat de teller tot 32767 en begint dan weer op nul...

Op vrijdag 15 maart 2024 21:25:31 schreef william1967:
Helaas Gert, de sets zijn op.

@pa3fun, de EMMC inhoud die je hebt geladen is niet meer goed, het is niet zo dat als je alle files kunt laden uit de EMMC dat deze ook goed zijn, was het maar zo'n feest. De EMMC moet vervangen worden en die moet je laden met software afkomstig uit een werkende tv, die is meestal wel te vinden op Russische websites , je hebt dan wel het probleem dat er enkele keys niet meer werken.

Zit er geen crccheck op de sectoren zoals btrfs oid. Fsck duid op Linux is hij dan niet te booten van iets anders? /boot op emmc / op een usbdrive, veel tv's kunnen updaten van usb dus hij word al vroeg gemount.

Dank voor alle reacties zover.
@Beeldbuisje: ik heb twee keer eerder tot volle tevredenheid zo'n vervangend SSB van William ingezet, maar deze zijn inderdaad niet meer voorradig. Daar komt bij, dat ik die hele exercitie rond het vervangen van een eMMC best leuk/leerzaam vind :).
En over het opnieuw schrijven naar de bestaande eMMC (die niet betrouwbaar is) heeft @smd natuurlijk helemaal gelijk als hij zegt dat dit Russische roulette is. Ik wil dit alleen maar tijdelijk doen (lees: uitproberen of dit kan), in afwachting van de bestelde eMMCs.
En v.w.b. de integriteit/juistheid van de over D0/serieel/in-circuit uitgelezen files: ik weet niet precies welke vorm van integriteitscheck er over lees- en schrijfacties van een eMMC zit, maar het feit dat er CRC-checks plaatsvinden doet mij vermoeden dat als het uitlezen lukt, de uitgelezen file toch goed moet zijn?
Anyhow: ik heb de proef maar op de som genomen en de eerder uitgelezen files weer teruggeschreven. Althans, een poging daartoe ondernomen. En vastgesteld dat de schrijfoperatie naar de eMMC na verloop van tijd faalt vanwege een "write-error". Het terugplaatsen van de kleine .BOOT1, .BOOT2, .EXT-C en .PRMB-files lijkt te zijn gelukt, maar het wegschrijven van de vele malen grotere .USER-file faalt. Vermoedelijk zijn er zoveel bad sectors dat die file eenvoudigweg niet weer kan worden weggechreven, daarvoor zijn er wellicht te weinig nog goede sectoren op de eMMC.
Dus: afwachten tot de bestelde eMMC's binnen zijn. En (eigenwijs) ga ik dan tóch eerst aan de slag met de eerder uitgelezen files. Als dat niet lukt heb ik inmiddels al een "bron" voor files afkomstig uit een nog werkend toestel.
Wordt vervolgd...

Das inderdaad jammer dat die sets op zijn. Heb zelf nog eentje liggen dat ik net uit een toestel met gebroken scherm gehaald heb. Goed bewaren dus :-)

Wat wijzer worden ivm die eMMCs is een belangrijk punt, dat gaan meerdere hobbyisten nog wel kunnen appreciëren denk ik.
Het ware erg leuk als je je ontdekkingen met ons zou delen _/-\o_

Het grote manko aan emmc is dat er geen wear leveling controller bij zit. Dit zou een bestandssysteem als jffs2 moeten oplossen.

Mogelijk is er een fsck -badblocks optie.

Je zet nu een image terug over een partitie met badblocks, dan kan de crc niet kloppen.

Dank opnieuw voor de reacties.
@Tuxie: een eMMC heeft wel degelijk een wear-leveling controller aan boord. Informatie over de werking van een eMMC waarin o.a. de problematiek van wear-leveling wordt behandeld vind je terug in dit artikel van Kingston. Afhankelijk van het type eMMC / de eMMC protocol-versie die de eMMC onstersteunt kan de host de mate van wear-level van een eMMC ook uitlezen (ik meen vanaf protocol-level 5.1).
En over de "fsck -badblocks" suggestie: was het maar zo'n feest dat ik een terminal tot mijn beschikking had :) . Maar nee dus. De log-output komt uit de Serv-U poort van de TV en die poort is (in ieder geval voor zover ik weet) output-only.

** BOOTLOG **
Wie zou zijn licht eens willen laten schijnen over (de inhoud van) bijgevoegde bootlog? Van de 49PUS7909/12 die te hooi en te gras opnieuw opstart? Ik twijfel waar ik de fout moet zoeken.
Enkele in het oog lopende logregels, in willekeurige volgorde:

1. "[10.738079] TZ CPU1 ERROR[mr_find_region:67] buffer=0x00000000, size=0x00001ad0"

2. "verify boot image passed."

3. "[ 0.170507] CPU1: Unknown IPI message 0x1"

4. "[ 33343]F(SM): SM:Watchdog 1 time out (CPU0/1 dies)
System automatically reset now!"

Alle hulp is welkom.

** UPDATE **
Omdat ik nog geen feedback zag op mijn vraag betreffende de interpretatie van de bootlog en even niets beters wist te bedenken heb ik de eMMC vervangen. De eerste vervangpoging faalde, de TV deed helemaal niets meer. Hoewel, er werd toch een bootlog geschreven, zie bijlage 1.
Omdat ik twijfelde of de eMMC wel precies goed was uitgelijnd of gewoon verkeerd geplaatst was en helemaal niet functioneerde, heb ik de eMMC weer van de print gehaald en de TV eens opgestart zónder eMMC.
Ook die bootlog heb ik bijgevoegd, bijlage 2.
Mijn conclusie is a) dat de standby-processor blijkbaar óók zonder eMMC een bootlog produceert en b) dat de eMMC bij mijn eerste vervangpoging blijkbaar helemaal niet functioneerde (lees: goed geplaatst was) want de beide bootlogs zijn praktisch identiek.
Dus: eMMC gereballed, met de RT809H gecheckt of hij nog uitleesbaar/okay was, en poging twee.
Nu start de TV weer op, de eMMC zit dit keer dus goed uitgelijnd op de print, hoera :) . Helaas vertoont het toestel exact dezelfde problemen als met de oude eMMC :( ; er is dus tóch iets anders aan de hand.
Daarom nogmaals de vraag: wie-oh-wie kan er vanuit zijn ervaring aan de hand van de derde bootlog (bijlage 3) iets zeggen over wat er aan de hand zou kunnen zijn met dit toestel?

Eerlijk gezegd stop ik daar geen tijd (meer) in omdat dat me te veel tijd gaat kosten, maar wellicht de Russische "vrienden" hebben dat wel uitgediept. Maar een EMMC beschreven met data uit de defecte EMMC is niet de optie. Ik vermoed dat je opzoek moet naar de juiste data uit de EMMC, maar ik betwijfel of dat gaat matchen met de rest van mainboard..

Ik krijg meer en meer de indruk dat niet de eMMC de oorzaak is van het probleem. Als ik zelf de bootlog uit mijn vorige post bekijk, dan vallen er een aantal logregels op:

1) "verify boot image passed."
Dat klinkt mooi. Maar betekent dit dat de gehele inhoud van de eMMC okay is of alleen de files .BOOT1 en .BOOT2?

2) "Uncompressing Linux... done, booting the kernel.
[ 0.170484] CPU1: Unknown IPI message 0x1
[ 0.210435] CPU2: Unknown IPI message 0x1
[ 0.250425] CPU3: Unknown IPI message 0x1"
Kan het zijn dat de file met de Linux-kernel, welke ook afkomstig is uit de eMMC, corrupt is waardoor deze fout getriggerd wordt?

3) "[ 1.174885] tpvfsck: Checking partition /dev/block/mmcblk0p13
[ 1.180831] tpvfsck: -p /dev/block/mmcblk0p13
[ 1.264406] mmc0: ADMA error
[ 1.267509] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status "
Betekent dit dat het uitlezen van de DDR-RAM faalt? (ADMA: Advanced Direct Memory Access)?

Helaas: op basis van bovenstaande regels uit de bootlog kan ik met mijn beperkte ervaring niet zeggen wat nu echt het probleem is :( . Daarom terug naar de ervaring van anderen.
In veel postings over problemen met het QFU1.2 chassis komt naar voren dat de Marvell-BGA na verloop van tijd problemen kan krijgen met de (BGA-)contacten met de print. De TV start dan niet meer op, de standbyLED knippert aanvankelijk niet maar na enkele minuten alsnog 2x, periodiek.
"Reflowen" en "Reballing"van de BGA worden vaak als oplossing genoemd.
Op basis van die mogelijkheid maar eens de TV opgestart en tegelijkertijd de BGA met enige kracht omlaag gedrukt gehouden, in de hoop een slecht contact weer even contact te laten maken...
En wat schetst mijn verbazing? De TV gedraagt zich anders! En bij sommige pogingen start hij zelfs op?! De conclusie lijkt dan ook gerechtvaardigd dat de problemen dus toch ("gewoon") met een loszittende chip te maken hebben.
Mouwen opstropen dus en aan de gang met voor mij iets nieuws: reflowen van de Marvell-BGA.

Wordt vervolgd.

** UPDATE **
Uit nieuwsgierigheid gelijk maar de reflow van de Marvell-BGA ter hand genomen. Allereerst het koellichaam van de BGA afgehaald en vervolgens de print een half uurtje op 1300 Celsius opgewarmd op een Uyue-946C "pre-heater". Dit laatste om (naar ik heb gelezen) de thermische spanning in de print tijdens de reflow te verminderen.
Aansluitend aan één zijde van de BGA een beetje flux aangebracht. Print op zijn kant gehouden, en net zo lang hele kleine beetjes flux langs diezelfde rand van de BGA tot de flux aan de andere kant onder de BGA vandaan kwam. Dat leek mij een betrouwbare manier om zeker te weten dat de flux overal terecht zou zijn gekomen.
Vervolgens met het hot-air station de BGA opgepiept. Paar minuten op 2500 Celsius, aansluitend minuutje op 3500 Celsius en daarna kort op 4000 Celsius. Qua opwarmtemperatuur-profiel vast niet zoals het hoort/zou moeten. En hoe correct de temperatuurcalibratie van het hot-air station is weet ik ook niet...
Aansluitend heb ik de print rustig af laten koelen, schoon gemaakt met IPA en weer in het toestel gemonteerd.
Spanning erop en - niet te geloven - de TV start weer op :), zie foto.
Uit de meelopende bootlog blijkt wel dat de temperatuur van de Marvel-BGA vrij snel oploopt naar maar liefst 780 Celsius?!
Op diverse fora heb ik gelezen dat het verstandig is om de zaag in de kast te zetten en te zorgen voor extra koeling van de BGA. Dat ga ik dan ook maar doen. Ik ben benieuwd hoe lang dit toestel het na deze reflow zal blijven doen.
Tot slot nog een vraag: wie kan mij zeggen hoe je de fluxresten kunt verwijderen die tussen de BGA en de print achterblijven??

Als je een niet hygroscopische flux gebruikt kun je die gewoon laten zitten.
Behalve als de boel met solderen veel te heet is geworden (flux is toffee-achtig van kleur), die moet je wel verwijderen.

Ter voorkoming van toekomstige problemen, een koelvin erop plakken. (dat beperkt het krimpen en uitzetten van de chip)

Sjee en zo word je om de tuin geleid met al die bootlogs.. Dus bekende problemen met BGA loskomen. Fluxresten is geen probleem. Ik zou een compacte koel blok gebruiken met een Laptop fan om te koelen, gaat prima.. 78 Graden levert iDD veel stress op in de soldeer.

Ik denk voor de simpele refow zijn temperaturen wel OK

** Onverwachte wending **
Eerder schreef ik dat de TV weer werkte, na een in diezelfde posting beschreven reflow. In mijn enthousiasme dacht ik echt een reflow gedaan te hebben. Daadwerkelijk zien dat de soldeerballen onder de BGA op enig moment gesmolten waren had ik niet.
Bij mijn vermeende reflow-exercitie had ik de reflow-cyclus van tevoren vastgelegd:
- koellichaam verwijderd
- de print onder/rond de BGA met pré-heater 15 minuten op 1300C voorverwarmd
- met hot-air de BGA drie minuten op 2500C, twee minuten op 3500C, één minuut op 4000C
Omdat ik twijfelde of er daarwerkelijk een reflow had plaatsgevonden heb ik de reflow-cyclus vandaag eens uitgevoerd op een afgeschreven QFU1.2E mainboard. De conclusie: de BGA zat aan het eind van de beschreven cyclus nog steeds muurvast. Geen "reflow" dus.
Nadat alles weer tot kamertemperatuur was afgekoeld heb ik de procedure nog eens herhaald met aangepaste parameters:
- met hot-air de BGA drie minuten op 2500C, drie minuten op 3500C, drie minuten op 4500C
Ook nu zat de BGA aan het einde van die cyclus nog steeds muurvast.
Gezegd moet worden dat de temperatuur van de onderzijde van de aangeblazen BGA (waar de te reflowen soldeerballen zitten) natuurlijk significant lager zal zijn dan de uitstroomtemperatuur van het hot-air station?! Gemeten hoe heet de BGA daadwerkelijk was heb ik bij deze pogingen nog niet.
De voorlopige conclusie is dat de er in tegenstelling tot wat ik eerder dacht géén reflow heeft plaatsgevonden.
Het feit dat de TV het eerst niet deed en na de vermeende reflow-operatie wél lijkt verklaard te worden door een ander fenomeen: electromigration. Over problemen met QFU-boards en dit fenomeen valt veel meer te lezen in deze blog.

Wordt vervolgd.

Jammer genoeg werkt dat reballen of reflowen altijd maar tijdelijk, en vroeger of later is het weer raak...

Ik denk ook dat afdoende koelen de oplossing is. Alle halfgeleiders gaan kapot door de hitte...

[Bericht gewijzigd door CrossFireX op (13%)]

Ik zie in die blog niets over electromigration staan. Zou het niet kunnen dat de losse balletjes gewoon ge-re-kleid / ge-re-hot worden?

Ik zie regelmatig monitoren van 10 tot 15 jaar oud met een Sigma VXP chip (professionele videochip zonder toeters en bellen, familie van de fusion) die niet los zit. Die fabrikant gebruikt dikke printplaten, dat zou ook wel eens flink verschil kunnen maken.

Oepsie...

De link in mijn vorige posting is inderdaad niet de juiste @maartenbakker, sorry. Het is op pagina zes van deze post waar het fenomeen "electromigration" als mogelijke oorzaak voor het falen van de Fusion120- BGA's naar voren gebracht.

Voor iedereen die (nog) aan QFU- toestellen knutselt het lezen waard.

Het zou dus gaan om loslaten (bekend verschijnsel van nvidia) en elektromigratie (had ik nog niet eerder van gehoord) van de bonding. Alle symptomen en reparaties die ik tot nu toe gelezen heb, wijzen er naar mijn idee niet exclusief naar maar sluiten het ook niet uit. Let wel dat ik dan bij een geslaagde tijdelijke herstelling eerder aan loslaten denk (van de bonding of van de ballen); electromigratie is onomkeerbaar.

Nou ken ik de reputatie en ervaring van de schrijver niet, dus kan de hypothese ook op die manier niet echt op waarde schatten. Vroeger had ik altijd de indruk van badcaps dat de kreupele de blinde hielp en dat het dus de kunst was om te ontdekken wie er kon lopen en wie er kon zien, om maar even een kort door de bocht analogie te gebruiken.

Voor mij is het verschijnsel "electromigration" ook nieuw. Ik kan mij echter voorstellen dat "re-hotten" het proces van electromigration (deels) kan terugdraaien. Ik ben geen fysicus, maar waarom zouden atoomkernen die ten gevolge van electromigration op enig moment niet meer uniform in het rooster verdeeld zitten, aansluitend ten gevolge van hitte (trillen) niet terug kunnen keren naar een meer homogene verdeling? In het meest extreme geval, waarbij de geleider smelt, gebeurt dit immers ook en het fenomeen electromigration laat zien dat de atoomkernen ook bij het metaal in vaste toestand (door toedoen van een sterke electronenstroom) kunnen verplaatsen.

Vandaag heb ik met een redelijk betrouwbare warmtebeeldcamera (PC210) vastgesteld dat de temperatuur onder de P120 chip bij mijn eerdere vermeende reflow-operatie niet boven de 1500C is gekomen. Ruim onder het smeltpunt van de loodvrije soldeer waaruit die balletjes bestaan (2200C toch?). Wat mij sterkt in de overtuiging dat er met die operatie niets gebeurd is met de soldeerballetjes en het dus wel iets anders moet zijn waardoor die TV het weer is gaan doen. Daaraan voeg ik nog toe dat ik de afgelopen dagen nog drie als "onherstelbaar" geparkeerde TV's (2xQFU1.2E, 1xQFU2.1E) aan dezelfde handelingen heb blootgesteld, en ook die drie toestellen zijn weer tot leven gekomen.

Electromigration? Toeval? De barometerstand? "Geflowed" heeft er in ieder geval niets. Zeg het maar.

de kans is aanwezig dat de print iets scheefbuigen of de chip aandrukken ook iets opgeleverd had. heb iig vaker gemerkt dat je daar ook al iets mee kunt bereiken. dan komen de ic contacten weer tegen de soldeerballetjes en maken weer contact. want dat is alles, rotte solderingen onder dat te hete ic.

Electromigratie is m.i. onomkeerbaar omdat zoekgeraakte atomen niet weten waar ze naar terug moeten. Vandaar dat je op een LCD ook altijd een volkomen symmetrische wisselspanning moet zetten. Dan zijn ze nog niet ver genoeg weg voordat ze weer teruggeroepen worden, zeg maar.

Er kunnen wel meerdere problemen spelen met deze toestellen. Zo denkt iemand op badcaps dat dit standaard aan een weerstandje ligt dat ook gewoon stuk kan zijn maar dan weer niet altijd (of meestal niet) het probleem is. Ik zie op badcaps en hier ook mensen die na een reball of zelfs een echte reflow weer jaren probleemloos spelen en ik las laatst hier ook nog van iemand die een IC aandrukte tijdens het booten en dat hielp ook. Dat wijst 100% op slechte balletjes tussen BGA en print.

De gevallen waarin het reflowen of rehotten maar een tijdje helpt, kunnen of een intern aahechtingsdefect in het IC zijn, mechanische spanning in de print, of balletjes die niet lekker gevloeid hebben en daardoor net zo hard weer doorscheuren.

[Bericht gewijzigd door maartenbakker op (57%)]