The MVME2700 series is a family of VME processor modules based on the Motorola
PowerPlus? VME Architecture with PowerPC architecture microprocessors that push
performance and functionality to limits unprecedented on VME. The flexibility of the
MVME2700 provides an excellent base platform that can be quickly and easily
customized for a variety of industry-specific applications.
Designed to meet the needs of military and aerospace, industrial automation, and
medical, the MVME2700 applies to a variety of applications.

MPC750 class 32-bit microprocessor

32KB/32KB L1 cache

1MB backside L2 cache

128MB or 256MB ECC DRAM on-board memory

8MB on-board Flash, 1MB socketed

64-bit PCI mezzanine connector

On-board debug monitor with self-test diagnostics

IEEE P1386.1 compatible 32/64-bit PMC expansion slot

Two or three async, one or two sync/async serial ports

Ethernet transceiver interface with 32-bit PCI local bus DMA

8- or 16-bit Fast SCSI-2 bus interface

Parallel, floppy, keyboard, and mouse interfaces

8KB x 8 NVRAM and time-of-day clock with replaceable battery backup

Four 32-bit timers, one watchdog timer

One VME slot, even when configured with PMC module

Known Issues

Issuing bsp_reset() does not reset the board (prior to 4.9)

There's a bug that likely occurs in mvme2300-2700. A call in libbsp/powerpc/shared/console/reboot.c attempted to board reset via the keyboard port. This resulted in a NOOP (i.e., nothing happened and the board did not reset). ​PR1362 included this proposed patch which sets bit 1, port 0x92. This successfully resets *only* the board and I've also verified it does not reset the VME bus as described below.

Tests performed:

I set bit 1 port 0x92 and removed the keyboard call. I verified that exit did (at least) a board reset. That works.

I also performed an exit with the board SYSCON disabled (J20). I again verified the exit performed a board reset, but it did not affect any peripheral boards.

SYSCON reenabled now, I included a peripheral board (vmic5588) and initialized it to make the fail light turn off. I again issued an exit and the 5588 fail light remained off, while the 2700 reset.

I verified pushing the RST on the 2700 that my 5588 fail light transition from OFF->fail, implying this is what I should see during a VME bus reset.

So I think this is a sufficient test indicating the board reset works and is independent of resetting the VME bus, which has also been verified with vmeUniverseResetBus().