going

Why do you want to get support for this particular Kali Linux?

The problem with displaying the actual temperature was noticed a long time ago and I fixed it in this core for the A83T processor. I did not notice any overheating problems during normal no-load operation. You just need to check if this will work for the H3 processor. You will be able to return to the 6.1 kernel in the same way if there are problems. And then just delete it using apt. Is 52 degrees the real temperature? How did you measure it? What does htop say? armbianmonitor?

@mc510 I tried to fix this situation. There are ready-made kernel packages here. Can you check it out? Just install the kernel package. The DTB package is not required.

I'm wondering how you measure the temperature? The readings of armbianmonitor and a finger touch? If the finger on the radiator feels warm, it means that the temperature is in the range of 35-45 degrees Celsius. At the same time, the readings in 26 C are false.

This question is not about Armbian and not about large SD cards. This question is about who produced this SD card and what technology, what kind of controller is there. Very well-known manufacturers (expensive ones) can release a SD card with a controller that will work well with the MSDOS partition table and the FAT, VFAT file system and will be very slow or will reduce the size with the EXT4 file system, and will not work with the GPT partition table. I have such an SD card. You can understand what you bought when you start using it.

@dhlii Thank you so much for the detailed answer. Now I see that you are a much more experienced developer than me. The H3 and H5 processors are pin-to-pin compatible. Theoretically, it is possible to solder one and solder another processor. And it should work.😁Of course it's a joke. Therefore, comparing the DTS sun50i-h5-nanopi-r1s-h5.dts and sun8i-h3-nanopi-r1.dts, I can see many identical nodes of the same name. This comparison will not be difficult for you. I wrote buildroot as an example. There are several such build systems for embedded operating systems. From my point of view, buildroot is not the most convenient to use.

I think that in the first step it is enough to compile only the kernel and install it into an existing OS. You have published a stack dump of the kernel panic. But to say something definite, I need to see this particular kernel source code.

The only way is to do the assembly yourself. First, it is necessary to check the correctness of applying patches to the kernel and u-boot.

@dhlii I wish good health to the developer of embedded Linux. It will be very interesting for me to talk to you. I have a question. Do you use specialized build systems such as buildroot in your work? The first thing to do is add the target DTS to the u-boot. You can take this as a basis: u-boot> find ./arch/arm/dts/ -name '*nanopi-r1*' ./arch/arm/dts/sun8i-h3-nanopi-r1.dts ./arch/arm/dts/sun50i-h5-nanopi-r1s-h5.dts linux-stable> find ./arch/arm/boot/dts/ -name '*nanopi*' ./arch/arm/boot/dts/allwinner/sun8i-h3-nanopi-duo2.dts ./arch/arm/boot/dts/allwinner/sun8i-h3-nanopi-m1-plus.dts ./arch/arm/boot/dts/allwinner/sun8i-h3-nanopi-m1.dts ./arch/arm/boot/dts/allwinner/sun8i-h3-nanopi-neo-air.dts ./arch/arm/boot/dts/allwinner/sun8i-h3-nanopi-neo.dts ./arch/arm/boot/dts/allwinner/sun8i-h3-nanopi-r1.dts ./arch/arm/boot/dts/allwinner/sun8i-h3-nanopi.dtsi This DTS must match the wiring of the pins of the printed circuit board and match the brands of soldered chips. The second good step is if you add the default u-boot configuration file. This will allow you to repeat the loader assembly by changing only the dts You can take this as a basis: u-boot> find ./configs/ -name '*h3*' u-boot> find ./configs/ -name '*nanopi*' Special attention is paid to the CONFIG_DRAM_CLK parameter. Even on identical boards but from different series, different memory chips can be soldered. After u-boot has done its job and it loads the dtb of the kernel and the kernel itself, we will be able to dynamically change the dtb using overlays. I.e., the DTB in u-boot is hard-coded, the DTB for the kernel we can change dynamically. P.S. Here I have described my own development process.

No way! There is no such package. There are packages with names: BRANCH = < legacy, current, edge > linux-image-${BRANCH}-sunxi, linux-headers-${BRANCH}-sunxi

Maybe so? python3 -m bCNC & Is the bCNC module visible in PYTHONPATH ?

If your SD card is working properly and the image is recorded on it correctly, then this is the reason: This image differs from the previous one in that in the uboot configuration the parameter 'CONFIG_DRAM_CLK=480'. This only means that your board needs 'CONFIG_DRAM_CLK=384' - this is what is set by default in the current Armbian images. Unfortunately, you have not published what exactly does not work. Maybe a system startup log? Maybe a set of commands that you used to switch the locale language?

There should be no problems with changing the locale. You can check this image. It contains only the English locale: Armbian_23.10_Bananapim3_bookworm_edge_6.4.16_minimal.img

For any image and for any board. First you have to see the real picture. There is no point in jumping from one image or core to another. Next, you change your dtb or make one correct dtb overlay. It is necessary to check the file '/boot/ArmbianEnv'. Nothing but your overlay should be loaded and the scp script should not be enabled. If you are not sure, just post this file here.

These settings are located in the dtb file. To change them, you will have to make an overlay file with your settings. Read the messages above.

