=============================== ADSP and CDSP firmware =============================== ``modem_a`` and ``dsp_a`` hold the non-HLOS Hexagon-DSP firmware. Both partitions are **filesystems**, not bare ELFs — the partition format is FAT16/ext4 (below), not the first *embedded* ELF at ``modem_a`` ``0x4b000``: - ``modem_a`` (195 MB) is a **FAT16** filesystem (``MSDOS5.0`` / ``FAT16`` boot sector at offset 0, ``0x55aa`` at ``0x1fe``) — the Qualcomm **``/firmware``** peripheral-image repository. It holds the split-loaded MBN images (``image/.mdt`` = ELF header + program table + type-2 HASH segment, with the payload in sibling ``.bNN`` files) for **modem/MPSS, adsp, cdsp, npu, venus** (video), plus **WLAN** (``wlanmdsp.mbn``), a set of QSEE trustlets (``qwes``, ``soter64``, ``smplap32/64``, ``gptest``, ``featenabler``, ``rtic``, and **``widevine.mbn``** — the DRM TA; cross-ref :doc:`/trustzone/secure-world`), and the ``modem_pr/`` carrier tree (**139** ``mcfg_sw`` + 4 ``mcfg_hw`` + 12 QMI ``.so``). ``verinfo/ver_info.txt`` records the meta-build **``Bitra.LA.3.2.1-00040-STD.PROD-2``** (2024-08-20). - ``dsp_a`` (64 MB) is an **ext4** filesystem (magic ``0xef53`` at ``0x438``, volume label ``dsp``) — the **``/dsp``** mount. It holds **FastRPC user-PD dynamic libraries** (``adsp/`` audio codecs + fluence + sensor skels; ``cdsp/`` compute/VPP/HTA skels + ``libc++``), **not** DSP boot firmware. So the CDSP/ADSP *boot* images live in ``modem_a``; ``dsp_a`` only carries their loadable user-space libraries. - ``core_nhlos_a`` (170 MB) is a **second FAT16** ``image/``+``verinfo/`` pack, byte-identical boot sector to ``modem_a``, carrying the **production** modem (``MPSS.HI.2.5.1-01188-BITRA_GEN_PACK-1``) and the WLAN firmware — whereas ``modem_a`` embeds a **test** modem variant (``MPSS.HI.2.5.1-01197-BITRA_GENNM_TEST-1``); the two partitions carry different MPSS builds. **No separate SLPI subsystem exists** — there is no ``slpi.*`` image in ``modem_a`` and no ``slpi/`` tree in ``dsp_a``; on this SM6350 build the sensor stack runs on the **ADSP** island (the ``SENSOR_IMG_bitra.adsp`` map and ``sns_bring_to_ear.so`` under ``dsp_a:adsp/``). Full per-file inventory and program-header dumps: ``artifacts/re_static/item6_modem_dsp_inventory.txt``. This page catalogs the human-readable config/manifest strings and the container structure; no code was executed. ``modem_a`` is **not** an ADSP-only image — it is a multi-subsystem non-HLOS bundle. It embeds four subsystem metadata blocks, each with its own ``QC_IMAGE_VERSION_STRING`` + ``IMAGE_VARIANT_STRING``: ``ADSP.VT.5.6-00702.1`` (``bitra.adsp.prodQ``), ``CDSP.VT.2.6-00570.1`` (``bitra.cdsp.prodQ``), ``MPSS.HI.2.5.1-01197-BITRA_GENNM_TEST`` (``bitra.gennm.testQ``), and ``NPU.FW.2.3-00083`` (``bitra.npu.prodQ``). String census confirms both the ADSP sensor/audio code (``sns_`` ×2178, ``adsp_proc`` ×182) **and** real MPSS baseband code (``wcdma_`` ×414, ``rrc_`` ×354, ``nas_`` ×299, ``qmi_`` ×305, ``policyman`` ×173, plus ``modem_proc/…`` build paths) are present. The MPSS baseband is **dormant**, not absent: this is a Wi-Fi-only device with no cellular RF front end (see the RF-leftover notes below), so the flashed generic-Bitra modem stack is never brought up. The sibling ``core_nhlos_a`` partition is a second non-HLOS pack (``MPSS.HI.2.5.1-01188-BITRA_GEN_PACK``, ``bitra.gen.prodQ``) that additionally carries the **WLAN firmware** — ``WLAN.HL.3.3.1-01884-QCAHLSWMTPLZ-1`` — i.e. the Wi-Fi radio firmware this e-reader actually uses. WLAN (Helium) is the WLAN side of the **WCN3990** combo; its Bluetooth/FM side (Cherokee) firmware lives in the ``bluetooth_a`` partition (:doc:`/wireless/bluetooth`). ADSP (within modem_a) ===================== ``ADSP.VT.5.6-00702.1-BITRA-1``, built 2023-08-24 (``CRMBuilds/ADSP.VT.5.6-00702.1-BITRA-1_20230824_021423``), builder ``xcq``, tree ``sm6350_androidT_rom``, variant ``bitra.adsp.prodQ``. Runs the SEE / SSC sensor stack + AVS audio stack + sensor/PMIC/thermal proxies. This is the ADSP sub-image of the ``modem_a`` bundle described above (which also embeds the MPSS, CDSP, and NPU sub-images). Sensors (SEE — Sensors Execution Environment) --------------------------------------------- - Physical IMU: ``LSM6DST`` (STMicro 6-axis accel+gyro) — the one identified sensor part (drives auto-rotate / orientation). Consistent with the DTB's minimal sensor set (:doc:`/boot/dtbo` adds a Hall sensor + Wacom via the SoC/overlay side, not ADSP). - Sensor framework internals: ``sns_*`` heap/instance manager, protection domain ``sensor_pd`` (``subdomain":"sensor_pd"``), virtual sensors ``motion_detect`` and ``sns_bring_to_ear.so`` (proximity/gesture), ``-sensor_name=`` / ``-sensor=`` registry plumbing. - Sensor power/thermal proxies: ``/node/pmic/client/sensor_vdd[/_2]``, ``sensor_vddio[/_2]``, ``sensor_dsp_proxy``, ``/therm/sensor`` — sensors GDSC power-domain gating (``Disabling Sensors GDSC``), ``LPI/LPR Registry``. Audio (AVS) ----------- - Bluetooth/stream codecs: ``AAC``, ``aptX``, ``SBC``, plus ``CELT`` (Xiph libcelt — Opus/CELT). - Voice/ML: ``EAI`` ML/NN algorithms (``eai_lib/ml_common/.../nn/{layer,network}_init``) — on-DSP neural-net audio; ``Listen`` / ``ListenStreamManager`` (voice-UI / hotword listen path); ``HVX`` vector algorithms. - Standard AVS audio encode/decode + calibration. Thermal monitoring (sysmon /therm/sensor) ----------------------------------------- Active thermal read/sample nodes: ``xo_therm``, ``pa`` / ``pa_1``, ``modem_tsens`` / ``modem_tsens1``, ``modem_bcl_warning`` (battery-current-limit warning). Sampled via ``/therm/sensor/%s/sampling``. Reference-base leftovers (present but not wired) ------------------------------------------------ - mmWave/5G RF thermals: ``BEAMER_{E,N,W}_THERM``, and a large ``qfe_mmw{0..3}``, ``qfe_mmw_streamer0``, ``qfe_wtr_pa{0..4}[_fr1]``, ``qfe_ret_pa0[_fr1]`` set — RF PA / mmWave front-end thermal zones. - RF-card hwids: ``rfc_hwid629/630/833_mmwave_sm6350_{na,row,qtm535}`` — 5G RF-card platform detect. - VoWiFi/ePDG carrier config: an ```` / ```` XML block (``throttling_series``, ``cause_code 10500``, ``esp_auth_algo_list``, ``across_epdg=TRUE``) — Wi-Fi-calling IPsec/IKEv2 data config. This is the "thermal throttling XML" of :doc:`/open-questions`; it is ePDG PDN throttling (modem data-services config), not thermal. These mmWave/5G thermal zones and RF-card hwids are stock SM6350 RF assets carried unchanged with no matching RF hardware — the same class of leftover as the XBL AMOLED panel (:doc:`/boot/boot-image`). Note the distinction from the MPSS baseband proper (RRC/NAS/WCDMA/QMI/policyman) documented in the bundle overview above: that is real, complete modem code — merely dormant for lack of a cellular front end — whereas these thermal/RF-card entries are unpopulated configuration for absent boards. CDSP — dsp_a ============ ``CDSP.VT.2.6-00570.1-BITRA-1``, built 2024-02-07 (``CRMBuilds/CDSP.VT.2.6-00570.1-BITRA-1_20240207_034818``), variant ``bitra.cdsp.prodQ``. Hexagon compute DSP (QuRT RTOS), reached from HLOS via fastRPC. Handles general offload, video post-processing, NN/tensor acceleration, and protected-content compute. Execution model --------------- - fastRPC transport: ``_pl_fastrpc_{invoke,smd,mem,uprocess,exception}``, ``__fastrpc_sys_mmap``. - Protection domains via signed/unsigned PD shells: ``fastrpc_shell_3`` (signed) and ``fastrpc_shell_unsigned_3`` (unsigned PD — allows unsigned test offload), plus ``fastrpc_shell_0`` (ADSP-side). Capabilities (fastRPC dynamic modules / \*_skel.so) --------------------------------------------------- .. list-table:: :header-rows: 1 :widths: 52 48 * - Module(s) - Function * - ``libvpp_svc_skel`` + ``libvpp_{nr,mvp,aie,qbr}.so``, ``ubwcdma_dynlib`` - Video Post-Processing — noise-reduction (nr), motion-vector (mvp), AIE, QBR; UBWC compressed DMA * - ``libhta_dsp_skel`` (``npu/hta``) - HTA — Hexagon Tensor Accelerator (NPU): on-DSP neural-net inference * - ``dspCV`` / FastCV (``CV/fastcv``, ``gaussian7x7_asm``, HVX) - computer-vision primitives * - ``libsysmon_skel``, ``libsysmonhvxthrottle_skel``, ``libsysmonquery_skel``, ``libsysmondomain_skel`` - DSP sysmon: HVX clock throttling, load/thermal query * - ``libstabilitydomain_skel``, ``libbenchmark_skel``, ``libloadalgo_skel`` - stability/PD watchdog, benchmark, dynamic-algo loader * - ``libadsp_default_listener1_skel`` - default listener PD SecurePD (secure protection domain) ----------------------------------- - Present: ``secure_pd_{mailbox_send,mb_get,mb_receive,mb_delete,thread_create}``, ``secdsplib2``, ``core/securemsm``. The shipped example SecurePD is a ``gaussian`` HVX algo under ``platform/securepd/example/{gaussian,proxy}`` (``loadalgo_skel``, ``example_algo.c``). - This is the CDSP side of protected-content compute — it pairs with the TZ Widevine OEMCrypto path in ``devcfg`` (``tzdrm/widevine_oemcrypto``, :doc:`/open-questions`): DRM/secured buffers can be processed inside a CDSP SecurePD isolated from the normal (unsigned) PDs. - The HTA/NPU module builds from a ``saipan.cdsp.prod`` sub-tree (shared NPU module reused across SoCs) while the rest is ``bitra.cdsp.prod`` — a build-tree leftover, not a functional difference. Both are test-key-signed where a chain is present (consistent with :doc:`/boot/secure-boot`, :doc:`/open-questions`). Nothing here changes the boot-chain/security findings; this catalogs functionality only. Audio hardware fabric (LPASS / bolero codec) ============================================ The **AVS** firmware above runs on the Q6 audio DSP inside LPASS; this is the hardware path it drives, for completeness. LPASS is loaded by PIL like the other subsystems — ``qcom,lpass@3000000`` (``qcom,pil-tz-generic``, ``xo`` proxy clock) — so the only *firmware* below userspace here is the ADSP/AVS image already catalogued; the blocks below are HW driven by that DSP over the APR (``qcom,msm-audio-apr`` → ``qcom,q6core-audio``). - **Bolero on-SoC digital codec** (``bolero-cdc``) with three macros in the LPASS register band: ``rx-macro@3200000`` (playback), ``tx-macro@3220000`` (mic/capture), ``wsa-macro@3240000`` (speaker / WSA path). No ``va-macro`` (voice-activation) is instantiated. - Each macro fronts a **SoundWire** master: ``swr1`` = rx, ``swr2`` = tx, ``swr0`` = wsa (aliases in the tree). - **External codec: WCD938x** (Qualcomm WCD9380/85) on the rx/tx SoundWire buses, hardware-reset through TLMM (``wcd938x_reset_active`` / ``_sleep`` pinctrl states, :doc:`/soc/pinctrl`). - **USB-C headset**: an ``fsa2275`` analog audio switch (GPIO-managed, :doc:`/soc/pinctrl`) routes analog audio over the Type-C connector. - **DAIs**: MI2S, CDC-DMA (the bolero DMA lanes) and the Q6 AFE DAIs. The ``qcom,msm-dai-q6-hdmi`` DAIs are present but **vestigial** — there is no HDMI on this device (:doc:`/soc/absent-hardware`). BT/FM audio rides the WCN3990 on SLIMbus (:doc:`/wireless/bluetooth`). - **Clocks**: ``vote_lpass_core_hw`` / ``vote_lpass_audio_hw`` (``qcom,audio-ref-clk``) and ``bolero-clk-rsc-mngr``, fed from the RPMh CXO (:doc:`/soc/clocks`). Nothing here adds a firmware blob below userspace beyond the ADSP/AVS image; the codec fabric is hardware the DSP and kernel drive. Hexagon instruction-level disassembly ====================================== Everything above this section was derived from container/header parsing and string mining. This section adds an instruction-level pass: a Hexagon disassembler is available in this environment — ``llvm-objdump`` (LLVM 23.1.1, under the pixi toolchain at ``~/Library/0.UserLibrary/bin/pixi/bin/llvm-objdump``) lists ``hexagon - Hexagon`` among its registered targets and correctly decodes these images. This section reports what a real instruction-level pass over the ADSP, CDSP, MPSS and NPU images actually found. Full raw disassembly excerpts, the extraction/repackaging method, and the sanity checks used to confirm the decode is genuine (not tool noise) are in ``artifacts/re_static/item_hexagon_dsp_disasm.txt`` — this section summarizes and does not repeat that file's content verbatim. Method, in brief ----------------- - ``modem_a`` uses the **split PIL form**: each ``.mdt`` is a small ELF32 header + program-header table + HASH segment only (confirmed 7.5–9.3 KB each); every ``PT_LOAD`` segment's actual bytes live in a sibling ``.bNN`` file, where ``NN`` is the zero-padded **program-header index** — verified empirically by matching each non-zero-filesz phdr's ``filesz`` to its ``.bNN`` file size exactly, for both ``adsp.mdt`` and ``cdsp.mdt``. - This build's ``llvm-objdump`` has **no raw-binary mode** (no ``-b binary``/``--target=binary``, confirmed via ``--help``): it only disassembles real object files. Each ``.bNN`` blob is therefore repackaged into a minimal synthetic ELF32 (``e_machine=0xA4`` / ``EM_HEXAGON``, one ``PT_LOAD`` + one executable-alloc ``.text`` section at the segment's real vaddr, taken from the ``.mdt`` program header) before disassembly. Script: ``artifacts/re_static/hexdis_wrap_elf.py``. The result is independently reproducible from the extracted ``.bNN`` files. Verifying the decode is genuine -------------------------------- Confirmed on several independent grounds (detailed in the deliverable file): ``llvm-objdump -f`` on the synthetic ELF reports ``elf32-hexagon`` purely from the ``e_machine`` field we set, i.e. the tool engages its real Hexagon decoder; standard VLIW packet syntax (``{ instr ; instr }``), ``immext`` constant extension, predicated (``if (p0.new) ...``) and ``.new``-forwarded forms, and recognizable ABI idioms (``allocframe``/``dealloc_return`` prologue-epilogue pairs, ``call``/``callr``/``jumpr r31``) appear throughout; and the **reset-vector bytes at the base of the ADSP, CDSP, MPSS and NPU code segments decode identically** across all four independently-built images (``ADSP.VT.5.6``, ``CDSP.VT.2.6``, ``MPSS.HI.2.5.1``, ``NPU.FW.2.3``, all 2023–2024 "BITRA" builds) despite each loading at a different vaddr — four separately-built images sharing byte-identical code is not explainable by decoder noise. What it decodes to: a 7-entry self-looping exception-vector table, one real vector jumping to an init routine, then ``r0=#0; ssr=r0; r0=syscfg; setbit x2; syscfg=r0; dckill; ickill; jump `` — the textbook Hexagon/QuRT reset-vector idiom (cache-kill + SSR/SYSCFG init). ``--mcpu=hexagonv66`` vs. the tool's implicit default produced byte-identical output on every excerpt checked. Findings -------- - **Shared QuRT crt0**: ADSP, CDSP, MPSS and NPU each start with the byte-identical reset-vector + early software-TLB-refill-handler sequence (``tlbp``/``tlbr``/``tlbw``/``isync`` walking and installing a TLB entry via a PC-relative page-number computation) — i.e. all four Hexagon cores on this SoC boot through the same compiled QuRT reset stub, just linked at different load addresses (``0xf0100000`` ADSP, ``0xfe000000`` CDSP, ``0xc0800000`` MPSS, ``0xb0000000`` NPU — ADSP and NPU's stubs are in fact byte-for-byte identical down to the internal jump offset, suggesting the literal same compiled object). - **Assert/logging call-site pattern**: in the ADSP's main ~2 MB R‑X segment, a recurring 3-``call`` sequence (fetch a guarded global via a small ``ugp``-null-checked helper, build a ``{ptr,0,0}`` struct on the stack, call a fixed helper, then call a second fixed helper passing a small integer in ``r1``) recurs at consecutive, monotonically increasing ``r1`` values (0x295, 0x359, 0x35c, 0x36d, …) consistent with source line numbers — the compiled shape of a FARF/assert-style logging macro invoked at many call sites. This is corroborated, not just guessed: the same image embeds the literal strings ``" -- assertion failed"``, ``"__assert"``, and ``"NULL ptr occurenaces in qurtos_free()"``, and the identical QuRT exception/TLB strings (``"!!! QURT_EXCEPT_FLOATING_POINT"``, ``"!!! QURT_TLB_MISS_*"``, ``"!!! Reserved vector Error"``) that match the reset/TLB code actually found. The callee address itself was **not** resolved to a name (no symbol table survives in these production MBN images — ``shnum=0`` in every ``.mdt``); the line-number correlation is inferential, not proven by a symbol. - **CDSP embeds full build source paths** confirming, beyond the header-level inventory above, that the NPU driver (``cdsp_proc/npu/npu_driver/*.c``) and FastRPC's invoke-path buffer-range validation (``cdsp_proc/platform/fastrpc_invoke/src/fastrpc_invoke.c``, with literal failed-assertion source expressions like ``br[ii]->start_vaddr <= br[ii]->end_vaddr``) are compiled into the CDSP image itself, not only into ``dsp_a``'s FastRPC skeleton libraries. Limits ------ No symbol table exists in any of these images, so every function identity above is inferred from calling convention and string cross-reference, never read from a name. Only small, targeted excerpts were disassembled — the boot vector plus roughly one function's worth of code per image; the multi-megabyte bulk of the AVS audio stack, the SEE sensor stack, and the CDSP FastRPC/NPU driver code were not walked function-by-function. MPSS's baseband protocol stack (RRC/NAS/QMI, confirmed present by the string census earlier in this page) was not disassembled beyond its reset vector — consistent with it being dormant firmware on this Wi‑Fi‑only device, a full baseband disassembly pass was not undertaken here. No HVX (vector-extension) instructions were encountered in the excerpts examined, and ``wlanmdsp.mbn`` (also Hexagon, per the inventory above) was not disassembled — the same method applies directly if needed. Modem NV storage (``modemst1``/``modemst2``) ================================================ Two small LUN5 partitions hold the modem's non-volatile item store — real data, not blank scaffolding, consistent with the dormant-but-present MPSS baseband documented above. Unlike ``fsg``/``fsc`` on the same LUN (confirmed all-``0x00``), ``modemst1.bin`` and ``modemst2.bin`` (2.5 MB each) are **99.59% non-zero**, and their SHA256 differ from each other (not an A/B mirror pair). Both open with a Qualcomm **EFS2** superblock: a 0x28-byte header whose two little-endian ``u32`` fields at offsets ``0x10``/``0x14`` each read ``0x0027fe00`` = 2,621,440 — the exact size of the 2.5 MB partition itself — followed by an ASCII magic at offset ``0x28`` that differs between the two: **``IMGEFS1&``** in ``modemst1.bin``, **``IMGEFS2%``** in ``modemst2.bin`` (consistent with the two being distinct primary/backup NV-store images, not a mirror pair). This is Qualcomm's modem-NV filesystem image format (``modemst1``/``modemst2`` are its conventional primary/backup NV-store partition names across Qualcomm platforms) — the NV store exists because the baseband image does, even though there is no cellular RF front end to use it. Past the header the two images diverge completely and are high-entropy (no readable strings beyond short printable runs consistent with packed binary NV-item records) — genuinely opaque without the EFS2 NV-item table format, which is not present anywhere in this dump (it lives in Qualcomm's NV-item build tooling, not on-device). :Source (modemst): ``../_READONLY/lun5/modemst1.bin``, ``../_READONLY/lun5/modemst2.bin``. :Method (modemst): header/magic read directly; distinct-byte-value scan for the 99.59%-non-zero figure; SHA256 compared between the two files. Provenance ========== :Source: ``../_READONLY/lun4/modem_a.bin``, ``../_READONLY/lun4/core_nhlos_a.bin``, ``../_READONLY/lun4/dsp_a.bin`` (read-only); subsystem identity from embedded ``QC_IMAGE_VERSION_STRING`` / ``IMAGE_VARIANT_STRING`` pairs and a baseband-vs- sensor string census. Audio-fabric nodes (``bolero-cdc`` macros, SoundWire masters, ``wcd938x`` reset states, ``qcom,lpass@3000000``, audio DAIs) from ``artifacts/boot_a/board.dts``. :Method: Located ELF start (zero-pad skip); ``strings`` mining for version tags, SEE sensor/registry names, ``/therm/sensor`` nodes, thermal/IKE XML, fastRPC ``*_skel.so``, and ``secure_pd`` / securepd paths; config blocks quoted from in-image strings. The "Hexagon instruction-level disassembly" section above supersedes this for actual machine-code analysis (``llvm-objdump``, target ``hexagon``) — see ``artifacts/re_static/item_hexagon_dsp_disasm.txt``. :Cross-refs: :doc:`/boot/secure-boot` (signing keys), :doc:`/boot/boot-image` (reference-base panel leftover), :doc:`/open-questions` (ADSP identity, Widevine OEMCrypto), :doc:`/boot/dtbo` (sensor overlays), :doc:`/soc/pinctrl` (WCD938x reset / fsa2275 pins), :doc:`/soc/clocks` (LPASS audio clocks), :doc:`/wireless/bluetooth` (WCN3990 SLIMbus BT/FM audio), :doc:`/soc/absent-hardware` (HDMI-audio DAIs).