Raspberry Pi 4

With the RT kernel I used on my RPI3 (from RMU on IRC) : 4.9.65 something
WIFI works fine, so well i never even used the Ethernet

( no idea about bluetooth )

Preempt RT works fine here, also every driver and hardware.

Follow this guide www.raspberrypi.org/documentation/linux/kernel/building.md
I started with github.com/raspberrypi/linux version rpi-4.19-y.
Applied the RT-patches from kernel.org or wherever they are, don't remember right now, the official ones. Couldn't find an exact match on RT-patch version and rpi-4.19-y version, so I took the RT patch that was closest and older. It patched OK, a few patches had line offsets which is kind of expected, but it all patched fine.

Then did something like "make bcm2711_defconfig".
Then "make menuconfig" and tick the preempt rt option.
Then build the kernel according the guide including the copying of dts-es whatever that is.

Changed /boot/cmdline.txt to use the new kernel. I can say based on experience that it is good to keep the original kernel around. If things fail, put the sdcard in the normal linux box and edit cmdline to point to the old kernel.

I have come a bit further. I am able to debug rtapi_app, there was a line in the code that told me how to, and it worked. At this point I suspect my ini/hal files. I was using 2.7.something on this lathe. It was all upgraded to 2.9 and I think there is something wrong with the axes and joints. Just my guess based on the error.

Definitely translation 2.7 -> 2.9.
Instead of jogging in Z, I tried to jog in X. Yes, steps are taken! (It works in X!)

Can someone be so kind to check the ini file and the hal file after the translation.
This is a very simple lathe with X and Z axis.
I think the error message I get now is a bit rough. Or it is probably all my fault

No, that is a bug in gmoccapy. Something with Z not being the second or third axis I guess.
Not RPI-specific, same problem is in the Intel PC.
Tested in axis, there it works.

So it works.

I'll see if a can do some real turning on the coming days.

A picture of the very professional installation

The hm2_rpspi might work, but be aware that it has numerous internal checks to assure its running on a genuine pi3. So there may be a need for some code TLC to both remove the pi3 checks, and likely add a compile switch to make it use the gpio headers for the rp4 version since its a different chip-set. Building 2 copies might be best. An rpspi.ko like now and an rpspi4.ko.

2 Questions though. Does the 40 pin header connector connect directly to the pi, or will we need a short 40 pin jumper cable? And the spi terms currently used for the 7i90 are where? I gave the docs a glance, looks pretty good.

Thanks Peter.
Cheers, Gene

>Andy said; I would prefer to go a different route, one GPIO component for all SoC ARM >boards.

I have no argument against that, but having tried to cut the rock64's headers into that code, theres an apparent diff in syntax between the headers used in the pi3 version, and the headers used in the rock64. And that diff got me lost, fast. Both are broadcom stuff, so I would have assumed more similarity

Cheers, Gene

I was going to some real turning with RPi4 and mesa 7i76e. But...
It runs the axis fine, controls the spindle and all that. It does work.
Also feels pretty responsive with the 1920x1080 touch screen. Not bad.
But I use andypugh's LatheMacro a lot, I would say I am dependent on it
for manual work. But there are missing python modules used, and wheb
trying to find them, they seem to be old and depreceated. Python-rsvg
Is the one that stopped my, but I think there are more along the line,
there is a message that No Xlib module.
Is gladevcp not going to work in buster? What are the thoughts here?

Hakan wrote:

But there are missing python modules used, and wheb
trying to find them, they seem to be old and depreceated. Python-rsvg
Is the one that stopped my, but I think there are more along the line,
there is a message that No Xlib module.
Is gladevcp not going to work in buster? What are the thoughts here?

I think you can pull them from older distributions, but ya in general python 2 libraries which linxcnc uses extensively is depreciated

Chris M