Re: Only boots up in RD Mode
 

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.

Re: Only boots up in RD Mode
 

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

Thanks!

Re: Only boots up in RD Mode
 

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...

Re: Only boots up in RD Mode
 

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)

Re: Only boots up in RD Mode
 

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
.
.
.

Re: Only boots up in RD Mode
 

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.

Re: Only boots up in RD Mode
 

// 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... ;)

Re: Only boots up in RD Mode
 

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

Re: Only boots up in RD Mode
 

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.

Re: Only boots up in RD Mode
 

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)

Re: Only boots up in RD Mode
 

Please revert to stock kernel (for now, until this got solved), never load this module (only available in powerkernel), best you delete it completely. This module is *known* to conflict with bme by exclusively allocating the I2C bus to bq27200, so whenever bme starts after the module got loaded, bme will blow chunks on trying to get info about battery

/j

Re: Only boots up in RD Mode
 

I don't think watchdogs have a way to cleanly unmount. Actually they usually trigger a rather hard shutdown.
Indeed without ID pin bme is tearing *down* device pretty fast. Good point. Needs furher evaluation. The temperature though is NOT via BSI (battery size|status indicator, the real name of ID pin). the bq27200 "temperature" value is the temp of the chip's die, and thus vastly irrelevant but never 0.
Indeed. but first of all DO NOT USE the bq27200 kernel module! It breaks bme operation.

I'll post a more comprehensive statement later
/j

Re: Only boots up in RD Mode
 

Sorry - please scratch this whole post. It has too many false assumptions to comment on them one by one.
Bottom line: it won't help

/j

Re: Only boots up in RD Mode
 

That's the reason :-)
I honestly suggest you try a new battery first, then if that gives same result we may have a look what else may cause this problem

/j

Re: Only boots up in RD Mode
 

ok, now that I'm at end of this thread, it seems you managed to spot the root cause. :-) Congrats. It's quite obvious this can only be a hw defect. Does anybody know what's a "good" value for BSI? (I probably could look up in source of getbootstate, but bear with me...)

jvollmann, please check carefully your 3 contact blades of battery contact in device - CLEAN them!

BSI also gets probed by modem directly, so I wonder what modem says to this. Alas we can't ask the modem ;-)

I only hope this isn't a silicon burnout, possibly caused by overclocking or harsh treatment of device like attaching alien power to battery contacts

cheers
jOERG

Re: Only boots up in RD Mode
 

About Estel's getbootstate.c:
- I installed gcc in n900 but i can't compile the file. Too many errors while compiling. I will try with SDK later!
- If it works, do you think this will let me charge the battery?

About joerg_rw comments:
- I reflashed the device to original PR1.3...
- I tried to start the phone with 2 different batteries and nothing...
- I will clean the battery contacts with a "contact cleaner" liquid...
- I don't think it's a silicon burnout, never overclocked and never used another battery but the original one.

Re: Only boots up in RD Mode
 

Hey joerg_rw! Thanks for coming here to help us. Common sense also tell me that it's possible only by some hw effect, but for some reason, it doesn't seem right for me. You're perfectly right that many things said there were just assumptions - that's why lot of #fixme - but especially two things doesn't fit IMO for hardware fail theory. First, jvollmann find posts from other users having same issues - they claimed that Nokia Care solved it flashing via serial pins beneath battery. Still I don't buy it as-is, cause I see no reasons why unprotected D+/D- pins could result in "deeper" reflash, but...

Then, despite fact You've suggested to scratch totally one of my posts (and I'm sure You're right about that - just to avoid misunderstanding), I think You'll agree that further update by jvollmann about his typo in command, resulting in false "0" for "charge_full_design", thus leaving only:

cat /sys/class/power_supply/bq27200-0/capacity
0
cat /sys/class/power_supply/bq27200-0/charge_full
0
cat /sys/class/power_supply/bq27200-0/charge_now
0
cat /sys/class/power_supply/bq27200-0/time_to_empty_avg
0
cat /sys/class/power_supply/bq27200-0/time_to_empty_now
0
cat /sys/class/power_supply/bq27200-0/time_to_full_now
0

...as 0 may root from chip's inability to perform ANY calibration (as per 412b and shadowjk's posts, it's performed internally no matter if You use stock kernel or power-kernel), cause jvollmann isn't able to charge via USB cable (only charging battery externally). Mix it with many full reflash procedures - including cold reflash and EMMC reflash (yea, not quite relevant, but You know what i mean), and this may be why capacity, charge_full, charge_now, both "times to empty" and "time to full" are 0's.

Then, charge_full_design shown as "2056320" , which is calculated by measuring resistance between ID pin and ground (thus being totally wrong, by the way), mean that ID pin IS probed correctly, right?

---

As for Your question, correct values for BSI are:

32-85 - Service battery, result in "LOCAL" bootstate
87-176 - Test battery, result in "TEST" bootstate
280-568 - Normal battery, no bootstate change, continue checking.

Everything else - "UNKNOWN" and shutdown, except R&D mode.

While 28-568 result in our perfectly fine load, I have no idea how LOCAL or TEST bootstates affect booting. It seems that scripts in /sbin/preinit/ and /etc/ that call getbootstate decide what to do - they're open, so probably, we can check that ;)

1. That's why I told You about SDK/scartchbox - many "include" at the beginning, which You probably don't have with only gcc.

2. IF it works, You'll definitely be able to charge battery - it return exact same state as NORMAL (280-568), so no reasons why Your battery should be threaten differently. Charging with "UNKNOWN" doesn't work in R&D, cause Nokians use "dummy" batteries (false battery attached to main DC power source) in their workdesk's, so they don't want N900 to put power back into main by any means ;)

Everything above is correct only if (we assume that it will work at all, of course) there is no real serious hardware damage to charging chip. Which I think is most unlikely - keep in mind that joerg_rw seems to think otherwise, and he is MUCH (threat MUCH as multiplied by n times ;) ) more experienced than me.

So only time will tell :)

Re: Only boots up in RD Mode
 

nope, the driver is both not really clean and deprecated, and as mentioned conflicts with bme in unpredictable ways.
No, that's not how bq27200 chip and BSI works. the chip doesn't reset all registers to 0 when CI=1 aka uncalibrated. And BSI is completely unrelated to bq27200
Many thanks for this interesting info. Note that BSI is also checked by modem directly (in hw) so any changes by "TEST" "battery" might affect the modem only. NOLO also checks during bootloading, so maybe early stages of boot are affected as well. My idea is a TEST battery has exactly same effect as setting R&D mode.
BSI resistor in a normal BL-5J is 100k-Ohm, this is a relatively high resistance. So any "shorts" in battery and at battery connector in device caused by dust, humidity, whatnot else, may easily cause this to get out of range.
Again, my suggestion is to clean the contacts and isolating material around the contacts, and maybe even open up the device and clean the inside so there are no "short circuits" caused by dust or residue from getting wet, which will cause the 100k value to get "detuned". Another rather weird idea tha comes to mind is the modem and its firmware are interfering with the OMAP BSI AD-conversion, in a way that switched modem's BSI sensing pin to an output or to internal pullup/down-resistor and so creates additional load to the circuit

cheers
jOERG

Re: Only boots up in RD Mode
 

Huge thanks for clearing things up. As for Your advices...

... nice idea. I know that default resistance is 100k-Ohm, but I didn't thought about possible short-circuit by something - shame on me, cause I'm already interested in getting info about lowest accepted BSI resistance, due to working on battery internal hotswap mod. Definitely worth trying. I would just advice to also measure resistance using multimeter, both between battery pins and N900 pins itself - for some most unlikely cases, where cleaning won't remove possible shortcut (so, clean and measure to be 100... ok, 99% sure)

