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: 
Highlighted
Observer yfortin
Observer
1,301 Views
Registered: ‎05-25-2015

Zynq7000 cannot boot from QSPI flash unless first executing U-BOOT from JTAG

Jump to solution

Hi,

 

  My platform is a custom design with Zynq 7030 which is booting Petalinux 2018.2 from on-board 32MB QSPI flash.

 

 When building new boards, the QSPI flash is obviously blank and needs programming. I figured that a useful way to write the QSPI would be to first boot a Petalinux image from SD Card, and then run an automated .sh script that writes two files "BOOT.BIN" and "image.ub" to QSPI flash. Of course this requires to momentarily change the MIO[5:3] strappings, so I have planned jumpers and external control for these lines.

 

  After successfully programming the QSPI flash from SD Card, I would expect Zynq to load from flash after a power cycle. However this is not happening. I can see activity on the QSPI signal lines, but the DONE_0 pin never goes high and there is no output on the UART console.

 

 After that, if I connect JTAG and use XSTC console from SDK 2018.2 to download and execute U-Boot (same version that is already on QSPI flash), then Zynq will fetch the rest of its code correctly from the QSPI flash and boot all the way to Petalinux console. The funny thing is, after doing this step of booting U-Boot through JTAG once, the QSPI is somehow "unlocked" and Zynq will always boot correctly from QSPI from there. After that I can cycle power and Zynq will always boot from QSPI without need for JTAG. Even if I erase the QSPI flash and redo the programming from SD Card, it will also boot correctly from QSPI.

 

 It seems that something is being modified permanently when I download and execute U-Boot from JTAG. Does anyone have an idea what it could be? I'm thinking there could be a OTP setting in the Zynq itself, or a setting in some register of the QSPI device that is being written. If there is such a thing, I wish I could include it on my SD Card build to avoid having to use JTAG at all.

 

  Any help welcome!

 

  Thank you,

  Yannick.

 

 

0 Kudos
1 Solution

Accepted Solutions
Observer yfortin
Observer
1,178 Views
Registered: ‎05-25-2015

Re: Zynq7000 cannot boot from QSPI flash unless first executing U-BOOT from JTAG

Jump to solution

Glad to say that my problem is solved;

 

The key was to add the description of the QSPI flash to the device tree (system-user.dtsi) before compiling Petalinux for my SD-Card. Now the boot process is doing what is necessary to work with this flash.

 

I am using a minimized version of Petalinux when booting from SD-Card, and I did not think it was relevant to specify the details of the QSPI flash since I wasn't booting from it. But I was wrong and everything is working after adding the description to device tree.

 

Thanks everyone!

Yannick.

 

&qspi {
 #address-cells = <1>;
 #size-cells = <0>;
 flash0: flash@0 {
  //compatible = "micron,n25q256";
  //spi-max-frequency = <50000000>;

  //--- Change flash to S25FL256S ---//
  compatible = "spansion,s25fl256s1";
  spi-tx-bus-width = <1>;
  spi-rx-bus-width = <4>;
  spi-max-frequency = <10000000>;

  reg = <0x0>;
  #address-cells = <1>;
  #size-cells = <1>;
  partition@0x00000000 {
   label = "boot";
   reg = <0x00000000 0x00800000>;
  };
  partition@0x00800000 {
   label = "bootenv";
   reg = <0x00800000 0x00020000>;
  };
  partition@0x00820000 {
   label = "kernel";
   reg = <0x00820000 0x00a80000>;
  };
  partition@0x012a0000 {
   label = "spare";
   reg = <0x012a0000 0x00000000>;
  };
 };
};

 

0 Kudos
10 Replies
Observer yfortin
Observer
1,278 Views
Registered: ‎05-25-2015

Re: Zynq7000 cannot boot from QSPI flash unless first executing U-BOOT from JTAG

Jump to solution

Another interesting observation about my problem;

 

