Hi
To support our board which has a 26 MHz oscillator instead the 24 MHz of the EVM, I've just modified the PLLs N-divisors value in SPL/U-Boot code in arch/arm/include/asm/arch-ti81xx/clocks_am335x.h: 25 instead of 23. Is it enough or do I need further changes?
I'm asking this because everything seemed ok with SDK 5.03 Kernel (PSP 04.06.00.03), which boots with these logs...
[ 0.000000] OMAP clockevent source: GPTIMER1 at 26000000 Hz[ 0.000000] OMAP clocksource: GPTIMER2 at 26000000 Hz[ 0.000000] sched_clock: 32 bits at 26MHz, resolution 38ns, wraps every 165191ms
...but after I moved to PSP 04.06.00.06, kernel boots detecting wrong frequency:
[ 0.000000] OMAP clockevent source: GPTIMER1 at 24000000 Hz[ 0.000000] OMAP clocksource: GPTIMER2 at 24000000 Hz
I had a quick look at kernel code, file arch/arm/mach-omap2/clock33xx_data.c: in PSP 04.06.00.06 it seems missing something already present in PSP 04.06.00.03 and now present also in git staging tree version, that I think can be related to the issue:
PSP 04.06.00.06:
static struct clk sys_clkin_ck = { .name = "sys_clkin_ck", .rate = 24000000, .ops = &clkops_null,};
PSP 04.06.00.03 and staging branch:
/* Oscillator clock *//* 19.2, 24, 25 or 26 MHz */static const struct clksel sys_clkin_sel[] = { { .parent = &virt_19_2m_ck, .rates = div_1_0_rates }, { .parent = &virt_24m_ck, .rates = div_1_1_rates }, { .parent = &virt_25m_ck, .rates = div_1_2_rates }, { .parent = &virt_26m_ck, .rates = div_1_3_rates }, { .parent = NULL },};/* sys_clk_in */static struct clk sys_clkin_ck = { .name = "sys_clkin_ck", .parent = &virt_24m_ck, .init = &omap2_init_clksel_parent, .clksel_reg = AM33XX_CONTROL_STATUS, .clksel_mask = AM33XX_SYSBOOT1, .clksel = sys_clkin_sel, .ops = &clkops_null, .recalc = &omap2_clksel_recalc,};
Any suggestion to understand and solve the issue?Is PSP 04.06.00.06 missing some other specific features already available in previous PSP?
Thanks. Regards,
Max
Max, you also need to change SYSBOOT[15:14] = 11 on the board. Refer to table 26-7 in the TRM. This will allow the ROM and your code to comprehend the correct input frequency.
Regards,
James
Hi James, thanks for you answer. Yes, of course, this was in charge of my HW colleague, and pins have been pulled-up properly.
My doubts are related to software because of different behaviours of old and new kernel.
Max,
There is new release label available which has clean and better implementation of clock tree, I would recommend you to use that branch and let me know how it works for you.
Release Tag - v3.2_AM335xPSP_04.06.00.07
Thanks,
Vaibhav
Hi Vaibhav,
I'm trying kernel on git branch AM335XPSP_04.06.00.07 as you suggested. Now I see:
[ 0.000000] OMAP clockevent source: GPTIMER2 at 26000000 Hz[ 0.000000] OMAP clocksource: GPTIMER1 at 32768 Hz[ 0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999msFirst line now is ok as expected, but I have doubts for next lines. GPTIMER1 previously was at 24 or 26 MHz and now at 32 KHz: resolution is much more lower, which will be the consequences, if any? Do I have to take care of?
I have an issue building this kernel: am335x-pm-firmware.bin is missing, causing error at build time. I made a quick workaround to build with success, but which are the exact features I have to disable or enable in kernel configuration to avoid this issue? Which is the purpose of this firmware binary file, and where can I get it?
Thanks in advance for your further help.
Recently we have added Suspend-To-Ram feature into the kernel, all the issues you are referring above, are due to this new feature addition into the kernel.
1. GPTIMER1 at 32k
GPTIMER1 at 32K is expected and its new important change, required from power management support. When you suspend the system, you need atleast system timer keep ticking, right? So we must use 32k clock, we do not have any option here.
2. Firmware
This firmware gets loaded into M3, to support power management (suspend-to-ram). You can get the code and pre-built binary at
http://arago-project.org/git/projects/?p=am33x-cm3.git;a=summary
Make sure that you copy it into firmware/ directory of your kernel sources and build the kernel again.
3. How to disable it
Disable complete PM support from the kernel.
Interesting feature: I will evaluate if it can be useful for our product. In case it won't, could I change GPTIMER1 to have a high resolution clock?
In the meantime I'm trying to build and use kernel without it: I have just unselected SUSPEND (and therefore PM_SLEEP too) in menuconfig and set EXTRA_FIRMWARE to empty string. This is similar to 04.06.00.06 kernel configuration: PM and PM_RUNTIME are still selected (depending on ARCH_OMAP2PLUS_TYPICAL). Is this configuration expected to work? I have a null pointer deference when I rmmod mass storage usb gadget (let me know if you are interested in full log):
[ 46.772961] musb g_mass_storage gadget disconnected.[ 46.778186] Unable to handle kernel NULL pointer dereference at virtual address 0000000c[ 46.786642] pgd = cf028000[ 46.789465] [0000000c] *pgd=8fb76831, *pte=00000000, *ppte=00000000[ 46.796035] Internal error: Oops: 17 [#1][ 46.800221] Modules linked in: g_mass_storage(-)[ 46.805063] CPU: 0 Not tainted (3.2.0-dirty #2)[ 46.810185] PC is at composite_disconnect+0x20/0x60 [g_mass_storage][ 46.816832] LR is at composite_disconnect+0x14/0x60 [g_mass_storage][ 46.823474] pc : [<bf001b4c>] lr : [<bf001b40>] psr: a0000193[ 46.823485] sp : cf22bc20 ip : cf22bc20 fp : cf22bc34[ 46.835473] r10: 000000f0 r9 : 00000098 r8 : 00000020[ 46.840932] r7 : 00000098 r6 : cf9050b8 r5 : a0000193 r4 : 00000000[ 46.847750] r3 : bf001b2c r2 : 000010c8 r1 : 00000000 r0 : 00000000[ 46.854575] Flags: NzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user[ 46.862121] Control: 10c5387d Table: 8f028019 DAC: 00000015[ 46.868123] Process rmmod (pid: 1821, stack limit = 0xcf22a2f0)[ 46.874308] Stack: (0xcf22bc20 to 0xcf22c000)[ 46.878868] bc20: cf904000 c0608fe0 cf22bc54 cf22bc38 c029bcb4 bf001b38 cf904000 00000001...[ 47.143926] Backtrace: [ 47.146529] [<bf001b2c>] (composite_disconnect+0x0/0x60 [g_mass_storage]) from [<c029bcb4>] (musb_g_disconnect+0xb0/0x1cc)[ 47.158069] r5:c0608fe0 r4:cf904000[ 47.161828] [<c029bc04>] (musb_g_disconnect+0x0/0x1cc) from [<c0297374>] (musb_interrupt+0x64c/0x10a4)[ 47.171551] r7:c0608a40 r6:c062f918 r5:00000001 r4:cf904000[ 47.177499] [<c0296d28>] (musb_interrupt+0x0/0x10a4) from [<c02a32c8>] (ti81xx_interrupt+0x268/0x528)[ 47.187150] [<c02a3060>] (ti81xx_interrupt+0x0/0x528) from [<c006de8c>] (handle_irq_event_percpu+0x58/0x1a4)[ 47.197428] [<c006de34>] (handle_irq_event_percpu+0x0/0x1a4) from [<c006e008>] (handle_irq_event+0x30/0x40)[ 47.207618] [<c006dfd8>] (handle_irq_event+0x0/0x40) from [<c006ff24>] (handle_level_irq+0x8c/0x100)[ 47.217159] r4:c05d2c24 r3:00020000[ 47.220911] [<c006fe98>] (handle_level_irq+0x0/0x100) from [<c006d77c>] (generic_handle_irq+0x38/0x48)[ 47.230633] r4:c05e2708 r3:c006fe98[ 47.234401] [<c006d744>] (generic_handle_irq+0x0/0x48) from [<c00150e4>] (handle_IRQ+0x40/0x8c)[ 47.243501] [<c00150a4>] (handle_IRQ+0x0/0x8c) from [<c0008550>] (omap3_intc_handle_irq+0x50/0x54)[ 47.252859] r6:ffffffff r5:cf22bdb0 r4:fa200000 r3:00040000[ 47.258804] [<c0008500>] (omap3_intc_handle_irq+0x0/0x54) from [<c0013e40>] (__irq_svc+0x40/0x60)[ 47.268074] Exception stack(0xcf22bdb0 to 0xcf22bdf8)[ 47.273353] bda0: d081c400 c062f918 00000000 c0295924[ 47.281904] bdc0: cf904000 d081c500 00000000 c062f918 cf904000 cf904000 d081c400 cf22be2c[ 47.290453] bde0: cf22bdf8 cf22bdf8 c0296078 c0296080 20000013 ffffffff[ 47.297361] r5:20000013 r4:c0296080[ 47.301118] [<c0295de4>] (musb_restore_context+0x0/0x2e4) from [<c0296108>] (musb_runtime_resume+0x2c/0x34)[ 47.311319] [<c02960dc>] (musb_runtime_resume+0x0/0x34) from [<c02192f4>] (pm_generic_runtime_resume+0x34/0x48)[ 47.321876] [<c02192c0>] (pm_generic_runtime_resume+0x0/0x48) from [<c021a664>] (rpm_resume+0x27c/0x4b4)[ 47.331793] [<c021a3e8>] (rpm_resume+0x0/0x4b4) from [<c021aac8>] (__pm_runtime_resume+0x38/0x50)[ 47.341075] [<c021aa90>] (__pm_runtime_resume+0x0/0x50) from [<c029ae14>] (musb_gadget_stop+0x200/0x278)...
Regards
The error does not depend on SUSPEND: it occurs even if I build kernel with SUSPEND selected.
And it occurs only on our custom board, and not on AM335x EVM board.
By the way it does not occur when using PSP 04.06.00.06 kernel: I wonder what it might depend on.