diff options
Diffstat (limited to 'Documentation/arm/SA1100/Assabet')
-rw-r--r-- | Documentation/arm/SA1100/Assabet | 301 |
1 files changed, 301 insertions, 0 deletions
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 @@ | |||
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 | |||