xiaomi-sm8450/android_kernel_xiaomi_sm8450
1
0
Vork 0
Code Kwesties Pull-aanvragen Actions Packages Projecten Publicaties Wiki Activiteit

Linux-2.6.12-rc2

Bladeren bron 
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
This commit is contained in:
Linus Torvalds
2005-04-16 15:20:36 -07:00
commit 1da177e4c3
17291 gewijzigde bestanden met toevoegingen van 6718755 en 0 verwijderingen
Download Patch-bestand Download Diff-bestand Expand all files Collapse all files

20
Documentation/arm/00-INDEX Normal file
Bestand weergeven

@@ -0,0 +1,20 @@
00-INDEX
- this file
Booting
- requirements for booting
Interrupts
- ARM Interrupt subsystem documentation
Netwinder
- Netwinder specific documentation
README
- General ARM documentation
SA1100
- SA1100 documentation
XScale
- XScale documentation
empeg
- Empeg documentation
mem_alignment
- alignment abort handler documentation
nwfpe
- NWFPE floating point emulator documentation

141
Documentation/arm/Booting Normal file
Bestand weergeven

@@ -0,0 +1,141 @@
Booting ARM Linux
=================
Author: Russell King
Date : 18 May 2002
The following documentation is relevant to 2.4.18-rmk6 and beyond.
In order to boot ARM Linux, you require a boot loader, which is a small
program that runs before the main kernel. The boot loader is expected
to initialise various devices, and eventually call the Linux kernel,
passing information to the kernel.
Essentially, the boot loader should provide (as a minimum) the
following:
1. Setup and initialise the RAM.
2. Initialise one serial port.
3. Detect the machine type.
4. Setup the kernel tagged list.
5. Call the kernel image.
1. Setup and initialise RAM
---------------------------
Existing boot loaders: MANDATORY
New boot loaders: MANDATORY
The boot loader is expected to find and initialise all RAM that the
kernel will use for volatile data storage in the system. It performs
this in a machine dependent manner. (It may use internal algorithms
to automatically locate and size all RAM, or it may use knowledge of
the RAM in the machine, or any other method the boot loader designer
sees fit.)
2. Initialise one serial port
-----------------------------
Existing boot loaders: OPTIONAL, RECOMMENDED
New boot loaders: OPTIONAL, RECOMMENDED
The boot loader should initialise and enable one serial port on the
target. This allows the kernel serial driver to automatically detect
which serial port it should use for the kernel console (generally
used for debugging purposes, or communication with the target.)
As an alternative, the boot loader can pass the relevant 'console='
option to the kernel via the tagged lists specifying the port, and
serial format options as described in
Documentation/kernel-parameters.txt.
3. Detect the machine type
--------------------------
Existing boot loaders: OPTIONAL
New boot loaders: MANDATORY
The boot loader should detect the machine type its running on by some
method. Whether this is a hard coded value or some algorithm that
looks at the connected hardware is beyond the scope of this document.
The boot loader must ultimately be able to provide a MACH_TYPE_xxx
value to the kernel. (see linux/arch/arm/tools/mach-types).
4. Setup the kernel tagged list
-------------------------------
Existing boot loaders: OPTIONAL, HIGHLY RECOMMENDED
New boot loaders: MANDATORY
The boot loader must create and initialise the kernel tagged list.
A valid tagged list starts with ATAG_CORE and ends with ATAG_NONE.
The ATAG_CORE tag may or may not be empty. An empty ATAG_CORE tag
has the size field set to '2' (0x00000002). The ATAG_NONE must set
the size field to zero.
Any number of tags can be placed in the list. It is undefined
whether a repeated tag appends to the information carried by the
previous tag, or whether it replaces the information in its
entirety; some tags behave as the former, others the latter.
The boot loader must pass at a minimum the size and location of
the system memory, and root filesystem location. Therefore, the
minimum tagged list should look:
+-----------+
base -> | ATAG_CORE | |
+-----------+ |
| ATAG_MEM | | increasing address
+-----------+ |
| ATAG_NONE | |
+-----------+ v
The tagged list should be stored in system RAM.
The tagged list must be placed in a region of memory where neither
the kernel decompressor nor initrd 'bootp' program will overwrite
it. The recommended placement is in the first 16KiB of RAM.
5. Calling the kernel image
---------------------------
Existing boot loaders: MANDATORY
New boot loaders: MANDATORY
There are two options for calling the kernel zImage. If the zImage
is stored in flash, and is linked correctly to be run from flash,
then it is legal for the boot loader to call the zImage in flash
directly.
The zImage may also be placed in system RAM (at any location) and
called there. Note that the kernel uses 16K of RAM below the image
to store page tables. The recommended placement is 32KiB into RAM.
In either case, the following conditions must be met:
- Quiesce all DMA capable devicess so that memory does not get
corrupted by bogus network packets or disk data. This will save
you many hours of debug.
- CPU register settings
r0 = 0,
r1 = machine type number discovered in (3) above.
r2 = physical address of tagged list in system RAM.
- CPU mode
All forms of interrupts must be disabled (IRQs and FIQs)
The CPU must be in SVC mode. (A special exception exists for Angel)
- Caches, MMUs
The MMU must be off.
Instruction cache may be on or off.
Data cache must be off.
- The boot loader is expected to call the kernel image by jumping
directly to the first instruction of the kernel image.

69
Documentation/arm/IXP2000 Normal file
Bestand weergeven

@@ -0,0 +1,69 @@
-------------------------------------------------------------------------
Release Notes for Linux on Intel's IXP2000 Network Processor
Maintained by Deepak Saxena <dsaxena@plexity.net>
-------------------------------------------------------------------------
1. Overview
Intel's IXP2000 family of NPUs (IXP2400, IXP2800, IXP2850) is designed
for high-performance network applications such high-availability
telecom systems. In addition to an XScale core, it contains up to 8
"MicroEngines" that run special code, several high-end networking
interfaces (UTOPIA, SPI, etc), a PCI host bridge, one serial port,
flash interface, and some other odds and ends. For more information, see:
http://developer.intel.com/design/network/products/npfamily/ixp2xxx.htm
2. Linux Support
Linux currently supports the following features on the IXP2000 NPUs:
- On-chip serial
- PCI
- Flash (MTD/JFFS2)
- I2C through GPIO
- Timers (watchdog, OS)
That is about all we can support under Linux ATM b/c the core networking
components of the chip are accessed via Intel's closed source SDK.
Please contact Intel directly on issues with using those. There is
also a mailing list run by some folks at Princeton University that might
be of help: https://lists.cs.princeton.edu/mailman/listinfo/ixp2xxx
WHATEVER YOU DO, DO NOT POST EMAIL TO THE LINUX-ARM OR LINUX-ARM-KERNEL
MAILING LISTS REGARDING THE INTEL SDK.
3. Supported Platforms
- Intel IXDP2400 Reference Platform
- Intel IXDP2800 Reference Platform
- Intel IXDP2401 Reference Platform
- Intel IXDP2801 Reference Platform
- RadiSys ENP-2611
4. Usage Notes
- The IXP2000 platforms usually have rather complex PCI bus topologies
with large memory space requirements. In addition, b/c of the way the
Intel SDK is designed, devices are enumerated in a very specific
way. B/c of this this, we use "pci=firmware" option in the kernel
command line so that we do not re-enumerate the bus.
- IXDP2x01 systems have variable clock tick rates that we cannot determine
via HW registers. The "ixdp2x01_clk=XXX" cmd line options allow you
to pass the clock rate to the board port.
5. Thanks
The IXP2000 work has been funded by Intel Corp. and MontaVista Software, Inc.
The following people have contributed patches/comments/etc:
Naeem F. Afzal
Lennert Buytenhek
Jeffrey Daly
-------------------------------------------------------------------------
Last Update: 8/09/2004

174
Documentation/arm/IXP4xx Normal file
Bestand weergeven

