Overview of SoC options


If I'm interpreting this even remotely correct:  http://images.anandtech.com/doci/4153/omap5.png
How many times do I have to repeat this? That drawing isn't a peripheral list. Stop trying to decipher meaningful information from it. It's a promotional piece. It doesn't matter. Read the TRM I linked.

According to the data manual, MMC1 is explicitly an SD card interface with the card detect/protect pins as you said, MMC2 is the eMMC interface (which can double as an SD card interface), MMC3 is SDIO with extra features for WLAN, MMC4 is an SDIO interface which can double as a regular SD card interface, and MMC5 doesn't actually exist.
And if all 4 are used it means losing the ability to have SATA and IR ports. Probably minor sacrifice.
This is why you need to read the TRM I linked and go to the section I specified. The data manual describes electrical interface, the TRM describes function. And it goes so far as to give diagrams indicating that you can use an MMC or SD card in the configurations described. The part that's lacking is that only MMC1 has CD and WP pins and can operate at 3V (presumably that works with the 3.3V standard). So the others need transceivers to work with 3.3V cards or they need to be limited to 1.8V SDHC/SDXC cards.

It's on the OMAP5430, but not the 5432.
This isn't right. a) Read the TRM, it's intended for both OMAP5430 and OMAP5432, and if MMC5 didn't exist on one of the two it'd explicitly say so. B) It IS in the specific OMAP5432 data manual, as in the latest one linked by TI, revision E. I don't know how you're not seeing this. In section 5.6.14, where it says "MMC4 and MMC5—Secure Digital Input / Output Interface (SDIO)" I mean, are you actually searching for MMC5 and not finding it or what?

An SD interface is small, TI is probably not going to remove it from the package of what's almost certainly a shared die between the two models.

Hopefully this can be put to rest now.
 
Last edited by a moderator:
So, in summary: the SoC can handle it.

I agree with Grench that if eMMC is not cheaper or faster than current microSD cards, then we don't need it. I'm assuming it still is cheaper and faster. Is it worth the extra board space though?

I like the idea of easily upgradable internal storage, in terms of both capacity and speed. Even if eMMC is currently faster and cheaper, the eMMC of today wil probably be crappy compared to microSD in a few years.
 
I did a quick look for some eMMC cards and found some 16GB ones for around $20-25 from standard distributors. But no specs on performance. Some will say they support one of the eMMC protocols at X MHz, that at least gives some idea of the peak speed.

There are some clear benefits to having a microSD slot, however there are also some disadvantages. The cage itself adds some cost, can take more board space, and adds a further issue of mechanical reliability. It'd at least probably not cut it to keep it in with friction alone like the kinds you often see on dev boards, no one would want to have their primary storage disconnect accidentally.
 
Last edited by a moderator:
There are some clear benefits to having a microSD slot, however there are also some disadvantages. The cage itself adds some cost, can take more board space, and adds a further issue of mechanical reliability. It'd at least probably not cut it to keep it in with friction alone like the kinds you often see on dev boards, no one would want to have their primary storage disconnect accidentally.
I saw that in a forum comparing both microSD and eMMC :

SD cards also suck at wear leveling and most will fail long before a 
similarly used eMMC due to the internal controller designs.  Please do a 
search on SD card failures on the list, you'll find many.  I've not seen 
any complaints of eMMC failures, yet.
eMMC is cheap, cheaper than you can buy a similar sized SD card at 
retail.  It is also much easier to obtain decent eMMC in large-ish 
quantity than SD cards.
 I've seen uSD sockets fail mechanically, and on investigating them 
you can see how they are prone to that
 
I've seen uSD sockets fail mechanically, and on investigating them you can see how they are prone to that
Out of context that means little. What type of sockets were they? Was a lot of card swapping involved?

If the socket is in an out of the way location and the card is almost never removed or changed, then mechanical failure seems somewhat less likely to become a problem.

- Neelix
 
SD cards also suck at wear leveling and most will fail long before a similarly used eMMC due to the internal controller designs. Please do a search on SD card failures on the list, you'll find many. I've not seen any complaints of eMMC failures, yet.
How long do they last.

I don't want my internal boot storage to fail.

If after 5 Years my internal SD would failure then it's ok as I will upgrade anyways.

But I don't need an internal SD that breaks every now and then.

The argument against this is that if the eMMC breaks you can't replace it.

If the SD breaks just get a new one.

I don't suppose there won't be any micro SDs available in some years any more.

Also I like the face that you simply can remove your internal MicroSD, put it in any other Pyra and have your OS booting.

No need to use the big SD cards for that any more.

The more I think of it the more I like the idea of an internal UHS 1/2 micro SD.

The only downside I see is that eMMC might be faster.
 
The type and quality of the SD card holder matters. I got a phone with two TF card slots. Both of the holders are of the flip-open type, where you then pull horizonatlly to lock. One of them failed mechanically (the hinge bent) after just half a dozen of card swaps.
 
Last edited by a moderator:
This isn't right. a) Read the TRM, it's intended for both OMAP5430 and OMAP5432, and if MMC5 didn't exist on one of the two it'd explicitly say so. B) It IS in the specific OMAP5432 data manual, as in the latest one linked by TI, revision E. I don't know how you're not seeing this. In section 5.6.14, where it says "MMC4 and MMC5—Secure Digital Input / Output Interface (SDIO)" I mean, are you actually searching for MMC5 and not finding it or what?
Section A.2 of the TRM, Memory mapping: "Table rows highlighted in orange indicate modules that are not functional in OMAP5432" which includes UART6 and MMC5. Table A-29 says the same thing.
 
If after 5 Years my internal SD would failure then it's ok as I will upgrade anyways. But I don't need an internal SD that breaks every now and then.
Unless I am mistaken they are talking about controller failure, not the SD cards themselves. If the controller fails you need to replace you motherboard. But I may be misinterpreting what I quoted.
 
If after 5 Years my internal SD would failure then it's ok as I will upgrade anyways. But I don't need an internal SD that breaks every now and then.
Unless I am mistaken they are talking about controller failure, not the SD cards themselves. If the controller fails you need to replace you motherboard. But I may be misinterpreting what I quoted.
Could you please post the link to the forum?
 
If after 5 Years my internal SD would failure then it's ok as I will upgrade anyways. But I don't need an internal SD that breaks every now and then.
 Unless I am mistaken they are talking about controller failure, not the SD cards themselves. If the controller fails you need to replace you motherboard. But I may be misinterpreting what I quoted.
What you quoted specifically mentions "sd card failures".

-God Ginrai
 
If after 5 Years my internal SD would failure then it's ok as I will upgrade anyways. But I don't need an internal SD that breaks every now and then.
 
Unless I am mistaken they are talking about controller failure, not the SD cards themselves. If the controller fails you need to replace you motherboard. But I may be misinterpreting what I quoted.
What you quoted specifically mentions "sd card failures".

-God Ginrai
And this wouldn't be a big problem I think.

SD cards don't break every month.
 
Section A.2 of the TRM, Memory mapping: "Table rows highlighted in orange indicate modules that are not functional in OMAP5432" which includes UART6 and MMC5. Table A-29 says the same thing.
Well then, I stand corrected. WTF TI? You put in a little disclaimer that parts of the thing don't work or are disabled without an explanation why but don't actually include any of that in the relevant section for the perpheral? That's a really bad way to do this...

But yeah, even the data manual includes that disclaimer :/ (when it could have, you know, not even listed the peripheral) Sorry for saying you were wrong on something I was clearly wrong on.
 
Last edited by a moderator:
But yeah, even the data manual includes that disclaimer :/ (when it could have, you know, not even listed the peripheral)
It's worse. Some balls are still listed as being multiplexed for sdio5. It looks like you could "activate" sdio5 and get some data lines (at the expense of sdio4 and usbb2) but no way to actually use it in any way.It's almost like there was a bug in MMC5 and rather than fix it they just kind of hacked out the broken parts leaving a non-functional but still half-present port.

Is this normal?
 
It's worse. Some balls are still listed as being multiplexed for sdio5. It looks like you could "activate" sdio5 and get some data lines (at the expense of sdio4 and usbb2) but no way to actually use it in any way.

It's almost like there was a bug in MMC5 and rather than fix it they just kind of hacked out the broken parts leaving a non-functional but still half-present port.

Is this normal?
Well, from what you say it sounds like they just didn't have the pins for it, maybe the DDR3 interface took up more lines or maybe the package just has less balls than whatever they had for OMAP5430. I assumed this wouldn't be the case because an SD interface is only like 6 pins (for 4-bit) and you'd think they'd make it a mux option with at least something instead of flat out disabling it. It is possible that there really is some kind of bug with it but that's pretty weird given that it's not really different from the MMC4 except it supports an 8-bit interface. They could have just disabled it down to 4-bit so that's probably not it. And then OMAP5430 is supposed to have it but who knows if that's even available in any capacity at all.

I don't really know what's going on here :/

On a tangent, it sucks if Pyra really is stuck with using DDR3 over LPDDR2, throwing out quite a bit of power efficiency there..
 
maybe the DDR3 interface took up more lines or maybe the package just has less balls than whatever they had for OMAP5430.
If Google didn't fail on me the 5432 has 235 contacts less than the 5430 (745 vs 980)
 
Last edited by a moderator:
Back
Top