Ideal Pyra configuration & Accessories

[Orbstheorem]

1) Probably 8GB as I'm almost never going to use it, mostly for booting an alternative OS from time to time

2) I don't get the question. If you mean having a non-supported filesystem by non-linux systems of course!, I can always use the gadget driver if I need to connect to a PC...

3) I'll mostly use my pyra as a handheld desktop computer, maybe some games from time to time, but I'm considering running a VM with android inside it

4) Everywhere

5) I don't currently own a pandora, but the pyra will make me throw my S4 away

 

[TrashyMG]

Thread is over a year old, a lot of things have changed.

32GB will be the size for the eMMC internal storage.

 

[Orbstheorem]

Thread is over a year old, a lot of things have changed.

32GB will be the size for the eMMC internal storage.

Do we still have the limitation of accessing either internal eMMC OR microSD card?

EDIT: Sorry for necro-posting

 

[TrashyMG]

Well there was talk of possible having them muxed somehow, allowing both capable of being used at once (most likely a half speed if accessed at the same time), but not sure this has been proven working yet.

 

[Neelix]

Do we still have the limitation of accessing either internal eMMC OR microSD card?

Yes and no. The hardware is designed to switch between the two. Only one of them can be active at any given moment. The switch itself is electronic though so it's been theorised that a kernel driver could do this transparently in the background, providing virtual simultaneous access. (though of course the bandwidth would be shared between both devices, so you couldn't access them both at full speed at the same time) However I haven't heard of any work being done or even planned as yet to actually implement such a system, so I believe that at this point it's still only a theoretical possibility.

-Neelix

 

[TrashyMG]

Nikolaus mentions it here:

https://pyra-handheld.com/boards/th...s-usd-modular-emmc.73682/page-14#post-1286383

Follow up here:
https://pyra-handheld.com/boards/th...s-usd-modular-emmc.73682/page-17#post-1286445

 

[diligentcircle]

1) What is the ideal MicroSD card size?

I probably won't need one immediately. I would get one if it turned out that the NAND wasn't big enough, or when the NAND wears out.

2) Are you going to isolate the Pyra so it doesn't require a PC for download of applications?

I would use the Pyra like a regular computer. I don't see why I would get another computer involved.

3) Are you going to use the Pyra on your HD television / Monitor as a Desktop device or gaming console?

:shrug:

4) Where is the primary location you will be using your Pyra?

Mostly when I'm out of town or otherwise in a situation where using my laptop is impractical.

5) Would the Pyra prompt you to sell other devices you might not use?

Probably not. It would just replace my Pandora, and I doubt I can get enough for that to bother selling it.

 

[Orbstheorem]

Yes and no. The hardware is designed to switch between the two. Only one of them can be active at any given moment. The switch itself is electronic though so it's been theorised that a kernel driver could do this transparently in the background, providing virtual simultaneous access. (though of course the bandwidth would be shared between both devices, so you couldn't access them both at full speed at the same time) However I haven't heard of any work being done or even planned as yet to actually implement such a system, so I believe that at this point it's still only a theoretical possibility.

-Neelix

Personally I'd go for a single device instead, having my rootfs bandwidth limited doesn't seems great to me. Unless we could manually enable or disable such feature

 

[WizardStan]

Personally I'd go for a single device instead, having my rootfs bandwidth limited doesn't seems great to me.

It would only be limited if you were trying to read from both at the same time, which isn't likely to happen, and it'd be pretty easy to give priority to one or the other, such that it always gets 100% throughput while the other blocks until the first is finished.
This all hinges on the idea that switching is easy and painless. If it takes a few milliseconds (or worse, a second or longer) to do the switch then you'll spend all your time just waiting for the switch to complete.

 

[Plume]

I doubt that the switch would take that long. We're not talking about a relay or similar.

 

[WizardStan]

It needs to stop the clock, switch everything over, restart the clock, and possibly re-initialize things. These aren't instant operations. I don't expect it to take a substantial length of time, but without some clever caching, ANY amount of time will build up.

 

[Grench]

It needs to stop the clock, switch everything over, restart the clock, and possibly re-initialize things. These aren't instant operations. I don't expect it to take a substantial length of time, but without some clever caching, ANY amount of time will build up.

But! Both are fast enough that even at 1/4 speed, that may be acceptable on occasion.

 

[Orbstheorem]

But! Both are fast enough that even at 1/4 speed, that may be acceptable on occasion.

a single data line at 25Mhz clock speed, that'd be ideally around 6 MB/s, not fast enough for rootfs, but quite handy though

EDIT: Checked the UHS-I Spec. Apparently the clock on the UHS is 100Mhz, therefore we could have an ideal speed of around 24MB/s

 

[WizardStan]

EDIT: Checked the UHS-I Spec. Apparently the clock on the UHS is 100Mhz, therefore we could have an ideal speed of around 24MB/s

The MMC is 8 bits wide, but the SD is only 4 bits wide so would only get half that throughput.

 

[Orbstheorem]

The MMC is 8 bits wide, but the SD is only 4 bits wide so would only get half that throughput.

I'll redo my math: from the 4 SD bits, a quarter would be 1 bit. The clock rules the rate of each line, so each line should be transfering at 100 Mhz, so 12.5 MB/s (raw, not read transfer rate). Sorry I was sleepy...

 

[Grench]

Mmm.... Something isn't right with that math or every spec I've seen on both the eMMC and the SD protocol are wrong. To my understanding, the eMMC bus speed (theoretical maximum) is 208 MB/s and the uSD and SD bus speed (theoretical maximum) is 104MB/s. Could you have used the -old- MMC and SD specs?

The Pandora got real world reads of just short of 20MB/s on it's SD ports. The Pyra's SoC specs call for SD bandwidth of 2.5x the Pandora's and eMMC bandwidth of twice the SD. Without the switching I'm expecting the eMMC to run around 100MB/s and the uSD card to cap around 50MB/s real world speeds. If you're copying data from one to the other (worst case scenario), Read, switch, write, validate write, switch, repeat... Each bus will be cut roughly in half and some speed will be then lost to the switching overhead.

Worst case scenario, when copying data from one to the other, that switching overhead would be half or less - that is where the 1/4 comes in. So - in that worst case scenario with worst case switching overhead taken into account, I expect the eMMC to be effectively reading at roughly 25 MB/s while writing to the uSD at 12.5 MB/s. Frankly, it should be considerably faster than that as I don't expect the switching overhead to fully half the performance.

Generally, I doubt anyone is going to be spending a lot of time copying files from the eMMC to the uSD. In cases where someone has both present, I would expect a scenario where they boot the OS from the eMMC and have /home on the eMMC.

I'm looking forward to ED being able to run some tests & benchmarks on the final boards with the 32GB eMMC and a solid uSD. I think they'll outperform my above 'worst case scenario'..

 

[Orbstheorem]

Mmm.... Something isn't right with that math or every spec I've seen on both the eMMC and the SD protocol are wrong. To my understanding, the eMMC bus speed (theoretical maximum) is 208 MB/s and the uSD and SD bus speed (theoretical maximum) is 104MB/s. Could you have used the -old- MMC and SD specs?

The Pandora got real world reads of just short of 20MB/s on it's SD ports. The Pyra's SoC specs call for SD bandwidth of 2.5x the Pandora's and eMMC bandwidth of twice the SD. Without the switching I'm expecting the eMMC to run around 100MB/s and the uSD card to cap around 50MB/s real world speeds. If you're copying data from one to the other (worst case scenario), Read, switch, write, validate write, switch, repeat... Each bus will be cut roughly in half and some speed will be then lost to the switching overhead.

Worst case scenario, when copying data from one to the other, that switching overhead would be half or less - that is where the 1/4 comes in. So - in that worst case scenario with worst case switching overhead taken into account, I expect the eMMC to be effectively reading at roughly 25 MB/s while writing to the uSD at 12.5 MB/s. Frankly, it should be considerably faster than that as I don't expect the switching overhead to fully half the performance.

Generally, I doubt anyone is going to be spending a lot of time copying files from the eMMC to the uSD. In cases where someone has both present, I would expect a scenario where they boot the OS from the eMMC and have /home on the eMMC.

I'm looking forward to ED being able to run some tests & benchmarks on the final boards with the 32GB eMMC and a solid uSD. I think they'll outperform my above 'worst case scenario'..

Actually we could have 4 lines on the SD card and 4 lines on the eMMC at a time (8-bit bus width). Then as soon as the device is able to cache a couple of MB on the write cache, it should do something good. I'd like to see the implementation of such driver though...

 

[TheOldOne]

1) What is the ideal MicroSD card size? My thoughts are towards 64GB but another part of me is saying bigger.

2TB but the technology isn't there yet

2) Are you going to isolate the Pyra so it doesn't require a PC for download of applications?

About as much as I do with my laptop.

3) Are you going to use the Pyra on your HD television / Monitor as a Desktop device or gaming console?

Perhaps with the CPU upgrade.

4) Where is the primary location you will be using your Pyra? Mine is away from home (particularly travelling and commuting to work)

On the bus.

5) Would the Pyra prompt you to sell other devices you might not use?

Depends on how well it can replace my hacked Nintendo DS.

 

[levi]

NDS? I've found my Pandora and DraStic have pretty much replaced my old NDS+R4.