All Activity

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.

Can you repeat your amrbian OS version, Linux, and hardware? I can't give a confident advice for you, but have you tried: * extraargs=cma=256M in armbianEnv.txt * turn off compositor, if using xfce (others have suggested it, and I found it unnecessary) In mpv, turn on verbosity by adding -v to the command. Then while it is running, close it and copy all the mpv text in a text editor. Search for the words h264, ffmpeg, v4l2, hardware, software

Here you have a video of connection. I already rewrite the sd-card image Armbian_community_26.2.0-trunk.357_Aml-s9xx-box_noble_current_6.18.7_xfce_desktop.img , try putty ssh but I have only a black screen when connect to ttyusb0 Test value speed 9600, 115200, 230400. S905X3

@jock The schematic is maybe was a wrong example (I just search for rk3399 schematic, and take the first) in this case Leez P710, but I also look at the RK3399_Design_Guide and find a interesting point, UART2 based on the sd card pins!!! I already read a bit regarding the ddrbin_tool.py (which is part of the rkbin), which one could be used to manipulate the rockchip boot loader, but until now I not really understood how this work, then I find this in the Rockpi4 schematic I became enlightened. In the ddrbin_tool_user_guide is the following: * UART info uart id: uart number. 0 for uart0, 1 for uart1, 2 for uart2..., 0xf will disable uart. uart iomux: uart iomux info, 0 for uartn_m0, 1 for uartn_m1, 2 for uartn_m2...(like uart2_m0, uart2_m1,uart2_m2), or 1 for uartn_a, 2 for uartn_b, 3 for uartn_c.(like uar2a, uart2b, uart2c). uart baudrate: uart baudrate should be 115200 or 1500000. I still don't understanding what the iomux (io multiplexing) is, but in theory if I change the uart iomux parameter to 1 then this should means that UART2A is used, which is SD card D0,D1 pins. (Similar concept I see in Amlogic SoCs. ) So I read out the ddrbin parameters from rk3399_ddr_800MHz_v1.27.bin ./tools/ddrbin_tool.py RK3399 -g ddrbin_param.txt ./bin/rk33/rk3399_ddr_800MHz_v1.27.bin then I change the UART parameters in the file ddrbin_param.txt like this: uart id=2 uart iomux=1 uart baudrate=115200 then I write the parameters back ./tools/ddrbin_tool.py RK3399 ddrbin_param.txt ./bin/rk33/rk3399_ddr_800MHz_v1.27.bin Then I build a new loader based on the rk3399_ddr_800MHz_v1.27.bin ./tools/boot_merger ./RKBOOT/RK3399MINIALL_1.27.ini Content of the ./RKBOOT/RK3399MINIALL_1.27.ini [CHIP_NAME] NAME=RK330C [VERSION] MAJOR=1 MINOR=30 [CODE471_OPTION] NUM=1 Path1=bin/rk33/rk3399_ddr_800MHz_v1.27.bin Sleep=1 [CODE472_OPTION] NUM=1 Path1=bin/rk33/rk3399_usbplug_v1.26.bin [LOADER_OPTION] NUM=2 LOADER1=FlashData LOADER2=FlashBoot FlashData=bin/rk33/rk3399_ddr_800MHz_v1.27.bin FlashBoot=bin/rk33/rk3399_miniloader_v1.26.bin [OUTPUT] PATH=rk3399_loader_v1.27.126.bin The result was uploaded in the emmc rkdeveloptool db rk3399_loader_v1.27.126.bin rkdeveloptool ul rk3399_loader_v1.27.126.bin the I connected my microsd sniffer and after some praying I reset the device ... Then the magic is happened 🤩 DDR Version 1.27 20211018 In channel 0 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel 1 training pass! change freq to 416MHz 0,1 Channel 0: LPDDR4,416MHz Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB Channel 1: LPDDR4,416MHz Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB 256B stride channel 0 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel 1 training pass! channel 0, cs 0, advanced training done channel 1, cs 0, advanced training done change freq to 856MHz 1,0 ch 0 ddrconfig = 0x101, ddrsize = 0x40 ch 1 ddrconfig = 0x101, ddrsize = 0x40 pmugrf_os_reg[2] = 0x32C1F2C1, stride = 0xD ddr_set_rate to 328MHZ ddr_set_rate to 666MHZ ddr_set_rate to 416MHZ, ctl_index 0 ddr_set_rate to 856MHZ, ctl_index 1 support 416 856 328 666 MHz, current 856MHz OUT Boot1 Release Time: May 29 2020 17:36:36, version: 1.26 CPUId = 0x0 ChipType = 0x10, 645 SdmmcInit=2 0 BootCa Yes, is working, I have debug output 😁 this is maybe not the best solution but I could start working running Armbian on this device. The key point was: So thanks again the advise.

