Finishing up the hardware


 

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.
 
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:
Do not under-estimate Game makers ;) Even on the Pandora, there are some games that will not work without a swapfile...
 
Last edited by a moderator:
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.
I'm not sure if raw transfer speed is really that important for the eMMC. It would have a bit of impact on the boot time, and the time needed for a suspend-to-disk, but other than that, I don't think it really makes a huge difference in practice between 100MB/s and 200MB/s. At least not for the loading times of most software.

For data transfers (e.g. if you put movie files or something on the eMMC) from the eMMC to something external over USB 3.0 or eSATA, it does make sense to have an eMMC that is as fast as possible.

The thing is: if the eMMC is small, you'll probably want to use it only for software, not for data, so the fast data transfers are not really very useful.

If the eMMC is big, you might want to use it for data, and then the data transfer speed matters more.

So I would say: try to find a good balance between speed, size and price.
 
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:
Do not under-estimate Game makers ;) Even on the Pandora, there are some games that will not work without a swapfile...
Firefox (5 windows, +2600 tabs total, +400 pages active), GIMP, GPicView, OpenOffice, PcManFM, HexChat, Terminator (tmux, mplayer, EMACS)

Thats what i have on my desktop right now, and it does take quite much 8GB of ram and 2GB of swap.
 
Last edited by a moderator:
... +2600 tabs total, +400 pages active ...
What for?  If it's just for testing purposes then even if PYRA were to have a gazillion GB of ram, it's still not enough as you always have ways to max out the ram by opening a +2600 gazillion tabs total, and +400 gazillion pages active ;)
 
Last edited by a moderator:
Back
Top