BT HomeHub 5 type A - retrofit SPI boot device?

Hi,

I just acquired a BT HomeHub 5. These are available for very low cost here in UK at the moment as they are EOL. I want to reflash with OpenWRT but the instructions referenced on the hardware page look painful, with several pitfalls with potential to brick the device. I believe the situation would be better if we weren't working with raw NAND flash.

I popped the lid and noticed there is what looks like it could be an unpopulated land for a SPI NOR flash. I just wondered where I could find some info on the boot strap in options and what the first stage loader might expect to find on a SPI flash.

I see there are a few other supported Lantiq VRX268 devices which have NOR flash, e.g. TD-W9980 and TD-W8980, the photo of the latter clearly shows a SPI NOR device. Also, this picture of Netgear VEVG2500 annotates one of the strap-in pins as "CFG02", so I guess someone here has access to the documentation for these SoCs.

Can anyone help me out with some info on Lantiq VRX200/268, please? All the original links I have found so far redirect to a 404 since Intel acquired the IP.

Thanks in advance!

1 Like

binwalk and or strings should tell you quite a bit... as would any docs / guides on uboot compilation for similar boards...

are you talking about the pads to the lower right of the bottom circle?

I agree re the bootloader image though I wonder whether there is already a script or tool to assemble it, assuming you don't simply write a raw binary to offset 0 or something like that.

Yes, it's the footprint peeping in at the bottom of that image. I count four traces heading back towards the SoC and was hoping for SPI. Could be just wishful thinking. :slight_smile:

Don't you think doing the normal steps to install OpenWrt on NAND (there are solderless methods) are still easier than trying to retrofit SPI-NOR to the BT Home Hub 5 Type A? You not only have to reverse engineer the PCB and also check that all traces and supporting resistors/ capacitors are present, but would also need to provide custom bootloaders and OpenWrt images (while still needing to decrypt the NAND, in order to get access to the calibration data), while having to solder 14 pins instead of (if at all) 4 test points.

Obviously there may be reasons to have a look at this anyways, but I don't think selling it as "less painful" would be correct.

Disclaimer: I have installed OpenWrt on a BT Business Hub 5 Type A with a variation of https://openwrt.ebilan.co.uk/viewtopic.php?f=14&t=965 - takes slightly less than an hour, yes it's not very convenient, but doable.

1 Like

No, you are right of course. To be honest, it was the thought of the combination of potential bad blocks and encrypted data that put me right off attempting to reuse the NAND flash. I do board bring up for my day job and always prefer either NOR or some sort of managed NAND flash.

(I know UBI is meant to be superior to the typical proprietary FTL present in e.MMC cards or SSDs, but when it comes to field updates, I am well aware of the many ways a software solution can go wrong.)

The typical OperWRT NOR layout and update mechanism seems to work very well too, so I like the idea of converting one of these boards to NOR. I was thinking of pre-programming a chip with a U-Boot (or Barebox) image before soldering it down, then taking things from there.

Newer devices (which the BTHub5 is not, quite) tend go with NAND (or ideally eMMC) instead of SPI-NOR, probably mostly for its size to price ratio. On newer devices we tend to see both a rise in dual-boot setups (improving field reliablity, by providing a fallback) and including services that are more flash hungry (samba4, dlna support, etc.). Even without dual-boot, this is getting tight with 16 MB flash (or already with 32 MB in a dual-boot setup). The largest SPI-NOR chips you'll see on actual devices top out at 32 MB, so it's clear that something larger will be needed in the future (not necessarily for OpenWrt, but for vendors and their OEM firmware at least). Right now only raw NAND and eMMC seem to fill that role, so we somehow need to deal with it (easy in case of eMMC, less reliable but at least standardized (ubi), in case of raw NAND).

1 Like

I just had a quick poke at the board and discovered R49, on the top side adjacent to SW4 is apparently boot_sel1. (R46 is boot_sel 3.) I believe shorting this to 3V3 while grounding boot_sel2 will result in a SPI boot.

Wouldn't changing the flash also mean you'd have to recompile the build for every sysupgrade?

1 Like

Yes, custom bootloader, custom partitioning, custom kernel (DTS), custom ART/ MAC/ calibration extraction - a completely custom one-of-a-kind target device; possible, but not really sensible.