Armbian 24.2 is broken on Orange PI PC2

[rmoriz]

@goingsure.

[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, too. I guess the issue is already solved in git?

[going]

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

[rmoriz]

@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

 

 

 

[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.

Edited December 16 by rmoriz

[going]

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

[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.

[going]

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 by going
Add P.S.

[rmoriz]

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.

 

 

[going]

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?

[rmoriz]

@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.