going

The patch conversion process cannot be automated. This is a completely manual process. It requires a human eye. It requires a person's analytical thinking. And he will make mistakes because he will not be able to track changes in other files that are not affected by the patch, but which (files) affect changes in the file to which the patch is applied. I do not approve of the presence of any script automating the patch conversion process in the build system itself. This can only be as an additional utility designed exclusively for manual use. A few years ago, I wrote something similar on awk. It was a process of training and learning regular expressions and the gawk language itself. But no more than that. The script almost completely provides the capabilities of commands from the "diff-utils" package, but it does everything automatically. And what is the result? After several months of using this script, I put it on the shelf. I have transferred all sunxi patches to a series and maintain only a clean set of patches in the build system. I hope we understand each other.

Below patch is a squash of following 4 commits borrowed from ayufan's https://github.com/ayufan-rock64/linux-mainline-kernel repo: From cc22206776d61948f6984a4f03d8013eb4f92984 Mon Sep 17 00:00:00 2001 From: Pantelis Antoniou <pantelis.antoniou@konsulko.com> Date: Wed, 3 Dec 2014 13:23:28 +0200 Subject: [PATCH] OF: DT-Overlay configfs interface This is a port of Pantelis Antoniou's v3 port that makes use of the new upstreamed configfs support for binary attributes. Original commit message: Add a runtime interface to using configfs for generic device tree overlay usage. With it its possible to use device tree overlays without having to use a per-platform overlay manager. Must be: From cc22206776d61948f6984a4f03d8013eb4f92984 Mon Sep 17 00:00:00 2001 From: Pantelis Antoniou <pantelis.antoniou@konsulko.com> Date: Wed, 3 Dec 2014 13:23:28 +0200 Subject: [PATCH] OF: DT-Overlay configfs interface Below patch is a squash of following 4 commits borrowed from ayufan's https://github.com/ayufan-rock64/linux-mainline-kernel repo: This is a port of Pantelis Antoniou's v3 port that makes use of the new upstreamed configfs support for binary attributes. ......... Change-Id: I421887697d2ba6e52aba9100100b7664760e2001 --- diff --git a/Documentation/devicetree/configfs-overlays.txt b/Documentation/devicetree/configfs-overlays.txt new file mode 100644 index 0000000000000..5fa43e0643072 ..... -- 2.35.3 You don't have to edit the fix file in the editor. Instead, apply a bad patch using the patch command to the source code. Then add the modified files to track the git git add -A. And make a commit git gui. In the commit message, add all the text that you consider important. Then extract the commit using the git format-patch -1 command From 7cfb967c52d374ddcb0fc9194f38d1d5f9d8cdd8 Mon Sep 17 00:00:00 2001 From: popcornmix <popcornmix@gmail.com> Date: Sun, 3 Dec 2017 21:43:03 +0000 Subject: [PATCH] configfs: New of_overlay API From 8637321fabb045fe8617360ef1b058978b0d8457 Mon Sep 17 00:00:00 2001 From: Phil Elwell <phil@raspberrypi.org> Date: Mon, 4 Dec 2017 14:07:40 +0000 Subject: [PATCH] SQUASH: config_fs: of_overlay_apply takes a pointer Signed-off-by: Phil Elwell <phil@raspberrypi.org> From 274dfabb947ca32116a429c582c74aaee6ff1b5b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Kamil=20Trzci=C5=84ski?= <ayufan@ayufan.eu> Date: Mon, 14 May 2018 11:28:09 +0200 Subject: [PATCH] ayufan: fix overlayfs to compile on 4.17 kernel ????????????????????????????????????????????????? only: Signed-off-by: Slawomir Stepien <sst@poczta.fm> Signed-off-by: Phil Elwell <phil@raspberrypi.org> Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com> Signed-off-by: popcornmix <popcornmix@gmail.com> Signed-off-by: Kamil Trzciski <ayufan@ayufan.eu>

What will show if replaced with this code: display_alert "Free SD cache" "$(LC_ALL=C df -h "${SDCARD}" | awk '{print $5}')" "info" display_alert "Mount point" "$(LC_ALL=C df -h "${MOUNT}" | awk '{print $5}')" "info"

