Re: [Xenomai] ARM kernel issue

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On 10/18/2012 11:07 AM, Henri Roosen wrote:
> On Thu, Oct 18, 2012 at 11:00 AM, Henri Roosen <henriroosen@gmail.com> wrote:
>> On Thu, Oct 18, 2012 at 10:21 AM, Henri Roosen <henriroosen@gmail.com> wrote:
>>> On Thu, Oct 18, 2012 at 6:20 AM, Gilles Chanteperdrix
>>> <gilles.chanteperdrix@xenomai.org> wrote:
>>>> On 10/17/2012 11:54 PM, Stefan Videv wrote:
>>>>
>>>>> Uncompressing Linux... done, booting the kernel.
>>>>> [    0.000000] Initializing cgroup subsys cpuset
>>>>> [    0.000000] Initializing cgroup subsys cpu
>>>>> [    0.000000] Linux version 3.2.31-psp24 (stefan@stefan-VirtualBox)
>>>>> (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #1 Wed Oct 17
>>>>> 17:09:40 BST 2012
>>>>> [    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7),
>>>>> cr=10c53c7d
>>>>> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
>>>>> instruction cache
>>>>> [    0.000000] Machine: am335xevm
>>>>
>>>>
>>>> You are trying to run Xenomai on a machine for which the I-pipe patch
>>>> does not contain the support. There is no miracle:
>>>> - either you add that support yourself
>>>
>>> I am currently trying to bring up Xenomai on the AM335x EVM board too.
>>> It seems Stephan from the thread referred to in the post was able to
>>> successfully port Xenomai on the Beaglebone which uses the same chip.
>>> So I'm using a similar approach:
>>>
>>> - kernel sources from
>>> git://arago-project.org/git/projects/linux-am33x.git, tag
>>> v3.2_AM335xPSP_04.06.00.08, .config am335x_evm_defconfig.
>>> - merged v3.2.21
>>> - merged core-3.2
>>> - changed arch/arm/mach-omap2/irq.c omap_intc_handle_irq to call
>>> ipipe_handle_multi_irq instead of handle_IRQ.
>>> - cnanged arch/arm/mach-omap2/timer.c OMAP_SYS_TIMER_INIT(3_am33xx,
>>> like Stephan suggested.
>>>
>>> With all this, the kernel boots correctly only without the ipipe.
>>>
>>> With the ipipe it hangs after 1 second during boot
>>> ..
>>> [    0.000000] OMAP clockevent source: GPTIMER2 at 24000000 Hz
>>> [    0.000000] OMAP clocksource: GPTIMER3 at 24000000 Hz
>>> [    0.000000] I-pipe, 24.000 MHz clocksource
>>> [    0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps
>>> every 178956ms
>>> [    0.000000] Interrupt pipeline (release #1)
>>> [    0.000000] Console: colour dummy device 80x30
>>> [    0.000519] Calibrating delay loop... 718.02 BogoMIPS (lpj=3590144)
>>> [ 0.119053] pid_max: default: 32768 minimum: 301
>>> [    0.119208] Security Framework initialized
>>> [    0.119329] Mount-cache hash table entries: 512
>>> ...
>>> [    1.002498] _regulator_get: 2-0018 supply Vdd not found, using
>>> dummy regulator
>>> [    1.010148] _regulator_get: 2-0018 supply Vdd_IO not found, using
>>> dummy regulator
>>>
>>> A printk in __ipipe_tsc_update which prints every 4096 calls shows:
>>>
>>> Any suggestions how to debug the clocksource? I put a printk in
>>>
>>> [    0.996420] Configure Bluetooth Enable pin...
>>> [    1.002498] _regulator_get: 2-0018 supply Vdd not found, using
>>> dummy regulator
>>> [    1.010148] _regulator_get: 2-0018 supply Vdd_IO not found, using
>>> dummy regulator
>>> [   82.133193] __ipipe_tsc_update
>>> [  164.071647] __ipipe_tsc_update
>>> [   67.053119] __ipipe_tsc_update
>>> [  148.991560] __ipipe_tsc_update
>>> [   51.973047] __ipipe_tsc_update
>>>
>>
>> Forcing clocksource="gp timer" at the kernel commandline makes the
>> board boot with the ipipe enabled.
> 
> Ok, the board boots now with clocksource ipipe_tsc. I had to change:
> 
> OMAP_SYS_TIMER_INIT(3_am33xx, 2, AM33XX_CLKEV_SOURCE, 3, AM33XX_MPU_SOURCE)
> to
> OMAP_SYS_TIMER_INIT(3_am33xx, 2, AM33XX_CLKEV_SOURCE, 1, AM33XX_MPU_SOURCE)
> 
> Can someone explain why / confirm this is correct?

By the way, it is probably better to use GP timer 1 as clock event than
as clock source as it has a higher latency (at least on OMAP3), this is
the reason why we try and avoid using it.

-- 
					    Gilles.