aboutsummaryrefslogtreecommitdiffstats
path: root/target/linux
Commit message (Collapse)AuthorAgeFilesLines
* kernel: bump 4.14 to 4.14.267Petr Štetiar2022-02-166-22/+23
| | | | | | | | | | | All patches refreshed automagically without conflicts, but test builds choked on new BPF_UNPRIV_DEFAULT_OFF kernel config symbol introduced in upstream commit e69f08ba23a3 ("bpf: Add kconfig knob for disabling unpriv bpf by default"). Run tested on ipq40xx/glinet-b1300 and mvebu/turris-omnia. Signed-off-by: Petr Štetiar <ynezz@true.cz>
* kernel: bump 4.14 to 4.14.265Petr Štetiar2022-02-105-17/+17
| | | | | | | | All patches refreshed automagically without conflicts. Run tested on ipq40xx/glinet-b1300 and mvebu/turris-omnia. Signed-off-by: Petr Štetiar <ynezz@true.cz>
* kernel: bump 4.14 to 4.14.264Petr Štetiar2022-01-3120-82/+82
| | | | | | | | All patches refreshed automagically without conflicts. Run tested on ipq40xx/glinet-b1300 and mvebu/turris-omnia. Signed-off-by: Petr Štetiar <ynezz@true.cz>
* kernel: bump 4.14 to 4.14.262Petr Štetiar2022-01-181-7/+7
| | | | | | | | All patches refreshed automagically without conflicts. Run tested on ipq40xx/glinet-b1300 and mvebu/turris-omnia. Signed-off-by: Petr Štetiar <ynezz@true.cz>
* kernel: bump 4.14 to 4.14.261Petr Štetiar2022-01-0621-36/+36
| | | | | | | | All patches refreshed automagically without conflicts. Run tested on ipq40xx/glinet-b1300 and mvebu/turris-omnia. Signed-off-by: Petr Štetiar <ynezz@true.cz>
* kernel: bump 4.14 to 4.14.259Petr Štetiar2021-12-2946-28/+58
| | | | | | | | | | | | All patches refreshed automagically without conflicts, but upstream in commit 48c2461f28fe ("ARM: 8800/1: use choice for kernel unwinders") added new config options UNWINDER_ARM and UNWINDER_FRAME_POINTER so we need to adjust default configs as well. Run tested on ipq40xx/glinet-b1300 and mvebu/turris-omnia. Signed-off-by: Petr Štetiar <ynezz@true.cz> Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
* kernel: bump 4.14 to 4.14.258Petr Štetiar2021-12-1946-387/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | Rebased patches: * generic: 273-batman-adv-Convert-packet.h-to-uapi-header.patch * ipq806x: 0065-arm-override-compiler-flags.patch * mvebu: 513-arm64-dts-marvell-armada37xx-Add-emmc-sdio-pinctrl-d.patch Removed patches: Fixed upstream: * ar71xx: 821-serial-core-add-support-for-boot-console-with-arbitr.patch * ath79: 921-serial-core-add-support-for-boot-console-with-arbitr.patch - in 4.14.256 via 9112e7ef87149b3d8093e7446d784117f6e18d69 * mvebu: 527-PCI-aardvark-allow-to-specify-link-capability.patch - in 4.14.257 via 62a3dc9b65a2b24800fc4267b8cf590fad135034 * mvebu: 524-PCI-aardvark-set-host-and-device-to-the-same-MAX-payload-size.patch - should be hopefully fixed by the bunch of changes in .256 and .257 Run tested on ipq40xx/glinet-b1300 and mvebu/turris-omnia. Fixes: CVE-2021-3640 Signed-off-by: Petr Štetiar <ynezz@true.cz>
* kernel: bump 4.14 to 4.14.254Hauke Mehrtens2021-11-0723-51/+51
| | | | | | | | | All updated automatically. Compile-tested on: malta/le, lantiq/xrx200 Runtime-tested on: malta/le, lantiq/xrx200 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* ar71xx: mikrotik: rb91x: fix 10M ethernet link speedKoen Vandeputte2021-10-121-0/+1
| | | | | | | | | | | | | | | Extensive testing on the board showed that ethernet does not work when forced to 10Mbps. Trial-and-error revealed that the correct PLL value should be altered to 0x00001313 (iso 0x00001616) The change is done for this specific board only as I do not have other boards using this specific SoC. The board now works correctly in 1000, 100 and 10 Mode Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
* kernel: bump 4.14 to 4.14.248Hauke Mehrtens2021-10-0220-43/+43
| | | | | | | | | All updated automatically. Compile-tested on: lantiq/xrx200, armvirt/64 Runtime-tested on: lantiq/xrx200, armvirt/64 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* kernel: bump 4.14 to 4.14.245David Bauer2021-09-0223-47/+47
| | | | | | | Compile-tested: ath79-generic Run-tested: ath79-generic Signed-off-by: David Bauer <mail@david-bauer.net>
* kernel: bump to 4.14.244David Bauer2021-08-203-3/+3
| | | | | | | Compile-tested: ath79-generic ipq40xx-generic Run-tested: ipq40xx-generic Signed-off-by: David Bauer <mail@david-bauer.net>
* kernel: bump to 4.14.243David Bauer2021-08-145-19/+19
| | | | | | | Compile-tested: x86-64 Run-tested: x86-64 Signed-off-by: David Bauer <mail@david-bauer.net>
* kernel: bump 4.14 to 4.14.241David Bauer2021-07-2841-113/+129
| | | | | | | | | Refreshed all patches Compile-tested: ath79-generic brcm2708-bcm2708 Run-tested: ath79-generic brcm2708-bcm2708 Signed-off-by: David Bauer <mail@david-bauer.net>
* kernel: bump 4.14 to 4.14.235Hauke Mehrtens2021-06-0620-56/+38
| | | | | | | | | | | | Manually rebased ramips/patches-5.4/0048-asoc-add-mt7620-support.patch All others updated automatically. Compile-tested on: ath79/generic, ramips/mt7621 Runtime-tested on: ath79/generic Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* generic: platform/mikrotik: release mtd device after useKoen Vandeputte2021-05-121-1/+4
| | | | | | | | | | | | | | The code uses get_mtd_device_nm() which must be followed by a call to put_mtd_device() once the handle is no longer used. This fixes spurious shutdown console messages such as: [ 83.099037] Removing MTD device #1 (hard_config) with use count 1 Reported-by: Koen Vandeputte <koen.vandeputte@ncentric.com> Tested-by: Koen Vandeputte <koen.vandeputte@ncentric.com> Signed-off-by: Thibaut VARÈNE <hacks@slashdirt.org> [Backported from master] Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
* kernel: bump 4.14 to 4.14.232Koen Vandeputte2021-05-103-5/+5
| | | | | | | | | | | | Refreshed all patches. Fixes: - CVE-2021-23133 Compile-tested on: ar71xx, cns3xxx, imx6, x86_64 Runtime-tested on: ar71xx, cns3xxx, imx6 Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
* ramips: backport unlocked mdiobus accessorsDavid Bauer2021-05-031-0/+141
| | | | | | | | | | | Commit 718e97c5c843 ("ramips: mt7530 swconfig: fix race condition in register access") backports a fix which depends on unlocked MMD accessors, however these were not yet included in Kernel 4.14 and they were not backported yet. Fixes commit 718e97c5c843 ("ramips: mt7530 swconfig: fix race condition in register access") Signed-off-by: David Bauer <mail@david-bauer.net>
* ramips: mt7530 swconfig: fix race condition in register accessDENG Qingfang2021-05-021-6/+10
| | | | | | | | | | | | | | | | | | | [ Upstream commit f99c9cd9c4d4c49a676d678327546fd41690fe2a ] The mt7530_{r,w}32 operation over MDIO uses 3 mdiobus operations and does not hold a lock, which causes a race condition when multiple threads try to access a register, they may get unexpected results. To avoid this, handle the MDIO lock manually, and use the unlocked __mdiobus_{read,write} in the critical section. This fixes the "Ghost VLAN" artifact[1] in MT7530/7621 when the VLAN operation and the swconfig LED link status poll race between each other. [1] https://forum.openwrt.org/t/mysterious-vlan-ids-on-mt7621-device/64495 Signed-off-by: DENG Qingfang <dqfext@gmail.com> (cherry picked from commit f99c9cd9c4d4c49a676d678327546fd41690fe2a)
* kernel: bump 4.14 to 4.14.231Koen Vandeputte2021-04-302-8/+8
| | | | | | | | | | | | | | Refreshed all patches. Fixes: - CVE-2020-25672 - CVE-2020-25671 - CVE-2020-25670 Compile-tested on: ar71xx, cns3xxx, imx6, x86_64 Runtime-tested on: ar71xx, cns3xxx, imx6 Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
* kernel: bump 4.14 to 4.14.230Koen Vandeputte2021-04-306-81/+31
| | | | | | | | | | | | Refreshed all patches. Remove upstreamed: - 840-can-flexcan-flexcan_chip_freeze-fix-chip-freeze-for-.patch Compile-tested on: ar71xx, cns3xxx, imx6, x86_64 Runtime-tested on: ar71xx, cns3xxx, imx6 Signed-off-by: Koen Vandeputte <koen.vandeputte@citymesh.com>
* kernel: backport fix for flexcan bugKoen Vandeputte2021-04-091-0/+50
| | | | | | | | This patch fixes a DIV/0 error which was introduced in 4.14.225 This patch was forgotten in upstream <= 4.14 and is now queued for future release. Signed-off-by: Koen Vandeputte <koen.vandeputte@citymesh.com>
* kernel: bump 4.14 to 4.14.229Koen Vandeputte2021-04-096-9/+9
| | | | | | | | | Refreshed all patches. Compile-tested on: ar71xx, cns3xxx, imx6, x86_64 Runtime-tested on: ar71xx, cns3xxx, imx6 Signed-off-by: Koen Vandeputte <koen.vandeputte@citymesh.com>
* kernel: bump 4.14 to 4.14.228Koen Vandeputte2021-04-093-30/+30
| | | | | | | | | Refreshed all patches. Compile-tested on: ar71xx, cns3xxx, imx6, x86_64 Runtime-tested on: ar71xx, cns3xxx, imx6 Signed-off-by: Koen Vandeputte <koen.vandeputte@citymesh.com>
* kernel: bump 4.14 to 4.14.227Koen Vandeputte2021-04-0926-73/+73
| | | | | | | | | | | | Refreshed all patches. Altered patches: - 809-flexcan-support-layerscape.patch Compile-tested on: ar71xx, cns3xxx, imx6, layerscape, x86_64 Runtime-tested on: ar71xx, cns3xxx, imx6 Signed-off-by: Koen Vandeputte <koen.vandeputte@citymesh.com>
* kernel: bump 4.14 to 4.14.224Koen Vandeputte2021-03-103-4/+4
| | | | | | | | | Refreshed all patches. Compile-tested on: ar71xx, cns3xxx, imx6, x86_64 Compile-tested on: ar71xx, cns3xxx, imx6 Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
* kernel: bump 4.14 to 4.14.223Koen Vandeputte2021-03-1018-49/+49
| | | | | | | | | Refreshed all patches. Compile-tested on: ar71xx, cns3xxx, imx6, x86_64 Runtime-tested on: ar71xx, cns3xxx, imx6 Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
* kernel: bump 4.14 to 4.14.222Koen Vandeputte2021-02-267-14/+14
| | | | | | | | | Refreshed all patches. Compile-tested on: ar71xx, cns3xxx, imx6, x86_64 Runtime-tested on: ar71xx, cns3xxx, imx6 Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
* ramips: remove factory image for TP-Link Archer C20 v1Stijn Segers2021-02-191-1/+0
| | | | | | | | | | | | | Similarly to the Archer C2 v1, the Archer C20 v1 will brick when one tries to flash an OpenWrt factory image through the TP-Link web UI. The wiki page contains an explicit warning about this [1]. Disable the factory image altogether since it serves no purpose. [1] https://openwrt.org/toh/tp-link/tp-link_archer_c20_v1#installation Signed-off-by: Stijn Segers <foss@volatilesystems.org> (backported from commit 0265cba40ad4f2b8ff4473ada123c35b53ffd97a)
* lantiq: fritz7320: enable USB power supplyMathias Kresin2021-02-181-0/+46
| | | | | | | | | | | | | The USB ports if a FRIZZ!Box 7320 do not supply power to connected devices. Add the GPIOs enabling USB power as regulator, to enable USB power supply as soon as the USB driver is loaded. Fixes FS#3624 Signed-off-by: Mathias Kresin <dev@kresin.me> (cherry picked from commit 6e4e97b2256327bb380ee2a83da9a1ddf657e395)
* kernel: bump 4.14 to 4.14.221Koen Vandeputte2021-02-157-29/+20
| | | | | | | | | | | | Refreshed all patches. Remove upstreamed hunk in: - 302-dts-support-layerscape.patch Compile-tested on: ar71xx, cns3xxx, imx6, x86_64 Runtime-tested on: ar71xx, cns3xxx, imx6 Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
* ramips: ethernet: Disable TSO support to improve stabilityBaptiste Jonglez2021-02-151-2/+1
| | | | | | | | | | | | | | | | | | | | | | | Stability of this Ethernet driver has been a long-standing issue, with many people reporting frequent "transmit queue timeouts" and even occasional crashes. Disabling TSO in the driver helps with stability, although it is likely a workaround and might not fix the issue completely. There is a slight slowdown in forwarding performance for TCP packets (75 kpps vs. 80 kpps with comparable CPU utilization), but this is still enough to forward close to 1 Gbit/s of full-sized packets across multiple flows. Master is using a different ethernet driver, so this is not a backport. Because of this different driver, the upcoming 21.02 release does not seem to be affected by these stability issues. Thanks to mrakotiq for the initial patch. Fixes: FS#2628 Signed-off-by: Baptiste Jonglez <git@bitsofnetworks.org>
* ramips: mark toggle input on EX6150 as a switchKurt Roeckx2021-02-151-0/+1
| | | | | | | | | | The Netgear EX6150 has an Access Point/Extender switch. Set it as an EV_SW. Otherwise when it's set to Access Point, it will trigger failsafe mode during boot. Fixes: FS#3590 Signed-off-by: Kurt Roeckx <kurt@roeckx.be> (cherry picked from commit 539966554d6d0686dc8ce62e39ff9e8f4e2d4e74)
* ramips: remove factory image for TP-Link Archer C2 v1Stijn Segers2021-02-141-1/+0
| | | | | | | | | | | | | | | | | | | | Initial commit 8375623a0640 ("ramips: add support for TP-Link Archer C2") contains detailed installation instructions, which do not mention a factory image. From what I can see, no support to install OpenWrt through the vendor web interface has been added since. The factory image is also conspicuously absent from the device page in the wiki. Yet, it is available for download. I bricked my Archer C2 loading the factory image through the web UI. Serial showed this error during bootloop: Uncompressing Kernel Image ... LZMA ERROR 1 - must RESET board to recover This patch disables the undocumented factory image so users won't get tricked into thinking easy web UI flashing actually works. Signed-off-by: Stijn Segers <foss@volatilesystems.org> (backported from commit ad5e29d38a48ce6ffbcabaf5d83bc76a64dfbe56)
* ath79: fix USB power GPIO for TP-Link TL-WR810N v1Adrian Schmutzler2021-02-121-1/+1
| | | | | | | | | | | | | | | | | | | The TP-Link TL-WR810N v1 is known to cause soft-brick on ath79 and work fine for ar71xx [1]. On closer inspection, the only apparent difference is the GPIO used for the USB regulator, which deviates between the two targets. This applies the value from ar71xx to ath79. Tested successfully by a forum user. [1] https://forum.openwrt.org/t/tp-link-tl-wr810n-v1-ath79/48267 Fixes: cdbf2de77768 ("ath79: Add support for TP-Link WR810N") Fixes: FS#3522 Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de> (cherry picked from commit 6934d30cf8d95bc8652b4dcd8180d14e5e8e2417)
* bcm63xx: sprom: override the PCI device IDDaniel González Cabanelas2021-02-072-1/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The PCI device ID detected by the wifi drivers on devices using a fallback SPROM is wrong. Currently the chipnum is used for this parameter. Most SSB based Broadcom wifi chips are 2.4 and 5GHz capable. But on devices without a physical SPROM, the only one way to detect if the device suports both bands or only the 5GHz band, is by reading the device ID from the fallback SPROM. In some devices, this may lead to a non working wifi on a 5GHz-only card, or in the best case a working 2.4GHz-only in a dual band wifi card. The offset for the deviceid in SSB SPROMs is 0x0008, whereas in BCMA is 0x0060. This is true for any SPROM version. Override the PCI device ID with the one defined at the fallback SPROM, to detect the correct wifi card model and allow using the 5GHz band if supported. The patch has been tested with the following wifi radios: BCM43222: b43: both 2.4/5GHz working brcm-wl: both 2.4/5GHz working BCM43225: b43: 2.4GHz, working brcmsmac: working brcm-wl: it lacks support BCM43217: b43: 2.4GHz, working brcmsmac: it lacks support brcm-wl: it lacks support Signed-off-by: Daniel González Cabanelas <dgcbueu@gmail.com> Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> Backported from a0e0e621ca
* kernel: bump 4.14 to 4.14.219Koen Vandeputte2021-02-052-2/+2
| | | | | | | | | Refreshed all patches. Compile-tested on: ar71xx, cns3xxx, imx6, x86_64 Runtime-tested on: ar71xx, cns3xxx, imx6 Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
* bcm63xx: R5010UNv2: fix flash partitions for 16MB flashDaniel González Cabanelas2021-02-041-5/+5
| | | | | | | | | | | | The router Nucom R5010UN v2 has the partitions defined for a 8MB flash, but the flash chip is 16MB size. We are wasting half of the flash. Fix it and use generic names for partitions. Fixes: 474cde61234c ("brcm63xx: probe SPI flash through DT") Signed-off-by: Daniel González Cabanelas <dgcbueu@gmail.com> (cherry picked from commit cef9e5a49f496b64449fca6814fc1b66a45601c3)
* kernel: bump 4.14 to 4.14.218Koen Vandeputte2021-02-025-9/+9
| | | | | | | | | Refreshed all patches. Compile-tested on: ar71xx, cns3xxx, imx6, x86_64 Runtime-tested on: ar71xx, cns3xxx, imx6 Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
* mvebu: omnia: make initramfs image usable out of the boxPetr Štetiar2021-02-021-2/+2
| | | | | | | | | | | | | | | | Currently it's not possible to boot the device with just initramfs image without additional effort as the initramfs image doesn't contain device tree. Fix it by producing FIT based image which could be booted with following commands: setenv bootargs earlyprintk console=ttyS0,115200 tftpboot ${kernel_addr_r} openwrt-mvebu-cortexa9-cznic_turris-omnia-initramfs-kernel.bin bootm ${kernel_addr_r} Acked-by: Klaus Kudielka <klaus.kudielka@gmail.com> Reviewed-by: Tomasz Maciej Nowak <tmn505@gmail.com> Signed-off-by: Petr Štetiar <ynezz@true.cz> (cherry-picked from commit 337ff74894110b35b61118918b7eb30bb6e60756)
* kernel: bump 4.14 to 4.14.217Hauke Mehrtens2021-01-255-11/+11
| | | | | | | | | Refreshed all patches. Compile-tested on: ipq40xx, lantiq/xrx200, x86/64, ipq806x Runtime-tested on: ipq40xx, lantiq/xrx200, x86/64 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* kernel: bump 4.14 to 4.14.216Koen Vandeputte2021-01-212-3/+3
| | | | | | | | | Refreshed all patches. Compile-tested on: ar71xx, cns3xxx, imx6, x86_64 Runtime-tested on: ar71xx, cns3xxx, imx6 Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
* kernel: bump 4.14 to 4.14.215Hauke Mehrtens2021-01-172-7/+7
| | | | | | | | | Refreshed all patches. Compile-tested on: ipq40xx, lantiq/xrx200, x86/64, ipq806x Runtime-tested on: ipq40xx, lantiq/xrx200, x86/64 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* kernel: bump 4.14 to 4.14.214Hauke Mehrtens2021-01-1216-176/+30
| | | | | | | | | | | | | Refreshed all patches. Removed patches because included in upstream: - 499-mtd-parser-cmdline-Fix-parsing-of-part-names-with-co.patch - 0071-2-PCI-qcom-Fixed-IPQ806x-PCIE-reset-changes.patch Compile-tested on: ipq40xx, lantiq/xrx200, x86/64, ipq806x Runtime-tested on: ipq40xx, lantiq/xrx200, x86/64 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* ath79: image: fix initramfs for safeloader devicesPetr Štetiar2020-12-171-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently it's not possible to tftpboot initramfs image on archer-c7-v5 as the image contains tplink-v1-header which leads to: ath> bootm ## Booting image at 81000000 ... Bad Magic Number as U-Boot expects uImage wrapped image. This is caused by following inheritance issue: define Device/Init KERNEL_INITRAMFS = $$(KERNEL) define Device/tplink-v1 KERNEL := kernel-bin | append-dtb | lzma KERNEL_INITRAMFS := kernel-bin | append-dtb | lzma | tplink-v1-header define Device/tplink-safeloader $(Device/tplink-v1) define Device/tplink-safeloader-uimage $(Device/tplink-safeloader) KERNEL := kernel-bin | append-dtb | lzma | uImageArcher lzma define Device/tplink_archer-c7-v5 $(Device/tplink-safeloader-uimage) where tplink-v1 defines KERNEL_INITRAMFS with tplink-v1-header and it's then used by all devices inheriting from tplink-safeloader. Fix this by overriding KERNEL_INITRAMFS to KERNEL variable again. Signed-off-by: Petr Štetiar <ynezz@true.cz> (cherry picked from commit ceeece9ffaa5a3a336505332c39794d76c08b2ca)
* kernel: bump 4.14 to 4.14.212Hauke Mehrtens2020-12-1616-84/+40
| | | | | | | | | | | | Refreshed all patches. Removed patches because included in upstream: - 315-v5.10-usbnet-ipeth-fix-connectivity-with-ios-14.patch Compile-tested on: ipq40xx, ath79, x86/64 Runtime-tested on: ipq40xx, ath79 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* ramips: enable LED VCC for Asus RT-AC51UDavide Fioravanti2020-12-101-11/+9
| | | | | | | | | | Previously only the power LED was working. With this patch all leds except 5GHz are working. Signed-off-by: Davide Fioravanti <pantanastyle@gmail.com> [rephrased commit title, drop status property] Signed-off-by: David Bauer <mail@david-bauer.net> (cherry picked from commit 67d019ac94015707926235a3ac0aa6bb12cee8c2)
* generic: ipeth: fix iOS 14 tetheringDavid Bauer2020-12-071-0/+44
| | | | | | | | | This fixes tethering with devices using iOS 14. Prior to this patch, connections to remote endpoints were not possible while data transfers between the OpenWrt device and the iOS endpoints worked fine. Signed-off-by: David Bauer <mail@david-bauer.net> (cherry picked from commit f64496f30f2ef97124dc4e13a48ee0de9d51832e)
* mvebu: fixup Turris Omnia U-Boot environmentKlaus Kudielka2020-12-041-0/+44
| | | | | | | | | | | | | | | | Fixup dfa357a3de "mvebu: base-files: Update Turris Omnia U-Boot environment" which should have included this file as well. By rebasing the initial patch this file somehow disappeared. Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com> Reviewed-by: Tomasz Maciej Nowak <tomek_n@o2.pl> Tested-by: W. Michael Petullo <mike@flyn.org> (Turris Omnia "2020") Tested-by: Klaus Kudielka <klaus.kudielka@gmail.com> (Turris Omnia) [explain fixup in commit message] Signed-off-by: Paul Spooren <mail@aparcar.org> (backported from commit 485ce5bbe5cc33526e56817694a79a7d94160e01) Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* mvebu: base-files: Update Turris Omnia U-Boot environmentKlaus Kudielka2020-12-041-9/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move the update procedure from sysupgrade to first boot, which is much more convenient in the sysupgrade case (otherwise the environment is always one generation behind). Check whether we have an old U-Boot release installed, and update the environment only if necessary. Some notes on the U-Boot environment: The first 9 lines are a copy of the default environment of the old U-Boot release - only modified, to run "distro_bootcmd", in case "mmcboot" fails to boot the factory OS. The remaining 16 lines are a backport of the default environment of the new U-Boot release (shipped with CZ11NIC23). The main entry point is "distro_bootcmd", which eventually sources boot.scr. This way, we have a unified boot protocol for all Turris Omnia revisions so far. This commit also fixes a shortcoming of previous Turris Omnia support: Users may install OpenWrt with the Turris Omnia in factory state (i.e. invalid environment store). In that case, neither fw_setenv, nor U-Boot itself, would import the default environment from the image - screwing up the rescue system, at least! Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com> Reviewed-by: Tomasz Maciej Nowak <tomek_n@o2.pl> Tested-by: W. Michael Petullo <mike@flyn.org> (Turris Omnia "2020") Tested-by: Klaus Kudielka <klaus.kudielka@gmail.com> (Turris Omnia) (cherry picked from commit dfa357a3def512c13f22371d24138b6e8093be18)
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-24 17:41:55 +0000