Comments (14)
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.
from dustcloud.
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.
from dustcloud.
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 ;)
from dustcloud.
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?
from dustcloud.
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
from dustcloud.
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?
from dustcloud.
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.
from dustcloud.
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
from dustcloud.
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.
from dustcloud.
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 the8189es
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.
from dustcloud.
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 :)
from dustcloud.
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 the8189es
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.
from dustcloud.
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 the8189es
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?
from dustcloud.
Related Issues (20)
- Wifi reset UART root method fails on Z10 Pro (p2028) HOT 3
- Privacy/homecalling of Dreame robots HOT 1
- Discussion: S6 MaxV UART pins HOT 1
- Replace soundpack on roborock s6 pure HOT 1
- Dreame Vacuum D9 is dead
- Which Xiaomi robot vacs ared supported?
- Roborock S5 Max firmware ver 1566 11/2021 confirmed rootable HOT 5
- SFTP support for Roborock HOT 4
- Rooting Xioami MJSTG1 HOT 28
- Support for Neato D8/D9/D10 HOT 2
- Support for Xiaomi Mi Robot Vacuum-Mop 2 Lite HOT 1
- Support for Dreame W10 rooting HOT 2
- Error while rooting xiaomi vacuum
- How to flash v8 to viomi v8 version? HOT 1
- Problem with voice generator
- docker-compose up -d --build fails with "SyntaxError: invalid syntax"
- Vacuum mop 2 pro support?
- Roborock S5max update failed
- Region lock
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dustcloud.