i.MX6 buildroot: Fatal: Kernel too old po dodaniu gcc, glibc

Witam,

Robię sobie próby z budowanie linuxa za pomocą buildroot'a.

Pierwszy test to wybranie predefiniowanej konfiguracji : freescale_imx6dlsabresd_defconfig

Po zbudowaniu systemu i przerzuceniu go na kartę SD system uruchamia się na docelowym sprzęcie.

Kolejny test to dodanie do wcześniej zbudowanej wersji gcc, glibc i tu problem. Pomimo poprawnego zbudowania systemu nie uruchamia się. Komuniakt to:
Fatal: Kernel too old.

W czym może być problem ?

@stmx Rozumię że mogę to sprawdzić tylko z poziomu "make menuconfig" ?
Bo tak jak mówiłem nie uruchamia się mi na zbudowanym systemie.

W menuconfig:
Custom kernel headers series (4.9.x)
Kernel version (Custom Git Repository ) ---> https://source.codeaurora.org/external/imx/linux-imx.git URL of (rel_imx_4.9.x_1.0.0_ga)

Dodano po 1 [minuty]:

@stmx Chodzi ci o to jaka mam wersję glibc na hoscie z którego uruchamiam buildroot'a?

Dodano po 2 [minuty]:

Damian7546 napisał:

Kolejny test to dodanie do wcześniej zbudowanej wersji gcc, glibc i tu problem. Pomimo poprawnego zbudowania systemu nie uruchamia się. Komuniakt to:
Fatal: Kernel too old.

Ale nie dodaję gcc i glibc na działającym systemie tylko z poziomu make menuconfig i przebudowuję system na hoscie. Następnie wrzucam go od nowa na kartę SD i uruchamiam - z tym że nie uruchamia się bo wyrzuca błąd jak pisałem

Dodano po 4 [minuty]:

Poniżej log z próby uruchomienia systemu na docelowym komputerze - gdy system zbudowany z toolchainem, glibc...



I poniżej log z uruchomienia systemu bez toolchaina, libc ..



Dodano po 13 [godziny] 11 [minuty]:

@stmx Opisze może problem od początku. Próbuję ogarnąć rozruch, budowanie linuxa wbudowanego w celach edukacyjnych

Na urządzeniu które próbuję uruchomić z własnym zbudowanym linuxem jest możliwość uruchomienia linuxa z wewnętrznej pamięci wykrywanej jako mmcblk3p1.

Ja próbuję uruchomić system z karty SD. A więc przy starcie komputera wszedłem w bootloadera i ustawiłem zmienną środowiskową jak poniżej:

setenv rootfsinfo 'root=/dev/mmcblk2p2 rootwait rw'
saveenv

I dzięki temu startuje mój zbudowany linux.
Problem pojawia się gdy na moim hoscie (Ubuntu) gdzie buduję linuxa za pomocą builtroota dodaje w 'make menuconfig' toolchaina z glibc wtedy to nie uruchamia mi się zbudowany system na docelowym komputerze.

Rozumię ze ww. zmienna środowiskowa uruchamia mi jądro i rootfs'a z SD ?
Chyba nie ma sytuacji że jądro odpala się z wewnętrznej pamięci a tylko rootfs z SD?

Ta zmienna środowiskowa wybiera Ci tylko rootfs z karty, jadro w dalszym ciągu uruchamia się z wewnętrznej pamięci - tak wynika z logu. I ewidentnie wybudowany rootfs (init) jest z tym starym jądrem niekompatybilny.
Musisz jeszcze zmienić konfiguracje U-boota aby jądro też zaciągał z karty (o ile tam je masz).
Niestety, nie jestem (jeszcze) ekspertem od konfiguracji U-boota.

@szelus no właśnie tu najprawdopodobniej jest problem... trzeba doczytać

Dodano po 9 [minuty]:

Chyba buildroot buduje od razu jądro:
Gdy wypalam obraz na SD to mam partycję
FAT z plikami:
zImage i imx6dlsabresd.dtb
i Ext2 z rootfs'em ...
Rozumię że w FAT jest jądro ?

Tak, zImage to jądro. Jeżeli możesz, to wywołaj komendę printenv U-Boota i wklej tutaj wynik. Spróbujemy coś wymyślić

Poniżej zmienne z uboot'a :


Dodano po 5 [minuty]:

Zapewne któryś z poniższych parametrów trzeba by podmienić :
Ale te adresy będą takie same ?

Spróbowałbym:

szelus napisał:

Spróbowałbym:

Kod: Bash

Zaloguj się, aby zobaczyć kod

Niestety, po zmianie mmcdev na 2 :



Dodano po 36 [minuty]:

Fragment z "Linux podstawy i aplikacje dla systemów embedded"


Dodano po 1 [minuty]:

Nie rozumie gdzie wskazywana jest partycja z jądrem.

Dodano po 7 [minuty]:

Obstawiałbym tą zmienną
mmcroot=/dev/mmcblk2p2 rootwait rw

ale jej zmiany nie da się zapisać ...

Dodano po 20 [minuty]:

Zmieniłem zmienna mmcdev jak niżej:

setenv mmcdev 0

efektem było to że zatrzymało się na odczycie pliku zImage z informacją że nie może odnaleźć imx6dl-sc200-ldo.dtb . Zmieniłem więc nazwę na karcie SD pliku z rozszerzeniem .dtb na szukaną przez uboota i coś ruszyło ....

Nie uruchamia się fsroot tylko ciągle sypie komunikatem :

max11801_ts 1-0048: FIFO_RD_AUX_MSB read failed (-6)
max11801_ts 1-0048: FIFO_RD_AUX_MSB read failed (-6)

Dodano po 26 [minuty]:

Teraz napewno startuje jądro z buildroot'a:


Tylko jakieś komplikacje ze startem

Z logu wynika, że Twój nowy Linux nie widzi karty SD.
Porównałem oba logi starującego Linuxa, które zamieściłeś i niestety są z innej bajki.
Oryginalny kernel jest 3.14.28 a Twój 4.9.11. Tak się nie da pracować.
Musisz zacząć od ściągnięcia, wybudowania i przetestowania jakiejś działającej konfiguracji buildroot'a, zanim zaczniesz ją modyfikować.
Nie napisałeś jaką masz płytkę i skąd wziąłeś inicjalną konfigurację buildroot'a.

@szelus I właśnie tutaj nie wiem jak podejść do sprawy.

Komputer na którym robię próby to:
https://etwoc.com/sc200-smart-connect-module/

Pisze że jego macierzystą płytką jest i.mx6dlsabresd .

Dlatego budując nowy fsroot i kernel wybrałem predefinicję z buildroota : freescale_imx6dlsabresd_defconfig .

Komputer dostałem z gotowym systemem i jądrem zbudowanym przez YOCTO Porject znajdującym się w wewnętrznym flashu.
Ja dla nauki chciałbym uruchomić ten komputer z jądra i fsroota zbudowanego przez buildroota używając karty SD.
Rozumię że predefinicja freescale_imx6dlsabresd_defconfig z buildroot'a nijak nie ma się do mojego komputera ?
W takim razie jak podejść do tematu ?

Nie wygląda to za ciekawie.
Masz płytkę, dla której publicznie nie jest dostępna praktycznie żadna dokumentacja (chyba, że coś przeoczyłem). Masz coś więcej, niż jest na tej stronie?
Płytka, nawet jeżeli bazuje na i.mx6dlsabresd (skąd pochodzi ta informacja?), to ewidentnie jest zmodyfikowana, ale nie wiadomo jakie dokładnie są te modyfikacje, a ma to wpływ na konfigurację driverów.
Konfiguracja buildroot'a nie jest do końca poprawna, jądro zgłasza trochę błędów na starcie i przede wszystkim nie widzi karty SD (chociaż widzi kontroler) - dlatego start utyka na dostępie do rootfs.
Masz chociaż źródła oryginalnego jądra (tego Yocto)?

Nie ma za wiele. Mam gotowe pliki bootloadera, kernela i fsroota oraz dokument w który opisany jest reflashing narzędziem mfg tool oraz opis płytki - przesyłam w załączniku.

Nie ma zbyt wielu opcji.

1. Można zażądać od firmy, która dostarczyła binarki, odpowiadających im źródeł kernela - zgodnie z GPL są zobowiązani dostarczyć. Ale czy się przejmą...
Na podstawie tych źródeł można by skonfigurować buildroot'a.

2. Jeżeli nie 1, to pozostaje hackerstwo - trzeba wyciągnąć oryginalny plik dtd, zdekompilować i na tej podstawie spróbować skonfigurować kernel, a następnie buildroot'a. Wydaje mi się to możliwe, ale byłoby z tym dużo zabawy.

szelus napisał:

1. Można zażądać od firmy, która dostarczyła binarki, odpowiadających im źródeł kernela - zgodnie z GPL są zobowiązani dostarczyć. Ale czy się przejmą...
Na podstawie tych źródeł można by skonfigurować buildroot'a.

Spróbuję.

Dodano po 14 [godziny] 3 [minuty]:

@szelus Nawet gdy dostanę źródło kerenla i w buildroot wskażę na kernela z lokalnej lokalizacji to w efekcie nie będzie to samo jak robiłem na początku postu, tj. Kernel uruchamiałem z wewnętrznej pamięci - a więc oryginalny natomiast rootfs'a z buidroot'a ?

Głownie chodzi o konfiguracje kernela, w szczególności device tree.
Jeżeli kernel nie wstaje poprawnie (a ten wybudowany przez Ciebie ma problemy przynajmniej z kontrolą zasilania oraz z wykryciem karty SD), to system nie będzie stabilny i dalsza zabawa ma raczej umiarkowany sens.
Jak już potrafisz wybudować poprawnie działający kernel, to można bawić się z konfiguracją oprogramowania w przestrzeni użytkownika - to jest mniej krytyczne.
Wtedy można też myśleć o upgradzie jądra do nowszej wersji.

@szelus Podesłali:

https://github.com/etwoc/linux-fslc-e2c

Jak teraz 'wkomponować' to w buildroot'a?

Trochę mnie nie było tutaj z powodu Świąt. Ściągnę to sobie i popatrzę.
W zasadzie zacząłbym od skompilowania tego kernela "z ręki" i podmiany w image-u, ale możesz też spróbować dodać go tak, jak poprzednio (jako custom) i zobaczyć co się pojawi w konfiguracji i czy da się wybudować...

@szelus No właśnie zastanawiam się jak dodać kernel do buildroota.
W Kernel-> Kernel wersion (Custom Git repository) usuwam ściezke z gita i w
Kernel-> Custom reposiotry version też usuwam.
Dodaję w Custom Kernel patches scieżkę do /home/damian/Desktop/linux-fslc-e2c-e2c/kernel

ale tak nie działa ... Chyba że to nie tak ?

A nie działa tak, jak poprzednio? Ze wskazaniem tego URL, co dostałeś, jako custom repository?

Tz Kernel version i custom repository version zostawić bez zmian natomiast do Custom Kernel Patches dodać ścieżkę /home/damian/Desktop/linux-fslc-e2c-e2c/kernel ??
To nie rozumie jak to ma zadziałać ? Jakie jądro mi zbuduje ?

Dodano po 52 [minuty]:

Gdy pozostawiam w freescale_imx6dlsabresd_defconfig wszystko bez zmian i dodaję tylko w "Kernel->Custom Kernel patches" scieżkę /home/damian/Desktop/linux-fslc-e2c-e2c/kernel

to kompilacja kończy się błędem:

Nie. Wyłącznie

Kernel version (Custom Git Repository ) ---> https://github.com/etwoc/linux-fslc-e2c.git

Custom kernel headers/patches puste/wyłączone.
defconfig powinien być wzięty ten z linux-fslc-ec2.

szelus napisał:

defconfig powinien być wzięty ten z linux-fslc-ec2.

Jak to zrobić w buildroot ?
Skopiowanie defconfig od e2c do katalgou buildroot/configs nadanie mu nazwy e2c_defconfig i uruchomienie go make e2c_defconfig ? --> tak nie zadziała ...

Nie zrozumieliśmy się.
Główny defconfig buildroot'a pozostaje bez zmian (freescale_...).
Kopiujesz sobie lokalnie plik defconfig z linux-fslc-ec2. Uruchamiasz menuconfig i ustawiasz:

I tyle. Sprawdziłem - buduje się.

(HEAD) Custom repository version , co oznacza wpis HEAD ?

Odwołuje się do najnowszej wersji dostępnej w repozytorium git.
Nie jest to najlepsze rozwiązanie, ale ponieważ repozytorium nie jest otagowane, to aby odwołać się do konkretnej wersji, możesz ewentualnie użyć szesnastkowego identyfikatora commit'a.

Ok, zbudował mi sie system zgodniez twoimi zaleceniami.
Po przebudowaniu dodałem w make menuconfig :
Toolchain: [*]Enable WCHAR support, oraz [*]Enable C++ support.
Kolejny raz uruchomiłem make i przeszło bez błędów.

Następnie dodałem : Target packages -> Interpreter languages and script -> [*]nodejs
I tym razem make nie przeszedł.


Błąd jak niżej: