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 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 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

`Please select you device:`                                                       
a) BT Home Hub 5 Type A                                                         
b) Plusnet Hub One                                                              
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
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
 ROM VER: 1.1.4
CFG 04

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.


@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

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.


Up to 1 hour is required to complete this process.

Please enter YESRESTORE to continue:

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
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]?

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:


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
ROM VER: 1.1.4
CFG 04

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 /

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?


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


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.

Now it's my BTHH5A stuck at uart prompt. The putty window is not responding to the keyboard. The router doesn't boot normally at all. Whether I ground the boot_sel or not, the router is always stuck at uart prompt.

ROM VER: 1.1.4
CFG 04

What can I do from here? Are there any chances of recovery?



Bin it

It's extremely unlikely.

Hi @krazeh ,

Actually it did show CFG06 ( instead of CFG04 ) in the begining. But I kept the uart connection running for about half an hour. This seems too long. After that the router is stuck at CFG04.

Don't know where did it all go wrong. Thanks for your advice though.


These vias are very fragile, soldering to them (applying too much heat for too long) can short PCB layers that mustn't be connected, fixing that is basically impossible (at least not in an economically viable way).

@bill888 has a good guide for the BT Hub5 but if you have it stuck at CFG04 then its likely you bricked the rom by holding bootsel down for too long. its mentioned in his guide and on the wiki.

  1. IMPORTANT: Remove the connection between boot_sel2 and GND as QUICKLY as possible. There have reported cases where HH5a remains stuck in 'CFG 04' which may have been caused by electronic component damage.

Ive got a pair of hub5s that are running version 19 if you want a spare and are in the uk? (ironically it seems to be the day for hub5's as someone else had theirs die too.)