All Activity

Hello. I have an old "Ott Amlogic S805 rlt8188 (wifi) 1GB/8GB" so Android 4.4.2 is fully outdated (It is no longer supported by Google, so it is unusable.) Is there an Armbian release that can be installed on "this fossil" 🙂 ?

You can add APA to your system and as one of the benefits get a managed GPG key so you should not run into this issue again in the future.

Armbian 25.8.1 Noble XFCE (mainline Kernel: 6.16.6-edge-rockchip64) + PanVk - mesa 23.0 (https://launchpad.net/~ernstp/+archive/ubuntu/mesaaco) + box64 3.7 (https://ryanfortner.github.io/box64-debs/) + wine-10.15-staging-tkg-ntsync-amd64-wow64 (https://github.com/Kron4ek/Wine-Builds/releases/tag/10.15) + DXVK-stripped v2.7.1 ~60fps@720p Hades

Hello @Ian Coelho, have you ever got any solution? I got the same issue

As long as you keep the discussion about this at their place... ophub is (ab)using the name Armbian without permission and they do not contribute to the core development process. Rather they trick users into thinking they get support here and therefore (ab)using our resources.

zero2w != zero2 moved

Hi All First post here. Have been using Rpi Zero 2W for a couple of years in various installations and other then speed been happy with it. So got an Orange Pi Zero 2 W in an attempt to use it as a plug in replacement for the Rpi. Installed Armbian and other than a booting issue, it all works. The first obstacle is the i2c, it is obvious that is nowhere near as easy as a Rpi to set up. I have read many posts and get more confused as the days go on. So, the question: Is there a step by step instruction on how to enable I2C. I am connecting 2 x ADS1115 A2D converters, one at &H48 and the 2nd at &H49. When I use i2cdetect -l i2c-0 i2c DesignWare HDMI i2c-1 i2c mv64xxx_i2c Adapter i2c-2 i2c ditto When I use i2cdetect -y 0 &h30 and &h50 show up When I use i2cdetect -y 1 I get UU on &h36 In software, I can do a fd = i2c_open("/dev/i2c-0") or use i2c-1 rc = i2cselect (fd,&h48,0) BUT, I cannot write or read to the device.(obviously because it does not exist according to i2cdetect ) My armbianEnv.txt has overlays=i2c3 changed from i2c0 after reading some posts. dtparam i2c_arm=on In armbian-config /system/kernel/booto001/ I have ticked i2c0-pi and for 2 and 3 as well. So after all that I have no idea how to proceed. Regards

I have the tinkerboard rk3288, where do I find the mpv-legacy

Yeah, I wasn't asking for diagnostics, I realise that this issue could be for a myriad of reasons, just I was sure (before) that it was hardware related, now I'm not so sure. FWIW, it has just happened again less than an hour after boot, so I'm going to pull the card and chroot in to analyse. (I'm a software developer, so am well aware of the 'it don't go, what's wrong?' approach to tech support 😉) Interestingly, I was still logged in on an ssh shell, and I realised there was an issue when it was telling me that `cat` was an unknown command (clearly not!). I logged out, and now got the dreaded "Connection reset by 192.168.1.44 port 22". I also ran a full badblocks pass (4 real passes) on the SD card prior to imaging just to 100% make sure the card is fine. My main concern is that it will not have flushed logs to disk after the issue, so I suspect I will find nothing. ____ Edit: It looks like Armbian has rsync on a schedule to hold logs in RAM and perhaps periodically copy back to HDD. so unfortunately I have no useful info here. Going to look into the Armbian docs and see if I can get it to log directly to disk whilst I test. ______________ Another edit: I managed to disable ramlog, but unfortunately nothing of note has been written to the log files. I have tried connecting a monitor via HDMI, but am getting no output. I am sure this is fixable, but not sure how much I'm prepared to fiddle around with a box that just wants to lock up after some undetermined amount of time. I'm going to install the official Ubuntu 18.04 image (urrrgh) and leave it running for a long while. If that displays the same symptoms, then I can safely say this board is e-waste. If it does not, then I will come back to it and try to get myself an output.

@torz77 Without logs and diagnostic information it's hard to tell what is going on because what you're saying is the equivalent of "it doesn't work" Nonetheless I had the same symptoms when my SDcard was dying (bad sectors here and there). The kernel and network layer was loaded in to memory OK, so pings would work, but ssh calls upon extra binaries and files from the SD card and I was getting I/O errors, hence would result in SSH dying which is the connection refused the client sees. I had to connect mine to a display for the duration of a diagnostic session but thankfully it was easily reproducible so the error glared out. A replacement SD card got me there.

I wonder if that is related to the issue I've been having. Not long after I posted my last message, I hit an issue where the Odroid would stop allowing me to SSH in (connection refused) but would still respond to pings. I tried with many different SD Cards (and USB Hard disks) and the issue would not go away. Could happen after a few hours or a week or so. In the end I just took the device out of service, as I assumed that it was just dying. My Odroid is headless, so can't connect to console to see any potential error messages. I can't remember how far I dug into logs, but I am sure I must have. I have now re-imaged it again, with latest Armbian Stable on Trixie, and will monitor it for further issues. I still suspect the device is dying, but your message has given me hope that it is not. I would be interested to know if anyone else is experiencing similar symptoms. v25.11 rolling for Odroid C1 running Armbian Linux 6.12.47-current-meson Packages: Debian stable (trixie) Support: DIY (custom image)

@Rodrigo Campos @kazekami_him I think @nitrolack and @afiftyp had the same Transpeed M98-8k board. It booted fine with my transpeed image. (other than wifi) They didn't have a board that had secure boot. Check if your board is the same. Maybe you could try my older images. It could be the newer u-boot and patches broke the ram detection? Maybe your board is using a different ram?

Hi and Thank @jock That's what I thought. I used ledconf-3 because that's the configuration you made specifically for my MX10 box. I ran a memtest, which went smoothly. The system is working, and I was able to compile rockchip mpp without any problems. The system is running Bookworm. Would it be better to update to Trixie or revert to a previous version? What do you think? I think the problem comes either from rk3318-box.dtb or from the overlays. Thanks again. 🤜🤛

Hi @kazekami_him, Thanks for your information, but I have no idea in how to use this content for test it. Maybe @Nick A Could understand what this guy did and how to bring it to his port and help us to detect the correct ram amount.

@jock well thanks but I already figured that part out 😊 my problem right now is that i can't find a single distro that works with my box . almost every one (even multitool) goes to a black screen and freezes excatly after 60 seconds . the best thing i could find was a android rom that have the same problem but in excatly 30 minute after booting up ! i did this stupid thing that did not backed up my original rom before writing to internal emcp flash 🤦‍♂️ if i can find any version that doesn't have this problem , i know how to merge armbian rootfs with it ! thank you again !

Have you tried your python script with your Linux PC? If it happens again, you can tell that the problem is within the ESP32 program. I generally prefer having the most complex system (Armbian) poll the simplest device (ESP32), instead of the ESP32 interrupting the Armbian system. I found it more stable that way. Stay with wifi, and use the ESP32 serial port just for debugging. Program the ESP32 print an acknowledgement of data requests, and an alarm if it gets stuck in an unexpected state. I have also found ESP32 circuit or micro python very stable for serial port communications.

I do not have any other monitor available but I did order a UART to usb device, and I have identified with a multimeter the uart pads, which are next to the SD card slot. I will keep this feed updated!

Hello! You should really look to the board name in rk3318-config rather than relying to led-conf numbering; also your dmesg is showing a very bad error which is probably due to an unstable system rather than a bug

rk322x armbian images never used the offset of 8192 sectors, only the multitool has such offset to increase compatibility with stock images

@Hqnicolas would it be possible to have the driver @guenter pointed out in the base image?

I think the core problem is that headers were compiled with Ubuntu compiler / userspace and you try to use it on Debian. I used this on Ubuntu, which is the reason why it worked. We are aware of this problem - headers should be distro specific. Which adds complexity on our side ...

Feel free to pr any missing overlay here: https://github.com/armbian/linux-rockchip

moved to csc https://docs.armbian.com/User-Guide_FAQ/#why-no-universal-image tl;dr: You are using the wrong image. Get/build one for your board

It works, but I found that the i2c dtbo file I needed was not in the armbian repository, so I manually extracted it from the radxa official image.

Armbian 25.8.1 Noble Gnome (Kernel: 6.1.115) + libMali (https://github.com/ginkage/libmali-rockchip) + box64 3.7 (https://ryanfortner.github.io/box64-debs/) + wine-9.22-staging-tkg-amd64-wow64 (https://github.com/Kron4ek/Wine-Builds/releases/tag/9.22) + DXVK-Sarek v1.11.1 - Mali GPU Fix by Ayman-Zeyada (https://github.com/Ayman-Zeyada/DXVK-Sarek/releases/tag/v1.11.1-mali-fix) ~60fps@1080p HK: SilkSong