Het besturingssysteem genaamd BirdOS

Dan nu eindelijk de update:

Het systeem kan het totale aantal RAM berekenen en niet alleen low en high.

Het systeem heeft een nieuw error systeem. Voorheen had het er geen, maar nu wel.

De huidige ondersteunde errors zijn:
- Unkown error (code 0)
- Couldn’t detect memory (code 55)
- Illegal operation (code 56)
- Failed allocating memory (code 57)

Aangezien ik geen idee heb over standaard error codes, heb ik me laten inspireren door POST codes (van de BIOS), waarbij 55 gebruikt wordt voor ongevonden RAM. Hierna heb ik gewoon doorgeteld waarbij unkown error een uitzondering is.

Memory map wordt niet ondersteund omdat GRUB 64-bit adressen gebruikt. In plaats daarvan claimen we gewoon alles na 10MiB. Deze soort oplossing wordt wel vaker gebruikt, al zou ik het niet de beste noemen. Maar, dit is meer dan genoeg en zal geen probleem zijn. Het systeem bijvoorbeeld zit nog steeds onder de 1 MiB, en zal er ook niet boven komen (hij is nu ~26 KB en GRUB is 5 MB, dit betekent dat er zo‘n 5 MiB, in het ergste geval 4 MiB, overblijft voor andere BIOS en kernel data).

Basic memory management is een groot onderdeel van deze versie. Het systeem kan meerdere stukken memory toewijzen (physical), natuurlijk zijn er nog geen programma’s dus dit is alleen voor eigen gebruik. Hierna kan het ook blokken weer weghalen als ze niet meer nodig zijn en daarna weer opnieuw toewijzen zonder problemen aan andere dingen. Ook kan het een grotere plek toewijzen dan de 1024 bytes, deze blokken worden dan gewoon simpelweg groter gemaakt.



Builds zullen nu anders aangegeven worden. Voorheen deden we het nummer van een build, maar om het duidelijk te maken en te houden zullen we deze voortaan aanduiden als een versie nummer. Als voorbeeld nemen we een van de builds deze maand: build 412 revision 2. We gebruiken altijd [major.minor.build.revision] als aanduiding dus hier gaat ‘ie… Deze build zou versie 0.4.12.2 zijn. Major zal altijd een duizendtal zijn dus wanneer we de duizend halen zal het pas versie 1.0.0.0 zijn. Hondertallen zijn minor en dan is dit dus build 12 van versie 0.4.x.x, revisions zijn revisions en zullen gebruikt worden als er bijvoorbeeld een klein dingetje verbeterd moet worden of terwijl er aan hetzelfde onderwerp gewerkt wordt. Zo was 0.4.11 voor basic memory management en v0.4.12 de verbetering en uitbreiding van memory management.

De laatste versie van deze update is 0.4.12.14, deze probeert paging aan te zetten maar faalt wat zorgt voor errors, vervolgens kan het systeem niet verder en blijft dus hangen. De belangrijkste versies deze update op een rijtje:

- v0.4.11.1 eerste build met functionele memory allocation
- v0.4.11.7 eerste build met functionele memory deallocation en reallocation
- v0.4.12.2 eerste build die in staat is grotere plekken dan 1024 bytes toe te wijzen
- v0.4.12.14 die paging probeert aan te zetten, maar faalt
 
Het is best geinig, het veranderen van CR0 naar 0x80000001 van 0x01 zorgt voor een double-fault. De 8 in 0x80000001 zet het 32ste bitje op 1. Het 32ste bitje is paging enabled wanneer het 1 is. CR0 is een register die een aantal dingen in Protected Mode regelt waaronder paging dus, maar ook het aanzetten van Protected Mode zelf. Geen idee waarom het gebeurd, rede is ook lastig te vinden.
 
v0.4.12.21 heeft meer licht op dit probleem geworpen.... Dus hier het deel van de 23 mei update, met meer informatie over de DOUBLE_FAULT.


Diagnostische info paging

Wanneer Vireo paging probeert in te schakelen, ontstaat er een DOUBLE_FAULT. Een DOUBLE_FAULT onstaat doordat er naast een onafgehandelde FAULT nog een FAULT ontstaat. Voor het volgende deel, weer een beetje uitleg. De CPU heeft registers deze worden gebruikt om te rekenen of om bepaalde informatie toe te passen of op te slaan. Alles met een 'e' ervoor (bijv. eax, edx, esi, edi en esp) zijn 32-bits adressen waar je bijna alles mee kan doen wat je wilt zoals rekenen en adressen tijdelijk op slaan. Daarnaast heb je nog CR registers, deze bevatten informatie die de CPU gebruikt waarvan je als besturingssysteem bij sommigen read/write access hebt. In geval van paging worden CR0, CR2 en CR3 gebruikt.

CR3 wordt gebruikt om het adres van de page directory (beetje info voor paging) in te stoppen. Op het moment dat we dat doen en paging aan zetten (bit 31 in CR0) ontstaat er een PAGE_FAULT. Dit is af te leiden aan (als we de logs van de virtuele machine gebruiken) CR2 een adres in zich heeft dit is het adres waar de PAGE_FAULT plaats heeft gevonden. Hierna heeft CR0 het nummer 0x60000010 (cache disable, not-write through en numeric error), belangrijk om te weten is dat het net daarvoor 0x80000011 was. 0x80000011 staat voor Protected mode enabled, numeric error en paging enabled. Misschien zie je het al ontstaan... Er ontstaat ergens een numeric error, we doen paging aan, dat veroorzaakt een PAGE_FAULT (fault #1) en tegelijkertijd zet de CPU (waarschijnlijk door de numeric error) Protected Mode uit wat nooit zomaar kan zonder een fault te creëren, dat is dus fault #2. Dus wat uitgezocht moet worden is wat de numeric error maakt en of dit inderdaad de oorzaak is voor 0x60000010 (of dat dit toch de PAGE_FAULT is) en waarom er een PAGE_FAULT onstaat.


Next up

Eerst gaan we aan de gang met Driveman (waar we weer ietsje verder mee zijn) en daarna komt ooit een keer paging, dus het huidige probleem wordt niet verholpen maar wordt weggestopt tot een andere keer. De rede dat ik hiervoor kies is zodat we het eerst allemaal functioneel maken en dan pas veiliger. Dus eerst nog wat andere milestonetjes pakken en dan komen we bij de rest.
 

Nieuwste berichten

Bovenaan Onderaan