There is a difference in "code that runs in the cpu of your hard drive" and "code running in your CPU to allow talking to the hard drive". >From what I recall, the RPI GPU stuff falls into the second category, whereas hard drives normally falls into the first.
One of them is just stuff that makes the drive work, and the other is what openbsd calls "a blob". You can't realistically prevent code from running inside the hard drive cpu (firmware loaded or not), and for most of the usage it just is how stuff is done today. What you can do realistically is to prevent untrusted binary code from running on the same cpu where your openbsd kernel runs, and that is where OpenBSD has drawn the line. 2015-02-02 16:43 GMT+01:00 Einfach Jemand <rru....@gmail.com>: > Am 02.02.2015 um 15:20 schrieb Janne Johansson: > > But it still requires a blob to actually run, does it not? > > > > The fact that there is docs for the blob isn't as important as being > forced > > to have someone elses code running alongside your kernel in order to even > > boot it, let alone produce graphics on it. > > > > > > 2015-02-02 13:47 GMT+01:00 Lampshade <lampsh...@poczta.fm>: > > > >> Hi > >> New version of Raspberry Pi is announced. Its SoC have four cores in > >> Cortex-A7 microarchitecture so it is compatible with ARMv7. It also > have 1 > >> GB of RAM. Have the same GPU as its predecessor: VideoCore IV 3d. For > some > >> time GPU have open documentation and open (BSD licence) driver in Linux > >> world. Price is still $35. It should be electrically compatible with > >> predecessor and have the same dimensions. > >> Are you going to support this hardware in OpenBSD? > >> > >> > > > > > > Hmm, isn't an "unknown blob" involved in every access to a hard-disc be > it spinning rust or SSD and the protocol involved ATA, SATA, SCSI or FC? > I haven't seen one disc yet where the firmware of the interface > controller was open sourced or even 'freely' documented. (Of course that > could simply be because I did not search hard enough to find one...) > > Or is this outside the scope since there is a well behaved (and > documented) programming interface that keeps you away for the internal > operations of the device? > > Sometimes for me the discussion of "libre hardware" seems moot - you > would have to start with sand and your own fab and thoroughly document > every step of designing and manufacturing a chip in order to get there. > > My 2 cents > rru > > -- May the most significant bit of your life be positive.
