<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Tested, works like a charm -- test log below.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
I can take care of the web UI modifications if you like.<br>
<br>
Regarding the product version 3.5 to distinguish 6MB capable
modules, I think that's a neat & simple solution.<br>
<br>
<blockquote type="cite">
<div>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).</div>
</blockquote>
<br>
I see what you mean… I wasn't aware there is so much space left
unused now. Like this, if partition alignment constraints allow?<br>
<br>
<font face="monospace">Label Type Subtype Address
Size <br>
nvs data nvs 0x00009000 16 KB<br>
otadata data ota 0x0000d000 8 KB<br>
phy_init data phy 0x0000f000 4 KB<br>
ota_0 app ota_0 0x00010000 7.46875 MB (0x778000
bytes)<br>
ota_1 app ota_1 0x00788000 7.46875 MB</font><font
face="monospace"> (0x778000 bytes)</font><br>
<font face="monospace">store data fat 0x00f00000
1 MB</font><br>
<br>
OK, that's substantially more.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<br>
<font face="monospace">OVMS# ota<br>
Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/3; MODEM
SIM7600<br>
Firmware: 3.3.005-711-g4feca695d/factory/edge (build idf
v3.3.4-854-g9063c8662c Feb 24 2026 21:17:07)<br>
Partition type: v3-f12 (factory, ota1, ota2)<br>
Partition table: 0x8000<br>
Running partition: factory<br>
Boot partition: factory<br>
Factory image: 3.3.005-711-g4feca695d<br>
OTA_O image: 3.3.005-711-g4feca695d<br>
OTA_1 image: 3.3.005-704-g6a1fed98<br>
<br>
OVMS# ota partitions list <br>
Partition table:<br>
Label Type Subtype Address Size <br>
nvs data nvs 0x00009000 16 KB<br>
otadata data ota 0x0000d000 8 KB<br>
phy_init data phy 0x0000f000 4 KB<br>
factory app factory 0x00010000 4 MB<br>
ota_0 app ota_0 0x00410000 4 MB<br>
ota_1 app ota_1 0x00810000 4 MB<br>
store data fat 0x00c10000 1 MB<br>
Digest: cfe36765a6bfe1b802a2abd4ec9f6851 pass<br>
<br>
OVMS# ota partitions upgrade <br>
Upgrade partition table to new format (y/n): y<br>
0x00009000 Skipping over data/nvs partition<br>
0x0000d000 Skipping over data/ota partition<br>
0x0000f000 Skipping over data/phy partition<br>
0x00010000 Converted factory partition to 6MB OTA 0<br>
0x00610000 Converted OTA 0 partition to 6MB OTA 1<br>
0x00c10000 Moved data/fat partition up one position<br>
Recalculated MD5 checksum<br>
Clearing trailing old MD5 checksum record<br>
Erasing old partition table (4096 bytes at 0x00008000)...<br>
Writing new partition table (4096 bytes at 0x00008000)...<br>
Partition table upgraded successfully - reboot required<br>
<br>
OVMS# ota<br>
Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/3; MODEM
SIM7600<br>
Firmware: 3.3.005-711-g4feca695d/factory/edge (build idf
v3.3.4-854-g9063c8662c Feb 24 2026 21:17:07)<br>
Partition type: v3-f12 (factory, ota1, ota2)<br>
Partition table: 0x8000<br>
Running partition: factory<br>
Boot partition: factory<br>
Factory image: 3.3.005-711-g4feca695d<br>
OTA_O image: 3.3.005-711-g4feca695d<br>
OTA_1 image: 3.3.005-704-g6a1fed98<br>
<br>
OVMS# ota partitions list <br>
Partition table:<br>
Label Type Subtype Address Size <br>
nvs data nvs 0x00009000 16 KB<br>
otadata data ota 0x0000d000 8 KB<br>
phy_init data phy 0x0000f000 4 KB<br>
ota_0 app ota_0 0x00010000 6 MB<br>
ota_1 app ota_1 0x00610000 6 MB<br>
store data fat 0x00c10000 1 MB<br>
Digest: a0d94b1efa7f6d8852b44150db218e8d pass<br>
<br>
OVMS# module reset <br>
Resetting system...<br>
<br>
OVMS# ota<br>
Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/3; MODEM
SIM7600<br>
Firmware: 3.3.005-711-g4feca695d/ota_0/edge (build idf
v3.3.4-854-g9063c8662c Feb 24 2026 21:17:07)<br>
Partition type: v3-12 (ota1, ota2, no factory)<br>
Partition table: 0x8000<br>
Running partition: ota_0<br>
Boot partition: ota_0<br>
OTA_O image: 3.3.005-711-g4feca695d<br>
<br>
OVMS# ota partitions list <br>
Partition table:<br>
Label Type Subtype Address Size <br>
nvs data nvs 0x00009000 16 KB<br>
otadata data ota 0x0000d000 8 KB<br>
phy_init data phy 0x0000f000 4 KB<br>
ota_0 app ota_0 0x00010000 6 MB<br>
ota_1 app ota_1 0x00610000 6 MB<br>
store data fat 0x00c10000 1 MB<br>
Digest: a0d94b1efa7f6d8852b44150db218e8d pass<br>
<br>
OVMS# ota boot ?<br>
Usage: ota boot ota_0|ota_1<br>
ota_0 Boot from ota_0 image<br>
ota_1 Boot from ota_1 image<br>
<br>
OVMS# ota copy ? <br>
Usage: ota copy ota_0|ota_1<br>
ota_0 OTA copy ota_0 <to><br>
ota_1 OTA copy ota_1 <to><br>
<br>
OVMS# ota erase ?<br>
Usage: ota erase ota_0|ota_1<br>
ota_0 Erase ota_0 image<br>
ota_1 Erase ota_1 image</font><br>
<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">Am 24.02.26 um 13:40 schrieb Mark
Webb-Johnson:<br>
</div>
<blockquote type="cite"
cite="mid:D4A9565A-FC9F-47D5-A337-0A8AF24080F2@webb-johnson.net">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
OK, I have just committed this. The two new commands are:
<div><br>
</div>
<div>
<ul class="MailOutline">
<li>ota partitions list</li>
<li>ota partitions upgrade [-noconfirm]</li>
</ul>
</div>
<div><br>
</div>
<div>Rollback is via:</div>
<div><br>
</div>
<div>
<ul class="MailOutline">
<li>wget <a
href="http://api.openvehicles.com/firmware/ota/v3.1/main/partitions.bin"
moz-do-not-send="true" class="moz-txt-link-freetext">http://api.openvehicles.com/firmware/ota/v3.1/main/partitions.bin</a></li>
<li>esptool.py -p <path-to-usb> write_flash 0x8000
partitions.bin </li>
</ul>
<div><br>
</div>
<div>General approach to manual upgrade:</div>
<div><br>
</div>
<div>
<ol class="MailOutline">
<li>Upgrade to firmware supporting this feature
(3.3.005-711-g4feca695 or later)</li>
<li>Copy running ota firmware to factory</li>
<li>Set to boot from flash and reboot</li>
<li>Use ‘ota partitions upgrade’ to upgrade</li>
<li>Reboot</li>
</ol>
</div>
<div><br>
</div>
<div>Items still to be addressed:</div>
<div><br>
</div>
<div>
<ul class="MailOutline">
<li>Documentation (including rollback procedure).</li>
<li>Modify partitions.csv to use this new format (when ready
for production).</li>
<li>Web interface (in particular concept of factory vs ota),
if necessary (haven’t checked this).</li>
<li>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).</li>
<li>Investigate any simple way to make this a simple
one-command (current ota->factory, boot factory,
reboot, partitions upgrade, reboot).</li>
</ul>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Regards, Mark.</div>
<div><br>
</div>
<div>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).</div>
<div><br>
<blockquote type="cite">
<div>On Feb 23, 2026, at 12:27 AM, Michael Balzer
<a class="moz-txt-link-rfc2396E" href="mailto:dexter@expeedo.de"><dexter@expeedo.de></a> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8">
<div> Awesome :-)<br>
<br>
We need to update the user manual's firmware rescue
guide
(<a class="moz-txt-link-freetext"
href="https://docs.openvehicles.com/en/latest/userguide/factory.html#flash-factory-firmware-via-usb"
moz-do-not-send="true">https://docs.openvehicles.com/en/latest/userguide/factory.html#flash-factory-firmware-via-usb</a>)
accordingly, so in case anything goes wrong, users can
help themselves or get local help.<br>
<br>
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.<br>
<br>
<blockquote type="cite">
<div>P.S. OVMS v2 had to fit in 96KB of flash ;-)</div>
</blockquote>
<br>
…and 3328 bytes of RAM in total… so much for the
"overhead" ;-)<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 22.02.26 um 16:00
schrieb Mark Webb-Johnson:<br>
</div>
<blockquote type="cite"
cite="mid:D1C69B8E-43DC-4BDA-BBCF-5B0D11EB0B6C@webb-johnson.net">
<meta http-equiv="content-type"
content="text/html; charset=UTF-8">
I’ve made some progress with this:
<div><br>
</div>
<blockquote
style="margin: 0 0 0 40px; border: none; padding: 0px;">
<div><font face="Andale Mono">OVMS# ota status
nocheck</font></div>
<div><font face="Andale Mono">Hardware:
OVMS WIFI BLE BT cores=2 rev=ESP32/1</font></div>
<div><font face="Andale Mono">Firmware:
3.3.005-704-g6a1fed98-dirty/factory/edge (build
idf v3.3.4-854-g9063c8662-dirty Feb 22 2026
22:28:00)</font></div>
<div><font face="Andale Mono">Partition type:
v3-f12 (factory, ota1, ota2)</font></div>
<div><font face="Andale Mono">Partition table:
0x8000</font></div>
<div><font face="Andale Mono">Running partition:
factory</font></div>
<div><font face="Andale Mono">Boot partition:
factory</font></div>
<div><font face="Andale Mono">Factory image:
3.3.005-704-g6a1fed98-dirty</font></div>
<div><font face="Andale Mono">OTA_O image:
3.3.005-662-g1f318f04</font></div>
<div><font face="Andale Mono">OTA_1 image:
3.3.005-643-gdbec4a13</font></div>
<div><font face="Andale Mono"><br>
</font></div>
<div><span
style="font-family: "Andale Mono";">OVMS#
ota partitions list</span></div>
<div><font face="Andale Mono">Partition table:</font></div>
<div><font face="Andale Mono">Label Type
Subtype Address Size</font></div>
<div><font face="Andale Mono">nvs data
nvs 0x00009000 16 KB</font></div>
<div><font face="Andale Mono">otadata data
ota 0x0000d000 8 KB</font></div>
<div><font face="Andale Mono">phy_init data
phy 0x0000f000 4 KB</font></div>
<div><font face="Andale Mono">factory app
factory 0x00010000 4 MB</font></div>
<div><font face="Andale Mono">ota_0 app
ota_0 0x00410000 4 MB</font></div>
<div><font face="Andale Mono">ota_1 app
ota_1 0x00810000 4 MB</font></div>
<div><font face="Andale Mono">store data
fat 0x00c10000 1 MB</font></div>
<div><font face="Andale Mono">Digest:
cfe36765a6bfe1b802a2abd4ec9f6851 pass</font></div>
<div><font face="Andale Mono"><br>
</font></div>
<div><span
style="font-family: "Andale Mono";">##
Before upgrade, user needs to copy current OTA
to FACTORY, set boot partition to FACTORY, then
reboot</span></div>
<div><font face="Andale Mono">## The upgrade process
checks this and will refuse to upgrade unless
that is the case</font></div>
<div><span
style="font-family: "Andale Mono";"><br>
</span></div>
<div><font face="Andale Mono">OVMS# ota partitions
upgrade</font></div>
<div><font face="Andale Mono">0x00009000 Skipping
over data/nvs partition</font></div>
<div><font face="Andale Mono">0x0000d000 Skipping
over data/ota partition</font></div>
<div><font face="Andale Mono">0x0000f000 Skipping
over data/phy partition</font></div>
<div><font face="Andale Mono">0x00010000 Converted
factory partition to 6MB OTA 0</font></div>
<div><font face="Andale Mono">0x00610000 Converted
OTA 0 partition to 6MB OTA 1</font></div>
<div><font face="Andale Mono">0x00c10000 Moved
data/fat partition up one position</font></div>
<div><font face="Andale Mono">
Recalculated MD5 checksum</font></div>
<div><font face="Andale Mono"> Clearing
trailing old MD5 checksum record</font></div>
<div><font face="Andale Mono">Erasing old partition
table (4096 bytes at 0x00008000)...</font></div>
<div><font face="Andale Mono">Writing new partition
table (4096 bytes at 0x00008000)...</font></div>
<div><font face="Andale Mono">Partition table
upgraded successfully - reboot required</font></div>
<div><font face="Andale Mono"><br>
</font></div>
<div><font face="Andale Mono">OVMS# ota partitions
list</font></div>
<div><font face="Andale Mono">Partition table:</font></div>
<div><font face="Andale Mono">Label Type
Subtype Address Size</font></div>
<div><font face="Andale Mono">nvs data
nvs 0x00009000 16 KB</font></div>
<div><font face="Andale Mono">otadata data
ota 0x0000d000 8 KB</font></div>
<div><font face="Andale Mono">phy_init data
phy 0x0000f000 4 KB</font></div>
<div><font face="Andale Mono">ota_0 app
ota_0 0x00010000 6 MB</font></div>
<div><font face="Andale Mono">ota_1 app
ota_1 0x00610000 6 MB</font></div>
<div><font face="Andale Mono">store data
fat 0x00c10000 1 MB</font></div>
<div><font face="Andale Mono">Digest:
a0d94b1efa7f6d8852b44150db218e8d pass</font></div>
</blockquote>
<div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>The partition table must also be held in
internal (not external SPI) RAM - which is about a
4KB overhead just for these checks.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Regards, Mark.</div>
<div><br>
</div>
<div>P.S. OVMS v2 had to fit in 96KB of flash ;-)</div>
<div><br>
</div>
<div>
<blockquote type="cite">
<div>On Jan 21, 2026, at 11:12 AM, Mark
Webb-Johnson <a class="moz-txt-link-rfc2396E"
href="mailto:mark@webb-johnson.net"
moz-do-not-send="true"><mark@webb-johnson.net></a>
wrote:</div>
<br class="Apple-interchange-newline">
<div>
<meta http-equiv="content-type"
content="text/html; charset=UTF-8">
<div
style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Michael,
<div><br>
</div>
<div>The links are very helpful.</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<blockquote
style="margin: 0 0 0 40px; border: none; padding: 0px;">
<div>
<div><font face="American Typewriter">real<span
class="Apple-tab-span"
style="white-space: pre;"> </span>0m24.642s</font></div>
<div><font face="American Typewriter">user<span
class="Apple-tab-span"
style="white-space:pre"> </span>5m50.376s</font></div>
<div><font face="American Typewriter">sys<span
class="Apple-tab-span"
style="white-space: pre;"> </span>0m38.276s</font></div>
</div>
</blockquote>
<div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Regards, Mark.</div>
<div><br>
<blockquote type="cite">
<div>On 11 Jan 2026, at 5:34 PM,
Michael Balzer via OvmsDev <a
class="moz-txt-link-rfc2396E"
href="mailto:ovmsdev@lists.openvehicles.com" moz-do-not-send="true"><ovmsdev@lists.openvehicles.com></a>
wrote:</div>
<br class="Apple-interchange-newline">
<div>
<meta charset="UTF-8">
<div style="position: relative;">
<div
class="protected-part-7BD01625-5127-40F2-A5D3-0E6C4E74C73A"
style="padding-top: 0px; position: relative; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 18px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-line: none; text-decoration-thickness: auto; text-decoration-style: solid;">
<div
class="protected-title-7BD01625-5127-40F2-A5D3-0E6C4E74C73A"
style="position: absolute; margin-top: -5px; background-color: rgb(255, 255, 255); margin-left: 20px; font-weight: bold;">Signed
PGP part</div>
<div
class="protected-content-7BD01625-5127-40F2-A5D3-0E6C4E74C73A"
style="border: 3px solid rgb(204, 204, 204); padding: 16px 16px 16px 20px;">On
the migration tool for
changing the partition table
from a running application,
we're (of course) not the
first having that issue.<br>
<br>
If we're about to go that way,
here is an implementation of
the process:<br>
<ul>
<li>Explanation:<span
class="Apple-converted-space"> </span><a class="moz-txt-link-freetext"
href="https://johnmu.com/2024-esp32-partition-update/"
moz-do-not-send="true">https://johnmu.com/2024-esp32-partition-update/</a></li>
<li>Source:<span
class="Apple-converted-space"> </span><a class="moz-txt-link-freetext"
href="https://github.com/softplus/Esp32Repartition"
moz-do-not-send="true">https://github.com/softplus/Esp32Repartition</a></li>
</ul>
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.<br>
<br>
The implementation allows for
direct manipulations of the
partition table, i.e. doesn't
need a prepared table blob to
flash.<br>
<br>
Using a prepared blob should
be even more simple, basically
just a matter of
`spi_flash_erase_range()`
& `spi_flash_write()` (→<a
class="moz-txt-link-freetext"
href="https://github.com/softplus/Esp32Repartition/blob/main/src/part_mgr.cpp#L297"
moz-do-not-send="true">https://github.com/softplus/Esp32Repartition/blob/main/src/part_mgr.cpp#L297</a>).
We probably don't even need
`getPartitionTableAddr()`, as
our table is fixed at 0x8000.<br>
<br>
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.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am
08.12.25 um 07:01 schrieb
Mark Webb-Johnson via
OvmsDev:<br>
</div>
<blockquote type="cite"
cite="mid:1EAA8F91-A8E9-43D0-9705-CF40927F337A@webb-johnson.net">Michael,
Carsten,
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>Looking at the
partition table:</div>
<div><br>
</div>
<blockquote
style="margin: 0px 0px 0px 40px; border: medium; padding: 0px;">
<div>
<div><font
face="Andale Mono">#
OVMS 16MB flash
ESP32 Partition
Table</font></div>
<div><font
face="Andale Mono">#
Name, Type,
SubType, Offset,
Size</font></div>
<div><font
face="Andale Mono">nvs,
data, nvs,
0x9000, 0x4000</font></div>
<div><font
face="Andale Mono">otadata,
data, ota,
0xd000, 0x2000</font></div>
<div><font
face="Andale Mono">phy_init,
data, phy,
0xf000, 0x1000</font></div>
<div><font
face="Andale Mono">factory,
app, factory,
0x10000, 4M</font></div>
<div><font
face="Andale Mono">ota_0,
app, ota_0, ,
4M</font></div>
<div><font
face="Andale Mono">ota_1,
app, ota_1, ,
4M</font></div>
<div><font
face="Andale Mono">store,
data, fat, ,
1M</font></div>
</div>
</blockquote>
<div><br>
</div>
<div>Assuming we could (and
that is a big assumption
given our older SDK)
change that at runtime,
then a possible migration
path could be:</div>
<div><br>
</div>
<div>
<ol class="MailOutline">
<li>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.</li>
<li>Provide a migration
tool for partition
table:</li>
<ol class="MailOutline">
<li>Copy running code
to factory (from
ota_0 or ota_1,
whichever is
current).</li>
<li>Reboot</li>
<li>Change partition
table (most likely
replacing the entire
table with a binary
blob of the new
format)</li>
<ol
class="MailOutline">
<li>factory 4MB
-> ota_0 same
offset, 6MB size</li>
<li>ota_0 ->
ota_1 6MB offset,
6MB size</li>
</ol>
<li>Change boot to
ota_0.</li>
<li>Reboot</li>
</ol>
<li>Liase with factory
so new modules use new
partition format (and
ship with firmware
that supports it).</li>
<li>Wait a reasonable
time for users to
update before
releasing any firmware
> 4MB.</li>
</ol>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>Regards, Mark.<br
id="lineBreakAtBeginningOfMessage">
<div><br>
<blockquote type="cite">
<div>On 7 Dec 2025, at
4:39 PM, Carsten
Schmiemann via
OvmsDev<span
class="Apple-converted-space"> </span><a class="moz-txt-link-rfc2396E"
href="mailto:ovmsdev@lists.openvehicles.com" moz-do-not-send="true"><ovmsdev@lists.openvehicles.com></a><span
class="Apple-converted-space"> </span>wrote:</div>
<br
class="Apple-interchange-newline">
<div>
<div
style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Hi
Michael,
<div><br>
</div>
<div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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). </div>
<div><br>
</div>
<div>All great
ideas, but in
the end, how
many users
really make
use of them?</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Just my 2
cents</div>
<div>Carsten</div>
<div><br>
</div>
<div>
<blockquote
type="cite">
<div>Am
07.12.2025 um
08:57 schrieb
Michael Balzer
via OvmsDev<span
class="Apple-converted-space"> </span><a class="moz-txt-link-rfc2396E"
href="mailto:ovmsdev@lists.openvehicles.com" moz-do-not-send="true"><ovmsdev@lists.openvehicles.com></a>:</div>
<br
class="Apple-interchange-newline">
<div>
<div>FYI: use
`make
size-components`
to create a
report on all
component
sizes (`make
size-files`
for source
file level).<br>
<br>
Unsurprisingly
the webserver
is on top,
even with all
assets
precompressed
already.<br>
<br>
<br>
<b><u>Top 10
components:</u></b><br>
<br>
<font
face="monospace">Per-archive contributions to ELF file:<br>
<span
class="Apple-converted-space"> </span>Archive File DRAM .data &
.bss IRAM
Flash code
& rodata
Total<br>
libovms_webserver.a
0
255 0
134342
399846
534443<br>
libstdc++.a
149
5640 0
141045
72513 219347<br>
libmain.a
15
2104 0
139216
40086 181421<br>
<span
class="Apple-converted-space"> </span>libduktape.a 0 0
0
141641
20367 162008<br>
libvehicle_renaulttwizy. 0 29 0 86517 75357
161903<br>
libc-psram-workaround.a 1854 66 18391 118283 10943
149537<br>
liblwip.a
17
3873 0
118366
16722 138978<br>
libnet80211.a
938
9042 10475
92339
21900 134694<br>
<span
class="Apple-converted-space"> </span>libmbedtls.a 100 560
76
107079
26785 134600<br>
<span
class="Apple-converted-space"> </span>libvehicle_vweup.a 8
8 0
60846
43432 104294</font><br>
<br>
<br>
<b><u>Vehicles:</u></b><br>
<br>
<font
face="monospace">Per-archive contributions to ELF file:<br>
<span
class="Apple-converted-space"> </span>Archive File DRAM .data &
.bss IRAM
Flash code
& rodata
Total<br>
libvehicle_renaulttwizy. 0 29 0 86517 75357
161903<br>
<span
class="Apple-converted-space"> </span>libvehicle_vweup.a 8
8 0
60846
43432 104294<br>
libvehicle_mgev.a
156
26 0
47756
33998 81936<br>
<span
class="Apple-converted-space"> </span>libvehicle_smarteq.a 82
15 0
59267
19527 78891<br>
<span
class="Apple-converted-space"> </span>libvehicle_smarted.a 0
9 0
48481
28801 77291<br>
libvehicle_renaultzoe_ph 4 10 0 44622 29564
74200<br>
<span
class="Apple-converted-space"> </span>libvehicle.a 0 68
0
57735
12062 69865<br>
<span
class="Apple-converted-space"> </span>libvehicle_bmwi3.a 0
2 0
33370
14357 47729<br>
libvehicle_minise.a
9432
2 0
35360
2210 47004<br>
libvehicle_hyundai_ioniq 176 7 0 32921 13425
46529<br>
libvehicle_nissanleaf.a 0 3 0 35491 8941
44435<br>
<span
class="Apple-converted-space"> </span>libvehicle_kiasoulev.a 240
9 0
32508
5473 38230<br>
<span
class="Apple-converted-space"> </span>libvehicle_kianiroev.a 108
7 0
24070
4006 28191<br>
libvehicle_mitsubishi.a 0 5 0 21645 3893
25543<br>
libvehicle_boltev.a
0
5 0
15999
7864 23868<br>
<span
class="Apple-converted-space"> </span>libvehicle_niu_gtevo.a 4
12 0
18248
3733 21997<br>
libvehicle_maxus_edelive 156 3 0 10713 7477
18349<br>
libvehicle_renaultzoe.a 0 6 0 14828 2859
17693<br>
libvehicle_maxus_euniq56 156 3 0 8363 6840
15362<br>
libvehicle_voltampera.a 0 5 0 13221 1932
15158<br>
libvehicle_hyundai_ioniq 0 3 0 11081 3191
14275<br>
libvehicle_teslaroadster 0 6 0 10367 2238
12611<br>
<span
class="Apple-converted-space"> </span>libvehicle_thinkcity.a 0
3 0
6114
3449 9566<br>
libvehicle_jaguaripace.a 0 8 0 5445 3941
9394<br>
libvehicle_fiatedoblo.a 0 2 0 4262 2126
6390<br>
libvehicle_teslamodels.a 0 2 0 5361 948
6311<br>
libvehicle_toyotarav4ev. 0 2 0 5023 1255
6280<br>
<span
class="Apple-converted-space"> </span>libvehicle_maxus_t90.a 0
3 0
2567
2204 4774<br>
<span
class="Apple-converted-space"> </span>libvehicle_byd_atto3.a 0
2 0
3503
947 4452<br>
libvehicle_energica.a
0
1 0
3319
880 4200<br>
libvehicle_demo.a
0
2 0
3205
795 4002<br>
libvehicle_maxus_euniq6. 0 2 0 2470 1182
3654<br>
<span
class="Apple-converted-space"> </span>libvehicle_fiat500.a 0
2 0
2838
732 3572<br>
libvehicle_zombie_vcu.a 0 4 0 1882 1259
3145<br>
libvehicle_mercedesb250e 0 2 0 2113 955
3070<br>
libvehicle_zeva.a
0
2 0
2209
688 2899<br>
<span
class="Apple-converted-space"> </span>libvehicle_dbc.a 0
2 0
1278
1395 2675<br>
libvehicle_cadillac_c2_c 0 7 0 1293 1105
2405<br>
libvehicle_maple60s.a
0
2 0
1416
698 2116<br>
libvehicle_chevrolet_c6_ 0 2 0 1053 1049
2104<br>
<span
class="Apple-converted-space"> </span>libvehicle_obdii.a 0
2 0
957
1007 1966<br>
libvehicle_teslamodel3.a 0 2 0 458 713
1173<br>
libvehicle_none.a
0
2 0
418
684 1104<br>
<span
class="Apple-converted-space"> </span>libvehicle_track.a 0
2 0
416
680 1098</font><br>
<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div
class="moz-cite-prefix">Am 06.12.25 um 10:33 schrieb Michael Balzer via
OvmsDev:<br>
</div>
<blockquote
type="cite"
cite="mid:6aad0365-f942-45ea-948d-5b9d67fc7073@expeedo.de">Everyone,<span
class="Apple-converted-space"> </span><br>
<br>
with the
latest vehicle
additions, the
firmware size
has now grown
to 4,015,328
bytes in build
3.3.005-485-gc4664881.<span class="Apple-converted-space"> </span><br>
<br>
Our flash
partitioning
scheme is
currently
designed to
provide three
firmware
partitions
(factory,
ota_0 &
ota_1) of 4MB
= 4,194,304
bytes each.<span
class="Apple-converted-space"> </span><br>
<br>
So we've now
got 178,976
bytes = ~4%
left.<span
class="Apple-converted-space"> </span><br>
<br>
Options beyond
the 4 MB
limit:<span
class="Apple-converted-space"> </span><br>
<br>
a) split
features, e.g.
vehicle
support, into
two or more
builds<span
class="Apple-converted-space"> </span><br>
<br>
b)
repartition
into two
firmware
partitions of
6 MB each,
reusing the
factory
partition for
OTA<span
class="Apple-converted-space"> </span><br>
<br>
c) switch to
an ESP32 WROOM
module with 32
MB flash
(possible?)<span
class="Apple-converted-space"> </span><br>
<br>
We've got some
time left, new
vehicles
normally don't
need that much
space, I just
wanted to
raise
awareness.<span
class="Apple-converted-space"> </span><br>
<br>
Regards,<span
class="Apple-converted-space"> </span><br>
Michael<span
class="Apple-converted-space"> </span><br>
<br>
<br>
<fieldset
class="moz-mime-attachment-header"></fieldset>
<pre wrap=""
class="moz-quote-pre">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:OvmsDev@lists.openvehicles.com" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext"
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre
class="moz-signature" cols="72">--
Michael Balzer * Am Rahmen 5 * D-58313 Herdecke
Fon 02330 9104094 * Handy 0176 20698926</pre>
<br>
</div>
_______________________________________________<br>
OvmsDev
mailing list<br>
<a
class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:OvmsDev@lists.openvehicles.com" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br>
<a
class="moz-txt-link-freetext"
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
_______________________________________________<br>
OvmsDev mailing list<br>
<a
class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:OvmsDev@lists.openvehicles.com" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br>
<a
class="moz-txt-link-freetext"
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset
class="moz-mime-attachment-header"></fieldset>
<pre wrap=""
class="moz-quote-pre">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:OvmsDev@lists.openvehicles.com" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext"
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature"
cols="72">--
Michael Balzer * Am Rahmen 5 * D-58313 Herdecke
Fon 02330 9104094 * Handy 0176 20698926</pre>
<br>
</div>
</div>
<span
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 18px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;">_______________________________________________</span><br
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 18px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-line: none; text-decoration-thickness: auto; text-decoration-style: solid;">
<span
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 18px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;">OvmsDev
mailing list</span><br
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 18px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-line: none; text-decoration-thickness: auto; text-decoration-style: solid;">
<a
href="mailto:OvmsDev@lists.openvehicles.com"
style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;"
moz-do-not-send="true"
class="moz-txt-link-freetext">OvmsDev@lists.openvehicles.com</a><br
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 18px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-line: none; text-decoration-thickness: auto; text-decoration-style: solid;">
<a
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;"
moz-do-not-send="true"
class="moz-txt-link-freetext">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a></div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Michael Balzer * Am Rahmen 5 * D-58313 Herdecke
Fon 02330 9104094 * Handy 0176 20698926</pre>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Michael Balzer * Am Rahmen 5 * D-58313 Herdecke
Fon 02330 9104094 * Handy 0176 20698926</pre>
<br>
</body>
</html>