Aros/Platforms/PPC support

From Wikibooks, open books for an open world
Jump to: navigation, search
Navbar for the Aros wikibook
Aros User Docs
Aros User Docs
Aros User FAQs
Aros User Applications
Aros User DOS Shell
Aros Dev Docs
Aros Developer Docs
Porting Software from AmigaOS/SDL
For Zune Beginners
Zune .MUI Classes
For SDL Beginners
Aros Developer BuildSystem
Specific platforms
Arm Raspberry Pi Support
Motorola 68k Amiga Support
Android Support
Linux and FreeBSD Support
Windows Mingw and MacOSX Support
Aros x86 Installing
Aros x86 Audio/Video Support
Aros x86 Network Support
Aros x86 Complete System HCL
Aros Storage Support IDE SATA etc
Aros Poseidon USB Support
x86-64 Support
PPC Power Architecture
Aros Public License

PPC Native Environment[edit]

AROS runs on Sam440EP thanks to the efforts of Michal Schulz. Boots on the SAM460ex thanks to Jason McMullan.

There is no native PowerPC-Mac Version of aros yet. You may try the darwin-hosted version under MacOSX or the linux ppc hosted under ppc-linux

Bootloaders (there is no grub but there is...)

Uboot => Bootloader => Bootable partitions => Configuration file => Operating system

Both bootloaders can read the AmigaOS configuration file, SYS:Kickstart/Kicklayout, and a configuration file on the Linux side, /boot/a1boot.conf (for SLB) or /menu.lst for Parthenope. So they both allow to boot either AmigaOS or Linux.

Hyperion's slbv2 cannot boot AROS and neither AROS nor AROS' slb supports SFS2. Use SFS instead. Keep in mind you will need to have your OS4 kernel files (kicklayout and modules) on SFS partition. AROS' Parthenope SLB (the same you probably use to boot linux) does not support JXFS yet. This ISO does require UBoot firmware (with implementation of the boota command!) to work.

You can either use AmigaOS 4.1 and Linux (SLBv2), or AROS and Linux (Parthenope or ub2lb). It's not possible to use AmigaOS 4.1 and AROS, unless you replace the SLB each time before booting the other OS.

Parthenope does not support booting AmigaOS 4.x. FFS can't be used as AmigaOS boot parition with it because it AFAIK it only supports short name FFS partitions (DOS\0-DOS\5), not the long name FFS ones (DOS\6 and DOS\7) which are required for an AmigaOS 4.x boot partition. SFS can't be used either because it only supports the AROS SFS (which is basically the same as the ancient AmigaOS SFS version 1.84), not the current AmigaOS versions of SFS.

  • parthenope supports FFS (all 8 formats of it, even if only DOS\6 and DOS\7 can be used for the AmigaOS boot partition), SFS\0, SFS\2, ISO9660, Linux (ext2fs/ext3fs) and network booting.
  • slbv2 support for JXFS filesystem, SFS2 filesystem and FFS2 filesystem

UB2lB listens to uboot and uses its list of boot devices. It tries to boot of media selected through the environment variables boot1, boot2 and boot3. As soon as it supports booting from desired media and as soon as the media contains boot/menu.lst file (the file defining the layout of kernel modules and other boot options) it will start booting from it.

setenv boot1 usb
setenv boot1 ide
setenv boot2 cdrom
setenv boot3 none

Still to be done.

Tested Hardware[edit]

Various PPC platforms use different firmwares, filesystems, etc which makes an all-in-one compatibility very difficult.

Desktop Systems[edit]

