What is the need that you see for 4GB? Am I missing something crucial in my 2GB assumptions?
No need, pure want. I want 4GB for future growth, to be able to open 40+ browser tabs all at once, to be able to compile a large project, to load as much into RAM at startup as possible to keep things fast, give more RAM to the Android VM so it can keep more things active at once.
Nothing there is a need, everything beyond 2GB (and even that's probably more than what I'd actually need) is strictly wishlist, pie-in-the-sky because we can.
You would want 4GB instead of 2GB, despite that extra 2GB being 'just along for the ride' >99% of the time, even if the trade-offs were:
Adds ~$50 to the retail price of everyone's Pyra.
Decreases the continuous run time by ~15%.
Decreases the standby time from ~2 weeks to ~1 week.
That still does not strike me as a rational trade off.
I'm not opposed to 'adding costs'. The question of adding $15 per unit so that every Pyra has 802.11b/g/n with 2.4Ghz and 5Ghz radios - THAT makes sense to me. This doubling of expensive (both in costs and battery life) RAM to quadruple what has been shown to be 'enough' on the Dev Boards (see Trashy's posts), 'just because' strikes me as an illogical waste.
Now, here's a thought. Instead of pushing for 4GB of RAM, push for 16GB or more of VERY fast eMMC NAND.
Yes, the RAM interface on the OMAP5 has a theoretical maximum transfer rate of 8.5GB/s. However, since it is DDR3, it is very power hungry.
The eMMC port, on the other hand, has a maximum transfer rate of 208MB/s. Since it is NAND, it is VERY power efficient. Yes, it's about 2% of the theoretical speed of the RAM bus. Still, it's capable SSD speeds, not old HDD speeds.
If you somehow manage to find a use case where you actually need more than 2GB of RAM, a portion of the eMMC NAND could be used as a very fast /SWAP partition.
So, maybe for those of you after 4GB of RAM... maybe you should consider asking for 16GB of the fastest eMMC available instead? It could give you the application space you're after without killing the power budget.