Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: MVME5500/Kate Feng wrote : > Anyway, the reason why I wanted to > clarify is that there is a cavet about the MVME5500 board, which is > due to its Discovery I system controller. It is a different issue fromwhat was discussed about the dummy read. > * Some PCI devices require Synchronization Barriers or PCI ordering > * for . For example, the VME-OMS58 motor controller we > * used at NSLS requires either enhanced CPU Synchronization Barrier > * or PCI-ordering (only one mechanism is allowed) for the PCI-write. > * The PCI-ordering simply implements a PCI conMVME5500/100 PCI sync. (was Re: Dev lib off-board register access)
From: Kate Feng <feng1@bnl.gov>
To: tech-talk@aps.anl.gov
Date: Thu, 17 Aug 2006 13:54:14 -0400
FYI :  In past July, I posted :
http://www.aps.anl.gov/epics/tech-talk/2006/msg00820.php

The PCI synchronization is required for some PCI or VME
devices  ( e.g. only VME-OMS58 motor controller is needed in our
application) to function properly on not only the MVME5500
but also the  6100.  The implementation on the MVME5500,
is different from the one in the MVME6100 (I do'nt have
the 6100).  The solution  I mentioned in the pci/pci_interface.c
(attached) has to be implemented at the MVME5500 BSP level
when the PCI bus is initilaized.  In other words,  vxWorks has to
provide the interface (or  an option) in the MVME5500 or 6100 BSP.
At the user level application, the  pciToCpuSync(0) is required
following  each register write.

Regards,
Kate







/* pci_interface.c
 *
 * Copyright 2004, 2006, All rights reserved including its function.
 *      Brookhaven National Laboratory and Shuchen Kate Feng <feng1@bnl.gov>
 *
 * The license and distribution terms for this file may be
 * found in the file LICENSE in this distribution.
 *
 * 8/17/2006 : S. Kate Feng
 *             uses in_le32()/out_le32(), instead of inl()/outl() so that
 *             it is easier to be ported.
 *
 */
#include <libcpu/io.h>
#include <rtems/bspIo.h>	    /* printk */

#include <bsp.h>
#include <bsp/pci.h>
#include <bsp/gtreg.h>
#include <bsp/gtpcireg.h> 

#define REG32_READ(reg) in_le32((volatile unsigned int *)(GT64260_REG_BASE+reg))
#define REG32_WRITE(data, reg) out_le32((volatile unsigned int *)(GT64260_REG_BASE+reg), data)

#define PCI_DEBUG     0

/* Please reference the GT64260B datasheet, for the PCI interface, 
 * Synchronization Barriers and PCI ordering.
 *
 * Some PCI devices require Synchronization Barriers or PCI ordering
 * for synchronization.  For example, the VME-OMS58 motor controller we
 * used at NSLS requires either enhanced CPU Synchronization Barrier
 * or PCI-ordering (only one mechanism allowed. See section 11.1.2).
 * To use the former mechanism(default), one needs to call 
 * CPU0_PciEnhanceSync() or CPU1_PciEnhanceSync() to perform software
 * synchronization between the CPU and PCI activities.
 * 
 * To use the PCI-ordering, one can call pciToCpuSync() to trigger
 * the PCI-to-CPU sync barrier after the out_xx(). In this mode,
 * PCI configuration reads suffer sync barrier latency. Please reference
 * the datasheet to explore other options.
 *
 * Note : If PCI_ORDERING is needed for the PCI0, while disabling the
 * deadlock  for the PCI0, one should keep the CommDLEn bit enabled
 * for the deadlock mechanism so that the 10/100 MB ethernet will
 * function correctly.
 *
 */
#define PCI_ORDERING

/*#define PCI_DEADLOCK*/

/*  So far, I do not see the need to disable the address pipelining.
#define DIS_ADDR_PIPELINE*/

#ifdef PCI_ORDERING
#define PCI_ACCCTLBASEL_VALUE          0x01009000
#else
#define PCI_ACCCTLBASEL_VALUE          0x01001000
#endif

#define ConfSBDis     0x10000000  /* 1: disable, 0: enable */
#define IOSBDis       0x20000000  /* 1: disable, 0: enable */
#define ConfIOSBDis   0x30000000
#define CpuPipeline   0x00002000  /* optional, 1:enable, 0:disable */

#define CPU0_SYNC_TRIGGER   0xD0  /* CPU0 Sync Barrier trigger */
#define CPU0_SYNC_VIRTUAL   0xC0  /* CPU0 Sync Barrier Virtual */

#define CPU1_SYNC_TRIGGER   0xD8  /* CPU1 Sync Barrier trigger */
#define CPU1_SYNC_VIRTUAL   0xC8  /* CPU1 Sync Barrier Virtual */


/* CPU to PCI ordering register */
#define DLOCK_ORDER_REG    0x2D0  /* Deadlock and Ordering register */
#define PCI0OrEn      0x00000001
#define PCI1OrEn      0x00000020
#define PCIOrEn       0x40000000
#define PCIOrEnMASK   0x40000021

#define CNT_SYNC_REG       0x2E0  /* Counters and Sync Barrier register */
#define L0SyncBar     0x00001000
#define L1SyncBar     0x00002000
#define DSyncBar      0x00004000
#define SyncBarMode   0x00008000
#define SyncBarMASK   0x0000f000

#define WRTBK_PRIO_BUFFER  0x2d8  /* writback priority and buffer depth */

#define ADDR_PIPELINE 0x00020000

