Memory Poll on Pyra

[xiongxioi]

I have to side with ED on this. I would never use NAND due to how hard it is to move things around with pandora control. I would not mind it that much even if it's 4gb. On the other hand, speed matters to me. 2gb of memory sounds great to me, 1ghz pandora only has 512mb, and it works like a charm in most situations. Increase it by 3 times would solve what ever debian's memory problem for at least a year or two. By then ED would have enough breath room to make an improved pyra by demand. So. There's no immediate need for these.


I hope pyra would have less white noise and an on par amplifier. But that's off topic.

 

[Grench]

We could theoretically do that through the SATA interface with an on-board adapter. More complications though.

Well, that's a interesting way to do eMMC+µSD.

Not as far fetched as you might think.

http://www.d-broad.com/db300_eg.html

Modern SD cards can outpace modern SoC's SD interface bus by 2:1 or more. Linking them into the SATA controller though - how fast can the SATA controller on the OMAP go?

This post is an exercise in 'what if' or 'wouldn't it be cool if' or 'hold my beer and check this out' and shouldn't be assumed to be a real idea.

 

[TrashyMG]

Instead of copying maybe a dd if=/dev/null of=/fileoncardoremmc might be an idea as well.

Did that on the write test.. in the second spoiler.

If TrashyMG has a probe that can measure frequency he could look at the clock pin going to the SD card slot..

I do have a decent 300Mhz oscilloscope.. I just can't find an accessible place to probe the clock pin. it's not visible on the underside of the board.. I tried it without the SD card in, but think I think the clock isn't running when the SD card is out of the socket. There is some esd circuitry I may be able to try and see if I can find the clock channel...  

Which eMMC (brand and type)? Which SD card (brand and type)?

the number on the eMMC is a SanDisk SDIN7DP2-4G (4GB eMMC) I haven't found a document on it quite yet.


I'll admit, my debian install may not have everything setup properly.. 

 

[vcoleiro1]

I think ED is right,   It's now in his hands to do some research and tests on what's best .   

 

[Grench]

Instead of copying maybe a dd if=/dev/null of=/fileoncardoremmc might be an idea as well.

Did that on the write test.. in the second spoiler.

If TrashyMG has a probe that can measure frequency he could look at the clock pin going to the SD card slot..

I do have a decent 300Mhz oscilloscope.. I just can't find an accessible place to probe the clock pin. it's not visible on the underside of the board.. I tried it without the SD card in, but think I think the clock isn't running when the SD card is out of the socket. There is some esd circuitry I may be able to try and see if I can find the clock channel...  

Which eMMC (brand and type)? Which SD card (brand and type)?

the number on the eMMC is a SanDisk SDIN7DP2-4G (4GB eMMC) I haven't found a document on it quite yet.

I'll admit, my debian install may not have everything setup properly..

I think this may be the eMMC on your dev board? Click on the specifications tab.

http://www.ssd.gb.com/index.php/products/sandisk-oem-flash/sandisk-industrial-embedded-ssd/sandisk-inand-embedded-flash-drives-efds/sandisk-inand-ultra-detail#specifications

What SD card are you using?

 

[TrashyMG]

What SD card are you using?

Came bundled with my old phone, no clue on Manufacturer... nothing on the backside either..


Picture below shows it being an 8 GB 30MB/s SDHC, but being brand-less who knows.

Spoiler

 

 

[_wb_]

We could theoretically do that through the SATA interface with an on-board adapter. More complications though.

Well, that's a interesting way to do eMMC+µSD.

Not as far fetched as you might think.

http://www.d-broad.com/db300_eg.html


Modern SD cards can outpace modern SoC's SD interface bus by 2:1 or more. Linking them into the SATA controller though - how fast can the SATA controller on the OMAP go?


This post is an exercise in 'what if' or 'wouldn't it be cool if' or 'hold my beer and check this out' and shouldn't be assumed to be a real idea.

The OMAP5432 block diagram says SATA 2.0 so I assume it can do 300MB/s.

If connecting an internal UHS-II µSD slot to the SATA interface is feasible, then that would be the best solution by far. With or without an eMMC (either would be possible). You could ship it with the µSD slot empty and a small but fast eMMC. Or you could forget about eMMC and just ship it with a µSD card.

If this is possible, it can be faster than eMMC and easily upgradeable. Best of all worlds.

 

[vcoleiro1]

How much does a decent brand UHS-II 16GB card cost?  

 

[comradekingu]

Maximum speed still is half as fast when booting from an eMMC on an OMAP5.

Maximum theoretical speed on the bus yes. Each brand and type of eMMC varies from 20MB/s through 160MB/s, and speeds all a question of money. I found references to Kingston's eMMC, but could find no benchmarks on it's actual performance. http://www.kingston.com/us/flash/emmc
Only the very fastest and most expensive eMMC is actually faster than the bus on the microSD.

Today's fastest MicroSD is already approaching bus saturation.

uSD isnt, and probably never will be, saturating the bus speed. It may meet one top end threshold on sequential read speeds. random 4k writes is in the order of a few MB/s

 

[_wb_]

Maximum speed still is half as fast when booting from an eMMC on an OMAP5.

Maximum theoretical speed on the bus yes. Each brand and type of eMMC varies from 20MB/s through 160MB/s, and speeds all a question of money. I found references to Kingston's eMMC, but could find no benchmarks on it's actual performance. http://www.kingston.com/us/flash/emmc

Only the very fastest and most expensive eMMC is actually faster than the bus on the microSD.


Today's fastest MicroSD is already approaching bus saturation.

