Actions
Forum Thread Details
  • State Suggested Answer
  • Replies 3 replies
  • Answers 2 answers
  • Subscribers 347 subscribers
  • Views 1148 views
  • Users 0 members are here
Related

UltraZed-EV **Bad device mmc 1**

gard1302

Hello,

I'm trying to use an UltraZed-EV SOM with a custom carrier card. When I try to boot from and SD card on my custom carrier card, I get messages saying MMC 1 busy timeout, and Bad device mmc 1 as shown below:

 

First Stage Boot Loader

Release 2018.3   Jul  6 2019  -  00:58:16

NOTICE:  ATF running on XCZU7EG/EV/silicon v4/RTL5.1 at 0xfffea000

NOTICE:  BL31: Secure code at 0x0

NOTICE:  BL31: Non secure code at 0x8000000

NOTICE:  BL31: v1.5(release):xilinx-v2018.2-919-g08560c36

NOTICE:  BL31: Built : 00:55:05, Jul  6 2019

PMUFW:  v1.1

 

U-Boot 2018.01 (Jul 06 2019 - 00:56:37 +0000) Xilinx ZynqMP ZCU102 rev1.0

 

I2C:   ready

DRAM:  4 GiB

EL Level:       EL2

Chip ID:        zu7

MMC:   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.

mmc_init: -70, time 7439

mmc@ff170000 - probe failed: -70

mmc@ff160000: 0 (eMMC)sdhci_send_command: MMC: 1 busy timeout.

sdhci_send_command: MMC: 1 busy timeout.

mmc_init: -70, time 7413

 

SF: Detected n25q256a with page size 512 Bytes, erase size 128 KiB, total 64 MiB

*** Warning - bad CRC, using default environment

 

In:    serial@ff000000

Out:   serial@ff000000

Err:   serial@ff000000

Board: Xilinx ZynqMP

Bootmode: SD_MODE1

Net:   ZYNQ GEM: ff0e0000, phyaddr 0, interface rgmii-id

eth0: ethernet@ff0e0000

U-BOOT for lrf_window_test

 

ethernet@ff0e0000 Waiting for PHY auto negotiation to complete....... done

BOOTP broadcast 1

BOOTP broadcast 2

DHCP client bound to address 10.2.118.221 (257 ms)

Hit any key to stop autoboot:  0

sdhci_send_command: MMC: 1 busy timeout.

sdhci_send_command: MMC: 1 busy timeout.

mmc_init: -70, time 7413

** Bad device mmc 1 **

Device: mmc@ff160000

Manufacturer ID: 13

OEM: 14e

Name: Q2J55

Tran Speed: 200000000

Rd Block Len: 512

MMC version 5.0

High Capacity: Yes

Capacity: 7.1 GiB

Bus Width: 4-bit

Erase Group Size: 512 KiB

HC WP Group Size: 8 MiB

User Capacity: 7.1 GiB WRREL

Boot Capacity: 16 MiB ENH

RPMB Capacity: 4 MiB ENH

sdhci_send_command: MMC: 1 busy timeout.

sdhci_send_command: MMC: 1 busy timeout.

mmc_init: -70, time 7413

** Bad device mmc 1 **

ZynqMP>

 

Has anyone else run into similar problems? Any ideas for solutions?

Parents
  • 0

    Hi there,

     

    Are you able to validate your software / hardware by using the out of box design, or an Avnet Carrier Card?  You just have to be careful about any IO/etc. that might become damaged at the wrong configuration.

    If possible, that might help you locate the issue (be it hardware layout, configuration for the SDIO controller, other).

     

    You might also cut the speed of the clock for the eMMC, just to check that aspect (although probably easier to just use the provided OOB files if you can).

     

    --Dan

  • 0 in reply to drozwood90

    So I rechecked the schematics for Avnet's carrier card, and I realized there were a few pins that I hadn't routed correctly. Here's a picture of Avnet's schematic for their SD card connector.image

    I used the same part (5025700893), but I hadn't routed G4 (DET) or G3 (POL). After doing some hacks on my board and getting those pins connected correctly on my custom carrier card, the boot sequence worked just fine. Any idea why that is?

     

    Mick

  • 0 in reply to gard1302

    Mick,

     

    First, I'm glad you figured that out!  Boot issues can be really tricky to track down.

     

    It is likely that those pins are feedback to the drivers.  Typically, I've seen those kinds of things timeout if a toggle or something similar does not happen.  What I recall from a previous experience with something like this - the driver sits there waiting for the pin to establish that the SDCARD is inserted.  Without that, the driver might be "hung" waiting - eventually timing out - assuming that the SDCARD is never inserted.  I do not recall the function of the POL pin.

     

    I do know that it can be worked around in JUST software, but I would NOT recommend that as you end up polling for activity instead of just being aware of the memory's presence.  I do believe that IS part of the standard (to poll for presence).  However, due to how the driver is provided, you would probably run into longer term maintenance issues with software as I suspect you would then not be following mainline.

     

    As this is not really a signal integrity based pin, but just logic, I'd suggest modifying boards as you did to start development work for your team.  Then, ensure the proper changes are in place for your second spin of prototypes, or even for your first articles.

     

    --Dan

Reply
  • 0 in reply to gard1302

    Mick,

     

    First, I'm glad you figured that out!  Boot issues can be really tricky to track down.

     

    It is likely that those pins are feedback to the drivers.  Typically, I've seen those kinds of things timeout if a toggle or something similar does not happen.  What I recall from a previous experience with something like this - the driver sits there waiting for the pin to establish that the SDCARD is inserted.  Without that, the driver might be "hung" waiting - eventually timing out - assuming that the SDCARD is never inserted.  I do not recall the function of the POL pin.

     

    I do know that it can be worked around in JUST software, but I would NOT recommend that as you end up polling for activity instead of just being aware of the memory's presence.  I do believe that IS part of the standard (to poll for presence).  However, due to how the driver is provided, you would probably run into longer term maintenance issues with software as I suspect you would then not be following mainline.

     

    As this is not really a signal integrity based pin, but just logic, I'd suggest modifying boards as you did to start development work for your team.  Then, ensure the proper changes are in place for your second spin of prototypes, or even for your first articles.

     

    --Dan

Children
No Data