-
Posts
14420 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by Igor
-
-
9 hours ago, fss-hacks said:
is so hard to find any info from anywhere about the Armada 1500 running anything
Welcome to custom hardware / division exotics / subdivision retro
It is hard already when its new custom hardware and main division. If nobody ported HW to mainline Linux and keep it operational, its usually quite a long path. Armbian provides build framework, that helps in the process, but hard work is still on the one that will deal with the SoC - here you can hope to find someone on forum(s) to share some specific ideas.
Adding is fairly straightforward https://docs.armbian.com/Process_Contribute/#adding-a-new-board but if there are sources for boot loader, sources for kernel, or better - support in the mainline kernel. Even when you have all this, it can still be quite challenging. Each such board usually require more people, a team.
On 7/1/2025 at 7:34 AM, fss-hacks said:I see that there are 2 development boards made by Marvell listed here but they are vastly different processors.
When I recall how many months we lost on one of Marvell's 🤔 Espressobin is an example how board support can be made super complicated - check history from day one. If board support package is on that level ... its worse out of all we have seen here. And now its an old hardware, not interesting so much. And remain broken as we don't have anyone to deal with it / its not worth.
-
14 hours ago, CDit said:
Any ideas why this happens?
Feature regressions are expected - Linux kernel is complicated machinery and without spending hours, a day or a week investigating, it's usually not possible to tell.
We don't touch Rpi kernels much. We have our own kernel config, but we use official Rpi sources, so I guess 1st step would be looking if someone reported something similar https://github.com/raspberrypi/linux/issues14 hours ago, CDit said:selected newer kernel
By newer you mean 6.12.y, 6.16.y ... or 6.6.63 -> -
1 hour ago, TRay said:
did an Armbian update where there is a new U-Boot v2025.04
I hope you flashed u-boot from armbian-install ? U-boot package does not update u-boot automatically. -
1 hour ago, adron said:
I managed to run UWE5621DS (wifi and bluetooth) on OpenWRT (linux kernel 6.6). WiFi works stably in client mode. Bluetooth too.
It works with Armbian too. Just two years ago it was not in good condition -
-
10 hours ago, Anb_o7 said:
I'll see if I can bisect the linux-image versions to find which one introduced the bug.
Check this thread -
Gnome uses Wayland and there some features don't work ... switch to X, where you will loose some functions, but remote desktop will work.
FYI:
https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277
-
7 hours ago, TRay said:
- whether u-boot for OZPI v3 will be in version 2025.04 and is the estimated date known?
-
10 hours ago, bmikulas said:
Thank you, than i try with Gnome, without the Ubuntu bloat that should be okay still if i just using desktop for doing some admin stuff.
Perhaps try one of these https://docs.armbian.com/User-Guide_Armbian-Software/Management/ They cover most of the use cases.
Otherwise, XFCE is lighter and more appropriate for the job. -
44 minutes ago, bmikulas said:
gnome has the best as i know but its a bit heavy on memory, do you know any lighter one?
We don't provide anything lighter then Gnome and there are some weird desktops in the build system, which most likely don't assemble as they are abandoned for a long time.I am not a Desktop guru ... perhaps someone else could give you other suggestions. I think Gnome is still the safest way, even it might eat more. But our Gnome is at least more or less vanilla, so no (Ubuntu) stuff coming with it.
-
4 hours ago, bmikulas said:
Sadly as it seems the hardware acceleration is not supported i guess because there is no HDMI port on the product but with Panfrost
This needs to be enabled: https://github.com/armbian/os/pull/332 As we started with a model without HDMI port, this was simply overlooked.
4 hours ago, bmikulas said:For me it would be enough if i get some help to add that to the build script for only me for now!
Build with: ./compile.sh ENABLE_EXTENSIONS="v4l2loopback-dkms,mesa-vpu"
4 hours ago, bmikulas said:remote desktop solution
That I don't know how it works if at all. Wayland is troublesome even on 1st class x86 hardware.
Update: will rebuild images later today with mesa extension enabled.
-
I'm more concerned about what version 5 might break.
3 hours ago, Werner said:drop commercial proprietary logins like Facebook and so on. Less pain, more freedom
Still, I don't think anyone makes Facebook account in order to login to Armbian forums 😄 and GitHub is not far from those I am afraid
By the end of the day, this would be a symbolic gesture that works against practical ways. I think most of people uses Google login connector. Do we have any stats for that?
-
8 hours ago, Ryzer said:
will likely fix the problem
If this worked for you, I propose to open a PR, so there is a GitHub record of your work. Add it here https://github.com/armbian/build/tree/main/patch/kernel/archive/sunxi-6.12 Here you also need to pay attention to add to series* files. -
-
Added instructions for joining your home lab:
https://docs.armbian.com/WifiPerformance/#adding-a-new-device -
45 minutes ago, TonyGoose said:
I tried updating/upgrading again and I'm back to not booting.
FYI. HDMI out is broken on those board at the moment. Try to access the board remotely. We don't have people to maintain those old boards.
-
3 minutes ago, eselarm said:
There is usually only 1 WAN interface on routers.
True. Also on most computers we have eth0Not just eth
4 minutes ago, eselarm said:A rename from WAN to WAN1 I would refuse, but I do not use netplan.io, so not affected.
Devices naming is a cosmetic thing from the outside / user perspection, while it has consistency issue from the inside and currently breaks initial (default netplan) configuration. Our job is not to tell user how to configure his network, but that network devices gets up at first boot. Now they do. Job done.
-
I just found one weird setting on R6S. Can you provide what is in this file:
cat /etc/udev/rules.d/70-persistent-net.rules
Reference for what to do: https://github.com/armbian/build/pull/8325
-
3 hours ago, eselarm said:
I do not know what armbian-update does
From the picture - I can only guess that kernel package was somehow not upgraded properly as kernel image files are missing. Perhaps they were removed by accident or there was some disk / file system troubles involved.Try hints from here:
https://docs.armbian.com/User-Guide_Troubleshooting/ -
41 minutes ago, StanleyLIM said:
I assume driver shouldn't be the issue..
To be more precise - parameters that are provided to that driver. If driver would be the problem, both NICs would be down. You need to find / create correct settings (device tree), based on schematics. This forum (search) can provide plenty of resources and hints how to do this. Someone from community (with the device so testing can be done) has to sacrifice afternoon or more to get this in operation.
-
13 hours ago, eselarm said:
so it might be that only 1 port
With logs, we could see if this is NIC not recognized or network stack problem.16 hours ago, StanleyLIM said:BTW, the Nanopi R5C looks different from the image showed on
Community supported target are often not having anyone behind https://docs.armbian.com/User-Guide_Board-Support-Rules/ -
It's a progress!
20 minutes ago, Ryzer said:Either shutting down or rebooting a kernel panic is triggered.
This or similar problem was seen / reported on H3 too.
-
17 hours ago, Ryzer said:
When attempting to build with current kernel 6.12.30, with drm patches for sun4i_hdmi_enc.c to use drm_hdmi_connector_mode_valid and drm_atomic_helper_connector_hdmi_check fails to compile. when just applying drm_atomic_helper_connector_hdmi_check patch build compilation is successful. Just need to verify this build works.
It is possible that broken patch removal is already a solution. -
On 6/7/2025 at 7:03 AM, Kevin Hoang said:
Does anyone know how to contact Realtek to request a more recent version or updated source code?
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
Board Bring-up Youyeetoo YY3568 RockChip RK3568
in Rockchip
Posted
Sadly no. https://github.com/armbian/build/tree/main/config/boards
There are (too) many boards in the system, added by random people (this is build system and we accept anything that builds, but we don't maintain those boards as we can't afford associated costs / there are not enough resources), but only supported / .conf are recognized until there is someone willing to maintaining them and fits condition of "supported" board. When we find out that conditions are not met anymore, they are "un-recognized".
Support is defined under those rules: https://docs.armbian.com/User-Guide_Board-Support-Rules