Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Mon, 26 Apr 2010 10:42:04 -0500

On Sunday 25 April 2010 02:18:58 éè wrote:
>
> I'm from SSRF. After I use sysVmeMapShow() function to the MVME5500 BSP, it
> display as follow:
>
>    -> sysVmeMapShow
>
>    VMEbus access from CPU:
>    CPU: 0xE7F00000 - 0xE7F3FFFF  =>  A32: 0xE7F00000 - 0xE7F3FFFF
>         0xEFF00000 - 0xF0EFFFFF  =>  A24:   0x000000 -   0xFFFFFF
>         0xF0F00000 - 0xF0F0FFFF  =>  A16:     0x0000 -     0xFFFF
>
>    CPU access from VMEbus:
>         A32:             -             =>            -
>         A24:    0x000000 - 0xFFFFFFFF  => 0x0F0F0000 - 0x0F0EFFFF
>    value = 0 = 0x0
>
> Do you think the display is OKïThe A32 address is available? Would you mind
> give me some suggestion about the blank of A32 address in "CPU access from
> VMEbus"?

I should first explain how to read the two parts of the command output:

The first section, "VMEbus access from CPU" shows you the VME Master windows 
from the Universe-2 bus bridge, i.e. which VME address ranges the programs 
running on the MVME5500 CPU have direct access to.  If a program does a read 
from address 0xf0f08000 it will be converted into a VMEbus read from address 
0x8000 in the A16 address space, and similarly for the other addresses in that 
range.  The addresses in this section are the ones that you normally need to 
know about when thinking about VME slave boards.

The second section "CPU access from VMEbus" probably should really be titled 
"RAM access from VMEbus".  It shows you the VME Slave windows from the 
Universe-2 bus bridge, i.e. at which VME addresses (if any) the RAM on the 
MVME5500 can be accessed by any other VME Bus Master boards in your system.  A 
VME Master might be a board with a built-in DMA controller but no local RAM, 
or it might even be a CPU board such as another MVME5500.  These are less 
common, but they do exist and get used with EPICS.  You should only worry 
about the addresses in this section if you know you have a board that can act 
as a VME Bus Master.

Now, in your case above the addresses in the second section do not look 
correct to me, but this could be for a number of reasons related to which 
Universe-2 slave windows are programmed by the BSP for which purposes.  I 
suspect that the sysVmeMapShow() code was programmed specifically for the 
board it came from, and if you didn't adjust it correctly when you added it to 
your BSP then if may be showing the wrong information.

If you don't have any other VME Bus Master boards in the system you probably 
don't need to worry about this and I would recommend deleting that section of 
code from the sysVmeMapShow() routine so as not to cause confusion in the 
future.

If you /do/ have any boards with a VME Bus Master interface that you plan to 
use, you probably will need your to open a VME Slave window on your Universe-2 
bridge to give the board(s) access to an area of the CPU's memory for them to 
do I/O into.  In that case you should fix the sysVmeMapShow() code by looking 
at how the mv5500 BSP sets up the chip's window registers and making sure that 
you display the right ones.  

You will have to read the MVME5500 User Guide and Programmer's Reference 
Manual from the board manufacturer (downloadable from their website usually) 
and the Universe-2 Reference Manual from the Tundra website and learn how CPU 
addresses get mapped to the PCI bus and then how the Universe-2 registers let 
you set up mappings between the PCI bus and VME bus and back.  This could take 
some time to understand, and unfortunately every MVME CPU board and Wind River 
BSP is different.

- Andrew
-- 
The best FOSS code is written to be read by other humans -- Harald Welte

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System