Failed to flash Yocto on wp7607

I am using wp7607, mangoH red
created yocto image:
make image_bin
then flashed:
cfglegato
fwupdate download build_bin/tmp/deploy/images/swi-mdm9x28/yocto_wp76xx.4k.cwe 192.168.2.2

and I got :

tmp/deploy/images/swi-mdm9x28(master)$ fwupdate download yocto_wp76xx.4k.cwe 192.168.2.2
Connecting to service …
Connecting to service …
Download started …
Download successful

but now system reboots (log from serial console):
error after flash.txt (17.8 KB)

I also tried recover the device using:

swiflash -m wp76xx -r

it prints succesful flash, and reset in a loop

  1. am I flashing correctly?
  2. how can I recover my device?

thank you

How about one click exe in Windows?
how about putting the switch 7 (SW401)to boot mode?
Can these method recover module?

finally managed to recover module, I had a faulty switch on the mangoH, so flashing the default image from Sierra works and provides a working board

but still, I can not flash a Yocto image that will not reset the device.

steps done:

make image_bin
then flashed:
cfglegato
fwupdate download build_bin/tmp/deploy/images/swi-mdm9x28/yocto_wp76xx.4k.cwe 192.168.2.2

am I missing something in the process?

is this a clean build without any change on source code?
normally i will just type “make” command to build the cwe file.
After that i will transfer to module /tmp folder by scp command.
Finally I will type “fwupdate download xx.cwe” on module console.

  1. no I did not changed the code

  2. I tryed in the manner you described and I stil get the fail

did you flashed the file :

yocto_wp76xx.4k.cwe ?

yes, i flash yocto_wp76xx.4k.cwe

additionally, I can not get a constant stable recovery, after one successful recovery, when I try again to recover:
swiflash -m “WP76XX” WP76xx_Release9_GENERIC_SPK.spk

I get:
Detecting USB of the target
No device connected

on the device loading (on UART) I get:

Format: Log Type - Time(microsec) - Message - Optional Info
Log Type: B - Since Boot(Power On Reset), D - Delta, S - Statistic
S - QC_IMAGE_VERSION_STRING=BOOT.BF.3.1.2-00089
S - IMAGE_VARIANT_STRING=LAATANAZA
S - OEM_IMAGE_VERSION_STRING=jenkins
S - Boot Config, 0x000002e1
B - 1216 - PBL, Start
B - 3720 - bootable_media_detect_entry, Start
B - 5040 - bootable_media_detect_success, Start
B - 5044 - elf_loader_entry, Start
B - 8497 - auth_hash_seg_entry, Start
B - 32132 - auth_hash_seg_exit, Start
B - 83519 - elf_segs_hash_verify_entry, Start
B - 130585 - PBL, End
B - 138958 - SBL1, Start
B - 196725 - pm_device_init, Start
B - 216855 - PM_SET_VAL:Skip
D - 18391 - pm_device_init, Delta
B - 218166 - boot_config_data_table_init, Start
D - 0 - boot_config_data_table_init, Delta - (0 Bytes)
B - 226920 - CDT version:3,Platform ID:8,Major ID:1,Minor ID:0,Subtype:129
B - 233813 - sbl1_ddr_set_params, Start
B - 237625 - Pre_DDR_clock_init, Start
D - 244 - Pre_DDR_clock_init, Delta
D - 0 - sbl1_ddr_set_params, Delta
B - 250344 - pm_driver_init, Start
D - 4514 - pm_driver_init, Delta
B - 256627 - cpr_init, Start
D - 122 - cpr_init, Delta
B - 261293 - cpr_cx_mx_apc_vol_update, Start
D - 61 - cpr_cx_mx_apc_vol_update, Delta
B - 276482 - clock_init, Start
D - 152 - clock_init, Delta
B - 276696 - boot_flash_init, Start
D - 39833 - boot_flash_init, Delta
B - 777567 - boot_flash_swi_ddr_init, Start
D - 28609 - boot_flash_swi_ddr_init, Delta
B - 922747 - hw_family:5, hw_type:19, hw_rev:40
B - 923326 - cannot detect SSMEM base
B - 924546 - SSMEM bad, reinit
B - 928755 - SSMEM init OK
B - 951661 - USB non-zero endpoint requirements: 9 in, 5 out
B - 954497 - opening partition 0:SWIFOTA
B - 955412 - error for readpage:0
B - 2960452 - SVC PIN detected
B - 2975641 - Failed to read size: /swinv/item_files/CUST_IM_SWITCH_HIDE
B - 2983906 - Failed to read size: /swinv/item_files/CUST_IM_CONFIG
B - 2990738 - ssmem_get: region 21 not exists
B - 3000864 - ssmem_release: region 20 not exists
B - 3000925 - ssmem_get: region 20 not exists
B - 3007544 - smart recovery counter cleared
B - 3429389 - Sahara over USB

I am using mangoH RED, turn on with switch 7 “on”

I have the udev rule set as instructed

what am I missing ?

Hi @deadpoolcode,

Are you building the image entirely from clean? (i.e. running make clean first, or having never built in that space before?). In release 9, an incremental build failure was identified with a similar result to what you’re describing. The dm-verity hash to validate the rootfs wasn’t being regenerated for each kernel re-build, so the mount of the rootfs is failing. If this description fits, you can try “make clean” before rebuilding (terrible, I know), or you can apply the following patch to meta-swi layer, which will be in the next release:

diff --git a/meta-swi-mdm9x28/recipes-core/initrdsripts/initramfs-mdminit.bbappend b/meta-swi-mdm9x28/recipes-core/initrdsripts/initramfs-mdminit.bbappend
index ff3a64f..0a7daae 100644
--- a/meta-swi-mdm9x28/recipes-core/initrdsripts/initramfs-mdminit.bbappend
+++ b/meta-swi-mdm9x28/recipes-core/initrdsripts/initramfs-mdminit.bbappend
@@ -9,4 +9,6 @@
     install -m 0755 ${WORKDIR}/init.sh ${D}/init
 }
 
+# force do_install task to run for synchronizing roothash
+do_install[nostamp] = "1"
 do_install[depends] += "mdm9x28-image-minimal:do_image_complete"

And then independently, there seems to be an issue with swiflash not consistently detecting the device for some customers (and for me too, for what it’s worth). We’re looking into that internally as well. Rebooting the host PC seems to resolve that issue temporarily.

Ryan

thank you for the valuable assistance

Hi @deadpoolcode,
this issue is solved in the last version of swiflash tool
https://source.sierrawireless.com/resources/airprime/software/swiflash/
best regards,