[meta-raspberrypi] linux kernel rt


Sherif Omran <sherifomran2000@...>
 

hey guys,

any body tried the real time kernel? I get an error, it is snot in the compatibility list.
can we skip it?

thanks


Andreas Müller
 

On Thu, Dec 14, 2017 at 2:58 AM, Sherif Omran <sherifomran2000@...> wrote:
hey guys,

any body tried the real time kernel? I get an error, it is snot in the compatibility list.
can we skip it?

thanks

--
Good news: I use RT kernel only together with VC4 graphics and have lots of fun on PI2/3.
Bad news: As far as I know it is not in meta-raspberrypi but in my fork [1]. There were attempts to land the RT-patches in meta-raspberrypi but that was denied for huge patch size :(


Andreas


Paul D. DeRocco
 

On Thu, Dec 14, 2017 at 2:58 AM, Sherif Omran
<sherifomran2000@gmail.com> wrote:

any body tried the real time kernel? I get an error, it
is snot in the compatibility list.
From: Andreas Müller

Good news: I use RT kernel only together with VC4 graphics
and have lots of fun on PI2/3.

Bad news: As far as I know it is not in meta-raspberrypi but
in my fork [1]. There were attempts to land the RT-patches in
meta-raspberrypi but that was denied for huge patch size :(
I can vouch for this. I've been using meta-raspi-light for a while on an RPi3, doing music synthesis, and pushing all four cores to about 90% utilization, running the OS "in the cracks", and it's been solid. Thanks, Andreas.

--

Ciao, Paul D. DeRocco
Paul mailto:pderocco@ix.netcom.com


Andreas Müller
 


On Thu, Dec 14, 2017 at 9:59 AM, Sherif Omran <sherifomran2000@...> wrote:
do you use the bluetooth also?




schöne Grüße aus dem Bodensee :)

Let's get back back to public..
 
Hallo Sherif,

I have disabled WLAN and Bluetooth for my devices - so I cannot say something about that. Reason is that I play around sequencer apps and radio devices cause trouble there.

Just for the record: I have the merge back to meta-raspberrypi on my TODO but did not find the time yet due to other challenges. Forking should not be the way to go because meta-raspberrypi is maintained very well these days.

Andreas


Mirza Krak <mirza.krak@...>
 

2017-12-14 9:41 GMT+01:00 Andreas Müller <schnitzeltony@gmail.com>:
On Thu, Dec 14, 2017 at 2:58 AM, Sherif Omran <sherifomran2000@gmail.com>
wrote:

hey guys,

any body tried the real time kernel? I get an error, it is snot in the
compatibility list.
can we skip it?

thanks

--
Good news: I use RT kernel only together with VC4 graphics and have lots of
fun on PI2/3.
Bad news: As far as I know it is not in meta-raspberrypi but in my fork [1].
There were attempts to land the RT-patches in meta-raspberrypi but that was
denied for huge patch size :(
If the patch size was the only problem one can pull it by doing the
following in the recipe:

SRC_URI += " \
https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.9/patch-4.9.65-rt56.patch.gz;name=rt-patch
\
"

SRC_URI[rt-patch.md5sum] = "9caa7b541d8c84c2d5c5f58985982e95"
SRC_URI[rt-patch.sha256sum] =
"47dfb518c78d8cbaafd4ab9130eb26fe0170be9189b580ab26209ef679309539"

Note that above sums are "random" and not the for the actually file
but are there for reference.

That way you do not need to keep a copy of it in meta-raspberrypi.

--
Med Vänliga Hälsningar / Best Regards

Mirza Krak


Andreas Müller
 

On Thu, Dec 14, 2017 at 11:40 AM, Mirza Krak <mirza.krak@...> wrote:
2017-12-14 9:41 GMT+01:00 Andreas Müller <schnitzeltony@...>:
> On Thu, Dec 14, 2017 at 2:58 AM, Sherif Omran <sherifomran2000@...>
> wrote:
>>
>> hey guys,
>>
>> any body tried the real time kernel? I get an error, it is snot in the
>> compatibility list.
>> can we skip it?
>>
>> thanks
>>
>> --
>
> Good news: I use RT kernel only together with VC4 graphics and have lots of
> fun on PI2/3.
> Bad news: As far as I know it is not in meta-raspberrypi but in my fork [1].
> There were attempts to land the RT-patches in meta-raspberrypi but that was
> denied for huge patch size :(

If the patch size was the only problem one can pull it by doing the
following in the recipe:

SRC_URI += " \
    https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.9/patch-4.9.65-rt56.patch.gz;name=rt-patch
\
"

SRC_URI[rt-patch.md5sum] = "9caa7b541d8c84c2d5c5f58985982e95"
SRC_URI[rt-patch.sha256sum] =
"47dfb518c78d8cbaafd4ab9130eb26fe0170be9189b580ab26209ef679309539"

Note that above sums are "random" and not the for the actually file
but are there for reference.

That way you do not need to keep a copy of it in meta-raspberrypi.

--

Hi Mirza,
 
Problem is that patches need alignments sometimes either caused by Raspberry-Pi-specific adjustments or versions not matching exactly - RT kernel patch updates are less frequent than kernel updates. Anyway: git is very good at maintaining huge text content and this should not be a problem these days. Another discussion about RT kernel was to have an extra kernel for it and I never understood why. To me that seems nothing but an extra maintenance burden.

However - just wrote to Paul: I plan to be at FOSDEM and we can discuss there how to get back to one layer only (not mine!) making everybody happy :)

Andreas


Andrei Gherzan
 

Hi all,

On Thu, Dec 14, 2017 at 12:09 PM, Andreas Müller <schnitzeltony@...> wrote:
On Thu, Dec 14, 2017 at 11:40 AM, Mirza Krak <mirza.krak@...> wrote:
2017-12-14 9:41 GMT+01:00 Andreas Müller <schnitzeltony@...>:
> On Thu, Dec 14, 2017 at 2:58 AM, Sherif Omran <sherifomran2000@...>
> wrote:
>>
>> hey guys,
>>
>> any body tried the real time kernel? I get an error, it is snot in the
>> compatibility list.
>> can we skip it?
>>
>> thanks
>>
>> --
>
> Good news: I use RT kernel only together with VC4 graphics and have lots of
> fun on PI2/3.
> Bad news: As far as I know it is not in meta-raspberrypi but in my fork [1].
> There were attempts to land the RT-patches in meta-raspberrypi but that was
> denied for huge patch size :(

If the patch size was the only problem one can pull it by doing the
following in the recipe:

SRC_URI += " \
    https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.9/patch-4.9.65-rt56.patch.gz;name=rt-patch
\
"

SRC_URI[rt-patch.md5sum] = "9caa7b541d8c84c2d5c5f58985982e95"
SRC_URI[rt-patch.sha256sum] =
"47dfb518c78d8cbaafd4ab9130eb26fe0170be9189b580ab26209ef679309539"

Note that above sums are "random" and not the for the actually file
but are there for reference.

That way you do not need to keep a copy of it in meta-raspberrypi.

--

Hi Mirza,
 
Problem is that patches need alignments sometimes either caused by Raspberry-Pi-specific adjustments or versions not matching exactly - RT kernel patch updates are less frequent than kernel updates. Anyway: git is very good at maintaining huge text content and this should not be a problem these days. Another discussion about RT kernel was to have an extra kernel for it and I never understood why. To me that seems nothing but an extra maintenance burden.

However - just wrote to Paul: I plan to be at FOSDEM and we can discuss there how to get back to one layer only (not mine!) making everybody happy :)


I remember the discussion. Indeed that was the reason and the recommendation was to maintain a separate linux-raspberry fork where whoever has interest in this will maintain on top of linux-raspberrypi this patch. Obviously that didn't happen but I'd like to see it landing.

--
Andrei Gherzan
 


Andreas Müller
 

On Thu, Dec 21, 2017 at 5:08 PM, Andrei Gherzan <andrei@...> wrote:
Hi all,

On Thu, Dec 14, 2017 at 12:09 PM, Andreas Müller <schnitzeltony@...> wrote:
On Thu, Dec 14, 2017 at 11:40 AM, Mirza Krak <mirza.krak@...> wrote:
2017-12-14 9:41 GMT+01:00 Andreas Müller <schnitzeltony@...>:
> On Thu, Dec 14, 2017 at 2:58 AM, Sherif Omran <sherifomran2000@...>
> wrote:
>>
>> hey guys,
>>
>> any body tried the real time kernel? I get an error, it is snot in the
>> compatibility list.
>> can we skip it?
>>
>> thanks
>>
>> --
>
> Good news: I use RT kernel only together with VC4 graphics and have lots of
> fun on PI2/3.
> Bad news: As far as I know it is not in meta-raspberrypi but in my fork [1].
> There were attempts to land the RT-patches in meta-raspberrypi but that was
> denied for huge patch size :(

If the patch size was the only problem one can pull it by doing the
following in the recipe:

SRC_URI += " \
    https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.9/patch-4.9.65-rt56.patch.gz;name=rt-patch
\
"

SRC_URI[rt-patch.md5sum] = "9caa7b541d8c84c2d5c5f58985982e95"
SRC_URI[rt-patch.sha256sum] =
"47dfb518c78d8cbaafd4ab9130eb26fe0170be9189b580ab26209ef679309539"

Note that above sums are "random" and not the for the actually file
but are there for reference.

That way you do not need to keep a copy of it in meta-raspberrypi.

--

Hi Mirza,
 
Problem is that patches need alignments sometimes either caused by Raspberry-Pi-specific adjustments or versions not matching exactly - RT kernel patch updates are less frequent than kernel updates. Anyway: git is very good at maintaining huge text content and this should not be a problem these days. Another discussion about RT kernel was to have an extra kernel for it and I never understood why. To me that seems nothing but an extra maintenance burden.

However - just wrote to Paul: I plan to be at FOSDEM and we can discuss there how to get back to one layer only (not mine!) making everybody happy :)


I remember the discussion. Indeed that was the reason and the recommendation was to maintain a separate linux-raspberry fork where whoever has interest in this will maintain on top of linux-raspberrypi this patch. Obviously that didn't happen but I'd like to see it landing.

Yes that was one of the suggestions which made me say 'Thanks - this is just additional maintenance burden and will not work for long time - I do my own'. FWIW: That suggestion came at a time when you (Andrei) seemed overworked totally (just to mention - PLEASE don't take it as criticism - I know what I am talking of when it comes to 'overworked').

Why not simply one stable kernel with RT-patches applied if user decides by an option? That is what I am doing for >1 year now and meta-raspi-light is the one which caused me least efforts/headaches of all. And yes I know I made life easy here by removing userland completely and taking care for RPi2/3 only.

Cheers,

Andreas


Sherif Omran <sherifomran2000@...>
 

hi Andreas,

so i need to integrate it now into my meta layer. Because i am using the meta-raspberry pi.
To put it into my local meta-layer:
should i copy the recipies-kernel->linux-raspberrypi4.9 only
is there some other files i need to copy?

I will be working with audio/wlan/bluetooth, no need for other tools.
what should i add to the local.conf, is it the following only?

#PREFERRED_PROVIDER_virtual/kernel = "linux-raspberrypi"
#PREFERRED_VERSION_linux-raspberrypi ?= "4.9%"

Do we need to add something to the kernel configuration?

thank you

On Thu, Dec 21, 2017 at 9:59 PM, Andreas Müller <schnitzeltony@...> wrote:
On Thu, Dec 21, 2017 at 5:08 PM, Andrei Gherzan <andrei@...> wrote:
Hi all,

On Thu, Dec 14, 2017 at 12:09 PM, Andreas Müller <schnitzeltony@...> wrote:
On Thu, Dec 14, 2017 at 11:40 AM, Mirza Krak <mirza.krak@...> wrote:
2017-12-14 9:41 GMT+01:00 Andreas Müller <schnitzeltony@...>:
> On Thu, Dec 14, 2017 at 2:58 AM, Sherif Omran <sherifomran2000@...>
> wrote:
>>
>> hey guys,
>>
>> any body tried the real time kernel? I get an error, it is snot in the
>> compatibility list.
>> can we skip it?
>>
>> thanks
>>
>> --
>
> Good news: I use RT kernel only together with VC4 graphics and have lots of
> fun on PI2/3.
> Bad news: As far as I know it is not in meta-raspberrypi but in my fork [1].
> There were attempts to land the RT-patches in meta-raspberrypi but that was
> denied for huge patch size :(

If the patch size was the only problem one can pull it by doing the
following in the recipe:

SRC_URI += " \
    https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.9/patch-4.9.65-rt56.patch.gz;name=rt-patch
\
"

SRC_URI[rt-patch.md5sum] = "9caa7b541d8c84c2d5c5f58985982e95"
SRC_URI[rt-patch.sha256sum] =
"47dfb518c78d8cbaafd4ab9130eb26fe0170be9189b580ab26209ef679309539"

Note that above sums are "random" and not the for the actually file
but are there for reference.

That way you do not need to keep a copy of it in meta-raspberrypi.

--

Hi Mirza,
 
Problem is that patches need alignments sometimes either caused by Raspberry-Pi-specific adjustments or versions not matching exactly - RT kernel patch updates are less frequent than kernel updates. Anyway: git is very good at maintaining huge text content and this should not be a problem these days. Another discussion about RT kernel was to have an extra kernel for it and I never understood why. To me that seems nothing but an extra maintenance burden.

However - just wrote to Paul: I plan to be at FOSDEM and we can discuss there how to get back to one layer only (not mine!) making everybody happy :)


I remember the discussion. Indeed that was the reason and the recommendation was to maintain a separate linux-raspberry fork where whoever has interest in this will maintain on top of linux-raspberrypi this patch. Obviously that didn't happen but I'd like to see it landing.

Yes that was one of the suggestions which made me say 'Thanks - this is just additional maintenance burden and will not work for long time - I do my own'. FWIW: That suggestion came at a time when you (Andrei) seemed overworked totally (just to mention - PLEASE don't take it as criticism - I know what I am talking of when it comes to 'overworked').

Why not simply one stable kernel with RT-patches applied if user decides by an option? That is what I am doing for >1 year now and meta-raspi-light is the one which caused me least efforts/headaches of all. And yes I know I made life easy here by removing userland completely and taking care for RPi2/3 only.

Cheers,

Andreas


--
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto



Andrei Gherzan
 

Hi Andreas,

On Thu, Dec 21, 2017 at 8:59 PM, Andreas Müller <schnitzeltony@...> wrote:
On Thu, Dec 21, 2017 at 5:08 PM, Andrei Gherzan <andrei@...> wrote:
Hi all,

On Thu, Dec 14, 2017 at 12:09 PM, Andreas Müller <schnitzeltony@...> wrote:
On Thu, Dec 14, 2017 at 11:40 AM, Mirza Krak <mirza.krak@...> wrote:
2017-12-14 9:41 GMT+01:00 Andreas Müller <schnitzeltony@...>:
> On Thu, Dec 14, 2017 at 2:58 AM, Sherif Omran <sherifomran2000@...>
> wrote:
>>
>> hey guys,
>>
>> any body tried the real time kernel? I get an error, it is snot in the
>> compatibility list.
>> can we skip it?
>>
>> thanks
>>
>> --
>
> Good news: I use RT kernel only together with VC4 graphics and have lots of
> fun on PI2/3.
> Bad news: As far as I know it is not in meta-raspberrypi but in my fork [1].
> There were attempts to land the RT-patches in meta-raspberrypi but that was
> denied for huge patch size :(

If the patch size was the only problem one can pull it by doing the
following in the recipe:

SRC_URI += " \
    https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.9/patch-4.9.65-rt56.patch.gz;name=rt-patch
\
"

SRC_URI[rt-patch.md5sum] = "9caa7b541d8c84c2d5c5f58985982e95"
SRC_URI[rt-patch.sha256sum] =
"47dfb518c78d8cbaafd4ab9130eb26fe0170be9189b580ab26209ef679309539"

Note that above sums are "random" and not the for the actually file
but are there for reference.

That way you do not need to keep a copy of it in meta-raspberrypi.

--

Hi Mirza,
 
Problem is that patches need alignments sometimes either caused by Raspberry-Pi-specific adjustments or versions not matching exactly - RT kernel patch updates are less frequent than kernel updates. Anyway: git is very good at maintaining huge text content and this should not be a problem these days. Another discussion about RT kernel was to have an extra kernel for it and I never understood why. To me that seems nothing but an extra maintenance burden.

However - just wrote to Paul: I plan to be at FOSDEM and we can discuss there how to get back to one layer only (not mine!) making everybody happy :)


I remember the discussion. Indeed that was the reason and the recommendation was to maintain a separate linux-raspberry fork where whoever has interest in this will maintain on top of linux-raspberrypi this patch. Obviously that didn't happen but I'd like to see it landing.

Yes that was one of the suggestions which made me say 'Thanks - this is just additional maintenance burden and will not work for long time - I do my own'. FWIW: That suggestion came at a time when you (Andrei) seemed overworked totally (just to mention - PLEASE don't take it as criticism - I know what I am talking of when it comes to 'overworked').

You will be suprised but all of us are busy and this is a side project handled as good possible in our spare time. I do agree that there was a time where this project was a little demoted in priority. But even if that is the case, contributions are always welcomed - as you know.
 

Why not simply one stable kernel with RT-patches applied if user decides by an option? That is what I am doing for >1 year now and meta-raspi-light is the one which caused me least efforts/headaches of all. And yes I know I made life easy here by removing userland completely and taking care for RPi2/3 only.


I will always advocate against forks but definitely that is an option too. What I want to understand is why maintaining it in meta-raspberrypi was painful. Basically, the question is how do you currently maintain, rebase etc the rt patch? I would expect it to happen in a git tree as well. Isn't that the case?

--
Andrei Gherzan


Andreas Müller
 

On Fri, Dec 22, 2017 at 2:25 PM, Andrei Gherzan <andrei@...> wrote:
Hi Andreas,

On Thu, Dec 21, 2017 at 8:59 PM, Andreas Müller <schnitzeltony@...> wrote:
On Thu, Dec 21, 2017 at 5:08 PM, Andrei Gherzan <andrei@...> wrote:
Hi all,

On Thu, Dec 14, 2017 at 12:09 PM, Andreas Müller <schnitzeltony@...> wrote:
On Thu, Dec 14, 2017 at 11:40 AM, Mirza Krak <mirza.krak@...> wrote:
2017-12-14 9:41 GMT+01:00 Andreas Müller <schnitzeltony@...>:
> On Thu, Dec 14, 2017 at 2:58 AM, Sherif Omran <sherifomran2000@...>
> wrote:
>>
>> hey guys,
>>
>> any body tried the real time kernel? I get an error, it is snot in the
>> compatibility list.
>> can we skip it?
>>
>> thanks
>>
>> --
>
> Good news: I use RT kernel only together with VC4 graphics and have lots of
> fun on PI2/3.
> Bad news: As far as I know it is not in meta-raspberrypi but in my fork [1].
> There were attempts to land the RT-patches in meta-raspberrypi but that was
> denied for huge patch size :(

If the patch size was the only problem one can pull it by doing the
following in the recipe:

SRC_URI += " \
    https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.9/patch-4.9.65-rt56.patch.gz;name=rt-patch
\
"

SRC_URI[rt-patch.md5sum] = "9caa7b541d8c84c2d5c5f58985982e95"
SRC_URI[rt-patch.sha256sum] =
"47dfb518c78d8cbaafd4ab9130eb26fe0170be9189b580ab26209ef679309539"

Note that above sums are "random" and not the for the actually file
but are there for reference.

That way you do not need to keep a copy of it in meta-raspberrypi.

--

Hi Mirza,
 
Problem is that patches need alignments sometimes either caused by Raspberry-Pi-specific adjustments or versions not matching exactly - RT kernel patch updates are less frequent than kernel updates. Anyway: git is very good at maintaining huge text content and this should not be a problem these days. Another discussion about RT kernel was to have an extra kernel for it and I never understood why. To me that seems nothing but an extra maintenance burden.

However - just wrote to Paul: I plan to be at FOSDEM and we can discuss there how to get back to one layer only (not mine!) making everybody happy :)


I remember the discussion. Indeed that was the reason and the recommendation was to maintain a separate linux-raspberry fork where whoever has interest in this will maintain on top of linux-raspberrypi this patch. Obviously that didn't happen but I'd like to see it landing.

Yes that was one of the suggestions which made me say 'Thanks - this is just additional maintenance burden and will not work for long time - I do my own'. FWIW: That suggestion came at a time when you (Andrei) seemed overworked totally (just to mention - PLEASE don't take it as criticism - I know what I am talking of when it comes to 'overworked').

You will be suprised but all of us are busy and this is a side project handled as good possible in our spare time. I do agree that there was a time where this project was a little demoted in priority. But even if that is the case, contributions are always welcomed - as you know.
 

Why not simply one stable kernel with RT-patches applied if user decides by an option? That is what I am doing for >1 year now and meta-raspi-light is the one which caused me least efforts/headaches of all. And yes I know I made life easy here by removing userland completely and taking care for RPi2/3 only.


I will always advocate against forks but definitely that is an option too. What I want to understand is why maintaining it in meta-raspberrypi was painful. Basically, the question is how do you currently maintain, rebase etc the rt patch? I would expect it to happen in a git tree as well. Isn't that the case?

I maintained it this way:

* Set new kernel version
* Check if there is an update at RT-Kernel. If so update the patch.
* Rebuild the kernel. In case a patch does not apply cleanly, I use git inside of oe work-shared folder, check/align for hunks failing and insert them manually into original patch. From my experience there are usually very few hunks to touch so this is no rocket science.

What do you think?

Some advertisement :) I would stand up to take care for RT and VC4 in the future. This is what I need to build heavy heavy world builds with EGL/GLES and able to mix/produce music..

Andreas


 

On Fri, Dec 22, 2017 at 2:17 PM, Andreas Müller <schnitzeltony@gmail.com> wrote:
On Fri, Dec 22, 2017 at 2:25 PM, Andrei Gherzan <andrei@gherzan.ro> wrote:

Hi Andreas,

On Thu, Dec 21, 2017 at 8:59 PM, Andreas Müller <schnitzeltony@gmail.com>
wrote:


Why not simply one stable kernel with RT-patches applied if user decides
by an option? That is what I am doing for >1 year now and meta-raspi-light
is the one which caused me least efforts/headaches of all. And yes I know I
made life easy here by removing userland completely and taking care for
RPi2/3 only.
I will always advocate against forks but definitely that is an option too.
What I want to understand is why maintaining it in meta-raspberrypi was
painful. Basically, the question is how do you currently maintain, rebase
etc the rt patch? I would expect it to happen in a git tree as well. Isn't
that the case?
I maintained it this way:

* Set new kernel version
* Check if there is an update at RT-Kernel. If so update the patch.
* Rebuild the kernel. In case a patch does not apply cleanly, I use git
inside of oe work-shared folder, check/align for hunks failing and insert
them manually into original patch. From my experience there are usually very
few hunks to touch so this is no rocket science.

What do you think?
So, my thinking was that if you're going through the effort of getting
the -rt patches to apply to the rpi kernel, I'd like to see that
available to non-OpenEmbedded users. I think a linux-raspberrypi-rt
kernel tree would be a useful think to make available as a standalone
project, which we can then pull into meta-raspberrypi as a simple
recipe.

My complaint with having the entire -rt patch in the meta-raspberrypi
repo was that it's a huge, un-reviewable blob. Multi-thousand line
patches are now less painful with review happening on GitHub now
though - they at least don't upset my email workflow anymore :)

Could you try handling this in git by merging the -rt kernel branch
(https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git/log/?h=v4.9-rt)
into the linux-raspberrypi branch regularly instead of by applying the
-rt patch manually? Any merge conflicts could be handled cleanly that
way and it would give us something we could bisect properly in case of
any bugs. The resulting git repository could be published online as
something like 'linux-raspberrypi-rt' if this works.

This is basically my opinion though, there is no one true Right Way
(TM) to do this. If you decide it's still easier for you to handle
this as a patch in the meta-raspberrypi layer then I'm happy to
support that.

--
Paul Barker
Togán Labs Ltd


Andreas Müller
 

On Fri, Dec 22, 2017 at 7:57 PM, Paul Barker <pbarker@...> wrote:
On Fri, Dec 22, 2017 at 2:17 PM, Andreas Müller <schnitzeltony@...> wrote:
> On Fri, Dec 22, 2017 at 2:25 PM, Andrei Gherzan <andrei@...> wrote:
>>
>> Hi Andreas,
>>
>> On Thu, Dec 21, 2017 at 8:59 PM, Andreas Müller <schnitzeltony@...>
>> wrote:
>>>
>>>
>>> Why not simply one stable kernel with RT-patches applied if user decides
>>> by an option? That is what I am doing for >1 year now and meta-raspi-light
>>> is the one which caused me least efforts/headaches of all. And yes I know I
>>> made life easy here by removing userland completely and taking care for
>>> RPi2/3 only.
>>>
>>
>> I will always advocate against forks but definitely that is an option too.
>> What I want to understand is why maintaining it in meta-raspberrypi was
>> painful. Basically, the question is how do you currently maintain, rebase
>> etc the rt patch? I would expect it to happen in a git tree as well. Isn't
>> that the case?
>>
> I maintained it this way:
>
> * Set new kernel version
> * Check if there is an update at RT-Kernel. If so update the patch.
> * Rebuild the kernel. In case a patch does not apply cleanly, I use git
> inside of oe work-shared folder, check/align for hunks failing and insert
> them manually into original patch. From my experience there are usually very
> few hunks to touch so this is no rocket science.
>
> What do you think?
>

So, my thinking was that if you're going through the effort of getting
the -rt patches to apply to the rpi kernel, I'd like to see that
available to non-OpenEmbedded users. I think a linux-raspberrypi-rt
kernel tree would be a useful think to make available as a standalone
project, which we can then pull into meta-raspberrypi as a simple
recipe.

My complaint with having the entire -rt patch in the meta-raspberrypi
repo was that it's a huge, un-reviewable blob. Multi-thousand line
patches are now less painful with review happening on GitHub now
though - they at least don't upset my email workflow anymore :)

Could you try handling this in git by merging the -rt kernel branch
(https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git/log/?h=v4.9-rt)
into the linux-raspberrypi branch regularly instead of by applying the
-rt patch manually? Any merge conflicts could be handled cleanly that
way and it would give us something we could bisect properly in case of
any bugs. The resulting git repository could be published online as
something like 'linux-raspberrypi-rt' if this works.

This is basically my opinion though, there is no one true Right Way
(TM) to do this. If you decide it's still easier for you to handle
this as a patch in the meta-raspberrypi layer then I'm happy to
support that.

Good suggestion - but:

1. you overestimate the RT-patching process / errors caused by RT
2. I would like to keep RT and non-RT kernel versions in sync
3. I see more efforts which don't buy me anything personally

My dislike (3.) might be increased by the fact that I

* (try to) maintain >400 recipes and contribute to others more or less for 'fun' and due to that I am not keen on some extra duty
* am an old man afraid of changing bad habits :)

However: there is no time pressure on this matter and I am looking forward to discuss this with you (and others) at FOSDEM. I am sure we'll find a solution/compromise there.

Andreas


Khem Raj
 

On 12/22/17 2:28 PM, Andreas Müller wrote:
On Fri, Dec 22, 2017 at 7:57 PM, Paul Barker <pbarker@toganlabs.com <mailto:pbarker@toganlabs.com>> wrote:
On Fri, Dec 22, 2017 at 2:17 PM, Andreas Müller
<schnitzeltony@gmail.com <mailto:schnitzeltony@gmail.com>> wrote:
> On Fri, Dec 22, 2017 at 2:25 PM, Andrei Gherzan <andrei@gherzan.ro <mailto:andrei@gherzan.ro>> wrote:
>>
>> Hi Andreas,
>>
>> On Thu, Dec 21, 2017 at 8:59 PM, Andreas Müller <schnitzeltony@gmail.com <mailto:schnitzeltony@gmail.com>>
>> wrote:
>>>
>>>
>>> Why not simply one stable kernel with RT-patches applied if user decides
>>> by an option? That is what I am doing for >1 year now and meta-raspi-light
>>> is the one which caused me least efforts/headaches of all. And yes I know I
>>> made life easy here by removing userland completely and taking care for
>>> RPi2/3 only.
>>>
>>
>> I will always advocate against forks but definitely that is an option too.
>> What I want to understand is why maintaining it in meta-raspberrypi was
>> painful. Basically, the question is how do you currently maintain, rebase
>> etc the rt patch? I would expect it to happen in a git tree as well. Isn't
>> that the case?
>>
> I maintained it this way:
>
> * Set new kernel version
> * Check if there is an update at RT-Kernel. If so update the patch.
> * Rebuild the kernel. In case a patch does not apply cleanly, I use git
> inside of oe work-shared folder, check/align for hunks failing and insert
> them manually into original patch. From my experience there are usually very
> few hunks to touch so this is no rocket science.
>
> What do you think?
>
So, my thinking was that if you're going through the effort of getting
the -rt patches to apply to the rpi kernel, I'd like to see that
available to non-OpenEmbedded users. I think a linux-raspberrypi-rt
kernel tree would be a useful think to make available as a standalone
project, which we can then pull into meta-raspberrypi as a simple
recipe.
My complaint with having the entire -rt patch in the meta-raspberrypi
repo was that it's a huge, un-reviewable blob. Multi-thousand line
patches are now less painful with review happening on GitHub now
though - they at least don't upset my email workflow anymore :)
Could you try handling this in git by merging the -rt kernel branch
(https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git/log/?h=v4.9-rt
<https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git/log/?h=v4.9-rt>)
into the linux-raspberrypi branch regularly instead of by applying the
-rt patch manually? Any merge conflicts could be handled cleanly that
way and it would give us something we could bisect properly in case of
any bugs. The resulting git repository could be published online as
something like 'linux-raspberrypi-rt' if this works.
This is basically my opinion though, there is no one true Right Way
(TM) to do this. If you decide it's still easier for you to handle
this as a patch in the meta-raspberrypi layer then I'm happy to
support that.
Good suggestion - but:
1. you overestimate the RT-patching process / errors caused by RT
2. I would like to keep RT and non-RT kernel versions in sync
3. I see more efforts which don't buy me anything personally
My dislike (3.) might be increased by the fact that I
* (try to) maintain >400 recipes and contribute to others more or less for 'fun' and due to that I am not keen on some extra duty
* am an old man afraid of changing bad habits :)
However: there is no time pressure on this matter and I am looking forward to discuss this with you (and others) at FOSDEM. I am sure we'll find a solution/compromise there.
Perhaps this discussions should be forwarded to rpi community and see if there is any interest in them maintaining a rt branch for rpi kernel.

Secondly, I wonder how good is upstream mainline kernel for rpi now a days, we could always have a mainline recipe as an option and use it as base for things like rt.

Andreas


Martin Hundebøll <martin.hundeboll@...>
 

On 2018-01-26 04:51, Khem Raj wrote:
Secondly, I wonder how good is upstream mainline kernel for rpi now a days, we could always have a mainline recipe as an option and use it as base for things like rt.
Apart from runtime device tree overlay support for RPi hats/extension boards, mainline linux fully supports each RPi revision.

I guess linux-yocto-rt would be just fine...

--
MARTIN HUNDEBØLL, Prevas A/S
Software Developer

Hedeager 3, DK-8200 Aarhus N
Phone +45 87438070
Mobile +45 25562438
Martin.Hundeboll@prevas.dk
www.prevas.com


Trevor Woerner
 

On Fri, Jan 26, 2018 at 3:43 AM, Martin Hundebøll <martin.hundeboll@...> wrote:


On 2018-01-26 04:51, Khem Raj wrote:

Secondly, I wonder how good is upstream mainline kernel for rpi now a days, we could always have a mainline recipe as an option and use it as base for things like rt.

Apart from runtime device tree overlay support for RPi hats/extension boards, mainline linux fully supports each RPi revision.

I guess linux-yocto-rt would be just fine...


Does anyone know if the FIQ bug has been fixed upstream? The last time I looked into PREEMPT_RT on the RPi, the only way to make it work/stable was to patch the FIQ issue, or disable FIQ altogether (not ideal). This patch was outside both the kernel and the PREEMPT_RT patch.


Andreas Müller
 

On Fri, Jan 26, 2018 at 3:09 PM, Trevor Woerner <twoerner@gmail.com> wrote:
On Fri, Jan 26, 2018 at 3:43 AM, Martin Hundebøll
<martin.hundeboll@prevas.dk> wrote:



On 2018-01-26 04:51, Khem Raj wrote:


Secondly, I wonder how good is upstream mainline kernel for rpi now a
days, we could always have a mainline recipe as an option and use it as base
for things like rt.

Apart from runtime device tree overlay support for RPi hats/extension
boards, mainline linux fully supports each RPi revision.

I guess linux-yocto-rt would be just fine...
Does anyone know if the FIQ bug has been fixed upstream? The last time I
looked into PREEMPT_RT on the RPi, the only way to make it work/stable was
to patch the FIQ issue, or disable FIQ altogether (not ideal). This patch
was outside both the kernel and the PREEMPT_RT patch.

--
Seems RPi.org made some progress on this[1].

If I only had some time left to give this a try...

[1] https://github.com/raspberrypi/linux/issues/2244#issuecomment-369597357

Andreas


Zoran
 


Zoran
_______

On Thu, Dec 14, 2017 at 2:58 AM, Sherif Omran <sherifomran2000@...> wrote:
hey guys,

any body tried the real time kernel? I get an error, it is snot in the compatibility list.
can we skip it?

thanks

--
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto



 

On Thu, Mar 1, 2018 at 1:59 PM, Andreas Müller <schnitzeltony@gmail.com> wrote:
Seems RPi.org made some progress on this[1].

If I only had some time left to give this a try...

[1] https://github.com/raspberrypi/linux/issues/2244#issuecomment-369597357
This looks great! I'd love to see a recipe for this added to
meta-raspberrypi. Let me know if you need any help and I'll see what I
can do.

--
Paul Barker
Togán Labs Ltd


Andrei Gherzan
 

On Thu, Mar 1, 2018 at 1:59 PM, Andreas Müller <schnitzeltony@...> wrote:
On Fri, Jan 26, 2018 at 3:09 PM, Trevor Woerner <twoerner@...> wrote:
> On Fri, Jan 26, 2018 at 3:43 AM, Martin Hundebøll
> <martin.hundeboll@...> wrote:
>>
>>
>>
>> On 2018-01-26 04:51, Khem Raj wrote:
>>>
>>>
>>> Secondly, I wonder how good is upstream mainline kernel for rpi now a
>>> days, we could always have a mainline recipe as an option and use it as base
>>> for things like rt.
>>
>>
>> Apart from runtime device tree overlay support for RPi hats/extension
>> boards, mainline linux fully supports each RPi revision.
>>
>> I guess linux-yocto-rt would be just fine...
>>
>
> Does anyone know if the FIQ bug has been fixed upstream? The last time I
> looked into PREEMPT_RT on the RPi, the only way to make it work/stable was
> to patch the FIQ issue, or disable FIQ altogether (not ideal). This patch
> was outside both the kernel and the PREEMPT_RT patch.
>
> --
Seems RPi.org made some progress on this[1].

If I only had some time left to give this a try...

[1] https://github.com/raspberrypi/linux/issues/2244#issuecomment-369597357

Nice.

--
Andrei Gherzan