Samsung Gear 2 (samsung-rinato)

Features
Flashing	Works
USB Networking	Works
Internal storage
SD card
Battery	Works
Screen	Works
Touchscreen	Works
Multimedia
3D Acceleration	Works
Audio	Broken
Camera
Camera Flash
Connectivity
WiFi	Partial
Bluetooth	Works
GPS
NFC
Modem
Calls
SMS
Mobile data
Miscellaneous
FDE
USB OTG
HDMI/DP
Sensors
Accelerometer	Works
Magnetometer
Ambient Light
Proximity
Hall Effect
Haptics
Barometer

Samsung Gear 2
	; Front view of a Gear 2
Manufacturer	Samsung
Name	Gear 2
Codename	samsung-rinato
Model	SM-R380, SM-R381
Released	2014
Type	watch
Hardware
Chipset	Samsung Exynos 3250
CPU	Dual-core 1.0 GHz Cortex-A7
GPU	Mali-400 MP2
Display	320x320 AMOLED
Storage	4 GB
Memory	512 MiB
Architecture	armv7
Software
Original software	Tizen
postmarketOS
Category	testing
Pre-built images	no
Mainline	yes

The Samsung Gear 2 originally runs Samsungs Tizen operating system, which is based on Linux.

Contributors

Eloy

FieryFlames

Casept

Hardware

The FCC page for the Gear 2 is available here, and for the Gear 2 Neo here.

iFixit has done a fairly comprehensive teardown here. Note that there's a mistake in the parts list - the audio codec is made by Yamaha according to downstream kernel sources, not BCD Semiconductor.

The accelerometer/gyroscope and heart rate sensor are not connected directly to the main SoC, but to an STM32 serving as the sensor hub. The sensor hub is connected via some interrupt lines and an SPI bus. According to /sys/class/sensors/ssp_sensor/mcu_name on downstream kernel, the exact model is STM32F401CCY6B.

The IR blaster is connected to an FPGA, which the SoC talks to via SPI for bitstream upload, and I2C afterwards. The exact model seems to be iCE40LP640.

The Bluetooth chip is actually also capable of Wi-Fi connectivity, and Samsung's mainline device tree sources suggest that it's actually usable. Why the stock firmware only uses Bluetooth is unclear.

Asides from the missing camera on the Gear 2 Neo, both models are identical and can run the same software.

How to enter flash mode

If your Gear 2 is not linked to a Samsung phone, you have to bypass the first screen. Click around 20 times on the watch symbol until the Bluetooth message pops up, then wait until it disappears and then long press the watch symbol once. See this video.

Long press Power to force a reboot (the regular software restart button does not work for accessing the menu), then press Power quickly multiple times to go into the boot menu. You can navigate to downloading mode by pressing Power and then waiting a few seconds.

Rooting the stock OS

Rooting Tizen can be very useful for playing around with the stock kernel and bootloader. See Tizen hacking for details. Repacking the Odin archive is not required, as you can flash the modified image directly using Heimdall instead.

A suitable su binary can be obtained by e.g. patching out a check performed in Busybox's check_passwd function, so the current user is always assumed to be authorized.

Mainline

The device has mainline support, added by Samsung. See here

Needs this patch to get the kernel to load on a retail unit.

A work-in-progress mainline kernel tree for this device is available here.

This kernel boots all the way to a USB console which can be used to login via initramfs. See below for details on hardware support.

Downstream source

As Samsung frequently deletes source code of old devices from it's open source portal and their server is quite slow, vendor code has been mirrored here. The kernel requires a very old toolchain and other build tooling, a pre-made Docker image containing these tools is available here.

Some searching on github also turned up something that looks like a newer vendor kernel, with non-mainline drivers and device tree bindings for them. This could be a good source for forward-porting missing or broken drivers such as the IR LED, sound chip and sensor hub.

Flashing the kernel

