Portierung von Darwin auf ARM-Prozessor?

  • Portierung von Darwin auf ARM-Prozessor?

    Nachdem es von Sharp den neuen Zaurus C3000 gibt (Features: 480x640 Touch screen, 4GByte Harddisk, 128MByte RAM, 400MHz Xscale, ARM-Linux - d.h. erfüllt Minimalaforderungen von MacOS X 10.0), besteht grundsätzlich die Möglichkeit, das Linux durch einen Darwin-Kernel + File-System zu ersetzen.

    Leider habe ich praktisch keine Ahnung von Darwin (ausser dass es der Kernel von MacOS X ist und auf Mach basiert) und deshalb interessiert mich ob schon mal jemand mit Darwin und evtl. einer Portierung auf den ARM-Prozessor Erfahrung gesammelt hat.

    Besten Dank,
    hns

  • Hallo,

    Erfahrung mit ARM und Portierung von Betriebssystemen (Linux/iPaq) wären bei mir vorhanden, wirkliche Erfahrung mit der Portierung von Darwin hat wohl außerhalb von Apple kaum jemand (lasse mich aber gerne eines Besseren belehren ;-)). Auf jeden Fall ein reizvolles Projekt.

    Ist schon klar, ob Sharp die kompletten Sourcen für den C3000 Linux-Kernel offengelegt hat oder evtl. gar Hardwarespezifikationen existieren?

    Wenn mir jemand so ein Teil sponsort ;) könnte ich durchaus schwach werden und mal schaun, wie weit es wirklich mit der Portabilität von Darwin hin ist. Bei ARM kommen natürlich noch so "Kleinigkeiten" wie fehlende Floatingpoint-Hardware dazu - die meisten Probleme in der Richtung dürfte aber auch schon NetBSD gelöst haben und als "Organspender" herhalten können...

    Michael

  • Prinzipiell, wie auch bei Linux, sollte es bei dem Mach Kernel einen Systemabhaengigen Teil geben (Darwin bzw. Mach Kernel gibts ja fuer x86 auch). Alles, was darauf aufbaut ist wahrscheinlich weniger das Problem. Sollte also machbar sein.
    Leider kenn ich mich mit Mach auch zu wenig aus.

  • Auf jeden Fall ein reizvolles Projekt.


    In der Tat! Deshalb habe ich ja die Frage gepostet :)

    Ist schon klar, ob Sharp die kompletten Sourcen für den C3000 Linux-Kernel offengelegt hat oder evtl. gar Hardwarespezifikationen existieren?


    Hier ist die Situation gemischt. Der Linux-Kernel ist noch nicht offengelegt, aber das dürfte nicht all zu lange dauern. Und so wie es aussieht, ist der C3000 nicht allzu verschieden vom C860 (außer dem Harddisk-Drive, aber das ist "nur" ein zweiter CF-Slot).

    Hardware-Specs sind meines Wisses relativ dünn gesäht, seit das Developer-Netz dichtgemacht wurde. Und nicht alles konnte gerettet werden. Es gibt aber noch das OpenZaurus und das pdaXrom-Projekt. Beide müssten eigentlich ziemlich tief in die Hardware eingestiegen sein. Ich glaube mich auch zu erinnern, dass der C860 einen eigenen Grafikchip mit Beschleuniger hat, der speziell beim pdaXrom verwendet wird.

    Wo es aber sicher ein Problem geben wird ist beim Treiber für die SD-Karte. Die scheint Sharp nur als compiliertes Kernel-Modul rauszugeben (Lizenzgebühr für SD-Interface).
    Wenn mir jemand so ein Teil sponsort ;)


    Muss ich mal schauen was sich vielleicht machen läßt (versprechen kann ich aber nichts). Noch ist er ja nicht in Europa lieferbar (aber bald...). Details sollten wir aber per Private Mail diskutieren.

    Bei ARM kommen natürlich noch so "Kleinigkeiten" wie fehlende Floatingpoint-Hardware dazu - die meisten Probleme in der Richtung dürfte aber auch schon NetBSD gelöst haben und als "Organspender" herhalten können...

    Und es gibt glaube ich im gcc 3.4 eine neue Floatingpoint-Library für den ARM die wesentlich schneller sein soll.

    -- hns

  • Original von asrael
    Prinzipiell, wie auch bei Linux, sollte es bei dem Mach Kernel einen Systemabhaengigen Teil geben (Darwin bzw. Mach Kernel gibts ja fuer x86 auch). Alles, was darauf aufbaut ist wahrscheinlich weniger das Problem. Sollte also machbar sein.

    Darwin/Mach hat soweit ich es verstehe sogar noch klarere Strukturen. Der kritische Teil wird wohl der Microkernel sein. Der Rest (POSIX, BSD, Device Driver, CoreFoundation, usw.) baut sich darum herum.

    Ergänzung: vom "Rest" die benötigten Device Drivers von Linux auf .kext zu portieren dürfte aber ein eher großer Aufwand sein.

    -- hns

  • Darwins Arm - About NetBSD/hpcarm

    nabent ich hab mich mal ein bischen schlau gemacht es gibt einige
    entwickler die sich mit verschiedenen portierungen beschäftigen

    fand das hier ganz interessant:

    About NetBSD/hpcarm

    NetBSD/hpcarm brings the NetBSD operating system to Intel StrongARM based Windows CE PDA machines. Currently, the SA1110 processor is supported.


    NetBSD/hpcarm

    gruss

  • Die NetBSD/hpcarm-Portierung ist sicher eine gute Informationsquelle.
    Allerdings ist die Portierung auf andere Geräte als den Jornada noch nicht wirklich weit fortgeschritten, auf dem iPaq 36xx z.B. funktioniert das Display nicht. Hier ist Linux deutlich weiter, Verwendung von Linux-Code in einer Darwin-Portierung ist aber "dank" der GPL leider zumindest problematisch, potentiell unmöglich. Was nicht heisst, dass man nicht Informationen über die Funktionsweise der Hardware aus den verfügbaren Linux-Sourcen extrahieren dürfte.

    Ich hab mir einige Dinge auch mal näher angeschaut:

    - Das erste Problem für die ARM-Portierung ist, dass es keine Compiler-Toolchain für arm-darwin-macho gibt (nur ELF/COFF/a.out), da müsste man also zumindest eine Config für gcc und binutils basteln. Alternativ könnte man Darwin um das ELF-Binärformat erweitern, was aber aufwendiger sein dürfte.

    - Floatingpoint-Emulation sollte nicht wirklich schwierig sein und im Kernel-Mode zumindest auch nicht notwendig

    - Grundlegende Treiber, z.B. für eine erste Portierung auf iPaq, wären nicht so aufwendig (Display, Touchscreen, serielle Schnittstelle, Flash). Optional wären Dinge wie Sound, Joypad/Buttons, IrDA, PCMCIA etc.

    - Im Userland wird es sicher noch weitere Probleme mit libc etc. geben. Das ist aber noch weit entfernt ;)

    Michael

  • porting

    Original von cuby
    Alternativ könnte man Darwin um das ELF-Binärformat erweitern, was aber aufwendiger sein dürfte.

    Michael


    hallo michael ,

    sehr interessant was du das so erzählst , ich habe diese sache mit dem
    ELF binärformat schon öfter gelesen , hier noch etwas von meiner seite:
    I'm a computer science student, and use a small
    toy operatin system (to test different proccess estragies, like monitors, signal, some OS thread strategies, etc, etc), well, it's small and
    just for education purpose (very cool by the way), it's name, Nano System.
    (dcc.uchile.cl/~lmateu/CC41B/download/nSystem2001.tgz)

    Ok here comes the problem, it's a very low level program, soo, a small part is writted directly in assembler, and has versions for Solaris (sparc) and Linux (x86). This assebler code is the only part that is no ANSI C, and it's for handling the memory stack, my idea is to port this assembler part into Mac OS X :) ....

    Where in darwin can I see the code for the memory stack handling?, there is some library, or file where i can find the assembler code, for something like that (handle memory stack), for adapt a version using the PPC processor registers, and any hardware specific code?, I guest just need a simplify version, but the mac os x version should be similar to the code i'm looking for...


    LAP, the Linux Application Platform, is a Linux emulation package for BSD/OS which uses a "little language" [Salu98] to describe transformations from Linux data types and values to BSD/OS data types and values, and vice versa. The little language simplifies and regularizes the specification of transformations, making the emulation easier to maintain. This paper describes the language and its place in the framework of LAP.


    usenix.org/publications/librar…x2000/freenix/seeley.html

  • RE: porting

    Das Paper zu LAP ist wirklich interessant, danke für den Hinweis! (Sogar relevant für meine Diss ;) ).

    Leider scheint mal an die Software nicht mehr ranzukommen "dank" WindRiver, die BSDi aufgekauft haben. Für eine Umsetzung ELF <-> Mach-O wäre LAP zwar nicht geeignet, für ein paar andere Sachen (eben Syscall-Matching und so) aber allemal. Naja, mal in der BSDi-Newsgroup nachfragen, ob vielleicht doch jemand den Source rausrücken mag...

    Hier ist übrigens ein erster Testbericht vom Sharp Zaurus C3000:

    i4u.com/section-viewarticle-71.html

    Michael

  • RE: porting

    Original von cuby
    Das Paper zu LAP ist wirklich interessant, danke für den Hinweis! (Sogar relevant für meine Diss ;) ).

    Leider scheint mal an die Software nicht mehr ranzukommen "dank" WindRiver, die BSDi aufgekauft haben. Für eine Umsetzung ELF <-> Mach-O wäre LAP zwar nicht geeignet, für ein paar andere Sachen (eben Syscall-Matching und so) aber allemal. Naja, mal in der BSDi-Newsgroup nachfragen, ob vielleicht doch jemand den Source rausrücken mag...

    Hier ist übrigens ein erster Testbericht vom Sharp Zaurus C3000:

    i4u.com/section-viewarticle-71.html

    Michael


    hi nichael , bei mir ist es leider so das mir die tiefgreifenden kenntnisse
    über das thema und prozesse dieser dimension fehlen, aber ich schnappe in diversen listen (unix porting darwin immer etwas auf wie z.b.


    Hello all,

    recent discussions make me wonder how much work it whould be to run
    binaries from other OS's on Mac OS X. Surely, it's an option to
    emulate a full computer (VirtualPC, qemu, ...) but this is resource
    starving and surely not the optimum for running a simple command line
    tool.

    To make the thing not too hard let's assume, the binaries are compiled
    for a compatible processor (PPC) and some sufficiently compatible OS.
    Let's say, binaries for FreeBSD/PPC, LinuxPPC or IBM's AIX.


    What else does one need besides some replacement for dyld? Some sort
    of ELF -> mach-o adaptor? Is relinking an ELF binary as mach-o binary
    possible? How does a thing like LaunchCFMApp work? Is there some other
    prior art available as open source?


    Take a look at how FreeBSD emulates Linux to get an idea of the work
    here. You're going to need:

    - - An ELF Loader
    - - System Call Emulation
    - - Library Emulation (at least libc)

    If you want to work on this, start with getting FreeBSD/ppc ELF
    executables to run on OSX. That'll have the least work you'll need to
    do. Linux/ppc support will require more translation, and emulation of
    at least glibc.

    I did the FreeBSD/alpha OSF/1 compat code, and ported linux compat to
    FreeBSD/alpha.. Let me make a few clarifications:

    First, there's no library emulation. The way it works in FreeBSD is
    the image activator sits in the kernel and handles the foreign binary
    by installing a different syscall vector for the process executing the
    foreign binary. System calls which take the same arguments in the
    same order are passed through. System calls which take different
    arguments, the same arguments in different order, etc, are translated
    and passed through to the native functions. System calls which do not
    exist at all are emulated.

    The linux (or OSF/1, or eventually MacOSX ;) libraries, runtime
    dynamic loader, and support files are installed in a separate path
    (/compat/linux, /compat/osf1, etc) and name lookup syscalls first
    check the compat path so that the foriegn libs are found first.
    (open(/lib/libc.so.6) returns a handle to /compat/linux/lib/libc.so.6)

    The BSDI guys took a different, totally userspace approach (see the
    LAP paper from the 2000 USENIX --
    usenix.org/publications/librar…x2000/freenix/seeley.html). LAP
    depends on the host OS being able to at least have an ELF loader,
    which MacOSX doesn't. So if you went that route, you'd at least need
    to add an ELF loader.

    And it would be SO NICE to have an ELF loader. Our product requires
    overriding malloc. This is an incredible PITA on MacOSX with its
    Mach-O toolchain. We were joking it would be easier to port an
    ELF toolchain to MacOSX than it would be to get our code to work right
    in all scenaries with Mach-O.




    Umsetzung ELF <-> Mach-O werd ich mal in ruhe erruieren.

    Das ist echt n feines teilchen der sharp Zaurus
    , auf so einem liese sich doch Symbian problemslos
    installieren gell?

    gruss

    marc 8)

  • nabent michael,

    wow jetzt hab ich mir die sache mir dem "system" mal genauer angesehn

    Metrowerks also has a forthcoming announcement to be made about the former Embedix Plus for Digital TVs program. Baratta described to me some of the things being done with digital televisions. I hadn't thought about it, but these newer televisions have operating systems. Many of these TVs are being built with some pretty serious hardware, including processors of several hundred megahertz and video cards that would do well playing Quake 3 on PCs. TV manufacturers are looking to put that hardware to work, creating value added features from the potential of such hardware. Baratta says it may not be long before your TV is a gaming console of its own.



    At LinuxWorld, AMD and Metrowerks are demonstrating a pre-release version of OpenPDA, a Linux-based software platform aimed at PDAs and smartphones using AMD's Alchemy RDK.





    Qtopia features:
    Windowing system
    Synchronization framework
    Development environment
    Localization support
    Games and multimedia
    PIM applications <------ was heisst das?
    Input methods
    Personalization options
    Productivity applications
    Internet applications
    Java integration
    Wireless support


    oder:

    Qtopia PDA contains a full complement of applications for business productivity, personal information management, Internet content, entertainment, and synchronization with desktop PCs.

    gruss


    *träum*

  • RE: Sharp Zaurus C3000

    weiss einer welches system auf dem sharp läuft?
    also freebsd, sybian oder so?

    Ausgeliefert werden sie (Beispiel C860) mit "Metrowerks OpenPDA 1.0" mit
    * Linux kernel 2.4.18
    * Qtopia 1.5.4
    Zum Compilieren braucht man noch den alten gcc 2.95.3

    Es gibt eine Reihe von ROMs die auf o.g. System aufsetzen und zwei andere Projekte mit modernerem Kernel und gcc:
    * Open Zaurus
    * pdaXrom

    Ganz andere Systeme gibt es bisher nicht.

    -- hns

  • danke hätte ja auch der PIM sein können
    Tja so ist es mit den Abkürzungen :D Alle sind 3 oder vierfach belegt.

    Nochwas: Hier die Login-Meldungen vom C3000:

    Quellcode

    1. INIT: version 2.78 booting
    2. INIT: Entering runlevel: 4
    3. INIT: Sending processes the TERM signal
    4. Lineo uLinux
    5. Kernel 2.4.20 on armv5tel
    6. zaurus login :

    -- hns

  • Hier die Login-Meldungen vom C3000:

    Quellcode

    1. INIT: version 2.78 booting
    2. INIT: Entering runlevel: 4
    3. INIT: Sending processes the TERM signal
    4. Lineo uLinux
    5. Kernel 2.4.20 on armv5tel
    6. zaurus login :

    -- hns


    wow ist das cool, DU HAST EINEN OK!!!!

    jetzt müssen wir nur noch für michael einen sammelfond aufmachen
    und ihn dann überreden

    8) :P

  • wow ist das cool, DU HAST EINEN OK!!!!

    Nee,
    habe leider noch keinen, aber ich weiss wo man die benötigte Infos über den C3000 bekommt :D

    Momentan schlage ich mich an einem C860 mit einem vertrackten "Illegal Instruction crash" in dlopen() unter Linux rum. Das brauche ich damit NSBundle auf dem Zaurus zuverlässig funktioniert. Mit einem Darwin-Kernel und dyld() auf dem Zaurus wäre das gar kein Problem...

    jetzt müssen wir nur noch für michael einen sammelfond aufmachen
    und ihn dann überreden

    Es dauert auch nicht mehr lange: Trisioft.de und Handheld-Linux.com haben sie in wenigen Tagen im Programm. Aber soweit ich ihn verstanden habe ist er momentan noch an seiner Diss gebunden.

    Mit dem Fonds ist eine gute Idee. Frage nur wie man das verwaltet
    Stiftung - zu teuer
    Verein - muss man erst eine Satzung aufstellen, Vorstand und Kassenwart wählen und sich 1mal im Jahr treffen
    Projekt bei Sourceforge mit Donations-Option - das läuft ins Henne-Ei-Problem: ohne C3000 kein Code & ohne Code keine Spende & ohne Spende kein C3000
    ppcnux.de/index.php - vielleicht haben die Interesse?

    Oder, ich muss mich mal mit meinem Steuerberater beraten (welch ein Sprachstil hätte mein Deutschlehrer gesagt!). Vielleicht lohnt es sich ja allein aus steuerlichen Gründen ein Gerät zu verleihen...

    -- hns