Linux/Unix编程

开发平台：
Unix_Linux

sab8253xds.txt：源码内容
							*_Design Specification of SAB8253X ASLX Driver for Linux_*
 
  The effort to design and implement the ASLX SAB8253X Driver for Aurora
  <http://www.auroratech.com/> hardware with the functionality described
  in *_Functional Specification of SAB8253X ASLX Driver for Linux
  <http://www.telfordtools.com/sab8253x/sab8253xfs.html>_* requires
  solutions to seven separate problems:
 
   1. creating a development environment for maintaining and extending
      the driver,
   2. integrating the driver into the kernel sources,
   3. creating a file structure of the driver that aids understanding,
   4. crafting a reasonable and easy to use user interface,
   5. developing simple tools and example programs for the driver, and
   6. designing the driver data structures and
   7. designing the driver program logic.
 
  _Development Environment_
 
      There are several possible approaches to creating a development
      environment.  The development environments for many drivers seem
      to have consisted simply of a single machine, and the developer
      used only /printk()/ in the driver code to debug.  I used such an
      environment to develop a driver for an IOP480 based intelligent
      adapter card.
 
For a driver that provides the functionality described in the Functional
Specification, a more sophisticated development and debugging
environment is useful.  (One could even occasionally wish for an ICE,
but that level of resources was not available to me.)
 
The development environment consisted of two 686 class machines, on
which the Linux operating system was installed.  One machine ran at 800
Mhz, the other at 1Ghz.  It probably would have been worthwhile to have
dual processor machine, and one was added to the development environment
later.  The 800 Mhz machine hosted the remote gdb application.  It ran
Redhat Linux 7.0, but because the machine served only as an NFS and
remote gdb host, the details of the Linux distribution on this machine
are not particularly important.
 
The target machine on which the driver was developed and debugged hosted
Suse Linux 7.1 and was later upgraded to Suse Linux 7.3.  Suse Linux
seemed to provide the most complete Linux distribution with the least
hassle in installation.  (As the Suse distribution comes on 7 standard
CDs or 1 DVD, there is a lot of value in having a DVD drive in the
target machine [and the gdb host if it runs a Suse distribution].)
 
The target and remote gdb machines are connected by a 100 Mbps Ethernet
network and by a serial crossover cable between the Com1 (ttyS0) ports. 
 
When I started developing the driver, I obtained the Linux 2.4.3 sources
from The Linux Kernel Archives <http://www.kernel.org/>.  Later as later
distributions became stable, I switched to the Linux 2.4.6
distribution.  The sources were installed first in
/home/martillo/kernel/linux-2.4.3 and then in
/home/martillo/kernel/linux-2.4.6 on the remote gdb host machine, which
was named frolix.
 
The sources were imported into CVS on frolix, and the core directory
into CVS  was added manually because the cvs import function ignores
it.  I consider it safer to maintain the CVS repository on the remote
gdb host machine instead of the target machine because the target
machine is likely to crash frequently, and its file system may be put
into bad states.
 
I executed the following commands on the remote gdb host machine.
 
*ln ^謘 /home/martillo/kernel/linux-2.4.3/include/asm-i386
/home/martillo/kernel/linux-2.4.3/include/asm*
* *
or
* *
*ln ^謘 /home/martillo/kernel/linux-2.4.6/include/asm-i386
/home/martillo/kernel/linux-2.4.6/include/asm*
* *
*ln ^謘 / /frolix *
 
I edited the /etc/exports file to contain the following.
 
/               ylith(rw)
/               fireball(rw)
/               bohun(rw)
/               indefatigable(rw)
 
Ylith is the original 1 Ghz target machine.  Fireball is a 400 Mhz
compact PCI target machine.  Indefatigable is a dual 1 Ghz target
machine.  Bohun is a Solaris target machine used for another project.
 
On the frolix, I started NFS with the following commands (contained in a
shell script).
 
*/etc/rc.d/init.d/nfs start*
*exportfs -va*
 
If it had been a Suse Linux machine, I would have used the yast2 control
center to start NFS service.
 
On ylith, I created an empty directory /frolix and executed the
following command.
 
