Het vrij bescheiden Buildroot-topic

[Demo]

Omdat ik zelf de afgelopen tijd enthousiast bezig ben met Buildroot en ik me haast niet kan voorstellen dat ik de enige ben, leek het me een goed idee om er een eigen topic aan te wijden. Omdat het bij lange na niet de aantallen zal halen van de grote desktop-distro's (en je uiteindelijk ook meestal een full blown distro gebruikt om Buildroot te bouwen) heb ik niet de ambitie om dit een 'groot topic' te noemen.
Voor wie het niet weet en toch dit topic bezoekt: Buildroot is een verzameling scripts om een embedded Linux-systeem mee te bouwen op basis van µClibc en Busybox. Het is geschikt voor zeer uiteenlopende architecturen, biedt ondersteuning voor enkele honderden pakketten (uiteraard wel geselecteerd op bruikbaarheid in een embedded systeem) en genereert bestandssystemen in diverse formaten.
Laat hier weten wat je doet of gedaan hebt met Buildroot (en waarop) of gooi vragen en frustraties er neer.

[Demo]

Omdat de topicstarter volgens goed gebruik begint: ik had het idee om een mediaspeler te bouwen voor in huis, met de eis dat ik in meerdere ruimtes tegelijk kon afspelen. Als hardware heb ik een aantal afgeschreven thinclients liggen (HP T5700, 256 MB en een 800 MHz Crusoe x86 cpu) en in eerste instantie ben ik begonnen met Debian daar op te installeren icm Music Player Daemon, werkte wel aardig maar kon niet synchroon spelen. Pulseaudio leek geschikt om over het netwerk geluid te versturen, maar neemt veel te veel dependencies mee en werkt alsnog niet perfect.
Toen maar begonnen met Buildroot, lekker klein en erg leerzaam, maar nog geen idee hoe ik dan dat geluid zou moeten transporteren. Ik had Pulse kunnen compilen met minimale dependencies, maar kwam op een veel simpeler, doch uiterst doeltreffend idee: netcat. Uiteindelijk ben ik uitgekomen op socat, omdat die ook multicasting ondersteunt.
Inmiddels heb ik de basis van mijn systeem draaiend, een kernel van 1,5 MB die alleen de hardware van mijn thinclients ondersteunt icm een initrd die in BZIP2 slechts 910 kB weegt. Dit start op via PXE-boot, mijn server draait Music Player Daemon met een pipe-output die de digitale audio uncompressed het netwerk op slingert (de bandbreedte is op gigabit toch te verwaarlozen) en mijn thinclients luisteren om hetzelfde multicast-adres en pipen de audio vervolgens naar aplay - een kind kan de was doen Het enige wat nog ontbreekt is een user interface, hoe ik dat ga oplossen moet ik nog even uitvogelen maar er zwerft hier nog een Arduino en een 240x128 pixel LCD rond

[DeadLock]

Leuk dat er een buildroot topic is!

Ik zit er al even naar te kijken, maar door gebrek aan hardware en goede toepassing is het er nog niet van gekomen. Sinds kort heb ik een raspberry pi en het lijkt me zeer leuk (en leerzaam) om hier met buildroot een systeem mee te bouwen.

Een van de dingen waar ik de rpi graag voor zou willen gebruiken is als mpd servertje (met een usb dac om het aan de versterker te hangen). Over de user interface twijfel ik ook nog wat, er valt vast wel iets te verzinnen om mpd aan te sturen zonder dat ik mijn desktop moet aanzetten .

Daarbuiten wil ik kijken wat er mogelijk is van extra services te samen met het afspelen van flac/mp3, het zou mooi zijn moest ik de huidige server kunnen 'vervangen' door de pi. Deze dient vooral voor nfs storage delen (maar de dataset die ik vaak gebruik kan de pi ook delen over nfs), wat screen sessies, webservertje en de sab/couchpotato/sickbeard combo. Idealiter zou ik dit allemaal naar de pi verhuizen en dan af en toe eens met wake-on-lan de server aanzetten om data te syncen. Ik vrees een beetje dat dat teveel hooi is op de vork van de arm cpu.

