ALIGMSTEN Posted October 28, 2022 Posted October 28, 2022 Hi anyone else having issue with selecting specific kernel? Adding: KERNELBRANCH='tag:v5.19.16' to build/userpatches/lib.config does not switch. sudo ./compile.sh EXPERT=yes CREATE_PATCHES=yes BOARD=orangepizero2 BRANCH=edge RELEASE=bullseye BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=yes COMPRESS_OUTPUTIMAGE=sha,gpg,img CLEAN_LEVEL=make,debs,images,cache Will BRANCH=edge cause conflict? 0 Quote
Werner Posted October 28, 2022 Posted October 28, 2022 47 minutes ago, ALIGMSTEN said: KERNELBRANCH There is no such switch. https://docs.armbian.com/Developer-Guide_Build-Options/ 0 Quote
ALIGMSTEN Posted October 28, 2022 Author Posted October 28, 2022 Thanks Werner, I am not understanding the use of KERNELBRANCH? https://docs.armbian.com/Developer-Guide_User-Configurations/#user-provided-configuration Quote User provided configuration If file userpatches/lib.config exists, it will be called and can override the particular kernel and u-boot versions. It can also add additional packages to be installed, by adding to PACKAGE_LIST_ADDITIONAL. For a comprehensive list of available variables, look through lib/configuration.sh. Some examples of what you can change: PACKAGE_LIST_ADDITIONAL="$PACKAGE_LIST_ADDITIONAL python-serial python" # additional packages [[ $LINUXFAMILY == sunxi64 && $BRANCH == edge ]] && BOOTBRANCH='tag:v2017.09' # conditionally change u-boot git branch/tag KERNELBRANCH="tag:v5.4.28" #always change to this kernel tag 0 Quote
ALIGMSTEN Posted October 28, 2022 Author Posted October 28, 2022 Ok think it sunk in!! something like this then. if [[ $LINUXFAMILY == sunxi64 && $BRANCH == edge ]] && BOOTBRANCH='tag:v2022.07' # conditionally change u-boot git branch/tag KERNELBRANCH="tag:v5.19.16" #always change to this kernel tag fi 0 Quote
Werner Posted October 28, 2022 Posted October 28, 2022 Might be an undocumented switch then. However its usage is not recommended since the kernel patchset follows upstream so sooner or later applying the patchset will fail on older branches. 0 Quote
ALIGMSTEN Posted October 28, 2022 Author Posted October 28, 2022 Thanks, yes understand the logic, being lazy, armbian series that after hasn't landed in 6.0, Now require many changes to do quick test builds for h616 cpu-frequency-scaling. Have to add thermal, sid, etc instead of simple changes to nvmem in 5.19 which will speed me getting this done. Not sure when will follow and conflicts with my changes later. Current 5.15 doesn't have what need. Anyway trying to force kernel doesn't work, above is missing conditional logic anyway, but wont force when added. 0 Quote
ALIGMSTEN Posted October 28, 2022 Author Posted October 28, 2022 Thought there was a way, but seems not, LIB_TAGS are for branch only? or looks that way. Decided to change sunxi64_common.inc in my fork to get testing done. Thanks. 0 Quote
going Posted October 28, 2022 Posted October 28, 2022 12 часов назад, ALIGMSTEN сказал: Hi anyone else having issue with selecting specific kernel? For only sunxi & EDGE use the configuration file for this: cp userpatches/config-example.conf userpatches/config-test.conf echo "KERNEL_VERSION_LEVEL=5.19" >> userpatches/config-test.conf echo "KERNELSWITCHOBJ='tag=v5.19.14' >> userpatches/config-test.conf echo "EXPERT=yes" >> userpatches/config-test.conf echo "BRANCH=edge" >> userpatches/config-test.conf ./compile.sh test See more config/sources/families/include/sunxi* files 0 Quote
ALIGMSTEN Posted October 30, 2022 Author Posted October 30, 2022 Thank you @going most useful... 0 Quote
going Posted October 30, 2022 Posted October 30, 2022 28.10.2022 в 12:54, ALIGMSTEN сказал: Now require many changes to do quick test builds for h616 cpu-frequency-scaling. Have to add thermal, sid, etc instead of simple changes to nvmem in 5.19 which will speed me getting this done. I think you can help in adapting and checking the performance of patches for this processor when applying them to the 6.0 kernel. If you are ready to work a little for general prosperity, I will tell you how it can be done. 0 Quote
ALIGMSTEN Posted October 30, 2022 Author Posted October 30, 2022 (edited) Thanks @going very willing to help, please guide. My initial attempts were as you have said above previously, but not so elegant, by adding KERNEL_VERSION_LEVEL="5.19" KERNELSWITCHOBJ='tag=v5.19.16' directly to >> userpatches/config-example.conf. However gave [....] Variable tag=v5.19.16 unreachable for extraction. I am assuming it will unfortunately end similarly with your above suggestion. EDIT: This could easily be related to my fork though! Edited October 30, 2022 by ALIGMSTEN 0 Quote
going Posted October 30, 2022 Posted October 30, 2022 [ o.k. ] Checking git sources [ linux-mainline/5.19 git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.gitorigin/linux-5.19.y ] [ o.k. ] Add original git sources [ linux-mainline/5.19 origin/linux-5.19.y ] remote: Enumerating objects: 104033, done. remote: Counting objects: 100% (104033/104033), done. remote: Compressing objects: 100% (87629/87629), done. remote: Total 104033 (delta 23879), reused 35657 (delta 15536), pack-reused 0 Receiving objects: 100% (104033/104033), 233.93 MiB | 1.29 MiB/s, done. Resolving deltas: 100% (23879/23879), done. From git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable * [new branch] linux-5.19.y -> origin/linux-5.19.y * [new tag] v5.19.17 -> v5.19.17 remote: Enumerating objects: 16, done. remote: Counting objects: 100% (16/16), done. remote: Compressing objects: 100% (16/16), done. remote: Total 16 (delta 0), reused 16 (delta 0), pack-reused 0 Unpacking objects: 100% (16/16), 12.46 KiB | 135.00 KiB/s, done. * [new tag] v5.19.1 -> v5.19.1 * [new tag] v5.19.10 -> v5.19.10 * [new tag] v5.19.11 -> v5.19.11 * [new tag] v5.19.12 -> v5.19.12 * [new tag] v5.19.13 -> v5.19.13 * [new tag] v5.19.14 -> v5.19.14 * [new tag] v5.19.15 -> v5.19.15 * [new tag] v5.19.16 -> v5.19.16 * [new tag] v5.19.2 -> v5.19.2 * [new tag] v5.19.3 -> v5.19.3 * [new tag] v5.19.4 -> v5.19.4 * [new tag] v5.19.5 -> v5.19.5 * [new tag] v5.19.6 -> v5.19.6 * [new tag] v5.19.7 -> v5.19.7 * [new tag] v5.19.8 -> v5.19.8 * [new tag] v5.19.9 -> v5.19.9 remote: Enumerating objects: 23, done. remote: Counting objects: 100% (20/20), done. remote: Compressing objects: 100% (9/9), done. remote: Total 9 (delta 7), reused 2 (delta 0), pack-reused 0 Unpacking objects: 100% (9/9), 1.16 KiB | 238.00 KiB/s, done. remote: Enumerating objects: 1, done. remote: Counting objects: 100% (1/1), done. remote: Total 1 (delta 0), reused 1 (delta 0), pack-reused 0 Unpacking objects: 100% (1/1), 558 bytes | 558.00 KiB/s, done. From git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable * [new tag] v5.19 -> v5.19 Enumerating objects: 104042, done. Counting objects: 100% (104042/104042), done. Delta compression using up to 6 threads Compressing objects: 100% (79295/79295), done. Writing objects: 100% (104042/104042), done. Total 104042 (delta 23886), reused 104032 (delta 23879), pack-reused 0 [ .... ] Switch v5.19.17 = a2c155d134dde217258a3026c1e48a1519f52acd All tags are present and I can switch to any in this core. The last line says that I specified the parameter: KERNEL_VERSION_LEVEL="5.19" KERNELSWITCHOBJ="tag=v5.19.17" My configuration file for tests contains: leo@vm-jammy:~/armbian$ cat userpatches/config-test.conf # Read build script documentation https://docs.armbian.com/Developer-Guide_Build-Options/ # for detailed explanation of these options and for additional options not listed here # leave empty to select each time, set to "yes" or "no" to skip dialog prompt KERNEL_ONLY="yes" KERNEL_CONFIGURE="no" # comma-separated list of clean targets: "make" = make clean for selected kernel and u-boot, # "debs" = delete packages in "./output/debs" for current branch and family, # "alldebs" = delete all packages in "./output/debs", "images" = delete "./output/images", # "cache" = delete "./output/cache", "sources" = delete "./sources" # "oldcache" = remove old cached rootfs except for the newest 8 files CLEAN_LEVEL="make,oldcache" REPOSITORY_INSTALL="" # comma-separated list of core modules which will be installed from repository # "u-boot", "kernel", "bsp", "armbian-config", "armbian-firmware" # leave empty to build from sources or use local cache DEST_LANG="ru_RU.UTF-8" # sl_SI.UTF-8, en_US.UTF-8 # advanced # compile and install or install prebuilt additional packages EXTERNAL_NEW="compile" INSTALL_HEADERS="" # install kernel headers package LIB_TAG="master" # change to "branchname" to use any branch currently available. USE_TORRENT="no" # use torrent network for faster toolchain and cache download DOWNLOAD_MIRROR="" # set to "china" to use mirrors.tuna.tsinghua.edu.cn CARD_DEVICE="" # device name /dev/sdx of your SD card to burn directly to the card when done EXPERT=yes BOARD=bananapim64 RELEASE=jammy KERNEL_VERSION_LEVEL="5.19" KERNELSWITCHOBJ="tag=v5.19.17" #SKIP_BOOTSPLASH=yes #EXTRAWIFI=no 0 Quote
ALIGMSTEN Posted October 30, 2022 Author Posted October 30, 2022 Thanks, think corruption my end, will start afresh. 0 Quote
going Posted October 30, 2022 Posted October 30, 2022 3 часа назад, ALIGMSTEN сказал: very willing to help, please guide. I have some helper scripts. They allow me to work both from a virtual machine and on an openSUSE host. Please let me know if you have an account on github? What is the way to start the build system? I will post a script version here for the convenience of work. 0 Quote
ALIGMSTEN Posted October 30, 2022 Author Posted October 30, 2022 Clean start and switch is now functioning, thanks again. I must have forgotten about something as building has been infrequent of late. https://github.com/AGM1968 At moment for home, I use windows laptop VM to build, nonetheless will set up linux machine shortly. Generic start as above, I assume that what you mean? sudo ./compile.sh EXPERT=yes CREATE_PATCHES=yes BOARD=orangepizero2 BRANCH=edge RELEASE=bullseye BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=yes COMPRESS_OUTPUTIMAGE=sha,gpg,img CLEAN_LEVEL=make,debs,images,cache 0 Quote
going Posted November 3, 2022 Posted November 3, 2022 30.10.2022 в 19:22, ALIGMSTEN сказал: I use windows laptop VM to build That's exactly what I wanted to know. You are working inside a virtual machine and all the necessary git repositories already exist there. But they were created by the build system and their owner is the superuser. This creates some security issues. The second problem I'm trying to solve now is the impact of recent changes in the build system. These changes have rendered my helper scripts inoperable. In the near future, I hope to achieve positive results. One more question. Can you open 2-3 terminal windows inside your VM? Or maybe 2-3 ssh sessions from different terminals on the host OS? 0 Quote
ALIGMSTEN Posted November 3, 2022 Author Posted November 3, 2022 Yes I do use multiple terminals during builds, essentially for patching and checking files when patching simultaneously. I don't normally ssh a session/sessions from the host but have in the past. 0 Quote
going Posted November 5, 2022 Posted November 5, 2022 Tell git who you are: git config --global user.name "You github name" git config --global user.email "You github email" git config --global user.signingkey XXXXXXXXXXXXX XXXXXXXXXXXXX - gpg-key See more: Telling Git about your GPG key Unzip the archive to the userpatches folder. Run with the --help | -h option. This is an incomplete script, but it already allows you to work effectively with a series of fixes. It creates or updates the linux kernel git repository. He consistently applies patches using the git am command, reading the file series.name. If the patch cannot be applied, the script will try to apply it using the patch command and stop. The target repository, at the same time, is in the session state of the "am". Further actions should take place in the target repository directory. If the patch command also failed, you must manually make changes to the target file yourself. Then just add it as a git add command and continue the "am" session. Next, you need to extract the last commit using the git format-patch command and replace the faulty patch file with the one that has just been fixed. Here is a small example of how the script works: 1 session as root: root@vm-jammy:/home/leo/armbian# userpatches/patching.sh pa -kv=5.19 -kt=v5.19.17 series.megous .... INFO: [206] Apply: patches.megous/Report-HDMI-hotplug-events.patch Applying: Report HDMI hotplug events error: patch failed: drivers/gpu/drm/bridge/synopsys/dw-hdmi.c:3140 error: drivers/gpu/drm/bridge/synopsys/dw-hdmi.c: patch does not apply Patch failed at 0001 Report HDMI hotplug events hint: Use 'git am --show-current-patch=diff' to see the failed patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". INFO: [206] Attempt to apply patches.megous/Report-HDMI-hotplug-events.patch checking file drivers/gpu/drm/bridge/synopsys/dw-hdmi.c Hunk #2 FAILED at 3140. 1 out of 2 hunks FAILED flag: [1] root@vm-jammy:/home/leo/armbian# cd cache/sources/linux-mainline/5.19 cache/sources/linux-mainline/5.19# nano drivers/gpu/drm/bridge/synopsys/dw-hdmi.c Note: for info cache/sources/linux-mainline/5.19# git diff cache/sources/linux-mainline/5.19# git status cache/sources/linux-mainline/5.19# git add drivers/gpu/drm/bridge/synopsys/dw-hdmi.c cache/sources/linux-mainline/5.19# git am --continue 2 session as user: leo@vm-jammy:~/armbian$ git -C /home/leo/armbian/cache/sources/linux-mainline/5.19 format-patch -1 -o ~/armbian/patch/kernel/archive/sunxi-5.19/patches.megous/ /home/leo/armbian/patch/kernel/archive/sunxi-5.19/patches.megous/0001-Report-HDMI-hotplug-events.patch leo@vm-jammy:~/armbian$ cd patch/kernel/archive/sunxi-5.19 rm patches.megous/Report-HDMI-hotplug-events.patch mv patches.megous/0001-Report-HDMI-hotplug-events.patch patches.megous/Report-HDMI-hotplug-events.patch Run the script again. After all the patches in the series are fixed and the script applies them without errors. Make a commit in the build system itself and push the result to your repository on github. Then make a pull request. P.S. I try to write in detail so that other users can navigate better. Write all your wishes and comments here. They will be taken into account. patching.zip 0 Quote
ALIGMSTEN Posted November 6, 2022 Author Posted November 6, 2022 Appreciate you sharing your work @going. Good to see these types of discussions here, which are otherwise less visible, and found in build PR's or Issues. Very helpful to myself and others who are new to the armbian eco-system. 0 Quote
going Posted November 10, 2022 Posted November 10, 2022 Everyone who downloaded the script, please share your opinion about the script. It will eventually become part of the build system. @ALIGMSTEN will you be able to fix a couple of patches for the 5.19.17 kernel and add the patch you need for the h616 processor and make a pull request? 0 Quote
ALIGMSTEN Posted November 12, 2022 Author Posted November 12, 2022 Hi @going apologies for delayed response, I can check the patches you need for h616 soc please advise, might best as personal mail. The frequency-scaling patches are not ready, concerns raised by Thomas Kaiser have been addressed for cpu variant, operating points, with efuse, the nvmem-cells bindings need some more work, which I haven't been able to do yet. This would limit the table to 1512 MHz for variant 1, further optimisations and testing beyond myself could lead to more discussion before a PR might be made. 0 Quote
going Posted November 12, 2022 Posted November 12, 2022 Hi @ALIGMSTEN. See the mail on this site. 58 минут назад, ALIGMSTEN сказал: The frequency-scaling patches are not ready, concerns raised by Thomas Kaiser have been addressed for cpu variant, ..... I am not aware of these issues. To begin with, let's try to rework the patches that apply to the 5.19 kernel for the 6.0 kernel. 0 Quote
ALIGMSTEN Posted November 28, 2022 Author Posted November 28, 2022 A Quick Note: On behalf of @going who corrected the script when I was stuck. Those that have downloaded patching.sh there is a change required, if you have not already done so yourself. Delete a line [[ -n "$KERNEL_VERSION_LEVEL" ]] && info_pr "parametr -kv is not defined"; showhelp or fix it [[ -z "$KERNEL_VERSION_LEVEL" ]] && info_pr "parametr -kv is not defined"; showhelp 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.