how to boot an embedded system from an emmc™ …beilenet.com/download/an2539.pdf · 1 embedded...
TRANSCRIPT
November 2008 Rev 2 1/25
AN2539Application note
How to boot an embedded system from an eMMC™equipped with a Microsoft FAT file system
OverviewThis application note describes a set of solutions used to boot an embedded device from an Embedded MultiMediaCard (eMMC™) equipped with a Microsoft File Allocation Table (FAT) file system.
Currently, the growing demand of such type of devices mainly depends on the following reasons:
■ A flash card is removable (you can substitute it with another one without changing the platform).
■ They provide low-cost mass data storage, providing substantial savings.
■ Flash cards are non-volatile, and so they can be used to store permanent data and software applications.
■ Unlike simple flash memory technology on which the cards are based, the software used to manage the data blocks (garbage collection, wear leveling, etc.) is all included on the card; releasing the designer from these design constraints and enabling the use of the card as if it was a hard disk.
This last point requires practically mounting a file system onto the card. If referring to a DOS FAT32 file system, the problem consists of finding a way for the following to coexist: the eMMC™, the boot code and the DOS FAT32 structures needed by the file system itself to recognize the card formatted after the boot phase.
www.numonyx.com
Contents AN2539
2/25
Contents
1 Embedded system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Hardware environment overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Embedded system software functional architecture . . . . . . . . . . . . . . . . . . 5
2 Boot process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1 Boot timing flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Boot functional architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 Boot loaders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1 BIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Parts of a boot loader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1 Boot code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.2 Second stage of boot loader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.3 Boot loader installer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3 Boot loader features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.1 Typical boot loader functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.2 Hardware considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.3 Boot sequence on standard PC (IBM-PC compatible) . . . . . . . . . . . . . . 10
3.3.4 MS-DOS boot loader boot process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4 Where to store the eMMC boot code? . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1 Storing the boot code in the hidden sectors area . . . . . . . . . . . . . . . . . . . 11
4.2 Placing the boot code in the FAT reserved sectors area . . . . . . . . . . . . . 12
4.3 Auto-boot solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.4 Conclusions (advantages and disadvantages) . . . . . . . . . . . . . . . . . . . . . 14
Appendix A eMMC overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
A.1 Operation modes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
A.2 Physical description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
A.3 Device signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
A.4 Numonyx eMMC-like products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Appendix B FAT overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
AN2539 Contents
3/25
B.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
B.2 FAT (file allocation table) file system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
B.3 What is the master boot record (MBR)? . . . . . . . . . . . . . . . . . . . . . . . . . . 19
B.4 FAT volume structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5 Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Embedded system AN2539
4/25
1 Embedded system
1.1 Hardware environment overview An embedded system consists of:
1. a microcontroller (or microprocessor)
2. a Read Only Memory (ROM)
3. an Embedded MultiMediaCard (eMMC™)
4. a Random Access Memory (RAM)
5. a NAND flash memory device (optional)
Figure 1. Hardware environment scheme
Microcontroller
Each embedded system contains a central processing unit (CPU). In most cases, this is a microcontroller (MCU) because its characteristics make it useful to manage devices and peripherals used in this type of system environment. Today one of the most used types of microcontrollers is the 32-bit ARM processor.
Read Only Memory (ROM)
Each system must execute code from a non-volatile memory directly accessible from the MCU. A Read Only Memory (or a NAND flash memory, see below) can be used for this purpose.
Embedded Multimedia Card (eMMC™)
An eMMC™ is an embedded storage solution consisting of an MMC interface, a flash memory device and a controller, all assembled in a small ball grid array (BGA) package. This is based on MMC system specifications V4.1/4.2 and JEDEC BGA packaging standards.
Random Access Memory (RAM)
The RAM is typically the memory from which the code is executed. In the boot phase, the boot code has to be transferred to the RAM before being executed.
NAND flash memory
This kind of memory can be useful if the ROM size is too small to contain the pre-boot code. If the system is able to remap NAND to the address 0x00000000, the use of a ROM device becomes optional.
MCU
eMMC RAM ROM NAND
AN2539 Embedded system
5/25
1.2 Embedded system software functional architectureFigure 2 shows the software architecture of an embedded system based upon an eMMC.
Figure 2. eMMC used as a bootable device
User application layer
This level provides the logical mass-storage access to the specific application running on the system; for example a smartphone, a PDA, etc. The application accesses the eMMC using the application layer to read and write objects.
This level contains both the user level operating system layer and the part of the application that communicates with the card.
Microsoft FAT32 file system layer
The File System Layer provides file management commands to the user application layer and translates them in a basic file system commands flow such as read and write sectors.
eMMC protocol layer
This layer translates the sector-based commands (for example, CMD17, CMD24, CMD18, CMD25, etc.) in eMMC protocol command sequences used for managing related card responses.
eMMC low level driver layer
This software layer translates the eMMC commands into specific configurations (register setting) of the hardware host controller.
User application layer
Microsoft FAT32 file system layer
eMMC protocol layer
eMMC low level driver layer
Hardware host controller layer
eMMC card
File management commands
File system commands (R, W, etc.)
eMMC commands (CMD17, 24, etc.)
Host controller configuration commands
eMMC communication signals
Boot process AN2539
6/25
2 Boot process
2.1 Boot timing flowFigure 3 shows the sequence of the boot process performed by the embedded system. This is a two-phase boot approach that provides flexibility required for customizing the OS boot loader in compliance with system requirements.
Figure 3. Boot timing flow
ROM pre-boot
During this phase, which is executed just after the power-on, the microcontroller accesses the Read Only Memory and starts to execute the code located at address 0x00000000. This code (pre-boot code) performs the following tasks in order:
1. Initializes the data MMC bus.
2. Initializes the card by using the low level mini drivers.
3. Shadows the eMMC pre-boot to the RAM.
4. Jumps to the RAM code and starts to execute it.
eMMC pre-boot
The eMMC pre-boot contains the eMMC device drivers that implement the various eMMC protocol commands and the configuration information needed to recognize the system hardware. This information is necessary to choose the correct OS boot loader to upload.
The last operation shadows the boot loader code to the RAM.
OS boot loader
This application, strongly dependent on the OS, shadows the OS kernel to the RAM, rapidly jumping to and executing it.
ROM pre-boot
eMMC pre-boot
OS boot loader
Operating system
AN2539 Boot process
7/25
2.2 Boot functional architectureAt power-on, the system must access a non-volatile storage media (bootable device) in order to load the operating system. If we use an eMMC for this purpose, we must provide drivers and tools required to boot the system. Figure 4 shows a boot functional software architecture built to reach this goal.
Figure 4. eMMC used as a ROM
Pre-boot task (BIOS)
This application is distributed in different memories (ROM, MMC) and its purpose is to execute the eMMC device boot. In particular we have to:
● Shadow the eMMC pre-boot to the RAM and execute it.
● Shadow the OS boot loader to the RAM and execute it.
The OS boot loader will:
● Load the OS kernel.
● Load (mount) the file system onto the card.
● Return the control to the OS, which will complete the boot phase.
Low-level mini driver layer
The low-level mini driver layer contains the minimal code that is able to access the eMMC card, initialize it, and read from it the eMMC pre-boot code. No unnecessary eMMC commands are implemented here due to the small ROM size.
Host controller layer
This layer can either be made of software that directly controls the eMMC command signal pins or by a programmable hardware controller that hides the card physical layer from the microcontroller.
Pre-boot task (BIOS)
eMMC mini driver layer
Host controller layer
eMMC card
eMMC commands (a small subset)
Host controller configuration commands
Host controller configuration commands
Boot loaders AN2539
8/25
3 Boot loaders
3.1 BIOS The basic input/output system (BIOS) is the program stored in the ROM of certain electronic devices. At the power-on, the BIOS is executed first. The BIOS is made up of:
● POST (power on self test).
● The setup menu, that is useful for setting certain environment parameters and controls the clock. It is also possible to decide the boot order, selecting the devices that BIOS checks for booting.
● The boot sector loader. Loads the first sector from the boot device into RAM and executes its code.
● The BIOS interrupts. These are drivers that programs use to access the peripherals. They are used by boot loaders to perform their operations.
The BIOS is a very simple program: in fact, the only thing it knows about disks is how to load the first 512-byte sector. The first sector of a hard disk (called the master boot record) is loaded at 0000:7C00 and then the BIOS jumps to it.
The boot loader has access to BIOS interrupts, which can be invoked by the INT instruction (software interrupts). The following routines are used by most boot loaders.
● INT 0x10 for screen output.
● INT 0x16 for keyboard input.
● INT 0x13 for disk I/O.
● INT 0x15 is a catch-all for many BIOS functions, one of which is moving data to extended memory (the BIOS is required to temporarily switch to protected mode to do this).
3.2 Parts of a boot loaderA boot loader is typically made up of 3 programs:
1. The boot sector code is loaded by the BIOS at boot time and is only 512 bytes in size.
2. The second stage program is the core of the boot loader. It loads the OS kernel and jumps to it.
3. The boot loader installer is used to install the boot loader and the second stage program onto the boot disk. They must be stored in special locations.
3.2.1 Boot code
After executing the BIOS bootstrap routine, the BIOS itself reads and executes the first physical sector of the mass-storage device identified as bootable.
Usually a boot code can do one of the following actions:
1. Load a boot sector. In this case the boot code is stored in the master boot record of the device. It finds the first sector of the selected active partition, named the boot sector and loads it. The boot sector on a DOS disk does not utilize a second stage boot loader, but generally loads MS-DOS kernel (files IO.SYS and MSDOS.SYS). The MBR program that came traditionally with MS-DOS has no ability to change the active partition at boot time.
AN2539 Boot loaders
9/25
There are other boot sector programs that let you select a partition by pressing a key, such as the MBR program of LILO
2. Load the kernel directly. A kernel is typically much larger than a second stage boot loader.
3. Load a second stage boot loader.
For example, the boot sector program in the Linux kernel loads the kernel directly into memory without the need for a second stage boot loader. As the kernel is located in contiguous sectors on a diskette, there is no need to traverse file system data structures.
3.2.2 Second stage of boot loader
This is the real boot program. It contains the user interface and the kernel loader. It contains the following functions:
● User interface. It is either a simple command line, a menu or both. It allows to select any number of operating systems and to specify additional parameters to the operating system. The available options are specified by a configuration file.
● Operating system loader. Loads the operating system into memory and runs it. Alternatively we can load another boot loader specific to another operating system and let it run. This is called chain loading.
3.2.3 Boot loader installer
The third part of the boot loader is only run when the boot loader is installed on a disk. It performs the following tasks:
● Installs the boot sector. If the boot sector will be installed in the MBR of a hard disk or on a DOS file system, not all 512 bytes may be overwritten, but the partition table must be preserved.
● Tells the boot sector where the second stage boot loader is. Usually it writes one or more sector addresses into the boot loader.
● Tells the second stage boot loader where all relevant information is (configuration, kernels).
3.3 Boot loader features
3.3.1 Typical boot loader functions
The boot loader typically resides in non-volatile memory on a target device and executes when the system powers up or resets. For future boot loader updates, usually the boot loader itself downloads and saves new run-time images.
These are the main features to ensure:
● The boot loader should reside in a non-volatile storage area, such as flash memory or flash memory cards, which can be optionally updated while in the system. In addition, locking the flash memory blocks containing the boot loader is a good way to help protect the boot loader from corruption.
● The boot loader should provide the ability to load both run-time images and boot loader images, not only to RAM but also to non-volatile storage, such as flash memory, to support testing in a simulated final product.
Boot loaders AN2539
10/25
● The boot loader should perform checksum checking on the downloaded data and should avoid changing the flash memory contents until the checksum is confirmed to be correct.
3.3.2 Hardware considerations
The hardware design of a target device influences how it is used and how effective it is as a development and test tool. The following list shows hardware considerations when you are developing a target device for development or testing:
● Allow ROM or flash memory containing the boot loader to be replaceable or support a JTAG interface.
● Provide a hardware switch to allow booting directly to a run-time image in flash memory or to allow booting the boot loader directly. Alternatively, use a software switch setting.
● Provide ample RAM and flash memory to support debugging. Run-time images that support the kernel debugger can be much larger than run-time images that support products for release to customers.
3.3.3 Boot sequence on standard PC (IBM-PC compatible)
If there is no active partition or the active partition's boot sector is invalid, the MBR may load and pass control to a secondary boot loader that will select a partition (often via user input) and load its boot sector, which usually loads the corresponding operating system kernel. Newer BIOSes can use an EFI boot manager instead of a standard MBR boot loader.
3.3.4 MS-DOS boot loader boot process
The boot loader loads a .bin image from any device the BIOS views as a storage device. This includes floppy, Compact Flash (CF), Disk-On-Chip, etc., and so eMMC too.
The following steps describe the boot loader boot process:
1. At power-on or reset, the CPU jumps to the BIOS code and starts to execute it.
2. The BIOS runs a power-on self test (POST) to check that devices the computer will rely on are functioning; it also initializes these devices. Then, it goes through a preconfigured list of devices until it finds one that is bootable.
3. If the bootable drive is a fixed disk, the BIOS loads and executes its boot sector. In the case of a hard drive, this is referred to as the master boot record (MBR) and is often not operating system specific.
4. Usually, the MBR code checks the partition table for an active partition. If one is found, the MBR code loads that partition's boot sector and executes it. The boot sector is often operating system specific.
5. The boot sector code (boot loader) in most operating systems loads and executes a kernel, which continues startup.
6. If there is no active partition or the active partition's boot sector is invalid, the MBR may load a secondary boot loader and pass control to it and this secondary boot loader will select a partition (often via user input) and load its boot sector, which usually loads the corresponding operating system kernel.
This method of booting from a generic storage device is very flexible and enables the designer to share different operating systems on the same device, by configuring different partitions and different boot loaders.
AN2539 Where to store the eMMC boot code?
11/25
4 Where to store the eMMC boot code?
With eMMC boot code is meant all the code needed to complete the boot phase that is stored on the eMMC card.
In particular, Figure 5 shows how it is divided into several addressable spaces in a Microsoft FAT32 file system.
Figure 5. Microsoft FAT32 file system
There are three possible solutions of where to store the eMMC boot code:
1. The first solution consists of storing the boot code in the hidden sectors of the master boot record (MBR) area (recommended solution).
2. Alternatively, the boot code could be stored in the reserved sectors of the BIOS parameter block (BPB).
3. Finally, the code could be stored in the user area, declaring a card size lower that the effective one. This way, the file system cannot access the last locations, thus leaving the boot code accessible only by low level software.
4.1 Storing the boot code in the hidden sectors area The MBR sector contains the partition table (for more information, refer to Section B.3 on page 19). Each entry in the partition table describes a particular partition. The initial CHS coordinates (position of the boot sector of the first partition) of the first partition implicitly define the number of hidden sectors in the MBR area. We can choose this parameter in order to define the size of the area we want to use to store the boot code. By “boot code”, we mean the code we have to store in the eMMC non-volatile storage device.
Our solution consists of placing the boot code (with the relative boot loader) into the MBR hidden area, thus speeding up the entire boot process. This can be done because the embedded system we work on is dedicated. There is no way to use the card in another system, because it is a non-removable device, so we will try to simplify the boot process by directly loading the boot loader in RAM and starting its execution.
Figure 6. Hidden sectors area
MBRHidden
BPBBPB
FS infoFree
FAT1 FAT2Root User
Reserved area
areadirectoryreserved
backupsectors sectors
MBRHidden
BPBBPB
FS infoFree
FAT1 FAT2Root User
Reserved area
areadirectoryreservedbackupsectorssectors
Where to store the eMMC boot code? AN2539
12/25
The following steps describe how the proposed solution works:
1. At power-on or reset, the CPU jumps to the ROM pre-boot code located at address 0x00000000 and starts to execute it.
2. This code configures the hardware and then loads the eMMC pre-boot (containing the card access drivers) to the RAM and starts to execute it.
3. The eMMC pre-boot recognizes the hardware platform and finds the boot loader and shadows it to the RAM.
4. The boot loader loads the OS kernel and jumps to the OS boot code executing it.
Figure 7. Placing the boot code in the hidden sectors area
4.2 Placing the boot code in the FAT reserved sectors areaAnother possible solution consists of placing the boot code into the partition reserved sectors area. This solution is used by Microsoft. This area is located just before the FAT (file allocation table) area. We can choose the size of this area by setting the RsvdSecCnt parameter in the BPB (BIOS parameter block).
Figure 8. FAT reserved sectors area
The steps needed to boot up the system from the eMMC are the same described in Section 4.1.
The drawback of this solution depends on the position of the boot code. Each time we want to format a card or volume, we have to rewrite the volume structures, including the reserved sectors themselves.
This will erase the boot code, producing an un-bootable card, and an un-bootable system.
To prevent this from occurring, the designer should disable the Format command for the user. Unfortunately, this command is often useful and appreciated by the users.
MCU
eMMC
ROM NAND
eMMC pre-boot
eMMC low level drivers
Boot loader
OS kernel
RAM
0
1
2
3
4
MBRHidden
BPBBPB
FS infoFree
FAT1 FAT2Root User
Reserved area
areadirectoryreserved
backupsectorssectors
AN2539 Where to store the eMMC boot code?
13/25
4.3 Auto-boot solutionThe eMMC standardization process is now in progress, so there are companies that are trying to contribute to the definition of the various aspects of the eMMC use.
One of these aspects is the boot process.
Some card manufacturers are thinking about an auto-boot solution in which the card itself provides the boot code to load in RAM when it receives a specific stimulus from the host.
In particular, the card could read out the boot code when a Boot Acknowledge signal sequence is raised by the host.
Figure 9 shows a timing diagram illustrating an auto-boot example.
In this solution, the host acknowledges the boot sequence to the card by setting the CMD line low and holding it for a specific time period, during which the card reads out the boot code as if the host raised a protocol read command.
Figure 9. Auto-boot example
CLK
CMD
DAT S 010 E S 512 bytes + CRC E
Where to store the eMMC boot code? AN2539
14/25
4.4 Conclusions (advantages and disadvantages)In all three solutions there are no limitations in regards to boot code size; the only limit is the size of the card.
As shown in Table 1, we can see that second solution (boot code in reserved sector) is the more restrictive because users do not have the possibility of formatting the card.
The third solution (auto-boot) ensures the maximum protection against formatting because boot code is hidden to any high-level application, but requires modifying (hardware and software) the MMC interface controller.
First solution does not require any hardware or software modifications. Common format processes do not erase hidden sectors (boot code), but processes that create, delete or redefine the size of the partitions may rewrite hidden sectors and boot code can be corrupted.
No solution is better than another; each solution has its own advantages and disadvantages. The choice of a solution depends of the requirements of the developer/user.
Table 1 provides an overview on advantages and disadvantages about the three solutions proposed in previous paragraph.
Table 1. Advantages and disadvantages of each solution
Solution Advantages Disadvantages
Boot code in hidden sector
We don’t need SW/HW modification of MMC interface controller
Format operation doesn’t erase boot code, but any operations that resize the partitions (fdisk/MBR) can erase the hidden sectors.
Boot code in reserved sectors
We don’t need SW/HW modification of the MMC interface controller
Format operation erases reserved sectors. In this way we lost boot code.
Auto-boot solution
Format operation doesn’t erase boot code
We need HW/SW modification of the MMC interface controller
AN2539 eMMC overview
15/25
Appendix A eMMC overview
The Multimedia Card Association (MMCA) and the JEDEC Solid State Technology Association (JEDEC) are jointly adopting eMMC as the trademark and product category of a class of embedded memory module products built on the joint MMCA/JEDEC multimedia card (MMC) standard specification. The MMCA and JEDEC entered into a joint standard-setting agreement in December 19, 2006. eMMC is the first product standard from the partnership.
eMMC describes an architecture comprised of an embedded storage solution with MMC interface, flash memory and controller, all in a small ball grid array (BGA) package.
It is based upon the industry-standard MMC system specification version 4.1/4.2 and JEDEC BGA packaging standards. With interface speeds of up to 52 Mbytes per second, eMMC provides fast scalable performance. It also allows for an interface voltage of either 1.8 volts or 3.3 volts. Accordingly, eMMC supports a wide range of applications in consumer electronics, wireless, navigation, industrial uses and other areas.
This system architecture is far more flexible than that based upon other memory card-only standards.
eMMC makes it easy to embed mass-storage flash memory on host systems. The standardized eMMC protocol interface offers designers high performance and keeps technology complexity, such as “not and” (NAND) flash functional differences among suppliers, invisible to the host. This differs from the conventional architecture, where a host system must support NAND products from multiple companies in a generic manner by necessity.
The conventional approach also increases design complexity to support company-specific functions for better performance.
The design complexity is magnified by generational process geometry shrinks and multilevel cell (MLC) technology. The benefit of eMMC to the host manufacturers is a simpler product design and qualification process and an overall shorter time to market.
Because eMMC is an industry standard, multiple sources of components will be available.
About MMCA
The MultiMediaCard Association (MMCA) is the open standard memory card organization, promoting worldwide adoption of storage media and peripheral I/O devices designed especially for mobile phones and digital imaging devices. It enables a myriad of applications to come together and share digital media contents.
Founded in 1998, the MMCA provides a global forum for memory card and semiconductor component suppliers, software vendors and manufacturers of mobile electronic devices. They jointly endorse and promote the worldwide adoption of MultiMediaCards and the MMC standards.
About JEDEC
JEDEC is the leading developer of standards for the solid-state industry. Almost 2900 participants, appointed by some 280 companies, work together in 50 JEDEC committees to meet the needs of every segment of the industry, manufacturers and consumers alike. The publications and standards that they generate are accepted throughout the world. All JEDEC standards are available online, at no charge.
eMMC overview AN2539
16/25
General description
JEDEC eMMC is a mass data storage device that utilizes a MultiMediaCard (MMC) interface, as shown in Figure 10. It features low cost, small size, flash-technology independence, and high data throughput. These features make JEDEC eMMC ideal for smart phones, digital cameras, PDAs, MP3 players, and countless other portable applications.
The non-volatile JEDEC eMMC draws no power to maintain stored data, delivers high performance across a wide range of operating temperatures, and resists shock and vibration disruption.
A JEDEC eMMC device includes a NAND flash component and a controller on an advanced 10-signal bus.
Flash-technology independence is supported by compliance with this specification. The specification defines the communication protocol for MMC mode. This ensures ongoing compatibility between evolving NAND flash components and existing microcontrollers.
Figure 10. eMMC functional block diagram
A.1 Operation modesJEDEC eMMC supports MultiMediaCard (MMC) mode as well as serial peripheral interface (SPI) mode.
A.2 Physical descriptionJEDEC eMMC has 10 signals. The host is connected to the device using a dedicated 10-ball connector.
DAT[7:0]
CMD
CLK
Vss
VssQ
VccQ
Vcc
eMMC
Controller
NAND flash
AN2539 eMMC overview
17/25
A.3 Device signalsJEDEC eMMC devices transfer data via a configurable number of data-bus signals. Table 2 lists these communication signals.
Device initialization uses only the CMD channel and is, therefore, compatible with all devices.
A.4 Numonyx eMMC-like productsNumonyx NAND08GAH0B (1-Gbyte, MLC based) and NANDxxxAH0x (256-Mbyte, 512-Mbyte and 1-Gbyte SLC based) are NAND flash memories with a MultiMediaCard interface, developed for universal low cost data storage and communication media. They can be considered as high speed MultiMediaCards embedded in LFBGA169 12 x 16 x 1.4 mm 0.5 mm pitch or LFBGA153 11.5 x 13 x 1.3 mm packages instead of an MMC. The devices are fully compatible with MMC bus and hosts.
Numonyx NAND08GAH0B and NANDxxxAH0x devices communicate via an advanced 13-pin bus. The bus can be either 1-bit, 4-bit, or 8-bit bus width. The devices operate in high-speed mode (HS-MMC) at clock frequencies equal or higher than 20 MHz. The communication protocol is defined as a part of this MMC standard and referred to as MultiMediaCard mode. For compatibility with existing controllers the devices may offer, in addition to the MultiMediaCard mode, an alternate communication protocol which is based on the SPI standard.
The devices are designed to cover a wide area of applications such as smart phones, cameras, organizers, PDA, digital recorders, MP3 players, pagers, electronic toys, etc. They feature high performance, low power consumption, low cost and high density.
To meet the requirements of embedded high density storage media and mobile applications, Numonyx NAND08GAH0B and NANDxxxAH0x support both 3 V supply voltage (VCC), and 1.8 V/3 V input/output voltage (VCCQ).
The devices have a built-in intelligent controller which manages interface protocols, data storage and retrieval, wear leveling, bad block management, garbage collection, internal error-correcting code (ECC).
Table 2. Communication signals
Signal Symbol Description
Clock CLKEach cycle of the clock directs a transfer on the command line and on the data line(s). The frequency can vary between the minimum and the maximum clock frequency.
Command CMD
This signal is a bidirectional command channel used for device initialization and command transfers. The CMD signal has two operating modes: open-drain for initialization, and push-pull for command transfer. Commands are sent from the MultiMediaCard bus master to the device, and responses are sent from the device to the host.
Data DAT[7:0]
These are bidirectional data signals. The DAT signals operate in push-pull mode. By default, after power-up or RESET, only DAT0 is used for data transfer. The memory controller can configure a wider data bus for data transfer using either DAT[3:0] (4-bit mode) or DAT[7:0] (8-bit mode). JEDEC eMMC includes internal pull-up resistors for data lines DAT[7:1]. Immediately after entering the 4-bit mode, the device disconnects the internal pull-up resistors on the DAT1 and DAT2 lines. (The DAT3 line internal pull-up is left connected.) Upon entering the 8-bit mode, the device disconnects the internal pull-ups on the DAT1, DAT2, and DAT[7:4] lines.
FAT overview AN2539
18/25
Appendix B FAT overview
This section provides an introduction to file systems, and in particular focuses on the issues of the FAT (file allocation table) file system. This is only an overview to file systems; for a complete description of file systems please refer to the specific documentation.
B.1 IntroductionBefore talking about FAT, we should understand the term “file system”. A file system is a way of storing data on a media, the way it is organized and managed. There are a lot of them, some much more used than the others: new technology file system (NTFS), high performance file system (HPFS), DOS, FAT 12/16/32, VFAT, Macintosh hierarchical file system (HFS), ISO 9660 (for CD-ROM), extended file systems (Ext, Ext2, Ext3), and many others.
All file systems include a few basic types of data structures:
● Bootstrap: code to be loaded into memory and executed when the computer is powered on.
● Volume descriptors: information describing the size, type, and layout of the file system.
● File descriptors: information that describes a file (ownership, protection, time of last update, etc.) and points where the actual data is stored on the disk.
● Free space descriptors: lists of blocks of (currently) unused space that can be allocated to files.
● File name descriptors: data structures that user-chosen names with each file.
B.2 FAT (file allocation table) file system
History
1977: The FAT file system was created by Bill Gates and Marc McDonald for managing disks in Microsoft Disk Basic. This initial version of FAT is now referred to as FAT12. Cluster addresses are 12 bits long.
1981: FAT16 debuts with MS-DOS. Cluster addresses are 16 bits long.
1996: FAT32 debuts in Windows 95 OEM Service Release 2. Cluster addresses are 28 bits long (4 bits are reserved).
Note that today, FAT12 is considered obsolete.
Figure 11 shows a typical layout of a FAT structure:
AN2539 FAT overview
19/25
Figure 11. Typical FAT structure layout
B.3 What is the master boot record (MBR)?At the end of the ROM BIOS bootstrap routine, the BIOS reads and executes the first physical sector of the first hard disk on the system. This first sector of the hard disk is called the master boot record (or sometimes the partition table or master boot block). There is a small program at the beginning of this sector of the hard disk. The partition information, or partition table, is stored at the end of this sector. This program uses the partition information to determine which partition is bootable (usually the first primary DOS partition) and attempts to boot from it. We can have only four primary partitions. The sector between MBR sector and boot sector of the first volume are called hidden sectors. A field in partition table entry indicates how large this area is. Figure 12 shows a structural diagram of MBR.
0
MBR
Hidden sectors
Boot sector
Reserved sectors
FAT1
FAT2
Root directory
User area
Boot sector
Reserved sectors
FAT1
FAT2
Root directory
User area
Single FAT volume1st partition
Single FAT volume2nd partition
FAT overview AN2539
20/25
Figure 12. Structural diagram of MBR
B.4 FAT volume structureDOS FAT file systems divide the volume into fixed-sized (physical) blocks, which are grouped into larger fixed-sized (logical) block clusters.
The first block of DOS FAT volume (boot sector) contains the bootstrap, along with certain volume description information. The file allocation table is used, both as a free list and to keep track of which blocks have been allocated to which files.
The remainder of the volume is data clusters, which can be allocated to files and directories. The first file on the volume is the root directory, the top of the tree from which all other files and directories on the volume can be reached.
Boot sector
The boot record is located at the beginning of a FAT volume. The first sector of the volume or the first few sectors are also known as the “reserved” sectors or the reserved area. The Reserved_Sectors field in the boot record tells us how large this area is. Note that the first FAT follows directly after the reserved area.
The DOS format program reserves 1 sector for FAT12 and FAT16 and usually 32 sectors for FAT32. The reserved area for FAT32 contains not only the boot record but also a backup copy of the boot record.
MBR code
Partition table entry 0
Partition table entry 1
Partition table entry 2
Partition table entry 3
Volume 1
Volume 2
AN2539 FAT overview
21/25
The boot record includes a field describing the sector size for the media and it is possible to have a boot record size different than the 512-byte commonly seen on hard disks and diskettes (usually seen on RAM-disks).
Inside the boot record there is a structure called the BPB or BIOS parameter block. To further complicate things, there are different versions of the boot record as well. Basically, as storage technology developed and disks become bigger, new fields are added to the boot record to support larger disk sizes.
Table 3. Common structure of the first 36 bytes used by all FAT versions
Byte offset
Length (bytes)
Description
0x00 3Jump instruction. This instruction will be executed and will skip past the rest of the (non-executable) header if the partition is booted from.
0x03 8OEM Name (padded with spaces). MS-DOS checks this field to determine which other parts of the boot record can be relied on Common values are IBM 3.3 (with two spaces between the “IBM” and the “3.3”) and MSDOS5.0.
0x0b 2Bytes per sector. A common value is 512, especially for file systems on IDE (or compatible) disks. The BIOS Parameter Block starts here.
0x0d 1Sectors per cluster. Allowed values are powers of two from 1 to 128. However, the value must not be such that the number of bytes per cluster becomes greater than 32 KB
0x0e 2Reserved sector count. The number of sectors before the first FAT in the file system image. Should be 1 for FAT12/FAT16. Usually 32 for FAT32.
0x10 1 Number of file allocation tables. Almost always 2.
0x11 2
Maximum number of root directory entries. Only used on FAT12 and FAT16, where the root directory is handled specially. Should be 0 for FAT32. This value should always be such that the root directory ends on a sector boundary (i.e. such that its size becomes a multiple of the sector size).
0x13 2 Total sectors (if zero, use 4 byte value at offset 0x20)
0x15 1
Media descriptor
0xF8: Single sided, 80 tracks per side, 9 sectors per track0xF9: Double sided, 80 tracks per side, 9 sectors per track0xFA: Single sided, 80 tracks per side, 8 sectors per track0xFB: Double sided, 80 tracks per side, 8 sectors per track0xFC: Single sided, 40 tracks per side, 9 sectors per track0xFD: Double sided, 40 tracks per side, 9 sectors per track0xFE: Single sided, 40 tracks per side, 8 sectors per track0xFF: Double sided, 40 tracks per side, 8 sectors per track
Same value of media descriptor should be repeated as first byte of each copy of FAT. Certain operating system (MSX-DOS version 1.0) ignore boot sector parameters altogether and use media descriptor value from the first byte of FAT to determine file system parameters.
0x16 2 Sectors per File Allocation Table
0x18 2 Sectors per track
0x1a 2 Number of heads
0x1c 4 Hidden sectors
0x20 4 Total sectors (if greater than 65535; see offset 0x13)
FAT overview AN2539
22/25
Further structure used by FAT12 and FAT16, also known as Extended BIOS Parameter Block:
Further structure used by FAT32:
Table 4. FAT12 and FAT16 structure
Byte Offset
Length (bytes)
Description
0x24 1 Physical drive number
0x25 1 Reserved (“current head”)
0x26 1 Signature
0x27 4 ID (serial number)
0x2b 11 Volume Label
0x36 8 FAT file system type, padded with blanks (0x20), e.g.: “FAT12 “, “FAT16 “
0x3e 448 Operating system boot code
0x1FE 2 End of sector marker (0x55 0xAA)
Table 5. FAT 32 structure
Byte Offset
Length (bytes)
Description
0x24 4 Sectors per file allocation table
0x28 2 FAT Flags
0x2a 2 Version
0x2c 4 Cluster number of root directory start
0x30 2 Sector number of FS Information Sector
0x32 2 Sector number of a copy of this boot sector
0x34 12 Reserved
0x40 1 Physical Drive Number
0x41 1 Reserved
0x42 1 Signature
0x43 4 ID (serial number)
0x47 11 Volume Label
0x52 8 FAT file system type: “FAT32 “
0x5a 420 Operating system boot code
0x1FE 2 End of sector marker (0x55 0xAA)
AN2539 FAT overview
23/25
FAT table
The available space on hard drives is divided into clusters. A single file on the hard drive may store its data in one or more of these clusters, as many as are required by its size. Each cluster on the hard drive is represented by an entry in the FAT table. An entry within the FAT table basically indicates one of three things. For a FAT12 the entry of FAT table is 12 bits long, for a FAT16 is 16 bits long and for FAT32 is 32 bits long. Each entry contains a value that indicates the location of the next data cluster of the file or a special End Of File (EOF) character that indicates the represented cluster is the last data cluster of the file or a zero value to indicate that the represented cluster is empty.
Root directory
The root directory is formatted just like any other directory. FAT12 and FAT16 volumes have the root directory located immediately following the file allocation table(s). For FAT32 a field in the boot record will tell you the initial cluster number of root directory.
Data area
The data area fills the rest of the volume, and is divided into clusters; it is here that the file data is stored. Subdirectories are files with a particular structure that is understood by the file system, and are marked as being directories rather than files by setting the “directory” attribute bit in the directory entry that points to it.
Revision history AN2539
24/25
5 Revision history
Table 6. Document revision history
Date Revision Changes
16-Aug-2007 1 Initial release.
18-Nov-2008 2Applied Numonyx branding. Modified Section A.4: Numonyx eMMC-like products.
AN2539
25/25
Please Read Carefully:
INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH NUMONYX™ PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN NUMONYX'S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, NUMONYX ASSUMES NO LIABILITY
WHATSOEVER, AND NUMONYX DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF NUMONYX PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT.
Numonyx products are not intended for use in medical, life saving, life sustaining, critical control or safety systems, or in nuclear facility applications.
Numonyx may make changes to specifications and product descriptions at any time, without notice.
Numonyx, B.V. may have patents or pending patent applications, trademarks, copyrights, or other intellectual property rights that relate to the presented subject matter. The furnishing of documents and other materials and information does not provide any license, express or implied,
by estoppel or otherwise, to any such patents, trademarks, copyrights, or other intellectual property rights.
Designers must not rely on the absence or characteristics of any features or instructions marked “reserved” or “undefined.” Numonyx reserves these for future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to them.
Contact your local Numonyx sales office or your distributor to obtain the latest specifications and before placing your product order.
Copies of documents which have an order number and are referenced in this document, or other Numonyx literature may be obtained by visiting Numonyx's website at http://www.numonyx.com.
Numonyx StrataFlash is a trademark or registered trademark of Numonyx or its subsidiaries in the United States and other countries.
*Other names and brands may be claimed as the property of others.
Copyright © 11/5/7, Numonyx, B.V., All Rights Reserved.