USB: convert drivers/staging/* to use module_usb_driver()
[zen-stable.git] / Documentation / arm / SA1100 / Assabet
blob08b885d35674aa4a37512a05059bd04c483bc120
1 The Intel Assabet (SA-1110 evaluation) board
2 ============================================
4 Please see:
5 http://developer.intel.com
7 Also some notes from John G Dorsey <jd5q@andrew.cmu.edu>:
8 http://www.cs.cmu.edu/~wearable/software/assabet.html
11 Building the kernel
12 -------------------
14 To build the kernel with current defaults:
16         make assabet_config
17         make oldconfig
18         make zImage
20 The resulting kernel image should be available in linux/arch/arm/boot/zImage.
23 Installing a bootloader
24 -----------------------
26 A couple of bootloaders able to boot Linux on Assabet are available:
28 BLOB (http://www.lartmaker.nl/lartware/blob/)
30    BLOB is a bootloader used within the LART project.  Some contributed
31    patches were merged into BLOB to add support for Assabet.
33 Compaq's Bootldr + John Dorsey's patch for Assabet support
34 (http://www.handhelds.org/Compaq/bootldr.html)
35 (http://www.wearablegroup.org/software/bootldr/)
37    Bootldr is the bootloader developed by Compaq for the iPAQ Pocket PC.
38    John Dorsey has produced add-on patches to add support for Assabet and
39    the JFFS filesystem.
41 RedBoot (http://sources.redhat.com/redboot/)
43    RedBoot is a bootloader developed by Red Hat based on the eCos RTOS
44    hardware abstraction layer.  It supports Assabet amongst many other
45    hardware platforms.
47 RedBoot is currently the recommended choice since it's the only one to have
48 networking support, and is the most actively maintained.
50 Brief examples on how to boot Linux with RedBoot are shown below.  But first
51 you need to have RedBoot installed in your flash memory.  A known to work
52 precompiled RedBoot binary is available from the following location:
54 ftp://ftp.netwinder.org/users/n/nico/
55 ftp://ftp.arm.linux.org.uk/pub/linux/arm/people/nico/
56 ftp://ftp.handhelds.org/pub/linux/arm/sa-1100-patches/
58 Look for redboot-assabet*.tgz.  Some installation infos are provided in
59 redboot-assabet*.txt.
62 Initial RedBoot configuration
63 -----------------------------
65 The commands used here are explained in The RedBoot User's Guide available
66 on-line at http://sources.redhat.com/ecos/docs.html.
67 Please refer to it for explanations.
69 If you have a CF network card (my Assabet kit contained a CF+ LP-E from
70 Socket Communications Inc.), you should strongly consider using it for TFTP
71 file transfers.  You must insert it before RedBoot runs since it can't detect
72 it dynamically.
74 To initialize the flash directory:
76         fis init -f
78 To initialize the non-volatile settings, like whether you want to use BOOTP or
79 a static IP address, etc, use this command:
81         fconfig -i
84 Writing a kernel image into flash
85 ---------------------------------
87 First, the kernel image must be loaded into RAM.  If you have the zImage file
88 available on a TFTP server:
90         load zImage -r -b 0x100000
92 If you rather want to use Y-Modem upload over the serial port:
94         load -m ymodem -r -b 0x100000
96 To write it to flash:
98         fis create "Linux kernel" -b 0x100000 -l 0xc0000
101 Booting the kernel
102 ------------------
104 The kernel still requires a filesystem to boot.  A ramdisk image can be loaded
105 as follows:
107         load ramdisk_image.gz -r -b 0x800000
109 Again, Y-Modem upload can be used instead of TFTP by replacing the file name
110 by '-y ymodem'.
112 Now the kernel can be retrieved from flash like this:
114         fis load "Linux kernel"
116 or loaded as described previously.  To boot the kernel:
118         exec -b 0x100000 -l 0xc0000
120 The ramdisk image could be stored into flash as well, but there are better
121 solutions for on-flash filesystems as mentioned below.
124 Using JFFS2
125 -----------
127 Using JFFS2 (the Second Journalling Flash File System) is probably the most
128 convenient way to store a writable filesystem into flash.  JFFS2 is used in
129 conjunction with the MTD layer which is responsible for low-level flash
130 management.  More information on the Linux MTD can be found on-line at:
131 http://www.linux-mtd.infradead.org/.  A JFFS howto with some infos about
132 creating JFFS/JFFS2 images is available from the same site.
134 For instance, a sample JFFS2 image can be retrieved from the same FTP sites
135 mentioned below for the precompiled RedBoot image.
137 To load this file:
139         load sample_img.jffs2 -r -b 0x100000
141 The result should look like:
143 RedBoot> load sample_img.jffs2 -r -b 0x100000
144 Raw file loaded 0x00100000-0x00377424
146 Now we must know the size of the unallocated flash:
148         fis free
150 Result:
152 RedBoot> fis free
153   0x500E0000 .. 0x503C0000
155 The values above may be different depending on the size of the filesystem and
156 the type of flash.  See their usage below as an example and take care of
157 substituting yours appropriately.
159 We must determine some values:
161 size of unallocated flash:      0x503c0000 - 0x500e0000 = 0x2e0000
162 size of the filesystem image:   0x00377424 - 0x00100000 = 0x277424
164 We want to fit the filesystem image of course, but we also want to give it all
165 the remaining flash space as well.  To write it:
167         fis unlock -f 0x500E0000 -l 0x2e0000
168         fis erase -f 0x500E0000 -l 0x2e0000
169         fis write -b 0x100000 -l 0x277424 -f 0x500E0000
170         fis create "JFFS2" -n -f 0x500E0000 -l 0x2e0000
172 Now the filesystem is associated to a MTD "partition" once Linux has discovered
173 what they are in the boot process.  From Redboot, the 'fis list' command
174 displays them:
176 RedBoot> fis list
177 Name              FLASH addr  Mem addr    Length      Entry point
178 RedBoot           0x50000000  0x50000000  0x00020000  0x00000000
179 RedBoot config    0x503C0000  0x503C0000  0x00020000  0x00000000
180 FIS directory     0x503E0000  0x503E0000  0x00020000  0x00000000
181 Linux kernel      0x50020000  0x00100000  0x000C0000  0x00000000
182 JFFS2             0x500E0000  0x500E0000  0x002E0000  0x00000000
184 However Linux should display something like:
186 SA1100 flash: probing 32-bit flash bus
187 SA1100 flash: Found 2 x16 devices at 0x0 in 32-bit mode
188 Using RedBoot partition definition
189 Creating 5 MTD partitions on "SA1100 flash":
190 0x00000000-0x00020000 : "RedBoot"
191 0x00020000-0x000e0000 : "Linux kernel"
192 0x000e0000-0x003c0000 : "JFFS2"
193 0x003c0000-0x003e0000 : "RedBoot config"
194 0x003e0000-0x00400000 : "FIS directory"
196 What's important here is the position of the partition we are interested in,
197 which is the third one.  Within Linux, this correspond to /dev/mtdblock2.
198 Therefore to boot Linux with the kernel and its root filesystem in flash, we
199 need this RedBoot command:
201         fis load "Linux kernel"
202         exec -b 0x100000 -l 0xc0000 -c "root=/dev/mtdblock2"
204 Of course other filesystems than JFFS might be used, like cramfs for example.
205 You might want to boot with a root filesystem over NFS, etc.  It is also
206 possible, and sometimes more convenient, to flash a filesystem directly from
207 within Linux while booted from a ramdisk or NFS.  The Linux MTD repository has
208 many tools to deal with flash memory as well, to erase it for example.  JFFS2
209 can then be mounted directly on a freshly erased partition and files can be
210 copied over directly.  Etc...
213 RedBoot scripting
214 -----------------
216 All the commands above aren't so useful if they have to be typed in every
217 time the Assabet is rebooted.  Therefore it's possible to automatize the boot
218 process using RedBoot's scripting capability.
220 For example, I use this to boot Linux with both the kernel and the ramdisk
221 images retrieved from a TFTP server on the network:
223 RedBoot> fconfig
224 Run script at boot: false true
225 Boot script:
226 Enter script, terminate with empty line
227 >> load zImage -r -b 0x100000
228 >> load ramdisk_ks.gz -r -b 0x800000
229 >> exec -b 0x100000 -l 0xc0000
231 Boot script timeout (1000ms resolution): 3
232 Use BOOTP for network configuration: true
233 GDB connection port: 9000
234 Network debug at boot time: false
235 Update RedBoot non-volatile configuration - are you sure (y/n)? y
237 Then, rebooting the Assabet is just a matter of waiting for the login prompt.
241 Nicolas Pitre
242 nico@fluxnic.net
243 June 12, 2001
246 Status of peripherals in -rmk tree (updated 14/10/2001)
247 -------------------------------------------------------
249 Assabet:
250  Serial ports:
251   Radio:                TX, RX, CTS, DSR, DCD, RI
252    PM:                  Not tested.
253   COM:                  TX, RX, CTS, DSR, DCD, RTS, DTR, PM
254    PM:                  Not tested.
255   I2C:                  Implemented, not fully tested.
256   L3:                   Fully tested, pass.
257    PM:                  Not tested.
259  Video:
260   LCD:                  Fully tested.  PM
261                         (LCD doesn't like being blanked with
262                          neponset connected)
263   Video out:            Not fully
265  Audio:
266   UDA1341:
267    Playback:            Fully tested, pass.
268    Record:              Implemented, not tested.
269    PM:                  Not tested.
271   UCB1200:
272    Audio play:          Implemented, not heavily tested.
273    Audio rec:           Implemented, not heavily tested.
274    Telco audio play:    Implemented, not heavily tested.
275    Telco audio rec:     Implemented, not heavily tested.
276    POTS control:        No
277    Touchscreen:         Yes
278    PM:                  Not tested.
280  Other:
281   PCMCIA:
282    LPE:                 Fully tested, pass.
283   USB:                  No
284   IRDA:
285    SIR:                 Fully tested, pass.
286    FIR:                 Fully tested, pass.
287    PM:                  Not tested.
289 Neponset:
290  Serial ports:
291   COM1,2:       TX, RX, CTS, DSR, DCD, RTS, DTR
292    PM:                  Not tested.
293   USB:                  Implemented, not heavily tested.
294   PCMCIA:               Implemented, not heavily tested.
295    PM:                  Not tested.
296   CF:                   Implemented, not heavily tested.
297    PM:                  Not tested.
299 More stuff can be found in the -np (Nicolas Pitre's) tree.