All Activity

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.

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.

Trixie ... let me check and fix this. I only tested Bookworm.

Hi, is the hardware clock set before power off ? What does "sudo hwclock" say ? Why did you modify the hwclock-set script ?

Hi, take a look at this similar issue: https://forums.raspberrypi.com/viewtopic.php?t=306463 Accroding to the RFC, the behaviour you see is correct, when Classless-Static-Route (121) is offered, the router option (3) must be ignored.

Maxio Tech kindly sent me some documentation and files. I managed to get the MAE0621 driver compiled into kernel 6.12.24. I had to make some new patches. But I am getting a DMA engine initialization failed message (see attached) in dmesg and Ethernet still doesn't work : [ 157.100705] rk_gmac-dwmac fe010000.ethernet end0: PHY [stmmac-0:00] driver [MAE0621A-Q2C Gigabit Ethernet] (irq=POLL) [ 158.104686] rk_gmac-dwmac fe010000.ethernet: Failed to reset the dma [ 158.105304] rk_gmac-dwmac fe010000.ethernet end0: stmmac_hw_setup: DMA engine initialization failed [ 158.106119] rk_gmac-dwmac fe010000.ethernet end0: __stmmac_open: Hw setup failed Do I also need to update uboot for MAE0621? The current uboot patches I have from the vendor apply to phy_init() which has been deprecated. Or maybe this is a DTB issue? Any hints or advice would be kindly appreciated. dmesg_error.txt

Hi there, Some other solution that I have not been able to make "permanent" yet. Thanks @FredK@Josua-SR and @Igor for allowing me to have some fun building U-Boot once more (have not built a U-Boot since i think 2006!), it for sure did bring back some good memories 🙂 Unfortunately the built U-Boot (with SDHCI_SDMA disabled) did not solve my issue. Then i decided to revert back to the previous release (*-6.6.87-current-mvebu => *-6.6.43-current-mvebu) by moving the symlinks in /boot around, which at least allowed the kernel and some userspace to boot. But due to lacking kernel modules (the 6.6.43 were removed during upgrade to 6.6.87) the box itself did not really work. After some inspection, based on the remarks from @Josua-SR about memory corruption, i decided to check if this might not be just a simple overlapping issue with the images, e.g. kernel image partially occupying where the initrd is loaded. Kernel image Size Size (hex) vmlinuz-6.6.43-current-mvebu 7170736 0x6d6ab0 vmlinuz-6.6.87-current-mvebu 8858728 0x872c68 Loading of files is done as follows: fdt (dtb) 0x2040000 (0x840000 max size) ramdisk (uInit) 0x2880000 kernel (vmlinuz) 0x2080000 (0x7fffff max size) You can already spot that the kernel image will not fit into the area that U-Boot has designated for it: 0x872c68 > 0x7fffff. whereas the 6.6.43 kernel should fit fine: 0x6d6ab0 < 0x7fffff. Some testing showed that when setting ramdisk_addr_r to a higher value - which should fit the bigger kernel image - things started to boot again: => setenv ramdisk_addr_r 2980000 => boot switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 2996 bytes read in 210 ms (13.7 KiB/s) ## Executing script at 03000000 Boot script loaded from mmc 176 bytes read in 201 ms (0 Bytes/s) 28834 bytes read in 424 ms (66.4 KiB/s) 11504908 bytes read in 2562 ms (4.3 MiB/s) 8858728 bytes read in 2218 ms (3.8 MiB/s) ## Loading init Ramdisk from Legacy Image at 02980000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 11504844 Bytes = 11 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 02040000 Booting using the fdt blob at 0x2040000 Loading Ramdisk to 0f507000, end 0ffffccc ... OK reserving fdt memory region: addr=2040000 size=6d000 Loading Device Tree to 0f497000, end 0f506fff ... OK Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0 Next is to try and figure out how I could change ramdisk_addr_r (the initial spot where U-Boot wants to load the ramdisk into), as I prefer not to have to type this at the U-Boot prompt every single time i reboot the box. Hope this helps someone out there with similar issue. Update: I built a U-Boot from the Kobol repo (https://wiki.kobol.io/helios4/uboot/#u-boot-2018) with the SDHCI_SDMA option disabled, and different memory load addresses for the ramdisk, script and efi stuff, see attached. Note i had some issues with the scripts/dtb, some yylloc variable had to be defined as external due to some linker error. in "scripts/dtc/dtc-lexer.lex.c" i had to change line 618 to: extern YYLTYPE yylloc; To update the memory load addresses, in "include/configs/helios4.h": #define KERNEL_ADDR_R __stringify(0x2080000) #define FDT_ADDR_R __stringify(0x2040000) #define RAMDISK_ADDR_R __stringify(0x3000000) #define SCRIPT_ADDR_R __stringify(0x4000000) #define PXEFILE_ADDR_R __stringify(0x4100000) Essentially moved RAMDISK_ADDR_R from 0x0288'0000 to 0x0300'0000 to allow for larger kernel image and moved SCRIPT_ADDR_R (a.o.) to make room for the ramdisk image, from 0x0300'0000 to 0x0400'0000. Then to write the U-Boot single page loader image out to the SDcard: sudo dd if=u-boot-spl.kwb of=/dev/mmcblk0 seek=1 bs=512 Groetjes, PS Warranty until the door for the attached U-Boot.... u-boot-spl.kwb

I’m wondering if it’s your ram settings. If you extract your original android dts. You might find it there.

A new problem( Which desktop environment to choose? Xfce is freezing on login screen, cinnamon do not work at all. Any additional helpful settings on compile time? Or classical runtime debug only?) The most strange thing that I have almost the same box(will take a board photo tomorrow) that do not have either first problem, not current.

I installed minidlna on a Linux Orange Pi PC 6.12.23-current-sunxi and also on an Orange Pi Zero, but it doesn't work; it doesn't appear in the client, on an LG Smart TV. On a Raspberry Pi, it does work; the configuration files are the same, and there are no network rules blocking any traffic... Any ideas what it could be?