Future of the CPU board?


That depends on how you define 'pyra-like'. Two full sized SD card slots? Highly unlikely. Game controls and a keyboard? Uncommon. 4G comms included? Still uncommon in the 'powered by a Pi' space.
 
Also very very unlikely getting any Pi SOC to boot with custom hardware. They are very closed source (RPi foundation keeps it that way) and extra effort into making sure the BSP can’t be repurposed. I’m not sure about the 4, but previous RPis use an obfuscated boot process involving the GPU in order to make it difficult to modify and customize. https://raspberrypi.stackexchange.com/questions/10442/what-is-the-boot-sequence

Let alone sourcing the SOCs, RPi foundation and Broadcom have a tight relationship preventing RPi SOCs from being sold to anyone else. I’m not sure if the case dimensions, but from what I’ve seen I don’t think a compute module + adapter board would fit in the Pyra.
[doublepost=1566403656,1566403383][/doublepost]
Grench said:
Especially when you can cherry pick a specific set of conditions for which the 'new' has a special trick to be faster - and not give any detail as to what was actually running for this, likely highly selective to their favor, "same workloads" 'test'.
Click to expand...

This is nothing new as well. Manufacturers have been doing this with processor benchmarks for decades (and in a some cases lying about them ie Pentium 4).
 
Also The Pi4 SoC module while small, it's surprisingly tall due to the lidded package it uses. I need to measure it, but I say it may be as thick as the OMAP5 and the Pyra SoC module board combined. The SODIMM package of the Compute module also takes a bit of real estate, so likely compromises in features would be needed to entertain using it.
 
The iMX8QM/P (A72+A53+GC7000) should be released pretty soon. Checking digikey, it looks like the price point for this SOC will be around $120, over double the cost of an iMX8MQ (A53+GC7000Lite). There is a raspberry Pi-esque board using an 8MQ which I may pick up to see how the performance compares to the OMAP5 once most of the urgent repairs are done in our BSP.

http://www.embest-tech.com/prod_view.aspx?TypeId=117&Id=388&Fid=t3:117:3
 
ToastBucket said:
The iMX8QM/P (A72+A53+GC7000) should be released pretty soon. Checking digikey, it looks like the price point for this SOC will be around $120, over double the cost of an iMX8MQ (A53+GC7000Lite). There is a raspberry Pi-esque board using an 8MQ which I may pick up to see how the performance compares to the OMAP5 once most of the urgent repairs are done in our BSP.

http://www.embest-tech.com/prod_view.aspx?TypeId=117&Id=388&Fid=t3:117:3
Click to expand...

I scanned around a bit and couldn't figure out the dimensions of the SoC or what lithography scale/process is used to make it or anything that would indicate relative performance per Watt. Do you have additional info on it?

levi said:
Support for GL/ES3.1 and apparently actual GL3.0 sounds like a step up to me, but I don't know at what thermal cost that all banks in.
Click to expand...

Pretty much any modern SoC we can count on needing to underclock it to our thermal envelope in order to have consistent performance. So, a big question is, "Will it run if throttled to the point where it is only burning 3W?"
 
From what I’ve read, the iMX8M SBC operates around 2.5W (compared to RPi 3 SOC with similar cores running at 6W). Not sure yet what kind of throttling is involved. It’s still made with a 28nm process, but finding an accessible SOC with recent/competitive cores at an improved process will be difficult. I’ll work on getting more information on this SOC and in particular the 8QM. Pretty soon I should be getting access to an iMX8QM EVK which I may be able to play with and run some benchmarks. The Avnet SBC is at least a cheap way to check out how the 8M compares to the OMAP5.

Here is a comparison of the 8MQ SBC and the RPi 3 to be taken with a grain of salt until verified.
MaaXBoard-vs-Raspberry-Pi-3-Model-B.jpg
 
Last edited:
I still think that we are a long ways from even considering a different SoC. General performance per Watt is pretty closely tied to the lithography process used in creating it. A new SoC should have at least double the performance of the existing one to have any chance to make the work required to do it "worth it".

Pyra OMAP5432 with 4GB & 32GB needs to sell well first.
Pyra OMAP5432 "Maxed" with max possible RAM (8GB?) and max possible eMMC (256GB?) would be a nICE HIGH $$$ up sell item to consider in 1.5 to 2 years after launch.
An entirely new SoC... we are at least 2 years from picking one and likely 3 years from it happening.
 
Bit late to the Pyra party here, hi everyone! I've been interested casually in the project for a few years now but I'm only just thinking of getting more involved with it. I'll likely be placing my pre-order soon. Now is a really exciting time to be a portable Linux device enthusiast, and it would be a shame to miss out on something this cool. :cool:

Has ED made any indication that he plans to open up the schematics for the CPU board? This might make it easier for community members to collaborate on building the next generation. Personally I would be excited to try something like the i.MX8M Quad in this machine. Even though the OMAP5 is sufficient for today's usage, its age leads me to believe that it won't be particularly useful for modern web applications in a few years, which to me is important since I am looking at the Pyra as a replacement for several of my devices long-term. I think whether you think that the OMAP5 is sufficient for today or not it is important to look to the future for a device like this. Even if he didn't open the schematic for the board, it would be helpful to have some data on the connector type, mechanical dimensions, and pinouts for the board so that we can build our own that works in this system.

Someone early in this thread mentioned FPGA-related systems design. Having some experience in this it would be really cool to include a small FPGA as a coprocessor system on the CPU board, we could even provide some kind of extended functionality like hardware acceleration for certain emulators, some kind of improved fast graphics, or other peripheral systems. It also allows us to provide on-the-fly hardware updates in addition to software updates. This of course comes at part cost, which is high for even small FPGAs. Even the iCE40 series from Lattice (which has a FOSS toolchain by the way :confused:) can get somewhat expensive.

These are just things I was thinking about while reading this thread, I am definitely interested in contributing to this design if we want to do it as a community or if the team themselves are looking for someone to help out on next-gen designs.
 
TrashyMG said:
Electrical schematics yes
Click to expand...

Ah yes, this is the type of thing I was looking for. With the pinout it should be possible to design something pin compatible with the main board, of course software is another story entirely. That said since all of the peripherals are on the main board anyway it would be a matter of ensuring that the drivers run well on the new SoC, not sourcing new drivers for new hardware and ensuring that they work on the new SoC.

Is there interest in the community for doing something like this? People seem confident in the current setup for current regular usage (smartphone style regular usage, like loading modern websites etc.), so maybe it isn't a high priority for people over getting their devices in the first place. That said, the development of something like this takes a very long time and it wouldn't be a bad idea to start early.
 
Yes I agree. Designing a new CPU board is a significantly smaller undertaking compared to the previous tasks of CPU board, mainboard, and display board. So I disagree with the 3 year timeline of designing this board. Hardware and basic software support should be doable in under a year. However, I’m assuming a separate kernel, full integration of the new SOC into our kernel would be a little bit of work.

Also the amount of software work changes significantly depending on the hardware chosen. From my experience, working with the iMX8 family is the path of least resistance software wise. I have done board bringup on iMX8MQ based platforms in the past and it has very good support. Many other vendors have proven to have significantly worse software support (poorly written kernel code that needs to be rewritten, etc).
 
Yes. Since we have this option available to us now it may be the time to start taking advantage of it while the support is readily available from the manufacturer.

ToastBucket said:
However, I’m assuming a separate kernel, full integration of the new SOC into our kernel would be a little bit of work.
Click to expand...

What do you percieve as the major hurdles with porting the current Pyra kernel to the iMX8MQ? Having toyed with some kernel and bare-metal code myself I wouldn't be opposed to trying to make time for this if we want to get it off the ground.
 
everfresh said:
What do you percieve as the major hurdles with porting the current Pyra kernel to the iMX8MQ? Having toyed with some kernel and bare-metal code myself I wouldn't be opposed to trying to make time for this if we want to get it off the ground.
Click to expand...
Very happy to hear that :) If you’re interested in helping out with the OMAP5 BSP also, let me know.

I’ll have to take a look as it fully depends on how far the NXP tree strays from the one we’re using. If it’s just missing drivers and fw, that is very low impact and isn’t a whole lot more than some copy paste. If the subsystems have been modified on the NXP side or the Letux side, there is significantly more effort involved repairing this to create compatibility. Letux already supports iMX6, so I have some confidence that we don’t stray too far but I’m not sure how stable the iMX support is in Letux.
 
@ToastBucket
Do you know the measurements of the iMX?
As EvilDragon and I were checking the current iMX procesors the big one was too large.
It's the thickness that matters as we have only about 2mm between CPU and Motherboard AFAIK.
 
ToastBucket said:
If you’re interested in helping out with the OMAP5 BSP also, let me know.
Click to expand...

I think that could be fun! I'd have to look and see what needs to be done to see if I can offer any help. I'm definitely open to learning more about this stuff but I'm also the type of person who knows when they're in over their head. I'd also be interested in doing some work to make the Pyra a bit more usable as a phone since that's one of the things I plan to use it to replace, which would involve things like a phone dialer and SMS app. That, however, might be a subject for another thread.
 
ToastBucket said:
Yes I agree. Designing a new CPU board is a significantly smaller undertaking compared to the previous tasks of CPU board, mainboard, and display board. So I disagree with the 3 year timeline of designing this board. Hardware and basic software support should be doable in under a year. However, I’m assuming a separate kernel, full integration of the new SOC into our kernel would be a little bit of work.

