Proposal RPi Linuxcnc Image Based on Raspi OS All welcome/encoraged to comment

bcm2712_defconfig.txt is the 16k-page one, it's broken by design, don't use it that's also pretty much the only difference between it and 2711, look at the diff between the two.
bcm2711_rt_defconfig.txt works on both Pi versions, I've tested it on my setup. it's the one that linux-image-6.12.x+rpt-rpi-v8-rt is built from. I only use SPI though (with my own drivers that mmap the registers), so I'm not sure how Mesa cards or GPIO would behave.

Ok you're telling me not to use a kernel that I have practical experience and have not had a single crash or anything similar. Neither have any users reported any crashes. I think an uptime of 39 days and being able to start Linuxcnc at anytime during that period with no crashes, latency errors or any other such issues proves to me that the kernel is solid and stable.
Before using it on the mill, I had been using to test some Mesa clones one based on a 7c81 and another more less based on the 7i92 design. I've also tested Ollie's riocore system, on the same 7c81 clone hardware early this year, before Oliie got his hands on a genuine Mesa 7c81 that he has made riocore formware for.
Could you point me to any papers, references or any such peer reviewed articles explaining why the 16k page kernel is broken by design.

So this time I will stand by my choices for the RPi5. Unless of course you can provide hard evidence as requested above.

Even this page says to config 2711 for RPi4 to RPi3 and 2712 for RPi5.
www.raspberrypi.com/documentation/computers/linux_kernel.html

unknown wrote:

Could you point me to any papers, references or any such peer reviewed articles explaining why the 16k page kernel is broken by design.

yeah no, sorry, I have used too strong wording there - 16k pages used to cause compatibility issues with older software, but I believe that has been a non-issue for several years now.

unknown wrote:

Ok you're telling me not to use a kernel that I have practical experience and have not had a single crash or anything similar.

not really, because I - still - have not seen the exact kernel configs that you've used in your images. are they on github somewhere?

all I'm saying is that the ONLY difference between bcm2711 and bcm2712 configs is that the latter enables 16k pages. we don't need them, the performance increase is practically zero for our application - LinuxCNC does not allocate huge amounts of memory in runtime. 4k pages work just fine and have been used since forever, bcm2711 config works perfectly on Pi 5, I've been making chips with it for a few months now without issues.

I don't get it - if you have a working vendor-provided RT kernel that you can just apt install, why bother building your own with a useless feature that no one needs?

Config attached.

One of my previous posts as a zip archive of the rpi-image builder used to build the RPi5 & RPi4 images.

I'm of the opinion of keeping the kernel locked is not such a bad idea. It prevents users from messing things up.
It can also save "I've updated my kernel and I have xxyyzz issues" and sometimes trying to help some people out is like pulling teeth. Sometimes you have to ask for the same information a couple of times because for whatever reason they don't think it's relevant. And sometimes Linuxcnc is a users first venture in Linux, after maybe using Mach or grbl. There's no reason why an experienced user can't use alternative kernels if required or wanted.
And TBH I don't think kernel building is such a large task. The first one I built was around the time of Redhat 6.0 on a 486 with 32MB RAM (Maybe around '99 or something like that). Yes it was a very, very slow task. Back in the day were one had to hand edit files to get a dial up connection.

As for updates.....there's some user's that have machines running on Ubuntu based versions of emc2. Bit like the ecu of a car\truck\snow mobile\jetski\road bike\off road bike or similar, not often an owner will think of updates if any are available.

I see where you're coming from. I very much don't agree with it, but that's just me.

I compiled my first kernel for RedHat 7 in 2001 I think. had no idea what I'm doing but since then, the novelty of compiling kernels - or anything, really - has worn down, mildly speaking. I'm a software engineer by trade, very lazy at that, and I prefer to a) update things as soon as possible, because the more versions I skip, the harder the update would be, and b) don't do work if I can avoid it - don't write code if I can use a library, don't compile my own kernel if a pre-built one is available, don't configure things that I don't need configured, etc., because if I do that, it means I now own that thing, and if there is an issue with it, it is my responsibility if not to fix it, then to at least investigate if the issue was caused by my changes.

I guess we have differing world views, and that's perfectly alright!

Despite my misgivings and boneheadedness I shall experiment with your suggestion.
If anything goes wrong I shall visit the local coven and take appropriate action.

My work experience has been a little different, many years labouring and doing install and repairs to play equipment, road work and traffic control. What this has taught me is that people aren't that a fair percentage of people are lucky to breathe and walk at the same time. So I try to accommodate for the lowest common denominator.
Take for instance when I used to work on the railways during a weekend shutdown. Signs every informing passengers the train service has been replaced by a bus service. Panels of track that have been pulled up, and people sitting on the platform asking when the nest train is due.
So yeah no actual experience in the computer field as a professional, but way too much dealings with The General Public hahaha.

Tho there were times as a Traffic Controller when the temps were in the high 40c that some residents would offer cold drinks. Or night shift in the middle of winter when someone would bring out a hot chocolate.

@f355
Kernel I'm using with the image I produced with pi-gen. Have kernel=kernel8_rt.img in config.txt So it would appear we're cooking with the same ingredients, installed xfce4 and boots to the gui, this was done whilst logged into the lite image. The issue I seem to have is that when running latency-histogram --nobase I'm getting "using POSIX non-realtime" which makes me wonder about the kernel.

Tho I am using the same SD card that I originally wrote through RPi Imager for an RPi5 but I'm running on a RPi-400.........The goblins seemed to have move my USB keyboard from where I last put it. Could this be the issue ? Any thoughts ? Yes the kernel config does have PREEMPT_RT set. (for anyone else reading)

But I do think using pi-gen is a simple solution.

which version of LinuxCNC you're on? before 2.9.5 (I think) it required /sys/kernel/realtime to be present, which is not the case in the Pi kernels. if you're on 2.9.4, you can work around it by setting LINUXCNC_FORCE_REALTIME env var to 1 (I just do 'echo "export LINUXCNC_FORCE_REALTIME=1" >/etc/profile.d/linuxcnc-force-realtime.sh'), or update to a later version.

Cheers
Ok that worked, funny thing is the RPi5 that runs with the official image, with the kernel I built, does have /sys/kernel/realtime present.

Ahh that's right my kernel guru explained it earlier.

forum.linuxcnc.org/38-general-linuxcnc-q...6-12?start=10#315437


Now, since you mentioned 6.12.47 seemed to crash, would you think it would be an idea the pin the kernel to 6.12.34 ?

Tho there does seem to to be 6.12.54.........natively ran a build using the sources pacakge from the raspi kernel repo.

But me thinks I'll stick to the basics for the time being.

Bit of an update:

Images have been created for bookworm, the only issue being:
Have to include a /etc/profile.d/linuxcnc-force-realtime.sh script to set up realtime as discussed above.

This one is the breaker for any real testing, booting to first login is to the terminal, has to be manually set for booting to desktop, then rebooted, after that everything is ok. Seeking answers via github so stay tuned.
Goal is for RPi users to feel more at home, except from the desktop change from LXDE to XFCE.
On the creators side, no having to build kernels, kernels come form the rpi repo.