Active threads

Hello! I try to flash my H96Max on RK3318 but i cannot load armbian. After success flash armbian to emmc i remove sd and nothing, nothing load and nothing in uart port, only red led light and thats all. Здравствуйте! Я пытаюсь прошить свой H96Max на RK3318, но не могу загрузить armbian. После успешной прошивки armbian на emmc я извлекаю SD-карту, и ничего, ничего не загружается и ничего не отображается в последовательном порту, только красный светодиод и всё. when i'm load from sd multitool i get this log from uart i'm try to find u-boot on my h96max emmc and nothing, first 100bytes empty. Where i can get u-boot? LoadLog.txt

Hello, Any update of this?

They will provide you new drivers only if you will pay them to do that for you. End users, including this project, can do nothing about - we have negative budget and can only do best-effort work to keep those drivers at least operational with recent kernels: https://github.com/armbian/build/tree/main/patch/misc while bulk of the patches goes directly to the Git of specific driver. What you are hoping exceeds ability of amateur maintainers, those few people that are actually looking into the code and fix bugs that are made by kernel API changes. HW vendor is usually long gone from there - their development capacity is also limited and they are focused into current products. FYI

A10 / A20 hdmi support was reported as broken and bug was recorded https://armbian.atlassian.net/browse/AR-2674 some time ago.

there are a few caveats that may need a bit of attention It is documented somewhere that if you use channel 0, the driver would automatically select an appropriate channel / frequency. However, it seemed that back then initially while I tested it, that didn't seem to work. (i'm not sure if it may have changed) hence to list the channels one needs to run iw list and you would get a list of channels like such * 2412 MHz [1] (20.0 dBm) * 2417 MHz [2] (20.0 dBm) * 2422 MHz [3] (20.0 dBm) * 2427 MHz [4] (20.0 dBm) * 2432 MHz [5] (20.0 dBm) * 2437 MHz [6] (20.0 dBm) * 2442 MHz [7] (20.0 dBm) * 2447 MHz [8] (20.0 dBm) * 2452 MHz [9] (20.0 dBm) * 2457 MHz [10] (20.0 dBm) * 2462 MHz [11] (20.0 dBm) * 2467 MHz [12] (20.0 dBm) * 2472 MHz [13] (20.0 dBm) * 2484 MHz [14] (20.0 dBm) * 5170 MHz [34] (disabled) * 5180 MHz [36] (20.0 dBm) * 5200 MHz [40] (20.0 dBm) * 5220 MHz [44] (20.0 dBm) * 5240 MHz [48] (20.0 dBm) * 5260 MHz [52] (20.0 dBm) (radar detection) * 5280 MHz [56] (20.0 dBm) (radar detection) ... * 5720 MHz [144] (20.0 dBm) (radar detection) * 5745 MHz [149] (20.0 dBm) * 5765 MHz [153] (20.0 dBm) * 5785 MHz [157] (20.0 dBm) * 5805 MHz [161] (20.0 dBm) * 5825 MHz [165] (20.0 dBm) what I normally do is to do a scan and pick an unused / least used channel : iw wlan0 scan pick an appropriate channel and specify it in hostapd.conf. 5ghz channels (hw_mode=a) delivers a max throughput of like 140 Mbps which is fast. https://docs.armbian.com/WifiPerformance/#uwe-5622 accordingly there are some country specific requirements for 5ghz channel selections and one may like review https://en.wikipedia.org/wiki/List_of_WLAN_channels iw reg set etc I did a google search and some of these resources may be useful https://wiki.archlinux.org/title/NetworkManager https://www.baeldung.com/linux/nmcli-wap-sharing-internet in a same way you may need to set the channel if necessary then that this repo is found in a google search which may be useful https://github.com/pi-top/Wi-Fi-Access-Point-and-Station-Mode/tree/master

I'm trying to compile an LED display driver: https://github.com/arthur-liberman/linux_openvfd I follow this description: https://github.com/bk3a12/openvfd_enable_for_tx3_mini However, I can't build anything and the whole process ends with errors: sh ./scripts/modules-check.sh /home/user/INSTALKI/linux_openvfd/driver/modules.order make -f ./scripts/Makefile.modpost make[3]: *** No rules to make an object '/home/user/INSTALKI/linux_openvfd/driver/modules.order', required by '/home/user/INSTALKI/linux_openvfd/driver/Module.symvers'. Stop. make[2]: *** [/usr/src/linux-headers-6.12.33-current-meson64/Makefile:1897: modpost] Error 2 make[1]: *** [Makefile:224: __sub-make] Error 2 make[1]: Leaving the directory '/usr/src/linux-headers-6.12.33-current-meson64' make: *** [Makefile:5: modules] Error 2

