Active threads

Wifi chip?

I am running bookworm on my Odroid HC4, upgraded from buster. USB stopped working, which I believe to be U-Boot related. So I am looking for a newer version of the U-Boot package "linux-u-boot-odroidhc4-current", which is at 26.2.1. I tried to change the apt sources to trixie and apt updated, but apt doesn't offer me a newer package. I am not so keen on compiling it myself, so is there a way of finding/downloading/installing a newer package...?

I bought this board because it has 2 lanes. So I changed the number of lanes in the dtb from 1 to 2. I need confirmation of an expert but my quick speed test with 2 lanes looks promising : gt@yy3568:~$ sudo hdparm -tT --direct /dev/nvme0n1p1 /dev/nvme0n1p1: Timing O_DIRECT cached reads: 1062 MB in 2.00 seconds = 530.34 MB/sec Timing O_DIRECT disk reads: 928 MB in 3.00 seconds = 308.97 MB/sec gt@yy3568:~$ sudo dmesg | grep lane [ 4.183004] phy phy-fe8c0000.phy.6: lane number 0, val 1 [ 4.183679] phy phy-fe8c0000.phy.6: lane number 1, val 2 pcie@fe280000 { compatible = "rockchip,rk3568-pcie"; #address-cells = <0x03>; #size-cells = <0x02>; bus-range = <0x20 0x2f>; clocks = <0x0f 0x8f 0x0f 0x90 0x0f 0x91 0x0f 0x92 0x0f 0x93>; clock-names = "aclk_mst\0aclk_slv\0aclk_dbi\0pclk\0aux"; device_type = "pci"; interrupts = <0x00 0xa5 0x04 0x00 0xa4 0x04 0x00 0xa3 0x04 0x00 0xa2 0x04 0x00 0xa1 0x04>; interrupt-names = "sys\0pmc\0msg\0legacy\0err"; #interrupt-cells = <0x01>; interrupt-map-mask = <0x00 0x00 0x00 0x07>; interrupt-map = <0x00 0x00 0x00 0x01 0xcb 0x00 0x00 0x00 0x00 0x02 0xcb 0x01 0x00 0x00 0x00 0x03 0xcb 0x02 0x00 0x00 0x00 0x04 0xcb 0x03>; linux,pci-domain = <0x02>; num-ib-windows = <0x06>; num-ob-windows = <0x02>; max-link-speed = <0x03>; msi-map = <0x2000 0x66 0x2000 0x1000>; num-lanes = <0x02>; phys = <0xca>; phy-names = "pcie-phy"; power-domains = <0x11 0x0f>; reg = <0x03 0xc0800000 0x00 0x400000 0x00 0xfe280000 0x00 0x10000 0x00 0xf0000000 0x00 0x100000>; ranges = <0x1000000 0x00 0xf0100000 0x00 0xf0100000 0x00 0x100000 0x2000000 0x00 0xf0200000 0x00 0xf0200000 0x00 0x1e00000 0x3000000 0x03 0x80000000 0x03 0x80000000 0x00 0x40000000>; reg-names = "dbi\0apb\0config"; resets = <0x0f 0xc1>; reset-names = "pipe"; status = "okay"; pinctrl-names = "default"; pinctrl-0 = <0xcc>; reset-gpios = <0x58 0x1e 0x00>; vpcie3v3-supply = <0xcd>; phandle = <0x271>; legacy-interrupt-controller { interrupt-controller; #address-cells = <0x00>; #interrupt-cells = <0x01>; interrupt-parent = <0x01>; interrupts = <0x00 0xa2 0x01>; phandle = <0xcb>; }; };

Here your debugging activity will need to start. There is an awful lot of things unknown, to others on this forum but more important, also to yourself. It could already be that your server (Armbian) has nothing to do with it, but that it is the info in your router (even caching stuff) that has refreshed, simply because you probably restarted, so something was not 'reset proof'. I have seen many of such things myself in my house/home networking and in conjunction with various ISP's (also mobile4G). Which made me use my own (open-source) router instance for example, so I can at least check all what is needed in such case as you have. But it might be simple, you can use wget (do 'man wget' first to see all options) to mimic browser behavior and that should already say something. If docker etc is involved, make sure you understand all (virtual) networking, it can get very complex. I haven't seen potentially disturbing things from Armbian 26.2.1, but I removed/blocked also several things, like no netplan.io, that at least works on Debian Trixie based installs. There have been lots of security related updates in Debian recently, so make sure you log and see changes to packages (edit listchanges.conf)

I own the one of the 1st post and I managed to run Kodi desktop within Armbian. Just did few tests as I don't know how to set up remote control and many other things. HDMI works fine but no hardware acceleration for H265 videos (or at least doesn't work smooth enough as in the Android FW). LAN also works but is HW limited to 100mbps as stated by Joao

I know it was already written here in some of the messages that these devices are not secure. But now I got a message from Telekom that they detected a Chineese spyware connection: The timeframe is exactly when I have switched the device on with an Android on board.

You'd better upgrade the kernel to 6.18 and keep Debian Bookworm, because Trixie has an mpv version which is not exactly friendly with hardware video decoding because some things are in the middle of a transition

