Hacker News Reader

Comment by davexunit | Hacker News Reader

This is a step in the right direction. Does this mean that the RaspberryPi can run blob-free now or with one less blob? I don't know what else is needed for the SoC to operate.

View on HN

Not quite yet. We're hoping to be able to provide a minimum-functionality blobless world fairly soon.

I think this is another example of how Raspberry Pi Foundation's decision not to move forward with a gazillion different boards, but rather to stick with A and B and let the software evolve, was a good one.

I'm very excited to see what the next year brings.

Yea with this happening I think what I would love is a bit more cpu power on the pi. Not even the new 64bit arm cores or anything but an A-15 or A-9 at double the MHz of the existing PI would put it in a huge sweetspot for embedded performance and make it far more usable for a desktop (with ideally more ram too but that's always good).

It sounds like you really want a TI Pandaboard or maybe even one of the Intel SoCs...

To be fair, the Pi opened the floodgates in terms of ARM boards; there are now loads of them.. not $25 but nothing like the insane pre-pi prices. The beaglebone black from TI is a good step up: 1Ghz A8 (~2x rPi performance), 1GB ram, $45. They don't really need to segment themselves (yet), as others can fill in the gaps.

Different development boards (like the Beaglebone Black) are already more open, but get much less attention. The Raspberry Pi has an enormous amount of mindshare, but they've been doing a pretty poor job until now of shifting the status quo of this industry.

Are you able to give any indication what might be included (or not) in such minimum functionality?

The ability to boot a kernel with USB (and thus Ethernet) running. Probably not display in the first instance (we're hella-resource-constrained), but we'd want to add that later on.

From the article -

"This isn’t the end of the road for us: there are still significant parts of the multimedia hardware on BCM2835 which are only accessible via the blob."

Ah, thanks. Poor reading comprehension on my part.

Will running without relying on blobs mean that processing can be further optimised or is it more of a moral victory than a technical progression.

I'm assuming doing away with the shim means that there is some gain but in practical terms is it likely to be quite minimal? Will there be routines accessible that weren't accessible via the shim?

More a moral victory from my PoV. Remember, code that runs in the blob is running on another processor, so not costing you ARM cycles. That's why we've set the Quake fps target much lower than what you can hit with the blob.

Thanks for all the effort to get to this stage Eben. As someone who was repeatedly told (on the RP forums) that I had no business to desire the user-land graphics to be open-sourced, and that only hardware engineers would get any benefit from this code, I thought this day would never come!

I'm happy to be proved wrong, and happy that many little 'RasPis' will have an extended lifespan from this decision by your employer. :-)

Fingers crossed. I'm most excited about the GPGPU stuff people will be able to do now we've documented the instruction set for the QPU. More on this next week.

Reply on news.ycombinator.com