Touchpad testing.

[Tom Sylla]

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.
>>
> 
>