OK, it looks like the BSP PCIe driver might have some issues related to power management. I’m not entirely sure of the root cause yet, but when I connected an NVMe drive, it got extremely hot and failed to initialize properly. The NVMe dmesg output suggested adding the following kernel parameters: nvme_core.default_ps_max_latency_us=0 pcie_aspm=off This resolved the NVMe issues on my side. I’ll try to dig deeper into the root cause, but @humanus please give it a try as well.

Thank you @greg396 for this sum-up on how to upgrade to 6.12 Since last months, have you experience any issue with this version ? I'm on 6.6.8 based on kernel 23.08.0. Stable so far...

Hi @OverNautt! Sorry not replying in time. Great that you found a solution to your issue and provided feedback!

Me neither. This is my primary intention, just currently overwhelmed with things. I did some changes on top on official: https://github.com/armbian/supervised-installer

For mate IIRC they use gnome's gnome-language-selector (start it in a terminal if you are missing the icon in settings), but it was a while since I used that desktop-env so I could be wrong. My old notes says the setting should be in: System > Control Center > Language Support For your information (as a fellow Swedish person): there is a locale called en_DK.UTF-8 that you might want to use instead. That way you get the correct settings for Scandinavian (like date/clock format for example) but the language is English. Or you can probably do it in terminal altogether: sudo dpkg-reconfigure locales # select en_DK.UTF-8 here, or whatever locale you want to use, I will use the dk version in this example localectl set-locale LANG=en_DK.UTF-8 sed -i "s/sv_SE/en_DK/" ~/.dmrc

Hello @vlw, Pull latest from build framework, compile and retry, we migrate R76S to use mainline uboot due a issue with uboot vendor. Let's update us.

This is a work-in-progress resource for bare-metal bringup for Rockchip devices. Source code: https://github.com/petabyt/rk https://danielc.dev/rk/

The issue has been resolved. It turns out that the official release has already configured the necessary documents or files before distribution. When I used im‑config, it gave me no response at all. Following the XDG Autostart manual, I copied /usr/share/applications/org.fcitx.Fcitx5.desktop to ~/.config/autostart; after that, fcitx5 starts automatically and works normally when I reboot or log out and back in. Thanks

@sven-ola Sorry, this was indeed a mystery problem with my SSD. I replaced it, and now everything works like a charm (I just need the CLI server; Wi-Fi or GPU isn’t necessary). By the way, when is the stable release planned?

@Sergioclr remove those two Failing patches you don’t need them anyways.

@SecLyzer U-Boot can boot from a FAT32 or Linux file system. You can change this in your board configuration file.

Due to the shortage of memory chips these days, Radxa is using different emmc models in their boards. For example, I recently ordered a big batch of Rock S0 boards, but they had to be delivered with Sandisk iNAND 32GB emmc drives instead of the typical 8GB option. The problem is that Armbian did not reliably boot on these new boards. It randomly gets stuck during initialization with the onboard LED endlessly blinking. Some boards works, some did not, some only works sometimes. Long story short, in case other people also have this problem: I found the solution. I believe it is caused by Armbian's Rock S0 device tree enabling the HS200 high speed mode for the emmc device. (source) I guess not all emmc chips reliably support this. To fix it, I had to remove the line in the device tree linked in the source above. Actually this should probably be done with a proper device tree modification, but in my case, just to test, I modified the boot scripts. In /boot/boot.cmd, add these lines near the bottom, but ABOVE the "booti ..." line: fdt rm /mmc@ff490000 mmc-hs200-1_8v fdt set /mmc@ff490000 max-frequency <0x02faf080> Then recompile in terminal with: mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr If you update the kernel/armbian distro these script will probably get overwritten, hence why it should preferably done with a custom device tree instead. But in my case I have frozen updates, and either way this will serve as a starting point for others having the same issue. Actually, I cannot see this troublesome patch on the 6.18 distro source, so maybe this is old news and no longer a problem on modern images anyway. But my image is still on 6.12, so I figured I'd share anyway.

@Taz Radxa's u-boot won’t load the kernel image. So I used vmlinux.

none which doesn't break other boards.

Armbian has limited resources. And given that there are hundreds of different boards out there, generally that means that new boards only get supported either because the company behind them is willing to contribute to Armbian (and Orange Pi has made if very clear that they don't do anything to support their boards software after the fact as it would reduce sales for new boards they are constantly introducing), or some volunteer from the community steps up to volunteer their time to add support. Most boards under Armbian are community supported. So it relies on volunteers like you to do the work.

Embedded Recipes returns to Nice for its second standalone edition, along with Linux Media Summit, PipeWire, libcamera, GStreamer Spring Hackfest, and new Display Next Hackfest & BlueZ F2F. Visit our table for Tyr, ML video analytics & Flipper One prototype! View the full article

Are you using the rolling release? Otherwise you should not use "full-upgrade" but rather just "upgrade". Not saying that is the reason for missing deps, but it definitely could be.

@Giunti & @samlevy0515 It would be helpful to the community if you responded to the developer trying to fix this issue rather than state a workaround. Thank you.