Have the port use GMAC1 with internal switch
which fixes the issue of the ethernet LED not functioning
The LED is triggered by the internal switch, not a GPIO.
The GPIO for the ethernet LED was added in ath79
as it was defined in the ar71xx target
but it was not functioning in ath79 for a previously unknown reason.
It is unknown why that GPIO was defined as an LED in ar71xx.
Signed-off-by: Michael Pratt <mcpratt@pm.me>
[drop unrelated changes: model property and SPI max frequency]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
for:
- ENH202 v1
- ENS202EXT v1
- EnstationAC v1
- EWS511AP
For EWS511AP, have default behavior as static ip
to match the behavior of all other APs in ath79
These boards are sold as
Client Bridge or Point to Point or Access Point
so there is probably no benefit to have WAN by default
for one of the ports, to prevent user confusion.
Signed-off-by: Michael Pratt <mcpratt@pm.me>
Port device support for Meraki MR12 from the ar71xx target to ath79.
Specifications:
- SoC: AR7242-AH1A CPU
- RAM: 64MiB (NANYA NT5DS32M16DS-5T)
- NOR Flash: 16MiB (MXIC MX25L12845EMI-10G)
- Ethernet: 1 x PoE Gigabit Ethernet Port (SoC MAC + AR8021-BL1E PHY)
- Ethernet: 1 x 100Mbit port (SoC MAC+PHY)
- Wi-Fi: Atheros AR9283-AL1A (2T2R, 11n)
Installation:
1. Requires TFTP server at 192.168.1.101, w/ initramfs & sysupgrade .bins
2. Open shell case
3. Connect a USB->TTL cable to headers furthest from the RF shield
4. Power on the router; connect to U-boot over 115200-baud connection
5. Interrupt U-boot process to boot Openwrt by running:
setenv bootcmd bootm 0xbf0a0000; saveenv;
tftpboot 0c00000 <filename-of-initramfs-kernel>.bin;
bootm 0c00000;
6. Copy sysupgrade image to /tmp on MR12
7. sysupgrade /tmp/<filename-of-sysupgrade>.bin
Notes:
- kmod-owl-loader is still required to load the ART partition into the
driver.
- The manner of storing MAC addresses is updated from ar71xx; it is
at 0x66 of the 'config' partition, where it was discovered that the
OEM firmware stores it. This is set as read-only. If you are
migrating from ar71xx and used the method mentioned above to
upgrade, use kmod-mtd-rw or UCI to add the MAC back in. One more
method for doing this is described below.
- Migrating directly from ar71xx has not been thoroughly tested, but
one method has been used a couple of times with good success,
migrating 18.06.2 to a full image produced as of this commit. Please
note that these instructions are only for experienced users, and/or
those still able to open their device up to flash it via the serial
headers should anything go wrong.
1) Install kmod-mtd-rw and uboot-envtools
2) Run `insmod mtd-rw.ko i_want_a_brick=1`
3) Modify /etc/fw_env.config to point to the u-boot-env partition.
The file /etc/fw_env.config should contain:
# MTD device env offset env size sector size
/dev/mtd1 0x00000 0x10000 0x10000
See https://openwrt.org/docs/techref/bootloader/uboot.config
for more details.
4) Run `fw_printenv` to verify everything is correct, as per the
link above.
5) Run `fw_setenv bootcmd bootm 0xbf0a0000` to set a new boot address.
6) Manually modify /lib/upgrade/common.sh's get_image function:
Change ...
cat "$from" 2>/dev/null | $cmd
... into ...
(
dd if=/dev/zero bs=1 count=$((0x66)) ; # Pad the first 102 bytes
echo -ne '\x00\x18\x0a\x12\x34\x56' ; # Add in MAC address
dd if=/dev/zero bs=1 count=$((0x20000-0x66-0x6)) ; # Pad the rest
cat "$from" 2>/dev/null
) | $cmd
... which, during the upgrade process, will pad the image by
128K of zeroes-plus-MAC-address, in order for the ar71xx's
firmware partition -- which starts at 0xbf080000 -- to be
instead aligned with the ath79 firmware partition, which
starts 128K later at 0xbf0a0000.
7) Copy the sysupgrade image into /tmp, as above
8) Run `sysupgrade -F /tmp/<sysupgrade>.bin`, then wait
Again, this may BRICK YOUR DEVICE, so make *sure* to have your
serial cable handy.
Signed-off-by: Martin Kennedy <hurricos@gmail.com>
[add LED migration and extend compat message]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Ran update_kernel.sh in a fresh clone without any existing toolchains.
Removed upstreamed patches:
imx6: 303-ARM-dts-imx6qdl-gw52xx-fix-duplicate-regulator-namin.patch
Build system: x86_64
Build-tested: ipq806x/R7800, bcm27xx/bcm2711
Run-tested: ipq806x/R7800
No dmesg regressions, everything functional
Signed-off-by: John Audia <graysky@archlinux.us>
Add statistics to ethtool. The statistics can be useful to
debug network issues.
The code is backported from mainline ag71xx.c driver.
Signed-off-by: Leon Leijssen <leon.git@leijssen.info>
Signed-off-by: Tianling Shen <cnsztl@gmail.com>
Specifications:
- SoC: QCA9558
- Flash: 128M NAND
- RAM: 256M
- Ethernet: QCA8337, 1 WAN and 4 LANs
- 2.4GHz wireless: SoC integrated
- 5GHz wireless: QCA9880
- 2 buttons (Reset and WPS)
- 4 GPIO-LEDs
- USB 2.0 port
Flash instructions: (To be done)
Note:
This router has an external watchdog connected to SoC's GPIO 18.
If the watchdog is not fed for about 2 seconds, it will reset the
SoC. Unfortunately, the stock U-boot has a bug that it does not
feed the watchdog when decompressing kernel. If the kernel is
LZMA-compressed, it might take too long before watchdog timeout.
So we have to use gzip instead for faster decompressing speed.
For initramfs image, compression is not used because it is bigger
and will take even more time to decompress.
Signed-off-by: DENG Qingfang <dengqf6@mail2.sysu.edu.cn>
Signed-off-by: CN_SZTL <cnsztl@project-openwrt.eu.org>
The majority of our targets provide a default value for the variable
SUPPORTED_DEVICES, which is used in images to check against the
compatible on a running device:
SUPPORTED_DEVICES := $(subst _,$(comma),$(1))
At the moment, this is implemented in the Device/Default block of
the individual targets or even subtargets. However, since we
standardized device names and compatible in the recent past, almost
all targets are following the same scheme now:
device/image name: vendor_model
compatible: vendor,model
The equal redundant definitions are a symptom of this process.
Consequently, this patch moves the definition to image.mk making it
a global default. For the few targets not using the scheme above,
SUPPORTED_DEVICES will be defined to a different value in
Device/Default anyway, overwriting the default. In other words:
This change is supposed to be cosmetic.
This can be used as a global measure to get the current compatible
with: $(firstword $(SUPPORTED_DEVICES))
(Though this is not precisely an achievement of this commit.)
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Signed-off-by: CN_SZTL <cnsztl@project-openwrt.eu.org>
On a platform with many very different devices, like found on ath79,
the generic profiles seem like remnants of the past that do not
have a real use anymore.
Remove them to have one thing less to maintain.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Acked-by: Paul Spooren <mail@aparcar.org>
Signed-off-by: CN_SZTL <cnsztl@project-openwrt.eu.org>
The "netgear,uimage" parser can be replaced by the generic
parser using device specific openwrt,ih-magic and
openwrt,ih-type properties.
Device tree properties for the following devices have not
been set, as they have been dropped from OpenWrt with the
removal of the ar71xx target:
FW_MAGIC_WNR2000V1 0x32303031
FW_MAGIC_WNR2000V4 0x32303034
FW_MAGIC_WNR1000V2_VC 0x31303030
FW_MAGIC_WPN824N 0x31313030
Tested-by: Sander Vanheule <sander@svanheule.net> # WNDR3700v2
Tested-by: Stijn Segers <foss@volatilesystems.org> # WNDR3700v1
Signed-off-by: Bjørn Mork <bjorn@mork.no>
The only difference between the "openwrt,okli" and the generic
parser is the magic. Set this in device tree for all affected
devices and remove the "openwrt,okli" parser.
Tested-by: Michael Pratt <mcpratt@protonmail.com> # EAP300 v2, ENS202EXT and ENH202
Signed-off-by: Bjørn Mork <bjorn@mork.no>
These devices do not run Ubiquiti AirOS. Rename the partition to the
name used by other UniFi devices with vendor dualboot support.
Signed-off-by: David Bauer <mail@david-bauer.net>
The USB port definition is only needed when it is linked to a USB
LED. Since there is none for this device, we might as well remove
the port definition.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
CPU: Atheros AR9342 rev 3 SoC
RAM: 64 MB DDR2
Flash: 16 MB NOR SPI
WLAN 2.4GHz: Atheros AR9342 v3 (ath9k)
WLAN 5.0GHz: QCA988X
Ports: 1x GbE
Flashing procedure is identical to other ubnt devices.
https://openwrt.org/toh/ubiquiti/common
Flashing through factory firmware
1. Ensure firmware version v8.7.0 is installed.
Up/downgrade to this exact version.
2. Patch fwupdate.real binary using
`hexdump -Cv /bin/ubntbox | sed 's/14 40 fe 27/00 00 00 00/g' | \
hexdump -R > /tmp/fwupdate.real`
3. Make the patched fwupdate.real binary executable using
`chmod +x /tmp/fwupdate.real`
4. Copy the squashfs factory image to /tmp on the device
5. Flash OpenWrt using `/tmp/fwupdate.real -m <squashfs-factory image>`
6. Wait for the device to reboot
(copied from Ubiquiti NanoBeam AC and modified)
Flashing from serial console
1. Connect serial console (115200 baud)
2. Connect ethernet to a network with a TFTP server, through a
passive PoE injector.
3. Press a key to obtain a u-boot prompt
4. Set your TFTP server's ip address, with:
setenv serverip <tftp-server-address>
5. Set the Bullet AC's ip address, with:
setenv ipaddr <bullet-ac-address>
6. Set the boot file, with:
setenv bootfile <name-of-initramfs-binary-on-tftp-server>
7. Fetch the binary with tftp:
tftpboot
8. Boot the initramfs binary:
bootm
9. From the initramfs, fetch the sysupgrade binary, and flash it with
sysupgrade.
The Bullet AC is identified as a 2WA board by Ubiquiti. As such, the UBNT_TYPE
must match from the "Flashing through factory firmware" install instructions
to work.
Phy0 is QCA988X which can tune either band (2.4 or 5GHz). Phy1 is AR9342,
on which 5GHz is disabled. It isn't currently known whether phy1 is
routed to the N connector at all.
Signed-off-by: Russell Senior <russell@personaltelco.net>
The flash capacity is divided in two flash chips and currently only
first is used. Increase available space for OpenWrt by additional 16 MiB
using mtd-concat driver. Because U-Boot might not be able to load kernel
image spanned through two flash chips, the size of kernel is limited
to space available on first first chip.
Cc: Vladimir Georgievsky <vladimir.georgievsky@yahoo.com>
Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
This device has (almost?) identical hardware to the F9J1108 v2 but uses
a different firmware magic and model number.
Specifications:
SoC: QCA9558
CPU: 720 MHz
Flash: 16 MiB NOR
RAM: 128 MiB
WiFi 2.4 GHz: QCA9558-AT4A 3x3 MIMO 802.11b/g/n
WiFi 5 GHz: QCA9880-2R4E 3x3 MIMO 802.11a/n/ac
Ethernet: 4x LAN and 1x WAN (all 1Gbit/s ports)
USB: 1 x USB 2.0 (lower), 1 x USB 3.0 (upper)
MAC addresses based on OEM firmware:
Interface Address Location
--------- ------- --------
lan *:5A sometimes in 0x6
wan *:5B 0x0
2.4Ghz *:5A 0x1002
5Ghz As per mini PCIe EEPROM
Flashing instructions:
The factory.bin can be flashed via the Belkin web UI or via the uboot
HTTP upgrade page (which is by default listening on 192.168.2.1). Once
the factory.bin has been written, sysupgrade.bin will work as usual.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
This moves some of the Engenius boards from generic to tiny:
- EAP350 v1
- ECB350 v1
- ENH202 v1
For these, factory.bin builds are already failing on master
branch because of the unique situation for these boards:
- 8 MB flash
- an extra "failsafe" image for recovery
- TFTP does not work (barely possible with 600 MTU)
- bootloader loads image from a longer flash offset
- 1 eraseblock each needed for OKLI kernel loader and fake rootfs
- using mtd-concat to make use of remaining space...
The manual alternative would be removing the failsafe partition.
However this comes with the risk of extremely difficult recovery
if a flash ever fails because TFTP on the bootloader is bugged.
Signed-off-by: Michael Pratt <mcpratt@pm.me>
[improve commit message]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Belkin F9J1108 v2 and F9K1115 v2 are (seemingly) identical hardware
with different model numbers. Extract all non-device specific code to a
common .dtsi so it can be re-used when adding support for the
F9K1115 v2.
Similar to the .dtsi most of the image building recipe code can be
re-used. Move everything except the device model, edimax header magic
and edimax header model into a shared build recipe.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
[drop duplicate TARGET_DEVICES, add EDIMAX_* to DEVICE_VARS, edit title]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
FCC ID: U2M-EAP350
Engenius EAP350 is a wireless access point with 1 gigabit PoE ethernet port,
2.4 GHz wireless, external ethernet switch, and 2 internal antennas.
Specification:
- AR7242 SOC
- AR9283 WLAN (2.4 GHz, 2x2, PCIe on-board)
- AR8035-A switch (GbE with 802.3af PoE)
- 40 MHz reference clock
- 8 MB FLASH MX25L6406E
- 32 MB RAM EM6AA160TSA-5G
- UART at J2 (populated)
- 3 LEDs, 1 button (power, eth, 2.4 GHz) (reset)
- 2 internal antennas
MAC addresses:
MAC address is labeled as "MAC"
Only 1 address on label and in flash
The OEM software reports these MACs for the ifconfig
eth0 MAC *:0c art 0x0
phy0 --- *:0d ---
Installation:
2 ways to flash factory.bin from OEM:
- if you get Failsafe Mode from failed flash:
only use it to flash Original firmware from Engenius
or risk kernel loop or halt which requires serial cable
Method 1: Firmware upgrade page:
OEM webpage at 192.168.10.1
username and password "admin"
Navigate to "Upgrade Firmware" page from left pane
Click Browse and select the factory.bin image
Upload and verify checksum
Click Continue to confirm and wait 3 minutes
Method 2: Serial to load Failsafe webpage:
After connecting to serial console and rebooting...
Interrupt uboot with any key pressed rapidly
execute `run failsafe_boot` OR `bootm 0x9f670000`
wait a minute
connect to ethernet and navigate to
"192.168.1.1/index.htm"
Select the factory.bin image and upload
wait about 3 minutes
Return to OEM:
If you have a serial cable, see Serial Failsafe instructions
otherwise, uboot-env can be used to make uboot load the failsafe image
*DISCLAIMER*
The Failsafe image is unique to Engenius boards.
If the failsafe image is missing or damaged this will not work
DO NOT downgrade to ar71xx this way, it can cause kernel loop or halt
ssh into openwrt and run
`fw_setenv rootfs_checksum 0`
reboot, wait 3 minutes
connect to ethernet and navigate to 192.168.1.1/index.htm
select OEM firmware image from Engenius and click upgrade
Format of OEM firmware image:
The OEM software of EAP350 is a heavily modified version
of Openwrt Kamikaze. One of the many modifications
is to the sysupgrade program. Image verification is performed
simply by the successful ungzip and untar of the supplied file
and name check and header verification of the resulting contents.
To form a factory.bin that is accepted by OEM Openwrt build,
the kernel and rootfs must have specific names...
openwrt-senao-eap350-uImage-lzma.bin
openwrt-senao-eap350-root.squashfs
and begin with the respective headers (uImage, squashfs).
Then the files must be tarballed and gzipped.
The resulting binary is actually a tar.gz file in disguise.
This can be verified by using binwalk on the OEM firmware images,
ungzipping then untaring.
The OEM upgrade script is at /etc/fwupgrade.sh
Later models in the EAP series likely have a different platform
and the upgrade and image verification process differs.
OKLI kernel loader is required because the OEM software
expects the kernel to be no greater than 1024k
and the factory.bin upgrade procedure would
overwrite part of the kernel when writing rootfs.
Note on PLL-data cells:
The default PLL register values will not work
because of the external AR8035-A switch between
the SOC and the ethernet PHY chips.
For AR724x series, the PLL register for GMAC0
can be seen in the DTSI as 0x2c.
Therefore the PLL register can be read from uboot
for each link speed after attempting tftpboot
or another network action using that link speed
with `md 0x1805002c 1`.
uboot did not have a good value for 1 GBps
so it was taken from other similar DTS file.
Tested from master, all link speeds functional
Signed-off-by: Michael Pratt <mcpratt@pm.me>
FCC ID: A8J-EAP600
Engenius EAP600 is a wireless access point with 1 gigabit ethernet port,
dual-band wireless, external ethernet switch, 4 internal antennas
and 802.3af PoE.
Specification:
- AR9344 SOC (5 GHz, 2x2, WMAC)
- AR9382 WLAN (2.4 GHz, 2x2, PCIe on-board)
- AR8035-A switch (GbE with 802.3af PoE)
- 40 MHz reference clock
- 16 MB FLASH MX25L12845EMI-10G
- 2x 64 MB RAM NT5TU32M16DG
- UART at H1 (populated)
- 5 LEDs, 1 button (power, eth, 2.4 GHz, 5 GHz, wps) (reset)
- 4 internal antennas
MAC addresses:
MAC addresses are labeled MAC1 and MAC2
The MAC address in flash is not on the label
The OEM software reports these MACs for the ifconfig
eth0 MAC 1 *:5e ---
phy1 MAC 2 *:5f --- (2.4 GHz)
phy0 ----- *:60 art 0x0 (5 GHz)
Installation:
2 ways to flash factory.bin from OEM:
- if you get Failsafe Mode from failed flash:
only use it to flash Original firmware from Engenius
or risk kernel loop or halt which requires serial cable
Method 1: Firmware upgrade page:
OEM webpage at 192.168.1.1
username and password "admin"
Navigate to "Upgrade Firmware" page from left pane
Click Browse and select the factory.bin image
Upload and verify checksum
Click Continue to confirm and wait 3 minutes
Method 2: Serial to load Failsafe webpage:
After connecting to serial console and rebooting...
Interrupt uboot with any key pressed rapidly
execute `run failsafe_boot` OR `bootm 0x9fdf0000`
wait a minute
connect to ethernet and navigate to
"192.168.1.1/index.htm"
Select the factory.bin image and upload
wait about 3 minutes
Return to OEM:
If you have a serial cable, see Serial Failsafe instructions
otherwise, uboot-env can be used to make uboot load the failsafe image
*DISCLAIMER*
The Failsafe image is unique to Engenius boards.
If the failsafe image is missing or damaged this will not work
DO NOT downgrade to ar71xx this way, it can cause kernel loop or halt
ssh into openwrt and run
`fw_setenv rootfs_checksum 0`
reboot, wait 3 minutes
connect to ethernet and navigate to 192.168.1.1/index.htm
select OEM firmware image from Engenius and click upgrade
Format of OEM firmware image:
The OEM software of EAP600 is a heavily modified version
of Openwrt Kamikaze. One of the many modifications
is to the sysupgrade program. Image verification is performed
simply by the successful ungzip and untar of the supplied file
and name check and header verification of the resulting contents.
To form a factory.bin that is accepted by OEM Openwrt build,
the kernel and rootfs must have specific names...
openwrt-senao-eap600-uImage-lzma.bin
openwrt-senao-eap600-root.squashfs
and begin with the respective headers (uImage, squashfs).
Then the files must be tarballed and gzipped.
The resulting binary is actually a tar.gz file in disguise.
This can be verified by using binwalk on the OEM firmware images,
ungzipping then untaring.
The OEM upgrade script is at /etc/fwupgrade.sh
Later models in the EAP series likely have a different platform
and the upgrade and image verification process differs.
OKLI kernel loader is required because the OEM software
expects the kernel to be no greater than 1536k
and the factory.bin upgrade procedure would
overwrite part of the kernel when writing rootfs.
Note on PLL-data cells:
The default PLL register values will not work
because of the external AR8035-A switch between
the SOC and the ethernet PHY chips.
For AR934x series, the PLL register for GMAC0
can be seen in the DTSI as 0x2c.
Therefore the PLL register can be read from uboot
for each link speed after attempting tftpboot
or another network action using that link speed
with `md 0x1805002c 1`.
Unfortunately uboot did not have the best values
so they were taken from other similar DTS files.
Tested from master, all link speeds functional
Signed-off-by: Michael Pratt <mcpratt@pm.me>
FCC ID: A8J-ECB600
Engenius ECB600 is a wireless access point with 1 gigabit PoE ethernet port,
dual-band wireless, external ethernet switch, and 4 external antennas.
Specification:
- AR9344 SOC (5 GHz, 2x2, WMAC)
- AR9382 WLAN (2.4 GHz, 2x2, PCIe on-board)
- AR8035-A switch (GbE with 802.3af PoE)
- 40 MHz reference clock
- 16 MB FLASH MX25L12845EMI-10G
- 2x 64 MB RAM NT5TU32M16DG
- UART at H1 (populated)
- 4 LEDs, 1 button (power, eth, 2.4 GHz, 5 GHz) (reset)
- 4 external antennas
MAC addresses:
MAC addresses are labeled MAC1 and MAC2
The MAC address in flash is not on the label
The OEM software reports these MACs for the ifconfig
phy1 MAC 1 *:52 --- (2.4 GHz)
phy0 MAC 2 *:53 --- (5 GHz)
eth0 ----- *:54 art 0x0
Installation:
2 ways to flash factory.bin from OEM:
- if you get Failsafe Mode from failed flash:
only use it to flash Original firmware from Engenius
or risk kernel loop or halt which requires serial cable
Method 1: Firmware upgrade page:
OEM webpage at 192.168.1.1
username and password "admin"
Navigate to "Upgrade Firmware" page from left pane
Click Browse and select the factory.bin image
Upload and verify checksum
Click Continue to confirm and wait 3 minutes
Method 2: Serial to load Failsafe webpage:
After connecting to serial console and rebooting...
Interrupt uboot with any key pressed rapidly
execute `run failsafe_boot` OR `bootm 0x9fdf0000`
wait a minute
connect to ethernet and navigate to
"192.168.1.1/index.htm"
Select the factory.bin image and upload
wait about 3 minutes
Return to OEM:
If you have a serial cable, see Serial Failsafe instructions
otherwise, uboot-env can be used to make uboot load the failsafe image
*DISCLAIMER*
The Failsafe image is unique to Engenius boards.
If the failsafe image is missing or damaged this will not work
DO NOT downgrade to ar71xx this way, it can cause kernel loop or halt
ssh into openwrt and run
`fw_setenv rootfs_checksum 0`
reboot, wait 3 minutes
connect to ethernet and navigate to 192.168.1.1/index.htm
select OEM firmware image from Engenius and click upgrade
Format of OEM firmware image:
The OEM software of ECB600 is a heavily modified version
of Openwrt Kamikaze. One of the many modifications
is to the sysupgrade program. Image verification is performed
simply by the successful ungzip and untar of the supplied file
and name check and header verification of the resulting contents.
To form a factory.bin that is accepted by OEM Openwrt build,
the kernel and rootfs must have specific names...
openwrt-senao-ecb600-uImage-lzma.bin
openwrt-senao-ecb600-root.squashfs
and begin with the respective headers (uImage, squashfs).
Then the files must be tarballed and gzipped.
The resulting binary is actually a tar.gz file in disguise.
This can be verified by using binwalk on the OEM firmware images,
ungzipping then untaring.
The OEM upgrade script is at /etc/fwupgrade.sh
Later models in the ECB series likely have a different platform
and the upgrade and image verification process differs.
OKLI kernel loader is required because the OEM software
expects the kernel to be no greater than 1536k
and the factory.bin upgrade procedure would
overwrite part of the kernel when writing rootfs.
Note on PLL-data cells:
The default PLL register values will not work
because of the external AR8035-A switch between
the SOC and the ethernet PHY chips.
For AR934x series, the PLL register for GMAC0
can be seen in the DTSI as 0x2c.
Therefore the PLL register can be read from uboot
for each link speed after attempting tftpboot
or another network action using that link speed
with `md 0x1805002c 1`.
Unfortunately uboot did not have the best values
so they were taken from other similar DTS files.
Tested from master, all link speeds functional
Signed-off-by: Michael Pratt <mcpratt@pm.me>
FCC ID: A8J-ECB350
Engenius ECB350 v1 is an indoor wireless access point with a gigabit ethernet port,
2.4 GHz wireless, external antennas, and PoE.
**Specification:**
- AR7242 SOC
- AR9283 WLAN 2.4 GHz (2x2), PCIe on-board
- AR8035-A switch RGMII, GbE with 802.3af PoE
- 40 MHz reference clock
- 8 MB FLASH 25L6406EM2I-12G
- 32 MB RAM
- UART at J2 (populated)
- 2 external antennas
- 3 LEDs, 1 button (power, lan, wlan) (reset)
**MAC addresses:**
MACs are labeled as WLAN and WAN
vendor MAC addresses in flash are duplicate
phy0 WLAN *:b8 ---
eth0 WAN *:b9 art 0x0/0x6
**Installation:**
- if you get Failsafe Mode from failed flash:
only use it to flash Original firmware from Engenius
or risk kernel loop or halt which requires serial cable
Method 1: Firmware upgrade page:
OEM webpage at 192.168.1.1
username and password "admin"
Navigate to "Firmware" page from left pane
Click Browse and select the factory.bin image
Upload and verify checksum
Click Continue to confirm and wait 3 minutes
Method 2: Serial to load Failsafe webpage:
After connecting to serial console and rebooting...
Interrupt uboot with any key pressed rapidly
execute `run failsafe_boot` OR `bootm 0x9f670000`
wait a minute
connect to ethernet and navigate to
"192.168.1.1/index.htm"
Select the factory.bin image and upload
wait about 3 minutes
**Return to OEM:**
If you have a serial cable, see Serial Failsafe instructions
otherwise, uboot-env can be used to make uboot load the failsafe image
*DISCLAIMER*
The Failsafe image is unique to Engenius boards.
If the failsafe image is missing or damaged this will not work
DO NOT downgrade to ar71xx this way, it can cause kernel loop or halt
ssh into openwrt and run
`fw_setenv rootfs_checksum 0`
reboot, wait 3 minutes
connect to ethernet and navigate to 192.168.1.1/index.htm
select OEM firmware image from Engenius and click upgrade
**TFTP recovery** (unstable / not reliable):
rename initramfs to 'vmlinux-art-ramdisk'
make available on TFTP server at 192.168.1.101
power board while holding or pressing reset button repeatedly
NOTE: for some Engenius boards TFTP is not reliable
try setting MTU to 600 and try many times
**Format of OEM firmware image:**
The OEM software of ECB350 v1 is a heavily modified version
of Openwrt Kamikaze. One of the many modifications
is to the sysupgrade program. Image verification is performed
by the successful ungzip and untar of the supplied file
and name check and header verification of the resulting contents.
To form a factory.bin that is accepted by OEM Openwrt build,
the kernel and rootfs must have specific names
and begin with the respective headers (uImage, squashfs).
Then the files must be tarballed and gzipped.
The resulting binary is actually a tar.gz file in disguise.
This can be verified by using binwalk on the OEM firmware images,
ungzipping then untaring.
The OEM upgrade script is at /etc/fwupgrade.sh.
OKLI kernel loader is required because the OEM software
expects the kernel size to be no greater than 1536k
and otherwise the factory.bin upgrade procedure would
overwrite part of the kernel when writing rootfs.
The factory upgrade script follows the original mtd partitions.
**Note on PLL-data cells:**
The default PLL register values will not work
because of the AR8035 switch between
the SOC and the ethernet port.
For AR724x series, the PLL register for GMAC0
can be seen in the DTSI as 0x2c.
Therefore the PLL register can be read from u-boot
for each link speed after attempting tftpboot
or another network action using that link speed
with `md 0x1805002c 1`
However the registers that u-boot sets are not ideal and sometimes wrong...
the at803x driver supports setting the RGMII clock/data delay on the PHY side.
This way the pll-data register only needs to handle invert and phase.
for this board no extra adjustements are needed on the MAC side
all link speeds functional
Signed-off-by: Michael Pratt <mcpratt@pm.me>
factory.bin was not tested for ECB1750...
but it was tested on it's sister board ECB1200
The product ID for the header can be verified by inspecting
the header of OEM images, or in the u-boot environment.
Also:
- the LAN LED is controlled directly by the AR8035 switch
- the labelled (first increment) MAC for both is ethaddr (eth0)
- list packages in alphabetical order
- use default sysupgrade.bin recipe
Signed-off-by: Michael Pratt <mcpratt@pm.me>
FCC ID: A8J-ECB1200
Engenius ECB1200 is an indoor wireless access point with a GbE port,
2.4 GHz and 5 GHz wireless, external antennas, and 802.3af PoE.
**Specification:**
- QCA9557 SOC MIPS, 2.4 GHz (2x2)
- QCA9882 WLAN PCIe card, 5 GHz (2x2)
- AR8035-A switch RGMII, GbE with 802.3af PoE, 25 MHz clock
- 40 MHz reference clock
- 16 MB FLASH 25L12845EMI-10G
- 2x 64 MB RAM 1538ZFZ V59C1512164QEJ25
- UART at JP1 (unpopulated, RX shorted to ground)
- 4 external antennas
- 4 LEDs, 1 button (power, eth, wifi2g, wifi5g) (reset)
**MAC addresses:**
MAC Addresses are labeled as ETH and 5GHZ
U-boot environment has the vendor MAC addresses
MAC addresses in ART do not match vendor
eth0 ETH *:5c u-boot-env ethaddr
phy0 5GHZ *:5d u-boot-env athaddr
---- ---- ???? art 0x0/0x6
**Installation:**
Method 1: Firmware upgrade page:
OEM webpage at 192.168.1.1
username and password "admin"
Navigate to "Firmware" page from left pane
Click Browse and select the factory.bin image
Upload and verify checksum
Click Continue to confirm and wait 3 minutes
Method 2: Serial to load Failsafe webpage:
After connecting to serial console and rebooting...
Interrupt uboot with any key pressed rapidly
(see TFTP recovery)
perform a sysupgrade
**Serial Access:**
the RX line on the board for UART is shorted to ground by resistor R176
therefore it must be removed to use the console
but it is not necessary to remove to view boot log
optionally, R175 can be replaced with a solder bridge short
the resistors R175 and R176 are next to the UART pinout at JP1
**Return to OEM:**
If you have a serial cable, see Serial Failsafe instructions
Unlike most Engenius boards, this does not have a 'failsafe' image
the only way to return to OEM is TFTP or serial access to u-boot
**TFTP recovery:**
Unlike most Engenius boards, TFTP is reliable here
rename initramfs-kernel.bin to 'ap.bin'
make the file available on a TFTP server at 192.168.1.10
power board while holding or pressing reset button repeatedly
or with serial access:
run `tftpboot` or `run factory_boot` with initramfs-kernel.bin
then `bootm` with the load address
**Format of OEM firmware image:**
The OEM software of ECB1200 is a heavily modified version
of Openwrt Altitude Adjustment 12.09.
This Engenius board, like ECB1750, uses a proprietary header
with a unique Product ID. The header for factory.bin is
generated by the mksenaofw program included in openwrt.
**Note on PLL-data cells:**
The default PLL register values will not work
because of the AR8035 switch between
the SOC and the ethernet port.
For QCA955x series, the PLL registers for eth0 and eth1
can be see in the DTSI as 0x28 and 0x48 respectively.
Therefore the PLL registers can be read from uboot
for each link speed after attempting tftpboot
or another network action using that link speed
with `md 0x18050028 1` and `md 0x18050048 1`.
However the registers that u-boot sets are not ideal and sometimes wrong...
the at803x driver supports setting the RGMII clock/data delay on the PHY side.
This way the pll-data register only needs to handle invert and phase.
for this board clock invert is needed on the MAC side
all link speeds functional
Signed-off-by: Michael Pratt <mcpratt@pm.me>
AirTight Networks (later renamed to Mojo Networks) C-75 is a dual-band
access point, also sold by WatchGuard under name AP320.
Specification
SoC: Qualcomm Atheros QCA9550
RAM: 128 MiB DDR2
Flash: 2x 16 MiB SPI NOR
WIFI: 2.4 GHz 3T3R integrated
5 GHz 3T3R QCA9890 oversized Mini PCIe card
Ethernet: 2x 10/100/1000 Mbps QCA8334
port labeled LAN1 is PoE capable (802.3at)
USB: 1x 2.0
LEDs: 7x which two are GPIO controlled, four switch controlled, one
controlled by wireless driver
Buttons: 1x GPIO controlled
Serial: RJ-45 port, Cisco pinout
baud: 115200, parity: none, flow control: none
JTAG: Yes, pins marked J1 on PCB
Installation
1. Prepare TFTP server with OpenWrt initramfs-kernel image.
2. Connect to one of LAN ports.
3. Connect to serial port.
4. Power on the device and when prompted to stop autoboot, hit any key.
5. Adjust "ipaddr" and "serverip" addresses in U-Boot environment, use
'setenv' to do that, then run following commands:
tftpboot 0x81000000 <openwrt_initramfs-kernel_image_name>
bootm 0x81000000
6. Wait about 1 minute for OpenWrt to boot.
7. Transfer OpenWrt sysupgrade image to /tmp directory and flash it
with:
sysupgrade -n /tmp/<openwrt_sysupgrade_image_name>
8. After flashing, the access point will reboot to OpenWrt. Wait few
minutes, until the Power LED stops blinking, then it's ready for
configuration.
Known issues
Green power LED does not work.
Additional information
The U-Boot fails to initialise ethernet ports correctly when a UART
adapter is attached to UART pins (marked J3 on PCB).
Cc: Vladimir Georgievsky <vladimir.georgievsky@yahoo.com>
Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
For:
- ENH202 v1
- ENS202EXT v1
These boards were committed before it was discovered
that for all Engenius boards with a "failsafe" image,
forcing the failsafe image to load next boot
can be achieved by editing the u-boot environment like:
`fw_setenv rootfs_checksum 0`
So it's not necessary to delete a partition to boot to failsafe image.
Signed-off-by: Michael Pratt <mcpratt@pm.me>
It is good practice to define device tree files based on specific
SoCs. Thus, let's not start to create files that are used across
different architectures.
Duplicate the DTSI file for D-Link DAP-2xxx in order to have one
for qca953x and one for qca955x, respectively.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The device is a one-port, but was set up as two-port by the
default case in 02_network. Fix it.
Signed-off-by: Sebastian Schaper <openwrt@sebastianschaper.net>
[commit title/message facelift]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Specifications:
* QCA9533, 16 MiB Flash, 64 MiB RAM, 802.11n 2T2R
* 10/100 Ethernet Port, 802.11af PoE
* IP55 pole-mountable outdoor case
Installation:
* Factory Web UI is at 192.168.0.50
login with 'admin' and blank password, flash factory.bin
* Recovery Web UI is at 192.168.0.50
connect network cable, hold reset button during power-on and keep it
pressed until uploading has started (only required when checksum is ok,
e.g. for reverting back to oem firmware), flash factory.bin
After flashing factory.bin, additional free space can be reclaimed by
flashing sysupgrade.bin, since the factory image requires some padding
to be accepted for upgrading via OEM Web UI.
Signed-off-by: Sebastian Schaper <openwrt@sebastianschaper.net>
Specifications:
* QCA9558, 16 MiB Flash, 256 MiB RAM, 802.11n 3T3R
* QCA9984, 802.11ac Wave 2 3T3R
* Gigabit LAN Port (AR8035), 802.11at PoE
Installation:
* Factory Web UI is at 192.168.0.50
login with 'admin' and blank password, flash factory.bin
* Recovery Web UI is at 192.168.0.50
connect network cable, hold reset button during power-on and keep it
pressed until uploading has started (only required when checksum is ok,
e.g. for reverting back to oem firmware), flash factory.bin
After flashing factory.bin, additional free space can be reclaimed by
flashing sysupgrade.bin, since the factory image requires some padding
to be accepted for upgrading via OEM Web UI.
Signed-off-by: Sebastian Schaper <openwrt@sebastianschaper.net>
Specifications:
* QCA9533, 16 MiB Flash, 64 MiB RAM, 802.11n 2T2R
* 10/100 Ethernet Port, 802.11af PoE
Installation:
* Factory Web UI is at 192.168.0.50
login with 'admin' and blank password, flash factory.bin
* Recovery Web UI is at 192.168.0.50
connect network cable, hold reset button during power-on and keep it
pressed until uploading has started (only required when checksum is ok,
e.g. for reverting back to oem firmware), flash factory.bin
After flashing factory.bin, additional free space can be reclaimed by
flashing sysupgrade.bin, since the factory image requires some padding
to be accepted for upgrading via OEM Web UI.
Signed-off-by: Sebastian Schaper <openwrt@sebastianschaper.net>
The phy label/node name should correspond to the reg property.
While at it, use more common decimal notation for reg property itself.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This patch was backported to the 5.4 kernel tree as commit
c2d5c4df27e0 at least since release v5.4.28. Since then, it enables RX
an TX ready override twice.
Signed-off-by: David Bauer <mail@david-bauer.net>
Device specifications:
======================
* Qualcomm/Atheros AR9344 rev 2
* 560/450/225 MHz (CPU/DDR/AHB)
* 64 MB of RAM
* 16 MB of SPI NOR flash
- 2x 7 MB available; but one of the 7 MB regions is the recovery image
* 2x 10/100 Mbps Ethernet
* 2T2R 5 GHz Wi-Fi
* 6x GPIO-LEDs (3x wifi, 2x ethernet, 1x power)
* 1x GPIO-button (reset)
* external h/w watchdog (enabled by default)
* TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX)
* 2x fast ethernet
- eth0
+ builtin switch port 1
+ used as LAN interface
- eth1
+ 18-24V passive POE (mode B)
+ used as WAN interface
* 12-24V 1A DC
* internal antennas
WAN/LAN LEDs appear to be wrong in ar71xx and have been swapped here.
Flashing instructions:
======================
Various methods can be used to install the actual image on the flash.
Two easy ones are:
ap51-flash
----------
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the image to the u-boot when the device boots up.
initramfs from TFTP
-------------------
The serial console must be used to access the u-boot shell during bootup.
It can then be used to first boot up the initramfs image from a TFTP server
(here with the IP 192.168.1.21):
setenv serverip 192.168.1.21
setenv ipaddr 192.168.1.1
tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr
The actual sysupgrade image can then be transferred (on the LAN port) to the
device via
scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/
On the device, the sysupgrade must then be started using
sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin
Signed-off-by: Sven Eckelmann <sven@narfation.org>
[add LED swap comment]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Device specifications:
======================
* Qualcomm/Atheros AR9330 rev 1
* 400/400/200 MHz (CPU/DDR/AHB)
* 64 MB of RAM
* 16 MB of SPI NOR flash
- 2x 7 MB available; but one of the 7 MB regions is the recovery image
* 2x 10/100 Mbps Ethernet
* 1T1R 2.4 GHz Wi-Fi
* 6x GPIO-LEDs (3x wifi, 2x ethernet, 1x power)
* 1x GPIO-button (reset)
* external h/w watchdog (enabled by default)
* TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX)
* 2x fast ethernet
- eth0
+ builtin switch port 1
+ used as LAN interface
- eth1
+ 18-24V passive POE (mode B)
+ used as WAN interface
* 12-24V 1A DC
* external antenna
Flashing instructions:
======================
Various methods can be used to install the actual image on the flash.
Two easy ones are:
ap51-flash
----------
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the image to the u-boot when the device boots up.
initramfs from TFTP
-------------------
The serial console must be used to access the u-boot shell during bootup.
It can then be used to first boot up the initramfs image from a TFTP server
(here with the IP 192.168.1.21):
setenv serverip 192.168.1.21
setenv ipaddr 192.168.1.1
tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr
The actual sysupgrade image can then be transferred (on the LAN port) to
the device via
scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/
On the device, the sysupgrade must then be started using
sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Device specifications:
======================
* Qualcomm/Atheros AR9330 rev 1
* 400/400/200 MHz (CPU/DDR/AHB)
* 64 MB of RAM
* 16 MB of SPI NOR flash
- 2x 7 MB available; but one of the 7 MB regions is the recovery image
* 2x 10/100 Mbps Ethernet
* 1T1R 2.4 GHz Wi-Fi
* 6x GPIO-LEDs (3x wifi, 2x ethernet, 1x power)
* 1x GPIO-button (reset)
* external h/w watchdog (enabled by default)
* TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX)
* 2x fast ethernet
- eth0
+ builtin switch port 1
+ used as LAN interface
- eth1
+ 18-24V passive POE (mode B)
+ used as WAN interface
* 12-24V 1A DC
* internal antennas
Flashing instructions:
======================
Various methods can be used to install the actual image on the flash.
Two easy ones are:
ap51-flash
----------
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the image to the u-boot when the device boots up.
initramfs from TFTP
-------------------
The serial console must be used to access the u-boot shell during bootup.
It can then be used to first boot up the initramfs image from a TFTP server
(here with the IP 192.168.1.21):
setenv serverip 192.168.1.21
setenv ipaddr 192.168.1.1
tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr
The actual sysupgrade image can then be transferred (on the LAN port) to
the device via
scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/
On the device, the sysupgrade must then be started using
sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Device specifications:
======================
* Qualcomm/Atheros AR9341 rev 1
* 535/400/200 MHz (CPU/DDR/AHB)
* 64 MB of RAM
* 16 MB of SPI NOR flash
- 2x 7 MB available; but one of the 7 MB regions is the recovery image
* 2x 10/100 Mbps Ethernet
* 2T2R 2.4 GHz Wi-Fi
* 6x GPIO-LEDs (3x wifi, 2x ethernet, 1x power)
* 1x GPIO-button (reset)
* external h/w watchdog (enabled by default)
* TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX)
* 2x fast ethernet
- eth0
+ 802.3af POE
+ builtin switch port 1
+ used as LAN interface
- eth1
+ 18-24V passive POE (mode B)
+ used as WAN interface
* 12-24V 1A DC
* internal antennas
Flashing instructions:
======================
Various methods can be used to install the actual image on the flash.
Two easy ones are:
ap51-flash
----------
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the image to the u-boot when the device boots up.
initramfs from TFTP
-------------------
The serial console must be used to access the u-boot shell during bootup.
It can then be used to first boot up the initramfs image from a TFTP server
(here with the IP 192.168.1.21):
setenv serverip 192.168.1.21
setenv ipaddr 192.168.1.1
tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr
The actual sysupgrade image can then be transferred (on the LAN port) to
the device via
scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/
On the device, the sysupgrade must then be started using
sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Device specifications:
======================
* Qualcomm/Atheros AR9341 rev 1
* 535/400/200 MHz (CPU/DDR/AHB)
* 64 MB of RAM
* 16 MB of SPI NOR flash
- 2x 7 MB available; but one of the 7 MB regions is the recovery image
* 2x 10/100 Mbps Ethernet
* 2T2R 2.4 GHz Wi-Fi
* 6x GPIO-LEDs (3x wifi, 2x ethernet, 1x power)
* 1x GPIO-button (reset)
* external h/w watchdog (enabled by default)
* TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX)
* 2x fast ethernet
- eth0
+ 802.3af POE
+ builtin switch port 1
+ used as LAN interface
- eth1
+ 18-24V passive POE (mode B)
+ used as WAN interface
* 12-24V 1A DC
* internal antennas
Flashing instructions:
======================
Various methods can be used to install the actual image on the flash.
Two easy ones are:
ap51-flash
----------
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the image to the u-boot when the device boots up.
initramfs from TFTP
-------------------
The serial console must be used to access the u-boot shell during bootup.
It can then be used to first boot up the initramfs image from a TFTP server
(here with the IP 192.168.1.21):
setenv serverip 192.168.1.21
setenv ipaddr 192.168.1.1
tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr
The actual sysupgrade image can then be transferred (on the LAN port) to
the device via
scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/
On the device, the sysupgrade must then be started using
sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Device specifications:
======================
* Qualcomm/Atheros AR9341 rev 1
* 535/400/200 MHz (CPU/DDR/AHB)
* 64 MB of RAM
* 16 MB of SPI NOR flash
- 2x 7 MB available; but one of the 7 MB regions is the recovery image
* 2x 10/100 Mbps Ethernet
* 2T2R 2.4 GHz Wi-Fi
* 6x GPIO-LEDs (3x wifi, 2x ethernet, 1x power)
* 1x GPIO-button (reset)
* external h/w watchdog (enabled by default)
* TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX)
* 2x fast ethernet
- eth0
+ 802.3af POE
+ builtin switch port 1
+ used as LAN interface
- eth1
+ 18-24V passive POE (mode B)
+ used as WAN interface
* 12-24V 1A DC
* internal antennas
Flashing instructions:
======================
Various methods can be used to install the actual image on the flash.
Two easy ones are:
ap51-flash
----------
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the image to the u-boot when the device boots up.
initramfs from TFTP
-------------------
The serial console must be used to access the u-boot shell during bootup.
It can then be used to first boot up the initramfs image from a TFTP server
(here with the IP 192.168.1.21):
setenv serverip 192.168.1.21
setenv ipaddr 192.168.1.1
tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr
The actual sysupgrade image can then be transferred (on the LAN port) to
the device via
scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/
On the device, the sysupgrade must then be started using
sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin
Signed-off-by: Sven Eckelmann <sven@narfation.org>
[drop redundant status from eth1]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The upgrade script for the openmesh sysupgrade procedure used always an 1
byte block size. This made it easier to seek the correct position in the CE
image and to make sure the right amount of data was copied. But this also
meant that the reading/writing of data required an excessive amount of
syscalls and copy operations.
A 5.4MB big sysupgrade image on an OM2P-HS v3 needed roughly 120s for the
write operation (170s in total) during the sysupgrade.
But it is possible to reduce this overhead slightly:
* index access to read the file size can be done in single 8 byte chunk
(while doing the seek with byte granularity) because each size entry is
example 8 bytes long
* the fwupgrade.cfg can be read as one block (while seeking to its position
using its actual byte offset) because it should be rather small and fit
into the RAM easily
* the kernel can be read in 1KB blocks (while seking to its positions using
its actual byte offset) because the the size of the kernel is always a
multiple of the NOR flash block size (64KB and 256KB)
This results in a sysupgrade write time of roughly 90s (140s in total).
This could be reduced even further when also using larger chunks for the
rootfs. But the squashfs rootfs image is at the moment always
(256KB or 64KB) * block + 4 bytes
long. It would be expected that the time for the sysupgrade write could be
reduced to roughly 30s (80s in total) when busybox's dd would support
the iflag count_bytes.
Reported-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Device specifications:
======================
* Qualcomm/Atheros QCA9533 v2
* 650/600/217 MHz (CPU/DDR/AHB)
* 64 MB of RAM
* 16 MB of SPI NOR flash
- 2x 7 MB available; but one of the 7 MB regions is the recovery image
* 2x 10/100 Mbps Ethernet
* 2T2R 2.4 GHz Wi-Fi
* 6x GPIO-LEDs (3x wifi, 2x ethernet, 1x power)
* 1x GPIO-button (reset)
* external h/w watchdog (enabled by default)
* TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX)
* 2x fast ethernet
- eth0
+ 24V passive POE (mode B)
+ used as WAN interface
- eth1
+ 802.3af POE
+ builtin switch port 1
+ used as LAN interface
* 12-24V 1A DC
* internal antennas
Flashing instructions:
======================
Various methods can be used to install the actual image on the flash.
Two easy ones are:
ap51-flash
----------
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the image to the u-boot when the device boots up.
initramfs from TFTP
-------------------
The serial console must be used to access the u-boot shell during bootup.
It can then be used to first boot up the initramfs image from a TFTP server
(here with the IP 192.168.1.21):
setenv serverip 192.168.1.21
setenv ipaddr 192.168.1.1
tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr
The actual sysupgrade image can then be transferred (on the LAN port) to
the device via
scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/
On the device, the sysupgrade must then be started using
sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Device specifications:
======================
* Qualcomm/Atheros QCA9533 v2
* 650/600/217 MHz (CPU/DDR/AHB)
* 64 MB of RAM
* 16 MB of SPI NOR flash
- 2x 7 MB available; but one of the 7 MB regions is the recovery image
* 2x 10/100 Mbps Ethernet
* 1T1R 2.4 GHz Wi-Fi
* 6x GPIO-LEDs (3x wifi, 2x ethernet, 1x power)
* 1x GPIO-button (reset)
* external h/w watchdog (enabled by default)
* TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX)
* 2x fast ethernet
- eth0
+ Label: Ethernet 1
+ 24V passive POE (mode B)
- eth1
+ Label: Ethernet 2
+ 802.3af POE
+ builtin switch port 1
* 12-24V 1A DC
* external antenna
Flashing instructions:
======================
Various methods can be used to install the actual image on the flash.
Two easy ones are:
ap51-flash
----------
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the image to the u-boot when the device boots up.
initramfs from TFTP
-------------------
The serial console must be used to access the u-boot shell during bootup.
It can then be used to first boot up the initramfs image from a TFTP server
(here with the IP 192.168.1.21):
setenv serverip 192.168.1.21
setenv ipaddr 192.168.1.1
tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr
The actual sysupgrade image can then be transferred (on the LAN port) to
the device via
scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/
On the device, the sysupgrade must then be started using
sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin
Signed-off-by: Sven Eckelmann <sven@narfation.org>
[wrap two very long lines, fix typo in comment]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
sysupgrade.bin has been added to IMAGES twice, resulting in
warnings like:
Makefile:86: warning: overriding recipe for target
'[...]/tmp/openwrt-ath79-generic-dlink_dap-2660-a1-squashfs-sysupgrade.bin'
Makefile:86: warning: ignoring old recipe for target
'[...]/tmp/openwrt-ath79-generic-dlink_dap-2660-a1-squashfs-sysupgrade.bin'
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The current support for MikroTik NAND-based devices relies on a
gross hack that packs the kernel into a static YAFFS stub, as the
stock bootloader only supports booting a YAFFS-encapsulated kernel.
The problem with this approach is that since the kernel partition is
blindly overwritten without any kind of wear or badblock management
(due to lack of proper support for YAFFS in OpenWRT), the NAND flash
is not worn uniformly and eventually badblocks appear, leading to
unbootable devices.
Until a proper fix is found (or the stock bootloader supports other
filesystems), we disable building these images to prevent unknowing
users from risking their devices.
Thanks to Thibaut Varène for summarizing the details above.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
