Mesa 7i90 in SPI mode

.

.

Hello Tinkerer,

The LinuxCNC txt output files look normal. There are no error messages to report. If there were I would post them. The only thing one sees is "invalid cookie." And I laid the responsibility for things not working squarely on my shoulders not on your code.

My needs are different than yours. You are running headless with a remote UI. I want something which is standalone, using the RPi3 only with no need for networking. I needed mesaflash functioning in order to evaluate a custom .bit file. You are using one provided in the Mesa archive. You build using qemu. I build natively. We have different goals.

The hm2_rpspi implementation is a memory-mapped polled solution, similar to the spi-bcm2835.c polled methodology. I re-enabled the debug output in the hm2_rpspi module and confirmed no data bytes (other than the first four {0xAA, 0xAA, 0xAA, 0xAA} response) are returned. Nothing but zeroes. I changed the transfer speed (slowed things down from 32MHz to 16MHz) and tried changing the read sequencing. Success on this continues to elude me.

If you have a recipe starting with a brand new RPi3 fresh out of the box, NOOBS or new Pixel install and ending with a functioning LinuxCNC with Axis UI running on the RPi3 please share. The perspective that "information is a debt to be collected" is not one I share.

All the best, Joe

.

guys, there is no need for animosity.

im using rpi3's with 7i90's to power a few 3d printers, im happy to help in any way i can. though i must admit i run all the machines in headless mode so ymmv.

i didnt need to modify the hm2_rpspi driver in any way except to backport it to 2.7.7.
im using archlinuxarm with kernel 4.4.23-1-rt31-ARCH #1 SMP PREEMPT RT

my /boot/config.txt is
for testing i loaded a bitfile using 7i90spi_justio_72 configuration.
joe, thank you for your work on updating mesaflash, prior to this i was having to pull out a jtag cable every time i needed to update the bitfile. im happy to test your patches if you point me to source, is this the only change?

im also happy to share the archlinuxarm packages i built on top of the base distribution, and/or my bitfiles if youd like to try using a setup like mine

.

all i did was to take the base package from arch linux arm
github.com/archlinuxarm/PKGBUILDs/blob/m...raspberrypi/PKGBUILD

and add the rt patches from www.kernel.org/pub/linux/kernel/projects/rt/4.4/ while disabling the aufs patches (they conflict with rt)

my kernel is a bit outdated (the downside of arch linux rolling release). but it works and im hesitant to mess with it for a while.
github.com/sleepybishop/linuxcnc/tree/ch...linux-rt-raspberrypi

.

Sleepybishop, I am happy to hear the hm2_rpspi is working for you. I had not considered the possible device tree issue. Thank you for pointing out the dtparam setting.

I am building CNC routers and was using BBB. The capes I used are no longer available so switching to Mesa solutions.

And I am glad you found the mesaflash update useful. You're welcome. Yes, the one hm2_spi.c change is all that is needed. This works with the RPi spidev driver. And you will need to specify the spidev_path argument to use the desired device (/dev/spidev0.0 on my Pi). A "heads up!" on something I saw - some SPI transfer timeout messages when using "Show HAL Configuration". Please let me know if you experience anything similar.

This hm2_spi.c change is also applicable to other boards. I plan to use this on the Pine64 in the near future. It's SPI driver (spi-sunxi.c) also limits its bpw value to 8.

Oh, just so there is no misunderstanding, I believe information and knowledge are treasures meant to be shared far and wide.

Have a great week! Joe

.