RE: [PATCH 4/5] OMAP3xx: Add DMA and IRQ definition for McBSP 1 and 2
#define OMAP24XX_DMA_MS 63 /* S_DMA_62 */ #define OMAP242X_DMA_EXT_DMAREQ5 64 /* S_DMA_63 */ #define OMAP243X_DMA_EXT_DMAREQ6 64 /* S_DMA_63 */ +#define OMAP34XX_DMA_MCBSP1_TX 31 /* S_DMA_30 */ +#define OMAP34XX_DMA_MCBSP1_RX 32 /* S_DMA_31 */ +#define OMAP34XX_DMA_MCBSP2_TX 33 /* S_DMA_32 */ +#define OMAP34XX_DMA_MCBSP2_RX 34 /* S_DMA_33 */ #define OMAP34XX_DMA_EXT_DMAREQ3 64 /* S_DMA_63 */ #define OMAP34XX_DMA_AES2_TX 65 /* S_DMA_64 */ #define OMAP34XX_DMA_AES2_RX 66 /* S_DMA_65 */ What's the point of this patch? Can't you use OMAP24XX_DMA_MCBSP* names? Yes, OMAP24XX_DMA_MCBSP* can be used as they have same values. There is no big difference, but readability. That's the point of this patch. Defining names OMAP34XX_DMA_MCBSP* would let people to write more readable code when specifying things specific for OMAP34XX. I was under the impression that one wouldn't be writing code specific to OMAP34XX given that it would work with zero modifications on a 24XX as in this case. In such a case, would it not make more sense to use the more generic name? That was why I left it that way - anything common to a 24XX and a 34XX gets the OMAP24XX name. __Quote__ OMAP242X_* for 2420 specific names OMAP243X_* for 2430 specific names/names present from 243X onwards OMAP24XX_* for names common to all 24XX, 34XX OMAP34XX_* for 34XX specific names __End_Quote__ One small correction, can we make OMAP34XX as just OMAP3, today we have OMAP3410, 3420, 3430 and OMAP3530, 3503. We also have OMAP2530, but changing OMAP24XX to OMAP2 will be a painful task. Let's just take this up for OMAP3 alone. Regards, Khasim -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/4] Adding OMAP3 EVM support
Hi Kevin, -Original Message- From: Kevin Hilman [mailto:[EMAIL PROTECTED] Sent: Friday, April 25, 2008 4:52 AM To: Syed Mohammed, Khasim Cc: linux-omap@vger.kernel.org; [EMAIL PROTECTED] Subject: Re: [PATCH 1/4] Adding OMAP3 EVM support Minor cosmetic suggestion... As new files are added, can we please leave out full path to the file in the file header? Not only is this unnecessary clutter, after a short amount of time, these are usually wrong as files get renamed, reorganized etc. and the paths rarely get updated. It's best to just leave them out. Will consider this, but sometimes it is also better to have complete path, especially when I pass complete file to some one, I don't have to give path names separately, and they can just get this info from file header. But as you said, it has to be maintained properly :) Do you think we should also consider removing the last line in this paragraph from the GPL header, * This program is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License as published by the * Free Software Foundation; either version 2 of the License, or (at your * option) any later version. * either version 2 of the License, or (at your option) any later version. Any later version will add GPL version 3 to the list. Any thoughts on this? Regards, Khasim -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: framebuffer on 2430sdp, configuration and bug
It's wrapped and you need to add some spaces before %s in all of them :-p In any case, this is only for testing purpose, i think it shouldn't be applied. I don't have lcd working on 3430sdp as well but never look at it. Ya i have seen its wrapped, stupid google webmailer wrapping my precious code! Anyways, patch is just to get the extra debug output, that is actually bothering me. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
pending patch
Hi Tony and Dave,
there's this one pending patch [1]. Do you guys have any comments on that
one?
Author: Felipe Balbi [EMAIL PROTECTED]
Date: Thu Apr 17 17:34:20 2008 +0300
USB: MUSB: Don't ignore disconnect on suspend
As soon as a usb device is disconnect we should
fall into a_wait_bcon state, ignoring disconnect
irq will prevent this behaviour.
Signed-off-by: Felipe Balbi [EMAIL PROTECTED]
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index c5816a2..019898a 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -659,7 +659,7 @@ static irqreturn_t musb_stage0_irq(struct musb *musb, u8
int_usb,
switch (musb-xceiv.state) {
#ifdef CONFIG_USB_OTG
case OTG_STATE_A_SUSPEND:
- musb-ignore_disconnect = 1;
+ musb-ignore_disconnect = 0;
musb_g_reset(musb);
/* FALLTHROUGH */
case OTG_STATE_A_WAIT_BCON: /* OPT TD.4.7-900ms */
[1] http://marc.info/?l=linux-omapm=120844324526642w=2
--
- Balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PRCM_CLKSRC_CTRL bits set incorrectly in omap2_en_osc_ck
Hi Seth,
On Thu, 24 Apr 2008, Seth Forshee wrote:
On my OMAP2430 board I was seeing the contents of DRAM become corrupted
shortly after the kernel started. I tracked this down to
omap2_enable_osc_ck(). I think this function is intended to only clear
the bits in OMAP_AUTOEXTCLKMODE_MASK, but it has the side-effect of
setting all of the other bits in the register. This includes setting
some fields to reserved values.
I'm not 100% sure whether the problem is with omap2_enable_osc_ck() or
prm_rmw_reg_bits() (maybe this should be masking off any bits not set in
mask), but based on what I see elsewhere I think that
omap2_enable_osc_ck() is to blame. If this is the case, the patch below
fixes the problem.
--
From: Seth Forshee [EMAIL PROTECTED]
Subject: [PATCH] ARM: OMAP2: Set PRCM_CLKSRC_CTRL correctly in
omap2_enable_osc_ck
This patch fixes an incorrect use of prm_rmw_reg_bits() in
omap2_enable_osc_ck() which is changing bits in PRCM_CLKSRC_CTRL
that are unrelated to the function it is performing.
Signed-off-by: Seth Forshee [EMAIL PROTECTED]
Indeed, you have found a bug - thanks for the patch!
Acked-by: Paul Walmsley [EMAIL PROTECTED]
---
arch/arm/mach-omap2/clock24xx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clock24xx.c b/arch/arm/mach-omap2/clock24xx.c
index 9b7fd15..e7968e7 100644
--- a/arch/arm/mach-omap2/clock24xx.c
+++ b/arch/arm/mach-omap2/clock24xx.c
@@ -78,7 +78,7 @@ static u32 omap2_get_dpll_rate_24xx(struct clk *tclk)
static int omap2_enable_osc_ck(struct clk *clk)
{
- prm_rmw_reg_bits(OMAP_AUTOEXTCLKMODE_MASK, ~OMAP_AUTOEXTCLKMODE_MASK,
+ prm_rmw_reg_bits(OMAP_AUTOEXTCLKMODE_MASK, 0,
OMAP24XX_PRCM_CLKSRC_CTRL);
return 0;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: framebuffer on 2430sdp, configuration and bug [RESOLVED]
Hi Arun, all I just switched to 2.6.23-omap1, which is booting with framebuffer. Which recent kernel version would you recommend to get down and dirty with Android on the 2430sdp? btw 2.6.24-omap1 is booting for me on 2430sdp, but with not framebuffer, though framebuffer gets registered according to kernel bootlog and is now also usable with my testprogramm, just nothing on the lcd The bug we were seeing: SYNCLOST something in dispc.c irq handler disappeared, looking backwards this may be also related to our recent switch to git for maintaining kernel sources. Maybe our selfhosted sources got tainted by our half-baked patching approaches, so sorry for the noise... Greetings, Gruessla Simon 2008/4/25, arun c [EMAIL PROTECTED]: On Fri, Apr 25, 2008 at 12:35 PM, Simon Braunschmidt [EMAIL PROTECTED] wrote: It's wrapped and you need to add some spaces before %s in all of them :-p In any case, this is only for testing purpose, i think it shouldn't be applied. I don't have lcd working on 3430sdp as well but never look at it. Ya i have seen its wrapped, stupid google webmailer wrapping my precious code! Anyways, patch is just to get the extra debug output, that is actually bothering me. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Hi, For me also v2.6.24-omap1 is not booting on 2430SDP In my case it fails in the panel enable r = fbdev-panel-enable(fbdev-panel); Due to some twl4030 related issue r gets -ve return value and fb initialization fails. twl4030 keypad also not working.. I have checked the hardware with the 2.6.14 kernel from ti site. I think problem is with twl2430 driver Regards, Arun c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH] BQ27000/BQ27200 battery monitoring driver for OMAP34xx
This patch provides the battery monitoring driver to monitor batteries with
BQ27000(HDQ) or BQ27200(i2C) chips.
On omap 3430 sdp BQ27000 battery is tested through the HDQ interface which uses
the earlier posted HDQ and BQ slave drivers.
The BQ27200 support is an extension to the BQ27000 driver as the register set
between BQ27000 and BQ27200 is the same.
Thanks to Klaus.K Pedersen and Mikko Ylinen for the suggestions to add support
for BQ27200 chip as part of
this driver.
Signed-off-by: Madhusudhan Chikkature[EMAIL PROTECTED]
---
drivers/power/Kconfig | 21 +
drivers/power/Makefile |1
drivers/power/bq27x00_battery.c | 556
drivers/w1/slaves/w1_bq27000.c |2
4 files changed, 579 insertions(+), 1 deletion(-)
Index: linux-omap-2.6/drivers/power/bq27x00_battery.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-omap-2.6/drivers/power/bq27x00_battery.c 2008-04-24
10:50:53.631358952 +0530
@@ -0,0 +1,556 @@
+/*
+ * linux/drivers/power/bq27x00_battery.c
+ *
+ * BQ27000/BQ27200 battery driver
+ *
+ * Copyright (C) 2008 Texas Instruments, Inc.
+ *
+ * Author: Texas Instruments
+ *
+ * This package is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
+ * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
+ *
+ */
+#include linux/module.h
+#include linux/param.h
+#include linux/jiffies.h
+#include linux/workqueue.h
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/power_supply.h
+
+#if defined(CONFIG_BATTERY_BQ27000)
+#define BATTERY_BQ27000
+#include ../w1/w1.h
+#endif
+#if defined(CONFIG_BATTERY_BQ27200)
+#define BATTERY_BQ27200
+#include linux/i2c.h
+#endif
+
+#define BQ27x00_REG_TEMP 0x06
+#define BQ27x00_REG_VOLT 0x08
+#define BQ27x00_REG_RSOC 0x0B /* Relative State-of-Charge */
+#define BQ27x00_REG_AI 0x14
+#define BQ27x00_REG_FLAGS 0x0A
+#define HIGH_BYTE(A) ((A) 8)
+
+#if defined(BATTERY_BQ27000)
+extern int w1_bq27000_read(struct device *dev, u8 reg);
+#endif
+
+struct bq27x00_device_info;
+struct bq27x00_access_methods {
+ int (*read)(u8 reg, int *rt_value, int b_single,
+ struct bq27x00_device_info *di);
+};
+
+struct bq27x00_device_info {
+ struct device *dev;
+#if defined(BATTERY_BQ27000)
+ struct device *w1_dev;
+#endif
+#if defined(BATTERY_BQ27200)
+ struct i2c_client *client;
+#endif
+ unsigned long update_time;
+ int voltage_uV;
+ int current_uA;
+ int temp_C;
+ int charge_rsoc;
+ struct bq27x00_access_methods *bus;
+ struct power_supply bat;
+ struct delayed_work monitor_work;
+};
+
+static unsigned int cache_time = 6;
+module_param(cache_time, uint, 0644);
+MODULE_PARM_DESC(cache_time, cache time in milliseconds);
+
+static enum power_supply_property bq27x00_battery_props[] = {
+ POWER_SUPPLY_PROP_PRESENT,
+ POWER_SUPPLY_PROP_VOLTAGE_NOW,
+ POWER_SUPPLY_PROP_CURRENT_NOW,
+ POWER_SUPPLY_PROP_CHARGE_NOW,
+ POWER_SUPPLY_PROP_CAPACITY,
+ POWER_SUPPLY_PROP_TEMP,
+};
+
+static int bq27x00_read(u8 reg, int *rt_value, int b_single,
+ struct bq27x00_device_info *di);
+
+#if defined(BATTERY_BQ27000)
+static int bq27000_battery_probe(struct platform_device *dev);
+static int bq27000_battery_remove(struct platform_device *dev);
+#ifdef CONFIG_PM
+static int bq27000_battery_suspend(struct platform_device *dev,
+ pm_message_t state);
+static int bq27000_battery_resume(struct platform_device *dev);
+#endif
+
+static struct platform_driver bq27000_battery_driver = {
+ .probe = bq27000_battery_probe,
+ .remove = bq27000_battery_remove,
+#ifdef CONFIG_PM
+ .suspend = bq27000_battery_suspend,
+ .resume = bq27000_battery_resume,
+#endif
+ .driver = {
+ .name = bq27000-bat,
+ },
+};
+#endif
+
+#if defined(BATTERY_BQ27200)
+static int bq27200_battery_probe(struct i2c_client *client);
+static int bq27200_battery_remove(struct i2c_client *client);
+static int bq27200_battery_suspend(struct i2c_client *client,
+ pm_message_t mesg);
+static int bq27200_battery_resume(struct i2c_client *client);
+static struct i2c_driver bq27200_battery_driver = {
+ .driver = {
+ .name = bq27200-bat,
+ },
+ .probe = bq27200_battery_probe,
+ .remove = bq27200_battery_remove,
+#ifdef CONFIG_PM
+ .suspend = bq27200_battery_suspend,
+
Re: pending patch
On Friday 25 April 2008, Felipe Balbi wrote:
Hi Tony and Dave,
there's this one pending patch [1]. Do you guys have any comments on that
one?
Author: Felipe Balbi [EMAIL PROTECTED]
Date: Thu Apr 17 17:34:20 2008 +0300
USB: MUSB: Don't ignore disconnect on suspend
As soon as a usb device is disconnect we should
fall into a_wait_bcon state, ignoring disconnect
irq will prevent this behaviour.
If it passes the OTG tests, fine. I don't recall how the
HNP handoff's disconnect signaling is handled ... presumably
it's different from some real disconnect.
Signed-off-by: Felipe Balbi [EMAIL PROTECTED]
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index c5816a2..019898a 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -659,7 +659,7 @@ static irqreturn_t musb_stage0_irq(struct musb *musb, u8
int_usb,
switch (musb-xceiv.state) {
#ifdef CONFIG_USB_OTG
case OTG_STATE_A_SUSPEND:
- musb-ignore_disconnect = 1;
+ musb-ignore_disconnect = 0;
musb_g_reset(musb);
/* FALLTHROUGH */
case OTG_STATE_A_WAIT_BCON: /* OPT TD.4.7-900ms */
[1] http://marc.info/?l=linux-omapm=120844324526642w=2
--
- Balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pending patch
On Fri, Apr 25, 2008 at 02:35:21AM -0700, David Brownell wrote: On Friday 25 April 2008, Felipe Balbi wrote: Hi Tony and Dave, there's this one pending patch [1]. Do you guys have any comments on that one? Author: Felipe Balbi [EMAIL PROTECTED] Date: Thu Apr 17 17:34:20 2008 +0300 USB: MUSB: Don't ignore disconnect on suspend As soon as a usb device is disconnect we should fall into a_wait_bcon state, ignoring disconnect irq will prevent this behaviour. If it passes the OTG tests, fine. I don't recall how the HNP handoff's disconnect signaling is handled ... presumably it's different from some real disconnect. No opt available for now... The problem is that when you ignore disconnect on suspend you only ack the disconnect interrupt after attaching other device. It won't get us too much trouble besides the bit will still set in int_src, but still musb should ack disconnect as soon as it happens, shouldn't it? And right after that start the timer for switching from a_wait_bcon to a_wait_vfall and after that a_idle. But as soon as I have and opt available, I'll try to run this test and report you if I can see any issues with this patch applied. For now, let's keep it as pending so. -- - Balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] BQ27000/BQ27200 battery monitoring driver for OMAP34xx
Some cosmetic comments below
On Fri, 25 Apr 2008 15:01:34 +0530, Madhusudhan Chikkature Rajashekar
[EMAIL PROTECTED] wrote:
This patch provides the battery monitoring driver to monitor batteries
with
BQ27000(HDQ) or BQ27200(i2C) chips.
On omap 3430 sdp BQ27000 battery is tested through the HDQ interface
which
uses the earlier posted HDQ and BQ slave drivers.
The BQ27200 support is an extension to the BQ27000 driver as the register
set between BQ27000 and BQ27200 is the same.
Thanks to Klaus.K Pedersen and Mikko Ylinen for the suggestions to add
support for BQ27200 chip as part of
this driver.
Signed-off-by: Madhusudhan Chikkature[EMAIL PROTECTED]
---
drivers/power/Kconfig | 21 +
drivers/power/Makefile |1
drivers/power/bq27x00_battery.c | 556
drivers/w1/slaves/w1_bq27000.c |2
4 files changed, 579 insertions(+), 1 deletion(-)
Index: linux-omap-2.6/drivers/power/bq27x00_battery.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-omap-2.6/drivers/power/bq27x00_battery.c2008-04-24
10:50:53.631358952 +0530
@@ -0,0 +1,556 @@
+/*
+ * linux/drivers/power/bq27x00_battery.c
+ *
+ * BQ27000/BQ27200 battery driver
+ *
+ * Copyright (C) 2008 Texas Instruments, Inc.
+ *
+ * Author: Texas Instruments
+ *
+ * This package is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
+ * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
+ *
+ */
+#include linux/module.h
+#include linux/param.h
+#include linux/jiffies.h
+#include linux/workqueue.h
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/power_supply.h
+
+#if defined(CONFIG_BATTERY_BQ27000)
Here use ifdef
+#define BATTERY_BQ27000
there's no need to add this one as you can use the Kconfig option
+#include ../w1/w1.h
+#endif
+#if defined(CONFIG_BATTERY_BQ27200)
+#define BATTERY_BQ27200
+#include linux/i2c.h
+#endif
+
+#define BQ27x00_REG_TEMP 0x06
+#define BQ27x00_REG_VOLT 0x08
+#define BQ27x00_REG_RSOC 0x0B /* Relative State-of-Charge */
+#define BQ27x00_REG_AI 0x14
+#define BQ27x00_REG_FLAGS0x0A
+#define HIGH_BYTE(A) ((A) 8)
+
+#if defined(BATTERY_BQ27000)
+extern int w1_bq27000_read(struct device *dev, u8 reg);
+#endif
+
+struct bq27x00_device_info;
+struct bq27x00_access_methods {
+ int (*read)(u8 reg, int *rt_value, int b_single,
+ struct bq27x00_device_info *di);
+};
+
+struct bq27x00_device_info {
+ struct device *dev;
+#if defined(BATTERY_BQ27000)
#ifdef CONFIG_BATERRY_BQ27000
+ struct device *w1_dev;
+#endif
+#if defined(BATTERY_BQ27200)
#ifdef CONFIG_BATTERY_BQ27200
+ struct i2c_client *client;
+#endif
+ unsigned long update_time;
+ int voltage_uV;
+ int current_uA;
+ int temp_C;
+ int charge_rsoc;
+ struct bq27x00_access_methods *bus;
+ struct power_supply bat;
+ struct delayed_work monitor_work;
+};
+
+static unsigned int cache_time = 6;
+module_param(cache_time, uint, 0644);
+MODULE_PARM_DESC(cache_time, cache time in milliseconds);
+
+static enum power_supply_property bq27x00_battery_props[] = {
+ POWER_SUPPLY_PROP_PRESENT,
+ POWER_SUPPLY_PROP_VOLTAGE_NOW,
+ POWER_SUPPLY_PROP_CURRENT_NOW,
+ POWER_SUPPLY_PROP_CHARGE_NOW,
+ POWER_SUPPLY_PROP_CAPACITY,
+ POWER_SUPPLY_PROP_TEMP,
+};
+
+static int bq27x00_read(u8 reg, int *rt_value, int b_single,
+ struct bq27x00_device_info *di);
+
+#if defined(BATTERY_BQ27000)
+static int bq27000_battery_probe(struct platform_device *dev);
+static int bq27000_battery_remove(struct platform_device *dev);
+#ifdef CONFIG_PM
+static int bq27000_battery_suspend(struct platform_device *dev,
+ pm_message_t state);
+static int bq27000_battery_resume(struct platform_device *dev);
+#endif
+
+static struct platform_driver bq27000_battery_driver = {
+ .probe = bq27000_battery_probe,
+ .remove = bq27000_battery_remove,
+#ifdef CONFIG_PM
+ .suspend = bq27000_battery_suspend,
+ .resume = bq27000_battery_resume,
+#endif
+ .driver = {
+ .name = bq27000-bat,
+ },
+};
+#endif
+
+#if defined(BATTERY_BQ27200)
+static int bq27200_battery_probe(struct i2c_client *client);
+static int bq27200_battery_remove(struct i2c_client *client);
+static int bq27200_battery_suspend(struct i2c_client *client,
+
Re: [PATCH 1/1] ARM: OMAP: omap3beagle: register SD interface
On Fri, 25 Apr 2008 09:13:19 +0200, Dirk Behme [EMAIL PROTECTED] wrote: Koen Kooi wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Op 24 apr 2008, om 22:00 heeft Tony Lindgren het volgende geschreven: * Koen Kooi [EMAIL PROTECTED] [080424 12:54]: Op 24 apr 2008, om 02:21 heeft Tony Lindgren het volgende geschreven: Hi, * Koen Kooi [EMAIL PROTECTED] [080423 00:42]: From dac3cdc5952ab39fa7ae0545d43e2daa95329b07 Mon Sep 17 00:00:00 2001 From: Koen Kooi [EMAIL PROTECTED] Date: Wed, 23 Apr 2008 09:38:31 +0200 Subject: [PATCH] omap3beagle: register SD interface Thanks for updating it. I've pushed it now, but I had to apply some parts manually because of recent changes. Can you please check it got applied OK? I compiled an booted latest git and see this: 6TWL4030: TRY attach Slave TWL4030-ID1 on Adapter OMAP I2C adapter [1] 1Unable to handle kernel NULL pointer dereference at virtual address 1pgd = c0004000 1[] *pgd= Internal error: Oops: 5 [#1] Modules linked in: CPU: 0Not tainted (2.6.25-omap1 #11) PC is at __rcu_process_callbacks+0x1ac/0x244 LR is at free_task+0x38/0x40 pc : [c0073924]lr : [c0048b04]psr: 8113 sp : c7c1dda8 ip : c7c085c0 fp : c7c1ddc4 r10: r9 : c0405678 r8 : 0001 r7 : c0400d80 r6 : 0005 r5 : r4 : c040563c r3 : r2 : 0027 r1 : c7c78340 r0 : c7c085c0 Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 00c5387f Table: 80004018 DAC: 0017 Process swapper (pid: 1, stack limit = 0xc7c1c2e0) More bootlogs at http://amethyst.openembedded.net/~koen/beagleboard/beagle-i2c-crash.txt I suspect it's somewhere in i2c, but I have no proof for that. Any quick guesses what might be causing this? Can you try if reverting following helps? http://source.mvista.com/git/gitweb.cgi?p=linux-omap-2.6.git;a=commitdiff;h=38c50a71591628c38206aa402500074a6137a4dc That doesn't seem to make a difference. Just tried recent OMAP git with gcc version 4.2.3 (Sourcery G++ Lite 2008q1-126) (download from today). With configuration in attachment it boots fine: -- cut -- ... USB: No board-specific platform config found i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz i2c_omap i2c_omap.2: bus 2 rev3.12 at 400 kHz i2c_omap i2c_omap.3: bus 3 rev3.12 at 400 kHz TWL4030: TRY attach Slave TWL4030-ID0 on Adapter OMAP I2C adapter [1] TWL4030: TRY attach Slave TWL4030-ID1 on Adapter OMAP I2C adapter [1] TWL4030: TRY attach Slave TWL4030-ID2 on Adapter OMAP I2C adapter [1] TWL4030: TRY attach Slave TWL4030-ID3 on Adapter OMAP I2C adapter [1] but still some problems in twl4030 driver, you see: i2c_omap i2c_omap.1: Transmit overflow Unable to register interrupt subsystem[-5][748] Trying to install chained interrupt handler for IRQ373 Initialized TWL4030 USB module SCSI subsystem initialized NET: Registered protocol family 2 ... -- cut -- No patches applied, only switched from arm-linux- to arm-none-linux-gnueabi- in main Makefile. Dirk -- Best Regards, Felipe Balbi http://felipebalbi.com [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PRCM: 34XX: Add PARENT_CONTROLS_CLOCK flag to dpll5_m2_ck
On Wed, 23 Apr 2008, Högander Jouni wrote: This patch removes following message on dpll5_m2_ck enable and disable: clock.c: Enable for dpll5_m2_ck without enable code clock: clk_disable called on independent clock dpll5_m2_ck which has no enable_reg Signed-off-by: Jouni Hogander [EMAIL PROTECTED] Acked-by: Paul Walmsley [EMAIL PROTECTED] - Paul
RE: [PATCH 4/5] OMAP3xx: Add DMA and IRQ definition for McBSP 1 and 2
-Original Message- From: Tony Lindgren [mailto:[EMAIL PROTECTED] Sent: Friday, April 25, 2008 10:16 PM To: Gadiyar, Anand Cc: Eduardo Valentin; linux-omap@vger.kernel.org; Eduardo Valentin Subject: Re: [PATCH 4/5] OMAP3xx: Add DMA and IRQ definition for McBSP 1 and 2 * Gadiyar, Anand [EMAIL PROTECTED] [080424 22:12]: snip diff --git a/include/asm-arm/arch-omap/dma.h b/include/asm-arm/arch-omap/dma.h index be0431e..270e158 100644 --- a/include/asm-arm/arch-omap/dma.h +++ b/include/asm-arm/arch-omap/dma.h @@ -273,6 +273,10 @@ #define OMAP24XX_DMA_MS 63 /* S_DMA_62 */ #define OMAP242X_DMA_EXT_DMAREQ5 64 /* S_DMA_63 */ #define OMAP243X_DMA_EXT_DMAREQ6 64 /* S_DMA_63 */ +#define OMAP34XX_DMA_MCBSP1_TX 31 /* S_DMA_30 */ +#define OMAP34XX_DMA_MCBSP1_RX 32 /* S_DMA_31 */ +#define OMAP34XX_DMA_MCBSP2_TX 33 /* S_DMA_32 */ +#define OMAP34XX_DMA_MCBSP2_RX 34 /* S_DMA_33 */ #define OMAP34XX_DMA_EXT_DMAREQ3 64 /* S_DMA_63 */ #define OMAP34XX_DMA_AES2_TX 65 /* S_DMA_64 */ #define OMAP34XX_DMA_AES2_RX 66 /* S_DMA_65 */ What's the point of this patch? Can't you use OMAP24XX_DMA_MCBSP* names? diff --git a/include/asm-arm/arch-omap/irqs.h b/include/asm-arm/arch-omap/irqs.h index 15446fd..4e185a8 100644 --- a/include/asm-arm/arch-omap/irqs.h +++ b/include/asm-arm/arch-omap/irqs.h @@ -316,7 +316,11 @@ #define INT_34XX_USIM_IRQ35 #define INT_34XX_WDT3_IRQ36 #define INT_34XX_SPI4_IRQ48 +#define INT_34XX_MCBSP1_IRQ_TX 59 +#define INT_34XX_MCBSP1_IRQ_RX 60 #define INT_34XX_I2C3_IRQ61 +#define INT_34XX_MCBSP2_IRQ_TX 62 +#define INT_34XX_MCBSP2_IRQ_RX 63 #define INT_34XX_PBIAS_IRQ 75 #define INT_34XX_OHCI_IRQ76 #define INT_34XX_EHCI_IRQ77 Ditto with the IRQ lines? @Tony, It would be nice to give people some time to take a look at the patches before they get pushed. Sorry, it seemed like a safe patch to push. I will revert it today. I'm sorry I snapped at you guys earlier - it's just that this DMA code was some of my earliest work in the community and I'm a little passionate about it. This particular request line cleanup went through several iterations and I thought I'd done it reasonably well. Regards, Anand -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PRCM: 34XX: Add PARENT_CONTROLS_CLOCK flag to dpll5_m2_ck
* Paul Walmsley [EMAIL PROTECTED] [080425 10:54]: On Wed, 23 Apr 2008, Högander Jouni wrote: This patch removes following message on dpll5_m2_ck enable and disable: clock.c: Enable for dpll5_m2_ck without enable code clock: clk_disable called on independent clock dpll5_m2_ck which has no enable_reg Signed-off-by: Jouni Hogander [EMAIL PROTECTED] Acked-by: Paul Walmsley [EMAIL PROTECTED] Pushing. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Android on N810 File System Problem
On Fri, Apr 25, 2008 at 07:42:52AM +0200, Dirk Behme wrote: Jonathan, CCing OMAP mailing list, there are more people to help. Jonathan Herriott wrote: Hi, I'm trying to get android installed on an N810. I have successfully installed the kernel, Which kernel (2.6.x, x == ?) do you use on N810? If I remember correctly, with N810 people use an older kernel than the one coming with Android SDK. but I am having major issues with the file system. I followed the tutorial you provided at http://elinux.org/Android_on_OMAP, but I get a segmentation fault when I try to init the kernel. I made sure to use the same android SDK version that was used to patch the kernel. My steps for reproduction are: 1) On my computer, unpack the ramdisk image to a folder. 2) Untar system, dev, and data to the unpacked ramdisk image. 3) Tar up the patched file system and scp it to /opt on the device. Ssh to the device and unpack the file system in /opt 4) Run umask 000 chroot /opt/android /init 5) Receive a segmentation fault. Can you send us the complete segementation fault output? Current linux-omap's head has all the necessary pieces to get n810 working. Touchscreen, keypad, ambient light sensor, led, usb, everything is there. Maybe it's easier to get android's patches on top of current linux-omap ? but anyway, it seems that you don't have android's fs support on your kernel... Are you getting a VFS: could not mount root or something like that? -- Best Regards, Felipe Balbi [EMAIL PROTECTED] http://blog.felipebalbi.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Android on N810 File System Problem
On Fri, 2008-04-25 at 21:36 +0300, ext Felipe Balbi wrote: Current linux-omap's head has all the necessary pieces to get n810 working. Somehow. Touchscreen, keypad, ambient light sensor, led, usb, everything is there. You forget power management. It should partially be redone together with the omap3 work, but stuff like DVFS has a quite different implementation due to the different capabilities of the implementations. Maybe it's easier to get android's patches on top of current linux-omap ? For any practical case where the device has to be used as mobile platform I think it's not an option to use the current l-o. Hopefully it will be in the future. -- Cheers, Igor --- Igor Stoppa Next Generation Software Nokia Devices RD - Helsinki -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Android on N810 File System Problem
On Fri, Apr 25, 2008 at 09:31:42PM +0300, Igor Stoppa wrote: You forget power management. It should partially be redone together with the omap3 work, but stuff like DVFS has a quite different implementation due to the different capabilities of the implementations. no comments. Maybe it's easier to get android's patches on top of current linux-omap ? For any practical case where the device has to be used as mobile platform I think it's not an option to use the current l-o. For some experiments with android is good enough. Hopefully it will be in the future. as soon as people start releasing code... -- Best Regards, Felipe Balbi [EMAIL PROTECTED] http://blog.felipebalbi.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Android on N810 File System Problem
On Fri, 2008-04-25 at 21:52 +0300, ext Felipe Balbi wrote: On Fri, Apr 25, 2008 at 09:31:42PM +0300, Igor Stoppa wrote: You forget power management. It should partially be redone together with the omap3 work, but stuff like DVFS has a quite different implementation due to the different capabilities of the implementations. no comments. since you have a both TRMs, you can check it by yourself: DMA stalling is not available in 2420 Maybe it's easier to get android's patches on top of current linux-omap ? For any practical case where the device has to be used as mobile platform I think it's not an option to use the current l-o. For some experiments with android is good enough. maybe ... i'm not the one experimenting, i'm just saying that it's better to get a bunch of charged batteries, in case one wants to carry the tablet around. Hopefully it will be in the future. as soon as people start releasing code... in case you haven't noticed, there's some major rework ongoing for power management as i said, hopefully in the future also n810 will benefit from it -- Cheers, Igor --- Igor Stoppa Next Generation Software Nokia Devices RD - Helsinki -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] MMC: OMAP: Remove unnecessary extern sdp_mmc_init
From: Francisco Alecrim [EMAIL PROTECTED] Remove unnecessary extern sdp_mmc_init() at board header. New extern hsmmc_init() defined include/asm-arm/arch-omap/hsmmc.h. Signed-off-by: Francisco Alecrim [EMAIL PROTECTED] Acked-by: Carlos Eduardo Aguiar [EMAIL PROTECTED] --- include/asm-arm/arch-omap/board-2430sdp.h |1 - include/asm-arm/arch-omap/board-3430sdp.h |1 - include/asm-arm/arch-omap/board-omap3beagle.h |2 -- 3 files changed, 0 insertions(+), 4 deletions(-) diff --git a/include/asm-arm/arch-omap/board-2430sdp.h b/include/asm-arm/arch-omap/board-2430sdp.h index ad682c5..b308e88 100644 --- a/include/asm-arm/arch-omap/board-2430sdp.h +++ b/include/asm-arm/arch-omap/board-2430sdp.h @@ -39,6 +39,5 @@ /* Function prototypes */ extern void sdp2430_flash_init(void); extern void sdp2430_usb_init(void); -extern void sdp_mmc_init(void); #endif /* __ASM_ARCH_OMAP_2430SDP_H */ diff --git a/include/asm-arm/arch-omap/board-3430sdp.h b/include/asm-arm/arch-omap/board-3430sdp.h index 34e878a..77f8647 100644 --- a/include/asm-arm/arch-omap/board-3430sdp.h +++ b/include/asm-arm/arch-omap/board-3430sdp.h @@ -30,7 +30,6 @@ #define __ASM_ARCH_OMAP_3430SDP_H extern void sdp3430_usb_init(void); -extern void sdp_mmc_init(void); #define DEBUG_BASE 0x0800 /* debug board */ diff --git a/include/asm-arm/arch-omap/board-omap3beagle.h b/include/asm-arm/arch-omap/board-omap3beagle.h index 782e2e5..14db589 100644 --- a/include/asm-arm/arch-omap/board-omap3beagle.h +++ b/include/asm-arm/arch-omap/board-omap3beagle.h @@ -29,8 +29,6 @@ #ifndef __ASM_ARCH_OMAP3_BEAGLE_H #define __ASM_ARCH_OMAP3_BEAGLE_H -extern void sdp_mmc_init(void); - #define TWL4030_IRQNUM INT_34XX_SYS_NIRQ #endif /* __ASM_ARCH_OMAP3_BEAGLE_H */ -- 1.5.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Android on N810 File System Problem
I'm using vanilla Kernel 2.6.21.0 with the patch from
http://android-on-n8xx.googlecode.com/files/linux-2.6.21_rx-34_android-m5-rc14.bz2.
I was told in another thread that I need to use the m3 userspace
files, but when trying to use those, I have the same issue.
I'm assuming you want the strace when running init:
\h:\w\$ strace -f -ff -tt -s 200 /init
04:02:38.896362 execve(/init, [/init], [/* 59 vars */]) = 0
04:02:38.909790 gettid()= 1464
04:02:38.912689 syscall_983045(0xbea0d614, 0, 0x20, 0, 0xbe9ee000,
0xbea0d6d0, 0xbea0d720, 0xf0005, 0xbea0d720, 0, 0x80b8, 0x80b4, 0,
0xbea0d608, 0x17c77, 0x17f2c, 0x6010, 0xbea0d614, 0, 0, 0xc764, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0) = 0
04:02:38.916168 socket(PF_FILE, SOCK_STREAM, 0) = 3
04:02:38.919250 connect(3, {sa_family=AF_FILE,
[EMAIL PROTECTED], 19) = -1 ECONNREFUSED (Connection refused)
04:02:38.923248 close(3)= 0
04:02:38.926208 sigaction(SIGCHLD, {0x8211, [], SA_NOCLDSTOP}, NULL,
0xc0fb8) = 0
04:02:38.929718 umask(0)= 022
04:02:38.932373 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost
isig icanon echo ...}) = 0
04:02:38.936523 dup(1) = 3
04:02:38.939422 write(3, init: HOW ARE YOU GENTLEMEN\n, 28init: HOW
ARE YOU GENTLEMEN
) = 28
04:02:38.943328 close(0)= 0
04:02:38.945983 close(1)= 0
04:02:38.948577 close(2)= 0
04:02:38.951202 open(/dev/null, O_RDWR|O_LARGEFILE) = 0
04:02:38.954345 dup2(0, 1) = 1
04:02:38.956939 dup2(0, 2) = 2
04:02:38.959625 write(3, init: reading config file\n, 26init:
reading config file
) = 26
04:02:38.963592 brk(0) = 0x2
04:02:38.966217 brk(0x2)= 0x2
04:02:38.968994 brk(0x21000)= 0x21000
04:02:38.971832 open(/etc/init.rc, O_RDONLY|O_LARGEFILE) = 4
04:02:38.975006 lseek(4, 0, SEEK_END) = 5746
04:02:38.991088 lseek(4, 0, SEEK_SET) = 0
04:02:38.993286 brk(0x22000)= 0x22000
04:02:38.998413 read(4, ## Global environment setup\n##\nenv {\n
PATH /sbin:/system/sbin:/system/bin\nLD_LIBRARY_PATH /system/lib
\nANDROID_BOOTLOGO 1\nANDROID_ROOT /system\n
ANDROID_ASSETS /system/app\n ANDROID_..., 5746) = 5746
04:02:39.002288 close(4)= 0
04:02:39.003845 brk(0x23000)= 0x23000
04:02:39.005310 mkdir(/proc, 0755)= -1 EEXIST (File exists)
04:02:39.006622 mkdir(/dev, 0755) = -1 EEXIST (File exists)
04:02:39.007843 mkdir(/dev/pts, 0755) = -1 EEXIST (File exists)
04:02:39.009368 mkdir(/sys, 0755) = -1 EEXIST (File exists)
04:02:39.011230 mkdir(/d, 0755) = -1 EEXIST (File exists)
04:02:39.012451 mount(/dev/pts, /dev/pts, devpts, 0, NULL) = -1
EBUSY (Device or resource busy)
04:02:39.017883 mount(/proc, /proc, proc, 0, NULL) = -1 EBUSY
(Device or resource busy)
04:02:39.026428 mount(/sys, /sys, sysfs, 0, NULL) = -1 EBUSY
(Device or resource busy)
04:02:39.033416 mount(/d, /d, debugfs, 0, NULL) = -1 EBUSY
(Device or resource busy)
04:02:39.038238 mount(/tmp, /tmp, tmpfs, 0, NULL) = 0
04:02:39.043457 open(/proc/cmdline, O_RDONLY|O_LARGEFILE) = 4
04:02:39.046417 read(4, root=1f03 rootfstype=jffs2 ro\n, 1023) = 30
04:02:39.048187 close(4)= 0
04:02:39.049346 chmod(/proc/cmdline, 0400) = 0
04:02:39.050689 open(/system_properties, O_RDWR|O_CREAT|O_EXCL|
O_LARGEFILE, 0600) = 4
04:02:39.052368 ftruncate(4, 32768) = 0
04:02:39.053588 open(/system_properties, O_RDONLY|O_LARGEFILE) = 5
04:02:39.056884 unlink(/system_properties) = 0
04:02:39.058624 mmap2(NULL, 32768, PROT_READ|PROT_WRITE, MAP_SHARED,
4, 0) = -1 EINVAL (Invalid argument)
04:02:39.059997 close(5)= 0
04:02:39.061096 close(4)= 0
04:02:39.063110 open(/etc/default.prop, O_RDONLY|O_LARGEFILE) = 4
04:02:39.064422 lseek(4, 0, SEEK_END) = 130
04:02:39.065521 lseek(4, 0, SEEK_SET) = 0
04:02:39.066619 read(4, # default system properties\n# these may be
overridden by /data/local.prop\n\nnet.bt.name = Android\n\n# end
default system properties\n, 130) = 130
04:02:39.069152 close(4)= 0
04:02:39.070251 --- SIGSEGV (Segmentation fault) @ 0 (0) ---
04:02:39.072601 +++ killed by SIGSEGV +++
Process 1464 detached
Thanks,
Jonathan
On Thu, Apr 24, 2008 at 10:42 PM, Dirk Behme [EMAIL PROTECTED] wrote:
Jonathan,
CCing OMAP mailing list, there are more people to help.
Jonathan Herriott wrote:
Hi,
I'm trying to get android installed on an N810. I have successfully
installed the kernel,
Which kernel (2.6.x, x == ?) do you use on N810? If I remember correctly,
with N810 people use an older kernel than the one coming with Android SDK.
but I am having major issues with the file
system. I followed the tutorial you provided at
http://elinux.org/Android_on_OMAP, but I get a segmentation fault when
I try to init the kernel. I made sure to use the same android SDK
version that was used to patch the kernel.
My steps for reproduction are:
1) On my
Re: Android on N810 File System Problem
On Fri, Apr 25, 2008 at 09:47:09PM +0300, Igor Stoppa wrote: On Fri, 2008-04-25 at 21:52 +0300, ext Felipe Balbi wrote: On Fri, Apr 25, 2008 at 09:31:42PM +0300, Igor Stoppa wrote: You forget power management. It should partially be redone together with the omap3 work, but stuff like DVFS has a quite different implementation due to the different capabilities of the implementations. no comments. since you have a both TRMs, you can check it by yourself: DMA stalling is not available in 2420 Maybe it's easier to get android's patches on top of current linux-omap ? For any practical case where the device has to be used as mobile platform I think it's not an option to use the current l-o. For some experiments with android is good enough. maybe ... i'm not the one experimenting, i'm just saying that it's better to get a bunch of charged batteries, in case one wants to carry the tablet around. true Hopefully it will be in the future. as soon as people start releasing code... in case you haven't noticed, there's some major rework ongoing for power management as i said, hopefully in the future also n810 will benefit from it Agreed here. -- Best Regards, Felipe Balbi [EMAIL PROTECTED] http://blog.felipebalbi.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Android on N810 File System Problem
I forgot to ask. Am I required to put the userspace files on separate
storage, or is it okay sticking it on the device's local file system?
On 4/25/08, Jonathan Herriott [EMAIL PROTECTED] wrote:
I'm using vanilla Kernel 2.6.21.0 with the patch from
http://android-on-n8xx.googlecode.com/files/linux-2.6.21_rx-34_android-m5-rc14.bz2.
I was told in another thread that I need to use the m3 userspace
files, but when trying to use those, I have the same issue.
I'm assuming you want the strace when running init:
\h:\w\$ strace -f -ff -tt -s 200 /init
04:02:38.896362 execve(/init, [/init], [/* 59 vars */]) = 0
04:02:38.909790 gettid()= 1464
04:02:38.912689 syscall_983045(0xbea0d614, 0, 0x20, 0, 0xbe9ee000,
0xbea0d6d0, 0xbea0d720, 0xf0005, 0xbea0d720, 0, 0x80b8, 0x80b4, 0,
0xbea0d608, 0x17c77, 0x17f2c, 0x6010, 0xbea0d614, 0, 0, 0xc764, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0) = 0
04:02:38.916168 socket(PF_FILE, SOCK_STREAM, 0) = 3
04:02:38.919250 connect(3, {sa_family=AF_FILE,
[EMAIL PROTECTED], 19) = -1 ECONNREFUSED (Connection refused)
04:02:38.923248 close(3)= 0
04:02:38.926208 sigaction(SIGCHLD, {0x8211, [], SA_NOCLDSTOP}, NULL,
0xc0fb8) = 0
04:02:38.929718 umask(0)= 022
04:02:38.932373 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost
isig icanon echo ...}) = 0
04:02:38.936523 dup(1) = 3
04:02:38.939422 write(3, init: HOW ARE YOU GENTLEMEN\n, 28init: HOW
ARE YOU GENTLEMEN
) = 28
04:02:38.943328 close(0)= 0
04:02:38.945983 close(1)= 0
04:02:38.948577 close(2)= 0
04:02:38.951202 open(/dev/null, O_RDWR|O_LARGEFILE) = 0
04:02:38.954345 dup2(0, 1) = 1
04:02:38.956939 dup2(0, 2) = 2
04:02:38.959625 write(3, init: reading config file\n, 26init:
reading config file
) = 26
04:02:38.963592 brk(0) = 0x2
04:02:38.966217 brk(0x2)= 0x2
04:02:38.968994 brk(0x21000)= 0x21000
04:02:38.971832 open(/etc/init.rc, O_RDONLY|O_LARGEFILE) = 4
04:02:38.975006 lseek(4, 0, SEEK_END) = 5746
04:02:38.991088 lseek(4, 0, SEEK_SET) = 0
04:02:38.993286 brk(0x22000)= 0x22000
04:02:38.998413 read(4, ## Global environment setup\n##\nenv {\n
PATH /sbin:/system/sbin:/system/bin\nLD_LIBRARY_PATH /system/lib
\nANDROID_BOOTLOGO 1\nANDROID_ROOT /system\n
ANDROID_ASSETS /system/app\n ANDROID_..., 5746) = 5746
04:02:39.002288 close(4)= 0
04:02:39.003845 brk(0x23000)= 0x23000
04:02:39.005310 mkdir(/proc, 0755)= -1 EEXIST (File exists)
04:02:39.006622 mkdir(/dev, 0755) = -1 EEXIST (File exists)
04:02:39.007843 mkdir(/dev/pts, 0755) = -1 EEXIST (File exists)
04:02:39.009368 mkdir(/sys, 0755) = -1 EEXIST (File exists)
04:02:39.011230 mkdir(/d, 0755) = -1 EEXIST (File exists)
04:02:39.012451 mount(/dev/pts, /dev/pts, devpts, 0, NULL) = -1
EBUSY (Device or resource busy)
04:02:39.017883 mount(/proc, /proc, proc, 0, NULL) = -1 EBUSY
(Device or resource busy)
04:02:39.026428 mount(/sys, /sys, sysfs, 0, NULL) = -1 EBUSY
(Device or resource busy)
04:02:39.033416 mount(/d, /d, debugfs, 0, NULL) = -1 EBUSY
(Device or resource busy)
04:02:39.038238 mount(/tmp, /tmp, tmpfs, 0, NULL) = 0
04:02:39.043457 open(/proc/cmdline, O_RDONLY|O_LARGEFILE) = 4
04:02:39.046417 read(4, root=1f03 rootfstype=jffs2 ro\n, 1023) = 30
04:02:39.048187 close(4)= 0
04:02:39.049346 chmod(/proc/cmdline, 0400) = 0
04:02:39.050689 open(/system_properties, O_RDWR|O_CREAT|O_EXCL|
O_LARGEFILE, 0600) = 4
04:02:39.052368 ftruncate(4, 32768) = 0
04:02:39.053588 open(/system_properties, O_RDONLY|O_LARGEFILE) = 5
04:02:39.056884 unlink(/system_properties) = 0
04:02:39.058624 mmap2(NULL, 32768, PROT_READ|PROT_WRITE, MAP_SHARED,
4, 0) = -1 EINVAL (Invalid argument)
04:02:39.059997 close(5)= 0
04:02:39.061096 close(4)= 0
04:02:39.063110 open(/etc/default.prop, O_RDONLY|O_LARGEFILE) = 4
04:02:39.064422 lseek(4, 0, SEEK_END) = 130
04:02:39.065521 lseek(4, 0, SEEK_SET) = 0
04:02:39.066619 read(4, # default system properties\n# these may be
overridden by /data/local.prop\n\nnet.bt.name = Android\n\n# end
default system properties\n, 130) = 130
04:02:39.069152 close(4)= 0
04:02:39.070251 --- SIGSEGV (Segmentation fault) @ 0 (0) ---
04:02:39.072601 +++ killed by SIGSEGV +++
Process 1464 detached
Thanks,
Jonathan
On Thu, Apr 24, 2008 at 10:42 PM, Dirk Behme [EMAIL PROTECTED] wrote:
Jonathan,
CCing OMAP mailing list, there are more people to help.
Jonathan Herriott wrote:
Hi,
I'm trying to get android installed on an N810. I have successfully
installed the kernel,
Which kernel (2.6.x, x == ?) do you use on N810? If I remember correctly,
with N810
