Met vriendelijke groet / kind regards, Mike Looijmans System Expert
TOPIC Embedded Products B.V. Materiaalweg 4, 5681 RJ Best The Netherlands T: +31 (0) 499 33 69 69 E: [email protected] W: www.topicproducts.com Please consider the environment before printing this e-mail On 08-01-2020 03:04, Jean-Francois Dagenais via Lists.Yoctoproject.Org wrote: > Hi all, > > This question might be better suited for actual xilinx forums, but I like this > crowd here a lot... so here goes. > > We've been having intermittent SD (SDHCI1) problems over the last 2 years as > we > have moved along the xilinx releases (vivado and sdk). We've always brushed it > aside as it was not critical until today. > > First, we can and do boot successfully from SD1, but that is for debug and > production needs. The real end-user image boots from eMMC (SD0). Since we > started skipping over u-boot (i.e. from fsbl directly to linux through the > tiny > trampoline code) our SDHCI1 controller seems to be in an incorrect state when > linux sdhci-of-arasan probes and scans for the mmc device. > > Basically, the first few commands/opcodes that are performed at 40KHz are > timing > out (10 seconds) with a SDHCI register dump. Then after a few of those 10 > seconds trial and failures, it seems the tuning is performed (and other > things, > not sure yet) and then the card is detected correctly. We get this behaviour > with either an actual SD storage card, or a Murata SDIO Wifi chip. > > We are getting this behaviour with both the 2019.1 and 2019.2 linux-xlnx > kernels. I have added "max-frequency = <10000000>;" to "&sdhci1" dts node and > this works around the problem. > > I am sure I am missing something quite simple, like a boolean in the PCW in > Vivado... or a build flag on FSBL, or a quirk I need to add to my DTS perhaps? One thing to check: Do you have a JTAG cable connected to the board? There's a bug in the ZynqMP hardware that makes the chip misbehave when the JTAG is connected. No active connection is needed, just the cable being there is enough to cause problems, mostly with the SD controllers, but also on I2C, SPI and serial. There is no solution for this other than removing the JTAG cable. A workaround is to disable CPU-idle support in Linux before connecting the cable: echo 1 > /sys/devices/system/cpu/cpu0/cpuidle/state1/disable We've had lots of troubles with the SD controller on the ZynqMP in the past as well, and I suspect the issue was related to pinmux. You mention three SDIO devices (eMMC, SD and WiFi), so if you are using pinmuxing to "select" active devices, this will not actually work, and result in the behaviour you described.
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4614): https://lists.yoctoproject.org/g/meta-xilinx/message/4614 Mute This Topic: https://lists.yoctoproject.org/mt/69519353/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/meta-xilinx/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
