Tiez dakujem za vysvetlenie a mal by som otazku.
Ako sa da rozpoznat kde sa to BBT a ZVB nachadza?
Je to nejak oznacene?
Vysvetlenie poruchovosti NAND K9GAG08U0E v D55XX/D57XX TV
Moderátor: Moderátoři
Napíš s ktorým programátorom pracuješ.
Všeobecne treba:
- ak programátor má rôzne metódy prístupu k pamäti, treba zvoliť prístup k celej oblasti nand, to znamená aby pracoval so všetkými blokmi, inak nestiahneš úplne všetko z nand ako zálohu, ale to sa asi týka len Elnec programátorov, ostatné programátory (čínske) väčšinou pracujú defaultne s celou nand ako RAW data, to znamená, že sťahujú všetko od adresy 0 do konca pamäte čo je adresa 88A7D7FF hexa.
- zálohovať (stiahnuť) obsah nand do PC a vo vytvorenom bin súbore alebo v buffri obslužného softu programátora je začiatok BBT od adresy 869D93B8 hexa.
To si vieš pozreť buď ako som písal v buffri softu programátora, alebo v nejakom hex prehliadači či editore.
Najjednoduchšie asi prehliadačom súborov v total commanderi pomocou F3 s nastavením zobrazovania hexadecimálne avšak voľba priamej adresy, ktorú chceš pozreť tam nie je možná, tak preklikávať sa na správnu adresu trvá dlho.
Total commander má ale možnosť porovnania dvoch bin súborov medzi sebou avšak limit veľkosti súboru je obmedzený veľkosťou RAM v konkrétnom PC.
Presúvanie, editácia v bufferi, vytváranie súborov z výsekov dát z buffra od adresy, načítavanie takýchto súborov od určitej adresy do buffra je napr. možné aj obslužným softom k programátorom elnec v demo režime bez programátora. Takže by som ako začiatočník začal tým.
Pre zachovanie BBT a kopírovanie do iného dumpu stačí uložiť výsek dát od 869D93B8 hexa do konca zo zalohového súboru alebo takého z ktorého chceš zachrániť BBT a tento vytvorený výsek súbor potom načítať do buffera od adresy 869D93B8 kde si si predtým natiahol súbor, do ktorého chceš zachránenú BBT preniesť.
ZVB nie každý programátor zobrazuje, niektoré len počet zlých blokov podľa ZVB, ale nie ich čísla, niektoré zobrazia čísla blokov až po zmazaní nand tým sa samozrejme zmaže aj BBT, preto je nutné predtým zálohovať obsah nand a niektoré majú na to voľbu, ktorá väčšinou tiež zmaže nand.
Formát zobrazenia čísel zlých blokov podľa ZVB väčšina programátorov zobrazuje len v desiatkovej sústave (teda čísla od 1-2076 alebo 0-2075), niektoré aj v hexa. Ale BBT ich má samozrejme v hexa.
Na prevod z desiatkovej do hexa a naopak sa dá použiť kalkulačka vo Windows v programátorskom režime.
Takže poľa horeuvedeného príkladu bloky 220 a 1400 desiatkovo budú v hexa DC (00DC) a 578 (0578) čo v BBT bude vidno takto: DC 00 a 78 05.
Každopádne pri vytváraní pripravovaného dumpu z ok zdrojového dumpu okrem presunu výseku dát platnej BBT do ok zdrojového dumpu je potrebné aj presunúť obsahy blokov zdrojového dumpu, ktorých sa to týka (označených v platnej BBT ako vadné) do blokov označených v BBT ako rezervné, inak to nemá žiaden zmysel, keďže systém dobré dáta na základe BBT bude hladať v označenom rezervnom bloku a nie v bloku označenom ako vadný. A samozrejme ak tie dáta v rezervnom bloku nenájde, tak teľka skolabuje a bude sa reštartovať.
Keďže dump súbor je vo veľkosti RAW tak prvý blok začína od adresy 0 po adresu 10D9FF hexa a následne od 10DA00 začína blok č. 2 do 21B3FF a č.3 od 21B400 atď až do konca pamäte.
To sa dá ľahko skontrolovať a to tak že vydelíš poslednú adresu pamäte +1 88A7D800 hexa (2292701184 desiatkovo celkový počet bajtov pamäte) veľkosťou jedného bloku 10DA00 hexa (1104384 bajtov desiatkovo je počet bajtov v jednom bloku) a výde ti číslo 81C hexa (2076 desiatkovo) čo je počet blokov tejto pamäte v číslovaní od 1-2076.
To aj znamená, že BBT sa nachádza v bloku 2045.
Prečo som v prvej správe písal o tom, že pamäť má celkový počet blokov 2074? Pretože od bloku 2073, ktorý je vždy vadný a nepočíta sa ako závada sú v bloku 2074-2076 interné dáta výrobcu nand, ktoré nie je možné čítať - načítajú sa len samé FF a nedajú sa zmazať, to znamená, že tam niekde je zamaskovaná aj ZVB, ID pamäte (signatúra výrobcu a typu) a pod.
Tie programátory, čo vedia načítať ZVB bez zmazania pamäte to robia na základe skenu obsahu pamäte na konci každého bloku (na prvom bloku je to na adresách od 100000 do 10D9FF) kde sú uložené 00 hexa ak je blok označený ako vadný.
Avšak ak nahrajem do pamäte cudzí dump, môže sa stať a stáva sa (ak pôvodná pamäť z ktorej je súbor mala vadné bloky či už ZVB alebo aj navyše iné v BBT okrem tých zo ZVB), že ako vadné budú označené aj bloky, ktoré boli vadné len v pôvodnej pamäti z ktorej je dump stiahnutý a tak pre zistenie skutočnej ZVB je vždy potrebné pamäť najprv vymazať a tým v blokoch, ktoré v skutočnosti niesú vadné už 00 hexa na týchto adresách nebude.
Vlastne kopírovaním cudzieho dumpu prenesieš info, že aj na tejto pamäti sú rovnaké bloky vadné.
Ale za predpokladu, že prenesená a platná BBT obsahuje aj bloky, ktoré sú vadné aj v pamäti, ktorú teraz riešiš, to nie je závadu a dump bude dobre a dlhodobo fungovať, samozrejme iba ak ti verifikácia po nahratí prejde bez chýb väčších ako 24/1kB.
A tu som sa zas dostal k tomu, že na niektorých programátoroch sa nedá nastaviť tolerantná verifikácia obsahu alebo ak taká verifikácia tam je možná, potom sa nedá nastaviť pri akom počte chýb na 1kB pamäte programátor zastaví verifikáciu s upozornením, že je prekročený počet chýb a po verifikácii celého obsahu len vypíše počet chýb v celej pamäti, ktorý je bezvýznamná informácia z hladiska fungovania dumpu, keďže nie je upresnené kde a ako na husto sú chyby rozmiestnené alebo napíše počet blokov, kde boli chyby ale nie ich čísla, takže tiež nepoužiteľná informácia.
Elnec a niektoré ďaľšie píšu bud každú bitovú chybu a adresu kde bola zistená, prípadne blok kde sa nachádza a ak strop na 1kB neprekročí nastavený počet chýb, tak pokračujú s verifikáciou a tak po úspešnej verifikácii bez chybového hlásenia prekročenia stropu si môžeš byť istý, že pamäť pobeží.
Čo som videl na jednom inom type, že dal sa nastaviť strop počtu chýb na 8kB čo zase nie je ono, lebo systém v TV robí s 1kB kusmi pri oprave bitových chýb a tak ak mám nastavených povedzme 8x24 chýb na 8kB nie je to záruka, že dump pobeží keďže všetkých 192 chýb môže byť v jednom úseku 1kB a to určite fungovať nebude.
A zase ak nastavím kompromis povedzme 20 chýb na 8kB, môže mi niektorý čip vyhodiť chybu a aj tak dobre pobeží, lebo 20 chýb môže byt rozložených po 1-3 v jednotlivých 1kB úsekoch v rámci 8kB.
Všeobecne treba:
- ak programátor má rôzne metódy prístupu k pamäti, treba zvoliť prístup k celej oblasti nand, to znamená aby pracoval so všetkými blokmi, inak nestiahneš úplne všetko z nand ako zálohu, ale to sa asi týka len Elnec programátorov, ostatné programátory (čínske) väčšinou pracujú defaultne s celou nand ako RAW data, to znamená, že sťahujú všetko od adresy 0 do konca pamäte čo je adresa 88A7D7FF hexa.
- zálohovať (stiahnuť) obsah nand do PC a vo vytvorenom bin súbore alebo v buffri obslužného softu programátora je začiatok BBT od adresy 869D93B8 hexa.
To si vieš pozreť buď ako som písal v buffri softu programátora, alebo v nejakom hex prehliadači či editore.
Najjednoduchšie asi prehliadačom súborov v total commanderi pomocou F3 s nastavením zobrazovania hexadecimálne avšak voľba priamej adresy, ktorú chceš pozreť tam nie je možná, tak preklikávať sa na správnu adresu trvá dlho.
Total commander má ale možnosť porovnania dvoch bin súborov medzi sebou avšak limit veľkosti súboru je obmedzený veľkosťou RAM v konkrétnom PC.
Presúvanie, editácia v bufferi, vytváranie súborov z výsekov dát z buffra od adresy, načítavanie takýchto súborov od určitej adresy do buffra je napr. možné aj obslužným softom k programátorom elnec v demo režime bez programátora. Takže by som ako začiatočník začal tým.
Pre zachovanie BBT a kopírovanie do iného dumpu stačí uložiť výsek dát od 869D93B8 hexa do konca zo zalohového súboru alebo takého z ktorého chceš zachrániť BBT a tento vytvorený výsek súbor potom načítať do buffera od adresy 869D93B8 kde si si predtým natiahol súbor, do ktorého chceš zachránenú BBT preniesť.
ZVB nie každý programátor zobrazuje, niektoré len počet zlých blokov podľa ZVB, ale nie ich čísla, niektoré zobrazia čísla blokov až po zmazaní nand tým sa samozrejme zmaže aj BBT, preto je nutné predtým zálohovať obsah nand a niektoré majú na to voľbu, ktorá väčšinou tiež zmaže nand.
Formát zobrazenia čísel zlých blokov podľa ZVB väčšina programátorov zobrazuje len v desiatkovej sústave (teda čísla od 1-2076 alebo 0-2075), niektoré aj v hexa. Ale BBT ich má samozrejme v hexa.
Na prevod z desiatkovej do hexa a naopak sa dá použiť kalkulačka vo Windows v programátorskom režime.
Takže poľa horeuvedeného príkladu bloky 220 a 1400 desiatkovo budú v hexa DC (00DC) a 578 (0578) čo v BBT bude vidno takto: DC 00 a 78 05.
Každopádne pri vytváraní pripravovaného dumpu z ok zdrojového dumpu okrem presunu výseku dát platnej BBT do ok zdrojového dumpu je potrebné aj presunúť obsahy blokov zdrojového dumpu, ktorých sa to týka (označených v platnej BBT ako vadné) do blokov označených v BBT ako rezervné, inak to nemá žiaden zmysel, keďže systém dobré dáta na základe BBT bude hladať v označenom rezervnom bloku a nie v bloku označenom ako vadný. A samozrejme ak tie dáta v rezervnom bloku nenájde, tak teľka skolabuje a bude sa reštartovať.
Keďže dump súbor je vo veľkosti RAW tak prvý blok začína od adresy 0 po adresu 10D9FF hexa a následne od 10DA00 začína blok č. 2 do 21B3FF a č.3 od 21B400 atď až do konca pamäte.
To sa dá ľahko skontrolovať a to tak že vydelíš poslednú adresu pamäte +1 88A7D800 hexa (2292701184 desiatkovo celkový počet bajtov pamäte) veľkosťou jedného bloku 10DA00 hexa (1104384 bajtov desiatkovo je počet bajtov v jednom bloku) a výde ti číslo 81C hexa (2076 desiatkovo) čo je počet blokov tejto pamäte v číslovaní od 1-2076.
To aj znamená, že BBT sa nachádza v bloku 2045.
Prečo som v prvej správe písal o tom, že pamäť má celkový počet blokov 2074? Pretože od bloku 2073, ktorý je vždy vadný a nepočíta sa ako závada sú v bloku 2074-2076 interné dáta výrobcu nand, ktoré nie je možné čítať - načítajú sa len samé FF a nedajú sa zmazať, to znamená, že tam niekde je zamaskovaná aj ZVB, ID pamäte (signatúra výrobcu a typu) a pod.
Tie programátory, čo vedia načítať ZVB bez zmazania pamäte to robia na základe skenu obsahu pamäte na konci každého bloku (na prvom bloku je to na adresách od 100000 do 10D9FF) kde sú uložené 00 hexa ak je blok označený ako vadný.
Avšak ak nahrajem do pamäte cudzí dump, môže sa stať a stáva sa (ak pôvodná pamäť z ktorej je súbor mala vadné bloky či už ZVB alebo aj navyše iné v BBT okrem tých zo ZVB), že ako vadné budú označené aj bloky, ktoré boli vadné len v pôvodnej pamäti z ktorej je dump stiahnutý a tak pre zistenie skutočnej ZVB je vždy potrebné pamäť najprv vymazať a tým v blokoch, ktoré v skutočnosti niesú vadné už 00 hexa na týchto adresách nebude.
Vlastne kopírovaním cudzieho dumpu prenesieš info, že aj na tejto pamäti sú rovnaké bloky vadné.
Ale za predpokladu, že prenesená a platná BBT obsahuje aj bloky, ktoré sú vadné aj v pamäti, ktorú teraz riešiš, to nie je závadu a dump bude dobre a dlhodobo fungovať, samozrejme iba ak ti verifikácia po nahratí prejde bez chýb väčších ako 24/1kB.
A tu som sa zas dostal k tomu, že na niektorých programátoroch sa nedá nastaviť tolerantná verifikácia obsahu alebo ak taká verifikácia tam je možná, potom sa nedá nastaviť pri akom počte chýb na 1kB pamäte programátor zastaví verifikáciu s upozornením, že je prekročený počet chýb a po verifikácii celého obsahu len vypíše počet chýb v celej pamäti, ktorý je bezvýznamná informácia z hladiska fungovania dumpu, keďže nie je upresnené kde a ako na husto sú chyby rozmiestnené alebo napíše počet blokov, kde boli chyby ale nie ich čísla, takže tiež nepoužiteľná informácia.
Elnec a niektoré ďaľšie píšu bud každú bitovú chybu a adresu kde bola zistená, prípadne blok kde sa nachádza a ak strop na 1kB neprekročí nastavený počet chýb, tak pokračujú s verifikáciou a tak po úspešnej verifikácii bez chybového hlásenia prekročenia stropu si môžeš byť istý, že pamäť pobeží.
Čo som videl na jednom inom type, že dal sa nastaviť strop počtu chýb na 8kB čo zase nie je ono, lebo systém v TV robí s 1kB kusmi pri oprave bitových chýb a tak ak mám nastavených povedzme 8x24 chýb na 8kB nie je to záruka, že dump pobeží keďže všetkých 192 chýb môže byť v jednom úseku 1kB a to určite fungovať nebude.
A zase ak nastavím kompromis povedzme 20 chýb na 8kB, môže mi niektorý čip vyhodiť chybu a aj tak dobre pobeží, lebo 20 chýb môže byt rozložených po 1-3 v jednotlivých 1kB úsekoch v rámci 8kB.
Trochu mi to trvalo stravit nove informacie za ktore este raz dakujem.
Programatorov mam k dispozicii niekolko. Xeltek 6100N, TNM5000 a aj RT809H.
RT809H uz velmi nepouzivam, lebo stale sa tam nachadzaju nejake virusy.
Pozeral som subor co tu mam z funkcnej pamete a nejak mi tam nieco nesedi.
Mozno je viac variacii co samsung pouziva ako napln do tych K9GAG.
Mozno iny model telky a BBT je niekde inde?
Blok 2045 v tejto pameti obsahuje na zaciatku toto:
55 50 43 48 ff 07 fc 07 00 00 ff ff 01 00 00 00
02 00 00 00 01 00 00 00 01 00 00 00 00 08 00 00
00 08 00 00 ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
to prve dvojcislie 55 50 by mohlo byt 555h co by bol blok 1365, ale
druhe dvojcislie 43 48 mi nedava zmysel 4843h - to by bolo 18499.
To cislo je prilis velke aby bolo cislo bloku.
Programatorov mam k dispozicii niekolko. Xeltek 6100N, TNM5000 a aj RT809H.
RT809H uz velmi nepouzivam, lebo stale sa tam nachadzaju nejake virusy.
Pozeral som subor co tu mam z funkcnej pamete a nejak mi tam nieco nesedi.
Mozno je viac variacii co samsung pouziva ako napln do tych K9GAG.
Mozno iny model telky a BBT je niekde inde?
Blok 2045 v tejto pameti obsahuje na zaciatku toto:
55 50 43 48 ff 07 fc 07 00 00 ff ff 01 00 00 00
02 00 00 00 01 00 00 00 01 00 00 00 00 08 00 00
00 08 00 00 ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
to prve dvojcislie 55 50 by mohlo byt 555h co by bol blok 1365, ale
druhe dvojcislie 43 48 mi nedava zmysel 4843h - to by bolo 18499.
To cislo je prilis velke aby bolo cislo bloku.
toto je americky model kde ten K9GAG je.Heno píše:To zas mne niečo nesedí lebo model D7000 používa dosky BN41-01622, ktoré nemajú K9GAG08U0E, takže si sa pomýlil.
Avšak tabuľka vyzerá ok, tak ako píšeš, blok 658 presmerovaný na 2043 rezervný.
Ak by tam boli ešte ďaľšie, nasledujúci rezervný na presmerovanie je 2042 (07FA) atď.
BN41-01605 a je rovnaky aj pre D6500.
Nefunkcne dosky mam momentalne 2, aj ked sa mi zda ze pri jednej to NAND nebude, mozno SEMS21
Telku kde by som to vedel odskusat momentalne nemam ...
Nechcem odbocit od temy, ale niekedy vymena NANDu dosku neopravi a na tej co spominam procesor vyzera byt prehriaty.
Ci su to americke alebo europske modely problem je ten isty...
Skontroloval som blok 658 a skutocne je tam dost vela miest s 00 00, ale su tam aj nejake data.
Predpokladam, ze sa to napise naraz a potom sa blok oznaci ako zly a nejake data tam ostanu? Alebo sa cast vyuzije na nieco?
Prehladal som aj subor, ale 92 02 fb 07 je len na jednom mieste.
Takze k druhej tabulke nemame pristup?
Ci su to americke alebo europske modely problem je ten isty...
Skontroloval som blok 658 a skutocne je tam dost vela miest s 00 00, ale su tam aj nejake data.
Predpokladam, ze sa to napise naraz a potom sa blok oznaci ako zly a nejake data tam ostanu? Alebo sa cast vyuzije na nieco?
Prehladal som aj subor, ale 92 02 fb 07 je len na jednom mieste.
Takze k druhej tabulke nemame pristup?
Ako vyzerá priehriaty CPU? Pošli fotku.
Nikde som nikdy nepísal, že oprava obsahu nand je univárzálne riešenie na opravu všetkých MB tohoto alebo podobného typu.
Nie je, lebo európske modely D7000 používajú ako som písal inú dosku a iný cpu.
A tá tvoja doska má K9GAG08U0E, to ešte neznamená, že sa tam nahrávajú tie isté dáta ako na BN41-01660 D55XX/D57XX alebo jedna rodina plaziem.
Avšak spôsob použitia BBT môže byt rovnaký keďže je to Samsung.
Dôležité je či na konci bloku na adresách, ktoré som vysvetloval sú rady núl ak áno blok je chybný a môže to byt blok doplnený ako chybný počas prevádzky a tak to niečo čo si tam videl je pozostatok toho čo tam kedysi bolo.
Pošly výsek súbor toho bloku.
Dve BBT sú len zriedka aj to neviem prečo, či to bola chyba softu.
Keďže nechceš alebo nevieš zmazat nand, lebo je funkčná a máš pochopitelne obavu, že zálohu programátor nenahraje tak ako má a už funkčná nebude, tak asi nezistíš, či spomenutý vadný blok je aj v ZVB a to by znamenalo, že tam bol od výroby čipu.
Nikde som nikdy nepísal, že oprava obsahu nand je univárzálne riešenie na opravu všetkých MB tohoto alebo podobného typu.
Nie je, lebo európske modely D7000 používajú ako som písal inú dosku a iný cpu.
A tá tvoja doska má K9GAG08U0E, to ešte neznamená, že sa tam nahrávajú tie isté dáta ako na BN41-01660 D55XX/D57XX alebo jedna rodina plaziem.
Avšak spôsob použitia BBT môže byt rovnaký keďže je to Samsung.
Dôležité je či na konci bloku na adresách, ktoré som vysvetloval sú rady núl ak áno blok je chybný a môže to byt blok doplnený ako chybný počas prevádzky a tak to niečo čo si tam videl je pozostatok toho čo tam kedysi bolo.
Pošly výsek súbor toho bloku.
Dve BBT sú len zriedka aj to neviem prečo, či to bola chyba softu.
Keďže nechceš alebo nevieš zmazat nand, lebo je funkčná a máš pochopitelne obavu, že zálohu programátor nenahraje tak ako má a už funkčná nebude, tak asi nezistíš, či spomenutý vadný blok je aj v ZVB a to by znamenalo, že tam bol od výroby čipu.
Heno píše:Ako vyzerá priehriaty CPU? Pošli fotku.
vidno to z druhej strany. Plosak zmenil farbu
Nikde som nikdy nepísal, že oprava obsahu nand je univárzálne riešenie na opravu všetkých MB tohoto alebo podobného typu.
Nie je, lebo európske modely D7000 používajú ako som písal inú dosku a iný cpu.
A tá tvoja doska má K9GAG08U0E, to ešte neznamená, že sa tam nahrávajú tie isté dáta ako na BN41-01660 D55XX/D57XX alebo jedna rodina plaziem.
Avšak spôsob použitia BBT môže byt rovnaký keďže je to Samsung.
To viem, ze obsah nie je to iste. Snazim sa pochopit ako sa naraba so zlymi blokmi a ci by som vedel nieco s tym urobit. To sa mi zda, ze je rovnake aj v EU aj v US
Dôležité je či na konci bloku na adresách, ktoré som vysvetloval sú rady núl ak áno blok je chybný a môže to byt blok doplnený ako chybný počas prevádzky a tak to niečo čo si tam videl je pozostatok toho čo tam kedysi bolo.
Pošly výsek súbor toho bloku.
Dve BBT sú len zriedka aj to neviem prečo, či to bola chyba softu.
Keďže nechceš alebo nevieš zmazat nand, lebo je funkčná a máš pochopitelne obavu, že zálohu programátor nenahraje tak ako má a už funkčná nebude, tak asi nezistíš, či spomenutý vadný blok je aj v ZVB a to by znamenalo, že tam bol od výroby čipu.
pozrel som ten blok , ale tam sa striedaju len 00 a ff, nic ine tam nie je
- Přílohy
-
-
- block658.rar
- (1.04 KiB) Staženo 189 x
"vidno to z druhej strany. Plosak zmenil farbu"
Predpokladám, že to čo si predložil ako fotku si sám vyfotil ako stav tvojej nefunkčnej dosky, o ktorej si myslíš že nefunguje z dôvodu prehriatia cpu.
Ak ide o dosku s cpu SEMS21 ako si písal minule, je to z mojho pohladu bežný stav po 3 a viac rokoch normálneho používania TV s cpu SEMS21, lebo to často vídavam ako bežný stav v prípade, že pri montáži TV v závode nepoužili dochladzovaciu silikónovú gumu medzi doskou a lcd panelom.
To znamená, že niektoré verzie TV so SEMS21 mávajú gumu a nemajú chladič na cpu a niektoré zase majú chladič a nemajú gumu.
Tie čo nemajú gumu a majú len chladič vyzerajú presne takto a fungujú, takže to nie je dôvod myslieť si, že doska nefunguje z dôvodu deštrukcie cpu prehriatím.
To, či vyfotená doska mala alebo nemala pod sebou gumu sa dá zistiť tým, že by bola odspodu doska mastná, čo na fotke len ťažko uvidím.
Pomerne rýchla deštrukcia cpu prehriatím by nastala ak by cpu nemal ani chladič a ani gumu odspodu, takže na to si aj treba dávať pozor.
Preto aj po oprave dosiek so SEMS21 a iných, kde cpu chladič nemá, tak vždy ho nalepujem, keďže neviem do akej verzie TV dosku namontuje ten, ktorému opravenú dosku posielam a on tento fakt ani nemusí chápať, ale keď sa doska pokazí, bude chcieť riešiť mieru zavinenia nie jeho vlasnou vinou.
"To viem, ze obsah nie je to iste. Snazim sa pochopit ako sa naraba so zlymi blokmi a ci by som vedel nieco s tym urobit. To sa mi zda, ze je rovnake aj v EU aj v US"
Ak to vieš, tak odkedy, lebo tvoje otázky bývajú dosť nejasné a niekedy aj odpovede. Ak chceš predísť nedorozumeniam, vyjadruj sa jasnejšie. Tak tebe sa zdá byť spôsob managementu BB v tej pamäti rovnaký v porovnaní s D55XX/D57XX...
Mne tiež ako som písal už v predošlej správe
"pozrel som ten blok, ale tam sa striedaju len 00 a ff, nic ine tam nie je"
To je to čo som mal na mysli, že sú tam samé nule, pretože FF niesú dáta ak sú to súvislé bloky a súvislé bloky núl vlastne tiež niesú dáta.
Takže takýmto spôsobom je označený chybný blok buď z výroby čipu alebo takýmto obsahom môže byť nahratý v prípade, že systém označil tento blok za zlý dodatočne počas používania TV a updatoval info o tom do BBT, prípadne ide o kópiu cudzieho dumpu, ktorý mal na čipe tento block vadný naozaj.
To či ide naozaj o zlý blok v tomto čipe od novoty alebo až dodatočný sa dá zistiť ako som už písal len porovnaním obsahu BBT s tým čo napíše programátor pri mazaní čipu ak túto funkciu podporuje. RT809H ju podporuje, TNM5000 nenapíše čísla blokov, len ich počet a ten tretí Xeltek taiwanský nepoznám.
Takže čo si písal, že tam ešte niečo malo byť, je vlastne nič ako som si myslel už predtým...
Takže to zhrniem podľa toho čo si písal...
Keďže máš zálohu pamäte, ktorá v doske funguje a máš ešte jednu predpokladám rovnakú dosku, ktorú si označil, že má prehriaty cpu, ale nemáš na čom ani jednu z tých dosiek otestovať, tak momentálne nevieš urobiť nič.
Overoval som si, že tvoja doska, ktorú si označil ako BN41-01605 sa používa v plazmových TV PN/PS 51/59 D6500/D6900 a tam je obsah nand identický s UEXXD55XX/D57XX avšak či je tvoj model americká verzia plazmy alebo LCD to ti nepoviem.
Ak by to bol LCD, tak by som tú tvoju dosku na testovanie do plazmy určite nestrkal.
Až budeš mať komplet TV pre túto dosku, potom si najprv otestuj dosky tam a napíš ako sa závada na nefunkčnej prejavuje a podľa toho už by sme mohli vedieť viac či má zmysel nand opravovať alebo nie.
Predpokladám, že to čo si predložil ako fotku si sám vyfotil ako stav tvojej nefunkčnej dosky, o ktorej si myslíš že nefunguje z dôvodu prehriatia cpu.
Ak ide o dosku s cpu SEMS21 ako si písal minule, je to z mojho pohladu bežný stav po 3 a viac rokoch normálneho používania TV s cpu SEMS21, lebo to často vídavam ako bežný stav v prípade, že pri montáži TV v závode nepoužili dochladzovaciu silikónovú gumu medzi doskou a lcd panelom.
To znamená, že niektoré verzie TV so SEMS21 mávajú gumu a nemajú chladič na cpu a niektoré zase majú chladič a nemajú gumu.
Tie čo nemajú gumu a majú len chladič vyzerajú presne takto a fungujú, takže to nie je dôvod myslieť si, že doska nefunguje z dôvodu deštrukcie cpu prehriatím.
To, či vyfotená doska mala alebo nemala pod sebou gumu sa dá zistiť tým, že by bola odspodu doska mastná, čo na fotke len ťažko uvidím.
Pomerne rýchla deštrukcia cpu prehriatím by nastala ak by cpu nemal ani chladič a ani gumu odspodu, takže na to si aj treba dávať pozor.
Preto aj po oprave dosiek so SEMS21 a iných, kde cpu chladič nemá, tak vždy ho nalepujem, keďže neviem do akej verzie TV dosku namontuje ten, ktorému opravenú dosku posielam a on tento fakt ani nemusí chápať, ale keď sa doska pokazí, bude chcieť riešiť mieru zavinenia nie jeho vlasnou vinou.
"To viem, ze obsah nie je to iste. Snazim sa pochopit ako sa naraba so zlymi blokmi a ci by som vedel nieco s tym urobit. To sa mi zda, ze je rovnake aj v EU aj v US"
Ak to vieš, tak odkedy, lebo tvoje otázky bývajú dosť nejasné a niekedy aj odpovede. Ak chceš predísť nedorozumeniam, vyjadruj sa jasnejšie. Tak tebe sa zdá byť spôsob managementu BB v tej pamäti rovnaký v porovnaní s D55XX/D57XX...
Mne tiež ako som písal už v predošlej správe
"pozrel som ten blok, ale tam sa striedaju len 00 a ff, nic ine tam nie je"
To je to čo som mal na mysli, že sú tam samé nule, pretože FF niesú dáta ak sú to súvislé bloky a súvislé bloky núl vlastne tiež niesú dáta.
Takže takýmto spôsobom je označený chybný blok buď z výroby čipu alebo takýmto obsahom môže byť nahratý v prípade, že systém označil tento blok za zlý dodatočne počas používania TV a updatoval info o tom do BBT, prípadne ide o kópiu cudzieho dumpu, ktorý mal na čipe tento block vadný naozaj.
To či ide naozaj o zlý blok v tomto čipe od novoty alebo až dodatočný sa dá zistiť ako som už písal len porovnaním obsahu BBT s tým čo napíše programátor pri mazaní čipu ak túto funkciu podporuje. RT809H ju podporuje, TNM5000 nenapíše čísla blokov, len ich počet a ten tretí Xeltek taiwanský nepoznám.
Takže čo si písal, že tam ešte niečo malo byť, je vlastne nič ako som si myslel už predtým...
Takže to zhrniem podľa toho čo si písal...
Keďže máš zálohu pamäte, ktorá v doske funguje a máš ešte jednu predpokladám rovnakú dosku, ktorú si označil, že má prehriaty cpu, ale nemáš na čom ani jednu z tých dosiek otestovať, tak momentálne nevieš urobiť nič.
Overoval som si, že tvoja doska, ktorú si označil ako BN41-01605 sa používa v plazmových TV PN/PS 51/59 D6500/D6900 a tam je obsah nand identický s UEXXD55XX/D57XX avšak či je tvoj model americká verzia plazmy alebo LCD to ti nepoviem.
Ak by to bol LCD, tak by som tú tvoju dosku na testovanie do plazmy určite nestrkal.
Až budeš mať komplet TV pre túto dosku, potom si najprv otestuj dosky tam a napíš ako sa závada na nefunkčnej prejavuje a podľa toho už by sme mohli vedieť viac či má zmysel nand opravovať alebo nie.