Also the amount of software work changes significantly depending on the hardware chosen. From my experience, working with the iMX8 family is the path of least resistance software wise. I have done board bringup on iMX8MQ based platforms in the past and it has very good support. Many other vendors have proven to have significantly worse software support (poorly written kernel code that needs to be rewritten, etc).
Click to expand...

Whether or not it can be done inside a year or not, there are sunk costs in making the current one work - and then the sunk costs of the environment around it. We as a community need it to be stable on one SoC for some time for it to be what we're after. Trying to pick a new SoC and starting any form of new development prior to shipping the current version is a big mistake. I can hear people thinking: "I've waited three years for this one - it costs a lot - if I just wait one more year I'll have a 'better one'..." That does not encourage the immediate orders and community software development needed for the Pyra to be a success.

Any thoughts to a new SoC needs to start with a lithography process of 20nm or smaller. The OMAP5432 is already on a 28nm process - the same as the ones being presented. A dramatic jump in real/general performance per Watt is only going to be seen with a lithography shrink. Sure, the 'newer' SoCs will have improvements in very specific functions - essentially additional ASICs in the CPU to handle very specific functions faster.

I'm not saying we should never consider a new SoC. I'm saying that it is WAY too early to consider a new SoC. I don't know what is going to be available on the market in two years, but I know that 2 years out is about the right timeframe to be then looking at what is available and on a 14nm or 20nm (at worst) process so that we can get a general increase in perf/Watt and not just chasing the cool new fringe functions strapped onto the latest silicone.

We have not even started to squeeze all of the performance and capabilities out of the current SoC. Why would we need another one already?
 
Grench said:
Whether or not it can be done inside a year or not, there are sunk costs in making the current one work - and then the sunk costs of the environment around it. We as a community need it to be stable on one SoC for some time for it to be what we're after. Trying to pick a new SoC and starting any form of new development prior to shipping the current version is a big mistake. I can hear people thinking: "I've waited three years for this one - it costs a lot - if I just wait one more year I'll have a 'better one'..." That does not encourage the immediate orders and community software development needed for the Pyra to be a success.

Any thoughts to a new SoC needs to start with a lithography process of 20nm or smaller. The OMAP5432 is already on a 28nm process - the same as the ones being presented. A dramatic jump in real/general performance per Watt is only going to be seen with a lithography shrink. Sure, the 'newer' SoCs will have improvements in very specific functions - essentially additional ASICs in the CPU to handle very specific functions faster.

I'm not saying we should never consider a new SoC. I'm saying that it is WAY too early to consider a new SoC. I don't know what is going to be available on the market in two years, but I know that 2 years out is about the right timeframe to be then looking at what is available and on a 14nm or 20nm (at worst) process so that we can get a general increase in perf/Watt and not just chasing the cool new fringe functions strapped onto the latest silicone.

We have not even started to squeeze all of the performance and capabilities out of the current SoC. Why would we need another one already?
Click to expand...
While I tend to agree on many of these points I don't think the lithography means as much as you think it means with regards to performance or even performance per watt. I think my favorite computer history example of this is the pentium vs PowerPC battle in the early 2000s. At this time, the PowerPC cores and the Intel cores were manufactured at the same process, but PowerPC could significantly beat intel at thermals and on raw performance simply because its architecture is more optimized (https://lowendmac.com/1998/powerpc-vs-pentium-ii-escargot/). This may be a contrived example since the architectures are fundamentally quite different, but there still exist these possibilities today. Newer architectural advances can provide these kinds of performance/watt benefits even within the confines of the ARM architecture by doing exactly what you said, creating dedicated hardware inside the processor to handle certain functions. This makes it faster and more power efficient.

Even with all of this said, I didn't consider the possible osborne effect of starting development on another CPU board before the Pyra's release. As much as I would like to have an even faster Pyra as soon as possible, maybe holding off on the actual development of the board until release wouldn't be such a bad plan.

Although, out of curiosity, what do you see as a potential way to further optimize for the OMAP5? I don't know much about the platform or what it has to offer other than having an ARM NEON vector unit, which is certainly a good thing to have and can speed a surprising number of operations up.
 
You must log in or register to reply here.

Similar threads

Rami
The Future of Pyra's CPU
8 9 10
Replies
190
Views
59K
Magic Sam
Magic Sam
pmprog
FPGA CPU Board
2
Replies
20
Views
9K
Linux-SWAT
Linux-SWAT
Kev2442
On the upgradability of the Pyra
4 5 6
Replies
110
Views
28K
theredbaron
theredbaron
mclien
LCD interface communitation: Which is delivered by the CPU board directly?
Replies
11
Views
6K
EvilDragon
EvilDragon
L
Using Pyra CPU Board for other purposes
Replies
12
Views
3K
Ligachamp
L
Back
Top