bayindirh

I was planning to try compiling the new kernel with old DTB but had no time lately. I can build the userspace in a pretty straightforward way. If I can create a development environment (even for vanilla Debian), will package it as a Vagrant file and share there, so it'll be reproducible. Maybe I can take some hints from the latest TV box releases. Did some (mid-weight) distro development work in my professional life, but never had to play with the kernel. This might be a good opportunity to do so. I know 3188 is old stuff, but if you can make old stuff run fast, new stuff runs even faster. So, I stubbornly try to use my stuff to its limits.

The biggest problem with Radxa Rock was building the kernel. The source and configuration of the latest 3.x kernel is available with all the drivers in Radxa's GitHub repository. If we can somehow port these changes to latest Linux kernel, building the userspace is really simple.

Thanks tparys for answer and the links. Rock's documentation was good enough to start and explore. I'll play with both Armbian and Rock's kernel building process and see what can I do. Will report my progress here. Regards, H.

Hello all, I just wanted to ask is there any consideration to support Radxa Rock (Standard/Pro) in any form. It is/was a Rk3188 based board with 2GB RAM and 8GB of flash. I'm using it as a VPN server with Debian 8 and it proved very reliable in all departments over the years. It was quite powerful for its time and I think it could prove to be very useful since it can be left to run without any active cooling or anything. I'm putting it here for consideration since I guess supporting RK3188 won't create any substantial workload, and it can do a lot even for today's standards. I have two of the devices and can use one of them for testing if required. Was unable to post anything to board bring-up subforum since I had no right to post there. More information about the board can be found here. Please feel free to correct me about the work required or just toss the idea away. No hard feelings, but I'd be happy if I can use these boards with something modern and be part of the effort if it's feasible.

I just wanted to post a quick update: Doing in-place upgrade to xenial -> bionic went without any problems. I only needed to update my armbian repository source file by hand (do-release-upgrade disables it, and updates it wrong, so there's that). The good news is, dnsmasq is not abruptly stopping anymore. It's working as it should. No weekly updates or paranoid nslookup checks to see whether it's alive.

I actually have enough spares. Can clone and try it, why not? It's a nice idea The customization I did should not be breaking. I've installed some packages, written some small tools, added some cron jobs, maybe changed some services' default parameters, etc. I actually use Debian for ~13 years now, and Linux in general for a bit longer. So I'm used to do small changes in my systems as I use them and find places which can be tuned better for my requirements. Since they're too small & short to document, they generally got lost in the process. This is why I'm hesitant to take the risk Thanks again for the quick reply. I'll keep the progress updated in this thread.

Thanks for your answer I've looked to DNSMasq bugzilla in Ubuntu, Debian and did a general Google search before. Didn't find a similar issue, and posted here at last. Is directly release-upgrading in Armbian safe? I've customized the distro the way I want a lot, and can't afford to migrate to a clean install of Bionic time-wise.

Hello all, I'm using Armbian 5.73 stable (Ubuntu 16.04.5 LTS) for a year or so on an OrangePi Zero. That little box is working as a backup box and network-wise DNS server via DNSMasq (ver. 2.75-1ubuntu0.16.04.5). The OS and general system is working very stable, but I'm having issues with DNSMasq. It's solving both local systems' names via /etc/hosts and internet hostnames for the whole network. Sometimes, DNSMasq stops solving external addresses. There'll be no error and warning messages anywhere, and when pinged with kill -USR1 signal, it happily prints the current stats. I'm running with a cache size of 6148, and I see no cache overflows in the stats. I've experienced no write/read errors on the SD card and the USB stick which I push backups to since I first installed the system, however I recently updated the PSU to an 2.5A one. It helped with speed, but the DNSMasq issue didn't go away. Has anyone experienced any problems with DNSMasq? Any suggestions? Thanks in advance.

Just wanted to add some, albeit not very scientific, testing and observation results for further reference. TL;DR: Do not use 1A power supplies with OrangePi Zero. The board is small, but with ethernet connected, it really needs and shines with 2.0A and more power to spare. Long Version I'm running an OrangePi Zero 1.4 with Armbian 16.04LTS. It runs DNSMasq for home network and also acts as a rsync/backup server for couple of android phones. I've powered the board with a high quality Artwizz 1.0A USB power supply around a year. Sometimes I experienced small problems like DNSMasq becoming non-responsive on a bi-weekly basis, or the SSH connections fail to the board rarely. Also, the board was working a bit sluggish. I attributed the problems to the CPU power and the overall quality of the board, but it was bothering me nevertheless. All in all, the uptime and general stability of the system was acceptable from that kind of board though. Yesterday, after losing SSH connection again, I thought about increasing the power budget of the board, then I found this thread and replaced the adapter with an 2.5A one (I'm a kind of engineer who over-engineers for reliability and headroom). DNSMasq is visibly snappier, the temps are down 2-3 degrees Celsius. I will observe the system more and will update here with long term test results.