UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Observer u-hide.ted
Observer
16,061 Views
Registered: ‎02-06-2012

Zynq SDIO via EMIO

Is there anyone using Zynq SDIO via EMIO?

 

Now examining SD access via EMIO, but correct access could not be confirmed.

 

According to reading sdio register, it seems to occur command CRC error (17 bit, Normal_interrupt_status_Errro_interrupt_status).

 

I'v alrady been checked eratta information, but not available.

 

Are there any other cautions for using SDIO via EMIO?

Should it be required any constraints in PL?

 

regards,

 

 

 

 

0 Kudos
43 Replies
Scholar sampatd
Scholar
15,942 Views
Registered: ‎09-05-2011

Re: Zynq SDIO via EMIO

Just check the following ARs, if you haven't already:

 

1. http://www.xilinx.com/support/answers/47874.htm

2. http://www.xilinx.com/support/answers/56141.htm

 

Regards,

0 Kudos
Observer lemli
Observer
15,867 Views
Registered: ‎03-28-2010

Re: Zynq SDIO via EMIO

Hi u-hide.ted,

 

I got EMIO kinda working with an eMMC in linux, and tried to post an explanation here but got 

 

"Authentication Ticket Mismatched, failed authentication. Return to my original page"

 

and my post was lost, together with the three days I lost fighting this issue. I'm not in the mood to type it up again.

 

Another frustrating Xilinx experience.

0 Kudos
Visitor vogtmark
Visitor
15,783 Views
Registered: ‎09-04-2013

Re: Zynq SDIO via EMIO

I have a very similar problem here. For now I spent over a week trying to figure out what's wrong with routing of the SDIO signal via EMIO. Problem is, that I have a board (MarsZX3 on MarsStarter from Enclustra) where the SD card slot is hardwired to PL pins. TO use an inserted SD card with the Zynq PS I have to route SDIO0 signals through the PL.

 

But for any reason the signals routed that way do not properly function as bidirectional ports. When accessing the SD card, commands are properly issued by the SD host controller and the device responds as expected. But, the response seem not to pass the PL/PS boundary. I confirmed using Chipscope that the response actually enters the PL, and I checked with PlanAhead that all routing is correct.

 

It seems that the EMIOSDIO0xxx pins are somehow broken inside the PS. Since the pins properly work as output, it looks like that the tristate logic inside the PS is not working as expected. Are there any know issues with the Zynq PS silicon?

Tags (1)
0 Kudos
Visitor dallas
Visitor
15,731 Views
Registered: ‎09-10-2013

Re: Zynq SDIO via EMIO

Are these the error messages you are seeing?

 

mmc0: req failed (CMD5): -123, retrying...
mmc0: req failed (CMD5): -123, retrying...
mmc0: req failed (CMD5): -123, retrying...
mmc0: req done (CMD5): -123: 00000000 00000000 00000000 00000000
mmc0: starting CMD55 arg 00000000 flags 000000f5
mmc0: req done (CMD55): -123: 00000000 00000000 00000000 00000000
mmc0: starting CMD55 arg 00000000 flags 000000f5
mmc0: req done (CMD55): -123: 00000000 00000000 00000000 00000000
mmc0: starting CMD55 arg 00000000 flags 000000f5
mmc0: req done (CMD55): -123: 00000000 00000000 00000000 00000000
mmc0: starting CMD55 arg 00000000 flags 000000f5
mmc0: req done (CMD55): -123: 00000000 00000000 00000000 00000000
mmc0: clock 300000Hz busmode 1 powermode 2 cs 0 Vdd 21 width 0 timing 0
mmc0: starting CMD1 arg 00000000 flags 000000e1
mmc0: req done (CMD1): -123: 00000000 00000000 00000000 00000000
mmc0: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0
mmc0: mmc_rescan_try_freq: trying to init card at 200000 Hz
mmc0: clock 0Hz busmode 2 powermode 1 cs 0 Vdd 21 width 0 timing 0
mmc0: clock 200000Hz busmode 2 powermode 2 cs 0 Vdd 21 width 0 timing 0
mmc0: starting CMD52 arg 00000c00 flags 00000195
mmc0: req done (CMD52): -123: 00000000 00000000 00000000 00000000
mmc0: starting CMD52 arg 80000c08 flags 00000195
mmc0: req done (CMD52): -123: 00000000 00000000 00000000 00000000
mmc0: clock 200000Hz busmode 2 powermode 2 cs 1 Vdd 21 width 0 timing 0
mmc0: starting CMD0 arg 00000000 flags 000000c0
mmc0: req done (CMD0): -123: 00000000 00000000 00000000 00000000
mmc0: clock 200000Hz busmode 2 powermode 2 cs 0 Vdd 21 width 0 timing 0
mmc0: starting CMD8 arg 000001aa flags 000002f5
mmc0: req done (CMD8): -123: 00000000 00000000 00000000 00000000
mmc0: starting CMD5 arg 00000000 flags 000002e1
mmc0: req failed (CMD5): -123, retrying...
mmc0: req failed (CMD5): -123, retrying...
mmc0: req failed (CMD5): -123, retrying...

etc etc etc

0 Kudos
Visitor vogtmark
Visitor
15,725 Views
Registered: ‎09-04-2013

Re: Zynq SDIO via EMIO

I tried to get the SD-card working with U-Boot to load the bootfiles (kernel, ramdisk, ...), so I did not boot into Linux yet and therefore did not see any error messages from the mmc driver. U-Boot fails with the SD card initialization sequence. Similar to your error log I see (via U-Boot debug output) a CMD0 issued sucessfully (CMD0 does not expect any response from the SD card) followed by a failing CMD5 (which actually does expect a response from the SD card). The response is never arriving at the processors SDIO-controller pins. As I wrote, I confirmed that the SD card generates the response correctly and that the signal actually enters the FPGA on the IO-pins but the internal electrical connection to the SDIO controller seems to be broken when it wants to read input on the CMD and/or DATA lines. I could try to get into a linux kernel and see what the mmc drivers error messages look like.
0 Kudos
Observer lemli
Observer
15,719 Views
Registered: ‎03-28-2010

Re: Zynq SDIO via EMIO

I'm in a better mood now thanks to a few weeks of absence from fighting Zynq issues.

 

TLDR: it is a BUG somewhere in the Xilinx tools. They generate tristate signals with wrong polarity.

 

When you make the SD CMD and DATA inout signals external in XPS and tie them to an inout pin in PL, it does not work because the tristate signals for CMD and DATA are internally inverted. This causes the pins to be driven when they should not and vice versa. The tools are creating a design that causes short circuits on CMD and DATA, and it is not obvious they are doing that.

 

So this is a Bad Bug with a capital Bs, not something "trivial" to be swept under the carpet by a cryptic AR.

 

Luckily, there is a workaround. Make the individual _O _I _T signals external instead, and to connect them via an IOBUF to an inout pin while inverting the _T signal.

 

VHDL example for CMD, do the same for DATA:

 

sdio_cmd_tn <= not sdio_cmd_t;
sdio_cmd_iobuf_inst: IOBUF
port map
(
IO => SDIO_CMD_pin,
O => sdio_cmd_i,
I => sdio_cmd_o,
T => sdio_cmd_tn
);

 

PS: mind the clock speeds. I haven't gotten around to working around that.

 

Now, just having to think about this misery again has worsened my mood. Back to something else...

 

0 Kudos
Visitor dallas
Visitor
15,716 Views
Registered: ‎09-10-2013

Re: Zynq SDIO via EMIO

Thanks for sharing what you experienced.  Which Zynq processor are you using and which version of the Xilinx toolset you are using that you saw the issue you had described?  Is it 14.6?

 

0 Kudos
Visitor dallas
Visitor
15,714 Views
Registered: ‎09-10-2013

