going

  • Posts

    90
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

going's Achievements

  1. I want to add to the list the topic userpatches organization #2915, which @TonyMac32 started. This is a fundamental principle and it requires attention.
  2. What I wrote is a strategy task. Given our resources, we will not be able to implement this even in six months. Look at this as a technical task that I wrote for myself.
  3. To implement this very good strategic direction, we will have to operate only with apt\apt-get tools inside the build system to install the assembled packages. We should refuse to install packages in a future image using a template search for it, for example, as here. At the initial stage, we need to create the entire infrastructure of the future local repository, for example, in the "output/local_repo" folder similar to the remote armbian repository and create it. We need to clear the folder "${DEB_STORAGE}/ " before starting the build. step one of building packages: We make a list of packages selected for subsequent assembly with the package name and version fields. step two: Let's check this list by the parameters package name and its version. If the package does not exist in the local repository, we build it. We will move all the files received after building the package to the folder " ${DEB_STORAGE}/ " step three metapackage: We will collect two or three metapackages and write down the hard dependencies package name version from the list that we received at the first step. Let's check the version of the metapackage in the local repository. If there is, add 1 and collect the metapackage. step four: We will add the packages that were built to the local repository. At the image creation stage, we add a local repository and install two or three metapackages. If the image is built successfully and it is a release, then everything collected can be added to the remote repository. And that's all. If something went wrong, we deal with the dependencies in a particular package and the process of building it. Thanks for attention.
  4. @Igor @lanefu There are two options working in this branch. For 5.12, the standard process for applying patches is. For 5.10, a series of patches is used. Both variants use the new mechanism and version numbering for the kernel and u-boot. Here I have laid out a hand tool with which I extract a series of patches. My lib.config ~/build$ cat userpatches/lib.config # KERNELSOURCE="https://github.com/megous/linux" if [ "$KERNELPATCHDIR" == "sunxi-current" ]; then KERNELSOURCE='git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git' KERNELBRANCH=tag:v5.10.37 fi Result: ~/build$ ls output/images/ Armbian_21.08.0~trunk_Orangepipc2_focal_edge_5.12.9_minimal.img Armbian_21.08.0~trunk_Orangepipc2_focal_edge_5.12.9_minimal.img.sha Armbian_21.08.0~trunk_Orangepipc2_focal_edge_5.12.9_minimal.img.txt ~/build$ ls output/debs armbian-config_21.08.0~trunk_all.deb linux-dtb-edge-sunxi64_5.12.9-21.08.0~trunk_arm64.deb armbian-firmware_21.08.0~trunk_all.deb linux-headers-edge-sunxi64_5.12.9-21.08.0~trunk_arm64.deb armbian-firmware-full_21.08.0~trunk_all.deb linux-image-edge-sunxi64_5.12.9-21.08.0~trunk_arm64.deb armbian-zsh_21.08.0~trunk_all.deb linux-libc-dev-edge-sunxi64_5.12.9-21.08.0~trunk_arm64.deb extra linux-source-edge-sunxi64_21.08.0~trunk_all.deb focal linux-u-boot-orangepipc2-edge_21.08.0~trunk_arm64.deb ~/build$ dpkg --info output/debs/linux-u-boot-orangepipc2-edge_21.08.0~trunk_arm64.deb new Debian package, version 2.0. size 287004 bytes: control archive=424 bytes. 335 байт(а), 11 строк control Package: linux-u-boot-orangepipc2-edge Version: 2021.04-armbian-21.08.0~trunk Architecture: arm64 Maintainer: Igor Pecovnik <igor.pecovnik@****l.com> Installed-Size: 1 Section: kernel Priority: optional Provides: armbian-u-boot Replaces: armbian-u-boot Conflicts: armbian-u-boot, u-boot-sunxi Description: Uboot loader 2021.04-armbian ~/build$ dpkg --info output/debs/linux-image-edge-sunxi64_5.12.9-21.08.0~trunk_arm64.deb new Debian package, version 2.0. size 28504152 bytes: control archive=72124 bytes. 483 байт(а), 13 строк control 282583 байт(а), 2821 строк md5sums 422 байт(а), 15 строк * postinst #!/bin/bash 297 байт(а), 12 строк * postrm #!/bin/bash 898 байт(а), 33 строк * preinst #!/bin/bash 295 байт(а), 12 строк * prerm #!/bin/bash Package: linux-image-edge-sunxi64 Source: linux-5.12.9-sunxi64 Version: 5.12.9-21.08.0~trunk Architecture: arm64 Maintainer: Igor Pecovnik <igor.pecovnik@****l.com> Installed-Size: 126265 Provides: armbian-edge, linux-image, linux-image-armbian Section: kernel Priority: optional Homepage: https://www.kernel.org/ Description: Linux kernel, armbian version 5.12.9-sunxi64 edge This package contains the Linux kernel, modules and corresponding other files, version: 5.12.9-sunxi64. P.S. I am waiting for healthy criticism and suggestions.
  5. I had to take a fascinating journey through Makefiles and scripts for building packages in kernel sources. In the original: After executing the mkdebian script, the debian/rules file looks like: #!$(command -v $MAKE) -f srctree ?= . build-indep: build-arch: $(MAKE) KERNELRELEASE=5.12.9-sunxi64 ARCH=arm64 KBUILD_BUILD_VERSION=trunk -f $(srctree)/Makefile build: build-arch binary-indep: binary-arch: build-arch $(MAKE) KERNELRELEASE=5.12.9-sunxi64 ARCH=arm64 KBUILD_BUILD_VERSION=trunk -f $(srctree)/Makefile intdeb-pkg clean: rm -rf debian/*tmp debian/files $(MAKE) clean binary: binary-arch This behavior causes the target to be collected at the package creation stage, if for some reason the target is considered not collected. The possible reason is the timestamp. This is a kind of insurance for a full-fledged assembly. Note the substitution of the MAKE variable. Here it's a simple call to /usr/bin/make. But, at this stage, we have already collected all the necessary goals. What could be the reason? For each kernel branch (5.4 5.10 5.12 ...) these reasons may be several and they will differ. Therefore, the simpler version of the debian/rules file turned out to be the most working one: #!/usr/bin/make -f srctree ?= . build: $(MAKE) KERNELRELEASE=5.12.9-sunxi64 ARCH=arm64 KBUILD_BUILD_VERSION=trunk -f $(srctree)/Makefile binary-arch: $(MAKE) KERNELRELEASE=5.12.9-sunxi64 ARCH=arm64 KBUILD_BUILD_VERSION=trunk -f $(srctree)/Makefile intdeb-pkg clean: rm -rf debian/*tmp debian/files $(MAKE) clean binary: binary-arch In any case, this file is very simple to be good. We need to develop it so that it can, for example, build a separate package with kernel modules that are not used on all boards. P.S. Example for hirsute debian/rules
  6. Our problem of recompiling to a single thread was in the rules file. diff --git a/packages/armbian/mkdebian b/packages/armbian/mkdebian index cfd38864c..02189b7a3 100755 --- a/packages/armbian/mkdebian +++ b/packages/armbian/mkdebian @@ -231,15 +231,11 @@ cat <<EOF > debian/rules srctree ?= . -build-indep: -build-arch: +build: \$(MAKE) KERNELRELEASE=${version} ARCH=${ARCH} \ KBUILD_BUILD_VERSION=${revision} -f \$(srctree)/Makefile -build: build-arch - -binary-indep: -binary-arch: build-arch +binary-arch: \$(MAKE) KERNELRELEASE=${version} ARCH=${ARCH} \ KBUILD_BUILD_VERSION=${revision} -f \$(srctree)/Makefile intdeb-pkg Your link came in very handy.
  7. For the sake of experiment, we will try to disable the creation of the kernel header module in the configuration for 5.12. I have run out of ideas. Tomorrow I will make the scripts easier, as in the 5.4 kernel. As just shown @Cornelius
  8. These are scripts from kernel 5.11. and they are adapted to armbian. Thanks for the link to the scripts, I saw that something needs to be checked.
  9. @Igor I did a check on a VM with the hirsute operating system. The kernel build is absolutely the same. In a clean system, only the script worked compile.sh Reassembly, when the compiler cache is full, takes 9 minutes. [ o.k. ] Runtime [ 9 min ] [ o.k. ] Repeat Build Options [ ./compile.sh BOARD=bananapim64 BRANCH=edge BUILD_MINIMAL=no BUILD_DESKTOP=no KERNEL_ONLY=yes KERNEL_CONFIGURE=no ] I watched the processes in the VM using htop. These processes go in a single thread: make KERNELRELEASE=5.12.6-sunxi64 ARCH=arm64 KBUILD_BUILD_VERSION=trunk -f ./Makefile CALL scripts/atomic/check-atomics.sh CALL scripts/checksyscalls.sh CHK include/generated/compile.h UPD include/generated/compile.h CC init/version.o AR init/built-in.a CHK kernel/kheaders_data.tar.xz GEN .version CHK include/generated/compile.h LD vmlinux.o MODPOST vmlinux.symvers MODINFO modules.builtin.modinfo GEN modules.builtin LD .tmp_vmlinux.kallsyms1 KSYMS .tmp_vmlinux.kallsyms1.S AS .tmp_vmlinux.kallsyms1.S LD .tmp_vmlinux.kallsyms2 KSYMS .tmp_vmlinux.kallsyms2.S AS .tmp_vmlinux.kallsyms2.S LD vmlinux SORTTAB vmlinux SYSMAP System.map OBJCOPY arch/arm64/boot/Image MODPOST modules-only.symvers GZIP arch/arm64/boot/Image.gz GEN Module.symvers make KERNELRELEASE=5.12.6-sunxi64 ARCH=arm64 KBUILD_BUILD_VERSION=trunk -f ./Makefile CALL scripts/atomic/check-atomics.sh CALL scripts/checksyscalls.sh CHK include/generated/compile.h CHK kernel/kheaders_data.tar.xz CHK kernel/kheaders_data.tar.xz - 6 cpus are loaded at 15-30% each. But when the linux-headers, linux-source package is created, archiving is done in multithreaded mode. 6 CPUs are 100% loaded.
  10. @Cornelius Thank you for the discussion. Today, for the 5.12 kernel, the build involves these two scripts. They are simply copied to the target directory here. I will ask you to look carefully at these two scripts. Maybe I don't see some error? These two scripts collect kernel packages normally on my local VM (focal) and on @Igor local VM. But the build on the VM that collects all the packages for armbian takes a very long time. It slows down at the end of the compilation process at the "make kernel headers as a kernel module" stage. This is not a kernel-heads package.
  11. The main problem with the linux-headers-* package is that it has a libc6-dev dependency, and it depends on the linux-libc-dev package without a version. During the installation and subsequent compilation, the distribution version "linux-libc-dev"is installed. That is, not the one that is relevant for us. I have to do it manually. on top of the already installed distribution version of "linux-libc-dev", I install my own, which I just built.
  12. Thanks. Did you mean a workable header package? I'll check it out tomorrow.
  13. linux-mainline/orange-pi-5.12$ git diff scripts/package/builddeb ... With the patch, some of the archiving processes fail with an error and this can be seen in the compilation log. Somewhere at the very end.
  14. @Igor I corrected the previous post. Now everything is in our hands. We can edit scripts right on the spot.
  15. For me, this process was a few seconds. It is installed in the configuration: I ran a test build to check it. @Igor I picked up the stopwatch. P.S. The process took 1 min 39 sec. VM 6 threads 3.4 Ghz [ o.k. ] Done building [ /home/leo/build/output/images/Armbian_21.08.0-trunk_Bananapim64_focal_edge_5.12.6_minimal.img ] [ o.k. ] Runtime [ 26 min ] [ o.k. ] Repeat Build Options [ ./compile.sh BOARD=bananapim64 BRANCH=edge RELEASE=focal BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=yes COMPRESS_OUTPUTIMAGE=sha,gpg,img ] Check the contents of the archive file: /sys/kernel/kheaders.tar.xz Just compare the sizes for 5.10 and 5.12 I don't need it. I use the linux-headers-*package. That's the reason I didn't pay attention. I'll try to figure it out. The first suspicion is that in addition to archiving, there is also a process of recompilation for the target architecture in the scripts folder in one thread.