1. Forum
  2. Usenet
  3. COMP.OS.OS9

  • MVME177, MVME335, Caching, serialized access, ...

    From Ralf Kiefer@21:1/5 to All on Wed Oct 31 02:16:50 2018
    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)
  • From Ralf Kiefer@21:1/5 to All on Wed Oct 31 12:02:52 2018
    /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)
  • From Dennis Boone@21:1/5 to All on Wed Oct 31 07:40:33 2018
    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)
  • From Ralf Kiefer@21:1/5 to Dennis Boone on Wed Oct 31 14:37:09 2018
    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)
  • From Ralf Kiefer@21:1/5 to All on Mon Nov 5 01:34:08 2018
    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)