sab8253xds.txt

该文件是rt_linux

*_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