Het besturingssysteem genaamd BirdOS

maarten70

Gevestigd lid
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
 

maarten70

Gevestigd lid
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.
 

maarten70

Gevestigd lid
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.
 

maarten70

Gevestigd lid
Sorry! Vals alarm...

Zoals ik vorige maand als reactie had gezegd waren 'we eindelijk klaar voor drive management', maar toen ik ermee bezig was bleek er een foutje te zitten in de PCI functionaliteit (hoe we bepaalde info verwerken), dit is een redelijk klein foutje maar ik heb er nog niks aan kunnen doen helaas. PCI is erg belangrijk voor AHCI (SATA drive management). Ik moet even kijken hoe we dit het handigst gaan oplossen, maar ooit komt het goed.

Ja, ik heb dus vrij weinig... Ik heb wel een plan voor de komende maanden: de website van FeatherCode moet een keer verbeterd worden maar dat komt in de zomervakantie samen met (hopelijk) een groot deel van drive management. Dus dat zijn de plannen voor de komende maanden, maar dit is een multi-maand plan.

En... BirdOS heeft een nieuw logo (zie hieronder)! Weg met die rare B met dropshadow.
Wat wel leuk is is dat dit logo tot stand is gekomen door een tomaat. Iedereen die wel eens een tomaat doorgesneden heeft weet wel dat daar waar het stokje aan vast hoort het allemaal iets steviger en witter is, dit wordt in stroken minder. Toevallig was het zo dat dat stukje in een driehoek uitgesneden was. De tomaat is verantwoordelijk geweest voor zowel de indeling van het logo als de vorm.

 

Rubensky

Moderator
Medewerker
Ik vind het een leuk logo! Ik ben benieuwd hoe veel je kan doen in de zomervakantie. Naar ik hoop is het dan mooi weer. Dan zou ik je toch willen adviseren daarvan te genieten en niet alle dagen binnen achter je computer te gaan zitten. :)
 

maarten70

Gevestigd lid
Het PCI probleem was het resultaat van verkeerd omrekenen van opgevraagde resultaten. Hierbij gaat het om het volgende:

De kernel vraagt informatie op van een PCI apparaat via de PCI I/O poort, de opgevraagde informatie (inmiddels ontvangen door de kernel) betreft 32 bits. De 32 bits kunnen onderverdeeld zijn in WORDS (16 bits) of BYTES (8 bits). Om te weten te komen of je het correcte apparaat hebt moet je 2 BYTES controleren.

De kernel probeerde dit te doen met specifieke aparte functies, PCIgetBaseClass() en PCIgetSubClass(), die de 32 bits probeerde om te rekenen naar de opgevraagde BYTE die ze moesten teruggeven aan de kernel. De BaseClass, of officieel genaamd de Class, geeft aan wat voor soort apparaat het is (bijvoorbeeld Ethernet controller of Mass Storage controller). De SubClass geeft weer de specifieke functie aan (zoals bij de Mass Storage controller onder andere Floppy Disk of ATA).

De twee functies waren echter niet in staat om dit correct om te rekenen waardoor de kernel niet het correcte apparaat kon vinden.

Alle functies die deze, of een soortgelijke taak hadden zijn ingewisseld voor de twee functies getBYTE() en getWORD(), die weer overkoepeld zijn door de functie getPCIval().

De getPCIval functie krijgt doorgegeven wat de ontvangen informatie is (uint32_t address), of de kernel een WORD of een BYTE wilt weten (bool BorW) en welke BYTE of WORD (uint8_t start). Die geeft dan de informatie address en start door aan de juiste functie. Om te beoordelen welke functie juist is om te gebruiken gebruikt de functie BorW (FALSE is BYTE en TRUE is WORD). Deze benaderingswijze blijkt tot nu toe correct te werken.
 

maarten70

Gevestigd lid
De kernel is op dit moment niet in staat om op correcte wijze een PCI apparaat te vinden. Hoewel we nog bezig zijn met onderzoek naar het probleem, hebben we het volgende probleem:

De kernel is in de veronderstelling dat, wanneer het zoekt naar een SATA apparaat, het een apparaat kan vinden. Zelfs wanneer er geen SATA apparaten aanwezig zijn. Het apparaat dat gevonden wordt bevindt zich op bus 1, apparaat 0.

Wanneer de kernel de opdracht krijgt om een IDE apparaat (of welk ander dan ook) op te sporen, geeft het aan dat het er geen kan vinden.
Hierbij kan het mogelijk gaan om een rekenfout door het systeem.

De fout die gemaakt is tijdens het testen is dat er alleen getest is voor een SATA apparaat. Dit was een fout gemaakt door mij. Bij nader testen is gebleken dat het systeem niet in staat was enige apparaten te vinden op de juiste wijze.

Inmiddels hebben we, om ons te ondersteunen bij het onderzoek, er een tweede Developer bijgehaald. Hij heeft meer ervaring met besturingssystemen en weet hoe PCI werkt.

Tot op heden hebben hij en ik het probleem nog niet kunnen vinden. Ondertussen zijn we bezig met het kijken naar mogelijke andere manieren om dit probleem te onderzoeken.

Het spijt ons voor de misinformatie en we houden je up-to-date over het onderzoek. Ik kan helaas geen uitspraak doen over wanneer dit probleem verholpen is.
 

maarten70

Gevestigd lid
Het PCI probleem is nog niet opgelost.

- Hexstr(), een functie die van nummers tekst kan maken is verbeterd. Het is nu sneller en kleiner.
- Het Memory Systeem is iets verbeterd zodat het systeem weet wat wat is.
- Een deel van de code is verbeterd en opgeruimd, zo zijn er oude functies die niet gebruikt worden verwijderd en zelfs hele bestanden.
- Een probleem is opgelost waar GetPCIDevice() te snel zou stoppen, hieronder meer
- We zijn begonnen aan een nieuwe custom bootloader, hieronder meer.

GetPCIDevice zou stoppen wanneer het één apparaat ziet dat niet voldoet, wat meestal de eerste is. Het originele probleem blijft bestaan.

We zijn aan een custom bootloader begonnen omdat we op dit moment GRUB gebruiken. GRUB is wel open source maar heel erg groot, het zou dus niet de moeite waard zijn om te kijken wat het doet. Het voordeel van een custom bootloader is dat je hem zelf hebt gemaakt en weet wat het doet, dit is fijn voor overzicht, vooral als er een probleem voor doet. We zijn er vandaag aan begonnen. Functionaliteit ontbreekt.
 

maarten70

Gevestigd lid
Mercury0x000d, de andere developer heeft het probleem gevonden en opgelost. Het lag er duidelijk aan dat ik iets probeerde te checken dat niet gecheckt hoeft te worden waardoor er rare dingen gebeuren.
 

maarten70

Gevestigd lid
Dit keer is het wel goed getest met de volgende apparaten die het op de juiste momenten wel en niet detecteert. Resultaten:

IDE, vindt als het er is (niet getest als het er niet is)
SATA, vindt als het er is, vindt niet als het er niet is
Ethernet, vindt als het er is, vindt niet als het er niet is
Multimedia Audio, vindt als het er is, vindt niet als het er niet is
 

maarten70

Gevestigd lid
Deze maand is er nu al meer gedaan dan in de afgelopen drie maanden samen.

En schrijf het in je agenda: 14 september a.s. bestaat BirdOS 4 jaar!
 

maarten70

Gevestigd lid
Elke maand wel weer iets... Afgelopen twee dagen is wiki.osdev.org offline, wat zo'n beetje de grootste bron van documentatie is voor OSdev. Nu moet je van alles apart bij elkaar zoeken, terwijl wiki.osdev.org alles bij elkaar heeft. Een beetje irritant.
 

maarten70

Gevestigd lid
Vandaag is BirdOS 4 jaar geworden! Het is ook alweer bijna twee jaar geleden dat ik in dit topic mijn eerste update schreef aan jullie. Namelijk op 9 december 2016 poste ik hier een bericht met een kleine uitleg over het project en wat nieuwsbrieven. Dit topic heeft al bijna 140 berichten, dat is veel. Ik had nooit verwacht dat er zoveel interesse zou zijn, dus aan allen: bedankt! Het motiveert me heel erg om te weten dat er mensen zijn die het leuk vinden om dit project te volgen.

Op 14 September 2014 was de eerste build van BirdOS geboren: Een 16-bit systeempje die de tekst 'Hello, World!’ op het scherm zette. Vier jaar later is er een 32-bit systeem die met de hardware en de gebruiker kan communiceren.

In oktober 2016 kwam daar een team bij, voor design.

Het is leuk om te zien hoe ver we al zijn gekomen. De 23ste een update!
 

Nieuwste berichten