-
Notifications
You must be signed in to change notification settings - Fork 560
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to reprogram FPGA and run NEW kernels in combination with XRT, affects both non-DFX and DFX base platforms #74
Comments
All right, after a few good hints (thanks @randyh62) and insisting on power-booting hardware platforms I conclude the following for non-DFX platforms:
Summarizing:
Why's only option 1. working? Can someone explain what are the processes behind reprogramming the FPGA in non-DFX platforms? Do I need to recreate the whole raw image (for the sd card) with |
All right, further testing things out (and through good feedback provided by Randy, Wes, Terry and others) I fount out that for non-DFX base platforms what matters isn't really the This then leads to the following fifth approach:
Summarizing:
This addresses questions above 1 and 3, but 2 remains:
|
@imrickysu can you look at this? |
Hi @vmayoral, |
In fact, I am experiencing the exact same issue. But if I don't reboot, for example, |
I have exactly the same behaviour than @dj-park. I am using a ZCU102 (DFX) and 2021.1 tools. Is there any solution to this problem? |
If I'm not mistaken, when you target the real hardware ( |
Still the case in 2023.2. Is there a way to put the PL in the xclbin file instead of the boot.bin file? Or maybe the FPGA has to boot before petalinux does, so there's no way to hot-swap the PL? |
Context
This ticket's part of a debugging effort and connected to past issues including #69 #70 #71 and #72.
While developing kernels it's common to test (also in
hw
target) incremental variants of it. So far, unfortunately, I haven't been able to do so. Only the first kernel produced (the first time the sd card is introduced is the hardware) remains. I haven't been able to successfully change this. The current issues has been validated in the following hardware and base platform combinations:A simple way to reproduce this is to build and test variants (silly ones, simple modifications of the kernel) of https://github.com/Xilinx/Vitis-Tutorials/tree/master/Getting_Started/Vitis. An exemplary flow to reproduce this issue is as follows:
app.exe
obtaining results coherent to thevadd.xclbin
kernel (whatever they are)vadd.cpp
(source code) introduce a small (or big, up to you) changev++
compilervadd.xclbin.new
for DFX platforms (or just build the whole image complete again withv++ -p
for non-DFX platforms)app.exe vadd.xclbin.new
The expected observation is that result remains fixed to 3. and not related to the changes introduced in 4., 5. and 6.. A past issue in XRT identified a similar behavior Xilinx/XRT#2747.
Results so far
NOTE: I'm using Vitis suite 2020.2 on top of Ubuntu 20.04.
NOTE 2: Ignore paths, they're specific to my development machines.
xilinx_zcu102_base_202020_1
Regardless of what I do the result's always the same which corresponds with the first kernel I flashed which modified https://github.com/Xilinx/Vitis-Tutorials/blob/master/Getting_Started/Vitis/example/src/vadd.cpp#L15 to:
xilinx_zcu102_base_dfx_202020_1
xilinx_zcu104_base_202020_1
I haven't been able to get tests to fail after this. Regardless of the modifications in the kernels.
Additional tests performed
Reinstalled Vitis suite and PetaLinux completely in a newly formatted machine with Ubuntu 20.04. Same result.
Temporary fix
A user proposed a temporary fix flashing manually the FPGA which I have not been able to reproduce Xilinx/XRT#2747 (comment). Here're my results when attempting this:
xilinx_zcu104_base_202020_1
Further debugging this issue led to a kernel panic:
xilinx_zcu102_base_dfx_202020_1
Questions
I was surprised that this (by "this" I mean the development flows explained above in Context) couldn't work in non-DFX platforms. Is this expected to work in non-DFX platforms? If not, what's the proposal for reprogramming the FPGA with XRT flows?addressed in Unable to reprogram FPGA and run NEW kernels in combination with XRT, affects both non-DFX and DFX base platforms #74 (comment)Since none of the above worked and the proposed fix in a past issue only led to more issues, how can I manually reprogram FPGAs for using them with XRT?addressed in Unable to reprogram FPGA and run NEW kernels in combination with XRT, affects both non-DFX and DFX base platforms #74 (comment)I'm currently blocked with this (and have been blocked by it for more than a week already) so It'd be great if someone could help with it or suggest and alternative route. Anything for
ZCU102
orZCU104
would do.Thanks!
The text was updated successfully, but these errors were encountered: