Netgear R6100 is a dual-band Wi-Fi 5 (AC1200) router based on Qualcomm
Atheros (AR9344 + QCA9882) platform. Support for this device was first
introduced in 15f6f67d18 (ar71xx). FCC ID: PY312400225.
Specifications:
- Atheros AR9344 (560 MHz)
- 128 MB of RAM (DDR2)
- 128 MB of flash (parallel NAND)
- 2T2R 2.4 GHz Wi-Fi (AR9344)
- 2T2R 5 GHz Wi-Fi (QCA9882)
- 5x 10/100 Mbps Ethernet (AR9344)
- 4x internal antenna
- 1x USB 2.0 (GPIO-controlled power)
- 6x LED, 3x button (reset, Wi-Fi, WPS)
- UART (4-pin, 2.54 mm pitch) header on PCB
- 1x mechanical power switch
- DC jack for main power input (12 V)
WARNING: sysupgrade from older stable releases is not possible, fresh
installation (via vendor's GUI or TFTP based recovery) is required.
Reason for that is increased kernel partition size.
Installation:
Use the 'factory' image under vendor's GUI or via TFTP U-Boot recovery.
You can use the 'nmrpflash' tool at a boot time, before kernel is loaded
or start it manually by pressing the 'reset' button for ~20 seconds from
powering up the device (U-Boot will start TFTP server on 192.168.1.1,
use TFTP client to send the image).
Signed-off-by: Enrico Mioso <mrkiko.rs@gmail.com>
Signed-off-by: Zoltan HERPAI <wigyori@uid0.hu>
Signed-off-by: Michael Pratt <mcpratt@pm.me>
Signed-off-by: Piotr Dymacz <pepe2k@gmail.com>
Dongwon T&I DW02-412H is a 2.4/5GHz band 11ac (WiFi-5) router, based on
Qualcomm Atheros QCA9557.
Specifications
--------------
- SoC: Qualcomm Atheros QCA9557-AT4A
- RAM: DDR2 128MB
- Flash: SPI NOR 2MB (Winbond W25Q16DVSSIG / ESMT F25L16PA(2S)) +
NAND 64/128MB
- WiFi:
- 2.4GHz: QCA9557 WMAC
- 5GHz: QCA9882-BR4A
- Ethernet: 5x 10/100/1000Mbps
- Switch: QCA8337N-AL3C
- USB: 1x USB 2.0
- UART:
- JP2: 3.3V, TX, RX, GND (3.3V is the square pad) / 115200 8N1
Installation
--------------
1. Connect a serial interface to UART header and
interrupt the autostart of kernel.
2. Transfer the factory image via TFTP and write it to the NAND flash.
3. Update U-Boot environment variable.
> tftpboot 0x81000000 <your image>-factory.img
> nand erase 0x1000000
> nand write 0x81000000 0x1000000 ${filesize}
> setenv bootpart 2
> saveenv
Revert to stock firmware
--------------
1. Revert to stock U-Boot environment variable.
> setenv bootpart 1
> saveenv
MAC addresses as verified by OEM firmware
--------------
WAN: *:XX (label)
LAN: *:XX + 1
2.4G: *:XX + 3
5G: *:XX + 4
The label MAC address was found in art 0x0.
Credits
--------------
Credit goes to the @manatails who first developed how to port OpenWRT
to this device and had a significant impact on this patch.
And thanks to @adschm and @mans0n for guiding me to revise the code
in many ways.
Signed-off-by: Jihoon Han <rapid_renard@renard.ga>
Reviewed-by: Sungbo Eo <mans0n@gorani.run>
Tested-by: Sungbo Eo <mans0n@gorani.run>
So far, board.d files were having execute bit set and contained a
shebang. However, they are just sourced in board_detect, with an
apparantly unnecessary check for execute permission beforehand.
Replace this check by one for existance and make the board.d files
"normal" files, as would be expected in /etc anyway.
Note:
This removes an apparantly unused '#!/bin/sh /etc/rc.common' in
target/linux/bcm47xx/base-files/etc/board.d/01_network
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Currently, we request LED labels in OpenWrt to follow the scheme
modelname:color:function
However, specifying the modelname at the beginning is actually
entirely useless for the devices we support in OpenWrt. On the
contrary, having this part actually introduces inconvenience in
several aspects:
- We need to ensure/check consistency with the DTS compatible
- We have various exceptions where not the model name is used,
but the vendor name (like tp-link), which is hard to track
and justify even for core-developers
- Having model-based components will not allow to share
identical LED definitions in DTSI files
- The inconsistency in what's used for the model part complicates
several scripts, e.g. board.d/01_leds or LED migrations from
ar71xx where this was even more messy
Apart from our needs, upstream has deprecated the label property
entirely and introduced new properties to specify color and
function properties separately. However, the implementation does
not appear to be ready and probably won't become ready and/or
match our requirements in the foreseeable future.
However, the limitation of generic LEDs to color and function
properties follows the same idea pointed out above. Generic LEDs
will get names like "green:status" or "red:indicator" then, and
if a "devicename" is prepended, it will be the one of an internal
device, like "phy1:amber:status".
With this patch, we move into the same direction, and just drop
the boardname from the LED labels. This allows to consolidate
a few definitions in DTSI files (will be much more on ramips),
and to drop a few migrations compared to ar71xx that just changed
the boardname. But mainly, it will liberate us from a completely
useless subject to take care of for device support review and
maintenance.
To also drop the boardname from existing configurations, a simple
migration routine is added unconditionally.
Although this seems unfamiliar at first look, a quick check in kernel
for the arm/arm64 dts files revealed that while 1033 lines have
labels with three parts *:*:*, still 284 actually use a two-part
labelling *:*, and thus is also acceptable and not even rare there.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This patch adds support for the WNDR4300SW, marketed by California ISP
SureWest (hence the 'SW' suffix). Hardware wise, it's identical to the
WNDR4300 v1.
Specifications:
* SoC: Atheros AR9344
* RAM: 128 MB
* Flash: 128 MB NAND flash
* WiFi: Atheros AR9580 (5 GHz) and AR9344 (2,4 GHz)
* Ethernet: 5x 1000Base-T
* LED: Power, WAN, LAN, WiFi, USB, WPS
* UART: on board, to the right of the RF shield at the top of the board
Installation:
* Flashing through the OEM web interface:
+ Connect your computer to the router with an ethernet cable and browse
to http://192.168.1.1/
+ Log in with the default credentials are admin:password
+ Browse to Advanced > Administration > Firmware Upgrade in the Netgear
interface
+ Upload the Openwrt firmware: openwrt-ath79-nand-netgear_wndr4300sw-squashfs-factory.img
+ Proceed with the firmware installation and give the device a few
minutes to finish and reboot.
* Flashing through TFTP:
+ Configure your wired client with a static IP in the 192.168.1.x range,
e.g. 192.168.1.10 and netmask 255.255.255.0.
+ Power off the router.
+ Press and hold the RESET button (the factory reset button on the bottom
of the device, with the red circle around it) and turn the router on
while keeping the button pressed.
+ The power LED will start flashing orange. You can release the button
once it switches to flashing green.
+ Transfer the image over TFTP:
$ tftp 192.168.1.1 -m binary -c put openwrt-ath79-nand-netgear_wndr4300sw-squashfs-factory.img
Signed-off-by: Stijn Segers <foss@volatilesystems.org>
This patch introduces support for Netgear WNDR4500v3. Router
is very similar to WNDR4300v2 and is based on the same PCB.
Information gathered from various Internet sources (including
https://patchwork.ozlabs.org/patch/809227/) shows following
differences to WNDR4300v2:
* two USB 2.0 ports with separate LEDs
* USB LEDs soldered to secondary pads
* WPS and RFKILL buttons soldered to secondary pads
* described as N900 device with 3x3:3 MIMO for 2.4GHz radio
* power supply requirement is DC 12V 2.5A
* vendor HW ID suffix differs in one digit
* bigger chassis
Signed-off-by: Michal Cieslakiewicz <michal.cieslakiewicz@wp.pl>
This patch introduces support for Netgear WNDR4300v2.
Specification
=============
* Description: Netgear WNDR4300 v2
* Loader: U-boot
* SOC: Qualcomm Atheros QCA9563 (775 MHz)
* RAM: 128 MiB
* Flash: 2 MiB SPI-NOR + 128 MiB SPI-NAND
- NOR: U-boot binary: 256 KiB
- NOR: U-boot environment: 64 KiB
- NOR: ART Backup: 64 KiB
- NOR: Config: 64 KiB
- NOR: Traffic Meter: 64 KiB
- NOR: POT: 64 KiB
- NOR: Reserved: 1408 KiB
- NOR: ART: 64 KiB
- NAND: Firmware: 25600 KiB (see notes for OpenWrt)
- NAND: Language: 2048 KiB
- NAND: mtdoops Crash Dump: 128 KiB
- NAND: Reserved: 103296 KiB
* Ethernet: 5 x 10/100/1000 (4 x LAN, 1 x WAN) (AR8337)
* Wireless:
- 2.4 GHz b/g/n (internal)
- 5 GHz a/n (AR9580)
* USB: yes, 1 x USB 2.0
* Buttons:
- Reset
- WiFi (rfkill)
- WPS
* LEDs:
- Power (amber/green)
- WAN (amber/green)
- WLAN 2G (green)
- WLAN 5G (blue)
- 4 x LAN (amber/green)
- USB (green)
- WPS (green)
* UART: 4-pin connector JP1, 3.3V (Vcc, TX, RX, GND), 115200 8N1
* Power supply: DC 12V 1.5A
* MAC addresses: LAN=WLAN2G on case label, WAN +1, WLAN5G +2
Important Notes
===============
0. NOR Flash (2 MiB) is not touched by OpenWrt installation.
1. NAND Flash (128 MiB) layout under OpenWrt is changed as follows:
all space is split between 4 MiB kernel and 124 MiB UBI areas;
vendor partitions (language and mtdoops) are removed; kernel space
size can be further expanded if needed; maximum image size is set
to 25600k for compatibility reasons and can also be increased.
2. CPU clock is 775 MHz, not 750 MHz.
3. 5 GHz wireless radio chip is Atheros AR9580-AR1A with bogus PCI
device ID 0xabcd. For ath9k driver to load successfully, this is
overriden in DTS with correct value for this chip, 0x0033.
4. RFKILL button is wired to AR9580 pin 9 which is normally disabled
by chip definition in ath9k code (0x0000F4FF gpio mask). Therefore
'qca,gpio-mask=<0xf6ff>' hack must be used for button to work
properly.
5. USB port is always on, no GPIO for 5V power control has been
identified.
Installation
============
* TFTP recovery
* TFTP via U-boot prompt
* sysupgrade
* Web interface
Test build configuration
========================
CONFIG_TARGET_ath79=y
CONFIG_TARGET_ath79_nand=y
CONFIG_TARGET_ath79_nand_DEVICE_netgear_wndr4300-v2=y
CONFIG_ALL_KMODS=y
CONFIG_DEVEL=y
CONFIG_CCACHE=y
CONFIG_COLLECT_KERNEL_DEBUG=y
CONFIG_IMAGEOPT=y
Signed-off-by: Michal Cieslakiewicz <michal.cieslakiewicz@wp.pl>
The GL.iNet GL-AR300M has been supported by the ar71xx and ath79
platforms with access to its 16 MB NOR flash, but not its 128 MB
SPI NAND flash.
This commit provides support for the NAND through the upstream
SPI-NAND framework. Devices with both NOR and NAND flash can support
independent firmware on each, with U-Boot able to boot from either.
The OEM U-Boot will fall back to the NOR firmware after three
"unsuccessful" boots.
The family of GL-AR300M devices on the ath79 platform now includes:
* glinet,gl-ar300m-lite "generic" target, NOR-only board
* glinet,gl-ar300m-nand "nand" target
* glinet,gl-ar300m-nor "nand" target (NAND-aware)
NB: This commit increases the kernel size from 2 MB to 4 MB
"Force-less" sysupgrade is presently supported from the current
versions of following NOR-based firmwre images to the version of
glinet,gl-ar300m-nor firmware produced by this commit:
* gl-ar300m -- OEM v3 NOR ar71xx (openwrt-ar300m16-*.bin)
* gl-ar300m -- OpenWrt 18.06 ar71xx
* gl-ar300m -- OpenWrt 19.07 ar71xx
Other upgrades to these images should be performed through U-Boot.
The GL-AR300M OEM U-Boot allows upload and flashing of either NOR
firmware (sysupgrade.bin) or NAND firmware (factory.img) through its
HTTP-based GUI. Serial connectivity is not required.
The glinet,gl-ar300m-nand and glinet,gl-ar300m-nor images generated
after this commit should safely flash each other using sysupgrade.
The boot counter is implemented by the OEM using u-boot-env. At this
time, it does not appear that the switch on the side of the unit can
be used to select NOR vs. NAND boot and the fail-over is only from
NAND to NOR. To save flash wear, it is only reset when running the
glinet,gl-ar300m-nand firmware.
NAND-specific base-files are used to remove impact on existing
generic and tiny targets.
As there is now no "generic" build appropriate for the GL-AR300M16,
(or for users of the GL-AR300M that do not need access to NAND)
it will be introduced in a subsequent commit.
Note: `mtd_get_mac_binary art 0x6` does not return the proper MAC
and the GL.iNet source indicates that only the 0x0 offset is valid
The ar71xx targets are unmodified.
Signed-off-by: Jeff Kletsky <git-commits@allycomm.com>
While most of the target's contents are split into subtargets, the
base-files are maintained for the target as a whole.
However, OpenWrt already implements a mechanism that will use (and
even prefer) files in the subtargets' directories. This can be
exploited to make several scripts subtarget-specific and thus save
some space (especially helpful for the tiny devices).
The only script remaining in parent base-files is
/etc/hotplug.d/ieee80211/00-wifi-migration, everything else is
moved/split.
Note that this will increase overall code lines, but reduce code
per subtarget.
base-files ipk size reduction:
master (generic) 49135 B
split (generic) 48533 B (- 0.6 kiB)
split (tiny) 43337 B (- 5.7 kiB)
split (nand) 44423 B (- 4.6 kiB)
Tested on TL-WR1043ND v4 (generic) and TL-WR841N v12 (tiny).
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
