5 ms·

It is a mischaracterization to say they have issues with the firmware, they clearly say they don't have the same objections to firmware running on the periphera

by throwaway2048 11y ago

It is a mischaracterization to say they have issues with the firmware, they clearly say they don't have the same objections to firmware running on the peripherals themselves. The issue here is that the rPI requires driver code running inside OpenBSD that is a closed source blob.

Bluerise 11y ago
I'm sorry, but that is wrong. The main blobs are being run on the GPU, as bootloaders, even before the actual operating system is loaded. OpenBSD does not need to run _any_ blob itself. There used to be a 3d graphics driver blob, but afaik that got open sourced. Also, if you don't do 3d, you wouldn't even need it.
- tedunangst 11y ago
  So, to summarize, if somebody makes a port that doesn't use a blob, all is good. The question seems to be not so much if the blob runs before or after OpenBSD, but whether we would need to distribute it. If it's in the ROM, then this isn't even a question. But if it's something we are expected to write to the flash drive, that's a potential problem. Anyway, the question isn't very interesting given that the magic porting elves haven't yet gifted us with an OpenBSD RPi port. I don't know exactly what the situation is. Don't care. I have a BeagleboneBlack if I wanted to watch the paint dry doing a build. :)
  - LukeShu 11y ago
    What's OpenBSD's policy on when something needs to be included? The rPi boot process requires several files to be on a FAT partition on an sd-card: bootcode.bin, fixup.dat, start.elf, config.txt and the OS kernel; the first 3 of which are blobs. Would those blobs need to be included, or would OpenBSD be fine saying "use your existing boot card, just drop in our kernel", or "go grab these files from https://github.com/raspberrypi/firmware/tree/master/boot https://github.com/raspberrypi/firmware/tree/master/boot when formatting the sd-card."?
    - tedunangst 11y ago
      If the blobs are preexisting that's less of a problem. But it also makes the hardware less interesting.
