Regarding Repositories

Interesting. And thanks for the reply!

Just to clarify, (1) are you saying the linuxcnc-2.8.1-pi4 doesn't work reliably on RasPi 4s (ie, might work on a particular model, but not for example the 4B)? (This might explain why I get a doorstop when I tried to use it on my rpi4 clone)

and (2) is there a reason you're suggesting upgrading all the way to Bookwork (Debian 12) instead of just resting at Buster (Debian 10), ie, do you know that won't work on an ARMHF?

Sorry vector if I seemed negative about ARM + Linuxcnc I just seem to see too many guys arriving at linuxcnc with the opening statement "hi, new to linux / linuxcnc .... i would like to install it on something unusual..."

whilst I am 100% certain it can be done.... is that REALLY what you want to start off with on day 1 of linux / linuxcnc and do it the hard way.

I would love to climb everest.... but I've never climbed anything in my life other than a few small hills and I get board after a while. I don't think I should really be getting an airline ticket to climb up the east side of Everest wearing nothing more than trainers and a pair of shorts .... (or mount Fuji):
www.thesundaily.my/style-life/going-vira...rwin-award-YA2604661


__________________

Yes there is an armhf distro:
bottom of the page: Linuxcnc distributions:
linuxcnc.org/downloads/

If you have installed linuxcnc on a PC first a few times and got used to its nuances then maybe look to build a RIP install as that will be VERY easy on a PC, you can then flip this experience to an SBC and hopefully resolve any issues.

have you done a latency test on the ARM?

have you tried to install the RT kernel?

the RT kernel is really the first key thing to get working on the ARM..... then building lnuxcnc if you cannot install one of the distros.

No worries, you guys are very welcoming already. (Some places dish a lot worse.)

I'm coming at this project after building several 3d printers and some robotic projects for the kids, so the SBC as a master controller for a g-code driven driver controller is in my comfort zone... plus my longer term concern about keeping the form/power factors as small as possible.

My linux is rusty, so it's been fine with me rebooting my knowledge while tinkering with the SBC... not lost time since I'd need to lose that time later on here and there.

I haven't attended to the rt kernel. looking into that now.

Thanks again for everyone's help!

It's on the standard kernel. I'm going to attempt to upgrade to RT now as now I see from your highlighting it for me that it's a prerequisite.

Congratulations on getting so close to being an official debian package. That must have been a heavy/long term lift.

Thanks again!

In case anyone finds this thread and is looking to put a Real Time Kernel onto an SBC aka a Single Board Computer, I offer these notes.

FYI, in my specific case I'm trying to get LinuxCNC onto a Single Board Computer clone of Rasberry Pi... my board is a libre-computer ALL-H3-CC H5 (2GB).

Generally SBCs are likely to use less expensive ARM chips (as opposed to AMD chips). This class of processors appears more problematic than AMD chips with respect to CNC for the following reason:

LinuxCNC needs a Real Time (RT) kernel in order to operate hardware. It supports three RT linux kernels (see linuxcnc.org/docs/html/getting-started/getting-linuxcnc.html ) : preempt-rt, RTAI and Xenomai. However, RTAI's website says they do not support ARM chips and Xenomai appears to be no longer under active development. So there's only one real choice for ARM enthusiasts: preempt-rt.

Therefore, to install LinuxCNC on this ARM based Single Board Computer, we're going to set our sights on installing a Preempt-rt linux kernel.

The normal fix would be to (a) download kernel files using either Synaptics (gui) or commands like apt-get , (b) verify the new RT kernel files are present in the /boot/ directory, (c) issue sudo update-grub (which writes the /boot/grub/grub.cfg file, (d) reboot, and finally (e) at the GRUB screen use the keyboard to select the new kernel, and post-finally (f) enjoy your success. 

However, this world of SBCs is a kind of Wild West where each manufacturer rolls their own bootloader for versions of hardware that in some cases are changing within weeks and months. They're shooting and running and not waiting around perfecting all the internal software-tool parameters.

My libre-computer board has a boot flow which I suspect resembles many others like Beagle Board, Raspberry Pi, and a whole host of ever-changing clones. That sequence is: U-boot launches to EFI (aka UEFI) which launches to GRUB (actually GRUB2) which launches Linux.   (Note the complete absence of BIOS)

In my case, the U-boot is version 2019.04 (Mar 25, 2019) ; EFI version is actually unknown; and Grub is Grub2

Apparently there is simply not enough resource at the board manufacturers to fully vet their initial bootloader implementations (U-boot to EFI to GRUB) and consequently many of the troubleshooting tools we might want do not work; a partial list of those tools includes: efibootmgr, fw_printenv, dmidecode -t bios, etc..

The reason the debugging would have been nice in my case is because I could not follow the normative sequence above. It failed at step (e) because I could not see a second kernel installed on the GRUB screen. Nor could I enter the GRUB command shell to even begin debugging because doing so requires using a keyboard and the SBC doesn't get keyboard drivers loaded until after GRUB loads the kernel. (Which also means that even if the kernel had appeared, I wouldn't have been able to use the keyboard to select it, though I could have worked around that by changing the default selection in grub.cfg.)

I spent many hours learning all of the above because when the tools weren't working, I still felt like perhaps I had made a mistake and so I kept troubleshooting down a rabbit hole that never had a rabbit.

If you have reached the point where you tried the correct sequence above and GRUB is not behaving as expected, and you're on an SBC, you may want to use the work around below. Otherwise I suspect that in order to make GRUB boot more than one kernel on many SBCs you will ultimately need to compile your own U-Boot to EFI to GRUB bootloader with complete loving care. While this could be a worthy fight, personally I decided I was happy pushing away from the table with my 'learning winnings' and not gambling more time or energy on a board that costs less than $50. This choice was even more rewarding because at the last second I discovered a kludgy fix... 

The good news is, you probably don't need more than one kernel version -- if you accept that, then you're ready to move on to this little trick to make GRUB pick up the one you want.

Basically you manually delete the old kernel files, then regenerate the GRUB config and reboot into RT nirvana.

The exact steps that need to be inserted between (c) and (d) above are: (ie, first do steps a, b and c from above, then do these steps i thru vi)
(i)    backup your SD card in case this fails.
(ii)    sudo mkdir /bootold
(iii)   use sudo mv to move all the "old" kernel files from /boot to /bootold.
(or if you're going yolo, you could delete these, but I don't recommend that)
In my case these files were:
    config-4.19.55+
    initrd.img-4.19.55+
    System.map-4.19.55+
    vmlinuz-4.19.55+ (note that this was a compressed file, but the new vmlinuz is not, do not compress the new vmlinuz)
(iv) Verify you have the 4 equivalent kernel-related files left in the  /boot directory.
In my case these new files were:
    config-4.19.0-0.bpo.19-rt-arm64
    initrd.img-4.19.0-0.bpo.19-rt-arm64
    System.map-4.19.0-0.bpo.19-rt-arm64
    vmlinuz-4.19.0-0.bpo.19-rt-arm64 (note this is not a compressed file)
(v) sudo update-grup
(vi) reboot

And if karma is with you, it will then boot into the new kernel.

It's a stupid work around: basically telling GRUB to work as a single-image only boot.

But, sometimes the stupidest rock can beat the most exquisitely crafted scissors.

Good luck.