GPIOs not set when overlay applied

GoogleGroups
1

Following the instructions set out by Derek Molloy, I'm trying to configure the pullups on some GPIOs. In particular, I want to disable them on GPIO0_27/P8_17. I'm trying to set the mode to 0x2f, but it always remains at the default 0x27.

Here's my .dts: http://pastebin.com/xk0TtvJU

# cat $PINS | grep 82c
pin 11 (44e1082c) 00000027 pinctrl-single

# echo podtique > /sys/devices/bone_capemgr.9/slots

dmesg shows:

[31799.644215] bone-capemgr bone_capemgr.9: part_number 'podtique', version 'N/A'
[31799.644400] bone-capemgr bone_capemgr.9: slot #10: generic override
[31799.644447] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 10
[31799.644495] bone-capemgr bone_capemgr.9: slot #10: 'Override Board Name,00A0,Override Manuf,podtique'
[31799.644760] bone-capemgr bone_capemgr.9: slot #10: Requesting part number/version based 'podtique-00A0.dtbo
[31799.644809] bone-capemgr bone_capemgr.9: slot #10: Requesting firmware 'podtique-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
[31799.644885] bone-capemgr bone_capemgr.9: slot #10: dtbo 'podtique-00A0.dtbo' loaded; converting to live tree
[31799.645261] bone-capemgr bone_capemgr.9: slot #10: #2 overlays
[31799.645743] bone-capemgr bone_capemgr.9: slot #10: Applied #2 overlays.

# cat $SLOTS
0: 54:PF---
1: 55:PF---
2: 56:PF---
3: 57:PF---
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-ADC
10: ff:P-O-L Override Board Name,00A0,Override Manuf,podtique

# cat $PINS | grep 82c
pin 11 (44e1082c) 00000027 pinctrl-single

Unfortunately, the pin mode hasn't changed. Any ideas?

# uname -a
Linux arm 3.8.13-bone68 #1 SMP Sat Nov 22 02:12:03 UTC 2014 armv7l GNU/Linux

Thanks!

2

After re-tracing my steps, I'm still no closer to figuring this out. One thing I did notice is that the first time I tried to apply the overlay, the log showed a failure and a second attempt:

[31360.880445] bone-capemgr bone_capemgr.9: part_number 'podtique', version 'N/A'
[31360.880629] bone-capemgr bone_capemgr.9: slot #8: generic override
[31360.880675] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 8
[31360.880722] bone-capemgr bone_capemgr.9: slot #8: 'Override Board Name,00A0,Override Manuf,podtique'
[31360.880984] bone-capemgr bone_capemgr.9: slot #8: Requesting part number/version based 'podtique-00A0.dtbo
[31360.881031] bone-capemgr bone_capemgr.9: slot #8: Requesting firmware 'podtique-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
[31360.917917] bone-capemgr bone_capemgr.9: failed to load firmware 'podtique-00A0.dtbo'

[31428.883458] bone-capemgr bone_capemgr.9: part_number 'podtique', version 'N/A'
[31428.883639] bone-capemgr bone_capemgr.9: slot #9: generic override
[31428.883686] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 9
[31428.883734] bone-capemgr bone_capemgr.9: slot #9: 'Override Board Name,00A0,Override Manuf,podtique'
[31428.883989] bone-capemgr bone_capemgr.9: slot #9: Requesting part number/version based 'podtique-00A0.dtbo
[31428.884037] bone-capemgr bone_capemgr.9: slot #9: Requesting firmware 'podtique-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
[31428.890324] bone-capemgr bone_capemgr.9: slot #9: dtbo 'podtique-00A0.dtbo' loaded; converting to live tree
[31428.890721] bone-capemgr bone_capemgr.9: slot #9: #2 overlays
[31428.891182] bone-capemgr bone_capemgr.9: slot #9: Applied #2 overlays.

Then I removed it and tried again.

Also, when it says "Using override eeprom data at slot 8," what does that mean? I have a physical cape attached, a SparkFun prototype cape with EEPROM, but the EEPROM is unflashed (I assume). If I can get this manual overlay to work, I'll next try to flash the EEPROM with the right stuff to get it all loaded at boot.

Robert, I have yet to try the steps you gave me earlier for building a new kernel with the USB changes for audio. I don't know if that kernel would make a difference?

Thanks!

3

After re-tracing my steps, I'm still no closer to figuring this out. One thing I did notice is that the first time I tried to apply the overlay, the log showed a failure and a second attempt:

[31360.880445] bone-capemgr bone_capemgr.9: part_number 'podtique', version 'N/A'
[31360.880629] bone-capemgr bone_capemgr.9: slot #8: generic override
[31360.880675] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 8
[31360.880722] bone-capemgr bone_capemgr.9: slot #8: 'Override Board Name,00A0,Override Manuf,podtique'
[31360.880984] bone-capemgr bone_capemgr.9: slot #8: Requesting part number/version based 'podtique-00A0.dtbo
[31360.881031] bone-capemgr bone_capemgr.9: slot #8: Requesting firmware 'podtique-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
[31360.917917] bone-capemgr bone_capemgr.9: failed to load firmware 'podtique-00A0.dtbo'

