[haiku-commits] haiku: hrev47181 - docs/develop/ports/arm
- From: pulkomandy@xxxxxxxxxxxxx
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Mon, 28 Apr 2014 22:25:11 +0200 (CEST)
hrev47181 adds 1 changeset to branch 'master'
old head: 554e2073842e023e35e1523fba025f30574fe137
new head: 5b172de12361eaf89c646b5b9629d2fabdfc104e
overview: http://cgit.haiku-os.org/haiku/log/?qt=range&q=5b172de+%5E554e207
----------------------------------------------------------------------------
5b172de: 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.
[ Adrien Destugues <pulkomandy@xxxxxxxxxxxxx> ]
----------------------------------------------------------------------------
Revision: hrev47181
Commit: 5b172de12361eaf89c646b5b9629d2fabdfc104e
URL: http://cgit.haiku-os.org/haiku/commit/?id=5b172de
Author: Adrien Destugues <pulkomandy@xxxxxxxxxxxxx>
Date: Mon Apr 28 20:24:04 2014 UTC
----------------------------------------------------------------------------
3 files changed, 111 insertions(+)
docs/develop/ports/arm/allwinner_a10.md | 76 +++++++++++++++++++++++++++++
docs/develop/ports/arm/beagle.md | 8 +++
docs/develop/ports/arm/todo.txt | 27 ++++++++++
----------------------------------------------------------------------------
diff --git a/docs/develop/ports/arm/allwinner_a10.md
b/docs/develop/ports/arm/allwinner_a10.md
new file mode 100644
index 0000000..f079d70
--- /dev/null
+++ b/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.
diff --git a/docs/develop/ports/arm/beagle.md b/docs/develop/ports/arm/beagle.md
index c139a2e..2d662e7 100644
--- a/docs/develop/ports/arm/beagle.md
+++ b/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)
diff --git a/docs/develop/ports/arm/todo.txt b/docs/develop/ports/arm/todo.txt
index a6bd633..043819b 100644
--- a/docs/develop/ports/arm/todo.txt
+++ b/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
Other related posts:
- » [haiku-commits] haiku: hrev47181 - docs/develop/ports/arm - pulkomandy
