This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM3517, Boot from eMMC device.

Other Parts Discussed in Thread: CSD

Hello all

I have some problems booting from a eMMC device. I have succesfully booted from a standard MMC device using a x-loader and u-boot in offset 128kb using the RAW boot method explained in SPRUGR0C section 24.4.7 Memory booting. This is my setup:

Image: Contains A simple TOC-header containing CHSETTINGS entry and (size, load address)+x-loader at offset 512 bytes in image, see section 24.4.8 in SPRUGR0C. The x-loader has been altered to load a  uboot image from offset sector 256+512=768. The u-boot then loads my kernel and OS.

This method works perfect when using a standard MMC.

In our product a eMMC device is used (N2M400FDB311A3CF). It contains, Boot area partitions 1,2 and a user area. I found a Technical note on the internet, TN-52-06: Booting from embedded MMC - JEDEC 4.41 introduction. My eMMC device is very similar to the standard.

First I thought that the case was simple, so I just made the same setup in the user area, used in my MMC boot setup. It did not work. Then I tried to copy (using dd) the images to boot area partitions 1, then 2 but with the same result.

By reading the "TN-52-06: Booting from embedded MMC - JEDEC 4.41 introduction" I figured out that some of the EXT_CSD registers needed to be altered, especially register 179.

Using a short search i found a project called mmc-utils, which was able to alter the EXT_CSD registers. I tried using the command "mmc bootpart enable", with different variations but still no success.
I have considered some of the other commands but most of the is one-time programmable (Very interesting  mmc enh_area set). Before I know what I am doing, I will not set these OTP bits.

I have attached the dump form the command "mmc extcsd read /dev/mmcblk0" in the bottom of this message.

I fear that the non standard detect method used in the OMAP boot room (section 24.7.6.1) violates the method defined in the JEDEC standard. The standard defines that the mmc CMD0 must be sent, but OMAP boot rom sends a CMD1 to support both SD/MMC. So does a successful boot depends on a "nice" respond from eMMC?? or can the EXT_CSD bit be forced to allow boot/respons to CMD1?

Any help/hints is most welcome. I must admit that I have faced a wall.

=============================================
  Extended CSD rev 1.5 (MMC 4.41)
=============================================

Card Supported Command sets [S_CMD_SET: 0x01]
HPI Features [HPI_FEATURE: 0x03]: implementation based on CMD12
Background operations support [BKOPS_SUPPORT: 0x01]
Background operations status [BKOPS_STATUS: 0x02]
1st Initialisation Time after programmed sector [INI_TIMEOUT_AP: 0xf2]
Power class for 52MHz, DDR at 3.6V [PWR_CL_DDR_52_360: 0x00]
Power class for 52MHz, DDR at 1.95V [PWR_CL_DDR_52_195: 0x00]
Minimum Performance for 8bit at 52MHz in DDR mode:
 [MIN_PERF_DDR_W_8_52: 0x00]
 [MIN_PERF_DDR_R_8_52: 0x00]
TRIM Multiplier [TRIM_MULT: 0x06]
Secure Feature support [SEC_FEATURE_SUPPORT: 0x15]
Secure Erase Multiplier [SEC_ERASE_MULT: 0x02]
Secure TRIM Multiplier [SEC_TRIM_MULT: 0x03]
Boot Information [BOOT_INFO: 0x07]
 Device supports alternative boot method
 Device supports dual data rate during boot
 Device supports high speed timing during boot
Boot partition size [BOOT_SIZE_MULTI: 0x80]
Access size [ACC_SIZE: 0x05]
High-capacity erase unit size [HC_ERASE_GRP_SIZE: 0x04]
 i.e. 2048 KiB
High-capacity erase timeout [ERASE_TIMEOUT_MULT: 0x01]
Reliable write sector count [REL_WR_SEC_C: 0x01]
High-capacity W protect group size [HC_WP_GRP_SIZE: 0x02]
 i.e. 4096 KiB
Sleep current (VCC) [S_C_VCC: 0x08]
Sleep current (VCCQ) [S_C_VCCQ: 0x08]
Sleep/awake timeout [S_A_TIMEOUT: 0x10]
Sector Count [SEC_COUNT: 0x00734000]
 Device is block-addressed
Minimum Write Performance for 8bit:
 [MIN_PERF_W_8_52: 0x08]
 [MIN_PERF_R_8_52: 0x08]
 [MIN_PERF_W_8_26_4_52: 0x08]
 [MIN_PERF_R_8_26_4_52: 0x08]
Minimum Write Performance for 4bit:
 [MIN_PERF_W_4_26: 0x08]
 [MIN_PERF_R_4_26: 0x08]
Power classes registers:
 [PWR_CL_26_360: 0x00]
 [PWR_CL_52_360: 0x00]
 [PWR_CL_26_195: 0x00]
 [PWR_CL_52_195: 0x00]
Partition switching timing [PARTITION_SWITCH_TIME: 0x01]
Out-of-interrupt busy timing [OUT_OF_INTERRUPT_TIME: 0x02]
Card Type [CARD_TYPE: 0x07]
 HS Dual Data Rate eMMC @52MHz 1.8V or 3VI/O
 HS eMMC @52MHz - at rated device voltage(s)
 HS eMMC @26MHz - at rated device voltage(s)
CSD structure version [CSD_STRUCTURE: 0x02]
Command set [CMD_SET: 0x00]
Command set revision [CMD_SET_REV: 0x00]
Power class [POWER_CLASS: 0x00]
High-speed interface timing [HS_TIMING: 0x01]
Erased memory content [ERASED_MEM_CONT: 0x00]
Boot configuration bytes [PARTITION_CONFIG: 0x00]
 Not boot enable
 No access to boot partition
Boot config protection [BOOT_CONFIG_PROT: 0x00]
Boot bus Conditions [BOOT_BUS_CONDITIONS: 0x00]
High-density erase group definition [ERASE_GROUP_DEF: 0x01]
Boot write protection status registers [BOOT_WP_STATUS]: 0x00
Boot Area Write protection [BOOT_WP]: 0x00
 Power ro locking: possible
 Permanent ro locking: possible
 ro lock status: not locked
User area write protection register [USER_WP]: 0x00
FW configuration [FW_CONFIG]: 0x00
RPMB Size [RPMB_SIZE_MULT]: 0x01
Write reliability setting register [WR_REL_SET]: 0x00
 user area: existing data is at risk if a power failure occurs during a write operation
 partition 1: existing data is at risk if a power failure occurs during a write operation
 partition 2: existing data is at risk if a power failure occurs during a write operation
 partition 3: existing data is at risk if a power failure occurs during a write operation
 partition 4: existing data is at risk if a power failure occurs during a write operation
Write reliability parameter register [WR_REL_PARAM]: 0x05
 Device supports writing EXT_CSD_WR_REL_SET
 Device supports the enhanced def. of reliable write
Enable background operations handshake [BKOPS_EN]: 0x00
H/W reset function [RST_N_FUNCTION]: 0x00
HPI management [HPI_MGMT]: 0x01
Partitioning Support [PARTITIONING_SUPPORT]: 0x03
 Device support partitioning feature
 Device can have enhanced tech.
Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x0001cd
 i.e. 1888256 KiB
Partitions attribute [PARTITIONS_ATTRIBUTE]: 0x00
Partitioning Setting [PARTITION_SETTING_COMPLETED]: 0x00
 Device partition setting NOT complete
General Purpose Partition Size
 [GP_SIZE_MULT_4]: 0x000000
 [GP_SIZE_MULT_3]: 0x000000
 [GP_SIZE_MULT_2]: 0x000000
 [GP_SIZE_MULT_1]: 0x000000
Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000
 i.e. 0 KiB
Enhanced User Data Start Address [ENH_START_ADDR]: 0x000000
 i.e. 0 bytes offset
Bad Block Management mode [SEC_BAD_BLK_MGMNT]: 0x00

  • some update.

    I found this post

    http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/t/30151.aspx

    and a very interesting reply in this post

    --- snip --:<----

    Yes you can use a eMMC device with the OMAP, but you can not boot from a eMMC, because booting from EMMC was introduced in v4.3 of the JEDEC standard and the Boorstrap of TI supports only v4.2. This means, you can boot from SD or MMC but not from eMMC.

    The Host (Omap) uses only the v4.2 features of the eMMC. This means booting is not possible.

    Put the first level bootloader somewhere else (a small SPI-EEPROM with 64k). Your own 1st level bootloader can read the rest from eMMC.

    --- snip --:<----

    Not good. So it seems that the only option is to find a method how to disable the boot partitions and make the eMMC act as a JEDEC 4.2 compatible card.

    Any hints on that issue?

  • I did not see any final conclusion to above reply regarding eMMC but I am also interested in using eMMC NAND Flash with AM335x.  Based on last comments do you see any problems with using 176k of AM335x Boot ROM for first level bootloader and then have linux file system,etc. reside on eMMC?