Search

Technical Discussion Group Forum

This forum is provided for user discussion. While Beacon EmbeddedWorks support staff and engineers participate, Beacon EmbeddedWorks does not guarantee the accuracy of all information within in the Technical Discussion Group (TDG).

The "Articles" forums provide brief Articles written by Beacon EmbeddedWorks engineers that address the most frequently asked technical questions.

To receive email notifications when updates are posted for a Beacon EmbeddedWorks product download, please subscribe to the TDG Forum of interest.

TDG Forum

PrevPrev Go to previous topic
NextNext Go to next topic
Last Post 06 Feb 2017 08:34 AM by  Adam Ford
DM37x Mainstream Linux BSP U-Boot Reboot Failure
 19 Replies
Sort:
You are not authorized to post a reply.
Author Messages
James Balean
New Member
New Member
Posts:5


--
09 Jan 2017 01:27 AM

    I am able to successfully boot the DM37x Mainstream Linux Demo Image v1.0.0. However I encounter the following error message when attempting to reboot the board:

     

    [   18.967102] reboot: Restarting
    U-Boot SPL 2016.03 (May 11 2016 - 00:30:42)
    Trying to boot from MMC
    spl: mmc init failed with error: -17
    SPL: failed to boot from all boot devices
    ### ERROR ### Please RESET the board ###
    

     

    Are you aware of this problem? Can you advise what some possible causes are or alternatively if you have a solution? I have been debugging the following U-boot source files, to no avail: boards/logic/omap3som/omap3logic.c, drivers/mmc/mmc.c and common/spl/spl_mmc.c. I suspect the MMC/SD/SDIO card interface or TWL4030 is not being reset properly. 

     

    This reboot behaviour is exhibited on versions of U-boot up to 2017.01.

     

    Thanks,
    Jeeb

    Adam Ford
    Advanced Member
    Advanced Member
    Posts:794


    --
    09 Jan 2017 08:13 AM
    I have seen that occasionally, and I have spent some time trying to resolve it. Unfortunately, the solution isn't clear. Usually power cycling the board or ejection and reinsertion of the card help. I have also seen some SD cards that are more susceptible, but I haven't identified the root cause as of yet.

    It is on my list of things to investigate.

    adam
    Adam Ford
    Advanced Member
    Advanced Member
    Posts:794


    --
    09 Jan 2017 11:56 AM
    I am going to submit the following patch to the U-Boot community for review. It seems to be specific for the OMAP36xx and up.

    diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
    index 0a1ee40..f3b794a 100644
    --- a/drivers/mmc/omap_hsmmc.c
    +++ b/drivers/mmc/omap_hsmmc.c
    @@ -38,6 +38,7 @@
    #include
    #endif
    #include
    +#include

    DECLARE_GLOBAL_DATA_PTR;

    @@ -115,6 +116,10 @@ static unsigned char mmc_board_init(struct mmc *mmc)
    PBIASSPEEDCTRL0 | PBIASLITEPWRDNZ0,
    &t2_base->pbias_lite);

    + if (get_cpu_family() == CPU_OMAP36XX)
    + writel(readl(OMAP34XX_CTRL_WKUP_CTRL) | OMAP34XX_CTRL_WKUP_CTRL_GPIO_IO_PWRDNZ,
    + OMAP34XX_CTRL_WKUP_CTRL);
    +
    writel(readl(&t2_base->devconf0) | MMCSDIO1ADPCLKISEL,
    &t2_base->devconf0);
    Adam Ford
    Advanced Member
    Advanced Member
    Posts:794


    --
    09 Jan 2017 12:14 PM
    jeeb -

    The OMAP36xx (and 37xx) have an extra register that the 3430 does not. It appears as if the default PBIAS configuration does not address the OMAP36 specific registers.

    After applying the above patch, I wasn't able to reproduce the issue (although I wasn't able to reproduce it before with any level if certainty).

    Let me know if that helps. I applied that against the 2017.01-RC3 build.

    Adam Ford
    Advanced Member
    Advanced Member
    Posts:794


    --
    09 Jan 2017 01:12 PM
    The patch was submitted and a link to it is here:

    http://patchwork.ozlabs.org/patch/712886/

    Since I am not the hs_mmc maintainer, I wanted to request feedback first.
    James Balean
    New Member
    New Member
    Posts:5


    --
    10 Jan 2017 01:33 AM
    Hi Adam,

    Thank you for your work on this - greatly appreciated.

    I applied the patch, however unfortunately it didn't resolve the issue. I still receive the "Please RESET the board" message on every reboot of my devices regardless of the SD card brand/speed and even if ejected and reinserted. Do you have any other suggestions?


    Looking at the dm37x manual, it would appear as though your patch is required though. My understanding is that GPIO_IO_PWRDNZ should be unset (disabling the extended-drain I/O cell), PBIASLITEVMODE1 should be unset to configure SIM_VDDC to 1.8V, then finally GPIO_IO_PWRDNZ should be set when the voltage has stabilized. Keen for your feedback on the following revised patch.

     

    
    --- uboot-custom.orig/drivers/mmc/omap_hsmmc.c  2016-05-02 11:14:18.000000000 -0500
    +++ uboot-custom/drivers/mmc/omap_hsmmc.c       2017-01-10 00:37:54.054615493 -0600
    @@ -38,6 +38,7 @@
     #include 
     #endif
     #include 
    +#include 
    
     DECLARE_GLOBAL_DATA_PTR;
    
    @@ -139,7 +140,8 @@ static unsigned char mmc_board_init(stru
     #if defined(CONFIG_OMAP34XX)
            t2_t *t2_base = (t2_t *)T2_BASE;
            struct prcm *prcm_base = (struct prcm *)PRCM_BASE;
    -       u32 pbias_lite;
    +       u32 cpu_family;
    +       u32 pbias_lite, wkup_ctrl;
    
            pbias_lite = readl(&t2_base->pbias_lite);
            pbias_lite &= ~(PBIASLITEPWRDNZ1 | PBIASLITEPWRDNZ0);
    @@ -147,12 +149,29 @@ static unsigned char mmc_board_init(stru
            /* for cairo board, we need to set up 1.8 Volt bias level on MMC1 */
            pbias_lite &= ~PBIASLITEVMODE0;
     #endif
    +#ifdef CONFIG_TARGET_OMAP3_LOGIC
    +       /* for Torpedo board, we need to set up 1.8 Volt SIM_VDDS bias level */
    +       pbias_lite &= ~PBIASLITEVMODE1;
    +#endif
            writel(pbias_lite, &t2_base->pbias_lite);
    
    +       cpu_family = get_cpu_family();
    +       if (cpu_family == CPU_OMAP36XX) {
    +               wkup_ctrl = readl(OMAP34XX_CTRL_WKUP_CTRL);
    +               wkup_ctrl &= ~OMAP34XX_CTRL_WKUP_CTRL_GPIO_IO_PWRDNZ;
    +               writel(wkup_ctrl, OMAP34XX_CTRL_WKUP_CTRL);
    +       }
    +
    +       udelay(150); // Is SDMMC1_VDDS/SIM_VDDS stable?
    +
            writel(pbias_lite | PBIASLITEPWRDNZ1 |
                    PBIASSPEEDCTRL0 | PBIASLITEPWRDNZ0,
                    &t2_base->pbias_lite);
    
    +       if (cpu_family == CPU_OMAP36XX)
    +               writel(wkup_ctrl | OMAP34XX_CTRL_WKUP_CTRL_GPIO_IO_PWRDNZ,
    +                       OMAP34XX_CTRL_WKUP_CTRL);
    +
            writel(readl(&t2_base->devconf0) | MMCSDIO1ADPCLKISEL,
                    &t2_base->devconf0);
    
    --- uboot-custom.orig/board/logicpd/omap3som/omap3logic.c       2017-01-10 00:34:19.014607424 -0600
    +++ uboot-custom/board/logicpd/omap3som/omap3logic.c    2017-01-10 00:39:47.714619758 -0600
    @@ -36,10 +36,6 @@
    
     DECLARE_GLOBAL_DATA_PTR;
    
    -#define CONTROL_WKUP_CTRL      0x48002a5c
    -#define GPIO_IO_PWRDNZ (1 << 6)
    -#define PBIASLITEVMODE1        (1 << 8)
    -
     /*
      * two dimensional array of strucures containining board name and Linux
      * machine IDs; row it selected based on CPU column is slected based
    @@ -144,16 +140,6 @@ static struct musb_hdrc_platform_data mu
      */
     int misc_init_r(void)
     {
    -       t2_t *t2_base = (t2_t *)T2_BASE;
    -       u32 pbias_lite;
    -       /* set up dual-voltage GPIOs to 1.8V */
    -       pbias_lite = readl(&t2_base->pbias_lite);
    -       pbias_lite &= ~PBIASLITEVMODE1;
    -       pbias_lite |= PBIASLITEPWRDNZ1;
    -       writel(pbias_lite, &t2_base->pbias_lite);
    -       if (get_cpu_family() == CPU_OMAP36XX)
    -               writel(readl(CONTROL_WKUP_CTRL) | GPIO_IO_PWRDNZ,
    -                               CONTROL_WKUP_CTRL);
            twl4030_power_init();
    
            omap_die_id_display();
    
    Adam Ford
    Advanced Member
    Advanced Member
    Posts:794


    --
    10 Jan 2017 08:52 AM
    The latest version of the U-Boot source already has the stuff deleted from misc_init_r.

    I agree with most of your changes. I'll clean it up a bit to a form that I think will be accepted by the mainline community and submit an updated patch. I already received some feedback from them already. I'll combine their with yours, test and resubmit.

    adam
    Adam Ford
    Advanced Member
    Advanced Member
    Posts:794


    --
    10 Jan 2017 09:38 AM
    I attempted your patch, but I get an SPL MMC error.

    When I reverted back to my original submission, it works again on the Logic PD Torpedo kit. I did a devmem after Linux booted on the 0x48002520 register to see what it reads. It read 0x00000287 which means:


    PBIASLITESUPPLYHIGH1 = 0 (SIM_VDDS = 1.8 V)
    PBIASLITEVMODEERROR1 = 0 (VMODE Level same or VMODE level not considered)

    PBIASLITEPWRDNZ1 = 1 (SIM_VDDS stable)
    PBIASLITEVMODE1 = 0 (SIM_VDDS = 1.8 V)

    PBIASLITEVMODEERROR0 = 0 (VMODE level same or VMODE level not considered)

    PBIASLITESUPPLYHIGH0 = 1 (PBIAS0 is supplied by SDMMC1_VDDS = 3.0 V)
    PBIASLITEPWRDNZ0 = 1 (SDMMC1_VDDS stable)
    PBIASLITEVMODE0 = 1 (SDMMC1_VDDS = 3.0 V)

    I believe those are all correct.
    James Balean
    New Member
    New Member
    Posts:5


    --
    11 Jan 2017 04:35 AM

    Hi Adam,

     

    Sadly I am running out of ideas to resolve my reset problem. Have you observed it since your patch?

     

    Regarding the revised patch I sent through, what SPL MMC error code did you receive? Was it only on reboot as per my original issue? Sorry I forgot to include a one line change to 'arch/arm/include/asm/arch-omap3/mmc_host_def.h' with the bit mask #define PBIASLITEVMODE1 (1 << 8) by the way.

     

    It seems strange that you obtain the correct register value of 0x287 with your patch and the 2017.01 release. Now that the code in misc_init_r which configures PBIASLITEVMODE1 has been removed, SIM_VDDS will be 3.0V instead of the 1.8V we want for the Torpedo (3V is the default reset value of the chip). Hence why devmem reads 0xb87 for the 0x8002520 register when I apply your patch:

     

    PBIASLITESUPPLYHIGH1 (bit 15) = 0 (SIM_VDDS = 1.8V)
    PBIASLITEVMODEERROR1 (bit 11) = 1 (VMODE_LEVEL not same as SUPPLY_HI_OUT)

    PBIASLITEPWRDNZ1 (bit 9) = 1 (SIM_VDDS stable)
    PBIASLITEVMODE1 (bit 8) = 1 (SIM_VDDS = 3.0V)

    PBIASLITEVMODEERROR0 (bit 3) = 0 (VMODE level same or VMODE level not considered)

    PBIASLITESUPPLYHIGH0 (bit 7) = 1 (PBIAS0 is supplied by SDMMC1_VDDS = 3.0V)
    PBIASLITEPWRDNZ0 (bit 1) = 1 (SDMMC_VDDS stable)
    VMODE0 (bit 0) = 1 (SDMMC_VDDS = 3.0V)

     

    I do receive the correct reading 0x287 after setting PBIASLITEVMODE1=0 (SIM_VDDS=1.8V) from my previous comment. The other code I added to your patch is because the chip manual advises that PBIASLITEPWRDNZ0, PBIASLITEPWRDNZ1 and GPIO_IO_PWRDNZ should be set and unset together.

     

    -jeeb

     

    Adam Ford
    Advanced Member
    Advanced Member
    Posts:794


    --
    12 Jan 2017 06:35 AM
    Jeeb - What version of Linux are you using? Are you using the Logic PD Torpedo Development kit or something else? I'll try to match my Linux to yours and see if it's Linux related. I've submitted a query to a couple people from TI who contribute to the U-Boot and Linux projects to see if they have any feedback.

    adam
    Adam Ford
    Advanced Member
    Advanced Member
    Posts:794


    --
    12 Jan 2017 08:34 AM
    I did a memory dump in U-Boot and I got the same dump as you did, so I wondering if Linux is doing something to address/fix the SIM_VDDS.
    Adam Ford
    Advanced Member
    Advanced Member
    Posts:794


    --
    19 Jan 2017 12:56 PM
    I have submitted your patch to the U-Boot community for review and I was asked to update a few other options, so that has been pushed. I confirmed the registers are correct using "md.l" in U-Boot, but the issue hasn't been resolved.

    Can you tell me what the full model # or part number of the SOM you are using?

    adam
    Adam Ford
    Advanced Member
    Advanced Member
    Posts:794


    --
    20 Jan 2017 11:45 AM
    I think I have a fix:

    Open the device tree and search toward the bottom for twl_power.

    Change the 'compatible' line to to read:

    compatible = "ti,twl4030-power","ti,twl4030-power-reset", "ti,twl4030-power-idle-osc-off", "ti,twl4030-power-idle";

    With that fix, I have been able to get my board to reboot consistently without issue, and the reboot sequence appears to run faster.

    If you confirm this works, I'll push a patch the mainline kernel.

    adam
    Ryan Crowell
    New Member
    New Member
    Posts:15


    --
    23 Jan 2017 03:54 PM
    I've been quietly following this thread because I have had a similar problem. I'm using a DM3730 Torpedo+Wireless module on a custom carrier board with Buildroot 2016.08.1 and Linux kernel version 4.4.27. I have NEVER been able to reboot this system. It always hangs with an error message similar to that at the start of this thread. Implementing the fix you described above seems to have completely solved my problem. The system reboot without any trouble now!

    Thanks Adam.
    James Balean
    New Member
    New Member
    Posts:5


    --
    23 Jan 2017 10:43 PM

    Hi Adam,

     

    Thanks for working on this while I have been away. I have been following the feedback on your U-boot patch RFC's, and confirm that 'md.l' (and devmem in Linux) now show the correct values for the 0x48002520 register for me using V3 ('[U-Boot,RFC,V3] drivers: mmc: omap_hsmmc: Fix IO Buffer on OMAP36xx'). I'm using U-boot 2017.01 and Linux 4.8.11 on the industrial variant of the Torpedo Wireless SOM.

     

    I did initially suspect a problem with the Linux kernel, though couldn't determine a cause and mistakenly ruled out a device tree error. The change to the device tree driver list for twl_power in arch/arm/boot/dts/logicpd-torpedo-som.dtsi resolves the issue for me! To be certain, I've had a board on a reboot loop test for most of today - no failures so far.

     

    An excellent result! Thank you again Adam!

    Adam Ford
    Advanced Member
    Advanced Member
    Posts:794


    --
    24 Jan 2017 07:09 AM
    I have been in contact with both the U-Boot and OMAP Kernel maintainers. I beleieve we've come to an agreement on the final draft of the patch I will be pushing to get the MMC1 fix in U-Boot.

    The OMAP maintainer believes there might be a bug in the twl4030-power.c file and he has asked me to check some items and report findings. I will keep this thread posted as to the final outcome of the discussion.

    Thanks for the feedback everyone.

    If you find more bugs, please feel free to post a new thread and I'll try to address them as I have time.

    adam
    Adam Ford
    Advanced Member
    Advanced Member
    Posts:794


    --
    26 Jan 2017 09:51 AM
    One of the side-effects of this work-around is higher power consumption.

    I have been working with people in the open source community and some of the OMAP experts have given me some ideas to try. I'll try to work through those over the next few days to see if we can get the reset working and keep the power consumption low.

    adam
    Adam Ford
    Advanced Member
    Advanced Member
    Posts:794


    --
    29 Jan 2017 06:43 AM
    I have a patch that seems to be fixing the issue and it allows the "ti,twl4030-power-idle-osc-off" compatible flag to keep the power low.

    I submitted the patch this morning.

    It is located: https://patchwork.kernel.org/patch/9543955/

    You should be able to undo the previous work-around and leave the compatible flag to "ti,twl4030-power-idle-osc-off" to reduce power consumption.

    adam

    James Balean
    New Member
    New Member
    Posts:5


    --
    03 Feb 2017 02:55 AM

    Hi Adam,

     

    Excellent news. Confirm that the patch achieves the same result without modifying the device tree. You mentioned that you were talking to the U-Boot community about possible changes to the TWL4030 code. Do you still see a requirement for changes to U-Boot, such as resetting VMMC1 on boot? Or is the problem completely resolved by the Linux Kernel patch?

     

    -jeeb

    Adam Ford
    Advanced Member
    Advanced Member
    Posts:794


    --
    06 Feb 2017 08:34 AM
    I still believe the U-Boot patches are important to ensure the correct operation of VMMC. I will be submitting a second patch once the first one is applied, however the U-Boot patch doesn't seem to have as much of an impact as the kernel patch to the PMIC driver which prevents the shutdown of the VMMC1 rail.

    I just returned from being out of the office and I need to follow up on both patches to see if they've been reviewed and/or applied to their respective trees.

    adam
    You are not authorized to post a reply.