going

Do you need an Armbian image for you? Did you take this from Ubuntu? 8 часов назад, Smartyn34 сказал: in dtb file, I now have: i2c2_ph_pins: i2c2-ph-pins { pins = "PH4","PH5"; function = "i2c2"; }; i2c@1c2b400 { compatible = "allwinner,sun8i-a83t-i2c\0allwinner,sun6i> reg = <0x1c2b400 0x400>; interrupts = <0x00 0x07 0x04>; clocks = <0x02 0x34>; resets = <0x02 0x27>; pinctrl-names = "default"; pinctrl-0 = <&i2c2_ph_pins>; status = "okay"; #address-cells = <0x01>; #size-cells = <0x00>; };

Two things are needed for this to work. The driver is in the kernel. UDEV rules for switching usb modeswitch. Reboot as a command on the command line or from a button? One inattentive developer made changes to the build system, but did not check other development lines and this made the uboot package broken for the record. This is fixed.

uboot I fixed in my branch. Fixed it in the sense that if you assemble the image then it will load. DTB for uboot or for kernel? Does dtb work for kernel? @sgjava I can probably make some changes to the dts, but I won't be able to check them. I don't have this device and this fact makes it very difficult. You can just check for EDGE to get the CLI image: ./compile.sh BUILD_ONLY="default" BUILD_MINIMAL=yes Before starting the build system, please clear the "output/debs/*" folder. In my branch, the directory structure for future package files will be slightly different.

If you're interested, I'm just continuing to develop this master branch here.

I'm sorry, @sgjava are you still doing this?

@yamah Thanks for the investigation.

I found where it can be found. please show me: igor@honeypot:/usr/src/linux-headers-6.1.15-sunxi$ find ./ -name special.h

I have just collected kernel packages in my sandbox, on the master branch. And installed them on a clean system. After installing the unsatisfied dependencies, the process of installing and compiling the kernel headers was successful. For the new version of the kernel build process, something is clearly wrong. The compilation process cannot find the headers. I can assume that not all dependencies are registered. Unfortunately, I can't help in this matter. I do not know who this one is special.h

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?