[31428.883458] bone-capemgr bone_capemgr.9: part_number 'podtique', version 'N/A'
[31428.883639] bone-capemgr bone_capemgr.9: slot #9: generic override
[31428.883686] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 9
[31428.883734] bone-capemgr bone_capemgr.9: slot #9: 'Override Board Name,00A0,Override Manuf,podtique'
[31428.883989] bone-capemgr bone_capemgr.9: slot #9: Requesting part number/version based 'podtique-00A0.dtbo
[31428.884037] bone-capemgr bone_capemgr.9: slot #9: Requesting firmware 'podtique-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
[31428.890324] bone-capemgr bone_capemgr.9: slot #9: dtbo 'podtique-00A0.dtbo' loaded; converting to live tree
[31428.890721] bone-capemgr bone_capemgr.9: slot #9: #2 overlays
[31428.891182] bone-capemgr bone_capemgr.9: slot #9: Applied #2 overlays.

Then I removed it and tried again.

Also, when it says "Using override eeprom data at slot 8," what does that mean? I have a physical cape attached, a SparkFun prototype cape with EEPROM, but the EEPROM is unflashed (I assume). If I can get this manual overlay to work, I'll next try to flash the EEPROM with the right stuff to get it all loaded at boot.

The capemgr in v3.8.x is setup to read the eeprom, so when we echo a
custom overlay... It's just very vocal that it's just not using the
eeprom.. Nothing to worry about..

Robert, I have yet to try the steps you gave me earlier for building a new kernel with the USB changes for audio. I don't know if that kernel would make a difference?

It might... Disabling DMA mode seems to help some usb devices.

On every kernel release, ti keep's adding more workarounds, so at some
point, dma on the musb will be stable..

Regards,

4

Slots 0-3 are reserved for capes auto-detected via their EEPROM values.
If your EEPROM is unprogrammed, nothing will load for that slot, and
you will need to manually load the overlay (as you are trying to do).
Slot 4 is for the on-board eMMC, and slot 5 is for HDMI. If you disable
the HDMI (with audio), slot 6 becomes the HDMIN cape (HDMI without audio).

Any manually loaded capes will start at the next available slot number
and increment from there.

5

Sorry, I meant, do you think the later kernel will have any effect on my efforts to configure the GPIO pullups that I can't seem to get to work with 3.8.13 bone68?

6

Well...

With v3.14.x and the dtb-rebuilder, you could just hardcode your gpio
settings and not worry about going thru the overlay interface..

The overlay is nice for dynamic changes, BUT if your hardware design
is choosen, why not just hardcode the dtb..

Regards,

7

I suppose for development purposes it makes it easier, not having to reboot, right? I mean, this should work, I think, and I must be doing something wrong. If I can't figure it out here, it might be that much harder with dtb-rebuilder. Not to mention, I might have audio issues.

Unfortunately, I'm running out of time to get this finished up before I have to present it (basically, I have until Thursday), and I still have to get some PRU code working, and I don't yet know if I'll have to change pinmuxing via DTB for that.

8

Hmm, some additional information. It seems I can set some of the pins, some of the time, and after that, I have to reboot.

For example, I grabbed Derek Molloy's example straight from his book, which sets P9_11's (at address 870) mode to 0x07. I can set that to 0x0f, but only once after reboot. If I change my .dts, unload the slot, and re-load it, it doesn't change.

But if I try to do the same thing with my own .dts, for pin P8_17 (0x82c), changing it to 0x0f or 0x37, it doesn't change (it stays at the default mode of 0x27).

As far as I can tell, this is an pin that's not in conflict with any other use.

9

So with dtb-rebuilder (wip: v3.19.x branch)

You can define that pin as:

BONE_P8_17 0x0f
or:
BONE_P8_17 0x3f

For example here's where i set the pinmux for can0:

https://github.com/RobertCNelson/dtb-rebuilder/blob/3.19.x/src/arm/am335x-bone-pinmux-can0.dtsi

The base "am335x-boneblack.dts"

https://github.com/RobertCNelson/dtb-rebuilder/blob/3.19.x/src/arm/am335x-boneblack.dts#L43

has every option available, you just have to uncomment different
peripherals/pinmux's..

cape-universal will be enabled again in a few days, so all the
'peripherals" will be enabled again, and you can use Charles's
pin-config utility to change the pinmux in userspace.

Regards,

10

So, I set up dtb-rebuilder for 3.14, and it worked, in that I was able to get my ADC and GPIO pins accessible, but I'm still not able to turn off the pullups on my output pin. I decided to try to use your BONE_P8_17 macro in case I was wrong about the address offset, but realized that's only in 3.19, and I have it right, anyway:

  0x02C (PIN_OUTPUT | MUX_MODE7) /* 0x02C gpio0_27 */

Also, there's the other issue I posted about having to do with rapidly reading sysfs and hanging.