Raspberry Pi 4

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.

Hi team, I followed JT's guide on RPi4 build on his uspace site and it completed without fuss albeit the poor wee cpu gets pretty hot during the building compilking activity.

And I have a basic gpio based hal file using the following.....

loadrt hal_pi_gpio dir=78855 exclude=32918520

# beware gpio 21 and 22 are still reversed, they control rpins 15&50 and are backwards almost everywhere in rpi docs
# easy to see and check with 'show pins hal_pi_gpio*

# tjp chg to 3 step dir types,plan on using gekco G540
# was loadrt stepgen step_type=5 ctrl_type=v
# make posn loop type
loadrt stepgen step_type=0,0,0

#net estop-out => parport.0.pin-01-out
net estop-out <= iocontrol.0.user-enable-out
net estop-out => iocontrol.0.emc-enable-in


# --- begin addf s
addf hal_pi_gpio.read base-thread
addf stepgen.make-pulses base-thread
addf stepgen.capture-position servo-thread
addf motion-command-handler servo-thread
addf motion-controller servo-thread
addf stepgen.update-freq servo-thread
addf hal_pi_gpio.write base-thread
# --- end addf s


# i use GPIO 2,3,4 for xtep ystep zstep, thats rpin 3,5,7 resp
net xstep stepgen.0.step => hal_pi_gpio.pin-03-out
net ystep stepgen.1.step => hal_pi_gpio.pin-05-out
net zstep stepgen.2.step => hal_pi_gpio.pin-07-out

# i use GPIO 14,15,18 for xdir ydir zdir, thats rpin
net xdir stepgen.0.dir => hal_pi_gpio.pin-08-out
net ydir stepgen.1.dir => hal_pi_gpio.pin-10-out
net zdir stepgen.2.dir => hal_pi_gpio.pin-12-out

I am trying to scope the pins with my oscilloscope and i am seeing no action.

my goal is to evaluate this against my current mach3 system and see how they compare

any thoughts much appreciated. Thanks to the team who are behind this amazxing project.

cheers
Richard

I'd recommend that a common kernel config and version should be used for preempt_rt on the Rpi's and the governor and scaling should also be at some consistent setting. Most users won't see the big picture and not understand why their system doesn't work properly unless the have an exact script to follow. Even then we have seen that most issues with building RTAI, preempt_rt and Linuxcnc are due to mistakes made with the tool chain or setting up the compile.

One of the first things to do with the Rpi4 before even installing any software is getting a proper case with heatsinks and/or cooling fans. The Rpi4 is not a complete single board computer unless its core speed is set very low since it requires a heatsink similar to most x86 PC's to run anywhere close to its top core speed. x86 CPU's used to come with the warning that a heatsink is required for operation. The Rpi4 should come with the same warning/recommendation.

@ gtt38

m.aliexpress.com/item/4000141655235.html is the link to the FPGA board that worked for me.

I didn't see any protection for all the IO's on that board. It gets you lots of gates and unprotected IO, so you'll still need another board to get the IO's out to the real world in a machine environment.

Not to hijack this thread but if anyone is interested I've been testing a 64-bit Gentoo image for the Raspberry Pi 4 :
github.com/sakaki-/gentoo-on-rpi-64bit

After I finish building my crosstools on x86 for this I'll likely have a link to working preempt_rt kernels for LCNC and a u-boot image once that gets stable. In case anyone else wants to stay away from Debian/Raspbian.

The best way is to only enable the performance governor.
But you also can set force_turbo=1 under [PI4] in the boot/config.txt. this will force the turbo clock at all times. doesn’t matter what governor is set.