Rockchip’s RK3188 quad-core processor is one of the fastest ARM Cortex-A9 chips on the market. But up until now if you’ve had a tablet, TV stick, or other devices with an RK3188 chip, you’ve probably only been able to run Android on it.

Now you can also run Ubuntu, and possibly other Linux-based operating systems as well.

RK3188 Ubuntu

Earlier this month Rikomagic released Linux source code for the MK802 IV mini PC with an RK3188 chip. Now a handful of people have used that code as a starting point for running Ubuntu Linux on similar devices, including the QC802 and Tronsmart T428.

For the most part, the steps for installing Ubuntu should work on most Android TV boxes with RK3188 chips — and since you’re booting Ubuntu from an SD card, you should be able to do it without affecting the Android software that probably came with your device.

On the other hand, Ubuntu for RK3188 sticks is still pretty rough around the edges. There’s currently no support for WiFi, Bluetooth, or hardware-accelerated graphics. Since different devices have different wireless chips it could take a while before Ubuntu is fully functional on every available device with an RK3188 chip.

Ian Morrison has posted details on getting Ubuntu up and running on an RK3188 box, as well as some performance benchmarks.

More details are available at CNX-Software.

Support Liliputing

Liliputing's primary sources of revenue are advertising and affiliate links (if you click the "Shop" button at the top of the page and buy something on Amazon, for example, we'll get a small commission).

But there are several ways you can support the site directly even if you're using an ad blocker* and hate online shopping.

Contribute to our Patreon campaign

or...

Contribute via PayPal

* If you are using an ad blocker like uBlock Origin and seeing a pop-up message at the bottom of the screen, we have a guide that may help you disable it.

Subscribe to Liliputing via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 9,547 other subscribers

29 replies on “Ubuntu up and running on Android mini PCs with RK3188 chips”

  1. Does any of those smartphone chips support virtualization? Several years out and anyone can start a “blade” (usb sticks) server with a USB hub. Wondering about xenserver support development… Would like to start one now.

  2. Everyone’s concerns with ARM and Linux will be addressed with Tizen.

  3. This development augurs well for developing countries where affordable mobile devices will play a big role in advancing school education. Back in March 2013, Ricky Cheng pioneered the use of Ubuntu in PC-TV devices to build a prototype server for Learning Management Systems in remote areas https://www.col.org/blog/Lists/Posts/Post.aspx?ID=169

  4. It’s not so much ARM but drivers for the Mali GPU or the GPU used generally thats the issue for Linux support, particularly getting HW acceleration

  5. I love to see linux support for ARM but Rockchip should consider having VGA support on their chips like Mlogic does, that way you could use a $35 stick like ARM computer in connection with a used or old monitor as a very functional all in one PC that could play music, HD video, Youtube, Games, and everything you would need an x86 computer can do, witch would be incredibly valuable to developing countries where for the price of an empty, used ATX case with a power supply, you could get a whole system that can enrich the life of a whole family somewhere. VGA is by far the most popular video output port in the world, witch is why many brand new devices still use it, on TV’s, laptops, projectors, etc. Nowadays used 4:3 LCD’s are being sold for less tham $20, all over the world, but for some stupid reason all the ARM sticks with ANDROID or Linux, all have HDMI output only, keeping this pairing from happening.
    Imagine what you could do with a bunch $35-$45 Linux sticks, with Ethernet port/s 4-8 USB ports, VGA and built in audio, You could make it in to an verry versatile firewalled linux based router, home file server, ip webcam, streaming tv tuner / DVR, silent over night doanload machine, or all those, in an all in one PC .
    ARM sticks with the right ports, Linux or Android and a contributing drivers developing community, can do things for the technology needs of modern man, that x86 never hoped to dream about, an it can do it all at a price per computational power unit that the world never taught possible before the ARM revolution when x86 was the only way to enjoy digital content and the online experience.

    1. To minimize long term maintenance costs, it’ll probably be cheaper to go with an x86 solution for developing countries or anyone who doesn’t want to stay with outdated software due to the lack of long term proprietary driver support. Unless they don’t want the newer features, security and stability enhancements of newer software.

      I doubt charity organizations can convince vendors to provide long term binary blob support either. With how ARM platforms are right now, the initial low price isn’t worth it in the long run. Especially with Bay Trail Atoms becoming more Linux friendly with open source drivers and also as cheap as ARM chips. Even if Intel stops supporting the chip, charity organizations and/or nice developers can update the open source code themselves.

      1. There is a new emerging market that has quadrupled since last year. The first few manufacturers to readily supply code for Linux developers will create the standard and will be awarded the market. All other arm chips will need to adapt to the new Linux kernel. I have full confidence that Ubuntu touch will work great. Where their is money there is innovation. Linux developers were right all these years. They will succeed in the marketplace given the correct environment and the right amount of demand. Because of the security of Linux the NSA will be the savior of the computer world forcing us to walk away from Apple and Microsoft just to maintain freedom. Ironic eh?

  6. This is why I haven’t jumped on the ARM bandwagon beyond smartphones. No device is the same and manufacturers implement things differently.

    I’m waiting until I can download the ISO from my distro of choice and just install it. I may like writing bash scripts and C++ software but I’m no Linux kernel developer.

    I’ll be sticking with larger x86 based SBCs for a while I guess.

    1. Well, at least we’ll start seeing similar x86 solutions with the upcoming 22nm Silvermont based updates for the ATOM.

      Unlike the present 32nm ATOM SoCs, we’ll see some actual Linux support as well as pretty decent performance.

    2. Ya, ARM is a mess for those who want to run a Linux distro other than the one the company provides images for. I don’t want to be running Android or some other mobile OS either especially when I plan on using it as some sort server or automation control device. Also, who knows how long the OEM will provide updated images if at all.

      I have some ARM SBCs where the OEMs haven’t provided any updated kernel images for years despite them still selling the boards. I have to edit and compile newer kernels myself. It’s a pain and much rather just go with x86.

      There’s work in creating a unified Linux kernel for ARM but that is a ways away from being usable by end users like us. I’m hoping some mini devices or maybe even sticks come out with Bay Trail Atoms. They’ll have much better out of the box Linux support than current Atoms and any ARM. Judging from the price of current Atoms, the Bay Trail ones will probably cost just as much as ARM SoCs.

      1. By the time the unified ARM kernel becomes stable enough for commercial products and vendors start standardizing their systems to help the ARM platform fragmentation, Intel Silvermont based Atoms will have become a viable platform for cheap low power mini devices targeting Linux desktop distros.

      2. It’s not just graphics that don’t work either. WiFi, Ethernet, Bluetooth and other controllers may not work. Even if the SoC maker provides Linux drivers to OEMs, those are proprietary and often tied to a Linux kernel version. So you can’t even upgrade the kernel yourself if the proprietary drivers aren’t updated to support the new kernel.

        This is going to be a problem for Ubuntu Touch that’s using Android’s graphics stack in order to get access to these closed source drivers. They may not be able to provide OS upgrades to all devices if the closed drivers aren’t compatible with the new kernel without a lot of effort. That would defeat the purpose of using Android’s stack since not wanting to put this kind of effort was one of the reasons to go with this route.

        I agree, it’s better to just target Bay Trail for tablets. It’s going to be a while before ARM SoC makers and OEMs start standardizing things and also provide open source drivers.

    3. It’s not that ARM is a mess per-se, it’s more that ARM doesn’t have a standardized BIOS in which to initialize the system to a “known state” before booting the OS. Since the manufacturer knowns where their SoC will jump to on boot and what state it will be in, it makes it a lot easier for them to make an image for their own hardware.

  7. Yup, always the same story. It works if you don’t want video. Really hope the Lima project gets up to snuff soon.

        1. Yes, Canonical’s decision on this one is definitely sensible.

          What I don’t understand is why Wayland is not following Mir and migrate to the Android OpenGL drivers.

          1. Because the Wayland devs are smart enough to avoid a binary blob trap. They want to retain the freedom of movement required to develop something new that they hope will be enough better to lure people away from X. By limiting themselves to whatever APIs are available on a closed binary intended for an alien environment they would have even longer odds of success.

            And remember, the only binary blobs available for most hardware is only EGL. Most X apps expect the full OpenGL environment, not the cut down embedded version. So you would setup a situation where X apps wouldn’t easily port to EGL while the other direction would be easy. Not a good way to encourage a migration.

          2. Adding to what John said, binary blobs often only work for specific kernel versions. If the SoC maker decides to stop supporting their SoC with updated proprietary drivers then Ubuntu is going to have a mess on their hands trying to keep every device updated. It’s not easy like with most x86 platforms right now. An x86 example, would be the Atoms with PowerVR graphics where updated binary blobs have stopped. With ARM, that situation occurs on every device and it’s not just the graphics that have proprietary drivers that don’t get updated.

            This is why some phones don’t get updated Android OS’s that have updated kernels even though the hardware should technically be powerful enough.

            Ubuntu initially said that they were working with hardware companies to try to get things standardized and keep things updated but those talks apparently failed by the fact that they’re falling back to Android. No surprise since Google couldn’t do it either.

          3. I agree that binry blobs are a problem but they are still MUCH better than no drivers at all.

            Imagine a situation on desktop Linux without binary X drivers from Nvidia and AMD. It wouldn’t be nice.

          4. Except NVIDIA and AMD provide consistent long term binary driver updates for their GPUs especially when newer kernels aren’t compatible. All the ARM vendors don’t. Canonical tried to talk with some ARM vendors and integrators but that failed. So the trend of near non-existent ARM driver updates for Linux will likely continue. This also includes all proprietary drivers and that’s more than just the GPU.

            Canonical’s solution of using Android might backfire. For Android it’s fine because Android isn’t intended to be installed and updated by end users and are forced to keep their devices outdated. Whereas Ubuntu is known to be installed and updated by end users. As vendors drop support for older ARM chips, Canonical is going to have a hard time explaining to users why they can’t install the newest OS version. Android OEMs still have a hard time doing that (that is if they actually want to provide updates to their phones).

            If Canonical wasn’t able to negotiate with ARM vendors and aren’t willing to put the effort into reverse engineering the proprietary drivers into open source ones then they should just target the Bay Trail Atom. It’ll be less costly in the long run.

            I just hope running Linux distros (not just Ubuntu Touch) becomes poplular on ARM devices so maybe vendors will start providing longer support for their chips.

          5. Why can’t they update everything except the kernel and just keep the kernel frozen for hardware compatibility?

          6. Sounds like you need to talk money not turkey. Getting down to the nuts and bolts of programming a lot easier when the money is backing it so talk to the employers and investors of these arm developers. The entire point for these manufacturers is profit motive.

        2. No, Ubuntu is doing something shortterm ‘pragmatic’ but long term stupid. In other words RMS is right. By binding Ubuntu to whatever one or two kernel versions the binary blobs require they are allowing Android to dictate which new kernel features will be usable in Ubuntu.

Comments are closed.