UART recovery of XV2-2

I have a failed XV2-2 unit which does not show any lights at all. I’ve already had it replaced under warranty and was told to dispose of the unit but I’m just trying to see if I can breathe any life into it at all. I’ve hooked up a USB UART adapter to the pins on the main board and I get a response. It dumps the following information to console before freezing. It stops at the same point every time.

I just wanted to see if there was any chance at all it can be reflashed or something like that? Is there perhaps a break sequence to get it to drop out of this boot?

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.XF.0.3-00077-IPQ60xxLZB-2
S - IMAGE_VARIANT_STRING=IPQ6018LA
S - OEM_IMAGE_VERSION_STRING=crm-ubuntu64
S - Boot Interface: SPI
S - Secure Boot: Off
S - Boot Config @ 0x000a602c = 0x000002e1
S - JTAG ID @ 0x000a607c = 0x0013a0e1
S - OEM ID @ 0x000a6080 = 0x00000000
S - OEM Config Row 0 @ 0x000a4188 = 0x0000000000000000
S - OEM Config Row 1 @ 0x000a4190 = 0x0000000000000000
S - Feature Config Row 0 @ 0x000a4130 = 0x0000000008000001
S - Feature Config Row 1 @ 0x000a4138 = 0x02c3e83383000009
S - PBL Patch Ver: 1
S - I-cache: On
S - D-cache: On
B - 3413 - PBL, Start
B - 592 - bootable_media_detect_entry, Start
B - 4339 - bootable_media_detect_success, Start
B - 4435 - elf_loader_entry, Start
B - 4607 - auth_hash_seg_entry, Start
B - 10853 - auth_hash_seg_exit, Start
B - 11349 - elf_segs_hash_verify_entry, Start
B - 383788 - elf_segs_hash_verify_exit, Start
B - 388215 - auth_xbl_sec_hash_seg_entry, Start
B - 388358 - auth_xbl_sec_hash_seg_exit, Start
B - 394902 - xbl_sec_segs_hash_verify_entry, Start
B - 394903 - xbl_sec_segs_hash_verify_exit, Start
B - 395832 - PBL, End
B - 316681 - SBL1, Start
B - 456707 - GCC [RstStat:0x0, RstDbg:0x600000] WDog Stat : 0x4
B - 459147 - clock_init, Start
D - 2745 - clock_init, Delta
B - 467626 - boot_flash_init, Start
D - 7991 - boot_flash_init, Delta
B - 478911 - sbl1_ddr_set_default_params, Start
D - 244 - sbl1_ddr_set_default_params, Delta
B - 485529 - boot_config_data_table_init, Start
D - 1921 - boot_config_data_table_init, Delta - (575 Bytes)
B - 494649 - CDT Version:2,Platform ID:8,Major ID:3,Minor ID:0,Subtype:0
B - 500200 - Image Load, Start
D - 6618 - OEM_MISC Image Loaded, Delta - (0 Bytes)
B - 509533 - Image Load, Start
D - 5063 - PMIC Image Loaded, Delta - (0 Bytes)
B - 517402 - sbl1_ddr_set_params, Start
B - 522373 - CPR configuration: 0x366
B - 525576 - Pre_DDR_clock_init, Start
D - 183 - Pre_DDR_clock_init, Delta
D - 0 - sbl1_ddr_set_params, Delta
B - 562237 - Image Load, Start
D - 457 - APDP Image Loaded, Delta - (0 Bytes)
B - 575321 - Image Load, Start
D - 427 - QTI_MISC Image Loaded, Delta - (0 Bytes)
B - 577731 - Image Load, Start
D - 793 - Auth Metadata
D - 701 - Segments hash check
D - 28792 - QSEE Dev Config Image Loaded, Delta - (36354 Bytes)
B - 608505 - Image Load, Start
D - 6527 - Auth Metadata
D - 10644 - Segments hash check
D - 818895 - QSEE Image Loaded, Delta - (1470632 Bytes)
B - 1427857 - Image Load, Start
D - 763 - Auth Metadata
D - 1007 - Segments hash check
D - 63501 - RPM Image Loaded, Delta - (102664 Bytes)
B - 1493036 - Image Load, Start
D - 30 - Auth

1 Like

Sorry, you’re hosed. The steps for ARM bootup with Cambium APs goes internal to ARM loader, primary boot loader (first partition in NOR), which then loads TZ/QSEE (security module) which then loads RPM (remote power- which we don’t use) and then u-boot (the tertiary boot loader). For units out in customer hands, the uboot loader doesn’t even listen to serial input. But this unit isn’t even getting that far.

What almost certainly occurred is some corruption in NOR. Whether this was due to a power outage during uboot upgrade or some bad software choice, QSEE loaded RPM, started to load u-boot and then choked. My guess is uboot partition is where the corruption is.

To actually fix this would require a hardware mod to the board and an external hardware debugger which can then load a flashless uboot which can then re-erase NOR and you then start over on a mfg image. The hardware mod is tricky and my eyes are too old even with magnifying glasses to do the work- I have to get a tech to add the mod.

I apologize for this mishap. It’s an area we are trying to improve on.We have a number of strategies under discussion but no clear delivery time frame yet.

3 Likes

Hi Matt. Thank you very much for the detailed response and no need to apologise. Although it is a bit of a pain to have a unit fail I can’t fault the support experience at all to have a new unit shipped to my door next day and not have to stuff around with sending the old one back. I’m reasonably handy with electronics but this seems to be destined for the bin so I’ll see to it appropriately. Thank you again!

1 Like