Active Topics
-
Porting apps to Leste (32)
to Maemo 7 / Leste by Arno_11 - 1 day, 1 hr ago -
[ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900 (2,264)
to Maemo 5 / Fremantle by panjgoori - 2 days, 20 hrs ago -
Full linux distros on Sailfish OS (254)
to SailfishOS by qoh - 3 days, 18 hrs ago - more...
| The Following 2 Users Say Thank You to Estel For This Useful Post: | ||
|
2011-07-19
, 03:56
|
|
Posts: 63 |
Thanked: 27 times |
Joined on Jul 2011
@ Venezuela
|
#72
|
Originally Posted by Mentalist Traceur
//edit:
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.
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!
Last edited by jvollmann; 2011-07-19 at 12:54.
| The Following 2 Users Say Thank You to jvollmann For This Useful Post: | ||
|
|
2011-07-19
, 04:05
|
|
Posts: 2,225 |
Thanked: 3,822 times |
Joined on Jun 2010
@ Florida
|
#73
|
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.
Last edited by Mentalist Traceur; 2011-07-19 at 04:08.
- 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.
Last edited by Mentalist Traceur; 2011-07-19 at 04:08.
|
|
2011-07-19
, 04:17
|
|
Posts: 63 |
Thanked: 27 times |
Joined on Jul 2011
@ Venezuela
|
#74
|
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:
. . . getbootstate: R&D mode enabled sh: serial-console unknown operand /sbin/preinit: line 339: getbootstate: Permission denied . . .
 |
|
2011-07-19
, 04:48
|
|
Posts: 5,028 |
Thanked: 8,613 times |
Joined on Mar 2011
|
#75
|
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?
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
|
|
2011-07-19
, 05:19
|
|
Posts: 63 |
Thanked: 27 times |
Joined on Jul 2011
@ Venezuela
|
#76
|
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:
Last edited by jvollmann; 2011-07-19 at 05:35.
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:
. . . getbootstate: Could not open /dev/tw14030-adc - No such file or directory getbootstate: User pressed power button getbootstate: Entering state: 'USER' getbootsate: slide open, trying to start boot menu Welcome to your upstart powered internet tablet . . .
Last edited by jvollmann; 2011-07-19 at 05:35.
| The Following User Says Thank You to jvollmann For This Useful Post: | ||
|
|
2011-07-19
, 08:42
|
|
Posts: 5,028 |
Thanked: 8,613 times |
Joined on Mar 2011
|
#77
|
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
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
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
|
|
2011-07-19
, 22:07
|
|
Posts: 63 |
Thanked: 27 times |
Joined on Jul 2011
@ Venezuela
|
#78
|
- 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?
Last edited by jvollmann; 2011-07-19 at 22:17.
- 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?
Last edited by jvollmann; 2011-07-19 at 22:17.
|
|
2011-07-19
, 23:25
|
|
Posts: 1,258 |
Thanked: 672 times |
Joined on Mar 2009
|
#79
|
The charging chip is not related to battery state of charge monitoring.
| The Following 3 Users Say Thank You to shadowjk For This Useful Post: | ||
|
|
2011-07-20
, 14:44
|
|
Posts: 63 |
Thanked: 27 times |
Joined on Jul 2011
@ Venezuela
|
#80
|
I couldn't use HEN because I don't have any device that connects thru microUSB... I will have to buy an usb adapter!
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.
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
Last edited by Estel; 2011-07-19 at 02:14.