Hi Kevin, thank you for your help. 2012/6/27 Kevin Hilman <khil...@ti.com>: > jean-philippe francois <jp.franc...@cynove.com> writes: > >> Hi, >> >> My board does not have any Power Management IC. >> Without the following patch, the bood ends with an oops. >> How can I further debug this, ie trace through the assembly >> in arch/arm/mach-omap2/sleep34xx.S ? > > The assembly code that is faulting has nothing to do with interaction > with the PMIC. > > Some more comments below ... > >> -- >> Patch needed to boot to userspace : >> >> Index: linux-3.4.3/arch/arm/mach-omap2/pm34xx.c >> =================================================================== >> --- linux-3.4.3.orig/arch/arm/mach-omap2/pm34xx.c 2012-06-17 >> 20:21:44.000000000 +0200 >> +++ linux-3.4.3/arch/arm/mach-omap2/pm34xx.c 2012-06-22 16:26:38.000000000 >> +0200 >> @@ -403,7 +403,7 @@ >> trace_power_start(POWER_CSTATE, 1, smp_processor_id()); >> trace_cpu_idle(1, smp_processor_id()); >> >> - omap_sram_idle(); >> + // omap_sram_idle(); > > FYI... you can get the same effect without patching the kernel by adding > 'nohlt' to the kernel command line. That avoids entering the idle loop > alltogether. >
Good to know :) >> clock: disabling unused clocks to save power >> Unable to handle kernel NULL pointer dereference at virtual address 00000000 >> pgd = c0004000 >> [00000000] *pgd=00000000 >> Internal error: Oops: 80000005 [#1] PREEMPT ARM >> Modules linked in: >> CPU: 0 Tainted: G W (3.4.3 #2) >> PC is at 0x0 >> LR is at omap34xx_do_sram_idle+0x8/0x10 > > This is a branch to 0x0, probably in omap34xx_cpu_suspend (in > sleep34xx.S) which was just called by omap34xx_do_sram_idle. > > My first guess would be that the omap3_do_wfi_sram address is zero. Can > you dump the value in omap_push_sram_idle()? If that looks good, do you > have a debugger setup so you can single step into omap34xx_cpu_suspend() > to find out where this is failing? > Thank you for pointing me in the right direction. My board code was not calling omap_sdrc_init(...), which in turns calls omap_sram_init, where all the sram pushing takes place. Now I safely boot to userspace, but have random crashes when waking up from idle, where random refers to the oops log, not the occurence. I suspect memory corruption problem, which could be due to ddr going into self refresh, right ? Currently I call omap_sdrc_init with NULL arguments, but a lot of boards do the same thing. How are the omap_sdrc_init args related to self refreh ? In other words, if ddr parameters are correctly set in x-loader, do I also need omap_sdrc_params in linux for idle to work ? Regards, Jean-Philippe François -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
