Linux on MegaRAID 300-8X
========================
I thought about it a bit more, and read a bunch of IOP33x docs, and I
think (in theory) that it would be possible.

The IOP33x ATU is visible on its local PCI bus (IDSEL directly connected
to A_AD[30] of the 'A' secondary PCI bus), which means that it should be
possible to see the IOP33x from the primary PCI.  (It is possible to hide
it by setting the "ATU Hide" bit in PCI bus A upstream bridge's BINIT
register, but this bit defaults to the ATU being visible, and in any
case, this bit is writable from the host -- you would have to convince
your host OS to re-scan the PCI bus in that case, though.)

Furthermore, the MegaRAID card has a jumper, J11, which is described
as "Jumpered: Causes the CPU core to be held in reset (mode 0)."  To me,
it sounds like this jumper is connected to the CORE_RST# (i.e. AD[5])
strap pin.  If so, and if RETRY (AD[6]) is strapped low, I think we are
golden.

By strapping CORE_RST#, the xscale core will be kept in reset after the
host powers on.  When the host goes through its PCI enumeration, the
IOP033x's BAR0 will have a default size of 16 megabytes (pointing into
the CPU's configuration register area at ff00_0000 by default), so that
the host will assign a 16M memory window to it, and all the other BARs
will be disabled.

While we boot the host OS, the IOP33x will be kept in reset.  Once we have
booted our host OS and are ready to boot the IOP33x, we initialise the
IOP33x's memory controller, copy a Linux kernel into its memory,
configure the PBI unit to disable window #0, configure the PBI unit's
memoryless boot registers to jump to the Linux kernel, enable mapping the
PBI unit's memoryless boot registers to physical address zero, and then
poke bit 1 of the PCSR register to release the xscale core from reset and
start booting Linux!  In theory, at least.

So assuming that J11 on the MegaRAID connects to the processor's
CORE_RST# pin and that RETRY is strapped low by default, yes, I think
it can be done.

The only problem might be that if we boot with the xscale core in reset,
the Marvell SATA controller will be visible to the host, since we won't
have a chance to enable private addressing in time, but I think we can
find a way around that.
------------------------------------------------------------------------------
80331: "If software disables ECC, the MCU does generate the ECC byte for
writes, but does not check the ECC byte for read.  For writes, the MCU
will not perform the Read and Modify steps normally performed for a sub
64-bit write [...]"  (Instead, it'll pad _every_ sub 64-bit write with
zeroes when calculating ECC, instead of reading the non-written sub-bytes
first.)