*mount frolix:/ /frolix*
* *
At this point both the remote gdb host (frolix) and the target
development and debugging machine can refer to the same files by the
same paths.  I could have guaranteed the same paths to the source files
on both machines if I had simply used /home/martillo as my home
directory on frolix and exported /home from frolix to all the other
machines so that there would only be one /home directory for all the
machines in my network.  I was lazy about the network configuration.
 
After making sure that the user martillo had read write access
permissions to all the kernel sources, I built the kernel on the target
machine from within xemacs with the following sequence of commands.
 
From a shell window:
*xemacs ^謊 shell&*
 
Inside xemacs:
 
*cd /frolix/home/martillo/kernel/linux-2.4.3*
 
or
 
*cd /frolix/home/martillo/kernel/linux-2.4.6*
 
Then make sure that linux-2.4.x/include/asm-i386 is symbolically linked to
linux-2.4.x/include/asm.
 
Execute the following emacs command.
 
          M-x compile
 
This command prompts for targets.
 
In the development environment the most useful target string was usually
/clean xconfig dep bzImage modules./ The target /xconfig /brings up a
configuration window.  In the basic development environment, it was
generally worthwhile to add SCSI CD ROM, SCSI legacy support, an
Ethernet driver and DOS file system support
 
The target/ dep/ creates the dependencies (note that if the kernel tree
is ever removed, the .depend and .hdepend files must be regenerated). 
The /bzImage /target builds the kernel.  The /modules/ target generates
all the modules to be dynamically installed in the kernel via the
*insmod* command.
 
After building the kernel, installing the modules in the /lib tree
requires the execution (as root) of
 
make modules_install
 
The command *make install* *INSTALL_PATH=/boot* will install the
compressed kernel image as vmlinuz along with other files in the /boot
partition.  I preferred to use a shell script with commands like the
following.
 
cp /frolix/home/martillo/kernel/linux-2.4.6/arch/i386/boot/bzImage
/boot/vmlinuz_246
cp /frolix/home/martillo/kernel/linux-2.4.6/System.map
/boot/System.map-2.4.6
cp /frolix/home/martillo/kernel/linux-2.4.6/.config /boot/vmlinuz_246.config
cp /frolix/home/martillo/kernel/linux-2.4.6/include/linux/autoconf.h
/boot/vmlinuz_246.autoconf.h
cp /frolix/home/martillo/kernel/linux-2.4.6/include/linux/version.h
/boot/vmlinuz_246.version.h
 
When the kernel comes from a linux-2.4.3 tree, the obvious substitutions
of 3 for 6 are required.
 
Once all the modules and the kernel image are installed, the next step
in giving the system the ability to boot with the new linux-2.4.3 or
linux-2.4.6 kernel image is the modification of the lilo.conf file.
 
I added the following directives to the lilo.conf file.
 
  image  = /boot/vmlinuz_243
  label  = linux_2.4.3
  root   = /dev/hde7
  optional
 
  image  = /boot/vmlinuz_246
  label  = linux_2.4.6
  root   = /dev/hde7
  optional
 
In this case /dev/hde7 corresponds to the /boot partition, and the
options linux_2.4.3 and linux_2.4.6 will be added to the boot menu once
the *lilo* command has been executed.  In other system setups the disk
partition that corresponds to /boot might have a different name like
/dev/hda7.
 
Once the new kernel successfully boots, the next step to creating a
driver development and debugging environment is patching the kernel for
remote gdb debugging.
 
The necessary patch can be obtained from kgdb: Source level debugging of
linux kernel <http://kgdb.sourceforge.net/downloads.html>.
 
Now the kernel can be built again with the extra step of configuring for
remote gdb support in the kernel configuration menu. 
 
The following directives should be added to lilo.conf.
 
  image  = /boot/vmlinuz_243
  label  = debug243
  append = "gdb gdbttyS=0 gdbbaud=115200"
  root   = /dev/hde7
  optional
 
  image  = /boot/vmlinuz_246
  label  = debug246
  append = "gdb gdbttyS=0 gdbbaud=115200"
  root   = /dev/hde7
  optional
 
      Then lilo can be executed.  On reboot the boot menu will include
      options for debug243 and debug246.
 
To test the patch, select one of the debug options.  Then, on the remote
gdb host machine execute the following command.
 
