Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Raspberry Pi 2 Model B on OpenBSD

comments.gmane.org

Post reply on HN
Print view View original

31–40 of 51 posts

Re: Raspberry Pi 2 Model B on OpenBSD

#31

Post by kbenson »

popalop wrote: post #29
kbenson wrote: post #26

Earlier quoted context omitted.

> 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 per…

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…

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.

Re: Raspberry Pi 2 Model B on OpenBSD

#34

Post by ghshephard »

tagrun wrote: post #24
ChuckMcM wrote: post #3

Earlier quoted context omitted.

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…

They seem OK with BIOS, Intel microcode and other firmware on amd64 though.

They don't have to distribute it.

Re: Raspberry Pi 2 Model B on OpenBSD

#35

Post by tedunangst »

LukeShu wrote: post #27
tedunangst wrote: post #18

Earlier quoted context omitted.

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 por…

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…

If the blobs are preexisting that's less of a problem. But it also makes the hardware less interesting.

Re: Raspberry Pi 2 Model B on OpenBSD

#36

Post by LukeShu »

protomyth wrote: post #30
LukeShu wrote: post #28

Earlier quoted context omitted.

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

You're right that Compaq went to a lot of reverse engineering effort, userbinator is also right about IBM releasing the source code for their BIOS. They did it to prevent reverse engineering by tainting anyone exposed to the code. https://en.m.wikipedia.org/wiki/Phoenix_Technologies

Huh, I didn't know that. Thanks!

Re: Raspberry Pi 2 Model B on OpenBSD

#37

Post by voltagex_ »

joe_inferno wrote: post #20
wolfgke wrote: post #16

Earlier quoted context omitted.

How long is a piece of string?

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.

Re: Raspberry Pi 2 Model B on OpenBSD

#38

Post by zurn »

GauntletWizard wrote: post #17
wolfgke wrote: post #15

Earlier quoted context omitted.

But the GPU has access to the RAM.

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

Re: Raspberry Pi 2 Model B on OpenBSD

#39

Post by sklogic »

LukeShu wrote: post #25
duaneb wrote: post #11

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

Re: Raspberry Pi 2 Model B on OpenBSD

#40

Post by sklogic »

LukeShu wrote: post #22
voltagex_ wrote: post #14

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

People are working on it. The biggest challenge is that it isn't "let's reverse engineer this ARM blob"--they have to reverse engineer the entire (VC4) architecture, and write an assembler for it. Most people think of the rPi as an ARM board; it's more helpful to think of it as a VideoCore IV board with an ARM co-processor tacked on. The stock "boot blob" isn't just a boot blob--it's actually an entire OS (ThreadX, I…

It's not VC4 GPU, which is fully documented and fairly open. The bootloader runs on VPU, for which the reverse engineering is the only option, because there were no resources for doing anything sane with the official internal docs, when I checked last time. And Broadcom does not even own a compiler for this ISA. So, people had been officially encouraged to reverse engineer it.
Post reply on HN