going

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.

I'm at a loss. I have a dataset h616. And this corresponds to the DTS: sun50i-h616.dtsi#L171 Probably nothing needs to be modified. Just enable (apply standard overlay): Write an overlay file sun50i-h616-i2c0.dts: /dts-v1/; /plugin/; / { compatible = "allwinner,sun50i-h616-i2c"; fragment@0 { target-path = "/aliases"; __overlay__ { i2c0 = "/soc/i2c@5002000"; }; }; fragment@1 { target = <&i2c0>; __overlay__ { status = "okay"; }; }; }; Compile the overlay: dtc -I dts -O dtb -o sun50i-h616-i2c0.dtso sun50i-h616-i2c0.dts copy sun50i-h616-i2c0.dtso file to /boot/dtb-**-sunxi/overlay/ armbianEnv.txt: overlay_prefix=sun50i-h616 overlays=i2c0 P.S. pins = "PI6", "PI7"; 40-pin: 22, 5 number Please check it out

Will you be able to publish part of the kernel build log? The part that reports on the application of patches. We don't need this build logic path. Force the build system to always build the kernel package: ./compile.sh test ARTIFACT_IGNORE_CACHE="yes" kernel Configuration file: ~/build$ cat userpatches/config-test.conf display_alert "Common settings for Armbian OS images" "setting default values" "info" #declare -g USE_MAINLINE_GOOGLE_MIRROR="yes" declare -g SYNC_CLOCK="no" declare -g INSTALL_HEADERS="no" declare -g WIREGUARD="no" declare -g VENDOR="Armbian_community" declare -g VENDORURL="https://github.com/armbian/build" declare -g VENDORDOCS="https://docs.armbian.com" declare -g VENDORSUPPORT="https://community.armbian.com/" declare -g VENDORPRIVACY="https://duckduckgo.com/" declare -g VENDORBUGS="https://github.com/armbian/community/issues" declare -g VENDORLOGO="armbian-logo" declare -g MAINTAINERMAIL=info@armbian.com declare -g MAINTAINER="The-going" declare -g COMPRESS_OUTPUTIMAGE="sha,img,xz" declare -g IMAGE_XZ_COMPRESSION_RATIO=5 declare -g EXPERT="yes" #declare -g KERNEL_CONFIGURE=yes #declare -g DONT_BUILD_ARTIFACTS="firmware,full_firmware,fake_ubuntu_advantage_tools,armbian-config,armbian-zsh,armbian-plymouth-theme" #Upload the log file to the armbian website. #SHARE_LOG=yes #ARTIFACT_IGNORE_CACHE="yes" KERNEL_GIT=shallow RELEASE=bookworm BOARD=bananapim64 BRANCH=current BUILD_DESKTOP=no BUILD_MINIMAL=yes P.S. Edit: BOARD=XXXX BRANCH=YYYYY

That's enough. It is not necessary to collect an image. It is enough to assemble the kernel package, install it in the OS and check its performance. I'll write the instructions.

I apologize. I didn't notice the spoiler. It seems that all PI pins (7, 8, 9, 10) are already occupied?

You and I have more brains than this moron! This is the diagram of your device. Please publish the part of the DTS extracted directly from the working device: dtc --sort -I fs -O dts /sys/firmware/devicetree/base > dts-spi-out.txt Only nodes: pio, i2c0_pins And if you can find a complete pinout of the 40pin connector. We will try to make the correct overlay.

The last time these patches were changed: Date: Wed Mar 27 20:50:41 2024 Obviously, patches need to be rebased to the new kernel version and conflicts need to be fixed. If you are ready to volunteer to support these patches, I can tell you how to do it. Regards.

Before these actions, it is necessary to verify users with UID >= 1000. And in the loop for the found users, first check the existence of the home directory and if it exists, then do these actions (cp, chown).

Do I understand correctly? Are you logged in as a "benda" user? There is another user "unifi" in your OS, but he does not have a home directory? Or does the directory exist but the user "1003" has write rights? Who has "sudo" rights? UID 1003 or 1000?

Thanks for the explanation, Paolo. @Tony3 Perhaps a more accurate name of the topic (problem) could gather people here who are aware of the issue. And the answers would be more qualified.

I'm just not aware of this topic (satellite TV). @Igor @jock The changes in the published patches seem insignificant. Does it make sense to add them to the build system?

Did I understand correctly? The ultimate goal of this work was to support TBS in the kernel?

I think you need to try to do the overlay yourself. Do it by analogy with this: https://github.com/armbian/sunxi-DT-overlays/blob/master/sun8i-h3/sun8i-h3-w1-gpio.dts https://github.com/armbian/sunxi-DT-overlays/blob/master/sun50i-h5/sun50i-h5-w1-gpio.dts May be /dev/ttyS2 This can be described using aliases: sun8i-a83t-bananapi-m3.dts#L54

For reference: Extract the applied final dts from the current file system: dtc --sort -I fs -O dts /sys/firmware/devicetree/base > cur-dts-out.txt