Search the Community

thanks for replying @Stephen Graf. I rather want to try using the older armbian-firmware package and keep the newer kernel, since the problem only shows up after I upgrade the firmware. currently it still hangs after 15-20 hours. can I extract the firmware from and image? the post from @ER Samson mention vnstat. I do not use it, and the package is not installed. i did use htop to check what's using the cpu. but nothing extensive. I haven't check the governor prior the deletion of firmware. currently is "on-demand"

I would not use ZFS with this kernel if I were you. This kernel is provided by hw vendor, by people / business that only cares about (selling) hardware features to work. Everything else is unmaintained and open source community (not just Armbian) developers are not even thinking to maintain this kernel outside that as its concorde fallacy. FYI - it is highly possible ZFS implementation is affected, but you are FREE to do whatever. 90% of solutions, not workarounds, Armbian team (a few people) is unable to integrate into OS with their private resources, public (thousands of you) are simply not there. I can estimate, we could integrate about 30% of resolved suggestions this community generate with few full time engineers. Which costs money. Until you are satisfied with reporting problems only, until you don't care that a lot of value is wasted, there is nothing we can do but keep trying to provide "best effort" support with what we have and explaining this situation. Users perspective will always be like we refuse to help ... but people that are working on / helping Armbian are already long maxed out in efforts of helping everyone, even our competitors. Also. Hardware vendors have exploit of open source community build into their business model. If it happens that you are using hardware with terrible vendors reputation, bugs can be written, but are last to be resolved, some bugs are never resolved ... If you really wanna help everyone, start here: https://github.com/armbian/os/wiki/Import-3rd-party-packages Study and implement a solution. We also have automated dependency testing, which should prevent this problem in first place, but ain't working well and it wouldn't help much in this case. ZFS package is imported from Trixie and yes I understand that upstream package dependency has been recently changed. Until a month ago, we didn't have this problem, everything was working right and now, there is little we can do except disabling importing (which will also delete packages from repository). We don't compile those packages on our own and I am aware that this is not the best way. There are more workarounds - like using Trixie or Noble user space ... Its sadly under-powered, too small. Math is simple - I would very much like to help, but costs are the one that are killing us. Imagine that fixing a problem costs 1000 USD. You are willing to pay 5 USD (or not even that), which is fair if there would be more people contributes their share that you cover all costs. This never happens. They come with another and another problem for 1000 USD (often a lot more, sometimes a lot less) instead. Then its expected that we pay the rest, 995 USD for costs of resolving community software problem, this is simply not sustainable way of cooperation. Even the bug was made by us. I am trying to keep ZFS available. Do you have any idea how much time loss this service already caused with no benefits whatsoever? There are thousands of bugs in open source software and most of people pin everything on us after they download "Armbian image" and images that are produced by copycats as they claim "its Armbian". This particular problem was introduced by us, yes, but alternatively would be not providing ZFS that is capable of working with recent kernels. Which touches to the core of embedded Linux experience and logic. Often we can't match user space and kernel like this is done on 1st class x86 desktop / server / hw Linux world. Even they, often breaks critical things too, even with thousands of full time employees (Redhat). We can't provide that level of services with close to nothing from your side.

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

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

@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

Attempting Armbian install onto an S905. Hardware specs at https://specdevice.com/showspec.php?id=6653-4ac9-1101-570d0033c587 Kernel begins to boot but gets errors and never completes dropping into initramfs shell. Was able to capture the dtb blob from the Android kernel and decompiled it. Enough differences to the dtb files in the Armbian distribution that I cannot figure out how to create a dtb file that will work. Have looked for other files on the internet but haven't come across something similar yet. Booting gets stuck in a loop of: meson-gx-mmc d0072000.mmc: no support for card's volts mmc0: error -22 whilst initialising SDIO card. mmc0: Card stuck being busy! __mmc_poll_for_busy Any feedback or guidance appreciated.

I have a tp link wn722n wifi adapter on the rtl8188eus chipset and I need to build a driver for the monitoring meter, but I don’t have the kernel headers, how and where can I download and install them?

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 have no complaints about the kernel that comes with the board. And with the fact that the ZFS packages supplied by armbian are not for debian 12 (bookworm). This has nothing to do with my board. I imagine there will be other boards that will have problems with the zfs package that comes from armbian and are using debian 12. As you can see, I have also shared the workaround.

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?

Description Rewrite with: ./compile.sh rewrite-kernel-config BOARD=board BRANCH=branch How Has This Been Tested? [ ] CI Checklist: Please delete options that are not relevant. [ ] My changes generate no new warnings View the full article

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

