Het Lab: Dusk OS

Henk van de Kamer

Twee maanden gelden beloofde ik een laatste aflevering over de Promax MI650C, maar daar zul je nog even op moeten wachten. Ik heb nu ruim een kilobyte aan machinetaal die de [MEM/0] functie duidelijk maakt. Daarin ook het aansturen van de 7-segments displays en het uitlezen van het toetsenbord. Dit is veel code voor het handmatig programmeren van een EEPROM en dat is absoluut de eerste stap voor het tot leven wekken van een ‘dode’ computer. Het zou beter zijn als we het kunnen terugbrengen tot minder dan de helft. Nu bevat de code vreemde constructies en ik zie absoluut mogelijkheden om een deel te schrappen. Of ik daarmee onder de 512 bytes kan komen, is een kwestie van uitvoeren en dat kost tijd...

Collapse OS

Zoals gezegd ben ik al jaren bezig met mijn dode-computerproject. In de praktijk is dat met enige regelmaat een zoekopdracht starten als een nieuwe gedachte bij mij opkomt. Tijdens zo’n zoektocht dwaal ik regelmatig af en kom ik uit bij ideeën van anderen die enigszins vergelijkbaar, maar toch een compleet andere insteek hebben.

Persoonlijk maak ik mij bijvoorbeeld zorgen over hoe afhankelijk onze maatschappij is geworden van computers. De kans dat een kleine kink onvoorspelbare gevolgen heeft, wordt steeds groter. Uiteraard ben ik niet de enige die hierover nadenkt en zo ontdekte ik anderhalf jaar geleden Collapse OS. Inderdaad een besturingssysteem voor het geval onze maatschappij als een kaartenhuis in elkaar stort.

Een paar maanden terug bezocht ik het project opnieuw en zag ik dat de maker heeft besloten om Collapse OS onder te brengen in Dusk OS. Als onze maatschappij terugvalt, zal er een overgangsperiode zijn. Nieuwe computers worden dan niet meer gemaakt, maar wat er reeds is, zal nog jaren lang bruikbaar zijn. Software is tegenwoordig bloatware ofwel veel te complex om te onderhouden als we de nieuwste machines niet meer kunnen maken. Wie niet terug wil naar mijn idee, zal een systeem op prijs stellen waarin oplossingen voor nog oudere systemen gemaakt kunnen worden. Op dat punt is Dusk OS één van de uitdagers met als grootste pluspunt dat het Collapse OS meebrengt om processoren als de Z80, 8086, 6809, 6502 en AVR iets zinnigs te laten doen.

Pine A64 LTS

Bijna alle nieuwe besturingssystemen beginnen op de i386-architectuur. Deze is zo uitgekauwd dat iedereen met kennis van programmeren iets simpels voor elkaar kan krijgen. Dit keer zag ik dat de maker ondertussen de ARM-architectuur heeft toegevoegd. Uiteraard op de eerste Raspberry Pi modellen, maar persoonlijk spreekt mij dat niet aan. De SOC – System On a Chip – die de Rasberry Pi gebruikt, start als eerste de videoprocessor en dat betekent een aantal blobs waarvan we de broncode niet hebben. Ja, iemand is bezig geweest om dat uit te zoeken, om vervolgens te stoppen omdat het een zooitje is.

Veel interessanter is de kandidaat in de titel van deze paragraaf. Deze heeft een Allwinner A64 die ook door de PinePhone gebruikt wordt. Helaas was deze SBC – Single Board Computer – alleen nog verkrijgbaar bij de makers. Omdat het om een klein Amerikaans bedrijf gaat, wordt de Nederlandse btw en mogelijke invoerrechten niet verrekend, waarmee we worden overgeleverd aan de cowboykoeriers die dat graag voor fikse administratiekosten alsnog namens u willen doen. Tel bij dat ‘voorrecht’ op dat het ook regelmatig weken bij de douane blijft liggen.

Nu bedacht ik dat de Allwinner A64 ongetwijfeld ook op andere bordjes aanwezig is. Daar kunnen naast de SOC – System On a Chip – andere componenten aanwezig zijn, maar ik schatte de kans groot dat dezelfde code met mogelijk wat kleine aanpassingen gewoon zou moeten werken. Na wat zoeken kwam ik terecht bij Olimex – een bedrijfje in Bulgarije, ofwel onderdeel van de EU en dus verplichte btw-afhandeling – en bestelde daar de A64-OLinuXino [https://www.olimex.com/Products/OLinuXino/A64/A64-OLinuXino/open-source-hardware].

A64-OLinuXino van Olimex

U-Boot SPL

Een SBC – Single Board Computer – heeft, tenzij deze een x86-processor heeft, geen BIOS. In plaats daarvan heeft de SOC een BROM – Boot ROM – die uitzoekt via welk ondersteunde media gestart kan worden. Anders dan het BIOS wordt alleen hardware geïnitialiseerd die voor deze stap nodig is. Dat is dus niet het geheugen omdat tijdens het maken van de SOC niet bekend is, welke varianten de makers van een SBC gaan kiezen.

Daarmee zitten we theoretisch in een spagaat. Zodra de BROM weet waar de code voor de volgende fase gestart kan worden, is er nog geen DRAM – Dynamic RAM – beschikbaar. Dit geheugen is zeer vergeetachtig en moet dus vele malen per seconde worden ververst. De exacte tijden verschillen per fabrikant, ofwel dat is de reden waarom de BROM dit niet kan gebruiken. Geheugenmodules in een desk- of laptop hebben een aparte chip die deze gegevens kan ophoesten, maar op een SBC worden de chips op het bordje gesoldeerd en een extra chip betekend een hogere verkoopprijs.

De oplossing is in de SOC een stukje SRAM – Static RAM – opnemen. Nu is dat per byte een stuk complexer, ofwel de hoeveelheid is meestal in het kilobyte-bereik. Op de Allwinner A64 is het 48 kilobyte voor normaal gebruik en dat is veel te weinig voor zeg een Linux-kernel. Vandaar dat we een tussenstap gebruiken en deze is onderdeel van U-Boot. De eerste stap wordt SPL – Secondary Program Loader, de eerste is de code in de BROM – genoemd en is meestal slechts 32 kilobyte groot.

Compileren

Zowel U-Boot als de Linux-kernel gebruiken een zogenaamd .dts – Device Tree Source – bestand voor systemen die geen BIOS hebben. In dit tekstbestand wordt de aanwezige hardware tot in details beschreven. Elk van de SBC’s met een Allwinner A64 heeft zijn eigen versie. Zoals gezegd bevat een SOC lang niet alles wat nodig is voor een werkend systeem.

De maker van Dusk OS legt uit hoe we een U-Boot SPL kunnen compileren voor de Pine A64 LTS. Met een andere _defconfig kan de U-Boot SPL voor een A64-OLinuXino woorden gecompileerd. Deze stap gebruikt uiteraard een .dts met onder andere de beschrijving van het gebruikte DRAM geheugen, ofwel die kan nu geïnitialiseerd worden. Vervolgens wordt daarin dan de rest van U-Boot geladen en gestart. En die kan vervolgens weer een Linux kernel starten. Echter niets weerhoudt ons om andere code te starten!

In een volgende stap kopiëren we onze SPL naar de Dusk OS-broncode en kan ook deze gecompileerd worden. Dat levert een 87.384 bytes (!) dusk.img bestand op die we naar een microSD kaart kunnen schrijven. Na plaatsen en aansluiten van een usb- naar UART-adapter, zag ik het volgende in Putty verschijnen:

U-Boot SPL 2024.04 (Aug 24 2024 - 16:15:18 +0200)

DRAM: 1024 MiB

Trying to boot from MMC1

Dusk OS

        ok

Het vreemde inspringen komt omdat Dusk OS alleen een linefeed als regeleinde gebruikt. Nu is het simpel om Putty automatisch een carriage return toe te laten voegen.

Forth

Dusk OS is geschreven in een eigen Forth-implementatie. Deze taal is lang geleden ontstaan en heeft als voordeel dat het gemakkelijk machinetaal kan genereren. In moderne programmeertalen is dat diep verstopt in de vertaalslag van abstracte code naar machinetaal. Dat is echter nog altijd het enige wat een computer begrijpt, hoe ver we de afgelopen ruim zestig jaar ook zijn gekomen.

Forth is een hogere programmeertaal dan assembly, al zullen de meeste programmeurs onder de lezers dat anders zien. Ik denk echter niet dat de moderne talen een binary ter grootte van de genoemde 87 kilobyte kunnen genereren. En als u bedenkt dat de eerste 8 kilobyte leeg is – andere besturingssystemen verwachten hier de MBR of tegenwoordig GPT – en de volgende 32 kilobyte onze U-Boot SPL bevat, wordt het nog indrukwekkender.

Tot slot

Na overleg met de maker van Dusk OS heb ik een kopie van zijn Pine A64 LTS gemaakt en die aangepast naar een versie die werkt op de A64-OLinuXino. Deze patch [https://git.sr.ht/~vdupras/duskos-deployments/commit/755df0ad32b5c7598f83e98c2566337c1b017879] is nu onderdeel van Dusk OS deployments. Voor mijn idee ga ik Forth uitzoeken, want dit lijkt een interessante sprong te zijn in de stappen machinetaal, assembly en dan een eerste generatie hogere programmeertaal.