VME A16 Master window access. Help plz!!

Hi,

We have a big problem getting access to the A16 master window on
Motorola MVME5100.

Background:
We are using a MVME5101 board with 64MB SDRAM. We use the this board to
connect to a VMIC1111 Digital Input board over the VME backplane. The
digital board uses VME addresses in the range of 0xc000 to 0xc007 as
input ports and 0xc008 to 0xc009 as CSRs.
The digital board is jumpered to supervisory access mode.

Our goal:
We need to use the MVME5101 board read from the Digital Input board!

Problem:
We have been having trouble reading or writing to the local address
translated from the VME bus address on A16 master window.
By default, the MVME5100 BSP provides us the following parameters of
A16
VME_A16_MSTR_BUS = 0x0
VME_A16_MSTR_LOCAL = 0xfbff0000
VME_A16_MSTR_SIZE = 0x10000

The return status of sysBusToLocalAdrs(0x2d, 0xc000, (char*)&localAdrs)
is OK with localAdrs = 0xfbffc000
However, when we use vxMemProbe((char*)localAdrs, VX_READ, 1,
(char*)readBuf)
to read from this local address, the program crashes.

We thought this crash was due to incorrect translation from local
address back to VME address(from the CPU point of view). So we took a
look at the MVME5100 BSP and found out the following translation rule
for A16 master window:
VAL_LSI3_BS = VME_A16_MSTR_LOCAL = 0xfbff0000
VAL_LSI3_BD = (VAL_LSI3_BS + VME_A16_MSTR_SIZE) = 0xfbff0000+0x10000 =
0xFC000000
VAL_LSI3_TO = (0xffff0000 + VME_A16_MSTR_BUS - VAL_LSI3_BS) = 0x4000000

We thought the translation offset wasnt' correct, so we modified it to
be 0x4010000, but still the crash remained. We even change the board
register LSI3_BS, LSI3_BD, LSI3_TO using ppc6-debuger. None of them
works.

We called WRS tech support, they haven't solved the problem yet.

Anybody had experience solving this?

Many thanks in advance!

Ray

In article <1147729350.038579.216800@i39g2000cwa.googlegroups.com>,
Ray <alienatsf@gmail.com> wrote:[color=blue]
>We are using a MVME5101 board with 64MB SDRAM. We use the this board to
>connect to a VMIC1111 Digital Input board over the VME backplane. The
>digital board uses VME addresses in the range of 0xc000 to 0xc007 as
>input ports and 0xc008 to 0xc009 as CSRs.
>The digital board is jumpered to supervisory access mode.[/color]

I'm using a MVME5110-2261 (same BSP as your MVME5101) but with 500 MB.
I have some I/O boards in VME_AM_SUP_SHORT_IO at 0xc000, 0xc040, 0xc080
and 0xc0c0 which sysBusToLocalAdrs gives as 0xfbffc000, 0xfbffc040,
0xfbffc080 and 0xfbffc0c0. My initialization code does vxMemProbe
VX_READ at those addresses which return successfully and I can read and
write to those boards without problem.

Double check the jumpers on your digital I/O board. Also, confirm that
the address you are doing the VX_READ on is suppose to be readable. If
that still doesn't work, make sure your code is doing what you think it
is doing. I don't think it is a problem with the BSP.

Some items missing from your post: How does the program "crash" on the
vxMemProbe()? What version of VxWorks are you using (I'm using VxWorks
5.5.1).

--
Steve

Thanks Steve,


We are using VxWorks 6.2 with Workbench 2.4 (latest version from wind
river). The "crash" has two parts. If we connect the board to a target
server, the "crash" means the connection to target server is lost. If
we don't connect the board to target server, instead we use the shell
to test, the "crash" means it hangs there, never returns a value and
never let us type anything.

We double checked the jumpers and saw no mistakes. the IO board is
using 0xc000 to 0xc007 as inputs and 0xc008 to 0xc009 for CSRs. 0xc009
is for LED testing.

any idea?

In article <1147802524.831540.175440@i39g2000cwa.googlegroups.com>,
Ray <alienatsf@gmail.com> wrote:[color=blue]
>We double checked the jumpers and saw no mistakes. the IO board is
>using 0xc000 to 0xc007 as inputs and 0xc008 to 0xc009 for CSRs. 0xc009
>is for LED testing.[/color]

Are there any other I/O boards in the crate (perhaps one whose address
space overlaps with your VMIVME-1111?)

I don't have a 1111 here; is it similar to the VMIVME-1182 digital input
board? I have one of those in use with a mvme-5100 with no problems. I
would suggest taking all the cards out of the crate except the 5100 and
the 1111. Then, from the shell, use the m command to write to the
board at 0xfbffc000 and see if you can turn off the front panel fail
LED by writing a 1 to whichever bit in the CSR controls it. Once you
can do that, things should fall in place quickly. Also, try

d 0xfbffc000

from the shell and see what you get.

--
Steve

When you do the above "m" commands, you may get a bus error - that
means the slave board did not respond and you got a bus error that
might show up as a machine check in the shell.

Some VME boards can be jumpered so that a machine check can be trapped
by software. Then you can use vxMemProbe to probe out some addresses on
a board to see if it's present, seated correctly, jumpered correctly,
etc.

If you display mem that you think is on the board and it machine checks
OR comes back all 0xFF, then the board is probably not in the VME where
you think it is.

Good luck,
lc

PS: Do these experiments from a shell on the serial port. Too many
things can go wrong with tgtSvr/windSh during this phase

Steve,

I've tried m() and d() on those addresses from 0xfbffc000 to
0xfbffc009. The system still hangs!!. I've tried putting the motorola
board in with the VMIVME-1111, also have tried with other boards (we
have another identical motorola board in the crate), none of them
worked! I've also tried the kernel image from WRS tech support. all
got the same problem. so i have come to conclusion that it is due to
the hardware problem or bootrom problem. all jumpers are the same as
default settings on mvmv5101. so it must be something wrong with the
bootrom. I am not sure whether my predecessors changed the bootrom or
not. Do you know where i can get a bootrom for our board
MVME5101-2133, MPC7400, with 64MB SDRAM?

Regards,

Ray

Not sure on the bootrom issue. It has very little to do with the VME
mapping once the kernel is loaded.

You are going to need to try those commands from a real console shell
and see if they give machine checks. From what you are saying, that
sounds likely that the addresses will not respond, which implies it's a
board issue.

Some BSP have the ability to dump out the VME mapping registers that
show the VME configuration. That would confirm your slave window
settings are corrent.

The command would be something like the following. If the settings are
as you expect, then it's a HW issue - jumpers on the slave board
possibly. A VME bus analyzer is always a sure way to diagnose these
issues if you have one available.

Good luck,
lc

vxKernel] -> sysVmeWindowsShow


default A16 window base address is 0xf3ff0000
default A16 window bound address is 0xf4000000
default A16 window translation offset is 0xc010000


default A16 window #2 base address is 0xf3fe0000
default A16 window #2 bound address is 0xf3ff0000
default A16 window #2 translation offset is 0xc020000


default A24 window base address is 0xf2fe0000
default A24 window bound address is 0xf3fe0000
default A24 window translation offset is 0xd020000


default A24 window #2 base address is 0xf1fe0000
default A24 window #2 bound address is 0xf2fe0000
default A24 window #2 translation offset is 0xe020000


default Dynamic window base address is 0xf1bd0000
default Dynamic window bound address is 0xf1fd0000
default Dynamic window translation offset is 0x8e430000
special PCI target image data ...SLSI value is 0x0
value = 18 = 0x12
[vxKernel] ->

Larry,

I've seen this sysVmeWindowsShow command from this group. I tried it
last week and no such function(command) exist anymore in vxWorks6.2.
The only way to look at it is to mv5100.h to see.

Unfortunely, we don't have a VME bus analyzer. I am replacing the
bootrom provided by WRS. hope it works. If it doesn't, does anybody
have any idea about what cause this problem? i am sure it's not the
software part problem. then it must be hardware, but how come there is
no problem running other things but only VME get problem?

Ray

In article <1147814337.870571.217370@j33g2000cwa.googlegroups.com>,
Ray <alienatsf@gmail.com> wrote:[color=blue]
>
>I've seen this sysVmeWindowsShow command from this group. I tried it
>last week and no such function(command) exist anymore in vxWorks6.2.[/color]

sysVmeWindowsShow() isn't on my 5.5.1 installation, either. Nor is it in
the VxWorks reference guide.
[color=blue]
>Unfortunely, we don't have a VME bus analyzer.[/color]

Can you strip the system down to the bare minimum for testing? Just the
mv5100 and the VMIVME-1111 and no application code? Use the serial port to
connect. You can use the following functions from the shell:
sysBusToLocalAdrs(), m(), d(), and vxMemProbe(). If that doesn't work,
try changing the address on the 1111 to something else. Then try
changing it from supervisory to non-privileged. If the 1111 lets you,
try changing from short to standard.

I've never seen an m, d, or vxMemProbe hang the system, even when
looking at an address that isn't there. At worst, a bus error, as
LarryC said. Will a ^c get your shell back after the hang? Is the CPU
LED on the 5100 staying on when it hangs?

Good luck,
--
Steve

Steve,

I've just replaced the bootrom from wind river tech support. the
problem remains!

Yeah I've never seen this situation before, nor the Wind River tech
support guy. I've tested sysBusToLocalAdrs(), m(), d(), vxMemProbe(),
bcopyBytes(), directly pointer to address to write or read on the
shell, not with the application code. Only the sysBusToLocalAdrs()
returns the local address (because this function doesn't actually do
anything to VME address, it only does math), other functions just hang
the system!!. Yes, the CPU LED on the mv5100 does stay on when it
hangs.

The VMIVME-1111 can't be set to use standard A24. It only uses the A16
window. however I can set the jumpers on it to change the VME access
address and the supervisory or non-priviledged mode. Ok let me try
some now.

Thanks so much,

Ray

Hi:

If you're not getting a machine check or DS exception on the shell and
the board is locking up instead, something's not set up for these
interrupts.

Did you build the kernel for this board with VME support built in? The
Tornado project entry for VME will have the properties to set up the
#defines needed to set up the Universe chip to support VME accessed.

Not all BSP's have sysVmeShow functions, but your BSP (it's a BSP
function if it starts with sys*) might have something similar. Take a
look at sysLib.c to see if you see any vme functions in there.

Good luck,
lc

Hi,

After testing with a brand new VME chassis, I discovered the "hang" was
due to the loose connection between the SBC and the backplane.

However, the vxMemProbe() function always return -1 (ERROR) no matter
how hard I tried on A16 master window local addresses (0xfbff0000 to
0xfc000000). The WRS tech support guy could run with return value 0
(OK). I also tested with a brand new MVME6100 SBC on A16 master window
local addresses (0x91000000 to 0x91010000). Everything was good.

So this must be either the BSP having problem instructing the board to
translate mapped local address to VME address or the MVME5100 board has
problem with the translation registers. Any experience in the Universe
II chip register debugging?

Regards,
Ray

In article <1147976699.886052.301350@i39g2000cwa.googlegroups.com>,
Ray <alienatsf@gmail.com> wrote:[color=blue]
>However, the vxMemProbe() function always return -1 (ERROR) no matter
>how hard I tried on A16 master window local addresses (0xfbff0000 to
>0xfc000000).[/color]

-> foo = 0;
foo = 0x1e915c00: value = 0 = 0x0
-> vxMemProbe(0xfbffc000,0,2,&foo);
value = 0 = 0x0
-> foo
foo = 0x1e915c00: value = -17956864 = 0xfeee0000 = topbin + 0xe0000c40
-> version
VxWorks (for Motorola MVME5110-2261 - MPC 7410) version 5.5.1.
Kernel: WIND version 2.6.
. . .

with a board at 0xc000 in short, supervisory space which has 0xfeee in
the read-only register at offset 0.

Check your hardware.

--
Steve

Steve,

[color=blue]
> -> foo = 0;
> foo = 0x1e915c00: value = 0 = 0x0
> -> vxMemProbe(0xfbffc000,0,2,&foo);
> value = 0 = 0x0
> -> foo
> foo = 0x1e915c00: value = -17956864 = 0xfeee0000 = topbin + 0xe0000c40
> -> version
> VxWorks (for Motorola MVME5110-2261 - MPC 7410) version 5.5.1.
> Kernel: WIND version 2.6.
> . . .[/color]

On my hardware it displays:
-> foo = 0
New symbol "foo" added to kernel symbol table.
foo = 0x6ceed0: value = 0 = 0x0
-> vxMemProbe(0xfbffc000,0,2,&foo);
value = -1 = 0xffffffff
-> vxMemProbe(0xfbffc000,0,2,&foo)
value = -1 = 0xffffffff
-> foo
foo = 0x6ceed0: value = 0 = 0x0
-> version
VxWorks (for Motorola MVME5101-2133 - MPC 7400) version 6.2.
Kernel: WIND version 2.8.
....

So it always returns -1.

Steve, did you put the SBC, which is used to talk to the backplane, in
the VME slot 0? I discovered something last evening. If we put the
board not in slot 0, it hangs again. but if we put it back to slot 0,
it returns -1. same "hang" happens when we use the MVME6100 for
comparison, however mvme6100 doesn't hang in slot 0. it returns 0 (OK).


We are now narrowing down the problem. It is mostly due to the BSP
problem, we guess. Some of the registers initialization functions in
universe.c of the BSP may not work correctly on our particular series
of MVME5101-2133 board. We come up with this guess because we use the
ppc6-bug to directly write 1 to 0xfbffc009. no error found. but the
VMIC-1111 LED didn't turn off though. Not sure why. The LED didn't
turn off as well when we used the MVME6100 for testing on VME address
c009 (6100 uses 0x9100c009 for local address).

Any of you had experience in the BSP development? Thanks

Ray

Before you hack the universe registers directly, look around for the
equivalent of sysVmeWindowsShow from some elses BSP or from Tundra.
Confirm the values are what you want. You can also examine/change them
via the Tornado project properties (on most BSPs at least).

The really only other issue that can come into play other that universe
registers is the size of the pci window. The more space you need on
the VME for windows, the large the window given to the universe part in
the entire pci space. There are also Tornado project parameters for
that that you can change.

Sounds like your board is a system controller and belongs in Slot0.

Good luck,
lc

In article <1148058952.175244.236610@j55g2000cwa.googlegroups.com>,
Ray <alienatsf@gmail.com> wrote:[color=blue]
>Steve, did you put the SBC, which is used to talk to the backplane, in
>the VME slot 0?[/color]

Yes. It's the crate controller.
[color=blue]
>We are now narrowing down the problem. It is mostly due to the BSP
>problem, we guess.[/color]

I'm not so sure about that.
[color=blue]
>We come up with this guess because we use the
>ppc6-bug to directly write 1 to 0xfbffc009. no error found. but the
>VMIC-1111 LED didn't turn off though. Not sure why.[/color]

Find out why. If the LED didn't turn off, ppc-bug likely did not write
to that address on the board. VxMemProbe is returning an ERROR because of
a bus error (most likely), but I don't think ppc-bug is going to tell
you that. Can you use ppc-bug to read a read-only register on the 1111
with a known value (like the board ID)?
[color=blue]
>The LED didn't
>turn off as well when we used the MVME6100 for testing on VME address
>c009 (6100 uses 0x9100c009 for local address).[/color]

Then you either have a hardware problem or a misconfigured 1111 board.

One of the reasons I like VMIC's VME I/O boards is that they always
have that fail LED. One of the first steps when working with a new I/O
board is to write to that LED register to turn off the LED. Once you can
do that, you know the board is configured correctly and you are working
at the right address, then you can start writing your device driver.

--
Steve

Hi guys,

We finally figured out the problem. It's because the backplane
connectors are dirty with dust and oil, possibly from hands. We've been
using the backplane chassis for 5 years. So it is hella dirty inside I
believe.

Is there a way to clean the oil inside the connectors on backplane? We
could use canned air to clean the dust.

Thanks

Ray