rmoriz

@tutralex What boot issue in your case? I just wiped my SD, built out of the current main branch 'Armbian-unofficial_25.02.0-trunk_Orangepipc2_bookworm_edge_6.12.9_minimal.img' and it booted fine but I've currently attached a NanoKVM via HDMI. cat /etc/armbian-release # PLEASE DO NOT EDIT THIS FILE BOARD=orangepipc2 BOARD_NAME="Orange Pi PC2" BOARDFAMILY=sun50iw2 BUILD_REPOSITORY_URL=https://github.com/armbian/build BUILD_REPOSITORY_COMMIT=d4b5c30 LINUXFAMILY=sunxi64 ARCH=arm64 BOOT_SOC= IMAGE_TYPE=user-built BOARD_TYPE=csc INITRD_ARCH=arm64 KERNEL_IMAGE_TYPE=Image KERNEL_TARGET=legacy,current,edge KERNEL_TEST_TARGET=current FORCE_BOOTSCRIPT_UPDATE= FORCE_UBOOT_UPDATE= OVERLAY_DIR="/boot/dtb/allwinner/overlay" VENDOR="Armbian-unofficial" VENDORDOCS="https://docs.armbian.com/" VENDORURL="https://duckduckgo.com/" VENDORSUPPORT="https://community.armbian.com/" VENDORBUGS="https://armbian.atlassian.net/" BOOTSCRIPT_FORCE_UPDATE="no" BOOTSCRIPT_DST="boot.cmd" VERSION=25.02.0-trunk REVISION=25.02.0-trunk BRANCH=edge

@going I'm using an USB-A to barrel adapter. It works fine when directly attached to my old 2017 5k iMac but fails when using a rather sophisticated 45W GAN wall adapter that claims to provide up to 3A at 5V. I run the device headless, nothing attached besides power and Ethernet, except when debugging.

Sorry for my late response. It's hard to reproduce. *current* incomplete observation using your kernels as mentioned in Successful path: When powered on: - at 0+17 seconds the green LED on the board starts turning on solid - at 0+28 seconds the yellow link LED of the ethernet port turns on solid for 3 seconds - at 0+37-40 seconds ICMP responses to PING start The rare unsuccessful boot: - at 0+17 seconds the green LED on the board starts turning on solid - at 0+28 seconds the yellow link LED of the ethernet port turns on solid AND STAYS ON nothing happens from this point on Variant: all LEDs turn off after a while Contrary to my prior observations, it does not have anything to do with UART or HDMI. Even when one or both plugged in, the unsuccessful path stays frozen. At this point I speculate about the power source, maybe the second case is kind of a brown-out. I will try other power sources and report back.

When adding UART the network becomes pingable almost instantaneously, way too fast for a U-Boot issue. I still assume systemd is blocking/waiting. But as I pointed out in my first post, I couldn't find a way to debug it. The kernel commandline options seem to be ignored.

Update: When I disconnect the TTL adapter, the node does not boot anymore to network, e.g. becomes unreachable after the next boot. Looks like at least UART-TTL or HDMI need to be present to successfully complete the system boot and enable networking.

@going Installed. Works fine! in detail: [Started on:] v24.11.1 for Orange Pi PC2 running Armbian Linux 6.11.9-edge-sunxi64 Packages: Debian stable (bookworm) orangepipc2:/tmp:# uname -ar Linux orangepipc2 6.11.9-edge-sunxi64 #1 SMP Sun Nov 17 14:09:55 UTC 2024 aarch64 GNU/Linux [installed the packages:] orangepipc2:/tmp:# dpkg -l|grep linux-\* ii binutils-aarch64-linux-gnu 2.40-2 arm64 GNU binary utilities, for aarch64-linux-gnu target ii console-setup-linux 1.221 all Linux specific part of console-setup ii libselinux1:arm64 3.4-1+b6 arm64 SELinux runtime shared libraries ii linux-base 4.9 all Linux image base package ii linux-dtb-edge-sunxi64 25.02.0-trunk arm64 Armbian Linux edge DTBs in /boot/dtb-6.12.4-edge-sunxi64 ii linux-headers-edge-sunxi64 25.02.0-trunk arm64 Armbian Linux edge headers 6.12.4-edge-sunxi64 ii linux-image-edge-sunxi64 25.02.0-trunk arm64 Armbian Linux edge kernel image 6.12.4-edge-sunxi64 ii linux-libc-dev-edge-sunxi64:arm64 25.02.0-trunk arm64 Armbian Linux support headers for userspace development ii linux-u-boot-orangepipc2-edge 24.11.1 arm64 Das U-Boot for orangepipc2 ii util-linux 2.38.1-5+deb12u2 arm64 miscellaneous system utilities ii util-linux-extra 2.38.1-5+deb12u2 arm64 interactive login tools [after reboot:] ~$ uname -ar Linux orangepipc2 6.12.4-edge-sunxi64 #3 SMP Mon Dec 9 09:41:16 UTC 2024 aarch64 GNU/Linux

