Fix rftool buffer overrun for RFSoC HDL Coder ZCU216 and ZCU111 #3
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…the layer on top of it
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR has direct origin off of the tag mathworks_zynqrfsoc_R25.1.0, no direct branch to do the PR off of exists. The mathworks_R2026a branch is the closest public branch. This change is for the rftool code for the ZCU216 and ZCU111.
This PR slightly changes the code that buffers the incoming control plane characters from the TCP sockets api. Before this change a minor or major sockets exception would trigger writing outside of the bounds of a user space buffer. The data plane buffer checks were also cleaned up but the data plane is not directly used by Mathworks and the data plane had a sanity check preventing it from going out of bounds.
It was observed that sometimes even during board boot up when rftool is used via a localhost connection, the memory became corrupted; rftool would go a little off the rails but eventually land in a sanity check that subtly directly exits and ends the process. The memory overwrite will not always happen, it actually works without issue more times than it fails. But when it does fail it is game over.
These changes were verified on the ZCU208 and seem to only make the system more robust. Testing should be performed on the ZCU111 and ZCU216 for anything that uses rftool that doesn't have this change.