RaspberryPi 4 support

[andypugh]

uname gives-
Linux realtimepi 4.19.50-v7l+ #895 SMP Thu Jun 20 16:03:42 BST 2019 armv7l GNU/Linux

I was expecting to see -RT or -preempt-rt or something.

LinuxCNC does not seem to think it is a realtime kernel:
pi@realtimepi:~/linuxcnc-dev/src $ latency-test
Note: Using POSIX non-realtime

Before I dig in to the LinuxCNC config and build, can you confirm that this is a realtime kernel, and which realtime flavour it is? I was assuming preempt-rt.

[guysoft]

1. which version of the image are you using?
2. Which version of RaspberryPi?

[andypugh]

From the nightly builds.
2019-06-29_2019-06-20-realtimepi-buster-lite-0.4.0.zip
Raspberry Pi 4.

[guysoft]

I haven't tested a RaspbeeryPi 4 because I have no access to the hardware, and its still partly documented.
It seems like multi v7 config is not supported yet. See:
raspberrypi/linux#3057

[andypugh]

So, is the answer to my original question "No, the 2019-06-29 image doesn't boot a Pi4 into a realtime kernel" ?
I was looking at RealtimePi after a report that the rpi-4.19.y-rt didn't work.
https://forum.linuxcnc.org/18-computer/36879-raspberry-pi-4?start=0#138874

[guysoft]

@andypugh If you want to tell hakan there, if he wants to maintain the patches we could make it work here.
Originally RealtimePi used the vanilla RaspberryPi branch and patches. Here is the code from last release:
https://github.com/guysoft/RealtimePi/tree/3225584da703cdb4409932835362298aa446cd05/src/modules/realtimepi/filesystem/home/pi/patches

If Rpi don't manage to maintain it we could go back to that method, it seems like there is a delay because the maintainer of that branch is based in China and doesn't have a Pi 4 to test yet. source: raspberrypi/linux#2943 (comment)

[TiejunChina]

@guysoft Sorry, I some confused here. Are you saying cureent rpi-4.19-y-rt does not work well for pi4? But Haken created his rt branch with rpi-4.19y + "usual rt patches" + https://github.com/guysoft/RealtimePi/tree/3225584da703cdb4409932835362298aa446cd05/src/modules/realtimepi/filesystem/home/pi/patches, and then this can work for pi4. If yes, you can revert all patches specific to my SOB? Then apply https://github.com/guysoft/RealtimePi/tree/3225584da703cdb4409932835362298aa446cd05/src/modules/realtimepi/filesystem/home/pi/patches on it, you can try this kind of version on your hardware platform. I still have no pi 4.

[TiejunChina]

At my first glance, just one patch takes effect compared to my branch. That is the patch, "Revert "softirq: Let ksoftirqd do its job"". Or maybe you just need to apply this on it rpi-4.19-y-rt to validate that again. If that can work, I'd like to merge that to rpi-4.19-y-rt in advance to make sure at least we have a workable rt branch. And then once I get pi 4, I can further dig into the problem.

[guysoft]

@TiejunChina Cool, if you do I can issue another build and then people around here can test it.
You might have your code ready and tested even before the Pi4 arrives :)

[MetalMusings]

Hi guys, I am the one testing the rpi-4.19-y-rt. I could not make it boot. No screen, no output in any log files that could give a clue on what was going on.
I was able to download the source for rpi-4.19-y, apply the patches for 4.19.50 which patched clean except for a few line offset warning. Compile, install and that worked just fine.

[TiejunChina]

@HakanBastedt You're talking about pi4? Or pi3

[MetalMusings]

Raspberry Pi 4 model B, 4GB memory.

[andypugh]

An observation, which might, or might not, be relevant.

I compiled a realtime kernel last night (rpi-4.19-y), patched with the (wrong) patch from kernel.org. (4.19.58 kernel patched with 4.19.57 patch).
The process created a "kernel7l.image" file alongside the existing "kernel7l.img" file. (note the difference in file extension).
I am not sure what causes the different file extension. I added kernel= to the config.txt file to use the RT kernel as I see it as actually useful to be able to revert to the standard kernel.
Is it possible that the realtimepi build scripts are simply ignoring this .image file?

[guysoft]

@andypugh Do you need both files?

At the moment this is the code that extracts the image:
https://github.com/guysoft/CustomPiOS/blob/devel/src/modules/kernel/end_chroot_script#L47

It takes if from arch/arm/boot/Image from the kernel source.

