I have worked a bit more on WiFi flasher. I've added a commandline, but I also have bad news.
Commandline:
OBK WiFi Downloader.
positional arguments:
filename specify file_crc.bin
optional arguments:
-h, --help show this help message and exit
-d DEVICE, --device DEVICE
Target device, default 192.168.0.1:8888
-s STARTADDR, --startaddr STARTADDR
burn flash address, defaults to 0x11000
-l LENGTH, --length LENGTH
length to read, defaults to 0x1000
-b BAUDRATE, --baudrate BAUDRATE
burn uart baudrate, defaults to 921600
-u, --unprotect unprotect flash first, used by BK7231N
-r, --read read flash
-w, --write write flash
-t, --test test flash (generate pattern, write, read, verify)
-v, --verify verify flash
-w -s 0 -u OpenBK7231N_QIO_1.18.193.bin
Short test:
-u -t -s 0 -l 0x2000
Long test:
-u -t -s 0 -l 0x100000
The bad news is that it somehow started having issues with getting bus. I am short on time, so I didn't do excessive testing, so I am a bit confused on what happened - is it the latency issue? Latency has changed on my WiFi? Or was it due to the flash content change of target Beken, maybe it was in a state where it was constantly rebooting so CEN wasn't really used?
At least it's
still working, it just needs like half a minute to get bus.
It is possible that I will have just need to make a tiny utility for getting bus on OBK itself (not via remote commands). It seems it's hard to get precise timing by sending pin toggle via HTTP and UART packet via TCP to UART.
Or maybe... if uartSendHex still works with TCP to UART, then maybe I can backlog hex send and CEN toggle for better timing, hmmm
I think I will release it tomorrow in a separate topic.