I'm wondering if anyone has had any luck using spi-gpio to bitbang SPI on the H5...  @martinayotte, I found a forum thread from a few years ago where you seemed to be looking at this area - perhaps you have an idea?

 

Doing a typical spi-gpio DT overlay for this properly loads the spi-gpio and spi-bitbang drivers, creates /dev/spidev0.0, and allocates the gpios (verified via gpiod)...but the first problem I see is that the CS line is simply not working (cs-gpios below)...?

/dts-v1/;
/plugin/;

/ {
        fragment@0 {
                target-path = "/";
                __overlay__ {
                        spi {
                                compatible = "spi-gpio";
                                #address-cells = <1>;
                                #size-cells = <0>;
                                ranges;
                                mosi-gpios = <&pio 0 64 0>;     /* PC0 */
                                miso-gpios = <&pio 0 65 0>;     /* PC1 */
                                sck-gpios = <&pio 0 66 0>;      /* PC2 */
                                cs-gpios = <&pio 0 67 1>;       /* PC3 */
                                num-chipselects = <1>;
                                status = "ok";

                                spidev {
                                        compatible = "spidev";
                                        reg = <0>;
                                        spi-max-frequency = <500000>;
                                };
                        };
                };
        };
};

I'm testing this on a NEO2 using dev kernel 5.3.8, and in this case I am re-using the same standard SPI lines for the HW SPI - this way I can switch between the two easily for testing.  Standard HW SPI works great, of course, but the spi-gpio version doesn't.  (I tested on other GPIO lines as well and the result is the same.)

 

I hooked the CS, CLK, MOSI, and MISO lines to my scope, and did a test write spi_test through /dev/spidev0.0, and it appears that CLK is properly working, as is the test data transferred via MOSI (at least I'm seeing data bits coming across).  But CS simply seems to not be working - I can't trigger properly on it (either high or low).  Right off, measuring it shows it as low, when by default it should be high...

 

I am not an expert by any means in this area, so any help/pointers/advice/thoughts would be greatly appreciated!

 

Thanks!

 

11 hours ago, 5kft said:

I found a forum thread from a few years ago where you seemed to be looking at this area

I don't recall, but you can maybe provide such link ...

11 hours ago, 5kft said:

But CS simply seems to not be working

Did you tried to use another plain GPIO which is not part of HW SPI ?

1 hour ago, martinayotte said:

I don't recall, but you can maybe provide such link

 

Sure!  https://forum.armbian.com/topic/4330-spi-gpio-chip-select-support/ - mid-way in the thread you did some nice debugging into the kernel regarding the initialization of CS.  I think I need to do a similar thing to figure out why it simply isn't initializing/working...  Perhaps there is no relation, but without digging into spi-gpio yet I'm wondering why it wouldn't initialize correctly...??

 

"gpioinfo" shows the overlay initialization working in terms of GPIO allocation:

        line  63:      unnamed       unused   input  active-high
        line  64:      unnamed       "mosi"  output  active-high [used]
        line  65:      unnamed       "miso"   input  active-high [used]
        line  66:      unnamed        "sck"  output  active-high [used]
        line  67:      unnamed   "spi0 CS0"  output   active-low [used]
        line  68:      unnamed       unused   input  active-high

...but for example measuring line 67 (PC3) the line is low, when it should be high.  Very strange...!

 

1 hour ago, martinayotte said:

Did you tried to use another plain GPIO which is not part of HW SPI ?

 

Yes, my original test was using several other GPIOs (e.g., PG6/7 for CSN)...same effect.

29 minutes ago, 5kft said:

Sure!  https://forum.armbian.com/topic/4330-spi-gpio-chip-select-support/ - mid-way in the thread

Right ! But my debugging was for HW SPI ...

I've looked quickly at drivers/spi/spi-gpio.c, it seems to be normal code, but if you wish to debug further, you can add some debug prints to make sure the initialization code and toggling code is done properly.

OK, thanks!  As I figured, I need to dive in deeper.  I'm curious about changes like this, for example: https://lkml.org/lkml/2019/4/3/9...  Looks like I have another weekend project to do!