Sorry, didn't used framebuffer kernel myself - search forum for related threads please.

As for jrBME, this idea was abandoned due to fact bme integrates with other hildon components - it would need a total rewrite of some essential parts (much, MUCH work, resulting on almost all open-sourced implementation of charging N900 - would be great, but impossible to create by small group of people. Need big project to do that).

Personally, i would love to see bme kicked out for good, but for now best we can achieve is shadowjk charger script (pretty awesome, by the way!). This will be included in next HEN release probably. Ho ever, joerg_rw (and others) work on replacing bme resulted in very good understanding of bme behaviours, so this wasn't definitely a waste.

I would suggest You to PM user joerg_rw pointing tot his thread, asking nicely to have a look. He, amongst others (shadowjk, 412b) is person that know bme / N900 charging process best. Maybe He or others mentioned would have an idea what the f... is going with Your (and others reporting same problem) device.

Ok, I will PM them... hopefully they can give us some more light in this tunnel..

Thanks!

I could install framebuffer kernel.

I'm attaching 4 pictures I took during booting in normal mode.

These are the lines that kept my atention:

Disabling unused clock "gpt11_fck"
.
.
.
Bootup reason: pwr_key
.
.
.
getbootstate: Unknown battery detected. raw bsi value 240
getbootstate: Entering state 'SHUTDOWN'
getbootstate: slide open, attemptin to use bootmenu
getbootstate: Unknown battery detected. raw bsi value 241
.
.
.
isp_mod: Unknown symbol iommu_put
.
.
.
isp_mod: Unknown symbol videobuf_to_dna
.
.
.
smc91x: not found (-19)
.
.
.


The final line was:
Failed to change runlevel...

It may be worth to do same in R&D mode, then compare framebuffer outputs. Anyway, at least, direct symptoms - I hope joerg_rw and other will be able to parse this. I don't have sufficient interpreter installed (for non-geeks - i mean my brain, not N900)

For my comparison between normal boot and R&D boot logs, the problem starts in: getbootstate command...

In normal mode, it shows: "Unknown battery" and then "Entering state: Shutdwon", while in R&D mode shows: "R&D mode enabled" and then "Entering state: USER".

It's good to know that I'm using two different batteries, the one wich comes with the n900 and the other one from my nokia 5800 (both works perfectly in that device).

On this url: https://bugs.maemo.org/show_bug.cgi?id=7019 I read this: "To shutdown the device for safety reasons if battery is of incompatible type."


I'm going to type some of the lines that showed up booting in R&D mode:

.
.
.
getbootstate: R&D mode enabled
getbootstate: Entering state 'USER'
.
.
.
About to exec dsme in state 'USER'
DSME 0.60.48 starting up
dsme wdd: R&D mode enabled
waitfordsme: Wait for DSME socket...
.
.
.
BOOTSTATE: 'USER'
state change request: DSME_STATE_NOT_SET -> DSME_STATE_USER
Startup state: DSME_STATE_USER
waitfordsme: OK: DSMEsocket exists
USER
Starting alsaped
Starting hal daemon
.
.
.

I have gone through whole bug thread You mentioned (nice drama, by the way - i really recommend reading this to everyone). It seems that definitely, for reasons unknow Your N900 can't properly recognize battery type. Nothing more, nothing less. Still, such unknow fail isn't good thing, but as long as it doesn't go further, there aren't any drawbacks related to this - of course if You don't plan to connect Your N900 to car battery

Stil, check comment 36 on bugtracker thread You mentioned. Pali published working, open source version of getbootstate. Modifying it to always return correct battery info - no matter what - would result in device booting in normal mode without problem, just like with R&D enabled, but with watchdogs still working and serial disabled, etc.

Also, check comment 7 - "Actual decission on what to do is made by script calling getbootstate, placed in /sbin/preinit and /etc init scripts". So, probably, You can avoid touching getbootstate and just edit that scripts, to make them boot even with "wrong" battery status. This is probably easier alternative to method 1, but require searching for getbootstate calls in preinit script, and determining which one decide to shutdown device.

// Bump Edit

I've modified Pali's Open Source version of getbootstate, to ignore values resulting in "unknown battery" and proceeding like with "normal" - see attachment. You need to compile it before use. Unmodified version was tested by Pali only in qemu, my modified version wasn't tested at all. Best to try using with framebuffer kernel, to debug possible problems.

WARNING!

Uncertified software hack. May brick Your device. May result in need for reflash. May blow up Earth.

I think it's only possible to test it properly on device affected by problem, i.e. Your device - otherwise, we won't have a clue if it returned "normal" mode because my tweak work, or because battery is really normal...

Nice... I will try that when I get home (about 12 hours). But I need help with instructions to run it, I'm not sure how to compile the file..

Hope it works!!
Thanks

Neither I am... You probably need maemo scratchbox/SDK. I'm now unable to test it myself - no desktop in reach - that's why all the warnings. Ho ever, other people that at least compiled anything for maemo (unlike me, mind that) may know for sure. Mentalist? Anyone?

Anyway, after You manage to compile it correctly, installation is just a piece of cake - drop it to /sbin/ , replacing old one. Boot only with framebuffer kernel, cause otherwise, we wouldn't be able to know if it failed cause my tweak is wrong, or because getbootstate doesn't work at all = compiled wrongly.

Again, keep in mind that I'm not expert by any means, so it can be screwed totally. Still, I think it got big chances to work properly - edit was just few lines long, and way it works seems very intuitive, common-sense friendly. Well, i think that's they joy of Open Source community - sometimes You just use things written by people less experienced that You think they are, and results are big mystery - yet, You're able to trace and fix issues, that probably even original developers have no idea about. Not to mention even dreaming about fixing it with "fake open"/closed source, shiny packaged Androids/Ipods and whatsnot.

Sorry, this is not exactly correct. R&D mode does a bit more than just enabling the activity signals on kbd bl. It e.g. also enables the serial tty on testpoints under battery, and whatnot else. As you can see with OP's case, there are quite some differences on a low level.
Nevertheless I agree R&D mode doesn't seem to do real harm (though I never heard of anybody else burning up 3+ batteries per day, Mohammad does it regularly).

/j

(sorry for replying to posts in the sequence they were posted, being late to the thread)