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 @ajoseph @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