jądro do qemu-arm

Nov 11, 2012 12 Replies

Noszę się z napisaniem bootloadera zgodnie z pomysłem podsunietym na grupie: wykorzystując jądro linuxa do załadowania innego jądra.



Ponieważ mój bootolader chciałbym możliwe napisać samodzielnie od kompletnego 0 to potrzebuje sandbox w którym mogę go testować.



Chciałbym sobie zrobić sandbox używając QEMU i emulując ARM.



Mój hardware nie obsługuje Thumb2 a jedynie Thumb lub normalny ARM.



Teraz pytanie: Jakie jądro (do jakiego urządzenia) powinienem wybrać aby: a) odpalało się pod QEmu b) nie uzywało Thumb2 c) miało support przynajmniej dla urządzeń blokowych i sieci w QEmu.



Przypuszczam że jakieś łatwo dostepny na rynku mały zestaw embedded będzie miał stosowane patche na jądro w celu emulacji. Czy ktoś móglby mi wskazać palcem czym się zainteresować? Ewentualnie: może waniljowe jądro obsługuje jakiś hardware ktory da się zaemulować QEmu?


W dniu 2012-11-11 23:55, Sebastian Biały pisze:

A ty dalej rzezbisz w gownie. Uboot Uboot i jeszcze raz uboot ma wszystko czego potrzebujesz.

Sebastian Biały napisal 2012-11-11 23:55:

Trochę poteoretyzuję, bo nigdy tego nie robiłem. Prawdziwa platforma sprzętowa jakoś wydawała się być wygodniejszą.

Opcja THUMB2_KERNEL jest jako "experimental" i domyślnie wyłączona - zgaduję, że nie powinno być z tym punktem problemu.

Kilka różnych platform tu wymieniają:

formatting link
Wygląda na to, że standardowy kernel powinien obsługiwać takie Versatile PB. Po uruchomieniu na kernelu 3.4.16 "make ARCH=arm menuconfig" w System Type widać, że jest dostępna ta platforma.

to chyba nie problem

Wspomniane wyżej Versatile PB ma dostępny ethernet, grafikę i kontroler SCSI.

Może waniliowe wystarczy.

W dniu 2012-11-11 23:55, Sebastian Biały pisze:

A może to:

formatting link
się nada do Twoich potrzeb ?

Pozdr AK

Problemem wszystkich booloaderow nie opartych o jądro linuxa jest nietypowość mojego hardware. Dostepny w chinach, dokumentacja po chińsku, strony na kóre trzeba się logowac po chińsku żeby poczytać chińskie opisy itd. Jedyne jądro jakie mam z działajacym (a i tak nie do końca) hardware to jakieś wczesne 2.6. U-boot zaś jest, ale nie ma driverów do czegokolwiek poza NAND. Efektem czego wydaje mi się że najłatwiej będzie jednak zmusić jądro do pracy jako bootloader. Własnie kompiluje qemu i zobaczymy ...

A co do dopisania tego kodu do u-boota to jedno spojrzenie na kod uboota aby mieć pewność że jest wystarczająco obleśny aby mi się odechciało.

Bo uboot jest tylko po to zeby uruchomic kernel jakie ty chcesz drivery do czego? Uboot ma zobaczyc tylko cos na czym jest kernel i tu sie jego rola konczy.

Melduje że zadanie wykonane, jądro linuxa laduje inne jądro linuxa w posób całkowicie kontrolowany z poziomu basha (w qemu i na prawdziwym cpu). Jeśli by komus przyszedł do głowy równie głupi pomysł to służę pomocą.

W dniu 2012-11-20 18:32, Sebastian Biały pisze:

A co laduje to pierwsze jadro ?

Pozdr AK

uboot, a jadro 1 we flashu.

W dniu 2012-11-20 18:32, Sebastian Biały pisze:

Nasuwa się fundamentalne pytanie. Po co dwa razy ładować jądro Linuxa? Dlaczego U-boot nie może ładować od razu tego drugiego?

Ponieważ:

a) jądro ladowane jest z dowolnego urzadzenia z nastepujących:

1) dowolne mass storage wsadzone w usb 2) karta sd 3) sieć (przez tftp i konfigurację dhcp) 4) sieć (po smb)

b) jadro pierwsze sprawdza podpis cyfrowy jądra 2. Jeśli się nie zgadza, nie ładuje go.

c) mogę dostarczyć jądro 2 na dowolnym filesystemie, w tym vfat.

d) mogę dostarczyć filesystem w trybie read-only albo dowolnie inaczej zmodyfikowanym (np filesystem jako plik na fat32 albo zaszyty w jądrze, pełna swoboda)

e) nie istnieje uboot mający dowolny z punktów a,b,c,d do mojego hardware.

f) kod uboota to kupa (odpada pomysł z dopisaniem)

OK. Wszystko jasne. To narzędzie odpalane na pierwszym Linuxie pisałeś od zera?

To skrypt basha :) Napisany w 2h z potknięciem o buga w kexec.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required