2009/9/29 Aguirre Rodriguez, Sergio Alberto <saaguirre@xxxxxx>: > From: linux-omap-owner@xxxxxxxxxxxxxxx [linux-omap-owner@xxxxxxxxxxxxxxx] On Behalf Of Alexander Shishkin [virtuoso@xxxxxxxxx] > Sent: Tuesday, September 29, 2009 2:20 PM >> 2009/9/29 Tony Lindgren <tony@xxxxxxxxxxx>: >> > * Felipe Contreras <felipe.contreras@xxxxxxxxx> [090929 10:24]: >> >> On Mon, Sep 28, 2009 at 10:04 PM, Tony Lindgren <tony@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
