Skip to content
Snippets Groups Projects
  • Martin Kennedy's avatar
    7e614820
    mpc85xx: add support for Extreme Networks WS-AP3825i · 7e614820
    Martin Kennedy authored
    Hardware:
    
    - SoC:     Freescale P1020
      - CPU:     2x e500v2 @ 800MHz
    - Flash:   64MiB NOR (1x Intel JS28F512)
    - Memory:  256MiB (2x ProMOS DDR3 V73CAG01168RBJ-I9H 1Gb)
    - WiFi1:   2.4+5GHz abgn 3x3 (Atheros AR9590)
    - Wifi2:   5GHz an+ac 3x3 (Qualcomm Atheros QCA9890)
    - ETH:     2x PoE Gigabit Ethernet (2x Atheros AR8035)
    - Power:   12V (center-positive barrel) or 48V PoE (active or passive)
    - Serial:  Cisco-compatible RJ45 next to 12V power socket (115200 baud)
    - LED Driver: TI LV164A
      - LEDs: (not functioning)
        - 2x Power (Green + Orange)
        - 4x ETH (ETH1 + ETH2) x (Green + Orange)
        - 2x WiFi (WiFi2 + WiFi1)
    
    Installation:
    
    1. Grab the OpenWrt initramfs <openwrt-initramfs-bin>, e.g.
       openwrt-mpc85xx-p1020-extreme-networks_ws-ap3825i-initramfs-kernel.bin.
       Place it in the root directory of a DHCP+TFTP server, e.g. OpenWrt
       `dnsmasq` with configuration `dhcp.server.enable_tftp='1'`.
    
    2. Connect to the serial port and boot the AP with options
       e.g. 115200,N,8. Stop autoboot in U-Boot by pressing Enter after
       'Scanning JFFS2 FS:' begins, then waiting for the prompt to be
       interrupted. Credentials are identical to the one in the APs
       interface. By default it is admin / new2day: if these do not work,
       follow the OEM's reset procedure using the reset button.
    
    3. Set the bootcmd so the AP can boot OpenWrt by executing:
    
    ```uboot
    setenv boot_openwrt "cp.b 0xEC000000 0x2000000 0x2000000; interrupts off; bootm start 0x2000000; bootm loados; fdt resize; fdt boardsetup; fdt chosen; bootm prep; bootm go;"
    setenv bootcmd "run boot_openwrt"
    saveenv
    ```
    
       If you plan on going back to the vendor firmware - the bootcmd for it
       is stored in the boot_flash variable.
    
    4. Load the initramfs image to RAM and boot by executing
    
    ```uboot
    setenv ipaddr <ipv4 client address>;
    setenv serverip <tftp server address>;
    tftpboot 0x2000000 <openwrt-initramfs-bin>;
    interrupts off;
    bootm start 0x2000000;
    bootm loados;
    fdt resize;
    fdt boardsetup;
    fdt chosen;
    bootm prep;
    bootm go;
    ```
    
    5. Make a backup of the "firmware" partition if you ever wish to go back
       to the vendor firmware.
    
    6. Upload the OpenWrt sysupgrade image via SCP to the devices /tmp
       folder.
    
    7. Flash OpenWrt using sysupgrade.
    
    ```ash
    sysupgrade /tmp/<openwrt-sysupgrade-bin>
    ```
    
    Notes:
    
    - We must step through the `bootm` process manually to avoid fdt
      relocation. To explain: the stock U-boot (and stock Linux) are configured
      with a very large CONFIG_SYS_BOOTMAPSZ (and the device's stock Linux
      kernel is configured to be able to handle it). The U-boot version
      predates the check for the `fdt_high` variable, meaning that upon fdt
      relocation, the fdt can (and will) be moved to a very high address; the
      default appears to be 0x9ffa000. This address is so high that when the
      Linux kernel starts reading the fdt at the beginning of the boot process,
      it encounters a memory access exception and panics[5]. While it is
      possible to reduce the highest address the fdt will be relocated to by
      setting `bootm_size`, this also has the side effect of limiting the
      amount of RAM the kernel can use[3].
    
    - Because it is not relocated, the flattened device tree needs to be
      padded in the build process to guarantee that `fdt resize` has
      enough space.
    
    - The primary ethernet MAC address is stored (and set) in U-boot; they are
      shimmed into the device tree by 'fdt boardsetup' through the
      'local-mac-address' property of the respective ethernet node, so OpenWrt
      does not need to set this at runtime. Note that U-boot indexes the
      ethernet nodes by alias, which is why the device tree explicitly aliases
      ethernet1 to enet2.
    
    - LEDs do not function under OpenWrt. Each of 8 LEDs is connected to an
      output of a TI LV164A shift register, which is wired to GPIO lines and
      operates through bit-banged SPI. Unfortunately, I am unable to get the
      spi-gpio driver to recognize the `led_spi` device tree node at all, as
      confirmed by patching in printk messages demonstrating
      spi-gpio.c::spi_gpio_probe never runs. It is possible to manually
      articulate the shift register by exporting the GPIO lines and stepping
      their values through the sysfs.
    
    - Though they do not function under OpenWrt, I have left the pinout details
      of the LEDs and shift register in the device tree to represent real
      hardware.
    
    - An archive of the u-boot and Linux source for the AP3825i (which is one
      device of a range of devices code-named 'CHANTRY') be found here[1].
    
    - The device has an identical case to both the Enterasys WS-AP3725i and
      Adtran BSAP-2030[2] (and potentially other Adtran BSAPs). Given that
      there is no FCC ID for the board itself (only its WLAN modules), it's
      likely these are generic boards, and even that the WS-AP3725i is
      identical, with only a change in WLAN card. I have ordered one to confirm
      this.
    
    - For additional information: the process of porting the board is
      documented in an OpenWrt forum thread[4].
    
    [1]: magnet:?xt=urn:btih:f5306a5dfd06d42319e4554565429f84dde96bbc
    [2]: https://forum.openwrt.org/t/support-for-adtran-bluesocket-bsap-2030/48538
    [3]: https://forum.openwrt.org/t/adding-openwrt-support-for-ws-ap3825i/101168/29
    [4]: https://forum.openwrt.org/t/adding-openwrt-support-for-ws-ap3825i/101168
    [5]: https://forum.openwrt.org/t/adding-openwrt-support-for-ws-ap3825i/101168/26
    
    
    
    Tested-by: default avatarMartin Kennedy <hurricos@gmail.com>
    Signed-off-by: default avatarMartin Kennedy <hurricos@gmail.com>
    7e614820
    History
    mpc85xx: add support for Extreme Networks WS-AP3825i
    Martin Kennedy authored
    Hardware:
    
    - SoC:     Freescale P1020
      - CPU:     2x e500v2 @ 800MHz
    - Flash:   64MiB NOR (1x Intel JS28F512)
    - Memory:  256MiB (2x ProMOS DDR3 V73CAG01168RBJ-I9H 1Gb)
    - WiFi1:   2.4+5GHz abgn 3x3 (Atheros AR9590)
    - Wifi2:   5GHz an+ac 3x3 (Qualcomm Atheros QCA9890)
    - ETH:     2x PoE Gigabit Ethernet (2x Atheros AR8035)
    - Power:   12V (center-positive barrel) or 48V PoE (active or passive)
    - Serial:  Cisco-compatible RJ45 next to 12V power socket (115200 baud)
    - LED Driver: TI LV164A
      - LEDs: (not functioning)
        - 2x Power (Green + Orange)
        - 4x ETH (ETH1 + ETH2) x (Green + Orange)
        - 2x WiFi (WiFi2 + WiFi1)
    
    Installation:
    
    1. Grab the OpenWrt initramfs <openwrt-initramfs-bin>, e.g.
       openwrt-mpc85xx-p1020-extreme-networks_ws-ap3825i-initramfs-kernel.bin.
       Place it in the root directory of a DHCP+TFTP server, e.g. OpenWrt
       `dnsmasq` with configuration `dhcp.server.enable_tftp='1'`.
    
    2. Connect to the serial port and boot the AP with options
       e.g. 115200,N,8. Stop autoboot in U-Boot by pressing Enter after
       'Scanning JFFS2 FS:' begins, then waiting for the prompt to be
       interrupted. Credentials are identical to the one in the APs
       interface. By default it is admin / new2day: if these do not work,
       follow the OEM's reset procedure using the reset button.
    
    3. Set the bootcmd so the AP can boot OpenWrt by executing:
    
    ```uboot
    setenv boot_openwrt "cp.b 0xEC000000 0x2000000 0x2000000; interrupts off; bootm start 0x2000000; bootm loados; fdt resize; fdt boardsetup; fdt chosen; bootm prep; bootm go;"
    setenv bootcmd "run boot_openwrt"
    saveenv
    ```
    
       If you plan on going back to the vendor firmware - the bootcmd for it
       is stored in the boot_flash variable.
    
    4. Load the initramfs image to RAM and boot by executing
    
    ```uboot
    setenv ipaddr <ipv4 client address>;
    setenv serverip <tftp server address>;
    tftpboot 0x2000000 <openwrt-initramfs-bin>;
    interrupts off;
    bootm start 0x2000000;
    bootm loados;
    fdt resize;
    fdt boardsetup;
    fdt chosen;
    bootm prep;
    bootm go;
    ```
    
    5. Make a backup of the "firmware" partition if you ever wish to go back
       to the vendor firmware.
    
    6. Upload the OpenWrt sysupgrade image via SCP to the devices /tmp
       folder.
    
    7. Flash OpenWrt using sysupgrade.
    
    ```ash
    sysupgrade /tmp/<openwrt-sysupgrade-bin>
    ```
    
    Notes:
    
    - We must step through the `bootm` process manually to avoid fdt
      relocation. To explain: the stock U-boot (and stock Linux) are configured
      with a very large CONFIG_SYS_BOOTMAPSZ (and the device's stock Linux
      kernel is configured to be able to handle it). The U-boot version
      predates the check for the `fdt_high` variable, meaning that upon fdt
      relocation, the fdt can (and will) be moved to a very high address; the
      default appears to be 0x9ffa000. This address is so high that when the
      Linux kernel starts reading the fdt at the beginning of the boot process,
      it encounters a memory access exception and panics[5]. While it is
      possible to reduce the highest address the fdt will be relocated to by
      setting `bootm_size`, this also has the side effect of limiting the
      amount of RAM the kernel can use[3].
    
    - Because it is not relocated, the flattened device tree needs to be
      padded in the build process to guarantee that `fdt resize` has
      enough space.
    
    - The primary ethernet MAC address is stored (and set) in U-boot; they are
      shimmed into the device tree by 'fdt boardsetup' through the
      'local-mac-address' property of the respective ethernet node, so OpenWrt
      does not need to set this at runtime. Note that U-boot indexes the
      ethernet nodes by alias, which is why the device tree explicitly aliases
      ethernet1 to enet2.
    
    - LEDs do not function under OpenWrt. Each of 8 LEDs is connected to an
      output of a TI LV164A shift register, which is wired to GPIO lines and
      operates through bit-banged SPI. Unfortunately, I am unable to get the
      spi-gpio driver to recognize the `led_spi` device tree node at all, as
      confirmed by patching in printk messages demonstrating
      spi-gpio.c::spi_gpio_probe never runs. It is possible to manually
      articulate the shift register by exporting the GPIO lines and stepping
      their values through the sysfs.
    
    - Though they do not function under OpenWrt, I have left the pinout details
      of the LEDs and shift register in the device tree to represent real
      hardware.
    
    - An archive of the u-boot and Linux source for the AP3825i (which is one
      device of a range of devices code-named 'CHANTRY') be found here[1].
    
    - The device has an identical case to both the Enterasys WS-AP3725i and
      Adtran BSAP-2030[2] (and potentially other Adtran BSAPs). Given that
      there is no FCC ID for the board itself (only its WLAN modules), it's
      likely these are generic boards, and even that the WS-AP3725i is
      identical, with only a change in WLAN card. I have ordered one to confirm
      this.
    
    - For additional information: the process of porting the board is
      documented in an OpenWrt forum thread[4].
    
    [1]: magnet:?xt=urn:btih:f5306a5dfd06d42319e4554565429f84dde96bbc
    [2]: https://forum.openwrt.org/t/support-for-adtran-bluesocket-bsap-2030/48538
    [3]: https://forum.openwrt.org/t/adding-openwrt-support-for-ws-ap3825i/101168/29
    [4]: https://forum.openwrt.org/t/adding-openwrt-support-for-ws-ap3825i/101168
    [5]: https://forum.openwrt.org/t/adding-openwrt-support-for-ws-ap3825i/101168/26
    
    
    
    Tested-by: default avatarMartin Kennedy <hurricos@gmail.com>
    Signed-off-by: default avatarMartin Kennedy <hurricos@gmail.com>