Name Chipset ACPI IDE SATA Integrated Gfx Audio USB Ethernet Wireless Opinion
Linux Hosted Works as at Feb 2012
PEGASOS II G4 1Ghz N/A AC97 STAC 9766 1.1 Marvell Discovery II MV64361 N/A Native not working - working via Linux hosted
AmigaOne SE G3 1.1 Untested native should work Linux hosted
AmigaOne XE G4 1.1 Untested native should work Linux hosted
Sam 440ep Flex AMCC440 ATI Radeon Mobility M9 Cirrus Logic CS4281 and AC97 Realtek ALC655 audio 1.1 with 2.0 to follow Booting and working OWB as at Feb 2011 but not booting May 2012,
Sam 460ex AMCC460 Silicon Image 4 SATA ports Sm502 AC97 ALC655 1.1 with 2.0 to follow NXP PCI controller Boots
Efika 5200B 400 MHz Freescale MPC5200B ATi Radeon PCI AGP 9250 AC97 IDT (formerly Sigmatel) STAC9766 OHCI Realtek RTL8201CL MII PHY thru a BestComm DMA controller N/A Working middle 2009 but not working August 2011
Amiga One X1000 1.8Ghz PA6T with and Xena FPGA Untested native should work Linux hosted
Power Mac G3 PowerMac2,1 Model Number M5521 400Mhz G3
Power Mac G3 PowerMac4,1 G3 600 Mhz ATi Rage 128 Untested native should work Linux hosted
Mac Cube G4 PowerMac5,1 Model Number M7886 Jul 2000 G4 433, 450, 500 Mhz ATi Rage 128 Untested native should work Linux hosted
iMac G4 PowerMac4,2 Model Number M6498 Jan 2002 G4 300-500 Mhz ATi Rage 128 15" 1024 x 768 Untested native should work Linux hosted
Apple iMac PowerMac4,5 Model Number M6498 Jul 2002
Powermac3,3 Dual G4 400 450Mhz ati rage 128 pro 2 1.1 ports Sawtooth 2 ports Fw400 - 7400 browser - 10.4 Tiger - itunes 9.2.1
Power Mac G4 PowerMac3,4 Model Number M5183 Jan 2001 833Ghz
Power Mac G4 PowerMac3,5 Model Number Jan 2002 733Mhz M8359LL/A 867Mhz 8360LL/A 933Mhz G4 - Dual 800MHz M8361LL/A 1GHz M8493 1920 x 1200 Nvidia 32Mb Geforce2 MX or 64Mb Geforce3 Quicksilver - 7400e browser
Power Mac G4 PowerMac3,6 M8570 Jan 2003 M5183 Jun 2003 1Ghz G4 Mirror Drive Door MDD - FW Firewire 800 - Leopard 10.5 - iLlife 09 with iMovie HD -
Power Mac G4 PowerMac6,1 G4 800 - 1.0 Ghz Radeon 9200 or Geforce 4 Ti Untested native should work Linux hosted
iMac G4 PowerMac6,3 1.25 Ghz G4
Powermac 7,2
Power Mac G5 PowerMac7,3 Model Number A1047 Dual 1.8Ghz
Apple iMac PowerMac8,1 G5 1.8 Ghz
Power Mac G5 PowerMac9,1 Single Core 1.6Ghz 1.8Ghz AGP Not working native - works Linux hosted
Power Mac G5 PowerMac9,2 Solo Core 1.8Ghz 2.0Ghz 2.3Ghz 2.5Ghz 2.7Ghz AGP Not working native - works Linux hosted
M9686xx/A M9686xx/B M9687xx/A M9687xx/B M9971xx/A M9971xx/B PowerMac10,1 Mac Mini G4 A1103 (Jan 2005) 1.25Ghz, (Sept 2005) 1.33Ghz and (Jan 2005) 1.42Ghz Radeon 9200 32MB VRAM AC97 Untested native should work Linux hosted
Mac Mini G4 M9687xx/B M9971xx/B A1103 PowerMac10,2 (October 2005 onwards) (24/27 Sept 2005) 1.5Ghz Radeon 9200 64MB VRAM AC97 Untested native should work Linux hosted
Power Mac G5 PowerMac11,1 A1117 PowerMac11, Dual Core 2.0Ghz - Dual Core 2.3Ghz - Quad Core 2.5Ghz PCI-E Not working native - works Linux hosted and with qemu
Power Mac G5 Not working native - works Linux hosted


