Author Topic: eMMC library  (Read 8400 times)

0 Members and 1 Guest are viewing this topic.

Offline Boomerang

  • Regular Contributor
  • *
  • Posts: 52
eMMC library
« on: November 26, 2015, 09:02:34 am »
Is there any good library for reading/writing blocks from/to eMMC chip that will work on Cortex-M3 ? Is it one same library for SD cards and eMMC or they are separated ?
 

Online blueskull

  • Supporter
  • ****
  • Posts: 13215
  • Country: cn
  • Power Electronics Guy
Re: eMMC library
« Reply #1 on: November 26, 2015, 09:12:32 am »
Is there any good library for reading/writing blocks from/to eMMC chip that will work on Cortex-M3 ? Is it one same library for SD cards and eMMC or they are separated ?

Should be the same, if you do not use MMC specific commands.
 

Offline Boomerang

  • Regular Contributor
  • *
  • Posts: 52
Re: eMMC library
« Reply #2 on: November 26, 2015, 11:53:41 am »
If it's the same - it should support 1, 4 and 8-bit bus, right? Where I can find such a library? What are you using for this purpose?
 

Online blueskull

  • Supporter
  • ****
  • Posts: 13215
  • Country: cn
  • Power Electronics Guy
Re: eMMC library
« Reply #3 on: November 26, 2015, 01:02:28 pm »
If it's the same - it should support 1, 4 and 8-bit bus, right? Where I can find such a library? What are you using for this purpose?

Plenty of libraries support SPI mode. I never tried to use SDIO mode.
 

Offline Boomerang

  • Regular Contributor
  • *
  • Posts: 52
Re: eMMC library
« Reply #4 on: November 26, 2015, 01:12:55 pm »
From Wikipedia:
Quote
The eMMC (embedded MMC[7]) architecture puts the MMC components (flash memory plus controller) into a small ball grid array (BGA) IC package for use in circuit boards as an embedded non-volatile memory system. This is noticeably different from other versions of MMC as this is not a user-removable card, but rather a permanent attachment to the circuit board. eMMC also does not support the SPI-bus protocol.

Is this true or it's outdated?
 

Online blueskull

  • Supporter
  • ****
  • Posts: 13215
  • Country: cn
  • Power Electronics Guy
Re: eMMC library
« Reply #5 on: November 26, 2015, 01:21:31 pm »
From Wikipedia:
Quote
The eMMC (embedded MMC[7]) architecture puts the MMC components (flash memory plus controller) into a small ball grid array (BGA) IC package for use in circuit boards as an embedded non-volatile memory system. This is noticeably different from other versions of MMC as this is not a user-removable card, but rather a permanent attachment to the circuit board. eMMC also does not support the SPI-bus protocol.

Is this true or it's outdated?

Unfortunately it is true. Seems you can only operate eMMC with MMC or SDIO interface, not SPI interface.

I have no idea where can I find an open source SDIO library.
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 1469
  • Country: 00
Re: eMMC library
« Reply #6 on: November 26, 2015, 01:23:01 pm »
Does it need to be connected to the outside world?
If not, why don't you use a generic flash memory chip with SPI?
The programming interface is much easier.
 

Offline Boomerang

  • Regular Contributor
  • *
  • Posts: 52
Re: eMMC library
« Reply #7 on: November 26, 2015, 02:14:29 pm »
Does it need to be connected to the outside world?
If not, why don't you use a generic flash memory chip with SPI?
The programming interface is much easier.

It will be connected only to my MCU. eMMC has so many advantages over the generic flash - it will take me years of coding and testing if I want to reach the same level of reliability with generic flash!
 

Online blueskull

  • Supporter
  • ****
  • Posts: 13215
  • Country: cn
  • Power Electronics Guy
Re: eMMC library
« Reply #8 on: November 26, 2015, 02:21:19 pm »
Does it need to be connected to the outside world?
If not, why don't you use a generic flash memory chip with SPI?
The programming interface is much easier.

It will be connected only to my MCU. eMMC has so many advantages over the generic flash - it will take me years of coding and testing if I want to reach the same level of reliability with generic flash!

Why not solder a microSD socket and populate a card in it?

Or directly solder a microSD on board?
 

Offline Boomerang

  • Regular Contributor
  • *
  • Posts: 52
Re: eMMC library
« Reply #9 on: November 26, 2015, 02:34:31 pm »
SD cards don't have ECC, bad block management, block refresh after read errors and etc....
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 18902
  • Country: nl
    • NCT Developments
Re: eMMC library
« Reply #10 on: November 26, 2015, 02:47:35 pm »
Does it need to be connected to the outside world?
If not, why don't you use a generic flash memory chip with SPI?
The programming interface is much easier.

