Changes for the Cycle of Life [MANUAL MERGE]
1 unresolved thread
1 unresolved thread
Compare changes
Files
7@@ -13,21 +13,21 @@ The current draft uses following service specification:
Finally ... This is quite a big changeset, so I tried to make sure to separate the changes into individual commits. Please don't squash!!
Please don't merge before everyone had the chance to take a look; these changes go quite deep into a lot of parts of the firmware and I fear I might have accidentally broken some things ...
WARNING: These changes break the API (hopefully for the last time ...)
Here's what's included:
The vector table's alignment requirements depend on the number of interrupts
(Cortex-M4 VTOR).
In our case, we have 0x6E(=110) interrupts and thus an alignment requirement
of 0x80(=128).
To satisfy this requirement, this commit moves the IVT to the beginning of
.text and enforces a 128 byte alignment. Please note that the headers which
come before .text will push the IVT to 0x100 instead of having it directly
in the beginning at 0x00.
@q3k, remember when I told you? :P
You can enable core 1 debugging by bootstrapping with
./bootstrap.sh -Ddebug_core1=trueCore 1 has its stack base at 0x20080000 which would overlap with the first
byte of the API parameter space. This patch moves the API further back to
prevent any weird behaviours being caused by this.
This allows Pycardium to learn which script it should start once it boots. Arguments can only be read before any API calls are made. Afterward they are lost.
To ensure they won't collide with anything during a core 1 restart,
they are offset by 0x20 from the start of the API buffer.
-1
Previously 0 was used but as 0 is also the ID of the reset interrupt,
this could lead to weird behaviors.
This commit introduces a way to control core 1. This is archieved by a predefined API-Interrupt: The reset interrupt. When triggered, it will bring the core back into its default state and wait for a new vector address from Epicardium. Once this vector address is transferred, it will start the new payload.
This method only works as long as core 1 is responsive to the API interrupts. Cases where this might not be the case:
Also add a mutex around API calls in preparation for future changes.
Hardware initialization routines should not clutter main and instead belong
into the new epicardium/modules/hardware.c. Haven't moved anything yet,
though.
Also splits the init into two steps, hardware_early_init() which runs before
absolutely everything and hardware_init() for less critical stuff.
This commit introduces a lifecycle for core 1. Based on the new loading system, a few APIs are made available to control the payload running on core 1. These are:
From core 1 (Pycardium, L0dable):
epic_exec(name) API Call: Request loading of a new payload by
name. If the file does not exist, the call will return with an
error code. Otherwise, control will go to the new payload.epic_exit(retcode) API Call: Return from payload
unconditionally. This call should be called whenever a payload is
done or when it has hit an unrecoverable error. On epic_exit,
Epicardium will reset the core back into the menu.From inside Epicardium:
epic_exec(name): This is not the same as the API call, as it
needs a different implementation underneath. It will load a new
payload and wait until this load actually completed (synchroneous).return_to_menu(): Return core 1 to the menu script no matter
what it is currently doing. This call is asynchroneous and will
return immediately after scheduling the lifecycle task. This task
will then take care of actually performing the load.Provides os.exit(ret) and os.exec("file.py").
When Pycardium encounters a HardFault, it will now return to the menu.
Pressing the power button will now excert the following behavior:
<400 ms: Return back to menu<1 s: Reset card10>1 s: Poweroffcc @schneider, @q3k, @swym