ag123

@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.

in a normal case, files in your home directory should belong to you except ..

type id and look at the groups you are in then ls -l and/or ls -ld and look at the owners and permissions for the files in your home folder the owners and group should match that in id otherwise you can probably change them using chown , chown -R , chmod etc. for rsync, scp etc, you probably need to use a same username across different hosts in a sense that it should remote login to your Orange Pi host using ssh with that username.

@OttawaHacker connect to the board using a usb-uart (debug) serial dongle. the boot messages would normally show up there, or that if it booted to the prompt, you could login as root and run dmesg to see what goes wrong try also the other u-boot https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/ to see if that helps. there is a sequence of patches that needs to be applied and I've done that with my implementation. Unfortunately, in my case I hardcoded the 1.5GB memory as I found that for 1.5GB boards, the mainline u-boot incorrectly detected memory as 2GB or 4GB inconsistently. For once it says 2GB, then 4GB, then 2GB, and the algorithm would probe into the wrong memory size. so 'hardcoding' it ensures that it is 1.5GB no more / no less. you can use the distributed Armbian images https://www.armbian.com/orange-pi-zero-3/ and subsequently apply the u-boot patch from my repository. If you don't use dd , you can try using the python script that I've provided in my respository to patch u-boot into the image. Checkout instructions in my repository.

@OttawaHacker you could try the images from here: https://www.armbian.com/orange-pi-zero-3/ and to patch the u-boot into the image from here https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/tree/main

@voapilro Thanks To try to get it to boot, try applying the patches https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/tree/main/patches in particular: https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/blob/main/patches/THS_fix.patch https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/blob/main/patches/enable_GPU.patch note that these are for mainline u-boot 2024-04 release (tag), the patches are for the same found in Armbian. I really disliked all these 'black magic', but that these are really the 'state-of-the-art'. After I did my initial 1.5GB 'hack' patches, originally I've got that 'gpu overheating' issue. But with that 2 patches, it booted to the prompt ! As for 'vendor' u-boot, I'm suspecting that orange pi customized u-boot to pass some additional variables (possibly hard coded) to boot.scr, boot.cmd. When something fails there, I'd guess it dropped to the u-boot prompt. It'd take figuring out what is the statement that the boot.scr, or boot.cmd aborted and what it needs. When that is figured out, you may also be able to do that same 'black magic', passing the variables boot.scr or boot.cmd is expecting. I kind of disliked these 'black magic', the 'right' way is for these to goto the device tree source or overlays (dts files), so that the relevant board use the correct board dts file instead of hard coding them in u-boot. But it is somewhat the 'state-of-the-art' as well as of current, the catch is mainline u-boot won't boot those custom boot.scr and boot.cmd as those 'special' hard coded variables won't be there. if you clone my repository, I've updated a build guide https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/blob/main/build.md those steps should compile the mainline u-boot for Orange Pi Zero 3 - note with the '1.5GB hack' my repository is managed using quilt https://wiki.debian.org/UsingQuilt to make edits (note those steps in build.md needs to be done at least once prior this) quilt series quilt push patches/1.5GB_OPZ3_fix.patch vi u-boot/arch/arm/mach-sunxi/dram_sun50i_h616.c <- or use any editor you prefer quilt refresh <- note this would update patches/1.5GB_OPZ3_fix.patch quilt push -a <- this applies the remaining of the patches # compile it cd arm-trusted-firmware bash arm-trust-fw-make.sh <- normally only need to be done once, not necessary if that is already built prior cd u-boot bash build.sh # test it if necessary # you can rollback all the patches using # quilt pop -a

@voapilro I think there could be another mistake besides that, my memory computation is using unsigned long long, my guess is that'd be 64 bits, that becomes the 'offset' in mctl_mem_matches_top(offset). I made a guess that the unsigned long long would be truncated dropping the high order 32 bits, that would still match the 32 bits based address, but could be wrong. For reasons uncertain, searching for CONFIG_SYS_SDRAM_BASE 'returns a blank' in my source base, as such I took a liberty to define that as 0. A thing is memsz is computed as 2 GB ( 2048 * 1024 * 1024 ), as I guess observed, I'm not too sure if that might be offset away a little, say the 'bottom' 32kb

