Alpha-B upgrading to 14.04 results in a brick

Hi All,

My upgrade from Alpha-B has gone horribly wrong, and I now have a bricked WP7104.

Followed the instructions as posted on - got to the point of issuing: AT!APPPARTCHG=768,50,19000,384,80000,300,38000,2560,120440,384 and the module rebooted.

If the BOOT pin is LOW, after reboot I get the android ADB Interface device in Windows. But there are no ‘SiWi’ ports available in the ‘Ports’ tab and the firmware updater executable ‘Checks the modem’, then errors out and closes before I can read the error message.

If I set the BOOT pin HI, after reboot I get the following in the serial console: ÿÿAndroid Bootloader - UART_DM Initialized!!! [10] ERROR: No misc partition found [740] ERROR: Cannot read boot image header [740] ERROR: Could not do normal boot. Reverting to fastboot mode. [780] udc_start()
And fastboot devices reports MDM9615 fastboot but adb devices reports nothing - but adb was apparently not functional on these early WP7 releases (as per another topic on the forum).

[size=150]**** HELP! ****[/size]

I’ve tried accessing the WP7 using a clean install of Win7 (x32) with fresh installs of drivers and still have had no joy.

Is there an intermediate firmware required between the ALPHA-B and R14?
Is there another method of downloading rather than the executable file?
Is there any way to get some diagnostics or error messages out of the firmware executable to try and figure our what’s going on?


Dave :frowning:


I’ve had a bit more of a look through the Alpha-B docs, and can also confirm that using the supplied ‘FDT’ software also fails as follows:[code]C:\Installers\Wavecom\Legato\Alpha-B\firmware>fdt wp-spkgz-060103.cwe
FDT version: 3.0.1306.1
Checking modem mode …

Firmware download failed.
Primary error code: 82 - Failed in checking modem mode.
Secondary error code: 5 - Neither NDIS adapter nor serial port is available.
Total time elapsed: 2043 ms.
Press Enter to continue …[/code]
So I guess that there is a driver problem talking to the WP7.

The Alpha-B getting started docs indicate that there are some pre-built images that can be loaded using fastboot. Are these available? I’ve looked through the tar files I installed, but can’t find any ‘prebuilt’ directories, or any files that look like ‘kernel’ or ‘rootfs’.

Any pointers to these would be gratefully accepted.

ciao, Dave

Hi Dave,

Indeed, you can quite easily flash the kernel and rootfs using fastboot.

fastboot erase kernel fastboot erase rootfs fastboot flash kernel <path_to_kernel> fastboot flash rootfs <path_to_rootfs> fastboot reboot

For the alphaB version, you can find the kernel and rootfs files in Legato-Yocto14-images.tar
You have to unzip it twice (unzip also Legato-Yocto14-images) and you’ll end up with the prebuilt folder which contains the images.

For the beta R14 version, the files system are located under Legato-Dist-PreBuilt-mdm9x15-14.1

I hope flashing the factory images will solve your problem !


What it looks like is that you re-partitioned the flash (I see you allocated extra for the rootfs) which erases any modified partitions. At this point the normal behaviour is what you are seeing - the lk bootloader will pause when it is time to boot linux as there is no kernel to boot. So far, ok.

Option 1 - firmware has already been upgraded:
The next step is as has pointed out - flash the kernel and rootfs using fastboot. The boot pin should be HIGH and you should see the error messages. Once you have done this, reboot and off you go.

Option 2 - you need to upgrade firmware
In this case you should set the boot pin to low and run the firmware updater from Windows. Is this the step that you are saying is failing? This should flash both the new firmware plus the latest Yocto build that went through the factory.

Can you let us know exactly what you did?

Hi All.

I was following the instructions in this document:, and got to the bit about using AT!APPPARTCHG which is where I ended up with the Fastboot prompt.

I stepped on into the ‘Ensure the firmware is updated’ at - which is where I got into grief. The supplied .exe file for the WP7104 would not complete the firmware upgrade - it pops up a little window in the bottom right hand side of the screen - says checking modem - then flashed up an error of some sort and closes the window immediately - so I can’t even tell you what the error is.

I suspect that there is a problem with the drivers or interface to the WP7. I never get the Sierra DM Port device appearing in the resource manager - I only get the Android Device -> Android ADB Interface device.

To top it all off, I tried updating to the new kernel/rootfs using fastboot using Arnaud’s notes - which worked OK … except that now there is a mismatch between the firmware and the linux kernel and the legato is now getting a kernel panic (something to do with a ‘Watchdog bite received from modem firmware’ about 5 sec after the login prompt appears) and the legato immediately reboots.

