[LinuxCNC/linuxcnc PR#281] Significant update of the hostmot2 hm2_rpspi driver:

#1 – BsAtHome 于 2017-06-10

BTW, it should be trivial to add this to the 2.7 branch as well.

The tricky part for either branch would be the fallback SPI base frequency (400MHz). The actual value is 250MHz, which is read from the debugfs. It seems that not all kernels have or mount the debugfs on /sys/kernel/debug.

The user must set the spiclk_base parameter to the right value if the debugfs is not accessible or all comms will be at 62.5% of the requested speed.

#2 – jepler 于 2017-06-11

Is this tested on mesa 7i90 with standard firmware? I can’t test it right now, and as it is essentially a rewrite I can’t effectively review it (github doesn’t even want to show me the diff of the main .c file!). However, I would like to see the improvements listed here appear in a future linuxcnc version.

#3 – BsAtHome 于 2017-06-11

It has been tested and, afaik, on standard SPI firmware. Not by me personally, but two users. One is on the forum (thread https://forum.linuxcnc.org/24-hal-components/32874-compiling-a-driver?start=20) and the other is Gene’s saga, which started the rewrite.

The tests may be not very extensive, but the old version was definitely doing it wrong for the RPI3 and hence unusable. For example, it failed to set the correct SPI clock frequency due to asynchronous register access and the frequency would change at random between transfers.

The module itself is stable, but Gene’s Pi machine (or mine) is not stable using a realtime kernel. There are significant stability problems with RT preempt kernel on the raspberry pi (runs rock solid without the RT patches).

Maybe Peter Wallace from Mesa can give us a hand here? He has expressed interest in using it, partly because it enables him to fiddle with the firmware.

Github does not show large diffs by default. You need to find the file in the list and click the “Load diff” to show the diff view of this file. However, as you write, it is essentially a rewrite for most of it. I think that the includes, rtapi_main and some small support functions survived from the original. Otherwise, the structure remains the same, but the low-level spi-controller interaction is completely rewritten.

#4 – andypugh 于 2017-06-12

If, as stated, the existing driver simply doesn’t work, then it seems safe to assume that it doesn’t have many current users. Given that this re-write is HAL-layer compatible I think there is a reasonable argument for merging it to 2.7.

#5 – BsAtHome 于 2017-06-12

To be more precise, the old driver may or may not work. This mainly depends on the current state of the peripheral, core(s), caches and the software that is running. Both Pi2 and Pi3 have multiple cores, so they will both have problems and will present the problems rather randomly. Any bugs in the rewrite would at least be consistent and therefore easily fixed. Also, the rewritten driver presents the user with configurable parameter options to tune and debug. This configurability is severely lacking in the old driver.

I do not think there are many Pi users at the moment using this driver. As you say, there are problems with the current driver. Those experiencing them are probably reverting to the spidev driver. There are also rt-kernel issues on the Pi which still need to be resolved. In that sense, the Pi for linuxcnc should, as a whole, be considered a work-in-progress.

#6 – pkmcnc 于 2017-06-12

I used the current hm2_rpspi a few times with Pi 2 and 3, and it was pretty stable for a few hours (unless I connected stepper drives to 7i90 outputs).

I can’t say the kernel was unstable either, but I had a few settings tweaked (found on the net):

In /boot/config.txt

enable_uart=1
force_turbo=1 #Voids warranty!
temp_limit=75 #Will throttle to default clock speed if hit.
gpu_mem=128

In /boot/cmdline.txt

dwcotg.fiqfsm_enable=0
dwcotg.fiqenable=0
dwcotg.nakholdoff=0

I’m interested in the new driver. I can do some tests if you guide me.

#7 – BsAtHome 于 2017-06-12

I pushed a 2.7 port of the hm2rpspi driver into a local branch hm2rpspi-2.7-branch to my repo clone (https://github.com/BsAtHome/linuxcnc). The only change required was to replace the rtapi call rtapiopenas_root() to open(). I presume that the rtapi thread/app is still running as root at that time.

#8 – BsAtHome 于 2017-06-12

@pkmcnc Any help is appreciated! The current changes are build using a full source-tree build on the Pi3 (raspbian) with “./configure –with-realtime=uspace” and I run linuxcnc in-place. I have no cross-platform running and no deb packages are created by me.

Alternatively, if you are running the master branch (2.8~pre), then I can send you a binary module which simply goes into rtlib. That should do the trick quick-and-easy.

#9 – pkmcnc 于 2017-06-12

@BsAtHome I emailed you regarding the binary.

#10 – BsAtHome 于 2017-06-12

One small additional change has been pushed. The debugfs on older kernels is not as specific on which clocks are actually active (seen while testing 4.4.4-rt9-v7+). However, it does have the right value available because the SPI clock is derived from the core clock. And, the core clock is readable in the debugfs. The change will now try the VPU clock, then the core clock and use the fallback only if both fail. This change is both in this (hm2rpspi) branch and backported to the 2.7 (hm2rpspi-2.7-branch) branch.

#11 – jepler 于 2017-06-20

@BsAtHome thanks for your efforts with this driver. I’ve merged this, so please open new pull requests for further work! (the close will be noted by github soon)