Name Screen Chipset ACPI IDE SATA Gfx Audio USB Ethernet Wireless Opinion
Apple iBook Clamshell 12" 800 x600 G3 300-400 Mhz ATi Rage or Rage 128 1.1 Does not boot native - untested linux hosted
Apple iBook A1005 12" and 14" G3 500-800 Mhz ATi Rage 128 or Radeon 7500 Does not boot native - untested linux hosted A1036 45W PSU
Apple iBook G4 A1010 G4 800 to 1.33Ghz ATi Radeon 9200 or 9550 Does not boot native - untested linux hosted
Name Screen Chipset ACPI IDE SATA Gfx Audio USB Ethernet Wireless Opinion
Apple 2001 Powerbook3,1 A10
Apple 2001 Powerbook3,2 A10
Apple 2001 Powerbook3,3 A10 M8407 Dec 2001 667Mhz G4
Apple Powerbook 15" Jan 2001 Titanium PowerBook3,4 Model Number A1001 15.2" Widescreen 1280x854 400Mhz, 533 Mhz, 800Mhz, 1Ghz Rage 128 or Radeon 7500 32Mb or Radeon 9000 Airport Does not boot native - untested linux hosted A1021 65W PSU Charger
Powerbook4,1 G3 iBook 2nd Gen White 2001 G3 500Mhz N/A does not boot native - untested linux hosted
Name Screen Chipset ACPI IDE SATA Gfx Audio USB Ethernet Wireless Opinion
Apple Powerbook 17" Jan 2003 Aluminium PowerBook5,1 A1013 17" 1Ghz G4 (7447A) Radeon 7500 Does not boot native - untested linux hosted Combi Drive
Apple iBook 12.1" G4 Jan 2003 Aluminum Model ID PowerBook6,1 Model Number A1010 Jan 2003 12.1" 4ː3 aspect ratio 867MHz G4 Nvidia Geforce4 420 Go PMac PowerMac Snapper Dev 31 ohci Broadcom BCM5221 PHY Broadcom 43xx PowerPC 7455 (G4) 1.33Ghz processor - MacRISC3 Power Macintosh - Does not boot native - untested linux hosted Combo Drive
Apple iBook 12.1" G4 Sept 2003 Aluminum Model ID PowerBook6,2 Model Number A1010 12.1" 4ː3 aspect ratio Does not boot native - untested linux hosted Combo Drive
Apple Powerbook 15.2" Sept 2003 Aluminum PowerBook5,2 A1046 15.2" 16ː10 ratio Radeon 9600 64Mb Airport Extreme Does not boot native - untested linux hosted
Apple 2003 Powerbook6,3 Powerbook6,4 A10
Apple Powerbook 15.2" 2004 Powerbook5,3 A1046 15" Radeon 9600 64Mb Does not boot native - untested linux hosted
Apple 2004 Powerbook6,4 A10
Apple Powerbook 15.2" 2004 PowerBook5,4 Model Number A1095 Apr 2004 M9422LL 15" 1.5Ghz Radeon 9700 64Mb Does not boot native - untested linux hosted ADB trackpad and keyboard
Apple Late 2004 Powerbook6,5 A1054 12"
G4 iBook 2004 White A1055 6.4 G4 7447a 1.07GHz 1.2Ghz N/A does not boot native - untested linux hosted
Name Screen Chipset ACPI IDE SATA Gfx Audio USB Ethernet Wireless Opinion
Apple Powerbook 17" 2005 Powerbook5,5 A1085 17" 1.67Ghz Radeon 9700 RV360M11 Does not boot native - untested linux hosted MATSHITA DVD-R UJ-825 SuperDrive
Apple Powerbook 12.1" 2005 A1104 M9690LL 12" Does not boot native - untested linux hosted
Apple Powerbook6,6 A10 2005
Apple Powerbook6,7 1.42Ghz G4 Ati M12 9550 32MB Texas Instruments TAS3004 codec
Apple Powerbook6,8
Apple Inc Powerbook 15.2" Jan 2005 PowerBook5,6 Model Number A1106 M9677LL 1.5Ghz G4 Ati Radeon 9700 64Mb Airport Xtreme USB trackpad and keyboard
Apple Powerbook5,7 17 inch model DDR SDRAM
Apple Powerbook 15̊ PowerBook5,8 Model Number A1138 Oct 2005 M9969LL 15.2" 1440 x 900 1.67 GHz Radeon Mobility 9700 128Mb Air Port Extem USB trackpad and keyboard
Name Screen Chipset ACPI IDE SATA Gfx Audio USB Ethernet Wireless Opinion
Amiga One Netbook Lime PC type - does not boot native - untested linux hosted


AMCC440 CPU conforms the PowerPC E-Book specification and this version of AROS will not work any other type of PPC core. Since the AMCC440EP CPU does not maintain cache coherency and more AROS code uses CachePreDMA and CachePostDMA pair of functions.


The ELF header for AROS executable was a 'Type' field of REL, while the ELF header for Linux executable is EXEC:

$ readelf -h /bin/ls | grep Type
  Type:                              EXEC (Executable file)
$ readelf -h $AROS/C/Dir  | grep Type
  Type:                              REL (Relocatable file)

using a prebuild PPC toolchain, made with:

$ mkdir toolchain-ppc
$ cd toolchain-ppc
$ ../configure --target=sam440-ppc --with-aros-toolchain-install=/opt/aros
$ make -s crosstools


After attempts to use configure and various config files to generate makefiles in a graceful build approach, and having the config break on missing tools or failure to navigate the source code tree, found possible solution by copying .h include directory tree from ./Development/include/<many directories> down to "each" functional file directory.