@voapilro I tried patching those codes into my custom u-boot loader https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/ unfortunately, when I tried booting with the updated u-boot, I noted 2 scenarios that is goofy and didn't work first the board is incorrectly detect as a 4GB board. For reasons I'm unsure, the detection is not stable. Sometimes it is detected as a 4GB board, other times 2GB. when it is correctly detected as 2GB, apparently I'm observing the 'dram wraparound' problem, i.e. writing to a little before 2GB spoofs and faked memory at that location when there is actually none. If it is working correctly, it should detect 2048M and return 1.5GB instead. The patch is like such: As such, I reverted the codes to the old 1.5GB hard coded version. It would have been good if this works (well), at least that it can be used on all the different Orange Pi Zero 3 boards

@voapilro, I'd think for 1.5GB, we'd make do with that 1.5GB custom bootloader, I'd likely adopt your codes so that most who use that can benefit from it. As for pushing it to mainline, I'd think it is pre-mature, as that code applies to *all* H616/H618 devices and not simply Orange Pi Zero 3.

@voapilro thanks, I'd do some tests when I've some time, possibly working that into the custom bootloader code so that others can test that as well. I hardcoded 1.5GB as an/the author partly of the h616/h618 dram initialization/detection reported that (some?) 1.5 GB ddr4 dram chips has address wrap around issues https://forum.openwrt.org/t/can-someone-make-a-build-for-orange-pi-zero-3/168930/38?u=ag1233 I'm not sure if this is after all true. As if that is true, then that writing to and reading the last accessible address e.g. 2GB would actually return a false match, saying that there is memory there when there is actually none (i.e. writes to somewhere else). my guess would be to patch that custom u-boot loader with this 'version 2' codes and let 'everyone' test it out including those having non 1.5 GB boards. we'd probably need a way to collect some feedback from the 'testers' if after all that 'works'. the notion is that if there is after all no wraparound, the codes can possibly be committed to u-boot mainline, and become codes in the mainline u-boot. That is truly ideal. of course, a catch with this code is that we'd assume the only 'odd' size is only 1.5 GB, it is unknown if there could possibly be some other weird permutations e.g. 2.5 GB, 3.5GB, 1.2GB, 0.9GB etc that may declare 'too little' or 'too much' dram for some such boards. for that i'd think the only 'right' way is to wait till someone release a means to read the dram registers, which stores the actual memory sizes configurations.

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 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?

note that various armbian os images are linked on github https://github.com/armbian/os https://github.com/armbian/os/releases are you able to download images from there? you probably have to copy that say into a usb thumb/flash drive bring that home and you can try flashing that using dd from your raspberry pi I think there are also torrents link as alternative on the boards web pages, but I'm not too sure if you are able to download torrents say on a public terminal.

blobs are practically 'useless', it is compiled for a particular os, a particular version of it and if it is *undocumented* there is no way to use the blob, and even if they document the api, if you try to use the blob in a different OS say armbian, chances are that a call to the api can *crash*. it is a 'miracle' if those blobs work.

@voapilro @bjorn @Long-Johnny, all psst some fun stuff https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/ ok that's the 2nd attempt to create a custom u-boot to boot Armbian on 1.5 GB OPi Zero 3 boards, do visit the repository for more info. first you can try that with the 'official' image https://www.armbian.com/orange-pi-zero-3/ but that this u-boot is build from mainline u-boot at the 2024.04 release https://gitlab.com/u-boot/u-boot and that it requires a working /boot/boot.scr or /boot/boot.cmd to boot linux. /boot/boot.scr or /boot/boot.cmd are the boot scripts that actually has u-boot commands which loads the kernel and dependencies and boot linux. if the boot drops you into a command shell, it could mean either that the /boot/boot.scr or /boot/boot.cmd is invalid or that it is using a *custom* u-boot and the /boot/boot.cmd, /boot/boot.scr uses or is expecting some variables that is not there in 'standard' mainline u-boot. I managed to boot to the Linux command prompt this time ! I'd just like to say that I took the Armbian Bookworm minimal image from the Armbian release web for Orange Pi Zero 3 Armbian_community 24.5.0-trunk.474 6.6.28 https://www.armbian.com/orange-pi-zero-3/ did my u-boot patch, run it on my 1.5 GB Orange Pi Zero 3 and it booted to the prompt! and just right now Here is a screenshot running from Orange Pi Zero 3 - 1.5 GB board tethered from usb-uart to debug console, I ran the command 'free' which shows that the total memory is 1.5GB how about that for a proof-of-concept without this u-boot 'patch' u'd get 'stuck' at the boot reporting 2GB seen on the usb-uart debug console for the 1.5GB board. men I feel like celebrating, now Armbian runs on 'all variants' of Orange Pi Zero 3 - 1 GB / 1.5 GB (with this hack) / 2 GB / 4GB