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

[vcoleiro1]

Were talking ARM compatible OS's .   But Natsu , you know that.

 

[Natsu]

Which isn't very likely

I guess your are right on that. :unsure:

Were talking ARM compatible OS's .   But Natsu , you know that.

Hasn't someone said that they had Window Vista running?

 

[Neelix]

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.

If you read the linked data sheet you'll see that its basically a switch, that allows you to select between 2 sets of 4 data lines.  Only one of the two sets can be used at any given time.

- Neelix

 

[Natsu]

µSSD+µSD. The fastest option, but requires the most board space and it is probably hard to find a suitable µSSD chip.

If we can find a suitable µSSD, this seem like the way to go.

If you read the linked data sheet you'll see that its basically a switch, that allows you to select between 2 sets of 4 data lines.  Only one of the two sets can be used at any given time.

- Neelix

I was leaning towards uSD+eMMc, but only two sets at a time could be bothersome. So, there's no way to just switch on/off with just the uSD and eMMc?

 

[Askarus]

Isn't the space for the uSSD better used for a big capacitor to hotswap the battery?

 

[_wb_]

Isn't the space for the uSSD better used for a big capacitor to hotswap the battery?

No. Hotswapping is not that important to me (especially if we get suspend to disk).

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.

If you read the linked data sheet you'll see that its basically a switch, that allows you to select between 2 sets of 4 data lines.  Only one of the two sets can be used at any given time.

- Neelix

Yes but how fast can it switch? I can imagine that with proper software support and if you can switch many times per second, you can effectively use both SD cards, just not both of them at max speed at the same time.

 

[Natsu]

eMMC

• 64GB: 38.00

I just looked at this. Does leaving this as the only option and have it modular just for easier replacement

if it would fail works?

 

[_wb_]

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.

All of Debian armhf in compressed .deb form is currently 43GB (source: http://www.debian.org/mirror/size), and you have to add the 87GB of no-arch data packages. I don't know how much that is when extracted, probably 200GB or so. It will only get bigger over time. I don't tend to believe statements of the form "<size> will always be enough".

Sure, we can make a compact core OS that fits in 1GB or so, and require anything else to be packaged as a PND like on the Pandora. That is not the most desirable option in my opinion.

Also, you may want to store some PNDs on your internal storage because you want to have them available all the time without having to copy them to all your SD cards.

 

[vcoleiro1]

Why would you copy the PNDs to all your SD when one SD will hold all of them which you would carry. And you still then have a free SD slot.


This is exactly what you do with the Pandora, nothing will change there.

 

[_wb_]

Why would you copy the PNDs to all your SD when one SD will hold all of them which you would carry. And you still then have a free SD slot.

This is exactly what you do with the Pandora, nothing will change there.

Some people need more than one SD card to fit all their stuff (media, ROMs, etc).

 

[vcoleiro1]

I can understand different cards for other stuff if you exceed there limit. But you said something completely different ie that all your PNDs need to go on all your SD cards, which isn't true. Basically, you miss said what you meant to say , fair enough

 

[_wb_]

I can understand different cards for other stuff if you exceed there limit. But you said something completely different ie that all your PNDs need to go on all your SD cards, which isn't true. Basically, you miss said what you meant to say , fair enough

Also, you may want to store some PNDs on your internal storage because you want to have them available all the time without having to copy them to all your SD cards.

My main point was that if you want to install a large subset of all of Debian, size will become an issue. It does not make sense to make everybody pay so we can put a 128GB eMMC in it, but if we go for a small eMMC (8, 16 or 32GB) it will at some point become too small for some people.

 

[vcoleiro1]

I agree , it doesn't make sense to make everybody pay for the few that will want that stuff. All that stuff compressed (130GB) wouldn't even fit on a 128GB card - that's a lot of stuff


By the way, this is the bit you didn't mean to say "having to copy them to all your SD cards."

 

[levi]

I would rather go for a moderately sized eMMC and be forced to extend over to SD if I wanted to install too much optional stuff. And I think the total size of the armhf repository is a bit of a red herring - conflicts will stop you install all of it at the same time. My current day-to-day install of Debian Xfce x86 fits in 15GB, not including the home directories, and I don't recall ever having cleared out unused packages yet.


Granted, a too small size will force whatever percentage of users who want to go above that to work around it, but too big will inflate the cost of the Pyra for everyone. I'd posit that 16GB of internal storage and a not insane OS install would probably only inconvenience 10% of users at most. Meanwhile an extra 16GB of eMMC storage (32GB versus 16GB) seems to cost rather more than 16 GBP, so I think if that money can be saved for 90% of users it's worthwhile.


Of course, if the internal storage is module (either uSD or pluggable eMMC) then the inconvenience is even less, but I don't know how much install a socket/ports and supplying a standard 16GB part for it would cost compared to hardwired eMMC. Maybe it's still worth saving that money for the inconvenience of only a small fraction of users.


I guess we could use the poll results above to work out what most people would be willing to pay. At present almost a third of users would pay an extra $20 for their chosen solution, while over half the people would add less or even want to make it as cheaply as possible regardless. That's probably worth taking into account.

 

[_wb_]

I would rather go for a moderately sized eMMC and be forced to extend over to SD if I wanted to install too much optional stuff. And I think the total size of the armhf repository is a bit of a red herring - conflicts will stop you install all of it at the same time. My current day-to-day install of Debian Xfce x86 fits in 15GB, not including the home directories, and I don't recall ever having cleared out unused packages yet.

I don't think there are that many conflicting packages to significantly change the ballpark figure I gave.


"Extend over to SD" is only possible if the SD-card is permanently inserted. You could do that with an internal µSD card, but not really with an external card (unless you are very careful to never remove it, but that kind of defeats the purpose of an external card slot).

Granted, a too small size will force whatever percentage of users who want to go above that to work around it, but too big will inflate the cost of the Pyra for everyone.

Exactly. That is the reason why I think we need upgradeable internal storage: no cost inflation (because you can ship with a small size or different sizes), and no limitations.

Can someone find the extra cost of a SIM/µSD combo slot instead of just a SIM slot, in terms of price and board space? My guess is that it is negligible.

I would personally like to have a relatively small µSSD (8 or 16GB) at good speeds, e.g. one of these:

http://www.foremay.net/oc177-ssd-solid-state-drive-flash-hard-drives.htm

http://www.sandisk.com/products/embedded/issd/i110/

http://www.siliconmotion.com/A3.2_Partnumber_Detail.php?sn=23

http://www.innodisk.com/Product/ProductDetail.aspx?SUQwMT0wMDEmSUQwMj1lZTU5MTNlMC1iYTM5LTRkMDYtYWRmZi0zMzE4ZjVhMTU4YmImSUQwMz0mSUQ9NWUyZDVmYmEtYWYxOS00OTkwLTg0MDItZTRjY2Y2NTFlOTNiJmRmbF9JRD0wMDE%3d

and on top of that, a SIM/µSD slot that can be empty by default, but can be used to add 64GB (and in the near future probably 128GB) of internal storage.

That way, we get more speed, reliability and upgradeability than with an eMMC-only solution.

 

[hns]

Can someone find the extra cost of a SIM/µSD combo slot instead of just a SIM slot, in terms of price and board space? My guess is that it is negligible.

Yes. As usual price depends on quality and quantity.BTW: the last prototype ED did show a photo is prepared to test a SIM/uSD slot (same as used in the GTA01/02/04 devices). The reader is robust and it is even easier to insert the SIM card than into a SIM only reader.

 

[_wb_]

Can someone find the extra cost of a SIM/µSD combo slot instead of just a SIM slot, in terms of price and board space? My guess is that it is negligible.

Yes. As usual price depends on quality and quantity.
BTW: the last prototype ED did show a photo is prepared to test a SIM/uSD slot (same as used in the GTA01/02/04 devices). The reader is robust and it is even easier to insert the SIM card than into a SIM only reader.

Could you clarify if it would be possible to have two full SD slots, one µSD, one eMMC and wifi/BT over SDIO? Would that switching component you talked about allow that (at the cost of lower bandwidth), or would it merely be a way to have 4 potential storage options with only 3 of them usable at the same time?

If it's the former, then I think eMMC+µSD for internal storage would be best. If it is the latter, then I think SATA µSSD+µSD (if feasible) or µSD-only (if µSSD is not feasible) are the best options.

 

[Grench]

I don't understand why we would want to have wifi/BT over SDIO instead of one of the USB 2.0 ports on the internal hub. Wifi over SDIO is simply slower - and it's an old kludge. We have plenty of USB ports on the SoC (Internal USB 2.0 hub). We're only exposing 1. Why not use one or more of the others for wifi/BT?

 

[TrashyMG]

I don't understand why we would want to have wifi/BT over SDIO instead of one of the USB 2.0 ports on the internal hub. Wifi over SDIO is simply slower - and it's an old kludge. We have plenty of USB ports on the SoC (Internal USB 2.0 hub). We're only exposing 1. Why not use one or more of the others for wifi/BT?

SDIO is a much more power efficient bus vs USB.

 

[Exophase]

I don't understand why we would want to have wifi/BT over SDIO instead of one of the USB 2.0 ports on the internal hub. Wifi over SDIO is simply slower - and it's an old kludge. We have plenty of USB ports on the SoC (Internal USB 2.0 hub). We're only exposing 1. Why not use one or more of the others for wifi/BT?

Because, as gta04 explained, there aren't USB wifi/BT chips to begin with (and as TrashyMG and I have added it's not power efficient, furthermore it'd take away from the current you can provide to external USB devices). Besides, you're wrong about USB 2.0 being faster than SDIO. SDIO's peak transfer speed is the same as SD, something over 90MHz for OMAP5432, and there shouldn't be much problem in coming close to saturating that connection. In theory USB 2.0 can transfer 480Mbit/s which should mean 60MB/s, but in practice it never hits anywhere close to that because of the overhead in the format. The best anyone gets with a single device is around 30MB/s, you can tell that the interface is limiting to this by benchmarking a USB 3.0 flash drive in both USB 3.0 and 2.0 ports.

But if they use a module like this http://www.murataamericas.com/murata/murata.nsf/innovations_sn1857brief.pdf the peak rate is only 65Mbit/s anyway, so it's moot.