Re: Zynq SDIO via EMIO

lemli, are you using the 7020 Zynq chip then?   http://www.xilinx.com/support/answers/47874.htm suggests the inverter issue is only applicable to the 7020 device.

0 Kudos
Visitor vogtmark
Visitor
15,709 Views
Registered: ‎09-04-2013

Re: Zynq SDIO via EMIO

I already tried the "individual _O _I _T" workaround as described by lemli. I can not confirm that the polarity of the enable signal is inverted. I connected the non-inverted _T signals to my IOBUF instances, and the output direction worked as expected. Only input seems not to work, even though the IOBUF itself is working properly. When connecting the inverted _T signals to the IOBUF, no output at all is leaving the chip when an SD-command is issued. I use a Zynq 7020 with Xilinx 14.4.
0 Kudos
Observer lemli
Observer
11,837 Views
Registered: ‎03-28-2010

Re: Zynq SDIO via EMIO

It's a Z7020 using ISE 14.5.

 

I don't have the device in front of me, but of note may be that IIRC the device is labeled CES99xx where xx does not appear in any public list of silicon revisions of the 7Z020. It reacts like production revision upon identification, however. 

 

I'm 100% certain that the _T inversion is required for this particular device/tool combination. First, I measured the signals with a scope and saw the bus conflict. Then, only after inversion, the eMMC could be identified by u-boot and the linux driver.

 

Eventually, when I return my focus to the project I'll need to verify if the workaround is still needed with a newer ISE version and/or Vivado and/or for another revision and/or another device. We have another but fairly similar design with the 7Z035 also. Fun stuff, 16 combinations to test.

 

If only Xilinx would clear up this confusion.

0 Kudos
Observer lemli
Observer
11,836 Views
Registered: ‎03-28-2010

Re: Zynq SDIO via EMIO

correction: 7Z020 and 7Z030
0 Kudos
Visitor dallas
Visitor
11,832 Views
Registered: ‎09-10-2013

Re: Zynq SDIO via EMIO

For U-Boot and Linux, which version are you using?  The latest 14.6 or an older version?  The reason I ask is from communicating with Xilinx, it sounded like eMMC support didn't get incorporated until 14.6.  Is that what you guys are using?

 

0 Kudos
Observer lemli
Observer
11,828 Views
Registered: ‎03-28-2010

Re: Zynq SDIO via EMIO



@dallas wrote:

For U-Boot and Linux, which version are you using?  The latest 14.6 or an older version?  The reason I ask is from communicating with Xilinx, it sounded like eMMC support didn't get incorporated until 14.6.  Is that what you guys are using?

 


Same as the tools used - 14.5. There is definitely at least some basic eMMC support present in 14.5 - the eMMC device/manufacturer/layout got recognized and I could read/write some blocks before errors occurred, most likely due to the too high 50Mhz clock. At this point it was only important to check the hardware for issues in preparation of a respin of the board, so I didn't push further for now.

0 Kudos
Visitor byip
Visitor
11,816 Views
Registered: ‎07-24-2013

Re: Zynq SDIO via EMIO

I believe 50 MHz is too high from reading the various Zynq documentatiosn and standards.  I think the Zynq can't support above 20 MHz when used with eMMC.

 

is your board designed directly with an embedded Micron eMMC?  Are you using 4 bit mode then?

 

0 Kudos
Observer lemli
Observer
11,810 Views
Registered: ‎03-28-2010

Re: Zynq SDIO via EMIO

Sure, 50MHz is too high, that's documented in the TRM. What's undocumented are the incantations one has to invoke to lower the clock speed across the board (from XPS to the linux driver). I'll find out eventually.

 

The onboard eMMC is a Hynix H26M21001. The Zynq PS7 only supports 4-bit mode which will do initially. If we find it too limiting, we'll have the option to integrate a controller in the PL that will work in 8-bit mode and at full speed later. That's the reason why we put it on EMIO instead of on the PS7 MIO.

