Quite a bit for you to read!

[Grench]

The EVM at least can boot from eMMC, SD, USB or SATA... the Pyra I believe should still have this feature.

The way I recall it... The OMAP5432 actually only has native interfaces for 1 eMMC and 1 SDXC. On the Pyra, the eMMC lines are multiplexed to create the microSD interface. The 2nd (right?) SDXC port is run off of GPIO. The eMMC and microSD can both be bootable because they're really the same interface run through the MUX. The left SDXC port is direct to SoC and bootable. The right SDXC port, being derived form GPIO is slower and not bootable.

So, someone who understands it better, please correct me if I got that wrong.

 

[Christoph.Krn]

140 MB/s - sequential write speed claimed by eMMC manufacturer

Rated figures are something insane like 270 MB/s read, 140 MB/s write. Those read speeds are better than what the OMAP5 eMMC interface supports.

SK hynix H26M64208EMR

Is the eMMC part capable of random reads & writes at faster than 80MB/s?

Yes, considerably.

I'm not sure either if this issue really matters. I've tried different SD cards as OS storage in the past, as long as read and write IOPS were high and reliable, it was fine for general use (except when copying or working with big files, but since 16GB is rather small these days and there's plenty of expansion space in the Pyra...). This was over five years ago, < 80MB/s. In the end, very high random read/write speeds only do so much when the usage primarily revolves around bursts of numerous of small-ish accesses. Eventually limiting factors also appear elsewhere, like @Bokkertoff already suggested.

I'm really looking forward to those tests, I can not imagine that killing the right-hand SD card slot's independence would be worth it.

 

[Grench]

I'm really looking forward to those tests, I can not imagine that killing the right-hand SD card slot's independence would be worth it.

Mmm... if you're referring to my admittedly far fetched idea of MUXing the right SDXC slot to the microSDXC slot, that should not actually slow down the right SDXC slot. If I understand correctly, that one is already slower as it runs off of GPIO. It would effectively slow down the microSDXC to the speed of the GPIO based right SDXC slot though. Using the two simultaneously (run with both mounted) would require a driver to be built to handle the MUX (just like for the eMMC to microSDXC would).

If we're going to explore this hypothetical though...
An equally theoretical far fetched idea may be to MUX the microSDXC slot with the LEFT SDXC slot. Both would theoretically be bootable. Both would theoretically run at the highest speed when used independently. The MUX switch should be more compatible with those data lines. It would not slow down the eMMC. Effectively it would be the solution we wanted (3 bootable devices) without the drawbacks of the MUX on the eMMC data lines. Hmm... Would require board revisions to get there.

 

[rohezal]

Can we have a (mechanial?) switch instead of a MUX for choosing to boot from micro SD card or EMMC?

 

[Bokkertoff]

Those read speeds are better than what the OMAP5 eMMC interface supports.

What are the max speeds the OMAP5 can do ?

 

[second exodous]

I say slap those 570 in a limited edition case, a color that will only be made for those, and say sure the eMMC is crippled but it is in a _____ limited edition case! Then, on the next batch fix the problem. It seems from reading posts on this forum there are a lot of people really concerned about the color of the plastic that houses the electronics so I'm sure there are 570 people that would be ok with the trade off.

 

[NetBLOKS]

I don't think it would be wise to mux the second SDXC slot. The slot is always accessible to the user, in contrary to the internal storages. Disabling it when the internal usd is active looks broken and the handling would suffer.

My ranking variations:
1. Same as now with faster mux (if possible)
2. Same as now
3. Just usd
4. Just emmc

 

[Grench]

What are the max speeds the OMAP5 can do ?

https://www.datalight.com/solutions/technologies/emmc/emmc-feature-comparison-by-version

OMAP5 should be "HS200" which would be theoretical 200MB/s. The 5.1 calls for "HS400" which would be a theoretical 400MB/s. Those are max interface speeds though, not specific to the parts themselves.

 

[zmatt]

The overall bandwidth of the v4.5 connection to the eMMC never would be able to match the overall bandwidth of the v5.1 eMMC.

I've explained previously that the use of eMMC standard numbers here is not very useful. v4.5 allows a variety of connections, all of which are still valid connections for v5.1. The max speed the OMAP5 supports for the eMMC is 71% of the advertised sequential read speed of the eMMC, and considerably faster than the advertised sequential write speed of the eMMC.

Does the current solution allow for and currently work with both the eMMC and microSD concurrently mounted or can this scenario only maybe work later after someone might be able to build a driver for it?

The latter.

Can the Pyra boot from all those? I thought it could only boot from microSD and eMMC?

ROM can load the bootloader from eMMC and the primary SD slot. The bootloader (u-boot) can boot from pretty much anything.

The way I recall it... The OMAP5432 actually only has native interfaces for 1 eMMC and 1 SDXC. On the Pyra, the eMMC lines are multiplexed to create the microSD interface. The 2nd (right?) SDXC port is run off of GPIO. The eMMC and microSD can both be bootable because they're really the same interface run through the MUX. The left SDXC port is direct to SoC and bootable. The right SDXC port, being derived form GPIO is slower and not bootable.

The OMAP5432 has four MMC/SD/SDIO interfaces, used for:

1. primary SD slot
2. eMMC / μSD
3. wifi/bluetooth chipset
4. secondary SD slot

interfaces 3 and 4 are limited to 24 MB/s.

What are the max speeds the OMAP5 can do ?

See my post on page 2.

 

[Bokkertoff]

A bit more useless info:

I just did a test on an AMD Athlon XP 2000+ (1666Mhz) with 1GB DDR333 memory (2.6 GB/s theoretical max).

If I read a 700MB file repeatedly from cache (no I/O at all), I am unable to crack 150MB/s. The CPU simply isnt fast enough.

I am not sure how the cpu power of the OMAP compares to that of the Athlon (I think it will be very similar). The 2nd core of the OMAP might ofc come in to play in certain situations.

The implication is that even though the theoretical max is much higher, we might not be able to come close to that even with everything connected at full speed because the cpu becomes the next bottle neck.

 

[WizardStan]

That term really means nothing

It means precisely what you know it very well it means. Context is important. "eMMC speed" in this case means at least the theoretically fully bus speed of the OMAP5

If you zoom in enough, signals never pass through unmodified.

Again, you knew exactly what I meant. Why does this MUXer have a signal limit? Others I've used have literally just been gates flipping one pin to the other and you can pass whatever signal you want through it. Why is this one introducing a delay on some of the lines but not on others? It's bizarre.

 

[slaeshjag]

It means precisely what you know it very well it means. Context is important. "eMMC speed" in this case means at least the theoretically fully bus speed of the OMAP5


Again, you knew exactly what I meant. Why does this MUXer have a signal limit? Others I've used have literally just been gates flipping one pin to the other and you can pass whatever signal you want through it. Why is this one introducing a delay on some of the lines but not on others? It's bizarre.

It's introducing a delay on all lines that pass through it. The only lines that it doesn't delay, are the lines not passing through it. All bus trancievers and muxes will have a delay, how long it is varies. That there's a limit on bandwidth or frequency is nothing out of the ordinary, all components have that.

 

[Pocak]

What are the max speeds the OMAP5 can do ?

Combining this, this, and a bit of this, i get :

MMC1 — left SD slot — 96 MB/s

MMC2 with direct connection to µSD (4 bits) — 96 MB/s
MMC2 with direct connection to eMMC (8 bits) — 192 MB/s

MMC3 — WiFi chip — 24 MB/s

MMC4 — right SD slot — 24 MB/s

(MMC5 — not available on OMAP5432 — 48 MB/s)

Can we have a (mechanial?) switch instead of a MUX for choosing to boot from micro SD card or EMMC?

If you mean switching the data/clock lines mechanically, I doubt that's feasible, as the eMMC chip is on the SoC board. I also wonder if such a switch would pass signals cleanly enough for maximum speed. See also this post.

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.

You shouldn't expect the combined throughput to be high — switching will be "slow" (think milliseconds.) So, maybe 40 MB/s reading from one, 1MB/s reading from both.

 

[Vardius]

In my case I will probably be using the uSD more than the eMMC for most things, so I think I could live with the slower eMMC speeds.

 

[Letalis Sonus]

Why does this MUXer have a signal limit? Others I've used have literally just been gates flipping one pin to the other and you can pass whatever signal you want through it.

In this special case the delay is problematic because it makes the data signals asynchronous, half of the data signals arrive slightly earlier than even the clock signal. It simply makes the whole connection less reliable.

There's more than just the propagation delay that is limiting the IC's maximum rated speed, the signals are not just being delayed but also disfigured. There's all sorts of unwanted physical effects affecting the transmission of high frequency signals, it's handling 6 signal lines in parallel of which 5 are bidirectional after all. At some point the manufacturer simply has to include counter measurements or special transistor types to properly support higher frequencies, if they decide that they want a cheaper production or ultra low power usage etc instead you're pretty much screwed.

 

[DAP]

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.

Have a look at this part: http://www.digikey.com/product-detail/en/texas-instruments/SN74CBT3383DBQR/296-6443-1-ND/377951
If this one isn't perfect, there are a whole series of bus switch type parts from several manufacturers.
These parts act as solid state relays with near zero delay, and about 5 ohms series resistance.

 

[slaeshjag]

Have a look at this part: http://www.digikey.com/product-detail/en/texas-instruments/SN74CBT3383DBQR/296-6443-1-ND/377951
If this one isn't perfect, there are a whole series of bus switch type parts from several manufacturers.
These parts act as solid state relays with near zero delay, and about 5 ohms series resistance.

It's just about fast enough, but... It doesn't do level translation, its typical voltage supply is problematicly high, and it's huge.

 

[Caine]

Hmm... I'll await the measurements and data from ED before passing my judgement on how to best handle the eMMC issue.

 

[Calculus]

I have been reading stuff here for a while, and up until now I was content simply observing.

Is the eMMC easily replacable?

 

[AnimatedFreak]

I have been reading stuff here for a while, and up until now I was content simply observing.

Is the eMMC easily replacable?

It's on the CPU board, so it could be replace relative easy but the CPU board (which I would prefer calling SoC board tbh) also contains the SoC (Sytem on a chip, so GPU and CPU) and the Ram, meaning you have to replace those too. Which makes it more expensive.