Purism's Librem 5 To Rely On Secondary Processor For Binary Blobs

[rene]

PS: They further write: "To further separate the binary blobs from the A53 cores, we will add an SPI flash chip to store the firmware. The SPI flash will be read only so the firmware blobs can’t be modified without the user knowing."

Well I actually would rather have a regular binary blob that we can work on reversing, modifing and replacing in the long term, than a "separated" binary blog that I may not be able to remove, ever??? !!! PPS: well except maybe desoldering the flash, ..! ;-)

[vinly]

Seems like a lot of people think the blob for DRAM training is like a driver blob. But it's not. It's just a small part of the bootloader (uboot in this case). Linux doesn't care what piece of code trained the ram. And if the final phone ships only with that one blob, it'll still be 10 times more open than any modern x86 desktop. Do you guys remember that x86 boards have Intel ME/AMD PSP, huge UEFI blobs, and various blobs in all the periphery devices (GPU, HDD, etc)? Somebody compared this blob to AOSP, but there is a huge difference: you can't use the mainline kernel with AOSP phones. It would be huge if Librem manages just that alone.

For the record, there is no x86 board with open DDR4 training. For instance, coreboot has open-source training only for DDR3, and it's still not as good as blobs. For instance, my RAM sticks are unstable with coreboot's training. For the newer board, coreboot uses Intel-provided blobs which do much more than just DRAM training.

Anyway, DRAM training blob is the one of the least scary blobs. And it probably could be reverse engineered later. I'm more interested what will Purism do about the modem chip. Also, since they is no discrete hdd and gpu in the phone, I wonder whether there would be any blobs for storage and graphics.

[sverris]

Disappointing. Surely this is going to add to the complexity and cost. Seems like an incorrect decision.
Could the correct decision simply to be using DDR3?

This project should always favor freedom over performance. It mentions the training needs to be done each boot but why can the results not be stored?

Will be the same with DDR3, I suppose.
Solution? Broad efforts to dive into an open source DDR4 PHY training on the long run.

[wizard69]

Why do people get so worked over these things? Im willing to bet that most of the whinning here comes from people that couldn't write this low level code if they tried.

[numacross]

Will be the same with DDR3, I suppose.
Solution? Broad efforts to dive into an open source DDR4 PHY training on the long run.

There also is the issue of not all i.MX 8 models supporting all types of memory. Some support only DDR3L and LPDDR4 with no DDR4 while others do (LP)DDR4 with no DDR3L.

[kneekoo]

Bummer. I hoped this phone would be blob-free.

Why do people get so worked over these things? Im willing to bet that most of the whinning here comes from people that couldn't write this low level code if they tried.

There's nothing wrong wanting and willing to pay for a completely open hardware and software solution, even when you can't built it yourself.

[madscientist159]

Why do people get so worked over these things? Im willing to bet that most of the whinning here comes from people that couldn't write this low level code if they tried.

Whoa there....

Here's my code to do DDR3: https://review.coreboot.org/cgit/cor...mdfam10?ofs=30 DDR4 is in the same general class of complexity.

[madscientist159]

For the record, there is no x86 board with open DDR4 training.

True, but this is not an x86 phone, is it? Looking outside x86 yields at least the Talos II with open DDR4 training. DDR4 is still pretty new, over time there will be more controllers that come on the market. This was probably a financial decision more than anything else, judging from what is on the blog post.

[Kendji]

Pretty hardcore considering this is a solution the mainstream manufacturers won't ever do

[agd5f]

This isn't a binary that runs on the host processor. It's binary firmware that gets loaded into sram on the DDR PHY and runs on that. It's basically just changing who loads the firmware into the DDR PHY.