Het relevante deel voor buildroot is dat rpi een eigen kernel repo heeft op github, maar het is me nog niet geheel duidelijk in welke mate het noodzakelijk is om deze te gebruiken (patches?). En hoe ik deze rpi git eventueel kan gebruiken tesamen met buildroot. Verder ben ik al enkele jaren linux gebruiker, maar is iets als buildroot toch wel een grote stap in het diepe . Zeker in combinatie met een geheel andere architectuur (arm) en de pi. Dit topic geeft me toch wel net dat duwtje in de rug om me erin te verdiepen!

[H!GHGuY]

Op het werk gebruiken we een OpenEmbedded-based distro. Hoge leercurve, foutgevoelig (imo), niet zo onderhoudbaar maar wel flexibel. Ik heb wel al positieve dingen over buildroot gehoord, maar er helaas nog niet mee gewerkt.

@DeadLock: Reken er maar op dat die patches voor de rpi binnen de kortste keren in de mainline kernel zitten.
Eventueel kun je met wat git magic een diff trekken van de mainline kernel en de rpi kernel.

[Ertepeller]

Demoniac schreef op zaterdag 19 mei 2012 @ 23:21:
een initrd die in BZIP2 slechts 910 kB weegt.

Waarom bzip2? Je kan beter kiezen voor:
- xz: comprimeert beter + decomprimeert een stuk sneller
- gzip: comprimeert minder goed, maar decomprimeert véél sneller
- lzop: comprimeert nog minder dan gzip, maar decompressie is bliksemsnel

bzip2 is het slechtst denkbare compromis eigenlijk: decompressietijd is het slechtst, terwijl ie niet eens het best comprimeert. Ga je voor een zo kleine mogelijke initrd (en kernel), kies dan voor xz, ga je voor snel opstarten, kies dan gzip of lzop. Maar never nooit voor bzip2.

Op processortjes als de Crusoe (en helemaal op ARM) moet je hier wel degelijk rekening mee gaan houden, omdat het booten tussen de snelste en langzaamste combinatie seconden kan schelen. Is toch mooi meegenomen lijkt me

Mijn initrd (voor een Debian Sid machientje) heb ik zelfs nog kleiner kunnen krijgen: 700k (xz, bzip2 maakt er 800k van). Zit alleen een busybox (static) + initscriptje in.

Wat vergelijkende cijfertjes qua groottes en decompressietijden:

code:

live@sid:~/initrd $ ls -l | sort -rk 5
-rw-r--r-- 1 live live 1690112 May 20 10:57 initrd
-rw-r--r-- 1 live live 1135384 May 20 10:58 initrd.lzop
-rw-r--r-- 1 live live  847785 May 20 10:58 initrd.gz
-rw-r--r-- 1 live live  817782 May 20 10:57 initrd.bz2
-rw-r--r-- 1 live live  711816 May 20 10:57 initrd.xz

live@sid:~/initrd $ time lzop -dc initrd.lzop >ird
real  0m0.014s
user  0m0.009s
sys   0m0.005s

live@sid:~/initrd $ time gzip -dc initrd.gz >ird
real  0m0.035s
user  0m0.027s
sys   0m0.006s

live@sid:~/initrd $ time bzip2 -dc initrd.bz2 >ird
real  0m0.172s
user  0m0.168s
sys   0m0.004s

live@sid:~/initrd $ time xz -dc initrd.xz >ird
real  0m0.113s
user  0m0.107s
sys   0m0.006s

Bendenk wel dat dit op een "gewone" PC (Q6600 Core2 quad) is gedaan. De tijden voor een Crusoe of ARM zullen een stuk hoger zijn (en voor een kernel helemaal, omdat ie zoveel groter is).
Het gaat alleen even om de verhoudingen.

[Demo]

Ertepeller schreef op zondag 20 mei 2012 @ 11:26:
[...]

Waarom bzip2? Je kan beter kiezen voor:
- xz: comprimeert beter + decomprimeert een stuk sneller
- gzip: comprimeert minder goed, maar decomprimeert véél sneller
- lzop: comprimeert nog minder dan gzip, maar decompressie is bliksemsnel

