All Activity

I am not using that distro at the moment as its not fulfilling my purpose at the moment so still evaluating. Milk v has a small core for running arduino application and then Linux and arduino can talk, this lets real time task run on small core, which is what i want. That distro is using small core for Image signal processing, which i do not want.

I have not tried to build the image myself. I wanted to flag that the file linked for download was not correctly assembled. I should have been more precise.

Unfortunately, there's no TTL data after the firmware update. RX and TX are silent.

server image, there was no activity led tried 2 decent sd cards, nothing board and activity led works with radxa bullseye os on same sd cards

I am glad that you made it work. However, it looks like you are using another Debian Distro for RiscV, not Armbian (not a bad thing) I am continuing the conversation over there

Maybe something isn't right...

We checked and it works on supported build host. We need to see logs to understand why it is failing for you.

Hi Luis, seems the main difference in the x4 is hardware AVI Video decoding, may I suggest you try the latest S905x Armbian release (main forum page) and find a suitable DTB (trial and error, start with meson-gxl-s905x-p212.dtb. If it boots on your machine, you may have everything you need. Good luck.

Hi Maurizio, do you mean that you can normally see the FAT32 BOOT partition after flashing (and then resinserting the USB adapter) with Balena Etcher in Windows, and you can no longer do that? I have that particular issue though I'm using Windows 11. The image boots fine on my server, using lsblk I see one partition, and what was the boot partition is now a folder. I can see the DTB folder on the running image, but am now only able to make changes to a running image. I'll try to flash using dd and let you know.

@Phi Hùng Nguyễn that link looks nothing like Armbian. You shouldn’t install it on your tv box. Try my build is unofficial Armbian but I provided source code. So you know what you are installing on your tv box. You can build it yourself if you want to. https://github.com/NickAlilovic/build/releases/tag/20250306

just noticed current kernel is broken. I assume because of upstream changes. looks like similar what I've fixed for meson64 6.18-rc7. Got it, will send pr Of course this does not explain why the image wasn't correctly assembled at all... Looking good: https://paste.armbian.de/ohagifufem ls -l|grep Odr -rw-rw-r-- 1 root root 142 Dec 2 05:14 Armbian-unofficial_26.02.0-trunk_Odroidc2_trixie_current_6.12.60_minimal.img.sha -rw-rw-r-- 1 root root 19751 Dec 2 05:14 Armbian-unofficial_26.02.0-trunk_Odroidc2_trixie_current_6.12.60_minimal.img.txt -rw-rw-r-- 1 root root 322026836 Dec 2 05:14 Armbian-unofficial_26.02.0-trunk_Odroidc2_trixie_current_6.12.60_minimal.img.x

Because this is not Armbian. This is a fork which uses the name Armbian without permission. We do not support 3rd party forks.

@SteeMan There is definitely something not right with current images, as the user above reported, I used Win32DiskImager to see if BalenaEtcher was the culprit. This shot is from PuppyLinux, but ext2fsd in Windows also shows RAW partitions. Naturally, W10 doesn't see anything. NOTE: the image burnt to SD Card was made in W10.

I was able to make 4 inch and 2 inch lcd work I reported the solution on github too where i was trying to solve it with someone Github link to solution For 2inch LCD module, i simply followed this link 2 inc LCD This patch in the above link was important duo-kernel-fb_st7789v.patch I was also able to make ST7796s 4inch LCD work, I kept the above patch but the init sequence for this display was different, below is the full code fb_st7796s.c /linux_5.10/drivers/staging/fbtft/fb_st7796s.c Make entry in the Makefile obj-$(CONFIG_FB_TFT_ST7796S) += fb_st7796s.o Entry in the kconfig config FB_TFT_ST7796S tristate "FB driver for the ST7789V LCD Controller" depends on FB_TFT help This enables generic framebuffer support for the Sitronix ST7796S display controller. The controller is intended for small color displays with a resolution of up to 320x240 pixels. Say Y if you have such a display that utilizes this controller. Keep modifications made by above patch for this file /linux_5.10/drivers/staging/fbtft/fbtft-core.c DTS that works for me I am having issue of the color inversion where RGB is BRG 4 inch preview 2 inch preview

Hello, sorry for my very bad english. I have a Vonstar H618 box, I can't find firmware support for it in this list https://github.com/ophub/amlogic-s9xxx-armbian/releases?ref=armbian.io I have downloaded the original firmware from the vontar homepage https://www.vontar.cn/pages/download. I hope everyone can help me install armbian on my device. Thank you very much

File (.xz) less than 1M, it extracts to 1444M, only 836k content, rest is sparse. Only U-Boot is written It looks like. So clearly image generation failed.

Does it fail to assemble image? Or you can make image but image is corrupted? For that part we have an explanation: https://docs.armbian.com/User-Guide_Getting-Started/#flash-to-sd-card

I think there is something wrong with the whole chain from 'computer-RAM down to SD-card itself'. I state it like this because there can be many points where the root-cause is. An issue like this I have seen several times before, and I think I also have had it myself, but was several years ago. /dev/sdc means you use some USB attached mmc, so even if sequential reads and writes work fine, certain pseudo random scattered small blocks can maybe hit some corner-case in the whole Linux I/O in combination with out-of-spec hardware; can be power issue internally in the SD-card adapter, anything. Also the SD-card itself might do very strange things internally, you don't know, it is some micro-controller firmware. Even if not counterfeit or just fake. Check CID and/or post here maybe. So to avoid at least USB adapter issues, I have used my RPI4 that runs from USB3-SATA SSD as SD-card reader/writer for images for for example a nanopineo. So then in the RPi4 , it is /dev/mmcblk0 you operate on. My NanoPi-R6C runs from eMMC+NVME, so also there /dev/mmcblk0 is free to use for image writing. Advantage is also that those SBC native slots do support trim, so to also internally wipe SD-card I do 'sudo blkdiscard /dev/mmcblk0' sometimes first, than all is fast and freely available. This command actually failed on some details for some SD-card brand when in ROCK3A SD-card slot for some kernel version. Also A2 SD-card and faulty queuing can randomly corrupt things.

I should have mentioned, I tried fsck on loop device and it was fine. It's what I cannot understand. In my script after writing the image I read it back and compare with the source: dd status=progress if=Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img of=/dev/sdc bs=1M conv=fsync 2032140288 bytes (2.0 GB, 1.9 GiB) copied, 79 s, 25.7 MB/s2034237440 bytes (2.0 GB, 1.9 GiB) copied, 79.2902 s, 25.7 MB/s Reading image from disk ... dd status=progress if=/dev/sdc of=Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img.from-disk bs=1M count=1941 2032140288 bytes (2.0 GB, 1.9 GiB) copied, 127 s, 16.0 MB/s They are equal in size. Produce same SHA hash: $ sha256sum Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img* ab74fc6f34f4f235ca224bc8d282feb1acf94cfe56bdf0b93c21894838ea0c71 Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img ab74fc6f34f4f235ca224bc8d282feb1acf94cfe56bdf0b93c21894838ea0c71 Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img.from-disk Tried also simple cmp on image file and SD card: $ sudo cmp Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img /dev/sdc cmp: EOF on Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img after byte 2034237440, in line 14175730 See, after byte 2034237440, so the 2034237440 bytes are equal on disk and on the SD card, .img is 2034237440 bytes of size: $ stat Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img File: Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img Size: 2034237440 Blocks: 1643993 IO Block: 131072 regular file $ sudo -fn /dev/sdc1 gives FS errors, hundreds of "Unattached inode" and such. Pass 5: Checking group summary information armbi_root: ********** WARNING: Filesystem still has errors ********** armbi_root: 64131/123136 files (0.1% non-contiguous), 441689/492539 blocks Voodoo? 😉 A spare SD card anyone to try it: 🙂

My intention is not to put the whole desktop on the display. Just a user application. I am trying to build a thermostat and might use LVGL for it. I tried a similar project on 256MB and still had plenty of RAM left.

As of 2025-12-01, current 'Armbian 25.11.1 Trixie Minimal / IOT' lists as 'Kernel: 6.12.58, Size: 505 KB, Release date: Nov 22, 2025' and seems to have had problems on image generation. Please check when possible. Thanks in advance, pbg

See https://wiki.luckfox.com/Luckfox-Lyra/Pinout and connect USB serial console cable You should see then what is going on and post that here.

At this time, panel-mipi-dbi is the most universal way of using these SPI LCDs. Even the Raspberry community gets this recommendation (except for Waveshare LCDs). Bhupiister, does the MilkV Duo S really have 512MB RAM? How do you deal with that? I have used an orange pi zero LTS with 512MB of RAM with LXDE desktop in the past, but only with lightweight GUI applications. Does it really have a useful TPU?

Making it work with panel-mipi-dbi is completely new to me. I hope ill be able to make sense out of it.

There's a 4 inch RED ili9488 in aliexpress. VERY RECOMMENDED. It may be shown as ili9486, correctly or incorrectly, but it doesn't matter. I have seen both ili9486 and ili9486 work with the same panel-mipi-dbi driver, settings and init firmware. At least in orange pi zero 3, some pins worked fine for GPIO and others didn't. Also make sure to use the default chip selects in your MilkV Duo 5, and not try to change that. Also share what Armbian and Linux version you are using.