cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
2,710 Views
Registered: ‎10-18-2017

Boot from QSPI is slow

Jump to solution

I am using ZC702 evaluation kit. The version of Vivado is 2017.2. The version of petalinux is 2017.2. 

 

When using pre-built image file for QSPI provided in UG1165, the boot time is about 10s which is fast. When build my own linux with the instruction of UG1144 and load the BOOT.bin into QSPI, the boot time is about 70s which is super slow.

 

I tried to modify the prescale of qspi clock in FSBL in SDK but it does not work. Did anyone encounter similar issue and any solution to it?

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Xilinx Employee
Xilinx Employee
3,676 Views
Registered: ‎10-06-2016

Hi @yywilson

 

Glad to hear that you found the root cause of the delay :)

 

There are different ways to modify your enviromental variables in U-Boot, one is on runtime and the other one in the build process. For the runtime use case just modify your variables using setenv command and then save it in the QSPI flash device using saveenv command.

 

For the petalinux use case that would modify your U-Boot compilation in order to set the default enviromental variables as desired. If not wrong you need to create a custom recipe for yocto to modify it. I would suggest you to open a new post as that way we can track better the issue and might me more useful for other users :)

 

Regards


Ibai
Don’t forget to reply, kudo, and accept as solution.

View solution in original post

0 Kudos
8 Replies
Highlighted
Xilinx Employee
Xilinx Employee
2,646 Views
Registered: ‎10-06-2016

Hi @yywilson

 

I'm not sure if the ZC702 pre-build image loads the bitstream or not but that might be one of the possible root causes. Nevertheless the first thing that you have to do is to identify which step is taking more time than expected in the boot process. BootROM? FSBL? U-Boot? Kernel?

 

Regards,

Ibai


Ibai
Don’t forget to reply, kudo, and accept as solution.
0 Kudos
Highlighted
Visitor
Visitor
2,631 Views
Registered: ‎10-18-2017

Hi Ibai,

 

Thank you for quick response.

 

The following is part of the output from console port. 

 

Hit any key to stop autoboot: 0
SF: Detected n25q128a with page size 256 Bytes, erase size 64 KiB, total 32 MiB
device 0 offset 0x520000, size 0xa80000

Wait for ~70s.
SF: 11010048 bytes @ 0x520000 Read: OK
## Loading kernel from FIT Image at 10000000 ...
Using 'conf@1' configuration
Verifying Hash Integrity ... OK
Trying 'kernel@0' kernel subimage

 

From the information I think reading kernel from address starts from 0x520000 cost a lot of time. And the speed of QSPI is just around 153KB/s.

 

0 Kudos
Highlighted
Visitor
Visitor
2,622 Views
Registered: ‎10-18-2017

I also tried that not include bitstream in both petalinux and fsbl.elf. It helps that the time of reading kernel reduced to ~35s but still much slower than pre-built image. 

 

I used pre-built bsp file for ZC702 when building petalinux. Does it define a lower read speed of QSPI?

 

 

0 Kudos
Highlighted
Explorer
Explorer
2,613 Views
Registered: ‎10-04-2017

I'm going to guess that u-boot is reprogramming the the SPI clock when it copies the data from flash to RAM.  I think the command you are looking for is 'sf probe

 

 

jeff

 

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
2,602 Views
Registered: ‎10-06-2016

Hi @yywilson

 

So your log clearly points that the issue is loading the image.ub (FIT image containing the kernel, rootfs and ramdisk) so there are just two possible reason for that:

1. The image.ub is bigger: 

SF: 11010048 bytes @ 0x520000 Read: OK 

In this case you have to either reduce your kernel size disabling non used drivers (no big changes) or take a look to your rootfs and disable non used utilities/libraries/applications. You could also change your rootfs type to use ext4 partitions or network based.

 

2. The interface is running much slower:

Zynq> sf probe -help
sf - SPI flash sub-system

Usage:
sf probe [[bus:]cs] [hz] [mode] - init flash device on given SPI bus and chip select

Take a look to you enviromental variables (printenv command) and modify the sf probe funciton in your FIT image load process and ensure that the [hz] parameter is defined to the highest frequency. (Most of the times the 0 value is used which does not guaranty to use the highest freq).

 

Regards,

Ibai

 


Ibai
Don’t forget to reply, kudo, and accept as solution.
0 Kudos
Highlighted
Visitor
Visitor
2,590 Views
Registered: ‎10-18-2017

Thank you for the response from Ibai and Jeff.

 

The root cause is that uboot did not set high speed for QSPI. From command "printenv" I can see something like "sf probe 0" which means it did not define the speed of QSPI. Then modify it to "sf probe 0 200000000 0" will solve this issue.

 

One more question is that where can I fine the configuration file of uboot in Petalinux 2017.2? And although "petalinux-config -c u-boot" is not introduced in any UG, it does show the menuconfig for uboot. Is it safe to modify the configuration?

 

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
3,677 Views
Registered: ‎10-06-2016

Hi @yywilson

 

Glad to hear that you found the root cause of the delay :)

 

There are different ways to modify your enviromental variables in U-Boot, one is on runtime and the other one in the build process. For the runtime use case just modify your variables using setenv command and then save it in the QSPI flash device using saveenv command.

 

For the petalinux use case that would modify your U-Boot compilation in order to set the default enviromental variables as desired. If not wrong you need to create a custom recipe for yocto to modify it. I would suggest you to open a new post as that way we can track better the issue and might me more useful for other users :)

 

Regards


Ibai
Don’t forget to reply, kudo, and accept as solution.

View solution in original post

0 Kudos
Highlighted
Adventurer
Adventurer
2,120 Views
Registered: ‎09-19-2017
hi, Is your problem solved? I have encountered the same problem as yours :). I'm looking forward to your reply.....................
0 Kudos