@werner Sorry the delay, I was trying to get the TTL adapter. Here is what I get from the TTL in the first boot after flashing Armbian_community_25.8.0-trunk.228_Orangepi5pro_bookworm_vendor_6.1.115_minimal.img DDR 9fa84341ce typ 24/09/06-09:51:11,fwver: v1.18 ch0 ttot6 ch1 ttot6 ch2 ttot6 ch3 ttot6 ch0 ttot7 LPDDR5, 2400MHz channel[0] BW=16 Col=10 Bk=16 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=4096MB ch1 ttot7 channel[1] BW=16 Col=10 Bk=16 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=4096MB ch2 ttot7 channel[2] BW=16 Col=10 Bk=16 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=4096MB ch3 ttot7 channel[3] BW=16 Col=10 Bk=16 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=4096MB Manufacturer ID:0xff DQS rds:l0,l0 CH0 RX Vref:27.1%, TX Vref:20.0%,20.0% DQ rds:h3 h4 h2 h1 h5 h2 h2 h1, h1 h3 h3 h5 h1 h3 h2 h2 DQS rds:l0,h1 CH1 RX Vref:27.9%, TX Vref:21.0%,20.0% DQ rds:l0 h1 h2 h3 h6 h2 h3 h6, h4 h2 h2 h2 h2 h1 h4 l0 DQS rds:l0,l0 CH2 RX Vref:26.7%, TX Vref:19.0%,21.0% DQ rds:h3 l0 l0 l0 h4 h1 h7 h3, h2 l0 h1 l0 h2 h4 h1 h1 DQS rds:l0,h1 CH3 RX Vref:27.9%, TX Vref:20.0%,20.0% DQ rds:h5 h3 h7 h4 h2 h2 h4 h4, h4 h3 h4 h2 h3 h1 h3 h1 stride=0x2, ddr_config=0x6 hash ch_mask0-1 0x20 0x40, bank_mask0-3 0x0 0x2400 0x44800 0x89000, rank_mask0 0 x2000 change to F1: 534MHz ch0 ttot6 ch1 ttot6 ch2 ttot6 ch3 ttot6 change to F2: 1320MHz ch0 ttot8 ch1 ttot8 ch2 ttot8 ch3 ttot8 change to F3: 1968MHz ch0 ttot6 ch1 ttot6 ch2 ttot6 ch3 ttot6 change to F0: 2400MHz ch0 ttot7 ch1 ttot7 ch2 ttot7 ch3 ttot7 out U-Boot SPL board init U-Boot SPL 2017.09 (Jun 13 2025 - 02:18:34) unknown raw ID ff ff ff unrecognized JEDEC id bytes: ff, ff, ff Trying to boot from MMC1 Card did not respond to voltage select! spl: mmc init failed with error: -95 Trying to boot from MMC2 Card did not respond to voltage select! spl: mmc init failed with error: -95 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ### # Reset the board to bootrom # Not sure if it matters, but I have a EMMC installed and flashed the image to it using the rkdevelop tool. ( The same way I do to flash the firmware from orangepi site ) Just in case, here are the commands I use ./rkdeveloptool db MiniLoaderAll.bin ./rkdeveloptool wl 0 Armbian_community_25.8.0-trunk.228_Orangepi5pro_bookworm_vendor_6.1.115_minimal.img ./rkdeveloptool rd

Hi, I also tried to run this sensor, tried different ports but to no avail. maybe you found a way to solve this problem?

Hi! So, I tried this overlay, and the device still did not detect USB. Although when I tried switching the dts file to the topwise a721, the HDMI stopped working but USB devices were correctly detected. On top of that, no the display still does not work even with the topwise device tree. I checked the RAM clock speed with the command you mentioned and it said 432000000, which is much higher than what I found from the boot file from original Android (384000000). Is there a way I can rebuild just u-boot and install it in this working image?

Share the image of your assembly, preferably server-side.

I think I solved it! In the upgraded system there was no package pahole! After I installed the pahole and reinstalled the package linux-headers-6.12.33-current-x86, I got the BTF stuff as described above in the .config file and I can compile modules! Pfff, finally! I checked the Raspberry Pi 4 version, I see no pahole package installed there, and I can compile modules and zfs. I don't see any BTF stuff in the .config there also. So, I don't know what is really going on here, I should install pahole on arm64 systems as well? And should pahole not be included when you upgrade your system to 25.5.1 ?

Thanks a lot for your help, Igor. That did not make the trick, as the available packages are still in the old form (docker.io instead of docker-ce for example. Nonetheless, I now have a working (but old) docker binary, which is enough for my use case. Now, I will try to build a more recent docker binary. The next problem to solve will be to get the NVMe to work. I'm sorry your F3 died.

accordingly H618 do not have mic in hardware https://www.cnx-software.com/2023/07/03/orange-pi-zero-3-allwinner-h618-sbc-ships-with-up-to-4gb-ram/ hence, an option is to use a usb soundcard / dongle https://www.aliexpress.com/w/wholesale-usb-sound-card.html there are also those 'arduinoish' approaches e.g. to use a ADC module board e.g. https://www.ti.com/lit/ds/symlink/ads1110.pdf https://www.aliexpress.com/w/wholesale-ads1110.html https://www.instructables.com/Arduino-and-the-TI-ADS1110-16-bit-ADC/ but that you would need to hack the pin interfaces to use i2c etc. note it seemed ads1110 is a bit too slow for sound. alternatives are like stm32, which has built-in adc that can go to like 1-2.5 Msps, but you would need to hack the spi interface etc. the 'easiest / cheapest' way seemed to be generic 'usb sound cards'

Has a fixed image been posted? Just upgraded to 25.5 from 25.2, so havent tested a new image download yet.

probably best to specify location for any sales offer

What is the status here?

@Nguyễn Tất Hùng If you want to use Armbian, you should start here: https://www.armbian.com/amlogic-s9xx-tv-box/ And specifically look at the link to the Status of TV Boxes on Armbian information.

Improving access, flexibility, and CI integration for development boards, making it easier for developers to work with embedded hardware, no matter where they are. View the full article

@ScoreABSM I don't think that is the reason? No, I haven't solved the Bluetooth issue. I have theories, but I still haven't cracked the nut. You are more than welcome to give it a whirl

Nice Are you going to use apps that will need high fps? If so, comment about the performance. Does the touch function feel steady and reliable? (dragging windows without jumpiness, with the stylus) The app for keyboard emulation with touch screen is "matchbox", if you need it.

@Igor, all just like to say that I installed Armbian_community_25.8.0-trunk.228_Orangepizero3_bookworm_current_6.12.30_minimal.imgArmbian_community_25.8.0-trunk.228_Orangepizero3_bookworm_current_6.12.30_minimal.img from the boards page https://www.armbian.com/orange-pi-zero-3/ apt update works 'out of the box', no PUBKEY errors thanks for the the updates @vtech, you may like to try the same for orange pi zero 2

Hi, thank you for your comments, at least I learned about the SysRq sequence this way. I actually have no clue which process should send this sequence, an hardware issue of the RX line seems also unlikely to me (very short wire to the RS232-USB converter). The only additional observations: -it is a rare event, 24x7 system, most recent events: Jun 9th: at the end of a shutdown sequence Jun, 5th: no obviously related entries in syslog before it May, 28th: no obviously related entries in syslog before it May, 24th: at the end of a shutdown sequence May, 23rd: at the end of a shutdown sequence May 22nd: at the end of a shutdown sequence -it always occurs in pairs, timestamps separated by some µs, e.g. 16:50:49.191219 and 16:50:49.191355 Meanwhile on v25.5.1 for Banana Pi Pro running Armbian Linux 6.12.30-current-sunxi. I guess I will have to live with this effect, which is not harmful as long as the system continues to run. Greetings.

Here are some:https://github.com/armbian/community/releases/

I have the same problem, and for me it seems unrelated to kernel revisions. I have a whole bunch of Orange Pi Zeros, all running the same kernel and all with the same updated packages. However, the ones that run from old SD cards and have been updated from earlier releases, they reboot fine, while those that running from relatively recently flashed SD cards struggle and halt instead of reboot. Since this is super annoying, I wish to find out what's causing this, so I will do some diffing between the systems to see if I can find the culprit.

Bumps dtschema from 2025.2 to 2025.6.1. Commits 18ac2d8 validator: Fix ordering issue with properties referencing another property 4dbacd6 tests: Add test for DTSchema.check_schema_refs() 2c5f057 schema: Rework instantiating DTSchema.validator 19c88b9 schemas: gpio-nexus-node: Fix schema $ref paths fb770c7 schema: Fix a false positive unevaluatedProperties/additionalProperties check b7f612c schemas: reset: Add '#reset-cells' into schema 7e3ef3e schemas: reset: Add descriptions from original text binding 53a2132 meta-schemas: nodes: Allow if-then-else directly in patternProperties objects 9d1305d schemas: PCI: Add standard PCIe WAKE# signal 49451a5 schemas: root-node: Add 'all-in-one' chassis-type Additional commits viewable in compare view Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase. Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: @dependabot rebase will rebase this PR @dependabot recreate will recreate this PR, overwriting any edits that have been made to it @dependabot merge will merge this PR after your CI passes on it @dependabot squash and merge will squash and merge this PR after your CI passes on it @dependabot cancel merge will cancel a previously requested merge and block automerging @dependabot reopen will reopen this PR if it is closed @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) View the full article