going

@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

Save the overlay file to sun8i-a83t-uart2.dts name. Compile the overlay: dtc -I dts -O dtb -o sun8i-a83t-uart2.dtbo sun8i-a83t-uart2.dts copy sun8i-a83t-uart2.dtbo file to /boot/dtb-**-sunxi/overlay/ Add to /boot/armbianEnv.txt file line: overlays=uart2 after the line overlay_prefix=sun8i-a83t sudo nano /boot/armbianEnv.txt

In this file for UART2: allwinner/sun8i-a83t.dtsi ... /omit-if-no-ref/ uart2_pb_pins: uart2-pb-pins { pins = "PB0", "PB1"; function = "uart2"; }; }; ... uart2: serial@1c28800 { compatible = "snps,dw-apb-uart"; reg = <0x01c28800 0x400>; interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>; reg-shift = <2>; reg-io-width = <4>; clocks = <&ccu CLK_BUS_UART2>; resets = <&ccu RST_BUS_UART2>; status = "disabled"; }; By analogy with uart0 here: dts/allwinner/sun8i-a83t-bananapi-m3.dts#L383 you can write an additional node: &uart2 { pinctrl-names = "default"; pinctrl-0 = <&uart2_pb_pins>; status = "okay"; }; But it will work if you build the DTB directly when compiling the kernel. Because without adding this node, the contact description node for uart2 will be omitted. That is, it is not in the standard DTB. You can write an overlay in which you need to specify both nodes: /dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-a83t"; fragment@0 { target-path = "/aliases"; __overlay__ { serial2 = "/soc/serial@1c28800"; }; }; fragment@1 { target = <&pio>; __overlay__ { uart2_pb_pins: uart2-pb-pins { pins = "PB0", "PB1"; function = "uart2"; }; }; }; fragment@2 { target = <&uart2>; __overlay__ { pinctrl-names = "default"; pinctrl-0 = <&uart2_pb_pins>; status = "okay"; }; }; }; Regards

For Armbian, long-term support is what is here: https://kernel.org/ The kernel is named "current" and it is always the largest version. Today it is 6.6. You can wait or you can do it yourself. The infrastructure is present.

The kernel compilation script contains "brute force" code that does: --> (46) COMMAND: ./scripts/config --enable EXPERT --> (46) COMMAND: ./scripts/config --enable CONFIG_MODULE_COMPRESS_NONE --> (46) COMMAND: ./scripts/config --set-str CONFIG_LOCALVERSION "" --> (46) COMMAND: ./scripts/config --enable CONFIG_IKCONFIG --> (46) COMMAND: ./scripts/config --enable CONFIG_IKCONFIG_PROC --> (46) COMMAND: ./scripts/config --enable CONFIG_GPIO_SYSFS Using your configuration file may not work correctly due to the above. First, compare it with the default configuration file.

Your new configuration has been exported: (119) INFO: Exporting new kernel config [ /home/eric/BuildKernel/build/output/config/linux-rk35xx-vendor.config ] The first step is to compare it with the old default cd /home/eric/BuildKernel/build/ diff -u config/kernel/linux-rk35xx-vendor.config output/config/linux-rk35xx-vendor.config Did that tell you something? Mutual dependencies in Kconfig may be inaccurate. MODPOST Module.symvers ERROR: modpost: module usb_f_uvc uses symbol dma_buf_attach from namespace DMA_BUF, but does not import it. ERROR: modpost: module usb_f_uvc uses symbol dma_buf_map_attachment from namespace DMA_BUF, but does not import it. ERROR: modpost: module usb_f_uvc uses symbol dma_buf_unmap_attachment from namespace DMA_BUF, but does not import it. ERROR: modpost: module usb_f_uvc uses symbol dma_buf_detach from namespace DMA_BUF, but does not import it. ERROR: modpost: "dma_contiguous_default_area" [drivers/media/common/videobuf2/videobuf2-cma-sg.ko] undefined! ERROR: modpost: "cma_release" [drivers/media/common/videobuf2/videobuf2-cma-sg.ko] undefined! ERROR: modpost: "cma_alloc" [drivers/media/common/videobuf2/videobuf2-cma-sg.ko] undefined! make[2]: *** [scripts/Makefile.modpost:126: Module.symvers] Error 1 I suspect that this driver cannot be built as a module because it does not export the necessary symbols. But in the Kconfig file, the ability to put the letter M is present. Unfortunately, this is a common mistake of programmers. You will have to fix the kernel code if you really want to build the driver as a module or leave everything as it is.

All Armbian images require the user to have an internet connection. Before the first start, your device must be connected to the router using a cable and the router must distribute IP addresses via DHCP. Almost all devices do not have a watch with a battery. Therefore, after the kernel boot stage, the OS service tries to configure the system clock by sending a request to the NTP server. If there is no response, then the system waits for it and kind of stops. The user sees a blank screen. This line says that the system turned out to be in the past. [ 6.026051] systemd[1]: System time before build time, advancing clock. At the same time, it cannot properly process the file system that is in the future. Possible solutions to the problem: 1) Purchase a watch with a battery and connect it to the 40 pin connector. Add a dtbo overlay file for this type of watch. Set the system clock to the current time. 2) Connect the device to a local network in which there is another device with a watch with a battery. Configure and run an NTP server on this device. On a device without a watch, specify the NTP address on the local network.

The whole problem lies in the "configure u-boot correctly" plane.