Update some docs for the ARM port.

* Add info on Allwinner A10 SOCs, which may be a worthwile target.
* Add info about the Linaro QEmu for emulating the BeagleBoard.
* Add more TODOs for PM aftermath.

docs/develop/ports/arm/allwinner_a10.md

@@ -0,0 +1,76 @@
+# Allwinner A10
+* http://linux-sunxi.org
+
+# Hardware Information
+
+The A10 is a system-on chip. There are many devices based on it, for example
+the CubieBoard and the Rikomagic mk802 (versions I and II).
+
+* ARMv7 Architecture (Cortex-A8)
+* Mali 400MP GPU
+* CedarX VPU
+* SD Card Storage
+* 1GB RAM (DDR)
+* 4GB NAND Flash
+* Video Outputs
+  * HDMI Video Output
+* Ethernet
+* USB
+
+# Setting up the Haiku SD card
+
+Not so fun layout here. The A10 boot ROM reads raw blocks from the SD card
+(MBR style), so the bootloader can't just be dropped in a FAT32 partition.
+
+*  8KB partition table
+*  24KB SPL loader
+*  512KB u-boot
+*  128KB u-boot environment variables
+*  352KB unused
+*  partition 1 -- FAT32 or ext2 (anything u-boot can read is fine)
+*  partition 2 -- BeFS, Haiku filesystem, type 'eb'
+
+Note this layout can be a bit different depending on the u-boot version used,
+some versions will store the environment in uEnv.txt in the FAT32 partition
+instead. Since everything is loaded from the SD Card, we are free to customize
+the u-boot or even remove it and get haiku_loader booting directly.
+
+## Boot Partition
+
+### Required Files
+
+*  haiku_loader: Haiku Loader
+*  haiku-floppyboot.tgz: Compressed image with Haiku kernel
+
+# Booting
+
+1. SOC load SPL
+2. SPL loads u-boot
+2. u-boot loads and run the kernel
+
+SPL is a small binary (24K) loaded from a fixed location on the SD card. It
+does minimal hardware initializations, then loads u-boot, also from the SD
+card. From there on things go as usual.
+
+In the long term, we can make haiku_loader be an SPL executable on this
+platform, if it fits the 24K size limit, or have a custom stage1 that loads it.
+For now, u-boot can be an useful debugging tool.
+
+## Script.bin
+
+In order to work on different devices (RAM timings, PIO configs, ...), the
+Linux kernels for Allwinner chips use a "script.bin" file. This is loaded to
+RAM at a fixed address by u-boot, then the Kernel parses it and uses it to
+configure the hardware (similar to FDT).
+
+We should probably NOT use this, and convert the script.bin file to an FDT
+instead. The format is known and there are tools to convert the binary file
+to an editable text version and back (bin2fex and fex2bin).
+
+This FEX stuff isn't merged in mainline Linux, and lives on as Allwinner
+patches. The mainline Linux kernel has some A10 support, rewritten to use
+FDT. We may use the FDT files from there for the most common boards.
+
+# Emulation support
+
+qemu 1.0 has a Cubieoard target which emulates this chip.

docs/develop/ports/arm/beagle.md

@@ -46,6 +46,14 @@ The BeagleBone Black supports booting from an microSD card while the boot switch
 2. If the boot switch is depressed:
    SPI0, MMC0, USB0, UART0
 
+# Emulation
+
+The Linaro Fork of QEmu has beagle board (and other OMAP3) support.
+https://launchpad.net/qemu-linaro
+
+It seems you get this as the default QEmu install on some, but not all, Ubuntu
+versions. For other distros (or Haiku), you'll have to compile it yourself.
+
 # Additional information
 
 * [CircutCo WikiPage](http://circuitco.com/support/index.php?title=BeagleBoneBlack)

docs/develop/ports/arm/todo.txt

@@ -1,7 +1,34 @@
+* Fix pre-ARMv7 support
+  Currently the cross-tools are compiled to default to ARMv7, Cortex-A8, and
+  hardware floating point. This works around the missing atomic support, see
+  below. This should be done by setting the -mcpu,-march and -mfloat-abi
+  switches at build time, however, they aren't passed on to haikuporter
+  during the bootstrap build, leading to the ports failing to find the
+  gcc atomic ops again.
+
 * Determine how to handle atomic functions on ARM.
   GCC inlines are not supported, since the instructionset is ill-equiped for
   this on older (pre-ARMv7) architectures. We possibly have to do something
   similar to the linux kernel helper functions for this....
+  On ARMv7 and later, this is not an issue. Not sure about ARMv6, we may get
+  it going there. ARMv5 definitely needs us to write some code, but is it
+  worth the trouble?
+
+* Fix multilib support
+  ARM-targetting versions of gcc are usually built with multilib support, to
+  allow targetting architectures with or without FPU, and using either ARM
+  or Thumb instructions. This bascally means a different libgcc and libstdc++
+  are built for each combination.
+  The cross-tools can be built with multilib support. However, we do some
+  tricks to get a separate libgcc and libstdc++ for the kernel (without C++11
+  threads support, as that would not build in the kernel). Building this lib
+  is not done in a multilib-aware way, so you get one only for the default
+  arch/cpu/abi the compiler is targetting. This is good enough, as long as that
+  arch is the one we want to use for the kernel...
+  Later on, the bootstrap build of the native gcc compiler will fail, because
+  it tries to build its multilib library set by linking against the different
+  versions of libroot (with and without fpu, etc). We only build one libroot,
+  so this also fails.
 
 * Figure out how to get page flags (modified/accessed) and implement it ;)
 	use unmapped/read-only mappings to trigger soft faults