linux-imx-3.10.9 with preempt-rt patch

linux-imx-3.10.9 with preempt-rt patch

[Jacob Kroon]

[-- Attachment #1.1: Type: text/plain, Size: 956 bytes --]

Hi,

So with this mail I hope I can start get the ball rolling with enabling the
Freescale kernel to build with the PREEMPT RT patch.
What I have sofar is Freescales 3.10.9 kernel + official 3.10.9-rt-patch
(See [1]) + minor fixes. I also had to set NR_CPUS to be less than the
default 4 in the default kernel config, otherwise I ran into some spin lock
NULL pointer dereferences in the Vivante physical-to-virtual memory
location conversion.

The attached patch was necessary in order to get the Vivante GPU kernel
driver to build.

I'm using a Wandboard Solo + an Qt5.2 QtQuick application.
While ping-flooing the Solo and running hackbench on the target, cyclictest
gives me an average of ~30 us, ~150 us max latency.

However, occasionally I get a kernel oops, and need to restart the board.
Oops mesage is also attached.

  -- Jacob

[1]
https://www.kernel.org/pub/linux/kernel/projects/rt/3.10/older/patch-3.10.9-rt5.patch.xz

[-- Attachment #1.2: Type: text/html, Size: 1192 bytes --]

[-- Attachment #2: oops.txt --]
[-- Type: text/plain, Size: 3884 bytes --]

Unable to handle kernel NULL pointer dereference at virtual address 0000004f
pgd = 8c5e0000
[0000004f] *pgd=1c489831, *pte=00000000, *ppte=00000000
Internal error: Oops: 17 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 354 Comm: QSGRenderThread Not tainted 3.10.9-rt5-monkey+gdbf364b #1
task: 8c7ce400 ti: 8c516000 task.ti: 8c516000
PC is at gckCOMMAND_Commit+0x210/0xa44
LR is at 0x139f8
pc : [<804f4c64>]    lr : [<000139f8>]    psr: 800f0013
sp : 8c517c18  ip : 90043000  fp : 8c517d94
r10: 68668038  r9 : ffffffff  r8 : 8c517c70
r7 : 00000000  r6 : 68621f08  r5 : 00000000  r4 : 8c23ee40
r3 : 8c4a6380  r2 : 000008b8  r1 : 00000000  r0 : 00000000
Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 10c53c7d  Table: 1c5e004a  DAC: 00000015
Process QSGRenderThread (pid: 354, stack limit = 0x8c516238)
Stack: (0x8c517c18 to 0x8c518000)
7c00:                                                       00000000 00000000
7c20: 8c517c54 8c517c30 20043000 90043000 00000748 000000b8 00001000 68ce5948
7c40: 8c23ed80 8c517c50 807076e4 00000001 20193948 00000008 00000020 00000008
7c60: 00000010 8cf09680 813b52c0 00000000 42444d43 00000000 00000000 00000000
7c80: 00000000 00000000 00000000 00000009 68cd2000 00000000 00020000 00013948
7ca0: 000139f8 0000c5f8 68ce59e8 00000000 000139e8 00000000 00000000 8c516020
7cc0: 00000057 00000000 f4000100 00000001 8c517cf4 8c517ce0 80032134 800923d8
7ce0: 8c517d04 8c517cf0 8005af64 8007aad4 40000000 8c516000 600f0013 ffffffff
7d00: 8c517d6c 8000e4e0 8c516000 807063a0 8c517d34 8c517d20 807063a0 80059e14
7d20: 00000010 804f3020 8c517d94 8c517d38 8000e50c 80706354 00000000 00000000
7d40: 00000000 8c036000 00000000 8c1d4900 8c23ee40 00000000 00000001 682b2ac8
7d60: 00000000 8c517d94 8c517d20 8c517e38 8c1d4900 8c23ee40 00000000 00000001
7d80: 682b2ac8 00000000 8c517e14 8c517d98 804f3820 804f4a60 682d1f20 00000149
7da0: 800759d8 80705c8c 8c517df4 8c517db8 00000000 00000000 00000000 00000000
7dc0: 00000149 8007aad4 00000001 8c516000 8c517df4 8c517de0 8005b03c 8005af5c
7de0: 80f02a38 80706b34 fffffffb 8c36bc00 8c4f0c00 8c516018 8c516000 00007530
7e00: 682b2ac8 00000000 8c517f0c 8c517e18 804ebbf8 804f3038 682b2b08 00000000
7e20: 000000a8 00000000 682b2b08 00000000 000000a8 00000000 00000013 00000001
7e40: 00000000 69e01000 00000005 75ab987c 00000000 6b26e990 00000007 00000000
7e60: 68621f08 00000000 68668038 00000000 682d1f20 00000000 00000011 00000000
7e80: 00000000 00000000 00000780 00000438 682b2b74 69e01000 0000000f 00000000
7ea0: 00000000 00000000 00000149 00000000 00000004 682b2c8c 00000000 75a0fac8
7ec0: 75ab988c 75ab9898 6b26bc10 75a10808 6b26bc10 00000001 00000000 00000780
7ee0: 8c517f2c 00007530 8c86df00 00000001 682b2ac8 8c4e9050 682b2ac8 00000000
7f00: 8c517f74 8c517f10 80118a20 804ebae4 00000000 8c516018 00000057 600f0193
7f20: 8c517f54 00000001 00000000 00000001 00000000 00000081 01cf26e8 80122c14
7f40: 00000001 00000003 8c517f74 00007530 00000003 00000001 682b2ac8 8c86df00
7f60: 8c516000 00000000 8c517fa4 8c517f78 80118c30 8011860c 8c517f90 00000001
7f80: 00000000 00002710 00007530 75ab9804 00000036 8000eb24 00000000 8c517fa8
7fa0: 8000e900 80118bf4 00002710 00007530 00000003 00007530 682b2ac8 01cdf008
7fc0: 00002710 00007530 75ab9804 00000036 68621ee8 68668038 00000000 00000000
7fe0: 75ab5cc0 682b2ab4 75aa27e4 7605266c 200f0010 00000003 1ff7e821 1ff7ec21
[<804f4c64>] (gckCOMMAND_Commit+0x210/0xa44) from [<804f3820>] (gckKERNEL_Dispatch+0x7f4/0x1268)
[<804f3820>] (gckKERNEL_Dispatch+0x7f4/0x1268) from [<804ebbf8>] (drv_ioctl+0x120/0x284)
[<804ebbf8>] (drv_ioctl+0x120/0x284) from [<80118a20>] (do_vfs_ioctl+0x420/0x5e8)
[<80118a20>] (do_vfs_ioctl+0x420/0x5e8) from [<80118c30>] (SyS_ioctl+0x48/0x74)
[<80118c30>] (SyS_ioctl+0x48/0x74) from [<8000e900>] (ret_fast_syscall+0x0/0x30)
Code: 0a000155 e5943060 e1530009 0a0000fa (e599c050) 
---[ end trace 0000000000000002 ]---

[-- Attachment #3: rt-fixes.patch --]
[-- Type: text/x-patch, Size: 2224 bytes --]

Index: git/drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_os.c
===================================================================
--- git.orig/drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_os.c
+++ git/drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_os.c
@@ -2959,7 +2959,7 @@ gckOS_CreateMutex(
     gcmkONERROR(gckOS_Allocate(Os, gcmSIZEOF(struct mutex), Mutex));
 
     /* Initialize the mutex. */
-    mutex_init(*Mutex);
+    mutex_init((struct mutex*)*Mutex);
 
     /* Return status. */
     gcmkFOOTER_ARG("*Mutex=0x%X", *Mutex);
@@ -3004,7 +3004,7 @@ gckOS_DeleteMutex(
     gcmkVERIFY_ARGUMENT(Mutex != gcvNULL);
 
     /* Destroy the mutex. */
-    mutex_destroy(Mutex);
+    mutex_destroy((struct mutex*)Mutex);
 
     /* Free the mutex structure. */
     gcmkONERROR(gckOS_Free(Os, Mutex));
@@ -7730,7 +7730,7 @@ gckOS_WaitSignal(
 
     might_sleep();
 
-    spin_lock_irq(&signal->obj.wait.lock);
+    raw_spin_lock_irq(&signal->obj.wait.lock);
 
     if (signal->obj.done)
     {
@@ -7760,9 +7760,8 @@ gckOS_WaitSignal(
             : Wait * HZ / 1000;
 #endif
 
-        DECLARE_WAITQUEUE(wait, current);
-        wait.flags |= WQ_FLAG_EXCLUSIVE;
-        __add_wait_queue_tail(&signal->obj.wait, &wait);
+        DEFINE_SWAITER(wait);
+        swait_prepare_locked(&signal->obj.wait, &wait);
 
         while (gcvTRUE)
         {
@@ -7774,9 +7773,9 @@ gckOS_WaitSignal(
             }
 
             __set_current_state(TASK_INTERRUPTIBLE);
-            spin_unlock_irq(&signal->obj.wait.lock);
+            raw_spin_unlock_irq(&signal->obj.wait.lock);
             timeout = schedule_timeout(timeout);
-            spin_lock_irq(&signal->obj.wait.lock);
+            raw_spin_lock_irq(&signal->obj.wait.lock);
 
             if (signal->obj.done)
             {
@@ -7840,7 +7839,7 @@ gckOS_WaitSignal(
             }
         }
 
-        __remove_wait_queue(&signal->obj.wait, &wait);
+        swait_finish_locked(&signal->obj.wait, &wait);
 
 #if gcdDETECT_TIMEOUT
         if (complained)
@@ -7853,7 +7852,7 @@ gckOS_WaitSignal(
 #endif
     }
 
-    spin_unlock_irq(&signal->obj.wait.lock);
+    raw_spin_unlock_irq(&signal->obj.wait.lock);
 
 OnError:
     /* Return status. */

Re: linux-imx-3.10.9 with preempt-rt patch

[Jacob Kroon]

[-- Attachment #1.1: Type: text/plain, Size: 1308 bytes --]

Hi,
Some further progress on the RT-patch support that I forgot.
The oops seemed to be caused by a comparison mixup of NULL or -1.
See attached patch. Comments would be appreciated.
Regards Jacob


On Sat, Jan 25, 2014 at 9:29 PM, Jacob Kroon <jacob.kroon@gmail.com> wrote:

> Hi,
>
> So with this mail I hope I can start get the ball rolling with enabling
> the Freescale kernel to build with the PREEMPT RT patch.
> What I have sofar is Freescales 3.10.9 kernel + official 3.10.9-rt-patch
> (See [1]) + minor fixes. I also had to set NR_CPUS to be less than the
> default 4 in the default kernel config, otherwise I ran into some spin lock
> NULL pointer dereferences in the Vivante physical-to-virtual memory
> location conversion.
>
> The attached patch was necessary in order to get the Vivante GPU kernel
> driver to build.
>
> I'm using a Wandboard Solo + an Qt5.2 QtQuick application.
> While ping-flooing the Solo and running hackbench on the target,
> cyclictest gives me an average of ~30 us, ~150 us max latency.
>
> However, occasionally I get a kernel oops, and need to restart the board.
> Oops mesage is also attached.
>
>   -- Jacob
>
> [1]
> https://www.kernel.org/pub/linux/kernel/projects/rt/3.10/older/patch-3.10.9-rt5.patch.xz
>



-- 
  -- Jacob

[-- Attachment #1.2: Type: text/html, Size: 1884 bytes --]

[-- Attachment #2: rt-fixes.patch --]
[-- Type: text/x-patch, Size: 3162 bytes --]

Index: git/drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_os.c
===================================================================
--- git.orig/drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_os.c
+++ git/drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_os.c
@@ -2959,7 +2959,7 @@ gckOS_CreateMutex(
     gcmkONERROR(gckOS_Allocate(Os, gcmSIZEOF(struct mutex), Mutex));
 
     /* Initialize the mutex. */
-    mutex_init(*Mutex);
+    mutex_init((struct mutex*)*Mutex);
 
     /* Return status. */
     gcmkFOOTER_ARG("*Mutex=0x%X", *Mutex);
@@ -3004,7 +3004,7 @@ gckOS_DeleteMutex(
     gcmkVERIFY_ARGUMENT(Mutex != gcvNULL);
 
     /* Destroy the mutex. */
-    mutex_destroy(Mutex);
+    mutex_destroy((struct mutex*)Mutex);
 
     /* Free the mutex structure. */
     gcmkONERROR(gckOS_Free(Os, Mutex));
@@ -7730,7 +7730,7 @@ gckOS_WaitSignal(
 
     might_sleep();
 
-    spin_lock_irq(&signal->obj.wait.lock);
+    raw_spin_lock_irq(&signal->obj.wait.lock);
 
     if (signal->obj.done)
     {
@@ -7760,9 +7760,8 @@ gckOS_WaitSignal(
             : Wait * HZ / 1000;
 #endif
 
-        DECLARE_WAITQUEUE(wait, current);
-        wait.flags |= WQ_FLAG_EXCLUSIVE;
-        __add_wait_queue_tail(&signal->obj.wait, &wait);
+        DEFINE_SWAITER(wait);
+        swait_prepare_locked(&signal->obj.wait, &wait);
 
         while (gcvTRUE)
         {
@@ -7774,9 +7773,9 @@ gckOS_WaitSignal(
             }
 
             __set_current_state(TASK_INTERRUPTIBLE);
-            spin_unlock_irq(&signal->obj.wait.lock);
+            raw_spin_unlock_irq(&signal->obj.wait.lock);
             timeout = schedule_timeout(timeout);
-            spin_lock_irq(&signal->obj.wait.lock);
+            raw_spin_lock_irq(&signal->obj.wait.lock);
 
             if (signal->obj.done)
             {
@@ -7840,7 +7839,7 @@ gckOS_WaitSignal(
             }
         }
 
-        __remove_wait_queue(&signal->obj.wait, &wait);
+        swait_finish_locked(&signal->obj.wait, &wait);
 
 #if gcdDETECT_TIMEOUT
         if (complained)
@@ -7853,7 +7852,7 @@ gckOS_WaitSignal(
 #endif
     }
 
-    spin_unlock_irq(&signal->obj.wait.lock);
+    raw_spin_unlock_irq(&signal->obj.wait.lock);
 
 OnError:
     /* Return status. */
Index: git/drivers/mxc/gpu-viv/hal/kernel/gc_hal_kernel_command.c
===================================================================
--- git.orig/drivers/mxc/gpu-viv/hal/kernel/gc_hal_kernel_command.c
+++ git/drivers/mxc/gpu-viv/hal/kernel/gc_hal_kernel_command.c
@@ -1068,6 +1068,7 @@ OnError:
 **
 **      Nothing.
 */
+#include <linux/printk.h>
 gceSTATUS
 gckCOMMAND_Commit(
     IN gckCOMMAND Command,
@@ -1265,8 +1266,13 @@ gckCOMMAND_Commit(
     waitLinkPhysical = (gctUINT8_PTR) Command->physical + offset;
     waitLinkLogical  = (gctUINT8_PTR) Command->logical  + offset;
 
+    if ( (int)Context == 0xffffffff )
+    {
+        printk("crash?");
+    }
+
     /* Context switch required? */
-    if (Context == gcvNULL)
+    if (Context == gcvNULL || (int)Context == 0xffffffff )
     {
         /* See if we have to switch pipes for the command buffer. */
         if (commandBufferObject->entryPipe == Command->pipeSelect)

Re: linux-imx-3.10.9 with preempt-rt patch

[Otavio Salvador]

Hello,

On Mon, Mar 24, 2014 at 11:27 AM, Jacob Kroon <jacob.kroon@gmail.com> wrote:
> Some further progress on the RT-patch support that I forgot.
> The oops seemed to be caused by a comparison mixup of NULL or -1.
> See attached patch. Comments would be appreciated.

I don't use the RT patch but for your best profit of it, would be good
if you could focus the 3.10.17 kernel in git.freescale.com as this is
the basis of the upcoming 3.10.17-1.0.0 GA release. This would allow
for people to easily use your patch :D

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: linux-imx-3.10.9 with preempt-rt patch

[Jacob Kroon]

Hi Otavio,

On Mon, 24 Mar 2014, Otavio Salvador wrote:

> Hello,
>
> On Mon, Mar 24, 2014 at 11:27 AM, Jacob Kroon <jacob.kroon@gmail.com> wrote:
>> Some further progress on the RT-patch support that I forgot.
>> The oops seemed to be caused by a comparison mixup of NULL or -1.
>> See attached patch. Comments would be appreciated.
>
> I don't use the RT patch but for your best profit of it, would be good
> if you could focus the 3.10.17 kernel in git.freescale.com as this is
> the basis of the upcoming 3.10.17-1.0.0 GA release. This would allow
> for people to easily use your patch :D
>

Right, I forgot to mention, I've been applying this on top of linux-imx 
3.10.17 (ec1af9f898d234001d8fc7d720382de34cb6580f) + patch-3.10.17-rt12.patch.

/Jacob

Re: linux-imx-3.10.9 with preempt-rt patch

[Otavio Salvador]

Hello Jacob,

On Mon, Mar 24, 2014 at 12:37 PM, Jacob Kroon <jacob.kroon@gmail.com> wrote:
> On Mon, 24 Mar 2014, Otavio Salvador wrote:
>> On Mon, Mar 24, 2014 at 11:27 AM, Jacob Kroon <jacob.kroon@gmail.com>
>> wrote:
>>>
>>> Some further progress on the RT-patch support that I forgot.
>>> The oops seemed to be caused by a comparison mixup of NULL or -1.
>>> See attached patch. Comments would be appreciated.
>>
>>
>> I don't use the RT patch but for your best profit of it, would be good
>> if you could focus the 3.10.17 kernel in git.freescale.com as this is
>> the basis of the upcoming 3.10.17-1.0.0 GA release. This would allow
>> for people to easily use your patch :D
>>
>
> Right, I forgot to mention, I've been applying this on top of linux-imx
> 3.10.17 (ec1af9f898d234001d8fc7d720382de34cb6580f) +
> patch-3.10.17-rt12.patch.

Have you did and measurement test with and without those patches? I
think this would be of great help.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: linux-imx-3.10.9 with preempt-rt patch

[Jacob Kroon]

Hi Otavio,

On Mon, 24 Mar 2014, Otavio Salvador wrote:

> Hello Jacob,
>
> On Mon, Mar 24, 2014 at 12:37 PM, Jacob Kroon <jacob.kroon@gmail.com> wrote:
>> On Mon, 24 Mar 2014, Otavio Salvador wrote:
>>> On Mon, Mar 24, 2014 at 11:27 AM, Jacob Kroon <jacob.kroon@gmail.com>
>>> wrote:
>>>>
>>>> Some further progress on the RT-patch support that I forgot.
>>>> The oops seemed to be caused by a comparison mixup of NULL or -1.
>>>> See attached patch. Comments would be appreciated.
>>>
>>>
>>> I don't use the RT patch but for your best profit of it, would be good
>>> if you could focus the 3.10.17 kernel in git.freescale.com as this is
>>> the basis of the upcoming 3.10.17-1.0.0 GA release. This would allow
>>> for people to easily use your patch :D
>>>
>>
>> Right, I forgot to mention, I've been applying this on top of linux-imx
>> 3.10.17 (ec1af9f898d234001d8fc7d720382de34cb6580f) +
>> patch-3.10.17-rt12.patch.
>
> Have you did and measurement test with and without those patches? I
> think this would be of great help.
>

I have done some testing using various tools from "rt-tests" package.
The patch does show a big improvement when looking at the numbers from
"cyclictest", max. peak of ~150 us in wakeup-latency for a high-priority
realtime thread (compared to milliseconds even with a PREEMPT kernel), 
while loading the system in all the possible ways I could think of,
including utilizing the GPU. This was on a Wandboard Solo.

/Jacob

Re: linux-imx-3.10.9 with preempt-rt patch

[Fabio Estevam]

Hi Jacob/Otavio,

On Mon, Mar 24, 2014 at 1:48 PM, Jacob Kroon <jacob.kroon@gmail.com> wrote:

> I have done some testing using various tools from "rt-tests" package.
> The patch does show a big improvement when looking at the numbers from
> "cyclictest", max. peak of ~150 us in wakeup-latency for a high-priority
> realtime thread (compared to milliseconds even with a PREEMPT kernel), while
> loading the system in all the possible ways I could think of,
> including utilizing the GPU. This was on a Wandboard Solo.

What about creating a recipe for rt kernels, so that folks interested
in real-time kernel could easily test it under meta-fsl-arm?

Regards,

Fabio Estevam

Re: linux-imx-3.10.9 with preempt-rt patch

[Otavio Salvador]

On Mon, Mar 24, 2014 at 1:52 PM, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Jacob/Otavio,
>
> On Mon, Mar 24, 2014 at 1:48 PM, Jacob Kroon <jacob.kroon@gmail.com> wrote:
>
>> I have done some testing using various tools from "rt-tests" package.
>> The patch does show a big improvement when looking at the numbers from
>> "cyclictest", max. peak of ~150 us in wakeup-latency for a high-priority
>> realtime thread (compared to milliseconds even with a PREEMPT kernel), while
>> loading the system in all the possible ways I could think of,
>> including utilizing the GPU. This was on a Wandboard Solo.
>
> What about creating a recipe for rt kernels, so that folks interested
> in real-time kernel could easily test it under meta-fsl-arm?

I like this idea. Jacob, are you up for the task? I can help if you want.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: linux-imx-3.10.9 with preempt-rt patch

[John Weber]

On 3/24/14, 11:52 AM, Fabio Estevam wrote:
> Hi Jacob/Otavio,
>
> On Mon, Mar 24, 2014 at 1:48 PM, Jacob Kroon <jacob.kroon@gmail.com> wrote:
>
>> I have done some testing using various tools from "rt-tests" package.
>> The patch does show a big improvement when looking at the numbers from
>> "cyclictest", max. peak of ~150 us in wakeup-latency for a high-priority
>> realtime thread (compared to milliseconds even with a PREEMPT kernel), while
>> loading the system in all the possible ways I could think of,
>> including utilizing the GPU. This was on a Wandboard Solo.
> What about creating a recipe for rt kernels, so that folks interested
> in real-time kernel could easily test it under meta-fsl-arm?
+1 to this.  It would be great to have for all boards, not just Wandboard.  But, 
I'm willing to test it on Wandboard as well.
>
> Regards,
>
> Fabio Estevam

Re: linux-imx-3.10.9 with preempt-rt patch

[Jacob Kroon]

On Mon, 24 Mar 2014, Otavio Salvador wrote:

> On Mon, Mar 24, 2014 at 1:52 PM, Fabio Estevam <festevam@gmail.com> wrote:
>> Hi Jacob/Otavio,
>>
>> On Mon, Mar 24, 2014 at 1:48 PM, Jacob Kroon <jacob.kroon@gmail.com> wrote:
>>
>>> I have done some testing using various tools from "rt-tests" package.
>>> The patch does show a big improvement when looking at the numbers from
>>> "cyclictest", max. peak of ~150 us in wakeup-latency for a high-priority
>>> realtime thread (compared to milliseconds even with a PREEMPT kernel), while
>>> loading the system in all the possible ways I could think of,
>>> including utilizing the GPU. This was on a Wandboard Solo.
>>
>> What about creating a recipe for rt kernels, so that folks interested
>> in real-time kernel could easily test it under meta-fsl-arm?
>
> I like this idea. Jacob, are you up for the task? I can help if you want.
>

Yes, it sounds like a good idea. I'll come up with a
patch for a linux-imx-rt recipe and post it for review here.

/Jacob

Re: linux-imx-3.10.9 with preempt-rt patch

[Jacob Kroon]

[-- Attachment #1: Type: text/plain, Size: 1609 bytes --]

Hi Otavio,

On Mon, Mar 24, 2014 at 6:10 PM, Jacob Kroon <jacob.kroon@gmail.com> wrote:

> On Mon, 24 Mar 2014, Otavio Salvador wrote:
>
>  On Mon, Mar 24, 2014 at 1:52 PM, Fabio Estevam <festevam@gmail.com>
>> wrote:
>>
>>> Hi Jacob/Otavio,
>>>
>>> On Mon, Mar 24, 2014 at 1:48 PM, Jacob Kroon <jacob.kroon@gmail.com>
>>> wrote:
>>>
>>>  I have done some testing using various tools from "rt-tests" package.
>>>> The patch does show a big improvement when looking at the numbers from
>>>> "cyclictest", max. peak of ~150 us in wakeup-latency for a high-priority
>>>> realtime thread (compared to milliseconds even with a PREEMPT kernel),
>>>> while
>>>> loading the system in all the possible ways I could think of,
>>>> including utilizing the GPU. This was on a Wandboard Solo.
>>>>
>>>
>>> What about creating a recipe for rt kernels, so that folks interested
>>> in real-time kernel could easily test it under meta-fsl-arm?
>>>
>>
>> I like this idea. Jacob, are you up for the task? I can help if you want.
>>
>>
> Yes, it sounds like a good idea. I'll come up with a
> patch for a linux-imx-rt recipe and post it for review here.
>
> /Jacob
>

So, the local patches I have are very light-weight, and the RT-patch can be
downloaded externally, but I wonder about the defconfig. Preempt-RT
switches the config parameters quite a lot, is there a tool or trick to use
in order to "cleanup" the defconfig to make it as minimal as possible ?
Right now I just use linux-imx defconfig as a start, turn on preempt-rt,
and save the resulting .config file.

  -- Jacob

[-- Attachment #2: Type: text/html, Size: 2592 bytes --]

Re: linux-imx-3.10.9 with preempt-rt patch

[Otavio Salvador]

Hello Jacob,

On Tue, Mar 25, 2014 at 7:49 AM, Jacob Kroon <jacob.kroon@gmail.com> wrote:
> On Mon, Mar 24, 2014 at 6:10 PM, Jacob Kroon <jacob.kroon@gmail.com> wrote:
>> On Mon, 24 Mar 2014, Otavio Salvador wrote:
>>> On Mon, Mar 24, 2014 at 1:52 PM, Fabio Estevam <festevam@gmail.com>
>>> wrote:
>>>> What about creating a recipe for rt kernels, so that folks interested
>>>> in real-time kernel could easily test it under meta-fsl-arm?
>>>
>>>
>>> I like this idea. Jacob, are you up for the task? I can help if you want.
>>>
>>
>> Yes, it sounds like a good idea. I'll come up with a
>> patch for a linux-imx-rt recipe and post it for review here.
>
> So, the local patches I have are very light-weight, and the RT-patch can be
> downloaded externally, but I wonder about the defconfig. Preempt-RT switches
> the config parameters quite a lot, is there a tool or trick to use in order
> to "cleanup" the defconfig to make it as minimal as possible ? Right now I
> just use linux-imx defconfig as a start, turn on preempt-rt, and save the
> resulting .config file.

So in this case please *download* the RT-patch. Check the 'name' param
for the SRC_URI so you can add the md5sum and sha256sum for it.

For the defconfig, yes. You should do:

make ARCH=arm savedefconfig

after doing the required changes.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: linux-imx-3.10.9 with preempt-rt patch

[Jacob Kroon]

[-- Attachment #1: Type: text/plain, Size: 1576 bytes --]

On Tue, Mar 25, 2014 at 12:43 PM, Otavio Salvador
<otavio@ossystems.com.br>wrote:

> Hello Jacob,
>
> On Tue, Mar 25, 2014 at 7:49 AM, Jacob Kroon <jacob.kroon@gmail.com>
> wrote:
> > On Mon, Mar 24, 2014 at 6:10 PM, Jacob Kroon <jacob.kroon@gmail.com>
> wrote:
> >> On Mon, 24 Mar 2014, Otavio Salvador wrote:
> >>> On Mon, Mar 24, 2014 at 1:52 PM, Fabio Estevam <festevam@gmail.com>
> >>> wrote:
> >>>> What about creating a recipe for rt kernels, so that folks interested
> >>>> in real-time kernel could easily test it under meta-fsl-arm?
> >>>
> >>>
> >>> I like this idea. Jacob, are you up for the task? I can help if you
> want.
> >>>
> >>
> >> Yes, it sounds like a good idea. I'll come up with a
> >> patch for a linux-imx-rt recipe and post it for review here.
> >
> > So, the local patches I have are very light-weight, and the RT-patch can
> be
> > downloaded externally, but I wonder about the defconfig. Preempt-RT
> switches
> > the config parameters quite a lot, is there a tool or trick to use in
> order
> > to "cleanup" the defconfig to make it as minimal as possible ? Right now
> I
> > just use linux-imx defconfig as a start, turn on preempt-rt, and save the
> > resulting .config file.
>
> So in this case please *download* the RT-patch. Check the 'name' param
> for the SRC_URI so you can add the md5sum and sha256sum for it.
>
> For the defconfig, yes. You should do:
>
> make ARCH=arm savedefconfig
>
> after doing the required changes.
>
>
Thanks, that shrank the defconfig _considerably_ :-)

/Jacob

[-- Attachment #2: Type: text/html, Size: 2354 bytes --]