* linux-omap git tree updated to v2.6.32-rc1, important changes, please read
@ 2009-09-28 19:04 Tony Lindgren
2009-09-28 21:54 ` Kalle Valo
` (3 more replies)
0 siblings, 4 replies; 25+ messages in thread
From: Tony Lindgren @ 2009-09-28 19:04 UTC (permalink / raw)
To: linux-omap
Hi all,
I've updated our linux-omap tree to v2.6.32-rc1. I've also
added a branch omap-2.6.31 for the old code.
This time I also nuked the remaining omap legacy code we
still had lurking around :) The commits at the end of this
mail describe what I did first as commits, then I merged
everything to be the same as the mainline v2.6.32-rc1.
So currently the linux-omap master branch is:
v2.6.32-rc1 + omap-fixes + ehci + cbus
The new model is that I'll be resetting the linux-omap master
branch to mainline at each -rc, then merge in our various
upstream queues back in again.
Please note that "Remove omap extra version in Makefile"
commit means that you now need to set the ARCH and CROSS_COMPILE
for your compiler.
The good news is that now you can pull in the linux-omap master
branch into any Linux kernel tree without messing up the other
architectures.
Also note that "Remove DEBUG_LL hack to printk" means that
in order to get DEBUG_LL working, you need to patch printk.c
yourself. You can find the patch in the omap-debug branch.
As always, if something important got thrown out, please
send patches against the mainline tree to patch back in
the missing functionality!
Regards,
Tony
f286f075db630e2266ddd011248f4533b55e8f85 REMOVE OMAP LEGACY CODE: Remove omap extra version in Makefile
3dc42bd7663d0b40eeabb5d509f9ab6f969c9ede REMOVE OMAP LEGACY CODE: Remove old documentation
e1483467f256833d406a386ef3ec97f7f5bb3642 REMOVE OMAP LEGACY CODE: Remove arch/arm hacks
9f4eec944af394feb212b48e6a7c3947424edb16 REMOVE OMAP LEGACY CODE: Remove drivers/Makefile hacks
b99dcece4468584eb08f8646477b7f0ca0c27f0f REMOVE OMAP LEGACY CODE: Remove DEBUG_LL hack to printk
9275f8614fd98139ea465455335e06b4ac4de0c4 REMOVE OMAP LEGACY CODE: Remove hacks for booting P2
dc3df234a0187c81ab9c0355ac6b659e25b11b33 REMOVE OMAP LEGACY CODE: Remove drivers/cbus
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read
2009-09-28 19:04 linux-omap git tree updated to v2.6.32-rc1, important changes, please read Tony Lindgren
@ 2009-09-28 21:54 ` Kalle Valo
2009-09-29 14:36 ` green
2009-09-29 10:54 ` Shilimkar, Santosh
` (2 subsequent siblings)
3 siblings, 1 reply; 25+ messages in thread
From: Kalle Valo @ 2009-09-28 21:54 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-omap
Tony Lindgren <tony@atomide.com> writes:
> Please note that "Remove omap extra version in Makefile"
> commit means that you now need to set the ARCH and CROSS_COMPILE
> for your compiler.
A handy tip is to create GNUmakefile containing this:
ARCH=arm
CROSS_COMPILE=arm-linux-
include Makefile
Now you can just write 'make' to compile the kernel as before.
The tip is also here:
http://elinux.org/N800#Simplify_make
--
Kalle Valo
^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: linux-omap git tree updated to v2.6.32-rc1, important changes, please read
2009-09-28 19:04 linux-omap git tree updated to v2.6.32-rc1, important changes, please read Tony Lindgren
2009-09-28 21:54 ` Kalle Valo
@ 2009-09-29 10:54 ` Shilimkar, Santosh
2009-09-30 17:55 ` Tony Lindgren
2009-09-29 17:24 ` Felipe Contreras
2009-09-30 14:07 ` Kevin Hilman
3 siblings, 1 reply; 25+ messages in thread
From: Shilimkar, Santosh @ 2009-09-29 10:54 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-omap
Tony,
> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Tony Lindgren
> Sent: Tuesday, September 29, 2009 12:34 AM
> To: linux-omap@vger.kernel.org
> Subject: linux-omap git tree updated to v2.6.32-rc1, important changes,
> please read
>
> Hi all,
>
> I've updated our linux-omap tree to v2.6.32-rc1. I've also
> added a branch omap-2.6.31 for the old code.
>
> This time I also nuked the remaining omap legacy code we
> still had lurking around :) The commits at the end of this
> mail describe what I did first as commits, then I merged
> everything to be the same as the mainline v2.6.32-rc1.
>
> So currently the linux-omap master branch is:
>
> v2.6.32-rc1 + omap-fixes + ehci + cbus
>
> The new model is that I'll be resetting the linux-omap master
> branch to mainline at each -rc, then merge in our various
> upstream queues back in again.
>
> Please note that "Remove omap extra version in Makefile"
> commit means that you now need to set the ARCH and CROSS_COMPILE
> for your compiler.
>
> The good news is that now you can pull in the linux-omap master
> branch into any Linux kernel tree without messing up the other
> architectures.
>
> Also note that "Remove DEBUG_LL hack to printk" means that
> in order to get DEBUG_LL working, you need to patch printk.c
> yourself. You can find the patch in the omap-debug branch.
>
> As always, if something important got thrown out, please
> send patches against the mainline tree to patch back in
> the missing functionality!
Thanks for fixing the OMAP4 compilation issues. We need below patch to make the kernel boot on OMAP4430 on the latest LO master.
>From d9a22d9f7b68b99aa9607bdab377d998dfe82acd Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Tue, 29 Sep 2009 16:10:46 +0530
Subject: [PATCH] ARM: OMAP4: Allow omap_serial_early_init() for OMAP4430 board
This patch enables omap_serial_early_init() function for OMAP4430
SDP. Without this the bootup would throw opps in omap_serial_init().
Additionally the patch removed the merge issue for the UART4.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/board-4430sdp.c | 4 ++--
arch/arm/mach-omap2/io.c | 2 ++
arch/arm/mach-omap2/serial.c | 10 ----------
3 files changed, 4 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index eb37c40..609a5a4 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -58,6 +58,8 @@ static void __init gic_init_irq(void)
static void __init omap_4430sdp_init_irq(void)
{
+ omap_board_config = sdp4430_config;
+ omap_board_config_size = ARRAY_SIZE(sdp4430_config);
omap2_init_common_hw(NULL, NULL);
#ifdef CONFIG_OMAP_32K_TIMER
omap2_gp_clockevent_set_gptimer(1);
@@ -70,8 +72,6 @@ static void __init omap_4430sdp_init_irq(void)
static void __init omap_4430sdp_init(void)
{
platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
- omap_board_config = sdp4430_config;
- omap_board_config_size = ARRAY_SIZE(sdp4430_config);
omap_serial_init();
}
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index e3a3bad..56be87d 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -302,7 +302,9 @@ void __init omap2_init_common_hw(struct omap_sdrc_params *sdrc_cs0,
pwrdm_init(powerdomains_omap);
clkdm_init(clockdomains_omap, clkdm_pwrdm_autodeps);
omap2_clk_init();
+#endif
omap_serial_early_init();
+#ifndef CONFIG_ARCH_OMAP4
omap_hwmod_late_init();
omap_pm_if_init();
omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index ae21868..54dfeb5 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -109,16 +109,6 @@ static struct plat_serial8250_port serial_platform_data2[] = {
.regshift = 2,
.uartclk = OMAP24XX_BASE_BAUD * 16,
}, {
-#ifdef CONFIG_ARCH_OMAP4
- .membase = OMAP2_IO_ADDRESS(OMAP_UART4_BASE),
- .mapbase = OMAP_UART4_BASE,
- .irq = 70,
- .flags = UPF_BOOT_AUTOCONF,
- .iotype = UPIO_MEM,
- .regshift = 2,
- .uartclk = OMAP24XX_BASE_BAUD * 16,
- }, {
-#endif
.flags = 0
}
};
--
1.5.4.7
Regards,
Santosh
^ permalink raw reply related [flat|nested] 25+ messages in thread
* Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read
2009-09-28 21:54 ` Kalle Valo
@ 2009-09-29 14:36 ` green
0 siblings, 0 replies; 25+ messages in thread
From: green @ 2009-09-29 14:36 UTC (permalink / raw)
To: linux-omap
[-- Attachment #1: Type: text/plain, Size: 589 bytes --]
Kalle Valo wrote at 2009-09-28 16:54 -0500:
> Tony Lindgren <tony@atomide.com> writes:
> > Please note that "Remove omap extra version in Makefile"
> > commit means that you now need to set the ARCH and CROSS_COMPILE
> > for your compiler.
>
> A handy tip is to create GNUmakefile containing this:
>
> ARCH=arm
> CROSS_COMPILE=arm-linux-
> include Makefile
>
> Now you can just write 'make' to compile the kernel as before.
Great tip!
> The tip is also here:
>
> http://elinux.org/N800#Simplify_make
I have been doing that since I noticed it at the above link.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read
2009-09-28 19:04 linux-omap git tree updated to v2.6.32-rc1, important changes, please read Tony Lindgren
2009-09-28 21:54 ` Kalle Valo
2009-09-29 10:54 ` Shilimkar, Santosh
@ 2009-09-29 17:24 ` Felipe Contreras
2009-09-29 18:26 ` Tony Lindgren
2009-09-30 14:07 ` Kevin Hilman
3 siblings, 1 reply; 25+ messages in thread
From: Felipe Contreras @ 2009-09-29 17:24 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-omap
On Mon, Sep 28, 2009 at 10:04 PM, Tony Lindgren <tony@atomide.com> wrote:
> Hi all,
>
> I've updated our linux-omap tree to v2.6.32-rc1. I've also
> added a branch omap-2.6.31 for the old code.
>
> This time I also nuked the remaining omap legacy code we
> still had lurking around :) The commits at the end of this
> mail describe what I did first as commits, then I merged
> everything to be the same as the mainline v2.6.32-rc1.
>
> So currently the linux-omap master branch is:
>
> v2.6.32-rc1 + omap-fixes + ehci + cbus
>
> The new model is that I'll be resetting the linux-omap master
> branch to mainline at each -rc, then merge in our various
> upstream queues back in again.
Excellent! I was wondering why this wasn't being done. I certainly
hope linus' 2.6.32 will work on omap right away.
Anyway, I haven't been able to make 2.6.31 boot on beagleboard, and
other people report similar issues:
http://www.spinics.net/lists/linux-omap/msg17968.html
Have you got 2.6.32-rc1 (+fixes) to boot?
Cheers.
--
Felipe Contreras
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read
2009-09-29 17:24 ` Felipe Contreras
@ 2009-09-29 18:26 ` Tony Lindgren
2009-09-29 19:20 ` Alexander Shishkin
2009-09-30 15:53 ` Roger Quadros
0 siblings, 2 replies; 25+ messages in thread
From: Tony Lindgren @ 2009-09-29 18:26 UTC (permalink / raw)
To: Felipe Contreras; +Cc: linux-omap
* Felipe Contreras <felipe.contreras@gmail.com> [090929 10:24]:
> On Mon, Sep 28, 2009 at 10:04 PM, Tony Lindgren <tony@atomide.com> wrote:
> > Hi all,
> >
> > I've updated our linux-omap tree to v2.6.32-rc1. I've also
> > added a branch omap-2.6.31 for the old code.
> >
> > This time I also nuked the remaining omap legacy code we
> > still had lurking around :) The commits at the end of this
> > mail describe what I did first as commits, then I merged
> > everything to be the same as the mainline v2.6.32-rc1.
> >
> > So currently the linux-omap master branch is:
> >
> > v2.6.32-rc1 + omap-fixes + ehci + cbus
> >
> > The new model is that I'll be resetting the linux-omap master
> > branch to mainline at each -rc, then merge in our various
> > upstream queues back in again.
>
> Excellent! I was wondering why this wasn't being done. I certainly
> hope linus' 2.6.32 will work on omap right away.
Yeah, let's hope Tomi gets in the DSS2 code too.
> Anyway, I haven't been able to make 2.6.31 boot on beagleboard, and
> other people report similar issues:
> http://www.spinics.net/lists/linux-omap/msg17968.html
>
> Have you got 2.6.32-rc1 (+fixes) to boot?
Hmm, looks like it's musb again. This is what I get on my
overo after applying the DEBUG_LL hack from omap-debug branch:
<3>musb_hdrc musb_hdrc: musb_init_controller failed with status -19
<1>Unable to handle kernel NULL pointer dereference at virtual address 00000000
<1>pgd = c0004000
<1>[00000000] *pgd=00000000
Internal error: Oops: 5 [#1]
<d>Modules linked in:
CPU: 0 Not tainted (2.6.32-rc2-05967-gd350540-dirty #892)
PC is at musb_free+0x68/0xb8
LR is at musb_free+0x34/0xb8
pc : [<c028a160>] lr : [<c028a12c>] psr: a0000013
sp : c781fe50 ip : 00000064 fp : 00000000
r10: 00000000 r9 : 00000000 r8 : c0557bc0
r7 : c7811000 r6 : c78110e8 r5 : c78110e8 r4 : 00000000
r3 : 00000000 r2 : 00000001 r1 : c04c95b6 r0 : ffffffed
Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c5387d Table: 80004019 DAC: 00000017
Process swapper (pid: 1, stack limit = 0xc781e2f0)
Stack: (0xc781fe50 to 0xc7820000)
fe40: ffffffed 00000000 c78110e8 c001e8f8
fe60: c781fea4 c7804180 00000000 c7804184 c0533dc8 c0533dd0 0000005c d80ab000
fe80: c0533dac c7811190 00000000 c781fedc c0114ad8 c7806850 c0546248 c06d74e0
fea0: 00000000 c03cd5c8 00000000 c781ff00 c78b8de0 c0114cbc c78b8d80 c781ff00
fec0: c78b8de0 c0114864 c78b8d80 c781ff00 c78b8de0 c011493c c781ff00 c78b8de0
fee0: c78b8d80 00000000 c781ff00 c78b8de0 c787a210 00000001 00000000 c01157b4
ff00: c787a210 00000000 00000000 c0533dd0 c0533dd0 c055df04 c7873600 c0557bc0
ff20: 00000000 00000000 00000000 c0210b7c c0533dd0 c020fbd4 c0533dd0 c0533e04
ff40: c055df04 c7873600 c0557bc0 c020fce0 00000000 c020fc80 c055df04 c020f420
ff60: c7802d08 c787b240 c0026dd4 00000080 c055df04 c020ed38 c03f14f4 c03f14f4
ff80: c7820000 c0026dd4 c055def0 c055df04 00000000 00000000 00000000 c020ffb0
ffa0: c0026dd4 c055def0 c001dca0 00000000 00000000 c0210f70 c0026dd4 00000000
ffc0: c001dca0 c002d2b4 00000031 00000000 00000000 00000192 00000000 c0026dd4
ffe0: 00000000 00000000 00000000 c0008578 00000000 c002ee10 817fdf10 00bbff00
[<c028a160>] (musb_free+0x68/0xb8) from [<c001e8f8>] (musb_probe+0xab8/0xbb4)
[<c001e8f8>] (musb_probe+0xab8/0xbb4) from [<c0210b7c>] (platform_drv_probe+0x1)
[<c0210b7c>] (platform_drv_probe+0x18/0x1c) from [<c020fbd4>] (driver_probe_dev)
[<c020fbd4>] (driver_probe_device+0xa0/0x14c) from [<c020fce0>] (__driver_attac)
[<c020fce0>] (__driver_attach+0x60/0x84) from [<c020f420>] (bus_for_each_dev+0x)
[<c020f420>] (bus_for_each_dev+0x44/0x74) from [<c020ed38>] (bus_add_driver+0xf)
[<c020ed38>] (bus_add_driver+0xf4/0x278) from [<c020ffb0>] (driver_register+0xa)
[<c020ffb0>] (driver_register+0xa8/0x130) from [<c0210f70>] (platform_driver_pr)
[<c0210f70>] (platform_driver_probe+0x10/0x88) from [<c002d2b4>] (do_one_initca)
[<c002d2b4>] (do_one_initcall+0x5c/0x1b4) from [<c0008578>] (kernel_init+0x90/0)
[<c0008578>] (kernel_init+0x90/0x10c) from [<c002ee10>] (kernel_thread_exit+0x0)
Code: e1a01005 ebf80722 e595309c e3a04000 (e5930000)
<4>---[ end trace 1b75b31a2719ed1c ]---
<0>Kernel panic - not syncing: Attempted to kill init!
After disabling musb, it boots further but can't mount root on the MMC:
...
<4>regulator_init_complete: incomplete constraints, leaving VUSB1V8 on
regulator_init_complete: incomplete constraints, leaving VUSB1V8 on
<4>regulator_init_complete: incomplete constraints, leaving VUSB1V5 on
regulator_init_complete: incomplete constraints, leaving VUSB1V5 on
<4>regulator_init_complete: incomplete constraints, leaving VMMC1 on
regulator_init_complete: incomplete constraints, leaving VMMC1 on
<6>twl4030_rtc twl4030_rtc: setting system clock to 2000-01-01 00:00:00 UTC (94)
twl4030_rtc twl4030_rtc: setting system clock to 2000-01-01 00:00:00 UTC (94668)
<6>Waiting for root device /dev/mmcblk0p2...
Waiting for root device /dev/mmcblk0p2...
What are you getting with DEBUG_LL enabled and the associated patch applied
from omap-debug branch?
Regards,
Tony
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read
2009-09-29 18:26 ` Tony Lindgren
@ 2009-09-29 19:20 ` Alexander Shishkin
2009-09-29 19:26 ` Aguirre Rodriguez, Sergio Alberto
2009-09-29 19:30 ` Tony Lindgren
2009-09-30 15:53 ` Roger Quadros
1 sibling, 2 replies; 25+ messages in thread
From: Alexander Shishkin @ 2009-09-29 19:20 UTC (permalink / raw)
To: Tony Lindgren; +Cc: Felipe Contreras, linux-omap
2009/9/29 Tony Lindgren <tony@atomide.com>:
> * Felipe Contreras <felipe.contreras@gmail.com> [090929 10:24]:
>> On Mon, Sep 28, 2009 at 10:04 PM, Tony Lindgren <tony@atomide.com> wrote:
>> > Hi all,
>> >
>> > I've updated our linux-omap tree to v2.6.32-rc1. I've also
>> > added a branch omap-2.6.31 for the old code.
>> >
>> > This time I also nuked the remaining omap legacy code we
>> > still had lurking around :) The commits at the end of this
>> > mail describe what I did first as commits, then I merged
>> > everything to be the same as the mainline v2.6.32-rc1.
>> >
>> > So currently the linux-omap master branch is:
>> >
>> > v2.6.32-rc1 + omap-fixes + ehci + cbus
>> >
>> > The new model is that I'll be resetting the linux-omap master
>> > branch to mainline at each -rc, then merge in our various
>> > upstream queues back in again.
>>
>> Excellent! I was wondering why this wasn't being done. I certainly
>> hope linus' 2.6.32 will work on omap right away.
>
> Yeah, let's hope Tomi gets in the DSS2 code too.
>
>> Anyway, I haven't been able to make 2.6.31 boot on beagleboard, and
>> other people report similar issues:
>> http://www.spinics.net/lists/linux-omap/msg17968.html
>>
>> Have you got 2.6.32-rc1 (+fixes) to boot?
>
> Hmm, looks like it's musb again. This is what I get on my
> overo after applying the DEBUG_LL hack from omap-debug branch:
>
> <3>musb_hdrc musb_hdrc: musb_init_controller failed with status -19
> <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000
> <1>pgd = c0004000
> <1>[00000000] *pgd=00000000
> Internal error: Oops: 5 [#1]
> <d>Modules linked in:
> CPU: 0 Not tainted (2.6.32-rc2-05967-gd350540-dirty #892)
> PC is at musb_free+0x68/0xb8
> LR is at musb_free+0x34/0xb8
> pc : [<c028a160>] lr : [<c028a12c>] psr: a0000013
> sp : c781fe50 ip : 00000064 fp : 00000000
> r10: 00000000 r9 : 00000000 r8 : c0557bc0
> r7 : c7811000 r6 : c78110e8 r5 : c78110e8 r4 : 00000000
> r3 : 00000000 r2 : 00000001 r1 : c04c95b6 r0 : ffffffed
> Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
> Control: 10c5387d Table: 80004019 DAC: 00000017
> Process swapper (pid: 1, stack limit = 0xc781e2f0)
> Stack: (0xc781fe50 to 0xc7820000)
> fe40: ffffffed 00000000 c78110e8 c001e8f8
> fe60: c781fea4 c7804180 00000000 c7804184 c0533dc8 c0533dd0 0000005c d80ab000
> fe80: c0533dac c7811190 00000000 c781fedc c0114ad8 c7806850 c0546248 c06d74e0
> fea0: 00000000 c03cd5c8 00000000 c781ff00 c78b8de0 c0114cbc c78b8d80 c781ff00
> fec0: c78b8de0 c0114864 c78b8d80 c781ff00 c78b8de0 c011493c c781ff00 c78b8de0
> fee0: c78b8d80 00000000 c781ff00 c78b8de0 c787a210 00000001 00000000 c01157b4
> ff00: c787a210 00000000 00000000 c0533dd0 c0533dd0 c055df04 c7873600 c0557bc0
> ff20: 00000000 00000000 00000000 c0210b7c c0533dd0 c020fbd4 c0533dd0 c0533e04
> ff40: c055df04 c7873600 c0557bc0 c020fce0 00000000 c020fc80 c055df04 c020f420
> ff60: c7802d08 c787b240 c0026dd4 00000080 c055df04 c020ed38 c03f14f4 c03f14f4
> ff80: c7820000 c0026dd4 c055def0 c055df04 00000000 00000000 00000000 c020ffb0
> ffa0: c0026dd4 c055def0 c001dca0 00000000 00000000 c0210f70 c0026dd4 00000000
> ffc0: c001dca0 c002d2b4 00000031 00000000 00000000 00000192 00000000 c0026dd4
> ffe0: 00000000 00000000 00000000 c0008578 00000000 c002ee10 817fdf10 00bbff00
> [<c028a160>] (musb_free+0x68/0xb8) from [<c001e8f8>] (musb_probe+0xab8/0xbb4)
> [<c001e8f8>] (musb_probe+0xab8/0xbb4) from [<c0210b7c>] (platform_drv_probe+0x1)
> [<c0210b7c>] (platform_drv_probe+0x18/0x1c) from [<c020fbd4>] (driver_probe_dev)
> [<c020fbd4>] (driver_probe_device+0xa0/0x14c) from [<c020fce0>] (__driver_attac)
> [<c020fce0>] (__driver_attach+0x60/0x84) from [<c020f420>] (bus_for_each_dev+0x)
> [<c020f420>] (bus_for_each_dev+0x44/0x74) from [<c020ed38>] (bus_add_driver+0xf)
> [<c020ed38>] (bus_add_driver+0xf4/0x278) from [<c020ffb0>] (driver_register+0xa)
> [<c020ffb0>] (driver_register+0xa8/0x130) from [<c0210f70>] (platform_driver_pr)
> [<c0210f70>] (platform_driver_probe+0x10/0x88) from [<c002d2b4>] (do_one_initca)
> [<c002d2b4>] (do_one_initcall+0x5c/0x1b4) from [<c0008578>] (kernel_init+0x90/0)
> [<c0008578>] (kernel_init+0x90/0x10c) from [<c002ee10>] (kernel_thread_exit+0x0)
> Code: e1a01005 ebf80722 e595309c e3a04000 (e5930000)
> <4>---[ end trace 1b75b31a2719ed1c ]---
> <0>Kernel panic - not syncing: Attempted to kill init!
>
> After disabling musb, it boots further but can't mount root on the MMC:
>
> ...
> <4>regulator_init_complete: incomplete constraints, leaving VUSB1V8 on
> regulator_init_complete: incomplete constraints, leaving VUSB1V8 on
> <4>regulator_init_complete: incomplete constraints, leaving VUSB1V5 on
> regulator_init_complete: incomplete constraints, leaving VUSB1V5 on
> <4>regulator_init_complete: incomplete constraints, leaving VMMC1 on
> regulator_init_complete: incomplete constraints, leaving VMMC1 on
> <6>twl4030_rtc twl4030_rtc: setting system clock to 2000-01-01 00:00:00 UTC (94)
> twl4030_rtc twl4030_rtc: setting system clock to 2000-01-01 00:00:00 UTC (94668)
> <6>Waiting for root device /dev/mmcblk0p2...
> Waiting for root device /dev/mmcblk0p2...
>
> What are you getting with DEBUG_LL enabled and the associated patch applied
> from omap-debug branch?
MUSB enabled gives me the same backtrace. When I disable it, I get
(this is beagle B6):
<1>Unable to handle kernel NULL pointer dereference at virtual address 00000000
<1>pgd = c0004000
<1>[00000000] *pgd=00000000
Internal error: Oops: 805 [#1]
<d>Modules linked in:
CPU: 0 Tainted: G W (2.6.32-rc2-05968-g11ddc16 #7)
PC is at __mutex_lock_slowpath+0xe0/0x218
LR is at __mutex_lock_slowpath+0xcc/0x218
pc : [<c02967bc>] lr : [<c02967a8>] psr: 40000093
sp : c7819e80 ip : 11111111 fp : c6d2e824
r10: c6d2e800 r9 : c6d2e800 r8 : c7886c24
r7 : c7817a40 r6 : 60000013 r5 : c7886c20 r4 : c7886c20
r3 : 00000000 r2 : c7818000 r1 : c7819e80 r0 : c7886c20
Flags: nZcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c5387d Table: 80004019 DAC: 00000017
Process swapper (pid: 1, stack limit = 0xc78182e8)
Stack: (0xc7819e80 to 0xc781a000)
9e80: c7886c24 00000000 11111111 c7819e80 c6d2fd00 c7886c20 c6d2e800 00000000
9ea0: c7886c20 c7886c00 c6d2e800 c6d2e800 c6d2e824 c0296900 c6d2e800 c0197afc
9ec0: c7886c00 00000000 c7886e68 00000000 c6d2e800 c0198f90 c6d369c8 00000000
9ee0: c7819f00 c6d36968 c7810518 69000001 7265746e 006c616e 00000000 00000000
9f00: c7810518 c0387d50 c0387d50 c03a0504 c03a0504 c03a4800 00000000 00000000
9f20: 00000000 c019b37c c0387d50 c01c009c c03a0504 c01bf0d4 00000000 c0387d50
9f40: c0387d84 c03a0504 c7819f60 c01bf204 00000000 c01bf1a4 c03a0504 c01be954
9f60: c7803af8 c7845970 c03a4800 c0022890 c03a0504 c03a0504 c6d30cc0 c01be1f8
9f80: c0315ab2 c00187a0 c6d30d40 c0022890 c0022948 c03a0504 00000000 00000000
9fa0: 00000000 c01bf508 c0022890 c0022948 c00187fc 00000000 00000000 c00272b4
9fc0: 00000000 00000192 c038ba20 00000000 00000000 c0022890 c0022948 00000000
9fe0: 00000000 c0008584 00000000 00000000 00000000 c0028d80 853bee50 007b4fa4
[<c02967bc>] (__mutex_lock_slowpath+0xe0/0x218) from [<c0296900>]
(mutex_lock+0xc/0x1c)
[<c0296900>] (mutex_lock+0xc/0x1c) from [<c0197afc>]
(set_fb_fix+0x30/0xbc)
[<c0197afc>] (set_fb_fix+0x30/0xbc) from [<c0198f90>]
(omapfb_do_probe+0x404/0x858)
[<c0198f90>] (omapfb_do_probe+0x404/0x858) from [<c019b37c>]
(omap3beagle_panel_probe+0x10/0x20)
[<c019b37c>] (omap3beagle_panel_probe+0x10/0x20) from [<c01c009c>]
(platform_drv_probe+0x1c/0x24)
[<c01c009c>] (platform_drv_probe+0x1c/0x24) from [<c01bf0d4>]
(driver_probe_device+0xa4/0x174)
[<c01bf0d4>] (driver_probe_device+0xa4/0x174) from [<c01bf204>]
(__driver_attach+0x60/0x84)
[<c01bf204>] (__driver_attach+0x60/0x84) from [<c01be954>]
(bus_for_each_dev+0x4c/0x8c)
[<c01be954>] (bus_for_each_dev+0x4c/0x8c) from [<c01be1f8>]
(bus_add_driver+0xa0/0x218)
[<c01be1f8>] (bus_add_driver+0xa0/0x218) from [<c01bf508>]
(driver_register+0xbc/0x148)
[<c01bf508>] (driver_register+0xbc/0x148) from [<c00272b4>]
(do_one_initcall+0x5c/0x1bc)
[<c00272b4>] (do_one_initcall+0x5c/0x1bc) from [<c0008584>]
(kernel_init+0x94/0x110)
[<c0008584>] (kernel_init+0x94/0x110) from [<c0028d80>]
(kernel_thread_exit+0x0/0x8)
Code: e2858004 e585d008 e58d8000 e58d3004 (e583d000)
<4>---[ end trace da227214a82491b8 ]---
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: linux-omap git tree updated to v2.6.32-rc1, important changes, please read
2009-09-29 19:20 ` Alexander Shishkin
@ 2009-09-29 19:26 ` Aguirre Rodriguez, Sergio Alberto
2009-09-29 19:42 ` Alexander Shishkin
2009-09-29 19:30 ` Tony Lindgren
1 sibling, 1 reply; 25+ messages in thread
From: Aguirre Rodriguez, Sergio Alberto @ 2009-09-29 19:26 UTC (permalink / raw)
To: Alexander Shishkin, Tony Lindgren; +Cc: Felipe Contreras, linux-omap
[-- Attachment #1: Type: text/plain, Size: 3299 bytes --]
From: linux-omap-owner@vger.kernel.org [linux-omap-owner@vger.kernel.org] On Behalf Of Alexander Shishkin [virtuoso@slind.org]
Sent: Tuesday, September 29, 2009 2:20 PM
> 2009/9/29 Tony Lindgren <tony@atomide.com>:
> > * Felipe Contreras <felipe.contreras@gmail.com> [090929 10:24]:
> >> On Mon, Sep 28, 2009 at 10:04 PM, Tony Lindgren <tony@atomide.com> wrote:
> >> > Hi all,
> >> >
> >> > I've updated our linux-omap tree to v2.6.32-rc1. I've also
> >> > added a branch omap-2.6.31 for the old code.
> >> >
> >> > This time I also nuked the remaining omap legacy code we
> >> > still had lurking around :) The commits at the end of this
> >> > mail describe what I did first as commits, then I merged
> >> > everything to be the same as the mainline v2.6.32-rc1.
> >> >
> >> > So currently the linux-omap master branch is:
> >> >
> >> > v2.6.32-rc1 + omap-fixes + ehci + cbus
> >> >
> >> > The new model is that I'll be resetting the linux-omap master
> >> > branch to mainline at each -rc, then merge in our various
> >> > upstream queues back in again.
> >>
> >> Excellent! I was wondering why this wasn't being done. I certainly
> >> hope linus' 2.6.32 will work on omap right away.
> >
> > Yeah, let's hope Tomi gets in the DSS2 code too.
> >
> >> Anyway, I haven't been able to make 2.6.31 boot on beagleboard, and
> >> other people report similar issues:
> >> http://www.spinics.net/lists/linux-omap/msg17968.html
> >>
> >> Have you got 2.6.32-rc1 (+fixes) to boot?
> >
> > Hmm, looks like it's musb again. This is what I get on my
> > overo after applying the DEBUG_LL hack from omap-debug branch:
> >
> > <3>musb_hdrc musb_hdrc: musb_init_controller failed with status -19
> > <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000
> > <1>pgd = c0004000
> > <1>[00000000] *pgd=00000000
> > Internal error: Oops: 5 [#1]
> > <d>Modules linked in:
> > CPU: 0 Not tainted (2.6.32-rc2-05967-gd350540-dirty #892)
> > PC is at musb_free+0x68/0xb8
> > LR is at musb_free+0x34/0xb8
<snip>
> >
> > After disabling musb, it boots further but can't mount root on the MMC:
> >
> > ...
> > <4>regulator_init_complete: incomplete constraints, leaving VUSB1V8 on
> > regulator_init_complete: incomplete constraints, leaving VUSB1V8 on
> > <4>regulator_init_complete: incomplete constraints, leaving VUSB1V5 on
> > regulator_init_complete: incomplete constraints, leaving VUSB1V5 on
> > <4>regulator_init_complete: incomplete constraints, leaving VMMC1 on
> > regulator_init_complete: incomplete constraints, leaving VMMC1 on
> > <6>twl4030_rtc twl4030_rtc: setting system clock to 2000-01-01 00:00:00 UTC (94)
> > twl4030_rtc twl4030_rtc: setting system clock to 2000-01-01 00:00:00 UTC (94668)
> > <6>Waiting for root device /dev/mmcblk0p2...
> > Waiting for root device /dev/mmcblk0p2...
> >
> > What are you getting with DEBUG_LL enabled and the associated patch applied
> > from omap-debug branch?
> MUSB enabled gives me the same backtrace. When I disable it, I get
> (this is beagle B6):
>
> <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000
> <1>pgd = c0004000
> <1>[00000000] *pgd=00000000
<snip>
Hi,
Can you please try attached patch?
Regards,
Sergio
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-omapfb-Condition-mutex-acquisition.patch --]
[-- Type: text/x-patch; name="0001-omapfb-Condition-mutex-acquisition.patch", Size: 2493 bytes --]
From bba2d89ea45ec0359dec6fe21c1756ad3406e347 Mon Sep 17 00:00:00 2001
From: Sergio Aguirre <saaguirre@ti.com>
Date: Tue, 29 Sep 2009 07:44:19 -0500
Subject: [PATCH] omapfb: Condition mutex acquisition
Acquiring mutex before framebuffer registration doesn't make sense,
As there's no danger of external access to the memory related fields.
NOTE: PLEASE REVIEW! I'M NOT AN EXPERT ON THIS.
Signed-off-by: Sergio Aguirre <saaguirre@ti.com>
---
drivers/video/omap/omapfb_main.c | 22 ++++++++++++++--------
1 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/video/omap/omapfb_main.c b/drivers/video/omap/omapfb_main.c
index 125e605..0d0c8c8 100644
--- a/drivers/video/omap/omapfb_main.c
+++ b/drivers/video/omap/omapfb_main.c
@@ -393,7 +393,7 @@ static void omapfb_sync(struct fb_info *fbi)
* Set fb_info.fix fields and also updates fbdev.
* When calling this fb_info.var must be set up already.
*/
-static void set_fb_fix(struct fb_info *fbi)
+static void set_fb_fix(struct fb_info *fbi, int from_init)
{
struct fb_fix_screeninfo *fix = &fbi->fix;
struct fb_var_screeninfo *var = &fbi->var;
@@ -403,10 +403,16 @@ static void set_fb_fix(struct fb_info *fbi)
rg = &plane->fbdev->mem_desc.region[plane->idx];
fbi->screen_base = rg->vaddr;
- mutex_lock(&fbi->mm_lock);
- fix->smem_start = rg->paddr;
- fix->smem_len = rg->size;
- mutex_unlock(&fbi->mm_lock);
+
+ if (!from_init) {
+ mutex_lock(&fbi->mm_lock);
+ fix->smem_start = rg->paddr;
+ fix->smem_len = rg->size;
+ mutex_unlock(&fbi->mm_lock);
+ } else {
+ fix->smem_start = rg->paddr;
+ fix->smem_len = rg->size;
+ }
fix->type = FB_TYPE_PACKED_PIXELS;
bpp = var->bits_per_pixel;
@@ -704,7 +710,7 @@ static int omapfb_set_par(struct fb_info *fbi)
int r = 0;
omapfb_rqueue_lock(fbdev);
- set_fb_fix(fbi);
+ set_fb_fix(fbi, 0);
r = ctrl_change_mode(fbi);
omapfb_rqueue_unlock(fbdev);
@@ -904,7 +910,7 @@ static int omapfb_setup_mem(struct fb_info *fbi, struct omapfb_mem_info *mi)
if (old_size != size) {
if (size) {
memcpy(&fbi->var, new_var, sizeof(fbi->var));
- set_fb_fix(fbi);
+ set_fb_fix(fbi, 0);
} else {
/*
* Set these explicitly to indicate that the
@@ -1504,7 +1510,7 @@ static int fbinfo_init(struct omapfb_device *fbdev, struct fb_info *info)
var->bits_per_pixel = fbdev->panel->bpp;
set_fb_var(info, var);
- set_fb_fix(info);
+ set_fb_fix(info, 1);
r = fb_alloc_cmap(&info->cmap, 16, 0);
if (r != 0)
--
1.6.0.4
^ permalink raw reply related [flat|nested] 25+ messages in thread
* Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read
2009-09-29 19:20 ` Alexander Shishkin
2009-09-29 19:26 ` Aguirre Rodriguez, Sergio Alberto
@ 2009-09-29 19:30 ` Tony Lindgren
2009-09-29 19:41 ` Alexander Shishkin
1 sibling, 1 reply; 25+ messages in thread
From: Tony Lindgren @ 2009-09-29 19:30 UTC (permalink / raw)
To: Alexander Shishkin; +Cc: Felipe Contreras, linux-omap
* Alexander Shishkin <virtuoso@slind.org> [090929 12:20]:
> 2009/9/29 Tony Lindgren <tony@atomide.com>:
> > * Felipe Contreras <felipe.contreras@gmail.com> [090929 10:24]:
> >> On Mon, Sep 28, 2009 at 10:04 PM, Tony Lindgren <tony@atomide.com> wrote:
> >> > Hi all,
> >> >
> >> > I've updated our linux-omap tree to v2.6.32-rc1. I've also
> >> > added a branch omap-2.6.31 for the old code.
> >> >
> >> > This time I also nuked the remaining omap legacy code we
> >> > still had lurking around :) The commits at the end of this
> >> > mail describe what I did first as commits, then I merged
> >> > everything to be the same as the mainline v2.6.32-rc1.
> >> >
> >> > So currently the linux-omap master branch is:
> >> >
> >> > v2.6.32-rc1 + omap-fixes + ehci + cbus
> >> >
> >> > The new model is that I'll be resetting the linux-omap master
> >> > branch to mainline at each -rc, then merge in our various
> >> > upstream queues back in again.
> >>
> >> Excellent! I was wondering why this wasn't being done. I certainly
> >> hope linus' 2.6.32 will work on omap right away.
> >
> > Yeah, let's hope Tomi gets in the DSS2 code too.
> >
> >> Anyway, I haven't been able to make 2.6.31 boot on beagleboard, and
> >> other people report similar issues:
> >> http://www.spinics.net/lists/linux-omap/msg17968.html
> >>
> >> Have you got 2.6.32-rc1 (+fixes) to boot?
> >
> > Hmm, looks like it's musb again. This is what I get on my
> > overo after applying the DEBUG_LL hack from omap-debug branch:
> >
> > <3>musb_hdrc musb_hdrc: musb_init_controller failed with status -19
> > <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000
> > <1>pgd = c0004000
> > <1>[00000000] *pgd=00000000
> > Internal error: Oops: 5 [#1]
> > <d>Modules linked in:
> > CPU: 0 Not tainted (2.6.32-rc2-05967-gd350540-dirty #892)
> > PC is at musb_free+0x68/0xb8
> > LR is at musb_free+0x34/0xb8
> > pc : [<c028a160>] lr : [<c028a12c>] psr: a0000013
> > sp : c781fe50 ip : 00000064 fp : 00000000
> > r10: 00000000 r9 : 00000000 r8 : c0557bc0
> > r7 : c7811000 r6 : c78110e8 r5 : c78110e8 r4 : 00000000
> > r3 : 00000000 r2 : 00000001 r1 : c04c95b6 r0 : ffffffed
> > Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
> > Control: 10c5387d Table: 80004019 DAC: 00000017
> > Process swapper (pid: 1, stack limit = 0xc781e2f0)
> > Stack: (0xc781fe50 to 0xc7820000)
> > fe40: ffffffed 00000000 c78110e8 c001e8f8
> > fe60: c781fea4 c7804180 00000000 c7804184 c0533dc8 c0533dd0 0000005c d80ab000
> > fe80: c0533dac c7811190 00000000 c781fedc c0114ad8 c7806850 c0546248 c06d74e0
> > fea0: 00000000 c03cd5c8 00000000 c781ff00 c78b8de0 c0114cbc c78b8d80 c781ff00
> > fec0: c78b8de0 c0114864 c78b8d80 c781ff00 c78b8de0 c011493c c781ff00 c78b8de0
> > fee0: c78b8d80 00000000 c781ff00 c78b8de0 c787a210 00000001 00000000 c01157b4
> > ff00: c787a210 00000000 00000000 c0533dd0 c0533dd0 c055df04 c7873600 c0557bc0
> > ff20: 00000000 00000000 00000000 c0210b7c c0533dd0 c020fbd4 c0533dd0 c0533e04
> > ff40: c055df04 c7873600 c0557bc0 c020fce0 00000000 c020fc80 c055df04 c020f420
> > ff60: c7802d08 c787b240 c0026dd4 00000080 c055df04 c020ed38 c03f14f4 c03f14f4
> > ff80: c7820000 c0026dd4 c055def0 c055df04 00000000 00000000 00000000 c020ffb0
> > ffa0: c0026dd4 c055def0 c001dca0 00000000 00000000 c0210f70 c0026dd4 00000000
> > ffc0: c001dca0 c002d2b4 00000031 00000000 00000000 00000192 00000000 c0026dd4
> > ffe0: 00000000 00000000 00000000 c0008578 00000000 c002ee10 817fdf10 00bbff00
> > [<c028a160>] (musb_free+0x68/0xb8) from [<c001e8f8>] (musb_probe+0xab8/0xbb4)
> > [<c001e8f8>] (musb_probe+0xab8/0xbb4) from [<c0210b7c>] (platform_drv_probe+0x1)
> > [<c0210b7c>] (platform_drv_probe+0x18/0x1c) from [<c020fbd4>] (driver_probe_dev)
> > [<c020fbd4>] (driver_probe_device+0xa0/0x14c) from [<c020fce0>] (__driver_attac)
> > [<c020fce0>] (__driver_attach+0x60/0x84) from [<c020f420>] (bus_for_each_dev+0x)
> > [<c020f420>] (bus_for_each_dev+0x44/0x74) from [<c020ed38>] (bus_add_driver+0xf)
> > [<c020ed38>] (bus_add_driver+0xf4/0x278) from [<c020ffb0>] (driver_register+0xa)
> > [<c020ffb0>] (driver_register+0xa8/0x130) from [<c0210f70>] (platform_driver_pr)
> > [<c0210f70>] (platform_driver_probe+0x10/0x88) from [<c002d2b4>] (do_one_initca)
> > [<c002d2b4>] (do_one_initcall+0x5c/0x1b4) from [<c0008578>] (kernel_init+0x90/0)
> > [<c0008578>] (kernel_init+0x90/0x10c) from [<c002ee10>] (kernel_thread_exit+0x0)
> > Code: e1a01005 ebf80722 e595309c e3a04000 (e5930000)
> > <4>---[ end trace 1b75b31a2719ed1c ]---
> > <0>Kernel panic - not syncing: Attempted to kill init!
> >
> > After disabling musb, it boots further but can't mount root on the MMC:
> >
> > ...
> > <4>regulator_init_complete: incomplete constraints, leaving VUSB1V8 on
> > regulator_init_complete: incomplete constraints, leaving VUSB1V8 on
> > <4>regulator_init_complete: incomplete constraints, leaving VUSB1V5 on
> > regulator_init_complete: incomplete constraints, leaving VUSB1V5 on
> > <4>regulator_init_complete: incomplete constraints, leaving VMMC1 on
> > regulator_init_complete: incomplete constraints, leaving VMMC1 on
> > <6>twl4030_rtc twl4030_rtc: setting system clock to 2000-01-01 00:00:00 UTC (94)
> > twl4030_rtc twl4030_rtc: setting system clock to 2000-01-01 00:00:00 UTC (94668)
> > <6>Waiting for root device /dev/mmcblk0p2...
> > Waiting for root device /dev/mmcblk0p2...
> >
> > What are you getting with DEBUG_LL enabled and the associated patch applied
> > from omap-debug branch?
> MUSB enabled gives me the same backtrace. When I disable it, I get
> (this is beagle B6):
>
> <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000
> <1>pgd = c0004000
> <1>[00000000] *pgd=00000000
> Internal error: Oops: 805 [#1]
> <d>Modules linked in:
> CPU: 0 Tainted: G W (2.6.32-rc2-05968-g11ddc16 #7)
> PC is at __mutex_lock_slowpath+0xe0/0x218
> LR is at __mutex_lock_slowpath+0xcc/0x218
> pc : [<c02967bc>] lr : [<c02967a8>] psr: 40000093
> sp : c7819e80 ip : 11111111 fp : c6d2e824
> r10: c6d2e800 r9 : c6d2e800 r8 : c7886c24
> r7 : c7817a40 r6 : 60000013 r5 : c7886c20 r4 : c7886c20
> r3 : 00000000 r2 : c7818000 r1 : c7819e80 r0 : c7886c20
> Flags: nZcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
> Control: 10c5387d Table: 80004019 DAC: 00000017
> Process swapper (pid: 1, stack limit = 0xc78182e8)
> Stack: (0xc7819e80 to 0xc781a000)
> 9e80: c7886c24 00000000 11111111 c7819e80 c6d2fd00 c7886c20 c6d2e800 00000000
> 9ea0: c7886c20 c7886c00 c6d2e800 c6d2e800 c6d2e824 c0296900 c6d2e800 c0197afc
> 9ec0: c7886c00 00000000 c7886e68 00000000 c6d2e800 c0198f90 c6d369c8 00000000
> 9ee0: c7819f00 c6d36968 c7810518 69000001 7265746e 006c616e 00000000 00000000
> 9f00: c7810518 c0387d50 c0387d50 c03a0504 c03a0504 c03a4800 00000000 00000000
> 9f20: 00000000 c019b37c c0387d50 c01c009c c03a0504 c01bf0d4 00000000 c0387d50
> 9f40: c0387d84 c03a0504 c7819f60 c01bf204 00000000 c01bf1a4 c03a0504 c01be954
> 9f60: c7803af8 c7845970 c03a4800 c0022890 c03a0504 c03a0504 c6d30cc0 c01be1f8
> 9f80: c0315ab2 c00187a0 c6d30d40 c0022890 c0022948 c03a0504 00000000 00000000
> 9fa0: 00000000 c01bf508 c0022890 c0022948 c00187fc 00000000 00000000 c00272b4
> 9fc0: 00000000 00000192 c038ba20 00000000 00000000 c0022890 c0022948 00000000
> 9fe0: 00000000 c0008584 00000000 00000000 00000000 c0028d80 853bee50 007b4fa4
> [<c02967bc>] (__mutex_lock_slowpath+0xe0/0x218) from [<c0296900>]
> (mutex_lock+0xc/0x1c)
> [<c0296900>] (mutex_lock+0xc/0x1c) from [<c0197afc>]
> (set_fb_fix+0x30/0xbc)
> [<c0197afc>] (set_fb_fix+0x30/0xbc) from [<c0198f90>]
> (omapfb_do_probe+0x404/0x858)
> [<c0198f90>] (omapfb_do_probe+0x404/0x858) from [<c019b37c>]
> (omap3beagle_panel_probe+0x10/0x20)
> [<c019b37c>] (omap3beagle_panel_probe+0x10/0x20) from [<c01c009c>]
> (platform_drv_probe+0x1c/0x24)
> [<c01c009c>] (platform_drv_probe+0x1c/0x24) from [<c01bf0d4>]
> (driver_probe_device+0xa4/0x174)
> [<c01bf0d4>] (driver_probe_device+0xa4/0x174) from [<c01bf204>]
> (__driver_attach+0x60/0x84)
> [<c01bf204>] (__driver_attach+0x60/0x84) from [<c01be954>]
> (bus_for_each_dev+0x4c/0x8c)
> [<c01be954>] (bus_for_each_dev+0x4c/0x8c) from [<c01be1f8>]
> (bus_add_driver+0xa0/0x218)
> [<c01be1f8>] (bus_add_driver+0xa0/0x218) from [<c01bf508>]
> (driver_register+0xbc/0x148)
> [<c01bf508>] (driver_register+0xbc/0x148) from [<c00272b4>]
> (do_one_initcall+0x5c/0x1bc)
> [<c00272b4>] (do_one_initcall+0x5c/0x1bc) from [<c0008584>]
> (kernel_init+0x94/0x110)
> [<c0008584>] (kernel_init+0x94/0x110) from [<c0028d80>]
> (kernel_thread_exit+0x0/0x8)
> Code: e2858004 e585d008 e58d8000 e58d3004 (e583d000)
> <4>---[ end trace da227214a82491b8 ]---
Maybe try Sergio's "omapfb: Condition mutex acquisition" patch:
http://patchwork.kernel.org/patch/50551/
Does that help?
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read
2009-09-29 19:30 ` Tony Lindgren
@ 2009-09-29 19:41 ` Alexander Shishkin
0 siblings, 0 replies; 25+ messages in thread
From: Alexander Shishkin @ 2009-09-29 19:41 UTC (permalink / raw)
To: Tony Lindgren; +Cc: Felipe Contreras, linux-omap
2009/9/29 Tony Lindgren <tony@atomide.com>:
> * Alexander Shishkin <virtuoso@slind.org> [090929 12:20]:
>> 2009/9/29 Tony Lindgren <tony@atomide.com>:
>> > * Felipe Contreras <felipe.contreras@gmail.com> [090929 10:24]:
>> >> On Mon, Sep 28, 2009 at 10:04 PM, Tony Lindgren <tony@atomide.com> wrote:
>> >> > Hi all,
>> >> >
>> >> > I've updated our linux-omap tree to v2.6.32-rc1. I've also
>> >> > added a branch omap-2.6.31 for the old code.
>> >> >
>> >> > This time I also nuked the remaining omap legacy code we
>> >> > still had lurking around :) The commits at the end of this
>> >> > mail describe what I did first as commits, then I merged
>> >> > everything to be the same as the mainline v2.6.32-rc1.
>> >> >
>> >> > So currently the linux-omap master branch is:
>> >> >
>> >> > v2.6.32-rc1 + omap-fixes + ehci + cbus
>> >> >
>> >> > The new model is that I'll be resetting the linux-omap master
>> >> > branch to mainline at each -rc, then merge in our various
>> >> > upstream queues back in again.
>> >>
>> >> Excellent! I was wondering why this wasn't being done. I certainly
>> >> hope linus' 2.6.32 will work on omap right away.
>> >
>> > Yeah, let's hope Tomi gets in the DSS2 code too.
>> >
>> >> Anyway, I haven't been able to make 2.6.31 boot on beagleboard, and
>> >> other people report similar issues:
>> >> http://www.spinics.net/lists/linux-omap/msg17968.html
>> >>
>> >> Have you got 2.6.32-rc1 (+fixes) to boot?
>> >
>> > Hmm, looks like it's musb again. This is what I get on my
>> > overo after applying the DEBUG_LL hack from omap-debug branch:
>> >
>> > <3>musb_hdrc musb_hdrc: musb_init_controller failed with status -19
>> > <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000
>> > <1>pgd = c0004000
>> > <1>[00000000] *pgd=00000000
>> > Internal error: Oops: 5 [#1]
>> > <d>Modules linked in:
>> > CPU: 0 Not tainted (2.6.32-rc2-05967-gd350540-dirty #892)
>> > PC is at musb_free+0x68/0xb8
>> > LR is at musb_free+0x34/0xb8
>> > pc : [<c028a160>] lr : [<c028a12c>] psr: a0000013
>> > sp : c781fe50 ip : 00000064 fp : 00000000
>> > r10: 00000000 r9 : 00000000 r8 : c0557bc0
>> > r7 : c7811000 r6 : c78110e8 r5 : c78110e8 r4 : 00000000
>> > r3 : 00000000 r2 : 00000001 r1 : c04c95b6 r0 : ffffffed
>> > Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
>> > Control: 10c5387d Table: 80004019 DAC: 00000017
>> > Process swapper (pid: 1, stack limit = 0xc781e2f0)
>> > Stack: (0xc781fe50 to 0xc7820000)
>> > fe40: ffffffed 00000000 c78110e8 c001e8f8
>> > fe60: c781fea4 c7804180 00000000 c7804184 c0533dc8 c0533dd0 0000005c d80ab000
>> > fe80: c0533dac c7811190 00000000 c781fedc c0114ad8 c7806850 c0546248 c06d74e0
>> > fea0: 00000000 c03cd5c8 00000000 c781ff00 c78b8de0 c0114cbc c78b8d80 c781ff00
>> > fec0: c78b8de0 c0114864 c78b8d80 c781ff00 c78b8de0 c011493c c781ff00 c78b8de0
>> > fee0: c78b8d80 00000000 c781ff00 c78b8de0 c787a210 00000001 00000000 c01157b4
>> > ff00: c787a210 00000000 00000000 c0533dd0 c0533dd0 c055df04 c7873600 c0557bc0
>> > ff20: 00000000 00000000 00000000 c0210b7c c0533dd0 c020fbd4 c0533dd0 c0533e04
>> > ff40: c055df04 c7873600 c0557bc0 c020fce0 00000000 c020fc80 c055df04 c020f420
>> > ff60: c7802d08 c787b240 c0026dd4 00000080 c055df04 c020ed38 c03f14f4 c03f14f4
>> > ff80: c7820000 c0026dd4 c055def0 c055df04 00000000 00000000 00000000 c020ffb0
>> > ffa0: c0026dd4 c055def0 c001dca0 00000000 00000000 c0210f70 c0026dd4 00000000
>> > ffc0: c001dca0 c002d2b4 00000031 00000000 00000000 00000192 00000000 c0026dd4
>> > ffe0: 00000000 00000000 00000000 c0008578 00000000 c002ee10 817fdf10 00bbff00
>> > [<c028a160>] (musb_free+0x68/0xb8) from [<c001e8f8>] (musb_probe+0xab8/0xbb4)
>> > [<c001e8f8>] (musb_probe+0xab8/0xbb4) from [<c0210b7c>] (platform_drv_probe+0x1)
>> > [<c0210b7c>] (platform_drv_probe+0x18/0x1c) from [<c020fbd4>] (driver_probe_dev)
>> > [<c020fbd4>] (driver_probe_device+0xa0/0x14c) from [<c020fce0>] (__driver_attac)
>> > [<c020fce0>] (__driver_attach+0x60/0x84) from [<c020f420>] (bus_for_each_dev+0x)
>> > [<c020f420>] (bus_for_each_dev+0x44/0x74) from [<c020ed38>] (bus_add_driver+0xf)
>> > [<c020ed38>] (bus_add_driver+0xf4/0x278) from [<c020ffb0>] (driver_register+0xa)
>> > [<c020ffb0>] (driver_register+0xa8/0x130) from [<c0210f70>] (platform_driver_pr)
>> > [<c0210f70>] (platform_driver_probe+0x10/0x88) from [<c002d2b4>] (do_one_initca)
>> > [<c002d2b4>] (do_one_initcall+0x5c/0x1b4) from [<c0008578>] (kernel_init+0x90/0)
>> > [<c0008578>] (kernel_init+0x90/0x10c) from [<c002ee10>] (kernel_thread_exit+0x0)
>> > Code: e1a01005 ebf80722 e595309c e3a04000 (e5930000)
>> > <4>---[ end trace 1b75b31a2719ed1c ]---
>> > <0>Kernel panic - not syncing: Attempted to kill init!
>> >
>> > After disabling musb, it boots further but can't mount root on the MMC:
>> >
>> > ...
>> > <4>regulator_init_complete: incomplete constraints, leaving VUSB1V8 on
>> > regulator_init_complete: incomplete constraints, leaving VUSB1V8 on
>> > <4>regulator_init_complete: incomplete constraints, leaving VUSB1V5 on
>> > regulator_init_complete: incomplete constraints, leaving VUSB1V5 on
>> > <4>regulator_init_complete: incomplete constraints, leaving VMMC1 on
>> > regulator_init_complete: incomplete constraints, leaving VMMC1 on
>> > <6>twl4030_rtc twl4030_rtc: setting system clock to 2000-01-01 00:00:00 UTC (94)
>> > twl4030_rtc twl4030_rtc: setting system clock to 2000-01-01 00:00:00 UTC (94668)
>> > <6>Waiting for root device /dev/mmcblk0p2...
>> > Waiting for root device /dev/mmcblk0p2...
>> >
>> > What are you getting with DEBUG_LL enabled and the associated patch applied
>> > from omap-debug branch?
>> MUSB enabled gives me the same backtrace. When I disable it, I get
>> (this is beagle B6):
>>
>> <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000
>> <1>pgd = c0004000
>> <1>[00000000] *pgd=00000000
>> Internal error: Oops: 805 [#1]
>> <d>Modules linked in:
>> CPU: 0 Tainted: G W (2.6.32-rc2-05968-g11ddc16 #7)
>> PC is at __mutex_lock_slowpath+0xe0/0x218
>> LR is at __mutex_lock_slowpath+0xcc/0x218
>> pc : [<c02967bc>] lr : [<c02967a8>] psr: 40000093
>> sp : c7819e80 ip : 11111111 fp : c6d2e824
>> r10: c6d2e800 r9 : c6d2e800 r8 : c7886c24
>> r7 : c7817a40 r6 : 60000013 r5 : c7886c20 r4 : c7886c20
>> r3 : 00000000 r2 : c7818000 r1 : c7819e80 r0 : c7886c20
>> Flags: nZcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
>> Control: 10c5387d Table: 80004019 DAC: 00000017
>> Process swapper (pid: 1, stack limit = 0xc78182e8)
>> Stack: (0xc7819e80 to 0xc781a000)
>> 9e80: c7886c24 00000000 11111111 c7819e80 c6d2fd00 c7886c20 c6d2e800 00000000
>> 9ea0: c7886c20 c7886c00 c6d2e800 c6d2e800 c6d2e824 c0296900 c6d2e800 c0197afc
>> 9ec0: c7886c00 00000000 c7886e68 00000000 c6d2e800 c0198f90 c6d369c8 00000000
>> 9ee0: c7819f00 c6d36968 c7810518 69000001 7265746e 006c616e 00000000 00000000
>> 9f00: c7810518 c0387d50 c0387d50 c03a0504 c03a0504 c03a4800 00000000 00000000
>> 9f20: 00000000 c019b37c c0387d50 c01c009c c03a0504 c01bf0d4 00000000 c0387d50
>> 9f40: c0387d84 c03a0504 c7819f60 c01bf204 00000000 c01bf1a4 c03a0504 c01be954
>> 9f60: c7803af8 c7845970 c03a4800 c0022890 c03a0504 c03a0504 c6d30cc0 c01be1f8
>> 9f80: c0315ab2 c00187a0 c6d30d40 c0022890 c0022948 c03a0504 00000000 00000000
>> 9fa0: 00000000 c01bf508 c0022890 c0022948 c00187fc 00000000 00000000 c00272b4
>> 9fc0: 00000000 00000192 c038ba20 00000000 00000000 c0022890 c0022948 00000000
>> 9fe0: 00000000 c0008584 00000000 00000000 00000000 c0028d80 853bee50 007b4fa4
>> [<c02967bc>] (__mutex_lock_slowpath+0xe0/0x218) from [<c0296900>]
>> (mutex_lock+0xc/0x1c)
>> [<c0296900>] (mutex_lock+0xc/0x1c) from [<c0197afc>]
>> (set_fb_fix+0x30/0xbc)
>> [<c0197afc>] (set_fb_fix+0x30/0xbc) from [<c0198f90>]
>> (omapfb_do_probe+0x404/0x858)
>> [<c0198f90>] (omapfb_do_probe+0x404/0x858) from [<c019b37c>]
>> (omap3beagle_panel_probe+0x10/0x20)
>> [<c019b37c>] (omap3beagle_panel_probe+0x10/0x20) from [<c01c009c>]
>> (platform_drv_probe+0x1c/0x24)
>> [<c01c009c>] (platform_drv_probe+0x1c/0x24) from [<c01bf0d4>]
>> (driver_probe_device+0xa4/0x174)
>> [<c01bf0d4>] (driver_probe_device+0xa4/0x174) from [<c01bf204>]
>> (__driver_attach+0x60/0x84)
>> [<c01bf204>] (__driver_attach+0x60/0x84) from [<c01be954>]
>> (bus_for_each_dev+0x4c/0x8c)
>> [<c01be954>] (bus_for_each_dev+0x4c/0x8c) from [<c01be1f8>]
>> (bus_add_driver+0xa0/0x218)
>> [<c01be1f8>] (bus_add_driver+0xa0/0x218) from [<c01bf508>]
>> (driver_register+0xbc/0x148)
>> [<c01bf508>] (driver_register+0xbc/0x148) from [<c00272b4>]
>> (do_one_initcall+0x5c/0x1bc)
>> [<c00272b4>] (do_one_initcall+0x5c/0x1bc) from [<c0008584>]
>> (kernel_init+0x94/0x110)
>> [<c0008584>] (kernel_init+0x94/0x110) from [<c0028d80>]
>> (kernel_thread_exit+0x0/0x8)
>> Code: e2858004 e585d008 e58d8000 e58d3004 (e583d000)
>> <4>---[ end trace da227214a82491b8 ]---
>
> Maybe try Sergio's "omapfb: Condition mutex acquisition" patch:
>
> http://patchwork.kernel.org/patch/50551/
>
> Does that help?
Indeed it does. Now I'm seeing the same regulator stuff you quoted.
Given that I'm not set up to mount rootfs from mmc, it just panics on
not able to mount rootfs (since there's nothing to mount). I think
I'll get myself some sort of an initramfs.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read
2009-09-29 19:26 ` Aguirre Rodriguez, Sergio Alberto
@ 2009-09-29 19:42 ` Alexander Shishkin
0 siblings, 0 replies; 25+ messages in thread
From: Alexander Shishkin @ 2009-09-29 19:42 UTC (permalink / raw)
To: Aguirre Rodriguez, Sergio Alberto
Cc: Tony Lindgren, Felipe Contreras, linux-omap
2009/9/29 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
> From: linux-omap-owner@vger.kernel.org [linux-omap-owner@vger.kernel.org] On Behalf Of Alexander Shishkin [virtuoso@slind.org]
> Sent: Tuesday, September 29, 2009 2:20 PM
>> 2009/9/29 Tony Lindgren <tony@atomide.com>:
>> > * Felipe Contreras <felipe.contreras@gmail.com> [090929 10:24]:
>> >> On Mon, Sep 28, 2009 at 10:04 PM, Tony Lindgren <tony@atomide.com> wrote:
>> >> > Hi all,
>> >> >
>> >> > I've updated our linux-omap tree to v2.6.32-rc1. I've also
>> >> > added a branch omap-2.6.31 for the old code.
>> >> >
>> >> > This time I also nuked the remaining omap legacy code we
>> >> > still had lurking around :) The commits at the end of this
>> >> > mail describe what I did first as commits, then I merged
>> >> > everything to be the same as the mainline v2.6.32-rc1.
>> >> >
>> >> > So currently the linux-omap master branch is:
>> >> >
>> >> > v2.6.32-rc1 + omap-fixes + ehci + cbus
>> >> >
>> >> > The new model is that I'll be resetting the linux-omap master
>> >> > branch to mainline at each -rc, then merge in our various
>> >> > upstream queues back in again.
>> >>
>> >> Excellent! I was wondering why this wasn't being done. I certainly
>> >> hope linus' 2.6.32 will work on omap right away.
>> >
>> > Yeah, let's hope Tomi gets in the DSS2 code too.
>> >
>> >> Anyway, I haven't been able to make 2.6.31 boot on beagleboard, and
>> >> other people report similar issues:
>> >> http://www.spinics.net/lists/linux-omap/msg17968.html
>> >>
>> >> Have you got 2.6.32-rc1 (+fixes) to boot?
>> >
>> > Hmm, looks like it's musb again. This is what I get on my
>> > overo after applying the DEBUG_LL hack from omap-debug branch:
>> >
>> > <3>musb_hdrc musb_hdrc: musb_init_controller failed with status -19
>> > <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000
>> > <1>pgd = c0004000
>> > <1>[00000000] *pgd=00000000
>> > Internal error: Oops: 5 [#1]
>> > <d>Modules linked in:
>> > CPU: 0 Not tainted (2.6.32-rc2-05967-gd350540-dirty #892)
>> > PC is at musb_free+0x68/0xb8
>> > LR is at musb_free+0x34/0xb8
>
> <snip>
>
>> >
>> > After disabling musb, it boots further but can't mount root on the MMC:
>> >
>> > ...
>> > <4>regulator_init_complete: incomplete constraints, leaving VUSB1V8 on
>> > regulator_init_complete: incomplete constraints, leaving VUSB1V8 on
>> > <4>regulator_init_complete: incomplete constraints, leaving VUSB1V5 on
>> > regulator_init_complete: incomplete constraints, leaving VUSB1V5 on
>> > <4>regulator_init_complete: incomplete constraints, leaving VMMC1 on
>> > regulator_init_complete: incomplete constraints, leaving VMMC1 on
>> > <6>twl4030_rtc twl4030_rtc: setting system clock to 2000-01-01 00:00:00 UTC (94)
>> > twl4030_rtc twl4030_rtc: setting system clock to 2000-01-01 00:00:00 UTC (94668)
>> > <6>Waiting for root device /dev/mmcblk0p2...
>> > Waiting for root device /dev/mmcblk0p2...
>> >
>> > What are you getting with DEBUG_LL enabled and the associated patch applied
>> > from omap-debug branch?
>> MUSB enabled gives me the same backtrace. When I disable it, I get
>> (this is beagle B6):
>>
>> <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000
>> <1>pgd = c0004000
>> <1>[00000000] *pgd=00000000
>
> <snip>
>
> Hi,
>
> Can you please try attached patch?
Yep, thanks! (provided it's actually the same patch that Toni referred to).
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read
2009-09-28 19:04 linux-omap git tree updated to v2.6.32-rc1, important changes, please read Tony Lindgren
` (2 preceding siblings ...)
2009-09-29 17:24 ` Felipe Contreras
@ 2009-09-30 14:07 ` Kevin Hilman
2009-09-30 17:25 ` Tony Lindgren
3 siblings, 1 reply; 25+ messages in thread
From: Kevin Hilman @ 2009-09-30 14:07 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-omap
Tony Lindgren <tony@atomide.com> writes:
> Hi all,
>
> I've updated our linux-omap tree to v2.6.32-rc1. I've also
> added a branch omap-2.6.31 for the old code.
>
> This time I also nuked the remaining omap legacy code we
> still had lurking around :) The commits at the end of this
> mail describe what I did first as commits, then I merged
> everything to be the same as the mainline v2.6.32-rc1.
>
> So currently the linux-omap master branch is:
>
> v2.6.32-rc1 + omap-fixes + ehci + cbus
>
> The new model is that I'll be resetting the linux-omap master
> branch to mainline at each -rc, then merge in our various
> upstream queues back in again.
>
> Please note that "Remove omap extra version in Makefile"
> commit means that you now need to set the ARCH and CROSS_COMPILE
> for your compiler.
FYI... As of 2.6.32, the kernel caches the ARCH and CROSS_COMPILE in
the build dir under include/generated/kernel.[arch,cross_compile], so
if you build using ARCH and CROSS_COMPILE once, it should remember
them until doing a clean build.
Kevin
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read
2009-09-29 18:26 ` Tony Lindgren
2009-09-29 19:20 ` Alexander Shishkin
@ 2009-09-30 15:53 ` Roger Quadros
2009-09-30 17:02 ` Alexander Shishkin
1 sibling, 1 reply; 25+ messages in thread
From: Roger Quadros @ 2009-09-30 15:53 UTC (permalink / raw)
To: ext Tony Lindgren; +Cc: Felipe Contreras, linux-omap
ext Tony Lindgren wrote:
> * Felipe Contreras <felipe.contreras@gmail.com> [090929 10:24]:
>> On Mon, Sep 28, 2009 at 10:04 PM, Tony Lindgren <tony@atomide.com> wrote:
>>> Hi all,
>>>
>>> I've updated our linux-omap tree to v2.6.32-rc1. I've also
>>> added a branch omap-2.6.31 for the old code.
>>>
>>> This time I also nuked the remaining omap legacy code we
>>> still had lurking around :) The commits at the end of this
>>> mail describe what I did first as commits, then I merged
>>> everything to be the same as the mainline v2.6.32-rc1.
>>>
>>> So currently the linux-omap master branch is:
>>>
>>> v2.6.32-rc1 + omap-fixes + ehci + cbus
>>>
>>> The new model is that I'll be resetting the linux-omap master
>>> branch to mainline at each -rc, then merge in our various
>>> upstream queues back in again.
>> Excellent! I was wondering why this wasn't being done. I certainly
>> hope linus' 2.6.32 will work on omap right away.
>
> Yeah, let's hope Tomi gets in the DSS2 code too.
>
>> Anyway, I haven't been able to make 2.6.31 boot on beagleboard, and
>> other people report similar issues:
>> http://www.spinics.net/lists/linux-omap/msg17968.html
>>
>> Have you got 2.6.32-rc1 (+fixes) to boot?
>
> Hmm, looks like it's musb again. This is what I get on my
> overo after applying the DEBUG_LL hack from omap-debug branch:
i've just sent a fix for this musb problem. patch is labelled "twl4030: Fix boot
with twl4030 usb transceiver enabled"
cheers,
-roger
>
> <3>musb_hdrc musb_hdrc: musb_init_controller failed with status -19
> <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000
> <1>pgd = c0004000
> <1>[00000000] *pgd=00000000
> Internal error: Oops: 5 [#1]
> <d>Modules linked in:
> CPU: 0 Not tainted (2.6.32-rc2-05967-gd350540-dirty #892)
> PC is at musb_free+0x68/0xb8
> LR is at musb_free+0x34/0xb8
> pc : [<c028a160>] lr : [<c028a12c>] psr: a0000013
> sp : c781fe50 ip : 00000064 fp : 00000000
> r10: 00000000 r9 : 00000000 r8 : c0557bc0
> r7 : c7811000 r6 : c78110e8 r5 : c78110e8 r4 : 00000000
> r3 : 00000000 r2 : 00000001 r1 : c04c95b6 r0 : ffffffed
> Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
> Control: 10c5387d Table: 80004019 DAC: 00000017
> Process swapper (pid: 1, stack limit = 0xc781e2f0)
> Stack: (0xc781fe50 to 0xc7820000)
> fe40: ffffffed 00000000 c78110e8 c001e8f8
> fe60: c781fea4 c7804180 00000000 c7804184 c0533dc8 c0533dd0 0000005c d80ab000
> fe80: c0533dac c7811190 00000000 c781fedc c0114ad8 c7806850 c0546248 c06d74e0
> fea0: 00000000 c03cd5c8 00000000 c781ff00 c78b8de0 c0114cbc c78b8d80 c781ff00
> fec0: c78b8de0 c0114864 c78b8d80 c781ff00 c78b8de0 c011493c c781ff00 c78b8de0
> fee0: c78b8d80 00000000 c781ff00 c78b8de0 c787a210 00000001 00000000 c01157b4
> ff00: c787a210 00000000 00000000 c0533dd0 c0533dd0 c055df04 c7873600 c0557bc0
> ff20: 00000000 00000000 00000000 c0210b7c c0533dd0 c020fbd4 c0533dd0 c0533e04
> ff40: c055df04 c7873600 c0557bc0 c020fce0 00000000 c020fc80 c055df04 c020f420
> ff60: c7802d08 c787b240 c0026dd4 00000080 c055df04 c020ed38 c03f14f4 c03f14f4
> ff80: c7820000 c0026dd4 c055def0 c055df04 00000000 00000000 00000000 c020ffb0
> ffa0: c0026dd4 c055def0 c001dca0 00000000 00000000 c0210f70 c0026dd4 00000000
> ffc0: c001dca0 c002d2b4 00000031 00000000 00000000 00000192 00000000 c0026dd4
> ffe0: 00000000 00000000 00000000 c0008578 00000000 c002ee10 817fdf10 00bbff00
> [<c028a160>] (musb_free+0x68/0xb8) from [<c001e8f8>] (musb_probe+0xab8/0xbb4)
> [<c001e8f8>] (musb_probe+0xab8/0xbb4) from [<c0210b7c>] (platform_drv_probe+0x1)
> [<c0210b7c>] (platform_drv_probe+0x18/0x1c) from [<c020fbd4>] (driver_probe_dev)
> [<c020fbd4>] (driver_probe_device+0xa0/0x14c) from [<c020fce0>] (__driver_attac)
> [<c020fce0>] (__driver_attach+0x60/0x84) from [<c020f420>] (bus_for_each_dev+0x)
> [<c020f420>] (bus_for_each_dev+0x44/0x74) from [<c020ed38>] (bus_add_driver+0xf)
> [<c020ed38>] (bus_add_driver+0xf4/0x278) from [<c020ffb0>] (driver_register+0xa)
> [<c020ffb0>] (driver_register+0xa8/0x130) from [<c0210f70>] (platform_driver_pr)
> [<c0210f70>] (platform_driver_probe+0x10/0x88) from [<c002d2b4>] (do_one_initca)
> [<c002d2b4>] (do_one_initcall+0x5c/0x1b4) from [<c0008578>] (kernel_init+0x90/0)
> [<c0008578>] (kernel_init+0x90/0x10c) from [<c002ee10>] (kernel_thread_exit+0x0)
> Code: e1a01005 ebf80722 e595309c e3a04000 (e5930000)
> <4>---[ end trace 1b75b31a2719ed1c ]---
> <0>Kernel panic - not syncing: Attempted to kill init!
>
> After disabling musb, it boots further but can't mount root on the MMC:
>
> ...
> <4>regulator_init_complete: incomplete constraints, leaving VUSB1V8 on
> regulator_init_complete: incomplete constraints, leaving VUSB1V8 on
> <4>regulator_init_complete: incomplete constraints, leaving VUSB1V5 on
> regulator_init_complete: incomplete constraints, leaving VUSB1V5 on
> <4>regulator_init_complete: incomplete constraints, leaving VMMC1 on
> regulator_init_complete: incomplete constraints, leaving VMMC1 on
> <6>twl4030_rtc twl4030_rtc: setting system clock to 2000-01-01 00:00:00 UTC (94)
> twl4030_rtc twl4030_rtc: setting system clock to 2000-01-01 00:00:00 UTC (94668)
> <6>Waiting for root device /dev/mmcblk0p2...
> Waiting for root device /dev/mmcblk0p2...
>
> What are you getting with DEBUG_LL enabled and the associated patch applied
> from omap-debug branch?
>
> Regards,
>
> Tony
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read
2009-09-30 15:53 ` Roger Quadros
@ 2009-09-30 17:02 ` Alexander Shishkin
2009-09-30 17:04 ` Gadiyar, Anand
0 siblings, 1 reply; 25+ messages in thread
From: Alexander Shishkin @ 2009-09-30 17:02 UTC (permalink / raw)
To: Roger Quadros; +Cc: ext Tony Lindgren, Felipe Contreras, linux-omap
2009/9/30 Roger Quadros <ext-roger.quadros@nokia.com>:
> ext Tony Lindgren wrote:
>>
>> * Felipe Contreras <felipe.contreras@gmail.com> [090929 10:24]:
>>>
>>> On Mon, Sep 28, 2009 at 10:04 PM, Tony Lindgren <tony@atomide.com> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I've updated our linux-omap tree to v2.6.32-rc1. I've also
>>>> added a branch omap-2.6.31 for the old code.
>>>>
>>>> This time I also nuked the remaining omap legacy code we
>>>> still had lurking around :) The commits at the end of this
>>>> mail describe what I did first as commits, then I merged
>>>> everything to be the same as the mainline v2.6.32-rc1.
>>>>
>>>> So currently the linux-omap master branch is:
>>>>
>>>> v2.6.32-rc1 + omap-fixes + ehci + cbus
>>>>
>>>> The new model is that I'll be resetting the linux-omap master
>>>> branch to mainline at each -rc, then merge in our various
>>>> upstream queues back in again.
>>>
>>> Excellent! I was wondering why this wasn't being done. I certainly
>>> hope linus' 2.6.32 will work on omap right away.
>>
>> Yeah, let's hope Tomi gets in the DSS2 code too.
>>
>>>
>>> Anyway, I haven't been able to make 2.6.31 boot on beagleboard, and
>>> other people report similar issues:
>>> http://www.spinics.net/lists/linux-omap/msg17968.html
>>>
>>> Have you got 2.6.32-rc1 (+fixes) to boot?
>>
>> Hmm, looks like it's musb again. This is what I get on my
>> overo after applying the DEBUG_LL hack from omap-debug branch:
>
> i've just sent a fix for this musb problem. patch is labelled "twl4030: Fix
> boot with twl4030 usb transceiver enabled"
I can't quite locate it in linux-usb archives (or anywhere within
google's reach). Could you sand it here or provide a link?
Regards,
--
Alex
^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: linux-omap git tree updated to v2.6.32-rc1, important changes, please read
2009-09-30 17:02 ` Alexander Shishkin
@ 2009-09-30 17:04 ` Gadiyar, Anand
2009-09-30 17:31 ` Tony Lindgren
0 siblings, 1 reply; 25+ messages in thread
From: Gadiyar, Anand @ 2009-09-30 17:04 UTC (permalink / raw)
To: Alexander Shishkin, Roger Quadros
Cc: ext Tony Lindgren, Felipe Contreras, linux-omap
> >>
> >>>
> >>> Anyway, I haven't been able to make 2.6.31 boot on beagleboard, and
> >>> other people report similar issues:
> >>> http://www.spinics.net/lists/linux-omap/msg17968.html
> >>>
> >>> Have you got 2.6.32-rc1 (+fixes) to boot?
> >>
> >> Hmm, looks like it's musb again. This is what I get on my
> >> overo after applying the DEBUG_LL hack from omap-debug branch:
> >
> > i've just sent a fix for this musb problem. patch is labelled "twl4030: Fix
> > boot with twl4030 usb transceiver enabled"
>
> I can't quite locate it in linux-usb archives (or anywhere within
> google's reach). Could you sand it here or provide a link?
>
Here you go. Patchwork rocks!
<http://patchwork.kernel.org/patch/50721/>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read
2009-09-30 14:07 ` Kevin Hilman
@ 2009-09-30 17:25 ` Tony Lindgren
0 siblings, 0 replies; 25+ messages in thread
From: Tony Lindgren @ 2009-09-30 17:25 UTC (permalink / raw)
To: Kevin Hilman; +Cc: linux-omap
* Kevin Hilman <khilman@deeprootsystems.com> [090930 07:07]:
> Tony Lindgren <tony@atomide.com> writes:
>
> > Hi all,
> >
> > I've updated our linux-omap tree to v2.6.32-rc1. I've also
> > added a branch omap-2.6.31 for the old code.
> >
> > This time I also nuked the remaining omap legacy code we
> > still had lurking around :) The commits at the end of this
> > mail describe what I did first as commits, then I merged
> > everything to be the same as the mainline v2.6.32-rc1.
> >
> > So currently the linux-omap master branch is:
> >
> > v2.6.32-rc1 + omap-fixes + ehci + cbus
> >
> > The new model is that I'll be resetting the linux-omap master
> > branch to mainline at each -rc, then merge in our various
> > upstream queues back in again.
> >
> > Please note that "Remove omap extra version in Makefile"
> > commit means that you now need to set the ARCH and CROSS_COMPILE
> > for your compiler.
>
> FYI... As of 2.6.32, the kernel caches the ARCH and CROSS_COMPILE in
> the build dir under include/generated/kernel.[arch,cross_compile], so
> if you build using ARCH and CROSS_COMPILE once, it should remember
> them until doing a clean build.
Nice, sounds like we removed that hack just at the right moment then!
Tony
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read
2009-09-30 17:04 ` Gadiyar, Anand
@ 2009-09-30 17:31 ` Tony Lindgren
2009-10-01 7:30 ` Roger Quadros
2009-10-01 7:58 ` Roger Quadros
0 siblings, 2 replies; 25+ messages in thread
From: Tony Lindgren @ 2009-09-30 17:31 UTC (permalink / raw)
To: Gadiyar, Anand
Cc: Alexander Shishkin, Roger Quadros, Felipe Contreras, linux-omap
* Gadiyar, Anand <gadiyar@ti.com> [090930 10:05]:
> > >>
> > >>>
> > >>> Anyway, I haven't been able to make 2.6.31 boot on beagleboard, and
> > >>> other people report similar issues:
> > >>> http://www.spinics.net/lists/linux-omap/msg17968.html
> > >>>
> > >>> Have you got 2.6.32-rc1 (+fixes) to boot?
> > >>
> > >> Hmm, looks like it's musb again. This is what I get on my
> > >> overo after applying the DEBUG_LL hack from omap-debug branch:
> > >
> > > i've just sent a fix for this musb problem. patch is labelled "twl4030: Fix
> > > boot with twl4030 usb transceiver enabled"
> >
> > I can't quite locate it in linux-usb archives (or anywhere within
> > google's reach). Could you sand it here or provide a link?
> >
>
> Here you go. Patchwork rocks!
>
> <http://patchwork.kernel.org/patch/50721/>
>
Great, thanks. Roger, please send your fix to Samuel for merging.
Meanwhile, I'll apply it into fixes-testing while waiting for it
to get to mainline via Samuel.
Regards,
Tony
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read
2009-09-29 10:54 ` Shilimkar, Santosh
@ 2009-09-30 17:55 ` Tony Lindgren
2009-10-01 4:04 ` Shilimkar, Santosh
0 siblings, 1 reply; 25+ messages in thread
From: Tony Lindgren @ 2009-09-30 17:55 UTC (permalink / raw)
To: Shilimkar, Santosh; +Cc: linux-omap
Hi,
* Shilimkar, Santosh <santosh.shilimkar@ti.com> [090929 03:54]:
<snip>
> Thanks for fixing the OMAP4 compilation issues. We need below patch to make the kernel boot on OMAP4430 on the latest LO master.
No problem. In the future, let's make sure the omap4 patches are merged
into l-o master branch for testing. This time the first three patches
in the omap-fixes branch were build breakage caused by the omap4 patches
directly or indirectly..
Also, please everybody check that your patches don't break the build
for other the omaps, and also boot test on some other omaps if someting
looks risky.
Few comments below.
>
> From d9a22d9f7b68b99aa9607bdab377d998dfe82acd Mon Sep 17 00:00:00 2001
> From: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Date: Tue, 29 Sep 2009 16:10:46 +0530
> Subject: [PATCH] ARM: OMAP4: Allow omap_serial_early_init() for OMAP4430 board
>
> This patch enables omap_serial_early_init() function for OMAP4430
> SDP. Without this the bootup would throw opps in omap_serial_init().
The opps probably should be oops above :)
> Additionally the patch removed the merge issue for the UART4.
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
> arch/arm/mach-omap2/board-4430sdp.c | 4 ++--
> arch/arm/mach-omap2/io.c | 2 ++
> arch/arm/mach-omap2/serial.c | 10 ----------
> 3 files changed, 4 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
> index eb37c40..609a5a4 100644
> --- a/arch/arm/mach-omap2/board-4430sdp.c
> +++ b/arch/arm/mach-omap2/board-4430sdp.c
> @@ -58,6 +58,8 @@ static void __init gic_init_irq(void)
>
> static void __init omap_4430sdp_init_irq(void)
> {
> + omap_board_config = sdp4430_config;
> + omap_board_config_size = ARRAY_SIZE(sdp4430_config);
> omap2_init_common_hw(NULL, NULL);
> #ifdef CONFIG_OMAP_32K_TIMER
> omap2_gp_clockevent_set_gptimer(1);
> @@ -70,8 +72,6 @@ static void __init omap_4430sdp_init_irq(void)
> static void __init omap_4430sdp_init(void)
> {
> platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
> - omap_board_config = sdp4430_config;
> - omap_board_config_size = ARRAY_SIZE(sdp4430_config);
> omap_serial_init();
> }
>
> diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
> index e3a3bad..56be87d 100644
> --- a/arch/arm/mach-omap2/io.c
> +++ b/arch/arm/mach-omap2/io.c
> @@ -302,7 +302,9 @@ void __init omap2_init_common_hw(struct omap_sdrc_params *sdrc_cs0,
> pwrdm_init(powerdomains_omap);
> clkdm_init(clockdomains_omap, clkdm_pwrdm_autodeps);
> omap2_clk_init();
> +#endif
> omap_serial_early_init();
> +#ifndef CONFIG_ARCH_OMAP4
> omap_hwmod_late_init();
> omap_pm_if_init();
> omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
> diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
> index ae21868..54dfeb5 100644
> --- a/arch/arm/mach-omap2/serial.c
> +++ b/arch/arm/mach-omap2/serial.c
> @@ -109,16 +109,6 @@ static struct plat_serial8250_port serial_platform_data2[] = {
> .regshift = 2,
> .uartclk = OMAP24XX_BASE_BAUD * 16,
> }, {
> -#ifdef CONFIG_ARCH_OMAP4
> - .membase = OMAP2_IO_ADDRESS(OMAP_UART4_BASE),
> - .mapbase = OMAP_UART4_BASE,
> - .irq = 70,
> - .flags = UPF_BOOT_AUTOCONF,
> - .iotype = UPIO_MEM,
> - .regshift = 2,
> - .uartclk = OMAP24XX_BASE_BAUD * 16,
> - }, {
> -#endif
> .flags = 0
> }
> };
Can't we fix the extra uart instead of removing it? We just added it!
It's still there in omap4, right?
Regards,
Tony
^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: linux-omap git tree updated to v2.6.32-rc1, important changes, please read
2009-09-30 17:55 ` Tony Lindgren
@ 2009-10-01 4:04 ` Shilimkar, Santosh
0 siblings, 0 replies; 25+ messages in thread
From: Shilimkar, Santosh @ 2009-10-01 4:04 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-omap
> -----Original Message-----
> From: Tony Lindgren [mailto:tony@atomide.com]
> Sent: Wednesday, September 30, 2009 11:25 PM
> To: Shilimkar, Santosh
> Cc: linux-omap@vger.kernel.org
> Subject: Re: linux-omap git tree updated to v2.6.32-rc1, important changes,
> please read
>
> Hi,
>
> * Shilimkar, Santosh <santosh.shilimkar@ti.com> [090929 03:54]:
>
> <snip>
>
> > Thanks for fixing the OMAP4 compilation issues. We need below patch to
> make the kernel boot on OMAP4430 on the latest LO master.
>
> No problem. In the future, let's make sure the omap4 patches are merged
> into l-o master branch for testing. This time the first three patches
> in the omap-fixes branch were build breakage caused by the omap4 patches
> directly or indirectly..
Agree!!
> Also, please everybody check that your patches don't break the build
> for other the omaps, and also boot test on some other omaps if someting
> looks risky.
>
> Few comments below.
>
> >
> > From d9a22d9f7b68b99aa9607bdab377d998dfe82acd Mon Sep 17 00:00:00 2001
> > From: Santosh Shilimkar <santosh.shilimkar@ti.com>
> > Date: Tue, 29 Sep 2009 16:10:46 +0530
> > Subject: [PATCH] ARM: OMAP4: Allow omap_serial_early_init() for OMAP4430
> board
> >
> > This patch enables omap_serial_early_init() function for OMAP4430
> > SDP. Without this the bootup would throw opps in omap_serial_init().
>
> The opps probably should be oops above :)
YEP :)
> > Additionally the patch removed the merge issue for the UART4.
> >
> > Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> > ---
> > arch/arm/mach-omap2/board-4430sdp.c | 4 ++--
> > arch/arm/mach-omap2/io.c | 2 ++
> > arch/arm/mach-omap2/serial.c | 10 ----------
> > 3 files changed, 4 insertions(+), 12 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-
> omap2/board-4430sdp.c
> > index eb37c40..609a5a4 100644
> > --- a/arch/arm/mach-omap2/board-4430sdp.c
> > +++ b/arch/arm/mach-omap2/board-4430sdp.c
> > @@ -58,6 +58,8 @@ static void __init gic_init_irq(void)
> >
> > static void __init omap_4430sdp_init_irq(void)
> > {
> > + omap_board_config = sdp4430_config;
> > + omap_board_config_size = ARRAY_SIZE(sdp4430_config);
> > omap2_init_common_hw(NULL, NULL);
> > #ifdef CONFIG_OMAP_32K_TIMER
> > omap2_gp_clockevent_set_gptimer(1);
> > @@ -70,8 +72,6 @@ static void __init omap_4430sdp_init_irq(void)
> > static void __init omap_4430sdp_init(void)
> > {
> > platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
> > - omap_board_config = sdp4430_config;
> > - omap_board_config_size = ARRAY_SIZE(sdp4430_config);
> > omap_serial_init();
> > }
> >
> > diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
> > index e3a3bad..56be87d 100644
> > --- a/arch/arm/mach-omap2/io.c
> > +++ b/arch/arm/mach-omap2/io.c
> > @@ -302,7 +302,9 @@ void __init omap2_init_common_hw(struct
> omap_sdrc_params *sdrc_cs0,
> > pwrdm_init(powerdomains_omap);
> > clkdm_init(clockdomains_omap, clkdm_pwrdm_autodeps);
> > omap2_clk_init();
> > +#endif
> > omap_serial_early_init();
> > +#ifndef CONFIG_ARCH_OMAP4
> > omap_hwmod_late_init();
> > omap_pm_if_init();
> > omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
> > diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
> > index ae21868..54dfeb5 100644
> > --- a/arch/arm/mach-omap2/serial.c
> > +++ b/arch/arm/mach-omap2/serial.c
> > @@ -109,16 +109,6 @@ static struct plat_serial8250_port
> serial_platform_data2[] = {
> > .regshift = 2,
> > .uartclk = OMAP24XX_BASE_BAUD * 16,
> > }, {
> > -#ifdef CONFIG_ARCH_OMAP4
> > - .membase = OMAP2_IO_ADDRESS(OMAP_UART4_BASE),
> > - .mapbase = OMAP_UART4_BASE,
> > - .irq = 70,
> > - .flags = UPF_BOOT_AUTOCONF,
> > - .iotype = UPIO_MEM,
> > - .regshift = 2,
> > - .uartclk = OMAP24XX_BASE_BAUD * 16,
> > - }, {
> > -#endif
> > .flags = 0
> > }
> > };
>
> Can't we fix the extra uart instead of removing it? We just added it!
> It's still there in omap4, right?
This is already fixed. Above piece is not necessary since there is a separate instance for UART4 (serial_platform_data3[])
Regards,
Santosh
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read
2009-09-30 17:31 ` Tony Lindgren
@ 2009-10-01 7:30 ` Roger Quadros
2009-10-01 7:58 ` Alexander Shishkin
2009-10-01 7:58 ` Roger Quadros
1 sibling, 1 reply; 25+ messages in thread
From: Roger Quadros @ 2009-10-01 7:30 UTC (permalink / raw)
To: ext Tony Lindgren
Cc: Gadiyar, Anand, Alexander Shishkin, Felipe Contreras, linux-omap
ext Tony Lindgren wrote:
> * Gadiyar, Anand <gadiyar@ti.com> [090930 10:05]:
>>>>>> Anyway, I haven't been able to make 2.6.31 boot on beagleboard, and
>>>>>> other people report similar issues:
>>>>>> http://www.spinics.net/lists/linux-omap/msg17968.html
>>>>>>
>>>>>> Have you got 2.6.32-rc1 (+fixes) to boot?
>>>>> Hmm, looks like it's musb again. This is what I get on my
>>>>> overo after applying the DEBUG_LL hack from omap-debug branch:
>>>> i've just sent a fix for this musb problem. patch is labelled "twl4030: Fix
>>>> boot with twl4030 usb transceiver enabled"
>>> I can't quite locate it in linux-usb archives (or anywhere within
>>> google's reach). Could you sand it here or provide a link?
>>>
>> Here you go. Patchwork rocks!
>>
>> <http://patchwork.kernel.org/patch/50721/>
>>
>
> Great, thanks. Roger, please send your fix to Samuel for merging.
>
> Meanwhile, I'll apply it into fixes-testing while waiting for it
> to get to mainline via Samuel.
>
> Regards,
>
> Tony
OK Tony, I'll do that.
cheers,
-roger
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read
2009-10-01 7:30 ` Roger Quadros
@ 2009-10-01 7:58 ` Alexander Shishkin
2009-10-01 8:06 ` Roger Quadros
0 siblings, 1 reply; 25+ messages in thread
From: Alexander Shishkin @ 2009-10-01 7:58 UTC (permalink / raw)
To: Roger Quadros
Cc: ext Tony Lindgren, Gadiyar, Anand, Felipe Contreras, linux-omap
2009/10/1 Roger Quadros <ext-roger.quadros@nokia.com>:
> ext Tony Lindgren wrote:
>>
>> * Gadiyar, Anand <gadiyar@ti.com> [090930 10:05]:
>>>>>>>
>>>>>>> Anyway, I haven't been able to make 2.6.31 boot on beagleboard, and
>>>>>>> other people report similar issues:
>>>>>>> http://www.spinics.net/lists/linux-omap/msg17968.html
>>>>>>>
>>>>>>> Have you got 2.6.32-rc1 (+fixes) to boot?
>>>>>>
>>>>>> Hmm, looks like it's musb again. This is what I get on my
>>>>>> overo after applying the DEBUG_LL hack from omap-debug branch:
>>>>>
>>>>> i've just sent a fix for this musb problem. patch is labelled "twl4030:
>>>>> Fix
>>>>> boot with twl4030 usb transceiver enabled"
>>>>
>>>> I can't quite locate it in linux-usb archives (or anywhere within
>>>> google's reach). Could you sand it here or provide a link?
>>>>
>>> Here you go. Patchwork rocks!
>>>
>>> <http://patchwork.kernel.org/patch/50721/>
>>>
>>
>> Great, thanks. Roger, please send your fix to Samuel for merging.
>>
>> Meanwhile, I'll apply it into fixes-testing while waiting for it
>> to get to mainline via Samuel.
>>
>> Regards,
>>
>> Tony
>
> OK Tony, I'll do that.
It doesn't crash any more, but I fail to get it to work either:
/sys/devices/platform/musb_hdrc/mode always says b_idle no matter what
I do and the host never attempts to enumerate it (I have a g_ether
statically compiled in for a gadget). Hints greatly appreciated.
Regards,
--
Alex
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read
2009-09-30 17:31 ` Tony Lindgren
2009-10-01 7:30 ` Roger Quadros
@ 2009-10-01 7:58 ` Roger Quadros
1 sibling, 0 replies; 25+ messages in thread
From: Roger Quadros @ 2009-10-01 7:58 UTC (permalink / raw)
To: ext Tony Lindgren
Cc: Gadiyar, Anand, Alexander Shishkin, Felipe Contreras, linux-omap
ext Tony Lindgren wrote:
> * Gadiyar, Anand <gadiyar@ti.com> [090930 10:05]:
>>>>>> Anyway, I haven't been able to make 2.6.31 boot on beagleboard, and
>>>>>> other people report similar issues:
>>>>>> http://www.spinics.net/lists/linux-omap/msg17968.html
>>>>>>
>>>>>> Have you got 2.6.32-rc1 (+fixes) to boot?
>>>>> Hmm, looks like it's musb again. This is what I get on my
>>>>> overo after applying the DEBUG_LL hack from omap-debug branch:
>>>> i've just sent a fix for this musb problem. patch is labelled "twl4030: Fix
>>>> boot with twl4030 usb transceiver enabled"
>>> I can't quite locate it in linux-usb archives (or anywhere within
>>> google's reach). Could you sand it here or provide a link?
>>>
>> Here you go. Patchwork rocks!
>>
>> <http://patchwork.kernel.org/patch/50721/>
>>
>
> Great, thanks. Roger, please send your fix to Samuel for merging.
>
> Meanwhile, I'll apply it into fixes-testing while waiting for it
> to get to mainline via Samuel.
>
> Regards,
>
> Tony
Tony, i accidentally removed the MMC regulators in my patch. this will break
MMC. Thanks to Felipe Balbi for pointing this out.
i will send v2 for my patch.
cheers,
-roger.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read
2009-10-01 7:58 ` Alexander Shishkin
@ 2009-10-01 8:06 ` Roger Quadros
2009-10-01 8:30 ` Roger Quadros
2009-10-01 8:31 ` Roger Quadros
0 siblings, 2 replies; 25+ messages in thread
From: Roger Quadros @ 2009-10-01 8:06 UTC (permalink / raw)
To: ext Alexander Shishkin
Cc: ext Tony Lindgren, Gadiyar, Anand, Felipe Contreras, linux-omap
ext Alexander Shishkin wrote:
> 2009/10/1 Roger Quadros <ext-roger.quadros@nokia.com>:
>> ext Tony Lindgren wrote:
>>> * Gadiyar, Anand <gadiyar@ti.com> [090930 10:05]:
>>>>>>>> Anyway, I haven't been able to make 2.6.31 boot on beagleboard, and
>>>>>>>> other people report similar issues:
>>>>>>>> http://www.spinics.net/lists/linux-omap/msg17968.html
>>>>>>>>
>>>>>>>> Have you got 2.6.32-rc1 (+fixes) to boot?
>>>>>>> Hmm, looks like it's musb again. This is what I get on my
>>>>>>> overo after applying the DEBUG_LL hack from omap-debug branch:
>>>>>> i've just sent a fix for this musb problem. patch is labelled "twl4030:
>>>>>> Fix
>>>>>> boot with twl4030 usb transceiver enabled"
>>>>> I can't quite locate it in linux-usb archives (or anywhere within
>>>>> google's reach). Could you sand it here or provide a link?
>>>>>
>>>> Here you go. Patchwork rocks!
>>>>
>>>> <http://patchwork.kernel.org/patch/50721/>
>>>>
>>> Great, thanks. Roger, please send your fix to Samuel for merging.
>>>
>>> Meanwhile, I'll apply it into fixes-testing while waiting for it
>>> to get to mainline via Samuel.
>>>
>>> Regards,
>>>
>>> Tony
>> OK Tony, I'll do that.
>
> It doesn't crash any more, but I fail to get it to work either:
> /sys/devices/platform/musb_hdrc/mode always says b_idle no matter what
> I do and the host never attempts to enumerate it (I have a g_ether
> statically compiled in for a gadget). Hints greatly appreciated.
>
> Regards,
> --
> Alex
Can you retry if it works without my patch and reverting commit
66760169492445395c530c812443f58e2cfdb3dc
cheers,
-roger
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read
2009-10-01 8:06 ` Roger Quadros
@ 2009-10-01 8:30 ` Roger Quadros
2009-10-01 8:31 ` Roger Quadros
1 sibling, 0 replies; 25+ messages in thread
From: Roger Quadros @ 2009-10-01 8:30 UTC (permalink / raw)
To: ext Alexander Shishkin
Cc: ext Tony Lindgren, Gadiyar, Anand, Felipe Contreras, linux-omap
[-- Attachment #1: Type: text/plain, Size: 1850 bytes --]
Roger Quadros wrote:
> ext Alexander Shishkin wrote:
>> 2009/10/1 Roger Quadros <ext-roger.quadros@nokia.com>:
>>> ext Tony Lindgren wrote:
>>>> * Gadiyar, Anand <gadiyar@ti.com> [090930 10:05]:
>>>>>>>>> Anyway, I haven't been able to make 2.6.31 boot on beagleboard, and
>>>>>>>>> other people report similar issues:
>>>>>>>>> http://www.spinics.net/lists/linux-omap/msg17968.html
>>>>>>>>>
>>>>>>>>> Have you got 2.6.32-rc1 (+fixes) to boot?
>>>>>>>> Hmm, looks like it's musb again. This is what I get on my
>>>>>>>> overo after applying the DEBUG_LL hack from omap-debug branch:
>>>>>>> i've just sent a fix for this musb problem. patch is labelled "twl4030:
>>>>>>> Fix
>>>>>>> boot with twl4030 usb transceiver enabled"
>>>>>> I can't quite locate it in linux-usb archives (or anywhere within
>>>>>> google's reach). Could you sand it here or provide a link?
>>>>>>
>>>>> Here you go. Patchwork rocks!
>>>>>
>>>>> <http://patchwork.kernel.org/patch/50721/>
>>>>>
>>>> Great, thanks. Roger, please send your fix to Samuel for merging.
>>>>
>>>> Meanwhile, I'll apply it into fixes-testing while waiting for it
>>>> to get to mainline via Samuel.
>>>>
>>>> Regards,
>>>>
>>>> Tony
>>> OK Tony, I'll do that.
>> It doesn't crash any more, but I fail to get it to work either:
>> /sys/devices/platform/musb_hdrc/mode always says b_idle no matter what
>> I do and the host never attempts to enumerate it (I have a g_ether
>> statically compiled in for a gadget). Hints greatly appreciated.
>>
>> Regards,
>> --
>> Alex
>
> Can you retry if it works without my patch and reverting commit
> 66760169492445395c530c812443f58e2cfdb3dc
>
> cheers,
> -roger
>
Also please try the attached patch on l-o HEAD.
It worked for me with file_storage driver.
dd if=/dev/zero of=/tmp/medium bs=1024 count=1024
modprobe g_file_storage file=/tmp/medium
-roger
[-- Attachment #2: 0001-twl4030-Fix-boot-with-twl4030-usb-transceiver-enabl.patch.gz --]
[-- Type: application/x-gzip, Size: 1445 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read
2009-10-01 8:06 ` Roger Quadros
2009-10-01 8:30 ` Roger Quadros
@ 2009-10-01 8:31 ` Roger Quadros
1 sibling, 0 replies; 25+ messages in thread
From: Roger Quadros @ 2009-10-01 8:31 UTC (permalink / raw)
To: ext Alexander Shishkin
Cc: ext Tony Lindgren, Gadiyar, Anand, Felipe Contreras, linux-omap
[-- Attachment #1: Type: text/plain, Size: 1850 bytes --]
Roger Quadros wrote:
> ext Alexander Shishkin wrote:
>> 2009/10/1 Roger Quadros <ext-roger.quadros@nokia.com>:
>>> ext Tony Lindgren wrote:
>>>> * Gadiyar, Anand <gadiyar@ti.com> [090930 10:05]:
>>>>>>>>> Anyway, I haven't been able to make 2.6.31 boot on beagleboard, and
>>>>>>>>> other people report similar issues:
>>>>>>>>> http://www.spinics.net/lists/linux-omap/msg17968.html
>>>>>>>>>
>>>>>>>>> Have you got 2.6.32-rc1 (+fixes) to boot?
>>>>>>>> Hmm, looks like it's musb again. This is what I get on my
>>>>>>>> overo after applying the DEBUG_LL hack from omap-debug branch:
>>>>>>> i've just sent a fix for this musb problem. patch is labelled "twl4030:
>>>>>>> Fix
>>>>>>> boot with twl4030 usb transceiver enabled"
>>>>>> I can't quite locate it in linux-usb archives (or anywhere within
>>>>>> google's reach). Could you sand it here or provide a link?
>>>>>>
>>>>> Here you go. Patchwork rocks!
>>>>>
>>>>> <http://patchwork.kernel.org/patch/50721/>
>>>>>
>>>> Great, thanks. Roger, please send your fix to Samuel for merging.
>>>>
>>>> Meanwhile, I'll apply it into fixes-testing while waiting for it
>>>> to get to mainline via Samuel.
>>>>
>>>> Regards,
>>>>
>>>> Tony
>>> OK Tony, I'll do that.
>> It doesn't crash any more, but I fail to get it to work either:
>> /sys/devices/platform/musb_hdrc/mode always says b_idle no matter what
>> I do and the host never attempts to enumerate it (I have a g_ether
>> statically compiled in for a gadget). Hints greatly appreciated.
>>
>> Regards,
>> --
>> Alex
>
> Can you retry if it works without my patch and reverting commit
> 66760169492445395c530c812443f58e2cfdb3dc
>
> cheers,
> -roger
>
Also please try the attached patch on l-o HEAD.
It worked for me with file_storage driver.
dd if=/dev/zero of=/tmp/medium bs=1024 count=1024
modprobe g_file_storage file=/tmp/medium
-roger
[-- Attachment #2: 0001-twl4030-Fix-boot-with-twl4030-usb-transceiver-enabl.patch.gz --]
[-- Type: application/x-gzip, Size: 1445 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2009-10-01 8:32 UTC | newest]
Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-09-28 19:04 linux-omap git tree updated to v2.6.32-rc1, important changes, please read Tony Lindgren
2009-09-28 21:54 ` Kalle Valo
2009-09-29 14:36 ` green
2009-09-29 10:54 ` Shilimkar, Santosh
2009-09-30 17:55 ` Tony Lindgren
2009-10-01 4:04 ` Shilimkar, Santosh
2009-09-29 17:24 ` Felipe Contreras
2009-09-29 18:26 ` Tony Lindgren
2009-09-29 19:20 ` Alexander Shishkin
2009-09-29 19:26 ` Aguirre Rodriguez, Sergio Alberto
2009-09-29 19:42 ` Alexander Shishkin
2009-09-29 19:30 ` Tony Lindgren
2009-09-29 19:41 ` Alexander Shishkin
2009-09-30 15:53 ` Roger Quadros
2009-09-30 17:02 ` Alexander Shishkin
2009-09-30 17:04 ` Gadiyar, Anand
2009-09-30 17:31 ` Tony Lindgren
2009-10-01 7:30 ` Roger Quadros
2009-10-01 7:58 ` Alexander Shishkin
2009-10-01 8:06 ` Roger Quadros
2009-10-01 8:30 ` Roger Quadros
2009-10-01 8:31 ` Roger Quadros
2009-10-01 7:58 ` Roger Quadros
2009-09-30 14:07 ` Kevin Hilman
2009-09-30 17:25 ` Tony Lindgren
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.