-
Positions
-
Part time technical support
Position: Technical supportNumber of places: 12Applicants: 16 -
Single board computer maintainer
Position: Board maintainerNumber of places: 64Applicants: 77 -
Code reviewer
Position: Framework maintainerNumber of places: UnlimitedApplicants: 11 -
Test Automation Engineer
Position: Software integration test engineerNumber of places: 16Applicants: 10 -
Build framework maintainer
Position: Framework maintainerNumber of places: 16Applicants: 6
-
-
Chat | Social Media
#armbian at
irc.libera.chat or irc.oftc.net
Matrix or Discord
Mastodon | 𝕏 -
Popular Now
-
Activity Stream
-
22
SV6256P WiFi Now Working on Linux 6.x (Armbian Tested)
If you plan to add this to the Armbian framework to have it included, I suggest to bring the drive in a dkms compatible state and create an extension (https://github.com/armbian/build/tree/main/extensions) to add this driver to specific boards. I know that other out-of-tree wifi drivers are added here (https://github.com/armbian/build/blob/main/lib/functions/compilation/patch/drivers_network.sh), however this is already a huge mess and I won't allow any more additions, rather than looking forward to some point in the future when this is dissolved in to individual extensions which make things hopefully more maintainable. AI will probably a huge help in this matter. -
3
Orange Pi PC: /usr/bin/su is a x86-64 binary
If this is really the case, then this must be an upstream issue since Armbian does not touch this file AFAIK. Picked a random userspace from armhf (since you did not state which you are using) ~/build/cache/rootfs/bin# file su su: setuid ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, BuildID[sha1]=b24ceef58082e181650b17e52819559be2d3a97b, for GNU/Linux 3.2.0, stripped -
0
Does rock64 have working HW watchdog?
my rock64 sometimes hangs with unknow reason. Enabling/testing watchdog did not help. Does hardware watchdog is working at all ? some outputs: # dmesg | grep -i watchd [ 0.838922] dw_wdt ff1a0000.watchdog: No valid TOPs array specified [ 0.928770] rk_gmac-dwmac ff540000.ethernet: Enable RX Mitigation via HW Watchdog Timer [ 3.920201] systemd[1]: Using hardware watchdog 'Synopsys DesignWare Watchdog', version 0, device /dev/watchdog0 [ 3.921218] systemd[1]: Watchdog running with a hardware timeout of 28s. # wdctl Device: /dev/watchdog0 Identity: Synopsys DesignWare Watchdog [version 0] Timeout: 28 seconds Timeleft: 18 seconds Pre-timeout: 0 seconds After doing kernel panic via echo c > /proc/sysrq-trigger device not rebooting. On raspberry pi that test is working fine. -
3
Orange Pi PC: /usr/bin/su is a x86-64 binary
Bedna I know that su command is a compiled binary but Orange Pi PC has a 32 bit ARM processor and not a 64 bit Intel (x86_64) processor. I find that extremely hard and impossible to believe that you missed the point. -
3
Orange Pi PC: /usr/bin/su is a x86-64 binary
Yes, applications are compiled into binaries, su is not a script. This is on for example Arch: $ file $(which su) /usr/bin/su: setuid ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=d47af40eeb87fea42d555df0d1385bc9a4b4df2c, for GNU/Linux 4.4.0, stripped Ok? So it's compiled with rust instead of C, still a binary. I find that extremely hard impossible to believe. https://www.reddit.com/r/learnprogramming/comments/lyw9gf/can_someone_explain_what_people_mean_by_binaries
-
-
Member Statistics
