Samsung Gear 2 (samsung-rinato)

From postmarketOS
Samsung Gear 2
Front view of a Gear 2
Front view of a Gear 2
Manufacturer Samsung
Name Gear 2
Codename samsung-rinato, samsung-sm-r380, samsung-sm-r381
Released 2014
Category testing
Pre-built images no
Original software Tizen
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
Type watch
Features
USB Networking
Works
Flashing
Works
Touchscreen
Works
Display
Works
WiFi
Broken
FDE
Mainline
Works
Battery
Works
3D Acceleration
Works
Audio
Broken
Bluetooth
Works
Camera
GPS
Mobile data
Internal storage
SMS
Calls
USB OTG
NFC
Sensors
Accelerometer
Works
Magnetometer
Ambient Light
Proximity
Hall Effect
Barometer
Power Sensor
Misc
Built-in DVB
Camera Flash
Keyboard
Touchpad
USB-A
HDMI/DP
Ir TX
Ir RX
Stylus
Memory Card
Haptics
Ethernet
FOSS bootloader

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

Contributors

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. This part seems to have mainline support contributed by Samsung.

The IR blaster is connected to an FPGA, which the SoC talks to via SPI.

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.

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.

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. 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.

The step counter implementation has been stubbed out in the downstream kernel, so it might be implemented by reading other sensors in userspace instead.

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: Has mainline driver and is declared in device tree. Driver complains about chip not being known, but might be an easy fix.

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.

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

  • 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