Roadmap and Intel FSP

Hardware
1

Aye, I wanted to discuss the Roadmap a little bit:

image|234.5x250
image|234.5x250700×745 104 KB

Specifically:

Firmware Support Package (FSP) Freed

My understanding is that Purism still uses Intel FSP, yes?

https://puri.sm/posts/intel-fsp-reverse-engineering-finding-the-real-entry-point/

Is it possible for maybe @mladen to confirm this?

I generally, trust that Purism is honest and what not, but this seems like pretty wild?

I could understand how the “ME” being consdered “neutralized” could be mis-represented as “freed” but how is FSP?

Edit:
Archive of Post: https://archive.st/be0l

2

I think you read this wrong. While the diagram is outdated, it only says that “FSP freed” is one of the prerequisites of moving from coreboot to libreboot.

3

@Caliga is correct, this is the roadmap plan of our work. No one has freed the FSP yet, which is sadly still needed to build a BIOS. We use the HAP bit to (verified) disable the ME and we have worked pretty hard on identifying parts of the ME firmware to remove (so even if it would be enabled again it would be pretty dysfunctional). But still we have to use some binary blobs, I’m afraid. But we are continuing work on all of these fronts.

Cheers
nicole

4 Likes
4

@nicole.faerber, It would be helpful if Freedom Roadmap page on the web site was updated to show the difference between the Librem 13/15 and the Librem 5, because Purism is at different places on the Roadmap for the different products.

3 Likes
5

@nicole.faerber Another, rumor I’ve heard is that Purism would be sued and probably die if they tried to reverse engineer stuff like Intel FSP. My understanding is that this can be considered “computer tampering” an illegal offense. Is this true?

6

Also, have ya’ll considered joining the RISC-V Foundation.

It wouldn’t just be an awesome PR move, but ya’ll could help steer them towards free software.
https://riscv.org/membership-application/

@nicole.faerber @mladen

7

Intel probably has patents covering the code in the FSP, so that it could destroy Purism if it wanted to. A patent dispute in court costs about half a million dollars in legal fees.

For reverse engineering, you have one team that studies the product and writes a detailed description of what it does. Then another team which never looks at the original product, then takes that description and re-engineer it. If the FSP contains some kind of encryption or code obfuscation to hide its contents, Intel could also file a complaint with the US government that the first team is violating section 1201 of the Digital Millennium Copyright Act (DMCA) that says it is “unlawful to circumvent technological measures used to prevent unauthorized access to copyrighted works.” I have no idea how a court would view that, but making a successful argument in court would probably be expensive.

However, Intel won’t do any of these things, because attacking one of its customers who is buying its chips is simply bad business. Intel doesn’t care about Purism’s tiny number of orders, but it does care a lot about its Linux server business, which is why Intel is the largest contributor to the Linux kernel. If Intel attacked Purism, many of the companies that build Linux servers would switch to AMD and Intel would lose billions in revenue. All the work that Intel has done for the last 2 decades to establish itself as a Linux-friendly company would be flushed down the drain, if it attacked Purism, and it won’t want to hand that business to AMD.

Intel might have licensed some of the tech in the FSP, so it legally can’t share it, or it might not want its competitors to know how its CPU operates, but I can’t see Intel attacking Purism, when Intel is trying to keep the Linux server companies from switching to AMD and ARM CPUs, and trying to convince laptop makers to not switch to Snapdragon.

1 Like
8

What Purism wants to influence is the direction of SiFive, because it is reportedly 2 years away from producing a mobile SoC for smartphones with a RISC-V CPU. Faerber recently hinted that Purism is close to announcing something, and from the context of the post, it is probably an agreement with SiFive, regarding the open hardware CPU and GPU that SiFive is developing.

2 Likes
9

So, for the time being becoming a RISC-V foundation member IMHO does not make much sense for Purism. We are growing but yet too small to start any CPU development on our own and to my understanding this would be the point when becoming a foundation member would make sense. I sincerely hope to be able to this in the not too distant future.

