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