Active threads

When I flash the Ubuntu 22.04 firmware from the board's developers - https://wiki.luckfox.com/Luckfox-Lyra/Image-flashing everything works fine. I flash it using the same methods as Armbian. If I flash the Armbian image, the device doesn't work. Therefore, I conclude that the quote "Random behavior is mostly due to hardware issues. So, powersupply is not OK, or bad storage, or the flashing introduces corrupt data blocks on the storage, a bad cable, or bad Windows computer/software." has absolutely nothing to do with it. Log 2 is immediately after rebooting after flashing. Log 1 is after the second reboot; this happens (not always). I tried flashing the firmware both through Linux and the rkdeveloptool program. Board into Maskrom mode rkdeveloptool ld rkdeveloptool ef sudo rkdeveloptool wl 0 Armbian-unofficial_26.02.0-trunk_Luckfox-lyra-ultra-w_trixie_vendor_6.1.115_minimal.img sudo rkdeveloptool rd The firmware update worked perfectly, without any errors. But after rebooting, the device was inaccessible. I flashed the image at address 0x0 using the RKDevTool_Release_v3.31 program in Windows - the result is the same. I compiled the firmware myself with these parameters ./compile.sh BOARD=luckfox-lyra-ultra-w BRANCH=vendor KERNEL_CONFIGURE=no DEB_COMPRESS=xz KERNEL_BTF=yes INSTALL_ARMBIAN_FIRMWARE=no BUILD_DESKTOP=no BUILD_MINIMAL=yes RELEASE=trixie The firmware was flashed perfectly without errors - after rebooting the device is inaccessible. I downloaded the firmware from Luckfox Lyra Ultra W here - https://github.com/armbian/community/releases since the first release (tried everything) The firmware was flashed perfectly without errors - after rebooting the device is inaccessible. I think the hardware problem is not in my device (since everything works on other firmware), but the problem is in the armbian firmware itself. I'm really hoping that at least one person who has this board will come along and try installing this firmware. I'm curious to see if it works for them. 🙂

https://github.com/ptitSeb/box64/issues/3146#issuecomment-3630691360 Optimize is on the way, just wait!

Is it possible to switch the operation to the OpenWRT system OR Linux OR DTB Q17 android tv box = Tanix TX11 android tv box = Q1 android tv box .... Works but ≠ X96Q android tv box AND ≠ Tanix TX1 android tv box .... It doesn't work current system firmware: Android 14 specs: - ARM Cortex-A53 - 32 bit - Mali-G31 - Allwinner H313 - arm,sun50iw9p1 4 GB RAM DDR3 32 GB HDD model = "sun50iw9"; compatible = "arm,sun50iw9p1";

I would take this as a base: https://wiki.friendlyelec.com/wiki/index.php/NanoPi_NEO2#Set_Audio_Device I have several H3 NanoPi-NEO and use their on-board audio HW. If you want external audio HW, dig deep into Armbian GPIO config, it can be set with some text in armbianEnv.txt, but all depends the board pinout and just reading H5 SoC datasheet for pin and signal codes how to map. Done that for an AllWinnner A20 board and lot of internet searching as well.

these modules/configs are missing in 6.16.8 (vs 6.15.4): CONFIG_SND_SUN9I_HDMI_AUDIO=y CONFIG_SND_SOC_SUNXI_MACH=m CONFIG_SND_SOC_SUNXI_AHUB=m CONFIG_SND_SOC_SUNXI_AHUB_DAM=m CONFIG_SND_SOC_SUNXI_INTERNALCODEC=m CONFIG_SND_SOC_SUNXI_AAUDIO=m Could this be a problem?

Hi again and thank you for the new reply. Something went wrong with the mip-dsi 7" display on that board somewhere between 6.1.104 (02/02/2025) and 6.6.750 (03/02/25). I already sourced those from the armbian-config kernel loader tool and confirm that the display works perfectly on the 6.1 kernel and d-t and not on 6.6, with no other changes. None of the more recent kernels work either. I figured that if I could find the exact kernel version where things broke, I might just be able to diff what changed, but 6.1 to 6.6 is a big gap. Any other suggestions? I don't see any significant changes in the logging (uboot unfortunately not available as I don't have a serial connector.), but the screen is picked up and loaded to the d-t. There's just no output. The screen is grey and noisy right from startup - no startup messages or anything at all, with no visible picture signal on 6.6. From 6.12 on it is completely black, although backlight appears to be there. Are any

Hello Respected Supporters, After upgrading to Armbian 26 (kernel version 6.12.58), the onboard network card (end0) experienced a severe degradation in transmission performance (reduced to approximately 1/10 of previous levels). Upon investigation, it was discovered that the kernel driver (dwmac-sun8i) has locked all hardware offload features (TSO/GSO/Checksum), forcing the CPU to handle all processing in software. root@orangepi3:~# uname -r 6.12.58-current-sunxi64 root@orangepi3:~# dpkg --list | grep linux-image ii linux-image-current-sunxi64 26.2.0-trunk.48 arm64 Armbian Linux current kernel image 6.12.58-current-sunxi64 root@orangepi3:~# readlink /sys/class/net/end0/device/driver ../../../../bus/platform/drivers/dwmac-sun8i root@orangepi3:~# ethtool -k end0 Features for end0: rx-checksumming: off tx-checksumming: off tx-checksum-ipv4: off tx-checksum-ip-generic: off [fixed] tx-checksum-ipv6: off tx-checksum-fcoe-crc: off [fixed] tx-checksum-sctp: off [fixed] scatter-gather: off tx-scatter-gather: off tx-scatter-gather-fraglist: off [fixed] tcp-segmentation-offload: off tx-tcp-segmentation: off [fixed] tx-tcp-ecn-segmentation: off [fixed] tx-tcp-mangleid-segmentation: off [fixed] tx-tcp6-segmentation: off [fixed] generic-segmentation-offload: off generic-receive-offload: off large-receive-offload: off [fixed] rx-vlan-offload: on [fixed] tx-vlan-offload: off [fixed] ntuple-filters: off [fixed] receive-hashing: off [fixed] highdma: on [fixed] rx-vlan-filter: off [fixed] vlan-challenged: off [fixed] tx-gso-robust: off [fixed] tx-fcoe-segmentation: off [fixed] tx-gre-segmentation: off [fixed] tx-gre-csum-segmentation: off [fixed] tx-ipxip4-segmentation: off [fixed] tx-ipxip6-segmentation: off [fixed] tx-udp_tnl-segmentation: off [fixed] tx-udp_tnl-csum-segmentation: off [fixed] tx-gso-partial: off [fixed] tx-tunnel-remcsum-segmentation: off [fixed] tx-sctp-segmentation: off [fixed] tx-esp-segmentation: off [fixed] tx-udp-segmentation: off [fixed] tx-gso-list: off [fixed] tx-nocache-copy: off loopback: off [fixed] rx-fcs: off [fixed] rx-all: off [fixed] tx-vlan-stag-hw-insert: off [fixed] rx-vlan-stag-hw-parse: on [fixed] rx-vlan-stag-filter: off [fixed] l2-fwd-offload: off [fixed] hw-tc-offload: off [fixed] esp-hw-offload: off [fixed] esp-tx-csum-hw-offload: off [fixed] rx-udp_tunnel-port-offload: off [fixed] tls-hw-tx-offload: off [fixed] tls-hw-rx-offload: off [fixed] rx-gro-hw: off [fixed] tls-hw-record: off [fixed] rx-gro-list: off macsec-hw-offload: off [fixed] rx-udp-gro-forwarding: off hsr-tag-ins-offload: off [fixed] hsr-tag-rm-offload: off [fixed] hsr-fwd-offload: off [fixed] hsr-dup-offload: off [fixed] Could you please help look into this issue? We are looking forward to seeing it fixed in an upcoming release. Thank you very much. Regards, GBH

@Octavio Cuatrochio, your box is locked no more than others. ADB over USB doesn't work on all versions. su works only through uart console. Toothpick method is only for recovery from backup partition (so 'upgrade' is not really upgrade - it's reflashing from backup). What to check: 1. Check you haven't shorted Tx and Rx to +3.3V. bus (trace between two test points). 2. Are Gnd's of the usb converter and tv box connected? 3. You have some switches on usb converter - what it is for? I/O voltage select? 4. Make sure you open serial port on PC with 115200 8n1 settings without hardware or software flow control. 5. You've checked it while lines was free-floating or connected to usb converter? If last, make measurements without usb converter connected. About performance of Android and Armbian: idk. Current Android firmware is 32-bit. But, according to datasheet, Hi3798MV310 have 64-bit core. So, if you manage to create 64-bit build of Android or Armbian, I suppose it should have slightly better performance.

@robertoj Thank you very much for your reply! I sincerely apologize for any misunderstanding. When I mentioned the 16-bit option, I was referring to the selection made when setting up the Armbian image. This option is located in the same menu as the mipi_panel_dbi support option. I mentioned this in my comment because I was a bit confused by the "but the greeter is not" part of your response. I probably just needed to enable the mipi_panel_dbi support parameter and continue building without adding any additional parameters. I use a screen with a red board on the ili9488 driver, the Chinese version for sure. I'd also like to clarify with someone who's already done this, whether I'm following all the steps correctly. If that's possible, please let me know within this forum thread. - I'm building a minimal image. - First, I use the DTS file from the thread you provided as a response. - After I see the image on the screen, if the colors are incorrect, I use the file provided by Pancake. Please forgive me again. In the thread you provided as a solution, I don't understand the sequence of actions and where I should start. Once again, I apologize for my meticulousness.

