Linux 2.6 for Cirrus Logic ARM Processors
Copyright (c) 2006,2007 Cirrus Logic, Inc.
This document describes the usage of the Linux 2.6 kernel for Cirrus
Logic EDB93x Development platforms.
* Licensing & Warnings
The software contained on this media includes open source software that may be
subject to the terms of the GPL, LPGL, MPL, or other similar open source
license agreement. It is the user's responsibility to confirm compliance with
all relevant terms and conditions of use associated with the software. Cirrus
Logic disclaims all representations and warranties with respect to the use of
this software.
This software includes libjpeg.so, which is based in part on the work of the
Independent JPEG Group.
!Mixing and matching components from various releases of this code may or may
not work (for example, continuing to use an old RedBoot with a new Linux
kernel). If problems occur, first make sure that components from only one
release are being used.!
* Requirements to Build Kernel From Source
Please see the README.BUILDING document in the source package for instructions on how to build the source.
* How to Use the Download Tool
** Overview
The download application is used to program either the NOR flash or the SPI
EEPROM connected to Cirrus Logic's ARM9 processor. For the board with an EP93xx,
it can program the NOR flash connected to nCS6 as well as the SPI EEPROM
connected to the SPI port. It supports all sizes of Intel B3, C3, J3, P30 and
and AM29LV320D flashes in either 16-bit or 32-bit-wide configuration. The 32-bit-wide
configuration is simply two 16-bit flashes connected in parallel on the
32-bit-wide bus. For SPI EEPROM, it supports the Atmel 25F1024 EEPROM
, SST SST25VF020, and SST SST25VF040B.
** Arguments
The arguments for the download program are as follows:
-b baud Use the specified baud rate. Valid values are 9600, 19200,
38400, 57600, and 115200.
Default is "115200".
-h Prints this usage message.
-n [MacAd] Program the specified 6-byte-long Ethernet MAC address into
EEPROM. The format of MAC address is XxXxXxXxXxXx,
where Xx is a hex number of a byte. If MacAd is not specified,
it prints the MAC address stored in EEPROM. This implies the
argument "-s 2".
-o offset The offset into the memory of FLASH or EEPROM where the
filename image should be programmed. It takes numbers,
Num*K (2^10), and Num*M (2^20). This value must correspond
to a block address boundary. If not, it will print an error
message and exit. Default is "0".
-p port Use the specified serial port. Append the specified port string
to the serial port prefix, /dev/tty for Linux and COM for Windows.
For Linux, default is "S0" which implies /dev/ttyS0.
Valid values are S0, S1,....USB0,USB1...etc.
For Windows, default is "1" which implies COM1.
Valid values are 1, 2, 3, 4, 5, 6,...etc.
-s device Program the specified image into a storage device, either EEPROM
or NOR FLASH. Valid values are 1 (NOR flash) and 2 (EEPROM).
Default is "1".
-v Prints the version of the program.
filename The name of the file to be programmed into NOR flash or EEPROM.
This argument is optional if "-n" is specified.
The information of MAC address is placed at offset 0x1000 in the EEPROM,
The 32 bytes of data at that position will be overwritten, and the
first 0x1000 bytes of the EEPROM will be filled with zeros if a file name
(filename) is not specified. If a file name is specified when -n is used,
the combination of the file size and the -o offset should not overlap with
the MAC address. In case overlap occurs, the program will print an error
message and exit.
** Usage
To program the file "foobar.bin" into the NOR FLASH at offset 0, using serial
port 1, and data speed of 115200, simply type the following,
download foobar.bin
To program the file "foobar.bin" into the SPI EEPROM at offset 0, using serial
port 1, and data speed of 115200, type the following,
download -s 2 foobar.bin
To program the file "foobar.bin" into the NOR FLASH at offset 16k (0x4000),
using serial 5, and the data speed is 57600, type the following,
For Linux,
download -b 57600 -o 16k -p S4 foobar.bin
download -b 57600 -o 0x4000 -p S4 foobar.bin
For Windows,
download -b 57600 -o 16k -p 5 foobar.bin
download -b 57600 -o 0x4000 -p 5 foobar.bin
To program the MAC address,12:34:56:AB:CD:EF, into the SPI EEPROM,
type the following,
download -n 123456ABCDEF
To program the file "foobar.bin" at offset 0 and the MAC address,
12:34:56:AB:CD:EF at offset 0x1000 into the SPI EEPROM,
type the following,
download -n 123456ABCDEF foobar.bin
To program the file "foobar.bin" at offset 0x400(1k) and the MAC address,
12:34:56:AB:CD:EF at offset 0x1000 into the SPI EEPROM,
type the following,
download -n 123456ABCDEF -o 1k foobar.bin
Read the Mac Address stored in EEPROM, type the following,
download -n
The information of the MAC address is placed at offset 0x1000 in the EEPROM,
The 32 bytes of data at that position will be overwritten, and the
first 0x1000 bytes of the EEPROM will be filled with zeros if a file name
(filename) is not specified. If a file name is specified when -n is used,
the combination of the file size and the -o offset should not overlap with
the MAC address. In case overlap occurs, the program will print an error
message and exit.
The data of the MAC address has 32 bytes. The first four bytes is "EMAC";
the next six bytes are the MAC address; the next six bytes are reserved;
the last 16 bytes are the string name for this board,
The last field currently uses 12 bytes to store the ASCII code of the MAC address
Once download is ready to talk to the board, it will display:
Waiting for the board to wakeup...
At this point, download is waiting for the board to initiate the serial boot
sequence. This sequence varies for each board:
For the EDB9301 and EDB9302:
1) Connect the "UART" port of the board (i.e. the bottom serial connector)
to the PC with a NULL modem cable.
2) Move the TEST0 jumper (JP14 on the EDB9301/EDB9302) from 2-3 to 1-2.
3) Press and release the RESET button.
4) In order to boot properly, the TEST0 jumper must be moved back to 2-3
once the download process is complete.
For the EDB9312 and EDB9315:
1) Connect the "UART1" port of the board (i.e. the bottom serial connector)
to the PC with a NULL modem cable.
2) Move the TEST0 jumper (JP92 on the EDB9312/EDB9315) from 2-3 to 1-2.
3) Press and release the RESET button.
4) In order to boot properly, the TEST0 jumper must be moved back to 2-3
once the download process is complete.
For the EDB9307:
1) Connect the "UART1" port of the board (i.e. the bottom serial connector)
to the PC with a NULL modem cable.
2) Press and hold S3 (BOOT 0).
3) Press and release SW2 (RESET).
4) Release S3 (BOOT 0).
For the EDB9315A:
1) Connect the "UART" port of the board to the PC with a NULL modem cable.
2) Press and hold S1 (SERIAL BOOT).
3) Press and release S3 (POR).
4) Release S1 (SERIAL BOOT).
At this point, download should start sending the initial boot code. As it does
so, it will display its status as follows:
Downloading boot code...(67%)
After the initial boot code is downloaded, it will check the starting offset
and image length to make sure they fit into the memory being programmed. For
all of the following messages, programming the NOR flash is assumed. If the
SPI EEPROM is being programmed, all occurrences of flash would appear as
EEPROM. If the image is too large to fit into the memory that was detected on
the board, it will display the following message and exit:
The image is too large for the flash.
If the starting offset does not correspond to a block boundary, it will display
the following message and exit:
The offset '543' is not valid for the flash.
If the starting address and image size are valid, it will erase the portion of
memory to be programmed. It could take several seconds to erase the memory so
be patient. It will display its status as follows:
Erasing the flash...
Once the memory is erased, it will program the contents of the memory. It will
display its status as follows:
Programming the FLASH...(17%)
After the memory has been programmed, download will display the final results
of the download. The data is checksummed as it is transferred over the serial
link, and read back from memory after it has been programmed to compare it to
the data received from the PC. If there is an error in any of these
verification steps, download will display the following message when complete:
Failed to program 'filename'.
Or it will display the following message if a problem occurred while
programmed just the Ethernet MAC address:
Failed to program the Ethernet MAC address.
If everything was successful, it will display the following message:
Successfully programmed 'filename'.
Or it will display the following message if just the Ethernet MAC address was
being programmed:
Successfully programmed the Ethernet MAC address.
It is possible that the PC and the target get a bit out of sync during the
download process. If this happens, the download program attempts to recover
the communication link gracefully. If it is unable to, it will eventually
time out. If the progress seems to be stuck, wait at least two minutes before
killing the download program.
For memories that support block locking, download will attempt to unlock the
blocks before erasing them. For blocks that are hardware locked (either via
permanent lock mechanism in the programming interface itself or a pin on the
chip itself), there is nothing that download can do; in this case, the download
will fail.
** Building Download
To build download, simply type "make". The appropriate cross compiler and
native compiler must be in the search path. By default, gcc is used as the
cross compiler and native compiler when building on Linux; ARM ADS 1.x and MSVC
are used as the cross compiler and native compiler when building in Windows.
If building on Windows, the appropriate Un*x-like utility must also be in the
search path; use the bin directory of this package if necessary. Many Windows
tool chains have their own version of make; be sure that GNU make is the one
executed when you type "make" or the build will surely fail.
* How to Add a New Flash Driver to the Download Tool
The strategy of download is based on the internal serial booting
mode of an EP93xx chip. It also takes into account of the different memory
layouts of the EDB93xx boards.
First, the first-stage boot code running in the internal Ethernet buffer
(0x80014000-0x80014800) detects the SDRAM automatically, initializes the
serial, gets the second-stage code from the host PC, copies the second-stage
code to SDRAM, and then switches to SDRAM to execute the second-stage code.
Second, the second-stage code has a standard architecture including the UART
and flash drivers. This code has a flexible architecture and can be easily written
by the C programming language. The C code can be easily changed to support a new
flash type.
** The data structures of the flash driver
The erase sector information structure:
typedef struct EraseBlockInfo {
unsigned long blocks;
unsigned long block_size;
} EraseBlockInfo_t;
The common flash interface information structure:
typedef struct CFIQuery {
unsigned long DeviceSize;
unsigned long NumEraseBlocks;
struct EraseBlockInfo sBlockInfo[4];
} CFIQuery_t;
The flash information structure:
typedef struct FlashInfo {
unsigned short ManufactureId;
unsigned short DeviceId[4];
unsigned short ByteWidth;
unsigned long FlashBase;
unsigned long SysConBase;
struct CFIQuery *pQuery;
} FlashInfo_t;
** The function of the flash driver
The flash operation function pointer:
typedef struct FlashOps {
int (*FlashQuery)(struct FlashInfo *pInfo);
int (*FlashErase)(struct FlashInfo *pInfo, int iOffset, int len);
int (*FlashProgram)(struct FlashInfo *pInfo, int iOffset, void *data, int len);
} FlashOps_t;
** Add the intel.c and intel.h
intel.h defines the Intel flash operation macros and functions.
Refer to download/src/src/intel.h.
intel.c declares the Intel operation functions.
Refer to download/src/src/intel.c.
Three functions must be implemented so these functions can be called from main.c
Function: int IntelFlashQuery(struct FlashInfo *pInfo);
Description: This routine reads the flash manufacture ID and device ID.
Return: 0 - success, 1 - failure.
Function: int IntelFlashErase(struct FlashInfo *pInfo, int iOffset, int len);
Description: This routine programs the Intel flash.
Arguments: iOffset - the offset address.
data - the data pointer.
len - the length.
Return: 0 - success, 1 - failure.
Function: int IntelFlashProgram(struct FlashInfo *pInfo, int iOffset, void *data, int len);
Description: This routine erases the sectors of Intel flash.
Arguments: iOffset - the offset address.
len - the length.
Return: 0 - success, 1 - failure.
** Add the Intel operation function
Add the following function pointer to download/src/src/main.c
struct FlashOps sFlashOps[]={
// AMD operation function pointer
{
AmdFlashQuery,
AmdFlashErase,
AmdFlashProgram
},
+ // INTEL operation function pointer
+ {
+ IntelFlashQuery,
+ IntelFlashErase,
+ IntelFlashProgram
+ },
// Add your operation function pointer
// The last one indicates the termination
{
0,
0,
0
}
};
Add the following code to download/src/main.c
else if(!sFlashOps[1].FlashQuery(&sFlashInfo))
{
// The flash is intel compatible serial.
spFlashOps = &sFlashOps[1];
#ifdef _DBG
iOffSet = 0x00;
iFileSize = 0x20000;
for(index=0; index<1024; index++)
{
data[index] = 0xaa;
}
spFlashOps->FlashErase(&sFlashInfo, iOffSet, iFileSize);
spFlashOps->FlashProgram(&sFlashInfo, iOffSet, (void *)data, 1024);
#endif
Serial_SendChar('I');
}
** Change the Makefile
Change download/src/Makefile to build the source code.
#
# The set of object files that comprise the download utility.
#
OBJS = init.o serial.o timer.o amd.o intel.o at25f1024.o sst25vf020.o main.o
* Running Redboot
Use the download application to program the redboot.bin image into the NOR
FLASH of the board to be used. Also can also use the download application to program the ethernet MAC address
(if it has not already been done) so that the ethernet interface can be used by
RedBoot. Or you can use the fconfig command to set the MAC.
Redboot can now be built for different flash types. The Cirrus Linux package has been updated to include support for
all flash devices supported in ECOS. With the new menu driven build system, building redboot for different flash types and boards has been greatly simplified
To build redboot for a different Flash Type you need to replace the default
command listed above with the type you are using from the provided list.
Example: To build AMD AM29LV320D 16bit Flash support for EDB9315.
[*] Download -- The Flash Programming Utilty
() also copy the download program to...
[*] RedBoot
EDB93XX Redboot Configuration (EDB9315) --->
[*] --- Non-Cirrus flash chip types ---
[ ] Intel P30 (NEW)
[ ] Intel 28FXXX (C3 Type) Flash Support (NEW)
[*] AMD/Spansion Flash Support
Select Flash Device (AMD AM29LV320D) --->
(16) ---- Flash width (8/16 bit) ---- (NEW)
(1) ---- Number of Flash Devices ---- (NEW)
() also copy redboot.bin to...
The following flash types are now supported by redboot for EP93XX.
Note. Not all flash devices have been tested by Cirrus Logic.
Intel 28FXXXX
INTEL 28F160S5
INTEL_28F160B3T
INTEL_28F320B3
INTEL_28F320C3
INTEL_28F320S3
INTEL_28F800B5
SHARP_LH28F016SCT_Z4
SHARP_LH28F016SCT_95
Intel P30
AMD/Toshiba/Spansion
AMD_AM29LV320D AMD_AM29F002T
AMD_AM29F010 AMD_AM29F040B
AMD_AM29LV128 AMD_MX29LV128
AMD_AM29LV160 AMD_AM29PL160
ST_M29W320D AMD_AM29LV200
ST_M29W200B AMD_AM29LV640
AMD_AM29DL322D AMD_AM29DL323D
AMD_AM29DL324D AMD_AM29LV400
AMD_AM29DL640D AMD_AM29F800
AMD_AM29LV800 AMD_TC58FVB800
AMD_AM29LV081B AMD_AM29LV017D
AMD_AM29LV033C AMD_AM29LV065D
AMD_AM29LV256 AMD_S29GL064M
AMD_S29PL032J AMD_S29PL064J
AMD_S29PL127J AMD_S29GL128N
AMD_S29GL256N AMD_S29GL512N
AMD_S29GL128M
Once programmed, the sequence to run RedBoot varies for each board:
For the EDB9301, EDB9302/A, EDB9307/A, EDB9312, and EDB9315/A:
- Run "minicom" (or a terminal emulation program of your choice).
- Set the serial port to 57600, 8-N-1. Also, select the same serial port
as used to download RedBoot to the board.
- Make sure that the TEST0 jumper (JP14 on the EDB9301/EDB9302 or JP92 on
the EDB9312/EDB9315) is on 2-3. On the EDB9307, do not press the BOOT0
(S3) button.
- Press and release the RESET button.
After some time, the RedBoot banner will be displayed. The first time it is
run on a board, it will attempt to get an IP address via BOOTP. If there is no
BOOTP server on your network (or the network cable is not plugged in), it will
take a couple of minutes to timeout. Be patient.
The first thing to do is to initialize the NOR FLASH filesystem (this only
needs to be done once, unless you wish to destroy the contents of your FLASH).
Simply type "fis init -f" and wait for it to complete. Then type "fconfig -i"
to configure RedBoot (again, only needs to be done once, unless you wish to
change the configuration, or add a boot script). The questions asked, along
with some recommended answers, are given here:
- Run script at boot: {false}
- Use BOOTP for network configuration: {depends on your network}
- Gateway IP address: {depends on your network}
- Local IP address: {depends on your network}
- Local IP address mask: {depends on your network}
- Default server IP address: {depends on your network}
- DNS server IP adddress: {depends on your network}
- Set eth0 network hardware address [MAC]: {false}
- GDB connection port: {9000}
- Force console for special debug messages: {false}
- Network debug at boot time: {false}
Details of how to configure networking in RedBoot are specific to your network
and can not be spelled out in detail here; the network configuration questions
in "fconfig" and the "ip_address" commands are available in RedBoot to
configure the network, and the "ping" command can be used to test the
networking. To later change some of the configuration values, simply use
"fconfig"; the "fconfig -i" variant will forget any previous settings that may
exist and reset them all to the default values.
The "load" command can be used to read images from a tftp server on the
network. The "fis create" command can be used to create a partition in the NOR
FLASH to contain an image, such as the ramdisk or the Linux kernel. They can
then be loaded with "fis load", not requiring any network activity, and also
MUCH faster. Note that if the images are loaded into the FLASH, the boot
script in "fconfig" can be used to automatically start Linux when the board is
powered on.
Consult the RedBoot documentation on http://sources.redhat.com/redboot for full
details of the capabilities of RedBoot and how to utilize them.
* Tftp Server
RedBoot uses tftp to retrieve images from the network. Therefore, a tftp
server must be running on a machine on your network, and the images to be
loaded onto the board must reside on that machine. Configuration of a tftp
server is different between various OSes, and between various distributions of
an OS (such as the various flavors of Linux). Documentation from your OS
vendor will have to be consulted in order to get a tftp server running.
* Loading the ramdisk.gz image
Once RedBoot (with networking) is running on the board, Linux can be loaded and
run. The images to be loaded by RedBoot must be placed into the area used by
the tftp server on your host machine, typically "/tftpboot" (though this may be
different based on your OS; see your OS vendor's documentation for details).
Initially, try the following:
For the EDB9307/12/15
RedBoot> load -r -v -b 0x1000000 ramdisk.gz
RedBoot> load -r -v -b 0x80000 zImage
RedBoot> exec -r 0x1000000 -s 0x1000000 -c "root=/dev/ram console=ttyAM video=ep93xxfb:vout=1,vmode=0,depth=16"
For the EDB9301/02
RedBoot> load -r -v -b 0x800000 ramdisk.gz
RedBoot> load -r -v -b 0x80000 zImage
RedBoot> exec -r 0x800000 -s 0x800000 -c "root=/dev/ram console=ttyAM"
For the EDB9302A
RedBoot> load -r -v -b 0x800000 ramdisk.gz
RedBoot> load -r -v -b 0x80000 zImage
RedBoot> exec -r 0x800000 -s 0x800000 -c "root=/dev/ram console=ttyAM" 0xc0080000
For the EDB9307A/15A
RedBoot> load -r -v -b 0x1000000 ramdisk.gz
RedBoot> load -r -v -b 0x80000 zImage
RedBoot> exec -r 0x1000000 -s 0x1000000 -c "root=/dev/ram console=ttyAM video=ep93xxfb:vout=0,vmode=2,depth=16" 0xc0080000
For the EDB9301/02/02A a default ramdisk_size of 0x800000 will suffice
For the EDB9307/07A/12/15/15A a default ramdisk_size of 0x1000000 will suffice
This will load the minimal ramdisk image, the Linux kernel, and then start it
running. Note that the "go" command will also start applications, though it
will not successfully start a Linux kernel; only use the "exec" command. The
"-s" argument to "exec" is the size of the ramdisk image; it must be greater
than or equal to the size of the ramdisk.gz loaded. If the size specified is
too small, the kernel will report "RAMDISK: ran out of compressed data" and
then panic.
While the SDRAM on some boards appears as multiple discontiguous regions of
memory in the physical address space, it is mapped into a single contiguous
logical region of memory by RedBoot. But, images must be loaded into a
physically contiguous region of memory since Linux is unable to correctly
handle images that are not physically contiguous. This means there are
artificial limitations on the locations to which images can be loaded. For
each board, the memory is segmented into the following size blocks:
- EDB9301: 8MB 8MB 8MB 8MB
- EDB9302: 8MB 8MB 8MB 8MB
- EDB9302A: 8MB 8MB 8MB 8MB
- EDB9307: 32MB 32MB
- EDB9307A: 32MB 32MB
- EDB9312: 32MB 32MB
- EDB9315: 32MB 32MB
- EDB9315A: 32MB 32MB
So, images can not be loaded such that they cross any of the boundaries between
the physically discontiguous blocks of memory. So, for example, the ramdisk
on a EDB9301 can not be loaded to address 0x7fff00 since it would cross the 8MB
memory boundary, which is physically discontiguous (but it can be loaded to
0x800000). The kernel can be loaded at any address within memory; RedBoot will
copy it to the execution address.
* Using JFFS2 as root filesystem
Cirrus Logic ARM Linux now supplies a JFFS2 root filesystem image which contains everything the ramdisk.gz images contains. Following are examples of how to use Redboot to load and write the image into Flash, and mount the JFFS2 image as a root filesystem.
To load the root.jffs2 for the EDB9307/12/15
RedBoot> fis init -f
About to initialize [format] FLASH image system - continue (y/n)? y
RedBoot> reset
RedBoot> load -r -v -b 0xa00000 root.jffs2
RedBoot> fis create -b 0xa00000 -l 0xe00000 jffs2
RedBoot> load -r -v -b 0x80000 zImage
RedBoot> exec -c "root=/dev/mtdblock1 rootfstype=jffs2 console=ttyAM"
For the EDB9301/02
RedBoot> fis init -f
About to initialize [format] FLASH image system - continue (y/n)? y
RedBoot> reset
RedBoot> load -r -v -b 0x800000 root.jffs2
RedBoot> fis create -b 0x800000 -l 0xa00000 jffs2
RedBoot> load -r -v -b 0x80000 zImage
RedBoot> exec -c "root=/dev/mtdblock1 rootfstype=jffs2 console=ttyAM"
For the EDB9302A/7A/15A
RedBoot> fis init -f
About to initialize [format] FLASH image system - continue (y/n)? y
RedBoot> reset
RedBoot> load -r -v -b 0xa00000 root.jffs2
RedBoot> fis create -b 0xa00000 -l 0xe00000 jffs2
RedBoot> load -r -v -b 0x80000 zImage
RedBoot> exec -c "root=/dev/mtdblock1 rootfstype=jffs2 console=ttyAM" 0xc0080000
These values will give you extra space to create and save data on the Flash to play with. You must specify the rootfstype to tell the kernel that you want to use JFFS2 as rootfs.
* Running UBoot
Use the download application to program the u-boot.bin image into the NOR
FLASH of the board to be used.Also can also use the download application to
program the ethernet MAC address (if it has not already been done) so that
the ethernet interface can be used by UBoot. Or you can use the setenv
command to set the MAC. UBoot can now be built for different flash types.
With the new menu driven build system,building redboot for different flash
types and boards has been greatly simplified
To build redboot for a different Flash Type you need to replace the default
command listed above with the type you are using from the provided list.
Example: To build AMD AM29LV320D 16bit Flash support for EDB9315.
[*] Download -- The Flash Programming Utilty
() also copy the download program to...
[ ] RedBoot
[*] UBoot
EDB93XX UBoot Configuration (EDB9315) --->
[*] --- Non-Cirrus flash chip types ---
[ ] Intel P30 (NEW)
[ ] Intel 28FXXX (C3 Type) Flash Support (NEW)
[*] AMD/Spansion Flash Support
Select Flash Device (AMD AM29LV320D) --->
(16) ---- Flash width (8/16 bit) ---- (NEW)
(1) ---- Number of Flash Devices ---- (NEW)
[ ] Make uboot linux kernel image
[ ] Make uboot linux ramdisk image
() also copy uboot.bin to...
The following flash types are now supported by uboot for EP93XX.
Note. Not all flash devices have been tested by Cirrus Logic.
Intel 28FXXXX
INTEL 28F160S5
INTEL_28F160B3T
INTEL_28F320B3
INTEL_28F320C3
INTEL_28F320S3
INTEL_28F800B5
SHARP_LH28F016SCT_Z4
SHARP_LH28F016SCT_95
Intel P30
AMD/Toshiba/Spansion
AMD_AM29LV320D AMD_AM29F002T
AMD_AM29F010 AMD_AM29F040B
AMD_AM29LV128 AMD_MX29LV128
AMD_AM29LV160 AMD_AM29PL160
ST_M29W320D AMD_AM29LV200
ST_M29W200B AMD_AM29LV640
AMD_AM29DL322D AMD_AM29DL323D
AMD_AM29DL324D AMD_AM29LV400
AMD_AM29DL640D AMD_AM29F800
AMD_AM29LV800 AMD_TC58FVB800
AMD_AM29LV081B AMD_AM29LV017D
AMD_AM29LV033C AMD_AM29LV065D
AMD_AM29LV256 AMD_S29GL064M
AMD_S29PL032J AMD_S29PL064J
AMD_S29PL127J AMD_S29GL128N
AMD_S29GL256N AMD_S29GL512N
AMD_S29GL128M
Once programmed, the sequence to run UBoot varies for each board:
For the EDB9301, EDB9302/A, EDB9307/A, EDB9312, and EDB9315/A:
- Run "minicom" (or a terminal emulation program of your choice).
- Set the serial port to 57600, 8-N-1. Also, select the same serial port
as used to download UBoot to the board.
- Make sure that the TEST0 jumper (JP14 on the EDB9301/EDB9302 or JP92 on
the EDB9312/EDB9315) is on 2-3. On the EDB9307, do not press the BOOT0
(S3) button.
- Press and release the RESET button.
After some time, the UBoot banner will be displayed.The first thing to do is
to initialize the Environment Variables.
You can use printenv command to get the default Environment Variables.
EDB9315A> printenv
bootdelay=2
baudrate=57600
ethaddr=01:02:93:12:15:07
bootfile="vmlinux.gz.img"
mtdids=nor0=edb93xx-nor0
bootcmd=tftp c0200000 9315A/vmlinux.gz.img;bootm c0200000
filesize=d00000
fileaddr=60080000
gatewayip=198.90.193.1
netmask=255.255.255.0
ipaddr=198.90.193.147
serverip=198.90.193.233
mtdparts=mtdparts=edb93xx-nor0:512k@0(Firmware),-@0x080000(JFFS2)
partition=nor0,0
mtddevnum=0
mtddevname=Firmware
bootargs=root=/dev/nfs ip=198.90.193.147
nfsroot=198.90.193.233:/mnt/9315A
console=ttyAM
stdin=serial
stdout=serial
stderr=serial
Environment size: 532/131067 bytes
Then you can use setenv command to modify variables:
EDB9315A> setenv ipaddr '198.90.193.167'
CAUTION:the value you want to set for the variable MUST be surrounded by
single quotes.
After modifying all variables you need , never forget to use saveenv command
to keep changes available:
EDB9315A> saveenv
Saving Environment to Flash...
Un-Protected 1 sectors
Un-Protected 1 sectors
Erasing Flash...
. done
Erased 1 sectors
Writing to Flash... done
Protected 1 sectors
Protected 1 sectors
You can set "bootcmd" variable to automatically start Linux when the board is
powered on.And "bootargs" is the commandline parameters passed to kernel.
Consult the UBoot documentation on
http://www.denx.de/wiki/UBoot/Documentation for full
details of the capabilities of UBoot and how to utilize them.
* UBoot Loading The Kernel and Ramdisk.gz Image
UBoot uses tftp to retrieve images from the network. Therefore, a tftp
server must be running on a machine on your network, and the images to be
loaded onto the board must reside on that machine. Configuration of a tftp
server is different between various OSes, and between various distributions of
an OS (such as the various flavors of Linux). Documentation from your OS
vendor will have to be consulted in order to get a tftp server running.
Once UBoot (with networking) is running on the board, Linux can be loaded
and run. The images to be loaded by UBoot must be placed into the area used
by the tftp server on your host machine, typically "/tftpboot" (though this
may be different based on your OS; see your OS vendor's documentation for
details).
While the SDRAM on some boards appears as multiple discontiguous regions of
memory in the physical address space, and UBoot uses no virtual address.
Images must be loaded into a physically contiguous region of memory since
Linux is unable to correctly handle images that are not physically contiguous.
This means there are artificial limitations on the locations to which images
can be loaded. For each board, the memory is segmented into the following
size blocks:
- EDB9301: 8MB 8MB 8MB 8MB
- EDB9302: 8MB 8MB 8MB 8MB
- EDB9302A: 8MB 8MB 8MB 8MB
- EDB9307: 32MB 32MB
- EDB9307A: 32MB 32MB
- EDB9312: 32MB 32MB
- EDB9315: 32MB 32MB
- EDB9315A: 32MB 32MB
So, images can not be loaded such that they cross any of the boundaries
between the physically discontiguous blocks of memory. So, for example, the
ramdisk on a EDB9301 can not be loaded to address 0x7fff00 since it would
cross the 8MB memory boundary, which is physically discontiguous (but it can be loaded
to 0x800000). The kernel can be loaded at any address within memory;
You can use mp command to get board SDRAM layout:
EDB9315A> mp
DRAM total 2 banks:
bank base-address size
0 c0000000 02000000
1 c4000000 02000000
These will help you to make simple decision for downloading images.
As UBoot uses special image format for linux kernel and ramdisk images,you
have to do some configuration in build system:
[*] Download -- The Flash Programming Utilty
() also copy the download program to...
[ ] RedBoot
[*] UBoot
EDB93XX UBoot Configuration (EDB9315A)--->
[*] --- Non-Cirrus flash chip types ---
[ ] Intel P30 (NEW)
[ ] Intel 28FXXX (C3 Type) Flash Support (NEW)
[*] AMD/Spansion Flash Support
Select Flash Device (AMD AM29LV320D) --->
(16) ---- Flash width (8/16 bit) ---- (NEW)
(1) ---- Number of Flash Devices ---- (NEW)
[*] Make uboot linux kernel image
[*] Make uboot linux ramdisk image
() also copy uboot.bin to...
Select both "Make uboot linux kernel image" and "Make uboot linux ramdisk
image" , these will create uboot style images -- vmlinux.gz.img and
ramdisk.gz.img.
Next,you can use tftp command to download the images:
EDB9315A> tftp c0200000 vmlinux.gz.img
TFTP from server 198.90.193.233; our IP address is 198.90.193.167
Filename 'vmlinux.gz.img'.
Load address: 0xc0200000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
##################################################
done
Bytes transferred = 1918559 (1d465f hex)
EDB9315A> tftp c4000000 ramdisk.gz.img
TFTP from server 198.90.193.233; our IP address is 198.90.193.167
Filename 'ramdisk.gz.img'.
Load address: 0xc4000000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
done
Bytes transferred = 11676555 (b22b8b hex)
Use bootm command to start kernel with ramdisk:
EDB9315A> bootm c0200000 c4000000
## Booting image at c0200000 ...
Image Name: linux kernel
Image Type: ARM Linux Kernel Image (gzip compressed)
Data Size: 1918495 Bytes = 1.8 MB
Load Address: c0080000
Entry Point: c0080000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading Ramdisk Image at c4000000 ...
Image Name: linux ramdisk
Image Type: ARM Linux RAMDisk Image (gzip compressed)
Data Size: 11676491 Bytes = 11.1 MB
Load Address: c4000000
Entry Point: c4000000
Verifying Checksum ... OK
Starting kernel ...
* Programing UBoot Kernel and Ramdisk.gz Image Into NOR FALSH.
Use flin command to get flash layout:
EDB9315A> flin
Bank # 1: CFI conformant FLASH (16 x 16) Size: 16 MB in 128 Sectors
Erase timeout 16384 ms, write timeout 3 ms, buffer write timeout 3
ms, buffer size 32
Sector Start Addresses:
60000000 (RO) 60020000 (RO) 60040000 (RO) 60060000 (RO) 60080000
600A0000 600C0000 600E0000 60100000 60120000
60140000 60160000 60180000 601A0000 601C0000
601E0000 60200000 60220000 60240000 60260000
60280000 602A0000 602C0000 602E0000 60300000
60320000 60340000 60360000 60380000 603A0000
603C0000 603E0000 60400000 60420000 60440000
60460000 60480000 604A0000 604C0000 604E0000
60500000 60520000 60540000 60560000 60580000
605A0000 605C0000 605E0000 60600000 60620000
60640000 60660000 60680000 606A0000 606C0000
606E0000 60700000 60720000 60740000 60760000
60780000 607A0000 607C0000 607E0000 60800000
60820000 60840000 60860000 60880000 608A0000
608C0000 608E0000 60900000 60920000 60940000
60960000 60980000 609A0000 609C0000 609E0000
60A00000 60A20000 60A40000 60A60000 60A80000
60AA0000 60AC0000 60AE0000 60B00000 60B20000
60B40000 60B60000 60B80000 60BA0000 60BC0000
60BE0000 60C00000 60C20000 60C40000 60C60000
60C80000 60CA0000 60CC0000 60CE0000 60D00000
60D20000 60D40000 60D60000 60D80000 60DA0000
60DC0000 60DE0000 60E00000 60E20000 60E40000
60E60000 60E80000 60EA0000 60EC0000 60EE0000
60F00000 60F20000 60F40000 60F60000 60F80000
60FA0000 60FC0000 60FE0000
Each address means one sector. And the sectors fllowed by "(RO)" are the
FIRMWARE region which you can't TOUCH. All flash operations are based on the
CELL -- sector,so the address used with flash correlative commands MUST be
aligned on sector boundary.
Before programing images ,you have to erase flash sectors to make it in ready
status:
EDB9315A> erase 60080000 6027ffff
This will erase 16 sectors between the start addr(0x60080000) and the end
addr(0x6027ffff) -- the end address MUST be the sector end address NOT the
following sector start address.
There are two methods for programing images into FLASH:
a.use tftp command programing flash directly:
EDB9315A> tftp 60520000 vmlinux.gz.img
TFTP from server 198.90.193.233; our IP address is 198.90.193.167
Filename '9315A/vmlinux.gz.img'.
Load address: 0x60520000
Loading:
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
##################################################
done
Bytes transferred = 1918559 (1d465f hex)
The address of tftp command is address of Flash sector where you want to
store image.
b.use tftp and cp command:
EDB9315A> tftp c0200000 vmlinux.gz.img
EDB9315A> cp C2000000 60080000 80000
First,download image into SDRAM,then copy image from SDRAM into flash.The cp
command will copy 0x80000*4 bytes datas from 0xc2000000(source) to
60080000(target).
After programing images into FLASH , you can use iminfo to verify image's
correctness:
EDB9315A> iminfo 60080000
## Checking Image at 60080000 ...
Image Name: linux kernel
Image Type: ARM Linux Kernel Image (gzip compressed)
Data Size: 1526351 Bytes = 1.5 MB
Load Address: c0080000
Entry Point: c0080000
Verifying Checksum ... OK
* UBoot Using JFFS2 As Root Filesystem
Cirrus Logic ARM Linux now supplies a JFFS2 root filesystem image which
contains everything the ramdisk.gz images contains. Following are examples of
how to use UBoot to load and write the image into Flash, and mount the JFFS2
image as a root filesystem.
For using jffs2 rootfs with uboot , have to do some modification on kernel
Memory Technology Devices (MTD) --->
< > RedBoot partition table parsing -- UNSELECT
[ ] Include unallocated flash regions -- UNSELECT
[ ] Force read-only for RedBoot system images -- UNSELECT
[*] Command line partition table parsing -- SELECT
Mapping drivers for chip access --->
<*> CFI Flash device in physical memory map
(0x0) Physical start address of flash mapping
(0x0) Physical length of flash mapping
(1) Bank width in octets
Download JFFS2 root filesystem into FLASH:
EDB9315A> tftp 60080000 rootfs.jffs2
Add mtd partitions:
EDB9315A>mtdparts add nor0 512k@0 Firmware
EDB9315A>mtdparts add nor0 -@0x080000 JFFS2
You can use mtdparts command to get MTD partitions status:
EDB9315A> mtdparts
device nor0 [edb93xx-nor0], # parts = 3
#: name size offset mask_flags
0: Firmware 0x00080000 0x00000000 0
1: JFFS2 0x01f80000 0x00080000 0
active partition: nor0,0 - (Firmware) 0x00080000 @ 0x00000000
defaults:
mtdids : nor0=edb93xx-nor0
mtdparts:mtdparts=edb93xx-nor0:512k@0(Firmware)-@0x080000(JFFS2)
Pass commandline parameters:
Linux-2.6.17.14 and below
EDB9315A> setenv bootargs 'root=/dev/mtdblock1 rootfstype=jffs2 \
mtdparts=phys_mapped_flash:512k(Firmware),-(JFFS2)
Linux-2.6.17.14 above
EDB9315A> setenv bootargs 'root=/dev/mtdblock1 rootfstype=jffs2 \
mtdparts=physmap-flash.0:512k(Firmware),-(JFFS2)
* Running Linux
You will see "Uncompressing linux.....done, booting the kernel." on the serial
port. After a little bit, it will say "Press enter to activate this console" on the serial
connection, at which point it is ready for you to do things.
Start by pressing enter. You'll see a welcome banner, followed by a command
prompt:
BusyBox v1.1.3 (2007.04.06-06:01+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
~ #
Type some typical Linux commands, such as ls. Some commands of special
interest on the minimal ramdisk are (not all applications will be on the
ramdisk for every target):
[dosfsck] Same as on desktop Linux. Verifies the consistency of a MS-DOS VFAT filesystem.
[e2fsck] Same as on desktop Linux. Verifies the consistency of an EXT2 or EXT3 filesystem.
[flash_eraseall] This application erases the entire contents of a MTD partition
on the NOR FLASH. Care should be taken in using it; if run on
/dev/mtd0 the entire FLASH will be erased, including RedBoot!
[fdisk] Same as on desktop Linux. A hard drive can be partitioned with this application.
[mkdosfs] Same as on desktop Linux. A hard drive partition, or a
ramdisk, can be formatted with this application using the
MS-DOS VFAT filesystem.
[mke2fs] Same as on desktop Linux. A hard drive partition, or a
ramdisk, can be formatted with this application using the EXT2 or EXT3 filesystems.
* QT Embedded
Additionally, on the EDB9307/A, EDB9312 and EDB9315/A, there is OPIE (Open Palm Integrated
Environment) that uses Qt. Several environment variables control the behavior of Qt:
** QWS_DISPLAY
This environment variable (if set) will choose the video driver that will be used; the EP93xx
driver is the default (as set in /etc/profile on the ramdisk). If this environment variable
is not set, then the standard linux framebuffer driver will be used. The valid values are:
LinuxFb:/dev/fb0 - the Linux framebuffer driver
EP93xx:/dev/fb0 - the EP93xx accelerated driver
Transformed:/dev/fb0:Rot90 - the EP93xx accelerated driver with
the screen rotated 90 degrees
Transformed:/dev/fb0:Rot180 - the EP93xx accelerated driver with
the screen rotated 180 degrees
Transformed:/dev/fb0:Rot270 - the EP93xx accelerated driver with
the screen rotated 270 degrees
** QWS_MOUSE_PROTO
This environment variable will choose between using a mouse or the touch screen for the
pointer device; the touch screen is the default (as set in /etc/profile on the ramdisk). The valid values are:
Microsoft:/dev/input/mice - a Microsoft-compatible mouse
IntelliMouse:/dev/input/mice - an IntelliMouse-compatible mouse
TPanel:/dev/misc/ep93xx_ts - the touch screen
IntelliMouse:/dev/lircm - an infrared remote
** QWS_SW_CURSOR
This environment variable controls whether a software or hardware cursor will be used.
If a cursor is not needed at all (such as when using the touch screen as the mouse),
then there is no cursor at all. Otherwise, this will choose between a software and a
hardware (if available) cursor. The valid values are:
0 - to use a hardware cursor
1 - to use a software cursor
The "-noswcursor" and "-swcursor" command line arguments can be used in place of,
or to override, this environment variable.
* Opie
Opie - Open Palmtop Integrated Environment
Applications and libraries for mobile devices.
The Open Palmtop Integrated Environment (Opie) is a completely Open Source based
graphical user environment and suite of applications for PDAs and other devices running Linux.
It is included in various embedded Linux distributions such as OpenZaurus, Familiar and OpenSIMpad.
For more information on OPIE visit their web site. http://opie.handhelds.org/cgi-bin/moin.cgi/
* Using The Board Peripherals
Each board has a specific set of peripherals available; the way each peripheral
it utilized is described as follows (the availability of the peripheral on a
board is listed after the peripheral):
** Nor Flash
Access to the NOR FLASH is provided through the /dev/mtd?, /dev/mtdr?, and
/dev/mtdblock? device files. The /dev/mtd? device files are character
devices that provide read/write access, the /dev/mtdr? device files are
also character devices but provide read-only access, and the /dev/mtdblock?
device files are block devices. The first MTD device (i.e. /dev/mtd0)
always refers to the entire FLASH device; great care should be taken when
using it. The remaining devices refer to the various partitions that were
created from within RedBoot (partitions can only be created from within
RedBoot). The available partitions and their names can be found by typing
the following into a shell:
!cat /proc/mtd!
The "flash_eraseall" command can be used to erase the contents of a partition.
An empty partition can be used for a file system by enabling the JFFS or
JFFS2 filesystem in the kernel and the using "mount" to mount the
appropriate /dev/mtdblock device. The following menu items in the kernel
configuration must be enabled to support the JFFS or JFFS2 filesystems:
<*> File systems
<*> Journalling Flash File System (JFFS) support
<*> Journalling Flash File System v2 (JFFS2) support
For linux-2.6.8.1 the following menu items in the kernel configuration must be enabled to
support the NOR FLASH on the boards:
Memory Technology Devices (MTD)
<*> Memory Technology Device (MTD) support
<*> MTD partitioning support
<*> RedBoot partition table parsing
<*> Direct char device access to MTD devices
<*> Caching block device access to MTD devices
RAM/ROM/Flash chip drivers
<*> Detect flash chips by Common Flash Interface (CFI) probe
<*> Support for Intel/Sharp flash chips
<*> Support for AMD/Fujitsu flash chips
Mapping drivers for chip access
<*> CFI Flash device mapped on EDB93xx
Additionally, the following menu items are used to specify how the FLASH is
connected to the EP93xx, and how the EP93xx is booted:
System Type
EP93xx Implementations
(CSn6) FLASH chip select
FLASH chip options --->
FLASH size (16MB) --->
FLASH width (32bit) --->
[*] Synchronous boot mode
For the EDB9302A/07A/15A the selection is as follows.
System Type
EP93xx Implementations
(CSn6) FLASH chip select
FLASH chip options --->
FLASH size (16MB) --->
FLASH width (16bit) --->
[ ] Synchronous boot mode
Cirrus Logic ARM now supports multiple types and sizes of flash from the kernel config menu.
FLASH size is how large the chip is 2MB to 64MB.
FLASH width is 16 or 32 bit.
The default settings are appropriate for the default configuration of the
EDB93xx boards. If the board configuration jumpers are changed, then these
kernel configuration items must be changed to reflect the changes. This
tells the MTD driver where to find the FLASH in physical memory.
** Nand Flash
Access to the NAND FLASH is very similar with the NOR FLASH.
The following menu items in the kernel configuration must be enabled to
support the NAND FLASH + JFFS2 filesystem on the boards:
Memory Technology Devices (MTD) --->
NAND Flash Device Drivers --->
<*> EDB93xx NAND Flash Support
File systems --->
Miscellaneous filesystems --->
[*] JFFS2 support for NAND flash
Memory Technology Devices (MTD) --->
<*> NFTL (NAND Flash Translation Layer) support
[ ] Write support for NFTL
After booting up Linux, exec the following commands to format the NAND FLASH
with JFFS2 filesystem.
#flash_eraseall -j /dev/mtd?
Then mount this filesystem.
#mount -t jffs2 /dev/mtdblock? /mnt
** Ide
If a hard drive or CD-ROM drive are connected (or both), they can be accessed as /dev/hda and /dev/hdb exactly the same
as on a desktop Linux system. Consult the man pages on a desktop Linux system to see how to mount a partition
("mount"), partition a disk ("fdisk"), format a partition ("mke2fs" and "mkdosfs"), and use a partition as swap space
("swapon", "swapoff", and "mkswap").
The following menu items in the kernel configuration must be enabled to support the IDE interface on an EDB9312,
EDB9315 and EDB9315A:
<*> ATA/ATAPI/MFM/RLL support
<*> Enhanced IDE/MFM/RLL disk/cdrom/tape/floppy support
<*> Include IDE/ATA-2 DISK support
<*> Include IDE/ATAPI CDROM support
<*> generic/default IDE chipset support (NEW)
[*] EP93xx support
[*] EP93xx IDE DMA support
** Network
A web server is started by the init scripts. Once the network is
configured, determine the IP address of the board with "ifconfig". Then,
in a web browser on another machine, browse to that IP address (with the
"http://{IP}" URL). Additionally, a telnet server is also started, so you
could also telnet into the board with "telnet {IP}"; it will give the same
banner as the console and dump you to a shell without any authentication.
There is also a telnet client, so you can telnet from the board to another
machine.
The following menu items in the kernel configuration must be enabled to
support the network on an EDB9301, EDB9302/A, EDB9307/A, EDB9312, EDB9315/A:
Networking options
<*> Packet socket
[*] Socket Filtering
[*] TCP/IP networking
Network device support
[*] Network device support
Ethernet (10 or 100Mbit)
<*> EP93xx Ethernet support
The "Networking options/Packet socket" and "Networking options/Socket
Filtering" options only need to be enabled if the DHCP client is to be
used; otherwise they can be disabled (if desired).
** Pcmcia
The following menu items in the kernel configuration must be enabled to support the PCMCIA interface on the EDB9315:
Loadable module support --->
[*] Enable loadable module support
[*] Module unloading
[*] Automatic kernel module loading
General setup --->
[*] Support for hot-pluggable devices
General setup --->
PCMCIA/CardBus support --->
<*> PCMCIA/CardBus support
<*> EP93xx support
For PCMCIA Ethernet devices the following should be enabled in the kernel
PCMCIA network device support
[*] PCMCIA network device support
< > 3Com 3c589 PCMCIA support
< > 3Com 3c574 PCMCIA support
< > Fujitsu FMV-J18x PCMCIA support
<*> NE2000 compatible PCMCIA support
< > New Media PCMCIA support
< > SMC 91Cxx PCMCIA support
< > Xircom 16-bit PCMCIA support
< > Asix AX88190 PCMCIA support
A Prism2-based 802.11b PCMCIA card can be inserted into the PCMCIA slot to enable wireless networking. The scripts on the ramdisk were tested using a Lucent Technologies Orinoco Gold Card, and connect to an unencrypted wireless network with a SSID of "linksys". The scripts will have to be modified to allow connection to the wireless network at your location (or a wireless AP can be setup with the above parameters). The configuration and management of the PCMCIA subsystem is via the pcmcia-cs package; see its documentation for details on how to configure it. The following additional items must be enabled in the kernel configuration in order to support 802.11b PCMCIA cards:
Networking support --->
Wireless LAN (non-hamradio) --->
[*] Wireless LAN drivers (non-hamradio) & Wireless Extensions
<*> Hermes chipset 802.11b support (Orinoco/Prism2/Symbol)
<*> Hermes PCMCIA card support
A compact FLASH card can be inserted into the PCMCIA slot (via a CF->PCMCIA converter) and accessed as a hard drive. It will appear as either hda (if the IDE driver is not enabled) or as hdc (if the IDE driver is enabled). The following additional items must be enabled in the kernel configuration in order to support compact FLASH cards:
ATA/ATAPI/MFM/RLL support --->
<*> Enhanced IDE/MFM/RLL disk/cdrom/tape/floppy support
<*> PCMCIA IDE support
<*> Include IDE/ATA-2 DISK support
<*> PCMCIA IDE support
** SDRAM Linux-2.6.8.1 ONLY
On these part, the SDRAM can be connected to any of four SDRAM chip
selects. The following menu items are used to specify how the SDRAM is
connected to the EP93xx, and how the EP93xx is booted:
System Type
EP93xx Implementations
(SDCSn3) SDRAM chip select
[*] Synchronous boot mode
For the EDB9302A/07A/15A the selection is as follows.
System Type
EP93xx Implementations
(SDCSn0) SDRAM chip select
[ ] Synchronous boot mode
The default settings are appropriate for the default configuration of the
EDB93xx boards. If the board configuration jumpers are changed, then these
kernel configuration items must be changed to reflect the changes. This
tell the kernel where to expect the SDRAM in physical memory.
While RedBoot passes tags to the Linux kernel telling it where the actual
SDRAM memory blocks are located, the kernel still has a built-in idea of
the base physical address of SDRAM. This must change to reflect the actual
base physical address in order for the kernel to properly map addresses
between logical address space and physical address space.
** Uart
A shell is started on the first serial port. Use a NULL modem cable to
connect that serial port to another system, run a terminal emulation
program on the other system, and press "" to start the shell. The
communications settings should be 57,600 8-N-1 for the boards.
The other serial port is not used by default; either an additional entry could be added to /etc/inittab to
start a shell, or the serial port could be used for KGDB.
The following menu items in the kernel configuration must be enabled to
support the serial ports.
Linux-2.6.8.1 ONLY
Character devices
Serial drivers
<*> Cirrus EP93xx serial port support
[*] Support for console on EP93xx serial port
Linux-2.6.17.14 and above
Character devices --->
Serial drivers --->
<*> ARM AMBA PL010 serial port support
[*] Support for console on AMBA serial port
** Touchscreen
The touch screen can be used by OPIE on the EDB9307/A, EDB9312, and EDB9315/A. OPIE and QT now use the tslib system to use the touchscreen.
The /dev/misc/ep93xx_ts will provide the touch screen data (8 bytes per sample) in the following format:
- 2 bytes for the pressure
- 2 bytes for the approximate X position
- 2 bytes for the approximate Y position
- 2 bytes of padding
An 8 byte sample is produced approximately every 200us during the time that the pen pressure is above the builtin threshold.
The following menu items in the kernel configuration must be enabled to support the touch screen on the EDB9307/A, EDB9312, or EDB9315/A
--- Input devices (needed for keyboard, mouse, ...)
--- Input Device Drivers
[*] Touchscreens
<*> EP93xx Touchscreen
The tslib system requires several environment variables to be set in order to use the touchscreen. The file /sbin/start-opie contains the appropriate variables to use the touchsreen.
export TSLIB_PLUGINDIR=/lib/ts
export TSLIB_TSDEVICE=/dev/misc/ep93xx_ts
export TSLIB_CALIBFILE=/etc/pointercal
export TSLIB_CONFFILE=/etc/ts.conf
export TSLIB_FBDEVICE=/dev/fb0
export TSLIB_CONSOLEDEVICE=/dev/tty
To use the touchscreen with QT Embedded, the following variables also need to be set
export QWS_MOUSE_PROTO=TPanel:/dev/misc/ep93xx_ts
Tslib comes with a few example and test programs in the ramdisk. They are as follow.
- ts_calibrate
- ts_harvest
- ts_print_raw
- ts_test
For more information about tslib please refer to http://cvs.arm.linux.org.uk
** USB Host
The following menu items in the kernel configuration must be enabled to
support the USB host:
USB support
<*> Support for USB
[*] Preliminary USB device filesystem
<*> OHCI-compatible host interface support
To connect keyboards, mice, joysticks, graphic tablets, or any other HID based
devices to your computer via USB the following must be enabled:
--- USB Human Interface Devices (HID)
<*> USB Human Interface Device (full HID) support
[*] HID input layer support
For the EDB9302/A, EDB9307/A, EDB9312 and EDB9315/A , these are enabled by
default. For the EDB9301, which does not have the USB connector populated
by default, these must be enabled after the USB connector has been
populated as decribed in the AN255 application note on Cirrus Logics website
http://www.cirrus.com/en/pubs/appNote/AN255REV2.pdf
Several options are available to use the USB host port:
*** Mass Storage
The following menu items in the kernel configuration must be enabled to support a USB mass storage device:
SCSI support
<*> SCSI support
<*> SCSI disk support
USB support
<*> USB Mass Storage support
The following menu items in the kernel configuration will typically need
to be enabled since most USB mass storage devices use the DOS FAT file
system:
File systems
DOS/FAT/NT Filesystems --->
<*> DOS FAT fs support
<*> VFAT (Windows-95) fs support
(437) Default codepage for FAT (NEW)
(iso8859-1) Default iocharset for FAT (NEW)
Partition Types --->
[*] Advanced partition selection
[*] PC BIOS (MSDOS partition tables) support
Native Language Support --->
(iso8859-1) Default NLS Option
<*> Codepage 437 (United States, Canada)
<*> NLS ISO 8859-1 (Latin 1; Western European Languages)
When a mass storage device is plugged in, it will appear as "/dev/sd?"
(typically it will be /dev/sda). The device can be partitioned with
"fdisk", or partitions mounted with "mount". Even though USB is a
hotplug bus, it is recommended to not hot-unplug a mass storage device
since cached write data will then be lost, leaving the filesystem on the
device corrupted. Instead, make sure all filesystems are unmounted
before unplugging the device.
*** 802.11b
The following menu items in the kernel configuration must be enabled to support a USB 802.11b device:
Loadable module support
[*] Enable loadable module support
General setup
[*] Support for hot-pluggable devices
Network device support
[*] Network device support
Wireless LAN (non-hamradio)
[*] Wireless LAN (non-hamradio)
Additionally, the linux-wlan-ng package must be on the root filesystem
(it is placed on the ramdisk via the "build_wlan_ng" procedure).
A Prism2-based USB 802.11b device can then be used. On the EDB9302/A,
EDB9307/A, EDB9312, and EDB9315/A targets, the "/sbin/hotplug" script will
setup a D-Link DWL-122 USB 802.11b device; it will connect to an
unencrypted wireless network with a SSID of "linksys?. The hotplug script can be changed to
support different device, a different SSID, a different encryption key,
or the ability to connect to an unencrypted wireless network.
*** 802.11g
The USB 802.11g device will be added into Linux kernel as a separate module.
The USB 802.11g device packages must be on the root filesystem(it is placed on the ramdisk via the "build_rt73" procedure ).
We now support ralink rt73 USB 802.11g device.
Additionally, the wpa_supplicant and open ssl packages must be on the root filesystem
(it is placed on the ramdisk via the "build_wpa" procedure, "build_openssl" procedure ).
Throught wpa_supplicant, we support WPA/WPA2. The WPA config file is placed in /etc/wpa_supplicant.conf
For different WPA modes, the config is different also, the config file need to be changed.
In the /etc/wpa_supplicant.conf, we provide some example.
A Ralink rt73 USB 802.11g device can then be used. On the EDB9302/A,
EDB9307/A, EDB9312, and EDB9315/A targets, the "/sbin/hotplug" script will
setup an ralink rt73 USB 802.11g device; it will connect to an
unencrypted wireless network with a SSID of "linksys. The hotplug script can be changed to
support different device, a different SSID, a different encryption key,
or the ability to connect to an unencrypted wireless network.
*** I2C RTC device
The following menu items in the kernel configuration must be enabled to support an I2C RTC device:
Linux-2.6.8.1 ONLY
Loadable module support
[*] Enable loadable module support
I2C setup
<*> I2C support
<*> I2C device interface
I2C Algorithms --->
<*> I2C bit-banging interfaces
I2C Hardware Bus support --->
<*> EP93XX I2C
Other I2C Chip support --->
<*>ISL 1208 RTC chip
Character devices
[*] RTC for Intersil 1208 device on Cirrus Logic EP93xx boards
Linux-2.6.17.14 and above
Loadable module support
[*] Enable loadable module support
I2C support
<*> I2C support
<*> I2C device interface
I2C Algorithms --->
<*> I2C bit-banging interfaces
I2C Hardware Bus support --->
<*> EP93XX I2C
Real Time Clock --->
<*> Cirrus Logic EP93XX
[ ] Cirrus Logic EDB93XX EMBEDDED
<*> RTC CHIP ISL1208
An Intersil ISL1208 External RTC chip device can then be used. On the EDB9302A,
EDB9307A, and EDB9315A targets, the "/sbin/hwclock" script will query and set the hardware clock.
And about features of RTC device, we only support the get time and set time two features.
More details are located in linux-2.6/Documentation/rtc.txt
*** Ethernet device
One of the following menu items in the kernel
configuration must be enabled to support a USB ethernet device:
USB support
<*> USB Pegasus/Pegasus-II based ethernet device support
<*> USB KLSI KL5USB101-based ethernet device support
This covers the most common USB ethernet devices; one of the other
choices might need to be selected based on the USB ethernet device that
is being used.
When plugged in, the device will appear as eth1 (or eth2, or eth3, etc.).
Standard network configuration can then be done to enable the interface
(i.e. "ifconfig eth1 < ip > up" or "udhcpc -i eth1"). Be sure to kill the
DHCP client (if started) and "ifconfig eth1 down" the interface before
unplugging the device.
** USB Slave EDB9312/15, EDB9307A, EDB9315A, and EDB9302A
The following menu items in the kernel configuration must be enabled to
support the USB host:
<*> Support for USB Gadgets
USB Peripheral Controller (EP931x USB Slave) --->
EP931x USB Slave
< M > USB Gadget Drivers
< > Gadget Zero (DEVELOPMENT)
< > Ethernet Gadget
< > Gadget Filesystem (EXPERIMENTAL)
< M > File-backed Storage Gadget (DEVELOPMENT)
[*] File-backed Storage Gadget test version
< > Serial Gadget
On EDB91x platform, insmod the gadget file storage to activate USB Slave.
#mke2fs /dev/ram1
#insmod g_file_storage.ko file=/dev/ram1 stall=0 removable=1
Plug the usb connector to the PC running with linux, exec this command.
#mount /dev/sda
Copy some files to it and have fun with it.
Note:
- Due to the share of EGPIO12, the usb slave conflicts with the ps2 keyboard.
- Due to the schema of gadget device in linux 2.6. You must use it
as a module because of no default module parameter for such module.
** PS/2 Keyboard EDB9312 or EDB9315
Simply type to use the keyboard on the virtual console. In order to use a
PS/2 keyboard, they must be plugged in when the Linux is started. The PS/2
keyboard support on the EDB9312/EDB9315 is shaky at best due to the
inherent deficiencies in the hardware interface on the board; it is highly
recommend that a USB keyboard be used instead.
The following menu items in the kernel configuration must be enabled to
support a PS/2 keyboard on an EDB9312 or EDB9315:
Input device support --->
--- Input Device Drivers
[*] Keyboards
[*] AT keyboard support
[ ] Sun Type 4 and Type 5 keyboard support
[ ] DECstation/VAXstation LK201/LK401 keyboard support
[ ] XT Keyboard support
[ ] Newton keyboard
[*] EP93xx Keyboard support
[*] EP93xx PS2 Keyboard support
** Display EDB9307/A, EDB9312, EDB9315/A
The following menu items in the kernel configuration must be enabled to
support the frame buffer.
Linux-2.6.8.1 ONLY
Graphics support --->
[*] Support for frame buffer devices
[*] EP93xx frame buffer support
EP93xx frame buffer display (LCD display) --->
( ) CRT display
(X) LCD display
( ) NTSC display
( ) PAL display
EP93xx frame buffer depth (16bpp true color) --->
( ) 8bpp pseudo color
(X) 16bpp true color
[ ] Virtual Frame Buffer support (ONLY FOR TESTING!)
Console display driver support --->
[ ] VGA text console
[ ] MDA text console (dual-headed) (EXPERIMENTAL)
[*] Framebuffer Console support
[*] Select compiled-in fonts
[*] VGA 8x8 font
[ ] VGA 8x16 font
[ ] Mac console 6x11 font (not supported by all drivers)
[ ] Pearl (old m68k) console 8x8 font
[ ] Acorn console 8x8 font
[ ] Mini 4x6 font
[ ] Sparc console 8x16 font
[ ] Sparc console 12x22 font (not supported by all drivers)
Logo configuration --->
[*] Bootup logo
[*] Standard black and white Linux logo
[*] Standard 16-color Linux logo
[*] Standard 224-color Linux logo
Linux-2.6.17.14 and above
Graphics support --->
[*] Support for frame buffer devices
[*] EP93xx frame buffer support
[ ] Virtual Frame Buffer support (ONLY FOR TESTING!)
Console display driver support --->
[ ] VGA text console
[ ] MDA text console (dual-headed) (EXPERIMENTAL)
[*] Framebuffer Console support
[*] Select compiled-in fonts
[*] VGA 8x8 font
[ ] VGA 8x16 font
[ ] Mac console 6x11 font (not supported by all drivers)
[ ] Pearl (old m68k) console 8x8 font
[ ] Acorn console 8x8 font
[ ] Mini 4x6 font
[ ] Sparc console 8x16 font
[ ] Sparc console 12x22 font (not supported by all drivers)
Logo configuration --->
[*] Bootup logo
[*] Standard black and white Linux logo
[*] Standard 16-color Linux logo
[*] Standard 224-color Linux logo
** Audio
Cirrus Logic ARM development boards EDB9301, EDB9302/A, EDB9307A, and EDB9315A support I2S audio with the CS4271 chip.
The I2S driver's capability is as follows,
For raw PCM data
_Audio Format: S8, U8, S16_LE, U16_LE, S24_LE, U24_LE_
_Sample Rate: 8000, 16000, 32000, 48000, 11025, 22050, 44100_
For WAV data
_Audio Format: U8, S16_LE, S24_LE_
_Sample Rate: 8000, 16000, 32000, 48000, 11025, 22050, 44100_
The following menu items in the kernel configuration must be enabled to
support the I2S audio interface on an EDB9301, EDB9302/A, EDB9307A, and EDB9315A:
Sound --->
[*] Sound card support
Advanced Linux Sound Architecture --->
[*] Advanced Linux Sound Architecture
[*] OSS Mixer API
[*] OSS PCM (digital audio) API
ALSA ARM devices --->
[*] EP93xx ALSA iis audio driver
[*] Cirrus cs4271 2-channels sound
The ramdisk for the boards contains the arecord, aplay and amixer application.
For example,
For raw PCM data
_arecord -c 2 -d 10 -f S16_LE -r 44100 -t raw test.dat_
It will record 10 seconds, 16 bit, 44.1Khz sample rate, stereo audio and store in raw PCM data.
_aplay -c 2 -d 10 -f S16_LE -r 44100 -t raw test.dat_
It will play 10 seconds, 16 bit, 44.1Khz sample rate, stereo audio.
For WAV data
_arecord -c 2 -d 10 -f S16_LE -r 44100 -t wav test.wav_
It will record 10 seconds, 16 bit, 44.1Khz sample rate, stereo audio and store in wav file.
_aplay -c 2 -d 10 -f S16_LE -r 44100 -t wav test.wav_
It will play 10 seconds, 16 bit, 44.1Khz sample rate, stereo audio.
The amixer application can be used to control the volume.
_amixer set Master 90_
It will control the volume of CS4271 codec.
Note: The one bit of CS4271 volume control register is correponding to 1db.
Use "arecord --help", "aplay --help", "amixer --help" to get more information.
Cirrus Logic ARM development board EDB9307, EDB9312, EDB9315 support I2S audio with the CS4228 chip.
The I2S driver's capability is as follows,
Raw PCM data
_Audio Format: S8, U8, S16_LE, U16_LE, S24_LE, U24_LE_
_Sample Rate: 8000, 16000, 32000, 48000, 11025, 22050, 44100_
WAV data
_Audio Format: U8, S16_LE, S24_LE_
_Sample Rate: 8000, 16000, 32000, 48000, 11025, 22050, 44100_
The following menu items in the kernel configuration must be enabled to
support the I2S audio interface on an EDB9307, EDB9312 or EDB9315:
Sound --->
[*] Sound card support
Advanced Linux Sound Architecture --->
[*] Advanced Linux Sound Architecture
[*] OSS Mixer API
[*] OSS PCM (digital audio) API
ALSA ARM devices --->
[*] EP93xx ALSA I2S audio driver
[*] Cirrus CS4228A 6-channel Sound
Note: The one bit of CS4228 volume control register is correponding to 0.5db.
Cirrus Logic ARM development board EDB9307, EDB9312, EDB9315 support AC97 audio with the CS4202 chip.
The AC97 driver's capability is as follows,
Raw PCM data
_Audio Format: S8, U8, S16_LE, U16_LE_
_Sample Rate: 8000, 16000, 32000, 48000, 11025, 22050, 44100_
WAV data
_Audio Format: U8, S16_LE_
_Sample Rate: 8000, 16000, 32000, 48000, 11025, 22050, 44100_
The amixer application can be used to control the volumes of 6 channels.
# amixer scontrols
Simple mixer control 'Master',0
Simple mixer control 'PCM',0
Simple mixer control 'Surround',0
Simple mixer control 'Center',0
Simple mixer control 'LFE',0
# amixer sset Master 181
# amixer sset PCM 181
# amixer sset Surround 181
# amixer sset Center 181
# amixer sset LFE 181
The aplay application can be used to play multiple-channel audio with the following options.
aplay -D channels2 stereo_audio_file.wav
aplay -D channels4 stereo_audio_file.wav
aplay -D channels6 stereo_audio_file.wav
The following menu items in the kernel configuration must be enabled to
support the AC97 audio interface on an EDB9307, EDB9312 or EDB9315:
Sound --->
[*] Sound card support
Advanced Linux Sound Architecture --->
[*] Advanced Linux Sound Architecture
[*] OSS Mixer API
[*] OSS PCM (digital audio) API
ALSA ARM devices --->
[*] AC97 driver for the Cirrus EP93xx chip
_amixer set Headphone 20_
It will control the volume of the CS4202
Note: The one bit of CS4202 volume control register is correponding to 1.5db.
*** Using Madplay
Madplay cannot be built with the new gcc-4.x toolchains. To use Madplay you must use the gcc-3.4.3 toolchain
All development boards now come with madplay command line MP3 playback.
http://www.underbit.com/products/mad
madplay is a command-line MPEG audio decoder and player based on the MAD library (libmad). For details about MAD, see the libmad package distributed separately.
After decoding, madplay sends the output to an audio output module. The following audio output modules are provided:
- an Open Sound System interface module (for Linux, et al.)
- a Sun audio interface module (for Solaris, NetBSD, et al.)
- a Mac OS Carbon audio interface module (for Mac OS X)
- a Win32 audio interface module (for Windows 95/98/NT/2000, et al.)
- an ALSA audio interface module
- a QNX audio interface module
- an EsounD interface module
- a CD audio output module (*.cdr, *.cda)
- an Audio IFF output module (*.aif, *.aiff)
- a Microsoft RIFF/WAVE file output module (*.wav)
- a Sun/NeXT audio file output module (*.au, *.snd)
- a raw PCM output module
- a hex output module (for debugging and compliance testing)
- a null module (for timing the decoder)
madplay will also read and display ID3 tag information, and further supports the relative volume adjustment information (RVA2) in such tags, as written by tools like `normalize'.
**** Audio Quality
MAD produces output samples with a precision greater than 24 bits. Because most output formats use fewer bits, typically 16, `madplay' implements a dithering algorithm when truncating samples for output. This produces high quality audio that generally sounds superior to the output of a simple rounding algorithm. However, dithering may unfavorably affect an analytic examination of the output (such as compliance testing), and therefore it may optionally be disabled at runtime.
** Consumer IR
The consumer IR is accessed via the lircd daemon, which is launched by the
startup script (/etc/rc.sysinit). Additionally, a mouse emulation daemon
is also launched (lircmd) that allows a remote control to emulate an
IntelliMouse. The 1, 2, 3, 6, 9, 8, 7, and 4 buttons are used to move the
mouse (in the relative directions expected based on the locations of the
buttons), the 5 button will click the left mouse button, and the 0 button
will toggle the left mouse button (so drag-and-drop operations can be
performed). The default configuration will respond to a Sony TV remote
control. Set QWS_MOUSE_PROTO to "IntelliMouse:/dev/lircm" and run any of
the Qt demos to try out the mouse emulation. See the lirc documentation
for details on customizing the package for other remote control types and
writing custom applications to respond to IR events.
** SIR IrDA
All options configured as built-in drivers, not loadable modules.
Configuration in _make menuconfig_:
Device Drivers -->
[*] Networking device support
<*> PPP (point-to-point protocol) support
[ ] PPP multilink support (EXPERIMENTAL)
[ ] PPP filtering
<*> PPP support for async serial ports
< > PPP support for sync tty ports
<*> PPP Deflate compression
<*> PPP BSD-Compress compression
< > PPP over Ethernet (EXPERIMENTAL)
<*> SLIP (serial line) support
[*] CSLIP compressed headers
[*] Keepalive and linefill
[*] Six bit SLIP encapsulation
Networking -->
<*> IrDA (infrared) subsystem support --->
--- IrDA (infrared) subsystem support
--- IrDA protocols
< M > IrLAN protocol
< M > IrNET protocol
<*> IrCOMM protocol
[*] Ultra (connectionless) protocol
--- IrDA options
[*] Cache last LSAP
[*] Fast RRs (low latency)
[ ] Debug information
Infrared-port device drivers --->
--- SIR device drivers
<*> IrTTY (uses Linux serial driver)
--- Dongle support
[*] Serial dongle support
<*> Cirrus EP93xx SIR dongle
To start the IrDA stack and begin discovery, boot Linux and type the
following command:
irattach /dev/ttyAM1 -d ep93xx_sir -s
This informs the IrDA stack that the EP93xx's SIR is on its UART2
(which is why the driver is implemented as a dongle driver).
* Using KGDB
KGDB allows source level debugging of the Linux kernel by placing a debugging
stub in the kernel that understands the GDB remote debugging protocol over a
serial connection. It is enabled in the "Kernel hacking" menu of the kernel
configuration. Simply say yes to the following options (each option is made
available by selecting the previous option):
Kernel hacking
[*] Include debugging information in kernel binary
[*] Kernel debugging
[*] KGDB support
[*] KGDB over serial port
(1) KGDB serial port UART selection
(115200) KGDB serial port BAUD rate selection
The final two options should be set as appropriate; typically UART1 will be
used for the EDB7312, EDB9301, and EDB9302, and UART2 will be used for the
EDB9307, EDB9312, and EDB9315. The baud rate should be set to 115200 for best
performance; it can be set lower if reliability problems occur.
The following option can also be enabled to allow the KGDB connection to act as
the system console (in write-only mode):
Kernel hacking
[*] Console messages over KGDB
This will register the KGDB stub as a console; it will only be selected if
"console=ttyKGDB" is passed to the kernel on its command line (or no other
consoles are available).
The following options can also be enabled to allow an asynchronous break into
KGDB:
Kernel hacking
[*] Magic SysRq key
[*] Enable SysRq-D command to invoke kgdb via breakpoint?
Then, pressing the SysRq-D sequence (i.e. press the "D" key while holding down
the "SysRq" key) will stop execution of the kernel and give control to KGDB.
This is useful since Ctrl-C in the GDB on the host is not able to stop
execution of the kernel; SysRq-D must be used in its place.
Before rebuilding the kernel with KGDB support, it is recommended that a "make
clean" be performed on the Linux source tree. This will remove all object
files, so that they will be re-built with source level debugging support.
On the root file system to be used with the KGDB-enabled kernel, make sure that
the serial port used for KGDB is not used for anything else. Mainly this means
disabling any shells or gettys on that serial port (via /etc/inittab).
After the kernel has been configured for KGDB support, rebuilt, and run on the
target, it will appear that the system has hung. This is normal. There is a
breakpoint in the kernel at the earliest possible place to allow as much of the
startup sequence to be debugged.
On the host, a serial port must be connected to the target with a NULL modem
cable. The following examples assume that /dev/ttyS0 is used; simply replace
it with the port appropriate to your setup. The baud rate of the host serial
port must be set to the rate used by the target; for a 115200 baud connection
use:
_stty -F /dev/ttyS0 ospeed 115200_
The next step is to run GDB on the host PC; type:
_arm-linux-gdb vmlinux_
from the base directory of the linux source tree. This will load the ELF
version of the Linux kernel, providing the source level information to GDB.
Then, type the following into GDB:
target remote /dev/ttyS0
This will connect to the KGDB stub on the target and get the current state.
Since it will be stopped on a breakpoint (the target MUST be at a breakpoint
when the "target remote" command is issued in GDB or it will get out of sync)
it will display:
0xc00214e4 in breakpoint () at kgdb-stub.c:1121
1121 BREAKPOINT();
indicating the current location within the kernel, and the corresponding line
of source code (the address and line number may vary). Normal GDB commands can
then be executed. See the GDB documentation for details of how to use GDB to
debug a program.
Some trial and error is required to understand what can and can not be done
with KGDB. When KGDB gains control, the kernel is already running (and can not
be restarted by KGDB) so the "run" command can not be used; "continue" is used
instead to resume execution of the kernel. Some functions in the kernel never
return, so stepping over them (with "next") will never return control to KGDB.
It is not possible to break into the kernel with Ctrl-C, so allowing execution
to continue without some active breakpoint will not allow KGDB to regain
control (other than via SysRq-D if enabled, or an unhandled kernel fault).
* Building GDB Server
gdbserver is a similar to KGDB except that it allows user level program to be
debugged. It is a small program that runs an application as an inferior
process and allows control of that program via a remote application that
understands the GDB remote debug protocol. Since gdbserver is a user level
process, it has full access to the capabilities of the Linux kernel, allowing
it to provide a communcations channel over the network, eliminating the need
for a NULL modem serial connection.
To use gdbserver with a network connection (in these examples, it is assumed
that the IP address of the target is 192.168.1.101 and the IP address of the
host is 192.168.1.100), type the following into a shell on the target:
_gdbserver 192.168.1.100:8888 app_
replacing "app" with the application to be debugged. Then, on the host, type:
_arm-linux-gdb app_
to start GDB and then:
_target remote 192.168.1.101:8888_
To connect to the gdbserver on the target. Normal GDB commands can now be
executed to debug the application.
gdbserver can also use a serial connection for debugging purposes. The serial
ports on both the host and target must be unused (i.e. no shells, gettys, etc.)
and must have their speeds set the same via:
_stty -F /dev/ttyXX ospeed 115200_
where ttyAMXX will be used on the target and ttySX will be used on the host.
Then type the following into a shell on the target:
_gdbserver /dev/ttyAM1 app_
replacing "/dev/ttyAM1" with the appropriate serial port and "app" with the
application to be debugged. Then, on the host, type:
_arm-linux-gdb app_
to start GDB and then
_target remote /dev/ttyS0_
replacing "dev/ttyS0" with the appropriate serial port. Normal GDB commands
can now be executed to debug the application. Since the application is already
running (and can not be restarted by gdbserver), the _run_ command is not
valid; use _continue_ instead to resume execution of the application. Unlike
remote debugging with KGDB, _Ctrl-C_ can be used to stop execution of the
application and return control to GDB.
In order to perform source level debugging, the application must be built
without optimizations and with source level debugging enabled. Typically, this
produces applications that are quite large, though most of this is the extra
debugging information that is not used by Linux to run the application. The
large version of the application is needed by GDB to provide source level
debugging, but a stripped version (which will be much smaller) can be run on
the target (i.e. "arm-linux-strip app"). Consult the GDB documentation for
details on how to build applications for debugging and how to use GDB to debug
applications.
* Installing Debian
To install Debian, either a hard drive or a r/w NFS share is needed. If using
a hard drive, connect it to the IDE port of the board, supply it power from an
external power supply, and start RedBoot. In RedBoot, type the following:
load -r -v -b 0x800000 debian_root.gz
load -r -v -b 0x80000 zImage
Then, if using an EDB7312 board, start the kernel with this command:
exec -r 0x800000 -s 0x200000 -c "root=/dev/ram video=edb7312fb:font=vtx4x8"
The "video=" option will choose a 4x8 font for the LCD. This font is a bit
difficult to read, but allows a full 80 columns on the LCD. The standard 6x8
font only provides 53 columns, and the Debian install is not very friendly on a
display less than 80 columns (you'll only see the middle portion of the
display). The 4x8 font is a tradeoff; you can see the entire screen, but some
of the glyphs are a bit difficult to decipher.
If using an EDB93xx board, start the kernel with this command:
exec -r 0x800000 -s 0x200000
Once the Debian installer starts, simply follow the directions. It will do the
following things:
- Configure the keyboard. Your selection depends on your keyboard. This
option will not be presented if using a serial console for the
installation.
- Partition the hard disk. Create a partition for swap space (at least
64MB, of type 82) and a partition for the root (at least 128MB).
- Initialize and Active a Swap Parition. Do not run the bad block scan
(unless you have a lot of time to kill).
- Initialize a Linux Parition. It doesn't really matter if you use EXT2
or EXT3. Again, do not run the bad block scan. Mount the partition as
/target.
- Install Kernel and Driver Modules. Select the network installation
medium. It will make you configure the network; this is dependent upon
your network. Don't bother to change the download URL or the proxy,
this step is going to fail anyway. If this step is skipped, though,
the base system install in the next step will fail.
- It will still want to install the kernel and driver modules. Instead,
cursor down to "Install the Base System" and select it. Again, choose
a network install. The US debian mirror is the default URL; optionally
change it to get to a closer (or faster) mirror based on your location.
Also, set the proxy information as appropriate.
- Sit back and wait; it will take 30 minutes or so.
- When it gets done, it will again want to install the kernel and driver
modules. Instead, cursor down to "Start a shell". Type "fixttys" in
the shell and then exit the shell. This is to fix the /dev/ttyS? device
entries to point to the proper ARM serial ports instead of the PC serial
ports.
- It will again want to install the kernel and driver modules.
Instead, cursor down to "Unmount a partition" and umount the /target partition.
- It will now want to initialize a linux partition again. Instead,
cursor down to "Reboot the System".
It will now restart and dump you back into RedBoot. Now, simply load the
kernel and start the system as follows:
load -r -v -b 0x80000 zImage
exec -c "root=/dev/hda2 video=edb7312fb:font=vtx4x8"
where /dev/hda2 is replaced with the partition used for the root filesystem,
and the video= is only used for EDB7312 boards. The installation will
continue, configuring the base packages and giving you the option to install
additional packages. Simply follow the directions on the screen.
If installing to a NFS partition, then several things need to be done
differently. First, you will need to rebuild the kernel so that it can mount
its root file system from NFS. The following menu items in the kernel
configuration must be enabled to support nfsroot:
Networking options
[*] TCP/IP networking
[*] IP: kernel level autoconfiguration
File systems
Network File Systems
[*] NFS file system support
[*] Root file system on NFS
Then, steps 2, 3, and 4 above are not necessary. Instead, perform the
following steps in their place:
- Configure the network. The configuration of the network is dependent
upon your network.
- Mount a root filesystem via NFS. Specify the NFS path to the root
filesystem to be used. It must be exported read/write from the server,
and have "no_root_squash" or equivalent permissions (i.e. allow the
remote mount to place files on the server with any uid/gid, including
0/0).
- Continue with step 5 above.
Then, when the install is complete and the system restarts, load the kernel
and start the system as follows:
load -r -v -b 0x80000 zImage
exec -c "root=/dev/nfs ip=... nfsroot=... video=edb7312fb:font=vtx4x8"
This "video=" option is only used for EDB7312 boards. For details on the "ip="
and "nfsroot=" kernel command line options, see the NFS root documentation in
linux-2.4.21/Documentation/nfsroot.txt. For a target with a static IP of
192.168.1.101, a server with a static IP of 192.168.1.100, and the root
residing on /target, the "ip=" and "nfsroot=" would be:
ip=192.168.1.101:192.168.1.100::::eth0:off
nfsroot=/target
For more details about Debian Linux, visit their website at
http://www.debian.org.
* Kernel Command Line Options
The following kernel command line options are specific to Cirrus Logic drivers:
- cs89x0_dma= Select the DMA channel to be used for the cs89x0. DMA is
not supported, so this option should not be specified. This
driver is only used on the EDB7312.
- cs89x0_media= Force the media type for the cs89x0. Possible choices are
"rj45", "aui", and "bnc". This driver is only used on the
EDB7312.
- nohalt Tell KGDB to not halt execution of the kernel at startup.
This means that the kernel will only stop when there is an
exception that can not be handled, or if the SysRq-D key is
pressed (if enabled). GDB can not be started until KGDB has
halted the kernel, so this option has limited value.
- video=edb7312fb Specify options for the edb7312fb frame buffer driver. This
driver is only used on the EDB7312. The options are
specified as a comma-separated list appended to
"video=edb7312fb:".
The valid options for the EP7312FB are:
- font= Specify the default font to be used for the frame buffer.
Valid values depend upon the available fonts in the kernel;
typical values are "vtx4x8", "vtx6x8", or "VGA8x8".
- video=ep93xxfb Specify options for the ep93xxfb frame buffer driver. This
driver is only used on the EDB9307/A, EDB9312, and EDB9315/A.
The options are specified as a comma-separated list appended
to "video=ep93xxfb:".
The valid options for the EP93xxFB are:
Parameters:
vmode - Specify the vmode mode number that should be used
vout - Specify video output(0 = CRT ,1 = LCD , 2 = TV)
depth - Color depth (8,16,24,32)
vout = 0 (CRT),vmode = 1-15,depth = 8,16,24,32
vmode Resolution
1 CRT-640x480-60
2 CRT-640x480-72
3 CRT-640x480-75
4 CRT-640x480-85
5 CTR-640x480-100
6 CRT-800x600-56
7 CRT-800x600-60
8 CRT-800x600-72
9 CRT-800x600-85
10 CRT-800x600-100
11 CRT-1024x768-60
12 CRT-1024x768-70
13 CRT-1024x768-75
14 CRT-1024x768-85
15 CRT-1280x720-60
vout = 1 (Philips-LB064V02),vmod = 0,depth = 16
0 Philips-LB064V02-640x480x60
vout = 2(TV),vmode = 0-23,depth = 8,16,24,32
vmode res Purpose of Mode Overscan
0 NTSC 640x400 Boot-up Screan Standart
1 NTSC 640x480 Desktop Lower
2 NTSC 640x480 Desktop Higher
3 NTSC 720x400 Boot-up Screen Standart
4 NTSC 720x480 DVD Very Low
5 NTSC 800x600 Desktop Alternate
6 NTSC 800x600 Desktop Lower
7 NTSC 800x600 Desktop Higher
8 NTSC 800x600 Desktop Standart
9 NTSC 1024x768 Desktop Standart
10 NTSC 1024x768 Desktop Lower
11 NTSC 1024x768 Desktop Higher
12 PAL 640x400 Boot-up Screen Standart
13 PAL 640x480 Desktop Standart
14 PAL 640x480 Desktop Lower
15 PAL 640x480 Desktop Higher
16 PAL-M 640x480 Desktop for Brazil Standart
17 PAL-Nc 640x480 Desktop for Argentina Standart
18 PAL 720x400 Boot-up Screen Standart
19 PAL 800x600 Desktop Lower
20 PAL 800x600 Desktop Standart
21 PAL 800x600 Desktop Higher
22 PAL 1024x768 Desktop Standart
23 PAL 1024x768 Desktop Higher
All other typical kernel command line options work as expected.
* Memory Configuration
The EP93xx has six SMC chip selects (CSn0, CSn1, CSn2, CSn3, CSn6, and CSn7)
which can be used to connect FLASH devices, and four SDRAM chip selects
(SDCSn0, SDCSn1, SDCSn2, and SDCSn3) that can be used to connect SDRAM devices.
Additionally, there is a choice between sychronous and asynchronous boot modes,
which effects the memory map of the system.
To quickly summarize the information available in the chip user's guide, the
following table shows the physical address of the memory attached to each of
these chip selects:
+--------------+-------------+-------------+
| Chip Select \ / Async boot | Sync Boot |
+--------------+-------------+-------------+
| CSn0 | 0x0000.0000 | 0xf000.0000 |
+--------------+-------------+-------------+
| CSn1 | 0x1000.0000 |
+--------------+---------------------------+
| CSn2 | 0x2000.0000 |
+--------------+---------------------------+
| CSn3 | 0x3000.0000 |
+--------------+---------------------------+
| CSn6 | 0x6000.0000 |
+--------------+---------------------------+
| CSn7 | 0x7000.0000 |
+--------------+---------------------------+
| SDCSn0 | 0xc000.0000 |
+--------------+---------------------------+
| SDCSn1 | 0xd000.0000 |
+--------------+---------------------------+
| SDCSn2 | 0xe000.0000 |
+--------------+---------------------------+
| SDCSn3 | 0xf000.0000 | 0x0000.0000 |
+--------------+-------------+-------------+
In addition to this, this is a chip bug that forces the width of the SDCSn3
memory to the boot pin determined width when booting in synchronous boot mode.
Being as this is the default configuration of the boards, this makes it
impossible to boot from a 16-bit width FLASH and use 32-bit wide SDRAM.
Therefore, reconfiguring the board and software to use asynchronous boot mode
avoids this problem and allows this memory configuration to be utilized.
Both RedBoot and the Linux kernel are sensitive (in varying degrees) to the
physical address of both FLASH and SDRAM. So, they must be informed of the
system configuration at build time in order to operate correctly.
For RedBoot, the only thing that it must know is the SDRAM chip select that is
used for SDRAM (it is able to deduce and adjust to the other configuration
options). The _CYG_HAL_ARM_ARM9_EP93XX_SDRAM_CS_ option tells it which chip
select to use; it can take on the values "SDCSn0", "SDCSn1", "SDCSn2", and
"SDCSn3", with the default being "SDCSn3". In order to change to another SDRAM
chip select (such as SDCSn0 in this example), create a file like the following:
cdl_option CYG_HAL_ARM_ARM9_EP93XX_SDRAM_CS {
user_value SDCSn0
};
And call it !sdram.ecm!. Then, change the call to "build_redboot" so that it is
similar to the following:
build_redboot `pwd` edb9301_ROMRAM "import `pwd`/sdram.ecm"
Keeping the board type as required. This will build RedBoot such
that it expects SDRAM on SDCSn0, and therefore it will not run if SDRAM is not
on SDCSn0.
For Linux, it must know about all of these hardware configuration settings.
The following menu items in the kernel configuration can be adjusted to
configure the kernel to match the hardware:
System Type
EP93xx Implementations
(CSn6) FLASH chip select
(SDCSn3) SDRAM chip select
[*] Synchronous boot mode
This will tell the kernel what to expect from the board; if the kernel is not
configured the same way as the board it probably won't run, so be sure that you
get it right.
Consult the board documentation to determine how to reconfigure the evaluation
board that you are using. While some boards will have jumpers to do this
reconfiguration, many will have zero-ohm resistors that must be moved from one
position to another.
* Add Your Own Binary File
Please see packages/fubar as example on how to add customer own application
into Cirrus Logic build system.
Some directories should be cared:
- $(TARGET_DIR): it's the rootfs directory -- build/root/ , the binary file should
be putted into $(TARGET)/usr/bin or $(TARGET)/usr/sbin.And if the
binary file is built dynamicly, the dependent libraries should be
putted into $(TARGET)/usr/lib.
- $(HOST_DIR): it's the directory in where intermedia files against which binary file is
compiled or tools are located -- host/ . the dependent header files or shared libraries
should be putted in $(HOST_DIR)/include or $(HOST_DIR)/lib.
- $(BUILD_DIR): it's the build directory.