And, yes, "gcc -I/<include path> -c..." or "gcc -I../../..<etc>" was also attempted but failed (not sure why nested .h's can not seem to navigate/reuse the -I<include> passed to cc1).

That said, there is issue of which stdio.h structure to use, and when to use native OS stdio or hosted AROS stdio, because:

AROS FILE struct def:

#ifndef __typedef_FILE
#   define __typedef_FILE
    /* I need a named struct for FILE, so that I can use it in wchar.h> */
    typedef struct __sFILE
    int fd;
    int flags;
    } FILE;

#   define _STDIO_EOF    0x0001L
#   define _STDIO_ERROR  0x0002L
#   define _STDIO_WRITE  0x0004L
#   define _STDIO_READ   0x0008L
#   define _STDIO_APPEND 0x0010L

while Darwin (using Mac OS X 10.5.8 for host) has following structure:

typedef    struct __sFILE {
    unsigned char *_p;    /* current position in (some) buffer */
    int    _r;        /* read space left for getc() */
    int    _w;        /* write space left for putc() */
    short    _flags;        /* flags, below; this FILE is free if 0 */
    short    _file;        /* fileno, if Unix descriptor, else -1 */
    struct    __sbuf _bf;    /* the buffer (at least 1 byte, if !NULL) */
    int    _lbfsize;    /* 0 or -_bf._size, for inline putc */

    /* operations */
    void    *_cookie;    /* cookie passed to io functions */
    int    (*_close)(void *);
    int    (*_read) (void *, char *, int);
    fpos_t    (*_seek) (void *, fpos_t, int);
    int    (*_write)(void *, const char *, int);

    /* separate buffer for long sequences of ungetc() */
    struct    __sbuf _ub;    /* ungetc buffer */
    struct __sFILEX *_extra; /* additions to FILE to not break ABI */
    int    _ur;        /* saved _r when _r is counting ungetc data */

    /* tricks to meet minimum requirements even when malloc() fails */
    unsigned char _ubuf[3];    /* guarantee an ungetc() buffer */
    unsigned char _nbuf[1];    /* guarantee a getc() buffer */

    /* separate buffer for fgetln() when line crosses buffer boundary */
    struct    __sbuf _lb;    /* buffer for fgetln() */

    /* Unix stdio files get aligned to block boundaries on fseek() */
    int    _blksize;    /* stat.st_blksize (may be != _bf._size) */
    fpos_t    _offset;    /* current lseek offset (see WARNING) */

Possibly explains the segment violation error on executing existing ppc binaries (from April 2011 build) which never successfully opens files, loads kernel modules and beyond "bus error":

./AROSBootstrap -c /Users/.../AROS-20110408-darwin-ppc-system/boot/AROSBootstrap.conf

Bus error

    • Note: required full filename path.

Q. absolute address 4 is put there by the AROS linker and Partenope just leaves it alone? No. On AROS SysBase is an ABS symbol in ELF file with special value. Parthenope (or AROSBootstrap, x86/x86_64 bootstrap, dos.library/LoadSeg or anything else that boots AROS) sees this special symbol during relocating the loaded ELF file and replaces it with address 0x00000004. This way the modules try to read the SysBase from that address.

Since at the stage where this symbol is resolved, there is no other AROS component working. THerefore we can neither put there address of some other SysBase pointer (there is none) nor do anything else than using just some arbitrary position in memory.

AROS and OS4 ELFs are different, don't see a reason why Partenope should not be able to handle each in a proper way. Not only the loaders for OS4 and AROS are quite independent on each other, but also OS4 does not use such ABS symbol in their ELF files. Not to mention they do not use REL elf files, but rather real ELF executables.

So can't we use another absolute address other than 4 on PPC, one that does not fall in the first memory page ? Let boot code then setup this (virtual) address to contain SysBase pointer? That would require modifying Parthenope in such a way as to either (a) break loading AmigaOS or (b) identifying and special casing AROS ELF as different from AmigaOS loads, or (c) use ld scripts to force SysBase to a specific memory address (resolving the symbol to a constant).

goSuper/goUser and krnAllocIntrNode & friends the only port that uses this is the Efika - most > everything else has these defines:

> #define goSuper() 0 > #define goUser() > #define goBack(mode)

Is this some dead code that should be removed?

I invented them in order to generalize existing code. Howewer, after that i introduced krnAllocXXX primitives. I intentionally introduced them, because in future (Michal suggested this) slab allocator would be used for these thing instead of exec's chunk allocator. AFAIR these things are inserted around actual Allocate() operation. This was done because PPC kernels have own memory area, accessible only in supervisor mode, for these things. This is why we do this. In fact i believe the thing could be refactored a bit. First, our KrnCreateContext() could accept extra argument, holding initialization taglist. Currently exec.library holds this fragment. After this, we could have a single function, which can be replaced on per-implementation basis. A generic implementation would call AllocMem(), then set up fields. However i would leave krnAllocXXX macros as they are, in order to simplify SLAB introduction. Another implementation could do own things. Additionally we could get rid of one more supervisor more call (exec's context initializer also has to become supervisor in order to access that memory).

