Version 1 (modified by Strauman, on Feb 5, 2009 at 4:22:59 AM) (diff)

New page: == Hardware and Software Info == OK, so I pulled out an old mvme167 board and an mvme712 transition module. The 167 has 167Bug firmware in its PROMs. == Patches == While trying out rte...


Hardware and Software Info

OK, so I pulled out an old mvme167 board and an mvme712 transition module. The 167 has 167Bug firmware in its PROMs.


While trying out rtems-4.9.1 (gcc-4.3.2) I encountered some problems that prevented me from using this BSP out of the box. For most of these I submitted PRs to the database. Download the associated patches and apply.

# The FPSP floating-point emulator uses some pretty bad (i.e., short and commonly-used) symbols which lead to linker errors (name clashes). PR#1369 addresses this Note that this patch touches a and file so you have to have the autotools available and you must run 'bootstrap' after applying the patches. # The console driver uses some inline assembly which causes problems for the gcc-4.3.2 optimizer; PR#1370 addresses this. The problem is also explained on the mailing list # The custom/mvme167.cfg snipped fails to convert the final ELF executable into a downloadable binary (167Bug requires a pure binary). PR#1371 provides a fix. You can also use the 'm68k-rtems-objcopy -Obinary' command to do the conversion manually. # Finally, there are quite a few bugs in the networking driver. I didn't have the time to do proper analysis, fixing and testing so take PR#1372 with a grain of salt - it may require more work.

RTEMS/BSP Configuration

In order to get the console to do what I want (the mvme712 transition board has one of the serial ports (port 0) labeled 'Console' and that's where 167Bug interacts with me and that's what I want RTEMS to use for the console. Unfortunately, by default RTEMS will use port 1 and not port 0 so you may not see anything on your terminal unless you either use a second terminal or provide different configuration settings. The console port and mode (IRQ-driven vs. polling, termios vs. non-termios) are configured at the time you say 'configure' but you pass the desired values on the commandline to configure. I use

configure CD2401_IO_MODE=1 CD2401_USE_TERMIOS=1 CONSOLE_MINOR=0 PRINTK_MINOR=0 <other configure options>

which chooses IRQ-driven mode (0 == polled), termios mode (0 == non-termios), and selects serial port 0 for console and printk output (use the desired serial port # here -- remember that this defaults to 1 if not set)

Firmware Setup

The mvme167 BSP by default (i.e., unless you tamper with the linkcmds) is linked at 0x0800000 and the firmware has to be properly configured so that loading and executing at that address is possible: # The board's RAM must be mapped starting at address 0x08000000 (and not zero as may seem more natural and which IIRC is 167Bug's default). ## Use 167Bug's 'env' command to set the 'Base Address of Local Memory' to 08000000. ## Use 167Bug's 'niot' command to set the download and execution address to 08000000. # By default, the 167Bug firmware uses the lowest 64k block of RAM it finds for internal data and this conflicts with RTEMS' needs. 167Bug won't allow you to download the RTEMS image to 0x08000000 unless you instruct 167Bug to use another area (e.g., static RAM) for it's internal data. ## Use 167Bug's 'env' command to set both, the 'Memory Search Starting Address' and 'Memory Search Ending Address' to zero. The 'search' area is the address-range that is scanned by 167Bug when it tries to find an area for it's internal data. If it finds no RAM (since start==end) then it uses static RAM and 08000000 and up can be used by RTEMS.


I use 'niot' to tell the box it should use BOOTP and set the download and entry point addresses as described above and then say 'nbo'.