openmoko-kernel Digest, Vol 85, Issue 17
Bilal Mehdi
bilal.mehdi at yahoo.com
Fri Dec 5 08:44:58 CET 2008
Hey i have a silly question...
I was trying to build the kernel but i am getting this error
+ VERSION=
+ '[' -d .git ']'
++ git show --pretty=oneline
++ head -n1
++ cut '-d ' -f1
++ cut -b1-16
+ HEAD=cfea911c6c57eebd
++ git branch
++ grep '^*'
++ cut '-d ' -f2
+ BRANCH=mystable
+ VERSION=-mystable_cfea911c6c57eebd
+ make -j5 ARCH=arm EXTRAVERSION=-mystable_cfea911c6c57eebd
../arm/bin/arm-angstrom-linux-gnueabi-gcc: ../arm/bin/arm-angstrom-linux-gnueabi-gcc: cannot execute binary file
CHK include/linux/version.h
SYMLINK include/asm-arm/arch -> include/asm-arm/arch-s3c2410
make[1]: `include/asm-arm/mach-types.h' is up to date.
CHK include/linux/utsrelease.h
CC scripts/mod/empty.o
/bin/sh: ../arm/bin/arm-angstrom-linux-gnueabi-gcc: cannot execute binary file
make[2]: *** [scripts/mod/empty.o] Error 126
make[1]: *** [scripts/mod] Error 2
make: *** [scripts] Error 2
+ exit 1
Please help me out with this
--- On Fri, 12/5/08, openmoko-kernel-request at lists.openmoko.org <openmoko-kernel-request at lists.openmoko.org> wrote:
From: openmoko-kernel-request at lists.openmoko.org <openmoko-kernel-request at lists.openmoko.org>
Subject: openmoko-kernel Digest, Vol 85, Issue 17
To: openmoko-kernel at lists.openmoko.org
Date: Friday, December 5, 2008, 2:27 AM
Send openmoko-kernel mailing list submissions to
openmoko-kernel at lists.openmoko.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.openmoko.org/mailman/listinfo/openmoko-kernel
or, via email, send a message with subject or body 'help' to
openmoko-kernel-request at lists.openmoko.org
You can reach the person managing the list at
openmoko-kernel-owner at lists.openmoko.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of openmoko-kernel digest..."
Today's Topics:
1. Re:[PATCH] looks like cut/paste error (Andy Green)
2. Re:[PATCH] andy-tracking merge breakage (Werner Almesberger)
3. Re:[PATCH] andy-tracking merge breakage (Andy Green)
4. Re:[PATCH] andy-tracking merge breakage (Werner Almesberger)
5. [PATCH] fix-gta03-gsm-module-startup.patch (Andy Green)
6. Re:Openmoko Bug #2115: White Screen of Death (even without
suspend) (Openmoko Public Trac)
7. [PATCH] fix-s3c-eint-offset-calc-error.patch (Andy Green)
8. Re:Openmoko Bug #2078: glamo-mci.0: ****** insanity timeout
(Openmoko Public Trac)
9. Re:Openmoko Bug #2078: glamo-mci.0: ****** insanity timeout
(Openmoko Public Trac)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Somebody in the thread at some point said:
| On Thu, Dec 04, 2008 at 08:38:39AM +0000, Andy Green wrote:
|> -----BEGIN PGP SIGNED MESSAGE-----
|> Hash: SHA1
|>
|> Somebody in the thread at some point said:
|> | On Thu, Dec 04, 2008 at 01:40:39PM +0700, Sean McNeil wrote:
|> |> The comment leads me to believe there is a cut/paste error on
masking
|> of
|> |> irq.
|> |>
|> |
|> | Hi Sean,
|> |
|> | Yes, I've seen this. I've fixed this along with other minor
things I've
|> | noticed. The code is not pushed yet.
|>
|> Do you want to take Wener's rtc patch as well then and I will rebase
|> when you update balaji-tracking.
|>
|
| Yes, I'll do that.
|
| Will update soon.
Great it just reminds me we are breaking new ground now updating
pending-tracking for the first time, let's hope that isn't too rough.
- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkk3uGoACgkQOjLpvpq7dMq3eACfeNpKjAAtAtNzeiX8y5In34zi
GZgAnimGv34d533Le8mDDZxHUhUS4HH+
=Kfe2
-----END PGP SIGNATURE-----
Andy Green wrote:
> Huh, it can be the new s3c pm stuff from Ben... what does it do, just
> not come back?
Yup, just plays dead. No response to AUX, POWER, or alarm.
Hardware reset works, so we're at least not powered down.
> At least there's the chance for git bisect type attack now.
Yes ! I'm very much looking forward to using that :-)
However, it seems that this time it won't help. We still have too
many build failures in our tree :-( Well, perhaps I can fix these
"transparently" from quilt on top of each commit git-bisect gives
me ...
- Werner
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Somebody in the thread at some point said:
| Andy Green wrote:
|> Huh, it can be the new s3c pm stuff from Ben... what does it do, just
|> not come back?
|
| Yup, just plays dead. No response to AUX, POWER, or alarm.
| Hardware reset works, so we're at least not powered down.
Ha that's funny because that was how the GTA03 resume was acting
yesterday. It can be that the issue is in the new s3c pm stuff and is
common to GTA02 as well then.
|> At least there's the chance for git bisect type attack now.
|
| Yes ! I'm very much looking forward to using that :-)
|
| However, it seems that this time it won't help. We still have too
| many build failures in our tree :-( Well, perhaps I can fix these
| "transparently" from quilt on top of each commit git-bisect gives
| me ...
It's hard now everything lives forever and it takes a long time to
switch build config and back again to confirm what's building on GTA03
as in this last instance didn't trash GTA02 build. Previously I would
just fix it and rewrite the branch like it never existed, now each build
problem will always exist in history, along with the fix subsequently.
- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkk3wFQACgkQOjLpvpq7dMrxbwCeMqPFLBy+8eFea4lpv3ktBJtM
yzUAn1q//102vh/O7znYfQVsRSSrz1g1
=S0zZ
-----END PGP SIGNATURE-----
Andy Green wrote:
> It's hard now everything lives forever and it takes a long time to
> switch build config and back again to confirm what's building on GTA03
> as in this last instance didn't trash GTA02 build.
Hmm, maybe you need a bit more memory and ccache. When everything lives
in some cache, git-checkout is almost instantaneous and builds are
reasonably fast as well, about one minute for a kernel+modules build.
> Previously I would
> just fix it and rewrite the branch like it never existed, now each build
> problem will always exist in history, along with the fix subsequently.
Perhaps we need a little nazibot that only allows commits that
don't break the builds ? :)
Actually, git-bisect could use a "dunno" option in general.
Sometimes, even if the builds are perfect, you hit just some other
showstopper that keeps you from probing the problem you're chasing.
- Werner
Power on is active low for GTA03 GSM module
Signed-off-by: Andy Green <andy at openmoko.com>
---
arch/arm/mach-s3c6410/om-gta03-features.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-s3c6410/om-gta03-features.c
b/arch/arm/mach-s3c6410/om-gta03-features.c
index 32ea4a3..b1b8db5 100644
--- a/arch/arm/mach-s3c6410/om-gta03-features.c
+++ b/arch/arm/mach-s3c6410/om-gta03-features.c
@@ -84,7 +84,7 @@ static void om_gta03_features_pwron_set_on(enum feature
feature)
s3c_gpio_cfgpin(GTA03_GPIO_N_MODEM_RESET, S3C_GPIO_SFN(1));
gpio_direction_output(GTA03_GPIO_N_MODEM_RESET, 0);
- gpio_direction_output(GTA03_GPIO_MODEN_ON, 1);
+ gpio_direction_output(GTA03_GPIO_MODEN_ON, 0);
s3c_gpio_setpull(GTA03_GPIO_MODEN_ON, S3C_GPIO_PULL_NONE);
s3c_gpio_cfgpin(GTA03_GPIO_MODEN_ON, S3C_GPIO_SFN(1));
msleep(1);
@@ -117,7 +117,7 @@ static void om_gta03_features_pwron_set_off(enum feature
feature)
break;
case OM_GTA03_GSM:
/* remove power from WLAN / BT module */
- gpio_direction_output(GTA03_GPIO_MODEN_ON, 0);
+ gpio_direction_output(GTA03_GPIO_MODEN_ON, 1);
s3c_gpio_setpull(GTA03_GPIO_MODEN_ON, S3C_GPIO_PULL_NONE);
s3c_gpio_cfgpin(GTA03_GPIO_MODEN_ON, S3C_GPIO_SFN(1));
break;
#2115: White Screen of Death (even without suspend)
-----------------------------+----------------------------------------------
Reporter: RuiSeabra | Owner: openmoko-kernel
Type: defect | Status: new
Priority: normal | Milestone: FSO
Component: System Software | Version: GTA02v5
Severity: major | Keywords: WSoD white screen death idle
fso gta02v5
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible: always
-----------------------------+----------------------------------------------
Comment(by RuiSeabra):
There's a patch and a test kernel at #1841 which so far looks like it
solved this problem for me.
This (#2115) bug doesn't happen with that kernel. So attached patch would
solve many problems in one.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2115#comment:5>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
There's a bug in calculation of IRQ_EINT_BIT introduced on the test
branch for pm changes for s3c by Ben Dooks fixed in this patch.
There's also a bit of a mystery about how wake gets to wake EINT
set of interrupts, I added a couple of lines that make it work for
EINT4+ but not sure what's meant to be there for EINT0-3.
Still, this gets GTA02 resume working again.
cc: Ben Dooks <ben-linux at fluff.org>
Signed-off-by: Andy Green <andy at openmoko.com>
---
arch/arm/mach-s3c2410/include/mach/irqs.h | 2 +-
arch/arm/plat-s3c24xx/irq-pm.c | 3 +++
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-s3c2410/include/mach/irqs.h
b/arch/arm/mach-s3c2410/include/mach/irqs.h
index 4a82338..1d0629d 100644
--- a/arch/arm/mach-s3c2410/include/mach/irqs.h
+++ b/arch/arm/mach-s3c2410/include/mach/irqs.h
@@ -84,7 +84,7 @@
#define IRQ_EINT22 S3C2410_IRQ(50)
#define IRQ_EINT23 S3C2410_IRQ(51)
-#define IRQ_EINT_BIT(x) ((x) - (IRQ_EINT4 + 4))
+#define IRQ_EINT_BIT(x) ((x) - IRQ_EINT4 + 4)
#define IRQ_EINT(x) (((x) >= 4) ? (IRQ_EINT4 + (x) - 4) : (IRQ_EINT0 +
(x)))
#define IRQ_LCD_FIFO S3C2410_IRQ(52)
diff --git a/arch/arm/plat-s3c24xx/irq-pm.c b/arch/arm/plat-s3c24xx/irq-pm.c
index b7acf1a..87bda52 100644
--- a/arch/arm/plat-s3c24xx/irq-pm.c
+++ b/arch/arm/plat-s3c24xx/irq-pm.c
@@ -34,6 +34,9 @@ int s3c_irq_wake(unsigned int irqno, unsigned int state)
{
unsigned long irqbit = 1 << (irqno - IRQ_EINT0);
+ if (irqno >= IRQ_EINT4)
+ return s3c_irqext_wake(irqno, state);
+
if (!(s3c_irqwake_intallow & irqbit))
return -ENOENT;
#2078: glamo-mci.0: ****** insanity timeout
-----------------------------+----------------------------------------------
Reporter: Sprite_tm | 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 Sprite_tm):
Something like this?
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2078#comment:6>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
#2078: glamo-mci.0: ****** insanity timeout
-----------------------------+----------------------------------------------
Reporter: Sprite_tm | 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):
Yes... thanks for reminding me... I modified it a little for style and
sent it on stable-tracking
http://git.openmoko.org/?p=kernel.git;a=commitdiff;h=7a55cd6f948a33c4452dd99da39e15efe832f2e2
because andy-tracking bases off stable-tracking, it inherits it too.
Thanks for finding the workaround and the patch.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2078#comment:7>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
_______________________________________________
openmoko-kernel mailing list
openmoko-kernel at lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/openmoko-kernel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/openmoko-kernel/attachments/20081204/a942a088/attachment-0001.htm
More information about the openmoko-kernel
mailing list
