DM8148 RBL ROM Boot Loader doesn't boot from 8GB eMMC

Erwin,

DM8148 will not support eMMC greater than 2GB, if the eMMC does not adhere to section 7.4.2 of the MMCA v4.41 spec. I suspect that the card you have only adheres to section 7.4.3 of the spec and does NOT adhere to section 7.4.2 of the spec. Please confirm from Micron that this is indeed the case.

There are four ways to fix this issue

a) Use a eMMC that specifically adheres to section 7.4.2 of the eMMC spec.

b) Use a esD card instead

c) Use a eMMC that is less than or equal to 2GB

d) Use a small SPI flash as the primary boot device and use the eMMC as a secondary boot device.

Regards,

Madan

Assuming we get an eMMC which is compliant with section 7.4.2, does the DM8148 require the use of eMMC boot partitions?  It looks to me that support for boot partitions is only available as patch that would have to be added into the linux kernel.

Erwin,

You are right - the DM8148 boot flow does not make use of eMMC boot partitions.

Reagrds,

Madan

Thank  you for both answers!  Of course,  I have one more question.

When the DM8148 boots in raw mode, does it use the same format file?  In other words, can I copy the MLO file to the

raw mode address and expect it to boot?

Erwin,

The MLO file cannot be used. You need to add a TOC header to the MLO file - there is a specific 512 byte header that would need to be put firsst for the ROM to identify the image and switch to RAW mode.

Regards,

Madan

I have figured out that the raw mode MLO file must have an 8-byte header containing the image size and load address.

I copied the format from a NAND-targetted MLO file, adjusting the size bytes to match the rest of my MLO image.

And it still doesn't work.  So I am trying to obtain a 512MB, 1GB or 2GB eMMC to avoid the >2GB  issue.

Erwin,

The MLO file is the boot binary + 8 bytes header, the RAW image is MLO + 512 byte TOC header. RAW mode will not work without the TOC header. 

Regards,

Madan

I wrote a 512-byte TOC header which contained the following values.  While I show them in decimal or binary

they are written to the 512-byte TOC.bin file in little endian order in binary:

  Value      Size          What

   512       4 bytes   offset from start of TOC to start of 8-byte GP header (=size of TOC header)

  74984   4 bytes   size of u-boot.min plus 8 byte GP header

        0       4 bytes   flags (reserved)

        0       4 bytes   Align (reserved)

0x4030000 4 bytes  Write Load address (should this be 402FFFF8 to allow for GP header??)

"MLO"     12 bytes  Filename, followed by 8 NUL bytes

0xFF        480 bytes  Rest of TOC header all 0xFFFFFFFF (ones)

The next part is the GP header, two 4-byte fields, little endian:

  Value       Size              What

  74976    4 bytes           size of u-boot.min image which follows

  0x40300000  4 bytes  load address of u-boot.min image in SRAM

The next part is the u-boot.min file itself, which had worked just fine when named "MLO" and stored on

a FAT partition of an SD card.

I write the above 3 parts to the eMMC, into contguous bytes starting at block 0.  It does not work on my 8GB eMMC. 

Tomorrow I expect to receive a 2GB eMMC to try it on.

Does this look correct?  And Is there a utility to generate TOC headers?   Creating it was not hard,

merely tedious, but I could think of things I'd rather do!   Thanks again for your help!

The problem just changes...

The 2GB Toshiba eMMC device boots up under RBL just like an SD media, using the MLO file in the vfat partition.

A pleasant surprise, since I no longer have to figure out exactly what goes in the TOC header.

But u-boot won't do the fatload command, complaining "mmc_read_data: timedout waiting for status!".

It is worthwhile to note that if I boot from the network, linux is able to access the Toshiba eMMC just fine,

and reads it at ~16MB/sec, and writes it at ~ 2MB/sec.

Is there a fix for MMC timeouts in the works for DM8148 u-boot driver?  Any ideas?

Hi,

If you can send me an example of a known-good u-boot image preceeded by a TOC header and GP Header,

I can figure out the rest of it and not post another question about this.   Binary or a hex dump of the first K Byte

or so would be fine.  Thank you!

Hi,

Did you make any progress with this issue ?

Reason I ask: I have the same problem, EVM8148 does not boot from 4GB Samsung eMMC.

eMMC is on a adapter card BGA -> MMC Card connector. eMMC goes into inactive state when accessed by ROM boot code .

Regards,

Tjeerd

Tjeerd,

Please go though the chain - the root cause of the issue you are facing has been explained and workarounds have been proposed. Copy pasting below for your convinience.

DM8148 will not support eMMC greater than 2GB, if the eMMC does not adhere to section 7.4.2 of the MMCA v4.41 spec. I suspect that the card you have only adheres to section 7.4.3 of the spec and does NOT adhere to section 7.4.2 of the spec. Please confirm from Micron that this is indeed the case.

There are four ways to fix this issue

a) Use a eMMC that specifically adheres to section 7.4.2 of the eMMC spec.

b) Use a esD card instead

c) Use a eMMC that is less than or equal to 2GB

d) Use a small SPI flash as the primary boot device and use the eMMC as a secondary boot device.

Regards,

Madan

Madans,

I wonder why we don't have this limitation on OMAP3 based devices but does on DM8148.

Is it because the ROM code has different scheme on booting?

Best Regard,
Rich

Rish,

The ORM has indeed changed. It has been modified to support backward comaptibility with older MMC devices. This would not have normally been a problem for 8GB devices, however currently available v4.41 8GB devices do not strictly adhere to the spec.

Reagrds,

Madan

Dear Madan,

Does the dm8168 have the same problem like dm8148 that will not support eMMC greater than 2GB? Will all the reasons be same as dm8148? Please help me to confirm that. Thanks in advance.

B.R.

OC

OC,

Kingston has an eMMC part that will work with all the DM devices. I recommend you try that part.

Regards,

Madan

Dear Madan,

Can you provide the eMMC part of Kingston for me directly? May I ask that part will match the below two conditions? Or I can follow below conditions to search the eMMC part of Kingston. Thanks for your kindly recommendation.

a) That specifically adheres to section 7.4.2 of the eMMC spec.

b) That is less than or equal to 2GB.

B.R.

OC

OC,

You can contact the following persons for this.

Business: Allen Yu E-mail: Allen_Yu@kingstonsolutionsinc.com

FAE: Anna Chou E-mail: Anna_Chou@kingston.com.tw

Any part that is less than 2GB will work fine on any device. The problem occurs only when trying to boot from eMMC devices gretaer than 2GB. The kinsgston parts adhere to section 7.4.2 of the eMMC spec.

Regards,

Madan

All,

Did anyone ever verify the proper eMMC image format wrt TOC and MLO?  See my interpretation of the TRM, Image format and TOC.  Any comments welcome.  Thanks.

But the TRM in section 4.7.4.5 says "A configuration header (CH) must be located in the first sector followed by a header. The CH might be void (only containing a CHSETTINGS tem for which the Valid field is zero)."

So, the question is whether the TOC contain information about the MLO section or should have a dummy CHSETTINGS or both?

Thanks,

-Ajesh

Ajesh,

For booting an MLO, the TOC only needs to contain a dummy CHSETTINGS section.

Regards,

Madan

Madan,

Can we walk through example of taking MLO (and possibly u-boot if we span multiple sectors to get 512KB), adding proper header, getting it into eMMC?

Thanks.