Specifications:
- CPU: MediaTek MT7628AN (580MHz)
- Flash: 16MB
- RAM: 64MB DDR2
- 2.4 GHz: IEEE 802.11b/g/n with Integrated LNA and PA
- Antennas: 4x external single band antennas
- WAN: 1x 10/100M
- LAN: 2x 10/100M
- LEDs: 2x yellow/blue. Programmable (labelled as power on case)
- Non-programmable (shows WAN activity)
- Button: Reset
How to install:
1- Use OpenWRTInvasion to gain telnet and ftp access.
2- Push openwrt firmware to /tmp/ using ftp.
3- Connect to router using telnet. (IP: 192.168.31.1 -
Username: root - No password)
4- Use command "mtd -r write /tmp/firmware.bin OS1" to flash into
the router..
5- It takes around 2 minutes. After that router will restart itself
to OpenWrt.
Specifications:
- SoC: MediaTek MT7621
- Flash: 16 MiB NOR SPI
- RAM: 128 MiB DDR3
- Ethernet: 3x 10/100/1000 Mbps (switched, 2xLAN + WAN)
- WIFI0: MT7603E 2.4GHz 802.11b/g/n
- WIFI1: MT7612E 5GHz 802.11ac
- Antennas: 4x external (2 per radio), non-detachable
- LEDs: Programmable "power" LED (two-coloured, yellow/blue)
Non-programmable "internet" LED (shows WAN activity)
- Buttons: Reset
Installation:
Bootloader won't accept any serial input unless "boot_wait" u-boot
environment variable is changed to "on".
Vendor firmware won't accept any serial input until "uart_en" is
set to "1".
Using the https://github.com/acecilia/OpenWRTInvasion exploit you
can gain access to shell to enable these options:
To enable uart keyboard actions - 'nvram set uart_en=1'
To make uboot delay boot work - 'nvram set boot_wait=on'
Set boot delay to 5 - 'nvram set bootdelay=5'
Then run 'nvram commit' to make the changes permanent.
Once in the shell (following the OpenWRTInvasion instructions) you
can then run the following to flash OpenWrt and then reboot:
'cd /tmp; curl https://downloads.openwrt.org/...-sysupgrade.bin
--output firmware.bin; mtd -e OS1 -r write firmware.bin OS1'
All targets now use OpenWrt device abstraction. Thus, all targets now
can be built using a per-device RootFS.
Signed-off-by: David Bauer <mail@david-bauer.net>
Upstream removed the factory images for the Archer C20 v1 as they
potentially brick the device. Remove them from Gluon to avoid build
failures on the next OpenWrt 19.07 bump.
Signed-off-by: David Bauer <mail@david-bauer.net>
This device is a dual 5GHz device. It is recommended to manually change the
radio of the first device to the lower 5GHz channels and the second radio
to the upper 5GHz channels
Use a manifest alias for the autoupdater image string of the Netgear
EX3700 / EX3800. This way, no unnecessary symlink is created and the
autoupdater functionality is preserved.
* ar71xx-generic: only create manifest alias for Rocket M5
This follow up the discussion done in #2070 by not creating a symlink
for the Rocket M5. Images for the Rocket M2 can still be flashed on a
Rocket M5.
This change will prevent the Rocket M5 from appearing in Firmware
selectors. Existing devices will still receive updates, as the device
name is still referenced for the device name expected by the M5.
Closes#2070
* docs: remove Rocket M5 from supported devices
Specifications:
* SoC: MT7620A
* RAM: 64 MB DDR
* Flash: 8MB NOR SPI flash
* WiFi: MT7612E (5Ghz) and builtin MT7620A (2.4GHz)
* LAN: 1x100M
The -factory images can be flashed from the device's web
interface or via nmrpflash.
Both devices differ by a additional power outlet for the EX3800.
This patch has been tested on a EX3800 device.
The new options are CONFIG_GLUON_AUTOUPDATER_BRANCH and
CONFIG_GLUON_AUTOUPDATER_ENABLED and allow to control the default branch
and default enable status separately.
The `or ''` fallback in targets/generic is removed, as GLUON_ENV will
set all variables in GLUON_VARS, making previously non-existing
variables exist with an empty value.
The packages necessary to get the DSL modem working increase the
squashfs size by around 1MB.
Remove them from Gluon, as this functionality is not supported.
Normally, we build all nonshared packages (which includes all kernel
modules) to generate an opkg feed for later package installations by
users. On targets without opkg, this just wastes time - disable it.
This change stores a Kernel with Debug-Symbols for the current
architecture in a new output directory '<outputdir>/debug'.
This allows a developer or operator of a network to store the kernel
along with the actual images. In case of a kernel oops the debug
information can be used with the script
'scripts/decode_stacktrace.sh' in the kernel source tree to get the
names to the symbols of the stack trace.
OpenWRT already provides the CONFIG_COLLECT_KERNEL_DEBUG -option that
creates a kernel with debug-symbols in the OpenWRT output directory.
This change enables this option and copies the generated kernel to the
gluon output directory.
Signed-off-by: Chrissi^ <chris@tinyhost.de>
target_config.lua and target_config_check.lua don't pass a table of
callbacks anymore, so target_config_lib.lua can by simplified by moving
all the code that was in the returned function to the toplevel.
So far, we were using a sort operation on the generated .config to
implement precedence of =y packages over =m, and =m over unset.
Unfortunately, this sort not only used for packages, but for all config
lines. This made it impossible to override settings from targets/generic
in a target config when the new setting was sorted before the generic
setting.
To fix this, track configurations by their keys, so we can properly
override config keys that were set before. Value-based precedence is
only preserved for package configuration.
The config() and try_config() calls always take key and value as
separate arguments now. Strings are quoted automatically; the values
true, nil and false map to y, m and unset for tristate options. config()
can take an optional third argument to override the error message to
display when the setting fails to apply.
All existing target configs generate the same .config with the old and the
new code. The new code is also a bit faster on targets with many devices.
In OpenWrt 19.07, the block size was increased to 1024KiB for "tiny"
devices by default to save flash. Unfortunately, this also significantly
increases the cache memory required by squashfs.
In my test, the increased block size reduced the image size by ~64KiB,
but increased the RAM usage by ~2.6MiB. As most tiny devices have only
32MiB of RAM, this is not a reasonable tradeoff.
The ar71xx-generic target already defines an even lower block size of
64KiB.