aboutsummaryrefslogtreecommitdiffstats
path: root/target/linux
Commit message (Collapse)AuthorAgeFilesLines
* ath79: add support for MikroTik RouterBOARD 921GS-5HPacD-15sSven Roederer2020-08-127-125/+175
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ath79: add support for MikroTik RouterBOARD LHG 2nDRoger Pueyo Centelles2020-08-127-0/+218
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* mediatek: disable btif in device tree to make the WMAC work againFelix Fietkau2020-08-121-1/+1
| | | | | | | btif and wmac access the same resources and at the moment enabling one breaks the other Signed-off-by: Felix Fietkau <nbd@nbd.name>
* mediatek: fix PCI device tree node for elecom wrc-2533gentFelix Fietkau2020-08-121-2/+5
| | | | Signed-off-by: Felix Fietkau <nbd@nbd.name>
* bcm47xx: use vendor_model scheme for device/image namesAdrian Schmutzler2020-08-123-180/+180
| | | | | | | | | | | 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>
* bcm53xx: use vendor_model scheme for device/image namesAdrian Schmutzler2020-08-121-57/+57
| | | | | | | | | | | 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>
* kernel: Fix cake patch for kernel 4.19.138Hauke Mehrtens2020-08-111-2/+2
| | | | | | | | | | | | | 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: fdac05b7416b ("kernel: Update kernel 4.19 to version 4.19.138") Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* kernel: Create UBIFS v5 volumeHauke Mehrtens2020-08-116-195/+0
| | | | | | | | | | | | | In commit 87b35c16adcf ("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>
* bcm63xx: switch to upstream CFE detection patchÁlvaro Fernández Rojas2020-08-113-71/+78
| | | | | | This patch has been merged in linux 5.9. Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
* malta: disable unnecessary built-in CDROM supportTony Ambardar2020-08-112-6/+0
| | | | | | | | | | | | | 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>
* oxnas: reduce size of ATA DMA descriptor spaceDaniel Golle2020-08-112-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ar71xx: fix ZyXEL NBG6616 wifi switchChristoph Krapp2020-08-111-2/+2
| | | | | | | The device uses a rf-kill switch instead of a button. Furthermore the GPIO is active high. Signed-off-by: Christoph Krapp <achterin@googlemail.com>
* kernel: Move CONFIG_IONIC to generic kernel configHauke Mehrtens2020-08-1013-12/+1
| | | | | | | 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>
* malta: Refresh kernel configurationHauke Mehrtens2020-08-105-18/+23
| | | | | | | | | | | 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>
* kernel: Update kernel 4.14 to version 4.14.193Hauke Mehrtens2020-08-108-15/+15
| | | | Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* kernel: Update kernel 4.19 to version 4.19.138Hauke Mehrtens2020-08-1017-258/+34
| | | | | | Compile and run tested on lantiq/xrx200 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* ath79: add support for ZyXEL NBG6616Christoph Krapp2020-08-108-145/+313
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* treewide: make dependency on kmod-usb-net selectiveAdrian Schmutzler2020-08-109-10/+9
| | | | | | | | 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>
* ath79: add support for Telco T1Nicholas Smith2020-08-104-2/+159
| | | | | | | | | | | | | | | | | | | | | | Description: 2x 100Mbps Etherent ports 24V passive PoE 64MB RAM 16MB Flash 2.4GHz WiFi 1x WiFi antenna (RP-SMA connector) 1x LTE antenna (SMA connector) Sierra Wireless MC7430 LTE modem Flash instructions: Original firmware is based on OpenWrt. Flash using sysupgrade -n SUPPORTED_DEVICES is added to support factory firmware. Signed-off-by: Nicholas Smith <nicholas.smith@telcoantennas.com.au> [add missing led_rssi0 DT label, add SUPPORTED_DEVICES] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* ath79: increase spi frequency on TL-WDR3500/3600/4300/4310Aleksander Jan Bajkowski2020-08-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ramips/mt7628: fix portmap based on board.d port assignmentAdrian Schmutzler2020-08-102-2/+2
| | | | | | | | | | | | | 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 7a387bf9a0d7 ("ramips: mt76x8: fix bogus mediatek,portmap") Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* ath79: add support for TP-Link TL-WPA8630P v2Andreas Böhler2020-08-107-1/+258
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* kernel: modules: add package kmod-iosched-bfqDaniel Golle2020-08-103-3/+0
| | | | Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* ar71xx: change u-boot-env to read-write for ZyXEL NBG6616Christoph Krapp2020-08-091-1/+1
| | | | | | | | | 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>
* kernel: add missing config symbolsFelix Fietkau2020-08-093-0/+9
| | | | Signed-off-by: Felix Fietkau <nbd@nbd.name>
* treewide: add sysupgrade comment for early DSA-adoptersAdrian Schmutzler2020-08-083-3/+6
| | | | | | | | | | 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>
* ath79: add support for TP-Link TL-WA901ND v3Adrian Schmutzler2020-08-084-0/+64
| | | | | | | | | | | | | | | | | | | | | 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>
* ipq806x: replace patches with upstream versionAnsuel Smith2020-08-088-166/+218
| | | | | | | | 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>
* ath79: drop redundant kmods-leds-gpioAdrian Schmutzler2020-08-081-7/+6
| | | | | | | 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>
* ramips: mt7621: implement compatibility version for DSA migrationAdrian Schmutzler2020-08-083-0/+109
| | | | | | | | | | | | | | | | | | | 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>
* kirkwood: fix sysupgrade experience for early DSA-adoptersAdrian Schmutzler2020-08-081-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* mvebu: fix sysupgrade experience for early DSA-adoptersAdrian Schmutzler2020-08-081-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ramips: use lzma-loader for RT5350F-OLinuXino devicesSungbo Eo2020-08-081-0/+2
| | | | | | | 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>
* ramips: adjust LZMA_TEXT_START for 32MB RAM devicesSungbo Eo2020-08-081-1/+1
| | | | | | | | | | 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>
* ramips: switch rt288x subtarget to kernel 5.4Adrian Schmutzler2020-08-071-2/+0
| | | | | | | | | | | | | | 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>
* ramips/mt7620: fix portmap based on board.d port assignmentAdrian Schmutzler2020-08-079-10/+8
| | | | | | | | | | | | | | 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 d3c0a944059b ("ramips: mt7620/mt7621: remove invalid mediatek,portmap") Cc: Sungbo Eo <mans0n@gorani.run> Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* ramips: invert wpad selection for mt7621Adrian Schmutzler2020-08-072-80/+89
| | | | | | | | | | | | | | | | | | | 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>
* bcm63xx: add missing endif board comnentsÁlvaro Fernández Rojas2020-08-0761-118/+118
| | | | | | This provides better context for board patches. Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
* bcm63xx: merge RTA770BW and RTA770W board patchesÁlvaro Fernández Rojas2020-08-0738-143/+101
| | | | | | The only difference between both boards is the DSL annex. Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
* bcm63xx: add missing fallback SPROMsÁlvaro Fernández Rojas2020-08-0717-50/+56
| | | | | | A couple of SPROM IDs are missing. Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
* bcm63xx: add missing OHCI nodesÁlvaro Fernández Rojas2020-08-0733-99/+102
| | | | | | All boards with EHCI enabled should also have OHCI enabled. Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
* bcm63xx: remove invalid EHCI nodesÁlvaro Fernández Rojas2020-08-0760-160/+158
| | | | | | There's no EHCI controller on BCM6348. Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
* bcm63xx: refactor board patchesÁlvaro Fernández Rojas2020-08-0769-1483/+1401
| | | | | | | Current board patches format is crazy. Let's try to put some order. Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
* ramips: switch rt3883 subtarget to kernel 5.4Adrian Schmutzler2020-08-061-2/+0
| | | | | | | | | | | | 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]
* bcm63xx: switch to upstream CFE version detection patchÁlvaro Fernández Rojas2020-08-067-32/+61
| | | | | | The patch improving CFE version detection has been merged (linux 5.9). Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
* bcm63xx: switch to upstream endif comments patchÁlvaro Fernández Rojas2020-08-0686-354/+451
| | | | | | | 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>
* bcm63xx: switch to upstream LED patchÁlvaro Fernández Rojas2020-08-061-44/+95
| | | | | | | 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>
* Revert "procd: update to git HEAD"Daniel Golle2020-08-061-2/+16
| | | | | | This reverts commit e0e607f0d000e62c6af8d822d7c3f57c2a582136. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* ath79/nand: add support for Netgear WNDR4300TNDavy Hollevoet2020-08-0610-40/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ramips: add support for Netgear JWNR2010 v5Shibajee Roy2020-08-065-0/+165
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Specification: - CPU: MediaTek MT7620N (580 MHz) - Flash size: 4 MB NOR SPI - RAM size: 32 MB DDR1 - Bootloader: U-Boot - Wireless: MT7620N 2x2 MIMO 802.11b/g/n (2.4 GHz) - Switch: MT7620 built-in 10/100 switch with vlan support - Ports: 4x LAN, 1x WAN - Others: 7x LED, Reset button, UART header on PCB (57600 8N1) Flash instructions: 1. Use ethernet cable to connect router with PC/Laptop, any router LAN port will work. 2. To flash openwrt we are using nmrpflash[1]. 3. Flash commands: First we need to identify the correct Ethernet id. nmrpflash -L nmrpflash -i net* -f openwrt-ramips-mt7620-netgear_jwnr2010-v5-squashfs-factory.img This will show something like "Advertising NMRP server on net*..." (net*, *=1,2,3... etc.) 4. Now remove the power cable from router back side and immediately connect it again. You will see flash notification in CMD window, once it says reboot the device just plug off the router and plug in again. Revert to stock: 1. Download the stock firmware from official netgear support[2]. 2. Follow the same nmrpflash procedure like above, this time just use the stock firmware. nmrpflash -i net* -f N300-V1.1.0.54_1.0.1.img MAC addresses on stock firmware: LAN = *:28 (label) WAN = *:29 WLAN = *:28 On flash, the only valid MAC address is found in factory 0x4. Special Note: This openwrt firmware will also support other netgear N300 routers like below as they share same stock firmware[3]. JNR1010v2 / WNR614 / WNR618 / JWNR2000v5 / WNR2020 / WNR1000v4 / WNR2020v2 / WNR2050 [1] https://github.com/jclehner/nmrpflash [2] https://www.netgear.com/support/product/JWNR2010v5.aspx [3] http://kb.netgear.com/000059663 Signed-off-by: Shibajee Roy <ador250@protonmail.com> [create DTSI, use netgear_sercomm_nor, disable by default, add MAC addresses to commit message, add label MAC address] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-05 08:44:28 +0000