[Openec] debugging data

Frieder Ferlemann frieder.ferlemann at web.de
Wed Aug 1 18:39:19 EDT 2007


Hi Joel,

Joel Stanley schrieb:
> > On 7/30/07, Frieder Ferlemann <frieder.ferlemann at web.de> wrote:
>> >> I plan to use the topmost 64 byte of RAM to hold debugging
>> >> info (currently the complete state of all statemachines).
>> >> If the BIOS could show (on a press of an USB keyboard)
>> >> a short version and a long version of the data there
>> >> that would be great.
> >
> > Freider suggested to me I write some Forth that would read the top 64
> > bytes of EC RAM and display this debugging data.
> >
> > I think we can use the Forth word that Mitch gave me for the ec-dump script.
> >
> > : ec-range  ( adr len -- )
> >    over 4 u.r ."  :    "    bounds do i ec@ 3 u.r loop  cr
> > ;
> >
> > then to use:
> >
> > ok 00 4 ec-range
> >   0:     2 ca ef 2
> >
> > ok 12 2 ec-range
> >  12:   22 2
> >
> > Freider; does the code already store the debugging info? If so,  point
> > me to the files and I'll work at making it display the data in a
> > slightly more human readable format.

Well the code does so partly. I'd plan to use the topmost 64 byte of RAM to
hold debugging info (currently the complete state of all statemachines).
If the BIOS could allow to automatically show a short version
and a long version of that data that would be great.

If struct states_type in states.h could be fed into forth
and forth would translate:
http://dev.laptop.org/git.do?p=projects/openec;a=blob;f=states.h;h=ee9cef7d74d2c2a9ca88ba8fa536492eb25a3376;hb=ca489a5f5a5ce8aee39b184f94c270d69de70787
line 39:


typedef struct states_type {
     unsigned int timestamp;
     unsigned int last_timestamp;
     unsigned int number;
     unsigned char battery;
     unsigned char keyboard;
     unsigned char touchpad;
     unsigned char watchdog;
     unsigned int watchdog_pc;
};




into something that looks like:

time last numb ba ke to wa watc  cb cc cd ce cf d0 d1    (... up to 0xfbff)
0020 001c 0123 01 00 00 80 0000  .. .. .. .. .. .. ..
0035 0033 0211 02 02 01 a0 0000  .. .. .. .. .. .. ..
003f 003e 0244 03 03 00 f0 0000  .. .. .. .. .. .. ..
004f 0048 0344 03 00 01 f0 0000  .. .. .. .. .. .. ..


and emit that on a keypress from an USB keyboard attached
to the OLPC this would give us a very good idea of
whats going on on the EC.



And a long version would be fine as well:)

Hosttime 2007-08-01 07:35:54.xxxxxx
EC Firmware 0.0.1p0 57ad8427 Jul 31 2007 01:35:49
timestamp       004f
last_timestamp  0048
number          0344
battery           03
keyboard          00
touchpad          01
watchdog          f0
watchdog_pc     0000



The short version allows to track the state of the EC state machines
at each iteration of the main loop. And to nail down how the
state-machines proceed/react on keyboard/host_interface/whatever
input.
The last bytes of RAM up to 0xfbff would simply be dumped so
if someone is interested in a special state/variables
he/she simply puts it up there...

We'd know the kb3700 time, the exact iteration of the main loop
together with the some arbitrary debugging data... not too bad:)


The long version would allow to identify the software version
and give even better readable human readable output:)

PLUS:

if the forth routine is set to dump 0xfb80..0xfbdf instead
of 0xfbc0..0xfbff it tells the state before (!) the last reset.
http://dev.laptop.org/git.do?p=projects/openec;a=blob;f=states.c;h=389c0feb379b472c1173a06167d15a43a5b2e9d5;hb=ca489a5f5a5ce8aee39b184f94c270d69de70787
(... post mortem ... ... provided the power was not lost ...)

This most likely is better than what a considerable fraction
of proprietary embedded code is able to offer :*)
(flush)

Greetings,

Frieder




More information about the Openec mailing list