ag123

in addition, armbian tends to be 'beyond' bleeding edge in a sense, like (*additional*) support for orange pi zero 3 is developed right here in this forum, no where else. and of course, it is by this community ('community support'), which means that you are practically supporting 'yourself'

@burger242 wrote note that Armbian is right here on https://www.armbian.com/ nowhere else. you go to the 'wrong' link. the authentic Armbian for Orange Pi Zero 3 images is here: https://www.armbian.com/orange-pi-zero-3/ scroll down to the bottom Note that this is a "community maintained" image, which means that that image is made possible by volunteers / contributors you see if you review this thread itself. simply flash the image to the sd card e.g. using belana etcher plug that into the uSD slot and boot it up. it is recommended that you use a usb-uart dongle to connect to the board on the 'debug uart' pins and use a serial terminal app e.g. https://www.putty.org/ to connect to it on the serial console. you should be able to see it boot up in the serial console that way. if you become any more 'advanced' than simply getting started, you can build your own image: https://docs.armbian.com/Developer-Guide_Build-Preparation/

well h618 isn't a 'high performing' cpu, so don't expect too much in terms of opencl etc, probably nil. and even GPU support is probably sketchy https://docs.mesa3d.org/drivers/panfrost.html https://bakhi.github.io/mobileGPU/panfrost/ https://en.opensuse.org/ARM_Mali_GPU GPU is a most undocumented aspects of these socs, many time you are left with 'you are on your own', no docs, no help, no hints, no nothing you can try plain old NEON https://developer.arm.com/Architectures/Neon https://developer.arm.com/documentation/dht0002/a/Introducing-NEON/Developing-for-NEON/Automatic-vectorization this would probably 'just works'

@D I'm really unfamiliar with DTS and such, hence there isn't much I'd help. But that are there any hints in dmesg etc? And as I suggested, try to decompile the dtb for your board and review that. In my case, I tried that for Orange Pi Zero 3 and did not see pwm devices listed. Hence, I'd guess those would need to be added by applying a .dtbo (device tree overlay binary). Accordingly, you may be able to check the same thing in a running system by checking them under /proc/device-tree as well. e.g. if you don't find them in /proc/device-tree, maybe that overlay isn't loaded.

@D answer to that question is 'complicated', there are a bunch of DTS patches https://github.com/armbian/build/tree/main/patch/kernel/archive/sunxi-6.6/patches.armbian which are laid on top of mainline H616 DTS https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero3.dts https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi you can try to decompile the dtb file back to its source to examine it dtc -I dtb -O dts -o ~/devtree.dts /boot/dtb/allwinner/sun50i-h618-orangepi-zero3.dtb

for H618 simply try the mainline uboot and kernel >= 6.6 various things has gone into mainline u-boot and kernel that makes it run on Orange Pi Zero 3 one could perhaps even try the Orange Pi Zero 3 image to see how that goes

@madeofstown I'd guess it is good to leave the default serial uart console running there as otherwise if things goofs, you may have no means to login onto the board. with the serial console, you can connect a usb-uart serial dongle and login to Armbian on the board. but if you insist you can nevertheless try going into /usr/lib/systemd/system look for those *getty* (e.g. ls *getty*), it would be one of those services. but that for debug output I'm not sure about that though, a google search I'd guess would get some leads e.g. https://superuser.com/questions/351387/how-to-stop-kernel-messages-from-flooding-my-console https://wiki.archlinux.org/title/working_with_the_serial_console I'd suggest to browse that same Orange Pi Zero 3 thread and figure out how to use a different serial uart port, there are probably more than a single uart port available on Orange Pi Zero 2W or Orange Pi Zero 3. using a different serial comm (uart) port is the correct solution in your case and you won't need to be bothered about console messages as they won't be there.

@JohnTheCoolingFan neither am I familiar with much of that. I'd just like to say that H618 support evolves out of H616 and the DTS for Orange Pi Zero 3 and Zero 2W is contributed by Andre Przywara from 6.6 mainline kernel. But that various contributors here worked the DTS further, check in the thread for details. Note that there are also change in *u-boot* for Orange Pi Zero 3, mainly to add the PMIC and DDR4 support for Orange Pi Zero 3 I think some key difference between Orange Pi Zero 2 (H616) vs Orange Pi Zero 3 (H618) are : - PMIC the power management IC is different - Orange Pi Zero 3 uses lpddr4 vs Orange Pi Zero 2 lpddr3 various other 'small' differences and that H618 is after all based on H616 codebase. Hence, my guess is to attempt to use the 6.6 and up mainline kernel and do a rebuild for CB1. One thing I'm not sure is where to configure that so that the build would use the 6.6.x mainline kernel during the build. It would likely 'not build cleanly' (e.g. without errors) and the build errors especially if the 'old' patches for the same board is applied and those would need to be resolved. You would take into account the actual hardware differences vs Orange Pi Zero 2 or Orange Pi Zero 3 if after all they are different on the CB1.

@madeofstown try out the orange pi zero 3 community images to see if it helps https://www.armbian.com/orange-pi-zero-3/ zero 2w don't have the motorcomm ethernet (requires an extension/expansion board accordingly), that's what I understand it to be. hopes that works still on zero 2w

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.

@wanasta orange pi zero 3 (and zero 2w) has on board wifi, have you tried them 1st? usb wifi dongles normally if the drivers are built into the kernel, plug them in and check dmesg if they are detected

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.

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.

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

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.