Pami, I have not personally found any LLM capable of generating working DTS files no matter what. It seems to be too niche for the LLM to understand. This DTS could potentially be a good starting ground for the pi, replacing "bcm2835" which refers to the pi zero 1, with "bcm2710" which refers to the pi zero 2. The github repository I linked is a good guide to getting the red displays working for a voron printer using panel-mipi driver, and I referenced it to create the DTS I use for the rock pi 4b. Also, try lowering the SPI speed to 20, 16, or 10 MHz, then raise it when you verify it works. I was frustrating myself for weeks thinking my DTS was broken, when it was fine the entire time, just my SPI speed was too high. robertoj: I appreciate your help, but I believe the issue I have with the red display (I have the same one as pami sent) is a combination of SPI commands being sent at the wrong interval (at the end of the clock cycle instead of in line), as well as insufficient SPI speed - where the display freezes above 24 MHz, and shows extreme visual tearing below it. At RGB666, its too much data for a measly 20MHz SPI rate, and the board does not support any other RGB modes in SPI. Since the TE pin is not exposed on the board, I cannot sync the SPI writes to the display. At least, that is my theory. I've given up on using an SPI display, and instead transitioned to an RGB Parallel display, which uses one gpio pin per color bit. Note that, at least in the display datasheet I received, the display actually does have the pins needed to drive it over DPI RGB Parallel. You can drive the board in 16, 18, or 24 bit mode over DPI RGB Parallel. These pins are not exposed on the board, but you could use an FPC breakout board to interface with these pins, and drive the display in DPI RGB parallel instead (accounting for the backlight voltage needed). The advantage of using RGB Parallel is it natively uses the GPU (RGB Parallel is the same technology as VGA) and has very fast refresh rate. For anyone here in future, any DPI hats that exist, like the adafruit kippah or othermod dpi topper, do not have the correct pinout to interface with this specific ili9486/8, but if you were to rearrange the pins on either the HATS or with an intermediary FPC PCB, then they would work plug and play.

Hello, i tried "Armbian_community_26.2.0-trunk.606_Radxa-cubie-a5e_trixie_edge_6.19.8_minimal.img" and wlan didn't work, i think the device tree is broken Radxa-cubie-a5e kernel 6.19.x as a quick fix, I copy the kernel 6.18.x "sun55i-a527-cubie-a5e.dtb" file to the /boot/dtb/allwinner directory to get wlan working.

@sven-ola there are 3 ways to boot the R2S: 1. Press the boot button before applying power. White USB port connected to a PC. Apply power. It goes into fastboot mode like an android. Theoretically this should let you flash the on-board eMMC. I can successfully put it in fastboot mode but the flashing has not worked. 2. Boot from eMMC 3. Boot from USB. The eMMC has two boot partitions that are fixed size and one large main partition. My project uses the u-boot environment but also does a few minor things. It prioritizes USB if it finds a bootable medium there. It also safely flashes the boot blocks on the eMMC and then the main blocks. It adds some safety checks before flashing. Nothing else.

hi, I installed in usb the last version and boot. something wrong happen here, only left these two upgrades, I tried again with backup-img and falied to boot again

Hello @lewa_j, there already is a CONFIG_POWERVR_ROGUE=y in the 6.18 kernel. This was required for Wayland and subsequently for Spacemit-GPU-Binary-Support (see https://github.com/armbian/build/pull/9515). What exactly will work additionally with this option (I am not a GPU expert)? Hello @1111Windows, doing "apt-get upgrade" on my GPU demo image this will downgrade the kernel from 6.18.18 to 6.6.99. Probably b/c recently the 6.6.99 was changed "current->legacy" and the 6.18 changed "edge->current". Also, OpiRV2 is not a really / full official Armbian image right now. So we probably need to wait until build pipelines catch up. I'll place a "apt-mark hold linux-image*" on my todo for those images. @maxsub The R2S does not have a NOR flash (or "MTD") that it boots from in the first place? That little project of yours does not look like an Armbian fork ready to be merged in. I may need some time to dig in and understand how it works. Have you considered changing the u-boot enviroment (...that can be save with "env save")?