Narishma 11y ago
The blob runs on a different processor (the GPU), not inside OpenBSD.
- wolfgke 11y ago
  But the GPU has access to the RAM.
  - GauntletWizard 11y ago
    So does the Hard Disk; see https://en.wikipedia.org/wiki/Direct_memory_access https://en.wikipedia.org/wiki/Direct_memory_access
    - zurn 11y ago
      Depends on how your firmware or OS sets up the memory protection hardware; see https://en.wikipedia.org/wiki/IOMMU https://en.wikipedia.org/wiki/IOMMU
      - throwaway7767 11y ago
        The same applies to the GPU. The rPi does not have an IOMMU, but most platforms OpenBSD supports do not have one either. That said, based on other discussion here it seems this whole thread is a red-herring and there is no problem with the blobs, it's just that noone has written support for it.
        wolfgke 11y ago
        If OpenBSD delivers the blob as part of their OS, they take moral responsibility for it (which, for good reasons, they don't want to take). On the other hand, you don't have to deliver a blob to support, say, a hard disk.
        throwaway7767 11y ago
        I agree 100% with the stance of not distributing blobs. But you can put it on the user to provide it. A lot of linux distros have gone this route, if you want to boot debian on RPi you either need to create the FAT partition and put the blobs there yourself, or fetch a third-party image which includes them.
duaneb 11y ago
To my understanding, no distribution of a binary blob would be necessary. It is already flashed onto the raspberry pi. The original drivers are open source but not free, but it would be easy to at least get vga working.
- LukeShu 11y ago
  My knowledge is based on the rPi1, but cursory investigation suggests that this is also true on the rPi2: There are several blobs that are necessary to be on the sd-card for boot: bootcode.bin, fixup.dat, and start.elf. Any bootable sd-card image for the Pi has them. What's kind of interesting is that most of what start.elf is is actually an entire OS (ThreadX, I believe), that is running on the VC4 GPU in parallel to the OS on the ARM CPU; and that most of the Linux GPU drivers for it are just shims that send messages saying "hey, ThreadX, would you mind doing this for me?"
  - sklogic 11y ago
    The open source driver does not run on the VPU. And the bootloader had been reverse engineered (quite accurately, btw., although all the ISA mnemonics are totally made up). It should be possible now to rebuild it from assembly source.
  - david-given 11y ago
    My understanding of the boot process is that: - the VC4 starts up and a ROM starts executing - the ROM loads bootcode.bin into the SRAM - bootcode.bin sets up the DRAM and loads the start.elf and fixup.dat - the start.elf sets up the ARM core and loads the Linux kernel ARM code only starts executing at the last stage. The only bit that's actually necessary on the SD card is the bootcode.bin --- everything else is under the control of whatever's in there.

Bluerise 11y ago

I'm sorry, but that is wrong. The main blobs are being run on the GPU, as bootloaders, even before the actual operating system is loaded. OpenBSD does not need to run _any_ blob itself. There used to be a 3d graphics driver blob, but afaik that got open sourced. Also, if you don't do 3d, you wouldn't even need it.

tedunangst 11y ago
So, to summarize, if somebody makes a port that doesn't use a blob, all is good. The question seems to be not so much if the blob runs before or after OpenBSD, but whether we would need to distribute it. If it's in the ROM, then this isn't even a question. But if it's something we are expected to write to the flash drive, that's a potential problem. Anyway, the question isn't very interesting given that the magic porting elves haven't yet gifted us with an OpenBSD RPi port. I don't know exactly what the situation is. Don't care. I have a BeagleboneBlack if I wanted to watch the paint dry doing a build. :)
- LukeShu 11y ago
  What's OpenBSD's policy on when something needs to be included? The rPi boot process requires several files to be on a FAT partition on an sd-card: bootcode.bin, fixup.dat, start.elf, config.txt and the OS kernel; the first 3 of which are blobs. Would those blobs need to be included, or would OpenBSD be fine saying "use your existing boot card, just drop in our kernel", or "go grab these files from https://github.com/raspberrypi/firmware/tree/master/boot https://github.com/raspberrypi/firmware/tree/master/boot when formatting the sd-card."?
  - tedunangst 11y ago
    If the blobs are preexisting that's less of a problem. But it also makes the hardware less interesting.

Narishma 11y ago

The blob runs on a different processor (the GPU), not inside OpenBSD.

wolfgke 11y ago
But the GPU has access to the RAM.
- GauntletWizard 11y ago
  So does the Hard Disk; see https://en.wikipedia.org/wiki/Direct_memory_access https://en.wikipedia.org/wiki/Direct_memory_access
  - zurn 11y ago
    Depends on how your firmware or OS sets up the memory protection hardware; see https://en.wikipedia.org/wiki/IOMMU https://en.wikipedia.org/wiki/IOMMU
    - throwaway7767 11y ago
      The same applies to the GPU. The rPi does not have an IOMMU, but most platforms OpenBSD supports do not have one either. That said, based on other discussion here it seems this whole thread is a red-herring and there is no problem with the blobs, it's just that noone has written support for it.
      - wolfgke 11y ago
        If OpenBSD delivers the blob as part of their OS, they take moral responsibility for it (which, for good reasons, they don't want to take). On the other hand, you don't have to deliver a blob to support, say, a hard disk.
        throwaway7767 11y ago
        I agree 100% with the stance of not distributing blobs. But you can put it on the user to provide it. A lot of linux distros have gone this route, if you want to boot debian on RPi you either need to create the FAT partition and put the blobs there yourself, or fetch a third-party image which includes them.

duaneb 11y ago

To my understanding, no distribution of a binary blob would be necessary. It is already flashed onto the raspberry pi. The original drivers are open source but not free, but it would be easy to at least get vga working.

LukeShu 11y ago
My knowledge is based on the rPi1, but cursory investigation suggests that this is also true on the rPi2: There are several blobs that are necessary to be on the sd-card for boot: bootcode.bin, fixup.dat, and start.elf. Any bootable sd-card image for the Pi has them. What's kind of interesting is that most of what start.elf is is actually an entire OS (ThreadX, I believe), that is running on the VC4 GPU in parallel to the OS on the ARM CPU; and that most of the Linux GPU drivers for it are just shims that send messages saying "hey, ThreadX, would you mind doing this for me?"
- sklogic 11y ago
  The open source driver does not run on the VPU. And the bootloader had been reverse engineered (quite accurately, btw., although all the ISA mnemonics are totally made up). It should be possible now to rebuild it from assembly source.
- david-given 11y ago
  My understanding of the boot process is that: - the VC4 starts up and a ROM starts executing - the ROM loads bootcode.bin into the SRAM - bootcode.bin sets up the DRAM and loads the start.elf and fixup.dat - the start.elf sets up the ARM core and loads the Linux kernel ARM code only starts executing at the last stage. The only bit that's actually necessary on the SD card is the bootcode.bin --- everything else is under the control of whatever's in there.