[Ovmsdev] Firmware size approaching 4 MB limit
Michael Balzer
dexter at expeedo.de
Tue Dec 9 01:04:41 HKT 2025
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> 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>:
>>>
>>> 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 list
>>>> OvmsDev at lists.openvehicles.com
>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>
>>> --
>>> Michael Balzer * Am Rahmen 5 * D-58313 Herdecke
>>> 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 list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
--
Michael Balzer * Am Rahmen 5 * D-58313 Herdecke
Fon 02330 9104094 * Handy 0176 20698926
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20251208/6650f70c/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/20251208/6650f70c/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20251208/6650f70c/attachment-0001.sig>
More information about the OvmsDev
mailing list