Why has no one reverse engineered the boot blob on either Pi?
How long is a piece of string?
[deleted]
Raspberry Pi 2 Model B on OpenBSD
21–30 of 51 posts
Re: Raspberry Pi 2 Model B on OpenBSD
#22Why 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 believe) that's running on the VC4 GPU, in parallel with whatever OS you load on the ARM CPU. Of course, you wouldn't need to re-implement all of the OS, but it does make reverse-engineering harder.
The people working on this like to hang out at #raspberrypi-internals on Freenode.
(Disclaimer: the last I looked into this was in January, before the Raspberry Pi 2 came out)
Re: Raspberry Pi 2 Model B on OpenBSD
#23Why has no one reverse engineered the boot blob on either Pi?
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 backwards-compatibility means that a lot of things still work like they used to - in the days when documentation was far more open. IBM released the PC with full schematics and source code for the BIOS. The RPi was released with nothing more than its software and a few very incomplete datasheets.
Re: Raspberry Pi 2 Model B on OpenBSD
#24OpenBSD 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…
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.
Re: Raspberry Pi 2 Model B on OpenBSD
#25Earlier quoted context omitted.
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.
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?"
Re: Raspberry Pi 2 Model B on OpenBSD
#26It'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 un…
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 fu…
> 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)?
Re: Raspberry Pi 2 Model B on OpenBSD
#27Earlier quoted context omitted.
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.
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/raspberrypi/firmware/tree/master/boot when formatting the sd-card."?
Re: Raspberry Pi 2 Model B on OpenBSD
#28Why has no one reverse engineered the boot blob on either Pi?
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.
Re: Raspberry Pi 2 Model B on OpenBSD
#29Earlier quoted context omitted.
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 fu…
> 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 hand holding are also valid.)
Re: Raspberry Pi 2 Model B on OpenBSD
#30Earlier 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.
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