0 Kudos
Visitor dallas
Visitor
11,771 Views
Registered: ‎09-10-2013

Re: Zynq SDIO via EMIO

When you were testing eMMC with UBoot, how were you using UBoot to test the eMMC?  Was there a UBoot command you were using to test the eMMC?  Thanks.

0 Kudos
Observer u-hide.ted
Observer
11,735 Views
Registered: ‎02-06-2012

Re: Zynq SDIO via EMIO

Hi 

 

Thank you for your comment and sorry that reply  is so late.

 

I checked feedback clock which is mentioned in AR#56141.htm and my problem was fixed.

 

In my case, according to a physical limitations, emioclkfb does't go through external of zynq.

 

Actually, I confirmed the access for sdcard via emio by connecting emioclkfb and emiosdioclk zynq internal.

 

regard u-hide

 

0 Kudos
Visitor vogtmark
Visitor
11,729 Views
Registered: ‎09-04-2013

Re: Zynq SDIO via EMIO

Hi u-hide.ted,

 

could you please describe in detail the steps you did to get SD via EMIO working? How does the configuration of your device look like (PS and PL)? Thanks!

0 Kudos
Observer u-hide.ted
Observer
11,705 Views
Registered: ‎02-06-2012

Re: Zynq SDIO via EMIO

Hi vogtmark,

 

As you can see in AR#56141, EMIOSDIO_CLK is connected to SDIO_CLK and EMIOSDIO_CLKFB with 0 ohm registers.

 

However, I connected EMIOSDIO_CLK and EMIOSDIO_CLKFB in PL directly because of  physical limitation (couldn't use PL IO for SDIO_CLKFB, so couldn't make connection external of zynq)

 

When SD via EMIO didn't work, EMIOSDIO_CLKFB was unused.

It seems EMIO_CLKFB port should be connected if using EMIO.

 

Regards u-hide.ted

0 Kudos
Scholar milosoftware
Scholar
12,685 Views
Registered: ‎10-26-2012

Re: Zynq SDIO via EMIO

I think we ran into the same issue here. Also several weeks after the PCBs came out of the factory, we discovered this thread. Hopefully, routing the IOBUF pin back to the feedback clk will fix the SDIO via EMIO not working at all.

 

Xilinx, please make this clear in your documents.

0 Kudos
Observer lemli
Observer
12,681 Views
Registered: ‎03-28-2010

Re: Zynq SDIO via EMIO

Good luck... 

 

One 7Z030 design was modified to loopback the clock externally, but the placer/router didn't want to cooperate. So the clock was fed back internally in the PL. At half clock speed linux raises I/O errors; lower is useless.

 

We tried a third party IP SD controller, but XST crashed during implementation. The vendor contacted Xilinx, who produced an unworkable workaround.

 

On the other 7Z020 design we abandoned the EMIO route and respun it, connecting the eMMC via MIO instead. After patching the PS7 initialization in fsbl due to the tools not properly configuring the CDN/WP signals, the eMMC works in linux.

 

The 7Z030 design will be modified a second time to use MIO.

 

You can imagine the cost for this mess.

 

Be advised; knowing what I do now, I definately recommend not going the EMIO route.

0 Kudos
Scholar milosoftware
Scholar
12,668 Views
Registered: ‎10-26-2012

Re: Zynq SDIO via EMIO

With the loopback in PL via the IOBUF, the EMIO still doesn't work. I've lowered the frequency to 1 MHz, that didn't help either.

 

Thanks for warning against implementing the whole SD controller in logic - it was the next thing I was planning to try.

0 Kudos
Observer lemli
Observer
12,664 Views
Registered: ‎03-28-2010

Re: Zynq SDIO via EMIO

There's no reason why a third party controller in the PL wouldn't work. It's just that the one I selected exposed problems that took Xilinx months to fix and out of necessity we moved on in the meantime.

 