@@ -0,0 +1,174 @@
-------------------------------------------------------------------------
Release Notes for Linux on Intel's IXP4xx Network Processor
Maintained by Deepak Saxena <dsaxena@plexity.net>
-------------------------------------------------------------------------
1. Overview
Intel's IXP4xx network processor is a highly integrated SOC that
is targeted for network applications, though it has become popular
in industrial control and other areas due to low cost and power
consumption. The IXP4xx family currently consists of several processors
that support different network offload functions such as encryption,
routing, firewalling, etc. The IXP46x family is an updated version which
supports faster speeds, new memory and flash configurations, and more
integration such as an on-chip I2C controller.
For more information on the various versions of the CPU, see:
http://developer.intel.com/design/network/products/npfamily/ixp4xx.htm
Intel also made the IXCP1100 CPU for sometime which is an IXP4xx
stripped of much of the network intelligence.
2. Linux Support
Linux currently supports the following features on the IXP4xx chips:
- Dual serial ports
- PCI interface
- Flash access (MTD/JFFS)
- I2C through GPIO on IXP42x
- GPIO for input/output/interrupts
See include/asm-arm/arch-ixp4xx/platform.h for access functions.
- Timers (watchdog, OS)
The following components of the chips are not supported by Linux and
require the use of Intel's propietary CSR softare:
- USB device interface
- Network interfaces (HSS, Utopia, NPEs, etc)
- Network offload functionality
If you need to use any of the above, you need to download Intel's
software from:
http://developer.intel.com/design/network/products/npfamily/ixp425swr1.htm
DO NOT POST QUESTIONS TO THE LINUX MAILING LISTS REGARDING THE PROPIETARY
SOFTWARE.
There are several websites that provide directions/pointers on using
Intel's software:
http://ixp4xx-osdg.sourceforge.net/
Open Source Developer's Guide for using uClinux and the Intel libraries
http://gatewaymaker.sourceforge.net/
Simple one page summary of building a gateway using an IXP425 and Linux
http://ixp425.sourceforge.net/
ATM device driver for IXP425 that relies on Intel's libraries
3. Known Issues/Limitations
3a. Limited inbound PCI window
The IXP4xx family allows for up to 256MB of memory but the PCI interface
can only expose 64MB of that memory to the PCI bus. This means that if
you are running with > 64MB, all PCI buffers outside of the accessible
range will be bounced using the routines in arch/arm/common/dmabounce.c.
3b. Limited outbound PCI window
IXP4xx provides two methods of accessing PCI memory space:
1) A direct mapped window from 0x48000000 to 0x4bffffff (64MB).
To access PCI via this space, we simply ioremap() the BAR
into the kernel and we can use the standard read[bwl]/write[bwl]
macros. This is the preffered method due to speed but it
limits the system to just 64MB of PCI memory. This can be
problamatic if using video cards and other memory-heavy devices.
2) If > 64MB of memory space is required, the IXP4xx can be
configured to use indirect registers to access PCI This allows
for up to 128MB (0x48000000 to 0x4fffffff) of memory on the bus.
The disadvantadge of this is that every PCI access requires
three local register accesses plus a spinlock, but in some
cases the performance hit is acceptable. In addition, you cannot
mmap() PCI devices in this case due to the indirect nature
of the PCI window.
By default, the direct method is used for performance reasons. If
you need more PCI memory, enable the IXP4XX_INDIRECT_PCI config option.
3c. GPIO as Interrupts
Currently the code only handles level-sensitive GPIO interrupts
4. Supported platforms
ADI Engineering Coyote Gateway Reference Platform
http://www.adiengineering.com/productsCoyote.html
The ADI Coyote platform is reference design for those building
small residential/office gateways. One NPE is connected to a 10/100
interface, one to 4-port 10/100 switch, and the third to and ADSL
interface. In addition, it also supports to POTs interfaces connected
via SLICs. Note that those are not supported by Linux ATM. Finally,
the platform has two mini-PCI slots used for 802.11[bga] cards.
Finally, there is an IDE port hanging off the expansion bus.
Gateworks Avila Network Platform
http://www.gateworks.com/avila_sbc.htm
The Avila platform is basically and IXDP425 with the 4 PCI slots
replaced with mini-PCI slots and a CF IDE interface hanging off
the expansion bus.
Intel IXDP425 Development Platform
http://developer.intel.com/design/network/products/npfamily/ixdp425.htm
This is Intel's standard reference platform for the IXDP425 and is
also known as the Richfield board. It contains 4 PCI slots, 16MB
of flash, two 10/100 ports and one ADSL port.
Intel IXDP465 Development Platform
http://developer.intel.com/design/network/products/npfamily/ixdp465.htm
This is basically an IXDP425 with an IXP465 and 32M of flash instead
of just 16.
Intel IXDPG425 Development Platform
This is basically and ADI Coyote board with a NEC EHCI controller
added. One issue with this board is that the mini-PCI slots only
have the 3.3v line connected, so you can't use a PCI to mini-PCI
adapter with an E100 card. So to NFS root you need to use either
the CSR or a WiFi card and a ramdisk that BOOTPs and then does
a pivot_root to NFS.
Motorola PrPMC1100 Processor Mezanine Card
http://www.fountainsys.com/datasheet/PrPMC1100.pdf
The PrPMC1100 is based on the IXCP1100 and is meant to plug into
and IXP2400/2800 system to act as the system controller. It simply
contains a CPU and 16MB of flash on the board and needs to be
plugged into a carrier board to function. Currently Linux only
supports the Motorola PrPMC carrier board for this platform.
See https://mcg.motorola.com/us/ds/pdf/ds0144.pdf for info
on the carrier board.
5. TODO LIST
- Add support for Coyote IDE
- Add support for edge-based GPIO interrupts
- Add support for CF IDE on expansion bus
6. Thanks
The IXP4xx work has been funded by Intel Corp. and MontaVista Software, Inc.
The following people have contributed patches/comments/etc:
Lennerty Buytenhek
Lutz Jaenicke
Justin Mayfield
Robert E. Ranslam
[I know I've forgotten others, please email me to be added]
-------------------------------------------------------------------------
Last Update: 01/04/2005

173
Documentation/arm/Interrupts Normal file
Bestand weergeven

@@ -0,0 +1,173 @@
2.5.2-rmk5
----------
This is the first kernel that contains a major shake up of some of the
major architecture-specific subsystems.
Firstly, it contains some pretty major changes to the way we handle the
MMU TLB. Each MMU TLB variant is now handled completely separately -
we have TLB v3, TLB v4 (without write buffer), TLB v4 (with write buffer),
and finally TLB v4 (with write buffer, with I TLB invalidate entry).
There is more assembly code inside each of these functions, mainly to
allow more flexible TLB handling for the future.
Secondly, the IRQ subsystem.
The 2.5 kernels will be having major changes to the way IRQs are handled.
Unfortunately, this means that machine types that touch the irq_desc[]
array (basically all machine types) will break, and this means every
machine type that we currently have.
Lets take an example. On the Assabet with Neponset, we have:
GPIO25 IRR:2
SA1100 ------------> Neponset -----------> SA1111
IIR:1
-----------> USAR
IIR:0
-----------> SMC9196
The way stuff currently works, all SA1111 interrupts are mutually
exclusive of each other - if you're processing one interrupt from the
SA1111 and another comes in, you have to wait for that interrupt to
finish processing before you can service the new interrupt. Eg, an
IDE PIO-based interrupt on the SA1111 excludes all other SA1111 and
SMC9196 interrupts until it has finished transferring its multi-sector
data, which can be a long time. Note also that since we loop in the
SA1111 IRQ handler, SA1111 IRQs can hold off SMC9196 IRQs indefinitely.
The new approach brings several new ideas...
We introduce the concept of a "parent" and a "child". For example,
to the Neponset handler, the "parent" is GPIO25, and the "children"d
are SA1111, SMC9196 and USAR.
We also bring the idea of an IRQ "chip" (mainly to reduce the size of
the irqdesc array). This doesn't have to be a real "IC"; indeed the
SA11x0 IRQs are handled by two separate "chip" structures, one for
GPIO0-10, and another for all the rest. It is just a container for
the various operations (maybe this'll change to a better name).
This structure has the following operations:
struct irqchip {
/*
* Acknowledge the IRQ.
* If this is a level-based IRQ, then it is expected to mask the IRQ
* as well.
*/
void (*ack)(unsigned int irq);
/*
* Mask the IRQ in hardware.
*/
void (*mask)(unsigned int irq);
/*
* Unmask the IRQ in hardware.
*/
void (*unmask)(unsigned int irq);
/*
* Re-run the IRQ
*/
void (*rerun)(unsigned int irq);
/*
* Set the type of the IRQ.
*/
int (*type)(unsigned int irq, unsigned int, type);
};
ack - required. May be the same function as mask for IRQs
handled by do_level_IRQ.
mask - required.
unmask - required.
rerun - optional. Not required if you're using do_level_IRQ for all
IRQs that use this 'irqchip'. Generally expected to re-trigger
the hardware IRQ if possible. If not, may call the handler
directly.
type - optional. If you don't support changing the type of an IRQ,
it should be null so people can detect if they are unable to
set the IRQ type.
For each IRQ, we keep the following information:
- "disable" depth (number of disable_irq()s without enable_irq()s)
- flags indicating what we can do with this IRQ (valid, probe,
noautounmask) as before
- status of the IRQ (probing, enable, etc)
- chip
- per-IRQ handler
- irqaction structure list
The handler can be one of the 3 standard handlers - "level", "edge" and
"simple", or your own specific handler if you need to do something special.
The "level" handler is what we currently have - its pretty simple.
"edge" knows about the brokenness of such IRQ implementations - that you
need to leave the hardware IRQ enabled while processing it, and queueing
further IRQ events should the IRQ happen again while processing. The
"simple" handler is very basic, and does not perform any hardware
manipulation, nor state tracking. This is useful for things like the
SMC9196 and USAR above.
So, what's changed?
1. Machine implementations must not write to the irqdesc array.
2. New functions to manipulate the irqdesc array. The first 4 are expected
to be useful only to machine specific code. The last is recommended to
only be used by machine specific code, but may be used in drivers if
absolutely necessary.
set_irq_chip(irq,chip)
Set the mask/unmask methods for handling this IRQ
set_irq_handler(irq,handler)
Set the handler for this IRQ (level, edge, simple)
set_irq_chained_handler(irq,handler)
Set a "chained" handler for this IRQ - automatically
enables this IRQ (eg, Neponset and SA1111 handlers).
set_irq_flags(irq,flags)
Set the valid/probe/noautoenable flags.
set_irq_type(irq,type)
Set active the IRQ edge(s)/level. This replaces the
SA1111 INTPOL manipulation, and the set_GPIO_IRQ_edge()
function. Type should be one of the following:
#define IRQT_NOEDGE (0)
#define IRQT_RISING (__IRQT_RISEDGE)
#define IRQT_FALLING (__IRQT_FALEDGE)
#define IRQT_BOTHEDGE (__IRQT_RISEDGE|__IRQT_FALEDGE)
#define IRQT_LOW (__IRQT_LOWLVL)
#define IRQT_HIGH (__IRQT_HIGHLVL)
3. set_GPIO_IRQ_edge() is obsolete, and should be replaced by set_irq_type.
4. Direct access to SA1111 INTPOL is depreciated. Use set_irq_type instead.
5. A handler is expected to perform any necessary acknowledgement of the
parent IRQ via the correct chip specific function. For instance, if
the SA1111 is directly connected to a SA1110 GPIO, then you should
acknowledge the SA1110 IRQ each time you re-read the SA1111 IRQ status.
6. For any child which doesn't have its own IRQ enable/disable controls
(eg, SMC9196), the handler must mask or acknowledge the parent IRQ
while the child handler is called, and the child handler should be the
"simple" handler (not "edge" nor "level"). After the handler completes,
the parent IRQ should be unmasked, and the status of all children must
be re-checked for pending events. (see the Neponset IRQ handler for
details).
7. fixup_irq() is gone, as is include/asm-arm/arch-*/irq.h
Please note that this will not solve all problems - some of them are
hardware based. Mixing level-based and edge-based IRQs on the same
parent signal (eg neponset) is one such area where a software based
solution can't provide the full answer to low IRQ latency.

78
Documentation/arm/Netwinder Normal file
Bestand weergeven

@@ -0,0 +1,78 @@
NetWinder specific documentation
================================
The NetWinder is a small low-power computer, primarily designed
to run Linux. It is based around the StrongARM RISC processor,
DC21285 PCI bridge, with PC-type hardware glued around it.
Port usage
==========
Min - Max Description
---------------------------
0x0000 - 0x000f DMA1
0x0020 - 0x0021 PIC1
0x0060 - 0x006f Keyboard
0x0070 - 0x007f RTC
0x0080 - 0x0087 DMA1
0x0088 - 0x008f DMA2
0x00a0 - 0x00a3 PIC2
0x00c0 - 0x00df DMA2
0x0180 - 0x0187 IRDA
0x01f0 - 0x01f6 ide0
0x0201 Game port
0x0203 RWA010 configuration read
0x0220 - ? SoundBlaster
0x0250 - ? WaveArtist
0x0279 RWA010 configuration index
0x02f8 - 0x02ff Serial ttyS1
0x0300 - 0x031f Ether10
0x0338 GPIO1
0x033a GPIO2
0x0370 - 0x0371 W83977F configuration registers
0x0388 - ? AdLib
0x03c0 - 0x03df VGA
0x03f6 ide0
0x03f8 - 0x03ff Serial ttyS0
0x0400 - 0x0408 DC21143
0x0480 - 0x0487 DMA1
0x0488 - 0x048f DMA2
0x0a79 RWA010 configuration write
0xe800 - 0xe80f ide0/ide1 BM DMA
Interrupt usage
===============
IRQ type Description
---------------------------
0 ISA 100Hz timer
1 ISA Keyboard
2 ISA cascade
3 ISA Serial ttyS1
4 ISA Serial ttyS0
5 ISA PS/2 mouse
6 ISA IRDA
7 ISA Printer
8 ISA RTC alarm
9 ISA
10 ISA GP10 (Orange reset button)
11 ISA
12 ISA WaveArtist
13 ISA
14 ISA hda1
15 ISA
DMA usage
=========
DMA type Description
---------------------------
0 ISA IRDA
1 ISA
2 ISA cascade
3 ISA WaveArtist
4 ISA
5 ISA
6 ISA
7 ISA WaveArtist

135
Documentation/arm/Porting Normal file
Bestand weergeven

@@ -0,0 +1,135 @@
Taken from list archive at http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2001-July/004064.html
Initial definitions
-------------------
The following symbol definitions rely on you knowing the translation that
__virt_to_phys() does for your machine. This macro converts the passed
virtual address to a physical address. Normally, it is simply:
phys = virt - PAGE_OFFSET + PHYS_OFFSET
Decompressor Symbols
--------------------
ZTEXTADDR
Start address of decompressor. There's no point in talking about
virtual or physical addresses here, since the MMU will be off at
the time when you call the decompressor code. You normally call
the kernel at this address to start it booting. This doesn't have
to be located in RAM, it can be in flash or other read-only or
read-write addressable medium.
ZBSSADDR
Start address of zero-initialised work area for the decompressor.
This must be pointing at RAM. The decompressor will zero initialise
this for you. Again, the MMU will be off.
ZRELADDR
This is the address where the decompressed kernel will be written,
and eventually executed. The following constraint must be valid:
__virt_to_phys(TEXTADDR) == ZRELADDR
The initial part of the kernel is carefully coded to be position
independent.
INITRD_PHYS
Physical address to place the initial RAM disk. Only relevant if
you are using the bootpImage stuff (which only works on the old
struct param_struct).
INITRD_VIRT
Virtual address of the initial RAM disk. The following constraint
must be valid:
__virt_to_phys(INITRD_VIRT) == INITRD_PHYS
PARAMS_PHYS
Physical address of the struct param_struct or tag list, giving the
kernel various parameters about its execution environment.
Kernel Symbols
--------------
PHYS_OFFSET
Physical start address of the first bank of RAM.
PAGE_OFFSET
Virtual start address of the first bank of RAM. During the kernel
boot phase, virtual address PAGE_OFFSET will be mapped to physical
address PHYS_OFFSET, along with any other mappings you supply.
This should be the same value as TASK_SIZE.
TASK_SIZE
The maximum size of a user process in bytes. Since user space
always starts at zero, this is the maximum address that a user
process can access+1. The user space stack grows down from this
address.
Any virtual address below TASK_SIZE is deemed to be user process
area, and therefore managed dynamically on a process by process
basis by the kernel. I'll call this the user segment.
Anything above TASK_SIZE is common to all processes. I'll call
this the kernel segment.
(In other words, you can't put IO mappings below TASK_SIZE, and
hence PAGE_OFFSET).
TEXTADDR
Virtual start address of kernel, normally PAGE_OFFSET + 0x8000.
This is where the kernel image ends up. With the latest kernels,
it must be located at 32768 bytes into a 128MB region. Previous
kernels placed a restriction of 256MB here.
DATAADDR
Virtual address for the kernel data segment. Must not be defined
when using the decompressor.
VMALLOC_START
VMALLOC_END
Virtual addresses bounding the vmalloc() area. There must not be
any static mappings in this area; vmalloc will overwrite them.
The addresses must also be in the kernel segment (see above).
Normally, the vmalloc() area starts VMALLOC_OFFSET bytes above the
last virtual RAM address (found using variable high_memory).
VMALLOC_OFFSET
Offset normally incorporated into VMALLOC_START to provide a hole
between virtual RAM and the vmalloc area. We do this to allow
out of bounds memory accesses (eg, something writing off the end
of the mapped memory map) to be caught. Normally set to 8MB.
Architecture Specific Macros
----------------------------
BOOT_MEM(pram,pio,vio)
`pram' specifies the physical start address of RAM. Must always
be present, and should be the same as PHYS_OFFSET.
`pio' is the physical address of an 8MB region containing IO for
use with the debugging macros in arch/arm/kernel/debug-armv.S.
`vio' is the virtual address of the 8MB debugging region.
It is expected that the debugging region will be re-initialised
by the architecture specific code later in the code (via the
MAPIO function).
BOOT_PARAMS
Same as, and see PARAMS_PHYS.
FIXUP(func)
Machine specific fixups, run before memory subsystems have been
initialised.
MAPIO(func)
Machine specific function to map IO areas (including the debug
region above).
INITIRQ(func)
Machine specific function to initialise interrupts.

198
Documentation/arm/README Normal file
Bestand weergeven

@@ -0,0 +1,198 @@
ARM Linux 2.6
=============
Please check <ftp://ftp.arm.linux.org.uk/pub/armlinux> for
updates.
Compilation of kernel
---------------------
In order to compile ARM Linux, you will need a compiler capable of
generating ARM ELF code with GNU extensions. GCC 2.95.1, EGCS
1.1.2, and GCC 3.3 are known to be good compilers. Fortunately, you
needn't guess. The kernel will report an error if your compiler is
a recognized offender.
To build ARM Linux natively, you shouldn't have to alter the ARCH = line
in the top level Makefile. However, if you don't have the ARM Linux ELF
tools installed as default, then you should change the CROSS_COMPILE
line as detailed below.
If you wish to cross-compile, then alter the following lines in the top
level make file:
ARCH = <whatever>
with
ARCH = arm
and
CROSS_COMPILE=
to
CROSS_COMPILE=<your-path-to-your-compiler-without-gcc>
eg.
CROSS_COMPILE=arm-linux-
Do a 'make config', followed by 'make Image' to build the kernel
(arch/arm/boot/Image). A compressed image can be built by doing a
'make zImage' instead of 'make Image'.
Bug reports etc
---------------
Please send patches to the patch system. For more information, see
http://www.arm.linux.org.uk/patches/info.html Always include some
explanation as to what the patch does and why it is needed.
Bug reports should be sent to linux-arm-kernel@lists.arm.linux.org.uk,
or submitted through the web form at
http://www.arm.linux.org.uk/forms/solution.shtml
When sending bug reports, please ensure that they contain all relevant
information, eg. the kernel messages that were printed before/during
the problem, what you were doing, etc.
Include files
-------------
Several new include directories have been created under include/asm-arm,
which are there to reduce the clutter in the top-level directory. These
directories, and their purpose is listed below:
arch-* machine/platform specific header files
hardware driver-internal ARM specific data structures/definitions
mach descriptions of generic ARM to specific machine interfaces
proc-* processor dependent header files (currently only two
categories)
Machine/Platform support
------------------------
The ARM tree contains support for a lot of different machine types. To
continue supporting these differences, it has become necessary to split
machine-specific parts by directory. For this, the machine category is
used to select which directories and files get included (we will use
$(MACHINE) to refer to the category)
To this end, we now have arch/arm/mach-$(MACHINE) directories which are
designed to house the non-driver files for a particular machine (eg, PCI,
memory management, architecture definitions etc). For all future
machines, there should be a corresponding include/asm-arm/arch-$(MACHINE)
directory.
Modules
-------
Although modularisation is supported (and required for the FP emulator),
each module on an ARM2/ARM250/ARM3 machine when is loaded will take
memory up to the next 32k boundary due to the size of the pages.
Therefore, modularisation on these machines really worth it?
However, ARM6 and up machines allow modules to take multiples of 4k, and
as such Acorn RiscPCs and other architectures using these processors can
make good use of modularisation.
ADFS Image files
----------------
You can access image files on your ADFS partitions by mounting the ADFS
partition, and then using the loopback device driver. You must have
losetup installed.
Please note that the PCEmulator DOS partitions have a partition table at
the start, and as such, you will have to give '-o offset' to losetup.
Request to developers
---------------------
When writing device drivers which include a separate assembler file, please
include it in with the C file, and not the arch/arm/lib directory. This
allows the driver to be compiled as a loadable module without requiring
half the code to be compiled into the kernel image.
In general, try to avoid using assembler unless it is really necessary. It
makes drivers far less easy to port to other hardware.
ST506 hard drives
-----------------
The ST506 hard drive controllers seem to be working fine (if a little
slowly). At the moment they will only work off the controllers on an
A4x0's motherboard, but for it to work off a Podule just requires
someone with a podule to add the addresses for the IRQ mask and the
HDC base to the source.
As of 31/3/96 it works with two drives (you should get the ADFS
*configure harddrive set to 2). I've got an internal 20MB and a great
big external 5.25" FH 64MB drive (who could ever want more :-) ).
I've just got 240K/s off it (a dd with bs=128k); thats about half of what
RiscOS gets; but it's a heck of a lot better than the 50K/s I was getting
last week :-)
Known bug: Drive data errors can cause a hang; including cases where
the controller has fixed the error using ECC. (Possibly ONLY
in that case...hmm).
1772 Floppy
-----------
This also seems to work OK, but hasn't been stressed much lately. It
hasn't got any code for disc change detection in there at the moment which
could be a bit of a problem! Suggestions on the correct way to do this
are welcome.
CONFIG_MACH_ and CONFIG_ARCH_
-----------------------------
A change was made in 2003 to the macro names for new machines.
Historically, CONFIG_ARCH_ was used for the bonafide architecture,
e.g. SA1100, as well as implementations of the architecture,
e.g. Assabet. It was decided to change the implementation macros
to read CONFIG_MACH_ for clarity. Moreover, a retroactive fixup has
not been made because it would complicate patching.
Previous registrations may be found online.
<http://www.arm.linux.org.uk/developer/machines/>
Kernel entry (head.S)
--------------------------
The initial entry into the kernel is via head.S, which uses machine
independent code. The machine is selected by the value of 'r1' on
entry, which must be kept unique.
Due to the large number of machines which the ARM port of Linux provides
for, we have a method to manage this which ensures that we don't end up
duplicating large amounts of code.
We group machine (or platform) support code into machine classes. A
class typically based around one or more system on a chip devices, and
acts as a natural container around the actual implementations. These
classes are given directories - arch/arm/mach-<class> and
include/asm-arm/arch-<class> - which contain the source files to
support the machine class. This directories also contain any machine
specific supporting code.
For example, the SA1100 class is based upon the SA1100 and SA1110 SoC
devices, and contains the code to support the way the on-board and off-
board devices are used, or the device is setup, and provides that
machine specific "personality."
This fine-grained machine specific selection is controlled by the machine
type ID, which acts both as a run-time and a compile-time code selection
method.
You can register a new machine via the web site at:
<http://www.arm.linux.org.uk/developer/machines/>
---
Russell King (15/03/2004)

43
Documentation/arm/SA1100/ADSBitsy Normal file
Bestand weergeven

@@ -0,0 +1,43 @@
ADS Bitsy Single Board Computer
(It is different from Bitsy(iPAQ) of Compaq)
For more details, contact Applied Data Systems or see
http://www.applieddata.net/products.html
The Linux support for this product has been provided by
Woojung Huh <whuh@applieddata.net>
Use 'make adsbitsy_config' before any 'make config'.
This will set up defaults for ADS Bitsy support.
The kernel zImage is linked to be loaded and executed at 0xc0400000.
Linux can be used with the ADS BootLoader that ships with the
newer rev boards. See their documentation on how to load Linux.
Supported peripherals:
- SA1100 LCD frame buffer (8/16bpp...sort of)
- SA1111 USB Master
- SA1100 serial port
- pcmcia, compact flash
- touchscreen(ucb1200)
- console on LCD screen
- serial ports (ttyS[0-2])
- ttyS0 is default for serial console
To do:
- everything else! :-)
Notes:
- The flash on board is divided into 3 partitions.
You should be careful to use flash on board.
It's partition is different from GraphicsClient Plus and GraphicsMaster
- 16bpp mode requires a different cable than what ships with the board.
Contact ADS or look through the manual to wire your own. Currently,
if you compile with 16bit mode support and switch into a lower bpp
mode, the timing is off so the image is corrupted. This will be
fixed soon.
Any contribution can be sent to nico@cam.org and will be greatly welcome!

301
Documentation/arm/SA1100/Assabet Normal file
Bestand weergeven

@@ -0,0 +1,301 @@
The Intel Assabet (SA-1110 evaluation) board
============================================
Please see:
http://developer.intel.com/design/strong/quicklist/eval-plat/sa-1110.htm
http://developer.intel.com/design/strong/guides/278278.htm
Also some notes from John G Dorsey <jd5q@andrew.cmu.edu>:
http://www.cs.cmu.edu/~wearable/software/assabet.html
Building the kernel
-------------------
To build the kernel with current defaults:
make assabet_config
make oldconfig
make zImage
The resulting kernel image should be available in linux/arch/arm/boot/zImage.
Installing a bootloader
-----------------------
A couple of bootloaders able to boot Linux on Assabet are available:
BLOB (http://www.lart.tudelft.nl/lartware/blob/)
BLOB is a bootloader used within the LART project. Some contributed
patches were merged into BLOB to add support for Assabet.
Compaq's Bootldr + John Dorsey's patch for Assabet support
(http://www.handhelds.org/Compaq/bootldr.html)
(http://www.wearablegroup.org/software/bootldr/)
Bootldr is the bootloader developed by Compaq for the iPAQ Pocket PC.
John Dorsey has produced add-on patches to add support for Assabet and
the JFFS filesystem.
RedBoot (http://sources.redhat.com/redboot/)
RedBoot is a bootloader developed by Red Hat based on the eCos RTOS
hardware abstraction layer. It supports Assabet amongst many other
hardware platforms.
RedBoot is currently the recommended choice since it's the only one to have
networking support, and is the most actively maintained.
Brief examples on how to boot Linux with RedBoot are shown below. But first
you need to have RedBoot installed in your flash memory. A known to work
precompiled RedBoot binary is available from the following location:
ftp://ftp.netwinder.org/users/n/nico/
ftp://ftp.arm.linux.org.uk/pub/linux/arm/people/nico/
ftp://ftp.handhelds.org/pub/linux/arm/sa-1100-patches/
Look for redboot-assabet*.tgz. Some installation infos are provided in
redboot-assabet*.txt.
Initial RedBoot configuration
-----------------------------
The commands used here are explained in The RedBoot User's Guide available
on-line at http://sources.redhat.com/ecos/docs-latest/redboot/redboot.html.
Please refer to it for explanations.
If you have a CF network card (my Assabet kit contained a CF+ LP-E from
Socket Communications Inc.), you should strongly consider using it for TFTP
file transfers. You must insert it before RedBoot runs since it can't detect
it dynamically.
To initialize the flash directory:
fis init -f
To initialize the non-volatile settings, like whether you want to use BOOTP or
a static IP address, etc, use this command:
fconfig -i
Writing a kernel image into flash
---------------------------------
First, the kernel image must be loaded into RAM. If you have the zImage file
available on a TFTP server:
load zImage -r -b 0x100000
If you rather want to use Y-Modem upload over the serial port:
load -m ymodem -r -b 0x100000
To write it to flash:
fis create "Linux kernel" -b 0x100000 -l 0xc0000
Booting the kernel
------------------
The kernel still requires a filesystem to boot. A ramdisk image can be loaded
as follows:
load ramdisk_image.gz -r -b 0x800000
Again, Y-Modem upload can be used instead of TFTP by replacing the file name
by '-y ymodem'.
Now the kernel can be retrieved from flash like this:
fis load "Linux kernel"
or loaded as described previously. To boot the kernel:
exec -b 0x100000 -l 0xc0000
The ramdisk image could be stored into flash as well, but there are better
solutions for on-flash filesystems as mentioned below.
Using JFFS2
-----------
Using JFFS2 (the Second Journalling Flash File System) is probably the most
convenient way to store a writable filesystem into flash. JFFS2 is used in
conjunction with the MTD layer which is responsible for low-level flash
management. More information on the Linux MTD can be found on-line at:
http://www.linux-mtd.infradead.org/. A JFFS howto with some infos about
creating JFFS/JFFS2 images is available from the same site.
For instance, a sample JFFS2 image can be retrieved from the same FTP sites
mentioned below for the precompiled RedBoot image.
To load this file:
load sample_img.jffs2 -r -b 0x100000
The result should look like:
RedBoot> load sample_img.jffs2 -r -b 0x100000
Raw file loaded 0x00100000-0x00377424
Now we must know the size of the unallocated flash:
fis free
Result:
RedBoot> fis free
0x500E0000 .. 0x503C0000
The values above may be different depending on the size of the filesystem and
the type of flash. See their usage below as an example and take care of
substituting yours appropriately.
We must determine some values:
size of unallocated flash: 0x503c0000 - 0x500e0000 = 0x2e0000
size of the filesystem image: 0x00377424 - 0x00100000 = 0x277424
We want to fit the filesystem image of course, but we also want to give it all
the remaining flash space as well. To write it:
fis unlock -f 0x500E0000 -l 0x2e0000
fis erase -f 0x500E0000 -l 0x2e0000
fis write -b 0x100000 -l 0x277424 -f 0x500E0000
fis create "JFFS2" -n -f 0x500E0000 -l 0x2e0000
Now the filesystem is associated to a MTD "partition" once Linux has discovered
what they are in the boot process. From Redboot, the 'fis list' command
displays them:
RedBoot> fis list
Name FLASH addr Mem addr Length Entry point
RedBoot 0x50000000 0x50000000 0x00020000 0x00000000
RedBoot config 0x503C0000 0x503C0000 0x00020000 0x00000000
FIS directory 0x503E0000 0x503E0000 0x00020000 0x00000000
Linux kernel 0x50020000 0x00100000 0x000C0000 0x00000000
JFFS2 0x500E0000 0x500E0000 0x002E0000 0x00000000
However Linux should display something like:
SA1100 flash: probing 32-bit flash bus
SA1100 flash: Found 2 x16 devices at 0x0 in 32-bit mode
Using RedBoot partition definition
Creating 5 MTD partitions on "SA1100 flash":
0x00000000-0x00020000 : "RedBoot"
0x00020000-0x000e0000 : "Linux kernel"
0x000e0000-0x003c0000 : "JFFS2"
0x003c0000-0x003e0000 : "RedBoot config"
0x003e0000-0x00400000 : "FIS directory"
What's important here is the position of the partition we are interested in,
which is the third one. Within Linux, this correspond to /dev/mtdblock2.
Therefore to boot Linux with the kernel and its root filesystem in flash, we
need this RedBoot command:
fis load "Linux kernel"
exec -b 0x100000 -l 0xc0000 -c "root=/dev/mtdblock2"
Of course other filesystems than JFFS might be used, like cramfs for example.
You might want to boot with a root filesystem over NFS, etc. It is also
possible, and sometimes more convenient, to flash a filesystem directly from
within Linux while booted from a ramdisk or NFS. The Linux MTD repository has
many tools to deal with flash memory as well, to erase it for example. JFFS2
can then be mounted directly on a freshly erased partition and files can be
copied over directly. Etc...
RedBoot scripting
-----------------
All the commands above aren't so useful if they have to be typed in every
time the Assabet is rebooted. Therefore it's possible to automatize the boot
process using RedBoot's scripting capability.
For example, I use this to boot Linux with both the kernel and the ramdisk
images retrieved from a TFTP server on the network:
RedBoot> fconfig
Run script at boot: false true
Boot script:
Enter script, terminate with empty line
>> load zImage -r -b 0x100000
>> load ramdisk_ks.gz -r -b 0x800000
>> exec -b 0x100000 -l 0xc0000
>>
Boot script timeout (1000ms resolution): 3
Use BOOTP for network configuration: true
GDB connection port: 9000
Network debug at boot time: false
Update RedBoot non-volatile configuration - are you sure (y/n)? y
Then, rebooting the Assabet is just a matter of waiting for the login prompt.
Nicolas Pitre
nico@cam.org
June 12, 2001
Status of peripherals in -rmk tree (updated 14/10/2001)
-------------------------------------------------------
Assabet:
Serial ports:
Radio: TX, RX, CTS, DSR, DCD, RI
PM: Not tested.
COM: TX, RX, CTS, DSR, DCD, RTS, DTR, PM
PM: Not tested.
I2C: Implemented, not fully tested.
L3: Fully tested, pass.
PM: Not tested.
Video:
LCD: Fully tested. PM
(LCD doesn't like being blanked with
neponset connected)
Video out: Not fully
Audio:
UDA1341:
Playback: Fully tested, pass.
Record: Implemented, not tested.
PM: Not tested.
UCB1200:
Audio play: Implemented, not heavily tested.
Audio rec: Implemented, not heavily tested.
Telco audio play: Implemented, not heavily tested.
Telco audio rec: Implemented, not heavily tested.
POTS control: No
Touchscreen: Yes
PM: Not tested.
Other:
PCMCIA:
LPE: Fully tested, pass.
USB: No
IRDA:
SIR: Fully tested, pass.
FIR: Fully tested, pass.
PM: Not tested.
Neponset:
Serial ports:
COM1,2: TX, RX, CTS, DSR, DCD, RTS, DTR
PM: Not tested.
USB: Implemented, not heavily tested.
PCMCIA: Implemented, not heavily tested.
PM: Not tested.
CF: Implemented, not heavily tested.
PM: Not tested.
More stuff can be found in the -np (Nicolas Pitre's) tree.

66
Documentation/arm/SA1100/Brutus Normal file
Bestand weergeven

@@ -0,0 +1,66 @@
Brutus is an evaluation platform for the SA1100 manufactured by Intel.
For more details, see:
http://developer.intel.com/design/strong/applnots/sa1100lx/getstart.htm
To compile for Brutus, you must issue the following commands:
make brutus_config
make config
[accept all the defaults]
make zImage
The resulting kernel will end up in linux/arch/arm/boot/zImage. This file
must be loaded at 0xc0008000 in Brutus's memory and execution started at
0xc0008000 as well with the value of registers r0 = 0 and r1 = 16 upon
entry.
But prior to execute the kernel, a ramdisk image must also be loaded in
memory. Use memory address 0xd8000000 for this. Note that the file
containing the (compressed) ramdisk image must not exceed 4 MB.
Typically, you'll need angelboot to load the kernel.
The following angelboot.opt file should be used:
----- begin angelboot.opt -----
base 0xc0008000
entry 0xc0008000
r0 0x00000000
r1 0x00000010
device /dev/ttyS0
options "9600 8N1"
baud 115200
otherfile ramdisk_img.gz
otherbase 0xd8000000
----- end angelboot.opt -----
Then load the kernel and ramdisk with:
angelboot -f angelboot.opt zImage
The first Brutus serial port (assumed to be linked to /dev/ttyS0 on your
host PC) is used by angel to load the kernel and ramdisk image. The serial
console is provided through the second Brutus serial port. To access it,
you may use minicom configured with /dev/ttyS1, 9600 baud, 8N1, no flow
control.
Currently supported:
- RS232 serial ports
- audio output
- LCD screen
- keyboard
The actual Brutus support may not be complete without extra patches.
If such patches exist, they should be found from
ftp.netwinder.org/users/n/nico.
A full PCMCIA support is still missing, although it's possible to hack
some drivers in order to drive already inserted cards at boot time with
little modifications.
Any contribution is welcome.
Please send patches to nico@cam.org
Have Fun !

29
Documentation/arm/SA1100/CERF Normal file
Bestand weergeven

@@ -0,0 +1,29 @@
*** The StrongARM version of the CerfBoard/Cube has been discontinued ***
The Intrinsyc CerfBoard is a StrongARM 1110-based computer on a board
that measures approximately 2" square. It includes an Ethernet
controller, an RS232-compatible serial port, a USB function port, and
one CompactFlash+ slot on the back. Pictures can be found at the
Intrinsyc website, http://www.intrinsyc.com.
This document describes the support in the Linux kernel for the
Intrinsyc CerfBoard.
Supported in this version:
- CompactFlash+ slot (select PCMCIA in General Setup and any options
that may be required)
- Onboard Crystal CS8900 Ethernet controller (Cerf CS8900A support in
Network Devices)
- Serial ports with a serial console (hardcoded to 38400 8N1)
In order to get this kernel onto your Cerf, you need a server that runs
both BOOTP and TFTP. Detailed instructions should have come with your
evaluation kit on how to use the bootloader. This series of commands
will suffice:
make ARCH=arm CROSS_COMPILE=arm-linux- cerfcube_defconfig
make ARCH=arm CROSS_COMPILE=arm-linux- zImage
make ARCH=arm CROSS_COMPILE=arm-linux- modules
cp arch/arm/boot/zImage <TFTP directory>
support@intrinsyc.com

21
Documentation/arm/SA1100/FreeBird Normal file
Bestand weergeven

@@ -0,0 +1,21 @@
Freebird-1.1 is produced by Legned(C) ,Inc.
(http://www.legend.com.cn)
and software/linux mainatined by Coventive(C),Inc.
(http://www.coventive.com)
Based on the Nicolas's strongarm kernel tree.
===============================================================
Maintainer:
Chester Kuo <chester@coventive.com>
<chester@linux.org.tw>
Author :
Tim wu <timwu@coventive.com>
CIH <cih@coventive.com>
Eric Peng <ericpeng@coventive.com>
Jeff Lee <jeff_lee@coventive.com>
Allen Cheng
Tony Liu <tonyliu@coventive.com>

98
Documentation/arm/SA1100/GraphicsClient Normal file
Bestand weergeven

@@ -0,0 +1,98 @@
ADS GraphicsClient Plus Single Board Computer
For more details, contact Applied Data Systems or see
http://www.applieddata.net/products.html
The original Linux support for this product has been provided by
Nicolas Pitre <nico@cam.org>. Continued development work by
Woojung Huh <whuh@applieddata.net>
It's currently possible to mount a root filesystem via NFS providing a
complete Linux environment. Otherwise a ramdisk image may be used. The
board supports MTD/JFFS, so you could also mount something on there.
Use 'make graphicsclient_config' before any 'make config'. This will set up
defaults for GraphicsClient Plus support.
The kernel zImage is linked to be loaded and executed at 0xc0200000.
Also the following registers should have the specified values upon entry:
r0 = 0
r1 = 29 (this is the GraphicsClient architecture number)
Linux can be used with the ADS BootLoader that ships with the
newer rev boards. See their documentation on how to load Linux.
Angel is not available for the GraphicsClient Plus AFAIK.
There is a board known as just the GraphicsClient that ADS used to
produce but has end of lifed. This code will not work on the older
board with the ADS bootloader, but should still work with Angel,
as outlined below. In any case, if you're planning on deploying
something en masse, you should probably get the newer board.
If using Angel on the older boards, here is a typical angel.opt option file
if the kernel is loaded through the Angel Debug Monitor:
----- begin angelboot.opt -----
base 0xc0200000
entry 0xc0200000
r0 0x00000000
r1 0x0000001d
device /dev/ttyS1
options "38400 8N1"
baud 115200
#otherfile ramdisk.gz
#otherbase 0xc0800000
exec minicom
----- end angelboot.opt -----
Then the kernel (and ramdisk if otherfile/otherbase lines above are
uncommented) would be loaded with:
angelboot -f angelboot.opt zImage
Here it is assumed that the board is connected to ttyS1 on your PC
and that minicom is preconfigured with /dev/ttyS1, 38400 baud, 8N1, no flow
control by default.
If any other bootloader is used, ensure it accomplish the same, especially
for r0/r1 register values before jumping into the kernel.
Supported peripherals:
- SA1100 LCD frame buffer (8/16bpp...sort of)
- on-board SMC 92C96 ethernet NIC
- SA1100 serial port
- flash memory access (MTD/JFFS)
- pcmcia
- touchscreen(ucb1200)
- ps/2 keyboard
- console on LCD screen
- serial ports (ttyS[0-2])
- ttyS0 is default for serial console
- Smart I/O (ADC, keypad, digital inputs, etc)
See http://www.applieddata.com/developers/linux for IOCTL documentation
and example user space code. ps/2 keybd is multiplexed through this driver
To do:
- UCB1200 audio with new ucb_generic layer
- everything else! :-)
Notes:
- The flash on board is divided into 3 partitions. mtd0 is where
the ADS boot ROM and zImage is stored. It's been marked as
read-only to keep you from blasting over the bootloader. :) mtd1 is
for the ramdisk.gz image. mtd2 is user flash space and can be
utilized for either JFFS or if you're feeling crazy, running ext2
on top of it. If you're not using the ADS bootloader, you're
welcome to blast over the mtd1 partition also.
- 16bpp mode requires a different cable than what ships with the board.
Contact ADS or look through the manual to wire your own. Currently,
if you compile with 16bit mode support and switch into a lower bpp
mode, the timing is off so the image is corrupted. This will be
fixed soon.
Any contribution can be sent to nico@cam.org and will be greatly welcome!

53
Documentation/arm/SA1100/GraphicsMaster Normal file
Bestand weergeven

@@ -0,0 +1,53 @@
ADS GraphicsMaster Single Board Computer
For more details, contact Applied Data Systems or see
http://www.applieddata.net/products.html
The original Linux support for this product has been provided by
Nicolas Pitre <nico@cam.org>. Continued development work by
Woojung Huh <whuh@applieddata.net>
Use 'make graphicsmaster_config' before any 'make config'.
This will set up defaults for GraphicsMaster support.
The kernel zImage is linked to be loaded and executed at 0xc0400000.
Linux can be used with the ADS BootLoader that ships with the
newer rev boards. See their documentation on how to load Linux.
Supported peripherals:
- SA1100 LCD frame buffer (8/16bpp...sort of)
- SA1111 USB Master
- on-board SMC 92C96 ethernet NIC
- SA1100 serial port
- flash memory access (MTD/JFFS)
- pcmcia, compact flash
- touchscreen(ucb1200)
- ps/2 keyboard
- console on LCD screen
- serial ports (ttyS[0-2])
- ttyS0 is default for serial console
- Smart I/O (ADC, keypad, digital inputs, etc)
See http://www.applieddata.com/developers/linux for IOCTL documentation
and example user space code. ps/2 keybd is multiplexed through this driver
To do:
- everything else! :-)
Notes:
- The flash on board is divided into 3 partitions. mtd0 is where
the zImage is stored. It's been marked as read-only to keep you
from blasting over the bootloader. :) mtd1 is
for the ramdisk.gz image. mtd2 is user flash space and can be
utilized for either JFFS or if you're feeling crazy, running ext2
on top of it. If you're not using the ADS bootloader, you're
welcome to blast over the mtd1 partition also.
- 16bpp mode requires a different cable than what ships with the board.
Contact ADS or look through the manual to wire your own. Currently,
if you compile with 16bit mode support and switch into a lower bpp
mode, the timing is off so the image is corrupted. This will be
fixed soon.
Any contribution can be sent to nico@cam.org and will be greatly welcome!

17
Documentation/arm/SA1100/HUW_WEBPANEL Normal file
Bestand weergeven

@@ -0,0 +1,17 @@
The HUW_WEBPANEL is a product of the german company Hoeft & Wessel AG
If you want more information, please visit
http://www.hoeft-wessel.de
To build the kernel:
make huw_webpanel_config
make oldconfig
[accept all defaults]
make zImage
Mostly of the work is done by:
Roman Jordan jor@hoeft-wessel.de
Christoph Schulz schu@hoeft-wessel.de
2000/12/18/

39
Documentation/arm/SA1100/Itsy Normal file
Bestand weergeven

@@ -0,0 +1,39 @@
Itsy is a research project done by the Western Research Lab, and Systems
Research Center in Palo Alto, CA. The Itsy project is one of several
research projects at Compaq that are related to pocket computing.
For more information, see:
http://www.research.digital.com/wrl/itsy/index.html
Notes on initial 2.4 Itsy support (8/27/2000) :
The port was done on an Itsy version 1.5 machine with a daughtercard with
64 Meg of DRAM and 32 Meg of Flash. The initial work includes support for
serial console (to see what you're doing). No other devices have been
enabled.
To build, do a "make menuconfig" (or xmenuconfig) and select Itsy support.
Disable Flash and LCD support. and then do a make zImage.
Finally, you will need to cd to arch/arm/boot/tools and execute a make there
to build the params-itsy program used to boot the kernel.
In order to install the port of 2.4 to the itsy, You will need to set the
configuration parameters in the monitor as follows:
Arg 1:0x08340000, Arg2: 0xC0000000, Arg3:18 (0x12), Arg4:0
Make sure the start-routine address is set to 0x00060000.
Next, flash the params-itsy program to 0x00060000 ("p 1 0x00060000" in the
flash menu) Flash the kernel in arch/arm/boot/zImage into 0x08340000
("p 1 0x00340000"). Finally flash an initial ramdisk into 0xC8000000
("p 2 0x0") We used ramdisk-2-30.gz from the 0.11 version directory on
handhelds.org.
The serial connection we established was at:
8-bit data, no parity, 1 stop bit(s), 115200.00 b/s. in the monitor, in the
params-itsy program, and in the kernel itself. This can be changed, but
not easily. The monitor parameters are easily changed, the params program
setup is assembly outl's, and the kernel is a configuration item specific to
the itsy. (i.e. grep for CONFIG_SA1100_ITSY and you'll find where it is.)
This should get you a properly booting 2.4 kernel on the itsy.

14
Documentation/arm/SA1100/LART Normal file
Bestand weergeven

@@ -0,0 +1,14 @@
Linux Advanced Radio Terminal (LART)
------------------------------------
The LART is a small (7.5 x 10cm) SA-1100 board, designed for embedded
applications. It has 32 MB DRAM, 4MB Flash ROM, double RS232 and all
other StrongARM-gadgets. Almost all SA signals are directly accessible
through a number of connectors. The powersupply accepts voltages
between 3.5V and 16V and is overdimensioned to support a range of
daughterboards. A quad Ethernet / IDE / PS2 / sound daughterboard
is under development, with plenty of others in different stages of
planning.
The hardware designs for this board have been released under an open license;
see the LART page at http://www.lart.tudelft.nl/ for more information.

11
Documentation/arm/SA1100/PLEB Normal file
Bestand weergeven

@@ -0,0 +1,11 @@
The PLEB project was started as a student initiative at the School of
Computer Science and Engineering, University of New South Wales to make a
pocket computer capable of running the Linux Kernel.
PLEB support has yet to be fully integrated.
For more information, see:
http://www.cse.unsw.edu.au/~pleb/

23
Documentation/arm/SA1100/Pangolin Normal file
Bestand weergeven

@@ -0,0 +1,23 @@
Pangolin is a StrongARM 1110-based evaluation platform produced
by Dialogue Technology (http://www.dialogue.com.tw/).
It has EISA slots for ease of configuration with SDRAM/Flash
memory card, USB/Serial/Audio card, Compact Flash card,
PCMCIA/IDE card and TFT-LCD card.
To compile for Pangolin, you must issue the following commands:
make pangolin_config
make oldconfig
make zImage
Supported peripherals:
- SA1110 serial port (UART1/UART2/UART3)
- flash memory access
- compact flash driver
- UDA1341 sound driver
- SA1100 LCD controller for 800x600 16bpp TFT-LCD
- MQ-200 driver for 800x600 16bpp TFT-LCD
- Penmount(touch panel) driver
- PCMCIA driver
- SMC91C94 LAN driver
- IDE driver (experimental)

7
Documentation/arm/SA1100/Tifon Normal file
Bestand weergeven

@@ -0,0 +1,7 @@
Tifon
-----
More info has to come...
Contact: Peter Danielsson <peter.danielsson@era-t.ericsson.se>

16
Documentation/arm/SA1100/Victor Normal file
Bestand weergeven

@@ -0,0 +1,16 @@
Victor is known as a "digital talking book player" manufactured by
VisuAide, Inc. to be used by blind people.
For more information related to Victor, see:
http://www.visuaide.com/victor
Of course Victor is using Linux as its main operating system.
The Victor implementation for Linux is maintained by Nicolas Pitre:
nico@visuaide.com
nico@cam.org
For any comments, please feel free to contact me through the above
addresses.

2
Documentation/arm/SA1100/Yopy Normal file
Bestand weergeven

@@ -0,0 +1,2 @@
See http://www.yopydeveloper.org for more.

2
Documentation/arm/SA1100/empeg Normal file
Bestand weergeven

@@ -0,0 +1,2 @@
See ../empeg/README

11
Documentation/arm/SA1100/nanoEngine Normal file
Bestand weergeven

@@ -0,0 +1,11 @@
nanoEngine
----------
"nanoEngine" is a SA1110 based single board computer from
Bright Star Engineering Inc. See www.brightstareng.com/arm
for more info.
(Ref: Stuart Adams <sja@brightstareng.com>)
Also visit Larry Doolittle's "Linux for the nanoEngine" site:
http://recycle.lbl.gov/~ldoolitt/bse/

47
Documentation/arm/SA1100/serial_UART Normal file
Bestand weergeven

@@ -0,0 +1,47 @@
The SA1100 serial port had its major/minor numbers officially assigned:
> Date: Sun, 24 Sep 2000 21:40:27 -0700
> From: H. Peter Anvin <hpa@transmeta.com>
> To: Nicolas Pitre <nico@CAM.ORG>
> Cc: Device List Maintainer <device@lanana.org>
> Subject: Re: device
>
> Okay. Note that device numbers 204 and 205 are used for "low density
> serial devices", so you will have a range of minors on those majors (the
> tty device layer handles this just fine, so you don't have to worry about
> doing anything special.)
>
> So your assignments are:
>
> 204 char Low-density serial ports
> 5 = /dev/ttySA0 SA1100 builtin serial port 0
> 6 = /dev/ttySA1 SA1100 builtin serial port 1
> 7 = /dev/ttySA2 SA1100 builtin serial port 2
>
> 205 char Low-density serial ports (alternate device)
> 5 = /dev/cusa0 Callout device for ttySA0
> 6 = /dev/cusa1 Callout device for ttySA1
> 7 = /dev/cusa2 Callout device for ttySA2
>
If you're not using devfs, you must create those inodes in /dev
on the root filesystem used by your SA1100-based device:
mknod ttySA0 c 204 5
mknod ttySA1 c 204 6
mknod ttySA2 c 204 7
mknod cusa0 c 205 5
mknod cusa1 c 205 6
mknod cusa2 c 205 7
In addition to the creation of the appropriate device nodes above, you
must ensure your user space applications make use of the correct device
name. The classic example is the content of the /etc/inittab file where
you might have a getty process started on ttyS0. In this case:
- replace occurrences of ttyS0 with ttySA0, ttyS1 with ttySA1, etc.
- don't forget to add 'ttySA0', 'console', or the appropriate tty name
in /etc/securetty for root to be allowed to login as well.

58
Documentation/arm/Samsung-S3C24XX/EB2410ITX.txt Normal file
Bestand weergeven

@@ -0,0 +1,58 @@
Simtec Electronics EB2410ITX (BAST)
===================================
http://www.simtec.co.uk/products/EB2410ITX/
Introduction
------------
The EB2410ITX is a S3C2410 based development board with a variety of
peripherals and expansion connectors. This board is also known by
the shortened name of Bast.
Configuration
-------------
To set the default configuration, use `make bast_defconfig` which
supports the commonly used features of this board.
Support
-------
Official support information can be found on the Simtec Electronics
website, at the product page http://www.simtec.co.uk/products/EB2410ITX/
Useful links:
- Resources Page http://www.simtec.co.uk/products/EB2410ITX/resources.html
- Board FAQ at http://www.simtec.co.uk/products/EB2410ITX/faq.html
- Bootloader info http://www.simtec.co.uk/products/SWABLE/resources.html
and FAQ http://www.simtec.co.uk/products/SWABLE/faq.html
MTD
---
The NAND and NOR support has been merged from the linux-mtd project.
Any prolbems, see http://www.linux-mtd.infradead.org/ for more
information or up-to-date versions of linux-mtd.
IDE
---
Both onboard IDE ports are supported, however there is no support for
changing speed of devices, PIO Mode 4 capable drives should be used.
Maintainers
-----------
This board is maintained by Simtec Electronics.
(c) 2004 Ben Dooks, Simtec Electronics

122
Documentation/arm/Samsung-S3C24XX/GPIO.txt Normal file
Bestand weergeven

@@ -0,0 +1,122 @@
S3C2410 GPIO Control
====================
Introduction
------------
The s3c2410 kernel provides an interface to configure and
manipulate the state of the GPIO pins, and find out other
information about them.
There are a number of conditions attached to the configuration
of the s3c2410 GPIO system, please read the Samsung provided
data-sheet/users manual to find out the complete list.
Headers
-------
See include/asm-arm/arch-s3c2410/regs-gpio.h for the list
of GPIO pins, and the configuration values for them. This
is included by using #include <asm/arch/regs-gpio.h>
The GPIO management functions are defined in the hardware
header include/asm-arm/arch-s3c2410/hardware.h which can be
included by #include <asm/arch/hardware.h>
A useful ammount of documentation can be found in the hardware
header on how the GPIO functions (and others) work.
Whilst a number of these functions do make some checks on what
is passed to them, for speed of use, they may not always ensure
that the user supplied data to them is correct.
PIN Numbers
-----------
Each pin has an unique number associated with it in regs-gpio.h,
eg S3C2410_GPA0 or S3C2410_GPF1. These defines are used to tell
the GPIO functions which pin is to be used.
Configuring a pin
-----------------
The following function allows the configuration of a given pin to
be changed.
void s3c2410_gpio_cfgpin(unsigned int pin, unsigned int function);
Eg:
s3c2410_gpio_cfgpin(S3C2410_GPA0, S3C2410_GPA0_ADDR0);
s3c2410_gpio_cfgpin(S3C2410_GPE8, S3C2410_GPE8_SDDAT1);
which would turn GPA0 into the lowest Address line A0, and set
GPE8 to be connected to the SDIO/MMC controller's SDDAT1 line.
Reading the current configuration
---------------------------------
The current configuration of a pin can be read by using:
s3c2410_gpio_getcfg(unsigned int pin);
The return value will be from the same set of values which can be
passed to s3c2410_gpio_cfgpin().
Configuring a pull-up resistor
------------------------------
A large proportion of the GPIO pins on the S3C2410 can have weak
pull-up resistors enabled. This can be configured by the following
function:
void s3c2410_gpio_pullup(unsigned int pin, unsigned int to);
Where the to value is zero to set the pull-up off, and 1 to enable
the specified pull-up. Any other values are currently undefined.
Getting the state of a PIN
--------------------------
The state of a pin can be read by using the function:
unsigned int s3c2410_gpio_getpin(unsigned int pin);
This will return either zero or non-zero. Do not count on this
function returning 1 if the pin is set.
Setting the state of a PIN
--------------------------
The value an pin is outputing can be modified by using the following:
void s3c2410_gpio_setpin(unsigned int pin, unsigned int to);
Which sets the given pin to the value. Use 0 to write 0, and 1 to
set the output to 1.
Getting the IRQ number associated with a PIN
--------------------------------------------
The following function can map the given pin number to an IRQ
number to pass to the IRQ system.
int s3c2410_gpio_getirq(unsigned int pin);
Note, not all pins have an IRQ.
Authour
-------
Ben Dooks, 03 October 2004
(c) 2004 Ben Dooks, Simtec Electronics

40
Documentation/arm/Samsung-S3C24XX/H1940.txt Normal file
Bestand weergeven

@@ -0,0 +1,40 @@
HP IPAQ H1940
=============
http://www.handhelds.org/projects/h1940.html
Introduction
------------
The HP H1940 is a S3C2410 based handheld device, with
bluetooth connectivity.
Support
-------
A variety of information is available
handhelds.org project page:
http://www.handhelds.org/projects/h1940.html
handhelds.org wiki page:
http://handhelds.org/moin/moin.cgi/HpIpaqH1940
Herbert P<>tzl pages:
http://vserver.13thfloor.at/H1940/
Maintainers
-----------
This project is being maintained and developed by a variety
of people, including Ben Dooks, Arnaud Patard, and Herbert P<>tzl.
Thanks to the many others who have also provided support.
(c) 2005 Ben Dooks

156
Documentation/arm/Samsung-S3C24XX/Overview.txt Normal file
Bestand weergeven

@@ -0,0 +1,156 @@
S3C24XX ARM Linux Overview
==========================
Introduction
------------
The Samsung S3C24XX range of ARM9 System-on-Chip CPUs are supported
by the 's3c2410' architecture of ARM Linux. Currently the S3C2410 and
the S3C2440 are supported CPUs.
Configuration
-------------
A generic S3C2410 configuration is provided, and can be used as the
default by `make s3c2410_defconfig`. This configuration has support
for all the machines, and the commonly used features on them.
Certain machines may have their own default configurations as well,
please check the machine specific documentation.
Machines
--------
The currently supported machines are as follows:
Simtec Electronics EB2410ITX (BAST)
A general purpose development board, see EB2410ITX.txt for further
details
Samsung SMDK2410
Samsung's own development board, geared for PDA work.
Samsung/Meritech SMDK2440
The S3C2440 compatible version of the SMDK2440
Thorcom VR1000
Custom embedded board
HP IPAQ 1940
Handheld (IPAQ), available in several varieties
HP iPAQ rx3715
S3C2440 based IPAQ, with a number of variations depending on
features shipped.
Acer N30
A S3C2410 based PDA from Acer. There is a Wiki page at
http://handhelds.org/moin/moin.cgi/AcerN30Documentation .
Adding New Machines
-------------------
The archicture has been designed to support as many machines as can
be configured for it in one kernel build, and any future additions
should keep this in mind before altering items outside of their own
machine files.
Machine definitions should be kept in linux/arch/arm/mach-s3c2410,
and there are a number of examples that can be looked at.
Read the kernel patch submission policies as well as the
Documentation/arm directory before submitting patches. The
ARM kernel series is managed by Russell King, and has a patch system
located at http://www.arm.linux.org.uk/developer/patches/
as well as mailing lists that can be found from the same site.
As a courtesy, please notify <ben-linux@fluff.org> of any new
machines or other modifications.
Any large scale modifications, or new drivers should be discussed
on the ARM kernel mailing list (linux-arm-kernel) before being
attempted.
NAND
----
The current kernels now have support for the s3c2410 NAND
controller. If there are any problems the latest linux-mtd
CVS can be found from http://www.linux-mtd.infradead.org/
Serial
------
The s3c2410 serial driver provides support for the internal
serial ports. These devices appear as /dev/ttySAC0 through 3.
To create device nodes for these, use the following commands
mknod ttySAC0 c 204 64
mknod ttySAC1 c 204 65
mknod ttySAC2 c 204 66
GPIO
----
The core contains support for manipulating the GPIO, see the
documentation in GPIO.txt in the same directory as this file.
Clock Management
----------------
The core provides the interface defined in the header file
include/asm-arm/hardware/clock.h, to allow control over the
various clock units
Port Contributors
-----------------
Ben Dooks (BJD)
Vincent Sanders
Herbert Potzl
Arnaud Patard (RTP)
Roc Wu
Klaus Fetscher
Dimitry Andric
Shannon Holland
Guillaume Gourat (NexVision)
Christer Weinigel (wingel) (Acer N30)
Lucas Correia Villa Real (S3C2400 port)
Document Changes
----------------
05 Sep 2004 - BJD - Added Document Changes section
05 Sep 2004 - BJD - Added Klaus Fetscher to list of contributors
25 Oct 2004 - BJD - Added Dimitry Andric to list of contributors
25 Oct 2004 - BJD - Updated the MTD from the 2.6.9 merge
21 Jan 2005 - BJD - Added rx3715, added Shannon to contributors
10 Feb 2005 - BJD - Added Guillaume Gourat to contributors
02 Mar 2005 - BJD - Added SMDK2440 to list of machines
06 Mar 2005 - BJD - Added Christer Weinigel
08 Mar 2005 - BJD - Added LCVR to list of people, updated introduction
08 Mar 2005 - BJD - Added section on adding machines
Document Author
---------------
Ben Dooks, (c) 2004-2005 Simtec Electronics

56
Documentation/arm/Samsung-S3C24XX/SMDK2440.txt Normal file
Bestand weergeven

@@ -0,0 +1,56 @@
Samsung/Meritech SMDK2440
=========================
Introduction
------------
The SMDK2440 is a two part evaluation board for the Samsung S3C2440
processor. It includes support for LCD, SmartMedia, Audio, SD and
10MBit Ethernet, and expansion headers for various signals, including
the camera and unused GPIO.
Configuration
-------------
To set the default configuration, use `make smdk2440_defconfig` which
will configure the common features of this board, or use
`make s3c2410_config` to include support for all s3c2410/s3c2440 machines
Support
-------
Ben Dooks' SMDK2440 site at http://www.fluff.org/ben/smdk2440/ which
includes linux based USB download tools.
Some of the h1940 patches that can be found from the H1940 project
site at http://www.handhelds.org/projects/h1940.html can also be
applied to this board.
Peripherals
-----------
There is no current support for any of the extra peripherals on the
base-board itself.
MTD
---
The NAND flash should be supported by the in kernel MTD NAND support,
NOR flash will be added later.
Maintainers
-----------
This board is being maintained by Ben Dooks, for more info, see
http://www.fluff.org/ben/smdk2440/
Many thanks to Dimitry Andric of TomTom for the loan of the SMDK2440,
and to Simtec Electronics for allowing me time to work on this.
(c) 2004 Ben Dooks

106
Documentation/arm/Samsung-S3C24XX/Suspend.txt Normal file
Bestand weergeven

@@ -0,0 +1,106 @@
S3C24XX Suspend Support
=======================
Introduction
------------
The S3C2410 supports a low-power suspend mode, where the SDRAM is kept
in Self-Refresh mode, and all but the essential peripheral blocks are
powered down. For more information on how this works, please look
at the S3C2410 datasheets from Samsung.
Requirements
------------
1) A bootloader that can support the necessary resume operation
2) Support for at least 1 source for resume
3) CONFIG_PM enabled in the kernel
4) Any peripherals that are going to be powered down at the same
time require suspend/resume support.
Resuming
--------
The S3C2410 user manual defines the process of sending the CPU to
sleep and how it resumes. The default behaviour of the Linux code
is to set the GSTATUS3 register to the physical address of the
code to resume Linux operation.
GSTATUS4 is currently left alone by the sleep code, and is free to
use for any other purposes (for example, the EB2410ITX uses this to
save memory configuration in).
Machine Support
---------------
The machine specific functions must call the s3c2410_pm_init() function
to say that its bootloader is capable of resuming. This can be as
simple as adding the following to the machine's definition:
INITMACHINE(s3c2410_pm_init)
A board can do its own setup before calling s3c2410_pm_init, if it
needs to setup anything else for power management support.
There is currently no support for over-riding the default method of
saving the resume address, if your board requires it, then contact
the maintainer and discuss what is required.
Note, the original method of adding an late_initcall() is wrong,
and will end up initialising all compiled machines' pm init!
Debugging
---------
There are several important things to remember when using PM suspend:
1) The uart drivers will disable the clocks to the UART blocks when
suspending, which means that use of printascii() or similar direct
access to the UARTs will cause the debug to stop.
2) Whilst the pm code itself will attempt to re-enable the UART clocks,
care should be taken that any external clock sources that the UARTs
rely on are still enabled at that point.
Configuration
-------------
The S3C2410 specific configuration in `System Type` defines various
aspects of how the S3C2410 suspend and resume support is configured
`S3C2410 PM Suspend debug`
This option prints messages to the serial console before and after
the actual suspend, giving detailed information on what is
happening
`S3C2410 PM Suspend Memory CRC`
Allows the entire memory to be checksummed before and after the
suspend to see if there has been any corruption of the contents.
This support requires the CRC32 function to be enabled.
`S3C2410 PM Suspend CRC Chunksize (KiB)`
Defines the size of memory each CRC chunk covers. A smaller value
will mean that the CRC data block will take more memory, but will
identify any faults with better precision
Document Author
---------------
Ben Dooks, (c) 2004 Simtec Electronics

129
Documentation/arm/Setup Normal file
Bestand weergeven

@@ -0,0 +1,129 @@
Kernel initialisation parameters on ARM Linux
---------------------------------------------
The following document describes the kernel initialisation parameter
structure, otherwise known as 'struct param_struct' which is used
for most ARM Linux architectures.
This structure is used to pass initialisation parameters from the
kernel loader to the Linux kernel proper, and may be short lived
through the kernel initialisation process. As a general rule, it
should not be referenced outside of arch/arm/kernel/setup.c:setup_arch().
There are a lot of parameters listed in there, and they are described
below:
page_size
This parameter must be set to the page size of the machine, and
will be checked by the kernel.
nr_pages
This is the total number of pages of memory in the system. If
the memory is banked, then this should contain the total number
of pages in the system.
If the system contains separate VRAM, this value should not
include this information.
ramdisk_size
This is now obsolete, and should not be used.
flags
Various kernel flags, including:
bit 0 - 1 = mount root read only
bit 1 - unused
bit 2 - 0 = load ramdisk
bit 3 - 0 = prompt for ramdisk
rootdev
major/minor number pair of device to mount as the root filesystem.
video_num_cols
video_num_rows
These two together describe the character size of the dummy console,
or VGA console character size. They should not be used for any other
purpose.
It's generally a good idea to set these to be either standard VGA, or
the equivalent character size of your fbcon display. This then allows
all the bootup messages to be displayed correctly.
video_x
video_y
This describes the character position of cursor on VGA console, and
is otherwise unused. (should not used for other console types, and
should not be used for other purposes).
memc_control_reg
MEMC chip control register for Acorn Archimedes and Acorn A5000
based machines. May be used differently by different architectures.
sounddefault
Default sound setting on Acorn machines. May be used differently by
different architectures.
adfsdrives
Number of ADFS/MFM disks. May be used differently by different
architectures.
bytes_per_char_h
bytes_per_char_v
These are now obsolete, and should not be used.
pages_in_bank[4]
Number of pages in each bank of the systems memory (used for RiscPC).
This is intended to be used on systems where the physical memory
is non-contiguous from the processors point of view.
pages_in_vram
Number of pages in VRAM (used on Acorn RiscPC). This value may also
be used by loaders if the size of the video RAM can't be obtained
from the hardware.
initrd_start
initrd_size
This describes the kernel virtual start address and size of the
initial ramdisk.
rd_start
Start address in sectors of the ramdisk image on a floppy disk.
system_rev
system revision number.
system_serial_low
system_serial_high
system 64-bit serial number
mem_fclk_21285
The speed of the external oscillator to the 21285 (footbridge),
which control's the speed of the memory bus, timer & serial port.
Depending upon the speed of the cpu its value can be between
0-66 MHz. If no params are passed or a value of zero is passed,
then a value of 50 Mhz is the default on 21285 architectures.
paths[8][128]
These are now obsolete, and should not be used.
commandline
Kernel command line parameters. Details can be found elsewhere.

32
Documentation/arm/Sharp-LH/CompactFlash Normal file
Bestand weergeven

@@ -0,0 +1,32 @@
README on the Compact Flash for Card Engines
============================================
There are three challenges in supporting the CF interface of the Card
Engines. First, every IO operation must be followed with IO to
another memory region. Second, the slot is wired for one-to-one
address mapping *and* it is wired for 16 bit access only. Second, the
interrupt request line from the CF device isn't wired.
The IOBARRIER issue is covered in README.IOBARRIER. This isn't an
onerous problem. Enough said here.
The addressing issue is solved in the
arch/arm/mach-lh7a40x/ide-lpd7a40x.c file with some awkward
work-arounds. We implement a special SELECT_DRIVE routine that is
called before the IDE driver performs its own SELECT_DRIVE. Our code
recognizes that the SELECT register cannot be modified without also
writing a command. It send an IDLE_IMMEDIATE command on selecting a
drive. The function also prevents drive select to the slave drive
since there can be only one. The awkward part is that the IDE driver,
even though we have a select procedure, also attempts to change the
drive by writing directly the SELECT register. This attempt is
explicitly blocked by the OUTB function--not pretty, but effective.
The lack of interrupts is a more serious problem. Even though the CF
card is fast when compared to a normal IDE device, we don't know that
the CF is really flash. A user could use one of the very small hard
drives being shipped with a CF interface. The IDE code includes a
check for interfaces that lack an IRQ. In these cases, submitting a
command to the IDE controller is followed by a call to poll for
completion. If the device isn't immediately ready, it schedules a
timer to poll again later.

45
Documentation/arm/Sharp-LH/IOBarrier Normal file
Bestand weergeven

@@ -0,0 +1,45 @@
README on the IOBARRIER for CardEngine IO
=========================================
Due to an unfortunate oversight when the Card Engines were designed,
the signals that control access to some peripherals, most notably the
SMC91C9111 ethernet controller, are not properly handled.
The symptom is that some back to back IO with the peripheral returns
unreliable data. With the SMC chip, you'll see errors about the bank
register being 'screwed'.
The cause is that the AEN signal to the SMC chip does not transition
for every memory access. It is driven through the CPLD from the CS7
line of the CPU's static memory controller which is optimized to
eliminate unnecessary transitions. Yet, the SMC requires a transition
for every write access. The Sharp website has more information about
the effect this power-conserving feature has on peripheral
interfacing.
The solution is to follow every write access to the SMC chip with an
access to another memory region that will force the CPU to release the
chip select line. It is important to guarantee that this access
forces the CPU off-chip. We map a page of SDRAM as if it were an
uncacheable IO device and read from it after every SMC IO write
operation.
SMC IO
BARRIER IO
Only this sequence is important. It does not matter that there is no
BARRIER IO before the access to the SMC chip because the AEN latch
only needs occurs after the SMC IO write cycle. The routines that
implement this work-around make an additional concession which is to
disable interrupts during the IO sequence. Other hardware devices
(the LogicPD CPLD) have registers in the same the physical memory
region as the SMC chip. An interrupt might allow an access to one of
those registers while SMC IO is being performed.
You might be tempted to think that we have to access another device
attached to the static memory controller, but the empirical evidence
indicates that this is not so. Mapping 0x00000000 (flash) and
0xc0000000 (SDRAM) appear to have the same effect. Using SDRAM seems
to be faster. Choosing to access an undecoded memory region is not
desirable as there is no way to know how that chip select will be used
in the future.

8
Documentation/arm/Sharp-LH/KEV7A400 Normal file
Bestand weergeven

@@ -0,0 +1,8 @@
README on Implementing Linux for Sharp's KEV7a400
=================================================
This product has been discontinued by Sharp. For the time being, the
partially implemented code remains in the kernel. At some point in
the future, either the code will be finished or it will be removed
completely. This depends primarily on how many of the development
boards are in the field.

15
Documentation/arm/Sharp-LH/LPD7A400 Normal file
Bestand weergeven

@@ -0,0 +1,15 @@
README on Implementing Linux for the Logic PD LPD7A400-10
=========================================================
- CPLD memory mapping
The board designers chose to use high address lines for controlling
access to the CPLD registers. It turns out to be a big waste
because we're using an MMU and must map IO space into virtual
memory. The result is that we have to make a mapping for every
register.
- Serial Console
It may be OK not to use the serial console option if the user passes
the console device name to the kernel. This deserves some exploration.

16
Documentation/arm/Sharp-LH/LPD7A40X Normal file
Bestand weergeven

@@ -0,0 +1,16 @@
README on Implementing Linux for the Logic PD LPD7A40X-10
=========================================================
- CPLD memory mapping
The board designers chose to use high address lines for controlling
access to the CPLD registers. It turns out to be a big waste
because we're using an MMU and must map IO space into virtual
memory. The result is that we have to make a mapping for every
register.
- Serial Console
It may be OK not to use the serial console option if the user passes
the console device name to the kernel. This deserves some exploration.

51
Documentation/arm/Sharp-LH/SDRAM Normal file
Bestand weergeven

@@ -0,0 +1,51 @@
README on the SDRAM Controller for the LH7a40X
==============================================
The standard configuration for the SDRAM controller generates a sparse
memory array. The precise layout is determined by the SDRAM chips. A
default kernel configuration assembles the discontiguous memory
regions into separate memory nodes via the NUMA (Non-Uniform Memory
Architecture) facilities. In this default configuration, the kernel
is forgiving about the precise layout. As long as it is given an
accurate picture of available memory by the bootloader the kernel will
execute correctly.
The SDRC supports a mode where some of the chip select lines are
swapped in order to make SDRAM look like a synchronous ROM. Setting
this bit means that the RAM will present as a contiguous array. Some
programmers prefer this to the discontiguous layout. Be aware that
may be a penalty for this feature where some some configurations of
memory are significantly reduced; i.e. 64MiB of RAM appears as only 32
MiB.
There are a couple of configuration options to override the default
behavior. When the SROMLL bit is set and memory appears as a
contiguous array, there is no reason to support NUMA.
CONFIG_LH7A40X_CONTIGMEM disables NUMA support. When physical memory
is discontiguous, the memory tables are organized such that there are
two banks per nodes with a small gap between them. This layout wastes
some kernel memory for page tables representing non-existent memory.
CONFIG_LH7A40X_ONE_BANK_PER_NODE optimizes the node tables such that
there are no gaps. These options control the low level organization
of the memory management tables in ways that may prevent the kernel
from booting or may cause the kernel to allocated excessively large
page tables. Be warned. Only change these options if you know what
you are doing. The default behavior is a reasonable compromise that
will suit all users.
--
A typical 32MiB system with the default configuration options will
find physical memory managed as follows.
node 0: 0xc0000000 4MiB
0xc1000000 4MiB
node 1: 0xc4000000 4MiB
0xc5000000 4MiB
node 2: 0xc8000000 4MiB
0xc9000000 4MiB
node 3: 0xcc000000 4MiB
0xcd000000 4MiB
Setting CONFIG_LH7A40X_ONE_BANK_PER_NODE will put each bank into a
separate node.

80
Documentation/arm/Sharp-LH/VectoredInterruptController Normal file
Bestand weergeven

@@ -0,0 +1,80 @@
README on the Vectored Interrupt Controller of the LH7A404
==========================================================
The 404 revision of the LH7A40X series comes with two vectored
interrupts controllers. While the kernel does use some of the
features of these devices, it is far from the purpose for which they
were designed.
When this README was written, the implementation of the VICs was in
flux. It is possible that some details, especially with priorities,
will change.
The VIC support code is inspired by routines written by Sharp.
Priority Control
----------------
The significant reason for using the VIC's vectoring is to control
interrupt priorities. There are two tables in
arch/arm/mach-lh7a40x/irq-lh7a404.c that look something like this.
static unsigned char irq_pri_vic1[] = { IRQ_GPIO3INTR, };
static unsigned char irq_pri_vic2[] = {
IRQ_T3UI, IRQ_GPIO7INTR,
IRQ_UART1INTR, IRQ_UART2INTR, IRQ_UART3INTR, };
The initialization code reads these tables and inserts a vector
address and enable for each indicated IRQ. Vectored interrupts have
higher priority than non-vectored interrupts. So, on VIC1,
IRQ_GPIO3INTR will be served before any other non-FIQ interrupt. Due
to the way that the vectoring works, IRQ_T3UI is the next highest
priority followed by the other vectored interrupts on VIC2. After
that, the non-vectored interrupts are scanned in VIC1 then in VIC2.
ISR
---
The interrupt service routine macro get_irqnr() in
arch/arm/kernel/entry-armv.S scans the VICs for the next active
interrupt. The vectoring makes this code somewhat larger than it was
before using vectoring (refer to the LH7A400 implementation). In the
case where an interrupt is vectored, the implementation will tend to
be faster than the non-vectored version. However, the worst-case path
is longer.
It is worth noting that at present, there is no need to read
VIC2_VECTADDR because the register appears to be shared between the
controllers. The code is written such that if this changes, it ought
to still work properly.
Vector Addresses
----------------
The proper use of the vectoring hardware would jump to the ISR
specified by the vectoring address. Linux isn't structured to take
advantage of this feature, though it might be possible to change
things to support it.
In this implementation, the vectoring address is used to speed the
search for the active IRQ. The address is coded such that the lowest
6 bits store the IRQ number for vectored interrupts. These numbers
correspond to the bits in the interrupt status registers. IRQ zero is
the lowest interrupt bit in VIC1. IRQ 32 is the lowest interrupt bit
in VIC2. Because zero is a valid IRQ number and because we cannot
detect whether or not there is a valid vectoring address if that
address is zero, the eigth bit (0x100) is set for vectored interrupts.
The address for IRQ 0x18 (VIC2) is 0x118. Only the ninth bit is set
for the default handler on VIC1 and only the tenth bit is set for the
default handler on VIC2.
In other words.
0x000 - no active interrupt
0x1ii - vectored interrupt 0xii
0x2xx - unvectored interrupt on VIC1 (xx is don't care)
0x4xx - unvectored interrupt on VIC2 (xx is don't care)

55
Documentation/arm/VFP/release-notes.txt Normal file
Bestand weergeven

@@ -0,0 +1,55 @@
Release notes for Linux Kernel VFP support code
-----------------------------------------------
Date: 20 May 2004
Author: Russell King
This is the first release of the Linux Kernel VFP support code. It
provides support for the exceptions bounced from VFP hardware found
on ARM926EJ-S.
This release has been validated against the SoftFloat-2b library by
John R. Hauser using the TestFloat-2a test suite. Details of this
library and test suite can be found at:
http://www.cs.berkeley.edu/~jhauser/arithmetic/SoftFloat.html
The operations which have been tested with this package are:
- fdiv
- fsub
- fadd
- fmul
- fcmp
- fcmpe
- fcvtd
- fcvts
- fsito
- ftosi
- fsqrt
All the above pass softfloat tests with the following exceptions:
- fadd/fsub shows some differences in the handling of +0 / -0 results
when input operands differ in signs.
- the handling of underflow exceptions is slightly different. If a
result underflows before rounding, but becomes a normalised number
after rounding, we do not signal an underflow exception.
Other operations which have been tested by basic assembly-only tests
are:
- fcpy
- fabs
- fneg
- ftoui
- ftosiz
- ftouiz
The combination operations have not been tested:
- fmac
- fnmac
- fmsc
- fnmsc
- fnmul

13
Documentation/arm/empeg/README Normal file
Bestand weergeven

@@ -0,0 +1,13 @@
Empeg, Ltd's Empeg MP3 Car Audio Player
The initial design is to go in your car, but you can use it at home, on a
boat... almost anywhere. The principle is to store CD-quality music using
MPEG technology onto a hard disk in the unit, and use the power of the
embedded computer to serve up the music you want.
For more details, see:
http://www.empeg.com

49
Documentation/arm/empeg/ir.txt Normal file
Bestand weergeven

@@ -0,0 +1,49 @@
Infra-red driver documentation.
Mike Crowe <mac@empeg.com>
(C) Empeg Ltd 1999
Not a lot here yet :-)
The Kenwood KCA-R6A remote control generates a sequence like the following:
Go low for approx 16T (Around 9000us)
Go high for approx 8T (Around 4000us)
Go low for less than 2T (Around 750us)
For each of the 32 bits
Go high for more than 2T (Around 1500us) == 1
Go high for less than T (Around 400us) == 0
Go low for less than 2T (Around 750us)
Rather than repeat a signal when the button is held down certain buttons
generate the following code to indicate repetition.
Go low for approx 16T
Go high for approx 4T
Go low for less than 2T
(By removing the <2T from the start of the sequence and placing at the end
it can be considered a stop bit but I found it easier to deal with it at
the start).
The 32 bits are encoded as XxYy where x and y are the actual data values
while X and Y are the logical inverses of the associated data values. Using
LSB first yields sensible codes for the numbers.
All codes are of the form b9xx
The numeric keys generate the code 0x where x is the number pressed.
Tuner 1c
Tape 1d
CD 1e
CD-MD-CH 1f
Track- 0a
Track+ 0b
Rewind 0c
FF 0d
DNPP 5e
Play/Pause 0e
Vol+ 14
Vol- 15

11
Documentation/arm/empeg/mkdevs Normal file
Bestand weergeven

@@ -0,0 +1,11 @@
#!/bin/sh
mknod /dev/display c 244 0
mknod /dev/ir c 242 0
mknod /dev/usb0 c 243 0
mknod /dev/audio c 245 4
mknod /dev/dsp c 245 3
mknod /dev/mixer c 245 0
mknod /dev/empeg_state c 246 0
mknod /dev/radio0 c 81 64
ln -sf radio0 radio
ln -sf usb0 usb

58
Documentation/arm/mem_alignment Normal file
Bestand weergeven

@@ -0,0 +1,58 @@
Too many problems poped up because of unnoticed misaligned memory access in
kernel code lately. Therefore the alignment fixup is now unconditionally
configured in for SA11x0 based targets. According to Alan Cox, this is a
bad idea to configure it out, but Russell King has some good reasons for
doing so on some f***ed up ARM architectures like the EBSA110. However
this is not the case on many design I'm aware of, like all SA11x0 based
ones.
Of course this is a bad idea to rely on the alignment trap to perform
unaligned memory access in general. If those access are predictable, you
are better to use the macros provided by include/asm/unaligned.h. The
alignment trap can fixup misaligned access for the exception cases, but at
a high performance cost. It better be rare.
Now for user space applications, it is possible to configure the alignment
trap to SIGBUS any code performing unaligned access (good for debugging bad
code), or even fixup the access by software like for kernel code. The later
mode isn't recommended for performance reasons (just think about the
floating point emulation that works about the same way). Fix your code
instead!
Please note that randomly changing the behaviour without good thought is
real bad - it changes the behaviour of all unaligned instructions in user
space, and might cause programs to fail unexpectedly.
To change the alignment trap behavior, simply echo a number into
/proc/sys/debug/alignment. The number is made up from various bits:
bit behavior when set
--- -----------------
0 A user process performing an unaligned memory access
will cause the kernel to print a message indicating
process name, pid, pc, instruction, address, and the
fault code.
1 The kernel will attempt to fix up the user process
performing the unaligned access. This is of course
slow (think about the floating point emulator) and
not recommended for production use.
2 The kernel will send a SIGBUS signal to the user process
performing the unaligned access.
Note that not all combinations are supported - only values 0 through 5.
(6 and 7 don't make sense).
For example, the following will turn on the warnings, but without
fixing up or sending SIGBUS signals:
echo 1 > /proc/sys/debug/alignment
You can also read the content of the same file to get statistical
information on unaligned access occurrences plus the current mode of
operation for user space code.
Nicolas Pitre, Mar 13, 2001. Modified Russell King, Nov 30, 2001.

72
Documentation/arm/memory.txt Normal file
Bestand weergeven

@@ -0,0 +1,72 @@
Kernel Memory Layout on ARM Linux
Russell King <rmk@arm.linux.org.uk>
May 21, 2004 (2.6.6)
This document describes the virtual memory layout which the Linux
kernel uses for ARM processors. It indicates which regions are
free for platforms to use, and which are used by generic code.
The ARM CPU is capable of addressing a maximum of 4GB virtual memory
space, and this must be shared between user space processes, the
kernel, and hardware devices.
As the ARM architecture matures, it becomes necessary to reserve
certain regions of VM space for use for new facilities; therefore
this document may reserve more VM space over time.
Start End Use
--------------------------------------------------------------------------
ffff8000 ffffffff copy_user_page / clear_user_page use.
For SA11xx and Xscale, this is used to
setup a minicache mapping.
ffff1000 ffff7fff Reserved.
Platforms must not use this address range.
ffff0000 ffff0fff CPU vector page.
The CPU vectors are mapped here if the
CPU supports vector relocation (control
register V bit.)
ffc00000 fffeffff DMA memory mapping region. Memory returned
by the dma_alloc_xxx functions will be
dynamically mapped here.
ff000000 ffbfffff Reserved for future expansion of DMA
mapping region.
VMALLOC_END feffffff Free for platform use, recommended.
VMALLOC_START VMALLOC_END-1 vmalloc() / ioremap() space.
Memory returned by vmalloc/ioremap will
be dynamically placed in this region.
VMALLOC_START may be based upon the value
of the high_memory variable.
PAGE_OFFSET high_memory-1 Kernel direct-mapped RAM region.
This maps the platforms RAM, and typically
maps all platform RAM in a 1:1 relationship.
TASK_SIZE PAGE_OFFSET-1 Kernel module space
Kernel modules inserted via insmod are
placed here using dynamic mappings.
00001000 TASK_SIZE-1 User space mappings
Per-thread mappings are placed here via
the mmap() system call.
00000000 00000fff CPU vector page / null pointer trap
CPUs which do not support vector remapping
place their vector page here. NULL pointer
dereferences by both the kernel and user
space are also caught via this mapping.
Please note that mappings which collide with the above areas may result
in a non-bootable kernel, or may cause the kernel to (eventually) panic
at run time.
Since future CPUs may impact the kernel mapping layout, user programs
must not access any memory which is not mapped inside their 0x0001000
to TASK_SIZE address range. If they wish to access these areas, they
must set up their own mappings using open() and mmap().

29
Documentation/arm/nwfpe/NOTES Normal file
Bestand weergeven

@@ -0,0 +1,29 @@
There seems to be a problem with exp(double) and our emulator. I haven't
been able to track it down yet. This does not occur with the emulator
supplied by Russell King.
I also found one oddity in the emulator. I don't think it is serious but
will point it out. The ARM calling conventions require floating point
registers f4-f7 to be preserved over a function call. The compiler quite
often uses an stfe instruction to save f4 on the stack upon entry to a
function, and an ldfe instruction to restore it before returning.
I was looking at some code, that calculated a double result, stored it in f4
then made a function call. Upon return from the function call the number in
f4 had been converted to an extended value in the emulator.
This is a side effect of the stfe instruction. The double in f4 had to be
converted to extended, then stored. If an lfm/sfm combination had been used,
then no conversion would occur. This has performance considerations. The
result from the function call and f4 were used in a multiplication. If the
emulator sees a multiply of a double and extended, it promotes the double to
extended, then does the multiply in extended precision.
This code will cause this problem:
double x, y, z;
z = log(x)/log(y);
The result of log(x) (a double) will be calculated, returned in f0, then
moved to f4 to preserve it over the log(y) call. The division will be done
in extended precision, due to the stfe instruction used to save f4 in log(y).

70
Documentation/arm/nwfpe/README Normal file
Bestand weergeven

@@ -0,0 +1,70 @@
This directory contains the version 0.92 test release of the NetWinder
Floating Point Emulator.
The majority of the code was written by me, Scott Bambrough It is
written in C, with a small number of routines in inline assembler
where required. It was written quickly, with a goal of implementing a
working version of all the floating point instructions the compiler
emits as the first target. I have attempted to be as optimal as
possible, but there remains much room for improvement.
I have attempted to make the emulator as portable as possible. One of
the problems is with leading underscores on kernel symbols. Elf
kernels have no leading underscores, a.out compiled kernels do. I
have attempted to use the C_SYMBOL_NAME macro wherever this may be
important.
Another choice I made was in the file structure. I have attempted to
contain all operating system specific code in one module (fpmodule.*).
All the other files contain emulator specific code. This should allow
others to port the emulator to NetBSD for instance relatively easily.
The floating point operations are based on SoftFloat Release 2, by
John Hauser. SoftFloat is a software implementation of floating-point
that conforms to the IEC/IEEE Standard for Binary Floating-point
Arithmetic. As many as four formats are supported: single precision,
double precision, extended double precision, and quadruple precision.
All operations required by the standard are implemented, except for
conversions to and from decimal. We use only the single precision,
double precision and extended double precision formats. The port of
SoftFloat to the ARM was done by Phil Blundell, based on an earlier
port of SoftFloat version 1 by Neil Carson for NetBSD/arm32.
The file README.FPE contains a description of what has been implemented
so far in the emulator. The file TODO contains a information on what
remains to be done, and other ideas for the emulator.
Bug reports, comments, suggestions should be directed to me at
<scottb@netwinder.org>. General reports of "this program doesn't
work correctly when your emulator is installed" are useful for
determining that bugs still exist; but are virtually useless when
attempting to isolate the problem. Please report them, but don't
expect quick action. Bugs still exist. The problem remains in isolating
which instruction contains the bug. Small programs illustrating a specific
problem are a godsend.
Legal Notices
-------------
The NetWinder Floating Point Emulator is free software. Everything Rebel.com
has written is provided under the GNU GPL. See the file COPYING for copying
conditions. Excluded from the above is the SoftFloat code. John Hauser's
legal notice for SoftFloat is included below.
-------------------------------------------------------------------------------
SoftFloat Legal Notice
SoftFloat was written by John R. Hauser. This work was made possible in
part by the International Computer Science Institute, located at Suite 600,
1947 Center Street, Berkeley, California 94704. Funding was partially
provided by the National Science Foundation under grant MIP-9311980. The
original version of this code was written as part of a project to build
a fixed-point vector processor in collaboration with the University of
California at Berkeley, overseen by Profs. Nelson Morgan and John Wawrzynek.
THIS SOFTWARE IS DISTRIBUTED AS IS, FOR FREE. Although reasonable effort
has been made to avoid it, THIS SOFTWARE MAY CONTAIN FAULTS THAT WILL AT
TIMES RESULT IN INCORRECT BEHAVIOR. USE OF THIS SOFTWARE IS RESTRICTED TO
PERSONS AND ORGANIZATIONS WHO CAN AND WILL TAKE FULL RESPONSIBILITY FOR ANY
AND ALL LOSSES, COSTS, OR OTHER PROBLEMS ARISING FROM ITS USE.
-------------------------------------------------------------------------------

156
Documentation/arm/nwfpe/README.FPE Normal file
Bestand weergeven

@@ -0,0 +1,156 @@
The following describes the current state of the NetWinder's floating point
emulator.
In the following nomenclature is used to describe the floating point
instructions. It follows the conventions in the ARM manual.
<S|D|E> = <single|double|extended>, no default
{P|M|Z} = {round to +infinity,round to -infinity,round to zero},
default = round to nearest
Note: items enclosed in {} are optional.
Floating Point Coprocessor Data Transfer Instructions (CPDT)
------------------------------------------------------------
LDF/STF - load and store floating
<LDF|STF>{cond}<S|D|E> Fd, Rn
<LDF|STF>{cond}<S|D|E> Fd, [Rn, #<expression>]{!}
<LDF|STF>{cond}<S|D|E> Fd, [Rn], #<expression>
These instructions are fully implemented.
LFM/SFM - load and store multiple floating
Form 1 syntax:
<LFM|SFM>{cond}<S|D|E> Fd, <count>, [Rn]
<LFM|SFM>{cond}<S|D|E> Fd, <count>, [Rn, #<expression>]{!}
<LFM|SFM>{cond}<S|D|E> Fd, <count>, [Rn], #<expression>
Form 2 syntax:
<LFM|SFM>{cond}<FD,EA> Fd, <count>, [Rn]{!}
These instructions are fully implemented. They store/load three words
for each floating point register into the memory location given in the
instruction. The format in memory is unlikely to be compatible with
other implementations, in particular the actual hardware. Specific
mention of this is made in the ARM manuals.
Floating Point Coprocessor Register Transfer Instructions (CPRT)
----------------------------------------------------------------
Conversions, read/write status/control register instructions
FLT{cond}<S,D,E>{P,M,Z} Fn, Rd Convert integer to floating point
FIX{cond}{P,M,Z} Rd, Fn Convert floating point to integer
WFS{cond} Rd Write floating point status register
RFS{cond} Rd Read floating point status register
WFC{cond} Rd Write floating point control register
RFC{cond} Rd Read floating point control register
FLT/FIX are fully implemented.
RFS/WFS are fully implemented.
RFC/WFC are fully implemented. RFC/WFC are supervisor only instructions, and
presently check the CPU mode, and do an invalid instruction trap if not called
from supervisor mode.
Compare instructions
CMF{cond} Fn, Fm Compare floating
CMFE{cond} Fn, Fm Compare floating with exception
CNF{cond} Fn, Fm Compare negated floating
CNFE{cond} Fn, Fm Compare negated floating with exception
These are fully implemented.
Floating Point Coprocessor Data Instructions (CPDT)
---------------------------------------------------
Dyadic operations:
ADF{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - add
SUF{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - subtract
RSF{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - reverse subtract
MUF{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - multiply
DVF{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - divide
RDV{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - reverse divide
These are fully implemented.
FML{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - fast multiply
FDV{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - fast divide
FRD{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - fast reverse divide
These are fully implemented as well. They use the same algorithm as the
non-fast versions. Hence, in this implementation their performance is
equivalent to the MUF/DVF/RDV instructions. This is acceptable according
to the ARM manual. The manual notes these are defined only for single
operands, on the actual FPA11 hardware they do not work for double or
extended precision operands. The emulator currently does not check
the requested permissions conditions, and performs the requested operation.
RMF{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - IEEE remainder
This is fully implemented.
Monadic operations:
MVF{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - move
MNF{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - move negated
These are fully implemented.
ABS{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - absolute value
SQT{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - square root
RND{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - round
These are fully implemented.
URD{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - unnormalized round
NRM{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - normalize
These are implemented. URD is implemented using the same code as the RND
instruction. Since URD cannot return a unnormalized number, NRM becomes
a NOP.
Library calls:
POW{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - power
RPW{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - reverse power
POL{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - polar angle (arctan2)
LOG{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - logarithm to base 10
LGN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - logarithm to base e
EXP{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - exponent
SIN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - sine
COS{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - cosine
TAN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - tangent
ASN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arcsine
ACS{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arccosine
ATN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arctangent
These are not implemented. They are not currently issued by the compiler,
and are handled by routines in libc. These are not implemented by the FPA11
hardware, but are handled by the floating point support code. They should
be implemented in future versions.
Signalling:
Signals are implemented. However current ELF kernels produced by Rebel.com
have a bug in them that prevents the module from generating a SIGFPE. This
is caused by a failure to alias fp_current to the kernel variable
current_set[0] correctly.
The kernel provided with this distribution (vmlinux-nwfpe-0.93) contains
a fix for this problem and also incorporates the current version of the
emulator directly. It is possible to run with no floating point module
loaded with this kernel. It is provided as a demonstration of the
technology and for those who want to do floating point work that depends
on signals. It is not strictly necessary to use the module.
A module (either the one provided by Russell King, or the one in this
distribution) can be loaded to replace the functionality of the emulator
built into the kernel.

67
Documentation/arm/nwfpe/TODO Normal file
Bestand weergeven

@@ -0,0 +1,67 @@
TODO LIST
---------
POW{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - power
RPW{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - reverse power
POL{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - polar angle (arctan2)
LOG{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - logarithm to base 10
LGN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - logarithm to base e
EXP{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - exponent
SIN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - sine
COS{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - cosine
TAN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - tangent
ASN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arcsine
ACS{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arccosine
ATN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arctangent
These are not implemented. They are not currently issued by the compiler,
and are handled by routines in libc. These are not implemented by the FPA11
hardware, but are handled by the floating point support code. They should
be implemented in future versions.
There are a couple of ways to approach the implementation of these. One
method would be to use accurate table methods for these routines. I have
a couple of papers by S. Gal from IBM's research labs in Haifa, Israel that
seem to promise extreme accuracy (in the order of 99.8%) and reasonable speed.
These methods are used in GLIBC for some of the transcendental functions.
Another approach, which I know little about is CORDIC. This stands for
Coordinate Rotation Digital Computer, and is a method of computing
transcendental functions using mostly shifts and adds and a few
multiplications and divisions. The ARM excels at shifts and adds,
so such a method could be promising, but requires more research to
determine if it is feasible.
Rounding Methods
The IEEE standard defines 4 rounding modes. Round to nearest is the
default, but rounding to + or - infinity or round to zero are also allowed.
Many architectures allow the rounding mode to be specified by modifying bits
in a control register. Not so with the ARM FPA11 architecture. To change
the rounding mode one must specify it with each instruction.
This has made porting some benchmarks difficult. It is possible to
introduce such a capability into the emulator. The FPCR contains
bits describing the rounding mode. The emulator could be altered to
examine a flag, which if set forced it to ignore the rounding mode in
the instruction, and use the mode specified in the bits in the FPCR.
This would require a method of getting/setting the flag, and the bits
in the FPCR. This requires a kernel call in ArmLinux, as WFC/RFC are
supervisor only instructions. If anyone has any ideas or comments I
would like to hear them.
[NOTE: pulled out from some docs on ARM floating point, specifically
for the Acorn FPE, but not limited to it:
The floating point control register (FPCR) may only be present in some
implementations: it is there to control the hardware in an implementation-
specific manner, for example to disable the floating point system. The user
mode of the ARM is not permitted to use this register (since the right is
reserved to alter it between implementations) and the WFC and RFC
instructions will trap if tried in user mode.
Hence, the answer is yes, you could do this, but then you will run a high
risk of becoming isolated if and when hardware FP emulation comes out
-- Russell].