Archive for category QQ2440

Detekcja bad blocków za pomocą U-Boot

Najpierw proponuję sprawdzić tablicę partycji czy testujemy porządny obszar.

qq2440 # mtdparts
device nand0 <nandflash0>, # parts = 3
 #: name			size		offset		mask_flags
 0: kernel              0x00200000	0x00000000	0
 1: jffs2               0x00800000	0x00200000	0
 2: yaffs               0x03600000	0x00a00000	0
active partition: nand0,0 - (kernel) 0x00200000 @ 0x00000000
defaults:
mtdids  : nand0=qq2440-nand
mtdparts: <NULL>

Oto prosty snippet do wykrywania bad blocków w pamięci NAND flash za pomocą U-Boota.

mw 0x32000000 55aa55aa 20000
nand write 0x32000000 0x00a00000 0x80000
nand read 0x32080000 0x00a00000 0x80000
cmp.l 0x32000000 0x32080000 0x20000

Objaśnienia po kolei:

  1. do ramu (0×3200000) wpisujemy jakieś bajty testowe (0x550xaa0x550xaa) i to razy 0×20000. Rozmiar jaki chcemy przetestować podzielony przez 4
  2. potem zapisujemy to do flasha (0xa00000) na testowany obszar
  3. odczytujemy do innego obszaru pamięci
  4. testujemy

Wyniki mogą być takie (adresy w przykładzie są z innego testu):

word at 0x32180000 (0x55aa55aa) != word at 0x32200000 (0x00000000)
Total of 393216 words were the same

Jeżeli znajdziemy jakiegoś babola wypada go odznaczyć, offset w pamięci flash trzeba obliczyć ręcznie, ale to chyba nie problem:

nand markbad 0xa00000

, , , ,

2 Comments

Linux na QQ2440: mini HOWTO

Od dłuższego czasu walczę z moją pracą magisterską, w skrócie temat dotyka Linuksa na urządzeniu wbudowanym. Specjalnie na tą okazję zaopatrzyłem się w zestaw developerski QQ2440 (made in China sic!)  oparty na procesorze Samsung s3c2440. Tak oto prezentuje się w pełnej krasie:

23082009088.jpg

Wczoraj wieczorem udało mi się uruchomić na nim moją własną wersję skompilowanego jądra.  Oczywiście nie customizowałem wszystkiego samemu, skorzystałem z patchy oraz wskazówek LeshaK’a. Wszystkich zainteresowanych odsyłam do jego bloga, gdyż to on jest autorem tego rozwiązania, w tym artykule postaram się tylko opisać czym różniło się moje podejście i ewentualnie doprecyzować niektóre moim zdaniem niejasne kwestie.

W tym artykule postaram się opisać:

  • przygotowanie środowiska kompilacji (toolchain)
  • skompilowanie kernela i przygotowanie obrazu jądra

W przeciwieństwie do niego jednak zamiast toolchaina crosstool-NG użyłem system OpenEmbedded. Nie zagłębiając się zanadto w szczegóły tej decyzji w skrócie opowiem, że z narzędziem crosstool-NG i kompilacją jajka walczyłem kilka miesięcy, a za pomocą OE udało mi się skompilować i uruchomić środowisko w jeden wieczór (może to tylko kwestia szczęścia).

Cross compile toolchain:

W skrócie to kompilatory, bin utilts’y, uc/glibc itp. słowem wszystko co potrzebne do procesu kompilacji czegokolwiek. Jako, że (przynajmniej tak zakładam) pracujemy na PC z rodziny x86,  mamy (lub nie) domyślnie kompilatory na tąże platformę (i tylko tą). Więc aby na x86 skompilować coś na ARM trzeba mieć osobny zestaw narzędzi czyli fachowo cross-compile toolchain na rodzinę ARM.  Polecam w wolnym czasie przeglądnąć artykuł na Wikipedii.

