We have a custom platform built from Vivado 2017.2, u-boot-xlnx-v2017.2 and linux-xlnx-v2017.2.
Short version: Everything works fine when we run our platform on a PicoZed 7010 Rev B module, but when we switch to a Rev C the eMMC doesn't work (we're booting from an SD card, and it's the exact same SD card we boot from so there's no difference in the code which tries to use the eMMC device).
It's not just in Linux the eMMC doesn't work, u-boot complains:
sdhci@e0100000: 0 (SD)Card did not respond to voltage select!
(Just a minor note in case someone thinks this looks odd: I switched places on the SD card and the eMMC in u-boot because when we tried to boot without an SD card inserted it would refuse to move on and scan for the eMMC and I wanted to be able to inspect the eMMC from u-boot booted from the QSPI).
u-boot finds the SD card then gets "Card did not respond to voltage select!" when probing the eMMC. Linux states during startup:
mmc1: SDHCI controller on e0101000.sdhci [e0101000.sdhci] using DMA
I'm not sure if that's just the device-tree node or if it's actually probed the hardware, but no mmbblk1 device node is generated.
The eMMC does however work if I boot from the pre-installed Linux on the QSPI memory, so I know the hardware works.
My philosophy when I built the hardware platform was to use as much of the tool generated code/data as possible and not change things manually unless there's a very good reason to. Specifically: I generated the Linux device tree from the hdf, and I built the hw platform from the latest Avnet PicoZed 7010 (+FMC1) board definition files, and almost everything is as the tools' default output.
What we've discovered when searching the 'net for the problem:
This seemed highly relevant, because "Rev C" and "eMMC problems". However, when I searched around some more about this issue I've seen others describe the behavior as more "flaky"; the eMMC would work but there would be read errors etc. In our case it seems almost completely dead (and yes, I tried running it for a while to "warm it up" but I could never get it to use the eMMC).
What I've tried (but which didn't change anything):
- Hoping this was merely fixable by device-tree tweaks I tried dumping the device tree from the pre-built system (which works) and replicated the device-tree as close as I could.
- I tried adding "broken-mmc-highspeed" to the eMMC's sdhci node in the device tree, because that seemed relevant to the AR#59999 issue.
Help? The Product Change Notification clearly states that things changed with Rev C with regards to the eMMC, but I can't translate that into any change I would need to perform in our platform to make eMMC work on Rev C modules.