void  pciAccessInit();

void pci_interface()
{
  unsigned int data;

#if  (defined(PCI_ORDERING)||defined(DIS_ADDR_PIPELINE))
  data = REG32_READ(0); /* needed : read to flush */
  /* MOTLOad default disables Configuration and I/O Read Sync Barrier 
   * which is needed for enhanced CPU sync. barrier  */
#ifdef PCI_ORDERING
  /* enable Configuration Read Sync Barrier and IO read Sync Barrier*/
  data &= ~ConfIOSBDis;
#endif
#ifdef DIS_ADDR_PIPELINE
  data &= ~ADDR_PIPELINE;

#if PCI_DEBUG
  printk("data %x\n", data);
#endif
#endif
  REG32_WRITE(data, 0);
  /* read polling of the register until the new data is being read */
  while ( REG32_READ(0)!=data);
#endif

#ifdef PCI_DEADLOCK
  REG32_WRITE(0x07fff600, CNT_SYNC_REG);
#endif
#ifdef PCI_ORDERING
  REG32_WRITE(0xc0060002, DLOCK_ORDER_REG);
  REG32_WRITE(0x07fff600, CNT_SYNC_REG);
#else
  REG32_WRITE(REG32_READ(PCI0_CMD_CNTL)|PCI_COMMAND_SB_DIS, PCI0_CMD_CNTL);
#endif

  /* asserts SERR upon various detection */
  REG32_WRITE(0x3fffff, 0xc28);

  pciAccessInit();
}
/* Use MOTLoad default for Writeback Priority and Buffer Depth 
 */
void pciAccessInit()
{
  unsigned int PciLocal, data;

  for (PciLocal=0; PciLocal < 2; PciLocal++) {
    /* MOTLoad combines the two banks of SDRAM into
     * one PCI access control because the top = 0x1ff
     */
    data = REG32_READ(GT_SCS0_Low_Decode) & 0xfff; 
    data |= PCI_ACCCTLBASEL_VALUE;
    data &= ~0x300000;
    REG32_WRITE(data, PCI0_ACCESS_CNTL_BASE0_LOW+(PciLocal * 0x80));
#if PCI_DEBUG
    printk("PCI%d_ACCESS_CNTL_BASE0_LOW 0x%x\n",PciLocal,REG32_READ(PCI_ACCESS_CNTL_BASE0_LOW+(PciLocal * 0x80))); 
#endif

  }
}

/* Sync Barrier Trigger. A write to the CPU_SYNC_TRIGGER register triggers
 * the sync barrier process.  The three bits, define which buffers should
 * be flushed.
 * Bit 0 = PCI0 slave write buffer.
 * Bit 1 = PCI1 slave write buffer.
 * Bit 2 = SDRAM snoop queue.
 */
void CPU0_PciEnhanceSync(unsigned int syncVal)
{
  REG32_WRITE(syncVal,CPU0_SYNC_TRIGGER);
  while (REG32_READ(CPU0_SYNC_VIRTUAL));
}

void CPU1_PciEnhanceSync(unsigned int syncVal)
{
  REG32_WRITE(syncVal,CPU1_SYNC_TRIGGER);
  while (REG32_READ(CPU1_SYNC_VIRTUAL));
}

/* Currently, if PCI_ordering is used for synchronization, configuration
 * reads is programmed to be the PCI slave "synchronization barrier" 
 * cycles. 
 */
void pciToCpuSync(int pci_num)
{
  unsigned char data;
  unsigned char bus=0;

  if (pci_num) bus += BSP_MAX_PCI_BUS_ON_PCI0;
  pci_read_config_byte(bus,0,0,4, &data);
}

Replies:
Re: MVME5500/Kate Feng wrote : > Anyway, the reason why I wanted to > clarify is that there is a cavet about the MVME5500 board, which is > due to its Discovery I system controller. It is a different issue fromwhat was discussed about the dummy read. > * Some PCI devices require Synchronization Barriers or PCI ordering > * for . For example, the VME-OMS58 motor controller we > * used at NSLS requires either enhanced CPU Synchronization Barrier > * or PCI-oMVME5500/100 PCI sync. (was Re: Dev lib off-board register access) Kate Feng

Navigate by Date:
Prev: Re: Original Motorola MVME 167 PROM Brad Cumbia
Next: Re: MVME5500/Kate Feng wrote : > Anyway, the reason why I wanted to > clarify is that there is a cavet about the MVME5500 board, which is > due to its Discovery I system controller. It is a different issue fromwhat was discussed about the dummy read. > * Some PCI devices require Synchronization Barriers or PCI ordering > * for . For example, the VME-OMS58 motor controller we > * used at NSLS requires either enhanced CPU Synchronization Barrier > * or PCI-oMVME5500/100 PCI sync. (was Re: Dev lib off-board register access) Kate Feng
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019 
Navigate by Thread:
Prev: EPICS Web Mirror How-To Ralph Lange
Next: Re: MVME5500/Kate Feng wrote : > Anyway, the reason why I wanted to > clarify is that there is a cavet about the MVME5500 board, which is > due to its Discovery I system controller. It is a different issue fromwhat was discussed about the dummy read. > * Some PCI devices require Synchronization Barriers or PCI ordering > * for . For example, the VME-OMS58 motor controller we > * used at NSLS requires either enhanced CPU Synchronization Barrier > * or PCI-oMVME5500/100 PCI sync. (was Re: Dev lib off-board register access) Kate Feng
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·