-
Notifications
You must be signed in to change notification settings - Fork 0
Hardware Support
In time, Orion should support multiple hardware platforms, based on both x86, and PowerPC (the Focus Architectures), using a combination of existing code, inherited from the L4Ka::Pistachio project, new code, and code ported from other projects, as well as other platforms, that may be of interest to users (the Bonus Architectures).
Because the codebase is old, in places, and undergoing renovation, not every hardware target that we intend to support is either functional, or capable of compiling, right now.
As an interim measure, the Orion/E product combines the Orion, and Enryo codebases (original L4Ka::Pistachio, with several community enhancements, and additional changes, that ran a different userland), so that the Orion userland can be ran on an enhanced Enryo kernel, containing some backported fixes (but not all of the NICTA contributions), on x86-64 systems. This also enables untested support for Extensible Firmware Interface image building.
In the NICTA_Pistachio_Mainline_FCL branch, initial work was undertaken to integrate the modifications from NICTA::Pistachio-embedded, that added support for DEC Alpha, ARM, MIPS64, SPARC64, and Itanium architectures, as well as a redesigned x86 port (called "IA32", in their code), and additional hardware products, to create a unified development stream of L4Ka::Pistachio, that takes advantage of engineering effort made over the course of several years, that didn't make it back into the main, public L4Ka::Pistachio repository.
This branch was merged back into the master branch, although the NICTA version of the x86 code is not actively being used, as it potentially introduces regressions, and the new architectures, and boards aren't currently integrated into the main kernel build system.
These additional hardware platforms (excluding x86) are considered Bonus Architectures, as whilst it would be nice to support them, to give new options to their users, we currently haven't got access to implementations of them, along with the toolchains, and enabling software, in order to bootstrap, and maintain them, at present.
These are maintained on a best-effort basis, and aren't guaranteed to work, but as a general rule, won't be purged from the codebase, as they provide a useful framework for maintaining portability, and useful historical information.
Code from the NICTA::Pistachio codebase, supporting some ARM architecture devices was imported, and needs backporting, to the Orion/E kernel tree, but there are currently no plans to make ARM a first-class, supported architecture, at this time.
We do, however have access to a Raspberry Pi Model B, and an OMAP3530 Evaluation Module.
Focus architectures receive the most support from Orion, as working hardware, and emulation is available within the project, and the code is primarily built on, and for them.
Currently, because of the aforementioned unification work, these don't currently build, and function reliably, unlike their ancestor repositories, although we're rapidly making progress on getting them to meet, and exceed the functionality expected.
The codebase has vestigial support for 32-bit, and 64-bit PowerPC machines (at least for G5/PPC970, POWER3, and POWER4, PPC440/750/604, 44X Embedded, BlueGene/P, and AMCC Ebony), as provided, but at present, not all of these targets can build, and it's unknown as to if they'd even still be functional, if they do. Open Firmware support is also present.
Ideally, we would fix up as many of these, as possible, at least to make them compile, but we can't easily obtain every piece of hardware that was supported by upstream Pistachio.
As part of the NICTA::Pistachio-embedded convergence initiative, many modifications were backported (some of which have temporarily introduced regressions, that we're working to resolve), to add hardware support, and features; support for compiling on Fedora, on POWER8 machines (in big-endian mode) was added; and, work is underway to unify redundant code supporting programmable interrupt controllers, Open Firmware support, and CPU variant detection, where possible, to simplify future maintenance.
The ambition of this project is to add at least support for new POWER8, and POWER9 machines (e.g. pSeries (we have access to QEMU's emulation, and MiniCloud), and Raptor Talos II), Cell (e.g. the Sony PlayStation 3 - the project already has a CECHL03 "fat NOR" model, running Rebug), and Espresso/Broadway (Nintendo Wii U/Wii - the project currently has one of each), and likely PowerPC Macintosh, and Amiga machines.
An iBook G4, upgraded to 1.1GB of RAM, and an AirPort Express card, running Ubuntu is available, and is currently being used, to test compiling code for Cell SPU, and 32-bit PowerPC systems.
The XBox 360's Xenon CPU could also be an interesting target, although it's necessary to do hardware modifications, in order to boot unsigned code on it, which makes it less desirable as a porting/build target. (One of these, along with the modchip, necessary to glitch the CPU, in order to run unsigned code, is available, within the project).
With work, it could be possible to support PowerPC 604e, and earlier CPUs, and the PReP specification, depending on availability of documentation, as we now have a Motorola PowerStack BlackHawk board, and power supply unit available.
If possible, we should be able to build Orion on any system running Linux (the project has been built on Debian/Ubuntu, and Fedora, at least), or FreeBSD.
Currently, Orion assumes that PowerPC machines run in Big Endian mode, and no support for Little Endian mode was ever added to the L4Ka::Pistachio codebase, since historically, only a handful of 32-bit systems (running PReP ports of Windows NT, and Solaris) ever defaulted to Little Endian mode, and some CPUs (e.g. the 970/G5 cores) don't implement support for it, at all.
However, with the advent of POWER9-based systems, IBM encourage adoption of Little Endian mode, to ease porting from x86, which seems to be mutually-exclusive, at compile-time (and, most likely, at runtime), so we would need to refactor carefully, if we wish to support both endianness modes, in the future.
Orion has a basic level of support for 32-bit x86 machines (the Enryo project (a predecessor, also based on Pistachio) could actually boot into a userland application), if the kernel is built with an old compiler, and an old version of GRUB is used, to boot it; and, the 64-bit version will at least build, although there are problems with MultiBoot, that prevents it from successfully booting into userland.
A handful of hardware peripherals (serial, and RTC) are known to be working, and Enryo had a rudimentary, polling-based keyboard driver, in its libio, which might be useful, for Orion. That project also had a working malloc() implementation, based on liballoc, which has also been integrated into Orion, as an interim measure, until we can properly switch to nedmalloc (which exposes a similar API, and implementation hooks, but has a more efficient implementation).
There is also a little code related to EFI, in the repository, but it is unknown if this even works, since it never gets built, and the build system isn't connected to it, at present.