De bewogen geschiedenis van coreboot

Inleiding

In dit artikel gaan we in op coreboot, een opensourcefirmwareproject dat gebruikt kan worden in plaats van bios of UEFI. We spreken met Ron Minnich, die het coreboot-project in 1999 startte. Hij vertelt onder meer over de interessante en bewogen geschiedenis van coreboot, dat door de jaren heen op flinke weerstand van chipsetmakers stuitte en bijna sneuvelde voordat het in 2011 werd 'gered' door Google en zijn ChromeOS-apparaten.

Het aanzetten van je computer is best simpel: je drukt op de aan-uitknop en de rest gaat vanzelf. Achter de schermen komt daar echter aanzienlijk meer bij kijken. Wanneer de pc wordt opgestart, is deze allesbehalve functioneel. De verschillende componenten van je systeem zijn in het begin van het opstartproces niet in staat om taken uit te voeren of met elkaar te communiceren. Firmware moet dat zooitje ongeregeld temmen tot een werkend systeem.

Bekende firmwarevoorbeelden zijn bios en UEFI, waar je als tweaker misschien wel eens in hebt rondgesnuffeld om je systeem te overklokken of XMP in te schakelen. Bij het opstarten initialiseren de UEFI en bios je componenten, zodat ze aan de slag kunnen, en laden vervolgens een besturingssysteem, zodat je je pc daadwerkelijk kunt gebruiken.

De manier waarop dat gebeurt, is vrij vaag. UEFI- en bios-firmwares zijn namelijk closed source, waardoor het onmogelijk is om te kijken wat er exact onder de motorkap gebeurt wanneer je pc wordt opgestart. De meeste gebruikers zullen hoe dan ook geen behoefte hebben om hun firmwarecode te bekijken, maar het heeft wel gevolgen voor de security: je moet er blind op vertrouwen dat de code die je draait veilig is, zonder dat dat gecontroleerd kan worden door derde partijen. Mede daarom zijn er in de loop der jaren verschillende opensourcefirmwareprojecten opgestart.

Een goed voorbeeld daarvan is coreboot, een platform dat sinds 1999 bestaat en is bedoeld als vervanger voor gesloten firmware. Coreboot is een opensourceproject en kan daardoor grotendeels door derde partijen gecontroleerd worden op achterdeurtjes en beveiligingslekken. Volgens de ontwikkelaars moet het ook andere voordelen met zich meebrengen. Net als bios en UEFI initialiseert coreboot de hardware nadat je de aan-uitknop van een systeem heb ingedrukt, waarna een besturingssysteem ingeladen kan worden. Coreboot voert echter zo min mogelijk stappen uit en geeft de controle daarna door aan het besturingssysteem, wat de opstartsnelheden flink zou verkorten.

Misschien heb je nog nooit van coreboot gehoord, maar het zit in een hoop apparaten. Coreboot draait niet op ieder moederbord of platform, maar is onder meer te vinden in alle Chromebooks en andere ChromeOS-apparaten en wordt daarmee vrij grootschalig ingezet. Ook bepaalde laptops, veelal met Linux, en embedded apparaten, zoals bepaalde Netgate-routers van pfSense, maken gebruik van coreboot.

Het verhaal achter coreboot is bewogen en kent veel ups en downs. Het project deed het goed tussen 1999 en 2004, maar ondervond ook pushback vanuit de x86-wereld en door chipsetmakers. Coreboot sneuvelde door de jaren heen meermaals bijna, maar werd uiteindelijk nieuw leven ingeblazen toen Google besloot het te gebruiken voor zijn Chromebooks en andere ChromeOS-apparaten. Tweakers sprak met de man achter coreboot, Ron Minnich, over de geschiedenis van dit firmwareproject.

Bannerfoto: fotograzia / Flavio Coelho / Getty Images

<br>

De opstartsnelheid van een coreboot-systeem naast een UEFI-pc

Het begin van coreboot: supercomputers met bios-perikelen

Het begon allemaal in de Amerikaanse staat New Mexico. Een team van het Los Alamos National Lab begon in 1999 aan coreboot, dat toen nog bekendstond als LinuxBIOS. Het doel was het neerzetten van een bios-vervanger, door Linux als de firmware van een hpc-systeem te gebruiken. De man die het project in 1999 startte, was Ron Minnich.

De roots van coreboot liggen in een supercomputer. "We hadden destijds in het Los Alamos National Lab een hpc-cluster met 128 nodes, wat in die tijd best groot was", vertelt Minnich aan Tweakers. "En de bios was altijd een groot probleem, mede omdat het was ontworpen om op een desktop te draaien en niet in een rack. Het was gewoon pijnlijk om mee te werken. Je had een toetsenbord, een 'video' en soms een muis nodig. Het vereiste veel interactie en het liep zonder goede reden vast. Het opstarten duurde ook nog eens minutenlang."

'De bios was gewoon pijnlijk om mee te werken'Als je de firmware wilde updaten, moest je bovendien met een floppydisk langs de 128 machines, zo vertelt Minnich. En als het flashen van de bios misging, dan moest je de machine uit het serverrack halen, deze openmaken, een jumper bewegen en een floppy met de recoverybios inladen. Die recoverybios werkte met piepcommando's, wat niet praktisch was voor supercomputers.

"Stel je dit voor: je bent in een lawaaierige machinekamer met een floppydisk. Je zet de jumper van de node opzij en stopt de schijf erin. Dan moet je proberen te luisteren naar enkele piepjes die je vertellen dat het recoveryproces klaar is. Onmogelijk."

Linux als de firmware

De bios was volgens Minnich dan ook een van de grootste onderhoudsproblemen die ze hadden en daarom ontstond het idee voor een alternatief: Linux gebruiken als de firmware. "Wat we ons realiseerden, was dat supercomputers in veel opzichten beperkter zijn dan een desktop. Ze hebben een vrij simpele configuratie en een vaste functie. Tegelijkertijd waren de flashchips voor de bios flink gegroeid, van 8KiB naar 256KiB. Toen was dat groot genoeg voor een kernel. Bovendien hadden we een PCI-bus met een self-describing hardwarestructuur, wat betekende dat je de bus volledig in software kon configureren. Alles wat de bios deed, hadden we daarom eigenlijk niet meer nodig. Kortom, de bios was buggy, langzaam, een securityprobleem en het deed niets wat we nodig hadden. Dus het leek erop dat we de bios konden weggooien en gewoon Linux konden gebruiken voor de firmware."

Het LinuxBIOS-logo

Zo ontstond coreboot, dat toen nog LinuxBIOS heette. Het doel was dus het oplossen van de bios-nadelen, en dat lukte. De opstarttijd werd teruggedrongen van minuten naar seconden. Er draaide een minimale hoeveelheid code, wat beter is vanuit een securityoogpunt. Ook het updaten ging makkelijker: via een enkel commando kon je volgens Minnich binnen 30 seconden alle nodes van een hpc-systeem flashen, iets wat eerder een dagenlang proces vormde.

Het eerdergenoemde herstelproces werd bovendien flink versimpeld. LinuxBIOS bestond uit een normale image en een fallback. "Nadat je je eerste LinuxBIOS-image voor een systeem had geschreven, hoorde je alleen de normale image te updaten. Als dat misging, en het systeem na een paar keer opnieuw opstarten merkte dat het niet kon booten, dan viel het systeem automatisch terug op de fallback, waarvan je wist dat het werkte." Daarna kon je een nieuwe image flashen op de normal. Het recoveryproces met piepjes was dus verleden tijd.

Het ontwikkelwerk en de ontvangst

Het ontwikkelwerk verliep spoedig. Ongeveer zes maanden na het begin in 1999, was LinuxBIOS volgens Minnich al klaar voor gebruik. "Het ging verrassend snel. Ik begon in september 1999 met pushen en ergens in 2000 stapten we naar mijn herinnering over op LinuxBIOS. Ik weet dat er op de Extreme Linux-bijeenkomst in de lente van 2000 al een aantal vendors met LinuxBIOS-systemen kwamen opdagen."

