David Woodhouse [Tue, 21 Jul 2020 18:07:47 +0000 (19:07 +0100)]
mediatek: mt7623: make gen_banana_pi_img.sh more generic
This actually covers fairly much all the MediaTek platforms; they
only have different images because they don't include the preloader
and U-Boot, and rely on preinstalled stuff from the vendor.
So this script can slowly take over the world as we complete the
support for various other platforms, starting with UniElec U7623…
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
David Woodhouse [Tue, 21 Jul 2020 16:43:12 +0000 (17:43 +0100)]
mediatek: mt7623: add scatter file for unbricking with SP Flash Tool
Many MediaTek SoCs can be unbricked by using the SP Flash Tool from
http://spflashtool.com/ along with a "scatter list" file, which is
just a text file listing which image gets loaded where.
We use a trivial partition layout for the tool, with the whole eMMC
image as a single "partition", which means users just need to unzip
the sysupgrade image. Doing the real partition layout would be overly
complex and would require the individual partitions to be shipped
as artifacts — or users to extract them out of the sysupgrade image
just for the tool to put them adjacent to each other on the eMMC
anyway.
The tool does require a copy of the preloader in order to operate,
even when it isn't flashing the preloader to the eMMC boot region.
So drop that into the bin directory as an artifact too.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
bpi-r2 images are shipped with mainline u-boot which can extract lzma
with no problem.
remove custom kernel recipe to build lzma fit image instead of
uncompressed fit with zboot.
David Woodhouse [Mon, 20 Jul 2020 20:10:04 +0000 (21:10 +0100)]
mediatek: mt7623: prepare for full sysupgrade support on UniElec U7623
An upcoming commit will add a full system image for U7623 which will
contain the MBR partition table and U-Boot too.
That contrasts with the current image which only owns the eMMC from
sector 0xa00 onwards, and must start with a legacy uImage.
Prepare for sysupgrade to the new images, and cope with the fact that
the recovery partition will be /dev/mmcblk0p2 instead of /dev/mmcblk0p1
after the upgrade.
This commit could potentially be backported to 19.07 to allow for direct
sysupgrade to the new image layout.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
David Woodhouse [Tue, 21 Jul 2020 08:53:32 +0000 (09:53 +0100)]
mediatek: mt7623: fix sysupgrade from vendor OpenWrt on UniElec U7623
This board ships with an ancient 14.07-based OpenWrt using block2mtd, and
the MBR partition table contains nonsense.
It is possible to sysupgrade to an upstream OpenWrt image, but the
legacy layout of the OpenWrt images start at 0xA00 in the eMMC, with
a raw uImage. The legacy OpenWrt image doesn't "own" the beginning
of the device, including the MBR and U-Boot.
This means that when a user upgrades to upstream OpenWrt, it doesn't
boot because it can't find the right partitions. So hard-code them on
the kernel's command line using CONFIG_CMDLINE_PARTITION (for block).
Additionally, the vendor firmware doesn't cope with images larger than
about 36MiB, because it only overwrites the contents of its "firmware"
MTD partition. The current layout of the legacy image wastes a lot of
space, allowing over 32MiB for the kernel and another 10MiB for the FAT
recovery file system which is only created as 3MiB. So pull those in
to allow 4¾ MiB for the kernel, 3MiB for recovery, and then we have over
20MiB for the root file system.
This doesn't affect the new images which ship with a full eMMC image
including a different MBR layout and a partition for U-Boot, because
our modern U-Boot can actually pass the command line to the kernel, and
the built-in one doesn't get used anyway.
Tested by upgrading from vendor OpenWrt to the current legacy image,
from legacy to itself, to the previous legacy layout, and then to
finally the full-system image.
This commit probably wants backporting to 19.07, which also doesn't
install over the vendor OpenWrt and doesn't even have a full-system
installation option.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
The cpximg file can be used with sysupgrade in the stock firmware (add
SSH key in luci for root access) or with the built-in cpximg loader.
The cpximg loader can be started either by holding the reset button
during power up or by entering the u-boot prompt and entering 'cpximg'.
Once it's running, a TFTP-server under 192.168.1.1 will accept the image
appropriate for the board revision that is etched on the board.
For example, if the board is labelled '7A02':
tftp -v -m binary 192.168.1.1 -c put openwrt-ath79-generic-compex_wpj563-squashfs-cpximg-7a02.bin
xrx200 has a 6 port built-in switch with 2 integrated PHY. None of the
xrx200 router uses external switch. Most boards use integrated or Lantiq
(Intel) PEF7071 PHY. Only some FritzBox routers use AT803X PHY and
VGV7510KW22 use ICPLUS PHY. Other unused PHY drivers may be removed.
This patch enables these symbols only on xway and xway_legacy subtargets:
- CONFIG_PSB6970_PHY (Driver for PHY in PSB6970 - 7 port FE Switch)
- CONFIG_RTL8366RB_PHY (Driver for PHY in RTL8366 - 6 port GE Switch)
- CONFIG_RTL8366_SMI (Driver for RTL8366 - 6 port GE Switch)
Signed-off-by: Aleksander Jan Bajkowski <A.Bajkowski@stud.elka.pw.edu.pl>
[fix sorting in config files, small fix in commit message] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The current condition with part of the variables set dependent on
the subtarget in Device/Default isn't really nice to read and also
defeats the purpose of having a default node.
This removes the special settings for mt7623 and moves them to the
individual devices, which is not much of a problem as there are
actually just two of them and they partly use different settings
anyway.
While at it, slightly adjust the order of variables and wrap some
long lines.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Sungbo Eo [Thu, 2 Jul 2020 13:33:18 +0000 (22:33 +0900)]
treewide: rename POWER_ON_STRIP register
AR8327 datasheet[1] calls the register at address 0x0010
"Power-on Strapping Register". As it has nothing to do with "strip",
let's rename it to "POWER_ON_STRAP" to make it easier to grasp.
John Thomson [Sat, 13 Jun 2020 11:25:12 +0000 (21:25 +1000)]
ramips: remove non-existant poe_passthrough for RouterBOARD 750Gr3
This 750gr3 GPIO17 switch was added based on vendor source,
but only the 760iGS (which shares the rbsysfs board identifier)
device has the physical wiring. The 750Gr3 actually does not
support PoE out.
Apart from that, note that the gpio base (480) would have required
this GPIO to be referenced as 497 if it was kept.
Fixes: 6ba58b7b020c ("ramips: cleanup the RB750Gr3 support") Signed-off-by: John Thomson <git@johnthomson.fastmail.com.au>
[commit title/message facelift] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The Winstars WS-WN583A6 is a wireless repeater with 2 gigabit ethernet
ports. Even if mine is branded as "Gemeita AC2100", the sticker on the
back says WS-WN583A6. So I will refer to it as Winstars WS-WN583A6.
Probably the real product name is the Wavlink WL-WN583A6 because of
the many references to Wavlink in the OEM firmware and bootlog.
Hardware
--------
SoC: Mediatek MT7621AT (880 MHz, 2 cores 4 threads)
RAM: 128MB
FLASH: 8MB NOR (GigaDevice GD25Q64B)
ETH: 2x 10/100/1000 Mbps Ethernet (MT7530)
WIFI:
- 2.4GHz: 1x MT7603E (2x2:2)
- 5GHz: 1x MT7615E (4x4:4)
- 6 internal antennas
BTN:
- 1x Reset button
- 1x WPS button
- 1x ON/OFF switch (working but unmodifiable)
- 1x Auto/Schedule switch (working but unmodifiable. Read Note #3)
LEDS:
- 1x White led
- 1x Red led
- 1x Amber led
- 1x Blue led
- 2x Blue leds (lan and wan port status: working but unmodifiable)
UART:
- 57600-8-N-1
Everything works correctly.
Currently there is no firmware update available. Because of this, in
order to restore the OEM firmware, you must firstly dump the OEM
firmware from your router before you flash the OpenWrt image.
Backup the OEM Firmware
-----------------------
The following steps are to be intended for users having little to none
experience in linux. Obviously there are many ways to backup the OEM
firmware, but probably this is the easiest way for this router.
Procedure tested on M83A6.V5030.191210 firmware version.
1) Go to http://192.168.10.1/webcmd.shtml
2) Type the following line in the "Command" input box:
mkdir /etc_ro/lighttpd/www/dev; for i in /dev/mtd*ro; do dd if=${i} of=/etc_ro/lighttpd/www${i}; done
3) Click "Apply"
4) After few seconds, in the textarea should appear this output:
16384+0 records in
16384+0 records out 8388608 bytes (8.0MB) copied, 4.038820 seconds, 2.0MB/s
384+0 records in
384+0 records out
196608 bytes (192.0KB) copied, 0.095180 seconds, 2.0MB/s
128+0 records in
128+0 records out
65536 bytes (64.0KB) copied, 0.032020 seconds, 2.0MB/s
128+0 records in
128+0 records out
65536 bytes (64.0KB) copied, 0.031760 seconds, 2.0MB/s
15744+0 records in
15744+0 records out 8060928 bytes (7.7MB) copied, 3.885280 seconds, 2.0MB/s
dd: can't open '/dev/mtd5ro': No such device
dd: can't open '/dev/mtd6ro': No such device
dd: can't open '/dev/mtd7ro': No such device
Excluding the "X.XXXXXX seconds" part, you should get the same
exact output. If your output doesn't match mine, stop reading
and ask for help in the forum.
5) Open the following links to download the partitions of the OEM FW:
http://192.168.10.1/dev/mtd0ro
http://192.168.10.1/dev/mtd1ro
http://192.168.10.1/dev/mtd2ro
http://192.168.10.1/dev/mtd3ro
http://192.168.10.1/dev/mtd4ro
If one (or more) of these files weight 0 byte, stop reading and ask
for help in the forum.
6) Store these downloaded files in a safe place.
7) Reboot your router to remove any temporary file from your router.
Installation
------------
Flash the initramfs image in the OEM firmware interface.
When openwrt boots, flash the sysupgrade image otherwise you won't be
able to keep configuration between reboots.
Restore OEM Firmware
--------------------
Flash the "mtd4ro" file you previously backed-up directly from LUCI.
Warning: Remember to not keep settings!
Warning2: Remember to force the flash.
Notes
-----
1) The "System Command" page allows to run every command as root.
For example you can use "dd" and "nc" to backup the OEM firmware.
PC (SERVER):
nc -l 5555 > ./mtdXro
ROUTER (CLIENT):
dd if=/dev/mtdXro | nc PC_IP_ADDRESS 5555
2) The OEM web interface accepts only images containing the string
"WN583A6" in the filename.
Currently the OEM interface accepts only the initramfs image
probably because it checks if the ih_size in the image header is
equal to the whole image size (instead of the kernel size)
Read more here:
https://forum.openwrt.org/t/support-for-strong-1200/22768/19
3) The white led (namely "Smart Night Light") can be controller by the
user only if the side switch is set to "Schedule" otherwise it will
be activated by the light condition (there is a photodiode on the
top side of the router)
4) Router mac addresses:
LAN XX:XX:XX:XX:XX:8F
WAN XX:XX:XX:XX:XX:90
WIFI 2G XX:XX:XX:XX:XX:91
WIFI 5G XX:XX:XX:XX:XX:92
Most newer targets have been converted to consistently use
vendor_model scheme for device definitions/image names, ox820 is
using it as well, so let's just convert ox810se for consistency.
While at it, use generic setup for DEVICE_DTS and add SUPPORTED_DEVICES.
The latter have been introduced for ox820 already in cf7896117b3e ("oxnas: enable image metadata by setting SUPPORTED_DEVICES")
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
build: Remove dependency of user space stack cookies from kernel
Currently the user space stack cookies work well also when the kernel
stack cookies are not activated. This is handled completely in user
space and does not need kernel support.
This dependency was probably needed some years ago when the libc did not
support stack cookies.
Reviewed-by: Ian Cooper <iancooper@hotmail.com> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Hauke Mehrtens [Sat, 20 Jun 2020 21:11:17 +0000 (23:11 +0200)]
mac80211: Update to version 5.8-rc2-1
The following patches:
* 972-ath10k_fix-crash-due-to-wrong-handling-of-peer_bw_rxnss_override-parameter.patch
* 973-ath10k_fix-band_center_freq-handling-for-VHT160-in-recent-firmwares.patch
are replaced by this commit in the upstream kernel:
* 3db24065c2c8 ("ath10k: enable VHT160 and VHT80+80 modes")
The following patches were applied upstream:
* 001-rt2800-enable-MFP-support-unconditionally.patch
* 090-wireless-Use-linux-stddef.h-instead-of-stddef.h.patch
The rtw88 driver is now split into multiple kernel modules, just put it
all into one OpenWrt kernel package.
rtl8812au-ct was patched to compile against the mac80211 from kernel
5.8, but not runtime tested.
Add a patch which fixes ath10k on IPQ40XX, this patch was send upstream
and fixes a crash when loading ath10k on this SoC.
Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> [ipq40xx/ map-ac2200] Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Michal Hrusecky [Mon, 20 Jul 2020 13:23:07 +0000 (15:23 +0200)]
openvpn: Allow override of interface name
If using a configuration file for OpenVPN, allow overriding name of the
interface. The reason is that then people could use configuration file
provided by VPN provider directly and override the name of the interface
to include it in correct firewall zone without need to alter the
configuration file.
This applies to tools directory what has been done for package/ in
commit 9c170cb92f4f ("package: drop PKG_VERSION for purely local
packages"):
In the package guidelines, PKG_VERSION is supposed to be used as
"The upstream version number that we're downloading", while
PKG_RELEASE is referred to as "The version of this package Makefile".
Thus, the variables in a strict interpretation provide a clear
distinction between "their" (upstream) version in PKG_VERSION and
"our" (local OpenWrt trunk) version in PKG_RELEASE.
For local (OpenWrt-only) packages, this implies that those will only
need PKG_RELEASE defined, while PKG_VERSION does not apply following
a strict interpretation. While the majority of "our" packages actually
follow that scheme, there are also some that mix both variables or
have one of them defined but keep them at "1".
This is misleading and confusing, which can be observed by the fact
that there typically either one of the variables is never bumped or
the choice of the variable to increase depends on the person doing the
change.
Consequently, this patch aims at clarifying the situation by
consistently using only PKG_RELEASE for "our" packages. For tools/,
only three packages were affected. This fixes two of them, and
leaves the remaining wrt350nv2-builder untouched, as the code there
seems to have some versioning of its own that is treated as upstream
version in PKG_VERSION.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
As already stated in the reverted patch, the OEM firmware will
properly recreate the config partition if it is overwritten by
OpenWrt.
The main reason for adding the partition was the image size
restriction imposed by the 0x3d0000 limitation of the TFTP
flashing process. Addressing this by shrinking the firmware
partition is not a good solution to that problem, though:
1. For a working image, the size of the content has to be smaller
than the available space, so empty erase blocks will remain.
2. Conceptually, the restriction is on the image, so it makes sense
to implement it in the same way, and not via the partitioning.
Users could e.g. do initial flash with TFTP restriction with
an older image, and then sysupgrade into a newer one, so TFTP
restriction does not apply.
3. The (content) size of the recovery image is enforced to 0x3d0000
by the tplink-v2-image command in combination with
TPLINK_FLASHLAYOUT (flash layout in mktplinkfw2.c) anyway.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Currently arc770 sets a board name from compatible for no apparent
reason. Just use the compatible directly instead.
This theoretically removes a board name "generic" when no compatible
was present, however, there is no case where this "generic" board
name was actually used.
This also fixes an issue where snps,axs101 would not have been
properly detected anyway, as its case was not set up syntactically
correct.
Fixes: 576621f1e353 ("linux: add support of Synopsys ARC770-based boards") Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Currently archs38 sets a board name from compatible for no apparent
reason. Just use the compatible directly instead.
This theoretically removes a board name "generic" when no compatible
was present, however, there is no case where this "generic" board
name was actually used.
This also fixes an issue where snps,axs103 would not have been
properly detected anyway, as its case was not set up syntactically
correct.
Fixes: 73015c4cb378 ("linux: add support of Synopsys ARCHS38-based boards") Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
David Bauer [Tue, 21 Jul 2020 18:11:28 +0000 (20:11 +0200)]
ramips: increase SPI frequency for MT7620 Archer
Increase the SPI frequency for the MT7620 based TP-Link Archer
series to 30MHz.
TP-Link uses different SPI flash chips for the same board
revision, so be conservative to not break boards with a
different chip. 30MHz should be well supported by all chips.
Tested on Archer C2 v1 (GD25Q64B) and Archer C20i (W25Q64FV).
Archer C20i (before)
====================
root@OpenWrt:~# time dd if=/dev/mtd1 of=/tmp/test.bin bs=64k
122+0 records in
122+0 records out
real 0m 15.30s
user 0m 0.00s
sys 0m 15.29s
Archer C20i (after)
===================
root@OpenWrt:~# time dd if=/dev/mtd1 of=/tmp/test.bin bs=64k
122+0 records in
122+0 records out
real 0m 5.99s
user 0m 0.00s
sys 0m 5.98s
Signed-off-by: David Bauer <mail@david-bauer.net> Acked-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
David Bauer [Tue, 21 Jul 2020 22:00:36 +0000 (00:00 +0200)]
ath79: re-enable image generation for GL-AR750S
The bootloader only writes the first 2MB of the image to the NOR flash
when installing the NAND factory image. The bootloader is capable of
booting larger kernels as it boots from the memory mapped SPI flash.
Disable the NAND factory image. The NAND can be bootstrapped by writing
the NAND initramfs image using the NOR upgrade method in the bootloader
web-recovery and sysupgrading from there. The NOR variant is not
affected.
Also refactor the partition definitions in the DTS to make them less
annoying to read.
ath79: correctly define WiFi switch for TL-WR841ND v8
The TL-WR841ND v8 feature a WiFi switch instead of a button.
This adds the corresponding input-type to prevent booting into
failsafe regularly.
This has been defined correctly in ar71xx, but was overlooked
when migrating to ath79. In contrast, the TL-WR842ND v2, which
has the key set up as switch in ar71xx, actually has a button.
The TL-MR3420 v2 has a button as well and is set up correctly
for both targets. (Information based on TP-Link user guide)
Note:
While looking into this, I found that support PR for TL-MR3420 v2
switched reset button to ACTIVE_HIGH. However, the other two
device still use ACTIVE_LOW. This seems strange, but I cannot
verify it lacking the affected devices.
Fixes: FS#2733 Fixes: 9601d94138de ("add support for TP-Link TL-WR841N/ND v8") Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The DEVICE_DTS variable always matches the device definition name,
just with "_" replaced by "-". Thus, create a DEVICE_DTS definition
in Device/Default and drop all the individual statements.
If necessary in the future, local DEVICE_DTS will still overwrite
that default.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Nelson Cai [Mon, 20 Jul 2020 05:02:27 +0000 (13:02 +0800)]
ramips: fix network setup for Ubiquiti ER-X/ER-X-SFP
The function name ucidef_set_interface_lan_wan does not exist,
use the proper name by adding an "s" and thereby fix network
setup on these devices.
Fixes: 22468cc40c8b (ramips: erx and erx-sfp: fix missing WAN interface) Signed-off-by: Nelson Cai <niphor@gmail.com>
[commit message/title facelift] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
David Bauer [Mon, 20 Jul 2020 13:07:47 +0000 (15:07 +0200)]
mac80211: create channel list for fixed channel operation
Currently a device which has a DFS channel selected using the UCI
channel setting might switch to a non-DFS channel in case no chanlist is
provided (UCI setting "channels") when the radio detects a DFS event.
Automatically add a chanlist consisting of the configured channel when
the device does not operate in auto-channel mode and no chanlist set to
circumvent this issue.
Johannes Kimmel [Mon, 20 Jul 2020 06:05:10 +0000 (08:05 +0200)]
vxlan: add capability for multiple fdb entries
Similar to wireguard, vxlan can configure multiple peers or add specific
entries to the fdb for a single mac address.
While you can still use peeraddr/peer6addr option within the proto
vxlan/vxlan6 section to not break existing configurations, this patch
allows to add multiple sections that conigure fdb entries via the bridge
command. As such, the bridge command is now a dependency of the vxlan
package. (To be honest without the bridge command available, vxlan isn't
very much fun to use or debug at all)
Field names are taken direclty from the bridge command.
Example with all supported parameters, since this hasn't been documented so
far:
config interface 'vx0'
option proto 'vxlan6' # use vxlan over ipv6
# main options
option ip6addr '2001:db8::1' # listen address
option tunlink 'wan6' # optional if listen address given
option peer6addr '2001:db8::2' # now optional
option port '8472' # this is the standard port under linux
option vid '42' # VXLAN Network Identifier to use
option mtu '1430' # vxlan6 has 70 bytes overhead
# extra options
option rxcsum '0' # allow receiving packets without checksum
option txcsum '0' # send packets without checksum
option ttl '16' # specifies the TTL value for outgoing packets
option tos '0' # specifies the TOS value for outgoing packets
option macaddr '11:22:33:44:55:66' # optional, manually specify mac
# default is a random address
Single peer with head-end replication. Corresponds to the following call
to bridge:
$ bridge fdb append 00:00:00:00:00:00 dev vx0 dst 2001:db8::3
For multiple peers, this section can be repeated for each dst address.
It's possible to specify a multicast address as destination. Useful when
multicast routing is available or within one lan segment:
config vxlan_peer
option vxlan 'vx0'
option dst 'ff02::1337' # multicast group to join.
# all bum traffic will be send there
option via 'eth1' # for multicast, an outgoing interface needs
# to be specified
All available peer options for completeness:
config vxlan_peer
option vxlan 'vx0' # the interface to configure
option lladdr 'aa:bb:cc:dd:ee:ff' # specific mac,
option dst '2001:db8::4' # connected to this peer
option via 'eth0.1' # use this interface only
option port '4789' # use different port for this peer
option vni '23' # override vni for this peer
option src_vni '123' # see man 3 bridge
Signed-off-by: Johannes Kimmel <fff@bareminimum.eu>
This fixes a nasty problem introduced in 2.81 which causes random
crashes on systems where there's significant DNS activity over TCP. It
also fixes DNSSEC validation problems with zero-TTL DNSKEY and DS
records.
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Daniel Golle [Mon, 20 Jul 2020 03:36:58 +0000 (04:36 +0100)]
procd: bump to git HEAD once again
Further complete OCI container support in ujail: f5f305e jail: move /tmp/resolv.conf.d to /dev/resolv.conf.d 6f078ae jail: add support for defining devices 686cf7a jail: actually apply filesystem-specific mount options f91009a jail: refactor default mounts into new structure 66ae2d9 jail: re-implement /proc/sys/net read-write in netns hack
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
lantiq/xrx200: make WLAN button responsive on Fritzbox 7360 & 7362
Pressing the 'WLAN' button should enable/disable wireless activity.
Currently, the button is mapped to the KEY_WLAN, which will not
have this effect.
This patch changes the mapping of the WLAN button, so a button
press will emit an action for the 'rfkill' key instead of 'wlan'.
Apparently, this is what stock OpenWRT expects.
This fix is analogous to the preceding patch for Fritzbox 3370.
Dustin Gathmann [Wed, 20 May 2020 23:22:53 +0000 (01:22 +0200)]
lantiq/xrx200: fix WLAN button actions for Fritzbox 3370
The WLAN button actions are reversed, i.e. pressing the button emits a
'released' action, and vice versa.
This can easily be checked by adding
logger -t button_action "$BUTTON $ACTION"
as the second line of /etc/rc.button/rfkill, and using logread to read
the events (assuming the preceding patch has been applied).
Defining the GPIO as ACTIVE_LOW corrects this behavior.
Dustin Gathmann [Wed, 20 May 2020 22:13:43 +0000 (00:13 +0200)]
lantiq/xrx200: make WLAN button responsive on Fritzbox 3370
Pressing the 'WLAN' button should enable/disable wireless activity.
However, on the Fritzbox 3370 this doesn't have an effect.
This patch changes the mapping of the physical WLAN button, so a button
press will emit an action for the 'rfkill' key instead of 'wlan'.
Apparently, this is what stock OpenWRT expects, and also what is
implemented for most other devices.
Daniel Golle [Sun, 19 Jul 2020 18:34:46 +0000 (19:34 +0100)]
procd: update to git HEAD
9eddf0f jail: fix hooks 1b1286b jail: parse and apply OCI sysctl values c049047 jail: implement OCI user additionalGIDs 0e1920c jail: read and apply umask from OCI if defined 1c46cc3 jail: parse and apply POSIX rlimits 76adac5 jail: /proc/$pid/oom_score_adj to OCI defined oomScoreAdj
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Alexander Müller [Fri, 17 Jul 2020 16:46:19 +0000 (18:46 +0200)]
ramips: fix flash layout for TP-Link TL-WR841N v14
The config partition was missing from the flash layout of the device.
Although the stock firmware resets a corrupted config partition to the
default values, the TFTP flash with an image bigger than 0x3d0000 will
truncate the image as the bootloader only copies 0x3d0000 bytes to flash
during TFTP flashing.
Fixed by adding the config partition and shrinking the firmware
partition.
Fixes: 3fd97c522bb7 ("ramips: add support for TP-Link TL-WR841n v14") Signed-off-by: Alexander Müller <donothingloop@gmail.com>
ramips: remove incorrect mtd-eeprom for TP-Link TL-WR841N v14
The factory partition on this device is only 64k in size, so having
mediatek,mtd-eeprom = <&factory 0x10000> would place the EEPROM data
after the end of the flash. As can be verified against the TP-Link
GPL sources, which contain the EEPROM data as binary blob, the actual
address for the EEPROM data is 0x0.
Since 0x0 is default for MT7628, the incorrect line is just removed.
This error is the reason for the abysmal Wifi performance that people
are complaining about for the WR841Nv14.
Fixes: 3fd97c522bb7 ("ramips: add support for TP-Link TL-WR841n v14") Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
David Bauer [Sat, 18 Jul 2020 20:12:19 +0000 (22:12 +0200)]
ramips: don't create switch config for VIXMINI
Don't create UCI switch config for the GL.iNet microuter-N300 and
VIXMINI. These devices only have a single LAN port.
Creating the switch config makes usage of VLANs more complicated,
as they would have to be configured on the MAC as well as the "switch".
Daniel Golle [Fri, 17 Jul 2020 10:59:16 +0000 (11:59 +0100)]
procd: bump to git HEAD
8d5208f jail: fix false return in case of nofail mount b41f76b procd: fix compile if procd-ujail is not selected 86a5105 jail: fs: fix build on uClibc-ng bfce7d1 jail: fix some more mount options 268126a jail: add support for maskedPaths and readonlyPaths
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
lantiq: move 01_led_migration script to subtargets
Split the /etc/uci-defaults/01_led_migration scripts into subtargets
as already done for most of the other base-files.
While this introduces a minor amount of code duplication, it still
is considered an improvement, as device-specific settings are kept
together in the subtargets' base-files and the script at hand can be
removed entirely for two of the subtargets not needing it.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Alberto Bursi [Sun, 12 Jul 2020 13:35:54 +0000 (15:35 +0200)]
mvebu: add Kobol Helios 4 device
The Helios 4 is a NAS from Kobol
that is powered by an Armada 38x
MicroSOM from Solidrun, similarly
to Clearfog.
This device has:
-Armada 38x CPU
(dual core ARMv7 1.6 Ghz)
-2 GB of ECC RAM
-Gigabit ethernet (Marvell)
-2x USB 3.0 ports
-4x Sata 3.0 ports
-i2c header (J9 |>GND|SDA|SCL|VCC)
-2x 3-pin fan headers with PWM
-micro-usb port is a TTL/UART to
USB converter connected to TTL
-MicroSD card slot
-System, 4xSata and 1xUSB LEDs
NOT WORKING: fan control
Fan Control requires a kernel patch
that is available in the Armbian
project (the "default firmware"
of this device) and named
mvebu-gpio-remove-hardcoded
-timer-assignment
This patch isn't acceptable
by OpenWrt, it should be upstreamed.
I also have that patch in my own
local OpenWrt builds,
in case you want a more
clean and less confusing patch
for upstreaming.
To install, write the disk image
on a micro SD card with dd or
win32 disk imager, insert the
card in the slot.
Check that the dip switch battery
for boot selection is as follows
Switch 1 and 2 down/off, switches
3, 4, 5 up/on.
Signed-off-by: Alberto Bursi <bobafetthotmail@gmail.com>
This patch adds support for D-Link DIR-867 A1 and D-Link DIR-882 A1. Given
the similarity of these devices, this patch also introduces a common DTS
shared between DIR-867 A1, DIR-878 A1 and DIR-882 A1.
Specifications:
* Board: AP-MTKH7-0002
* SoC: MediaTek MT7621AT
* RAM: 128 MB (DDR3)
* Flash: 16 MB (SPI NOR)
* WiFi: MediaTek MT7615N (x2)
* Switch: 1 WAN, 4 LAN (Gigabit)
* Ports: 1 USB 2.0, 1 USB 3.0
* Buttons: Reset, WiFi Toggle, WPS
* LEDs: Power (green/orange), Internet (green/orange), WiFi 2.4G (green),
WiFi 5G (green), USB 2.0 (green), USB 3.0 (green)
Notes:
* WiFi 2.4G and WiFi 5G LEDs are wired directly to the wireless chips
* DIR-867 wireless chips are limited to 3x3 streams at hardware level
* USB ports and related LEDs available only on DIR-882
Serial port:
* Parameters: 57600, 8N1
* Location: J1 header (close to the Reset, WiFi and WPS buttons)
* Pinout: 1 - VCC
2 - RXD
3 - TXD
4 - GND
Installation:
* D-Link Recovery GUI: power down the router, press and hold the reset
button, then re-plug it. Keep the reset button pressed until the power
LED starts flashing orange, manually assign a static IP address under
the 192.168.0.xxx subnet (e.g. 192.168.0.2) and go to http://192.168.0.1
* Some modern browsers may have problems flashing via the Recovery GUI,
if that occurs consider uploading the firmware through cURL:
curl -v -i -F "firmware=@file.bin" 192.168.0.1
Signed-off-by: Mateus B. Cassiano <mbc07@live.com>
[move DEVICE_VARIANT to individual definitions] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Everything works! Been running it for a couple weeks now and haven't had
any problems. Please let me know if you run into any.
Installation:
Flash factory image through GUI.
This might fail due to the A/B nature of this device. When flashing, OEM
firmware writes over the non-booted partition. If booted from 'A',
flashing over 'B' won't work. To get around this, you should flash the
OEM image over itself. This will then boot the router from 'B' and
allow you to flash OpenWRT without problems.
Reverting to factory firmware:
Hard-reset the router three times to force it to boot from 'B.' This is
where the stock firmware resides. To remove any traces of OpenWRT from
your router simply flash the OEM image at this point.
Signed-off-by: Santiago Rodriguez-Papa <contact@rodsan.dev>
[use v1 only, minor DTS adjustments, use LINKSYS_HWNAME and add it to
DEVICE_VARS, wrap DEVICE_PACKAGES, adjust commit message/title] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This harmonizes the model names for the ath79 Ubiquiti devices by
applying a few minor cosmetic adjustments:
- Removes hyphens where they are not found in the product names
(Ubiquiti uses hyphens only for the abbreviated version names
like UAP-AC-PRO which we don't use anyway.)
- Add (XM) suffix for DTS model strings to help with distinguishing
them from their XW counterparts.
- Remove DEVICE_VARIANT for LAP-120 which actually was an alternate
device name.
- Generally make DTS model names and those from generic-ubnt.mk
more consistent.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
package: drop PKG_VERSION for purely local packages
In the package guidelines, PKG_VERSION is supposed to be used as
"The upstream version number that we're downloading", while
PKG_RELEASE is referred to as "The version of this package Makefile".
Thus, the variables in a strict interpretation provide a clear
distinction between "their" (upstream) version in PKG_VERSION and
"our" (local OpenWrt trunk) version in PKG_RELEASE.
For local (OpenWrt-only) packages, this implies that those will only
need PKG_RELEASE defined, while PKG_VERSION does not apply following
a strict interpretation. While the majority of "our" packages actually
follow that scheme, there are also some that mix both variables or
have one of them defined but keep them at "1".
This is misleading and confusing, which can be observed by the fact
that there typically either one of the variables is never bumped or
the choice of the variable to increase depends on the person doing the
change.
Consequently, this patch aims at clarifying the situation by
consistently using only PKG_RELEASE for "our" packages. To achieve
that, PKG_VERSION is removed there, bumping PKG_RELEASE where
necessary to ensure the resulting package version string is bigger
than before.
During adjustment, one has to make sure that the new resulting composite
package version will not be considered "older" than the previous one.
A useful tool for evaluating that is 'opkg compare-versions'. In
principle, there are the following cases:
1. Sole PKG_VERSION replaced by sole PKG_RELEASE:
In this case, the resulting version string does not change, it's
just the value of the variable put in the file. Consequently, we
do not bump the number in these cases so nobody is tempted to
install the same package again.
2. PKG_VERSION and PKG_RELEASE replaced by sole PKG_RELEASE:
In this case, the resulting version string has been "version-release",
e.g. 1-3 or 1.0-3. For this case, the new PKG_RELEASE will just
need to be higher than the previous PKG_VERSION.
For the cases where PKG_VERSION has always sticked to "1", and
PKG_RELEASE has been incremented, we take the most recent value of
PKG_RELEASE.
Apart from that, a few packages appear to have developed their own
complex versioning scheme, e.g. using x.y.z number for PKG_VERSION
_and_ a PKG_RELEASE (qos-scripts) or using dates for PKG_VERSION
(adb-enablemodem, wwan). I didn't touch these few in this patch.
Cc: Hans Dedecker <dedeckeh@gmail.com> Cc: Felix Fietkau <nbd@nbd.name> Cc: Andre Valentin <avalentin@marcant.net> Cc: Matthias Schiffer <mschiffer@universe-factory.net> Cc: Jo-Philipp Wich <jo@mein.io> Cc: Steven Barth <steven@midlink.org> Cc: Daniel Golle <dgolle@allnet.de> Cc: John Crispin <john@phrozen.org> Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Bumping package version has been overlooked in a previous commit.
While at it, use PKG_RELEASE instead of PKG_VERSION, as the latter
is meant for upstream version number only.
(The effective version string for the package would be "3" in both
cases, so there is no harm done for version comparison.)
Flashing via WebUI:
Upload the factory image via the stock firmware web UI.
Attention: airOS firmware versions >= 5.6 have a new bootloader with
an incompatible partition table!
Please downgrade to <= 5.5 _before_ flashing OpenWrt!
Refer to the device's Wiki page for further information.
Flashing via TFTP:
Same procedure as other Bullet M (XM) boards.
- Use a pointy tool (e.g., pen cap, paper clip) and keep the reset
button on the device or on the PoE supply pressed
- Power on the device via PoE (keep reset button pressed)
- Keep pressing until LEDs flash alternatively LED1+LED3 =>
LED2+LED4 => LED1+LED3, etc.
- Release reset button
- The device starts a TFTP server at 192.168.1.20
- Set a static IP on the computer (e.g., 192.168.1.21/24)
- Upload via tftp the factory image:
$ tftp 192.168.1.20
tftp> bin
tftp> trace
tftp> put openwrt-ath79-generic-xxxxx-ubnt_powerbridge-m-squashfs-factory.bin
Signed-off-by: Vieno Hakkerinen <vieno@hakkerinen.eu>