Commit 7fb48178 authored by Rahix's avatar Rahix
Browse files

feat(lifecycle): Allow core 1 to disable interrupts during API calls

When interrupts are disabled during API calls on core 1, we can only
trigger a core 1 reset when there is no API call ongoing.  This means
that the lifecycle machinery needs to allow any running API calls to
complete before it has a chance to see its reset interrupt delivered.

This is complicated because we cannot synchronize on core 1 triggering
an API call - the best we can do is stop the dispatcher, check whether
our reset interrupt was delivered, and if not, give it another chance to
process an API call.

Additionally, "give it another chance to process an API call" means that
the IDLE task must run, because this is currently a prerequisite to
scheduling the dispatcher (see [1]).  The only way to facilitate this is
with a sleep that is long enough that it will eventually let core 0 go
idle.  It seems that an 8 tick delay does the job quite fine.

Thus, implement a busy loop which provides the above requirements and
with that makes Epicardium prepared for payloads which perform API calls
with interrupts disabled.

[1]: https://firmware.card10.badge.events.ccc.de/epicardium/overview.html#internals
parent f26b9987
......@@ -119,8 +119,18 @@ static int do_load(struct load_info *info)
/*
* Wait for the core to become ready to accept a new payload.
*
* If it is not yet ready, hand back control of the API mutex to the
* dispatcher so it can finish dispatching a current API call. This is
* necessary for payloads which have interrupts disabled during an API
* call.
*/
core1_wait_ready();
while (!core1_is_ready()) {
mutex_unlock(&api_mutex);
/* Sleep so the dispatcher task can take the lock. */
vTaskDelay(8);
mutex_lock(&api_mutex);
}
/*
* Reinitialize Hardware & Drivers
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment