Portierung von Darwin auf ARM-Prozessor?

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Original von cuby
    [URLhttp://developer.apple.com/documentation/Darwin/Conceptual/KernelProgramming/index.html[/URL]
    l

    Super! Am besten finde ich den Abschnitt "Building Your First Kernel"... Muss ich wenn ich mal ein paar Stunden Zeit habe ausprobieren und schauen was da eigentlich alles passiert. Und mal sehen, wie weit man mit dem ARM-Crosscompiler kommt :)

    -- hns

  • ... "Building Your First Kernel"... Muss ich wenn ich mal ein paar Stunden Zeit habe ausprobieren...

    habe alles geladen und lt. Anleitung angefangen zu compilieren. Bin aber ziemlich schnell bei

    Quellcode

    1. make RC_OS=macos kld_build
    2. ...
    3. In file included from ../layout.c:54:
    4. ../../include/mach-o/rld.h:30:29: streams/streams.h: No such file or directory
    hängengeblieben... Braucht also noch mehr Stunden Zeit :)

    -- hns

  • Man muss beim Bootstrappen ein bischen mehr sudo machen und dann werden die Tools erstellt

    Quellcode

    1. ...
    2. cd ../../Libstreams-version
    3. make
    4. sudo make install
    5. cd ../cctools-version
    6. ...
    Nach ca. 30 Minuten fleissig compilieren bleibt es jetzt bei

    Quellcode

    1. /bin/sh: line 1: /usr/local/bin/kextsymboltool: No such file or directory
    2. make[3]: *** [/Volumes/Data/hns/Documents/Projects/OS-X-Lite/System/Sources/Darwin/xnu-517.9.4/BUILD/obj/RELEASE_PPC/System6.0.symbolset] Error 1

    hängen. Anscheinend fehlt trotzdem noch das kextsymboltool...

    Ein find -exec fgrep hat es aber in den lt. Anleitung geladenen Sourcen nicht gefunden. Benutzt wird es nur in xnu-517.9.4/config/Makefile.

    -- hns

  • So, jetzt weiß ich wenigstens, warum mein xnu hier "rumzickte" - ich hatte nicht ein offizielles Release auf der Platte, sondern irgendeinen relativ aktuellen Stand aus dem cvs. Da scheint wohl was im Argen zu liegen. Ich bekomme die cctools grade auch nicht compiliert, werde morgen nochmal genauer reinschauen.

    kextsymboltool findet sich übrigens in den kext_tools-42. Das ist zur Abwechslung mal ein ProjectBuilder-Projekt. Und produziert auf Anhieb mal einen Stapel Fehler wegen eines nicht gefundenen Headerfiles "IOKit/kext/KXKextManager.h". Das findet sich auf der Platte meines Powerbooks auch nicht. Argh, wo haben sie das nur wieder versteckt?

    Michael

  • Ha, ich hab jetzt einen fertig compilierten Kernel. Kaum macht man's richtig, schon geht's. Die Anleitung war sehr hilfreich, auch wenn ich bei den cctools teilweise (warum auch immer) die Teilprojekte bauen musste, indem ich ein cd in das Unterverzeichnis gemacht und dort make aufgerufen habtte. Naja, Kleinigkeiten ;-).

    Mal sehn, ob der Kernel mit der OS X-Version von mol (Mac-on-Linux) bootet...

    Michael

  • So,
    ich habe es auch geschafft. Es fehlten noch zwei Packages - und das Ganze dann neu compilieren scheiterte zuerst daran, dass manche mv-Befehle nur einmalig funktionieren (besser wäre cp...).

    Ich habe alles einfach in ein Schellscript 'make.sh' gesteckt, das man auch ggf. mehrfach aufrufen kann (siehe Anhang).

    Interessanterweise ist der generierte Kernel 7.6 ein bischen kleiner (3855012 bytes) als der 10.3.6 (3863440 bytes). Keine Ahnung was da weggelassen wird.

    Für einen ARM-Kernel sieht das eigentlich ganz gut aus, da Binaries erfahrungsgemäß nur etwa 50-60% der Codelänge eines PowerPC benötigen. Das heisst man käme mit 1,5-2MByte hin. Der Sharp ARM-Linux-Kernel ist glaube ich knapp 1.5MByte groß.

    Und nun fängt erst der schwierigste Teil an - mal vorsichtig den ARM-gcc anschmeissen. Da kann natürlich beliebig viel schiefgehen und mehr als ein paar Centimeter weit werde ich wohl nicht kommen :)

    Hier ein paar Gedanken für mögliche Barrieren:
    1. Darwin verwendet Mach-O - ARM-gcc&ld erzeugen ELF, d.h. manche Tools (kextsymboltool) werden scheitern
    2. ich habe im Moment nur einen gcc2.95.3 und Darwin verwendet sicher gcc 3.3 oder 3.4 (was ist mit 64 bit pointer und integers?)
    3. in den Makefiles sind wahrscheinlich PowerPC-spezifische und MacOS-spezifische Compilerflags gesetzt
    4. vielleicht gibt es den einen oder anderen Header nicht
    5. ist sicher ein bischen PPC Assemblercode für die Hardware-Abstraction dabei

    Jedenfalls genügend Möglichkeiten.

    -- hns

  • Hier ein paar Gedanken für mögliche Barrieren:
    1. Darwin verwendet Mach-O - ARM-gcc&ld erzeugen ELF, d.h. manche Tools (kextsymboltool) werden scheitern


    Ja, auf jeden Fall. Hier gibt's zwei Möglichkeiten - entweder Darwin davon zu überzeugen, als ELF-Kernel zu laufen und einiges am Build-Prozess und den Tools umbauen oder eine bfd-Beschreibung für gcc/binutils für arm-macho bauen. Letzteres halte ich für die sinnvollere Lösung, zumal man die Toolchain eh für die Darwin Userland-Pakete benötigt.

    2. ich habe im Moment nur einen gcc2.95.3 und Darwin verwendet sicher gcc 3.3 oder 3.4 (was ist mit 64 bit pointer und integers?)


    Mit 2.95 dürfte ein aktueller Darwin nicht glücklich werden. Im Moment wird glaube ich ein 3.3 vorausgesetzt. Ein aktueller gcc Crosscompiler mit ARM-Target sollte sich evtl. recht gut aus NetBSD-Quellen bauen lassen - die Toolchain baut zumindest auch auf OS X, habe mal daraus einen x86-Crosscompiler auf Panther gebaut.

    3. in den Makefiles sind wahrscheinlich PowerPC-spezifische und MacOS-spezifische Compilerflags gesetzt


    Hält sich in Grenzen, der Darwin-Kernel compiliert ja auch für x86, so dass da ziemlich viel schon sauber getrennt ist. Der ARM-Support muss natürlich an vielen Stellen noch rein, die sollten sich aber relativ leicht identifizieren lassen (auch wenn man immer irgendeine vergißt ;-)).

    4. vielleicht gibt es den einen oder anderen Header nicht


    Da bin ich mir fast sicher :)

    5. ist sicher ein bischen PPC Assemblercode für die Hardware-Abstraction dabei


    Ja, aber der ist dank vorhandener x86-Portierung auch schon gut modularisiert. So arg viel Assembler ist auch nicht dabei, größere Sorgen macht mir der C++-Code in libkern, IOKit und libsa. Aber erstmal nen Crosscompiler bauen, sonst hilft das alles nichts.

    Michael

  • Mit 2.95 dürfte ein aktueller Darwin nicht glücklich werden. Im Moment wird glaube ich ein 3.3 vorausgesetzt. Ein aktueller gcc Crosscompiler mit ARM-Target sollte sich evtl. recht gut aus NetBSD-Quellen bauen lassen - die Toolchain baut zumindest auch auf OS X, habe mal daraus einen x86-Crosscompiler auf Panther gebaut.

    So, hier schon mal Links wo jemand mit dem gcc-3.x als Cross-Compiler für für uCLinux erfolgreich war:
    ukos.ch/site/ef_cross.html bzw. klingler.net/toolchain_links.php und gnude.sourceforge.net/

    -- hns

  • Ja, auf jeden Fall. Hier gibt's zwei Möglichkeiten - entweder Darwin davon zu überzeugen, als ELF-Kernel zu laufen und einiges am Build-Prozess und den Tools umbauen oder eine bfd-Beschreibung für gcc/binutils für arm-macho bauen. Letzteres halte ich für die sinnvollere Lösung, zumal man die Toolchain eh für die Darwin Userland-Pakete benötigt.

    Alles auf ELF umstellen hat vermutlich tiefgreifende Auswirkungen - nicht zuletzt dyld. Ich habe gerade auf Linux meine Erfahrungen mit dlopen() gesammelt und um eine Fehler zu finden tief in die Sourcen geschaut. dlopen() macht ja im Prinzip einen mmap() und durchsucht dann die Symboltabelle der shared-library. Und das Mach-O-Gegenstück macht es sicher ähnlich. Und das alles umstellen halte ich auch für ziemlich aufwe(ä)ndig. Dann lieber doch den Compiler&Tools.

    Hier ein Link für die Mitleser: developer.apple.com/documentat…/chapter_1_section_1.html

    -- hns

  • eine bfd-Beschreibung für gcc/binutils für arm-macho bauen.

    Gibt es anscheinend auch schon - und ist vielleicht eine weitere Antwort auf die Frage neulich nach einer Library um Mach-O zu manipulieren. Hier ein paar ergoogelte Links:

    sources.redhat.com/ml/binutils/2003-11/msg00244.html
    lists.gnu.org/archive/html/gcl-devel/2003-10/msg00161.html
    opensource.apple.com/darwinsou…/gdb-292/src/bfd/mach-o.c

    Hier habe ich noch etwas gefunden was beschreibt wie BFD funktioniert: cs.utah.edu/dept/old/texinfo/bfd/bfd.html

    -- hns

  • Pistachio microkernel

    nabent,

    fand noch etwas :

    L4Ka::Pistachio is the latest L4 microkernel developed by the System Architecture Group at the University of Karlsruhe in collaboration with the DiSy group at the University of New South Wales, Australia. It is the first available kernel implementation of the L4 Version 4 kernel API (currently code-named Version X.2), which is fully 32 and 64 bit clean, provides multiprocessor support, and super-fast local IPC.


    Pistachio microkernel

    und

    Libsndfile

    ibsndfile is a C library for reading and writing files containing sampled sound (such as MS Windows WAV and the Apple/SGI AIFF format) through one standard library interface. It is released in source code format under the Gnu Lesser General Public License.
    The library was written to compile and run on a Linux system but should compile and run on just about any Unix (including MacOSX). It can also be compiled and run on Win32 systems using the Microsoft compiler and MacOS (OS9 and earlier) using the Metrowerks compiler. There are directions for compiling libsndfile on these platforms in the Win32 and MacOS directories of the source code distribution.


    chüss

  • So,
    hier die neuesten Neuigkeiten für das Projekt:

    1. Es hat sich jemand von ARM Ltd. dafür interessiert, wie denn der Projektstatus ist

    2. Ich habe eine englische Projektseite dsitri.de/wiki.php?page=Darwin%20on%20ARM
    und ein eigenes Forum dsitri.de/phpBB2/viewforum.php?f=24 eingerichtet

    3. Mein C860 für 'cuby' (Michael) reserviert - sobald ich mit anderen Projekten komplett auf den C3000 umgestiegen bin

    4. Schließlich brauchen wir noch mehr Mitstreiter - bitte also in den einschlägigen Foren und Mailinglisten herumfragen und kräftig die Werbetrommel rühren!

    -- hns