porting PREEMPT_RT v5.15

[amamory]

The goal is to continue on the discussion started here about porting a newer version of PREEMPT_RT to RPI`s Yocto.
This repo could be use as a laboratory to try new things/approaches. If we get a good port, perhaps in the future this can become a more official Yocto supported kernel version.

@micaeb, @kdoren, @matthiasklein manifested interest in this discussion.

[mebel-christ]

@amamory So first up something that is entirely unrelated to the porting process. In my opinion we should not start developing new recipes etc on the 3.1 "Dunfell" release since there was a major syntax change since then (Overrides are now written as VAR:append instead of VAR_append) which will result in additional work later on.

My proposal would be to switch to Yocto 3.4 "Honister" (non-lts) for development and proceed with Yocto 3.5 "Kirkstone" (Future LTS, released April 2022) once availabled.

What do you think about that?

[mebel-christ]

@amamory A question I have is how do you manage your layers when building? Do you use some external tools like repo or kas?

[amamory]

@micaeb Sure, the readme points to this docker container.
You can see in the docker file how my environment was setup. Just the bare minimum yocto layers to build a RPi image. No repo or kas.

[amamory]

Just to you understand my level of experience. I started w yocto few months ago. The 1st thing i built was the docker, the 2nd one was this tutorial repo for custom software. The 3rd was this meta-rpi. I did all of this to have the required experience to build this meta-fred and meta-retis for FPGAs, with petalinux on top of Yocto. These last two are for the research project i am working on. Since i am interested in real time for robotics/autonomous vehicles applications, i decided to increment meta-rpi and meta-retis with the basic Linux realtime setup, i.e. removing dvfs, cpu idle, etc.

That`s why i am interested of building a nice, reproducible, up-to-date realtime setup for RPi and FPGA. the story was a bit longer than i expected, but i guess now you understand my mindset and motivations :-)

[mebel-christ]

@amamory Thanks for the link, did not look into the readme yet, my bad ^^

[mebel-christ]

@amamory To get to the juicy part now, I looked over your recipes and they seem fine to me after all (I guess you made sure they work as intended, so I did not look into that).

My idea on the other hand would be to stick to the structure and recipes from meta-raspberrypi. Therefor I suggest the following method to create a RT-patched raspberrypi kernel:

/recipes-kernel/linux/linux-raspberrypi_5.10.bbappend:

require ${@bb.utils.contains('DISTRO_FEATURES', 'rt', '${BPN}_rt.inc', '', d)}

/recipes-kernel/linux/linux-raspberrypi_rt.inc:

FILESEXTRAPATHS:prepend := "${THISDIR}/linux-raspberrypi-rt:"

SRC_URI = "git://<appropriate linux-raspberrypi base commit> \
  file://<common rt>.patch \
  file://<rpi specific rt>.patch \
  file://defconfig \
"

The patches must be stored in the linux-raspberrypi-rt folder beside the bbappend. Guess this approach benefits a lot from the fact that it only extends the available infrastructue in constrast to creating a hole new recipe. Additionaly the offical linux-raspberrypi is still in use and only the patchsets must be provided.

What are your thoughts on that? I guess from a technical point of view the result is the same but idk I feel like the described approach is "cleaner". But this is mainly a feeling of mine :D

[amamory]

@micaeb. great, thanks !
I will try it today or tomorrow.

A question, is there a particular reason you are suggesting version v5.10 instead of v5.15 ?
I don't have any reason to choose v5.15 rather than it was the newest version i have found.

[mebel-christ]

@amamory Actually it was just a typo I made because I use the 5.10 branch (since it is LTS) on a daily basis, so I would blame muscle memory on that ^^

[mebel-christ]

@amamory On the other hand I just checked and meta-raspberrypi uses 5.10 (probably because it is LTS) so this approach would indeed only work with 5.10