stty 115200 < /dev/ttyS0
 
Start up an *xemacs* process.  Execute the following commands within
*xemacs.*
 
          M-x shell
 
Then within the shell window execute the following command.
 
cd /frolix/home/martillo/kernel/linux-2.4./X/
/ /
Then invoke the remote debugger.
 
          M-x gdb
 
Reply to the file prompt with *vmlinux.*
* *
In the gdb window, execute the following command.
 
target remote /dev/ttyS0
 
The gdb window should break in gdbstub.c which will be displayed in the
gdb source window.
 
At this point, all the basic gdb remote debugging capabilities are ready
to use.
 
To access the hardware breakpoint capability of the i386 processor, the
following commands can be loaded directly or from a file with the
*script* command.
 
#Hardware breakpoints in gdb
#
#Using ia-32 hardware breakpoints.
#
#4 hardware breakpoints are available in ia-32 processors. These breakpoints
#do not need code modification. They are set using debug registers.
#
#Each hardware breakpoint can be of one of the
#three types: execution, write, access.
#1. An Execution breakpoint is triggered when code at the breakpoint
address is
#executed.
#2. A write breakpoint ( aka watchpoints ) is triggered when memory location
#at the breakpoint address is written.
#3. An access breakpoint is triggered when memory location at the breakpoint
#address is either read or written.
#
#As hardware breakpoints are available in limited number, use software
#breakpoints ( br command in gdb ) instead of execution hardware
breakpoints.
#
#Length of an access or a write breakpoint defines length of the datatype to
#be watched. Length is 1 for char, 2 short , 3 int.
#
#For placing execution, write and access breakpoints, use commands
#hwebrk, hwwbrk, hwabrk
#To remove a breakpoint use hwrmbrk command.
#
#These commands take following types of arguments. For arguments associated
#with each command, use help command.
#1. breakpointno: 0 to 3
#2. length: 1 to 3
#3. address: Memory location in hex ( without 0x ) e.g c015e9bc
#
#Use the command exinfo to find which hardware breakpoint occured.
 
 
#hwebrk breakpointno address
define hwebrk
        maintenance packet Y$arg0,0,0,$arg1
end
document hwebrk
        hwebrk breakpointno address
        Places a hardware execution breakpoint
end
 
#hwwbrk breakpointno length address
define hwwbrk
        maintenance packet Y$arg0,1,$arg1,$arg2
end
document hwwbrk
        hwwbrk breakpointno length address
        Places a hardware write breakpoint
end
 
#hwabrk breakpointno length address
define hwabrk
        maintenance packet Y$arg0,1,$arg1,$arg2
end
document hwabrk
        hwabrk breakpointno length address
        Places a hardware access breakpoint
end
 
#hwrmbrk breakpointno
define hwrmbrk
        maintenance packet y$arg0
end
document hwrmbrk
        hwrmbrk breakpointno
        Removes a hardware breakpoint
end
 
#exinfo
define exinfo
        maintenance packet qE
end
document exinfo
        exinfo
        Gives information about a breakpoint.
end
 
Once the above macros are define, the developer can set hardware
breakpoints.
 