bzip2 is het slechtst denkbare compromis eigenlijk: decompressietijd is het slechtst, terwijl ie niet eens het best comprimeert. Ga je voor een zo kleine mogelijke initrd (en kernel), kies dan voor xz, ga je voor snel opstarten, kies dan gzip of lzop. Maar never nooit voor bzip2.

Op processortjes als de Crusoe (en helemaal op ARM) moet je hier wel degelijk rekening mee gaan houden, omdat het booten tussen de snelste en langzaamste combinatie seconden kan schelen. Is toch mooi meegenomen lijkt me

Mijn initrd (voor een Debian Sid machientje) heb ik zelfs nog kleiner kunnen krijgen: 700k (xz, bzip2 maakt er 800k van). Zit alleen een busybox (static) + initscriptje in.

Wat vergelijkende cijfertjes qua groottes en decompressietijden:

code:

live@sid:~/initrd $ ls -l | sort -rk 5
-rw-r--r-- 1 live live 1690112 May 20 10:57 initrd
-rw-r--r-- 1 live live 1135384 May 20 10:58 initrd.lzop
-rw-r--r-- 1 live live  847785 May 20 10:58 initrd.gz
-rw-r--r-- 1 live live  817782 May 20 10:57 initrd.bz2
-rw-r--r-- 1 live live  711816 May 20 10:57 initrd.xz

live@sid:~/initrd $ time lzop -dc initrd.lzop >ird
real  0m0.014s
user  0m0.009s
sys   0m0.005s

live@sid:~/initrd $ time gzip -dc initrd.gz >ird
real  0m0.035s
user  0m0.027s
sys   0m0.006s

live@sid:~/initrd $ time bzip2 -dc initrd.bz2 >ird
real  0m0.172s
user  0m0.168s
sys   0m0.004s

live@sid:~/initrd $ time xz -dc initrd.xz >ird
real  0m0.113s
user  0m0.107s
sys   0m0.006s

Bendenk wel dat dit op een "gewone" PC (Q6600 Core2 quad) is gedaan. De tijden voor een Crusoe of ARM zullen een stuk hoger zijn (en voor een kernel helemaal, omdat ie zoveel groter is).
Het gaat alleen even om de verhoudingen.

Dank voor de tip, ik ben/was niet bekend met XZ, heb gisteravond mijn kernel opnieuw gecompileerd met XZ support, het wordt inderdaad nog iets kleiner en boot nu weer iets sneller Misschien ga ik ook wel voor GZIP, uiteindelijk maakt het op een 100 Mb netwerk ook niet echt uit of je er 800kB of 900kB overheen trekt
Op dit moment zit ik met een rare bug, ik heb de output/target map weggegooid omdat aanpassingen die ik deed in fs/skeleton niet werden overgenomen in mijn image. Nu zijn na een make de scripts allemaal netjes op hun plek gezet, maar worden de losse packages die ik geselecteerd heb (socat en ethtool) weer niet naar de target gekopieerd?! Nouja, het houdt me van de straat zullen we maar denken Vanavond eens een hele nieuwe build proberen, ben alleen altijd huiverig om mijn configs te verliezen/overschrijven.

[Demo]

Zo, anderhalf jaar later, ik had niet verwacht dat dit topic hard zou gaan lopen maar dit is wel heel stil..
Ben een eind met mijn project gekomen, audio multicasten over een LAN werkt, maar ik gebruik eigenlijk nooit multiroom audio (met 2 personen in een driekamerappartement )
Al met al ben ik een paar weken terug helemaal opnieuw begonnen, met Buildroot 2013.08.1 als basis, dit keer met het plan om MPD in de thinclient op te nemen. Gisteravond nog een uurtje bezig geweest om bijzaken als ACPI (voor netjes afsluiten dmv powerbutton) en NTP aan de praat te krijgen. Mooi dat ik de eerste keer maanden bezig ben geweest en nu in een paar avonden en een regenachtige zondag het ding opnieuw opgebouwd heb. (oké, de scripts heb ik grotendeels kunnen kopiëren, maar toch)
Volgende uitdaging: een projectje met een grafische interface, eens kijken hoe klein ik dat kan krijgen

[ Voor 6% gewijzigd door Demo op 22-11-2013 14:30 ]