going

Will you be able to formulate this in a detailed way and set goals more specifically?

I tested the 6.6.30 kernel without changing anything. The assembly was done locally on the main branch. I noticed that the temperature for A64 A83T is calculated incorrectly. DMESG does not report errors. Device loading is a bit weird with freezes. U-boot has not checked yet. The first step is to re-release the patches. I've already done that for the core. I'll fix the temperature and make a pull request.

I meant this line: KERNELBRANCH="tag:v6.1.69" which uniquely determines which version of the kernel patches are applied cleanly. I.e. to version 6.1.69 and not to the current 6.1.90 for today.

@Charlie Romer Hi. Let's try to figure it out. Core panic - how is this problem solved? It is assumed that you have the kernel source code. You look at the kernel messages, and then using utilities like grep you find the function in the source code. The very function that could not cope and caused panic. This appears in the kernel panic messages. The first probable reason that led to this is that a patch was incorrectly applied to a file with this function. I.e. we are looking for all patches that modified this source code file. In fact, we will need to apply all the patches in the series to the source code in the core git repository. Apply as the "git am" command. We pay special attention to those patches that change our target file. Then we extract a series of our patches from the repository using a script and place it in the target patch folder. I.e., we replace the existing series with a new one, which is applied without offsets and fuzziness. The second reason is the changes in the upstream of the kernel that led to the situation our patch has aged. In this case, we are fixing this patch. We simply make our new changes to the fixation after applying the patch in the process of applying the series step by step. The complexity of the core panic situation in the Armbian project lies in the fact that it is impossible to reproduce this particular problem. Therefore, if you did everything as I wrote and made the necessary corrections from your point of view, then assembled the kernel and the panic repeated, you simply push your changes to your repository on github and only after that you can write here on the forum or ask a question here by specifying a link to your repository and the kernel version to which corrections have been applied. Only after that, the maintainer or the interested user will be able to check it. The third possible option is that the u-boot code does not match the kernel code due to their development. We may have to monitor this loader build process as well. @Igor Did I miss something? Where did the fixed kernel version go in these settings? How is the correct application of patches controlled today?

After your image is recorded on the SD card with the dd command, during the first startup, the root partition will be stretched over all free space and you will need to configure the user, language preferences, system clock.... This process proceeds without an emergency if the device is connected to the Internet and requires access to the Linux console, for example "minicom" via UART. If the device does not have a real-time hardware clock, this will cause problems with subsequent system starts. The system service will send a request to the time server at startup and wait indefinitely for a response. This is what you need to pay attention to first.

@Igor This line may sound rude, but you are probably waiting for the developers of the source code to take some action to improve patches or kernel settings. As long as this heresy is present in the build system (bad package build scripts), the project will receive crumbs from what developers can and do locally.

The developers of Armbian have signed their own impotence with this. They cannot or do not want to add support for creating an additional package with debugging symbols. If we look at simple scripts for creating debian packages directly in the kernel source codes, we will see that the debugging package is created automatically when the configuration option is selected: CONFIG_DEBUG_INFO The only way is to change the script of the build system itself by removing these lines and adding 10 lines to the script to create a debugging package. With respect to all free software developers. Leonid.

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 ?