I just received an e-mail today from Xylon with the info that Xilinx has solved the problem with a patch. You could try an evaluation version of the IP; it seems easy enough to set up and Xylon is very responsive.

0 Kudos
Visitor plastek
Visitor
12,635 Views
Registered: ‎03-27-2014

Re: Zynq SDIO via EMIO

We observe the same issue. Is Xilinx interested in solving this?

0 Kudos
Scholar milosoftware
Scholar
12,567 Views
Registered: ‎10-26-2012

Re: Zynq SDIO via EMIO

A new board arrived with the same chip on the MIO interface. The chip is detected correctly. So EMIO appears to be the cause of the communication problems.

0 Kudos
Adventurer
Adventurer
11,700 Views
Registered: ‎11-09-2013

Re: Zynq SDIO via EMIO

Hello fellow EMIO SD sufferers -

 

I was forced to utilize SD over EMIO as well (did not want too as SD via MIO worked great on ZedBoard, ZC702 and many others) and it's been terrible. No ability to utilize an external feedback clock either (I think this is my problem) Here is where I am at so far:

 

U-Boot v2013.4 - can read and write blocks from over 20 different types of microSD card. Successfully booted Linux kernel + rootfs at least 100 times. Had to patch U-Boot so it knew that the SD clock frequency was 25MHz. U-Boot v2013.4 Xilinx tag.

 

U-Boot uses the SD clock frequency you compile in as its basis for calculating divisors; the default U-Boot assumes 50MHz.

 

FSBL - setup IO clock for SD peripheral to be 25MHz. FSBL is programming register correctly for this.

 

WP/CD - neither implemented here. CD is active-low, and tied low in the Vivado design, works great. WP is confusing in Xilinx documentation as to whether it is active high, or active low. Assuming it is active-low, tied off WP to '1' in Vivado design, Write Protect register from SD0 reports that it is asserted, which is not correct (again for emphasis: the silicon hardware is convinced that WP is asserted). Possibly due to the PS/PL level-shifters? FSBL has programmed these to use EMIO "pins" 0x37 and 0x38, what are these in reference too?

 

I have seen issues in the past where people were getting FSBL's setting WP/CD to use random MIO pins instead of the indicated EMIO pins or otherwise, and I was actually hoping that would be the issue.

 

Linux - can consistently read from a minority of microSD cards. Errors whilst trying to read from others, unless an oscilloscope probe with ~8pF of capacitance is left on the clock line. Consistent write errors with any microSD card. Xilinx v2013.4-trd kernel. WP INVERTED quirk set because of above problem with WP.

 

Linux software also does not use device-tree at all, and obtains the current SD clock frequency from the SLCR.

 

FPGA - FAST slew rate w/ 12mA drive set on CLK, CMD and DATA[3:0]. WP and CD tied off in block diagram to 1'h1 and 1'h0 respectively.

 

My thoughts:

 

- Don't think I am suffering from the old Xilinx AR that applied to old silicon revisions where the polarity of the tri-state enables were inverted, as I can read and write to the card.

- Why was AR #56141 removed from the Xilinx website? I remember this AR describing the connectivity of SD_CLK and SD_CLK_FB. 

- Why does the EMIO require a FB clock connection, and the MIO does not?

- Is there anyone in existence who has successfully validated SDHC operation utilizing EMIO at 25MHz?

- Should I chain some inverters to introduce artificial delay in the PL for the FB signal? Terrible because tprop will change with temperature.

- Is the EMIO WP signal active-low or active-high?

 

I remember seeing this thread in September, making the recommendation that we utilize MIO based on my past Zynq projects and the issues this thread ran into, and now I'm back 5 months later. Argh.

 

I will let you know if I manage to fix it. My next thing is going to be dropping the IO clock frequency to 5MHz or so in FSBL, U-Boot and Linux and seeing if it is any more reliable.

 

Details:

Zynq 7020 484FBGA

Vivado 2013.4

Linux 3.12 (xilinx-v2013.4)

U-Boot (v2013.4)

