![]() |
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
Quote:
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:
Code:
. |
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: Code:
. |
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!
|
| All times are GMT. The time now is 01:24. |
vBulletin® Version 3.8.8