going

😁👍

Can you post your changes here as "git diff" or "git format-patch -1"

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.

Yes. I'm hinting at the same thing. We need to make some additional packages. But the build system lacks a simple or general mechanism for assembling/reassembling debian packages.

The same problem. And I still can't find a place in the source code where it can be fixed.

[ 0.000000] Linux version 6.6.73-current-spacemit (build@armbian) (riscv64-linux-gnu-gcc (Ubuntu 13.2.0-23ubuntu4) 13.2.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #1 SMP PREEMPT_DYNAMIC Tue Jan 21 12:19:25 UTC 2025 [ 0.000000] Machine model: BananaPi BPI-F3 [ 0.000000] SBI specification v1.0 detected [ 0.000000] SBI implementation ID=0x1 Version=0x10003 [ 0.000000] SBI IPI extension detected [ 0.000000] SBI RFENCE extension detected Maybe Patrick @c0rnelius can shed some light on this issue? It's still in development. Please join the development. Code source: https://gitee.com/bianbu-linux Today, only the following has been added to the build system: (spacemit.conf) opensbi, u-boot-spacemit, linux-bianbu But this is not enough for full-fledged work. Welcome!

You can also compare the dts after all the patches have been applied in my branch. sunxi-6.6-rebase If you find that something does not match the circuit board and you can fix it, then you can post the fixes (git forat-patch -1) directly here or make a pull request on the github.

The h5 <-> h3 processors are pin-to-pin compatible. That is, you can solder h3 and solder h5 to this place. After modifying the DTS file for the board, you can make it work. That's the theory. In your case, the difference is probably in the PCB layout. gpio = <0x15 0x01 0x09 0x00>; gpio = <0x42 0x00 0x02 0x00>; You'll have to find some kind of workaround.

But dtb may have differences. I mean the one that was used on a working device. Extract for both cases and compare. dtc --sort -I fs -O dts /sys/firmware/devicetree/base > dts-out.txt Maybe this will give you a clue.

@asayed I have been using QEMU KVM + Virtual Machine Manager for over 10 years. Just install the official ubuntu 22.04 server image in the VM and clone the armbian repository inside the VM. With respect. P.S. This allows you to quickly roll back to the snapshot in case of a crash and not ruin your running OS on host. It is necessary to have 45-50 GB of free space inside the VM before the first start.

Perhaps nothing needs to be soldered. Try to purchase a 4 amp power supply with a detachable power cable. For example: Power supply <-> USB-microUSB cable <-> Board.

1500 mm - It's a long cable. The Council. Shorten the cable and solder a new connector. The connectors are sold disassembled in specialty stores. The connector on the board itself may also be loose or the soldering location may be oxidized (poor contact). It can also be replaced (solder a new one). Maybe it will serve you for a few more years.

micro USB is a fairly delicate connector. He might get loose. The power supply circuit on most of these development boards is implemented in a fairly simple way and any additional load can lead to a decrease in the supply voltage in individual circuits. The variation of the actual resistance value from the nominal value in the resistors can lead to both an increase in voltage and a decrease. This leads to the fact that my NVME is working, but it is very hot (increased supply voltage) or, in your case, a malfunction (low supply voltage). This can be cured if you pick up a soldering iron. But for this you need to be well versed in circuit design and have experience in such work. I have encountered such problems when connecting HDD, SSD, NVME via USB-SATA adapter. But never with an SD card. Will you be able to publish the brand of the equipment so that other users can read about this issue?

Maybe so: sudo chroot /mnt/ or sudo chroot /mnt/bin/bash or cd /mnt sudo chroot ./bin/bash

First, you need to mount your memory device in the /mnt folder. ls -l /mnt/bin/bash

My x86_64 work machine has openSUSE OS installed. I use QEMU KVM and Virtualbox Manager. I'm just installing an ubuntu server from the official website in this VM. The disk size for a VM is 55-60 GB. And already in this ubuntu VM, I'm cloning the armbian repository. In case of a VM malfunction, it is easy to restore it from a snapshot.

Download the device from the SD card. Mount the eMMC in /mnt. Post what is there: ls -al /mnt/boot ls -al /mnt/usr/lib/modules

Please let the community know which core your device is running on.

I think we need to remember this and publish it in the documentation in the section HOW TO KILL\DESTROY THE DEVICE CORRECTLY.

Did you download the device from the SD card? Is your broken space located on eMMC? If so, you will need to mount your eMMC. sudo mount /dev/mmcblk*** /mnt sudo mount --bind /proc /mnt/proc sudo mount --bind /sys /mnt/sys sudo mount --bind /dev /mnt/dev sudo mount --bind /dev/pts /mnt/dev/pts sudo chroot /mnt apt update; apt install linux-image-current-meson64 linux-dtb-current-meson64 exit sudo umount /mnt/dev/pts sudo umount /mnt/dev sudo umount /mnt/sys sudo umount /mnt/proc

You can fix this using fsck. The errors will go away for a while. But with active I/O, they will return. This indicates that the SD card is very close to the end of its life cycle.

I've watched it. It looks like the OS has fallen asleep when the user is not doing anything. What kind of power supply is it now? And what is connected to the board besides the mouse and keyboard?

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?

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

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