Noctua_PWM_specifications_white_paper.pdf - The fans operate at full rated speed if there is no PWM input signal. 1) Only two wires. The fan rotates at maximum speed: Yellow +5V -> 5V -> pin2 or pin4 (40pin con.) Black - GND -> pin6 (40pin con.) 2) Three wires. The power is regulated by the internal fan circuit. It may be necessary to connect pins 1 and 2 with a 1 kohm resistor. Yellow +5V -> 5V -> pin2 or pin4 (40pin con.) Black - GND -> pin6 (40pin con.) Blue PWM Signal -> => to right contact (2): 3) Two wires. The power is regulated by the internal OPI5-plus circuit: Everything that is drawn here you use at your own risk. There are no guarantees. I do not know the internal circuit of the fan.

If you use this fan and want to connect to the 40-pin connector. @greg396 Read this discussion. It's well written here. 5V+4+pin+PWM+Noctua+A4X10+on+Raspberry+Pi P.S. My previous recommendation is not suitable for this fan.

In this case, the TRIM will be continuous and implemented directly by the kernel. P.S. More info: Solid_state_drive I don't have anything to add to this article.

This is a key importance for me and for you. Perhaps some hints exist in man fstrim On my SSD, which is 50% full, the slowdown is observed after about 2 months. I just run the command in this case and wait (do nothing). This repeats itself when I start to observe a slowdown. To be honest, I do not know of any other tool for this functionality than dmesg messages when mounting a file system.

Working with loop devices in BASH is similar to opening a file for reading and closing it after completing the operation in the C language. In the build system, there is a code that remembers the open loop device and there is a code that should delete\close the loop device. But for some reason this does not happen. May it be necessary to wait for the operation to complete? The problem is in the build system. Perhaps the new kernel is faster?

Maybe we should first discuss what is driving your desire in this direction? What is the ultimate goal?

Okay, let's move on. When I mount an ext4 FS, sudo mount -v -o rw,noatime,nodiratime,discard,errors=remount-ro,commit=600 /dev/sdf1 /mnt dmesg reports: [28422.686388] EXT4-fs (sdf1): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none. [28422.717550] EXT4-fs (sdf1): mounted filesystem with ordered data mode. Opts: errors=remount-ro. Quota mode: none. [28612.985794] EXT4-fs (sdf1): mounting with "discard" option, but the device does not support discard [28612.985800] EXT4-fs (sdf1): mounted filesystem with ordered data mode. Opts: discard,errors=remount-ro,commit=600. Quota mode: none. When I mount an btrfs FS, sudo mount -o rw,relatime,ssd,space_cache,subvolid=5,subvol=/ /dev/sdf /mnt dmesg reports: [35708.200591] BTRFS: device label test-btrfs devid 1 transid 5 /dev/sdf scanned by mkfs.btrfs (24307) [35708.283831] BTRFS info (device sdf): disk space caching is enabled [35708.283837] BTRFS info (device sdf): has skinny extents [35708.283839] BTRFS info (device sdf): flagging fs with big metadata feature [35708.286642] BTRFS info (device sdf): checking UUID tree [36135.461701] BTRFS info (device sdf): disk space caching is enabled [36135.461706] BTRFS info (device sdf): has skinny extents [36268.307315] BTRFS info (device sdf): enabling ssd optimizations [36268.307322] BTRFS info (device sdf): disk space caching is enabled [36268.307324] BTRFS info (device sdf): has skinny extents EXT4 reports that there is no trim support. BTRFS informs you that everything is included. Perhaps I am mistaken and this is the presence/absence of support in the kernel drivers. I have two more devices, adapters for SATA. One is directly soldered to the BPI-M3. The other is an external PCIe-SATA. I'll check them later.

partprobe /dev/loop2 Error: Partition(s) 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16,........ ........... This is the result of incorrect processing of operations with the loop device in the assembly system itself. Some versions of Linux kernels have a delay with these operations, and the BASH script continues without waiting for the operation to complete. As a result, we see a lot of open loop devices. @Igor Are further explanations required?

I need time to think. P.S. Test: OS openSUSE 15.4, desktop computer SATA3 <-> SSD_SATA3 sudo fstrim -v / good work USB2.0 <-> USB2-SATA_adaptor <->SSD_SATA3 fstrim: /mnt: the discard operation is not supported USB2.0 <-> USB3-SATA_adaptor <->SSD_SATA3 fstrim: /mnt: the discard operation is not supported USB3.0 <-> USB3-SATA_adaptor <->SSD_SATA3 fstrim: /mnt: the discard operation is not supported > sudo mount -v -o rw,noatime,nodiratime,discard,errors=remount-ro,commit=600 /dev/sdf1 /mnt > sudo mount | grep /mnt /dev/sdf1 on /mnt type ext4 (rw,noatime,nodiratime,discard,errors=remount-ro,commit=600) > sudo fstrim -v /mnt fstrim: /mnt: the discard operation is not supported I think it's some kind of hardware limitation. You have a newer generation USB3-SATA3 adapter and it supports the function when connected to a USB3 port. Mine is not. Armbian has nothing to do with this. @Crossplatform Vlad I intentionally ran the test on my work computer, not on a banana.

uname -r ? Have you updated the kernel on this distribution? @Crossplatform Vlad My recommendations: Make a new installation of the distribution based on ubuntu 22.04. The build system works on this version. Why is that? Do you need further explanations?