mirror of
https://github.com/edk2-porting/linux-next.git
synced 2024-12-23 12:43:55 +08:00
0ea6e61122
Below you will find an updated version from the original series bunching all patches into one big patch updating broken web addresses that are located in Documentation/* Some of the addresses date as far far back as 1995 etc... so searching became a bit difficult, the best way to deal with these is to use web.archive.org to locate these addresses that are outdated. Now there are also some addresses pointing to .spec files some are located, but some(after searching on the companies site)where still no where to be found. In this case I just changed the address to the company site this way the users can contact the company and they can locate them for the users. Signed-off-by: Justin P. Mattock <justinmattock@gmail.com> Signed-off-by: Thomas Weber <weber@corscience.de> Signed-off-by: Mike Frysinger <vapier.adi@gmail.com> Cc: Paulo Marques <pmarques@grupopie.com> Cc: Randy Dunlap <rdunlap@xenotime.net> Cc: Michael Neuling <mikey@neuling.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
301 lines
8.9 KiB
Plaintext
301 lines
8.9 KiB
Plaintext
The Intel Assabet (SA-1110 evaluation) board
|
|
============================================
|
|
|
|
Please see:
|
|
http://developer.intel.com
|
|
|
|
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.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.
|
|
|