[haiku] Re: Haiku for Raspberry Pi?
- From: Travis Geiselbrecht <geist@xxxxxxxxxx>
- To: haiku@xxxxxxxxxxxxx
- Date: Sun, 4 Sep 2011 16:55:29 -0700
On Sun, Sep 4, 2011 at 2:06 PM, Ivan Vodopiviz <merkoth@xxxxxxxxx> wrote:
> Besides endianess and the obvious difference in performance, what are
> the main difficulties of porting Haiku to ARM? Does make extensive use
> of x86 assembly?
All in all the main difficulties will be less of the ARM architecture
bits and more of the system drivers that will be needed for each of
the SoC (system on chips) that it would be ported to. TI OMAP4 for
example (which a pandaboard has) is almost completely different from
the broadcom chip in the Raspberry Pi. Each of those SoC families are
basically a completely different system design. The only real
commonality is the instruction set. If you look in the linux kernel
source tree, for example, the arch/arm dir is a monster compared to
the rest of the arches since they support a zillion different SoCs.
Different timers, different interrupt controllers, memory controllers,
busses, etc.
We'd also need to probably develop some new stacks and technologies.
SD/MMC comes to mind, and perhaps some raw NAND, generic i2c, generic
i2s. Power management will be somewhat more fine grained than on a PC.
Another biggie is the fact that most ARM implementations are not cache
coherent with regards to IO, so there may need to be a lot more cache
flushes jammed into various parts of any generic driver stacks. Some
assumptions about the order of device operations may need to be
reevaluated.
Anyway, my personal suggestion is to start with an ARMv7-a class cpu
(cortex-a8 or cortex-a9). The mmu, cache operations, and SMP is well
standardized in ARMv7. ARMv6 is a bit more loose with some of that,
and requires a bit more per-core code. A Raspberry Pi appears to be an
ARM11 (probably an arm1136jf-s) which is an ARMv6 implementation.
However, as long as you start with most ARMv6 and ARMv7 based designs
you wont have to deal with the real monsters: TLB and cache being non
coherent. Earlier arms (ARMv4,ARMv5) cores had no coherency between
the TLB and cpu cache, which severely limited your ability to double
map any pages and generally required you flush the entire cache on
context switch. Generally speaking these class of ARM cores are in the
200mhz range and not really useful for general purpose designs anyway,
so it's not a big deal.
Travis
Other related posts:
