Booting RTEMS/GeSys on a Motorola MVME167 (m68040) Board

There are still many of these boards around. A perfect and cost-effective platform for running not too demanding applications. RTEMS/GeSys gives you a comfortable platform without licensing hassles and no threat of support being dropped - you always have access to the source code.

Remarks About Memory

Note that RTEMS/GeSys was configured for modern boards with much more memory than the old MVME167. Some simple cutbacks have been made (fewer networking mbuf buffers, less RTEMS workspace) but the memory footprint is certainly not optimal. Even for running the simple EPICS example application, 8MB of memory are a 'must'. Plain RTEMS/GeSys can live with 4MB, however. For use beyond this demo, the system should be properly configured, i.e., more optional software/libraries should be excluded when building RTEMS/GeSys.

AFAIK, the BSP does not probe the amount of RAM present. Therefore, RTEMS/GeSys was compiled for the minimum which are 4MB of RAM. However, the BSP was patched to provide a means for specifying the correct amount of RAM at run-time, simply by setting a variable, 'BSP_RamBeyond4M', e.g., at the Cexp> prompt or from a script. This should be performed prior to loading applications or doing other memory-demanding tasks. E.g., if your board has 8MB or RAM, issue (since there are 4MB in addition to the configured 4M):

Cexp> BSP_RamBeyond4M = 0x400000
0x00400000 (4194304)

After this, the full amount is available (although no contiguous chunk > ~4MB can be allocated).

One more thing to keep in mind: The run-time loader temporarily copies files to RAM when loading an object from the TFTP filesystem (due to limitations of this filesystem). This can easily exhaust the memory on a MVME167. Hence, it is preferrable to load objects from NFS where no such temporary copy is necessary.

Jumper Settings

For reasons mentioned below (vxWorks Bootrom support), the BSP's feature to retrieve several configuration parameters from NVRAM has been removed since the vxWorks bootrom uses the same NVRAM region. Hence, it is mandatory to remove jumper J1-4 indicating that the NVRAM shall not be queried. Jumpers J1-5..J1-7 should probably be inserted in order to take advantage of the cache. Serial port #0 is used for console and printk I/O. README for further information about board configuration and other issues specific to the mvme167 RTEMS BSP.

Booting with the 167-Bug Firmware

On the MVME167, RTEMS/GeSys can be booted using the Motorola 167-Bug firmware. First, you need to configure the firmware settings using the 'env' and 'NIOT' commands. The settings you want to look for are:

BOOTP/RARP Request Control: Always/When-Needed (A/W)=A? A

My complete settings can be found here.

Once the correct settings have been entered, simply type the 'NBO' command to initiate the boot process. There are several 'env' options for autostarting the board. Consult the 167-Bug documentation (and part 2).

167-Bug> NBO

Booting with a vxWorks Bootrom

On many MVME167s, the original firmware PROM has been replaced by a vxWorks bootrom which is a far less powerful firmware than 167-Bug (I never understood why vxWorks is not booted by 167-Bug). Nowadays it can be difficult to find the original PROMs, a file with their contents or even some pristine chips to burn.

Therefore, attempting to support booting via a vxWorks bootrom, I removed some pieces of code from the BSP. Code that relies on 167-Bug firmware services (in particular, no polled console IO is available - the BSP is less verbose during early stages of the boot process) or NVRAM settings and configured the BSP for interrupt driven I/O, exclusively.

Applying several modifications (contained in the patches), I was able to successfully boot RTEMS/GeSys from a vxWorks bootrom. However, since the bootrom internals are poorly or not at all documented, YMMV. Here are some things I discovered:

The patched RTEMS Makefiles already 'know' how to and actually do generate an a.out format file that is loadable by a vxBootrom as well as by 167-Bug. It could be that your vxBootrom version requires a different 'start address' or does not work at all (as I said: YMMV), however.