MVME162 BSP Issues

[Joel Sherrill]

On 11/02/2011 09:21 AM, Hoover, Victor P CTR NAVAIR, AIR 4.1.3.3 wrote:
> On the web page for this BSP the "Test Reports" section has the following comment:
>
>    CVS head -- March 24, 2011: User:Richard Campbell:
>    Ticker ran successfully; File I/O printed to console but did not accept input.
>
That would be the board in the RTEMS lab which only gets spotty
checking.  We also had issues with where the console was directed
at first.  I recall it wasn't the same as where 162Bug went.
> This still seems to be the case with RTEMS version 4.10.1 (in addition the loopback program in the testsuites/samples directory locks up with a yellow STAT light - the processor halts).
>
The NIC is not yet supported.

Besides this is a loopback test with only the local interface.
If it locks up, then there is a reason.  I have no idea what though.
> 1) Has anyone gotten the console to work properly for this board?
>
> 2) Is anyone actively using this BSP?
>
>
Those are both questions for the community.  We did not
have this board for the lab until not long before we tested
it.  If the console input ever worked, I don't know.

Check c/src/lib/libbsp/m68k/mvme162/console/console.c

FWIW this looks like a pre-termios driver so it is possible that
the input doesn't interface correctly.  Check that inbyte works
and then refactor the driver to follow the "simple polled
single port" template.  powerpc/psim has a nice example of
this.  Basically inbyte/outbyte become support routines
for a framework.

This is a very old BSP.  It was the first BSP ever submitted.
Any updates will be appreciated.  I will review and merge
them.
> Note that the ticker and base_sp programs from testsuites/samples both run.  Originally they also triggered the yellow SCON light upon completion and do not return to the 162Bug program.  This is the result of bugs in the bsp_return_to_monitor_trap() function in the bspclean.c module.
>
> There's an #ifdef for mvme162lx that conditionally sets the 162Bug vector address.  By default, 162Bug uses DRAM to run in and the address should always be 0x0 (not 0xFFE00000, this is the SRAM address).  The rest of the function is commented out with an #if 0 block that says it does not work on the 162 board.  If the vector address is correctly restored the code does work (at least it does on an MVME162-413 board).
>
Submit a patch.  If you can tidy up the lose ends on this BSP.

It is likely a case of mild bitrot over the years. :(
> 	Vic Hoover
>
>
>


-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985