now, my opinion about the eMMC situation: I think the goal should be maximum reliability, especially for storage
eMMC does pay more attention to reliability features, exactly because they get embedded.
And to my delight I spotted this in the "extended card specific data" of the pyra's eMMC:
user area: the device protects existing data if a power failure occurs during a write operation
For comparison, here's the same line from the Kingston eMMC on the beaglebone:
user area: existing data is at risk if a power failure occurs during a write operation
Now if you disagree with kingston's attitude towards data integrity you can set a config bit in the eMMC to fix that, but this may have unspecified performance impact, and once set the bit cannot be cleared. Nice. Of course their performance numbers are with the bit cleared, cutting corners on reliability to get better results.
SK Hynix apparently decided not to play this game, and ships their eMMC with reliability-bit already set.
I remember the Openmoko phone, which had issues with a shared channel between the video and SD card. it caused garbled SD cards every so often...not nice
hmm, this is about power then I assume? brown-outs are indeed not healthy for... well pretty much any storage medium
I simply don't want a brick when the eMMC fails, and don't plan on relying on it at all, since it can't be replaced. Is it possible to use the eMMC as read-only just for the boot-loader and then boot off the faster full size SD?
ROM can directly boot to the primary SD slot, so an eMMC failure cannot result in a brick. Also, eMMC has two special bootloader sections that use extra reliable storage. (It has two instead of one to enable atomic upgrades of the bootloader: write new bootloader to the inactive section, confirm it has been properly written, mark that section as the active bootloader.)
As others have said, I wouldn't worry that much about it. You can however also ask the eMMC to give an estimate of how far along its expected device life time (i.e. how worn-out) it is.
On a "next board revision" basis, could the mux chip be changed for one that can handle all the data lines on the eMMC? And would routing the extra data lines through the mux help the situation?
It would help somewhat, although a better solution would be to use a fast non-level-shifting analog mux followed by just a level shifter for the microSD.
The annoying thing is, it only needs to level-shift to 3.3V for legacy non-UHS cards and for the initialization phase of UHS cards. Neither of those are high-performance. But after initialization, UHS cards use 1.8V signalling too. In other words, once performance becomes important you'd want the level shifter to just... be gone.
I wonder why they found out that the storage does not work as it should only now.
I'll tell you something funny. Any previous tests would have had no chance of actually performing as well as they should. It wasn't until yesterday that I discovered that the necessary driver support isn't in mainline linux yet, I had to fish it out of some TI repository where it was implemented (mainly for the DRA7xx SoCs). It's fortunate that I can read kernel code fairly well, and have a healthy suspicion of drivers, otherwise this could have been a long search for the cause of the "missing performance".
