If this matured, maybe there would be some interest in porting OpenBSD to RPi with this? Theo didn't like the firmware blob, right?..
An openbsd port is already underway.
Minimal Raspberry Pi VPU firmware
11–20 of 62 posts
Re: Minimal Raspberry Pi VPU firmware
#12Earlier quoted context omitted.
The Raspberry Pi is really a VideoCore IV processor with an ARM bolted on the side. At power on, a boot ROM loads an embedded OS image into the VC4 processor. That then sets up the hardware, powers up the ARM, and loads the OS image into that . The VC4 then continues running in the background servicing RPCs from the ARM. What this is is a replacement VC4 operating system image which just fires up the ARM with an embe…
> The Raspberry Pi is really a VideoCore IV processor with an ARM bolted on the side. I knew that the bootloader worked that way but didn't think of it being that way until reading your comment. Interesting to think of the hierarchy that way. Naively this makes me think that the ARM ISA could use something like UEFI (or BIOS) to unify the devices' bootstrapping logic around some common metaphor.
Linux (and probably *BSD, not sure if they support it) can use devicetree files to configure itself for the hardware it's running on. No runtime firmware necessary.
Re: Minimal Raspberry Pi VPU firmware
#13What can one do with it? Is it like a bootloader? Sorry really not enough know-how.
It's basically like a BIOS on x86? The original is closed source, initializes the VideoCore chip?
Kinda, but with x86 the BIOS code is executed on the x86 processor itself and before that, the processor bootstraps itself. Here, the VideoCore processor (the GPU iiuc) is responsible for bootstrapping the CPU.
Re: Minimal Raspberry Pi VPU firmware
#14Earlier quoted context omitted.
The Raspberry Pi is really a VideoCore IV processor with an ARM bolted on the side. At power on, a boot ROM loads an embedded OS image into the VC4 processor. That then sets up the hardware, powers up the ARM, and loads the OS image into that . The VC4 then continues running in the background servicing RPCs from the ARM. What this is is a replacement VC4 operating system image which just fires up the ARM with an embe…
> The Raspberry Pi is really a VideoCore IV processor with an ARM bolted on the side. I knew that the bootloader worked that way but didn't think of it being that way until reading your comment. Interesting to think of the hierarchy that way. Naively this makes me think that the ARM ISA could use something like UEFI (or BIOS) to unify the devices' bootstrapping logic around some common metaphor.
Well, the ARM is literally powered down until the VC4 turns it on.
(I've heard that the only reason the ARM is there at all is that Broadcom had a royalty-free license and there was some spare silicon, so they thought, hey, why not, it might be useful...)
Traditionally ARMs have never used any kind of common boot process because they come out of the embedded world where every system is bespoke --- the focus is always on individual products, rather than building a platform.
There have been various efforts to fix this but AFAIAA they've never come to much. I think the current one is DeviceTree, but I don't believe there's much vendor support.
Re: Minimal Raspberry Pi VPU firmware
#15Earlier quoted context omitted.
The Raspberry Pi is really a VideoCore IV processor with an ARM bolted on the side. At power on, a boot ROM loads an embedded OS image into the VC4 processor. That then sets up the hardware, powers up the ARM, and loads the OS image into that . The VC4 then continues running in the background servicing RPCs from the ARM. What this is is a replacement VC4 operating system image which just fires up the ARM with an embe…
> The Raspberry Pi is really a VideoCore IV processor with an ARM bolted on the side. I knew that the bootloader worked that way but didn't think of it being that way until reading your comment. Interesting to think of the hierarchy that way. Naively this makes me think that the ARM ISA could use something like UEFI (or BIOS) to unify the devices' bootstrapping logic around some common metaphor.
The ARM world is rapidly moving towards UEFI, partly thanks to Microsoft insisting there be something like it for them to build on.
Even better, u-boot implements enough of it to boot a UEFI operating system. So on some new devices you'll get UEFI firmware, on everything else you can flash u-boot with UEFI support... and it's now part of their default configs.
Pretty cool. :-)
Re: Minimal Raspberry Pi VPU firmware
#16Earlier quoted context omitted.
It replaces the non-free binary blob on the Raspberry Pi that runs right after reset and initializes the processor. Modern complex processors require a specific and carefully orchestrated series of initialization steps to configure system clocks and ensure external RAM and other peripherals work correctly. Of course no one in their right mind would use this reverse-engineered code here for any serious purpose. Instea…
Do you know if there's one of these boards on the market that has: 1. A GPU 2. No binary blobs, no reverse engineering?
Intel GPUs require neither a blob nor reverse engineering, so ironically the Minnowboard (http://wiki.minnowboard.org/MinnowBoard_Wiki_Home; current revision is "Minnowboard Turbot") is very open (also the UEFI implementation (TianaCore) is open source; just a small FSP (Firmware Support Package) by Intel containing binary data has to be compiled in - as far as I know it contains no suspicious data; start at https://firmware.intel.com/projects/minnowboard-max if you want to read about the details). I am rather sure this processor/board has no support for the dreaded Intel AMT.
If you want an ARM board: The "Sabre Lite - i.MX6 Quad Core" board is the nearest to this ideal that I know of. Traditionally Freescale has been very open with the specifications (though after NXP bought them this changed to worse). The GPU (Vivante™ GC2000) is not strictly in the category "No binary blobs, no reverse engineering", but I have read that this is among the GPUs found on ARM boards by far the most easy one to reverse engineer, thus there seems to exist a decent reverse-engineered driver:
> https://en.wikipedia.org/w/index.php?title=Free_and_open-sou...
(EDIT: For the situation for open Vivante drivers also see https://www.phoronix.com/scan.php?page=news_item&px=Etnaviv-... (from https://news.ycombinator.com/item?id=12743550)).
Re: Minimal Raspberry Pi VPU firmware
#17Earlier quoted context omitted.
Do you know if there's one of these boards on the market that has: 1. A GPU 2. No binary blobs, no reverse engineering?
I think the Jetson TK1 from NVIDIA can run mainline Linux with most of the devices working.
I actually have one of those, but never investigated the bootloader situation for that platform.
And to get good use out of the GPU (one of the main selling points for this platform), you'll want to use the Nvidia proprietary driver.
Re: Minimal Raspberry Pi VPU firmware
#18Earlier quoted context omitted.
> The Raspberry Pi is really a VideoCore IV processor with an ARM bolted on the side. I knew that the bootloader worked that way but didn't think of it being that way until reading your comment. Interesting to think of the hierarchy that way. Naively this makes me think that the ARM ISA could use something like UEFI (or BIOS) to unify the devices' bootstrapping logic around some common metaphor.
Well, the ARM is literally powered down until the VC4 turns it on. (I've heard that the only reason the ARM is there at all is that Broadcom had a royalty-free license and there was some spare silicon, so they thought, hey, why not, it might be useful...) Traditionally ARMs have never used any kind of common boot process because they come out of the embedded world where every system is bespoke --- the focus is always…
> there was some spare silicon
I don't think such a thing exists. Aren't dies made as small as possible to increase yield? I know the Cell processor in the ps3 had a spare spe core to significantly increase yield.
Re: Minimal Raspberry Pi VPU firmware
#19Earlier quoted context omitted.
> The Raspberry Pi is really a VideoCore IV processor with an ARM bolted on the side. I knew that the bootloader worked that way but didn't think of it being that way until reading your comment. Interesting to think of the hierarchy that way. Naively this makes me think that the ARM ISA could use something like UEFI (or BIOS) to unify the devices' bootstrapping logic around some common metaphor.
Well, the ARM is literally powered down until the VC4 turns it on. (I've heard that the only reason the ARM is there at all is that Broadcom had a royalty-free license and there was some spare silicon, so they thought, hey, why not, it might be useful...) Traditionally ARMs have never used any kind of common boot process because they come out of the embedded world where every system is bespoke --- the focus is always…
> there was some spare silicon
I don't think such a thing exists. Aren't dies made as small as possible to increase yield? I know the Cell processor in the ps3 had a spare spe core to significantly increase yield.
Re: Minimal Raspberry Pi VPU firmware
#20Earlier quoted context omitted.
Do you know if there's one of these boards on the market that has: 1. A GPU 2. No binary blobs, no reverse engineering?
Intel GPUs require neither a blob nor reverse engineering, so ironically the Minnowboard ( http://wiki.minnowboard.org/MinnowBoard_Wiki_Home ; current revision is "Minnowboard Turbot") is very open (also the UEFI implementation (TianaCore) is open source; just a small FSP (Firmware Support Package) by Intel containing binary data has to be compiled in - as far as I know it contains no suspicious data; start at https:…
Looks like this Minnowboard is costly... looks like it cost about 200 dollars. :-/