Rikomagic Announces MK802III LE and MK802IV LE mini PCs Preloaded with Linux (Picuntu)

If you’ve been following the ARM based mini PC space, you may already know about Rikomagic MK802 III and MK802 IV HDMI TV Sticks, respectively based on Rockchip RK3066 and RK3188, running Android Jelly Bean. Rikomagic and Cloudsto Electronics have just announced they will launch a “Linux Edition” (LE) for those two devices called MK802III LE and MK802IV LE Quad Core, running Picuntu (Ubuntu) Linux.


Since Linux on RK3188 is still work on progress, Cloudsto MK802III LE will be available first, with the following specs:

  • SoC – Rockchip RK3066 dual core Cortex A9 @ 1.6Ghz + Mali-400 MP4 GPU
  • System Memory – 1GB RAM
  • Storage – 16GB Micro SD card preloaded with PicUntu, but no word about NAND flash
  • Video Output – HDMI (1080p)
  • Connectivity – Wifi 802.11 b/g/n
  • USB –  2 x USB ports
PicUntu Desktop (Click to Enlarge)
PicUntu Desktop (Click to Enlarge)

It’s not very clear if the hardware will be slightly tweaked (e.g. smaller NAND flash, as I understand it is required for booting), or if it will just be exactly the same hardware as the Android version, but the addition of a 16GB micro SD card preloaded with Picuntu. Pricing and availability have not been provided at this time, but those will probably be updated on Rikomagic UK’s Linux mini PCs page.

Via G+ mini PC community

Share this:
FacebookTwitterHacker NewsSlashdotRedditLinkedInPinterestFlipboardMeWeLineEmailShare

Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress

ROCK 5 ITX RK3588 mini-ITX motherboard

18 Replies to “Rikomagic Announces MK802III LE and MK802IV LE mini PCs Preloaded with Linux (Picuntu)”

  1. It’s great they’re contributing to get Linux working on these sticks. But itf they don’t put it on the internal flash, what they actually offering anything? I mean, wouldn’t a vast majority of Linux dabblers know how to burn a Picuntu ISO to an SD card?

  2. To boot any RK3066 or RK3188 device all you need is about 36MiB of Flash for full blown standard size boot off the external microSD card, 52MiB if you stay with standard recovery partition, but if the stick has only one bootable partition, then that 36MiB would be enough… and if you hardwire the chip into different memory address space (or change the partition layout itself, that also works), then you could get away with 32MiB for one bootable partition, or 48MiB for dual bootable partitions.

    Would they have exchanged the 8GiB/16GiB chip into 32MiB/64MiB? Who knows (as it is technically possible), but I think that would be pretty silly, as the raw chip price difference would be in the cents range.

    But I bet they have changed the “linuxroot” partition label to something else to seem all professional and stuff (actually that is nothing more than an ASCII string within the parameter partition). 😉

    Well, an good step forward after all, hopefully they keep that policy in the future, and include all source codes for regenerating itself with the stick (especially now the modded kernel, and hopefully try to upstream as much of it as possible, maybe by Linux 3.12 it can be built native within the system itself? as 3.11 is not cutting it).

  3. Oh, of course they could also shrink the partitions themselves, 16MiB for an kernel image space is a bit large, but of course is good for future proofing, but not strictly necessary, majority of kernels can be easily fit into 8MiB partitions.

    I hope people should start to make their kernels less module-based though, so of course including the drivers and such into the kernel would make them larger… But as a Gentoo-ner, I prefer to compile everything possible within the kernel, and minimize all external module and firmware files, but that comes with the territory of being a Gentoo ricer. 🙂

    Anyone against it, see the boot kernel log, the unused drivers get thrown out of memory after the kernel boots, the result does NOT use a lot more memory, and having to manage separate files in /lib/modules is too much of an hassle, why not compile every single driver that is found built in into those RK3xxx sticks, and build those into the kernel, and rest of external plugable stuff as loadable modules?

  4. @cnxsoft
    Yeah, have been monitoring the few commits here and there, but is just wishful thinking from my part.

    I wish all those ARM manufacturers could see the benefit of mainlining all they could, as then people could really start to move the usages of those sticks from conventional Android/Desktop into other areas as well.

    My sticks work just fine as servers of all kind of data, web, DLNA, distcc, and similar _server_ tasks, these current RK3xxx chips can easily beat my previous x86-based systems, only few things lack (mostly lack of native SATA/Gigabit Ethernet and such bandwidth things), but overall the lack of noise/heat, and general power usage still beats the old school stuff easily.

    And as the major players in the x86 world have moved to also do micro servers, why not the ARM world?

  5. I got a few more details from Rikomagic:

    “The MK802III LE is a bit different to the MK802III, actually its more akin to the MK802IIIS, with onboard PMU, RTL8188 Wifi chipset and easily accessible recovery switch.

    Should be available in the next 1-2 weeks.”

  6. @cnxsoft
    Yeah, the fact is that if they use III’s WiFi (RTL8188CU), with an upgrade to the PMU from IIIS, then that stick will be very nice indeed.

    I have one of those IIIS sticks that have that awful Mediatek WiFi, that simply disables their usage for Linux stuff, only Android side works fine (binary driver blob and what comes with that), was a bad buy from me (did not look up the specs beforehand, stupid me, live and learn). 🙁

  7. @anon
    Yes – I also recommend 32768 blocks or 16777216 bytes (16MB/16MiB) because as you say as this allows modules to be built into the kernel without any risk of “bleeding” into the next partition after flashing.

  8. Well, my first RK3188 (MK802IV with AP6210) turned up to be a disaster, did manage to upgrade the NAND to have the NEOTV Hybrid Android, and the linuxium test kernel for Picuntu, both booted up just fine, until the picuntu tried to load leftover rk30fb from the drive, then the stick got stuck, and I powered it down.

    After modding to disable XDM/KDM from starting with another stick, tried to boot the Quad stick again… and nothing, the stick is dead, can’t even see it on other system via the USB (with or without trying to go to recovery mode with the button), dead as a door nail.

    Not really sure what could had gone wrong, maybe the rk30fb got the CPU/GPU into some fault mode that burned something on the SoC? Sounds far fetched, such stuff should not happen.

    And naturally had the case cover opened yesterday already, so even if RMA would had been a possibility, now that is not happening. :-S

    If anyone have any idea how it might be recoverable, please share the information.

    So now my dealings with the RK3188 is on hiatus for a while, need to wait and see with the new crop of devices before throwing money into fire pit, hopefully the MK802IV LE will be more robust.

  9. @cnxsoft : any hope to get vpu working through libhybris + stagefright ? Without any vpu support it all becomes much less interesting, compared to i.Mx6 quad…

  10. Phew, bricking the actual MK802IV hardware was just a scare tactics I made for myself. 😀

    The stick came back kicking after doing the official firmware update via RK Batch Tool (1st time user of it, and on Windoze, yack!) with few errors here and there, but in the end getting it pass the flashing.

    Will certainly be looking forward to seeing what the LE versions bring, I sure hope they keep that USB-interfaced Realtek WiFi.

    (dreaming of an large heatsink, but that’s not gonna happen, as they use the same standard casings for them)

Leave a Reply

Your email address will not be published. Required fields are marked *

Khadas VIM4 SBC
Khadas VIM4 SBC