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?
Any clue will help. Thanks in advance!
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#4613):
https://lists.yoctoproject.org/g/meta-xilinx/message/4613
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]]
-=-=-=-=-=-=-=-=-=-=-=-
