A board can now customise mboot with:
- MBOOT_LED1, MBOOT_LED2, MBOOT_LED3, MBOOT_LED4: if it needs to have
different LEDs for mboot compared to the application
- MBOOT_BOARD_LED_INIT: if it needs a fully customised LED init function
- MBOOT_BOARD_LED_STATE: if it needs a fully customised LED state-setting
function
- MBOOT_BOARD_GET_RESET_MODE: if it needs a fully customised function to
get the reset mode
With full customisation, the only requirement is a single LED to show the
status of the bootloader (idle, erasing, flashing, etc), which can be
configured to do nothing if needed.
Signed-off-by: Damien George <damien@micropython.org>
It is enabled by default to get the standard behaviour of doing a reset
after it is finished, but can be disabled by a board to jump straight to
the application (likely the board needs to use MBOOT_BOARD_CLEANUP to make
this work).
The application is passed a reset mode of BOARDCTRL_RESET_MODE_BOOTLOADER
if the bootloader was active and entered via a jump.
Signed-off-by: Damien George <damien@micropython.org>
This new logic is equivalent to the old logic when the only possibilities
for reset_mode are NORMAL, SAFE_MODE and FILESYSTEM, which is the standard
case. But the new logic also allows other reset_mode values (eg
BOOTLOADER) to run boot.py and main.py.
Signed-off-by: Damien George <damien@micropython.org>
When disabled the bootloader is entered via a direct jump. When enabled
the bootloader is entered via a system reset then a jump. It's enabled by
default to retain the existing behaviour, which is the recommended way.
Signed-off-by: Damien George <damien@micropython.org>
Improvements made:
- PSRAM support for S2
- partition definition for 16MiB flash
- correct ADC and DAC pins
- correct GPIO and IRQ pins
- S3 components in CMakeLists
Based on original commit made by Seon Rozenblum aka @UnexpectedMaker.
Signed-off-by: Damien George <damien@micropython.org>
Any code running on core1 should be stopped on soft-reset (the GC heap is
reset so if code continues to run on core1 it will see corrupt memory).
Signed-off-by: Damien George <damien@micropython.org>
So a lock can be acquired on one Python thread and then released on
another. A test for this is added.
Signed-off-by: Damien George <damien@micropython.org>
Because vPortCleanUpTCB runs on the FreeRTOS idle task and cannot execute
any VM or runtime related code like freeing memory.
Signed-off-by: Damien George <damien@micropython.org>
This fixes a bug where double arguments on a 32-bit architecture would not
be passed correctly because they only had 4 bytes of storage (not 8). It
also fixes a compiler warning/error in return_ffi_value on certian
architectures: array subscript 'double[0]' is partly outside array bounds
of 'ffi_arg[1]' {aka 'long unsigned int[1]'}.
Fixes issue #7064.
Signed-off-by: Damien George <damien@micropython.org>
