The resulting `firmware.zip` file is self contained with everything needed
to deploy the firmware, eg over SE UART.
Signed-off-by: Damien George <damien@micropython.org>
Most extmod network drivers were being defined on a per-port basis,
duplicating code and making enabling a driver on a new port harder.
This consolidates extmod driver declarations and removes the existing
per-port definitions of them.
This commit has been verified to be a no-op in terms of firmware change.
Signed-off-by: Andrew Leech <andrew.leech@planetinnovation.com.au>
Previously MicroPython ports would linker-wrap dcd_event_handler
in order to schedule the USB task callback to run when needed.
TinyUSB 0.16 added proper support for an event hook to do the
same thing without the hacky linker wrapping.
This work was funded through GitHub Sponsors.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
This commit renames the NORETURN macro, indicating to the compiler
that a function does not return, into MP_NORETURN to maintain the same
naming convention of other similar macros.
To maintain compaitiblity with existing code NORETURN is aliased to
MP_NORETURN, but it is also deprecated for MicroPython v2.
This changeset was created using a similar process to
decf8e6a8b ("all: Remove the "STATIC"
macro and just use "static" instead."), with no documentation or python
scripts to change to reflect the new macro name.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
This is only a surface level refactor, some deeper refactoring would be
possible with (for example) the SDIO interface in mimxrt and stm32, or the
BTHCI interface which is is similar on supported ports. But sticking to
cases where the macros are the same across all ports.
This work was funded through GitHub Sponsors.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
To match the instruction length, so the DFS is restored to the XIP value
after an erase or write (due to the final wait WIP).
Signed-off-by: Damien George <damien@micropython.org>
Now raises an exception if the pin doesn't support the alternate function
unit number and line type, eg UART0_TX (previously it only checked the
peripheral).
Signed-off-by: Damien George <damien@micropython.org>
Unlike HWSEM, the MHU IRQ can wake up cores from low-power modes, making it
better suited for notifying remote cores. Note that no special function is
required to wake up a remote core—the act of sending a message alone will
notify it.
Signed-off-by: iabdalkader <i.abdalkader@gmail.com>
This channel can be used to communicate (pass messages) between the M55
cores in the RTSS. Currently it's only used to notify the cores.
Signed-off-by: iabdalkader <i.abdalkader@gmail.com>
The right service call to get UID is SERVICES_system_get_eui_extension
which returns an 8 bytes UID.
Signed-off-by: iabdalkader <i.abdalkader@gmail.com>
The byte order (endianness) seems to be swapped when read in 8D-8D-8D in
XIP mode, for most flashes, with the exception of MX which seems to swap
half-words.
This commit adds a flash setting to allow parts to enable half-word swap
when data is written, to fix this issue. By default, only endianness is
fixed.
Tested with both MX and ISSI parts on AE3, flash test and simple file
write/read.
Signed-off-by: iabdalkader <i.abdalkader@gmail.com>
The OSPI controller supports concurrent direct/XIP accesses, there's no
need to disable XIP on direct access. In addition to improving the
performance, this change lays the groundwork for supporting access by
the HP and HE cores simultaneously.
Signed-off-by: iabdalkader <i.abdalkader@gmail.com>
This change increases XIP read speed to ~30Mbytes/s at 50MHz DDR:
- Enable continuous mode.
- Remove hard-coded settings.
- Set XIP continuous mode timeout.
The prefetch remains disabled. Although enabling the prefetch gives the
best performance for the CPU in XIP mode, it must be disabled when the NPU
accesses the OSPI flash.
Signed-off-by: iabdalkader <i.abdalkader@gmail.com>
Leaving this pin low in combination with the default EM settings enables
flash protection for the EM flash.
Signed-off-by: iabdalkader <i.abdalkader@gmail.com>
The default dummy cycles may not match the actual flash frequency supported
by a certain board. For example, the MX chip uses 20 dummy cycles by
default which supports up to 200MHz DDR, but the maximum frequency
supported by the AE3 board is 50MHz DDR. So the dummy cycles for this
board can be as low as 6. It's important to set the correct dummy cycles,
as it results in doubling the XIP read speed, in the case of the AE3 board.
Signed-off-by: iabdalkader <i.abdalkader@gmail.com>
This commit enables detecting the flash device in runtime, and uses the
settings of the detected device instead of board-defined flash settings.
Signed-off-by: iabdalkader <i.abdalkader@gmail.com>