uSD isnt, and probably never will be, saturating the bus speed. It may meet one top end threshold on sequential read speeds. random 4k writes is in the order of a few MB/s

Random 4k writes is a nice benchmark, but in most of the realistic use cases, sequential reading (and to a lesser extent, sequential writing) is more important. There is a reason why they are using bigger block sizes. You're more likely to be transferring files the size of several hundreds of kilobytes to several hundreds of megabytes than lots of randomly scattered small files. There are some small config files in /etc and perhaps some small executables and scripts in /usr, but those that are needed frequently will be in cache anyway.

How much does a decent brand UHS-II 16GB card cost?  

Today, a lot I guess. I wouldn't ship one of those now. Just a reasonably fast UHS-I card will be more than enough for now.

This UHS-II SD through SATA idea needs to be explored; even if we don't want it for the internal storage, it could be good to have it on one of the external SD slots. The speed of the SD slots is likely to become the limiting factor on the Pyra (like it was on the Pandora too) since cards already exist today that are faster than that. So it would be really nice if we can get a potential factor 3 speedup in this way.

 

[Natsu]

Today, a lot I guess. I wouldn't ship one of those now. Just a reasonably fast UHS-I card will be more than enough for now.


This UHS-II SD through SATA idea needs to be explored; even if we don't want it for the internal storage, it could be good to have it on one of the external SD slots. The speed of the SD slots is likely to become the limiting factor on the Pyra (like it was on the Pandora too) since cards already exist today that are faster than that. So it would be really nice if we can get a potential factor 3 speedup in this way.

UHS-II SD doesn't even seem to be wide spread yet. I did found this.

Link

If we use it for an external SD slot, then that just frees up a spot for the uSD.

Allwinner doesn't seem like option for SATA.

 

[klapse]

So far it looks like ED is tending to 16GB EMMC, which will be OK.

(But even my N900s have 32GB internal storage (though not reserved for the rootfs). I think it would be nice if our internal storage matched these 5 year old devices.)

 

[EvilDragon]

No, not at all. emmc sizes are pin compatible, so I'm not planning with any size yet. I'm planning with a total maximum production cost, but we don't know yet how much all parts cost and what the eMMC prices will be like when mass production starts.

 

[vcoleiro1]

^ Hopefully the screen will be cheaper by then , 70 Euro is a lot.

 IF it comes down, that will be some deserved extra profit for you or Pyra cost reduction - a bit of both maybe

 

[_wb_]

Today, a lot I guess. I wouldn't ship one of those now. Just a reasonably fast UHS-I card will be more than enough for now.


This UHS-II SD through SATA idea needs to be explored; even if we don't want it for the internal storage, it could be good to have it on one of the external SD slots. The speed of the SD slots is likely to become the limiting factor on the Pyra (like it was on the Pandora too) since cards already exist today that are faster than that. So it would be really nice if we can get a potential factor 3 speedup in this way.

UHS-II SD doesn't even seem to be wide spread yet. I did found this.

Link

If we use it for an external SD slot, then that just frees up a spot for the uSD.

Allwinner doesn't seem like option for SATA.

There's this one from SanDisk: http://www.sandisk.com/products/memory-cards/sd/extremepro-sdxc-sdhc-uhs-ii/ (280MB/s read, 250MB/s write) and this one from Toshiba: http://www.toshiba-memory.com/cms/en/products/sd-cards/exceria/exceria-uhs-2.html (260MB/s read, 120MB/s write).

We would need to find a UHS-II to SATA 2.0 bridge though -- if the bridge can only handle UHS-I, we don't gain anything since OMAP5 can do that directly already. Well, we gain one SD port, but that's it.

 

[vcoleiro1]

Wow, those UHS-II SD cards are mega expensive.  For example, that Toshiba 32GB one is $400. 

 

[_wb_]

No, not at all. emmc sizes are pin compatible, so I'm not planning with any size yet. I'm planning with a total maximum production cost, but we don't know yet how much all parts cost and what the eMMC prices will be like when mass production starts.

If you use uSD instead of eMMC, it simplifies planning a lot because you only need to buy the cards at the rate you're shipping devices -- no need to buy a pile of eMMC components before board population can start. It would significantly lower the budget needed to start a production run.

 

[Natsu]

There's this one from SanDisk: http://www.sandisk.com/products/memory-cards/sd/extremepro-sdxc-sdhc-uhs-ii/ (280MB/s read, 250MB/s write) and this one from Toshiba: http://www.toshiba-memory.com/cms/en/products/sd-cards/exceria/exceria-uhs-2.html (260MB/s read, 120MB/s write).

We would need to find a UHS-II to SATA 2.0 bridge though -- if the bridge can only handle UHS-I, we don't gain anything since OMAP5 can do that directly already. Well, we gain one SD port, but that's it.

I knew about those, but forgot where I seen the prices.

While true, it's better than one less SD port.

 

[comradekingu]

Actually it lowers the bill of material by one, if the connector for the sim is the combo sim/uSD used in the gta04. It lowers implicit production cost because you can sell devices without emmc. Also it means preflashing of OS is possible.

 

[xiongxioi]

^^^ That's definitely a valid argument, _wb_. Not sure if it will offset microSD's speed problem. I guess having less parts laying around eroding and wasting way is a good thing. It could also make replacing dead nand easier, even though Pandora rarely have the problem. I guess ED can then sell replacement OS microSDs in his shop to help any unfortunate souls revive their bricked pyras. (But if so, the assembling of Pyra must be easier than Pandora. Pandora is a nightmare to take apart and put back together without breaking anything.)