VxWorks / Tornado II FAQ

2. Changes/additions to be made to BSP's

2.1 Different BSP's

2.2 Processor specific issues

2.2.1 Power PC

2.2.2 I960

2.2.3 MIPS

2.2.4 ARM

2.3 Bootstrap

2.4 Adding component to your VxWorks configuration

2.5 VME problems

2.6 VxWorks environment

2.6.1 usrSerial.c

2.6.2 prj_vxworks.tcl

2.7 PCI problems

Index

2. Changes/additions to be made to BSP's

A: More information on device drivers is available in the Tornado BSP developers kit(only available for Tornado 1.x). It covers several types at a high level, such as serial, network, scsi etc.
The Vxworks Network programmers guide also does a little coverage of BSD style device drivers.
The Network Protocol Toolkit Users Guide is also a pretty good source of information about network drivers. It is available online at the wrs website.
A really good source if information is the souce code that comes with BSPs that you purchase from WRS. I have used their examples in conjunction with the available docs and this forum to create a couple of drivers for chips that were unsupported.
(From: John Beauford, qjb005@email.mot.com)

2.1 Different BSP's

• Motorola MBX860
• Motorola MCP750 board
• Motorola MV23xx/MVME27xx board
• Simulator (Sim-NT)
• PC-type systems

2.2 Processor specific issues

2.2.1 Power PC

2.2.2 I960

A: Fred Roeber wrote the following in the newsgroup:
I had similar problems with an i960 device driver. I spent some time going through the compiler code and manuals. This document is something I put together back then that I think might help.
(From: Fred Roeber, froeber@bbn.com)

2.2.3 MIPS

A: Just received from Windriver support the following note regarding e_flags and MIPS.
(From: Xjasartist@yahoo.com)

There are several types of warnings generated by compiler. These are harmless.
During compilation of vxWorks image:

uses different e_flags (0x0) fields than previous modules
(0x10000001)

Usually when this error message comes up with MIPS, it is from one of two different flags.

First is 0x1, which specifies that somewhere in the code a .noreorder directive was given. For MIPS, the name of this flag is EF_MIPS_NOREORDER. There should not be any problems related to this flag differing between the original object modules and the final module.

Second is 0x10000000, which is E_MIPS_ARCH_2. What this means is that some modules were compiled to use the ARCH 2 functionality. When you are using an ARCH 2 or ARCH 3 processor, this should also not be a problem.

The MIPS specific flags are:

/* Processor specific flags for the ELF header e_flags field.  */

/* At least one .noreorder directive appears in the source.  */
#define EF_MIPS_NOREORDER       0x00000001

/* File contains position independent code.  */
#define EF_MIPS_PIC             0x00000002

/* Code in file uses the standard calling sequence for calling position independent code.  */
#define EF_MIPS_CPIC            0x00000004

/* Four bit MIPS architecture field.  */
#define EF_MIPS_ARCH            0xf0000000

/* -mips1 code.  */
#define E_MIPS_ARCH_1           0x00000000

/* -mips2 code.  */
#define E_MIPS_ARCH_2           0x10000000

/* -mips3 code.  */
#define E_MIPS_ARCH_3           0x20000000

For PowerPC, the same error message may come up from the function ppc_elf_merge_private_bfd_data(). If this happens then the basic cause of the problem is the same as for MIPS, namely that the ELF output e_flags are different from the input flags. However, at this time our records do not contain indications about the differences in e_flags which actually occur, or even indications that this condition has ever occurred for PowerPC at all. Also, the PPC processor specific flags do not give any indication of similar conditions to the NOREORDER condition mentioned for MIPS above. If you find this error message when using PowerPC, please contact Wind River support.

2.2.4 ARM

A: ___fixunsdfsi converts double to unsigned int. For some (unkown) reason both ___fixunsdfsi and ___fixunssfsi (single to uint) are absent from the vxworks image.
The following (untested) arm assembler probably does the job!

#define SGN_BIT 0x80000000      /* sign bit */
#define MNT_SZ          20      /* mantissa bits in first word */


___fixunsdfsi:
        movs    r12,r0,asr #MNT_SZ      /* get sign and exponent */
        movmi   r12,#0                  /* convert -ve to zero */
        /* extract top 32 bits of mantissa */
        mov     r0,r0,lsl #31 - MNT_SZ
        mov     r1,r1,lsr #MNT_SZ + 1
        orr     r0,r0,r1
        orr     r0,r0,#SGN_BIT          /* add hidden bit */

        sub     r12,r12,#0x400
        rsbs    r12,r12,#0x1e           /* unbiassed and negated */
        bmi     10$
        mov     r0,r0,lsr r12
        mov     pc,lr

10$:    /* overflow */
        mvn     r0,#0
        mov     pc,lr

Q: Information on implementing PCMCIA on StrongARM.

A: Implementing the pcmcia on the SA1110/SA1111 is painful to say the least. We have that hardware combination with 2 pcmcia sockets.
PCIC.C/TCIC.c are the driver files, you need to write a similar file for the SA-1111. This is the hardware specific file. I found the pcic and tcic to be much more complicated than the SA-1111, so my driver file was simpler.
Once the driver is implemented and working then you define an pcmcia adapter for the card, which references the functions in your driver.
pcmciaLib.c, cisLib.c, pccardLib.c these are the higher level functions for the pcmcia, they had to be modified in various places to accomodate the hardware. I ended up making a local copy of all the files to work on.
Here are some of the issues encountered. I don't know if you'll have the same problems or not. BTW, this is just a high level pass at the information, the devil is in the details.

1. VXWORKS implementation assumes a PC architecture. They assume both pcmcia slots used the same address space. I had to modify cislib.c (and problaby another file). So that it would reference the right address space for the socket.
2. Interrupts. The SA1111 uses edge interrupts therefore it detects inserts (rising edge) or removals (falling edge or vice versa). I had to add a polling routing to reliably detect the card insert.
3. SA1111 bug. We're using ATA cards. We found a problem where the Card does not handle 8 bit reads at odd addresses. I had to use a 16 bit read and mask off the appropriate bit. This causes a problem because the ATA spec. has data that is only valid with an 8-bit odd read.

2.3 Bootstrap

A: Change the value of the define TIMEOUT in bootConfig.c to the right value, recompile the bootstrap and load this bootstrap in your target.

Q: How can I change the boot parameters without a physcial serial to my target to change these at boot time?

A: Use the command "bootChange" from the target shell or host shell using Telnet or Rlogin.
(From: Pete Kockritz (petekz@my-deja.com)

Q: I get the message "Error in boot line:". Why is this message generated and how can I get rid of it?

A: The message is generated when bootStringToStruct() doesn't return a pointer to EOS. That happens when something in the bootline is not understood correctly and the processing terminates before the whole line has been read. What follows the message should be the bootline string with a ^ symbol under the part that was misunderstood... If you are getting garbage then that is probably the cause of the error ;-)
(From: john_94501@my-deja.com)

Q: When I try to boot my PC target using vxload I boot DOS without any config.sys or autoexec.bat. But still I get the error "Not enough memory to load". How can I get more memory available?

A: The line

shell=a:\vxworks\vxload.com a:\vxworks\bootrom

Q: When I try to start an VxWorks image from T1 it runs, but when I try to start the image compiled under T2 the system freezes.

A: The problem was a file called "sysalib.s" in our vxWorks configuration BSP. It contains the first entrypoint for vxWorks.
When we have compiled the image an warning was shown in the last line like this
"could not find _sysinit, set it to default 0x10000"
After we added the file to the vxWorks build, it works fine.
(From: "Achim Zimmer" (hzimmer@dica.de))

Q: Is it possible to boot from a compressed VxWorks image on a file system?

A: Yes, that is possible. It can be done if you have enough RAM available.

Take a look at the attached routine bootLoadModuleInflate() in bootLoadModInfl.c, intended to go in all/bootConfig.c. It presents the same interface as bootLoadModule(), except the file descriptor that it takes is that of a deflated file.

Code such as the following code can be used to automatically call bootLoadModuleInflate() instead of bootLoadModule() when the boot file name ends with a certain extension. Then you can boot either way.

#define DEFLATED_EXT		".D"
#define DEFLATED_EXT_LEN	(sizeof (DEFLATED_EXT) - 1)
#define DEFLATED_FILE(fileName) \
	(strlen(fileName) >= DEFLATED_EXT_LEN && \
	 strcmp((fileName) + strlen(fileName) - DEFLATED_EXT_LEN, \
                  DEFLATED_EXT) == 0)

    /*
     * Support loading deflated or regular files.
     */

    if (DEFLATED_FILE(fileName)) {
	if (bootLoadModuleInflate(fd, pEntry) != OK)
	    goto readErr;
    } else {
	if (bootLoadModule (fd, pEntry) != OK)
	    goto readErr;
    }

DEFLATE = ${WIND_BASE}/host/${WIND_HOST_TYPE}/bin/deflate
VX_BINARY = vxWorks.st

${VX_BINARY}.D: ${VX_BINARY}
        @echo "Deflating ${VX_BINARY} ==> ${VX_BINARY}.D ...."
        ${DEFLATE} < ${VX_BINARY} > ${VX_BINARY}.D

Q: When I boot my target over an FTP connection the kernel is loaded in a couple of seconds, but then the symbol table takes a much more time. Why does the second phase take so much more time than the first part.

A: The FTP client binds a port and lets vxWorks assign the port number. VxWorks always assigns port numbers incrementing from 1024. So first the boot ROM uses port 1024 to load the image. Then vxWorks resets itself, causing it to use port 1024 again for the first file transfer after boot. Unfortunately, some servers don't let you re-use the same port number for up to several minutes. The port is kept unusable in the TIMED_WAIT state.
The problem may also occur if you reboot a system twice in a row because the boot ROM tries to use port 1024 repeatedly.
One fix is to call bind() a bunch of times in a loop during early init. This wastes port numbers. The loop count may be chosen pseudo-randomly, but then you may occasionally still have the problem. It is better to store the loop count in NVRAM and increment it by 16 or something every boot, modulo some number.
Since doing this I have had no problems using any server. Here's my version of the routine sysBindFix(). It should be called after usrNetInit() in usrConfig.c for the kernel, and also from a convenient place in the boot ROM, such as before netLoad(). My implementation is appended below.

#include "netinet/in.h"         /* for sysBindFix() */
#include "sockLib.h"            /* for sysBindFix() */

/*****************************************************************************
*
* Each time VxWorks is rebooted, it starts assigning system-assigned
* port numbers beginning at 1024.  Thus, if vxWorks is rebooted two or
* more times in succession, the same port number will be re-used.
*
* This behavior causes problems when vxWorks is being booted from a
* remote FTP server (particularly one running Solaris), because port
* 1024 goes into a TIME_WAIT state on the server and cannot be reused
* until it times out, typically in 2-4 minutes.
*
* This hack reduces the likelyhood of this happening by "wasting"
* a different number of system-assigned port numbers for each boot.
*/

void sysBindFix(void)
{
    UINT8               N;

    sysNvRamGet((char *) &N, 1, NV_OFF_BINDFIX);
    N -= 16;
    sysNvRamSet((char *) &N, 1, NV_OFF_BINDFIX);

    /* This is quite fast even when N=255 */

    while (N--) {
        int s;
        struct sockaddr_in saddr;
        saddr.sin_addr.s_addr = htonl(INADDR_ANY);
        saddr.sin_port = 0;
        saddr.sin_family = AF_INET;
        s = socket(AF_INET, SOCK_STREAM, 0);
        bind(s, (struct sockaddr *) &saddr, sizeof(saddr));
        close(s);
    }
}

If the host is Solaris that you are booting from you can set TIMED_WAIT to its minimum value, as root using 'ndd':

• When using Solaris 2.6:

  ndd -set /dev/tcp tcp_close_wait_interval 1000
  

• When using Solaris 2.7:

  ndd -set /dev/tcp tcp_time_wait_interval 1000
  

I put a script in /etc/rc2.d to automate this on each reboot:

#!/sbin/sh
#   for Solaris 2.7
# refer to ndd man page

case "$1" in
'start')
   if [ -f /usr/sbin/ndd  ]; then
      echo 'shortening tcp_close_wait_interval to 1000'
      /usr/sbin/ndd -set /dev/tcp/ tcp_close_wait_interval 1000
   fi
   ;;

'stop')
   ;;

*)
        echo "Usage: $0 { start | stop }"
        exit 1
        ;;
esac
exit 0

There is also a possible solution on the Vxworks side - make sure that when the machine reboots, it does not reuse the same port numbers again. This happens on fast reboots as well as switches between boot and memory (vxWorks) images. A simple way to go about is to add code into useNetwork.c, that creates a couple of additional sockets and binds them to dunamic ports.
(From: Leonid Rosenboim, leonid@bitband.com)

Q: When I startup my target and want to download my VxWorks image using an FTP session, and my ftp daemon is not yet available I have to manually restart my target or use the bootprompt to start my system. How can I avoid this?

A: You could try to increase the boot timeout, but that would also be the case when your FTP deamon machine is available.
Another option is to modify the boot process. Now, when the boot fails the bootprompt apears. Modify it in such a way that the countdown starts again. This means that after 10 seconds a new FTP action is started, and if this fails 10 seconds later another is started.
Be sure to have the bootloader react to a key however. The bootprompt should apear when you press a key, so you can still modify the boot parameters.

Q: Is it possible to make a "multi-boot"?

A: Yes, VxWorks is quite capable of multi-booting. However, not without some work on your part and then reburning the boot ROMs (or rebuilding the boot image if you're using BOOTP).
What you have to do is to modify the bootConfig.c file in the area of the routine called the bootCmdLoop.
You will need to define an alternate bootline and store it somewhere. You'll find an example in <Your BSP>/config.h. It should look something like this:

#define DEFAULT_BOOT_LINE \
"ei(0,0)host:/usr/vw/config/mv162/vxWorks h=90.0.0.3 e=90.0.0.50 u=target"

#define ALTERNATE_BOOT_LINE1 \
"scsi=0,0(0,0)intructor:/u/team7/vxWorks h=192.168.32.50 e=192.168.32.17
u=team7 tn=vx7 s=/sd0/startup.cmd o=ei"

#define ALTERNATE_BOOT_LINE2 \
"ei(0,0)intructor:/u/team7/vxWorks h=192.168.32.50 e=192.168.32.17 u=team7
tn=vx7 s=/u/team7/startup.cmd"

char  secondChance = 2;

    /* start autoboot, unless no-autoboot specified */

    bootStringToStruct (BOOT_LINE_ADRS, &params);
    sysFlags = params.flags;

    if (!(sysStartType & BOOT_NO_AUTOBOOT) &&
	!(sysFlags & SYSFLG_NO_AUTOBOOT))
	{
	int timeout = TIMEOUT;

	if ((sysStartType & BOOT_QUICK_AUTOBOOT) ||
	    (sysFlags & SYSFLG_QUICK_AUTOBOOT))
	    {
	    timeout = 1;
	    }

	key = autoboot (timeout);	/* doesn't return if successful */
  } else {
	    int timeout = TIMEOUT;
      /* we only get here if the autoboot above fails */
  		switch (secondChance) {
				  case 2 :
                 strcpy (BOOT_LINE_ADRS, ALTERNATE_BOOT_LINE2);
                 secondChance--;
                 key = autoboot (timeout); /* doesn't return if successful */
                 break;
				  case 1 :
			  		     timeout = TIMEOUT;
                 strcpy (BOOT_LINE_ADRS, ALTERNATE_BOOT_LINE1);
                 secondChance--;
                 key = autoboot (timeout); /* doesn't return if successful */
                 break;
     }

  }
    /* If we're here, either we aren't auto-booting, or we got an error
     * auto-booting, or the auto-booting was stopped. */

Q: When I use a compressed VxWorks image a timeout resets my target before my VxWorks becomes active. Is it possible te reset the watchdog during the inflate?

A: You can modify and rebuild the inflate function to include a function to reset the watchdog. The sources can be found at: http://www.info-zip.org/pub/infozip/zlib/
(Bill Pringlemeir, bpringlemeir@yahoo.com)

Q: How do I create a boot-disk?

A: Creating Bootable Floppy from Boot-ROM:

• Open DOS window.
• From DOS window execute tornado\host\x86-win32\bin\torvars (it will fix environment vars).
• From the location of your boot-rom file (tornado\target\config\ BSP-dir\bootrom_uncmp) type mkboot a: bootrom_uncmp. The mkboot utility will create a bootable floppy disk

• 1st stage will be to prepare a Hard Disk that will be suitable for VxWorks environment.
• Prepare a Floppy Disk with DOS6.2, FDISK & FORMAT files on it.
• Turn off your PC, remove your HD and place VxWorks HD instead.
• Boot your PC from DOS 6.2 Floppy Disk.
• Run FDISK Create FAT16 2Gbyte partition and set it to be the active partition.
• Exit from FDISK, reboot from the Floppy Disk and format the HD by using the FORMAT command from the Floppy Disk.
• Turn Off your PC, reconnect your original HD, and add VxWorks HD as a secondary HD (for example as disk D).
• Turn ON your PC (Windows NT should be activated).
• Open DOS window.
• From DOS window execute tornado\host\x86-win32\bin\torvars (it will fix environment vars).
• From the location of your boot-rom file (tornado\target\config\ BSP-dir\bootrom_uncmp) copy bootrom_uncmp to file name bootrom.dat.
• Type vxsys d: (assuming VxWorks HD is mapped as disk D). The vxsys.com installs a bootstrap loader that will be used to load bootrom.sys file.
• Type vxcopy bootrom.dat d:bootrom.sys. vxcopy copys & converts the bootrom_uncmp file to the required format.

Q: When booting using the wu_ftpd shipped with RedHat 6.2 the booting hangs during the download.

A: The system does not hang, if you wait until the connection times-out you will see that the system boots.
Some more research turned up a plausible explanation of the problem on the wu ftp web site (the Red Hat Linux ftp server) and the fix was pretty simple.
Basically, the ftp server has been made more RFC "insistent" and this caused the VxWorks boot code to break (it also broke Lynx, Midnight Commander and various other programs so WRS were not alone!).
The patch is to close the data connection immediately after the read returns EOF (ie the other end has signalled a close). This is consistent with the FTP RFC 959.
The patch should be safe (the data connection is no longer used), and it works for me with the ftp daemon (wu ftpd) on Linux Red Hat 6.0, 6.2, as well as the ftp supplied fom WRS for Windows - wftpd version 2.03.
So, in bootConfig.c, in the 2 places where the connection is terminated (normal case and error case). Move the close(fd) up after the read. That is:

    /* Empty the Data Socket before close. PC FTP server hangs otherwise */

    while ((read (fd, command, sizeof (command))) > 0);
    /* Close data connection now
    close (fd);

(From: paulvroberts@my-deja.com)

Q: What does the "hostname" field in the boot-parameters mean?

A: The host name field in the boot line refers to the card/machine that has the host inet address. This hostname will appear on your 'devs' list so that you can access the host machine through the target.
There's another field called target name that used for the name of the card/machine that the image is running on.
Look in Section 13 of the VxWorks Networks Programmer's Guide for an explanation of all the fields.
(From: Christian Gan, cgan@iders.ca)

Q: I boot from my Disk On Chip, but now I get unresolved symbols when I try to access a symbol.

A: First you have to generate the symbol table. When you include this with your image you have to copy this (much larger) VxWorks file to your target. When you create a seperate symbol file you must put the vxworks.sym (the symbol table ) in the same site of the vxworks image. vxworks.sym is created when you build the vxworks image.
(From: ilavin@alumnos.uva.es)

Q: After copying the file BOOTROM.SYS to a disk my PC-board does not start. It only shows VxLd ....... [etc].

A: Verify that the file BOOTROM.SYS is not fragmented from MS-DOS's point of view. You can verify this with

chkdsk C:\bootrom.sys

2.4 Adding component to your VxWorks configuration

A: The component structure is defined in the .cdf files, so study these first. Before you start to add your component you should answer 3 questions:

1. During which startup routine should the initialization take place? (see prjConfig.c for startup routines)
2. Where in the component structure should your component be defined?
3. What items should be visible (and editable) to the users during configuration? Also define a constant that should be used to enable the component.

1. Create a CDF file for your component. This file can include the following item (some of these are required):
   • NAME: The name of your component, as it should appear in the component list.
   • SYNOPSIS: The description of your component.
   • MODULES: The object modules to load.
   • INIT_RTN: The routine that should be called to initialize your component
   • HDR_FILES: The header file.
   • CONFIGLETTES: The source files that define your component. This source file will be included in the prjConfig.c.
   • CFG_PARAMS: The configuration parameters. These will appear as defines in the file prjParams.h. For each of the parameters an extra parameter definition can be given. In this item the name, the type and the default value can be defined
   Be sure to place the header and source file in a place that will be searched. The CDF file should have the name 00<component name>.cdf. If it is a architecture independent component place it in target\config\comps\vxWorks, otherwise place it in target\comps\vxWorks\arch\<Architecture>.
   For a good example see the item FOLDER_CLOCK, and follow all the items.
2. Find the right InitGroup item in the file 00VxWorks.cdf. This file is located in target/config/comps/vxWorks. Now add the line INCLUDE_<component> at the right place in the list of include statements. Don't forget to add a backslash to this line (or the one above if the component is added at the end).
3. Now find in the file 00VxWorks.cdf or 00BSP.cdf (in the same directory) the right folder to put your component. Add don't forget the backslash.

NOTE: there is probably a better way to define new components using extra tools. I don't have these tools so I had to find another way to include my new components.

2.5 VME problems

A: Andrew Fraser wrote some notes about this. This can be found here: vmeAutoId.html

Q: Is it possible to configure vxWorks so that it makes use of external VME memory as part of the local memory?

A: Your VME-memory should be accessible via standard VME-setup, if not change your sysPhysMemDesc[] in sysLib.c and / or your VME-settings parameters. On boot you may add your memory by a call to memAddToPool(). I would recommend to insert this call in function sysHwInit2() in sysLib.c.
(From: "Michael Lawnick, Lawnick@softec.de)

Q: Another card on the VME bus is generating a bus error. How can I avoid that my SW will be stoppen by this error?

A: I was able to make my own version of VxMemProbe that's a lot faster and recovers from bus errors. Here's what worked for me:

jmp_buf myEnv;

void mySigHandler(int sigNum)
{
        longjmp(myEnv, ERROR);
}

//  Call this once before calling the Probe() routine below.
void myByteProbeInit()
{
        struct sigaction newSig, oldSig;

        newSig.sa_handler = mySigHandler;
        newSig.sa_mask    = 0;
        newSig.sa_flags   = 0;

        sigaction(SIGBUS,  &newSig, &oldSig);
        sigaction(SIGSEGV, &newSig, &oldSig);
}

STATUS
myByteProbe(char *addr, int mode, char *data)
{
        if(setjmp(myEnv) == 0)
        {
                if(mode == READ) *data = *addr;
                else *addr = *data;
        }
        else
                return (ERROR);
}

2.6 VxWorks environment

2.6.1 usrSerial.c

A: There is an error in usrSerial.c, in the function itos. In this function there is the following line:

	val = val - (val %= 10);

        val = (val - (val % 10))/10;

2.6.2 prj_vxworks.tcl

Q: When I create a new bootable project all items in the VxWorks tab are marked as "not installed". How can I get these back?

A: This is caused by the fact that an extra library has been defined in your BSP Makefile (LIB_EXTRA = ...). The project is generated only with the first library to look for the objects needed for the BSP.
It is possible to change this. The file where the project is generated is prj_vxWorks.tcl. This file can be found in host/resource/tcl/app-config-Project. In this file the following changes must be made:

*** prj_vxWorks.tcl-old Mon Jan 24 12:08:26 2000
--- prj_vxWorks.tcl     Mon Aug  7 14:33:51 2000
*** 895,905 ****
      set wcc [file tail $bspDir]
      wccCreate $hProj $wcc
      wccCdfPathSet $hProj $cdfPath
      foreach lib [bspMakeGet LIBS] {
!       if {[string match *lib[bspMakeGet CPU]*.a $lib]} {
!           set mxrLibs [file tail $lib]
!           break
!       }
      }
      if {![info exists mxrLibs]} {
        set mxrLibs lib[bspMakeGet CPU][bspMakeGet TOOL]vx.a
--- 895,905 ----
      set wcc [file tail $bspDir]
      wccCreate $hProj $wcc
      wccCdfPathSet $hProj $cdfPath
+     set mxrLibs ""
      foreach lib [bspMakeGet LIBS] {
!         if {[string match *lib[bspMakeGet CPU]*.a $lib]} {
!             lappend mxrLibs [file tail $lib]
!         }
      }
      if {![info exists mxrLibs]} {
        set mxrLibs lib[bspMakeGet CPU][bspMakeGet TOOL]vx.a

2.7 PCI problems

A: From James Marshall (james_marshall@agilent.com):
I've just broken through into a clearing in the jungle of PCI Configuration & VxWorks on various PC platforms including CompactPCI. Some things I found useful on the journey:

1. There's a brief WindRiver Technical Note, WTN-49, that talks about some of these issues - it's on Windsurf. In particular it covers VME window mapping, if only briefly.
2. PCI System Architecture by Tom Shanley & Don Anderson, part of the MindShare series.
3. Linux source for PCI configuration. I used the source browser at lxr.linux.no to look at (for example) drivers/pci/pci.c http://lxr.linux.no/source/drivers/pci/pci.c?v=2.4.0-test7. It lets you click on identifiers to uncover where they are defined and used.
4. For interpreting PCI Config registers, the PCICFG program might help: http://www.cs.cmu.edu/~ralf/pub-files/rbpci119.zip.

In your driver you would use PCI routines from sysLib [pcPentium]: pciFindDevice() to get the config address (bus,device,function) for each instance of your device, then read the appropriate BAR(s) to get their address(es). I guess your master/slave window stuff mentioned in WTN-49 comes in at that point.

Note that the PCI Auto Config Library (src/drv/pci/pciAutoConfigLib.c) mentioned in WTN-49 isn't supported on x86 targets because the PCI BIOS (a callable part of the BIOS) is expected to do all PCI configuration before the OS boots. This is why the default setting for PCI_CFG_TYPE on x86 targets is PCI_CFG_NONE.

Index