Skip to content

Revised IPC Implementation: Drivers and Test Applications - #580

Open
brghena wants to merge 8 commits into
masterfrom
dev/ipc-support
Open

Revised IPC Implementation: Drivers and Test Applications#580
brghena wants to merge 8 commits into
masterfrom
dev/ipc-support

Conversation

@brghena

@brghena brghena commented Aug 2, 2026

Copy link
Copy Markdown
Contributor

Pull Request Overview

This pull request corresponds to Tock PR tock/tock#5015 See the overview of the project there.

This PR adds drivers for the new IPC capsules, both libtock and libtock-sync.

This PR also adds applications that demonstrate each driver. The READMEs for each application describe the expected behavior.

Testing Strategy

This PR was tested on a Microbit v2. For fault testing, the PanicPolicy of the board needs to be changed to restart apps rather than panic.

TODO or Help Wanted

This should be good to go.

This is a quite big unfortunately. I did try to separate commits into separate parts of the system. So if you only want to look at one piece at a time, take a look at the corresponding single commit. Let me know if it would be preferable to split these commits into separate, smaller PRs.

PR Contents

AI Use

  • No AI was used in this PR.
  • AI was used in this PR. I have read Tock's AI policy and have properly disclosed my AI use below.
The design and code implementation was all human here. Probably ought to have used AI for some of the tedious parts...

@brghena

brghena commented Aug 7, 2026

Copy link
Copy Markdown
Contributor Author

This is going to have to deal with #581

Particularly, the IPC Relay Request has the apparently unique design of having success and failure types that aren't identical, so they weren't available in <tock.h> and I implemented them myself. But now, since these use u64 values, they have to accommodate the 64-bit TRD.

The current (as of writing) code:

returncode_t libtock_ipc_relay_request_command_server_get_next_request(uint32_t* len, uint64_t* ipc_id) {
  syscall_return_t cval = command(DRIVER_NUM_IPC_RELAY_REQUEST, 0x22, 0, 0);

  // We have different success and failure variants so we implement this ourselves
  // Success with u32 and u64
  // Failure with u64
  if (cval.type == TOCK_SYSCALL_SUCCESS_U32_U64) {
    *len = cval.data[0];
    uint32_t lsb = cval.data[1];
    uint32_t msb = cval.data[2];
    *ipc_id = (((uint64_t)msb) << 32) | ((uint64_t)lsb);
    return RETURNCODE_SUCCESS;
  } else if (cval.type == TOCK_SYSCALL_FAILURE_U64) {
    // In this error case, len is either max or irrelevant depending on the returncode
    uint32_t lsb = cval.data[1];
    uint32_t msb = cval.data[2];
    *ipc_id = (((uint64_t)msb) << 32) | ((uint64_t)lsb);
    return tock_status_to_returncode(cval.data[0]);
  } else {
    // The remaining SyscallReturn variants must never happen if using this
    // function. We return `EBADRVAL` to signal an unexpected return variant.
    return RETURNCODE_EBADRVAL;
  }
}

An update to <tock.c> made by #581:

#if defined(__riscv) && __riscv_xlen == 64
    // TRD-RISCV64BIT
    *val = command_return.data[0];
#else
    // TRD104
    uint32_t lsb;
    uint32_t msb;
    lsb  = command_return.data[0];
    msb  = command_return.data[1];
    *val = ((uint64_t)msb << 32) | lsb;
#endif

I really don't want RISC-V specific knowledge to leak into the IPC system, so this function needs to move back into the <tock.h> library.

Uses TBF Header Package Name field to register apps
Uses process-provided strings to register apps
Provides single-copy, allow-to-allow, request-and-response communication
This is particularly important for handling 64-bit platforms
@brghena

brghena commented Aug 10, 2026

Copy link
Copy Markdown
Contributor Author

#581 is now dealt with. Wasn't so hard. 3f79593

I ended up naming the new function: tock_command_return_u32_u64_or_u64_to_returncode()

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant