PCI Configuration for Summit 1553 Application - VxWorks

This is a discussion on PCI Configuration for Summit 1553 Application - VxWorks ; I am trying to create a 1553 application/driver on an MCP750 board, with an ALPHI Card and Summit Chip under VxWorks. I'm not having much luck in properly configuring the PCI device however. I am able to locate the device ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: PCI Configuration for Summit 1553 Application

  1. PCI Configuration for Summit 1553 Application

    I am trying to create a 1553 application/driver on an MCP750 board,
    with an ALPHI Card and Summit Chip under VxWorks. I'm not having much
    luck in properly configuring the PCI device however.


    I am able to locate the device (found at Bus 1, Device 12, Function 0)
    using:

    rtv = pciFindDevice(ALPHI_VD_ID, ALPHI_DEVICE_ID, Index,
    &pInfo->Bus, &pInfo->Device, &pInfo->Function);

    and can subsequently access and modify the Base Address Registers and
    PCI command word. I do not seem to be mapping these addresses
    properly however, and cannot access the SUMMIT Memory or I/O Space. I
    thought I had this code at least partially working, only to discover
    that it had just found some open memory location that it was able to
    write to that initially appeared correct. I am currently setting the
    BAR as follows. I have tried other offset values as well with varying
    results. These values allow the Summit BIT and ram_tests to execute
    successfully, however I get an exception when attempting to write to
    the Summit RAM (SummitWriteBuf) and also realized that I was able to
    write values to all summit registers, including read-only values,
    indicating that I am apparently accessing the wrong memory locations.
    Some of the other values I have tried result in failed tests,
    exceptions, and/or a locked up board.

    #define BASE_SUMMIT_IO_SPACE 0x80020000
    #define BASE_SUMMIT_DUAL_PORT_SRAM_SPACE 0x80000000
    #define BASE_SUMMIT_CPLI_OP_REG 0x80030000

    My initialization code is essentially the same as that at
    http://www.slac.stanford.edu/exp/gla...Alphi/RT1553.C
    (which I'm assuming is the original sample file from ALPHI that the
    code I am working off of was based on), except configured for a BC and
    using slightly different variable names. I also consolidated several
    of the #defines into the above definitions based on values from the
    previous sample code and experimentation.

    Any help or advise would be greatly appreciated.

    Thanks,
    David E.

  2. Re: PCI Configuration for Summit 1553 Application

    On 2007-04-23, VeryAngryGuy@gmail.com wrote:
    > I am currently setting the
    > BAR as follows.

    You should not be setting the BARs at all. They are initialized by the
    console firmware based upon addresses assigned to the module during
    system probing and sizing. You should read them to find out what
    addresses have been assigned, but do *not* normally need to write them.
    --
    roger ivie
    rivie@ridgenet.net

  3. Re: PCI Configuration for Summit 1553 Application

    On 2007-04-23, Roger Ivie wrote:
    > On 2007-04-23, VeryAngryGuy@gmail.com wrote:
    >> I am currently setting the
    >> BAR as follows.
    >
    > You should not be setting the BARs at all. They are initialized by the
    > console firmware based upon addresses assigned to the module during
    > system probing and sizing. You should read them to find out what
    > addresses have been assigned, but do *not* normally need to write them.

    Ah. I might be wrong. I thought I was posting in the VMS newsgroup...

    I've not yet done a PCI device driver for VxWorks, so I don't know for
    sure.
    --
    roger ivie
    rivie@ridgenet.net

  4. Re: PCI Configuration for Summit 1553 Application

    I've tried using the default values as well with similar results.
    I've gathered from others that have used these boards in the past that
    while some boards do automatically configure the BARS when powered on
    (making life a little easier), these particular boards do not. I
    appreciate the quick response anyway though.

    fyi, my default values are listed below. As far as I can tell, these
    values are likely to low in memory to be a correct mapping, as
    evidenced by the fact that when I try using these values the board
    locks up and has to be manually reset (aka pushing the reset button).

    At the moment, I am wondering if the issue may be related to that pci
    status register. I can't find any documentation on that register, or
    the DEVSEL=0 value, however all other detected devices have non-zero
    values and show FBTB DEVSEL=1. Could this be the case? If so, any
    ideas on what I'm missing to enable it?

    [1,12,0] type=OTHER DEVICE
    status=0x0000 ( DEVSEL=0 )
    command=0x0006 ( MEM_ENABLE MASTER_ENABLE )
    bar0 in 32-bit mem space @ 0x00100000
    bar1 in 32-bit mem space @ 0x00100080
    bar3 in 32-bit mem space @ 0x00120000


    Thanks again,

    On Apr 23, 9:38 pm, Roger Ivie wrote:
    > On 2007-04-23, Roger Ivie wrote:
    >
    > > On 2007-04-23, VeryAngry...@gmail.com wrote:
    > >> I am currently setting the
    > >> BAR as follows.
    >
    > > You should not be setting the BARs at all. They are initialized by the
    > > console firmware based upon addresses assigned to the module during
    > > system probing and sizing. You should read them to find out what
    > > addresses have been assigned, but do *not* normally need to write them.
    >
    > Ah. I might be wrong. I thought I was posting in the VMS newsgroup...
    >
    > I've not yet done a PCI device driver for VxWorks, so I don't know for
    > sure.
    > --
    > roger ivie
    > r...@ridgenet.net


  5. Re: PCI Configuration for Summit 1553 Application

    I've tried using the default values as well with similar results.
    I've gathered from others that have used these boards in the past that
    while some boards do automatically configure the BARS when powered on
    (making life a little easier), these particular boards do not. I
    appreciate the quick response anyway though.

    fyi, my default values are listed below. As far as I can tell, these
    values are likely to low in memory to be a correct mapping, as
    evidenced by the fact that when I try using these values the board
    locks up and has to be manually reset (aka pushing the reset button).

    At the moment, I am wondering if the issue may be related to that pci
    status register. I can't find any documentation on that register, or
    the DEVSEL=0 value, however all other detected devices have non-zero
    values and show FBTB DEVSEL=1. Could this be the case? If so, any
    ideas on what I'm missing to enable it?

    [1,12,0] type=OTHER DEVICE
    status=0x0000 ( DEVSEL=0 )
    command=0x0006 ( MEM_ENABLE MASTER_ENABLE )
    bar0 in 32-bit mem space @ 0x00100000
    bar1 in 32-bit mem space @ 0x00100080
    bar3 in 32-bit mem space @ 0x00120000


    Thanks again,

    [Let's try this again, Google-Groups doesn't seem to like me
    today . . . ]

    On Apr 23, 9:38 pm, Roger Ivie wrote:
    > On 2007-04-23, Roger Ivie wrote:
    >
    > > On 2007-04-23, VeryAngry...@gmail.com wrote:
    > >> I am currently setting the
    > >> BAR as follows.
    >
    > > You should not be setting the BARs at all. They are initialized by the
    > > console firmware based upon addresses assigned to the module during
    > > system probing and sizing. You should read them to find out what
    > > addresses have been assigned, but do *not* normally need to write them.
    >
    > Ah. I might be wrong. I thought I was posting in the VMS newsgroup...
    >
    > I've not yet done a PCI device driver for VxWorks, so I don't know for
    > sure.
    > --
    > roger ivie
    > r...@ridgenet.net


+ Reply to Thread
« does anyone have these two files? | MemScope Peak Memory Usage »