going

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

This opportunity is necessary for professionals. I have almost implemented such an opportunity to build and develop packages in a chroot environment. And this remains only in my local branch for now. First, we need to make a small adjustment in the logic of choosing goals.

What do you want to say? Stop the execution of the build system and output the command line in the chroot environment? And provide the user with the ability to enter commands, install or remove packages, fix system scripts?

https://github.com/armbian/build/pull/4515 armbian-build/cache/sources/linux-mainline/6.0> ls arch/arm/boot/dts/*nanopi* arch/arm/boot/dts/sun8i-h2-plus-nanopi-duo.dts arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts arch/arm/boot/dts/sun8i-h3-nanopi.dtsi arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts arch/arm/boot/dts/sun8i-h3-nanopi-r1.dts arch/arm/boot/dts/sun8i-h3-nanopi-duo2.dts arch/arm/boot/dts/sun8i-h3-nanopi-neo-air.dts

If you want to check the operation of the device, boot it from the memory card and check the file system on the soldered chip with the standard fsck utility. That's enough. But I think the reboot problem for bananapiM3 is related to the firmware of the controller and its interaction with the kernel. It's not related to the operating system at all. I have this device and I confirm the problem.

Developer-Guide_Build-Options EXTERNAL_NEW ( no | prebuilt | compile ) prebuilt: install extra applications from repository compile: compile extra applications in chroot Does this key work for the repository you are using?

Hi @ALIGMSTEN. See the mail on this site. 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.

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?

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

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?

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.

[ 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

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.

Thanks for the feedback. I'm working on a fix.

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

I see two ways. 1) You can turn the user's @hoov manual into a debian/rule file. Mount the already patched kernel into the build environment and assemble the kernel module. Take my branch. https://github.com/The-going/armbian-build/tree/chroot_build_pkg Use the parameter mount_linux_src=yes https://github.com/The-going/armbian-build/blob/1e9a7a1b24e5d5aead730f58ad910124782b5576/lib/chroot-buildpackages.sh#L313 Here I help the user to build a debian package in a chroot environment, bypassing many unnecessary steps. 2) I wanted to try to rework the debian rules directly from the original ubuntu repository: /gituser/ubuntu-kernel> mkdir jammy /gituser/ubuntu-kernel> cd jammy/ /gituser/ubuntu-kernel/jammy> git init /gituser/ubuntu-kernel/jammy> git remote add origin git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/jammy /gituser/ubuntu-kernel/jammy> git fetch /gituser/ubuntu-kernel/jammy> git checkout -b hwe-5.19-next origin/hwe-5.19-next I'll take that as a basis. Everything is available here. We only need to choose what we will take.