-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dumping flash from Linux console and uploading it to your PC #1
Comments
How about simply, for example, ssh 192.168.1.86 -l root "cat /dev/mtd0" >mtd0 Or, for complete flash: ssh 192.168.1.86 -l root "cat /dev/mtd[0-4]" > flash |
Im not familiar with Linux only sheeting little now and then with Lubuntu. The EFR32 is dumped and no special config in the user data region of the flash and normal serial boot loader is in.
So possible flashing new EZSP firmware without problems with SWD flasher. If the boot loader is protected i dont knowing must testing on the serial pins. |
The module is running one little older EZSP version and if knowing the pads for the force boot loader mode of the module its very likely possible upgrading the main firmware to the latest EZSP 6.7.8.0. is it possible sending high / low to the GIPOs with commands in the CLI and how ? The boot loader can being protected and needing signed GBL files like Sonoff have doing but not so likely. If not its very easy doing one update of the module then have the possible toggling the extra GIPOs. If its protected with certificate and need signed firmware its only using one SWD probe like BMP on one ESP8266 and doing one flash erase and flashing on new cooked boot loader and EZSP. |
Are the EZSP blobs generic? Where do you find EZSP 6.7.8.0 for that CPU? |
Its normally need being for the same generation of the EFR32 (different CPU different cod base). and the size of the flash. Elelabs-ELU013 and ELR023 looks having thee same pin out but slightly different CPU. If it not working i can doing one request for one 6.7.8.0 firmware from one great firmware cooker (hi have doing my for "IKEA Billy EZSP and all the tasmota is using on there Zigbee Bridge) but i have not getting it verified where the force boot loader pin is that the SOC is using for booting the module in boot loader mode but i think its pin 2 The procedure is grounding (low) the boot loader pin and then putting the reset pin low and high so the module is rebooting in to the boot loader. Then connecting with one serial terminal and pressing one Its also possible rebooting in boot loader mode with command to the EZSP but its need running python on the device. Most firmware is using software flow control at 115200 and i think your socat is not working then loading them :-(( The good thing is that the SWD flashing pins is on J1 that making easy flashing back the dumped firmware if needed. You can looking on my repro if you like knowing more of flashing EFR32 on IKEA modules. |
"Its also possible rebooting in boot loader mode with command to the EZSP but its need running python on the device." We've gone beyond socat already - there's a Gateway compiled for MIPS here: https://paulbanks.org/projects/lidl-zigbee/ha.html with source code. It listens on TCP port 8888 and sets up the serial port properly with hardware flow control. |
The request is made to the ZHA devs for implanting it in ZHA and only need the comport tunnel working and that the EZSP can communicating with ZHA so its no need for changing your socat for making it working if they is implanting it. Im not sure if the tuya EZSP firmware is using hard or software flow control then ZHA is only supporting software flow control but its working with ZHA in real. The socat is working great and is up and running for some days in one docker container with one LIDL LED strip without problems !! By the way great work done ! ! ! |
"Im not sure if the tuya EZSP firmware is using hard or software flow control then ZHA is only supporting software flow control but its working with ZHA in real." I think the TuYa is doing hardware flow control. I suspect that even if ZHA was only doing software flow it wouldn't matter because the TuYa firmware would never issue any flow control characters in hardware mode (XON, XOFF.) and the gateway takes care of the flow control anyway so ZHA doesn't know/care. If we manage to update the firmware and there's some incompatibility we can fix/fudge it in our serial->IP gateway. "By the way great work done ! ! !" Thanks! 👍 :) |
Very true the HW flow control is only between EFR32 and the SOC and from the SOC its one pipe to ZHA and dont knowing wot is going on the other side so transparent sot ZHA. I was shouldering direct pins for RX. TX, Reset and the FRC_DCLK that looks going to the SOC and trying rebooting to bootloader but the FRC_DCLK is not one force bot loader pin in the bootloader so only possible software command looks possible. But the EFR32 is running and sending one frame after restart:
Have installed bellows in virtual environment in windows 10 but it dont like connecting with the GW. Trying connecting with USB-TTL tomorrow and see if i can getting bellows sending "bootloader" and see if i can upload one "normal" EZSP firmware. PS: EZSP 6.7.8.0 is not backwards compatible with the older stacks so tuya GW app can not using it but is shod not being any problem flashing back the original dumped firmware with SWD / J-Tag flasher. And for the HA postings: And thanks one more time for help and feedback !! |
I have flashing my ZBGWs Zigbee module with some tricks and ist now running EZSP 6.7.8.0 but i cant using with ZHA / bellows then i only having one firmware with software flow control that making the hard coded hardware flow control in the socat is blocking the communication with the Zigbee module.
Can you pleas cooking on socat with software flow control for getting around the problem ? Thanks in advance Mattias W |
I added a "-f" option to disable hardware flow control. Give that a go! |
Thanks !!! |
ZHA is up and running with one Australian EZSP 6.7.8.0 firmware:
Need little more testing for see how tuya app is reacting of the "hotted" firmware then reactivating it before can recommending it for "normal" user. |
From /tmp (that being deleted after reboot and not saved in the flash).
dd if=/dev/mtd0 of=/tmp/dmtd0.bin
for mtd0 - mtd4
Install tftpd64.464 and confing your eth network.
tftp -l /tmp/dmtd0.bin -r dmtd0.bin -p 192.168.2.10
For dmtd0.bin - dmtd4.bin
The tftp is one busybox version and have lesser parameters and dont printing command errors so well but looks working OK.
I have 5 bin files that looks good but i have not verifying if they is 100% OK.
Some like trying verifying that is working ???
ZHA is working great but my docker under windows is making strange things so cant testing so much.
Great work done !!
The text was updated successfully, but these errors were encountered: