Kompilacja

Kiedy pada słowo "kompilacja", natychmiast odzywają się ludzie, którzy boją się tematu jak diabeł wody święconej, tak jakby to była jakaś magia i wiedza tajemna, dostępna tylko ludziom o nadprzyrodzonym zdolnościom ...
Zaczynając od początku, to procesor wykonuje kod maszynowy, będący ciągiem zer i jedynek, niezrozumiały dla człowieka. Dlatego wymyślono języki programowania, które zasadniczo mają dwie cechy - są zrozumiałe dla człowieka i są łatwe do przetłumaczenia na kod maszynowy. Do tłumaczenia służą także programy, które się dzielą na interpretery i kompilatory. Różnica jest taka, że interpreter tłumaczy kod źródłowy na maszynowy tuż przed jego wykonaniem, natomiast kompilator zapisuje wykonywalny kod maszynowy do pliku, który można potem wielokrotnie uruchamiać.
Zasadniczo kompilacja programu sprowadza się do wydania w terminalu polecenia składającego się z nazwy kompilatora i ciągu parametrów.
W szczególności NIE POTRZEBNA JEST ZNAJOMOŚĆ ŻADNEGO JĘZYKA PROGRAMOWANIA, choć znajomość podstaw jest wskazana.
Jakby tego było mało, to przy bardziej skomplikowanych projektach, programiści piszą też skrypty automatyzujące kompilację. Często też do kodu źródłowego dołączany jest plik tekstowy z dokładnym opisem co i w jakiej kolejności należy zrobić.
Dlatego warto się przełamać i spróbować, bo wcale nie jesteś skazany na archaicznego Debiana Wheezy, archaiczny kernel 3.6 i archaiczny linuxcnc2.7.
Ja po prostu nie wierzę, żeby ktoś kto umiał własnoręcznie zbudować obrabiarkę CNC i umiał napisać dla niej g-kod, nie potrafił własnoręcznie skompilować kernela czy linuxcnc.
Polecam przejrzeć stronę https://gnipsel.com/linuxcnc/uspace/index.html . Niektóre informacje są tam nieaktualne, ale ogólnie jest to dobry dowód na to, że nie święci garnki lepią ...

c.d.n.

@tuxcnc

To nie jest żaden problem wklepać kilka linijek do terminala i poczekać aż się zrobi. Na tym etapie zgadzam się 100%. Jest tylko jeden problem. W całej instrukcji jaka jest, znajdzie się literówka, jakieś repozytoria znikną, zmienią nazwę etc. i siedzenie przy tym kilka godzin nawet nic nie da. Sam wyżej napisałeś że nie wszystko już aktualne !!!. Wiesz co to oznacza dla normalnego użytkownika ?. Stracony czas i nic poza tym.

Owszem ktoś, kto się na tym zna być może załapie, być może zmieni poprawi linki etc. Ale szympans jak to określiłeś mniej kumatych sobie z tym nie poradzi. Kiedyś podchodziłem do takich akcji w linuxie. Szybciutko się z tych wszystkich instruktarzy wyleczyłem. Szkoda czasu bo zawsze praktycznie poległem. Udało mi się Xboxa tylko zainstalować w/g takiego poradnika rozpisanego na linijki. Cudem zadziałało wykonało zainstalowało i działa.

Przeważnie jednak te poradniki to nic nie warte śmieci, źle napisane, nie działające, nie aktualne. To się zmienia z dnia na dzień, z godziny na godzinę, a co dopiero jakieś instrukcje po dłuższym czasie kiedy większość to zawieszone w necie nic nie warte bajty.

Nie da się skompilować kernela czasu rzeczywistego bez nałożenia łat na kod źródłowy.
W istocie problem sprowadza się do tego żeby mieć właściwy kod, właściwe łaty i proces uruchomić we właściwym folderze.

