CLKOUT2 access in RCN 3.12 kernel?

I’ve been successfully using the Arago 3.2.0 kernel in a Beaglebone (white) project that uses GPMC.
I’d like to move to a more recent kernel, thinking that there are realtime fixes in 3.8+ that might help realtime performance.
I’ve been able to stop using omap_mux and move to device tree.

My code runs on 3.8 kernel for a little while, but then I get an oops that locks up everything. (but that’s a topic for a different thread…) So, (thinking that’s a kernel bug that may have been fixed in a more recent kernel,) I’m trying 3.12 instead.

I’m able to get an SD card updated to 3.12 with
wget http://rcn-ee.net/deb/saucy-armhf/v3.12.6-bone11/install-me.sh
sudo bash ./install-me.sh
and can compile my device tree file for it,
but when I run my device tree file I get

[ 110.746390] pinctrl-single 44e10800.pinmux: pin 44e109b4.0 already requested
by ; cannot claim for 50000000.gpmc
[ 110.758839] pinctrl-single 44e10800.pinmux: pin-109 (50000000.gpmc) status -22
[ 110.766597] pinctrl-single 44e10800.pinmux: could not request pin 109 (44e109b4.0) from group pinmux_gpmc_pins on device pinctrl-single
[ 110.779699] omap-gpmc 50000000.gpmc: Error applying setting, reverse things back

– which, as near as I can decipher, is telling me that something else (44e10800.pinmux, apparently)
has grabbed clkout2 and won’t let me use it.
I’m just not sure how to find this culprit and make it give me my pin back.

Any suggestions?

I’m guessing that this is arch/arm/boot/dts/am335x-evm.dts.
In 3.8 there is no mention of clkout2, the pinmux grabs lcd_pins_s0
In 3.12 in a similar-looking section, lcd_pins_s0 is replaced by clkout2_pin

lots of guessing going on..

What am335x file are you including into your dts? and can you share
the pinmux section of gpmc..

Regards,

Thanks for responding…

I did
grep clkout2 *.dts
in both directories and found that clkout2 didn’t show up in the 3.8 but did show up in 3.12
in 3.12 it shows up in am335x-evm.dts and also am335x-evmsk.dts… (and dove-cubox.dts but I don’t think that is related)

I also just noticed that it also shows up in am335x-bone-common.dtsi, (3.12) which now seems more likely to be the beaglebone related file.

Here’s that chunk from my device tree file…

fragment@0 {
target = <&am33xx_pinmux>;
overlay {
gpmc_pins: pinmux_gpmc_pins {
pinctrl-single,pins = <
/* 0x20 = Fast, RX_enabled, pullup, pullup_enable, mode 0 /
0x000 0x20 /
gpmc_ad0.gpmc_ad0 MODE0 | INPUT | PULLUP /
0x004 0x20 /
gpmc_ad1.gpmc_ad1 MODE0 | INPUT | PULLUP /
0x008 0x20 /
gpmc_ad2.gpmc_ad2 MODE0 | INPUT | PULLUP /
0x00C 0x20 /
gpmc_ad3.gpmc_ad3 MODE0 | INPUT | PULLUP /
0x010 0x20 /
gpmc_ad4.gpmc_ad4 MODE0 | INPUT | PULLUP /
0x014 0x20 /
gpmc_ad5.gpmc_ad5 MODE0 | INPUT | PULLUP /
0x018 0x20 /
gpmc_ad6.gpmc_ad6 MODE0 | INPUT | PULLUP /
0x01C 0x20 /
gpmc_ad7.gpmc_ad7 MODE0 | INPUT | PULLUP /
0x020 0x20 /
gpmc_ad8.gpmc_ad8 MODE0 | INPUT | PULLUP /
0x024 0x20 /
gpmc_ad9.gpmc_ad9 MODE0 | INPUT | PULLUP /
0x028 0x20 /
gpmc_ad10.gpmc_ad10 MODE0 | INPUT | PULLUP /
0x02C 0x20 /
gpmc_ad11.gpmc_ad11 MODE0 | INPUT | PULLUP /
0x030 0x20 /
gpmc_ad12.gpmc_ad12 MODE0 | INPUT | PULLUP /
0x034 0x20 /
gpmc_ad13.gpmc_ad13 MODE0 | INPUT | PULLUP /
0x038 0x20 /
gpmc_ad14.gpmc_ad14 MODE0 | INPUT | PULLUP /
0x03C 0x20 /
gpmc_ad15.gpmc_ad15 MODE0 | INPUT | PULLUP */

0x078 0x04 /* gpmc_ben1.gpmc_dir MODE4 | OUTPUT /
0x080 0x00 /
gpmc_cscn1.gpmc_cscn1 MODE0 | OUTPUT /
0x08C 0x00 /
gpmc_clk.gpmc_clk MODE0 | OUTPUT /
0x090 0x00 /
gpmc_advn_ale.gpmc_advn_ale MODE0 | OUTPUT /
0x094 0x00 /
gpmc_oen_ren.gpmc_oen_ren MODE0 | OUTPUT /
0x098 0x00 /
gpmc_wen.gpmc_wen MODE0 | OUTPUT /
0x09C 0x00 /
gpmc_ben0_cle.gpmc_ben0_cle MODE0 | OUTPUT /
0x1b4 0x03 /
xdma_event_intr1.clkout2 MODE3 | OUTPUT */

;
};
};
};

I used BB-BONE-CAM3 as a starting point but yes, I’m mostly guessing at what this stuff means.
My next guess is that the last line above is in the wrong section… clkout2 is not a gpmc pin.

I don’t have any /include/ lines in my file… just
compatible = “ti,beaglebone”, “ti,beaglebone-black”;
from the CAM3 file I modified.

I set my issue aside for a while (the 3.2 kernel is working okay for me now…)
However, I did come across this link that discusses what changed in beaglebone device trees from 3.8 to 3.12.
I figured it might be interesting reading for others as well.

http://www.thing-printer.com/converting-device-tree-overlays-kernel-3-12/

I seems that what you are trying to do is to setup GPMC access on the BeagleBone Black using kernel 3.12.x. The steps to do this are as follows:

(1) You must boot using an external micro SDHC card because the internal eMMC must be disabled
(2) Disable eMMC and HDMI in uEnv.txt by adding optargs=capemgr.disable_partno=BB-BONE-EMMC-2G,BB-BONELT-HDMI,BB-BONELT-HDMIN
(3) After booting cape manager will still load both capes. The must be removed manually.
(4) In the sources of kernel 3.12.x we must modify /arch/arm/boot/dts/am335x-boneblack.dts to free up the reset pin for the eMMC device. This is done by changing status from “ok” to disabled in section &mmc2
(5) It should now be possible to load your custom .dts file without any warnings

Unfortunately, the GPMC is still not working in kernel 3.12. I have tested this using 3.12.8 and 3.12.10. I cannot see any activity on the GPMC signals. The same procedure is working in kernel 3.8.13.

Is there really nobody interested in using the GPMC on the BeagleBone Black?

Most people are still on the 3.8 kernel.

Gerald

I’m definitely interested!

Thank you for the reply and the hints.

I assumed my GPMC wasn’t working in 3.12 because of missing CLKOUT2…

Now I see that maybe ALL of my GPMC signals are dead…?

(I’ll have to break out the scope and double check that…)

Sounds like they may not setup properly in the DTS file.

Gerald

There are two files which a relevant in this case: am335x-boneblack.dts & am335x-bone-common.dts. Both files have changed. The strange thing is, that the .dts file for my cape loads without any issues. But the GPMC signals seem to be dead. I think nobody has tested this functionality yet for kernel 3.12.