All Activity

Hi there, Some other solution that I have not been able to make "permanent" yet. Thanks @FredK@Josua-SR and @Igor for allowing me to have some fun building U-Boot once more (have not built a U-Boot since i think 2006!), it for sure did bring back some good memories 🙂 Unfortunately the built U-Boot (with SDHCI_SDMA disabled) did not solve my issue. Then i decided to revert back to the previous release (*-6.6.87-current-mvebu => *-6.6.43-current-mvebu) by moving the symlinks in /boot around, which at least allowed the kernel and some userspace to boot. But due to lacking kernel modules (the 6.6.43 were removed during upgrade to 6.6.87) the box itself did not really work. After some inspection, based on the remarks from @Josua-SR about memory corruption, i decided to check if this might not be just a simple overlapping issue with the images, e.g. kernel image partially occupying where the initrd is loaded. Kernel image Size Size (hex) vmlinuz-6.6.43-current-mvebu 7170736 0x6d6ab0 vmlinuz-6.6.87-current-mvebu 8858728 0x872c68 Loading of files is done as follows: fdt (dtb) 0x2040000 (0x840000 max size) ramdisk (uInit) 0x2880000 kernel (vmlinuz) 0x2080000 (0x7fffff max size) You can already spot that the kernel image will not fit into the area that U-Boot has designated for it: 0x872c68 > 0x7fffff. whereas the 6.6.43 kernel should fit fine: 0x6d6ab0 < 0x7fffff. Some testing showed that when setting ramdisk_addr_r to a higher value - which should fit the bigger kernel image - things started to boot again: => setenv ramdisk_addr_r 2980000 => boot switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 2996 bytes read in 210 ms (13.7 KiB/s) ## Executing script at 03000000 Boot script loaded from mmc 176 bytes read in 201 ms (0 Bytes/s) 28834 bytes read in 424 ms (66.4 KiB/s) 11504908 bytes read in 2562 ms (4.3 MiB/s) 8858728 bytes read in 2218 ms (3.8 MiB/s) ## Loading init Ramdisk from Legacy Image at 02980000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 11504844 Bytes = 11 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 02040000 Booting using the fdt blob at 0x2040000 Loading Ramdisk to 0f507000, end 0ffffccc ... OK reserving fdt memory region: addr=2040000 size=6d000 Loading Device Tree to 0f497000, end 0f506fff ... OK Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0 Next is to try and figure out how I could change ramdisk_addr_r (the initial spot where U-Boot wants to load the ramdisk into), as I prefer not to have to type this at the U-Boot prompt every single time i reboot the box. Hope this helps someone out there with similar issue. Groetjes,

I’m wondering if it’s your ram settings. If you extract your original android dts. You might find it there.

A new problem( Which desktop environment to choose? Xfce is freezing on login screen, cinnamon do not work at all. Any additional helpful settings on compile time? Or classical runtime debug only?) The most strange thing that I have almost the same box(will take a board photo tomorrow) that do not have either first problem, not current.

Hello Igor, thanks for your reply and the advice about the armbian-bsp* package. It worked! 👍 I tried it out and finally managed to update all previously withheld packages and get rid of the error messages, but it was still kind of bumpy... I had to take these steps: 1. dpkg -r the armbian-bsp-cli-rpi4b-current because apt remove would not work and produce errors 2. apt --fix-broken install 3. dpkg -i --force-all /var/cache/apt/archives/armbian-bsp-cli-rpi4b-current_25.2.3_arm64.deb as apt install would not work without errors and dpkg would not work without forcing it. The error message was something about armbian-bsp* trying to overwrite a file that had been created by raspi-firmware (or something like that. Unfortunately, I did not copy the exact message) Now, everything seems up to date, including the RPi firmware (which had been quite old in the pre-built image, now it's up to date). BTW: in my previous post I wrote that OMV is running on an RPi4B, in fact that was a typo, it is an RPI3B+ really, so the firmware is not in an EEPROM, but only in a couple files in the /boot/firmware folder. Thanks again. I'm curious if it will stay stable or if future updates will cause trouble again at some point. 🙂 🙃

Thank you, I was trying to dig out old instructions but have used these now and successfully booted noble current. I keep getting random mac addresses on reboot though. I have reserve ip on my router for the actual mac. Apart from messing around with netplan is there a smarter way to fix the mac address?

Nice find I don't know why those changes happen... but we as bleeding edge linux users, must be aware of those things (by searching in the armbian forum... or sometimes in the raspberry forum)

This is around 10 years old (!) demo / beta image that was deprecated cca. 8-9 years ago. If automated builds doesn't work (we can't cover for endless software support for endless ultra-cheap hardware), IMO your best (only) way is digging into https://docs.armbian.com/Developer-Guide_Build-Preparation/ and fixing reasons which are preventing latest kernel / boot loader to work. It might be trivial, it might be hard. Probably nobody knows without research. This will help you http://debug.armbian.de/

Thank you very much!!!

Maybe you find a working one in oldarchive: https://fi.mirror.armbian.de/oldarchive/orangepiplus2e/archive/

Maybe related https://github.com/armbian/build/pull/8087

Thanks, but this image is one of the tested ones, and doesn't work. Thank you anyway!!!"

WiFi is missing in "Armbian_25.5.0-trunk.428_Rpi4b_trixie_current_6.12.22_minimal.img" Solved by following commands ``` sudo apt update sudo apt install firmware-brcm80211 --fix-broken sudo reboot ```

moved https://www.armbian.com/orange-pi-plus-2e/

Same here ... I've had two Cubietrucks running like a charm for years with regular updates up to v24.x.x. Since the upgrade to v25.x.x I noticed at some stage that the system was running including SSH but consolewise I had lost control over it due to the fact that both my USB keyboard and HDMI display were dead. Definitely no hardware problem though, I checked on that. So I was wondering if others have witnessed the same issues on more recent Armbian builds for the Cubietruck and if there's an "easy" way for getting back HDMI and USB-keyboard functionality through SSH access.

I have an Orange Pi Plus 2 that has worked with Android installed for a long time. But now I needed to install Linux on it. I needed to find a Linux image to install on it, and I've already got several, but all the ones that worked, and that were on the login screen, didn't go beyond that, since in none of the 4 USB ports the keyboard worked and I imagine the mouse. I read somewhere that the image Armbian_5.38_Orangepiplus_Ubuntu_xenial_default_3.4.113_desktop.7z or Armbian_5.20_Orangepiplus_Debian_jessie_3.4.112_desktop.7z, but I don't know where to get it, hoping to solve all the problems. Can someone give a helping hand, please?

As of today, NVK is a conformant Vulkan 1.4 implementation for NVIDIA Maxwell, Pascal, and Volta GPUs, and will be enabled by default starting with Mesa 25.1. View the full article

Yes you were right it found those sha files when I tried yesterday! I didn't even realize I was trying that close to the release. Build has worked! Thank you!

Update the version of U-boot used with Radxa rock 4 se to v2025.04. Tested locally on my board after building an armbian image. ubuntu@rock-4se:~$ strings /dev/mmcblk1 | grep U-Boot U-Boot SPL 2025.04-armbian-2025.04-S3482-P4a0b-H3d34-Va9af-Bb703-R448a (Apr 22 2025 - 10:05:17 +0000) U-Boot phase U-Boot FIT image for U-Boot with bl31 (TF-A) Description Update the version of U-boot used with Radxa rock 4 se. GitHub issue reference: Jira reference number [AR-9999] How Has This Been Tested? Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration. [x] Image built using armbian/build [x] Flashed and booted the system using latest version (v2025.04) of U-boot on a rock 4 se board. Checklist: Please delete options that are not relevant. [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] My changes generate no new warnings View the full article

I'm unable to make an RTC module to work: RTC module ds3231, BPI M2Z and ARMBIAN Bookworm i2c pins 3 and 5 Driver RTC-ds1307 loaded, because RTC-ds3231 is not available. Why do I need a RTC-module? Often in the field I'm not online but I do need the right time on my observation camera's. My application does not allow me for having a monitor. My system does the recordings by motion detection, and the recordings do need the right time on it. armbian-config i2c0 set Tools installed: apt install python3-smbus i2c-tools i2cdetect -y 0 Detects address 068 and not UU as proof of driver been loaded File "hwclock-set" adapted #if [ -e /run/systemd/system ] ; then # exit 0 #fi Fake hwclock removed sudo apt -y remove fake-hwclock sudo update-rc.d -f fake-hwclock remove armbianEnv.txt overlay and dtoverlay correctly set modules.conf added: rtc-ds1307 Still, after a power down, the hardware clock shows 1970 as the date The same module tested on my RPi Zero 2W, and all is working perfect. If somebody can help me, that would be wonderful.

This should be fixed, but there might be an error with firmware package. Fix is uninstalling armbian-bsp*, updating all packages, installing bsp againg.

Struggling with repo management for past few days. It would be nice to write it from scratch, but time is an issue

The build is working, thank you so much!

Ok, this morning apt-get upgrade tells me that there is armbian-config to update. Done and now solved the overlay issue also on my old image Thanks

Hi. geeks So i've installed v25.05.0 armbian bookworm 6.1.21 on my tv box and so far no bluetooth and wifi My chipset is Cdtech 47w3155. rfkill gives nothing. just blank space