how cr9 VxWorks bsp support more than 9 pci devices - VxWorks

This is a discussion on how cr9 VxWorks bsp support more than 9 pci devices - VxWorks ; Dear all, The hardware design is as follows: one elma cpci backplane that contains 2 pci-pci bridge(2050) and has 16 cpci slots. one cr9 cpci main board ( X86 architecture )which runs VxWorks based on cr9 bsp provided by GE. ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: how cr9 VxWorks bsp support more than 9 pci devices

  1. how cr9 VxWorks bsp support more than 9 pci devices

    Dear all,

    The hardware design is as follows:

    one elma cpci backplane that contains 2 pci-pci bridge(2050) and has
    16 cpci slots.

    one cr9 cpci main board ( X86 architecture )which runs VxWorks based
    on cr9 bsp provided by GE.

    ten pci cards, some of which are AD cards, the others are DSP cards.

    If we plug 9 pci cards, VxWorks boots OK.

    But if add one more pci card, VxWorks can't boot and stop at VxSys+++++
    +++++++

    We infer that there is something wrong with VxWorks pci configuration
    process.

    other phenomena are:

    the same hardware system works fine with Windows system, and 10 pci
    cards can all be recognized and tested OK.

    Our engineer has succeeded in doing such work with a PPC system. And
    there is no additional procedures to make it work.

    I don't think it is the power problem, because it works fine under
    Windows.

    I'm asking if anybody met this problem before and has any suggestions?


  2. Re: how cr9 VxWorks bsp support more than 9 pci devices

    solved with this post.

    lingsiva
    View profile
    More options Aug 17 1999, 3:00 pm
    Newsgroups: comp.os.vxworks
    From: lings...@my-deja.com
    Date: 1999/08/17
    Subject: Re: PCI support in VxWorks (x86)
    Reply to author | Forward | Print | Individual message | Show original
    | Report this message | Find messages by this author


    For X86 Arch PC's.
    --------------------
    By default, Vxworks works does not scan the entire Pci bus to detect
    the devices and map the memory range into its Global Memory Map Table
    (MMU - PHYS_MEM_DESC) while booting up. It is the responsibility of
    device driver developer to provide a function that will detect the
    device and create an entry in to Global Memory Map Table.

    The Pc bios does this hard work for you and allocates resources for
    the
    pci devices. But Vxworks does not use this information to map this
    into
    its MMU table. This work we have to do. I have given the entire code
    bit and where to be inserted below.

    What Vxworks Does is:
    If INCLUDE_PCI is defined, it initializes the Pci Library
    PciConfigLibInit(....) and PciIntLibInit().
    Note: If Pci device driver is to be implemented then INCLUDE_PCI must
    be defined.

    Memory Mapping of Pci Devices

    Vxworks provides three options to configure the Pci Devices
    1) PCI_CONFIG_FORCE: The BSP through data tables, configuration
    macros, or some other static methods known at compile time, configures
    each device separately. The address and interrupt numbers for each of
    the device are known in advance and programmed directly into the
    device.
    2) PCI_CONFIG_AUTO: This is typically a dynamic Pci bus
    configuration. This is similar to Bios pci resource assignment. No
    interrupt need to be known in advance. Only Memory pool and IO pool is
    to be passed to this library. This is not recommended because it is
    non
    portable from one chipset to another as per vxworks documentation.
    This
    is implemented in pciautoconfiglib.c in the BSP directory.
    3) PCI_CONFIG_NONE.: This is used in a situation where an
    external
    agent configures the entire Pci bus. Like PC bios. In this case , all
    the PCI devices are already configured before the VXWORKS os IS
    started.

    By Default for X86 arcitecture, the 3rd option is chosen and is the
    preferred one.
    Pci Initialization Sequence

    1) Any pci device MMU memory map table initialization must be
    done in sysHwInit() in sysLib.c that is called from usrConfig.c.
    2) This initialization routine should only be called after the
    Pci
    Libraries (pciConfigLibInit & pciInitLibint) are initialized in
    sysHwInit().
    3) This should be done before any device dependent driver
    initialization is run
    4) This should be done before usrMmuInit() routine in
    usrConfig.c
    is called.

    The Following is the code bit from sysLib.c

    #ifdef INCLUDE_PCI

    pciConfigLibInit (PCI_MECHANISM_1, PCI_CONFIG_ADDR,
    PCI_CONFIG_DATA, NONE);
    pciIntLibInit ();

    /*
    * PCI-to-PCI bridge initialization should be done here, if it is.
    * It is not necessary for Intel 430HX PCISET, which splits
    * the extended memory area as follows:
    * - Flash BIOS area from 4GByte to (4GB - 512KB)
    * - DRAM memory from 1MB to a maximum of 512MB
    * - PCI memory space from the top of DRAM to (4GB - 512KB)
    */

    #ifdef INCLUDE_MY_DEVICE_DRIVER

    sysCirrusPciInit(); This is our routine.
    #endif

    #ifdef INCLUDE_LN_97X_END
    sysLan97xPciInit ();
    #endif /* INCLUDE_LN_97X_END */

    Also it is better to include the source code for the required driver
    in
    this file itself as shown below:.. Thus we don't have to include any
    system specific header files.

    #ifdef INCLUDE_MY_DEVICE_DRIVER
    #include "Cirrus/VgaSrc.c"
    #endif

    The actual location of the source code may be in any one of the
    following locations:
    $(WIND_HOME)/target/src/drv/OurDriver/ourDriver.c
    $(WIND_HOME/target/config/$(BSP)/ourDriver.c

    For x86 Vxworks, the window to access Pci is 1:1 mapping. I.e. no
    translation from CPU local address to Pci bus address is required. So
    whatever memory address assigned by bios to that particular device is
    used from MMU mapping.
    Note : If you use a VME bus then you have to do a translation.

    A sample Pci Mmu initialization is given below.

    #define CIRRUS_INTI_STATE_MASK (VM_STATE_MASK_VALID |
    VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE)

    #define CIRRUS_INIT_STATE (VM_STATE_VALID| VM_STATE_WRITABLE |
    VM_STATE_CACHEABLE_NOT)

    #define CIRRUS_VENDOR_ID 0x1013

    #define CIRRUS_DEVICE_ID 0xa0

    /
    ************************************************** *********************
    ******************
    sysCirrusPciInit()
    This is function is called from SysHwInit() in sysLib.c. if
    INCLUDE_PCI
    option is defined.
    This should be called only after pci intiliazition .

    This will scan pci bus to find the device with specific device id and
    vendior id. Then it
    will read the bar0 address and calulate the mem range and then add to
    the GDT SYS_PHYS_MEM
    structure thru a function sysMemMapAdd. And then enable the memory on
    the board through configuration space
    */

    int sysCirrusPciInit()
    {

    ULONG dwBase0Addr;
    ULONG dwMemRange;
    ULONG dwTmpAddr;
    int pciBusNo;
    int pciDevNo;
    int pciFuncNo;

    /* find the bdf tuple */
    if((pciFindDevice(CIRRUS_VENDOR_ID, CIRRUS_DEVICE_ID, 0,
    &pciBusNo, &pciDevNo, &pciFuncNo)) != OK)
    return;

    /* read the bar 0 address */

    pciConfigInLong(pciBusNo, pciDevNo, pciFuncNo, PCI_CFG_BASE_ADDRESS_0,
    (unsigned int *) &dwBase0Addr);

    /* to calculate the size */ /* this code bit posted on this group by
    Geurt */
    /* first write all 1's to bar 0*/
    pciConfigOutLong(pciBusNo, pciDevNo, pciFuncNo,
    PCI_CFG_BASE_ADDRESS_0,
    0xfffffff0);

    /* now read the bar0 */
    pciConfigInLong(pciBusNo, pciDevNo, pciFuncNo, PCI_CFG_BASE_ADDRESS_0,
    (unsigned int *) &dwMemRange);

    /* restore the original value */
    pciConfigOutLong(pciBusNo, pciDevNo, pciFuncNo,
    PCI_CFG_BASE_ADDRESS_0,
    dwBase0Addr);

    /* check if mem range is zero. if zero return false */
    if(dwMemRange == 0 )
    return;

    /* caluclate the size */

    dwMemRange = ~(dwBase0Addr & PCI_MEMBASE_MASK) +1;

    /* mask of the lower bits as per pci2.1 spec */
    dwBase0Addr = dwBase0Addr & PCI_MEMBASE_MASK;

    /* add to the memory table */

    if ((sysMmuMapAdd( (void *) dwBase0Addr, (unsigned int) dwMemRange,
    (unsigned int) CIRRUS_INTI_STATE_MASK,
    (unsigned int) CIRRUS_INIT_STATE)) != OK)
    {
    logMsg("Could not map the device \n", 0,0,0,0,0,0);
    return;

    }

    /* now enable the cards memory */

    pciConfigOutWord(pciBusNo, pciDevNo, pciFuncNo, PCI_CFG_COMMAND,
    PCI_CMD_MEM_ENABLE | PCI_CMD_MASTER_ENABLE);

    }

    regards,
    s.shiva


    On Sep 25, 12:09 pm, Kai wrote:
    > Dear all,
    >
    > The hardware design is as follows:
    >
    > one elma cpci backplane that contains 2pci-pcibridge(2050) and has
    > 16 cpci slots.
    >
    > one cr9 cpci main board ( X86 architecture )which runs VxWorks based
    > on cr9 bsp provided by GE.
    >
    > tenpcicards, some of which are AD cards, the others are DSP cards.
    >
    > If we plug 9pcicards, VxWorks boots OK.
    >
    > But if add one morepcicard, VxWorks can't boot and stop at VxSys+++++
    > +++++++
    >
    > We infer that there is something wrong with VxWorkspciconfiguration
    > process.
    >
    > other phenomena are:
    >
    > the same hardware system works fine with Windows system, and 10pci
    > cards can all be recognized and tested OK.
    >
    > Our engineer has succeeded in doing such work with a PPC system. And
    > there is no additional procedures to make it work.
    >
    > I don't think it is the power problem, because it works fine under
    > Windows.
    >
    > I'm asking if anybody met this problem before and has any suggestions?







+ Reply to Thread