Hello. I also had such a problem some time ago. I don't know how much experience you have with linux. Probably missing the /boot stuff. You can try the following, but it's a bit risky. You make an mmc card with arbian and kernel 6.1.XX. and you start nanopc from it. After it loads. You put in a USB to SD card adapter. In the new memory card, after loading the OS, create an OMV folder, in it /OMV/boot and /OMV/os/ in it you create /OMV/boot and /OMV/os/ rsync -va /boot/ /OMV/boot/ mv /OMV/os/lib/modules/6.1.43-vendor-rk35xx /OMV/os/lib/modules/6.1.43-vendor-rk35xx_old rsync -va /lib/modules/6.1.43-vendor-rk35xx /OMV/os/lib/modules/ After that, umount /OMV/boot and /OMV/os/, put the OMV card in the nanopc and if you're lucky, it might start. I hope I was helpful and good luck

Hello, I have ZFS installed, today there was an update, in which I no longer have ZFS. root@msrv 49.00℃ :~# apt dist-upgrade Reading package lists... Done Building dependency tree... Done Reading state information... Done Calculating upgrade... Done The following packages were automatically installed and are no longer required: libnvpair3linux libuutil3linux libzfs4linux libzpool5linux Use 'apt autoremove' to remove them. The following packages will be REMOVED: zfs-zed zfsutils-linux The following packages have been kept back: libnvpair3linux libzfs4linux The following packages will be upgraded: libuutil3linux libzpool5linux zfs-dkms 3 upgraded, 0 newly installed, 2 to remove and 2 not upgraded. Need to get 0 B/3,598 kB of archives. After this operation, 2,533 kB disk space will be freed. Do you want to continue? [Y/n] Y Preconfiguring packages ... (Reading database ... 71907 files and directories currently installed.) Removing zfs-zed (2.1.11-1) ... Removing zfsutils-linux (2.2.3-1) ... (Reading database ... 71592 files and directories currently installed.) Preparing to unpack .../libuutil3linux_2.2.3-2_arm64.deb ... Unpacking libuutil3linux (2.2.3-2) over (2.2.3-1) ... Preparing to unpack .../libzpool5linux_2.2.3-2_arm64.deb ... Unpacking libzpool5linux (2.2.3-2) over (2.2.3-1) ... Preparing to unpack .../zfs-dkms_2.2.3-2_all.deb ... Module zfs-2.2.3 for kernel 6.1.43-vendor-rk35xx (aarch64). Before uninstall, this module version was ACTIVE on this kernel. zfs.ko: - Uninstallation - Deleting from: /lib/modules/6.1.43-vendor-rk35xx/updates/dkms/ - Original module - No original module was found for this module on this kernel. - Use the dkms install command to reinstall any previous module version. spl.ko: - Uninstallation - Deleting from: /lib/modules/6.1.43-vendor-rk35xx/updates/dkms/ - Original module - No original module was found for this module on this kernel. - Use the dkms install command to reinstall any previous module version. depmod... Deleting module zfs-2.2.3 completely from the DKMS tree. Unpacking zfs-dkms (2.2.3-2) over (2.2.3-1) ... Setting up zfs-dkms (2.2.3-2) ... Loading new zfs-2.2.3 DKMS files... Building for 6.1.43-vendor-rk35xx Building initial module for 6.1.43-vendor-rk35xx Done. zfs.ko: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/6.1.43-vendor-rk35xx/updates/dkms/ spl.ko: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/6.1.43-vendor-rk35xx/updates/dkms/ depmod... Setting up libuutil3linux (2.2.3-2) ... Setting up libzpool5linux (2.2.3-2) ... Processing triggers for libc-bin (2.36-9+deb12u7) ... Processing triggers for man-db (2.11.2-2) ... Processing triggers for initramfs-tools (0.142) ... ln: failed to create hard link '/boot/initrd.img-6.1.43-vendor-rk35xx.dpkg-bak' => '/boot/initrd.img-6.1.43-vendor-rk35xx': Operation not permitted update-initramfs: Generating /boot/initrd.img-6.1.43-vendor-rk35xx W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125a-3.fw for module r8169 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8107e-2.fw for module r8169 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168fp-3.fw for module r8169 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168g-3.fw for module r8169 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168g-2.fw for module r8169 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8106e-2.fw for module r8169 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8106e-1.fw for module r8169 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8411-2.fw for module r8169 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8411-1.fw for module r8169 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8402-1.fw for module r8169 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168f-2.fw for module r8169 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168f-1.fw for module r8169 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8105e-1.fw for module r8169 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168e-3.fw for module r8169 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168e-2.fw for module r8169 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168e-1.fw for module r8169 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168d-2.fw for module r8169 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168d-1.fw for module r8169 W: Possible missing firmware /lib/firmware/regulatory.db for built-in driver cfg80211 W: Possible missing firmware /lib/firmware/regulatory.db.p7s for built-in driver cfg80211 update-initramfs: Armbian: Converting to u-boot format: /boot/uInitrd-6.1.43-vendor-rk35xx Image Name: uInitrd Created: Sat May 11 11:42:20 2024 Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 9305942 Bytes = 9087.83 KiB = 8.87 MiB Load Address: 00000000 Entry Point: 00000000 update-initramfs: Armbian: Symlinking /boot/uInitrd-6.1.43-vendor-rk35xx to /boot/uInitrd ln: failed to create symbolic link '/boot/uInitrd': Operation not permitted update-initramfs: Symlink failed, moving /boot/uInitrd-6.1.43-vendor-rk35xx to /boot/uInitrd renamed '/boot/uInitrd-6.1.43-vendor-rk35xx' -> '/boot/uInitrd' update-initramfs: Armbian: done. root@msrv 48.07℃ :~# Fortunately, the module is on and everything is working now. ZFS is from the armbian repo. When I try to install I get this: root@msrv 47.15℃ :~# aptitude install zfs-zed zfsutils-linux The following NEW packages will be installed: libuutil3linux{a} zfs-zed{b} zfsutils-linux{b} 0 packages upgraded, 3 newly installed, 0 to remove and 0 not upgraded. Need to get 541 kB/666 kB of archives. After unpacking 2,696 kB will be used. The following packages have unmet dependencies: zfs-zed : Depends: libnvpair3linux (>= 0.8.2) but it is not installable Depends: libzfs4linux (>= 2.1.11-1) but it is not installable zfsutils-linux : Depends: libnvpair3linux (= 2.2.3-2) but it is not installable Depends: libzfs4linux (= 2.2.3-2) but it is not installable Depends: libzpool5linux (= 2.2.3-2) but it is not installable Depends: libssl3t64 (>= 3.0.0) which is a virtual package and is not provided by any available package The following actions will resolve these dependencies: Keep the following packages at their current version: 1) zfs-zed [Not Installed] 2) zfsutils-linux [Not Installed] Accept this solution? [Y/n/q/?] Y No packages will be installed, upgraded, or removed. 0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B of archives. After unpacking 0 B will be used. Any ideas on how to fix it and/or what to provide as additional information

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

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.

