85 lines
7.3 KiB
Markdown
85 lines
7.3 KiB
Markdown
# Änderungen am WinnerMicro W600 SDK
|
|
|
|
Quelle: `qcx-w600-firmware/qconnex_sdk/ext/WM_SDK_WM600` (QConnex-Stand 2025). Kopiert wurden nur
|
|
Include, Platform (ohne Boot/armcc), Src/OS, Src/Network, Src/App/{OTA,httpclient,dhcpserver,dnsserver},
|
|
Lib/GNU, Bin/secboot.img, Tools/GNU/link_w600_2m.ld (→ ld/) und wm_tool.c (→ tools/).
|
|
|
|
1. `Platform/Common/fwup/wm_fwup.c`: wolfSSL-SHA256 durch `nl_sha256_*` ersetzt, die QConnex-RSA-Prüfung
|
|
`Check_OTA_Image()` durch den Hook `nl_fwup_verify_tail()` (src/sys/nl_fwup_hook.h). Das Image-Format
|
|
(Header + Payload + 512-Byte-Endblock) bleibt unverändert. Die starke Definition des Hooks liegt seit
|
|
Plan 3 in `src/sys/nl_ota.c` (Trailer-Prüfung über `nl_trailer_verify()`); die bisherige `weak`-Variante
|
|
`src/sys/fwup_hook_default.c` ist entfallen.
|
|
Fix-Runde 1 (Task-4-Review) hat drei weitere Stellen in diesem Bereich korrigiert:
|
|
- `wm_fwup.c`, Bedingung um `nl_fwup_verify_tail()`: Checksummen- und Trailer-Prüfung liefen in
|
|
einer kurzschließenden `||`-Bedingung; bei falscher Checksumme wurde `nl_fwup_verify_tail()` nie
|
|
aufgerufen. Beide Fälle jetzt getrennt behandelt; ein Checksummenfehler ruft
|
|
`nl_ota_set_error("crc")` auf, bevor `goto request_finish` springt (sonst hätte `ota_task()` ihn
|
|
als generisches `"download"` gemeldet).
|
|
- `wm_fwup.c`, `request_finish:`-Block: `tls_sys_reset()` lief unbedingt, sobald der Transfer zu
|
|
Ende war - auch wenn `nl_fwup_verify_tail()` oder die Checksummenprüfung das Image gerade
|
|
abgelehnt hatten. Die Lampe hätte also trotz abgelehntem Image sofort neu gestartet, `ota_task()`
|
|
wäre nie zu Ende gelaufen und `last_ota_error` hätte nie `trailer`/`device_mismatch`/`hash`
|
|
gemeldet. Der Reset läuft jetzt nur noch, wenn `fwup->current_state` keinen Fehler-Bit-Satz
|
|
(`TLS_FWUP_STATE_ERROR`) trägt.
|
|
- `Src/App/OTA/wm_http_fwup.c`, `HANDLE_BODY`: Scheitert `tls_fwup_img_header_check()`, blieb
|
|
`nRetCode` auf `HTTP_CLIENT_SUCCESS` stehen, wodurch die abschließende
|
|
`if(nRetCode) socket_fwup_err(...)`-Bereinigung nie lief und die SDK-eigene fwup-Session
|
|
(`fwup->busy`) für jeden weiteren Versuch blockiert blieb. `nRetCode` wird jetzt in diesem Fall
|
|
explizit auf `HTTP_CLIENT_ERROR_BAD_HEADER` gesetzt.
|
|
- `Src/App/OTA/wm_http_fwup.c`, `SHUTDOWN_LINK`: Ein abbrechender Download sprang unbegrenzt oft
|
|
zurück nach `PREPARE_PACKET` (Resume per Range-Header) - schaltet der Server während der
|
|
Übertragung ab, hängt `t_http_fwup()` (und damit der aufrufende Task) für immer. Eine großzügige
|
|
Obergrenze (`NL_OTA_MAX_RETRY_ROUNDS`, 200 Resume-Runden) lässt `http_fwup()` danach mit
|
|
`HTTP_CLIENT_ERROR_SOCKET_TIME_OUT` zurückkehren, statt endlos zu warten.
|
|
|
|
Fix-Runde 2 (Re-Review von Fix-Runde 1) hat zwei Nachwirkungen der obigen Änderungen behoben:
|
|
- `Src/App/OTA/wm_http_fwup.c`, `HANDLE_BODY`: Lehnt `socket_fwup_recv()` einen Chunk ab (Checksummen-
|
|
/Trailer-Fehler oder ein anderer fataler fwup-Fehler), sprang der Code bisher nach `SHUTDOWN_LINK`
|
|
- da `recvLen` dabei nie den vollen `totalLen` erreicht, startete das eine komplette
|
|
Resume-Schleife (bis zu `NL_OTA_MAX_RETRY_ROUNDS` = 200 Range-Requests), deren Daten die fwup-Task
|
|
wegen des bereits gesetzten Fehler-Bits (siehe unten) jedes Mal sofort verwarf. `t_http_fwup()` kam
|
|
also erst nach Minuten mit dem richtigen Fehler zurück, `s_busy`/`ota_pending` standen so lange.
|
|
Springt jetzt direkt nach `QUIT_OTA` (mit `nRetCode = ret`, damit die `socket_fwup_err()`-
|
|
Bereinigung am Funktionsende trotzdem läuft) - der Abbruch ist damit sofort sichtbar, nicht erst
|
|
nach der vollen Resume-Schleife.
|
|
- `Platform/Common/fwup/wm_fwup.c`, Trailer-Puffer-Allokation (`RSA_SHA256 = tls_mem_alloc(512)`):
|
|
Schlug das fehl, sprang der Code nach `request_finish`, ohne ein Fehler-Bit zu setzen. Mit dem
|
|
Fix-Runde-1-Reset-Guard (siehe oben, `!(fwup->current_state & TLS_FWUP_STATE_ERROR)`) wäre das der
|
|
letzte verbliebene Weg gewesen, an `nl_fwup_verify_tail()` vorbei trotzdem zu resetten - der
|
|
Trailer wäre dann nie geprüft worden. Setzt jetzt `TLS_FWUP_STATE_ERROR_MEM` /
|
|
`TLS_FWUP_REQ_STATUS_FMEM` (wie die andere Allokationsprüfung in dieser Funktion) und
|
|
`nl_ota_set_error("download")` (kein spezifischerer Wert aus dem Vokabular passt hier).
|
|
2. `Src/OS/RTOS/include/FreeRTOSConfig.h`: `configGENERATE_RUN_TIME_STATS 0`, QConnex-Debug-Hooks entfernt.
|
|
3. `undefined reference` beim Linken auf `EarlyInit` und `pre_gpio_config` (von
|
|
`sdk/Platform/Sys/wm_main.c` als `extern`-Hooks erwartet, aber nur von der App bereitgestellt):
|
|
minimale Stubs in `src/sys/sdk_stubs.c` angelegt (leere Funktionskörper). In der alten Firmware
|
|
(`qconnex_sdk/src/qc_main.c`) war `pre_gpio_config()` bereits ein No-Op; `EarlyInit()` rief dort nur
|
|
in die QConnex-Hardwareschicht (`QCXH_EarlyInit()`), die ninlight nicht verwendet. Board-spezifische
|
|
Frühinitialisierung (falls nötig) folgt in einem späteren Plan.
|
|
4. `Platform/Sys/wm_main.c`: `vApplicationIdleHook()` hat bisher jedes Mal `tls_watchdog_clr()`
|
|
aufgerufen, wenn der Idle-Task lief - also immer dann, wenn kein anderer Task rechenbereit war.
|
|
Ein Task-Deadlock (z.B. ein Task, der `nl_app_lock()` hält und nie freigibt) hätte den Watchdog
|
|
damit nie ausgelöst, weil der Idle-Task munter weiter gefüttert hätte. Der `tls_watchdog_clr()`-
|
|
Aufruf wurde entfernt; `wfi` bleibt. Der einzige verbleibende `tls_watchdog_clr()`-Aufruf im SDK
|
|
ist in `Platform/Common/fwup/wm_fwup.c` (Firmware-Update-Task).
|
|
**Einschätzung aktualisiert (Task 4, Fix-Runde 1):** Als dieser Punkt geschrieben wurde, gab es noch
|
|
keinen OTA-Pfad - das Fenster war rein theoretisch. Mit Task 4 ist es real und kann durch einen
|
|
langsamen oder hängenden Download mehrere Minuten dauern: Solange `wm_fwup.c` seinen eigenen
|
|
`tls_watchdog_clr()` aufruft, wird der Watchdog gefüttert, **egal** ob `light_task`, `nl_wifi`/`nl_mdns`
|
|
oder `nl_http_server` in dieser Zeit echt hängen - der App-Task-Heartbeat-Mechanismus in
|
|
`src/app_main.c` (der genau das eigentlich verhindern soll) greift währenddessen nicht, weil der
|
|
Watchdog gar nicht bei ihm ankommt. Das ist kein Rückschritt gegenüber vorher (vor Task 4 gab es
|
|
dieses Fenster schlicht nicht), aber die bisherige Einstufung „unkritisch" war nur so lange richtig,
|
|
wie der Fall real nie eintrat. Kein Fix in dieser Runde - der Watchdog-Heartbeat müsste dafür wissen,
|
|
ob der fwup-Task selbst noch vorankommt (z. B. über einen eigenen Beat-Zähler, den `app_task`
|
|
zusätzlich zu `light`/`net`/`http` prüft); das ist ein eigenständiger Task für einen späteren Plan.
|
|
Getestet mit dem Konsolenkommando `wdtest`
|
|
(src/sys/nl_console_cmd.c, src/sys/nl_console.c): es hält `nl_app_lock()` für immer, wodurch
|
|
`light_task` und `app_task` blockieren und der Watchdog den Chip zurücksetzen muss.
|
|
5. `Platform/Drivers/internalflash/wm_internal_fls.c`: Semaphor `s_fls2_lock` serialisiert den Flash-Pfad
|
|
oberhalb von 1 MB (Pin-Umschaltung via `tls_spifls_cs/ck/di/do_switch` war ungeschützt).
|
|
T1 (Plan 2 final review): `tls_fls_init()` ignorierte den Rückgabewert von
|
|
`tls_os_sem_create(&s_fls2_lock, 1)` stillschweigend - jetzt eine `printf()`-Meldung
|
|
(`TLS_DBGPRT_ERR` ist in diesem Build wegkompiliert), falls das Anlegen fehlschlägt
|
|
(dann bliebe der Bereich oberhalb von 1 MB unprotokolliert ungeschützt).
|