Concerning SiFIve and the GPU development it is still to be seen if this will be an open GPU design or only an incorporation of a proprietary GPU core. SiFive is a company, they work on the open and free RISC-V ISA and foster free development around the core, but there is no statement or rule that prevents them from adding proprietary building blocks to new silicon designs. So all I’m saying here is, just because it is RISC-V based and/or coming from SiFive does not necessarily mean that it will be open and free. The announcement they had:


suggests to me that they will rather include the closed PowerVR GPU into a RISC-V design. Which is perfectly legal and valid, don’t get me wrong! But it is not what Purism would want.

November last year I briefly visited the RISC-V summit in Santa Clara (CA). The impression I got there is that a business eco system is now developing around the free RISC-V core design. But this eco system is to the most part again proprietary.

We have to see how RISC-V develops. Making chips is a very expensive enterprise, even if you have a free design to base on. Much more (about a magnitude or more) expensive than making consumer electronics. So I can very well understand that it needs a healthy business eco system around this technology to sustain the development. I sincerely hope though that silicon IP holders more and more recognize the huge benefits of open IP and release their stuff. Like in the software industry it needs redefining their current business models - you can have a successful business based on free software, why not based on free hardware (chip) designs?

Cheers
nicole

5 Likes
10

Whatever you’re up to regarding RISC-V and GPU, it would be dope if would use posits.
Probably wishful thinking, but it seems like posits instead of floats could compensate some of the shortcomings a new/non-mainstream design has.
New Approach Could Sink Floating Point Computation

11

It’s a bummer to hear that SiFive didn’t partner with Vivante for its GPUs.

OK, all we need to do is convince 5 million people to buy Librem devices, so Purism has the revenue to finance free hardware projects.

All we need to do is transform Todd Weaver into a supermodel and make him stutter like Elon Musk, so he can generate a ton of publicity. Or maybe we need to convince every Hollywood celebrity to carry around a Librem 5 to turn the Linux brick into a fashion statement. :wink:

4 Likes
12

@amosbatto the good news is that Purism isn’t labeled as an outcast yet.

You see this happen to many times, where a perfectly good products gets labeled for the wrong purpose. Or, get criticized under the wrong banner.

We don’t want to be labeled as “tin hat” folks. It murders any project.
Luckily, somehow Purism seems to have an amazing PR team.

I mean, they gained quick appearances on Digital Trends, reviewed by MakeUseOf, sponsor and now employer of Bryan Lunduke, Twit Channel, excellent ratings by TechRadar, Bootstrapping in America. TFiR, Monero Talk, World Crypto Network, Time News Tech, e.c.t.

Not sure how often Purism views these, but what I think would be awesome is if Purism could join free software boards like RISC-V, Linux Foundation, w3c, e.c.t.
It could be expensive, but for many of these they have lower plans at only a couple K.
Free software is not yet fully heard at these organizations.

1 Like
13

Ok, so think that through. Some hardware is created which uses POSITs instead of IEEE754. Now you need the software to be updated to use it, and that’s where, as far as a GPU is concerned, it all goes pear shaped.

Not only does GNU libm not have support for the POSIT data type, neither do any compilers. So you need to define special data types, and update libraries to cope with them.

Then you need to approach the 3D industry, and let them know that POSITs are better. However because none of the GPU Software Libraries use POSITs, it doesn’t help.

So instead, you have to contact the Khronos Group and convince them to add POSITs to the standards they manage: OpenGL, OpenCL, SPIRV and Vulkan.

Five to eight years down the line, that has been achieved. Vulkan now has POSITs, and so does the hardware. NVIDIA, AMD, Intel, they all have POSITs in hardware.

Now you need to convince Games Writers to actually redesign their shader engines to use POSITs!

At that point, some ten to twelve years since first starting, there will be a large enough customer base to justify the spend on a hardware POSIT ALU.

Sadly, then, POSITs being better than IEEE754 is just nowhere near enough. The software has to be in place as well, and given that IEEE754 is good enough and is entrenched into actual compiler datatypes, POSIT just does not stand a chance. Sorry to be the bearer of realistic news!

2 Likes
14

@lkcl, your reasoning assumes implicitely that the world will not change, that established technology will always be cheaper then the cost of deveploping and employing new things, that are in the long run cheaper.

Such predictions are almost always true.

They also have the downside of being, by definition, unable to predict the change.

Posits have one advantage over IEEE - they can allow to use 8-bit or 16-bit numbers and obtaing results on par with 32 and 64 IEEE calculations. And this in machine learning area, no less. If big tech can cut down their memory costs by half, or to 25% of what they are using now, they will invest in posits.

I say there will be no convincing anyone, just bulk order of new hardware from big tech and, if we are lucky, a bunch of patches for open source compiler to go with the new hardware.

1 Like
15

I admit I didn’t, but I was more on the wishful thinking side of things :wink:

Anyway, possibly it’s not as complicated as you make it. Of course, libs are needed

C algorithms for all of the math library functions will be an Addendum to the Posit Standard when it is completed. I already have most of the 16-bit functions done

Maybe it would be possible to add a compiler option that substitutes float types with posits (which will probably only work for code that doesn’t do any UB/dirty tricks), and when interfacing with non-posit libs, implicitly converts (which should be a comparatively cheap operation).

However, the question is, would conversion float<>posit be really needed often? The context here was a new CPU+GPU, so you have no legacy burden. CPU+GPU would only have native implementations for posits, but possibly can have very fast conversion ops, but only for compatibility if needed.

You could implement a standards compliant Vulkan library, which only serves as a wrapper for identical functions that have posits as parameters. But again, not sure if the compatibility is a hard requirement. It would be a completely independent architecture, without the requirement to be backwards compatible with proprietary software. Because that’s the only thing why you would need that.

It seems to be a similar problem as supporting little/big endian. In 99.999% of the code written it doesn’t even matter. Only when interfacing with the network or a file one needs to pay attention.
As said, no, I didn’t think that 100% through, but it does seem possible.

EDIT: @lkcl, forgive my ignorance, I had no clue who’s hiding behind that nickname. I totally understand there’s already an overwhelming amount of work to do, without the need to complicate things even more :wink:
I just dreamed a bit as this would be such an amazing opportunity.
The article states posits are “straightforward to implement in hardware”, which I read as “not more complex, possibly simpler than IEEE 754”. Together with the paragraph on quires, stating up to sixfold performance, I was wondering if an architecture that has only posit instructions, plus float<>posit conversion instructions would be able to achieve these goals:

  • compatibility to IEEE floats, plus smooth migration path
  • minor/no performance penalty for typical workloads, when working in compatibility mode (convert, mul-add, mul-add, mul-add, convert)
  • manageable effort to adapt the compiler
16

The Libre RISC-V doesn’t have to worry about supporting legacy tech, but Luke Leighton is trying to develop the Libre RISC-V for the lowest possible cost with the least amount of labor.

Leighton might be wrong in his predictions about how long it will take for posits to reach production and be supported by the software, but doing experimental design is not a good idea if the goal is to minimize costs and labor. Let the well-financed tech giants take the initial risks in proving posits and the community figure out how to write the software to support them. Only then is it a good idea for a free hardware project with very little funding to incorporate a new technology like posits in my opinion.

Look at how GNU HURD got derailed because they tried to do experimental kernel design, rather than sticking to a traditional design like Linux did. Linux wasn’t very good when it started, but it was able to iterate rapidly and attract more and more developers and companies, so it got much better over time. Hopefully the Libre RISC-V will follow a similar development path.

2 Likes
17

Yep these are all sensible replies, spot on. It is quite boring, run of the mill, just do something that meets existing standards, zzzz, right? :slight_smile: not very sexy at all, not like AI which is all the rage and guaranteed to get 7 figure VC funding, right?

Vulkan compliance unfortunately is just flat out unquestionably essential. Users cannot be expected to invest man years of redevelopment of custom shader engines JUST for a processor that isn’y even compliant with the Vulkan spec! Not to mention, Vulkan is Trademarked: nobody could use the word “Vulkan” if they used POSITs instead of IEEE754.

Performing conversions is also equally problematic. On balance it’s just too much of a risk, no matter how “good” POSITs really are.

If however the Khronos Group members adopt POSITs, because power consumption and gate count is so greatly reduced that it would be foolish not to provide the option, THEN we can revisit this one.

Or, if the success of the project was not critically linked to Vulkan (which remember provides OpenCL as well), we could seriously consider it.

1 Like