Mathias Kresin [Sun, 15 Mar 2020 20:26:23 +0000 (21:26 +0100)]
lantiq: move mux for pins into subnodes
The mux need to be defined in a subnode to be considered by the pinctrl
framework. These muxes aren't set as expected and might cause not
working subsystems.
Fixes: 8e7b573b7aa4 ("lantiq: dts: assign the PCI pins to the PCI controller node") Fixes: dcb5e52209e5 ("lantiq: dts: assign the STP pins to the STP GPIO controller node") Fixes: 660200e53d62 ("lantiq: dts: assign the GPHY LED pins to the Ethernet controller node") Signed-off-by: Mathias Kresin <dev@kresin.me>
The libcap isn't as optional as the commit messages suggests. A hard
dependency to the libcap package is added, which is only available in
the external packages feed. Therefore it is impossible to package
ip-full without having the external packages feed up and running, which
is a regression to the former behaviour.
Signed-off-by: Mathias Kresin <dev@kresin.me> Acked-by: Hans Dedecker <dedeckeh@gmail.com>
Jo-Philipp Wich [Fri, 13 Mar 2020 14:54:50 +0000 (15:54 +0100)]
pkgconf: always retain -I and -L flags
The pkgconf fork filters -I and -L flag values from .pc files which match
pkgconf's builtin system directory value.
During configure, pkgconf derives the default system include and library
search path values from exec_prefix, which is set to staging_dir/host in
the host tool build phase.
Due to that, pkgconf will drop all -I and -L flags pointing to
staging_dir/host/include or staging_dir/host/lib, unless invoked with
--keep-system-cflags and --keep-system-libs respectively, breaking our
kernel libelf discovery / stack validation workarounds.
In order to inhibit the filtering, add --keep-system-cflags and
--keep-system-libs to our pkg-config shell wrapper.
Fixes: GH#2832 Fixes: 867298cf47 ("tools/pkg-config: Replace with pkgconf")
Ref: https://lists.infradead.org/pipermail/openwrt-devel/2020-March/022182.html
Ref: https://git.openwrt.org/fe43969336201f2cc7d103b68fd6e65989bee184 Signed-off-by: Jo-Philipp Wich <jo@mein.io> Acked-by: Petr Štetiar <ynezz@true.cz>
Hans Dedecker [Sun, 15 Mar 2020 19:06:12 +0000 (20:06 +0100)]
odhcpd: update to latest git HEAD
6594c6b ubus: use dhcpv6 ia assignment flag a90cc2e dhcpv6-ia: avoid setting lifetime to infinite for static assignments bb07fa4 dhcpv4: avoid setting lifetime to infinite for static assignments
Bump to iptable 1.8.4 and address packaging issue as mentioned in the
original bump/revert cycle.
"This reverts commit 10cbc896c0a26aecff37261450c21f29fb5b99db.
The updated iptables package does not build due to the following error
encountered on the buildbots:
cp: cannot stat '.../iptables-1.8.4/ipkg-install/usr/lib/libiptc.so.*': No such file or directory
The changelog mentions "build: remove -Wl,--no-as-needed and libiptc.so" so
it appears as if further packaging changes are needed beyond a simple
version bump."
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Robert Marko [Sun, 15 Mar 2020 12:36:40 +0000 (13:36 +0100)]
ipq40xx: 5.4: enable NAND
Lets enable RAW NAND and Qcom NANDC drivers again in kernel 5.4.
They were dropped when 5.4 support was introduced due to upstream
changing the symbol names so refreshing was not enough.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
[cut long line in commit message, enabled BCH as well] Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Sungbo Eo [Wed, 11 Mar 2020 17:50:35 +0000 (02:50 +0900)]
mvebu: use generic diag.sh
This commit removes the target-specific diag.sh script. This way, the
generic one is used for the target, which uses DT-aliases to specify the
LEDs used.
Signed-off-by: Sungbo Eo <mans0n@gorani.run> Tested-by: Ansuel Smith <ansuelsmth@gmail.com> [wrt3200acm @ 5.4]
David Bauer [Sat, 14 Mar 2020 23:01:38 +0000 (00:01 +0100)]
ath79: add correct phy-mode for QCA9563 boards
The TP-Link RE450 as well as the UniFi AC series missed the phy-mode
property. Because of this, the incorrect MII phy-mode from the root dtsi
was used.
With Kernel 5.4, this leads to problems when used with a AR8033 PHY. The
bootloader seems to leave the fiber pages selected.
As there's not switch to copper pages happening in at803x_config_init
due to the incorrect phy-mode, the new at803x_read_status will interpret
the status of the SGMII side as the status of the copper side.
This patch removes the 4.14 kernel support from the apm821xx target.
The 4.19 kernel has been available and stable for a while and the 5.4
kernel support has been tested successfully on real hardware as well.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
As part of the kernel build process there are utilities built to run on
the host system that expect linux kernel headers to be available.
Unfortunately macos/darwin doesn't have these headers.
vdso2c requires types.h so provide a minimal stub to satisfy it.
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
David Bauer [Fri, 13 Mar 2020 00:07:39 +0000 (01:07 +0100)]
ath79: use downstream ag71xx for Kernel 5.4
The ag71xx driver from Linux 5.4 currently has various shortcomings
when used with OpenWrt compared to our downstream version.
For example, the upstream driver does not support modifying the ethernet
clock and configuring RGMII delays on the MAC side.
While we should certainly switch to the upstream driver, the amount of
necessary patches would make it cumbersome to work with. It's also
highly likely we won't be able to finish patching the upstream driver in
time for a Linux 5.4 release.
Sungbo Eo [Thu, 5 Mar 2020 14:42:18 +0000 (23:42 +0900)]
kernel: make kmod-i2c-core selected by dependent modules
Currently kmod-i2c-* will not get into images unless kmod-i2c-core is added to
DEVICE_PACKAGES as well. By changing the dependencies from "depends on" to
"select", we do not have the issue anymore.
Furthermore, we can remove most occurrences of the package from DEVICE_PACKAGES
and similar variables, as it is now pulled by dependent modules such as:
- kmod-hwmon-lm75
- kmod-i2c-gpio
- kmod-i2c-gpio-custom
- kmod-i2c-mux
- kmod-i2c-ralink
Signed-off-by: Sungbo Eo <mans0n@gorani.run>
[do not touch ar71xx] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Sungbo Eo [Thu, 5 Mar 2020 14:22:47 +0000 (23:22 +0900)]
kernel: make kmod-hwmon-core selected by dependent modules
Currently kmod-hwmon-* will not get into images unless kmod-hwmon-core is added
to DEVICE_PACKAGES as well. By changing the dependencies from "depends on" to
"select", we do not have the issue anymore.
Furthermore, we can remove most occurrences of the package from DEVICE_PACKAGES
and similar variables, as it is now pulled by dependent modules such as:
- kmod-hwmon-gpiofan
- kmod-hwmon-lm63
- kmod-hwmon-lm75
- kmod-hwmon-lm85
- kmod-hwmon-lm90
Signed-off-by: Sungbo Eo <mans0n@gorani.run>
[do not touch ar71xx, adjust line wrapping] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Installation via web interface:
1. Flash **initramfs** image through the stock web interface.
2. Boot into OpenWrt and perform sysupgrade with sysupgrade image.
Revert to stock firmware:
1. Perform sysupgrade with stock image.
Tested on device by JasonHCH <hsuan670629@gmail.com>
By default on module load, 2 ifb interfaces are created and typically
remain unused, cluttering 'ip link' outputs and generally confusing
things. sqm-scripts for example, creates its own ifb interface/s
instead of using these 2 defaults ifbs.
Tell the ifb module to not create any default ifbs on load via the
numifbs parameter.
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Tim Harvey [Wed, 11 Mar 2020 15:02:58 +0000 (08:02 -0700)]
imx6: add support for GW5907/GW5910/GW5912/GW5913
This patch adds support for GW5907/GW5910/GW5912/GW5913 IMX6 based boards
from the Gateworks Ventana Family[A]:
- backport upstream dt patches from 5.6 to 4.19 and 5.4
- add dtb's to ventana images
- add board-name and network config
A. https://www.gateworks.com/products/imx6-single-board-computer-gateworks-ventana-family
Flashing instructions for Ventana boards:
Using pre-flashed bootloader:
- Use appropriate ubi image depending on board NAND to flash via bootloader:
openwrt-imx6-ventana-squashfs-nand.ubi - 2KiB page size
openwrt-imx6-ventana-large-squashfs-nand.ubi - 4KiB page size
http://trac.gateworks.com/wiki/linux/ubi
Using Gateworks JTAG dongle:
- Use Gateworks mkimage_jtag script to create a JTAG image comprised of
pre-built bootloader and ubi image:
http://trac.gateworks.com/wiki/jtag_instructions
Instead of dangerous rewriting full chip with firmware.bin image to
update OpenWrt, add sysupgrade image. This image will be used to update
kernel and rootfs, leaving bootloader intact and making recovery
possible, without resorting to external hardware tools.
Signed-off-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
Combine fixed sizes of "kernel" and "rootfs" partitions into one
partition managed by OpenWrt splitter, it will allow better management
of chip capacity and less maintenance burden when compiled kernel image
will outgrow allocated size for kernel partition. This also changes kernel
image format, since splitter only manages kernel and rootfs partitions,
the dtb needs to be updated with the kernel, so for convenience, kernel is
packed to FIT image.
Signed-off-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
Specification
SoC: LS1012A single core 800MHz
RAM: 512 MB DDR3
Flash: 64 MB QSPI NOR
Ethernet: 2x 10/100/1000 Mbps
Connectors: µUSB 3.0 OTG
µUSB 2.0 (debugging & power input)
2x 3.5mm jack for microphone & headphone (SGTL5000)
Arduino Shield expansion with I2C, SPI, UART, and GPIO
JTAG
LEDS: 3x (non-configurable)
Buttons: 1x (reset, non-configurable)
Be advised that erasing or writing 64MB flash takes some time to finish.
Do not reset the board until all operations end with success, otherwise
You'll need external tools to re-program the flash chip.
Installation
Follow the QSPI programing procedure for LS1012AFRWY board in
target/linux/layerscape/README, point 3.3.
Don't forget about updating U-Boot environment with MAC addresses of
ethernet interfaces, variable 'ethaddr' for eth0 and 'eth1addr' for eth1.
As the LSDK images do not support sysupgrade, nor do changes in this
commit, it's planed in upcoming submissions.
Signed-off-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
Hauke Mehrtens [Sat, 29 Feb 2020 15:31:26 +0000 (16:31 +0100)]
x86: Remove kernel 4.14 support
This target was switched to kernel 4.19 more than 6 months ago in commit f342ffd300da ("treewide: kernel: bump some targets to 4.19") and now
with kernel 5.4 support being added it gets harder to support kernel
4.14 in addition to kernel 4.19 and 5.4.
Hauke Mehrtens [Sat, 29 Feb 2020 15:52:57 +0000 (16:52 +0100)]
tegra: Remove kernel 4.14 support
This target was switched to kernel 4.19 more than 6 months ago in commit f342ffd300da ("treewide: kernel: bump some targets to 4.19") and now
with kernel 5.4 support being added it gets harder to support kernel
4.14 in addition to kernel 4.19 and 5.4.
Hauke Mehrtens [Sat, 29 Feb 2020 15:38:58 +0000 (16:38 +0100)]
sunxi: Remove kernel 4.14 support
This target was switched to kernel 4.19 more than 6 months ago in commit f342ffd300da ("treewide: kernel: bump some targets to 4.19") and now
with kernel 5.4 support being added it gets harder to support kernel
4.14 in addition to kernel 4.19 and 5.4.
Hauke Mehrtens [Sat, 29 Feb 2020 15:52:36 +0000 (16:52 +0100)]
octeon: Remove kernel 4.14 support
This target was switched to kernel 4.19 more than 6 months ago in commit f342ffd300da ("treewide: kernel: bump some targets to 4.19") and now
with kernel 5.4 support being added it gets harder to support kernel
4.14 in addition to kernel 4.19 and 5.4.
Hauke Mehrtens [Sat, 29 Feb 2020 15:52:03 +0000 (16:52 +0100)]
mvebu: Remove kernel 4.14 support
This target was switched to kernel 4.19 more than 6 months ago in commit f342ffd300da ("treewide: kernel: bump some targets to 4.19") and now
with kernel 5.4 support being added it gets harder to support kernel
4.14 in addition to kernel 4.19 and 5.4.
Hauke Mehrtens [Sat, 29 Feb 2020 15:50:56 +0000 (16:50 +0100)]
mpc85xx: Remove kernel 4.14 support
This target was switched to kernel 4.19 more than 6 months ago in commit f342ffd300da ("treewide: kernel: bump some targets to 4.19") and now
with kernel 5.4 support being added it gets harder to support kernel
4.14 in addition to kernel 4.19 and 5.4.
Hauke Mehrtens [Sat, 29 Feb 2020 15:50:26 +0000 (16:50 +0100)]
malta: Remove kernel 4.14 support
This target was switched to kernel 4.19 more than 6 months ago in commit f342ffd300da ("treewide: kernel: bump some targets to 4.19") and now
with kernel 5.4 support being added it gets harder to support kernel
4.14 in addition to kernel 4.19 and 5.4.
Hauke Mehrtens [Sat, 29 Feb 2020 15:36:21 +0000 (16:36 +0100)]
ipq40xx: Remove kernel 4.14 support
This target was switched to kernel 4.19 more than 6 months ago in commit f342ffd300da ("treewide: kernel: bump some targets to 4.19") and now
with kernel 5.4 support being added it gets harder to support kernel
4.14 in addition to kernel 4.19 and 5.4.
Hauke Mehrtens [Sat, 29 Feb 2020 15:49:58 +0000 (16:49 +0100)]
imx6: Remove kernel 4.14 support
This target was switched to kernel 4.19 more than 6 months ago in commit f342ffd300da ("treewide: kernel: bump some targets to 4.19") and now
with kernel 5.4 support being added it gets harder to support kernel
4.14 in addition to kernel 4.19 and 5.4.
Hauke Mehrtens [Sat, 29 Feb 2020 15:49:09 +0000 (16:49 +0100)]
gemini: Remove kernel 4.14 support
This target was switched to kernel 4.19 more than 6 months ago in commit f342ffd300da ("treewide: kernel: bump some targets to 4.19") and now
with kernel 5.4 support being added it gets harder to support kernel
4.14 in addition to kernel 4.19 and 5.4.
Hauke Mehrtens [Sat, 29 Feb 2020 15:34:31 +0000 (16:34 +0100)]
ath79: Remove kernel 4.14 support
This target was switched to kernel 4.19 more than 6 months ago in commit f342ffd300da ("treewide: kernel: bump some targets to 4.19") and now
with kernel 5.4 support being added it gets harder to support kernel
4.14 in addition to kernel 4.19 and 5.4.
Hauke Mehrtens [Sat, 29 Feb 2020 15:48:33 +0000 (16:48 +0100)]
armvirt: Remove kernel 4.14 support
This target was switched to kernel 4.19 more than 6 months ago in commit f342ffd300da ("treewide: kernel: bump some targets to 4.19") and now
with kernel 5.4 support being added it gets harder to support kernel
4.14 in addition to kernel 4.19 and 5.4.
Sungbo Eo [Thu, 5 Mar 2020 13:57:29 +0000 (22:57 +0900)]
kernel: make kmod-ata-core selected by dependent modules
Currently kmod-ata-* will not get into images unless kmod-ata-core is added to
DEVICE_PACKAGES as well. By changing the dependencies from "depends on" to
"select", we do not have the issue anymore.
Furthermore, we can remove most occurrences of the package from DEVICE_PACKAGES
and similar variables, as it is now pulled by dependent modules such as:
- kmod-ata-ahci
- kmod-ata-ahci-mtk
- kmod-ata-sunxi
While at it, use AddDepends/ata for kmod-ata-pdc202xx-old.
Sungbo Eo [Mon, 9 Mar 2020 12:14:06 +0000 (21:14 +0900)]
build: image: move IMAGE_SIZE to image.mk
IMAGE_SIZE is widely used in many targets. Declare it in the default template to
clean up redundant code. This also prevents deriving IMAGE_SIZE unintentionally
from the previously defined device.
While at it, remove duplicate KERNEL_SIZE declaration.
ar71xx: remove wrong MAC address adjustment for Archer C60 v2
The adjustment of the MAC address for Archer C60 v2 in 10_fix_wifi_mac
is broken since a "mac" partition is not set up for this device on
ar71xx. Instead, the MAC address is already patched correctly in
11-ath10k-caldata.
Remove the useless adjustment.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
ar71xx/ath79: ew-dorin, fix the trigger level for WPS button
Because the WPS button had the wrong trigger level,
the failsafe mode was triggered quite often,
after this commit:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=27f3f493de
These instructions were written for firmware version v3.9.27.
Downgrade if necessary.
1. Copy the OpenWrt sysupgrade image to the devices /tmp folder
via scp. On factory defaults, user and password is "ubnt" at
192.168.1.20/24.
2. Write the bootselect flag. Otherwise, the device might boot from the
wrong partition. Verify the mtd partition used in the command below
is the one labled "bs" in /proc/mtd (as this might change in the
future).
> dd if=/dev/zero bs=1 count=1 of=/dev/mtd4
3. Write the OpenWrt sysupgrade to the mtd partitions labled
"kernel0" and "kernel1".
build: clean menuconfig utility as part of dirclean
When sharing a common build directory between different build platforms
eg. macos v docker based linux v virtual machine, a 'make dirclean'
isn't quite enough to clean all the platform related binaries. The
'conf' and 'mconf' aka 'make menuconfig/defconfig & friends' utilities
remain.
Clean those as part of 'dirclean' so they get rebuilt for the current
platform on the next 'make'
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Rafał Miłecki [Tue, 10 Mar 2020 14:46:49 +0000 (15:46 +0100)]
bcm47xx: add support for kernel 5.4
Ethernet, switch, LEDs, buttons, USB, sysupgrade & LuCI were
successfully tested on BCM4706.
WARNING: Hack for BCM4710 adding BCM4710_PROTECTED_FILL_TLB() to the
local_r4k_flush_cache_sigtramp() could not be ported. That function has
been dropped in:
commit adcc81f148d7 ("MIPS: math-emu: Write-protect delay slot emulation pages")
commit 3315b6b336c8 ("MIPS: Delete unused flush_cache_sigtramp()")
it's unsure if that chipset will still work reliably.
Leon M. George [Thu, 7 Nov 2019 12:24:40 +0000 (13:24 +0100)]
ipq40xx: add cpximg to flash Compex WPJ428 via bootloader
Generate a cpximg that is compatible with the cpximg loader in Compex' u-boot.
The cpximg loader can be started either by holding the reset button during power
up or by entering the u-boot prompt and entering 'cpximg'.
Once it's running, a TFTP-server under 192.168.1.1 will accept an image
appropriate for the board revision that is etched on the board (e.g. 6A04).
The image can be pushed using tftp:
tftp -v -m binary 192.168.1.1 -c put openwrt-ipq40xx-generic-compex_wpj428-squashfs-cpximg-6a04.bin
cpximg files can also be used with the sysupgrade utility in stock images.
(add SSH key in luci for root access)
In mkmylofw_32m, the calculation of the "partition size" has been preferred
to just padding the partition as this will result in less block transfers
during flashing (while the additional complexity is bearable).
Signed-off-by: Leon M. George <leon@georgemail.eu> Co-developed-by: Adrian Schmutzler <freifunk@adrianschmutzler.de> Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Petr Štetiar [Thu, 5 Mar 2020 11:46:21 +0000 (12:46 +0100)]
malta: fix missing watchdog core dependency for hwmon-sch5627
Fixes following error uncovered while building malta/be on 5.4:
Package kmod-hwmon-sch5627 is missing dependencies for the following libraries:
watchdog.ko
That dependency was introduced in upstream via 2d8c7ff52c24
("hwmon/sch56xx: Depend on watchdog for watchdog core functions") in
v3.5.
The issue emerged in 5.4 because the kconfig symbol CONFIG_WATCHDOG_CORE
is now a tristate value. Previously it was a bool
Cc: Yousong Zhou <yszhou4tech@gmail.com> Signed-off-by: Petr Štetiar <ynezz@true.cz> Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com>
(drop the config-4.19 change. reword about the cause)
Web interface:
It is possible to upgrade to OpenWrt via the web interface. However, the
OEM firmware upgrade file is required and a tool to fix the MD5 sum of
the header. This procedure overwrites U-Boot and there is not failsafe /
recovery mode present! To prepare an image, you need to take the header
and U-Boot (i.e. 0x200 + 0x20000 bytes) from an OEM firmware file and
attach the factory image to it. Then fix the header MD5Sum1.
Serial/TFTP:
You can use initramfs for booting via RAM or flash the image directly.
Additional Notes:
If the web interface upgrade fails, you have to open your device and
attach serial console. Since the web upgrade overwrites the boot loader,
you might also brick your device.
In order to flash back to stock, the first header and U-Boot needs to be
stripped from the original firmware.
Signed-off-by: Christoph Krapp <achterin@googlemail.com>
[change rssi LED labels] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
DENG Qingfang [Thu, 5 Mar 2020 08:13:55 +0000 (16:13 +0800)]
kernel: add exFAT fs driver
This was available since kernel 5.4. The one provided in packages feed
will be considered deprecated and renamed to kmod-fs-exfat0.
Signed-off-by: DENG Qingfang <dengqf6@mail2.sysu.edu.cn> Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com>
(use name kmod-fs-exfat. use "@!(LINUX_4_4||LINUX_4_19)" for dependency)
Robert Marko [Sun, 8 Mar 2020 16:21:27 +0000 (17:21 +0100)]
ipq40xx: add support for 8devices Habanero DVK
This patch adds support for the 8devices Habanero development board.
Specs are:
CPU: QCA IPQ4019
RAM: DDR3L 512MB
Storage: 32MB SPI-NOR and optional Parallel SLC NAND(Some boards ship with it and some without)
WLAN1: 2.4 GHz built into IPQ4019 (802.11n) 2x2
WLAN2: 5 GHz built into IPO4019 (802.11ac Wawe-2) 2x2
Ethernet: 5x Gbit LAN (QCA 8075)
USB: 1x USB 2.0 and 1x USB 3.0 (Both built into IPQ4019)
MicroSD slot (Uses SD controller built into IPQ4019)
SDIO3.0/EMMC slot (Uses the same SD controller)
Mini PCI-E Gen 2.0 slot (Built into IPQ4019)
5x LEDs (4 GPIO controllable)
2x Pushbutton (1 is connected to GPIO, other to SoC reset)
LCD ZIF socket (Uses the LCD controller built into IPQ4019 which has no driver support)
1x UART 115200 rate on J18
2x breakout development headers
12V DC Jack for power
DIP switch for bootstrap configuration
Installation instructions:
Since boards ship with vendors fork of OpenWrt sysupgrade can be used.