1-wire on BB Blue

GoogleGroups
1

Hi,

I have several questions and hope someone can help. I’m trying to figure out how to configure ports on a beaglebone, generically. I haven’t found a good site which describes any of this thanks to the relatively recent changes in how device tree overlays are handled. I’d like to be able to configure ports differently from how they ship, so I’m looking to develop generic understanding as well as to figure out my specific problem on how to configure a port differently:

I’m trying to configure 1-wire on a Beaglebone Blue using the latest iot build on beaglebone.org. The BB Blue has 6 free GPIOs which are pinned to connectors. Of the 6, looking at the dtb-rebuilder repo it seems that GPIO1_25 has the fewest number of hits there so perhaps this one is least likely to be used elsewhere. I’ve modified a dts file from bb-overlays.org repository, and guessed my way to the correct offset value for what I think should be PIN57 and produced and compiled the following dts:

/dts-v1/;
/plugin/;

/ {
compatible = “ti,beaglebone”, “ti,beaglebone-black”, “ti,beaglebone-green”;

/* identification */
part-number = “BB-W1-P1.25”;
version = “00A0”;

/* state the resources this cape uses /
exclusive-use =
/ the pin header uses */
“P1.25”;

/*

  • Free up the pins used by the cape from the pinmux helpers.
    */
    fragment@0 {
    target = <&ocp>;
    overlay {
    P1_25_pinmux { status = “disabled”; };
    };
    };

fragment@1 {
target = <&am33xx_pinmux>;
overlay {

dallas_w1_pins: pinmux_dallas_w1_pins {
pinctrl-single,pins = <
0x0e4 0x37

;
};
};
};

fragment@2 {
target-path=“/”;
overlay {

onewire {
status = “okay”;
pinctrl-names = “default”;
pinctrl-0 = <&dallas_w1_pins>;

compatible = “w1-gpio”;
gpios = <&gpio1 25 0>;
};
};
};
};

In compiling this I get the following warnings, which don’t mean much to me yet:
dtc -O dtb -o BB-W1-P1.25-00A0.dtb BB-W1-P1.25-00A0.dts -@

BB-W1-P1.25-00A0.dtb: Warning (unit_address_vs_reg): Node /fragment@0 has a unit name, but no reg property
BB-W1-P1.25-00A0.dtb: Warning (unit_address_vs_reg): Node /fragment@1 has a unit name, but no reg property
BB-W1-P1.25-00A0.dtb: Warning (unit_address_vs_reg): Node /fragment@2 has a unit name, but no reg property

In my /boot/uEnv.txt I have made the following changes, on the suspicion that there may be some sharing of the pin with video features:
uboot_overlay_addr0=/home/debian/BB-W1-P1.25-00A0.dtb
disable_uboot_overlay_video=1

Finally:
root@beaglebone:/opt/scripts/tools# ./version.sh
git:/opt/scripts/:[1aa73453b2c980b75e31e83dab7dd8b6696f10c7]
eeprom:[A335BNLTBLA21722EL002623]
model:[TI_AM335x_BeagleBone_Blue]
dogtag:[BeagleBoard.org Debian Image 2018-10-07]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 2018.09-00002-g0b54a51eee]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2017.05-rc1-00002-g35aecb]:[location: dd MBR]
kernel:[4.14.71-ti-r80]
nodejs:[v6.15.0]
device-tree-override:[uboot_overlay_addr0=/home/debian/BB-W1-P1.25-00A0.dtb]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_addr0=/home/debian/BB-W1-P1.25-00A0.dtb]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade ]
pkg:[bb-cape-overlays]:[4.4.20181120.0-0rcnee0~stretch+20181120]
pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]
pkg:[kmod]:[23-2rcnee1~stretch+20171005]
pkg:[librobotcontrol]:[1.0.4-git20181123.0-0rcnee0~stretch+20181124]
pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~stretch+20180328]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep admin spi tisdk weston-launch xenomai]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet]
dmesg | grep pinctrl-single
[ 1.089162] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
[ 30.947099] pinctrl-single 44e10800.pinmux: pin PIN57 already requested by ocp:helper; cannot claim for onewire
[ 31.202623] pinctrl-single 44e10800.pinmux: pin-57 (onewire) status -22
[ 31.454403] pinctrl-single 44e10800.pinmux: could not request pin 57 (PIN57) from group pinmux_dallas_w1_pins on device pinctrl-single
dmesg | grep gpio-of-helper

I’m still new with the Beaglebone/linux configuration, sorry if any of these things demonstrate my stupidity. Thanks in advance for any help.

Best,

Jim

2

Hi all,

Perhaps someone understands the device tree overlay file format better than I do (I sure hope so). Again, my purpose here is to be able to use a 1-wire interface on the Beaglebone Blue using one of the 6 GPIO pins connected to a header. I have selected GPIO1_25 which seems to be otherwise unencumbered, and I believe that maps to PIN57.

I’m currently trying to understand the following sections of the dts file format:

/* state the resources this cape uses /
exclusive-use =
/ the pin header uses */
“P9.12”;

/*

  • Free up the pins used by the cape from the pinmux helpers.
    */
    fragment@0 {
    target = <&ocp>;
    overlay {
    P9_12_pinmux { status = “disabled”; };
    };
    };

First, the exclusive-use list can include multiple features. According to the Adafruit BBB Device Tree manual, this can include both pins and hardware features (like a uart). I don’t see where it ties pin headers to anything else, so it seems I can use something arbitrary here and it won’t immediately break anything (though it will eventually cause me problems if that same device is used elsewhere but has a different correct name). I intend to use the following line: exclusive-use = “P1.25”;

Second, the fragment@0 pinmux statement P9_12_pinmux… where does that thing come from? I would like to use something along the lines of P1_25_pinmux if it existed, but in all of bb.org-overlays there is no use of P1_25, because on the non-blue boards that pin doesn’t come out anywhere. So where is this defined so that I can create a new one, or just write it in manually with the correct format?

Ultimately all I really want is to get the 1-wire driver to talk to a different pin but I also want to understand what is going on here. My final target will be both a Pocketbeagle and a Green/Black board and I need to be able to reconfigure UARTs and I2C ports to do that, so I’d like to know what I am up to when I change these files.

Thanks in advance for any words of advice.

Best,

Jim

3

Hello,

Use this: https://debian.beagleboard.org/images/bone-debian-9.5-iot-armhf-2018-10-07-4gb.img.xz which can be found at bbb.io/latest-images. You can then use config-pin to set up your “pinmuxing.”

Seth

P.S. Use this cmd for P9.13 to use GPIO functionality: sudo config-pin P9.13 gpio.

4

Hi Seth,

I’m glad to hear from you. I am already using the latest-images iot build. But I’m trying to learn how to reconfigure the 1-wire interface which has a dts file configured to use P9.22 on the beaglebone black, and move it to a different GPIO pin on the beaglebone blue. P9.13 (which I think lines up to GPIO0_31) doesn’t exist on the blue.

Any idea how to get a list of pins supported by config-pin? Or how to tie a pin to the 1-Wire linux driver? Or if I’m completely barking up the wrong tree?

Anyway, you’re making me think of something else. The pin I think I want, GPIO1_25, on the Beaglebone Black happens to be P8.30. Maybe config-pin works with that port, which would maybe save me a reboot trying to find out which things might work in a dts file… but alas, same error results (PIN57 owned by ocp:helper).

Here’s what I have for a dts file right now:

$ cat /opt/source/bb.org-overlays/src/arm/BB-W1-P1.25-jim-00A0.dts
/dts-v1/;
/plugin/;

/ {
compatible = “ti,beaglebone”, “ti,beaglebone-blue”;

/* identification */
part-number = “BB-W1-P9.12”;
version = “00A0”;

/* state the resources this cape uses /
exclusive-use =
/ the pin header uses */
“P8.30”;

/*

  • Free up the pins used by the cape from the pinmux helpers.
    */
    fragment@0 {
    target = <&ocp>;
    overlay {
    P8_30_pinmux { status = “disabled”; };
    };
    };

fragment@1 {
target = <&am33xx_pinmux>;
overlay {

dallas_w1_pins: pinmux_dallas_w1_pins {
pinctrl-single,pins = <
0x0e4 0x37

;
};
};
};

fragment@2 {
target-path=“/”;
overlay {

onewire {
status = “okay”;
pinctrl-names = “default”;
pinctrl-0 = <&dallas_w1_pins>;

compatible = “w1-gpio”;
gpios = <&gpio1 25 0>;
};
};
};
};

5

Hi Jim!

I cannot answer your questions, but perhaps point you to a further solution: Some years ago I needed multiple Dallas temperature sensors input for a project, and tested the kernel driver. I found out that (at this time) the kernel driver doesn’t support simultaneous measurements from multiple sensors, and therefor doesn’t meet my needs. So I developed my own driver, which can be found at https://github.com/DTJF/libpruw1. This driver runs on a PRU and depends on libpruio (at the other PRU) for pinmuxing. You can choose any GPIO pin for the W1 bus.

libpruio is prepared for the BBBlue, just use the matching header file: https://github.com/DTJF/libpruio/blob/master/src/c_include/pruio_pins_blue.h. So it should be possible to get it running, but t’is untested jet, since I have no Blue hardware.

Regards