8
33
Fork
You've already forked blackmagic
23

Fix: Memory access halting heuristic #1962

Merged
esden merged 5 commits from fix/memory-access-halting-heuristic into main 2024年10月17日 18:14:35 +02:00

Detailed description

In this PR we address the incredibly broken target halting for memory access heuristic, replacing it fully with a TOPT which can be set on targets that are confirmed to work without bad reads, CPU halts or perturbed timings (such as stolen bus cycles that upset hard real-time applications).

For now this is only enabled on RISC-V targets that use the System Bus mechanism for memory access as that's guaranteed to be okay by the RISC-V Debug specification, however it can be easily enabled for targets where it's confirmed okay by simply adding target->target_options |= TOPT_NON_HALTING_MEM_IO; in the probe routine for that target.

This method has been chosen on account of how difficult it is to find out if a target can do this correctly, and the numerous counter-examples shown for, eg, saying "all Cortex-M are okay" as this is not true on the Tiva-C series, instantly striking down this statement and requiring a narrower enablement. Before a target can be enabled as allowing non-halting memory I/O it must be shown to: be able to read memory correctly without halting (this is the problem for the Tiva-C, you will get back garbled reads if you try this); be able to read without halting the CPU (eg, checking SysTick timings); be able to show that the reads to not perturb the CPU using the bus (indication of stolen cycles) in a way that throws off timings (eg, by wiggling a GPIO in a loop).

With this change done, some sort of memory monitoring command becomes possible as was being requested/talked about in #1532 and Koen's PRs for "memwatch". These were not taken before as it introduced obvious unsafety into the code on account it did not block reading on Cortex-A/R targets where, short of the vendor providing a secondary AP for memory I/O, it is not possible to do a non-halting read, and this heuristic did not stop attempts on RISC-V parts that use the Abstract Command mechanism or progbuf mechanism for access.

Your checklist for this pull request

Closing issues

<!-- Filling this template is mandatory --> ## Detailed description In this PR we address the incredibly broken target halting for memory access heuristic, replacing it fully with a TOPT which can be set on targets that are confirmed to work without bad reads, CPU halts or perturbed timings (such as stolen bus cycles that upset hard real-time applications). For now this is only enabled on RISC-V targets that use the System Bus mechanism for memory access as that's guaranteed to be okay by the RISC-V Debug specification, however it can be easily enabled for targets where it's confirmed okay by simply adding `target->target_options |= TOPT_NON_HALTING_MEM_IO;` in the probe routine for that target. This method has been chosen on account of how difficult it is to find out if a target can do this correctly, and the numerous counter-examples shown for, eg, saying "all Cortex-M are okay" as this is not true on the Tiva-C series, instantly striking down this statement and requiring a narrower enablement. Before a target can be enabled as allowing non-halting memory I/O it must be shown to: be able to read memory correctly without halting (this is the problem for the Tiva-C, you will get back garbled reads if you try this); be able to read without halting the CPU (eg, checking SysTick timings); be able to show that the reads to not perturb the CPU using the bus (indication of stolen cycles) in a way that throws off timings (eg, by wiggling a GPIO in a loop). With this change done, some sort of memory monitoring command becomes possible as was being requested/talked about in #1532 and Koen's PRs for "memwatch". These were not taken before as it introduced obvious unsafety into the code on account it did not block reading on Cortex-A/R targets where, short of the vendor providing a secondary AP for memory I/O, it is not possible to do a non-halting read, and this heuristic did not stop attempts on RISC-V parts that use the Abstract Command mechanism or progbuf mechanism for access. ## Your checklist for this pull request * [x] I've read the [Code of Conduct](https://github.com/blackmagic-debug/blackmagic/blob/main/CODE_OF_CONDUCT.md) * [x] I've read the [guidelines for contributing](https://github.com/blackmagic-debug/blackmagic/blob/main/CONTRIBUTING.md) to this repository * [x] It builds for hardware native (see [Building the firmware](https://github.com/blackmagic-debug/blackmagic?tab=readme-ov-file#building-black-magic-debug-firmware)) * [x] It builds as BMDA (see [Building the BMDA](https://github.com/blackmagic-debug/blackmagic?tab=readme-ov-file#building-black-magic-debug-app)) * [x] I've tested it to the best of my ability * [x] My commit messages provide a useful short description of what the commits do ## Closing issues <!-- put "fixes #XXXX" here to auto-close the issue(s) that your PR fixes (if any). -->
esden (Migrated from github.com) approved these changes 2024年10月17日 18:13:34 +02:00
esden (Migrated from github.com) left a comment
Copy link

LGTM, great to see that we are getting closer to having non halting memory access. :)

LGTM, great to see that we are getting closer to having non halting memory access. :)
Author
Owner
Copy link

💯 we're glad to have got this heuristic situation fixed as well as it'd been bothering us as we do actually want to see more features for memory debugging merged, just.. safely!

💯 we're glad to have got this heuristic situation fixed as well as it'd been bothering us as we do actually want to see more features for memory debugging merged, just.. safely!
Sign in to join this conversation.
No reviewers
Labels
Clear labels
BMD App
Black Magic Debug App (aka. PC hosted) (not firmware)
BMP Firmware
Black Magic Probe Firmware (not PC hosted software)
Bug
Confirmed bug
Build system
Build system
Can't reproduce
Maintainers can't reproduce this problem
CI
Continuous Integration System
Contribution wanted
User contributions welcome
Documentation
Project documentation
Draft
Work in progress draft
Duplicate
This issue or pull request already exists
Enhancement
General project improvement
Feedback wanted
Requires additional submitter feedback
Foreign Host Board
Non Native hardware to runing Black Magic firmware on
GDB
Issue/PR related to GDB
Good first issue
Good for newcommers
HwIssue Mitigation
Solving or mitigating a Hardware issue in Software
Information Needed
Maintainers need more information
NativeHardware
Official Black Magic Debug Hardware
New Host Board
New hardware to run Black Magic firmware on
New Target
New debug target
Off Topic
Something that does not involve the project in any way
Potential Bug
A potential, unconfirmed or very special circumstance bug
Regression
Bug caused by a regression
User Interest Needed
More user interest required before consideration
User Testing Needed
Looking for user testing reports
Won't fix
Outside of the project scope or works as intended
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
blackmagic-debug/blackmagic!1962
Reference in a new issue
blackmagic-debug/blackmagic
No description provided.
Delete branch "fix/memory-access-halting-heuristic"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?