[yocto] [meta-raspberrypi] linux kernel rt

[Sherif Omran]

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 at gmail.com>
wrote:

> On Thu, Dec 21, 2017 at 5:08 PM, Andrei Gherzan <andrei at gherzan.ro> wrote:
>
>> Hi all,
>>
>> On Thu, Dec 14, 2017 at 12:09 PM, Andreas Müller <schnitzeltony at gmail.com
>> > wrote:
>>
>>> On Thu, Dec 14, 2017 at 11:40 AM, Mirza Krak <mirza.krak at gmail.com>
>>> wrote:
>>>
>>>> 2017-12-14 9:41 GMT+01:00 Andreas Müller <schnitzeltony at gmail.com>:
>>>> > On Thu, Dec 14, 2017 at 2:58 AM, Sherif Omran <
>>>> sherifomran2000 at 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/patc
>>>> h-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 at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20171222/6592d1e7/attachment.html>