[Ovmsdev] Firmware size approaching 4 MB limit
Michael Geddes
frog at bunyip.wheelycreek.net
Tue Dec 9 08:02:47 HKT 2025
One of the things missing is the bms averaging stuff. I started it but a
house move and stuff got in the way... but yeah if someone wants to try
I'll get onto that bit!
//.
On Tue, 9 Dec 2025, 01:04 Michael Balzer via OvmsDev, <
ovmsdev at lists.openvehicles.com> wrote:
> This is the growth over a selection of main releases:
>
> Date Size Version
> 2018-04-08 2100352 3.1.003/ovms3.bin
> 2018-04-17 2111536 3.1.004/ovms3.bin
> 2018-05-01 2172176 3.1.005/ovms3.bin
> 2018-05-20 2247760 3.1.006/ovms3.bin
> 2018-06-18 2311072 3.1.007/ovms3.bin
> 2018-08-18 2386640 3.1.009/ovms3.bin
> 2018-11-04 2503744 3.1.011/ovms3.bin
> 2019-05-12 2933840 3.2.002/ovms3.bin
> 2020-08-04 2943440 3.2.014/ovms3.bin
> 2020-09-02 2957216 3.2.015/ovms3.bin
> 2021-03-05 3189808 3.2.016/ovms3.bin
> 2021-09-29 3309536 3.2.017/ovms3.bin
> 2021-11-22 3318000 3.2.018/ovms3.bin
> 2021-11-22 3367696 3.3.001/ovms3.bin
> 2022-03-07 3396208 3.3.002/ovms3.bin
> 2022-09-03 3406816 3.3.003/ovms3.bin
> 2024-03-23 3675344 3.3.004/ovms3.bin
> 2025-07-18 3895696 3.3.005/ovms3.bin
>
>
>
>
> So extending the partition size to 6 MB will buy us quite some time.
>
> Regarding Javascript/DBC vehicles, Michael Geddes' work on this is quite
> advanced, and really needs some tester now trying to implement an actual
> vehicle, to see what's missing.
>
> Regards,
> Michael
>
>
> Am 08.12.25 um 07:01 schrieb Mark Webb-Johnson via OvmsDev:
>
> Michael, Carsten,
>
> I think that if targeting things to cull, we would need to be balance size
> vs importance. For example, the RE tools mentioned is just 10KB total size.
> By comparison TPMS is 9KB, and web server is 538KB.
>
> We learned with OVMS v2 that the biggest culprits in the long-run are
> always the vehicle modules. The core system stays pretty stable, but the
> space required for *all* vehicle modules grows with the number of vehicles
> supported.
>
> I don’t think we can simply switch to 32MB flash, as that would abandon
> the existing users. We would also need to source a standard certified 32MB
> module (which I don’t think Espressif offer themselves).
>
> Looking at the partition table:
>
> # OVMS 16MB flash ESP32 Partition Table
> # Name, Type, SubType, Offset, Size
> nvs, data, nvs, 0x9000, 0x4000
> otadata, data, ota, 0xd000, 0x2000
> phy_init, data, phy, 0xf000, 0x1000
> factory, app, factory, 0x10000, 4M
> ota_0, app, ota_0, , 4M
> ota_1, app, ota_1, , 4M
> store, data, fat, , 1M
>
>
> Assuming we could (and that is a big assumption given our older SDK)
> change that at runtime, then a possible migration path could be:
>
>
> 1. Have our code support both old and new partition table formats, and
> refuse to update to old format if firmware > 4MB. Get that code out into
> the hands of users.
> 2. Provide a migration tool for partition table:
> 1. Copy running code to factory (from ota_0 or ota_1, whichever is
> current).
> 2. Reboot
> 3. Change partition table (most likely replacing the entire table
> with a binary blob of the new format)
> 1. factory 4MB -> ota_0 same offset, 6MB size
> 2. ota_0 -> ota_1 6MB offset, 6MB size
> 4. Change boot to ota_0.
> 5. Reboot
> 3. Liase with factory so new modules use new partition format (and
> ship with firmware that supports it).
> 4. Wait a reasonable time for users to update before releasing any
> firmware > 4MB.
>
>
> That would work more similarly to other more modern ESP frameworks which
> don’t bother with ‘factory’. It would allow us another 50% expansion. But
> it does run the risk of bricking (requiring espflash to recover) during the
> process.
>
> But longer-term, the solution to me seems to be to allow the vehicle
> module code to overlay - so only the single vehicle you choose is loaded.
> And (absent any dynamic linking of modular code in freertos), the only
> straightforward way of doing that I know of is migrating vehicle support to
> Javascript (which comes along with a host of other advantages - most
> notably not having to be a C++ embedded developer to add/refine vehicle
> support).
>
> Regards, Mark.
>
> On 7 Dec 2025, at 4:39 PM, Carsten Schmiemann via OvmsDev
> <ovmsdev at lists.openvehicles.com> <ovmsdev at lists.openvehicles.com> wrote:
>
> Hi Michael,
>
> It was to be expected that we would eventually run out of flash storage.
> That’s why I would immediately question whether we should detach ourselves
> from components that aren’t really being used. We could even start a survey
> or something like that.
>
> For example, the RE tools — the idea behind them is great, but without
> documentation they’re not easy to use, and every time I tried to work with
> them, it just resulted in crashes.
>
> Then there’s the question of who actually uses Telnet, SSH, the Duktape
> framework, the DBC parser, OBD2ECU, or CANopen (yes, the Twizy integration
> is the only one that uses it).
>
> All great ideas, but in the end, how many users really make use of them?
> The fewer active components we have to maintain, the ‘easier’ it would
> also be to port the code to a more current ESP-IDF version — and that would
> bring significant benefits such as improved networking features, including
> firewall capabilities and a much more stable switching between LTE and
> Wi-Fi. I’ve looked at llanges attempts and it’s extremely tough.
>
> As an example, in my own custom firmware builds, I don’t enable the
> components (and of course not all vehicles, so not 100 percent
> representative) mentioned above. This requires small modifications in the
> code because, for example, the ESP logger is missing but referenced in
> another file, etc. But my firmware file is only about 2.8 MB.
>
> Just my 2 cents
> Carsten
>
> Am 07.12.2025 um 08:57 schrieb Michael Balzer via OvmsDev
> <ovmsdev at lists.openvehicles.com> <ovmsdev at lists.openvehicles.com>:
>
> FYI: use `make size-components` to create a report on all component sizes
> (`make size-files` for source file level).
>
> Unsurprisingly the webserver is on top, even with all assets precompressed
> already.
>
>
> *Top 10 components:*
>
> Per-archive contributions to ELF file:
> Archive File DRAM .data & .bss IRAM Flash code & rodata
> Total
> libovms_webserver.a 0 255 0 134342 399846
> 534443
> libstdc++.a 149 5640 0 141045 72513
> 219347
> libmain.a 15 2104 0 139216 40086
> 181421
> libduktape.a 0 0 0 141641 20367
> 162008
> libvehicle_renaulttwizy. 0 29 0 86517 75357
> 161903
> libc-psram-workaround.a 1854 66 18391 118283 10943
> 149537
> liblwip.a 17 3873 0 118366 16722
> 138978
> libnet80211.a 938 9042 10475 92339 21900
> 134694
> libmbedtls.a 100 560 76 107079 26785
> 134600
> libvehicle_vweup.a 8 8 0 60846 43432
> 104294
>
>
> *Vehicles:*
>
> Per-archive contributions to ELF file:
> Archive File DRAM .data & .bss IRAM Flash code & rodata
> Total
> libvehicle_renaulttwizy. 0 29 0 86517 75357
> 161903
> libvehicle_vweup.a 8 8 0 60846 43432
> 104294
> libvehicle_mgev.a 156 26 0 47756 33998
> 81936
> libvehicle_smarteq.a 82 15 0 59267 19527
> 78891
> libvehicle_smarted.a 0 9 0 48481 28801
> 77291
> libvehicle_renaultzoe_ph 4 10 0 44622 29564
> 74200
> libvehicle.a 0 68 0 57735 12062
> 69865
> libvehicle_bmwi3.a 0 2 0 33370 14357
> 47729
> libvehicle_minise.a 9432 2 0 35360 2210
> 47004
> libvehicle_hyundai_ioniq 176 7 0 32921 13425
> 46529
> libvehicle_nissanleaf.a 0 3 0 35491 8941
> 44435
> libvehicle_kiasoulev.a 240 9 0 32508 5473
> 38230
> libvehicle_kianiroev.a 108 7 0 24070 4006
> 28191
> libvehicle_mitsubishi.a 0 5 0 21645 3893
> 25543
> libvehicle_boltev.a 0 5 0 15999 7864
> 23868
> libvehicle_niu_gtevo.a 4 12 0 18248 3733
> 21997
> libvehicle_maxus_edelive 156 3 0 10713 7477
> 18349
> libvehicle_renaultzoe.a 0 6 0 14828 2859
> 17693
> libvehicle_maxus_euniq56 156 3 0 8363 6840
> 15362
> libvehicle_voltampera.a 0 5 0 13221 1932
> 15158
> libvehicle_hyundai_ioniq 0 3 0 11081 3191
> 14275
> libvehicle_teslaroadster 0 6 0 10367 2238
> 12611
> libvehicle_thinkcity.a 0 3 0 6114 3449
> 9566
> libvehicle_jaguaripace.a 0 8 0 5445 3941
> 9394
> libvehicle_fiatedoblo.a 0 2 0 4262 2126
> 6390
> libvehicle_teslamodels.a 0 2 0 5361 948
> 6311
> libvehicle_toyotarav4ev. 0 2 0 5023 1255
> 6280
> libvehicle_maxus_t90.a 0 3 0 2567 2204
> 4774
> libvehicle_byd_atto3.a 0 2 0 3503 947
> 4452
> libvehicle_energica.a 0 1 0 3319 880
> 4200
> libvehicle_demo.a 0 2 0 3205 795
> 4002
> libvehicle_maxus_euniq6. 0 2 0 2470 1182
> 3654
> libvehicle_fiat500.a 0 2 0 2838 732
> 3572
> libvehicle_zombie_vcu.a 0 4 0 1882 1259
> 3145
> libvehicle_mercedesb250e 0 2 0 2113 955
> 3070
> libvehicle_zeva.a 0 2 0 2209 688
> 2899
> libvehicle_dbc.a 0 2 0 1278 1395
> 2675
> libvehicle_cadillac_c2_c 0 7 0 1293 1105
> 2405
> libvehicle_maple60s.a 0 2 0 1416 698
> 2116
> libvehicle_chevrolet_c6_ 0 2 0 1053 1049
> 2104
> libvehicle_obdii.a 0 2 0 957 1007
> 1966
> libvehicle_teslamodel3.a 0 2 0 458 713
> 1173
> libvehicle_none.a 0 2 0 418 684
> 1104
> libvehicle_track.a 0 2 0 416 680
> 1098
>
>
> Regards,
> Michael
>
>
> Am 06.12.25 um 10:33 schrieb Michael Balzer via OvmsDev:
>
> Everyone,
>
> with the latest vehicle additions, the firmware size has now grown to
> 4,015,328 bytes in build 3.3.005-485-gc4664881.
>
> Our flash partitioning scheme is currently designed to provide three
> firmware partitions (factory, ota_0 & ota_1) of 4MB = 4,194,304 bytes each.
>
> So we've now got 178,976 bytes = ~4% left.
>
> Options beyond the 4 MB limit:
>
> a) split features, e.g. vehicle support, into two or more builds
>
> b) repartition into two firmware partitions of 6 MB each, reusing the
> factory partition for OTA
>
> c) switch to an ESP32 WROOM module with 32 MB flash (possible?)
>
> We've got some time left, new vehicles normally don't need that much
> space, I just wanted to raise awareness.
>
> Regards,
> Michael
>
>
> _______________________________________________
> OvmsDev mailing listOvmsDev at lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> --
> Michael Balzer * Am Rahmen 5 * D-58313 Herdecke <https://www.google.com/maps/search/Am+Rahmen+5+*+D-58313+Herdecke?entry=gmail&source=g>
> Fon 02330 9104094 * Handy 0176 20698926
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
>
> _______________________________________________
> OvmsDev mailing listOvmsDev at lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> --
> Michael Balzer * Am Rahmen 5 * D-58313 Herdecke <https://www.google.com/maps/search/Am+Rahmen+5+*+D-58313+Herdecke?entry=gmail&source=g>
> Fon 02330 9104094 * Handy 0176 20698926
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20251209/07ec4630/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wxu1FytkV5ZAdQlY.png
Type: image/png
Size: 19448 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20251209/07ec4630/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wxu1FytkV5ZAdQlY.png
Type: image/png
Size: 19448 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20251209/07ec4630/attachment-0003.png>
More information about the OvmsDev
mailing list