ZynqBerry demo_1 design with partial reconfiguration

[duckcud]

Hello Expert,

I succeeded to make a simple partial reconfiguration example work on ZynqBerry (Zynq processor, AXI, and a partial module). When I merged the partial module to Demo 1 design, I got an SD f_open error by code 3, which meant "the physical drive not work". f_mount was passed, but f_open returned the error code. If there were some change in the demo 1, which disturbed the SD configuration?

Could you please give some hint to solve the problem?!

Thank you in advance!

Best Regards,
YM

[JH]

Hello,

do you mean real partial reconfiguration of only a part of the PL? https://www.xilinx.com/products/design-tools/vivado/implementation/partial-reconfiguration.html
If you mean real PR, which Vivado version did you use? Vivado 16.2 or 17.1?
I think PR should not influence SD, but I must check your implementation before. Did you mix our prebuilt files (linux image...) with your own design? Maybe Files are generated with different vivado versions?

Or did you mean, you reconfigure the PL part over PS during running operation?

BR
John

[duckcud]

Hello John,

thank you for quick replying.

Yes, real partial reconfiguration by Vivado 16.2. I agree with you that the PR doesn't influence the SD, but somehow the software drive to access to the SD with this hardware design fails. I took over the PS configuration in Demo_1 and deactivated some peripheral ports and only built a PS processor, an AXI bus and an AXILite partial module (marked as TEST design). With this design, it worked. After I integrated the partial module with the full Demo_1, I got the FR_NOT_READY error code during the run-time. The initialisation of the SD passed, but it failed to open a file in the SD.

Momently, I didn't mix the linux image. I tested with a bare-metal application, which worked with TEST design, but failed in Demo_1. I googled some tipps, mostly related to the clock frequency, but the frequency in both design are same. What I doubt is that maybe some other peripheral configuration influences the SD so that the new generated BSP doesn't support the bare-metal app to access the SD. I try to build a petalinux app to see what will happen.

BR, YM

[JH]

My experience with Xilinx PR are out of date (old ISE, and a little bit from first Vivado version) , but i will try to help.

Ok, you use only bare metal app, did fsbl initialization passed and only SD access on your own application failed? Maybe during partial reconfiguration process? Do you try read PR image from SD?

Did you connect your AXILite PR module to same AXI Bus as the other components of DEMO1? Can you try it with a separate PS AXI Port.  In the past, IO's which are used in the PR region should be set constant, maybe there goes something wrong with Bus access.

Can you check also with Vivado Floorplanner, that no other signal is routed through the PR Region. Xilinx PR was glitch free, but maybe some of these signals are not available in one of your PR files.

br
John

[JH]

Did you check Chapter 8 "Known Issues and Limitations":

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2016_2/ug909-vivado-partial-reconfiguration.pdf



br
John

[duckcud]

Hello John,

thanks again!

The FSBL passed and the f_mount() of SD of my bare-metal app also worked, but f_open() failed. The process is stuck during transmitting the partial bit data from SD to DDR. I think there is nothing wrong with PR.

I didn't check the known issues and limitations, since it worked already with the TEST design. I am checking now.

BR, YM

[JH]

A part of the DDR is used as frame buffer (input and output) in demo 1, maybe there is a conflict. See fsbl_hooks.c from fsbl template included into the reference design (te0726_m_demo1\sw_lib\sw_apps\zynq_fsbl\src).

br
John

[duckcud]

Ach!

I will work on it, and post the result later.

BR, YM

[duckcud]

I found the problem. It was not due to the frame buffer on DDR, but somehow the actual SD frequency was changed to 102564102. After I set the SD clock source to IO PLL everything goes fine.

BR, YM

[JH]

Hi,

Arm PLL was selected on the 2016.2 Reference Design. 100MHz could not be set with this CLK dividers, so Vivado used nearest solution. This is fixed on 17.1 demo design now (Use IOPLL, like on board part files), which is know available on:

• https://shop.trenz-electronic.de/en/Download/?path=Trenz_Electronic/TE0726/Reference_Design/2017.1/zynqberrydemo1

br
John

[duckcud]

Hi John,

firstly, thanks for the information.

But it is strange that the original demo design used ARM PLL actually generates the 100MHz frequency. After I added my own module, the actual frequency changed. Anyway, the problem is solved.

Thanks again for the help!

Best Regards,
YM