Finishing up the hardware


I have come to accept 2GB because most people feel that will be enough for everything practical we can throw at the Pyra.  
Even with heavy multi-tasking I've been hard pressed to consume more than 750MBs on the Devboard. 
What about metasploit (if possible) or VMs and games like I mentioned?  I don't have specific games in mind since the ones I am most interested in either don't run at all, or are nearly unplayable, on x86 Linux boxes.
The thing with anything emulated (e.g. Windows) or virtualized is that it essentially has a big time overhead and a very small space overhead.

So the bottleneck will always be the processing speed, not the memory. You'll always be emulating things from the past, which was a time when CPUs were slower and everything had less RAM. E.g. Windows XP ran on machines with 64MB of RAM, Windows 98 needed 16MB of RAM (24MB "recommended"), and games or applications from that era normally don't have memory requirements that are much higher than that.

More RAM will not help much at all for emulation. For native games, it could make a difference, but even there I suspect that the bottleneck will usually be in the processing power (the GPU with its limited power) and not in the amount of available memory. The biggest difference would be for native applications like big compile jobs, lots and lots of browser tabs, editing huge images or videos, stuff like that.

Sorry for being so badly informed about the development, but what "eMMC" are we talking about, and why do we need it to be that big? What other memory-related topic have i missed?

He's referring to the internal storage which the OS will be installed to.  Larger internal storage will mean more applications can be installed without having to put them on an SD card.

-Neelix
Exactly. And this is also the thing that should be the most future-proof, because IIRC it's not on the CPU board (which is in principle upgradeable) but it's on the main PCB. If a next-edition Pyra would have an upgraded CPU board (perhaps even an x86 based one with a full OpenGL GPU?), then it would make sense, and it would be possible, to give it more RAM as well to match that. But the internal storage on the eMMC is still going to be what it is.

I immediately want to add though that it's not that important to have a future-proof eMMC, since there's still the µSD slot that can override the eMMC, and also, I imagine that the idea of the "upgradeable CPU board" is mostly something to simplify the design of potential Pyra successors, but it's not really meant to actually upgrade Pyra 1 units to Pyra 2 units: the Pyra 2 would probably still have a slightly updated main PCB as well, with perhaps a faster/better wifi/4G chip, faster SD card slots, and a new eMMC. At least that's my prediction.
 
I think the Pyra should have more RAM than the Pandora, but perhaps 1GB is enough. I'm not sure, but if 2GB just ends up being mostly unused, slightly increasing the power consumption and probably increasing the price, then I'm not even sure if 2GB is a good idea. If we're going to have more than 2GB, then I first want to see a realistic use case for which it is actually useful.
I think 2GB of RAM should be enough, but maybe there is a reason smartphone manufacturers went up to 3GB of RAM for Android ? 

Somehow i forgot that the solution was to keep both the microSD slot and the eMMC.


64M sure is enough for me ^_^
I doubt ED will choose 64GB, I personally hope for 32GB, but 16 GB are also ok (but if one wants to install a lot of SDK n'stuff, it could get a little crowded on the NAND internal memory)
 
Last edited by a moderator:
32GB seems pretty fine for me as well, especially as I'll be able to plug in various SDs, µSDs, and of course my HDD.

2GB should be enough for heavy browser usage (I often browse with more than a hundred tabs, but I'm likely to change my habits as soon as I get a Pyra) but it's not too much either for the OMAP5.

We should wait for a better SoC to upgrade to 4GB or maybe 8. Some months ago, we heard about ED discussing with AMD about their 64-bit ARM w/ Radeon GPU. That would be nice to have with lots'o RAM. With such power, the world is ours. Mwahahaaa ! :lol:
 
Bigger screen, faster processor and backlit keyboard, all in the same sized case!  Everything else is icing on the cake for me.  I can't wait. :)
 
The parts needed for the eSATA port have been removed from the PCB to save costs and moved onto the adapter.


Without the adaptor, you couldn't use eSATA anyways, so no need to have all the needed parts inside the normal device
except you keep the parts and the solderpoints inside the device, so we can choose to exchange the USB port with the SATA port or find us an old stock of a combined port or salvage it from some brocken notebook...
 
 

Our goal is to have the full hardware finished within July, so we actually have real prototypes ready to show at the GamesCom in August.

Yep, if you're visiting there, you might be able to play on a real Pyra prototype!
BTW: Is there a way to get legitimation as "Fachbesucher" for us? Or is there any needed? Would be nice to have the possibilty to get there on Thursday.. (less crowded perhaps?)
 
The parts needed for the eSATA port have been removed from the PCB to save costs and moved onto the adapter.


Without the adaptor, you couldn't use eSATA anyways, so no need to have all the needed parts inside the normal device
except you keep the parts and the solderpoints inside the device, so we can choose to exchange the USB port with the SATA port or find us an old stock of a combined port or salvage it from some brocken notebook...
If you're soldering on a new connector, it should be not much harder to unsolder the chip needed from the adaptor and squirrel it away somewhere inside the case.  To be honest, unsoldering the USB port and putting in a new port seems very difficult anyway, as an eSATA port is a different shape, and even a combined port is likely to have slightly different dimensions.  You'd need to bridge in a daughter PCB somehow anyway, even if you didn't need an extra chip to make it work.

Personally, I'd stick with the adaptor.  Hopefully it's all hot swappable, so I can just plug it in with my SATA hdd when I get to my destination, if I need to take it with me.
 
The thing with anything emulated (e.g. Windows) or virtualized is that it essentially has a big time overhead and a very small space overhead.
A properly virtualized system has hardly any performance loss compared to bare metal, I'm using a Windows VM for gaming myself (KVM with VGA passthrough) - a few things even get faster.
Actually, a VM needs quite a lot of RAM without paravirtualization (or memory ballon drivers), because you have to reserve a fixed amount of RAM. However, there are tons of systems like FreeBSD that support para-virtualization on a Linux host, which makes things extremely efficient.
 
The thing with anything emulated (e.g. Windows) or virtualized is that it essentially has a big time overhead and a very small space overhead.
A properly virtualized system has hardly any performance loss compared to bare metal, I'm using a Windows VM for gaming myself (KVM with VGA passthrough) - a few things even get faster.
Yes, but that's not going to work on the Pyra, with its non-x86 CPU and all. Maybe an Android VM or something could make sense, and then more RAM would be useful.
 
true... as long as the task is not IO intensive
For some reason my ext4 + SMB + VirtIO-LAN setup seems to be about twice as fast as a native Windows on NTFS when handling a lot of small files, though, but that might just as well be a quite extreme superiority of ext4 over NTFS.
 
64M sure is enough for me ^_^
What will you fit in 64 megabytes?
Keys, a bunch of kernels, bl and a 'interesting" irfs.
Exactly. And this is also the thing that should be the most future-proof, because IIRC it's not on the CPU board (which is in principle upgradeable) but it's on the main PCB. If a next-edition Pyra would have an upgraded CPU board (perhaps even an x86 based one with a full OpenGL GPU?), then it would make sense, and it would be possible, to give it more RAM as well to match that. But the internal storage on the eMMC is still going to be what it is.

I immediately want to add though that it's not that important to have a future-proof eMMC, since there's still the µSD slot that can override the eMMC, and also, I imagine that the idea of the "upgradeable CPU board" is mostly something to simplify the design of potential Pyra successors, but it's not really meant to actually upgrade Pyra 1 units to Pyra 2 units: the Pyra 2 would probably still have a slightly updated main PCB as well, with perhaps a faster/better wifi/4G chip, faster SD card slots, and a new eMMC. At least that's my prediction.
Does anybody still believe that the carrier board will stay as released for more than a few months? Dont you feel how fast do we approach the "mix and match" here?We can add more storage, better soundcards, better wireless equipment, but we cant just plug a new SoC into a OTG port ( :lol: ) , so thats why people are serious about it.

Somehow i forgot that the solution was to keep both the microSD slot and the eMMC.

64M sure is enough for me ^_^
I doubt ED will choose 64GB, I personally hope for 32GB, but 16 GB are also ok (but if one wants to install a lot of SDK n'stuff, it could get a little crowded on the NAND internal memory)
I also do, but its 64 or nothing! :D
 
Does anybody still believe that the carrier board will stay as released for more than a few months? Dont you feel how fast do we approach the "mix and match" here?
I don't think it will be that much of an issue, Bringing up a new CPU board is intensive work, not only is there the electrical design, there is the Kernel/OS development side of things as well. I doubt EvilDragon and Nikolaus want to do that every few months. As for the additional things on the CPU boards the eMMC, DRAM and such is something that can be sourced in bulk, most likely for the entire 5000 planned units.
 
Last edited by a moderator:
Another thing to consider is heat may prevent being able to upgrade to some SoCs even if they can be procured in the limited quantities needed, not to mention all the other issues.  TrashyMG, EvilDragon, and others with devboards probably know more if  this will be a problem than my best guess.  How do other mobile devices deal with the heat issue, or are they just not designed for heavy use?
 
_wb_ above seems to think the eMMC will be on the peripheral board (aka. the main board), not the CPU board, and I suspect he's right (since that's where the uSD slot is).  I think lvid is expecting an updated peripheral board down the line soon rather than later, and perhaps he's right - memory prices will change and a few months down the line maybe a 16GB chip will be as cheap or cheaper than an 8GB one.  Probably not though, 16GB SD cards have always been more than 8GB ones, although a quick test shows that 4GB cards are slightly more expensive than 8GB ones (bought singly at least - a pair of 4GB cards is only slightly more again, making each one cheaper).  Although I check that on a standard retailer, who have to figure in postage and handling fees; on a component shop where you can buy hundreds at once, I suspect 4GB will still be cheaper.
 
Another thing to consider is heat may prevent being able to upgrade to some SoCs even if they can be procured in the limited quantities needed, not to mention all the other issues.  TrashyMG, EvilDragon, and others with devboards probably know more if  this will be a problem than my best guess.  How do other mobile devices deal with the heat issue, or are they just not designed for heavy use?
I guess this wont be a serious problem for the next 5 years.
 
_wb_ above seems to think the eMMC will be on the peripheral board (aka. the main board), not the CPU board, and I suspect he's right (since that's where the uSD slot is).

I actually suspect it is on the CPU board, having it on the Main PCB doesn't make it really upgrade friendly and I suspect it is a part that doesn't age well and can be obsoleted quickly overtime.  eMMC memory module packages are not really standard between companies or sometimes even within the same manufacturer as new versions tend to drastically change the pinouts and package size.
 
Last edited by a moderator:
CHyl2O3WUAEVzYu.jpg


CIQy8MwWgAAkHHm.jpg


CIaxJt2W8AAIG8n.jpg


 

Find the differences :D
 
2GB of RAM should be adequate to run the Debian OS,  3 Android VMs, web browser, LibreOffice, a movie and one incredibly resource intensive game all at once - but not much more than that.   :lol:

For the eMMC - you guys are thinking about it backwards and valuing size over speed.

eMMC is capable of TWICE the data rate of microSD.  However the fastest eMMC are MUCH more expensive per GB.

eMMC maxes out at 200MB/s (+/-)

microSD maxes out at 100MB/s (+/-)

If a 16GB 200MB/s eMMC costs the same as a 32GB 100MB/s eMMC, I'd rather have the 16GB eMMC installed.

Max out the speed on the internal eMMC.  I can already buy microSD cards that max out the speed of the microSD port.  That gives the end user a choice of sorts.  Use the smaller, but super fast internal eMMC or drop in a slower but much larger microSD card.

Heck, if it makes the eMMC considerably faster, I'd be OK with the eMMC being only 8GB.  User data can all go on the two SD cards anyway.
 
Back
Top