All Activity

@maxsub: the sad truth is: nearly any non-primitive hardware component needs some sort of firmware these days, you should live with that... Anyhow, as I told earlier, just replace the FW for the bcmdhd. Here's how (make sure do disabled any /etc/netplan/wifi-this-and-that.yaml, my device has inet via eth) apt-get install hostapd cat > /etc/hostapd.conf << EOF interface=wlan0 driver=nl80211 ssid=test channel=1 EOF wget -O /lib/firmware/fw_bcm43456c5_ag.bin https://github.com/orangepi-xunlong/firmware/raw/refs/heads/master/fw_bcm43456c5_ag.bin hostapd -d /etc/hostapd.conf This works, tested on the Forky-minimal linked above. HTH // Sven-Ola

you cannot login as root via ssh using password, it is disabled by default for years already you need a normal user first or prepare the image/sd-card to use ssh keys/ids

Thanks @sven-ola! You have been of amazing support here. My worry about using the closed source binary firmware is that it opens up a security hole (no patches for vulnerabilities, etc). Same for OpenWrt - the xunlong code is a fork from OpenWrt and not being updated as far as I can tell. That's why I went the Armbian route, with your code in mainstream, it will get continuously updated. The WiFi is definitely underpowered, and CPU overpowered. I am using an R2S with a USB Wireless adapter (realtek): Panda wireless PAU0B. However, the 6.6 kernel seems to not allow AP mode.

Hello @maxsub! The RV2 is a bit overpowered CPU-wise for an access point while underpowered Wifi-wise. I am pretty sure, that AP mode works with 6.6 if you overwrite fw_bcm43456c5_ag.bin from https://github.com/orangepi-xunlong/firmware As a note: to build a Wifi-Router/AP, you can use OpenWrt which is available for the RV2 and may be better up to the task... HTH // Sven-Ola

@DaBo no, sorry, no progress on my side. But I also have to admit that I did not had the time to mess around with it some more.

ref. to Igor: I think the system runs fine because i can ping and because there is actually a ssh server active. Due to that I have a Odroid HC2 and not the XU4, I have no console and have to rely on ssh. I used putty and the ssh client in the "advanced IP scanner" - www.advanced-ip-scanner.com: both seem to connect but 1234 just does not work. In that Debian raspberry I used the normal ssh client and in WIN10/11 also the ssh client from the command line. All of these three ssh clients were not able to connect to the Odroid due to a different level of keystrength and procedure. I try the WIN11 ssh client to accept the situation and will come back edit: I needed to use these command options to connect to the ssh server from the WIN11 ssh client: ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -oHostKeyAlgorithms=+ssh-dss -oCiphers=+aes128-cbc -oMACs=+hmac-sha1 That is a pile of ancient security settings! Anyway - even now the 1234 did not work. in verbose mode I got no alarms from the ssh connection

Might be because at first login, you enter 1234, it then asks for you to change that, create a user and whatnot. Not so sure putty will have any idea of what to do with those prompts. When you wrote: "once more: tried ssh through a raspi in the network. the raspi cannot connect to the armbian:" What do you mean by that? You logged in to a rpi OS with putty, and you then tried to connect to this device via the rpi? Was this before or AFTER you already tried logging in to it using putty? In your log: ### [firstrun] Recreated SSH keys (entropy: 256 256) I don't know what this means, but sounds like keys are enrolled and maybe assumed to be used in future. You will have to look into putty (and ask the devs of putty) to learn what is happening, unless you are willing to use a "normal" ssh client that will tell you what is going on by providing STDOUT & STDERR to your monitor. With a NORMAL ssh client, type "ssh root@xxx.xxx.xxx.xxx" (the ip to the device) and it will ask for passw, it will then require you to CHANGE passwd etc. Seems very likely putty has no idea how to deal with that and are doing some strange things at first login, witch then probably leads to it borking your system.