No to nurkujemy, na początek instalacja OE tu wam nie pomogę, ale wszystko jet na oficjalnym wiki, aha nic nie budujemy, tylko instalacja! Jeżeli czytasz dalej to znaczy, że już masz OE na swoim hoście pora na konfigurację. Nasza platforma to QQ2440 i nie jest ona obsługiwana przez OE :( , ale jest osadzona na procesorze z rodziny s3c24xx, tak tej samej na której działa OpenMoko, więc w pliku local.conf ustawiamy:

MACHINE = "om-gta02"
TARGET_OS = "linux-uclibc"
DISTRO = "minimal-uclibc"
IMAGE_FSTYPES = "jffs2"

Teraz OE już jest gotowe do zbudowania naszego toolchaina:

bitbake task-sdk-host

To polecenie pobierze i skompiluje automagicznie około 500 pakietów. Po udanym wykonaniu powyższego polecenia możemy udać się do katalogu:

{OE}/build/conf/tmp/cross/armv4t/bin

i cieszyć się naszym wspaniałym świeżutkim toolchainem.

Kernel:

Niestety nie możemy wykorzystać dobrodziejstw systemu Open Embedded w celu przygotowania obrazu jądra gdyż nasza platforma nie jest wspierana pod tym kątem. Ten krok nie odbiega bardzo od podejścia Leshak’a, podam tylko skrócone tłumaczenie dla leniwych:

  • instalujemy program mkimage,
    sudo apt-get install mkimage
  • instalujemy dowolny serwer tftp (przyda się do przesyłania po sieci binariów na sprzęt), np.
    sudo apt-get install atftpd
  • pobieramy jądro Linuksa 2.6.29, standardowo z kernel.org
  • patch ze strony Leshaka

Następnie patchujemy pobrane źrodła kernela i jesteśmy prawie gotowi do kompilacji. Domyślnie Makefile Leshak’a po skompilowaniu jądra tworzy obraz za pomocą programu mkimage i umieszcza go katalogu głównym serwera tftp (domyślna ścieżka dla obrazu u Leshak’a: /opt/share/tftp/uImage), dodatkowa instrukcja znajduje się w pliku linux-2.6.29/arch/arm/boot/Makefile.
Wystarczy zmienić tą ścieżkę na nasz katalog główny serwera tftp i możemy bawić się dalej.

Teraz zgodnie z zaleceniami kompilujemy:

 cd linux-2.6.29
 export PATH=$PATH:/Wpisz/tu/sciezke/do/build/conf/tmp/cross/armv4t/bin
 make qq2440_defconfig
 CROSS_COMPILE=arm-oe-linux-uclibcgnueabi- make -j5

Po tym kroku otrzymujemy wspaniałe świeże jajko i co najważniejsze działające!
Pozostaje tylko kilka kroków zanim przekonamy się, że faktycznie nasz Linux działa.

Boot loader i instalacja:

Odsyłam do artykułu o przygotowaniu U-Boota (link), są tam zarówno źródła jak i instrukcje jak postępować. Należy tylko pamiętać aby skompilować U-Boot za pomocą naszego toolchaina, postępując analogicznie jak z kernelem.

Dalej w celu instalacji znowu odsyłam do strony Leshak’a w celu zasięgnięcia instrukcji odnośnie osadzenia przygotowanych binarek na urządzeniu (link).  Tutaj znowu mam drobną uwagę, w związku ze zmianą rozmiaru obrazów należy przeliczyć sobie rozmiar swojego jądra, systemu plików, bootloadera i odpowiednio zmodyfikować polecenia dla bootloadera (super vivi oraz U-Boot ). Dla mnie wyglądało to mniej więcej tak:

qq2440> tftp 0x32000000 uImage
qq2440> nand erase 0x100000 0x200000
qq2440> nand write 0x32000000 0x100000 0x200000
qq2440> setenv bootcmd 'nand read 0x32000000 0x100000 0x1a78c4; bootm 0x32000000'
qq2440> saveenv
qq2440> reset

W skrócie opisze co się dzieje:

  1. pobierz z serwera tftp plik uImage pod adres 0×32000000 w RAM
  2. wyczyść 2097152 bajtów pamięci NAND od adresu 0×100000
  3. wczytaj z RAM (spod adresu 0×32000000) i zapisz do NAND (pod adres 0×100000) 2097152 bajtów
  4. ustaw parametry “bootowania” dla U-Boot’a, a w nich:
    1. wczytaj z NAND (spod adresu 0×100000) i zapisz do RAM (0×32000000)  1734852 bajtów
    2. wykonaj skok do (czytaj uruchom program spod adresu) 0×32000000 (RAM)

Wybaczcie za tak łopatologiczne tłumaczenie, ale nie potrafię inaczej tego wytłumaczyć.  Jako, że dane przelatują kilka razy tam i z powrotem trzeba odpowiednio zmodyfikować parametry tak by odpowiadały rzeczywistej wielkości danych, należy uważać też, aby nie napisać “przypadkiem” kawałka jądra, systemu plików czy boot loadera. Polecam do tego celu kartkę i długopis.

Może też zdarzyć sytuacja, że występują bad sektory w pamięci NAND flash, najlepiej wówczas odpowiednio przesunąć obraz w którym one występują. Przy przenoszeniu jądra należy pamiętać aby odpowiednio zmodyfikować parametry programu mkimage.

System plików i dystrybucja:

Aktualnie pracuje nad tą częścią artykułu, tymczasem kolejny raz odsyłam do bloga Leshak‘a, do załączonej płyty z oprogramowaniem (tam też są gotowe obrazy systemu plików) oraz jako ciekawostkę polecam narzędzie online do tworzenia obrazu dystrybucji Angstrom.

Your Name:

Your Email Address:

Your Message:


, , , ,

No Comments