Jump to content

NAND - bad sectory


Guest tuspam

Recommended Posts

Guest tuspam

Jak sprawdzic czy czasami nie mamy bad sectorow w nand? Oczywiste jest ze jesli w nandzie bedzie sporo bad sectorow to moga one powodowac niestabila prace tunera wiec dobrze spradzic i ewentualnie "zamknac" uszkodzone sektory, dlatego dobrze to wykluczyc zanim wezmiemy sie za wymiany podzespolow. Da sie to zrobic z poziomu e2? Prosze o instrukcje.

 

Pzdr

 

Link to comment
Share on other sites

Metoda jaką podają na forach użytkownicy FreeBSD w temacie sprawdzania dysków, nie jestem pewny czy da się ją bezpośrednio przenieść na flasha. Wykonać można, tylko czy wynik można interpretować podobnie jak w przypadku dysków, to nie jestem pewny :(

dd if=/dev/mtd0 of=/dev/null
dd if=/dev/mtd1 of=/dev/null

Jeżeli przy odczycie nie było błędów, to znaczy, że jest ok. Komendy czyta całego flasha, czyli wszystkie sektory a nie tylko pliki. Jeżeli zamiast /dev/null dałbyś plik na dysku, np. /hdd/plik1, odczytał kilka razy odstając za każdym razem to samo to znaczyłoby, że odczyt flasha działa bez problemów.

Nie podaję przykładowych komend bo to już mały hardcore, ale można jeszcze zrobić tak, że of= jest takie same jak if=... Dokładniej: najpierw zapisujemy mtd0 i mtd1 do plików. Potem za pomocą dd czytamy i od razu zapisujemy z powrotem if->of. I ponownie odczyt do pliku na dysku. Jeżeli będzie to taki sam plik, to należy wnioskować, że flash odczytał się i zapisał poprawnie, czyli nie ma bad bloków.
Link to comment
Share on other sites

Ja sprawdziłem u siebie w następujący sposób:

 

Odpaliłem E2 z pena

z konsoli

 

1. Sprawdzam gdzie mamy rootfs

cat /proc/mtd

 

2. Kopia NAND-

dd if=/dev/mtd0 of=/hdd/rootfs.img

lub

cat /dev/mtd0 >/hdd/rootfs.img

 

3. Kasowanie NAND

flash_eraseall /dev/mtd0

 

po wykonaniu kasowania jest informacja czy operacja przebiegła prawidłowo.

u mnie :

 

\"tuxish-nBox:~# flash_eraseall  /dev/mtd0

Erasing 16 Kibyte @ 3cec000 -- 99 % complete.

Skipping bad block at 0x03cf0000

 

Skipping bad block at 0x03cf4000

 

Skipping bad block at 0x03cf8000

 

Skipping bad block at 0x03cfc000

Erasing 16 Kibyte @ 3d00000 -- 100 % complete.\"

 

no i ponownie zapisanie kopii do NAND

4. dd if=/hdd/backup/rootfs.img of=/dev/mtd0

lub

cat /hdd/rootfs.img > /dev/mtd0

 

kernela nie ruszałem

 

 

 

Link to comment
Share on other sites

Guest tuspam

Wyniki za kazdym razem mam takie same (testowane z 10razy)

 

tuxish-nBox:~# dd if=/dev/mtd1 of=/dev/null

8192+0 records in

8192+0 records out

4194304 bytes (4.0MB) copied, 1.751176 seconds, 2.3MB/s

tuxish-nBox:~# dd if=/dev/mtd0 of=/dev/null

122880+0 records in

122880+0 records out

62914560 bytes (60.0MB) copied, 25.989458 seconds, 2.3MB/s

 

Oznacza to ze nand jest pozbawione badow?

 

@matzg

Czy to oznacza ze masz 3 bad sectory? Nie markujesz ich zeby przy ponownym wgrywaniu nie zapisywal w tych miejscach? Mozesz sprawdzic czy po sprawdzeniu metoda @mickey-a wykaze jakiekolwiek roznice w zapisie - odczycie?

 

Ps. Jest tam jeszcze jedna przydatna rzecz predkosc kopiowania 2.3MB/s - ciekawe jak bedzie na sofcie w penie lub karcie sd.

 

 

Link to comment
Share on other sites

Mam 4 Skipping bad block , są na końcu nic sie nie dzieje nie przeszkadzaja mi na razie...

I nie wiem jak zabrać sie za markowanie, pewnie musiałbym to robić zaraz po zatrzymaniu u-boota... chyba na dzień dzisiejszy nie mam pojęcia.

Może ktos coś podpowie..?

;)

zrobiłem

tuxish-nBox:~# dd if=/dev/mtd0 of=/dev/null

ale nie za bardzo wiem o co w tym chodzi wyszło mi na końcu  (61.0MB) że ja mam (3.0MB)-kernel

Mam porównać records in i records out czy zawsze są takie same?

 

 

Link to comment
Share on other sites

Guest tuspam

No tak wywnioskowalem ze ilosc in i out zawsze powinna sie zgadzac. Moze niech sie mickey wypowie lub sprawdzi watek skad pochodzi ta metoda. U ciebie niby sa bady wiec powinny sie roznic te wielkosci.

 

Link to comment
Share on other sites

Zaraz sprawdzę i wszystko będzie wiadomo...

\"

tuxish-nBox:~# dd if=/dev/mtd0 of=/dev/null

6144+0 records in

6144+0 records out

3145728 bytes (3.0MB) copied, 1.324392 seconds, 2.3MB/s

tuxish-nBox:~# dd if=/dev/mtd1 of=/dev/null

124928+0 records in

124928+0 records out

63963136 bytes (61.0MB) copied, 26.714875 seconds, 2.3MB/s

tuxish-nBox:~# flash_eraseall  /dev/mtd1

Erasing 16 Kibyte @ 3cec000 -- 99 % complete.

Skipping bad block at 0x03cf0000

 

Skipping bad block at 0x03cf4000

 

Skipping bad block at 0x03cf8000

 

Skipping bad block at 0x03cfc000

Erasing 16 Kibyte @ 3d00000 -- 100 % complete.\"

 

in i out zawsze taki sam

 

 

Link to comment
Share on other sites

Jakby nie czytać i nie analizować → odpowiedź jest prosta.

Jeżeli będzie nie zamarkowany BAD w NAND to tego sektora nie odczytasz → efekt → inna suma kontrolna tego co wgrałeś i sczytałeś z NAND.

 

Procedura prosta ale nie podaję jej ze względu na bezpieczeństwo. Za dużo osób czyta i wykonuje ślepo polecenia nie wiedząc do końca co mogą zrobić.

 

Link to comment
Share on other sites

Guest tuspam

@tux to moze dodac gdzies w opcjach z pilota sprawdzanie nanda. Wykonaja sie komendy z postow wyzej a wynik wyswietli np nand ok lub cos w te buty, pewnie 5 min roboty dla ciebie a moze komus pomoze kto ma problemy z tunerem.

 

Link to comment
Share on other sites

Guest tuspam

@matzg

 

No i przyszedl czas na przetestowanie i zonk, po komendzie:

 

flash_eraseall /dev/mtd0

 

dostaje odp.

 

flash_eraseall: applet not found

 

System uruchomiony z pena (najnowszy obraz by tux)

 

 

Link to comment
Share on other sites

Guest tuspam

Musialem uruchomic tuner z nand bo jak byl z pena to nie chcialo. Rozpakowalem tar xzvf pliki.tar.gz -C / zrobilem restart i stoi na usb1, ale to raczej nie wina tego ze zostaly dograne poprostu chyba nie lubi pena lub ogolnie ma problem z uruchamianiem systemu spod usb. Nie wiem czy to problem z mlultibootem czy cos innego bo zdarza sie ze tuner zaczyna sie uruchamiac z usb dopiero po kilku minutach. Powalcze jeszcze z karta sd.

 

