Black boxes given away with a bt broadband subscription. It comes in two versions Type A and Type B. The two versions look identical, and although they provide similar functionality, they are quite different on the inside.

Type A is made by Thomson, and is broadcom based, using Thomson linux based firmware. Type B is made by SHC (Siemens), and is Infineon/Lantiq Danube based, using OpenRG based linux firmware. Bootloader is u-boot.

The homehub V2 includes ADSL2+, 802.11b/g/n wireless, host USB port, 4 wired ethernet ports, DECT, FXS & FXO ports and VOIP functionality.

The firmware of both units can be successfully hacked for use on other ISPs (see www.psidoc.com). The Type A firmware is a litlte more flexible than the Type B firmware in terms of what can be done after gaining access.

Until the patches come through to trunk, source mods for building OpenWRT for Type B are here: https://sourceforge.net/p/hh2b4ever/code/ci/7c17843ab0596dccb2bd972ed9df6c4ccd9995a8/tree/

latest info: binary at sourceforge for annexa works, although the leds are squiffy and the ADSL reports a fault but works. see http://www.psidoc.com/showthread.php/495-OpenWRT-on-HHV2B for details

News 25/3/2012: Thanks to blogic, some patches went into trunk today…. Building from trunk

→generic.flashing

Bootlog of the OEM firmware

NOR: PHYS_FLASH_1 0xB0000000 16 bit in EBU region 0 NAND: PHYS_FLASH_2 0xB4000000 Sector size 256 nand max floors 1 nand max chips 1 in EBU region 1

In the photos above, wires are soldered on to the 3.3v serial lines.

The connections are:

Note that the original u-boot has 'silent' mode enabled

The CPU has 2 x 16 possible GPIO
The board provides a further 24? GPOs (for leds) controlled by stp
for each pin there are control bits dir = direction out = value? altsel0/altsel1 od - 0=open drain, 1='normal mode' puch pull pudsel = pullup/down select 1=up puden = pull up/down enable

uboot initial values

USB Power? 13

from original bootlog: FXO reset using GPIO-10 FXO interrupt using GPIO-1 FXO Chip Select using GPIO-9

from u-boot, initial values are:

All buttons are active low.

Near the 11 leds, there are two HC595: 8-Bit Serial-Input/Serial or Parallel-Output Shift Register with Latched 3-State Outputs (http://pdf1.alldatasheet.com/datasheet-pdf/view/46165/SLS/HC595.html)

LED control base address is 0xBE100BB0 which correlates with ltq_register_gpio_stp.

Atheros 9160-BC1A 802.11b/g/n, pci, 0x18000000, irq 22, slot 14
Marked as device 168C:FF1C

The calibration data is stored in the first 0x4000 bytes of the nand
the first 0x60 of these contain PCI register fixups, organised as Reg16:Value32. These need to be written to the PCI register space BEFORE the PCI device is probed… This leads to the issue that the PCI device is probed before the nand is active, so before we can get to the data, so a scheme of hardcoding these register fixups and calling the writing routine as a DECLARE_PCI_FIXUP_EARLY routine works. The actual eeprom data can be read later as part of the ath9k initialisation by utilising the hook ltqpci_plat_dev_init().

The eeprom data needs to be byte-swapped, then the data which is meant to be words byte swapped again. We can't currently tell Ath9k to handle this without patching ath9k, but once done, it works.

unfortunately, wireless (PCI) and NAND (EBU) interact. for the moment, PCI gets inhibited while the nand chip is selected; I felt it better to have some wireless degradation rather than file system corruption.

The FXO/FXS interface for telephony is a combination of Teridian 73m1966 and Infineon Vinetic PEF4268F 'Ringing SLIC with Integrated DC/DC Converter', for which some drivers are available. I believe that as I write, some work may be being done on using SIP with the telephone interfaces.

The DECT modem (SiTel SC14488) is a processor in it's own right. It is connected to ttyLTQ0, and also to Danube PCM Lines? We would need firmware to run within the SiTel modem to talk to the Dect phones, and to understand the protocols on the serial control, as well as implement the PCM communication (which seems to be DMAed). There is an un-populated site for a serial eeprom? - so the firmware must be programmed by the main cpu at startup.

Although we have the original BT firmware for the DECT modem, there is little or no information regarding how this may be controlled. The control seems to be done from within the OpenRG application, for which we have no source.