tasmota-webserial-esptool 6.4.1 → 6.5.1

package/.github/workflows/build_upload.yml

@@ -12,8 +12,11 @@ concurrency:
 jobs:
   build:
     runs-on: ubuntu-latest
+    permissions:
+      contents: write
+      id-token: write  # required to use OIDC
     steps:
-      - uses: actions/checkout@v5
+      - uses: actions/checkout@v6
       - name: Remove old files and folders
         run: |
           rm -rf package-lock.json
@@ -21,7 +24,7 @@ jobs:
           rm -rf js/modules
           mkdir js/modules
       - name: install node v20
-        uses: actions/setup-node@v4
+        uses: actions/setup-node@v6
         with:
           node-version: 20
       - name: Install Yarn with NPM
@@ -40,11 +43,11 @@ jobs:
           mv js/modules/index.js js/modules/esptool.js
           #ls js/modules/
       - name: Commit Distribution Files
-        uses: stefanzweifel/git-auto-commit-action@v5
+        uses: stefanzweifel/git-auto-commit-action@v7
         with:
           commit_message: "Github Action: Updated dist files"
       - name: Publish to NPM registry
-        uses: JS-DevTools/npm-publish@v3
+        uses: JS-DevTools/npm-publish@v4
         with:
           registry: https://registry.npmjs.org/
           token: ${{ secrets.NPM_TOKEN }}
@@ -52,7 +55,7 @@ jobs:
       - name: Setup Pages
         uses: actions/configure-pages@v5
       - name: Upload artifact
-        uses: actions/upload-pages-artifact@v3
+        uses: actions/upload-pages-artifact@v4
         with:
           path: "."
 

package/.github/workflows/ci.yml

@@ -12,9 +12,9 @@ jobs:
     runs-on: ubuntu-latest
 
     steps:
-      - uses: actions/checkout@v5
+      - uses: actions/checkout@v6
       - name: Use Node.js
-        uses: actions/setup-node@v4
+        uses: actions/setup-node@v6
         with:
           node-version: 20
       - name: Remove old package-lock.json
@@ -25,6 +25,6 @@ jobs:
       - run: script/build
       - run: npm exec -- prettier --check src
       - name: Commit changed files
-        uses: stefanzweifel/git-auto-commit-action@v5
+        uses: stefanzweifel/git-auto-commit-action@v7
         with:
           commit_message: "Github Action: Updated files"

package/BUGFIX_GET_SECURITY_INFO.md