I'm trying to enable GPU support for watching youtube on orange pi 2 zero w model. But there is no Mali driver and even kernel package How can I enable this?

Hi all, I have some x905 boxes and I'd like to use one (an old TX95 -> x905w IIRC) as a midi sequencer with fluidsynth. I found the hard way that the default kernel has no midi sequencer support (in kernel or module) so there's no way to use aconnect and have it as a midi box. The only solution seems to be rebuild the kernel with the added module support but it's been decades since last time i rebuilt a kernel and S905 kernels (with added balbes150 mods and stuff to have it working on those cheap boxes) seems a bit too complex for me. So the question is: is there a way to get a working kernel with midi support, and how to put it in. If this wasn't really feasable: how could a mere mortal (with some knowledge) rebuild an x905w kernel, pack it and install without breaking the whole thing in the process ? ( I'm not interested in a GUI or similar, it would work as headless with the RCA out for audio )

Description The vendor config of rk35xx is originally for rk3588 which doesn't need this driver. But rk3568 need it. CONFIG_NET_VENDOR_MOTORCOMM=y is introduced by rewrite-kernel-config, I guess it should be fine. How Has This Been Tested? Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration. [x] ./compile.sh BOARD=hinlink-hnas BRANCH=vendor BUILD_DESKTOP=yes BUILD_MINIMAL=yes DEB_COMPRESS=xz KERNEL_CONFIGURE=no RELEASE=jammy KERNEL_GIT=shallow [x] Tested on hinlink hnas which has 4 2.5 inch sata. Checklist: Please delete options that are not relevant. [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [x] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

Hello, everyone I used your patch @Stephen Graf https://github.com/stephengraf/armbian_build_sg/blob/main/patch/kernel/archive/sunxi-6.6/patches.armbian/sound-soc-h616.patch I found a bug when using it. If I turned on Volume Control in the middle of playing video or audio, the video or audio would suddenly speed up playing, even if I just turned on Volume Control without doing anything,very crazy😂

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?

Hi, I've tried to blacklist the driver, seemed stable but crashed after 2 weeks. At this point I don't know what else to try. For now i set kernel.panic=10 in /etc/sysctl.d/96-panic.conf to see if at least reboots when a panic happens.

Definitely, if you look at the kernel source code you can enable the codec Yes, it is. I think it is in the kernel mailing list, so it is something that is already floating around and eventually will be merged.

I meant this line: KERNELBRANCH="tag:v6.1.69" which uniquely determines which version of the kernel patches are applied cleanly. I.e. to version 6.1.69 and not to the current 6.1.90 for today.

Hasn't changed. https://github.com/armbian/build/tree/main/patch/kernel Just symlinking of subfolder are perhaps adding some confusion.