All Activity

Hello there, I have found another problem. My setup: T95Z plus box cpu amlogic meson(s912)arm cortex-a53 mali t820 gpu dtb used: amlogic/meson-gxm-t95z-plus.dtb everything works including WIFI. But I have overscan in the terminal and in de Cinnamon desktop I am looking for info https://docs.armbian.com/User-Guide_Advanced-Configuration/ enable a custom screen resolution whitin x.org for a resolution when i open a terminal and run xrandr --listmonitors the result is: Monitors: 1 0: +HDMI 1920x1080/90+0+0 HDMI-1 then i type cvt 1680 1050 but the next command allready result in bash:cvt: command not found Now i am stuck here any tips?

It gets problematic if it is only Windows that is available. In the past I advised people to download Knoppix and boot the PC with that so you have full control. But nowadays SecureBoot might already be a showstopper, unless you know how to deal with it. So your best Linux is probably the ROCK5 with Armbian Bookworm. You can use that to edit the Trixie SD-card. Or upgrade bookworm in-place to Trixie, I have done it more than 10 times in 2025H2, still 1 or 2 computers to go.

I don't know how to set loglevel to 7 in armbianEnv.txt 😕 On Windows after flashing the SD card, I don't have access to the files (ext4 partition probably). And on my Linux VM I'm not able to mount the SD card 😕

From the log I see: Model: Radxa ROCK 5B 272910 bytes read in 34 ms (7.7 MiB/s) I would expect Radxa ROCK 5B+ Or is it 1 DTB nowadays? The bytes read should represent the DTB file that is loaded, I use extlinux so can see what files are loaded, seems this 2025.10 build does not show this. Also be aware it first tries EFI booting, it fails as one can see, so no issue here, but I got confused on my ROCK5B (not the newer upgraded + board) because I had an NVME connectod with a working bootaa64.efi grub.cfg etc as well, so it booted something else than the image from SD-card. I was my own tuned rootfs, so was rather easy to see, but other occasion I did not notice and wasted a lot of time. For this case, what does the kernel spit out ? set loglevel to 7 in armbianEnv.txt

Try what? Do I need to guess what "the most current stable Armbian" is ? Best post an URL + sha256sum what you are doing/using. In theory, I could fairly easy merge it into booting in a KVM, it has then properly working (virtual) RTC from the host (ROCK5B or NanoPi-R6C or RPi4B), but likely needs generic Debian Trixie kernel+initrd/(DTB). That can hide potential errors with your hardware, like a dangling wire in your cable or RJ45 connector or duplicate DHCPserver in LAN or worse (criminals). Or you have ethernet time protocol working, various ethernet HW supports it, like on RPi. Or what do you use to manage your network? Recently netplan.io got pushed, that was a disaster for me, such that I banned Ubuntu now.

Thanks geoW, I look to be having some success with the 25.2.3 build I just have to see if it survives the ugrades

In general it can be done what you want. You just need to understand how Arm SBCs boot/work and Linux in general. Simply stated, it is: ROM -> bootloader -> kernel -> userspace ROM is very specific for the SoC of course, also bootloader is specific as well as the kernel. You can make a kernel that includes all various drivers and methods, like there is for x86 (works with Intel chips and AMD chips). userspace (rootfs) is normally generic, so if you take RPi bootloader+kernel and Libre userspace, it can work. I have done such things several times, but then the other way around: RPi userspace from my 5 years always in-place upgraded rootfs running on Rockchip RK3588 SBCs (Armbian bootloader and kernel). That way no lengthy and boring re-install of all sorts of debian packages and configs tuning etc. Even browser bookmarks are the same then. So very fast up and running with the new SBC. You need to know or start to study the differences in bootloader methods of course. In your case looking into the Libre script/tool would be a good start I think.

I confirm, here it is failing setting up openssh service, it starts rebooting after root autologin prompt, tested on rpi5.

As suggested by Werner, I have connected my computer to the board over UART. I have got this as output. Not sure if it helps.

From the serial_log.txt I can conclude that your SPI-flash must be empty, as it uses the u-boot version that is on the SD-card. So if you also don't have an eMMC attatched, that is now more simple. It is that older legacy based U-Boot, so should work with kernel 6.1.x. But kernellogging level is default set to 1, so I cannot see from the txt file what kernel it is, it might be older 6.1.x, I had lots of trouble with those. At least the 6.1.115 runs very solid on my ROCK3A now; it does all I/O I want: SPI, NVME, SATA (and SD-card as well but slot normally empty). This U-Boot: root@rock3a:~# strings /dev/mtdblock0 | grep "U-Boot SPL 20" U-Boot SPL 2017.09-armbian (May 20 2024 - 00:46:51) You can set loglevel to 7 in armbianEnv.txt (or directly on kernel commandline is more generic), then you see much more what is going on, it even might spit out info about crashing itself. A key thing for ROCK3A is to have proper PSU: Mine is never stable with whatever 5V only PSU, so also not the RPI5 PSU for example. Various U-Boot versions don't support USB-C PD, so I just soldered my own USB-C cable/connector that I connect to a 12V old car battery or some random 12V PSU that can do 2A or so. Then the onboard DC-DC converter is used to create a stable 5V etc. I don't remember how the ROCK3C should be powered, also not sure if it has own DC-DC converter onboard, so in that case it is just 5V and you are quite dependent on the quality of your PSU. If only an SD-card, it should be fine, but when PCIe is used fort NVME, I think expect freezes. Also think what you want with the ROCK3C; If you want a generic Arm64 Linux computer, you might be better off with 'edge' (both u-boot and kernel). You can't use quite some specific RK35xx features, but should be stable and easier to maintain. You can always compile/build an image yourself.

I'm having trouble with the raspberry omv builds. The latest build I can get working is 24.11.1 which doesn't survive an upgrades (I've tried holding the various packages that seem to cause issues which used to work but doesn't work anymore. The suggested trouble shooting on the download page doesn't work either. Currently the 25.11.1 build is stuck in a bootloop, the only irregularity I can identify is failure to load console-setup.service message. I had a working system that lost my soundcard/DAC-hat after trying to address update error messages which's what started this whole refresh process

I believe renegade uses a diff bootloader but seems logical that firmwares would be different given different hardware The Libre tool is designed to inject Renegade firmware to make a Debian system swappable between Rpis and Renegade boards. What I was ultimately hoping to do though is use Rpi builds for other distros like Alpine and inject Renegade/Firefly firmware to make those pi builds usable on a Renegade board

@Nick A do you know how to remove key ring error? [🐳|🌱] git: Fetch from remote completed, rev-parsing... [ 'debootstrap-debian-devel' 'master' 'FETCH_HEAD' ] [🐳|🌱] Debootstrap version [ '1.0.142' for /armbian/cache/sources/debootstrap-debian-devel/debootstrap ] [🐳|🌱] Installing base system with 5 packages [ Stage 1/2 ] [🐳|🔨] I: Retrieving InRelease [🐳|🔨] I: Checking Release signature [🐳|🔨] E: Release signed by unknown key (key id F8D2585B8783D481) [🐳|🔨] The specified keyring /usr/share/keyrings/debian-archive-keyring.gpg may be incorrect or out of date. [🐳|🔨] You can find the latest Debian release key at https://ftp-master.debian.org/keys.html [🐳|💥] error! [ Debootstrap first stage failed /armbian/cache/sources/debootstrap-debian-devel/debootstrap bookworm yes ]

Thanks a lot @Nick A I will give a try now. I see few more device support added on your fork https://github.com/NickAlilovic/build Can I get the change log only for IK316/H616 with LPDDR2 RAM support? I would like to sync those changes with the most recent upstream source code.

This is confusing for me. What are you actually trying to achieve? What is on Renegade that is not on Rpi?

Even just someone kicking in with yes I think it's possible but not sure how or whatever I'd been thinking to ad the armbian repo hosting firmware files but I doubt it's so simple in practice

@Jeeva Kandasamy I noticed the same problem with my older builds. Should be fixed now. You'll need to install Docker. Also, if you see the build-root errors. Run the same compile options again and it continue where you left off.

These are forums for Armbian Linux, not Android.

I'm looking for an Android 10 image but I haven't been able to find one, but I still need to do the cut to know.

What image are you trying to load?

Thanks for replying, I hadn't noticed the android thing, I have two sd cards one with the radxa android 14 and the other with the debian bullseye from radxa. I didn't mess with the SPI flash because both work correctly, does android flash the spi when booting, I don't understand how it works with the default debian but not here? I will try to maskrom mode and update. Btw here is the whole boot sequence in case it helps (I tried an older armbian build here but still the same). serial_log.txt

Did someone managed to make it work on this model below? I tried creating the image with different allwinner chips but its not booting when I burn the sd and insert on the device. The tv box is a Mortal T1 Android 13 2gb ram and 16gb rom

I am glad that you have the first 15% done: get your kernel module in the OS, and the uboot accepting the DTBO Now you are stuck in correcting the DTS, so that it configures the SPI pins correctly. My last advice for you (through this stage) is: make sure you don't have anything else using SPI pins. Deactivate "spi_dev" in armbian-config. Since I only had experience with H3 and H618 CPUs, I can't help with confidence. Post your question in the appropriate Rockchip forum section for up-to-date reliable advice. I can say that Radxa/Waveshare DTS is very out of date: it uses the fb_ili9486, which is "framebuffer" (poor fps), instead of the modern "DRM" display driver (high fps, will allow wayland). You should stay with that DTS with fb_ili9486, because it is still the closest starting point for you, and when you have it working, claiming all the GPIO pins needed, I can help again to use the DRM driver panel-mipi-dbi. Regarding MISO and MOSI, I only meant to change that nomenclature in the graphic that you show in the forum. I did't mean to change it in the DTS, if that's how other people make it work. Maybe you need to have the full linux source, so you can decompile the DTBO correctly, showing the gpio pin addresses or symbols. Is it possible that you get the Radxa/Waveshare original DTS?

@laibsch: Thanks, but your objections are worthless. You have zero sense of humor, son. @esalarm: As a Debian user since 1997 I did an aptitude purge between trying daemons. I can not make any of them set the time, as they usually do in normal Debian. There is something missing in the most current stable Armbian. I wish you would try it on an N2+. I am happy to use chrony, as I have for several years, although in this case it has no effect. But the new Debians seem to be moving to systemd for everything such as this, so I adapted. But that didn't work either. I can't be the only one; maybe the first?

Thanks @dale I'll test it out on my box first and add it later on today.