:eek: Any ideas hot this possibility can be verified/fixed?

Re: Only boots up in RD Mode
 

I opened up the phone, clean the battery contacts (both on phone and battery itself) but the problem persists. I don't have a multimeter here, I'm going to borrow one and try to test the resistance.

Should I still try to compile the getbootstate.c file??

Re: Only boots up in RD Mode
 

Of course You should. Sorry if it was confusing - both methods were to try @ parallel, not exclusive. As for getbootstate, we are not sure that my modified version will work, but we're sure (well, at least for 99%...) that correctly tweaked getboostate IS going to at least let You boot device in normal mode. Then, we suppose, that this will also allow You to charge in both normal and R&D mode (if charging chip isn't physically damaged or other bizarre things).

So, even if this getbootstate doesn't work, it's just matter of checking why (that's why still use framebuffer) and fix eventual mistakes. This way, we can optimistically assume that it WILL work, sooner or later, i.e it's only matter of time (and eventually asking someone for assistance, if it turns out that i suck big time and modifying source code of getbootstate).

So, to push things forward, we're waiting only for proper compilation and testing @ Your side.

Re: Only boots up in RD Mode
 

I'm getting these errors when compiling Estel's getbootstate.c fix:

[sbox-FREMANTLE_X86: ~] > gcc -Wall -g getbootstate.c -o getbootstate

getbootstate.c: In function 'get_bsi':
getbootstate.c:234: warning: implicit declaration of function 'ioctl'
/var/tmp/ccmwLNCv.o: In function `get_rdmode':
/home/leli/getbootstate.c:256: undefined reference to `cal_init'
/home/leli/getbootstate.c:259: undefined reference to `cal_read_block'
/home/leli/getbootstate.c:260: undefined reference to `cal_finish'
collect2: ld returned 1 exit status

I'm not sure what to do...

Re: Only boots up in RD Mode
 

That definitely means that i screwed implementing fix ;) try now (new file attached to this post)

WARNING!

As last method failed, I tried now uglier "hack" - if it succeed to compile, may still fail to boot without problems on Your device. If that would be the case, let me know and we will try something other and/or ask someone more experienced @ coding to look at this.

---

Also, here is update to my findings about bsi values (joerg_rw may be interested) and it's meaning to getboostate - I see now that my last report would not totally correct. Value ranges remain the same, but LOCAL and TEST work *only* in R&D mode - there is !rdmode based line, which result in returning SHUTDOWN state and logging "Unknow battery detected" if BSI value is out of NORMAL range *and* R&D mode is *not* present.

So, LOCAL and TEST must mean something special to use *only* in R&D mode.

Re: Only boots up in RD Mode
 

I don't think it's the way you modified the file but the way gcc works!

I found this: http://wiki.maemo.org/Documentation/...ment/Maemo_SDK

"The source code started with #include, and you need to tell the compiler where to look for that critical -- header file. The compiler probably also needs some special flags to be able to use the correct compilation settings for building -- software...
When linking the application, the linker has to be told which libraries to link against. In fact, the whole program linking phase will fail without this information. "

So, I think I have to tell the compiler about libcal location or something..

Re: Only boots up in RD Mode
 

I compiled the new file and I'm getting the same errors:

[sbox-FREMANTLE_X86: ~] > gcc -Wall -g getbootstate2.c -o getbootstate

getbootstate2.c: In function 'get_bsi':
getbootstate2.c:234: warning: implicit declaration of function 'ioctl'
/var/tmp/cc0MyZ7b.o: In function `get_rdmode':
/home/leli/getbootstate2.c:256: undefined reference to `cal_init'
/home/leli/getbootstate2.c:259: undefined reference to `cal_read_block'
/home/leli/getbootstate2.c:260: undefined reference to `cal_finish'
collect2: ld returned 1 exit status

Re: Only boots up in RD Mode
 

Nice catch.

Damn, so I think You should ask here how to compile it properly, which info about errors. Fortunately, Pali is quite active...

