[Bug 79] Dealing with GTA01 breakage / Community GTA01 tree

Andy Green andy at openmoko.com
Tue Apr 15 10:52:22 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:

| :) Whatever the default branch is for use in OE; I haven't actually
| checked.  I can see the latest commits, though, and that's been good
| enough for the moment.

Probably "stable" branch now I should think.

|> | Not-so-good news: ...it's badly broken on the gta01 :(   It panics on
|> | shutdown, suspend crashes and requires the battery to be removed to get
|> Do you have a copy of the panic?
| It's a heisen-bug, it seems.  I can only see it once-in-a-while, and
| never when I have anything connected to the neo that can log the panic.
|  That behavior might be a clue, I hope.

Hum if you have a debug board, it shouldn't really be able to tell if
you have it connected or not, you might copy the panic from the debug
console.  If it appears on screen, if you can find the top few function
names it can give a clue too.

|> | the device back.  No audio (or too low to hear in my automobile).
|> If your tree is not recent, "no audio" can be due to changes in the
|> audio driver, new mixer controls appeared in the last few weeks.  I saw
|> errors on alsactl restore from the mismatch and was able to get stuff
|> working by meddling with alsamixer and then alsactl store.
| I tried the new kernel with an older rootfs and got audio, so I expect
| this is not a kernel issue directly.  The audio is relatively low on my
| list right now, compared to the panic and the failure to suspend/resume.

The old kernel's sound driver might match your old alsa.state and work.
~ I am happy to at least stare at the panic if I can get a dump.

|> | So for the moment anyone who wishes to test a kernel that seems to
|> | behave better on the gta01 wrt suspend/resume can't get it from the
|> | normal places; instead fetch the kernel from http://moko.mwester.net/ .
|> In the longer run if GTA01 is going to keep working without excessive
|> pain the answer is either for GTA01 folk to run their own tree (eg, an
|> "mwester" branch) cherrypicking and testing new patches in parallel, or
|> for a more regular tracking of the stable tree in git and reporting
|> breakage pretty close to when we broke it.  After we fix whatever these
|> issues are.
| The current urgent need is to catch up to the current development HEAD,
| and return the GTA01 functionality to at least the 2.6.22 kernel level.

Yeah, this is sort of "today's problems".  Then "ongoing problem" -->

| The fundamental problem is rooted in a misunderstanding; the community
| believed (since there was never any indication to the contrary) that the
| GTA01 was being maintained by Openmoko.  The result is that we're now
| faced with fixing stuff that has never worked for the GTA01 since the

My understanding from what I see going on around me is:

~ - All development effort is on GTA02 the last months
~ - We try to avoid breaking GTA01 (hard when we did a big uplevel)
~ - We try to uplevel GTA01 along with GTA02, so it is not "dead" for us
~ - Hey I even did the odd bugfix on GTA01 when we found a common bug
~ - I am not testing against GTA01, don't think Werner is either
~ - Soon we will start a GTA04 kernel effort probably on s3c6400 and I
won't be doing much on s3c24xx
~ - We probably do the right things here all things considered

For these reasons if there is a capable guy or guys for GTA01 kernel, it
seems to me you can be better off running your own tree based off our
24xx 2.6.24/25 stable once we straighten out current breakage.  Or, you
can do that with the tree you have, whatever is best.  Or at a minimum,
we need regression testing help from GTA01 users against our current
trees and we continue to uplevel and fix breakage.  If that happens a
bit more regularly off the same tree, we will get reports like "commit
xyz killed GTA01 sound" that really make figuring it out easier.

| 2.6.24 transition, on top of keeping the GTA02 changes from impacting
| the GTA01 negatively.  No amount of branching or cherrypicking will fix
| that problem, I'm afraid.

These are two separate issues.  We have some breakage against GTA01
today, it is inevitable if we build multiple products off one tree, one
build is heavily worked on and one build isn't, we are going to take a
dump on the other build sometimes.  In addition, we upleveled to 2.6.24
during this.  So OK there are some things to examine there, send a dump
and more info and assistance is possible.

| (Compounding this problem is the current git/OE issue -- it randomly
| fails for a number of folks; until we can figure out what that is and
| get a reliable way to keep the community in sync with the master repos,
| reporting breakages is going to be hit or miss, I'm afraid.  Hopefully
| this git/OE issue will be resolved soon.)

Again, this is an ephemeral issue, I have no idea about bitbake or how
it fetches from git, but it sounds like we can figure it out or even
someone has meddled already and got it working.

| We're going to need a *LOT* of help with the GSM suspend/resume thing.

Sorry, what GSM suspend/resume thing?

| That's the area where I'm most worried, as I think the community lacks
| the necessary documentation from TI, but also the information on how it
| is supposed to work, and how it actually does work for each of the
| several firmware versions out in the field.  I completely understand
| that we can ask OM questions, and you'll try to answer -- but I'm sure
| that the engineers at OM understand that the problem in so many cases is
| that one doesn't have enough information to know what question to ask.
| We'll cross that bridge when we get there; hopefully soon.

Yeah Sean Chiang is the firmware guy, he has it, can recompile it, he
can know how to answer what you want to ask.  When you're ready just
post about it on the kernel list and cc Sean Chiang
<sean_chiang at openmoko.com>.

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org


More information about the openmoko-kernel mailing list