5
3
Fork
You've already forked bmputil
2

Feature: BMD RSP v4 support #88

Merged
northernpaws merged 23 commits from feature/full-bmp-rsp-support into main 2026年07月04日 00:52:47 +02:00

In this PR we fully implement BMD remote protocol v4. This includes fixing the return types in the RISC-V related traits so the functions can properly report errors, and creating a RISC-V error type to report them with. The structure of the RISC-V Debug support types now matches up to the structure of the ADI ones.

This PR also includes some bugfixes for the older protocol versions to correct some mistakes that had been made sizing packets and such which could lead to some unintended consequences or panics. They are applied in this PR for consistency with the new support that already integrates matching changes. There will be a PR to BMD reflecting the findings here too.

The branch this is on has now concluded use as this is the fourth of a series of 4 PRs implementing full remote protocol support into bmputil, so should be deleted after merge.

With this PR merged, current remote protocol support will be fully available in bmputil, save for the ensure idle functionality that was recently added to BMD. That functionality will be implemented in a follow-up PR at a separate point in time. We are aware that unit testing for all this new functionality is a bit lacking and intend to correct that with a faux serial interface system that allows us to run remote protocol transactions in unit tests without needing hardware. That too will be an additional follow-up PR.

In this PR we fully implement BMD remote protocol v4. This includes fixing the return types in the RISC-V related traits so the functions can properly report errors, and creating a RISC-V error type to report them with. The structure of the RISC-V Debug support types now matches up to the structure of the ADI ones. This PR also includes some bugfixes for the older protocol versions to correct some mistakes that had been made sizing packets and such which could lead to some unintended consequences or panics. They are applied in this PR for consistency with the new support that already integrates matching changes. There will be a PR to BMD reflecting the findings here too. The branch this is on has now concluded use as this is the fourth of a series of 4 PRs implementing full remote protocol support into bmputil, so should be deleted after merge. With this PR merged, current remote protocol support will be fully available in bmputil, save for the ensure idle functionality that was recently added to BMD. That functionality will be implemented in a follow-up PR at a separate point in time. We are aware that unit testing for all this new functionality is a bit lacking and intend to correct that with a faux serial interface system that allows us to run remote protocol transactions in unit tests without needing hardware. That too will be an additional follow-up PR.
serial/remote/protocol_v4: Implemented the logic for riscv_jtag_init() to actually initialise the protocol mode properly
All checks were successful
ci/woodpecker/pr/build-windows/2 Pipeline was successful
ci/woodpecker/pr/build-linux Pipeline was successful
ci/woodpecker/pr/build-windows/1 Pipeline was successful
a5ef9e74d7
northernpaws approved these changes 2026年06月28日 23:49:26 +02:00
Dismissed
northernpaws left a comment
Copy link

Looks good to me!

Looks good to me!
serial/remote/protocol_v0: Fixed a format string error in the JTAG TDI-TDO sequence function
All checks were successful
ci/woodpecker/pr/build-windows/2 Pipeline was successful
ci/woodpecker/pr/build-linux Pipeline was successful
ci/woodpecker/pr/build-windows/1 Pipeline was successful
0c22ccb6cf
dragonmux dismissed northernpaws's review 2026年07月01日 03:10:41 +02:00
Reason:

New commits pushed, approval review dismissed automatically according to repository settings

serial/remote/protocol_v2: Fixed a clock cycles constraint check being missing in the JTAG run cycles function implementation
All checks were successful
ci/woodpecker/pr/build-windows/2 Pipeline was successful
ci/woodpecker/pr/build-linux Pipeline was successful
ci/woodpecker/pr/build-windows/1 Pipeline was successful
ci/woodpecker/push/build-linux Pipeline was successful
ci/woodpecker/push/build-windows/2 Pipeline was successful
ci/woodpecker/push/build-windows/1 Pipeline was successful
0ab561ed49
Author
Owner
Copy link

Found another couple of mistakes, so please could you re-review and approve?

Found another couple of mistakes, so please could you re-review and approve?
@ -150,3 +150,3 @@
}
fn riscv_jtag_init(&self)-> Option<Arc<dynBmdRiscvProtocol>>
fn riscv_jtag_init(&self)-> Result<Option<Arc<dynBmdRiscvProtocol>>>

I'm not saying this doesn't have a reason but why do you need both Result and Option here? If you're looking at certain classes of errors it's often more ergonomic to use a conversion method, isn't it?

I'm not saying this doesn't have a reason but why do you need both Result and Option here? If you're looking at certain classes of errors it's often more ergonomic to use a conversion method, isn't it?
Author
Owner
Copy link

This particular remote protocol acceleration is optional - it is not an error for the probe to say it doesn't support the acceleration and so while we want to report protocol errors and such (Result), we also want to be able to say "not supported" without that being an error (Option).

In such a case, a fallback implementation should be used that uses the JTAG protocol implementation directly - this isn't currently provided, but perhaps once it is, this becomes just simply a Result<Arc<dyn BmdRiscvProtocol>> - but that being down the road.

This particular remote protocol acceleration is optional - it is not an error for the probe to say it doesn't support the acceleration and so while we want to report protocol errors and such (Result), we also want to be able to say "not supported" without that being an error (Option). In such a case, a fallback implementation should be used that uses the JTAG protocol implementation directly - this isn't currently provided, but perhaps once it is, this becomes just simply a `Result<Arc<dyn BmdRiscvProtocol>>` - but that being down the road.
freyjadomville marked this conversation as resolved
freyjadomville left a comment
Copy link

LGTM with that explanation

LGTM with that explanation
northernpaws left a comment
Copy link

Changes look good to me!

Changes look good to me!
northernpaws deleted branch feature/full-bmp-rsp-support 2026年07月04日 00:52:48 +02:00
Sign in to join this conversation.
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
3 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/bmputil!88
Reference in a new issue
blackmagic-debug/bmputil
No description provided.
Delete branch "feature/full-bmp-rsp-support"

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?