All Activity

For my complete log and Banana pi M2 Zero data, see: https://paste.armbian.com/yusewapuzi Kernel: 6.12.23-current-sunxi RTC module ds3231, connected to pin 3 and 5 (i2c0) 3.3V from 1 and 9 overlays=sun8i-h3-i2c0 dtoverlay=i2c-rtc,ds1307

First problem was fixed in predicted way. There is no more firmware warnings on upgrade / kernel install. New package is getting to the stable repository in a couple of hours, while it is already present in beta. Agree. While testing kernel, I installed Ubuntu Noble based image and ERROR: Unsupported initramfs version does not manifest there! I suspect this problem is caused by some script that is coming from RaspberryPi OS - on Debian based Armbian, we use userspace and Rpi related firmware packages from RPi OS (which is Bookworm based, so we have great / full packages compatibility). I will try to get to the bottom of this when possible. Basic problem is that in open source and especially in packages assemblies, there are always (tens of) thousands of potentially irritating issues. You noticed this one, we already have a list of many others that needs attention and there is endless list that well always be somewhere ...

Ver 20250423-edge kernel 6.15

Moved

Thanks maka for replying. Issue is resolved and Ethernet is working now. I did not read the first email from Maxio tech properly and I was sent files for MAE0621A-Q3C rather than the MAE0621A-Q2C which I have. Maxio tech kindly sent me files for MAE0621A-Q2C yesterday and I managed to compile it into the current kernel 6.12.24

I don't use my Clearfog Base as a filer or anything, but I much prefer to have some snappy storage on systems that I access frequently - and since this system is my firewall, I end up working on it often enough. When I'm not at home it's often where I push files - so running off an SD card is right out. For years now I've been using an m.2 SATA drive which has been fine, but it's got a minipcie slot just sitting there that I've never used... it's not particularly fast (PCIe gen 1 x1) but with one of these and an m.2 NVMe drive (the older the better...), you can get much better perf than SATA. You can't boot off it (at least I don't know how to make that happen) but it's easy enough to do that via an SD card or SATA and use one of these for the root filesystem or /home, etc.

Thanks for those that answered. I was hoping someone would bring up a board targeted at networking (router / firewall) that was well supported by modern software, but nothing is really jumping out. Here are some more random thoughts on the matter... since my previous experience was with SolidRun Clearfog Base (and with Armbian it was quite positive!) I am interested in their newer Clearfog CN9130 Base but it's a bit expensive and I'm hesitant to use anything not supported by Armbian due to poor experience with vendor images. But it looks cool! MACCHIATObin double shot isn't new, and doesn't have the best support either from what I can gather - but it also is attractive. And lastly, Honeycomb LX2 is pretty boss as well - but it also is a bit dated now, isn't cheap, and seems to have not caught on well so doesn't have great software support. All of those seem like nice hardware but I don't expect the software experience to warrant buying one. I had an impulse to buy when I saw the new dual 2.5gbe HAT from Radxa as I have a Rock 4a that claims to support it. I've had that little box in use as a container host running simple services like DNS, DHCP, Unifi controller, etc for a long time now and it's been nothing but reliable - though I do need to evacuate it so I can try bringing it up running Bookworm (it's on Bullseye still - but it's stable!). But I just noticed that maybe its own software support is rotting... it's community supported and the last Armbian image for it is quite old, so maybe I shouldn't put any more money or effort into it and let it do its thing. Dunno. But yeah, a tiny system that is quite low power which supports 2 x 2.5gbe and 1gbe along with NVMe sounds pretty nice especially since I already own the SBC... I suppose what I should really do is continue to ride my existing router until it dies. Considering I locked the kernel and firmware I expect it will work for a long while at this point, though I don't figure it to be able to upgrade to the next major Debian release once it's available. Maybe by then the support for Rock 5 ITX will be solid and I can start using it for this. If anyone else runs Armbian systems as their firewall, please chime in with thoughts and experiences!

Off-topic, but related to "trixie / sid" on RPi4 On a freshly written 64-bit raspberrypi os bookworm (Lite) image, replaced word "bookworm" by "trixie" in following two files: "/etc/apt/sources.list" and "/etc/apt/sources.list.d/raspi.list" . After above modifications, ran following commands: sudo apt update sudo apt full-upgrade sudo apt autoremove sudo apt autoclean sudo reboot The upgrade command took about half an hour to complete, and upgraded 470 packages. No issues during & after upgrade. Everything is OK.

Hi, anybory know The STV-2000 Aquário tvbox? It's brazilian make, It a gxl-s905w-p281board, this old product, but can install armbian in interna memory? Thanks

TV Box Name: Sunvell T95Z plus Octagon shaped box (Beware – apparently a lot of variants) CPU Amlogics S912 Armbian build file name: Armbian_community_25.5.0-trunk.370_Aml-s9xx-box_noble_current_6.12.23 DTB file used: meson-gxm-vega-s96.dtb (but several seem to work… none with wifi out of the box) Kernel Version: 6.12.24 Distribution Installed (focal, buster, etc): Noble Working Ethernet (Yes/No): Yes Max Ethernet Speed that works (100/1000): Not sure how to determine... Does wifi work (Yes/No): YES *** See Below Does bluetooth work (Yes/No): Not tested Does HDMI audio work (Yes/No): Yes Additional Comments (provide any additional information you feel is important): Tested many files. Ubuntu (noble) seemed much more usable than Debian (bookworm) Also tested Armbian_community_25.5.0-trunk.334_Aml-s9xx-box_bookworm_current_6.12.21 _gnome_desktop.img.xz Armbian_community_25.5.0-trunk.334_Aml-s9xx-box_noble_current_6.12.21 _gnome_desktop.img.xz Armbian_community_25.5.0-trunk.334_Aml-s9xx-box_oracular_edge_6.14.0 _gnome_desktop.img.xz Armbian_community_25.5.0-trunk.334_Aml-s9xx-box_oracular_edge_6.14.0.img.xz Since I am trying to learn server/media center/adguard or pihole stuff – chose the server headless install eventually. Learning has started. **** Thank you thank you to @ZuiMelanieForno and their post here: But basically looks like the easy way is to create a soft link of the ap6330 driver file as the brcm4330 file that must be loaded by default. sudo mv /lib/firmware/brcm/brcmfmac4330-sdio.txt /lib/firmware/brcm/brcmfmac4330-sdio.txt.old sudo ln -s /lib/firmware/brcm/brcmfmac-ap6330-sdio.txt /lib/firmware/brcm/brcmfmac4330-sdio.txt Not sure of this solution will survive update. (UPDATE: Confirmed - it does not survive update - but doing the commands again and a reboot seemed to work.) I have installed pihole and had it running. I had jellyfin running. Rebuilt from 0 again and am trying to do inside of docker containers. Dockers seems running but still some learning to go. If I write my sd to my eMMC – can reset to 0 again by booting from an sd card … and when ready burn that to eMMC? Or should I keep the writes to the eMMC as few as possible? I own two of these boxes – Identical on the outside but the newer one (bought probably 1 year later) does NOT have an eMMC. It has the dreaded NAND chip(BiWIN 16GB)… Also a different wifi module I think…. (LTM8830) Oh and – can I just say I love pulling this thing out of retirement and having a tiny low cost media server in the house. Thanks @balbes150 and @SteeMan and Everyone for their hard work! This is amazing... until I blow it up again...

Thanks @Igor for your prompt attention and help. Yes, you are right. The error messages I posted in my last post do NOT break anything, but these are very irritating.

Warnings are safe to ignore, happens on other platforms too, but it looks like also error. CONFIG_USB_RTL8152=y -> m should probably do. I will make a config change: https://github.com/armbian/build/pull/8116 I have noticed the initramfs error too, but it doesn't looks it breaks anything. Need to be investigated.

Hi @Ed van den Enden, I think your BananaPi runs an Allwinner SoC, which is similar to the OrangePi zero. Can you list the RTCs on your board? ls /dev/rtc* On my OrangePi's here, the H2+ SoC also has an RTC that is wildly unprecise, but it's still used as /dev/rtc0 and therefore used by the kernel to synchronize to when the kernel boots. I do not know much about your SBC, but perhaps sharing my config for the OrangePi zero helps you as well: I have two RTCs, one from the H2+ SoC and one connected via i2c: djurny@sinaspi:~$ ls /dev/rtc* /dev/rtc /dev/rtc0 /dev/rtc1 As the SoC RTC will be seen first by the kernel, i had to update the DTB to make it appear later than the i2c one: The dtb is specifically for the OrangePi zero (1), so most likely not suitable for your SBC. But the idea might help you to fixup your dtb. For my NanoPi neo3 i was not able to apply a dtb fix and had to make some oddball script (attached). It would check for any RTC that is currently being synced by NTP and if i cannot find one (during boot and before NTP can sync) it will copy the date/time from the first "external" RTC it can find. If it finds NTP is sync'ed, it will write the wallclock to the external "freerunning" RTCs to make sure the "external" RTC will have a reasonably accurate time when the system power cycles/reboots. Let me know if this works for you. About the dtb fixups, i cannot really remember unfortunately, but some other posts on here helped a lot. You can try here for more hints and things you can try: Hope some of this might help your case, Groetjes, rtc-sync

kernel version? uname -r

Hi, I am currently using MagicBox M16S to flash Armbian. However, I did try to use VIM2 Armbian img to flash into my magicbox but it wont worked. Currently it seem like my device is bricked ( try to flash original ROM from some china website but it stuck at 1% and fail). Do anyone have idea on this device? Thanks~

Upgrading: pi@pi-1-Armbian-trixie:~$ apt list --upgradable armbian-bsp-cli-rpi4b-current/trixie 25.5.0-trunk.438 arm64 [upgradable from: 2> linux-dtb-current-bcm2711/trixie 25.5.0-trunk.438 arm64 [upgradable from: 25.5.> linux-image-current-bcm2711/trixie 25.5.0-trunk.438 arm64 [upgradable from: 25.> When issued command "sudo apt upgrade", upgrade did take place, but when it reached finishing stage, got following errors: Armbian 'linux-image-current-bcm2711' for '6.12.22-current-bcm2711': 'postinst' starting. update-initramfs: Generating /boot/initrd.img-6.12.22-current-bcm2711 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8156b-2.fw for built-in driver r8152 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8156a-2.fw for built-in driver r8152 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153c-1.fw for built-in driver r8152 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153b-2.fw for built-in driver r8152 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153a-4.fw for built-in driver r8152 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153a-3.fw for built-in driver r8152 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153a-2.fw for built-in driver r8152 ERROR: Unsupported initramfs version (6.12.22-current-bcm2711) ERROR: Unsupported kernel version (6.12.22-current-bcm2711) update-initramfs: Generating /boot/initrd.img-6.12.22-current-bcm2711 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8156b-2.fw for built-in driver r8152 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8156a-2.fw for built-in driver r8152 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153c-1.fw for built-in driver r8152 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153b-2.fw for built-in driver r8152 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153a-4.fw for built-in driver r8152 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153a-3.fw for built-in driver r8152 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153a-2.fw for built-in driver r8152 ERROR: Unsupported initramfs version (6.12.22-current-bcm2711)

I will leave it for what it is for now. I will move back to RPi zero 2W, solder an antenna, and I'm good to go. Would have loved to go to the BPI m2z and later to the BPI m4z, but for now not an option. By the way, with the latest Armbian upgrade an hour ago, my USB camera is also not working anymore. Thank you very much for the support. Kind regards, Ed👏

Nop, that didn't work had also both i2c0 and i2c1 activated root@clearview:~# i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: 30 -- 32 33 34 35 36 -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- root@clearview:~# i2cdetect -y 1 Error: Could not open file `/dev/i2c-1' or `/dev/i2c/1': No such file or directory root@clearview:~# ls /dev/i2c-* /dev/i2c-0

This should mean that the rtc is there. Take a look at https://wiki.banana-pi.org/BPI_RTC_real_time_Module You could try: echo ds3231 0x68 > /sys/class/i2c-adapter/i2c-0/new_device Then a dmesg to see if there's something new about rtc.

Hello friends, Has anyone here successfully activated the I2S pins for connecting a DAC? According to the official documentation, the PCM functionality should be available on physical pins 12 (GPIO4_A6), 35 (GPIO3_C2), 38 (GPIO3_C0), and 40 (GPIO3_B7) of the GPIO header. I've tried many options - in the DTS overlay I've enabled various I2S variants starting from "i2s0_8ch" up to "i2s9_8ch", including different "pinctrl" m[0-1] variants like "i2s1m0" or "i2s1m1", and alternatively "i2s2m0" or "i2s2m1", but I've never managed to get ALT3 mode on the mentioned pins (I assume I2S function = ALT3 mode). In certain combinations, I can at least achieve some half-working state where the system detects the sound card and it can be controlled (e.g., in alsamixer), but I've never managed to get any actual sound output. Has anyone managed to get I2S-DAC working on Orange Pi 5 MAX? I'm attaching the overlay I've been working with. Remember that I've tried all available i2s target combinations: /dts-v1/; /plugin/; / { compatible = "xunlong,orangepi-5-max", "rockchip,rk3588"; // Enable I2S fragment@0 { target = <&i2s1_8ch>; __overlay__ { status = "okay"; #address-cells = <1>; #size-cells = <0>; pinctrl-names = "default"; pinctrl-0 = <&i2s1m0_mclk &i2s1m0_lrck &i2s1m0_sclk &i2s1m0_sdo0 &i2s1m0_sdi0>; }; }; // Enable I2C fragment@1 { target = <&i2c2>; __overlay__ { status = "okay"; #address-cells = <1>; #size-cells = <0>; wm8960: wm8960@1a { compatible = "wlf,wm8960"; reg = <0x1a>; #sound-dai-cells = <0>; clocks = <&clk_fixed>; clock-names = "mclk"; wlf,shared-lrclk; }; }; }; // Define soundcard fragment@2 { target-path = "/"; __overlay__ { sound: sound { compatible = "simple-audio-card"; simple-audio-card,name = "WM8960 Audio"; simple-audio-card,format = "i2s"; simple-audio-card,bitclock-master = <&dailink0_cpu>; simple-audio-card,frame-master = <&dailink0_cpu>; simple-audio-card,widgets = "Speaker", "Speaker", "Headphone", "Headphone", "Microphone", "Mic"; simple-audio-card,routing = "Speaker", "SPK_LP", "Speaker", "SPK_LN", "Headphone", "HPOUTL", "Headphone", "HPOUTR", "IN1L", "Mic", "Mic", "Mic Bias"; simple-audio-card,cpu { sound-dai = <&i2s1_8ch>; dai-tdm-slot-num = <2>; dai-tdm-slot-width = <32>; }; dailink0_cpu: simple-audio-card,codec { sound-dai = <&wm8960>; }; }; }; }; // Define MCLK fragment@3 { target-path = "/"; __overlay__ { clk_fixed: clk_fixed { compatible = "fixed-clock"; #clock-cells = <0>; clock-frequency = <12288000>; // Typická MCLK pro WM8960 clock-output-names = "mclk"; }; }; }; };

Try to enable i2c1 also (just a stupid suggestion) in armbianEnv.txt and scan the bus with i2cdetect. Who knows, maybe there's a weird mapping of the bus interfaces.

Indeed, the rtc_ds1307 is compatible with the ds3231 and removing pps-gpio w1-gpio did the errors disappear. The RTC module still doesn't work. 😭

The second box. I received both with a non-working native Android. Under armbian built-in mmc is read only, I could not mount "boot" partition (unknown fs type?), so I did not manage to extract original android dts. What am I doing wrong?

I believe the rtc_ds1307 is compatible with the ds3231. You can check that with "modinfo rtc_ds1307" I don't know the hardware, can you check that you don't have pin conflicts? Do you need these overlays : "pps-gpio w1-gpio" ? If not, you might remove them from armbianEnv.txt, boot and check again.

Hello Hqnicolas, thank you very much for the effort you made with the yy3568. I have a nvme SSD connected to .m2 and this works with the youyeetoo kernel "Linux yy3568 4.19.232 #8 SMP Wed Aug 7 10:48:37 CEST 2024 aarch64 GNU/Linux". I tried your Armbian plus the attached patch but the SSD doesn't work. See attached screenlog.0 [ 2.512779] pci 0000:00:00.0: ROM [mem 0xf4200000-0xf420ffff pref]: assigned [ 2.512806] pci 0000:00:00.0: PCI bridge to [bus 01-ff] [ 2.512830] pci_bus 0000:00: resource 4 [io 0x0000-0xfffff] [ 2.512844] pci_bus 0000:00: resource 5 [mem 0xf4200000-0xf5ffffff] [ 2.512857] pci_bus 0000:00: resource 6 [mem 0x300000000-0x33fffffff] [ 2.516131] pcieport 0000:00:00.0: PME: Signaling with IRQ 73 [ 2.516722] pcieport 0000:00:00.0: AER: enabled with IRQ 73 [ 2.518475] phy phy-fe8c0000.phy.2: lane number 0, val 1 [ 2.518506] phy phy-fe8c0000.phy.2: lane number 1, val 2 [ 2.518519] phy phy-fe8c0000.phy.2: bifurcation enabled [ 2.519039] phy phy-fe8c0000.phy.2: rockchip_p3phy_rk3568_init: lock failed 0x6890000, check input refclk and power supply [ 2.519059] phy phy-fe8c0000.phy.2: phy init failed --> -110 [ 2.519102] rockchip-dw-pcie 3c0800000.pcie: probe with driver rockchip-dw-pcie failed with error -110 [ 2.520137] mmc0: new HS200 MMC card at address 0001 [ 2.525326] mmcblk0: mmc0:0001 ISOCOM 57.6 GiB [ 2.529794] rockchip-usb2phy fe8a0000.usb2phy: Requested PHY is disabled [ 2.531377] rockchip-usb2phy fe8a0000.usb2phy: Requested PHY is disabled [ 2.531408] rockchip-usb2phy fe8a0000.usb2phy: Requested PHY is disabled At least is PCI bridge found: root@yy3568:~# lspci -v 00:00.0 PCI bridge: Rockchip Electronics Co., Ltd RK3568 Remote Signal Processor (rev 01) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 73 Bus: primary=00, secondary=01, subordinate=ff, sec-latency=0 I/O behind bridge: [disabled] [16-bit] Memory behind bridge: [disabled] [32-bit] Prefetchable memory behind bridge: [disabled] [64-bit] Expansion ROM at f4200000 [virtual] [disabled] [size=64K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable- Count=1/32 Maskable- 64bit+ Capabilities: [70] Express Root Port (Slot-), MSI 00 Capabilities: [b0] MSI-X: Enable- Count=1 Masked- Capabilities: [100] Advanced Error Reporting Capabilities: [148] Secondary PCI Express Capabilities: [160] L1 PM Substates Capabilities: [170] Vendor Specific Information: ID=0002 Rev=4 Len=100 <?> Kernel driver in use: pcieport It would be great if you find some time to find a solution. Kind Regards, Guenter kernel-rockchip64-edge.patch screenlog.0