aboutsummaryrefslogtreecommitdiffstats
path: root/target
Commit message (Collapse)AuthorAgeFilesLines
* apm821xx: WNDAP660: fix ethernet port orderingChristian Lamparter2022-06-254-13/+13
| | | | | | | | | | | | | | | | | | | Tim Small reported: | Viewing the 'Network' -> 'Switch' config page in LuCI: | | The LuCI LAN 1 port corresponds to the port physically | labelled 2 at the rear of the device. | [...] | | When a patch cord is attached to the port labelled 1 [...], | the LED labelled °2 illuminates. => essentially, the Ports and LEDs are reversed. Reported-by: Tim Small Fixes: #10111 Signed-off-by: Christian Lamparter <chunkeey@gmail.com> (cherry picked from commit 36483600d337ab3ec8a6dabeaa160614d07f5588)
* ramips: mt7621-dts: fix claiming rgmii2 pin group for EdgeRouter X SFPArınç ÜNAL2022-06-252-5/+7
| | | | | | | | | | | | | | | | | | | | For a TX->TX connected external phy to transmit/receive data, the rgmii2 pin group needs to be claimed with gpio function, at least for EdgeRouter X SFP. We already claim the pin group under the pinctrl node with gpio function on the gpio node on mt7621_ubnt_edgerouter-x.dtsi. However, we should claim a pin group under its consumer node. It's the ethernet node in this case, which we already claim the rgmii2 pin group under it on mt7621.dtsi. Therefore, set the function as gpio on the rgmii2 node for EdgeRouter X SFP and get rid of claiming the rgmii2 pin group under the pinctrl node. With this change, we also get to remove a definition from mt7621_ubnt_edgerouter-x.dtsi which is specific to EdgeRouter X SFP. This change is tested on an EdgeRouter X SFP. Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> (cherry picked from commit a1ad8377355c41a7cc3012b707fcecab923cbc90)
* ramips: force ZyXEL NR7101 to boot from "Kernel" partitionBjørn Mork2022-06-251-0/+1
| | | | | | | | | | | | | | | | | | | | Make sure BootingFlag points to the system partition we install to. The BootingFlag variable selects which system partition the system boots from (0 => "Kernel", 1 => "Kernel2"). OpenWrt does not yet have device specific support for this dual image scheme, and can therefore only boot from "Kernel". This has not been an issue until now, since all known OEM firmware versions have ignored "Kernel2" - leaving the BootingFlag fixed at 0. But the newest OEM firmware has a new upgrade procedure, installing to the "inactive" system partition and setting BootingFlag accordingly. This workaround is needed until the dual image scheme is fully supported. Signed-off-by: Bjørn Mork <bjorn@mork.no> (cherry picked from commit 79112e7d4758cc79dea506ffebdf40e00d94fa06)
* ath79: fix rootfs padding for D-Link DAP-2xxxSebastian Schaper2022-06-251-1/+2
| | | | | | | | | | | | It was observed that `rootfs_data` was sometimes not correctly erased after performing sysupgrade, resulting in previous settings to prevail. Add call to `wrgg-pad-rootfs` in sysupgrade image recipe to ensure any previous jffs2 will be wiped, consistent with DAP-2610 from the ipq40xx target, which introduced the double-flashing procedure for these devices. Signed-off-by: Sebastian Schaper <openwrt@sebastianschaper.net> (cherry picked from commit f770c33d7bb94b610d3a1c1fa84bc917678b65bc)
* mpc85xx: p2020: add RTC ds1307 to kernelJosef Schlehofer2022-06-251-0/+1
| | | | | | | | | | | | | | | If the RTC module is compiled as a module, the hctosys fails to initialize because ds1307 is loaded later. Fixes: [ 2.004145] hctosys: unable to open rtc device (rtc0) [ 11.957997] rtc-ds1307 0-006f: registered as rtc0 This is similar to commit 5481ce9a1157a43d8b2c963e03fb243e70974361, which was done for imx6 target. Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com> (cherry picked from commit dc7f78da97c62cd6c17a75f754da5bf6b957837d)
* bcm53xx: remove 07_set_preinit_iface_bcm53xxChristian Lamparter2022-06-251-14/+0
| | | | | | | | | with the switch to DSA setup, the switch gets correctly programmed via the device-tree now. This hack is no longer necessary. Signed-off-by: Christian Lamparter <chunkeey@gmail.com> (cherry picked from commit 554ca44730731da6fddc51e1d3027c5e666a7d0d)
* realtek: make "u-boot-env" partition writable for Netgear 3xx seriesAndreas Böhler2022-06-241-1/+0
| | | | | | | | | | The Netgear GS3xx devices do not properly initialise the port LEDs during startup unless the boot command in U-Boot is changed. Making the U-Boot env partition writable allows this modification to be done from within OpenWrt by calling "fw_setenv bootcmd rtk network on\; boota". Signed-off-by: Andreas Böhler <dev@aboehler.at> (cherry picked from commit d9e12c21fa98c90d0cc355e344d90469c5fd42c1)
* realtek: make Netgear GS1xx u-boot env partition writableStijn Segers2022-06-241-1/+0
| | | | | | | | | | | | Make the u-boot environment partition for the NETGEAR GS108T v3 and GS110TPP writable (they share a DTS), so the values can be manipulated from userspace. See https://forum.openwrt.org/t/57875/1567 for a real world example. Signed-off-by: Stijn Segers <foss@volatilesystems.org> (cherry picked from commit 9c381d3386ab375a4c79812641192faef368d191)
* ramips: fix booting on ZyXEL NBG-419N v2Piotr Dymacz2022-06-201-0/+1
| | | | | | | | | | | | | | This fixes a well known "LZMA ERROR 1" error, reported previously on numerous of other devices from 'ramips' target. Fixes: #9842 Fixes: #8964 Reported-by: Juergen Hench <jurgen.hench@gmail.com> Tested-by: Juergen Hench <jurgen.hench@gmail.com> Signed-off-by: Demetris Ierokipides <ierokipides.dem@gmail.com> Signed-off-by: Piotr Dymacz <pepe2k@gmail.com> (cherry picked from commit fd72e595c2b2a46bab8cbc7e9415fbfeae7b5b0d)
* realtek: add support for power LED on Netgear GS108Tv3Pascal Ernster2022-06-191-0/+27
| | | | | | | | | | | | | | | | | | | | | | The Netgear GS108Tv3 is already supported by OpenWrt, but is missing LED support. After OpenWrt installation, all LEDs are off which makes the installation quite confusing. This enables support for the green/amber power LED to give feedback about the current status. This is basically just a verbatim copy of commit c4927747d25a ("realtek: add support for power LED on Netgear GS308Tv1"). Please note that both LEDs are wired up in an anti-parallel fashion, which means that only one of both LEDs/colors can be switched on at the same time. If both LEDs/colors are switched on simultanously, the LED goes dark. Tested-by: Pascal Ernster <git@hardfalcon.net> Signed-off-by: Pascal Ernster <git@hardfalcon.net> [add title to commit reference] Signed-off-by: Sander Vanheule <sander@svanheule.net> (cherry picked from commit adbdfc9366fed2d28dbd36883ddbdb566a313f71)
* realtek: add support for power LED on Netgear GS308Tv1Andreas Böhler2022-06-191-0/+27
| | | | | | | | | | | The Netgear GS308Tv1 is already supported by OpenWrt, but is missing LED support. After OpenWrt installation, all LEDs are off which makes the installation quite confusing. This enables support for the green/amber power LED to give feedback about the current status. Signed-off-by: Andreas Böhler <dev@aboehler.at> (cherry picked from commit c4927747d25af59db8233a66a59fdf9e8c0e395d)
* ramips: fix RT-AC57U button levelDavid Bauer2022-06-181-1/+1
| | | | | | | | Both buttons on the RT-AC57U are active-low. Fix the GPIO flag for the WPS cutton to fix button behavior. Signed-off-by: David Bauer <mail@david-bauer.net> (cherry picked from commit 535b0c70b1c466733b009144f81f5207f1ecd311)
* mpc85xx: enable error reporting for RAM and PCIeJosef Schlehofer2022-06-141-0/+4
| | | | | | | | | | | | | | | | | | | | | All Freescale processors used in this target are capable to detect error and correction. [1] It can not be used as kernel module. [2] This is helpful to report hardware errors. It enables three kernel options: - EDAC, which is a subsystem - EDAC_LEGACY_SYSFS, it enables sysfq nodes - MP85XX, support for Freescale MPC8349, MPC8560, MPC8540, MPC8548, T4240 EDAC is already enabled for following targets: qoriq, octeon, octeontx and zynq. [1] https://cateee.net/lkddb/web-lkddb/EDAC.html [2] https://patchwork.ozlabs.org/patch/554908/ Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com> (cherry picked from commit bfc73f42df3189a2eb34bebc8d9e73b3389a83a2)
* sunxi/cortexa53: enable armv8-CE crypto algorithmsEneas U de Queiroz2022-06-111-0/+10
| | | | | | | | This enables armv8 crypto extensions version of AES, GHASH, SHA1, and CRC T10 algorithms in the kernel. Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com> (cherry picked from commit 9be35180f43a4916f53430d8c93437d33896e860)
* rockchip/armv8: enable armv8-CE crypto algorithmsEneas U de Queiroz2022-06-111-0/+9
| | | | | | | | This enables armv8 crypto extensions version of AES, GHASH, and CRC T10 algorithms in the kernel. Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com> (cherry picked from commit b1346d35e470662c98912efc49108733ee7c101c)
* octeontx: add armv8-CE version of CRC T10Eneas U de Queiroz2022-06-111-0/+1
| | | | | | | | Adds the crypto extensions version of the CRC T10 algorithm that is already built into the kernel. Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com> (cherry picked from commit 1b94e4aab8ddbe5719f1e859e064c1c5dfa4587f)
* mvebu/cortexa72: enable armv8-CE crypto algosEneas U de Queiroz2022-06-111-0/+11
| | | | | | | | | | | | This enables armv8 crypto extensions version of AES, GHASH, SHA1, SHA256, and SHA512 algorithms in the kernel. The choice of algorithms match the 32-bit versions that are enabled in the target config-5.10 file, but were only used by the cortexa9 subtarget. Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com> (cherry picked from commit 06bb5ac1f2b62c3e10f24d7096e86f6368aaf41d)
* mvebu/cortexa72: refresh kernel 5.10 configEneas U de Queiroz2022-06-111-1/+4
| | | | | | | This is result of a plain make kernel_oldconfig CONFIG_TARGET=subtarget. Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com> (cherry picked from commit 39b6af114747fbee06cf6fab3a76d7037b53a4cc)
* mvebu/cortexa53: enable armv8-CE crypto algosEneas U de Queiroz2022-06-111-0/+11
| | | | | | | | | | | | This enables armv8 crypto extensions version of AES, GHASH, SHA1, SHA256, and SHA512 algorithms in the kernel. The choice of algorithms match the 32-bit versions that are enabled in the target config-5.10 file, but were only used by the cortexa9 subtarget. Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com> (cherry picked from commit f5167e11bf7e0a1a3675f0563423254005d0eb2d)
* mvebu/cortexa53: refresh kernel 5.10 configEneas U de Queiroz2022-06-111-1/+7
| | | | | | | This is result of a plain make kernel_oldconfig CONFIG_TARGET=subtarget. Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com> (cherry picked from commit a4c6384d930a0d0817ad12770da3abbd106e8c4d)
* layerscape/armv8_64b: enable armv8-CE crypto algosEneas U de Queiroz2022-06-111-0/+11
| | | | | | | | This enables armv8 crypto extensions version of AES, GHASH, SHA256 and CRC T10 algorithms in the kernel. Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com> (cherry picked from commit eb33232420ea2537d8302d5ec121eed03db474d1)
* bcm4908: enable armv8-CE crypto algorithmsEneas U de Queiroz2022-06-111-0/+8
| | | | | | | | This enables armv8 crypto extensions version of AES and GHASH algorithms in the kernel. Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com> (cherry picked from commit b2cb87bc98e8d7b5f29899b8b966990e200cfe44)
* bcm27xx/bcm2711: enable asm crypto algorithmsEneas U de Queiroz2022-06-111-0/+8
| | | | | | | | | This enables arm64/neon version of AES, SHA256 and SHA512 algorithms in the kernel. bcm2711 does not support armv8 crypto extensions, so they are not included. Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com> (cherry picked from commit 7b6beb7489c750c0613153822ec1d5ba8a9ab388)
* bcm27xx/bcm2710: enable asm crypto algorithmsEneas U de Queiroz2022-06-111-0/+8
| | | | | | | | | This enables arm64/neon version of AES, SHA256 and SHA512 algorithms in the kernel. bcm2710 does not support armv8 crypto extensions, so they are not included. Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com> (cherry picked from commit 38ebb210a9f4895cfade3580815d5c9a3eb1b7e4)
* ath79: D-Link DAP-2680: select QCA9984 firmwareStijn Segers2022-06-111-1/+1
| | | | | | | | | | | | | The DAP-2680 has a QCA9984 radio [1], but the commit adding support mistakenly adds the QCA99x0 firmware package. See forum topic [2]. [1] https://wikidevi.wi-cat.ru/D-Link_DAP-2680_rev_A1 [2] https://forum.openwrt.org/t/missing-5ghz-radio-on-dlink-dap-2680/ Fixes: 5b58710fad21 ("ath79: add support for D-Link DAP-2680 A1") Signed-off-by: Stijn Segers <foss@volatilesystems.org> Tested-by: Alessandro Fellin <af.registrazioni@gmail.com> (cherry picked from commit 0dc056eb66e1b3a4a6797bdf91f7362df6ced9c3)
* bcm53xx: remove BROKEN flag from Asus RT-AC88UArınç ÜNAL2022-06-101-1/+0
| | | | | | | | The image builds and works fine on Asus RT-AC88U. Therefore, remove the BROKEN flag from the makefile. Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> (cherry picked from commit 5c1b1918abf853c95976daf7fea58fb1355eae6d)
* kernel: move Toshiba-TC58NVG0S3H patch to ipq40xxChristian Lamparter2022-06-091-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Hannu Nyman wrote in openwrt's github issue #9962: |Based on forum discussion, the commit 0bc794a |"kernel: add support for Toshiba TC58NVG0S3HTA00 NAND flash" |causes flash memory chip misdetection for some other |Fritzbox devices, as the commit only defines a 4-byte flash |memory chip ID that matches several chips used in the devices. | |See discussion from this onward |<https://forum.openwrt.org/t/openwrt-22-03-0-rc1-first-release-candidate/126045/182> | |OpenWrt 22.03.0-rc2 and rc3 are causing on a Fritzbox 7412 |bootloops due to a misdetected flash chip. | |Yup, that patch is missing the 5th ID byte entirely - both chips |share the same first 4; | | TC58NVG0S3HTA00 = 0x98 0xf1 0x80 0x15 0x72 (digikey datasheet, page 35) | TC58BVG0S3HTA00 = 0x98 0xf1 0x80 0x15 0xf2 (digikey datasheet, page 28) | |The commit has also been backported to openwrt-22.03 after rc1, |so both rc2 and rc3 suffer from this bug." Andreas' TC58NVG0S3H seems not to follow Toshibas/Kioxa's own datasheet. It only reports the first four bytes: "98 f1 80 15 00 00 00 00". This patch changes the id_len in the entry to 8. This makes it so that Andreas' NAND is still detected. At the same time, this prevents other Toshiba NAND flash chips - that share the same four bytes - from being misdetected. Upstream (Miquel Raynal) decided to drop this patch for now. But he advised to keep it in OpenWrt. As other devices could be affected. <https://lore.kernel.org/linux-mtd/20220606155919.23001410@xps-13/> Reported-by: Peter-vdL Tested-by: Peter-vdL Tested-by: Andreas B<C3><B6>hler <dev@aboehler.at> Fixes: 0bc794a66845 ("kernel: add support for Toshiba TC58NVG0S3HTA00 NAND flash") Link: <https://github.com/openwrt/openwrt/issues/9962> (actually move the patch, added comment about possible counterfeits) Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
* kernel: bump 5.10 to 5.10.120John Audia2022-06-078-10/+10
| | | | | | | | | | All patches automatically rebased. Build system: x86_64 Build-tested: ipq806x/R7800, x86/64 Signed-off-by: John Audia <therealgraysky@proton.me> (cherry picked from commit f800f8d6fc4f21ed87454aa657ebbf376dc3b6cf)
* kernel: bump 5.10 to 5.10.119John Audia2022-06-075-8/+7
| | | | | | | | | | | Delete the crypto-lib-blake2s kmod package, as BLAKE2s is now built-in. Patches automatically rebased. Build system: x86_64 Build-tested: ipq806x/R7800, x86/64 Signed-off-by: John Audia <therealgraysky@proton.me> (cherry picked from commit cd634afe6cb6565eb6865931c8d73d97cab3600a)
* kernel: bump 5.10 to 5.10.118John Audia2022-06-079-129/+13
| | | | | | | | | | | | | | Removed upstreamed: generic-backport/774-v5.15-1-igc-remove-_I_PHY_ID-checking.patch generic-backport/774-v5.15-2-igc-remove-phy-type-checking.patch All patches automatically rebased. Build system: x86_64 Build-tested: ipq806x/R7800 Signed-off-by: John Audia <therealgraysky@proton.me> (cherry picked from commit b789a588b1c55fe1df7e2d6ae1c4f84b96a03a95)
* kernel: bump 5.10 to 5.10.117John Audia2022-06-0712-28/+28
| | | | | | | | | | | | | Removed upstreamed: backport-5.10/890-v5.19-net-sfp-Add-tx-fault-workaround-for-Huawei-MA5671A-SFP-ON.patch All patches automatically rebased. Build system: x86_64 Build-tested: ipq806x/R7800 Signed-off-by: John Audia <therealgraysky@proton.me> (cherry picked from commit 01a6a5c73120ccddd2a83381252ede91aac070f4)
* ath79: allow use GPIO17 as regular gpio on GL-AR300M devicesPtilopsis Leucotis2022-06-071-3/+3
| | | | | | | | | Small update to my previous path 'fix I2C on GL-AR300M devices'. This update allow using GPIO17 as regular GPIO in case it not used as I2C SDA line. Signed-off-by: Ptilopsis Leucotis <PtilopsisLeucotis@yandex.com> (cherry picked from commit 493080815d2ba6e3b7740dbd45c44310935aeebc)
* ath79: ZTE MF286[,A,R]: use GPIO19 as ath9k LEDLech Perczak2022-06-071-14/+7
| | | | | | | | | | | | | With the pinctrl configuration set properly by the previous commit, the LED stays lit regardless of status of 2.4GHz radio, even if 5GHz radio is disabled. Map GPIO19 as LED for ath9k, this way the LED will show activity for both bands, as it is bound by logical AND with output of ath10k-phy0 LED. This works well because during management traffic, phy*tpt triggers typically cause LEDs to blink in unison. Link: <https://github.com/openwrt/openwrt/pull/9941> Signed-off-by: Lech Perczak <lech.perczak@gmail.com> (cherry picked from commit 5ca45e0a21ee1bdafd3652e7e91a761a9cd0c838)
* ath79: ZTE MF286[,A,R]: fix WLAN LED mappingLech Perczak2022-06-071-0/+8
| | | | | | | | | | | The default configuration of pinctrl for GPIO19 set by U-boot was not a GPIO, but an alternate function, which prevented the GPIO hog from working. Set GPIO19 into GPIO mode to allow the hog to work, then the ath10k LED output can control the state of actual LED properly. Link: <https://github.com/openwrt/openwrt/pull/9941> Signed-off-by: Lech Perczak <lech.perczak@gmail.com> (cherry picked from commit 82b59846368db85ad1470396d95e7c20157288eb)
* kernel: fix crashes in bridge offload codeFelix Fietkau2022-06-071-5/+5
| | | | | | | - fix an issues when accessing the port pointer of an expired/invalid fdb entry Signed-off-by: Felix Fietkau <nbd@nbd.name> (cherry picked from commit 38a5b593ef9e94deedefb627f1952b3bb881df56)
* kernel: backport flow offload fixesRitaro Takenaka2022-06-072-1/+100
| | | | | | | | | | Some dst in IPv6 flow offload table become invalid after the table is created. So check_dst is needed in packet path. Signed-off-by: Ritaro Takenaka <ritarot634@gmail.com> [Add patch for kernel 5.15 too and rename file] Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> (cherry picked from commit efff48529b5cdb4046b923bebee483c7c68755a7)
* bmips: dgnd3700v2: fix network configÁlvaro Fernández Rojas2022-06-071-0/+1
| | | | | | | | ucidef_set_bridge_device is needed for DGND3700v2 network config since VLAN 1 must be used for the switch to be correctly configured. Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> (cherry picked from commit 90e4c8c6e6fe060d849a5b96bc7595345ce3d6ea)
* realtek: add gpio-restart for D-Link DGS-1210-28Luiz Angelo Daros de Luca2022-06-071-0/+6
| | | | | | | | | A GPIO assert is required to reset the system. Otherwise, the system will hang on reboot. Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Reviewed-by: Robert Marko <robimarko@gmail.com> (cherry picked from commit a2817ce96f17db3a5af77837ae5733b47182ae0d)
* realtek: add reset button for D-Link DGS-1210-28Luiz Angelo Daros de Luca2022-06-071-0/+18
| | | | | | | | Tested in a DGS-1210-28 F3, both triggering failsafe and reboot. Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Reviewed-by: Robert Marko <robimarko@gmail.com> (cherry picked from commit b85f59b726442621efb95153ff60b8767723feca)
* packages: nvram: add NVRAM quirks for bcm53xx targetArınç ÜNAL2022-06-071-13/+0
| | | | | | | | | | | | Add NVRAM quirks script for the bcm53xx target. Split NVRAM quirks for the bcm47xx and bcm53xx targets. Move clear partialboot NVRAM quirk for Linksys EA9500 here. Add set wireless LED behaviour quirk for Asus RT-AC88U. Use boot() instead of start() as nvram commands are meant to be executed only once, at boot. Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> (cherry picked from commit f4e219fd5e6cfa33d234dad134fb105cc1620f54)
* bcm53xx: add support for Asus RT-AC88UArınç ÜNAL2022-06-072-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Asus RT-AC88U is an AC3100 router featuring 9 Ethernet ports over the integrated Broadcom and the external Realtek switch. Hardware info: * Processor: Broadcom BCM4709C0KFEBG dual-core @ 1.4 GHz * Switch: BCM53012 in BCM4709C0KFEBG & external RTL8365MB * DDR3 RAM: 512 MB * Flash: 128 MB (ESMT F59L1G81LA-25T) * 2.4GHz: BCM4366 4×4 2.4/5G single chip 802.11ac SoC * 5GHz: BCM4366 4×4 2.4/5G single chip 802.11ac SoC * Ports: 8 Ports, 1 WAN Ports Flashing instructions: * Boot to CFE Recovery Mode by holding the reset button while power-on. * Connect to the router with an ethernet cable. * Set IPv4 address of the computer to 192.168.1.2 subnet 255.255.255.0. * Head to http://192.168.1.1. * Reset NVRAM. * Upload the OpenWrt image. CFE bootloader may reject flashing the image due to image integrity check. In that case, follow the instructions below. * Rename the OpenWrt image as firmware.trx. * Run a TFTP server and make it serve the firmware.trx file. * Run the URL below on a browser or curl. http://192.168.1.1/do.htm?cmd=flash+-noheader+192.168.1.2:firmware.trx+flash0.trx Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> [rmilecki: mark BROKEN until we sort out nvram & CFE recovery] Signed-off-by: Rafał Miłecki <rafal@milecki.pl> (cherry picked from commit 72b9b721d707b7f70109eb70b2a9f22449ceba08)
* realtek: add support for ZyXEL GS1900-24ERaylynn Knight2022-06-062-0/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ZyXEL GS1900-24E is a 24 port gigabit switch similar to other GS1900 switches. Specifications -------------- * Device: ZyXEL GS1900-24E * SoC: Realtek RTL8382M 500 MHz MIPS 4KEc * Flash: 16 MiB Macronix MX25L12835F * RAM: 128 MiB DDR2 SDRAM Nanya NT5TU128M8GE * Ethernet: 24x 10/100/1000 Mbps * LEDs: 1 PWR LED (green, not configurable) 1 SYS LED (green, configurable) 24 ethernet port link/activity LEDs (green, SoC controlled) * Buttons: 1 "RESET" button on front panel * Switch: 1 Power switch on rear of device * Power 120-240V AC C13 * UART: 1 serial header (JP2) with populated standard pin connector on the left side of the PCB. Pinout (front to back): + Pin 1 - VCC marked with white dot + Pin 2 - RX + Pin 3 - TX + PIn 4 - GND Serial connection parameters: 115200 8N1. Installation ------------ OEM upgrade method: * Log in to OEM management web interface * Navigate to Maintenance > Firmware * Select the HTTP radio button * Select the Active radio button * Use the browse button to locate the realtek-rtl838x-zyxel_gs1900-24e-initramfs-kernel.bin file and select open so File Path is updated with filename. * Select the Apply button. Screen will display "Prepare for firmware upgrade ...". *Wait until screen shows "Do you really want to reboot?" then select the OK button * Once OpenWrt has booted, scp the sysupgrade image to /tmp and flash it: > sysupgrade -n /tmp/realtek-rtl838x-zyxel_gs1900-24e-squashfs-sysupgrade.bin it may be necessary to restart the network (/etc/init.d/network restart) on the running initramfs image. U-Boot TFTP method: * Configure your client with a static 192.168.1.x IP (e.g. 192.168.1.10). * Set up a TFTP server on your client and make it serve the initramfs image. * Connect serial, power up the switch, interrupt U-boot by hitting the space bar, and enable the network: > rtk network on * Since the GS1900-24E is a dual-partition device, you want to keep the OEM firmware on the backup partition for the time being. OpenWrt can only boot from the first partition anyway (hardcoded in the DTS). To make sure we are manipulating the first partition, issue the following commands: > setsys bootpartition 0 > savesys * Download the image onto the device and boot from it: > tftpboot 0x84f00000 192.168.1.10:openwrt-realtek-rtl838x-zyxel_gs1900-24e-initramfs-kernel.bin > bootm * Once OpenWrt has booted, scp the sysupgrade image to /tmp and flash it: > sysupgrade -n /tmp/openwrt-realtek-rtl838x-zyxel_gs1900-24e-squashfs-sysupgrade.bin it may be necessary to restart the network (/etc/init.d/network restart) on the running initramfs image. Signed-off-by: Raylynn Knight <rayknight@me.com> (cherry picked from commit b515ad10a6e1bd5c5da0ea95366fb19c92a75dea)
* ramips: use hotplug script for EAP615-Wall MACsStijn Tintel2022-06-062-2/+4
| | | | | | | | | | | | | | Using nvmem-cells to set the MAC address for a DBDC device results in both PHY devices using the same MAC address. This in turn will result in multiple BSSes using the same BSSID, which can cause various problems. Use the hotplug script for the EAP615-Wall instead to avoid this. Fixes: a1b8a4d7b3ff ("ramips: support TP-Link EAP615-Wall") Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be> Tested-by: Stijn Segers <foss@volatilesystems.org> Tested-By: Andrew Powers-Holmes <aholmes@omnom.net> (cherry picked from commit ce90ba1f3168e3f4581fd8581e2c0cd31efa14cf)
* ipq40xx: add Aruba AP-365 specific BDFDavid Bauer2022-06-022-1/+10
| | | | | | | | | | | | | | Aruba deploys a BDF in the root filesystem, however this matches the one used for the DK04 reference board. The board-specific BDFs are built into the kernel. The AP-365 shows sinificant degraded performance with increased range when used with the reference BDF. Replace the BDF with the one extracted from Arubas kernel. Signed-off-by: David Bauer <mail@david-bauer.net> (cherry picked from commit b21b98627dcd6c1868d13964f6d84e8d43ae9ef7)
* malta: use default OpenWrt network configurationHauke Mehrtens2022-06-021-13/+0
| | | | | | | | | | | | | | | | | Currently malta configures the first Ethernet device as WAN interface. If it finds a second one it will configure it as LAN. This commit reverses it to match armvirt and x86. If there is only one network device it will be configured as LAN device now. If we find two network devices the 2. one will be WAN. If no board.d network configuration is given it will be configured in package/base-files/files/etc/board.d/99-default_network Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> [minor typos] Signed-off-by: Paul Spooren <mail@aparcar.org> (cherry picked from commit fb1ba922026a4b7d04ef5c8058f7890ed7b790e6)
* ath79: fix label MAC address for D-Link DIR-825B1Sebastian Schaper2022-05-291-0/+1
| | | | | | | | The label MAC address for DIR-825 Rev. B1 is the WAN address located at 0xffb4 in `caldata`, which equals LAN MAC at 0xffa0 incremented by 1. Signed-off-by: Sebastian Schaper <openwrt@sebastianschaper.net> (cherry picked from commit 4bed263af7a13cb4b9401f7ae04f788cfcc234f7)
* ath79: NanoBeam M5 fix target_devicesJan-Niklas Burfeind2022-05-212-2/+2
| | | | | | | | | | | Update the name of for the Ubiquiti NanoBeam M5 to match the auto-generated one at runtime. Otherwise sysupgrade complains about mismatching device names. This also required renaming the DTS. Signed-off-by: Jan-Niklas Burfeind <git@aiyionpri.me> (cherry picked from commit 21a3ce97d571ef28a25754549503bab61a79faf2)
* ath79: add support for Ubiquiti NanoBeam M5Jan-Niklas Burfeind2022-05-212-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ubiquiti NanoBeam M5 devices are CPE equipment for customer locations with one Ethernet port and a 5 GHz 300Mbps wireless interface. Specificatons: - Atheros AR9342 - 535 MHz CPU - 64 MB RAM - 8 MB Flash - 1x 10/100 Mbps Ethernet with passive PoE input (24 V) - 6 LEDs of which four are rssi - 1 reset button - UART (4-pin) header on PCB Notes: The device was supported by OpenWrt in ar71xx. Flash instructions (web/ssh/tftp): Loading the image via ssh vias a stock firmware prior "AirOS 5.6". Downgrading stock is possible. * Flashing is possible via AirOS software update page: The "factory" ROM image is recognized as non-native and then installed correctly. AirOS warns to better be familiar with the recovery procedure. * Flashing can be done via ssh, which is becoming difficult due to legacy keyexchange methods. This is an exempary ssh-config: KexAlgorithms +diffie-hellman-group1-sha1 HostKeyAlgorithms ssh-rsa PubkeyAcceptedKeyTypes ssh-rsa User ubnt The password is ubnt. Connecting via IPv6 link local worked best for me. 1. scp the factory image to /tmp 2. fwupdate.real -m /tmp/firmware_image_file.bin -d * Alternatively tftp is possible: 1. Configure PC with static IP 192.168.1.2/24. 2. Enter the rescue mode. Power off the device, push the reset button on the device (or the PoE) and keep it pressed. Power on the device, while still pushing the reset button. 3. When all the leds blink at the same time, release the reset button. 4. Upload the firmware image file via TFTP: tftp 192.168.1.20 tftp> bin tftp> trace Packet tracing on. tftp> put firmware_image.bin Signed-off-by: Jan-Niklas Burfeind <git@aiyionpri.me> (cherry picked from commit 4cd3ff8a79738fa503150e52162c7df6d9bd3534)
* ath79: add support for MikroTik hAP (RB951Ui-2nD)Maciej Krüger2022-05-216-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The MikroTik hAP (product code RB951Ui-2nD) is an indoor 2.4Ghz AP with a 2 dBi integrated antenna built around the Atheros QCA9531 SoC. Specifications: - SoC: Atheros QCA9531 - RAM: 64 MB - Storage: 16 MB NOR - Winbond 25Q128FVSG - Wireless: Atheros QCA9530 (SoC) 802.11b/g/n 2x2 - Ethernet: Atheros AR934X switch, 5x 10/100 ports, 10-28 V passive PoE in port 1, 500 mA PoE out on port 5 - 8 user-controllable LEDs: · 1x power (green) · 1x user (green) · 4x LAN status (green) · 1x WAN status (green) · 1x PoE power status (red) See https://mikrotik.com/product/RB951Ui-2nD for more details. Notes: The device was already supported in the ar71xx target. Flashing: TFTP boot initramfs image and then perform sysupgrade. Follow common MikroTik procedure as in https://openwrt.org/toh/mikrotik/common. Signed-off-by: Maciej Krüger <mkg20001@gmail.com> (cherry picked from commit 5ce64e0646fcd5c4f374b4de898b591560c32e18)
* ath79: add support for MikroTik RouterBOARD hAP ac liteThibaut VARÈNE2022-05-217-0/+142
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The MikroTik RB952Ui-5ac2nD (sold as hAP ac lite) is an indoor 2.4Ghz and 5GHz AP/router with a 2 dBi integrated antenna. See https://mikrotik.com/product/RB952Ui-5ac2nD for more details. Specifications: - SoC: QCA9533 - RAM: 64MB - Storage: 16MB NOR - Wireless: QCA9533 802.11b/g/n 2x2 / QCA9887 802.11a/n/ac 2x2 - Ethernet: AR934X switch, 5x 10/100 ports, 10-28 V passive PoE in port 1, 500 mA PoE out on port 5 - 6 user-controllable LEDs: - 1x user (green) - 5x port status (green) Flashing: TFTP boot initramfs image and then perform sysupgrade. The "Internet" port (port number 1) must be used to upload the TFTP image, then connect to any other port to access the OpenWRT system. Follow common MikroTik procedure as in https://openwrt.org/toh/mikrotik/common. Signed-off-by: Thibaut VARÈNE <hacks@slashdirt.org> (cherry picked from commit 2bd33e8626bd04fd7115ee1a42aaf03aae2fffb8)
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-04 17:36:59 +0000