going

This option can only be used when you have already done the build once. The sources in the cache folder have been updated or created. By applying this parameter, the build system should not update local sources and their state should not change. In this case, it is possible to achieve repeatability of the assembly. But this is only local. It is not possible to re-build a package that exists in a remote repository.

Ambiguity of the translation Unfortunately, it is not possible to build a specific version or, in other words, repeat the build. Let's assume that I'm building all the packages and installing them in a future image. I have made my custom changes in the kernel package and in two other packages. And I don't want these packages of mine to be updated when the OS is updated. In this case, I install a version larger than the latest version in the Armbian repository. Another case. I've put together three packages and just want to install them into an already running OS on the device. I'm doing the same thing with the version. That's what I meant.

The entry in this file is used as the package version. If you want the packages you have collected to be installed and then they are not updated to packages from the Armbian repository, then the version in your build should be higher than the current one for today. I.e. 24.5.1-trunk.

@Andrea @Jens J. Currently, the build system is not designed for the development process and does not have convenient tools for this. Alternatively, you can copy the entire kernel tree after patches have been applied and changes have been made to it in other non-traditional ways. Stopping the compilation process as soon as it has started. The build system deletes some files and replaces them by copying its own or simply copies its own files. In this copy of the tree, make a commit of the git with the addition of all unindexed files. Next, you make your changes and commit them. Extract the changes as a patch and place it in custom patches. This method avoids many time-consuming processes, but has one drawback. The process of applying patches using the python script is accompanied by dividing large patches into separate pieces and applying them separately. At the same time, some pieces can be applied with displacement and diffusion in one line. Thus, the changes end up in another function. Externally, it looks as if all the patches were applied without errors. Let's assume that you found this bug and made your own patch of fixes. But after a while, the patch author may make corrections and your custom patches will need to be redone. Thank you for your attention.

😄👍

thanks. I understand your point of view. For a clean system, you may need this key: KEEP_ORIGINAL_OS_RELEASE=yes The script that @Igor advises will add the Kali repository to the /etc/apt/sources.list.d/kali.list file. But one inaccuracy remains. You'll probably want to change that: https://github.com/armbian/build/blob/27a07d918e3e010f74dc24fcc17f510a8eb35252/lib/functions/rootfs/distro-specific.sh#L150 @Igor sid and unstable are synonyms of the same repositorysid and ustable. sid|unstable) cat <<- EOF > "${basedir}"/etc/apt/sources.list deb ${DEBIAN_MIRROR} $release main contrib non-free non-free-firmware #deb-src ${DEBIAN_MIRROR} $release main contrib non-free non-free-firmware EOF Otherwise, apt will read the same thing twice.

If you know the Kali Linux distribution well, then you can try installing Armbian and then change the sources in the /etc/apt/source.list file. Then just update the sources. Or do you need some special changes in the kernel? I am not familiar with this distribution. My questions may look strange.

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.