Wow, this is really handy.
When on a computer and it goes to ..., i use the liveCD. But on N900, there is no such thing. This is a good replacement.
Only thing I use Multiboot at the moment...

I just finished my bootmenu-less/multiboot-less script. See my last post's edit. Keep in mind this won't work by itself from within multiboot, but if someone understands what they're doing and is familiar with multiboot (*cough*hawaii*cough*), they should be able to take the binaries from bootmenu, stick them into the right paths, and combine it with the bootmenu-independent script I finished just now, to get a multiboot compatible version.

I'm on the job, but don't know how long it'll take me to get working - luckily I've got a few N900s from Nokia to futz around with.

More newb questions from me:

Does anyone have an explanation for why any module other than fbcon is needed? I get a perceivably identical shell without loading the other three modules (bitblit, softcursor, and something else) that pali's original bootmenu .item file specified.

I also seem to do fine without evkey, not sure what that's supposed to do.

Nor, honestly, do I understand the purpose of the "sync" command, although my logical guess is it makes sure whatever changes you made are written to disk before the mini-reboot script is ran - is that correct? If so, assuming I'm skipping the mini-reboot (without the bootmenu/multiboot, typing "exit" simply resumes the boot process), does the sync command really have to be there? Because right now my code looks like this as bootmenu.sh and works just fine:

modprobe/insmod fbcon and the two watchdogs
that code from bootmenu to kick the watchdogs to avoid reboots
loadkmap (kmap)
sh
killall watchdogs

Is there anything horribly unsafe in how my code is written, vs pali's original much bigger (excluding my paste-in of watchdog sustaining code) one?

Okay, so nearly as I can tell, there is nothing necessary missing about my way as I described it in my last post.

Also, after having spent the last - ...day, or so, is probably a good estimate - on modifying /sbin/preinit and breaking something, having to reflash, and having at it again, I have figured out how to not only give a console at boot, but also how to make it somewhat casual-reboot friendly by making it give a 5 second countdown - if you press any key, it drops you into the shell, if not, it continues with boot as normal. Beautiful, no?

Now, cons of using /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").

It is also technically not a GPL'ed script, and the license OFFICIALLY says you're not allowed to distribute /sbin/preinit - which means you have to distribute either scripts that directly modify preinit or do it illegally... Or find some BS work-around like "I recoded this from scratch" - which CAN be believable, since without pre-init the N900 is still reflashable and someone COULD theoretically reverse engineer their own. But that kind of argument requires good lawyers to back it up.

That said, ****ing up is only really a matter of not following directions correctly / making typos now that I HAVE gone through a few iterations of ****ing up to get it right. So if care is taken that risk is minimal.

There are pros of if being /sbin/preinit however - one, you don't need to do the entire keyboard in/keyboard out shtick. Maybe it works for some people, it doesn't match my aesthetic. Two, it also means you have between when you turn the N900 on until it reaches 0 on the countdown to drop to a shell, instead of booting up with keyboard in out of habit or something and then going "**** I wanted to get to bootmenu" so you have to wait until the boot process ends. 'course, after the countdown you're still stuck waiting until the end, but at least now your window for 'last second realization that you want a shell' is almost 10 seconds, instead of ~1.

Three, you know that console output is sexy - you don't want your keyboard hanging out every time you boot just to see it.

Four - and this is probably the most important in my opinion - it both doesn't depend on bootmenu, AND it doesn't conflict or collide with it. Which means if you don't want bootmenu as a package - screw it, you don't need it - but if you do, you can still get your shell at the beginning of a boot, without needing to drop into bootmenu. Why is this awesome? Because it means you can, say, boot up, run the shell, and then close the keyboard right after you type exit, and you should be able to bypass bootmenu. Alternatively, you can go to bootmenu right after if you so choose. (To be fair though, I haven't tested how much leeway you have in the timings between shell access and having keyboard closed to avoid dropping into bootmenu.) The other thing is, I'm pretty sure that this would be compatible with multiboot as well as bootmenu.

- How to -

Get the "watchdogs" binary from the bootmenu package, and place it somewhere in your path (chmod +x, of course). Make sure it's on rootfs, not in /opt or /home and symlinked - /home isn't mounted that early. (Not needed if you're running R&D mode with watchdogs disabled on your device.)

Install power-kernel47 or the framebuffer-kernel (or some other kernel with framebuffer console available). I'm not sure what happens if you try to "modprobe fbcon" on a kernel that has fbcon statically compiled instead of as a module, so... yeah SHOULD be okay, but I had the aforementioned kernel panic thing happen when I did something wrong insmod'ing the watchdog modules or whatever they are. I have also not yet (though it's on my list) tested this with u-boot+kernel kernel images.

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, but I couldn't for the life of me figure out where to get one.

Get pali's nokia-n900.kmap (I might make my own later that supports a couple more characters if I can figure out how) from the package page he links to earlier in this thread. Put it in /etc/

Add the following lines after line 28 of /sbin/preinit
Take note that the white-space are spaces, not tabs... I'm not sure if this is necessary, but it's the norm used in /sbin/preinit, so I went with it. I've reflashed enough recently so I don't want to keep screwing with it too much, but I can't think of any reason why it wouldn't support tabs just because it's early in the boot process (unless it's run by nolo vs. the kernel, and nolo parses white-space in a non-standard way), so brave souls may dare to use tabs instead of spaces, and report back what happens.

Those running R&D Mode with the watchdogs disabled may safely ignore the chunk from the beginning of the line with the first insmod and up to (but not including) the loadkmap line. (It doesn't break anything if you have both that code and the watchdogs disabled, though.)

If possible, I do wish to see what I can do about providing an open-source clone of /sbin/preinit (I think multiboot had something like that in it... need to look into that more as time permits) so that Nokia's legalisms can go suck it, followed up with a packaging of this and uploading to devel... That's a bit of a ways off, though, and ideally someone still needs to see what happens if you run a fbcon-not-supporting kernel with this. Because I HAVE been able to get a shell I couldn't see when fbcon didn't load (typo'd modprobe as "modprove"), but I could still enter commands and boot didn't continue until I entered "exit". Which may mean users getting stuck not knowing what's going on if they press a button early enough in the boot. Or it may mean the kernel panic I got on consecutive reboots when I tried to insmod/modprobe modules that I made typos in. 'course, dependency on the necessary stuff would take care of normal kernel power / kernel framebuffer uninstallations, but it would not notice kernel reflashes that are done manually, underneath the dpkg/apt-get system.

Finally - DO NOT forget to include the "done" statements for their respective "for" statements. That was the closest I had ever come to not being able to reflash. It got stuck on the initial Nokia screen. Hardware power button holding for really long stretches of time didn't power the device off; pulling the battery powered it off but putting it back in immediately turned it on in the exact state it was when battery was pulled. Flasher wouldn't recognize it at first and it wouldn't go into flashing mode when plugging it in with the u key held down. The only way I got it into flashing mode was pulling the battery, holding the u key, plugging it into the usb port, and only then putting the battery back in. 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) - many thanks to their respective writers, without whom I'd have no clue what the frak I was doing and wouldn't have gotten anywhere with this. What isn't from them is from me - for legality's sake I'll just say the parts that are mine are under GPLv3 for the time being. I'm not a GPL-savvy person, so if that doesn't work somehow, let me know and I'll correct that.

@pali: how did you make your nokia-n900.kmap? I've used dumpkmap on my N900 itself (although I have really fancy custom key remappings) and it simply doesn't register the FN+key combinations, just as it fails to if you omit "loadkmap". So I'm unsure if it's my N900 xkb keymap changes that's doing this - in which case I can just revert to less fancy versions for making my key maps - or if you used some special way to make your .kmap? (Of course, I can use a hex editor on your kmap to get the desired extra keys onto mine, but that's hardly ideal.)

*Facepalm* Was about to go to bed then I realized I forgot to write in two rather important lines in the above "watchdogs" and "killall watchdogs". Without it nothing breaks horribly, but the device shuts off after about 32-or-whatever-it-was seconds. It SHOULD be completely correct now.

binary kmap file comes from meego n900 rescue initrd:
http://meego.gitorious.org/meego-dev...-rescue-initrd

Later I commit generating script and source file of kmap to my bzr branch.

This is...beautiful.

Binary kmap file was deleted. Now it is replaced by source text file + commands to generate it in Makefile.

Thank you Pali. And just seeing the source was pleasantly educational (now I know shift+space = tab key on the .kmap you included). (Now I wish that loadkeys was available on the N900 as well. I hate going all the way into a virtual linux machine just to do basic stuff for the N900 that I'm going to be using only on the N900. Looks like I need to do more digging.)