This reverts commit b4aad29a1d.
This was accidentally folded into a single commit. Remove it and
apply it properly again.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Partially restore the wild-card matching for kmod-usb3 modules to fix
build on platforms without PCI which otherwise file, as seen on
buildbot:
ERROR: module '[...]/linux-5.4.102/drivers/usb/host/xhci-pci.ko' is missing.
modules/usb.mk:1675: recipe for target '[...]/kmod-usb3_5.4.102-1_mips_mips32.ipk' failed
Fixes: 7bda2e9aba ("kernel: fix kmod-usb3 dependencies")
Fixes: be23f9818a ("apm821xx: add support for kernel 5.10")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
It appears to be an automatic Kconfig symbol that varies depending on
the host platform. There is no need to define it in target configs, so
filter it out.
Also sort config-filter entries alphabetically.
Cc: Adrian Schmutzler <mail@adrianschmutzler.de>
Cc: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
Remove unneeded delcarations form package Makefile now that everything
comes from github.com/mtk-openwrt upstream.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Adding CONFIG_USB_XHCI_PCI_RENESAS to KCONFIG made it so it was set
for all targets that included kmod-usb3, not just the intended
apm821xx/nand. xhci-pci has a dependency on xhci-pci-renesas if
CONFIG_USB_XHCI_PCI_RENESAS is set, breaking kmod-usb3 builds on
Linux 5.10 on all other targets.
Rework the dependencies by breaking out xhci-hcd, xhci-mtk, and
xhci-pci-renesas into new hidden kernel modules and setting kmod-usb3
dependencies properly.
Tested by building mt7621 and apm821xx/nand with kmod-usb3 on Linux 5.10
Fixes: be23f981 ("apm821xx: add support for kernel 5.10")
Cc: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
DDR3_FLYBY has accidentally been set also for the 1-chip variant which
lead to broken, unbootable images. Fix that.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Enable testing kernel.
Delete upstreamed patches:
0098-disable_cm.patch can be dropped, upstream fixed CM handling.
Fix compile errors by using new kernel APIs.
Fix fuzz by manually editing patches to ensure the code goes in the
right place.
For 721-NET-no-auto-carrier-off-support.patch, revert upstream commit
a307593a6 to keep the OpenWrt ralink driver operational.
Add mt7621-pci-phy patch to select REGMAP_MMIO as discussed in PR #3693
and #3952.
Rename patches to follow the 3-digit classification from the OpenWrt
Developer Guide.
Run automatic quilt refresh.
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
This patch copies over refreshed patches from 5.4.
- dropped crypto patches (they got upstreamed)
- dropped renesas USB 3 firmware loader (they got upstreamed)
- NAND now needs extra device-properties for ECC settings.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
* allow MAC address from U-Boot env to be inhertied
* allow eMMC installation to succeed also without recovery present
on the SD Card.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Also add a new kconfig symbol (CONFIG_KCMP) to the generic config,
disabling the SYS_kcmp syscall (it was split from
CONFIG_CHECKPOINT_RESTORE, which is disabled by default, so the
previous behaviour is kept).
Removed (upstreamed) patches:
070-net-icmp-pass-zeroed-opts-from-icmp-v6-_ndo_send-bef.patch
081-wireguard-device-do-not-generate-ICMP-for-non-IP-pac.patch
082-wireguard-queueing-get-rid-of-per-peer-ring-buffers.patch
083-wireguard-kconfig-use-arm-chacha-even-with-no-neon.patch
830-v5.12-0002-usb-serial-option-update-interface-mapping-for-ZTE-P685M.patch
Manually rebased patches:
313-helios4-dts-status-led-alias.patch
104-powerpc-mpc85xx-change-P2020RDB-dts-file-for-OpenWRT.patch
Run tested:
ath79 (TL-WDR3600)
mvebu (Turris Omnia)
Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
All necessary blobs are now contained in the upstream repository, no
more wild replacing of blobs needed.
This new version also contains new storage drivers for (SPI-)NAND which
already comes with support for FM35Q1GA, so that patch can be dropped
as well.
Tested on:
* Bananapi BPi-R64
- sdmmc-2ddr
- emmc-2ddr
* Linksys E8450
- snand-1ddr
All works fine (booting Bananapi BPi-R64 from SD Card does NOT require
a signed image, so patch arm-trusted-firmware-mediatek to allow doing
that).
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
U-boot will reject all nodes with @ since commit:
79af75f777
This will cause the OpenWrt images to fail booting,
to rectify use the config-1 as default.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
U-boot will reject the nodes with @ for the address since
commit:
79af75f777
This in turn will cause the failure to boot with OpenWrt
generated images.
So, to rectify that simply replace @ with -.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
(cover also newly added rootfs@1 and initrd@1 nodes)
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
It's a BCM4906 based device (2 CPU cores). It has 512 MiB of RAM, 4 LAN
ports, 1 WAN port, 2 USB ports, NAND flash. WiFi unknown at this point.
Flashing is possible using CFE only, proper image will be worked on
later.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
From the original commit message:
"With GCC 10, building usbip triggers error for multiple definition
of 'udev_context', in:
- libsrc/vhci_driver.c:18 and
- libsrc/usbip_host_common.c:27.
Declare as extern the definition in libsrc/usbip_host_common.c."
Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
REFCOUNT_FULL was removed for linux 5.5:
commit fb041bb7c0a9 (locking/refcount: Consolidate implementations of refcount_t)
COMMON_CLK_VERSATILE was removed on linux 5.8:
commit 5f55f1fb187d (clk: versatile: Fix kconfig dependency on COMMON_CLK_VERSATILE)
Signed-off-by: Luis Araneda <luaraneda@gmail.com>
Patch to fix kernel panic was recently accepted upstream so rename patch
and add acked lines to reflect that.
Signed-off-by: Sieng Piaw Liew <liew.s.piaw@gmail.com>
(add the same patch for v5.10)
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
The BCM5365 UID was updated in the driver, but we should also update it in the
fixup.
Fixes: cbcac4fde8 ("kernel: b53: update the BCM5365 UID")
Signed-off-by: Daniel González Cabanelas <dgcbueu@gmail.com>
(Ammend commit description, add Fixes tag)
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
This will use the new application led trigger backend. For now this is
the only package that uses leds trigger in user space to configure the
kernel led triggers.
The callback script only emmits a message for now, so that this LED is now
managed by the rssileds service. Until now a generic warning was emitted that
this LED trigger is not supported. But that is not true.
-> Skipping trigger 'rssileds' for led '<name>' due to missing kernel module
I think this callback should be changed in the future to restart the
service.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
For now we have only kernel LED trigger support. With this change it is now
possible to use application triggers.
If we configure a LED with a non kernel trigger, then we check on every
restart and boot of the LED service if we have this trigger as an application
in "/usr/libexec/led-trigger". If this file with the name is found, then we
execute this to init the LED.
Possible use cases are:
- Start/Stop/Restart an application led trigger service for this led
- Init a LED that is configured by a hotplug script (VPN tunnel established)
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
stropts.h is unavailable under glibc (and unneeded when building
against glibc). Include it only if not building against glibc.
Reported-by: @DazzyWalkman
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
While rebasing into setting bits instead of magic values,
I accidentally forgot to actually set the force bit.
Without it using the pins as GPIO-s did not actually work.
Fixes: b5c93ed ("ipq40xx: add Qualcomm QCA807x driver")
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Debugging the SPI CS issue with kernel 5.10 resulted in a better
understanding for the root cause and a proper patch with a better
explanation.
Exchange the old hack patch with a more efficient (and upstreamable)
solution.
Signed-off-by: David Bauer <mail@david-bauer.net>
Don't try to install files which no longer exist
Since {e,sd}mmc are now produced by ptgen they have been removed.
Fixes: 5a3562cd1d ("arm-trusted-firmware-mediatek: remove {e,sd}mmc headers")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
5.4.102 backported a lot of stuff that our WireGuard backport already
did, in addition to other patches we had, so those patches were
removed from that part of the series. In the process other patches were
refreshed or reworked to account for upstream changes.
This commit involved `update_kernel.sh -v -u 5.4`.
Cc: John Audia <graysky@archlinux.us>
Cc: David Bauer <mail@david-bauer.net>
Cc: Petr Štetiar <ynezz@true.cz>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
All mt7622 devices except for the UBI-variant of the mt7622-rfb1 carry
metadata appended to the sysupgrade image.
Add it for the mt7622-rfb1-ubi as well and check it on sysupgrade to
avoid accidentally flashing firmware for the wrong device (or variant
or future DEVICE_COMPAT_VERSION).
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The freifunk feed is being removed becasue
a) it is an external project and the OpenWrt team does not have access to it.
b) upon original addition of the feed, there was only a very weak tendency for
the addition.
c) there is a general lack of interest in the freifunk repo to review and/or
merge pull requests.
d) as far as can be found, all projects which use the freifunk feed have their
own make system and self-maintained feeds list. They do not use the
feeds.conf.default from the openwrt repo.
more information can be read at the following links:
http://lists.openwrt.org/pipermail/openwrt-devel/2021-February/033807.htmlhttps://github.com/freifunk/openwrt-packages/issues/37
Signed-off-by: Perry Melange <isprotejesvalkata@gmail.com>
`which` utility is not shipped by default for example on recent Arch
Linux and then any steps relying on its presence fails, like for example
following Python3 prereq build check:
$ python3 --version
Python 3.9.1
$ make
/bin/sh: line 1: which: command not found
...
Checking 'python3'... failed.
So make `which` utility host build requirement.
References: PR#3820 FS#3525
Signed-off-by: Petr Štetiar <ynezz@true.cz>
This reverts commit c7aec47e5e.
The original commit replaces 'which' with 'command'. Sadly most of
them are not equivalent and for 'which -a', there is no easy
replacements that would not reimplement PATH parsing logic. Hence
revert. Keeping a dependency on which is absolutely fine.
Signed-off-by: Clemens Fruhwirth <clemens@endorphin.org>
Currently minimal GNU supported GCC version is 7 (from May 2, 2017),
buildbots are using default GCC version 6 on Debian 9 (old stable),
current Debian stable has GCC version 8.3.0.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Compile testing i.mx6 with ALL_KMODS=y, PACKAGE_perf=y and bunch of
tracing/probing symbols has unveiled bunch of missing config options so
add them.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Just by running `make kernel_oldconfig` and unsetting following options
manually as those cores are cortex-a7 based and thus irrelevant for the
currently default cortex-a9 used cores.
CONFIG_CLK_IMX6SL is not set
CONFIG_CLK_IMX6SX is not set
CONFIG_CLK_IMX6UL is not set
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Turned out those are simply MBR with active boot partition. And not
needed at all on emmc. Remove them as ptgen can now generate hybrid
MBR sufficient to boot MT7622 from SD Card.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
mt7622 uses MBR partition for booting from SD card.
Add hybrid MBR entry with boot flag after PMBR entry.
Signed-off-by: Oskari Lemmela <oskari@lemmela.net>
Do not align partitions with sectors. Only kb align
for GPT is supported.
Use 254 heads and 63 sectors for PMBR.
Signed-off-by: Oskari Lemmela <oskari@lemmela.net>
