CPU Boards & Prices

[Revan]

Hello. I've been following the project for a while now, and am a frequent lurker on these boards.
I was wondering if there's any firm details on the hardware to be used on the upgrade boards? The Pyra truly is a wonderful device that I'd love to own, but I have a lot of economic concerns about obtaining one.
Given the cost of the unit itself compared with it being 2019 and the specs of the current SoC and RAM, I've been on the fence due to the comparably heavy workloads of just webpages nowadays, along with the kind of software one might wish to run on a UMPC. Given the thought and care given into planning every aspect of the Pyra, and its solid appearance, it looks every bit like a premium device.
Will the cost of the upgrade boards be around the same ballpark as the unit itself? half the cost? What are we talking here?

 

[pmprog]

That's impossible to say. It would unlikely cost a much as another machine, but it depends on the price of the soc used on the new board. But if nobody buys the machine with the omap, there won't be any upgrade boards anyway...

 

[levi]

ED once estimated that future prices for a new CPU board would be a fraction of the price of a full unit, although that was a long time ago now, and he might need to make more money back to cover his outgoings still, and it might not be as simple an operation to make as is currently estimated, and the CPU cost itself probably wasn't considered.

 

[Grench]

To the best of my knowledge there is no development ongoing for a "upgrade board". The device itself is capable of having the SoC, RAM and eMMC board user replaced though, which means some day, if enough of the units sell, an "upgrade board" becomes something that -might- be able to happen. Realistically, though, I think that any change to a different SoC is 3+ years out. More likely an "upgrade board" that maxes out the RAM and eMMC capabilities of the current SoC could theoretically happen a year or two out from release - which would maintain device compatibility. Much like the 1Ghz Pandora was an upgrade to the Rebirth Pandora which was an upgrade to the CC Pandora. Same SoC (essentially).

 

[everfresh]

I've been on the fence due to the comparably heavy workloads of just webpages nowadays

I was on the fence about this too, but I think it should be possible to make this a bit better with some software optimizations and lightening the GUI a bit. 4GB of RAM is actually plenty even among midrange smartphones today, and I would expect that it wouldn't be as much of a problem as you would think to load modern sites. Running a web browser is a single threaded process anyhow which is unaffected by the higher core counts of modern CPUs. I think that the performance in single threaded applications should be similar to that of a raspberry pi 3, based solely on reading the specs for the A15 core versus the A53 core. There are certainly things that this won't be good at, and I think in the future a new board is a good idea to allow the Pyra to keep up with modern application demands, but I think for now the fun of hobbyist devices like this one lies in making it do things that it was never meant to do with deep optimizations in software.

 

[Kev2442]

Considering @EvilDragon will most likely offer spare CPU boards for sale at some point after launch, its price would give us a rough idea of the retail price of an upgrade. But we'd still need to account for development costs and a potentially higher SoC base price, without even considering that we don't yet have a final price for the Pyra let alone it's CPU board.
The point is : it is too soon to reasonably talk about it, yet we have plenty of time to discuss it while waiting for the release

 

[Bosbeetle]

I think it is fair to say that because this is a small company and chip manufacturers are not the most keen on providing small batches you will never get bleeding edge chips on the pyra (even if we get a newer one that the omap5 it will be not the newest around). If having the most recent SoCs onboard is a must I think the pyra might not be for you. On the other hand I must say that the pandora even amazed me at the time compared to much newer SoCs in phones, and thats mainly because of linux vs andoid.

 

[ToastBucket]

I think it is fair to say that because this is a small company and chip manufacturers are not the most keen on providing small batches you will never get bleeding edge chips on the pyra (even if we get a newer one that the omap5 it will be not the newest around). If having the most recent SoCs onboard is a must I think the pyra might not be for you. On the other hand I must say that the pandora even amazed me at the time compared to much newer SoCs in phones, and thats mainly because of linux vs andoid.

Yes we will never get cutting edge SoCs. Ever. We will never get any SoC that you have seen in a phone in the last 5 years. It will honestly be at least 1-3 years before we will have access to any hardware that is anywhere close to current hardware seen in current phones and tablets.

That being said, I do have a couple points I want to raise. Process is not everything. The general argument here for an upgrade tends to be improved process or nothing. Yes improved process does have a major effect on power efficiency, but other things do as well. Improvements in the individual IP blocks within the SOC have a larger effect than they’re given credit in a lot of these arguments. I’m hoping I can do some performance tests to show this, but that depends on hardware availability.

Another big point is software support. A state of the art SOC is useless without quality software support. In my experience, these new phone SoCs have particularly poor software support from the vendor. The vendors will often provide very basic but incomplete software with poor documentation because the implementers are expected to work directly with the vendor engineers to provide correct implementation for their own product. I can personally attest to working with Qualcomm chips. Their software support is atrocious. Even if we were able to somehow source Qualcomm SoCs for the Pyra, they wouldn’t even give us the light of day when it comes to necessary information for proper software implementation. Beyond that, the current software that is provided is horrible and would take years to repair with our current resources even if we had the documentation we needed.

 