Link to comment
Share on other sites

Guest tuspam

Po testach:

 

cat /proc/mtd  wyszlo ze rootfs w mtd1

 

dd if=/dev/mtd1 of=/hdd/rootfs.img 100% ok

 

flash_eraseall  /dev/mtd1 poszlo 100% ok bez badow

 

dd if=/hdd/backup/rootfs.img of=/dev/mtd1 100% ok

 

Restart tunera i stoi na nLam

 

 

Link to comment
Share on other sites

Guest tuspam

Pisalem z pamieci moglem pomylic ale na pewno zrobilem poprawnie - zgadzaly sie wielkosci img.

 

Najwazniejsze ze sprawdzone ze nie mam badow w nandzie. Kopie udalo sie przywrocic wg wskazowek z 2 posta.

 

Wnioski:

1 Zeby sprawdzic nanda trzeba odpalic nboxa np z usb lub hdd - instrukcja w 3 poscie

2 Do zrobienia full backupa wystarczy zrobic kopie rootfs.img i karnel.img z poziomu e2 z nand-a wg instrukcji w 2 poscie (sprawdzone, dokopiowalem tylko plik update i wgralem wszystkie trzy pliki przez update z pena w fat32)

 

Link to comment
Share on other sites

Dzisiaj musiałem do NAND wrzucić system. Jak się okazało sprzęt, w który miałem wrzucić system na zwalony NAND. Wywalał się przy wgrywaniu.

Ciekawostką bło to iż dd nie wywaliło nawet jednego błędu → po analizie to nawet logiczne bo zapisuje sektor w sektor i jak jest w czym zapisać (sektor istnieje) to zapis będzie wykonany → niezależnie od tego czy błędnie czy nie.

Idąc dalej w testy...

Z terminala ze złącza DEBUG można wrzucać pliki do NAND. I teraz właściwie cała sprawa sprowadza się do próby wrzucenia pliku do NAND i markowania tego sektora, na którym się wyłoży.

 

Oczywiście tuner spisany na straty odpalił bez ALE

 

Link to comment
Share on other sites

Jak pisałem wcześniej, to metoda z dd dotyczy dysków i jak widać z treści całego wątku nie da się przenieść bezpośrednio na flasha. Flasha należałoby testować raczej jak pamięć niż jak dysk, czyli przez zapis/odczyt pewnych sekwencji i porównywanie.

Co do markowania badów. Jeżeli jakieś są, to po zamarkowaniu zawsze istnieje groźba, że wyskoczą następne. A update przez usb chyba już na takim flashu odpada?
Link to comment
Share on other sites

U mnie po zamarkowaniu zapamiętało 3 bady i działa. Czy będą nowe? Nie wiem... zawsze mogą.

Jednak często bady są na nowo przerabianych boxach. Podejrzewam, że w czasie produkcji trafiają się już jakieś i są markowane. Z takimi to to działa w N a jak wywalisz ich soft to zabawa od nowa.

 

Link to comment
Share on other sites

  • 5 years later...

tux[/member]

Możesz proszę chociaż dodać linka gdzie można poczytać o markowaniu bad block'ow.

"

Jakby nie czytać i nie analizować → odpowiedź jest prosta.

Jeżeli będzie nie zamarkowany BAD w NAND to tego sektora nie odczytasz → efekt → inna suma kontrolna tego co wgrałeś i sczytałeś z NAND.

 

Procedura prosta ale nie podaję jej ze względu na bezpieczeństwo. Za dużo osób czyta i wykonuje ślepo polecenia nie wiedząc do końca co mogą zrobić.

"

 

Jak mam po formacie:

GraterliaOS:~# flash_eraseall /dev/mtd0
Erasing 16 Kibyte @ 380c000 - 93% complete.
Skipping bad block at 0x03810000
Erasing 16 Kibyte @ 3c00000 - 100% complete.

 

to sa pomarkowane ? i poki nie użyje dd to nie powinno byc zapisów do bad block ?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...