aboutsummaryrefslogtreecommitdiffstats
path: root/target/linux
Commit message (Collapse)AuthorAgeFilesLines
* 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>
* bcm53xx: update kernel 5.4 configRafał Miłecki2020-08-041-100/+4
| | | | Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
* ramips: add support for TP-Link RE200 v3Richard Fröhning2020-08-034-0/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TP-Link RE200 v3 is a wireless range extender with Ethernet and 2.4G and 5G WiFi with internal antennas. It's based on MediaTek MT7628AN+MT7610EN like the v2. Specifications -------------- - MediaTek MT7628AN (580 Mhz) - 64 MB of RAM - 8 MB of FLASH - 2T2R 2.4 GHz and 1T1R 5 GHz - 1x 10/100 Mbps Ethernet - 8x LED (GPIO-controlled), 2x button Unverified: - UART header on PCB (57600 8n1) There are 2.4G and 5G LEDs in red and green which are controlled separately. MAC addresses ------------- MAC address assignment has been done according to the RE200 v2. The label MAC address matches the OpenWrt ethernet address. Installation ------------ Web Interface ------------- It is possible to upgrade to OpenWrt via the web interface. Simply flash the -factory.bin from OEM. In contrast to a stock firmware, this will not overwrite U-Boot. Recovery -------- Unfortunately, this devices does not offer a recovery mode or a tftp installation method. If the web interface upgrade fails, you have to open your device and attach serial console. The device has not been opened for adding support. However, it is expected that the behavior is similar to the RE200 v2. Instructions for serial console and recovery may be checked out in commit 6d6f36ae787c ("ramips: add support for TP-Link RE200 v2") or on the device's Wiki page. Signed-off-by: Richard Fröhning <misanthropos@gmx.de> [adjust commit title/message, sort support list] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* ramips: fix/tidy up 4M tplink-v2-image flash layoutsAdrian Schmutzler2020-08-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | For the TP-Link 4M devices with tplink-v2-image recipe (mktplinkfw2.c), there are two different flash layouts based on the size of the (u)boot partition: device uboot OEM firmware OpenWrt (incl. config) tl-wr840n-v5 0x20000 0x3c0000 0x3d0000 tl-wr841n-v14 0x10000 0x3d0000 0x3e0000 In both cases, the 0x10000 config partition is used for the firmware partition as well due to the limited space available and since it's recreated by the OEM firmware anyway. However, the TFTP flashing process will only copy data up to the size of the initial (OEM) firmware size. Therefore, while we can use the bigger partition to have additional erase blocks on the device, we have to limit the image sizes to the TFTP limits. So far, only one layout definition has been set up in mktplinkfw2.c for 4M mediatek devices. This adds a second one and assigns them to the devices so the image sizes are correctly restrained. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* kirkwood: get rid of BOARD_NAME and tidy up DEVICE_DTSAdrian Schmutzler2020-08-031-16/+14
| | | | | | | | | | | Since most of the DTS file names follow a common scheme now, let's update the automatically generated DEVICE_DTS value and get rid of some DEVICE_DTS and all BOARD_NAME entries for individual devices. This should specifically make the job easier for developers adding new devices, as they are not tempted to copy over BOARD_NAME anymore. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* target: replace remaining occurrences of ifconfig with ipAdrian Schmutzler2020-08-035-8/+9
| | | | | | | | | | | ifconfig is effectively deprecated for quite some time now. Let's replace the remaining occurrences for our target setup by the corresponding ip commands now. Note that this does not touch ar71xx, as it will be dropped anyway, and changing it would only make backports harder. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* ar71xx: restore support for boot console with arbitrary baud ratesSungbo Eo2020-08-021-0/+54
| | | | | | | | | | | Commit 1bfbf2de6df9 ("ar71xx: serial: core: add support for boot console with arbitrary baud rates") added support for arbitrary baud rates which enabled 250000 baud rate for Yun. But the patch was not ported to kernel 4.9, and since then the kernel set its baud rate to 9600. This commit ports the patch to kernel 4.14, thereby restoring the serial console of Yun. Cc: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: Sungbo Eo <mans0n@gorani.run>
* ar71xx: enable ethernet LED of Arduino YunSungbo Eo2020-08-021-2/+1
| | | | | | | | Commit 05d73a2a7379 enabled GPIO on ethernet LED, but proper LED setup was not added then. This commit fixes it by reverting the change on the LED. Fixes: 05d73a2a7379 ("ar71xx: Arduino Yun board 'WLAN RST' button support") Signed-off-by: Sungbo Eo <mans0n@gorani.run>
* ar71xx: fix sysupgrade for Arduino YunSungbo Eo2020-08-021-1/+1
| | | | | | | | | Commit bb46b635df48 changed its partition scheme, but sysupgrade image validation still uses the old format. This commit fixes it so that force flag is not needed for sysupgrade. Fixes: bb46b635df48 ("ar71xx: move Arduino Yun to generic building code") Signed-off-by: Sungbo Eo <mans0n@gorani.run>
* Revert "ar71xx: fix Arduino Yun enabling of level shifters outputs"Sungbo Eo2020-08-021-2/+2
| | | | | | | | | This reverts commit 077253dd666a30ae5231c3748222d4b5b138593d. The output enable pins should be disabled by default, and only enabled when used. Otherwise unwanted conflicts might occur between MCU and SoC pins. Signed-off-by: Sungbo Eo <mans0n@gorani.run>
* ath79/mikrotik: create shared device definitions for nor and nandAdrian Schmutzler2020-08-012-13/+19
| | | | | | | Move the image preparation and nand-utils package selection into common device definitions for NOR/NAND devices. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
generated by cgit v1.2.3 (git 2.25.1) at 2024-10-31 00:46:43 +0000