Out of curiosity I build an image based on the official repo (default options, just selecting the board, result was Armbian-unofficial_24.11.0-trunk_Orangepipc2_bookworm_edge_6.11.9.img) and it booted fine, too. I guess the issue is already solved in git?

Debug console/TTL is #1 and you can get them for below 5$/€. You may also consider buying a cheap USB capture stick (~15€) for HDMI. You can open the device in VLC or OBS, they are low tech and usually don't need any additional drivers. (Personally, I would also love to see an affordable version of https://linux-automation.com/en/products/usb-sd-mux-fast.html ) For this SBC see also

@goingsure.

@goingawesome! That booted and worked fine. Thank you very much! 👏😃 Can you upstream/merge the fix to Armbian? That would be great! Again, thank you very much!

I just tried the Debian image from http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/service-and-support/Orange-Pi-Pc2.html ailable via https://drive.google.com/drive/folders/1XpcwsdtkUOx3zFg1u9-_7Fd89o8tKLGz and it booted fine. I'm happy to test and report anything. Just tell me what to do 🙂

Update: I changed boot.cmd: Now I'm getting more information ON HDMI (wtf?) while TTL stays the same (zram line). Not sure if this output is related to the systemd-debug or a root cause? Maybe someone else with that device can try the patch provided by @going in to rule out hardware defect of my unit.

@goingThank you! The failed to load '/boot/dtb/overlay/sun50i-h5-fixup.scr' error is now gone: Boot script loaded from mmc 273 bytes read in 5 ms (52.7 KiB/s) Load fdt: /boot/dtb/allwinner/sun50i-h5-orangepi-pc2.dtb 34856 bytes read in 8 ms (4.2 MiB/s) Working FDT set to 4fa00000 4191 bytes read in 8 ms (510.7 KiB/s) Applying kernel provided DT fixup script (sun50i-h5-fixup.scr) ## Executing script at 45000000 10957347 bytes read in 456 ms (22.9 MiB/s) 23443464 bytes read in 978 ms (22.9 MiB/s) Moving Image from 0x40080000 to 0x40200000, end=418f0000 ## Loading init Ramdisk from Legacy Image at 4ff00000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 10957283 Bytes = 10.4 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 4fa00000 Booting using the fdt blob at 0x4fa00000 Working FDT set to 4fa00000 Loading Ramdisk to 4958c000, end 49fff1e3 ... OK Loading Device Tree to 000000004951b000, end 000000004958bfff ... OK Working FDT set to 4951b000 Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] sadly my device is still hanging. Last lines via TTL: Last lines via HDMI: I want to debug systemd but it's ignoring my attempt to set debug options through the kernel cmdline. (systemd debugging info) In boot.cmd I added the systemd debug shell option: Sadly no debug shell appears when booting. Even worse, nothing happens after I run which, according to the systemd debugging page, should do the same as the cmdline. I assume something in the boot process after systemd-binfmt.service is freezing the device. I want to know what unit is the culprit.

Werner, see my post above. I already have a TTL attached to get the output. Please dont't spam useless video links that could have been 3 sentences and are also not related to the issue. Thanks.

I've no clue where to get more debug results. How can I change the bootargs/cmdline?