Send buglog mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.openmoko.org/mailman/listinfo/buglog
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of buglog digest..."
Today's Topics:
1. Openmoko Bug #2181: [andy-tracking] Not charging according to
kernel when charging from a stupid charger (Openmoko Public Trac)
2. Re: Openmoko Bug #2181: [andy-tracking] Not charging
according to kernel when charging from a stupid charger
(Openmoko Public Trac)
3. Re: Openmoko Bug #2181: [andy-tracking] Not charging
according to kernel when charging from a stupid charger
(Openmoko Public Trac)
4. Re: Openmoko Bug #2169: mokomakefile/org.openmoko.asu.stable:
illume_svn.bb do_fetch failed (Openmoko Public Trac)
5. Openmoko Bug #2182: [openembedded] build fails due to
duplicates in PACKAGE_ARCHS (Openmoko Public Trac)
6. Re: Openmoko Bug #2182: [openembedded] build fails due to
duplicates in PACKAGE_ARCHS (Openmoko Public Trac)
7. Re: Openmoko Bug #2181: [andy-tracking] Not charging
according to kernel when charging from a stupid charger
(Openmoko Public Trac)
8. Re: Openmoko Bug #2181: [andy-tracking] Not charging
according to kernel when charging from a stupid charger
(Openmoko Public Trac)
--- Begin Message ---
#2181: [andy-tracking] Not charging according to kernel when charging from a
stupid charger
-----------------------------+----------------------------------------------
Reporter: TimoJyrinki | Owner: openmoko-kernel
Type: defect | Status: new
Priority: normal | Milestone:
Component: System Software | Version:
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-----------------------------+----------------------------------------------
As a regression from stable-tracking/stable etc., the kernel says Neo is
not charging when charging from a stupid charger like a portable USB
battery or a car charger. Ie. /sys/class/power_supply/battery/status (and
uevent) say Not Charging. However, on IRC another user stated he can
measure that in reality it charges fine (and even more so if forcing the
usb current limit, as usual). So somehow kernel isn't picking this up.
If charging from laptop it shows fine.
Using andy-tracking de473ca893c9285a on top of daily testing. The actual
USB charger I'm using is from Proporta.com.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2181>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2181: [andy-tracking] Not charging according to kernel when charging from a
stupid charger
-----------------------------+----------------------------------------------
Reporter: TimoJyrinki | Owner: openmoko-kernel
Type: defect | Status: new
Priority: normal | Milestone:
Component: System Software | Version:
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-----------------------------+----------------------------------------------
Comment(by lindi):
The other user was me. Please let me know if there is something else I
could test. (Is there a way to subscribe to a trac ticket without having
to actually add a comment?)
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2181#comment:1>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2181: [andy-tracking] Not charging according to kernel when charging from a
stupid charger
-----------------------------+----------------------------------------------
Reporter: TimoJyrinki | Owner: openmoko-kernel
Type: defect | Status: new
Priority: normal | Milestone:
Component: System Software | Version:
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-----------------------------+----------------------------------------------
Comment(by andy):
What is the limit shown in
cat /sys/class/i2c-adapter/i2c-0/0-0073/pcf50633-mbc/usb_curlim
when you have the dumb charger... I guess it should be 100mA and then it's
right that there is not enough current to power the device (which gets
first dibs on the incoming power) and have some left for charging, at
least not if backlight is up.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2181#comment:2>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2169: mokomakefile/org.openmoko.asu.stable: illume_svn.bb do_fetch failed
---------------------+------------------------------------------------------
Reporter: lindi | Owner: openmoko-devel
Type: defect | Status: new
Priority: normal | Milestone:
Component: unknown | Version: unspecified
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
---------------------+------------------------------------------------------
Comment(by joel):
I can confirm that the stable image doesn't build out of the box.
Main problem is that the source packages are missing for the revisions
that the build system tries to download. It looks like direct svn access
is used as fallback but fails as well. I had to manually find existing
version and put new revision numbers in the following file:
{{{
$OMDIR/openembedded/conf/distro/includes/sane-srcrevs.inc
}}}
You're for example missing:
'''illume_svn.enlightenment.org_.svn.e.trunk_35818_.tar.gz''' at
http://downloads.openmoko.org/sources/
So you can try setting illume revision to something that exists. I used
the following to make it build (don't know if it's the best choice...):
{{{
EFL_SRCREV ?= "36540"
SRCREV_pn-illume ?= "36520"
}}}
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2169#comment:1>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2182: [openembedded] build fails due to duplicates in PACKAGE_ARCHS
---------------------+------------------------------------------------------
Reporter: joel | Owner: openmoko-devel
Type: defect | Status: new
Priority: normal | Milestone:
Component: unknown | Version: unspecified
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
---------------------+------------------------------------------------------
I had to remove "armv4t" in om-gta02.conf (see diff below) since tune-
arm920t.inc is included and also defines "armv4t".
/joel
Error:
{{{
$ cd shr-testing; make image
. conf/topdir.conf && test "`pwd`" = "$TOPDIR" || echo
"TOPDIR='`pwd`'" > conf/topdir.conf
. ./setup-env; exec bitbake "shr-image"
ERROR: Openembedded's config sanity checker detected a potential
misconfiguration.
Either fix the cause of this error or at your own risk disable the
checker (see sanity.conf).
Following is the list of potential problems / advisories:
Error, Your PACKAGE_ARCHS field contains duplicates. Perhaps you
set EXTRA_PACKAGE_ARCHS twice accidently through some tune file?
make: *** [image] Error 1
}}}
Diff for shr-testing/openembedded:
{{{
#!diff
diff --git a/conf/machine/om-gta02.conf b/conf/machine/om-gta02.conf
index f3e746b..37c5c89 100644
--- a/conf/machine/om-gta02.conf
+++ b/conf/machine/om-gta02.conf
@@ -5,7 +5,7 @@
#-----------------------------------------------------------------------------
TARGET_ARCH = "arm"
-PACKAGE_EXTRA_ARCHS = "armv4t"
+# PACKAGE_EXTRA_ARCHS = "armv4t"
PREFERRED_PROVIDER_virtual/kernel ?= "linux-openmoko"
PREFERRED_PROVIDER_virtual/xserver = "xserver-kdrive-glamo"
}}}
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2182>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2182: [openembedded] build fails due to duplicates in PACKAGE_ARCHS
------------------------+---------------------------------------------------
Reporter: joel | Owner: openmoko-devel
Type: defect | Status: closed
Priority: normal | Milestone:
Component: unknown | Version: unspecified
Severity: normal | Resolution: fixed
Keywords: | Haspatch: 0
Blockedby: | Estimated:
Patchreview: | Blocking:
Reproducible: |
------------------------+---------------------------------------------------
Changes (by john_lee):
* status: new => closed
* resolution: => fixed
Comment:
I just fixed that a few minutes ago. Thanks for reporting!
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2182#comment:1>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2181: [andy-tracking] Not charging according to kernel when charging from a
stupid charger
-----------------------------+----------------------------------------------
Reporter: TimoJyrinki | Owner: openmoko-kernel
Type: defect | Status: new
Priority: normal | Milestone:
Component: System Software | Version:
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-----------------------------+----------------------------------------------
Comment(by TimoJyrinki):
Like I (unclearly) stated, it's 100mA but changes to 500mA if I force it.
Usually at this point the charging icon shows up and the kernel tells it's
charging, but currently it does not. the usb_curlim does change to 500,
but there is no indication that the charging would be happening.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2181#comment:3>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2181: [andy-tracking] Not charging according to kernel when charging from a
stupid charger
-----------------------------+----------------------------------------------
Reporter: TimoJyrinki | Owner: openmoko-kernel
Type: defect | Status: new
Priority: normal | Milestone:
Component: System Software | Version:
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-----------------------------+----------------------------------------------
Comment(by andy):
OK so if I understood it the issue boils down to the UI indications (I
guess it means charger change events) are not impacted by using the curlim
forcing sysfs?
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2181#comment:4>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
_______________________________________________
buglog mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/buglog