Librem 7 phone with Intel N100 processor?

Larger device and larger battery … could make quite a heavy phone.

Also, given that the current design is based around a particular ARM chip, I don’t see going to Intel as an easy hardware change. (Conversely, while such a change might get greater commonality between the Librem 7 and the Librem 11, I don’t know that Purism did the design of the Librem 11, so adapting it may not be straightforward.)

Then there are the questions around blob status for any Intel CPU.

3 Likes

Intel N100 is a x86 CPU :confused: no thank you. (Intel ME)
I vote for the next Librem phone to use a RISK-V CPU. :smiley:

5 Likes

RISC-v indeed should be the only future possibility for hardware.

3 Likes

I would rather Purism continue their work on ARM64 than restart low-level development all over again for another several years.

5 Likes

I was thinking of this as an intermediate step to gain some money to help develop the librem eco system, so long as it didn’t mean too much effort.
I was under the impression that since the Juno tab 3 uses it (also many mini pcs) that Purism wouldn’t need to do much firmware work, is that not the case?

While I find Risc-V very cool, I’m not sure it’s ready to be used in a phone in terms of performance, I might be mistaken though.

1 Like

All x86 Intel CPU generations past Nahalem have various degrees of microcode (Intel ME) that increasingly become difficult to remove the more modern the generation is. The tradeoff of using x86 is user freedom to remove this microcode.

1 Like

A phone in general is less demanding of performance. Probably any of the three options being floated here (the current NXP ARM, Intel N100, RISC-V) would be adequate from a performance perspective. There are however so many other considerations.

Note that the Intel ME and the microcode are separate and unrelated things, although they might both be a problem from a strict perspective of blobware.

2 Likes

So you’re saying a current RISC-V CPU+GPU is as good as a current NXP ARM CPU+GPU, including power consumption?

2 Likes

No. I intended power consumption to be among those “other considerations”. My comment was strictly about CPU performance (speed). However you raise a good point about the associated GPU support and capability.

2 Likes

Power consumption is in direct relation to calculation performance. You can increase the calculation performance by 50% if it costs 100% more power consumption (random numbers - showing direction). But we need a good performance at low power consumption.

In additional, if you reduce the physical nm-size you can get more calculation performance with same consumption.

1 Like

Note that the Intel ME and the microcode are separate and unrelated things

Are you sure about that? I’m no firmware developer but, I am pretty sure we say “IntelME” to refer to the actual hardware inside the CPU (the CPU inside the CPU), that hardware needs code to run, that code is in the microcode. Not all microcode is for IntelME, I think it also does other things.

RISK-V is a long way off.

EDIT: Wellp, this is all wrong. @irvinewade is right. What runs on the IntelME is just called IntelME Firmware, and the microcode is what is translating and executing x86 CPU instructions. Sorry >.<

1 Like

Indeed. For that reason, if we are talking about a hypothetical successor to the Librem 5, I would rather that Purism stuck with the NXP ARM and just went with a die shrink when NXP releases a suitable successor to the Librem 5’s current CPU.

I acknowledge that you have updated your post … but the Intel ME is a separate CPU. So if you have a four core x86 CPU then you actually have five x86 cores in a manner of speaking. However that fifth core (the Intel ME) runs independently of the normal four cores, is not directly compatible with the other cores, may not be located in the same silicon, runs specific and unique firmware out of flash, and certainly can’t run your own software. However all of this is largely opaque i.e. serious security fail (security through obscurity), and not a great basis for any device where security not only has to be done but has to be seen to be done.

So, microcode runs on a (micro)CPU inside each of the normal cores, while the Intel ME runs alongside the normal cores.

I guess it is open to the Intel ME CPU to use (completely separate) microcode of its own. To be honest, I haven’t ever seen that question discussed but, again, it is all obscure-by-design.

Disclaimer: The above are generic comments about Intel x86 CPUs today. I didn’t check anything to be specifically correct for the Intel N100 and at a certain lower level of embedded system (system-on-chip) it may be desirable for Intel to adopt a different arrangement i.e. most people don’t need remote hardware management on a phone and the very thought of it should raise massive red flags.

2 Likes

Until a Risk-V CPU is at a competitive enough point. I hope we’re getting to this point rather sooner than later (even if my expectations a low for now).

2 Likes

My concern about RISC-V is more about Purism starting from scratch with a complete board redesign (whether for Intel or RISC-V) v. in the ideal case, a drop-in replacement NXP ARM CPU if one became available. Do they have the resources to start from scratch? Can it be financially justified? I suspect (with no actual knowledge) that a RISC-V Librem phone could only be done, in the future, by funding it from the sales of the existing phone and hence that’s where resources need to be deployed right now i.e. buffing off the rough edges of the existing phone.

3 Likes

Ideally they should stay on NXP until the software has a solid state. This is more important for the whole “mission” of spreading Linux phone devices - especially with non tech users in mind. The first big step is done, of cause, but you know, there is still work left over and it’s not enough that few people are working on Phosh. Even suspend is “experimental” - not to forget other lower priority things as camera and microphone API + front end stack.

I agree with you. My post is more an “on top” thing.

3 Likes

The 7-inch screen size and associated overall dimensions are enough to kill my interest. That’s getting into unwieldy, unpocketable tablet-territory, to say nothing of the added weight if Purism continues its isolation-of-components design goals (as already mentioned).

However, if Purism decides to manufacture it without excluding, say, a “Librem 4-to-4.5,” then more power to them, and to you.

EDIT: I wouldn’t mind the addition of some kind of magnifying software to the UI, though, since you mentioned improved visibility.

4 Likes

Thanks all for the helpful comments!
It seems this would be much more work than I expected, so not feasible unless Purism were approached by an OEM with a ready made design like the Librem 11, and even then.
I confess I’m trying to dream this device into reality.
I will keep an eye on projects like the pilet 7 and the HiGole F9B and see if their next gen becomes slimmer and bring sensors like fingerprint and nfc.

1 Like

Just saying: Purism will not release such products (as long as they do not change their politics). I know, you spoke about other projects - I just wanted to add this information.

3 Likes

3 posts were split to a new topic: Librem 5 battery

RISC-V is an officially supported architecture for Debian and has made huge strides in the last few years.

There are now many RISC-V processors available. I have a DeepComputing ROMA RISC-V Pad II tablet for a few weeks now. It has good performance and good battery life. It would be great to see next generation products from Purism with RISC-V processors. It is much more in line with their corporate philosophy as well.

Here’s the CPU that’s in it:

Happy hacking!

3 Likes