BT HomeHub stuck in CFG04 mode after installation

I have a problem with a BT HomeHub being stuck in CFG04 mode after installation. I followed the instructions at https://wiki.openwrt.org/toh/bt/homehub_v5a and have successfully soldered a serial connector and gone through the whole installation procedure. But when I reboot, the device stays in CFG04 mode even after a power cycle.

I suspect it has something to do with the soldering; I've done the same procedure on two other HomeHubs where I didn't solder the connector on to the boot_sel2 resistor, but only held a wire to it on first boot. These work fine after installation, but the first one (which I did solder) is stuck.

I've de-soldered the connector, and cleaned up the solder point. It looks fine. And the funny thing is that when I measure the voltage of that connection point relative to ground, it shows +3.3v. So the resistor doesn't appear to be shorted to ground anymore, and yet it still boots in CFG04 mode. I've tried repeating the installation procedure, to no avail.

Does anyone have any ideas as to how I might be able to rescue the device? Or do I just have to write it off as a learning experience and get a new one? :slight_smile:

Have a look at http://openwrt.ebilan.co.uk/viewforum.php?f=7. This topic was discussed already there.

Hi all,

Sorry to resurrect this thread but following through the links I don't think I've seen a relevant answer for me.
Situation is as per title. After performing the sysupgrade I just see the UART CFG04 prompt. Power cycling the router makes no difference. However, hold boot_sel2 to GND and I can boot over serial. Must admit that I haven't tried without holding boot_sel2 to GND.

I spent quite a while futzing with the HH5A before performing the sysupgrade so I am fairly happy the connections are robust.

Anyway, here's the stuff I saw on the serial when sysupgrading. Any clues in this? I ran with the lede-lantiq-xrx200-BTHOMEHUBV5A-squashfs-sysupgrade.bin in /tmp after a sha256 mismatch when the file was on USB. After rewriting and copying to /tmp, the sha256 was good.

And finally, I got my files from here https://downloads.lede-project.org/snapshots/targets/lantiq/xrx200/

`Please select you device:`                                                       
                                                                                
a) BT Home Hub 5 Type A                                                         
b) Plusnet Hub One                                                              
                                                                                
a                                                                               
                                                                                
WRITING custom uboot-env to unlock u-boot console and update bootcmd...         
Erasing 128 Kibyte @ 0 -- 100 % complete                                        
Writing data to block 0 at offset 0x0                                           
                                                                                
REMOVING ubi volume OpenRG...                                                   
ubirmvol: error!: cannot find UBI volume "OpenRG"                               
          error 2 (No such file or directory)                                   
                                                                                
REMOVING ubi volume FFS...                                                      
ubirmvol: error!: cannot find UBI volume "FFS"                                  
          error 2 (No such file or directory)                                   
                                                                                
                                                                                
Preparation completed!

root@lede:/# sysupgrade /tmp/lede-lantiq-xrx200-BTHOMEHUBV5A-squashfs-sysupgrade
.bin 
Cannot save config while running from ramdisk.
killall: watchdog: no process killed
Watchdog handover: fd=3
- watchdog -
killall: telnetd: no process killed
Sending TERM to remaining processes ... ubusd logd netifd odhcpd mountd ntpd dnsm 
Sending KILL to remaining processes ... 
removing ubiblock0_1
[ 1444.398030] block ubiblock0_1: released
Volume ID 0, size 14 LEBs (1806336 bytes, 1.7 MiB), LEB size 129024 bytes (126.0 1
Volume ID 1, size 26 LEBs (3354624 bytes, 3.2 MiB), LEB size 129024 bytes (126.0 1
Set volume size to 122185728
Volume ID 2, size 947 LEBs (122185728 bytes, 116.5 MiB), LEB size 129024 bytes (11
sysupgrade successful
umount: can't unmount /dev: Resource busy
umount: can't unmount /tmp: Resource busy

[ 1470.800218] reboot: Restarting sy�
ROM VER: 1.1.4
CFG 04
UART
�
 ROM VER: 1.1.4
CFG 04
UART

As mentioned by mkresin, this issue has been raised several times on the ebilan forum in the past. Sadly, the cause and a solution has not yet been found.

eg.
http://openwrt.ebilan.co.uk/viewtopic.php?f=7&t=131&p=1055&hilit=CFG+04#p1055

@tohojo , it is interesting to learn that you only had an issue when you chose to solder to the resistor (or solder pad) for boot_sel2 for one of your three hubs. It does seem to suggest heat from soldering could be a factor if it had caused some damage.

@scrumpydude, for curiosity, have you tried restoring stock BT firmware from your nanddump file - it will take about an hour to complete?

Restore to BT firmware currently in progress. Will have to continue it in the morning. Will report back soon.

Interesting, when I powered it on this evening (not holding boot_sel2 to GND) and saw the CFG04 prompt I tried cat-ting the serial boot to it. No dice. So despite what looks like the serial boot prompt I don't believe it was in that mode. Power cycled with boot_sel2 to GND, same prompt but cat-ting serial boot worked like a charm.

Aaaaaand it appears to be bricked. Still get the CFG04 prompt. I guess there is nowhere back from here.

The restore seemed to go without a hitch. Serial console output below:

root@lede:/# restore /tmp/mounts/USB-A1/lede-hh5a.nanddump 

This script will erase the Nand flash memory, and then attempt to restore the
stock firmware to this Hub.


WARNING: You may wish to make a backup of the current running firmware
         and save it to your COMPUTER or other storage device before
         continuing.

IMPORTANT: You MUST use the original hh5a.nanddump backup file originally
           created from this Hub. Do not use a backup file from any other Hub
           to avoid issues like bad WiFi perfomance because of not matching
           WiFi calibration data.


DO NOT POWER OFF THE DEVICE DURING THIS RESTORE PROCESS!

Up to 1 hour is required to complete this process.

Please enter YESRESTORE to continue:
YESRESTORE

COPYING data to virtual nand chip
Writing data to block 0 at offset 0x0
Writing data to block 1 at offset 0x20000
Writing data to block 2 at offset 0x40000
etc
Writing data to block 1010 at offset 0x7e40000
Writing data to block 1011 at offset 0x7e60000

ATTACHING backup ubi partition to ubi dev number 9
UBI device number 9, total 1016 LEBs (131088384 bytes, 125.0 MiB), available 3 LE)

DETACHING nand ubi partition...

RESTORING u-boot partition from backup
Erasing 128 Kibyte @ 80000 -- 100 % complete 
Writing data to block 0 at offset 0x0
Writing data to block 1 at offset 0x20000
Writing data to block 2 at offset 0x40000
Writing data to block 3 at offset 0x60000
Writing data to block 4 at offset 0x80000

RESTORING u-boot env partition from backup
Erasing 128 Kibyte @ 0 -- 100 % complete 
Writing data to block 0 at offset 0x0

Do you wish to unlock the u-boot prompt? This will allow use of tftpboot etc.

Unlock [y/N]?
y

UNLOCKING u-boot prompt
Erasing 128 Kibyte @ 0 -- 100 % complete 

RESTORING unused partition from backup
Erasing 128 Kibyte @ 20000 -- 100 % complete 
Writing data to block 0 at offset 0x0
Writing data to block 1 at offset 0x20000

FORMATING nand ubi partition
ubiformat: mtd3 (nand), size 132644864 bytes (126.5 MiB), 1012 eraseblocks of 131s
libscan: scanning eraseblock 1011 -- 100 % complete  
ubiformat: 1012 eraseblocks have valid erase counter, mean value is 358
ubiformat: formatting eraseblock 1011 -- 100 % complete  

ATTACHING nand ubi partition to ubi dev number 0 using
19 reserved blocks for bad block handling
UBI device number 0, total 1012 LEBs (130572288 bytes, 124.5 MiB), available 989 )

RESTORING OpenRG ubi volume from backup
Volume ID 1, size 326 LEBs (42061824 bytes, 40.1 MiB), LEB size 129024 bytes (1261
20538+0 records in                                       
20538+0 records out                                      
                                                         
RESTORING FFS ubi volume from backup                     
Volume ID 2, size 662 LEBs (85413888 bytes, 81.5 MiB), LEB size 129024 bytes (1261
41706+0 records in
41706+0 records out

RESTORING caldata ubi volume from backup
Volume ID 3, size 1 LEBs (129024 bytes, 126.0 KiB), LEB size 129024 bytes (126.0 1
63+0 records in
63+0 records out


Restoration completed!


To prepare the system for installing LEDE. You may run:

  prepare


Otherwise, type 'reboot'!
If the UART prompt appears, power-cycle your device!
The hub should now boot up using the stock firmware.
root@lede:/# reboot
root@lede:/# 
ROM VER: 1.1.4
CFG 04
UART

The transcript of your restore seems to look OK, including the CFG 04 prompt at the end.

I presume you power cycled the HH5a, and it made no difference.

Repeatedly and desperately. :slight_smile:

So I've played with this thing a little more. Tried putting BT stock firmware back this time not overwriting U-Boot. Still broken.

Slightly unsure if what said above about the unit not being in serial boot when powered on without holding boot_sel2 low is (or was) true. The device currently will happily serial boot without holding boot_sel2 low at power on.

I've checked the continuity and there is no short to ground. The boot_sel2 wire is at 3.3 volts when the unit is on.

Any suggestions? I'd happily try someone else's stock image. I've nothing to lose and I may have the caldata backed up after a (post borking) play with the openwrt install image running /hh5a-uboot-install.sh

I guess serial boot is the lantiq's default 'safe mode' should it not find a boot image in NAND (if that's where it lives/right terminology - getting beyond my knowledge now). If so, how can I get a bootable image down (presumably a U-Boot).

Just to provide closure here and advise anyone who stumbles upon this thread via Google. The cause of my problems appear to have been the use of a USB to RS232 serial converter. Pretty obvious with hindsight. The thing you want is a USB to TTL serial converter. The RS232 levels somehow broke the UART interface on the HH5A. You can still talk serial to it, just can't ever leave serial boot.

That wouldn't really be a surprise (and should be widely documented), RS232 can go up to +/- 15 V (most of the time at least 5 V in practice), while most (pretty much all) embedded devices need the TTL level serial console at up to 3.3 V. If you connect such a board to non-TTL RS232 interface, you fry the electronics within seconds.

I just had the issue despite using an adaptor labelled as USB to TTL, which flashed one hh5a just fine, before this one got stuck in CFG 04. The only difference that I saw during the installation was a reported bad block during nanddump backing up.

Did you actually resolve the issue by changing the adapter, or is yours permanently stuck?

Hi,

For the bricked units I never managed to get them to work properly again. I've given up and binned them. I've flashed 2 with a USB to TTL converter and they both worked fine. The bricked units were with a standard USB to RS232 converter.

Sorry to be the bearer of bad news.

I have another unit to hack at some point. Fingers crossed.

I've managed to recover a hh5a that was stuck in UART mode.

I realised my unit had no resistor on R45 as shown on the unit in the wiki

IMG_20180215_12164

To regain access I simply shorted this and now it boots.

Can anyone else check this on their unit? I'm wondering if these resistors are accidentally being pulled off when covering the board in tape or simply when touching it. I noticed two more at R41 and beside R369 are also missing, but they have no effect on normal operation.

This seems a plausible cause for this problem as the area is near the cpu which runs quite hot, which may cause flexing on the PCB and weaken the joint over time.

For reference my board is REV:4.10. The router is second hand so unsure of its age.

I had the same CFG-04 boot prompt issue, the solution for me was to de-solder the jumper wire from "R45" (boot_sel2) pad. After which the router booted as normal into OpenWRT/LEDE. I am using a USB to RS232 serial converter, therefore I am not convinced this is causing any UART over voltage conditions. It's probably my bad solder work more than anything.