Raspberry Pi 4

silden wrote: Hi all,
We're currently testing linuxcnc 2.8 on our raspberry pi 4 and an mesa 7c81.
It looks promising but we wanted to determine the real load on the system.
We found a post by PCW which stated that MESA Ethernet cards work optimally when servo-thread.tmax is well below 50% of motion.servo.last-period.
During checking that we found that motion.servo.last-period is always almost equal to [EMCMOT]SERVO_PERIOD rather than the actual number of CPU cycles which should be around 2 million.
This odd since the documentation states that it should be in CPU cycles and our Raspberry Pi is overclocked to 2GHz, as well as our current PC is showing the expected CPU cycles for a 1 millisecond thread.

Is this a known issue on the raspberry pi or did we do something wrong in the configuration of the pi?
Thank you in advance for any help on this issue.

RPI times are in nanoseconds _not_ CPU clocks (at least they are on the RPI3)

Only 3 bytes diff in size. Swapped it in and debuild is running.

Hi Bertho;

Some questions re the newer driver.

The man page hasn't yet mentioned the rpi4.

What the man page recommends to disable the ondemand governor can't be applied directly, even with a sudo its response is no "permission"

And its currently set to 600 megahertz and ondemand.. I'll try putting it in rc.local and rebooting the rpi4.

But before rebooting, in case the governor stuff in rc.local backfires, an spi_debug=3
in the loadrt line elicits this:

hm2: loading Mesa HostMot2 driver version 0.15
hm2_rpspi: Platform: Raspberry Pi 4 Model B Rev 1.1
hm2_rpspi: Base address 0xfe000000 size 0x01800000
hm2_rpspi: Mapped peripherals from 0xfe000000 (size 0x01800000) to gpio:0x0xb47a1000, spi:0x0xb47a5000, aux:0x0xb47b6000
hm2_rpspi: SPI0/CE0 clock rate: 41666000/25000000 Hz, VPU clock rate: 550000000 Hz
hm2_rpspi: SPI0/CE0 write clock rate calculated: 39285714 Hz (clkdiv=14)
hm2_rpspi: SPI0/CE0 read clock rate calculated: 25000000 Hz (clkdiv=22)
hm2_rpspi: SPI0/CE0 Valid cookie matched
hm2_rpspi: SPI0/CE0 Base: hm2_7i90.0

So ATM it seems to be respecting the loadrt command line.
Now I'll reboot it to see if that fixes the governor nonsense.

It did not:
pi@rpi4:~ $ sudo cat /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq
600000
pi@rpi4:~ $ sudo cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
ondemand

Next? I should add it seems to be running well. The governor was not changed when linuxcnc was running and enabled for several minutes. I should probably do a remake of the kernel after disabling the ondemand. I thought I did that once, but I'll double check when next I have both eyes open.

Thanks for any insight, but I fear this is not a lot of help for the other 2 cards as I don't have them, just the original 7i90HD, with Jon Elson's terminator card and about a 1" cable.

Thanks a bunch, Bertho.

Hi everybody !

I just tried with a RPI3 and it's not working too on SPI1 at every speed (from 5Mz to 50Mhz). It works great on RPI3 SPI0 at 50mhz so I don't think it's coming from my FPGA dev board with a custom Hostmot2 firmware.
I don't know how to compile and remplace a new rpspi driver. maybe i should create a restauration point just before linuxcnc compilation to easily compile linuxcnc with a new hm2_rpspi firmware.


RPSPI can be moded to be used with a STM32 via SPI ? it could be a nice and cheap fast I/O expander.
Is it possible to communicate with the STM32 directly with the FPGA ? Via SPI ? UART ?
Edit : i found a good start here : github.com/rene-dev/stmio
Edit 2 : i added this to my FPGA firmware : but still looking to add BSPI to test

unforch, I have no experience with the STM32 so I'm not going to be of any help. Sorry.

Hi Gene,

You need to check if the kernel has the governor compiled in. You can do:
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors

That should give you a list of available governors. If "performance" is not there, the it needs to be compiled in. If it is there, then it should simply work.

For the RPi4 you will need to check the max frequency as configured in the system (probably different from the RPi3). You can do so using:
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

Then you can force the same frequency to be the minimum. Actually, you could simply do:
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq

Note, if you use sudo, the redirections must be part of the executed command and you need something like:
$ sudo sh -c "cat /sys/... > /sys/devices/system/....."
$ sudo sh -c "echo blabla > ...."
Otherwise, your targeted redirect-file is opened using the normal user id, which probably fails. The target file needs to be opened as root.

Edit: You may also need to check if the governor and scaling is applied to all cores (like it is on the SoC for the RPi3). My guess is that it is, but you should verify this because the RPi4 is a newer BCM SoC.