Announcement

Collapse
No announcement yet.

Allwinner SoC Still Unlikely For Upstream Linux Kernel

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    I do think that the article is essentially correct, although it paints a picture that is slightly too gloomy.
    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.
    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).

    Comment


    • #17
      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.

      Comment


      • #18
        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.

        Originally posted by ssvb View Post
        it's all open source
        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, 04:40 PM. Reason: Add comment about Fex

        Comment


        • #19
          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.

          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.
          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?

          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.

          Comment


          • #20
            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.

            Comment


            • #21
              Originally posted by myxal View Post
              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.
              I compiled XBMC in debian chroot by just typing the build commands from the wiki. This does not seem to be too difficult, except that native compilation is a bit slow on this hardware. I think I have seen links to bootable SD card images with XBMC in the mailing list or somewhere else.

              • 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.
              The problem is that the ethernet is sometimes sporadically gets initialized to "10Mbps, half-duplex" mode after reboot. I'm using the udelay workaround from the first post in the following thread: https://groups.google.com/d/topic/li...0ck/discussion
              Seems to work fine for me, and I'm a heavy ethernet user myself (nfs root). The general consensus is that this is a hack and not a real fix, some people are using other tweaks with or without success. Somebody just needs to get really annoyed by this issue and properly debug it.

              • 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)
              You could always try the latest kernel and check whether the issue is still there. If it still does not work the way you expect it to work, then please report the issue with enough details to reproduce it. I'm just not using the monitor hotplug feature (my monitor is always plugged) and have no idea at the moment. Maybe some other people can help.

              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?
              http://linux-sunxi.org/sunxi:Community_portal

              Comment

              Working...
              X