Mesa 7i90 in SPI mode

Without fully refreshing my memory, the 7i90 will echo AAAAAAAA for the first dummy data under some condition. The comment implies it has to do with the /CS signal but the source says so the comment is just saying that that whatever the specific condition was, I couldn't figure out a way to use it for a basic "is device connected" test in the hm2_spi driver.

The AAAAAAAA is transmitted when there has been a frame timeout (SPI master idle for more than 50 usec) so can be used for detecting the card as long as you guarantee 50 usec of idle time before checking

The SPI "data in" looks bogus in your scope plot, you would expect the first doubleword of a burst
to have a 0xA or 0xB (read or write) command, but it does not (32/64 bit issue?)

OK, it looks like a problem with 32bit block write on ODROID-C1 SPI interface.
What is correct frame which should be send to the 7i90 board to get correct cookie response ? eg. {0x55aacafe, 0x54534f48, 0x32544f4d}

I do not know how could be possible to make trouble to odroid to realize 32bit transfers. Because according my understanding of hm2_spi.c driver github.com/LinuxCNC/linuxcnc/blob/master...stmot2/hm2_spi.c#L92
The data are sent per bytes.

I think ODROID-C1 is 32-bit so it's probably not a 64/32 issue (the recent -C2 is 64-bit if I'm not mistaken). armhf is same endian as x86, so it shouldn't be an endian issue, and if it was it should have turned up on my U3 (though in general hostmot2 is riddled with lack of attention to endianness and probably only works properly on little-endian systems)

We make the following settings via ioctl, checking the result for an error at each step:
spidev_set_mode(0) sets SPI_MODE_0, aka SPI_CPHA=0, SPI_CPOL=0.

To just read the cookie you would send:
0x0100A010 0x00000000 ( read one doubleword starting at 0x0100 hex )
To read the cookie and the hostmot2 name you would send:
0x0100A830 0x00000000 0x00000000 0x00000000 (read 3 doublewords starting at 0x0100 with autoinc)

it should be possible to tell linux the transfer mode is 8-bit but always send a multiple of 4 bytes. As long as linux keeps /CS asserted the whole transfer, I don't think the slave really can tell the difference. I'm not sure what all changes would be needed (how does this affect the order of the bytes in memory vs order of bits on the wire), but I'll be happy to review any proposed change and test it on my U3. If 32-bit transfers really are unsupported, it's a pity that the ioctl() to set the 32-bit transfer width doesn't fail!