Wszystko
Najnowsze
Archiwum
Cześć,
Hobbystycznie/edukacyjnie chciałbym stworzyć sobie customowy obraz #yocto pewnie pod #raspberrypi. Chciałbym poznać zasadę działania character devices, modułów kernelowych itd. Pierwszym celem jest doprowadzenie do pojawienia się drivera pod /dev, który przy odczycie zwracałby cokolwiek. W dalszej kolejności napisanie jakiegoś drivera pod ADC, który zwracałby sampla, gdzie pewnie wchodzi już iio, interfejsy fizyczne, device tree i tym podobne. Do tej pory znalazłem kilka ciekawych źródeł jak:
The
Hobbystycznie/edukacyjnie chciałbym stworzyć sobie customowy obraz #yocto pewnie pod #raspberrypi. Chciałbym poznać zasadę działania character devices, modułów kernelowych itd. Pierwszym celem jest doprowadzenie do pojawienia się drivera pod /dev, który przy odczycie zwracałby cokolwiek. W dalszej kolejności napisanie jakiegoś drivera pod ADC, który zwracałby sampla, gdzie pewnie wchodzi już iio, interfejsy fizyczne, device tree i tym podobne. Do tej pory znalazłem kilka ciekawych źródeł jak:
The
Hej chciałbym aby każda maszyna zdefiniowana w mojej warstwie miała zainstalowane następujące pliki:
- /etc/hwname - zdefiniowany w pliku maszyny lub po prostu wykorzystałbym wartość ze zmiennej MACHINE
- /etc/hwserial - tutaj pasowałoby mi zrobić jakąś nakładkę, która w zależności od maszyny pobierałaby te dane dla rpi to np. /sys/firmware/device tree/base/serial-number/
- /etc/hwrevision - póki co zahardcodowane w pliku maszyny (machinename.conf)
Czy powinienem sobie zrobić nowy recipe np. recipe-board i w board.bb
- /etc/hwname - zdefiniowany w pliku maszyny lub po prostu wykorzystałbym wartość ze zmiennej MACHINE
- /etc/hwserial - tutaj pasowałoby mi zrobić jakąś nakładkę, która w zależności od maszyny pobierałaby te dane dla rpi to np. /sys/firmware/device tree/base/serial-number/
- /etc/hwrevision - póki co zahardcodowane w pliku maszyny (machinename.conf)
Czy powinienem sobie zrobić nowy recipe np. recipe-board i w board.bb
Kurde mam mały problem z Yocto, robię update do kirkstone i mam problem z kompilacją jednej apki.
Mianowicie, jednak z apek (budowana przez CMake) którą dodaję do obrazu, podczas kompilowania korzytsa z czegoś co się nazywa ExternalProjectAdd. W skrócie dodaję tym zewnętrzny target, np. z githuba. Aby więc móc go wykorzystać trzeba pobrać źródła. Odbywa się to poprzez git clone. I tutaj pojawia się problem, gdyż jak próbuję zbudować obraz w Yocto,
Mianowicie, jednak z apek (budowana przez CMake) którą dodaję do obrazu, podczas kompilowania korzytsa z czegoś co się nazywa ExternalProjectAdd. W skrócie dodaję tym zewnętrzny target, np. z githuba. Aby więc móc go wykorzystać trzeba pobrać źródła. Odbywa się to poprzez git clone. I tutaj pojawia się problem, gdyż jak próbuję zbudować obraz w Yocto,
@Mr_Przyjemny: Niestety nic to nie zmieniło.
@Mr_Przyjemny: Mirku ogarnięte. Dałeś mi dobry trop. Zasugerowałem się tym https://zenn.dev/nbo/scraps/d485855bbf2d9b
i dodalem do recipe
doconfigure[network] = "1"
docompile[network] = "1"
i poszło :) dzięki :) Btw ostatnio podpowiadałes mi też odnośnie swupdate, też się udało ogarnąc, trzeba było zamemu wrzucić wszystko do IMAGE_INSTALL. Dzięki! :)
i dodalem do recipe
doconfigure[network] = "1"
docompile[network] = "1"
i poszło :) dzięki :) Btw ostatnio podpowiadałes mi też odnośnie swupdate, też się udało ogarnąc, trzeba było zamemu wrzucić wszystko do IMAGE_INSTALL. Dzięki! :)
@pepepanpatryk: @Mr_Przyjemny: fwenv.config jest dodawany właśnie przez libubootenv a nie przez warstwe z swupdate.
@chodzacy_internet: tak już ogarnąłem
Cześć mam trochę pytań odnośnie Yocto. Coś tam już sobie jakiś czas temu pokonfigurowałem, wszystko działa tak jak chcę, ale teraz chciałbym popytać o jakieś dobre praktyki w Yocto. W pytanich głównie przewiną się rzeczy związane z tym gdzie co należy dodać. Idealnie wszystkie opcje konfiguracyjne typu IMAGEINSTALL chciałbym wywalić z local.conf i wrzucić w miejsca bardziej odpowiednie.
1) Mam kernel driver, który służy do kontroli sprzętu podpietego do boarda - umieściłem
1) Mam kernel driver, który służy do kontroli sprzętu podpietego do boarda - umieściłem
@pepepanpatryk: Witaj mireczku. Siedzę już trochę w Yocto. Odpowiem na Twoje pytania pisząc jak ja robię i dlaczego tak - co nie oznacza że jestem wyrocznią.
Zrobiłem i udostępniłem swoją podstawową warstwę dla płytek SOMLabs i na jej podstawie będę pisał
https://github.com/QB4-dev/meta-somlabs-bsp
Zrobiłem i udostępniłem swoją podstawową warstwę dla płytek SOMLabs i na jej podstawie będę pisał
https://github.com/QB4-dev/meta-somlabs-bsp
1) Mam kernel driver, który służy do kontroli sprzętu podpietego do boarda - umieściłem go w meta-custom-bsp/recipes-kernel/custom-module. Czy to jest
@QBA__: Dzięki mireczku, powiem szczerze,że po cichu liczyłem na Twoją odpowiedź bo już kiedyś mi pomagałeś ( ͡° ͜ʖ ͡°) Dzieki za wszystkie odpowiedzi, póki co nie mam więcej pytań, pojawią się jak zacznę wdrażać to o co tutaj zapytałem :)
@Mr_Przyjemny: szukam dobrego kursu/książki gdzie mógłbym ogólnie poczytać i zobaczyć jakieś dobre praktyki. Ja od dłuższego czasu pracuję przy yocto/openemeeded itd. ale przeważnie jakieś drobne zmiany. A system jest kiepsko u nas napisany.
Komentarz usunięty przez autora
Taka ciekawostka.
Kernel Linuxa ma taką klasę jak led-trigger - czyli źródło zdarzeń do migania ledami. Jednym z nich jest "heartbeat" - podpięcie go do diody powoduje miganie w takt bicia serca.
Ale to nie koniec. Prędkość tego migania jest uzależniona od obciążenia systemu w ciągu ostatniej minuty(load_avg).
Mówiąc prościej:
Im bardziej procesor d------y zadaniami tym szybciej bije "serce" naszej płytki - małe, proste i fajne (
Kernel Linuxa ma taką klasę jak led-trigger - czyli źródło zdarzeń do migania ledami. Jednym z nich jest "heartbeat" - podpięcie go do diody powoduje miganie w takt bicia serca.
Ale to nie koniec. Prędkość tego migania jest uzależniona od obciążenia systemu w ciągu ostatniej minuty(load_avg).
Mówiąc prościej:
Im bardziej procesor d------y zadaniami tym szybciej bije "serce" naszej płytki - małe, proste i fajne (
@QBA__: W linuksie kernela i narzędziach GNU to w ogóle kryje się dużo fajnych rzeczy gdzie widać, że pisali to ludzie dla innych ludzi a korporacje z kijem w dupie xD
@Kryspin013: yup, polecam jeszcze inna ciekawostke, usb-ip
Mirki eksperty od #linux #embedded #iot
Ma ktoś doświadczenie z Bulidroot i Yocto?
Poczytałem to co poniżej i nasuwają mi się takie spostrzeżenia:
- Yocto - bardziej skomplikowane, pozwala na stworzenie własnej dystrybucji z managerem paczek, widzę że dostępne są .deb, .rpm, .ipk czyli coś jak w OpenWRT, możliwość częściowych aktualizacji
Ma ktoś doświadczenie z Bulidroot i Yocto?
Poczytałem to co poniżej i nasuwają mi się takie spostrzeżenia:
- Yocto - bardziej skomplikowane, pozwala na stworzenie własnej dystrybucji z managerem paczek, widzę że dostępne są .deb, .rpm, .ipk czyli coś jak w OpenWRT, możliwość częściowych aktualizacji
Co lepsiejsze?
- Bulidroot 16.7% (3)
- Yocto 33.3% (6)
- to zależy 16.7% (3)
- Install Gentoo :) 33.3% (6)
@Mr_Przyjemny: @Oo-oO: Ooo treściwe odpowiedzi się pojawiły - jednak to prawda że to portal ekspercki ( ͡° ͜ʖ ͡°). Dziękuję i obserwuję
U mnie ma to być system na te płytki od SOMLabsa:
https://wiki.somlabs.com/index.php?title=VisionSOM-6ULL
Mają gotowe obrazy Yocto z własną meta-warstwą(chyba tak to się zwie) - minimalny z konsolą i większy z QT. Jutro w pracbazie to sobie sam pobuduję, dziś budowałem tego ich debiana, ale to normalne
U mnie ma to być system na te płytki od SOMLabsa:
https://wiki.somlabs.com/index.php?title=VisionSOM-6ULL
Mają gotowe obrazy Yocto z własną meta-warstwą(chyba tak to się zwie) - minimalny z konsolą i większy z QT. Jutro w pracbazie to sobie sam pobuduję, dziś budowałem tego ich debiana, ale to normalne
@Mr_Przyjemny: świetne community, nie tak ociężale jak yocto, proste budowanie gotowych obrazów z wykorzystaniem genimage, prosty w portowaniu i dodawaniu nowych paczek, wsparcie dla ext br2 (chociaz yocto też zapewne to ma). Jedynie czego brakuje względem yocto to ichniejszego ccache, ten buildrootowy niestety nie jest tak dobry jak yoctowy i współdzielonej kompilacji
Swoją drogą "kto ma wiedzieć ten wie" ale może są ludzie którzy nie wiedzą a chcieliby się dowiedzieć a może nawet zarejestrować:
2026.01.31-2026.02.01 https://fosdem.org/2026/ (darmowy)
2026.02.02 https://pretalx.com/openembedded-workshop-2026-2025