djurny

Hi @wolf7250, I'm not familiar with OMV, so not sure what that update/upgrade process looks like. If it will update/upgrade the armbian packages to the latest release 25.11, then the correct version of armbian-bsp-cli will be installed. The installation of that package should update /boot/boot.scr and make a new U-Boot image available that you would have to install with nand-sata-install. Gr,

Hi @wolf7250, The correct U-Boot and bootscript is for sure in the newest release. I built recently and all is there and working without issue on my helios4. Let's unravel what is happening for you and get that sorted out. Gr,

Hi @wolf7250, That does not look like the new bootscript. Did you update already? To get it working again, you can try the quick workaround as you pointed to earlier, which should allow more room for U-Boot loading kernel, initrd and the rest. Gr,

Hi @wolf7250, Can you post the serial console output? Want to make sure the new U-Boot and bootscript are used. Gr,

Hi @wolf7250, Should be, yes. If not, do check back in here 🙂 Gr,

Hi @wolf7250, When you upgrade, one of the packages will update the bootscript (/boot/boot.scr), that will prevent a load address conflict - this should be armbian-bsp-cli iirc. The new bootscript will either calculate the load addresses or use new defaults to avoid the image overlap/"corruption" issue. The U-Boot for the helios4 has been updated as well to enable load address calculation, instead of using hardcoded values. To update U-Boot, run nand-sata-install and select to "install/update the bootloader on SD/MMC" (see here). Groetjes,

I think it still makes sense. And in the off chance that you DO find you have some time leftover, it's also nice to tinker and hobby about with. Mine is still running Buster and has not missed a beat since I got the thing - besides some issues with the SATA connector on the top drive and the inability to upgrade RAM. Groetjes,

Hi @Scott Ksander, Can you share on which I2C bus the RTC was detected? On my Nanopi Neo3 it was on i2c0, but I see in the meson DTs that RTC is on i2c2. Perhaps you can start with a barebones overlay and add until it starts to work. /dts-v1/; /plugin/; / { fragment@1 { target = <&i2c2>; __overlay__ { #address-cells = <1>; #size-cells = <0>; pcf8563@51 { compatible = "nxp,pcf8563"; reg = <0x51>; status = "okay"; }; }; }; }; Groetjes,

Some more info, I found a lot of DT entries for the PCF8563 in a recent codebase for some of the Amlogic SoCS, but not the C2. What is shown are: HC4 M2 Perhaps you can check if those overlays are compatible with the C2 and experiment a bit? Groetjes,

Hi @Scott Ksander, `i2cdetect` will just detect stuff on the I2C bus, you would not need a DT overlay for the device for that to work. For the kernel to detect the device and load the appropriate kernel module for it, you do have to make sure the device is known in the DT. I'm not sure about your board, but for a PCF8523 (different RTC) my Nanopi Neo3 I had to add or adjust an existing user overlay to make the PFC known to the kernel. /dts-v1/; /plugin/; / { compatible = "rockchip,rk3328"; fragment@1 { target = <&i2c0>; __overlay__ { #address-cells = <1>; #size-cells = <0>; pcf8523@68 { compatible = "nxp,pcf8523"; reg = <0x68>; status = "okay"; }; }; }; }; &rk805 { rk808-rtc { status = "disabled"; }; }; For a DS3231 I also had to add a user overlay that would tell the kernel that it can use the DS3232 driver for a DS3231 device. You most likely already found all the information on this already on the interwebs. You will have to adjust the compatible entry to your board, you might even try without that line completely. Add the file to `/boot/overlay-user/` and then compile and add to `armbianEnv.txt` using `armbian-add-overlay`. Groetjes,

Hi @Scott Ksander, Can you share a little more information? Like what errors are logged, which commands you tried to use, what DT and overlay you tried,etc. Thanks,

Hi @loeriver, Yes, it depends a bit on what brand/type and how you connect the USB to serial converter. The ones i use to monitor the serial console on all my SBCs have these spurious events as well, even when I do not connect the +5Vdc on the serial/UART end. For me they are sometimes preventing a full board shutdown as they seem to leach power to the SBC (not sure how this is happening electrically, perhaps some pull-ups allowing current to flow from RX into the Vcc of the board?). You could try to remove the dongle from the system to see if that has any effect to rule this out completely. Groetjes,

Hi there, I ran octoprint and klipper on a orangepi zero (not at the same time). Octoprint from docker and klipper I cannot remember. Octoprint ran fine but it did have some issues when the CPU got overloaded with loading a new gcode file while printing for example. If you do things one by one it should be OKish. Btw i ran octoprint in a 512MB version, not on the 256MB one. Groetjes,

Hi there, Then I would advise to try to: bridge NIC1 and NIC2, then configure the resulting bridge interface br0 to 192.168.100.101/24 configure 'device 1' to 192.168.100.102/24 or some other IP address that does not overlap/conflict with any other device on the 192.168.100.0/24 network. This setup should present "one interface" to the 192.168.100.0/24 network, pulling 'device 1' into the network as it were. I'm not sure if you have to enable ip forwarding in case you create a bridge, my experience with bridge (both networking and card wise) is limited. Groetjes, Btw, there has to be a reason why PC1 and the gateway/router in the red box are not able to be changed 😉 Perhaps the people that set it up that way were actively trying to prevent fanning out into different additional networks. (I know many employers do not allow this on their office network for example, for very good reasons...)

Not to forget this: What is your endgoal here? You just want to ping 'device 1' from PC1 ? Or you want to connect to 'device 1' from PC1 using some protocol? Gr,