Search

Technical Discussion Group Forum

This forum is provided for user discussion. While Beacon EmbeddedWorks support staff and engineers participate, Beacon EmbeddedWorks does not guarantee the accuracy of all information within in the Technical Discussion Group (TDG).

The "Articles" forums provide brief Articles written by Beacon EmbeddedWorks engineers that address the most frequently asked technical questions.

To receive email notifications when updates are posted for a Beacon EmbeddedWorks product download, please subscribe to the TDG Forum of interest.

TDG Forum

PrevPrev Go to previous topic
NextNext Go to next topic
Last Post 28 Mar 2018 08:15 AM by  Adam Ford
How to acces /dev/spi
 1 Replies
Sort:
You are not authorized to post a reply.
Author Messages
James Giesbrecht
New Member
New Member
Posts:1


--
28 Mar 2018 01:57 AM

    In short, I'm trying to connect to a device using the SPI bus, and can't even get it to show up as a device in linux.

     

    What I've done:

    - Following the document:1028364B_DM37x_Linux_Mainstream_UG.pdf

    - Install and run the Ubuntu VM 1029082_Ubuntu_16.04 DM37x Mainstream Linux 1.0-1.ova (I've just started a new version straight from the downloaded copy so I know it's completely clean)

    - In ~/logic/buildroot/, 'make menuconfig' and enable anything labelled 'spi'

    ~/logic/buildroot$ grep -i spi .config

    BR2_PACKAGE_SPIDEV_TEST=y

    BR2_PACKAGE_SPI_TOOLS=y

    BR2_PACKAGE_PYTHON_SPIDEV=y

    - in ~/logic/linux-stable, make menuconfig and do the same

    ~/logic/linux-stable$ grep -i spi .config

    CONFIG_SPI=y

    CONFIG_SPI_MASTER=y

    CONFIG_SPI_BITBANG=m

    CONFIG_SPI_GPIO=m

    CONFIG_SPI_SPIDEV=m

    (etc)

    - then 'make linux-rebuild' and then 'make'

    - everything builds properly, because in ~/logic/buildroot/output/images, the following files have today's date:

    logicpd-torpedo-37xx-devkit.dtb, rootfs.tar, zImage

    - but the following files still have the default (March 2017) that came with the VM:

    MLO, u-boot.img

    -- (Do these two need to be rebuilt, and if so how?)

    - Do the section 3.2.1 'create_sdcard.sh' stuff and copy abovementioned files to the SD card in the right order.

    - Boot the Zoomboard, do the nand unlock/erase/etc steps.

     

    So all of that works, BUT, there's just no /dev/spi.

    'modprobe spidev' and spidev shows up in 'lsmod', but there's still no /dev/spi.

    So what else do I have to do to get /dev/spi to show up?

     

    Further, once I do this:

    # mount -t debugfs none /sys/kernel/debug/

    # cd /sys/kernel/debug/pinctrl/48002030.pinmux/

    # grep -i mcspi ./*
    ./pingroups:group: pinmux_mcspi1_pins
    ./pinmux-functions:function: pinmux_mcspi1_pins, groups = [ pinmux_mcspi1_pins ]
    ./pinmux-pins:pin 204 (480021c8.0): 48098000.spi (GPIO UNCLAIMED) function pinmux_mcspi1_pins group pinmux_mcspi1_pins
    ./pinmux-pins:pin 205 (480021ca.0): 48098000.spi (GPIO UNCLAIMED) function pinmux_mcspi1_pins group pinmux_mcspi1_pins
    ./pinmux-pins:pin 206 (480021cc.0): 48098000.spi (GPIO UNCLAIMED) function pinmux_mcspi1_pins group pinmux_mcspi1_pins
    ./pinmux-pins:pin 207 (480021ce.0): 48098000.spi (GPIO UNCLAIMED) function pinmux_mcspi1_pins group pinmux_mcspi1_pins

     

    So the pinmux is showing them as GPIO UNCLAIMED. Shouldn't that be showing them as SPI if they are indeed enabled?

     

     

    ALSO, here's a thing I've noticed. In the buildroot menuconfig, I enabled bash as the default shell.

    ~/logic/buildroot$ grep -i bash .config

    BR2_SYSTEM_BIN_SH_BASH=y

    BR2_SYSTEM_BIN_SH="BASH"

    BR2_PACKAGE_BASH=y

    But when I boot into the Zoomboard, it's using 'ash' (because in /root/ there's a file called .ash_history and no file called .bash_history).

    I don't mind using ash, but that's not the point. The point is, maybe the compilation steps aren't working properly? If it's ignoring my ash->bash change in the menuconfig, maybe it's also ignoring my spidev change? The kernel is compiling fine, because otherwise I wouldn't have spidev.ko available. But maybe the buildroot/.config is stuffing up somewhere?

     

    Does it have something to do with devicetree? i don't even know what one is, frankly, and in all the documentation that i've downloaded from the site here the only real mention of it that i can see are the few lines in sections 2.5/2.6. Section 2.6 of the userguide says to append it to the zImage to create zImage_dtb, but then that isn't copied to the SD card anyway, so that can't be making a difference.

    Adam Ford
    Advanced Member
    Advanced Member
    Posts:793


    --
    28 Mar 2018 08:15 AM

    There is lot in your message, but I'll try to address them.

    Buildroot appears to not handle switching shells well. If you do a 'make clean' then 'make' I would expect the shell you want to be built. I haven't found a better way to handle it, and unfortunately, it takes a long time to rebuild.

    The SPI dev has 3 components. The userspace tool you noticed in buildroot, the spidev driver or module in the kernel and the device tree.

    The device tree is effectively a table which shows which devices in your hardware. It allows people to modify the tree independently of the Kernel which allows a single kernel to run on multiple platforms and the device tree helps the drivers understand pin-muxing configurations and which peripherals are available.

    In order to build spidev, you'll need to enable the kernel driver, which it appears you have done so. U-Boot does not need rebuilding.

    The part you need to still do is the device tree editing. The 4.4 kernel has two files which describe the Torpeodo.

    ~/logic/buildroot/output/build/linux-4.4.76/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
    Describes the SOM itself.

    ~/logic/buildroot/output/build/linux-4.4.76/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
    Describes the baseboard + SOM.

    Without going into a bunch of details, you'll need to edit either of these two files.

    My recomendation would be to edit
    ~/logic/buildroot/output/build/linux-4.4.76/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts

    In this file you'll see a section referencing SPI1

    &mcspi1 {
    at25@0 {
    compatible = "atmel,at25";
    reg = <0>;
    spi-max-frequency = <5000000>;
    spi-cpha;
    spi-cpol;

    pagesize = <64>;
    size = <32768>;
    address-width = <16>;
    };
    };


    The &mcspi1 references SPI1 and implies we're going to make changes or additions to the what's already been defined for mcspi1.

    In side the braces describes what's attached to spi1. In this case the at25 eeprom.

    If your baseboard does not contain the at25 eeprom, you can delete the inner contents so the eeprom driver doesnt' attempt to load.

    If you want to enable spidev, you can insert the bindings for it inside mcspi1.

    spidev@0x00 {
    compatible = "spidev";
    spi-max-frequency = <30000000>;
    reg = <0>;
    };

    If you want to use a different SPI bus, you'll have to define the pin-muxing etc for that bus, but for this example I'll assume spi1

    The spidev@0x00 and reg=<0> options both select CS0. If you want to change these to other chip selects, you'll also need to change both of these to 0x01 and <1> respectively and modify the pin-muxing.

    since the baseboard already contains the EEPROM and you cannot have multiple devices sharing the same CS, make sure you remove the EEPROM stuff.

    If you want me to help you with the pinmuxing examples, let me know.
    Those are found in ~/logic/buildroot/output/build/linux-4.4.76/arch/arm/boot/dts/logicpd-torpedo-som.dtsi

    OMAP3_CORE1_IOPAD(0x21ce, PIN_OUTPUT | MUX_MODE0) /* mcspi1_cs0.mcspi1_cs0 */

    The above line represents the pinmux. The address 0x21ce is found in table 13-4 of the DM3730 Technical Reference manual where the mcspi1_cs0 is the top 16 bits of address 0x4800 21CC (which makes it 21ce) and the mode 0 represents chip select.

    Once you've edited and saved the file, you can rebuild linux with 'make linux-rebuild' from the buildroot directory.  Once completed, 'make' will replace contents of output/images with the new ones you just build.  You should be able to use the new kernel, userspace files and device tree to boot and /dev/spidev1.0 will represent spi1-cs0


    adam
     

    You are not authorized to post a reply.