going

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

I do not promise a quick result. Thanks for the dts file. Very timely, I am currently fixing it for the 6.2 kernel. Unfortunately, I am not an advisor on displays and their resolutions. I work with headless devices. Wait, someone will help.

And can you see 2GB of memory? Just attach this file to your message

Maybe the android version will work. I only need a dtb blob from the working version. These chips, according to the data that I found, can work with a voltage of a little more or less. The question is the exact figure. If we have any working image. I'll pull the information out of it and assemble a working kernel for you.

@lissizza Which image is currently running on your device. Why am I asking? Whether some other was downloaded, for example from the manufacturer's website or another Armbian edition.

Different series of the same chip. It is sad. I'll think about what can be done.

These inscriptions on this chip? Do I understand correctly?

I sincerely wish you gentlemen good luck.

I think the best option is to take a fresh image for your device

Here I just want to change the core. I think it's clear what needs to be done.

In order to disable the patch, it is enough to put a minus sign at the beginning of the line with this patch in the "series.conf" file. These patches exist, but they don't apply.

It has no functionality for processor frequency @ALIGMSTEN Alistair, can you add patches that you have running on the 5.19 kernel for the 6.1 kernel?

htop --version on bullseye ?