docs/develop: More reorganization.
* There is now a 'busses' folder, and the extant USB/SDHCI/Bluetooth/etc. docs now live in it, instead of various other places. * kernel/ports is now kernel/arch, like it is in src/system. SPARC documentation is now in there, too. * VM files (these are rather outdated) are now in kernel/vm. * SCSI ASC info removed, this is easily available online and it doesn't seem to be very relevant.
This commit is contained in:
Augustin Cavalier
@@ -0,0 +1,84 @@
|
||||
# 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,60 @@
|
||||
# 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,5 @@
|
||||
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,15 @@
|
||||
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
|
||||
@@ -0,0 +1,2 @@
|
||||
* Does not support < ARMv5
|
||||
* Requires support for high vectors
|
||||
@@ -0,0 +1,74 @@
|
||||
# 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,74 @@
|
||||
# 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,64 @@
|
||||
* 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).
|
||||
@@ -0,0 +1,13 @@
|
||||
* 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
|
||||
@@ -0,0 +1,48 @@
|
||||
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,3 @@
|
||||
- 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 @@
|
||||
http://wandel.ca/homepage/execdis/
|
||||
@@ -0,0 +1,57 @@
|
||||
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
|
||||
@@ -0,0 +1,19 @@
|
||||
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,7 @@
|
||||
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,11 @@
|
||||
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,76 @@
|
||||
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/
|
||||
@@ -0,0 +1,32 @@
|
||||
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.
|
||||
@@ -0,0 +1,37 @@
|
||||
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.
|
||||
@@ -0,0 +1,12 @@
|
||||
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