On the upgradability of the Pyra


@Grench's ideas look great to me, especially the Pyramote and Parallel. But let's not divert ED's attention too much from the weakest point in the Pyra : it's CPU. Better make a more powerful device, then when it's good all around, we can think about diversifying the boards.
We can still come up with new stuff (I'm thinking of a NAS), but we should not try to produce them before we have a solid start in selling the original Pyra and conceiving its upgrades.
 
there were a few threads about cameras back in the day . consensus of opinion was the majority of users did not want one.
I'm not sure how that consensus was determined, but a small majority from years ago being against the camera does not mean that it would not be a cool upgrade.

My top 4 is:
- Camera
- More memory (e.g. internal, more SD slots, or SD slots supporting newer SD cards)
- Remove all ports and replace them with USB-C ports
- Other keyboard layout
 
imo, it's the GPU that's the weak point not the CPU. Lack of OpenGL ES3, Vulkan, or any realistic chance of open drivers are quite limiting, whereas the Cortex A15 still has plenty of raw power. Lack of ARM64 is a shame, but with a few exceptions it's easier to recompile software than make it work with an older GLES version.
 
Indeed, yet a better CPU would still be appreciated, especially for emulation. Let's face it, we won't have many games developed for the Pyra pushing its limits, most will be ports and emulators. And those like raw power, be it for accuracy or software rendering.
 
I don't think there is much point in pursuing anything that doesn't double the performance per watt of the existing while staying within the existing envelope. I.e. it is going to have to be something in the 10nm or maybe 14nm process space while still being something that this project can actually obtain and afford.

In the meantime, we actually have a heck of an SoC with nearly every connection it can provide -and then some really- exposed. Frankly, we haven't even seen the beginning of the start to what the existing SoC is capable of. Don't underestimate the power of a niche community in the quality of games and applications that can get created or ported.
 
I'm still rooting for the iMX8M :p. The A15 cores actually offer a lot of raw power, but the 8M gives us 4 A53s which offer similar to better performance than the A15s (need to get some metrics to back this up) and have the benefits of aarch64. The power threshold for these SOCs is also really quite good. https://www.nxp.com/docs/en/nxp/application-notes/AN12118.pdf. The dimensions of the chip are also similar to the OMAP5, though they are a little taller which may be a problem. Big benefit of this platform is existing and current kernel support from NXP. Any upgrade to the SOC board is a ways off though as the focus is definitely get the current one fully stabilized and as optimized as we can.

iMX8QM/P would also be quite awesome (A72x2+A53x4+GC7200x2) but the power threshold on these bad boys is likely to be way out of spec for what we are looking for. Power metrics haven't been released for these yet but the EVKs come with a big beefy heatsink and a fan so thats not a good sign...

I don't think there is much point in pursuing anything that doesn't double the performance per watt of the existing while staying within the existing envelope. I.e. it is going to have to be something in the 10nm or maybe 14nm process space while still being something that this project can actually obtain and afford.

Issue with using SOCs which are closer to state-of-the-art is part sourcing and manufacturer support. I've done work on some of these nicer SOCs (ie Snapdragon series) and they are near-impossible to source parts without an established relationship with manufacturer. You need to be purchasing very large quantities to even get a response from the sales team. The out-of-the-box software support is often very poor as well as they expect you to pay them to help you bring it up, rather than providing a fully featured and stable kernel. Additionally, getting access to the required documentation to implement this support is near-impossible and has a very high cost (I had no hardware documentation when I was working on it for a relatively large company. We had to reverse engineer a lot of the IP blocks). This route is really only worth it if you are expecting to ship units in the range of millions as the upfront cost of development is very high.

On the contrary, NXP's business model relies on accessibility and good out-of-the-box support. They sell in much smaller quantities and provide good support to provide a good platform for the littler guys like us. I could go on digikey right now and purchase a single iMX8 and download the technical reference manual, kernel, and necessary docs for free. And while the performance of the SOC I will get is not the absolute best on the market, it will be good enough for what I need to do and I will save a hell of a lot of time and money in development as I am starting from a very sold base.

The bottom line here is that a lot of the mobile processor market at the moment is based on getting the best specs and power metrics because thats what sells. A lot of this comes from marketing, but in practice this is partly due to the extremely inefficient nature of Android (the main target for these platforms). Android is about 70-80% Java code. While the JVM which it runs (Bionic/Dalvik) is highly optimized, you still have the majority of the OS frameworks running in a JVM (honestly these iMX series SOCs (excluding the 7, stay away from that one) run Android very well). On a device like the Pyra where the majority of the OS is based in well written C, we don't have anywhere near the need for the raw power these state-of-the-art SOCs provide. We can get very good performance out of a "weaker" SOC by properly leveraging the hardware acceleration the unit has to offer. While we would definitely benefit from the power threshold gains from SOCs built on a better process, from a business standpoint the cost of acquiring and using one of these SOCs is extreme in comparison. We would likely be looking at at least double the cost for a Pyra unit (plus longer development time as there is much more work to do and the software is developed purely on a volunteer basis) if ED could even swing sourcing any of these parts.

All this said, with @daveshah's work on the OpenGL stuff, the Pyra runs damn well on the OMAP5.
 
I sure hope they did a better job with these ones than with their automotive SoCs, because from my experience NXP produces a lot of seriously broken hardware designs.

Which ones are you referencing? I mostly have experience with the iMX platforms. Lots of experience on the iMX6 and some on the iMX8. The iMX7 was a total flop riddled with hardware issues, few use it.
 
While the iMX8M is undoubtedly the SoC of choice if designing something like a Pyra today, I just don't think it is worth upgrading to it today after all the effort that has been put into the OMAP, and the significant costs of fragmenting an already small user base.

Hopefully, by the time we start to seriously consider a new CPU board (say 2 years time), the iMX9 is out, at least vaguely stable and is an even more tempting option for everyone. Otherwise, by that point we will end up with another slightly-long-in-the-tooth SoC if we went with the i.MX8. While there are benefits to that it would be nice to have something a bit more shiny given all the downsides of an upgrade.
 
While the iMX8M is undoubtedly the SoC of choice if designing something like a Pyra today, I just don't think it is worth upgrading to it today after all the effort that has been put into the OMAP, and the significant costs of fragmenting an already small user base.

Hopefully, by the time we start to seriously consider a new CPU board (say 2 years time), the iMX9 is out, at least vaguely stable and is an even more tempting option for everyone. Otherwise, by that point we will end up with another slightly-long-in-the-tooth SoC if we went with the i.MX8. While there are benefits to that it would be nice to have something a bit more shiny given all the downsides of an upgrade.

Agreed. Though 2 years may be a bit short for an iMX9. They took quite a while to get the iMX8 out and rolling (still very fresh)
 
Which ones are you referencing? I mostly have experience with the iMX platforms. Lots of experience on the iMX6 and some on the iMX8. The iMX7 was a total flop riddled with hardware issues, few use it.
You won't find much public information about most of them, NXP usually prefers to keep their automotive SoCs mostly confidential - the whole respective category in DocStore is entirely hidden unless an employee explicitly unlocked you for one of the chips in it, therefore I'll only use explicit hardware references down below from which I know that at least some sort of public documentation exists.

One of the worst I've seen so far were their Calypso series (MPC5748G and related chips) and some sort of Frankenstein ARM chip with mostly PA-inherited peripherals, because the ARM IPs were apparently too expensive. They have a certain track record with broken timer implementations as well. Concerning PA in general, they totally botched it when they tried to make the old BookE architecture multi-core capable - there is no universal method to ensure atomic operations, memory reservations are totally broken across cores, even on recent chips. Several chips have a decorated storage memory controller than can be used instead, but even among the more recent multi-core chips are some that do not implement it. They did implement a SEMA42 module to provide hardware semaphores as an own solution for this, but they didn't even think about adding padding between semaphore registers to make sure that you can assign them to different memory regions due to the MPU alignment requirements (all of them only fit into a single region!), which is needed to ensure freedom from interference as requested by higher level ASIL certifications (ISO 26262). Coherent caches are a rare occurence on many SoCs as well, which is a PITA due to the fact that PA only has very limited cache control instructions available in user mode.

Among their older sins is the Leopard series (nowadays sold under the ST brand, e.g. SPC56EL). I don't want to know how cheap they pump out this ancient relict nowadays as even the Safety Manual of that thing is available publicly. It has an entirely broken NMI input that didn't even make it into the errata sheet in all these years, its PA core implements an MMU instead of an MPU whose alignment requirements are way too big for its tiny RAM to be useful for memory protection, and despite its slow core architecture it has its general purpose registers expanded to 64bit solely for an FPU extension, which makes context switches way too expensive to ever consider even using that extension. There is a surprisingly high chance of random failures when doing test runs on it as well. And that piece of crap is still being sold as ASIL-D certified for new projects.

As far as safety is concerned, I have yet to see anything that comes even close to Infineon's Tricore architecture. Yes, it's totally Kraut Space Magic that makes you question pretty much everything you know about microcontrollers, but they seriously nailed it.
 
Last edited:
There are other automotive SoCs too. But, I think picking this conversation back up in ~2 years feels about right. The Pyra, "as is", is a pretty awesome piece of kit. Lets get the most out of what, "is" before worrying about what, "is next".
 
When i saw the picture of the Adversive Heat Sink, i thought its may be a bit divicult to change the CPU Board ?? , or are these Heat Spreading Parts not that expensive, so whe could put one Mat in every CPU Upgrade Kit? ..
I mean: Open Up the Pyra should be that Easy as on the Pandora, so after you screw the Botton Part, you could pull the CPU Board of the Mainboard, but how to deal whit the Heat Spreading Material ?
 
When i saw the picture of the Adversive Heat Sink, i thought its may be a bit divicult to change the CPU Board ?? , or are these Heat Spreading Parts not that expensive, so whe could put one Mat in every CPU Upgrade Kit? ..
I mean: Open Up the Pyra should be that Easy as on the Pandora, so after you screw the Botton Part, you could pull the CPU Board of the Mainboard, but how to deal whit the Heat Spreading Material ?

Peel it off and put a new one on when you put in the upgrade? It won't be a real question for a few -years- still, so, not really something to worry about.
 
But ditnt i also peel up the electronic parts if i remove the adhisive,? At least they only stick on the board because of the soldering ..

I dont think i would need to change my CPU Board as i want to get used to it , i know it cant run fly simulator 2020
 
But ditnt i also peel up the electronic parts if i remove the adhisive,? At least they only stick on the board because of the soldering ..

I dont think i would need to change my CPU Board as i want to get used to it , i know it cant run fly simulator 2020

You need to be pretty damn aggressive with the thing to break it that way. Any adhesive between the heat spreader and the components will not be strong enough to rip the components out of their solder joints. Removing the CPU board is easy and safe (granted I haven't used the new heat spreaders, but can't imagine they make it much more difficult). Best to use a plastic spudger to gently but firmly pop the board out of the connector one side at a time, but if you trust yourself and are willing to take the risk you can just user your fingers.
 
I'd like to imagine if we ever get an upgrade board, there'd be an optional upgrade service as well if you don't feel confident to do it yourself. The store has an entire section dedicated to repair and upgrade services already after all.
 
Back
Top