[Ovmsdev] Firmware size approaching 4 MB limit
Mark Webb-Johnson
mark at webb-johnson.net
Wed Feb 25 09:58:37 HKT 2026
Michael,
> Only thing that was a bit odd: "ota" still showed the old layout directly after "ota partitions upgrade" (before the reboot). Probably cached, "ota partitions list" showed the new layout.
This is a simple fix. I will change tonight.
> Only thing odd with that was: "ota boot factory" failed correctly (did nothing), but did so without any error output. Not really a situation that will occur with normal users, so not really an issue.
I guess because it can no longer find the partition type ‘factory’.
Both these edge cases would not occur if a reboot was done after the partition upgrade.
> AFAICT "ota partitions upgrade" currently does not verify the system has booted from "factory" before allowing the operation -- I think that should be added as a safety measure.
I thought it did that check. Maybe not working?
const esp_partition_t *p = esp_ota_get_running_partition();
if ((p != NULL)&&(strcmp(p->label,"factory")!=0))
{
writer->puts("Error: Cannot upgrade partition table if running partition is not factory");
return;
}
p = esp_ota_get_boot_partition();
if ((p != NULL)&&(strcmp(p->label,"factory")!=0))
{
writer->puts("Error: Cannot upgrade partition table if boot partition is not factory");
return;
}
> I can take care of the web UI modifications if you like.
That would be helpful. I’m not really familiar with that code.
> OK, that's substantially more.
Here are the three partition table options:
Original (f12):
Label Type Subtype Offset (Hex) Size (Hex) Next (Hex) Offset (Dec) Size (Dec)
bootloader bootloader bootloader 0x0000 0x8000 8000 0 32768
partition_table partition_table partition_table 0x8000 0x1000 9000 32768 4096
nvs data nvs 0x9000 0x4000 D000 36864 16384
otadata data ota 0xD000 0x2000 F000 53248 8192
phy_init data phy 0xF000 0x1000 10000 61440 4096
factory app factory 0x10000 0x400000 410000 65536 4194304
ota_0 app ota_0 0x410000 0x400000 810000 4259840 4194304
ota_1 app ota_1 0x810000 0x400000 C10000 8454144 4194304
store data fat 0xC10000 0x100000 D10000 12648448 1048576
*unused* 0xD10000 0x2F0000 1000000 13697024 3080192
Current (12):
Label Type Subtype Offset (Hex) Size (Hex) Next (Hex) Offset (Dec) Size (Dec)
bootloader bootloader bootloader 0x0000 0x8000 8000 0 32768
partition_table partition_table partition_table 0x8000 0x1000 9000 32768 4096
nvs data nvs 0x9000 0x4000 D000 36864 16384
otadata data ota 0xD000 0x2000 F000 53248 8192
phy_init data phy 0xF000 0x1000 10000 61440 4096
ota_0 app ota_0 0x10000 0x600000 610000 65536 6291456
ota_1 app ota_1 0x610000 0x600000 C10000 6356992 6291456
store data fat 0xC10000 0x100000 D10000 12648448 1048576
*unused* 0xD10000 0x2F0000 1000000 13697024 3080192
Suggested (12, 7MB code, more store):
Label Type Subtype Offset (Hex) Size (Hex) Next (Hex) Offset (Dec) Size (Dec)
bootloader bootloader bootloader 0x0000 0x8000 8000 0 32768
partition_table partition_table partition_table 0x8000 0x1000 9000 32768 4096
nvs data nvs 0x9000 0x4000 D000 36864 16384
otadata data ota 0xD000 0x2000 F000 53248 8192
phy_init data phy 0xF000 0x1000 10000 61440 4096
ota_0 app ota_0 0x10000 0x700000 710000 65536 7340032
ota_1 app ota_1 0x710000 0x700000 E10000 7405568 7340032
store data fat 0xE10000 0x1F0000 1000000 14745600 2031616
It would make sense to resize store *now* if we are going to do it, but I am wary of requiring a factory reset. Also need to double check that the unused space at the end is truly unused. I am assuming the boot loader is in the first 32KB, but haven’t actually checked.
Looking at the third (resize store) arrangement, it would be moving 0xC10000-0xD0FFFF to 0xE10000-0xFFFFFF, which doesn’t seem to overlap. I wonder what simply copy that partition over (without reformatting flash) would do? Either corrupt the filesystem, ignore the extra space, or magically have the new space available to FAT? I suspect corruption. So, there is another (more complex) alternative:
Create a 2nd fat store partition (0xE10000-0xFFFFFF)
Format and mount that as FAT
Copy files from old to new
Unmount and drop the old store
Finish the rest of the partition upgrade
I suspect #3 would be the most complex step.
Or the store move and resize could be done first as a separate step.
Thoughts? Much more complex and risky...
Regards, Mark
> On 25 Feb 2026, at 6:00 AM, Michael Balzer <dexter at expeedo.de> wrote:
>
> Tested, works like a charm -- test log below.
>
> Only thing that was a bit odd: "ota" still showed the old layout directly after "ota partitions upgrade" (before the reboot). Probably cached, "ota partitions list" showed the new layout.
>
> I then tried rebooting into the old build to see if doing an OTA update from there would show any issues -- nope, works perfectly, installs to the other OTA partition and boots from there. So even after the upgrade, people can still run older firmware versions and perform normal OTA updates, the partitions are identified and located correctly by their label.
>
> Only thing odd with that was: "ota boot factory" failed correctly (did nothing), but did so without any error output. Not really a situation that will occur with normal users, so not really an issue.
>
> AFAICT "ota partitions upgrade" currently does not verify the system has booted from "factory" before allowing the operation -- I think that should be added as a safety measure.
>
> I can take care of the web UI modifications if you like.
>
> Regarding the product version 3.5 to distinguish 6MB capable modules, I think that's a neat & simple solution.
>
>> P.S. There is a possibility to do this another way to make even more flash space available, but that would mean moving the store partition right to the end of the 16MB flash, which is not so simple. Is 6MB really enough? Probably so if we can move to javascript vehicle modules, otherwise probably not (long-term).
>
> I see what you mean… I wasn't aware there is so much space left unused now. Like this, if partition alignment constraints allow?
>
> Label Type Subtype Address Size
> nvs data nvs 0x00009000 16 KB
> otadata data ota 0x0000d000 8 KB
> phy_init data phy 0x0000f000 4 KB
> ota_0 app ota_0 0x00010000 7.46875 MB (0x778000 bytes)
> ota_1 app ota_1 0x00788000 7.46875 MB (0x778000 bytes)
> store data fat 0x00f00000 1 MB
>
> OK, that's substantially more.
>
> Another option would be to allocate say 7 MB to each OTA partition (or even keep them at 6 MB) and add the remaining free capacity to store.
>
> Performing a config restore currently already fails due to lack of space when not done from a freshly cleared config, especially with some scripts & plugins installed.
>
> With custom JS vehicles being installed to /store, that will get a bit more tight yet, and maybe JS vehicles want to use /store for some extended data storage as well. So more capacity for /store would make sense, heading in that direction.
>
> Regards,
> Michael
>
>
>
> OVMS# ota
> Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/3; MODEM SIM7600
> Firmware: 3.3.005-711-g4feca695d/factory/edge (build idf v3.3.4-854-g9063c8662c Feb 24 2026 21:17:07)
> Partition type: v3-f12 (factory, ota1, ota2)
> Partition table: 0x8000
> Running partition: factory
> Boot partition: factory
> Factory image: 3.3.005-711-g4feca695d
> OTA_O image: 3.3.005-711-g4feca695d
> OTA_1 image: 3.3.005-704-g6a1fed98
>
> OVMS# ota partitions list
> Partition table:
> Label Type Subtype Address Size
> nvs data nvs 0x00009000 16 KB
> otadata data ota 0x0000d000 8 KB
> phy_init data phy 0x0000f000 4 KB
> factory app factory 0x00010000 4 MB
> ota_0 app ota_0 0x00410000 4 MB
> ota_1 app ota_1 0x00810000 4 MB
> store data fat 0x00c10000 1 MB
> Digest: cfe36765a6bfe1b802a2abd4ec9f6851 pass
>
> OVMS# ota partitions upgrade
> Upgrade partition table to new format (y/n): y
> 0x00009000 Skipping over data/nvs partition
> 0x0000d000 Skipping over data/ota partition
> 0x0000f000 Skipping over data/phy partition
> 0x00010000 Converted factory partition to 6MB OTA 0
> 0x00610000 Converted OTA 0 partition to 6MB OTA 1
> 0x00c10000 Moved data/fat partition up one position
> Recalculated MD5 checksum
> Clearing trailing old MD5 checksum record
> Erasing old partition table (4096 bytes at 0x00008000)...
> Writing new partition table (4096 bytes at 0x00008000)...
> Partition table upgraded successfully - reboot required
>
> OVMS# ota
> Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/3; MODEM SIM7600
> Firmware: 3.3.005-711-g4feca695d/factory/edge (build idf v3.3.4-854-g9063c8662c Feb 24 2026 21:17:07)
> Partition type: v3-f12 (factory, ota1, ota2)
> Partition table: 0x8000
> Running partition: factory
> Boot partition: factory
> Factory image: 3.3.005-711-g4feca695d
> OTA_O image: 3.3.005-711-g4feca695d
> OTA_1 image: 3.3.005-704-g6a1fed98
>
> OVMS# ota partitions list
> Partition table:
> Label Type Subtype Address Size
> nvs data nvs 0x00009000 16 KB
> otadata data ota 0x0000d000 8 KB
> phy_init data phy 0x0000f000 4 KB
> ota_0 app ota_0 0x00010000 6 MB
> ota_1 app ota_1 0x00610000 6 MB
> store data fat 0x00c10000 1 MB
> Digest: a0d94b1efa7f6d8852b44150db218e8d pass
>
> OVMS# module reset
> Resetting system...
>
> OVMS# ota
> Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/3; MODEM SIM7600
> Firmware: 3.3.005-711-g4feca695d/ota_0/edge (build idf v3.3.4-854-g9063c8662c Feb 24 2026 21:17:07)
> Partition type: v3-12 (ota1, ota2, no factory)
> Partition table: 0x8000
> Running partition: ota_0
> Boot partition: ota_0
> OTA_O image: 3.3.005-711-g4feca695d
>
> OVMS# ota partitions list
> Partition table:
> Label Type Subtype Address Size
> nvs data nvs 0x00009000 16 KB
> otadata data ota 0x0000d000 8 KB
> phy_init data phy 0x0000f000 4 KB
> ota_0 app ota_0 0x00010000 6 MB
> ota_1 app ota_1 0x00610000 6 MB
> store data fat 0x00c10000 1 MB
> Digest: a0d94b1efa7f6d8852b44150db218e8d pass
>
> OVMS# ota boot ?
> Usage: ota boot ota_0|ota_1
> ota_0 Boot from ota_0 image
> ota_1 Boot from ota_1 image
>
> OVMS# ota copy ?
> Usage: ota copy ota_0|ota_1
> ota_0 OTA copy ota_0 <to>
> ota_1 OTA copy ota_1 <to>
>
> OVMS# ota erase ?
> Usage: ota erase ota_0|ota_1
> ota_0 Erase ota_0 image
> ota_1 Erase ota_1 image
>
>
>
>
> Am 24.02.26 um 13:40 schrieb Mark Webb-Johnson:
>> OK, I have just committed this. The two new commands are:
>>
>> ota partitions list
>> ota partitions upgrade [-noconfirm]
>>
>> Rollback is via:
>>
>> wget http://api.openvehicles.com/firmware/ota/v3.1/main/partitions.bin
>> esptool.py -p <path-to-usb> write_flash 0x8000 partitions.bin
>>
>> General approach to manual upgrade:
>>
>> Upgrade to firmware supporting this feature (3.3.005-711-g4feca695 or later)
>> Copy running ota firmware to factory
>> Set to boot from flash and reboot
>> Use ‘ota partitions upgrade’ to upgrade
>> Reboot
>>
>> Items still to be addressed:
>>
>> Documentation (including rollback procedure).
>> Modify partitions.csv to use this new format (when ready for production).
>> Web interface (in particular concept of factory vs ota), if necessary (haven’t checked this).
>> OTA flash builds. We will need a way to support 6MB builds for those that can use them. I suggest to change GetOVMSProduct() to return v3.5 for these modules that are running this new 6MB capable partition table. Then on server we can build a production release final 4MB firmware including this support, and then use v3.5 tree to build future 6MB only builds. The ‘ota flash’ system would automatically support that and give people time to upgrade (as well as new users with 4MB partition modules for many months).
>> Investigate any simple way to make this a simple one-command (current ota->factory, boot factory, reboot, partitions upgrade, reboot).
>>
>> For the moment, please try this out and let me know if you find any problems. We can then decide on the items still to be addressed.
>>
>> Regards, Mark.
>>
>> P.S. There is a possibility to do this another way to make even more flash space available, but that would mean moving the store partition right to the end of the 16MB flash, which is not so simple. Is 6MB really enough? Probably so if we can move to javascript vehicle modules, otherwise probably not (long-term).
>>
>>> On Feb 23, 2026, at 12:27 AM, Michael Balzer <dexter at expeedo.de> <mailto:dexter at expeedo.de> wrote:
>>>
>>> Awesome :-)
>>>
>>> We need to update the user manual's firmware rescue guide (https://docs.openvehicles.com/en/latest/userguide/factory.html#flash-factory-firmware-via-usb) accordingly, so in case anything goes wrong, users can help themselves or get local help.
>>>
>>> The 4KB RAM overhead shouldn't be an issue I think, but we could add a free memory check and recommend switching to the "NONE" vehicle while performing the operation, if memory is too tight.
>>>
>>>> P.S. OVMS v2 had to fit in 96KB of flash ;-)
>>>
>>> …and 3328 bytes of RAM in total… so much for the "overhead" ;-)
>>>
>>> Regards,
>>> Michael
>>>
>>>
>>> Am 22.02.26 um 16:00 schrieb Mark Webb-Johnson:
>>>> I’ve made some progress with this:
>>>>
>>>> OVMS# ota status nocheck
>>>> Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/1
>>>> Firmware: 3.3.005-704-g6a1fed98-dirty/factory/edge (build idf v3.3.4-854-g9063c8662-dirty Feb 22 2026 22:28:00)
>>>> Partition type: v3-f12 (factory, ota1, ota2)
>>>> Partition table: 0x8000
>>>> Running partition: factory
>>>> Boot partition: factory
>>>> Factory image: 3.3.005-704-g6a1fed98-dirty
>>>> OTA_O image: 3.3.005-662-g1f318f04
>>>> OTA_1 image: 3.3.005-643-gdbec4a13
>>>>
>>>> OVMS# ota partitions list
>>>> Partition table:
>>>> Label Type Subtype Address Size
>>>> nvs data nvs 0x00009000 16 KB
>>>> otadata data ota 0x0000d000 8 KB
>>>> phy_init data phy 0x0000f000 4 KB
>>>> factory app factory 0x00010000 4 MB
>>>> ota_0 app ota_0 0x00410000 4 MB
>>>> ota_1 app ota_1 0x00810000 4 MB
>>>> store data fat 0x00c10000 1 MB
>>>> Digest: cfe36765a6bfe1b802a2abd4ec9f6851 pass
>>>>
>>>> ## Before upgrade, user needs to copy current OTA to FACTORY, set boot partition to FACTORY, then reboot
>>>> ## The upgrade process checks this and will refuse to upgrade unless that is the case
>>>>
>>>> OVMS# ota partitions upgrade
>>>> 0x00009000 Skipping over data/nvs partition
>>>> 0x0000d000 Skipping over data/ota partition
>>>> 0x0000f000 Skipping over data/phy partition
>>>> 0x00010000 Converted factory partition to 6MB OTA 0
>>>> 0x00610000 Converted OTA 0 partition to 6MB OTA 1
>>>> 0x00c10000 Moved data/fat partition up one position
>>>> Recalculated MD5 checksum
>>>> Clearing trailing old MD5 checksum record
>>>> Erasing old partition table (4096 bytes at 0x00008000)...
>>>> Writing new partition table (4096 bytes at 0x00008000)...
>>>> Partition table upgraded successfully - reboot required
>>>>
>>>> OVMS# ota partitions list
>>>> Partition table:
>>>> Label Type Subtype Address Size
>>>> nvs data nvs 0x00009000 16 KB
>>>> otadata data ota 0x0000d000 8 KB
>>>> phy_init data phy 0x0000f000 4 KB
>>>> ota_0 app ota_0 0x00010000 6 MB
>>>> ota_1 app ota_1 0x00610000 6 MB
>>>> store data fat 0x00c10000 1 MB
>>>> Digest: a0d94b1efa7f6d8852b44150db218e8d pass
>>>>
>>>> This is mostly implemented in a new ovms_partitions.{h,cpp} in ovms_ota component, with only minor extensions to ovms_ota itself. I have removed the ‘factory’ commands from ovms_ota if the new partition layout is detected at boot.
>>>>
>>>> One big ‘gotcha’ I found was that we need to set CONFIG_SPI_FLASH_WRITING_DANGEROUS_REGIONS_ABORT= and CONFIG_SPI_FLASH_WRITING_DANGEROUS_REGIONS_ALLOWED=y in our sdkconfig - otherwise the partition table cannot be re-flashed.
>>>>
>>>> The partition table must also be held in internal (not external SPI) RAM - which is about a 4KB overhead just for these checks.
>>>>
>>>> The usual app-flash still works (and now targets the first OTA at 0x0010000, rather than factory), so this approach seems feasible and workable now. Once we are happy with this, and have a production firmware supporting this layout, I can also provide a new partitions.bin to the factory for new units to ship with.
>>>>
>>>> I have a few minor enhancements to make: (a) add a ‘yes/no’ (like factory reset), (b) an option to load partition table in internal/external ram (internal only at the moment), and (c) some minor tidy-ups. I suggest then to just check it in with this basic manual functionality that can be experimented with. Absent any comments / suggestions, I should be able to commit this early in the coming week.
>>>>
>>>> Regards, Mark.
>>>>
>>>> P.S. OVMS v2 had to fit in 96KB of flash ;-)
>>>>
>>>>> On Jan 21, 2026, at 11:12 AM, Mark Webb-Johnson <mark at webb-johnson.net> <mailto:mark at webb-johnson.net> wrote:
>>>>>
>>>>> Michael,
>>>>>
>>>>> The links are very helpful.
>>>>>
>>>>> I have some time, and inclination to handle this (now that my new home build host is up and running and a make of OVMS from clean, with 32 cores and a fast SSD, is under 25 seconds).
>>>>>
>>>>> real 0m24.642s
>>>>> user 5m50.376s
>>>>> sys 0m38.276s
>>>>>
>>>>> We’ve already got the ‘ota copy’ command, so I will start with trying to work on manipulation of the partition table and improving the ‘ota status’ command to show partition table format and sizes.
>>>>>
>>>>> Regards, Mark.
>>>>>
>>>>>> On 11 Jan 2026, at 5:34 PM, Michael Balzer via OvmsDev <ovmsdev at lists.openvehicles.com> <mailto:ovmsdev at lists.openvehicles.com> wrote:
>>>>>>
>>>>>> Signed PGP part
>>>>>> On the migration tool for changing the partition table from a running application, we're (of course) not the first having that issue.
>>>>>>
>>>>>> If we're about to go that way, here is an implementation of the process:
>>>>>> Explanation: https://johnmu.com/2024-esp32-partition-update/
>>>>>> Source: https://github.com/softplus/Esp32Repartition
>>>>>> It's written for the Arduino IDE with the PlatformIO lib to create a UI, but the core function is straight forward and should be adaptable for us.
>>>>>>
>>>>>> The implementation allows for direct manipulations of the partition table, i.e. doesn't need a prepared table blob to flash.
>>>>>>
>>>>>> Using a prepared blob should be even more simple, basically just a matter of `spi_flash_erase_range()` & `spi_flash_write()` (→https://github.com/softplus/Esp32Repartition/blob/main/src/part_mgr.cpp#L297). We probably don't even need `getPartitionTableAddr()`, as our table is fixed at 0x8000.
>>>>>>
>>>>>> The code needed is small. When using a blob, the table in theory uses a full flash sector of 4096 bytes, but probably doesn't fill the whole sector.
>>>>>>
>>>>>> 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:
>>>>>>>
>>>>>>> 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.
>>>>>>> Provide a migration tool for partition table:
>>>>>>> Copy running code to factory (from ota_0 or ota_1, whichever is current).
>>>>>>> Reboot
>>>>>>> Change partition table (most likely replacing the entire table with a binary blob of the new format)
>>>>>>> factory 4MB -> ota_0 same offset, 6MB size
>>>>>>> ota_0 -> ota_1 6MB offset, 6MB size
>>>>>>> Change boot to ota_0.
>>>>>>> Reboot
>>>>>>> Liase with factory so new modules use new partition format (and ship with firmware that supports it).
>>>>>>> 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> <mailto: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> <mailto: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 <mailto: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 <mailto:OvmsDev at lists.openvehicles.com>
>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> OvmsDev mailing list
>>>>>>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> OvmsDev mailing list
>>>>>>> OvmsDev at lists.openvehicles.com <mailto: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 <mailto: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
>>>
>>
>
> --
> 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/20260225/8b9fcce2/attachment-0001.htm>
More information about the OvmsDev
mailing list