Is it possible to build against a current kernel (6.18 for example)? I am trying to build an access point on Armbian but 6.6 does not support AP mode on most adapters.

ok thanks.

Moved to off-topic as this isn't Armbian related

Hello everyone, I'm looking on how to get patched boot.img from this firmware: https://disk.yandex.ru/d/10ARWp8CEpWr_Q It is Z1 se android box with h313 chip and 2/16 gb ram What i tried is: magisk latest apk (unsupported) If anyone could help me,my telegram account is: @jasmin8111

Double checked with fresh image Armbian imager -> Odroid -> XU4 -> Armbian Trixie minimal. Works as expected.

A bit more info. I updated the mesa drivers with backport drivers to 25.0.7. Now videos outside of the ranges I listed earlier produce an error when trying to play with mpv. Mesa: error: panfrost: rejecting image due to unsupported offset or stride alignment Of course googling that error comes up with nada. All videos inside the ranges continue to play fine. If I scale the video down (from 706x480 to 704x480) when encoding to bring it within the working ranges. ffmpeg -hwaccel drm -hwaccel_device /dev/dri/renderD128 -i "input.mkv" -pix_fmt yuv420p -vf scale=704x480 "output.mkv" The video will play in mpv but still has the green/purple issue. This command produces a playable video with no green/purple issue ffmpeg -i "input.mkv" -vf scale=704x480 "output.mkv" Whatever the issue seems to be effecting both ffmpeg and mpv with certain video widths. Fmmpeg is outputting video with screwed up colours and mpv causes a driver error. mpv uses ffmpeg under the hood so it makes sense it's effecting both of them. I don't suppose anyone using this repository with a mali-g31 gpu could try and play a 706x480 file to see if it works ok and confirm I'm not crazy? You need to make sure it says "Using hardware decoding (drm)" in the terminal when mpv is launched. I guess there is a chance it's just a driver issue and not related to this repository at all.

One option is to start a crowdfunding campaign. You can review how previous campaigns were structured here: https://forum.armbian.com/crowdfunding/ As a rough estimate, bringing a new board or image to a sustainable level typically requires around $5,000 just to cover the initial development effort - when dealing with something simple. Running a campaign also gives a clear picture of how challenging it is to secure funding for this type of work. However, initial development is only part of the cost. To avoid creating another long-term maintenance burden (a “support black hole”), an additional $5,000–$10,000 is usually needed to cover ongoing maintenance, updates, CI resources, testing, and long-term support. It’s also important to emphasize a general principle: you should ideally choose hardware that is already officially supported, rather than expecting support to be built around hardware after purchase. Supporting embedded devices sustainably requires planning, funding, and long-term commitment — it doesn’t happen automatically. In short - it’s possible, but it requires realistic budgeting and shared responsibility.

Feel free to reach out and become a partner: https://www.armbian.com/partners/ @Bruno Santos

Thanks but they didn't make any difference. I have confirmed it's an issue with the ffmpeg output when drm is enabled. I used the following to extract a single frame from a video using drm. ffmpeg -hwaccel drm -hwaccel_device /dev/dri/renderD128 -ss 00:00:10 -i "input.mkv" -frames:v 1 -q:v 2 "output%03d.jpg" It produces an image but it's nearly all green. If I remove the -hwaccel drm option the image produced is correct. I tried PNG format as well to rule out a format issue and got the same result. After the above result I tried ffmpeg -hwaccel drm -hwaccel_device /dev/dri/renderD128 -i "input.mkv" "output.mkv" As it's using default settings this converts the video to x264 output.mkv still plays as a black screen in mpv but when I play it with ffplay I get a video covered in green with splashes of purple here and there. Edit: I should clarify you can still make out the video contents, it's just the colours are messed up. It's mainly all green with purple flickers occasionally. So I guess I need to play around with ffmpeg.... the last time I tried to build my own it wasn't a fun time. Also unrelated to this issue but I found the cause of the invalid argument 22 error I mentioned earlier when playing x264 videos. 10 bit x264 videos are unsupported. Using -pix_fmt yuv420p when encoding changes it to an 8bit video which plays successfully in mpv with drm. I don't normally have 10bit x264 but when I was testing I converted a x265 to x264 and it must have maintained the pixel format. Edit: By adding the --vf=format=rgba to the mpv command line I can get mpv to play the file like ffplay does. Lots of green and purple but at least it displays an image instead of a black screen. I tried a bunch of different formats but they all come out exactly the same, except for --vf=format=gray. This plays a perfect black and white version of the video. For some frames the colours are correct in places but there is a lot of green blocky squares everywhere. So I don't think it's a format issue, I think ffmpeg is just screwing up the colour space for parts of the frame for certain width videos when drm is used.

