2016-01-17 21:05:19 +00:00
|
|
|
CONFIG_ARCH_HAS_TICK_BROADCAST=y
|
2017-10-21 13:44:30 +00:00
|
|
|
CONFIG_AT803X_PHY=y
|
2024-08-06 22:05:13 +00:00
|
|
|
CONFIG_B53=y
|
|
|
|
|
CONFIG_B53_MDIO_DRIVER=y
|
|
|
|
|
CONFIG_BCM_NET_PHYLIB=y
|
2019-01-16 23:43:13 +00:00
|
|
|
CONFIG_BROADCOM_PHY=y
|
2017-10-21 13:44:30 +00:00
|
|
|
CONFIG_CMDLINE_OVERRIDE=y
|
2014-12-11 18:39:22 +00:00
|
|
|
CONFIG_CPU_RMAP=y
|
2017-10-21 13:44:30 +00:00
|
|
|
CONFIG_EEPROM_LEGACY=y
|
2019-01-16 23:43:13 +00:00
|
|
|
# CONFIG_FSL_CORENET_CF is not set
|
2016-01-17 21:05:19 +00:00
|
|
|
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
|
2014-12-11 18:39:22 +00:00
|
|
|
CONFIG_GENERIC_TBSYNC=y
|
mpc85xx: add support for Extreme Networks WS-AP3825i
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: Martin Kennedy <hurricos@gmail.com>
Signed-off-by: Martin Kennedy <hurricos@gmail.com>
2021-11-28 01:59:18 +00:00
|
|
|
CONFIG_GPIO_74X164=y
|
2024-08-06 22:05:13 +00:00
|
|
|
CONFIG_GRO_CELLS=y
|
2017-10-21 13:44:30 +00:00
|
|
|
# CONFIG_GPIO_MAX77620 is not set
|
2014-12-11 18:39:22 +00:00
|
|
|
CONFIG_HAVE_RCU_TABLE_FREE=y
|
2017-10-21 13:44:30 +00:00
|
|
|
CONFIG_HIVEAP_330=y
|
2019-01-16 23:43:13 +00:00
|
|
|
CONFIG_PANDA=y
|
2024-05-30 00:27:50 +00:00
|
|
|
CONFIG_MSM460=y
|
2017-10-21 13:44:30 +00:00
|
|
|
CONFIG_I2C_CHARDEV=y
|
|
|
|
|
CONFIG_LEDS_LP5521=y
|
|
|
|
|
CONFIG_LEDS_LP55XX_COMMON=y
|
2016-01-17 21:05:19 +00:00
|
|
|
CONFIG_LOCK_SPIN_ON_OWNER=y
|
2021-08-10 18:22:18 +00:00
|
|
|
# CONFIG_MAX77620_THERMAL is not set
|
2017-10-21 13:44:30 +00:00
|
|
|
# CONFIG_MAX77620_WATCHDOG is not set
|
|
|
|
|
CONFIG_MFD_CORE=y
|
|
|
|
|
CONFIG_MFD_MAX77620=y
|
|
|
|
|
CONFIG_MTD_CFI=y
|
2019-01-16 23:43:13 +00:00
|
|
|
CONFIG_MTD_NAND_FSL_ELBC=y
|
2017-10-21 13:44:30 +00:00
|
|
|
CONFIG_MTD_PHYSMAP=y
|
2019-12-13 20:31:50 +00:00
|
|
|
CONFIG_MTD_SPLIT_FIRMWARE=y
|
|
|
|
|
CONFIG_MTD_SPLIT_FIT_FW=y
|
mpc85xx: Patch HiveAP 330 u-boot to fix boot
When Kernel 5.10 was enabled for mpc85xx, the kernel once again became too
large upon decompression (>7MB or so) to decompress itself on boot (see
FS#4110[1]).
There have been many attempts to fix booting from a compressed kernel on
the HiveAP-330:
- b683f1c36d8a ("mpc85xx: Use gzip compressed kernel on HiveAP-330")
- 98089bb8ba82 ("mpc85xx: Use uncompressed kernel on the HiveAP-330")
- 26cb167a5ca7 ("mpc85xx: Fix Aerohive HiveAP-330 initramfs image")
We can no longer compress the kernel due to size, and the stock bootloader
does not support any other types of compression. Since an uncompressed
kernel no longer fits in the 8MiB kernel partition at 0x2840000, we need to
patch u-boot to autoboot by running variable which isn't set by the
bootloader on each autoboot.
This commit repartitions the HiveAP, requiring a new COMPAT_VERSION,
and uses the DEVICE_COMPAT_MESSAGE to guide the user to patch u-boot,
which changes the variable run on boot to be `owrt_boot`; the user can
then set the value of that variable appropriately.
The following has been documented in the device's OpenWrt wiki page:
<https://openwrt.org/toh/aerohive/hiveap-330>. Please look there
first/too for more information.
The from-stock and upgrade from a previous installation now becomes:
0) setup a network with a dhcp server and a tftp server at serverip
(192.168.1.101) with the initramfs image in the servers root directory.
1) Hook into UART (9600 baud) and enter U-Boot. You may need to enter
a password of administrator or AhNf?d@ta06 if prompted. If the password
doesn't work. Try reseting the device by pressing and holding the reset
button with the stock OS.
2) Once in U-Boot, set the new owrt_boot and tftp+boot the initramfs image:
Use copy and paste!
# fw_setenv owrt_boot 'setenv bootargs \"console=ttyS0,$baudrate\";bootm 0xEC040000 - 0xEC000000'
# save
# dhcp
# setenv bootargs console=ttyS0,$baudrate
# tftpboot 0x1000000 192.168.1.101:openwrt-mpc85xx-p1020-aerohive_hiveap-330-initramfs-kernel.bin
# bootm
3) Once openwrt booted:
carefully copy and paste this into the root shell. One step at a time
# 3.0 install kmod-mtd-rw from the internet and load it
opkg update; opkg install kmod-mtd-rw
insmod mtd-rw i_want_a_brick=y
# 3.1 create scripts that modifies uboot
cat <<- "EOF" > /tmp/uboot-update.sh
. /lib/functions/system.sh
cp "/dev/mtd$(find_mtd_index 'u-boot')" /tmp/uboot
cp /tmp/uboot /tmp/uboot_patched
ofs=$(strings -n80 -td < /tmp/uboot | grep '^ [0-9]* setenv bootargs.*cp\.l' | cut -f2 -d' ')
for off in $ofs; do
printf "run owrt_boot; " | dd of=/tmp/uboot_patched bs=1 seek=${off} conv=notrunc
done
md5sum /tmp/uboot*
EOF
# 3.2 run the script to do the modification
sh /tmp/uboot-update.sh
# verify that /tmp/uboot and /tmp/uboot_patched are good
#
# my uboot was: (is printed during boot)
# U-Boot 2009.11 (Jan 12 2017 - 00:27:25), Build: jenkins-HiveOS-Honolulu_AP350_Rel-245
#
# d84b45a2e8aca60d630fbd422efc6b39 /tmp/uboot
# 6dc420f24c2028b9cf7f0c62c0c7f692 /tmp/uboot_patched
# 98ebc7e7480ce9148cd2799357a844b0 /tmp/uboot-update.sh <-- just for reference
# 3.3 this produces the /tmp/u-boot_patched file.
mtd write /tmp/uboot_patched u-boot
3) scp over the sysupgrade file to /tmp/ and run sysupgrade to flash OpenWrt:
sysupgrade -n /tmp/openwrt-mpc85xx-p1020-aerohive_hiveap-330-squashfs-sysupgrade.bin
4) after the reboot, you are good to go.
Other notes:
- Note that after this sysupgrade, the AP will be unavailable for 7 minutes
to reformat flash. The tri-color LED does not blink in any way to
indicate this, though there is no risk in interrupting this process,
other than the jffs2 reformat being reset.
- Add a uci-default to fix the compat version. This will prevent updates
from previous versions without going through the installation process.
- Enable CONFIG_MTD_SPLIT_UIMAGE_FW and adjust partitioning to combine
the kernel and rootfs into a single dts partition to maximize storage
space, though in practice the kernel can grow no larger than 16MiB due
to constraints of the older mpc85xx u-boot platform.
- Because of that limit, KERNEL_SIZE has been raised to 16m.
- A .tar.gz of the u-boot source for the AP330 (a.k.a. Goldengate) can
be found here[2].
- The stock-jffs2 partition is also removed to make more space -- this
is possible only now that it is no longer split away from the rootfs.
- the console-override is gone. The device will now get the console
through the bootargs. This has the advantage that you can set a different
baudrate in uboot and the linux kernel will stick with it!
- due to the repartitioning, the partition layout and names got a makeover.
- the initramfs+fdt method is now combined into a MultiImage initramfs.
The separate fdt download is no longer needed.
- added uboot-envtools to the mpc85xx target. All targets have uboot and
this way its available in the initramfs.
[1]: https://bugs.openwrt.org/index.php?do=details&task_id=4110
[2]: magnet:?xt=urn:btih:e53b27006979afb632af5935fa0f2affaa822a59
Tested-by: Martin Kennedy <hurricos@gmail.com>
Signed-off-by: Martin Kennedy <hurricos@gmail.com>
(rewrote parts of the commit message, Initramfs-MultiImage,
dropped bootargs-override, added wiki entry + link, uboot-envtools)
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
2021-12-22 18:08:33 +00:00
|
|
|
CONFIG_MTD_SPLIT_UIMAGE_FW=y
|
2019-01-16 23:43:13 +00:00
|
|
|
CONFIG_MTD_UBI=y
|
|
|
|
|
CONFIG_MTD_UBI_BEB_LIMIT=20
|
|
|
|
|
CONFIG_MTD_UBI_BLOCK=y
|
|
|
|
|
CONFIG_MTD_UBI_WL_THRESHOLD=4096
|
2014-12-11 18:39:22 +00:00
|
|
|
CONFIG_MUTEX_SPIN_ON_OWNER=y
|
2024-08-06 22:05:13 +00:00
|
|
|
CONFIG_NET_DEVLINK=y
|
|
|
|
|
CONFIG_NET_DSA=y
|
|
|
|
|
CONFIG_NET_DSA_TAG_BRCM=y
|
|
|
|
|
CONFIG_NET_DSA_TAG_BRCM_COMMON=y
|
|
|
|
|
CONFIG_NET_DSA_TAG_BRCM_LEGACY=y
|
|
|
|
|
CONFIG_NET_DSA_TAG_BRCM_PREPEND=y
|
|
|
|
|
CONFIG_NET_DSA_TAG_NONE=y
|
2014-12-11 18:39:22 +00:00
|
|
|
CONFIG_NET_FLOW_LIMIT=y
|
2024-08-06 22:05:13 +00:00
|
|
|
CONFIG_NET_SWITCHDEV=y
|
2013-04-26 16:57:43 +00:00
|
|
|
CONFIG_NR_CPUS=2
|
2017-10-21 13:44:30 +00:00
|
|
|
CONFIG_PADATA=y
|
|
|
|
|
CONFIG_REGMAP_IRQ=y
|
2021-02-20 00:36:06 +00:00
|
|
|
CONFIG_REGULATOR=y
|
2014-12-11 18:39:22 +00:00
|
|
|
CONFIG_RFS_ACCEL=y
|
|
|
|
|
CONFIG_RPS=y
|
2017-10-21 13:44:30 +00:00
|
|
|
# CONFIG_RTC_DRV_MAX77686 is not set
|
2016-01-17 21:05:19 +00:00
|
|
|
CONFIG_RWSEM_SPIN_ON_OWNER=y
|
2013-04-26 16:57:43 +00:00
|
|
|
CONFIG_SMP=y
|
mpc85xx: add support for Extreme Networks WS-AP3825i
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: Martin Kennedy <hurricos@gmail.com>
Signed-off-by: Martin Kennedy <hurricos@gmail.com>
2021-11-28 01:59:18 +00:00
|
|
|
CONFIG_SPI_GPIO=y
|
2014-12-11 18:39:22 +00:00
|
|
|
CONFIG_TREE_RCU=y
|
2019-01-16 23:43:13 +00:00
|
|
|
CONFIG_UBIFS_FS=y
|
2019-12-13 20:31:50 +00:00
|
|
|
CONFIG_WS_AP3710I=y
|
mpc85xx: add support for Extreme Networks WS-AP3825i
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: Martin Kennedy <hurricos@gmail.com>
Signed-off-by: Martin Kennedy <hurricos@gmail.com>
2021-11-28 01:59:18 +00:00
|
|
|
CONFIG_WS_AP3825I=y
|
2014-12-11 18:39:22 +00:00
|
|
|
CONFIG_XPS=y
|
