OrangePiZero 3 and w1-gpio for DS18B20

TRay · May 4

I have question.

OZPI v3 has support for hardware DS18B20 thermal sensor via w1-gpio ?

In armbian-config when we got to the “system” section and select “Hardware” is not existing w1-gpio or OZPI v3 has not support for w1-gpio hardware ?

Does not work because there is no device tree file (in the /boot/dtb/allwinner/) and we need to create it ??? like for OZPI v2 ?:

1. Create text file "sun50i-h616-w1-gpio.dts"

/dts-v1/;

/ {

compatible = "xunlong,orangepi-zero2\0allwinner,sun50i-h616";

fragment@0 {

target = <0xffffffff>;

__overlay__ {

w1_pins {

pins = "PC9";

function = "gpio_in";

phandle = <0x01>;

};

fragment@1 {

target-path = [2f 00];

__overlay__ {

onewire@0 {

compatible = "w1-gpio";

pinctrl-names = "default";

pinctrl-0 = <0x01>;

gpios = <0xffffffff 0x02 0x06 0x00>;

status = "okay";

};

__symbols__ {

w1_pins = "/fragment@0/__overlay__/w1_pins";

};

__fixups__ {

pio = "/fragment@0:target:0\0/fragment@1/__overlay__/onewire@0:gpios:0";

};

__local_fixups__ {

fragment@1 {

__overlay__ {

onewire@0 {

pinctrl-0 = <0x00>;

};

2. After you need to compile it, with command "dtc -O dtb -o sun50i-h616-w1-gpio.dtbo sun50i-h616-w1-gpio.dts"

3. Copy it too /boot/dtb/allwinner/overlay/

ag123 · May 4

hi @TRay

I'd like to suggest playing with libgpiod to get familiar with gpiod based gpio access

https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git

https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/

The readme is quite instructive

https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/README

Spoiler


TOOLS
-----

There are currently six command-line tools available:

* gpiodetect - list all gpiochips present on the system, their names, labels
               and number of GPIO lines

* gpioinfo   - list lines, their gpiochip, offset, name, and direction, and
               if in use then the consumer name and any other configured
               attributes, such as active state, bias, drive, edge detection
               and debounce period

* gpioget    - read values of specified GPIO lines

* gpioset    - set values of specified GPIO lines, holding the lines until the
               process is killed or otherwise exits

* gpiomon    - wait for edge events on GPIO lines, specify which edges to watch
               for, how many events to process before exiting, or if the events
               should be reported to the console

* gpionotify - wait for changed to the info for GPIO lines, specify which
               changes to watch for, how many events to process before exiting,
               or if the events should be reported to the console

Examples:

    (using a Raspberry Pi 4B)

    # Detect the available gpiochips.
    $ gpiodetect
    gpiochip0 [pinctrl-bcm2711] (58 lines)
    gpiochip1 [raspberrypi-exp-gpio] (8 lines)

    # Read the info for all the lines on a gpiochip.
    $ gpioinfo -c 1
    gpiochip1 - 8 lines:
     line   0: "BT_ON"          output
     line   1: "WL_ON"          output
     line   2: "PWR_LED_OFF"    output active-low consumer="led1"
     line   3: "GLOBAL_RESET"   output
     line   4: "VDD_SD_IO_SEL"  output consumer="vdd-sd-io"
     line   5: "CAM_GPIO"       output consumer="cam1_regulator"
     line   6: "SD_PWR_ON"      output consumer="sd_vcc_reg"
     line   7: "SD_OC_N"        input

    # Read the info for particular lines.
    $ ./gpioinfo PWR_LED_OFF STATUS_LED_G_CLK GLOBAL_RESET
    gpiochip0 42 "STATUS_LED_G_CLK" output consumer="led0"
    gpiochip1 2 "PWR_LED_OFF"    output active-low consumer="led1"
    gpiochip1 3 "GLOBAL_RESET"   output

    # Read the value of a single GPIO line by name.
    $ gpioget RXD1
    "RXD1"=active

    # Read the value of a single GPIO line by chip and offset.
    $ gpioget -c 0 15
    "15"=active

    # Read the value of a single GPIO line as a numeric value.
    $ gpioget --numeric RXD1
    1

    # Read two values at the same time. Set the active state of the lines
    # to low and without quoted names.
    $ gpioget --active-low --unquoted GPIO23 GPIO24
    GPIO23=active GPIO24=active

    # Set the value of a line and hold the line until killed.
    $ gpioset GPIO23=1

    # Set values of two lines, then daemonize and hold the lines.
    $ gpioset --daemonize GPIO23=1 GPIO24=0

    # Set the value of a single line, hold it for 20ms, then exit.
    $ gpioset --hold-period 20ms -t0 GPIO23=1

    # Blink an LED on GPIO22 at 1Hz
    $ gpioset -t500ms GPIO22=1

    # Blink an LED on GPIO22 at 1Hz with a 20% duty cycle
    $ gpioset -t200ms,800ms GPIO22=1

    # Set some lines interactively (requires --enable-gpioset-interactive)
    $ gpioset --interactive --unquoted GPIO23=inactive GPIO24=active
    gpioset> get
    GPIO23=inactive GPIO24=active
    gpioset> toggle
    gpioset> get
    GPIO23=active GPIO24=inactive
    gpioset> set GPIO24=1
    gpioset> get
    GPIO23=active GPIO24=active
    gpioset> toggle
    gpioset> get
    GPIO23=inactive GPIO24=inactive
    gpioset> toggle GPIO23
    gpioset> get
    GPIO23=active GPIO24=inactive
    gpioset> exit

    # Wait for three rising edge events on a single GPIO line, then exit.
    $ gpiomon --num-events=3 --edges=rising GPIO22
    10002.907638045	rising	"GPIO22"
    10037.132562259	rising	"GPIO22"
    10047.179790748	rising	"GPIO22"

    # Wait for three edge events on a single GPIO line, with time in local time
    # and with unquoted line name, then exit.
    $ gpiomon --num-events=3 --edges=both --localtime --unquoted GPIO22
    2022-11-15T10:36:59.109615508	rising	GPIO22
    2022-11-15T10:36:59.129681898	falling	GPIO22
    2022-11-15T10:36:59.698971886	rising	GPIO22

    # Wait for falling edge events with a custom output format.
    $ gpiomon --format="%e %c %o %l %S" --edges=falling -c gpiochip0 22
    2 gpiochip0 22 GPIO22 10946.693481859
    2 gpiochip0 22 GPIO22 10947.025347604
    2 gpiochip0 22 GPIO22 10947.283716669
    2 gpiochip0 22 GPIO22 10947.570109430
    ...

    # Block until an edge event occurs. Don't print anything.
    $ gpiomon --num-events=1 --quiet GPIO22

    # Monitor multiple lines, exit after the first edge event.
    $ gpiomon --quiet --num-events=1 GPIO5 GPIO6 GPIO12 GPIO17

    # Monitor a line for changes to info.
    $ gpionotify GPIO23
    11571.816473718	requested	"GPIO23"
    11571.816535124	released	"GPIO23"
    11572.722894029	requested	"GPIO23"
    11572.722932843	released	"GPIO23"
    11573.222998598	requested	"GPIO23"
    ...

    # Monitor a line for requests, reporting UTC time and unquoted line name.
     $ gpionotify --utc --unquoted GPIO23
    2022-11-15T03:05:23.807090687Z	requested	GPIO23
    2022-11-15T03:05:23.807151390Z	released	GPIO23
    2022-11-15T03:05:24.784984280Z	requested	GPIO23
    2022-11-15T03:05:24.785023873Z	released	GPIO23
    ...

    # Monitor multiple lines, exit after the first is requested.
    $ gpionotify --quiet --num-events=1 --event=requested GPIO5 GPIO6 GPIO12 GPIO17

    # Block until a line is released.
    $ gpionotify --quiet --num-events=1 --event=released GPIO6

unfortunately, I've not tried out gpiod itself and wouldn't be able to say much more about it.

Other than to say that I found the kernel repo for gpiod / libgpiod and think it is possibly a good way to do some gpio

A good thing is libgpiod has bindings like c++ and python / rust

https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/bindings

https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/bindings/python/examples

which means that starting to play with them can start with python etc. e.g. to try to blink a led connected on the header. That (blinking a led) is normally the 'hello world' for embedded / bare metal programming.

I'm not sure if more elaborate stuff like spi / i2c is achieved through the same means, those (SPI / I2C) would likely need messing with DTS and even deep down into the drivers and even lower to bare metal to interface with H618 *hardware* registers (for SPI / I2C etc) , it can be a pretty high bar to jump depending on how much information is available and can be found, e.g. is the SPI / I2C hardware after all publicly documented?

TRay · May 5

Hi,

I am not sure but in HARDWARE armbian-config when we set [*] w1-gpio (on for example OZPI v1 with ArmBian v23) is only set automatic loading modules during start up system?

modprobe wire
modprobe w1-gpio
modprobe w1-therm

I do this manually and I see exist path in system

/sys/bus/w1/devices/

but we need know how to set number GPIO to use 1-Wire hardware, on Armbian v23 (Debian v11) it was added in /boot/armbianEnv.txt

param_w1_pin=PA14
param_w1_pin_int_pullup=1

but how do this in Armbian v25 (based on Debian v12)

so if I would like to connect my thermal sensor to GPIO 74 (PC10) I should be set in armbianEnv.txt ?

param_w1_pin=PC10
param_w1_pin_int_pullup=1

TRay · May 6

Looking to /boot/dtb-6.6.30-current-sunxi64/allwinner/overlay/

for h616 not exit dtbo

sun50i-h616-w1-gpio.dtbo

So for this reason not available in armbina-config in HARDWARE setup w1-gpio

so we can not at current use 1-Wire sensor to define on which GPIO is connected 1-Wire sensor

DS18B20 uses the 1-wire bus so it will be nice to have possibility use 1-Wire sensors with OZPI v3

TRay · May 7

Hi @ag123

Thank you for the replay but in case the DS18B20 uses a 1-wire bus, libgpiod is used to use the deprecated sysfs interface to GPIO, so it does not apply in this case, but I may be wrong

TRay · May 7

I tried to make of file with command:

dtc -O dtb -o sun50i-h616-w1-gpio.dtbo sun50i-h616-w1-gpio.dts

but result is with warring so we can not use example from Orange Pi Zero 2 to create dtbo file for OZPI v3 ?

Warning (unit_address_vs_reg): /__local_fixups__/fragment@1/__overlay__/onewire@0: node has a unit name, but no reg or ranges property
sun50i-h616-w1-gpio.dts:27.33-69: Warning (gpios_property): /fragment@1/__overlay__/onewire@0:gpios: cell 1 is not a phandle reference
sun50i-h616-w1-gpio.dts:27.33-69: Warning (gpios_property): /fragment@1/__overlay__/onewire@0:gpios: Could not get phandle node for (cell 1)

TRay · May 8

I found another example dtoverlay support for 1-wire subsystem on H616 devices

https://github.com/orangepi-xunlong/linux-orangepi/pull/21

/dts-v1/;
/plugin/;

/ {
        compatible = "allwinner,sun50i-h616";

        fragment@0 {
                target = <&pio>;
                __overlay__ {
                        w1_pins: w1_pins {
                                pins = "PC10";
                                function = "gpio_in";
                        };
                };
        };

        fragment@1 {
                target-path = "/";
                __overlay__ {
                        onewire@0 {
                                compatible = "w1-gpio";
                                pinctrl-names = "default";
                                pinctrl-0 = <&w1_pins>;
                                gpios = <&pio 2 10 0>; /* PC10 */
                                status = "okay";
                        };
                };
        };
};

I will try used

TRay · May 8

Much better, but still warning:

sun50i-h616-w1-gpio.dts:20.35-26.27: Warning (unit_address_vs_reg): /fragment@1/__overlay__/onewire@0: node has a unit name, but no reg or ranges property

TRay · May 8

I found information that this is a dtc issue. The error can be suppressed with -W no-unit_address_vs_reg, for example:

dtc -W no-unit_address_vs_reg -O dtb -o sun50i-h616-w1-gpio.dtbo sun50i-h616-w1-gpio.dts

or warning can be squashed by adding #address-cells and #size-cells

TRay · May 8

Refer to https://docs.armbian.com/User-Guide_Allwinner_overlays/

The file sun50i-h616-w1-gpio.dtbo should be copied to /boot/overlay-user/

and /boot/armbinaEnv.txt should be to contain for DS18B20 connected to GPIO 74/PC10

user_overlays=w1-gpio
param_w1_pin=PC10
param_w1_pin_int_pullup=1

Edited May 8 by TRay
add info about GPIO

TRay · May 10

I read again info https://docs.armbian.com/User-Guide_Allwinner_overlays/

and compile overlay by command:

armbian-add-overlay w1-gpio.dts

I see that in /boot/overlay-user/ is file w1-gpio.dtbo

in /boot/armbianEnv.txt

user_overlays=w1-gpio
param_w1_pin=PC10
param_w1_pin_int_pullup=1

after this I reboot OZPI v3

after restart OZPIv3 I check dmesg info where found

[    4.990724] Driver for 1-wire Dallas network protocol.
[    4.997793] sun50i-h616-pinctrl 300b000.pinctrl: pin PC10 already requested by onewire@0; cannot claim for 300b000.pinctrl:74
[    4.997833] w1-gpio onewire@0: gpio_request (pin) failed
[    4.997841] w1-gpio: probe of onewire@0 failed with error -22

cat /sys/kernel/debug/gpio

gpiochip0: GPIOs 0-287, parent: platform/300b000.pinctrl, 300b000.pinctrl:
 gpio-76  (                    |red:status          ) out lo
 gpio-77  (                    |green:power         ) out hi
 gpio-80  (                    |regulator-usb1-vbus ) out hi
 gpio-166 (                    |cd                  ) in  lo ACTIVE LOW
 gpio-210 (                    |reset               ) out hi ACTIVE LOW

Can anyone help?

Edited May 10 by TRay

ag123 · May 10

based on the messages, it seemed you managed to load the overlay for w1-gpio

perhaps venture further and connect a device appropriately ?

based on the data sheet

https://www.analog.com/media/en/technical-documentation/data-sheets/DS18B20.pdf

(page 15, fig 15)

it seeemed detection works by master (host) pulling down the line for 480 uS then pull that up again.

then the chip would respond by first pulling it down, and after some 60-240 uS pull that up to inform the host of presence.

it may take using specialized equipment like a scope / logic analyzer to probe those signals.

for what is worth, and not trying to disappoint you, I think it is probably easier to connect the sensor to a (simple) microcontroller e.g. using uart and for the microcontroller to interface the sensor. the thing is for things related to timing, it may take going pretty much close to 'bare metal' e.g. work the on chip hardware to synchronize those signals, e.g. using pwm, spi etc.

a h616 manual is found here

https://linux-sunxi.org/images/2/24/H616_User_Manual_V1.0_cleaned.pdf

if you want to venture there.

uart on orange pi zero 3 is likely available in the standard configs without dts overlays.

TRay · May 11

Thank you for your answer and suggestions.

Hmm, the problem is that I have a DS18B20 sensor connected to OZPIv3, which I used in another project on another SBC.

PIN DATA DS18B20 is connected to PC10 and through the 4k7 resistor to VCC 3.3V and the third pin DS18B20 to GND I will have to check this sensor again to see if RPI or OZPIv1 works on the 6.1.x kernel or I will take another unit for testing.

ag123 · May 11

I'm half way feeling that it may be possibly to use DS18B20 using gpiod / libgpiod

https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/

I tried googling around but thare are lots of offers for DS18B20 many of which use w1-gpio as you are doing

the timing requires for DS18B20 fig 16 page 16

https://www.analog.com/media/en/technical-documentation/data-sheets/DS18B20.pdf

from 15 uS to 60 uS per bit of data isn't after all that impossible to synchronize

the hard part about libgpiod is the timing part as sending and receiving data is timing sensitive, if there is a way to do that to read and write data in sync with tight timing it is possibly feasible to do so even in python. i.e. no kernel drivers, the python (or c etc) codes simply use libgpiod and work the signals.

I've thus far not (yet) found one based on libgpiod admist the 'noise' returned from the searches, maybe try searching around and you may find an existing implementation that's already done.

ether way, you seemed to have *achieved* making w1-gpio work, perhaps try connecting a sensor to see if the dmesg changes.

the hint is

[    4.997833] w1-gpio onewire@0: gpio_request (pin) failed
[    4.997841] w1-gpio: probe of onewire@0 failed with error -22

if w1-gpio does a 'probe' it is probably sending the 'reset' signal to the chip and waiting for a response

TRay · May 11

I checked new sensor DS18B20 but still the same error in dmesg info, so I will try with my RPI or OZPI v1 z kernel 6.1 check use w1-gpio overlay

TRay · May 11

I connect DS18B20 to orange Pi Zero on Armbian 23.02.2 Bullseye with Linux 6.1.63

Via armbian-config in Hardware enabled w1_gpio and add to armbiaEnv.txt

param_w1_pin=PA14
param_w1_pin_int_pullup=0

and in overlyas= was w1_gpio

cat /sys/bus/w1/devices/28-03165129ecff/w1_slave
54 01 4b 46 7f ff 0c 10 fd : crc=fd YES
54 01 4b 46 7f ff 0c 10 fd t=21250

cat /sys/kernel/debug/gpio

gpiochip0: GPIOs 0-223, parent: platform/1c20800.pinctrl, 1c20800.pinctrl:
 gpio-14  (                    |onewire@0           ) out hi
 gpio-17  (                    |orangepi:red:status ) out lo
 gpio-20  (                    |reg_vcc_wifi        ) out hi
 gpio-166 (                    |cd                  ) in  lo ACTIVE LOW
 gpio-204 (                    |usb0_id_det         ) in  hi IRQ

dmesg |grep wire*

[    9.398674] Driver for 1-wire Dallas network protocol.
[    9.410366] gpio-14 (onewire@0): enforced open drain please flag it properly in DT/ACPI DSDT/board file
[    9.463654] w1_master_driver w1_bus_master1: Attaching one wire slave 28.03165129ecff crc 24

so all working very well on OZPI v1 with kernel 6.163 on Armbian 23.02.2

So my DS18B20 is work but on OZPI v3 with 6.6.30 kernel and user overlay for w1-gpio not work for me. It maybe we need more add in overlay for w1-gpio.dts?

TRay · May 11

Form firs message from dmesg is not clear

sun50i-h616-pinctrl 300b000.pinctrl: pin PC10 already requested by onewire@0; cannot claim for 300b000.pinctrl:74

I see many similar problems z similar info for UART SPI etc , I suppose that we need to solve this problem or I am wrong

TRay · May 11

Wow 🙂 I have success

dmesg | grep -i wire*

[    4.991132] Driver for 1-wire Dallas network protocol.
[    4.994076] w1-gpio onewire@0: there is not valid maps for state default
[    4.994183] gpio-74 (onewire@0): enforced open drain please flag it properly in DT/ACPI DSDT/board file
[    5.021347] w1_master_driver w1_bus_master1: Attaching one wire slave 28.03165129ecff crc 24

cat /sys/bus/w1/devices/28-03165129ecff/w1_slave

54 01 4b 46 7f ff 0c 10 fd : crc=fd YES
54 01 4b 46 7f ff 0c 10 fd t=21250

What do I change in /boot/armbianEnv.txt Instead of capital letters PC10, I used in lowercase letters pc10 for the gpio name

stupid mistake on my part and maybe I suggested examples

param_w1_pin=pc10
param_w1_pin_int_pullup=0
user_overlays=w1-gpio

So we can now use sensors like DS18B20 etc with w1-gpio on Orange Pi Zero v3 w with w1-gpio.dts:

/dts-v1/;
/plugin/;

/ {
        compatible = "allwinner,sun50i-h616";

        fragment@0 {
                target = <&pio>;
                __overlay__ {
                        w1_pins: w1_pins {
                                pins = "PC10";
                                function = "gpio_in";
                        };
                };
        };

        fragment@1 {
                target-path = "/";
                __overlay__ {
                        onewire@0 {
                                compatible = "w1-gpio";
                                pinctrl-names = "default";
                                pinctrl-0 = <&w1_pins>;
                                gpios = <&pio 2 10 0>; /* PC10 */
                                status = "okay";
                        };
                };
        };
};

I don't know what I need to correct to remove this info:


[    4.994076] w1-gpio onewire@0: there is not valid maps for state default

Edited May 11 by TRay

TRay · May 11

But it is interesting most of examples armbianEnv.txt for parameters

param_w1_pin=PC10

show name of gpio in use capital letters but when I use name in capital letters is problem and show in demsg info

[ 4.997793] sun50i-h616-pinctrl 300b000.pinctrl: pin PC10 already requested by onewire@0; cannot claim for 300b000.pinctrl:74

and 1-Wire not working but when I use name of gpio in lowercase letters pc20 1-Wire works and show temperature from DS18B20 but is info

[ 4.994076] w1-gpio onewire@0: there is not valid maps for state default

It maybe any bug ?

Edited May 11 by TRay

ag123 · May 11

it may help to look in codes

https://github.com/torvalds/linux/blob/master/drivers/w1/masters/w1-gpio.c

https://github.com/torvalds/linux/tree/master/drivers/w1

[ 4.997793] sun50i-h616-pinctrl 300b000.pinctrl: pin PC10 already requested by onewire@0; cannot claim for 300b000.pinctrl:74

seem to suggest that pinctrl tries to map that pin but onewire@0 is using it, so i guess this is ok as long as you are not using that as normal gpio pin.

that "no maps for state" is found here

https://github.com/torvalds/linux/blob/cf87f46fd34d6c19283d9625a7822f20d90b64a4/drivers/pinctrl/devicetree.c#L175

	ret = ops->dt_node_to_map(pctldev, np_config, &map, &num_maps);
	if (ret < 0)
		return ret;
	else if (num_maps == 0) {
		/*
		 * If we have no valid maps (maybe caused by empty pinctrl node
		 * or typing error) ther is no need remember this, so just
		 * return.
		 */
		dev_info(p->dev,
			 "there is not valid maps for state %s\n", statename);
		return 0;
	}

my guess is it may be related to

pinctrl-names = "default";

some related stuff

https://www.kernel.org/doc/Documentation/devicetree/bindings/w1/

https://www.kernel.org/doc/Documentation/devicetree/bindings/w1/w1-gpio.txt

as it works as you mentioned, I'd guess that "not valid maps for state default" can be ignored.

TRay · May 11

Quote

[ 4.997793] sun50i-h616-pinctrl 300b000.pinctrl: pin PC10 already requested by onewire@0; cannot claim for 300b000.pinctrl:74

seem to suggest that pinctrl tries to map that pin but onewire@0 is using it, so i guess this is ok as long as you are not using that as normal gpio pin.

But I am not use gpio PC10 by another application etc, I define PC10 only for w1-gpio in armbianEnv.tx but when I use PC10 instead pc10 w1-gpio is not working and I can not read data DS18B20. When I use pc10 all working and I read atat from DS18B20

so info in log:

pin PC10 already requested by onewire@0; cannot claim for 300b000.pinctrl:74

give me that w1-gpio is not working

ag123 · May 11

rather pinctrl could be related to pinctrl or maybe gpiod. I'm not too sure if that message means that w1-gpio is using that pin so pinctrl cannot use it.

if that is the case, I think it is ok if pinctrl don't use it for gpio.

that message is likely safe to ignore as long as your w1-gpio works.

to 'fix' that it may take editing other dts to exclude that pin from pinctrl which could be a hassle.

TRay · May 11

Yes "no maps for state" is connected with

but in all examples .dts is used :

pinctrl-names = "default";

TRay · May 11

Yes, that's right, I can ignore it when I have a working w1-gpio on OZPI v3, but it would be nice to see how to fix it so that it works correctly.
But what's strange to me is that I have to use the gpio name in lower case and not in upper case as it was always described in the w1-gpio examples. I tried to use the name with gpiod, i.e. "gpio74", instead of names like PC10, but it didn't work, so it occurred to me to try writing the name in lower case "pc10" instead of capital letters as usual, and I found that it worked, but I think it's not normal since capital letters have been used so far, I will check on OZP v1 whether it will work if I change to lowercase letters

Thank you for exchanging ideas and tips on solving the problem

ag123 · May 12

dts overlay aren't 'perfect'

https://elinux.org/Device_Tree_Source_Undocumented#:~:text=Node can be deleted with,%2Fdelete-property%2F directive.&text=If a delete is specified,with the overlay source file.

If a delete is specified in an overlay source file, the delete only
impacts the files compiled in association with the overlay source
file.  The delete does not result in an opcode in the resulting
.dtb, thus applying the overlay will not delete the node or
property in the base tree.

and it may take using those 'hacks' described at that page to attempt a 'fix'

hence, you may like to just note that those messages are 'benign' and w1-gpio works normally.

TRay · May 12

I have checked what hapen when on Ornage Pi Zero v1 with kernel 6.1.63 in armbianEnv.txt use pa14 instead PA14

in log I see

[    9.358693] Driver for 1-wire Dallas network protocol.
[    9.366246] w1-gpio onewire@0: there is not valid maps for state default
[    9.368019] gpio-110 (onewire@0): enforced open drain please flag it properly in DT/ACPI DSDT/board file

and w1-gpio not working and no files in /sys/bus/w1/devices/

but we see marked in red the same information that I have on OZPI v3 when I use pc10 instead of PC10 but on OZPI v3 DS18B20 works and on OZPI v1 it doesn't work when I use the lower case name gpio

This looks like some kind of bug in kernel 6.6.30 on OZPI v3

TRay · May 12

Summary,

In all examples to use w1-gpio in Armbian in armbinaEnv.txt always is name of gpio is write in capital

letters for example PC10

param_w1_pin=PC10

but when we use PC10 w1-gpio not works and in log is message:

[ 4.997793] sun50i-h616-pinctrl 300b000.pinctrl: pin PC10 already requested by onewire@0; cannot claim for 300b000.pinctrl:74

command cat /sys/kernel/debug/gpio did not show that gpio 74 / PC10 is used

command

but when we use name gpio in lowercase letters pc10

w1-gpio works and show data from DS18B20 but show message in log

[ 9.366246] w1-gpio onewire@0: there is not valid maps for state default

command cat /sys/kernel/debug/gpio show

gpiochip0: GPIOs 0-287, parent: platform/300b000.pinctrl, 300b000.pinctrl:
gpio-74 ( |onewire@0 ) out hi

and we can see data from DS18B20

cat /sys/bus/w1/devices/28-03165129ecff/w1_slave

53 01 4b 46 7f ff 0c 10 2d : crc=2d YES
53 01 4b 46 7f ff 0c 10 2d t=21187

for me, it is bug or in kernel 6.6.30 or overlay for Ornage Pi Zreo v3

TRay · May 12

Ha, interesting ...

I have put in armbianEnv.txt instead pc10 now

param_w1_pin=gpio71

where gpio71 is number line for PC7 which is not connected DS18B20 🙂 at current is nothing connected

and working w1-gpio with info log where is show PC10/gpio-74

[    4.957396] Driver for 1-wire Dallas network protocol.
[    4.960325] w1-gpio onewire@0: there is not valid maps for state default
[    4.960433] gpio-74 (onewire@0): enforced open drain please flag it properly in DT/ACPI DSDT/board file
[    4.986579] w1_master_driver w1_bus_master1: Attaching one wire slave 28.03165129ecff crc 24

cat /sys/bus/w1/devices/28-03165129ecff/w1_slave

5f 01 4b 46 7f ff 0c 10 12 : crc=12 YES
5f 01 4b 46 7f ff 0c 10 12 t=21937

I can not understand this

TRay · May 12

Unfortunately, my programming knowledge is low and knowledge of DTS Overlays + source code of w1-gpio linux kernel does not allow me to find the source of the problem

[ 4.997793] sun50i-h616-pinctrl 300b000.pinctrl: pin PC10 already requested by onewire@0; cannot claim for 300b000.pinctrl:74

TRay · May 13

Maybe I need a change in my w1-gpio.dts looking to https://elixir.bootlin.com/linux/v6.6.30/source/arch/arm64/boot/dts/allwinner

compatible = "allwinner,sun50i-h616";

to

model = "OrangePi Zero3";

compatible = "xunlong,orangepi-zero3", "allwinner,sun50i-h618";

and add

#include "sun50i-h616-orangepi-zero.dtsi"

like in https://elixir.bootlin.com/linux/v6.6.30/source/arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero3.dts

Sign In

OrangePiZero 3 and w1-gpio for DS18B20

Recommended Posts

TRay

ag123

TRay

TRay

TRay

TRay

TRay

TRay

TRay

TRay

TRay

ag123

TRay

ag123

TRay

TRay

TRay

TRay

TRay

ag123

TRay

ag123

TRay

TRay

ag123

TRay

TRay

TRay

TRay

TRay

Join the conversation

Similar Content

Forums

My Activity Streams

Download

Store

Important Information