December 13, 20241 yr 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?
December 13, 20241 yr 9 часов назад, rmoriz сказал: 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 I spent three days looking for a problem testing kernel variants on my bananapi-m64 (a64 core). I have no problem. Let's just test the new kernel: Orangepipc2-6.12-crust-mini + linux-image 6.12.4
December 15, 20241 yr @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
December 16, 20241 yr 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. Edited December 16, 20241 yr by rmoriz
December 17, 20241 yr 16 часов назад, rmoriz сказал: 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. I also noticed something similar when I was testing on bananapim64. I run without HDMI, only UART and Ethernet. The Ethernet starts working immediately, but the UART does not respond to the keyboard from the minicom. After a few minutes, everything magically starts working. These two boards of ours have not been tested for a long time. Perhaps something in u-boot needs to be fixed. Try to view the kernel messages by first adding debug level 10. sudo nano /boot/armbianEnv.tx verbosity=10 # sudo reboot sudo dmesg | grep -i ether Or something like that
December 20, 20241 yr 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.
December 23, 20241 yr 20.12.2024 в 15:32, rmoriz сказал: 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. My guess: It can be a /boot/boot.cmd script. Source for sunxi64 config/bootscripts/boot-sun50i-next.cmd, for sunxi config/bootscripts/boot-sunxi.cmd The kernel command line parameters for the console and display are set in it. By default, in the settings file armbianEnv.txt It must be: console=both You can try to change console=display or any. Please keep me informed if you find an error in the script. P.S. In any case, the connection from the console service to other services seems strange to me. Maybe look in the system event log of the system in the order in which this happens during a crash? Edited December 23, 20241 yr by going Add P.S.
December 23, 20241 yr 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.
December 24, 20241 yr 17 часов назад, rmoriz сказал: Variant: all LEDs turn off after a while I've watched it. It looks like the OS has fallen asleep when the user is not doing anything. 17 часов назад, rmoriz сказал: At this point I speculate about the power source, maybe the second case is kind of a brown-out. What kind of power supply is it now? And what is connected to the board besides the mouse and keyboard?
December 25, 20241 yr @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.
January 11, 20251 yr Maybe it will be useful for someone. Working file "sun50i-h5-orangepi-pc2.dtb" with processor overclocking to 1.44 GHz. For everything to work, you also need to correct the parameter MAX_SPEED=1440000 in the file "/etc/default/cpufrequtils". As for the boot issue, it's still not solved. I just wrote a script that after the next update replaces the non-working "/boot/dtb/allwinner/sun50i-h5-orangepi-pc2.dtb" with the one attached in this post (this needs to be done before rebooting). cpufrequtils sun50i-h5-orangepi-pc2.dtb Edited January 11, 20251 yr by tutralex A small clarification.
January 22, 20251 yr @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 Edited January 22, 20251 yr by rmoriz
January 23, 20251 yr 12.01.2025 в 01:22, tutralex сказал: Working file "sun50i-h5-orangepi-pc2.dtb" with processor overclocking to 1.44 GHz. Warning: H5 processors from the first batches cannot be overclocked to these frequencies. On my device, I was unable to get stable operation at a frequency higher than 1.2Ghz.
January 23, 20251 yr 12.01.2025 в 01:22, tutralex сказал: I just wrote a script that after the next update replaces the non-working "/boot/dtb/allwinner/sun50i-h5-orangepi-pc2.dtb" with the one attached in this post (this needs to be done before rebooting). Can you post your changes here as "git diff" or "git format-patch -1"
January 24, 20251 yr @rmoriz The problem exists in the official "current" image. @going Oh, forgot to say that this is the latest revision of the board with a 1.368 GHz processor. These settings will not break older devices and can be easily rolled back. Edited January 24, 20251 yr by tutralex 1.368 freq
January 24, 20251 yr Цитата Can you post your changes here as "git diff" or "git format-patch -1" I'm afraid I don't have enough experience for this.
March 13, 20251 yr In case anyone's still interested in this, here's the diff between an up-to-date -current-sunxi64 setup and the dtb linked above: # diff sun50i-h5-orangepi-pc2.dts sun50i-h5-orangepi-pc2-armbian-forum.dts 61a62,69 > scpi { > compatible = "arm,scpi"; > mboxes = < 0x06 0x02 0x06 0x03 >; > mbox-names = "tx\0rx"; > shmem = < 0x07 >; > phandle = < 0x49 >; > }; > 65c73 < phandle = < 0x49 >; --- > phandle = < 0x4a >; 68c76 < sound-dai = < 0x06 >; --- > sound-dai = < 0x08 >; 72c80 < sound-dai = < 0x07 >; --- > sound-dai = < 0x09 >; 76,83d83 < scpi { < compatible = "arm,scpi"; < mboxes = < 0x08 0x02 0x08 0x03 >; < mbox-names = "tx\0rx"; < shmem = < 0x09 >; < phandle = < 0x4a >; < }; < 343c343 < phandle = < 0x08 >; --- > phandle = < 0x06 >; 382,383d381 < phys = < 0x18 0x00 >; < phy-names = "usb"; 394,395d391 < phys = < 0x18 0x00 >; < phy-names = "usb"; 835c831 < phandle = < 0x07 >; --- > phandle = < 0x09 >; 863c859 < dma-names = "tx\0rx"; --- > dma-names = "rx\0tx"; 879c875 < dma-names = "tx\0rx"; --- > dma-names = "rx\0tx"; 895c891 < dma-names = "tx\0rx"; --- > dma-names = "rx\0tx"; 911c907 < dma-names = "tx\0rx"; --- > dma-names = "rx\0tx"; 993c989 < phandle = < 0x06 >; --- > phandle = < 0x08 >; 1099c1095 < silergy,fixed-microvolt = < 0x10c8e0 >; --- > silergy,fixed-microvolt = < 0x124f80 >; 1191c1187 < phandle = < 0x09 >; --- > phandle = < 0x07 >; 1522a1519,1524 > > opp-1440000000 { > opp-hz = < 0x00 0x55d4a800 >; > opp-microvolt = < 0x155cc0 0x155cc0 0x155cc0 >; > clock-latency-ns = < 0x3b9b0 >; > }; 1566c1568 < linux,code = < 0x100 >; --- > linux,code = < 0x74 >; 1598d1599 < sound_hdmi = "/sound_hdmi"; 1599a1601 > sound_hdmi = "/sound_hdmi"; Unfortunately that doesn't make my systems stable (running 6.6.75-current-sunxi64): they keep kernel oopsing every few hours/days. I initially thought those crashes were related to DVFS, but even running echo 480000 >/sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq to keep it at the minimum supported frequency doesn't seem to improve things. Attached is a dmesg log of a few kernel stacktraces happening right after boot. Those keep happening every few minutes until the board resets on a kernel OOPS. I'm going to give linux-image-edge-sunxi64 a shot and will report back. dmesg.log
March 13, 20251 yr Looks like linux-image-edge-sunxi64 didn't help. I managed to cook a custom image using u-boot and sun50i-h5-orangepi-pc2.dtb from Armbian to boot Debian's netinstaller and go from there. I'm now running Debian 12 on kernel 6.1.123-1. I'm going to let that system run for a few days and if I don't see any crash I'll probably use that as base image for the other fielded systems.
March 21, 20251 yr I just updated my system and it failed to boot, see here: I assume I have the same cause as you guys? What can I do to recover my install and get it booting?
April 8, 20251 yr @Magnets Remove the SD card from the board, insert it into the card reader, find and replace the file "/boot/dtb/allwinner/sun50i-h5-orangepi-pc2.dtb" with the one in my attachments or extract it from your old image. Edited April 8, 20251 yr by tutralex link to comment
April 12, 20251 yr Author Solution Finally Armbian 25.2.3 (kernel 6.12.20) fixes the boot problem on PC2! Upgrade from 23.11/6.1.x to 25.2.3/6.12.20 Edited April 12, 20251 yr by Moklev
April 12, 20251 yr FYI: My node running 25.02.0-trunk as mentioned above has stability issues after ~30 days. I had to reboot it at least 2 times. Cause unknown. Maybe not an issue depending on the workload/use case:
May 18, 20251 yr Author No problem installing Armbian stable 23.11 (or 23.8) and then upgrading to 25.2.3. Don't use nightly/trunk... francesco@orangepipc2:~$ uptime 08:32:44 up 29 days, 16:57, 1 user, load average: 0,26, 0,64, 0,36
May 30, 20251 yr Hello. I wonder if this issue is connected to my issue - to show something on i2c, while there is nothing, and not be able to communicate on it ? Edited May 30, 20251 yr by Yordan Yanakiev
November 25, 2025Nov 25 I recently updated my Orange-Pi-PC2 to Debian 13 (trixie). Image: "Armbian_community_26.2.0-trunk.7_Orangepipc2_trixie_current_6.12.58_minimal.img.xz". Everything works now, and the issue mentioned above no longer exists! Maybe it will be useful to someone... However, I still had to make some adjustments to "/boot/dtb/allwinner/sun50i-h5-orangepi-pc2.dtb" sun50i-h5-orangepi-pc2.dtb: Overclocked the processor to 1.44 GHz (new board revision 1.368 GHz CPU!); Similar to the other firmware versions, I configured the red LED as a power indicator (constantly lit) and the green LED as a heartbeat indicator. For everything to work, you also need to correct the parameter MAX_SPEED=1440000 in the file "/etc/default/cpufrequtils" cpufrequtils.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.