Contents of /alx-src/trunk/kernel26-alx/linux/Documentation/arm/SA1100/Assabet
Parent Directory | Revision Log
Revision 628 -
(show annotations)
(download)
Wed Mar 4 10:48:58 2009 UTC (15 years, 2 months ago) by niro
File size: 9204 byte(s)
Wed Mar 4 10:48:58 2009 UTC (15 years, 2 months ago) by niro
File size: 9204 byte(s)
import linux sources based on 2.6.12-alx-r9: -using linux-2.6.12.6 -using 2.6.12-ck6 patch set -using fbsplash-0.9.2-r3 -using vesafb-tng-0.9-rc7 -using squashfs-2.2 -added cddvd-cmdfilter-drop.patch as ck dropped it -added via-epia-dri (cle266) patch -added zd1211-svn-32 wlan driver (http://zd1211.ath.cx/download/) -added debian patches to zd1211 for wep256 etc
1 | The Intel Assabet (SA-1110 evaluation) board |
2 | ============================================ |
3 | |
4 | Please see: |
5 | http://developer.intel.com/design/strong/quicklist/eval-plat/sa-1110.htm |
6 | http://developer.intel.com/design/strong/guides/278278.htm |
7 | |
8 | Also some notes from John G Dorsey <jd5q@andrew.cmu.edu>: |
9 | http://www.cs.cmu.edu/~wearable/software/assabet.html |
10 | |
11 | |
12 | Building the kernel |
13 | ------------------- |
14 | |
15 | To build the kernel with current defaults: |
16 | |
17 | make assabet_config |
18 | make oldconfig |
19 | make zImage |
20 | |
21 | The resulting kernel image should be available in linux/arch/arm/boot/zImage. |
22 | |
23 | |
24 | Installing a bootloader |
25 | ----------------------- |
26 | |
27 | A couple of bootloaders able to boot Linux on Assabet are available: |
28 | |
29 | BLOB (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 | |
34 | Compaq'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 | |
42 | RedBoot (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 | |
48 | RedBoot is currently the recommended choice since it's the only one to have |
49 | networking support, and is the most actively maintained. |
50 | |
51 | Brief examples on how to boot Linux with RedBoot are shown below. But first |
52 | you need to have RedBoot installed in your flash memory. A known to work |
53 | precompiled RedBoot binary is available from the following location: |
54 | |
55 | ftp://ftp.netwinder.org/users/n/nico/ |
56 | ftp://ftp.arm.linux.org.uk/pub/linux/arm/people/nico/ |
57 | ftp://ftp.handhelds.org/pub/linux/arm/sa-1100-patches/ |
58 | |
59 | Look for redboot-assabet*.tgz. Some installation infos are provided in |
60 | redboot-assabet*.txt. |
61 | |
62 | |
63 | Initial RedBoot configuration |
64 | ----------------------------- |
65 | |
66 | The commands used here are explained in The RedBoot User's Guide available |
67 | on-line at http://sources.redhat.com/ecos/docs-latest/redboot/redboot.html. |
68 | Please refer to it for explanations. |
69 | |
70 | If you have a CF network card (my Assabet kit contained a CF+ LP-E from |
71 | Socket Communications Inc.), you should strongly consider using it for TFTP |
72 | file transfers. You must insert it before RedBoot runs since it can't detect |
73 | it dynamically. |
74 | |
75 | To initialize the flash directory: |
76 | |
77 | fis init -f |
78 | |
79 | To initialize the non-volatile settings, like whether you want to use BOOTP or |
80 | a static IP address, etc, use this command: |
81 | |
82 | fconfig -i |
83 | |
84 | |
85 | Writing a kernel image into flash |
86 | --------------------------------- |
87 | |
88 | First, the kernel image must be loaded into RAM. If you have the zImage file |
89 | available on a TFTP server: |
90 | |
91 | load zImage -r -b 0x100000 |
92 | |
93 | If you rather want to use Y-Modem upload over the serial port: |
94 | |
95 | load -m ymodem -r -b 0x100000 |
96 | |
97 | To write it to flash: |
98 | |
99 | fis create "Linux kernel" -b 0x100000 -l 0xc0000 |
100 | |
101 | |
102 | Booting the kernel |
103 | ------------------ |
104 | |
105 | The kernel still requires a filesystem to boot. A ramdisk image can be loaded |
106 | as follows: |
107 | |
108 | load ramdisk_image.gz -r -b 0x800000 |
109 | |
110 | Again, Y-Modem upload can be used instead of TFTP by replacing the file name |
111 | by '-y ymodem'. |
112 | |
113 | Now the kernel can be retrieved from flash like this: |
114 | |
115 | fis load "Linux kernel" |
116 | |
117 | or loaded as described previously. To boot the kernel: |
118 | |
119 | exec -b 0x100000 -l 0xc0000 |
120 | |
121 | The ramdisk image could be stored into flash as well, but there are better |
122 | solutions for on-flash filesystems as mentioned below. |
123 | |
124 | |
125 | Using JFFS2 |
126 | ----------- |
127 | |
128 | Using JFFS2 (the Second Journalling Flash File System) is probably the most |
129 | convenient way to store a writable filesystem into flash. JFFS2 is used in |
130 | conjunction with the MTD layer which is responsible for low-level flash |
131 | management. More information on the Linux MTD can be found on-line at: |
132 | http://www.linux-mtd.infradead.org/. A JFFS howto with some infos about |
133 | creating JFFS/JFFS2 images is available from the same site. |
134 | |
135 | For instance, a sample JFFS2 image can be retrieved from the same FTP sites |
136 | mentioned below for the precompiled RedBoot image. |
137 | |
138 | To load this file: |
139 | |
140 | load sample_img.jffs2 -r -b 0x100000 |
141 | |
142 | The result should look like: |
143 | |
144 | RedBoot> load sample_img.jffs2 -r -b 0x100000 |
145 | Raw file loaded 0x00100000-0x00377424 |
146 | |
147 | Now we must know the size of the unallocated flash: |
148 | |
149 | fis free |
150 | |
151 | Result: |
152 | |
153 | RedBoot> fis free |
154 | 0x500E0000 .. 0x503C0000 |
155 | |
156 | The values above may be different depending on the size of the filesystem and |
157 | the type of flash. See their usage below as an example and take care of |
158 | substituting yours appropriately. |
159 | |
160 | We must determine some values: |
161 | |
162 | size of unallocated flash: 0x503c0000 - 0x500e0000 = 0x2e0000 |
163 | size of the filesystem image: 0x00377424 - 0x00100000 = 0x277424 |
164 | |
165 | We want to fit the filesystem image of course, but we also want to give it all |
166 | the 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 | |
173 | Now the filesystem is associated to a MTD "partition" once Linux has discovered |
174 | what they are in the boot process. From Redboot, the 'fis list' command |
175 | displays them: |
176 | |
177 | RedBoot> fis list |
178 | Name FLASH addr Mem addr Length Entry point |
179 | RedBoot 0x50000000 0x50000000 0x00020000 0x00000000 |
180 | RedBoot config 0x503C0000 0x503C0000 0x00020000 0x00000000 |
181 | FIS directory 0x503E0000 0x503E0000 0x00020000 0x00000000 |
182 | Linux kernel 0x50020000 0x00100000 0x000C0000 0x00000000 |
183 | JFFS2 0x500E0000 0x500E0000 0x002E0000 0x00000000 |
184 | |
185 | However Linux should display something like: |
186 | |
187 | SA1100 flash: probing 32-bit flash bus |
188 | SA1100 flash: Found 2 x16 devices at 0x0 in 32-bit mode |
189 | Using RedBoot partition definition |
190 | Creating 5 MTD partitions on "SA1100 flash": |
191 | 0x00000000-0x00020000 : "RedBoot" |
192 | 0x00020000-0x000e0000 : "Linux kernel" |
193 | 0x000e0000-0x003c0000 : "JFFS2" |
194 | 0x003c0000-0x003e0000 : "RedBoot config" |
195 | 0x003e0000-0x00400000 : "FIS directory" |
196 | |
197 | What's important here is the position of the partition we are interested in, |
198 | which is the third one. Within Linux, this correspond to /dev/mtdblock2. |
199 | Therefore to boot Linux with the kernel and its root filesystem in flash, we |
200 | need this RedBoot command: |
201 | |
202 | fis load "Linux kernel" |
203 | exec -b 0x100000 -l 0xc0000 -c "root=/dev/mtdblock2" |
204 | |
205 | Of course other filesystems than JFFS might be used, like cramfs for example. |
206 | You might want to boot with a root filesystem over NFS, etc. It is also |
207 | possible, and sometimes more convenient, to flash a filesystem directly from |
208 | within Linux while booted from a ramdisk or NFS. The Linux MTD repository has |
209 | many tools to deal with flash memory as well, to erase it for example. JFFS2 |
210 | can then be mounted directly on a freshly erased partition and files can be |
211 | copied over directly. Etc... |
212 | |
213 | |
214 | RedBoot scripting |
215 | ----------------- |
216 | |
217 | All the commands above aren't so useful if they have to be typed in every |
218 | time the Assabet is rebooted. Therefore it's possible to automatize the boot |
219 | process using RedBoot's scripting capability. |
220 | |
221 | For example, I use this to boot Linux with both the kernel and the ramdisk |
222 | images retrieved from a TFTP server on the network: |
223 | |
224 | RedBoot> fconfig |
225 | Run script at boot: false true |
226 | Boot script: |
227 | Enter 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 | >> |
232 | Boot script timeout (1000ms resolution): 3 |
233 | Use BOOTP for network configuration: true |
234 | GDB connection port: 9000 |
235 | Network debug at boot time: false |
236 | Update RedBoot non-volatile configuration - are you sure (y/n)? y |
237 | |
238 | Then, rebooting the Assabet is just a matter of waiting for the login prompt. |
239 | |
240 | |
241 | |
242 | Nicolas Pitre |
243 | nico@cam.org |
244 | June 12, 2001 |
245 | |
246 | |
247 | Status of peripherals in -rmk tree (updated 14/10/2001) |
248 | ------------------------------------------------------- |
249 | |
250 | Assabet: |
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 | |
290 | Neponset: |
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 | |
300 | More stuff can be found in the -np (Nicolas Pitre's) tree. |
301 |