Lantiq SoCs

The design has changed hands a few times, from Texas Instruments to Infineon to Lantiq, then to Intel and perhaps now to MaxLinear.

Terminology:

• The AR7 is included here for historical context but ar7 is a distinct platform in OpenWrt.
• Lantiq applied the XWAY trademark to various parts (see product brochures/listings) but in BB, CC and trunk (as of 2016-05):
  • OpenWrt's xway only includes the DANUBE- and AR9-based models, not AMAZON
  • OpenWrt's xrx200 includes the VR9-based models
• but see OpenWrt Support for details

[1] Infineon called Amazon “AR8” in at least one product brochure. It probably applied to Danube too.

Manuals: 617580_dxs_api_device_driver_pr_rev3.0.pdf 617585_dxs_um_sd_rev2.2.pdf 617837_gateway_socs_voice_sp_4.44rc5_rn_rev2.0.pdf

Judging mostly by age and wiki pages:

• DANUBE devices: look pretty well supported, with builds for many devices having been in the system for years.
• xRX2xx devices: seem to work fine (speaking from experience of the BTHH5A, and the healthy wiki pages of the ZyXEL P2812HNU-Fx).
• AR9 devices: the Buffalo WBMR-HP-G300H and Netgear DGN3500B wiki pages look healthy.
• AMAZON-SE devices: platform support has been around since 2011 and remains, but timing was unkind; support consolidated shortly after the Attitude Adjustment freeze, but as few devices/user reports existed, build support got dropped again before Barrier Breaker. There has been some success building trunk (2016-05) for the DGN1000.
• AMAZON-ME: no data; anecdotally: “we tried booting OpenWrt on [one]: we never got a single response from it (even after hacking around in some linux early-boot code...)”
• VINAX, other AMAZON variants: no data

ADSL and VDSL are generally supported (probably through a combination of GPL dumps for some units and contributions directly from Lantiq; there may still be some blobs?). Some people report that AR9-/VR9-based routers achieve better synchronization than Danube-based boards.

Annex A,B,J,L,M should be supported. see package/network/config/ltq-vdsl-app/files/dsl_control

Danube/Danube-S: They have two MIPS 24kec CPUs, but the second core has few differences that make SMP support impossible. The second core is used for VoIP.

AR9/VR9: Their cores have multithreading support, but it does not work properly with these SoCs without some hacks seen in the source dumps of some boards. For now multithreading is not supported without specific patches for the AR9 and VR9.

A Lantiq WiFi chip. See https://forum.openwrt.org/t/support-for-wave-300-wi-fi-chip/24690/161

Lantiq SoCs have small mask ROMs capable of booting from various sources, selected by a combination the boot_selN pins. This mask ROM is what emits “ROM VER x.yy ... CFG 0x” over serial on these devices. Finding those pins on a given device can be tricky, but on several Lantiq-based devices it's the primary mechanism for installation or recovery. Consult the pages for a specific device for details on boot_selN access discovered so far (if any); since pins have only been found for BGA-packaged chips so far, access probably involves soldering to small surface mount resistor pads. Be careful, if you short the pins too long it is possible to create a loop. In this case the SoC tries always to boot e.g. from CFG 04 (UART). In this case your SoC is bricked!

The bootloader is typically U-Boot, sometimes brnboot.

When the boot_selN pins select UART mode (or on some SoCs such as the 50601, when the SPI flash can't be read or appears invalid), the mask ROM routine waits for data in hex. The format, which seems to have originated on the Motorola MMC2107, is:

• lines start with addresses (8 hex digits, encoding a 32-bit address)
• addresses are followed by data (128 hex digits, encoding 64 bytes)
• aligned addresses simply denote 64-byte writes at the corresponding locations
• selected unaligned addresses cause data to be interpreted differently:
  • 33333333: data is address/value pairs for writing individual words
    • this is typically used first, to configure some RAM access (SRAM? SDRAM? cache-as-RAM?) so there's somewhere to store the image
    • unused pairs seem to use all zeros for address/value
  • 11111111: data is a 32-bit checksum, followed by 120 0s of padding
  • 99999999: data is a 32-bit start address, again padded

U-Boot is often the payload, as in this example.

The Motorola toolchain included a Perl script called sikadown.pl which converted traditional S-record files into this format. OpenWrt's boot package contains (within Lantiq patches) a newer version, gct.pl, that is very similar to the one from the DGN1000 Netgear GPL release and does the same with the addition of RAM initialisation.

This is taken from a patent application and the specific example of the the PSB 50601 (Amazon SE), but other variants are likely very similar. What seems to vary between implementations is:

• Ease of influencing the boot via boot_selN pins:
  • Some might load and run code from any valid-looking flash if any boot_selN pin is set, and the structure of the flash can mean the set pins are ignored. The PSB 50601 behaves this way.
    • On these, if the boot_selN pins can't be located then another approach may be to inhibit flash reads, e.g. pull /CE high on a serial flash chip.
  • Others might honour the boot_selN pins before consulting the flash (the VRX268 seems to do this).
• Fallback mechanism; some may default to UART if other methods fail, some may not.

On an example PSB 50601-based unit the start of SPI, dictated by the mask ROM, is:

AA 55 FF FF  03 02 01 00  0C 00 05 04

This is interpreted as:

• the signature/magic 0xAA55 (signifies valid flash)
• a PHY0 address (0xFF); unclear what is expected to interpret this, or how
• a PHY1 address (0xFF); unclear what is expected to interpret this, or how
• a MAC (here 00:01:02:03:04:05), oddly laid out to straddle...
• the size (0x0C) in bytes of this header and reserved area (in this case there's no extra reserved space beyond this header)
• a validity flag for the MAC address (0x00 means valid)

If there were any reserved space, it would appear next.

A list of entries then follows. Similar to UART mode, addresses can indicate word writes, block writes or transfer of control:

• a plain address with clear low bits (0b00) is followed by a single word to be written there
• an address ORed with 0b01 is followed by a length (in 32-bit words) and a block of data to write; should be possible to initialise multiple non-contiguous regions just by concatenating multiple entries of this type
• a uint32 with 0b11 low bits terminates the list:
  • 0xFFFFFFFF: treat the following uint32 as the entry address, jumping to it
  • 0x00000003: attempt to boot from whatever boot_selN indicates (the next word isn't consulted)

The documentation outlines this, and transfers would be quicker than serial. Documentation/tooling welcomed.

On PSB 50601 the JTAG pins are:

• 49: TDO
• 50: TMS
• 51: nTRST
• 52: TDI
• 53: TCK

SPI pins are:

• 44: CLK
• 45: MOSI
• (46 unknown)
• 47: MISO
• 48: Slave select (probably the first of several)

EXIN = External Interrupt

The list of related devices: adsl, adsl2+, adsl2, amazon, ar7, ar9, danube, lantiq, vdsl, vdsl2, vinax, vr9