Re: DM3730 without PMIC oops on idle

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Kevin, thank you for your help.

2012/6/27 Kevin Hilman <khilman@xxxxxx>:
> jean-philippe francois <jp.francois@xxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux