Upgrading One-Wire cape

I’m not able to get a cape that was working on the older OS. I suspect it’s due to the 1-Wire changes in the newer kernel and OS.

Running this:
debian@ebb:/opt/scripts/device/bone$ sudo ./show-pins.pl
Produces this:
P8.11 13 R12 fast rx up 7 gpio 1.13 onewire (pinmux_dallas_w1_pins)

I have this cape installed which used to work with the older 3.7 kernel:
debian@ebb:/sys/bus/i2c/devices$ cat 2-0057/eeprom | hexdump -C
00000000 aa 55 33 ee 41 30 4f 6e 65 57 69 72 65 20 70 6c |.U3.A0OneWire pl|
00000010 75 73 20 43 41 4e 62 75 73 00 00 00 00 00 00 00 |us CANbus…|
00000020 00 00 00 00 00 00 30 30 41 30 41 75 74 6f 41 72 |…00A0AutoAr|
00000030 74 69 73 61 6e 73 20 49 6e 63 42 42 2d 57 31 2d |tisans IncBB-W1-|
00000040 50 38 2e 31 31 00 00 00 00 00 00 00 00 00 00 00 |P8.11…|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…|
00000130 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |…|

The DTS file was created from a 2012 example.
* Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
* Modified  by Russell Senior from the weather cape's DTS file.
* Minor formatting by C W Rose.
/ {
    compatible = "ti,beaglebone", "ti,beaglebone-black";
    part-number = "BB-W1-P8.11";
    version = "00A0";
    exclusive-use = "P8.11";
    fragment@0 {
        target = <&am33xx_pinmux>;
        __overlay__ {
             bb_w1_pins: pinmux_bb_w1_pins {
                 pinctrl-single,pins =  <0x34 0x37 /* gpmc_ad13.gpio1_13, OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE7 - w1-gpio */ >;
    fragment@1 {
        target = <&ocp>;
        __overlay__ {
            onewire@0 {
                status          = "okay";
                compatible      = "w1-gpio";
                pinctrl-names   = "default";
                pinctrl-0       = <&bb_w1_pins>;
                gpios = <&gpio1 13 0>;

But doesn’t really match the one on the new OS for P9.12.
Which inside actually has this 00A2 rather than 00A1:
BB-W1-P9.12-00A2 = TIMESTAMP;

So do I just change the pins inside the P9.12 for P8.11 as per this tutorial?


is onewire module loaded?


That’s “ONLY” used to generate this helper…

beagle-version | grep UBOOT
UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
UBOOT: Loaded Overlay:[BB-ADC-00A0.kernel]
UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0.kernel]
UBOOT: Loaded Overlay:[BB-HDMI-TDA998x-00A0.kernel]


Blockquote Doesn’t appear to be loaded.
debian@ebb:~$ sudo beagle-version | grep UBOOT
[sudo] password for debian:
UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-14-TI-00A0]
UBOOT: Loaded Overlay:[BB-ADC-00A0.bb.org-overlays]
UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0.bb.org-overlays]
UBOOT: Loaded Overlay:[BB-HDMI-TDA998x-00A0]

Blockquote From the /boot/uEnv.txt
###Custom Cape

And it’s in that folder:

debian@ebb:~$ ls /lib/firmware/W1
/lib/firmware/BB-W1-P8.11-00A0.dtbo /lib/firmware/BB-W1-P9.12-00A0.dtbo

The .dts file was not in the folder with all the others. Don’t know if that matters. Or if the upgrade therefore missed something?

Yeap, that’s the whole point of this section:

/ {
	 * Helper to show loaded overlays under: /proc/device-tree/chosen/overlays/
	fragment@0 {
		__overlay__ {

			chosen {
				overlays {
					BB-W1-P9.12-00A2 = __TIMESTAMP__;

Otherwise, you get to watch boot over serial to see if it actually loaded… :wink:

I’d expect that load properlly, does dmesg show anything?

Run the full:

sudo beagle-version

So we can see if there is a pinmux issue…


From dmesg

[ 115.639050] Driver for 1-wire Dallas network protocol.
[ 115.712863] gpio-45 (P8_11): enforced open drain please flag it properly in DT/ACPI DSDT/board file

And here’s the full beagle-version. It looks like it did detect the EEROM on the cape. It’s got to be something really dumb.



debian@ebb:~$ sudo beagle-version
[sudo] password for debian:
dogtag:[BeagleBoard.org Debian Image 2018-10-07]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot SPL 2018.09-00002-g0b54a51eee (Sep 10 2018 - 19:41:39 -0500)]:[location: dd MBR]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 2018.09-00002-g0b54a51eee]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot SPL 2019.04-00002-gbb4af0f50f (Jul 08 2019 - 11:44:39 -0500)]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2019.04-00002-gbb4af0f50f]:[location: dd MBR]
UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-14-TI-00A0]
UBOOT: Loaded Overlay:[BB-ADC-00A0.bb.org-overlays]
UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0.bb.org-overlays]
UBOOT: Loaded Overlay:[BB-HDMI-TDA998x-00A0]
/boot/uEnv.txt Settings:
pkg check: to individually upgrade run: [sudo apt install --only-upgrade <pkg>]
groups:[debian : debian adm kmem dialout cdrom floppy sudo 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 uboot_detected_capes=BB-W1-P8.11, coherent_pool=1M net.ifnames=0 quiet]
dmesg | grep remote
[ 115.979127] remoteproc remoteproc0: wkup_m3 is available
[ 116.049069] remoteproc remoteproc0: powering up wkup_m3
[ 116.049101] remoteproc remoteproc0: Booting fw image am335x-pm-firmware.elf, size 217148
[ 116.049385] remoteproc remoteproc0: remote processor wkup_m3 is now up
[ 122.722991] remoteproc remoteproc1: 4a338000.pru is available
[ 122.802055] remoteproc remoteproc2: 4a334000.pru is available
dmesg | grep pru
[ 122.722991] remoteproc remoteproc1: 4a338000.pru is available
[ 122.723205] pru-rproc 4a338000.pru: PRU rproc node pru@38000 probed successfully
[ 122.802055] remoteproc remoteproc2: 4a334000.pru is available
[ 122.802254] pru-rproc 4a334000.pru: PRU rproc node pru@34000 probed successfully
dmesg | grep pinctrl-single
[ 1.326444] pinctrl-single 44e10800.pinmux: 142 pins, size 568
dmesg | grep gpio-of-helper
[ 1.339869] gpio-of-helper ocp:cape-universal: ready
Bus 001 Device 004: ID 046d:c534 Logitech, Inc. Unifying Receiver
Bus 001 Device 003: ID 0403:ffa8 Future Technology Devices International, Ltd
Bus 001 Device 002: ID 0bda:5411 Realtek Semiconductor Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub



okay that’s new:

Looking at:


We might have to change the pin configuration in our W1 overlay…

gpios = <&foo 42 GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN>; in a

Thus maybe…

                gpios = <&gpio1 13 0>
                gpios = <&gpio1 13 GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN>





Thus maybe…

                gpios = <&gpio1 13 0>
                gpios = <&gpio1 13 GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN>

I’m not sure about the GPIO ACTIVE HIGH even though it has a value of zero. Open drain are by nature active low since you can have multiple devices on the bus at the same time. But selecting GOIO_ACTIVE_LOW would not match the req 0 value. More logical to leave it out.
Also GPIO_OPEN_DRAIN has a 4 in the GPIO_LINE_OPEN_DRAIN so that makes <&gpio 13 0> incorrect.

There’s also a difference in your fragment@2 compared to my fragment@0

	fragment@2 {
		target = <&am33xx_pinmux>;
		__overlay__ {

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

Mine has a few things different.

   fragment@0 {
        target = <&am33xx_pinmux>;
        __overlay__ {
             bb_w1_pins: pinmux_bb_w1_pins {
                 pinctrl-single,pins =  <0x34 0x37 /* gpmc_ad13.gpio1_13, OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE7 - w1-gpio */ >;

You say dallas_, I say bb_. Does it matter?

Your “BONE_P9_12 0x37” is much more readable than my “0x34 0x37”. Would be better for me to have “BONE_P8_11 0x37”

Maybe my DTS file just needs to be recompiled by the current OS tools in order for it to work.

Oh and is
required if the EEROM has the information?

Hi John,

do you know the libpruw1 one-wire driver:


It configures the GPIO pin per custom software, no device tree magic necessary.


Thanks for the suggestion.
I’ll need it to work with Lazarus. But in either case there’s the bigger issue just getting the cape with the EEROM to work properly. By the book so to speak.

I found the actual dts and dtbo from 2019 that I used the last time this all worked.
BB-W1-P8.11-00A0.dts (1.3 KB)
As the comments at the front show, I started with Robert’s P9.12 version. The dtbo file is located in /lib/firmware/
So I’ll change this one to have the GPIO_OPEN_DRAIN and see what happens. If I can figure out how to compile it again.

From dmesg after following directions at bottom of page to make and install it.

bone$ cd /opt/source/bb.org-overlays
bone$ make && sudo make install
[  115.300859] Driver for 1-wire Dallas network protocol.
[  115.483214] w1_master_driver w1_bus_master1: Attaching one wire slave 22.000000219f58 crc 3d

And then

debian@ebb:/sys/class$ cd hwmon
debian@ebb:/sys/class/hwmon$ ls
debian@ebb:/sys/class/hwmon$ cat */name
debian@ebb:/sys/class/hwmon$ cd hwmon0
debian@ebb:/sys/class/hwmon/hwmon0$ ls
device  name  power  subsystem  temp1_input  uevent
debian@ebb:/sys/class/hwmon/hwmon0$ cat temp1_input

The temperature in my office is 21.125 degrees C.
So it’s working. Looks like the GPIO_OPEN_DRAIN is now required when back in 2019 it wasn’t


And here’s the Python program from 2019 now with the main gauge working again.
Screenshot from 2021-10-07 00-10-29
DallasTemperatureMeter.py (5.9 KB)

So I think I can finish this thread off with the following information. I’ve included the new .dts file for the P8.11.
BB-W1-P8.11-00A0.dts (1.4 KB)
In the previous message I showed a Python application that reads the sensor. Now here’s a Lazarus FPC project that periodically polls the sensor and reports the value. The query buttons lets a user select the path to the device.
Screenshot from 2021-10-07 19-50-48
Here’s the source code for it.
OneWireTest.zip (125.8 KB)
The 7 segment display comes from: Rack Controls for Lazarus · Luca Olivetti

I also commented out the /boot/uEnv.txt line :

which made no difference as shown below after a sudo reboot.

debian@ebb:/sys/class/hwmon/hwmon0/device$ ls
driver  hwmon  id  name  power  subsystem  uevent  w1_slave
debian@ebb:/sys/class/hwmon/hwmon0/device$ cat w1_slave
4d 01 4b 46 7f ff 03 10 d8 : crc=d8 YES
4d 01 4b 46 7f ff 03 10 d8 t=20812

Anyway the previous postings show how to install and compile the dts so I think that’s it. Thanks to Robert for the help.

P.S. Forgot to include a picture of the DS1822 One WIre sensor which on this board was used to create a unique serial # and measure the temperature inside the enclosure. It’s the black little TO92 package on the round LED board. On the Right is a small I2C display and on the left an SPI based Thermocouple sensor which also doesn’t work anymore after the OS upgrade. But that’s for a different thread.