'Tegen het einde van de jaren '90 werden bedrijven een stuk behulpzamer'In eerste instantie verwachtte het LinuxBIOS-team dat de interesse vanzelf zou komen. Niet geheel gek: in de begindagen van Linux vochten hardwarevendors tegen die kernel, maar dat sloeg later om en na vijf á zes jaar begonnen fabrikanten Linux juist te omarmen. "Om een voorbeeld te geven: ik probeerde ooit een ethernetdocument van Intel te krijgen, om een driver te schrijven. Ik kreeg vijf slecht gekopieerde pagina's met vrijwel geen bruikbare informatie. Maar tegen het einde van de jaren '90 werd Intel een stuk behulpzamer. Ik zag die verandering in bedrijven."

De insteek was dan ook om LinuxBIOS te maken en het vervolgens beschikbaar te stellen aan fabrikanten, die de ondersteuning zouden overnemen. Dat liep uiteindelijk anders. "Mijn gedachtegang was als volgt: we zetten Linux weliswaar door naar een andere usecase, maar we kunnen verwachten dat de vendors behulpzaam zijn", vertelt Minnich. "Immers, hetgeen dat de bedrijven al ondersteunen als kernel, kunnen ze nu ook als firmware gebruiken. Het leek me overduidelijk dat ze dat zouden willen doen, maar dat is nooit echt gebeurd. We eindigden in een situatie waar we dachten dat we het konden overdragen, maar uiteindelijk moesten we het het zelf blijven onderhouden."

'We dachten dat we het konden overdragen, maar uiteindelijk moesten we het zelf blijven onderhouden'Aan de andere kant werd LinuxBIOS op andere plekken juist goed ontvangen. LinuxBIOS werd eerst puur opgezet voor high-performance computing en daarmee supercomputers, maar volgens Minnich werd het project al snel buiten dat veld ingezet. "Het bleek dat veel bedrijven dit model wilden." IRobot, onder meer bekend van de Roomba-stofzuigers, pakte LinuxBIOS bijvoorbeeld in de eerste paar jaar op voor gebruik in een 'packbot': een robot die landmijnen vindt. "Een mijnenvinder die in seconden opstart is immers beter dan een mijnenvinder die in minuten opstart", voegt Minnich daaraan toe.

"Er was ook een bedrijf dat de Apache Military Modem II maakte, een modem voor helikopters. Ook die modem moet snel opstarten. En een vriend van me belde me ooit vanuit Zwitserland om te vertellen dat een digitale tv-set uit Turkije gebruikmaakte van LinuxBIOS, want ook je tv hoort natuurlijk snel op te starten." Ook Arista gebruikte LinuxBIOS lange tijd in zijn netwerkswitches.

Coreboot-supercomputer — 2003: Het Los Alamos National Lab neemt zijn 'Pink'-supercomputer in ontvangst van Linux Networx.
Deze cluster met 1024 nodes draaide LinuxBIOS en leverde maar liefst 10TFLops aan rekenkracht.
Bron: Ron Minnich, tijdens een OSFC-keynote

Van Linux naar 'payloads' en naamswijziging

Na een aantal jaar werd LinuxBIOS dus al ingezet in productieapparatuur om Linux als de firmware te gebruiken, maar al snel moest van Linux worden afgestapt. "De Linux-kernel bleef maar groeien. Vrij snel na het begin van LinuxBIOS moesten we daarom overstappen op flashgeheugenchips van een halve MB. Dat was oké. Maar later stapten fabrikanten over op fysiek kleinere flashchips van een kwart MB, uit kostenoverwegingen. Linux paste daar niet op. Dus dat was het einde van Linux als de bios."

'De Linux-kernel bleef maar groeien'Mensen stapten in plaats daarvan over op 'payloads', die door LinuxBIOS geladen konden worden. Die overstap op payloads gebeurde rond 2003 en volgde dus al vrij snel na het begin van LinuxBIOS. De payload kan van alles zijn. Denk aan bootloaders als Etherboot, GRUB en FILO, maar ook aan andere software, zoals SeaBIOS. Dergelijke payloads kunnen in het bootflashgeheugen van een moederbord geplaatst worden en gebruikt worden om een besturingssysteem te starten. LinuxBIOS initialiseert de hardware, waarna de payload de controle overneemt en het OS kon worden ingeladen. LinuxBIOS verdwijnt dan voor zover mogelijk uit het plaatje. "Het is sindsdien bijna continu zo geweest, met payloads."

Opvallend genoeg veranderden de opslaglimieten later met een nieuw soort LPC-flashchips. Die chips hadden 16MB opslagruimte, meer dan groot genoeg voor Linux. Toch bleven de payloads, en keerde Linux als de firmware niet echt meer terug. "Dus er gebeurde eigenlijk iets grappigs: we verwijderden Linux vanwege de limiet. Toen ging de limiet weg, maar keerde Linux niet meer terug."

De overstap naar coreboot

In de jaren daarop hield het team gewoon de naam LinuxBIOS, hoewel Linux niet langer werd gebruikt. Daar kwam in 2006 verandering in. "Bij de Server Computing-beurs in 2006 kwamen Microsoft en Sun allebei naar onze booth. Beide zeiden ze dat ze LinuxBIOS zouden gebruiken als de term Linux er niet in zat. En bovendien was het eigenlijk geen LinuxBIOS meer. Linux was uit beeld. Het was misleidend. Ook klaagden veel mensen bij ons dat het geen bios was. Ons hele model is: 'we starten, en dan gaan we weg'. Wat het ook is, we booten het, en dan stappen we aan de kant. Bios blijft juist altijd aanwezig, net als UEFI."

Het coreboot-logo

Tijd voor een nieuwe naam dus. Om die te verzinnen, sprak het LinuxBIOS-team af bij een restaurant in Livermore om te brainstormen. "We tekenden op een placemat allemaal plaatjes met manieren om systemen op te starten. In het midden stond een cirkel. We zeiden: die cirkel vormt de kern van het booten. Snap je? Coreboot." Dat is de redenering achter de naam die tegenwoordig wordt gebruikt.

"Achteraf gezien weet ik niet of het veranderen van de naam een goede beslissing was", voegt Minnich daar aan toe. "Het is misschien niet altijd een goed idee om een bekende merknaam op te geven, zelfs als die niet helemaal logisch is." Op Google Trends is bijvoorbeeld te zien dat de term 'coreboot' nooit zo populair is geworden als 'LinuxBIOS'. "Maar het is oké. We hebben de nieuwe naam en het logo is heel mooi."

Coreboot-interesse Google — 'Interesse' in LinuxBIOS (blauw) en coreboot (rood) op Google

Pushback door chipsetmakers en wederopstanding bij Google

Coreboot had enige tijd redelijk succes, maar rond 2005 liep dat terug. Coreboot ondersteunde in het begin meerdere computerarchitecturen: naast x86 kon de firmware ook overweg met de PowerPC- en DEC Alpha-instructiesets. Die laatste twee vielen later achter weg, waardoor de coreboot-firmware enkel nog geschikt was voor x86. Iot-apparaten stapten daarbij over op Arm en lieten coreboot vallen, waardoor de gebruiksgevallen al snel meer werden beperkt.

Weerstand vanuit de x86-wereld

Tegelijkertijd werden x86-chipsetmakers volgens Minnich steeds minder behulpzaam. "De informatie om een coreboot-port te doen, werd op het laatst eigenlijk gewoon niet meer beschikbaar gemaakt. Als je vroeger keek naar bepaalde sites, zoals de ontwikkelaarswebsite van Intel, dan waren dat hele technische websites. Nu zijn het meer marketingwebsites. De openbare datasheets daar kun je eigenlijk nergens meer voor gebruiken."

