From: pat@wrs.com (Patrick Boylan)
Subject: Re: 167BUG Diagnostics and VxWorks
Keywords: 167BUG, VxWorks, Diagnostics
Reply-To: pat@wrs.com
Organization: Wind River Systems, Alameda CA
Distribution: wrs
Date: Tue, 29 Sep 1992 23:48:24 GMT

In article <1992Sep11.085304.19546@icf.hrb.com>, r2c@icf.hrb.com (Robert J. Cole) writes:
|> 
|> 	I am attempting to write c diagnostic routines for the Motorola
|> 167 board to run in vxWorks.  The Motorola 167BUG firmware exists on the
|> board and on power-up, boots and passes control to vxWorks.  167BUG
|> exists in the first two PROMS and VxWorks in the second set.  VxWorks
|> boot ok in this configuration.  The intention is to run the user diagnostic 
|> routines on the 167 board which will make use of the resident Motorola 
|> diagnostic routines already in ROM, however this effort seems to be rife
|> with difficulty.	
|> 	
|> 	Has anyone done anything similar to what I am attempting and is
|> able to offer any advice?
|>  
|> Rob Cole.  r2c@icf.hrb.com

Rob,

I've done something similar for the Motorola MVME-147 and MVME-133.

The procedure involves booting MBUG, then upon successful MBUG boot,
MBUG searches for a boot block.  This boot block is used to jump start 
vxWorks.  Diagnostic results from MBUG were no more than pass/fail (if it 
failed it would not make it to vxWorks).  The results are printed out onto 
the console which was good enough for us.
Unfortunatley it was difficult to extract the individual diagnostics 
procedures from MBUG.  As far as I remember there was no jump table, nor was 
it well enough modularized to allow for this much execution granularity, 
even with the source code.

This is the procedure for using MBUG power up test procedures and
then vectoring to VxWorks.  These steps are specifically for the MVME147 and 
MVME133.  The MVME-167 might be different, however.

Install MBUG PROMS in bank0.

Reconfigure jumpers for the larger size EPROMS (see documentation for 
the target).

Build VxWorks with a ROM start address equal to the bank1 base address instead 
of bank0.  This is changed in the VxWorks file "vw/<target>/config.h".
Optionally poke the BOOT block (shown below) into these ROMs also 
using the editor of the PROM programmer.  I put it at address 0xffa1f800 on 
the MVME133XT.  Incidentally, another option is to put the bootblock direclty 
into non-volatile RAM.

Install the newly built VxWorks PROMS in bank1.

In order to cause MBUG to autovector to vxWorks.
MBUG completes self test, then checks the romboot flag (set from the MBUG
debugger), then if an address is specified when the romboot is turned
on, then this address is searched first for the boot block, if the bootblock 
is not found at this address, memory is searched for a bootblock in
NVRAM, RAM, or ROM .  Note that the boot blovk has to be on an 8KByte 
(0x2000) boundary).

The boot block can be inserted into non-volatile RAM.
This makes it easier for testing, and is easier and quicker to set up.
The MV133XT nonvolatile RAM is in the RTC which is located at 0xfffc0000
There are 2040 bytes available but the first 256 are used for the VxWorks boot
line.  Try putting the boot block at 0xfffc0300.  Take a look at the memory to 
make sure it is not being used by MBUG.

The MVME147 battery backed RAM should be at 0xfffe0000.

Using MBUG search through this novram for a block that is not being used.

Modify memory to insert the following data into the NV RAM:

Boot block data for the MVME133XT follows:
xxxx000:  424f 4f54 0000 0018  0000 0016 7678 576f   *BOOT........vxWo*
xxxx010:  726b 7320 d2b6 0000  4e56 0000 dffc 0000   *rks ....NV......*
xxxx020:  0000 48d7 0000 4ef9  fff2 0008 7000 4e5e   *..H...N.....p.N^*
xxxx030:  4e75 ffff 

Boot block data for the MVME147 follows:
xxxx000:  424f 4f54 0000 0018  0000 0016 7678 576f   *BOOT........vxWo*
xxxx010:  726b 7320 d2b6 0000  4e56 0000 dffc 0000   *rks ....NV......*
xxxx020:  0000 48d7 0000 4ef9  ffa0 0008 7000 4e5e   *..H...N.....p.N^*
xxxx030:  4e75 ffff 

The boot block for other processors is the same except the appropriate bank 1
execution address should be inserted into offset 28.  In the first case it 
is 0xfff20008 which is the MVME133XT ROM bank1 base address + 8.

The MVME147 bank1 execution address is 0xffa00008.
Then insert the checksum.  This is the last word of the boot block 
(at offset 32).  This is sum from the first word of the bootblock 
(offset 0) to the last word of the bootblock (0x30), but inverted so that 
the total checksum including this word should add up to zero.

Note: I can't remember whether it is 16 bit or 8 bit checksum.  Look at MBUG documentation or try it.

Configure romboot parameters in MBUG, using the rb command.

Turn on RB, assign the address where the boot block is located (saves time)
and rom boot on power up only (this allows you to use the RESET switch to
get back to MBUG).

Cycle power to test rom boot procedure.

If it takes a while and sits at a message saying searching for boot block,
then either the boot block has not been found, the address is wrong, or
the checksum does not match.  If the address is wrong and the boot block is 
located at an 8KByte (0x2000) boundary then it should be found eventually.  
It just may take a while.

When it is found note the address that it was found at and specify this 
address as the search start address to save some time.

Hope that helps.

Regards,
Patrick
-- 
 Patrick Boylan, Consulting Engineer, FAE Asia/Pacific
 Wind River Systems
 1010 Atlantic Ave. Alameda, CA  94501
 email: pat@wrs.com   tel: (510)748-4100   fax: (510)814-2010