Nachrichten

1

Softwareentwicklung / Re: "uint8_t" kennt mein GCC nicht

« am: 30. October 2012, 14:44 »

Also, wie gesagt, die werden nicht vom OS mitgeliefert bzw. auf die sollte man sich im Fall des Falles nicht verlassen, weil jeder Compiler die unterschiedlich definieren kann (wie groß ein int ist z.B.) und deswegen wird das vom Compiler in Form der stdint.h mitgeliefert.

Das wird besonders deutlich wenn du einen Cross-Compiler nutzt und z.B. für einen Mikrocontroller Code erzeugst. Da wird auch keine stdint.h vom OS genommen, sondern die die zum entsprechendem Compiler dazu gehört, weil die Datentypen halt unterschiedlich groß sind.

Heutzutage ist das mit den unterschiedlichen Größen der Datentypen nicht mehr so schlimm, da sich die Compiler-Hersteller auf die selben Werte geeinigt haben (war früher nicht so). Es gibt jetzt halt "nur" noch die Unterschiede zw. den Architekturen.

2

Softwareentwicklung / Re: "uint8_t" kennt mein GCC nicht

« am: 29. October 2012, 21:56 »

Sie wird vom OS (!) in stdint.h wie folgt definiert:

Code: [Auswählen]

typedef unsigned char uint8_t;Aber glaub mir: Lern bitte erstmal ein paar C-Grundlagen. Zu wissen, was in stdint.h steht, gehört wirklich zu den Basics.

Die solltest du auch lernen

Die wird nicht vom OS, sondern vom Compiler, nicht eingetragen, sondern mitgeliefert, in Form der stdint.h. Im C/C++ Standard steht nämlich leider nicht ganz genau welcher Datentyp immer wie groß ist. Deswegen ist bzw. war das Compiler abhängig.

3

Lowlevel-Coding / Re: Eigener mehrstufiger Bootloader

« am: 10. September 2012, 20:24 »

Ok, Bootloader ist für mich die Firmware, die die CPU startet (sprich auch sowas wie RAM initialisieren), auf dem PC wären das also BIOS und EFI. Auf ARM Systemen z.B. uboot.

Als OS-Loader sehe ich alles an, was kein Bootloader ist, sondern von diesem geladen werden muss, um dann ein OS zu laden.

4

Lowlevel-Coding / Re: Eigener mehrstufiger Bootloader

« am: 10. September 2012, 20:04 »

Jeder Bootloader, der nicht explizit Unterstützung für Fremdbetriebssysteme anbietet, ist auf ein Betriebssystem zugeschnitten... auch deiner.

Jap, genau was ich meine

Allerdings verwendest du hier wieder den Begriff Bootlaoder, meinst doch aber sicherlich OS-Loader. Denn GRUB ist kein Bootloader.

Multiboot gibt es ausschließlich für x86.

War nicht mal geplant GRUB auch auf andere Architekturen zu portieren? Aber dann müsste es wahrscheinlich auch zu einem Bootloader werden.

5

Lowlevel-Coding / Re: Eigener mehrstufiger Bootloader

« am: 10. September 2012, 17:06 »

Also ist jeder Bootloader, der nur _ein_ Modul laden kann, Linux-spezifisch. Kann er mehrere, ist er auf ein einziges Betriebssystem zugeschnitten (Ausnahme: Multiboot, was du explizit nicht unterstützen willst) und kann er keine, ist er auch auf ein einziges Betriebssystem zugeschnitten.

Die Intention der Ersteller war genau das, Linux zu laden und nicht, wie kann man auch andere OS laden.

Zumal nach der Argumentation auch mein Loader nicht nur auf mein OS zugeschnitten wäre.

Zu Multiboot, ich würde das gerne unterstützen bzw. auf anderen Platformen werde ich das auch machen (sofern vorhanden), aber es ist auf x86 einfach mehr Arbeit für mich.

6

Lowlevel-Coding / Re: Eigener mehrstufiger Bootloader

« am: 10. September 2012, 14:26 »

Und damit die meisten vorhandenen.

So viel zu deiner weiter unten geforderten Interoperabilität Die Loader sind also alle Unix- bzw. sogar Linux-spezifisch

tyndur ist kein Unix und ich verbitte mir diese Unterstellung.

Es geht mir darum, dass die meisten (auf jeden Fall auf ARM) Loader nur kernel+initrd können und das ist sehr wohl Linux-spezifisch Denn da kommt das ja her (bzw. von Unix) und die haben auch nicht auf eine Interoperabilität geachtet

7

Lowlevel-Coding / Re: Eigener mehrstufiger Bootloader

« am: 10. September 2012, 12:55 »

Dann würde ich das aber nicht mehr "Bootloader", sondern "OS-Loader" nennen, weil der Bootloader bleibt u-boot.

Dann ist aber GRUB auch "nur" ein OS-Loader, aber ja mir geht es um einen OS-Loader.

