Support CoreMgmt over DRTIO on Zynq Devices #323

Open
occheung wants to merge 21 commits from occheung/artiq-zynq:drtio-coremgmt into master
Owner

Summary

The corresponding Kasli-SoC PR for ARTIQ PR.

Main differences to the ARTIQ PR

  • No frontend
  • Kasli-SoC already supports flashing via config write

Similar issues experienced on RISC-V devices can be expected here.

## Summary The corresponding Kasli-SoC PR for [ARTIQ PR](https://github.com/m-labs/artiq/pull/2559). ## Main differences to the ARTIQ PR - No frontend - Kasli-SoC already supports flashing via `config write` Similar issues experienced on RISC-V devices can be expected here.
occheung added 3 commits 2024-08-28 13:44:53 +08:00
mwojcik reviewed 2024-08-28 13:55:36 +08:00
@ -232,1 +870,3 @@
pub fn start(cfg: Config) {
pub fn start(
cfg: Config,
drtio_tuple: Option<(
Owner

Slightly related: I like the tuple to keep the argument list shorter/more compartmentalized, should we adapt it in other places too?

Slightly related: I like the tuple to keep the argument list shorter/more compartmentalized, should we adapt it in other places too?
Contributor

Agreed that a a lot of argument lists are needlessly long. Especially with the shared sync primitives theres a lot of repetition. Though I'm not sure that these tuples make things much shorter, without some type aliasing. Is there a case for putting these shared sync prims in a struct and passing around an Rc to that instead? (In a similar style to how the mainline repo passes around Io)

Putting the idea out there, obviously it would be a heavy refactor...

Agreed that a a lot of argument lists are needlessly long. Especially with the shared sync primitives theres a lot of repetition. Though I'm not sure that these tuples make things much shorter, without some type aliasing. Is there a case for putting these shared sync prims in a struct and passing around an `Rc` to that instead? (In a similar style to how the mainline repo passes around `Io`) Putting the idea out there, obviously it would be a heavy refactor...
occheung added 8 commits 2024-09-05 12:17:20 +08:00
occheung added 1 commit 2024-09-09 17:28:31 +08:00
sb10q reviewed 2024-09-14 11:42:12 +08:00
@ -115,0 +837,4 @@
stream: &mut TcpStream,
pull_id: Rc<RefCell<u32>>,
cfg: Rc<Config>,
_drtio_tuple: Option<(&Rc<Mutex<bool>>, &RoutingTable, GlobalTimer)>,
Owner

Isn't that just an idiosyncratic object? Canonical way would be to define a struct.

Isn't that just an idiosyncratic object? Canonical way would be to define a ``struct``.
occheung force-pushed drtio-coremgmt from fbb20bc723 to 93e25169fb 2024-09-19 17:19:45 +08:00 Compare
occheung added 3 commits 2024-09-20 17:10:17 +08:00
occheung changed title from WIP: Support CoreMgmt over DRTIO on Zynq Devices to Support CoreMgmt over DRTIO on Zynq Devices 2024-09-20 17:38:58 +08:00
This pull request can be merged automatically.
You are not authorized to merge this pull request.
You can also view command line instructions.

Step 1:

From your project repository, check out a new branch and test the changes.
git checkout -b occheung-drtio-coremgmt master
git pull drtio-coremgmt

Step 2:

Merge the changes and update on Gitea.
git checkout master
git merge --no-ff occheung-drtio-coremgmt
git push origin master
Sign in to join this conversation.
No reviewers
No Milestone
No Assignees
4 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: M-Labs/artiq-zynq#323
No description provided.