Quite a bit for you to read!

[Yori]

Well, I would max out SD card speeds if it is at all possible on future units if not these. The eMMC would really be secondary to me as I want to use my Pyra to transfer video from sd cards to a ssd connected through the USB 3 port. I did want to run the on board memory as root and have the internal SD card as /home if it was possible, but if it would make SD faster to run everything off the internal SD and turn the eMMC off then that's what I'd do. I say do everything to max out the speed of the SD cards and since the eMMC would be faster than the SD cards in a crippled state then don't worry about it.

One of the main features is the memory expandability through the 2 possible SD slots, don't let the speed of those be crippled in anyway.

EDIT: I don't know if I have seen screen shots of the OS yet but wow, these look great. One of my main gripes about the Pandora was the low resolution so when you opened up program preferences the window didn't fit on the screen so selecting options was impossible. It looks like enough is on the screen to where this won't be a problem.

Keep up the good work!

I have to agree, fast SD card support is much more important than internal eMMC. Due to being able to expand SD cards to massive storage sizes. While I could easily do without eMMC storage ;D
[doublepost=1490554164,1490553889][/doublepost]I don't mind waiting longer and buying the keychain with my Pyra! : D

Whatever it takes to get the Pyra to be the best it can be!

 

[TrashyMG]

I have to agree, fast SD card support is much more important than internal eMMC. Due to being able to expand SD cards to massive storage sizes. While I could easily do without eMMC storage ;D

The other larger normal sized SD card slots are not muxed and thus wasn't affected by the issue, it's the internal microSD slot that is. It sounds like zmatt figured a bit of performance issues out, I'm not sure it fully fixes the issue though.

Although I highly disagree that the internal eMMC is less important.

 

[Yori]

The other larger normal sized SD card slots are not muxed and thus wasn't affected by the issue, it's the internal microSD slot that is. It sounds like zmatt figured a bit of performance issues out, I'm not sure it fully fixes the issue though.

Although I highly disagree that the internal eMMC is less important.

If the 2 big SD card slots are unefected. then I change my mind. A fast internal eMMC whold be nice. ( screw the micro SD )
[doublepost=1490556133,1490554847][/doublepost]

Well the original plan was just having a switch to select between one or the other. The the cool surprise Nikolaus came up with is the muxer that was suppose to give everyone what they wanted.

Why don't we go back to the switch!

 

[lukey]

If the 2 big SD card slots are unefected. then I change my mind. A fast internal eMMC whold be nice. ( screw the micro SD )
[doublepost=1490556133,1490554847][/doublepost]

Why don't we go back to the switch!

The Switch would just toggle the MUX, so the Problem is still there. You can't just leave an unpowered Chip connected to the Same Traces. Maybe we could find an MUX without level-shifting and the same Pinout as the Current one (as these are faster) and put the Level shifter on the Mainboard (as these aren't produced yet).

 

[hns]

The Switch would just toggle the MUX, so the Problem is still there. You can't just leave an unpowered Chip connected to the Same Traces. Maybe we could find an MUX without level-shifting and the same Pinout as the Current one (as these are faster) and put the Level shifter on the Mainboard (as these aren't produced yet).

Well, in an ideal world such a chip would exist, but it does not appear to be so. In the almost ideal world, we could design our own chips. Then we would make it very fast, have level shifting and put it pin-compatible into a package of the same size... Just dreaming loudly...

BTW: I was able to merge and compile zmatt's high speed driver and it works if I reduce the optimal clock frequency of 192 MHz to 142 MHz. Then I can read the eMMC with approx. 70MB/s. With 192 MHz clock I get the console log flooded by mmc CRC errors. Maybe this will be gone after removing the mux chip on one board and bridging by tiny wires (which is work like for a neuro-surgeon).

 

[troy]

Thanks for the update hns, do you think ~70MB/s is the max we're going to get with the mux chip?

 

[AndiTheBest]

So, the emmc speed loss is not ~50%, its just ~25% in this test?
We will see the final result when the neuro-surgeon-work is done.
For me, the pyra still will be a perfect device as i think 70MB/s is pretty fast for a mobile device.

 

[Grench]

So, the emmc speed loss is not ~50%, its just ~25% in this test?
We will see the final result when the neuro-surgeon-work is done.
For me, the pyra still will be a perfect device as i think 70MB/s is pretty fast for a mobile device.

The purpose of having the eMMC is speed. microSD can do 70+MB/sec and is user upgradable/removable/replaceable.

At that point may as well drop the eMMC and add a 2nd microSD on the SoC board instead.

In theory the microsurgery that @HNC is doing should yield a board that can max out the eMMC but would have a dead microSD port for testing.

 

[Eight Bit]

So it will be something like this?

192 MB/s - max transfer speed for eMMC (ignoring mux)
70MB/s - max transfer speed for eMMC (due to mux, with lowered clock frequency)

96 MB/s - max transfer speed for μSD slot (ignoring mux)
48 MB/s - max transfer speed for μSD slot (due to mux)

