OMAP-L138: Boot from second MMC interface (SD1)

James Hall2

Part Number: OMAP-L138
Other Parts Discussed in Thread: OMAPL138

Hi E2E support,

I have checked the OMAP-L138 bootloader guide (sprab41f), and notice that the SD1 boot mode is missing from the table in appendix 1. We have a prototype being manufactured which has an eMMC part on SD0 which will be the normal boot device, and an SD card slot on SD1 which we wish to boot from to perform development and initial preparation of the board.

Would SD1 mode simply be the next mode number from SD0 (00x1 1101 rather than 00x1 1100)?

Many thanks,

James

over 4 years ago

0 Rahul Prabhu over 4 years ago

TI__Guru** 116170 points

Based on boot ROM spec here is the different SDMMC mode supported:

DEVICE_BOOTMODE_SDMMC0, // 0x00x1 1100
DEVICE_BOOTMODE_SDMMC1, // 0x00x1 1101

So as you suspected it simply the next mode number from SD0 except BOOTMODE[5] should be set to indicate either MMC or SD.

Regards,

Rahul

0 James Hall2 over 4 years ago in reply to Rahul Prabhu

Intellectual 260 points

Hi Rahul,

Thank you very much for your reply and for checking the bootrom. It is extremely good news that we can select SD1! I could not think of a logical reason why it should not support it. Just odd that it is not in the published document.

Regards,

James

0 James Hall2 over 4 years ago in reply to Rahul Prabhu

Intellectual 260 points

Hi again Rahul,

Since my previous reply we now have possession of some of our prototype boards. It seems that when setting the boot mode to 00011101, I cannot see the clock line to the SD1 interface toggling on an oscilloscope.

In contrast when setting the boot mode to 00011100, I do see the clock line to the SD0 interface toggling (although this goes to a soldered eMMC part which is blank).

Is there some other pre-condition that I should check for booting from SD1?

Many thanks,

James

0 Rahul Prabhu over 4 years ago in reply to James Hall2

TI__Guru** 116170 points

James,

