For OpenWrt, not modem itself.
That's exactly what I thought. I'm actually just looking for the modem firmware. My OpenWrt is working perfectly; I just brick the modem...
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
eko.one.pl → Posty przez gadaga
Strony 1
For OpenWrt, not modem itself.
That's exactly what I thought. I'm actually just looking for the modem firmware. My OpenWrt is working perfectly; I just brick the modem...
Yes i have try the github of stich86. The firmware included in links is for B05 version.
For https://dl.eko.one.pl/orig/zte_mf289f/, mdt16 and mtd 17 are for openwrt partitionn not for modem?
Does anyone have a firmware for the modem?
I have this model : CR_VDFDEMF289FV1.0.0B08
stock firmware listed above don't work with my model
Hi all,
I'm following stich86's MF289F recovery guide (Windows) on a bare MF289F module (mini-PCIe to USB adapter, no UART access). I'm stuck at the same place every time and would appreciate any idea.
Setup
- Original firmware before the brick: CR_VDFDEMF289FV1.0.0B08 (note: no "1" after F)
- Package flashed: Vodafone DE - AT2, which is VDF_DE_MF289F1MODV1.0.0B05 (the config inside the sysfs ztedata is the same string)
- Tool: qfenix (flash, efsbackup, efsls/efspush/efspull, efsrestore, readall)
Symptom
1. Flash from EDL works. Module comes up as 19d2:0016 with the 3 TTY. At this point qfenix efsbackup completes and AT commands work.
2. After ANY reboot (QCN restore, AT+CFUN=1,1, qfenix reset, or even just the auto reset after readall) the module comes back as 19d2:0076, a single "ZTE Diagnostics Interface" COM port, no NMEA/AT. QPST and EFS Explorer trigger a reboot when they connect. I have to short the board to get back into EDL.
What I tried (always the same result)
- Dummy QCN, my own QCN, and no QCN at all
- Pushing the "config" file to the EFS root with qfenix efspush before rebooting; verified with efspull + fc /b, identical to ztedata/config from the flashed sysfs. It survives the reboot (found in efs2.bin)
- QPST QCN restore after pushing config (config still present afterwards)
- AT sequence from the guide (ZCDRUN=8, ZCDRUN=F, ZSNT=6,0,0, CFUN=1,1) before the reboot
- Writing back my full original efs2 partition (11,534,336 bytes, dumped with QFIL before the brick)
- Other firmware versions from the MEGA folder: only this one gives me 3 TTY
- Different USB ports, Windows and Linux
Partition comparison (qfenix readall, 28 partitions, fresh-flash state vs bricked state)
- Identical: sbl, tz, abl, uefi, boot, mibib, recovery, recoveryfs, devinfo, misc, fota
- Different: ddr (about 750 bytes differ between EVERY dump, bricked or not, so it looks like normal training data), efs2, and the UBI partitions
- ZTERW contents (extracted with ubi_reader) are identical except logfs/syslog
Syslog (ZTERW logfs, bricked state)
- zte_adapter_cfg requests the file "config" from the modem (q6_file:config) and gets "cfg send to modem failed, qmi_error:0, resp_msg.resp.error:3", retries about 20 times over ~18 s, then "cfg get config file from Q6 failed"
- "read nv usb_speed_mode empty" and "Don't find the USB cmd[0]"
- The Linux side keeps running for at least 2-3 minutes after that. The clock restarts from a fixed value (hw_diff_systime 1700950138) every boot, so the dates in the log are meaningless
- I have not compared with a healthy-boot syslog, so I don't know if error 3 also appears there
The 0076 state
- qfenix lists it as a DIAG/EDL COM port but it refuses Firehose. The first packets from the module look like Sahara HELLO with mode 2 followed by command 9 (memory debug) with address 0x14878B20 and size 0x5B0. My reading, which may be wrong, is that the SoC crashes and offers a RAM dump
- qfenix ramdump stops right after that packet, same on Linux, so I can't get the dump
Questions
1. Are F and F1 firmware interchangeable? My original firmware was named MF289F, the package is MF289F1.
2. Has anyone seen this "works once, crashes on every following boot" behaviour, or seen a module end up in Sahara memory-debug mode?
3. Does the error 3 on config mean anything specific (missing NV item, file location, version check)?
4. Is there a tool that can extract the ramdump in this mode when qfenix stops?
5. Anything else worth checking before I consider the hardware (NAND/RAM) damaged?
I can post full logs, partition dumps hashes or the syslog if useful. Thanks!
Strony 1
eko.one.pl → Posty przez gadaga
Forum oparte o PunBB, wspierane przez Informer Technologies, Inc