IMHO on PPC .bss section should be allowed in ROM module and hard linked to absolute address maybe involving MMU to map it to that location. We *do* have .bss on modules on PPC, and we *do* use it. It's _unresolved_ symbols that Parthenope has funny ideas about.

On Sam440PPC, Parthenope loads each library/device itself from disk/network, and resolves the symbols *before* passing control to kernel/exec. So when Parthenope loads, say 'intuition.library', and sees an unresolved SysBase symbol, it assigns it 0x00000004 (just like AmigaOS would expect).

Right now (before I finish cleaning this up for PPC), the sam440 port (follow along in arch/ppc-sam440/kernel/intr.c:mmu_handler) has this horrid hack to try to fix up the instructions that access SysBase:

    /* SysBase access at 4UL? Occurs only with lwz instruction and DEAR=4
     * It is unfortunate that the Parthenope bootloader forces SysBase
     * to 4UL in loaded modules.
    if ((insn & 0xfc000000) == 0x80000000 && rdspr(DEAR) == 4)
        int reg = (insn & 0x03e00000) >> 21;

        DB2(bug("Parthnope patchup to R%d, SRR0=%p\n", reg, ctx->cpu.srr0));
        /* patch from lwz %rN => mr %rN, %r2 */
        insn = 0x7c401378 | (reg << 16);
        *(uint32_t *)ctx->cpu.srr0 = insn;
        /* Flush this new instuction out of the cache */
        asm volatile(
                "dcbst 0,%0; sync;"
                "icbi 0,%0; isync;"

Gross, right? This is not needed anymore with the local SysBase method. In the end, here are the fact as I see it with local SysBase:

  • No application code needed to be changed
 - Only 'compiler' code in autoinit, libinit, and arosc
 - Some rom/ library code (very little, in fact)
  • Fixed issues I had on two platforms that I support
  • Does not affect performance on other platforms
  • Reduced special cases in *three* programs that handled ELF loading
 - elf2hunk
 - dos/LoadSeg
 - bootstrap's ELF loader

Then SysBase should be in .bss and not unresolved. Correct. The .bss of *every* *single* *module*. A local SysBase for very modules. Which means n modules * 4 bytes data loss. If that is the price to pay to avoid pushing/popping SysBase on/from the stack for every INIT/EXIT function call, so be it. Passing SysBase in INIT/EXIT is needed so that setting up that local SysBase in the library's LibInit doesn't require a compile-time change, only a link time change.

struct ExecBase *SysBase;

... LibInit ... (struct ExecBase *,sysBase, A6)

  SysBase = sysBase;
  /* No need! I'm going to be linked into one big ELF! */

Parthenope doesn't load 'one big ELF' - it loads each module separately. Any reason why modules can't be joined into bigger ones with single SysBase if huge memory loss as computed above is really a problem ? 'huge memory loss'???!? 4 * 52 is *not* a huge memory loss. And being able have a user simply replace one module instead of having to rebuild an ELF is a significant advantage, in my opinion.

Make it conditional on AROS_STACK_GROWS_DOWNWARDS ? (although on all archs it currently seems to grow downwards) Is SP_OFFSET actually used, otherwise maybe best to remove it? AFAIR SP_OFFSET is needed e.g. on PowerPC architectures.

Entered OpenFirmware with the usual Command-Option-O-F key combination on boot chime, and listed the device tree with the usual "dev / ls" command.

Rentering OpenFirmware and constructing an adequate boot command (boot /pci@f2000000/usb@19/disk@1:2,\\:tbxi) booted

1.- USB booting is supported by all Mac OS X bootloaders, but Mac OS X <= 10.3 do not load the USB MSC drivers at boot and the kernel is then unable to find the root volume. 2.- USB booting is unsupported at all by Mac OS 9, because it requires Toolbox drivers and they only exist for ATA, ATAPI and SCSI. 3.- USB booting is supported by all Linux distributions, expect to load Yaboot configuration file from "cd:" device alias, and you must point that to your exact USB device in OpenFirmware for Yaboot to work. 4.- If your last boot disk is an USB one, it DOES appear on the boot menu. If it's not the case, it will never do, and you must boot manually from OpenFirmware.

boot usb1/@1:1,\boot.img bd=umsd0 rd

nvalias ud /pci@f2000000/usb@1b/device@1/disk@0:5 setenv boot-device ud:,\\:tbxi