96 MB/s - max transfer speed for primary SD slot
24 MB/s - max transfer speed for secondary SD slot

From this I too conclude that it's not worth having eMMC muxed with an SD slot, as a µSD without mux can be bigger and faster.
If this speed was the only factor the sane thing to do is to make a choice to build either µSD or eMMC Pyra's and ditch the mux entirely.

My preference then would still be to ditch the mux and the 3rd SD slot and go for the fastest option, the 32GB eMMC @ 192 MB/S.

K.I.S.S.

 

[comradekingu]

The bottleneck isn't 70MB/s anyway, that is more of a cap on ideal sequential reads.

I have long since forgotten the options, but uSD only + two front SD cards is what I would use.

uSD wins for me over soldered eMMC because,

- Segmentation, get the card you want,
drop a lot of money on it if you want that, get quickness or storage space.

- Modularity,
if it fails, get a new one, no need to bother ED with warranties,

-Price
Cheaper Pyra up front for the customer, cheaper Pyra to produce for ED.

- Future proof
Whatever edges a stationary target eMMC has now, are bound to be diminishing over time, especially storage size.
SD cards have seen some additional uses too, we can probably get hardware encryption in the future.

 

[Swordfish II]

The purpose of having the eMMC is speed. microSD can do 70+MB/sec and is user upgradable/removable/replaceable.

At that point may as well drop the eMMC and add a 2nd microSD on the SoC board instead.

.

Ummm no. Doing what you suggest is a complete redesign. Feel free to go do that on your own, but you don't speak for ED. If he thinks it is fine then it is.

I'm getting pretty tired of everyone telling him what he needs to do. Leave it alone until he decides what he is going to do.

 

[levi]

So it will be something like this?

Not really, no. Hns never said it can do 192MBps - he said it should clock at 192MHz. Currently he can only clock it at 142MHz which results in ~70MBps reads (which suggests a 4-bit bus to me, giving a full byte every two ticks). If that's right, 192MHz would result in ~95MBps only.

 

[Kippykip]

Wait so who's doing the speed testing?

 

[Grench]

Well, in an ideal world such a chip would exist, but it does not appear to be so. In the almost ideal world, we could design our own chips. Then we would make it very fast, have level shifting and put it pin-compatible into a package of the same size... Just dreaming loudly...

BTW: I was able to merge and compile zmatt's high speed driver and it works if I reduce the optimal clock frequency of 192 MHz to 142 MHz. Then I can read the eMMC with approx. 70MB/s. With 192 MHz clock I get the console log flooded by mmc CRC errors. Maybe this will be gone after removing the mux chip on one board and bridging by tiny wires (which is work like for a neuro-surgeon).

Several of us are curious about the opposite experiment as well.

If an SoC board has no eMMC, can the MUX be set so that the microSD is checked for the bootloader? I.e. can a Pyra boot if the only media is microSD (eMMC not populated)?

 

[levi]

If I understand how booting works in these sort of devices at all, you'll probably need a working version of uboot installed on a card in the left slot to allow booting of the OS on microSD, I think. If the eMMC is still functional, it'll use uboot on there if no full-sized SD cards containing uboot are present.

 

[slaeshjag]

Well, in an ideal world such a chip would exist, but it does not appear to be so. In the almost ideal world, we could design our own chips. Then we would make it very fast, have level shifting and put it pin-compatible into a package of the same size... Just dreaming loudly...

BTW: I was able to merge and compile zmatt's high speed driver and it works if I reduce the optimal clock frequency of 192 MHz to 142 MHz. Then I can read the eMMC with approx. 70MB/s. With 192 MHz clock I get the console log flooded by mmc CRC errors. Maybe this will be gone after removing the mux chip on one board and bridging by tiny wires (which is work like for a neuro-surgeon).

I'm curious if it still works at that speed after getting warm. That speed is like 3x faster than the timing information suggests it could run at.

 

[benoitb]

I think 70 MB/s is much faster than any mobile device's storage I have ever used. If we can get our Pyras faster and/or cheaper I would favor not changing anything hardware wise.

 

[Eight Bit]

Not really, no. Hns never said it can do 192MBps - he said it should clock at 192MHz.

I quoted that list from zmatt's post earlier in this thread.
https://pyra-handheld.com/boards/threads/quite-a-bit-for-you-to-read.80096/page-2#post-1409127

 

[EvilDragon]

I think 70 MB/s is much faster than any mobile device's storage I have ever used. If we can get our Pyras faster and/or cheaper I would favor not changing anything hardware wise.

The GPD Win does about 80MB/s in average, I've benchmarked it.

 

[matzesu]

So, then, why do you bother whit it ??? The Speed seems ok, i mean the Pandora got 256 mb, so in 3,2 Seconds, whit the Speed of the Pyra, you can shovel the whole Pandora NAND in the Ram..
I ditnt be a Tech Expert, but for me the speed sounds great..
Or is the any other disadvantage whit the current Speed ??