Jak przygotować własną dystrybucję Linux-a

[Elvis]

Jakiś czas temu na forum pojawiło się kilka wpisów krytykujących Raspberry Pi jako platformę sprzętową. Nie próbuję nawet wmawiać, że malinka jest idealna - jednak niektóre problemy można rozwiązać bardzo (albo chociaż dość) łatwo. Problemy o których piszę to np. zużywanie kart SD, długi czas uruchamiania płytki, problemy z systemem plików jeśli nagle odłączymy zasilanie, długi czas kompilacji programów, czy brak możliwości uruchomienia systemu z pamięci USB.

Wiele z opisanych niedogodności wynika ze sposobu używania malinki. Większość osób stara się zrobić z niej mały komputer PC - i nie ma w tym nic złego, w końcu na Forbocie właśnie tak opisywaliśmy kurs Raspberry Pi. Jednak malinka nie we wszystkim może zastąpić komputer stacjonarny i czasem nieco inne podejście może dawać nieco lepsze rezultaty.

Komputer stacjonarny, a komputer wbudowany

Pierwsza istotna sprawa to rozróżnienie między rozwiązaniami wbudowanymi (embedded), a komputerem stacjonarnym (desktop/laptop). Urządzenia wbudowane są konstruowane do spełniania jednej, z góry określonej funkcji - przykłady to procesor w ekspresie do kawy, bankomacie, czy samochodzie. Oprogramowanie można aktualizować, nawet zmieniać na własne (tym zajmują się hackerzy), ale nadal program ma ściśle określone zadanie do wykonania. System ogólnego przeznaczenia, to nasze komputery stacjonarne lub przenośne - czyli zupełne przeciwieństwo wbudowanych. Można na nich grać w pasjansa, Wiedźmina, a nawet inne gry, przeglądać internet, pisać programy i robić miliony innych rzeczy. Instalacja nowych programów jest łatwa, niekiedy nawet udaje się je odinstalować.

Arduino jest kolejnym przykładem platformy wbudowanej. Program kompilujemy na PC, wgrywamy na płytkę i ma on wykonywać to co sobie zaplanowaliśmy - migać diodą, sterować robotem, itd. Ale już nowych progamów nie dodamy, nie będziemy na Arduino kompilować kodu, ani grać w pasjansa (chyba że to jest główna funkcja naszego układu).

Raspberry Pi natomiast jest najczęściej używane jako mały komputer PC. Instalujemy na karcie SD Raspbiana (lub inną dystrybucję) i dalej używamy tak samo jak komputer stacjonarny. Może gier jest mniej, ale minecraft działa całkiem fajnie, RetroPie pozwala na emulację starych komputerów i konsol, a użwanie kompilatora (np. gcc) nikogo nie dziwi. Raspberry Pi całkiem dobrze sobie z takimi zadaniami radzi, ale to wbrew pozorom nadal głównie komputer wbudowany.

W niniejszym artykule chciałbym chociaż wprowadzić w nową opcję, czyli użycie malinki jako komputera wbudowanego - mającego jedno zadanie, które dobrze wykonuje.

System operacyjny

Wszyscy wiemy jak działa Raspberry Pi - na karcie SD mamy ulubioną dystrybucję, kartę umieszczamy w czytniku, podłączanie zasilanie, czekamy, chwilę jeszcze czekamy, a może jeszcze jedną chwilę... i mamy pulpit z ikonkami albo chociaż konsolę do wydawania poleceń. Programy pobieramy z sieci (repozytorium), apt jest prosty i sympatyczny w użyciu.

A gdybyśmy tak spróbowali przygotować własną, mniejszą ale dopasowaną do naszych potrzeb wersję systemu? Okazuje się że nie jest to aż tak trudne (chociaż proste też nie jest), w nagrodę będziemy za to mogli pozbyć się problemów o których wspominałem na początku artykułu.

Yocto

