All Activity

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.

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?