Atheros PB44

The PB44 is a reference design (a.k.a. evaluation platform) from Atheros (now Qualcomm), designed to demonstrate their “AR9001AP-3NX2” dual-concurrent 802.11n AP/Router solution¹⁾, which consists of a AR7161 CPU/SOC (System On Chip) and two AR9160 wireless chipsets used in a high-performance dual-band access point/router. The PB44 contains two mini-PCI slots, each of which contains a dual-band 801.11abgn 3×3 (3T3R) wireless card based on the AR9160 wireless MAC and AR5133 or AR9016 dual-band 3×3 MIMO Radio (some have one single-band card which is similar but with AR2133 or AR9103 2.4 GHz Radio). Three dual-band antennas each have a connection to both wireless cards. Each radio operates in one band at a time, but the two radios allow simultaneous dual-band operation.

The PB44 PCB carries a copyright dated 2006, 2007, and is marked with part number 250-01488-xxx, where xxx is a revision number (030 and 040 have been seen). The PB44 main PCB may be any of various colors: yellow, green, and red have been seen.

1. → downloads
2. → Install OpenWrt

→flash.layout

Note that the relative sizes of the vmlinux, rootfs, and rootfs_data will vary depending on the build that is being used. The total size is 7808 KiB (64 KiB x 122).

Download the pre-built Backfire release images from http://backfire.openwrt.org/10.03.1/ar71xx/, look for pb44 in the file names. The squashfs images are generally preferred over JFFS2 (see downloads). If you are brave, you can try out the bleeding edge firmware at http://downloads.openwrt.org/snapshots/trunk/.

In order to install OpenWRT, the boot process is halted to give access to the RedBoot prompt. Then the kernel and filesystem can be removed and replaced with OpenWRT images. The currently installed RedBoot does not need to be (and should not be) updated. Refer to the Installation walkthrough below for details.

Use teraterm and serial port. USB to serial adapters are excellent. Set serial to 115200/8/N/1/None

Press Ctl-C with a few seconds of power-up to halt boot and drop to RedBoot prompt.

RedBoot>

Now have a look at the current FLASH file system

RedBoot> fis list
Name              FLASH addr  Mem addr    Length      Entry point
RedBoot           0xBF000000  0xBF000000  0x00040000  0x00000000
vmlinux           0xBF040000  0x80060000  0x00120000  0x8029E000
filesystem        0xBF160000  0x80500000  0x00600000  0x00000000
FIS directory     0xBF7E0000  0xBF7E0000  0x0000F000  0x00000000
RedBoot config    0xBF7EF000  0xBF7EF000  0x00001000  0x00000000
RedBoot>

The factory firmware is stored in the vmlinux (kernel) and filesystem files.

Delete the factory firmware using fis init

RedBoot> fis init
About to initialize [format] FLASH image system - continue (y/n)? y
*** Initialize FLASH Image System
... Erase from 0xbf7e0000-0xbf7f0000: .
... Program from 0x80ff0000-0x81000000 at 0xbf7e0000: .
RedBoot> fis list
Name              FLASH addr  Mem addr    Length      Entry point
RedBoot           0xBF000000  0xBF000000  0x00040000  0x00000000
FIS directory     0xBF7E0000  0xBF7E0000  0x0000F000  0x00000000
RedBoot config    0xBF7EF000  0xBF7EF000  0x00001000  0x00000000
RedBoot>

Use fis free to view available FLASH space.

RedBoot> fis free
  0xBF040000 .. 0xBF7E0000
RedBoot>

In the above example, there is 0xBF7E0000 - 0xBF040000 = 0x7A00000 bytes (7.625 MB) of available space.

Determine start of free memory

RedBoot> %{FREEMEMLO}

The address is displayed along with an error message you can ignore. Round up to the next 0x100000 to avoid trouble. In the following, the memory address used to load the images is 0x80100000

Load the OpenWRT kernel image using the load command. You can use tftp, http, xmodem, or ymodem to load the firmware. I experienced trouble with tftp and http no matter what server software was used, so I opted to use ymodem instead. This loads the file over the serial port, which takes longer, but still only a minute or two.

RedBoot> load -r -v -b 0x80100000 -m ymodem
CCC

After issuing the above command, you will see a few “C” characters printed as part of the ymodem protocol. Now send the kernel file with ymodem using your terminal program (e.g. TeraTerm).

CCRaw file loaded 0x80100000-0x801dffff, assumed entry at 0x80100000
xyzModem - CRC mode, 0(SOH)/2049(STX)/0(CAN) packets, 6 retries
RedBoot>

Burn the file in memory to flash. There is no need to specifiy the start or end addresses as they will default to the values used in the load command. The memory base address and entry point are specified as 0x80060000, which is rounded up from the value returned by %{FREEMEMLO}.

RedBoot> fis create -b 0x80060000 -e 0x80060000 vmlinux
... Erase from 0xbf040000-0xbf120000: ..............
... Program from 0x80100000-0x801e0000 at 0xbf040000: ..............
... Erase from 0xbf7e0000-0xbf7f0000: .
... Program from 0x80ff0000-0x81000000 at 0xbf7e0000: .

Determine the amount of free FLASH space; when burning the filesystem, you want to use all available space.

RedBoot> fis free
  0xBF120000 .. 0xBF7E0000

Use a hexadecimal calculator to get the difference, in this case, 0x6c0000 bytes.

Load and burn the filesystem image, I recommend the squashfs image. Note the use of 0x6c0000 below.

RedBoot> load -r -v -b 0x80100000 -m ymodem
CCRaw file loaded 0x80100000-0x802fffff, assumed entry at 0x80100000
xyzModem - CRC mode, 0(SOH)/2049(STX)/0(CAN) packets, 6 retries
RedBoot>
RedBoot> fis create -l 0x6c0000 rootfs
... Erase from 0xbf120000-0xbf7e0000: ............................................................................................................
... Program from 0x80100000-0x80300000 at 0xbf120000: ................................
... Erase from 0xbf7e0000-0xbf7f0000: .
... Program from 0x80ff0000-0x81000000 at 0xbf7e0000: .
RedBoot> 
RedBoot> fis list
Name              FLASH addr  Mem addr    Length      Entry point
RedBoot           0xBF000000  0xBF000000  0x00040000  0x00000000
vmlinux           0xBF040000  0x80060000  0x000E0000  0x80060000
rootfs            0xBF120000  0x80050C00  0x006C0000  0x80050C00
FIS directory     0xBF7E0000  0xBF7E0000  0x0000F000  0x00000000
RedBoot config    0xBF7EF000  0xBF7EF000  0x00001000  0x00000000
RedBoot>

You have the OpenWRT kernel and filesystem in FLASH.

You now must edit the configuration boot script. The default firmware uses a gzip compressed kernel image, but the OpenWRT kernel uses an lzma compressed image. So we must change the load command in the boot script to use -l (decompress lzma) not -d (decompress gzip). Do not edit any of the other parameters unless you know that they need to change. Just press enter to skip editing the other parameters.

RedBoot>
RedBoot> fconfig
Run script at boot: true
Boot script:
.. fis load -d vmlinux
.. exec
Enter script, terminate with empty line
>> fis load -l vmlinux
>> exec
>>
Boot script timeout (1000ms resolution): 3
Use BOOTP for network configuration: false
Gateway IP address:
Local IP address: 192.168.1.2
Local IP address mask: 255.255.255.0
Default server IP address: 192.168.1.20
Console baud rate: 115200
GDB connection port: 9000
Force console for special debug messages: false
Network debug at boot time: false
Update RedBoot non-volatile configuration - continue (y/n)? y
... Erase from 0xbf7e0000-0xbf7f0000: .
... Program from 0x80ff0000-0x81000000 at 0xbf7e0000: .
RedBoot>

Now just reboot.

RedBoot> reset

This time, allow RedBoot to boot. You should see the usual OpenWRT console messages as it boots. Toward the end you will see that it is initializing the JFFS2 filesystem. This only happens on first boot. When the action stops, press enter to get to the shell BusyBox ash prompt.

The LAN GbE switch does not function with the current pre-compiled stable image. You will need to take a few extra steps to obtain the firmware and the driver (to load the firmware) in order to make the GbE switch function.