How can I help fund the cost of creating the image, and what would be the minimum feasible amount?

Can't figure how to copy putty terminal output messages, the terminal sent more messages but I can't find how to copy to a text file.

What you now need to capture is the initial boot loader messages, what you are showing here look to me to be messages from a booted android linux kernel

Now seems that boots, I just need to touch the metal part of power button when click to give power and then starts to message events. [ 27.438701@2] dhd_dbg_set_event_log_tag set log tag iovar failed -23 [ 27.442840@2] dhd_dbg_set_event_log_tag set log tag iovar failed -23 [ 27.449129@1] dhd_dbg_set_event_log_tag set log tag iovar failed -23 [ 27.455380@2] dhd_dbg_set_event_log_tag set log tag iovar failed -23 [ 27.461729@2] dhd_dbg_set_event_log_tag set log tag iovar failed -23 [ 27.467993@3] dhd_dbg_set_event_log_tag set log tag iovar failed -23 [ 27.474575@3] dhd_dbg_set_event_log_tag set log tag iovar failed -23 [ 27.480723@3] dhd_dbg_set_event_log_tag set log tag iovar failed -23 [ 27.487114@3] dhd_dbg_set_event_log_tag set log tag iovar failed -23 [ 27.493447@3] dhd_dbg_set_event_log_tag set log tag iovar failed -23 [ 27.499798@1] dhd_dbg_set_event_log_tag set log tag iovar failed -23 [ 27.506161@1] dhd_dbg_set_event_log_tag set log tag iovar failed -23 [ 27.512469@1] dhd_dbg_set_event_log_tag set log tag iovar failed -23 [ 27.521394@3] dhd_dbg_attach_pkt_monitor, 1501 [ 27.526673@3] net_os_enable_packet_filter: val = 0 [ 27.530649@2] net_os_rxfilter_add_remove: add_remove = 0, num = 2 [ 27.536809@3] net_os_enable_packet_filter: val = 1 [ 27.541011@3] net_os_enable_packet_filter: val = 0 [ 27.544909@3] net_os_rxfilter_add_remove: add_remove = 0, num = 3 [ 27.551271@0] net_os_enable_packet_filter: val = 1 [ 27.555831@1] dhd_set_suspend: Remove extra suspend setting [ 27.560882@1] dhd_enable_packet_filter: enter, value = 0 [ 27.622938@2] init: [libfs_mgr]Unable to open zram conf comp device /sys/block/zram0/max_comp_streams [ 30.111457@3] [dhd-wlan0] wl_run_escan : LEGACY_SCAN sync ID: 0, bssidx: 0 [ 34.581269@1] [dhd-wlan0] wl_cfg80211_connect : Connecting with 3c:47:11:4d:2a:ff ssid "WiFi_2AFF", len (9), sec=wpa2psk/tkipaes, channel=1 [ 34.581269@1] [ 34.612484@0] dhd_dbg_start_pkt_monitor, 1621 [ 34.612522@0] __dhd_dbg_free_tx_pkts, 1412 [ 34.615294@0] __dhd_dbg_free_rx_pkts, 1431 [ 34.638471@3] [dhd-wlan0] wl_iw_event : Link UP with 3c:47:11:4d:2a:ff [ 34.639572@3] [dhd-wlan0] wl_ext_iapsta_event : [S] Link UP with 3c:47:11:4d:2a:ff [ 34.649918@2] [dhd-wlan0] wl_bss_connect_done : Report connect result - connection succeeded [ 34.685204@1] [dhd-wlan0] wl_add_keyext : key index (0) [ 34.743323@2] dhd_dev_apf_get_version: firmware doesn't support APF [ 34.743986@2] dhd_dev_apf_get_max_len: firmware doesn't support APF [ 34.816935@0] dhd_ndo_remove_ip_by_type: failed, retcode = -14 [ 34.817143@0] dhd_dev_ndo_cfg: failed to update host ip addr: -14 [ 34.856175@0] net_os_enable_packet_filter: val = 0 [ 34.858467@0] net_os_rxfilter_add_remove: add_remove = 1, num = 2 [ 34.871997@0] net_os_enable_packet_filter: val = 1 [ 34.973661@2] dhd_set_suspend: Remove extra suspend setting [ 34.976808@2] dhd_enable_packet_filter: enter, value = 0 [ 35.068208@0] dhd_arp_get_arp_hostip_table: ioctl WLC_GET_VAR error -23 [ 35.070340@1] dhd_aoe_hostip_clr failed code -23 [ 35.076591@1] aoe_update_host_ipv4_table failed [ 50.164518@1] [dhd-wlan0] wl_run_escan : LEGACY_SCAN sync ID: 1, bssidx: 0 [ 50.945561@3] audit: audit_lost=13 audit_rate_limit=5 audit_backlog_limit=64 [ 50.946974@3] audit: rate limit exceeded [ 53.223909@1] audit: audit_lost=15 audit_rate_limit=5 audit_backlog_limit=64 [ 53.225408@1] audit: rate limit exceeded [ 54.252938@1] audit: audit_lost=28 audit_rate_limit=5 audit_backlog_limit=64 [ 54.254399@1] audit: rate limit exceeded [ 82.286034@3] [dhd-wlan0] wl_run_escan : LEGACY_SCAN sync ID: 2, bssidx: 0 [ 94.451441@3] dhd_dbg_monitor_get_tx_pkts, 1913 [ 94.451532@3] dhd_dbg_monitor_get_tx_pkts(): no tx_status in tx completion messages, make sure that 'd11status' is enabled in firmware, status_pos=0 [ 94.466807@2] dhd_dbg_monitor_get_rx_pkts, 2010 [ 122.294218@3] [dhd-wlan0] wl_run_escan : LEGACY_SCAN sync ID: 3, bssidx: 0

Now appear this on terminal.

I improvise a solder points and connect cables to tx, rx, ground, where tx goes to rx and rx goes to tx, but the result is the same, putty terminal only has a blinking cursor.

Thanks for the comments. Still no joy. I tried another SD card with etcher and then switched over to armbian imager. Same result: with putty you can connect through ssh, set "root" as username and then the "1234" is not accepted anymore. That also with another ssh client (not putty) and the Win11 built in one. Both ssh clients mention the low security of the sha1 systemin armbian and accept the override. P.S. - Same with one of the last bookworm images P.P.S - same using putty on a WIN10 system "login as: root further authentification required root@IP-address password: 1234 access denied" once more: tried ssh through a raspi in the network. the raspi cannot connect to the armbian: the raspi does not like to use diffie-hellman-group1-sha1 the raspi does not like to use ssh-dss does that tell anything?

Thank you: I've downloaded both images. Both images boot, work, and seems to grab the correct updates.

I don't know what pins you are connecting to on the board as your video doesn't show that. But if I had to guess the three pads labeled gnd,rx,tx just above what you are connecting to is what you want to be connecting to.