CONFIG_VLAN_8021Q was explicitely disabled in oxnas kernel config.
Don't do that, so VLANs can be used on the target.
Fixes: dcc34574ef ("oxnas: bring in new oxnas target")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Sercomm H500-s is an xDSL dual band wireless router based on Broadcom
BCM63167 SoC.
Hardware:
SoC: Broadcom BCM63167
CPU: BMIPS4350 V8.0, 400 MHz, 2 cores
Flash: NAND 128 MiB
RAM: DDR3 128 MiB
Ethernet: 4x 10/100/1000 Mbps
Switch: BCM53134S
Wireless: 802.11b/g/n: BCM435f (integrated)
802.11ac: Quantenna QT3740BC (onboard SoC)
USB: 1x 2.0
LEDs/Buttons: 11x / 2x
Flash instruction, web UI:
1. Reset to defaults using the reset button if the admin password is
unknown
2. Login into the web UI as admin.
Address: http://192.168.0.1
User: admin
Password: VF-ESVodafone-H-500-s or l033i-h500s
3. Go to Settings -> Firmware Update, and select the Openwrt factory
firmware
4. Update the firmware.
5. Wait until it finish, the device will reboot with Openwrt installed
on the alternative image partitions keeping the stock firmware in
the former.
Notes:
- The patch also adds support for the lowi version. Only the factory
firmware is different.
- The integrated Wifi in the Broadcom Soc isn't still supported.
- The Quantenna 802.11ac wifi works ok, but needs to be configured with
the Quantenna client application. It can't be configured with Luci
nor any iw command since it's a separated subsystem linked via
ethernet.
- The BCM53134S external switch is managed via MDIO which isn't
supported in this target. Therefore it will behave as a dumb switch.
Signed-off-by: Daniel González Cabanelas <dgcbueu@gmail.com>
Some CFEs are located at the address currently used for relocation and lzma
loader load address, so we need to provide a way to override it.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
There is no need to include the CFE bootloader in the Sercomm factory
images.
There might be a case when this could be useful:
- We are running the stock firmware on the first Sercomm image
- The second partition storing the botloader was erased (unlikely)
Even in this case flashing an image without a bootlader is harmless.
Don't include the bootloader in the factory image creation and rid of the
risk of flashing factory images with an untested bootloader partition.
Signed-off-by: Daniel González Cabanelas <dgcbueu@gmail.com>
The BCM63167 is a BCM63268 SoC with a different physical packaging.
Add the CPU ID to allow supporting routers with this SoC (i.e Sercomm
H500-s)
Signed-off-by: Daniel González Cabanelas <dgcbueu@gmail.com>
- sort device recipes alphabetically
- adjust board name of ELECOM WRC-2533GENT
- harmonize line wrapping
Signed-off-by: Sungbo Eo <mans0n@gorani.run>
[rebased]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This updates to the last firmware version before the switch to building
from the common firmware branch, which introduces various issues.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Acked-by: Álvaro Fernández Rojas <noltari@gmail.com>
This reverts commit 9e467a764b.
The Raspberry Pi firmware recently switched to building from the common
firmware branch. This introduces changes in the core clock handling,
causing various issues.
E.g. enable_uart=1 no longer fixes the core clock frequency to 250MHz.
When the disable-bt DT overlay is not loaded, the core clock frequency
is increased to 400MHz. As a result, the UART baud rate is no longer
correct, and this causes garbled serial console, or communication
problems with HATs that use the UART.
As a workaround, the core clock could be fixed to 250MHz by adding
'core_freq=250' in /boot/config.txt, but as there appear to be other
issues than just the UART being broken, the safer bet is to revert the
firmware for now.
Upstream bug: https://github.com/raspberrypi/firmware/issues/1376
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Acked-by: Álvaro Fernández Rojas <noltari@gmail.com>
As reported in https://github.com/openwrt/packages/issues/12072, the
imagebuilder fails due to a dependency resolution error when the userspace
packages are built using a target that has a different kernel version than
that which is being run. To resolve this, add a virtual kernel package with
the conditional dependency currently used in sqm-scripts. The idea is to
move the sqm-scripts dependency to this virtual package, which hopefully
should be consistent with the actual kernel module being built.
Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
Use in tree version of cake for kernels 4.19+ and backport features from
later kernel versions to 4.19.
Unfortunately PROVIDES dependency handling produces bogus circular
dependency warnings so whilst this package and kmod-sched-cake-oot
should be able to PROVIDE kmod-sched-cake this doesn't work.
Instead, remove the PROVIDES option and modify package sqm-scripts to
depend on the correct module independently.
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
In preparation for dropping the out of tree cake module and using
in tree cake from upstream, rename the package to kmod-sched-cake-oot
(out of tree)
Initially add a PROVIDES kmod-sched-cake so that package dependencies
can be satisfied.
Ultimately this package will be removed when linux 4.14 is removed.
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Due to a typo, /boot is not properly unmounted after copying the backup
file to it. Fix the typo to solve this.
Fixes: 246916ddf4 ("brcm2708: use x86's upgrade scripts for all rpi targets")
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
If you want to use the Raspberry Pi UART, "console=serial0,115200" needs
to be removed from the kernel cmdline. This is done by editing
/boot/cmdline.txt. However, this file is not currently backed up during
sysupgrade, so this effectively breaks HATs that require the use of the
UART every sysupgrade.
Backup this file during sysupgrade, and restore it before rebooting.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
This will be moved to packages:
https://github.com/openwrt/packages/pull/12378
Signed-off-by: Rosen Penev <rosenp@gmail.com>
[commit subject facelift]
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Does not seem to be needed here. This will be imported into packages.
Ref: https://github.com/openwrt/packages/pull/12256
Signed-off-by: Rosen Penev <rosenp@gmail.com>
[subject facelift, PR ref]
Signed-off-by: Petr Štetiar <ynezz@true.cz>
No package in base uses libconfig. Everything is in the packages feed.
Ref: https://github.com/openwrt/packages/pull/12255
Signed-off-by: Rosen Penev <rosenp@gmail.com>
[subject facelift, PR ref]
Signed-off-by: Petr Štetiar <ynezz@true.cz>
While the other fq-based qdiscs take advantage of skb->hash and doesn't
recompute it if it is already set, sch_cake does not.
This was a deliberate choice because sch_cake hashes various parts of the
packet header to support its advanced flow isolation modes. However,
foregoing the use of skb->hash entirely loses a few important benefits:
- When skb->hash is set by hardware, a few CPU cycles can be saved by not
hashing again in software.
- Tunnel encapsulations will generally preserve the value of skb->hash from
before the encapsulation, which allows flow-based qdiscs to distinguish
between flows even though the outer packet header no longer has flow
information.
It turns out that we can preserve these desirable properties in many cases,
while still supporting the advanced flow isolation properties of sch_cake.
This patch does so by reusing the skb->hash value as the flow_hash part of
the hashing procedure in cake_hash() only in the following conditions:
- If the skb->hash is marked as covering the flow headers (skb->l4_hash is
set)
AND
- NAT header rewriting is either disabled, or did not change any values
used for hashing. The latter is important to match local-origin packets
such as those of a tunnel endpoint.
The immediate motivation for fixing this was the recent patch to WireGuard
to preserve the skb->hash on encapsulation. As such, this is also what I
tested against; with this patch, added latency under load for competing
flows drops from ~8 ms to sub-1ms on an RRUL test over a WireGuard tunnel
going through a virtual link shaped to 1Gbps using sch_cake. This matches
the results we saw with a similar setup using sch_fq_codel when testing the
WireGuard patch.
Fixes: 046f6fd5daef ("sched: Add Common Applications Kept Enhanced (cake) qdisc")
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
A direct upgrade from previous swconfig version with
incompatible settings to DSA will break the internet.
Remove SUPPORTED_DEVICES so users cannot upgrade directly.
Signed-off-by: DENG Qingfang <dengqf6@mail2.sysu.edu.cn>
[rebase after Linksys rename, adjust title]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The Linksys devices in mvebu target feature a mixed naming,
where parts are based on the official product name (device
node, image; e.g. WRT3200ACM) and parts are based on the
internal code name (DTS file name, compatible, LED labels;
e.g. rango). This inconsistent naming has been perceived
as quite confusing.
A recent attempt by Paul Spooren to harmonize this naming
in kernel has been declined there. However, for us it still
makes sense to apply at least a part of these changes
locally.
Primarily, this patch changes the compatible in DTS and thus
the board name used in various scripts to have them in line
with the device, model and image names. Due to the recent
switch from swconfig to DSA, this allows us to drop
SUPPORTED_DEVICES and thus prevent seamless upgrade between
these incompatible setups.
However, this does not include the LED label rename from
Paul's initial patch: I don't think it's worth keeping the
enormous diff locally for this case, as we can implement
this much easier in 01_leds if we have to live with the
inconsistency anyway.
Signed-off-by: Paul Spooren <mail@aparcar.org>
[rebase, extend to all devices, drop DT LED changes]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
When a client moves from a DSA user port to a software port in a bridge,
it cannot reach any other clients that connected to the DSA user ports.
That is because SA learning on the CPU port is disabled, so the switch
ignores the client's frames from the CPU port and still thinks it is at
the user port.
Fix it by enabling SA learning on the CPU port.
To prevent the switch from learning from flooding frames from the CPU
port, set skb->offload_fwd_mark to 1 for unicast and broadcast frames,
and let the switch flood them instead of trapping to the CPU port.
Multicast frames still need to be trapped to the CPU port for snooping,
so set the SA_DIS bit of the MTK tag to 1 when transmitting those frames
to disable SA learning.
Signed-off-by: DENG Qingfang <dengqf6@mail2.sysu.edu.cn>
Currently enabling VLAN filtering blocks all traffic in the bridge
immediately. That is because DSA ignores all VLAN setup when VLAN
filtering is disabled, and when it is enabled, there is no VLAN entry
in the VLAN table, causing all traffic to be blocked.
Add patches to allow VLAN setup even if VLAN filtering is disabled.
Signed-off-by: DENG Qingfang <dengqf6@mail2.sysu.edu.cn>
Currently, setting a bridge's self PVID to other value and deleting
the default VID 1 renders untagged ports of that VLAN unable to talk to
the CPU port:
bridge vlan add dev br0 vid 2 pvid untagged self
bridge vlan del dev br0 vid 1 self
bridge vlan add dev sw0p0 vid 2 pvid untagged
bridge vlan del dev sw0p0 vid 1
# br0 cannot send untagged frames out of sw0p0 anymore
That is because the CPU port is set to security mode and its PVID is
still 1, and untagged frames are dropped due to VLAN member violation.
Set the CPU port to fallback mode so untagged frames can pass through.
Signed-off-by: DENG Qingfang <dengqf6@mail2.sysu.edu.cn>
Remove dependencies on core kernel headers in host tools used to build perf,
which break on any non-linux system
Signed-off-by: Felix Fietkau <nbd@nbd.name>
