This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Sitara SDK 05.05, patched kernel with RT patch, doesn't compile anymore

Here I have a Sitara AM335X with its latest SDK v05.05.00. I installed it and I'm able to compile my kernels.

However, I want to use the official RT patches from http://www.kernel.org/pub/linux/kernel/projects/rt/3.2/older/. Since kernel 3.2.0 is delivered with this SDK, I chose http://www.kernel.org/pub/linux/kernel/projects/rt/3.2/older/patch-3.2-rt10.patch.bz2 as the correct patch. With it, I patched my kernel sources - no errors here. After that, I checked if there are any problems by compiling this patched kernel. No problems, my board just boots fine.

Then I really wanted to use the new RT features, so I backed up ti-sdk-am335x-evm-05.05.00.00/board-support/linux-3.2.0-psp04.06.00.08.sdk/arch/arm/configs/tisdk_am335x-evm_defconfig and changed the option "CONFIG_PREEMPT_NONE=y" to "CONFIG_PREEMPT_RT_FULL=y".

If I now compile this, I get an error when compiling drivers/pwm/pwm.c:

...
CC drivers/pwm/pwm.o
drivers/pwm/pwm.c: In function 'pwm_set_frequency':
drivers/pwm/pwm.c:291:2: error: expected expression before 'do'
make[3]: *** [drivers/pwm/pwm.o] Error 1
make[2]: *** [drivers/pwm] Error 2
make[1]: *** [drivers] Error 2
make[1]: Leaving directory `/home/user/ti-sdk-am335x-evm-05.05.00.00/board-support/linux-3.2.0-psp04.06.00.08.sdk'
make: *** [linux] Error 2

This is the function near this line:

282 int pwm_set_frequency(struct pwm_device *p, unsigned long freq)
283 {
284 struct pwm_config c;
285
286 if (!freq)
287 return -EINVAL;
288
289 c.config_mask = BIT(PWM_CONFIG_PERIOD_TICKS),
290 c.period_ticks = pwm_ns_to_ticks(p, (NSEC_PER_SEC / freq)),
291 spin_lock(&p->pwm_lock);
292 p->period_ns = NSEC_PER_SEC / freq;
293 spin_unlock(&p->pwm_lock);
294 return pwm_config(p, &c);
295 }
296 EXPORT_SYMBOL(pwm_set_frequency);

So the error seems to be related with the call of spin_lock, which surely gets changed by the RT patch. Has anyone a hint for me? I'm quite new to this matter... :(
I appreciate any help! 

  • Andre,

    the RT patch is from mainline, as is probably the original AM335x kernel. But then TI adds drivers and tests them. But we don't test so far with RT patches. So it might be there are in-compatabilities and it is up to you to fix them. I assume this requires some know how in how to write drivers in the context of RT-preemption.

    Regards.

  • Please do not misunderstand me, I do not blame TI for this. I just hope that someone may have a hint or a solution.

    Removing this PWM driver from the source tree let me compile the kernel successfully, so this seems to be the only one problematic driver. I also contacted the guys at the linux-rt-users mailing list, maybe they have an idea. 

  • Andre,

    if this works for you fine. Especially if you don't plan to use PWM. But the fact it compiles doesn't mean it will work in all cases... Testing is usually the largest part of the integration work. The patches are often minimal.

    Regards.

  • Well, I changed my mind: Now I do blame TI for this - just a little bit (I was also blind). If you look at the function pwm_set_frequency() a little bit closer, you will see at lines 289 and 290 that there are commas at the end of the line, not semicolons (thanks to Paul from the mailing list). If I fix this, the code compiles without error.

    So the only remaining question is: why does the code compile if I do not use "CONFIG_PREEMPT_RT_FULL=y"?

  • 289 > c.config_mask = BIT(PWM_CONFIG_PERIOD_TICKS);
    290 > c.period_ticks = pwm_ns_to_ticks(p, (NSEC_PER_SEC / freq));

    289 < c.config_mask = BIT(PWM_CONFIG_PERIOD_TICKS),
    290 < c.period_ticks = pwm_ns_to_ticks(p, (NSEC_PER_SEC / freq)),




  • Dear Andre,


    We are also trying to make our system hard real time & I hit upon this thread. Thanks for sharing this information. The patch got applied without any problem. As mentioned here, build error occured in pwm.c . After correction it got compiled correctly and got the uImage.

    Were you able to see performance improvement in am335x ?  How did you test it basically ? We are yet to test this.

  • Well, providing a realtime environment was a requirement from a project partner, so they got it. I didn't have done any further tests whether or not there were improvements.