This is a preliminary Plan 9 port to the Compulab Trimslice,
containing a Tegra 2 SoC: a dual-core, (truly) dual-issue 1GHz
Cortex-A9 v7a-architecture ARM system, *and* it comes in a case.  VFP
3 floating-point hardware is present, but 5l doesn't yet generate
those instructions.  This is the first multiprocessor ARM port we've
done, and much of the code should be reusable in future ports.  There
are still things to be done but it can run both processors and is
believed to have adequate kernel support for VFP 3 floating-point.


What's implemented.

Two cpus running concurrently with level 1 and 2 caches enabled.

Realtek 8168 Ethernet.  A slightly dimmer 8169.  Has to be jabbed with
an electric cattle prod by software about once per day when it wedges.

Profiling.  Charles Forsyth fixed various bugs to make user-mode
profiling on ARMs work for the first time ever.


What's not (yet) implemented.

USB.  It probably just needs initialisation.

NOR flash.

Video.

VFP3 floating point.  The go 5l generates VFP 3 floating-point
instructions (among other changes).  Attempts to transplant just that
code into our 5l failed to generate correct code.  Eventually someone
will get this to work, and then we'll be able to use the hardware
floating-point.  [Added 2013.01.11: eventually someone did -- see
patch 5l-vfp]  Even with only software emulation of floating-point,
astro runs in under 3 seconds.

In-line 64-bit arithmetic in 5[cl].

And the really horrid peripherals: NAND flash and MMC.


Known problems.

kprof.  kprof profiling doesn't work correctly, charging all CPU time
to _start.

Reboot.  After an fshalt -r reboot (or two) with cpu1 enabled,
accesses to pci registers (notably 0x80015000) in the newly-loaded
kernel often hang.  One of three watchdogs' reset should jolt the
system back to life and force a reboot through u-boot when this
happens.  Sometimes the ethernet goes dead instead ("waiting for
dhcp..." forever); this could be a different symptom of pci illness.

Also following a reboot, cpu1's local (not tegra SoC shared) timers
don't interrupt.  Since the local watchdogs don't seem to actually
interrupt nor generate resets when used in anger (as opposed to
boot-time check-out), their loss is merely a mystery.  The local timer
not interrupting is more worrying.