ORVIBO V70X/ Mixpad D1

I’ve recently purchased some orvibo V70X / MixpadD1 smart switches. I’d like to get them working in HA as they are very nice looking touch screen dimmer switches, with an audio input/output device and customizable scene control via the orvibo app, but have been unable to do so using the existing S20 integration. I’ve tried both discovery and manual config and neither works, the error when hass is loading is: ERROR (SyncWorker_5) [homeassistant.components.orvibo.switch] S20 at 192.168.1.240 couldn’t be initialized

Has anyone managed to connect one of these switches to HA?

An nmap scan of the device shows some open ports, does this look similar to any other device anyone has run into?:

Nmap scan report for rk3326_64.attlocal.net (192.168.1.240)

Host is up (0.029s latency).

Not shown: 996 closed tcp ports (reset), 983 closed udp ports (port-unreach)

PORT      STATE         SERVICE       VERSION

22/tcp    open          ssh           Dropbear sshd 2019.78 (protocol 2.0)

53/tcp    open          tcpwrapped

5555/tcp  open          adb           Android Debug Bridge device (name: occam; model: Nexus 4; device: mako)

8088/tcp  open          radan-http?

53/udp    open|filtered domain

67/udp    open|filtered dhcps

68/udp    open|filtered dhcpc

123/udp   open          ntp           NTP v4 (secondary server)

| ntp-info: 

|_  receive time stamp: 2022-12-10T07:31:00

1065/udp  open|filtered syscomlan

2223/udp  open|filtered rockwell-csp2

2362/udp  open|filtered digiman

5353/udp  open|filtered zeroconf

10000/udp open|filtered ndmp

17331/udp open|filtered unknown

18832/udp open|filtered unknown

19039/udp open|filtered unknown

20424/udp open|filtered unknown

21698/udp open|filtered unknown

25462/udp open|filtered unknown

57172/udp open|filtered unknown

58075/udp open|filtered unknown

MAC Address: 28:7E:80:A5:EE:D0 (Unknown)
2 Likes

The SSH server prompts for a login, but I have no idea the credentials to use.
The ADB bridge accepts a connection and appears to be a root login:

C:\platform-tools>adb connect 192.168.1.240
connected to 192.168.1.240:5555

C:\platform-tools>adb shell
[root@rk3326_64:/]# ls
backup_data     etc      media  orb_data       root    system     usr
bin             init     misc   overlay        run     timestamp  var
busybox.config  lib      mnt    proc           sbin    tmp        vendor
data            lib64    oem    rockchip_test  sdcard  udisk      version
dev             linuxrc  opt    rom            sys     userdata

The root ADB shell was a good find and had me curious, so I bought one and have been poking around. Haven’t found much, but figured I’d share/document.

For my use case, I’d like to build a small custom Android app that replaces the stock one and can communicate with HA.

Findings thus far:

  • I believe this is running something based on Android 4.0.0. It’s extremely stripped down, and the standard property definitions aren’t there. I base the 4.0.0 number on the contents of /own/version, which isn’t the strongest signal.
  • The ORVIBO app is a Flutter app (see /own/app/flutter-gui) that’s launched directly (see /oem/mixpad_gui_start.sh). The Android Activity Manager (the am command”) is not installed. Nor is pm.
  • Given the above, it’s not clear you can even run “normal” JVM based Android apps. Flutter apps are compiled to C/C++ code and the Dart VM from what I’ve found. This may be a way to keep the system smaller/lighter.
  • You can get the current value of the luminosity sensor by doing cat /sys/class/sensor_class/light_value. I haven’t been able to find any other sensors or the relay yet though.
  • The screen is a 1.9” 170x320 pixel LCD. The device has 512MB of RAM

If anyone else finds anything interesting, please post here as well.

I haven’t had more time to look into it, but the device page says it supports matter, so I’ve been trying to get that running on ha today.
It is a little limited using busybox without a full set of gnu tools but I was able to trace down the two listening ports below that show an app that seems to be written in ember, Tailing the logfiles over time looks like it actually reports the json received and sent by the vihome application. It may be possible to adapt GitHub - sandysound/orvibo2mqtt: A bridge from the orvibo socket sever to MQTT for home assistant mqtt auto discovery integration or GitHub - happyleavesaoc/python-orvibo or build on the projects they reference to format the request to send in.

The device seems to operate as a hub, using an emulated IR link and 7bit data to control the attached dimmer. Poking around the config directory I found a list of what the gpio is connected to but can’t seem to find my notes on that at the moment.

tcp 0 0 0.0.0.0:8088 0.0.0.0:* LISTEN PID1814 /oem/ember-host/bin/ember-host -t 1 PID1982 lircd rst:72
tcp 0 0 0.0.0.0:8600 0.0.0.0:* LISTEN same 2 pid above

1 Like

Those same config files also seem like the application might have some Chinese trigger words for voice control built in. With the announced HA focus on a local independent voice assistant, that interests me a lot. The intercom and broadcast features are okay but I can imagine some uses for the audio device via HA notifications or a voice/video call for the doorbell etc. I might end up cracking open one of them to see what else is there.

2 Likes

Hi, did you ever get any further on this? These look pretty nice for some areas in my house

1 Like

Is anyone still working on this by any chance? This sounded very promising.

4 Likes

I have not had a chance to look into it further, the switches now say they support Matter integration so when that is ready in HA it might be easier to integrate them that way.

1 Like

Real interesting device.

I have a couple of them that i brought. The obvious end point i found was /sys/devices/platform/backlight/backlight/backlight/brightness which is the display brightness.

This teardown link wasn’t to hard to find https://fccid.io/2AWF7-V70X/Internal-Photos/Internal-photos-6008352 looks pretty interesting inside with header pins and some sort of RTL872 not opened mine up to confirm if these pictures are production boards or not. I see 8723ds kernel module loaded. The spec seems to suggest it supports 2.4 & 5ghz.

1 Like

just picked up 3 of these for use around my house and will probably goof around with them this week. would love to get these integrated myself even just for local control via HA, but I am also interested in figuring out how to expose other devices TO the switch (even through some hacky bridge), if anyone has attempted that yet.

They’re currently 20% off with a $30 off coupon on Amazon so quite cheaper than they usually are:

1 Like

looked around the filesystem for a bit today and found a few neat things:

  • it seems like there is some persistent device memory mounted to /userdata and /orb_data
  • there are some MP3 files in /orb_data/local_music
  • you can use the play cmd from the ADB shell to play these MP3s over the device speaker (cool?)
  • there is a basic utility that can turn the switch on/off and toggle:
=======VV=========== Zigbee测试命令 =======VV===========
/oem/ember-host/bin/dm-uds-command.sh -t search                      # zigbee>打开组网
/oem/ember-host/bin/dm-uds-command.sh -t devicelist                  # zigbee>获取已经入网设备列表
/oem/ember-host/bin/dm-uds-command.sh -t on                          # zigbee>所有开关打开
/oem/ember-host/bin/dm-uds-command.sh -t off                         # zigbee>所有开关关闭
/oem/ember-host/bin/dm-uds-command.sh -t toggle                      # zigbee>所有开关反转
/oem/ember-host/bin/dm-uds-command.sh -t kickall                     # zigbee>把添加进来的设备全部剔除,并关闭组网
/oem/ember-host/bin/dm-uds-command.sh -t zigbee_clear_network        # zigbee>清除zigbee网络(重启后才重新建网,对工厂使用,用户慎用)
=======VV===== 串口485 开关底壳 测试命令 =======VV======
/oem/ember-host/bin/dm-uds-command.sh -s devicelist                       # 485>获取已经入网设备列表
/oem/ember-host/bin/dm-uds-command.sh -s search                           # 485>启动发现设备
/oem/ember-host/bin/dm-uds-command.sh -s device_trun_on     -d [node_id]  # 485>打开设备列表中node_id字段的灯
/oem/ember-host/bin/dm-uds-command.sh -s device_trun_off    -d [node_id]  # 485>关闭设备列表中node_id字段的灯
/oem/ember-host/bin/dm-uds-command.sh -s device_trun_toggle -d [node_id]  # 485>翻转设备列表中node_id字段的灯
=======VV===== 串口485 安防底壳 测试命令 =======VV======
getprop sys.orb.bottomcase             # 得到>mixpads_sensorbox
/oem/ember-host/bin/dm-uds-command.sh -s sensor_box_status                # 485>获取传感器全部状态
/oem/ember-host/bin/dm-uds-command.sh -s sensor_box_find_485              # 485>下发命令检测外接485是否存在
=======VV===== 通用设备 测试命令 =======VV======
/oem/ember-host/bin/dm-uds-command.sh -c devicelist -p [zigbee/serial/ble]                   # 获取相关引擎已经入网设备列表 ,返回json串
/oem/ember-host/bin/dm-uds-command.sh -c [cmd] -d [node_id] -p [str]                         # 通过cmd命令,控制设备node_id,输入参数str
      1、/oem/ember-host/bin/dm-uds-command.sh -c setonoff -d [node_id] -p [on/off/toggle]   # 通过onoff命令,控制设备node_id
      2、/oem/ember-host/bin/dm-uds-command.sh -c getvalue -d [node_id] -p [devicetype]      # devicetype是设备类型, 通过getvalue命令,获取设备node_id的数据,数据通过json返回
      3、/oem/ember-host/bin/dm-uds-command.sh -c setmask  -d [node_id] -p [on/off]          # 通过onoff命令,屏蔽设备node_id的状态上报

