Announcement

Collapse
No announcement yet.

MSM DRM/KMS Driver For Snapdragon Progresses

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

  • MSM DRM/KMS Driver For Snapdragon Progresses

    Phoronix: MSM DRM/KMS Driver For Snapdragon Progresses

    Rob Clark has posted the second version of his MSM DRM driver, an open-source reverse-engineered kernel Direct Rendering Manager driver for Qualcomm's "Snapdragon" SoCs...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Is there any good and open GPU driver for ARM gadgets? I heard that the one for rpi was a joke.

    Comment


    • #3
      Originally posted by kaszak View Post
      Is there any good and open GPU driver for ARM gadgets? I heard that the one for rpi was a joke.
      Right now, adreno is the most functional w/ opensrc drivers, although your odds are still best with one of the variations of adreno that I have (a220 and a320).

      Looks like the etnaviv (vivante) folks are starting to get their gallium driver functional, so hopefully in the near future that is also an option.

      There isn't (yet) any within any support from the gpu vendor. Although hopefully that will eventually change.

      Comment


      • #4
        Originally posted by kaszak View Post
        Is there any good and open GPU driver for ARM gadgets? I heard that the one for rpi was a joke.
        Just thought I'd let the world know, for the last week I've been playing around with a couple of IFC6410 boards, they are very very nice boards, with APQ8064 (quad-core krait v2 + adreno 320), LVDS+HDMI output. Soon I'm going to start playing around with the freedreno stuff.

        Forget rpi. Not only are those units hopelessly underpowered, but as you're obviously aware, the open source driver is just a shim for their binary junk. I also am not impressed with the attitudes of those responsible for rpi, they get into flame wars with their customers on their forums. IFC is far more professional. The IFC boards cost a bit more than 4x the price of rpi, but you get about 1000x more for the money.

        Comment


        • #5
          Originally posted by droidhacker View Post
          Just thought I'd let the world know, for the last week I've been playing around with a couple of IFC6410 boards, they are very very nice boards, with APQ8064 (quad-core krait v2 + adreno 320), LVDS+HDMI output. Soon I'm going to start playing around with the freedreno stuff.

          Forget rpi. Not only are those units hopelessly underpowered, but as you're obviously aware, the open source driver is just a shim for their binary junk. I also am not impressed with the attitudes of those responsible for rpi, they get into flame wars with their customers on their forums. IFC is far more professional. The IFC boards cost a bit more than 4x the price of rpi, but you get about 1000x more for the money.
          I'm doing the drm driver work on an ifc6410.. very nice board. With SATA and gigabit-ethernet too. Quite a lot of kit for $150.

          fwiw, https://github.com/freedreno/freedreno/wiki/Ifc6410

          Comment


          • #6
            Originally posted by robclark View Post
            I'm doing the drm driver work on an ifc6410.. very nice board. With SATA and gigabit-ethernet too. Quite a lot of kit for $150.

            fwiw, https://github.com/freedreno/freedreno/wiki/Ifc6410
            Nice
            FYI in case you haven't figured this part out (and up until yesterday, the guys at IFC didn't even know this...)
            On the expansion header, short pin 25 (pm_gpio_38/vol-) --> 30 (GRD), then power up, and it boots into recovery. Short pin 26 (pm_gpio_35/vol+) --> 30, then power up, and it boots into fastboot. No need for a functional normal boot and adb reboot bootloader, which means that we can screw around with the boot partition and not brick the board.

            Comment


            • #7
              Originally posted by droidhacker View Post
              Nice
              FYI in case you haven't figured this part out (and up until yesterday, the guys at IFC didn't even know this...)
              On the expansion header, short pin 25 (pm_gpio_38/vol-) --> 30 (GRD), then power up, and it boots into recovery. Short pin 26 (pm_gpio_35/vol+) --> 30, then power up, and it boots into fastboot. No need for a functional normal boot and adb reboot bootloader, which means that we can screw around with the boot partition and not brick the board.
              heh, nice.. I just 'fastboot erase boot' to avoid it booting into android.

              Now what I *really* need to figure out is how to repartition eMMC to give it a larger boot partition. Since a real linux distro kernel + initrd won't fit in the default 10MB boot partition. Not a big deal at the moment, since I'm rebuilding the kernel constantly as I work on the drm/kms kernel bits, but it would be nice not to have to use fastboot to boot it each time when I'm working on userspace bits. But I'm really not an android/fastboot expert.

              Comment


              • #8
                Originally posted by robclark View Post
                heh, nice.. I just 'fastboot erase boot' to avoid it booting into android.

                Now what I *really* need to figure out is how to repartition eMMC to give it a larger boot partition. Since a real linux distro kernel + initrd won't fit in the default 10MB boot partition. Not a big deal at the moment, since I'm rebuilding the kernel constantly as I work on the drm/kms kernel bits, but it would be nice not to have to use fastboot to boot it each time when I'm working on userspace bits. But I'm really not an android/fastboot expert.
                I *think* that it should be possible to repartition it in the usual manner, however, I wouldn't really want to be doing that since if you break something there, there's no getting back from it.

                Best option for this, I believe, would be to stick another bootloader in place of the kernel in the boot.img, then you could just arrange the sdcard with a boot partition and the usual kernel and ramdisk files.

                Comment


                • #9
                  Huh, seems that littlekernel/aboot (mmcblk0p5) is open source and builds along with CAF.

                  Comment


                  • #10
                    Learning this board over the last week has been an interesting challenge. When I queried IFC yesterday about the boot selection switches on the board, they informed me that these referred to different sections of the eMMC. This actually contradicts the board's documentation.

                    From the schematics, SDC1 is the eMMC, SDC3 is the uSD, so positioning switch 1 to "on" will have the board boot straight off the uSD card, but fall back to the eMMC if the card is not present. The question now becomes how to prepare the card to be bootable?

                    Once we get through this, the issue is effectively solved, at least for installing OS externally.

                    Comment

                    Working...
                    X