GitLab

This patch allows executing .mpy files (including native ones) directly on
a target, eg a board over a serial connection.  So there's no need to copy
the file to its filesystem to test it.

For example:

    $ mpy-cross foo.py
    $ pyboard.py foo.mpy

- Corrected pin assignments and checked with CubeMX.
- Added additional I2C and UARTs.
- Added Ethernet interface definitions with lwIP and SSL support (but
  Ethernet is currently unsupported on H7 MCUs so not fully enabled).

- Removed remarks on DFU/OCD in mpconfigboard.h because deploy-stlink works
  fine too.
- Added more UARTs, I2C, corrected SPI, CAN, etc; verified against CubeMX.
- Adapted pins.csv to remove errors, add omissions, etc. according to
  NUCLEO-144 User Manual.
- Changed linker file stm32f767.ld to reflect correct size of the Flash.
- Tested with LAN and SD card.

The Nucleo board does not have an SD card slot but does have the requisite
pins next to each other and labelled, so provide the configuration for
convenience.

This example will now work on all ports with networking and ssl support,
with both axtls and mbedtls.

This makes sure tinytest.o is rebuilt if any of its dependencies change.

This makes the loading of viper-code-with-relocations a bit neater and
easier to understand, by treating the rodata/bss like a special object to
be loaded into the constant table (which is how it behaves).

See issues #3220 and #3710.

So accessing the seek offset (at the C level) doesn't cause an
OverflowError on 32-bit targets.

Because MICROPY_ALLOC_PATH_MAX is only 128 for this port.

Because CPython 3.8.0 now produces different output:
- basics/parser.py: CPython does not allow '\\\n' as input.
- import/import_override: CPython imports _io.

Because in network_wiznet5k the TX/RX buffers are set to 16k each when in
MACRAW mode, which is used with lwIP.

Enabling WIZCHIP_USE_MAX_BUFFER will make the TX/RX buffers the maximum
available size, for use with MACRAW mode.

We don't want to add a feature flag to .mpy files that indicate float
support because it will get complex and difficult to use.  Instead the .mpy
is built using whatever precision it chooses (float or double) and the
native glue API will convert between this choice and what the host runtime
actually uses.

So they can be built as dynamic native modules, as well as existing static
native modules.

This commit adds a new tool called mpy_ld.py which is essentially a linker
that builds .mpy files directly from .o files.  A new header file
(dynruntime.h) and makefile fragment (dynruntime.mk) are also included
which allow building .mpy files from C source code.  Such .mpy files can
then be dynamically imported as though they were a normal Python module,
even though they are implemented in C.

Converting .o files directly (rather than pre-linked .elf files) allows the
resulting .mpy to be more efficient because it has more control over the
relocations; for example it can skip PLT indirection.  Doing it this way
also allows supporting more architectures, such as Xtensa which has
specific needs for position-independent code and the GOT.

The tool supports targets of x86, x86-64, ARM Thumb and Xtensa (windowed
and non-windowed).  BSS, text and rodata sections are supported, with
relocations to all internal sections and symbols, as well as relocations to
some external symbols (defined by dynruntime.h), and linking of qstrs.

Usage:

    mpy-tool.py -o merged.mpy --merge mod1.mpy mod2.mpy

The constituent .mpy files are executed sequentially when the merged file
is imported, and they all use the same global namespace.

These allow discovery of symbols by native code that is loaded dynamically.