SD_CLK f20-80% - 4ns

SD_CLK r20-80% - 4ns

Xilinx Employee
Xilinx Employee
11,696 Views
Registered: ‎01-09-2013

Re: Zynq SDIO via EMIO

Movax,

 

 

I am curious, how is your feedback clock routed on your board ?

WP needs to be connected to ground.

 

Did you capture the SDIO signals using a scope?


Would be interesting to see the timing on your interface?

Did you add any constraints to the SDIO interface?

 

example of SDIO constraints on 25MHz clock:

  TIMEGRP "sdio_pin_group" = PADS( SDIO0_* );
  TIMESPEC "TS_sdio_inputs" = FROM "sdio_pin_group" 8    ns;
  TIMESPEC "TS_sdio_outputs" = TO  "sdio_pin_group" 13.5 ns;

 

NOTE: there is other things to do as well but all depends on your interface timing and layout of your board.

 

 

0 Kudos
Adventurer
Adventurer
11,692 Views
Registered: ‎11-09-2013

Re: Zynq SDIO via EMIO

Hi habibe -

 

Sorry, I might not have been clear in my original posting, but to be explicit (and fully admit this could be the problem): no feedback clock is routed. This is a development board from a popular vendor (won't name them here as I don't want to disparage them / hurt them).

 

Currently, my top-level HDL simply ties the SD pins as such:


.SD0_buspow(1'hZ),

.SD0_busvolt(3'hZ),
.SD0_led(1'hZ),
.SD0_cdn(1'h0),
.SD0_clk(o_CLK_SD),
.SD0_clk_fb(o_CLK_SD),
.SD0_wp(1'h1),
.sd0_cmd_io(io_SD_CMD),
.sd0_data_io(io_SD_DATA), 


 

I notice that you said WP should be connected to GND; I will make that change and see what happens. Table 13-1 in the TRM lists the WP signals as 'EMIOSDIO0WP', leading me to believe it was active-high, but then figure 13-8 lists it as an active-low signal. Perhaps a documentation update is needed, but it sounds like you are confirming that from the POV of the silicon, WP is in fact an active-high signal?

 

I have been monitoring CLK on my scope, I attached a capture of the clock during U-Boot, after it has initialized a card at 25MHz.

 

Here are the constraints I have on the SD interface, they are probably not correct:

 

create_clock -period 30.300 -name clk_33 -waveform {0.000 15.150} [get_ports i_CLK_33]
create_clock -period 40.000 -name sd_clk -waveform {0.000 20.000} [get_ports o_CLK_SD]

create_clock -period 40.000 -name EMIOSDIO0CLK -waveform {0.000 20.000} [get_pins zamak/zamak_design_i/zamak_ps/processing_system7_1/inst/PS7_i/EMIOSDIO0CLK]
set_clock_groups -name pl_iopll_clocks -asynchronous -group [get_clocks {clk_fpga_0 EMIOSDIO0CLK sd_clk}] -group [get_clocks clk_33]

 

Looks like I should try throwing them on the CMD and DATA pins also? Should I be referencing the EMIOSDIOx* names?

scope_sdio_clk.jpg
0 Kudos
Xilinx Employee
Xilinx Employee
11,689 Views
Registered: ‎01-09-2013

Re: Zynq SDIO via EMIO

Yes, having a scope capture with the fowarded clock with respect to CMD and DATA that would be very useful.

 

There is lot of people that are looking for development baord with SD interface so there is nothing wrong with saying where one can be obtained.

Not an issue or bad on anyone part for not routing the Feedback clock on their baord (no all developent baord are made to be connected to just Xilinx eval boards).

 

The feedback clock needs to be connected internaly in the PL. So connecct the EMIOSDIO0CLKFB directly to the  EMIOSDIO0CLK.

 

Grounding CD implies card is always detected and tiying  WP to ground so the part is always writable. 

you can use the constraints that I provided in the previous response.


I will wait for the next scope capture.

0 Kudos