aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/arm
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/arm')
-rw-r--r--Documentation/arm/00-INDEX20
-rw-r--r--Documentation/arm/Booting141
-rw-r--r--Documentation/arm/IXP200069
-rw-r--r--Documentation/arm/IXP4xx174
-rw-r--r--Documentation/arm/Interrupts173
-rw-r--r--Documentation/arm/Netwinder78
-rw-r--r--Documentation/arm/Porting135
-rw-r--r--Documentation/arm/README198
-rw-r--r--Documentation/arm/SA1100/ADSBitsy43
-rw-r--r--Documentation/arm/SA1100/Assabet301
-rw-r--r--Documentation/arm/SA1100/Brutus66
-rw-r--r--Documentation/arm/SA1100/CERF29
-rw-r--r--Documentation/arm/SA1100/FreeBird21
-rw-r--r--Documentation/arm/SA1100/GraphicsClient98
-rw-r--r--Documentation/arm/SA1100/GraphicsMaster53
-rw-r--r--Documentation/arm/SA1100/HUW_WEBPANEL17
-rw-r--r--Documentation/arm/SA1100/Itsy39
-rw-r--r--Documentation/arm/SA1100/LART14
-rw-r--r--Documentation/arm/SA1100/PLEB11
-rw-r--r--Documentation/arm/SA1100/Pangolin23
-rw-r--r--Documentation/arm/SA1100/Tifon7
-rw-r--r--Documentation/arm/SA1100/Victor16
-rw-r--r--Documentation/arm/SA1100/Yopy2
-rw-r--r--Documentation/arm/SA1100/empeg2
-rw-r--r--Documentation/arm/SA1100/nanoEngine11
-rw-r--r--Documentation/arm/SA1100/serial_UART47
-rw-r--r--Documentation/arm/Samsung-S3C24XX/EB2410ITX.txt58
-rw-r--r--Documentation/arm/Samsung-S3C24XX/GPIO.txt122
-rw-r--r--Documentation/arm/Samsung-S3C24XX/H1940.txt40
-rw-r--r--Documentation/arm/Samsung-S3C24XX/Overview.txt156
-rw-r--r--Documentation/arm/Samsung-S3C24XX/SMDK2440.txt56
-rw-r--r--Documentation/arm/Samsung-S3C24XX/Suspend.txt106
-rw-r--r--Documentation/arm/Setup129
-rw-r--r--Documentation/arm/Sharp-LH/CompactFlash32
-rw-r--r--Documentation/arm/Sharp-LH/IOBarrier45
-rw-r--r--Documentation/arm/Sharp-LH/KEV7A4008
-rw-r--r--Documentation/arm/Sharp-LH/LPD7A40015
-rw-r--r--Documentation/arm/Sharp-LH/LPD7A40X16
-rw-r--r--Documentation/arm/Sharp-LH/SDRAM51
-rw-r--r--Documentation/arm/Sharp-LH/VectoredInterruptController80
-rw-r--r--Documentation/arm/VFP/release-notes.txt55
-rw-r--r--Documentation/arm/empeg/README13
-rw-r--r--Documentation/arm/empeg/ir.txt49
-rw-r--r--Documentation/arm/empeg/mkdevs11
-rw-r--r--Documentation/arm/mem_alignment58
-rw-r--r--Documentation/arm/memory.txt72
-rw-r--r--Documentation/arm/nwfpe/NOTES29
-rw-r--r--Documentation/arm/nwfpe/README70
-rw-r--r--Documentation/arm/nwfpe/README.FPE156
-rw-r--r--Documentation/arm/nwfpe/TODO67
50 files changed, 3282 insertions, 0 deletions
diff --git a/Documentation/arm/00-INDEX b/Documentation/arm/00-INDEX
new file mode 100644
index 000000000000..d753fe59a248
--- /dev/null
+++ b/Documentation/arm/00-INDEX
@@ -0,0 +1,20 @@
100-INDEX
2 - this file
3Booting
4 - requirements for booting
5Interrupts
6 - ARM Interrupt subsystem documentation
7Netwinder
8 - Netwinder specific documentation
9README
10 - General ARM documentation
11SA1100
12 - SA1100 documentation
13XScale
14 - XScale documentation
15empeg
16 - Empeg documentation
17mem_alignment
18 - alignment abort handler documentation
19nwfpe
20 - NWFPE floating point emulator documentation
diff --git a/Documentation/arm/Booting b/Documentation/arm/Booting
new file mode 100644
index 000000000000..fad566bb02fc
--- /dev/null
+++ b/Documentation/arm/Booting
@@ -0,0 +1,141 @@
1 Booting ARM Linux
2 =================
3
4Author: Russell King
5Date : 18 May 2002
6
7The following documentation is relevant to 2.4.18-rmk6 and beyond.
8
9In order to boot ARM Linux, you require a boot loader, which is a small
10program that runs before the main kernel. The boot loader is expected
11to initialise various devices, and eventually call the Linux kernel,
12passing information to the kernel.
13
14Essentially, the boot loader should provide (as a minimum) the
15following:
16
171. Setup and initialise the RAM.
182. Initialise one serial port.
193. Detect the machine type.
204. Setup the kernel tagged list.
215. Call the kernel image.
22
23
241. Setup and initialise RAM
25---------------------------
26
27Existing boot loaders: MANDATORY
28New boot loaders: MANDATORY
29
30The boot loader is expected to find and initialise all RAM that the
31kernel will use for volatile data storage in the system. It performs
32this in a machine dependent manner. (It may use internal algorithms
33to automatically locate and size all RAM, or it may use knowledge of
34the RAM in the machine, or any other method the boot loader designer
35sees fit.)
36
37
382. Initialise one serial port
39-----------------------------
40
41Existing boot loaders: OPTIONAL, RECOMMENDED
42New boot loaders: OPTIONAL, RECOMMENDED
43
44The boot loader should initialise and enable one serial port on the
45target. This allows the kernel serial driver to automatically detect
46which serial port it should use for the kernel console (generally
47used for debugging purposes, or communication with the target.)
48
49As an alternative, the boot loader can pass the relevant 'console='
50option to the kernel via the tagged lists specifying the port, and
51serial format options as described in
52
53 Documentation/kernel-parameters.txt.
54
55
563. Detect the machine type
57--------------------------
58
59Existing boot loaders: OPTIONAL
60New boot loaders: MANDATORY
61
62The boot loader should detect the machine type its running on by some
63method. Whether this is a hard coded value or some algorithm that
64looks at the connected hardware is beyond the scope of this document.
65The boot loader must ultimately be able to provide a MACH_TYPE_xxx
66value to the kernel. (see linux/arch/arm/tools/mach-types).
67
68
694. Setup the kernel tagged list
70-------------------------------
71
72Existing boot loaders: OPTIONAL, HIGHLY RECOMMENDED
73New boot loaders: MANDATORY
74
75The boot loader must create and initialise the kernel tagged list.
76A valid tagged list starts with ATAG_CORE and ends with ATAG_NONE.
77The ATAG_CORE tag may or may not be empty. An empty ATAG_CORE tag
78has the size field set to '2' (0x00000002). The ATAG_NONE must set
79the size field to zero.
80
81Any number of tags can be placed in the list. It is undefined
82whether a repeated tag appends to the information carried by the
83previous tag, or whether it replaces the information in its
84entirety; some tags behave as the former, others the latter.
85
86The boot loader must pass at a minimum the size and location of
87the system memory, and root filesystem location. Therefore, the
88minimum tagged list should look:
89
90 +-----------+
91base -> | ATAG_CORE | |
92 +-----------+ |
93 | ATAG_MEM | | increasing address
94 +-----------+ |
95 | ATAG_NONE | |
96 +-----------+ v
97
98The tagged list should be stored in system RAM.
99
100The tagged list must be placed in a region of memory where neither
101the kernel decompressor nor initrd 'bootp' program will overwrite
102it. The recommended placement is in the first 16KiB of RAM.
103
1045. Calling the kernel image
105---------------------------
106
107Existing boot loaders: MANDATORY
108New boot loaders: MANDATORY
109
110There are two options for calling the kernel zImage. If the zImage
111is stored in flash, and is linked correctly to be run from flash,
112then it is legal for the boot loader to call the zImage in flash
113directly.
114
115The zImage may also be placed in system RAM (at any location) and
116called there. Note that the kernel uses 16K of RAM below the image
117to store page tables. The recommended placement is 32KiB into RAM.
118
119In either case, the following conditions must be met:
120
121- Quiesce all DMA capable devicess so that memory does not get
122 corrupted by bogus network packets or disk data. This will save
123 you many hours of debug.
124
125- CPU register settings
126 r0 = 0,
127 r1 = machine type number discovered in (3) above.
128 r2 = physical address of tagged list in system RAM.
129
130- CPU mode
131 All forms of interrupts must be disabled (IRQs and FIQs)
132 The CPU must be in SVC mode. (A special exception exists for Angel)
133
134- Caches, MMUs
135 The MMU must be off.
136 Instruction cache may be on or off.
137 Data cache must be off.
138
139- The boot loader is expected to call the kernel image by jumping
140 directly to the first instruction of the kernel image.
141
diff --git a/Documentation/arm/IXP2000 b/Documentation/arm/IXP2000
new file mode 100644
index 000000000000..e0148b6b2c40
--- /dev/null
+++ b/Documentation/arm/IXP2000
@@ -0,0 +1,69 @@
1
2-------------------------------------------------------------------------
3Release Notes for Linux on Intel's IXP2000 Network Processor
4
5Maintained by Deepak Saxena <dsaxena@plexity.net>
6-------------------------------------------------------------------------
7
81. Overview
9
10Intel's IXP2000 family of NPUs (IXP2400, IXP2800, IXP2850) is designed
11for high-performance network applications such high-availability
12telecom systems. In addition to an XScale core, it contains up to 8
13"MicroEngines" that run special code, several high-end networking
14interfaces (UTOPIA, SPI, etc), a PCI host bridge, one serial port,
15flash interface, and some other odds and ends. For more information, see:
16
17http://developer.intel.com/design/network/products/npfamily/ixp2xxx.htm
18
192. Linux Support
20
21Linux currently supports the following features on the IXP2000 NPUs:
22
23- On-chip serial
24- PCI
25- Flash (MTD/JFFS2)
26- I2C through GPIO
27- Timers (watchdog, OS)
28
29That is about all we can support under Linux ATM b/c the core networking
30components of the chip are accessed via Intel's closed source SDK.
31Please contact Intel directly on issues with using those. There is
32also a mailing list run by some folks at Princeton University that might
33be of help: https://lists.cs.princeton.edu/mailman/listinfo/ixp2xxx
34
35WHATEVER YOU DO, DO NOT POST EMAIL TO THE LINUX-ARM OR LINUX-ARM-KERNEL
36MAILING LISTS REGARDING THE INTEL SDK.
37
383. Supported Platforms
39
40- Intel IXDP2400 Reference Platform
41- Intel IXDP2800 Reference Platform
42- Intel IXDP2401 Reference Platform
43- Intel IXDP2801 Reference Platform
44- RadiSys ENP-2611
45
464. Usage Notes
47
48- The IXP2000 platforms usually have rather complex PCI bus topologies
49 with large memory space requirements. In addition, b/c of the way the
50 Intel SDK is designed, devices are enumerated in a very specific
51 way. B/c of this this, we use "pci=firmware" option in the kernel
52 command line so that we do not re-enumerate the bus.
53
54- IXDP2x01 systems have variable clock tick rates that we cannot determine
55 via HW registers. The "ixdp2x01_clk=XXX" cmd line options allow you
56 to pass the clock rate to the board port.
57
585. Thanks
59
60The IXP2000 work has been funded by Intel Corp. and MontaVista Software, Inc.
61
62The following people have contributed patches/comments/etc:
63
64Naeem F. Afzal
65Lennert Buytenhek
66Jeffrey Daly
67
68-------------------------------------------------------------------------
69Last Update: 8/09/2004
diff --git a/Documentation/arm/IXP4xx b/Documentation/arm/IXP4xx
new file mode 100644
index 000000000000..d4c6d3aa0c25
--- /dev/null
+++ b/Documentation/arm/IXP4xx
@@ -0,0 +1,174 @@
1
2-------------------------------------------------------------------------
3Release Notes for Linux on Intel's IXP4xx Network Processor
4
5Maintained by Deepak Saxena <dsaxena@plexity.net>
6-------------------------------------------------------------------------
7
81. Overview
9
10Intel's IXP4xx network processor is a highly integrated SOC that
11is targeted for network applications, though it has become popular
12in industrial control and other areas due to low cost and power
13consumption. The IXP4xx family currently consists of several processors
14that support different network offload functions such as encryption,
15routing, firewalling, etc. The IXP46x family is an updated version which
16supports faster speeds, new memory and flash configurations, and more
17integration such as an on-chip I2C controller.
18
19For more information on the various versions of the CPU, see:
20
21 http://developer.intel.com/design/network/products/npfamily/ixp4xx.htm
22
23Intel also made the IXCP1100 CPU for sometime which is an IXP4xx
24stripped of much of the network intelligence.
25
262. Linux Support
27
28Linux currently supports the following features on the IXP4xx chips:
29
30- Dual serial ports
31- PCI interface
32- Flash access (MTD/JFFS)
33- I2C through GPIO on IXP42x
34- GPIO for input/output/interrupts
35 See include/asm-arm/arch-ixp4xx/platform.h for access functions.
36- Timers (watchdog, OS)
37
38The following components of the chips are not supported by Linux and
39require the use of Intel's propietary CSR softare:
40
41- USB device interface
42- Network interfaces (HSS, Utopia, NPEs, etc)
43- Network offload functionality
44
45If you need to use any of the above, you need to download Intel's
46software from:
47
48 http://developer.intel.com/design/network/products/npfamily/ixp425swr1.htm
49
50DO NOT POST QUESTIONS TO THE LINUX MAILING LISTS REGARDING THE PROPIETARY
51SOFTWARE.
52
53There are several websites that provide directions/pointers on using
54Intel's software:
55
56http://ixp4xx-osdg.sourceforge.net/
57 Open Source Developer's Guide for using uClinux and the Intel libraries
58
59http://gatewaymaker.sourceforge.net/
60 Simple one page summary of building a gateway using an IXP425 and Linux
61
62http://ixp425.sourceforge.net/
63 ATM device driver for IXP425 that relies on Intel's libraries
64
653. Known Issues/Limitations
66
673a. Limited inbound PCI window
68
69The IXP4xx family allows for up to 256MB of memory but the PCI interface
70can only expose 64MB of that memory to the PCI bus. This means that if
71you are running with > 64MB, all PCI buffers outside of the accessible
72range will be bounced using the routines in arch/arm/common/dmabounce.c.
73
743b. Limited outbound PCI window
75
76IXP4xx provides two methods of accessing PCI memory space:
77
781) A direct mapped window from 0x48000000 to 0x4bffffff (64MB).
79 To access PCI via this space, we simply ioremap() the BAR
80 into the kernel and we can use the standard read[bwl]/write[bwl]
81 macros. This is the preffered method due to speed but it
82 limits the system to just 64MB of PCI memory. This can be
83 problamatic if using video cards and other memory-heavy devices.
84
852) If > 64MB of memory space is required, the IXP4xx can be
86 configured to use indirect registers to access PCI This allows
87 for up to 128MB (0x48000000 to 0x4fffffff) of memory on the bus.
88 The disadvantadge of this is that every PCI access requires
89 three local register accesses plus a spinlock, but in some
90 cases the performance hit is acceptable. In addition, you cannot
91 mmap() PCI devices in this case due to the indirect nature
92 of the PCI window.
93
94By default, the direct method is used for performance reasons. If
95you need more PCI memory, enable the IXP4XX_INDIRECT_PCI config option.
96
973c. GPIO as Interrupts
98
99Currently the code only handles level-sensitive GPIO interrupts
100
1014. Supported platforms
102
103ADI Engineering Coyote Gateway Reference Platform
104http://www.adiengineering.com/productsCoyote.html
105
106 The ADI Coyote platform is reference design for those building
107 small residential/office gateways. One NPE is connected to a 10/100
108 interface, one to 4-port 10/100 switch, and the third to and ADSL
109 interface. In addition, it also supports to POTs interfaces connected
110 via SLICs. Note that those are not supported by Linux ATM. Finally,
111 the platform has two mini-PCI slots used for 802.11[bga] cards.
112 Finally, there is an IDE port hanging off the expansion bus.
113
114Gateworks Avila Network Platform
115http://www.gateworks.com/avila_sbc.htm
116
117 The Avila platform is basically and IXDP425 with the 4 PCI slots
118 replaced with mini-PCI slots and a CF IDE interface hanging off
119 the expansion bus.
120
121Intel IXDP425 Development Platform
122http://developer.intel.com/design/network/products/npfamily/ixdp425.htm
123
124 This is Intel's standard reference platform for the IXDP425 and is
125 also known as the Richfield board. It contains 4 PCI slots, 16MB
126 of flash, two 10/100 ports and one ADSL port.
127
128Intel IXDP465 Development Platform
129http://developer.intel.com/design/network/products/npfamily/ixdp465.htm
130
131 This is basically an IXDP425 with an IXP465 and 32M of flash instead
132 of just 16.
133
134Intel IXDPG425 Development Platform
135
136 This is basically and ADI Coyote board with a NEC EHCI controller
137 added. One issue with this board is that the mini-PCI slots only
138 have the 3.3v line connected, so you can't use a PCI to mini-PCI
139 adapter with an E100 card. So to NFS root you need to use either
140 the CSR or a WiFi card and a ramdisk that BOOTPs and then does
141 a pivot_root to NFS.
142
143Motorola PrPMC1100 Processor Mezanine Card
144http://www.fountainsys.com/datasheet/PrPMC1100.pdf
145
146 The PrPMC1100 is based on the IXCP1100 and is meant to plug into
147 and IXP2400/2800 system to act as the system controller. It simply
148 contains a CPU and 16MB of flash on the board and needs to be
149 plugged into a carrier board to function. Currently Linux only
150 supports the Motorola PrPMC carrier board for this platform.
151 See https://mcg.motorola.com/us/ds/pdf/ds0144.pdf for info
152 on the carrier board.
153
1545. TODO LIST
155
156- Add support for Coyote IDE
157- Add support for edge-based GPIO interrupts
158- Add support for CF IDE on expansion bus
159
1606. Thanks
161
162The IXP4xx work has been funded by Intel Corp. and MontaVista Software, Inc.
163
164The following people have contributed patches/comments/etc:
165
166Lennerty Buytenhek
167Lutz Jaenicke
168Justin Mayfield
169Robert E. Ranslam
170[I know I've forgotten others, please email me to be added]
171
172-------------------------------------------------------------------------
173
174Last Update: 01/04/2005
diff --git a/Documentation/arm/Interrupts b/Documentation/arm/Interrupts
new file mode 100644
index 000000000000..72c93de8cd4e
--- /dev/null
+++ b/Documentation/arm/Interrupts
@@ -0,0 +1,173 @@
12.5.2-rmk5
2----------
3
4This is the first kernel that contains a major shake up of some of the
5major architecture-specific subsystems.
6
7Firstly, it contains some pretty major changes to the way we handle the
8MMU TLB. Each MMU TLB variant is now handled completely separately -
9we have TLB v3, TLB v4 (without write buffer), TLB v4 (with write buffer),
10and finally TLB v4 (with write buffer, with I TLB invalidate entry).
11There is more assembly code inside each of these functions, mainly to
12allow more flexible TLB handling for the future.
13
14Secondly, the IRQ subsystem.
15
16The 2.5 kernels will be having major changes to the way IRQs are handled.
17Unfortunately, this means that machine types that touch the irq_desc[]
18array (basically all machine types) will break, and this means every
19machine type that we currently have.
20
21Lets take an example. On the Assabet with Neponset, we have:
22
23 GPIO25 IRR:2
24 SA1100 ------------> Neponset -----------> SA1111
25 IIR:1
26 -----------> USAR
27 IIR:0
28 -----------> SMC9196
29
30The way stuff currently works, all SA1111 interrupts are mutually
31exclusive of each other - if you're processing one interrupt from the
32SA1111 and another comes in, you have to wait for that interrupt to
33finish processing before you can service the new interrupt. Eg, an
34IDE PIO-based interrupt on the SA1111 excludes all other SA1111 and
35SMC9196 interrupts until it has finished transferring its multi-sector
36data, which can be a long time. Note also that since we loop in the
37SA1111 IRQ handler, SA1111 IRQs can hold off SMC9196 IRQs indefinitely.
38
39
40The new approach brings several new ideas...
41
42We introduce the concept of a "parent" and a "child". For example,
43to the Neponset handler, the "parent" is GPIO25, and the "children"d
44are SA1111, SMC9196 and USAR.
45
46We also bring the idea of an IRQ "chip" (mainly to reduce the size of
47the irqdesc array). This doesn't have to be a real "IC"; indeed the
48SA11x0 IRQs are handled by two separate "chip" structures, one for
49GPIO0-10, and another for all the rest. It is just a container for
50the various operations (maybe this'll change to a better name).
51This structure has the following operations:
52
53struct irqchip {
54 /*
55 * Acknowledge the IRQ.
56 * If this is a level-based IRQ, then it is expected to mask the IRQ
57 * as well.
58 */
59 void (*ack)(unsigned int irq);
60 /*
61 * Mask the IRQ in hardware.
62 */
63 void (*mask)(unsigned int irq);
64 /*
65 * Unmask the IRQ in hardware.
66 */
67 void (*unmask)(unsigned int irq);
68 /*
69 * Re-run the IRQ
70 */
71 void (*rerun)(unsigned int irq);
72 /*
73 * Set the type of the IRQ.
74 */
75 int (*type)(unsigned int irq, unsigned int, type);
76};
77
78ack - required. May be the same function as mask for IRQs
79 handled by do_level_IRQ.
80mask - required.
81unmask - required.
82rerun - optional. Not required if you're using do_level_IRQ for all
83 IRQs that use this 'irqchip'. Generally expected to re-trigger
84 the hardware IRQ if possible. If not, may call the handler
85 directly.
86type - optional. If you don't support changing the type of an IRQ,
87 it should be null so people can detect if they are unable to
88 set the IRQ type.
89
90For each IRQ, we keep the following information:
91
92 - "disable" depth (number of disable_irq()s without enable_irq()s)
93 - flags indicating what we can do with this IRQ (valid, probe,
94 noautounmask) as before
95 - status of the IRQ (probing, enable, etc)
96 - chip
97 - per-IRQ handler
98 - irqaction structure list
99
100The handler can be one of the 3 standard handlers - "level", "edge" and
101"simple", or your own specific handler if you need to do something special.
102
103The "level" handler is what we currently have - its pretty simple.
104"edge" knows about the brokenness of such IRQ implementations - that you
105need to leave the hardware IRQ enabled while processing it, and queueing
106further IRQ events should the IRQ happen again while processing. The
107"simple" handler is very basic, and does not perform any hardware
108manipulation, nor state tracking. This is useful for things like the
109SMC9196 and USAR above.
110
111So, what's changed?
112
1131. Machine implementations must not write to the irqdesc array.
114
1152. New functions to manipulate the irqdesc array. The first 4 are expected
116 to be useful only to machine specific code. The last is recommended to
117 only be used by machine specific code, but may be used in drivers if
118 absolutely necessary.
119
120 set_irq_chip(irq,chip)
121
122 Set the mask/unmask methods for handling this IRQ
123
124 set_irq_handler(irq,handler)
125
126 Set the handler for this IRQ (level, edge, simple)
127
128 set_irq_chained_handler(irq,handler)
129
130 Set a "chained" handler for this IRQ - automatically
131 enables this IRQ (eg, Neponset and SA1111 handlers).
132
133 set_irq_flags(irq,flags)
134
135 Set the valid/probe/noautoenable flags.
136
137 set_irq_type(irq,type)
138
139 Set active the IRQ edge(s)/level. This replaces the
140 SA1111 INTPOL manipulation, and the set_GPIO_IRQ_edge()
141 function. Type should be one of the following:
142
143 #define IRQT_NOEDGE (0)
144 #define IRQT_RISING (__IRQT_RISEDGE)
145 #define IRQT_FALLING (__IRQT_FALEDGE)
146 #define IRQT_BOTHEDGE (__IRQT_RISEDGE|__IRQT_FALEDGE)
147 #define IRQT_LOW (__IRQT_LOWLVL)
148 #define IRQT_HIGH (__IRQT_HIGHLVL)
149
1503. set_GPIO_IRQ_edge() is obsolete, and should be replaced by set_irq_type.
151
1524. Direct access to SA1111 INTPOL is depreciated. Use set_irq_type instead.
153
1545. A handler is expected to perform any necessary acknowledgement of the
155 parent IRQ via the correct chip specific function. For instance, if
156 the SA1111 is directly connected to a SA1110 GPIO, then you should
157 acknowledge the SA1110 IRQ each time you re-read the SA1111 IRQ status.
158
1596. For any child which doesn't have its own IRQ enable/disable controls
160 (eg, SMC9196), the handler must mask or acknowledge the parent IRQ
161 while the child handler is called, and the child handler should be the
162 "simple" handler (not "edge" nor "level"). After the handler completes,
163 the parent IRQ should be unmasked, and the status of all children must
164 be re-checked for pending events. (see the Neponset IRQ handler for
165 details).
166
1677. fixup_irq() is gone, as is include/asm-arm/arch-*/irq.h
168
169Please note that this will not solve all problems - some of them are
170hardware based. Mixing level-based and edge-based IRQs on the same
171parent signal (eg neponset) is one such area where a software based
172solution can't provide the full answer to low IRQ latency.
173
diff --git a/Documentation/arm/Netwinder b/Documentation/arm/Netwinder
new file mode 100644
index 000000000000..f1b457fbd3de
--- /dev/null
+++ b/Documentation/arm/Netwinder
@@ -0,0 +1,78 @@
1NetWinder specific documentation
2================================
3
4The NetWinder is a small low-power computer, primarily designed
5to run Linux. It is based around the StrongARM RISC processor,
6DC21285 PCI bridge, with PC-type hardware glued around it.
7
8Port usage
9==========
10
11Min - Max Description
12---------------------------
130x0000 - 0x000f DMA1
140x0020 - 0x0021 PIC1
150x0060 - 0x006f Keyboard
160x0070 - 0x007f RTC
170x0080 - 0x0087 DMA1
180x0088 - 0x008f DMA2
190x00a0 - 0x00a3 PIC2
200x00c0 - 0x00df DMA2
210x0180 - 0x0187 IRDA
220x01f0 - 0x01f6 ide0
230x0201 Game port
240x0203 RWA010 configuration read
250x0220 - ? SoundBlaster
260x0250 - ? WaveArtist
270x0279 RWA010 configuration index
280x02f8 - 0x02ff Serial ttyS1
290x0300 - 0x031f Ether10
300x0338 GPIO1
310x033a GPIO2
320x0370 - 0x0371 W83977F configuration registers
330x0388 - ? AdLib
340x03c0 - 0x03df VGA
350x03f6 ide0
360x03f8 - 0x03ff Serial ttyS0
370x0400 - 0x0408 DC21143
380x0480 - 0x0487 DMA1
390x0488 - 0x048f DMA2
400x0a79 RWA010 configuration write
410xe800 - 0xe80f ide0/ide1 BM DMA
42
43
44Interrupt usage
45===============
46
47IRQ type Description
48---------------------------
49 0 ISA 100Hz timer
50 1 ISA Keyboard
51 2 ISA cascade
52 3 ISA Serial ttyS1
53 4 ISA Serial ttyS0
54 5 ISA PS/2 mouse
55 6 ISA IRDA
56 7 ISA Printer
57 8 ISA RTC alarm
58 9 ISA
5910 ISA GP10 (Orange reset button)
6011 ISA
6112 ISA WaveArtist
6213 ISA
6314 ISA hda1
6415 ISA
65
66DMA usage
67=========
68
69DMA type Description
70---------------------------
71 0 ISA IRDA
72 1 ISA
73 2 ISA cascade
74 3 ISA WaveArtist
75 4 ISA
76 5 ISA
77 6 ISA
78 7 ISA WaveArtist
diff --git a/Documentation/arm/Porting b/Documentation/arm/Porting
new file mode 100644
index 000000000000..a492233931b9
--- /dev/null
+++ b/Documentation/arm/Porting
@@ -0,0 +1,135 @@
1Taken from list archive at http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2001-July/004064.html
2
3Initial definitions
4-------------------
5
6The following symbol definitions rely on you knowing the translation that
7__virt_to_phys() does for your machine. This macro converts the passed
8virtual address to a physical address. Normally, it is simply:
9
10 phys = virt - PAGE_OFFSET + PHYS_OFFSET
11
12
13Decompressor Symbols
14--------------------
15
16ZTEXTADDR
17 Start address of decompressor. There's no point in talking about
18 virtual or physical addresses here, since the MMU will be off at
19 the time when you call the decompressor code. You normally call
20 the kernel at this address to start it booting. This doesn't have
21 to be located in RAM, it can be in flash or other read-only or
22 read-write addressable medium.
23
24ZBSSADDR
25 Start address of zero-initialised work area for the decompressor.
26 This must be pointing at RAM. The decompressor will zero initialise
27 this for you. Again, the MMU will be off.
28
29ZRELADDR
30 This is the address where the decompressed kernel will be written,
31 and eventually executed. The following constraint must be valid:
32
33 __virt_to_phys(TEXTADDR) == ZRELADDR
34
35 The initial part of the kernel is carefully coded to be position
36 independent.
37
38INITRD_PHYS
39 Physical address to place the initial RAM disk. Only relevant if
40 you are using the bootpImage stuff (which only works on the old
41 struct param_struct).
42
43INITRD_VIRT
44 Virtual address of the initial RAM disk. The following constraint
45 must be valid:
46
47 __virt_to_phys(INITRD_VIRT) == INITRD_PHYS
48
49PARAMS_PHYS
50 Physical address of the struct param_struct or tag list, giving the
51 kernel various parameters about its execution environment.
52
53
54Kernel Symbols
55--------------
56
57PHYS_OFFSET
58 Physical start address of the first bank of RAM.
59
60PAGE_OFFSET
61 Virtual start address of the first bank of RAM. During the kernel
62 boot phase, virtual address PAGE_OFFSET will be mapped to physical
63 address PHYS_OFFSET, along with any other mappings you supply.
64 This should be the same value as TASK_SIZE.
65
66TASK_SIZE
67 The maximum size of a user process in bytes. Since user space
68 always starts at zero, this is the maximum address that a user
69 process can access+1. The user space stack grows down from this
70 address.
71
72 Any virtual address below TASK_SIZE is deemed to be user process
73 area, and therefore managed dynamically on a process by process
74 basis by the kernel. I'll call this the user segment.
75
76 Anything above TASK_SIZE is common to all processes. I'll call
77 this the kernel segment.
78
79 (In other words, you can't put IO mappings below TASK_SIZE, and
80 hence PAGE_OFFSET).
81
82TEXTADDR
83 Virtual start address of kernel, normally PAGE_OFFSET + 0x8000.
84 This is where the kernel image ends up. With the latest kernels,
85 it must be located at 32768 bytes into a 128MB region. Previous
86 kernels placed a restriction of 256MB here.
87
88DATAADDR
89 Virtual address for the kernel data segment. Must not be defined
90 when using the decompressor.
91
92VMALLOC_START
93VMALLOC_END
94 Virtual addresses bounding the vmalloc() area. There must not be
95 any static mappings in this area; vmalloc will overwrite them.
96 The addresses must also be in the kernel segment (see above).
97 Normally, the vmalloc() area starts VMALLOC_OFFSET bytes above the
98 last virtual RAM address (found using variable high_memory).
99
100VMALLOC_OFFSET
101 Offset normally incorporated into VMALLOC_START to provide a hole
102 between virtual RAM and the vmalloc area. We do this to allow
103 out of bounds memory accesses (eg, something writing off the end
104 of the mapped memory map) to be caught. Normally set to 8MB.
105
106Architecture Specific Macros
107----------------------------
108
109BOOT_MEM(pram,pio,vio)
110 `pram' specifies the physical start address of RAM. Must always
111 be present, and should be the same as PHYS_OFFSET.
112
113 `pio' is the physical address of an 8MB region containing IO for
114 use with the debugging macros in arch/arm/kernel/debug-armv.S.
115
116 `vio' is the virtual address of the 8MB debugging region.
117
118 It is expected that the debugging region will be re-initialised
119 by the architecture specific code later in the code (via the
120 MAPIO function).
121
122BOOT_PARAMS
123 Same as, and see PARAMS_PHYS.
124
125FIXUP(func)
126 Machine specific fixups, run before memory subsystems have been
127 initialised.
128
129MAPIO(func)
130 Machine specific function to map IO areas (including the debug
131 region above).
132
133INITIRQ(func)
134 Machine specific function to initialise interrupts.
135
diff --git a/Documentation/arm/README b/Documentation/arm/README
new file mode 100644
index 000000000000..a6f718e90a86
--- /dev/null
+++ b/Documentation/arm/README
@@ -0,0 +1,198 @@
1 ARM Linux 2.6
2 =============
3
4 Please check <ftp://ftp.arm.linux.org.uk/pub/armlinux> for
5 updates.
6
7Compilation of kernel
8---------------------
9
10 In order to compile ARM Linux, you will need a compiler capable of
11 generating ARM ELF code with GNU extensions. GCC 2.95.1, EGCS
12 1.1.2, and GCC 3.3 are known to be good compilers. Fortunately, you
13 needn't guess. The kernel will report an error if your compiler is
14 a recognized offender.
15
16 To build ARM Linux natively, you shouldn't have to alter the ARCH = line
17 in the top level Makefile. However, if you don't have the ARM Linux ELF
18 tools installed as default, then you should change the CROSS_COMPILE
19 line as detailed below.
20
21 If you wish to cross-compile, then alter the following lines in the top
22 level make file:
23
24 ARCH = <whatever>
25 with
26 ARCH = arm
27
28 and
29
30 CROSS_COMPILE=
31 to
32 CROSS_COMPILE=<your-path-to-your-compiler-without-gcc>
33 eg.
34 CROSS_COMPILE=arm-linux-
35
36 Do a 'make config', followed by 'make Image' to build the kernel
37 (arch/arm/boot/Image). A compressed image can be built by doing a
38 'make zImage' instead of 'make Image'.
39
40
41Bug reports etc
42---------------
43
44 Please send patches to the patch system. For more information, see
45 http://www.arm.linux.org.uk/patches/info.html Always include some
46 explanation as to what the patch does and why it is needed.
47
48 Bug reports should be sent to linux-arm-kernel@lists.arm.linux.org.uk,
49 or submitted through the web form at
50 http://www.arm.linux.org.uk/forms/solution.shtml
51
52 When sending bug reports, please ensure that they contain all relevant
53 information, eg. the kernel messages that were printed before/during
54 the problem, what you were doing, etc.
55
56
57Include files
58-------------
59
60 Several new include directories have been created under include/asm-arm,
61 which are there to reduce the clutter in the top-level directory. These
62 directories, and their purpose is listed below:
63
64 arch-* machine/platform specific header files
65 hardware driver-internal ARM specific data structures/definitions
66 mach descriptions of generic ARM to specific machine interfaces
67 proc-* processor dependent header files (currently only two
68 categories)
69
70
71Machine/Platform support
72------------------------
73
74 The ARM tree contains support for a lot of different machine types. To
75 continue supporting these differences, it has become necessary to split
76 machine-specific parts by directory. For this, the machine category is
77 used to select which directories and files get included (we will use
78 $(MACHINE) to refer to the category)
79
80 To this end, we now have arch/arm/mach-$(MACHINE) directories which are
81 designed to house the non-driver files for a particular machine (eg, PCI,
82 memory management, architecture definitions etc). For all future
83 machines, there should be a corresponding include/asm-arm/arch-$(MACHINE)
84 directory.
85
86
87Modules
88-------
89
90 Although modularisation is supported (and required for the FP emulator),
91 each module on an ARM2/ARM250/ARM3 machine when is loaded will take
92 memory up to the next 32k boundary due to the size of the pages.
93 Therefore, modularisation on these machines really worth it?
94
95 However, ARM6 and up machines allow modules to take multiples of 4k, and
96 as such Acorn RiscPCs and other architectures using these processors can
97 make good use of modularisation.
98
99
100ADFS Image files
101----------------
102
103 You can access image files on your ADFS partitions by mounting the ADFS
104 partition, and then using the loopback device driver. You must have
105 losetup installed.
106
107 Please note that the PCEmulator DOS partitions have a partition table at
108 the start, and as such, you will have to give '-o offset' to losetup.
109
110
111Request to developers
112---------------------
113
114 When writing device drivers which include a separate assembler file, please
115 include it in with the C file, and not the arch/arm/lib directory. This
116 allows the driver to be compiled as a loadable module without requiring
117 half the code to be compiled into the kernel image.
118
119 In general, try to avoid using assembler unless it is really necessary. It
120 makes drivers far less easy to port to other hardware.
121
122
123ST506 hard drives
124-----------------
125
126 The ST506 hard drive controllers seem to be working fine (if a little
127 slowly). At the moment they will only work off the controllers on an
128 A4x0's motherboard, but for it to work off a Podule just requires
129 someone with a podule to add the addresses for the IRQ mask and the
130 HDC base to the source.
131
132 As of 31/3/96 it works with two drives (you should get the ADFS
133 *configure harddrive set to 2). I've got an internal 20MB and a great
134 big external 5.25" FH 64MB drive (who could ever want more :-) ).
135
136 I've just got 240K/s off it (a dd with bs=128k); thats about half of what
137 RiscOS gets; but it's a heck of a lot better than the 50K/s I was getting
138 last week :-)
139
140 Known bug: Drive data errors can cause a hang; including cases where
141 the controller has fixed the error using ECC. (Possibly ONLY
142 in that case...hmm).
143
144
1451772 Floppy
146-----------
147 This also seems to work OK, but hasn't been stressed much lately. It
148 hasn't got any code for disc change detection in there at the moment which
149 could be a bit of a problem! Suggestions on the correct way to do this
150 are welcome.
151
152
153CONFIG_MACH_ and CONFIG_ARCH_
154-----------------------------
155 A change was made in 2003 to the macro names for new machines.
156 Historically, CONFIG_ARCH_ was used for the bonafide architecture,
157 e.g. SA1100, as well as implementations of the architecture,
158 e.g. Assabet. It was decided to change the implementation macros
159 to read CONFIG_MACH_ for clarity. Moreover, a retroactive fixup has
160 not been made because it would complicate patching.
161
162 Previous registrations may be found online.
163
164 <http://www.arm.linux.org.uk/developer/machines/>
165
166Kernel entry (head.S)
167--------------------------
168 The initial entry into the kernel is via head.S, which uses machine
169 independent code. The machine is selected by the value of 'r1' on
170 entry, which must be kept unique.
171
172 Due to the large number of machines which the ARM port of Linux provides
173 for, we have a method to manage this which ensures that we don't end up
174 duplicating large amounts of code.
175
176 We group machine (or platform) support code into machine classes. A
177 class typically based around one or more system on a chip devices, and
178 acts as a natural container around the actual implementations. These
179 classes are given directories - arch/arm/mach-<class> and
180 include/asm-arm/arch-<class> - which contain the source files to
181 support the machine class. This directories also contain any machine
182 specific supporting code.
183
184 For example, the SA1100 class is based upon the SA1100 and SA1110 SoC
185 devices, and contains the code to support the way the on-board and off-
186 board devices are used, or the device is setup, and provides that
187 machine specific "personality."
188
189 This fine-grained machine specific selection is controlled by the machine
190 type ID, which acts both as a run-time and a compile-time code selection
191 method.
192
193 You can register a new machine via the web site at:
194
195 <http://www.arm.linux.org.uk/developer/machines/>
196
197---
198Russell King (15/03/2004)
diff --git a/Documentation/arm/SA1100/ADSBitsy b/Documentation/arm/SA1100/ADSBitsy
new file mode 100644
index 000000000000..ab47c3833908
--- /dev/null
+++ b/Documentation/arm/SA1100/ADSBitsy
@@ -0,0 +1,43 @@
1ADS Bitsy Single Board Computer
2(It is different from Bitsy(iPAQ) of Compaq)
3
4For more details, contact Applied Data Systems or see
5http://www.applieddata.net/products.html
6
7The Linux support for this product has been provided by
8Woojung Huh <whuh@applieddata.net>
9
10Use 'make adsbitsy_config' before any 'make config'.
11This will set up defaults for ADS Bitsy support.
12
13The kernel zImage is linked to be loaded and executed at 0xc0400000.
14
15Linux can be used with the ADS BootLoader that ships with the
16newer rev boards. See their documentation on how to load Linux.
17
18Supported peripherals:
19- SA1100 LCD frame buffer (8/16bpp...sort of)
20- SA1111 USB Master
21- SA1100 serial port
22- pcmcia, compact flash
23- touchscreen(ucb1200)
24- console on LCD screen
25- serial ports (ttyS[0-2])
26 - ttyS0 is default for serial console
27
28To do:
29- everything else! :-)
30
31Notes:
32
33- The flash on board is divided into 3 partitions.
34 You should be careful to use flash on board.
35 It's partition is different from GraphicsClient Plus and GraphicsMaster
36
37- 16bpp mode requires a different cable than what ships with the board.
38 Contact ADS or look through the manual to wire your own. Currently,
39 if you compile with 16bit mode support and switch into a lower bpp
40 mode, the timing is off so the image is corrupted. This will be
41 fixed soon.
42
43Any contribution can be sent to nico@cam.org and will be greatly welcome!
diff --git a/Documentation/arm/SA1100/Assabet b/Documentation/arm/SA1100/Assabet
new file mode 100644
index 000000000000..cbbe5587c78d
--- /dev/null
+++ b/Documentation/arm/SA1100/Assabet
@@ -0,0 +1,301 @@
1The Intel Assabet (SA-1110 evaluation) board
2============================================
3
4Please see:
5http://developer.intel.com/design/strong/quicklist/eval-plat/sa-1110.htm
6http://developer.intel.com/design/strong/guides/278278.htm
7
8Also some notes from John G Dorsey <jd5q@andrew.cmu.edu>:
9http://www.cs.cmu.edu/~wearable/software/assabet.html
10
11
12Building the kernel
13-------------------
14
15To build the kernel with current defaults:
16
17 make assabet_config
18 make oldconfig
19 make zImage
20
21The resulting kernel image should be available in linux/arch/arm/boot/zImage.
22
23
24Installing a bootloader
25-----------------------
26
27A couple of bootloaders able to boot Linux on Assabet are available:
28
29BLOB (http://www.lart.tudelft.nl/lartware/blob/)
30
31 BLOB is a bootloader used within the LART project. Some contributed
32 patches were merged into BLOB to add support for Assabet.
33
34Compaq's Bootldr + John Dorsey's patch for Assabet support
35(http://www.handhelds.org/Compaq/bootldr.html)
36(http://www.wearablegroup.org/software/bootldr/)
37
38 Bootldr is the bootloader developed by Compaq for the iPAQ Pocket PC.
39 John Dorsey has produced add-on patches to add support for Assabet and
40 the JFFS filesystem.
41
42RedBoot (http://sources.redhat.com/redboot/)
43
44 RedBoot is a bootloader developed by Red Hat based on the eCos RTOS
45 hardware abstraction layer. It supports Assabet amongst many other
46 hardware platforms.
47
48RedBoot is currently the recommended choice since it's the only one to have
49networking support, and is the most actively maintained.
50
51Brief examples on how to boot Linux with RedBoot are shown below. But first
52you need to have RedBoot installed in your flash memory. A known to work
53precompiled RedBoot binary is available from the following location:
54
55ftp://ftp.netwinder.org/users/n/nico/
56ftp://ftp.arm.linux.org.uk/pub/linux/arm/people/nico/
57ftp://ftp.handhelds.org/pub/linux/arm/sa-1100-patches/
58
59Look for redboot-assabet*.tgz. Some installation infos are provided in
60redboot-assabet*.txt.
61
62
63Initial RedBoot configuration
64-----------------------------
65
66The commands used here are explained in The RedBoot User's Guide available
67on-line at http://sources.redhat.com/ecos/docs-latest/redboot/redboot.html.
68Please refer to it for explanations.
69
70If you have a CF network card (my Assabet kit contained a CF+ LP-E from
71Socket Communications Inc.), you should strongly consider using it for TFTP
72file transfers. You must insert it before RedBoot runs since it can't detect
73it dynamically.
74
75To initialize the flash directory:
76
77 fis init -f
78
79To initialize the non-volatile settings, like whether you want to use BOOTP or
80a static IP address, etc, use this command:
81
82 fconfig -i
83
84
85Writing a kernel image into flash
86---------------------------------
87
88First, the kernel image must be loaded into RAM. If you have the zImage file
89available on a TFTP server:
90
91 load zImage -r -b 0x100000
92
93If you rather want to use Y-Modem upload over the serial port:
94
95 load -m ymodem -r -b 0x100000
96
97To write it to flash:
98
99 fis create "Linux kernel" -b 0x100000 -l 0xc0000
100
101
102Booting the kernel
103------------------
104
105The kernel still requires a filesystem to boot. A ramdisk image can be loaded
106as follows:
107
108 load ramdisk_image.gz -r -b 0x800000
109
110Again, Y-Modem upload can be used instead of TFTP by replacing the file name
111by '-y ymodem'.
112
113Now the kernel can be retrieved from flash like this:
114
115 fis load "Linux kernel"
116
117or loaded as described previously. To boot the kernel:
118
119 exec -b 0x100000 -l 0xc0000
120
121The ramdisk image could be stored into flash as well, but there are better
122solutions for on-flash filesystems as mentioned below.
123
124
125Using JFFS2
126-----------
127
128Using JFFS2 (the Second Journalling Flash File System) is probably the most
129convenient way to store a writable filesystem into flash. JFFS2 is used in
130conjunction with the MTD layer which is responsible for low-level flash
131management. More information on the Linux MTD can be found on-line at:
132http://www.linux-mtd.infradead.org/. A JFFS howto with some infos about
133creating JFFS/JFFS2 images is available from the same site.
134
135For instance, a sample JFFS2 image can be retrieved from the same FTP sites
136mentioned below for the precompiled RedBoot image.
137
138To load this file:
139
140 load sample_img.jffs2 -r -b 0x100000
141
142The result should look like:
143
144RedBoot> load sample_img.jffs2 -r -b 0x100000
145Raw file loaded 0x00100000-0x00377424
146
147Now we must know the size of the unallocated flash:
148
149 fis free
150
151Result:
152
153RedBoot> fis free
154 0x500E0000 .. 0x503C0000
155
156The values above may be different depending on the size of the filesystem and
157the type of flash. See their usage below as an example and take care of
158substituting yours appropriately.
159
160We must determine some values:
161
162size of unallocated flash: 0x503c0000 - 0x500e0000 = 0x2e0000
163size of the filesystem image: 0x00377424 - 0x00100000 = 0x277424
164
165We want to fit the filesystem image of course, but we also want to give it all
166the remaining flash space as well. To write it:
167
168 fis unlock -f 0x500E0000 -l 0x2e0000
169 fis erase -f 0x500E0000 -l 0x2e0000
170 fis write -b 0x100000 -l 0x277424 -f 0x500E0000
171 fis create "JFFS2" -n -f 0x500E0000 -l 0x2e0000
172
173Now the filesystem is associated to a MTD "partition" once Linux has discovered
174what they are in the boot process. From Redboot, the 'fis list' command
175displays them:
176
177RedBoot> fis list
178Name FLASH addr Mem addr Length Entry point
179RedBoot 0x50000000 0x50000000 0x00020000 0x00000000
180RedBoot config 0x503C0000 0x503C0000 0x00020000 0x00000000
181FIS directory 0x503E0000 0x503E0000 0x00020000 0x00000000
182Linux kernel 0x50020000 0x00100000 0x000C0000 0x00000000
183JFFS2 0x500E0000 0x500E0000 0x002E0000 0x00000000
184
185However Linux should display something like:
186
187SA1100 flash: probing 32-bit flash bus
188SA1100 flash: Found 2 x16 devices at 0x0 in 32-bit mode
189Using RedBoot partition definition
190Creating 5 MTD partitions on "SA1100 flash":
1910x00000000-0x00020000 : "RedBoot"
1920x00020000-0x000e0000 : "Linux kernel"
1930x000e0000-0x003c0000 : "JFFS2"
1940x003c0000-0x003e0000 : "RedBoot config"
1950x003e0000-0x00400000 : "FIS directory"
196
197What's important here is the position of the partition we are interested in,
198which is the third one. Within Linux, this correspond to /dev/mtdblock2.
199Therefore to boot Linux with the kernel and its root filesystem in flash, we
200need this RedBoot command:
201
202 fis load "Linux kernel"
203 exec -b 0x100000 -l 0xc0000 -c "root=/dev/mtdblock2"
204
205Of course other filesystems than JFFS might be used, like cramfs for example.
206You might want to boot with a root filesystem over NFS, etc. It is also
207possible, and sometimes more convenient, to flash a filesystem directly from
208within Linux while booted from a ramdisk or NFS. The Linux MTD repository has
209many tools to deal with flash memory as well, to erase it for example. JFFS2
210can then be mounted directly on a freshly erased partition and files can be
211copied over directly. Etc...
212
213
214RedBoot scripting
215-----------------
216
217All the commands above aren't so useful if they have to be typed in every
218time the Assabet is rebooted. Therefore it's possible to automatize the boot
219process using RedBoot's scripting capability.
220
221For example, I use this to boot Linux with both the kernel and the ramdisk
222images retrieved from a TFTP server on the network:
223
224RedBoot> fconfig
225Run script at boot: false true
226Boot script:
227Enter script, terminate with empty line
228>> load zImage -r -b 0x100000
229>> load ramdisk_ks.gz -r -b 0x800000
230>> exec -b 0x100000 -l 0xc0000
231>>
232Boot script timeout (1000ms resolution): 3
233Use BOOTP for network configuration: true
234GDB connection port: 9000
235Network debug at boot time: false
236Update RedBoot non-volatile configuration - are you sure (y/n)? y
237
238Then, rebooting the Assabet is just a matter of waiting for the login prompt.
239
240
241
242Nicolas Pitre
243nico@cam.org
244June 12, 2001
245
246
247Status of peripherals in -rmk tree (updated 14/10/2001)
248-------------------------------------------------------
249
250Assabet:
251 Serial ports:
252 Radio: TX, RX, CTS, DSR, DCD, RI
253 PM: Not tested.
254 COM: TX, RX, CTS, DSR, DCD, RTS, DTR, PM
255 PM: Not tested.
256 I2C: Implemented, not fully tested.
257 L3: Fully tested, pass.
258 PM: Not tested.
259
260 Video:
261 LCD: Fully tested. PM
262 (LCD doesn't like being blanked with
263 neponset connected)
264 Video out: Not fully
265
266 Audio:
267 UDA1341:
268 Playback: Fully tested, pass.
269 Record: Implemented, not tested.
270 PM: Not tested.
271
272 UCB1200:
273 Audio play: Implemented, not heavily tested.
274 Audio rec: Implemented, not heavily tested.
275 Telco audio play: Implemented, not heavily tested.
276 Telco audio rec: Implemented, not heavily tested.
277 POTS control: No
278 Touchscreen: Yes
279 PM: Not tested.
280
281 Other:
282 PCMCIA:
283 LPE: Fully tested, pass.
284 USB: No
285 IRDA:
286 SIR: Fully tested, pass.
287 FIR: Fully tested, pass.
288 PM: Not tested.
289
290Neponset:
291 Serial ports:
292 COM1,2: TX, RX, CTS, DSR, DCD, RTS, DTR
293 PM: Not tested.
294 USB: Implemented, not heavily tested.
295 PCMCIA: Implemented, not heavily tested.
296 PM: Not tested.
297 CF: Implemented, not heavily tested.
298 PM: Not tested.
299
300More stuff can be found in the -np (Nicolas Pitre's) tree.
301
diff --git a/Documentation/arm/SA1100/Brutus b/Documentation/arm/SA1100/Brutus
new file mode 100644
index 000000000000..2254c8f0b326
--- /dev/null
+++ b/Documentation/arm/SA1100/Brutus
@@ -0,0 +1,66 @@
1Brutus is an evaluation platform for the SA1100 manufactured by Intel.
2For more details, see:
3
4http://developer.intel.com/design/strong/applnots/sa1100lx/getstart.htm
5
6To compile for Brutus, you must issue the following commands:
7
8 make brutus_config
9 make config
10 [accept all the defaults]
11 make zImage
12
13The resulting kernel will end up in linux/arch/arm/boot/zImage. This file
14must be loaded at 0xc0008000 in Brutus's memory and execution started at
150xc0008000 as well with the value of registers r0 = 0 and r1 = 16 upon
16entry.
17
18But prior to execute the kernel, a ramdisk image must also be loaded in
19memory. Use memory address 0xd8000000 for this. Note that the file
20containing the (compressed) ramdisk image must not exceed 4 MB.
21
22Typically, you'll need angelboot to load the kernel.
23The following angelboot.opt file should be used:
24
25----- begin angelboot.opt -----
26base 0xc0008000
27entry 0xc0008000
28r0 0x00000000
29r1 0x00000010
30device /dev/ttyS0
31options "9600 8N1"
32baud 115200
33otherfile ramdisk_img.gz
34otherbase 0xd8000000
35----- end angelboot.opt -----
36
37Then load the kernel and ramdisk with:
38
39 angelboot -f angelboot.opt zImage
40
41The first Brutus serial port (assumed to be linked to /dev/ttyS0 on your
42host PC) is used by angel to load the kernel and ramdisk image. The serial
43console is provided through the second Brutus serial port. To access it,
44you may use minicom configured with /dev/ttyS1, 9600 baud, 8N1, no flow
45control.
46
47Currently supported:
48 - RS232 serial ports
49 - audio output
50 - LCD screen
51 - keyboard
52
53The actual Brutus support may not be complete without extra patches.
54If such patches exist, they should be found from
55ftp.netwinder.org/users/n/nico.
56
57A full PCMCIA support is still missing, although it's possible to hack
58some drivers in order to drive already inserted cards at boot time with
59little modifications.
60
61Any contribution is welcome.
62
63Please send patches to nico@cam.org
64
65Have Fun !
66
diff --git a/Documentation/arm/SA1100/CERF b/Documentation/arm/SA1100/CERF
new file mode 100644
index 000000000000..b3d845301ef1
--- /dev/null
+++ b/Documentation/arm/SA1100/CERF
@@ -0,0 +1,29 @@
1*** The StrongARM version of the CerfBoard/Cube has been discontinued ***
2
3The Intrinsyc CerfBoard is a StrongARM 1110-based computer on a board
4that measures approximately 2" square. It includes an Ethernet
5controller, an RS232-compatible serial port, a USB function port, and
6one CompactFlash+ slot on the back. Pictures can be found at the
7Intrinsyc website, http://www.intrinsyc.com.
8
9This document describes the support in the Linux kernel for the
10Intrinsyc CerfBoard.
11
12Supported in this version:
13 - CompactFlash+ slot (select PCMCIA in General Setup and any options
14 that may be required)
15 - Onboard Crystal CS8900 Ethernet controller (Cerf CS8900A support in
16 Network Devices)
17 - Serial ports with a serial console (hardcoded to 38400 8N1)
18
19In order to get this kernel onto your Cerf, you need a server that runs
20both BOOTP and TFTP. Detailed instructions should have come with your
21evaluation kit on how to use the bootloader. This series of commands
22will suffice:
23
24 make ARCH=arm CROSS_COMPILE=arm-linux- cerfcube_defconfig
25 make ARCH=arm CROSS_COMPILE=arm-linux- zImage
26 make ARCH=arm CROSS_COMPILE=arm-linux- modules
27 cp arch/arm/boot/zImage <TFTP directory>
28
29support@intrinsyc.com
diff --git a/Documentation/arm/SA1100/FreeBird b/Documentation/arm/SA1100/FreeBird
new file mode 100644
index 000000000000..eda28b3232e7
--- /dev/null
+++ b/Documentation/arm/SA1100/FreeBird
@@ -0,0 +1,21 @@
1Freebird-1.1 is produced by Legned(C) ,Inc.
2(http://www.legend.com.cn)
3and software/linux mainatined by Coventive(C),Inc.
4(http://www.coventive.com)
5
6Based on the Nicolas's strongarm kernel tree.
7
8===============================================================
9Maintainer:
10
11Chester Kuo <chester@coventive.com>
12 <chester@linux.org.tw>
13
14Author :
15Tim wu <timwu@coventive.com>
16CIH <cih@coventive.com>
17Eric Peng <ericpeng@coventive.com>
18Jeff Lee <jeff_lee@coventive.com>
19Allen Cheng
20Tony Liu <tonyliu@coventive.com>
21
diff --git a/Documentation/arm/SA1100/GraphicsClient b/Documentation/arm/SA1100/GraphicsClient
new file mode 100644
index 000000000000..8fa7e8027ff1
--- /dev/null
+++ b/Documentation/arm/SA1100/GraphicsClient
@@ -0,0 +1,98 @@
1ADS GraphicsClient Plus Single Board Computer
2
3For more details, contact Applied Data Systems or see
4http://www.applieddata.net/products.html
5
6The original Linux support for this product has been provided by
7Nicolas Pitre <nico@cam.org>. Continued development work by
8Woojung Huh <whuh@applieddata.net>
9
10It's currently possible to mount a root filesystem via NFS providing a
11complete Linux environment. Otherwise a ramdisk image may be used. The
12board supports MTD/JFFS, so you could also mount something on there.
13
14Use 'make graphicsclient_config' before any 'make config'. This will set up
15defaults for GraphicsClient Plus support.
16
17The kernel zImage is linked to be loaded and executed at 0xc0200000.
18Also the following registers should have the specified values upon entry:
19
20 r0 = 0
21 r1 = 29 (this is the GraphicsClient architecture number)
22
23Linux can be used with the ADS BootLoader that ships with the
24newer rev boards. See their documentation on how to load Linux.
25Angel is not available for the GraphicsClient Plus AFAIK.
26
27There is a board known as just the GraphicsClient that ADS used to
28produce but has end of lifed. This code will not work on the older
29board with the ADS bootloader, but should still work with Angel,
30as outlined below. In any case, if you're planning on deploying
31something en masse, you should probably get the newer board.
32
33If using Angel on the older boards, here is a typical angel.opt option file
34if the kernel is loaded through the Angel Debug Monitor:
35
36----- begin angelboot.opt -----
37base 0xc0200000
38entry 0xc0200000
39r0 0x00000000
40r1 0x0000001d
41device /dev/ttyS1
42options "38400 8N1"
43baud 115200
44#otherfile ramdisk.gz
45#otherbase 0xc0800000
46exec minicom
47----- end angelboot.opt -----
48
49Then the kernel (and ramdisk if otherfile/otherbase lines above are
50uncommented) would be loaded with:
51
52 angelboot -f angelboot.opt zImage
53
54Here it is assumed that the board is connected to ttyS1 on your PC
55and that minicom is preconfigured with /dev/ttyS1, 38400 baud, 8N1, no flow
56control by default.
57
58If any other bootloader is used, ensure it accomplish the same, especially
59for r0/r1 register values before jumping into the kernel.
60
61
62Supported peripherals:
63- SA1100 LCD frame buffer (8/16bpp...sort of)
64- on-board SMC 92C96 ethernet NIC
65- SA1100 serial port
66- flash memory access (MTD/JFFS)
67- pcmcia
68- touchscreen(ucb1200)
69- ps/2 keyboard
70- console on LCD screen
71- serial ports (ttyS[0-2])
72 - ttyS0 is default for serial console
73- Smart I/O (ADC, keypad, digital inputs, etc)
74 See http://www.applieddata.com/developers/linux for IOCTL documentation
75 and example user space code. ps/2 keybd is multiplexed through this driver
76
77To do:
78- UCB1200 audio with new ucb_generic layer
79- everything else! :-)
80
81Notes:
82
83- The flash on board is divided into 3 partitions. mtd0 is where
84 the ADS boot ROM and zImage is stored. It's been marked as
85 read-only to keep you from blasting over the bootloader. :) mtd1 is
86 for the ramdisk.gz image. mtd2 is user flash space and can be
87 utilized for either JFFS or if you're feeling crazy, running ext2
88 on top of it. If you're not using the ADS bootloader, you're
89 welcome to blast over the mtd1 partition also.
90
91- 16bpp mode requires a different cable than what ships with the board.
92 Contact ADS or look through the manual to wire your own. Currently,
93 if you compile with 16bit mode support and switch into a lower bpp
94 mode, the timing is off so the image is corrupted. This will be
95 fixed soon.
96
97Any contribution can be sent to nico@cam.org and will be greatly welcome!
98
diff --git a/Documentation/arm/SA1100/GraphicsMaster b/Documentation/arm/SA1100/GraphicsMaster
new file mode 100644
index 000000000000..dd28745ac521
--- /dev/null
+++ b/Documentation/arm/SA1100/GraphicsMaster
@@ -0,0 +1,53 @@
1ADS GraphicsMaster Single Board Computer
2
3For more details, contact Applied Data Systems or see
4http://www.applieddata.net/products.html
5
6The original Linux support for this product has been provided by
7Nicolas Pitre <nico@cam.org>. Continued development work by
8Woojung Huh <whuh@applieddata.net>
9
10Use 'make graphicsmaster_config' before any 'make config'.
11This will set up defaults for GraphicsMaster support.
12
13The kernel zImage is linked to be loaded and executed at 0xc0400000.
14
15Linux can be used with the ADS BootLoader that ships with the
16newer rev boards. See their documentation on how to load Linux.
17
18Supported peripherals:
19- SA1100 LCD frame buffer (8/16bpp...sort of)
20- SA1111 USB Master
21- on-board SMC 92C96 ethernet NIC
22- SA1100 serial port
23- flash memory access (MTD/JFFS)
24- pcmcia, compact flash
25- touchscreen(ucb1200)
26- ps/2 keyboard
27- console on LCD screen
28- serial ports (ttyS[0-2])
29 - ttyS0 is default for serial console
30- Smart I/O (ADC, keypad, digital inputs, etc)
31 See http://www.applieddata.com/developers/linux for IOCTL documentation
32 and example user space code. ps/2 keybd is multiplexed through this driver
33
34To do:
35- everything else! :-)
36
37Notes:
38
39- The flash on board is divided into 3 partitions. mtd0 is where
40 the zImage is stored. It's been marked as read-only to keep you
41 from blasting over the bootloader. :) mtd1 is
42 for the ramdisk.gz image. mtd2 is user flash space and can be
43 utilized for either JFFS or if you're feeling crazy, running ext2
44 on top of it. If you're not using the ADS bootloader, you're
45 welcome to blast over the mtd1 partition also.
46
47- 16bpp mode requires a different cable than what ships with the board.
48 Contact ADS or look through the manual to wire your own. Currently,
49 if you compile with 16bit mode support and switch into a lower bpp
50 mode, the timing is off so the image is corrupted. This will be
51 fixed soon.
52
53Any contribution can be sent to nico@cam.org and will be greatly welcome!
diff --git a/Documentation/arm/SA1100/HUW_WEBPANEL b/Documentation/arm/SA1100/HUW_WEBPANEL
new file mode 100644
index 000000000000..fd56b48d4833
--- /dev/null
+++ b/Documentation/arm/SA1100/HUW_WEBPANEL
@@ -0,0 +1,17 @@
1The HUW_WEBPANEL is a product of the german company Hoeft & Wessel AG
2
3If you want more information, please visit
4http://www.hoeft-wessel.de
5
6To build the kernel:
7 make huw_webpanel_config
8 make oldconfig
9 [accept all defaults]
10 make zImage
11
12Mostly of the work is done by:
13Roman Jordan jor@hoeft-wessel.de
14Christoph Schulz schu@hoeft-wessel.de
15
162000/12/18/
17
diff --git a/Documentation/arm/SA1100/Itsy b/Documentation/arm/SA1100/Itsy
new file mode 100644
index 000000000000..3b594534323b
--- /dev/null
+++ b/Documentation/arm/SA1100/Itsy
@@ -0,0 +1,39 @@
1Itsy is a research project done by the Western Research Lab, and Systems
2Research Center in Palo Alto, CA. The Itsy project is one of several
3research projects at Compaq that are related to pocket computing.
4
5For more information, see:
6
7 http://www.research.digital.com/wrl/itsy/index.html
8
9Notes on initial 2.4 Itsy support (8/27/2000) :
10The port was done on an Itsy version 1.5 machine with a daughtercard with
1164 Meg of DRAM and 32 Meg of Flash. The initial work includes support for
12serial console (to see what you're doing). No other devices have been
13enabled.
14
15To build, do a "make menuconfig" (or xmenuconfig) and select Itsy support.
16Disable Flash and LCD support. and then do a make zImage.
17Finally, you will need to cd to arch/arm/boot/tools and execute a make there
18to build the params-itsy program used to boot the kernel.
19
20In order to install the port of 2.4 to the itsy, You will need to set the
21configuration parameters in the monitor as follows:
22Arg 1:0x08340000, Arg2: 0xC0000000, Arg3:18 (0x12), Arg4:0
23Make sure the start-routine address is set to 0x00060000.
24
25Next, flash the params-itsy program to 0x00060000 ("p 1 0x00060000" in the
26flash menu) Flash the kernel in arch/arm/boot/zImage into 0x08340000
27("p 1 0x00340000"). Finally flash an initial ramdisk into 0xC8000000
28("p 2 0x0") We used ramdisk-2-30.gz from the 0.11 version directory on
29handhelds.org.
30
31The serial connection we established was at:
32 8-bit data, no parity, 1 stop bit(s), 115200.00 b/s. in the monitor, in the
33params-itsy program, and in the kernel itself. This can be changed, but
34not easily. The monitor parameters are easily changed, the params program
35setup is assembly outl's, and the kernel is a configuration item specific to
36the itsy. (i.e. grep for CONFIG_SA1100_ITSY and you'll find where it is.)
37
38
39This should get you a properly booting 2.4 kernel on the itsy.
diff --git a/Documentation/arm/SA1100/LART b/Documentation/arm/SA1100/LART
new file mode 100644
index 000000000000..2f73f513e16a
--- /dev/null
+++ b/Documentation/arm/SA1100/LART
@@ -0,0 +1,14 @@
1Linux Advanced Radio Terminal (LART)
2------------------------------------
3
4The LART is a small (7.5 x 10cm) SA-1100 board, designed for embedded
5applications. It has 32 MB DRAM, 4MB Flash ROM, double RS232 and all
6other StrongARM-gadgets. Almost all SA signals are directly accessible
7through a number of connectors. The powersupply accepts voltages
8between 3.5V and 16V and is overdimensioned to support a range of
9daughterboards. A quad Ethernet / IDE / PS2 / sound daughterboard
10is under development, with plenty of others in different stages of
11planning.
12
13The hardware designs for this board have been released under an open license;
14see the LART page at http://www.lart.tudelft.nl/ for more information.
diff --git a/Documentation/arm/SA1100/PLEB b/Documentation/arm/SA1100/PLEB
new file mode 100644
index 000000000000..92cae066908d
--- /dev/null
+++ b/Documentation/arm/SA1100/PLEB
@@ -0,0 +1,11 @@
1The PLEB project was started as a student initiative at the School of
2Computer Science and Engineering, University of New South Wales to make a
3pocket computer capable of running the Linux Kernel.
4
5PLEB support has yet to be fully integrated.
6
7For more information, see:
8
9 http://www.cse.unsw.edu.au/~pleb/
10
11
diff --git a/Documentation/arm/SA1100/Pangolin b/Documentation/arm/SA1100/Pangolin
new file mode 100644
index 000000000000..077a6120e129
--- /dev/null
+++ b/Documentation/arm/SA1100/Pangolin
@@ -0,0 +1,23 @@
1Pangolin is a StrongARM 1110-based evaluation platform produced
2by Dialogue Technology (http://www.dialogue.com.tw/).
3It has EISA slots for ease of configuration with SDRAM/Flash
4memory card, USB/Serial/Audio card, Compact Flash card,
5PCMCIA/IDE card and TFT-LCD card.
6
7To compile for Pangolin, you must issue the following commands:
8
9 make pangolin_config
10 make oldconfig
11 make zImage
12
13Supported peripherals:
14- SA1110 serial port (UART1/UART2/UART3)
15- flash memory access
16- compact flash driver
17- UDA1341 sound driver
18- SA1100 LCD controller for 800x600 16bpp TFT-LCD
19- MQ-200 driver for 800x600 16bpp TFT-LCD
20- Penmount(touch panel) driver
21- PCMCIA driver
22- SMC91C94 LAN driver
23- IDE driver (experimental)
diff --git a/Documentation/arm/SA1100/Tifon b/Documentation/arm/SA1100/Tifon
new file mode 100644
index 000000000000..dd1934d9c851
--- /dev/null
+++ b/Documentation/arm/SA1100/Tifon
@@ -0,0 +1,7 @@
1Tifon
2-----
3
4More info has to come...
5
6Contact: Peter Danielsson <peter.danielsson@era-t.ericsson.se>
7
diff --git a/Documentation/arm/SA1100/Victor b/Documentation/arm/SA1100/Victor
new file mode 100644
index 000000000000..01e81fc49461
--- /dev/null
+++ b/Documentation/arm/SA1100/Victor
@@ -0,0 +1,16 @@
1Victor is known as a "digital talking book player" manufactured by
2VisuAide, Inc. to be used by blind people.
3
4For more information related to Victor, see:
5
6 http://www.visuaide.com/victor
7
8Of course Victor is using Linux as its main operating system.
9The Victor implementation for Linux is maintained by Nicolas Pitre:
10
11 nico@visuaide.com
12 nico@cam.org
13
14For any comments, please feel free to contact me through the above
15addresses.
16
diff --git a/Documentation/arm/SA1100/Yopy b/Documentation/arm/SA1100/Yopy
new file mode 100644
index 000000000000..e14f16d836ac
--- /dev/null
+++ b/Documentation/arm/SA1100/Yopy
@@ -0,0 +1,2 @@
1See http://www.yopydeveloper.org for more.
2
diff --git a/Documentation/arm/SA1100/empeg b/Documentation/arm/SA1100/empeg
new file mode 100644
index 000000000000..4ece4849a42c
--- /dev/null
+++ b/Documentation/arm/SA1100/empeg
@@ -0,0 +1,2 @@
1See ../empeg/README
2
diff --git a/Documentation/arm/SA1100/nanoEngine b/Documentation/arm/SA1100/nanoEngine
new file mode 100644
index 000000000000..fc431cbfefc2
--- /dev/null
+++ b/Documentation/arm/SA1100/nanoEngine
@@ -0,0 +1,11 @@
1nanoEngine
2----------
3
4"nanoEngine" is a SA1110 based single board computer from
5Bright Star Engineering Inc. See www.brightstareng.com/arm
6for more info.
7(Ref: Stuart Adams <sja@brightstareng.com>)
8
9Also visit Larry Doolittle's "Linux for the nanoEngine" site:
10http://recycle.lbl.gov/~ldoolitt/bse/
11
diff --git a/Documentation/arm/SA1100/serial_UART b/Documentation/arm/SA1100/serial_UART
new file mode 100644
index 000000000000..aea2e91ca0ef
--- /dev/null
+++ b/Documentation/arm/SA1100/serial_UART
@@ -0,0 +1,47 @@
1The SA1100 serial port had its major/minor numbers officially assigned:
2
3> Date: Sun, 24 Sep 2000 21:40:27 -0700
4> From: H. Peter Anvin <hpa@transmeta.com>
5> To: Nicolas Pitre <nico@CAM.ORG>
6> Cc: Device List Maintainer <device@lanana.org>
7> Subject: Re: device
8>
9> Okay. Note that device numbers 204 and 205 are used for "low density
10> serial devices", so you will have a range of minors on those majors (the
11> tty device layer handles this just fine, so you don't have to worry about
12> doing anything special.)
13>
14> So your assignments are:
15>
16> 204 char Low-density serial ports
17> 5 = /dev/ttySA0 SA1100 builtin serial port 0
18> 6 = /dev/ttySA1 SA1100 builtin serial port 1
19> 7 = /dev/ttySA2 SA1100 builtin serial port 2
20>
21> 205 char Low-density serial ports (alternate device)
22> 5 = /dev/cusa0 Callout device for ttySA0
23> 6 = /dev/cusa1 Callout device for ttySA1
24> 7 = /dev/cusa2 Callout device for ttySA2
25>
26
27If you're not using devfs, you must create those inodes in /dev
28on the root filesystem used by your SA1100-based device:
29
30 mknod ttySA0 c 204 5
31 mknod ttySA1 c 204 6
32 mknod ttySA2 c 204 7
33 mknod cusa0 c 205 5
34 mknod cusa1 c 205 6
35 mknod cusa2 c 205 7
36
37In addition to the creation of the appropriate device nodes above, you
38must ensure your user space applications make use of the correct device
39name. The classic example is the content of the /etc/inittab file where
40you might have a getty process started on ttyS0. In this case:
41
42- replace occurrences of ttyS0 with ttySA0, ttyS1 with ttySA1, etc.
43
44- don't forget to add 'ttySA0', 'console', or the appropriate tty name
45 in /etc/securetty for root to be allowed to login as well.
46
47
diff --git a/Documentation/arm/Samsung-S3C24XX/EB2410ITX.txt b/Documentation/arm/Samsung-S3C24XX/EB2410ITX.txt
new file mode 100644
index 000000000000..000e3d7a78b2
--- /dev/null
+++ b/Documentation/arm/Samsung-S3C24XX/EB2410ITX.txt
@@ -0,0 +1,58 @@
1 Simtec Electronics EB2410ITX (BAST)
2 ===================================
3
4 http://www.simtec.co.uk/products/EB2410ITX/
5
6Introduction
7------------
8
9 The EB2410ITX is a S3C2410 based development board with a variety of
10 peripherals and expansion connectors. This board is also known by
11 the shortened name of Bast.
12
13
14Configuration
15-------------
16
17 To set the default configuration, use `make bast_defconfig` which
18 supports the commonly used features of this board.
19
20
21Support
22-------
23
24 Official support information can be found on the Simtec Electronics
25 website, at the product page http://www.simtec.co.uk/products/EB2410ITX/
26
27 Useful links:
28
29 - Resources Page http://www.simtec.co.uk/products/EB2410ITX/resources.html
30
31 - Board FAQ at http://www.simtec.co.uk/products/EB2410ITX/faq.html
32
33 - Bootloader info http://www.simtec.co.uk/products/SWABLE/resources.html
34 and FAQ http://www.simtec.co.uk/products/SWABLE/faq.html
35
36
37MTD
38---
39
40 The NAND and NOR support has been merged from the linux-mtd project.
41 Any prolbems, see http://www.linux-mtd.infradead.org/ for more
42 information or up-to-date versions of linux-mtd.
43
44
45IDE
46---
47
48 Both onboard IDE ports are supported, however there is no support for
49 changing speed of devices, PIO Mode 4 capable drives should be used.
50
51
52Maintainers
53-----------
54
55 This board is maintained by Simtec Electronics.
56
57
58(c) 2004 Ben Dooks, Simtec Electronics
diff --git a/Documentation/arm/Samsung-S3C24XX/GPIO.txt b/Documentation/arm/Samsung-S3C24XX/GPIO.txt
new file mode 100644
index 000000000000..0822764ec270
--- /dev/null
+++ b/Documentation/arm/Samsung-S3C24XX/GPIO.txt
@@ -0,0 +1,122 @@
1 S3C2410 GPIO Control
2 ====================
3
4Introduction
5------------
6
7 The s3c2410 kernel provides an interface to configure and
8 manipulate the state of the GPIO pins, and find out other
9 information about them.
10
11 There are a number of conditions attached to the configuration
12 of the s3c2410 GPIO system, please read the Samsung provided
13 data-sheet/users manual to find out the complete list.
14
15
16Headers
17-------
18
19 See include/asm-arm/arch-s3c2410/regs-gpio.h for the list
20 of GPIO pins, and the configuration values for them. This
21 is included by using #include <asm/arch/regs-gpio.h>
22
23 The GPIO management functions are defined in the hardware
24 header include/asm-arm/arch-s3c2410/hardware.h which can be
25 included by #include <asm/arch/hardware.h>
26
27 A useful ammount of documentation can be found in the hardware
28 header on how the GPIO functions (and others) work.
29
30 Whilst a number of these functions do make some checks on what
31 is passed to them, for speed of use, they may not always ensure
32 that the user supplied data to them is correct.
33
34
35PIN Numbers
36-----------
37
38 Each pin has an unique number associated with it in regs-gpio.h,
39 eg S3C2410_GPA0 or S3C2410_GPF1. These defines are used to tell
40 the GPIO functions which pin is to be used.
41
42
43Configuring a pin
44-----------------
45
46 The following function allows the configuration of a given pin to
47 be changed.
48
49 void s3c2410_gpio_cfgpin(unsigned int pin, unsigned int function);
50
51 Eg:
52
53 s3c2410_gpio_cfgpin(S3C2410_GPA0, S3C2410_GPA0_ADDR0);
54 s3c2410_gpio_cfgpin(S3C2410_GPE8, S3C2410_GPE8_SDDAT1);
55
56 which would turn GPA0 into the lowest Address line A0, and set
57 GPE8 to be connected to the SDIO/MMC controller's SDDAT1 line.
58
59
60Reading the current configuration
61---------------------------------
62
63 The current configuration of a pin can be read by using:
64
65 s3c2410_gpio_getcfg(unsigned int pin);
66
67 The return value will be from the same set of values which can be
68 passed to s3c2410_gpio_cfgpin().
69
70
71Configuring a pull-up resistor
72------------------------------
73
74 A large proportion of the GPIO pins on the S3C2410 can have weak
75 pull-up resistors enabled. This can be configured by the following
76 function:
77
78 void s3c2410_gpio_pullup(unsigned int pin, unsigned int to);
79
80 Where the to value is zero to set the pull-up off, and 1 to enable
81 the specified pull-up. Any other values are currently undefined.
82
83
84Getting the state of a PIN
85--------------------------
86
87 The state of a pin can be read by using the function:
88
89 unsigned int s3c2410_gpio_getpin(unsigned int pin);
90
91 This will return either zero or non-zero. Do not count on this
92 function returning 1 if the pin is set.
93
94
95Setting the state of a PIN
96--------------------------
97
98 The value an pin is outputing can be modified by using the following:
99
100 void s3c2410_gpio_setpin(unsigned int pin, unsigned int to);
101
102 Which sets the given pin to the value. Use 0 to write 0, and 1 to
103 set the output to 1.
104
105
106Getting the IRQ number associated with a PIN
107--------------------------------------------
108
109 The following function can map the given pin number to an IRQ
110 number to pass to the IRQ system.
111
112 int s3c2410_gpio_getirq(unsigned int pin);
113
114 Note, not all pins have an IRQ.
115
116
117Authour
118-------
119
120
121Ben Dooks, 03 October 2004
122(c) 2004 Ben Dooks, Simtec Electronics
diff --git a/Documentation/arm/Samsung-S3C24XX/H1940.txt b/Documentation/arm/Samsung-S3C24XX/H1940.txt
new file mode 100644
index 000000000000..d6b1de92b111
--- /dev/null
+++ b/Documentation/arm/Samsung-S3C24XX/H1940.txt
@@ -0,0 +1,40 @@
1 HP IPAQ H1940
2 =============
3
4http://www.handhelds.org/projects/h1940.html
5
6Introduction
7------------
8
9 The HP H1940 is a S3C2410 based handheld device, with
10 bluetooth connectivity.
11
12
13Support
14-------
15
16 A variety of information is available
17
18 handhelds.org project page:
19
20 http://www.handhelds.org/projects/h1940.html
21
22 handhelds.org wiki page:
23
24 http://handhelds.org/moin/moin.cgi/HpIpaqH1940
25
26 Herbert Pötzl pages:
27
28 http://vserver.13thfloor.at/H1940/
29
30
31Maintainers
32-----------
33
34 This project is being maintained and developed by a variety
35 of people, including Ben Dooks, Arnaud Patard, and Herbert Pötzl.
36
37 Thanks to the many others who have also provided support.
38
39
40(c) 2005 Ben Dooks \ No newline at end of file
diff --git a/Documentation/arm/Samsung-S3C24XX/Overview.txt b/Documentation/arm/Samsung-S3C24XX/Overview.txt
new file mode 100644
index 000000000000..3af4d29a8938
--- /dev/null
+++ b/Documentation/arm/Samsung-S3C24XX/Overview.txt
@@ -0,0 +1,156 @@
1 S3C24XX ARM Linux Overview
2 ==========================
3
4
5
6Introduction
7------------
8
9 The Samsung S3C24XX range of ARM9 System-on-Chip CPUs are supported
10 by the 's3c2410' architecture of ARM Linux. Currently the S3C2410 and
11 the S3C2440 are supported CPUs.
12
13
14Configuration
15-------------
16
17 A generic S3C2410 configuration is provided, and can be used as the
18 default by `make s3c2410_defconfig`. This configuration has support
19 for all the machines, and the commonly used features on them.
20
21 Certain machines may have their own default configurations as well,
22 please check the machine specific documentation.
23
24
25Machines
26--------
27
28 The currently supported machines are as follows:
29
30 Simtec Electronics EB2410ITX (BAST)
31
32 A general purpose development board, see EB2410ITX.txt for further
33 details
34
35 Samsung SMDK2410
36
37 Samsung's own development board, geared for PDA work.
38
39 Samsung/Meritech SMDK2440
40
41 The S3C2440 compatible version of the SMDK2440
42
43 Thorcom VR1000
44
45 Custom embedded board
46
47 HP IPAQ 1940
48
49 Handheld (IPAQ), available in several varieties
50
51 HP iPAQ rx3715
52
53 S3C2440 based IPAQ, with a number of variations depending on
54 features shipped.
55
56 Acer N30
57
58 A S3C2410 based PDA from Acer. There is a Wiki page at
59 http://handhelds.org/moin/moin.cgi/AcerN30Documentation .
60
61
62Adding New Machines
63-------------------
64
65 The archicture has been designed to support as many machines as can
66 be configured for it in one kernel build, and any future additions
67 should keep this in mind before altering items outside of their own
68 machine files.
69
70 Machine definitions should be kept in linux/arch/arm/mach-s3c2410,
71 and there are a number of examples that can be looked at.
72
73 Read the kernel patch submission policies as well as the
74 Documentation/arm directory before submitting patches. The
75 ARM kernel series is managed by Russell King, and has a patch system
76 located at http://www.arm.linux.org.uk/developer/patches/
77 as well as mailing lists that can be found from the same site.
78
79 As a courtesy, please notify <ben-linux@fluff.org> of any new
80 machines or other modifications.
81
82 Any large scale modifications, or new drivers should be discussed
83 on the ARM kernel mailing list (linux-arm-kernel) before being
84 attempted.
85
86
87NAND
88----
89
90 The current kernels now have support for the s3c2410 NAND
91 controller. If there are any problems the latest linux-mtd
92 CVS can be found from http://www.linux-mtd.infradead.org/
93
94
95Serial
96------
97
98 The s3c2410 serial driver provides support for the internal
99 serial ports. These devices appear as /dev/ttySAC0 through 3.
100
101 To create device nodes for these, use the following commands
102
103 mknod ttySAC0 c 204 64
104 mknod ttySAC1 c 204 65
105 mknod ttySAC2 c 204 66
106
107
108GPIO
109----
110
111 The core contains support for manipulating the GPIO, see the
112 documentation in GPIO.txt in the same directory as this file.
113
114
115Clock Management
116----------------
117
118 The core provides the interface defined in the header file
119 include/asm-arm/hardware/clock.h, to allow control over the
120 various clock units
121
122
123Port Contributors
124-----------------
125
126 Ben Dooks (BJD)
127 Vincent Sanders
128 Herbert Potzl
129 Arnaud Patard (RTP)
130 Roc Wu
131 Klaus Fetscher
132 Dimitry Andric
133 Shannon Holland
134 Guillaume Gourat (NexVision)
135 Christer Weinigel (wingel) (Acer N30)
136 Lucas Correia Villa Real (S3C2400 port)
137
138
139Document Changes
140----------------
141
142 05 Sep 2004 - BJD - Added Document Changes section
143 05 Sep 2004 - BJD - Added Klaus Fetscher to list of contributors
144 25 Oct 2004 - BJD - Added Dimitry Andric to list of contributors
145 25 Oct 2004 - BJD - Updated the MTD from the 2.6.9 merge
146 21 Jan 2005 - BJD - Added rx3715, added Shannon to contributors
147 10 Feb 2005 - BJD - Added Guillaume Gourat to contributors
148 02 Mar 2005 - BJD - Added SMDK2440 to list of machines
149 06 Mar 2005 - BJD - Added Christer Weinigel
150 08 Mar 2005 - BJD - Added LCVR to list of people, updated introduction
151 08 Mar 2005 - BJD - Added section on adding machines
152
153Document Author
154---------------
155
156Ben Dooks, (c) 2004-2005 Simtec Electronics
diff --git a/Documentation/arm/Samsung-S3C24XX/SMDK2440.txt b/Documentation/arm/Samsung-S3C24XX/SMDK2440.txt
new file mode 100644
index 000000000000..32e1eae6a25f
--- /dev/null
+++ b/Documentation/arm/Samsung-S3C24XX/SMDK2440.txt
@@ -0,0 +1,56 @@
1 Samsung/Meritech SMDK2440
2 =========================
3
4Introduction
5------------
6
7 The SMDK2440 is a two part evaluation board for the Samsung S3C2440
8 processor. It includes support for LCD, SmartMedia, Audio, SD and
9 10MBit Ethernet, and expansion headers for various signals, including
10 the camera and unused GPIO.
11
12
13Configuration
14-------------
15
16 To set the default configuration, use `make smdk2440_defconfig` which
17 will configure the common features of this board, or use
18 `make s3c2410_config` to include support for all s3c2410/s3c2440 machines
19
20
21Support
22-------
23
24 Ben Dooks' SMDK2440 site at http://www.fluff.org/ben/smdk2440/ which
25 includes linux based USB download tools.
26
27 Some of the h1940 patches that can be found from the H1940 project
28 site at http://www.handhelds.org/projects/h1940.html can also be
29 applied to this board.
30
31
32Peripherals
33-----------
34
35 There is no current support for any of the extra peripherals on the
36 base-board itself.
37
38
39MTD
40---
41
42 The NAND flash should be supported by the in kernel MTD NAND support,
43 NOR flash will be added later.
44
45
46Maintainers
47-----------
48
49 This board is being maintained by Ben Dooks, for more info, see
50 http://www.fluff.org/ben/smdk2440/
51
52 Many thanks to Dimitry Andric of TomTom for the loan of the SMDK2440,
53 and to Simtec Electronics for allowing me time to work on this.
54
55
56(c) 2004 Ben Dooks \ No newline at end of file
diff --git a/Documentation/arm/Samsung-S3C24XX/Suspend.txt b/Documentation/arm/Samsung-S3C24XX/Suspend.txt
new file mode 100644
index 000000000000..e12bc3284a27
--- /dev/null
+++ b/Documentation/arm/Samsung-S3C24XX/Suspend.txt
@@ -0,0 +1,106 @@
1 S3C24XX Suspend Support
2 =======================
3
4
5Introduction
6------------
7
8 The S3C2410 supports a low-power suspend mode, where the SDRAM is kept
9 in Self-Refresh mode, and all but the essential peripheral blocks are
10 powered down. For more information on how this works, please look
11 at the S3C2410 datasheets from Samsung.
12
13
14Requirements
15------------
16
17 1) A bootloader that can support the necessary resume operation
18
19 2) Support for at least 1 source for resume
20
21 3) CONFIG_PM enabled in the kernel
22
23 4) Any peripherals that are going to be powered down at the same
24 time require suspend/resume support.
25
26
27Resuming
28--------
29
30 The S3C2410 user manual defines the process of sending the CPU to
31 sleep and how it resumes. The default behaviour of the Linux code
32 is to set the GSTATUS3 register to the physical address of the
33 code to resume Linux operation.
34
35 GSTATUS4 is currently left alone by the sleep code, and is free to
36 use for any other purposes (for example, the EB2410ITX uses this to
37 save memory configuration in).
38
39
40Machine Support
41---------------
42
43 The machine specific functions must call the s3c2410_pm_init() function
44 to say that its bootloader is capable of resuming. This can be as
45 simple as adding the following to the machine's definition:
46
47 INITMACHINE(s3c2410_pm_init)
48
49 A board can do its own setup before calling s3c2410_pm_init, if it
50 needs to setup anything else for power management support.
51
52 There is currently no support for over-riding the default method of
53 saving the resume address, if your board requires it, then contact
54 the maintainer and discuss what is required.
55
56 Note, the original method of adding an late_initcall() is wrong,
57 and will end up initialising all compiled machines' pm init!
58
59
60Debugging
61---------
62
63 There are several important things to remember when using PM suspend:
64
65 1) The uart drivers will disable the clocks to the UART blocks when
66 suspending, which means that use of printascii() or similar direct
67 access to the UARTs will cause the debug to stop.
68
69 2) Whilst the pm code itself will attempt to re-enable the UART clocks,
70 care should be taken that any external clock sources that the UARTs
71 rely on are still enabled at that point.
72
73
74Configuration
75-------------
76
77 The S3C2410 specific configuration in `System Type` defines various
78 aspects of how the S3C2410 suspend and resume support is configured
79
80 `S3C2410 PM Suspend debug`
81
82 This option prints messages to the serial console before and after
83 the actual suspend, giving detailed information on what is
84 happening
85
86
87 `S3C2410 PM Suspend Memory CRC`
88
89 Allows the entire memory to be checksummed before and after the
90 suspend to see if there has been any corruption of the contents.
91
92 This support requires the CRC32 function to be enabled.
93
94
95 `S3C2410 PM Suspend CRC Chunksize (KiB)`
96
97 Defines the size of memory each CRC chunk covers. A smaller value
98 will mean that the CRC data block will take more memory, but will
99 identify any faults with better precision
100
101
102Document Author
103---------------
104
105Ben Dooks, (c) 2004 Simtec Electronics
106
diff --git a/Documentation/arm/Setup b/Documentation/arm/Setup
new file mode 100644
index 000000000000..0abd0720d7ed
--- /dev/null
+++ b/Documentation/arm/Setup
@@ -0,0 +1,129 @@
1Kernel initialisation parameters on ARM Linux
2---------------------------------------------
3
4The following document describes the kernel initialisation parameter
5structure, otherwise known as 'struct param_struct' which is used
6for most ARM Linux architectures.
7
8This structure is used to pass initialisation parameters from the
9kernel loader to the Linux kernel proper, and may be short lived
10through the kernel initialisation process. As a general rule, it
11should not be referenced outside of arch/arm/kernel/setup.c:setup_arch().
12
13There are a lot of parameters listed in there, and they are described
14below:
15
16 page_size
17
18 This parameter must be set to the page size of the machine, and
19 will be checked by the kernel.
20
21 nr_pages
22
23 This is the total number of pages of memory in the system. If
24 the memory is banked, then this should contain the total number
25 of pages in the system.
26
27 If the system contains separate VRAM, this value should not
28 include this information.
29
30 ramdisk_size
31
32 This is now obsolete, and should not be used.
33
34 flags
35
36 Various kernel flags, including:
37 bit 0 - 1 = mount root read only
38 bit 1 - unused
39 bit 2 - 0 = load ramdisk
40 bit 3 - 0 = prompt for ramdisk
41
42 rootdev
43
44 major/minor number pair of device to mount as the root filesystem.
45
46 video_num_cols
47 video_num_rows
48
49 These two together describe the character size of the dummy console,
50 or VGA console character size. They should not be used for any other
51 purpose.
52
53 It's generally a good idea to set these to be either standard VGA, or
54 the equivalent character size of your fbcon display. This then allows
55 all the bootup messages to be displayed correctly.
56
57 video_x
58 video_y
59
60 This describes the character position of cursor on VGA console, and
61 is otherwise unused. (should not used for other console types, and
62 should not be used for other purposes).
63
64 memc_control_reg
65
66 MEMC chip control register for Acorn Archimedes and Acorn A5000
67 based machines. May be used differently by different architectures.
68
69 sounddefault
70
71 Default sound setting on Acorn machines. May be used differently by
72 different architectures.
73
74 adfsdrives
75
76 Number of ADFS/MFM disks. May be used differently by different
77 architectures.
78
79 bytes_per_char_h
80 bytes_per_char_v
81
82 These are now obsolete, and should not be used.
83
84 pages_in_bank[4]
85
86 Number of pages in each bank of the systems memory (used for RiscPC).
87 This is intended to be used on systems where the physical memory
88 is non-contiguous from the processors point of view.
89
90 pages_in_vram
91
92 Number of pages in VRAM (used on Acorn RiscPC). This value may also
93 be used by loaders if the size of the video RAM can't be obtained
94 from the hardware.
95
96 initrd_start
97 initrd_size
98
99 This describes the kernel virtual start address and size of the
100 initial ramdisk.
101
102 rd_start
103
104 Start address in sectors of the ramdisk image on a floppy disk.
105
106 system_rev
107
108 system revision number.
109
110 system_serial_low
111 system_serial_high
112
113 system 64-bit serial number
114
115 mem_fclk_21285
116
117 The speed of the external oscillator to the 21285 (footbridge),
118 which control's the speed of the memory bus, timer & serial port.
119 Depending upon the speed of the cpu its value can be between
120 0-66 MHz. If no params are passed or a value of zero is passed,
121 then a value of 50 Mhz is the default on 21285 architectures.
122
123 paths[8][128]
124
125 These are now obsolete, and should not be used.
126
127 commandline
128
129 Kernel command line parameters. Details can be found elsewhere.
diff --git a/Documentation/arm/Sharp-LH/CompactFlash b/Documentation/arm/Sharp-LH/CompactFlash
new file mode 100644
index 000000000000..8616d877df9e
--- /dev/null
+++ b/Documentation/arm/Sharp-LH/CompactFlash
@@ -0,0 +1,32 @@
1README on the Compact Flash for Card Engines
2============================================
3
4There are three challenges in supporting the CF interface of the Card
5Engines. First, every IO operation must be followed with IO to
6another memory region. Second, the slot is wired for one-to-one
7address mapping *and* it is wired for 16 bit access only. Second, the
8interrupt request line from the CF device isn't wired.
9
10The IOBARRIER issue is covered in README.IOBARRIER. This isn't an
11onerous problem. Enough said here.
12
13The addressing issue is solved in the
14arch/arm/mach-lh7a40x/ide-lpd7a40x.c file with some awkward
15work-arounds. We implement a special SELECT_DRIVE routine that is
16called before the IDE driver performs its own SELECT_DRIVE. Our code
17recognizes that the SELECT register cannot be modified without also
18writing a command. It send an IDLE_IMMEDIATE command on selecting a
19drive. The function also prevents drive select to the slave drive
20since there can be only one. The awkward part is that the IDE driver,
21even though we have a select procedure, also attempts to change the
22drive by writing directly the SELECT register. This attempt is
23explicitly blocked by the OUTB function--not pretty, but effective.
24
25The lack of interrupts is a more serious problem. Even though the CF
26card is fast when compared to a normal IDE device, we don't know that
27the CF is really flash. A user could use one of the very small hard
28drives being shipped with a CF interface. The IDE code includes a
29check for interfaces that lack an IRQ. In these cases, submitting a
30command to the IDE controller is followed by a call to poll for
31completion. If the device isn't immediately ready, it schedules a
32timer to poll again later.
diff --git a/Documentation/arm/Sharp-LH/IOBarrier b/Documentation/arm/Sharp-LH/IOBarrier
new file mode 100644
index 000000000000..c0d8853672dc
--- /dev/null
+++ b/Documentation/arm/Sharp-LH/IOBarrier
@@ -0,0 +1,45 @@
1README on the IOBARRIER for CardEngine IO
2=========================================
3
4Due to an unfortunate oversight when the Card Engines were designed,
5the signals that control access to some peripherals, most notably the
6SMC91C9111 ethernet controller, are not properly handled.
7
8The symptom is that some back to back IO with the peripheral returns
9unreliable data. With the SMC chip, you'll see errors about the bank
10register being 'screwed'.
11
12The cause is that the AEN signal to the SMC chip does not transition
13for every memory access. It is driven through the CPLD from the CS7
14line of the CPU's static memory controller which is optimized to
15eliminate unnecessary transitions. Yet, the SMC requires a transition
16for every write access. The Sharp website has more information about
17the effect this power-conserving feature has on peripheral
18interfacing.
19
20The solution is to follow every write access to the SMC chip with an
21access to another memory region that will force the CPU to release the
22chip select line. It is important to guarantee that this access
23forces the CPU off-chip. We map a page of SDRAM as if it were an
24uncacheable IO device and read from it after every SMC IO write
25operation.
26
27 SMC IO
28 BARRIER IO
29
30Only this sequence is important. It does not matter that there is no
31BARRIER IO before the access to the SMC chip because the AEN latch
32only needs occurs after the SMC IO write cycle. The routines that
33implement this work-around make an additional concession which is to
34disable interrupts during the IO sequence. Other hardware devices
35(the LogicPD CPLD) have registers in the same the physical memory
36region as the SMC chip. An interrupt might allow an access to one of
37those registers while SMC IO is being performed.
38
39You might be tempted to think that we have to access another device
40attached to the static memory controller, but the empirical evidence
41indicates that this is not so. Mapping 0x00000000 (flash) and
420xc0000000 (SDRAM) appear to have the same effect. Using SDRAM seems
43to be faster. Choosing to access an undecoded memory region is not
44desirable as there is no way to know how that chip select will be used
45in the future.
diff --git a/Documentation/arm/Sharp-LH/KEV7A400 b/Documentation/arm/Sharp-LH/KEV7A400
new file mode 100644
index 000000000000..be32b14cd535
--- /dev/null
+++ b/Documentation/arm/Sharp-LH/KEV7A400
@@ -0,0 +1,8 @@
1README on Implementing Linux for Sharp's KEV7a400
2=================================================
3
4This product has been discontinued by Sharp. For the time being, the
5partially implemented code remains in the kernel. At some point in
6the future, either the code will be finished or it will be removed
7completely. This depends primarily on how many of the development
8boards are in the field.
diff --git a/Documentation/arm/Sharp-LH/LPD7A400 b/Documentation/arm/Sharp-LH/LPD7A400
new file mode 100644
index 000000000000..3275b453bfdf
--- /dev/null
+++ b/Documentation/arm/Sharp-LH/LPD7A400
@@ -0,0 +1,15 @@
1README on Implementing Linux for the Logic PD LPD7A400-10
2=========================================================
3
4- CPLD memory mapping
5
6 The board designers chose to use high address lines for controlling
7 access to the CPLD registers. It turns out to be a big waste
8 because we're using an MMU and must map IO space into virtual
9 memory. The result is that we have to make a mapping for every
10 register.
11
12- Serial Console
13
14 It may be OK not to use the serial console option if the user passes
15 the console device name to the kernel. This deserves some exploration.
diff --git a/Documentation/arm/Sharp-LH/LPD7A40X b/Documentation/arm/Sharp-LH/LPD7A40X
new file mode 100644
index 000000000000..8c29a27e208f
--- /dev/null
+++ b/Documentation/arm/Sharp-LH/LPD7A40X
@@ -0,0 +1,16 @@
1README on Implementing Linux for the Logic PD LPD7A40X-10
2=========================================================
3
4- CPLD memory mapping
5
6 The board designers chose to use high address lines for controlling
7 access to the CPLD registers. It turns out to be a big waste
8 because we're using an MMU and must map IO space into virtual
9 memory. The result is that we have to make a mapping for every
10 register.
11
12- Serial Console
13
14 It may be OK not to use the serial console option if the user passes
15 the console device name to the kernel. This deserves some exploration.
16
diff --git a/Documentation/arm/Sharp-LH/SDRAM b/Documentation/arm/Sharp-LH/SDRAM
new file mode 100644
index 000000000000..93ddc23c2faa
--- /dev/null
+++ b/Documentation/arm/Sharp-LH/SDRAM
@@ -0,0 +1,51 @@
1README on the SDRAM Controller for the LH7a40X
2==============================================
3
4The standard configuration for the SDRAM controller generates a sparse
5memory array. The precise layout is determined by the SDRAM chips. A
6default kernel configuration assembles the discontiguous memory
7regions into separate memory nodes via the NUMA (Non-Uniform Memory
8Architecture) facilities. In this default configuration, the kernel
9is forgiving about the precise layout. As long as it is given an
10accurate picture of available memory by the bootloader the kernel will
11execute correctly.
12
13The SDRC supports a mode where some of the chip select lines are
14swapped in order to make SDRAM look like a synchronous ROM. Setting
15this bit means that the RAM will present as a contiguous array. Some
16programmers prefer this to the discontiguous layout. Be aware that
17may be a penalty for this feature where some some configurations of
18memory are significantly reduced; i.e. 64MiB of RAM appears as only 32
19MiB.
20
21There are a couple of configuration options to override the default
22behavior. When the SROMLL bit is set and memory appears as a
23contiguous array, there is no reason to support NUMA.
24CONFIG_LH7A40X_CONTIGMEM disables NUMA support. When physical memory
25is discontiguous, the memory tables are organized such that there are
26two banks per nodes with a small gap between them. This layout wastes
27some kernel memory for page tables representing non-existent memory.
28CONFIG_LH7A40X_ONE_BANK_PER_NODE optimizes the node tables such that
29there are no gaps. These options control the low level organization
30of the memory management tables in ways that may prevent the kernel
31from booting or may cause the kernel to allocated excessively large
32page tables. Be warned. Only change these options if you know what
33you are doing. The default behavior is a reasonable compromise that
34will suit all users.
35
36--
37
38A typical 32MiB system with the default configuration options will
39find physical memory managed as follows.
40
41 node 0: 0xc0000000 4MiB
42 0xc1000000 4MiB
43 node 1: 0xc4000000 4MiB
44 0xc5000000 4MiB
45 node 2: 0xc8000000 4MiB
46 0xc9000000 4MiB
47 node 3: 0xcc000000 4MiB
48 0xcd000000 4MiB
49
50Setting CONFIG_LH7A40X_ONE_BANK_PER_NODE will put each bank into a
51separate node.
diff --git a/Documentation/arm/Sharp-LH/VectoredInterruptController b/Documentation/arm/Sharp-LH/VectoredInterruptController
new file mode 100644
index 000000000000..23047e9861ee
--- /dev/null
+++ b/Documentation/arm/Sharp-LH/VectoredInterruptController
@@ -0,0 +1,80 @@
1README on the Vectored Interrupt Controller of the LH7A404
2==========================================================
3
4The 404 revision of the LH7A40X series comes with two vectored
5interrupts controllers. While the kernel does use some of the
6features of these devices, it is far from the purpose for which they
7were designed.
8
9When this README was written, the implementation of the VICs was in
10flux. It is possible that some details, especially with priorities,
11will change.
12
13The VIC support code is inspired by routines written by Sharp.
14
15
16Priority Control
17----------------
18
19The significant reason for using the VIC's vectoring is to control
20interrupt priorities. There are two tables in
21arch/arm/mach-lh7a40x/irq-lh7a404.c that look something like this.
22
23 static unsigned char irq_pri_vic1[] = { IRQ_GPIO3INTR, };
24 static unsigned char irq_pri_vic2[] = {
25 IRQ_T3UI, IRQ_GPIO7INTR,
26 IRQ_UART1INTR, IRQ_UART2INTR, IRQ_UART3INTR, };
27
28The initialization code reads these tables and inserts a vector
29address and enable for each indicated IRQ. Vectored interrupts have
30higher priority than non-vectored interrupts. So, on VIC1,
31IRQ_GPIO3INTR will be served before any other non-FIQ interrupt. Due
32to the way that the vectoring works, IRQ_T3UI is the next highest
33priority followed by the other vectored interrupts on VIC2. After
34that, the non-vectored interrupts are scanned in VIC1 then in VIC2.
35
36
37ISR
38---
39
40The interrupt service routine macro get_irqnr() in
41arch/arm/kernel/entry-armv.S scans the VICs for the next active
42interrupt. The vectoring makes this code somewhat larger than it was
43before using vectoring (refer to the LH7A400 implementation). In the
44case where an interrupt is vectored, the implementation will tend to
45be faster than the non-vectored version. However, the worst-case path
46is longer.
47
48It is worth noting that at present, there is no need to read
49VIC2_VECTADDR because the register appears to be shared between the
50controllers. The code is written such that if this changes, it ought
51to still work properly.
52
53
54Vector Addresses
55----------------
56
57The proper use of the vectoring hardware would jump to the ISR
58specified by the vectoring address. Linux isn't structured to take
59advantage of this feature, though it might be possible to change
60things to support it.
61
62In this implementation, the vectoring address is used to speed the
63search for the active IRQ. The address is coded such that the lowest
646 bits store the IRQ number for vectored interrupts. These numbers
65correspond to the bits in the interrupt status registers. IRQ zero is
66the lowest interrupt bit in VIC1. IRQ 32 is the lowest interrupt bit
67in VIC2. Because zero is a valid IRQ number and because we cannot
68detect whether or not there is a valid vectoring address if that
69address is zero, the eigth bit (0x100) is set for vectored interrupts.
70The address for IRQ 0x18 (VIC2) is 0x118. Only the ninth bit is set
71for the default handler on VIC1 and only the tenth bit is set for the
72default handler on VIC2.
73
74In other words.
75
76 0x000 - no active interrupt
77 0x1ii - vectored interrupt 0xii
78 0x2xx - unvectored interrupt on VIC1 (xx is don't care)
79 0x4xx - unvectored interrupt on VIC2 (xx is don't care)
80
diff --git a/Documentation/arm/VFP/release-notes.txt b/Documentation/arm/VFP/release-notes.txt
new file mode 100644
index 000000000000..f28e0222f5e5
--- /dev/null
+++ b/Documentation/arm/VFP/release-notes.txt
@@ -0,0 +1,55 @@
1Release notes for Linux Kernel VFP support code
2-----------------------------------------------
3
4Date: 20 May 2004
5Author: Russell King
6
7This is the first release of the Linux Kernel VFP support code. It
8provides support for the exceptions bounced from VFP hardware found
9on ARM926EJ-S.
10
11This release has been validated against the SoftFloat-2b library by
12John R. Hauser using the TestFloat-2a test suite. Details of this
13library and test suite can be found at:
14
15 http://www.cs.berkeley.edu/~jhauser/arithmetic/SoftFloat.html
16
17The operations which have been tested with this package are:
18
19 - fdiv
20 - fsub
21 - fadd
22 - fmul
23 - fcmp
24 - fcmpe
25 - fcvtd
26 - fcvts
27 - fsito
28 - ftosi
29 - fsqrt
30
31All the above pass softfloat tests with the following exceptions:
32
33- fadd/fsub shows some differences in the handling of +0 / -0 results
34 when input operands differ in signs.
35- the handling of underflow exceptions is slightly different. If a
36 result underflows before rounding, but becomes a normalised number
37 after rounding, we do not signal an underflow exception.
38
39Other operations which have been tested by basic assembly-only tests
40are:
41
42 - fcpy
43 - fabs
44 - fneg
45 - ftoui
46 - ftosiz
47 - ftouiz
48
49The combination operations have not been tested:
50
51 - fmac
52 - fnmac
53 - fmsc
54 - fnmsc
55 - fnmul
diff --git a/Documentation/arm/empeg/README b/Documentation/arm/empeg/README
new file mode 100644
index 000000000000..09cc8d03ae58
--- /dev/null
+++ b/Documentation/arm/empeg/README
@@ -0,0 +1,13 @@
1Empeg, Ltd's Empeg MP3 Car Audio Player
2
3The initial design is to go in your car, but you can use it at home, on a
4boat... almost anywhere. The principle is to store CD-quality music using
5MPEG technology onto a hard disk in the unit, and use the power of the
6embedded computer to serve up the music you want.
7
8For more details, see:
9
10 http://www.empeg.com
11
12
13
diff --git a/Documentation/arm/empeg/ir.txt b/Documentation/arm/empeg/ir.txt
new file mode 100644
index 000000000000..10a297450164
--- /dev/null
+++ b/Documentation/arm/empeg/ir.txt
@@ -0,0 +1,49 @@
1Infra-red driver documentation.
2
3Mike Crowe <mac@empeg.com>
4(C) Empeg Ltd 1999
5
6Not a lot here yet :-)
7
8The Kenwood KCA-R6A remote control generates a sequence like the following:
9
10Go low for approx 16T (Around 9000us)
11Go high for approx 8T (Around 4000us)
12Go low for less than 2T (Around 750us)
13
14For each of the 32 bits
15 Go high for more than 2T (Around 1500us) == 1
16 Go high for less than T (Around 400us) == 0
17 Go low for less than 2T (Around 750us)
18
19Rather than repeat a signal when the button is held down certain buttons
20generate the following code to indicate repetition.
21
22Go low for approx 16T
23Go high for approx 4T
24Go low for less than 2T
25
26(By removing the <2T from the start of the sequence and placing at the end
27 it can be considered a stop bit but I found it easier to deal with it at
28 the start).
29
30The 32 bits are encoded as XxYy where x and y are the actual data values
31while X and Y are the logical inverses of the associated data values. Using
32LSB first yields sensible codes for the numbers.
33
34All codes are of the form b9xx
35
36The numeric keys generate the code 0x where x is the number pressed.
37
38Tuner 1c
39Tape 1d
40CD 1e
41CD-MD-CH 1f
42Track- 0a
43Track+ 0b
44Rewind 0c
45FF 0d
46DNPP 5e
47Play/Pause 0e
48Vol+ 14
49Vol- 15
diff --git a/Documentation/arm/empeg/mkdevs b/Documentation/arm/empeg/mkdevs
new file mode 100644
index 000000000000..7a85e28d14f3
--- /dev/null
+++ b/Documentation/arm/empeg/mkdevs
@@ -0,0 +1,11 @@
1#!/bin/sh
2mknod /dev/display c 244 0
3mknod /dev/ir c 242 0
4mknod /dev/usb0 c 243 0
5mknod /dev/audio c 245 4
6mknod /dev/dsp c 245 3
7mknod /dev/mixer c 245 0
8mknod /dev/empeg_state c 246 0
9mknod /dev/radio0 c 81 64
10ln -sf radio0 radio
11ln -sf usb0 usb
diff --git a/Documentation/arm/mem_alignment b/Documentation/arm/mem_alignment
new file mode 100644
index 000000000000..d145ccca169a
--- /dev/null
+++ b/Documentation/arm/mem_alignment
@@ -0,0 +1,58 @@
1Too many problems poped up because of unnoticed misaligned memory access in
2kernel code lately. Therefore the alignment fixup is now unconditionally
3configured in for SA11x0 based targets. According to Alan Cox, this is a
4bad idea to configure it out, but Russell King has some good reasons for
5doing so on some f***ed up ARM architectures like the EBSA110. However
6this is not the case on many design I'm aware of, like all SA11x0 based
7ones.
8
9Of course this is a bad idea to rely on the alignment trap to perform
10unaligned memory access in general. If those access are predictable, you
11are better to use the macros provided by include/asm/unaligned.h. The
12alignment trap can fixup misaligned access for the exception cases, but at
13a high performance cost. It better be rare.
14
15Now for user space applications, it is possible to configure the alignment
16trap to SIGBUS any code performing unaligned access (good for debugging bad
17code), or even fixup the access by software like for kernel code. The later
18mode isn't recommended for performance reasons (just think about the
19floating point emulation that works about the same way). Fix your code
20instead!
21
22Please note that randomly changing the behaviour without good thought is
23real bad - it changes the behaviour of all unaligned instructions in user
24space, and might cause programs to fail unexpectedly.
25
26To change the alignment trap behavior, simply echo a number into
27/proc/sys/debug/alignment. The number is made up from various bits:
28
29bit behavior when set
30--- -----------------
31
320 A user process performing an unaligned memory access
33 will cause the kernel to print a message indicating
34 process name, pid, pc, instruction, address, and the
35 fault code.
36
371 The kernel will attempt to fix up the user process
38 performing the unaligned access. This is of course
39 slow (think about the floating point emulator) and
40 not recommended for production use.
41
422 The kernel will send a SIGBUS signal to the user process
43 performing the unaligned access.
44
45Note that not all combinations are supported - only values 0 through 5.
46(6 and 7 don't make sense).
47
48For example, the following will turn on the warnings, but without
49fixing up or sending SIGBUS signals:
50
51 echo 1 > /proc/sys/debug/alignment
52
53You can also read the content of the same file to get statistical
54information on unaligned access occurrences plus the current mode of
55operation for user space code.
56
57
58Nicolas Pitre, Mar 13, 2001. Modified Russell King, Nov 30, 2001.
diff --git a/Documentation/arm/memory.txt b/Documentation/arm/memory.txt
new file mode 100644
index 000000000000..4b1c93a8177b
--- /dev/null
+++ b/Documentation/arm/memory.txt
@@ -0,0 +1,72 @@
1 Kernel Memory Layout on ARM Linux
2
3 Russell King <rmk@arm.linux.org.uk>
4 May 21, 2004 (2.6.6)
5
6This document describes the virtual memory layout which the Linux
7kernel uses for ARM processors. It indicates which regions are
8free for platforms to use, and which are used by generic code.
9
10The ARM CPU is capable of addressing a maximum of 4GB virtual memory
11space, and this must be shared between user space processes, the
12kernel, and hardware devices.
13
14As the ARM architecture matures, it becomes necessary to reserve
15certain regions of VM space for use for new facilities; therefore
16this document may reserve more VM space over time.
17
18Start End Use
19--------------------------------------------------------------------------
20ffff8000 ffffffff copy_user_page / clear_user_page use.
21 For SA11xx and Xscale, this is used to
22 setup a minicache mapping.
23
24ffff1000 ffff7fff Reserved.
25 Platforms must not use this address range.
26
27ffff0000 ffff0fff CPU vector page.
28 The CPU vectors are mapped here if the
29 CPU supports vector relocation (control
30 register V bit.)
31
32ffc00000 fffeffff DMA memory mapping region. Memory returned
33 by the dma_alloc_xxx functions will be
34 dynamically mapped here.
35
36ff000000 ffbfffff Reserved for future expansion of DMA
37 mapping region.
38
39VMALLOC_END feffffff Free for platform use, recommended.
40
41VMALLOC_START VMALLOC_END-1 vmalloc() / ioremap() space.
42 Memory returned by vmalloc/ioremap will
43 be dynamically placed in this region.
44 VMALLOC_START may be based upon the value
45 of the high_memory variable.
46
47PAGE_OFFSET high_memory-1 Kernel direct-mapped RAM region.
48 This maps the platforms RAM, and typically
49 maps all platform RAM in a 1:1 relationship.
50
51TASK_SIZE PAGE_OFFSET-1 Kernel module space
52 Kernel modules inserted via insmod are
53 placed here using dynamic mappings.
54
5500001000 TASK_SIZE-1 User space mappings
56 Per-thread mappings are placed here via
57 the mmap() system call.
58
5900000000 00000fff CPU vector page / null pointer trap
60 CPUs which do not support vector remapping
61 place their vector page here. NULL pointer
62 dereferences by both the kernel and user
63 space are also caught via this mapping.
64
65Please note that mappings which collide with the above areas may result
66in a non-bootable kernel, or may cause the kernel to (eventually) panic
67at run time.
68
69Since future CPUs may impact the kernel mapping layout, user programs
70must not access any memory which is not mapped inside their 0x0001000
71to TASK_SIZE address range. If they wish to access these areas, they
72must set up their own mappings using open() and mmap().
diff --git a/Documentation/arm/nwfpe/NOTES b/Documentation/arm/nwfpe/NOTES
new file mode 100644
index 000000000000..40577b5a49d3
--- /dev/null
+++ b/Documentation/arm/nwfpe/NOTES
@@ -0,0 +1,29 @@
1There seems to be a problem with exp(double) and our emulator. I haven't
2been able to track it down yet. This does not occur with the emulator
3supplied by Russell King.
4
5I also found one oddity in the emulator. I don't think it is serious but
6will point it out. The ARM calling conventions require floating point
7registers f4-f7 to be preserved over a function call. The compiler quite
8often uses an stfe instruction to save f4 on the stack upon entry to a
9function, and an ldfe instruction to restore it before returning.
10
11I was looking at some code, that calculated a double result, stored it in f4
12then made a function call. Upon return from the function call the number in
13f4 had been converted to an extended value in the emulator.
14
15This is a side effect of the stfe instruction. The double in f4 had to be
16converted to extended, then stored. If an lfm/sfm combination had been used,
17then no conversion would occur. This has performance considerations. The
18result from the function call and f4 were used in a multiplication. If the
19emulator sees a multiply of a double and extended, it promotes the double to
20extended, then does the multiply in extended precision.
21
22This code will cause this problem:
23
24double x, y, z;
25z = log(x)/log(y);
26
27The result of log(x) (a double) will be calculated, returned in f0, then
28moved to f4 to preserve it over the log(y) call. The division will be done
29in extended precision, due to the stfe instruction used to save f4 in log(y).
diff --git a/Documentation/arm/nwfpe/README b/Documentation/arm/nwfpe/README
new file mode 100644
index 000000000000..771871de0c8b
--- /dev/null
+++ b/Documentation/arm/nwfpe/README
@@ -0,0 +1,70 @@
1This directory contains the version 0.92 test release of the NetWinder
2Floating Point Emulator.
3
4The majority of the code was written by me, Scott Bambrough It is
5written in C, with a small number of routines in inline assembler
6where required. It was written quickly, with a goal of implementing a
7working version of all the floating point instructions the compiler
8emits as the first target. I have attempted to be as optimal as
9possible, but there remains much room for improvement.
10
11I have attempted to make the emulator as portable as possible. One of
12the problems is with leading underscores on kernel symbols. Elf
13kernels have no leading underscores, a.out compiled kernels do. I
14have attempted to use the C_SYMBOL_NAME macro wherever this may be
15important.
16
17Another choice I made was in the file structure. I have attempted to
18contain all operating system specific code in one module (fpmodule.*).
19All the other files contain emulator specific code. This should allow
20others to port the emulator to NetBSD for instance relatively easily.
21
22The floating point operations are based on SoftFloat Release 2, by
23John Hauser. SoftFloat is a software implementation of floating-point
24that conforms to the IEC/IEEE Standard for Binary Floating-point
25Arithmetic. As many as four formats are supported: single precision,
26double precision, extended double precision, and quadruple precision.
27All operations required by the standard are implemented, except for
28conversions to and from decimal. We use only the single precision,
29double precision and extended double precision formats. The port of
30SoftFloat to the ARM was done by Phil Blundell, based on an earlier
31port of SoftFloat version 1 by Neil Carson for NetBSD/arm32.
32
33The file README.FPE contains a description of what has been implemented
34so far in the emulator. The file TODO contains a information on what
35remains to be done, and other ideas for the emulator.
36
37Bug reports, comments, suggestions should be directed to me at
38<scottb@netwinder.org>. General reports of "this program doesn't
39work correctly when your emulator is installed" are useful for
40determining that bugs still exist; but are virtually useless when
41attempting to isolate the problem. Please report them, but don't
42expect quick action. Bugs still exist. The problem remains in isolating
43which instruction contains the bug. Small programs illustrating a specific
44problem are a godsend.
45
46Legal Notices
47-------------
48
49The NetWinder Floating Point Emulator is free software. Everything Rebel.com
50has written is provided under the GNU GPL. See the file COPYING for copying
51conditions. Excluded from the above is the SoftFloat code. John Hauser's
52legal notice for SoftFloat is included below.
53
54-------------------------------------------------------------------------------
55SoftFloat Legal Notice
56
57SoftFloat was written by John R. Hauser. This work was made possible in
58part by the International Computer Science Institute, located at Suite 600,
591947 Center Street, Berkeley, California 94704. Funding was partially
60provided by the National Science Foundation under grant MIP-9311980. The
61original version of this code was written as part of a project to build
62a fixed-point vector processor in collaboration with the University of
63California at Berkeley, overseen by Profs. Nelson Morgan and John Wawrzynek.
64
65THIS SOFTWARE IS DISTRIBUTED AS IS, FOR FREE. Although reasonable effort
66has been made to avoid it, THIS SOFTWARE MAY CONTAIN FAULTS THAT WILL AT
67TIMES RESULT IN INCORRECT BEHAVIOR. USE OF THIS SOFTWARE IS RESTRICTED TO
68PERSONS AND ORGANIZATIONS WHO CAN AND WILL TAKE FULL RESPONSIBILITY FOR ANY
69AND ALL LOSSES, COSTS, OR OTHER PROBLEMS ARISING FROM ITS USE.
70-------------------------------------------------------------------------------
diff --git a/Documentation/arm/nwfpe/README.FPE b/Documentation/arm/nwfpe/README.FPE
new file mode 100644
index 000000000000..26f5d7bb9a41
--- /dev/null
+++ b/Documentation/arm/nwfpe/README.FPE
@@ -0,0 +1,156 @@
1The following describes the current state of the NetWinder's floating point
2emulator.
3
4In the following nomenclature is used to describe the floating point
5instructions. It follows the conventions in the ARM manual.
6
7<S|D|E> = <single|double|extended>, no default
8{P|M|Z} = {round to +infinity,round to -infinity,round to zero},
9 default = round to nearest
10
11Note: items enclosed in {} are optional.
12
13Floating Point Coprocessor Data Transfer Instructions (CPDT)
14------------------------------------------------------------
15
16LDF/STF - load and store floating
17
18<LDF|STF>{cond}<S|D|E> Fd, Rn
19<LDF|STF>{cond}<S|D|E> Fd, [Rn, #<expression>]{!}
20<LDF|STF>{cond}<S|D|E> Fd, [Rn], #<expression>
21
22These instructions are fully implemented.
23
24LFM/SFM - load and store multiple floating
25
26Form 1 syntax:
27<LFM|SFM>{cond}<S|D|E> Fd, <count>, [Rn]
28<LFM|SFM>{cond}<S|D|E> Fd, <count>, [Rn, #<expression>]{!}
29<LFM|SFM>{cond}<S|D|E> Fd, <count>, [Rn], #<expression>
30
31Form 2 syntax:
32<LFM|SFM>{cond}<FD,EA> Fd, <count>, [Rn]{!}
33
34These instructions are fully implemented. They store/load three words
35for each floating point register into the memory location given in the
36instruction. The format in memory is unlikely to be compatible with
37other implementations, in particular the actual hardware. Specific
38mention of this is made in the ARM manuals.
39
40Floating Point Coprocessor Register Transfer Instructions (CPRT)
41----------------------------------------------------------------
42
43Conversions, read/write status/control register instructions
44
45FLT{cond}<S,D,E>{P,M,Z} Fn, Rd Convert integer to floating point
46FIX{cond}{P,M,Z} Rd, Fn Convert floating point to integer
47WFS{cond} Rd Write floating point status register
48RFS{cond} Rd Read floating point status register
49WFC{cond} Rd Write floating point control register
50RFC{cond} Rd Read floating point control register
51
52FLT/FIX are fully implemented.
53
54RFS/WFS are fully implemented.
55
56RFC/WFC are fully implemented. RFC/WFC are supervisor only instructions, and
57presently check the CPU mode, and do an invalid instruction trap if not called
58from supervisor mode.
59
60Compare instructions
61
62CMF{cond} Fn, Fm Compare floating
63CMFE{cond} Fn, Fm Compare floating with exception
64CNF{cond} Fn, Fm Compare negated floating
65CNFE{cond} Fn, Fm Compare negated floating with exception
66
67These are fully implemented.
68
69Floating Point Coprocessor Data Instructions (CPDT)
70---------------------------------------------------
71
72Dyadic operations:
73
74ADF{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - add
75SUF{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - subtract
76RSF{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - reverse subtract
77MUF{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - multiply
78DVF{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - divide
79RDV{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - reverse divide
80
81These are fully implemented.
82
83FML{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - fast multiply
84FDV{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - fast divide
85FRD{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - fast reverse divide
86
87These are fully implemented as well. They use the same algorithm as the
88non-fast versions. Hence, in this implementation their performance is
89equivalent to the MUF/DVF/RDV instructions. This is acceptable according
90to the ARM manual. The manual notes these are defined only for single
91operands, on the actual FPA11 hardware they do not work for double or
92extended precision operands. The emulator currently does not check
93the requested permissions conditions, and performs the requested operation.
94
95RMF{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - IEEE remainder
96
97This is fully implemented.
98
99Monadic operations:
100
101MVF{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - move
102MNF{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - move negated
103
104These are fully implemented.
105
106ABS{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - absolute value
107SQT{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - square root
108RND{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - round
109
110These are fully implemented.
111
112URD{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - unnormalized round
113NRM{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - normalize
114
115These are implemented. URD is implemented using the same code as the RND
116instruction. Since URD cannot return a unnormalized number, NRM becomes
117a NOP.
118
119Library calls:
120
121POW{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - power
122RPW{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - reverse power
123POL{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - polar angle (arctan2)
124
125LOG{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - logarithm to base 10
126LGN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - logarithm to base e
127EXP{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - exponent
128SIN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - sine
129COS{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - cosine
130TAN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - tangent
131ASN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arcsine
132ACS{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arccosine
133ATN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arctangent
134
135These are not implemented. They are not currently issued by the compiler,
136and are handled by routines in libc. These are not implemented by the FPA11
137hardware, but are handled by the floating point support code. They should
138be implemented in future versions.
139
140Signalling:
141
142Signals are implemented. However current ELF kernels produced by Rebel.com
143have a bug in them that prevents the module from generating a SIGFPE. This
144is caused by a failure to alias fp_current to the kernel variable
145current_set[0] correctly.
146
147The kernel provided with this distribution (vmlinux-nwfpe-0.93) contains
148a fix for this problem and also incorporates the current version of the
149emulator directly. It is possible to run with no floating point module
150loaded with this kernel. It is provided as a demonstration of the
151technology and for those who want to do floating point work that depends
152on signals. It is not strictly necessary to use the module.
153
154A module (either the one provided by Russell King, or the one in this
155distribution) can be loaded to replace the functionality of the emulator
156built into the kernel.
diff --git a/Documentation/arm/nwfpe/TODO b/Documentation/arm/nwfpe/TODO
new file mode 100644
index 000000000000..8027061b60eb
--- /dev/null
+++ b/Documentation/arm/nwfpe/TODO
@@ -0,0 +1,67 @@
1TODO LIST
2---------
3
4POW{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - power
5RPW{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - reverse power
6POL{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - polar angle (arctan2)
7
8LOG{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - logarithm to base 10
9LGN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - logarithm to base e
10EXP{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - exponent
11SIN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - sine
12COS{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - cosine
13TAN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - tangent
14ASN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arcsine
15ACS{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arccosine
16ATN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arctangent
17
18These are not implemented. They are not currently issued by the compiler,
19and are handled by routines in libc. These are not implemented by the FPA11
20hardware, but are handled by the floating point support code. They should
21be implemented in future versions.
22
23There are a couple of ways to approach the implementation of these. One
24method would be to use accurate table methods for these routines. I have
25a couple of papers by S. Gal from IBM's research labs in Haifa, Israel that
26seem to promise extreme accuracy (in the order of 99.8%) and reasonable speed.
27These methods are used in GLIBC for some of the transcendental functions.
28
29Another approach, which I know little about is CORDIC. This stands for
30Coordinate Rotation Digital Computer, and is a method of computing
31transcendental functions using mostly shifts and adds and a few
32multiplications and divisions. The ARM excels at shifts and adds,
33so such a method could be promising, but requires more research to
34determine if it is feasible.
35
36Rounding Methods
37
38The IEEE standard defines 4 rounding modes. Round to nearest is the
39default, but rounding to + or - infinity or round to zero are also allowed.
40Many architectures allow the rounding mode to be specified by modifying bits
41in a control register. Not so with the ARM FPA11 architecture. To change
42the rounding mode one must specify it with each instruction.
43
44This has made porting some benchmarks difficult. It is possible to
45introduce such a capability into the emulator. The FPCR contains
46bits describing the rounding mode. The emulator could be altered to
47examine a flag, which if set forced it to ignore the rounding mode in
48the instruction, and use the mode specified in the bits in the FPCR.
49
50This would require a method of getting/setting the flag, and the bits
51in the FPCR. This requires a kernel call in ArmLinux, as WFC/RFC are
52supervisor only instructions. If anyone has any ideas or comments I
53would like to hear them.
54
55[NOTE: pulled out from some docs on ARM floating point, specifically
56 for the Acorn FPE, but not limited to it:
57
58 The floating point control register (FPCR) may only be present in some
59 implementations: it is there to control the hardware in an implementation-
60 specific manner, for example to disable the floating point system. The user
61 mode of the ARM is not permitted to use this register (since the right is
62 reserved to alter it between implementations) and the WFC and RFC
63 instructions will trap if tried in user mode.
64
65 Hence, the answer is yes, you could do this, but then you will run a high
66 risk of becoming isolated if and when hardware FP emulation comes out
67 -- Russell].