Reduce firmware size on gemma m0, trinket m0

[jepler]

this also includes weblate's commit from #3229 that put it over the edge.

[jepler]

I first noticed this on the weblate PR but it's affecting the main branch already as well.

[jepler]

Failing main branch build: https://github.com/adafruit/circuitpython/runs/927877015?check_suite_focus=true

[jerryneedell]

Is it really necessary to only make the change for these translations? Why not just do it for all languages?

[dhalbert]

Is it really necessary to only make the change for these translations? Why not just do it for all languages?

The inline limit change makes the code slower, so if we can avoid this some of the time, it's probably better.

[jerryneedell]

Is it really necessary to only make the change for these translations? Why not just do it for all languages?

The inline limit change makes the code slower, so if we can avoid this some of the time, it's probably better.

Thanks. That's what i figured. I just hope we never run into issues that only occur in these translations!

[tannewt]

We could switch to GCC10 instead. I think we have everything in-place to do it.

[dhalbert]

I've uploaded the preview gcc10 toolchain from arm here:

 aws s3 ls s3://adafruit-circuit-python
                           PRE adabot/
                           PRE bin/
2019-04-16 19:02:28     103853 CircuitPython_Repo_header_logo.png
2017-11-15 23:05:07   65011116 gcc-arm-embedded_6-2017q2-2~trusty1_amd64.deb
2018-01-05 00:32:54   65541900 gcc-arm-embedded_7-2017q4-1~trusty3_amd64.deb
2018-07-25 17:40:07   63038916 gcc-arm-embedded_7-2018q2-1~trusty1_amd64.deb
2018-11-26 13:37:45   64502044 gcc-arm-embedded_7-2018q2-1~xenial1_amd64.deb
2020-07-30 14:00:40  155720620 gcc-arm-none-eabi-10-2020-q2-preview-x86_64-linux.tar.bz2
2019-12-17 17:29:27  116802378 gcc-arm-none-eabi-9-2019-q4-major-x86_64-linux.tar.bz2
2018-11-16 17:30:34        669 index.html
2019-01-23 14:10:12       9411 list.js
2017-04-27 16:50:27      20480 update-bootloader-v1.20.0.uf2

[dhalbert]

@jepler Did you see the discussion on dropping bitbangio on tiny M0 builds to make space and some mild refactoring it would need?

[jepler]

@dhalbert bitbangio is already disabled on those ports, it's only in FULL_BUILD.

Looks like trinket_m0 still didn't fit with these changes. Weird, it passed locally. Did I fail to build with the language I intended?

There were also some spurious-or-preexisting failures of xtensa:

FileExistsError: [Errno 17] File exists: '/opt/hostedtoolcache/Python/3.8.5/x64/bin/python' -> '/home/runner/work/circuitpython/circuitpython/.idf_tools/python_env/idf4.2_py3.8_env/bin/python'

[dhalbert]

This command will print the routine sizes in the .elf file, sorted with largest first:

arm-none-eabi-nm --print-size --size-sort --reverse-sort --radix=d firmware.elf

The smallest builds still have pulseio enabled, which is substantial. They also have transcendental functions enabled in math, which are also fairly large. We could knock out some of the transcendental functions with NotImplementedError.

[dhalbert]

Setting SUPEROPT_VM = 0 saves 300 bytes on Trinket. Supposed this slows down the interpreter by 20% (according to comment in py.mk. We could do this only on the translations that are overflowing.

[dhalbert]

rtc is also enabled on all builds. It uses 1556 bytes on trinket_m0.
pulseio uses 5888 bytes.
Dropping math frees 8296 bytes. We woudn't drop it all, but dropping larger functions would help a lot. Some of the lesser-used functions are already dropped by an existing flag setting.

[deshipu]

math is kinda useful for its sqrt and trigonometric functions. I use trinket m0 in one of my robots, and I would need to make a custom build for it that contains the math module.

I think that before we start dropping things (I know we have already started), we should think about the actual use cases we want supported. For example, pulseio is required for IRremote, and I think that gemma m0 and trinket m0 are perfect for that.

[jepler]

        # Normally different language builds are all done based on the same set of compiled sources.
        # But sometimes a particular language needs to be built from scratch, if, for instance,
        # CFLAGS_INLINE_LIMIT is set for a particular language to make it fit.
        clean_build_check_result = subprocess.run(
            "make -C ../ports/{port} TRANSLATION={language} BOARD={board} check-release-needs-clean-build -j {cores} | fgrep 'RELEASE_NEEDS_CLEAN_BUILD = 1'".format(
                port = board_info["port"], language=language, board=board, cores=cores),
            shell=True, stdout=subprocess.PIPE, stderr=subprocess.STDOUT)

I don't see any evidence of RELEASE_NEEDS_CLEAN_BUILD actually being set. Does this mean that we're not actually building these translations with the expected CFLAGS?

[dhalbert]

I don't see any evidence of RELEASE_NEEDS_CLEAN_BUILD actually being set. Does this mean that we're not actually building these translations with the expected CFLAGS?

That sounds like a bug! But I wonder why it worked?? Could you try a commit to add that?

[dhalbert]

I will add RELEASE_NEEDS_CLEAN_BUILD various places, and see what happens. Also I have an idea about the esp-idf builds: I will change the cache tag key.

[dhalbert]

@jepler the only failure was an S3 upload failure, unrelated to builds, so looks good for now