W Linuksie są dwa programy : diff i patch.
diff wypisuje róznice pomiędzy folderami i plikami, patch natomiast wykonuje czynność odwrotną, czyli wprowadza zmiany.
Dam przykład którego nie będę opisywał szczegółowo, ale powinien on dać pojęcie o co chodzi.
Otóż Linuxcnc2.9 odmawia uruchomienia przez użytkownika root, jeżeli się najpierw nie poustawia jakichś zmiennych systemowych. Zasadniczo nie wiem dokładnie jak i po co, może komuś do czegoś było to potrzebne, może to tylko objaw debianowej paranoi, mnie to jednak irytuje i mi przeszkadza, dlatego bez wnikania w szczegóły postanowiłem wywalić tą "użyteczność", przy okazji tworząc przykład użycia diff i patch.
Utworzyłem w tym celu dwa foldery o nazwach old i new, po czym wypakowałem do obydwu zawartość pliku linuxcnc-master.zip. Czyli w tej chwili miałem dwa foldery o identycznej zawartości. Wszedłem do folderu new i wyszukałem plik zawierający "run as root", co jest fragmentem tego debilnego komunikatu który mnie wkurza. Ja akurat do takich rzeczy używam mc (midnight commander), co każdemu polecam, ale tutaj opisywać nie będę. Winny okazał się plik src/rtapi/uspace_rtapi_app.cc , w którym znalazłem fragment kodu zaczynający się od instrukcji if a kończący się poleceniem exit(1). Tutaj akurat trzeba mieć podstawową wiedzę z zakresu programowania, ale to też nie jest specjalnie skomplikowane. Oto ten fragment kodu : Działa to w taki sposób, że jeżeli warunek w nawiasach będzie spełniony, to wykonany zostanie kod zawarty pomiędzy klamrami, w tym wypadku jeśli UID użytkownika będzie równy zero (root), to zostanie wyświetlony komunikat po czym program zakończy działanie zgłaszając błąd. W tym wypadku mamy komfortową sytuację, bo wykonanie tego kodu zawsze skończy się przerwaniem programu, więc możemy go zupełnie bezpiecznie usunąć od literki i do drugiego nawiasu klamrowego włącznie, co zrobiłem i co nie może mieć wpływu na resztę programu.
W tej chwili foldery już się różnią, bo w new jeden plik został zmieniony.
Przyszedł czas na diff.
Tutaj taka uwaga, że zarówno diff jak i patch działają ze standardowym wejściem/wyjściem, czyli zasadniczo oczekują poleceń z klawiatury a wynik wysyłają na monitor. Żeby czytać z pliku albo zapisać do pliku, musimy użyć znaków przekierowania, czyli np. diff > plik albo patch < plik. Nic trudnego, ale trzeba pamiętać po co te znaczki.
Tak więc w folderze zawierającym old i new wydałem polecenie : Nie będę tutaj tłumaczył dlaczego akurat -Naur, można sobie sprawdzić w man diff.
Zawartość pliku lcnc2.9-run-as-root.patch jest następująca : Znowu nie trzeba być informatykiem żeby załapać o co chodzi. Najpierw jest informacja jak plik powstał i czego dotyczy. Pomiędzy małpami jest opis miejsca gdzie należy szukać interesującego fragmentu, potem trzy linie poprzedzające fragment, potem linie zaczynające się minusem to te do usunięcia, linie zaczynające się plusem (tu akurat nie ma) to te które trzeba dodać, a na koniec trzy linie następujące bezpośrednio po fragmencie. Gdyby ktoś się uparł, toby taki plik napisał "z palca" i by działało.
Co jest ważne ? Zasadniczo to bardzo ważne jest to, że w naszym pliku ścieżki dostępu zaczynają się od old/ i new/. Oczywiście te nazwy są zupełnie przypadkowe, taki miałem kaprys że je tak nazwałem i jest bardzo mało prawdopodobne, żeby gdzie indziej występowały. Dlatego w poleceniu patch podajemy parametr -p<liczba>, który odcina z podanej ścieżki określoną liczbę członów. Na przykład patch -p3 zamieni new/linuxcnc-master/src/rtapi/uspace_rtapi_app.cc na rtapi/uspace_rtapi_app.cc. Podanie właściwego parametru p jest tutaj największym problemem, bo teoretycznie plik łaty może być dowolnie wszędzie, a polecenie możemy także uruchomić w dowolnym folderze. Czyli w naszym przypadku możemy zrobić na przykład tak : <ścieżka> będzie różna w zależności od tego gdzie są pliki i gdzie jesteśmy my, a -p2 odetnie new/linuxcnc-master/.
patch buntuje się gdy podamy niewłaściwą ścieżkę do pliku łaty, gdy podamy niewłaściwy parametr -p, oraz co ważne, gdy spróbujemy załatać inny plik, na przykład różniący się datą, albo już łatany tą samą, albo inną łatą. Pomijając sytuacje oczywiście błędne, patch jest wyrozumiały i szuka fragmentu do zamiany także w okolicach miejsca w którym powinien być, co pozwala na załatanie plików w innej wersji, lub już łatanych, ale oczywiście bez przesady. Takich rzeczy już opisywać nie będę, żeby nie gmatwać, ale warto wiedzieć że tak jest.
Istotą łat jest to, że program źródłowy może mieć, jak w tyk przypadku, 36,5 MB ale łata ma tylko niecały kilobajt. Po dokonaniu jakiejś zmiany nie trzeba wysyłać czy pobierać całego kodu, wystarczy mały plik łaty, i to jest sens tego rozwiązania.

