going

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.

Hello. Are we talking about starting the OS booting from eMMC? Today I can only give some recommendations in theory. My problem is that the BPI-m3 appeared to me in 2013. I have successfully completed and completed one project on it. But I forgot how I did it. And I didn't keep all the old images. Should I lay out the theoretical foundations? Today I'm trying to figure out the new u-boot code. And make the assembly within the framework of the Armbian assembly system so that the image can be loaded from both the SD card and the eMMC.

Trying to boot from MMC2 Card did not respond to voltage select! : -110 spl: mmc init failed with error: -95 SPL: failed to boot from all boot devices The SPL must supply power for the chip to work. He doesn't seem to know where to go. Unfortunately, I don't remember how I did it in the old u-boot. I have no records left, which means that everything was very simple. But the code has changed and additional settings may be required for the default configuration. We'll have to wait a bit while I test my changes.

Yes, I confirm. U-boot does not support (not configured during compilation) booting from EMMC. Today I will fix it for Armbian and for my image. Wait a bit.

dd if=/dev/zero of=/dev/mmcblk2 bs=1M count=10; sync dd if=YYY.img of=/dev/mmcblk2 bs=1M; sync On my device, a rather old image is recorded in EMMC. I'll check tomorrow how the new one will work. One more nuance. These sections are completely empty for me: mmcblk2boot0 179:16 0 4M 1 disk mmcblk2boot1 179:24 0 4M 1 disk

Perhaps you can make changes to the DTS yourself? P.S. Fixes for this issue appeared 17 days ago. https://git.sr.ht/~tokyovigilante/linux/log/h700-audio-rewrite Maybe someone from the community can check them out? Who has these devices on h616, h618 chips.