Can the OPI5 be Configured to Run LCNC?

rodw that would be very nice if you could make an Armbian repo to build rt kernels for sbc. Without the rt patches I guess it will not perform well, but as long as it's (close enough to) mainline it wouldn't be difficult to apply the patches.
The Armbian kernel is dependent of the source, when the Opi-5 will be supported by mainline, that will become an option too. It's just that at the moment there isn't a better option.

Andrea here is the image: easyupload.io/qtgt4aIt's not a clean image, I used it first to built LinuxCNC too, so all the dependencies are installed on it. The debs are also in a folder, so if someone need these for Ubuntu Focal... The passwd is the same as the username.Oops I see that you need to set the scale back to 100% or enable Fractional scaling in the display settings, otherwise the letters in LinuxCNC are a bit scrambled.I also forgot to test audio from hdmi, to fix this:
 - Place the extracted file "HDMI-OUT.conf" in /usr/share/alsa/cards/
 - sudo nano /usr/share/alsa/cards/aliases.conf
 - Then add " rockchip-hdmi0 cards.HDMI-OUT "
 - sudo alsa force-reload && pulseaudio -k && pulseadio -D
After this you could choose hdmi in the settings.
 

Update:
I compiled the repo you suggested (just kernel) but it was available only LEGACY and not EDGE.. don't know how bad it is.
Now I'm ready to build with 3 steps but I'm convinced I should fist place the patch RT somewhere.
I tried 5.10.176 and 5.10.109 in all folders inside userpatches but they don't work.
I was able to see "FULLY PREEMPT" option only one time but confirming it and going ahead I got error building.
So.. which version of patch RT have sense to test in your opinion?
..and where is the right folder (avoiding to try all )
Based on what Royka wrote seems not possible to patch RT then.... so, Rodw, do you agree or could make sense I still trying with some more ideas?
 

Great job Royka!!
It works, the latency is absolutely good, better than RPI4 with RT.. Of course this board is super performant. I can't imagine with RT, maybe in future someone....
Now I will focus next days to rebuild the hardware and try with my CNC.

Thanks a lot

This is with rt and 2 cores isolated (5 and 7), latency should be somewhere around 10us. Adding "idle=poll" might help a bit, but you'll need a good heatsink and IMO not worth it with this result.
I don't expect that the mainline kernel will perform better soon, but it shall be better secured for sure.

So I feel like this process has been a series  one step forward and two steps back with any attempts to get a ryoka's configuration to work. 
After a bit of digging, I was able to find the SD_Firmware_Tool on firefly's website that allowed me to write the rtlinux image to an SD card so that I could extract the kernel files from the boot partition. This took a few attempts as the tool didn't like exFAT files system that came on the SD card. Changing the file system to ext4, the tool was able to write the image to the SD card.  Finally some success. However I kinda find it interesting that they don't offer the SD firmware tool for Linux, only windows. The rtlinux image I used was the ITX-rk3588J-RTLINUX_Ubuntu20.04_Gnome_r211156_v1.0.6c_230306.

Following ryoka's write up, I deleted all but the "rootfs" partition on the SD card, and creating a new partition for the new boot drive, used ext4,but as stated it really doesn't matter. 

Using the link in ryoka's post, I downloaded the RebornOS image so as to use it to build the boot partition. I chose the build  dated prior to the write up post in the event that later builds might cause an issue and break The hack. the Image I used was the RebornOS-ARM-opi5-2023-01-28.img
I tried mounting the image directly, using losetup to create a loop device then mounting the boot partition. Unfortunately while I was able to create the loop device, my computer didn't recognize the file systems of the partitions so I couldn't mount the boot partition. So I then wrote the image to a USB drive using BalenaEtcher and was able to mount the partition now that the file system was recognized. using dd I copied the boot partition from the RebornOS image to the SD card into that first partition that I created.  copied over the Image, System, initrd files from the original ITX-rk3588j image. I also copied the lib folder over, although it gave me a couple errors telling me I couldn't copy some symbolic links for build and source. 
I copied the rk3588s-orangepi-5.dtb file that I downloaded from the balbes150's thread on the Armbian forum since it was suggested to use the dtb from armbian in the writeup. I noticed there was already a dtb file for the orange pi 5 in the dtbs/rockchip folder, I ran a diff command on the two dtb files and it returned saying they were different, so I renamed the one already in the rockchip folder and then copied the armbian one over.
edited the extlinux.conf file to match exactly what was posted making sure the kernel file names matched. I kept the "root=/dev/mmcblk0p6" as that matched what I had and since it seemed to work for ryoka, no since in changing it. 
I edited the fstab using the UUID values found when I ran blkid command. the RebornOS boot partition matched what was in the write up. however the rootfs partition had a different UUID than what was in the write. I don't think this mattered so long as the the fstab matched the partition values.
I checked to make sure the boot partition had the right flags using parted. For some reason I can't get GParted to install on my system and the KDE partition manager doesn't show the flags of a partition.  Parted showed that the boot partition had both boot, and esp so we should be good to go right? Well... remember I said one step forward and two steps back. Powering on the Orange Pi gave me a whole lot of nothing. Black screen. no flashing green LED to let you know it's thinking. Just the red power led and that's it nothing else.

So I am not sure what I did wrong. Am I using the wrong images? were there other steps that needed to be taken that I missed out on? I know the board function correctly as I did install the official Armbian image on the same SD card prior to attempting this process and it did boot up fine in Armbian. So I don't think there is any hardware issue. Is it possible that there is a build incompatibility between the boot partition and the root partition? 

Currently not sure what to try next. I tried rodw's approach but ran into too many errors and was not able to even set up the build environment.

any thoughts?


 

Just download this ready to use image with LinuxCNC already installed:

easyupload.io/qtgt4a

I think you're missing that the right u-boot/idbloader has to be written on the SD. When you want to be able to boot from an ext4 boot partition you'll need an idbloader that supports this, otherwise make it fat16 or ext2.
To write this u-boot to the SD, the first 16mb needs to be free, find an u-boot that supports opi5:

dd if=idbloader.img of=/dev/sdX conv=notrunc seek=64dd if=u-boot.itb of=/dev/sdX conv=notrunc seek=16384

That dtb from that thread is for Linux 6 with pancsf, for me it did not work on 5.10. If you want to be able to boot from USB you could write his loader to the SPI flash, it's in /usr/lib/linux-u-boot..../rkspi_loader.img and dd to mtdblock0.

In that folder you'll also find the idbloader and u-boot to write to the SD. To be honest I'm not sure if this is still necessary with that loader on SPI flash, but I think it does.

Connecting the UART and watch the serial monitor will help to see what's going wrong.

You are probably correct that I am missing the right boot loader. The I made sure that the boot partition was fat16 as that seemed to be the case for working installs. Plus I remember reading somewhere that booting off a ext4 was an issue and why it was a headache to try to get it to boot from a nvme SSD drive. Something I'd still like to do at some point, but a working build is enough for me at the moment.
I did make sure the first 16mb were free, as it seemed every image I looked at had the same.
I had saw you the image available earlier but the link was broken. I downloaded the new image I just don't have the time until later today to try it.

Cheers!

That link became broken indeed after I edited the message, the editor on this forum is broken, it changes things you won't. (The first word after the link connected with the link)
On my nvme I just have one ext4 partition covering the whole drive with the syslinux/extlinux bootloader in /boot. Perhaps when you've the right rkspiloader written to the SPI flash you won't need it on the SD card either, but didn't try that. I assume this is usually done to make it bootable without needing to write it to the SPI flash to make it easier to flash afterwards.
In extlinux.conf it normally should be sufficient to write the UUID (root=UUID=.... and it will find that drive, but somehow it didn't. When it boots you into the syslinux command line you probably need to change the root=/dev/... in extlinux.conf. You could find the right location with "ls /dev" this could be different in Armbian vs syslinux.
In the UART console you'll see what's going on in the idbloader.

A mistake I made before was forgetting to add /boot/ to the locations of the kernel and initrd in extlinux.conf when I had the bootloader on the same partition as the root partition. When you don't see the UART console it's harder to find the issue.

But with writing the image I'd uploaded to a SD you should be ready to go. When you want to copy it to a nvme, an easy way to do this without having an extra bootloader on it, is to create 2 partitions exact the same size as on the image and dd the 2 partitions you need (boot and root). Then edit in extlinux.conf the root to /dev/nvme...p2. You could make these partitions easy with the gnome-disk-utility and set the size in bytes. But as you could see there are different ways to do this when you know which files are needed to edit.
Have fun with it, cheers!

I was able to boot up the image you provided last night and everything seems to be working so far. Looking forward to hooking up my Mesa board and start running some tests.
Thanks Royka, you've been extremely helpful!

Cheers!