@@ -0,0 +1,126 @@
+# Bugfix: GET_SECURITY_INFO für ESP32-C3
+
+## Problem
+
+ESP32-C3 v0.4 (und andere moderne Chips) sollten `GET_SECURITY_INFO` unterstützen, aber es schlug mit einer leeren Antwort fehl:
+
+```
+GET_SECURITY_INFO failed, using magic value detection: Error: Invalid security info response length: 0
+```
+
+## Ursache
+
+Das Problem lag in der `checkCommand()` Funktion:
+
+1. `GET_SECURITY_INFO` wird während `detectChip()` aufgerufen
+2. Zu diesem Zeitpunkt ist `chipFamily` noch **nicht gesetzt**
+3. `checkCommand()` konnte die Status-Länge nicht korrekt bestimmen
+4. Es fiel in den `else` Block und verwendete die falsche Status-Länge
+5. Die Daten wurden falsch geparst → leere `responseData`
+
+### Code-Flow (vorher):
+
+```typescript
+async detectChip() {
+  // chipFamily ist noch NICHT gesetzt!
+  const securityInfo = await this.getSecurityInfo();
+  //                          ↓
+  //                   checkCommand(ESP_GET_SECURITY_INFO, ...)
+  //                          ↓
+  //                   chipFamily ist undefined
+  //                          ↓
+  //                   statusLen wird falsch berechnet
+  //                          ↓
+  //                   data wird falsch geparst
+  //                          ↓
+  //                   responseData.length === 0
+}
+```
+
+## Lösung
+
+In `checkCommand()` wurde eine spezielle Behandlung für `GET_SECURITY_INFO` hinzugefügt:
+
+```typescript
+async checkCommand(opcode, buffer, checksum, timeout) {
+  // ...
+  
+  let statusLen = 0;
+
+  if (this.IS_STUB || this.chipFamily == CHIP_FAMILY_ESP8266) {
+    statusLen = 2;
+  } else if ([CHIP_FAMILY_ESP32, ...].includes(this.chipFamily)) {
+    statusLen = 4;
+  } else {
+    // NEU: Wenn chipFamily noch nicht gesetzt ist (während detectChip)
+    if (opcode === ESP_GET_SECURITY_INFO) {
+      statusLen = 4;  // Moderne Chips verwenden 4-Byte Status
+    } else if ([2, 4].includes(data.length)) {
+      statusLen = data.length;
+    }
+  }
+  
+  // ...
+}
+```
+
+## Ergebnis
+
+Nach dem Fix sollte ESP32-C3 v0.4 (und andere moderne Chips) korrekt erkannt werden:
+
+### Vorher:
+```
+[debug] GET_SECURITY_INFO failed, using magic value detection: Error: Invalid security info response length: 0
+[debug] Detected chip via magic value: 0x1B31506F (ESP32-C3)
+```
+
+### Nachher (erwartet):
+```
+[debug] Detected chip via IMAGE_CHIP_ID: 5 (ESP32-C3)
+Chip type ESP32-C3
+```
+
+## Betroffene Chips
+
+Dieser Fix verbessert die Erkennung für:
+
+- ✅ ESP32-C3 (alle Revisionen mit GET_SECURITY_INFO Support)
+- ✅ ESP32-S3
+- ✅ ESP32-C6
+- ✅ ESP32-C61
+- ✅ ESP32-H2
+- ✅ ESP32-C5
+- ✅ ESP32-P4 Rev. 300+
+
+## Fallback bleibt erhalten
+
+Der Fallback auf Magic Value Detection bleibt weiterhin funktionsfähig für:
+
+- ESP8266
+- ESP32
+- ESP32-S2
+- Ältere ROM-Versionen, die GET_SECURITY_INFO nicht unterstützen
+
+## Testing
+
+### Zu testen:
+- [ ] ESP32-C3 v0.4 → sollte via IMAGE_CHIP_ID erkannt werden
+- [ ] ESP32-S3 → sollte via IMAGE_CHIP_ID erkannt werden
+- [ ] ESP32-P4 Rev. 300+ → sollte via IMAGE_CHIP_ID erkannt werden
+- [ ] ESP8266 → sollte via Magic Value erkannt werden (Fallback)
+- [ ] ESP32 → sollte via Magic Value erkannt werden (Fallback)
+
+### Erwartetes Verhalten:
+
+**Moderne Chips (mit GET_SECURITY_INFO):**
+```
+[debug] Detected chip via IMAGE_CHIP_ID: X (ESP32-XX)
+```
+
+**Ältere Chips (ohne GET_SECURITY_INFO):**
+```
+[debug] GET_SECURITY_INFO failed, using magic value detection
+[debug] Detected chip via magic value: 0xXXXXXXXX (ESP32-XX)
+```
+
+Beide Wege führen zur korrekten Chip-Erkennung! ✅

package/CHANGELOG_CHIP_VARIANT.md

@@ -0,0 +1,169 @@
+# Changelog: Chip Variant Support
+
+## Änderungen in WebSerial_ESPTool
+
+### Neue Features
+
+#### 1. `chipVariant` Feld in ESPLoader
+- Neues öffentliches Feld: `chipVariant: string | null`
+- Wird automatisch bei der Chip-Erkennung gesetzt
+- Für ESP32-P4: `"rev0"` (Revision < 300) oder `"rev300"` (Revision >= 300)
+- Für alle anderen Chips: `null`
+
+#### 2. Erweiterte ESP32-P4 Erkennung
+- Revision wird aus eFuses gelesen (EFUSE_BLOCK1)
+- Funktioniert sowohl bei IMAGE_CHIP_ID als auch Magic Value Erkennung
+- Logging der erkannten Variante im Debug-Modus
+
+### Geänderte Dateien
+
+- `src/esp_loader.ts`:
+  - Hinzugefügt: `chipVariant: string | null` Feld
+  - Erweitert: `detectChip()` Methode setzt chipVariant für ESP32-P4
+  - Erweitert: Logging für bessere Nachvollziehbarkeit
+
+### API-Änderungen
+
+```typescript
+// Vorher
+const esploader = new ESPLoader(port, logger);
+await esploader.initialize();
+console.log(esploader.chipName);      // "ESP32-P4"
+console.log(esploader.chipRevision);  // 300
+
+// Nachher (zusätzlich)
+console.log(esploader.chipVariant);   // "rev300"
+```
+
+### Abwärtskompatibilität
+
+✅ Vollständig abwärtskompatibel
+- Bestehendes Code funktioniert unverändert
+- Neues Feld ist optional und kann ignoriert werden
+- Keine Breaking Changes
+
+## Änderungen in esp-web-tools
+
+### Neue Features
+
+#### 1. `chipVariant` Support in Manifesten
+- Neues optionales Feld in `Build` Interface: `chipVariant?: string`
+- Ermöglicht spezifische Firmware-Builds für verschiedene Chip-Varianten
+- Intelligente Matching-Logik mit Fallback-Unterstützung
+
+#### 2. Erweiterte Build-Auswahl
+- Priorisiert Builds mit passendem `chipVariant`
+- Fallback auf Builds ohne `chipVariant` Angabe
+- Bessere Fehlermeldungen mit Varianten-Information
+
+### Geänderte Dateien
+
+- `src/const.ts`:
+  - Erweitert: `Build` Interface mit `chipVariant?: string`
+  - Erweitert: `BaseFlashState` Interface mit `chipVariant?: string | null`
+
+- `src/flash.ts`:
+  - Erweitert: Build-Matching-Logik berücksichtigt chipVariant
+  - Erweitert: Fehlermeldungen zeigen chipVariant an
+  - Erweitert: Initialisierungsmeldung zeigt chipVariant an
+
+- `README.md`:
+  - Hinzugefügt: Dokumentation für Chip Variant Support
+  - Hinzugefügt: Beispiel für P4-Varianten
+
+### Manifest-Beispiel
+
+```json
+{
+  "name": "My Firmware",
+  "version": "1.0.0",
+  "builds": [
+    {
+      "chipFamily": "ESP32-P4",
+      "chipVariant": "rev0",
+      "parts": [...]
+    },
+    {
+      "chipFamily": "ESP32-P4",
+      "chipVariant": "rev300",
+      "parts": [...]
+    }
+  ]
+}
+```
+
+### Abwärtskompatibilität
+
+✅ Vollständig abwärtskompatibel
+- Bestehende Manifeste ohne `chipVariant` funktionieren weiterhin
+- `chipVariant` ist optional
+- Keine Breaking Changes
+
+## Testing
+
+### Build-Tests
+- ✅ WebSerial_ESPTool kompiliert erfolgreich
+- ✅ esp-web-tools kompiliert erfolgreich
+- ✅ Keine TypeScript-Fehler
+- ✅ Keine Linting-Fehler
+
+### Funktionale Tests (empfohlen)
+- [ ] Test mit ESP32-P4 Rev. 0 Hardware
+- [ ] Test mit ESP32-P4 Rev. 300 Hardware
+- [ ] Test mit Manifest mit chipVariant
+- [ ] Test mit Manifest ohne chipVariant (Fallback)
+- [ ] Test mit anderen ESP32-Chips (sollte chipVariant = null sein)
+
+## Deployment
+
+### WebSerial_ESPTool
+1. Version in `package.json` erhöhen
+2. `npm run prepublishOnly` ausführen
+3. `npm publish` ausführen
+
+### esp-web-tools
+1. Warten bis neue WebSerial_ESPTool Version verfügbar ist
+2. `package.json` aktualisieren: `"tasmota-webserial-esptool": "^6.5.0"` (oder höher)
+3. Version in `package.json` erhöhen
+4. `npm install`
+5. `npm run prepublishOnly` ausführen
+6. `npm publish` ausführen
+
+## Dokumentation
+
+- ✅ `CHIP_VARIANT_SUPPORT.md` - Vollständige technische Dokumentation
+- ✅ `manifest-example-p4-variants.json` - Beispiel-Manifest
+- ✅ `README.md` (esp-web-tools) - Kurze Anleitung
+- ✅ `CHANGELOG_CHIP_VARIANT.md` - Diese Datei
+
+## Verwendungsbeispiele
+
+### Szenario 1: Separate Builds für jede Variante
+```json
+{
+  "builds": [
+    { "chipFamily": "ESP32-P4", "chipVariant": "rev0", "parts": [...] },
+    { "chipFamily": "ESP32-P4", "chipVariant": "rev300", "parts": [...] }
+  ]
+}
+```
+
+### Szenario 2: Ein Build für alle Varianten
+```json
+{
+  "builds": [
+    { "chipFamily": "ESP32-P4", "parts": [...] }
+  ]
+}
+```
+
+### Szenario 3: Spezifischer Build + Fallback
+```json
+{
+  "builds": [
+    { "chipFamily": "ESP32-P4", "chipVariant": "rev300", "parts": [...] },
+    { "chipFamily": "ESP32-P4", "parts": [...] }
+  ]
+}
+```
+Rev300 verwendet ersten Build, Rev0 verwendet zweiten Build (Fallback).

package/CHIP_VARIANT_SUPPORT.md

@@ -0,0 +1,184 @@
+# ESP32-P4 Chip Variant Support
+
+## Übersicht
+
+Die beiden Projekte unterstützen jetzt die Unterscheidung zwischen verschiedenen ESP32-P4 Varianten über das neue `chipVariant` Feld.
+
+## WebSerial_ESPTool
+
+### Änderungen
+
+Das `ESPLoader` Objekt hat jetzt ein neues Feld:
+- `chipVariant: string | null` - Identifiziert die Chip-Variante
+
+### ESP32-P4 Varianten
+
+Für ESP32-P4 Chips werden folgende Varianten erkannt:
+- `"rev0"` - ESP32-P4 Revision < 300 (ältere Versionen)
+- `"rev300"` - ESP32-P4 Revision >= 300 (neuere Versionen)
+
+Die Erkennung erfolgt automatisch basierend auf der Chip-Revision, die aus den eFuses gelesen wird.
+
+### Beispiel
+
+```typescript
+const esploader = new ESPLoader(port, logger);
+await esploader.initialize();
+
+console.log(esploader.chipName);      // "ESP32-P4"
+console.log(esploader.chipFamily);    // CHIP_FAMILY_ESP32P4
+console.log(esploader.chipRevision);  // z.B. 0 oder 300
+console.log(esploader.chipVariant);   // "rev0" oder "rev300"
+```
+
+## esp-web-tools
+
+### Änderungen
+
+#### Manifest Format
+
+Das `Build` Interface unterstützt jetzt ein optionales `chipVariant` Feld:
+
+```typescript
+interface Build {
+  chipFamily: "ESP32-P4" | ...;
+  chipVariant?: string;  // NEU
+  parts: { path: string; offset: number; }[];
+}
+```
+
+#### Flash State
+
+Der `FlashState` enthält jetzt auch die `chipVariant` Information:
+
+```typescript
+interface BaseFlashState {
+  chipFamily?: "ESP32-P4" | ...;
+  chipVariant?: string | null;  // NEU
+  // ...
+}
+```
+
+### Manifest Beispiel
+
+Hier ist ein Beispiel-Manifest, das verschiedene Firmware-Builds für die zwei P4-Varianten bereitstellt:
+
+```json
+{
+  "name": "My ESP32-P4 Firmware",
+  "version": "1.0.0",
+  "builds": [
+    {
+      "chipFamily": "ESP32-P4",
+      "chipVariant": "rev0",
+      "parts": [
+        { "path": "bootloader_rev0.bin", "offset": 0 },
+        { "path": "partition-table.bin", "offset": 32768 },
+        { "path": "firmware_rev0.bin", "offset": 65536 }
+      ]
+    },
+    {
+      "chipFamily": "ESP32-P4",
+      "chipVariant": "rev300",
+      "parts": [
+        { "path": "bootloader_rev300.bin", "offset": 0 },
+        { "path": "partition-table.bin", "offset": 32768 },
+        { "path": "firmware_rev300.bin", "offset": 65536 }
+      ]
+    },
+    {
+      "chipFamily": "ESP32-S3",
+      "parts": [
+        { "path": "bootloader_s3.bin", "offset": 0 },
+        { "path": "partition-table.bin", "offset": 32768 },
+        { "path": "firmware_s3.bin", "offset": 65536 }
+      ]
+    }
+  ]
+}
+```
+
+### Matching-Logik
+
+Die Firmware-Auswahl funktioniert wie folgt:
+
+1. **Wenn `chipVariant` im Build angegeben ist**: Der Build wird nur verwendet, wenn sowohl `chipFamily` als auch `chipVariant` übereinstimmen.
+
+2. **Wenn `chipVariant` im Build NICHT angegeben ist**: Der Build wird für alle Varianten dieser `chipFamily` verwendet (Fallback).
+
+#### Beispiele
+
+**Szenario 1: Spezifische Builds für jede Variante**
+```json
+{
+  "builds": [
+    { "chipFamily": "ESP32-P4", "chipVariant": "rev0", "parts": [...] },
+    { "chipFamily": "ESP32-P4", "chipVariant": "rev300", "parts": [...] }
+  ]
+}
+```
+- ESP32-P4 rev0 → verwendet ersten Build
+- ESP32-P4 rev300 → verwendet zweiten Build
+
+**Szenario 2: Ein Build für alle Varianten**
+```json
+{
+  "builds": [
+    { "chipFamily": "ESP32-P4", "parts": [...] }
+  ]
+}
+```
+- ESP32-P4 rev0 → verwendet den Build
+- ESP32-P4 rev300 → verwendet den Build
+
+**Szenario 3: Spezifischer Build + Fallback**
+```json
+{
+  "builds": [
+    { "chipFamily": "ESP32-P4", "chipVariant": "rev300", "parts": [...] },
+    { "chipFamily": "ESP32-P4", "parts": [...] }
+  ]
+}
+```
+- ESP32-P4 rev0 → verwendet zweiten Build (Fallback)
+- ESP32-P4 rev300 → verwendet ersten Build (spezifisch)
+
+## Abwärtskompatibilität
+
+Alle Änderungen sind vollständig abwärtskompatibel:
+
+- Bestehende Manifeste ohne `chipVariant` funktionieren weiterhin
+- Das `chipVariant` Feld ist optional
+- Für alle Chips außer ESP32-P4 ist `chipVariant` `null`
+
+## Technische Details
+
+### Chip-Erkennung
+
+Die ESP32-P4 Revision wird aus den eFuses gelesen (EFUSE_BLOCK1):
+- Minor Revision: Bits [3:0]
+- Major Revision: Bit [23] << 2 | Bits [5:4]
+- Revision = Major * 100 + Minor
+
+### Erkennungsmethoden
+
+Die Chip-Erkennung verwendet einen zweistufigen Ansatz:
+
+1. **Primär: GET_SECURITY_INFO** (IMAGE_CHIP_ID)
+   - Unterstützt von: ESP32-C3 (neuere ROM), ESP32-S3, ESP32-C6, ESP32-H2, ESP32-P4 Rev. 300+
+   - Liefert direkt die Chip-ID
+   - Wenn nicht unterstützt oder leere Antwort → Fallback zu Magic Value
+
+2. **Fallback: Magic Value Detection**
+   - Unterstützt von: ESP8266, ESP32, ESP32-S2, ESP32-C3 (ältere ROM), ESP32-P4 Rev. < 300
+   - Liest Magic-Wert aus Register 0x40001000
+   - Zuverlässige Methode für ältere Chips
+
+**Für ESP32-P4:**
+- Beide Methoden funktionieren
+- Nach Erkennung wird die Revision aus eFuses gelesen
+- Basierend auf Revision wird `chipVariant` gesetzt:
+  - Rev. < 300 → `"rev0"`
+  - Rev. >= 300 → `"rev300"`
+
+**Hinweis:** Die Debug-Meldung "GET_SECURITY_INFO failed, using magic value detection" ist normal und erwartet für ältere Chips. Der Fallback-Mechanismus stellt sicher, dass alle Chips korrekt erkannt werden.