The next step to creating a useful development and debugging environment
is to provide a shell script to for remote debugging of dynamically
loaded modules.  The following shell script (called *loadmodule.sh*)
creates a gdb script called *load/ModuleName/* in
/frolix/home/martillo/kernel/linux-2.4.6 when it is invoked (as root)
with the following command.
loadmodule.sh modulename
 
In order to decrease the probability of confusion, I usually make a link
in kernel root directory,  /frolix/home/martillo/kernel/linux-2.4.6, to
the location of the module to be debugged in the kernel tree.  The above
command is invoked on the target machine (ylith) in the root directory. 
On the remote debug machine, in the gdb command window, whose working
directory should be the kernel root directory,
/frolix/home/martillo/kernel/linux-2.4.6, the command, *script
load/ModuleName/*, is invoked.  Once the script is executed the symbols
for the module are available for remote symbolic debugging.
 
#!/bin/sh
# This script loads a module on a target machine and generates a gdb script.
# source generated gdb script to load the module file at appropriate
addresses
# in gdb.
#
# Usage:
# Loading the module on target machine and generating gdb script)
#       [foo]$ loadmodule.sh <modulename>
#
# Loading the module file into gdb
#       (gdb) source <gdbscriptpath>
#
# Modify following variables according to your setup.
#       TESTMACHINE - Name of the target machine
#       GDBSCRIPTS - The directory where a gdb script will be generated
#
# Author: Amit S. Kale (akale@veritas.com).
#
# If you run into problems, please check files pointed to by following
# variables.
#       ERRFILE - /tmp/<modulename>.errs contains stderr output of insmod
#       MAPFILE - /tmp/<modulename>.map contains stdout output of insmod
#       GDBSCRIPT - $GDBSCRIPTS/load<modulename> gdb script.
 
TESTMACHINE=ylith
GDBSCRIPTS=/frolix/home/martillo/kernel/linux-2.4.6
 
if [ $# -lt 1 ] ; then {
        echo Usage: $0 modulefile
        exit
} ; fi
 
MODULEFILE=$1
MODULEFILEBASENAME=`basename $1`
 
if [ $MODULEFILE = $MODULEFILEBASENAME ] ; then {
        MODULEFILE=`pwd`/$MODULEFILE
} fi
 
ERRFILE=/tmp/$MODULEFILEBASENAME.errs
MAPFILE=/tmp/$MODULEFILEBASENAME.map
GDBSCRIPT=$GDBSCRIPTS/load$MODULEFILEBASENAME
 
function findaddr() {
        local ADDR=0x$(echo "$SEGMENTS" | 
                grep "$1" | sed 's/^[^ ]*[ ]*[^ ]*[ ]*//' | 
                sed 's/[ ]*[^ ]*$//')
        echo $ADDR
}
 
function checkerrs() {
        if [ "`cat $ERRFILE`" != "" ] ; then {
                cat $ERRFILE
        } fi
}
 
#load the module
#echo Copying $MODULEFILE to $TESTMACHINE
#*rcp $MODULEFILE root@${TESTMACHINE}:
 
echo Loading module $MODULEFILE
#rsh -l root $TESTMACHINE  /sbin/insmod -m ./`basename $MODULEFILE` 
#       > $MAPFILE 2> $ERRFILE &
/sbin/insmod -m ./`basename $MODULEFILE` $2 . .  > $MAPFILE 2> $ERRFILE &
sleep 5
checkerrs
 
NUMLINES=`grep -n '^$' $MAPFILE | sed -e 's/:.*//g'`
SEGMENTS=`head -n $NUMLINES $MAPFILE | tail -n $(eval expr $NUMLINES - 1)`
TEXTADDR=$(findaddr "\.text[^.]")
LOADSTRING="add-symbol-file $MODULEFILE $TEXTADDR"
SEGADDRS=`echo "$SEGMENTS" | awk '//{
        if ($1 != ".text" && $1 != ".this" &&
            $1 != ".kstrtab" && $1 != ".kmodtab") {
                print " -s " $1 " 0x" $3 " "
        }
}'`
LOADSTRING="$LOADSTRING $SEGADDRS"
echo Generating script $GDBSCRIPT
echo $LOADSTRING > $GDBSCRIPT
 
With the addition of the above shell script, the driver development and
debugging environment is almost complete.  Other useful tools for
developing and debugging this type of serial driver would include a
Wanalyzer (I used an Interview 7700 and an HP 4952A in developing this
driver), a breakout box that displays interface signal states and  (for
developing the serial Ethernet-like network driver) several WAN LAN VLAN
routers as described in *Packet Switching Software and Platforms
<http://members.aol.com/Telford001/vrouter2g.html>*, *Routing in a
Bridged Network <http://members.aol.com/Telford001/routetti2.html>, **A
WAN SUBSYSTEM for a High Performance Packet Switch
<http://members.aol.com/Keleustes/syncdob.html>* and *A New High
Performance Architecture for Routers, Bridges and LAN Switches (Software
Defined Internetworking)
<http://members.aol.com/Ishtar7713/private/sdi4.html>.*
 
  _Integration into the Kernel Sources_
   
The driver has its own directory, {kernel root
directory}/drivers/net/wan/8253x, in the 2.4.* kernel source tree.
 
