-
-
Notifications
You must be signed in to change notification settings - Fork 781
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
Reversions, cleanup, and fixes to the scanchain systems #978
Conversation
Please break up in several PRs. b502a43, 1b677c5, d693647 are mostly syntactical fixes. Removal of the "auto-scan" is user interface change . For reverting the JTAG detection scheme, I think an issue to discuss is worth the effort. I have to access the impact on the RiscV and AVR8 branch. If jtag_scan again needs the irlens argument to scan through unknown chains, I think this would be a regression. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall it looks good to me. I am happy to merge this after the other questions are answered or amended.
b502a43
to
a15e378
Compare
I still urge to break up this PR in smaller, unrelated ones. This mixes up changes to the scan system with other things like syntactical changes and user interface changes. Of course auto/swd/jtag scan is a good idea, but still worth it's own PR. |
There is a bunch of patches in the pipeline that will improve things regarding device detection and supporting new platforms. They depend on this cleanup patch. I agree that we should strive to make pull requests transparent and focused on one task. But after talking to @DX-MON I think we will have to make an exception in this particular case. So I am merging this. Thanks for the hard work @DX-MON :) |
This set of commits seeks to address issues in the current JTAG scanchain detection and setup code.
The first problem this addresses is the way in which the post-scanchain-detection handler init is done as the table of ID Codes to handlers is needed for a future PR to provide support for JTAG-PDI, and passing the entire jtag_devs slot structure to the handler is horridly wasteful for information that can be gleaned a different way without this layering violation.
The second problem is in how chain scanning is being performed - the old code works a very particular way and this is necessary for correctly detecting things like ATXMega devices.
The third is the conflation of SWD and JTAG scan that is occurring, which is only partially addressed by this PR as SWD being able to defer on failure to JTAG at all is a violation of the boundy set by having specific
jtag_scan
andswd_scan
monitor commands - a future PR will be submitted that entirely removes this deferral and introduces anauto_scan
command that allows the BlackMagic Probe Firmware to slew through a pile of scan chain possibilities and try and auto-detect what is present.