going

This feature is not available at the stage of image assembly using the Armbian assembly system. Why? I don't know. P.S. The Armbian build system does not build and distribute source packages. Only binary packages are collected and provided. Why? I don't know.

Congratulations. We will be watching, but the first comment is already available.

Orange Pi 4 -> SOC rk3399 -> The driver for the bus on this SOC drivers/i2c/busses/i2c-rk3x.c Documentation/i2c Check the status of this driver in the kernel on a running OS: grep -n I2C_RK3X /boot/config* There are nine i2c controllers on this SOC and they are described in this file. As far as I can tell from the rk3399-orangepi.dts file, the first five controllers (i2c0-i2c4) are already occupied (in use). Is your temperature sensor unique? Why do you want to write a unique driver for it? In any case, you must enable (activate) a free bus controller, for example i2c7 or i2c8 in the dts file for the temperature sensor driver used. In the Armbian OS, you can do this using an overlay. examples for allwinner SOC. overlay for rockchip64 With respect

I'm using atomic OS updates on my work computer right now. And this is what is provided to me by default by the openSUSE General Purpose Operating System. I'm asking myself a question. And what does the Armbian OS have to do with it? Armbian is a general purpose OS. It is not an embedded OS in the classical sense of the term. Embedded OS, for example, is what you have built using buildroot or Yocto. In this case, you may need these tools as rauc or swupdate. Apt does not violate anything. They violate improperly assembled packages that it installs. You will probably have to control this process yourself. In other words, to assemble some packages yourself and before sending them to your own repository, test them in practice locally in your laboratory. To use atomic updates of multiple packages, you can use the BTRFS snapshot mechanism, for example. In any case, you need to look for help on specialized forums of system administrators. With respect

Thanks for the feedback. Everything else is not an Armbian problem. LLVM is not used when building Armbian images.

@rockmusic64 You can attract the user's attention in two ways: 1) Start typing the username with the @ prefix and click on the suggested option 2) User's quote Unfortunately, I have never used this functionality. Please describe what you want to connect in this mode. I have two devices (OPI-4B rk3399b chip, BPI-f3 k1 chip) with a USB-Type-C connector. How can I physically verify the correctness of the operation when the code is added to the kernel? We learn from each other.

You are looking at the master branch. We need an orange-pi-6.9 branch. See: https://megous.com/git/linux/tree/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts?h=orange-pi-6.9#n729 But simply adding this node will not bring results. A set of patches from this rk3399-typec-6.9 branch is needed and there may be something else. Use the instructions to get the necessary README Look at the contents\history (git log -p megi/rk3399-typec-6.9) of the received branches. Special attention is paid to: megi/tcpm-6.9 megi/typec-extcon-6.9 megi/rk3399-typec-6.9 megi/fusb302-6.9

A little theory: The listener is sitting in the 10th row in the center of the hall. An orchestra is playing music on stage. In the left ear, the sound from the instruments located on the left will be more intense than from the instruments located on the right. The sound from the instruments located on the right will be shifted in phase in the left ear relative to the sound entering the right ear. This is stereo sound from the front. The sound travels through the entire hall and is reflected from the walls and ceiling. It also enters the left and right ears of lower intensity and with a different phase shift. This is a quadro effect. In practice, when recording an audio track, the sound of individual instruments is recorded into separate audio tracks and then mixed using special equipment and recorded into two parallel audio tracks. This is stereo sound from the front. The difference lies in how we listen to the recorded track. If these are simple stereo headphones, then additional mixers allow us to create the effect of presence in the hall. This is a pseudo quadro effect. If you use a good sound card and it has 4 or more outputs and you listen to music through speakers located around the perimeter of the room, then with the help of mixers you can achieve almost the full effect of presence in the concert hall. With respect.

This is not required. First you need to understand what is going on.

Oh. It seems you just don't see anything that's going on? In this case, you need to connect the UART for debugging. _________________ FTDI232 BPI Board | _________________ | | 3.3v |_____ ____ UART GND o|---------------|o GND o| | || | | Linux TX o|---------------|o RX o| | USB|| |====USB cable===| console RX o|---------------|o TX o |____||____| | "minicom" _________________| |________5v______| At the first start of the OS, Armbian tries to get a timestamp from a remote server in order to set the clock to the current time. If she doesn't get it, she waits and kind of freezes. In other words, the download process is not completed and you don't see anything. You will also not be able to connect via ssh, since the user has not yet been installed in the system. Try to configure the router so that it distributes IP addresses via DHCP. With respect

There is a 99.99% chance that our email will be ignored. Our core is not vanilla. Our compiler belongs to ubuntu, which means that we have to write there. But even there we will be ignored, because we are not using ubuntu core. With respect

@mikhailai Thanks for this detailed study of the problem. After you posted about this issue, I did the following. Just the reverse of the specified commit: sunxi-6.1: Revert: handle entropy from atomic process context Your changes are here today. But I do not know who to write the author. That's why I indicated your account on the forum. PR: #6945

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?