Hi,

actually I want to add a MVME335 (two M68681 ACIAs and one M68230) to my MVME177 (68060 @60MHz) running V3.0.3.

The MVME335 is located in A16 (short IO of the VMEbus and not in A24): $FFFF.xxxx. It's jumpered to $FFFF.F8xx. Observation: I cannot use
$FFFF.00xx because the MVME177 occupies the first 16bytes. This is not documented. I don't know the cause of this unexpected behaviour. But I
see also some other strange behaviour: In Rombug I want to read the
address space of the MVME335. "d $ffff.f800" displays the first 16
bytes, than Bus error. I can read the following 16bytes by typing "d
ffff.f810" and so on. There is always a bus error after reading 16 bytes
(a single cache line?).

After booting OS-9 (Kernel Ed.336 or Ed.375), my own init module and the sc68681 Ed.39 or Ed.40 I see the same: bus error with the first access
to the MVME335. Cache and SSM are configered to copy back mode between $0000.000 and $1000.0000 and to serialized access/cache inhibited from
start of A24 at $F000.0000 to $FFFF.FFFF (including A24, A16, the local
devices and ROM). The I/O devices from the MVME177 are working well
(CD2401, clock, SCSI). "ssm060" is Ed.6 or Ed.7, "cache060" is Ed.23 or
Ed.25. No difference.

Probably this problem is independant of OS-9 but I don't really know.


There is something more irregular with that box: it's a VMEbus system
based on a 12slot Schroff backplane (P1 & P2) with the 5 jumpers per
slot for Bus grant and IACK. This backplane does not use the more modern automatic mode. But it's strange: I can add cards in slots at the right
end of the backplane without jumpering the IACKs of the slots between
the cards at the left end. The interrupt driven drivers are working.
There is a EKF LAN 68570 (running OS-9/NET and ISPNET) and a Radstone
SIO-3 (intelligent serial card). Both are working well without correct jumpering of the backplane.

I'm confused and actually without any idea.

Regards,
Ralf

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

/me wrote:

Probably this problem is independant of OS-9 but I don't really know.

Additional observation: I've forgotten to use the 177-bug from Motorola
in the FLASH ROM.

When I configure the ENV parameters to use A16 I get correct access to
A16 from 177-bug: bus error at $FFFF.0000, and no bus error between
$FFFF.F800 and $FFFF.F8FF (address space of the MVME335). That's what I
expect to see. But in Microware's Rombug the configuration from VMEbug
is lost. And wrong. No access to A16.

Regards,
Ralf

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

The MVME335 is located in A16 (short IO of the VMEbus and not in A24): $FFFF.xxxx. It's jumpered to $FFFF.F8xx. Observation: I cannot use $FFFF.00xx because the MVME177 occupies the first 16bytes. This is not documented. I don't know the cause of this unexpected behaviour. But I
see also some other strange behaviour: In Rombug I want to read the
address space of the MVME335. "d $ffff.f800" displays the first 16
bytes, than Bus error. I can read the following 16bytes by typing "d ffff.f810" and so on. There is always a bus error after reading 16 bytes
(a single cache line?).

I know nothing about these specific boards, and very little about
VME, but:

1. Do you have an addressing overlap?

2. Are you requesting, e.g., a 16-bit transfer from a device that
only supports 8-bit transfers?

De

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Dennis Boone wrote:

1. Do you have an addressing overlap?

No. The MVME177 reserves the address space from $FFFF.0000 to $FFFF.FFFF
as A16. This is "VMEbus", means pre-decoded. There is no other card. But
it's the first time ever I want to use this address space. In the past I
had just cards in A24 or in A32.

I changed the jumpers onto the MVME335 and I saw what I expected. The
same behaviour with the other addresses. Or always Bus errors without
the MVME335.

The MVME335 can just do A16 and nothing else. But it's possible.
Microware mentioned exactly this combination in their manual.

2. Are you requesting, e.g., a 16-bit transfer from a device that
only supports 8-bit transfers?

See my other posting: I tried the same from Motorola's VMEbug (or
"177-bug"), and there I see what I expect.

Another observation: the driver sc68681 wants to access the MVME335 for
the first time with this instruction:
move.b MPSVec(a5),d0 read current device vector

Bus error.

Motorola's VMEbug is the first code running after Reset. This code is in
the flash ROM of the MVME177. The EPROM sockets are populated with the
code from Microware with ROMbug, a OS9Boot to boot from EPROM and a
complete (but minimal) OS-9 for emergency cases. The default is booting
OS-9 from SCSI disk without using any ROM code after having booted.

So I think there is a problem with the configuration of cache, ssm,
snooper or something like that in the Microware part.

Regards,
Ralf

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Some news :-)

The VMEchip2 from the MVME167 and MVME177 (and some other?) cannot
access bytes in the Short IO (A16) address space. Means: bus error when
move.b to or from the MVME335. Move.w or move.l are ok for accessing the
board but move.w is preferred because of the address definitions.

So the driver sc68681 cannot work. One possible solution: changing the "longio.m" in /dd/DEFS, means the macro REGMOVE and the local macro
CHECK. I would prefer to change the code directly without the macro
stuff.

Seem's to me that I'm the first who ever tried to use a MVME335 beside a MVME167/MVME177 although this combination was explicitly mentioned by Microware.

Regards,
Ralf

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)