Weil? Du musst ja kein Root-Dateisystem drin haben. Eine verkettete Liste mit Modulen reicht auch - und dann ist es äquivalent zu von GRUB oder deinem OS-Loader geladenen Modulen. Nur halt in einer einzelnen Datei, die bei der Installation vom OS erzeugt wird.

Ist mir aus Nutzersicht zu umständlich, ich müsste also jedes Mal wenn der Nutzer, einen anderen Treiber schon vom OS-Loader mit laden lassen will oder es ein Update gab, das Image neu erstellen und das ist für mich einfach ein no-go. Das ich mir dadurch woanders Schwierigkeiten einhandle ist mir bewusst.

Allerdings ist es das gleiche bei der Sicherheit, entweder du machst es ganz einfach, also keine Sicherheit oder du betreibst Aufwand um Sicherheit zu bekommen.

Und damit die meisten vorhandenen.

So viel zu deiner weiter unten geforderten Interoperabilität Die Loader sind also alle Unix- bzw. sogar Linux-spezifisch

Hier kann ich dir grad nicht folgen. Was denn zum Beispiel?

Ich gucke im BIOS wegen PCI, weiß nicht wie gut GRUB das mit VESA hinbekommt und nutze es um das Bootlaufwerk genauer zu bestimmen (kann auch noch mehr sein, weiß ich gerade nicht genau).

Wieviele Bootloader gibt es denn, die du so in der realen Verbreitung mal gesehen hast?

Naja, da liegt doch das "Problem", zu weit über 90% Windows und ansonsten alles mögliche, was derjenige halt gerade mag um sein Linux laden zu lassen.

So nenne Er sie mir beim Namen.

Das ist ja das Problem, ich kenn sie nicht alle Und gerade auf dem PC/BIOS ist es doch relativ "einfach" einen OS-Loader zu schreiben, genauso wie für Openfirmware.

Und vernichtest zuverlässig jede Form von "mehrere Betriebssysteme". Wenn du natürlich den Microsoft-Ansatz "etwas anderes braucht niemand" nimmst, ist das valide. Für ein Hobby-OS solltest du Interoperabilität bereitstellen.

Ich glaube da scheitern wir beide an Bootloader oder OS-Loader, weil nur es meinem OS-Loader auf dem PC reicht, dass der Bootsektor geladen wird, heißt das doch nicht das andere OS nicht geladen werden können.

Um es kurz zu machen, ich brauche immer einen Bootloader der meinen OS-Loader lädt (auf dem PC BIOS oder in Zukunft mal EFI).

Nenne dein Teil einfach OS-Loader und lasse es vom garantiert funktionierenden Bootloader der Hardware (BIOS, GRUB, u-boot) laden.

Wie weiter oben schon gesagt, genau das ist der Fall

Also eMMC/SD sind definitiv extrem hardwarespezifisch. Und wenn du oben sämtliche Bootloader, die nur Kernel+Initrd laden können ausschließt, warum sind die dann jetzt hier wieder aktuell?

Also ich schließe die Bootloader aus, direkt mein OS zu laden, sie sind dafür da meinen OS-Loader zu laden. Dazu reicht ja kernel+initrd (sprich hardwarespezifischer Teil + allgemeiner Loader-Teil).

8

Lowlevel-Coding / Re: Eigener mehrstufiger Bootloader

« am: 10. September 2012, 09:44 »

Ich glaube, für den PC hast du keine 20% übrig.

Wie gesagt, reden wir von installiert/verwendet oder von wenn ich GRUB verwenden würde und dann noch die anderen, die vllt installiert sind? Denn auf den meisten System ist außer Windows nix installiert.

Ich habe mit einem eigenen Bootloader einfach mehr Sicherheit (mal davon abgesehen, dass ich das genauso wie das OS aus interesse mache), woran der Fehler liegt und nachher weniger Arbeit.

Abgesehen davon ist die Sinnfrage bei einem Bootloader genauso sinnlos wie bei einem OS.

Mein Reden

9

Lowlevel-Coding / Re: Eigener mehrstufiger Bootloader

« am: 10. September 2012, 07:02 »

Zu den Boards, die das nicht haben, zitiere ich mich selbst:

Siehe für den ARM-Port vor, dass man FTDs auch statisch in den Kernel einkompilieren kann und du hast das Bootloader-Problem gelöst.

Dann habe ich aber entweder nen Kernel, der unnötig groß ist (zumal ich das im Kernel gar nicht brauche) oder wieder einen Kernel pro Board, das keinen FTD hat. Also packe ich es in die sowieso boardspezifische Loaderstufe.

Für mich klingt dein Problem nach "mein Kernel braucht aber Module". Gute Bootloader können das bereits.

Weil jeder Bootloader das anders umsetzt und ich dann ja doch wieder für jeden Bootloader eine extra Stage schreiben muss. Zumal dann für jeden Bootloader wieder eine andere Config-Datei angepasst werden muss.

Es gibt aber weniger verschiedene Bootloader als Plattformen. Wenn du für u-boot und GRUB dein OS angepasst hast, hast du bereits 80% des Notwendigen erschlagen. So brauchst du ohnehin für jede Plattform einen eigenen Bootloader.

Jap, in gewisser Weise brauche ich das sowieso. Was mir am Wochenende einfach klar geworden ist, auf der ARM-Architektur kann ich noch nicht mal einfach so die UART benutzen, weil das auch wieder boardspezifisch ist. Mal wird eine ARM kompatible UART genutzt, mal eine die 16550 ähnlich ist und mal eine die noch anders funktioniert (nur mal als ein Bsp).

Da würde ich dann liebe an die Stelle nen vernünftigen Bootloader (z.B. openfirmware und selbst uboot dürfte da noch gehen) und die können dann ja wieder aus einem Dateisystem laden.

Dein Bootloader soll u-boot starten?

Da hast du mich falsch verstanden, ich möchte dass dann uboot meinen Bootloader startet.

Dann nimm doch den Bootloader, der schon angepasst ist.

Eigentlich wollte ich mir die Diskussion ja ersparen, aber egal Die Bootloader bieten aber halt nicht das was ich bräuchte und ich müsste so oder so noch eine eigene Stage da drüber packen.

Dann bau doch lieber eine bootloader-spezifische stage2, die
- bei guten Bootloadern (Kernel+Module) den Speicher so umbaut, wie dein Kernel das will
- bei normalen Bootloadern (Kernel+Initrd) die Module aus einer initrd in den Speicher so entpackt, wie dein Kernel das will
- bei dummen Bootloadern (BIOS) die Module von einem Speicher lädt und so in den Speicher packt, wie dein Kernel das will

Fertig. Da brauchst du nicht groß Layer schaufeln. Für x86 ist Multiboot ein geeigneter Standard, für ARM wären es FTDs (plus deine Modulliste, aber die kann ja statisch in den stage2 einkompiliert sein).

Also eine initrd will ich auf keinen Fall haben, nicht so wie Linux sie hat. Damit fallen schonmal die Bootloader weg, welche nur Kernel+initrd laden können. Dann kommt hinzu, dass es nicht nur darum geht, dass ich die Module dann so umbauen müsste wie ich das für richtige halte, sondern das ich im Falle von z.B. GRUB, auch noch andere Sachen machen muss und dazu gehört dann der Zugriff aufs BIOS. Der Plan ist zwar, eventuell auch nen "Loader" für GRUB mal zu haben, aber das liegt noch in sehr weiter Ferne.

Zumal, wie gesagt, dann noch das Problem der Config-Dateien dazu kommt, ich habe mir einfach als Ziel gesetzt, dass das bei mir einheitlich sein soll und das heißt also, dass ich nicht will das man einmal an einer GRUB oder sonstwas für nem Bootloader Config-Datei rumspielen muss, sondern an der Config-Datei von meinem Bootloader.

Ich weiß halt nicht wie das bei extfs aussieht, also ob es da sowas wie defragmentieren gibt, weil da könnte genau das Problem auftreten und das will ich, wenn es irgendwie geht, halt vermeiden.

ext2 kennt "immutable" als Dateiflag. Damit ist es nicht verschiebbar. Lässt sich mit root-Rechten natürlich entfernen.

Also genauso "sicher" wie vorher auch. Es und nach Murphy wird es auch schief gehen

Zumal, was ist eigentlich das Problem daran, einen eigenen Bootloader zu schreiben, wenn man es für richtig hält? Warum darf es denn unter Linux, so viele verschiedene Bootloader geben und GUIs geben usw.?

Es ist ja nicht so, dass es hier darum geht ein eigenes OS zu schreiben, da macht der Bootloader es dann auch nicht mehr schlimmer

Edit::

Um nochmal was zur Diskussion, eigener Bootloader beizutragen

Wenn du für u-boot und GRUB dein OS angepasst hast, hast du bereits 80% des Notwendigen erschlagen.

Meinst du damit die installierten Bootloader bzw verwendeten? Weil damit hast du definitv nicht Recht (ich sag nur Verhältnis Windows-/Linuxsysteme)!

Dazu kommt noch, was mache ich mit den restlichen 20%, vorallem auf dem PC. Von dem Bootloader den du verwendest habe ich z.B. auch noch nichts gehört. Da müsste ich also für jeden Bootloader den es auf dem PC gibt meine Stage2 anpassen. Da werde ich ja nie fertig um 100% der Systeme zu unterstützen. Wenn ich aber einen eigenen schreibe, unterstütze ich aber sofort 100% der Systeme.

Das gleiche für ARM, wenn ich nur uboot unterstütze, kann ich die meisten Android-Systeme vergessen (an die ist nunmal am günstigsten ranzukommen), denn da wird fastboot genutzt. Da ich auf ARM eh einen Boardspezifischen Teil brauche, kann ich auch zumindest das Laden von eMMC und SD unterstützen und wenn es dann noch reicht einen Kernel+initrd zu laden, sollte ich auch dort annähernd 100% der vorhandenen Bootloader unterstützen.

10

Lowlevel-Coding / Re: Eigener mehrstufiger Bootloader

« am: 09. September 2012, 16:27 »

Was meinst du mit "würde mit zum Bootsektor gehören"? Ist nicht alles, was im FS liegt, außerhalb des Bootsektors?

Naja, einmal von der Lage des Source-Code´s her und Stage1 und 1.5 bilden zusammen ja eine Einheit, z.B. wenn Stage1 für´s BIOS und FAT12 geschrieben ist, dann ist es Stage1.5 auch. Daher gehört das für mich "zusammen", wenn man die Stage1.5 dann auch im Dateisystem sehen kann. Dazu fällt mir ein, gibt es eigentlich bei anderen Dateisystemen auch sowas wie versteckt/hidden als Ordner- und Dateiattribut?

Zu der ganzen Thematik fällt mir noch ein, bei FAT32 gibt es doch sowieso mehr als nur den eigentlichen Bootsektor, da müsste das wahrscheinlich nicht mal so sein.

11

Lowlevel-Coding / Re: Eigener mehrstufiger Bootloader

« am: 09. September 2012, 15:36 »

FTDs solltest du nutzen, statt dir eine eigene /boot/device.hints (siehe FreeBSD) einfallen zu lassen.

Genau das werde ich auch versuchen zu machen

Damit lässt sich Platform und Architektur unabhängig, die vorhandene Hardware definieren. So ist alles nach der Stage3 gleich und muss nicht für eine andere Platform/Architektur angepasst werden.

Da kommt aber noch ganz schön Arbeit auf mich zu

12

Lowlevel-Coding / Re: Eigener mehrstufiger Bootloader

« am: 09. September 2012, 14:14 »

Du solltest aufmerksamer lesen.

Das war das mit dem Platz zwischen MBR und dem Start der ersten Partition.

Ich hatte das schon gelesen, aber irgendwie hatte ich es in Erinnerung, dass die als Datei irgendwo liegt.

Zur Not, muss ich halt doch eine Datei in "/" ablegen und diese als stage1.5 nutzen, würde dann ja mit zum Bootsektor gehören und ist eine Lösung mit der ich mich anfreunden könnte.

13

Lowlevel-Coding / Re: Eigener mehrstufiger Bootloader

« am: 09. September 2012, 13:39 »

GRUB packt seine stage1.5 doch in den Platz zwischen MBR und Anfang der ersten Partition. Traditionell wären das also zusätzliche 31 kB, neuerdings eher ein knappes MB. Geht aber natürlich nur, wenn dir die komplette Platte gehört, in einem Partitionsbootsektor klappt das offensichtlich nicht. Da könntest du dich entscheiden, eine eigene Partition für diese Zusatzsektoren herzunehmen, oder ein FS zu benutzen, das dir erlaubt, ein paar Sektoren am Anfang abzuzwacken (FAT hat das ja zum Beispiel).

Das mit den Zusatzsektoren bei FAT wusste ich so noch gar nicht, aber birgt auch wieder das Problem, ich kann dann wahrscheinlich nicht einfach in eine schon vorhandene Partition installieren. Ziel wäre es, so wenig wie möglich an den schon vorhandenen Sachen zu ändern, sprich "einfach" nur den Bootsektor ändern, die Dateien an die richtige Stelle kopieren und gut ist. Muss ich mir mal genauer angucken und durch den Kopf gehen lassen.

Für die ARM-Architektur geben dir Flattened Device Trees (FTDs) eine Möglichkeit, zur Laufzeit die vorhandene Hardware zu ermitteln. Die sind boardspezifisch und werden vom Hersteller mit dem Bootloader mitgeliefert und beim Start dem Kernel bereitgestellt, entweder als binäre Datenstruktur oder in einem menschenlesbaren Format.

Gilt für welche Boards und was ist mit den Boards die das nicht haben? Ich habe hier halt nen Raspberry Pi, der hat es nicht und nen AC100 (Tegra 2) und ich möchte meinen da gibts das auch nicht. Mein drittes ARM-Board (weiß gerade nicht die Bezeichnung) hat das definitiv nicht, da schon älter.

Das ist also nur eine zusätzliche Option und nicht die ultimative Lösung

Für mich klingt dein Problem nach "mein Kernel braucht aber Module". Gute Bootloader (EFI, GRUB, Syslinux, Openfirmware) können das bereits. Warum du sie ablehnst, kann ich nicht nachvollziehen.

Weil jeder Bootloader das anders umsetzt und ich dann ja doch wieder für jeden Bootloader eine extra Stage schreiben muss. Zumal dann für jeden Bootloader wieder eine andere Config-Datei angepasst werden muss.

Ok, obiges muss ich so oder so machen, aber ich habe einen Punkt ab dem das dann alles einheitlich ist und das will ich versuchen zu erreichen.

Deine Verzeichnisstruktur ist overkill, denn sie setzt voraus, dass auch ein Dateisystem verwendet wird. Das ist bei Flash nicht zwingend gegeben, normalerweise hast du dort den Kernel und die Initrd in zwei getrennten, fixen Bereichen im Flash sitzen und der Bootloader kopiert diese 1:1 in den RAM und springt hin.

Ist kein unüberwindbares Problem. In dem Fall wäre es dann ähnlich wie beim BIOS, man bräuchte ne Stage1, welche Stage2 und 3 lädt. Zumal das Problem ja ohnehin vorhanden ist. Da würde ich dann liebe an die Stelle nen vernünftigen Bootloader (z.B. openfirmware und selbst uboot dürfte da noch gehen) und die können dann ja wieder aus einem Dateisystem laden.

Dann nimm doch den Bootloader, der schon angepasst ist.

Eigentlich wollte ich mir die Diskussion ja ersparen, aber egal Die Bootloader bieten aber halt nicht das was ich bräuchte und ich müsste so oder so noch eine eigene Stage da drüber packen.

GRUB und LILO benutzen Blocklisten in ein Dateisystem hinein, GRUB aber nur für stage2 (die sich seltener ändert und daher seltener kaputtgeht).

Naja, seltener ist immer noch zu oft Ich weiß halt nicht wie das bei extfs aussieht, also ob es da sowas wie defragmentieren (als Bsp.) gibt, weil da könnte genau das Problem auftreten und das will ich, wenn es irgendwie geht, halt vermeiden.

Stimmt, GRUB 1 benutzt natürlich auch Blocklisten für stage2, außer wenn man eine stage1.5 benutzt. Ob GRUB 2 das immer noch kann, weiß ich nicht, aber meines Wissens ist da der normale Weg, dass man einen FS-Treiber fest in die core.img reinbaut, die einer kombinierten stage1 und stage1.5 entspricht.

Also wurde das Problem auch schon mal so ähnlich von anderen gelöst, interessant.

Wo liegt dann eigentlich diese stage1.5?

14

Lowlevel-Coding / Eigener mehrstufiger Bootloader

« am: 09. September 2012, 11:24 »

Als erstes möchte ich sagen, ja ich will einen eigenen Bootloader schreiben (bzw. habe dies ohnehin schon gemacht) und nicht GRUB und Co nutzen.

Da ich jetzt endlich wieder etwas mehr Zeit habe und mich mal wieder mit OSDev beschäftigen kann, wollte ich meinen Kernel (und dann auch das gesamte OS) auf andere Architekturen portieren. Da mit dem Raspberry Pi auch eine sehr gute Möglichkeit dafür zur Verfügung steht, habe ich mit der ARM-Archiktektur angefangen.

Bevor ich den Kernel portieren kann, muss dieser erstmal geladen werden können (und bei mir auch noch zusätzlich Programme). Nein ich will die Programme nicht in eine initrd packen (warum das eher unschön ist, sollte sich weiter unten ergeben).

Problem, vorallem auch auf der ARM Architektur, ist es, dass es keine einheitliche Platform, für die man programmieren kann, gibt. Jedes Board ist im Endeffekt wieder eine andere Platform, selbst wenn mir ein flexibler Bootloader zur Verfügung stehen sollte. Es ist von uboot, über Openfirmware (mein momentaner Favorit), fastboot bis bald EFI alles mögliche vorhanden.

Dann kommt noch hinzu, dass es keine, mir bekannte, Möglichkeit gibt, zur Laufzeit die vorhandene Hardware herauszufinden und vorallem auch wo im Adressbereich sie sich befindet. Also muss es auf jeden Fall auf der ARM-Architektur immer was Board-spezifisches geben.

Dazu kam mir dann, mal wieder (wie einige jetzt denken werden ), hoch komplizierte Idee.

Ich möchte meinen Bootloader in mehrere Stages aufteilen (bisher nix neues):

• Stage 1 (optional, wenn wir auf dem PC, die Firmware keine Dateien laden kann) -> Bootsektor, lädt Stage 2 und 3
• Stage 1.5 (optinal, nur wenn benötigt) -> lädt Stage 2 und 3
• Stage 2 -> hardware-dependent Teil, stellt ein HAL für die jeweilige Platform zur Verfügung
• Stage 3 -> hardware-independent Teil, nutzt HAL und lädt Kernel und Programme

Soweit nix neues, aber ich möchte es nun so umsetzen, dass Stage 2 und 3, 2 voneinander unabhängige Dateien sind.

Der "boot"-Ordner von meinem System könnte für die x86-Architektur z.B. so aussehen:

/boot
    osloader
    /stage2
        bios
        efi
        openfirmware

Mit EFI habe ich mich noch nicht weiter beschäftigt, aber Openfirmware z.B. kann Dateien von unterstützten Dateisystemen laden. Problem ist hier das BIOS, denn dort habe ich nur 512byte (bzw. genug wenn ich direkt von CD boote) zur Verfügung. Der Bootsector müsste nun aber die beiden Dateien "/boot/stage2/bios" und "/boot/osloader" laden, dass das nicht geht ist mir klar. Also war mein erster (und bisher leider einziger) Gedanke, ich brauche eine Stage 1.5. Der Bootsektor würde also entweder ein paar mehr Sektoren laden, keine Ahnung wo ich die abzwacken soll oder (was zwar gehen würde, aber unschön wäre) ich müsste noch eine Datei z.B. "stage_1_5_bios" laden und die lädt dann die anderen beiden Dateien.

Problem bei dieser zusätzlichen Datei wäre, wo soll diese gespeichert werden. Um so flexibel wie möglich zu sein, müsste sie in "/", was aber nicht so schön in eine aufgeräumte Ordnerstruktur passen würde. Eine andere Möglichkeit wäre, im Bootsektor einen direkten Verweis auf z.B. den FAT-Dateieintrag zu speichern. Da sehe ich aber das Problem, was passiert beim Defragmentieren? Der FAT-Dateieintrag könnte ja an eine andere Position verschoben werden und dann findet der Bootsektor den Eintrag nicht mehr. Ich weiß auch nicht wie es mit anderen Dateisystemen ist, könnte es da ein ähnliches Problem geben?

Meine Frage also, wie könnte man obiges Problem sinnvoll lösen?

[Jetzt sollte man nur weiterlesen wenn man das Konzept interessant findet oder darüber diskutieren möchte, hat nämlich nix mehr mit dem obigen Problem zu tun]

Warum eigentlich so kompliziert? Mein Problem ist einfach, dass ich nicht meinen kompletten Bootloader für jedes ARM-Board anpassen wollte. Als ich mich dann aber mal näher mit der Doku zum Raspberry Pi auseinander gesetzt habe, viel mir auf, dass sich das mit dem bisherigen Konzept nicht machen lässt. Deswegen jetzt mehrere Stufen.

Um einfach mal zu verdeutlichen wie das ganze dann für die ARM-Architektur aussehen könnte:

/boot
    osloader
    /stage2
        bcm2835
        tegra2
        openfirmware

Bei openfirmware bin ich mir auch nicht ganz 100%ig sicher, denn ich weiß dass es möglich ist, so einiges über die Hardware herauszufinden und auch bestimmte Funktionen (ähnlich wie beim BIOS) nutzen zu können, aber ob ich auch direkt herausfinde welcher UART verwendet wird und wo dieser hingemappt ist, keine Ahnung. Kann also gut sein, dass ich auch für Boards mit openfirmware eine spezialisierte Stage2 haben muss.

Die Idee ist es dann, dass Stage2 die Hardware initialisiert und einen HAL für Stage3 zur Verfügung stellt. Dabei kann Stage2 im einfachen binär-Format vorliegen (z.B. beim BIOS nötig) oder als ELF-Datei (für Bootloader wie uboot oder auch GRUB). Stage3 ist dann auf jeden Fall im ELF-Format (es sei denn mir kann noch jemand, ein einfacheres, weniger komplexes, Dateiformat nennen, wo ich die Datei an einer beliebigen Stelle ausführen kann und nur die Symbole auflösen muss, welches auch noch von aktuellen GCC-Versionen unterstützt wird?), damit es an einer beliebigen, von Stage2 festgelegten, Stelle ausgeführt werden kann.

Von Stage2 werden dann auch ein paar nötige hardware-dependent Sachen an Stage3 weitergegeben (z.B. Memory-Map und eindeutiger Name des Boards/derPlatform). Denn Stage3 muss dann auch eine Board-/Platformspezifische Konfigurationsdatei laden, in dem die zu ladenden Programme (was auch Treiber sein können bzw. müssen) stehen. Bei dieser Sache bin ich mir auch noch nicht ganz sicher ob ich das über eine Konfigurationsdatei mache oder ob die zu ladenden Programme nicht direkt in Stage2 gespeichert werden und Stage3 dann zur Verfügung gestellt werden. So wäre ich nicht ganz so flexibel, aber es wäre weniger aufwendig. Das einzige was nämlich in so einer Datei stehen würde, wäre der zu ladende Kernel (für den Fall es könnte mehrere Versionen geben, was ich im Moment nicht plane) und viel wichtige, die zu ladenden Programme und Treiber, damit das OS von sich aus die restlichen Treiber und Programme laden kann.

Am Beispiel des x86er, bräuchte ich z.B. einen IDE-, einen AHCI, einen USB1-3, einen ATAPI usw. -Treiber und noch mind. der Device- und Storage-Server. Für die x86er Architektur würde sich wahrscheinlich eine Datei anbieten, damit man die Treiber auswechseln bzw erweitern kann. Auf den ARM-Boards ist das eher unnötigt, da es sich um SOCs handelt, wo es keine austauschbare Hardware gibt.

Was also machen?

15

Softwareentwicklung / Re: Makefile Magie ;)

« am: 17. February 2012, 21:27 »

Thx, das mit dem VPATH hat wunderbar funktioniert

16

Softwareentwicklung / Re: Makefile Magie ;)

« am: 16. February 2012, 19:43 »

Die eine Lösung wäre eine zusätzliche Regel einzuführen, die analog zur built-in-Regel die Plattformdateien kompiliert:

Interessant, werde ich dann mal ausprobieren.

Was vielleicht auch funktionieren könnte, wäre den PLATFORM-Pfad zusätzlich in den VPATH aufzunehmen. Das ist allerdings nur Spekulation meinerseits, weil ich um VPATH lieber einen Bogen mache. Es könnten dann weitere Probleme auftreten, falls in beiden Verzeichnissen Dateien mit dem selben Namen liegen.

Hmm, ich habe im VPATH ja schon das Source-Verzeichnis drin, kann man da mehrere Verzeichnisse reinpacken? An doppelten Dateinamen sollte es nicht hapern.

17

Softwareentwicklung / Re: Makefile Magie ;)

« am: 16. February 2012, 17:59 »

Wow, jetzt bin ich noch mehr verwirrt

Ich dachte bisher das die Abhängigkeiten auch gleichzeitig das "Rezept" zum Kompilien sind. Sprich in der Form "AUSGABE_DATEI: SOURCE_DATEI [ABHÄNGIGKEITEN]".

Also scheine ich make nicht wirklich verstanden zu haben. Anders gefragt, wie könnte ich denn mein Problem lösen? Im Moment denke ich einfach nur, wieso ist make so blöd

18

Softwareentwicklung / Re: Makefile Magie ;)

« am: 15. February 2012, 21:54 »

Das Problem ist, dass keine Regel existiert, die Source-Dateien in $(PLATFORM) in Objektdateien nach . kompiliert. Also sowas wie zum Beispiel das hier:

Hmm, ich dachte die erste Regel entspricht in etwa genau deinem Bsp.?!

Es ist keine Fehlermeldung ausgegeben worden, weil die leeren Regeln aus der .depend-Datei (kernel.o: ../../../../src/platform/x86_32/kernel.cpp usw...) auch die Dependencies von kernel.ko erfüllen.

Da kann ich dir gerade gar nicht folgen.

19

Softwareentwicklung / Makefile Magie ;)

« am: 15. February 2012, 21:12 »

Ich baue meine Sources gerade so um, dass ich meinen Kernel (und dann das ganze OS) auf andere Architekturen portieren kann.

In meinem Makefile habe ich eine Variable "SRCS" wo meine ganzen Source-Dateien drin stehen. Aus dieser Liste habe ich vorher einfach durch ersetzen der Endung eine Liste von Object-Dateien gemacht. Nun müssen aber einige Einträge der Liste um die Verzeichnisse bereinigt werden, was auch kein Problem war (wird über die Hilfsvariable "TEMP" gemacht). Nur kompiliert er jetzt genau diese Dateien nicht. Obwohl die entsprechenden Regeln dafür vorhanden sind.

Mein Makefile:

Code: [Auswählen]

CXXFLAGS = -O2 -Wall -Wextra -fno-use-cxa-atexit -fno-stack-protector -fno-rtti -fno-exceptions -fno-asynchronous-unwind-tables -fno-builtin -march=i586 -I$(PREFIX)include -I../../../../../include -fno-common
CXXFLAGS += -DX86_32
LDFLAGS = -nostdlib -T$(LINKERSCRIPT) -i
PREFIX = ../../../../src/
PLATFORM = platform/x86_32/
SRCS = $(PLATFORM)kernel.cpp string.cpp $(PLATFORM)exceptions.cpp $(PLATFORM)idt.cpp $(PLATFORM)video.cpp debug.cpp $(PLATFORM)vmm.cpp
SRCS += $(PLATFORM)vmmAddrSpace.cpp slab.cpp map.cpp avl.cpp $(PLATFORM)pmm.cpp list.cpp $(PLATFORM)cpu.cpp $(PLATFORM)gdt.cpp
SRCS += $(PLATFORM)tss.cpp patriciatree.cpp array.cpp $(PLATFORM)syscall.cpp semaphore.cpp $(PLATFORM)scheduler.cpp
SRCS += $(PLATFORM)task.cpp $(PLATFORM)thread.cpp port.cpp
TEMP = $(subst $(PLATFORM),,$(SRCS))
OBJS = $(TEMP:%.cpp=%.o) exceptions-asm.o scheduler-asm.o
DEPENDFILE = .depend
LINKERSCRIPT = ../kernel.ld
VPATH = $(PREFIX)

.PHONY: all clean

all: $(DEPENDFILE) kernel.ko

$(DEPENDFILE): $(SRCS:%=$(PREFIX)%)
$(CXX) -M $(SRCS:%=$(PREFIX)%) $(CXXFLAGS) > $(DEPENDFILE)

-include $(DEPENDFILE)

exceptions-asm.o: $(PREFIX)$(PLATFORM)exceptions.asm
nasm -O3 $(PREFIX)$(PLATFORM)exceptions.asm -f elf -o exceptions-asm.o
scheduler-asm.o: $(PREFIX)$(PLATFORM)scheduler.asm
nasm -O3 $(PREFIX)$(PLATFORM)scheduler.asm -f elf -o scheduler-asm.o
   
kernel.ko: $(OBJS) $(LINKERSCRIPT)
$(LD) $(OBJS) -o kernel.ko $(LDFLAGS)
cp kernel.ko ../

clean:
-rm -f kernel.ko
-rm -f *.o
-rm -f *.s
-rm -f $(DEPENDFILE)

Folgender Ausschnitt aus meiner ".depend"-Datei sieht auch ok aus (die ganze passte nicht in den Beitrag):

Code: [Auswählen]

kernel.o: ../../../../src/platform/x86_32/kernel.cpp \
 ../../../../src/include/panic.hpp ../../../../../include/typedef.h \
 ../../../../../include/compiler.h \
 ../../../../src/include/loader-strucs.hpp \
 ../../../../src/include/platform/x86_32/loader-strucs.hpp \
 ../../../../src/include/platform/x86_32/irq/ioapic.hpp \
 ../../../../src/include/video.hpp \
 ../../../../src/include/platform/x86_32/video.hpp \
 ../../../../src/include/exceptions.hpp \
 ../../../../src/include/platform/x86_32/exceptions.hpp \
 ../../../../src/include/debug.hpp ../../../../src/include/pmm.hpp \
 ../../../../src/include/platform/x86_32/pmm.hpp \
 ../../../../src/include/vmm.hpp \
 ../../../../src/include/platform/x86_32/vmm.hpp \
 ../../../../src/include/spinlock.hpp \
 ../../../../src/include/platform/x86_32/spinlock.hpp \
 ../../../../src/include/map.hpp ../../../../src/include/avl.hpp \
 ../../../../src/include/list.hpp ../../../../src/include/slab.hpp \
 ../../../../src/include/memory.hpp \
 ../../../../src/include/platform/x86_32/memory.hpp \
 ../../../../src/include/kernel.hpp \
 ../../../../src/include/platform/x86_32/kernel.hpp \
 ../../../../src/include/cpu.hpp \
 ../../../../src/include/platform/x86_32/cpu.hpp \
 ../../../../src/include/asm.hpp \
 ../../../../src/include/platform/x86_32/asm.hpp \
 ../../../../src/include/irq.hpp \
 ../../../../src/include/platform/x86_32/irq.hpp \
 ../../../../src/include/fpu.hpp \
 ../../../../src/include/platform/x86_32/fpu.hpp \
 ../../../../src/include/timer.hpp \
 ../../../../src/include/patriciatree.hpp \
 ../../../../src/include/rwlock.hpp \
 ../../../../src/include/platform/x86_32/rwlock.hpp \
 ../../../../src/include/syscall.hpp \
 ../../../../src/include/platform/x86_32/syscall.hpp \
 ../../../../src/include/semaphore.hpp ../../../../src/include/os.hpp \
 ../../../../src/include/array.hpp ../../../../src/include/task.hpp \
 ../../../../src/include/platform/x86_32/task.hpp \
 ../../../../src/include/thread.hpp \
 ../../../../src/include/platform/x86_32/thread.hpp \
 ../../../../src/include/atomic.hpp \
 ../../../../src/include/platform/x86_32/atomic.hpp \
 ../../../../src/include/scheduler.hpp \
 ../../../../src/include/platform/x86_32/tss.hpp \
 ../../../../src/include/port.hpp \
 ../../../../src/include/platform/x86_32/cpu/smp.hpp \
 ../../../../src/include/platform/x86_32/timer/rtc.hpp \
 ../../../../src/include/platform/x86_32/idt.hpp
string.o: ../../../../src/string.cpp ../../../../src/include/string.hpp \
 ../../../../../include/typedef.h ../../../../../include/compiler.h
Die "string.cpp" wird kompiliert, aber nicht die "kernel.cpp". Kann sich jemand denken wieso? Ich bekomme auch keine Fehlermeldung oder so (erst wenn ld versucht alle Object-Dateien zusammen zu linken).

20

Softwareentwicklung / Re: Welche Compiler

« am: 26. January 2012, 12:28 »

"ziemlich sicher" heißt, dass du es nicht weißt. Und damit auch nicht, ob VBox oder dein Code schuld ist.

Warum läuft der Code dann überall anders?! Zumal ich soweit war, dass VBox Probleme mit "push gs" hatte, sobald die Instruktion auskommentiert war, lief der Code. Weiter habe ich nicht geguckt, da VBox auch sonst mehr Probleme macht als alles andere.