Vorstellung Feature: OTA Funktionalität für 4MB Boards

laszloh · 16. November 2023 um 15:11

Hallo zusammen,
Nachdem ich einige Boards mit 4MB Flash habe und diese auch verbauen wollte, habe ich mir Gedanken darüber gemacht, wie OTA auf diesen aussehen könnte (WAF Faktor wichtig, da diese Geschenke werden und ich nicht jedes Mal nach Budapest reisen will wenn es ein Update gibt ).

Ich habe die Idee von Tasmota (und Android mit der Recovery Partition) übernommen, die haben ein OTA Lösung mit zwei Asymmetrischen Partitionen implementiert („app0“ mit dem normalen Tasmota und „safeboot“ mit einer minimalen Version). Die safeboot Version ist dann dediziert nur für ein OTA Update verantwortlich.

Aktuell habe ich mich für die folgende Partitionierung für die 4MB Version entschieden:

Hier reserviere ich 800 kB für die OTA Partition, die nach der Haupt-App sitzt.

Ein Proof of Concept ist aktuell hier zu finden (Achtung Spielwiese, force-pushes können hier ohne Vorwarnung kommen):

Der Safeboot OTA ist hier sehr einfach implementiert, es greift auf die SD-Karte zu und schaut, ob da eine Datei „/firmware.bin“ zu finden ist. Wenn ja, wir die ESPuino Partition gesichert und die firmware.bin über das OTA System von espidf geschrieben. Danach wird die neue FW gebootet.

Sollte etwas dabei schief laufen, wir das Backup in „recovery.bin“ umbenannt und ein Reboot wieder zu safeboot ausgeführt. Danach versucht es ein OTA mit der alten SW (noch nicht getestet, ob es wirklich so funktioniert).

Features:

Speichern einer neuer Firmware auf der SD-Karte und Booten zu Safeboot
Applikation über OTA update überschreiben
Backup der bestehenden Firmware
Recovery nach einem fehlerhaften OTA
Recovery nach einem Stromausfall beim OTA
NVS Partition darf nicht verschoben werden

Vorteil von dem System ist, dass auch bei der 4MB Flash Varianten ein OTA möglich ist. Der Safeboot braucht aktuell zwingend eine SD-Karte, aber in Theorie könnte auch ein Webserver mit einer minimalen Website in den Speicher passen.

Nachteil, dass wir (aktuell) 800kB an Speicher für ESPuino verlieren. Diese könnte auf ca 400kB reduziert werden, wenn keine zusätzlichen Features hinzu kommen. Auch ist ein Recovery komplizierter als bei der klassischen OTA-Variante von ESP32 (wo nach einem fehlerhaften OTA einfach die aktuelle Partition gebootet wird). Auch ist ein Rollback nach einem Update aus dem gleichen Grund nicht möglich.

Ideen und Meinungen sind gerne willkommen.

edit:
Haben wir eine Kategorie für die Vorstellung von Features?

biologist · 16. November 2023 um 16:11

Also generell ist das natürlich cool, dass man damit auch OTA-Flashing mit 4 MB hinkriegt. Ich hatte auch immer mal im Hinterkopf, mir das bei Tasmota mal anzuschauen, es letztlich dann aber doch nie gemacht.
Ich habe nur so ein bisschen Bedenken, dass das relativ viel Code ist, den regulär niemand testet und der ohnehin nur von ganz ganz wenigen Leuten (vielleicht nur du?) gebraucht wird. Weil:

a) Ich habe mit den 4 MB-WROOM-Modellen angefangen. Aber wie wir demletzt gemerkt haben, geht es mit Arduino2 ohne PSRAM nicht. Du wirst deinen Code aber auch nicht auf Arduino1 portieren. Insofern sind diese (ich denke mehrere Dutzend) User raus.
b) Im WROVER-Umfeld gibt es 4, 8 und 16 MB, aber 8 MB findet man quasi gar nicht und 4 MB recht selten. Bleibt da außer TTGO noch was mit 4 MB? Ok, das Audiokit gibt es noch, das hat auch 4 MB und ich glaube auch PSRAM (da bin ich mir aber nicht mehr sicher). Bei dem weiß ich aber eh nicht, ob da aktueller Code drauf lauffähig ist.
c) Die 16er im WROVER-Umfeld dürften hier den bei weitem größten Nutzerkreis haben: Neben den gut 300 Modulen, die von mir stammen, kommen nochmal einige Lolin D32 pro dazu. Da wird man das Partitions-Layout nicht einfach umstellen wollen, weil das halt das gesamte NVS überschreibt. Wir hatten das einmal, weil das NVS irgendwann zu klein wurde. Das war unschön aber leider nicht zu verhindern. Zugegeben: Das Hauptproblem mit NVS sind ja die RFID-Zuweisungen und die kriegt man wieder einfach importiert. Aber erstmal erwischt man den ein oder anderen User bestimmt eiskalt.

Also ich will mich jetzt nicht hier hinstellen und sagen, dass wir das nicht machen, aber mich würde interessieren, ob es da auch Bedarf von mehreren Usern für gibt.

Bisher nicht. Brauchen wir eine Subkategorie von Software?

laszloh · 20. November 2023 um 01:19

Der Umfang der Änderung im den Codestamm ist zum Glück überschaubar, die größte Änderung ist in der Haupt-App im Web.cpp um die Funktionalität vom FactoryOtaHandler zu implementieren. Der safeboot selber habe ich versucht auf jeden Fall so einfach und Dumm zu halten wie es nur geht

Zu deinen Punkten

a) Nein, ich habe nicht vor auf Arduino 1 zu Backporten, damit fallen auch bei alle WROOM Boards weg.
b) Interessanterweise finde ich hier in Wien fast nur 4MB WROVER-Board (Aliexpress ist natürlich eine Lösung, aber dank unserer Regierung liefern aktuell gefühlt 20% aller Verkäufer hierher). Ich setzte meist TTGOs ein (v1.8), weil die einfach und schnell hier zu haben sind.
c) Ich würde auch nicht empfehlen andere Module als die 4MB auf die Factory umzustellen. Bei 8MB oder höher haben wir das Problem nicht, dass der Speicher nicht reicht um 2x die Applikation (und damit die Standard-OTA vom ESP32) zu verwenden. Das funktioniert von Haus aus, somit sollten wir das auch nicht anfassen.

Wegen dem NVS, ich habe extra die SafeBoot Partiton so gelegt, dass die NVS nicht verändert wird. Ich schneide mir die 800kB für die Factory Partition aus der Haupt-App raus. Somit gibt es auch bei einem Upgrade von noOTA auf factoryOTA kein Verlust des NVS.