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