The kernel is stored in the BOOT partition. It can be flashed using Henrik Grimler's Heimdall fork. Whether the original, unmaintained Heimdall works has not been tested.

Packing the kernel into an Android boot image has not been tested and is not necessary, just flash the raw zImage. The bootloader has no support for loading device trees, so the DTB has to be appended directly to the kernel image.

Serial console

Unlike most more modern Samsung watches, the Gear 2 exposes USB without having to take it apart. Downstream kernel sources suggest that a regular Carkit debug cable (identical to the one used for many other Samsung devices) grants a serial console.

The main problem is that the USB ID pin is not connected within the charging/data transfer cradle. Disassembling the cradle confirms this, as the pin is explicitly marked with a "NC" (not connected) silkscreen on the board. However, as the Pogo pin assembly is mounted through-hole, it's possible to run a magnet wire from this pin to the 3rd pin from the left of the micro USB connector.

Alternatively, some aftermarket cradles from sites like Aliexpress have all pins connected from the get-go, so if you don't want to try soldering you can try your luck with those.

Note that the device uses a 1.8V logic level for UART, which is not supported by many cheap USB-UART dongles. Connecting to a 3.3V TX may fry the UART, and you usually won't be able to see any output on an RX expecting 3.3V either.

In order to see kernel logs, you have to add console=ttySAC1,115200 to the kernel cmdline. Debug mode must be enabled from the stock firmware, otherwise you'll only see bootloader output!

UART is quite fiddly and on some boots the kernel refuses to print anything, so it's easier to use a USB serial gadget or SSH.

Debug information

As hinted at by the stock kernel's cmdline, the S-Boot bootloader exposes debug information at several locations in memory. The stock kernel configuration exposes /dev/mem, so these can be conveniently accessed from a rooted stock OS using e.g. memdump for reading memory ranges or `busybox devmem` for writing to them.

Bootloader logs are accessible in a "0x157d" byte range starting at address 0x46028ee5. These survive warm reboots, so you can flash mainline, boot it, reflash the stock kernel, then read logs from Tizen. These logs can tell you details like whether S-Boot even tried to load your kernel, or rejected it for some reason.

A more persistent log is available in a 0x200000 byte range starting at 0x46000000.

The bootloader reserves a framebuffer of currently unknown size at 0x48000000. If this region is written to from within Tizen and the system is rebooted, some pixels will be visible before the Galaxy logo at next reboot. Unfortunately, defining a simplefb console at this address from a mainline kernel doesnt't result in any output. This might be due to the display panel being put into command mode by the bootloader and not switched back by mainline, further research is required.

Getting kernel output without a serial cable

Like Samsung phones, S-Boot on the watch exposes the ability to dump RAM ranges via USB using the so-called "Upload mode".

To make use of it, it first has to be enabled from the stock OS by dialing *#9900#, then switching "Debug mode" to "on" in the settings menu that appears and tap the checkbox icon in the upper-right corner. A new option will then appear in the reboot menu, which can be used to enter upload mode.

The downstream kernel is also capable of entering this mode by itself on a certain key press sequence or a kernel panic. This is implemented here by writing some magic to the very start of main memory at 0x40000000. It also has the ability to print debug messages to a buffer there, which will be displayed by S-Boot in upload mode. The mainline fork linked above also has hacky support for this functionality.

Kernel console output and other debug details can be logged to dumpable memory by utilizing the kernel's pstore subsystem, like done here.

Dumping can be performed using e.g. bkerler's sboot dump tool. It's recommended to specify only the memory range where your kernel's pstore lives, as dumping all of RAM takes about 10 minutes.

pstore dumps are partially human-readable, but unfortunately no tool seems to exist for reading these in a manner other than booting a working kernel on the crashed machine. It'd probably be easier to implement such a tool than to backport pstore to the ancient vendor kernel.

Hardware support

SoC: All peripherals have mainline drivers. I2C seems broken, however this is not a major issue because the I2C pins can be re-mapped to GPIO pins in the device tree and used with the bitbanging I2C driver from mainline.

USB: Gadget mode works, but is a bit flakey. Especially after flashing, the watch may have to be turned off and back on until USB works.

GPU and Display: Panel has a driver and works, but only renders 2 penguins on system start and no kernel log. As soon as e.g. Wayland tries to draw to the framebuffer though, it works. The GPU driver and 3D acceleration work, but require a rejected kernel patch.

Touch: Supported downstream by MELFAS_W driver. People online claim that this is an MCS8000 chip, but that's unlikely as the downstream driver looks like it doesn't use the MIP4 protocol used by MCS8000. Much more likely to be a chip similar to MMS152. Mainline driver probes the chip successfully, but touches don't cause interrupts to be registered. It might be mandatory to implement firmware loading for this chip, which mainline currently doesn't support.

A slightly newer driver with device tree bindings exists for a different watch, suggesting that the proper model of this chip may be MMS128S. This driver has been ported to newer kernel versions in the mainline fork for this watch, and seems to work fine.

Regulators: MAX77836 used for charging and haptics enumerates fine. The Samsung built-in regulator also works, but must be controlled via bitbanged I2C due to SoC driver issues.

Battery/Charger: Fuel gauge is in mainline and works. Charging has been implemented by copying from a newer downstream kernel's DTS, but still needs more testing. Probably a good idea to keep an eye on the watch while charging. Overcurrent and thermal protections should be active, but their values might still need some tweaks.

Sensor hub: Has mainline driver, but driver fails to probe the device (complains about firmware version mismatch), then crashes the kernel. Can be resolved by patching in the firmware version the watch ships with.

Accelerometer and Gyroscope work and have been contributed to mainline by Samsung.

It's unclear how exactly downstream reads step counter data. However, it's quite certain that the sensorhub itself counts steps as messages such as [SSP]: MSG From MCU - PD: MPed 97 appear in it's debug output, with 97 referring to the amount of steps counted since boot. Therefore, a low-effort solution could indeed be simply parsing these debug messages.

Heart rate sensor has 2 drivers written in mainline fork (for raw and interpreted values, respectively). Values are currently just dumped to userspace via the kernel IIO framework, as interpreting them requires reverse engineering Samsung's Tizen userspace daemon.

Haptics: Controlled by MAX77836. Haptics enumerate and work fine.

Front button: Works fine.

Bluetooth: Has mainline driver and is declared in device tree. Requires firmware blob extracted from e.g. the stock ROM or Android wear port. Seems to work fine.

Wi-Fi: Does not officially exist on this watch and stock firmware does not support it. However, the hardware is present (probably because Samsung couldn't get a comparable bluetooth chip without it). Has mainline driver and is declared in device tree. People on the Armbian forum have developed a patch to the kernel for enabling it, which basically just requires adding an entry to a table telling `brcmfmac` that a `BCM43342/1` chip exists and what it's firmware is called.

Nonetheless, Wi-Fi performance is very poor and the watch fails to connect to some networks, though it can scan for them. Open networks seem to work a bit more reliably than ones with WPA active. However, even if a connection is established the connection is too poor to do anything useful, even just a single ping.

The driver complains about missing some regulatory files, which might be the cause for the poor performance (along with probably missing a Wi-Fi antenna, I'd assume). I've only managed to find the firmware itself, extracted by Armbian from some set-top boxes. Please get in touch with casept if you manage to track the `clm_blob` for this chip down.

An excerpt of the kernel log generated when loading the driver:

[13186.405445] bus: 'platform': add driver brcmfmac [13186.409142] bus: 'sdio': add driver brcmfmac [13186.417640] brcmfmac: F1 signature read @0x18000000=0x1601a94e [13186.449432] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43342-sdio for chip BCM43342/1 [13186.488888] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43342-sdio.clm_blob failed with error -2 [13186.784133] wake enabled for irq 83 (gpx1-1) [13186.786229] wake disabled for irq 83 (gpx1-1) [13186.920620] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available [13186.927320] brcmfmac: brcmf_c_process_txcap_blob: no txcap_blob available (err=-2) [13186.940553] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43342/1 wl0: Oct 18 2016 17:43:42 version 6.25.134.25 (r662387) FWID 01-281dd9d9

Audio chip (YM381): No mainline driver, no datasheet. Will take lots of work. Might also have been used in some Samsung smartphones.

A branch in the mainline repo exists where the code for this chip has been imported, but it doesn't yet compile and even getting to that point would require fixing several screens worth of compiler errors.

IR LED: An attempt to port the downstream driver has been made, but the FPGA controlling the LED doesn't signal that it's been programmed. It might be possible to refactor the driver to use the kernel's FPGA programming framework instead of the driver's hand-rolled hacky programming routine, which could resolve the issue.

After programming, the FPGA is controlled via I2C. As an I2C device is detected on the bus and the FPGA's datasheet advertises non-volatile bitstream storage, it might be that programming the FPGA on every boot is actually not necessary and it'd be sufficient to just treat it as a regular I2C device once it's been programmed at least once by booting the downstream kernel.

Downstream exposes the IR LED as a character device which takes in ASCII strings of comma-separated numerals which somehow describe the waveform to send. This is converted to binary data by the driver and sent out via I2C. The magic for generating this waveform is done in /usr/lib/libWatchONNP.so.

GUI

See AsteroidOS. A fork of meta-asteroid with initial support is available [here https://github.com/casept/meta-asteroid]. Touch currently doesn't work, and USB is very unstable. Needs further debugging.

External links

Notes

Patch necessary to get retail unit to load mainline

Android Wear cmdline: console=ram loglevel=4 no_console_suspend androidboot.selinux=disabled root=/dev/mmcblk0p8 rw rootfstype=ext4 rootwait sec_debug.enable=0 sec_debug.enable_user=0 sec_watchdog.sec_pet=5 sec_log=0x200000@0x46000000 androidboot.serialno=redacted tizenboot.emmc_checksum=3 tizenboot.odin=1 bootloader.ver=R380XXU0BOA2 bootloader.fb=0x48000000 bootloader.log=0x15d5@0x4603ceef

Tizen cmdline: console=ram loglevel=4 root=/dev/mmcblk0p15 ro rootfstype=ext4 rootwait bootmode=normal pwron.reason=ap:swrst,pmic:acok sec_debug.enable=0 sec_debug.enable_user=0 sec_watchdog.sec_pet=5 sec_log=0x200000@0x46000000 lcdtype=0 oops=panic pmic_info=1875 sysscope=0xee000000 cordon=310baa3d7e5cd27155b0d44028aebdfd serialno=redacted tizenboot.emmc_checksum=3 tizenboot.odin=1 bootloader.ver=R380XXU0BOA2 bootloader.fb=0x48000000 bootloader.log=0x157d@0x46028ee5
Bootloader log via serial:

OMUIC rev = MAX14577(117)

MON: 0x7d(7)

MON[0] = (7)[0x1c, 0x5c]

MON[1] = (0)[0x1c, 0x68]

MON[2] = (1)[0x32, 0x3c]

MON[3] = (2)[0x36, 0x28]

MON[4] = (3)[0x1c, 0x56]

MON[5] = (4)[0x0c, 0x01]

MON[6] = (5)[0x18, 0x20]

MON[7] = (6)[0x0a, 0x00]

cardtype: 0x00000007

SB_MMC_HS_52MHZ_1_8V_3V_IO

mmc->card_caps: 0x00000f11

mmc->host_caps: 0x00000f11

!!!Enter 8 Bit DDR mode.!!!

[mmc] capacity = 7634944

Photos

Charging cradle disassembled
Bottom of charging cradle PCB/pogo pins
Charging cradle PCB modded for UART
Mainline initializes the panel
Sway running on the watch