cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
alain_k
Observer
Observer
22,450 Views
Registered: ‎06-27-2014

Zynq FSBL cannot read BOOT.bin from SD card

Jump to solution

Hello,

 

I have a Microzed board with a Zynq 7020. I created a Project in Vivado and applied the board definition files prvided here. Then I created a FSBL project in the SDK based on that hardware project. As a minimal example I generated a bootimage using the FSBL I generated and the u-boot.elf from the SD card image provided by Avnet, from the same link as above. I enabled the debug output of the FSBL and it tells me this:


Xilinx First Stage Boot Loader
Release 2014.2 Sep 22 2014-14:34:28
Devcfg driver initialized
Silicon Version 3.1
Boot mode is SD
SD: rc= 0
SD: Unable to open file BOOT.BIN: 3
SD_INIT_FAIL
FSBL Status = 0xA009

This Boot Mode Doesn't Support Fallback
In FsblHookFallback function

 

I am able to boot from the original BOOT.bin provided by Avnet, so neither my SD card, nor my Microzed should be broken. As suggested in related threads, I also verified that the CD and WP pins are configured right and that the SD card clock is set to 50MHz. Is there anything else I could try?

 

Thanks,

Alain

0 Kudos
Reply
1 Solution

Accepted Solutions
norman_wong
Scholar
Scholar
27,886 Views
Registered: ‎05-28-2012

That error sounds like the SD controller is not quite connectd to the SD card. Your function calling stack must be part of 2014.1. I've only updated as far as 14.7. In that tool version, I think XSdPs_SdCardInitialize must be sd_init(). The CMD8 appears the be first command that needs a response.

 

From the MicroZED Schematic
 MIO40 = SD_CLK
 MIO41 = SD_CMD
 MIO42 = SD_D0
 MIO43 = SD_D1
 MIO44 = SD_D2
 MIO45 = SD_D3
 MIO46 = SD_CD
 MIO50 = SD_WP

From the ug585-Zynq-7000-TRM
2.5.4 MIO-at-a-Glance Table
- Double check pins uses in
B.28 System Level Control Registers (slcr)
Register (slcr) MIO_PIN_40 -> 0xF80007A0
Register (slcr) MIO_PIN_41 -> 0xF80007A4
Register (slcr) MIO_PIN_42 -> 0xF80007A8
Register (slcr) MIO_PIN_43 -> 0xF80007AC
Register (slcr) MIO_PIN_44 -> 0xF80007B0
Register (slcr) MIO_PIN_45 -> 0xF80007B4
Register (slcr) MIO_PIN_46 -> 0xF80007B8
Register (slcr) MIO_PIN_50 -> 0xF80007C8

In ps7_init.c, you should see somthing like this:
EMIT_MASKWRITE(0XF80007A0, 0x00003FFFU ,0x00000280U),
EMIT_MASKWRITE(0XF80007A4, 0x00003FFFU ,0x00000280U),
EMIT_MASKWRITE(0XF80007A8, 0x00003FFFU ,0x00000280U),
EMIT_MASKWRITE(0XF80007AC, 0x00003FFFU ,0x00000280U),
EMIT_MASKWRITE(0XF80007B0, 0x00003FFFU ,0x00000280U),
EMIT_MASKWRITE(0XF80007B4, 0x00003FFFU ,0x00000280U),
EMIT_MASKWRITE(0XF80007B8, 0x00003F01U ,0x00000201U),
EMIT_MASKWRITE(0XF80007C8, 0x00003F01U ,0x00000201U),

It appears that you are using 2014.1 or 2014.2. What version of tools was Avnet using to create their images? Maybe try to match. Some indication of FSBL problems here
 http://forums.xilinx.com/t5/Embedded-Development-Tools/FSBL-for-Zynq-does-not-work-SDK-2013-4-and-2014-1/td-p/522973
