jimw

Nice. Thank you.

Thanks all; I'll try this.

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

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?

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

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.

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?

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

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!

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.

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.

I've tried many permutations of overlays and user-overlays and I can get /dev/spidev0.0 or /dev/spidev0.1 to be present, but I can't seem to get both simultaneously. I need both to migrate a project from an older Fedora distribution relying on modprobe to the latest version of Armbian. Any suggestions will be greatly appreciated! I started with very recent Armbian 23.02 Bullseye XFCE downloaded from arbian.com/banana-pi-plus .. Armbian_23.02.2_Bananapi_bullseye_current_5.15.93_xfce_desktop.img and I added the following to the /boot/armbianEnv.txt file, as described in the Armbian page associated with the BananaPi M1+ .. fdtfile=sun7i-a20-bananapi-m1-plus.dtb I also added these overlays at the same file .. overlay=spi-spidev spi-add-cs1 param_spidev_spi_bus=0 After reboot, I see one /dev/spidev device: # ls /dev/sp* /dev/spidev0.0 If instead, I also add .. param_spidev_spi_cs=1 Then after reboot, I see a device for the other chip select, only .. # ls /dev/sp* /dev/spidev0.1 but I can't find a means to have access to both simultaneously. As an aside, I also tried the following; Through some searching in the forum, I found a link to a promising overlay .. armbian / sunxi-DT-overlays / examples / spi-double-spidev-cs.dts Contents shown below .. I downloaded this and compiled it using .. dtc -@ -I dts -O dtb -o /boot/overlay-user/spi-double-spidev-cs.dtbo spi-double-spidev-cs.dts Then, since the thread said, "You will still need to use spidev-add-cs1 overlay but remove spi-spidev one because the custom one will be used instead of it," I used the following in the /boot/armbianEnv.txt file .. overlays=spi-add-cs1 user_overlays=spi-double-spidev-cs I confirmed the user overlay did load .. But this produced neither /dev/spidev0.0 or /dev/spidev0.1. Any ideas? I'd rather not have to compile the kernel since I'd have to outfit a whole new development environment for that, so I'm hoping this can be done with dts or dtbo files. Any tips or hints on which direction I should go next will be GREATLY appreciated. Thank you.