https://github.com/chewitt/linux/commit/d39e2d1a2027e05de26af5bac575e99dedf7ce74

I don't have a working board to add yet. I followed the documentation on creating a ~/build/config/boards/sv06ace.csc file but got lost about how to bring in the rk-kernel.dts values into the build. I started a new https://forum.armbian.com/topic/58141-rk3308b-build-using-sysfirmwareftb-on-sovol-sv06-ace/ since the question could apply to other 3D printer boards.

I’m using an Orange Pi 3B running Armbian Trixie Minimal as a headless SBC. It has been working fine for a couple of months, but after a recent reboot, it failed to connect to the network. After connecting an HDMI cable to troubleshoot, I realized the system is no longer auto logging in; it gets stuck at the login screen. Once I log in manually, I found that the wired network (Ethernet) isn't working at all, though wireless is functioning fine. I even tried flashing the latest image from the website, but the issues persist. To summarize, I have two main problems: - Wired connection (Ethernet) is not working. - The system no longer auto-logs in after booting. Has anyone else encountered this with the recent Trixie builds?

Per the title, I was able to extract an ftb file and convert it to dtb and dts file. I would like to use the community build framework and build Armbian for SV06 Ace. The initial plan was to base the new board/*csc files on other rk3308b boards; sakurapi and rock-s0 and then pull configuration values from the OEM dts file. I'm confused about the dts structure in Community builds and the proper locations for defconfig, dts and dtsi files. I've worked with the files in OpenWRT where they are rigidly structured - something that would be a monumental task for Armbian community builds. The OEM dts file does not use any includes/dtsi files. If successful, I would like to publish on github similiar to @Torte https://github.com/torte71/armbian-mksklipad50 Can someone point me to the relevant documentation for Armbian dts files?

If you installed the Armbian 25.11.1 Edge Image the earlier post fixed the HDMI audio issue. However, if you upgrade with the command sudo apt update && sudo apt upgrade you will break both HDMI audio and WiFi. Here is the new fix: 1. The Wi-Fi Fix (Rebuild DKMS) Since the kernel updated, we just need to force the system to recompile the missing Wi-Fi driver for the new kernel version. Run this command in your terminal: Bash sudo dpkg-reconfigure aic8800-usb-dkms Wait a minute or two for it to finish compiling. Your Wi-Fi will be restored upon your next reboot. 2. The HDMI Audio Fix (Restore Qualcomm Configs) The HDMI audio broke because the system is now missing the Use Case Manager (UCM) profiles for the QCS6490 chip. We need to pull the newest configurations directly from the ALSA project repository and put them in the right folders. Run these commands one by one: Bash # Install the base UCM configurations sudo apt install -y alsa-ucm-conf # Download the latest master branch configs to your temporary folder cd /tmp curl -sL "https://github.com/alsa-project/alsa-ucm-conf/archive/refs/heads/master.tar.gz" | tar xz # Copy the specific Qualcomm configs and dependencies to your system sudo cp -r alsa-ucm-conf-master/ucm2/Qualcomm/qcs6490 /usr/share/alsa/ucm2/Qualcomm/ sudo cp -r alsa-ucm-conf-master/ucm2/conf.d/qcs6490 /usr/share/alsa/ucm2/conf.d/ sudo cp -r alsa-ucm-conf-master/ucm2/lib /usr/share/alsa/ucm2/ sudo cp -r alsa-ucm-conf-master/ucm2/codecs /usr/share/alsa/ucm2/ # Restart your audio server to apply the changes systemctl --user restart pulseaudio Once you've run those, give your board a quick sudo reboot.

poweroff doesn't work on any of my boxes either. Does reboot work correctly for you? It does on my boxes, and I usually issue a reboot and then time a power disconnect when the drives have spun down and before they restart.

Change the dp dm and gave this. sudo dmesg | grep tty [ 0.471034] console [tty0] enabled [ 633.797008] usb 1-1.4.1.3: cp210x converter now attached to ttyUSB0 [ 1159.103497] cp210x ttyUSB0: cp210x converter now disconnected from ttyUSB0 [ 2713.702725] usb 1-1.4.1.2: cp210x converter now attached to ttyUSB0 [ 3812.350749] cp210x ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32 [ 3812.351220] cp210x ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32 [ 3812.447580] cp210x ttyUSB0: failed set request 0x12 status: -19 [ 3812.447593] cp210x ttyUSB0: failed set request 0x0 status: -19 [ 3812.447923] cp210x ttyUSB0: cp210x converter now disconnected from ttyUSB0 [ 4077.235990] usb 1-1.4.1.2: cp210x converter now attached to ttyUSB0 [ 4098.361943] cp210x ttyUSB0: cp210x converter now disconnected from ttyUSB0 [ 5224.734896] usb 1-1.4.1.3: cp210x converter now attached to ttyUSB0 [ 5248.927091] cp210x ttyUSB0: cp210x converter now disconnected from ttyUSB0 [ 5250.665687] usb 1-1.4.1.3: cp210x converter now attached to ttyUSB0 [ 5600.550201] cp210x ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32 [ 5600.550539] cp210x ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32 [ 5601.154463] cp210x ttyUSB0: failed set request 0x12 status: -19 [ 5601.154476] cp210x ttyUSB0: failed set request 0x0 status: -19 [ 5601.154818] cp210x ttyUSB0: cp210x converter now disconnected from ttyUSB0 [ 5725.698091] usb 1-1.4.1.3: cp210x converter now attached to ttyUSB0 GNU/Linux When pass → sudo screen /dev/ttyUSB0 115200 Only has cursor blinking.

Only a guess, but the first thing I would look at is how this is connected to your t box as it seems to not be connecting correctly. Maybe some pictures of your connection points?

If you installed the Armbian 25.11.1 Edge Image the earlier post fixed the HDMI audio issue. However, if you upgrade with the command sudo apt update && sudo apt upgrade you will break both HDMI audio and WiFi. Here is the new fix: 1. The Wi-Fi Fix (Rebuild DKMS) Since the kernel updated, we just need to force the system to recompile the missing Wi-Fi driver for the new kernel version. Run this command in your terminal: Bash sudo dpkg-reconfigure aic8800-usb-dkms Wait a minute or two for it to finish compiling. Your Wi-Fi will be restored upon your next reboot. 2. The HDMI Audio Fix (Restore Qualcomm Configs) The HDMI audio broke because the system is now missing the Use Case Manager (UCM) profiles for the QCS6490 chip. We need to pull the newest configurations directly from the ALSA project repository and put them in the right folders. Run these commands one by one: Bash # Install the base UCM configurations sudo apt install -y alsa-ucm-conf # Download the latest master branch configs to your temporary folder cd /tmp curl -sL "https://github.com/alsa-project/alsa-ucm-conf/archive/refs/heads/master.tar.gz" | tar xz # Copy the specific Qualcomm configs and dependencies to your system sudo cp -r alsa-ucm-conf-master/ucm2/Qualcomm/qcs6490 /usr/share/alsa/ucm2/Qualcomm/ sudo cp -r alsa-ucm-conf-master/ucm2/conf.d/qcs6490 /usr/share/alsa/ucm2/conf.d/ sudo cp -r alsa-ucm-conf-master/ucm2/lib /usr/share/alsa/ucm2/ sudo cp -r alsa-ucm-conf-master/ucm2/codecs /usr/share/alsa/ucm2/ # Restart your audio server to apply the changes systemctl --user restart pulseaudio Once you've run those, give your board a quick sudo reboot.