diff --git a/cspell.yaml b/cspell.yaml index cf52548..564a7d0 100644 --- a/cspell.yaml +++ b/cspell.yaml @@ -176,6 +176,13 @@ words: - opmode - opmodes - HRAIJ + - Quansheng + - Kenwood + - FTDI + - Flytek + - Xtensa + - FLIX + - teardown patterns: - name: markdown_code_block pattern: /^\s*```[\s\S]*?^\s*```/gm diff --git a/hardware/c62.md b/hardware/c62.md index aedacbc..69bd998 100644 --- a/hardware/c62.md +++ b/hardware/c62.md @@ -1,135 +1,202 @@ # Retevis C62 -## Development Status +The Retevis C62 is a 5 W dual-band handheld built around a ListenAI CSK6011B, a +multi-core SoC that pairs an ARM Cortex-M33 application core with a Cadence HiFi4 +DSP and a small NPU. The DSP and NPU drive the radio's "AI noise reduction". RF +is handled by a BK4819, the same chip found in the Quansheng UV-K5, with a BK1080 +for broadcast FM. -There is a functional port for OpenRTX currently in development. Right now, the main functions (boot, display, keys) function as expected. However, there has been a significant challenge in getting the DSP coprocessor to cooperate to allow for audio in/out, including for analog FM. For now, There is a workaround for FM RX (and only RX) that involves an ET3157 analog switch that is present on the board; it allows for the BK4819's "earphone output" to be piped directly to the speaker. +## Development status -**⚠️ Important Note: The Retevis C62 is not yet ready to run M17 protocol. While the hardware is capable of supporting M17, firmware development is currently in progress.** +This is a work in progress, not a finished firmware. What works today on the +[`retevis_c62-pr`](https://github.com/OpenRTX/OpenRTX/pull/415) branch: -The C62 was identified as a candidate for M17 development after discovering an undocumented DMR-like digital mode in its factory firmware, which prompted investigation into its suitability for open-source protocol implementation. +- Boot, display, keypad +- Analog FM RX and TX -## Device Models -- Retevis C62 5W Long Range UV Dual Band Business Radio +M17 and other digital modes do not work yet. The blocker is audio. The +CSK6011B's ADC and DAC are owned by the HiFi4 DSP, and OpenRTX reaches them +through a closed-source DSP firmware from ListenAI's SDK (see +[DSP firmware](#dsp-firmware) below). That firmware only samples at 16 kHz, +whereas M17 needs 24 kHz, so the receive path requires a resampling stage that is +still under development. ## Specifications -### General Specifications -* **Power Output**: 5W -* **Frequency Bands**: Dual Band (136-174, 400-520MHz. Chip technically capable of 18-1300MHz; feasible range TBD) -* **Display**: ST7735R display controller -* **Battery**: TBD -* **AI Noise Reduction**: Built-in AI noise reduction technology +* **MCU**: ListenAI CSK6011B (Cortex-M33, HiFi4 DSP, NPU) +* **RF front-end**: BK4819 (as in the UV-K5) +* **Broadcast FM**: BK1080 +* **Display**: ST7735R +* **Flash**: 4 MB SPI NOR (PY25Q32HB) +* **Battery**: Retevis BL2, 2S Li-ion, 2 Ah, 14.8 Wh +* **Power output**: 5 W +* **Bands**: 136 to 174 MHz and 400 to 520 MHz. The BK4819 covers a much wider + range, the usable range on this hardware is still TBD. -## Hardware Configuration +### Hardware images -### Key Components -* **Main MCU**: ListenAI CSK6011B -* **RF Front-end**: BK4819 (same chip used in UV-K5 radios) -* **FM Receiver**: BK1080 - -### Hardware Images - -#### Main Processor (CSK6011B) +#### Main processor (CSK6011B) ![CSK6011B Main Processor](../_media/c62_csk6011b.jpeg) -#### RF Front-end (BK4819) +#### RF front-end (BK4819) ![BK4819 RF Chip](../_media/c62_bk4819.jpeg) -#### Main Board Overview +#### Main board overview ![C62 Main Board](../_media/c62_mainboard.jpeg) -## Development Environment +## Programming cable and entering burn mode + +All of the steps below run over the Kenwood-style speaker/mic jack, so there is +no need to open the radio. Any Baofeng/Kenwood K-plug USB cable works, and a +TalkPod A36 cable is also confirmed. The boot ROM's UART shares pins with the PTT +lines, which is why the entry procedure matters. + +`cskburn` normally drives the BOOT and RESET pins over RTS/DTR, but a two-wire +radio cable exposes neither. On the C62 the CSK6011B enters UART burn mode when +its `GPIO_B_01` strap is held low at power-on, and that pin is wired to the +**secondary PTT**, the lower side key. The sequence is: + +1. Radio **off**. +2. Hold the **secondary PTT** (lower side button). +3. Power the radio on, then release the button. + +The screen stays dark in burn mode. That is expected, not a dead radio. Do not +press the main PTT while flashing, because that line is the boot-ROM UART RX. If +a command reports "device did not respond after reset", the radio was not in burn +mode. Repeat the sequence. + +## cskburn + +Flashing and dumping use [`cskburn`](https://github.com/LISTENAI/cskburn). +Download a prebuilt binary from its releases page. The CSK6 chip family is +selected with `-C 6`. Reading flash uses the `--read` option. + +A reliable serial adapter matters more here than usual. FTDI-based cables often +refuse baud rates above 115200 with `cskburn`, and some PL2303 clones stall +during long sustained reads. Use 115200 unless your adapter is known to handle +more. -### Docker Setup -The C62 development environment uses Docker for cross-platform compatibility: +## Backing up the factory firmware + +Do this before flashing anything, as it is the only way back. The flash is 4 MB, +so read the full `4194304` bytes: + +```bash +cskburn --read "0x0:4194304:factory.bin" -C 6 -b 115200 -v -s /dev/ttyUSB0 +``` + +If the read stops partway through, which flaky adapters do on the full 4 MB, read +it in smaller regions and concatenate them. `cskburn` accepts several `--read` +arguments in one session, and `--no-reset` keeps the radio in burn mode between +regions: ```bash -docker run --platform linux/amd64 --privileged -v /dev:/dev -v /run/udev:/run/udev -it listenai/csk6:latest +cskburn --read "0x0:0x100000:p0.bin" \ + --read "0x100000:0x100000:p1.bin" \ + --read "0x200000:0x100000:p2.bin" \ + --read "0x300000:0x100000:p3.bin" \ + --no-reset -C 6 -b 115200 -s /dev/ttyUSB0 +cat p0.bin p1.bin p2.bin p3.bin > factory.bin ``` -**Note**: The `--platform linux/amd64` flag is required only when developing on M-series Mac computers. +Factory images are per-device. There is a serial number and calibration blob +around offset `0xA4010`, so an image from one radio will not run correctly on +another. Name your dumps by serial number. + +## Building + +The board target lives on the `retevis_c62-pr` branch of OpenRTX and builds +against ListenAI's Zephyr fork (Zephyr 3.1 era, hardware model v1). Mainline +Zephyr does not contain CSK6 support. The branch's `west.yml` references an +upstream Zephyr revision, but the working build uses the fork that ships inside +ListenAI's container image, so the simplest path is to build in that container. + +```bash +docker pull listenai/csk6:latest +# --platform linux/amd64 is only needed on Apple silicon +docker run --privileged -v /dev:/dev -v /run/udev:/run/udev \ + -v "$PWD":/OpenRTX -it listenai/csk6:latest +``` + +Inside the container, from the repository checkout: + +```bash +lisa zep exec ./run_build_c62.sh +``` + +`run_build_c62.sh` drives the build through Meson. Its `openrtx_c62` target runs +`west update --group-filter +c62` to pull the C62-only dependencies, then +`west build -b c62`. Two things to know: + +- The stock image does not ship Meson. Install it first with + `pip install meson` inside the container. +- The C62-specific modules (`af`, `lsf`, `urpc`, `freertos_shims`) are only + fetched when the `+c62` west group is enabled, which is why the build passes + `--group-filter +c62`. + +The output is `build/zephyr/zephyr.hex`, roughly 340 kB of code. RAM is the tight +resource, sitting around two-thirds full. + +## Flashing OpenRTX + +Put the radio in burn mode, then write the application at `0x0`: + +```bash +cskburn -s /dev/ttyUSB0 -C 6 -b 115200 0x000000 build/zephyr/zephyr.hex +``` + +A build that uses the DSP for audio, meaning anything beyond the FM-RX analog +workaround, also needs the DSP firmware at `0x100000`, described below. +`cskburn` resets the radio when it finishes, so re-enter burn mode before each +command. All OpenRTX log output returns over the same UART at 115200. + +To restore the factory firmware, write your backup at `0x0` the same way. -### Required Hardware -* **Programming Cable**: TalkPod A36 (recommended) -* **Debug Access**: Debug pads located on opposite side of CSK6011B chip +## DSP firmware -## Firmware Development +Audio on this radio does not run on the Cortex-M33. The CSK6011B's ADC and DAC +belong to the HiFi4 DSP, and the M33 reaches them by remote procedure calls to a +firmware image running on the DSP. OpenRTX loads that image from flash at boot, +from the `dsp_firmware` partition at `0x100000`. -### Firmware Extraction -To extract the original firmware for analysis: +There is no open DSP firmware yet, so the port uses the example blob from +ListenAI's [`lsf-zephyr-sdk`](https://cloud.listenai.com/listenai/lsf-zephyr-sdk), +found at `resources/dsp_firmware.bin` (about 443 kB). Flash it once: ```bash -cskburn --read "0x0000000:4096000:app.bin" -C 6 -b 115200 -v -s {device} +cskburn -s /dev/ttyUSB0 -C 6 -b 115200 0x100000 dsp_firmware.bin ``` -**Parameters:** -- `0x0000000:4096000:app.bin`: Read 4MB starting from address 0x0 -- `-C 6`: Communication parameter 6 -- `-b 115200`: Baud rate 115200 -- `-v`: Verbose output -- `-s {device}`: Specify device path - -### Development Tools -* **Reverse Engineering**: Ghidra with armv8-LE processor definitions -* **Firmware Tool**: Modified cskburn from OE3ANC - -## Hardware Disassembly - -### Disassembly Process -1. Remove 4 corner screws from the radio case -2. Carefully disconnect the volume knob -3. Disconnect the antenna connection -4. Remove the screen carefully (secured by 2 clips) -5. Separate internal components to access main board -6. Locate debug pads on the opposite side of the CSK6011B chip - -**⚠️ Caution**: Handle internal components with care, especially the screen and cable connections. - -## Build Instructions - -### Development Environment Setup -1. Install Docker on your development machine -2. Pull the ListenAI CSK6 development image: - ```bash - docker pull listenai/csk6:latest - ``` -3. Run the development container with appropriate permissions -4. Set up the modified cskburn tool for firmware operations - -### Firmware Development Status -* **Current Status**: Firmware development in progress -* **Memory Mapping**: Incomplete - community contributions welcome -* **Decompilation**: Partial success with Ghidra armv8-LE definitions -* **Target Protocol**: M17 implementation planned - -## Technical Notes - -### Unique Characteristics -* Undocumented digital mode discovered in factory firmware -* Shares BK4819 RF chip with popular UV-K5 platform -* ListenAI CSK6011B processor offers development potential -* Hardware architecture suitable for M17 protocol implementation - -### Development Challenges -* Incomplete memory map requires further reverse engineering -* Decompilation accuracy needs improvement -* Community contributions needed for complete chip understanding - -### Hardware Compatibility -* BK4819 RF chip provides proven radio frequency performance -* CSK6011B processor architecture supports complex protocol development -* Hardware debugging access available through exposed pads - -## Community Development - -The C62 development effort welcomes community contributions, particularly in: -* Complete memory map development -* Improved decompilation accuracy -* M17 protocol firmware implementation -* Hardware debugging and analysis - ---- - -*Hardware analysis and development information from:* -- *GitHub Repository: https://github.com/JKI757/C62_Teardown* -- *Official Product Information: https://www.retevis.com/retevis-c62-5-w-long-range-uv-dual-band-ai-noise-reducation-business-radio-us* +Two blobs are in circulation. The one in `lsf-zephyr-sdk` works. The smaller one +in the separate `lsf-dsp-firmware` repository does not, because its RPC bindings +do not match. The radio's own factory DSP firmware, whose header starts with +`IFLY` (iFlytek), uses a different and undocumented RPC protocol and cannot be +reused as-is. + +The example blob is a HiFi4 build of an Android-style AudioFlinger and AudioMixer +stack plus a WebAssembly runtime for the NPU. Its limitations are what currently +hold back M17. It only exposes 16 kHz sampling, and it logs to the same UART pins +OpenRTX uses. A proper open DSP firmware, or ListenAI releasing the example +source, is the preferred long-term fix. + +## Reverse engineering + +The DSP core is Xtensa HiFi4. In Ghidra, `Xtensa:LE:32:default` produces +reasonable disassembly for the DSP portions. The NPU and WASM parts are a +separate problem. It is a custom Xtensa configuration with TIE and FLIX +extensions, so some instructions fall outside Ghidra's stock processor module. +The Cadence `venus_hifi4` core bundle documents them. + +Building your own DSP code is possible without a paid license. The Cadence +XtensaTools RI-2021.7 toolchain and the `venus_hifi4` core files are +downloadable, and once the core parameters are fixed up they build for +`XTENSA_CORE=venus_hifi4`. This is not needed to run OpenRTX. It matters only for +lifting the 16 kHz limit or writing a fully open DSP firmware. + +## References + +- [OpenRTX C62 support PR](https://github.com/OpenRTX/OpenRTX/pull/415) +- [C62 teardown, pinout and schematics](https://github.com/JKI757/C62_Teardown) +- [cskburn](https://github.com/LISTENAI/cskburn) +- [ListenAI LSF Zephyr SDK](https://cloud.listenai.com/listenai/lsf-zephyr-sdk) +- [Product page](https://www.retevis.com/retevis-c62-5-w-long-range-uv-dual-band-ai-noise-reducation-business-radio-us)