2008/10/1 Werner Almesberger <[EMAIL PROTECTED]>: > andrzej zaborowski wrote: >> First was when I was booting off the sd for the first time and the sd >> had errors so the kernel loaded from nand okay and then init loaded >> but then subsequent programs or scripts loaded corrupt and something >> locked up, so I used the power button. > > Hmm, and then you booted from NAND and went on to repair the uSD card > using the system booted from NAND ? Thanks, that's indeed a case where > there's a visible difference, because we wouldn't even reach the point > where neodog is running, yet the kernel isn't completely dead yet. > >> Second time was when I was hacking the timers yesterday and apparently >> I broke gettimeofday and one of the first processes hung waiting for >> something, I used the power button (for kicks) and it worked. (99% of >> the times I was just taking the battery out and wouldn't mind doing it >> that time also) > > You're very brave to do this kind of low-level hacking without a debug > board ;-) > > By the way, my solution for quickly resetting the Neo without too much > physical effort is to just toggle the debug board reset: > > http://svn.openmoko.org/developers/werner/dbgrst/ > > I almost always keep the debug board attached, since I don't want to > miss any clues printed on the serial console, and I also like to copy > and paste printks for later reference (which I couldn't do if I only > had them on the screen).
Yeah, that's a good thing. I did get the debug board but I don't use it unless there's something interesting happening before glamo initialises because flashing kernels through u-boot seems quicker and for that I have to disconnect the debug board everytime. > >> Something to consider is that Linux has something called SysRq key for >> like 15 years and it's a similar concept. It's something that works >> at all times even after the kernel panicked and nobody doubts its >> usefulness. > > Yes, SysRq is pretty close to this. Even there, the low-level driver > only provides the SysRq keycode, but it's higher-level code that > decides what to do with it. But I take your point that this is still > in the kernel, not in user space. > > How about the following compromise: we leave the power-down code in > the kernel, but move it from the interrupt handler to a separate > function (perhaps in a separate file as well) that just gets called > on ONKEY/SECOND events and that's responsible for handling > onkey_seconds and perhaps also PCF50633_F_PWR_PRESSED. Yes, sounds good, and also I'm not suggesting that it be forced upstream. I was just thinking if the SysRq mechanism couldn't be reused by registering a tty etc, but it doesn't seem it could easily. Cheers
