Experience with STYTJ02YM robots

[martinhoyer]

Hi @dgiese @Hypfer,

I got three Xiaomi Mop P STYTJ02YM in an auction and want to share some things I've learned during the process of rooting them and and installing viomi v6 conversion fw w/ Valetudo.

While all three look identical, one was clearly a different revision then the other two. One was working straight away with v6 fw, the other two needed a different wlan driver.
The clear indicator of which is which is the color of LED - when holding home, the two robots with different wlan driver turns purple when holding home button during power-on, while the one which was safe to flash to v6 was white/blue-ish. (both go orange when left bumper is pressed).
Also I guess you can identify it by having a different partition table?

diff partitions ../partitions 
13a14,15
>  254        0      20224 dm-0
>  254        1       8192 dm-1

The driver needed is 8189fs.ko, which I got from the original fw.
I used the enable_8821cs.sh script as a reference to make sure it's loaded after reboot.
So far I haven't encountered any issues.

The third one I soft-bricked and so had to flash livesuit image through FEL, i.e. I disassemble it. Interestingly I can see R16, while the fw reports A33. Super confused.

USB device 001:061   Allwinner A33     0461872a:8f749047:2b971977:6c118000

To get it to FEL via serial, it wants 2 character to be pressed on power-on.
"Disassembly" to get to UART is very easy, just one screwdriver and some plastic tool to "un-click/pry-free" four plastic clips.

