Quite a bit for you to read!


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

There are versions of these parts that do level translation between 5V and 3.3V (I've not seen one what goes down to 1.8V though).
Presumably the port on the processor can directly connect to eMMC or an SD card, so level translation should not be necessary.
If you do need level translation on the eMMC, it won't work anyway because I've never seen a level translator with less than 5ns delay, and the lower the voltage, the longer the delay.

Even if this part has a high supply voltage, this is irrelevant to the I/O voltage since this acts as an analog switch. But if you must, there are equivalent parts with 3.3V power, and probably lower.

Without the actual requirements, I can't tell you the optimum part for this task, but there is a huge variety of parts of this style to choose from.
 
I wonder why they found out that the storage does not work as it should only now.
By spotting a certain detail in the part's documents.

From my point of view the reason is a very bad testing routine.
Nothing concerning the actual limitations has been tested, yet, this is all speculative talk based on the current implementation and what the manufacturer of the chip has rated its product for.
 
I wonder why they found out that the storage does not work as it should only now.
From my point of view the reason is a very bad testing routine. In such a project you have to test everything as soon as possible! To test everything when everything is nearly ready and partway produced is way to late.

But i know, it's to late for that now.
I wouldn't call it a "very bad testing routine", as he tests pretty much everything he receives and has been doing a pretty good job if you look at older news posts. But in the end we're all human and certain things can slip. A speed test of the eMMC probably wasn't really noticeable but diving into the target specs he probably just realised the limitations of the chip.

Also before we jump into conclusions, we don't know if it's going to be a serious issue or not as the CPU might bottleneck the speeds in the first place.
We should wait until an actual speed test is performed yet.
 
Alright I'm completely lost here

Me too, this thread has been blowing up with theoretical fixes and ways to sell the 570 flawed boards as well as opinions on how bad these boards actually are and if they should be used or not. Combine that with misconceptions because of mistranslations and flawed technical understandings of some who still want their opinion to be heard and some mix-ups in terminology because of a mistake in ED's first post and you've got this amazing thread.

I wish this board could stop poking at an issue from all theoretical angles when we don't even have all the information needed to make an educated guess. This is the keyboard threads all over again. I just hope it concludes in something similarly awesome, but I personally will do the same I did back then and remove myself from the grindy conversation that just gives me a headache the more I look at it.
 
I wonder why they found out that the storage does not work as it should only now.
From my point of view the reason is a very bad testing routine. In such a project you have to test everything as soon as possible! To test everything when everything is nearly ready and partway produced is way to late.

But i know, it's to late for that now.
Storage itself has been tested, but not the full speed.
That's not as easy as it sounds.
We tested the speed of the eMMC of the EVM, two days ago and that runs slower than on the Pyra currently.

However, it reports that it runs with 50MHz, but why?
Can't the eMMC of the EVM handle that?
Is there a bug in the driver?
Do you have to enable higher frequencies somewhere?

It's not just running a quick hdparm - that works on PCs, where the drivers are usually finished.
They aren't for the OMAP5, so before we can do a proper speed test, we need to first find out how to make it run with higher speeds. That involves reading a lot of documentation about the eMMC, OMAP5, how Linux handles it, etc.

We're getting there, no worries.
 
tmp-cam-156056936.jpg

The wait is killing me hehe
 
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".
 
Could it fail? Sure... But I don't think it will. For perspective I use the NAND on a Pandora. No issues. I also use the SSD on an original eeepc. No issues.

People will bring that up, but IMO the concern is misplaced.
Flash data density has become so high in the last few years that it's actually had an enormous impact on durability, depending on what kind of flash storage you're looking at.
 
Back
Top