going

This patch is not complete. A solution already seems to exist in this discussion. I will add these changes to this PR#7705 tomorrow.

Maybe you can describe the problem/goal that you want to solve using RT Core. First you need to figure out what is required. There are several real-time Cores. And each solves its own problems.

I understood. Thank you.

[ 9.527925] videodev: Linux video capture interface: v2.00 [ 9.539551] panfrost 1800000.gpu: clock rate = 432000000 [ 9.539593] panfrost 1800000.gpu: bus_clock rate = 200000000 [ 9.540215] panfrost 1800000.gpu: mali-g31 id 0x7093 major 0x0 minor 0x0 status 0x0 [ 9.540250] panfrost 1800000.gpu: features: 00000000,000027f7, issues: 00000000,00000400 [ 9.540262] panfrost 1800000.gpu: Features: L2:0x07100206 Shader:0x00000000 Tiler:0x00000209 Mem:0x1 MMU:0x00002821 AS:0xff JS:0x7 [ 9.540274] panfrost 1800000.gpu: shader_present=0x1 l2_present=0x1 [ 9.544584] [drm] Initialized panfrost 1.2.0 for 1800000.gpu on minor 1 Thank you for the information provided! A simple clarification. Does it work on an h616 processor with the patch disabled? For the h618 processor, I was unable to get the GPU to work with or without this patch. It remains to be seen whether this patch plays a positive role for the h6 processor. If there is no positive effect, then I'd better turn it off.

Is the GPU node enabled for your board?

Try to set the disabled status for the GPU node. or temporarily disable this patch: patch/kernel/archive/sunxi-6.12/series.conf#L472

The kernel has a driver for i2s: sound/soc/sunxi/sun4i-i2s.c It works for the h6 processor. Try adding the line compatible = "allwinner,sun50i-h6-i2s" to the DTS node so that the driver can be called. This driver may also work for the h618.