😄 Ricardo well done! This is an incentive for the correct design of patches. The patch should contain a description in this style. Otherwise, it may be difficult for another person to understand what has been done and for what purpose. This is also necessary so that the patch can be applied as a git am command.

Ricardo, all we need in the future is a lot of additional versioning of the commands that we use in the build system. And a message to the user if the version is lower than the required one. Linux OS can be anything if the versions of the commands meet the requirements. This will save us from a lot of discussions on the forum.

Probably this message printed once is enough. You have a good tracer. Error occurred in main shell code 1 at /mnt/data/build-armbian/armbian-next/build/lib/functions/logging/runners.sh:186 run_host_command_logged_raw() --> ./lib/functions/logging/runners.sh:186 run_host_command_logged() --> ./lib/functions/logging/runners.sh:169 aggregate_all_packages() --> ./lib/functions/configuration/aggregation.sh:59 do_main_configuration() --> ./lib/functions/configuration/main-config.sh:428 prepare_and_config_main_build_single() --> ./lib/functions/main/config-prepare.sh:93 cli_standard_build_run() --> ./lib/functions/cli/cli-build.sh:12 armbian_cli_run_command() --> ./lib/functions/cli/utils-cli.sh:126 cli_entrypoint() --> ./lib/functions/cli/entrypoint.sh:155 main() --> ./compile.sh:52

Thanks for the clarification. If you think all this information is necessary for debugging, then you can try to enter the key "VERBOSE" and set it to "0" by default. In this case, the log will contain only brief messages about the execution stage. If "1" then the values of the variables for this stage are added (not all). If "2", then the name of the execution stage function and the place from which it was called are additionally printed. And then up to the number "7". But I think this is somewhat superfluous for such a simple script as the armbian build system. This particular message is not necessary at all. # ARGs: 'BOARD=orangepi-r1' 'BRANCH=current' 'RELEASE=bullseye' 'BUILD_MINIMAL=yes' 'BUILD_DESKTOP=no' 'KERNEL_ONLY=no' 'KERNEL_CONFIGURE=no' 'CREATE_PATCHES=no' This is printed at the very beginning. That's enough. If the build was successful, 90% of this log is not needed. If I got an error, I need this error in the log. I need the name of the function and the file where the error occurred. And that's probably it.

I cleaned part of the log from the husk that prevented reading. But I didn't understand what the mistake was. I guess I'll have to do this every time I get an error and try to read the log. Is that true? What is the sacred meaning of typing the same message 2 and 3 times?

@schwar3kat A good place to discuss. Please add echo "$(git diff)" here. I am interested in whether or not new files appeared in the build system after you started it to run? @rpardini Please explain why this is in the log: .... --> 🦋 1: 2382876 - 2382876 - 2382876: ehBE: .... --> 🧽 1: 2382876 - 2382876 - 2382876: ehBE: .... --> 🧽 1: 2382876 - 2382876 - 2382876: ehBE: .... .... And what does it mean, how can I understand the meaning?

This question is for a philosophical conversation. Let's leave it hanging in the air.

For me, it's still vague. The topic requires study for me. I assume that there should be no development packages in the standard image. The fakeroot package alone is a security issue.

This image is assembled incorrectly. This error has been fixed in the build system to date. You need to uninstall the kernel header package. Then install the dependencies necessary for the build. apt-get install build-essential kmod debhelper devscripts After that, install the kernel header package again. @Igor I still have a question about why the kernel headers are installed in the standard image?

@atone The only option for changes can only be if we add an additional global variable that can be defined at the very beginning of the path, instead of having to program the value 500. For your case, 400-450 will be the optimal value. For my case, it will have a different meaning. If you make this fix, then I approve this pull request.

This is not a mistake. This is not a very good way to get around some of the providers' restrictions on the download speed for the end user. If the download speed is less than specified in the limit, then the connection breaks and an attempt is made to download from the following address. We can pre-check the speed of distribution from a specific address, but we will not be able to do a download speed check for your specific provider. For example, a provider can provide a high download speed for the first 50-100 megabytes from the download address, and then reduces the download speed to 20 kilobytes/sec. The existing algorithm in this situation allows for faster loading. The downside of this is getting error messages.

The chip operates at a voltage of 1.1V, and you have applied a voltage of 1.8V or vice versa, you have not applied enough voltage of 0.9V. You are trying to change the mode of operation of the chip and write a value to the register, but the register is mixed up and something else will change. You need to learn how to properly read the user documentation, the schematic diagram of the device. And learn how to compare the documentation and the device tree file. Sorry, the question is general - the answer is general.

If this is your device, then there is only one RAM chip on it. I find it difficult to guess anything.

If the radiator is not glued, but screwed with a screw and thermal paste. If you glued it, then don't touch it.

@sp595 UART output shows? If this is not possible for you, then publish the inscriptions on the memory chips.

It can't be called a marriage. The device board was tested before sale. The test image did not register an error and the device was sold. I have 4 RAM bars of different manufacturers on an x86 machine. All of them say that they work at 1800 Mhz, but one bar works stably only at 1600. I just set this frequency and enjoy stable operation. You can set the value of the variable "verbosity=7" in the file "/boot/armbianEnv.txt " and see what the UART output shows. When you can catch a stable value and the value of the frequency at which one memory chip fails, then write here and call me like this: @going

Very strange behavior. But unfortunately this happens. This is similar to the fact that one memory chip soldered to the device cannot work at a frequency \ mode at which the other chip works normally. A possible solution to the problem is to experimentally select the operating modes on which both chips will function normally. Try to register this in the device tree overlay file. This will only be your personal file. But unfortunately I am not an assistant in this matter.

Please roll back to kernel 5.19. Wait a few days. There will be a working 6.1 kernel. Work in progress.

Hello Alistair. leo@localhost:/1.8T/gituser/armbian-build> url="cache/sources/linux-mainline/6.1" leo@localhost:/1.8T/gituser/armbian-build> mkdir -p ~/tmp/test/patches.test leo@localhost:/1.8T/gituser/armbian-build> tdir="/home/leo/tmp/test/patches.test" leo@localhost:/1.8T/gituser/armbian-build> tools/mk_format_patch $url mego-6.1..HEAD "$tdir" LOCAL GIT URL =: [/1.8T/gituser/armbian-build/cache/sources/linux-mainline/6.1] revision range =: [mego-6.1..HEAD] target folder for patches =: [/home/leo/tmp/test/patches.test] prefix =: [] numbered =: [false] It's generate format-patch: In tmp folder: /tmp/format_patch_lD9TFyE All generated patches: [7] Good patches: [7] leo@localhost:/1.8T/gituser/armbian-build> tree /home/leo/tmp/test/ /home/leo/tmp/test/ ├── patches.test │ ├── Doc-dt-bindings-usb-add-binding-for-DWC3-controller-on-Allwinne.patch │ ├── drv-bluetooth-btrtl-Add-rtl8822cs-hci-ver-0008.patch │ ├── drv-mfd-Add-support-for-AC200.patch │ ├── drv-net-phy-Add-support-for-AC200-EPHY.patch │ ├── drv-pinctrl-pinctrl-sun50i-a64-disable_strict_mode.patch │ ├── drv-rtc-sun6i-support-RTCs-without-external-LOSCs.patch │ └── Revert-net-Remove-net-ipx.h-and-uapi-linux-ipx.h-header-files.patch └── series.test 1 directory, 8 files revision range =: [mego-6.1..HEAD] After I applied all the "megous" patches, at the top of the story I made the tag "mego-6.1". Now you can see at what stage my work is today. Specify the full, absolute paths and everything will work.

sudo apt install apt-file sudo apt-file update apt-file search /usr/bin/cvt gnustep-base-runtime: /usr/bin/cvtenc sudo: /usr/bin/cvtsudoers sudo-ldap: /usr/bin/cvtsudoers xcvt: /usr/bin/cvt apt search xcvt Sorting... Done Full Text Search... Done libxcvt-dev/jammy 0.1.1-3 amd64 VESA CVT standard timing modelines generator -- development files libxcvt0/jammy 0.1.1-3 amd64 VESA CVT standard timing modelines generator -- shared library wcslib-tools/jammy 7.7+ds-1 amd64 Command line tools utilizing wcslib xcvt/jammy 0.1.1-3 amd64 VESA CVT standard timing modelines generator