Previously, grub2 was hardcoded to always look on "hd0" for the
kernel.
This works well when the system only had a single disk.
But if there was a second disk/stick present, it may have look
on the wrong drive because of enumeration races.
This patch utilizes grub2 search function to look for a filesystem
with the label "kernel". This works thanks to existing setup in
scripts/gen_image_generic.sh. Which sets the "kernel" label on
both the fat and ext4 filesystem variants.
Signed-off-by: Jax Jiang <jax.jiang.007@gmail.com>
Suggested-by: Alberto Bursi <bobafetthotmail@gmail.com> (MX100 WA)
(word wrapped, slightly rewritten commit message, removed MX100 WA)
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
(cherry picked from commit 1050e66c8f7c67ab8b3d1895e2559f03baeb2345)
These devices only have 6MiB available for firmware, which is not
enough for recent release images, so move these to the tiny target.
Note for users sysupgrading from the previous ath79-generic snapshot
images:
The tiny target kernel has a 4Kb flash erase block size instead
of the generic target's 64kb. This means the JFFS2 overlay partition
containing settings must be reformatted with the new block size or else
there will be data corruption.
To do this, backup your settings before upgrading, then during the
sysupgrade, de-select "Keep Settings". On the CLI, use "sysupgrade -n".
If you forget to do this and your system becomes unstable after
upgrading, you can do this to format the partition and recover:
* Reboot
* Press RESET when Power LED blinks during boot to enter Failsafe mode
* SSH to 192.168.1.1
* Run "firstboot" and reboot
Signed-off-by: Joe Mullally <jwmullally@gmail.com>
Tested-by: Robert Högberg <robert.hogberg@gmail.com>
Signed-off-by: Petr Štetiar <ynezz@true.cz> [commit message facelift]
(cherry picked from commit 44e1e5d)
Signed-off-by: Petr Štetiar <ynezz@true.cz>
According to the vendor [1] these HATs share the same DT overlay:
hifiberry-dacplus. The PCM512x-compatible control unit is attached to
I2C, so the additional snd-soc-pcm512x-i2c kernel module is required.
Also explicitly note the Amp2 support to reduce confusion for those
users.
[1] <https://www.hifiberry.com/docs/software/configuring-linux-3-18-x/>
Signed-off-by: Torsten Duwe <duwe@lst.de>
(added bcm27xx tag, changed commit message)
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
(cherry picked from commit 7ea9936f7f32fd90af1a29775ac3b297d7775db7)
The MikroTik RouterBOARD mAPL-2nd (sold as mAP Lite) is a small
2.4 GHz 802.11b/g/n PoE-capable AP.
See https://mikrotik.com/product/RBmAPL-2nD for more info.
Specifications:
- SoC: Qualcomm Atheros QCA9533
- RAM: 64 MB
- Storage: 16 MB NOR
- Wireless: Atheros AR9531 (SoC) 802.11b/g/n 2x2:2, 1.5 dBi antenna
- Ethernet: Atheros AR8229 (SoC), 1x 10/100 port, 802.3af/at PoE in
- 4 user-controllable LEDs:
· 1x power (green)
· 1x user (green)
· 1x lan (green)
· 1x wlan (green)
Flashing:
TFTP boot initramfs image and then perform sysupgrade. Follow common
MikroTik procedure as in https://openwrt.org/toh/mikrotik/common.
Note: following 781d4bfb397cdd12ee0151eb66c577f470e3377d
The network setup avoids using the integrated switch and connects the
single Ethernet port directly. This way, link speed (10/100 Mbps) is
properly reported by eth0.
Signed-off-by: Thibaut VARÈNE <hacks@slashdirt.org>
(cherry picked from commit eb38af788180d624e5b37aa5db1fe3766b138dc8)
Specification:
- QCA9533 (650 MHz), 64 or 128MB RAM, 16MB SPI NOR
- 2x 10/100 Mbps Ethernet, with 802.3at PoE support (WAN)
- 2T2R 802.11b/g/n 2.4GHz
Flash instructions:
If your device comes with generic QSDK based firmware, you can login
over telnet (login: root, empty password, default IP: 192.168.188.253),
issue first (important!) 'fw_setenv' command and then perform regular
upgrade, using 'sysupgrade -n -F ...' (you can use 'wget' to download
image to the device, SSH server is not available):
fw_setenv bootcmd "bootm 0x9f050000 || bootm 0x9fe80000"
sysupgrade -n -F openwrt-...-yuncore_...-squashfs-sysupgrade.bin
In case your device runs firmware with YunCore custom GUI, you can use
U-Boot recovery mode:
1. Set a static IP 192.168.0.141/24 on PC and start TFTP server with
'tftp' image renamed to 'upgrade.bin'
2. Power the device with reset button pressed and release it after 5-7
seconds, recovery mode should start downloading image from server
(unfortunately, there is no visible indication that recovery got
enabled - in case of problems check TFTP server logs)
Signed-off-by: Clemens Hopfer <openwrt@wireloss.net>
Signed-off-by: Thibaut VARÈNE <hacks@slashdirt.org>
(cherry-picked from commit a05dcb07241aa83a4416b56201e31b4af8518981)
[switch to mtd-mac-address instead of nvmem-cells]
Specification:
- QCA9563 (775MHz), 128MB RAM, 16MB SPI NOR
- 2T2R 802.11b/g/n 2.4GHz
- 2T2R 802.11n/ac 5GHz
- 2x 10/100/1000 Mbps Ethernet, with 802.3at PoE support (WAN port)
LED for 5 GHz WLAN is currently not supported as it is connected directly
to the QCA9882 radio chip.
Flash instructions:
If your device comes with generic QSDK based firmware, you can login
over telnet (login: root, empty password, default IP: 192.168.188.253),
issue first (important!) 'fw_setenv' command and then perform regular
upgrade, using 'sysupgrade -n -F ...' (you can use 'wget' to download
image to the device, SSH server is not available):
fw_setenv bootcmd "bootm 0x9f050000 || bootm 0x9fe80000"
sysupgrade -n -F openwrt-...-yuncore_...-squashfs-sysupgrade.bin
In case your device runs firmware with YunCore custom GUI, you can use
U-Boot recovery mode:
1. Set a static IP 192.168.0.141/24 on PC and start TFTP server with
'tftp' image renamed to 'upgrade.bin'
2. Power the device with reset button pressed and release it after 5-7
seconds, recovery mode should start downloading image from server
(unfortunately, there is no visible indication that recovery got
enabled - in case of problems check TFTP server logs)
Signed-off-by: Thibaut VARÈNE <hacks@slashdirt.org>
(cherry-picked from commit c91df224f54fdd44c9c0487a8c91876f5d273164)
Workaround for max 14 chars limitation.
Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
(cherry picked from commit 5e66ed82a8aa1966ca2232f087d77cdf2456ed7c)
Fixes two high-severity vulnerabilities:
- CVE-2022-25640: A TLS v1.3 server who requires mutual authentication
can be bypassed. If a malicious client does not send the
certificate_verify message a client can connect without presenting a
certificate even if the server requires one.
- CVE-2022-25638: A TLS v1.3 client attempting to authenticate a TLS
v1.3 server can have its certificate heck bypassed. If the sig_algo in
the certificate_verify message is different than the certificate
message checking may be bypassed.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
(cherry picked from commit e89f3e85eb1c1d81294e5d430a91b0ba625e2ec0)
This updates mac80211 to version 5.10.110-1 which is based on kernel
5.10.110.
The removed patches were applied upstream.
This new release contains many fixes which were merged into the upstream
Linux kernel.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Rename feature variable clang-bpf-global-var following upstream changes.
This restores the HAVE_CLANG feature override and should avoid rare build
errors where a recent host clang and BTF-enabled host kernel are present.
Fixes: 23be333401f0 ("bpftools: update to 5.10.10")
Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
(cherry picked from commit cf20f1bb5f0479c2509dd651d08e235a3b9e8755)
These patches can be used on other platforms, so
move it to generic.
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
(cherry picked from commit cc2a8c25459f437e82b58b1bb94afd811cbb131f)
The following devices have a Winbond W25Q256FV flash chip,
which does not have the RESET pin enabled by default,
and otherwise would require setting a bit in a status register.
Before moving to Linux 5.4, we had the patch:
0053-mtd-spi-nor-add-w25q256-3b-mode-switch.patch
which kept specific flash chips with explicit 3-byte and 4-byte address modes
to stay in 3-byte address mode while idle (after an erase or write)
by using a custom flag SPI_NOR_4B_READ_OP that was part of the patch.
this was obsoleted by the patch:
481-mtd-spi-nor-rework-broken-flash-reset-support.patch
which uses the newer upstream flag SNOR_F_BROKEN_RESET
for devices with a flash chip that cannot be hardware reset with RESET pin
and therefore must be left in 3-byte address mode when idle.
The new patch requires that the DTS of affected devices
have the property "broken-flash-reset", which was not yet added for most of them.
This commit adds the property for remaining affected devices in ramips target,
specifically because of the flash chip model.
However, it is possible that there are other devices
where the flash chip uses an explicit 4-byte address mode
and the RESET pin is not connected to the SOC on the board,
and those DTS would also need this property.
Ref: 22d982ea0033 ("ramips: add support for switching between 3-byte and 4-byte addressing")
Ref: dfa521f12953 ("generic: spi-nor: rework broken-flash-reset")
Signed-off-by: Michael Pratt <mcpratt@pm.me>
[pepe2k@gmail.com: backported to 21.02]
Fixes: #9655, #9636, #9547
Signed-off-by: Piotr Dymacz <pepe2k@gmail.com>
(backported from commit 74516f4357d281f093f0daac01c4c5c239acc443)
When using external targets there is a symlink being created for the
target under target/linux which then becomes dangling under Image
Builder. Fix it by dereferencing the possible symlink.
Tested on IB with external target, ipq40xx and mvebu.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
(cherry picked from commit 621f39d1f438bf95dbae667c575926fa16a6d797)
(cherry picked from commit ec9af870f3278f75549836b469baefa260e2ed41)
When upgrading a TP-Link Archer C5 v1 from ar71xx to ath79,
the 5ghz radio stops working because the device path changed.
Same has been done for the Archer C7 before:
commit e19506f20618 ("ath79: migrate Archer C7 5GHz radio device paths")
Signed-off-by: Jan-Niklas Burfeind <git@aiyionpri.me>
(cherry picked from commit c6eb63d48f942f1e54737ed182776cf9a08de542)
The label has the MAC address of eth0, not the WLAN PHY address. We can
merge the definition back into ar7241_ubnt_unifi.dtsi, as both DTS
derived from it use the same interface for their label MAC addresses
after all.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
(cherry picked from commit aee9ccf5c1b536189ebee8c232273657334da843)
This backports the following upstream Linux patches
net: sfp: add mode quirk for GPON module Ubiquiti U-Fiber Instant
net: sfp: relax bitrate-derived mode check
net: sfp: cope with SFPs that set both LOS normal and LOS inverted
for 5.4 for mvebu platform.
This fixes GPON modules:
Ubiquiti U-Fiber Instant SFP GPON
VSOL V2801F
CarlitoxxPro CPGOS03-0490 v2.0
Signed-off-by: Marek Behún <marek.behun@nic.cz>
1. Drop package: cypress-firmware-4359-pcie
This binary is no longer provided and there are not many details what
happened.
2. Drop package: cypress-firmware-4359-sdio
This binary is no longer provided, but in this case, to compare it with
PCIe package mention as first, there was added
support in Linux-firmware [1], but no sign of firmware file.
4. Drop package: cypress-firmware-89459-pcie [2]
According to Infineon: "CYW89459 is an automotive Wi-Fi chip which is not
supported in the broad market community."
[1] https://patchwork.kernel.org/project/linux-wireless/patch/20191211235253.2539-6-smoch@web.de/
[2] https://community.infineon.com/t5/Wi-Fi-Bluetooth-for-Linux/the-wifi-driver-for-CYW89459-in-linux4-14-98-2-3-00/m-p/138971
Fixes: 7ca7e0b22de6e629f5df12b8a935a168073bcca3 ("cypress-firmware:
update it to version 5.4.18-2021_0812")
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
(cherry picked from commit 8c66bf89d1e8e67d8a3537e164bb7d9669259c08)
- Binary files were renamed to cyfmac from brcmfmac, but the files needs
to be on the router with the previous naming
[ 6.656165] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[ 6.665182] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43455-sdio.bin failed with error -2
[ 6.674928] brcmfmac mmc1:0001:1: Falling back to sysfs fallback for: brcm/brcmfmac43455-sdio.bin
- Cypress were acquired by Infineon Technologies
Thus change the project URL and switch to download files from their
GitHub repository. This is much better than the previous solution, which
requires finding new threads on their community forum about new driver
updates, and it will be necessary to change the URL each time.
Unfortunately, it seems that there is not published changelog, but
according to this forum thread [1], be careful by opening the link from
solution since it contains ending bracket ), it brings fixes for various
security vulnerabilities, which were fixed in 7_45_234.
Fixes:
- FragAttacks
- Kr00k
Also add LICENSE file
Run tested on Seeedstudio router powered by Raspberry Pi 4 CM with
package cypress-firmware-43455-sdio.
Before:
root@OpenWrt:~# dmesg | grep 'Firmware: BCM4345/6'
[ 6.895050] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Mar 23 2020 02:20:01 version 7.45.206 (r725000 CY) FWID 01-febaba43
After:
root@OpenWrt:~# dmesg | grep 'Firmware: BCM4345/6'
[ 6.829805] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Apr 15 2021 03:03:20 version 7.45.234 (4ca95bb CY) FWID 01-996384e2
[1] https://community.infineon.com/t5/Wi-Fi-Bluetooth-for-Linux/Outdated-brcmfmac-firmware-for-Raspberry-Pi-4-in-OpenWrt-21-02-1/m-p/331593#M2269
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
(cherry picked from commit 7ca7e0b22de6e629f5df12b8a935a168073bcca3)
The OCEDO Raccoon had significant packet-loss with cables longer than 50
meter. Disabling EEE restores normal operation.
Also change the ethernet config to reduce loss on sub-1G links.
Signed-off-by: David Bauer <mail@david-bauer.net>
(cherry picked from commit 4551bfd91f31be5987727c77e58333fa06ba3acd)
Required to allow sysupgrades from OpenWrt 19.07.
Closes#7071
Fixes: 98fbf2edc021 ("ath79: move TPLINK_HWID/_HWREV to parent for tplink-safeloader")
Tested-by: J. Burfeind <git@aiyionpri.me>
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
(cherry picked from commit 8ba71f1f6f2359f9cf54201e9fc037df33f123c0)
Tavis has just reported, that he was recently trying to track down a
reproducible crash in a compressor. Believe it or not, it really was a
bug in zlib-1.2.11 when compressing (not decompressing!) certain inputs.
Tavis has reported it upstream, but it turns out the issue has been
public since 2018, but the patch never made it into a release. As far as
he knows, nobody ever assigned it a CVE.
Suggested-by: Tavis Ormandy <taviso@gmail.com>
References: https://www.openwall.com/lists/oss-security/2022/03/24/1
Signed-off-by: Petr Štetiar <ynezz@true.cz>
(cherry picked from commit b3aa2909a79aeff20d594160b207a89dc807c033)
(cherry picked from commit 3965dda0fa70dc9408f1a2e55a3ddefde78bd50e)
a20-olinuxino-lime2 is currently having hard time with link detection of
certain 1000Mbit partners due to usage of generic PHY driver, probably
due to following missing workaround introduced in upstream in commit
3aed3e2a143c ("net: phy: micrel: add Asym Pause workaround"):
The Micrel KSZ9031 PHY may fail to establish a link when the Asymmetric
Pause capability is set. This issue is described in a Silicon Errata
(DS80000691D or DS80000692D), which advises to always disable the
capability. This patch implements the workaround by defining a KSZ9031
specific get_feature callback to force the Asymmetric Pause capability
bit to be cleared.
This fixes issues where the link would not come up at boot time, or when
the Asym Pause bit was set later on.
As a20-olinuxino-lime2 has Micrel KSZ9031RNXCC-TR Gigabit PHY since
revision H, so we need to use Micrel PHY driver on those devices.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
(cherry picked from commit ffa1088f63267f817a3adf34c84b8e8089b1a938)
uDPU has 2 LM75 compatible temperature sensors, so include the driver for
them by default in order to utilize them.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Signed-off-by: Petr Štetiar <ynezz@true.cz> [rebase]
(cherry picked from commit a8b2d3590329386d0ae6873460b2d5126f63ddaa)
(cherry picked from commit b9e90935db8e0c0166c80fc6e5e50755282e9e0b)
uDPU provides a FIT based initramfs, but currently gets stuck after U-boot
starts the kernel at "Starting kernel..".
It is due to the load address being too low, so increase it in order to get
the initramfs booting again.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
(cherry picked from commit 80f21e53360d52d493c51a4a263d9b7607b7494e)
(cherry picked from commit d65269a732d82ca9d084c89d6ca05d125d4ab629)