Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 1 | The Intel Assabet (SA-1110 evaluation) board |
| 2 | ============================================ |
| 3 | |
| 4 | Please see: |
Justin P. Mattock | 0ea6e61 | 2010-07-23 20:51:24 -0700 | [diff] [blame] | 5 | http://developer.intel.com |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 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 | |
Erik Mouw | c8c4b93 | 2006-03-27 15:32:30 +0100 | [diff] [blame] | 28 | BLOB (http://www.lartmaker.nl/lartware/blob/) |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 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 |
Justin P. Mattock | 0ea6e61 | 2010-07-23 20:51:24 -0700 | [diff] [blame] | 66 | on-line at http://sources.redhat.com/ecos/docs.html. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 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 |
Nicolas Pitre | 2f82af0 | 2009-09-14 03:25:28 -0400 | [diff] [blame] | 242 | nico@fluxnic.net |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 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 | |