Probably there should be a driver for this device in the kernel. For 6.12.16: linux-sf> grep -nr 'compatible = "maxim,max9' drivers/media/* drivers/staging/media/* drivers/media/i2c/max9286.c:1666: { .compatible = "maxim,max9286" }, drivers/media/i2c/max96714.c:1006: { .compatible = "maxim,max96714f" }, drivers/media/i2c/max96717.c:1085: { .compatible = "maxim,max96717f" }, drivers/staging/media/max96712/max96712.c:465: { .compatible = "maxim,max96712" },

I think he won't give much information in this situation. I have these two boards (OPI-5, OPI-5-plus). They both arrived with a pre-installed loader in SPI-Flash. The loading order on both boards is the same. BootRom searches for the boot code on SPI-flash and downloads it. In other words. If u-boot v2019 is written to the SPI-flash and the bootloader v2025.01 is written to the SD card, I will see the v2019 message in the UART console. Maybe the documentation will give you a hint? This is part of the wiring diagram.

I still recommend restoring the original circuit.

OPI-5, OPI-5-plus - The connection scheme of the SPI flash memory chip is similar. I did an experiment with OP-5-plus. On a running OS, I erased all mtd-flash using the dd if=/dev/zero of=/dev/mtd command. The device turned into a brick. Downloading from an SD card or NVME has become impossible. Recovery: I downloaded this archive from the official orangepi website: MiniLoader - what is needed for burning Linux images-20241230T170815Z-001.zip The device is in MaskRom mode and the MaskRom button is not pressed. MiniLoader> ls -al итого 6136 drwxr-xr-x 2 leo users 208 янв 1 20:33 . drwxr-xr-x 4 leo users 45 дек 31 16:30 .. -rw-r--r-- 1 leo users 448960 янв 1 1980 MiniLoaderAll.bin -rw-r--r-- 1 leo users 1249 янв 1 1980 rk3588_linux_emmc.cfg -rw-r--r-- 1 leo users 1859 янв 1 1980 rk3588_linux_pcie.cfg -rw-r--r-- 1 leo users 1249 янв 1 1980 rk3588_linux_spiflash.cfg -rw-r--r-- 1 leo users 1249 янв 1 1980 rk3588_linux_tfcard.cfg -rw-r--r-- 1 leo users 4194304 янв 1 1980 rkspi_loader.img -rw-r--r-- 1 leo users 1620480 янв 1 18:53 u-boot-rockchip-spi.bin rkdeveloptool db MiniLoaderAll.bin If your device switches to MaskRom mode on its own and the command returns an error at this stage, the MaskRom button may be defective (it is always pressed). This is an assumption. In my case, I had to press a button, then turn on the power and release the button. Nothing is connected to the device. There is no SD card. There is no HDMI cable. There is no UART. Only the power cable and the USB cable to the PC. Boot_option It is not possible to boot this device if the mtd chip is clean. In my case, I wrote the entire u-boot v2025.01 code to mtd. I built it myself in the Armbian build system without any additional patches. Today, my device loads any image (OS) from all the memory devices I have. Well good luck. With respect to you as a person who knows how to operate a soldering iron.

Help: Rkdeveloptool Rockusb rk3588_spl_loader_v1.15.113.bin as miniloader I assume that you have a computer with Linux OS installed. The rkdeveloptool utility is installed or built. Connect your device to this computer using a USB cable. Press the Maskrom button and hold it down to turn on the power on the device. In the next step, you should download the mini loader to your device using the rkdeveloptool utility. rkdeveloptool db rkxx_loader_vx.xx.bin Now the device should come to life and should respond to requests and perform some actions. If you have pre-downloaded and unpacked the u-boot armbian binary package for your device (extract the bootloader file from the package), you can do the following: Just in case, run the clear command. Write the armbian bootloader to the memory chip. For tips on the offset, see the u-boot package script.

https://stpete-mirror.armbian.com/ (St. Petersburg) This mirror works well in the Russian Federation. But how do I make sure that this mirror is automatically selected in the build system itself at the image creation stage? I mean the phase of installing packages in a future image. ... [🔨] Err:5 http://mirror.hostiko.network/armbian bookworm InRelease ... [🔨] Err:5 http://fastmirror.pp.ua/armbian bookworm InRelease ...

leo@bananapim64:~$ sudo nano /etc/apt/sources.list.d/armbian.list http://apt.armbian.com =>> https://stpete-mirror.armbian.com/apt leo@bananapim64:~$ cat /etc/apt/sources.list.d/armbian.list deb [signed-by=/usr/share/keyrings/armbian.gpg] https://stpete-mirror.armbian.com/apt bookworm main bookworm-utils bookworm-desktop leo@bananapim64:~$ sudo apt update Сущ:1 http://deb.debian.org/debian bookworm InRelease Сущ:2 http://security.debian.org bookworm-security InRelease Сущ:3 http://deb.debian.org/debian bookworm-updates InRelease Сущ:4 http://deb.debian.org/debian bookworm-backports InRelease Сущ:5 https://github.armbian.com/configng stable InRelease Пол:6 https://stpete-mirror.armbian.com/apt bookworm InRelease [53,3 kB] Пол:7 https://stpete-mirror.armbian.com/apt bookworm/main all Packages [17,5 kB] Пол:8 https://stpete-mirror.armbian.com/apt bookworm/bookworm-utils arm64 Packages [37,4 kB] Пол:9 https://stpete-mirror.armbian.com/apt bookworm/bookworm-desktop all Packages [7 526 B] Пол:10 https://stpete-mirror.armbian.com/apt bookworm/main arm64 Packages [1 168 kB] Пол:11 https://stpete-mirror.armbian.com/apt bookworm/bookworm-desktop arm64 Packages [15,9 kB] Пол:12 https://stpete-mirror.armbian.com/apt bookworm/bookworm-utils all Packages [3 965 B] Получено 1 304 kB за 9с (149 kB/s) Чтение списков пакетов… Готово Построение дерева зависимостей… Готово Чтение информации о состоянии… Готово Может быть обновлено 4 пакета. Запустите «apt list --upgradable» для их показа.

Yesterday, at my test stand, I discovered a malfunction on the banana pi M64. The behavior is exactly the same as that of your board. I found the reason quickly. These were oxidized/weakened contacts on the power supply. When the board starts, the consumption is low. But then all the regulators are turned on, and when the OS starts setting up, consumption increases dramatically. In that place of bad contact, a voltage drop occurs and the board turns off. Soldering iron + screwdriver solved the problem. My power supply is open and I have access to it.