It will be connected only to my MCU. eMMC has so many advantages over the generic flash - it will take me years of coding and testing if I want to reach the same level of reliability with generic flash!
Why do you think that? Flash usually is single level cell so more reliable to begin with and if you store data in a circular way then you'll wear each flash cell equally. Implementing & testing this takes a few days (been there/done that). If you want to make it fancy you can do a write/verify and write the next piece of flash if the verify fails. If each record has a checksum then a valid checksum can be used to check whether the data is valid.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online blueskull

  • Supporter
  • ****
  • Posts: 13215
  • Country: cn
  • Power Electronics Guy
Re: eMMC library
« Reply #11 on: November 26, 2015, 02:53:04 pm »
SD cards don't have ECC, bad block management, block refresh after read errors and etc....

Panasonic manufactures high-rel SD cards, along with microSD ones. Their MLC based devices are not too expensive (about 4x toe cost compared to consumer ones).
 

Offline Boomerang

  • Regular Contributor
  • *
  • Posts: 52
Re: eMMC library
« Reply #12 on: November 26, 2015, 03:49:54 pm »
SD cards don't have ECC, bad block management, block refresh after read errors and etc....

Panasonic manufactures high-rel SD cards, along with microSD ones. Their MLC based devices are not too expensive (about 4x toe cost compared to consumer ones).

Even if I have hardware ECC - the rest of the block management will be up to me... I don't see any reason to write all this when it's already done and integrated into the eMMC controller.
 

Online blueskull

  • Supporter
  • ****
  • Posts: 13215
  • Country: cn
  • Power Electronics Guy
Re: eMMC library
« Reply #13 on: November 26, 2015, 04:05:00 pm »
SD cards don't have ECC, bad block management, block refresh after read errors and etc....

Panasonic manufactures high-rel SD cards, along with microSD ones. Their MLC based devices are not too expensive (about 4x toe cost compared to consumer ones).

Even if I have hardware ECC - the rest of the block management will be up to me... I don't see any reason to write all this when it's already done and integrated into the eMMC controller.

Google Panasonic Industrial SD card first, please. They are fully managed SD cards (actually most SD cards are, but SD specification does not mandate this, so a Panasonic will give you more confident, since they rated their product with this capability).
 

Offline poorchava

  • Super Contributor
  • ***
  • Posts: 1556
  • Country: pl
  • Troll Cave Electronics!
Re: eMMC library
« Reply #14 on: November 26, 2015, 04:11:52 pm »
If eMMC doesn't support SPI,  then you'll need to use a CPU which has a hardware SDIO module. The SDIO protocol is proprietary,  much like MIPI DSI and CSI stuff. You need to pay membership fees to have access to documentation. It is possible though to implement communication using a hardware module without having the documentation. Can't tell you details, but I know for a fact that it can be done.

Sent from my HTC One M8s using Tapatalk.

I love the smell of FR4 in the morning!
 

Offline MT

  • Super Contributor
  • ***
  • Posts: 1283
  • Country: cn
« Last Edit: November 26, 2015, 04:29:19 pm by MT »
 

Offline Boomerang

  • Regular Contributor
  • *
  • Posts: 52
Re: eMMC library
« Reply #16 on: November 26, 2015, 04:29:16 pm »
If eMMC doesn't support SPI,  then you'll need to use a CPU which has a hardware SDIO module. The SDIO protocol is proprietary,  much like MIPI DSI and CSI stuff. You need to pay membership fees to have access to documentation. It is possible though to implement communication using a hardware module without having the documentation. Can't tell you details, but I know for a fact that it can be done.

it's a JEDEC standard available for download - if there is no good library for this - I will have to write my own.
 

Offline marshallh

  • Supporter
  • ****
  • Posts: 1462
  • Country: us
    • retroactive
Re: eMMC library
« Reply #17 on: November 26, 2015, 11:53:37 pm »
There is some confusion.


SD cards can be accessed either by SPI or the SD protocol (1/4bit) with its UHS-I/II extensions. You can implement the full SD protocol with completely accessible documentation (Simplified SD Spec 4.10 from the SD Association)

SDIO is a standard for interfacing periperals like network cards, cameras and card readers over the SD bus. It does not define the lower protocol, which is the SD protocol.


eMMC is basically a hard-wired SD card with functionality that is a superset of SD (which is itself a superset of original MMC). You should be able to access it with the same MCU peripheral you use to read a 4-bit SD card, or FPGA IP core.


Internally, these types of memory cards contain deceptively powerful 32bit ARM cores (typically) running a small RTOS that provides all manner of NAND babysitting like bad block mapping and on-demand reallocation (garbage collection). Modern MLC flash requires pretty complex error correction to even function -- the data stored on NAND is more like a stasticial approxmiation of what the data "should" be. BCH is basically the bare minimum to get meaningful data - which is probably done in software with some parts accelerated on die.

Lukcily you don't need to worry about all that, it's abstracted away by the controller on the memory. You just tell it "I'd like to read 26 sectors starting here" or "I'd like to write at least 60 sectors, so pre-erase them for me and then I'll send the data".
So, first talk to a normal SD card, then grab an emmc and take it from there.
« Last Edit: November 26, 2015, 11:56:44 pm by marshallh »
Verilog tips
BGA soldering intro

11:37 <@ktemkin> c4757p: marshall has transcended communications media
11:37 <@ktemkin> He speaks protocols directly.
 

Offline Boomerang

  • Regular Contributor
  • *
  • Posts: 52
Re: eMMC library
« Reply #18 on: November 27, 2015, 07:52:55 am »
OK, the question now turns to "is there some good library for working with SD cards over SD protocol?"
« Last Edit: November 27, 2015, 07:56:58 am by Boomerang »
 

Offline Boomerang

  • Regular Contributor
  • *
  • Posts: 52
Re: eMMC library
« Reply #19 on: November 27, 2015, 09:03:21 am »
The main reason I'm planing to use eMMC is their capability to detect data retention errors and refresh the blocks when such errors are detected. I don't know any SD card capable doing this.
 

Online blueskull

  • Supporter
  • ****
  • Posts: 13215
  • Country: cn
  • Power Electronics Guy
Re: eMMC library
« Reply #20 on: November 27, 2015, 11:47:49 am »
A warning, implementing SD protocol requires SD patent license, despite it could be long expired if you use the oldest protocol.

If you implement MMC protocol, it is royalty free.

However, I would use a MCU with SDIO, and just use it, and fuck the patent. Anyway where is no way anyone will charge you.

Sue someone with copyright infringement is easy, sue someone with patent problems is extremely hard, and costly.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 18902
  • Country: nl
    • NCT Developments
Re: eMMC library
« Reply #21 on: November 27, 2015, 01:54:12 pm »
A warning, implementing SD protocol requires SD patent license, despite it could be long expired if you use the oldest protocol.

If you implement MMC protocol, it is royalty free.

However, I would use a MCU with SDIO, and just use it, and fuck the patent.
I would assume the SDIO royalties are already paid because the MCU already has the interface.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline dgtl

  • Regular Contributor
  • *
  • Posts: 165
  • Country: ee
Re: eMMC library
« Reply #22 on: November 29, 2015, 05:30:04 pm »
The SD cards must have ECC inside them; otherwise they would be unusable. Modern NAND flash chips require ECC to work at all (bit flips are part of "normal" operation). Even SLC flashes now require 4 bits correction capability, MLC and TLC flashes much more. Consumer-grade SD cards seem to lack proper wear levelling and die when some areas are written more.
There are enough industrial quality SD card vendors, even in micro-sd format. For example Swissbit, Panasonic, Apacer Industrial etc. If SD format is preferred, go for them. But the advantage of removable storage is the possibility of user swapping in whatever flash they want and that causes problems if they use inferior quality flashes. In these cases, reducing the functionality by having on-board flash is a good choice.

Driving an eMMC chip using microcontroller SDIO interface is not too difficult. The lower layers are the same (sending commands and payload data). Commandset-wise they are somewhat different (at least initialization). Download the eMMC spec (free) and just re-write the init commands. The spec may be frightening at first, but go for the state diagram and command code list for better overview. As the chip is soldered on board, you can probably avoid most of the auto-detection and just hardcode the geometry.

The eMMC has 8-bit interface, that is good for performance without getting clock rate too high. I've used eMMC flashes on STM32F2 uCs and the data rate was limited by the eMMC chip itself (we wrote the whole code ourself). When going for high-performance, read thoroughly the random-access specification of the eMMC chip. Linear bulk transport figures are specified for very large buffers (ie 1MB) and that is not available on uCs. You should see the random-access performance numbers, these are written as IOPS (read small print: IO operations per second for 4kB blocks). There is a large penalty of starting a new transfer and even for double-buffered 2x32kB blocks, you wont get near the linear transfer rate. But 200Mbit/s read rate is totally possible using ver 4.51 Micron chips.

On larger application processors, using eMMC instead of SD card is usually easier as the eMMC layer drivers in Linux and u-boot are already there and the SDIO controller does not care. Usually just designing the eMMC instead of SD socket works with very little effort.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf