going

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

This is a common Linux issue and we usually do not provide assistance. But you have interested me in this fact. If I understood correctly, then the same SSD drive connected via the SATA connector - trim mode is possible, and connected via a USB-SATA adapter - trim mode is impossible? Publish the DMESG output of the line where the USB-SATA adapter is defined. I have a lot of these things. I'll check it out.

Absolute agreement. And this is part of the user's research. A millivoltmeter and knowledge of the measuring point is something that cannot be programmed and provided.

datasheet: [ LPDDR3 ] * VDD1 = 1.8V (1.7V to 1.95V) * VDD2, VDDCA and VDDQ = 1.2V (1.14V to 1.30) * HSUL_12 interface (High Speed Unterminated Logic 1.2V datasheet; e·MMC consists of NAND flash and a MMC controller. 3V supply voltage is required for the NAND area (VDDF) whereas 1.8V or 3V dual supply voltage (VDD) is supported for the MMC controller. Maximum MMC interface frequency of 200MHz and maximum bus widths of 8 bit are supported MMC I/F Clock Frequency : 0 ~ 200MHz MMC I/F Boot Frequency : 0 ~ 52MHz Temperature : Operation(-25C ~ 85C), Storage without operation (-40C ~ 85C) Power : Interface power → VDD (1.70V ~ 1.95V or 2.7V ~ 3.6V), Memory power → VDDF (2.7V ~ 3.6V)

Individual settings for the memory chip such as timings, power supply voltage in the uboot bootloader can solve some problems. Maybe we can compare what is soldered on our boards? @Tu Hu @dd5xl @AaronNGray My board: Bpi-M3 v1.1 ___________ AXP813 ___________ RTL8211E _______________ SUMSUNG 319 KLM8G1GEAC-B001 _______________ SKhynix H9CCNNNBJTML ARNUM 521A UTMBA023HA _______________

Do these images work for your BPI? Is there an internet connection when you launch them? When you run your BPI on your current image without going online, is there normal operation?