1. 39
  1.  

  2. 7

    Awesome! This seemed, at one point, to be one of those “it’ll be a cold day in hell before openBSD supports RaspberryPI”–what changed?

    1. 9

      @cr1901: WOW, that was unexpected. Why the change of heart?

      @phessler: there is no more binary blob required in the kernel, and now ppl care about armv7.

      https://twitter.com/phessler/status/762346582117326849

      1. 6

        I think the boot situation is a lot better now. OpenBSD uses UEFI, so the kernel on the ARMv7 is universal between each board supported on that port. It’s just a matter of loading the UEFI stub. I’m not sure if Broadcom’s firmware can do this directly (as Windows 10 runs on Pi, and it’s also ARM on UEFI) or if it’s using U-Boot (and presumably the firmware can handle it better) like the other boards.

        Graphics will be fun though.

        1. 4

          I have two of these devices sitting unused. I had ambitions of doing things with them that never happened. I am sure that installing openBSD on one of them is another, but one can dream!

        2. 4

          I would say it’s because there was nobody who wanted to invest time in it. No developer really cared about armv7. The requests to support the Raspberry Pi were just blocked with the “too many blobs” argument. There actually are blobs, but they are not kernel drivers. The blobs are run on the GPU, parallel to the CPU. They are loaded and run even before the CPU is turned on. So yeah, they are blobs, but it’s just firmware. Firmware is ok. Some time ago the 3D graphics stack actually had closed-source linux kernel drivers. Still, they were not needed to boot the device. Now the whole graphics stack is BSD-licensed anyway, so it’s all good.

        3. 3

          Very awesome. Good work guys.

          1. 2

            I am so looking forward to seeing this succeed!