Zo begon het verlies aan gebruikers. "We hadden daarom een aantal hele grote LinuxBIOS-'klanten' die op die manier geforceerd werden om over te stappen op UEFI. Het was altijd een strijd, maar halverwege de jaren nul werd het echt erg. Dus terwijl Linux van de grond kwam, werd LinuxBIOS in feite om zeep geholpen", zegt Minnich. "Niet om een goede of technische reden. We waren heel goed in het beschikbaar stellen van kennis. In 1999 wist niemand hoe je dram moest initialiseren. Wij creëerden die kennis. Hetzelfde met het trainen van dram. We kwamen erachter dat de vendors het niet leuk vonden dat we die informatie naar buiten brachten. Het maakte ons een goede concurrent voor UEFI."

Dat verlies zette door en tegen 2010 stopten enkele coreboot-ontwikkelaars. Ook Minnich nam een stapje terug. "Coreboot werd amper nog gebruikt. Of nou ja, het werd nog wel gebruikt, maar niet op manieren waarover werd gepraat. Er waren bedrijven die het doorverkochten, wat letterlijk een schending van de GPL-licentie is, maar het was het niet waard om achter hen aan te gaan. In de ruimere zin werd coreboot veel meer gebruikt in 2004 dan in 2010. Het werd zo frustrerend dat we besloten om iets anders met ons leven te gaan doen."

Coreboot-commits — Het aantal coreboot-commits per jaar. Bron: Ron Minnich, tijdens een OSFC-keynote

Een wederopstanding bij Google

Dat een deel van het team stopte, was rond 2010, maar slechts een jaar later zou coreboot een soort tweede leven ingaan. Stefan Reinauer, een Duitse ontwikkelaar en projectlead bij coreboot, kwam in die tijd bij Google terecht. Dat bedrijf werkte toen actief aan de eerste Chromebooks, en het was met die apparaten dat coreboot in 2011 een soort wederopstanding zou ondergaan.

De eerste Chromebooks maakten gebruik van UEFI, maar dat was geen goede match. "UEFI is te flexibel. Chromebooks zijn niet erg configureerbaar. De disk zit vastgesoldeerd op het moederbord. Het geheugen tegenwoordig ook. Het staat allemaal zeer vast qua configuratie. UEFI is ontworpen om een enorme runtime te hebben, volledig configureerbaar. Dat is niet nodig voor een Chromebook."

Nu Reinauer bij Google zat, ontstond intern dan ook het idee om coreboot te gebruiken voor ChromeOS-apparaten. "Stefan Reinauer vertelde het verhaal als volgt. Hij werd bij Google op de gang aangesproken. 'Ben jij niet die coreboot-kerel?' Stefan antwoorde dat hij dat was, en de collega zegt: 'Nou, wat denk je ervan dat we coreboot doen op een Chromebook?' Wat volgde waren een zeer intense zes maanden, werkende aan een coreboot-port om te laten zien dat het kan werken op een Chromebook, zo vertelde Stefan me. En het eindresultaat was zo veel beter. Het was beter voor de prestaties, voor bugs, voor controleerbaarheid... Vanuit elke mogelijke hoek. Het was een makkelijke beslissing."

Later kwam ook Ron Minnich bij Google terecht, waar hij onderzocht of coreboot ook zou werken op Chromeboxen, mini-pc's met ChromeOS waar gebruikers een monitor en eigen invoerapparatuur op moeten aansluiten. "Dat kostte me twee weken. Het werd al snel duidelijk dat we ook voor de Chromebox geen UEFI wilden gebruiken. In deze zeer korte tijd stelden we dus vast dat we geen UEFI wilden, dat coreboot zou werken op een Chrome-whatever en dat we dat prettig vonden."

Het heden: ChromeOS, coreboot-ports, blobs en oreboot

