OFW access from linux

[Deepak Saxena]

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

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

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?

~Deepak