bricks/ev3: use .elf instead of uImage

[dlech]

Replace creating a uImage with using the .elf file directly for the EV3 firmware. This simplifies the build process and avoids the need for u-boot-tools. U-Boot already knows how to load the .elf file, so we can use it directly by using bootelf instead of bootm (this change was made in the pybricks/v2.0.0 release of u-boot).

In order to keep the size of the .elf file small, we do not enable -ffunction-sections and -fdata-sections for the EV3 firmware. This avoids the large tables of section names that are generated by these flags, which would otherwise increase the size of the .elf file by nearly 200 kB. The .elf file is still a bit larger than the uImage because of a bit more overhead, but only by less than 4kB.

[github-actions]

Download the artifacts for this pull request:

• pr_number.zip
• mpy-cross.zip
• nxt-firmware-build-3887-gitd4dfeec7.zip
• cityhub-firmware-build-3887-gitd4dfeec7.zip
• ev3-firmware-build-3887-gitd4dfeec7.zip
• movehub-firmware-build-3887-gitd4dfeec7.zip
• technichub-firmware-build-3887-gitd4dfeec7.zip
• essentialhub-firmware-build-3887-gitd4dfeec7.zip
• primehub-firmware-build-3887-gitd4dfeec7.zip

[coveralls]

coverage: 57.091%. remained the same
when pulling d5a98d1 on dlech:ev3-elf-firmware
into 52a2c62 on pybricks:master.

[ArcaneNibble]

avoids the large tables of section names that are generated by these flags

You should be able to fix this with an appropriate linker script, which can also be used to keep important functions so that they are not dropped. I can look into this later if we are really trying to keep code sizes down.

[dlech]

I can look into this later if we are really trying to keep code sizes down.

Thanks, but I'm happy with how it turned out. -ffunction-sections creates a separate .text.function_name section for every single function, so we ended up with several thousand sections. When I turned off that option, we now just have the most basic section list we can have. So I don't think there is really any more to gain here. We have plenty of flash and RAM on EV3, so a little bit extra doesn't matter. The extra 180kB from the section tables was about 1/3 of the total .elf file size though, so seemed a bit much.

[BertLindeman]

My stupid mistake. Must have used the wrong sensorport (not S1)
All is fine.
Sorry..

installed ev3 firmware from build 3888 at git2c7a38e7. No REPL.
One step back:
installed ev3 firmware from build 3887 at gitd4dfeec7. REPL OK.

Somewhere there is something different between these two builds.

EV3 debug console

EV3 initialization passed!
Booting EV3 EEprom Boot Loader

        EEprom Version:   0.60
        EV3 Flashtype:    N25Q128A13B

EV3 Booting system

Jumping to entry point at: 0xC1080000


U-Boot 2025.07-rc5-pybricks-2.0.0+ (Jul 05 2025 - 23:37:14 +0000)

DRAM:  64 MiB
Core:  10 devices, 10 uclasses, devicetree: separate
MMC:   da830-mmc: 0
Loading Environment from nowhere... OK
In:    serial@10c000
Out:   serial@10c000
Err:   serial@10c000
Autoboot in 0 seconds - press 'l' to stop...
Card did not respond to voltage select! : -110
SF: Detected n25q128a13 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
device 0 offset 0x50000, size 0x100000
SF: 1048576 bytes @ 0x50000 Read: OK
Pybricks MicroPython ci-build-3887-v3.6.1-192-gd4dfeec7 on 2025-07-05; MINDSTORMS EV3 Brick with TI Sitara AM1808

[EDIT] Maybe this should be added to issue 2256