Advanced Search

Kernel built whilst using Rod's imager, running over a ssh session.

gene_weber wrote:

I will probably create a separate thread about jitter optimization.

This is badly needed based on the reported latency which is unusable

I have a 4b that is bricked like this.
Try updating the firmware using the Pi Imager. That may work. Otherwise I have no solution

Create the base .config file for the Raspberry Pi 4 64-bit:
NOTE: For a Raspberry Pi 5 64-bit the lines should be:

Make / launch the menuconfig utility:
Install the required package:
Under General Setup, select: Fully Preemptible Kernel (Real-Time)Exit and Save.


Change Local version name. vi .config and change the following line:To:

Build the kernel and log the output (Note this took over 2 hr 10 min):
NOTE: During the compilation process the temperature of the ARM processor increased from ~30°C to as high as 43°C. I have a heat-sink and cooling fan on my Pi. If you don't, you may want to keep an eye on the temp (/usr/bin/vcgencmd measure_temp). The maximum rating on the Pi is 85°C.


Install the kernel modules onto the boot media and log the output:
create a backup image of the current kernel, install the fresh kernel image, overlays, README, and unmount the partitions:

Reboot the Raspberry Pi to run the new kernel:
Check kernel after reboot:    Linux raspberrypi 6.13.0-rc7-rt3-v8_full_preempt+ #1 SMP PREEMPT_RT Tue Jan 14 12:49:46 EST 2025 aarch64 GNU/Linux


From the LinuxCNC downloads page , download LinuxCNC Uspace 2.9.3 arm64 .

Install the Gdebi installer:Run the Gdebi installer and install linuxcnc-uspace_2.9.3_arm64.deb

EDITED 1/16/25: Changed image to X11 pre-optimization latency.
Ran a baseline latency test before making any jitter optimizations.    Note: Using POSIX realtime


I checked the real-time attributes of the latency-histogram process (the process ID for this run was 10527):    pid 10527's current scheduling policy: SCHED_OTHER
    pid 10527's current scheduling priority: 0

I had thought the policy would be SCHED_FIFO, or SCHED_RR. But even after I added CPU isolation it remains SCHED_OTHER.

I will probably create a separate thread about jitter optimization.

I'm posting the steps I executed to build and install a PREEMPT RT Linux kernel in Raspberry Pi OS for my Pi 4B for two reasons.

1. Hopefully it helps someone trying to do this or something similar. I appreciate the pointers I got from alangibson, cornholio, and rodw
2. This is the first Linux kernel I've ever built. So I open this up to comments and suggestions.

NOTE: Version 6.13 of the Linux kernel is under development and could have bugs / issues. So far it's been stable for me, but your mileage may vary.

I started with a fresh installation of Raspberry Pi OS on my Pi 4B.

1/16/25 Edit: Based on responses after the initial post it was clear that the Wayland display protocol is non-optimal for LinuxCNC. A comparison of the baseline pre-optimized jitter was conducted where the only difference is the display protocol, Wayland vs X11. The latency histograms for each are included in those posts, and show a dramatic difference with X11 inducing significantly less jitter. Wayland is the default in the current Raspberry Pi OS, but is easily changed to X11.

You can check the session type:    wayland

Launch Rasp-config command line tool in a terminal:Arrow down to "Advanced Options", and enter.
Arrow down to "Wayland                 Switch between X and Wayland backends", and enter.
If not on the line that says "W1 X11     Openbox window manager with X11 backend", arrow to it and enter.
The popup should say "Openbox on X11 is active" and have "Ok" highlighted. Enter.
It will return to the main screen. Use left-righ arrows to select "Finish". Enter.
Popup asks if you would like to reboot now, with "Yes" highlighted. Enter.

After reboot:    x11


Raspberry Pi's documentation on how to build a kernel was used as the guideline for this process:

Download the source code for the 6.13 Raspberry Pi kernel:
Install the needed build dependencies:

Download the RT patches for v6.13 and the signature file. Starting here , select the tarballs link at bottom left of page. From the list of versions, select the 6.13 link .
Download the patch file patch-6.13-rc6-rt3.patch.gz:Download the signature file patch-6.13-rc6-rt3.patch.sign:

