Ubiquiti's own bootloader expects the configuration mode to be present
with a "@" instead of a "-" for the sperator character. Otherwise
booting of the image fails.
Signed-off-by: David Bauer <mail@david-bauer.net>
Make packages depending on usb-serial selective, so we do not have
to add kmod-usb-serial manually for every device.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
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>
Enable testing kernel.
Fix compile errors by using new kernel APIs.
Fix fuzz by manually editing patches to ensure the code goes in the
right place.
For 721-NET-no-auto-carrier-off-support.patch, revert upstream commit
a307593a6 to keep the OpenWrt ralink driver operational.
Add mt7621-pci-phy patch to select REGMAP_MMIO as discussed in PR #3693
and #3952.
Run automatic quilt refresh on the rest.
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
0098-disable_cm.patch is not needed because upstream fixed CM handling.
The rest are straightforward removals of upstreamed patches.
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
This reverts commit b4aad29a1d.
This was accidentally folded into a single commit. Remove it and
apply it properly again.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Enable testing kernel.
Delete upstreamed patches:
0098-disable_cm.patch can be dropped, upstream fixed CM handling.
Fix compile errors by using new kernel APIs.
Fix fuzz by manually editing patches to ensure the code goes in the
right place.
For 721-NET-no-auto-carrier-off-support.patch, revert upstream commit
a307593a6 to keep the OpenWrt ralink driver operational.
Add mt7621-pci-phy patch to select REGMAP_MMIO as discussed in PR #3693
and #3952.
Rename patches to follow the 3-digit classification from the OpenWrt
Developer Guide.
Run automatic quilt refresh.
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
5.4.102 backported a lot of stuff that our WireGuard backport already
did, in addition to other patches we had, so those patches were
removed from that part of the series. In the process other patches were
refreshed or reworked to account for upstream changes.
This commit involved `update_kernel.sh -v -u 5.4`.
Cc: John Audia <graysky@archlinux.us>
Cc: David Bauer <mail@david-bauer.net>
Cc: Petr Štetiar <ynezz@true.cz>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Changes:
* Increase "oem" partition size from 0x10000 to 0x20000
* Correct partition lables, synchronize with official firmware
Evidence:
It should be the same as hiwifi hc5x61a and the fact indeed the
case. Here is part of dmesg boot log read from official firmware:
[ 1.470000] Creating 7 MTD partitions on "raspi":
[ 1.470000] 0x000000000000-0x000000030000 : "u-boot"
[ 1.480000] 0x000000030000-0x000000040000 : "hw_panic"
[ 1.490000] 0x000000040000-0x000000050000 : "Factory"
[ 1.490000] 0x000000fc0000-0x000000fe0000 : "oem"
[ 1.500000] 0x000000fe0000-0x000000ff0000 : "bdinfo"
[ 1.510000] 0x000000ff0000-0x000001000000 : "backup"
[ 1.510000] 0x000000050000-0x000000fc0000 : "firmware"
Signed-off-by: Shiji Yang <yangshiji66@qq.com>
ZTE MF283+ is a dual-antenna LTE category 4 router, based on Ralink
RT3352 SoC, and built-in ZTE P685M PCIe MiniCard LTE modem.
Hardware highlighs:
- CPU: MIPS24KEc at 400MHz,
- RAM: 64MB DDR2,
- Flash: 16MB SPI,
- Ethernet: 4 10/100M port switch with VLAN support,
- Wireless: Dual-stream 802.11n (RT2860), with two internal antennas,
- WWAN: Built-in ZTE P685M modem, with two internal antennas and two
switching SMA connectors for external antennas,
- FXS: Single ATA, with two connectors marked PHONE1 and PHONE2,
internally wired in parallel by 0-Ohm resistors, handled entirely by
internal WWAN modem.
- USB: internal miniPCIe slot for modem,
unpopulated USB A connector on PCB.
- SIM slot for the WWAN modem.
- UART connector for the console (unpopulated) at 3.3V,
pinout: 1: VCC, 2: TXD, 3: RXD, 4: GND,
settings: 57600-8-N-1.
- LEDs: Power (fixed), WLAN, WWAN (RGB),
phone (bicolor, controlled by modem), Signal,
4 link/act LEDs for LAN1-4.
- Buttons: WPS, reset.
Installation:
As the modem is, for most of the time, provided by carriers, there is no
possibility to flash through web interface, only built-in FOTA update
and TFTP recovery are supported.
There are two installation methods:
(1) Using serial console and initramfs-kernel - recommended, as it
allows you to back up original firmware, or
(2) Using TFTP recovery - does not require disassembly.
(1) Using serial console:
To install OpenWrt, one needs to disassemble the
router and flash it via TFTP by using serial console:
- Locate unpopulated 4-pin header on the top of the board, near buttons.
- Connect UART adapter to the connector. Use 3.3V voltage level only,
omit VCC connection. Pin 1 (VCC) is marked by square pad.
- Put your initramfs-kernel image in TFTP server directory.
- Power-up the device.
- Press "1" to load initramfs image to RAM.
- Enter IP address chosen for the device (defaults to 192.168.0.1).
- Enter TFTP server IP address (defaults to 192.168.0.22).
- Enter image filename as put inside TFTP server - something short,
like firmware.bin is recommended.
- Hit enter to load the image. U-boot will store above values in
persistent environment for next installation.
- If you ever might want to return to vendor firmware,
BACK UP CONTENTS OF YOUR FLASH NOW.
For this router, commonly used by mobile networks,
plain vendor images are not officially available.
To do so, copy contents of each /dev/mtd[0-3], "firmware" - mtd3 being the
most important, and copy them over network to your PC. But in case
anything goes wrong, PLEASE do back up ALL OF THEM.
- From under OpenWrt just booted, load the sysupgrade image to tmpfs,
and execute sysupgrade.
(2) Using TFTP recovery
- Set your host IP to 192.168.0.22 - for example using:
sudo ip addr add 192.168.0.22/24 dev <interface>
- Set up a TFTP server on your machine
- Put the sysupgrade image in TFTP server root named as 'root_uImage'
(no quotes), for example using tftpd:
cp openwrt-ramips-rt305x-zte_mf283plus-squashfs-sysupgrade.bin /srv/tftp/root_uImage
- Power on the router holding BOTH Reset and WPS buttons held for around
5 seconds, until after WWAN and Signal LEDs blink.
- Wait for OpenWrt to start booting up, this should take around a
minute.
Return to original firmware:
Here, again there are two possibilities are possible, just like for
installation:
(1) Using initramfs-kernel image and serial console
(2) Using TFTP recovery
(1) Using initramfs-kernel image and serial console
- Boot OpenWrt initramfs-kernel image via TFTP the same as for
installation.
- Copy over the backed up "firmware.bin" image of "mtd3" to /tmp/
- Use "mtd write /tmp/firmware.bin /dev/mtd3", where firmware.bin is
your backup taken before OpenWrt installation, and /dev/mtd3 is the
"firmware" partition.
(2) Using TFTP recovery
- Follow the same steps as for installation, but replacing 'root_uImage'
with firmware backup you took during installation, or by vendor
firmware obtained elsewhere.
A few quirks of the device, noted from my instance:
- Wired and wireless MAC addresses written in flash are the same,
despite being in separate locations.
- Power LED is hardwired to 3.3V, so there is no status LED per se, and
WLAN LED is controlled by WLAN driver, so I had to hijack 3G/4G LED
for status - original firmware also does this in bootup.
- FXS subsystem and its LED is controlled by the
modem, so it work independently of OpenWrt.
Tested to work even before OpenWrt booted.
I managed to open up modem's shell via ADB,
and found from its kernel logs, that FXS and its LED is indeed controlled
by modem.
- While finding LEDs, I had no GPL source drop from ZTE, so I had to probe for
each and every one of them manually, so this might not be complete -
it looks like bicolor LED is used for FXS, possibly to support
dual-ported variant in other device sharing the PCB.
- Flash performance is very low, despite enabling 50MHz clock and fast
read command, due to using 4k sectors throughout the target. I decided
to keep it at the moment, to avoid breaking existing devices - I
identified one potentially affected, should this be limited to under
4MB of Flash. The difference between sysupgrade durations is whopping
3min vs 8min, so this is worth pursuing.
In vendor firmware, WWAN LED behaviour is as follows, citing the manual:
- red - no registration,
- green - 3G,
- blue - 4G.
Blinking indicates activity, so netdev trigger mapped from wwan0 to blue:wwan
looks reasonable at the moment, for full replacement, a script similar to
"rssileds" would need to be developed.
Behaviour of "Signal LED" in vendor firmware is as follows:
- Off - no signal,
- Blinking - poor coverage
- Solid - good coverage.
A few more details on the built-in LTE modem:
Modem is not fully supported upstream in Linux - only two CDC ports
(DIAG and one for QMI) probe. I sent patches upstream to add required device
IDs for full support.
The mapping of USB functions is as follows:
- CDC (QCDM) - dedicated to comunicating with proprietary Qualcomm tools.
- CDC (PCUI) - not supported by upstream 'option' driver yet. Patch
submitted upstream.
- CDC (Modem) - Exactly the same as above
- QMI - A patch is sent upstream to add device ID, with that in place,
uqmi did connect successfully, once I selected correct PDP context
type for my SIM (IPv4-only, not default IPv4v6).
- ADB - self-explanatory, one can access the ADB shell with a device ID
added to 51-android.rules like so:
SUBSYSTEM!="usb", GOTO="android_usb_rules_end"
LABEL="android_usb_rules_begin"
SUBSYSTEM=="usb", ATTR{idVendor}=="19d2", ATTR{idProduct}=="1275", ENV{adb_user}="yes"
ENV{adb_user}=="yes", MODE="0660", GROUP="plugdev", TAG+="uaccess"
LABEL="android_usb_rules_end"
While not really needed in OpenWrt, it might come useful if one decides to
move the modem to their PC to hack it further, insides seem to be pretty
interesting. ADB also works well from within OpenWrt without that. O
course it isn't needed for normal operation, so I left it out of
DEVICE_PACKAGES.
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
[remove kmod-usb-ledtrig-usbport, take merged upstream patches]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The kernel bump to 5.4 has removed the mx25l25635f hack, and the
mx25l25635f compatible is no longer required.
Signed-off-by: DENG Qingfang <dqfext@gmail.com>
As suggested by Sergio, this adds GPIOs 19 and 8 explicitly into the
DIR-860L DTS, so the PCI-E ports get reset and the N radio (radio1)
on PCI-E port 1 comes up reliably.
Fixes the following error that popped up in dmesg:
[ 1.638942] mt7621-pci 1e140000.pcie: pcie1 no card, disable it (RST & CLK)
Suggested-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Stijn Segers <foss@volatilesystems.org>
Reviewed-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
The Netgear R6800 and R6700v2 devices have a Semtech SX1503 GPIO
expander controlling the device LEDs. This expander was initially
supported on 4.14, but support was lost in the transition to 5.4.
Since this driver cannot be built as a kernel module, enable it in the
kernel config for all mt7621 devices.
Run-tested on a Netgear R6800.
Cc: Stijn Segers <foss@volatilesystems.org>
Cc: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Tested-by: Stijn Segers <foss@volatilesystems.org>
Description:
1. From key and led config setting, we can find only "uartf" and "i2c" are used
as gpio by check mt7620 datasheet. It's time to remove unused pin group.
2. PSG1218 only have three led, so we can remove ethernet led pinctrl. refer to
Phicomm K2G.
Signed-off-by: Shiji Yang <yangshiji66@qq.com>
The lan port sequence was reversed compared to the labels.
Signed-off-by: Shiji Yang <yangshiji66@qq.com>
[improve commit title/message]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The aliases node is expected as one of the first entries, and
having it there matches alphabetic sorting as well.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
These were redefines of the same value already set in the SoC dtsi
files.
Reported-by: Shiji Yang <yangshiji66@qq.com>
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Phicomm K2G:
add missing label_mac
Phicomm PSG1218A & PSG1218B:
The previous wan mac was set as factory@0x28 +1 (originally based
on the default case for the ramips target), but the correct wan mac
is factory@0x28 -1, being equal to factory@0x2e.
Signed-off-by: Shiji Yang <yangshiji66@qq.com>
[minor commit title/message adjustments]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The Netgear EX6150 can, just like the D-Link DIR-860L rev B1, fail to
initialise both radios in some cases. Add the reset GPIOs explicitly
so the PCI-E devices get re-initialised properly. See also FS #3632.
Error shows up in dmesg as follows:
[ 1.560764] mt7621-pci 1e140000.pcie: pcie1 no card, disable it (RST & CLK)
Tested-by: Kurt Roeckx <kurt@roeckx.be>
Signed-off-by: Stijn Segers <foss@volatilesystems.org>
[removed period from commit title]
Signed-off-by: David Bauer <mail@david-bauer.net>
As kernel size increased it start to fail to load squishfs image,
using lzma-loader fixed it.
wevo_11acnas is almost same device as w2914ns-v2 except ram size,
so I expect same thing would've happen in that device too.
Signed-off-by: Seo Suchan <abnoeh@mail.com>
Reviewed-by: Sungbo Eo <mans0n@gorani.run>
The TP-Link EAP235-Wall is a wall-mounted, PoE-powered AC1200 access
point with four gigabit ethernet ports.
When connecting to the device's serial port, it is strongly advised to
use an isolated UART adapter. This prevents linking different power
domains created by the PoE power supply, which may damage your devices.
The device's U-Boot supports saving modified environments with
`saveenv`. However, there is no u-boot-env partition, and saving
modifications will cause the partition table to be overwritten. This is
not an issue for running OpenWrt, but will prevent the vendor FW from
functioning properly.
Device specifications:
* SoC: MT7621DAT
* RAM: 128MiB
* Flash: 16MiB SPI-NOR
* Wireless 2.4GHz (MT7603EN): b/g/n, 2x2
* Wireless 5GHz (MT7613BEN): a/n/ac, 2x2
* Ethernet: 4× GbE
* Back side: ETH0, PoE PD port
* Bottom side: ETH1, ETH2, ETH3
* Single white device LED
* LED button, reset button (available for failsafe)
* PoE pass-through on port ETH3 (enabled with GPIO)
Datasheet of the flash chip specifies a maximum frequency of 33MHz, but
that didn't work. 20MHz gives no errors with reading (flash dump) or
writing (sysupgrade).
Device mac addresses:
Stock firmware uses the same MAC address for ethernet (on device label)
and 2.4GHz wireless. The 5GHz wireless address is incremented by one.
This address is stored in the 'info' ('default-mac') partition at an
offset of 8 bytes.
From OEM ifconfig:
eth a4:2b:b0:...:88
ra0 a4:2b:b0:...:88
rai0 a4:2b:b0:...:89
Flashing instructions:
* Enable SSH in the web interface, and SSH into the target device
* run `cliclientd stopcs`, this should return "success"
* upload the factory image via the web interface
Debricking:
U-boot can be interrupted during boot, serial console is 57600 baud, 8n1
This allows installing a sysupgrade image, or fixing the device in
another way.
* Access serial header from the side of the board, close to ETH3,
pin-out is (1:TX, 2:RX, 3:GND, 4:3.3V), with pin 1 closest to ETH3.
* Interrupt bootloader by holding '4' during boot, which drops the
bootloader into its shell
* Change default 'serverip' and 'ipaddr' variables (optional)
* Download initramfs with `tftpboot`, and boot image with `bootm`
# tftpboot 84000000 openwrt-initramfs.bin
# bootm
Revert to stock:
Using the tplink-safeloader utility from the firmware-utils package,
TP-Link's firmware image can be converted to an OpenWrt-compatible
sysupgrade image:
$ ./staging_dir/host/bin/tplink-safeloader -B EAP235-WALL-V1 \
-z EAP235-WALLv1_XXX_up_signed.bin -o eap235-sysupgrade.bin
This can then be flashed using the OpenWrt sysupgrade interface. The
image will appear to be incompatible and must be force flashed, without
keeping the current configuration.
Known issues:
- DFS support is incomplete (known issue with MT7613)
- MT7613 radio may stop responding when idling, reboot required.
This was an issue with the ddc75ff704 version of mt76, but appears to
have improved/disappeared with bc3963764d.
Error notice example:
[ 7099.554067] mt7615e 0000:02:00.0: Message 73 (seq 1) timeout
Hardware was kindly provided for porting by Stijn Segers.
Tested-by: Stijn Segers <foss@volatilesystems.org>
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Similarly to the Archer C2 v1, the Archer C20 v1 will brick when one
tries to flash an OpenWrt factory image through the TP-Link web UI.
The wiki page contains an explicit warning about this [1].
Disable the factory image altogether since it serves no purpose.
[1] https://openwrt.org/toh/tp-link/tp-link_archer_c20_v1#installation
Signed-off-by: Stijn Segers <foss@volatilesystems.org>
Ran update_kernel.sh in a fresh clone without any existing toolchains.
No manual changes needed.
Build system: x86_64
Build-tested: bcm27xx/bcm2711
Signed-off-by: John Audia <graysky@archlinux.us>
The Netgear EX6150 has an Access Point/Extender switch. Set it as
an EV_SW. Otherwise when it's set to Access Point, it will trigger
failsafe mode during boot.
Fixes: FS#3590
Signed-off-by: Kurt Roeckx <kurt@roeckx.be>
The bootloader of a number of recent TP-Link devices does not properly
initialise the MT7621's internal switch when booting from flash. To
enable the mt7530 driver to clear the reset on the switch, the ramips
reset controller must be allowed to toggle these.
Backport upstream commit 3f9ef7785a9c from mips-next to allow control of
the "mcm" reset line.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Initial commit 8375623a06 ("ramips: add support for TP-Link Archer
C2") contains detailed installation instructions, which do not mention
a factory image. From what I can see, no support to install OpenWrt
through the vendor web interface has been added since. The factory
image is also conspicuously absent from the device page in the wiki.
Yet, it is available for download.
I bricked my Archer C2 loading the factory image through the web UI.
Serial showed this error during bootloop:
Uncompressing Kernel Image ... LZMA ERROR 1 - must RESET board to recover
This patch disables the undocumented factory image so users won't get
tricked into thinking easy web UI flashing actually works.
Signed-off-by: Stijn Segers <foss@volatilesystems.org>
Specifications:
- SoC: MediaTek MT7621AT
- RAM: 128 MB (DDR3)
- Flash: 16 MB (SPI NOR)
- WiFi: MediaTek MT7603E, MediaTek MT7612E
- Switch: 1 WAN, 4 LAN (Gigabit)
- Ports: 1 USB 3.0
- Buttons: Reset, WPS
- LEDs: Power, System, Wan, Lan 1-4, WiFi 2.4G, WiFi 5G, WPS, USB
- Power: DC 12V 1A tip positive
UART Serial:
115200 baud
Located on unpopulated 4 pin header near J4:
J4
[o] Rx
[o] Tx
[o] GND
[ ] Vcc - Do not connect
Installation:
Download and flash the manufacturer's built OpenWRT image available at
http://www.cudytech.com/openwrt_software_download
Install the new OpenWRT image via luci (System -> Backup/Flash firmware)
Be sure to NOT keep settings. The force upgrade may need to be checked
due to differences in router naming conventions.
Recovery:
- Loads only signed manufacture firmware due to bootloader RSA verification
- serve tftp-recovery image as /recovery.bin on 192.168.1.88/24
- connect to any lan ethernet port
- power on the device while holding the reset button
- wait at least 8 seconds before releasing reset button for image to
download
- See http://www.cudytech.com/newsinfo/547425.html
MAC addresses as verified by OEM firmware:
use address source
LAN *:f0 label
WAN *:f1 label + 1
2g *:f0 label
5g *:f2 label + 2
The label MAC address is found in bdinfo 0xde00.
Signed-off-by: Andrew Pikler <andrew.pikler@gmail.com>
While the latest version of 19.07 release is usable,
the current master is unbootable on the device in a normal way.
"Normal way" installations includes:
- sysupgrade (e.g. from 19.07)
- RESET button recovery with Ron Curry's (Wingspinner) UBoot image
(10.10.10.3 + "Kernal.bin")
- RESET button recovery with original U-Boot
(10.10.10.254 + "kernel")
One could flash and boot the latest master sysupgrade image successfully
with serial access to the device. But a sysupgrade from this state still
breaks the U-Boot and soft-bricks the device.
Signed-off-by: Szabolcs Hubai <szab.hu@gmail.com>
shellcheck recommends || and && over "-a" and "-o" because the
latter are not well defined.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This replaces several full-text and abbreviated licenses found in
DTS files by the corresponding SPDX identifiers.
This should make it easier to identify the license both by humans
and machines.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
UniElec U7621-01 is a router platform board, the smaller model of
the U7621-06.
The device has the following specifications:
- MT7621AT (880 MHz)
- 256 of RAM (DDR3)
- 16 MB of FLASH (SPI NOR)
- 5x 1 Gbps Ethernet (MT7621 built-in switch)
- 1x 2.4Ghz MT7603E
- 1x 5Ghz MT7612
- 1x miniPCIe slots (PCIe bus only)
- 1x miniSIM slot
- 1x USB 2.0 (uses the usb 3.0 driver)
- 8x LEDs (1x GPIO-controlled)
- 1x reset button
- 1x UART header (4-pins)
- 1x GPIO header (30-pins)
- 1x DC jack for main power (12 V)
The following has been tested and is working:
- Ethernet switch
- 1x 2.4Ghz MT7603E (wifi)
- 1x 5Ghz MT7612 (wifi)
- miniPCIe slots (tested with Wi-Fi cards and LTE modem cards)
- miniSIM slot (works with normal size simcard)
- sysupgrade
- reset button
Installation:
This board has no locked down bootloader. The seller can be asked to
install openwrt v18.06, so upgrades are standard sysupgrade method.
Recovery:
This board contains a Chinese, closed-source bootloader called Breed
(Boot and Recovery Environment for Embedded Devices). Breed supports web
recovery and to enter it, you keep the reset button pressed for around
5 seconds during boot. Your machine will be assigned an IP through DHCP
and the router will use IP address 192.168.1.1. The recovery website is
in Chinese, but is easy to use. Click on the second item in the list to
access the recovery page, then the second item on the next page is where
you select the firmware. In order to start the recovery, you click the
button at the bottom.
LEDs list (left to right):
- ESW_P0_LED_0
- ESW_P1_LED_0
- ESW_P2_LED_0
- ESW_P3_LED_0
- ESW_P4_LED_0
- CTS2_N (GPIO10, configured as "status" LED)
- LED_WLAN# (connected with pin 44 in wifi1 slot)
Signed-off-by: David Bentham <db260179@gmail.com>
[add DEVICE_VARIANT, fix DEVICE_PACKAGES, remove &gpio]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Specifications:
- SoC: MediaTek MT7688AN
- RAM: 128 MB
- Flash: 32 MB
- Ethernet: 5x 10/100 (1x WAN, 4x LAN)
- Wireless: built in 2.4GHz (bgn)
- USB: 1x USB 2.0 port
- Buttons: 1x Reset
- LEDs: 1x (WiFi)
Flash instructions:
- Configure TFTP server with IP address 10.10.10.3
- Name the firmware file as firmware.bin
- Connect any Ethernet port to the TFTP server's LAN
- Choose option 2 in U-Boot
- Alternatively choose option 7 to upload firmware to the built-in
web server
MAC addresses as verified by OEM firmware:
use address source
2g *:XX factory 0x4
LAN *:XX+1 factory 0x28
WAN *:XX+1 factory 0x2e
Notes:
This board is ostensibly a module containing the MediaTek MT7688AN SoC,
128 MB DDR2 SDRAM and 32 MB flash storage. The SoC can be operated in
IoT Gateway Mode or IoT Device Mode.
From some vendors the U-Boot that comes installed operates on UART 2
which is inaccessible in gateway mode and operates unreliably in the
Linux kernel when using more than 64 MB of RAM. For those, updating
U-Boot is recommended.
Signed-off-by: Ewan Parker <ewan@ewan.cc>
[add WLAN to 01_leds]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
On a platform with many very different devices, like found on ramips,
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.
Actually, rt288x didn't have a default profile in the first place.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Acked-by: Paul Spooren <mail@aparcar.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>
