guidol

Ok, returning to the original question. I did some dissection, and the problem appears to be a 6.1.x kernel bug as opposed to something being broken on the Armbian side.
Disclaimer: I did not use a proper Armbian build; rather just took the kernel code from "linux-6.1.y" branch and used "config-6.1.77-legacy-sunxi".
 
So here are my results:
The v6.1.87 is booting fine: the same way as "linux-image-legacy-sunxi" version 24.2.1. The v6.1.88 is broken with the same symptoms as "linux-image-legacy-sunxi" version 24.5.1. The culprit is the following commit:
07b37f227c8daa27e68f57b1c691fab34a06731e (HEAD) random: handle creditable entropy from atomic process context
commit 07b37f227c8daa27e68f57b1c691fab34a06731e Author: Jason A. Donenfeld <Jason@zx2c4.com> Date: Wed Apr 17 13:38:29 2024 +0200 random: handle creditable entropy from atomic process context commit e871abcda3b67d0820b4182ebe93435624e9c6a4 upstream. The entropy accounting changes a static key when the RNG has initialized, since it only ever initializes once. Static key changes, however, cannot be made from atomic context, so depending on where the last creditable entropy comes from, the static key change might need to be deferred to a worker. Previously the code used the execute_in_process_context() helper function, which accounts for whether or not the caller is in_interrupt(). However, that doesn't account for the case where the caller is actually in process context but is holding a spinlock. This turned out to be the case with input_handle_event() in drivers/input/input.c contributing entropy: [<ffffffd613025ba0>] die+0xa8/0x2fc [<ffffffd613027428>] bug_handler+0x44/0xec [<ffffffd613016964>] brk_handler+0x90/0x144 [<ffffffd613041e58>] do_debug_exception+0xa0/0x148 [<ffffffd61400c208>] el1_dbg+0x60/0x7c [<ffffffd61400c000>] el1h_64_sync_handler+0x38/0x90 [<ffffffd613011294>] el1h_64_sync+0x64/0x6c [<ffffffd613102d88>] __might_resched+0x1fc/0x2e8 [<ffffffd613102b54>] __might_sleep+0x44/0x7c [<ffffffd6130b6eac>] cpus_read_lock+0x1c/0xec [<ffffffd6132c2820>] static_key_enable+0x14/0x38 [<ffffffd61400ac08>] crng_set_ready+0x14/0x28 [<ffffffd6130df4dc>] execute_in_process_context+0xb8/0xf8 [<ffffffd61400ab30>] _credit_init_bits+0x118/0x1dc [<ffffffd6138580c8>] add_timer_randomness+0x264/0x270 [<ffffffd613857e54>] add_input_randomness+0x38/0x48 [<ffffffd613a80f94>] input_handle_event+0x2b8/0x490 [<ffffffd613a81310>] input_event+0x6c/0x98 According to Guoyong, it's not really possible to refactor the various drivers to never hold a spinlock there. And in_atomic() isn't reliable. So, rather than trying to be too fancy, just punt the change in the static key to a workqueue always. There's basically no drawback of doing this, as the code already needed to account for the static key not changing immediately, and given that it's just an optimization, there's not exactly a hurry to change the static key right away, so deferal is fine. Reported-by: Guoyong Wang <guoyong.wang@mediatek.com> Cc: stable@vger.kernel.org Fixes: f5bda35fba61 ("random: use static branch for crng_ready()") Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff --git a/drivers/char/random.c b/drivers/char/random.c index 5d1c8e1c99b5..fd57eb372d49 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -683,7 +683,7 @@ static void extract_entropy(void *buf, size_t len) static void __cold _credit_init_bits(size_t bits) { - static struct execute_work set_ready; + static DECLARE_WORK(set_ready, crng_set_ready); unsigned int new, orig, add; unsigned long flags; @@ -699,8 +699,8 @@ static void __cold _credit_init_bits(size_t bits) if (orig < POOL_READY_BITS && new >= POOL_READY_BITS) { crng_reseed(); /* Sets crng_init to CRNG_READY under base_crng.lock. */ - if (static_key_initialized) - execute_in_process_context(crng_set_ready, &set_ready); + if (static_key_initialized && system_unbound_wq) + queue_work(system_unbound_wq, &set_ready); wake_up_interruptible(&crng_init_wait); kill_fasync(&fasync, SIGIO, POLL_IN); pr_notice("crng init done\n"); @@ -870,8 +870,8 @@ void __init random_init(void) /* * If we were initialized by the cpu or bootloader before jump labels - * are initialized, then we should enable the static branch here, where - * it's guaranteed that jump labels have been initialized. + * or workqueues are initialized, then we should enable the static + * branch here, where it's guaranteed that these have been initialized. */ if (!static_branch_likely(&crng_is_ready) && crng_init >= CRNG_READY) crng_set_ready(NULL);  
The code change is rather simple: it switches from using "execute_in_process_context" to "queue_work", but that switch is causing the lock-up. I don't have enough knowledge to debug why it is happening: suspect some sort of a deadlock.
 
I've tried taking the "random.c" from the 6.6.34 kernel and doing hacky modifications to get to to compile on 6.1.y: that fixed the problem, so I'm guessing the "random.c" on the 6.1.y branch is not in a good state.
 
Does anyone have suggestions on how to proceed from here?

Hello all
 
Lately I have been spending some time trying to update Kernel and OS to my Lichee Zero Pi.
I reached to compile Kernel 5.20 and upgrade Debian from Jessie (8) (official image) to Buster (10), and stop there.
 
I've faced the same USB Keyboard problem, as mentioned before by @Kot, and solved by simply replacing the dtb file in the SD for the one compiled.
 
You can see a short guide how I compiled the Lichee Zero Pi Kernel here
 
Moving from Jessie to Buster was not really complicated but it needs a lot of time,
First I upgraded from Jessie (8) to Stretch (9) and Second from Stretch (9) to Buster (10)
My initial LicheeZero Pi image was: mindb_dd.tar.gz you can downloaded at the unofficial Lichee Zero Pi site.
MOVING FROM JESSIE TO STRETCH
I followed these steps to get Jessie Support using freexian: https://www.freexian.com/lts/extended/docs/how-to-use-extended-lts/
1. Manually installed freexian-archive-keyring package with:
 
wget --no-check-certificate https://deb.freexian.com/extended-lts/pool/main/f/freexian-archive-keyring/freexian-archive-keyring_2022.06.08_all.deb && sudo dpkg -i freexian-archive-keyring_2022.06.08_all.deb  
2. Modify the sources list to the ones from freexian config file in this location: /etc/apt/sources.list or /etc/apt/sources.list.d/multistrap-debian.list
Comment all lines in the sources list file and add these other lines
 
deb [arch=armhf] http://deb.freexian.com/extended-lts jessie main contrib non-free deb-src [arch=armhf] http://deb.freexian.com/extended-lts jessie main contrib non-free  
3.  Installed sudo, correct host name and enable bash history
apt update # Here, I was able to install sudo apt install sudo # Correct the host name adding LicheePi together to localhost: 127.0.0.1 LicheePi localhost nano /etc/hosts # And enable bash history touch ~/.bash_history  
4. Modify again source list to add Stretch sources listed here: https://debiansupport.com/mirrors/  sources file /etc/apt/sources.list.d/multistrap-debian.list 
deb [arch=armhf] http://archive.debian.org/debian stretch main contrib non-free deb-src [arch=armhf] http://archive.debian.org/debian stretch main contrib non-free deb [arch=armhf] http://archive.debian.org/debian-security stretch/updates main contrib non-free deb-src [arch=armhf] http://archive.debian.org/debian-security stretch/updates main contrib non-free  
5. Now Update, Upgrade and dist-upgrade
sudo apt clean sudo apt update sudo apt upgrade -y sudo apt dist-upgrade -y  
MOVING FROM STRETCH TO BUSTER
Just follow again the steps 4 and 5, but replacing the sources list by the ones of Buster founded in the above link.
 
Hope this help somebody
Regards

I do ran into the same problem today with my rock-3a running
    Armbian 24.2.1 Bookworm with Linux 6.6.16-current-rockchip64

It occurred after re-boot of the system because of the banner the message "Please reboot system do to kernel-updated" appeared. After that ethernet (was named "end0") did not come up anymore. When activating using "nmtui" the message comes:
"Activation failed. Device could not be prepared for activation ..." (freely translated from German language).

journalctl -x gives the following:
(armbian-monitor -u already performed)
Mar 14 10:51:01 cloud kernel: rk_gmac-dwmac fe010000.ethernet end0: __stmmac_open: Cannot attach to PHY (error: -19) Mar 14 10:51:01 cloud NetworkManager[745]: <info>  [1710409861.7565] device (end0): state change: config -> failed (reason 'config-failed', sys-iface-state: 'managed') Mar 14 10:51:01 cloud NetworkManager[745]: <warn>  [1710409861.7579] device (end0): Activation: failed for connection 'Ethernet' Mar 14 10:51:01 cloud NetworkManager[745]: <info>  [1710409861.7588] device (end0): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed')
After all I updated the bootloader (using armbian-config) and it luckily resolved the problem ...

Thx for reading this. Hope it helps others ...

You could test the options from this page:
https://unix.stackexchange.com/questions/387502/disable-bluetooth-at-boot
 
- via /etc/bluetooth/main.conf
           AutoEnable=false
- rfkill
           sudo rfkill block bluetooth
- lsmod / blacklist the modules

Duo2 was tested with 23.5.2 image that was uploaded yesterday.

The command below seems to be the solution for this problem: 
 
ethtool -K enp1s0 tso off  
I have found this post, where the command was.
 

I can recommend the USB Image Tool:
Info-Page: https://www.alexpage.de/usb-image-tool/
Download at: https://www.alexpage.de/usb-image-tool/download/
 

First of all I want to thank Armbian and balbes150 for producing a working image for D1! I still remember the old days of fiddling with ancient BSP kernels for Allwinner-based boards when they first showed up years ago. Today I'm able to boot into mainline on a fresh board with a fresh ISA. Great work, really appreciated and hopefully this will speed up RISC-V adoption across the industry!
 
I installed the image 5.19.0-rc1-d1  on my MQ-Pro and it worked like a charm. Eventually "upgraded" it to sid by swapping out repos but the kernel is still the same custom build. Debian now has linux-image-5.19.0-1-riscv64 in its repos - any idea if it would even boot on D1 or I better stick with the custom one? If so - where can I get a more recent build as there's an announcement of a 5.19.0 build in this thread.

Added alpha version of image build support for RISC-V.
So far, this is an early version and some of the functions do not work in it.
Currently, support has been added for the StarFive model.
 
https://rvspace.org/
 
Details can be seen in this topic.
 
https://forum.rvspace.org/t/armbian-for-starfive-build-system-ubuntu-debian/468
 
 
Added support for Nezha D1 and Lichee RV (Dock) with Allwinner D1 RISC-V chip. To start the system. Download the image, unpack it, burn it to the SD card.  Connect the SD card to the device and turn on the power. Further steps for initial setup are similar for all Armbian systems.
 
For the Nezha D1 model, HDMI, LAN, USB, analog audio via 3.5 jack works.
For Lichee RV Dock  works HDMI WiFi USB USB-LAN
 
Link to download images.
https://disk.yandex.ru/d/da8qJ8wyE1hhcQ
 
https://www.cnx-software.com/2021/12/30/sipeed-lichee-rv-risc-v-module-gets-5-carrier-board-with-hdmi-and-usb-ports-optional-wifi/
 
forum MangoPI
https://forum.mangopi.org/

Since several weeks, we build all not supported images that at least build, but they are elsewhere https://github.com/armbian/community and untested.
 
Improvements, if any, are still accepted:
https://docs.armbian.com/Process_Contribute/

Exactly, Easy!!
I comment gpu_mem=256 ...and armbian its for know correctly booted and hardware detect on Raspberry Pi Zero 2 W . 
Thank you!!
 

for anyone have same problem 7" display
what i did was changing boot script

 1. modify file /boot/boot.cmd
setenv disp_mode "1024x600p60"
mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr
 
but now I have another problem.
It's loading long time can anybody help me with that?

Then either adjust one of the ip addresses to be in the same /24 subnet or adjust subnet mask on both to /16

Here are compiled kernel and uboot by me with ethernet and lcd 800x480 support:
 
https://github.com/nathalis/Lichee_kernel_uboot_eth_lcd800x480_
 
also guide how to compile it...
 

Of course, I will, but I'm far from that. Most probably it would be faster if I shared the kernel file, that would render all available 2G IoT images usable. I will see what I can do.
 
Unfortunately I couldn't make the sound card work yet, and on my device the touch screen stopped to respond. I ordered another one from Aliexpress, but it will take a few weeks to arrive. I also discovered that the full size USB port is running at 10 mbps normally, because the modem needs to initialize the micro USB port first, and this procedure takes about six seconds. If we start to load the kernel USB drivers after this, then our USB works at 480 mbps. I have to figure out how to deal with it.

The Z80-MBC2 is a 4-chip Z80-computer which can run CP/M and has a 5V TTL-serial-port.
The Z80-MBC2 is powered and accessable via a USB-TTL-serial-adapter (configured to 5V - not 3.3V) type CP2102 seen as /dev/ttyUSB0
 
The easy way would be to connect the USB-adapter to a Pi-style computer wth armbian, login via SSH and start minicom for the port.

But that way doenst look as good - to me - as the following way  
 
First we need to install ser2net and telnet (telnet doesnt seem to be installed as standard) in armbian via
apt install ser2net telnet
 
Then we have to edit /etc/ser2net.conf (delete all lines after the comments and insert these):
 
BANNER:banner:\r\nser2net port \p device \d [\s] (Debian GNU/Linux)\r\n\r\n BANNER:z80mbc2:\r\nZ80-MBC2 via Telnet on Port [\p]\r\nDevice connected to [\d]\r\nConnection Speed [\s]\r\n # 2000:telnet:600:/dev/ttyS0:9600 8DATABITS NONE 1STOPBIT banner # 2001:telnet:600:/dev/ttyS1:9600 8DATABITS NONE 1STOPBIT banner # 3000:telnet:600:/dev/ttyS0:19200 8DATABITS NONE 1STOPBIT banner # 3001:telnet:600:/dev/ttyS1:19200 8DATABITS NONE 1STOPBIT banner 127.0.0.1,2023:telnet:0:/dev/ttyUSB0:115200 8DATABITS NONE 1STOPBIT z80mbc2  
Now create a login "shell"/pogram for the new local user z80mbc2 as /usr/local/bin/z80mbc2 :
 
#!/bin/sh /usr/bin/telnet 127.0.0.1 2023 exit Do a chmod 755  /usr/local/bin/z80mbc2
 
Now we can create the new local user z80mbc2 as seen on
http://www.lug-wr.de/wiki/index.php/Howto:Network:SerialConsoleServer
 
adduser --shell /usr/local/bin/z80mbc2.sh -q z80mbc2  
If you havent done - connect your TTL-USB-Dongle to your SBC - and it should show up as /dev/ttyUSB0 :
[354660.047087] usb 7-1: Product: CP2102 USB to UART Bridge Controller [354660.047099] usb 7-1: Manufacturer: Silicon Labs [354660.047109] usb 7-1: SerialNumber: 0001 [354660.112318] usbcore: registered new interface driver usbserial_generic [354660.112414] usbserial: USB Serial support registered for generic [354660.131499] usbcore: registered new interface driver cp210x [354660.131617] usbserial: USB Serial support registered for cp210x [354660.131902] cp210x 7-1:1.0: cp210x converter detected [354660.141405] usb 7-1: cp210x converter now attached to ttyUSB0

Now its time to reboot your SBC (I used my NanoPi K1 Plus) via
reboot 
to automatically let start ser2net-service while booting
 
Now when you connect to your SBC via SSH and use the z80mbc2 User to login, you should generate a automatic and local (127.0.0.1) telnet-login to Port 2023 where /dev/ttyUSB0 a.k.a the Z80-MBC2 device is configured.
 
PS: other (german) interesting Page about ser2net:
http://www.nwlab.net/tutorials/ser2net/konsolenserver-linux.html
 

 

Z80-MBC2_SSH_Ser2Net.zip

Instead of manipulating the main device tree, enabling i2s@1c22000 should be possible via overlay as well, like:
    fragment@0 {         target-path = "/soc/i2s@1c22000";         __overlay__ {             status = "okay";         };     };  
Hence the whole overlay:
/dts-v1/; /plugin/; / {     compatible = "allwinner,sun8i-h3";     fragment@0 {         target-path = "/soc/i2s@1c22000";         __overlay__ {             status = "okay";         };     };     fragment@1 {          target-path = "/";          __overlay__ {              pcm5102a: pcm5102a {                 #sound-dai-cells = <0>;                 compatible = "ti,pcm5102a";                 pcm510x,format = "i2s";             };         };      };     fragment@2 {         target = <&i2s0>;         __overlay__ {             status = "okay";             pinctrl-0 = <&i2s0_pins>;             sound-dai = <&pcm5102a>;             pinctrl-names = "default";         };     };     fragment@3 {         target-path = "/";         __overlay__ {             sound_i2s {                 compatible = "simple-audio-card";                 simple-audio-card,name = "I2S-master";                 simple-audio-card,mclk-fs = <256>;                 simple-audio-card,format = "i2s";                 status = "okay";                 simple-audio-card,cpu {                     sound-dai = <&i2s0>;                 };                 simple-audio-card,codec {                     sound-dai = <&pcm5102a>;                 };             };         };     }; };
I will verify that the path /soc/i2s@1c22000 is correct, I guess there is a symbol for this as well, but obviously it is not <&i2s0>.

and before the
exit 0
in /etc/rc.local

Thank-you, that did the trick!

Improved testing on hardware - its attached to nightly builds and currently needs to be run manually:
 

 
connects to the device via SSH as root (ssh key must be there) runs apt update + upgrade reboots waits 3 minutes that machine is back true or false power cycle the board in case of false (where we have power control)  
Currently 38 boards are attached, but its very simple to add more of them.

Dear all,
 
First post here
 
I just wanted to thank you for the up-to-date image you made for the pcDuino4 Nano (a.k.a the NanoPI M1):
 
https://armbian.hosthatch.com/archive/nanopim1/archive/
 
It's much better than the stock image provided my LinkSprite, based upon Debian 8 "Jessie":
 
https://www.linksprite.com/pcduino4-nano/
 
I only had one issue so far with your image, certainly related to the default overclocking at 1368 MHz, which didn't play well with the CPU intensive, NEON optimized tasks I threw at it (BOINC)
 
I lowered the frequency to 1296 MHz and it's been running stable for a couple of hours now
 
So thanks again and keep up the good work !
 
Best regards,
 
Magic Sam from the Open Pandora / Dragonbox Pyra community
 
https://www.openpandora.org/
https://pyra-handheld.com/boards/pages/pyra/

Yes, that was the information what I was missing..
 
I was thinking about that, but I didn't find that information.
 
Thanks for sharing your DTB, but i'm on 5.10.60.
I froze the kernel and changed my DTB, all is fine now!
 
@guidol
 
Liebe Grüsse aus Bishkek/Kirgistan wo ich zeitweise außer in Haiger/Hessen lebe..

As I read
http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=3399
it seems to be possible.
At the URL is a information how to change the .DTB for the OPi Zero to use the USB-OTG as USB-HOST
 
You have to find the right usb-port (usb@1c19000) in the .DTB/.DTS for the OPi One
 
DTB to DTS decompile
dtc -I dtb -O dts /boot/dtb/sun8i-h3-orangepi-one.dtb -o /boot/dtb/sun8i-h3-orangepi-one.dts
 
EDIT
change in the .DTS:
change the line:
                        dr_mode = "otg";
to                     dr_mode = "host";
in the section
usb@1c19000
 
from: usb@1c19000 { compatible = "allwinner,sun8i-h3-musb"; reg = <0x1c19000 0x400>; clocks = <0x03 0x20>; resets = <0x03 0x11>; interrupts = <0x00 0x47 0x04>; interrupt-names = "mc"; phys = <0x10 0x00>; phy-names = "usb"; extcon = <0x10 0x00>; dr_mode = "otg"; status = "okay"; phandle = <0x48>; }; to: usb@1c19000 { compatible = "allwinner,sun8i-h3-musb"; reg = <0x1c19000 0x400>; clocks = <0x03 0x20>; resets = <0x03 0x11>; interrupts = <0x00 0x47 0x04>; interrupt-names = "mc"; phys = <0x10 0x00>; phy-names = "usb"; extcon = <0x10 0x00>; dr_mode = "host"; status = "okay"; phandle = <0x48>; };  
 
DTS to DTB compile
dtc -I dts -O dtb /boot/dtb/sun8i-h3-orangepi-one.dts -o /boot/dtb/sun8i-h3-orangepi-one.dtb
 
then REBOOT
 
As attachment the new compiled version (when you have the same kernel as I 5.15.4
 
@MacBreaker
PS: Liebe Gruesse nach Hessen - vor 6 Jahren habe ich in Babenhausen bei Frankfurt/Darmstadt gewohnt - nun in der Tuerkei....
sun8i-h3-orangepi-one.dtb

@NicoD
why only for the RPI4?
I commented out (like you said in the video) the 2GHz overclock out of the config.txt and booted the image on the RPI3b(+)
for a headless-server-only version (No Desktop)
 
Little problem was the /erc/rc.local where I mount my SAMBA from another pistyle-sbc, because the Network card is getting up very late.
So I had to add a "sleep 20" at the beginning of my /etc/rc.local
 
Armbian on my the RPi 3B v1.2 takes around 185MB for booting - so enough space to do something
 
Because onboard audio doesnt work I used a USB-Audio with a proper /etc/asound.conf
 
After a "dpkg-reconfigure console-setup" the RPi does copy many new/current modules again and seem to setup the system better.
 
To gain back some memory from the RPi3 I changed the GPU memory in the config.txt from 256MB to 32MB to get 950MB useable for the headless-server
 
armbianmonitor -u result at:
http://ix.io/3Fly
 
 

@NicoD
why only for the RPI4?
I commented out (like you said in the video) the 2GHz overclock out of the config.txt and booted the image on the RPI3b(+)
for a headless-server-only version (No Desktop)
 
Little problem was the /erc/rc.local where I mount my SAMBA from another pistyle-sbc, because the Network card is getting up very late.
So I had to add a "sleep 20" at the beginning of my /etc/rc.local
 
Armbian on my the RPi 3B v1.2 takes around 185MB for booting - so enough space to do something
 
Because onboard audio doesnt work I used a USB-Audio with a proper /etc/asound.conf
 
After a "dpkg-reconfigure console-setup" the RPi does copy many new/current modules again and seem to setup the system better.
 
To gain back some memory from the RPi3 I changed the GPU memory in the config.txt from 256MB to 32MB to get 950MB useable for the headless-server
 
armbianmonitor -u result at:
http://ix.io/3Fly