djurny

Hi @Ed van den Enden, the blob shown was a device tree overlay. The device tree is the non-PCI variant of PCI config spaces. It specifies which hardware is located where and on what bus and so on. There are default device tree overlays for adding an 'external' RTC to the board, the one I shared is based on this, but just to make sure the 'external' will be 'found' first (and therefore updated by kernel). Edit: to be clear - if you choose to use a device tree overlay where the RTC is listed as the first RTC in your system, you do not need to use the script. If you do not use the device tree overlay to put your external RTC first in line, you can try if the script suits your needs. The scrip attached, you can just put on your system, somewhere in /usr/local/sbin/ would be my advice. To make it work, you have to trigger it during boot and on interval basis. I think I have it triggered from /etc/rc.local (not the best spot, but it works). Set proper ownership (root as owner and anyone in the adm group can execute): sudo chown root:adm /usr/local/sbin/rtc-sync sudo chmod 0750 /usr/local/sbin/rtc-sync Add to /etc/rc.local: /usr/local/sbin/rtc-sync -A start (Create and) Add to /etc/cron.d/rtc-sync: */22 * * * * root /usr/local/sbin/rtc-sync -A update The cron job will start rtc-sync 'update' every 22 minutes, which checks if the wallclock is synchronized by ntp. If so, if will update the 'freerunning' clocks with the wallclock. 'freerunning' means "not updated by ntpd" in this case. For all this to work, you do need to install and configure ntp. The ntp daemon will update the wallclock and the kernel will set the first RTC it sees (/dev/rtc0) with the adjusted wallclock it keeps. The kernel will not update any other RTC than the first one -> this is where the rtc-sync script will help. This update will happen every 11 minutes and is hardcoded in the kernel somewhere. (See https://unix.stackexchange.com/questions/285129/switch-off-11-minute-kernel-mode for some more info.) Hope this all helps, Groetjes, PS I forgot why I added the link to the topic about the NTP server with external GPS receiver... I guess I sometimes get a little bit distra

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

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

Hi there, Seems that you are trying to download an incorrect image for HASS: 2024-05-14 11:38:38.835 ERROR (MainThread) [supervisor.docker.interface] Can't install ghcr.io/home-assistant/odroid-n2-homeassistant:2024.5.3: 404 Client Error for http+docker://localhost/v1.45/images/ghcr.io/home-assistant/odroid-n2-homeassistant:2024.5.3/json: Not Found ("No such image: ghcr.io/home-assistant/odroid-n2-homeassistant:2024.5.3") 2024-05-14 11:38:38.837 WARNING (MainThread) [supervisor.homeassistant.core] Error on Home Assistant installation. Retrying in 30sec Looks like the HASS supervised installation is trying to install a docker image for an Odroid N2 instead of the Libre Renegade? According to Odroid, the N2 is based on an Amlogic SoC and not on a Rockchip SoC (like the Libre Renegade). Apart from that, it appears it cannot locate the docker image either. Perhaps contact the HASS community? You can also try to install Armbian on your SBC and use the regular Docker image for HASS. Hope that helps, Groetjes,