Can the OPI5 be Configured to Run LCNC?

That's the one Armbian also use for the OPI5 images, with this patch:
github.com/armbian/build/blob/master/pat...oard-orangepi5.patch

github.com/orangepi-xunlong/u-boot-orangepi.git

After editing some of the rt patches, hoping that after I fix the first few patches the follow up patches would apply without errors, but of course they didn't, I found there is actually a kernel from Rockchip with the rt patches meant for Android:
github.com/rockchip-linux/kernel/tree/develop-5.10-rt53
Had to make s small patch and disable some things in the kernel-config to make it compile. It did boot, but the whole system got stuck after a while every time and it was still not a full realtime kernel. I know made some config errors. Will look further into it soon.

After applying an overlay to overclock the big cores to 2.4ghz the max jitter of the servo thread is 25us with 4x glxgears and playing 4k YouTube.I've added a screenshot and the compiled overlay from a patch of github
Boot parameter: isolcpus=5,7
If someone is getting more jitter with this overlay I could upload my kernel (settings).

Too bad, just before I'd finished this message the max jitter went to 54us (after about 45min running) Need to say that I've running tvheadend with an USB dvb tuner and zigbee2mqtt in the background as well.
Arch timer interrupts a lot on cpu7, but there is also a rk timer which avoids cpu 5 and 7 as it should. 
Could the rk timer function as a replacement of arch timer?

Found a Preempt_RT image, but had to change the bootloader. Unfortunately no source code available. But it works great. After about an hour a max jitter of 8.1us, assuming the biggest number is the max jitter (-8.1). Either way for Mesa/Remora this is perfect.

The base-thread is still going up to 100us somehow, so it's not good for software stepping yet. I've isolated 2 cores and only 1 core is getting used, so I assume the base thread is on the same core as the servo thread? What could be the reason for the the base thread latency getting so high? Would it be possible to make that a separate process on the second (first) isolated core?

Correction, actually not bad at all, didn't test the base-thread after my last change in the boot parameters. Now has max jitter of 13.9us on base and 19.4us on the thread after a quick test of 20min, I expect it stays stable since it also did with only the servo thread for an hour.

Since the image is meant for another board and I had to install another bootloader to make it work on the OPI5, is it allowed to post an image or howto, if there is any interest?

The requirement for a base thread is only for software stepping on the main core processors and using GPIO for Step/Dir.

Mesa and Remora only require a Servo thread. The 8.1uS jitter is well beyond the <100-200uS jitter required.

If the integrated Cortex M0 microcontrollers can be used for software stepping they would be accessed with a Servo thread and have their own firmware similar to Remora or OrangeCNC for Step/Dir generation.

The base thread is actually not bad at all, at the moment running the test for 45min and still 13.9us on the base thread and 19.4us on the servo thread. So even software stepping is possible.

I've seen on the website of the manufacturer a page about the rt kernel that they mention to use the mcu's when you need even less latency, but that's all the information they give.

Maybe I will look at the MCU later if it's easy to port/copy to this board. Actually just bought a micro desktop for LinuxCNC which work well, although not as good as the OPI5.

Please post the link to the kernel and patches tested here along with your boot parameters so others can follow.

Thank you again!

I'd downloaded the image with rt-kernel (...rtlinux...) from:
drive.google.com/drive/folders/1tlyMGSqB...yWGSXBo6CVWPw7jkJ0sy
The image has a tool included to write the image to a SD. In the config.ini file you could set the language to English. In the tool you've to choose for upgrade, then write to the SD.

The SD card now has about 7 partitions. Copy from the third partition "boot" the kernel files to a local folder: Image-5.10.110-rt53 System.map-5.10.110-rt53 initrd-5.10.110-rt53 and lib directory (which I forgot and not missed them yet)

Then delete from the SD card all partitions except the 6th (rootfs) partition. On Linux it's easy to use Disks for that, however with Gparted you'll see all the partition labels. Create a new partition at the beginning, filesystem doesn't matter.

For the bootloader, download the Reborn OS image:
github.com/RebornOS-Developers/lxqt-opi5-image/releases
Mount the image and dd the mounted BOOT partition to the first partition of the SD.
For example: sudo dd if=/dev/loop0p1 of=/dev/mmcblk1p2

Copy the rt kernel files to the BOOT partition of the SD card
Copy the dtb file (I used the one from Armbian) for the OPI5 to boot/dtbs/rockchip
Then edit the extlinux/extlinux.conf file:Check if all the filenames are correct, somehow it didn't find the UUID so had to put the /dev/ name, in armbian the name was mmcblk1... but now it was mmcblk0...

From the rootfs partition edit the etc/fstab to
UUID=f5b6bbae-4757-4154-963f-8f787f9b3df6  / ext4 defaults,noatime,commit=600,errors=remount-ro 0 1
UUID=B6ED-9ADC /boot vfat defaults 0 2 /boot vfat defaults 0 2

The UUID you'll see when you type: blkid

Then check if the boot partition has the right flags with gparted: boot, esp
Now you should be able to boot the system.


To be able to use glx in wayland I installed the following packages, probably not all of them are needed:
sudo apt install libwayland-egl1-mesa libgl1-mesa-glx libglx-mesa0 libgl1-mesa-dri xwayland-hwe-18.04

Now everything should work.
After 2,5hrs testing still the same low latency as at the beginning.

Hello, This thread has me very intrigued and after reading this thread a couple of times, it has convinced me to try and pursue this approach. I have already purchased a OPI5 and am looking to attempt to set the board up exactly as describe by royka.

Now I realize this isn't the typical SD image burn one would do for a Rasberry Pi and is more of a hack, so there would be some hiccups along the way.

Right off the bat though I ran into a hiccup and wanted to get some clarification on the first step. Using the update tool, I realize you have to connect your OPi5 to a host computer and write the image using the update tool. I am using the linux approach as my laptop is running Manjaro and figured it would be more straight forward approach via command line. However when I try to use the update_tool, I get a segmentation fault error. I was wondering if I need to prepare the SD card prior to running the tool. Or is there any specific thing I have to do when powering up the OPi5 like entering a loader or maskrom mode. I was reading the wiki page that was included in the readme.txt file and seems to be the case for the dev board explained on the wiki, I wasn't sure if it was the same for the OPi5. A little clarification could help on this step.

Cheers

You don't have to connect the opi5 to a host pc. On the orange pi site there is a great manual to get started.

Basically you'll need the rt kernel from the image I mentioned, but because that image is made for a different rk3588 board it will not boot. So copy the kernel files to a working system and rename the files to the existing ones or rename the filenames in the bootloader.

There has been some developments in the meantime, there is since today an u-boot you could write to the spi flash that could boot extlinux right from an ext4 partition, so you won't need an extra boot partition. You could find this on the Armbian forum.
There is also a working UEFI firmware made for the OPI5 (even Windows 11 could be installed), but this is all in alpha state at the moment.
So in the near future it will be better/easier to set up.

I did try straight mounting the img file, using dd and balenaEtcher to write the img file to the SD card first before using the Upgrade tool. However the .img file for the rtlinux in the link had no recognizable partition table so there was no way to extract the files. I figured there was some special process the upgrade_tool was using to write to the SD card. Its possible that my download was corrupted, so I'll give it another go after I get home from work. Also could be that the img file is different from when you wrote the procedure. It looks like the image is dated 230306. Could that have broken the procedure?