Let me know if I can provide any more info, thought they are all now running v6. I've dumped the nands fwiw.
(I'm not on telegram)

As for rooting, honestly the biggest pain is to establish the ADB connection. I spent so much time on it, pressing all kinds of button combos, etc. I even suspect the bumper buttons have role, because every time I got adb working I did press/hold them, though it does not seem plausible.
To make it easier for other people, it would be really nice to find a reproducible way to get it working.
Currently, I'd say it's easier/faster to use serial connection, if the robot doesn't provide adb straight away.

btw, I watched your (this year's) Defcon talk. Very nice!

[ksga]

I'm definitely interested in more info.
I think I soft-bricked my unit, at least loosing acces through SSH and ADB (rumpeltux/viomi-rooting#54) , so I guess serial is the way forward for me...

I've started a "V7,V8 conversion to V6 (V6 ver 0041, 11/2020)" livesuit build - but I don't know how to use when it's done. Is there a UART connection guide for the V8 anywhere?
Should I pickup Livesuit from here: https://www.getdroidtips.com/download-livesuit-tool-latest-version/ and will it accept a serial connection?
How do I use the correct wlan driver?

Sorry about all the questions - but fluff is starting to build under bed ;)

[ksga]

Got a bit further. Cracked open the vacuum, soldered a few pins to the MB (remembered seeing a photo somewhere showing GND as the middle pin, and RX/TX on either side).

Connected a USB/UART board to the pins and a micro-usb cable to the connector, and look and behold - output on TeraTerm:

HELLO! BOOT0 is starting!
boot0 version : 4.2.0
boot0 commit : a1ae6c20d88d561753072492191f817d9ff10a36

fel_flag = 0x00000000
rtc[0] value = 0x00000000
rtc[1] value = 0x00000000
rtc[2] value = 0x00000000
rtc[3] value = 0x00000000
DRAM DRIVE INFO: V1.7
DRAM Type =3 (2:DDR2,3:DDR3,6:LPDDR2,7:LPDDR3)
DRAM zq value: 00003bbbDRAM CLK =552 MHZ
ID CHECK VERSION: V0.1
using ic R16
USE PLL DDR1
USE PLL NORMAL
PLL FREQUENCE = 1104 MHZ
DRAM PLL DDR1 frequency extend open !
DRAM master priority setting ok.
Auto calculate timing parameter!
para_dram_tpr0 = 0047214f
para_dram_tpr1 = 01c2294b
para_dram_tpr2 = 00061043
tcl = 6,tcwl = 4
DRAM TIMING PARA0 = 0b0e180b
DRAM TIMING PARA1 = 0003040f
DRAM TIMING PARA2 = 0406050a
DRAM TIMING PARA3 = 0000400c
DRAM TIMING PARA4 = 05020405
DRAM TIMING PARA5 = 05050403
DRAM TIMING PARA8 = 90003310
DRAM PHY INTERFACE PARA = 02040102
DRAM VTC is disable
DRAM dynamic DQS/DQ ODT is on
DRAM DQS gate is PD mode.
DRAM one rank training is on,the value is 91003587
DRAM work mode register value = 004318e4
DRAM SIZE =512 M
set one rank ODTMAP
DRAM simple test OK.
dram size =512
NAND_ClkRequest, nand_index: 0x00001000
Reg 0x01c20080: 0x00053de3
Reg 0x01c20060: 0x00053dd6
Reg 0x01c202c0: 0x00053dd6
NAND_SetClk, nand_index: 0x0000000a
Reg 0x01c20080: 0x00053de7
NB0 : nand phy init ok
block from 4 to 39
nand block 4 is bad
nand block 5 is bad
nand block 6 is bad
nand block 7 is bad
current block is 8 and last block is 39.
current block is 9 and last block is 39.
current block is 10 and last block is 39.
current block is 11 and last block is 39.
current block is 12 and last block is 39.
current block is 13 and last block is 39.
current block is 14 and last block is 39.
sum=4828c2fe
src_sum=4828c2fe
The file stored in start block %u is perfect.
Ready to disable icache.
Jump to secend Boot.
[      0.448]

U-Boot 2011.09-rc1-dirty (Apr 25 2017 - 14:33:40) Allwinner Technology

[      0.456]version: 1.1.0
[      0.459]uboot commit : a1ae6c20d88d561753072492191f817d9ff10a36

[      0.466]pmbus:   normal or secure os
ready
[      0.470]PMU: AXP221
[      0.472]PMU: AXP22x found
bat_vol=0, ratio=100
[      0.478]PMU: dcdc3 1100
[      0.481]PMU: pll1 1008 Mhz,PLL6=600 Mhz
AXI=336 Mhz,AHB=200 Mhz, APB1=100 Mhz
dcdc1_vol = 3000
dcdc2_vol = 1100
dcdc3_vol = 1100
dcdc4_vol = 0
dcdc5_vol = 1500
aldo2_vol = 2500
aldo3_vol = 3000
find power_sply to end
vbus exist
fel key new mode
run key detect
no key found
no key input
dram_para_set start
dram_para_set end
[      1.604]DRAM:  512 MiB
relocation Offset is: 1e1f3000
save config for small mem_size
workmode = 0
[      1.672]NAND: NAND_UbootInit
NAND_UbootInit start
NB1 : enter NAND_LogicInit
uboot:nand version: 3 5003 20170418 1437
nand : get id_number_ctl fail, 1
uboot:nand info: 9590dac2 ffffff06 28c 0 0
nand : get sorting_flag fail, a
nand : get CapacityLevel fail, 5eb96e90
not burn nand partition table!
NB1 : nftl num: 1
 init nftl: 0
NB1 : NAND_LogicInit ok, result = 0x0
[      2.258]sunxi flash init ok
In:    serial
Out:   serial
Err:   serial
--------fastboot partitions--------
-total partitions:11-
-name-        -start-       -size-
boot-res    : 1000000       100000
env         : 1100000       100000
boot        : 1200000       a00000
rootfs      : 1c00000       3000000
rootfs_data : 4c00000       a00000
private     : 5600000       100000
recovery    : 5700000       2000000
misc        : 7700000       100000
verity_block: 7800000       100000
secret      : 7900000       a00000
UDISK       : 8300000       0
-----------------------------------
base bootcmd=run setargs_nand boot_normal
bootcmd set setargs_nand
key 0
cant find rcvy value
cant find fstbt value
misc partition found
to be run cmd=run setargs_nand boot_normal
sunxi_serial: sn_filename is not exist
serial is: 29278e142108ffffd488
Net:   usb_etherWarning: failed to set MAC address

WORK_MODE_BOOT
board_status_probe
sunxi_bmp_logo_display
sunxi secure storage is not supported
[      2.395]usb burn from boot
delay time 0
[      2.466]usb prepare ok
usb sof ok
vbus pc exist ,limit to pc
[      2.673]usb probe ok
[      2.675]usb setup ok
==== try to handshake ====
set address 0x2
[      5.677]timer occur
[      5.712]do_burn_from_boot usb : have no handshake
[      5.717]Hit any key to stop autoboot:  0
fatload partition name: boot -> 2
## Booting kernel from Legacy Image at 43800000 ...
   Image Name:   ARM OpenWrt Linux-3.4.39
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    10432740 Bytes = 9.9 MiB
   Load Address: 40008000
   Entry Point:  40008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK
[      6.519][mmc]: MMC Device 2 not found
[      6.523][mmc]:  mmc  not find,so not exit
NAND_UbootExit
NB1 : NAND_LogicExit
nand release dma:0
reload config to 0x43000000
[      6.527]
Starting kernel ...

How do I get a serial login from here? Or can I somehow flash the livesuit img?

[ksga]

Found a few hints on getting a shell via serial, but no luck so far.
Holding "s" during boot opened `sunxi´
Tried:

setenv init /bin/sh
setenv boot_partition boot1
boot

and

setenv init /bin/sh
setenv boot_partition boot1
run setargs_nand
run boot_normal

but both just ended in the same "Starting kernel ..." line and nothing further.

Now I just noticed the comment in the first post about holding 2 during boot. It changes the output, but still no ADB shell working:

HELLO! BOOT0 is starting!
boot0 version : 4.2.0
boot0 commit : a1ae6c20d88d561753072492191f817d9ff10a36

enter 0x00000002,ready jump to fes

On host:

PS C:\Users\ksga> adb devices
List of devices attached

No devices :(

Output from dmesg and lsusb:

[147850.833790] usb 4-1: USB disconnect, device number 2
[147859.578583] usb 4-1: new full-speed USB device number 3 using ohci-platform
[147859.799641] usb 4-1: New USB device found, idVendor=1f3a, idProduct=efe8, bcdDevice= 2.b3
[147859.799672] usb 4-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
cubie@cubieboard2:~$ lsusb
Bus 004 Device 003: ID 1f3a:efe8 Allwinner Technology sunxi SoC OTG connector in FEL/flashing mode

[martinhoyer]

Hi @ksga, sorry for the late reply.

First, get a livesuit image from https://builder.dontvacuum.me/ (v6 conversion)

Flashing it was super painful for me on my Fedora 38, but also other modern Linux distros (as well as windows), because of the tooling. Make your life easier and use older OS. I used ubuntu 18.04

Build the usb driver and install sunxi tool - https://linux-sunxi.org/LiveSuit (the guide is not comprehensive, you will need to install additional dependencies)

Boot to FES by presing 2 and run the tool.

[ksga]

Hi @ksga, sorry for the late reply.

First, get a livesuit image from https://builder.dontvacuum.me/ (v6 conversion)

Flashing it was super painful for me on my Fedora 38, but also other modern Linux distros (as well as windows), because of the tooling. Make your life easier and use older OS. I used ubuntu 18.04

Build the usb driver and install sunxi tool - https://linux-sunxi.org/LiveSuit (the guide is not comprehensive, you will need to install additional dependencies)

Boot to FES by presing 2 and run the tool.

Thank you for getting back to me.
I'll try and get the tool working.

Can you also share the wlan driver and script?

[martinhoyer]

Can you also share the wlan driver and script?

It's in /opt/8821cs/, where you put the 8821fs.ko and modify enable_8821cs.sh so it enables that instead of 8821cs.
8821cs_patched.ko -> 8889fs.ko
Reboot after running the script.

8189fs.zip

[dgiese]

Thank you for investigating it. We are completely clueless on what is going on with the V8, as neither Sören nor me have one of them. The only Viomi I own is the v6. No clue why they have so many different wifi modules. Any recommendations on how we can fix it for everyone? This is what the builder currently does: https://github.com/dgiese/dustbuilder-script-public/blob/master/modifyviomi.sh

[Hypfer]

I don't have time for a full response atm but at a quick glance, that module zip you attached is just taken straight from the firmware with no modifications?
You need to modify it so that the metadata of it states that it's actually the 8189es because there are a few things in the firmware where that module name is hardcoded.

[martinhoyer]

Any recommendations on how we can fix it for everyone?

I guess the same as the vacuums with RTL8821CS - https://github.com/Hypfer/valetudo-crl200s-root?tab=readme-ov-file#6-additional-model-specific-steps
(could be automated?)

The real win would be to figure out how to get to adb reliably.

that module zip you attached is just taken straight from the firmware with no modifications?
You need to modify it so that the metadata of it states that it's actually the 8189es because there are a few things in the firmware where that module name is hardcoded.

Correct. I assumed as much from the 8821cs_patched file name. So far it works fine though.

@ksga BTW, check if wlan works before doing anything with network drivers. Maybe you have the revision that uses 8189es.

[martinhoyer]

FWIW There is another batch of auctions with Xiaomi Mop Pro Vacuums. They've been used in some company and are being auctioned in batch, so should be well below 100EUR. Should I try to get some for "development purposes"? (I'm in EU)

Fun fact: I've found the company's laser-scanned floor plans, wi-fi network credentials and list of devices on the network along with vacuuming logs... info-sec fail :)

[ksga]

Any recommendations on how we can fix it for everyone?

I guess the same as the vacuums with RTL8821CS - https://github.com/Hypfer/valetudo-crl200s-root?tab=readme-ov-file#6-additional-model-specific-steps (could be automated?)

The real win would be to figure out how to get to adb reliably.

that module zip you attached is just taken straight from the firmware with no modifications?
You need to modify it so that the metadata of it states that it's actually the 8189es because there are a few things in the firmware where that module name is hardcoded.

Correct. I assumed as much from the 8821cs_patched file name. So far it works fine though.

@ksga BTW, check if wlan works before doing anything with network drivers. Maybe you have the revision that uses 8189es.

Got the USB driver compiled (@Hypfer has already fixed everything here: https://github.com/Hypfer/valetudo-sunxi-livesuit ).
Created a livesuit image on dustbuilder, let dustbuilder create a SSH key, patch DNS, nano etc. and marked factory reset.
LiveSuit caught the device when it went to FEL mode, flashing went fine, but ended with an error (sorry but didn't write down exactly what).

The device rebooted, enabled a shell via UART. I'm still not able to connect over SSH (key seems to fail even though I'm specifying the file received from dustcloud as identity).
ADB still fails:

kenneth@ubuntu:~$ sudo adb devices
List of devices attached
* daemon not running; starting now at tcp:5037
* daemon started successfully
20080411	device

kenneth@ubuntu:~$ sudo adb shell
- exec '/bin/adb_shell' failed: Exec format error (8) -
CNXN
[adbd D]parse_banner: host::features=stat_v2,cmd,shell_v2c format error (8) -

[adbd D]adb: online
[adbd D]Calling send_connect 
[adbd D](null): transport got packet, sending to remote
[adbd D]about to write (fd=8, len=24)
[adbd D][ done fd=8 ]
[adbd D]about to write (fd=8, len=66)
[adbd D][ done fd=8 ]
[adbd D][ done fd=8 ]
[adbd D]about to read (fd=8, len=7)
[adbd D][ done fd=8 ]
[adbd D](null): received remote packet, sending to transport
[adbd D]about to read (fd=8, len=24)
[adbd D]transport_socket_events(fd=13, events=0001,...)
[adbd D]handle_packet() OPEN

The unit connected to WLAN, dmesg showing:

/ # dmesg | grep 8189
[    9.525950] RTW: rtl8189es v5.8.9_35085.20190919

I expected it would not because of the factory reset flag, but apparantly not.
Should I try to let LiveSuit erase the memory when asked? Would like to get a fresh start.

[ksga]

Any recommendations on how we can fix it for everyone?

I guess the same as the vacuums with RTL8821CS - https://github.com/Hypfer/valetudo-crl200s-root?tab=readme-ov-file#6-additional-model-specific-steps (could be automated?)
The real win would be to figure out how to get to adb reliably.

that module zip you attached is just taken straight from the firmware with no modifications?
You need to modify it so that the metadata of it states that it's actually the 8189es because there are a few things in the firmware where that module name is hardcoded.

Correct. I assumed as much from the 8821cs_patched file name. So far it works fine though.
@ksga BTW, check if wlan works before doing anything with network drivers. Maybe you have the revision that uses 8189es.

Got the USB driver compiled (@Hypfer has already fixed everything here: https://github.com/Hypfer/valetudo-sunxi-livesuit ). Created a livesuit image on dustbuilder, let dustbuilder create a SSH key, patch DNS, nano etc. and marked factory reset. LiveSuit caught the device when it went to FEL mode, flashing went fine, but ended with an error (sorry but didn't write down exactly what).

The device rebooted, enabled a shell via UART. I'm still not able to connect over SSH (key seems to fail even though I'm specifying the file received from dustcloud as identity). ADB still fails:

kenneth@ubuntu:~$ sudo adb devices
List of devices attached
* daemon not running; starting now at tcp:5037
* daemon started successfully
20080411	device

kenneth@ubuntu:~$ sudo adb shell
- exec '/bin/adb_shell' failed: Exec format error (8) -
CNXN
[adbd D]parse_banner: host::features=stat_v2,cmd,shell_v2c format error (8) -

[adbd D]adb: online
[adbd D]Calling send_connect 
[adbd D](null): transport got packet, sending to remote
[adbd D]about to write (fd=8, len=24)
[adbd D][ done fd=8 ]
[adbd D]about to write (fd=8, len=66)
[adbd D][ done fd=8 ]
[adbd D][ done fd=8 ]
[adbd D]about to read (fd=8, len=7)
[adbd D][ done fd=8 ]
[adbd D](null): received remote packet, sending to transport
[adbd D]about to read (fd=8, len=24)
[adbd D]transport_socket_events(fd=13, events=0001,...)
[adbd D]handle_packet() OPEN

The unit connected to WLAN, dmesg showing:

/ # dmesg | grep 8189
[    9.525950] RTW: rtl8189es v5.8.9_35085.20190919

I expected it would not because of the factory reset flag, but apparantly not. Should I try to let LiveSuit erase the memory when asked? Would like to get a fresh start.

I played a bit more with the unit - and everything is now solved...
ADB shell access: The content of adb_shell in /bin/ had disappeared leaving behind an empty file. Adding the lines from the root script (did it through UART, but adb push would probably have worked) fixed the issue.
SSH access: Decided to generate a manual V6 conversion image, pushed it through adb using the procedure in https://github.com/Hypfer/valetudo-crl200s-root step 5 and 7 - and now ssh works using my key pair.

The vacuum has been up for a couple of days without issue, and cleaning zones or segments works a expected...

@martinhoyer - did you flash the V6 0046 firmware, or just stay on the conversion 0041 firmware?

[martinhoyer]

Glad it worked out for you.

@martinhoyer - did you flash the V6 0046 firmware, or just stay on the conversion 0041 firmware?

I stayed on the 0041.

[suaveolent]

@martinhoyer Thank you so much for your work. Wifi is working now for me too, using the 8189fs.ko.

[0k00l]

Hi guys, so i can try to install dustcloud on this device? I've already build at dustbuilder firmware for manual installation (via ssh) for 'V7,V8 conversion to V6 (V6 ver 0041, 11/2020) ' version - is it correct for this device(STYTJ02YM - viomi.vacuum.v8)? The firmware file has name: viomi.vacuum.v7_fw.tar.gz (i'm bit confused because of v7 in it)

[suaveolent]

Hi guys, so i can try to install dustcloud on this device?

Yes, I am successfully running a v8 with said version. Remember that you need to manuallly install the 8189fs driver.

[0k00l]

So i need to take this driver from my vaccum and then push this it via adb? Does adb works after flashing out of the box?

[suaveolent]

Yes, or take the driver from above.
ADB worked for me after flashing since Wifi will not work, this will be the only way to push the driver.

[0k00l]

Did it! :D My wifi driver was 8189es so i don't need to do a thing.

Thx you all for this incredible work!

[0k00l]

Found another issue: i have no map in valetudo :/. Robot works as expected, so space mapping is working - but map doesn't shows up. Did you experience such issue?

[suaveolent]

The mapping feature of the viomi is somewhat buggy. In my case, the map would sometimes be rotated when the robot was vacuuming. This lead to all kinds of weird behaviour including th robot not being able to return to the dock.

In my case what works best was to disable "Persistent maps" in Valetudo and perform a "Map Reset" once.

[0k00l]

Did it - still no map. I don't even know where to start investigating :/ ... on my previous vacuums everything worked fine.

[0k00l]

In /mnt/UDISK/log i found map of my home... but not in GUI.

[0k00l]

Got it - factory reset helped. Thx! I should try it at first ;)