Quite a bit for you to read!
- Thread starter EvilDragon
- Start date
gpb
Still Fresh
In my opinion the eMMC issue is not as bad as it looks. In the contrary, it shows some of the advantages of the pyra and this community.
Sure, we are all perfectionists and want the maximum out of our pyra. But I'm pretty sure you find nearly 569 other enthusiasts, who are okay with 96Mbps (theoretical limit) for the eMMC.
A normal company would just ship the product without anyone noticing such a limitation.
We are in a much more comfortable situation:
- impatient zombies, like me can take the board as is and be happy
- perfectionists wait for the second batch of CPU boards
- soldering experts could buy now and fix it for themself (and their buddies)
- and the millionaires among us could buy now and upgrade later
- fans get the opportunity for a new keychain
In my eyes that eMMC situation is not an issue, it is a test of ED's flexibility.
Sure, we are all perfectionists and want the maximum out of our pyra. But I'm pretty sure you find nearly 569 other enthusiasts, who are okay with 96Mbps (theoretical limit) for the eMMC.
A normal company would just ship the product without anyone noticing such a limitation.
We are in a much more comfortable situation:
- impatient zombies, like me can take the board as is and be happy
- perfectionists wait for the second batch of CPU boards
- soldering experts could buy now and fix it for themself (and their buddies)
- and the millionaires among us could buy now and upgrade later
- fans get the opportunity for a new keychain
In my eyes that eMMC situation is not an issue, it is a test of ED's flexibility.
AnimatedFreak
Very Active Member
- Joined
- Oct 29, 2011
- Messages
- 307
- Age
- 30
You talked before that the latest case you ordered was not transparrent but black. Is this still the case? With all the cases being ordered and if it's new once or old once I get confused :s
slaeshjag
¯\_(ツ)_/¯
By the mux merely existing, it's slowing down both.
Looking at the timings, it could be that eMMC is limited to SDR48 and µSD to DDR48, meaning both have a theoretical maximum of 48 MB/s (SI). One could really hope DDR48 is possible for eMMC, or at least SDR60, but I'm getting sceptical. Tests would have to verify this.
Grench
Forum Addict!
- Joined
- Oct 3, 2008
- Messages
- 6,629
Wow - when connected to a 5.1 interface those can be very quick indeed. They should be able to saturate the interface on the OMAP5432. How fast are they running now? What is being used to benchmark or gauge performance?
[doublepost=1490284938,1490284388][/doublepost]
Would it make any difference if the MUX was locked to one or the other instead of constantly switching? Or is it causing some impedance on the lines that is limiting data rates?
/*********/
I just had a grand and entirely impractical thought that would not be able to be implemented without major board changes. But - what if the MUXer was moved so that it did it's magic between the microSD slot and the slower of the two SDXC slots? (I seem to recall that the two SDXC slots were going to have different max specs. Could be wrong on that.)
Effectively that would make the uSD fast enough for storage/recall for media files or to boot from for playing with a 2nd OS without impacting the speed of the eMMC. It would seriously hamper the uSD's speed, but the most capacious 256GB uSD cards aren't as fast anyway. Hmmm... Entirely impractical at this stage.
slaeshjag
¯\_(ツ)_/¯
No, the problem is the speed and delay of signals going through the mux.
EDIT: Just to clarify, specifically, that half the eMMC bus gets delayed by the MUX, but not the other half, meaning that half the data might change before the clock and the rest of the data is there.
While moving the mux to external slot 2 and µSD would more or less get rid of the bottleneck, it's something that requires a new CPU board revision. It would also mean you can't boot from µSD, but that might be a small price to pay. If the µSD card slot is to stay, I see this as the most reasonable solution yet.
I'd also like to quote ED on that not using the already ordered CPU PCBs would likely cause a 3 or so month delay. There ought to be enough demand to ship the boards even with the bottleneck.
EDIT: Just to clarify, specifically, that half the eMMC bus gets delayed by the MUX, but not the other half, meaning that half the data might change before the clock and the rest of the data is there.
While moving the mux to external slot 2 and µSD would more or less get rid of the bottleneck, it's something that requires a new CPU board revision. It would also mean you can't boot from µSD, but that might be a small price to pay. If the µSD card slot is to stay, I see this as the most reasonable solution yet.
I'd also like to quote ED on that not using the already ordered CPU PCBs would likely cause a 3 or so month delay. There ought to be enough demand to ship the boards even with the bottleneck.
Last edited:
Swordfish II
Advanced Member
- Joined
- May 20, 2015
- Messages
- 1,175
Honestly I would take it with the bottleneck. As long as it can use both, and both are still faster than the Pandora...I am all good.
Grench
Forum Addict!
- Joined
- Oct 3, 2008
- Messages
- 6,629
Thank you - this is making more sense. It raises more questions though.
Will the eMMC work at all then on the current board revision with half the pins getting the latency and half not?
If both will work, but simply be considerably slower, will these boards be able to access both & flip on the fly so that both are usable in a single session? Are both currently bootable? If both of those are 'Yes', then this might be a very livable scenario.
Like I said above - Entirely impractical at this stage.
If both eMMC and uSD are fully supported at reduced speeds and able to mount both at the same time, I might be OK with that for my prototype. The deciding factor would be if they're both capable of at least 20MB/s each with combined throughput of 25MB/s and data transfer between eMMC and microSD is at least 10MB/s. Maybe a bit arbitrary, but I could live with it nicely at those speeds.
My plan had always been to boot from and keep core programs on the eMMC and load a slow/cheap 200GB microSD in to hold my primary music & video library. Any data processing and the like would hit files on the SDXC slots. It sounds like the current board might work just fine for my uses.
It sounds like the project is a few weeks out from having usable keymats and cases, so there is time to finish quantifying and fine tuning the current boards cycle. I will eagerly await more news. Thanks!
How lovely is the transparent case! I really, really want the transparent one! :~)
slaeshjag
¯\_(ツ)_/¯
As long as it goes slow enough, the eMMC will work. At SDR48, the latency should be less than half a clock cycle, which hopefully is good enough. Anyone so inclined could read up on the spec about when signals change. Switching between µSD and eMMC at apprently work to some extent. I know partially sucessfull boots from eMMC have been mentioned on IRC a while back. Don't know about the status regarding booting from µSD.
The mentioned speeds doesn't seem obviously impossible at first glance, but tests would have to be done.
Sorry for the confusion, too much work and too little sleep.
Indeed, I meant that the eMMC speed is crippled, NOT the MicroSD card speed. The MicroSD card speed should work as fast as the OMAP can handle.
Now, I don't think this will have any real effect in normal usage, as a normal Linux usually doesn't access the disk much. So unless you copy hundreds of large files regularly onto your eMMC, it probably won't be noticeable.
The crippled eMMC speed is still faster than most SD cards (needs to be tested, but it should be approximately as fast as an UHF-U3 card)
It might boot or start programs a bit slower, but whether that's noticeable needs to be tested (we'll do that).
Buying a new CPU board with a fix later on won't be that cheap though - production costs incl. parts are already more than 100 EUR. So don't bet on it.
So how could we fix it?
Most likely, there's no MUXer available that would be fast enough.
An eMMC is usually not MUXed, only SD Cards are. And eMMC are capable of being a lot faster than any existing SD Card. That's why these MUXers have no reason to be faster.
A possible fix would be MUXing the MicroSD slot with the SD Slot 2.
That means you can't use both at the same time (unless someone writes a driver for that, as it is possible!), but you can switch between both on-the-fly (without rebooting).
We'll try to make real life tests with both a MUXed and unMUXed eMMC as soon as possible (but it needs a modification on the CPU Board, so it won't happen within a day or two).
Indeed, I meant that the eMMC speed is crippled, NOT the MicroSD card speed. The MicroSD card speed should work as fast as the OMAP can handle.
Now, I don't think this will have any real effect in normal usage, as a normal Linux usually doesn't access the disk much. So unless you copy hundreds of large files regularly onto your eMMC, it probably won't be noticeable.
The crippled eMMC speed is still faster than most SD cards (needs to be tested, but it should be approximately as fast as an UHF-U3 card)
It might boot or start programs a bit slower, but whether that's noticeable needs to be tested (we'll do that).
Buying a new CPU board with a fix later on won't be that cheap though - production costs incl. parts are already more than 100 EUR. So don't bet on it.
So how could we fix it?
Most likely, there's no MUXer available that would be fast enough.
An eMMC is usually not MUXed, only SD Cards are. And eMMC are capable of being a lot faster than any existing SD Card. That's why these MUXers have no reason to be faster.
A possible fix would be MUXing the MicroSD slot with the SD Slot 2.
That means you can't use both at the same time (unless someone writes a driver for that, as it is possible!), but you can switch between both on-the-fly (without rebooting).
We'll try to make real life tests with both a MUXed and unMUXed eMMC as soon as possible (but it needs a modification on the CPU Board, so it won't happen within a day or two).
Grench
Forum Addict!
- Joined
- Oct 3, 2008
- Messages
- 6,629
Are things in place to be able to run the eMMC at slower speed and the microSD during the same session? I.e. is the MUX working properly at the reduced speeds with both devices mounted?
ible
professional vim user
put me down for being ok with SD card speeds for the eMMC. i don't anticipate copying large files on/off the eMMC.
PCXT
Very Active Member
- Joined
- Sep 14, 2016
- Messages
- 277
- Age
- 36
I have a question: In many demos I always see Pyra with GIMP. What is a real speed of operation in this program? I think not about painting a line, but e.g. messing with large selections or applying blur on a larger photo (2048x1536, I've never used bigger resolution for photos, however there were some 3100x2500 scans).
I think that access to eMMC is quite important here if there will be hibernation.
I think that access to eMMC is quite important here if there will be hibernation.
Bokkertoff
Member
- Joined
- Oct 28, 2016
- Messages
- 35
If I interpret this correctly, then 480Mb/s (SI) is theoretical max that we can get through the multiplexer. (Either uSD or eMMC).
So it should be very close to the performance you would get from a GEN1 SSD in a USB2 enclosure...
Edit: My math is letting me down... seems to be 57 MB/s
Last edited:
ashcloud
-- BANNED! -- Lactose Intolerant Volcano
But wouldn't that defy the purpose the micro-SD card slot had in the first place? I thought the idea was to be able to dual-boot without sacrificing one of the external SD card slots.
ible
professional vim user
@PCXT probably more limited by RAM there. 3100x2500 pixels is about 30 MB (assuming true-color with alpha). assuming you work with a few layers (each of which will take 30 MB), you're still well under a GB, which would be stored in working memory... (unless i'm missing something.)
you won't save to the eMMC directly as pixels either (unless you use the inefficient ppm format), so whatever format you use will probably save you some bytes for read/write.
you won't save to the eMMC directly as pixels either (unless you use the inefficient ppm format), so whatever format you use will probably save you some bytes for read/write.
Swordfish II
Advanced Member
- Joined
- May 20, 2015
- Messages
- 1,175
Everything has trade offs.
You either get full emmc speed, and don't get to boot from a microsd, or you get to boot from a microsd but have a slower emmc.
