Revised IPC Implementation: Drivers and Test Applications - #580
Open
brghena wants to merge 8 commits into
Open
Conversation
5 tasks
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 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 #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;
#endifI really don't want RISC-V specific knowledge to leak into the IPC system, so this function needs to move back into the |
brghena
force-pushed
the
dev/ipc-support
branch
from
August 10, 2026 20:32
737f5f4 to
213bd62
Compare
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
force-pushed
the
dev/ipc-support
branch
from
August 10, 2026 21:07
213bd62 to
3f79593
Compare
Contributor
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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...