The error is :swi-mdm9x15 login: SMSM: Modem SMSM state changed to SMSM_RESET. Notify: start reset Probable fatal error on the modem. modem subsystem failure reason: nvread: data buffer size too small:100:nvread: data buffer size too small. subsys-restart: subsystem_restart(): Restart sequence requested for modem, restart_level = 1. Kernel panic - not syncing: subsys-restart: Resetting the SoC - modem crashed. [<c0014a44>] (unwind_backtrace+0x0/0xfc) from [<c061192c>] (dump_stack+0x20/0x24) [<c061192c>] (dump_stack+0x20/0x24) from [<c0611f34>] (panic+0x94/0x1cc) [<c0611f34>] (panic+0x94/0x1cc) from [<c0043990>] (subsystem_restart+0x1e8/0x234) [<c0043990>] (subsystem_restart+0x1e8/0x234) from [<c0043fa4>] (restart_modem+0xb4/0xd0) [<c0043fa4>] (restart_modem+0xb4/0xd0) from [<c00442b4>] (smsm_state_cb+0x38/0x44) [<c00442b4>] (smsm_state_cb+0x38/0x44) from [<c0029c90>] (notify_smsm_cb_clients_worker+0xb8/0x1e8) [<c0029c90>] (notify_smsm_cb_clients_worker+0xb8/0x1e8) from [<c006f9b8>] (process_one_work+0x25c/0x480) [<c006f9b8>] (process_one_work+0x25c/0x480) from [<c006fdfc>] (worker_thread+0x1e4/0x328) [<c006fdfc>] (worker_thread+0x1e4/0x328) from [<c00752bc>] (kthread+0x9c/0xac) [<c00752bc>] (kthread+0x9c/0xac) from [<c000ee30>] (kernel_thread_exit+0x0/0x8) Rebooting in 5 seconds.. Watchdog bite received from modem software! modem subsystem failure reason: (unknown, init string found). subsys-restart: subsystem_restart(): Restart sequence requested for modem, restart_level = 1. Kernel panic - not syncing: subsys-restart: Resetting the SoC - modem crashed. [<c0014a44>] (unwind_backtrace+0x0/0xfc) from [<c061192c>] (dump_stack+0x20/0x24) [<c061192c>] (dump_stack+0x20/0x24) from [<c0611f34>] (panic+0x94/0x1cc) [<c0611f34>] (panic+0x94/0x1cc) from [<c0043990>] (subsystem_restart+0x1e8/0x234) [<c0043990>] (subsystem_restart+0x1e8/0x234) from [<c0043fa4>] (restart_modem+0xb4/0xd0) [<c0043fa4>] (restart_modem+0xb4/0xd0) from [<c0044254>] (modem_wdog_bite_irq+0x38/0x60) [<c0044254>] (modem_wdog_bite_irq+0x38/0x60) from [<c00b0b80>] (handle_irq_event_percpu+0x98/0x2a4) [<c00b0b80>] (handle_irq_event_percpu+0x98/0x2a4) from [<c00b0df0>] (handle_irq_event+0x64/0x84) [<c00b0df0>] (handle_irq_event+0x64/0x84) from [<c00b3928>] (handle_fasteoi_irq+0xbc/0x120) [<c00b3928>] (handle_fasteoi_irq+0xbc/0x120) from [<c00b047c>] (generic_handle_irq+0x30/0x40) [<c00b047c>] (generic_handle_irq+0x30/0x40) from [<c000ed4c>] (handle_IRQ+0x70/0x94) [<c000ed4c>] (handle_IRQ+0x70/0x94) from [<c00084b4>] (gic_handle_irq+0x48/0x60) [<c00084b4>] (gic_handle_irq+0x48/0x60) from [<c061bcc0>] (__irq_svc+0x40/0x70) Exception stack(0xcf20bdf0 to 0xcf20be38) bde0: 0001b44f ffffffff 000006fc 00001388 be00: 00000001 00000064 000000c8 00000021 c09b84a8 0008006a cf1bac00 cf20be64 be20: cf20be38 cf20be38 c0611fcc c0317ad0 20000013 ffffffff [<c061bcc0>] (__irq_svc+0x40/0x70) from [<c0317ad0>] (__delay+0x0/0xc) Rebooting in 5 seconds.. Going down for res
I’m going to set up a macro that fires off the login and attempts to switch to bootloader mode to put the original Alpha-B kernel & filesystem in. More on that soon.

To summarise, I think the issue is that the Legato is not enumerating the correct drivers for the firmware update tool to complete the upgrade process. I’ve tried it on two Win7 machines - one x64 and the other a clean x32 install - and has the same response.

ciao, Dave


A little bit later

OK, I’ve managed to get the Legato out of the reboot loop and back into fastboot mode (Thanks TeraTerm and it’s macro facilities). Reflashed the original Alpha-B kernel and rootfs images using fastboot - and my Legato is running again! :smiley:

