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.

AM335x U-boot problem when booting from eMMC

Other Parts Discussed in Thread: AM3352

Hi,

Customer has find an issue on booting AM3352 from eMMC (on their own board). They are using following versions

U-Boot version:               u-boot-2014.07-g7e537bf (from ti-sdk-am335x-evm-08.00.00.00)

Linux kernel version:     linux-4.1.18 (from ti-processor-sdk-linux-am335x-evm-02.00.02.11)

They sometimes see that U-boot is not able to load Linux image. They have debugged this further and find out that the reason is that get_timer(0) function sometimes gives decreased value compared to previous value which never should happen (except in roll-over) . They have seen e.g.

452424700          OK

452423902          ERROR, decreased value!

452473268          OK

452502021          OK

This behavior is causing false timeout to be triggered in omap_hsmmc.c 

mmc_stat = readl(&mmc_base->stat);
if (get_timer(0) - start > MAX_RETRY_MS) {
   printf("%s: timedout waiting for status!\n",

which then causes image will not be loaded. They have tested this by doing

while true; do run loadimage; done

to reproduce the issue. Sometimes it happens in couple of minutes but sometimes it takes some hours to reproduce.

Any ideas what could cause this issue?

  • Hi,

    Please check AM335x Errata Advisory 1.0.30.
  • Hi Biser,

    Thanks for your reply. Customer said that they have applied this errata fix because they suspect it is root cause for another issue they have. For that they will need at least 3 weeks test to be confident.

    But in any case they are already sure this 1.0.30 errata fix it is not fixing this issue.

    They have tested with four different configurations, and they can see this issue in all of them

    1.       Own HW with u-boot-2014.07-g7e537bf from ti-sdk-am335x-evm-08.00.00.00; posted mode enabled (default setting)

    2.       Own HW with u-boot-2014.07-g7e537bf from ti-sdk-am335x-evm-08.00.00.00; posted mode disabled in u-boot command line

    3.       Beaglebone black rev B6 with bone-debian-8.4-lxqt-4gb-armhf-2016-05-13-4gb.img; posted mode enabled (default setting)

    4.       Beaglebone black rev B6 u-boot-2014.07-g7e537bf from ti-sdk-am335x-evm-08.00.00.00; posted mode enabled (default setting)

    They have already workaround for the issue, which is either to reset mmc controller at U-boot when they see this timeout (see below) or reset the whole u-boot to define CONFIG_BOOT_RETRY_TIME and CONFIG_RESET_TO_RETRY.

    do {
      mmc_stat = readl(&mmc_base->stat);
      if (get_timer(0) - start > MAX_RETRY_MS) {
        printf("%s: timedout waiting for status!\n", __func__);
        //return TIMEOUT;
        mmc_reset_controller_fsm(mmc_base, SYSCTL_SRD);
      }
    } while (mmc_stat == 0);
    

    However they would like to understand what can cause this timer value decreasing as the product is in industrial scope running 24/7.

  • Have they tried with a newer SDK than v08.00.00.00?
  • Hi,

    I received an update that with u-boot-2016.05+gitAUTOINC+2f757e5b2c-g2f757e5b2c from ti-processor-sdk-linux-am335x-evm-03.01.00.06 the bahavior is the same.

    Br,
    Jani
  • I will ask the factory team if they have encountered this and have any suggestions. They will respond here.
  • Hi Biser et all,

    Additional information from customer. They have now tested with kernel from our latest SDK (ti-processor-sdk-linux-am335x-evm-03.01.00.06) and are seeing time jumping back there as well. See picture below

  • Hi Jani,

    This has been assigned within the factory team and I have escalated today. However, based on your last post, I have the feeling that this may be a hardware issue, as we haven't had this sort of issue from a long time. Could you ask them to check their crystal selection and oscillator circuits against the requirements in the AM335x Datasheet? They should also check power supply decoupling and whether they have excessive noise on the power rails and the oscillator signals. Proper grounding is also very important - do they have a solid ground plane?