Pinmuxing for SPI, UART, and GPIO Access

[Ben Manley]

I've been trying to use the SPI pins on the BeagleBoard-X15, but as far as I can tell I have not been changing the correct pins to the correct muxmodes.

On the TI PinMux Tool, I set it up for spi4 (pin AA4 for CS0, AB3 for D0, AB9 for D1, and AA3 for SCLK. These, as far as I can tell from this spreadsheet, correspond to the extension pins 17.39, 17.40, 17.09, and 17.10, respectively.). I see the autogenerated files on the right side, but I'm not sure what parts of that information must be put into the device tree file, or exactly how syntactically to do that. The most relevant information seems to be in the genericFileFormatPadConf.txt file:

0x4A003744 0x50002 AA3 CTRL_CORE_PAD_MCASP5_ACLKX mcasp5_aclkx spi4_sclk

0x4A00374C 0x50002 AB3 CTRL_CORE_PAD_MCASP5_AXR0 mcasp5_axr0 spi4_d0

0x4A003748 0x10002 AB9 CTRL_CORE_PAD_MCASP5_FSX mcasp5_fsx spi4_d1

0x4A003750 0x10002 AA4 CTRL_CORE_PAD_MCASP5_AXR1 mcasp_axr1 spi4_cs0

(That is with Rx checked off for D0 and SCLK)

The file I've been editing is the am57xx-beagle-x15-revc.dtb. Right now, this is the spi4 module in my .dtb:

spi@480ba000 {

                        pinctrl-names = "default";

                        pinctrl-0 = <&mcspi4_pins>;

                        compatible = "ti,omap4-mcspi";

                        reg = <0x480ba000 0x200>;

                        interrupts = <0x0 0x2b 0x4>;

                        #address-cells = <0x1>;

                        #size-cells = <0x0>;

                        ti,hwmods = "mcspi4";

                        ti,spi-num-cs = <0x1>;

                        dmas = <0xb1 0x46 0xb1 0x47>;

                        dma-names = "tx0", "rx0";

                        status = "okay";

                        linux,phandle = <0x1ea>;

                        phandle = <0x1ea>;

                        mcspi4_pins: mcspi4_pins {

                                pinctrl-single,pins = <

                                      ... (SEE BELOW) ...

                                >;

                        };

                        spidev@0 {

                                #address-cells = <0x1>;

                                #size-cells = <0x1>;

                                compatible = "linux,spidev";

                                spi-max-frequency = <0x1312d00>;

                                reg = <0x0>;

                                status = "okay";

                        };

};

Inside of that mcspi4_pins block, inside of pinctrl-single,pins, I've tried a multitude of different syntaxes and modes. At first, I started with this block because documentation online said it was correct:

0x344 (PIN_INPUT_PULLUP | MANUAL_MODE | MUX_MODE2)

0x348 (PIN_INPUT_PULLUP | MANUAL_MODE | MUX_MODE2)

0x34c (PIN_OUTPUT_PULLUP | MANUAL_MODE | MUX_MODE2)

0x350 (PIN_OUTPUT_PULLUP | MANUAL_MODE | MUX_MODE2)

However, this gives a "cannot parse input tree" error when attempting to compile from dts to dtb.

I've tried putting variations of the PinMux Tool information in there, but nothing has worked. Besides editing the dtb file (I am actually editing a copy called am57xx-beagle-x15-revc-ben.dtb), I have changed the /boot/uEnv.txt file to use am57xx-beagle-x15-revc-ben.dtb (and I have tested and proven that my edited file is used or booting), I have edited the config-4.9.35-ti-r44 file by changing the CONFIG_SPI_SPIDEV and similar configuration lines from "= m" to "= y".

The furthest I have gotten is being able to see the correct spidevX.X folders in /dev. I'm not sure how to get this part of my system working.

As a final addition, I wanted to ask if the process for accessing UARTs and GPIOs is similar / how that should be done.

Thank you!

[Jason Kridner]

Which file did you see that syntax? Was there an include file specified that defined the macros?

I've tried putting variations of the PinMux Tool information in there, but nothing has worked. Besides editing the dtb file (I am actually editing a copy called am57xx-beagle-x15-revc-ben.dtb), I have changed the /boot/uEnv.txt file to use am57xx-beagle-x15-revc-ben.dtb (and I have tested and proven that my edited file is used or booting), I have edited the config-4.9.35-ti-r44 file by changing the CONFIG_SPI_SPIDEV and similar configuration lines from "= m" to "= y".

The furthest I have gotten is being able to see the correct spidevX.X folders in /dev. I'm not sure how to get this part of my system working.

What syntax are you using to send SPI data? Can you share the kernel log provided by ‘dmesg’?

There’s a way to dump the active pinmux modes (register values). I’ll try to find it. 

As a final addition, I wanted to ask if the process for accessing UARTs and GPIOs is similar / how that should be done.

Should be similar. 

Thank you!

--
You received this message because you are subscribed to the Google Groups "beagleboard-x15" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard-x...@googlegroups.com.
To post to this group, send email to beagleb...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard-x15/f4a8befd-e840-46c6-9286-885bb0217b9d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ben Manley]

The syntax with the device tree came from using dtc to create a .dts file from am57xx-beagle-x15-revc.dtb (that I copied and edited into am57xx-beagle-x15-revc-ben.dtb). The syntax with the 0x4A003744... came from genericFileFormatPadConf.txt on the TI PinMux Tool, and it did not include any /include files. The syntax with the 0x344 (PIN_INPUT_PULLUP...), I found online from multiple people saying it worked for them.

For SPI data, I'm using a Python SpiDev library. As of right now, I was essentially just using writebytes([0x01]) and readbytes(8) to attempt to get a message from a SPI device. It connects to the spidevX.X folders in /dev, but no data is coming through it.

I've attached the dmesg output to this post. (Ignore the lines with errors like cs2 >= max 2 involving spi - those are from SPI1, SPI2, and SPI3, where I haven't yet changed the configuration to have more than 1 chip select each). The lines that I noticed were:

[    2.414171] pinctrl-single 4a003400.pinmux: please update dts to use #pinctrl-cells = <1>

and

[    9.599171] spi_master spi4: cannot find modalias for /ocp/spi@480ba000/mcspi4_pins

[    9.608313] spi_master spi4: Failed to create SPI device for /ocp/spi@480ba000/mcspi4_pins                                         

[    9.608345] spi spi4.0: not using DMA for McSPI (-19)

[何海宇MHE]

Hi Ben,

  My guide can help you :

      https://github.com/mhe747/dawnboard/blob/master/BeagleSDR_KernelHack.md

After my tests on SPI, which doesn't show any voltage activities detected by my osciloscope. MCSPI maybe not working in Beagleboard-x15, the pin configuration maybe missing from the Kernel ? 

So good luck, and tell us if you manage to.

BR,

Mich.

[Jason Kridner]

Ben,

Just a bit of a primer on editing your dtb.

You should probably start by updating your kernel.

cd /opt/scripts

git pull

cd tools

sudo ./update_kernel.sh --lts-4_14

REBOOT

You should be editing the dts via /opt/source/dtb-4.14-ti.

cd /opt/source

git clone https://github.com/RobertCNelson/dtb-rebuilder.git dtb-4.14-ti

cd dtb-4.14-ti

cp src/arm/am57xx-beagle-x15.dts src/arm/am57xx-beagle-x15-ben.dts 

EDIT src/arm/am57xx-beagle-x15-ben.dts

make

sudo make install

I believe you already know how to specify your dtb in /boot/uEnv.txt.

dtb=am57xx-beagle-x15-ben.dtb

--

You received this message because you are subscribed to the Google Groups "beagleboard-x15" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard-x...@googlegroups.com.
To post to this group, send email to beagleb...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard-x15/1e3a1126-878b-4628-9fe0-af7682b41fdd%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

https://beagleboard.org/about

[Jason Kridner]

On Wed, Apr 25, 2018 at 1:21 PM Jason Kridner <jkri...@gmail.com> wrote:

Ben,

Just a bit of a primer on editing your dtb.

You should probably start by updating your kernel.

cd /opt/scripts

git pull

cd tools

sudo ./update_kernel.sh --lts-4_14

REBOOT

You should be editing the dts via /opt/source/dtb-4.14-ti.

cd /opt/source

git clone https://github.com/RobertCNelson/dtb-rebuilder.git dtb-4.14-ti

cd dtb-4.14-ti