First, plug obtain an internet connection by plugging the WAN port (the single Ethernet port) into your DHCP-enabled network. The eth0 interface will automatically come up and will obtain an IP address via DHCP. Now you can download the necessary firmware file as below.

cd /tmp
wget http://mirror2.openwrt.org/sources/vsc73x5-ucode.tar.bz2
bunzip2 vsc73x5-ucode.tar.bz2
tar xvf vsc73x5-ucode.tar
cp vsc73x5-ucode/g5e_Plus1_2_29a_unmanaged_Atheros_v3.bin /lib/firmware/vsc7395_ucode_pb44.bin
ls /lib/firmware

Verify that there is a file named vsc7395_ucode_pb44.bin

Install the driver package.

opkg update
opkg install kmod-spi-vsc7385

The driver will install, then proceed to load the firmware into the GbE switch. You will see all four LAN port LEDs light momentarily after firmware is loaded. The LAN side Ethernet can now be used.

Refer to Basic Configuration for tips on initial setup.

→ generic.sysupgrade

Note that due to the lack of a firmware partition in flash, it is not possible to perform a sysupgrade using the command line or LuCI. Instead, the new kernel (vmlinux) and squashfs or jffs2 file system (rootfs) must be written to flash using RedBoot, following the installation procedure as above. Be sure to manually save any configuration data that you wish to apply to the new installation as it will be wiped out.

→ Basic configuration After flashing, proceed with this.
Set up your Internet connection, configure wireless, configure USB port, etc.

The default network configuration is:

Both wireless links are disabled by default. DHCP server is enabled by default on br-lan.

There is no support for VLANs on the PB44. This is a limitation of the firmware and/or driver for the VSC7395 switch; the hardware itself is capable of using VLANs.

→ failsafe_and_factory_reset

→ hardware.button on howto use and configure the hardware button(s).

The PB44 has two buttons, RST and JPST. Here, we merely name the buttons, so we can use them in the above Howto:

PCB: 250-01488-030

(Mouse over devices for description)

The PB44 has several LEDs on board, some of which can be controlled by software, and some of which are controlled exclusively by hardware. Refer to the PCB image for locations.

The WAN Ethernet port LED is controlled by the VAC8601 Phy chip. It glows green steadily when there is a good link, and flashes when there is activity on the port. The four LAN Ethernet port LEDs are controlled by the VSC7395 switch. They glow green when there is a good link on the port, and do not flash for activity.

→ LEDs can be controlled via UCI System Configuration or LuCI, in the system tab.

A dual-color LED is provided for each mini-PCI slot, and is controlled by the card in the slot. Only the amber portion of the LED appears to be functional. Another dual-color LED is controlled via the AR7161 GPIO pins. These four LEDs are configured as:

• ath9k-phy0
• ath9k-phy1
• pb44:amber:jump1
• pb44:green:jump2

All LEDs and their connections, from left to right in the PCB image:

→ Hardware Buttons General information about making use of hardware buttons.

The PB44 has two hardware buttons which can be configured to perform arbitrary actions when pressed (or released for that matter):

• “JPST”, configured as BTN_0
• “RST”, configured as BTN_1

The PB44 has three dual-band antennas which connect to the Mini PCI wireless boards using standard U.FL (aka IPX, aka UMCC) connectors. They are not removable in that they are not attached with RP-SMA connectors, but they are easily replaceable if desired. The U.FL connector with the red band is the 5 GHz antenna. The other is for the 2.4 GHz band. It is possible to use the 2.4 GHz antenna at 5 GHz with reduced efficiency (gain), but the 5 GHz antenna will function quite poorly at 2.4 GHz. Keep this in mind when deciding which radio to use in each band.

→ port.serial general information about the serial port, serial port cable, etc.

The PB44 main PCB has a 2×6 pin header with TTL level serial signals, but it also includes the required RS232-level converter board. To connect with serial, use a standard straight-through male to female DB-9 serial cable. Set your serial port to 115200 baud, 8/N/1 and no flow control.

→ port.jtag general information about the JTAG port, JTAG cable, etc.

JTAG is available via a header on the PCB. Pinout is not known.

→ generic.debrick

1. you could read about bootloader in general

