maybe You're not going to do it, but others may. Reinob is right - backupmenu, in it's all greatness (life0saver many times) is a mess, when it comes to actual code, and providing updated/enhanced functionality is PITA. Maybe that's why RobbieThe1st quite lost interest in developing it further, at least for now.

In backupmenu code, we got nice ready-to-use methods of achieving functionalities, but I agree that "interface" should be rewritten, without text2screen.

I don't blame Robbie - probably, he was "forced" to use t2s, when no real fbcon was available. but now, it's time to move to more sane approach.

---

By the way, I'm hapilly using *every* function of backupmenu with fbcon enabled, and console/backupmenu tearing isn't that bad. Most of the times, when something change in backupmenu, it goes to the "surface" of screen ( ) giving enough time to make selection. I've used - without problem - backuping, restoring, read/write USB, USB networking, enabling SSHD...

So, until it becomes re-written, we can easily use current backupmenu, without much hassle.

/Estel

He lost interest because he was one of the 144,000 who were ascended to n950'dom.

Also true + He got accident with his hard disk while upgrading debian. Well, bad luck comes in pairs - first N950, then disk...

Honestly though, it's quite off-topic here. Everyone, who is going to re-write backupmenu for recovery console approach (and to document work on it/code, unlike Robbie - no offense...) is going to have my never-dying blessing and some "beer" donations.

/Estel

bootmenu (I mean fanoush bootmenu) using text2screen for rendering chars directly to framebuffer device - not to framebuffer console. Also you can specify size of font....

So bootmenu should work without fbcon too, so it is not good idea to use fbcon for bootmenu.

I adding more usefull functions for bootmenu into preinit. Then I clean also bootmenu...

I've started taking some notes about Backupmenu with the plan of making a cleaner version.

Don't get your hopes too high though. For now I'm just documenting..

sorry if going off-topic

I have modified Backup-menu in the past to start from u-boot using a 2.6.37 kernel.

http://talk.maemo.org/showpost.php?p...&postcount=915

the interface is just text written to frame buffer console..

it needs some polishing but is fully functional, the advantage is that the device can be recovered without flashing first as it doesn't need to access maemo's rootfs to start.

please take a look at it, if you are going to improve backup menu.

sorry again for going off-topic.

I think it's a perfectly fine idea to do what was suggested earlier. Use fbcon for bootmenu if preinit/bootmenu detects fbcon is loaded (which would happen if it was available AND the person configured it to load), and fall back on text2screen for when it's not.

That way you avoid the screen tearing problems mentioned above, but can have your framebuffer device text rendering as well.

Alternatively you have to configure all these boot script to check if fbcon is loaded, and then safely unload it, before proceeding to something that's using text2screen.

Sidenote: I also still think a basic recovery shell option should be built into preinit itself - actually, ideally, a recovery shell should be hacked into NOLO, but that's not happening until that's properly reverse-engineered and/or an open source version exists (does one? I think I've seen someone mentioning something like that on TMO within the last month?) - I know it's a minute difference, but the further away from the very first script ran you get, the more likely that someone will delete or modify or break it, and yet has the device booting correctly at least to /sbin/preinit execution.

Putting a simple shell as early as possible within /sbin/preinit is slightly more likely to let someone save a device from a screw up when editing some other boot-related script/program.

Recovery shell is already in preinit. But it is enabled only for serial console. I can rewrite that to work with framebuffer too (serial console or framebuffer output - all is same - character device ).

That works. I'm happy now. Although for the framebuffer one, the watchdog and keyboard led stuff is needed. (Watchdog stuff so that the device doesn't kill itself and keyboard leds so you can actually see the keys when using recovery shell in a dark environment.)

Just came back to this thread wondering if anything new had occured.

For the record, I'm still occasionally messing around with legitly/legally reverse-engineering the booting process. My reasoning is this: if I use a modified preinit plus a console to get command-line access at the earliest moment possible, and then I figure out how to boot all the way from there, referring only to the open source parts of Maemo 5 for reference/guidance, then the results are proper, legally-clean, reverse engineering.

Needless to say, given that I'm a complete coding newb (and for booting-level stuff, linux newb too), unlike most Maemo devs, I suspect progress will be painfully slow. For instance, someone who knows what they're doing would already know how to mount the eMMC from where my old preinit mod (with the boot shell as early as I thought reasonable) gives you the shell. However, I am still just figuring out mknod properly. So don't expect real results on this front any time soon.