What is workflow for debugging spi driver problem?

[jimw]

Glad to say creating virtual machine and getting Armbian build environment and running ./compile.sh was easy and successful for bananapim1plus / 6.1 kernel / jammy.  Created SD card and booted and is running fine.  Added DT overlay to enable spidev and got /dev/spidev0.0 as expected.  Got new version of cross compiler to build code I formerly ran on fedora image and the SPI driver behaves differently.  It pulses CS low for every transfer instead of optionally staying low for multiple transfers based on "cs_change" field in each transfer message.  Found kernel source in build/cache/sources/linux-kernel-worktree/6.1__sunxi__armhf/drivers/spi, and tried editing there to begin debugging (even tried git commit there), and each time I re-run ./compile.sh, my changes are blown-away.  Looking to understand what the standard workflow is for this?  Do I have to use user patches?  Do I have to build the kernel somewhere else and inject it into the img somewhere?  Any suggestions welcome.  THANK YOU.

[going]

13 часов назад, jimw сказал:

build/cache/sources/linux-kernel-worktree/6.1__sunxi__armhf

Check the git status in this repository if this folder is under git control.

Add all the files and commit. Assign a tag to it.
Step by step make your changes and commit git for each step.

Extract all your commits in one move:

mkdir userpatches/patch/kernel/sunxi-6.1/patches.spi
KERNEL="cache/sources/linux-kernel-worktree/6.1__sunxi__armhf"

./tools/mk_format_patch $KERNEL Tag..HEAD userpatches/patch/kernel/sunxi-6.1/patches.spi

I do not know how patches are applied today in the current version of the build system.

But they will be applied every time the build system starts assembling the kernel.
The order of assembly is determined by a single file: patch/kernel/archive/sunxi-6.1/series.conf

Just add them to this place and write them in this file.

[going]

14 часов назад, jimw сказал:

Got new version of cross compiler to build code I formerly ran on fedora image and the SPI driver behaves differently.  It pulses CS low for every transfer instead of optionally staying low for multiple transfers based on "cs_change" field in each transfer message.

Please show the link in the code:

drivers/spi/spi-sun6i.c

which deadlines do you think are working incorrectly.

And please check the dtb on the working board.
It may need to be fixed.

[jimw]

Thank you sincerely.  It will take me a little time to digest and try this.  Right now, I have just built the kernel on the Banana Pi (15 hours to build) and am able to boot.  Not quite there yet, since I lost /dev/spidev0.0.  If I can get that back, then I believe I have a debugging environment and can discover the changes I will need for the steps you mentioned.  Again, Thank You.

[going]

28.08.2023 в 22:08, jimw сказал:

(15 hours to build)

😢! What is the banana version? bananapim1plus - A20 SOC.

The native reassembly of the kernel turns into eternity.

 

28.08.2023 в 22:08, jimw сказал:

Not quite there yet, since I lost /dev/spidev0.0.

Check the configuration:

grep -nr CONFIG_SPI_SPIDEV /boot/conf*

 

27.08.2023 в 19:05, jimw сказал:

It pulses CS low for every transfer instead of optionally staying low for multiple transfers based on "cs_change" field in each transfer message.

Maybe some details from you?
What is connected via SPI?

[jimw]

Thanks; I appreciate your questions.  The CONFIG_SPI_SPIDEV was "m" and it didn't work, so I tried recompiling with "y" and that didn't work either.  "m" at least booted.  I couldn't get "y" to boot (am trying this again).   In armbianEnv.txt, I have:

 

fdtfile=sun7i-a20-bananapi-m1-plus.dtb

overlay_prefix=sun7i_a20

overlays=spi-spidev

param_spidev_spi_bus=0

param_spidev_spi_cs=0

param_spidev_max_freq=25000000

 

But no /dev/spidev0.0 available after boot.  As described below, I have two SPI devices attached, so I really need /dev/spidev0.0 and /dev/spidev0.1.  But to test, I at least need /dev/spidev0.0 (worst case, I can manipulate CS pins myself, though I'd rather not).

 

The SPI pins on the Banana PI Header, include CLK, MOSI, and MISO, as well as two CS pins.  The two CS pins are connected to two devices on custom hardware.  One is a chunk of flash memory that holds the firmware for an FPGA.  Upon reset, the FPGA is filled with this contents.  The other is the FPGA itself, which implements a custom protocol consisting of a 32-bit value that describes the type of the transaction followed by optional data that goes along with it.  Things like reading and writing bytes or quantities of 32-bit values from designated registers or auto-incrementing registers.  There is a base set of global registers and separate common registers addressed to multiple "slices" of the same logic that can be accessed individually or with simultaneous broadcast capability to all slices, which minimizes the number of SPI transactions.  A typical global register transaction would be:

 

1. lower CS

2. send one U32 indicating something like: Writing 16 U32 values to address 0x22

3. send the 16 U32 Values

4. raise CS

 

Using SPIDEV, this is accomplished by stacking up two SPI driver messages and sending them down using ioctl() calls.  The first one sets "cs_change=0" so the CS wont change between #2 and #3 above.  That's what's not working.   Instead, the CS toggles and the FPGA starts a whole new protocol session when CS goes low and then high again, so it fails.

 

P.S. 15 hours was long, but I was impressed that it actually did work!

 

[going]

15 часов назад, jimw сказал:

The CONFIG_SPI_SPIDEV was "m"

It is ok.

 

15 часов назад, jimw сказал:

overlay_prefix=sun7i_a20

overlays=spi-spidev

This entry says that an overlay will be accepted: sun7i-a20-spi-spidev.dtbo /_/-/ Replace the underscore with a dash

Let's look at the source file:

Скрытый текст

/dts-v1/;
/plugin/;

/ {
	compatible = "allwinner,sun7i-a20";

	fragment@0 {
		target-path = "/aliases";
		__overlay__ {
			spi0 = "/soc@1c00000/spi@1c05000";
			spi1 = "/soc@1c00000/spi@1c06000";
			spi2 = "/soc@1c00000/spi@1c17000";
		};
	};

	fragment@1 {
		target = <&spi0>;
		__overlay__ {
			#address-cells = <1>;
			#size-cells = <0>;
			spidev@0 {
				compatible = "armbian,spi-dev";
				status = "disabled";
				reg = <0>;
				spi-max-frequency = <1000000>;
			};
		};
	};

	fragment@2 {
		target = <&spi1>;
		__overlay__ {
			#address-cells = <1>;
			#size-cells = <0>;
			spidev@0 {
				compatible = "armbian,spi-dev";
				status = "disabled";
				reg = <0>;
				spi-max-frequency = <1000000>;
			};
		};
	};

	fragment@3 {
		target = <&spi2>;
		__overlay__ {
			#address-cells = <1>;
			#size-cells = <0>;
			spidev@0 {
				compatible = "armbian,spi-dev";
				status = "disabled";
				reg = <0>;
				spi-max-frequency = <1000000>;
			};
		};
	};
};

 

compatible = "armbian,spi-dev"; - This line will cause the spidev module to load into the kernel.

But the /dev/spidev0.X interface will not be present because it is not enabled (status = "disabled").

 

It is necessary to register more overlays to include the necessary nodes spi0, spi1 or spi2.

The source text of the file "sun7i-a20-spi0.dts":

Скрытый текст

/dts-v1/;
/plugin/;

/ {
	compatible = "allwinner,sun7i-a20";

	fragment@0 {
		target-path = "/aliases";
		__overlay__ {
			spi0 = "/soc@1c00000/spi@1c05000";
		};
	};

	fragment@1 {
		target = <&spi0>;
		__overlay__ {
			status = "okay";
			pinctrl-names = "default", "default";
			pinctrl-0 = <&spi0_pi_pins>;
			pinctrl-1 = <&spi0_cs0_pi_pin>;
		};
	};
};

 

 

To include spi1 and spi2, the lines must be:

...
fdtfile=sun7i-a20-bananapi-m1-plus.dtb
overlay_prefix=sun7i-a20
overlays=spi-spidev spi1 spi2
...

In this case, three nodes will be added for control via the spidev driver and only two will be enabled.

This can be bad if, for example, spi0 is planned to be used in some other way and another driver must be connected.

You will have to rewrite the overlay yourself for a specific task and compile it.

 

You can find all the source texts of the overlays in the kernel folder after all the patches have been applied before compiling.

build/cache/sources/linux-kernel-worktree/6.1__sunxi__armhf/arch/arm/boot/dts/overlay/*

[jimw]

Thanks for the instruction.  I'll try this right away.

[jimw]

No luck yet.  I got the dts source files from the build worktree folder and compiled them.  I tried

 

   overlays=spi-spidev spi1 spi2

 

and didn't get any /dev/sp* files to access.

 

I also tried

 

   overlays=spi-spidev spi0

 

since it looked to me that spi# overlay dealt with individual SPI controllers accessing different bus pins, and according to the README file in the overlay directory, only the spi0 overlay was connected to the specific pins connected to the banana pi 40-pin header.

 

But this didn't work.  I also tried:

 

   overlays=spi-spidev spi0 spi-add-cs1

 

but, not surprisingly, this didn't work either.  

 

I noticed while booting, all the dtbo's were found and loaded without error, and afterwards, sun7i-a20-fixup.scr was executed.  This would have been the original file as I didn't copy that from the build directory.  Not sure if I should have copied that as well?

 

I see in the source sun7i-a20-spi-spidev.dts, where spi0 is disabled:

 

 

Thought I might try setting this to "okay" and compiling it and copying it to the dtb/overlay folder.  Any thoughts on that idea?

 

 

 

 

 

 

 

 

[going]

18 минут назад, jimw сказал:

Thought I might try setting this to "okay" and compiling it and copying it to the dtb/overlay folder.  Any thoughts on that idea?

That's exactly what you need to do and combine both overlays: sun7i-a20-spi0-spidev.dts

Скрытый текст

/dts-v1/;
/plugin/;

/ {
	compatible = "allwinner,sun7i-a20";

	fragment@0 {
		target-path = "/aliases";
		__overlay__ {
			spi0 = "/soc@1c00000/spi@1c05000";
		};
	};

	fragment@1 {
		target = <&spi0>;
		__overlay__ {
			#address-cells = <1>;
			#size-cells = <0>;
			spidev@0 {
				compatible = "armbian,spi-dev";
				status = "okay";
				pinctrl-names = "default", "default";
				pinctrl-0 = <&spi0_pi_pins>;
				pinctrl-1 = <&spi0_cs0_pi_pin>;
				reg = <0>;
				spi-max-frequency = <1000000>;
			};
		};
	};

	fragment@2 {
		target = <&pio>;
		__overlay__ {
			spi0_pi_pins: spi0-pi-pins {
				pins = "PI11", "PI12", "PI13";
				function = "spi0";
			};

			spi0_cs0_pi_pin: spi0-cs0-pi-pin {
				pins = "PI10";
				function = "spi0";
			};

			spi0_cs1_pi_pin: spi0-cs1-pi-pin {
				pins = "PI14";
				function = "spi0";
			};
		};
	};
};

 

fragment2 is taken from the sun7i-a20.dtsi

[jimw]

Help me understand, "combine both overlays".  Are you saying to create a new overlay called sun-7i-a20-spi0-spidev.dts?  Do I literally concatenate the existing sun7i-a20-spi-spidev.dts and sun7i-a20-spi0.dts files, and change the status to "okay" for the fragment@1 from the sun7i-a20-spi-spidev.dts portion?  Or are their sections from both files I should include in the new file, and are these sections needed to be in specific places in the hierarchy structure?  I somewhat understand the purpose of the files, but I don't understand all the syntax and hierarchy and linkages they represent.  Thanks.

 

[jimw]

Oh, duh.  I see you already did the combining and I hadn't clicked on the "reveal hidden contents" button.  NVM.

[jimw]

I created the .dtbo and used the following in armbianEnv.txt ..

 

fdtfile=sun7i-a20-bananapi-m1-plus.dtb
overlay_prefix=sun7i-a20

overlays=spi0-spidev

 

No luck yet.  I see an error message when executing the fixup script that is new:

 

 

Any suggestions?

 

[going]

11 часов назад, jimw сказал:

Any suggestions?

Try setting the verbose parameter to 7 in armbianEnv.txt

verbosity=7

 

The final DTS with the applied overlay can be obtained directly on the working device:

dtc --sort -I fs -O dts  /sys/firmware/devicetree/base > dts-out.txt

 

Check the existence of the spi object in the sys file system:

find /sys/ -name '*spi*'

 

Check dmesg command.

dmesg | grep spi
dmesg | grep -i err
dmesg | grep -i warn

 

This processor has not been tested for a long time.
Perhaps changes in the upstream of the u-boot, kernel sources somehow affected the situation.

Feel free to experiment. The device is in your hands.
I'm just trying to guide you along some path.
And the code I wrote is not necessarily working.
Just do your own by analogy.
The errors that you will get as a result are posted here in text form.

[jimw]

I really appreciate the help you have given me.  Thank you.

[going]

2 часа назад, jimw сказал:

I really appreciate the help you have given me.  Thank you.

Don't rush to say goodbye.

22 часа назад, jimw сказал:

I see an error message when executing the fixup script that is new:

Try to provide more information

[Ryzer]

Hi there,

 

I have been testing this on my Pcduino3 (Same A20 Soc) and was able to generate spidev0.0 and spidev0.1 using the old examples overlays. All initially did was change the compatibility field to use "armbian,spi-dev". The original example overlays can be found here:  https://github.com/armbian/sunxi-DT-overlays/tree/master/examples. I then found that I need to add the pinctrl nodes as demonstrated above to actually configure the pins correctly. You can check the pins are set correctly by using sudo cat /sys/kernel/debug/pinctrl/1c20800.pinctrl/pinmux-pins | grep PI1. Please see the resulting overlay below:

 

/dts-v1/;
/plugin/;

/ {
        compatible = "allwinner,sun4i-a10", "allwinner,sun7i-a20", "allwinner,sun8i-h3", "allwinner,sun50i-a64", "allwinner,sun50i-h5";

        fragment@2 {
                target = <&pio>;
                __overlay__ {
                        spi0_pi_pins: spi0-pi-pins {
                                pins = "PI11", "PI12", "PI13";
                                function = "spi0";
                        };

                        spi0_cs0_pi_pin: spi0-cs0-pi-pin {
                                pins = "PI10";
                                function = "spi0";
                        };

                        spi0_cs1_pi_pin: spi0-cs1-pi-pin {
                                pins = "PI14";
                                function = "spi0";
                        };
                };
        };

        fragment@1 {
                target = <&spi0>;
                __overlay__ {
                        #address-cells = <1>;
                        #size-cells = <0>;
                        status = "okay";

                        pinctrl-names = "default";
                        pinctrl-0 = <&spi0_pi_pins>;
                        spi-max-frequency = <1000000>;
                        num-chipselects = <2>;

                        spidev@0 {
                                reg = <0>; /* Chip Select 0 */
                                compatible = "armbian,spi-dev";
                                pinctrl-names = "default";
                                pinctrl-0 = <&spi0_cs0_pi_pin>;
                                status = "okay";
                        };

                        spidev@1 {
                                reg = <1>; /* Chip Select 1 */
                                compatible = "armbian,spi-dev";
                                pinctrl-names = "default";
                                pinctrl-0 = <&spi0_cs1_pi_pin>;
                                status = "okay";
                        };
                };
        };
};

 

 

btw you can use the "armbian-add-overlay" command to automatically compile and move into the overlay fold

 

best of luck

 

Ryzer

[jimw]

Thanks all; I'll try this.