Własną dystrybucję Linux-a można przygotować zupełnie od podstaw - zaczynając od kompilacji kompilatora. Jest to jednak dość złożony proces, świetny do nauki, ale niekoniecznie wygodny. Na szczęście znajdziemy gotowe projekty przygotowujące naszą dystrybucję linuksa od podstaw. Buildroot (https://buildroot.org/) jest jednym z takich projektów - pozwala on na łatwe wybranie potrzebnych nam programów oraz ich skompilowanie ze źródeł.

Ostatnio coraz większą popularność zyskuje jednak inny projekt - Yocto (https://www.yoctoproject.org/). Działa o wiele wolniej niż buildroot (jak to z narzędziamy opartymi o Pythona bywa), ale lepiej sprawdza się w dużych projektach.

W następnym wpisie postaram się opisać jak można użyć Yocto to przygotowania własnej wersji systemu dla malinki.

 

 

Jeszcze dwa słowa odnośnie buildroot-a. Dawno, dawno temu opisywałem jak użyć go podczas instalowania linuksa na netbook-u domyślnie pracującym z Androidem: https://forbot.pl/blog/sprawdz-jak-tanio-zbudowac-robota-z-systemem-linux-id7751

To co chcę teraz opisać to bardzo podobne rozwiązanie, ale zamiast netbook-a jest Raspberry Pi, a rolę Androida zajmuje Raspbian. No i po tych kilku latach yocto uzyskało pewną przewagę na buildrootem, więc też będzie użyte.

Szybki start

Żeby nie zanudzić najpierw szybki i dość ogólny opis. Celem będzie utworzenie podstawowego obrazu systemu, z którego wystartuje malinka.

Najpierw należy przygotować odpowiedni komputer PC oraz system operacyjny. System to oczywiście Linux - wspierane są dystrybucje Debian, Ubuntu, Fedora, OpenSUSE oraz CentOS. Prawdopodobnie użycie innej dystrybucji jest też możliwe, może jednak wymagać dodatkowych kroków. W zależności od posiadanej wersji musimy zainstalować odpowiednie pakiety oprogramowania, wszystko znajdziemy opisane tutaj: https://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#required-packages-for-the-host-development-system

Yocto można używać w systemie Windows lub MacOS wykorzystując maszynę wirtualną. Jednak takie rozwiązanie ma znaczącą wadę - bardzo spowalnia i tak czasochłonną kompilację obrazu systemu. Nie polecam takiego rozwiązania, lepiej używać natywnego linux-a i poszukać możliwie mocnego komputera - 4 rdzenie to raczej minimum, ale yocto potrafi nawet 44 wykorzystać (tyle testowałem), więc im silniejszy komputer tym lepiej i szybciej - a maszyny wirtualne pod względem wydajności niestety nie oszałamiają.

Oprócz szybkiego procesora o możliwie wielu rdzeniach, będziemy potrzebowali również sporo miejsca na dysku. Minimum to ok. 30 GB, ale nieco bardziej rozbudowana konfiguracja może potrzebować i 100GB. Oczywiście szybki dysk ma swoje zalety, więc jeśli mamy miejsce na dysku SSD, warto go użyć.

Ja wykorzystuję dysk SSD podłączany przez USB. To całkiem wydajne rozwiązanie, a możliwość odłączenia dysku od stacji roboczej i podłączenia do laptopa bardzo się przydaje. Dlatego u mnie ścieżka do projektu jest nieco długa: /mnt/usbssd/raspberry/yocto

W tym katalogu należy pobrać sam projekt yocto, czyli wykonać:

git clone -b sumo git://git.yoctoproject.org/poky.git

Potrzebne będą jeszcze dwie tzw. warstwy, czyli powiedzmy biblioteki: meta-openembedded oraz meta-raspberrypi.

Pobiera się je poleceniami:

git clone -b sumo git://git.yoctoproject.org/meta-raspberrypi
git clone -b sumo git://git.openembedded.org/meta-openembedded

Teraz w katalogu /mnt/usbssd/raspberry/yocto znajdziemy trzy podkatalogi: poky, meta-raspberrypi, meta-openembedded.

Pierwszy z nich jest dla nas najważniejszy więc wchodzimy do niego, a następnie wczytujemy zmienne ze skryptu oe-init-build-env:

cd poky
source oe-init-build-env

Na ekranie widzimy podpowiedź co zrobić dalej, jednak zanim do tego przejdziemy musimy poprawić domyślną konfigurację yocto. Plik conf/bblayers.conf zawiera listę wybranych wartstw (bibliotek). Musimy dopisać używane przez nas, dopisujemy więc:

BBLAYERS ?= " \
  /mnt/usbssd/raspberry/yocto/poky/meta \
  /mnt/usbssd/raspberry/yocto/poky/meta-poky \
  /mnt/usbssd/raspberry/yocto/poky/meta-yocto-bsp \
  /mnt/usbssd/raspberry/yocto/meta-raspberrypi \
  /mnt/usbssd/raspberry/yocto/meta-openembedded/meta-oe \
  /mnt/usbssd/raspberry/yocto/meta-openembedded/meta-multimedia \
  /mnt/usbssd/raspberry/yocto/meta-openembedded/meta-networking \
  /mnt/usbssd/raspberry/yocto/meta-openembedded/meta-python \
  "

Kolejny krok to edycja głównego pliku konfiguracyjnego o nazwie conf/local.conf. Domyślnie zawiera on dużo komentarzy, uproszczona wersja wygląda następująco:

MACHINE = "raspberrypi3-64"
DL_DIR = "${TOPDIR}/downloads"
DISTRO ?= "poky"
PACKAGE_CLASSES ?= "package_ipk"
EXTRA_IMAGE_FEATURES ?= "debug-tweaks"
USER_CLASSES ?= "buildstats image-mklibs image-prelink"
CONF_VERSION = "1"
RPI_USE_U_BOOT = "1"
ENABLE_UART = "1"

Pierwsza linia ustala typ naszej "maszyny", czyli Raspberry Pi 3 w wersji 64-bitowej. Jeśli używamy innej wersji, musimy odpowiednio zmodyfikować ten wpis.

Co ciekawe cała dystrybucja będzie wykorzystywała ustawienia zoptymalizowane dla naszgo procesora - domyślnie Raspbian jest kompilowany tak, aby programy działały na najmniejszym wspólnym mianowniku, czyli starym Raspberry 1 - używając yocto nie tylko jądro, ale i cały system zostanie skompilowany pod nasze potrzeby. Nie zadziała na starszych płytkach, ale na naszej wykorzysta jej potencjał.

Kolejny ważny parametr to ustawienie RPI_USE_U_BOOT. Dzięki niemu zostanie użyty bootloader u-boot, co pozwoli na załadowanie systemu przez sieć (TFTP), podłączenie dysku sieciowego (NFS), albo nawet użycie pamięci USB. Jest to pierwszy etap pozwalający na pozbycie się usterek na które wiele osób narzeka.

W tym pliku można również wymusić użycie systemu "tylko do odczytu". Jedna dodatkowa linijka i karta SD będzie działać prawie w nieskończoność - do tego wrócimy później.

Na razie czas zacząć kompilację i zrobić sobie (długą) przerwę. Wydajemy polecenie:

bitbake core-image-minimal

Yocto pobierze z sieci źródła wszystkich programów a następnie je skompiluje. Taki proces wymaga szybkiego łącza i trwa... od 20min do 4h. Na szczęście później jest już szybciej, ale za pierwszym razem można sobie zrobić przerwę na lunch.

 

 

 

 

 

 

Po zjedzeniu lunchu, albo chociaż przerwie mamy gotowy obraz naszego systemu. Wynikowe pliki znajdziemy w katalogu tmp/deploy/images/raspberrypi3-64:

Tym co na początek nas zainteresuje to plik z gotowym obrazem całej karty SD, czyli core-image-minimal-raspberrypi3-64.rpi-sdimg. Warto zwrócić uwagę na wielkość obrazu - u mnie wyszło 56 MB. To nadal bardzo dużo, ale domyślny Raspbian wymaga kilku GB.

Kartę SD przygotujemy poleceniem dd, u mnie urządzenie /dev/sdh odpowiada karcie, więc polecenie:

sudo dd if=tmp/deploy/images/raspberrypi3-64/core-image-minimal-raspberrypi3-64.rpi-sdimg of=/dev/sdh bs=4M

Pozwala na nagranie obrazu na nośnik. Teraz można umieścić kartę w czytniku Raspberry Pi i wystartować system:

Uruchomienie sytemu zajmuje znacznie mniej czasu niż w przypadku domyślnego systemu. To nadal bardzo daleka od optymalnej konfiguracja, ale i tak linux jest gotowy do pracy w kilka sekund.

To co otrzymaliśmy to pierwsza, minimalna wersja systemu - mała ale zoptymalizowana dla naszego sprzętu. Nie znajdziemy na niej minecrafta, ani nawet interfejsu graficznego, ale to co wybraliśmy działa szybko i wydajnie. Mając taki system jako punkt wyjścia możemy przygotować bardziej rozbudowaną wersję, wyposażoną w potrzebne nam programy i biblioteki.

Warto natomiast zwrócić uwagę na nieco inny sposób pracy z systemem. Całą kompilację wykonujemy na komputerze stacjonarnym, malinka tylko wykonuje przygotowane programy. Działa więc tak jak Arduino, a nie typowy Raspbian.

 

Edytowano Sierpień 12, 2018 przez Elvis
błędy

[Elvis]

Nie samą maliną człowiek żyje

Już na samym początku wspominałem o tym, że Raspberry Pi nie jest wcale ani jedyną, najlepszą, ani najtańszą platformą sprzętową dla wbudowanego Linux-a. Jej ogromnym plusem jest bardzo dobre wsparcie, ale nic nie stoi na przeszkodzie w używaniu innych płytek. I tutaj ważna uwaga - w bardzo podobny sposób możemy łatwo przygotować obraz systemu również dla innych platform.

Yocto wykorzystuje tzw. warstwy - są to zestawy gotowych skryptów, jak dla mnie to takie moduły, czy biblioteki, ale ktoś wymyślił określenie warstwa więc będę się tego trzymać. W internecie znajdziemy całkiem sporo gotowych warstw, wiele osób przygotowuje własne - my też możemy, chociaż to chyba trochę bardziej zaawansowany temat.

Co ważne warstwy pozwalają na oddzielenie części sprzętowej (BSP - Board Support Package) od reszty systemu. Więc zmieniając warstwę meta-raspberrypi na inną dostaniemy taki sam system (tzn. z takimi samymi pakietami), ale działający na innej platformie.

Jakie platformy są wspierane? W sumie to prawie wszystkie - najlepiej do znajdowania warstw użyć wyszukiwarki: http://layers.openembedded.org/layerindex/branch/sumo/layers/

Wspomnę o kilku platformach, które moim zdaniem są warte uwagi:

• BeagleBone - jest domyślnie wspierana przez Yocto i włączona do dystrybucji
• Odroid (http://layers.openembedded.org/layerindex/branch/sumo/layer/meta-odroid/) - często wymieniane jako konkurencja malinki, na ogół wydajniejsze niż oryginał
• Xilinx (http://layers.openembedded.org/layerindex/branch/sumo/layer/meta-xilinx/) - tutaj znajdziemy wsparcie dla układów Zynq, czyli FPGA z Cortex-A9
• Freescale (http://layers.openembedded.org/layerindex/branch/sumo/layer/meta-freescale/) - bardzo fajne procesory i płytki, trochę droższe ale z lepszą dokumentacją
• Intel (http://layers.openembedded.org/layerindex/branch/sumo/layer/meta-intel/) - yocto może też przygotować dystrybucję dla x86. Stary komputer może odzyskać drugą młodość jeśli potraktujemy go jako urządzenie wbudowane. Poza tym są wszystkie LattePanda i podobne (był też Edison, ale to już historia)
• Tegra (http://layers.openembedded.org/layerindex/branch/sumo/layer/meta-tegra/) - coś dla miłośników szybkich maszyn oraz GPU (albo hackerów Nintendo Switch)

W nieco starszej wersji yocto mamy jeszcze większy wybór:

• Altera (http://layers.openembedded.org/layerindex/branch/rocko/layer/meta-altera/) - układy z FPGA oraz Cortex-A9, odpowiednik Zynq od Xilinx-a. Właśnie tej warstwy używałem przygotowując oprogramowanie dla mojego wyświetlacza paneli LED (https://forbot.pl/forum/topic/12015-wyswietlacz-z-paneli-led/)
• AllWinner (http://layers.openembedded.org/layerindex/branch/rocko/layer/meta-sunxi/) - to coś dla miłośników tańszych układów, znajdziemy je na wszelkiej maści OrangePi, BananaPi, NanoPi oraz Olinuxino

Jeśli będzie zainteresowanie tematem Yocto, postaram się opisać nieco dokładniej możliwości jego wykorzystania z Raspberry Pi - ale większość omawianych możliwości można wykorzystać na innych platformach.

[Nawyk]

Jest zainteresowanie 🙂

[ethanak]

A może warto sprawdzić co oznacza słowo "dystrybucja"?

Dajesz przepis na zrobienie własnego Linuksa (dostosowanego do Twoich potrzeb). Co to ma wspólnego z dystrybucją?

Tylko nie pisz że "tak się na to mówi".

PS. Kiedyś to się nazywało "LFS". Dzisiaj mamy narzędzia do robienia sobie takich LFS-ów skol'ko ugodno. Tym niemniej z dystrybucją nie ma to nic wspólnego.

 

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[Elvis]

A może mogłbyś podać swoje źródło mądrości? Będzie łatwiej się dogadać, zamiast rzucać hasłami. O ile rozumiem LFS to Linux From Scratch - oczywiście to fajna sprawa, nawet miałem o tym napisać, ale yocto wykonuje nieco więcej.

Ja używając słowa dystrybucja wykorzystywałem bezpośrednie tłumaczenie ze strony: https://www.yoctoproject.org/

Ale jeśli "The Yocto Project.  It's not an embedded Linux Distribution, It creates a custom one for you." należy inaczej rozumieć, albo tłumaczyć - chętnie dowiem się czegoś nowego. W sumie człowiek całe życie się uczy 🙂

 

Skoro o LFS już wspomnieliśmy – bardzo polecam wszystkim zainteresowanym tworzeniem własnego obrazu Linux-a zupełnie od podstaw książkę:

“Linux w systemach embedded” Marcina Bis-a https://wydawnictwo.btc.pl/elektronika/184248-linux-w-systemach-embedded.html

Jest warta swojej wagi w bitcoinach i moim zdaniem nie ma nic lepszego na polskim rynku wydawniczym, a nawet na amazonie niełatwo znaleźć pozycję na podobnym poziomie. Autor nie jest entuzjastą yocto, co w pełni rozumiem – ale w kwestii tworzenia linuxa od podstaw, nie ma sobie równych.

[ethanak]

Proszę bardzo - Słownik Wyrazów Obcych:

Dystrybucja (łac. „distributio” – 'rozdział, podział' od distribuere 'rozdzielać; rozdawać'; dis- 'roz-; na części' i tributum 'podatek; danina' od tribuere '(roz)dawać; udzielać; łożyć' z tribus 'okrąg, jednostka podziału terytorialnego ludności starożytnego Rzymu')

"Dystrybucja Linuksa" to takie coś, co paru ludzi w pocie czoła składa do kupy a kupa ludzi sobie to bez problemu instaluje. Są wielkie dystrybucje (RedHat, Debian), niszowe (PLD), dystrybucje bazujące na innych dystrybucjach (Ubuntu na Debianie, Mint na Ubuntu), czy nawet dystrybucje przygotowywane przez pojedyncze osoby (Knoppix).

W naszym przypadku nie ma mowy o rozpowszechnianiu - tworzysz pojedynczy egzemplarz Linuksa, dokładnie jak w LFS, i tego egzemplarza nie rozpowszechniasz.

A w przytoczonym zdaniu określenie "custom one" nie odnosi się do dystrybucji, tylko do Linuksa.

A żeby nie było: nie neguję absolutnie treści posta, być może sam skorzystam z przepisu (choćby dlatego, że kupiłem sobie właśnie RPi3+, a o Yocto usłyszałem po raz pierwszy w życiu). Czepiam się tylko i wyłącznie do jednego słówka 🙂

 

 

[Elvis]

Myślę, że nie warto spierać się o takie głupoty - jako inny przykład definicji dystrybucji linuxa polecam wiki: https://pl.wikipedia.org/wiki/Dystrybucja_Linuksa

Tutaj mamy nieco lepiej zdefiniowane kryteria, bo pisanie o paru ludziach to chyba kiepski pomysł - w każdej nietrywialnej firmie znajdziemy paru ludzi, niektórzy nawet pracują.

Pobieranie i używanie też nie nadaje się zbytnio - jako ciekawostkę podam, że yocto ma manager pakietów, do wyboru .deb, .rpm, .ipk oraz .tar - nie opisuję tego, ale pakiety są automatycznie tworzone i wystarczy je umieścić na serwerze. A co do jednego użytkownika to faktycznie na RPi moja dystrybucja ma jednego użytkownika - natomiast systemy nad którymi pracuję zawodowo mają znacznie więcej użytkowników. Wszyscy pobierają pakiety i z nich korzystają np. oglądając telewizję, chociaż wcale nie widzą że na pokładzie dekodera działa linux...

Więc zostawmy może te spory językowe w spokoju - yocto to w rzeczywistości zestaw skryptów, coś jak make. Pozwala na skompilowanie relatywnie dużego systemu, a czy nazwiemy go dystrybucją, firmware-m, czy androidem to zostawmy lingwistom.

 

A jak już się czepiamy słówek - formalnie Linux to samo jądro... Cała reszta to właśnie dystrybucja, czyli zestaw oprogramowania bazujący na GNU. Dlatego niektórzy puryści nazywają takie cudo GNU/Linux, natomiast to co mamy w telefonach Android/Linux.

Zawartość karty SD

Wracając do głównego wątku, czyli możliwości pracy z linuksem nieco inaczej niż przez instalację Raspbiana.

Ostatnio wygenerowałem obraz systemu poleceniem bitbake core-image-minimal. Jak łatwo się domyślić jest to minimalny działający obraz, możemy go uruchomić ale praca na nim nie będzie pasjonująca. Jednak zanim przejdziemy dalej chciałbym zatrzymać się przez chwilę nad tym co taki minimalny obraz zawiera - skoro jest mały to łatwiej zrozumieć jak to działa.

Tutaj pierwsza uwaga - wbrew pozorom działa już całkiem sporo rzeczy. Zawdzięczamy to jądru systemu - mamy minimalny zestaw oprogramowania, ale jądro oraz większość sterowników jest już na miejscu. Jeśli podłączymy np. wyświetlacz zobaczymy że działa - nawet bez x serwera.

Wspominam o tym żeby zwrócić uwagę na pewną nadmiarowość pełnych dystrybucji. Okazuje się że system wbudowany może używać znacznie mniej pamięci i innych zasobów niż pełna wersja "desktopowa".

Na karcie SD znajdziemy podobnie jak w przypadku Raspbiana dwie partycje:

Pierwsza ma rozmiar "aż" 40MB i typ FAT32. Druga to główny system plików, który zajmuje raptem 12MB.

Na pierwszej partycji znajdziemy firmware dla GPU Malinki (za chwilę do tego wrócę), bootloadery oraz obraz jądra linuksa.

Druga partycja to raczej minimalistyczny system plików - znajdziemy na nim (dość sporą) bibliotekę języka C oraz BusyBox, czyli program udostępniający podstawowe polecenia powłoki (https://busybox.net/about.html).

Warto zwrócić uwagę na znaczny rozmiar katalogu lib - to właśnie domyślna biblioteka C tyle zajmuje. W urządzeniach wbudowanych są popularne jej zamienniki, jak chociażby uclibc (https://www.uclibc.org/) - nie tylko są mniejsze, ale często szybciej działają.

W każdym razie taka optymalizacja pojednczych MB to temat na osobny wątek.

Jak startuje system

Celem moich być może zbyt długich wpisów jest pokazanie jak korzystać z u-boot-a, jednak niejako przy okazji chciałbym wyjaśnić miejsce bootloadera w procesie uruchamiania komputera.

Zacznijmy od czegoś prostego co wszyscy znają, czyli mikrokontrolera. Powiedzmy ATmega328 - po włączeniu zasilania następuje reset procesora oraz wykonywany jest program z pamięci Flash. Adres gdzie zaczyna się program jest znany (nie jestem pewien jaki, ale to chyba mało istotne). Nowy mikrokontroler ma pustą pamięć Flash, więc przed pierwszym zaprogramowaniem procesor wykonuje tylko instrukcje NOP (https://www.microchip.com/webdoc/avrassembler/avrassembler.wb_NOP.html).

Aby wgrać program konieczny jest sprzętowy programator - po zaprogramowaniu, program z pamięci Flash będzie wykonywany zaraz po załączeniu zasilania lub resecie procesora. Wszystko jest proste, ale wymaga dwóch istotnych elementów: pamieci flash oraz programatora.

Konieczność posiadania programatora została elegancko rozwiązana w przypadku Arduino. Nowe mikrokontrolery są programowane za pomocą sprzętowego programatora i wgrywany jest do nich krótki program - nazywany właśnie bootloader-em. Przy kolejnych uruchomieniach procesora najpierw będzie zawsze działać bootloader. Wykona on sprawdzenie stanów odpowiednich pinów lub poczeka na dane przesyłane przez UART i jeśli wykryje odpowiednie sekwencje umożliwi programowanie pozostałej części pamięci flash. Natomiast podczas normalnej pracy urządzenia po prostu przekaże sterowanie do programu użytkownika.

W pamięci flash przechowywane są więc dwa programy: bootloader oraz kod użytkownika. Jednak nie działają one równocześnie - bootloader rozpoczyna pracę, a następnie przekazuje sterowanie do głównego programu.

Podobny schemat wykorzystywany jest w przypadku mikroprocesorów, chociaż jest nieco bardziej skomplikowany.

Raspberry Pi jest pod tym względem nieco nietypowe - BCM2837 zawiera aż dwa procesory. Głównym wcale nie jest znany nam ARM, ale procesor graficzny, czyli VideoCore IV (https://en.wikipedia.org/wiki/VideoCore). Wiele osób takie rozwiązanie krytykuje, ale wcale nie jest ono aż tak nietypowe - spotkamy je również w świecie mikrokontrolerów, przykładowo przetworniki ADC mogą mieć wbudowany procesor (http://www.analog.com/en/products/aduc814.html), moduły radiowe często mogą wykonywać programy (http://www.ti.com/lit/ug/swru319c/swru319c.pdf), nawet popularny ESP8266 jest właściwie modułem radiowym który przypadkiem ma również procesor.

Po załączeniu zasilania pierwszy startuje procesor graficzny, czyli VideoCore. Początkowy program jest zapisany w jego pamięci ROM - tutaj pojawia się pierwsza różnica między światem mikorkontrolerów i mikroprocesorów - ROM zamiast flash, to wbrew pozorom istotna zmiana. Jednak zasada jest identyczna - w ROM mamy bootloader, który wczytuje program. Różnica to liczba etapów. Na Arduino bootloader wczytywał od razu program główny, natomiast w przypadku mikroprocesorów najczęściej jest uruchamianych kilka bootloaderów, a dopiero na końcu właściwy program.

Więc jako pierwszy uruchmia się bootloader zapisany w pamięci ROM - niewiele o nim wiadomo, większość producentów traktuje taki kod jako bardzo tajny. Ten bootloader potrafi obsługiwać karty SD oraz system Fat32. Stara się wczytać i uruchomić plik o nazwie bootcode.bin. Jak łatwo się domyślić, yocto pobrało odpowiedni plik z sieci i umieściło w obrazie, który nagraliśmy na karcie. Kolejny etap to wczytanie pliku start.elf. Nie jestem na 100% pewien, ale to chyba główny program dla VideoCore. Na naszej karcie znajdziemy jeszcze wersję start_x.elf z obsługą kamery RaspiCam oraz start_db.elf w wersji do debugowania (ale kodu i tak nie dostaniemy). Jest jeszcze plik start_cd.elf - nie wiem po co, może ktoś na forum wie do czego ta wersja służy?

Pliki start.elf mają odpowiadajace im pliki z danymi, czyli fixup.dat, fixup_x.dat, fixup_db.dat oraz fixup_cd.dat. Wszystkie znajdziemy na naszej karcie SD - chociaż niepotrzebne możemy usunąć.

Jeszcze dwa pliki są istotne dla uruchamiania malinki - config.txt oraz cmdline.txt. Oba są w formacie tekstowym, więc można użyć dowolnego edytora do ich zmiany. Pełnią funkcję ustawień, coś jak BIOS w stacjonarnym komputerze. Pierwszy jest bardzo rozbudowany, więcej o nim przeczytamy na stronie raspberrypi: https://www.raspberrypi.org/documentation/configuration/config-txt/README.md. Drugi zawiera parametry dla jądra systemu - używając u-boota nie będziemy musieli z niego korzystać.

Teraz ostatnia i najważniejsza część - VideoCore ładuje z karty plik o nazwie kernel8.img do pamięci RAM oraz uruchamia rdzeń ARM tak aby wykonywał wczytany kod.

Pewnie większość osób odgadnie, że kernel8.img to jądro systemu Linux - tak jest domyślnie, ale to wcale nie jest wymagane. Możemy napisać własny program, nazwać go kernel8.img i zostanie on uruchomiony bez Linux-a, czyli tak jak na Arduino. Jeśli lubimy takie ekstremalne rozrywki, polecam kurs programowania Raspberry Pi bez systemu operacyjnego: https://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/, jest nawet wersja dla języka C zmiast asemblera (ale to takie niesportowe 😉  : http://www.valvers.com/open-software/raspberry-pi/step01-bare-metal-programming-in-cpt1/.

W naszym przypadku kernel8.img to wcale nie jądro linuksa - jądro znajdziemy w pliku Image. Natomiast kernel8.img to u-boot, czyli kolejny bootloader: https://www.denx.de/wiki/U-Boot

Konfiguracja przygotowana przez yocto startuje więc u-boota, który dopiero uruchamia właściwego Linux-a. W kolejnych wpisach pokażę do czego się to może przydać - wspomnę tylko że możliwości są spore, a przede wszystkim możliwe jest pobieranie obrazu przez sieć. Więc karta SD może być używana jedynie na początku uruchamiania systemu, podczas gdy wszystkie pliki przechowamy bezpiecznie na serwerze lub stacji roboczej.

 

 

Edytowano Sierpień 13, 2018 przez Elvis

[ethanak]

Dlatego niektórzy puryści nazywają takie cudo GNU/Linux, natomiast to co mamy w telefonach Android/Linux.

O tempora, o mores!

[Elvis]

Do czego może się przydać U-Boot

Oczywiście chodzi mi o bootloader, pewnie łódź podwodna miałaby inne zastosowania. Swoją drogą nie sposób nie docenić poczucia humoru Niemców, którzy wybierali nazwę dla swojego projektu. W każdym razie pisząc uboot będę miał na myśli zawsze bootloader.

Jak wspominałem wcześniej podstawowym zadaniem bootloadera jest wczytanie głównego programu. Jeśli chcemy jednak skorzystać z interfejsu bootloadera musimy podczas uruchamiania malinki nacisnąc dowolny klawisz (w odpowiednim momencie). Wtedy zobaczymy interfejs naszego uboot-a:

Polecenia wydawane są w podobny sposób jak w przypadku konsoli. Jednym z pierwszych, które warto poznać i wypróbować to help (a powinno być SOS):

Help wyświetla listę poleceń, jeśli chcemy poznać dokładniej wybrane polecenie możemy napisać help <komenda>. U-boot to bardzo rozbudowane narzędzie i można byłoby o nim napisać niejedną książkę, więc osoby zainteresowane odeślę do dokumentacji: https://www.denx.de/wiki/DULG/Manual

Opiszę tylko w skrócie do czego ten bootloader może nam się przydać. Jednak zanim do tego przejdę jeszcze jedna informacja - uboot korzysta z poleceń oraz zmiennych.

Wszystkie zmienne można wyświetlić pisząc printenv. Do ustawiania wartości zmiennej przydaje się setenv, a nowe wartości można zapisać za pomocą saveenv.

Piszę o zmiennych, ponieważ jedna z nich jest bardzo ważna. Mam na myśli zmienną bootcmd. Przechowuje ona polecenia wykonywane domyślnie, czyli gdy użytkownik nie przerwie uruchamiania systemu (ile czasu u-boot czeka ustala zmienna bootdelay).
 

Domyślna konfiguracja którą wygenerowało yocto jest koszmarnie skomplikowana, pokażę więc jej uproszczoną wersję:

setenv bootargs "8250.nr_uarts=1 cma=256M bcm2708_fb.fbwidth=800 bcm2708_fb.fbheight=480 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 dwc_otg.lpm_enable=0 console=ttyS0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait"
fatload mmc 0:1 ${kernel_addr_r} Image
booti ${kernel_addr_r} - ${fdt_addr}

Pierwsze polecenie ustawia wartość kolejnej ważnej zmiennej, czyli bootargs. Jej wartość zostanie przekazana do jądra jako parametry (w Raspbianie taką funkcję spełnia plik cmdline.txt).

Instrukcja fatload wczytuje z karty sd (mmc 0) plik o nazwie Image. Gdybyśmy więc chcieli nazwać nasz kernel inaczej, możemy to bez problemu zrobić.

Na koniec polecenie booti uruchamia samego linuksa.

Przyznam, że nie wiem jak wczytywany jest plik device-tree, jego adres określa zmienna fdt_addr, ale wygląda jakby był wczytywany poza działaniem bootloadera. Jest to dość nietypowe, większość płytek ma po prostu jeszcze jedno polecenie fatload, które wczytuje plik .dtb do pamięci.

Warto zapamiętać z tego dwie rzeczy: po pierwsze u-boot jest dostępny na prawie wszystkie platformy wbudowane, znajdziemy go nawet na urządzeniach z Androidem. Druga sprawa, to jednak nieco nietypowe zachowanie malinki - ma swoje dziwactwa, chyba ze względu na obsługę nakładek (overlay).

Dlaczego tyle pisałem o uboocie? chciałem pokazać, że zamiast fatload można użyć innych poleceń i pobrać plik jądra np. z serwera TFTP. Ja używam podczas programowania serwera DHCP oraz lokalnego połączenia dedykowanego płytce ewaluacyjnej. Odpowiednio konfigurując serwer, wystarczy zamiast fatload wydać polecenie dhcp. Wtedy przy każdym uruchomieniu płytka pobierze najnowsze jądro ze stacji roboczej. Wydaje się to dziwne? Nic bardziej mylnego, można zmieniać jądro i nie potrzeba wyjmować karty SD z malinki - wystarczy reset i nowa wersja jest na płytce. Takie podejście ma co najmniej dwa zastosowania: przydaje się podczas pracy z kodem jądra, to dużo łatwiejsze niż ciągłe przekładanie karty. Kolejne zastosowanie które widziałem to urządzenie z dużą ilością malinek, tak powiedzmy 200. Aktualizacja obrazu systemu to niezbyt miłe zadanie - a używając sieci wystarczy reset i wszystko działa z najnowszą wersją.

Kolejna ważna sprawa to parametry przekazywane do jądra. Znajdziemy tam fragment: root=/dev/mmcblk0p2. Jest to informacja dla jądra, że główny system plików znajduje się na partycji 2 karty SD. Zmieniając ten parametr możemy łatwo używać systemu plików z dysku podłączonego przez USB, albo co bardzo wygodne z serwera NFS.

O ile TFTP dla jądra przydaje się w bardziej ekstremalnych przypadkach, o tyle NFS to idealne rozwiązanie dla każdego programisty. Mamy wtedy wszystkie pliki na naszej stacji roboczej, a pisząc programy lub zmieniając konfigurację nie musimy nic kopiować. Co najważniejsze zanik prądu nam nie groźny - no i tworząc backup nie musimy wyjmować karty SD z nośnika. Wszystko jest już i tak na dysku komputera stacjonarnego.

Ostatnie zastosowanie to system plików tylko do odczytu. To całkiem łatwe rozwiązanie w przypadku yocto - postaram się je pokazać nieco później.

 

Edytowano Sierpień 13, 2018 przez Elvis

[Elvis]

Jak dodać pakiet

Pisanie o bootloader-ach mogło wydać się już nieco nudne, wracam więc do głównego wątku. Jak wspominałem wcześniej core-image-minimal tworzy minimalny obraz systemu. Wbrew pozorom to często dobry punkt wyjścia do tworzenia własnego projektu. Wypadałoby jednak coś to tego minimum dodać. Można to zrobić na wiele sposobów, najprościej jest zmienić plik conf/local.conf.

Jak pamiętamy są w nim główne ustawienia z których korzysta yocto. Do dodawania pakietów służy polecenie:

CORE_IMAGE_EXTRA_INSTALL += "bcm2835-dev rpi-gpio wiringpi"

Czyli dodajemy do zmiennej CORE_IMAGE_EXTRA_INSTALL oddzielone spacjami nazwy potrzebnych nam pakietów. Yocto zadba o wszystkie zależności, więc dodając bibliotekę rpi-gpio dla pythona automatycznie włączyłem wsparcie dla tego języka. Yocto doda wybrane pakiety do obrazu, przygotuje również paczki z tymi pakietami, więc jeśli ktoś chciałby używać takiego systemu w sposób typowy dla zwykłych dystrybucji może sobie powiedzmy wiringpi pobrać i doinstalować.

Muszę się jednak przyznać do pewnego problemu, który obszedłem niezbyt elegancko. Wcześniej miałem ambicje żeby wszystko kompilować w trybie 64-bitowym. Niestety okazało się, że moduły specyficzne dla Raspberry jak np. GPIO nie radzą sobie z tym najlepiej. Ostatecznie więc zmieniłem definicję maszyny i używam:

MACHINE = "raspberrypi3"

Pewnie można byłoby zostać przy raspberry3-64, ale tak było najłatwiej. Za to nie tylko gpio zaczęło działać, ale nawet framebuffer wystartował w pełni:

Obraz z dodanymi pakietami jest trochę większy - zajmuje już 76MB, jednak jest znacznie ciekawszy. Mamy na nim bibliotekę wiringPi, python-a 2, oraz RPi.GPIO - można więc uruchamiać przykłady z kursu Raspberry Pi (https://forbot.pl/blog/kurs-raspberry-pi-podstawy-pythona-gpio-id26099).

Pakiety które chcemy zainstalować znajdziemy w odpowiednich warstwach, te które dodawałem są w meta-raspberrypi, a dokładniej meta-raspberrypi/recipes-devtools: http://git.yoctoproject.org/cgit.cgi/meta-raspberrypi/tree/recipes-devtools

W ten sposób możemy dodawać gotowe pakiety do systemu, aż uzyskamy oczekiwaną konfigurację. Możemy również tworzyć własne pakiety (i dołączać do obrazu) - w ten sposób yocto przygotuje nam gotową dystrybucję zgodną z oczekiwaniami naszego projektu.

Dla osób lubiących interfejsy graficzne dostępne jest narzędzie o nazwie Toaster: https://www.yoctoproject.org/software-item/toaster/

Pozwala ono na wykonywanie opisywanych czynności za pomocą interfejsu opartego o przeglądarkę. Ja nie jestem zwolennikiem takich rozwiązań, ale na pewno łatwiej jest tak wybierać pakiety:

 

 

[Elvis]

System plików tylko do odczytu

Napisałem się już całkiem sporo o yocto, a pewnie wiele osób nadal nie widzi najmniejszego sensu w jego używaniu. Może i system uruchamia się trochę szybciej, ale to nie zawsze istotne.

Nie pozostaje mi nic innego niż pokazać kolejną zaletę używania yocto - albo raczej przygotowywania obrazu systemu na PC.

Wiele osób narzeka na problemy z kartami SD. Jest to jedna z bolączek użytkowników Raspberry i argument zwolenników innych platform - podobno karty padają jak muchy (a emmc jest niby nieśmiertelne). Oczywiście jest w tym nieco prawdy - zapis do pamięci Flash powoduje jej zużycie, a tanie karty SD mają tendencję do zaskakująco krótkiego czasu życia.

A co gdybyśmy nie zapisywali danych na karcie? Pewnie wiele osób pomyśli że to bez sensu - ale w tym szaleństwie jest metoda. Wcale nie musimy zupełnie nic nie zapisywać. Wystarczy, że system operacyjny nie będzie modyfikował danych na karcie, a to co nas interesuje i jest faktycznie potrzebne zapiszemy "ręcznie", np. na innej partycji lub zewnętrznym dysku.

Łatwo powiedzieć, ale trudniej zrobić. Okazuje się jednak, że w przypadku yocto to bardzo proste. Wystarczy do pliku conf/local.conf dopisać linijkę:

IMAGE_FEATURES = "read-only-rootfs"

Teraz możemy przygotować obraz systemu tak jak dotychczas, następnie nagrać na kartę i gotowe:

Jak widać zapis nie jest możliwy, więc karta powinna wytrzymać dużo, dużo dłużej niż w przypadku Raspbiana. Oczywiście czasem możemy jednak potrzebować zapisać pliki, ale jak wspomniałem wcześniej - do tego najlepiej użyć kolejnej partycji (w końcu użyliśmy raptem 76MB), albo podłączyć stary dobry dysk HDD (przez USB) i zapisywać na nim to co potrzebujemy.

Gdybyśmy jednak potrzebowali coś zmienić na karcie, wystarczy że "zamontujemy" system w trybie do zapisu:

mount -o remount,rw /

Po wydaniu tego polecenia mamy system plików dostępny jak zwykle i możemy np. zmienić pliki konfiguracyjne, czy doinstalować programy. A po kolejnym uruchomieniu systemu znowu wszystko wróci do normy (czyli trybu tylko do odczytu).

Sieciowy system plików

W tym momencie opisałem już podstawowe funkcje zarówno yocto, jak i uboot-a. Wspominałem o nich nie bez powodu - chciałęm opisać jak przygotować konfigurację bardzo wygodną podczas programowania oraz przygotowywania obrazu systemu.

Na początek mały powrót do uboot-a i jego zmiennych. Konfiguracja ustalona przez yocto jest nieco skomplikowana, więc zacznę od zastąpienia jej bardzo prostym odpowiednikiem:

setenv bootargs "8250.nr_uarts=1 bcm2708_fb.fbwidth=800 bcm2708_fb.fbheight=480 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000  dwc_otg.lpm_enable=0 console=ttyS0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait"
setenv bootcmd "fatload mmc 0:1 0x01000000 uImage; bootm 0x01000000 - ${fdt_addr}"
setenv bootdelay 1
saveenv

Pierwsze polecenie ustala parametry dla jądra (bootargs) - domyślnie są one "wyciągane" z pliku .dtb, tutaj mamy po prostu tą samą wartość ale widoczną i łatwą do zmiany.

Druga ustawia wartość zmiennej bootcmd, której zawartość jest uruchamiana podczas startu systemu. Więc polecenia oddzielone średnikami będą domyślnie wykonywane po włączeniu malniki: fatload to wczytanie obrazu jądra z pliku uImage do pamięci, natomiast bootm uruchamia system Linux.

Zmieniłem jeszcze czas czekania na przerwanie startu systemu na jedną sekundę (bootdelay) - domyślne 3 sekundy to straszna strata czasu.

A na koniec polecenie saveenv zapisuje zmienne na karcie SD. Teraz można zrestartować malinkę - powinna uruchomić się jak zwykle. Z drugiej strony zamiast czarnej magii mamy prostą konfigurację. Czas ją zmodyfikować.

 

Pierwszy etap to wykorzystanie serwera DHCP. Nie jest on niezbędny, ale nie lubię ręcznie wpisywać wszystkich parametrów sieci.

Potrzebny będzie MAC adres naszej malinki. Okazuje się że jest on dostępny w uboot-cie jako zmienna ethaddr. Można ją odczytać poleceniem printenv, które można nawet skrócić do pierwszych dwóch liter, czyli pr:

Gdy znam adres mojej płytki, mogę ustawić jej parametry w konfiguracji serwera DHCP. Ja używam isc-dhcp-server, który działa na lokalnej karcie ethernet, dedykowanej dla raspberry (lub innej płytki). Do pliku /etc/dhcp/dhcpd.conf dopisuję następujące ustawienia:

host broken_rpi3 {
    hardware ethernet b8:27:eb:21:e9:ea;
    fixed-address 192.168.3.129;
    server-name "192.168.3.1";
    next-server 192.168.3.1;
    filename "raspberry/uImage";
    option domain-name-servers 8.8.8.8;
    option routers 192.168.3.1;
    option root-path "192.168.3.1:/srv/nfs/raspberry,vers=3";
}

Nazwa broken_rpi3 bierze się stąd, że moja malinka już ledwo żyje - grzeje się i WiFi nie działa, ale do testów jest idealna - chociaż nie będzie żal jak całkiem padnie. MAC adres odczytałem z uboot-a, adresy IP samej płytki, serwera itd. odpowiadają mojej sieci lokalnej.

Warto zwrócić uwagę na dwa pola: filename oraz root-path.

Pierwsze określa nazwę obrazu jądra - będzie pobierane z tego pliku zamiast z karty SD (to nie jest konieczne, ale bardzo wygodne). Drugi parametr to lokalizacja obrazu systemu na serwerze NFS - zamiast z karty SD malinka będzie używała systemu z folderu /srv/nfs/rapsberry (ale o tym za chwilę).

 

 

Jądro linuksa jest pobierane przez uboot-a, najwygodniej jest je umieścić na serwerze TFTP. U mnie serwer udostępnia pliki z folderu /srv/tftp, w nim mam katalog raspberry dla malinki oraz katalogi dla innych płytek. Malinka potrzebuje tylko pliku uImage, który został przygotowany przez yocto (większość płytek z którymi pracowałem wymaga jeszcze co najmniej jednego pliku - Device Tree, czyli opisu peryferiów platformy). Wystarczy więc skopiować go do katalogu /srv/tftp/raspberry i zrestartować malinkę - wyjmowanie karty SD nie jest konieczne .

Główny system plików jest udostępniany przez serwer NFS (Network File System), ja używam z pakietu nfs-kernel-server, konfiguracja sprowadza się dodania następującej linii w pliku /etc/exports:

/srv/nfs/raspberry    192.168.3.0/255.255.255.0(rw,sync,no_subtree_check,no_root_squash,insecure)

Ten wpis udostępnia zawartość katalogu /srv/nfs/raspberry w sieci lokalnej. Nie jest to zbyt bezpieczne, ale jak wspominałem to konfiguracja tylko do programowania.

Teraz do przygotowanego katalogu wystarczy rozpakować obraz systemu. Dla urozmaicenia przykładu używam innego obrazu niż poprzednio, przygotowałem go poleceniem bitbake rpi-test-image. Do rozpakowania archiwum używam polecenia:

sudo tar -apxf tmp/deploy/images/raspberrypi3/rpi-test-image-raspberrypi3.tar.bz2 -C /srv/nfs/raspberry/

Jest ono wykonywane jako root (sudo) ponieważ pliki muszą mieć zachowane odpowiednie atrybuty, a do tego niezbędne są wyższe uprawnienia.

 

 

[Elvis]

Teraz wystarczy zmodyfikować parametry przekazywane do jądra linuksa:

setenv bootargs "8250.nr_uarts=1 cma=256M bcm2708_fb.fbwidth=800 bcm2708_fb.fbheight=480 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 dwc_otg.lpm_enable=0 console=ttyS0,115200 root=/dev/nfs ip=dhcp"

To polecenie sprawia, że główny system plików zamiast z karty SD (root=/dev/mmcblk0p2) będzie pobierany z sieci (root=/dev/nfs).

Taka konfiguracja ma co najmniej dwa zastosowania. Po pierwsze jest bardzo wygodna podczas programowania, albo konfiguracji naszej dystrybucji. Wszelkie zmiany wymagają co najwyżej restartu malinki, ale karty SD nie trzeba więcej wyjmować z gniazda, ani modyfikować. To ogromne ułatwienie dla programisty.

Można również taką konfigurację wykorzystać jeśli mamy serwer plików, a chcemy uniknąć zmian na kartach SD - dzięki temu wszystkie malinki w sieci mogą używać tego samego obrazu systemu właściwie automatycznie. Co więcej karty SD się praktycznie nie zużywają - są używane tylko do załadowania oprogramowania dla procesora graficzego oraz wczytania bootloadera.

Ja najczęściej używam takiej konfiguracji programując. Mam wtedy dostęp do przestrzeni dysku stacji roboczej:

Co więcej wszystkie pliki są niejako automatycznie backup-owane, a zmiany nie wymagają wyjmowania karty SD z gniazda (co u mnie już się skończyło pierwszymi błędami...).

Natomiast ostateczna wersja, może być zapisana na karcie SD. Po przetestowaniu i modyfikacjach, najlepiej w trybie tylko-do-odczytu - jak najbardziej można użyć karty SD jako nośnika.

Edytowano Sierpień 14, 2018 przez Elvis

[zook]

Dnia 13.08.2018 o 08:53, Elvis napisał:

Początkowy program jest zapisany w jego pamięci ROM - tutaj pojawia się pierwsza różnica między światem mikorkontrolerów i mikroprocesorów - ROM zamiast flash, to wbrew pozorom istotna zmiana. Jednak zasada jest identyczna - w ROM mamy bootloader, który wczytuje program.

Trochę nekromancji.

Nie mogę się z tym zgodzić mikrokontrolery powszechnie mają w swoim rom-ie (nieistotne jest to czy jest to rom faktyczny czy wydzielona sekcja flash) różnica jest taka że w toku normalnego wykonywania kodu ten bootloader jest nieaktywny.