you can use the -s devicelist to get the id of the switch and then the -s device_trun_on -d [node_id] to activate the light

this shell script is basically just echoing commands to an open socket using socat

I’m going to test getting these implemented using Matter on 2023.5 (as soon as I finish upgrading my system to 64bit), but if that doesn’t work, it seems like there’s a possibility to run a very small netcat based server on the switch that is started using the root crontab that supports some very basic commands

1 Like

well, I am clueless on how to add these via the Matter integration- there is seemingly no way to put the device in some kind of pairing mode to add it to a Matter network, and I cannot seem to get the companion app to go into “pairing mode” either, so I’ll have to try this again another time

I found out that you can change the root password by remounting /dev/block/by-name/rootfs_data .

Here’s what I did:

  1. adb connect 127.0.0.1 # Replace 127.0.0.1 with your Mixpad D1 IP Address
  2. adb shell
  3. mount -o rw,remount /dev/block/by-name/rootfs_data
  4. cat /proc/mounts # Verify that /dev/block/by-name/rootfs_data is read & write
  5. passwd root # Once executed, enter your password for root
  6. exit
  7. ssh [email protected] # Enter password for root SSH

Now you can change settings through SSH without ADB installed.

Note: I haven’t tried it past an update yet, so the root password may get reset after an update.

3 Likes

I received an email back last week from the Orvibo folks and they authorized the beta version of the firmware for my account, which they expect to be released this month more broadly. There is a very straightforward way to include the device in a Matter fabric now. I was able to control the dimmer within Home Assistant without fail immediately. It was really slick, and can probably be added to the supported devices page!

However, I think I’m still interested in:

  1. treating the device like a media player within homeassistant (playing audio to it, seems to be possible)
  2. exposing other non-orvibo devices to the screen for control
  3. feedback on setting the home/away scenes within the device in homeassistant

so I’m going to keep tinkering as well. I probed further with Orvibo support to see if there was local API documentation available or options planned for the future to add other Matter devices as controllable items on the mixpad itself.

but for now, I’m pretty satisfied with barebones controllable functionality within Home Assistant as a Matter entity!

2 Likes

Do you mind sharing what was the process like to get your devices enrolled in the beta firmware and how long it took? I’ve sent an email through their app asking to enroll mine but haven’t heard back.

UPD: Never mind, I got through and they updated my switches to support matter. Works great.
They also told me that they are working to have their switches turn on/off instantly (although I’ve selected that my lights are not dimmable during setup, it messes up with my led driver during the default dimming transition and starts to flicker). They promised to push the update to me as soon as it’s ready.