Then, try correctly compiling my first modified version, and try second only, if it fails. first one get rid of returning SHUTDOWN state alltogether (best chance of success in your case IMO), second one keeps that lice, except that it tell it to return NORMAL state instead of shutdown (that why it's uglier "hack").

Also, in thread i linked, you can find original getbootstate. You can try compiling it also before asking - to be sure that You get same errors, and it's not fault of my modification. If it compile by any chance, of course, putting original getbootstate in phone is useless, so only report it there and we'll think what to do.

Re: Only boots up in RD Mode
 

Ok, I will ask there. Hopefully someone know how to compile it!

About compiling Pali's original file, I got the same errors:

[sbox-FREMANTLE_X86: ~] > gcc -Wall -g getbootstate3.c -o getbootstate
getbootstate3.c: In function 'get_bsi':
getbootstate3.c:234: warning: implicit declaration of function 'ioctl'
/var/tmp/ccYjDQYl.o: In function `get_rdmode':
/home/leli/getbootstate3.c:256: undefined reference to `cal_init'
/home/leli/getbootstate3.c:259: undefined reference to `cal_read_block'
/home/leli/getbootstate3.c:260: undefined reference to `cal_finish'
collect2: ld returned 1 exit status

I will let you know any news, thanks

Re: Only boots up in RD Mode
 

I could compile the file!

I tried first with Estel's modification and didn't worked.
After that, I compiled Pali's original file and also didn't worked.

The screen shows: "System malfunction" Device shutdown in 10s

FB-kernel log showed this up:

Re: Only boots up in RD Mode
 

Nice that You compiled it. Still, I told you that trying with pali's unmodified version is pointless in your case ;)

so, first modified getbootstate failed... Any errors from framebuffer? Also, using first modified file with R&D also failed to boot, or boot but still unable to charge?

Also, tried with second modified file?

I'm trying now to determine what failed - my pseudo-hacking skillz, or there is another factor unseen before.

Re: Only boots up in RD Mode
 

I'm going to look into compiling this experimental bootstate in the near future, see if I can get it to work. In the meantime, I appreciate everyone's informative posts in this thread, keep it up and such.

jvollmann, you compiled it for armel right? Because one of your output posts suggests you had scratchbox pointed at the x86 target. Different processor architectures use different binaries. (x86 is what most desktop computers have on board, most mobile devices are the armel architecture.)

If you put the for-x86-compiled binary into the N900 it simply wouldn't work, which might explain why you got the errors you got.

Re: Only boots up in RD Mode
 

Thanks Mentalist - only after your post i noticed that error occured before ever entering getbootstate internals. Permission denied? 0_o

If You're 100% sure that it's compiled for ARM, maybe You need to chmod a+x it, after placing on device? Seems little stupid for me - permission check at so early stage - but, who knows?

// Edit

I'm also looking forward for your results (Mentalist) with compiling it. If You feel adventurous, you may also try my modified one (better start with 1st one, second got higher chance of being totally flawed) - it should work without problems on device with recognized battery, only allowing others to be threaten as recognized. Just keep in mind that I've no idea what's gonna happen if my ugly hack doesn't work. Probably nothing worse than jvollmann get with totally faulty getbootstate, thought.

Re: Only boots up in RD Mode
 

//edit:

Estel: Sorry if I didn't make myself clear: The framebuffer-log I wrote before happened in both cases: Yours and Pali's getbootstate.c file... I couldn't boot in R&D mode when replacing the getbootstate file in /sbin .

Mentalist: I think you're right, I compiled in x86,,, as you said, that might be the reason of errors.

Let me try to compile it for armel and I'll post results!

Re: Only boots up in RD Mode
 

Well, worse case scenario I reflash. Nothing new to me. :P

- Edit -
Sorry, didn't see you post right before-me/as-I-was-typing. Good luck with the compiling for armel. Hope if works for you.

Re: Only boots up in RD Mode
 

Ok, I compiled for armel. Replace the file in sbin (without chmod it). Restart the device in R&D mode and this is part of the log:

Re: Only boots up in RD Mode
 

Change permissions? Also, try with non R&D mode, to check, if error will be same as with compiled for x86? Try compiling Pali unmodified getbootstate and check if error occur in R&D mode? Try second (uglier) "hacked" version?

Re: Only boots up in RD Mode
 

I chmod it (like Estel proposed) and it worked!

Pali's version didn't worked for me as Estel told me, but his first modified version made it...

Thanks a lot!

Now, I tried to charge the battery with usb cable, the device asked me if I wanted "Mass storage" or "Pc Suite", in that moment appeared a screen notification telling: 'Not charging' (the led didn't turn on either)

In framebuffer log, now appears:

Re: Only boots up in RD Mode
 

I'm very glad it worked finally! I suppose, it boots up without R&D now? (rhetorical question)

What the hell is /dev/tw14030-adc ?!

Still, if You can't charge anyway, I suppose charging chip damage :( I wonder, if You can now use HEN? AFAIK (can be wrong with chip names, thought) same chip provide up to 200 mA to USB 5V, during hostmode. Try installing H-E-N and connecting some kind of pendrive, mouse or whatever... I'm afraid only way to use hostmode for You now is via Y-Cable or powered HUB. But we still need to check that, it's only assumption.

The only other possible root of problems, that come to my mind, is malfunction of chip firmware/eeprom data (corruption?). Rather crazy idea, but I can't get how this chip can work "partially", like now it seems to act. Still, fixing firmware/eeprom is probably out of scope (require some kind of hardware programmer + access to chip itself + and appropriate software?).

Of course You can live with charging outside and hostmoding with powered hub/Y-cable, but I've hoped for better results that "just" taking You out of R&D mode. Still, it's good that we find source of problems and semi-fixed it.

Last idea, that i get right now, is to check if "USER" is really normal mode. If "Unknown" battery prohibited charging (for safety reasons), and probably same apply for LOCAL (as it's DC power source acting as battery), it *is* possible, that I only changed behavior for detecting "unknown" battery via BSI value, but still there somewhere (getbootstate, or even in other place?) something using raw BSI value to decide what to do? Joerg_rw told us, that modem use BSI value, for example - but modem doesn't seems to comply.

What makes me wonder, is that You get Not charging" message, instead of "Charging error", that we would suppose to see with damaged chip (there is "Charging Error" command - I've seen it pretty much while experimenting with chip calibration). Like it's some "correct" behavior, for current state of things (well, particularly for current BSI value).

Of course it's just plain assumption, so don't get Your hopes too high. Ho ever, i wonder if there is a way to "fake" BSI value, that scripts get/it's reported... To use one from "normal" range...

Summarizing: We need to:

1. Be sure that "USER" is our plain, everyday normal bootstate, cause You're obviously now getting "USER" bootstate.

2. Audit scripts, for possible bsi readings?

Can anyone with access to desktop PC and device *not* affected by problem (Mentalist, I'm looking at You, cause others following this thread probably won't dare ;) ) flash framebuffer kernel and check which bootstate is used during normal boot? Another, probably easier way, is to determine it by examining getbootstate source code. Every state is obvious for me just by looking @ this code, except what i used during normal boot... :/

Sorry for little chaotic, stream-of-consciousnesses like way i posted it. I'm after night without sleep ;)

Re: Only boots up in RD Mode
 

- I'll install HEN and try to connect something..

- I just recharged the battery from my nokia 5800 but the n900's battery icon keeps showing low battery level and warning.

Is the charging chip related to the monitor/level of the battery?

Re: Only boots up in RD Mode
 

The charging chip is not related to battery state of charge monitoring.

Re: Only boots up in RD Mode
 

I couldn't use HEN because I don't have any device that connects thru microUSB... I will have to buy an usb adapter!