The SDK and some applications are precompiled for different architectures. One of them is MIPS and MIPSEL, which is common on cheap routers that support OpenWrt, you can use those.
my routers hardware is MIPSEL architecture , can i use that downloading and update binary files directly
All of the pre compiled SDK’s are for running with Linux on different architectures, the same would be for an ARM, if you had Open WRT running on an ARM processor it is at heart Open WRT still. That’s not to say you can’t try.
Regards
Matt
no my device processor is mipsel not arm processor.
Yes, I get that, I used ARM as an example. Let me re phrase.
If you have Linux running on a MIPS processor yes you would be able to do it with the pre compiled SDK but you have Open WRT running on a MIPS processor and the SDK is build/written to run on Linux.
Regards
Matt
OpenWrt is Linux. (or better a Linux distribution)
That should work. But note that you will have to use the GobiNet and GobiSerial drivers as well to be able to use the SDK.
NOTE: The rest of this is for users with bigger balls than brains, and with the ability to read, understand and modify C and perl code. It does not Just Work. And it will probably “brick” your modem at least once before you get it to work for you. You are now warned.
Another alternative, if you have the capability to do a bit of development, is to take this proof of concept update tool and fix it up as necessary:
mork.no/~bjorn/swi-update.c
It does work as-is for me on MC7455, and I have also tried it with success on an EM7305. But as you can see it is still in very much in a state of debugging, guessing and developing. The tool will only upload a single file to a modem already in QDL mode. You still need some other way to switch the modem into update mode, waiting for an image upload, and repeat that for updating PRI etc. I’ve so far used my ugly-as-hell perl QMI development script to do this ( git.mork.no/wwan.git/plain/scripts/qmi.pl ), as I haven’t had the time to integrate the IMPREF command into libqmi.
My usage has been something along the lines of
- unzip SWI9X30C_02.08.02.00_Generic_002.007_000.zip
Archive: /tmp/SWI9X30C_02.08.02.00_Generic_002.007_000.zip
inflating: SWI9X30C_02.08.02.00.cwe
inflating: SWI9X30C_02.08.02.00_Generic_002.007_000.nvu
-
set image preference (for slot 1):
./qmi.pl --device=wwan2 impref 02.08.02.00 002.007_000 GENERIC 1 -
start upload
./qmi.pl --device=wwan2 --system=dms 0x003e -
./swi-update --image SWI9X30C_02.08.02.00.cwe --serial /dev/ttyUSB3
-
upload NVU
./qmi.pl --device=wwan2 --system=dms 0x003e -
./swi-update --image SWI9X30C_02.08.02.00_Generic_002.007_000.nvu --serial /dev/ttyUSB3
I won’t make any claim regarding the correctness of this procedure, as I don’t know. It’s guesswork. And I won’t provide any further support, as the reason this hasn’t been finished and made available as a ready-to-use tool is simply the lack of time to do that.
I humbly ask that anyone who actually tries this and does any development on it obey the copyright and license. And I would really appreciate it if someone completed the work and made this available to the public, e.g. as part of the libqmi source or as a separate project.