Verify the signature of the patch file. These were committed by Sebastian Andrzej Siewior.
Add the following two lines:
Get the public key for "Sebastian Andrzej Siewior <This email address is being protected from spambots. You need JavaScript enabled to view it.>"
Unzip the patch file:
Verify signature:    gpg: assuming signed data in 'patch-6.13-rc6-rt3.patch'
    gpg: Signature made Thu 09 Jan 2025 05:04:09 AM EST
    gpg:                using RSA key 57892E705233051337F6FDD105641F175712FA5B
    gpg: Good signature from "Sebastian Andrzej Siewior <This email address is being protected from spambots. You need JavaScript enabled to view it.>" [unknown]
    gpg: WARNING: This key is not certified with a trusted signature!
    gpg:          There is no indication that the signature belongs to the owner.
    Primary key fingerprint: 6425 4695 FFF0 AA44 66CC  19E6 7B96 E816 2A8C F5D1
         Subkey fingerprint: 5789 2E70 5233 0513 37F6  FDD1 0564 1F17 5712 FA5B


Go back to the linux directory created by the git clone:Patch the 6.13 RT kernel:    patching file arch/arm/Kconfig
    patching file arch/arm/kernel/module-plts.c
    patching file arch/arm/kernel/traps.c
    patching file arch/arm/mm/fault.c
    patching file arch/arm64/kernel/ftrace.c
    patching file arch/arm64/kernel/traps.c
    patching file arch/loongarch/kernel/ftrace_dyn.c
    patching file arch/loongarch/kernel/unwind_orc.c
    patching file arch/powerpc/Kconfig
    patching file arch/powerpc/include/asm/stackprotector.h
    patching file arch/powerpc/include/asm/thread_info.h
    patching file arch/powerpc/kernel/interrupt.c
    patching file arch/powerpc/kernel/trace/ftrace.c
    patching file arch/powerpc/kernel/trace/ftrace_64_pg.c
    patching file arch/powerpc/kernel/traps.c
    patching file arch/powerpc/kvm/Kconfig
    patching file arch/powerpc/lib/vmx-helper.c
    patching file arch/powerpc/platforms/pseries/Kconfig
    patching file arch/powerpc/platforms/pseries/iommu.c
    patching file arch/s390/kernel/dumpstack.c
    patching file arch/x86/kernel/callthunks.c
    patching file arch/x86/kernel/dumpstack.c
    patching file arch/x86/kernel/unwind_orc.c
    patching file arch/xtensa/kernel/traps.c
    patching file drivers/gpu/drm/i915/Kconfig
    patching file drivers/gpu/drm/i915/display/intel_crtc.c
    patching file drivers/gpu/drm/i915/display/intel_cursor.c
    patching file drivers/gpu/drm/i915/display/intel_display_trace.h
    patching file drivers/gpu/drm/i915/display/intel_vblank.c
    patching file drivers/gpu/drm/i915/gt/intel_execlists_submission.c
    patching file drivers/gpu/drm/i915/gt/uc/intel_guc.h
    patching file drivers/gpu/drm/i915/i915_request.c
    patching file drivers/gpu/drm/i915/i915_trace.h
    patching file drivers/gpu/drm/i915/i915_utils.h
    patching file drivers/tty/serial/8250/8250_core.c
    Hunk #1 succeeded at 403 (offset 15 lines).
    Hunk #2 succeeded at 411 (offset 15 lines).
    Hunk #3 succeeded at 541 (offset 15 lines).
    patching file drivers/tty/serial/8250/8250_port.c
    Hunk #4 succeeded at 3317 (offset 9 lines).
    Hunk #5 succeeded at 3350 (offset 9 lines).
    Hunk #6 succeeded at 3409 (offset 9 lines).
    Hunk #7 succeeded at 3475 (offset 9 lines).
    Hunk #8 succeeded at 3618 (offset 9 lines).
    Hunk #9 succeeded at 3628 (offset 9 lines).
    patching file include/linux/kallsyms.h
    patching file include/linux/module.h
    patching file include/linux/preempt.h
    patching file include/linux/serial_8250.h
    patching file kernel/cfi.c
    patching file kernel/jump_label.c
    patching file kernel/kprobes.c
    patching file kernel/ksysfs.c
    patching file kernel/livepatch/core.c
    patching file kernel/module/internal.h
    patching file kernel/module/kallsyms.c
    patching file kernel/module/main.c
    patching file kernel/module/tracking.c
    patching file kernel/module/tree_lookup.c
    patching file kernel/module/version.c
    patching file kernel/sched/core.c
    patching file kernel/static_call_inline.c
    patching file kernel/trace/bpf_trace.c
    patching file kernel/trace/trace.c
    patching file kernel/trace/trace_kprobe.c
    patching file lib/bug.c
    patching file lib/dump_stack.c
    patching file localversion-rt

Hello everyone, I'm very new to everything Linux related but frustrations with my current machinery has led me down a rabbit hole. Here we are.

I saw people asking for feedback on running the 2.9.2 package on a raspberry pi. I have a Raspberry Pi 4B 8G model that I have attempted to boot the 2.9.2 image to with very little success. I used the XZ file on the downloads page and put it into the Raspberry Pi imager, the board was booted with a small touchscreen plugged into it's display port via ribbon cable. ACT/power lights appeared promising until I got a peculiar message showing up on screen with some skulls. I have attached it here.  

After the skull message, power light turns off and the ACT light switches to a faint, consistent flicker while the display continues rotating through solid colors. 

It's entirely possible that since this is the second time ever using one of these that I have royally screwed up somewhere. I have also read some negative reviews as far as the compatibility of the 8G model goes so it could have something to do with that. Any and all info you guys could provide would be greatly appreciated. Thank you!

[Edit], the XZ file taken off the homepage for version 2.9.2 failed to flash using BalenaEtcher 

Goto the linuxcnc home page.

Where do I find a current link to download the 2.9.3 image for Pi 5?
Thanks

My RPi5 kit has come up. A book report:

The full kit name as listed in Amazon is:

  -- iUniker - Extreme Starter Kit for Raspberry Pi 5 - (8GB RAM - 128GB Storage Edition)
  
