Dumping flash from Linux console and uploading it to your PC about lidl-gateway-freedom HOT 13 CLOSED

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

from lidl-gateway-freedom.

Im not familiar with Linux only sheeting little now and then with Lubuntu.
So i hope my dumped flash is OK.

The EFR32 is dumped and no special config in the user data region of the flash and normal serial boot loader is in.

(gdb) mon sw
Target voltage: 2980mV
Available Targets:
No. Att Driver
 1      EFR32MG1B 232 F256 Mighty Gecko M3/M4
(gdb) at 1
Attaching to Remote target

(gdb) mon efm_info
DI version 1 (silabs remix?) base 0x0fe08000

EFR32MG1B 232 F256 = Mighty Gecko 256kiB flash, 32kiB ram
Device says flash page size is 2048 bytes, we're using 2048 bytes

Radio si0

(gdb) info mem
Using memory regions provided by the target.
Num Enb Low Addr   High Addr  Attrs
0   y   0x00000000 0x00040000 flash blocksize 0x800 nocache
1   y   0x0fe00000 0x0fe00800 flash blocksize 0x800 nocache
2   y   0x0fe10000 0x0fe12800 flash blocksize 0x800 nocache
3   y   0x20000000 0x20008000 rw nocache

(gdb) dump memory TZ01.bin 0x00000000 0x00040000
(gdb) dump memory TZ01.bin 0x0fe00000 0x0fe00800
(gdb) dump memory TZ03.bin 0x00004000 0x00040000
(gdb) dump memory TZ04.bin 0x0fe10000 0x0fe12800

TZ01 = Flash
TZ02 = User data
TZ03 = APP
TZ04 = Lockbits

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.
Also finding the force boot loader and EZSP reset pin then i dont knowing where they are and how to trigger them from the tuya GWs linux.

from lidl-gateway-freedom.

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.
Have you finding out wot GIPO is being used for rigging the boot loader mode (if its being connected) and reset of the EFR32 is connected on the RTL chip ?

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.

from lidl-gateway-freedom.

Are the EZSP blobs generic? Where do you find EZSP 6.7.8.0 for that CPU?

from lidl-gateway-freedom.

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.
I like trying if its working then i have time and see if the boot loader is locked or not.

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 FRC_DCLK (looks like its going to the one pin SOC as the reset is also doing) on the module.

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 1 and start sending the GBL file with x-modem.
If its locked its trowing the file after receiving it because failed CRC or signing and if its OK its flashing it and using it on the next boot.

Its also possible rebooting in boot loader mode with command to the EZSP but its need running python on the device.
I have requested "custom command" implantation in ZHA for doing it easy for user but have not getting any response.
Also the hardware is needed if the EZSP is not working OK and cant communicating with ZHA.

Most firmware is using software flow control at 115200 and i think your socat is not working then loading them :-((
Also possible using 2 TCP connection is helping then making it possible looking in the feed back from thee boot loader then doing the file transfer.

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.

from lidl-gateway-freedom.

"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.

from lidl-gateway-freedom.

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.
Bellows CLI have it implanted.

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 ! ! !

from lidl-gateway-freedom.

"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! 👍 :)

from lidl-gateway-freedom.

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:

[SERIAL/DIRECT] CONNECTED TO PORT com8 (115200-8N1)

�┴��¢{~              

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:
Xiaomi and tuya devices is not working with out zhaquirks installed then there is not talking real "zigbeech" ;-)

And thanks one more time for help and feedback !!

from lidl-gateway-freedom.

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.

Sending /tmp/NCP678.gbl, 1431 blocks: Give your local XMODEM receive command now.

Bytes Sent: 183296   BPS:5636

Transfer complete

Can you pleas cooking on socat with software flow control for getting around the problem ?
Then its opening for users updating there ZBGW to the "golden version" of the EZSP.

Thanks in advance

Mattias W

from lidl-gateway-freedom.

I added a "-f" option to disable hardware flow control. Give that a go!

from lidl-gateway-freedom.

Thanks !!!

from lidl-gateway-freedom.

ZHA is up and running with one Australian EZSP 6.7.8.0 firmware:

2021-02-15 08:29:33 INFO (MainThread) [bellows.zigbee.application] EZSP Radio manufacturer: 
2021-02-15 08:29:33 INFO (MainThread) [bellows.zigbee.application] EZSP Radio board name: 
2021-02-15 08:29:33 INFO (MainThread) [bellows.zigbee.application] EmberZNet version: 6.7.8.0 build 373

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 lidl-gateway-freedom.