pali | # 31 | 2011-05-30, 11:10 | Report

Instead key_pressed, you can use program evkey (it is in bootmenu package). But also can tell you what key was pressed

evkey is opensource (part of bootmenu project), source here:
https://garage.maemo.org/plugins/scm...nu&view=markup

command read in shell read input from /dev/tty but evkey read it directly without terminal from /dev/input/event*

====

In future I will push kbd (from ubuntu/debian) and this my recovery-boot to extras repository. So it will be possible to install it in HAM

If somebody confirm that my recovery-boot has no problems, I can push it...

sourcedriver | # 32 | 2011-05-30, 14:34 | Report

Thanks everyone for all the replies. I actually compiled kbd myself as well. Getting the SDK setup was a long process but something I probably needed to do anyway.

Mentalist Traceur | # 33 | 2011-05-30, 16:49 | Report

Hmmm... I'm unsure if that's better or worse for my purposes. On the one hand, it means my implementation doesn't depend on busybox-power, on the other, I'm lazy, and if I were to package my version of console-at-boot, it'd be easier for me to put busybox-power as a dependency than to figure out how to make the autobuilder build all the sources right...

I'll look into it eventually.

Hmm... up to you if you want to package it. I'd be happy to though, if you don't feel like maintaining it. I know I promised myself the moment I started uploading stuff to the repository, that I would maintain what I upload as long as I think there's any users who can benefit from it. (Also, since the binaries are small I was going to suggest not optifying kbd; though I suppose power users who might need loadkeys/dumpkeys from the recovery consoles can figure out how to mount the /home and /opt partitions.)

As for your recovery-boot, since I don't use bootmenu, I can't tell you for sure if it works; BUT my experiences with my versions added as /bootmenu.sh and to /sbin/preinit worked fine and that was me going off your code, so I think it should be safe. One thing I request is that your package clearly indicates it's a bootmenu entry, as I will eventually package my /sbin/preinit added version too. Don't want users getting confused between the two. I'm guessing "recovery-boot" is what you'll use as the literal package name?

pali | # 34 | 2011-05-30, 16:59 | Report

I uploaded deb package, see first post.

Mentalist Traceur | # 35 | 2011-07-02, 06:08 | Report

Rejoice! I have a new version of my /sbin/preinit console-at-boot modification - now with:

1. Less need to dig up the 'watchdogs' binary if you have busybox-power (because busybox-power comes with "watchdog", which lets you achieve the same effect, and, if I ever package this, it saves me even MORE effort - since I won't have to compile watchdogs sources [which I would have to do for those not running bootmenu, or depend on bootmenu]). (Credit goes to iDont - the maintainer of busybox-power - for pointing this out to me.)

2. Illuminated keyboard - WOOO! I've been wanting to make this happen ever since I had to use my console-at-boot in the middle of the night with no light - I can touch thumb-type on the N900 but not perfectly, so I've wanted to figure out how to make the keyboard leds light up ever since. I'm sure at least some of you using my boot-shell implementation will now be happier. (Credit goes to RobbieThe1st for telling me how to do it. The values he told me to change I never would've tested in the middle of the boot-shell because they don't work during normal N900 operation - turns out at the low level we're at when /sbin/preinit executes though, they do control the keyboard LEDs.)

/sbin/preinit - if you **** up in some crucial parts, the N900 WILL need a reflash, and it will not get far enough in the boot process to run bootmenu/backupmenu/whatever (be especially careful with the for loops and the insmod commands. When I had typos in my insmod commands in /sbin/preinit, the kernel would boot once, and then panic at boot from then on - something about "inconsistent" and "tried to kill init").


- How to (some of this is just copy-past from the last how to, but if you don't know how to do it by heart, I recommend rereading it just in case) -

Install busybox-power, OR get yourself a better "read" binary than what stock busybox provides (needs to support both the -n flag and the -t flag). If you don't install busybox-power, you will ALSO need to compile loadkmap that pali provided - or find another loadkmap binary somewhere, AND as of this version, you will also have to get the watchdogs binary from the bootmenu package, and change/remove the relevant lines to make the watchdog part use watchdogs as in my previous version.

Get pali's nokia-n900.kmap (I've make my own that supports a couple more characters, like [, ], {, and } - post here if you want it) from the package page he links to earlier in this thread. Put it in /etc/

To make pali's kmap from what's up on the server, you need to have a loadkeys command on your Linux machine with the -b flag working. You can download and compile the entire kbd package, which contains loadkeys, from here:
http://www.kernel.org/pub/linux/utils/kbd/
or here:
http://kbd.sourcearchive.com/
Or use the one pre-made by Tigerite earlier in this thread.)

