The Future of Pyra's CPU

[ToastBucket]

In terms of grunt, it's based around quad 1.5GHz 'little' 64-bit processors, so less efficient than the A15 cores in the Pyra although with four of them it might be worth playing with.

4xA72s is a huge upgrade in terms of raw power from the A15s but yes they are more power hungry than other cores. It could be comparable to A15s though, they are very inefficient cores. A72s are actually part of the big cluster in a big.LITTLE combo, there’s just no LITTLE on the BCM2711.

I know it’s fun to toy with the idea, but this will never be used in the Pyra Required documentation is locked down through business contracts between Broadcom and the Pi Foundation. Most importantly, boot procedure is obfuscated, which is particularly problematic for us because we need to perform very specific operations early in the boot process in order to manage some of the power management design.

if we could get our hands on some RK3399’s we may be able to leverage some of the work being done on the pine book pro as well as contribute back to their project. We could potentially have the option of running Manjaro on the Pyra too, in that case which would be sweet.

 

[Eight Bit]

if we could get our hands on some RK3399’s we may be able to leverage some of the work being done on the pine book pro as well as contribute back to their project. We could potentially have the option of running Manjaro on the Pyra too, in that case which would be sweet.

It has been suggested as a feasible candidate before
Manjaro on my pinebook pro is pretty decent. Though not perfect yet, I can already do a lot of "big computer things" on it.
I think it would be ideal if we could merge the efforts from both communities somewhat.

 

[RZR]

4xA72s is a huge upgrade in terms of raw power from the A15s but yes they are more power hungry than other cores. It could be comparable to A15s though, they are very inefficient cores. A72s are actually part of the big cluster in a big.LITTLE combo, there’s just no LITTLE on the BCM2711.

I know it’s fun to toy with the idea, but this will never be used in the Pyra Required documentation is locked down through business contracts between Broadcom and the Pi Foundation. Most importantly, boot procedure is obfuscated, which is particularly problematic for us because we need to perform very specific operations early in the boot process in order to manage some of the power management design.

if we could get our hands on some RK3399’s we may be able to leverage some of the work being done on the pine book pro as well as contribute back to their project. We could potentially have the option of running Manjaro on the Pyra too, in that case which would be sweet.

What is the problem on getting the RK3399?? Package quantity for that chip is 600 uds, so I suppose it enters whiting Pyra's production numbers.

And another question, these SOC, cannot be ordered without the IHS?? If the Pyra already has a heat spreader then there's no need for the integrated one, and it saves 1mm or so of thickness...

 

[EvilDragon]

The RK3399 seems to be WAY too big. We had space issues with the OMAP5 (we originally planned to use the way smaller OMAP5430, but that one never went into production).
So fitting the 23x23mm with 1mm thickness into the little space we have seems impossible.

The best candidate right now seems to be the i.MX8M Nano.

 

[Swordfish II]

But isn't the RPi4 SOC (BCN2711) compromised by needing blobs to boot ?

Pyra's wifi/bt/cellular will likely need blobs. The sgx is a blob too

 

[EvilDragon]

Pyra's wifi/bt/cellular will likely need blobs. The sgx is a blob too

Yes, but you don't need that to boot. You can use the system without them, you would just be missing these features.
Wifi / BT could be done with a USB stick, for example, and not everyone needs the SGX.

The "to boot" is pretty horrible, in my opinion.

 

[Phlyra]

The RK3399 seems to be WAY too big. We had space issues with the OMAP5

So fitting the 23x23mm with 1mm thickness into the little space we have seems impossible.

The best candidate right now seems to be the i.MX8M Nano.

So we’d be looking for something smaller than the current smallest module (35 x 40mm)?
http://linuxgizmos.com/linux-driven-i-mx8m-nano-module-is-smallest-yet/

PicoCore™MX8MN » F&S Elektronik Systeme GmbH

PicoCore™MX8MN Computer on Module, NXP i.MX 8M Nano, ARM Cortex-A53 + Cortex-M7, up to 512MB SLC NAND Flash or 32GB eMMC, up to 8GB LPDDR4 RAM, Linux

www.fs-net.de

Feel free to shoot me down/ignore me since I know you have more important things to deal with atm and I really know nothing about this, just flailing around in hope lol.

 

[Alec]

What about RK3328? It's 14X14 by 0.65mm (same area but 0.15mm taller than the i.MX8M Nano), and similar specs.

I was really impressed with Rock64 because it's the first board I had where I built the latest mainline kernel and everything just worked. RockChip contributes directly upstream.

It also has Mali-450 GPU which now has open-source 3d drivers in the kernel (never tried them though, I use it as a server).

 

[docbroke]

How about RK3288 with quad core cortex A17 with Mali T-764 GPU in 19x19, 0.65mm.

 

[ToastBucket]

The RK3399 seems to be WAY too big. We had space issues with the OMAP5 (we originally planned to use the way smaller OMAP5430, but that one never went into production).
So fitting the 23x23mm with 1mm thickness into the little space we have seems impossible.

The best candidate right now seems to be the i.MX8M Nano.

Thats a bit of a bummer. With the iMX8M nano our battery life will likely go through the roof, but we'll likely be sacrificing a good amount of raw power limiting tasks like web browsing. Its hard to do a full comparison because there's a lot of differences between these core families, but a big one is the A53's are missing out-of-order execution which we see on the A15's. The Nano is also missing the VPU (so we lose multimedia decode/encode) and HDMI. Is there a reason the 8M is not an option in place of the 8M nano? I haven't looked at the physical size difference. I remember looking at the 8M and it was similar in size to the OMAP5.

All in all, it would be nice to get something with at least one A7x core for larger load tasks. Also a Mali GPU would be great as we are starting to get in-tree kernel support for Mali GPUs.

What are the restrictions on size? The RK3399 datasheet says the chip is 21mmx21mmx1.51mm. So may be a bit tall, but its smaller than 23mmx23mm.

https://www.rockchip.fr/RK3399%20datasheet%20V1.8.pdf

How about RK3288 with quad core cortex A17 with Mali T-764 GPU in 19x19, 0.65mm.

I'm a bit hesitant to go with an A17. It's already just as obsolete than the A15. And to be honest, this is the only SOC I've actually seen sporting one, so I'm not very hopeful for good support for the A17 in the kernel.

 

[RZR]

The OMAP 5432 is indeed a tight fit:


OMAP 5430 -> 14mmx14mmx0.4mm
OMAP 5432 -> 17mmx17mmx0.5mm

And this goes against the MOBO+heat spreader, so there must not be a lot of room regarding pitch.

 

[EvilDragon]

The heat spreader is only 0.2mm. And I checked today: We can stack about 0.8mm between the OMAP5 and the mainboard.
So with the heatspreader included, it means that an SoC could have a height of max 1mm.

 

[EvilDragon]

Thats a bit of a bummer. With the iMX8M nano our battery life will likely go through the roof, but we'll likely be sacrificing a good amount of raw power limiting tasks like web browsing. Its hard to do a full comparison because there's a lot of differences between these core families, but a big one is the A53's are missing out-of-order execution which we see on the A15's. The Nano is also missing the VPU (so we lose multimedia decode/encode) and HDMI. Is there a reason the 8M is not an option in place of the 8M nano? I haven't looked at the physical size difference. I remember looking at the 8M and it was similar in size to the OMAP5.

All in all, it would be nice to get something with at least one A7x core for larger load tasks. Also a Mali GPU would be great as we are starting to get in-tree kernel support for Mali GPUs.

What are the restrictions on size? The RK3399 datasheet says the chip is 21mmx21mmx1.51mm. So may be a bit tall, but its smaller than 23mmx23mm.

https://www.rockchip.fr/RK3399%20datasheet%20V1.8.pdf

I'm a bit hesitant to go with an A17. It's already just as obsolete than the A15. And to be honest, this is the only SOC I've actually seen sporting one, so I'm not very hopeful for good support for the A17 in the kernel.

For some reason, the 8M has a die in the middle which is 2mm high. The rest of the SoC would be fine, 0.8mm height would fit perfectly, but 2mm...?

The 8M Mini would fit, but that would be a step back. The 8M Plus might be a candidate. The physical size is different than the rest, but it's in preproduction and they don't tell us the height yet.

 

[RZR]

For some reason, the 8M has a die in the middle which is 2mm high. The rest of the SoC would be fine, 0.8mm height would fit perfectly, but 2mm...?

The 8M Mini would fit, but that would be a step back. The 8M Plus might be a candidate. The physical size is different than the rest, but it's in preproduction and they don't tell us the height yet.

Isn't that the 8X?

i.MX 8X Applications Processors | Arm Cortex A35

NXP's i.MX 8X family is comprised of common subsystems and architecture from the higher-end i.MX 8 family. For graphics, video, image processing, audio, and voice.

www.nxp.com

The 8M appears as 17mmx17mmx0.65mm

https://www.nxp.com/docs/en/data-sheet/IMX8MDQLQCEC.pdf

EDIT: Ah it's true, page 79 shows a bump in the middle of almost 2mm...

 

[pyrat]

What are the restrictions on size? The RK3399 datasheet says the chip is 21mmx21mmx1.51mm. So may be a bit tall, but its smaller than 23mmx23mm.

Good question

And does it depend on other factors ?

I mean maybe we have all the ram chips but the OMAP cannot be got any more. Then we need a SOC the same size or smaller than the OMAP.
But if we have enough components secured for the Pyra orders, and it is just for a future cpu board, maybe it could carry different RAM chips and if they were smaller there could be some room
left for a bigger SOC.

I mean it sounds a little naive to me just looking at the size alone, because it's gonna have to be a new CPU board. I thought there was plenty of time for it, and I still hope it turns out so.

I'm a bit hesitant to go with an A17. It's already just as obsolete than the A15. And to be honest, this is the only SOC I've actually seen sporting one, so I'm not very hopeful for good support for the A17 in the kernel.

I think it might be a nomenclature thing. A12s were replaced with A17s. Anyway RK3288 was used in chromebooks, like veyron speedy (Asus C201) which someone liberated. I believe the support should be ok (or at least it was).
I believe it has uboot too, but if not, coreboot could work.

 

[pyrat]

The 8M appears as 17mmx17mmx0.65mm

Could that 0.65mm be pitch for the contacts instead of height ?

https://www.nxp.com/docs/en/data-sheet/IMX8MDQLQCEC.pdf

EDIT: Ah it's true, page 79 shows a bump in the middle of almost 2mm...

And not quite in the middle, it's off center. What a weird chip. Not that I know chips any well, but still.

 

[ToastBucket]

The 8M Mini would fit, but that would be a step back. The 8M Plus might be a candidate. The physical size is different than the rest, but it's in preproduction and they don't tell us the height yet.

A while back I picked up a Maaxboard which is based on the 8M to try and evaluate general performance of the part in comparison to the OMAP5. Unfortunately the support out the door for this board is pretty bad. Since there's a good amount of work required to test this out I dropped it for now since I don't have time to work on fixing the graphics before evaluation. I might try and borrow an official NXP devkit from work, I think we've got a few of the iMX8 platforms lying around.

 

[pyrat]

RK3288 19x19x1.50mm (pg.27)
RK3328 14x14x1.17mm (pg.17-18)
RK3399 21x21x1.51mm (pg. 28)

 

[EvilDragon]

Ah, sorry: The OMAP5432 is between 1.06mm and 1.29mm high.
So we have between 1.8 and 2mm space... which would be a VERY tight fit for the i.MX8M (which is 2.03 +/- 0.15mm high).
But we need to fit the 0.2mm heatspreader in as well (unless it doesn't run very hot).

The RK3399 would fit then - at least the height...

I'll check the datasheets of the connectors for the PCBs, they should have exact measurements for the total height as well.

 

[ToastBucket]

The RK3399 would fit then - at least the height...

I'll check the datasheets of the connectors for the PCBs, they should have exact measurements for the total height as well.

That's good news. The RK3399 looks like an excellent candidate under the hood. Btw, the 1.51mm height includes the BGA connections. See pages 28-29 of the datasheet for package measurements.