Advanced Search

Thank you for trying to help, but the problem is that linuxcnc does not support 2.9.1 for raspberrys, so I could not fully install it, so I could not connect to the terminal or wifi. also, for friends who have problems connecting to the screen, I would like to state that the reason why it cannot connect to the screen is due to the use of hdmi micro hdmi converter.

Thanks for the feedback. I'm just feeling my way into this. I don't have a magic solution. I think we can agree that the new image still doesn't talk to the 7c81. I will start to follow the emc mailing lists.

thadwald wrote:

This image can be downloaded from here
drive.google.com/file/d/16kKamxMKPdYAeJp...KLf/view?usp=sharing
At first glance everything seems to work regularly and the lowest value that did not show the "Unexpected realtime delay" message was
latency-test 12000
Trying your image now. ... what username and pw does it take?

user: pi
pwd: raspberry

There's no need to "believe" that the 7c81 uses the SPI it does, unless you change the firmware for EPP and cook up a custom connector & use the hm2_7i90 driver to talk to the 7c81 over the parallel port.

github.com/jncronin/rpi-boot The last commit was in Feb 16 of 2022 I don't get why this is relevant.

www.abelectronics.co.uk/kb/article/2/spi...ux-on-a-raspberry-pi is well out of date

www.tomshardware.com/reviews/raspberry-pi-5 is just a run of the mill blurb on the RPi5, there is no mention of SPI.

github.com/raspberrypi/firmware/issues Has no issues related to the RPi5 & SPI

The resources you listed aren't really that helpful. The fact that the RP1 documentation isn't mentioned is absolutely astonishing. Next time could you you actually look through any resources you are given and sort out what is relevant and what is not. A few predate the release of the RPi5.

And as far as my research has led me, there is no "RP1" driver (although I havent played with the latest kernel), the SPI side is covered by the spi_bcm2835 driver. The hm2_spi driver uses this.

Another thing that is an issue in the hm2_rpspi driver is where it gathers the information for the clock, it's in a different location.

Actually I'm going to blow out of this part of the discussion. Good luck & all the best.

If you really want to get the attention of the devs your best course of action would to be raise an issue on github or via the emc mailing lists, the relevant information for those resources can be found on the Linuxcnc homepage.

rodw wrote:

I don't think there is a solution to install  qtpyvcp and probe-basic yet.
Hi Rod,

I've been looking around to see if someone's been able to install probe_basic on a rpi4 setup but haven't found anything. Do you know if this has been accomplished yet ?

Thanks !

Jay

P.S. I should mention we're trying to use the BTT SKR v1.4 Turbo.
 

I don't know that it's chip select.  That's educated speculation.  I believe it's true that the 7c81 requires a SPI connection.  I did some research last night by talking with google's "Bard".  This is what I got.  After the summary, I asked Bard where it found the information. The links to the projects are there.  (Sorry about the cut and paste formatting)

Bard" on RP5 SPI driver
Unfortunately, the Raspberry Pi 5 RP1 driver does not fully support SPI at this time. While basic SPI functionality is available, there are some limitations and missing features:Limitations:

• Limited clock speed: The RP1 driver currently only supports SPI clock speeds up to 10MHz. This is significantly lower than the Raspberry Pi 4 which can reach speeds of 50MHz.
  • Data size limitations: The RP1 driver only supports data transfers of 8 and 16 bits. Larger data sizes like 32-bit are not currently supported.
    • Limited DMA support: DMA transfers are not yet fully implemented for the RP1 driver, which can impact performance.
      
      Missing features:
      • Chip select (CS) support: The RP1 driver lacks proper support for chip select signals, which is crucial for controlling communication between the Raspberry Pi and multiple SPI devices.
        • SPI mode support: Not all SPI modes (e.g., CPOL/CPHA combinations) are currently implemented in the RP1 driver.
          • Interrupt support: Interrupt handling for SPI is not yet available in the RP1 driver.
            
            Current status:The RP1 driver is still under development, and the developers are actively working on adding full SPI support. However, there is no official timeline for when these limitations and missing features will be addressed.
          •  
  • Here are some specific references that I used to gather the information:
    • Official Raspberry Pi SPI documentation: pinout.xyz/pinout/spi
    • Raspberry Pi forum thread on SPI support:
    • ​​​​​​​ www.abelectronics.co.uk/kb/article/2/spi...ux-on-a-raspberry-pi
    • Technical blog post on Raspberry Pi 5 features: www.tomshardware.com/reviews/raspberry-pi-5
    • RP1 driver code repository on GitHub: github.com/jncronin/rpi-boot
      RP1 driver issue tracker on GitHub: github.com/raspberrypi/firmware/issues

Do you have a link to "The Rp1 peripherals project" ?

I 've gone thru the draft docs for the RP1 and couldn't find any reference to CS being missing. Nor could I have find any reference to the 2 M3 cores being user accessible, the docs show the memory for the RP1 cores being ROM.

As I said the CS seems to work as the hm2_spi (whic I mixed up with h2_7i90 which is the EPP driver) driver works fine within the context of a halrun session, but not within the context of a running config.

Thanks. I realized I was wrong about the memory right after posting. The RPi peripherals project (firmware for RP1) says that it's not complete, and CS is one of the things missing. I'm just guessing from my previous experience with SPI that missing CS could be important. If no one else gets to it first I'll get to building the whole thing. Gotta start somewhere.

chuckp47 wrote:

This image can be downloaded from here
drive.google.com/file/d/16kKamxMKPdYAeJp...KLf/view?usp=sharing
I installed this and it's quite nice.  Much like the default Pi release, everything came up normally.  The latency historgram looks good.  I'm trying to talk to a Mesa 7c81.  After I set it up for an XZ lathe I get this error report when launch.  The key part seems to be:

Note: Using POSIX realtime
hm2_rpspi: Can't map peripherals: Invalid argument
hm2_rpspi: cannot map peripheral memory.
hm2_rpspi: rtapi_app_main: Invalid argument (-22)
./my_LinuxCNC_machine.hal:9: waitpid failed /usr/bin/rtapi_app hm2_rpspi
./my_LinuxCNC_machine.hal:9: /usr/bin/rtapi_app exited without becoming ready
./my_LinuxCNC_machine.hal:9: insmod for hm2_rpspi failed, returned -1

One of you can probably point out how to correct the memory management.  Suggestions?  There are less errors on the rspi than in the past.  Maybe if I get the memory setup right it can load the rspi driver?
ulimit -l reports 1030416, much bigger than the 20480 noted in the build document.

 



OK it has nothing to do with ulimit.

If you look at the source and do some investigation you find to begin with the driver is detecting the board as a RPi3. Therefore the driver is trying to use a memory location that is completely wrong. I raised this issue on github, along with a few experiments I've made but as of yet no replies other than my own have been made. The hm2_rpspi driver takes over from the kernel driver for spi, in fact it unloads the spi_bcm2835 driver.

If you really want to investigate further the first thing you'll need to do is setup all the required dependencies to build Linuxcnc from source.

I dont know where you got the info regarding the chip select line from. The hm2_spi driver will communicate via SPI when using halrun, unfortunately when being used in a config the driver is not fast enough. This is due to the fact that this driver uses the linux kernel SPI driver, and this is actually noted in the man page for that driver.

The GPIO interface has changed to such a degree, the RPi5 will not work with many of the utils & libraries that access the GPIO on the RPi4.

And yes I do have access to boards that run both 7i90 & 7c81 firmware that run fine on a RP-400.

[/quote]
[/quote]

thadwald wrote:

rodw post=287637 userid=20660I did a bit of reading. can you guys try adding this at the beginning of cmdline.txt?

video=HDMI-A-1:1920x1080M@60D 

I also noticed that the RT patch 6.1,66 has been released and the 6.1.66 kernel was merged into the 6.1.y branch yesterday so it would be a good time to build another image.
 
There was no cmdline.txt. Creating one with this line didn't change anything.

cmdline.txt is in a subfolder of /boot

I used the OS customization in the rpi-img program to set them to my own and it worked. It also connected right up to WiFi.

So what's the password on that image? I can't seem to find it posted anywhere. cnc didn't work for me.

Reading the errors again, these are all about rspi. That's the same as I had in Rod's image.
I suspect that the SPI driver is still not capable of what is expected here. Some research into the SPI situation showed me that there are features like chip select support that are not yet available in the RPi 5 (RP1 chip) driver package. This will be something more to look into, both in the how LinuxCNC is using SPI and what the SPI firmware driver for the RP1 chip is doing.

This image can be downloaded from here
drive.google.com/file/d/16kKamxMKPdYAeJp...KLf/view?usp=sharing

I installed this and it's quite nice.  Much like the default Pi release, everything came up normally.  The latency historgram looks good.  I'm trying to talk to a Mesa 7c81.  After I set it up for an XZ lathe I get this error report when launch.  The key part seems to be:

Note: Using POSIX realtime
hm2_rpspi: Can't map peripherals: Invalid argument
hm2_rpspi: cannot map peripheral memory.
hm2_rpspi: rtapi_app_main: Invalid argument (-22)
./my_LinuxCNC_machine.hal:9: waitpid failed /usr/bin/rtapi_app hm2_rpspi
./my_LinuxCNC_machine.hal:9: /usr/bin/rtapi_app exited without becoming ready
./my_LinuxCNC_machine.hal:9: insmod for hm2_rpspi failed, returned -1

One of you can probably point out how to correct the memory management.  Suggestions?  There are less errors on the rspi than in the past.  Maybe if I get the memory setup right it can load the rspi driver?
ulimit -l reports 1030416, much bigger than the 20480 noted in the build document.

 

Sorry, I was quoting  a source, the file name and location (to a subfolder) may have changed