Also I can see in the build log:

  OBJCOPY arch/arm/boot/Image
  Building modules, stage 2.
  Kernel: arch/arm/boot/Image is ready

So it looks like the file is in place.

You can run the build youself and have a look (suggest only one kernel because it takes a while).
Or I can put something to test if that helps.

Full build log attached.
build.log

[andypugh]

I would need to look back through the command history, but it is looking rather like the ,image file was created by me miss-typing a command, and my previous message should be ignored.

[andypugh]

Hi guys, I am the one testing the rpi-4.19-y-rt. I could not make it boot. No screen, no output in any log files that could give a clue on what was going on.

Exactly the same result for me on the Pi4.
I checked-out rpi-4.19.y-rt, found that there was no bcm2711_defconfig file in that branch, wgot that from github, compiled, installed, got nothing on boot even configged for no splash and boot to terminal.
Checked out the 4-19-y branch, (4.19.58 kernel) applied the 4.19.50 preempt-rt patch (close enough fit to apply), compiled and it all works nicely.

[MetalMusings]

When I checked, I saw that rpi-4.19.y-rt was something like more than 500 commits behind rpi-4.19.y. At that point I abadonded rpi-4.9.y-rt. Just so you know, I wish it had worked.

[TiejunChina]

Good, I'm happy to rebase our branch but I'm in my business travel. I'll make this next week. Thank you, guys!

[guysoft]

I am heading our camping in Denmark so will probably have time for it only next week anyways

[TiejunChina]

@guysoft @andypugh @HakanBastedt I just refreshed rpi-4.19.y-rt as
4.19.59 + v4.19.59-rt23 + rpi-4.19.y patches against 4.19.59 + "usb: dwc_otg: fix system lockup when interrupts are threaded" + "Don't need to use _nort" + "Enable CONFIG_PREEMPT_RT_FULL". I also enabled bcm2711_defconfig as well.

[MetalMusings]

Tested today. Yeah works fine. Thanks, great!

pi@raspberrypi:~ $ uname -a
Linux raspberrypi 4.19.59-rt23-v7l+ #1 SMP PREEMPT RT Tue Jul 23 15:57:25 CEST 2019 armv7l GNU/Linux

The latency-figures are more than acceptable for linuxcnc using the mesa 7i76e card. Especially when wlan0 is disabled. I tried also with a separate usb-wlan dongle, but same figures. With wlan active say 100 microseconds, without wlan 20 microseconds. I know the numbers doesn't say a lot, but if better latency is wanted then disable wlan.

Thanks again.

[guysoft]

Started another build, should finish by tomorrow and we should have something to test.

[MetalMusings]

Just to report, I have got the rpi-4.19.y-rt kernel mentioned above running linuxcnc for a while now and that works fine.
What are the plans here? Will it be released as a package? Or to be compiled by users?

[guysoft]

Ok, unmouinting the docker environment and remounting fixed it. Strange but fixed :)

Image:
http://unofficialpi.org/Distros/RealtimePi/nightly/2019-08-07_2019-07-10-realtimepi-buster-lite-0.4.0.zip
md5:
http://unofficialpi.org/Distros/RealtimePi/nightly/2019-08-07_2019-07-10-realtimepi-buster-lite-0.4.0.zip.md5

kernel only that you can untar on top of an existing raspbian:
http://unofficialpi.org/Distros/RealtimePi/nightly/2019-08-07_realtimepi-kernel-4.19.59.tar.gz

Note: I didn't change the cmdline.txt mentioned here:
raspberrypi/linux#2943 (comment)
Likely now that the usd owc patch is in place I can remove that, rebuild, and hopefully release.

[guysoft]

Ok, new build with the right cmdline.txt.

I wanna test it here, if it works it goes out as an release candidate.

Please help test!:

http://unofficialpi.org/Distros/RealtimePi/nightly/2019-08-20_2019-07-10-realtimepi-buster-lite-0.4.0.zip

md5:
http://unofficialpi.org/Distros/RealtimePi/nightly/2019-08-20_2019-07-10-realtimepi-buster-lite-0.4.0.zip.md5

Kernel and modules only:
http://unofficialpi.org/Distros/RealtimePi/nightly/2019-08-20_realtimepi-kernel-4.19.59.tar.gz

Pi 4 boots in to normal kernel, Pi3 B+ does not boot. Use previous build

[guysoft]

Ok, this means we need to compile 3 kernels, now, also kernel7l.img.

[guysoft]

Solved in 0.4.0 RC2 (build should be uploaded shortly #2943