Flashing VeSync GreenSun WHOGPLUG Smart Plug to BK7231M Module

VeSync / GreenSun smart plug info.
See https://github.com/openshwprojects/OpenBK7231T_App/issues/826 and flashing guide (though OTA ability might be a work-in-progress right now) https://www.elektroda.com/rtvforum/topic4058227.html

Like the BSD33 here https://www.elektroda.com/rtvforum/topic4058227.html#21450591 I have flashed this user's (@thenitek) backup to a BK7231M module which has a key of 00000000 00000000 00000000 00000000 in efuse.

fw ver 1.0.01 boot log from TX2


VeSync app pairing and update screesnhots:





fw ver 1.0.02 boot log from TX2


Added after 10 [minutes]:

both versions fw backups can be found here https://github.com/openshwprojects/FlashDumps/tree/main/IoT/BK7231M

Added after 1 [hours] 33 [minutes]:

OTA is at 0x125000 on these. Flash a BK7231N rbl to that address and it OTAs to OBK




0x125000 start address and 0xB0000 length (737,280 bytes) - I think!


I had to ask ChatGPT for help on the length


Added after 9 [minutes]:

Regarding the mac. TLV starts at 0x1D9000 where the mac we'd like to see in OpenBeken after OTA from VeSync 1.0.02-> OBK is seen - FC 58 4A A1 D3 C2

which correlates with what's seen in the VeSync app


current:

with custom build where OTA partition is changed to 0x125000 then OTA works as expected https://github.com/openshwprojects/OpenBK7231T_App/pull/1542







mac is still wrong though even with 0x1D9000 set for RF/Net

>>21452918 Are those partitions correct? They shouldn't intersect.

Have you tried to replace bootloader with standard 1.0.1? That should fix OTA, but would still do nothing for MAC. Though you would have to edit build.sh
Either uncomment (i don't know why it is commented out, not working perhaps?) https://github.com/openshwprojects/OpenBK7231...ter/platforms/bk7231n/bk7231n_os/build.sh#L72
Or combine binary with unencrypted bootloader and then run encryption with these parameters: 0 0 0 0 0
Not sure if it would work though, i did once encrypted a 1.0.13 bootloader for bk7231n and it worked.

insmod wrote:

Are those partitions correct? They shouldn't intersect.

ah probably not correct then. couldn't quite get head round the 01PE hex for this one for some reason.

insmod wrote:

Have you tried to replace bootloader with standard 1.0.1? That should fix OTA, but would still do nothing for MAC. Though you would have to edit build.sh

this would be the ultimate, then no need for these odd M builds for each vendor's chosen partition layout. I have flashed a few BLs, but none so far have booted. I've also tried making my own using RT-Thread Partition Tool. I'll have another go, getting a good BL for 000000 key devices, which uses standard Tuya partition addresses, would be the way to go it seems

As i've written before, i don't remember what exactly i've done to encrypt bootloader.
But, another possibility is to run encrypt with zero keys and zero address on unencrypted bootloader directly, and then combine it with uart firmware and run standard encrypt with zero keys and 10000 address.

i see.

so we could perhaps do that with something like



if using the newer version of encrypt.exe



https://github.com/openshwprojects/OpenBK7231...k7231n_os/beken378/build/post-build-steps.bat

Added after 3 [minutes]:

hmm. bootloader_bk7231n_uart2_v1.0.8_enc.bin doesn't seem to boot. nor does a standard BK7231N_1.0.1 decrypted/re-encrypted from a device with bk7231tools

Added after 25 [minutes]:

oh. doesn't this suggest M QIO already has this https://www.elektroda.com/rtvforum/topic4056377.html#21106098

Probably related discussion:
https://www.elektroda.com/rtvforum/topic4032988-30.html#21466523

regarding https://www.elektroda.com/rtvforum/viewtopic.php?p=21723544#21723544

these changes have made a BK7231M QIO that boots and can OTA. BK7231N appears to remain working.

https://github.com/openshwprojects/OpenBK7231N/compare/master...divadiow:bk7231m_qio?expand=1

Nice, i think I have BK7231M hooked to WiFi flasher, so I can check, however, please first make sure that your changes do not affect other binaries going through that path, in this case, the classic BK7231N binary.

OK. I will double-check BK-N is OK.

wait. BK7231M_ALT (OpenBK7231M_ALT_QIO_1.18.202.bin) does boot already. It's being built with bk7231n_bootloader.bin, assuming comparison script is working. bk7231n_bootloader_zero_keys.bin not being used at all?



uncrc and comparison script



Added after 2 [hours] 9 [minutes]:

oh https://github.com/openshwprojects/OpenBK7231...s/bk7231n/bk7231n_os/build.sh#L144C20-L144C30

Added after 37 [minutes]:

not sure I fully understand what's happening. If you delete bk7231n_bootloader_zero_keys.bin build does not fail. With these two changes BK7231M QIO boots and detection script says:

It is possible that zeroKeys was not used in the end, but I am not sure.

I've checked ALT now with WiFi Flasher. It boots:

ALT boots yes, but the old SDK M QIO does not

Added after 2 [minutes]:

change bk7231n_bootloader_enc.bin to bk7231n_bootloader.bin in the M code block and then it'll boot

I am not sure what happened there, but you may have a correct solution. First I tried to manually insert a bootloader with 0 keys, but then I realized that we can just use the one without _enc