[benoitb]

I've said it before but a nice approach would be to use the Raspberry Pi compute module that is upgraded from time to time independantly from the Pyra project.
It's probably very hard to design around that hardware as well. When the Pyra was being designed I think there was only the 1st compute module available which was really underpowered. Nowadays it is better and I guess it will only improve as time passes.

 

[ToastBucket]

I've said it before but a nice approach would be to use the Raspberry Pi compute module that is upgraded from time to time independantly from the Pyra project.
It's probably very hard to design around that hardware as well. When the Pyra was being designed I think there was only the 1st compute module available which was really underpowered. Nowadays it is better and I guess it will only improve as time passes.

Not gonna happen. Closed source boot process, no access to reference manual, horrible power efficiency, unmodifiable form factor.

 

[levi]

Personally I think we have more change of getting a newer SoC when the initial pyra chassis is out in the wild. It's then easier to estimate how many you'll sell, and you'll have proven to suppliers that you can take a unit from design to retail, which technically at the moment is still a promise.

But I can't guess which SoC fabricators and sellers will be sufficiently convinced to sell to ED even then.

 

[Djoga'Ro]

But I can't guess which SoC fabricators and sellers will be sufficiently convinced to sell to ED even then.

What about those, that make it their business to let you order chips like you order at Subways and explicitly state, that they support small quantities? SiFive does that. And who knows, that may just the beginning of a market.

 

[oskda]

[QUOTE="everfresh, post: 1458488, member: 80787"I think that the performance in single threaded applications should be similar to that of a raspberry pi 3, based solely on reading the specs for the A15 core versus the A53 core.
[/QUOTE]

Cortex-A15 core is much more powerful than Cortex-A53 core (although this has 64 bit mode).

Cortex-A15 offers like 3.5 DMIPS/MHz per core, while Cortex-A53 offers like 2.3 DMIPS/MHz.

Cortex-A53 was lower/cheaper cores in 64 bit ARM (now they have other even lower).

PD: The only good thing is that Cortex-A53, as low CPU with in-order execution, is immune to Spectre bugs.

 

[Letalis Sonus]

PD: The only good thing is that Cortex-A53, as low CPU with in-order execution, is immune to Spectre bugs.

A CPU can provide more speculative action for Spectre-style exploits than just out-of-order execution, though. Some time ago someone posted a link to a branch prediction related bug of the Xbox 360 PowerPC CPU, which effectively performed malicious speculative execution despite being in-order.

 

[levi]

True, branch predictors can also sometimes be abused for speculative leaks of state.

 

[NutNut]

True, branch predictors can also sometimes be abused for speculative leaks of state.

I, for one, would not like my CPU to leak state secrets.

 

[oskda]

A CPU can provide more speculative action for Spectre-style exploits than just out-of-order execution, though. Some time ago someone posted a link to a branch prediction related bug of the Xbox 360 PowerPC CPU, which effectively performed malicious speculative execution despite being in-order.

You are totally right. Spectre is a vulnerability that affects CPUs performing branch prediction (associated with speculative execution).

In fact out-of-order doesn't imply speculative execution, nor branch prediction.

To correct my statement I must include "SOME": «some in-order execution CPUs are immune to Spectre. And ARM Cortex-A53», for example used in Raspberry Pi 3, is one of them

An interesting link I read a year or so ago: https://forum.level1techs.com/t/list-of-cpus-most-likely-immune-to-spectre/123128

 

[Swordfish II]

A CPU can provide more speculative action for Spectre-style exploits than just out-of-order execution, though. Some time ago someone posted a link to a branch prediction related bug of the Xbox 360 PowerPC CPU, which effectively performed malicious speculative execution despite being in-order.

Any potential for running homebrew on the 360? I am not very familiar with speculative execution/branch prediction

 

[levi]

You are totally right. Spectre is a vulnerability that affects CPUs performing branch prediction (associated with speculative execution).

In fact out-of-order doesn't imply speculative execution, nor branch prediction.

In my understanding of the situation, branch prediction in it's current implementation does imply speculative execution. Out-of-order just makes it somewhat more unpredictable and maybe more or less common; I'd need to see some examples of the situation it occurs in better to have a more precise understanding.

Edit: As I understand it, @Swordfish_II, speculative execution only lets secrets out of the cpu's exact behaviour, it won't let you implement your own instruction in any real sense, and therefore won't help with cracking systems for homebrew and giggles.

 

[oskda]

In my understanding of the situation, branch prediction in it's current implementation does imply speculative execution. Out-of-order just makes it somewhat more unpredictable and maybe more or less common; I'd need to see some examples of the situation it occurs in better to have a more precise understanding.

Branch prediction is always associated with speculative execution as far as I know (I tried to communicate that in sentence in brackets).