Overlay does not create SPI pingroups with 4.4.21 kernel

GoogleGroups
1

I have several overlays that I’ve been using with an earlier (4.1.10) kernel. In trying to port everything to a more recent kernel, my two SPI overlays don’t create pingroups and don’t set pinmux attributes. I’ve recompiled them using the dtc that came with the new kernel with no effect. They load with no errors and appear in the slots file, but the SPI buses don’t work and there are no SPI pingroups.

Other overlays (for uarts, for instance) load properly and create pingroups as expected.

On the same hardware, the earlier kernel works fine with the same overlays - the overlays load and the expected pingroups are created.

The SPI overlays are the defaults, except that CS1 is enabled on spidev1.

What’s the next step in debugging this?

dmesg excerpt - same as with old kernel:
[ 6071.124287] bone_capemgr bone_capemgr: part_number ‘BB-SPIDEV1’, version 'N/A’
[ 6071.124320] bone_capemgr bone_capemgr: slot #4: override
[ 6071.124335] bone_capemgr bone_capemgr: Using override eeprom data at slot 4
[ 6071.124351] bone_capemgr bone_capemgr: slot #4: 'Override Board Name,00A0,Override Manuf,BB-SPIDEV1’
[ 6071.140084] bone_capemgr bone_capemgr: slot #4: dtbo ‘BB-SPIDEV1-00A0.dtbo’ loaded; overlay id

New kernel pin states:

pin 89 (44e10964.0) 00000027 pinctrl-single
pin 100 (44e10990.0) 00000027 pinctrl-single
pin 101 (44e10994.0) 00000027 pinctrl-single
pin 102 (44e10998.0) 00000027 pinctrl-single
pin 103 (44e1099c.0) 00000027 pinctrl-single

pin 89 (44e10964.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)

pin 100 (44e10990.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 101 (44e10994.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 102 (44e10998.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 103 (44e1099c.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)

Old kernel (working) pin states:

pin 89 (44e10964.0) 00000012 pinctrl-single

pin 100 (44e10990.0) 00000033 pinctrl-single
pin 101 (44e10994.0) 00000033 pinctrl-single
pin 102 (44e10998.0) 00000013 pinctrl-single
pin 103 (44e1099c.0) 00000013 pinctrl-single

pin 89 (44e10964.0): 481a0000.spi (GPIO UNCLAIMED) function pinmux_bb_spi1_pins group pinmux_bb_spi1_pins

pin 100 (44e10990.0): 481a0000.spi (GPIO UNCLAIMED) function pinmux_bb_spi1_pins group pinmux_bb_spi1_pins
pin 101 (44e10994.0): 481a0000.spi (GPIO UNCLAIMED) function pinmux_bb_spi1_pins group pinmux_bb_spi1_pins
pin 102 (44e10998.0): 481a0000.spi (GPIO UNCLAIMED) function pinmux_bb_spi1_pins group pinmux_bb_spi1_pins
pin 103 (44e1099c.0): 481a0000.spi (GPIO UNCLAIMED) function pinmux_bb_spi1_pins group pinmux_bb_spi1_pins

2

Disable the "edma-fix" it's causing spi issues in v4.4.x

Just comment out it out like:

https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am335x-boneblack.dts#L12

Regards,

3

Thanks. I’m using your precompiled kernel, so I assume I checkout / download your ‘dtb-rebuilder’ and recompile the am335x dtb files that live in /boot/dtbs// - correct?

4

yeah..

Or if your running: 4.4.21-ti-r47 or newer, r47 was the first 4.4.x
release with the spi edma workaround disabled by default..

Regards,

5

Killing me here - I’m running 4.4.21-ti-r45. Is it worth just getting the newer kernel?

6

Yeah, just upgrade:

sudo apt-get update
sudo apt-get install linux-image-4.4.21-ti-r47
sudo reboot

https://github.com/RobertCNelson/ti-linux-kernel-dev/commits/ti-linux-4.4.y

r46: bbgw wl/bt_en hacks

r47:
tilcdc fixes (lcd panels work again)
fixed edt-ft5x05 touchscreen
spi overlay fix..

Regards,

7

Thanks. Love your work, by the way. Pretty near perfect for my needs. We have an open-source building control built on top of the BBB - we created the world’s largest cape and stuffed it with industrial-grade I/O:

8

Fixed and working - thanks for your help and your quick response. I could have banged my head against the wall a good deal longer on this one. It feels so good when you stop doing that.

9

I am having almost the identical issue with SPI as pbft, except that I am running BBB’s with 4.4.19-bone-rt-r13 and 4.4.38-bone-rt-r14. I assume these can be fixed as per your suggestion, but it appears that the dtb-rebuilder is for the TI kernels only. Is this the case? If so, how should I proceed? Or is there some other problem entirely? Any guidance would be appreciated.

Thanks,
Phil

10

Ok, I found https://github.com/adafruit/adafruit-beaglebone-io-python/issues/94 and followed the instructions there. It works! Which leads me to my next comments/questions:

I have written a device tree overlay that incorporates SPI0, SPI1 and the PRUSS, and where SPI1 uses a GPIO for a 2nd chip select. Can I load this in the same manner via the kernel parameter in /boot/uEnv.txt? If this isn’t the right way, then what is?

Phil

11

I have written a device tree overlay that incorporates SPI0, SPI1 and the

PRUSS, and where SPI1 uses a GPIO for a 2nd chip select. Can I load this in
the same manner via the kernel parameter in /boot/uEnv.txt? If this isn't
the right way, then what is?

So whatever way that works for you, is the right way. But yes, in my own
opinion loading from uEnv.txt is the proper way. As the pin configurations
take place the quickest possible after a boot.

   1. So you need the overlay in /lib/firmware of course.
   2. Then you need to add the overlay to the
   cape_enable=bone_capemgr.enable_partno= line in uEnv.txt
   3. Finally you'll need to update the initramfs

To update the initramfs You need to:

william@beaglebone:~$ cd /opt/scripts/
william@beaglebone:/opt/scripts$ git pull /* So you need to sudo apt-get
install git - If not already installed */

william@beaglebone:/opt/scripts$ cd tools/developers/

william@beaglebone:/opt/scripts/tools/developers$ sudo ./update_initrd.sh

william@beaglebone:/opt/scripts/tools/developers$ sudo reboot

Then your custom overlay will be "injected" into the initramfs, and
properly load at boot.

12

Thanks for the info. I am not so sure about the need to update initramfs though. Just for yuks, I specified my custom overlay in uEnv.txt, and it seems to have loaded properly, which I confirmed by inspecting the output of dmesg. I am still verifying that my SPI ports work as expected (phase and polarity, mostly), but it seems to be working.

13

If you load overlays that are already included in your image, then you do not have to update the initramfs. But if you create your own custom overlay, it will not be included in the initramfs.

14

Do also keep in mind, I’m talking about recent images. The older images that use 3.8.x do not need this done that I’m aware of. I’ve been using 4.x for a long time now, and I do not recall off hand.

15

Hi,
I’m having an issue with a SPI device that works with Kernel 3.8. but not with the 4.4.x series. I have also tried the latest one 4.4.41-ti-r82.
The device exists in both cases and I cannot think of a reason.
Can you give me a hint what I might try to debug it?
I tried the SPI loopback test from the kernel code and it seems to work in both cases.
BG, Thomas