missig spidev2.1

mafish

Hello,
I work on a project where I need to communicate with two external MCUs, via SPI.
I've successfully used MRAA lib to test the communications to single MCU, but when I've tried to write to the second one I've noticed I only got /dev/spidev2.0 in my system.
As I understand to access the second MCU (using same MOSI/MISO/SCK lines) I should have spidev2.1 also present.
What might be an issue and how to fix it?

I am using ubilinux kernel with RT patch right now,
Linux ubilinux4 4.9.45-rt37-upboard+ #1 SMP PREEMPT RT Sun Aug 11 10:20:11 UTC 2019 x86_64 GNU/Linux
although my issue was also present before patching.

Dan O'Donovan

Hi @mafish

You could try adding the following parameter on the kernel command line:
up_board.spidev1=1

To extend the kernel command line parameters, one option is to edit /etc/default/grub and add the parameter to the $GRUB_CMDLINE_LINUX_DEFAULT variable, and then run sudo update-grub2, and reboot.

I hope that helps.

Best regards,
-Dan

mafish

Thank you, for a quick and clear response!
It's a partial success. The device spidev2.1 has appeared in /dev/ and MRAA library is initializing the interface nominally, but there is no output on CS1 pin (it is constantly in high state), all the other pins(MOSI/MISO/SCK) work fine.
Can CS1 pin be somehow rewired to other GPIO? Or maybe I need to somehow show the kernel what GPIO to use as CS1?

[EDIT]: I've just checked the bios. in Advanced/HAT Configuration/GPIO Configuration in Pin Order, pins from SPI (Pin 19, 21, 23 and 24 -> 24 being CS0) are grayed out and marked as 'SPI2' and pin 26 (CS1) is represented as regular GPIO ( can be set either Input or Output), is this BIOS related error then? I haven't upgraded my BIOS, it is completely stock.

Dan O'Donovan

The UP board doesn't have a real CS1 signal for the SPI2 bus, so we used a GPIO pin instead for that... or so I thought... but I've just discovered that the patches I created initially for the v4.4 kernel to make that work were dropped from later UP board kernels. I'm not sure why.

I don't think these will apply cleanly on the v4.9 kernel, but perhaps you might like to see if you can integrate them manually?
https://github.com/emutex/meta-up-board/blob/krogoth/recipes-kernel/linux/files/0017-spi-spi-pxa2xx-use-cs_gpio-if-valid.patch
https://github.com/emutex/meta-up-board/blob/krogoth/recipes-kernel/linux/files/0018-spi-spi-pxa2xx-add-GPIO-CS-lines-for-UP-platform.patch

mafish

For now, I have no idea how to make use of the links you posted. I guess its time to learn something new.
I will update the topic once I've find and implement a solution of some sort. Thank you nonetheless.
[EDIT]: can you recommend any source of knowledge in this topic (kernel patches, device drivers etc), other than raw documentation? Any online(and free) courses or tutorials.

rushu

I have the same problem when I need to use the spidev 2.1 in UP board. Is it need to use UP square instead?

mafish

Hi @rushu , I've figured out it can be done using software and GPIO toggling, with some reasonable latency. Using MRAA C++ library and Ubilinux with PREEMPT-RT patch I have achieved ~70us delay in CS1 switching, compared to regular hardware CS0. It's good enough for me.

rushu

Thanks @mafish , you are really good! It seems a good way to solve the problem.
But I am using Ubuntu and python, I still don't know how to patch preempt RT under Ubuntu system.
May be I should tend to use the Ubilinux.

DCleri

@rushu

Ubilinux is no longer supported and it won't receive future updates.

Thanks to your feedback we will include a patch in a future kernel to re-enable the CS on recent kernel also for Ubuntu.

About the Preempt-rt patches we will review internally if release it as a separate kernel or include in the standard one.

rushu

@DCleri
Great！We are looking forward to the official updates.

horson

@DCleri
Great！We are looking forward to the official updates.

Dan O'Donovan

Hi folks

The Ubuntu Xenial/Bionic (v4.15) and Yocto sumo (v4.14) kernels have now been updated to enable spidev2.1 on UP board. It is disabled by default, but can be now enabled by adding up_board.spidev1=1 to the kernel command line and rebooting.

See the following instructions (or my earlier post above) for an example of how to add kernel command-line parameters on Ubuntu: https://askubuntu.com/questions/19486/how-do-i-add-a-kernel-boot-parameter

Let me know if you have any questions.

Best regards,
-Dan

Dan O'Donovan

If needed, patches for the v4.14 kernel can be downloaded from here:
0019-spi-pxa2xx-Set-dir-and-value-when-requesting-cs-gpio.patch
0020-platform-x86-upboard-Add-gpio-chip-select-for-UP-Boa.patch

mafish

Hello again.
I am again @Dan O'Donovan. I am back on the topic with new project, fresh upboard, clean ubuntu 18.04 (v4.15), configured according to the wiki, with up_board.spidev1=1 argument in kernel cmdline . My goal is the same - achieve low latency dual SPI working, from upboard to two MCUs. I've started with MRAA, first of all, CS1 doesn't work out-of-the-box with mraa lib. Furthermore, after once setting
the kernel argument, I've cannot use pin22 as GPIO (neither from mraa, nor from cmdline), the pin is stuck in low state.
I went as far as trying to use <linux/spi/spidev.h>, basing on what i have found on MIT Cheetah Software. Using this method, neither of CS pins are responding (with all other pins switching correctrly).
May I ask, what is the proper way of using the SPI now? What libs are fully supported?

tdudz

@Dan O'Donovan I am having this same issue. spidev.h is able to open /dev/spidev2.0 and /dev/spidev2.1 but i get no data in the rx_buf when trying to communicate. it seems like the chipselect still does not work