going

The header package has been unpacked and I assume that the target directory has remained in place. Only compilation failed. Please check it out: cd /usr/src/linux-headers-6.1.15-sunxi/ find include/ -name elf.h find arch/ -name elf.h Please tell me, for what purpose do you use kernel headers? This is my simple curiosity.

Very strange. Dependencies are spelled out. This means that the packages needed to build the headers are installed. Today, @rpardini Ricardo is in charge of building kernel packages. Maybe he can clarify the situation here on the forum. Or you can open a discussion of the issue directly on github.

If I understand correctly, kernel headers have already been installed in your OS. Try installing only one library: sudo apt install libelf-dev And then install the headers again.

@IgorS I can't comment on that. Let's try to figure out what you got with the collected packages. Please publish what the team will print: dpkg --info linux-headers-current-sunxi_6.1.15-S4261-D4dc8-Pd2ed-C54bbHfe66-Bd6b8_armhf.deb

sudo apt install libelf-dev The full set of tools will be installed by dependencies for these three packages when they are installed. build-essential kmod debhelper devscripts

void

Thanks for the explanation! The problem is in point 1) We have to fill in the working directory of the future package in one way or another (extract the git state, apply patches, etc.). We have to form files in the debian directory. Then only the "make" command works. All scripts for building debian packages are a kind of wrapper for this command. The version should be formed at this stage and in the manner recommended in the debian documentation. How to make the correct update when downgrading the version from the point of view of apt, it is written in the debian documentation. No brainstorming is needed for this.

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

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.