Documentation/arm/SA1100/Assabet

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