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.

Linux/AM4378: SD boot MLO issue

Part Number: AM4378

Tool/software: Linux

Hi Everyone!

We have a custom board based on the am437x-gp-evm.  Our latest batch of prototypes is not booting.

The changes in this revision are related to moving the PMIC chip to the second i2c bus, which frees up the other bus for a dedicated task.

The other change was the vendor crossed in some higher grade RAM of the same memory we previously used,  If interested you can check here... 

If I reboot the board over and over, about 1 out of 5 times I will see the MLO splash screen on the console.  Then it halts with some garbage characters.

We have scoped out the SD interface and noticed a few things.  On our previous board the lower speed hand shaking time period is about 100ms longer than on the new boards.  Both versions switch over to the faster bus speed and the data transferred appears to be the same.  I assume this is the MLO being copied to SRAM.  However our older boards continue to boot after that copy.  The new boards halt.

And they really halt.  I can't even connect CCS to them via a JTAG.

We xray'd the boards and there is no difference in traces.  We're stumped.

Any thoughts or help on where to go next would be greatly appreciated.

Thanks in advance,

Nathan

  • Hi Nathan,

    As you change PMIC configuration, I would suggest you first to check and verify power-up sequence is valid. You can change the boot mode from SD card to UART, and if you have CCCC characters on the UART terminal, then the power-up sequence is fine and you can proceed debugging SD card interface.

    processors.wiki.ti.com/.../AM335x_board_bringup_tips

    Regards,
    Pavel
  • Hi Pavel,

    Thanks for your response. I configured the board to boot UART0 and I see a never ending stream of C's on UART0. So it would seem the power-up sequence is fine.

    I will look over the link you provided. Any other ideas?

    Thanks,
    Nathan
  • Following the guide provided...
    1. I can get C's on UART0
    2. If I change boot to MMC0, and insert an SD card that worked on rev 2 of this board, I lock up the processor
    3. If I remove the SD card, I can attach a JTAG and I see 0x0040030C in CTRL_STS register. Checking each bit it seems the ROM read the dip switches correctly.
    - Booting to MMC0 only
    - 24 MHz clock
    - CLKOUT1 disabled
    4. Program counter is at 0x00035A14 , which is not in the range 0x20000-0x2C000 described in the link, but the link is for 335x, so I'm not sure if that matters.

    Is there an equivalent to the am335x-boot.dss file for the am437x processor? Will the am335x-boot.dss work for the 437x?

    Thanks,
    Nathan
  • Since every once in a while I do get some MLO output on UART0... I gave it 20 minutes and rebooted it until I saw console output.

    When I caught it I could attach a JTAG to it.  I copied the reset vectors...

    0x40338E40 - 0010009E 00001000 00000010 02001E00

    ... dissecting these I can see that...

    • vector 1
      • entered main function
      • running after cold reset
      • main booting routine entered
      • header found
      • MMC Configuration Header CHSETTINGS found
    • vector 2
      • Memory booting trial 0
    • vector 3
      • Memory booting device MMCSD0
    • vector 4
      • MMC Card in Ready State(CMD1 complete)
      • Data Read from the MMC Card
      • Master Boot record found
      • Active Partition Found
      • Reserved bit 25 is high

    Anyone know what reserved bit 25 is for?

    The program counter is sitting at 0x00035A7E.

    Thoughts?

    Thanks,

    Nathan

  • Nathan Wright said:
    1. I can get C's on UART0

    Seems that ROM Code runs fine.

    Nathan Wright said:
    2. If I change boot to MMC0, and insert an SD card that worked on rev 2 of this board, I lock up the processor

    Can you try to boot from another source (UART, NAND, Ethernet, USB), thus we will be sure that MMC0 is the main problem. Refer to the below wiki for how to boot from various sources:

    http://processors.wiki.ti.com/index.php/Linux_Core_U-Boot_User's_Guide

    Nathan Wright said:
    4. Program counter is at 0x00035A14 , which is not in the range 0x20000-0x2C000 described in the link, but the link is for 335x, so I'm not sure if that matters.

    This looks correct for AM437x. AM437x ROM Code memory map is from 0x30000 to 0x3FFFC, see AM437x TRM, section 5.2.3.1 Public ROM Memory Map

    Nathan Wright said:
    Is there an equivalent to the am335x-boot.dss file for the am437x processor? Will the am335x-boot.dss work for the 437x?

    No, am335x-boot.dss can not be used for AM437x device. Check the below links for details:

    Regards,
    Pavel

  • Nathan Wright said:

    When I caught it I could attach a JTAG to it.  I copied the reset vectors...

    0x40338E40 - 0010009E 00001000 00000010 02001E00

    ... dissecting these I can see that...

    • vector 1
      • entered main function
      • running after cold reset
      • main booting routine entered
      • header found
      • MMC Configuration Header CHSETTINGS found
    • vector 2
      • Memory booting trial 0
    • vector 3
      • Memory booting device MMCSD0
    • vector 4
      • MMC Card in Ready State(CMD1 complete)
      • Data Read from the MMC Card
      • Master Boot record found
      • Active Partition Found
      • Reserved bit 25 is high

    Anyone know what reserved bit 25 is for?

    The program counter is sitting at 0x00035A7E.

    Thoughts?

    Please compare the trace vectors between successful AM437x MMC0 booting board and non-booting board and check for any differences.

    Do you use the same SD card to boot "good" and "bad" boards? If not, may be your SD card is corrupted, try to format and re-create one with the create-sdcard.sh script.

    Regards,
    Pavel

  • Yes, it is the same card.

    Does the MLO do anything with PMIC or EEPROM? We moved those two devices to i2c1 from i2c0. I think the answer is no because I thought I scoped the busses on the good board and confirmed no activity happens that early in boot.
  • Looks like I was wrong.

    We cut some traces and moved the PMIC and EEPROM back on to i2c0 and the board boots. I removed the u-boot.img so only the MLO was present and there is activity on i2c0.

    So I guess this question now becomes, where in the spl source code do I need to switch it to look at i2c1?
  • We have confirmed the MLO will only boot as long as the PMIC is on i2c0. Removing the eeprom did not stop the MLO from booting. Is there a change I can make to the MLO to tell it to look for the PMIC on i2c1? Or do I need to change my layout and respin my boards?

    Thanks,
    Nathan
  • Ok, some progress :)

    Inside <u-boot./board/ti/am43xx/mux.c

    static struct module_pin_mux i2c0_pin_mux[] = {
    //	{OFFSET(i2c0_sda), (MODE(0) | PULLUP_EN | RXACTIVE | SLEWCTRL)},
    //	{OFFSET(i2c0_scl), (MODE(0) | PULLUP_EN | RXACTIVE | SLEWCTRL)},
    	{OFFSET(spi0_d1), (MODE(2) | PULLUP_EN | RXACTIVE | SLEWCTRL)},
    	{OFFSET(spi0_cs0), (MODE(2) | PULLUP_EN | RXACTIVE | SLEWCTRL)},
    	{-1},
    };
    
    static struct module_pin_mux gpio5_7_pin_mux[] = {
    //	{OFFSET(spi0_cs0), (MODE(7) | PULLUP_EN)},	/* GPIO5_7 */
    	{OFFSET(spi4_cs0), (MODE(7) | PULLUP_EN)},	/* GPIO5_7 */
    	{-1},
    };
    
    #ifdef CONFIG_NAND
    

    And it boots.

  • Hi Nathan,

    Glad to see you have fix it. Please let me know if you have more questions.

    Note also that I2C0 is a strict requirement if low power modes are desired. We do mention using I2C0 with our software in the schematic checklist [1]. If you plan to use the PM features [2] of AM437x supported by the PM firmware, I2C1 will not work.

    [1] processors.wiki.ti.com/.../AM437x_Schematic_Checklist

    [2] processors.wiki.ti.com/.../Linux_Core_Power_Management_User's_Guide_(v4.4)

    Regards,
    Pavel