/boot
osloader
/stage2
bios
efi
openfirmware
/boot
osloader
/stage2
bcm2835
tegra2
openfirmware
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.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).
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.Womit wir wieder bei der Sinnfrage wären. :-)
Warum eigentlich so kompliziert? Mein Problem ist einfach, dass ich nicht meinen kompletten Bootloader für jedes ARM-Board anpassen wollte.Dann nimm doch den Bootloader, der schon angepasst ist. ;-) Auf ARM habe ich übrigens bisher nur u-boot, RedBoot und boot.nb0 angetroffen, Openfirmware kenne ich nur von Sun SPARC...
Auf den ARM-Boards ist das eher unnötigt, da es sich um SOCs handelt, wo es keine austauschbare Hardware gibt.Zumindest u-boot unterstützt USB und kann auch davon booten... und schon hast du austauschbare Hardware. :-)
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.
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.
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?Du solltest aufmerksamer lesen. ;)
Du solltest aufmerksamer lesen.Ich hatte das schon gelesen, aber irgendwie hatte ich es in Erinnerung, dass die als Datei irgendwo liegt.
Das war das mit dem Platz zwischen MBR und dem Start der ersten Partition.
FTDs solltest du nutzen, statt dir eine eigene /boot/device.hints (siehe FreeBSD) einfallen zu lassen.Genau das werde ich auch versuchen zu machen :)
Ich hatte das schon gelesen, aber irgendwie hatte ich es in Erinnerung, dass die als Datei irgendwo liegt.GRUB 1 installiert die verfügbaren stage1.5 schon nach /boot/grub, genauso wie auch stage1 dort landet, aber in beiden Fällen ist das keine Datei, die beim Booten wirklich benutzt wird.
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.Was meinst du mit "würde mit zum Bootsektor gehören"? Ist nicht alles, was im FS liegt, außerhalb des Bootsektors?
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?
Also meine Seagate Dockstar hat das, wenn ich mich recht entsinne. Mein Toradex T20 hat es definitiv. Möglicherweise hat es auch mein Allnet 6500. (Die Geräte sind weit weg, daher kann ich das gerade nicht nachprüfen.) Sicher ist, dass FTDs die Zukunft sind.Zitat von: svenska... Flattened Device Trees (FTDs) ...Gilt für welche Boards und was ist mit den Boards die das nicht haben?
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.
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.Zitat von: svenskaFü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.
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? ;-)
Dann bau doch lieber eine bootloader-spezifische stage2, dieZitat von: svenskaDann 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.
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. :-P
FreeBSD kann neuerdings übrigens auch FTDs.Zitat von: svenskaFTDs solltest du nutzen, statt dir eine eigene /boot/device.hints (siehe FreeBSD) einfallen zu lassen.Genau das werde ich auch versuchen zu machen :)
Zu den Boards, die das nicht haben, zitiere ich mich selbst: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.ZitatSiehe für den ARM-Port vor, dass man FTDs auch statisch in den Kernel einkompilieren kann und du hast das Bootloader-Problem gelöst.
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).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.Zitat von: svenskaFü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.
Da hast du mich falsch verstanden, ich möchte dass dann uboot meinen Bootloader startet.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? ;-)
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.Dann bau doch lieber eine bootloader-spezifische stage2, dieZitat von: svenskaDann 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.
- 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 genauso "sicher" wie vorher auch. Es und nach Murphy wird es auch schief gehen ;)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. :-P
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.Ich glaube, für den PC hast du keine 20% übrig. Und extlinux (falls du den mit dem unbekannten Bootloader meinst) kriegt auch Multiboot hin, ist also keine zusätzliche Arbeit für dich.
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.
Abgesehen davon ist die Sinnfrage bei einem Bootloader genauso sinnlos wie bei einem OS.Mein Reden ;)
Darum habe ich ja auch gesagt, dass du das in den stage2 tun kannst, der ohnehin plattformspezifisch ist. Der Ansatz ist, auf ARM immer FTDs zu haben, weil die Anzahl der Boards mit FTD steigt. ;-)ZitatSiehe 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.
Da hast du mich falsch verstanden, ich möchte dass dann uboot meinen Bootloader startet.Dann würde ich das aber nicht mehr "Bootloader", sondern "OS-Loader" nennen, weil der Bootloader bleibt u-boot. ;-)
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.Dann bau doch lieber eine bootloader-spezifische stage2, dieAlso eine initrd will ich auf keinen Fall haben, nicht so wie Linux sie hat.
- 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
Damit fallen schonmal die Bootloader weg, welche nur Kernel+initrd laden können.Und damit die meisten vorhandenen.
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.Hier kann ich dir grad nicht folgen. Was denn zum Beispiel?
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.Dein Bootloader/OS-Loader muss jetzt aber auch geladen werden. Bei x86 tut das das BIOS, bei ARM der vorhandene Bootloader (hast du oben geschrieben). Um alles einheitlich hinzubekommen, wirfst du dann jede Information weg, die dir der Bootloader geben könnte und nimmst dann eine statische, boardspezifische Konfigurationsdatei, die die gleichen Informationen enthält. Hab ich das jetzt richtig verstanden?
Es funktioniert bei Millionen von Rechnern, warum sollte es bei dir nicht der Fall sein? Entweder, du hast deine unverschiebbaren Daten außerhalb des Dateisystems, was den Aufwand in die Höhe treibt - oder du hast sie im Dateisystem, was bei Blocklisten nicht ganz unproblematisch ist. (Und bei ext2 deutlich unproblematischer als bei FAT - wobei DEFRAG Systemdateien ebenfalls in Ruhe lässt.)ext2 kennt "immutable" als Dateiflag. Damit ist es nicht verschiebbar. Lässt sich mit root-Rechten natürlich entfernen. :-PAlso genauso "sicher" wie vorher auch. Es und nach Murphy wird es auch schief gehen ;)
Wieviele Bootloader gibt es denn, die du so in der realen Verbreitung mal gesehen hast?Zitat von: svenskaWenn 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.So nenne Er sie mir beim Namen. :-P
Von dem Bootloader den du verwendest habe ich z.B. auch noch nichts gehört.Syslinux ist eine Suite aus 4 Bootloadern: syslinux für FAT, extlinux für ext2/3/4, pxelinux für Netzwerkboot und isolinux für ISO9660/El-Torito. Letzteres kennst du von nahezu jeder Linux-Installations-CD.
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.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.
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.Dummerweise sind die Android-Systeme, an die günstig heranzukommen ist, nur per Reverse-Engineering zu analysieren. Zumindest der erste Port sollte auf ein Development-Board geschehen, und dort findest du eigentlich ausschließlich u-boot. Und wer hindert dich eigentlich daran, pro Bootloader (nicht pro Plattform!) eine stage2 zu schreiben, wenn du doch ohnehin für jede Plattform einen Bootloader schreiben willst? ;-)
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.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?
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.
Und damit die meisten vorhandenen.So viel zu deiner weiter unten geforderten Interoperabilität ;) Die Loader sind also alle Unix- bzw. sogar Linux-spezifisch :P
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.
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).
tyndur ist kein Unix und ich verbitte mir diese Unterstellung. :PZitat von: svenskaUnd damit die meisten vorhandenen.So viel zu deiner weiter unten geforderten Interoperabilität ;) Die Loader sind also alle Unix- bzw. sogar Linux-spezifisch :P
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 :Ptyndur ist kein Unix und ich verbitte mir diese Unterstellung. :PZitat von: svenskaUnd damit die meisten vorhandenen.So viel zu deiner weiter unten geforderten Interoperabilität ;) Die Loader sind also alle Unix- bzw. sogar Linux-spezifisch :P
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.
Jeder Bootloader, der nicht explizit Unterstützung für Fremdbetriebssysteme anbietet, ist auf ein Betriebssystem zugeschnitten... auch deiner.Jap, genau was ich meine ;)
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.