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/AM6548: UBOOT/AM6548: SD card timeout error when boot from ospi flash

Part Number: AM6548

Tool/software: Linux

Hi TI,

I encountered the following error when boot from opsi flash(MMC0), So I can't access SD card(MMC1).

MMC: sdhci@0: 0, sdhci@0: 1
sdhci_send_command: MMC: 1 busy timeout increasing to: 200 ms.
sdhci_send_command: MMC: 1 busy timeout increasing to: 400 ms.
sdhci_send_command: MMC: 1 busy timeout increasing to: 800 ms.
sdhci_send_command: MMC: 1 busy timeout increasing to: 1600 ms.
sdhci_send_command: MMC: 1 busy timeout increasing to: 3200 ms.
sdhci_send_command: MMC: 1 busy timeout.

But it can work when I booted from SD card. Under this conditions, MMC0 and MMC1 both work good.

My setup:

AM6548 EVM board

Processor SDK 05_01_00_11

Thanks

BS

  • Hi user5772774,

    Could you please provide the whole boot up log (not just part of it)?

    Make sure you are following below user guide:

    software-dl.ti.com/.../Foundational_Components_U-Boot.html

    Regards,
    Pavel
  • I make a flash.bin with three files: tiboot3.bin and tispl.bin and u-boot.img, their order is "mtdparts=47040000.ospi.0:512k(ospi.tiboot3),2m(ospi.tispl),5m(ospi.u-boot),128k(ospi.env),-@8m(ospi.rootfs)", Then I burn spiflash.bin into the ospi flash. But I encountered the bellow problem when booted from ospi flash.

    The whole boot up log of u-boot as following:

    U-Boot SPL 2018.01-00444-g4b39a3d-dirty (Nov 05 2018 - 16:55:29)
    SYSFW ABI: 2.4 (firmware rev 0x0012 '18.8.2-v2018.08b (Curious Crow)')
    Trying to boot from SPI
    Starting ATF on ARM64 core...

    NOTICE:  BL31: v1.5(release):ti2018.03-rc1
    NOTICE:  BL31: Built : 02:55:53, Oct  6 2018
    I/TC:
    I/TC: OP-TEE version: 3.2.0-81-g48952f9-dev #1 Sat Oct  6 03:34:58 UTC 2018 aarch64
    I/TC: Initialized

    U-Boot SPL 2018.01-00444-g4b39a3d-dirty (Nov 05 2018 - 16:55:25)
    Trying to boot from SPI


    U-Boot 2018.01-00444-g4b39a3d-dirty (Nov 05 2018 - 16:55:25 +0800)

    Model: Texas Instruments AM654 Base Board
    I2C:   Error, wrong i2c adapter 0 max 0 possible
    ready
    DRAM:  4 GiB
    MMC:   sdhci@0: 0, sdhci@0: 1
    sdhci_send_command: MMC: 1 busy timeout increasing to: 200 ms.
    sdhci_send_command: MMC: 1 busy timeout increasing to: 400 ms.
    sdhci_send_command: MMC: 1 busy timeout increasing to: 800 ms.
    sdhci_send_command: MMC: 1 busy timeout increasing to: 1600 ms.
    sdhci_send_command: MMC: 1 busy timeout increasing to: 3200 ms.
    sdhci_send_command: MMC: 1 busy timeout.
    sdhci_send_command: MMC: 1 busy timeout.
    ** Bad device mmc 1 **
    Using default environment

    Error, wrong i2c adapter 0 max 0 possible
    In:    serial@2800000
    Out:   serial@2800000
    Err:   serial@2800000
    Net:
    Warning: cpsw_nuss@046000000 using MAC address from ROM
    eth0: cpsw_nuss@046000000
    Hit any key to stop autoboot:  0
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_send_command: MMC: 1 busy timeout.
    SD/MMC found on device 1
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_send_command: MMC: 1 busy timeout.
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_send_command: MMC: 1 busy timeout.
    ** Bad device mmc 1 **
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_send_command: MMC: 1 busy timeout.
    ** Bad device mmc 1 **
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_send_command: MMC: 1 busy timeout.
    ** Bad device mmc 1 **
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_send_command: MMC: 1 busy timeout.
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_send_command: MMC: 1 busy timeout.
    ** Bad device mmc 1 **
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_send_command: MMC: 1 busy timeout.
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_set_clock: Timeout to wait cmd & data inhibit
    sdhci_send_command: MMC: 1 busy timeout.
    ** Bad device mmc 1 **

     

  • Hi TI,

      Now I enable the macro 'CONFIG_ENV_IS_IN_SPI_FLASH=y' to save environment variable to spi flash (Previously it be saved in the SD card), I don't encounter above problem, bootloader can startup from spi flash then boot kernel and mount rootfs from SD card. so in this way, we can bypass the trap! but still don't find the root cause...

    The whole bootloader log as following:

    U-Boot SPL 2018.01-00446-g02efeaa (Nov 15 2018 - 10:19:59)
    SYSFW ABI: 2.4 (firmware rev 0x0012 '18.8.2-v2018.08b (Curious Crow)')
    Trying to boot from SPI
    Starting ATF on ARM64 core...

    NOTICE:  BL31: v1.5(release):ti2018.03-rc1
    NOTICE:  BL31: Built : 02:55:53, Oct  6 2018
    I/TC:
    I/TC: OP-TEE version: 3.2.0-81-g48952f9-dev #1 Sat Oct  6 03:34:58 UTC 2018 aarch64
    I/TC: Initialized

    U-Boot SPL 2018.01-00446-g02efeaa (Nov 15 2018 - 10:19:38)
    Trying to boot from SPI


    U-Boot 2018.01-00446-g02efeaa (Nov 15 2018 - 10:19:38 +0800)

    Model: Texas Instruments AM654 Base Board
    I2C:   Error, wrong i2c adapter 0 max 0 possible
    ready
    DRAM:  4 GiB
    MMC:   sdhci@0: 0, sdhci@0: 1
    SF: Detected mt35xu512g with page size 256 Bytes, erase size 128 KiB, total 64 MiB
    Error, wrong i2c adapter 0 max 0 possible
    In:    serial@2800000
    Out:   serial@2800000
    Err:   serial@2800000
    Net:   eth0: cpsw_nuss@046000000
    Hit any key to stop autoboot:  0

  • user5772774,

    On the failing case you have: u-boot, kernel and rootfs on OSPI Flash and boot env on SD card (MMC1), is that correct?

    On the good case you have: u-boot, boot env, kernel and rootfs on OSPI Flash, is that correct?

    How eMMC (MMC0) is involved in your use case, can you provide more details? We have some known issues related to eMMC/MMC0 timeout:

    software-dl.ti.com/.../Release_Specific_Release_Notes.html

    LCPD-13667 - mmc 0 timeout and env could not be saved to eMMC on one board (farm26)

    LCPD-13666 - Seeing mmc0 timeout errors on some boards

    LCPD-13371 - mmc0 enumeration commands timeout in kernel




    Regards,
    Pavel

  • If you have no more questions related to the subject, please close/verify/resolve this thread.

    Regards,
    Pavel