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 |…|
*
00008000
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.
*/
/dts-v1/;
/plugin/;
/ {
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.
BB-W1-P9.12-00A0.dts
Which inside actually has this 00A2 rather than 00A1:
BB-W1-P9.12-00A2 = TIMESTAMP;
[ 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.
Thanks
John
debian@ebb:~$ sudo beagle-version
[sudo] password for debian:
eeprom:[A335BNLT00C02716BBBK0E8D]
model:[TI_AM335x_BeagleBone_Black]
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]
kernel:[4.19.94-ti-r68]
nodejs:[v10.24.0]
/boot/uEnv.txt Settings:
uboot_overlay_options:[enable_uboot_overlays=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]
uboot_overlay_options:[dtb_overlay=/lib/firmware/BB-W1-P8.11-00A0.dtbo]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade <pkg>]
pkg:[bb-cape-overlays]:[4.14.20210821.1-0~stretch+20210923]
pkg:[bb-customizations]:[1.20210810.1-0~stretch+20210810]
pkg:[bb-usb-gadgets]:[1.20210923.0-0~buster+20210923]
pkg:[bb-wl18xx-firmware]:[1.20210922.1-0~stretch+20210922]
pkg:[kmod]:[26-1]
pkg:[librobotcontrol]:[1.0.5-git20200715.0-0~stretch+20200716]
pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~stretch+20200305]
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
lsusb
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
END
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
@DTJF
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.
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
hwmon0
debian@ebb:/sys/class/hwmon$ cat */name
w1_slave_temp
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
21125
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
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.
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 : #dtb_overlay=/lib/firmware/BB-W1-P8.11-00A0.dtbo
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
debian@ebb:/sys/class/hwmon/hwmon0/device$
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.
