$24 Sunvell R69 Android 4.4 TV Box is Powered by Allwinner H2 Processor

We’ve fist seen Allwinner H2(+) quad core Cortex A7 processor in cheap development boards such as Orange Pi Zero, but the processor main market is actually “Basic OTT TV boxes” for 1080p video playback, and Sunvell R69 TV box is one of the first of those, and comes with 1GB RAM & 8GB storage.

Sunvell R69 TV box specifications:

  • SoC – Allwinner H2 quad core Cortex A7 processor @ up to 1.5 GHz (TBC) with Mali-400MP2 GPU
  • System Memory – 1GB DDR3
  • Storage – 8GB flash + micro SD slot up to 32GB
  • Video & Audio Output – HDMI 1.4 output up to 1080p60, AV port (composite video + stereo audio)
  • Video Codec – H.265 / H.264 up to 1080p
  • Connectivity – 10/100M Ethernet, 802.11 b/g/n WiFi (via XR819 chipset)
  • USB – 2x USB 2.0 ports
  • Power Supply – 5V/2A
  • Dimensions – 9 x 9.5 x 1.8 cm
  • Weight – 200 grams

The box runs Android 4.4, which means Kodi 17 won’t be supported as Android 5.0 Lollipop or greater is required, but you can always install Kodi 16.0 if it is not pre-loaded yet. The media player ships an IR remote control, a HDMI cable, an a power adapter.

Sunvell R69 is currently sold on GearBest for $23.99 including shipping when using GBSR69 coupon.  That’s about $5 to $10 cheaper than entry level Amlogic S905X TV boxes capable of handling 4K videos with similar specs (1GB RAM/8GB storage). The price is also very close to Rockchip RK3229 TV boxes catering for the same market (1080p Android media player).

Via AndroidPC.es

Share this:
FacebookTwitterHacker NewsSlashdotRedditLinkedInPinterestFlipboardMeWeLineEmailShare

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

ROCK Pi 4C Plus

