On 2015-02-02, Janne Johansson <icepic...@gmail.com> wrote: > But it still requires a blob to actually run, does it not?
Not sure... It's no different on the 2 than the original pi (same GPU/boot mechanism), but there is a project https://github.com/jncronin/rpi-boot which claims to be an alternative second-stage so perhaps it's possible that way.. First-stage bootloader is pre-programmed on the board. It loads the second- stage from SD card to the GPU and starts it. Second-stage bootloader runs on the gpu and loads start.elf (3rd stage) which contains gpu "firmware" (actually an RTOS which stays running) and which boots the main cpu. The RTOS has a message passing interface used for GPU access from the main OS, so one area of concern is how that handles malicious inputs. It sets up a memory split between GPU/CPU at boot but it's unclear how this is protected if at all; one important question is whether the code running on the GPU can access CPU memory after boot. There are scary things on common x86 systems too of course (network-accessible management processors running crappy software sitting on the same i2c bus as the EEPROM containing the BIOS; a payload inserted to code running in SMM would have a lot of access ...) For all of the posts with people asking about OpenBSD on the rpi I don't think I've seen a single one along the lines of "I've done x and y (see this diff) but am stuck on getting z to work", I only remember ones that are more like "can somebody port OpenBSD to the rpi for me". (Hint: if somebody is willing/ able/interested/stubborn enough to do this, posts like that will be totally off the radar).
