This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Using SPI in userspace in linux-3.12 on beaglebone black

Hi,

I failed to use SPI with the latest TI Linux : ti-sdk-am335x-evm-07 for beaglebone black

1) Config the kernel to enable SPI

2) CompileDocument/spi/spidev_test.c

3) Make node /dev/spidev c 153 32

The error is

can't open device: No such device or address
Aborted

I believe something about SPI0, SPI1, ...

What should I do ?

Thanks,

~Duy-Ky

##############################################################

Below is the details what I did

1) Kernel config

[ v ] SPI support (enable)

[ v ] Debug support for SPI

[ v ] MxSPI for OMAP

[ v ] User mode SPI

2) Run new kernel

Compile, load and run new kernel, the BBB (BeagleBone Black) appears to run new kernel

[    0.000000] Linux version 3.12.10-ti2013.12.01 (dkn@dkn-ubuntu-10) (gcc version 4.9.1 20140505 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.05 - Linaro GCC 2014.05) ) #1 Fri Nov 7 17:18:32 PST 2014

3) Compile spidev_test.c using cross-compiler arm-linux-eabihf-gcc

  • You might have to modify the device tree to enable SPI and pinmux. Never done this on this platform. Some threads show how others have modified the device tree for SPI.
    http://e2e.ti.com/support/arm/sitara_arm/f/791/p/341710/1194372.aspx
    http://e2e.ti.com/support/arm/sitara_arm/f/791/t/370905.aspx
    http://e2e.ti.com/support/embedded/linux/f/354/t/375525.aspx

  • Hi Norman,

    It's nice to see you again

    To me Linux for BeagleBone, and embedded Linux as a whole, is really a mess as the board is too cheap so too many people work on it, once they failed to do something, they blame the the structure, rather try to solve their problem in a backward compatible way.

    In the old day, there was only one computer for hundred, even thousand users. So an error from a single user must be isolated, no impact on computer so it's operational for others to use. That's where privilege permission came to rescue

    Nowadays, on contrary, a single user has several computers, so that kind of protection is totally irelevent, it's even to make thing worse as we have to spend too much time to overcome this privilege for nothing!

    In embedded world, even a single task goes wrong, the whole system must be shutdown, so there won't be unexpected result. So, why bother those kind of privilege permission, ... To me, it's just bureaucracy, a big waiste

    I really love uC-Linux as it has no such stupid protection as in Linux, all drivers are straight-forward using memory pointer as in conventional embedded world

    I started using Device Tree quite several years ago for PowerPC and found it's very convenient compared to my previous Linux for x86 SBC (Single Brd Comp)

    The real mess in BB is there're several flavors of kernel and they behave totally different

    1) eLinux for BB : I reconfig to enable SPI, it stops working after new kernel replace

    2) Armstrong : I had to spend a lot of time in struggling to find out the whole set working together : kernel, uboot and busybox for root filesystem as different compilers must be used for different package! I'm not able to use the same compiler for all!

    3) Build-Root (BR) : the best, it provide the whole tool set to create the whole system : kernel, uboot, busybox root-filesystem and a lot more

    4) Back to BB (BeagleBone), device tree starts from kernel 3.8. BB uses overlay device-tree (DT) via capemngr where new DT is plugged into the existing one, but only for eLinux kernel, I'm not able to use for BR kernel as there's no capemangr

    In my opinion, TI should focus their effort on using uC-Linux if they want a big success with little effort

    Back to my problem per you suggestion, like I mentioned earlier, I'm not able applied overlay DT to my current kernel, now I'm trying to modify right on the original one in kernel. I'll let you know if I could make it

    Thanks, Norman

    ~Duy-Ky

  • Hi Norman,

    I have to modify am335x-boneblack.dts to enable SPI1 via pinmux

    &spi1 {
            spi1_pins: pinmux_spi1_pins {
                pinctrl-single,pins = <
                    0x190 0x33    /* spi1_clk.spi0_clk : 190 = 990 - 800*/
                    0x194 0x33    /* spi1_d0.spi0_d0 */
                    0x198 0x33    /* spi1_d1.spi0_d1 */
                    0x19c 0x33    /* spi1_cs0.spi0_cs0 */
                >;
            };
    };
     but it doesn't help,

    Anyone has any idea ?

    Thanks,

    ~Duy-Ky

  • I am still undecided about the the application of linux on embedded platforms. Depends on the features required. A lot of times, I do wish there was a viable bare metal solution (less said about StarterWare...). Other times, linux is the price for a rich feature set.

    Not so about the usefulness of device trees either. They only make sense if you have a kernel with ALL device drivers compiled in and then use the device tree to enable only those you actually have. The kernel size gets quite large. Beagle Bone use of device trees is awe inspiring. Not in a good way.

    Most peripherals have a common base definition in am33xx.dtsi include file. They all have a 'status = "disabled";' that unsurprisingly disables the peripheral. Specific platforms override that with a 'status = "okay";'. Using your tree, Ankur Tank's tree and some code from google searches, you could try something like this:

    spi1_pins: pinmux_spi1_pins {
          pinctrl-single,pins = <
                0x190 0x33    /* spi1_clk.spi0_clk : 190 = 990 - 800*/
                0x194 0x33    /* spi1_d0.spi0_d0 */
                0x198 0x33    /* spi1_d1.spi0_d1 */
                0x19c 0x33    /* spi1_cs0.spi0_cs0 */
          >;
    };
    
    &spi1 {
            status = "okay";
            pinctrl-names = "default";
            pinctrl-0 = <&spi1_pins>;
            spidev@1 {
                    spi-max-frequency = <1000000>;
                    reg = <0>; /* Device minor?  */
                    compatible = "linux,spidev";
            };
    };
    
    
    

    Some info here:

    http://elinux.org/BeagleBone_Black_Enable_SPIDEV

    Try searching around your kernel's dts directory. Hopefully some other AM335x dts file uses SPI.

  • Hi Normal,

    I totally agree with you regarding embedded Linux vs bare-metal one. That's why I bought both BB Black  & White as the latter has on-board JTAG so it's convenient to do StarterWare as usual!

    It took me few hours to get SPI up & run to have a nice color TFT display, but forever in fight with Linux SPI !!! I used SPI/I2C bit-bang in all my previous eLinux projects/products

    To me, Linux should be used "as is" in network-related products, I worked on several projects on network time server (NTP, PTP) using X86 SBC and PowerPC. All became great successful products

    But, once we need to have full control of HW, it's wise to use bare-metal one.

    I just want to refresh my Linux skill using BB after few years to see how thing change

    I got BB-Blk ($55) + 128GB USB Drive ($45) to have a several servers running on this BB-B : Subversion, Samba , Telnet & Web server.

    Before, I had subversion running on Win7 and had to call home to turn on PC in order to access SVN repo. Now I don't have to, my BB-Blk Linux server runs 24/7/365. I really like it, Norman.

    I don't believe in "one size fit all", so we need to pick the right technology for the right application

    I've just update DTS and it doesn't work. The reason they disable all peripheral, actually disable all peripheral clock, in order to save power consumption, so save battery life in handheld devices.

    I probably give up this attempt, it waistes my time too much for just a curiosity

    Thanks, Norman

    ~Duy-Ky