The version of RedBoot that is pre-installed works well with OpenWRT. Unless you have a special requirement to do so, avoid modifying or upgrading the bootloader, as this may brick the router in a way that requires JTAG to recover (i.e. you probably won't recover it). As long as the RedBoot bootloader and its configuration remain intact in FLASH, you will almost always be able to recover a bricked router by flashing a fresh set of images using RedBoot.

The AR7161 CPU is capable of addressing up to 256 MB of memory. An upgrade to up to 256 MB is therefore possible at least in theory, using two 64Mx16 (1024 Mbit) DDR chips. These are very rare, especially in TSSOP form (as opposed to BGA). More realistic is an upgrade to 128 MB using two 32Mx16 (512 Mbit) DDR chips, which can occasionally be found on 512 MB SO-DIMMs. Ensure that you use 400 MHz (“PC3200”) chips, capable of CAS 2.5 (or better) at 333 MHz, and CAS 3 (or better) at 400 MHz.

If the SLIC (FXO/FXS) PCM telecom interface and/or I²S (Stereo Audio) interface are not going to be used, then the four GPIO pins that are used for each function can be re-used as GPIO instead. These are GPIO_2 through 5 for SLIC, and GPIO_6 through 8 and 11 for I²S. Ensure that bit 17 (I²S) and bit 16 (SLIC) of the GPIO Function register (0x18040028) are set to 0 to disable the respective functionality and to enable the pins as general purpose GPIO. OpenWRT does not include drivers for either SLIC or I²S, and these should be disabled by default.

The GPIO pins can be accessed using the pseudo files under /dev/class/gpio, or they may be registered by other custom device drivers for special functions such as to drive LEDs, to implement a bit-banged I²C or SPI bus, etc..

Electrical access to these GPIO is possible through the three 10-pin headers marked “SLIC” and the unnamed 30-pin header at the top of the board. For GPIO 6, 7, 8, and 11, some resistors may need to be moved/populated in order to divert the signals from the on-board CODEC (ADC/DAC) to the header. These are very small SMD resistors, so only those persons skilled and equipped to do SMD rework should attempt this.

This has not been tested yet.

Some GPIO may be limited to either input or output due to the use of a buffer IC between the AR7161 and the external device. In particular, GPIO 2 and 11 are used as inputs for SLIC and I²S respecitively, and should NEVER be configured to an output. This will cause the AR7161 and the buffer to each drive the signal, possibly to a different voltage, causing excess current and possible overheating or damage to the AR7161 or buffer IC.

If you are considering a bandwidth-heavy use for GPIO (such as a I²C or SPI bus, MMC-over-SPI, LCD, etc.) then use GPIO < 16 instead of trying to use GPIO at >= 16, which are controlled by a GPIO extender accessed over an I²C bus. The extra overhead of I²C access makes those higher numbered GPIO much slower and completely unsuitable for fast operation. (They are fine for LEDs).

Pinout of the connectors is TDB. If you have this information, please add it here.

A bit-banged I²C bus is implemented using GPIO 0 and 1. Due to the nature of I²C, more devices can easily be added. The only device on this I²C bus is the PCF8575 I/O expander at device 0x20. The PCF8575 is used to implement 16 additional GPIO (16 through 31) which are used primarily for the on-board LEDs and buttons. Any number of additional I²C devices can be added as long as addresses are unique and bus signal integrity is maintained. Various packages are available to scan the I²C bus for devices and to access the devices from the shell. Device-specific drivers can also be used, and of course custom drivers can also be developed.

Electrical access to the I²C data and clock can be obtained by soldering small wires directly to the respective pins of the PCF8575, or you can attempt to visually trace the bus signals to another point on the board.

This has not been tested yet.

The RS232 converter board has three LEDs on it, one of which is dual-color. The required current limiting resistors are also present. These four LEDs can be driven directly from GPIO pins 're-used' as above, or from any other active-HI signal. For example, one each could be connected to the Tx and Rx signals for the console, to give a visual indication of serial port activity.

This has not been tested yet.

Overclocking the CPU and DDR memory is possible by directly manipulating the registers that control the PLL used to drive the CPU, DDR, and AHB (system bus) clocks. Note that while the base PLL clock speed can be changed, it is not possible to change the CPU/DDR ratio without also issuing a CPU reset. By default, the PLL is configured to 680 MHz, with the CPU running at 1/1 of the PLL frequency (680 MHz), the DDR running at 1/2 of the PLL Frequency (340 MHz), and the AHB running at 1/4 of the PLL frequency (170 MHz). By changing only the PLL frequency, all of these are changed simultaneously. An overclock to 720 MHz CPU speed and 360 MHz DDR speed (approximately +6%) should be easily achieved on most boards. Overclock to 760 OR 800 MHz may or may not be possible depending on individual boards.

When overclocking, you may need to increase the CAS latency of the DDR RAM in order for it to continue to work normally. At 680 MHz CPU / 340 MHz DDR speed, RedBoot sets the CAS latency to 2.5. At 400 MHz CPU / 400 MHz DDR speed, the CAS latency is set to 3. Changing CAS latency on-the-fly is possible but somewhat risky. This must only be done in RedBoot (not in Linux) when RAM is not being accessed frequently. Both the DDR controller (of the AR7161) and the DDR RAM chips themselves need to be updated with the new CAS latency value. To do this, the 'DDR_CONFIG' and 'DDR_MODE_REGISTER' are updated, then the value 0x1 is written to the 'DDR_CONTROL' register to initiate a “MRS update cycle” which sends the new configuration to the DDR chips. The following will achieve this:

ar7100_reg_wr 0x18000000 0x77b8884e;ar7100_reg_wr 0x18000008 0x33;ar7100_reg_wr 0x18000010 0x1

Note that the serial console baud rate is based on the AHB bus speed, so changing the PLL (and thereby the AHB) speed results in the baud rate changing as a side effect. Therefore, if the PLL is adjusted using the RedBoot console command prompt, the console is rendered unusable. The workaround is to string together several commands (with ';' between each) which update the PLL, and the baud rate in a single line.

Note that PCI and Ethernet interface clocks are derived from a secondary PLL, and are not affected by the adjustment of the primary (CPU) PLL.

All registers associated with overclocking can be (and must be) manipulated from RedBoot prior to the Linux kernel being executed. The following is an example:

ar7100_reg_rd 0x18050000

value of 0xC0140080 is returned

ar7100_reg_wr 0x18050000 0x80140088

1. increases the PLL Feedback divider by 1, increasing PLL frequency by 40 MHz (to 720 MHz).
2. bits 3 through 7 of this register control the PLL divisor (effectively the multiplier, x 40 MHz). e.g for 0xc0140080, bits 3..7 give b10000, which is 16. Add 1 and multiply by 40 MHz to get 680 MHz.

Running the above command will immediately cause the serial console to stop working as the baud rate will be wrong. See below for examples of correcting the baud rate.

Don't do this

Can't get your router to work at 800 MHz but desperately want to, for some reason? Try over-volting the CPU! Actually, don't. You'll probably fry your very nice router. You've been warned.

The CPU operates on 1.20 V nominal, with a maximum recommended operating voltage of 1.24 V. Identify the power supply that provides the 1.20 V for the CPU and measure it. If it is less than 1.24 V, try increasing it. If you don't know how to do that, then don't bother trying. You'll just end up destroying your router. If you have the skills to pull off this modification, then you may be able to squeeze a few more MHz from your CPU.

Don't even try this without a heatsink on the AR7161 CPU. Power dissipation (read: HEAT) increases with the square of voltage increase, so bumping up voltage by a measly 10% will increase power by 21%! ... and that's at the same frequency. Add the propertional increase in heat caused by increasing frequency (+10% speed = +10% heat) and you can see that heat becomes a problem very quickly. At 10% increase in voltage with a 10% increase in clock speed, produces 33% more heat!

The PCI bus of the AR7161 is specified to operate at up to 66 MHz. The AR9160 based Mini-PCI cards can also operate at 66 MHz. There are no other devices on the PCI bus. It should therefore be possible to switch the PCI bus to 66 MHz operation to increase PCI throughput. By modifying the PCI Clock Control Register, it is possible to adjust the PCI clock rate to an (almost) arbitrary value. The PCI clock is derived from the secondary PLL, which is nominally set to 1 GHz. in order to adjust the PCI clocking in RedBoot, refer to the following examples:

ar7100_reg_rd 0x1805001C

returns 0x000000EE which is 33 MHz (0xE+1=0xF=15 clock counts at Hi state, then 0xE→15 clock counts at Lo state, total is 30 counts, 1000 MHz / 30 = 33.33 MHz).

Set to 66 MHz:

ar7100_reg_wr 0x1805001C 0x76

Sets the Hi phase clock counts to 8 (7+1) and low phase to 7 (6+1), which is 15 counts total, so at 1 Ghz, the clock period is (1000 MHz)/15 = 66.66 MHz

This has the potential to have an actual positive effect on system performance, as at 300 Mbit/s on each of the two radios, up to 300/8 = 35 MB/s of PCI bandwidth may be consumed by each radio. That does not include the address cycles or any other reads/writes other than the raw transmitted and received data. It is therefore possible that the PCI bus is utilized at >75% when the radios are very busy. Increasing to 66 MHz operation will reduce the PCI bus utilization to <50% in all conditions, potentially reducing hardware and software latency in accessing data over the bus.

Be aware of the risk of data corruption. Do a lot of testing prior to implementing this permanently (so far I personally have seen no issues). Be aware of extra heat generated in the AR7161 due to the increased speed.

While it is possible to run the above commands manually at the RedBoot prompt, it would be convenient to have those commands run automatically at startup. This is possible by adding the commands to RedBoot's 'fconfig' startup script. Due to the large number of commands and the size of them, they occupy more space than is available to store the script. To work around this, aliases can becreated to significantly reduce the size of the script.

First create the aliases. Answer “n” to update fconfig except after the last one.

alias pci "ar7100_reg_wr 0x1805001c "
n
alias pll "ar7100_reg_wr 0xb8050000 "
n
alias com "ar7100_reg_wr 0xb802000"
n
alias ddr "ar7100_reg_wr 0xb80000"
n
alias boot "fis load -l vmlinux;exec"
y

The following 'fconfig' boot script will set the PCI to 66 MHz, set the PLL to 720 MHz (720/360/180 Mhz CPU/DDR/AHB speed), update the baud rate to 115200, and load and boot the linux kernel. DDR CAS latency remains 2.5. This configuration is stable on my router.

%{pci}0x76
%{pll}0x140188;%{pll}0x80143188;%{com}c 0x80;%{com}0 98;%{com}4 0;%{com}c 0;%{com}c 3
%{boot}

The value of '98' above is used to set the baud rate. It is calculated as follows: AHB Speed in Hz / ( 16 * BaudRate). E.g. 180000000/(16*115200) = 97.65625 = 98

The following 'fconfig' boot script will set the PCI to 66 MHz, set the DDR CAS latency to 3, set the PLL to 760 MHz (760/380/190 Mhz CPU/DDR/AHB speed), update the baud rate to 115200, and load and boot the linux kernel. (This configuration will boot but is not stable on my router).

%{pci}0x76
%{ddr}00 0x77b8884e;%{ddr}08 0x33;%{ddr}10 1
%{pll}0x140190;%{pll}0x80143190;%{com}c 0x80;%{com}0 103;%{com}4 0;%{com}c 0;%{com}c 3
%{boot}

The following 'fconfig' boot script will set the PCI to 66 MHz, set the DDR CAS latency to 3, set the PLL to 800 MHz (800/400/200 Mhz CPU/DDR/AHB speed), update the baud rate to 115200, and load and boot the linux kernel. (This configuration will not boot on my router).

%{pci}0x76
%{ddr}00 0x77b8884e;%{ddr}08 0x33;%{ddr}10 1
%{pll}0x140198;%{pll}0x80143198;%{com}c 0x80;%{com}0 109;%{com}4 0;%{com}c 0;%{com}c 3
%{boot}

Success? Failure? Discuss your overclocking results in the OpenWrt forum.

If you push the limits too high and the router crashes, then power cycle the router. When the bootloader loads, it uses the default stable configuration, but you must stop RedBoot from booting using ctl-C. Then you can update the boot script to remove/change the overclock.

How to add tags