Napsal: 14 lis 2018, 09:12
Tiez dakujem za vysvetlenie a mal by som otazku.
Ako sa da rozpoznat kde sa to BBT a ZVB nachadza?
Je to nejak oznacene?
Ako sa da rozpoznat kde sa to BBT a ZVB nachadza?
Je to nejak oznacene?
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.