Definitely a learning experience (several delicate operations but that's probably good if you are needing to learn).

• A critical concern with all electronics not designed to handle it is electrostatic discharge (ESD). Shuffle across a rug and touch the bare board and your new RPi5 may never come up. The RPi5 specs make a nod toward ESD protection but one way to get by ESD, if you don't have a special "static discharge mat", is to lay down a very slightly damp cloth and work on it.
•  I only received a 64 GB SD card instead of a 128 GB SD Card.
•  I only received one video cable instead of 2.
•  Once installed, the fan connector needs to be inserted into a plug on the board. The plug seemed to elude me for quite a while but it's there. Be very sure of which way around the plug needs to be oriented.
• The 4 USB connectors are very, very difficult to insert into. I worried about the stress on the board. I opted for a hard-wired keyboard/mouse combo and had to use 2 USB connectors. It supports wireless keyboard/mouse combos if you have them in pairing mode at system boot time.

Finally, it came up, started, and took my breath away. Very cool.
Tom

Hello @cornholio:

I do understand some of the things you are saying. 

I'm not a LinuxCNC'er so please bear with me.

A start might be to enumerate types of users as I see them:

Gold users just want to get something done (say make parts for a space station). Their CNC machines are already supported by LinuxCNC. They would appreciate a working version of LinuxCNC. Once they get it they probably will not change it over time unless they need to support new devices or new features.

The key here is that installing and getting LinuxCNC running should be as easy as it is to get Raspberry Pi 5 or Ubuntu up in the first place. (I'm not sure if my experience getting RPi5 up is similar to getting RPi4 up but more on that later).

If a newcomer can not get a version going enough to run say a "Maslow" machine (please Google "maslow cnc kit") then work still needs to be done.

Silver users/developers know and contribute to the LinuxCNC GitHub repo. The users have absolute control of the repo and the CNC, sysgen and testing features merged into it.

Bronze users/developers know and contribute to the Linux GitHub repo. The users have absolute control of the repo and the OS, sysgen and testing features merged into it.

The question comes: How to manage the need for support between Gold, Silver and Bronze users. I'm not sure of a solution here but I believe some solution will arise.

Tests should exist that (all) developers can run and get understandable results from. The only issue should be coverage at a given point in time. Hopefully the more tests you develop and manage the better off everyone should be.

I realize some of the above exists. It just needs to be pulled together.

An observation about configuration files: I think they may have gotten a bit out of hand.

I believe plain text files are easier for users to work with than XML but, a coherent "system build, installation and configuration" facility may be easier to develop and maintain if the configuration is rationally represented by some data handling facility (not a DBMS).

Please let me know your thoughts up to this point.

Many thanks,
Tom

Hi Guys, I'm pretty new here and just getting started with LinuxCNC, I've been retro fitting a rf31 mill and have a NVEM V2 I was using with Mach3 on an old laptop. the laptop started to play up and lost all my motor settings so i decided to ditch it all and buy a Raspberry Pi 5, load it with LinuxCNC and set it up solely for this machine.
I recently got my STlink all setup and now I need to confirm which bin file I need to download from GitHub? is it the Remora-NVEM-STM32-1.0.0.bin file in the Remora-NVEM/firmware directory or the Remora-NVEM.bin file in the Remora-NVEM/Remora-NVEM-STM32/Firmware directory? 
I'm going off the Scott 3D Youtube videos, but the GitHub info seems to be a bit out of date. Is any of the info in those videos still up to date or should I be looking elsewhere?
Thanks

First of all this is the first time I can recall this issue emerging.
I & many others I have used the image mentioned by the OP with no issues.

The screen going black isn't an indication that the Pi is bricked, there is a setting config.txt that controls whether you get the "rainbow" screen or not.

Generally there are issues which using the Rpi imager to write the image. If using windows Balena etcher is recommended, on Linux balena etcher can be used, dd is another alternative or whatever image writer that comes with your system.

To be pendantic, the bootloader is contained on the RPi board. As you have not mentioned any messages about of an out of date bootloader I doubt this is an issue.

One thing you could try, as you say you just recently bought a RPi5, is insert a blank SD card, connect an ethernet cable and boot. If you have the most recent bootloader the RPi5 should attempt to load an OS to the SD card via the internet.

pimylifeup.com/raspberry-pi-network-install/

One point to note, you get far far better bang for buck using a second hand corporate PC that a RPi5.

That is sort of what I tried. Unfortunately the new configs can only be made for a parallel port or a Mesa card.

Since this is a raspberry pi the parallel port won't run. I do have another working CNC that is running a Mesa, but that is operational and in use at the moment.

What I attempted here was to use the sample config I had to get a working gmoccapy, which worked fine, including jogging.

I then ran the wizard with the par_port option and qtPlasmac as the front end to create a default plasmac config.

I then replaced the par_port and associated hal nets, mainly just the joints and limits with the ones from the working gmoccapy config.

Unsure if there is a better way to achieve this.

Hello all, could use some help.  Currently in the final throws of getting a new build up and running:
QtPlasmaC V2.9-238.314
Raspberry Pi5
Mesa IO boards
Sheetcam and associated post processors

I realized that my THC was active on holes, which then led me to see that M67 commands weren't working for my holes.  Further investigating showed the following:

• M67 is working as I expect it to if G1 linear commands follow in lines below
• When a G3 is encountered, it resets feedrate to 100% and executes the arc at 100%
• I didn't test G2 yet
• If an inline M67 is issued with the G3, it will execute the arc at commanded rate.  For example, have the following as one line of code:
  • G3 X0.0 Y0.0 I-0.2 J-0.2 M67 E3 Q50
• However, after executing the above correctly it STILL resets feedrate back to 100%

I don't believe this is the expected behavior, my apologies if it is.  If it is the expected behavior, can someone point me to a Sheetcam post processor that would format it as such?

Thank you!

These are the exact commands I do:
git clone github.com/raspberrypi/linux.git -b rpi-6.12.y
cd linux
KERNEL=kernel_2712 make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- bcm2712_defconfig
KERNEL=kernel_2712 make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- menuconfig

After that you choose fully preemptible.
Now I wonder what you do different I guess you didn't use the defconfig, then you should set EXPERT=y like I mentioned before: General Setup => Configure standard kernel features (expert users) and press Y, and Fully Preemptible is visible. But I advise to apply the changes to the defconfig at github.com/by/RT-Kernel except the rtc and ntp options, and use the defconfig.

To enable the realtime indicator I used the patch that I posted on page 2.
wget forum.linuxcnc.org/media/kunena/attachme...ernel-realtime.patch
cd linux
git apply ../sys-kernel-realtime.patch

And to prevent compile errors (after the above patch) go at menuconfig to: General Setup =>  Kexec and crash features => press Y so CRASH_DUMP gets selected so VMCORE_INFO gets selected.