Generate developer docs with Sphinx
An effort was started some time ago to consolidate all internal documentation in the git tree. However, this was just an accumulation of files in various formats without any strucutre or way to browse it, which results in no one even knowing that we have docs here. This converts most of the files to restructuredtext and uses Sphinx to generate an HTML browsable user manual (with a table of content and a first attempt to put things in a global hierarchy). There are almost no changes to the documentation content in this commit (some obviously obsolete things were removed). The plan is to get the toolchain up and running to make these docs easily available, and only then see about improving the content. We can migrate some things off the wiki and website, and rework the table of contents to have some more hierarchy levels because currently it's a bit messy. Change-Id: I924ac9dc6e753887ab56f18a09bdb0a1e1793bfd Reviewed-on: https://review.haiku-os.org/c/haiku/+/4370 Reviewed-by: Niels Sascha Reedijk <[email protected]>
This commit is contained in:
Adrien Destugues
committed by
Adrien Destugues
Adrien Destugues
parent
7f8195344a
commit
a5061ecec5
@@ -1,84 +0,0 @@
|
||||
# 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.
|
||||
|
||||
# Useful links
|
||||
|
||||
Arch Linux instructions on creating a bootable SD card (partition layout, etc)
|
||||
http://archlinuxarm.org/platforms/armv7/allwinner/cubieboard#qt-platform_tabs-ui-tabs2
|
||||
|
||||
Linux SunXi: mainline Linux support for the Allwinner chips. Lots of docs on the hardware.
|
||||
http://linux-sunxi.org/
|
||||
@@ -0,0 +1,99 @@
|
||||
Allwinner A10 hardware notes
|
||||
############################
|
||||
|
||||
- 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
|
||||
3. 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.
|
||||
|
||||
Useful links
|
||||
============
|
||||
|
||||
Arch Linux instructions on creating a bootable SD card (partition
|
||||
layout, etc)
|
||||
http://archlinuxarm.org/platforms/armv7/allwinner/cubieboard#qt-platform_tabs-ui-tabs2
|
||||
|
||||
Linux SunXi: mainline Linux support for the Allwinner chips. Lots of
|
||||
docs on the hardware. http://linux-sunxi.org/
|
||||
@@ -1,60 +0,0 @@
|
||||
# BeagleBone Black
|
||||
* http://beagleboard.org
|
||||
* TODO: This is a WIP
|
||||
|
||||
# Hardware information (Rev A5A)
|
||||
|
||||
* ARMv7 Architecture
|
||||
* Sitara AM3359AZCZ100 Cortex-A8 CPU @ 1 Ghz
|
||||
* PowerVR SGX530 3D GPU
|
||||
* eMMC Onboard Storage 2GB (MMC1)
|
||||
* SD Card Storage (MMC0)
|
||||
* 512 MB DDR3L RAM
|
||||
* Video Outputs
|
||||
* HDMI Video Output (with audio)
|
||||
* SMSC LAN8710A Ethernet
|
||||
|
||||
# Setting up the Haiku SD card
|
||||
|
||||
The BeagleBone Black supports booting from an microSD card while the boot switch is pressed at power on. A MBR file system layout is normally used as seen below. Partition 1 is all that is required to boot an OS.
|
||||
|
||||
* partition 1 -- FAT32, bootable flag, type 'c'
|
||||
* partition 2 -- BeFS, Haiku filesystem, type 'eb'
|
||||
|
||||
## Boot Partition
|
||||
|
||||
### Required files
|
||||
|
||||
* MLO
|
||||
* u-boot.img: u-Boot image
|
||||
* uEnv.txt: u-Boot Environment settings
|
||||
|
||||
### Optional files
|
||||
|
||||
* ID.txt: Unknown
|
||||
|
||||
# Compiling
|
||||
|
||||
* Create your work directory `mkdir generated.beagle; cd generated.beagle`
|
||||
* Build an ARM toolchain using `../configure --build-cross-tools arm ../../buildtools --target-board beagle`
|
||||
* TODO
|
||||
|
||||
# Booting
|
||||
|
||||
1. If the boot switch is not depressed:
|
||||
MMC1, MMC0, UART0, USB0
|
||||
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)
|
||||
* [BeagleBone Black A5A SRM](https://github.com/CircuitCo/BeagleBone-Black/blob/master/BBB_SRM.pdf?raw=true)
|
||||
@@ -0,0 +1,78 @@
|
||||
BeagleBone Black
|
||||
================
|
||||
|
||||
- http://beagleboard.org
|
||||
- TODO: This is a WIP
|
||||
|
||||
Hardware information (Rev A5A)
|
||||
==============================
|
||||
|
||||
- ARMv7 Architecture
|
||||
- Sitara AM3359AZCZ100 Cortex-A8 CPU @ 1 Ghz
|
||||
- PowerVR SGX530 3D GPU
|
||||
- eMMC Onboard Storage 2GB (MMC1)
|
||||
- SD Card Storage (MMC0)
|
||||
- 512 MB DDR3L RAM
|
||||
- Video Outputs
|
||||
|
||||
- HDMI Video Output (with audio)
|
||||
|
||||
- SMSC LAN8710A Ethernet
|
||||
|
||||
Setting up the Haiku SD card
|
||||
============================
|
||||
|
||||
The BeagleBone Black supports booting from an microSD card while the
|
||||
boot switch is pressed at power on. A MBR file system layout is normally
|
||||
used as seen below. Partition 1 is all that is required to boot an OS.
|
||||
|
||||
- partition 1 – FAT32, bootable flag, type ‘c’
|
||||
- partition 2 – BeFS, Haiku filesystem, type ‘eb’
|
||||
|
||||
Boot Partition
|
||||
--------------
|
||||
|
||||
Required files
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
- MLO
|
||||
- u-boot.img: u-Boot image
|
||||
- uEnv.txt: u-Boot Environment settings
|
||||
|
||||
Optional files
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
- ID.txt: Unknown
|
||||
|
||||
Compiling
|
||||
=========
|
||||
|
||||
- Create your work directory
|
||||
``mkdir generated.beagle; cd generated.beagle``
|
||||
- Build an ARM toolchain using
|
||||
``../configure --build-cross-tools arm ../../buildtools --target-board beagle``
|
||||
- TODO
|
||||
|
||||
Booting
|
||||
=======
|
||||
|
||||
1. If the boot switch is not depressed: MMC1, MMC0, UART0, USB0
|
||||
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>`__
|
||||
- `BeagleBone Black A5A
|
||||
SRM <https://github.com/CircuitCo/BeagleBone-Black/blob/master/BBB_SRM.pdf?raw=true>`__
|
||||
@@ -0,0 +1,8 @@
|
||||
Efika MX
|
||||
========
|
||||
|
||||
FDT
|
||||
---
|
||||
|
||||
* http://svnweb.freebsd.org/base/head/sys/boot/fdt/dts/imx51x.dtsi?revision=248557&view=markup
|
||||
* http://svnweb.freebsd.org/base/head/sys/boot/fdt/dts/efikamx.dts?revision=248557&view=markup
|
||||
@@ -1,5 +0,0 @@
|
||||
Notes on Efika MX port -*- org -*-
|
||||
|
||||
* FDT
|
||||
http://svnweb.freebsd.org/base/head/sys/boot/fdt/dts/imx51x.dtsi?revision=248557&view=markup
|
||||
http://svnweb.freebsd.org/base/head/sys/boot/fdt/dts/efikamx.dts?revision=248557&view=markup
|
||||
@@ -0,0 +1,20 @@
|
||||
iPaq
|
||||
====
|
||||
|
||||
* http://www.NetBSD.org/ports/hpcarm/
|
||||
* http://www.ibm.com/developerworks/linux/library/l-ipaq/index.html
|
||||
* http://mstempin.free.fr/linux-ipaq/html_nochunks/Linux-iPAQ-HOWTO-1.1.html#BACKING-UP-BOOTLOADER
|
||||
* http://www.eecs.umich.edu/~panalyzer/
|
||||
* http://www.eecs.umich.edu/~panalyzer/sim-ipaq/sim_ipaq_readme.html
|
||||
* http://blogs.unbolt.net/index.php/brinley/2007/08/04/exploring_hp_ipaq_6515e_bootloader
|
||||
* http://gert-menke.de/jtag-howto/
|
||||
* http://ecos.sourceware.org/docs-3.0/redboot-guide/ipaq.html
|
||||
* http://www.balloonboard.org/balloon/balloon3/distro/test-v0.2/sources/balloonsvn/bootldr295/doc/install-via-osloader.html
|
||||
|
||||
RS232
|
||||
-----
|
||||
|
||||
* http://www.kronosrobotics.com/Zeus/IPAQcon.pdf
|
||||
* http://bevhoward.com/serial.htm
|
||||
* http://www.mail-archive.com/[email protected]/msg132363.html
|
||||
* http://web.archive.org/web/20050408063754/http://www.handhelds.org/pipermail/ipaq/2000-August/000061.html
|
||||
@@ -1,15 +0,0 @@
|
||||
http://www.NetBSD.org/ports/hpcarm/
|
||||
http://www.ibm.com/developerworks/linux/library/l-ipaq/index.html
|
||||
http://mstempin.free.fr/linux-ipaq/html_nochunks/Linux-iPAQ-HOWTO-1.1.html#BACKING-UP-BOOTLOADER
|
||||
http://www.eecs.umich.edu/~panalyzer/
|
||||
http://www.eecs.umich.edu/~panalyzer/sim-ipaq/sim_ipaq_readme.html
|
||||
http://blogs.unbolt.net/index.php/brinley/2007/08/04/exploring_hp_ipaq_6515e_bootloader
|
||||
http://gert-menke.de/jtag-howto/
|
||||
http://ecos.sourceware.org/docs-3.0/redboot-guide/ipaq.html
|
||||
http://www.balloonboard.org/balloon/balloon3/distro/test-v0.2/sources/balloonsvn/bootldr295/doc/install-via-osloader.html
|
||||
|
||||
RS232:
|
||||
http://www.kronosrobotics.com/Zeus/IPAQcon.pdf
|
||||
http://bevhoward.com/serial.htm
|
||||
http://www.mail-archive.com/[email protected]/msg132363.html
|
||||
http://web.archive.org/web/20050408063754/http://www.handhelds.org/pipermail/ipaq/2000-August/000061.html
|
||||
@@ -1,2 +0,0 @@
|
||||
* Does not support < ARMv5
|
||||
* Requires support for high vectors
|
||||
@@ -0,0 +1,170 @@
|
||||
The ARM port
|
||||
============
|
||||
|
||||
Note: there are in fact two ports to the ARM architecture, one for 32-bit, and one for 64-bit
|
||||
systems. They don't have a lot of shared code as the two architectures are very different from
|
||||
one another.
|
||||
|
||||
ARM devices are very popular, and especially since the release of the Raspberry Pi, people have
|
||||
been requesting that Haiku is ported to it. Unfortunately, limitations in the architecture itself
|
||||
and the wide diversity of hardware have made this task more complicated, and progress has been
|
||||
slow. For example, ARM has no standard like the PC is for x86, so concepts as basic as a system
|
||||
timer, a bootloader, or a serial port, are different from one machine to another. The situation
|
||||
has improved with the later generations, as more things were integrated in the CPU core, and u-boot
|
||||
is now well established as the main bootloader for ARM devices.
|
||||
|
||||
Limitations
|
||||
-----------
|
||||
|
||||
There will be no support for hardware using architectures older than ARMv5. There will probably be
|
||||
no support for architectures before ARMv7, which require more work on the compiler and OS, for
|
||||
example due to lack of atomic instructions.
|
||||
|
||||
Support for high vectors (interrupt vectors stored at the end of the memory space) is required.
|
||||
|
||||
Information about specific hardware targets
|
||||
-------------------------------------------
|
||||
|
||||
Over the years, various possible ARM targets have been considered for the Haiku ARM port.
|
||||
We have accumulated some notes and documentation on some of them.
|
||||
|
||||
.. toctree::
|
||||
|
||||
/kernel/arch/arm/allwinner_a10
|
||||
/kernel/arch/arm/beagle
|
||||
/kernel/arch/arm/efikamx
|
||||
/kernel/arch/arm/ipaq
|
||||
/kernel/arch/arm/rpi1
|
||||
/kernel/arch/arm/rpi2
|
||||
|
||||
TODO list
|
||||
---------
|
||||
|
||||
Fix pre-ARMv7 support
|
||||
*********************
|
||||
|
||||
The ARM instruction set has evolved a lot over time, and we have to make a choice: use the oldest
|
||||
versions of the instruction set gives us maximal compatibility, but at the cost of a large
|
||||
performance hit on newer systems, as well as extra code being needed in the OS to compensate for
|
||||
the missing instructions.
|
||||
|
||||
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.
|
||||
|
||||
It seems this create other problems, mainly because the UEFI environment for ARM is not supposed to
|
||||
handle floating point registers. So, the softfloat ABI should be used there instead. To be able
|
||||
to build both "soft float" and "hard float" code, we need multilib support, see below.
|
||||
|
||||
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.
|
||||
|
||||
The current version of the x86_64 compiler appears is using multilib (to build for both 32 and 64
|
||||
bit targets) and is working fine, so it's possible that most of the issues in this area have
|
||||
already been fixed.
|
||||
|
||||
Figure out how to get page flags (modified/accessed) and implement it
|
||||
*********************************************************************
|
||||
|
||||
use unmapped/read-only mappings to trigger soft faults for tracking used/modified flags for ARMv5 and ARMv6
|
||||
|
||||
Fix serial port mapping
|
||||
***********************
|
||||
|
||||
Currently kernel uses the haiku_loader identity
|
||||
mapping for it, but this lives in user virtual address space...
|
||||
(Need to not use identity mapping in haiku_loader but just
|
||||
map_physical_memory() there too so it can be handed over without issues).
|
||||
|
||||
Seperate ARM architecture/System-On-Chip IP code
|
||||
************************************************
|
||||
|
||||
The early work on the ARM port resulted in lots of board specific code being added to early stages
|
||||
of the kernel. Ideally, this would not be needed, the kernel would manage to initialize itself
|
||||
mostly in a platform independant way, and get the needed information from the FDT passed by the
|
||||
bootloader. The difficulty is that on older ARM versions, even the interrupt controller and timers
|
||||
can be different on each machine.
|
||||
|
||||
KDL disasm module
|
||||
*****************
|
||||
|
||||
Currently it is not possible to disassemble code in the kernel debugger.
|
||||
|
||||
The `NetBSD disassembler <http://fxr.watson.org/fxr/source/arch/arm/arm/disassem.c?v=NETBSD>`_ could be ported and used for this.
|
||||
|
||||
Add KDL hangman to the boot image
|
||||
*********************************
|
||||
|
||||
for more enjoyment during porting....
|
||||
|
||||
Userland
|
||||
********
|
||||
|
||||
Even if KDL hangman is fun, users will want to run real applications someday.
|
||||
|
||||
Bootloader TODOs
|
||||
****************
|
||||
|
||||
- Better handling of memory ranges. Currently no checks are done, and
|
||||
memory is assumed to be a single contiguous range, and the "input"
|
||||
ranges for mmu_init are setup, but never considered.
|
||||
- Allocate the pagetable range using mmu_allocate() instead of identity
|
||||
mapping it. That way, there's a bit more flexibility in where to place
|
||||
it both physically and virtually. This will need a minor change on the
|
||||
kernel side too (in the early pagetable allocator).
|
||||
|
||||
Other resources
|
||||
---------------
|
||||
|
||||
About flatenned device trees
|
||||
****************************
|
||||
|
||||
* http://www.denx.de/wiki/U-Boot/UBootFdtInfo
|
||||
* http://wiki.freebsd.org/FlattenedDeviceTree#Supporting_library_.28libfdt.29
|
||||
* http://elinux.org/images/4/4e/Glikely-powerpc-porting-guide.pdf
|
||||
* http://ols.fedoraproject.org/OLS/Reprints-2008/likely2-reprint.pdf
|
||||
* http://www.bsdcan.org/2010/schedule/events/171.en.html
|
||||
* http://www.devicetree.org/ (unofficial bindings)
|
||||
* http://www.devicetree.org/Device_Tree_Usage
|
||||
* http://elinux.org/Device_Trees
|
||||
|
||||
About openfirmware
|
||||
******************
|
||||
|
||||
http://www.openfirmware.info/Bindings
|
||||
|
||||
About floating point numbers handling on ARM
|
||||
********************************************
|
||||
|
||||
https://wiki.debian.org/ArmHardFloatPort/VfpComparison
|
||||
@@ -1,74 +0,0 @@
|
||||
# Raspberry Pi
|
||||
* http://raspberrypi.org
|
||||
|
||||
# Hardware Information
|
||||
|
||||
* ARMv6 Architecture
|
||||
* Broadcom BCM2835 (SoC)
|
||||
* Includes ARM1176JZF-S CPU @ 700 MHz
|
||||
* Includes VideoCore IV GPU
|
||||
* SD Card Storage
|
||||
* 256 or 512 MB RAM (depending on revision)
|
||||
* Video Outputs
|
||||
* HDMI Video Output
|
||||
* Composite Video Output
|
||||
* Ethernet
|
||||
|
||||
# Setting up the Haiku SD card
|
||||
|
||||
The Raspberry Pi SD card generally uses the MBR file system layout below. Partition 1 is all that is required to boot an OS.
|
||||
|
||||
* partition 1 -- FAT32, bootable flag, type 'c'
|
||||
* partition 2 -- BeFS, Haiku filesystem, type 'eb'
|
||||
|
||||
## Boot Partition
|
||||
|
||||
### Required Files
|
||||
|
||||
* bootcode.bin : 2nd stage bootloader
|
||||
* start.elf: The GPU binary firmware image
|
||||
* config.txt: A configuration file read by the Pi to start u-boot.bin
|
||||
* u-boot.bin: u-boot loader for the Pi 2
|
||||
* bcm2835-rpi-b.dtb: FDT binary for the Raspberry Pi 2
|
||||
* haiku_loader_linux.ub: Haiku Loader
|
||||
* haiku-floppyboot.tgz.ub: Compressed initial ram image with Haiku kernel
|
||||
|
||||
### Optional Files
|
||||
|
||||
* vlls directory: Additional GPU code, e.g. extra codecs.
|
||||
* uEnv.txt: u-boot configuration script to automate boot.
|
||||
|
||||
# Compiling
|
||||
|
||||
* Create your ARM work directory `mkdir generated.arm; cd generated.arm`
|
||||
* Build an ARM toolchain using `../configure --build-cross-tools arm ../../buildtools --target-board=rpi1`
|
||||
* Build our loader using `jam -q haiku_loader_linux.ub`
|
||||
* Build our initial ram disk using `jam -q haiku-floppyboot.tgz.ub`
|
||||
|
||||
# Booting
|
||||
|
||||
1. SOC finds bootcode.bin
|
||||
2. bootcode.bin runs start.elf
|
||||
3. start.elf reads config.txt and start u-boot
|
||||
4. u-boot.bin starts the Haiku loader
|
||||
5. Haiku loader boots Haiku kernel
|
||||
|
||||
## config.txt Options
|
||||
|
||||
kernel=u-boot.bin
|
||||
|
||||
## u-boot startup
|
||||
|
||||
These will be condensed and automated long-term via uEnv.txt :-)
|
||||
|
||||
* `fatload mmc 0 ${fdt_addr_r} bcm2835-rpi-b.dtb`
|
||||
* `fdt addr ${fdt_addr_r}`
|
||||
* `fatload mmc 0 ${ramdisk_addr_r} haiku-floppyboot.tgz.ub`
|
||||
* `fatload mmc 0 ${kernel_addr_r} haiku_loader_linux.ub`
|
||||
* `bootm ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}`
|
||||
|
||||
# Additional Information
|
||||
|
||||
* [Latest Raspberry Pi firmware](http://github.com/raspberrypi/firmware/tree/master/boot)
|
||||
* [config.txt options](http://www.elinux.org/RPiconfig)
|
||||
|
||||
@@ -0,0 +1,96 @@
|
||||
Raspberry Pi
|
||||
############
|
||||
|
||||
- http://raspberrypi.org
|
||||
|
||||
Hardware Information
|
||||
====================
|
||||
|
||||
- ARMv6 Architecture
|
||||
- Broadcom BCM2835 (SoC)
|
||||
|
||||
- Includes ARM1176JZF-S CPU @ 700 MHz
|
||||
- Includes VideoCore IV GPU
|
||||
|
||||
- SD Card Storage
|
||||
- 256 or 512 MB RAM (depending on revision)
|
||||
- Video Outputs
|
||||
|
||||
- HDMI Video Output
|
||||
- Composite Video Output
|
||||
|
||||
- Ethernet
|
||||
|
||||
Setting up the Haiku SD card
|
||||
============================
|
||||
|
||||
The Raspberry Pi SD card generally uses the MBR file system layout
|
||||
below. Partition 1 is all that is required to boot an OS.
|
||||
|
||||
- partition 1 – FAT32, bootable flag, type ‘c’
|
||||
- partition 2 – BeFS, Haiku filesystem, type ‘eb’
|
||||
|
||||
Boot Partition
|
||||
--------------
|
||||
|
||||
Required Files
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
- bootcode.bin : 2nd stage bootloader
|
||||
- start.elf: The GPU binary firmware image
|
||||
- config.txt: A configuration file read by the Pi to start u-boot.bin
|
||||
- u-boot.bin: u-boot loader for the Pi 2
|
||||
- bcm2835-rpi-b.dtb: FDT binary for the Raspberry Pi 2
|
||||
- haiku_loader_linux.ub: Haiku Loader
|
||||
- haiku-floppyboot.tgz.ub: Compressed initial ram image with Haiku
|
||||
kernel
|
||||
|
||||
Optional Files
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
- vlls directory: Additional GPU code, e.g. extra codecs.
|
||||
- uEnv.txt: u-boot configuration script to automate boot.
|
||||
|
||||
Compiling
|
||||
=========
|
||||
|
||||
- Create your ARM work directory
|
||||
``mkdir generated.arm; cd generated.arm``
|
||||
- Build an ARM toolchain using
|
||||
``../configure --build-cross-tools arm ../../buildtools --target-board=rpi1``
|
||||
- Build our loader using ``jam -q haiku_loader_linux.ub``
|
||||
- Build our initial ram disk using ``jam -q haiku-floppyboot.tgz.ub``
|
||||
|
||||
Booting
|
||||
=======
|
||||
|
||||
1. SOC finds bootcode.bin
|
||||
2. bootcode.bin runs start.elf
|
||||
3. start.elf reads config.txt and start u-boot
|
||||
4. u-boot.bin starts the Haiku loader
|
||||
5. Haiku loader boots Haiku kernel
|
||||
|
||||
config.txt Options
|
||||
------------------
|
||||
|
||||
::
|
||||
|
||||
kernel=u-boot.bin
|
||||
|
||||
u-boot startup
|
||||
--------------
|
||||
|
||||
These will be condensed and automated long-term via uEnv.txt :-)
|
||||
|
||||
- ``fatload mmc 0 ${fdt_addr_r} bcm2835-rpi-b.dtb``
|
||||
- ``fdt addr ${fdt_addr_r}``
|
||||
- ``fatload mmc 0 ${ramdisk_addr_r} haiku-floppyboot.tgz.ub``
|
||||
- ``fatload mmc 0 ${kernel_addr_r} haiku_loader_linux.ub``
|
||||
- ``bootm ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}``
|
||||
|
||||
Additional Information
|
||||
======================
|
||||
|
||||
- `Latest Raspberry Pi
|
||||
firmware <http://github.com/raspberrypi/firmware/tree/master/boot>`__
|
||||
- `config.txt options <http://www.elinux.org/RPiconfig>`__
|
||||
@@ -1,74 +0,0 @@
|
||||
# Raspberry Pi 2
|
||||
* http://raspberrypi.org
|
||||
|
||||
# Hardware Information
|
||||
|
||||
* ARMv7 Architecture
|
||||
* Broadcom BCM2836 (SoC)
|
||||
* Includes Quad ARM1176JZF-S CPU @ 900 MHz
|
||||
* Includes VideoCore IV GPU
|
||||
* SD Card Storage
|
||||
* 1 GB RAM
|
||||
* Video Outputs
|
||||
* HDMI Video Output
|
||||
* Composite Video Output
|
||||
* Ethernet
|
||||
|
||||
# Setting up the Haiku SD card
|
||||
|
||||
The Raspberry Pi SD card generally uses the MBR file system layout below. Partition 1 is all that is required to boot an OS.
|
||||
|
||||
* partition 1 -- FAT32, bootable flag, type 'c'
|
||||
* partition 2 -- BeFS, Haiku filesystem, type 'eb'
|
||||
|
||||
## Boot Partition
|
||||
|
||||
### Required Files
|
||||
|
||||
* bootcode.bin : 2nd stage bootloader
|
||||
* start.elf: The GPU binary firmware image
|
||||
* config.txt: A configuration file read by the Pi to start u-boot.bin
|
||||
* u-boot.bin: u-boot loader for the Pi 2
|
||||
* bcm2836-rpi-2-b.dtb: FDT binary for the Raspberry Pi 2
|
||||
* haiku_loader_linux.ub: Haiku Loader
|
||||
* haiku-floppyboot.tgz.ub: Compressed initial ram image with Haiku kernel
|
||||
|
||||
### Optional Files
|
||||
|
||||
* vlls directory: Additional GPU code, e.g. extra codecs.
|
||||
* uEnv.txt: u-boot configuration script to automate boot.
|
||||
|
||||
# Compiling
|
||||
|
||||
* Create your ARM work directory `mkdir generated.arm; cd generated.arm`
|
||||
* Build an ARM toolchain using `../configure --build-cross-tools arm ../../buildtools --target-board=rpi2`
|
||||
* Build our loader using `jam -q haiku_loader_linux.ub`
|
||||
* Build our initial ram disk using `jam -q haiku-floppyboot.tgz.ub`
|
||||
|
||||
# Booting
|
||||
|
||||
1. SOC finds bootcode.bin
|
||||
2. bootcode.bin runs start.elf
|
||||
3. start.elf reads config.txt and start u-boot
|
||||
4. u-boot.bin starts the Haiku loader
|
||||
5. Haiku loader boots Haiku kernel
|
||||
|
||||
## config.txt Options
|
||||
|
||||
kernel=u-boot.bin
|
||||
|
||||
## u-boot startup
|
||||
|
||||
These will be condensed and automated long-term via uEnv.txt :-)
|
||||
|
||||
* `fatload mmc 0 ${fdt_addr_r} bcm2836-rpi-2-b.dtb`
|
||||
* `fdt addr ${fdt_addr_r}`
|
||||
* `fatload mmc 0 ${ramdisk_addr_r} haiku-floppyboot.tgz.ub`
|
||||
* `fatload mmc 0 ${kernel_addr_r} haiku_loader_linux.ub`
|
||||
* `bootm ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}`
|
||||
|
||||
# Additional Information
|
||||
|
||||
* [Latest Raspberry Pi firmware](http://github.com/raspberrypi/firmware/tree/master/boot)
|
||||
* [config.txt options](http://www.elinux.org/RPiconfig)
|
||||
|
||||
@@ -0,0 +1,96 @@
|
||||
Raspberry Pi 2
|
||||
##############
|
||||
|
||||
- http://raspberrypi.org
|
||||
|
||||
Hardware Information
|
||||
====================
|
||||
|
||||
- ARMv7 Architecture
|
||||
- Broadcom BCM2836 (SoC)
|
||||
|
||||
- Includes Quad ARM1176JZF-S CPU @ 900 MHz
|
||||
- Includes VideoCore IV GPU
|
||||
|
||||
- SD Card Storage
|
||||
- 1 GB RAM
|
||||
- Video Outputs
|
||||
|
||||
- HDMI Video Output
|
||||
- Composite Video Output
|
||||
|
||||
- Ethernet
|
||||
|
||||
Setting up the Haiku SD card
|
||||
============================
|
||||
|
||||
The Raspberry Pi SD card generally uses the MBR file system layout
|
||||
below. Partition 1 is all that is required to boot an OS.
|
||||
|
||||
- partition 1 – FAT32, bootable flag, type ‘c’
|
||||
- partition 2 – BeFS, Haiku filesystem, type ‘eb’
|
||||
|
||||
Boot Partition
|
||||
--------------
|
||||
|
||||
Required Files
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
- bootcode.bin : 2nd stage bootloader
|
||||
- start.elf: The GPU binary firmware image
|
||||
- config.txt: A configuration file read by the Pi to start u-boot.bin
|
||||
- u-boot.bin: u-boot loader for the Pi 2
|
||||
- bcm2836-rpi-2-b.dtb: FDT binary for the Raspberry Pi 2
|
||||
- haiku_loader_linux.ub: Haiku Loader
|
||||
- haiku-floppyboot.tgz.ub: Compressed initial ram image with Haiku
|
||||
kernel
|
||||
|
||||
Optional Files
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
- vlls directory: Additional GPU code, e.g. extra codecs.
|
||||
- uEnv.txt: u-boot configuration script to automate boot.
|
||||
|
||||
Compiling
|
||||
=========
|
||||
|
||||
- Create your ARM work directory
|
||||
``mkdir generated.arm; cd generated.arm``
|
||||
- Build an ARM toolchain using
|
||||
``../configure --build-cross-tools arm ../../buildtools --target-board=rpi2``
|
||||
- Build our loader using ``jam -q haiku_loader_linux.ub``
|
||||
- Build our initial ram disk using ``jam -q haiku-floppyboot.tgz.ub``
|
||||
|
||||
Booting
|
||||
=======
|
||||
|
||||
1. SOC finds bootcode.bin
|
||||
2. bootcode.bin runs start.elf
|
||||
3. start.elf reads config.txt and start u-boot
|
||||
4. u-boot.bin starts the Haiku loader
|
||||
5. Haiku loader boots Haiku kernel
|
||||
|
||||
config.txt Options
|
||||
------------------
|
||||
|
||||
::
|
||||
|
||||
kernel=u-boot.bin
|
||||
|
||||
u-boot startup
|
||||
--------------
|
||||
|
||||
These will be condensed and automated long-term via uEnv.txt :-)
|
||||
|
||||
- ``fatload mmc 0 ${fdt_addr_r} bcm2836-rpi-2-b.dtb``
|
||||
- ``fdt addr ${fdt_addr_r}``
|
||||
- ``fatload mmc 0 ${ramdisk_addr_r} haiku-floppyboot.tgz.ub``
|
||||
- ``fatload mmc 0 ${kernel_addr_r} haiku_loader_linux.ub``
|
||||
- ``bootm ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}``
|
||||
|
||||
Additional Information
|
||||
======================
|
||||
|
||||
- `Latest Raspberry Pi
|
||||
firmware <http://github.com/raspberrypi/firmware/tree/master/boot>`__
|
||||
- `config.txt options <http://www.elinux.org/RPiconfig>`__
|
||||
@@ -1,64 +0,0 @@
|
||||
* 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
|
||||
for tracking used/modified flags for ARMv5 and ARMv6
|
||||
|
||||
* Fix serial port mapping. Currently kernel uses the haiku_loader identity
|
||||
mapping for it, but this lives in user virtual address space...
|
||||
(Need to not use identity mapping in haiku_loader but just
|
||||
map_physical_memory() there too so it can be handed over without issues).
|
||||
|
||||
* Seperate ARM architecture/System-On-Chip IP code. Needed very early on
|
||||
(Interrupt Controller, Timer IP block). Should use FDT for this too.
|
||||
|
||||
* Use FDT to remove all the seperate board definitions in the build. Use a
|
||||
"minimal ARM architecture version" as the compile flag for ARM support.
|
||||
This to be able to optimize a kernel build for a specific SoC (or family).
|
||||
|
||||
* KDL disasm module.
|
||||
cf.
|
||||
http://fxr.watson.org/fxr/source/arch/arm/arm/disassem.c?v=NETBSD
|
||||
|
||||
* Add KDL hangman to the boot floppy image for more enjoyment during porting....
|
||||
|
||||
* Userland...........
|
||||
|
||||
* Bootloader TODOs:
|
||||
- Better handling of memory ranges. Currently no checks are done, and
|
||||
memory is assumed to be a single contiguous range, and the "input"
|
||||
ranges for mmu_init are setup, but never considered.
|
||||
- Allocate the pagetable range using mmu_allocate() instead of identity
|
||||
mapping it. That way, there's a bit more flexibility in where to place
|
||||
it both physically and virtually. This will need a minor change on the
|
||||
kernel side too (in the early pagetable allocator).
|
||||
@@ -1,13 +0,0 @@
|
||||
* FDT
|
||||
http://www.denx.de/wiki/U-Boot/UBootFdtInfo
|
||||
http://wiki.freebsd.org/FlattenedDeviceTree#Supporting_library_.28libfdt.29
|
||||
http://elinux.org/images/4/4e/Glikely-powerpc-porting-guide.pdf
|
||||
http://ols.fedoraproject.org/OLS/Reprints-2008/likely2-reprint.pdf
|
||||
http://www.bsdcan.org/2010/schedule/events/171.en.html
|
||||
http://www.devicetree.org/ (unofficial bindings)
|
||||
http://www.devicetree.org/Device_Tree_Usage
|
||||
http://elinux.org/Device_Trees
|
||||
* OF
|
||||
http://www.openfirmware.info/Bindings
|
||||
* Floating Point; VFP
|
||||
https://wiki.debian.org/ArmHardFloatPort/VfpComparison
|
||||
Reference in New Issue
Block a user