Due to a limited grep pattern, subjects containing dots like `image.mk`
were falsely reported as problematic. Extend pattern to allow dots.
Signed-off-by: Paul Spooren <mail@aparcar.org>
Adding the feature flag automatically creates a a rootfs.tar.gz files
which can be used for Docker rootfs containers.
Signed-off-by: Paul Spooren <mail@aparcar.org>
Backport fix for API breakage of SSL_get_verify_result() introduced in
v5.1.1-stable. In v4.8.1-stable SSL_get_verify_result() used to return
X509_V_OK when used on LE powered sites or other sites utilizing
relaxed/alternative cert chain validation feature. After an update to
v5.1.1-stable that API calls started returning X509_V_ERR_INVALID_CA
error and thus rendered all such connection attempts imposible:
$ docker run -it openwrt/rootfs:x86_64-21.02.2 sh -c "wget https://letsencrypt.org"
Downloading 'https://letsencrypt.org'
Connecting to 18.159.128.50:443
Connection error: Invalid SSL certificate
Fixes: #9283
References: https://github.com/wolfSSL/wolfssl/issues/4879
Signed-off-by: Petr Štetiar <ynezz@true.cz>
fwtool is now always part of the sysupgrade stage2 ramdisk, so drop
the no longer needed RAMFS_COPY_BIN variable.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Now that both, fw_printenv/fw_setenv and fwtool are always present
during stage2 sysupgrade, we no longer need to list them in
RAMFS_COPY_BIN and RAMFS_COPY_DATA in platform.sh.
Drop both variables as they are now unneeded.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Not all targets create /var/lock or touch /var/lock/fw_printenv.lock in
their platform.sh. This is problematic as fw_printenv then fails in
case /var/lock/fw_printenv.lock has not been created by previous calls
to fw_printenv/fw_setenv before sysupgrade is run.
Targets using fw_printenv/fw_setenv during sysupgrade:
* ath79/*
* ipq40xx/*
* ipq806x/*
* kirkwood/*
* layerscape/*
* mediatek/mt7622
* mvebu/*
* ramips/*
* realtek/*
Targets currently using additional steps in /lib/upgrade/platform.sh
to make sure /var/lock/fw_printenv.lock (or at least /var/lock)
actually exists:
* ath79/* (openmesh devices)
* ipq40xx/* (linksys devices)
* ipq806x/* (linksys devices)
* kirkwood/* (linksys devices)
* layerscape/*
* mvebu/cortexa9 (linksys devices)
Given that accessing the U-Boot environment during sysupgrade is not
uncommon and the situation across targets is currently quite diverse,
just make sure both tools as well fw_env.config are always copied to
the ramdisk used for sysupgrade. Also make sure /var/lock always
exists.
This now allows to remove copying of fw_printenv/fw_setenv as well as
fw_env.config, creation of /var/lock or even /var/lock/fw_printenv.lock
from lib/upgrade/platform.sh or files included there.
As the same applies also to 'fwtool' which is used by generic eMMC
sysupgrade, also always copy that to ramdisk.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
diffconfig.sh runs ./scripts/config/conf, but it does not get built
with 'make {menu,x,n}config. Call 'make ./scripts/config/conf' to
ensure it's been built befpre running it.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
Toplevel Make is not aware about changes in the `scripts/config/*conf`
targets and this is causing issues for during update to that part of
build tree, where one needs to handle this manually by either force
rebuilding the targets or running `make config-clean`. Fix this by
forcing the rebuild if necessary.
Fixes: #9297
Signed-off-by: Petr Štetiar <ynezz@true.cz>
This uses uci to configure engines, by generating a list of enabled
engines in /var/etc/ssl/engines.cnf from engines configured in
/etc/config/openssl:
config engine 'devcrypto'
option enabled '1'
Currently the only options implemented are 'enabled', which defaults to
true and enables the named engine, and the 'force' option, that enables
the engine even if the init script thinks the engine does not exist.
The existence test is to check for either a configuration file
/etc/ssl/engines.cnf.d/%ENGINE%.cnf, or a shared object file
/usr/lib/engines-1.1/%ENGINE%.so.
The engine list is generated by an init script which is set to run after
'log' because it informs the engines being enabled or skipped. It
should run before any service using OpenSSL as the crypto library,
otherwise the service will not use any engine.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
This enables an engine during its package's installation, by adding it
to the engines list in /etc/ssl/engines.cnf.d/engines.cnf.
The engine build system was reworked, with the addition of an engine.mk
file that groups some of the engine packages' definitions, and could be
used by out of tree engines as well.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
This changes the configuration of engines from the global openssl.cnf to
files in the /etc/ssl/engines.cnf.d directory. The engines.cnf file has
the list of enabled engines, while each engine has its own configuration
file installed under /etc/ssl/engines.cnf.d.
Patches were refreshed with --zero-commit.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
The 'BOARDNAME' variable is part of target configuration and shouldn't
be part of a device's image recipe.
Signed-off-by: Piotr Dymacz <pepe2k@gmail.com>
The I/O base address for the timers was hardcoded into the driver,
or derived from the HW IRQ number as an even more horrible hack. All
supported SoC families have these timers, but with hardcoded addresses
the code cannot be reused right now.
Request the timer's base address from the DT specification, and store it
in a private struct for future reference.
Matching the second interrupt specifier, the address range for the
second timer is added to the DT specification.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
The Realtek timer node for RTL930x doesn't have any child nodes, making
the use of '#address-cells' quite pointless. It is also not an interrupt
controller, meaning it makes no sense to define '#interrupt-cells'.
The I/O address for this node is also wrong, but this is hidden by the
fact that the driver associated with this node bypasses the usual DT
machinery and does it's own thing. Correct the address to have a sane
value, even though it isn't actually used.
Fixes: a75b9e3ecb ("realtek: Adding RTL930X sub-target")
Signed-off-by: Sander Vanheule <sander@svanheule.net>
When driven by a GPIO pin, the system LED needs to be configured as
active high. Otherwise the LED switches off after booting and
initialisation.
Fixes: 47f5a0a3ee ("realtek: Add support for ZyXEL GS1900-48 Switch")
Signed-off-by: Sander Vanheule <sander@svanheule.net>
The default value for a DT node's status property is already "okay", so
there's no need to specify it again. Drop the status property to clean
up the DTS.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
The assigned output index for the event timers was quite low, lower even
than the ethernet interrupt. This means that high network load could
preempt timer interrupts, possibly leading to all sorts of strange
behaviour.
Increase the interrupt output index of the event timers to 5, which is
the highest priority output and corresponds to the (otherwise unused)
MIPS CPU timer interrupt.
Fixes: a75b9e3ecb ("realtek: Adding RTL930X sub-target")
Signed-off-by: Sander Vanheule <sander@svanheule.net>
The RTL8231 is an external chip, and not part of the SoC. That means
it is more appropriate to define it in the board specific (base) files,
instead of the DT include for the SoC itself.
Moving the RTL8231 definition also ensures that boards with no GPIO
expander, or an alternative one, don't have a useless gpio1 node label
defined.
Tested on a Netgear GS110TPPv1.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
The address in some node names doesn't match the actual offset specified
in the DT node. Update the names to fix this.
While fixing the node names, also drop the unused node labels.
Fixes: 0a7565e536 ("realtek: Update rtl839x.dtsi for realtek,rtl-intc, new gpio controller remove RTL8231 node")
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Bootargs for devices in the realtek target were previously consolidated
in commit af2cfbda2b ("realtek: Consolidate bootargs"), since all
devices currently use the same arguments.
Commit a75b9e3ecb ("realtek: Adding RTL930X sub-target") reverted this
without any argumentation, so let's undo that.
Commit 0b8dfe0851 ("realtek: Add RTL931X sub-target") introduced the
old bootargs also for RTL931x, without providing any actual device
support. Until that is done, let's assume vendors will have done what
they did before, and use a baud rate of 115200.
Fixes: a75b9e3ecb ("realtek: Adding RTL930X sub-target")
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Enable the AP806's cpufreq driver. This driver is compatible with the
Armada 7K and 8K platforms.
Tested-by: Stijn Segers <foss@volatilesystems.org> (RB5009UG+S+IN)
Signed-off-by: Matthew Hagan <mnhagan88@gmail.com>
100-ddr-marvell-a38x-fix-BYTE_HOMOGENEOUS_SPLIT_OUT-deci.patch [1]:
SoC Marvell A38x is used in Turris Omnia, and we thought that with recent
fiddling around DDR training to fix it once for all, there were
reproduced the issue in the upcoming new revision Turris Omnia boards.
101-arm-mvebu-spl-Add-option-to-reset-the-board-on-DDR-t.patch [2]:
This is useful when some board may occasionally fail with DDR training,
and it adds the option to reset the board on the DDR training failure
102-arm-mvebu-turris_omnia-Reset-the-board-immediately-o.patch [3]:
This enables the option CONFIG_DDR_RESET_ON_TRAINING_FAILURE (added by
101 patch), so the Turris Omnia board is restarted immediately, and it
does not require to reset the board manually or wait 120s for MCU to
reset the board
[1] https://patchwork.ozlabs.org/project/uboot/patch/20220217000837.13003-1-kabel@kernel.org/
[2] https://patchwork.ozlabs.org/project/uboot/patch/20220217000849.13028-1-kabel@kernel.org/
[3] https://patchwork.ozlabs.org/project/uboot/patch/20220217000849.13028-2-kabel@kernel.org/
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
Enabled CONFIG_ALL_KMODS and ran make kernel_menuconfig against
bcm2711 to update defconfig. Some of the removed symbols are
present in target/linux/generic/config-5.10 while others were
removed by the make target.
Signed-off-by: John Audia <graysky@archlinux.us>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com> (wrapped)
Enabled CONFIG_ALL_KMODS and ran make kernel_menuconfig against
bcm2710 to update defconfig. Some of the removed symbols are
present in target/linux/generic/config-5.10 while others were
removed by the make target.
Signed-off-by: John Audia <graysky@archlinux.us>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com> (wrapped)
Enabled CONFIG_ALL_KMODS and ran make kernel_menuconfig against
bcm2709 to update defconfig. Some of the removed symbols are
present in target/linux/generic/config-5.10 while others were
removed by the make target.
Signed-off-by: John Audia <graysky@archlinux.us>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com> (wrapped)
Enabled CONFIG_ALL_KMODS and ran make kernel_menuconfig against
bcm2708 to update defconfig. Some of the removed symbols are
present in target/linux/generic/config-5.10 while others were
removed by the make target.
Signed-off-by: John Audia <graysky@archlinux.us>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com> (wrapped)
This commit adds the following package compile options.
CONFIG_PACKAGE_RTW88_DEBGUG:
Compile the driver with additional debug logging output
CONFIG_PACKAGE_RTW88_DEBGUGFS:
Add the possibility to map information about the driver rtw88 into
debugfs.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
Fix the missing ;; after the cAP ac case in /e/b/01_leds.
Fixes: 93d9119 ("ipq40xx: add MikroTik cAP ac support")
Signed-off-by: Robert Marko <robimarko@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com> (minor touch-up)
The kernel of both images will no longer fit into
the 3072KiB / 3MiB kernel partition:
|Image Name: ARM OpenWrt Linux-5.10.100
|Created: Sat Feb 19 00:11:55 2022
|Image Type: ARM Linux Kernel Image (uncompressed)
|Data Size: 3147140 Bytes = 3073.38 KiB = 3.00 MiB
Disable both targets for now, until a solution is available.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Contains following changes:
136006b88826 cmake: fix usage of implicit library and include paths
bc0e84d689e2 netifd: interface-ip: don't set fib6 policies if ipv6 disabled
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Use correct indent in target/linux/ramips/image/mt7621.mk
to be consistent with the rest of the file.
Signed-off-by: Nick McKinney <nick@ndmckinney.net>
[rephrase commit message as Adrian suggested, fix a6004ns-m indent]
Signed-off-by: Sungbo Eo <mans0n@gorani.run>
The LED and LAN port numbering on the case of wndr4500v3 devices are
reversed relative to the wndr4300v2. I created this patch to so that the
ordering in OpenWRT will be consistent with that.
Signed-off-by: Graham Cole <diakka@gmail.com>
Add support for ipTIME A3002MESH.
Hardware:
- SoC: MediaTek MT7621AT (880MHz, Duel-Core)
- RAM: DDR3 128MB
- Flash: XMC XM25QH128AHIG (SPI-NOR 16MB)
- WiFi: MediaTek MT7615D (2.4GHz, 5GHz, DBDC)
- Ethernet: MediaTek MT7530 (WAN x1, LAN x2, SoC built-in)
- UART: [GND, RX, TX, 3.3V] (57600 8N1, J4)
MAC addresses:
| interface | MAC | source | comment
|-----------|-------------------|----------------|----------
| LAN | 70:XX:XX:5X:XX:X3 | |
| WAN | 70:XX:XX:5X:XX:X1 | u-boot 0x1fc40 |
| WLAN 2G | 72:XX:XX:4X:XX:X0 | |
| WLAN 5G | 70:XX:XX:5X:XX:X0 | factory 0x4 |
| | 70:XX:XX:5X:XX:X0 | u-boot 0x1fc20 | unknown
| | 70:XX:XX:5X:XX:X2 | factory 0x8004 | unknown
- WLAN 2G MAC address is not the same as stock firmware since OpenWrt
uses LAN MAC address with local bit sets.
Installation:
1. Flash initramfs image. This can be done using stock web ui or TFTP
2. Connect to OpenWrt with an SSH connection to 192.168.1.1
3. Perform sysupgrade with sysupgrade image
Revert to stock firmware:
- Flash stock firmware via OEM TFTP Recovery mode
- Perform sysupgrade with stock image
TFTP Recovery method:
1. Unplug the router
2. Hold the reset button and plug in
3. Release when the power LED stops flashing and go off
4. Set your computer IP address manually to 192.168.0.x / 255.255.255.0
5. Flash image with TFTP client to 192.168.0.1
Signed-off-by: Yoonji Park <koreapyj@dcmys.kr>
[wrap/rephrase commit message]
Signed-off-by: Sungbo Eo <mans0n@gorani.run>
This reverts commit 13a185bf8a.
There was a report that one A1004ns device fails to detect its flash
chip correctly:
[ 1.470297] spi-nor spi0.0: unrecognized JEDEC id bytes: e0 10 0c 40 10 08
[ 1.484110] spi-nor: probe of spi0.0 failed with error -2
It also uses a different flash chip model:
* in my hand: Winbond W25Q128FVSIG (SOIC-8)
* reported: Macronix MX25L12845EMI-10G (SOP-16)
Reducing spi-max-frequency solved the detection failure. Hence revert.
Reported-by: Koasing <koasing@gmail.com>
Tested-by: Koasing <koasing@gmail.com>
Signed-off-by: Sungbo Eo <mans0n@gorani.run>
e061299 wireless-regdb: Raise DFS TX power limit to 250 mW (24 dBm) for the US
2ce78ed wireless-regdb: Update regulatory rules for Croatia (HR) on 6GHz
0d39f4c wireless-regdb: Update regulatory rules for South Korea (KR)
acad231 wireless-regdb: Update regulatory rules for France (FR) on 6 and 60 GHz
ea83a82 wireless-regdb: add support for US S1G channels
4408149 wireless-regdb: add 802.11ah bands to world regulatory domain
5f3cadc wireless-regdb: Update regulatory rules for Spain (ES) on 6GHz
e0ac69b Revert "wireless-regdb: Update regulatory rules for South Korea (KR)"
40e5e80 wireless-regdb: Update regulatory rules for South Korea (KR)
e427ff2 wireless-regdb: Update regulatory rules for China (CN)
0970116 wireless-regdb: Update regulatory rules for the Netherlands (NL) on 6GHz
4dac44b wireless-regdb: update regulatory database based on preceding changes
Signed-off-by: Sungbo Eo <mans0n@gorani.run>
mtd-mac-address should no longer be used after commit 5ae2e78639
("kernel: drop support for mtd-mac-address"). Convert it to nvmem-cells.
While at it, also convert OpenWrt's custom mtd-cal-data property and
userspace pre-calibration data extraction to the nvmem implementation.
Note: nvmem-cells in QCN5502 wmac has not been tested.
Fixes: c32008a37b ("ath79: add partial support for Netgear EX7300v2")
Signed-off-by: Sungbo Eo <mans0n@gorani.run>
Upstream hwmon-maintainer had various comments about
the changes to the tc654 driver. These have been
addressed and the cooling device support is destined
for inclusion.
One of the comments was the change of the cooling states
scaling. No longer the driver uses the same values as the
hwmon interface, instead the states are now the 17 states
the tc654 supports.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
package hwmon's lm70.ko. This module supports the
National Semiconductor/TI LM70,LM71,LM74 and
TI TMP121,TMP122,TMP123 and TMP124 chips (all SPI).
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
include the device-tree binding headers that provide definitions
for keys codes and gpios in the device-tree files.
Random bonus: merge tl-wdr4900-v1's uboot with the nvmem-node.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
silences the following message:
> eeprom 0-0051: eeprom driver is deprecated, please use at24 instead
The chip was likely a Dallas Semiconductor and later MAXIM part
before Analog Devices, Inc. bought MAXIM.
From the datasheet:
"The DS28CN01 combines 1024 bits of EEPROM with challenge-and-response
authentication security implemented with the FIPS 180-1/180-2 and
ISO/IEC 10118-3 Secure Hash Algorithm (SHA-1)."
...
"Write Access Requires Knowledge of the Secret
and the Capability of Computing and Transmitting
a 160-Bit MAC as Authorization"
OpenWrt doesn't use it. There's no in-kernel driver
from what I know. Let's document that the chip is
at the location.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
The tricolor LED which is controlled by a lp5521 needed
some maintenance as the driver failed to load in the
current v5.10 image:
| lp5521: probe of 0-0032 failed with error -22
This is because the device-tree needed to be updated
to match the latest led coloring and function trends.
- removed the device name from the label
- added color/function properties
- added required reg and cells properties
For reference a disabled multicolor/RGB is added since this
reflects the real hardware. Unfortunately, the multicolor
sysfs interface isn't supported by yet.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
