Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
此提交包含在：
Linus Torvalds
@@ -0,0 +1,43 @@
|
||||
ADS Bitsy Single Board Computer
|
||||
(It is different from Bitsy(iPAQ) of Compaq)
|
||||
|
||||
For more details, contact Applied Data Systems or see
|
||||
http://www.applieddata.net/products.html
|
||||
|
||||
The Linux support for this product has been provided by
|
||||
Woojung Huh <whuh@applieddata.net>
|
||||
|
||||
Use 'make adsbitsy_config' before any 'make config'.
|
||||
This will set up defaults for ADS Bitsy support.
|
||||
|
||||
The kernel zImage is linked to be loaded and executed at 0xc0400000.
|
||||
|
||||
Linux can be used with the ADS BootLoader that ships with the
|
||||
newer rev boards. See their documentation on how to load Linux.
|
||||
|
||||
Supported peripherals:
|
||||
- SA1100 LCD frame buffer (8/16bpp...sort of)
|
||||
- SA1111 USB Master
|
||||
- SA1100 serial port
|
||||
- pcmcia, compact flash
|
||||
- touchscreen(ucb1200)
|
||||
- console on LCD screen
|
||||
- serial ports (ttyS[0-2])
|
||||
- ttyS0 is default for serial console
|
||||
|
||||
To do:
|
||||
- everything else! :-)
|
||||
|
||||
Notes:
|
||||
|
||||
- The flash on board is divided into 3 partitions.
|
||||
You should be careful to use flash on board.
|
||||
It's partition is different from GraphicsClient Plus and GraphicsMaster
|
||||
|
||||
- 16bpp mode requires a different cable than what ships with the board.
|
||||
Contact ADS or look through the manual to wire your own. Currently,
|
||||
if you compile with 16bit mode support and switch into a lower bpp
|
||||
mode, the timing is off so the image is corrupted. This will be
|
||||
fixed soon.
|
||||
|
||||
Any contribution can be sent to nico@cam.org and will be greatly welcome!
|
||||
301
Documentation/arm/SA1100/Assabet
一般檔案
301
Documentation/arm/SA1100/Assabet
一般檔案
@@ -0,0 +1,301 @@
|
||||
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.lart.tudelft.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@cam.org
|
||||
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.
|
||||
|
||||
66
Documentation/arm/SA1100/Brutus
一般檔案
66
Documentation/arm/SA1100/Brutus
一般檔案
@@ -0,0 +1,66 @@
|
||||
Brutus is an evaluation platform for the SA1100 manufactured by Intel.
|
||||
For more details, see:
|
||||
|
||||
http://developer.intel.com/design/strong/applnots/sa1100lx/getstart.htm
|
||||
|
||||
To compile for Brutus, you must issue the following commands:
|
||||
|
||||
make brutus_config
|
||||
make config
|
||||
[accept all the defaults]
|
||||
make zImage
|
||||
|
||||
The resulting kernel will end up in linux/arch/arm/boot/zImage. This file
|
||||
must be loaded at 0xc0008000 in Brutus's memory and execution started at
|
||||
0xc0008000 as well with the value of registers r0 = 0 and r1 = 16 upon
|
||||
entry.
|
||||
|
||||
But prior to execute the kernel, a ramdisk image must also be loaded in
|
||||
memory. Use memory address 0xd8000000 for this. Note that the file
|
||||
containing the (compressed) ramdisk image must not exceed 4 MB.
|
||||
|
||||
Typically, you'll need angelboot to load the kernel.
|
||||
The following angelboot.opt file should be used:
|
||||
|
||||
----- begin angelboot.opt -----
|
||||
base 0xc0008000
|
||||
entry 0xc0008000
|
||||
r0 0x00000000
|
||||
r1 0x00000010
|
||||
device /dev/ttyS0
|
||||
options "9600 8N1"
|
||||
baud 115200
|
||||
otherfile ramdisk_img.gz
|
||||
otherbase 0xd8000000
|
||||
----- end angelboot.opt -----
|
||||
|
||||
Then load the kernel and ramdisk with:
|
||||
|
||||
angelboot -f angelboot.opt zImage
|
||||
|
||||
The first Brutus serial port (assumed to be linked to /dev/ttyS0 on your
|
||||
host PC) is used by angel to load the kernel and ramdisk image. The serial
|
||||
console is provided through the second Brutus serial port. To access it,
|
||||
you may use minicom configured with /dev/ttyS1, 9600 baud, 8N1, no flow
|
||||
control.
|
||||
|
||||
Currently supported:
|
||||
- RS232 serial ports
|
||||
- audio output
|
||||
- LCD screen
|
||||
- keyboard
|
||||
|
||||
The actual Brutus support may not be complete without extra patches.
|
||||
If such patches exist, they should be found from
|
||||
ftp.netwinder.org/users/n/nico.
|
||||
|
||||
A full PCMCIA support is still missing, although it's possible to hack
|
||||
some drivers in order to drive already inserted cards at boot time with
|
||||
little modifications.
|
||||
|
||||
Any contribution is welcome.
|
||||
|
||||
Please send patches to nico@cam.org
|
||||
|
||||
Have Fun !
|
||||
|
||||
29
Documentation/arm/SA1100/CERF
一般檔案
29
Documentation/arm/SA1100/CERF
一般檔案
@@ -0,0 +1,29 @@
|
||||
*** The StrongARM version of the CerfBoard/Cube has been discontinued ***
|
||||
|
||||
The Intrinsyc CerfBoard is a StrongARM 1110-based computer on a board
|
||||
that measures approximately 2" square. It includes an Ethernet
|
||||
controller, an RS232-compatible serial port, a USB function port, and
|
||||
one CompactFlash+ slot on the back. Pictures can be found at the
|
||||
Intrinsyc website, http://www.intrinsyc.com.
|
||||
|
||||
This document describes the support in the Linux kernel for the
|
||||
Intrinsyc CerfBoard.
|
||||
|
||||
Supported in this version:
|
||||
- CompactFlash+ slot (select PCMCIA in General Setup and any options
|
||||
that may be required)
|
||||
- Onboard Crystal CS8900 Ethernet controller (Cerf CS8900A support in
|
||||
Network Devices)
|
||||
- Serial ports with a serial console (hardcoded to 38400 8N1)
|
||||
|
||||
In order to get this kernel onto your Cerf, you need a server that runs
|
||||
both BOOTP and TFTP. Detailed instructions should have come with your
|
||||
evaluation kit on how to use the bootloader. This series of commands
|
||||
will suffice:
|
||||
|
||||
make ARCH=arm CROSS_COMPILE=arm-linux- cerfcube_defconfig
|
||||
make ARCH=arm CROSS_COMPILE=arm-linux- zImage
|
||||
make ARCH=arm CROSS_COMPILE=arm-linux- modules
|
||||
cp arch/arm/boot/zImage <TFTP directory>
|
||||
|
||||
support@intrinsyc.com
|
||||
@@ -0,0 +1,21 @@
|
||||
Freebird-1.1 is produced by Legned(C) ,Inc.
|
||||
(http://www.legend.com.cn)
|
||||
and software/linux mainatined by Coventive(C),Inc.
|
||||
(http://www.coventive.com)
|
||||
|
||||
Based on the Nicolas's strongarm kernel tree.
|
||||
|
||||
===============================================================
|
||||
Maintainer:
|
||||
|
||||
Chester Kuo <chester@coventive.com>
|
||||
<chester@linux.org.tw>
|
||||
|
||||
Author :
|
||||
Tim wu <timwu@coventive.com>
|
||||
CIH <cih@coventive.com>
|
||||
Eric Peng <ericpeng@coventive.com>
|
||||
Jeff Lee <jeff_lee@coventive.com>
|
||||
Allen Cheng
|
||||
Tony Liu <tonyliu@coventive.com>
|
||||
|
||||
@@ -0,0 +1,98 @@
|
||||
ADS GraphicsClient Plus Single Board Computer
|
||||
|
||||
For more details, contact Applied Data Systems or see
|
||||
http://www.applieddata.net/products.html
|
||||
|
||||
The original Linux support for this product has been provided by
|
||||
Nicolas Pitre <nico@cam.org>. Continued development work by
|
||||
Woojung Huh <whuh@applieddata.net>
|
||||
|
||||
It's currently possible to mount a root filesystem via NFS providing a
|
||||
complete Linux environment. Otherwise a ramdisk image may be used. The
|
||||
board supports MTD/JFFS, so you could also mount something on there.
|
||||
|
||||
Use 'make graphicsclient_config' before any 'make config'. This will set up
|
||||
defaults for GraphicsClient Plus support.
|
||||
|
||||
The kernel zImage is linked to be loaded and executed at 0xc0200000.
|
||||
Also the following registers should have the specified values upon entry:
|
||||
|
||||
r0 = 0
|
||||
r1 = 29 (this is the GraphicsClient architecture number)
|
||||
|
||||
Linux can be used with the ADS BootLoader that ships with the
|
||||
newer rev boards. See their documentation on how to load Linux.
|
||||
Angel is not available for the GraphicsClient Plus AFAIK.
|
||||
|
||||
There is a board known as just the GraphicsClient that ADS used to
|
||||
produce but has end of lifed. This code will not work on the older
|
||||
board with the ADS bootloader, but should still work with Angel,
|
||||
as outlined below. In any case, if you're planning on deploying
|
||||
something en masse, you should probably get the newer board.
|
||||
|
||||
If using Angel on the older boards, here is a typical angel.opt option file
|
||||
if the kernel is loaded through the Angel Debug Monitor:
|
||||
|
||||
----- begin angelboot.opt -----
|
||||
base 0xc0200000
|
||||
entry 0xc0200000
|
||||
r0 0x00000000
|
||||
r1 0x0000001d
|
||||
device /dev/ttyS1
|
||||
options "38400 8N1"
|
||||
baud 115200
|
||||
#otherfile ramdisk.gz
|
||||
#otherbase 0xc0800000
|
||||
exec minicom
|
||||
----- end angelboot.opt -----
|
||||
|
||||
Then the kernel (and ramdisk if otherfile/otherbase lines above are
|
||||
uncommented) would be loaded with:
|
||||
|
||||
angelboot -f angelboot.opt zImage
|
||||
|
||||
Here it is assumed that the board is connected to ttyS1 on your PC
|
||||
and that minicom is preconfigured with /dev/ttyS1, 38400 baud, 8N1, no flow
|
||||
control by default.
|
||||
|
||||
If any other bootloader is used, ensure it accomplish the same, especially
|
||||
for r0/r1 register values before jumping into the kernel.
|
||||
|
||||
|
||||
Supported peripherals:
|
||||
- SA1100 LCD frame buffer (8/16bpp...sort of)
|
||||
- on-board SMC 92C96 ethernet NIC
|
||||
- SA1100 serial port
|
||||
- flash memory access (MTD/JFFS)
|
||||
- pcmcia
|
||||
- touchscreen(ucb1200)
|
||||
- ps/2 keyboard
|
||||
- console on LCD screen
|
||||
- serial ports (ttyS[0-2])
|
||||
- ttyS0 is default for serial console
|
||||
- Smart I/O (ADC, keypad, digital inputs, etc)
|
||||
See http://www.applieddata.com/developers/linux for IOCTL documentation
|
||||
and example user space code. ps/2 keybd is multiplexed through this driver
|
||||
|
||||
To do:
|
||||
- UCB1200 audio with new ucb_generic layer
|
||||
- everything else! :-)
|
||||
|
||||
Notes:
|
||||
|
||||
- The flash on board is divided into 3 partitions. mtd0 is where
|
||||
the ADS boot ROM and zImage is stored. It's been marked as
|
||||
read-only to keep you from blasting over the bootloader. :) mtd1 is
|
||||
for the ramdisk.gz image. mtd2 is user flash space and can be
|
||||
utilized for either JFFS or if you're feeling crazy, running ext2
|
||||
on top of it. If you're not using the ADS bootloader, you're
|
||||
welcome to blast over the mtd1 partition also.
|
||||
|
||||
- 16bpp mode requires a different cable than what ships with the board.
|
||||
Contact ADS or look through the manual to wire your own. Currently,
|
||||
if you compile with 16bit mode support and switch into a lower bpp
|
||||
mode, the timing is off so the image is corrupted. This will be
|
||||
fixed soon.
|
||||
|
||||
Any contribution can be sent to nico@cam.org and will be greatly welcome!
|
||||
|
||||
@@ -0,0 +1,53 @@
|
||||
ADS GraphicsMaster Single Board Computer
|
||||
|
||||
For more details, contact Applied Data Systems or see
|
||||
http://www.applieddata.net/products.html
|
||||
|
||||
The original Linux support for this product has been provided by
|
||||
Nicolas Pitre <nico@cam.org>. Continued development work by
|
||||
Woojung Huh <whuh@applieddata.net>
|
||||
|
||||
Use 'make graphicsmaster_config' before any 'make config'.
|
||||
This will set up defaults for GraphicsMaster support.
|
||||
|
||||
The kernel zImage is linked to be loaded and executed at 0xc0400000.
|
||||
|
||||
Linux can be used with the ADS BootLoader that ships with the
|
||||
newer rev boards. See their documentation on how to load Linux.
|
||||
|
||||
Supported peripherals:
|
||||
- SA1100 LCD frame buffer (8/16bpp...sort of)
|
||||
- SA1111 USB Master
|
||||
- on-board SMC 92C96 ethernet NIC
|
||||
- SA1100 serial port
|
||||
- flash memory access (MTD/JFFS)
|
||||
- pcmcia, compact flash
|
||||
- touchscreen(ucb1200)
|
||||
- ps/2 keyboard
|
||||
- console on LCD screen
|
||||
- serial ports (ttyS[0-2])
|
||||
- ttyS0 is default for serial console
|
||||
- Smart I/O (ADC, keypad, digital inputs, etc)
|
||||
See http://www.applieddata.com/developers/linux for IOCTL documentation
|
||||
and example user space code. ps/2 keybd is multiplexed through this driver
|
||||
|
||||
To do:
|
||||
- everything else! :-)
|
||||
|
||||
Notes:
|
||||
|
||||
- The flash on board is divided into 3 partitions. mtd0 is where
|
||||
the zImage is stored. It's been marked as read-only to keep you
|
||||
from blasting over the bootloader. :) mtd1 is
|
||||
for the ramdisk.gz image. mtd2 is user flash space and can be
|
||||
utilized for either JFFS or if you're feeling crazy, running ext2
|
||||
on top of it. If you're not using the ADS bootloader, you're
|
||||
welcome to blast over the mtd1 partition also.
|
||||
|
||||
- 16bpp mode requires a different cable than what ships with the board.
|
||||
Contact ADS or look through the manual to wire your own. Currently,
|
||||
if you compile with 16bit mode support and switch into a lower bpp
|
||||
mode, the timing is off so the image is corrupted. This will be
|
||||
fixed soon.
|
||||
|
||||
Any contribution can be sent to nico@cam.org and will be greatly welcome!
|
||||
@@ -0,0 +1,17 @@
|
||||
The HUW_WEBPANEL is a product of the german company Hoeft & Wessel AG
|
||||
|
||||
If you want more information, please visit
|
||||
http://www.hoeft-wessel.de
|
||||
|
||||
To build the kernel:
|
||||
make huw_webpanel_config
|
||||
make oldconfig
|
||||
[accept all defaults]
|
||||
make zImage
|
||||
|
||||
Mostly of the work is done by:
|
||||
Roman Jordan jor@hoeft-wessel.de
|
||||
Christoph Schulz schu@hoeft-wessel.de
|
||||
|
||||
2000/12/18/
|
||||
|
||||
39
Documentation/arm/SA1100/Itsy
一般檔案
39
Documentation/arm/SA1100/Itsy
一般檔案
@@ -0,0 +1,39 @@
|
||||
Itsy is a research project done by the Western Research Lab, and Systems
|
||||
Research Center in Palo Alto, CA. The Itsy project is one of several
|
||||
research projects at Compaq that are related to pocket computing.
|
||||
|
||||
For more information, see:
|
||||
|
||||
http://www.research.digital.com/wrl/itsy/index.html
|
||||
|
||||
Notes on initial 2.4 Itsy support (8/27/2000) :
|
||||
The port was done on an Itsy version 1.5 machine with a daughtercard with
|
||||
64 Meg of DRAM and 32 Meg of Flash. The initial work includes support for
|
||||
serial console (to see what you're doing). No other devices have been
|
||||
enabled.
|
||||
|
||||
To build, do a "make menuconfig" (or xmenuconfig) and select Itsy support.
|
||||
Disable Flash and LCD support. and then do a make zImage.
|
||||
Finally, you will need to cd to arch/arm/boot/tools and execute a make there
|
||||
to build the params-itsy program used to boot the kernel.
|
||||
|
||||
In order to install the port of 2.4 to the itsy, You will need to set the
|
||||
configuration parameters in the monitor as follows:
|
||||
Arg 1:0x08340000, Arg2: 0xC0000000, Arg3:18 (0x12), Arg4:0
|
||||
Make sure the start-routine address is set to 0x00060000.
|
||||
|
||||
Next, flash the params-itsy program to 0x00060000 ("p 1 0x00060000" in the
|
||||
flash menu) Flash the kernel in arch/arm/boot/zImage into 0x08340000
|
||||
("p 1 0x00340000"). Finally flash an initial ramdisk into 0xC8000000
|
||||
("p 2 0x0") We used ramdisk-2-30.gz from the 0.11 version directory on
|
||||
handhelds.org.
|
||||
|
||||
The serial connection we established was at:
|
||||
8-bit data, no parity, 1 stop bit(s), 115200.00 b/s. in the monitor, in the
|
||||
params-itsy program, and in the kernel itself. This can be changed, but
|
||||
not easily. The monitor parameters are easily changed, the params program
|
||||
setup is assembly outl's, and the kernel is a configuration item specific to
|
||||
the itsy. (i.e. grep for CONFIG_SA1100_ITSY and you'll find where it is.)
|
||||
|
||||
|
||||
This should get you a properly booting 2.4 kernel on the itsy.
|
||||
14
Documentation/arm/SA1100/LART
一般檔案
14
Documentation/arm/SA1100/LART
一般檔案
@@ -0,0 +1,14 @@
|
||||
Linux Advanced Radio Terminal (LART)
|
||||
------------------------------------
|
||||
|
||||
The LART is a small (7.5 x 10cm) SA-1100 board, designed for embedded
|
||||
applications. It has 32 MB DRAM, 4MB Flash ROM, double RS232 and all
|
||||
other StrongARM-gadgets. Almost all SA signals are directly accessible
|
||||
through a number of connectors. The powersupply accepts voltages
|
||||
between 3.5V and 16V and is overdimensioned to support a range of
|
||||
daughterboards. A quad Ethernet / IDE / PS2 / sound daughterboard
|
||||
is under development, with plenty of others in different stages of
|
||||
planning.
|
||||
|
||||
The hardware designs for this board have been released under an open license;
|
||||
see the LART page at http://www.lart.tudelft.nl/ for more information.
|
||||
11
Documentation/arm/SA1100/PLEB
一般檔案
11
Documentation/arm/SA1100/PLEB
一般檔案
@@ -0,0 +1,11 @@
|
||||
The PLEB project was started as a student initiative at the School of
|
||||
Computer Science and Engineering, University of New South Wales to make a
|
||||
pocket computer capable of running the Linux Kernel.
|
||||
|
||||
PLEB support has yet to be fully integrated.
|
||||
|
||||
For more information, see:
|
||||
|
||||
http://www.cse.unsw.edu.au/~pleb/
|
||||
|
||||
|
||||
@@ -0,0 +1,23 @@
|
||||
Pangolin is a StrongARM 1110-based evaluation platform produced
|
||||
by Dialogue Technology (http://www.dialogue.com.tw/).
|
||||
It has EISA slots for ease of configuration with SDRAM/Flash
|
||||
memory card, USB/Serial/Audio card, Compact Flash card,
|
||||
PCMCIA/IDE card and TFT-LCD card.
|
||||
|
||||
To compile for Pangolin, you must issue the following commands:
|
||||
|
||||
make pangolin_config
|
||||
make oldconfig
|
||||
make zImage
|
||||
|
||||
Supported peripherals:
|
||||
- SA1110 serial port (UART1/UART2/UART3)
|
||||
- flash memory access
|
||||
- compact flash driver
|
||||
- UDA1341 sound driver
|
||||
- SA1100 LCD controller for 800x600 16bpp TFT-LCD
|
||||
- MQ-200 driver for 800x600 16bpp TFT-LCD
|
||||
- Penmount(touch panel) driver
|
||||
- PCMCIA driver
|
||||
- SMC91C94 LAN driver
|
||||
- IDE driver (experimental)
|
||||
@@ -0,0 +1,7 @@
|
||||
Tifon
|
||||
-----
|
||||
|
||||
More info has to come...
|
||||
|
||||
Contact: Peter Danielsson <peter.danielsson@era-t.ericsson.se>
|
||||
|
||||
16
Documentation/arm/SA1100/Victor
一般檔案
16
Documentation/arm/SA1100/Victor
一般檔案
@@ -0,0 +1,16 @@
|
||||
Victor is known as a "digital talking book player" manufactured by
|
||||
VisuAide, Inc. to be used by blind people.
|
||||
|
||||
For more information related to Victor, see:
|
||||
|
||||
http://www.visuaide.com/victor
|
||||
|
||||
Of course Victor is using Linux as its main operating system.
|
||||
The Victor implementation for Linux is maintained by Nicolas Pitre:
|
||||
|
||||
nico@visuaide.com
|
||||
nico@cam.org
|
||||
|
||||
For any comments, please feel free to contact me through the above
|
||||
addresses.
|
||||
|
||||
@@ -0,0 +1,2 @@
|
||||
See http://www.yopydeveloper.org for more.
|
||||
|
||||
@@ -0,0 +1,2 @@
|
||||
See ../empeg/README
|
||||
|
||||
@@ -0,0 +1,11 @@
|
||||
nanoEngine
|
||||
----------
|
||||
|
||||
"nanoEngine" is a SA1110 based single board computer from
|
||||
Bright Star Engineering Inc. See www.brightstareng.com/arm
|
||||
for more info.
|
||||
(Ref: Stuart Adams <sja@brightstareng.com>)
|
||||
|
||||
Also visit Larry Doolittle's "Linux for the nanoEngine" site:
|
||||
http://recycle.lbl.gov/~ldoolitt/bse/
|
||||
|
||||
@@ -0,0 +1,47 @@
|
||||
The SA1100 serial port had its major/minor numbers officially assigned:
|
||||
|
||||
> Date: Sun, 24 Sep 2000 21:40:27 -0700
|
||||
> From: H. Peter Anvin <hpa@transmeta.com>
|
||||
> To: Nicolas Pitre <nico@CAM.ORG>
|
||||
> Cc: Device List Maintainer <device@lanana.org>
|
||||
> Subject: Re: device
|
||||
>
|
||||
> Okay. Note that device numbers 204 and 205 are used for "low density
|
||||
> serial devices", so you will have a range of minors on those majors (the
|
||||
> tty device layer handles this just fine, so you don't have to worry about
|
||||
> doing anything special.)
|
||||
>
|
||||
> So your assignments are:
|
||||
>
|
||||
> 204 char Low-density serial ports
|
||||
> 5 = /dev/ttySA0 SA1100 builtin serial port 0
|
||||
> 6 = /dev/ttySA1 SA1100 builtin serial port 1
|
||||
> 7 = /dev/ttySA2 SA1100 builtin serial port 2
|
||||
>
|
||||
> 205 char Low-density serial ports (alternate device)
|
||||
> 5 = /dev/cusa0 Callout device for ttySA0
|
||||
> 6 = /dev/cusa1 Callout device for ttySA1
|
||||
> 7 = /dev/cusa2 Callout device for ttySA2
|
||||
>
|
||||
|
||||
If you're not using devfs, you must create those inodes in /dev
|
||||
on the root filesystem used by your SA1100-based device:
|
||||
|
||||
mknod ttySA0 c 204 5
|
||||
mknod ttySA1 c 204 6
|
||||
mknod ttySA2 c 204 7
|
||||
mknod cusa0 c 205 5
|
||||
mknod cusa1 c 205 6
|
||||
mknod cusa2 c 205 7
|
||||
|
||||
In addition to the creation of the appropriate device nodes above, you
|
||||
must ensure your user space applications make use of the correct device
|
||||
name. The classic example is the content of the /etc/inittab file where
|
||||
you might have a getty process started on ttyS0. In this case:
|
||||
|
||||
- replace occurrences of ttyS0 with ttySA0, ttyS1 with ttySA1, etc.
|
||||
|
||||
- don't forget to add 'ttySA0', 'console', or the appropriate tty name
|
||||
in /etc/securetty for root to be allowed to login as well.
|
||||
|
||||
|
||||
新增問題並參考
封鎖使用者