p-i-u.de

It's quite some time ago that I used my rockpi however today I wanted to restart my project again (some sensors with an A/D Board connected to SPI). First of all I tested the Board on a Raspberry Pi (with Raspbian) there it is working as expected so it is not a hardware issue. I connected my board MOSI = GPIO2_B2 (Pin 29), MISO = GPIO2_B1 (Pin 31), CS = GPIO2_B4 (Pin 33), Clock = GPIO2_B3 (Pin 7). The matter is that it sometimes works and the correct data is received but just once in a while. For me it seems that the CS is not working properly but how to get SPI communication working correctly? In the attached screenshot the value 744 is the correct value, i attached it to show the behavior of the SPI Bus, 4095 equals FF when using spidev-test util. There is also another ambiguous value 2047. Below are the contents of my /boot/armbianEnv.txt overlays=spi-spidev param_spidev_spi_bus=2 param_spidev_max_freq=100000 The frequency is also the same as what is used by the board. I'm currently on Armbian 23.02 with Kernel 5.15.93 (but also tested on another Rock Pi 4 A version 1.4 with kernel 6.1, same result) so does anyboday have an idea how to solve that issue?

I don't mess something up, the DTBO which is provided in this post brings up spidev0.1, I just try to help @martinayotte to get the cs-gpio kernel patch to work to help testing the patch with real hardware, that's all. With this you can have a SPI Bus and multiple GPIOs as chipselect so in other words use more than SPI Device on a single bus. As SPI Devices are common in the industrial field this would enhance the rockchip a lot.

Also on my end using real hardware, there is no output. Let me know if I can help further. How did you compute the numbers 3 16 to match GPIO3_C0? This is something I didn't figure out yet, is there any document?

I can do the test for you, as I've already set up everything, so just need the CS Pin number

I used your original dtbo and cabled my device to GPIO1_B0 = MOSI, GPIO1_A7= MISO, GPIO1_B1 = CLK, GPIO1_B2 = CS unfortunately it does not work. the dtbo as you already mentioned brings up spidev under spidev0.1. One question from what source do you got your information about how to set up you dts file? I've read the Device Tree Documentation and also looked at the patch however from that information I do not know what parameters to set in the dts, I would like to help out on this topic so that's why I'm asking

AFAIK, as that used for the internal SPI Flash ( I got a Rev 1.4 Board), however I can test tomorrow if it works with the default values

I have built the custom kernel with this patch being applied, changed the target path to target-path = "/spi@ff1e0000"; as SPI1 is not usable on rock pi 4, compiled with dtc and moved it to /boot/dtb/rockchip/overlay/rockchip-spidev2-1.dtbo having this in /boot/armbianEnv.txt overlays=spidev2-1 Now when I reboot I get /dev/spidev0.1 So, what wonders me is, a) why does it come up as spidev0 and b) how do I know which gpio pin is used for CS? Otherwise I'm ready to test What do I miss?

actually I meant to get the patch in the upstream kernel sources. I've currently setting up my build environment and will start a build. Will need a few days until I'm done with testing, as I can just use certain timeslice each day to not interfere with my other projects.

I have a device to check,. Hmmmh should we do some advocacy work to get the patch into the mainline Kernel? As from the post to me it seems that has simply just forgotten

to what I understood it seems to be possible https://patchwork.kernel.org/patch/9780471/ if you can tell me what work is to do maybe I can help

Mainly, because I wasn't aware of them plus second I also want to access the gpio without being root and I develop in Java so need some native JNI library. Leaving just User Space IO where I'll have a look at. Actually the MRAA Library developed by Intel first exists since 2015 so it was there before the alternatives, the question should have been why did the others re-invent the wheel :-)

I also plan to add Tinkerboard Support as I got this board, too. However I know what you mean by time constraints which is also a very limiting factor for me. What would you think are the most important boards to add? OrangePi, Odroid?

What do you mean by R&D? Resources and Development? Note: the Github Repo is mine, which means I have done the modifications. Only problem though I'm not a C Coder and could need some help by an experienced C developer here and there

As WiringPi was never meant to support other boards nor does the author like to support other boards and it is officially depreciated now (http://wiringpi.com/wiringpi-deprecated/). I want to ask why not put some efforts into libmraa https://github.com/intel-iot-devkit/mraa and put it into the Armbian repository. I have already a fork which fixes Rock Pi 4 on recent mainline 5.3 kernels with updated debian build scripts here: https://github.com/bootsy52/mraa, so debian packages could be simple built using dpgk-buildpackage. Why I think it is a good idea to supply libmraa with the Armbian repository Supporting multiple boards is a desired goal of the project Supporting a board is really easy, for Rock Pi for example this is just the files src/arm/rockpi4.c include/arm/rockpi4.h and an entry in src/arm/arm.c, that's it Instead of multiple forks of wiringPi and different sources of different versions (or even different gpio implementations) just have one common implementation for all boards with wiringPi you need additional bridges if you want to code in other languages like Java or Python for example, with MRAA you have out of the box bindings for Python, Java, Javascript, C/C++ and NodeJS support What do you think? @Igor

I can confirm latest 5.3.11 buster server Image working fine on RockPI 4A with EMMC. Further more I used CP2102 successfully to connect via putty on serial console of RockPI at 1500000 https://www.amazon.de/Anpro-CP2102-Konverter-Stecker-eingebautem/dp/B0757FQ5CX

Thanx for the tip, I've used what Linus Torvalds used in his spidev_test.c program so I thought that is the correct way (I'm not a C Coder)

That part with AFTER seems an important one, however here comes the sad story short in hope that maybe at least another one who has this specific setup reads this post and finds this helpful. So the reason why i was always getting "Failed to perform SPI transfer": Bad Address had nothing to do with hardware but with the fact that we are on aarch64 on Rock PI and simply the libwidgetlords libraries where obiously not tested under 64bit as they used (uint32_t) instead of (unsigned long) in their code. So everybody who has a RockPI 4 and Pi-SPi-8AI Raspberry Pi Analog Input (4 - 20 mA) Interface follow this to get it to work Note you currently have to use the Armbian DEV branch so that overlays work put this in /boot/armbianEnv.txt (Note I also enabled uart4 as I use this for another device), you cannot use the 40 gpio to 26gpio Ribbon cable as we use SPI2 instead of SPI0 so you have to connect the board using jumper cables. So connect PIN 26 of the 8AI Board to PIN 33 of the RockPI, Pin 19 to 29 on RockPI, Pin 21 to 31 on RockPI and Pin 23 to 7 on RockPI For those of you who wonder how to connect the sensors to this board, using 2 wire sensors INPUT (voltage supply) goes in the V+ Terminal and the Output from the sensor goes into A1 - A8 overlays=spi-spidev uart4 param_spidev_spi_bus=2 Clone the git repository git clone https://github.com/widgetlords/libwidgetlords.git change includes (don't know if that's necessary but these are the ones used in spidev_test.c program by Linus Torvalds) and the following in src/spi.c #include <errno.h> #include <fcntl.h> #include <linux/spi/spidev.h> #include <stdint.h> #include <stdio.h> #include <string.h> #include <sys/ioctl.h> #include <linux/ioctl.h> #include <unistd.h> from this static const char prefix[] = "/dev/spidev0."; spi.tx_buf = (uint32_t)data; spi.rx_buf = (uint32_t)data; to this static const char prefix[] = "/dev/spidev2."; spi.tx_buf = (unsigned long)data; spi.rx_buf = (unsigned long)data; change SPI_8AI to 0 because we use /dev/spidev2.0 not /dev/spidev2.1 include/pi_spi.h #define SPI_8AI 0 Please find also attached a Java Implementation using MRAA to get access to this board (then there is in fact no need anymore for the libwidgetloard libraries at all) pi_spi.h spi.c SensorMRAA.java

Yes, that's what I've done to see if it's active after I got the Input/Output error and it was not there only ttyS0, ttyS2 Regarding SPI, thanx I'll try that above once again, maybe the error lies somewhere else, as i had cabling like that already before but get always "Bad address" however /dev/spidev2.0 is there

I already used jumper cables and tried to exacty do that which also doesn't work, as far as my understanding of the Chip Select = 1 is, that CS = 1 means active high getting to low and CS = 0 being active low, so it seems without spi-add-cs1 overlay I am quite lost on this BTW, could it be that the uart4 overlay is also not yet functioning? as I get Input/Output error on ttyS4

I'm using this board https://widgetlords.com/products/pi-spi-8ai-raspberry-pi-analog-input-interface the Pi-SPi-8AI 4-20 mA Variant, till now I've not found any way to get it working. Do you have any hints how to make the correct overlay or where to start? That is the overlay what they use for Raspberry PI https://github.com/widgetlords/libwidgetlords/blob/master/overlays/pi-spi.dts however I was not able to translate it to rk3399. Note I have an older Variant with 2 Jumpers to select CE1 and 22

I'm using the DEV branch right now and the overlay spi-add-cs1 is missing, do you have any idea how to get the information to create that overlay for RockPI? Furthermore I looked into rk3399-rock-pi-4.dts from there I see that CS1 is only in the section for SPI0, however when I use SPI0 I have no ethernet device anymore, so I thought I use SPI2 and CS1. Currently I'm not sure if this will work at all. Do you know if SPI2 and CS1 will work and how to get it to work? I connected my board which has definatley worked on Raspberry Pi before but I get no output

latest modifications of rk3399-rock-pi-4.dtb broke libmraa, the model name is set to "Radxa ROCK Pi 4" however libmraa looks in /proc/device-tree/model for "ROCK PI 4A" and "ROCK PI 4B" respectively. I verified that this is the reason which breaks mraa by changing the the model in the dtb to ROCK PI 4A and mraa is working fine, wheres before you get "No Pins" issuing the command mraa-gpio list. You can have a look in the sources of libmraa there you'll see that it is looking for that name in src/arm/rockpi4.c

OK, I've installed DEV Branch now, and now I see what's the reason that I did not see the README, because it is simply not there in 4.4 stable :-)

Personally as I'm using SoC for industrial purposes I'm glad that there is not coming anything new all the time, because we need stable, good software support and I have to test everything and support everything. I'm using RockPI 4A and I really hope, that I'll get longterm access to this product as it's fits perfect my needs.

Somehow the README.rockchip-overlays seems to be lost on my system. Does this also work on stable 4.4 or just in Dev Branch? Currently I'm on stable 4.4 branch. So if this is just in Dev is there any timeframe it is expected to get into stable? Otherwise great it works, as I really thought this is just not working