However, still no go with the update executable from Windows, nor do I have any ports etc in the Windows device manager. Only way I can talk to the modem inside the legato is via my Linux VM and use minicom to talk to /dev/ttsACM0.

ATI on the modem reports the following:[code]ati

Manufacturer: Sierra Wireless, Incorporated
Model: WP7104
Revision: SWI9X15W_06.01.03.00 r19329 CNSHZ-AR-BUILD 2013/11/25 21:09:19
IMEI: 355604050001080
FSN: JA347400060203
+GCAP: +CGSM,+DS,+ES[/code]Hopefully this will provide some more info for diagnosing the problem.

I really feel that there is something going badly wrong with the Driver install package. Looking in the Delivery Note it indicates that there should be three USB drivers - a COM port, Network and Modem driver. I don’t see any of these in my device manager. Even viewing ‘Hidden’ devices doesn’t show any SiWi devices. The driver package I’m using is identifying itself as shown below:

which is what I’ve downloaded from the Legato site. I’ve even used the BUSDRIVER=0 parameter to remove the drivers before installing new ones.

Any more thoughts?

Hi David,

When you ran the .exe file, was your target BOOT switch set to ‘OFF/LOW’’? Only a ‘Sierra Wirelress DM Port’ should enumerate on Windows which will be used for the firmware upgrade process.

That’s good to hear! :smiley: The ports are probably not enumerating on Windows because it is conflicting with the usb devices from linux (acm, ecm). If you want the ports to enumerate properly on Windows, try the following:

  1. On target, go to /etc/legato/
  2. There should be a file named ‘usbmode’ (contains acm, ecm, audio)
  3. Disable this file by renaming it to something other than ‘usbmode’ (e.g. mv usbmode usbmode.ex)
  4. Reset target and try on Windows again (make sure BOOT switch is set to ‘ON/HIGH’).

Hope this helps,

Hi Enoch,

Ta for the assistance.

Yep. Made no difference. The updater tried ‘checking modem’, then errored out and closed immediately.

Tried this too - also made no difference - still didn’t get any of the SiWi USB devices. Also made no difference when trying the boot loader with the BOOT switch low.

The only device I get to enumerate is a ‘Android ADB Interface’, and the Device manager shows a WP7104 device (with the generic icon).

Are there any switches for the Driver Installer that will force installation, and create a log file of some sort?
Also, is there any way to get some error info/logs out of the software updater?

I’m convinced that there is a problem with the Driver Installer - I have the same issues on both Win7 x32 and Win7 x64.

Will try to find a XP machine and see what happens.

ciao, Dave

Hmm this sounds like something that’s happened to me once. Can you try the following steps as well?

(With boot switch off)

  1. Delete the ‘Android ADB Interface’ (In my notes it says ‘Android Composite Device’ but its been a while…)
  2. Right click yellow band device and select ‘Update Driver Software’.
  3. Then ‘Browser my computer for driver software’
  4. Followed by ‘Let me pick from a list of device drivers on my computer’
  5. Select ‘Universal Serial Bus controllers’
  6. Choose ‘Standard USB Host Controller’ under Manufacturer. And select ‘USB Composite Device’ under Model. Then ‘Yes’.

With the USB Composite device installed now, the DM port should enumerate.

(OR after you delete the ‘Android ADB Interface’)

  1. Switch boot switch on
  2. Restart
  3. This should install ‘USB Composite device’
  4. Then turn off device, and switch to boot off and enumerate the DM port.

Thank you,

Hi Enoch.


Deleting the ADB Device and then re-installing it as a composite device worked like a charm.

Windows got a bit confused during the installation of the drivers (couldn’t install 4 copies of WP7104???), and the NMEA and WWAN drivers had the yellow ! mark - but after a reboot all is well.

Firmware upgrade appears to have gone OK - ati reports:Manufacturer: Sierra Wireless, Incorporated Model: WP7104 Revision: SWI9X15W_06.02.14.00 r21134 CNSHZ-AR-BUILD 2014/03/25 00:04:10 IMEI: 355604050001080 IMEI SV: 0 FSN: JA347400060203 +GCAP: +CGSM,+DS,+ES which looks correct to me.
at!gstatus? reports[code]!GSTATUS:
Current Time: 729 Temperature: 26
Bootup Time: 6 Mode: ONLINE
System mode: WCDMA PS state: Not attached
IMS Reg State: NO SRV
WCDMA band: WCDMA 2100
WCDMA channel: 10737

WCDMA L1 State:L1M_PCH_SLEEP LAC: 927D (37501)
RRC State: DISCONNECTED Cell ID: 0C5590AB (206934187)
RxM RSSI C0: -56 RxD RSSI C0: -106
RxM RSSI C1: -106 RxD RSSI C1: -106
[/code] which also looks sane.

Now to upgrade the linux dev environment.

Thanks for your help.

ciao, Dave