The mt7621 subtarget has been switched to DSA quite a while ago and
seems to run sufficiently fine. Build with older kernels than 5.4 has
been disabled directly during the kernel bump, so our local ethernet
driver is unused in master since then.
Therefore, let's remove the mt7621-specific parts of "our" ethernet
driver, so we don't have to maintain them and it's obvious to
everybody that they are not used anymore.
This also drops the offloading components as this was specifically
implemented to depend on mt7621.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Remove local diag.sh in favor of generic one and add the required
led-* aliases to DTS.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This uses the vendor_model scheme for the device/image name in
order to make this consistent to most other targets.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This refreshes the patches, removes patches already applied upstream and
removes the SPI NAND framework to use the upstream version.
In addition it also refreshes the kernel configuration.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This adds support for the TP-Link TL-WR710N v2.1. It is basically a
re-issue of the v1.2.
Specifications:
SoC: Atheros AR9331
CPU: 400 MHz
Flash: 8 MiB
RAM: 32 MiB
WiFi: 2.4 GHz b/g/n
Ethernet: 2x 100M ports
USB: 1x 2.0
The only difference from the v1 is the TP-Link hardware ID/revision.
Attention:
The TL-WR710N v2.0 (!) has only 4 MB flash and cannot be flashed with
this image. It has a different TPLINK_HWREV, so accidental flashing
of the factory image should be impossible without additional measures.
Unfortunately, the v2.0 in ar71xx has the same board name, so sysupgrade
from ar71xx v2.0 into ath79 v1/v2.1 will not be prevented, but will brick
the device.
Flashing instruction:
Upload the factory image via the OEM firmware GUI upgrade mechanism.
Further notes:
To make implementation easier if somebody desires to port the 4M v2.0,
this already creates two DTSI files.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Tested-by: Fabian Eppig <fabian@eppig.de>
As described in commit commit 891a700759 ("lantiq: enable second VPE
on Fritz!Box 7412"):
The AVM Fritz!Box 7412 does not use the VMMC part of the Lantiq chip but
rather a proprietary solution based on the DECT chip for the FXS ports.
We can remove last traces of vmmc in dts.
Signed-off-by: Aleksander Jan Bajkowski <A.Bajkowski@stud.elka.pw.edu.pl>
The layerscape kernel patches appears to be just some uncleaned local
development tree, where patches are sometimes directly followed by
their revert. While this does not seem a problem in the first place,
it becomes incredibly unpleasant when the upstream kernel changes in
the relevant areas and requires rebase.
This removes all these patch-revert pairs and refreshs the rest.
It removes about 44000 lines of entirely useless code.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
In order to support SAE/WPA3-Personal in default images. Replace almost
all occurencies of wpad-basic and wpad-mini with wpad-basic-wolfssl for
consistency. Keep out ar71xx from the list as it won't be in the next
release and would only make backports harder.
Build-tested (build-bot settings):
ath79: generic, ramips: mt7620/mt76x8/rt305x, lantiq: xrx200/xway,
sunxi: a53
Signed-off-by: Petr Štetiar <ynezz@true.cz>
[rebase, extend commit message]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Patch 1 introduces a change, and patch 2 reverts it again. Remove
both patches and achieve the same outcome.
Refreshed patches for the target as well.
Cc: Álvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Acked-by: Álvaro Fernández Rojas <noltari@gmail.com>
This PR is a blend of several kernel bumps authored by ldir taken from his
staging tree w/ some further adjustments made by me and update_kernel.sh
Summary:
Deleted upstreamed patches:
generic:
742-v5.5-net-sfp-add-support-for-module-quirks.patch
743-v5.5-net-sfp-add-some-quirks-for-GPON-modules.patch
bcm63xx:
022-v5.8-mtd-rawnand-brcmnand-correctly-verify-erased-pages.patch
024-v5.8-mtd-rawnand-brcmnand-fix-CS0-layout.patch
mediatek:
0402-net-ethernet-mtk_eth_soc-Always-call-mtk_gmac0_rgmii.patch
Deleted patches applied differently upstream:
generic:
641-sch_cake-fix-IP-protocol-handling-in-the-presence-of.patch
Manually merged patches:
generic:
395-v5.8-net-sch_cake-Take-advantage-of-skb-hash-where-appropriate.patch
bcm27xx:
950-0132-lan78xx-Debounce-link-events-to-minimize-poll-storm.patch
layerscape:
701-net-0231-enetc-Use-DT-protocol-information-to-set-up-the-port.patch
Build system: x86_64
Build-tested: ath79/generic, bcm27xx/bcm2708, bcm27xx/bcm2711,
imx6, mvebu/cortexa9, sunxi/a53
Run-tested: Netgear R7800 (ipq806x)
No dmesg regressions, everything functional
Signed-off-by: John Audia <graysky@archlinux.us>
Tested-By: Lucian Cristian <Lucian.cristian@gmail.com> [mvebu]
Tested-By: Curtis Deptuck <curtdept@me.com> [x86/64]
[do not remove 395-v5.8-net-sch_cake-Take-advantage-... patch,
adjust and refresh patches, adjust commit message]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Tested-By: John Audia <graysky@archlinux.us> [ipq806x]
On Mikrotik SPI NOR devices, the firmware partition must be erased when
flashing from stock firmware, otherwise leftover bits (in particular a
kernel signature) can trigger a boot loop.
When booted from initramfs (the only way to install OpenWRT on these
devices), this patch unconditionally erases the firmware partition in
the do_upgrade() stage for all supported SPI NOR devices.
This is forward-ported from ed49d0876 and 20452a8db
Signed-off-by: Thibaut VARÈNE <hacks@slashdirt.org>
This reverts commit b1f6a5d9df.
In this particular case, the echo command was _not_ useless, but
converted the newlines back to spaces.
Add a comment into the code to make that obvious for the next one
looking at it like me.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The output is already produced in the inner $() brackets, no need
to catch and echo it again.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The node needs to be terminated by a semicolon.
Fixes: 8484a764df ("ath79: ar724x: make sure builtin-switch is
enabled in DT")
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Both TL-WPA8630(P) v1 and v2 feature a button labelled "WiFi".
While this is implemented as KEY_RFKILL for v1 in ar71xx and ath79,
the v2 sets it up as WPS button.
According to the manual, the behavior in OEM firmware is:
"Press and hold the button for 1 second to copy wireless settings
from the main router to the extender. Go to Wi-Fi Clone for more
information. Press and hold the button for at least 5 seconds to
turn the wireless function on or off."
Consequently, and since this is historic behavior on v1 in OpenWrt,
we set this button to KEY_RFKILL on both revisions.
Fixes: ab74def0db ("ath79: add support for TP-Link TL-WPA8630P v2")
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The moves a few additional common nodes to the common DTSI files
for qcom-ipq8064-v2.0 and qcom-ipq8065 devices.
Remove a few redundant definitions on the way.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
On ar7240/ar7241 the mdioX node with the builtin-switch is enabled
in the DTSI files, but the parent ethX node is left disabled. It
only gets enabled per device or device family, and has not been
enabled at all yet for the TP-Link WA devices with ar7240, making
the switch unavailable there.
This patch makes sure ð0/ð1 nodes are enabled together with
the &mdio0/&mdio1 nodes containing the builtin-switch.
For ar7240_tplink_tl-wa.dtsi, ð0 is properly hidden again via
compatible = "syscon", "simple-mfd";
This partially fixes FS#2887, however it seems dmesg still does
not show cable (dis)connect in dmesg for ar7240 TP-Link WA
devices.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The leds block was copied over from the RT-AC85P DTS to the common
DTSI while keeping the device-specific model name in the label.
This moves the LEDs back to the DTS files and adjusts the names to
properly resemble the model name of the devices used at, just like
it is handled on most other devices.
Fixes: 7c5f712e4f ("ramips: add support for Asus RT-AC65P")
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This files have been emptied during subtarget consolidation, but
not removed. Remove them now.
Fixes: aff084adf3 ("at91: Merge SAMA5 subtargets")
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Itus Networks Shield - 1Ghz dual-core mips64 / Cavium Octeon 3 SoC,
1Gb RAM, 4Gb eMMC,3 GbE 10/100/1000 ports
Information regarding device can be found:
https://deviwiki.com/wiki/Itus_Networks_Shield_Pro
Installing OpenWrt on Itus Networks Shield:
1) Boot Shield
2) On device: mount /dev/mmcblk1p1 /mnt
3) scp openwrt-octeon-itus,shield-router-initramfs-kernel.bin to
/mnt/ItusrouterImage
3a) Optionally: scp openwrt-octeon-itus,shield-router-initramfs-kernel.bin
to /mnt/ItusgatewayImage to allow you to have an emergency recovery
boot in the GATEWAY slot - this slot will have no permament storage and
is used for emergency recovery only when booted in the (G)ateway
position
4) On device: umount /mnt
5) reboot
Once booted, run the sysupgrade via cli or luCi on the
openwrt-octeon-itus,shield-router-squashfs-sysupgrade.tar file the mode
you are running.
Once rebooted, the system installation is complete. Your storage partition
for the mode is inialized and set.
Signed-off-by: Donald Hoskins <grommish@gmail.com>
[cut out sysupgrade-* changes, move a few lines,
drop case CVMX_BOARD_TYPE_ITUS_SHIELD]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
So far, the sysupgrade-* folder used during upgrade in octeon was
hardcoded to contain the board name. Therefore, changing board name
or BOARD_NAME variable in image/Makefile might have broken upgrade.
Improve this by adding a step to determine the folder name via
a wildcard, as it is done for generic nand_upgrade_tar() in
lib/upgrade/nand.sh.
While this still does not remove the problem for existing devices
(which still have the old script), it will entirely remove the
issue on newly added devices on this platform.
Signed-off-by: Donald Hoskins <grommish@gmail.com>
[split into separate patch, add commit message, add return values]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This renames board patches to make finding devices easier
and reorders them based on their board.
The devices are grouped based on the board/cpu_id. New device
patches should be numbered based on their group.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
ALLNET ALL-WAP02860AC is a dual-band wireless access point.
Specification
SoC: Qualcomm Atheros QCA9558
RAM: 128 MB DDR2
Flash: 16 MB SPI NOR
WIFI: 2.4 GHz 3T3R integrated
5 GHz 3T3R QCA9880 Mini PCIe card
Ethernet: 1x 10/100/1000 Mbps AR8035-A, PoE capable (802.3at)
LEDS: 5x, which four are GPIO controlled
Buttons: 1x GPIO controlled
UART: 4 pin header near Mini PCIe card, starting count from white
triangle on PCB
1. VCC 3.3V, 2. GND, 3. TX, 4. RX
baud: 115200, parity: none, flow control: none
MAC addresses
Calibration data does not contain valid MAC addresses.
The calculated MAC addresses are chosen in accordance with OEM firmware.
Because of:
a) constrained environment (SNMP) when connecting through Telnet
or SSH,
b) hard-coded kernel and rootfs sizes,
c) checksum verification of kerenel and rootfs images in bootloder,
creating factory image accepted by OEM web interface is difficult,
therefore, to install OpenWrt on this device UART connection is needed.
The teardown is simple, unscrew four screws to disassemble the casing,
plus two screws to separate mainboard from the casing.
Before flashing, be sure to have a copy of factory firmware, in case You
wish to revert to original firmware.
Installation
1. Prepare TFTP server with OpenWrt initramfs-kernel image.
2. Connect to LAN port.
3. Connect to UART port.
4. Power on the device and when prompted to stop autoboot, hit any key.
5. Alter U-Boot environment with following commands:
setenv failsafe_boot bootm 0x9f0a0000
saveenv
6. 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
7. Wait about 1 minute for OpenWrt to boot.
8. Transfer OpenWrt sysupgrade image to /tmp directory and flash it
with:
sysupgrade -n /tmp/<openwrt_sysupgrade_image_name>
9. After flashing, the access point will reboot to OpenWrt. Wait few
minutes, until the Power LED stops blinking, then it's ready for
configuration.
Signed-off-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
[add MAC address comment to commit message]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The malta subtargets for mips64 and mips64el fail to start the init process
at boot, resulting in a boot loop. The issue was raised and analyzed within
FS#3277. Investigation suggested code near the [vdso] memory area of the
process was long jumping into a region inaccessible to the process, e.g.
init: - preinit -
init: Launched preinit instance, pid=522
do_page_fault(): sending SIGSEGV to init for invalid read access from 0000000000000360
epc = 0000000000000360 in init[aaab42b000+4000]
ra = 000000fffee385e0 in
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
Rebooting in 1 seconds..
Note the low-memory read access and epc are the same. Upstream kernel 5.6
included a relevant patch and discussion:
* d3f703c4359f ("mips: vdso: fix 'jalr t9' crash in vdso code")
Disassembly of the failing kernel's vdso.so confirmed presence of the
telltale long jumps, e.g.:
00000000000007c0 <__vdso_clock_getres@@LINUX_2.6>:
[...]
7dc: 0320f809 jalr t9
[...]
Restore booting mips64/mips64el malta by backporting the above commit:
* 310-v5.6-mips-vdso-fix-jalr-t9-crash-in-vdso-code.patch
Fixes: 54310a3aa0 ("malta: add kernel 5.4 config")
Fixes: FS#3277
Ref: https://bugs.openwrt.org/index.php?do=details&task_id=3277
Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
This ports the TP-Link TL-WPA8630 v1 from ar71xx to ath79.
Specifications:
SoC: QCA9563
CPU: 750 MHz
Flash/RAM: 8 / 128 MiB
Ethernet: 3x 1G ports (QCA8337 switch)
WLAN: 2.4 GHz b/g/n, 5 GHz a/n/ac (ath10k)
Buttons, LEDs and network setup appear to be almost identical
to the v2 revision.
Powerline interface is connected to switch port 5 (Label LAN4).
Installation:
No "fresh" device was available for testing the factory image.
It is not known whether flashing via OEM firmware GUI is possible
or not. A discussion from 2018 [1] about that indicates a few
adjustments are necessary, but it is not clear whether those
are already implemented with the TPLINK_HEADER_VERSION = 2 or not.
Note that for the TL-WPA8630P v1, the TPLINK_HWID needs to be
changed to 0x86310001 to allow factory flashing.
[1] https://forum.openwrt.org/t/solved-tl-wpa8630p-lede-does-not-install/8161/27
Recovery:
Recovery is only possible via serial.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The commands to read ath9k caldata on mikrotik subtarget are
mostly repetitive, so let's put them into a function to make
writing and reading them easier.
This function will only be required when patching the MAC address.
For cases where it is put correctly into the calibration data by
the vendor, caldata_sysfsload_from_file can be used directly as
done for ath10k at the moment.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This patch adds support for the MikroTik RouterBOARD 760iGS router.
It is similar to the already supported RouterBOARD 750Gr3.
The 760iGS device features an added SFP cage, and passive
PoE out on port 5 compared to the RB750Gr3.
https://mikrotik.com/product/hex_s
Specifications:
- SoC: MediaTek MT7621A
- CPU: 880MHz
- Flash: 16 MB
- RAM: 256 MB
- Ethernet: 5x 10/100/1000 Mbps
- SFP cage
- USB port
- microSD slot
Unsupported:
- Beeper (requires PWM driver)
- ZT2046Q (ADS7846 compatible) on SPI as slave 1 (CS1)
The linux driver requires an interrupt, and pendown GPIO
These are unknown, and not needed with the touchscreen
only used for temperature and voltage monitoring.
ads7846 hwmon:
temp0 is degrees Celsius
temp1 is voltage * 32
GPIOs:
- 07: input passive PoE out (lan5) compatible (Mikrotik) device connected
- 17: output passive PoE out (lan5) switch
Installation through RouterBoot follows the usual MikroTik method
https://openwrt.org/toh/mikrotik/common
To boot to intramfs image in RAM:
1. Setup TFTP server to serve intramfs image.
2. Plug Ethernet cable into WAN port.
3. Unplug power, hold reset button and plug power in.
Wait (~25 seconds) for beep and then release reset button.
The SFP LED will be lit in RouterBoot, but will not be lit in OpenWRT.
4. Wait for a minute. Router should be running OpenWrt,
check by plugging in to port 2-5 and going to 192.168.1.1.
To install OpenWrt to flash:
1. Follow steps above to boot intramfs image in RAM.
2. Flash the sysupgrade.bin image with web interface or sysupgrade.
3. Once the router reboots you will be running OpenWrt from flash.
OEM firmware differences:
- RouterOS assigns a different MAC address for each port
- The first address (E01 on the sticker) is used for wan (ether1 in OEM).
- The next address is used for lan2.
- The last address (E06 on the sticker) is used for sfp.
[Initial port work, shared dtsi]
Signed-off-by: Vince Grassia <vincenzo.grassia@zionark.com>
[SFP support and GPIO identification]
Signed-off-by: Luka Logar <luka.logar@iname.com>
[Misc. fixes and submission]
Signed-off-by: John Thomson <git@johnthomson.fastmail.com.au>
[rebase, drop uart3 from state_default on 750gr3, minor commit
title/message facelift]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This moves some common definitions for Mikrotik devices, mainly
routerboot partitions and reset key, to a common DTSI file.
While at it, remove unused hard_config DT label.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This beeper hardware requires a PWM driver for frequency selection.
Since the GPIO driver does not provide that, revert the beeper
support to a simple gpio-export.
This effectively reverts the corresponding changes from
6ba58b7b02 ("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>
This driver is only used by ipq806x SoCs. Move it there and drop
dependency from ipq40xx since it's not used anywere.
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
[rebase on changes to previous patches]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Tested-by: Paul Blazejowski <paulb@blazebox.homeip.net> [R7800]
- Replace nvmem qcom patch with upstream version
- Update compatible
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
[refresh patches, minor commit message rewording]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Tested-by: Paul Blazejowski <paulb@blazebox.homeip.net> [R7800]
- Replace dwc3 phy patch with upstream version
- Rework the dts to use the upstream bindings
- Update changed config flags
- Rename module to reflect config name
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
[fix qcom,tx-deamp_3_5db typo, refresh patches, rename kmod]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Tested-by: Paul Blazejowski <paulb@blazebox.homeip.net> [R7800]
The missing "size" property was acceptable in the context of a single
DTS as the underlying device is known to have a 64KB flash, and thus
the bios partition fit exactly between the preceding and following ones.
However as this block has moved in a DTSI, for the sake of clarity and
explicitness the size property is added to ensure that if the flash
happens to be larger than expected, the bios partition remains properly
sized.
Suggested-by: Thibaut VARÈNE <hacks@slashdirt.org>
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This harmonizes the appearance of ethX nodes in qca953x DTSes by:
- having the same order of nodes and properties
- removing redundant status property on eth1 (set in qca953x.dtsi)
This is meant to help both copy-pasters and reviewers, since
deviations and errors can be spotted easier.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
After those symbols have been removed from generic kernel config,
they were added to the target config during every kernel config
refresh. As that's not desirable, add them back to the generic
config.
Fixes: d1a8217d87 ("kernel: clean-up build-configurable kernel config symbols")
Fixes: cfe235c436 ("kernel: modules: add package kmod-iosched-bfq")
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The MikroTik SXT Lite5 (product code RBSXT5nDr2, also SXT 5nD r2) is
an outdoor 5GHz CPE with a 16 dBi integrated antenna built around the
Atheros AR9344 SoC. It is based on the "sxt5n" board platform.
Specifications:
- SoC: Atheros AR9344
- RAM: 64 MB
- Storage: 128 MB NAND
- Wireless: Atheros AR9340 (SoC) 802.11a/n 2x2:2
- Ethernet: Atheros AR8229 switch (SoC), 1x 10/100 port,
8-32 Vdc PoE in
- 6 user-controllable LEDs:
· 1x power (blue)
· 1x wlan (green)
· 4x rssi (green)
- 1 GPIO-controlled buzzer
See https://mikrotik.com/product/RBSXT5nDr2 for more details.
Notes:
The device was already supported in the ar71xx target. There, the
Ethernet port was handled by GMAC1. Here in ath79 it is handled by
GMAC0, which allows to get link information (loss, speed, duplex) on
the eth0 interface.
Flashing:
TFTP boot initramfs image and then perform sysupgrade. Follow common
MikroTik procedure as in https://openwrt.org/toh/mikrotik/common.
Acknowledgments:
Michael Pratt (@mpratt14) for helping on the network settings.
Signed-off-by: Roger Pueyo Centelles <roger.pueyo@guifi.net>
[rebase, use mikrotik LED label prefix, make names consistent,
add reg for bootloader2, use led_user for boot indication etc.,
minor cosmetic changes]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The MikroTik RouterBOARD 921GS-5HPacD-15s (mANTBox 15s) is an outdoor
antenna for 5 GHz with an built-in router. This ports the board from
ar71xx.
See https://mikrotik.com/product/RB921GS-5HPacD-15S for more info.
Specifications:
- SoC: Qualcomm Atheros QCA9558 (720 MHz)
- RAM: 128 MB
- Storage: 128 MB NAND
- Wireless: external QCA9892 802.11a/ac 2x2:2
- Ethernet: 1x 1000/100/10 Mbps, integrated, via AR8031 PHY, passive PoE in
- SFP: 1x host
Working:
- NAND storage detection
- Ethernet
- Wireless
- 1x user LED (blinks during boot, sysupgrade)
- Reset button
- Sysupgrade
Untested:
- SFP cage (probably not working)
Installation (untested):
- Boot initramfs image via TFTP and then flash sysupgrade image
As the embedded RB921-pcb is a stripped down version of the RB922 this patch
adds a common dtsi for this series and includes this to the final dts-files.
Signed-off-by: Sven Roederer <devel-sven@geroedel.de>
[move ath10k-leds closer to ath10k definition in DTS files]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The MikroTik RouterBOARD LHG 2nD (sold as LHG 2) is a 2.4 GHz
802.11b/g/n outdoor device with a feed and an integrated dual
polarization grid dish antenna based on the LHG-HB platform.
See https://mikrotik.com/product/lhg_2 for more info.
Specifications:
- SoC: Qualcomm Atheros QCA9533
- RAM: 64 MB
- Storage: 16 MB NOR
- Wireless: Atheros AR9531 (SoC) 802.11b/g/n 2x2:2, 18 dBi antenna
- Ethernet: Atheros AR8229 (SoC), 1x 10/100 port, 12-28 Vdc PoE in
- 8 user-controllable LEDs:
· 1x power (blue)
· 1x user (green)
· 1x lan (green)
· 1x wlan (green)
· 4x rssi (green)
Note:
The rssihigh LED is disabled, as it shares GPIO 16 with the reset
button.
Flashing:
TFTP boot initramfs image and then perform sysupgrade. Follow common
MikroTik procedure as in https://openwrt.org/toh/mikrotik/common.
Signed-off-by: Roger Pueyo Centelles <roger.pueyo@guifi.net>
[rebase, remove rssiled setup, adjust commit message, add DTSIs]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Most targets have been updated to consistently use the vendor_model
scheme for device definitions and thus, image names.
Apply this to bcm47xx as well. This does _not_ apply any other
specific naming changes.
Cc: Rafał Miłecki <rafal@milecki.pl>
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Most targets have been updated to consistently use the vendor_model
scheme for device definitions and thus, image names.
Apply this to bcm53xx as well. This does _not_ apply any other
specific naming changes.
Cc: Rafał Miłecki <rafal@milecki.pl>
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This fixes the following build problem with cake:
net/sched/act_ctinfo.c: In function 'tcf_ctinfo_act':
net/sched/act_ctinfo.c:99:6: error: implicit declaration of function 'tc_skb_protocol'; did you mean 'skb_protocol'? [-Werror=implicit-function-declaration]
if (tc_skb_protocol(skb) == htons(ETH_P_IP)) {
^~~~~~~~~~~~~~~
skb_protocol
CC [M] net/sched/sch_hfsc.o
Fixes: fdac05b741 ("kernel: Update kernel 4.19 to version 4.19.138")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
In commit 87b35c16ad ("kernel: ubifs: create use file system format 4
by default") we changed the default UBIFS version used when the kernel
creates a new volume from 5 to 4. UBIFS v5 was added in kernel 4.10 and
only kernel 4.10 and later can read it.
We changed the kernel to create version 4 volumes also on more recent
kernel versions to make it possible to downgrade to an OpenWrt version
with kernel 4.9, the upgrade still works. This is probably not needed
any more and we can remove this patch.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The CDROM is not needed for booting and can be included by selecting the
loadable module as a package instead.
This also avoids triggering a memory allocation failure during probing of
the CDROM due to lack of low 16MB DMA memory, as decribed in FS#3278:
https://bugs.openwrt.org/index.php?do=details&task_id=3278
Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
Link: https://github.com/openwrt/openwrt/pull/3289
Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com>
After years of trying to find the reason for random kernel crashes
while both CPU and SATA are under load it has been found.
Some odd commented-out #defines in kref's single-port driver [1] which
were copied from the vendor driver made me develop a theory:
The IO-mapped memory area for DMA descriptors apparetly got some holes
just before the alignment boundaries.
This feels like an off-by-one bug in the hardware or maybe those fields
are used internally by the SATA controller's firmware.
Whatever the cause is: they cannot be used and trying to use them
results in reading back unexpected stuff and ends up with oopsing
Unable to handle kernel paging request at virtual address d085c004
Work around the issue by reducing the area used for bmdma descriptors.
This reduces SATA performance (iops) quite a bit, but finally makes
things work reliably. Possibly one could optimize this much more by
really just skipping the holes in that memory area -- however, that
seems to be non-trivial with the driver and libata in it's current form
(suggestions are welcome).
The 'proper' way to have good SATA performance would be to make use of
the hardware RAID features (one can use the JBOD mode to access even
just a single disc transparently through the RAID controller integrated
in the SATA host instead of accessing the SATA ports 'raw' as we do
now).
[1]: https://github.com/kref/linux-oxnas/blob/master/drivers/ata/sata_oxnas.c#L25
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
It is deactivated everywhere, just set this in the generic config.
Acked-by: Yousong Zhou <yszhou4tech@gmail.com>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This refreshes the kernel configuration on top of kernel 5.4.
It now builds without asking to select some kernel options on all 4
subtargets.
It still does not boot up, there is a different problem.
Tested-By: Yousong Zhou <yszhou4tech@gmail.com>
Acked-By: Yousong Zhou <yszhou4tech@gmail.com>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Specifications:
SoC: Qualcomm Atheros QCA9557
RAM: 128 MB (Nanya NT5TU32M16EG-AC)
Flash: 16 MB (Macronix MX25L12845EMI-10G)
Ethernet: 5x 10/100/1000 (1x WAN, 4x LAN)
Wireless: QCA9557 2.4GHz (nbg), QCA9882 5GHz (ac)
USB: 2x USB 2.0 port
Buttons: 1x Reset
Switches: 1x Wifi
LEDs: 11 (Pwr, WAN, 4x LAN, 2x Wifi, 2x USB, WPS)
MAC addresses:
WAN *:3f uboot-env ethaddr + 3
LAN *:3e uboot-env ethaddr + 2
2.4GHz *:3c uboot-env ethaddr
5GHz *:3d uboot-env ethaddr + 1
The label contains all four MAC addresses, however the one without
increment is first, so this one is taken for label MAC address.
Notes:
The Wifi is controlled by an on/off button, i.e. has to be implemented
by a switch (EV_SW). Despite, it appears that GPIO_ACTIVE_HIGH needs
to be used, just like recently fixed for the NBG6716.
Both parameters have been wrong at ar71xx.
Flash Instructions:
At first the U-Boot variables need to be changed in order to boot the
new combined image format. ZyXEL uses a split kernel + root setup and
the current kernel is too large to fit into the partition. As resizing
didnt do the trick, I've decided to use the prefered combined image
approach to be future-kernel-enlargement-proof (thanks to blocktrron for
the assistance).
First add a new variable called boot_openwrt:
setenv boot_openwrt bootm 0x9F120000
After that overwrite the bootcmd and save the environment:
setenv bootcmd run boot_openwrt
saveenv
After that you can flash the openwrt factory image via TFTP. The servers
IP has to be 192.168.1.33. Connect to one of the LAN ports and hold the
WPS Button while booting. After a few seconds the NBG6616 will look for
a image file called 'ras.bin' and flash it.
Return to vendor firmware is possible by resetting the bootcmd:
setenv bootcmd run boot_flash
saveenv
and flashing the vendor image via the TFTP method as described above.
Accessing the U-Boot Shell:
ZyXEL uses a proprietary loader/shell on top of u-boot: "ZyXEL zloader v2.02"
When the device is starting up, the user can enter the the loader shell
by simply pressing a key within the 3 seconds once the following string
appears on the serial console:
| Hit any key to stop autoboot: 3
The user is then dropped to a locked shell.
| NBG6616> ?
| ATEN x,(y) set BootExtension Debug Flag (y=password)
| ATSE x show the seed of password generator
| ATSH dump manufacturer related data in ROM
| ATRT (x,y,z,u) ATRT RAM read/write test (x=level, y=start addr, z=end addr, u=iterations
| ATGO boot up whole system
| ATUR x upgrade RAS image (filename)
In order to escape/unlock a password challenge has to be passed.
Note: the value is dynamic! you have to calculate your own!
First use ATSE $MODELNAME (MODELNAME is the hostname in u-boot env)
to get the challange value/seed.
| NBG6616> ATSE NBG6616
| 00C91D7EAC3C
This seed/value can be converted to the password with the help of this
bash script (Thanks to http://www.adslayuda.com/Zyxel650-9.html authors):
- tool.sh -
ror32() {
echo $(( ($1 >> $2) | (($1 << (32 - $2) & (2**32-1)) ) ))
}
v="0x$1"
a="0x${v:2:6}"
b=$(( $a + 0x10F0A563))
c=$(( 0x${v:12:14} & 7 ))
p=$(( $(ror32 $b $c) ^ $a ))
printf "ATEN 1,%X\n" $p
- end of tool.sh -
| # bash ./tool.sh 00C91D7EAC3C
| ATEN 1,10FDFF5
Copy and paste the result into the shell to unlock zloader.
| NBG6616> ATEN 1,10FDFF5
If the entered code was correct the shell will change to
use the ATGU command to enter the real u-boot shell.
| NBG6616> ATGU
| NBG6616#
Signed-off-by: Christoph Krapp <achterin@googlemail.com>
[move keys to DTSI, adjust usb_power DT label, remove kernel config
change, extend commit message]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
A bunch of kernel modules depends on kmod-usb-net, but does not
select it. Make AddDepends/usb-net selective, so we can drop
some redundant +kmod-usb-net definitions for DEVICE_PACKAGES.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
SPI Flash chip supports up to 33 MHz wihout fast read opcode.
Available frequencies are 112.5, 56.25, 37.5, 28.125, 22.5 etc.
This patch increases the nominal maximum frequency to 33 MHz,
reaching an effective increase from 22.5 to 28.125 MHz.
Formula to calculate SPI frequency:
Freq = 225 MHz / 2 / div
Before:
$ time dd if=/dev/mtd1 of=/dev/null bs=8M
0+1 records in
0+1 records out
real 0m 3.58s
user 0m 0.00s
sys 0m 3.57s
After:
$ time dd if=/dev/mtd1 of=/dev/null bs=8M
0+1 records in
0+1 records out
real 0m 2.95s
user 0m 0.00s
sys 0m 2.93s
Signed-off-by: Aleksander Jan Bajkowski <A.Bajkowski@stud.elka.pw.edu.pl>
[minor commit message adjustments]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
When comparing to the port assignment in board.d/02_network, a few
devices seem to use the wrong setup of mediatek,portmap.
The corrects the values for mt76x8 subtarget based on the location
of the wan port.
A previous cleanup of obviously wrong values has already been done in
7a387bf9a0 ("ramips: mt76x8: fix bogus mediatek,portmap")
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The TL-WPA8630P v2 is a HomePlug AV2 compatible device with a QCA9563 SoC
and 2.4GHz and 5GHz WiFi modules.
Specifications
--------------
- QCA9563 750MHz, 2.4GHz WiFi
- QCA9888 5GHz WiFi
- 8MiB SPI Flash
- 128MiB RAM
- 3 GBit Ports (QCA8337)
- PLC (QCA7550)
MAC address assignment
----------------------
WiFi 2.4GHz and LAN share the same MAC address as printed on the label.
5GHz WiFi uses LAN-1, based on assumptions from similar devices.
LAN Port assignment
-------------------
While there are 3 physical LAN ports on the device, there will be 4
visible ports in OpenWrt. The fourth port (internal port 5) is used
by the PowerLine Communication SoC and thus treated like a regular
LAN port.
Versions
--------
Note that both TL-WPA8630 and TL-WPA8630P, as well as the different
country-versions, differ in partitioning, and therefore shouldn't be
cross-flashed.
This adds support for the two known partitioning variants of the
TL-WPA8630P, where the variants can be safely distinguished via the
tplink-safeloader SupportList. For the non-P variants (TL-WPA8630),
at least two additional partitioning schemes exist, and the same
SupportList entry can have different partitioning.
Thus, we don't support those officially (yet).
Also note that the P version for Germany (DE) requires the international
image version, but is properly protected by SupportList.
In any case, please check the OpenWrt Wiki pages for the device
before flashing anything!
Installation
------------
Installation is possible from the OEM web interface. Make sure to
install the latest OEM firmware first, so that the PLC firmware is
at the latest version. However, please also check the Wiki page
for hints according to altered partitioning between OEM firmware
revisions.
Additional thanks to Jon Davies and Joe Mullally for bringing
order into the partitioning mess.
Signed-off-by: Andreas Böhler <dev@aboehler.at>
[minor DTS adjustments, add label-mac-device, drop chosen, move
common partitions to DTSI, rename de to int, add AU support strings,
adjust TPLINK_BOARD_ID, create common node in generic-tp-link.mk,
adjust commit message]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
As the ath79 port of this device uses a combined kernel + root
partition the uboot bootcmd variable needs to be changed. As using
cli/luci is more convenient than opening up the case and using a uart
connection, lets unlock the uboot-env partition for write access.
Signed-off-by: Christoph Krapp <achterin@googlemail.com>
Add a specific comment for early DSA-adopters that they can keep
their config when prompted due to compat-version increase.
This is a temporary solution, the patch should be simply reverted
before any release.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This ports support for the TL-WA901ND v3 from ar71xx to ath79.
Most of the hardware is shared with the TL-WA850/860RE v1 range
extenders. It completes the TL-WA901ND series in ath79.
Specifications:
Board: AP123 / AR9341
Flash/RAM: 4/32 MiB
CPU: 535 MHz
WiFi: 2.4 GHz b/g/n
Ethernet: 1 port (100M)
Flashing instructions:
Upload the factory image via the vendor firmware upgrade option.
This has not been tested on device, but port from ar71xx is
straightforward and the device will be disabled by default anyway.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Replace all the custom patches with the backported upstream version
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
[refresh patches]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The ath79 target has CONFIG_LEDS_GPIO=y set in kernel config, so
no need to pull the kmod-leds-gpio module for specific devices.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This implements the newly introduced compat-version to prevent
broken upgrade between swconfig and DSA for ramips' mt7621 subtarget.
In order to make the situation more transparent for the user, and
to prevent large switch-cases for devices, it is more convenient to
have the entire subtarget 1.1-by-default. This means that new devices
will be added with 1.1 from the start, but in contrast we don't need
to switch them in board.d files. Apart from that, users that manually
backport devices to 19.07 with swconfig will have an equivalent
upgrade experience to officially supported devices.
Since DSA support on mt7621 is out for a while already, this applies
the same uci-defaults workaround for early adopters as already
done for kirkwood and mvebu in previous commits.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Conceptually, the compat-version during sysupgrade is meant to
describe the config. Therefore, if somebody starts with a device on
19.07 and swconfig, and that person does a forceful upgrade into a
DSA-based firmware without wiping his/her config, then the local
compat-version should stay at 1.0 according to the config present
(and not get updated).
However, this poses a problem for those people that early-adopted
DSA in master, as they already have adjusted their config for DSA,
but it still is "1.0" as far as sysupgrade is concerned. This can
be healed by a simple
uci set system.@system[0].compat_version="1.1"
uci commit system
But this needs to be applied _after_ the upgrade (as the "old" fwtool
on the old installation does not know about compat_version) and it
requires access via SSH (i.e. no pure GUI solution is available for
this group of people, apart from wiping their config _again_ for
no technical reason). Despite, the situation will not become
obvious to those just upgrading via GUI, they will just have the
experience of a "broken upgrade".
This is a conflict which cannot be resolved by achieving both goals,
we have to decide to either keep the strict concept or improve the
situation for early adopters.
In this patch, we address the issue by providing a uci-defaults
script that will raise the compat_version for _all_ people upgrading
into a 1.1 image, no matter whether they have reset config or not.
The idea is to implement this as a _temporary_ solution, so early
adopters can upgrade into the new mechanism without issues, and
after a few weeks/months we could remove the uci-defaults script
again.
If we e.g. remove the script just before 20.xx.0-rc1, early adopters
should have moved on by then, and existing stable users would still
get the intended experience.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Conceptually, the compat-version during sysupgrade is meant to
describe the config. Therefore, if somebody starts with a device on
19.07 and swconfig, and that person does a forceful upgrade into a
DSA-based firmware without wiping his/her config, then the local
compat-version should stay at 1.0 according to the config present
(and not get updated).
However, this poses a problem for those people that early-adopted
DSA in master, as they already have adjusted their config for DSA,
but it still is "1.0" as far as sysupgrade is concerned. This can
be healed by a simple
uci set system.@system[0].compat_version="1.1"
uci commit system
But this needs to be applied _after_ the upgrade (as the "old" fwtool
on the old installation does not know about compat_version) and it
requires access via SSH (i.e. no pure GUI solution is available for
this group of people, apart from wiping their config _again_ for
no technical reason). Despite, the situation will not become
obvious to those just upgrading via GUI, they will just have the
experience of a "broken upgrade".
This is a conflict which cannot be resolved by achieving both goals,
we have to decide to either keep the strict concept or improve the
situation for early adopters.
In this patch, we address the issue by providing a uci-defaults
script that will raise the compat_version for _all_ people upgrading
into a 1.1 image, no matter whether they have reset config or not.
The idea is to implement this as a _temporary_ solution, so early
adopters can upgrade into the new mechanism without issues, and
after a few weeks/months we could remove the uci-defaults script
again.
If we e.g. remove the script just before 20.xx.0-rc1, early adopters
should have moved on by then, and existing stable users would still
get the intended experience.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The bootloader fails to extract a big kernel, e.g. v5.4 kernel image
with ALL_KMODS enabled. This can be fixed by using lzma-loader.
Signed-off-by: Sungbo Eo <mans0n@gorani.run>
Currently the lzma-loader is placed in RAM at 32MB offset, which does not
make sense for devices with only 32MB RAM. If we adjust LZMA_TEXT_START to
24MB offset, then the lzma-loader can be used on those devices and still
about 24MB memory will be available for uncompressed image, which should be
enough for most use cases.
Signed-off-by: Sungbo Eo <mans0n@gorani.run>
The sbutarget has testing support for kernel 5.4 for quite a while
and builds fine, however, only one devices there is > 4 MiB.
Since it's unlikely to get a Tested-by for that device, and the other
ralink subtargets appear to be working with 5.4 so far, let's set
this target to 5.4 by default as well.
That way, even if the device happens to break, we'll still have at
least usable SDK and IB for people to use.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
When comparing to the port assignment in board.d/02_network, many
devices seem to use the wrong setup of mediatek,portmap.
The corrects the values for mt7620 subtarget based on the location
of the wan port.
A previous cleanup of obviously wrong values has already been done in
d3c0a94405 ("ramips: mt7620/mt7621: remove invalid mediatek,portmap")
Cc: Sungbo Eo <mans0n@gorani.run>
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
For ramips/mt7621, the wpad-basic package is not selected by default,
but added for every device individually as needed.
While this might be technically correct if the SoC does not come with
a Wifi module, only 18 of 97 devices for that platform are set up
_without_ wpad-basic currently.
Therefore, it seems more convenient to add wpad-basic by default for
the subtarget and then just remove it for the 18 mentioned devices,
instead of having to add it for about 60 times instead.
This would also match the behavior of the 5 other subtargets, where
wpad-basic/wpad-mini is added by default as well, and thus be more
obvious to developers without detailed SoC knowledge.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The target has testing support for kernel 5.4 for quite a while,
compiles fine for all devices, and has been run-tested on Asus
RT-N56U successfully.
Let's set it to kernel 5.4 by default to increase the audience
before an 20.xx stable branch.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Tested-by: Eneas U de Queiroz <cotequeiroz@gmail.com> [Asus RT-N56U]
This allows better context for board patches and we no longer need a
downstream patch for that.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
The patch adding support for the second LED HW blinking interval has been
merged (linux 5.9).
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
This patch adds support for the WNDR4300TN, marketed by Belgian ISP
Telenet. The hardware is the same as the WNDR4300 v1, without the
fifth ethernet port (WAN) and the USB port. The circuit board has
the traces, but the components are missing.
Specifications:
* SoC: Atheros AR9344
* RAM: 128 MB
* Flash: 128 MB NAND flash
* WiFi: Atheros AR9580 (5 GHz) and AR9344 (2.4 GHz)
* Ethernet: 4x 1000Base-T
* LED: Power, LAN, WiFi 2.4GHz, WiFi 5GHz, 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.0.51/
+ Log in with the default credentials are admin:password
+ Browse to Advanced > Administration > Firmware Upgrade in the Telenet
interface
+ Upload the Openwrt firmware: openwrt-ath79-nand-netgear_wndr4300tn-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 gray circle around it, next to the Telenet logo)
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_wndr4300tn-squashfs-factory.img
Signed-off-by: Davy Hollevoet <github@natox.be>
[use DT label reference for adding LEDs in DTSI files]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