I have doubts it is problem with the auto-generated FSBL. I suppose the FSBL code might be putting the SC controller into a bad state. However any bugs in the autogenerated ps7-init code can be a problem. Sometimes ISE config doesn't make it to the ps7_init code. Seen that back in 14.1 with bus widths and 14.7 with NAND bus timing.

You have to careful about modifying the ps7_init.c in the FSBL source. It can be overwritten when there is a new export. Is some tools versions, I have seen the ps7_init files copied several times through the HW platform and BSP projects.

 

View solution in original post

22 Replies
achutha
Xilinx Employee
Xilinx Employee
22,420 Views
Registered: ‎07-01-2010
Hi,

If the card is write protected (WP is active), FSBL can not boot and returns this error.
The work-around is to route the PS SDIO WP pin out to EMIO and tie it to 0.

Let us know if this helps.

Regards,
Achutha
---------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------
0 Kudos
Reply
sampatd
Scholar
Scholar
22,409 Views
Registered: ‎09-05-2011
Can you do the checks mentioned in the AR below:
http://www.xilinx.com/support/answers/59476.html
0 Kudos
Reply
alain_k
Observer
Observer
22,397 Views
Registered: ‎06-27-2014

I tried to tie the WP pin to 0, but that didn't work. But I also doubt that my attempt to do it actually worked, as I don't think the PL is getting configured. Shouldn't the DONE pin be asserted after the PL was configured? In my case a LED would go on but it doesn't. If I boot the working original BOOT.bin, the LED goes on. For this test I tried it with and without my .bit-file in the Zynq image.

 

I read the AR, but it couldn't solve my problem. It refers to AR 59316, which says that the error with the WP pin should be fixed in Vivado 2014.1 and I'm using 2014.2. The other AR's it refers to (5202352016 and 51907) also shouldn't be the problem as I can boot the other image. And I think I coverd most of the other things in my initial post.

0 Kudos
Reply
norman_wong
Scholar
Scholar
22,370 Views
Registered: ‎05-28-2012

The boot steps are like so:
1) The ROM bootloader reads BOOT.bin from SD Card.
2) It extracts FSBL from the file and executes it.
3) FSBL runs the ps7_init code exported from Vivado.
4) FSBL reads the BOOT.bin from the SD Card.
5) FSBL loads u-boot and optional bitstream
6) FSBL executes u-boot.
The ROM bootloader is okay with the SD Card. It might not care about WP and CD though. I think FSBL does. The problem is likely that your ps7_init is disabling the SD Card is some way. Check the MIO config register writes in ps7_init.c and then back in Vivado.

0 Kudos
Reply
alain_k
Observer
Observer
22,361 Views
Registered: ‎06-27-2014

I looked into my ps7_init.c, but it doesn't make much sense for me. I searched for SDIO and that's about the only thing it finds:

 

// .. SDIO0_WP_SEL = 55
// .. ==> 0XF8000830[5:0] = 0x00000037U
// .. ==> MASK : 0x0000003FU VAL : 0x00000037U
// .. SDIO0_CD_SEL = 46
// .. ==> 0XF8000830[21:16] = 0x0000002EU
// .. ==> MASK : 0x003F0000U VAL : 0x002E0000U
// ..
EMIT_MASKWRITE(0XF8000830, 0x003F003FU ,0x002E0037U),

 

This output is from the version where WP should be routed to an EMIO. I also checked again in Vivado and SD 0 is definitely activated. Or is there a way to prevent the FSBL from caring about WP and CD at all?

0 Kudos
Reply
norman_wong
Scholar
Scholar
22,350 Views
Registered: ‎05-28-2012

