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
|
||||
@@ -1,48 +0,0 @@
|
||||
Notes on long double support
|
||||
============================
|
||||
|
||||
The "long double" type is different on each architecture. Depending on the
|
||||
available hardware and ABI conventions, performance compromises, etc, there
|
||||
may be many implementations of it. Here is a summary for our convenience.
|
||||
|
||||
128-bit IEEE
|
||||
------------
|
||||
|
||||
Platforms: Sparc, ARM64, RISC-V
|
||||
|
||||
This is the standard long double type from IEEE754. It has 1 sign bit,
|
||||
15 exponent bit, and 112 fractional part bits. It is the natural extension
|
||||
of the 64bit double.
|
||||
|
||||
Sparc specifies this type in their ABI but no implementation actually has
|
||||
the instructions, they instead trigger a trap which would software emulate
|
||||
them. However, gcc short circuits this by default and calls C library
|
||||
support functions directly.
|
||||
|
||||
64-bit IEEE
|
||||
-----------
|
||||
|
||||
Platforms: ARM
|
||||
|
||||
This is the same representation as plain "double". ARM uses this for simplicity.
|
||||
|
||||
80-bit
|
||||
------
|
||||
|
||||
Platform: x86, x86\_64, m68k
|
||||
|
||||
This intermediate format is used by x86 CPUs internally. It may end up being
|
||||
faster than plain double there. It consists of a 64bit fractional part, 15
|
||||
exponent bits, and 1 sign bit. This is convenient because the fractional part
|
||||
is a relatively easy to handle 64bit number.
|
||||
|
||||
m68k uses a similar format, but padded to 96 bits (the extra 16 bits are unused).
|
||||
|
||||
double double
|
||||
-------------
|
||||
|
||||
Platforms: PowerPC?
|
||||
|
||||
This is also a 128bit type, but the representation is just two 64bit doubles.
|
||||
The value is the sum of the two halves. This format allows faster emulation
|
||||
than a "true" 128bit long double, and the precision is almost as good.
|
||||
@@ -0,0 +1,54 @@
|
||||
Notes on long double support
|
||||
============================
|
||||
|
||||
The “long double” type is different on each architecture. Depending on
|
||||
the available hardware and ABI conventions, performance compromises,
|
||||
etc, there may be many implementations of it. Here is a summary for our
|
||||
convenience.
|
||||
|
||||
128-bit IEEE
|
||||
------------
|
||||
|
||||
Platforms: Sparc, ARM64, RISC-V
|
||||
|
||||
This is the standard long double type from IEEE754. It has 1 sign bit,
|
||||
15 exponent bit, and 112 fractional part bits. It is the natural
|
||||
extension of the 64bit double.
|
||||
|
||||
Sparc specifies this type in their ABI but no implementation actually
|
||||
has the instructions, they instead trigger a trap which would software
|
||||
emulate them. However, gcc short circuits this by default and calls C
|
||||
library support functions directly.
|
||||
|
||||
.. _bit-ieee-1:
|
||||
|
||||
64-bit IEEE
|
||||
-----------
|
||||
|
||||
Platforms: ARM
|
||||
|
||||
This is the same representation as plain “double”. ARM uses this for
|
||||
simplicity.
|
||||
|
||||
80-bit
|
||||
------
|
||||
|
||||
Platform: x86, x86_64, m68k
|
||||
|
||||
This intermediate format is used by x86 CPUs internally. It may end up
|
||||
being faster than plain double there. It consists of a 64bit fractional
|
||||
part, 15 exponent bits, and 1 sign bit. This is convenient because the
|
||||
fractional part is a relatively easy to handle 64bit number.
|
||||
|
||||
m68k uses a similar format, but padded to 96 bits (the extra 16 bits are
|
||||
unused).
|
||||
|
||||
double double
|
||||
-------------
|
||||
|
||||
Platforms: PowerPC?
|
||||
|
||||
This is also a 128bit type, but the representation is just two 64bit
|
||||
doubles. The value is the sum of the two halves. This format allows
|
||||
faster emulation than a “true” 128bit long double, and the precision is
|
||||
almost as good.
|
||||
@@ -1,3 +0,0 @@
|
||||
- optimization: remove M68KPagingStructures[*]::UpdateAllPageDirs() and just allocate all the kernel page root entries at boot and be done with it. It's not very big anyway.
|
||||
- possibly other optimizations in the VM code due to not supporting SMP?
|
||||
|
||||
@@ -0,0 +1,4 @@
|
||||
The Amiga port
|
||||
==============
|
||||
|
||||
* http://wandel.ca/homepage/execdis/
|
||||
@@ -1 +0,0 @@
|
||||
http://wandel.ca/homepage/execdis/
|
||||
@@ -0,0 +1,108 @@
|
||||
The Atari ST port
|
||||
=================
|
||||
|
||||
Atari ST executables
|
||||
--------------------
|
||||
|
||||
From: DaFi <[email protected]>
|
||||
|
||||
The specs for Atari ST executables (was listed as requested on www.wotsit.demon.co.uk/wanted.htm)...
|
||||
|
||||
applies for TOS, PRG, TTP, PRX, GTP, APP, ACC, ACX (different suffixes indicate different behavior of the program, i.e. TOS and TTP may not use the GEM GUI, while all the others may; only TTP and GTP can be called with parameters; ACC may be installed as desktop accessories; PRX and ACX mean the programs were disabled.
|
||||
|
||||
file structure:
|
||||
|
||||
+--------------------+---------------------------------------------------------------------------+
|
||||
| [2] WORD PRG_magic | magic value 0x601a |
|
||||
+--------------------+---------------------------------------------------------------------------+
|
||||
| [4] LONG PRG_tsize | size of text segment |
|
||||
+--------------------+---------------------------------------------------------------------------+
|
||||
| [4] LONG PRG_dsize | size of data segment |
|
||||
+--------------------+---------------------------------------------------------------------------+
|
||||
| [4] LONG PRG_bsize | size of bss segment |
|
||||
+--------------------+---------------------------------------------------------------------------+
|
||||
| [4] LONG PRG_ssize | size of symbol table |
|
||||
+--------------------+---------------------------------------------------------------------------+
|
||||
| [4] LONG PRG_res1 | reserved |
|
||||
+--------------------+---------------------------------------------------------------------------+
|
||||
| [4] LONG PRGFLAGS | bit vector that defines additional process characteristics, as follows: |
|
||||
| | |
|
||||
| | * **Bit 0 PF_FASTLOAD** - if set, only the BSS area is cleared, otherwise,|
|
||||
| | the program's whole memory is cleared before loading |
|
||||
| | * **Bit 1 PF_TTRAMLOAD** - if set, the program will be loaded into TT RAM |
|
||||
| | * **Bit 2 PF_TTRAMMEM** - if set, the program will be allowed to allocate |
|
||||
| | memory from TT RAM |
|
||||
| | |
|
||||
| | Bit 4 AND 5 as a two bit value with the following meanings: |
|
||||
| | |
|
||||
| | * 0 PF_PRIVATE - the processes entire memory space is considered private |
|
||||
| | * 1 PF_GLOBAL - the processes memory will be r/w-allowed for others |
|
||||
| | * 2 PF_SUPER - the memory will be r/w for itself and any supervisor proc |
|
||||
| | * 3 PF_READ - the memory will be readable by others |
|
||||
+--------------------+---------------------------------------------------------------------------+
|
||||
| [2] WORD ABSFLAG | is NON-ZERO, if the program does not need to be relocated |
|
||||
| | |
|
||||
| | is ZERO, if the program needs to be relocated |
|
||||
| | |
|
||||
| | note: since some TOS versions handle files with ABSFLAG>0 incorrectly, |
|
||||
| | this value should be set to ZERO also for programs that need to be |
|
||||
| | relocated, and the FIXUP_offset should be set to 0. |
|
||||
+--------------------+---------------------------------------------------------------------------+
|
||||
|
||||
From there on... (should be offset 0x1c)
|
||||
|
||||
[PRG_tsize] TEXT segment
|
||||
[PRG_dsize] DATA segment
|
||||
[PRG_ssize] Symbol table
|
||||
|
||||
[4] LONG FIXUP_offset - first LONG that needs to be relocated (offset to beginning of file)
|
||||
|
||||
From there on till the end of the file...
|
||||
|
||||
FIXUP table, with entries as follows:
|
||||
|
||||
[1] BYTE value
|
||||
|
||||
with value as follows:
|
||||
|
||||
- value=0 end of list
|
||||
- value=1 advance 254 bytes
|
||||
- value=2 to value=254 (only even values!) advance this many bytes and relocate the LONG found there.
|
||||
|
||||
That's it. You made it through to EOF.
|
||||
|
||||
A final note about fixing up (relocating) an executable: (pseudo-code)
|
||||
|
||||
The long value FIXUP_offset tells you your start adress. Let's call it "adr". So, now, that
|
||||
you have adr, read the first byte of the table.
|
||||
|
||||
(*) loop
|
||||
|
||||
- if it's 0, stop relocating -> you're done!
|
||||
- if it's 1, add 254 to adr and read the next byte, jump back to the asterisk (*)
|
||||
- if it's any other even value, add the value to your adr, then relocate the LONG at adr.
|
||||
(i.e. add the adress of the LONG to its value)
|
||||
|
||||
Useful resources
|
||||
----------------
|
||||
|
||||
* http://toshyp.atari.org/en/index.html
|
||||
|
||||
* http://www.lysator.liu.se/~celeborn/sync/atari/misc.html
|
||||
* http://www.lysator.liu.se/~celeborn/sync/atari/ATARI/F30.ZIP
|
||||
* http://www.lysator.liu.se/~celeborn/sync/atari/ATARI/FALCLIB6.ZIP
|
||||
* http://www.lysator.liu.se/~celeborn/sync/atari/ATARI/FALCREGS.ZIP
|
||||
|
||||
* http://fxr.watson.org/fxr/source/include/asm-m68k/atarihw.h?v=linux-2.4.22
|
||||
* http://lxr.linux.no/linux+v2.6.27/arch/m68k/atari/config.c#L664
|
||||
|
||||
* http://www.atari-forum.com/wiki/index.php/MFP_MK68901
|
||||
|
||||
* http://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/sys/arch/atari/stand/xxboot/ahdi-xxboot/xxboot.ahdi.S
|
||||
|
||||
AHDI args
|
||||
|
||||
* http://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/sys/arch/atari/stand/xxboot/wdboot/wdboot.S
|
||||
* http://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/sys/arch/atari/stand/xxboot/sdboot/sdboot.S
|
||||
* http://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/sys/arch/atari/stand/xxboot/fdboot/fdboot.S
|
||||
|
||||
@@ -1,57 +0,0 @@
|
||||
Subject: Atari ST executables
|
||||
From: DaFi <[email protected]>
|
||||
|
||||
The specs for Atari ST executables (was listed as requested on www.wotsit.demon.co.uk/wanted.htm)...
|
||||
|
||||
applies for TOS, PRG, TTP, PRX, GTP, APP, ACC, ACX (different suffixes indicate different behavior of the program, i.e. TOS and TTP may not use the GEM GUI, while all the others may; only TTP and GTP can be called with parameters; ACC may be installed as desktop accessories; PRX and ACX mean the programs were disabled.
|
||||
|
||||
file structure:
|
||||
[2] WORD PRG_magic - magic value 0x601a
|
||||
[4] LONG PRG_tsize - size of text segment
|
||||
[4] LONG PRG_dsize - size of data segment
|
||||
[4] LONG PRG_bsize - size of bss segment
|
||||
[4] LONG PRG_ssize - size of symbol table
|
||||
[4] LONG PRG_res1 - reserved
|
||||
[4] LONG PRGFLAGS - bit vector that defines additional process characteristics, as follows:
|
||||
Bit 0 PF_FASTLOAD - if set, only the BSS area is cleared, otherwise,
|
||||
the program´s whole memory is cleared before loading
|
||||
Bit 1 PF_TTRAMLOAD - if set, the program will be loaded into TT RAM
|
||||
Bit 2 PF_TTRAMMEM - if set, the program will be allowed to allocate
|
||||
memory from TT RAM
|
||||
Bit 4 AND 5 as a two bit value with the following meanings:
|
||||
0 PF_PRIVATE - the processes entire memory space is considered private
|
||||
1 PF_GLOBAL - the processes memory will be r/w-allowed for others
|
||||
2 PF_SUPER - the memory will be r/w for itself and any supervisor proc
|
||||
3 PF_READ - the memory will be readable by others
|
||||
[2] WORD ABSFLAG - is NON-ZERO, if the program does not need to be relocated
|
||||
is ZERO, if the program needs to be relocated
|
||||
note: since some TOS versions handle files with ABSFLAG>0 incorrectly,
|
||||
this value should be set to ZERO also for programs that need to be
|
||||
relocated, and the FIXUP_offset should be set to 0.
|
||||
|
||||
From there on... (should be offset 0x1c)
|
||||
[PRG_tsize] TEXT segment
|
||||
[PRG_dsize] DATA segment
|
||||
[PRG_ssize] Symbol table
|
||||
|
||||
[4] LONG FIXUP_offset - first LONG that needs to be relocated (offset to beginning of file)
|
||||
|
||||
From there on till the end of the file...
|
||||
FIXUP table, with entries as follows:
|
||||
[1] BYTE value - with value as follows:
|
||||
value=0 end of list
|
||||
value=1 advance 254 bytes
|
||||
value=2 to value=254 (only even values!) advance this many bytes and
|
||||
relocate the LONG found there
|
||||
That´s it. You made it through to EOF.
|
||||
|
||||
A final note about fixing up (relocating) an executable: (pseudo-code)
|
||||
The long value FIXUP_offset tells you your start adress. Let´s call it "adr". So, now, that
|
||||
you have adr, read the first byte of the table.
|
||||
(*) loop
|
||||
- if it´s 0, stop relocating -> you´re done!
|
||||
- if it´s 1, add 254 to adr and read the next byte, jump back to the asterisk (*)
|
||||
- if it´s any other even value, add the value to your adr, then relocate the LONG at adr.
|
||||
(i.e. add the adress of the LONG to its value)
|
||||
|
||||
dafi
|
||||
@@ -1,19 +0,0 @@
|
||||
http://toshyp.atari.org/en/index.html
|
||||
|
||||
http://www.lysator.liu.se/~celeborn/sync/atari/misc.html
|
||||
http://www.lysator.liu.se/~celeborn/sync/atari/ATARI/F30.ZIP
|
||||
http://www.lysator.liu.se/~celeborn/sync/atari/ATARI/FALCLIB6.ZIP
|
||||
http://www.lysator.liu.se/~celeborn/sync/atari/ATARI/FALCREGS.ZIP
|
||||
|
||||
|
||||
http://fxr.watson.org/fxr/source/include/asm-m68k/atarihw.h?v=linux-2.4.22
|
||||
http://lxr.linux.no/linux+v2.6.27/arch/m68k/atari/config.c#L664
|
||||
|
||||
http://www.atari-forum.com/wiki/index.php/MFP_MK68901
|
||||
|
||||
http://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/sys/arch/atari/stand/xxboot/ahdi-xxboot/xxboot.ahdi.S
|
||||
AHDI args
|
||||
http://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/sys/arch/atari/stand/xxboot/wdboot/wdboot.S
|
||||
http://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/sys/arch/atari/stand/xxboot/sdboot/sdboot.S
|
||||
http://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/sys/arch/atari/stand/xxboot/fdboot/fdboot.S
|
||||
|
||||
@@ -0,0 +1,21 @@
|
||||
The m68k port
|
||||
#############
|
||||
|
||||
The Motorola 68000 is an old CPU and not a reasonable target for Haiku. However, later models
|
||||
which are equipped with a memory management unit could work (slowly).
|
||||
|
||||
There is work in progress to target Atari, Amiga, and NeXT hardware platforms.
|
||||
|
||||
Todo list
|
||||
=========
|
||||
|
||||
- optimization: remove M68KPagingStructures[*]::UpdateAllPageDirs() and just allocate all the kernel page root entries at boot and be done with it. It's not very big anyway.
|
||||
- possibly other optimizations in the VM code due to not supporting SMP?
|
||||
|
||||
Target platforms information
|
||||
============================
|
||||
|
||||
.. toctree::
|
||||
|
||||
/kernel/arch/m68k/amiga
|
||||
/kernel/arch/m68k/atari
|
||||
@@ -0,0 +1,19 @@
|
||||
Notes on a possible BeBox Haiku port
|
||||
====================================
|
||||
|
||||
Bootloader
|
||||
----------
|
||||
|
||||
The BeBox ROM expects the bootloader to be in PEF format, as was produced by the CodeWarrior
|
||||
compiler used by Be. However, support for this format in binutils seems incomplete.
|
||||
|
||||
references
|
||||
----------
|
||||
|
||||
* http://www.netbsd.org/ports/bebox/
|
||||
* http://netbsd.2816.n7.nabble.com/BeBox-memory-configuration-td278318.html
|
||||
|
||||
QEMU target
|
||||
-----------
|
||||
|
||||
http://qemu-project.org/Features/BeBox
|
||||
@@ -1,7 +0,0 @@
|
||||
Notes on a possible BeBox Haiku port -*- org -*-
|
||||
|
||||
* references
|
||||
http://www.netbsd.org/ports/bebox/
|
||||
http://netbsd.2816.n7.nabble.com/BeBox-memory-configuration-td278318.html
|
||||
** QEMU target
|
||||
http://qemu-project.org/Features/BeBox
|
||||
@@ -0,0 +1,17 @@
|
||||
The Apple Macintosh port
|
||||
======================================
|
||||
|
||||
The current target is "new world" machines, which have a more complete and reliable implementation
|
||||
of Open Firmware.
|
||||
|
||||
* http://www.debian.org/releases/stable/powerpc/ch05s01.html.en
|
||||
* http://www.kernelthread.com/mac/osx/arch_boot.html
|
||||
* http://playground.sun.com/1275/mejohnson/
|
||||
* http://homepages.gold.ac.uk/suzanne/startup.html
|
||||
* http://www.netbsd.org/ports/macppc/SystemDisk-tutorial/
|
||||
* http://www.netneurotic.net/mac/openfirmware.html
|
||||
* http://www.netbsd.org/ports/macppc/faq.html
|
||||
* http://mail-index.netbsd.org/port-macppc/1999/03/21/0001.html
|
||||
* http://mail-index.netbsd.org/port-macppc/1999/06/25/0006.html
|
||||
* http://ps-2.kev009.com/solinno.co.uk/7043-140/files/docs/ {OF,PReP}
|
||||
* http://www.openfirmware.org/1275/bindings/chrp/
|
||||
@@ -1,11 +0,0 @@
|
||||
http://www.debian.org/releases/stable/powerpc/ch05s01.html.en
|
||||
http://www.kernelthread.com/mac/osx/arch_boot.html
|
||||
http://playground.sun.com/1275/mejohnson/
|
||||
http://homepages.gold.ac.uk/suzanne/startup.html
|
||||
http://www.netbsd.org/ports/macppc/SystemDisk-tutorial/
|
||||
http://www.netneurotic.net/mac/openfirmware.html
|
||||
http://www.netbsd.org/ports/macppc/faq.html
|
||||
http://mail-index.netbsd.org/port-macppc/1999/03/21/0001.html
|
||||
http://mail-index.netbsd.org/port-macppc/1999/06/25/0006.html
|
||||
http://ps-2.kev009.com/solinno.co.uk/7043-140/files/docs/ {OF,PReP}
|
||||
http://www.openfirmware.org/1275/bindings/chrp/
|
||||
@@ -0,0 +1,24 @@
|
||||
The PowerPC port
|
||||
================
|
||||
|
||||
PowerPC was the first non-x86architecture for which a port of Haiku was attempted. The initial
|
||||
target was the (then recently released) Mac Mini, but of course the BeBox was in everyone's mind
|
||||
as a possible target for this port.
|
||||
|
||||
This port went as far as starting the kernel, but then difficulties in implementing the Mac Mini
|
||||
PCI bus driver stopped it.
|
||||
|
||||
Later on, some work as done on adding support for the Sam460ex development board, after a donation
|
||||
of one to one of the Haiku developers.
|
||||
|
||||
Recently, the lack of easily available and affordable PowerPC hardware has reduced interest in this
|
||||
port.
|
||||
|
||||
Platform specific details
|
||||
-------------------------
|
||||
|
||||
.. toctree::
|
||||
|
||||
/kernel/arch/ppc/bebox
|
||||
/kernel/arch/ppc/mac
|
||||
/kernel/arch/ppc/sam460ex
|
||||
@@ -0,0 +1,119 @@
|
||||
The Sam460ex Haiku port
|
||||
=======================
|
||||
|
||||
Complications for this port comes from the fact that the CPU used was designed for embedded devices,
|
||||
and has a much simpler MMU than the one on desktop machines. As a result, completely different
|
||||
memory management code needs to be written.
|
||||
|
||||
U-Boot commands
|
||||
---------------
|
||||
|
||||
no-fdt no-initrd
|
||||
****************
|
||||
|
||||
seems the U-Boot input buffer is quite limited, can't paste much more on single line in minicom
|
||||
|
||||
setenv ipaddr 192.168.4.100; tftpboot 0x4000000 192.168.4.2:haiku_loader_linux.ub; bootm 0x4000000
|
||||
|
||||
with FDT and tgz as initrd
|
||||
**************************
|
||||
|
||||
setenv ipaddr 192.168.4.100
|
||||
tftpboot 0x4000000 192.168.4.2:haiku_loader_linux.ub
|
||||
tftpboot 0x8000000 192.168.4.2:haiku_initrd.ub
|
||||
tftpboot 0xc000000 192.168.4.2:sam460ex.dtb
|
||||
fdt addr 0xc000000
|
||||
fdt header
|
||||
bootm 0x4000000 0x8000000 0xc000000 plop
|
||||
|
||||
for environment
|
||||
***************
|
||||
|
||||
setenv booth1 'setenv ipaddr 192.168.4.100; tftpboot 0x4000000 192.168.4.2:haiku_loader_linux.ub'
|
||||
setenv booth2 'tftpboot 0x8000000 192.168.4.2:haiku_initrd.ub'
|
||||
setenv booth3 'tftpboot 0xc000000 192.168.4.2:sam460ex.dtb'
|
||||
setenv booth4 'bootm 0x4000000 0x8000000 0xc000000 plop'
|
||||
setenv booth 'run booth1; run booth2; run booth3; run booth4'
|
||||
saveenv
|
||||
run booth
|
||||
|
||||
TODOs
|
||||
-----
|
||||
|
||||
* U-Boot API?
|
||||
* move Partenope hack to proper official U-Boot API?
|
||||
* reserved regs?
|
||||
|
||||
BoardSetup +=:?
|
||||
TARGET_BOOT_CCFLAGS += -ffixed-r2 -ffixed-r14 -ffixed-r29 ;
|
||||
TARGET_BOOT_C++FLAGS += -ffixed-r2 -ffixed-r14 -ffixed-r29 ;
|
||||
|
||||
* kdebug/disasm/ppc http://code.google.com/p/ppcd/
|
||||
|
||||
Other ports
|
||||
-----------
|
||||
|
||||
* `AROS port <https://www.gitorious.org/aros/aros/commits/sam460>`_
|
||||
* `Linux port <http://kernel.org/doc/ols/2003/ols2003-pages-340-350.pdf>`_
|
||||
* `NetBSD <https://wiki.netbsd.org/users/rkujawa/sam4x0/>`_
|
||||
|
||||
PowerPC information
|
||||
-------------------
|
||||
|
||||
Classic
|
||||
*******
|
||||
|
||||
* http://class.ee.iastate.edu/cpre211/labs/quickrefPPC.html
|
||||
* http://www.ibm.com/developerworks/library/l-ppc/
|
||||
* http://www.csd.uwo.ca/~mburrel/stuff/ppc-asm.html
|
||||
|
||||
Book-E
|
||||
******
|
||||
|
||||
* http://www.linux-kvm.org/page/PowerPC_Book_E_MMU
|
||||
* http://wiki.freebsd.org/powerpc/BookE
|
||||
* http://en.wikipedia.org/wiki/Memory_management_unit#PowerPC
|
||||
|
||||
ePAPR
|
||||
*****
|
||||
|
||||
* https://www.power.org/wp-content/uploads/2012/06/Power_ePAPR_APPROVED_v1.1.pdf
|
||||
* PPC440: http://elinux.org/Book_E_and_PPC_440
|
||||
|
||||
amcc 4x0
|
||||
********
|
||||
|
||||
* http://c0ff33.net/drop/PPC440_UM2013.pdf
|
||||
* http://www.embeddeddeveloper.com/assets/processors/amcc/datasheets/PP460EX_DS2063.pdf
|
||||
|
||||
Freescale 440
|
||||
*************
|
||||
|
||||
This version has a different mmu!!
|
||||
|
||||
* http://www.freescale.com/files/32bit/doc/white_paper/POWRPCARCPRMRM.pdf
|
||||
|
||||
FDT
|
||||
---
|
||||
|
||||
* http://www.denx.de/wiki/U-Boot/UBootFdtInfo
|
||||
* http://wiki.freebsd.org/FlattenedDeviceTree#Supporting_library_.28libfdt.29
|
||||
* (see also arm docs)
|
||||
|
||||
Sam440 dts
|
||||
**********
|
||||
|
||||
* http://lxr.linux.no/linux+v3.4/arch/powerpc/boot/dts/sam440ep.dts
|
||||
* Sam460ex dts: identical to amcc,Canyonlands !?
|
||||
* http://www.denx.de/wiki/view/DULG/Appendix#Section_13.1.
|
||||
|
||||
OpenFirmware framebuffer
|
||||
************************
|
||||
|
||||
(not really usable from U-Boot (yet?))
|
||||
|
||||
* http://www.feedface.com/howto/forth.html
|
||||
* http://mail-index.netbsd.org/port-macppc/2004/12/13/0046.html
|
||||
* http://lists.freebsd.org/pipermail/svn-src-user/2012-January/004806.html
|
||||
* http://www.openfirmware.info/Bindings
|
||||
|
||||
@@ -1,76 +0,0 @@
|
||||
Notes on Sam460ex Haiku port -*- org -*-
|
||||
|
||||
* U-Boot commands
|
||||
** no-fdt no-initrd
|
||||
# (seems the U-Boot input buffer is quite limited, can't paste much more on single line in minicom)
|
||||
setenv ipaddr 192.168.4.100; tftpboot 0x4000000 192.168.4.2:haiku_loader_linux.ub; bootm 0x4000000
|
||||
** with FDT and tgz as initrd
|
||||
setenv ipaddr 192.168.4.100
|
||||
tftpboot 0x4000000 192.168.4.2:haiku_loader_linux.ub
|
||||
tftpboot 0x8000000 192.168.4.2:haiku_initrd.ub
|
||||
tftpboot 0xc000000 192.168.4.2:sam460ex.dtb
|
||||
fdt addr 0xc000000
|
||||
fdt header
|
||||
bootm 0x4000000 0x8000000 0xc000000 plop
|
||||
** for environment:
|
||||
setenv booth1 'setenv ipaddr 192.168.4.100; tftpboot 0x4000000 192.168.4.2:haiku_loader_linux.ub'
|
||||
setenv booth2 'tftpboot 0x8000000 192.168.4.2:haiku_initrd.ub'
|
||||
setenv booth3 'tftpboot 0xc000000 192.168.4.2:sam460ex.dtb'
|
||||
setenv booth4 'bootm 0x4000000 0x8000000 0xc000000 plop'
|
||||
setenv booth 'run booth1; run booth2; run booth3; run booth4'
|
||||
saveenv
|
||||
run booth
|
||||
|
||||
|
||||
* TODO U-Boot API?
|
||||
** TODO move Partenope hack to proper official U-Boot API?
|
||||
** TODO reserved regs?
|
||||
BoardSetup +=:?
|
||||
TARGET_BOOT_CCFLAGS += -ffixed-r2 -ffixed-r14 -ffixed-r29 ;
|
||||
TARGET_BOOT_C++FLAGS += -ffixed-r2 -ffixed-r14 -ffixed-r29 ;
|
||||
|
||||
* Other ports
|
||||
** AROS port
|
||||
https://www.gitorious.org/aros/aros/commits/sam460
|
||||
** Linux port
|
||||
http://kernel.org/doc/ols/2003/ols2003-pages-340-350.pdf
|
||||
** NetBSD
|
||||
https://wiki.netbsd.org/users/rkujawa/sam4x0/
|
||||
|
||||
* PPC
|
||||
** Classic
|
||||
http://class.ee.iastate.edu/cpre211/labs/quickrefPPC.html
|
||||
http://www.ibm.com/developerworks/library/l-ppc/
|
||||
http://www.csd.uwo.ca/~mburrel/stuff/ppc-asm.html
|
||||
** Book-E
|
||||
http://www.linux-kvm.org/page/PowerPC_Book_E_MMU
|
||||
http://wiki.freebsd.org/powerpc/BookE
|
||||
http://en.wikipedia.org/wiki/Memory_management_unit#PowerPC
|
||||
** ePAPR
|
||||
https://www.power.org/wp-content/uploads/2012/06/Power_ePAPR_APPROVED_v1.1.pdf
|
||||
** 440
|
||||
http://elinux.org/Book_E_and_PPC_440
|
||||
*** amcc 4x0
|
||||
http://c0ff33.net/drop/PPC440_UM2013.pdf
|
||||
http://www.embeddeddeveloper.com/assets/processors/amcc/datasheets/PP460EX_DS2063.pdf
|
||||
*** Freescale 440 (different mmu!!)
|
||||
http://www.freescale.com/files/32bit/doc/white_paper/POWRPCARCPRMRM.pdf
|
||||
|
||||
* FDT
|
||||
http://www.denx.de/wiki/U-Boot/UBootFdtInfo
|
||||
http://wiki.freebsd.org/FlattenedDeviceTree#Supporting_library_.28libfdt.29
|
||||
(see also arm docs)
|
||||
** Sam440 dts
|
||||
http://lxr.linux.no/linux+v3.4/arch/powerpc/boot/dts/sam440ep.dts
|
||||
** Sam460ex dts: identical to amcc,Canyonlands !?
|
||||
http://www.denx.de/wiki/view/DULG/Appendix#Section_13.1.
|
||||
|
||||
* OF framebuffer
|
||||
(not really usable from U-Boot (yet?))
|
||||
http://www.feedface.com/howto/forth.html
|
||||
http://mail-index.netbsd.org/port-macppc/2004/12/13/0046.html
|
||||
http://lists.freebsd.org/pipermail/svn-src-user/2012-January/004806.html
|
||||
http://www.openfirmware.info/Bindings
|
||||
|
||||
* TODO kdebug/disasm/ppc
|
||||
http://code.google.com/p/ppcd/
|
||||
@@ -1,32 +0,0 @@
|
||||
The SPARC architecture has 32 integer registers, divided as follows:
|
||||
|
||||
- global registers (g0-g7)
|
||||
- input (i0-i7)
|
||||
- local (l0-l7)
|
||||
- output (o0-o7)
|
||||
|
||||
Parameter passing and return is done using the output registers, which are
|
||||
generally considered scratch registers and can be corrupted by the callee. The
|
||||
caller must take care of preserving them.
|
||||
|
||||
The input and local registers are callee-saved, but we have hardware assistance
|
||||
in the form of a register window. There is an instruction to shift the registers
|
||||
so that:
|
||||
- o registers become i registers
|
||||
- local and output registers are replaced with fresh sets, for use by the
|
||||
current function
|
||||
- global registers are not affected
|
||||
|
||||
Note that as a side-effect, o7 is moved to i7, this is convenient because these
|
||||
are usually the stack and frame pointers, respectively. So basically this sets
|
||||
the frame pointer for free.
|
||||
|
||||
Simple enough functions may end up using just the o registers, in that case
|
||||
nothing special is necessary, of course.
|
||||
|
||||
When shifting the register window, the extra registers come from the register
|
||||
stack in the CPU. This is not infinite, however, most implementations of SPARC
|
||||
will only have 8 windows available. When the internal stack is full, an overflow
|
||||
trap is raised, and the handler must free up old windows by storing them on the
|
||||
stack, likewise, when the internal stack is empty, an underflow trap must fill
|
||||
it back from the stack-saved data.
|
||||
@@ -1,37 +0,0 @@
|
||||
The SPARC CPU is not designed to gracefully handle misaligned accesses.
|
||||
You can access a single byte at any address, but 16-bit access only at even
|
||||
addresses, 32bit access at multiple of 4 addresses, etc.
|
||||
|
||||
For example, on x86, such accesses are not a problem, it is allowed and handled
|
||||
directly by the instructions doing the access. So there is no performance cost.
|
||||
|
||||
On SPARC, however, such accesses will cause a SIGBUS. This means a trap handler
|
||||
has to catch the misaligned access and do it in software, byte by byte, then
|
||||
give back control to the application. This is, of course, very slow, so we
|
||||
should avoid it when possible.
|
||||
|
||||
Fortunately, gcc knows about this, and will normally do the right thing:
|
||||
- For usual variables and structures, it will make sure to lay them out so that
|
||||
they are aligned. It relies on stack alignment, as well as malloc returning
|
||||
sufficiently aligned memory (as required by the C standard).
|
||||
- On packed structure, gcc knows the data is misaligned, and will automatically
|
||||
use the appropriate way to access it (most likely, byte-by-byte).
|
||||
|
||||
This leaves us with two undesirable cases:
|
||||
- Pointer arithmetics and casting. When computing addresses manually, it's
|
||||
possible to generate a misaligned address and cast it to a type with a wider
|
||||
alignment requirement. In this case, gcc may access the pointer using a
|
||||
multi byte instruction and cause a SIGBUS. Solution: make sure the struct
|
||||
is aligned, or declare it as packed so unaligned access are used instead.
|
||||
- Access to hardware: it is a common pattern to declare a struct as packed,
|
||||
and map it to hardware registers. If the alignment isn't known, gcc will use
|
||||
byte by byte access. It seems volatile would cause gcc to use the proper way
|
||||
to access the struct, assuming that a volatile value is necessarily
|
||||
aligned as it should.
|
||||
|
||||
In the end, we just need to be careful about pointer math resulting in unalined
|
||||
access. -Wcast-align helps with that, but it also raises a lot of false positives
|
||||
(where the alignment is preserved even when casting to other types). So we
|
||||
enable it only as a warning for now. We will need to ceck the sigbus handler to
|
||||
identify places where we do a lot of misaligned accesses that trigger it, and
|
||||
rework the code as needed. But in general, except for these cases, we're fine.
|
||||
@@ -1,116 +0,0 @@
|
||||
Notes on the Ultrasparc MMUs
|
||||
============================
|
||||
|
||||
First, a word of warning: the MMU was different in SPARCv8 (32bit)
|
||||
implementations, and it was changed again on newer CPUs.
|
||||
|
||||
The Ultrasparc-II we are supporting for now is documented in the Ultrasparc
|
||||
user manual. There were some minor changes in the Ultrasparc-III to accomodate
|
||||
larger physical addresses. This was then standardized as JPS1, and Fujitsu
|
||||
also implemented it.
|
||||
|
||||
Later on, the design was changed again, for example Ultrasparc T2 (UA2005
|
||||
architecture) uses a different data structure format to enlarge, again, the
|
||||
physical and virtual address tags.
|
||||
|
||||
For now te implementation is focused on Ultrasparc-II because that's what I
|
||||
have at hand, later on we will need support for the more recent systems.
|
||||
|
||||
Ultrasparc-II MMU
|
||||
=================
|
||||
|
||||
There are actually two separate units for the instruction and data address
|
||||
spaces, known as I-MMU and D-MMU. They each implement a TLB (translation
|
||||
lookaside buffer) for the recently accessed pages.
|
||||
|
||||
This is pretty much all there is to the MMU hardware. No hardware page table
|
||||
walk is provided. However, there is some support for implementing a TSB
|
||||
(Translation Storage Buffer) in the form of providing a way to compute an
|
||||
address into that buffer where the data for a missing page could be.
|
||||
|
||||
It is up to software to manage the TSB (globally or per-process) and in general
|
||||
keep track of the mappings. This means we are relatively free to manage things
|
||||
however we want, as long as eventually we can feed the iTLB and dTLB with the
|
||||
relevant data from the MMU trap handler.
|
||||
|
||||
To make sure we can handle the fault without recursing, we need to pin a few
|
||||
items in place:
|
||||
|
||||
In the TLB:
|
||||
- TLB miss handler code
|
||||
- TSB and any linked data that the TLB miss handler may need
|
||||
- asynchronous trap handlers and data
|
||||
|
||||
In the TSB:
|
||||
- TSB-miss handling code
|
||||
- Interrupt handlers code and data
|
||||
|
||||
So, from a given virtual address (assuming we are using only 8K pages and a
|
||||
512 entry TSB to keep things simple):
|
||||
|
||||
VA63-44 are unused and must be a sign extension of bit 43
|
||||
VA43-22 are the 'tag' used to match a TSB entry with a virtual address
|
||||
VA21-13 are the offset in the TSB at which to find a candidate entry
|
||||
VA12-0 are the offset in the 8K page, and used to form PA12-0 for the access
|
||||
|
||||
Inside the TLBs, VA63-13 is stored, so there can be multiple entries matching
|
||||
the same tag active at the same time, even when there is only one in the TSB.
|
||||
The entries are rotated using a simple LRU scheme, unless they are locked of
|
||||
course. Be careful to not fill a TLB with only locked entries! Also one must
|
||||
take care of not inserting a new mapping for a given VA without first removing
|
||||
any possible previous one (no need to worry about this when handling a TLB
|
||||
miss however, as in that case we obviously know that there was no previous
|
||||
entry).
|
||||
|
||||
Entries also have a "context". This could for example be mapped to the process
|
||||
ID, allowing to easily clear all entries related to a specific context.
|
||||
|
||||
TSB entries format
|
||||
==================
|
||||
|
||||
Each entry is composed of two 64bit values: "Tag" and "Data". The data uses the
|
||||
same format as the TLB entries, however the tag is different.
|
||||
|
||||
They are as follow:
|
||||
|
||||
Tag
|
||||
---
|
||||
|
||||
Bit 63: 'G' indicating a global entry, the context should be ignored.
|
||||
Bits 60-48: context ID (13 bits)
|
||||
Bits 41-0: VA63-22 as the 'tag' to identify this entry
|
||||
|
||||
Data
|
||||
----
|
||||
|
||||
Bit 63: 'V' indicating a valid entry, if it's 0 the entry is unused.
|
||||
Bits 62-61: size: 8K, 64K, 512K, 4MB
|
||||
Bit 60: NFO, indicating No Fault Only
|
||||
Bit 59: Invert Endianness of accesses to this page
|
||||
Bits 58-50: reserved for use by software
|
||||
Bits 49-41: reserved for diagnostics
|
||||
Bits 40-13: Physical Address<40-13>
|
||||
Bits 12-7: reserved for use by software
|
||||
Bit 6: Lock in TLB
|
||||
Bit 5: Cachable physical
|
||||
Bit 4: Cachable virtual
|
||||
Bit 3: Access has side effects (HW is mapped here, or DMA shared RAM)
|
||||
Bit 2: Privileged
|
||||
Bit 1: Writable
|
||||
Bit 0: Global
|
||||
|
||||
TLB internal tag
|
||||
----------------
|
||||
|
||||
Bits 63-13: VA<63-13>
|
||||
Bits 12-0: context ID
|
||||
|
||||
Conveniently, a 512 entries TSB fits exactly in a 8K page, so it can be locked
|
||||
in the TLB with a single entry there. However, it may be a wise idea to instead
|
||||
map 64K (or more) of RAM locked as a single entry for all the things that needs
|
||||
to be accessed by the TLB miss trap handler, so we minimize the use of TLB
|
||||
entries.
|
||||
|
||||
Likewise, it may be useful to use 64K pages instead of 8K whenever possible.
|
||||
The hardware provides some support for mixing the two sizes but it makes things
|
||||
a bit more complex. Let's start out with simpler things.
|
||||
@@ -1,97 +0,0 @@
|
||||
Openboot is Sun's implementation of Open Firmware. So we should be able to share
|
||||
a lot of code with the PowerPC port. There are some differences however.
|
||||
|
||||
Executable format
|
||||
=================
|
||||
|
||||
PowerPC uses COFF. Sparc uses a.out, which is a lot simpler. According to the
|
||||
spec, some fields should be zeroed out, but they say implementation may chose
|
||||
to allow other values, so a standard a.out file works as well.
|
||||
|
||||
It used to be possible to generate one with objcopy, but support was removed,
|
||||
so we now use elf2aout (imported from FreeBSD).
|
||||
|
||||
The file is first loaded at 4000, then relocated to its load address (we use
|
||||
202000 and executed there)
|
||||
|
||||
Openfirmware prompt
|
||||
===================
|
||||
|
||||
To get the prompt on display, use STOP+A at boot until you get the "ok" prompt.
|
||||
On some machines, if no keyboard is detected, the ROM will assume it is set up
|
||||
in headless mode, and will expect a BREAK+A on the serial port.
|
||||
|
||||
STOP+N resets all variables to default values (in case you messed up input or
|
||||
output, for example).
|
||||
|
||||
Useful commands
|
||||
===============
|
||||
|
||||
Disable autoboot to get to the openboot prompt and stop there
|
||||
-------------------------------------------------------------
|
||||
|
||||
setenv auto-boot? false
|
||||
|
||||
Configuring for keyboard/framebuffer io
|
||||
---------------------------------------
|
||||
|
||||
setenv screen-#columns 160
|
||||
setenv screen-#rows 49
|
||||
setenv output-device screen:r1920x1080x60
|
||||
setenv input-device keyboard
|
||||
|
||||
Configuring openboot for serial port
|
||||
------------------------------------
|
||||
|
||||
setenv ttya-mode 38400,8,n,1,-
|
||||
setenv output-device ttya
|
||||
setenv input-device ttya
|
||||
reset
|
||||
|
||||
Boot from network
|
||||
-----------------
|
||||
|
||||
static ip:
|
||||
This currently works best, because rarp does not let the called binary know the
|
||||
IP address. We need the IP address if we want to mount the root filesystem using
|
||||
remote_disk server.
|
||||
|
||||
boot net:192.168.1.2,somefile,192.168.1.89
|
||||
|
||||
The first IP is the server from which to download (using TFTP), the second is
|
||||
the client IP to use. Once the bootloader starts, it will detect that it is
|
||||
booted from network and look for a the remote_disk_server on the same machine.
|
||||
|
||||
rarp:
|
||||
|
||||
This needs a reverse ARP server (easy to setup on any Linux system). You need
|
||||
to list the MAC address of the SPARC machine in /etc/ethers on the server. The
|
||||
machine will get its IP, and will use TFTP to the server which replied, to get
|
||||
the boot file from there.
|
||||
|
||||
boot net:,somefile
|
||||
|
||||
(net is an alias to the network card and also sets the load address: /pci@1f,4000/network@1,1)
|
||||
|
||||
dhcp:
|
||||
|
||||
This needs a DHCP/BOOTP server configured to send the info about where to find
|
||||
the file to load and boot.
|
||||
|
||||
boot net:dhcp
|
||||
|
||||
|
||||
|
||||
Debugging
|
||||
---------
|
||||
|
||||
202000 dis (disassemble starting at 202000 until next return instruction)
|
||||
|
||||
4000 1000 dump (dump 1000 bytes from address 4000)
|
||||
|
||||
.registers (show global registers)
|
||||
.locals (show local/windowed registers)
|
||||
|
||||
%pc dis (disassemble code being exectuted)
|
||||
|
||||
ctrace (backtrace)
|
||||
@@ -0,0 +1,335 @@
|
||||
The SPARC port
|
||||
##############
|
||||
|
||||
The SPARC port targets various machines from Sun product lineup. The initial effort is on the
|
||||
Ultra 60 and Ultra 5, with plans to latter add the Sun T5120 and its newer CPU. This may change
|
||||
depending on hardware donations and developer interest.
|
||||
|
||||
Support for 32-bit versions of SPARC is currently not planned.
|
||||
|
||||
SPARC ABI
|
||||
=========
|
||||
|
||||
The SPARC architecture has 32 integer registers, divided as follows:
|
||||
|
||||
- global registers (g0-g7)
|
||||
- input (i0-i7)
|
||||
- local (l0-l7)
|
||||
- output (o0-o7)
|
||||
|
||||
Parameter passing and return is done using the output registers, which are
|
||||
generally considered scratch registers and can be corrupted by the callee. The
|
||||
caller must take care of preserving them.
|
||||
|
||||
The input and local registers are callee-saved, but we have hardware assistance
|
||||
in the form of a register window. There is an instruction to shift the registers
|
||||
so that:
|
||||
|
||||
- o registers become i registers
|
||||
- local and output registers are replaced with fresh sets, for use by the
|
||||
current function
|
||||
- global registers are not affected
|
||||
|
||||
Note that as a side-effect, o7 is moved to i7, this is convenient because these
|
||||
are usually the stack and frame pointers, respectively. So basically this sets
|
||||
the frame pointer for free.
|
||||
|
||||
Simple enough functions may end up using just the o registers, in that case
|
||||
nothing special is necessary, of course.
|
||||
|
||||
When shifting the register window, the extra registers come from the register
|
||||
stack in the CPU. This is not infinite, however, most implementations of SPARC
|
||||
will only have 8 windows available. When the internal stack is full, an overflow
|
||||
trap is raised, and the handler must free up old windows by storing them on the
|
||||
stack, likewise, when the internal stack is empty, an underflow trap must fill
|
||||
it back from the stack-saved data.
|
||||
|
||||
Misaligned memory access
|
||||
========================
|
||||
|
||||
The SPARC CPU is not designed to gracefully handle misaligned accesses.
|
||||
You can access a single byte at any address, but 16-bit access only at even
|
||||
addresses, 32bit access at multiple of 4 addresses, etc.
|
||||
|
||||
For example, on x86, such accesses are not a problem, it is allowed and handled
|
||||
directly by the instructions doing the access. So there is no performance cost.
|
||||
|
||||
On SPARC, however, such accesses will cause a SIGBUS. This means a trap handler
|
||||
has to catch the misaligned access and do it in software, byte by byte, then
|
||||
give back control to the application. This is, of course, very slow, so we
|
||||
should avoid it when possible.
|
||||
|
||||
Fortunately, gcc knows about this, and will normally do the right thing:
|
||||
|
||||
- For usual variables and structures, it will make sure to lay them out so that
|
||||
they are aligned. It relies on stack alignment, as well as malloc returning
|
||||
sufficiently aligned memory (as required by the C standard).
|
||||
- On packed structure, gcc knows the data is misaligned, and will automatically
|
||||
use the appropriate way to access it (most likely, byte-by-byte).
|
||||
|
||||
This leaves us with two undesirable cases:
|
||||
|
||||
- Pointer arithmetics and casting. When computing addresses manually, it's
|
||||
possible to generate a misaligned address and cast it to a type with a wider
|
||||
alignment requirement. In this case, gcc may access the pointer using a
|
||||
multi byte instruction and cause a SIGBUS. Solution: make sure the struct
|
||||
is aligned, or declare it as packed so unaligned access are used instead.
|
||||
- Access to hardware: it is a common pattern to declare a struct as packed,
|
||||
and map it to hardware registers. If the alignment isn't known, gcc will use
|
||||
byte by byte access. It seems volatile would cause gcc to use the proper way
|
||||
to access the struct, assuming that a volatile value is necessarily
|
||||
aligned as it should.
|
||||
|
||||
In the end, we just need to be careful about pointer math resulting in unalined
|
||||
access. -Wcast-align helps with that, but it also raises a lot of false positives
|
||||
(where the alignment is preserved even when casting to other types). So we
|
||||
enable it only as a warning for now. We will need to ceck the sigbus handler to
|
||||
identify places where we do a lot of misaligned accesses that trigger it, and
|
||||
rework the code as needed. But in general, except for these cases, we're fine.
|
||||
|
||||
The Ultrasparc MMUs
|
||||
============================
|
||||
|
||||
First, a word of warning: the MMU was different in SPARCv8 (32bit)
|
||||
implementations, and it was changed again on newer CPUs.
|
||||
|
||||
The Ultrasparc-II we are supporting for now is documented in the Ultrasparc
|
||||
user manual. There were some minor changes in the Ultrasparc-III to accomodate
|
||||
larger physical addresses. This was then standardized as JPS1, and Fujitsu
|
||||
also implemented it.
|
||||
|
||||
Later on, the design was changed again, for example Ultrasparc T2 (UA2005
|
||||
architecture) uses a different data structure format to enlarge, again, the
|
||||
physical and virtual address tags.
|
||||
|
||||
For now te implementation is focused on Ultrasparc-II because that's what I
|
||||
have at hand, later on we will need support for the more recent systems.
|
||||
|
||||
Ultrasparc-II MMU
|
||||
-----------------
|
||||
|
||||
There are actually two separate units for the instruction and data address
|
||||
spaces, known as I-MMU and D-MMU. They each implement a TLB (translation
|
||||
lookaside buffer) for the recently accessed pages.
|
||||
|
||||
This is pretty much all there is to the MMU hardware. No hardware page table
|
||||
walk is provided. However, there is some support for implementing a TSB
|
||||
(Translation Storage Buffer) in the form of providing a way to compute an
|
||||
address into that buffer where the data for a missing page could be.
|
||||
|
||||
It is up to software to manage the TSB (globally or per-process) and in general
|
||||
keep track of the mappings. This means we are relatively free to manage things
|
||||
however we want, as long as eventually we can feed the iTLB and dTLB with the
|
||||
relevant data from the MMU trap handler.
|
||||
|
||||
To make sure we can handle the fault without recursing, we need to pin a few
|
||||
items in place:
|
||||
|
||||
In the TLB:
|
||||
|
||||
- TLB miss handler code
|
||||
- TSB and any linked data that the TLB miss handler may need
|
||||
- asynchronous trap handlers and data
|
||||
|
||||
In the TSB:
|
||||
|
||||
- TSB-miss handling code
|
||||
- Interrupt handlers code and data
|
||||
|
||||
So, from a given virtual address (assuming we are using only 8K pages and a
|
||||
512 entry TSB to keep things simple):
|
||||
|
||||
VA63-44 are unused and must be a sign extension of bit 43
|
||||
VA43-22 are the 'tag' used to match a TSB entry with a virtual address
|
||||
VA21-13 are the offset in the TSB at which to find a candidate entry
|
||||
VA12-0 are the offset in the 8K page, and used to form PA12-0 for the access
|
||||
|
||||
Inside the TLBs, VA63-13 is stored, so there can be multiple entries matching
|
||||
the same tag active at the same time, even when there is only one in the TSB.
|
||||
The entries are rotated using a simple LRU scheme, unless they are locked of
|
||||
course. Be careful to not fill a TLB with only locked entries! Also one must
|
||||
take care of not inserting a new mapping for a given VA without first removing
|
||||
any possible previous one (no need to worry about this when handling a TLB
|
||||
miss however, as in that case we obviously know that there was no previous
|
||||
entry).
|
||||
|
||||
Entries also have a "context". This could for example be mapped to the process
|
||||
ID, allowing to easily clear all entries related to a specific context.
|
||||
|
||||
TSB entries format
|
||||
------------------
|
||||
|
||||
Each entry is composed of two 64bit values: "Tag" and "Data". The data uses the
|
||||
same format as the TLB entries, however the tag is different.
|
||||
|
||||
They are as follow:
|
||||
|
||||
Tag
|
||||
***
|
||||
|
||||
Bit 63: 'G' indicating a global entry, the context should be ignored.
|
||||
Bits 60-48: context ID (13 bits)
|
||||
Bits 41-0: VA63-22 as the 'tag' to identify this entry
|
||||
|
||||
Data
|
||||
****
|
||||
|
||||
Bit 63: 'V' indicating a valid entry, if it's 0 the entry is unused.
|
||||
Bits 62-61: size: 8K, 64K, 512K, 4MB
|
||||
Bit 60: NFO, indicating No Fault Only
|
||||
Bit 59: Invert Endianness of accesses to this page
|
||||
Bits 58-50: reserved for use by software
|
||||
Bits 49-41: reserved for diagnostics
|
||||
Bits 40-13: Physical Address<40-13>
|
||||
Bits 12-7: reserved for use by software
|
||||
Bit 6: Lock in TLB
|
||||
Bit 5: Cachable physical
|
||||
Bit 4: Cachable virtual
|
||||
Bit 3: Access has side effects (HW is mapped here, or DMA shared RAM)
|
||||
Bit 2: Privileged
|
||||
Bit 1: Writable
|
||||
Bit 0: Global
|
||||
|
||||
TLB internal tag
|
||||
****************
|
||||
|
||||
Bits 63-13: VA<63-13>
|
||||
Bits 12-0: context ID
|
||||
|
||||
Conveniently, a 512 entries TSB fits exactly in a 8K page, so it can be locked
|
||||
in the TLB with a single entry there. However, it may be a wise idea to instead
|
||||
map 64K (or more) of RAM locked as a single entry for all the things that needs
|
||||
to be accessed by the TLB miss trap handler, so we minimize the use of TLB
|
||||
entries.
|
||||
|
||||
Likewise, it may be useful to use 64K pages instead of 8K whenever possible.
|
||||
The hardware provides some support for mixing the two sizes but it makes things
|
||||
a bit more complex. Let's start out with simpler things.
|
||||
|
||||
Software floating-point support
|
||||
===============================
|
||||
|
||||
The SPARC instruction set specifies instruction for handling long double
|
||||
values, however, no hardware implementation actually provides them. They
|
||||
generate a trap, which is expected to be handled by the softfloat library.
|
||||
|
||||
Since traps are slow, and gcc knows better, it will never generate those
|
||||
instructions. Instead it directly calls into the C library, to functions
|
||||
specified in the ABI and used to do long double math using softfloats.
|
||||
|
||||
The support code for this is, in our case, compiled into both the kernel and
|
||||
libroot. It lives in src/system/libroot/os/arch/sparc/softfloat.c (and other
|
||||
support files). This code was extracted from FreeBSD, rather than the glibc,
|
||||
because that made it much easier to get it building in the kernel.
|
||||
|
||||
Openboot bootloader
|
||||
===================
|
||||
|
||||
Openboot is Sun's implementation of Open Firmware. So we should be able to share
|
||||
a lot of code with the PowerPC port. There are some differences however.
|
||||
|
||||
Executable format
|
||||
-----------------
|
||||
|
||||
PowerPC uses COFF. Sparc uses a.out, which is a lot simpler. According to the
|
||||
spec, some fields should be zeroed out, but they say implementation may chose
|
||||
to allow other values, so a standard a.out file works as well.
|
||||
|
||||
It used to be possible to generate one with objcopy, but support was removed,
|
||||
so we now use elf2aout (imported from FreeBSD).
|
||||
|
||||
The file is first loaded at 4000, then relocated to its load address (we use
|
||||
202000 and executed there)
|
||||
|
||||
Openfirmware prompt
|
||||
-------------------
|
||||
|
||||
To get the prompt on display, use STOP+A at boot until you get the "ok" prompt.
|
||||
On some machines, if no keyboard is detected, the ROM will assume it is set up
|
||||
in headless mode, and will expect a BREAK+A on the serial port.
|
||||
|
||||
STOP+N resets all variables to default values (in case you messed up input or
|
||||
output, for example).
|
||||
|
||||
Useful commands
|
||||
---------------
|
||||
|
||||
Disable autoboot to get to the openboot prompt and stop there
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
setenv auto-boot? false
|
||||
|
||||
Configuring for keyboard/framebuffer io
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
setenv screen-#columns 160
|
||||
setenv screen-#rows 49
|
||||
setenv output-device screen:r1920x1080x60
|
||||
setenv input-device keyboard
|
||||
|
||||
Configuring openboot for serial port
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
setenv ttya-mode 38400,8,n,1,-
|
||||
setenv output-device ttya
|
||||
setenv input-device ttya
|
||||
reset
|
||||
|
||||
Boot from network
|
||||
-----------------
|
||||
|
||||
static ip
|
||||
*********
|
||||
|
||||
This currently works best, because rarp does not let the called binary know the
|
||||
IP address. We need the IP address if we want to mount the root filesystem using
|
||||
remote_disk server.
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
boot net:192.168.1.2,somefile,192.168.1.89
|
||||
|
||||
The first IP is the server from which to download (using TFTP), the second is
|
||||
the client IP to use. Once the bootloader starts, it will detect that it is
|
||||
booted from network and look for a the remote_disk_server on the same machine.
|
||||
|
||||
rarp
|
||||
****
|
||||
|
||||
This needs a reverse ARP server (easy to setup on any Linux system). You need
|
||||
to list the MAC address of the SPARC machine in /etc/ethers on the server. The
|
||||
machine will get its IP, and will use TFTP to the server which replied, to get
|
||||
the boot file from there.
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
boot net:,somefile
|
||||
|
||||
(net is an alias to the network card and also sets the load address: /pci@1f,4000/network@1,1)
|
||||
|
||||
dhcp
|
||||
****
|
||||
|
||||
This needs a DHCP/BOOTP server configured to send the info about where to find
|
||||
the file to load and boot.
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
boot net:dhcp
|
||||
|
||||
|
||||
|
||||
Debugging
|
||||
---------
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
202000 dis (disassemble starting at 202000 until next return instruction)
|
||||
4000 1000 dump (dump 1000 bytes from address 4000)
|
||||
.registers (show global registers)
|
||||
.locals (show local/windowed registers)
|
||||
%pc dis (disassemble code being exectuted)
|
||||
ctrace (backtrace)
|
||||
@@ -1,12 +0,0 @@
|
||||
The SPARC instruction set specifies instruction for handling long double
|
||||
values, however, no hardware implementation actually provides them. They
|
||||
generate a trap, which is expected to be handled by the softfloat library.
|
||||
|
||||
Since traps are slow, and gcc knows better, it will never generate those
|
||||
instructions. Instead it directly calls into the C library, to functions
|
||||
specified in the ABI and used to do long double math using softfloats.
|
||||
|
||||
The support code for this is, in our case, compiled into both the kernel and
|
||||
libroot. It lives in src/system/libroot/os/arch/sparc/softfloat.c (and other
|
||||
support files). This code was extracted from FreeBSD, rather than the glibc,
|
||||
because that made it much easier to get it building in the kernel.
|
||||
Reference in New Issue
Block a user