Commit | Line | Data |
---|---|---|
1da177e4 LT |
1 | The Intel Assabet (SA-1110 evaluation) board |
2 | ============================================ | |
3 | ||
4 | Please see: | |
0ea6e611 | 5 | http://developer.intel.com |
1da177e4 LT |
6 | |
7 | Also some notes from John G Dorsey <jd5q@andrew.cmu.edu>: | |
8 | http://www.cs.cmu.edu/~wearable/software/assabet.html | |
9 | ||
10 | ||
11 | Building the kernel | |
12 | ------------------- | |
13 | ||
14 | To build the kernel with current defaults: | |
15 | ||
16 | make assabet_config | |
17 | make oldconfig | |
18 | make zImage | |
19 | ||
20 | The resulting kernel image should be available in linux/arch/arm/boot/zImage. | |
21 | ||
22 | ||
23 | Installing a bootloader | |
24 | ----------------------- | |
25 | ||
26 | A couple of bootloaders able to boot Linux on Assabet are available: | |
27 | ||
c8c4b939 | 28 | BLOB (http://www.lartmaker.nl/lartware/blob/) |
1da177e4 LT |
29 | |
30 | BLOB is a bootloader used within the LART project. Some contributed | |
31 | patches were merged into BLOB to add support for Assabet. | |
32 | ||
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/) | |
36 | ||
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. | |
40 | ||
41 | RedBoot (http://sources.redhat.com/redboot/) | |
42 | ||
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. | |
46 | ||
47 | RedBoot is currently the recommended choice since it's the only one to have | |
48 | networking support, and is the most actively maintained. | |
49 | ||
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: | |
53 | ||
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/ | |
57 | ||
58 | Look for redboot-assabet*.tgz. Some installation infos are provided in | |
59 | redboot-assabet*.txt. | |
60 | ||
61 | ||
62 | Initial RedBoot configuration | |
63 | ----------------------------- | |
64 | ||
65 | The commands used here are explained in The RedBoot User's Guide available | |
0ea6e611 | 66 | on-line at http://sources.redhat.com/ecos/docs.html. |
1da177e4 LT |
67 | Please refer to it for explanations. |
68 | ||
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. | |
73 | ||
74 | To initialize the flash directory: | |
75 | ||
76 | fis init -f | |
77 | ||
78 | To initialize the non-volatile settings, like whether you want to use BOOTP or | |
79 | a static IP address, etc, use this command: | |
80 | ||
81 | fconfig -i | |
82 | ||
83 | ||
84 | Writing a kernel image into flash | |
85 | --------------------------------- | |
86 | ||
87 | First, the kernel image must be loaded into RAM. If you have the zImage file | |
88 | available on a TFTP server: | |
89 | ||
90 | load zImage -r -b 0x100000 | |
91 | ||
92 | If you rather want to use Y-Modem upload over the serial port: | |
93 | ||
94 | load -m ymodem -r -b 0x100000 | |
95 | ||
96 | To write it to flash: | |
97 | ||
98 | fis create "Linux kernel" -b 0x100000 -l 0xc0000 | |
99 | ||
100 | ||
101 | Booting the kernel | |
102 | ------------------ | |
103 | ||
104 | The kernel still requires a filesystem to boot. A ramdisk image can be loaded | |
105 | as follows: | |
106 | ||
107 | load ramdisk_image.gz -r -b 0x800000 | |
108 | ||
109 | Again, Y-Modem upload can be used instead of TFTP by replacing the file name | |
110 | by '-y ymodem'. | |
111 | ||
112 | Now the kernel can be retrieved from flash like this: | |
113 | ||
114 | fis load "Linux kernel" | |
115 | ||
116 | or loaded as described previously. To boot the kernel: | |
117 | ||
118 | exec -b 0x100000 -l 0xc0000 | |
119 | ||
120 | The ramdisk image could be stored into flash as well, but there are better | |
121 | solutions for on-flash filesystems as mentioned below. | |
122 | ||
123 | ||
124 | Using JFFS2 | |
125 | ----------- | |
126 | ||
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. | |
133 | ||
134 | For instance, a sample JFFS2 image can be retrieved from the same FTP sites | |
135 | mentioned below for the precompiled RedBoot image. | |
136 | ||
137 | To load this file: | |
138 | ||
139 | load sample_img.jffs2 -r -b 0x100000 | |
140 | ||
141 | The result should look like: | |
142 | ||
143 | RedBoot> load sample_img.jffs2 -r -b 0x100000 | |
144 | Raw file loaded 0x00100000-0x00377424 | |
145 | ||
146 | Now we must know the size of the unallocated flash: | |
147 | ||
148 | fis free | |
149 | ||
150 | Result: | |
151 | ||
152 | RedBoot> fis free | |
153 | 0x500E0000 .. 0x503C0000 | |
154 | ||
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. | |
158 | ||
159 | We must determine some values: | |
160 | ||
161 | size of unallocated flash: 0x503c0000 - 0x500e0000 = 0x2e0000 | |
162 | size of the filesystem image: 0x00377424 - 0x00100000 = 0x277424 | |
163 | ||
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: | |
166 | ||
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 | |
171 | ||
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: | |
175 | ||
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 | |
183 | ||
184 | However Linux should display something like: | |
185 | ||
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" | |
195 | ||
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: | |
200 | ||
201 | fis load "Linux kernel" | |
202 | exec -b 0x100000 -l 0xc0000 -c "root=/dev/mtdblock2" | |
203 | ||
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... | |
211 | ||
212 | ||
213 | RedBoot scripting | |
214 | ----------------- | |
215 | ||
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. | |
219 | ||
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: | |
222 | ||
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 | |
230 | >> | |
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 | |
236 | ||
237 | Then, rebooting the Assabet is just a matter of waiting for the login prompt. | |
238 | ||
239 | ||
240 | ||
241 | Nicolas Pitre | |
2f82af08 | 242 | nico@fluxnic.net |
1da177e4 LT |
243 | June 12, 2001 |
244 | ||
245 | ||
246 | Status of peripherals in -rmk tree (updated 14/10/2001) | |
247 | ------------------------------------------------------- | |
248 | ||
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. | |
258 | ||
259 | Video: | |
260 | LCD: Fully tested. PM | |
261 | (LCD doesn't like being blanked with | |
262 | neponset connected) | |
263 | Video out: Not fully | |
264 | ||
265 | Audio: | |
266 | UDA1341: | |
267 | Playback: Fully tested, pass. | |
268 | Record: Implemented, not tested. | |
269 | PM: Not tested. | |
270 | ||
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. | |
279 | ||
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. | |
288 | ||
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. | |
298 | ||
299 | More stuff can be found in the -np (Nicolas Pitre's) tree. | |
300 |