When I was pulling apart my u8plus smartwatch, I noted that there were five unlabelled pads, and that these were likely jtag:

Although I had reasonable results with jtagenum, nothing I tried worked with a real adaptor. I turned to google and rediscovered bunnie/xob's work on fernvale. Xob specifically mentions problems with jtag:

"In theory it has JTAG, which should let us attach a debugger and break the execution flow of the CPU. However, we never got it working, and it's unclear what steps must be taken, or even which set of pins to use."

Making the assumption that if bunnie/xob couldn't get the jtag working, I was unlikely to stumble on the required magic. Instead I pulled xob's repo to see what it would do with the mt6261. It was able to connect and extract a bunch of information:

Waiting for serial port to connect: .......
Setting serial port parameters... Ok
Initiating communication... Ok
Getting hardware version... 0xcb01
Getting chip ID... 0x6261
Getting boot config (low)... 0x0000
Getting boot config (high)... 0x0000
Getting hardware subcode... 0x8000
Getting hardware version (again)... 0xcb01
Getting chip firmware version... 0x0001
Getting security version... v 5
Enabling security (?!)... Ok
Reading ME... 00000000 ad 3f 07 fa 5e 5d 0b ad  10 71 b2 02 3d 5b e5 a3  |.?..^]...q..=[..|
Disabling WDT... Ok
Reading RTC Baseband Power Up (0xa0710000)... 0x0002
Reading RTC Power Key 1 (0xa0710050)... 0xa357
Reading RTC Power Key 2 (0xa0710054)... 0x67d2
Setting seconds... Ok
Disabling alarm IRQs... Ok
Disabling RTC IRQ interval... Ok
Enabling transfers from core to RTC... Ok
Reading RTC Baseband Power Up (0xa0710000)... 0x0002
Getting security configuration... None.
Getting PSRAM mapping... 0x0000
Disabling PSRAM -> ROM remapping... Ok
Checking PSRAM mapping... 0x0002
Checking on PSRAM mapping again... 0x0002
Updating PSRAM mapping again for some reason... Ok
Reading some fuses... 0x00000000
Enabling UART... 0x0000
  

This looked promising but it was hanging before it could attempt to upload the first stage. A lucky guess (based on reading *somewhere* that 6261 had less SRAM) at hacking the load address and the stack address let it continue though to:

Loading Fernly USB loader... checksum matches 0x1ec6 Ok
Executing Ferly USB loader... Ok
Waiting for Fernly USB loader banner...
  

At this point, it seems that we might have code running on the cpu; the watch was unresponsive until I pulled the USB - I was hoping I had at least crashed it..

The fernly usb loader is able to read/write memory pretty trivially, so I used it's functions to dump the 4MB of onboard flash (at 0x0). I also attempted to 'spray' all over the area where the uart blocks are on the 6260; with the bus pirate connected to the hardware uart, I thought I'd at least see something random spit out - no luck.

Having a dump of the flash to analyse is useful, but - from reading though the fernly information - a dump of the rom (at 0xfff00000) is where a lot of the hardware detail is hiding. I didn't expect that to be a problem, I expected the usb loader to just dump it out for me; instead it hung, turns out that area is protected from usb reads.

After quite a while of searching for something even remotely looking like a memory map for the 6261, so I could use the uart to dump the rom, I came across this post by jimparis. He'd been through the same process, and also hadn't been able to find the uarts. What he had found though was the address of the vibration motor; his code buzzed the motor on my watch too. Jim also says "So I'm sure that code is running now. What's next? Try to find and dump the internal ROM via the motor? :/"

When I read that, I vaguely remembered reading about how the original ipod rom was dumped and thought that I could do something similar with the vibrator motor. My set up is much simplier than the ipod - I de-soldered the motor and after a quick examination with the scope, I patched the line into an adruino.

The assembler for the mt6261-test image was modified to loop through a memory range, reading in a 32 bit value, and then generating a pulse for each bit. I'm lazy - I chose a short 'on' (1x call to delay()) for zero, a long 'on' (2x calls to delay(), so double the length), using 'off' to represent the gap between bits; e.g:

1 0 1 0 0 1 = off, long, off, short, off, long, off, short, off, short, off, long, off
  

The main assembler loop was debugged using qemu-arm+gdb (the image can be used as a qemu flash image) before attempting to upload to the real device. On the arduino side, a pin was monitored and the length of the pulses was tracked. If the pulse was over a certain threshold then a '1' is output, otherwise a '0'. To validate the method before dumping the unknown rom, I dumped the first part of the flash - this was compared with the data dumped using the usb loader and after a few tweaks they were bit perfect. A small bit of throwaway python was hacked together to reassemble the bits into a file:

s = """
10110000000000000000000001010111
01111111111111111111111101010111
01111111111111111111111101010111
01111111111111111111111101010111
01111111111111111111111101010111
01111111111111111111111101010111
01111111111111111111111101010111
01111111111111111111111101010111
...
00000000000000000000000000001110
00000000000001000000000000001110
00000000000000100000000000001110
00000000000001100000000000001110
00000000000000010000000000001110
00000000000011010000000000001110
"""

import struct

l = s.replace("\n\n", "\n").split('\n')

f = open('file.dat', 'wb')

for x in l:
  try:
    i = int(x[::-1], 2)
    f.write(struct.pack('I', i))
  except:
    pass

f.close()
  

This method wasn't fast - and I suspect that the pulse lengths could be reduced somewhat - but it was getting late, and in the end I just left it running overnight. When I got up, it had stopped before the end of the 64k - however when reassembled I had a 44k file, that seemed to contain the whole rom :) - here's some strings:

SF_BOOT
BRLYT
P0Dx
[USBDL] Waiting for start cmd over 1 min ...
p[USBDL] Waiting for host's response over 1 min ...
8pGpGpG
 -JD2
KXhA
p!LD4
ACM COMMU.
ACM DATA
ACM VIRTUALCOM
RC_INIT
JM	5X
EM15M
pRESV0 
H@xpG
xSxG"
pBOOTRETY
pBoot failed, reset ...
System halt!
DELY@ 
pUART0\
p1_ENJump to BL
MhhB
D^[a5d
pUART,\
p1_EN
xpGLI
EEEEMMM
 h,I
FILE_INFO
	HpG
SCTLCERT
"x1h
BBBB
I	h	
ZZZZ
HapG
`BA02
G G(G0G8G8
"#KBC{D
Invalid Operation
Divide By Zero
Overflow
Underflow
Inexact Result
: Heap memory corrupted
Unknown signal
X65dAl
Abnormal termination
Arithmetic exception: 
Illegal instruction
Interrupt received
Illegal address
Termination request
Stack overflow
Redirect: can't open: 
Out of heap memory
User-defined signal 1
User-defined signal 2
Pure virtual fn called
C++ library exception  
  

My fork of the fernly repo (including the arduino sketch) can be found here (mt6261 branch).

I noticed this smart watch on Amazon for the bargain price of £7.51, which was just too cheap to ignore - I didn't expect much but I was quite surprised at how functional it actually was... Anyhow, it was never expected to stay in once piece for long, and after an hour I took the screwdriver to it.

The back is covered by a aluminium plate that seemed to be sticky backed; it came off pretty easily. Underneath was four screws that released the back cover.

Inside, not much too see: a 200mAh, 3.7v battery, speaker, reset button (on the right) and what looks like a bluetooth antenna at the bottom.

With the battery and the speaker pulled back we can see a MediaTek MT6261 SoC and supporting components on the left. On the right are connections for the reset button (mounted on top of the usb connector), speaker and what I assume is a vibrator motor connected to 'VIB'. The touchscreen is also connected at the top, with it's controller mounted on the flat flex cable. The home/power button is tucked in on the far left.

The other side of the board, removed from the shell: the connections to the LCD are at the bottom, the power button on the right and some test pads sprinkled all over :)

The 'D+' and 'D-' and the proximity to the USB suggest the four pads on the left are for the USB; VBAT is positive side of the battery; PWR connects to the power/home button. Just slightly covered by the green label is RXD and TXD - which is likely our UART, and two others ('OW2' and 'OL0'). Above them next to PWR are five unlabelled pads - hopefully these are JTAG.

Wires connected to the GND, RXD and TXD, ready for the bus pirate. With the green label removed we can see that the two adjacent pads are actually labelled 'KROW2' and 'KCOL0'...? (I also added a scrap of sticky label to protect the LCD connections a little.)

And finally, the bootloader (@115200):

F1: 0000 0000
V0: 0000 0000 [0001]
00: 0000 0000
U0: 0000 0001 [0000]
G0: 0002 0000 [0000]
T0: 0000 00BB
Jump to BL




~~~ Welcome to MTK Bootloader V005 (since 2005) ~~~
**===================================================**


Bye bye bootloader, jump to=0x1000b5b0