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.

AM437x Custom Board failing at [ 2.460489] Waiting for root device /dev/mmcblk0p2...

Other Parts Discussed in Thread: AM4378

We're using an AM437x processor on a custom board, and our U-boot is getting stuck at the following line:

[    2.460489] Waiting for root device /dev/mmcblk0p2...

Since this was not happening on our other dev boards, we investigated any hardware changes made to the uSD card connector.  The only major difference is that our new connector does not have a card detection and our MPU pin R25 is pulled up to 3.3V.  

This U-BOOT patch from 2011 http://lists.denx.de/pipermail/u-boot/2011-December/112202.html states that the MMC_getcd() function is no longer used and it will always return -1 which mean the card detection mechanism is no longer implemented in u-boot.  This was the latest update we saw based on our research that pertains to the card detection function.  Although these findings imply that our hardware change to the card detect is not the culprit, we do see that there are many responses still implying that the problem lies somewhere with this card detect signal.

Is there any solution to this problem?

Thanks,

Trent

  • Hi Trent,

    I will forward this to the SW team. Could you attach the entire log file?

  • Hi Trent,

    If you see this message the SPI(MLO), u-boot and part of the kernel are loaded from sd-card this mean that sd-card work well. This command point kernel where to look for file systems. Please check if the file systems is in this partition and if this partition is not broken. Do you formatted sd-card with a available script or yourself, because the sd-card must be formatted as explain in documentation.

    BR
    Ivan
  • Hey Biser/Ivan,

    I looked through our log file and it definitely appears that the MPU is booting at least SPL and u-boot from MMC0 (which is what our SD card is connected to). I'm not sure what the exact message is that I should be looking for, but I have attached the entire log file for assistance. I formatted this sd card with the bin/create-sdcard.sh script that comes with the AM437x ti-sdk, which I have been using the entire time and has never failed on me. We did notice that it might be because the MPU was trying to load from an EXT4 filesystem while the create-sdcard.sh script was creating a EXT3 partition, so we already tried changing that partition in the sd card to be EXT4 but I got the same exact results.

    G��@uiP#XDY�BWJbZjmZ%�eZ.bB�XhXf vP�jY�H]ddA�YR�W�XIP�IPI
    S]G�ZB\DԵYR�W�S�W�IP��SPL: Please implement spl_start_uboot() for your board
    SPL: Direct Linux boot not active!
    reading u-boot.img
    reading u-boot.img


    U-Boot 2013.10-g586fef6-dirty (Feb 02 2015 - 13:37:29)

    I2C: ready
    DRAM: 1 GiB
    NAND: 0 MiB
    MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
    *** Error - No Valid Environment Area found
    *** Warning - bad CRC, using default environment

    Could not probe the EEPROM at 0x50
    Could not get board ID.
    Net: <ethaddr> not set. Validating first E-fuse MAC
    Could not get PHY for cpsw: addr 0
    cpsw
    Hit any key to stop autoboot: 3 2 1 0
    (Re)start USB...
    USB0: Register 2000440 NbrPorts 2
    Starting the controller
    USB XHCI 1.00
    scanning bus 0 for devices... 1 USB Device(s) found
    scanning usb for storage devices... 0 Storage Device(s) found

    USB device 0: unknown device
    mmc0 is current device
    Scanning mmc 0...
    4112136 bytes read in 237 ms (16.5 MiB/s)
    46592 bytes read in 15 ms (3 MiB/s)
    mmc0 is current device
    SD/MMC found on device 0
    reading uEnv.txt
    ** Unable to read file uEnv.txt **
    4112136 bytes read in 236 ms (16.6 MiB/s)
    46592 bytes read in 14 ms (3.2 MiB/s)
    Booting from mmc0 ...
    Kernel image @ 0x80200000 [ 0x000000 - 0x3ebf08 ]
    ## Flattened Device Tree blob at 80f80000
    Booting using the fdt blob at 0x80f80000
    Loading Device Tree to 9fff1000, end 9ffff5ff ... OK

    Starting kernel ...

    [ 0.000000] Booting Linux on physical CPU 0x0
    [ 0.000000] Linux version 3.12.10-gded175e-dirty (rufuslabs@RufusLabsAcer) (gcc version 4.7.3 20130226 (prerelease) (crosstool-NG linaro-1.13.1-4.7-2013.03-20130313 - Linaro GCC 2013.03) ) #2 Fri Jan 30 15:04:57 PST 2015
    [ 0.000000] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d
    [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
    [ 0.000000] Machine: Generic AM43 (Flattened Device Tree), model: TI AM437x gp EVM
    [ 0.000000] cma: CMA: reserved 24 MiB at ae000000
    [ 0.000000] Memory policy: ECC disabled, Data cache writeback
    [ 0.000000] CPU: All CPU(s) started in SVC mode.
    [ 0.000000] AM437x ES1.0 (sgx neon )
    [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 259856
    [ 0.000000] Kernel command line: console=ttyO0,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait
    [ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
    [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
    [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
    [ 0.000000] Memory: 1003124K/1045504K available (5551K kernel code, 558K rwdata, 1872K rodata, 345K init, 225K bss, 42380K reserved, 267264K highmem)
    [ 0.000000] Virtual kernel memory layout:
    [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
    [ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
    [ 0.000000] vmalloc : 0xf0000000 - 0xff000000 ( 240 MB)
    [ 0.000000] lowmem : 0xc0000000 - 0xef800000 ( 760 MB)
    [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
    [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
    [ 0.000000] .text : 0xc0008000 - 0xc074804c (7425 kB)
    [ 0.000000] .init : 0xc0749000 - 0xc079f528 ( 346 kB)
    [ 0.000000] .data : 0xc07a0000 - 0xc082b958 ( 559 kB)
    [ 0.000000] .bss : 0xc082b958 - 0xc0863f80 ( 226 kB)
    [ 0.000000] NR_IRQS:16 nr_irqs:16 16
    [ 0.000000] GIC CPU mask not found - kernel will fail to boot.
    [ 0.000000] GIC CPU mask not found - kernel will fail to boot.
    [ 0.000000] OMAP clockevent source: timer2 at 19200000 Hz
    [ 0.000000] sched_clock: 32 bits at 19MHz, resolution 52ns, wraps every 223696ms
    [ 0.000000] OMAP clocksource: timer1 at 19200000 Hz
    [ 0.000000] Console: colour dummy device 80x30
    [ 0.000486] Calibrating delay loop... 479.23 BogoMIPS (lpj=2396160)
    [ 0.119506] pid_max: default: 32768 minimum: 301
    [ 0.119674] Security Framework initialized
    [ 0.119769] Mount-cache hash table entries: 512
    [ 0.131192] CPU: Testing write buffer coherency: ok
    [ 0.131776] Setting up static identity map for 0xc05716a8 - 0xc0571718
    [ 0.131940] L310 cache controller enabled
    [ 0.131972] l2x0: 16 ways, CACHE_ID 0x410000c9, AUX_CTRL 0x7e030000, Cache size: 256 kB
    [ 0.132992] devtmpfs: initialized
    [ 0.137259] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
    [ 0.207510] omap_hwmod: dss_dispc: cannot be enabled for reset (3)
    [ 0.211101] omap_hwmod: dss_rfbi: cannot be enabled for reset (3)
    [ 0.211931] pinctrl core: initialized pinctrl subsystem
    [ 0.213035] regulator-dummy: no parameters
    [ 0.215790] NET: Registered protocol family 16
    [ 0.219117] DMA: preallocated 256 KiB pool for atomic coherent allocations
    [ 0.222685] cpuidle: using governor ladder
    [ 0.222702] cpuidle: using governor menu
    [ 0.239515] L3 debug error: target 13 clkdm 1 (unclearable)
    [ 0.239569] L3 application error: target 13 clkdm 1 (unclearable)
    [ 0.239891] platform 49000000.edma: FIXME: clock-name 'fck' DOES NOT exist in dt!
    [ 0.241653] platform 44e3e000.rtc: Cannot lookup hwmod 'rtc'
    [ 0.243748] OMAP GPIO hardware version 0.1
    [ 0.257686] platform 56000000.sgx: FIXME: clock-name 'fck' DOES NOT exist in dt!
    [ 0.260305] platform ocp2scp.0: FIXME: clock-name 'fck' DOES NOT exist in dt!
    [ 0.260722] platform ocp2scp.1: FIXME: clock-name 'fck' DOES NOT exist in dt!
    [ 0.261176] platform 48380000.omap_dwc3_1: FIXME: clock-name 'fck' DOES NOT exist in dt!
    [ 0.261616] platform 483c0000.omap_dwc3_2: FIXME: clock-name 'fck' DOES NOT exist in dt!
    [ 0.262019] platform 4832a000.dss: FIXME: clock-name 'fck' DOES NOT exist in dt!
    [ 0.262450] platform 4832a400.dispc: FIXME: clock-name 'fck' DOES NOT exist in dt!
    [ 0.263150] platform 4832a800.rfbi: FIXME: clock-name 'fck' DOES NOT exist in dt!
    [ 0.267649] No ATAGs?
    [ 0.267683] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers.
    [ 0.267698] hw-breakpoint: maximum watchpoint size is 4 bytes.
    [ 0.302414] bio: create slab <bio-0> at 0
    [ 0.323877] edma-dma-engine edma-dma-engine.0: TI EDMA DMA engine driver
    [ 0.325194] vmmcsd_fixed: 3300 mV
    [ 0.325726] evm_v3p3: 3300 mV
    [ 0.330936] vgaarb: loaded
    [ 0.332616] SCSI subsystem initialized
    [ 0.334486] usbcore: registered new interface driver usbfs
    [ 0.334762] usbcore: registered new interface driver hub
    [ 0.335040] usbcore: registered new device driver usb
    [ 0.336461] omap_i2c 44e0b000.i2c: could not find pctldev for node /pinmux@44e10800/pinmux_i2c0_pins, deferring probe
    [ 0.336499] platform 44e0b000.i2c: Driver omap_i2c requests probe deferral
    [ 0.336537] omap_i2c 4802a000.i2c: could not find pctldev for node /pinmux@44e10800/i2c1_pins, deferring probe
    [ 0.336559] platform 4802a000.i2c: Driver omap_i2c requests probe deferral
    [ 0.336591] omap_i2c 4819c000.i2c: could not find pctldev for node /pinmux@44e10800/i2c2_pins, deferring probe
    [ 0.336613] platform 4819c000.i2c: Driver omap_i2c requests probe deferral
    [ 0.336990] media: Linux media interface: v0.10
    [ 0.337237] Linux video capture interface: v2.00
    [ 0.337628] pps_core: LinuxPPS API ver. 1 registered
    [ 0.337643] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
    [ 0.337828] PTP clock support registered
    [ 0.341388] Switched to clocksource timer1
    [ 0.367648] NET: Registered protocol family 2
    [ 0.368438] TCP established hash table entries: 8192 (order: 4, 65536 bytes)
    [ 0.368667] TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
    [ 0.368799] TCP: Hash tables configured (established 8192 bind 8192)
    [ 0.368974] TCP: reno registered
    [ 0.368994] UDP hash table entries: 512 (order: 1, 8192 bytes)
    [ 0.369035] UDP-Lite hash table entries: 512 (order: 1, 8192 bytes)
    [ 0.369334] NET: Registered protocol family 1
    [ 0.369832] RPC: Registered named UNIX socket transport module.
    [ 0.369849] RPC: Registered udp transport module.
    [ 0.369859] RPC: Registered tcp transport module.
    [ 0.369868] RPC: Registered tcp NFSv4.1 backchannel transport module.
    [ 0.371058] NetWinder Floating Point Emulator V0.97 (double precision)
    [ 0.372125] PM: Loading am335x-pm-firmware.binbounce pool size: 64 pages
    [ 0.569030] VFS: Disk quotas dquot_6.5.2
    [ 0.569109] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
    [ 0.569832] NFS: Registering the id_resolver key type
    [ 0.569911] Key type id_resolver registered
    [ 0.569924] Key type id_legacy registered
    [ 0.569979] jffs2: version 2.2. (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc.
    [ 0.570225] msgmni has been set to 1485
    [ 0.572523] NET: Registered protocol family 38
    [ 0.572580] io scheduler noop registered
    [ 0.572592] io scheduler deadline registered
    [ 0.572622] io scheduler cfq registered (default)
    [ 0.573608] omap-ocp2scp ocp2scp.0: invalid resource
    [ 0.573651] omap-ocp2scp: probe of ocp2scp.0 failed with error -22
    [ 0.574267] omap-ocp2scp ocp2scp.1: invalid resource
    [ 0.574300] omap-ocp2scp: probe of ocp2scp.1 failed with error -22
    [ 0.578470] pinctrl-single 44e10800.pinmux: 199 pins at pa f9e10800 size 796
    [ 0.587693] OMAP DSS rev 2.0
    [ 0.612117] Console: switching to colour frame buffer device 100x30
    [ 0.627748] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
    [ 0.631110] omap_uart 44e09000.serial: No clock speed specified: using default:48000000
    [ 0.631537] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 104, base_baud = 3000000) is a OMAP UART0
    [ 1.598816] console [ttyO0] enabled
    [ 1.605538] omap_rng 48310000.rng: OMAP Random Number Generator ver. 20
    [ 1.628096] brd: module loaded
    [ 1.639446] loop: module loaded
    [ 1.650083] mtdoops: mtd device (mtddev=name/number) must be supplied
    [ 1.664746] usbcore: registered new interface driver asix
    [ 1.672262] usbcore: registered new interface driver ax88179_178a
    [ 1.680616] usbcore: registered new interface driver cdc_ether
    [ 1.688576] usbcore: registered new interface driver r815x
    [ 1.696132] usbcore: registered new interface driver smsc95xx
    [ 1.704015] usbcore: registered new interface driver net1080
    [ 1.711772] usbcore: registered new interface driver cdc_subset
    [ 1.719870] usbcore: registered new interface driver zaurus
    [ 1.727542] usbcore: registered new interface driver cdc_ncm
    [ 1.735805] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
    [ 1.744509] ehci-pci: EHCI PCI platform driver
    [ 1.750681] ehci-omap: OMAP-EHCI Host Controller driver
    [ 1.759087] usbcore: registered new interface driver cdc_wdm
    [ 1.766924] usbcore: registered new interface driver usb-storage
    [ 1.776573] mousedev: PS/2 mouse device common for all mice
    [ 1.785634] input: matrix_keypad.8 as /devices/matrix_keypad.8/input/input0
    [ 1.799019] omap_rtc 44e3e000.rtc: rtc core: registered 44e3e000.rtc as rtc0
    [ 1.809880] i2c /dev entries driver
    [ 1.815733] vpfe-capture 48326000.vpfe: v4l2 device registered
    [ 1.823596] vpfe-capture 48326000.vpfe: Asynchronous subdevice registration
    [ 1.832933] vpfe-capture 48326000.vpfe: AM437x ISIF is registered with vpfe.
    [ 1.843019] vpfe-capture 48328000.vpfe: v4l2 device registered
    [ 1.850768] vpfe-capture 48328000.vpfe: Asynchronous subdevice registration
    [ 1.860168] vpfe-capture 48328000.vpfe: AM437x ISIF is registered with vpfe.
    [ 1.869850] Driver for 1-wire Dallas network protocol.
    [ 1.880296] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec
    [ 1.892456] edma-dma-engine edma-dma-engine.0: allocated channel for 0:25
    [ 1.901666] edma-dma-engine edma-dma-engine.0: allocated channel for 0:24
    [ 1.951965] edma-dma-engine edma-dma-engine.0: allocated channel for 0:3
    [ 1.960874] edma-dma-engine edma-dma-engine.0: allocated channel for 0:2
    [ 2.015785] ledtrig-cpu: registered to indicate activity on CPUs
    [ 2.024457] edma-dma-engine edma-dma-engine.0: allocated channel for 0:36
    [ 2.033630] omap-sham 53100000.sham: hw accel on OMAP rev 0.0
    [ 2.045264] omap-aes 53501000.aes: OMAP AES hw accel rev: 0.1
    [ 2.053112] edma-dma-engine edma-dma-engine.0: allocated channel for 0:5
    [ 2.062138] edma-dma-engine edma-dma-engine.0: allocated channel for 0:6
    [ 2.072264] omap-des 53701000.des: OMAP DES hw accel rev: 0.33
    [ 2.080074] edma-dma-engine edma-dma-engine.0: allocated channel for 0:33
    [ 2.089243] edma-dma-engine edma-dma-engine.0: allocated channel for 0:34
    [ 2.099996] usbcore: registered new interface driver usbhid
    [ 2.107444] usbhid: USB HID core driver
    [ 2.116267] oprofile: no performance counters
    [ 2.122699] oprofile: using timer interrupt.
    [ 2.128753] TCP: cubic registered
    [ 2.133205] Initializing XFRM netlink socket
    [ 2.138972] NET: Registered protocol family 17
    [ 2.145014] NET: Registered protocol family 15
    [ 2.150977] 8021q: 802.1Q VLAN Support v1.8
    [ 2.156634] Key type dns_resolver registered
    [ 2.163148] cpu cpu0: cpu0 regulator not ready, retry
    [ 2.169872] platform cpufreq-cpu0.0: Driver cpufreq-cpu0 requests probe deferral
    [ 2.180580] ThumbEE CPU extension supported.
    [ 2.195351] vdd_core: 920 <--> 1140 mV at 1100 mV
    [ 2.204992] vdd_mpu: 920 <--> 1375 mV at 1100 mV
    [ 2.213311] DCDC3: at 1500 mV
    [ 2.221553] LDO1: 1800 mV
    [ 2.226458] omap_i2c 44e0b000.i2c: bus 0 rev0.12 at 100 kHz
    [ 2.237994] omap_i2c 4802a000.i2c: bus 1 rev0.12 at 100 kHz
    [ 2.245881] pinctrl-single 44e10800.pinmux: pin 44e10a38.0 already requested by encoder.2; cannot claim for 4819c000.i2c
    [ 2.260348] pinctrl-single 44e10800.pinmux: pin-142 (4819c000.i2c) status -22
    [ 2.269855] pinctrl-single 44e10800.pinmux: could not request pin 142 (44e10a38.0) from group i2c2_pins on device pinctrl-single
    [ 2.285331] omap_i2c 4819c000.i2c: Error applying setting, reverse things back
    [ 2.296875] omap_i2c 4819c000.i2c: bus 2 rev0.12 at 100 kHz
    [ 2.305479] cpufreq_cpu0: Bootloader freq 480000000Hz no match to table, Using 300000000Hz
    [ 2.391445] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
    [ 2.399522] davinci_mdio 4a101000.mdio: no live phy, scanning all
    [ 2.408042] davinci_mdio: probe of 4a101000.mdio failed with error -5
    [ 2.417552] Detected MACID = 34:b1:f7:36:2a:c9
    [ 2.445358] omap_rtc 44e3e000.rtc: setting system clock to 2000-01-01 00:00:00 UTC (946684800)
    [ 2.460489] Waiting for root device /dev/mmcblk0p2...
    [ 60.482040] PM: request_firmware failed
  • Hi Trent, I checked during uboot and the kernel, and the signal for Card Detect is not even being enabled in the pinmux, so definitely uboot/kernel are not using this signal. Does this occur across multiple SD cards and/or multiple boards? As Ivan says, I would double check your formatting of the card (rerun the script or use different card). I know i've gotten stuck in the past at the same point because of badly formatted card or an incorrect filesystem.

    Regards,
    James
  • Hey James,

    This problem does occur across multiple SD cards. We only have one board in house to test on, but we also tried making the sd card on a completely different machine and the same problem occurred. I just checked and the create-sdcard.sh file is identical to the ti-sdk standard, and it has never failed us before. The boot and rootfs folders are in the sd card and the partitions look identical to a card that was definitely working on our other dev boards.

    Any ideas on where else the problem might lie?

    Thanks,
    Trent
  • Trent, can you send us the MMC/SD portion of the schematic, from AM437x out to the card?

    Thanks,
    James
  • Hi James,

    The problem is not from card detect signal. From listed log I saw too many errors. For examples:
    [ 0.000000] GIC CPU mask not found - kernel will fail to boot.
    [ 0.000000] GIC CPU mask not found - kernel will fail to boot.

    Also in a u-boot I saw that looking for USB device. Next u-boot find sd-card and continue reading from there. Any way it read kernel and start it. At the end of log the kernel has to initialize mmc device, but this is missing. See on my side what is it:

    [ 2.300610] mmc1: new high speed SD card at address b368
    [ 2.306909] mmcblk0: mmc1:b368 SD 1.88 GiB
    [ 2.326087] mmcblk0: p1 p2

    I think that your mmc driver not work properly. Here kernel has to load file system, but it can't find the device and hang up. Also please see the boot pins.

    BR
    Ivan
  • Hi Trent, thanks for the schematic. A few things to try and some questions:

    -What is the approximate distance from AM437x to the card cage?
    -The is a note in the schematic to place the series resistors close to AM437x. Can you confirm that this is true, especially for MMC_CLK?
    -Really the only series resistor needed is for MMC_CLK. Keep the 33ohm on MMC_CLK and replace the others with 0ohm. Also, remove the pullup on MMC_CLK. This will get us closer to the EVM schematic which we haven't had any issues with.

    Regards,
    James
  • THanks Ivan, i didn't check the log in detail.

    Trent, aside from the h/w fixes, can you look into these errors. Maybe compare it to a log from a working board. Are you getting these same errors on a working board?

    Regards,
    James
  • Hey Ivan/James,

    Thanks for the input.  I am looking into the software errors right now.   All of this makes sense because our older boards that booted linux had eMMC installed on the  GPMC pins.  But then we removed the eMMC and decided to utilize the sd card as a boot device AND general purpose for the end user.  I am currently having problems trying to upload a screenshot of our old eMMC interface but I can show you below which pins were connected to what:

    AM4378 B5/A5/B6/A6/B7/A7/C8/B8<-> eMMC DAT0-7

    AM4378 B9 -> 22Ohm Resistor -> eMMC CLK

    AM4378 F10 -> 10K pullup to 3.3V -> eMMC CMD

    Like I stated before these pins are no longer connected to anything on the new boards that are having problems.

    I have already made the following changes to board/ti/am43xx/mux.c to disable the MMC1 muxing for our older boards.

     

    Thanks,

    Trent

  • Trent, what does the device tree look like for MMC0? It should be a copy of what we have in our SDK. I don't think what you removed will have an effect on operation of MMC0.

    Regards,
    James
  • Never used this processor. Some guesses.
    - The u-boot MMC driver does not care about the CD pin. Your hang is occurring in the Linux side.
    - The pinmux config source code appears to be for u-boot. Linux will do it's own mux settings.
    - The linux MMC driver for this processor requires CD and WP pins.
    - The CD and WP pins not optional as it is in other MMC drivers.
    - The MMC driver uses GPIO pins for CD and WP. It does not use the CD and WP pins on the MMC peripheral.
    - The CD and WP pins are assumed active low. Your schematic ties R25 high. It should be tied low for always detected.
    - The GPIO for CD and WP are defined in the device-tree. Using the am335x device tree as a basis, your device tree should have something like this:

    am43xx_pinmux: pinmux@44e10800 {
    mmc1_pins: pinmux_mmc1_pins {
    pinctrl-single,pins = <
    0x160 (PIN_INPUT | MUX_MODE7) /* spi0_cs1.gpio0_6 */
    >;
    };
    };
    ...
    &mmc1 {
    status = "okay";
    ...
    pinctrl-names = "default";
    pinctrl-0 = <&mmc1_pins>;
    cd-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
    };
  • Norman,

    Is there anyway to change the software so the processor assumes the CD pin is active high?  In other words, is there any way to fix our problem without making any hardware changes?

    And our device tree does have the same piece of code that you quoted, which is puzzling because shouldn't gpio 0 6 be set to active low since the CD pin is assumed active low by the processor?

    Thanks,

    Trent

  • Some of the other MMC drivers allow a invalid GPIO number to suggect that CD is always true and WP is always false. Other MMS drivers have callbacks such that the board file defines the behaviour. In this case, the device tree assumes that there is always a GPIO and that that GPIO is defined using the descriptor model. Even if your MMC driver supported it, I would have not idea on how to define an invalid GPIO number in the device tree. I think you struck with modifying the kernel. I think your driver is drivers/mmc/host/omap_hsmmc.c.

    static int omap_hsmmc_card_detect(struct device *dev, int slot)
    {
      struct omap_hsmmc_host *host = dev_get_drvdata(dev);
      struct omap_mmc_platform_data *mmc = host->pdata;
      /* NOTE: assumes card detect signal is active-low */
      return !gpio_get_value_cansleep(mmc->slots[0].switch_pin);
    
    }
    
    static int omap_hsmmc_get_wp(struct device *dev, int slot)
    {
      struct omap_hsmmc_host *host = dev_get_drvdata(dev);
      struct omap_mmc_platform_data *mmc = host->pdata;
      /* NOTE: assumes write protect signal is active-high */
      return gpio_get_value_cansleep(mmc->slots[0].gpio_wp);
    
    }
    
    static int omap_hsmmc_get_cover_state(struct device *dev, int slot)
    
    {
      struct omap_hsmmc_host *host = dev_get_drvdata(dev);
      struct omap_mmc_platform_data *mmc = host->pdata;
      /* NOTE: assumes card detect signal is active-low */
      return !gpio_get_value_cansleep(mmc->slots[0].switch_pin);
    
    }

    Note the above code assumes that the GPIO logical and physical level is the same, ie 0=low, 1=high. The code then inverts it as needed. If you want to fool the MMC core driver that your card is always there and writable. You need to stub out these functions:

    static int omap_hsmmc_get_cd(struct mmc_host *mmc)
    {
      struct omap_hsmmc_host *host = mmc_priv(mmc);
      if (!mmc_slot(host).card_detect)
        return -ENOSYS;
      return mmc_slot(host).card_detect(host->dev, host->slot_id);
    }
    
    static int omap_hsmmc_get_ro(struct mmc_host *mmc)
    {
      struct omap_hsmmc_host *host = mmc_priv(mmc);
      if (!mmc_slot(host).get_ro)
        return -ENOSYS;
      return mmc_slot(host).get_ro(host->dev, 0);
    }

    to

    static int omap_hsmmc_get_cd(struct mmc_host *mmc)
    {
      return 0;
    }
    
    static int omap_hsmmc_get_ro(struct mmc_host *mmc)
    {
      return 0;
    }

    You might get problems with the rest of the omap_hsmmc.c code as it seems to really depend on those GPIOs.

  • I changed the following:

    index a2dd101..ce30a6d 100644
    --- a/drivers/mmc/host/omap_hsmmc.c
    +++ b/drivers/mmc/host/omap_hsmmc.c
    @@ -1735,11 +1735,7 @@ end_ios:
     
     static int omap_hsmmc_get_cd(struct mmc_host *mmc)
     {
    -       struct omap_hsmmc_host *host = mmc_priv(mmc);
    -
    -       if (!mmc_slot(host).card_detect)
    -               return -ENOSYS;
    -       return mmc_slot(host).card_detect(host->dev, host->slot_id);
    +    return 1;
     }

    This was the only change that was required to get the linux to boot up fully.  Thanks to everyone for the assistance.

  • Hi Trent,

    After some consultation with my colleagues, we found that the device tree properties can handle your situation where a CD signal is not present. 

    Try removing the edits you did to the kernel driver and use the "broken-cd" in the device tree bindings for MMC0.  It will look something like below.  You just have to add broken-cd to what you have, and remove any reference to the CD signal.  The other lines shown are just an example, which you may or may not have:

    &mmc0 {
        status = "okay";
        vmmc-supply = <&vmmc_reg>;
        bus-width = <4>;
        pinctrl-names = "default", "sleep";
        pinctrl-0 = <&mmc1_pins_default>;
        pinctrl-1 = <&mmc1_pins_sleep>;
        broken-cd;
    };

    Some more information can be found here:  lxr.free-electrons.com/.../mmc.txt

    By doing this, it looks like the driver will use a polling mechanism to determine if the card is present.  This will be much more robust than trying to fake out the driver with the signal pulled low or forcing a return value in the code. 

    Let me know if you have other questions.

    Regards,

    James 

  • I'm still catching up on this device tree stuff. Much more used to board files. From what I see, I think the "broken-cd" enables CPIO polling of the CD pin instead of a GPIO interrupt on the CD pin. The GPIO pin for CD is still required. I am guessing the "non-removable" property might be a better choice. Looks like the associated MMC_CAP_NONREMOVABLE host cap flag is available for platform devices in those board files.
  • James,

    Thank you for your assistance.  I have one final question.  If we ground the card detect input signal instead of pulling it up, can we discard the software changes we made (i.e. broken-cd)?  Will everything work as expected if we just make the following change in the schematic?  I want to fix this problem the right way.

    Thanks,

    Trent

  • Hi Trent, I think both will work, but I believe the "better" way is to use broken-cd. I would test out the use of broken-cd to make sure it works as expected, but from the description, the use of this best describes your situation to the driver (ie, you don't have a CD signal)

    A couple of scenarios which i thought of:
    -keeping the CD signal grounded and removing the software changes will make the driver assume the card is always present. This will keep clocks and power (if separately enabled) always on. If your application is power sensitive, you will take a slight hit.
    -you may want to test the scenario where writes or reads are occurring on the SD card while the card is removed. With the signal grounded, the driver will probably hang since it expects the card to be there. Possibly using broken-cd, it may be able to gracefully abort the accesses (again, i would test this to ensure the descriptions matches my assumptions).

    So really both scenarios will work normally, it is just these exceptions which i'm trying to account for.

    Regards,
    James
  • Hey James,

    Using the broken-cd does seem like the better way to solve this for booting uboot and linux. Do you foresee any potential problems we could run into when trying to load Android? And since we aren't using R25 (the MPU Card Detect pin), can we just leave it hanging?

    Thanks,
    Trent