[TESTING] - NAND OMGB (1.2.3)

[argenisaz]

Originally Posted by argenisaz

2. I was on a call, and while talking I noticed the screen off and a solid green light. The call finished and the phone wouldn't come back to life. I let it settle for 10 min and nothing, I didn't respond to the press of any button (solid green light all the time). I wanted the ADB into it, but as soon as I connected the usb cable it restarted, I'm posting my last_kmsg.

It happened again, here's the last kmsg

[[ACL]]

Originally Posted by argenisaz

It happened again, here's the last kmsg

Ahh I think arrggg told me about this in the past. So the phone tries to go to sleep when you are in a call right? So when your call is over, the phone probably doesnt realize it should be awake instead of napping. This actually happens to native devices as well. My friend's OG droid for example had very similar issue. Wonder how they solved it.

[arrrghhh]

Originally Posted by [ACL]

Actually no, its not just the charge discharge logic. The whole batt code is broken and needs love. Do a text search on the batt code and you will find the word "hack often. I've been so busy at work i havent had time to do anything lately. If anyone wants to dive in, just study the htc_battery_smem.c file and you will see why its so broken.

This!!!!

Originally Posted by [ACL]

Ahh I think arrggg told me about this in the past. So the phone tries to go to sleep when you are in a call right? So when your call is over, the phone probably doesnt realize it should be awake instead of napping. This actually happens to native devices as well. My friend's OG droid for example had very similar issue. Wonder how they solved it.

Or if they solved it...

I thought the ARM11 side was allowed to sleep during a call, but ARM9 is obviously still up and functioning. But the green LED indicates ARM11 state, so it would go green while in a long call...

However, the real issue is why it doesn't wake back up. I've had it happen before, but usually the phone wakes back up... So AFAIK it's "normal" for the phone to sleep in a call. What's not normal is the not waking afterwards .

[[ACL]]

Originally Posted by arrrghhh

This!!!!



Or if they solved it...

I thought the ARM11 side was allowed to sleep during a call, but ARM9 is obviously still up and functioning. But the green LED indicates ARM11 state, so it would go green while in a long call...

However, the real issue is why it doesn't wake back up. I've had it happen before, but usually the phone wakes back up... So AFAIK it's "normal" for the phone to sleep in a call. What's not normal is the not waking afterwards .

good question .. My calls are so short i guess i never have to worry about sleep. I'll need to test this again in the future once i have more time.

[detule]

Originally Posted by [ACL]

Ahh I think arrggg told me about this in the past. So the phone tries to go to sleep when you are in a call right? So when your call is over, the phone probably doesnt realize it should be awake instead of napping.

Perhaps a different issue, but on the new kernels there used to be an issue where the device would be unresponsive after suspending (GREEN led) in the midst of a phone call. Don't remember why/how but it was bma to blame. The new bma driver doesn't suffer from this problem.

[[ACL]]

Originally Posted by detule

Perhaps a different issue, but on the new kernels there used to be an issue where the device would be unresponsive after suspending (GREEN led) in the midst of a phone call. Don't remember why/how but it was bma to blame. The new bma driver doesn't suffer from this problem.

We never used the original bma driver. Our bma code is based on htc code but what these guys are reporting can be replicated. I just need to make a convo long enough to do it ..lol. Time to add money to the boost account..

[[ACL]]

I'm thinking of an easy way to just reverse the winmo batt logic. We can prob get this done from haret or a small winmo app. Dump all the smem values per hour on a file from start to death. We also dump the converted values so we dont need to create damn algorithms from raw values but use a look up table to handle it.

maybe its the coffee talking but thats what i would do if i had time ..

[detule]

Originally Posted by [ACL]

We never used the original bma driver. Our bma code is based on htc code ..

Oh snap...So in addition to the official bosch driver, and the mess in .27 that's probably our very own, there's also a htc branded one. I should know better by now, why have one driver when you can have three.

[[ACL]]

Originally Posted by detule

Oh snap...So in addition to the official bosch driver, and the mess in .27 that's probably our very own, there's also a htc branded one. I should know better by now, why have one driver when you can have three.

Yeah. When i first build gingerbread in general, the old bma driver wasnt very nand friendly with the aosp userland libs. So if you notice, our userland sensor libs also differ so they can work with the htc kernel libs. Pain in the ass i know.. lol..

[yovy]

Could someone try to cook darktremors app2sd(ext3) script into OMGB i got it to work but it stops working after a few reboots.