going

It usually looks like this: diff --git a/arch/arm/kernel/patch.c b/arch/arm/kernel/patch.c index e9e828b6bb30..ce0fd3aeb575 100644 --- a/arch/arm/kernel/patch.c +++ b/arch/arm/kernel/patch.c @@ -101,11 +101,18 @@ void __kprobes __patch_text_real(void *addr, unsigned int insn, bool remap) if (waddr != addr) { flush_kernel_vmap_range(waddr, twopage ? size / 2 : size); - patch_unmap(FIX_TEXT_POKE0, &flags); } flush_icache_range((uintptr_t)(addr), (uintptr_t)(addr) + size); + + /* Can only call 'patch_unmap' after flushing dcache and icache, + * because it calls 'raw_spin_unlock_irqrestore', but that may + * happen to be the very function we're currently patching + * (as it happens during the ftrace init). + */ + if (waddr != addr) + patch_unmap(FIX_TEXT_POKE0, &flags); } static int __kprobes patch_text_stop_machine(void *data) @Gunjan Gupta You might want to take a look at this.

Very good. You are our man. Why ubuntu? Just because the project is being built in this environment and it is tested. But it doesn't matter. The last stable debian, mint, will do.... Why a virtual machine? Any error in the build system itself can ruin a working system. It is easy to restore a VM from an OS snapshot. First, check the DTB. On a running device, extract from the file system: dtc --sort -I fs -O dts /sys/firmware/devicetree/base > dts-out.txt Check if there are nodes describing hdmi, dp. P.S. dmesg | grep -i hdmi

Using the documentation, install the Armbian build system on your desktop: Getting started Building Armbian I recommend installing ubuntu-22.04\24.04-server into a virtual machine (Qemu\Kvm or VirtualBox) Download the ISO image from the official website. Connect via SSH from the terminal to the OS in the virtual machine (As a regular user). Next in the terminal: sudo apt install git nano mc bash-completion git clone --depth=1 --branch=main https://github.com/armbian/build cd build ./compile.sh BRANCH=edge BOARD=rockpro64 Assemble a minimal image, write it to the SD card and check its performance. Please describe in words your level of knowledge of Linux, git and the problem you want to solve. I'm just sending English text to an automatic translator.

I can give advice, write a sequence of steps if you are ready to do the assembly yourself.

You shouldn't expect help from me for this device.

@dmitgrib As far as I understand from your messages, the package from the debian repository does not work for you. Warning: Several packages that install and modify files on flash devices, memory devices, and bootloaders do not work correctly in the Armbian OS. Just because the paths or names of the target files are different. In this package, at least two libraries require additional attention, in addition to attention to the source texts of the package itself: swupdate (2022.12+dfsg-4+deb12u1) swupdate is a Linux update agent with the goal to provide an efficient and safe way to update an embedded system. - Install on embedded media (eMMC, SD, Raw NAND, NOR and SPI-NOR flashes) - Allow delivery single image for multiple devices - Multiple interfaces for getting software 1. local storage 2. integrated web server 3. integrated REST client connector to hawkBit 4. remote server download - Software delivered as images, gzipped tarball, etc - Allow custom handlers for installing FPGA/ microcontroller firmware. - Power-Off safe ..... dep: libgpiod2 (>= 1.1) C library for interacting with Linux GPIO device - shared libraries ..... dep: libswupdate0.1 (>= 2021.04) Library for controlling the swupdate framework The best way to make a package is to repeat the steps described in the debian documentation #packaging-tutorial You can do this directly on the device. sudo nano /etc/apt/sources.list replace "# deb-src" to "deb-src" sudo apt update mkdir packaging cd packaging # not sudo: apt-get source swupdate sudo apt-get build-dep swupdate Next, we edit the source texts and assemble them as described in the documentation.

@Aleksey Vasenev The problem will be solved with this PR: # 6893

SWUpdate package - Here, please, in more detail. What is this package? Maybe I can help.

@kreestyahn Maybe start from the beginning. Disable all overlays. Download the OS. On a running OS, extract the DTS: dtc --sort -I fs -O dts /sys/firmware/devicetree/base > dts-base.txt Connect the overlay. Reboot. On a running OS, the DTS is extracted to another file. Compare.

fragment@2 { target = <&spi1>; __overlay__ { #address-cells = <1>; #size-cells = <0>; pinctrl-names = "default", "default"; pinctrl-0 = <&spi1_pins>, <&spi1_cs0_pin>; status = "okay"; And try to experience

Pins are recorded for the mmc0 node dts/allwinner/sun50i-h616.dtsi#L275 bat mmc0_pins: Add fragment0: aliases By analogy with this aliases /omit-if-no-ref/ - This line says that they are missing from your dtb Add fragment1: spi1_pins: spi1_pins: spi1-pins { pins = "PH6", "PH7", "PH8"; function = "spi1"; }; spi1_cs0_pin: spi1-cs0-pin { pins = "PH5"; function = "spi1"; }; Your fragment has now become the third. Add a description of the pins to it by analogy with this: pinctrl-names

Can you publish the connection diagram of this device. What's in the brief? First, you need to write an overlay for the DTS. Compile it and add it to /boot/dtb*/overlay, and a line to load into armbianEnv.txt the file. After that, the SD card will be automatically mounted as /dev/mmcblkXp1

Alexey, will you be able to publish the console boot log with the debug message parameter 7?

There have been changes in the 6.1.78 kernel that negatively affect arm (Cortex-A7). Try not to use kernels more than 6.1.78. I hope this will be fixed soon.

architecture - arm64 (aarch64) Chip: Rockchip RK3588 It is a core with PREEMPT technology. Your application and the kernel driver that the application uses should be running with increased priority. In order for them to be able to displace other tasks (processes) which occupy the processor core at the right time. The PREEMPT_RT patch for the kernel contains bits that allow rt tasks to do preemption. These bits must be present in the heavy (expensive) parts of the kernel code. For example, in the gpu driver (mali -lima), dma .... The hardware can provide good speed, but the drivers providing the process should be a priority and should be able to avoid conflicts over resources with other parts of the kernel. As far as I understand, did you take a ready-made, assembled core by someone? Have you run latency tests from LinuxCNC or cyclictest on this kernel? I looked at this driver: spi-rockchip.c and it uses dma in its work. The kernel from the manufacturer may contain some changes in this driver and in the dma driver. You may need to study the code carefully. And make changes yourself and build the kernel. And also configure the initial boot of the kernel (additional parameters for isolating individual processors on which your RT tasks will run). To understand the problem, I need to look into the source code of this particular kernel. Therefore, just general recommendations. It is better to get more qualified help in a specialized forum from people who have already taken steps in this direction. This is the LinuxCNC forum and the like. There are many of them. If you are just starting development, I would recommend that you pay attention to the Xenomai3 Xenomai4 and the Dovetail core. How to add the necessary bits to the SOC architecture is well described here. Very detailed documentation. And this is done by real professionals. Regards

Oh! I'm sorry, but you got on the wrong forum. What is the processor architecture? This is a very slow driver. It is intended mainly for development, to debug code or for non-speed-critical applications. But you can always write your own driver using the features of the RT kernel. Which one? A little more details and I will direct you to the right place where professionals deal with these issues.

@bedna It's possible that I'm wrong. Here the user seems to have found a problem and this is a corrupted dts for OPI-PC2: https://forum.armbian.com/topic/35635-armbian-242-is-broken-on-orange-pi-pc2/?do=findComment&comment=195299

This script assumes that there should be one user on your system with a UID >= 1000. https://github.com/armbian/build/blob/main/lib/functions/compilation/packages/armbian-zsh-deb.sh#L40-L54 In general, this is not true. If you need an administrator user without a home directory, you can create one with a UID < 1000. But in this case, zsh will not work correctly for him. Or fix the situation manually. There may be two problems here. There is no clock on the device and the OS makes a request to a remote time server at startup and if it does not receive a timestamp, then it just waits. It looks like it's stuck. 1) The external internet connection is not working. 2) You have updated the kernel package. Your OS is Debian Bullseye. Packages are collected in the ubuntu noble environment (24.04). This may have caused the Ethernet connection to break down. P.S. Try installing Ubuntu 24.04 on your device. And your 4 year updates won't create any problems.

Okay, I get it. Can we just take these few patches from the 6.6 kernel and add them to the 6.1 kernel? It is better if they are in the form in which they already exist in 6.6. I mean, what have you already tested.

Name topik: Orange Pi Zero 2W overlay I2C SPI help Write here

@Werner While I was doing something, they had already done it.

BPI-F3 Introduction For this device, we can make an image using the Source Code: BananaPi_BPI-F3#_development Let's try to add support to the Armbian build system.

Summary: kernel patching: 498 total patches; 498 applied; 81 with problems; 80 needs_rebase; 4 not_mbox This line indicates that problems exist, but is silent about what kind of problems they are. Row offset? Diffusion? Here, a separate piece can be applied to another node in the DTS or to another function in the C code. Only a person who reads the source code of the file and reads the patch file can detect the problem.

This patch in the 6.6 kernel is present after the v6.6.28 tag 998f52a860555a9f02242bc0a4b3e9b47d47dc11 I think the problem lies elsewhere.

Analysis: linux-stable> git log --pretty=oneline v6.1.87..07b37f227c8daa27e68f57b1c691fab34a06731e | wc -l 8 Maybe we will do the following: 1) Freeze the outdated kernel to version 6.1.87. diff --git a/config/sources/families/include/sunxi64_common.inc b/config/sources/families/include/sunxi64_common.inc index 18775666..e37fe516 100644 --- a/config/sources/families/include/sunxi64_common.inc +++ b/config/sources/families/include/sunxi64_common.inc @@ -25,6 +25,7 @@ case $BRANCH in legacy) declare -g KERNEL_MAJOR_MINOR="6.1" # Major and minor versions of this kernel. + declare -g KERNELBRANCH="tag:v6.1.87" ;; current) diff --git a/config/sources/families/include/sunxi_common.inc b/config/sources/families/include/sunxi_common.inc index 93b14ab8..f6261767 100644 --- a/config/sources/families/include/sunxi_common.inc +++ b/config/sources/families/include/sunxi_common.inc @@ -26,6 +26,7 @@ case $BRANCH in legacy) declare -g KERNEL_MAJOR_MINOR="6.1" # Major and minor versions of this kernel. + declare -g KERNELBRANCH="tag:v6.1.87" ;; current) 2) Переработаем (извлечём заново патчи) для этой версии ядра. 3) Leave this kernel in this state, and eliminate the cause for the current 6.6 kernel. If it is present in it.