Announcement

Collapse
No announcement yet.

Linux 5.5 Lands Broadcom BCM2711 / Raspberry Pi 4 Bits

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

  • Linux 5.5 Lands Broadcom BCM2711 / Raspberry Pi 4 Bits

    Phoronix: Linux 5.5 Lands Broadcom BCM2711 / Raspberry Pi 4 Bits

    Following last week's Arm architecture updates for Linux 5.5, sent in via four pull requests on Thursday was all the new and improved hardware enablement for the SoCs and single-board computer platforms...

    http://www.phoronix.com/scan.php?pag...5-ARM-Hardware

  • #2
    Le Potato already has the last media bits for VP9/H.265/H.264 upstream in Linux along with upstream u-boot. Raspberry Pi is still trying to figure how to undo their proprietary mess while still sticking to their proprietary mess.

    They could have saved everyone so much time and effort by not making every bit of their ecosystem proprietary. Linux for embedded would probably be light years ahead probably with working Chromium Ozone on Wayland.

    Comment


    • #3
      Originally posted by LoveRPi View Post
      Le Potato already has the last media bits for VP9/H.265/H.264 upstream in Linux along with upstream u-boot. Raspberry Pi is still trying to figure how to undo their proprietary mess while still sticking to their proprietary mess.

      They could have saved everyone so much time and effort by not making every bit of their ecosystem proprietary. Linux for embedded would probably be light years ahead probably with working Chromium Ozone on Wayland.
      And then you update your Wayland compositor and it doesn't work any more with your blob drivers due to missing GBM functions... (e.g. https://github.com/heiher/libmali-rk3399)

      As an alternative to Chromium, https://wpewebkit.org/ is an embedded-optimised WebKit with Wayland support.

      Comment


      • #4
        It is good that enablements are making it to the mainline kernel. It would be better if Broadcom (for the SoC), and the RPi foundation (for the board layout), pushed the enablements many months ahead of release (like some other vendors attempt to do) so that when device ships, the kernel is already ready.

        Comment


        • #5
          Originally posted by archsway View Post

          And then you update your Wayland compositor and it doesn't work any more with your blob drivers due to missing GBM functions... (e.g. https://github.com/heiher/libmali-rk3399)

          As an alternative to Chromium, https://wpewebkit.org/ is an embedded-optimised WebKit with Wayland support.
          Blob no more with Panfrost kernel driver in place and Mesa state tracker. Not many good reasons left to use libmali. Now distro's should just target GLES instead of GL for ARM64.

          Comment


          • #6
            Is support for the Rockchip RK3399 mainlined yet? Mali T860? Anyone know off the top of their heads?

            Comment


            • #7
              Originally posted by LoveRPi View Post
              Raspberry Pi is still trying to figure how to undo their proprietary mess while still sticking to their proprietary mess.

              They could have saved everyone so much time and effort by not making every bit of their ecosystem proprietary.
              The problem is, they released the Raspberry Pi in 2012 and back when they started the ARM opensource situation was rather dire. There wasn't *any* opensource solution available at all, and Eben Upton just picked up one of the many closed ones. Getting stuck into proprietary mess was the only existing option.

              Le Potato have a little bit more luck, they started their crowdfunding in 2017, at a time when they could pick Amlogic S905X and benefit from the work on Mali - thanks to the Lima reverse engineered driver started in five year earlier (and be then more or less functional already).

              (Same for the other SBC that went for Rockchip 3399 chipset and can benefit from the panfrost opensourcing efforts).

              Note that Raspberry Pi Foundation hasn't been twiddling their thumbs neither:

              GPU-wise, they have sponsored Eric Anholt, which eventually gave rise to the VC4 driver (enabling an opensource mesa solution for older RPi 1-3 on VideoCore IV) and V3D driver (available on the VideoCore VI based RPi 4 from release day).

              Architecture wise, they have shifted from a chipset (in RPi 1-3) where the GPU is in charge of bringing up everything (and thus having the same problem as smartphone with "Cell modem works as a northbridge and runs on proprietary blob") (Though Kristina Brooks has posted some minimal reverse engineered opensource firmware that can at least start the chipset in headless mode), to a architecture more typical of other board where the main CPU is responsible for bringing everything up and the GPU is only a peripheral. (If my understanding is correct).

              It's going to take some time, but they are on the right track. They just bet on the wrong proprietary horse and are facing a bit steeper challenge until opensourcing everything.

              Originally posted by LoveRPi View Post
              Blob no more with Panfrost kernel driver in place and Mesa state tracker. Not many good reasons left to use libmali. Now distro's should just target GLES instead of GL for ARM64.
              Or try to use gl4es until then ?

              Comment


              • #8
                Originally posted by browseria View Post
                Is support for the Rockchip RK3399 mainlined yet?
                Some has been in the kernel since the the mid 4-x days. But remember it is more than just the SoC, it is also the specific board layouts that utilize the chip, so you need to ask about a particular implementation to know the status (there are constantly new boards using the RK3399, and the kernel needs to get new (at least) device tree descriptions for those boards).
                Mali T860?
                The Panfrost driver was added back in 5.2

                In all cases these are works in progress, and may not support all the various features/peripherals that some proprietary driver may.

                Comment


                • #9
                  Originally posted by CommunityMember View Post
                  It is good that enablements are making it to the mainline kernel. It would be better if Broadcom (for the SoC), and the RPi foundation (for the board layout), pushed the enablements many months ahead of release
                  to push something you have to write it first. maybe they don't have enough manpower allocated

                  Comment


                  • #10
                    Originally posted by LoveRPi View Post
                    Le Potato already has the last media bits for VP9/H.265/H.264 upstream in Linux along with upstream u-boot.
                    how much of it was developed by amlogic? or to put it another way, why people are developing support for amlogic instead of developing support for broadcom?

                    Comment

                    Working...
                    X