Ticket #1682 (closed defect: fixed)

Opened 6 years ago

Last modified 5 years ago

Neo turns off before reaching X

Reported by: queen6 Owned by: openmoko-kernel
Priority: high Milestone: Om2008.8
Component: kernel Version: GTA02v5
Severity: normal Keywords:
Cc: Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: no PatchReviewResult:
Reproducible:

Description

Hi,

When I turn on my freerunner while battery is very weak, starts normally, but turns itself off somewhere during INIT.

Where is the charing initiated (500mA from USB)? Is it in kernel, userspace or u-boot?

The only way to boot it properly is to swap battery for more charged one, fully boot (until X) and replace it with original one.

I'm using b-boot from 2008.07.27, all other packages have been updated with Opkg update/upgrade at 2008.07.28. Still the same problem.

Some time ago (~2 weeks) it was possible to boot without battery (battery was only needed only to power neo on. You could remove on u-boot screen). Right now it seems it's more power hungry somewhere during INIT.

I'm not sure if that has anything to do with:

Jul 29 07:00:27 om-gta02 user.info kernel: [ 1520.155000] glamo-mci glamo-mci.0: Error after cmd: 0x8021
Jul 29 07:00:28 om-gta02 user.info kernel: [ 1520.155000] glamo-mci glamo-mci.0: Error after cmd: 0x8123
Jul 29 07:00:28 om-gta02 user.err kernel: [ 1520.155000] mmcblk0: error -84 sending read/write command
Jul 29 07:00:28 om-gta02 user.warn kernel: [ 1520.155000] end_request: I/O error, dev mmcblk0, sector 0
Jul 29 07:00:28 om-gta02 user.err kernel: [ 1520.155000] Buffer I/O error on device mmcblk0, logical block 0

I will file another bug about it anyway.

Change History

comment:1 follow-up: ↓ 2 Changed 6 years ago by andy

Charging is handled by the kernel driver, 500mA is allowed after USB stack informs us we are enumerated by a host for 500mA.

You shouldn't get forced off just because it wants to charge anyway, I guess something else goes on.

comment:2 in reply to: ↑ 1 Changed 6 years ago by queen6

Replying to andy:

Charging is handled by the kernel driver, 500mA is allowed after USB stack informs us we are enumerated by a host for 500mA.

You shouldn't get forced off just because it wants to charge anyway, I guess something else goes on.

Hmm.. that way it should initiate 500mA _before_ INIT (correct me if I'm wrong).

Does it mean FR can't charge when it's powered down (the phone is turned off and you connect wall charger), or will it charge but using 100mA? (if it does, what initiate charging? HW or u-boot?)

What if the phone is suspended? Does it charge with 100mA, 500mA or doesn't charge at all?

Anyway I can't reproduce glamo/mmc error messages linked above after manually (dfu_util) flashing with newer kernel (btw because of end_request: I/O error, dev mmcblk0, I couldn't access SD card at all). I think this error message came up after opkg update (from community list it seems you guys are aware there was/is a problem there).

I will drain my FR's battery to 0 (wifi+gps+no_apm) and see if I can reproduce the problem.

comment:3 Changed 6 years ago by queen6

Yeah, exactly the same behaviour. It starts loading, kernel, everything seems to be fine, initiate INIT, that the bloody boots come up (how can I remove it btw? Without it I could see exactly when it dies). That around 1 min later (around the time when X should load and change the background theme to openmoko one) it just dies (turns itself off).

Leaving phone connected to USB charger for 10 min doesn't change the situation (hence the previous question - does the phone charge while powered off?).
I'm guessing it's battery related, because if I change the battery to more charged one (nokia spare battery), that it starts fine. I can remove the battery and place my original one.

As mentioned before, some time ago (~2 weeks) you could boot completely without the battery (it was only needed for powering the device up and initiating u-boot). It never required battery during linux boot process or X. Right now I can't get into X without well charged battery.
The battery voltage was around 3.55V when it died (used watch -n.5 'cat /sys/.../current_voltage' to monitor) - can't check it manually using voltage meter.

Any ideas?

comment:4 Changed 6 years ago by queen6

"the bloody boots come up" - splashscreen :)

comment:5 Changed 6 years ago by queen6

Well I've tried a few times more, and it seems it managed to reach X once (FR turned itself off just after showing the icons).

Also it seems I can't swap the battery when under X any more ;(
When I remove it, the device powers down.

I will try to reflash it with last last available ASU to see if that's gonna change anything.

comment:6 Changed 6 years ago by werner

This may be the VB_SYS bypass capacitor: GTA02v5 has a very small capacitor to
stabilize the system voltage. It's perfectly conceivable that a different
pattern of load changes could cause VB_SYS to break down before the USB host
adjusts its output.

If you like to play with a soldering iron, you could try to modify a USB cable
and put a big capacitor (I'd try about 100uF) between GND and VBUS. The whole
setup won't be USB-compliant (USB 2.0 section 7.2.4.1, page 177, only allows
10uF, and we already exceed that by a considerable margin), but you can usually
get away with that.

You may also be able to get better results with a shorter or better quality
USB cable, since it may reduce the voltage drop from host to device. Also a
different host may perform better or worse.

comment:7 Changed 6 years ago by queen6

Hi Werner,

Interesting theory, but doesn't really explain why it worked before. It also work fine on different image (tested on FSO Milestone2), so I dont think this is the case here. On FSO image I can remove battery at any point (just after u-boot phase, during boot on X).
I've built ASU image myself (from org.openmoko.dev repo) and I could reproduce this issue.
All tests were done in the same hardware (laptop+FR+cable).

Could any of you please answer my previous question about charging? I would like to know when FR is actually charging.

Thanks!

Rob

comment:8 Changed 5 years ago by andy

  • HasPatchForReview unset

Is this still happening with current andy-tracking or stable kernels (2.6.29-rc2/3)?

comment:9 Changed 5 years ago by queen6

Nope. You can safely close this ticket now. I can't even remember when I used ASU last time (I can't close it meself).

comment:10 Changed 5 years ago by andy

  • Status changed from new to closed
  • Resolution set to fixed

Great thanks for the feedback.

Note: See TracTickets for help on using tickets.