Hi Stefen,
On 01/29/2016 05:17 PM, Andrew Johnson wrote:
> Ok, I will write that up and post it here next week.
Here are my instructions on adding a CR/CSR master window to a VxWorks
BSP for a Motorola/Emerson board that uses the Universe-2 bridge chip.
The mv5500 BSP is a bit different to the mv5100 which I took these
changes from, but most of the changes should be very similar and
hopefully this will give you a good idea of the parts that you will need
to change.
One thing that I didn't explicitly discuss in the text is the CPU to PCI
mapping window, which is part of the Mv64260 Host Bridge on the MVME5500
board. The mapping window that covers the VME space is programmed using
the VME_MEM_LOCAL_START and VME_MEM_LOCAL_SIZE values that I did
discuss, so I don't think you will need to make any changes, but you
should be aware that the window exists in case you come across any
problems getting this to work. It is configured in mv64260PhbTbl in the
file sysMv64260Phb.c
Good luck!
- Andrew
--
There are only two hard problems in distributed systems:
2. Exactly-once delivery
1. Guaranteed order of messages
2. Exactly-once delivery
-- Mathias Verraes
Universe-2 VME CR/CSR Support for VxWorks BSPs
Background information about the software changes described in this
message can be found in Eric Bjorklund's slides from the June 2006 EPICS
Collaboration Meeting at this link:
http://www.aps.anl.gov/epics/meetings/2006-06/RecDevDrv_Support/Support_for_CR-CSR_Addressing.pdf
This message describes the changes needed for VxWorks BSPs of Motorola/
Emerson VME boards that use the Tundra Universe-2 chip; Eric's slides
only covered the Tsi148 chip. I have successfully applied the changes
described here to the mv2100, mv2700 and mv5100 BSPs, but I take no
responsibility for their correctness.
I will not describe how to make a copy of the VxWorks BSP directory to
make changes in or to build a VxWorks OS Image based on the result. I
suggest you build and boot an OS image based on your new BSP directory
before you make any of the modifications below, just to ensure that you
have that part working correctly first.
The first addition is to the BSP's config.h file. Find the preprocessor
macros that define the size and bus base addresses of each of the VME
master windows. Add these lines just after the existing definitions:
=== modified file 'config.h'
/* VME CR/CSR master window (16MB) */
#define VME_CRCSR_MSTR_BUS 0x00000000 /* Base VME address */
#define VME_CRCSR_MSTR_SIZE 0x01000000 /* either 0 or 16MB, only */
=== end
Next you need to find a suitable place in the board's CPU and PCI memory
maps to place the new master window, and also find a spare Universe-2
PCI slave window to use for it.
The addresses of the different master windows are usually defined as
macros with the names like VME_A24_MSTR_LOCAL. There may be a board
memory map shown as an ASCII diagram in the config.h file to help
understand the layout. Note that some BSPs use the macro EXTENDED_VME
to select between two completely different memory maps, depending on
whether EXTENDED_VME is defined or not; make sure you use the right map
(usually this will be the one with EXTENDED_VME defined).
The 16MB address range for the new CR/CSR space needs to be adjacent to
(or possibly in between) the other VME master windows, and it must start
on a 16MB boundary. In order to meet those requirements you may have to
move the A16 master window, or you might be able to put it immediately
below the A24 window in the gap that the A32 window can expand into.
The Universe-2 chip has 8 PCI slave windows that can map VME memory onto
the board's PCI bus. Some of those windows will already be in use, but
there will usually be some spares. Look in the header file(s) named
after the BSP (mv2100.h, mv5100.h, mv5500A.h etc.) for a section where
macros with names like VAL_LSI1_BS_VALUE are set.
My example below for the MVME5100 board (mv5100 BSP) uses the address
range 0xf2000000 - 0xf2ffffff for CR/CSR space, and the PCI slave window
number 4, but you should not assume that these will be available in your
mv5100 BSPs. I have made many other changes to this BSP including moving
the windows around and changing their allocations.
Add the following definitions to the header file, replacing the 0xf2 and
LSI4_ prefixes with your own chosen values:
=== modified file 'mv5100.h'
/*
* VME MASTER WINDOW FOR CR/CSR SPACE
*
* Universe PCI slave (VME master) window 4
*/
/*
* Map access to CR/CSR VMEbus - 16M
* This maps: MPU RANGE: 0xf2000000 - 0xf2ffffff
* to: PCI RANGE: 0xf2000000 - 0xf2ffffff
* to: VME RANGE: 0xff000000 - 0xffffffff
*/
#define VME_CRCSR_MSTR_LOCAL 0xf2000000
#define VAL_LSI4_BS_VALUE (VME_CRCSR_MSTR_LOCAL)
#if (VME_CRCSR_MSTR_SIZE & ~0x01000000)
# error VME_CRCSR_MSTR_SIZE must be 0 or 16 MB
#endif /* (VME_CRCSR_MSTR_SIZE & ~0x01000000) */
#define VAL_LSI4_BS (VAL_LSI4_BS_VALUE)
#define VAL_LSI4_BD (VAL_LSI4_BS + VME_CRCSR_MSTR_SIZE)
#define VAL_LSI4_TO (0xff000000 + VME_CRCSR_MSTR_BUS - VAL_LSI4_BS)
#define VAL_LSI4_CTL ( LSI_CTL_EN | LSI_CTL_WP |\
LSI_CTL_D32 | LSI_CTL_CSR |\
LSI_CTL_DATA | LSI_CTL_SUP |\
LSI_CTL_SINGLE | LSI_CTL_PCI_MEM )
=== end
In the same header file you should find definitions for three macros
named VME_MEM_LOCAL_START, VME_MEM_LOCAL_SIZE and VME_MEM_LOCAL_END or
for two macros named VME_MSTR_LO_ADRS and VME_MSTR_HI_ADRS. These are
used to let the BSP code know which CPU addresses are actually mapped to
the VMEbus. Adjust their values if and as necessary to ensure that their
range includes your new CR/CSR window.
Finally there may be another macro defined in the same header file
called IS_VME_ADDR_MOD. If it is present, it will need to be extended to
also recognize the value VME_AM_CSR as being a VME address modifier.
This change can be seen on slide 8 of Eric Bjorklund's presentation.
Next we have to add an MMU mapping for the new window. These mappings
are defined in an array named sysPhysMemDesc[] found near the beginning
of the sysLib.c file. Add the following block at an appropriate place in
the array:
=== modified file 'sysLib.c' array 'sysPhysMemDesc'
/* CR/CSR VME WINDOW */
{
(VIRT_ADDR) VME_CRCSR_MSTR_LOCAL,
(PHYS_ADDR) VME_CRCSR_MSTR_LOCAL,
VME_CRCSR_MSTR_SIZE,
VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE |
VM_STATE_MASK_GUARDED,
VM_STATE_VALID | VM_STATE_WRITABLE | VM_STATE_CACHEABLE_NOT |
VM_STATE_GUARDED
},
=== end
Another change to the sysLib.c file is to modify the sysBusToLocalAdrs
routine. Different BSPs have different versions of this code and you
should copy the code you have for the VME_AM_STD_ address modifiers and
change it to recognize the address modifier VME_AM_CSR. Some versions
read the window address range from a data structure so the added code
might not need any references to the VME_CRCSR_MSTR_* macros, but added
code for the mv5100 BSP should probably look like this:
=== modified file 'sysLib.c' routine 'sysBusToLocalAdrs'
case VME_AM_CSR:
if (((ULONG) busAdrs >= VME_CRCSR_MSTR_BUS) &&
((ULONG) busAdrs < (VME_CRCSR_MSTR_BUS + VME_CRCSR_MSTR_SIZE)))
{
*pLocalAdrs = busAdrs + (VME_CRCSR_MSTR_LOCAL - VME_CRCSR_MSTR_BUS);
break;
}
return ERROR;
=== end
In the mv5100 BSP the sysVmeProbe routine which is also in sysLib.c has
references to the individual VME master windows so must be adjusted when
adding the CR/CSR space with the additional code shown below, but other
BSPs may not need anything equivalent:
=== modified file 'sysLib.c' routine 'sysVmeProbe'
else if ((VME_CRCSR_MSTR_SIZE != 0) && ((UINT32)adrs >= VME_CRCSR_MSTR_LOCAL) &&
((UINT32)adrs <= (VME_CRCSR_MSTR_LOCAL + VME_CRCSR_MSTR_SIZE)))
lsiCtlReg = (UINT32)(UNIVERSE_LSI4_CTL);
=== end
Finally we add the code that programs the PCI slave window, found in the
file universe.c. The routine sysUniverseReset initializes the window
control register to zero, so will need extending to set the newly chosen
register number like this:
=== modified file 'universe.c' routine 'sysUniverseReset'
UNIV_OUT_LONG(UNIVERSE_LSI4_CTL, 0);
=== end
The routine sysUniverseInit programs all the window registers, and will
need extending like this:
=== modified file 'universe.c' routine 'sysUniverseInit'
/* Map to get to VMEbus using CR/CSR */
UNIV_OUT_LONG(UNIVERSE_LSI4_BS, VAL_LSI4_BS);
UNIV_OUT_LONG(UNIVERSE_LSI4_BD, VAL_LSI4_BD);
UNIV_OUT_LONG(UNIVERSE_LSI4_TO, VAL_LSI4_TO);
UNIV_OUT_LONG(UNIVERSE_LSI4_CTL, VAL_LSI4_CTL);
=== end
- References:
- VxWorks 6.9 Stefen Paul
- Re: VxWorks 6.9 Andrew Johnson
- Re: VxWorks 6.9 Stefen Paul
- Re: VxWorks 6.9 Stefen Paul
- Re: VxWorks 6.9 Andrew Johnson
- Re: VxWorks 6.9 Stefen Paul
- Re: VxWorks 6.9 Andrew Johnson
- Re: VxWorks 6.9 Stefen Paul
- Re: VxWorks 6.9 Andrew Johnson
- Navigate by Date:
- Prev:
RE: Active modbus read function upon request Mark Rivers
- Next:
RE: epicsqt question Andrew Rhyder
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
<2016>
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: VxWorks 6.9 Andrew Johnson
- Next:
Indices returned by asynPortDriver::createParam Phil Atkin
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
<2016>
2017
2018
2019
2020
2021
2022
2023
2024
| 
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·