Add warm SoC reset and two-stage watchdog escalation (WB85 only)#90
Closed
evgeny-boger wants to merge 2 commits into
Closed
Add warm SoC reset and two-stage watchdog escalation (WB85 only)#90evgeny-boger wants to merge 2 commits into
evgeny-boger wants to merge 2 commits into
Conversation
Warm reset pulses the PMIC RESET (PWROK) line for 100 ms instead of cycling the 5V rail. On WB 8.5 the line is wired to both the AXP15060 PWROK pin and the T507 RESET pin; with PMIC restart-on-PWROK-low disabled (AXP REG32[4]=0, the power-on default) the pulse resets only the SoC while all PMIC rails, including DRAM power, stay up. DRAM contents survive, so ramoops panic logs can be read back after reboot. Validated on WB 8.5.1: 16 MB test pattern survived EC-driven PWROK reset bit-perfect. The feature is gated by WBEC_HAS_WARM_RESET, defined only in config_wb85.h: the pulse behavior is hardware-validated on WB 8.5 only, so WB74 keeps its exact previous behavior (immediate hard power cycle on watchdog timeout, 2 s PMIC RESET hold on the reset_pmic request). On WB85 the watchdog escalates in two stages: the first timeout triggers a warm reset (new appended poweron reason 8, REASON_WATCHDOG_WARM); if Linux does not feed the watchdog via regmap before the next timeout, the EC falls back to the original hard power cycle (REASON_WATCHDOG). Feeding the watchdog re-arms the warm stage; a timeout-only regmap write restarts the timer but deliberately does not re-arm it. On WB85 the reset_pmic request from Linux (POWER_CTRL bit 2) now performs the short-pulse warm reset instead of the 2 s hold. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RiQPqJiM3ftEk3SDda31Kf
…light A watchdog timeout racing a 3.3V loss (or a reset_pmic request) in the same main loop pass started a second power sequence on top of the warm reset pulse already in flight. The pulse never completed, the PMIC RESET (PWROK) line stayed latched and the SoC was held in reset forever: 5V rail on, no SPL/U-Boot output ever, and no further watchdog recovery (the escalation was latched to hard resets, which did not release the line). Matches the failure observed on a WB 8.5.1 bench unit after a rapid kernel-hang reboot loop. The same race latched the line on WB74 via the reset_pmic request path. - wbec: allow only one power action per pass in WORKING; once a power sequence is started, defer the watchdog and 3.3V checks to the next passes (pending watchdog flags are not lost) - wbec: restart the escalation after a stage-2 hard reset so unfed timeouts alternate warm/hard; the first hang of every fresh boot gets a DRAM-preserving warm reset and ramoops stays readable - linux-power-control: hard_reset/hard_off/power-on always release the PMIC RESET (PWROK) line so no aborted sequence can leave it latched; a completed warm pulse turns 5V on before the power-on sequence - add wbec + linux-power-control + wdt integration test suite with a board model (PMIC/SoC/5V rail): reproduces the wedge, sweeps PMIC failure timing across all reset phases, asserts bounded recovery Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EVPkc2g2yir6SGyrED6uNT
Member
Author
|
Superseded by #91, which now targets |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Что происходит; кому и зачем нужно:
Тёплый сброс SoC и двухступенчатый watchdog на WB 8.5 (под гейтом
WBEC_HAS_WARM_RESET, толькоconfig_wb85.h):reset_pmicиз Linux (POWER_CTRL бит 2) теперь тоже выполняет короткий тёплый импульс вместо удержания до 2 с.Нужно поддержке и разработке: после паник и зависаний в поле остаются логи ядра. Парный PR ядра: wirenboard/linux#357, диагархив: wirenboard/wb-diag-collect#66.
Поведение WB74 не изменилось (гейт выключен: немедленный жёсткий сброс,
reset_pmic— старое удержание до 2 с).Что поменялось для пользователей:
На WB 8.5 после паники/зависания контроллер сначала перезагружается «тёпло» с сохранением логов; при неуспехе — жёсткий сброс, как раньше. Потребители
poweron_reasonдолжны считать watchdog-сбросом оба значения: 5 и 8. Для тёплого сброса требуется, чтобы в PMIC был выключен рестарт по PWROK (AXP REG32[4]=0 — заводское значение; парный kernel-PR чистит бит на probe).Как проверял/а:
wb-ec-firmware-update: паника → тёплый сброс → причина 8 → логи ramoops считаны (ECC: 0 ошибок); сохранение 16 МиБ паттерна в DRAM через сброс — bit-perfect; эскалация «тёплый → жёсткий» проверена юниттестами, вживую — только первая ступень.Покрыл/а изменения юниттестом и если нет, то почему:
Да: тайминг импульса тёплого сброса (граница WBEC_WARM_RESET_PULSE_MS), fallback на штатное включение при пропаже 3.3В, двухступенчатая эскалация с негативными проверками, сброс эскалации по «кормлению» watchdog, семантика fed-флага (в т.ч. запись только таймаута не сбрасывает эскалацию), поведение WB74 без гейта.
🤖 Generated with Claude Code