- Aug 15, 2019
-
-
rahix authored
Signed-off-by:
Rahix <rahix@rahix.de>
-
rahix authored
Also add a mutex around API calls in preparation for future changes. Signed-off-by:
Rahix <rahix@rahix.de>
-
rahix authored
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: - During times where core 1 has interrupts disabled - When in a higher priority exception handler - When core 1 has corrupted its IVT Signed-off-by:
Rahix <rahix@rahix.de>
-
rahix authored
Signed-off-by:
Rahix <rahix@rahix.de>
-
rahix authored
Previously 0 was used but as 0 is also the ID of the reset interrupt, this could lead to weird behaviors. Signed-off-by:
Rahix <rahix@rahix.de>
-
rahix authored
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. Signed-off-by:
Rahix <rahix@rahix.de>
-
rahix authored
Signed-off-by:
Rahix <rahix@rahix.de>
-
rahix authored
Closes #67 Signed-off-by:
Rahix <rahix@rahix.de>
-
Signed-off-by:
Mateusz Zalega <mateusz@appliedsourcery.com>
-
- Aug 14, 2019
- Aug 13, 2019
-
-
swym authored
-
- Aug 12, 2019
-
-
This commit substitutes the vendor gfx library with a completely new implementation. It also adds a text-buffer mode. Signed-off-by:
Mateusz Zalega <mateusz@appliedsourcery.com>
-
- Aug 10, 2019
-
-
rahix authored
Signed-off-by:
Rahix <rahix@rahix.de>
-
- Aug 09, 2019
-
-
- Implement de-initialization - Wrap filesystem operations in semaphore - Introduce EpicFileSystem object and move epic_file_FOO(...) imlementations into efs_FOO(EpicFileSystem*, ...) functions. - epic_file_FOO(...) functions are now wrappers around the _fs_ functions, but lock and unlock the global filesystem object before & after calls. This way, all efs_ functions can assume that the necessary lock has been acquired. - libff: don't use FF_FS_REENTRANT, our own FS lock is enough
-
- Aug 06, 2019
-
-
rahix authored
Signed-off-by:
Rahix <rahix@rahix.de>
-
rahix authored
Signed-off-by:
Rahix <rahix@rahix.de>
-