 2f82af08fc
			
		
	
	
	2f82af08fc
	
	
	
		
			
			Due to problems at cam.org, my nico@cam.org email address is no longer valid. FRom now on, nico@fluxnic.net should be used instead. Signed-off-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
		
			
				
	
	
		
			301 lines
		
	
	
	
		
			9 KiB
			
		
	
	
	
		
			Text
		
	
	
	
	
	
			
		
		
	
	
			301 lines
		
	
	
	
		
			9 KiB
			
		
	
	
	
		
			Text
		
	
	
	
	
	
| The Intel Assabet (SA-1110 evaluation) board
 | |
| ============================================
 | |
| 
 | |
| Please see:
 | |
| http://developer.intel.com/design/strong/quicklist/eval-plat/sa-1110.htm
 | |
| http://developer.intel.com/design/strong/guides/278278.htm
 | |
| 
 | |
| Also some notes from John G Dorsey <jd5q@andrew.cmu.edu>:
 | |
| http://www.cs.cmu.edu/~wearable/software/assabet.html
 | |
| 
 | |
| 
 | |
| Building the kernel
 | |
| -------------------
 | |
| 
 | |
| To build the kernel with current defaults:
 | |
| 
 | |
| 	make assabet_config
 | |
| 	make oldconfig
 | |
| 	make zImage
 | |
| 
 | |
| The resulting kernel image should be available in linux/arch/arm/boot/zImage.
 | |
| 
 | |
| 
 | |
| Installing a bootloader
 | |
| -----------------------
 | |
| 
 | |
| A couple of bootloaders able to boot Linux on Assabet are available:
 | |
| 
 | |
| BLOB (http://www.lartmaker.nl/lartware/blob/)
 | |
| 
 | |
|    BLOB is a bootloader used within the LART project.  Some contributed
 | |
|    patches were merged into BLOB to add support for Assabet.
 | |
| 
 | |
| Compaq's Bootldr + John Dorsey's patch for Assabet support
 | |
| (http://www.handhelds.org/Compaq/bootldr.html)
 | |
| (http://www.wearablegroup.org/software/bootldr/)
 | |
| 
 | |
|    Bootldr is the bootloader developed by Compaq for the iPAQ Pocket PC.
 | |
|    John Dorsey has produced add-on patches to add support for Assabet and
 | |
|    the JFFS filesystem.
 | |
| 
 | |
| RedBoot (http://sources.redhat.com/redboot/)
 | |
| 
 | |
|    RedBoot is a bootloader developed by Red Hat based on the eCos RTOS
 | |
|    hardware abstraction layer.  It supports Assabet amongst many other
 | |
|    hardware platforms.
 | |
| 
 | |
| RedBoot is currently the recommended choice since it's the only one to have
 | |
| networking support, and is the most actively maintained.
 | |
| 
 | |
| Brief examples on how to boot Linux with RedBoot are shown below.  But first
 | |
| you need to have RedBoot installed in your flash memory.  A known to work
 | |
| precompiled RedBoot binary is available from the following location:
 | |
| 
 | |
| ftp://ftp.netwinder.org/users/n/nico/
 | |
| ftp://ftp.arm.linux.org.uk/pub/linux/arm/people/nico/
 | |
| ftp://ftp.handhelds.org/pub/linux/arm/sa-1100-patches/
 | |
| 
 | |
| Look for redboot-assabet*.tgz.  Some installation infos are provided in
 | |
| redboot-assabet*.txt.
 | |
| 
 | |
| 
 | |
| Initial RedBoot configuration
 | |
| -----------------------------
 | |
| 
 | |
| The commands used here are explained in The RedBoot User's Guide available
 | |
| on-line at http://sources.redhat.com/ecos/docs-latest/redboot/redboot.html.
 | |
| Please refer to it for explanations.
 | |
| 
 | |
| If you have a CF network card (my Assabet kit contained a CF+ LP-E from
 | |
| Socket Communications Inc.), you should strongly consider using it for TFTP
 | |
| file transfers.  You must insert it before RedBoot runs since it can't detect
 | |
| it dynamically.
 | |
| 
 | |
| To initialize the flash directory:
 | |
| 
 | |
| 	fis init -f
 | |
| 
 | |
| To initialize the non-volatile settings, like whether you want to use BOOTP or
 | |
| a static IP address, etc, use this command:
 | |
| 
 | |
| 	fconfig -i
 | |
| 
 | |
| 
 | |
| Writing a kernel image into flash
 | |
| ---------------------------------
 | |
| 
 | |
| First, the kernel image must be loaded into RAM.  If you have the zImage file
 | |
| available on a TFTP server:
 | |
| 
 | |
| 	load zImage -r -b 0x100000
 | |
| 
 | |
| If you rather want to use Y-Modem upload over the serial port:
 | |
| 
 | |
| 	load -m ymodem -r -b 0x100000
 | |
| 
 | |
| To write it to flash:
 | |
| 
 | |
| 	fis create "Linux kernel" -b 0x100000 -l 0xc0000
 | |
| 
 | |
| 
 | |
| Booting the kernel
 | |
| ------------------
 | |
| 
 | |
| The kernel still requires a filesystem to boot.  A ramdisk image can be loaded
 | |
| as follows:
 | |
| 
 | |
| 	load ramdisk_image.gz -r -b 0x800000
 | |
| 
 | |
| Again, Y-Modem upload can be used instead of TFTP by replacing the file name
 | |
| by '-y ymodem'.
 | |
| 
 | |
| Now the kernel can be retrieved from flash like this:
 | |
| 
 | |
| 	fis load "Linux kernel"
 | |
| 
 | |
| or loaded as described previously.  To boot the kernel:
 | |
| 
 | |
| 	exec -b 0x100000 -l 0xc0000
 | |
| 
 | |
| The ramdisk image could be stored into flash as well, but there are better
 | |
| solutions for on-flash filesystems as mentioned below.
 | |
| 
 | |
| 
 | |
| Using JFFS2
 | |
| -----------
 | |
| 
 | |
| Using JFFS2 (the Second Journalling Flash File System) is probably the most
 | |
| convenient way to store a writable filesystem into flash.  JFFS2 is used in
 | |
| conjunction with the MTD layer which is responsible for low-level flash
 | |
| management.  More information on the Linux MTD can be found on-line at:
 | |
| http://www.linux-mtd.infradead.org/.  A JFFS howto with some infos about
 | |
| creating JFFS/JFFS2 images is available from the same site.
 | |
| 
 | |
| For instance, a sample JFFS2 image can be retrieved from the same FTP sites
 | |
| mentioned below for the precompiled RedBoot image.
 | |
| 
 | |
| To load this file:
 | |
| 
 | |
| 	load sample_img.jffs2 -r -b 0x100000
 | |
| 
 | |
| The result should look like:
 | |
| 
 | |
| RedBoot> load sample_img.jffs2 -r -b 0x100000
 | |
| Raw file loaded 0x00100000-0x00377424
 | |
| 
 | |
| Now we must know the size of the unallocated flash:
 | |
| 
 | |
| 	fis free
 | |
| 
 | |
| Result:
 | |
| 
 | |
| RedBoot> fis free
 | |
|   0x500E0000 .. 0x503C0000
 | |
| 
 | |
| The values above may be different depending on the size of the filesystem and
 | |
| the type of flash.  See their usage below as an example and take care of
 | |
| substituting yours appropriately.
 | |
| 
 | |
| We must determine some values:
 | |
| 
 | |
| size of unallocated flash:	0x503c0000 - 0x500e0000 = 0x2e0000
 | |
| size of the filesystem image:	0x00377424 - 0x00100000 = 0x277424
 | |
| 
 | |
| We want to fit the filesystem image of course, but we also want to give it all
 | |
| the remaining flash space as well.  To write it:
 | |
| 
 | |
| 	fis unlock -f 0x500E0000 -l 0x2e0000
 | |
| 	fis erase -f 0x500E0000 -l 0x2e0000
 | |
| 	fis write -b 0x100000 -l 0x277424 -f 0x500E0000
 | |
| 	fis create "JFFS2" -n -f 0x500E0000 -l 0x2e0000
 | |
| 
 | |
| Now the filesystem is associated to a MTD "partition" once Linux has discovered
 | |
| what they are in the boot process.  From Redboot, the 'fis list' command
 | |
| displays them:
 | |
| 
 | |
| RedBoot> fis list
 | |
| Name              FLASH addr  Mem addr    Length      Entry point
 | |
| RedBoot           0x50000000  0x50000000  0x00020000  0x00000000
 | |
| RedBoot config    0x503C0000  0x503C0000  0x00020000  0x00000000
 | |
| FIS directory     0x503E0000  0x503E0000  0x00020000  0x00000000
 | |
| Linux kernel      0x50020000  0x00100000  0x000C0000  0x00000000
 | |
| JFFS2             0x500E0000  0x500E0000  0x002E0000  0x00000000
 | |
| 
 | |
| However Linux should display something like:
 | |
| 
 | |
| SA1100 flash: probing 32-bit flash bus
 | |
| SA1100 flash: Found 2 x16 devices at 0x0 in 32-bit mode
 | |
| Using RedBoot partition definition
 | |
| Creating 5 MTD partitions on "SA1100 flash":
 | |
| 0x00000000-0x00020000 : "RedBoot"
 | |
| 0x00020000-0x000e0000 : "Linux kernel"
 | |
| 0x000e0000-0x003c0000 : "JFFS2"
 | |
| 0x003c0000-0x003e0000 : "RedBoot config"
 | |
| 0x003e0000-0x00400000 : "FIS directory"
 | |
| 
 | |
| What's important here is the position of the partition we are interested in,
 | |
| which is the third one.  Within Linux, this correspond to /dev/mtdblock2.
 | |
| Therefore to boot Linux with the kernel and its root filesystem in flash, we
 | |
| need this RedBoot command:
 | |
| 
 | |
| 	fis load "Linux kernel"
 | |
| 	exec -b 0x100000 -l 0xc0000 -c "root=/dev/mtdblock2"
 | |
| 
 | |
| Of course other filesystems than JFFS might be used, like cramfs for example.
 | |
| You might want to boot with a root filesystem over NFS, etc.  It is also
 | |
| possible, and sometimes more convenient, to flash a filesystem directly from
 | |
| within Linux while booted from a ramdisk or NFS.  The Linux MTD repository has
 | |
| many tools to deal with flash memory as well, to erase it for example.  JFFS2
 | |
| can then be mounted directly on a freshly erased partition and files can be
 | |
| copied over directly.  Etc...
 | |
| 
 | |
| 
 | |
| RedBoot scripting
 | |
| -----------------
 | |
| 
 | |
| All the commands above aren't so useful if they have to be typed in every
 | |
| time the Assabet is rebooted.  Therefore it's possible to automatize the boot
 | |
| process using RedBoot's scripting capability.
 | |
| 
 | |
| For example, I use this to boot Linux with both the kernel and the ramdisk
 | |
| images retrieved from a TFTP server on the network:
 | |
| 
 | |
| RedBoot> fconfig
 | |
| Run script at boot: false true
 | |
| Boot script:
 | |
| Enter script, terminate with empty line
 | |
| >> load zImage -r -b 0x100000
 | |
| >> load ramdisk_ks.gz -r -b 0x800000
 | |
| >> exec -b 0x100000 -l 0xc0000
 | |
| >>
 | |
| Boot script timeout (1000ms resolution): 3
 | |
| Use BOOTP for network configuration: true
 | |
| GDB connection port: 9000
 | |
| Network debug at boot time: false
 | |
| Update RedBoot non-volatile configuration - are you sure (y/n)? y
 | |
| 
 | |
| Then, rebooting the Assabet is just a matter of waiting for the login prompt.
 | |
| 
 | |
| 
 | |
| 
 | |
| Nicolas Pitre
 | |
| nico@fluxnic.net
 | |
| June 12, 2001
 | |
| 
 | |
| 
 | |
| Status of peripherals in -rmk tree (updated 14/10/2001)
 | |
| -------------------------------------------------------
 | |
| 
 | |
| Assabet:
 | |
|  Serial ports:
 | |
|   Radio:		TX, RX, CTS, DSR, DCD, RI
 | |
|    PM:			Not tested.
 | |
|   COM:			TX, RX, CTS, DSR, DCD, RTS, DTR, PM
 | |
|    PM:			Not tested.
 | |
|   I2C:			Implemented, not fully tested.
 | |
|   L3:			Fully tested, pass.
 | |
|    PM:			Not tested.
 | |
| 
 | |
|  Video:
 | |
|   LCD:			Fully tested.  PM
 | |
| 			(LCD doesn't like being blanked with
 | |
| 			 neponset connected)
 | |
|   Video out:		Not fully
 | |
| 
 | |
|  Audio:
 | |
|   UDA1341:
 | |
|    Playback:		Fully tested, pass.
 | |
|    Record:		Implemented, not tested.
 | |
|    PM:			Not tested.
 | |
| 
 | |
|   UCB1200:
 | |
|    Audio play:		Implemented, not heavily tested.
 | |
|    Audio rec:		Implemented, not heavily tested.
 | |
|    Telco audio play:	Implemented, not heavily tested.
 | |
|    Telco audio rec:	Implemented, not heavily tested.
 | |
|    POTS control:	No
 | |
|    Touchscreen:		Yes
 | |
|    PM:			Not tested.
 | |
| 
 | |
|  Other:
 | |
|   PCMCIA:
 | |
|    LPE:			Fully tested, pass.
 | |
|   USB:			No
 | |
|   IRDA:
 | |
|    SIR:			Fully tested, pass.
 | |
|    FIR:			Fully tested, pass.
 | |
|    PM:			Not tested.
 | |
| 
 | |
| Neponset:
 | |
|  Serial ports:
 | |
|   COM1,2:	TX, RX, CTS, DSR, DCD, RTS, DTR
 | |
|    PM:			Not tested.
 | |
|   USB:			Implemented, not heavily tested.
 | |
|   PCMCIA:		Implemented, not heavily tested.
 | |
|    PM:			Not tested.
 | |
|   CF:			Implemented, not heavily tested.
 | |
|    PM:			Not tested.
 | |
| 
 | |
| More stuff can be found in the -np (Nicolas Pitre's) tree.
 | |
| 
 |