OFW access from linux

[Paul Fox]

deepak wrote:
 > On Sep 15 2009, at 17:31, Paul Fox was caught saying:
 > > john wrote:
 > >  > > there's no SysRq key on the XO keyboard, so you'll need to use a
 > >  > > break on the serial console to invoke it...
 > >  > 
 > >  > Please.  If you're going to put this hook in, which I think is a great
 > >  > idea, at least make it work on the standard hardware!  And when the
 > >  > operating system is not very responsive.  That's when you'll need it
 > >  > for debugging or resetting the system.  Without taking the plastic
 > >  > apart, finding a part with no known suppliers, and soldering it to
 > >  > your motherboard.
 > > 
 > > i agree.  getting the hook in place was a first step, and
 > > satisfies my immediate need for wanting to be able to look at and
 > > modify h/w registers during development -- the /proc trigger
 > > is sufficient for that.  we have a constant tension between "just
 > > make it work on the XO" and "make it so we have a prayer of
 > > merging it upstream without lots of pushback", and i confess i
 > > erred towards the latter, this time.  custom key combinations
 > > would require more extensive changes to the input drivers than i
 > > was willing to take on last night.
 > ...
 > >  > 
 > >  > There are some pretty obscure keys on the XO keyboard -- howabout
 > >  > something like holding down the leftmost and rightmost "gradually
 > >  > increasing sized dots" keys in the top row, and then pressing the
 > >  > M-for-Mitch key?
 > > 
 > > i would applaud, encourage, and otherwise buy beer for anyone that
 > > could help out in making something like this happen.  (i might get
 > > to it someday, myself, but that will no doubt be _after_ i need it.)
 > 
 > 
 > I disagree. sysrq is the standard way of trapping keyboard
 > sequences to cause special kernel actions. If you want another set

but the issue is that there's no such key on the XO keyboard:  SysRq/PrtSc
doesn't exist.

 > of key sequences to make this happen, you probably want to trap
 > it in X and have that send the proper sequnce to the /proc. I
 > guess don't see the benefit of moving from a simple two key 
 > combination to some multi-key command.

it did occur to me earlier that adding a hook such as you describe to
olpc-kbdshim (which is watching all mouse and keyboard traffic
anyway) might be useful.  if the system is hung, it won't help, but
it might in many cases.

 > 
 > In the case that the kernel is hung to the point that we can't
 > talk to it at all, if the hang is caused by an oops, we can
 > have a patch that traps calls to die() and bug() and jumps to
 > OFW. This is what KGDB does, so there is some precedent.
 > We could also have some magic in the EC to look for a sequence
 > of keys that signals a low-level handler to kick into OFW in
 > the case of major lockup (assuming there's enough space in
 > EC code space to do this...).

interesting idea:  an EC solution would be the most failsafe, but
i don't believe it currently actually looks at any of the
keystroke data as it passes through.  (except for the keys on the
screen bezel, which it has complete responsibility for.)  i think
we'd have to see a pretty strong need to go down this path, though.

 > 
 > I've not seen many total hangs that can't be fixed with some
 > printk debugging + KGDB when it works. Or a JTAG unit, but
 > I don't think we can do that on the XO, right?

right, no jtag.

but as you say, cases where the system is well and truly hung
and need sysrq aren't all that frequent.

paul

 > 
 > ~Deepak
 > 

=---------------------
 paul fox, pgf at laptop.org