Mitch Bradley wrote:
Will do. I'm currently writing a PRS parser that will run in my diag
environment, so I can do PRS verification without having to install
giant wads o' TCL.
Ah, people aren't understanding the PRS parser. You run it in FS2. You
don't need wads of TCL, it comes with your FS2 installation.
In FS2:
source PRSCheck.tcl
and have the prs file in the same dir, and it will run. It reads the
MSRs, I/Os, etc through JTAG, and checks them. The PRS is always going
to be very dependent on where the thing is run, so porting it to a
different environment is usually a bad idea. Part of the OLPC PRS
process has to include at what point in the boot to run the PRS.
Will a complete PRS scan cover the SERIRQ settings?
The utility of the PRS is only as good as the quality of the input file.
The LPC section is probably very much wrong, since the specs were not
available, and even now that they are, there will probably still need to
be some reverse engineering of the way the IRQs work.
Tom Sylla wrote:
look at SERIRQ. It will probably be in continuous mode, where it
shouldn't be or the polarity settings will be wrong. None of the EC
init is being done, there is no "super I/O" configured into LB. The
5536 config is a best guess back when the EC spec was not available,
so that is probably wrong too. If you look at the PS/2 and SERIRQ at
the same time, the answer will just fall out.
Mitch Bradley wrote:
These pictures show what happens on the OLPC board when you
a) Don't drain the queue (QueueHoldoff.png)
b) Drain the queue every so often (RateControl.png)
Conclusion: the EC is able to handle normal-rate mouse reports when the
software services it at the correct rate.
_______________________________________________
Devel mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/devel