Add the following lines after line 28 of /sbin/preinit
Those running R&D Mode with the watchdogs disabled may safely ignore the chunk from the beginning of the line with the third insmod and up to (and including) the first "done". (It doesn't break anything if you have both that code and the watchdogs disabled, though.)

I still plan on eventually recoding /sbin/preinit all the way, so that we can just ditch all the legalisms of me getting to only show people the changes, and just have a freely distributable /sbin/preinit.

Finally, be very attentive when entering this code into /sbin/preinit. (See my last how-to for what can happen if you screw up certain things that in normal shell scripts would just be inconveniences.) Honestly, it's probably not THAT horribly risky, because I WAS able to reflash and that should work for everyone else too - but it was a close call and I want to give everyone due warning.

Legalities and thanks for the above lines of code: These lines are part code from bootmenu, part code from pali (both of which are GPL'ed AFAIK, correct me if I'm wrong), part code from RobbieThe1st and part code from iDont - many thanks to their respective writers, without whom I'd have no clue what the frak I was doing. What isn't from them is from me - previous post's legalities apply - GPLv3 unless someone feels like telling me why they think I should do something else.

- Edit -

The led_class.ko driver is probably unnecessary. I think it controls some other LEDs. I just put it in there when first figuring out how all this worked.

The -t flag on "watchdog" can probably be longer. As I understand it it's in seconds, and the watchdogs take 32 seconds to reboot. I am personally still testing this, but I'm pretty sure it'd be safe to push the -t value to 30. That said, I'm a bit concerned that if you're doing something heavy on cpu and ram from the boot-shell, you might cause the watchdog task to get held back long enough to not execute and the watchdogs will reboot the device - which, if you're doing something CPU/RAM-intensive from the boot-shell, then it's probably some important recovery operation and it is probably the worst time for the device to spontaneously shut-down.

- Edit 2 -

Also, the brightness value goes to 128 IF I remember correctly. Maybe more. I did 25 because the point is to be able to see the keyboard in a really dark environment - you don't want the device eating too much extra power on keyboard leds, and this provides plenty of light to make out the keys. If you feel you want the keyboard brighter for your boot-shell, you can always change the value to something higher.

---

Last edited by Mentalist Traceur; 2011-07-02 at 06:22. Reason: Some quick notes

RobbieThe1st | # 36 | 2011-07-03, 06:58 | Report

Ok, guys, I'm trying to add this to Backupmenu.
I've managed to get fbcon to load(requires bitblit, font and softcursor), but despite it loading and seemingly giving me a console(I see the boot log in the background, like having a framebuffer kernel), I cannot get an interactive shell.
running 'sh' just ends immediately.
Note that I haven't grabbed 'loadkmap' yet, but I'd expect to *see* a console, even if I can't type much if at all.
Or am I wrong there?

My codeis as follows:
and I get "line: 0", then my pressAnyKey code. The shell doesn't seem to do anything... what am I doing wrong?

Mentalist Traceur | # 37 | 2011-07-04, 00:21 | Report

In my experience "modprobe fbcon" will auto-load the necessary requisite modules. Maybe it's different inside bootmenu (since you mentioned it's chrooted when in bootmenu).

Loadkmap isn't necessary for a shell. If you run it without loadkmap you'll just end up unable to enter the blue/fn-arrow keys. The normal letters and their shifted versions should still work, so you should still be able to type "exit" to end the shell and use ctrl+i for tab-completion.

What's the whole "$T2S -s ..." line after it do?

Since you have "press any key" after busybox sh, can you tell me what exactly you're doing? Are you trying to run the press any key prompt inside the busybox shell? Because that might cause "sh" to terminate upon executing the command specified?

RobbieThe1st | # 38 | 2011-07-04, 00:46 | Report

$T2S is just a replacement for "text2screen", a small binary that does exactly what it says on the tin.
What *should* happen is that upon running "busybox sh", I'd get a terminal. Once "exit" is typed, and the program ends, that line would report the return code.

What *does* happen is that the shell ends instantly, and I get a return code of 0.

As far as modules go, I might be able to use modprobe... but I'd need to know each module needed so I can copy them into my chroot, else I can't access them.

Based on what you said, I suspect I'm missing some module - Could someone run "modprobe -l" right before "sh" in the recovery console script; give me a list of all loaded modules.

Mentalist Traceur | # 39 | 2011-07-04, 01:52 | Report

No, I don't think that's it.

One, I think that's all the required modules.
Two, the insmod commands should work just fine if the above is true.
Three, all fbcon does is provide the framebuffer console. The shell isn't dependent on it... For example, if you put a "sh" command in a line in /sbin/preinit (like I did in my above code), but don't load fbcon, you'll still get the shell. (Boot will just seem to 'pause', until you type "exit", indicating the shell is there, just invisible.)

hawaii | # 40 | 2011-07-04, 02:42 | Report

FWIW, something here is broken. My device boots, registers the LED and then simply halts and does nothing...