If that doesn't do it, try the main integration branch which for once combines all branches and for the other is actually meant to be used by megi iirc:https://codeberg.org/megi/linux/commits/branch/orange-pi-6.18

First step is to cleanup and bump the sunxi patchset to 6.18. This is a major blocker. Once that is done. Patches for more recent Allwinner SoCs can be added. I started doing that but it is extremely exhausting. I have no clue how the-going managed to maintain that for that long... must be sort of masochistic or something lol. https://github.com/EvilOlaf/build/tree/sunxi-6.18

Not an Armbian uboot binary. Also we started to drop vendor uboot in favor of mainline.

Hi Igor, I recently updated to Armbian 25.11.2 bookworm aarch64 with kernel Linux odroidhc4 6.12.58-current-meson64. This should be a working version? There I still get the same connect-debounce error. Do you have any advice?

Hi all, i've been going this forum long enough to try and root a tv box that i buyed recently, but this one is HEAVILY locked up, like nothing i have seen before. My objective here is to access 'su' so i can have access to rooting/overclocking this thing for emulators, and after that adding a heatsink, active cooling, etc. I tried ADB over all USBs (4 in total) but nothing. then i tried to see if root was available through some leftover app or vulnerability, but nothing. Then i tried following the specs from this thread (pretty similar in design to my PCB) but my UART displays nothing. (I leave the images from my setup below), i tried switching the wires, i tested the voltages and they return 3.3v, so they are ok. I tried the toothpick method to access recovery, but it has 2 buttons. 1 does nothing (AFAIK) and the other one goes directly to updating, so no menu. Any help is appreciated, as i'm out of any ideas. I leave my pictures below, and my specs: CPU: Alwinner H313 RAM: 1GB ROM: 8GB PCB: Z01S-v13.3, 2025.05.20 OS: Android 7-8 ish

Also, interesting to see your updates. I keep seeing a lot related to GStreamer, will need to look more into that.

I think you are looking for the "kernel" build command. Have a look at some of the others as well like kernel-config or dts-check.

Thank you for sharing your findings with the community!

Yes. Try the latest kernel. The latest is always the one with the most corrections (unless someone discovers an error). How do you select a H616 vs H618 kernel? I always select Unsupported Board > Orange Pi Zero 3

That photo tells me that you have the SPI and GPIO configuration right. Keep that. The completed solution for orange pi zero 3 and ili9341 is: https://forum.armbian.com/topic/44191-orangepi-zero-lts-ili9341-tft-lcd-and-later-orangepi-zero-3/#comment-204672 Copy the parts within the ili9341:ili9341@0 {} section, while keeping your gpio

Okay, trying another HDMI cable fixed it, although on radxa's debian it worked with the same cable but thanks.

I ran into a similar issue, I think it was related to having the wifi usb adapter plugged in at the same time. after a second reboot with the adapter unplugged I was able to get to the first run setup screen and set the root password and create my local user account. new to armbian, replaced a failed image from the stock odroid c1+ ubuntu 18 release with the latest, was happy to get it up and running, as we used this board to drive our home 3d printer. unrelated - i did apply to be a board maintainer, happy to help if/when/where I can

Hi @wolf7250, The $PWD is an environment variable that represents the current working directory. The lone period "." also represents the current working directory. $PWD has nothing to do with your password - unless your folder names are the same as your password and/or vice versa. As to your question, yes, I would think a fresh reinstall from scratch is going to be the best way forward. But I have no idea how easy that will be with transferring OMV settings from old to new etc. OMV is unbeknownst to me. On the other hand, if the workaround with the new load addresses in `armbianEnv.txt` work (and they seem to work just fine) it's more of a matter of how "correct" you want your situation to be. Things seems to be working. Groetjes,

Here the link to the video. Thanks to Mike from Mekotronics. https://mekotronics.wetransfer.com/downloads/9a21fbbbd8123b75cb5119d632bb565020251208034519/a7c7d3?t_lsid=dd63b65e-c41d-4c4e-81ea-66eea92954d0&t_network=link&t_rid=YXV0aDB8NjE4ZTI0ZjkyMDYzZGYwMDY5Y2FhMmFh&t_s=download_link&t_ts=1765165519

@snowbody you are using an older version of the driver with the current version of the display-service. That won't work. Since you are on 6.12 kernel, start by cloning the main branch of https://github.com/jefflessard/tm16xx-display.git it already contains the line-display backport.

Maybe this will work https://xdaforums.com/t/how-to-use-otg-in-twrp.3097688/