Not sure about MIO 55 for WP. I think that maps to an EMIO. My area is primary firmware. I would guess that the bitstream must be loaded into the FPGA to map the WP to that EMIO. The FSBL loads the FPGA but the FSBL depends on the FPGA to setup the WP. Your ps7_init.c should have MIO_PIN_46 muxed to "nothing", eg
    EMIT_MASKWRITE(0XF80007B8, 0x00003F01U ,0x00000201U

Maybe there are other config. Clock frequency perhaps?


Unsure about modifying the FSBL. You might be able to modify it to ignore the CD and WP but your changes would likely get overwriten everytime you update the tools.

 

No idea what the AvNet images are doing to allow SD Card boot. Are they using the same version of tools? Each version generates a different FSBL.

 

Just checked the MicroZED schematic. MIO_PIN_50 is labelled as SD_WP.

0 Kudos
Reply
alain_k
Observer
Observer
22,336 Views
Registered: ‎06-27-2014

As I said, this was when I routed the WP pin to an EMIO, so that's how it should be. I checked the schematics of the MicroZed again and I saw now that the SD_WP pin (MIO_PIN_50) is hardwired to GND. So I guess that really shouldn't be the issue here. I also checked the config line you posted, but I already have the exact same line in my ps7_init.c. I changed my config back so that the WP pin is connected to MIO 50 and the config now looks like this:

 

// .. SDIO0_WP_SEL = 50
// .. ==> 0XF8000830[5:0] = 0x00000032U
// .. ==> MASK : 0x0000003FU VAL : 0x00000032U
// .. SDIO0_CD_SEL = 46
// .. ==> 0XF8000830[21:16] = 0x0000002EU
// .. ==> MASK : 0x003F0000U VAL : 0x002E0000U
// ..
EMIT_MASKWRITE(0XF8000830, 0x003F003FU ,0x002E0032U),

 

Still the same. What else can I try?

0 Kudos
Reply
norman_wong
Scholar
Scholar
22,317 Views
Registered: ‎05-28-2012

In ps7_init.c, double check the mux registers MIO_PIN_* for the the SD signals, clock, cmd, data, etc. I assume you are using the ps7_init in the FSBL source.

Enable or add printing in the SD code to see where it is failing. I think the file is ff.c. That error code of 3 is something to do with device not ready or init not completed.


0 Kudos
Reply
alain_k
Observer
Observer
22,309 Views
Registered: ‎06-27-2014

My problem is, that there is nothing at all in my ps_init.c that is named MIO_PIN_* and there is only that one part I posted before that contains the word SD. I can't see anything about the other SD card signals. Maybe their configuration is hidden somewhere in a cryptic register address and it is not commented with something related to SD. I also didn't find a table or something that would list the registers needed for the SD card configuration.

 

I also took the time to trace the error to the very end and I found out that it occures in InitSD()->f_open()->chk_mounted()->disk_initialize()->XSdPs_SdCardInitialize()->XSdPs_CmdTransfer(). XSdPs_SdCardInitialize() sends CMD8 and expects a response, but XSdPs_CmdTransfer() failes in the section described as "Polling for response for now".

0 Kudos
Reply
norman_wong
Scholar
Scholar
27,887 Views
Registered: ‎05-28-2012

That error sounds like the SD controller is not quite connectd to the SD card. Your function calling stack must be part of 2014.1. I've only updated as far as 14.7. In that tool version, I think XSdPs_SdCardInitialize must be sd_init(). The CMD8 appears the be first command that needs a response.

 

From the MicroZED Schematic
 MIO40 = SD_CLK
 MIO41 = SD_CMD
 MIO42 = SD_D0
 MIO43 = SD_D1
 MIO44 = SD_D2
 MIO45 = SD_D3
 MIO46 = SD_CD
 MIO50 = SD_WP

From the ug585-Zynq-7000-TRM
2.5.4 MIO-at-a-Glance Table
- Double check pins uses in
B.28 System Level Control Registers (slcr)
Register (slcr) MIO_PIN_40 -> 0xF80007A0
Register (slcr) MIO_PIN_41 -> 0xF80007A4
Register (slcr) MIO_PIN_42 -> 0xF80007A8
Register (slcr) MIO_PIN_43 -> 0xF80007AC
Register (slcr) MIO_PIN_44 -> 0xF80007B0
Register (slcr) MIO_PIN_45 -> 0xF80007B4
Register (slcr) MIO_PIN_46 -> 0xF80007B8
Register (slcr) MIO_PIN_50 -> 0xF80007C8

In ps7_init.c, you should see somthing like this:
EMIT_MASKWRITE(0XF80007A0, 0x00003FFFU ,0x00000280U),
EMIT_MASKWRITE(0XF80007A4, 0x00003FFFU ,0x00000280U),
EMIT_MASKWRITE(0XF80007A8, 0x00003FFFU ,0x00000280U),
EMIT_MASKWRITE(0XF80007AC, 0x00003FFFU ,0x00000280U),
EMIT_MASKWRITE(0XF80007B0, 0x00003FFFU ,0x00000280U),
EMIT_MASKWRITE(0XF80007B4, 0x00003FFFU ,0x00000280U),
EMIT_MASKWRITE(0XF80007B8, 0x00003F01U ,0x00000201U),
EMIT_MASKWRITE(0XF80007C8, 0x00003F01U ,0x00000201U),

It appears that you are using 2014.1 or 2014.2. What version of tools was Avnet using to create their images? Maybe try to match. Some indication of FSBL problems here
 http://forums.xilinx.com/t5/Embedded-Development-Tools/FSBL-for-Zynq-does-not-work-SDK-2013-4-and-2014-1/td-p/522973
I have doubts it is problem with the auto-generated FSBL. I suppose the FSBL code might be putting the SC controller into a bad state. However any bugs in the autogenerated ps7-init code can be a problem. Sometimes ISE config doesn't make it to the ps7_init code. Seen that back in 14.1 with bus widths and 14.7 with NAND bus timing.

You have to careful about modifying the ps7_init.c in the FSBL source. It can be overwritten when there is a new export. Is some tools versions, I have seen the ps7_init files copied several times through the HW platform and BSP projects.

 

View solution in original post

alain_k
Observer
Observer
16,160 Views
Registered: ‎06-27-2014

You are right, CMD8 is the first command that needs a response. I checked those config lines and they are exactly as you said. I am working with the 2014.2 tools, but I'm not sure which version Avnet used. The image they provide has a 14.5 kernel, so it might be ISE 14.5. But strangely, the BOOT.bin from the MicroZed tutorials (here) doesn't work either. I've downloaded the "Solutions" and they got a BOOT.bin in there for the peripheral test example. It doesn't work and that is definitely built with 2014.2. I believe they tested those examples once before releasing them, so does that mean my Zynq is somehow broken? But there has to be a way to get it running as the other image still works fine. I've looked at that thread and you might be right. There seem to be several others that can't get a working FSBL out of Vivado. ISE seems to be working though. I try to install ISE now and hope I can get it running.

0 Kudos
Reply
alain_k
Observer
Observer
16,145 Views
Registered: ‎06-27-2014

IT WORKS! With ISE 14.7 everything works like a charm. For now that will do it. I hope that some day Xilinx will release a working version of Vivado, but at least I can continue to work now. Thank you very much for your help and for pointing at the thread that gave me the hint.

0 Kudos
Reply
norman_wong
Scholar
Scholar
16,137 Views
Registered: ‎05-28-2012

Good to hear.. I'm using 14.7 myself. I haven't dared updating yet. Other bugs have stopped me. This is another one. That is too bad as the Vivado is suppose to fix some PL side problems.

 

Judging from your function calling tree to the sd init function, I would guess that the newer FSBLs use the SD driver in the BSP project rather the FSBL project. Perhaps the BSP SD driver is not properly initialized.

 

0 Kudos
Reply
norman_wong
Scholar
Scholar
15,890 Views
Registered: ‎05-28-2012

I've been forced to upgrade to 2014.3 and encountered the same problem. After much effort, I've traced the problem down to a change in the SD driver. In older SDK versions, the driver was in the FSBL project with the name mmc.c. The newer versions have thedriver in the BSP under sdps_v2_2:zsdps.c. The newer driver appears to only support newer SD (version 2) cards that support the CMD8 message. Older version 1 cards do not respond to that message. I have doubts that the new driver supports SDHC cards. Using identical files, a old 1GB card failed while a newer 4GB card worked.

 

EDIT:Correct size of bad card.

 

0 Kudos
Reply
ivzaen
Newbie
Newbie
13,863 Views
Registered: ‎06-26-2015

Vivado 2015.1 and ZedBoard.

Export hardware from Vivado to SDK, then build FSBL with SDK, it hangs on boot from SD card. FPGA fails to program, linux doesn't boot.

Tried two different cards: Transcend SD 2 Gb, Transcend SDHC 4 Gb, both of them don't boot with FSBL from Vivado 2015.1, but run okay with old ZedBoard FSBL.

 

Debug shows:

fails:  u32 InitSD(const char *filename)  // sd.c

fails:  rc = f_open(&fil, boot_file, FA_READ);  //returns rc=FR_NOT_READY

XSdPs_SdCardInitialize  //Fails

 

//file xsdps.c lines 308-313  should be commented out:

    /*
     * CMD8; response expected
     * 0x1AA - Supply Voltage 2.7 - 3.6V and AA is pattern
     */
//    Status = XSdPs_CmdTransfer(InstancePtr, CMD8,
//            XSDPS_CMD8_VOL_PATTERN, 0);
//    if (Status != XST_SUCCESS) {
//        Status = XST_FAILURE;
//        goto RETURN_PATH;
//    }

 

Commentinug out lines 308-313 of xsdps.c helped me to solve the problem.

 

ivan.

0 Kudos
Reply
sanjivgarg
Adventurer
Adventurer
13,516 Views
Registered: ‎12-10-2014

@alain_k wrote:

IT WORKS! With ISE 14.7 everything works like a charm. For now that will do it. I hope that some day Xilinx will release a working version of Vivado, but at least I can continue to work now. Thank you very much for your help and for pointing at the thread that gave me the hint.


hi alain_k,

I'm having the exact same problem;

the FSBL  can't read the BOOT.bin file on the SD card;

how did you use ISE 14.7 to solve your problem?

did you import the vivado project into ISE some how and then

generated the BOOT.bin file?

can you send detailed instructions?

 

 

0 Kudos
Reply
rankeney
Participant
Participant
13,488 Views
Registered: ‎11-26-2014

We just ran into the same problem. We had MIO7 connected to the SD. After switching it to MIO0 tied low, everything started working. This is with Vivado 2014.4. Ideally we'd still like to use MIO7. I'm trying to sort throught the EMIT_MASKWRITE calls to see if we can make that work.

0 Kudos
Reply
rankeney
Participant
Participant
13,487 Views
Registered: ‎11-26-2014

I meant to say connected to the SD_CD card detect line.

0 Kudos
Reply
rankeney
Participant
Participant
13,481 Views
Registered: ‎11-26-2014

Typos - We're using MIO9 for Card detect and MIO6 for WP.

0 Kudos
Reply
mamisadegh3
Explorer
Explorer
8,342 Views
Registered: ‎09-19-2010

I have had the exact same issue with one of the ZYNQ boards.

 

I am using Vivado 2015.4.

 

For me the solution was to lower down the clock freqeucny at which the sdio is operating.

I just moved it from 125MHz (default) to 50MHz, and things started working fine.

 

Mo.

Anonymous
Not applicable
7,247 Views

hi,

can you help me about the SD card?

I am debug the SD card  on Zynq (ZC706) by SD mode;

The SD card's  CLK pin in idle state  is  pull-up  or pull-down ?

 

0 Kudos
Reply
jamsoft
Participant
Participant
6,881 Views
Registered: ‎11-22-2016

Thank you!

 

This was solution also for my project! Changing frekquency from  default 125 to 50 solved the problems with reading from SD card on the Z-Turn board (7020).

Kindly note: please mark the Answer as "Accept as solution" if information provided is helpful and/or give Kudos to a post. Thank you!