tobleminer / dialog-cr16c-uart-boot Goto Github PK

View Code? Open in Web Editor NEW

7.0 4.0 2.0 170 KB

Tools and utilities for booting Dialog SC14441 and similar MCUs via UART

License: MIT License

Makefile 1.42% Python 25.07% C 71.02% Assembly 2.49%

dialog-cr16c-uart-boot's Introduction

dialog-cr16c-uart-boot

Overview

UART bootloader for CR16C based Dialog DECT SoCs

gigaset-debug.mp4

dialog-cr16c-uart-boot works similar to tools like esptool.py and will upload a loader program to RAM via the phones built-in ROM UART/serial bootloader. The flash loader program can then be communicated with using dialogtool.py to do things like read/write to SPI flash, check chip IDs, etc.

Required hardware

dialog-cr16c-uart-boot is designed to work with https://github.com/Manawyrm/Gigaset-Debug-Adapter#readme, altough a 1.8V USB-UART converter can also be used. Interfacing with the test pads on the phone PCB manually while supplying the phone with power is tricky. The DECT TX pin needs to be pulled down to ground to force the phone into the UART loader.

Tested SoCs/phones

Osmocom Wiki contains a list of tested & supported phones/SoCs:
https://osmocom.org/projects/misc-dect-hacks/wiki/Dialog-cr16c-uart-boot

These include Gigaset C430 (Dialog SC14441, SC14448), CL660HX (Dialog SC14444), etc. phones.

Usage

usage: dialogtool.py [-h] [-p PORT] [-b BAUDRATE] [-l LOADER] [--skip-loader]
                     [--initial-baudrate INITIAL_BAUDRATE]
                     {chip_id,flash_info,read_flash,write_flash}

Reading Chip ID (safe, good connection test)

./host/dialogtool.py -p /dev/ttyUSB0 chip_id

Dumping flash content (safe)

./host/dialogtool.py -p /dev/ttyUSB0 read_flash gigaset_c430_dump.bin

In some cases, the automatic flash size detection can fail.
The flash size can be provided manually to force reading (for a 8 MiB flash chip):

./host/dialogtool.py -p /dev/ttyUSB0 read_flash gigaset_c430_dump.bin 0x0 0x800000 # [offset] [length], both decimal and hex (with 0x prefix) are supported

Writing flash content (unsafe, dangerous)

The UART bootloader cannot be bricked, but you might render your phone unbootable if you do not have a valid firmware dump (or upload a broken firmware).
Proceed with caution and validate you have (ideally multiple copies) of a valid firmware dump.

./host/dialogtool.py -p /dev/ttyUSB0 write_flash gigaset_c430_dump.bin

Partial writing is also supported. This can be useful for development, as a full flash write can take a long time.

./host/dialogtool.py -p /dev/ttyUSB0 write_flash gigaset_c430_dump.bin 0x100000 0x1000 # [offset] [length], both decimal and hex (with 0x prefix) are supported

Loader stub

Device side loader code lives in device directory.
This repo includes a prebuilt loader binary. Toolchain is not required unless you want to modify the loader binary. Loader build infrastructure assumes cr16-c-elf toolchain is installed in $HOME/opt/cross/ and cr16-c-elf-* binaries are in $PATH
Needs libc in prefix $HOME/opt/cross/cr16-c-elf/

dialog-cr16c-uart-boot's People

Contributors

Stargazers

Watchers

Forkers

manawyrm fridtjof

dialog-cr16c-uart-boot's Issues

Handle unsupported baudrates

CH340 can't deal with 230400. Some mechanism to probe/detect that would be the premium solution, but I think just a command line switch is enough.

Support writing flash based on diffs only

Writing flash is pretty slow. Might be worth having a diff mode where only changed content is updated. Would need to keep some state on the host though since reading the flash is also pretty slow atm, thus calculating the diff would probably not make things faster

project doesn't have a license yet

Would be good if the authors could pick whatever favorite FOSS license and reference it (via human-readable notices, SDPX-Identifiers or whatever). Thanks!

Rename to generic name

This tool seems to work fine on a bunch of different SoCs without modifications.
Might be wise to rename it to dialog-uart-boot or similar.

Gigaset A415 can't synchronize

Gigaset A415 logs

root@vaporeon:/home/garfieldairlines/dialog-cr16c-uart-boot/host^main ♥
# python3 dialogtool.py -p /dev/ttyUSB0 chip_id                                                                                                                                                                                                                          18:16:32
Will send 6992 bytes to SC14441 bootloader
Unexpected byte 0x00 from bootloader
Payload size accepted, sending data
Response checksum correct, starting payload
Dispatching command Dispatch, id: 0, cmd: <__main__.PingCommand object at 0x7f9e9543f220>
Dispatching command Dispatch, id: 1, cmd: <__main__.PingCommand object at 0x7f9e9543c520>
Dispatching command Dispatch, id: 2, cmd: <__main__.PingCommand object at 0x7f9e9543f220>
Failed to synchronize with loader

More robust flash detection

Right now SFDP is the only source of information for flash size. Additionally there is only one command used to read SFDP, flash is not reset from possible QIO, QPI modes etc.

Changing baudrates requires bidirectional ACK

Certain USB->UART chipsets will immediately change their transmit baudrate, even when their buffer still contains data.
This will lead to a failure to connect when trying to switch the baudrate while the "SetBaudrateCommand" is still in some buffer somewhere.

Waiting for the phone to ACK the baudrate change in the old baudrate should solve this issue.

command line parser

test connection / read chip id
read flash into file
write file into flash
read arbitrary memory (boot ROM etc.)
write arbitrary memory / execute arbitrary memory (probably useful for development)