I'm working on resuscitating a system that includes an SBC first used in 1995. The model number is MVME 167, and the add-on eeprom slots hold 2 vxworks v 1.0 chips, but I've yet to be able to login as I'm still trying to navigate the requirements of
VXworks compatibility. Originally this system was managed by an old Sun workstation, and I suspect it was not upgraded due to compatibility issues. All of the components are in good working order, I think, and have been previously configured to run the
current application, so my first step is just to communicate with the SBC. If I don't intend to build any applications on this card myself, just operate it as it is currently programmed, all I need is Telnet, is that correct?

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

Telnet might work, depending on how the VxWorks kernel was configured. More common was support for rlogin. You could try using rlogin (which you might need to install, depending on your host system) to contact the system. This assumes you know for sure what the IP address for the target VxWorks system is.

If you don't know the IP address or you continue to have trouble logging in over the network, you could take the more traditional approach. Connect a serial line to the system and connect directly with the VxWorks console shell. On the other end of the serial line you'll need to use a terminal emulator such as minicom or kermit, or go really retro and use an actual terminal (if you have one). The usual default serial settings were 9600 baud, 8-bit, no parity.

Once you can talk to the console, look at the boot parameters to see how the system is configured to talk to the network. (Try the bootChange command, and keep hitting return to step through all the settings.)

Good luck.

In article <6d78a16c-2375-4728-93cb-92fe983093f8@googlegroups.com>,
SpaceSpaz <amberlauer@gmail.com> wrote:

I'm working on resuscitating a system that includes an SBC first used in >1995. The model number is MVME 167, and the add-on eeprom slots hold 2 >vxworks v 1.0 chips, but I've yet to be able to login as I'm still
trying to navigate the requirements of VXworks compatibility. Originally
this system was managed by an old Sun workstation, and I suspect it was
not upgraded due to compatibility issues. All of the components are in
good working order, I think, and have been previously configured to run
the current application, so my first step is just to communicate with
the SBC. If I don't intend to build any applications on this card
myself, just operate it as it is currently programmed, all I need is
Telnet, is that correct?

--
Todd Litwin
Jet Propulsion Laboratory
Phone: (818) 354-5028; FAX: (818) 393-5007
Email: Todd.E.Litwin@jpl.nasa.gov

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

Perhaps I better back up, I think I'm making some assumptions that aren't necessarily correct. I may have access to the host software for vxworks and vxworks workbench, but right now I'm just trying to see if I can communicate with the SBC. I intend to
do that over LAN, because that is the only connection available. So I need to properly configure the network (which involves an unmanaged switch) and get the IP of the SBC. If I can do that, then I can try rlogin or telnet to talk to it. Can I send
commands over these protocols? Or do I need to install the host software? I have been working under the assumption that the vxworks host software is only necessary if I want to reprogram the target or add functionality. Final question: If I get one of
the more current versions (not sure which one my group purchased), will it support an SBC that old?

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

You say this is a board from the 1990s? If so, and if it was previously in service (as opposed to being a new unit that's been sealed in its box for 20 years), then I would expect that VxWorks has been installed on the board in non-volatile memory. (There are other possibilities, but this kind of setup was very common.) As such, VxWorks would boot automatically when the board is powered up. Its network would be configured according to the boot parameters that were saved on the board.

Assuming you cannot predict what the boot parameters are, I would not connect it to the local area network until I could review those parameters and make them compatible with the network. Otherwise you can confuse other devices on your network.

Without using the network, the only reasonable way you can see what's happening on the board is to connect a terminal to the serial port. That way you can watch the default VxWorks printout as the system boots, and then command it
to review and change boot parameters.


In article <00eaa9d4-b511-47aa-b9e7-180b9be884ef@googlegroups.com>,
SpaceSpaz <amberlauer@gmail.com> wrote:

Perhaps I better back up, I think I'm making some assumptions that
aren't necessarily correct. I may have access to the host software for >vxworks and vxworks workbench, but right now I'm just trying to see if I
can communicate with the SBC. I intend to do that over LAN, because that
is the only connection available. So I need to properly configure the
network (which involves an unmanaged switch) and get the IP of the SBC.
If I can do that, then I can try rlogin or telnet to talk to it. Can I
send commands over these protocols? Or do I need to install the host >software? I have been working under the assumption that the vxworks host >software is only necessary if I want to reprogram the target or add >functionality. Final question: If I get one of the more current versions
(not sure which one my group purchased), will it support an SBC that
old?

--
Todd Litwin
Jet Propulsion Laboratory
Phone: (818) 354-5028; FAX: (818) 393-5007
Email: Todd.E.Litwin@jpl.nasa.gov

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

Hi
Never heard of this sbc model.
Any case, Todd is right to the point.
To even see the boot rom you'll need to get it connected to a serial port. A lot of guess work to guess the actual settings but as I recall in the 90s default setting windriver had was 96007e1 for the rs232 connection.

To your workbench support question, you might be lucky and this sbc or at least the boards mcu is supported, yet I doubt it.

Most probably tornado was used to program this board.

Interesting project you've started, this is the first time I reply to this group since 2001 I think. I thought the group has only spam.

Good luck.

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

Thanks Sinan and Todd, you have confirmed what I suspected after trying a few things to network with the card. I had a spare PC that wasn't doing anything so I tried to connect the two, first using a Cat5 crossover cable, and then via an unmanaged switch.
I was unsuccessful, which could be due to my lack of experience in networking and BOOTP (the DHCP precursor that the network transceiver runs on). I think the more likely case is that the card already has a static IP address which I will never be able
to guess. Unfortunately, Moore's law hadn't yet progressed to fit all the components on one board when this model came out, so all of the IO was on a transition board which we don't have. The secondary market for these things is pretty active so we might
just buy it, but we might just buy a newer board instead. I'm leaning toward the latter option but it's up to my boss. Also, the compatibility with VME Cern is an issue (I made a new post about that). Thanks again for responding. I have been reporting
the spam when I have time to clean up the group.

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

On Monday, October 12, 2015 at 11:43:34 PM UTC-5, SpaceSpaz wrote:

I'm working on resuscitating a system that includes an SBC first used in 1995. The model number is MVME 167, and the add-on eeprom slots hold 2 vxworks v 1.0 chips, but I've yet to be able to login as I'm still trying to navigate the requirements of

VXworks compatibility. Originally this system was managed by an old Sun workstation, and I suspect it was not upgraded due to compatibility issues. All of the components are in good working order, I think, and have been previously configured to run the
current application, so my first step is just to communicate with the SBC. If I don't intend to build any applications on this card myself, just operate it as it is currently programmed, all I need is Telnet, is that correct?

Don't know if you made progress with this - but there is a module - "transition module" - that plugs into the backside of the VME behind the 167. The module provides hookups for RS232, SCSI, ethernet, and other stuff. check google images or ebay for "
mvme167 transition module". Connect to the RS232 with 9600bd / 8bit / no parity / xon-xoff (software flow).

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