Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 21

Thread: Allwinner SoC Still Unlikely For Upstream Linux Kernel

  1. #11
    Join Date
    Jan 2012
    Posts
    113

    Default

    Yeah, the article blatantly misrepresents faсts, and the title is particularly wrong. Though it might work as http://en.wikipedia.org/wiki/Succ%C3%A8s_de_scandale because more people will become aware of Allwinner based ARM boards and other devices (hdmi dongles, tablets, TV boxes, netbooks, ...)

    The Allwinner A10/A13 hardware is very free software friendly thanks to lack of signed bootloaders (any device can boot GNU/Linux from SD card instead of the preinstalled firmware in NAND), availability of documentation, reasonably feature-complete problem-free community maintained custom LTS kernels based on the vendor code drop, and quickly progressing real mainline kernel support.

  2. #12
    Join Date
    Feb 2008
    Posts
    114

    Default

    That mailthread was most entertaining
    Luke's lack of insight into the currents state of affairs around allwinner SoC raised some red flags, but what topped it off was when Bj√rn Mork revealed that Luke is likely a troll notorious enough to be used as an example of -ENOPATCH.

    I'm going to give Luke the benefit of the doubt a wonder if his action will result in better support from Allwinner. Going by the mainlining-effort wiki page, the support is already pretty good for essential hardware and patches coming in 3.11 should make it workable as a server at least (working network, booting, USB for input, etc.) As an owner of Mele A2000, it would be awesome if VPU support was open and mainlined (or at least working properly, ATM the only working setups use a blob for android), but who am I kidding...

  3. #13
    Join Date
    Jan 2012
    Posts
    113

    Default

    Quote Originally Posted by myxal View Post
    As an owner of Mele A2000, it would be awesome if VPU support was open and mainlined
    There are some CedarX reverse engineering efforts (that's the name of the VPU in Allwinner chips). A tracer of accesses to hardware registers has been already implemented: https://gitorious.org/recedro/recedro
    And also a proof of concept open source CedarX accelerated decoder for JPEG (starting with the simple things makes sense): https://github.com/jemk/recedar/tree/master/jpeg-test
    The guys are making a good progress while we talk here

    (or at least working properly, ATM the only working setups use a blob for android), but who am I kidding...
    There are patches for VLC and XBMC to use CedarX hardware accelerated decoding in Linux (via a proprietary userland library so far). It is possible to watch HD videos, but these patched players are still not prefect and have some limitations.
    Last edited by ssvb; 06-12-2013 at 07:50 PM.

  4. #14
    Join Date
    Feb 2008
    Posts
    114

    Default

    Quote Originally Posted by ssvb View Post
    There are some CedarX reverse engineering efforts (that's the name of the VPU in Allwinner chips). A tracer of accesses to hardware registers has been already implemented: https://gitorious.org/recedro/recedro
    And also a proof of concept open source CedarX accelerated decoder for JPEG (starting with the simple things makes sense): https://github.com/jemk/recedar/tree/master/jpeg-test
    The guys are making a good progress while we talk here
    Indeed, this is quite far from being a ready product. What's worse:
    • if I understood the various wiki articles/blog posts correctly, is that AW's proprietary blob for regular linux is rubbish itself - it chokes on some kinds of streams
    • there's another, android-targeting blob, which reportedly works fine, but doesn't use OMX API and only recently gathered enough attention to warrant development of a wrapper.
    • The blobs don't come with any license, and developers are staying away from providing ready-to-use builds.

    It's depressing that R.Pi, which doesn't even boot without firmware blobs, coupled with lates XBMC builds, has a nearly ready product, while the A10 was hobbled by AW's lack of cooperation and is only now becoming a somewhat usable platform for HTPC and even so, the community support for the platform is nowhere near that for R.Pi, and last I checked, has still quite a few bugs which I consider show-stoppers.

    Quote Originally Posted by ssvb View Post
    There are patches for VLC and XBMC to use CedarX hardware accelerated decoding in Linux (via a proprietary userland library so far). It is possible to watch HD videos, but these patched players are still not prefect and have some limitations.
    As noted earlier, a set of patches (at least they're hosted on the sunxi site) is far from a ready-to-use SD-card image.

  5. #15
    Join Date
    Jan 2012
    Posts
    113

    Default

    Quote Originally Posted by myxal View Post
    It's depressing that R.Pi, which doesn't even boot without firmware blobs, coupled with lates XBMC builds, has a nearly ready product, while the A10 was hobbled by AW's lack of cooperation and is only now becoming a somewhat usable platform for HTPC
    Your Mele A2000 is a consumer product, which is coincidentally marketed as a freaking HTPC Just boot Android and use it for watching videos instead of launching XBMC. That is if you really don't care whether the player and underlying libraries are proprietary or free software.

    By the way, have you already tried Allwinner A10 port of XBMC in Linux yourself? Did you have bad experience with it or you are expecting to get bad experience based on various wiki pages and blogs?

    and even so, the community support for the platform is nowhere near that for R.Pi, and last I checked, has still quite a few bugs which I consider show-stoppers.
    Do you mean show stopper bugs for the platform itself, which are not related to the proprietary GPU/VPU parts? Could you please provide some links?

    The proprietary 3D GPU and VPU work, but are problematic. Just like they are problematic for every other ARM hardware. But at least for Allwinner A10/A13 we have fairly good chances to clean up this GPU and VPU mess via reverse engineering. I already provided CedarX VPU reverse engineering links in this topic. And for Mali400 GPU, I guess you have seen this: http://libv.livejournal.com/24735.html
    Last edited by ssvb; 06-13-2013 at 12:55 PM.

  6. #16
    Join Date
    Jul 2008
    Location
    Berlin, Germany
    Posts
    825

    Default

    I do think that the article is essentially correct, although it paints a picture that is slightly too gloomy.
    Quote Originally Posted by Kivada View Post
    Maybe, but there are those of us waiting for the unicorn. A high end Cortex-A15 device with a fast GPU that has docs released for all hardware and an unlocked bootloader that lets you erase the Androids/Chrome/whatever other crappy OS it comes with and install a real Linux.
    I expect that no Cortex-A15 ever will have public non-reverse-engineered GPU docs, because that would require a GPU vendor which actually releases docs. I don't think there are any on the ARM side of things. Maybe this will change if/when AMD produces ARM processors in the future, but they appear to go right for Cortex-A50, and ignore A15.
    Quote Originally Posted by ssvb View Post
    And for Mali400 GPU, I guess you have seen this: http://libv.livejournal.com/24735.html
    Yes, that post talks about having no short-term plans for a Mali DRM driver. So that's one area where you can forget about mainlining in the near future (unless the kernel driver from ARM enters mainline, which is very unlikely).

  7. #17
    Join Date
    Jan 2012
    Posts
    113

    Default

    Quote Originally Posted by chithanh View Post
    I do think that the article is essentially correct, although it paints a picture that is slightly too gloomy.
    Which part of it looks correct to you?

    Yes, that post talks about having no short-term plans for a Mali DRM driver. So that's one area where you can forget about mainlining in the near future (unless the kernel driver from ARM enters mainline, which is very unlikely).
    I think it's all about priorities. What's the point spending time rewriting the existing open source GPL kernel driver when there is still so much work to do in the userland driver part? And it's all open source, everyone is free to jump in and try his skills implementing a DRM driver.

    But keep in mind that CedarX VPU and Mali GPU are less important optional parts of the SoC and don't require immediate mainlining. You can run the system perfectly fine without these extras. The display controller and 2D hardware accelerator are documented (and have GPL drivers in the vendor code drop). You already have a usable desktop with no need for proprietary blobs. Just without 3D games and HD video playback.

  8. #18
    Join Date
    Jul 2008
    Location
    Berlin, Germany
    Posts
    825

    Default

    Quote Originally Posted by ssvb View Post
    Which part of it looks correct to you?
    As I said, essentially the whole article. The Fex part has been shown wrong, but does not change the general picture. Booting a mainline kernel on any Allwinner board will result in so many restrictions that it is useless for practical purposes. Hence the article rightfully decries the lack of mainline support.

    Quote Originally Posted by ssvb View Post
    it's all open source
    Quote Originally Posted by ssvb View Post
    no need for proprietary blobs
    Is all fine and dandy, but not the same as mainlining.
    Last edited by chithanh; 06-13-2013 at 04:40 PM. Reason: Add comment about Fex

  9. #19
    Join Date
    Feb 2008
    Posts
    114

    Default

    Quote Originally Posted by ssvb View Post
    Your Mele A2000 is a consumer product, which is coincidentally marketed as a freaking HTPC Just boot Android and use it for watching videos instead of launching XBMC. That is if you really don't care whether the player and underlying libraries are proprietary or free software.
    Sorry, I left out some important background info. I'm an egoistical bastard , and when I say "usable platform", I mean "platform usable for me". Now put that together with some really far-outlying requirements, and you can see that no commercial product meets them, at least AFAICT. I bought the A2000 because I expected the A10 hackables (Cubieboard, hackberry) to gain a lot of traction, following the same path as RPi. I thought of it as a supercharged Pi in a nice case and much better connectivity, rather than an HTPC product that met my needs. Still, the shortcomings proved greater than I expected - it's ridiculous that performance of the onboard Ethernet is worse than that of the WiFi, which only 802.11g, FFS.

    Quote Originally Posted by ssvb View Post
    By the way, have you already tried Allwinner A10 port of XBMC in Linux yourself?
    Not recently, no. I don't think it was available as a ready-to-try SD card image at the time (is it offfered now, at least?) and my attempts to build the image myself ended in failure. I did try the Linaro build, it did run, but without XBMC, it was not of much use.
    Quote Originally Posted by ssvb View Post
    Did you have bad experience with it or you are expecting to get bad experience based on various wiki pages and blogs?

    Do you mean show stopper bugs for the platform itself, which are not related to the proprietary GPU/VPU parts? Could you please provide some links?
    • As mentioned above, the poorly performing Ethernet is show-stopper for me. I have my media on a home server (currently served through NFS, so hooking up android would be a pain). Without the ability to set the buffer size (which is often small or zero in many players), I need to move at least 40 Mbps reliably.
    • Video output problems - many, many issues:
    • On Linaro, there seemed to be no way to configure the video output at runtime, to say nothing of output hotplug support. Has this changed?
    • In Android, while the modesetting did work, the UI and most of the video players was always rendered to 16:9/16:10 ratio, resulting in distorted picture on my old SXGA monitor. I found only 1 player that didn't distort the video, and that player had poor subtitle support.
    • In HDMI, I had the "black is purple" problem. I think this is caused by A2000 outputting YCbCr while the DVI-only monitor expects RGB (it certainly wasn't the cable - that works fine for RPi)

    Also, what links? These are my experiences, and would love to report them to relevant people/project, but I don't know where I should complain - do you know where I should report these issues?

    Quote Originally Posted by ssvb View Post
    The proprietary 3D GPU and VPU work, but are problematic. Just like they are problematic for every other ARM hardware. But at least for Allwinner A10/A13 we have fairly good chances to clean up this GPU and VPU mess via reverse engineering. I already provided CedarX VPU reverse engineering links in this topic. And for Mali400 GPU, I guess you have seen this: http://libv.livejournal.com/24735.html
    I wish the devs good luck. Here's a funny thing. On the RPi, good VPU support is essential as SW decoding is simply not going to work with the anemic CPU. The A10, OTOH, is powerful enough to SW-decode low-bitrate 480p, so I could live without VPU support for some time. But when even setting the display doesn't work, or preparing an SD-card image is a 15-step process, that barrier is bit high for me, given the motivation.

  10. #20
    Join Date
    Jan 2012
    Posts
    113

    Default

    Quote Originally Posted by chithanh View Post
    Booting a mainline kernel on any Allwinner board will result in so many restrictions that it is useless for practical purposes. Hence the article rightfully decries the lack of mainline support.
    You are contradicting yourself. If the board can boot a mainline kernel (with just initramfs or over network via nfs), then it has at least *some* mainline support already. And now please read the article again, where the emphasis is on "it's still unlikely that the patches will land upstream anytime soon". Guess what? The patches have already landed, more are expected to land in the near future, end of story.

    Just based on what I know, every paragraph is factually incorrect, except for the last one (about the linux distros currently using the non-mainline kernel based on vendor code drop). But appears that we agree to disagree
    Is all fine and dandy, but not the same as mainlining.
    Yes, please don't deviate from the main topic. It was you who started picking on the GPU support for some reason, but it's not really relevant to mainlining the essential peripherals of the SoC. Not to mention that the Mali GPU is not even Allwinner IP and it's silly to complain that they are not "mainlining" it.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •