test0r
e580126d84
Sets up the BES2600 mainlining work tree with: - README: project overview, hardware target, driver lineage (CW1200 -> Bestechnic -> arjan-vlek -> Mobian/danctnix), patch series status, repo map, build/deploy workflow. - patches/: c1 patch generated by git format-patch from marfrit/bes2600-dkms branch bes2600/factory-request-firmware (checkpatch.pl --no-tree --strict: 0 errors / 0 warnings / 0 checks). - scripts/: build-bes2600-on-ohm.sh, deploy-c1-to-ohm.sh, backup-ohm-kernel.sh - reproducible build + deploy + backup. - fw-analysis/: per-blob strings.txt + fnnames.txt extracted from the 4 firmware blobs pulled from ohm 2026-04-21. Source binaries NOT committed (Bestechnic-proprietary). - notes/: observed-bugs.md (4 known bug surfaces with file:line + patch-series cross-reference), source-map.md (every public driver source variant + their canonical role). Companion work tree: marfrit/bes2600-dkms (Mobian DKMS fork) at git.reauktion.de. Signed-off-by: Markus Fritsche <fritsche.markus@gmail.com>
3.4 KiB
Observed BES2600 driver bugs on PineTab2 (ohm)
Compiled from on-device dmesg + Pine64 wiki + community reports. Cross-references the patch series.
Bug #1 — factory.txt path mismatch + filp_open antipattern (FIXED in c1)
File: bes2600_factory.c:148-170 (read), :188-200 (create)
Symptom (pre-fix):
(NULL device *): read and check /lib/firmware/bes2600_factory.txt error
Root cause: hardcoded FACTORY_PATH=/lib/firmware/bes2600_factory.txt Makefile macro;
real file ships at /lib/firmware/bes2600/bes2600_factory.txt. Worse, the read uses
filp_open + kernel_read directly, bypassing the firmware-class infrastructure.
Fix: c1 patch — request_firmware() for the read path, repointed Makefile macro
to firmware-class name bes2600/bes2600_factory.txt.
Bug #1.5 — factory.txt parse failure (NEW, c5 to investigate)
File: bes2600_factory.c factory_parse()
Symptom (post-c1):
bes2600_factory.txt parse fail
read and check bes2600/bes2600_factory.txt error
factory cali data get failed.
How discovered: c1 fix exposed a deeper bug — factory_parse() chokes on the data
that request_firmware() now successfully returns. The original bug masked this
because the read always failed first.
Hypotheses: null-termination assumption mismatch (request_firmware doesn't
null-terminate), FACTORY_MEMBER_NUM=30/31 count discrepancy, kmalloc not
zero-initialized, parser strict on trailing %%\n delimiter.
Status: investigation pending (task c5). Driver falls back to defaults; WiFi functional but TX power is uncalibrated (all channels at 0x1400).
Bug #2 — PM low-power handshake timeout (recurring)
File: bes_pwr.c:470-558 — bes2600_pwr_enter_lp_mode(). Error at line 538.
Symptom:
bes2600_wlan mmc2:0001:1: bes2600_pwr_enter_lp_mode, wait pm ind timeout
Fires every 5–10s in steady state when associated. Floods dmesg, likely correlates with bug #3 (SDIO TX stack splat) and bad battery life.
Root cause: wait_for_completion_timeout(&pm_enter_cmpl, 5*HZ) waits
for firmware to acknowledge a PM mode change; firmware never sends ACK.
Driver proceeds to bes2600_pwr_device_enter_lp_mode() regardless.
Mobian == danctnix: identical bes_pwr.c (1447 lines, 0-hunk diff). No upstream fix exists; we'd invent it (gate device-LP entry on completion + add retry).
Status: task c2.
Bug #3 — SDIO TX scatter-gather panic / WARN
File: bes2600_sdio.c:952-1200 — bes_sdio_memcpy_to_io_helper,
sdio_tx_work.
Symptom:
[RX] Receive failure: 4.
bes_sdio_memcpy_to_io_helper+0x18c/0x288 [bes2600]
sdio_tx_work+0x2b4/0x4a0 [bes2600]
Workqueue: bes_sdio sdio_tx_work [bes2600]
Recurring under TX load. Can wedge the chip irrecoverably (per Pine64 wiki: "Power/reset circuitry not properly implemented; hard reset impossible without board power-cycle").
Status: task c3 (indirectly, via bes_chardev removal which currently gates the signal/nosignal mode switch path).
Bug #4 — scan_complete_cb constant loop
File: scan.c:883-909 — bes2600_scan_complete_cb().
Symptom:
ieee80211 phy0: bes2600_scan_complete_cb status: 0
Fires every 2–10s (status=0 = success, but the FREQUENCY suggests background scanning runs continuously when associated + idle).
Most likely a NetworkManager scheduling artifact, not a driver bug. Low priority; suppress the wiphy_dbg print or skip scan-on-assoc'd if it matters.