41–50 of 51 posts
Earlier quoted context omitted.
I'm unfamiliar with that rebuttal, but it sounds like it has significance. Could someone explain it to me?
It signifies an unknown quantity, a string could be any length. I really don't like that saying at all.
The "enforced" binary blob really turns me off the Raspberry Pi. I bought a BeagleBone black as you can actually boot them without non-free software. Recently BeagleBone's GPU manufacturer Imagination Technologies made comments that the PowerVR chip https://www.reddit.com/r/hardware/comments/37h2a9/i_work_for... is planned to be open sourced.
If this happens I hope a lot more people will switch over to the BeagleBone rather than head in the direction of cheaper and cheaper closed ARM platforms. For me, the promising part of these single board ARM computers is that we may escape from running untrusted binaries and avoid things like Intel's Management Engine.
Earlier quoted context omitted.
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 t…
- 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.
Earlier quoted context omitted.
So does the Hard Disk; see https://en.wikipedia.org/wiki/Direct_memory_access
Depends on how your firmware or OS sets up the memory protection hardware; see https://en.wikipedia.org/wiki/IOMMU
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.
Earlier quoted context omitted.
Depends on how your firmware or OS sets up the memory protection hardware; see https://en.wikipedia.org/wiki/IOMMU
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.
Earlier quoted context omitted.
Depends on how your firmware or OS sets up the memory protection hardware; see https://en.wikipedia.org/wiki/IOMMU
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.
Earlier quoted context omitted.
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.
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.
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.
Earlier quoted context omitted.
I'm sure people have (tried to), but the problem is that, possible legal issues aside, the RPi is not a relatively standard and widespread system like the PC and Broadcom have not released much in the way of documentation. There's so much undocumented, and not enough people willing to go and analyse it all (unlike with the PC). Although PCs are becoming more closed and blobby with each new generation, the legacy of b…
> IBM released the PC with ... source code for the BIOS. Um, no they didn't. The BIOS was very much a blob. Compaq spent a significant amount of resources reverse-engineering the BIOS, which made the IBM-PC-compatible market possible.
Starts on page 337.
They did it for the AT too (page 161):
https://archive.org/details/bitsavers_ibmpcat150ferenceMar84...
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
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.
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.