W następnym odcinku kompilacja LInuxcnc2.9 na Xubuntu18.04.3 z kernelem 4.14.148-rtai-amd64.
Właściwie wszystko mam już przygotowane, tylko musi mi się zachcieć wklepać to w klawiaturę.

Lubisz pracować tylko jako root?
Nie znam Xubuntu ale to dobrze, bo mógłbym przejść twoją ścieżką i po drodze zrobić opisy (tak jak tu: https://gnipsel.com/linuxcnc/uspace/index.html) z punktu widzenia "świeżaka" i z konta użytkownika z pomocą sudo.

pitsa pisze: ↑

03 sty 2020, 08:43

Lubisz pracować tylko jako root?

Od kiedy zainstalowałem pierwszego Linuksa, a było to naprawdę dawno temu, wszędzie i zawsze loguję się jako root, i wszystkie programy uruchamiam z uprawnieniami roota. ABSOLUTNIE NIGDY nie miałem z tego powodu ŻADNEJ AWARII. Hardware padał ze starości, ale raz postawione systemy pracowały latami ...
Nawiasem mówiąc NIGDY nie popełniłem takiego błędu, którego bym uniknął pisząc sudo przed każdym poleceniem.
Tak w ogóle, to ta debianowa paranoja jest kompletnym debilizmem i funkcjonuje na zasadach sekty, w której wszyscy wierzą wiarą tak głęboką, że się nie odważą na żadną herezję.
Sudo jako takie wymyślono po coś zupełnie innego, żeby można było dowolnemu użytkownikowi nadać prawa do uruchamiania NIEKTÓRYCH programów z prawami roota, żeby przysłowiowa małpa nie musiała wzywać administratora do błahych działań.
Natomiast do administracji systemu jest konto root i kto zna hasło roota, temu wolno WSZYSTKO.
Amen.

pitsa pisze: ↑

03 sty 2020, 08:43

z punktu widzenia "świeżaka" i z konta użytkownika z pomocą sudo.

Tym razem, specjalnie dla Was, zrobiłem wszystko jak debianowy prawiczek, czyli bez aktywowania konta root. Po prostu doszedłem do wniosku, że jeżeli ma to być poradnik DLA WSZYSTKICH, no to także dla tych, którzy pracować jako root nie chcą, albo nie potrafią. Ale resztę napiszę dalej.

*************************************************************************************************************

Na początek kilka uwag natury ogólnej.

Po pierwsze, kompilacja to proces czasochłonny, więc warto użyć szybkiej maszyny. Szczególnie w przypadku kernela kompilator ma co mielić. To NAPRAWDĘ jest wielka różnica czy kompilacja będzie trwała dwadzieścia minut czy cztery godziny. Zrozumiesz to, gdy coś pójdzie nie tak i będziesz musiał zaczynać wszystko od początku. Co do zasady, to Linux tym się różni od Windows, że z dysku przełożonego do innego komputera system się uruchomi. Są oczywiście wyjątki, ale to wtedy gdy zainstalujesz własnościowe sterowniki, albo różnice w sprzęcie będą naprawdę ogromne. Dlatego na czas kompilacji warto dysk z docelowego komputera przełożyć do szybszej maszyny.
WAŻNA UWAGA : System operacyjny należy ZAWSZE instalować na docelowym sprzęcie, dopiero później można dysk przełożyć gdzieś indziej.

Po drugie, warto mieć do tej zabawy osobny dysk. Dzisiaj zupełnie nowy dysk HDD 250-320 GB można kupić poniżej 50 zł, a zupełnie nowy dysk SSD 128 GB poniżej 100 zł. Warto te pieniądze wydać, żeby sobie nie śmiecić w komputerze używanym do innych celów, oraz uniknąć katorgi z kopiowaniem megabajtów danych.

Po trzecie, zupełnie czymś innym jest instalacja programu z pakietu deb, a czymś innym jego kompilacja ze źródeł. W pierwszym przypadku musimy spełnić wyłącznie zależności samego programu, w drugim także zależności kompilatora. biorąc pod uwagę że zależności mają swoje zależności, sprawa się kończy na tym, że po zainstalowaniu systemu trzeba jeszcze doinstalować jakieś 500 MB softu, także zupełnie niepotrzebnego, jak choćby pakiety do tworzenia dokumentacji w językach których nie znamy. No ale tego uniknąć się nie da. Pocieszające jest to, że kiedy już skompilujemy program do pakietu deb, to możemy go zainstalować na gołym systemie pozbawionym tych wszystkich dodatków. Z powyższych powodów zalecam używanie polecenia apt-get zamiast apt. Różnica jest taka, że apt-get każdy pobrany pakiet zapisuje w folderze /var/cache/apt który to folder warto sobie backupować. Zasada jest taka, że gdy polecimy aptowi zainstalować jakiś pakiet, to on sprawdza czy takiego pliku nie ma w folderze /var/cache/apt. Jeśli znajdzie, to go bierze stamtąd zamiast ściągać z internetu. WAŻNE jest to, że zawartość tego folderu nie jest nigdzie sprawdzana czy zapisywana, czyli możemy tam robić dowolnie wszystko, usuwać pliki albo je dodawać i mieć tam totalny burdel, jeśli tylko lubimy. W szczególności, jeśli po zainstalowaniu systemu skopiujemy do /var/cache/apt pakiety z innej instalacji, to możemy uniknąć pobierania bez sensu gigabajtów danych. Natomiast jeśli na dysku zrobi się ciasno, to można ten folder bez żadnych obaw wyczyścić.

Teraz do roboty.

Potrzebujemy 20 GB wolnego miejsca na dysku i połączenie z internetem.

Najpierw należy się zdecydować który kernel, potem jaka dystrybucja Linuksa.
Kernele do wyboru mamy dwa - rtai i rt-preempt. Rtai jest lepszy ale trochę zacofany (<=4.14), rt-preempt daje gorsze rezultaty, ale jest dostępny w najnowszych wersjach kernela (>5.0).
Ja się zdecydowałem na 4.14.148-rtai-amd64, ponieważ wypowiedziałem wojnę jitterowi. Nawiasem mówiąc nie jest to oficjalna łata twórców rtai, tylko mocno przekombinowane rozwiązanie autorskie. Przekombinowane, bo wyłączono w nim dosłownie WSZYSTKO co psuło jitter, nawet tak użyteczne rzeczy jak obsługa kart graficznych Intela i Nvidii. Tak więc ten kernel nie na każdym sprzęcie będzie dobrym rozwiązaniem, raczej tylko ma jakichś platformach AMD z jakimś Radeonem, ale i tak warto go mieć choćby i tylko po to, żeby się dowiedzieć co nasza płyta i procesor potrafią ...

Wybór dystrybucji jest już prostszy, ma być w miarę nowa i taka którą znamy i lubimy. Ja pracuję na Xubuntu 18.04, co jest dobrym wyborem, bo to najnowsza dystrybucja LTE, czyli o długim wsparciu, która będzie aktualizowana jeszcze trzy lata, natomiast xfce4 to jest lekki i fajny menedźer okien, trochę przypominający starego Windowsa a trochę maca, każdy powinien się w nim odnaleźć. No i przede wszystkim nie ma tych kretyńskich kafli, które może się nadają do telefonu, ale na pewno nie do komputera.
Co do wyboru konkretnego pliku do instalacji, to na początku myślałem o starszej wersji, bo 18.04 startował z kernelem 4.15 a ja chcę instalować 4.14, więc bardzo blisko. Niestety teoria rozminęła się z praktyką, a zmarnowany dzień skutecznie wybił mi ten pomysł z głowy. Problem sprowadza się do tego, że co prawda pliki instalacyjne pierwszej wersji 18.04 są dostępne i oczywiście można z nich zainstalować system, ale REPOZYTORIA SĄ ZAKTUALIZOWANE do najnowszych wersji pakietów, które jakby tego było mało, potrafią mieć też zmienione nazwy. Krótko mówiąc burdel jest totalny, system zależności totalnie rozpieprzony, wielu pakietów nie da się ani zainstalować ani zaktualizować, programy nie chcą się kompilować, jak się skompilują to nie chcą się instalować, a w najlepszym razie nie będą działać prawidłowo.
DLATEGO JEDYNYM ROZWIĄZANIEM JEST INSTALACJA Z NAJNOWSZEGO PLIKU xubuntu-18.04.3-desktop-amd64.iso , a następnie jego natychmiastowa aktualizacja.

Procedury instalacji systemu opisywać nie będę, ale trzeba zauważyć że instalator ma dwie użyteczne funkcje : "wybór innego rozwiązania" który umożliwia ręczne partycjonowanie dysku, oraz zawartą tam opcję wyboru gdzie zainstalować GRUB. Użyteczność pierwszego jest oczywista, drugie się przydaje gdy już mamy na dysku zainstalowanego GRUBa i innego Linuksa, bo wybierając MBR partycji na której instalujemy system, on sam się nie uruchomi, ale też nie nadpiszemy poprzedniej konfiguracji. To już wyższa szkoła jazdy i nie miejsce na tłumaczenie, ale warto wiedzieć że taka możliwość istnieje.
Można też uruchamiając system z płyty lub USB (opcja "wypróbuj Xubuntu") zainstalować na live gparted (to tylko kilkaset kilobajtów do pobrania) i zmniejszyć/przesunąć istniejace partycje żeby zrobić wolne miejsce.
Jak pisałem potrzebna jest 20 GB partycja. Na mniejszej może się nie zmieścić wszystko czego potrzebujemy. Jeśli chcemy tej instalacji używać też do innych celów, to zalecam co najmniej 40 GB.
Instalator z automatu utworzy partycję swap albo plik swapfile w głównym folderze partycji. Co do zasady, współczesny Linux używa około gigabajta pamięci dla własnych celów, programy różnie, ale można przyjąć założenie, że jeżeli mamy w systemie co najmniej 2 GB RAM i nie będziemy robić rzeczy w rodzaju obróbki grafiki wielkoformatowej, to partycja/plik swap nigdy nie zostanie użyty i można go spokojnie usunąć. Trzeba tylko najpierw usunąć właściwą linię w /etc/fstab , a którą to się każdy domyśli.

W połowie pracy trzeba będzie system zrestartować i uruchomić już na nowym kernelu. Z zasady okno GRUB nie pokazuje się gdy mamy zainstalowany tylko jeden system i tylko jeden kernel. Czasem jednak zdarza się że nie pokazuje się także wtedy, gdy teoretycznie powinno. Można sobie z tym poradzić ale nie będę opisywał jak, rozwiązanie można znaleźć w necie.
Instalować będziemy kernel w starszej wersji niż domyślny, dostarczony w pliku iso, dlatego będzie on najprawdopodobniej ostatni na liście GRUBa. Kiedy pojawi się menu GRUB trzeba wejść w "opcje zaawansowane" i tam wybrać linię z kernelem 4.14.148-rtai-amd64. Nawiasem mówiąc, można wtedy wcisnąć zamiast <enter> <e> i przejść do edycji wiersza poleceń GRUBa. To jest sposób by jednorazowo dodać dodatkowe parametry, jak choćby magiczne isolcpus=<wartość>, co potrafi dawać zaskakujące efekty, ale o tym innym razem.

Jak pisałem na wstępie, postanowiłem wszystko zrobić jak debianowy prawiczek, bez logowania się na konto root, ale też bez debilnego klepania sudo przed każdym poleceniem. Służy do tego polecenie Jest to tryb interaktywny, w którym po podaniu hasła użytkownika .... logujemy się na nieistniejące konto roota, ale tylko W TYM terminalu. Każde kolejne polecenie wydajemy już jako root i wykonujemy z uprawnieniami roota, aż do zamknięcia okna, albo wydania komendy Jak widać, jest to kolejny dowód na totalny debilizm koncepcji sudo w debianie.

W Xubuntu można w terminalu używać myszy, działa zaznaczanie, kopiowanie i wklejanie, co ciekawe nawet pomiędzy oknami roota i oknami użytkownika bez przywilejów.
W poniższym kodzie są dwie bardzo długie linie. Jeśli skopiujemy je do edytora tekstu, a ten będzie miał ustawione zawijanie wierszy, to nie uda się tych linii skopiować w całości, tylko zostaną dodane znaki nowej linii, tam gdzie akurat edytor uzna za stosowne. Wtedy terminal po wklejeniu takiego dziwoląga wywali błąd. Jeśli ktoś chce, to sobie może te linie rozbić na kilka poleceń apt-get.
Pierwsze apt-get zaspokaja zależności kompilatora, drugie zaspokaja zależności linuxcnc2.9 i nie musimy go wykonywać jeśli planujemy instalację pakietów na innym systemie.

Linie zaczynające się od wget pobierają pliki z internetu, jeśli mamy te pliki pobrane wcześniej, to możemy je skopiować a pobieranie pominąć.

Folder ~/src wymyśliłem żeby było mniej pisaniny. Tylda oznacza katalog domowy użytkownika, czyli w tym wypadku będzie to /root/src . Nic nie stoi na przeszkodzie, żeby użyć dowolnie innego folderu.

Jest ważne by kompilując kernel ustawić (w uruchomionym menuconfig) lokalną wersję na -rtai-amd64 bo inaczej będą później problemy.

Wszystko kompiluje się do pakietów deb, z którymi możemy robić to co z pakietami deb robić można, w szczególności zainstalować je zupełnie gdzieś indziej.

O tym jak w tym kernelu włączyłem obsługę grafik Intela i915, GMA i HD będzie innym razem.


Ostatnia uwaga, ale BARDZO WAŻNA.
Zaraz po zainstalowaniu trzeba włączyć repozytoria pakietów z kodem źródłowym. Można to zrobić w trybie graficznym Menu_systemu->ustawienia-> "oprogramowanie i aktualizacje" (Software and upgrades) stawiając ptaszka przy "kod źródłowy" ("source code"), albo edytując plik /etc/apt/sources.list - należy w odpowiednich liniach usunąć wszystkie znaki poprzedzające deb-src, czyli je odkomentować. Jeśli tego nie zrobimy, kompilator wywali dość niejasny komunikat o błędzie i odmówi dalszej współpracy.

Linie zaczynające się od # to komentarze i nie należy ich wpisywać w terminalu, natomiast należy je UWAŻNIE PRZECZYTAĆ I SIĘ DO NICH ZASTOSOWAĆ.
Sprawdzałem kilka razy, mam nadzieję że żadnego błędu nie ma.

Tym razem to nie będzie poradnik, tylko zasygnalizowanie tematu, a pisać będę z pamięci, więc proszę wszystkiego nie brać dosłownie.

Otóż mam dwie płyty główne na procesorze Intel Atom i nie zamierzam z nich rezygnować dopóki same nie padną ze starości. Dlatego też podpiąłem dysk z Xubuntu18.04+4.14.148-rtai-amd64+linuxcnc-2.9 pod płytę Intel D525MW. Na pierwszy rzut oka wszystko było cacy, ale ja zawsze po zainstalowaniu nowego kernela wydaje polecenie xrandr , które wywaliło mi znany i doskonale mylący komunikat : Tak naprawdę nie chodzi tu o żadną gammę, tylko najzwyczajniej znaczy to, że sterowniki grafiki nie są zainstalowane. Faktycznie, polecenie lsmod nie pokazało modułu i915 , który jest stosowany dla tej karty. Tego modułu nie znalazłem też w /lib/kernel/modules ...
Wróciłem więc do kompilacji kernela.
Po uruchomieniu xconfig (takie lepsze menuconfig) zacząłem szukać grafiki Intela, ale bez żadnego skutku. Najzwyczajniej nie ma, a przecież być powinno.
Rozwiązanie może być tylko jedno - łatanie kernela musiało namieszać.
Faktycznie w pliku 0003-Countless-Kconfig-tweaks-for-IPIPE.patch znalazłem fragment : Jak już wcześniej pisałem, linie zaczynające się minusem to te które trzeba usunąć, a zaczynające się plusem to te które należy dodać. W tym konkretnie przypadku, zmiana będzie polegała na dodaniu && !IPIPE na końcu jednej linii. Nawiasem mówiąc bardzo podobny fragment dotyczy też grafiki Intela GMA.
Tutaj potrzebna jest wiedza z podstaw programowania, ale znowu nic skomplikowanego, najzwyczajniej && znaczy "oraz" a wykrzyknik oznacza negację i możemy go rozumieć jako "nie". Po prostu moduły kernela mają zależności podobne jak pakiety debiana - jedne się wzajemnie wymagają, inne się wzajemnie wykluczają ...
Tutaj akurat moduły i915 oraz IPIPE wzajemnie się wykluczają i albo rybka albo pipka, czyli albo kernel będzie rtai, albo będzie obsługiwał grafikę Intela, ale na raz nie da rady.
Nie pozostało nic innego jak ręczna ingerencja w źródła. Zasadniczo tego robić NIE WOLNO, bo nie jesteśmy w stanie przewidzieć jaki wpływ na resztę programu może mieć zmiana jednej linii.
Ponieważ jednak nie miałem nic do stracenia, to otworzyłem już załatany plik drivers/gpu/drm/i915/Kconfig do edycji i po chamsku usunąłem && !IPIPE z końca właściwej linii. To samo zrobiłem z drivers/gpu/drm/gma500/Kconfig .
Po uruchomieniu xconfig grafika Intela cudownie się odnalazła i zaznaczyłem ją do kompilacji. Na wszelki wypadek jednak odptaszkowałem wszystkie dostępne opcje, bo lepiej czegoś nie mieć, niż miałoby to zawieszać komputer.
Kompilator wypluł kilka ostrzeżeń o niespełnionych zależnościach, ale kernel się skompilował, dał się zainstalować i chyba działa prawidłowo.
Jitter się trochę popsuł, ale i tak jest rewelacyjny.

Naprawdę nie potrzeba być wybitnym programistą żeby coś zrobić. Wystarczy elementarna wiedza z podstaw programowania, google i umiejętność logicznego myślenia.

O kurcze sporo tego czeka mnie ciężka walka;)

Witam,
skończyłem właśnie instalacje według poradnika kolegi tuxcnc (świetna robota) i niby wszystko działa tylko problem mam z jitterem. O ile na starym Ubuntu 10.04 i na debianie był bardzo przyzwoity, max 12000 po godzinie testowanie to teraz po chwili testu potrafi wskoczyć na ponad 200000. Mój sprzęt to Asrock D1800 z Celeronem J1800 + 8Gb RAMu. Da się coś z tym zrobić?

pozdrawiam
Artur

isolcpus-t103711.html ?
A poza tym, to kompletnie straciłem zaufanie do latency test.
nigdy-nie-wierz-benchmarkom-t103779.html

Zhan pisze: ↑

19 mar 2020, 01:58

O ile na starym Ubuntu 10.04 i na debianie był bardzo przyzwoity, max 12000 po godzinie testowanie to teraz po chwili testu potrafi wskoczyć na ponad 200000.

Na Ubuntu pewnie miałeś linuxCNC 2.7
Ja robiłem instalacje z gotowego ISO, Debian wheezy i linuxCNC 2.7. Laatency test wskazywał max jitteru ok 7 US. Wystarczy tylko na skompilować i zainstalować linuxCNC 2.9 (bez kompilacji jądra, tylko i wyłącznie sam linuxCNC) i już latency test na tym samym komputerze potrafi skoczyć do 50us już w pierwszej minucie testu. Podglądałem na oscyloskopie jak wygląda przebieg sygnału kroku, generowany co 100 US. Trigger ustawiony na wychwytywanie levelu dłuższego niż (wychwytywanie poziomu niskiego dłuższego niż np 110 US) i tak naprawdę nie zaobserwowałem tych 50 US nigdy. Przebieg był stabilny i tak naprawdę nie różnił się od tego na linuxCNC 2.7 gdzie latency test wskazywał o wiele mniejsze wartosci.