From
https://www.nanotech-elektronik.pl/index.php/en/info/stackup I can see a
12 layer PCB can be 1,6mm in best case, while for example a
8 layer PCB can be 1,0mm thick (best case), so
it could be 0,6 mm difference between them. And that could add up space for a bit thicker SOC chip. A
10 layer PCB can be 1,3mm thick, so it would be only 0,3mm difference, but even in this case it adds up space.
Since we are already splitting hairs (almost)... I think the PCB would end up centered on the socket, so if you have a board 0,6mm thinner, you'd only get a 0,3mm extra margin (on each side, but your SOC will sit on only one side, so you can only replace it with one that is 0,3mm thicker, a soc 0,6mm thicker won't fit even if the PCB was 0,6mm thinner).
I'm not so sure how it works, though. It's very small numbers and I guess you need some margin to be able to insert and extract it (maybe you're counting it's the same existing margin, whatever it is).
But I doubt you can so easily reduce number of layers just by choosing a different (and more powerful) SOC.
The way to reduce layers would be to reduce components in the board. Maybe if you could get fewer RAM chips for the same RAM, or you choose to leave out eMMC. I don't know.
If you go for narrower buses you should get worse performance (and if you go fewer RAM chips possibly too, it may depend).
Btw. What was the comment about ? OMAP5430 had POP RAM (so no need to add SOC-RAM traces to the board, which must be a lot of them) and OMAP5432 needed the RAM chips on the PCB, so more traces ?
O wasn't that the difference?
I've heard current SOCs don't use POP anymore, but anyway, wouldn't the stack SOC+RAM be even taller than the current OMAP5432 ? We'd also have more problems with heat, I suppose.
POP should also be harder to solder, I have heard, so possibly lower yield?.
And more important: are support, drivers, open soft and DOCUMENTATION on Chinese RK3399 as good as on European² NXP?
Having PineBook Pro and RockPro64 inter alia should help there.
I think
it needs a blob for eDP, but I think Pyra uses MIPI DSI, so maybe we're lucky ?
I know a RockPro64 can boot and use a desktop on HDMI, with browser, display videos, play sound, etc. with a
uBoot that should be now mainline, an ATF without the hdcp blob, linux-libre and debian 10.
I even tried a while without a fan (but in open air, not enclosed). Once I mounted a fan on the SOC (it covered the SOC and most part of the RAM chips) I had to make it play 3 internet videos at a time in overlapped windows
to get it to turn on (I don't remember the threshold temp now). I'm crappy like that at benchmarks. But I don't have it anymore.
I think I remember documentation is available, but maybe not so complete as NXP.
When a lot of ordered Pyra be sent, and summer/hot arrives, we will know how much time Cortex-A15 can run at full (or even turbo) speed (and how much battery drained that way).
Or if some of the first preorderers are in the boreal hemisphere ?
By other way we could get a RK3399 SBC without fan nor heatsink and we could encapsulate it in a small box to simulate in some way Pyra environment, and we could see power consumption and sustained speed, how much it would throttled down, etc.
Err... I wouldn't know how to begin to try that. I mean how do I know the environment is similar enough ? Or what to test ?
I know Pine64 recommends using a fan or a big dissipator on the RockPro64. My intuition is that it would get hot on the Pyra.
How much or how usable it'd be temp-constrained, I have no idea.
About NXP SOCs I have seen more open aware hardware on ARM is selecting NXP:
I think using so NXP hard Pyra could attract not only retrogammers and some Linux users, but also free minded people looking for less closed hard/soft. And it would be another selling point for Pyra.
I don't know iMX8M but I used to like i.MX6Q, so yes, I have good vibes for NXP.
That MNT Reform page you linked warns that
HDMI port (on i.MX8M, requires an optional HDMI TX firmware blob to work)
But
otherwise seems very nice.
I would reconsider NXP SOCs for all the aforementioned points. And more important, I would check power consumption and temperature/throttling of RK3388 (28nm?) in an environment similar to Pyra (no heatsink on SOC, no fan, small and near closed box) in front of 14nm Cortex-A53 NXP SOC. It would be bad we end with a burning hands while holding a Pyra and with very slow Cortex-A72 after severe throttling down in hot summer.
Is RK3388 a typo or some chip I don't know ? Did you mean RK3399, RK3288, or RK3588 ?
Please consider that for example
Pine uses RK3399 on Pinebook Pro but on Pinephone and Pinetab they use an Allwinner Quad Core Cortex-A53 SOC. So they think that RK3399 isn't optimal for handheld devices: heat, power consumption, no heatsink, no fan...
Yes, but their Pinephone is thinner than a Pyra, isn't it?
And how does the enclosure of a PineBook Pro compare with a Pyra ?
That's hard for me to understand.
I don't know. I'd like RK3399 or i.MX8M better than OMAP5432, but I don't know how feasible that would be, and what I know is that we now have an OMAP5432.
First we need to use and develop for this.
In a future one can see.
But in the future the available SOCs will be other.
If we start choosing SOC too early, then we can block future decisions before we need to.
Once the Pyras are sold, investment recovered, and EvilDragon, or someone decides to take the risk of a new CPU Board, it is then the right time to see what SOCs are available and which are feasible and which one we like better.
