

Raspberry Pi 2 Model B on OpenBSD - justinwr
http://comments.gmane.org/gmane.os.openbsd.misc/219675

======
Bluerise
OpenBSD does not run on the rPi because there are only a handful developers
taking care of the arm subtree, and none of them have time for it or are
simply not interested. Heck, their whole arm subtree has been rotting and
needs some major overhaul.

The main components of the new rPi are rather simple to get to work, so it's
not a technical issue. The only real crapware inside is the usb controller.

I bet if someone supplied a diff they'd gladly take it. Also, I wonder why
this rather old post is up here.

~~~
ChuckMcM
Actually if you read the comments from the developers in that thread they
won't support it until there is documentation on the firmware "blobs" you need
to have in order to even boot.

I agree it is a fuzzy line but one which I happen to agree with.

There is a probably a thesis to be had for the first person to build a
provably trusted system using untrusted base hardware. I am not even sure how
you would start such a project.

~~~
throwaway2048
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
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
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
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
If the blobs are preexisting that's less of a problem. But it also makes the
hardware less interesting.

------
kbenson
It's hard from this thread to determine if the OpenBSD developers have a point
and are just expressing it unclearly, or if they are mistaken in some of their
assertions and are unwilling to event engage on the issue enough to learn
this.

The one time someone references a prior rPi discussion, it's to a message from
Theo De Raadt that says:

 _Wow. Dream on. It is a mess of firmware. You know nothing of our history?_

I understand maybe this has come up before and they are tired of the
discussion, but this is just toxic. Is it really so hard to just reference a
valid prior discussion when this comes up?

~~~
popalop
The OpenBSD mailing lists tend to be extremely Spartan.

The guidelines users are expected to learn before using them generally involve
(from most accepted to least accepted)

Read the mailing lists.

Read them again.

If you have a problem read the man pages.

If you still have a problem search the mailing lists for similar problems.

Make sure you really understand your problem then search again.

If after research you fully understand the problem but still don't have a
solution post to the specific mailing list with diagnostic info.

Consider writing up a bug report/ creating your own solution as necessary.

and way way down the list, in the has virtually never been the correct thing
to do category, is ask questions like "Will you support the RPi?" Those sort
of questions have been asked for essentially every piece of hardware and
subtechnology out there, and the answer is always either "No, because
propritery whatever but you're free to do the work yourself" or "No, because
we're busy and barely keeping the lights and servers on, but you're free to do
the work yourself" or "Yes, and you'd know that if you read the mailing
lists".

The mailing lists are famous for their get sh*t done attitude and any
information about posting on them will relay that to new users.

~~~
kbenson
> Read the mailing lists.

I would have a lot more sympathy for this point of view if they didn't fill
the mailing lists with replies on the topic that were extremely unhelpful.
Every reply that doesn't steer the poster towards a _useful_ prior discussion
or further the discussion in some way muddies the mailing list for future
searchers, leading to more questions on topics that have been covered before.
It's a self perpetuating cycle. Guess who has the power to stop it (or at
least prevent it from getting worse)?

~~~
popalop
That's a very valid approach.

OpenBSD has been like this since it's very turbulent beginnings. For better or
worse they prefer it this way (and it's bolstered by the lists having a
famously high signal to noise ratio).

For a team of their size with the resources available to them they've achived
a huge amount of success.

(Debates about whether they'd have larger success if they did a bit more of
what they would call hand holding are also valid.)

~~~
kbenson
Maybe the signal to noise ratio has gotten better, or maybe my recollection is
off, but I remember an excessive amount of bikeshedding circa 2006/2007 when I
was reading it heavily. I've always been highly impressed with the product,
but the mailing lists seem be unproductive, possibly _counterproductive_ , in
some instances, IMHO.

------
trengrj
The Free Software Foundation has a good resource here
[https://www.fsf.org/resources/hw/single-board-
computers](https://www.fsf.org/resources/hw/single-board-computers) on the
"relative" freedom of single board computers.

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...](https://www.reddit.com/r/hardware/comments/37h2a9/i_work_for_imagination_technologies_mips_powervr/)
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.

------
voltagex_
Why has no one reverse engineered the boot blob on either Pi?

~~~
wolfgke
How long is a piece of string?

~~~
joe_inferno
I'm unfamiliar with that rebuttal, but it sounds like it has significance.
Could someone explain it to me?

~~~
voltagex_
It signifies an unknown quantity, a string could be any length. I really don't
like that saying at all.

~~~
SmellyGeekBoy
Also, it doesn't really make sense in the context of the question anyway...