I took another blank board and instead of running the SD Card first, I have left MIO[5:3] to boot from blank QSPI (which obviously didn't load) and then used XSCT to download/execute U-BOOT over JTAG as the very first step. The boot log is posted below.

 

After doing that, I have cycled power and loaded Zynq from SD Card and let it write BOOT.BIN and image.ub files to QSPI flash. This time the Zynq booted correctly from QSPI flash after power cycle. This is another example that executing U-Boot over JTAG is somehow unlocking the QSPI flash on my platform, regardless of being executed before or after writing the QSPI flash.

 

The steps to download/execute U-Boot over JTAG/XSCT are simply:

xsct% ps7_init

xsct% ps7_post_config

xsct% dow u-boot.elf

xsct% con

 

Below is the boot LOG from U-Boot downloaded/executed over JTAG on a blank board:

U-Boot 2018.01 (Jul 10 2018 - 10:11:18 -0400) Xilinx Zynq ZC702

Model: xs_m001_00593
Board: Xilinx Zynq
Silicon: v3.1
I2C:   ready
DRAM:  ECC disabled 256 MiB
MMC:   Card did not respond to voltage select!
mmc_init: -95, time 24
sdhci@e0100000 - probe failed: -95
Card did not respond to voltage select!
mmc_init: -95, time 25

SF: Detected s25fl256s_64k with page size 256 Bytes, erase size 64 KiB, total 32 MiB
*** Warning - bad CRC, using default environment

In:    serial@e0001000
Out:   serial@e0001000
Err:   serial@e0001000
Model: xs_m001_00593
Board: Xilinx Zynq
Silicon: v3.1
Net:   ZYNQ GEM: e000b000, phyaddr ffffffff, interface rgmii-id
eth0: ethernet@e000b000
U-BOOT for xs_m001_00593

Hit any key to stop autoboot:  0
SF: Detected s25fl256s_64k with page size 256 Bytes, erase size 64 KiB, total 32 MiB
device 0 offset 0x820000, size 0xa80000
SF: 11010048 bytes @ 0x820000 Read: OK
Wrong Image Format for bootm command
ERROR: can't get kernel image!
Zynq>

0 Kudos
Xilinx Employee
Xilinx Employee
1,246 Views
Registered: ‎10-16-2015

Re: Zynq7000 cannot boot from QSPI flash unless first executing U-BOOT from JTAG

Jump to solution

Hi Yannick,

 

 

If you're not getting anything on the UART at all then the ROM is probably failing in its attempt to load the FSBL from QSPI.  I suggest you check the BootROM error code.  Section 6.3.12 of the TRM (UG585v1.12.1) goes over these codes.  They can either be read from the INIT_B pin or over JTAG from the slcr.REBOOT_STATUS register.  The code should help troubleshoot the issue.

 

U-boot tends to be more robust with respect to flash support, so this may explain why it can access the flash but the ROM code cannot.  Additionally, you run ps7_init prior to loading u-boot which configures the QSPI.  The ROM on the other hand uses some default values for access.

 

Regards,

Shaun

0 Kudos
Observer yfortin
Observer
1,232 Views
Registered: ‎05-25-2015

Re: Zynq7000 cannot boot from QSPI flash unless first executing U-BOOT from JTAG

Jump to solution

Hi Shaun,

 

  Thank you for the advice. I have checked the INIT_B pin but the waveform is not consistent with what UG585 is showing. I don't see the 1 second delays and there are fewer pulses. The waveform is attached for your reference.

 

  I have also read the error code from slcr.REBOOT_STATUS [BOOTROM_ERROR_CODE] register using JTAG and XSCT:

xsct% mrd 0xF8000258

F8000258: F048200C

 

  Which if I understand correctly means:

  0x200C: Quad-SPI boot mode. The BootROM is unable to find a valid header within the image search range.

 

  Can you tell me if that "header" is part of the BOOT.BIN or image.ub files generated by Petalinux?

  If not, what exactly is U-BOOT doing to create/configure those headers? Is there a way to run the header configuration while booting from the SD Card?

 

  Thanks,

  Yannick.

 

INIT_B.jpg
0 Kudos
Adventurer
Adventurer
1,227 Views
Registered: ‎05-26-2017

Re: Zynq7000 cannot boot from QSPI flash unless first executing U-BOOT from JTAG

Jump to solution

Header is part of boot.bin. See page 69 - https://www.xilinx.com/support/documentation/user_guides/ug1137-zynq-ultrascale-mpsoc-swdev.pdf

 

To me it sounds like you have a pin that's floating, that needs to be driven or pulled up. That can cause strange behavior like this. 

 

Also, I would connect a SPI analyzer to see what transactions are taking place

 

Regards, 

0 Kudos
Observer yfortin
Observer
1,212 Views
Registered: ‎05-25-2015

Re: Zynq7000 cannot boot from QSPI flash unless first executing U-BOOT from JTAG

Jump to solution

Hi ottob,

 

  Thank you very much for your suggestion. I first thought too that some pin could be floating, but now I doubt it. I have set PUDC_B low to enable pull-ups on all I/Os, and I have on-board strapping resistors for everything that matters. If there was indeed some pin floating I would expect behavior to be random, but it is not. After it boots once from QSPI (after running U-BOOT from JTAG), it always boots correctly afterwards. There's got to be some field distinct from BOOT.BIN that is being modified.

 

  Debugging with a SPI analyzer is something I was hoping to avoid, because interpretation of the data can be time consuming. But I will do it if I have too.

 

  Thanks!

  Yannick.

0 Kudos
Xilinx Employee
Xilinx Employee
1,198 Views
Registered: ‎10-16-2015

Re: Zynq7000 cannot boot from QSPI flash unless first executing U-BOOT from JTAG

Jump to solution

Hi Yannick,

 

Another quick check you could do is read back the contents of flash from u-boot.  In particular, check that the header information read from u-boot matches what it should be in the boot.bin.

 

Also note that the boot.bin must start at a 32 KB aligned address. If you're burning the image at the start of flash this shouldn't be an issue.

 

If u-boot can read the header correctly but the ROM cannot, this would help isolate the issue to default NVM controller settings vs ps7_init settings.  It's also possible to override some default settings with register initialization values in the boot.bin (see BIF File Syntax in UG821).

 

Regards,

Shaun

0 Kudos
Observer yfortin
Observer
1,187 Views
Registered: ‎05-25-2015

Re: Zynq7000 cannot boot from QSPI flash unless first executing U-BOOT from JTAG

Jump to solution

Hi Shaun,

 

  Thank you for the suggestion.

 

  According to Section 6.3.2 "BootROM Header" of UG585 v1.12.2 (p.171), the boot header is located at the beginning of the flash device, starting at offset 0x000, up to checksum at offset 0x048.

 

  I have booted U-Boot from SD-Card and dumped the boot headers from QSPI flash for a non-booting board and another board that boots correctly. I have also compared the contents to original BOOT.BIN file. In all circumstances the contents are identical (see dump below). I think this demonstrates again that the problem is not with the contents of the flash or BOOT.BIN.

 

  What you're saying about default NVM controller settings vs ps7_init settings makes sense. But then how come the NVM controller settings become permanently modified after running U-Boot once from JTAG? After the first successfully boot, I am not running ps7_init anymore and it works perfectly. Where is that permanent setting?

 

  Also, I have tried to run only ps7_init and ps7_post_config (but not U-Boot) from JTAG, and then cycle power. This is not working. So whatever is being modified is not solely contained in the ps7_init script...

 

  Thanks,

  Yannick.

 

Zynq> sf probe
SF: Detected s25fl256s_64k with page size 256 Bytes, erase size 64 KiB, total 32 MiB
Zynq> sf read 0x04000000 0 100
device 0 offset 0x0, size 0x100
SF: 256 bytes @ 0x0 Read: OK
Zynq> md 0x04000000
04000000: eafffffe eafffffe eafffffe eafffffe    ................
04000010: eafffffe eafffffe eafffffe eafffffe    ................
04000020: aa995566 584c4e58 00000000 01010000    fU..XNLX........
04000030: 00001700 00018008 00000000 00000000    ................
04000040: 00018008 00000001 fc164530 00000000    ........0E......
04000050: 00000000 00000000 00000000 00000000    ................
04000060: 00000000 00000000 00000000 00000000    ................
04000070: 00000000 00000000 00000000 00000000    ................
04000080: 00000000 00000000 00000000 00000000    ................
04000090: 00000000 00000000 000008c0 00000c80    ................
040000a0: ffffffff 00000000 ffffffff 00000000    ................
040000b0: ffffffff 00000000 ffffffff 00000000    ................
040000c0: ffffffff 00000000 ffffffff 00000000    ................
040000d0: ffffffff 00000000 ffffffff 00000000    ................
040000e0: ffffffff 00000000 ffffffff 00000000    ................
040000f0: ffffffff 00000000 ffffffff 00000000    ................

0 Kudos
Observer yfortin
Observer
1,182 Views
Registered: ‎05-25-2015

Re: Zynq7000 cannot boot from QSPI flash unless first executing U-BOOT from JTAG

Jump to solution

Hi,

 

  After discussing with my colleagues, I think I may have found a very interesting lead;

 

  My QSPI flash device is Cypress S25FL256SAGBHIC00. According to datasheet, bit 1 in the Configuration Register 1 (CR1) is the "QUAD" field which is non-volatile and determines whether or not the flash can operate in Quad mode. The default value for this field is 0 (Quad mode disabled).

 

  Apparently Zynq will not boot unless this bit is set to 1. Therefore it is very likely that the sequence of operation executed by the JTAG boot includes the special command that sets this bit to 1 permanently. This would be the perfect explanation to everything I have observed.

 

  The question now is, is there a way to set this bit to 1 from the Petalinux user space? Is there some tool or command that I could execute as part of my startup script?

 

  Thanks,

  Yannick.

0 Kudos
Observer yfortin
Observer
1,179 Views
Registered: ‎05-25-2015

Re: Zynq7000 cannot boot from QSPI flash unless first executing U-BOOT from JTAG

Jump to solution

Glad to say that my problem is solved;

 

The key was to add the description of the QSPI flash to the device tree (system-user.dtsi) before compiling Petalinux for my SD-Card. Now the boot process is doing what is necessary to work with this flash.

 

I am using a minimized version of Petalinux when booting from SD-Card, and I did not think it was relevant to specify the details of the QSPI flash since I wasn't booting from it. But I was wrong and everything is working after adding the description to device tree.

 

Thanks everyone!

Yannick.

 

&qspi {
 #address-cells = <1>;
 #size-cells = <0>;
 flash0: flash@0 {
  //compatible = "micron,n25q256";
  //spi-max-frequency = <50000000>;

  //--- Change flash to S25FL256S ---//
  compatible = "spansion,s25fl256s1";
  spi-tx-bus-width = <1>;
  spi-rx-bus-width = <4>;
  spi-max-frequency = <10000000>;

  reg = <0x0>;
  #address-cells = <1>;
  #size-cells = <1>;
  partition@0x00000000 {
   label = "boot";
   reg = <0x00000000 0x00800000>;
  };
  partition@0x00800000 {
   label = "bootenv";
   reg = <0x00800000 0x00020000>;
  };
  partition@0x00820000 {
   label = "kernel";
   reg = <0x00820000 0x00a80000>;
  };
  partition@0x012a0000 {
   label = "spare";
   reg = <0x012a0000 0x00000000>;
  };
 };
};

 

0 Kudos
Adventurer
Adventurer
794 Views
Registered: ‎05-26-2017

Re: Zynq7000 cannot boot from QSPI flash unless first executing U-BOOT from JTAG

Jump to solution

Good find ! Is your u-boot environment in SPI Flash by any chance..? It must be trying to access it for some reason, even though you boot from SD. I'd be curios to know where that Bit is getting set in the SPI flash..

 

We went through similar problems with our board a year ago. Power-up booting from QSPI worked well, but when trying to reboot it would fail to load FSBL. Turns out Linux changed the SPI flash mode, which the BootROM did not handle. This has since been fixed in the Kernel, however it doesn't cover the case where the watchdog kicks in due to a kernel crash. For that modifications to the PMU Firmware was needed (to toggle the reset line of the SPI device).

 

/Otto

0 Kudos