Samsung Gear 2 (samsung-rinato)

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 to force a reboot (the regular software restart button does not work for accessing the menu), then press quickly multiple times to go into the boot menu. You can navigate to downloading mode by pressing 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 and sound chip.
There's also , not sure what it's relation to the other trees is exactly. But it contains a driver for the camera (s5k8b1), which makes it interesting.
=== 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. To see the kernel console, `console=tty0` has to be added to the cmdline. 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.
Camera: The MIPI PHY is supported in mainline (s5p-fimc). The camera module seems to have a driver in , which has been ported in the mainlining repo. Support for Exynos3250 MIPI-CSIS is missing in mainline, but exists in both and as a modification to the mainline exynos4-is driver. is preferred as a source for porting, as that contains a git history as well.
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 submission of the port to AsteroidOS is in progress.
== External links ==
* XDA-developers thread about the Android port
* Kernel tree of the Android port, includes some potentially useful fixes
* Samsung presentation containing images of their janky "devkit" for the watch
* Teardown of the watch, including a die shot of the BT chip
== 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 ==
File:Rinato-Cradle-Disassembled.jpeg|thumb|left|Charging cradle disassembled
File:Rinato-Cradle-PCB-Bottom.jpeg|thumb|left|Bottom of charging cradle PCB/pogo pins
File:Rinato-Cradle-PCB-Modded.jpeg|thumb|left|Charging cradle PCB modded for UART
File:Rinato-Mainline-Penguins.jpeg|thumb|left|Mainline initializes the panel
File:Rinato-Mainline-Sway.jpeg|thumb|left|Sway running on the watch