07-07-2020 01:42 AM
I've got a strange problem where my bitstream runs correctly before the kernel is booted, but stops working part way through the kernel boot, and I can't reflash it from the Linux userspace.
I'm new to the Zynq board and FPGAs in general, I'm developing on an MYIR Z-Turn Zynq 7020 board. I'm using the OCL flow, using Vivado 2019.1 and SDK 2019.1, and have successfully built a kernel, devicetree, and u-boot using the buildroot program.
I'm trying to output one of the clock signals on one of the header pins on the bottom of the dev board,
I've got the pin hooked up to an oscilloscope
and the clock signal is being output as expected, but it only last for a only a few seconds on the header pin as expected while u-boot loads the kernel, then the signal disappears part-way through the kernel boot process! It seems to be around the point where "of-fpga-region fpga-full: FPGA Region probed" is printed to the console.
I've configured the PL bitstream to be programmed by u-boot by including the bitstream in the boot.bin file.
I suspect that the problem may be that the kernel is re-flashing the bitstream somehow, but I can't figure out where.
As part of troubleshooting the problem of why the PL stops running, I ran into another problem through trying to program the bitstream from the Linux userspace using FPGA Manager, following the instructions on https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841645/Solution+Zynq+PL+Programming+With+FPGA+Manager. I checked that the fpga_full and devcfg nodes were present in the devicetree, and it seems that the FPGA Manager is at least running because there is a message in the console on boot, and the /sys/class/fpga_manager/fpga0/ directory is present on the device.
When I follow the steps for flashing using the "Using sysfs interface", the output looks exactly the same as the "Expected Output Using Sysfs" part at the bottom of the page, but the system hangs when I run the "devmem 0xA0000000" command. The FPGAINITDONE light flashes on the Z-Turn board, the same as when the bitsream gets programmed by u-boot, and the scope probe connected to the header pin momentarily goes high, but does not show the clock signal on the pin as it does after the bitstream is programmed by u-boot.
I've attached the serial console output, as well as the Make configs for buildroot, as well as the Make configs for the kernel and u-boot (from the buildroot/output/build/ directory).
I've also converted the devicetreeblob to readable format to include on this forum post, I'm using the blob on the actual dev board.I think the two problems are likely related but I can't figure it out.
Any tips or obvious things that I've missed would be greatly appreciated.
07-07-2020 04:32 PM
It turns out that flashing the bitstream is not the problem at all, I watched the FPGAINITDONE light as the kernel was booting and it doesn't intermittently flash like it does when it gets programmed by u-boot. I was previously attempting to output FCLK_CLK3 onto the header pins, and the problem actually seems to be that this fabric clock is getting stopped in the kernel boot process, because if I change the Zynq block diagram in Vivado to output FCLK_CLK0 onto the header pins, it remains working the whole way through the kernel boot process (CLK0 is being used as the AXI bus clock elsewhere in the block diagram).
So first half of my problem is a clock problem, not an embedded linux problem.
I also checked to see a new bitstream was getting programmed through the userspace FPGA Manager by attempting to program a different bitstream to the one that u-boot flashes, and have confirmed that the bitstream programming still does NOT work. I created two different bitstream files, one with FCLK_CLK0 set to 100MHz , and the other one withFCLK_CLK0 set to 50 MHz. I copied them both onto the SD card and tried to flash each one individually through userspace, but the clock signal coming out the header pins remains the same frequency after programming each of the two bitstreams, I would have expected it to change.
07-07-2020 08:03 PM - edited 07-07-2020 08:05 PM
What version are you using ?
I'm not sure whether clock divider issue is presence or not on Zynq.
But I know it in drivers/clk/zynqmp/divider.c is presence with on ZynqMPSoC (PMUFW) at 2019.1, if user set parameter promptly.
If so, you need to consider divider setting on dts and might need to modify it...
Hope this helps.
07-07-2020 09:18 PM
Hi Watari, what do you want to know the version of?
I'm using a MYIR Z-Turn Zynq with a Zynq 7000 series XC7Z020 SoC
Linux/arm 4.19.0 Kernel
U-Boot 2019.01, Vivado 2019.1 and SDK 2019.1
I'll look into the clock divider settings, thanks for the tip