Progress with Java VM portings

[Gauthier]

Thanks for the info. Any URLs or other pointers? We do have the original
MBX boards. Almost certainly they have early revisions of the CPU. Maybe
that's our problem.

Rick McBain wrote:
> 
> Old versions of 860/821 had hardware errata with the cache.  I don't know if
> they ever built any MBX boards with that revision of chip, though.  I know
> that when evaluating VxWorks and PSOS on the Motorola evaluation boards,  we
> then had software problems with non-errata chips, because the OS guys had
> debugged workarounds on errata chips,  but hadn't debugged (un-workarounds)
> with the non-errata chips.  That is, we turned the cache on (non-errata
> chip), and the software would die, because the code still had bugs.
> 
> My $0.02
> 
> Regards,
> Rick McBain
> ----- Original Message -----
> From: Charles-Antoine Gauthier <charles.gauthier at nrc.ca>
> To: Eric Norum <eric at cls.usask.ca>
> Cc: <rtems-users at oarcorp.com>
> Sent: February 24, 2000 11:22 AM
> Subject: Re: Progress with Java VM portings
> 
> > Eric Norum wrote:
> > >
> > > > Charles-Antoine Gauthier wrote:
> > > > > My collegues just complete the port of RTEMS to the MBX821/MBX860.
> The
> > > > > last few weeks were spent trying to figure out why the MBX821 will
> not
> > > > > work at all with the data cache turned on. We suspect that the
> memory
> > > > > controller values in the documentation are wrong and that we are
> getting
> > > > > bus errors during burst writes. Also, on the MBX860, interrupts from
> the
> > > > > serial ports do not interrupt the PowerPC core when the data cache
> is
> > > > > turned on. We can see the interrupt pending in the SIPEND register,
> the
> > > > > SIMASK register is set to pass them on, and the interrupts are
> enabled
> > > > > in the core, but no cookie :-( We submitted the code yesterday to
> OAR. I
> > > > > am sure that we missed the cutoff date for inclusion in RTEMS 4.5,
> but
> > > > > that was unavoidable.
> > > > >
> > >
> > > Could this be related to the problems I've seen with the 68360?  The
> > > event bit is set, the mask bit is set, interrupts are enabled, but the
> > > bit in the `in-service' register (CISR) is also set so no interrupt
> > > occurs.  I was able to work around the problem by running the
> > > programmable interrupt timer at the same CPU32 priority as the CPM.  If
> > > the PIT is at a higher priority than the CPM, the CPM interrupt would
> > > get locked once every 30,000 to 40,000 times.
> > > The 860 has only one interrupt level though (recalled from my dim
> > > memory...), right?  So perhaps interrupt priority problems could not be
> > > the problem here.
> >
> > I don't know. We are aware of the problems with the 68360. We are
> > planning some further experiments in the near future to try to narrow it
> > down.
> >
> > >
> > > > > For the first time yesterday, we had the Lego RCX driving around
> under
> > > > > control from a Java program running in the MBX821 and MBX860. C++
> and
> > > > > Java exceptions are working. Previously, we only could use the
> MVME167
> > > > > to control the robot.
> > >
> > > Does that mean you have a network driver working for the MVME167???? :-)
> >
> > You wish :-). The student is here, but he was employed on higher
> > priority tasks, and continues to be. At this time, I don't know when he
> > might get back to the network driver. Sorry. So much code to write and
> > debug, so little time... FYI, the RCX is driven from the serial port at
> > 2400bsp, 8 data bits, odd parity, 1 stop bit, through an infrared
> > transceiver. No networking required. It does mean that the MBX8xx and
> > MVME167 serial drivers can run at other settings than 9600 8N1 (for the
> > MBX8xx, that will be true when we submit a patch to the patch we
> > submitted yesterday, which should be Real Soon Now).
> >
> > >
> > > --
> > > Eric Norum                                 eric at cls.usask.ca
> > > Canadian Light Source                      Phone: (306) 966-6308
> > > University of Saskatchewan                 FAX:   (306) 966-6058
> > > Saskatoon, Canada.
> >
> > --
> > Charles-Antoine Gauthier
> > Research Officer
> > Software Engineering Group
> > Institute for Information Technology
> > National Research Council of Canada
> > Ottawa, ON, Canada
> > K1A 0R6

-- 
Charles-Antoine Gauthier
Institute for Information Technology  Institut de technologie de l'information
National Research Council of Canada   Conseil national de recherches du Canada