Those are really neat switches, I don’t have the skills to dig deeper into it, but would love to get access to the luminosity sensor in HA. Even better would be some sort of background app or custom firmware that would allow access to the mic and speaker to use it as a local HA voice assistant device that’s discreetly available in every room

I just bought a Mixpad D1 last week. I used the app and asked for the Matter update. I received the update in less than 24 hours. I can’t get the Matter update to work with Home Assistant, but it works in SmartThings, Homekit, and Amazon.

I also asked about the instant-off feature and they told me they are working on a software update and will push it out as soon as possible. I hate the fade-off feature.

After the matter update to home assistant, I now have the d1 working.

I also got my switch into Home Assistant with ease after I requested and received the matter update.
I was curious if anyone else has figured out how to use the speaker function on it with home assistant?

I purchased one of these recently and applied the matter update. Afterwards, it seems like ADB is closed off. A factory reset (under info, long-press device name) just clears the user settings but doesn’t actually downgrade the OS. Long-pressing WiFi Address brings up a menu with two factory test apps, one for checking out all the internal functionality, and one for doing a burn-in test. Interestingly, doing a factory reset and then setting up with Matter again, without ever telling the MixPad which WiFi network to connect to, gets it on the right WiFi network. Is that part of Matter or is that the device not actually erasing all the user data?

With the goal of getting ADB working, I disassembled the device and found some TX/RX pads on the back side of the low-voltage PCB. This is a serial port with a bit period of 666.6 ns according to my scope (1.5 MBaud). Here’s the bootup dump (with all ribbon cables disconnected):

DDR V2.06 20220317
ln
vlog1v
D3,512MB,333MHz
bw      col     bk      row     cs      dbw
16      10      8       15      1       16
OUT
Boot1 Release Time: Dec 28 2021 15:25:31, version: 1.35
support nand flash type: slc
ROM VER:0x56323030, 26
hamming_distance:3326 3330 3
chip_id:524b3326_0,0
ChipType = 0x1a, 1044
...nandc_flash_init enter...
No.1 FLASH ID:98 dc 90 26 76 16
No.2 FLASH ID:ff ff ff ff ff ff
SFTL version: 5.0.57 20211222
...FtlVpcCheckAndModify enter...
SdmmcInit=0 NOT PRESENT
StorageInit ok = 169809
SecureMode = 0
Secure read PBA: 0x4
Secure read PBA: 0x204
Secure read PBA: 0x404
Secure read PBA: 0x604
Secure read PBA: 0x804
SecureInit ret = 0, SecureMode = 0
atags_set_bootdev: ret:(0)
GPT part:  0, name:            uboot, start:0x4000, size:0x2000
GPT part:  1, name:            trust, start:0x6000, size:0x2000
GPT part:  2, name:             misc, start:0x8000, size:0x800
GPT part:  3, name:             boot, start:0x8800, size:0x4000
GPT part:  4, name:         recovery, start:0xc800, size:0x7000
GPT part:  5, name:               sn, start:0x13800, size:0x80
GPT part:  6, name:             uuid, start:0x13880, size:0x80
GPT part:  7, name:           rootfs, start:0x13900, size:0x23000
GPT part:  8, name:              oem, start:0x36900, size:0x37000
GPT part:  9, name:         orb_data, start:0x6d900, size:0x16000
GPT part: 10, name:      rootfs_data, start:0x83900, size:0x1000
GPT part: 11, name:      backup_data, start:0x84900, size:0x3000
GPT part: 12, name:         userdata, start:0x87900, size:0x666df
find part:uboot OK. first_lba:0x4000.
find part:trust OK. first_lba:0x6000.
LoadTrust Addr:0x6000
No find bl30.bin
Load uboot, ReadLba = 4000
Load OK, addr=0x200000, size=0xdc468
RunBL31 0x40000 @ 276635 us
INFO:    Preloader serial: 2
NOTICE:  BL31: v2.3():v2.3-354-g14c8e3da7:huan.he
NOTICE:  BL31: Built : 09:00:18, Apr 20 2022
NOTICE:  BL31:Rockchip release version: v1.0
INFO:    ARM GICv2 driver initialized
INFO:    Using opteed sec cpu_context!
INFO:    boot cpu mask: 1
INFO:    plat_rockchip_pmu_init: pd status f00e
INFO:    BL31: Initializing runtime services
INFO:    BL31: Initializing BL32
I/TC:
I/TC: OP-TEE version: 3.13.0-641-g4167319d3 #hisping.lin (gcc version 10.2.1 20201103 (GNU Toolchain for the A-profile Architecture 10.2-2020.11 (arm-10.16))) #9 Wed Mar 16 17:44:01 CST 2022 aarch64
I/TC: Primary CPU initializing
I/TC: Primary CPU switching to normal world boot
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x200000
INFO:    SPSR = 0x3c9


U-Boot 2017.09 (May 16 2023 - 07:11:09 +0000)

Model: Rockchip RK3326 EVB
PreSerial: 2, raw, 0xff160000
DRAM:  502 MiB
Sysmem: init
Relocation Offset: 1db9e000
Relocation fdt: 1bd93200 - 1bd94cc3
CR: M/C/I
Using default environment

DM: v1
...nandc_flash_init enter...
No.1 FLASH ID:98 dc 90 26 76 16
SFTL version: 5.0.56 20210329
Bootdev(atags): rknand 0
PartType: EFI
boot mode: None
Found DTB in boot part
DTB: rk-kernel.dtb
HASH(s): OK
I2c0 speed: 400000Hz
PMIC:  RK8090 (on=0x40, off=0x00)
vdd_logic 1000000 uV
vdd_arm 900000 uV
Could not find baseparameter partition
Model: Rockchip rk3326 mixpad-d
orb main key status:
key1:[0],key2:[0],key3:[0]
key4:[1],key5:[0],key6:[0]
get_mixpad_main_gpio_id:value=0x0010
main hw not match, use default
get_mixpadmini_secondary_gpio_id key1=0,key2=1,key3=1
get_mixpadmini_secondary_gpio_id mixpad_model=0x0003
get_mixpadmini_secondary_gpio_id2 key1=0,key2=0,key3=0
get_mixpadmini_secondary_gpio_id2 mixpad_model_id2=0x0000
saradc 0 val = 511
orb_mixpad_model_check : main_model=0
orb_mixpad_model_check : device_model=2
orb_mixpad_model_check : device_model_id2=0
orb_mixpad_model_check : device_model_adc_val=511
orb-logo]devtype:rknand,devnum:0
orb-logo] read logo-header(.orb_logo.bmp) ++
orb-logo],partNUm:0:d
orb-logo],Error:file(.orb_logo.bmp) not exist
orb-logo] read logo-header --
orb-logo],1,Using default-logo,for read logo-file(.orb_logo.bmp) failed
orb-logo],2,Using default-logo,for read logo-file(.orb_logo.bmp) failed
Rockchip UBOOT DRM driver version: v1.0.1
Using display timing dts
rgb:  detailed mode clock 165000 kHz, flags[a]
    H: 0170 0175 0185 0195
    V: 0320 0325 0335 0345
bus_format: 101c
CLK: (sync kernel. arm: enter 400000 KHz, init 600000 KHz, kernel 600000 KHz)
  apll 600000 KHz
  dpll 1332000 KHz
  cpll 660000 KHz
  npll 1188000 KHz
  gpll 1200000 KHz
  aclk_bus 200000 KHz
  hclk_bus 150000 KHz
  pclk_bus 100000 KHz
  aclk_peri 200000 KHz
  hclk_peri 150000 KHz
  pclk_pmu 100000 KHz
Net:   Net Initialization Skipped
No ethernet found.
Hit key to stop autoboot('CTRL+C'):  0
ANDROID: reboot reason: "(none)"
optee api revision: 2.0
TEEC: Waring: Could not find security partition
Booting LZ4 kernel at 0x03e80000(Uncompress to 0x00280000) with fdt at 0x08300000...


Fdt Ramdisk skip relocation
## Booting Android Image at 0x03e7f800 ...
Kernel: 0x00280000 - 0x008c8cb5 (6436 KiB)
## Flattened Device Tree blob at 0x08300000
   Booting using the fdt blob at 0x08300000
   Uncompressing LZ4 Kernel Image from 0x03e80000 to 0x00280000 ... with 00cdc008 bytes OK
   kernel loaded at 0x00280000, end = 0x00f5c008
  'reserved-memory' ramoops@110000: addr=110000 size=f0000
   Using Device Tree in place at 0000000008300000, end 000000000831d59d
orb-logo]devtype:rknand,devnum:0
orb-logo] read logo-header(.orb_logo.bmp) ++
orb-logo],partNUm:0:d
orb-logo],Error:file(.orb_logo.bmp) not exist
orb-logo] read logo-header --
orb-logo],1,Using default-logo,for read logo-file(.orb_logo.bmp) failed
orb-logo],2,Using default-logo,for read logo-file(.orb_logo.bmp) failed
failed to reserve drm-cubic-lut memory
Adding bank: 0x00200000 - 0x08400000 (size: 0x08200000)
Adding bank: 0x08c00000 - 0x20000000 (size: 0x17400000)
Total: 1652.100 ms

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 4.4.194 (root@55d5dd6ab898) (gcc version 6.3.1 20170404 (Linaro GCC 6.3-2017.05) ) #13 SMP Tue May 16 07:11:50 UTC 2023
[    0.000000] Boot CPU: AArch64 Processor [410fd042]
[    0.000000] earlycon: Early serial console at MMIO32 0xff160000 (options '')
[    0.000000] bootconsole [uart0] enabled
[    0.000000] On node 0 totalpages: 128512
[    0.000000]   DMA zone: 2040 pages used for memmap
[    0.000000]   DMA zone: 0 pages reserved
[    0.000000]   DMA zone: 128512 pages, LIFO batch:31
[    0.000000] psci: probing for conduit method from DT.
[    0.000000] psci: PSCIv1.1 detected in firmware.
[    0.000000] psci: Using standard PSCI v0.2 function IDs
[    0.000000] psci: Trusted OS migration not required
[    0.000000] PERCPU: Embedded 21 pages/cpu @ffffffc01ff21000 s45736 r8192 d32088 u86016
[    0.000000] pcpu-alloc: s45736 r8192 d32088 u86016 alloc=21*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[    0.000000] Detected VIPT I-cache on CPU0
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 126472
[    0.000000] Kernel command line: storagemedia=nand androidboot.storagemedia=nand androidboot.mode=normal  orbmodel=MixpadHostD androidboot.serialno=<removed>  rootwait earlycon=uart8250,mmio32,0xff160000 swiotlb=1 loglevel=8 root=PARTUUID=614e0000-0000 rootfstype=squashfs
[    0.000000] PID hash table entries: 2048 (order: 2, 16384 bytes)
[    0.000000] Dentry cache hash table entries: 65536 (order: 7, 524288 bytes)
[    0.000000] Inode-cache hash table entries: 32768 (order: 6, 262144 bytes)
[    0.000000] software IO TLB: mapped [mem 0x1fe1d000-0x1fe5d000] (0MB)
[    0.000000] Memory: 481552K/514048K available (8190K kernel code, 1200K rwdata, 2772K rodata, 960K init, 612K bss, 32496K reserved, 0K cma-reserved)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     modules : 0xffffff8000000000 - 0xffffff8008000000   (   128 MB)
[    0.000000]     vmalloc : 0xffffff8008000000 - 0xffffffbdbfff0000   (   246 GB)
[    0.000000]       .init : 0xffffff8008b40000 - 0xffffff8008c30000   (   960 KB)
[    0.000000]       .text : 0xffffff8008080000 - 0xffffff8008880000   (  8192 KB)
[    0.000000]     .rodata : 0xffffff8008880000 - 0xffffff8008b40000   (  2816 KB)
[    0.000000]       .data : 0xffffff8008c30000 - 0xffffff8008d5c008   (  1201 KB)
[    0.000000]     vmemmap : 0xffffffbdc0000000 - 0xffffffbfc0000000   (     8 GB maximum)
[    0.000000]               0xffffffbdc0008000 - 0xffffffbdc0800000   (     7 MB actual)
[    0.000000]     fixed   : 0xffffffbffe7fb000 - 0xffffffbffec00000   (  4116 KB)
[    0.000000]     PCI I/O : 0xffffffbffee00000 - 0xffffffbfffe00000   (    16 MB)
[    0.000000]     memory  : 0xffffffc000200000 - 0xffffffc020000000   (   510 MB)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[    0.000000] Hierarchical RCU implementation.
[    0.000000]  Build-time adjustment of leaf fanout to 64.
[    0.000000]  RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
[    0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=4
[    0.000000] NR_IRQS:64 nr_irqs:64 0
[    0.000000] GIC: Using split EOI/Deactivate mode
[    0.000000] Architected cp15 timer(s) running at 24.00MHz (phys).
[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns
[    0.000009] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 4398046511097ns
[    0.002515] Console: colour dummy device 80x25
[    0.002939] console [tty0] enabled
[    0.003273] bootconsole [uart0] disabled
I/TC: Secondary CPU 1 initializing
I/TC: Secondary CPU 1 switching to normal world boot
I/TC: Secondary CPU 2 initializing
I/TC: Secondary CPU 2 switching to normal world boot
I/TC: Secondary CPU 3 initializing
I/TC: Secondary CPU 3 switching to normal world boot

I’ve done some work with Yocto/uboot in the past but I’m going to have to read up on how to get the boot console to stay up (unless anybody here knows?). Edit: I hooked up the RX side of the UART and it seems like maybe bootdelay is set to 0 because it doesn’t register my CTRL+C (and also doesn’t visibly count down). I was able to interrupt it eventually and get into the uboot cmd.

=> printenv
arch=arm
autoload=no
baudrate=1500000
board=evb_px30
board_name=evb_px30
boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}extlinux/extlinux.conf
boot_net_usb_start=usb start
boot_prefixes=/ /boot/
boot_script_dhcp=boot.scr.uimg
boot_scripts=boot.scr.uimg boot.scr
boot_targets=mmc1 mmc0 rknand0 usb0 pxe dhcp
bootargs=storagemedia=nand androidboot.storagemedia=nand androidboot.mode=normal  orbmodel=MixpadHostD
bootcmd=boot_android ${devtype} ${devnum};boot_fit;bootrkp;run distro_bootcmd;
bootcmd_dhcp=run boot_net_usb_start; if dhcp ${scriptaddr} ${boot_script_dhcp}; then source ${scriptaddr}; fi;
bootcmd_mmc0=setenv devnum 0; run mmc_boot
bootcmd_mmc1=setenv devnum 1; run mmc_boot
bootcmd_pxe=run boot_net_usb_start; dhcp; if pxe get; then pxe boot; fi
bootcmd_rknand0=setenv devnum 0; run rknand_boot
bootcmd_usb0=setenv devnum 0; run usb_boot
bootdelay=0
cpu=armv8
devnum=0
devtype=rknand
distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done
eth1addr=<removed>
ethaddr=<removed>
fdt_addr_r=0x08300000
kernel_addr_c=0x03e80000
kernel_addr_r=0x00280000
mmc_boot=if mmc dev ${devnum}; then setenv devtype mmc; run scan_dev_for_boot_part; fi
partitions=uuid_disk=${uuid_gpt_disk};name=loader1,start=32K,size=4000K,uuid=${uuid_gpt_loader1};name=loader2,start=8MB,size=4MB,uuid=${uuid_gpt_loader2};name=trust,size=4M,uuid=${uuid_gpt_atf};name=boot,size=112M,bootable,uuid=${uuid_gpt_boot};name=rootfs,size=-,uuid=B921B045-1DF0-41C3-AF44-4C6F280D3FAE;
pxefile_addr_r=0x00600000
ramdisk_addr_r=0x0a200000
rkimg_bootdev=if mmc dev 1 && rkimgtest mmc 1; then setenv devtype mmc; setenv devnum 1; echo Boot from SDcard;elif mmc dev 0; then setenv devtype mmc; setenv devnum 0;elif mtd_blk dev 0; then setenv devtype mtd; setenv devnum 0;elif mtd_blk dev 1; then setenv devtype mtd; setenv devnum 1;elif mtd_blk dev 2; then setenv devtype mtd; setenv devnum 2;elif rknand dev 0; then setenv devtype rknand; setenv devnum 0;elif rksfc dev 0; then setenv devtype spinand; setenv devnum 0;elif rksfc dev 1; then setenv devtype spinor; setenv devnum 1;elsesetenv devtype ramdisk; setenv devnum 0;fi;
scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;
scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done
scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}extlinux/extlinux.conf; then echo Found ${prefix}extlinux/extlinux.conf; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
scriptaddr=0x00500000
serial#=<removed>
soc=rockchip
stderr=serial,vidconsole
stdout=serial,vidconsole
usb_boot=usb start; if usb dev ${devnum}; then setenv devtype usb; run scan_dev_for_boot_part; fi
vendor=rockchip

There are also pads for USB (5V/GND/ID/D+/D-) on the top side of the low-voltage board which are easily accessible without disconnecting any of the ribbon cables. I wonder if ADB will connect through that USB interface?

Looking into Dart/Flutter, there is a WebView widget with a native Android implementation; seems like it could be quick to build a simple Flutter UI with just this single WebView widget set up to load either a pre-baked Home Assistant URL, or a URL from a file, etc.

Anybody here make any more progress? Any thoughts on how to get ADB/SSH access again after applying the Matter update?

3 Likes

I was able to get to the root shell! I just held down CTRL+C prior to applying power, then I changed the bootargs env var to:

storagemedia=nand androidboot.storagemedia=nand androidboot.mode=normal orbmodel=MixpadHostD console=uart8250,mmio32,0xff160000 earlyprintk=serial,keep

From there I remounted the rootfs as rw and changed the root password, per @Smord’s post, and could then SSH into the device.

Here’s what dmesg reported for the kernel args after my env changes:

storagemedia=nand androidboot.storagemedia=nand androidboot.mode=normal orbmodel=MixpadHostD console=uart8250,mmio32,0xff160000 earlyprintk=serial,keep androidboot.serialno=<removed>  rootwait earlycon=uart8250,mmio32,0xff160000 swiotlb=1 loglevel=8 root=PARTUUID=614e0000-0000 rootfstype=squashfs

After reassembly and a power cycle, everything still works and the root credentials are preserved.

There are references to android all over the filesystem, and adb_shell and adbd are in the path, but whatever is on this thing doesn’t really look like android. And maybe that’s fine; there are lots of references to Weston and Flutter, and my understanding is that Flutter can/will use the Android NDK to make native executables, so there’s a chance that the WebView thing might still work.

To start, I’m just going to try to make a “hello world” flutter app run on the device. But I’m not sure what Android platform version to pick in Android Studio. uname -r reports 4.4.194 which should be android 8 or 9 but who knows with this thing.

The internals of this device are extremely clean and it seems very well-built overall. To open it up, I started to shim it near where the ground strap exits the case (looking at it from the back, I picked the bottom-left side). I moved the shim clockwise to the left side (from the back) and popped that side open, then wiggled the whole back casing a bit to separate the low power and high power boards.

There is a “typical” 0.1" pitch 4x2 board-to-board connector (can be seen in the disassembly photos linked by @tcrofts ) to feed 5V power from the HV side to the LV side, and there is some kind of slower (115200) serial interface between the boards, presumably to control the dimmer/relay functionality. A plastic clip-on cover helps insulate the WiFi/BT chip and other components on the LV side from the HV side. The USB (OTG?) pads are on under this cover, and the boot UART pads are on the same edge as the WiFi/BT chip but on the “back” side of the board.

Reassembly was very easy and the back cover snapped right back on and feels just as secure as before. The physical quality of this thing is great, which makes me all the more determined to get some kind of HA (visual) interface running on it.

6 Likes