Future of the CPU board?

[Silent-Hunter]

The i.MX8 Mobile is actually the one we´re looking at.
It´s not much faster than the OMAP5 - but needs less power and produces less heat.

That sounds nice! What GPU does it have?

 

[daveshah]

That sounds nice! What GPU does it have?

Assuming "i.MX8 Mobile" is i.MX8M then it is a Vivante GC7000 Lite (OpenGL ES 3.1)

I'm surprised that gives significantly better performance/W given it is still 28nm though - some of the other i.MX8 parts are 14nm but appear to have inferior GPUs.

 

[matzesu]

If this CPU Board is good, then i think im fine..
But how easy will it realy be to change the CPU Board on the Final Pyra?? That easy as to fix the Shoulderbuttons on the Pandora ??
Whe have now these whole Thermo Sink Material, Heatshield, Heatsink etc, but it is still plug and play??

 

[fahrstuhl]

The i.MX8 Mobile is actually the one we´re looking at.
It´s not much faster than the OMAP5 - but needs less power and produces less heat.

Not sure if I posted this before, but have you had a look at the Rockchip RK3399? Collabora has worked on making the reverse engineered GPU driver work and it seems like a good open source platform.

Edit:

I've been very happy recently, running Manjaro Linux 64 bit on my Pinebook pro (much happier than I was when it ran Debian) which sports a rockchip RK3399 SOC with Mali T860 MP4 GPU. Now I'm no expert on SOC's and the PBP is surely not a gaming device but Manjaro seems to run quite decently with the latest kernel. I now even have 32 bit chromium running in a docker container so I can use Wiidevine for watching and listening to DRM content like spotify and netflix and it works great. I feel it will only get better as it did with the Pandora.

So maybe that or the RK3399pro are worth considering as it would be easy to surf along on already made efforts in regards to the software?

Eight Bit posted this before, maybe I should read a thread before posting in it

 

[daveshah]

RK3399 certainly has a nice feature set and it's good to hear of decent open source support compared to many of these processors. My concern would be power/heat and size, it looks more optimised to TV box or laptop type scenarios than smaller devices.

 

[EvilDragon]

The problem with the Rockchips isn´t only software. There is only a chinese hardware documentation available (if at all) which makes designing the CPU board nigh impossible.

 

[Askarus]

What about Amlogic S992X?
It's the one odroid N2 uses.
And it's Cortex A73 instead of A72. So it's a lit more power efficient than the Rockchip

 

[elvissteinjr]

The i.MX8 Mobile is actually the one we´re looking at.
It´s not much faster than the OMAP5 - but needs less power and produces less heat.

Honestly? That sounds like a lot of headaches and effort for next to no gain. I just don't see many existing users switching and if the difference is barely there, it wouldn't really get us many additional either.
If OMAP5's EoL is imminent, I suppose it's the next best step, but otherwise? I know there aren't really many good alternatives, but perhaps it's not the time yet? Getting the OMAP5 to work took a while (and is partially still an ongoing effort, iirc), so imo the steps should be significant.

At the end I can only speak for myself, though. i.MX8 doesn't look like an upgrade board I'd buy in the future.

 

[asimov-solensan]

The A72 on the i.mx8 is really not that powerful compared to the A15 in the actual omap?

It is like two generations ahead the A15. I thought there would be a huge difference. But well, I know nothing about this things.

 

[daveshah]

What about Amlogic S992X?
It's the one odroid N2 uses.
And it's Cortex A73 instead of A72. So it's a lit more power efficient than the Rockchip

HardKernel have uploaded some fairly good documentation here: https://dn.odroid.com/S922X/ODROID-N2/Datasheet/S922X_Public_Datasheet_V0.2.pdf too, not as good as something like the iMX8 but a start.

But I'm still a bit worried as to whether a TV-box SoC will be power optimised enough for this use case

 

[Askarus]

The A72 on the i.mx8 is really not that powerful compared to the A15 in the actual omap?

It is like two generations ahead the A15. I thought there would be a huge difference. But well, I know nothing about this things.

We're talking about the i.mx mini or mobile or whatever.
Not the automotive version.
That one does not have A72 Cores but only A53.

But I do agree with @elvissteinjr .
I don't see the i.mx8 as an upgrade that's worth the effort.
As long as the OMAP5 is supported I'd stick with it and optimize software for it.
For me choosing a SoC with only LITTLE cores and no big ones dies not make sense.

 

[Askarus]

HardKernel have uploaded some fairly good documentation here: https://dn.odroid.com/S922X/ODROID-N2/Datasheet/S922X_Public_Datasheet_V0.2.pdf too, not as good as something like the iMX8 but a start.

But I'm still a bit worried as to whether a TV-box SoC will be power optimised enough for this use case

I'd rather throttle down "big" cores instead of not having them at all.
Having high peak performance is important for desktop usage.
We don't need to run them at full speed all the time.

I'd even prefer being forced to use an older Kernel because of driver issues instead of having a SoC without "big" cores.
We don't need to deliver as much performance than GPD does, but having some more power when needed is not a bad thing

One more thing not mentioned here:
The i.mx has one more advantage over the OMAP 5 : it is 64-bit.
However, it would not justify the effort for me.

 

[daveshah]

I'd rather throttle down "big" cores instead of not having them at all.
Having high peak performance is important for desktop usage.
We don't need to run them at full speed all the time.

I'd even prefer being forced to use an older Kernel because of driver issues instead of having a SoC without "big" cores.
We don't need to deliver as much performance than GPD does, but having some more power when needed is not a bad thing

One more thing not mentioned here:
The i.mx has one more advantage over the OMAP 5 : it is 64-bit.
However, it would not justify the effort for me.

Indeed, it looks like power to the A73s can be turned off, so as well as power benefits people who want in-order only for security can just use the A53s and ignore the A73s.

 

[Farox]

According to this sheet https://www.nxp.com/docs/en/supporting-information/IMX8LAYERCMPR.pdf
The only interesting SOC of the i-MX8 family is IMHO
i.MX8 --- 2 x Arm Cortex-A72 @ 1.6 GHz and 4 x Cortex-A53 @ 1.2 GHz,
2 x GC7000XSVX (8-shader each)* OpenGL® ES 3.2, Vulkan®, OpenCL™ 1.2; OpenVX™ 1.1 vision extensions; high-performance 2D Blit Engine
DSP
but the mayor drawback are that is 28 nm and for automotive so big consume and heat.

and the i.MX 8M Plus ----- (Quad/QuadLite) 4 x Cortex-A53 @ 1.8 GH, 1 x Cortex-M7 @ 800 MH
1 x GC7000UltraLite 3D GPU (2 shaders) OpenGL®ES 3.1, Vulkan,® OpenCL™ 1.2; GC520L 2D GP
14 nm
but the horsepower will be similar to the OMAP 5 (only the GPU will probably be a bit better...) and maybe power consumed will be less than TI Soc.

So in the end not a big leap forward...but maybe in next two year...will see the light a new SOC...who knows.

 

[levi]

Now I'm confused. So there's the iMX8M and the iMX8M mini (and the iMX 8M plus) and there all different things. Which of them are we actually targetting here?

 

[Nilsnsn]

Well, the A53s would give the advantage of being 64 bit. It may not be a speed advantage, but saves us from trouble with spreading drop of software support for 32 bit (see Dolphin or KVM in Kernel).

 

[daveshah]

I had a bit more of a look into the Amlogic S922X as a possibility (and perhaps for another project of my own, too).

The biggest downside seems to be the boot process isn't very well documented and requires a number of signed binary blobs. Whilst there is a tool provided that I think would enable you to sign your own code to replace some of these, that tool is provided as an x86-64 binary only (it is also needed to make a U-boot image at all). Someone did reverse engineer it for another Amlogic device (https://github.com/repk/gxlimg) but without the source code for the blobs you would have to decompile those too. There are also some DDR4 controller firmware blobs but I think the i.MX8 suffers from these too.

This means for people to whom it matters, getting a blob free boot would be somewhere between a lot of work and impossible. Even though it's not the biggest issue myself security wise (unpatchable and unauditable burned in ROMs being more of a concern than dissassembleable blobs), it could certainly make debugging harder if there is no visibility into the earlier parts of boot.

As ever with these things, although the registers are all documented which is better than usual, there isn't any very good description of how everything glues together (I was trying to find out what the video pipeline looked like and how panel rotation would work, which is even advertised as a feature).

 

[EvilDragon]

Well, I've seen the normal i.MX8 on the Embedded World exhibition in Nuremburg.
It had a huge fan on top (PC fan size)... but yeah, that was to be expected, as it has more power than the OMAP5... but yeah, with 28nm, it will NEED that fan if you want to use the horsepower.

So only the smaller ones would be helpful. While they don't give more CPU power, they produce less heat, are 64bit and probably have an easier to use 3D and hardware rotation included.

 

[Askarus]

What about the MediaTek Helio SoCs?
Are they easily available and well documented?
They have Cortex A75 and A76 SoCs.

 

[daveshah]

What about the MediaTek Helio SoCs?
Are they easily available and well documented?
They have Cortex A75 and A76 SoCs.

I can't find any pinout or register level documentation for any of the Mediatek SoCs, presumably it is under strict NDA and hasn't leaked. I suspect availability could be an issue too.