Zo geschiedde. Met Google en ChromeOS stond coreboot in een klap weer op de kaart. Op de eerste paar Chromebooks na, maken alle ChromeOS-apparaten gebruik van coreboot. Dat is zo sinds 2012 en is sindsdien niet meer veranderd. Gaandeweg werd op andere fronten aan de weg getimmerd. Minnich besloot een jaar later dat coreboot ook van pas zou komen voor Chromebooks met Arm-chips, waarmee de firmware voor het eerst in jaren weer ondersteuning bood voor meerdere architecturen. Ron Minnich startte later bovendien LinuxBoot, wat tegenwoordig onderdeel is van The Linux Foundation. Hiermee kan Linux weer als firmware ingezet worden; in feite een soort terugkeer naar de roots van coreboot en LinuxBIOS.

Coreboot op andere apparaten en waarom ieder bord een eigen port nodig heeft

Coreboot is dan ook nog altijd draaiend, ook op andere platformen. De makkelijkste manier om aan een coreboot-systeem te komen, is met voorgebouwde apparaten, zoals laptops. Onder meer Linux-laptopmaker System76 biedt bepaalde modellen met eigen firmware op basis van coreboot aan. Ook andere bedrijven, waaronder StarLabs en Purism, bieden coreboot-laptops aan, die specifiek bedoeld zijn voor Linux. Qua oudere platformen ondersteunen bijvoorbeeld veel oude ThinkPads coreboot, zoals de X200- en T400-series.

Libre X230 — Een 'Libre' X230 met coreboot.
Bron: Minifree

De Nederlandse laptopmaker Nova Customs levert sinds kort ook bepaalde coreboot-laptops. Dat zijn laptops van oem Clevo, waarvoor het bedrijf coreboot-firmware heeft ontwikkeld in samenwerking met andere Europese bedrijven. Tot nu toe zijn dat modellen met elfdegeneratie-Intel Core-cpu's, maar later dit jaar moeten ook Alder Lake-modellen volgen. Een bekend voorbeeld voor andere gebruiksgevallen is routersoftwaremaker pfSense, die coreboot gebruikt in bepaalde Netgate-routers.

Soms wordt coreboot ook geport naar nieuwe consumentenhardware. Een voorbeeld daarvan is het MSI Pro Z690-A-moederbord voor Alder Lake-cpu's. Dat gebeurt echter niet regelmatig: coreboot vereist nog altijd een aparte build voor ieder moederbord en gelet op de geslotenheid van x86 is dat niet altijd even makkelijk.

System76 Lemur met Coreboot — System76 Lemur met coreboot

"Het hele doel van firmware is om een soort Potemkin-dorp te maken waarvan een OS zegt: 'O, ik weet hoe ik dit moet draaien! Dit is gewoon een pc'", legt Minnich uit. "Maar bij het opstarten is het helemaal nog geen pc. Onder de motorkap zit een enorme hoeveelheid variatie. Om een voorbeeld te geven: op bepaalde moederborden zit een gpio, die de dram inschakelt. En het lijkt erop dat niemand het er over eens is welke gpio gebruikt moet worden. Dus je kunt twee identieke borden van twee fabrikanten hebben, waarvan het enige verschil is welke gpio gebruikt wordt. Die hebben dan beide andere firmware-images nodig. Op bijvoorbeeld x86 heb je dus mooie uniformiteit, maar een deel van de uniformiteit moet gemaakt worden door de firmware. Dat is waarom ieder bord een eigen build nodig heeft."

Libreboot en blobs

In 2013 verscheen daarnaast Libreboot, een door de community onderhouden coreboot-fork voor oudere platformen die relatief makkelijk te installeren moet zijn en bovendien volledig vrij is van blobs, anders dan coreboot. Blobs zijn gesloten stukjes firmwarecode waarvan de broncode niet beschikbaar is. Die zijn bijvoorbeeld nodig om bepaalde delen van een systeem te doen werken. Een bekend voorbeeld daarvan is de Intel Management Engine. Die blobs zijn nodig om een modern x86-systeem op te kunnen starten. Tegelijkertijd zijn dit dus stukjes gesloten code in een opensourceproject, compleet met de eerdergenoemde bezwaren.

Coreboot bevat enkele van die blobs, maar volgens Minnich is dat onvermijdelijk op moderne platformen. "Het lastige is dat nieuwere processors niet functioneren zonder blobs, tot op het punt dat ze geheugen niet correct kunnen aansturen", zegt Minnich. "Je kunt blob-vrij zijn op een moderne cpu, maar dat zorgt voor silent data corruption. Dat is geen prijs die ik bereid ben te betalen. Volledig blob-vrij zijn, is dus een zeer lastig probleem. Om nog een voorbeeld te geven: er staan kleine spanningsregelaars op je moederbord, de vrm's. Die vrm's hebben firmware. Overal zit firmware. Een bord bouwen zonder gesloten firmware gaat dus veel verder dan alleen de firmware van de cpu. Om dat goed te krijgen, moet je helemaal tot de kern gaan en schoon beginnen. Dat kan niet met x86."

Oreboot: coreboot zonder C

In 2019 werd dan ook oreboot gestart, een officiële fork van coreboot die ook geen blobs bevat. Oreboot staat voor coreboot zonder C (de programmeertaal). "Ik was klaar met C. Er waren door de tijd heen een hoop pogingen gedaan om C te vervangen, en het leek erop dat Rust de taal zou zijn die het daadwerkelijk zou lukken."

Daarop werd coreboot geforkt en herschreven in Rust. Tegenwoordig wordt oreboot nog altijd onderhouden als een downstream fork van coreboot. "Er waren heel veel onderdelen van coreboot die uitstekend werken. De structuur van de directory, bijvoorbeeld. We forkten daarom coreboot, verwijderden alle C-code, lieten de directorystructuur hetzelfde en begonnen in Rust te schrijven."

Oreboot is momenteel vooral gericht op RISC-V, een opensource-instructiesetarchitectuur voor processors. "We overwogen om x86 naar oreboot te brengen, inclusief de benodigde blobs. Maar uiteindelijk hebben we dat allemaal verwijderd, omdat we niet meer met x86 wilden dealen. We hebben onze focus voor oreboot gevonden en dat is alles wat we volledig opensource kunnen doen. RISC-V in het bijzonder is daar erg geschikt voor."

Oreboot is dan ook geen coreboot-vervanger, maar eerder een losstaand project. "Het is niet mijn plan om oreboot en coreboot samen te voegen. Volgens mij is dat niemands plan. Op zich zou het wel kunnen. Er zitten al verschillende programmeertalen in coreboot. We hebben Assembly en C. En niemand weet dit, maar er zit ook een derde taal in coreboot: we hebben een 'dialect' van de Ada-programmeertaal, Spark. Die code is geschreven door een paar mensen in Duitsland en initialiseert de x86-framebuffers."

"Zou coreboot een vierde programmeertaal kunnen huisvesten? Makkelijk. Het punt is: coreboot heeft echt goed werk gedaan om met de benodigde blobs om te gaan en die te accommoderen. En bij oreboot doen we daar dus niet meer aan."

Tot slot

Zo blijkt dat een dergelijk klein stukje van je pc, de firmware, toch een behoorlijke geschiedenis kan hebben. Zo vertelt ook Ron Minnich: "Voor de gebruiker horen we niet uit te maken. Ons doel is om in hooguit een tiende van een seconde weg te zijn. Voordat je scherm oplicht, zijn we al verdwenen. Dus, voor bijna iedereen doen we er niet toe. Maar tegelijkertijd: geen firmware, geen computer. We zijn net zo belangrijk als de hardware, want zonder firmware heb je een brick. De kernel heeft het daarom makkelijk, want wij doen al het vuile werk. Als de processor wordt aangezet, functioneert die niet. En het is aan ons om ervoor te zorgen dat het werkt. Dus ik vind dat we erg belangrijk zijn. Het is een stuk zeer gecompliceerde code, maar niemand weet dat het bestaat."