From the ROM perspective, I don`t see any precondition. To elaborate here is the code and you compare the flow to SD0:

// Configure for selected boot mode
  switch (bl1Handle->bootMode)
  {
     .........................
    case DEVICE_BOOTMODE_SDMMC0:
      bl1Handle->bootPeripheral = DEVICE_BOOTPERIPHERAL_SDMMC;
      bl1Handle->devNumber = 0;
      bl1Handle->bitsPerShot = 8;
      bl1Handle->isMaster = 1;
      bl1Handle->protocolImplement  = &BL_AIS_bootload;
      bl1Handle->openPeripheral     = &BL_SDMMC_open;
      bl1Handle->readBytes          = &BL_SDMMC_read;
      bl1Handle->closePeripheral    = &BL_SDMMC_close;
      bl1Handle->abortFxn           = &BL_SDMMC_abortBoot;
      bl1Handle->bootSearchOffset   = 0x200;
      break;

    case DEVICE_BOOTMODE_SDMMC1:
      bl1Handle->bootPeripheral = DEVICE_BOOTPERIPHERAL_SDMMC;
      bl1Handle->devNumber = 1;
      bl1Handle->bitsPerShot = 8;
      bl1Handle->isMaster = 1;
      bl1Handle->protocolImplement  = &BL_AIS_bootload;
      bl1Handle->openPeripheral     = &BL_SDMMC_open;
      bl1Handle->readBytes          = &BL_SDMMC_read;
      bl1Handle->closePeripheral    = &BL_SDMMC_close;
      bl1Handle->abortFxn           = &BL_SDMMC_abortBoot;
      bl1Handle->bootSearchOffset   = 0x200;
      break;
.....................
}

The BL_SDMMC_open is called to initialize the interface

/************************************************************
* Global Function Definitions                               *
************************************************************/

#pragma CODE_SECTION (BL_SDMMC_open, ".text:bl1_sdmmc")
Uint32 BL_SDMMC_open (BL_CfgHandle bl1Handle)
{
  SDMMC_MEM_Type memType = (SDMMC_MEM_Type) ((bl1Handle->bootPins >> 5) & 0x1);

  // Device level init for SDMMC
  DEVICE_SDMMCInit(bl1Handle->devNumber);
  
  // Now open the SDMMC device
  bl1Handle->sdmmcMemInfo = (void *) SDMMC_MEM_open(bl1Handle->devNumber, NULL, memType);

  if (bl1Handle->sdmmcMemInfo == NULL)
  {
    return BL_ERROR_UNKNOWN;
  }

  // Assign static data in bootloader structure
  bl1Handle->memBuffer    = gMemBuff;
  bl1Handle->memBufferPtr = 0;
  bl1Handle->memCurrAddr  = 0;

  // The open operation succeeded
  return BL_ERROR_NONE;
}

So the initialization, I believe should work the same way on SD1 as in case of SD0. Can you please check from HW design perspective if your SD0 and SD1 are connected in the same manner?

Regards,

Rahul

0 James Hall2 over 4 years ago in reply to Rahul Prabhu

Intellectual 260 points

Hi again Rahul,

Firstly thank you for your prompt reply and for looking into the code for me.

I have carefully checked the schematic and layout some more and cannot see any issue with the boot bits and SD interface lines.

However I was interested to see what those referenced bootrom functions do (DEVICE_SDMMCInit and SDMMC_MEM_open).

I found the following snippet on the web:

Uint32 DEVICE_SDMMCInit(Uint8 periphNum)
{
  // Assign the correct register base
  if (periphNum >= SDMMC_PERIPHERAL_CNT)
  {
    return E_FAIL;
  }
  
  switch (periphNum)
  {
    case 0:
      DEVICE_LPSCTransition(PSCNUM0, LPSC_SDMMC0, PD0, PSC_ENABLE);
      DEVICE_pinmuxControl(10,0xFFFFFFFF,0x22222222); // CLK, CMD, DAT[5:0]
      DEVICE_pinmuxControl(11,0x000000FF,0x00000022); // DAT[7:6]
      break;
    case 1:
      DEVICE_LPSCTransition(PSCNUM1, LPSC_SDMMC1, PD0, PSC_ENABLE);
      DEVICE_pinmuxControl(10,0xFF0FFF00,0x11022200); // CLK, CMD, DAT[7:6,0]
      DEVICE_pinmuxControl(11,0x000FFFFF,0x00022211); // DAT[5:1]
      break;
    default:
      return E_FAIL;
  }

  return E_PASS;
}

Source URL:http://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/42/4426.device.c

I cannot be sure that this is the actual code from the OMAP-L138 bootrom (some macros at the top of the file referenced DA850 and C6746 so I think it might be), but if it is then it seems to have a problem.

SD1 interface is on pinmux registers 18 and 19, but registers 10 and 11 are being set in this function.

Could you please check the actual code to see if this problem is there? Is there any way for us customers to get access to the bootrom source?

Many thanks,

James

0 Rahul Prabhu over 4 years ago in reply to James Hall2

TI__Guru** 116170 points

James,

Boot ROM source is not distributed to customers primarily because we do have a secure boot implementation on this device in the boot ROM. We have in the past shared snippets of code as I have done that relates to configuration of the peripherals but have not shared the full source.

Let me check on the pinmux configuration in ROM but you may also be able to check this on the failing board when the boot fails, if you connect the JTAG to the device and read the pinmux register, you can see the ROM configuration. In the meantime, I will also try to look up SD boot ROM validation data to see if SD1 interface was tested as most of our customers and EVM have been using SD0 for booting.

Regards,

Rahul

0 James Hall2 over 4 years ago in reply to Rahul Prabhu

Intellectual 260 points

Thanks again Rahul,

I actually did try to connect with JTAG (I have XDS110), but I've never tried to connect to the ARM core in the past (I've only done DSP development with JTAG) and could not successfully connect to the ARM.

Unfortunately the DSP is in reset, so I cannot read the registers from that side when the processor is in this state.

When I get a chance I will try to search for my ARM JTAG attach issue on this forum to see if I can solve this.

It will be interesting to hear what you find in the pinmux setup in DEVICE_SDMMCInit.

Many thanks,

James

0 UNA over 4 years ago

Mastermind 7980 points

Part Number: OMAP-L138

Hi,

I would like to know if the OMAP-L138 can boot with MMC/SD1 port.
A similar question has been posted in the following thread, but the thread has been closed with the Boot ROM support status unclear.

So, I'd like clarification on whether the BOOT ROM is in a Pinmux configuration for MMC/SD1.
Also, is the AIS tool compatible with MMC/SD1?

Best Regards,
UNA

e2e.ti.com/.../945103

0 James Hall2 over 4 years ago in reply to James Hall2

Intellectual 260 points

Hi Rahul,

Is there any update on the investigation of the bootrom code?

Regards,

James

0 Rahul Prabhu over 4 years ago in reply to James Hall2

TI__Guru** 116170 points

James,

I looked into the ROM code and have confirmed that the code that you have post for DEVICE_SDMMCInit does match with what has been used with OMAPL138 boot ROM. Also, based on ROM revision history, only MMC/SD0 boot was added to the Boot ROM in PG 2.1 as mentioned in Appendix E of the bootloader application notes:

https://www.ti.com/lit/an/sprab41f/sprab41f.pdf

All of the ROM validation tests indicate only SD0 was validated for booting. It appears there is code/provision in the ROM for SD1 but this was not scoped and validated so unfortunately, it appears on Sd0 can be used for SD boot. I apologize for the confusion that this may have caused.

Regards,

Rahul

0 James Hall2 over 4 years ago in reply to Rahul Prabhu

Intellectual 260 points

Hi Rahul,

I'm still trying to figure out a way to boot this board. We have so far been unsuccessful at getting a UART (AIS) supplied uboot image to work, and Code Composer just won't talk to the ARM core via the XDS110 (I cannot get this working on my LCDK board either).

I was wondering whether a workaround could be done to boot from SD1 by using some AIS commands supplied via a UART boot.

Some "Boot Table" commands could be provided to write to the correct registers to power up the SD1 peripheral.

Then maybe some variables in the bootrom could be updated to overwrite the boot mode to be SD1, and jump to an appropriate function in the bootrom which then goes on to boot from SD1.

As an alternative the UART boot AIS could contain all code required to boot from the SD card. Do you such code available to share?

This would at least give us a way to perform an initial boot from SD card before writing to the on board eMMC.

Thanks,

James

0 James Hall2 over 4 years ago in reply to James Hall2

Intellectual 260 points

Hi Rahul,

Please can you advise? These PCBs are currently not moving forward because of this bootrom bug. Can you help with the above suggested workaround to get initial code onto the boards?

Regards,

James

0 James Hall2 over 4 years ago in reply to James Hall2

Intellectual 260 points

Also please remove the "resolved" marker from this thread.

0 Rahul Prabhu over 4 years ago in reply to James Hall2

TI__Guru** 116170 points

James,

Ones a post is marked resolved, we can`t remove the marker. The only option is to start a related thread.

At the current moment, it appears , we can`t support direct boot from SD1. The recommendation would be to use SD0 for SD/MMC boot. you can first test the image with LCDK and then try it on your PCB.

Please note, when you are porting uboot, you will also need to change the external memory (mDDR/DDR2) configuration. Please provide your AIS configuration and indicate how it is different from what we provide for the LCDK. Please also connect using JTAG to the ARM And let us know what is the value of the program counter so we can provide some guidance on where it hangs in ROM.

Regards,

Rahul

Processors

Processors forum

OMAP-L138: Boot from second MMC interface (SD1)