Yeah I never did get this resolved. Ended up buying a different modem and tossed this one in a box. I think I read elsewhere it could be related to it being an “engineering sample” or something. Still following along in case someone finds a solution so I can at least have it as a backup.
@mlw @dl5162 @anon56110884 @alex.ciarlillo This is a follow up to this thread for anyone who visits here. What I’ve found is that it’s possible to muck with a modem enough to where you can’t successfully upload new firmware and have it pair with the matching uploaded PRI file.
If you revert the firmware to the original firmware on the modem, then the built-in GENERIC PRI file will pair with the firmware and the modem will power up online.
I have since automated our company’s modem provisioning process, and have successfully upgraded the firmware on 8 MC7455 modems so far. We have many more to go.
I think automating this process is key to reducing the possibility of bricking another modem.
Thanks to everyone for your support and patience.
Am I understand yhis correctly? All the examples of failing modems have been upgraded and downgraded a large number of times?
I have been wondering about something I’ve seen in a few select firmware versions only: They include something looking like an additional persistent(?) delete scripts Maybe it makes a difference if one of these versions have ever been installed? If it cleans up a file system which would otherwise fill up with each upgrade, for example. But I have no idea how you would verify that rather thin theory…
FWIW, I have a couple of really old MC7455s (HWID 0.2) which have been through a large number of firmware upgrades, including quite a few using failing tools. They were used to develop the hackish code Aleksander later turned into the nicely polished qmi-firmware-update. This was mostly based on analyzing captures from official tools. I guess it goes without saying that there were some failures on the way. But nothing ever caused any permanent problem. To me, the MC7455 boot loader and update process have always appeared rock solid and fool proof.
If you want to experiment with the delete script theory, then it’s easy to identify candidate versions by comparing the size of the NVU files for the same vendor. It’s very obvious for the 02.08.02.00 firmware, which have a version both with (001) and without (000) the script:
$ ls -l SWI9X30C_02.08.02.00_G*.nvu
-rw-r--r-- 1 bjorn bjorn 3044 Jan 19 2016 SWI9X30C_02.08.02.00_GENERIC_002.007_000.nvu
-rw-r--r-- 1 bjorn bjorn 5422 Jul 7 2016 SWI9X30C_02.08.02.00_Generic_002.007_001.nvu
Or you can look for the script filename:
$ grep -l NVUP_PERSIST_UPDATE.002 *.nvu
SWI9X30C_02.08.02.00_ATT_002.009_001.nvu
SWI9X30C_02.08.02.00_Bell_000.001_001.nvu
SWI9X30C_02.08.02.00_Generic_002.007_001.nvu
SWI9X30C_02.08.02.00_Rogers_000.001_001.nvu
SWI9X30C_02.08.02.00_ROGERS_000.001_002.nvu
SWI9X30C_02.08.02.00_Telus_000.001_001.nvu
SWI9X30C_02.08.02.00_TELUS_000.001_002.nvu
SWI9X30C_02.08.02.00_Verizon_002.012_002.nvu
SWI9X30C_02.13.01.00_Sprint_002.007_000.nvu
SWI9X30C_02.14.03.00_Bell_000.005_000.nvu
SWI9X30C_02.14.03.00_DoCoMo_000.010_000.nvu
SWI9X30C_02.14.03.00_Generic_002.012_000.nvu
SWI9X30C_02.14.03.00_Rogers_000.005_000.nvu
SWI9X30C_02.14.03.00_Sprint_002.008_000.nvu
SWI9X30C_02.14.03.00_Swisscom_002.011_000.nvu
SWI9X30C_02.14.03.00_Telefonica_002.011_000.nvu
SWI9X30C_02.14.03.00_Telstra_002.013_000.nvu
SWI9X30C_02.14.03.00_Telus_000.005_000.nvu
SWI9X30C_02.14.03.00_Vodafone_000.008_000.nvu
SWI9X30C_02.18.02.00_ATT_002.017_000.nvu
SWI9X30C_02.18.02.00_BELL_000.008_000.nvu
SWI9X30C_02.18.02.00_DOCOMO_000.013_000.nvu
SWI9X30C_02.18.02.00_GENERIC_002.015_000.nvu
SWI9X30C_02.18.02.00_ORANGE-EU_002.014_000.nvu
SWI9X30C_02.18.02.00_ROGERS_000.009_000.nvu
SWI9X30C_02.18.02.00_SPRINT_002.015_000.nvu
SWI9X30C_02.18.02.00_SWISSCOM_002.014_000.nvu
SWI9X30C_02.18.02.00_TELEFONICA_002.014_000.nvu
SWI9X30C_02.18.02.00_TELSTRA_002.016_000.nvu
SWI9X30C_02.18.02.00_TELUS_000.009_000.nvu
SWI9X30C_02.18.02.00_VERIZON_002.022_000.nvu
SWI9X30C_02.18.02.00_VODAFONE_000.011_000.nvu
If my understanding og this is correct (that’s a big IF), then the script will delete these files and directories on every upgrade:
/swir/anthsms/
/nv/item_files/mcs/tcxomgr/
/sfs_siwi/
/nv/item_files/modem/uim/uimdrv/nv_active_slot_configuration
/nv/item_files/modem/lte/ML1/tx_power_backoff
/nv/item_files/therm_monitor/config.ini
/nv/item_files/modem/lte/common/lte_fc_macul_target_rates
/siwi/
/swinv/item_files/AVMS_WDSI
/swinv/item_files/AVMS_DM_SESSION_TIME
/swinv/item_files/AVMS_RETRY_TEMPO
/swinv/item_files/AVMS_CONFIG
/swinv/item_files/AVMS_LAST_USER_AGREEMENT
/swinv/item_files/SWI_LWM2M_TRAFFIC_SMS
/swinv/item_files/SWI_LWM2M_TRAFFIC_DATA
/swinv/item_files/IDS_FUMO_RESET_COUNTER
/swinv/item_files/ANTITHEFT_PASSWORD
/swinv/item_files/ANTITHEFT_MODE
/swinv/item_files/ANTITHEFT_PHNUMS
/swinv/item_files/ANTITHEFT_AUTOPIN1
/swinv/item_files/ATHIGHPWD
/swinv/item_files/DG_SMS_DESTINATION
/swinv/item_files/DG_SMS_CONTENT
/swinv/item_files/ANTITHEFT_SMS_IDX
/nvm/num/550
/nvm/num/1943
/swinv/item_files/USER_MODEMDISABLE
/swinv/item_files/DG_STATUS
/swinv/item_files/LED_ENABLE
Red herring, or important workaround for some observed issue?
@dl5162 interesting observations, and thanks for responding. I wouldn’t even know how to peer inside the modem to observe its internal file system. It takes great skill, but we have managed to brick two of these modems so far. Would be happy to send one to you – I’m not planning on trying to return them or anything.
Thank you for all the great work you do on the linux kernel. -Perry
Hello everyone. We have also just ran into the same issue. We were wondering if anyone managed to find a solution for their Rev.A modules. Thanks in advance!
I had a similar issue so I thought I’d share my workaround…
I have a hundred MC7455s (all Rev C) that I’m upgrading to the latest Generic F/W. My installation script does an RMARESET=1 followed by an IMAGE=0 before loading 9999999_9904609_SWI9X30C_02.33.03.00_00_GENERIC_002.072_000.exe
I have one that just did not want to load the new firmware, and gets stuck in LOW POWER MODE. I have another card with an IMEI only a couple digits higher and it works fine. After running RMARESET=1 and IMAGE=0 I get this on the behaving card:
AT!IMAGE?
TYPE SLOT STATUS LRU FAILURES UNIQUE_ID BUILD_ID
FW 1 EMPTY 0 0 0
FW 2 EMPTY 0 0 0
FW 3 EMPTY 0 0 0
FW 4 EMPTY 0 0 0
Max FW images: 4
Active FW image is at slot 255
AT!IMPREF?
!IMPREF:
preferred fw version: 02.08.02.00
preferred carrier name: GENERIC
preferred config name: GENERIC_002.007_001
current fw version: 02.08.02.00
current carrier name: GENERIC
current config name: GENERIC_002.007_001
Whereas the faulty card gives me this after RMARESET=1 and IMAGE=0:
AT!IMAGE?
TYPE SLOT STATUS LRU FAILURES UNIQUE_ID BUILD_ID
FW 1 EMPTY 0 0 0
FW 2 EMPTY 0 0 0
FW 3 EMPTY 0 0 0
FW 4 EMPTY 0 0 0
Max FW images: 4
Active FW image is at slot 255
AT!IMPREF?
!IMPREF:
preferred fw version: 02.08.02.00
preferred carrier name: GENERIC
preferred config name: GENERIC_002.007_001
current fw version: 02.24.05.06
current carrier name: GENERIC
current config name: GENERIC_002.007_001
fw version mismatch
So it would appear that the SLOT 255 firmware was somehow overwritten. A bunch of experimenting has found that if you run FDT2.exe without any flags, it will flash the lowest CWE found in that folder to SLOT 255. Since my faulty card wants 02.08.02.00 I downloaded it from here:
PS C:\Users\Rick\Desktop\FDT> .\fdt2
FDT version: 1.0.1702.1
Awaiting suitable port or adapter ...
Switching to boot & hold mode ...
Disabling selective suspend ...
Awaiting port removal ...
Awaiting download port ...
Downloading images ...
Writing image -
Flashing image \
Enabling selective suspend ...
Awaiting adapter ...
Checking update status ...
Enabling selective suspend ...
Firmware image download succeeded.
Final Firmware update succeeded.
Preexisting images information:
Current:
Firmware:
ImageId: 002.007_001
BuildId: 02.24.05.06_GENERIC
Configuration:
ImageId: 002.007_001
BuildId: 02.24.05.06_GENERIC
Final images information:
Current:
Firmware:
ImageId: 002.007_001
BuildId: 02.08.02.00_GENERIC
Configuration:
ImageId: 002.007_001
BuildId: 02.08.02.00_GENERIC
OEM PRI: 9904514 001.006 Generic-M2M
IMEI: ###
Total time elapsed: 93844 ms.
Time to switch to boot mode: 7844 ms.
Images downloaded:
Image ID: ?_?
Build ID: 02.08.02.00_?
write time: 4906 ms
additional flash time: 50063 ms
Time to reset to application mode: 23922 ms.
Which gives us:
AT!IMAGE?
TYPE SLOT STATUS LRU FAILURES UNIQUE_ID BUILD_ID
FW 1 EMPTY 0 0 0
FW 2 EMPTY 0 0 0
FW 3 EMPTY 0 0 0
FW 4 EMPTY 0 0 0
Max FW images: 4
Active FW image is at slot 255
!IMPREF:
preferred fw version: 02.08.02.00
preferred carrier name: GENERIC
preferred config name: GENERIC_002.007_001
current fw version: 02.08.02.00
current carrier name: GENERIC
current config name: GENERIC_002.007_001
And now I can run the latest firmware update as usual with no dramas. End result is this:
AT!IMAGE?
TYPE SLOT STATUS LRU FAILURES UNIQUE_ID BUILD_ID
FW 1 GOOD 1 0 0 ?_? 02.33.03.00_?
FW 2 EMPTY 0 0 0
FW 3 EMPTY 0 0 0
FW 4 EMPTY 0 0 0
Max FW images: 4
Active FW image is at slot 1
TYPE SLOT STATUS LRU FAILURES UNIQUE_ID BUILD_ID
PRI FF GOOD 0 0 0 002.072_000 02.33.03.00_GENERIC
Max PRI images: 50
AT!IMPREF?
!IMPREF:
preferred fw version: 02.33.03.00
preferred carrier name: GENERIC
preferred config name: GENERIC_002.072_000
preferred subpri index: 000
current fw version: 02.33.03.00
current carrier name: GENERIC
current config name: GENERIC_002.072_000
current subpri index: 000