All Activity

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

I notice that there is a linux driver available at GITHUB for the ds3231, but I have no clue how to compile/install this driver. https://github.com/AxelElRojo/ds3231-linux

The below output with the RTC module taken off the BPI M2Z Further below I saw that there were some pin errors. (most probably nothing to do with this topic) https://paste.armbian.com/axoduwanuq [ 1.020506] usbcore: registered new interface driver usb-storage [ 1.022284] sun6i-rtc 1f00000.rtc: registered as rtc0 [ 1.022371] sun6i-rtc 1f00000.rtc: setting system clock to 1970-01-01T00:00:04 UTC (4) [ 1.023147] i2c_dev: i2c /dev entries driver [ 1.025025] sunxi-wdt 1c20ca0.watchdog: Watchdog enabled (timeout=16 sec, nowayout=0) [ 7.721526] sun8i-h3-pinctrl 1c20800.pinctrl: pin PD14 already requested by onewire@0; cannot claim for pps@0 [ 7.721577] sun8i-h3-pinctrl 1c20800.pinctrl: pin-110 (pps@0) status -22 [ 7.721597] sun8i-h3-pinctrl 1c20800.pinctrl: could not request pin 110 (PD14) from group PD14 on device 1c20800.pinctrl [ 7.721613] pps-gpio pps@0: Error applying setting, reverse things back

Another remark/question: The latest Armbian does not show a driver RTC-ds3231, just the RTC-ds1307 driver. Therefore I used fo my ds3231 RTC module the available driver RTC-ds1307. Could that be the reason for the malfunction of the hwclock?

There seems to be a RTC detected on boot [ 1.018029] sun6i-rtc 1f00000.rtc: registered as rtc0 [ 1.018081] sun6i-rtc 1f00000.rtc: setting system clock to 1970-01-01T00:00:04 UTC (4) Just to confirm, you could disconnect your RTC and boot again. Then check the boot log if the system says anything about rtc.

To my understanding and the documentation I found, by investigating the RTC address, with the outcome 068, it indicates that the RTC driver is not loaded, otherwise the address request would show UU as outcome.

When connected to WiFi root@clearview:~# timedatectl status Local time: Wed 2025-04-23 09:56:59 CEST Universal time: Wed 2025-04-23 07:56:59 UTC RTC time: Wed 2025-04-23 07:56:58 Time zone: Europe/Brussels (CEST, +0200) System clock synchronized: no NTP service: active RTC in local TZ: no After power down and disconnected from WiFi root@clearview:~# timedatectl status Local time: Wed 2025-04-23 10:04:43 CEST Universal time: Wed 2025-04-23 08:04:43 UTC RTC time: Wed 1970-01-01 00:02:45 Time zone: Europe/Brussels (CEST, +0200) System clock synchronized: no NTP service: active RTC in local TZ: no

After boot, can you show the output of "timedatectl status" ?

Just measured again the battery on the battery pins of the RTC-ds3231, and it shows me 3.6 volt (not the BPI 3.3 volt pins (1 + 9)

See link https://paste.armbian.com/alehuretiw Now connected to WiFi

None of those boards are officially supported, so we are not aware on their hw support status. Those are also 32bit architecture, while we only provide 64bit support for Rpi. Did you use Armbian for Rpi? And which particular build? And on which Rpi? There are many unknown things - big difference. Hard to determine the reason from current informations.

This would suggest that the battery of the rtc is dead, but it is confusing because you say it works with RPI zero. Could you provide logs with sudo armbianmonitor -u

Indeed, the hardware clock has been set and checked before power off. 1) date -s "April 22, 2024 11:54:00" 2) hwclock -w 3) hwclock -r 4) battery hwclock 3.6V 5) works flawless with RPi Zero 2W 6) i2cdetect -y 0 shows address 068 Why did you modify the hwclock-set script ? Suggested by many, but without modifying this script, it does not change mallfunction of the hwclock. When connected to WiFi hwclock --verbose tells me following: hwclock from util-linux 2.38.1 System Time: 1745389217.903091 Trying to open: /dev/rtc0 Using the rtc interface to the clock. Last drift adjustment done at 1745317708 seconds after 1969 Last calibration done at 1745317708 seconds after 1969 Hardware clock is on UTC time Assuming hardware clock is kept in UTC time. Waiting for clock tick... ...got clock tick Time read from Hardware Clock: 2025/04/23 06:20:20 Hw clock time : 2025/04/23 06:20:20 = 1745389220 seconds since 1969 Time since last adjustment is 71512 seconds Calculated Hardware Clock drift is 0.000000 seconds 2025-04-23 08:20:18.895813+02:00 After power down and When disconnected from WiFi (my application and so the reason why I need a hwclock to work) hwclock --verbose tells me following: hwclock from util-linux 2.38.1 System Time: 1745389772.399976 Trying to open: /dev/rtc0 Using the rtc interface to the clock. Last drift adjustment done at 1745317708 seconds after 1969 Last calibration done at 1745317708 seconds after 1969 Hardware clock is on UTC time Assuming hardware clock is kept in UTC time. Waiting for clock tick... ...got clock tick Time read from Hardware Clock: 1970/01/01 00:04:02 Hw clock time : 1970/01/01 00:04:02 = 242 seconds since 1969 Time since last adjustment is 1745317466 seconds Calculated Hardware Clock drift is 0.000000 seconds 1970/01/01 01:04:00.760027+01:00

The driver is well so the problem seems you are in the wrong ethernet phy. Change from phy0 to phy1 in the ethernet node.

If you have the EFI version installed in SPI, it can only run EFI-enabled images. To run "regular" images with u-boot, you need to have a version with u-boot in SPI.