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.

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

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.

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

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

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.

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

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:

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.

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.