cp src/arm/am57xx-beagle-x15.dts src/arm/am57xx-beagle-x15-ben.dts 

ooops, should be:

cp src/arm/am57xx-beagle-x15-revc.dts src/arm/am57xx-beagle-x15-ben.dts 

--

https://beagleboard.org/about

[Jason Kridner]

Can you provide the contents of /sys/kernel/debug/pinctrl/4a003400.pinmux/pins ? 

--

https://beagleboard.org/about

[Jason Kridner]

Heard you reboot without having the dtb specified available for the new kernel. Sorry for sending you down that path.

Grab an X15 image off of https://beagleboard.org/latest-images and use http://etcher.io to write it to a microSD.

After you boot....

sudo mount /dev/mmcblk1p1 /mnt

EDIT /mnt/boot/uEnv.txt to comment out the dtb= line

sync

REBOOT

Then you can get about the business of editing your new dtb. Wish the bootloader config was smart enough to use the default when the manually supplied option cannot be found. :-(

--

https://beagleboard.org/about

[何海宇MHE]

Hi Jason,

   Thank you for the link. However after checking out the file am57xx-beagle-x15.dts

I can't find any pin muxing for mcspi4. What does it do ? Did you try by yourself the mcspi ? Did you manage to have it worked ?

BR,

[何海宇MHE]

    Attached file is my pinmux file "4a003400_pinmux.txt" ... Can you imagine the cause ?

[Ben Manley]

I have attached the pins file as you requested - this is after editing the .dts, making the dtb in the boot directory, editing uEnv.txt accordingly, and rebooting.

[何海宇MHE]

   Tested the new version of Kernel 4.14 of RobertCNelson,
however the matrix-app-launcher doesn't work, seems something broken with the non-official TI Kernel.
maybe opencl examples don't work too.

[Ben Manley]

Ended up flashing the new X15 image onto it (nothing to lose, so just reset it all). Changed the pinmux configuration, compiled the dtb, and rebooted. The pin information in /sys/kernel/debug/pinctrl/4a003400.pinmux changed from its original state, so hopefully it worked. About to test the clock signal with an oscilloscope. Attached is the dmesg output of the board right now.

[何海宇MHE]

Hi Ben,

    May I have a snapshot (plz, use your smartphone to take photo) of your oscilloscope showing activities of SPI ? also which pin did you test ? on which port ? P17 ?

Thanks

PS:  btw is it normal that rpmsg was disabled ? and did you see the matrix gui ?

[何海宇MHE]

Hi,

I think the SPI Pin Mux may not properly work in the TI Processor-SDK 4.xx kernel. It may have something related to.

Indeed, I have following traces in my Kernel that Ben seems not having met at all :

[ 2.869937] pinctrl-single 4a003400.pinmux: could not add functions for mcspi4_pins 4294960020x

That should stands for pin mux fault in the linux kernel of TI Processor SDK. Either they use a Kernel locked version,

either the CPU pins were not exactly same as those mentionned in the datasheet.

I just can't use another Kernel version because the one inside of Processor SDK comes with all AM5728 cores firmware.

It is the multi-core enabled version...

What a pity we can't afford the spi feature. I remember those good old days, when the 1st Beagleboard came already with SPI,

and used to work flawlessly. Whatever...

Thank you Jason and Ben for all !

Mich.

[Ben Manley]

Unfortunately I am no longer with the oscilloscope. I was sending out one byte at a time, so if I ever saw anything on the oscilloscope it was just one line that would instantly appear and disappear. This worked for multiple different MCSPI4 pin sets on P17

[Ben Manley]

For both UART3 and MCSPI4, I was able to see signals out on the oscilloscope when working with the py-serial and py-spidev libraries after changing the dts and dtsi in opt/source/dtb-4.14-ti/src/arm. Still figuring out exactly why Im not getting data back from the devices, but I will reach out to the manufacturers of those devices about that.

On a semi-related note:

Upon adding many different pin sets to the TI PinMux Tool (multiple SPI buses, a UART, a few GPIO, a SATA, and two USB), I have run into a set of pin conflicts that I'm not sure about.

When using all of these sets, there are inevitable pin conflicts between the pins on the extension headers (16, 17, 18, and 19). However, there are certain pins that seem to not be on the extension header (like led usr 0 and 1, and HDMI ct hpd, pins that can have SPI1 muxmodes), but are these actually usuable and accessible?

Also, I don't think I have a full understanding of how a sensor would talk over a USB connection (unless it works in /dev/ttyUSB* and is serial), how a hard drive would talk over SATA, or exactly how those work with pinmuxing (if its as straightforward as with SPI and UART or if there's extra stuff that needs to be done)

Thanks!

[何海宇MHE]

Ben,

   I think the pin-muxing is just a mess. We all have same issue. SPI never hits interrupt, that's why no data back to get received. Worse than that, I don't even detect any voltage activities of SPI output. 

Nobody seems to know how and why that works or not.

I tested on all 4 ports. Really no spi signal anywhere...  I use the TI Kernel  Linux am57xx-evm 4.9.59-ga75d8e9305. 

I eventually recommend to contact TI forum. Just keep us in your pipe. For now, I give up the SPI feature. What a pity, really.

[Matthijs van Duin]

For those still strugging with SPI, I've created a py-uio example that tests communication between mcspi and a simple pru spi slave device via four external loopback connections (each of which is a pair of adjacent pins, so you can just take an FX18-60S connector and solder-blob those four pairs together). At the very least you can use the device tree fragment as a known-good example on how to setup mcspi.

Beware: I noticed that u-boot sets up most expansion header pins to various functions, intended for the lcd board of the AM572x uEVM. I strongly recommend disabling this default pinmux to avoid drive conflicts:

https://github.com/dutchanddutch/u-boot/commit/3e515ed6ef4e

and then configuring your own pins, either in u-boot or in the dts. If you're configuring pins in the dts, be advised that TI warns that this may cause glitches on pins while they're being reconfigured.

Device tree fragment:

https://github.com/mvduin/py-uio/blob/master/dts/bbx15-spi-test.dtsi

PRU firmware:

https://github.com/mvduin/py-uio/blob/master/pru-examples/fw/bbx15-spi-test.pasm

Test script:

https://github.com/mvduin/py-uio/blob/master/pru-examples/bbx15-spi-test.py

If you haven't used py-uio before, be sure to install this udev rule:

https://github.com/mvduin/py-uio/blob/master/etc/udev/rules.d/uio-pruss.rules

Hope this is useful

Matthijs

[Jason Kridner]

Great tips, thanks!

--

You received this message because you are subscribed to the Google Groups "beagleboard-x15" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard-x...@googlegroups.com.
To post to this group, send email to beagleb...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard-x15/CAALWOA8HDUpxyQPYQKreU49%3DHfv%2BDyXV_ijtZSEdxdXZMrcX_g%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

https://beagleboard.org/about

[何海宇MHE]

ok, so we have to link port P17 pins :

33<->34

04<->03

07<->06

36<->37

thank you mat. !

[mich...@gmail.com]

Hi Jason,

     Happy new year and wishing you the best among all ! Thank for having appreciated my project BeagleSDR.
Just let you know the BeagleSDR project still is evolving. Now I'd like to integrate an UHF/VHF local oscillator plus RF mixer and an audio codec chip.
What do you suggest more ?

BR

MHE

[Jason Kridner]

You should start a new thread.

A simplified quick start with special attention on mechanical connection would be great.

I’m not an SDR expert. I’d ask Phillip Balister.

--

https://beagleboard.org/about

[pooja chakraborty]

Hello,

I am very new to this device tree concept and need some help. I want to use i2c4 and gpio5_8. I have checked the muxmode of these pins in the /sys/kernel/debug/pinctrl/4a003400.pinmux/pins file and they are in the correct pinmux setting , i.e. i2c4_scl and i2c4_sda, gpio5_8 all these pins are configured in the appropriate mux mode. Still if i do i2cdetect, it does not show i2c4 . So i believe I have to enable it.

Checking several links i can understand that i have to modify some .dts file and compile it to .dtb. My doubt is:

1) How to know my board is running which .dtb file since i can see multiple .dtb files under /boot/dtbs directory.

2) rather than editing the dts file can i write an overlay for enabling i2c4.? So as per my understanding, to enable i2c4 the overlay should be as follows (Kindly correct me if its incorrect):

/dts-v1/;

/plugin/;

 / {

 fragment@0 {

              target= <&i2c4>;

              __overlay__{

              status= "okay"

              };

};

};

Is this sufficient?