Code size report:

Reference:  rp2/CMakeLists.txt: Require boards to define PICO_FLASH_SIZE_BYTES. [44a569b]
Comparison: rp2: Link nano.specs for newlib-nano. [merge of b353960]
  mpy-cross:    +0 +0.000% 
   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:    +0 +0.000% PYBV10
      esp32:    +0 +0.000% ESP32_GENERIC
     mimxrt:    +0 +0.000% TEENSY40
        rp2:  -132 -0.014% RPI_PICO_W[incl -704(bss)]
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS
  qemu rv32:    +0 +0.000% VIRT_RV32

Thanks for doing this. I like the idea, and on RPI_PICO_W it saves 1624 bytes of flash and 960 bytes of RAM.

But... the tests/net_hosted/ssl_verify_callback.py now locks up! Also tests/net_inet/asyncio_tls_open_connection_readline.py and probably others (these were just the first two I found). Note that some SSL tests still work though.

snprintf looks like it's being pulled in via some mbedTLS features

I guess that's the cause of the crashes? I tried adding shared/libc/printf.c to the build to fix that (and noted that MICROPY_USE_INTERNAL_PRINTF is already enabled) but that didn't fix it. I think anyway shared/libc/printf.c is already included in the cmake builds due to it being in MICROPY_SOURCE_EXTMOD.

I'd be interested to know exactly what mbedTLS is pulling in from libc that doesn't work with newlib-nano... it's a bit scary that we don't fully understand the dependencies here, especially since ports like stm32 work just fine with -nostdlib (libc is provided by our own code in shared/libc/ for that port).

@Gadgetoid I'm surprised you didn't see failures with your firmware when using nano.specs. Did you test SSL with your firmware?

But... the tests/net_hosted/ssl_verify_callback.py now locks up! Also tests/net_inet/asyncio_tls_open_connection_readline.py and probably others (these were just the first two I found). Note that some SSL tests still work though.

Oh wow, sorry! I didn't realise those tests weren't part of the default run-tests.py coverage!

I wonder if it's to do with linker placement instead of the actual features, there might be something that's now reading from cached flash. I'll do a bit of spelunking and try to figure this out.

I didn't realise those tests weren't part of the default run-tests.py coverage!

You mentioned you ran the tests on RPI_PICO2, which won't be able to run the network tests anyway.

Eventually octoprobe will help here, by just running all tests regardless. But also probably we should think about merging #16112; I use it all the time now (and is how I tested this PR).