Documentation/arm/sa1100/assabet.rst

   1 ============================================
   2 The Intel Assabet (SA-1110 evaluation) board
   3 ============================================
   4
   5 Please see:
   6 http://developer.intel.com
   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.lartmaker.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.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 automate 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@fluxnic.net
 244
 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
 264    (LCD doesn't like being blanked with neponset connected)
 265
 266   - Video out:          Not fully
 267
 268  Audio:
 269   UDA1341:
 270   -  Playback:          Fully tested, pass.
 271   -  Record:            Implemented, not tested.
 272   -  PM:                        Not tested.
 273
 274   UCB1200:
 275   -  Audio play:        Implemented, not heavily tested.
 276   -  Audio rec:         Implemented, not heavily tested.
 277   -  Telco audio play:  Implemented, not heavily tested.
 278   -  Telco audio rec:   Implemented, not heavily tested.
 279   -  POTS control:      No
 280   -  Touchscreen:       Yes
 281   -  PM:                Not tested.
 282
 283  Other:
 284   - PCMCIA:
 285   - LPE:                Fully tested, pass.
 286   - USB:                No
 287   - IRDA:
 288   - SIR:                Fully tested, pass.
 289   - FIR:                Fully tested, pass.
 290   - PM:                 Not tested.
 291
 292 Neponset:
 293  Serial ports:
 294   - COM1,2:             TX, RX, CTS, DSR, DCD, RTS, DTR
 295   - PM:                 Not tested.
 296   - USB:                Implemented, not heavily tested.
 297   - PCMCIA:             Implemented, not heavily 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.