To facilitate the automatic build of the 8253x driver, the following
standard kernel files were modified.
 
1.                  {kernel root directory}/drivers/net/wan/Config.in to
which the line
 
tristate '  Aurora Technology, Inc. synchronous asynchronous PCI cards
V2' CONFIG_ATI_XX20
 
was added,
2.                  {kernel root directory}/drivers/net/wan/Makefile to
which the following lines were added,
 
subdir-$(CONFIG_ATI_XX20) += 8253x
 
ifeq ($(CONFIG_ATI_XX20),y)
  obj-y += 8253x/ASLX.o
endif
 
When the driver is built as a dynamically loaded module, the following
macro commands in the file 8253xini.c puts the module entry points in
the special module entry point segment.
 
module_init(auraXX20_probe);
module_exit(auraXX20_cleanup);
 
The sources are provided to the users in a patch file, tentatively named
8253x.patch <http://www.telfordtools.com/sab8253x/8253x.patch>.
 
To install it the user sets his directory to the top level of the kernel
sources and executes the following command.
 
patch ^謕1 < /{directory-patch}//8253x.patch
   
  _File Structure of the ASLX Driver Source Code_
 
The following files are present in the driver directory.
 
8253x.h
8253xdbg.c
8253xmac.c
8253xsyn.c
PciRegs.h
crc32.h
sp502.h
8253xcfg.c
8253xini.c
8253xnet.c
8253xtty.c
Reg9050.h
crc32dcl.h
ring.h
8253xctl.h
8253xioc.h
8253xplx.c
8253xint.c
crc32.c
endian.h
Makefile
Amcc5920.c
8253xmcs.h
8253xmcs.c
8253xchr.c
8253xutl.c
 
 
 
The source code is divided functionally among the files of the ASLX driver.
 
8253xcfg.c is the source for a user application that configures 8253x
control registers to provide clocking.  8253xmac.c is the source for a
user application that sets a pseudo-MAC address for the network driver.
 
8253xini.c contains the initialization/probe logic.
 
8253xint.c contains the common interrupt logic.
 
8253xtty.c contains the asynchronous TTY logic.
 
8253xsyn.c contains the synchronous TTY logic.
 
8253xnet.c contains the network driver logic.
 
8253xchr.c contains the character driver logic.
 
8253xdbg.c contains some debugging functions.
 
8253xutl.c contains most of the functions that are common among the
different driver functional subunits.
 
8253xplx.c contains some functions specific to the PLX9050 (a PCI bridge
chip) and specifically to reading and reprogramming the associated
serial EEPROM.
 
amcc5920.c contains some functions specific to the AMCC5920 (a PCI
bridge chip) and specifically to reading and reprogramming the
associated serial EEPROM.
 
8253xmcs.c contains functions specific to programming the multichannel
server (mostly G-LINK related logic, programming the sp502 driver chip
and reading or programming the serial EEPROM associated with the
interface cards contained within the MCS unit).
 
crc32.c contains logic to append a CRC32 to a pseudo MAC frame that is
generated by the network driver.
 
8253x.h contains symbols, structures and macros that relate mostly to
the 8253x chips and ports.
 
8253xctl.h contains symbols, structures and macros that relate mostly to
the adapter cards.
 
8253xmcs.h contains symbols and structures that relate mostly to the
multichannel server.  A lot of this file relates to G-LINK.
 
sp502.h contains symbols and structures that relate to the programming
of the hardware interface line drivers of the 3500 adapter cards of the
multichannel server.
 
8253xioc.h contains symbols and structures that relate to private ioctls.
 
PciRegs.h contains symbols and structures that relate to PCI
configuration space.
 
Reg9050.h contains symbols and structures that relate to the PLX9050 PCI
interface chip and its serial eprom
 
crc32.h, crc32dcl.h and .endian.h contain symbols, structures and macros
that relate to generating a correct CRC32.
 
ring.h contains symbols and structures that relate to the network driver
frame transmission ring and frame reception.
 
The Makefile is a standard Linux kernel Makefile whose structure is
dictated by the current Linux build formalism.
 
  _Using the ASLX Driver _
   
  The ASLX driver is designed to be a ^觩lug-and-play^

						