aboutsummaryrefslogtreecommitdiffstats
path: root/target
Commit message (Collapse)AuthorAgeFilesLines
* 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>
* ramips: drop remaining m25p,chunked-io from DTSAdrian Schmutzler2020-08-063-3/+0
| | | | | | | | | | | | | | This option was a spi nor hack which is dropped in commit bcf4a5f474d1 ("ramips: remove chunked-io patch and set spi->max_transfer_size instead") Most of it has already been removed in be2b61e4f1ec ("ramips: drop m25p,chunked-io from dts") It seems all current usages were added after that. Remove them. Cc: Chuanhong Guo <gch981213@gmail.com> Reported-by: Sungbo Eo <mans0n@gorani.run> Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* ramips: add common definition netgear_sercomm_norAdrian Schmutzler2020-08-063-27/+24
| | | | | | | | Like NAND-based devices, SPI-NOR based Netgear devices also share a common setup for their images. This creates a common defition for them in image/Makefile, so it can be reused across subtargets. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* procd: update to git HEADDaniel Golle2020-08-061-16/+2
| | | | | | | | | | | 47a9f0d service: add method to query available container features afbaba9 initd: attempt to mount cgroup2 ead60fe jail: use pidns semantics also for timens 759e9f8 jail: make use of BLOBMSG_CAST_INT64 for OCI rlimits 83053b6 instance: add instances into unified cgroup hierarchy 16159bb jail: parse OCI cgroups resources Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* ramips: tidy up MAC address setup for Linkit Smart and Omega2Adrian Schmutzler2020-08-063-8/+2
| | | | | | | | | | | | | | | | | | | | Linkit Smart 7688 and Onion Omega 2(+) are one-port devices, and have their port set to LAN by default. Setting up a WAN MAC address for them doesn't make any sense, as no wan interface will be created in uci config. Despite, these devices also set lan_mac in 02_network, although mtd-mac-address sets a different address for the ethernet interface in DTS. Clean this up by moving the lan_mac value into DTS and dropping the entries in 02_network completely. That way, the effective address on the LAN interface should stay the same, but we get rid of the extra (re)assignments. As I don't have access to the devices, this does not tell anything about whether 0x2e is actually a good choice, it just preserves the existing assignment. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* ramips: WizFi630S use macs from factory partionTobias Welz2020-08-062-3/+6
| | | | | | | | | | | | | | | | | | | | WIZnet WizFi630s has three mac addresses in the factory partition: 0x04 (also on the label), 0x28 for wan mac and 0x2e as lan mac. All three macadresses are sequential series of addresses. This is making use of them. While at it, also add the label MAC address to 02_network. MAC addresses as verified by OEM firmware: use interface source WLAN ra0 factory 0x04 (label) WAN eth0.2 factory 0x28 (label + 1) LAN eth0.1 factory 0x2e (label + 2) Signed-off-by: Tobias Welz <tw@wiznet.eu> [fix sorting in 02_network, commit message adjustments] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* ramips: correct WizFi630S pin mappingsTobias Welz2020-08-061-26/+8
| | | | | | | | | | WizFi630S had some pins changed in the release version of the board. The run led, wps button and a slide switch where affected. This patch is correcting this. i2c is removed as it is sharing a pin with the run (system) led. uart2 is enabled as it is also enabled in the OEM firmware. Signed-off-by: Tobias Welz <tw@wiznet.eu>
* ipq40xx: refresh kernel 5.4 configAdrian Schmutzler2020-08-061-11/+3
| | | | | | | | | | | Refresh config with make kernel_oldconfig. After d1a8217d87bf ("kernel: clean-up build-configurable kernel config symbols"), the routine wants to add an additional CONFIG_CGROUPS (=n), which has been removed manually again, as this seems unintended. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* mediatek: fix mt7622-rfb1 board supportFelix Fietkau2020-08-066-60/+67
| | | | | | | Make GPIO keys active-low. Add DSA support Signed-off-by: Felix Fietkau <nbd@nbd.name>
* kernel: unify CONFIG_GPIO_SYSFS in kernel configsFelix Fietkau2020-08-0667-67/+3
| | | | | | Enable it for all platforms Signed-off-by: Felix Fietkau <nbd@nbd.name>
* ramips: switch rt305x subtarget to kernel 5.4Alexey Dobrovolsky2020-08-056-6/+5
| | | | | | | | | | | | | | RT3x5x seems to work fine with kernel 5.4. Set the default kernel version to 5.4 to bring this to a broader audience. Since 4 of 6 targets are on kernel 5.4 now, invert the kernel version setup logic in Makefile/target.mk files. Tested on ZyXEL Keenetic. Signed-off-by: Alexey Dobrovolsky <dobrovolskiy.alexey@gmail.com> [invert version setup logic] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* ramips: enable flashing WizFi630S via OEM firmwareTobias Welz2020-08-051-0/+1
| | | | | | | | | | | WIZnet WizFi630s board name is written slightly different it its OEM OpenWrt firmware. This causes an incompatibility warning during flashing with sysupgrade. This patch is adding the vendor board name to the supported devices list to avoid this warning. For initial flashing you can use sysupgrade via command line or luci beside of TFTP. Do not keep the OEM configuration during sysupgrade. Signed-off-by: Tobias Welz <tw@wiznet.eu>
* ipq806x: use qcom-ipq8064-v1.0.dtsi from upstreamAdrian Schmutzler2020-08-058-222/+186
| | | | | | | | | | | | | | | | | This uses upstream qcom-ipq8064-v1.0.dtsi and modifies it by patches instead of keeping a local version. As a consequence: - we use a part of the shared definitions there and update device DTS files accordingly - we move additional stuff from our local v1.0.dtsi to the patch - we drop partitions, LEDs and keys from the file as we will implement them differently anyway Like with the previous patch, this follows the idea that a diff from upstream might be easier to handle than a big file of our own with different distribution pattern of properties. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* ipq806x: use qcom-ipq8064.dtsi from upstreamAdrian Schmutzler2020-08-058-1579/+1164
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Though a qcom-ipq8064.dtsi file exists upstream, we still do overwrite it with a full version of our own in the ipq806x target. About half of the contents of our file are upstream content, the other half are local improvements. To prevent us from having a lot of code maintained twice in parallel, this adjusts the target to use the upstream qcom-ipq8064.dtsi. Our local changes are arranged into three patches, the first pulling a commit from upstream, the second doing a few small adjustments, and the third adding all additional stuff. This should get us the best of both worlds. The property "ports-implemented" on sata@29000000 is moved to 2nd-level DTSI files as kernel defines it there as well. While at, rename 080-ARM-dts-qcom-add-gpio-ranges-property.patch to include the kernel version where it's added upstream. Even though this might look more complicated in the first place, the aim is to bring our files closer to upstream, so we can benefit from changes directly and vice-versa. After all, this drop about 650 lines just copied from the upstream DTSI file. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* ramips: remove doublet entry in WizFi630S dts fileTobias Welz2020-08-051-4/+0
| | | | | | | &wmac entry in WIZnet WizFi630S dts file was existing two times. This is removing one of them. Signed-off-by: Tobias Welz <tw@wiznet.eu>
* ramips: disable unused phy ports of WizFi630STobias Welz2020-08-051-0/+1
| | | | | | | WIZnet WizFi630S is using only 3 of the phy ports. The unused phy ports draw unnecessarily power. This is disabling the unused phy ports. Signed-off-by: Tobias Welz <tw@wiznet.eu>
* bcm47xx: switch to kernel 5.4Rafał Miłecki2020-08-041-1/+1
| | | | | | Switch, LEDs, USB, buttons, sysupgrade testedon BCM4706. Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
* bcm53xx: switch to kernel 5.4Rafał Miłecki2020-08-041-1/+1
| | | | | | Switch, USB, WiFi, buttons tested on BCM47094. Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
* bcm53xx: set HW_RANDOM_BCM2835=yRafał Miłecki2020-08-041-0/+2
| | | | | | | | | | This enables Random Number Generator support on Northstar (described in DT with brcm,bcm5301x-rng). It's also a workaround for OpenWrt bug with kernel config causing: Broadcom BCM2835/BCM63xx Random Number Generator support (HW_RANDOM_BCM2835) [Y/n/m/?] (NEW) Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
* bcm53xx: update kernel 5.4 DTS to upstream 5.9 stateRafał Miłecki2020-08-043-0/+333
| | | | Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-09 11:16:50 +0000