Igor
-
Posts
14421 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by Igor
-
-
A10 / A20 hdmi support was reported as broken and bug was recorded https://armbian.atlassian.net/browse/AR-2674 some time ago.
-
3 hours ago, gounthar said:
on Trixie
Here some troubles are expected ... Can you try manual steps to install docker by follow:
https://github.com/armbian/configng/blob/main/tools/modules/software/module_docker.sh#L26-L56
installing packages, adding to group, adding docker bridge.
This might reveal more.
BTW. My F3 died - waiting for replacement.
-
4 hours ago, Herman Liang said:
I will use Etcher instead of USBImager for armbian in future.
Actually its the opposite so it must have been something else. Etcher is known to be broken for bigger images (desktops). There is some bug in the .xz decompression method used by Etcher. I am using only USB imager for at least a year and haven't run into any problems. At least not on this level.
-
Images were tested. Do you perhaps use Etcher for flashing? And try minimal image. That might even work with Etcher.
-
13 hours ago, vtech said:
When will this fix be released
Just FYI why images are delayed. GitHub, which we rely our build infrastructure on, is having many troubles and builds does not start due to out of (their) resources (probably). 30 out 30 tries, I am getting
Error: Error 504: We couldn't respond to your request in time. Sorry about that. Please try resubmitting your request and contact us if the problem persists.
Perhaps this is a limitation of free tier, dunno.
-
11 hours ago, Jon M said:
if it even works in this version? If someone could help that would be great!
You can try on actual machine by editing device tree file. (/boot/dtb/rockchip/name.dtb probably rock5b something)
https://chatgpt.com/share/684bbac2-2728-8005-bb50-a2751316ac2bIf similar changes work - you need to reboot to apply changes - then report here.
-
3 hours ago, vtech said:
When
Those builds are made by automation, once per week if nothing else goes wrong. -
1 hour ago, Jon M said:
Is there a patch or something i can do to fix this?
Perhaps same bits are missing in 5b device tree?
https://github.com/armbian/build/blob/main/patch/kernel/archive/rockchip64-6.12/rk3588-1020-Add-HDMI-and-VOP2-to-Rock-5A.patchIf you get it working, make a patch and push it here: https://github.com/armbian/build/tree/main/patch/kernel/archive/rockchip64-6.12
-
Spoiler
v25.5 rolling for Orange Pi Zero2 running Armbian Linux 6.12.23-current-sunxi64 Packages: Debian stable (bookworm) Updates: Kernel upgrade enabled and 8 packages available for upgrade Support: for advanced users (rolling release) IPv4: (LAN) 10.0.30.133 (WAN) Performance: Load: 2% Up time: 15:51 Memory usage: 16% of 971M CPU temp: 54°C Usage of /: 5% of 29G Commands: Configuration : armbian-config Upgrade : armbian-upgrade Monitoring : htop igorp@orangepizero2:~$ sudo apt update [sudo] password for igorp: Dobi:1 http://deb.debian.org/debian bookworm InRelease [151 kB] Dobi:2 http://security.debian.org bookworm-security InRelease [48,0 kB] Dobi:3 http://deb.debian.org/debian bookworm-updates InRelease [55,4 kB] Dobi:4 http://deb.debian.org/debian bookworm-backports InRelease [59,4 kB] Dobi:5 https://github.armbian.com/configng stable InRelease [3992 B] Dobi:6 http://security.debian.org bookworm-security/main arm64 Packages [262 kB] Dobi:7 https://pkgs.tailscale.com/stable/debian bookworm InRelease Dobi:9 http://deb.debian.org/debian bookworm/main arm64 Packages [11,9 MB] Dobi:8 https://netcup-02.armbian.com/beta bookworm InRelease [53,3 kB] Dobi:10 http://deb.debian.org/debian bookworm-backports/non-free-firmware arm64 Packages.diff/Index [6117 B] Dobi:11 http://deb.debian.org/debian bookworm-backports/main arm64 Packages.diff/Index [63,3 kB] Dobi:12 http://deb.debian.org/debian bookworm-backports/contrib arm64 Packages.diff/Index [63,3 kB] Dobi:13 https://github.armbian.com/configng stable/main arm64 Packages [423 B] Dobi:14 http://deb.debian.org/debian bookworm-backports/non-free-firmware arm64 Packages T-2025-05-29-0204.34-F-2025-05-29-0204.34.pdiff [2665 B] Dobi:15 http://deb.debian.org/debian bookworm-backports/main arm64 Packages T-2025-06-12-0204.25-F-2025-05-14-2011.58.pdiff [31,6 kB] Dobi:14 http://deb.debian.org/debian bookworm-backports/non-free-firmware arm64 Packages T-2025-05-29-0204.34-F-2025-05-29-0204.34.pdiff [2665 B] Dobi:15 http://deb.debian.org/debian bookworm-backports/main arm64 Packages T-2025-06-12-0204.25-F-2025-05-14-2011.58.pdiff [31,6 kB] Dobi:16 http://deb.debian.org/debian bookworm-backports/contrib arm64 Packages T-2025-05-24-2017.15-F-2025-05-24-2017.15.pdiff [428 B] Dobi:16 http://deb.debian.org/debian bookworm-backports/contrib arm64 Packages T-2025-05-24-2017.15-F-2025-05-24-2017.15.pdiff [428 B] Dobi:17 http://deb.debian.org/debian bookworm/non-free arm64 Packages [93,9 kB] Dobi:18 http://deb.debian.org/debian bookworm/contrib arm64 Packages [54,5 kB] Dobi:19 http://deb.debian.org/debian bookworm/non-free-firmware arm64 Packages [6407 B] Dobi:20 https://netcup-02.armbian.com/beta bookworm/bookworm-utils all Packages [3873 B] Dobi:21 https://netcup-02.armbian.com/beta bookworm/bookworm-desktop all Packages [2104 B] Dobi:22 https://netcup-02.armbian.com/beta bookworm/bookworm-utils arm64 Packages [29,8 kB] Dobi:23 https://netcup-02.armbian.com/beta bookworm/main all Packages [1585 B] Dobi:24 https://netcup-02.armbian.com/beta bookworm/main arm64 Packages [262 kB] Dobi:25 https://netcup-02.armbian.com/beta bookworm/bookworm-desktop arm64 Packages [3252 B] Pridobljenih 13,2 MB v 3s (4139 kB/s) Branje seznama paketov ... Narejeno Gradnja drevesa odvisnosti ... Narejeno Branje podatkov o stanju ... Narejeno 44 packages can be upgraded. Run 'apt list --upgradable' to see them.Unable to reproduce. Probably date and time is out of sync.
Edit: aha, this is / was the problem:
https://github.com/armbian/build/commit/aa5526a9189097b87ada0784cff61bda85e46609Which means next week community build will have this auto-fixed.
-
10 minutes ago, Ryzer said:
I can only guess
Me too. I was not paying attention to this due to dealing with many non technical things in past few months and as already mentioned, those upgrades are not being tested on older boards. We simply don't have enough resources, test automation is limited - HDMI is not tested in any case. There is more or less just one main person doing general maintenance on Allwinner with occasional help of random people.10 minutes ago, Ryzer said:kernel 6.14 already has the changes adopted so does not need to be patched. I appreciate that boards like the pcduino2 are over a decade old now and not likely to achive the same attention as something like the orange pi zero.
6.14 is already EOL and we just switched to 6.15 (EDGE branch), but we will probably stay on stable CURRENT branch with 6.12.y for awhile as its fairly stabilized in general across several platforms. IMO it is best to backport this patch for 6.12.y or fix whatever breaks this.
-
On 6/7/2025 at 9:59 PM, pcduino2user said:
but there seems to be no hdmi signal coming from the port
I have noticed regression on A20, probably also on A10 few weeks ago ... but so far we haven't been able to do anything - almost no active developer have those boards. ... and Welcome!
-
Welcome!
1 hour ago, shirkit said:I need to to something else
This question is a bit off topic here as general Armbian updates are not part of HA extension. As this is community supported hardware, stable BSP upgrades - where OS version is stored - might not be generated, while kernel and everything else is getting upgrades. tl;dr; Don't worry about this. For board related topics proceed here https://forum.armbian.com/forum/173-allwinner-sunxi/
-
1 hour ago, armbuilder said:
Are platinum supported boards not tested on actual hardware before posting images?
Yes, that is the main idea, but sometimes things slipped trough. Images were tested (we aim to have two people on one platinum target to be able to provide better service, but perfection is still not possible), but here we ran into weird problem that CI compilation silently broke on u-boot recompilation, while local build works. We have a problem with build framework / compiler internals, unrelated to this specific hardware and problem only manifest on some u-boot variants. Right now, I don't have a clear picture, but we are working on it. This was introduced while moving framework to Noble, which is mandatory for some targets and there are some Python libraries troubles ... which are sometimes used for u-boot / ATF compile. Its a mess.
1 hour ago, armbuilder said:not sure if all the USB/wifi related driver issues were fixed?
Software maintenance within such extreme complexity is job that is never done. Generally speaking. -
Yeah, it was reported at GH too:
https://github.com/armbian/build/issues/8227Probably related:
https://github.com/armbian/build/issues/8269
No solution yet. -
We do have 3A https://fi.mirror.armbian.de/incoming/igorpecovnik/rock-3a/archive/ (need report if this latest build works) and build config for 3C but not 3B. Does it make sense to make for 3C too or 3A can cover them all. I don't have any of those, so I can't check.
-
He probably meant upstream driver version v5.7.9_35795.20191128
https://github.com/jwrdegoede/rtl8189ES_linux/blob/rtl8189fs/include/rtw_version.h
and by looking into Makefile it feels as we are in 2010
-
1 hour ago, CaWeissWz said:
it would really be helpful to have the drivers already in the official armbian builds.
Welcome to submit PR here:
https://github.com/armbian/build/tree/main/config/kernel
Best to all those configs:
-
19 minutes ago, ricardo_brz said:
built-in audio is not
I think this is handled with overlay "audio" "analogue" or something similar.https://docs.armbian.com/User-Guide_Armbian-Config/System/#device-tree-overlays
-
1 hour ago, Kevin Hoang said:
Is there a newer version available?
No and we can't get new one as it doesn't exists. Common practice is that vendor drops driver sources to the wild and never look back. All costs of maintenance are on few people in and around this community and similar (volunteer based) projects that deals with Linux wireless. This chip is probably only used by few (Orangepi) single board computers and perhaps some Android tablets, TV boxes. Which are not in our focus anyway.
There is some community efforts to bring such drivers to mainline code, but I doubt this chip will ever find a way there - and this doesn't mean that it will work better. Check here
https://github.com/torvalds/linux/tree/master/drivers/net/wireless/realtekif there is any sign of it.
-
3 hours ago, dart wejder said:
And now I see that the HA team considers the supervised method unsupported.
This method will keep working for years and I will try to fix problems as long as they won't take too much time.
3 hours ago, dart wejder said:The issue is that these images do not have a boot partition.
Most of Armbian images doesn't have boot partition as it is not needed.
3 hours ago, dart wejder said:I tried to install using a flash drive with a boot partition from pure Armbian. But this trick did not work.
Most of boards does not support boot from flash drive, but from SD card.
3 hours ago, dart wejder said:you can tell me how to install it correctly.
I have absolutely no clue. There is a whole section of Armbian community forums that are dealing with the complexity of booting weird TV box hardware. I suggest you to start here:
https://forum.armbian.com/forum/189-faq/3 hours ago, dart wejder said:image for Odroid C4, since it is for the same processor as the current TV box on Amlogic s903 x3.
It is enough that board uses different memory modules and device won't give any sign of life. When you manage to boot Armbian Bookworm with help from TV box section, use armbian-config.
-
10 minutes ago, guy cal said:
Which image can be used for a orangepipc2
Well, for Home Assistant, Armbian / Debian Bookworm image is required. That we usually provide for all variants, supported and not supported. Since this hardware is not actively maintained, we don't know if there are any hardware level issues related to this board. Here you are on your own, hope for / wish you luck. Usually things works ... Next step is this: https://docs.armbian.com/User-Guide_Armbian-Software/HomeAutomation/#home-assistant It will provide the same result as image with pre-loaded Home Assistant.
-
2 hours ago, Rocky said:
I am entirely new to Armbian.
Welcome to Armbian forums. Most of general questions are answered in:https://docs.armbian.com/
https://docs.armbian.com/User-Guide_Board-Support-Rules/
Remove those you will get answers there ...
-
8 hours ago, äxl said:
with Home Assistant Application from your site as soon as the board arrives.
I would suggest you to download clean Debian minimal image and proceed this way:
https://docs.armbian.com/User-Guide_Armbian-Software/HomeAutomation/#home-assistantEVCC can be installed this way - official Docker container:
https://docs.armbian.com/User-Guide_Armbian-Software/HomeAutomation/#evcc
8 hours ago, äxl said:It is available as an HA add-on
How to deal with EVCC from HA, no idea. This is application level knowledge and I am just an average user of HA. I assume addon will want to connect to the service which runs on some IP address and some port. IMO this part is similar as official HAOS image.
8 hours ago, äxl said:What is the right way to go? Install it as an add-on on Home Assistant or install it as an Armbian package?
Current application images are not yet rebuild with latest stable base, so until then its better going clean Debain + armbian-config way. -
52 minutes ago, Torte said:
Updating homeassistant-supervised with apt-upgrade first showed a selection box of the used hardware
I see. This package is done bad in first place. No wonder they decide to simply drop everything ... Most of people anyway use embedded HAOS.Then we should not adding updated packages to the repository anymore.
What is the latest version of the RTL8189FS driver?
in Beginners
Posted
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