42 Replies to “$24 Sunvell R69 Android 4.4 TV Box is Powered by Allwinner H2 Processor”

  1. @cnxsoft:
    ‘up to 1.5 GHz (TBC)’ — there’s nothing to confirm. The vendor would be stupid to overvolt H2 to be able to clock up to 1.5GHz without instantly crashing. But since Allwinner’s default BSP kernel cpufreq operating points have 1536 MHz as highest OPP defined tools like CPU-Z will happily report 1536 MHz –> mission accomplished (same with all A64 devices that are all identified as 1.3GHz devices by CPU-Z or pseudo benchmarks like eg. Geekbench).

  2. Do such tv boxes have the ability to power down and repower from IR? I dont think there is a pmu coming with h2.
    Im fed up with constantly plugging/unplugging my rpi3… And powering down without pmu/other clever circuit handling the situation is kind of pointless.

  3. @itchy n scratchy
    Most TV boxes can be powered down and up from the remote control. So this should not be a problem.
    For RPI3, you can also do something like that by using HDMI CEC + the TV remote. That’s provided you use a HDMI cable, and not the AV port.

  4. @itchy n scratchy
    On H2+/H3/H5 with Allwinner’s BSP it’s done this way: a kernel setting implements ‘shutdown’ as a special reboot variant setting an u-boot flag. When you power down your device it reboots into u-boot, turns off almost everything and only the OpenRISC core inside the SoC remains active (talking about a few 100mW here). Then you define wakeup sources (power button, IR, even BT or Wi-Fi are possible but this is all device dependent and you have to define the stuff correctly in the so called sys_config.fex) and as soon as such a wakeup event is triggered (press the power button on your IR remote) the OpenRISC core wakes the ARM cores and Android or Linux boot normally.

    So it’s not really powered down but being in suspend mode with only the OpenRISC sitting there and waiting at minimum consumption.

    Sure, just extract the sys_config.fex from the Android (see h3disp thread in Armbian forum where I linked to a tutorial), then take the Desktop image for OPi Zero, slightly modify the fex file and you’re done. Since this TV box also uses the low-end XR819 Wi-Fi everything should be working out of the box (and now we know why we ended up with XR819 on the Zero –> since Allwinner’s H2+ reference design 😉 )

    To get the idea about potential fex modifications simply have a look at the 2nd commit here: github.com/armbian/build/commits/master/config/fex/nanopim1plus.fex (I usually try to import the vendor fex first and with next commit adopt the Armbian specific bits/optimizations for exactly that reason: that others might be able to understand how insanely easy it is to add another H2/H3 device 🙂 )

    1. @tkaiser
      Thats an interesting concept, not stupid at all…

      You say in allwinner bsp thats working, as no one in his proper mind would even consider running this vanilla… Is there support for this in mainline, or are you aware of any plans implementing it at all? Or if not is there any branch of sunxi supporting it?

      If not then maybe chip or an s905? Else i might as well have to heat up my soldering iron and glue an avr to the raspi…

  5. > 802.11 b/g/n WiFi (via XR819 chipset)

    Oh boy, anyone who buys this is in for a “fun” experience…

  6. Well just as some of us thought- these Android boxes are now much better in price/performance than those xPis with PIA OSes !

    Plus very hackable, both SD and onboard mem options, dual media output, no significant power issues, not to mention commercially tested and with free shipping mostly.

    No surprise though. These Android Box vendors started like xPi vendors, but had better tech and marketing- not 1000s but 100Ks of units annually now.

    Won’t be surprised to see these prices drop to $20+ by summer.

    Amused to see XR819 working on Android while Armbians couldn’t figure it out on their choice OS in 9 months.

    Why not just run Android on OPi? Looks like Xunlong has seen the light with Android potential on their RDA 2G $10 model.

  7. cnxsoft :
    Maybe it works better with Android than with Linux.

    Nope, which isn’t that surprising since the ‘Linux driver’ (at least the one Armbian uses with the legacy OS images) is exactly the code drop from H2 Android SDK (see filez.zoobab.com/allwinner/h2/). The horribly low performance on first preliminary Armbian images for OPi Zero was due to enabled Wi-Fi powermanagement which was a simple fix we implemented then for all Wi-Fi variants on all boards after some discussion. With both the Android driver and the out-of-tree mainline variant there are still a lot of issues but no one right in his mind will try to improve things any further. Status: https://github.com/fifteenhex/xradio/blob/master/README.md

    In the meantime we got a newer Android code drop from Allwinner that is prepared to also run on kernel 3.10 (hey, it’s 2017! 😉 ) and I had some hope that we might get a little bit further since FriendlyELEC planned to use XR819 on their not yet released NanoPi NEO Plus 2. But guess what: at least according to github.com/friendlyarm/linux/commits/sunxi-4.11.y they dropped the idea and use now AP6212A instead. Since it’s impossible to fix hardware in software (quite easy to understand but obviously not for everyone).

  8. @Athar

    XR819 is made by Allwinner and it is working on their Android port. Geez I’d hope it’d be working, Allwinner has over $1B market cap on the stock market and hundreds of employees. Armbian is probably functioning off from a few thousand dollars. Xunlong does not write this stuff, he just gets it from Allwinner and reships. Similar story with RDA.

    The sorry story here is why Allwinner can’t get their chips supported in mainline. Sooner or later they will finally figure out that it is less work than what they are currently doing.

    1. @Jon Smirl

      I agree. This is the difference between professional work (e.g., Free Electrons with Allwinner R8 based $9 CHIP) and volunteers like Armbian.

      With this model Sunvell has jumped most OrangePi models. How come Sunwell can run Android over H2+ but Xunlong doesn’t?

  9. @Jon Smirl
    Why do you feed the troll/liar? He’s not able to understand what you’re telling him and now feels encouraged again to spread BS like he does since months.

    The XR819 driver mess is the result of professional work (Allwinner employees ). If you want to vomit take a look at their latest code drop: http://kaiser-edv.de/tmp/lGtv38/patch-add-support-xr819.tar.gz

    And that pretty much explains why Allwinner isn’t able to upstream their code since it would never pass any review. And that also explains why no one wants to clean up this mess: since it’s awful as most if not all code from the ‘port and forget’ Android world where this cheap tablet and TV box stuff originates from.

    Of course XR819 does ‘work’ on Allwinner’s Android (I tested it on OPi Zero) but the ‘performance’ is as good (better call it bad) as with plain Linux or even OpenWRT. And it’s pretty easy to understand by listening to those folks who actually looked into the driver (see above link to github.com/fifteenhex/xradio/blob/master/README.md)

    1. @tkaiser

      So why spin wheels for nothing? Let the professional folks like Free Electrons do their job.

      Do you like to vomit on yourself?

      Don’t make promises you can’t keep- and what’s the innovation in SATA over USB2?

  10. Athar :
    Why not just run Android on OPi? Looks like Xunlong has seen the light with Android potential on their RDA 2G $10 model.

    Well, maybe because Android sucks?

    One of these days, just for fun, looking at the apks installed on my droid tablet, I counted 7 different Python, some of them the same version.
    What a waste of space and resources!

    1. @JotaMG

      Android may suck like all those other distros and Windows and Mac, but as free stuff it still beats all its competitors.

      It certainly has taken over all those xPi Linux SBC vendors given its superior price/performance.

      Nothing wrong with hacking- but if it doesn’t advance the state of art, those volunteers shouldn’t be loud mouthing their SATA over USB2 like or power/ SD card repair “achievements.”

  11. @tkaiser

    I don’t dispute your extensive knowledge of the technologies, but I suggest you deal better with people that have different opinions than yours.

    Although I thanks Armbian for all the great work, there is lots of space for improvements, like using f2fs, a different (better) install method, etc.

    And, to call “professional work” what AW have been delivering, is going down on the semantics of the words…

  12. @JotaMG

    AW code has a whole lot of problems. It is riddled with security holes and bugs. These problems are AW own doing since they won’t participate in the community review process. Samsung and many other companies don’t have any problem with participating in the community review process which make their code orders of magnitude better than AW’s. Instead AW writes code in isolation and doesn’t accept much feedback when problems are reported. I suspect the RDA code is in a similar state.

    It is free to participate in the community review process. AW just has to post their code to the relevant email list and ask for feedback. Hundreds of people participate in these reviews and AW’s code would benefit greatly. It is unknown to me why AW won’t participate. Many people have asked them to join.

    So use the AW/RDA code if you want, just be aware that it contains security bugs that were patched in mainline Android years ago. Any halfway competent hacker can root an AW system with ease.

  13. @itchy n scratchy
    This suspend/resume works with Allwinner’s BSP (and some Linux distros using 3.4 kernel also implement it, eg. Armbian H3/H2+ OS images with legacy kernel). For the Android behaviour also Allwinner’s u-boot would be needed and at least in Armbian we decided against to deal with another mess so ‘device wakeup’ neither works with power button nor IR or anything else (only a real power cycle will do). To be honest: since we managed to ger idle consumption on these devices that low (OPi Zero for example is at ~500mW, no idea what this TV box here uses for voltage regulators/regulation so can’t say anything) there are not that much savings possible comparing idle and suspend.

    I’m curious about that ‘space for improvements’ so please feel free to open a thread in Armbian forum to discuss this. Wrt F2FS: I was very excited years ago and we fully support it in Armbian. All you’ve to do is to use the build system and then

    You’ll end up with a rootfs with fixed size that will and can not be resized automatically on first boot due to F2FS not supporting this. And of course the kernel you use needs to support the FS (so you’d need to use mainline kernel since F2FS came with 3.8 and received tons of fixes later). These two limitations are the reason why we don’t provide F2FS OS images by default and some tests showed zero benefits compared to ext4. IMO the way better alternative is btrfs here, you can follow progress or even contribute here: https://github.com/armbian/build/issues/650

  14. @tkaiser In any case after reading the thread about cw1200 driver i think allwinner bought the most crappy wifi ip available for money so if wifi and power down and proper sw is a feature that counts then maybe better forget about such a crap. Somehow i lost my enthusiasm for those crappy boards where the bsp is even so ugly to repel developers who would like to refactor it… Just im not aware of any viable alternative. Beaglebone, rpi, s905, somehow all are lacking somewhere…

  15. Suppose it is one way to get a case, power supply , board for RetroOrangePi . if it will run on the hardware.

  16. itchy n scratchy :
    Somehow i lost my enthusiasm for those crappy boards where the bsp is even so ugly to repel developers who would like to refactor it…

    Not entirely true. Since a Pinebook dev sample arrived a few days ago I looked into development progress with BSP u-boot/kernel there and some community folks (especially ayufan who is mostly responsible for Android on A64 devices that does not suck) did an awesome work and also discuss currently to look deeper into Allwinner’s H5 code drop to port over stuff from H5 to A64 — one must know that those ‘professional’ Allwinner coders working in different business units all do their own job and BU 3 responsible for the TV box SoCs — H2+, H3, H5 and so on — seems to push out better code than BU 2 responsible for the tablet series (the A SoCs).

    But most devs don’t want to waste their time with ‘dead code’ and focus on mainlining efforts and there’s been some huge progress in the last months with Allwinner devices. Stay tuned and watch status matrix in linux-sunxi wiki.

    Your above comment applies to situation with XR819 Wi-Fi driver: both hardware and driver are crappy and no one right in his mind wants to waste further time with this stuff especially since we still don’t have documentation worth the name.

    So we have a device that performs even more shitty than all the other 1T1R 2.4 GHz Wi-Fi devices but if you have the use cases in mind — either dirt cheap TV boxes or IoT nodes — this doesn’t matter that much. The dropped frames in TX direction (sending) aren’t a problem on TV boxes since they receive mostly and on IoT devices XR819 bandwidth requirements are non existent since sensors don’t produce high amounts of data (but XR819 can of course easily exceed 1 MB/s if needed even with the crappy driver we have to use now).

    1. @tkaiser
      Im more than happy if im being proven wrong 🙂 im in no hurry at the moment so im keeping an eye on the development before making a decision.

      Also my usecase is not yet clearly defined, do i want a zattoo player or an sbc for tinkering or both? I first have to make up my mind…

      The xr819 seems crap but for most usecases under mainline its ok and else there is also usb. But still sad what a crap is being manufactured.

      1. Lol concerning making up my mind… I should soon get a beelink x2… Lets see what its good for… Except wasting nights with tinkering…

  17. tkaiser:

    The resize problem is solved very easily with a redesign of the install process, and it works ok for both f2fs and btrfs 😉
    Concerning the benefits from f2fs, if you use a class 10 SD card with good random I/O, yes, there’s almost no difference and for the sake of simplicity ext4 is a good choice by default,.
    But with some old class 4 and 6 SD cards, some emmc and some flash, just using f2fs will boost random I/O speed by a significant amount!
    (althoug the sequential remains fairly bad, of course)

  18. itchy n scratchy :
    @tkaiser In any case after reading the thread about cw1200 driver i think allwinner bought the most crappy wifi ip available for money so if wifi and power down and proper sw is a feature that counts then maybe better forget about such a crap.

    The cw1200 driver was written by ST-Ericsson (who don’t even exist anymore) and the driver currently in mainline is for _pre-production_ silicon. Allwinner then made some hacks to this already ugly driver to support the XR819. The firmware running on the chip is a black box, and if the quality of the firmware is anything like the kernel module, it is only surprising that the XR819 isn’t *more* unstable. No one is going to waste their time trying to reverse engineer the firmware to figure out why it crashes so much.

    So right now it’s all on Allwinner. Either they release a datasheet for the XR819 and the community can and will improve the driver, or things can stay as they are now, and no one who does any research before purchasing will buy an XR819 product due to the numerous issues. Although few people do any research before buying the cheapest product, so likely they will just complain when they find out it’s terribad (this is also why Armbian people have stopped even replying to threads about WiFi performance; there is nothing more to be said).

    tkaiser :
    Your above comment applies to situation with XR819 Wi-Fi driver: both hardware and driver are crappy and no one right in his mind wants to waste further time with this stuff especially since we still don’t have documentation worth the name.

    Yes, as tkaiser says it’s 1T1R, so performance will always be low. This being said, I would *happily* continue work to improve the driver if there was any documentation available for the XR819. Unfortunately there is no documentation released.

    1. @hmartin
      Thanks for the explanations

      I’m usually quite ok with SISO 2.4g wlan for my usecase but as i hate things not working properly I’ll definitely avoid this piece of crap. And should I end up possessing one i know what it is 😉

      I’m just wondering if an xr819 is so much cheaper than an rtl or similar alternative…

  19. itchy n scratchy :
    I’m just wondering if an xr819 is so much cheaper than an rtl or similar alternative…

    Those ‘cheap TV box’ vendors usually can’t afford doing any real development (same with support later, don’t expect that you get any updates fixing device issues). XR819 was part of Allwinner’s reference design for H2+ devices and I would assume that’s the main reason we find it on such a TV box here or on Orange Pi Zero (usually the SoC vendor does all the work in this market segment so you as vendor define BOM costs, they recommend this or that and do the software up to the point where it somewhat works so product can be shipped to clueless customers).

    Since XR819 has performance issues especially in TX direction (lots of dropped frames) it should be even ok-ish for such TV boxes since receiving mostly… and TV box consumers don’t (want to) get the details anyway.

    It should be noted that some TV box manufacturers act differently (Zidoo for example comes to my mind who provide a rather polished Android and various upgrades for their H3 TV boxes) and that you usually can interchange the Android images between H2+/H3 devices (you just need to adjust so called sys_config.fex stuff and in case different Wi-Fi/BT modules are used you need some luck whether device/driver is supported/loaded). In other words: better choose a H3 box instead (like the Beelink X2 you already mentioned) than any of those newer and more cheap H2+ thingies 😉

  20. @JotaMG
    Wrt F2FS I wasted some time to test through some ‘real world’ Linux scenarios in the meantime (again) and weren’t able to find an advantage that would justify spending more time on this (just check the above link to Armbian forum).

    Since Linux situation is partially different from Android (many apps constantly using fsync calls so low random IO performance is responsible for sluggish behaviour)… do you or anyone else knows of a F2FS vs. ext4 comparison with Android that is worth the name?

    I only found ‘tests’ that were broken by design (just one test run, interchanging relevant parts of the hardware in between and so on)

  21. The beelink ended up cheaper than any h2+ box. I dont get that aliexpress behaviour anymore. Something costs 26$ then you click it et voilà now its 26 to 42…
    Now try selecting “colour” and plug type, no way you will get below 34…
    Thats a pretty new thing to me. So i ended up with an h3 😉

  22. You can get the box for $9.99 on GearBest.
    The trick is that it’s a flash sale with 5 pieces per day, starting at 10:00 UTC between May 8 and May 13.

  23. Do you have a direct link? Or can it only be found while there are supplies? I was bit early today 😉

  24. One Armbian user extracted the sys_config.fex stuff from Android and it seems this box is not implementing voltage regulation so the H2+ here ends up with being allowed to clock at 1008 MHz max (while CPU-Z and Geekbench of course still show 1.5GHz as intended).

    I made the usual modifications to fex settings to better deal with Allwinner H3 legacy kernel (used by Armbian, H3Droid, RetrOrangePi, Lakka and the community OpenELEC distro) and created Armbian images for the box where most stuff (Wi-Fi included) seems to work. Downloadable the next few weeks from here. Now it’s up to users of the box to create a device page in linux-sunxi wiki and hack together mainline u-boot/kernel stuff (more or less copy&paste with modifications to DRAM clockspeeds and THS/DVFS settings to reflect the SoC being fed with 1.2V only)

Leave a Reply

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

Khadas VIM4 SBC
Khadas VIM4 SBC