[poll; updated] eMMC vs. uSD; modular eMMC

[WizardStan]

Can someone explain what problem the USB drive is theoretically trying to solve? I seem to have completely missed the point and don't understand what's going on anymore at all.

 

[vcoleiro1]

^ Its not trying solve anything, it was only mentioned as a removeable storage option, 1 person seemed to object to them being seen as a removeable storage option. 2 pages of arguments over that point ensued. Ahh, the Pandora Forum lol

 

[WizardStan]

Got it. I was worried I'd missed some big suggestion about using USB as bootable instead of either eMMC or microSD.

 

[vcoleiro1]

Unfortunately my question to gta04 got drowned out in all this, so I'll ask it again.

@gta04

What eMMC do you have in mind for the Pyra?, like what size , what category 4.5 or 5.0 (has 5.0 been looked into), and what speeds?

 

[hns]

Unfortunately my question to gta04 got drowned out in all this, so I'll ask it again.

@gta04

What eMMC do you have in mind for the Pyra?, like what size , what category 4.5 or 5.0 (has 5.0 been looked into), and what speeds?

Nothing specfic, since it is a standard. OMAP5 is the limiting factor (unless we choose a different one): "Full compliance with MMC/eMMC command/response sets as defined in the JC64 MMC/eMMC standard specification, v4.5"

 

[thatgui]

I could see a case for using that to switch between an on board eMMC and a uSD slot, but not for swapping one of the main SD slots for a uSD.

second

 

[comradekingu]

I tried to add some substance to the usb wifi/bt combo problem http://boards.openpandora.org/topic/15262-thoughts-on-wireless-hardware/#entry316133/URL]

 

[_wb_]

Since we will probably need a SIM slot anyway, we can just as well have a SIM/µSD combo instead. Upgradeable internal storage capacities are a good thing for making it future proof. External storage options are not a full substitute for internal storage; e.g. you cannot (or at least should not) install .deb packages on a card or USB flash drive that can be ejected at any time.

The only benefit of eMMC over µSD is extra speed, since they tend to be better optimized for random access and the max bus speed is 200MB/s for eMMC and only 100MB/s for SD. To that my first answer was: 100MB/s is good enough, linux can do caching for us. Still, people insisted that speed is crucial (they want it to boot in 5 seconds instead of 6 or something, I don't know). So my second answer was: OK then, let's use a small SSD (non-upgradeable, small capacity) over SATA (an interface that would otherwise be unused), which has a max bus speed of 300MB/s on the OMAP5, and on top of that, still have the µSD in the SIM/µSD combo.

Switching between eMMC and µSD (in a way that allows you to use both at the same time, just with lower bandwidth) is also a good solution for me. The important thing to me is that internal storage can be upgraded.

 

[CrazyIvan]

^ I second that.

Upgradeable internal storage capacities are a good thing for making it future proof

And actually could decrease initial price for those who will want to buy microsd themselves for whatever reason.

External storage options are not a full substitute for internal storage; e.g. you cannot (or at least should not) install .deb packages on a card or USB flash drive that can be ejected at any time

sometimes even accidentally as there are no protection mechanisms on SD slots 

 

[Neelix]

Switching between eMMC and µSD (in a way that allows you to use both at the same time, just with lower bandwidth) is also a good solution for me. The important thing to me is that internal storage can be upgraded.

We couldn't get both going at once without sacrificing another interface. I see the 2 external full size cards and the wifi/BT as being non-negotiable, which effectively rules that out.  I do like the idea though of having a set eMMC onboard, and then allowing the end user to override (and disable) it by inserting a micro-USB card.  That way if the eMMC should die,  there's a way to replace the internal storage without doing surgery on the PCB, or if the end user wants to sacrifice some speed for larger internal storage they also have that as an option.

The only trouble I can think of with this idea is that the chip gta04 linked earlier only switches 4 data lines,  which means that unless there is an 8 line version of the chip it might be necessary to find a way to disable the remaining 4 data lines when switching to uSD (possibly by using a second chip of the same type connected to the same trigger?) and there may not be enough available board space.

- Neelix

 

[comradekingu]

Switching between bus-es and half-baked solutions really arent intuitive. Spend the money and space more wisely.  There was one chip (rtl8723) that could do BT and wifi on usb alone.

 

[Natsu]

^ Its not trying solve anything, it was only mentioned as a removeable storage option, 1 person seemed to object to them being seen as a removeable storage option. 2 pages of arguments over that point ensued. Ahh, the Pandora Forum lol

I'm saying it should be discounted as it compare to SD and eMMC. We are talking about storage options for inside the device.

Just wanted to clarify.

The only benefit of eMMC over µSD is extra speed, since they tend to be better optimized for random access and the max bus speed is 200MB/s for eMMC and only 100MB/s for SD. To that my first answer was: 100MB/s is good enough, linux can do caching for us. Still, people insisted that speed is crucial (they want it to boot in 5 seconds instead of 6 or something, I don't know). So my second answer was: OK then, let's use a small SSD (non-upgradeable, small capacity) over SATA (an interface that would otherwise be unused), which has a max bus speed of 300MB/s on the OMAP5, and on top of that, still have the µSD in the SIM/µSD combo.

Switching between eMMC and µSD (in a way that allows you to use both at the same time, just with lower bandwidth) is also a good solution for me. The important thing to me is that internal storage can be upgraded.

So, has this become eMMC + µSD vs µSSD + µSD?

 

[_wb_]

Well, another option could be this: http://www.ti.com/lit/ds/symlink/txs02612.pdf


So we could switch between a uSD/SIM and let's say the left big SD slot.


I have no idea if Linux can support that. And it limits the bandwidth (since only one card can be active).

"Only one card can be active": does that mean you can use both cards at the same time, but they have to share the lines so they can only get half bandwidth? Or does that mean that only one of the cards can be used?

I'm assuming/hoping that it's the former, not the latter (since you said "limits the bandwidth"). In that case it does in fact make sense to put the internal µSD and one of the external SD slots together, so the eMMC and the µSD don't interfere with one another. That would in principle allow someone to set up a RAID 1 (mirrored pair) between the eMMC and the internal µSD in order to get an automatic backup and better read performance.

 

[vcoleiro1]

As with the Pandora , the Pyra will have 2 SD slots.. These are specifically there for apps/games to be loaded on and run off. That's there purpose.
SD is a far better solution for this than a uSD thats behind the battery. These 2 SD will always have higher capacity options for a starters, have cheaper/speed options and are better accessable as they need to be for there purpose.

With eMMC , you have far better read speeds and latency than uSD. Lets not start the argument of how fast it loads the OS, I could say it will load it in half the time - saying it loads in 5 seconds rather than 6 is a comment designed specifically to be missleading. But it's more than just the load time, its also the better latency, it will also give you better OS performance. Separating the OS and Apps onto seperate storage should also help performance.
16GB (or maybe 32GB) will always have enough room for the OS, currently the OS needs what 1/2 GB . It has plenty of room for that and then some for other OS's to be on there also.
Unfortunately , becuase of the uSD OMPA5 bus limit of 100MB/s , uSD will always be slower than eMMC (for important read) no matter the uSD options available in the future.

The question I have been asking myself is this. We have eMMC OS storage and we have app/game +data storage via the 2 SD slots. Does it make sense to combine them on a uSD? If we do , what will you use the SD slots for, apps/games + data is after all there purpose.

Lets look at some senarios. In the case of having uSD for both the OS and everything else and losing eMMC. You will either :

1) Use it to put your apps/games and data on. But its not a best suited option for that , the SD slots are as per there purpose and will always have better storage options than uSD, be a cheaper/speed option and more easily accessable for this purpose. You've got to wonder , how many would use it for this if the SD slots are better suited. If were talking about the minority, is it worth losing the eMMC OS performance for everyone, to satisfy the few?.

2) Not use it for data/games + data because the SD slots are better suited . Which negates the need for uSD as it wouldnt be used.

Do the the above scenarios warrant the loss to everyone, of faster OS load and performance (latency etc), when the SD slots are there itching to be used for there purpose which they are better suited for?

Being able to put a bigger uSD in the future , means nothing for the OS, as they will all fit now on eMMC(16GB or 32GB) with a lot of space to spare. The current Panora OS takes up 1/2 GB.

Even a bloated Windows RT plus Office plus built in Apps takes up less than 16GB - ie the most bloated OS and Apps. If you look at Windows Vista 7 years ago for desktops, it needed under 15GB , 7 years later, Windows 8.1 still is around the same size. 

Then along with the loss of performance you have the issue Exophase talked about , ie if everyone has different performance uSD cards , they all have different app experiences on there Pyra - That's not helpful for devs like Exophase for the reasons he pointed out .

Also, of mention is power consumption.  One of the three benefits of eMMC along with speed etc is power consumption, it is one of the main reasons mobile tech makers use it.   eMMC uses about 1/4 or less  the power used by uSD cards.   Have a look at the link below,  just to match the Nand speed of the current Pandora ~ 50-60 MB/s according to Wizardstan , an SD draws 1.44Watts - thats up there with modern SOCs under load.  And if you wanted a 90MB/s read speed uSD which is still substantially slower than eMMC options.  Youre lookiing at a power draw of 2.88Watts .  

http://en.wikipedia.org/wiki/Secure_Digital#Power_consumption 

Next , what sort of support issues can we expect with a uSD, Lets look on the GCWZERO forum , it uses a uSD for the OS
http://boards.dingoonity.org/gcw-help/corrupt-filesystem/
http://boards.dingoonity.org/gcw-help/(work-around)-possible-short-term-fix-for-sd-problems-7614/
http://boards.dingoonity.org/gcw-help/where-can-i-send-my-defective-gcw-for-servicing/
etc etc
^ Do we really want this

 

[_wb_]

So, has this become eMMC + µSD vs µSSD + µSD?

 

Not really. I suspect that some people would be fine with only eMMC; I personally would be fine with only µSD. Also, eMMC+µSD has the problem that the SoC only supports 4 SD/eMMC cards (and we already need 3 for the external SD slots and wifi/BT; wifi/BT could maybe also be done over USB but it would be less power-efficient). And µSSD has the problem that ultra-low-power ultra-small fast SATA 2.0 SSDs are not easy to find.

 

So there are four options:

• eMMC only. Not upgradeable, can be fast, should be easy to source.
• µSD only. Upgradeable, tends to be slower, trivial to source. No additional board space required.
• eMMC+µSD. Combines the above two, but requires two out of {eMMC,µSD,SD,SD} to share a SoC connection, reducing their bandwidth when used together
• µSSD+µSD. The fastest option, but requires the most board space and it is probably hard to find a suitable µSSD chip.

I'm fine with anything except the "eMMC only" option.

 

[Natsu]

uSD is for backup if the the other internal storage fails and some random files. uSD can beat the speed of finite storage later on and can have a bigger capacity for multiple OS.

 

[vcoleiro1]

uSD is bus limited to 100MB/s now and forever, ie it will never beat eMMC for read speed which is the important one. It's also worse for latency - which may/maynot change. But Exophase , several others and myself have said this now several times.


What bigger OS, the biggest and most bloated is Windows RT . Windows RT plus Office plus built in Apps takes up less than 16GB - ie the most bloated OS and Apps. As I said ,eMMC will be fine for the current 1/2 GB OS and several other on there for that matter.

 

[Natsu]

What bigger OS, the biggest and most bloated is Windows 8.1 for mobile and its under 10GB.     As I said ,eMMC will be fine for the current 1/2 GB OS and several other  on there for that matter.

Why are we limiting this to other mobile OS? Besides, future proofing.
What about if the eMMC failed?

 

[thatgui]

uSD is for backup if the the other internal storage fails

Which isn't very likely

 

[Askarus]

The uSD and eMMC combination is also a nice idea.

Main OS on eMMC and /home on uSD.

I would not want to share the lines with the Big SD-Slots.

Other question:

Allwinner and Qualcom are still not out of the question.

Would they have more options than OMAP?