OMAP 35x Booting from eMMC BGA package

The OMAP3 ROM boot loader can boot off of MMC, so it should also be able to handle eMMC memory connected to the same interface. The initial boot loader will utilize 1-bit MMC mode so your eMMC device would have to be capible of that, once your boot loader runs you could use the hardware in 8-bit mode.

As to testing, I have booted the OMAP3 EVM off of an SD card many times, I have never tried MMC or eMMC though I imagine operation should be similar.

Sorry for dredging up an old post, but wanted to follow up.  Has TI successfully booted an OMAP 35xx from eMMC?  I ask because I'm having real difficulties recognizing eMMC on 35xx-based hardware and have started to look closely at CMD and CLK at the eMMC device.  At the time when ROM is functioning, it appears that the eMMC is not being recognized.  I'm not positive of this and without the ROM code it's tough to figure out exactly what it's trying to do.

So anybody have first hand experience with actually booting from eMMC?

Hi,

We are planning to use OMAP3503 with eMMC for boot and storage in our design. We are using eMMC [Part No: THGBM1G4D1EBAI7] from Toshiba.

We would like to know OMAP3503 successfully booted with eMMC?

Can you please provide us the following information.

1. Can we use any MMC1 or MMC2 port of OMAP35x for eMMC boot? or any restriction (like Power sequence, IO Voltage etc..)?

2. Is Boot ROM supports 8-bit Mode or only 1-bit mode? If only 1-bit mode what is the performance (MBps)?

3. What is the Maximum performance (MBps) achieved in 8-bit mode?

Looking forward you support.

Thanks

Ranjith

Hi All & Ranjith,

Is eMMC booting is working properly on OMAP3530???

We are planning to use OMAP3730 with eMMC for boot, 

Pls share, if Any body tried & tested ??

Thanks in-advance

Ananth

Hello Ananth,

Yes, you can use eMMC with both OMAP3530 and DM3730.  Here is a link to our MMC setup wiki. 

http://processors.wiki.ti.com/index.php/SD-MMC_Usage_Notes_on_OMAP35x_and_AM37x

Hi,

we tried to boot from a eMMC 4.41 device too.

Bootstrap stops after INIT->CMD0->CMD8->CMD55

The Command CMD8 and CMD55 check if there is a sdcard. But eMMC does not respond like expected and bootstrap scans bus infinite.

The OMAP 35xx /AM35xx supports v4.2 only. Booting from eMMC was introduced in v4.3 first.

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.

Our 35x board boots from eMMC? For more details you can contact me on imtiyaj@ariemtech.com

Hi Pomsler,

You seem to be confusing between the special Boot partition (accessed using switch cmd in a already booted system) and the associated Boot logic supported by the new eMMC devices and a generic boot of SD/MMC device (which should include eMMC devices also) in turn in Raw or FAT mode.

Based on what ever limited test we have done (Rather we goofed up and swapped the voltages to our eMMC device, so currently not able to use eMMC in our board), the ROM Bootloader/Code seems to properly trigger the CMD1 to try and identify if it is a MMC device (which includes eMMC) or not (again as discussed in the TRM). However because we don't have a active eMMC device on the mmc i/f it fails there and we aren't able to test eMMC booting beyond this point in our current spin.

In your case you have not mentioned about CMD1 but talk about CMD55(which means it has already assumed that MMC is not present), which seems bit strange and different from the sequence mentioned in the TRM (as well as what we probed in our board). Cross check once again. May be something is wrong and CMD1 is failing that is the reason it is trying a SDCard boot rather than a MMC boot.

Based on TRM,

a) if one has a FAT partition as a full device (i.e no partition table) or with partition table (ensure active flag is set - had some issue with SD card booting long time back but don't remember the details now as to whether it was at rom code level or xloader level issue). And in turn if it has the proper MLO (x-loader) file in the root directory, it should load it.

OR

b) It will try a raw mode booting, where it will the check the initial sector for the header structure defined in TRM and then goes about accordingly.

Hope it helps.

HanishKVC

The Bootstrap has send the CMD1 too and stopped after this..

INIT->CMD0->CMD8->CMD55->CMD1

The eMMC, that is connected to the bus ignores the given Voltage Levels and returns always the Voltage level, that it requires. This is written in the JEDEC standard v4.41 chapter 7.4.2 "Operation Voltage range validation"

The device answers with busybit 'high' on the line.

Then the strange thing occures: the bootstrap starts after a few ms again with INIT...

i set the ext reg 179 to boot from user partition. i flashed also a bootloader with the 8 header bytes in.

Hi Pomsler,

This seems to indicate that the ROM CODE is trying to find if there is a SD Card (ACMD41), and in turn because eMMC doesn't respond to it (which is correct), it should be potentially trying the other option that is MMC card (including eMMC, using CMD1). In turn because your eMMC is not coming out of its reset procedure (i.e getting into ready state and giving a valid R3 back to Host) the Boot ROM code is potentially timing out and retrying again. (I haven't dumped (or even tried for that matter) the ROM Code currently, so I am just guessing this based on what you have mentioned and what is in TRM.

Now the thing which you have to see is why is your eMMC device still in busy state. I assume

a) your reset line is released

b) When you say device answer with busybit high on the line (I assume you get some response with busy bit set in OCR part of R3 for CMD1) (OR if it is D0 line based busy response or some such thing, I haven't got into SD phy layer before beyond basic things, so not sure if such a thing is valid for CMD1).

c) the VCC and VCCQ voltages are correct (We messed up here by swapping 1.8v and 3.3v - overconfident oversight :-(

d) Are the OCR argument sent as part of CMD1 valid for your eMMC like Sector Mode/Byte Mode, Voltage range (Will be surprised if it doesn' find any valid match which satisfy both end i.e HOST and DEVICE, but just confirming). Worth cross checking to be on safe side.

I will also think thro further and see if I have missed out anything, but for now these are the ideas I get. Also I require to check on my board and see if I am getting only CMD1(s) or even if I am also getting CMD0-CMD8-CMD55 sequence which you seem to be getting. Currently I have a very basic logic analyser only on hand with 4K buffer or so  which generates VCD dumps and no trigger mechanism, which in turn I am decoding to bitstream using my own hand rolled python code (just did it today) so difficult to get good traces at my end, but with what ever few traces I captured, I don't remember noticing CMD8 and CMD55, but I have to capture more and check (But again as I had the voltage issue I hadn't bothered till today).

Hi Imtiaj,

As you have a working board with eMMC at your end, can you see any difference / issue here, which we might have missed out.

Hi Pomsler,

Just so that I haven't mis interpreted you, are you saying that for you CMD1 succeeds with BusyBit in OCR registor data in R3 as 1 (i.e NOT busy). But still the ROM CODE seems to get stuck in a loop???? In which case have you checked if it tries to read any sectors?

OR are you saying that CMD1 fails with busy bit being set (i.e == 0). In which case what I mentioned in my earlier post still holds good.

We are using eMMC on Port2 with VMMC2 connected to Vcc and VIO (1.8v) connected to Vccq (Rather this is what we should have done). In turn the ROM Boot CODE does change the VMMC2 voltage to 3V as required. How about you?

Hi,

now i got more details. The clkout line is now looped back into clkin (dat7).

2x~100 clocks -->

CMD0 (args=0)--> 

CMD8 -->

<-- no response

CMD55-->

<--no response

CMD 1 () -->

<-- response with device is busy

CMD 1 (other voltage level) -->

<-- response with device is busy

In previous postings i read the ocr content in wrong order. 

Now i can see that CMD is send with AccessMode=ByteMode 

Our device answers with 0b10=SectorMode and busy.

Hi Pomsler,

If the host sends with the wrong Access mode, then the eMMC will deadlock, if my interpretation of eMMC spec is correct.

However at the same time I am surprised that the ROM code is sending AccessMode as ByteMode, because I see it sending SectorMode in my case (I am using DM3730 chip and using MMC2 port) let me recheck my interpretation of the bits on the CMD line (Cross checked once again, dumped below at the end).

However you can

Step1) After booting into your device using another boot mode like SDCard or NAND or uart3 or ...

Step2) do a hardware reset of eMMC using its reset line and

Step3) Try handshaking with eMMC using the proper OCR bits in the CMD1 which you will be generating in your code.

Step4) And in turn configure the eMMC and in turn try reading the Sector 0 and Sector 1 and see those are succeding properly

If this succeeds then you have to check with Ti as to why in your case you are getting ByteMode in the AccessMode field in the CMD1 argument from ROM BOOT CODE.

*** MY CMD line capture dump interpretation***

Markers: ['#', '#', '!']
0 0 0 0 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1
0                  --- Start (Cmd)
1                  --- Host
0 0 0 0 0 1        --- Cmd1
0                  --- Busy bit ignored in Cmd
1 0                --- Sector mode
0 0 0 0 0          --- Reserved bits
1 1 1 1 1 1 1 1 1  --- 2.7 to 3.6V
0 0 0 0 0 0 0      --- 2.0 to 2.6V
0                  --- 1.7 to 1.95V
0 0 0 0 0 0 0      --- Reserved
0 0 0 0 1 0 1      --- CRC Bits (Haven't cross verified)
1                  --- Stop bit
1 1 1 1 1
0                  --- Start (Response)
0                  --- Slave/Device
1 1 1 1 1 1        --- Check 6 1s
0                  --- Busy
0 0                --- Byte mode (Either way not valid till Device comes out of Reset mode)
0 0 0 0 0          --- Reserved bits
1 1 1 1 1 1 1 1 1  --- Supports 2.7 to 3.6V
0 0 0 0 0 0 0      --- 2.0 to 2.6V
1                  --- Supports 1.7 to 1.95V
0 0 0 0 0 0 0      --- Reserved
1 1 1 1 1 1 1      --- Check 7 1s
1                  --- Stop bit
1 1 1 1 1 1 1 1 1 1 1 1 1

Hi,

the bootstrap sends always the ByteAcess Mode, which fails.

if we boot from another device and use our own MMC-Driver for accessing the eMMC device, where we set it to use SectorMode, then the device get's out of busy.

This means the TI-Bootstrap supports only byte accessmode.

Hi Pomsler,

The bitstream dump which I pasted in my previous response is what is generated from the BOOT ROM CODE in 3730. And as you can see it is specifying Sector mode in my case. So cross check why it is the other way round in your chip. Which Ti SOC are you using and what port in it. As mentioned I am using 3730 and MMC2 port.

Only thing I can think of is, may be initialy it is sending Byte mode in my case also, but as I am not able to capture the initial few handshakes I missed it out. And after first few tries with Byte mode it is switching to Sector mode. But that would seem like a strange behaviour or a deadlock. As I have swapped 1.8 and 3v between my Vcc and Vccq, I am assuming that the wrong core voltage is what is keeping my eMMC in busy state (I cann't correct the swap and check till next spin of the board, we didn't assume we will make such silly mistake, so didn't provide any points to tap this).

So, i think the Bootstrap is wrong.

It does not try to send a CMD1 with sectormode.

The connected eMMC device answers correct with busy, if there is only bytemode selected.

The MMCHS_REV registers are all 0x26000000

CONTROL.CONTROL_IDCODE[31:0] = 0x1b86802f

Not sure of your Ti SOC from the IDCODE (but it is Different from 3730, I haven't dumped it in mine, but TRM says different), but if your SOC BOOTROM CODE is only generating CMD1 with Byte Access mode,  then do cross check with your TI CONTACT wrt this and what strategy they have going forward for your selected SOC.

In case of 3730 it is generating CMD1 with SECTOR access mode properly (except for a remote possibility which I mentioned previously) (NOTE: However I find that it doesn't set the 1.7 to 1.95V Voltage range bit in CMD1, but that is a different issue from yours.)

Only suggestion I can give is, if it has multiple MMC ports and it supports boot support on more than 1 MMC port, cross check what CMD sequence it generates on your other boot supported MMC port(s) and see if it helps you.

My Question is:

Why does the TI Boot ROM not try to access the eMMC device in SectorMode?

If the device answers to a CMD8, then it supports sector access. -->it is an SD card compliant with standard 2.0 or later

If the device does not answer to CMD8 then it has byte access only.

The used eMMC does not answer on a CMD8.

Hi,

i read the memory address

@0x4001bffc = 0x00000000. This is a strange value. i expected something like 0x0000XXYY.

@0x00014020 = 0x8B63DB59 which is a crc over bootrom. HAs somebody a different version?

So, after debuggin a while i got the following:

@0x15a30, memory boot starts by setting trace vector to 0x1b

@0x1702e, the trace vector is touched again

@0x1745c, @0x17476, @0x17538 a command is send

- The Code uses the SRAM (Stack), because there are some Pushes and Pops inside.

@0x15ade the tracing vector changes to 0x3b, "No more devices to check"

and resets by starting again with 0x14000

Why does it reset?