going

I will vote with both hands for us to adhere to this policy.

This detailed article description requires reflection. This is a very good way. The initial extraction will be difficult, but in the following years it will allow us to avoid a lot of work. But the problem is hidden somewhere else. I don't see much difference in the way we came to the state in the working directory of the kernel. In what order we applied the patches. One way or another. The algorithm will miss for some reason. It will fly past the target. This needs to be sorted out. I'll say more. Some patches do not change the values of variables in the Makefile, but add changes that will eventually add a local version. That is, in the process of the make command. For example, the PREEMPT_RT patch (one of the five known to me) or the user can add a local version during kernel configuration..

Today I am engaged in putting the code in order with the assignment of the kernel version for the master branch. After the code is stabilized, I will post it in my repository. Ricardo will be able to independently apply this logic to his code in the main branch

The problem has arisen here and now at this moment in time. And it must be solved here and now. It exists for the "main" branch. It exists in my branch. And it's the same thing. A small difference in details will not play any role. I am against going back to the old version system. It creates more problems than it allows you to do with minimal actions. We have to do everything at once and now. To begin with, let's list the currently existing repositories. I see only one armbian repository. And an empty preferences.d directory. You should make a new repository named jammy-staging for packages with a downgraded version of packages and configure repository priorities in preferences.d/80-armbian-staging.pref. cat <<- 'EOF' > "${basedir}"/etc/apt/preferences.d/80-armbian-staging.pref Package: * Pin: release n=jammy-staging Pin-Priority: 1001 EOF cat <<- EOF >> "${basedir}"/etc/apt/sources.list.d/armbian.list deb [signed-by=/usr/share/keyrings/armbian.gpg] http://apt.armbian.com jammy-staging main EOF You may want to choose a different priority policy, for example, only for certain packages. Read also man apt_preferences

@Igor Repository settings occur in this function. rootfs/apt-sources.sh But it could be a package named armbian-update-${variant}.deb In this package, we can configure repository priorities and prescribe specific dependencies. But before that, the packages must be assembled correctly.

And what do we have now? Updating for the end user from the armbian repository with a downgrade of the package version is solved very simply at the level of the repository itself. A description of how to do this exists in the debian documentation. This version is in the Makefile before patches are applied. This version is after applying patches. The package must contain an up-to-date one. The problem is that I can't see where a miss occurs in the script. I can't do anything to help. Therefore, I just advise you.

5.4.234 - Makefile There is only one way to change this. Change the function itself. Somewhere here it is necessary to redefine the artifact_version variable. It is important to understand that you are on your own in this. I can only give "harmful" advice.

But you apply a lot of patches that change the kernel version in the Makefile. If I can judge by this code, the bicycle has been invented here again. Please show the output of the command for the assembled package: dpkg --info output/debs/linux-image-*.deb

Do you build the kernel yourself and update it? Did I understand correctly? And do you want your versions to run up?

5.4.228 - The upstream kernel source code version. And that's right. S3043-De511-P0a53-C0750H6842-Bb436 - It looks like some kind of hash. @rpardini Ricardo, what information can I extract from this? For example, a user reports some kind of error in the kernel and sends me a package file. I see this information. Can I reproduce the build of this particular kernel to understand the cause of the error?

@belegdol Are you interested in how to do this in your local assembly? Or is it a problem with updates, when a new kernel with a lower version should be updated by apt to the old kernel from the armbian repository but with a higher version? I want to understand the essence of the problem in a broader sense. And information for everyone. I am continuing to develop the master branch. At home locally. And knowing, understanding what the user wants is very important for all of us.

@lissizza It seems to me that I have reviewed all the links on the Internet, but I have not found any information about the chip with the letters that you published. Can we try to get information from the other side? For example, show what is written directly on the printed circuit board: the name of the device and its version. For example, I have: Orange PI PC v1.1 And please give me a link to download the schematic diagram for the version of this device.

Please check the correct operation usb_modeswitch