Closed DavidWang2014-01-28 closed 3 years ago
Thanks for testing 😝
buy new hub till they have factory firmware 1.4.5/1.4.6 (expect 1.4.7 soon) OR solder uart, boot to bootloader and fix boot_info partition so it boots using older firmware slot.
@rezmus two questions:
device has 2 slots for kernel/rootfs. this method works if you did update to firmware 1.4.7 only once, so you still have firmware 1.4.4-1.4.6 in 2nd slot. if you did update to 1.4.7 twice or more (for example 1.4.7_0063 and then 1.4.7_0065) this method can't be used. you will have to solder ethernet and recover via tftp.
once you boot to bootloader you have to modify boot_info to make device boot from the other slot (firmware 1.4.4-1.4.6).
note: use all bootloader commands in the same (lower/upper)case they are bellow.
# read boot_info to from nand to memory
NANDR 0xa0000 0xa0a00000 55
# display boot_info in memory
db 0xa0a00000 55
example output
A0A00000: 7c 91 00 00 XX XX YY YY YY YY 00 20 ec 04 c8 cf
A0A00010: 01 00 20 74 04 e8 7e 01 00 82 80 04 62 c6 00 00
A0A00020: 75 90 04 a4 0a 00 00 00 01 31 2e 30 2e 32 2e 30
A0A00030: 30 35 00 00 00 00 00
XX XX is boot_info checksum and YY YY YY YY is slot setup. slot setup will be 00 00 00 00 which means 1st slot is used or 01 01 01 01 which means 2nd slot is used. your goal is to change it to opposite and fix boot_info checksum.
if you change 00 00 00 00 to 01 01 01 01 you have to subtract 2 (-2) from each checksum byte. if you change 01 01 01 01 to 00 00 00 00 you have to add 2 (+2) to each checksum byte.
for example we had XX XX YY YY YY YY = 7a 25 00 00 00 00. we need to make it 78 23 01 01 01 01.
# modify boot_info in memory
eb 0xa0a00000 7c 91 00 00 XX XX YY YY YY YY
where XX XX YY YY YY YY is value we want to have (that we calculated in previous step). now we can display boot_info again and check if it looks like we want.
# display boot_info in memory
db 0xa0a00000 55
if everything is OK we can save it to nand.
# write boot_info from memory to nand
NANDW a0000 a0a00000 55
after reboot it should boot from the other slot (older firmware).
note: ALWAYS keep all uart logs and/or backups!
if your boot_info partition looks like this
A0A00000: 7c 91 00 00 XX XX YY YY YY YY 00 00 00 00 00 00 A0A00010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 A0A00020: 00 00 00 00 00 00 00 00 01 31 2e 30 2e 32 2e 30 A0A00030: 30 35 00 00 00 00 00
it got wiped during boot (can happen if you short tp16/tp13 in wrong moment). you need to recreate it based on info from logs/backups or headers of rootfs partitions. in case of such problem tag me in this thread.
Works only if the previous firmware was with an open Telnet.
If you upgraded twice to a bad firmware, it does not work.
If you have bad firmware from the factory (euro hub) - it does not work.
for global hub ZNDMWG02LM with firmware 1.4.6_0043 we should be able to open telnet using similar method (uart + boot to bootloader). if somebody wants to try tag me in this thread.
Hi rezmus:
With your method, I successfully downgrade to the old firmware. But there is a mistake in your instructions. When interrupted the boot sequence, the boot_info may be reset to default values. (need interrupt boot at right timing) the sum and size value of kerne and rootfs become to zero.
So it is important to keep the logs to know the sum and size of kernel and rootfs.
there is no mistake there, but indeed boot_info can be wiped if you short tp16/gnd in wrong moment, because it's being read/write during boot (to mark failed attempts). i entered bootloader several times without wipe, but saw similar cases before. if you have boot logs or backup you can recreate boot_info. you can also restore it by reading kernel/rootfs header of both slots. i have checksum/size of each firmware.
I mean that it is very easy to get the wrong boot_info if short tp16/gnd in the wrong moment. So in your instructions, there shall be a step to check boot_info is correct or not to remind the user the boot_info was not reset to default.
some ppl with wiped boot_info had also broken rootfs/kernel partitions. some had no backups or uart logs so it's more tricky to restore it. you have to read partition header to check which fw version is there. at this point i think it's best to just write here in case of any problems with downgrade.
After several days' study. Here is some information I can share.
I can transmit kerenl and rootfs to DDR RAM by xmodem and write kernel or rootfs in DDR to SPI NAND
After flash kernel and rootfs in slot 0, slot 1, I rewrite the boot_info and flash to MTD1. Then can update any kernel or rootfs.
What is next? unsquashfs/mksquashfs the rootfs to enable telnetd.
By the way, if you are hardware engineer or magic GOD and have ethernet board for xaiomi gateway 3, you can use Ethernet and tftp to transmit firmwares. Unfortunately most users like poor me don’t have it. The Xmodem is only way to transmit firmwares. And WiFi and BT were not working in bootloader, too.
@tsunglung please describe xmodem method. some users cut utp cable and solder to board for tftp (probably way faster than xmodem), but i never did that so can't give you much details.
some info about custom squashfs
@rezmus There is no ethernet chip on the gateway3 board. Cut UTP cable to solder is still impossible.
I saw your info about custom squashfs. It helps a lot. Thanks. I tried to create a small rootfs yesterday but failed. I still try to find out why. I will try the custom complete rootfs today.
There is no ethernet chip on the gateway3 board. Cut UTP cable to solder is still impossible.
here you go, young Sherlock ) https://pasteboard.co/JyVxUOI.jpg
There is no ethernet chip on the gateway3 board. Cut UTP cable to solder is still impossible.
here you go, young Sherlock ) https://pasteboard.co/JyVxUOI.jpg
Great. Then we do not need to use xmodem to burn firmware.
@tsunglung Ethernet also works in stock firmware if you solder it :)
@tsunglung please describe xmodem method.
\<RealTek>xmrx 80000000 (start address of RAM) then start upload using your terminal program. beware, your're limited by ram size then you can copy from RAM to NAND: \<RealTek> snwbi \<RealTek> snwbwecc 80000000 [offset_on_nand/2048] [lenght_of_image_in_bytes]
xmodem is slow. Not good to transmit firmware.
xmodem is slow. Not good to transmit firmware.
enough to recover bootloader and boot_info partitions
agree.
boot up logs.
=== Linux Firmware === version=1.4.7_0065 branch=release-1.4.7_0060
=== RootFS Firmware === product=aqara-rtl8197-mijia-gateway branch=release-1.4.7_0060 VERSION=1.4.7_0065 version=1.4.7_0065
use telnet to login.
BusyBox v1.22.1 (2020-06-22 16:58:24 CST) built-in shell (ash) Enter 'help' for a list of built-in commands.
cat /etc/rootfs_fw_info product=aqara-rtl8197-mijia-gateway branch=release-1.4.7_0060 VERSION=1.4.7_0065 version=1.4.7_0065
miio-client --help Version: miio-client 4.1.3 Build time: 07:49:59 Aug 21 2020
Finally, my bricked gateway3 becomes alive after re-burn the firmware via stupid and slow xmodem.
Hope there could be easyway to flash the firmware, i was not able to buy new gatway with old firmware.
Just received the new ZNDMWG03LM with factory firmware v1.4.6_0043 ( Do I have any chance to downgrade the firmware and how? Thanks.
does this open a way to support 1.4.7_0065 firmware?
1.4.7 has closed telnet which can't be open. you want to downgrade or flash custom 1.4.7 firmware with telnet enabled. both require to solder uart.
Found firmware here, we still need an instruction for starter like me through. https://github.com/niceboygithub/XiaomiGateway3fw
fw_update is only for those with telnet access. if you don't have it you still need solder uart to flash custom firmware. manual and user friendly method will be published soon.
fw_update is only for those with telnet access. if you don't have it you still need solder uart to flash custom firmware. manual and user friendly method will be published soon.
please use this manual for flashing to latest 1.4.7 firmware with open telnet via UART: https://github.com/serrj-sv/lumi.gateway.mgl03/tree/main/uart_recovery
@serrj-sv Thanks for the guide, works on ZNDMWG02LM
I got the gateway with 1.4.6_0043 AFAIK with password telnet So, followed AlexxIT and Rezmus docs - got into bootloader, read memory and decoded 2 (two) passwords - those passwords is different depends of the entered MAC-address - all capitals or not. Anyway I've got two password and how now I can get into telnet session? If I boot up gw "normal way" and see gw on router - any my telnet attempts just tell me "connection refused". In the bootloader mode gw not accesible from net and no way to enter any commands except those included in the doc.Tried from windows, linux, mikrotik telnets. Any idea? Thanks
I got the gateway with 1.4.6_0043 AFAIK with password telnet So, followed AlexxIT and Rezmus docs - got into bootloader, read memory and decoded 2 (two) passwords - those passwords is different depends of the entered MAC-address - all capitals or not. Anyway I've got two password and how now I can get into telnet session? If I boot up gw "normal way" and see gw on router - any my telnet attempts just tell me "connection refused". In the bootloader mode gw not accesible from net and no way to enter any commands except those included in the doc.Tried from windows, linux, mikrotik telnets. Any idea? Thanks
https://github.com/serrj-sv/lumi.gateway.mgl03/tree/main/uart_recovery
@stryker01 if you have password already use @AlexxIT HA component to open telnet.
if you don't use HA you can open telnet with miio cmd.
@rezmus, thanks! HA component works halfway - I've got login on the UART session where enter needed commands to clear the password. After reboot @AlexxIT components works as planned. Need to resolder UART and then will try custom firmware
Hi all. I bought this gateway and upgraded it to 1.4.7_0065 before coming across this project. Anyhow, is it possible to downgrade the firmware using the UART method as documented in https://github.com/serrj-sv/lumi.gateway.mgl03/tree/main/uart_recovery?
@serrj-sv Thanks for the guide worked perfect on ZNDMWG03LM on a windows 10 PC with an CP2102 USB 2.0 to UART adapter.
@serrj-sv Thanks for the guide worked perfect on ZNDMWG03LM on a windows 10 PC with an CP2102 USB 2.0 to UART adapter.
thanks for feedback! glad it worked for you :)
@ serrj-sv https://github.com/serrj-sv/lumi.gateway.mgl03/tree/main/uart_recovery If you follow these instructions and install custom firmware 65, hone assistant will it work?
@ serrj-sv https://github.com/serrj-sv/lumi.gateway.mgl03/tree/main/uart_recovery If you follow these instructions and install custom firmware 65, hone assistant will it work?
of course, there is a minimum of differences from the original, the main difference is an open telnet and mqtt broker.
@VladimirSe76 I used that guide to install the firmware and get the gateway to work with HA.
for global hub ZNDMWG02LM with firmware 1.4.6_0043 we should be able to open telnet using similar method (uart + boot to bootloader). if somebody wants to try tag me in this thread. @rezmus I want to know how to do that? using similar method ? 1.4.6_0043 needs password(telnet has a password)
https://github.com/AlexxIT/XiaomiGateway3/wiki/Decode-Telnet-Password
@rezmus Thank you very much! I'll try to do it
@rezmus After following the steps instructions in the website link, restart the gateway and fail to telnet it The error message: The remote system refused the connection. Telnet server seems to be disabled? my firmware version is 1.4.6_0043
use @AlexxIT integration or miio command to start telnet service, then login with password you decoded.
@rezmus, hello, can you help me, please? I'm just wiped boot_info:
> NANDR 0xa0000 0xa0a00000 55
> db 0xa0a00000 55
[Addr] .0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .A .B .C .D .E .F
A0A00000: 7c 91 00 00 44 07 00 00 00 00 00 00 00 00 00 00 |...D...........
A0A00010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
A0A00020: 00 00 00 00 00 00 00 00 01 31 2e 30 2e 32 2e 30 .........1.0.2.0
A0A00030: 30 35 00 00 00 00 00
I've saved 2 'good' reboots:
Boot process is failing now:
I have no idea how to repair boot_info
I have no idea how to repair boot_info https://github.com/serrj-sv/lumi.gateway.mgl03/tree/main/uart_recovery
for global hub ZNDMWG02LM with firmware 1.4.6_0043 we should be able to open telnet using similar method (uart + boot to bootloader). if somebody wants to try tag me in this thread.
Hello,
@rezmus Is the "ZNDMWG02LM with firmware 1.4.6_0043" contains telnet? I am not able to connect to the Gateway. No promt only a message box with a "connection refused" error message. Is the telnet disabled by default?
Telnet disabled by default. Setup my component, it will enable telnet
By mistake, i upgrade the firmware to 1.4.7_0065 and the gatwway won't work with this integration aymore. Hope any solution with this issue in the further.