sab8253xds.txt

该文件是rt_linux

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 ([e-mail]).

#

# 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^