Signed-off-by: Jonathan Lancett <j.lancett@ntlworld.com>
[minor tweak to commit title]
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
(backported from 95b3f8ec8d)
This adds support for BBR (Bottleneck Bandwidth and RTT) TCP
congestion control. Applications (e.g. webservers, VPN client/server)
which initiate connections from router side can benefit from this.
This provide an easier way for users to use BBR by selecting /
installing kmod-tcp-bbr instead of altering kernel config and
compiling firmware by themselves.
Signed-off-by: Keith Wong <keithwky@gmail.com>
(backported from 79c233daa4)
Some of the modules in the crypto-misc package have alternate
implementations optimized for different x86 instruction set extensions,
but only one of these was built for this package until now: twofish-i586.ko
Tested with insmod, on both x86 and x86_64. The modules now have an
autoload, which they previous didn't, loading the dependencies in the
correct order.
Signed-off-by: Daniel Gimpelevich <daniel@gimpelevich.san-francisco.ca.us>
(backported from c762817c92)
Problem - rapsberry pi 3 b/b+ does not boot with bcm2710 images!
How Raspberry Pi boots Actualy?
When Raspberry is switched on GPU is activated.
1. GPU execute First stage bootloader from ROM.
First stage bootloader mount the FAT boot partition on the SD card
and execute second stage bootloader (bootcode.bin).
2. Second stage bootloader (bootcode.bin) activate SDRAM.
Load the GPU firmware (start.elf).
3. GPU firmware (start.elf)
a) display Rainbow splash.
b) read firmware configuration file config.txt and
split the RAM using fixup.dat.
c) loads a cmdline.txt
d) enables the CPU.
e) loads the kernel image configurable via config.txt
In your target/linux/brcm2708/image/config.txt
493 ## kernel (string)
494 ## Alternative name to use when loading kernel.
495 ##
496 #kernel=""
it is not configured!
But in your target/linux/brcm2708/image/Makefile
75 KERNEL_IMG := kernel8.img
76 DEVICE_TITLE := Raspberry Pi 3B/3B+
you have kernel8.img
GPU Firmware search order by default for a PI 3 is:
kernel8.img if found boot in 64 bit mode
kernel8-32.img if found boot in 32 bit mode
kernel7.img if found boot in 32 bit mode
kernel.img if found boot in 32 bit mode
But a PI 2 will start the search from kernel7.img and
a PI 1 only looks for kernel.img.
Оbviously the kernel has been found.
But something goes wrong and the device is restarted.
In your package/kernel/brcm2708-gpu-fw/Makefile
11 PKG_NAME:=brcm2708-gpu-fw
12 PKG_VERSION:=2017-08-08
13 PKG_RELEASE:=e7ba7ab135f5a68b2c00a919ea9ac8d5528a5d5b
boot loader is 10 monts old.
In conclusion, the best way to solve the problem is
to update the boot loader!
Fixup_cd.dat and start_cd.elf files are not necessary.
These are used when GPU memory is set to 16 MB, which disables
some GPU features.
I did not remove them just in case!
cheers
Signed-off-by: Christo Nedev <christo.nedev@gmail.com>
(backported from c335649629)
Add xt_bpf modules to {kmod-ipt,iptables-mod}-filter.
Match using Linux Socket Filter. Expects a BPF program in decimal
format. This is the format generated by the nfbpf_compile utility.
Signed-off-by: Alin Nastac <alin.nastac@gmail.com>
(backported from ab07ae2f27)
As of commit in kernel:
6104c37094 fbcon: Make fbcon a built-time depency for fbdev
framebuffer console is build in into framebuffer module and there's no
standalone fbcon module. Therefore drop the kmod-fbcon and enable
console in kmod-fb. The only targets which use these modules are imx6
and geode, both are on kernel 4.14 so no fallback for other kernels is
introduced.
Being at that this commit also fixes autoload of fbdev for x86.
Signed-off-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
(backported from 9c0ddafd46)
- adds new drivers for mt76x2u, mt76x0u and mt76x0e
- adds back fixed version of the tx status fixes
- improves mt7603e stability
Signed-off-by: Felix Fietkau <nbd@nbd.name>
First one is a fix for reporting channels to the user space. Important
for users as they could try setting invalid channel and fail to start an
interface.
Later is a support for newer FullMAC chipset firmwares.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Currently it's close to impossible to tell what part of mac80211 setup
went wrong. Errors logged into system log look like this:
radio0 (6155): command failed: No error information (-524)
radio0 (6155): command failed: Not supported (-95)
radio0 (6155): command failed: I/O error (-5)
radio0 (6155): command failed: Too many open files in system (-23)
With this commit change it's getting clear:
command failed: No error information (-524)
Failed command: iw dev wlan0 del
command failed: Not supported (-95)
Failed command: iw phy phy0 set antenna_gain 0
command failed: I/O error (-5)
Failed command: iw phy phy0 set distance 0
command failed: Too many open files in system (-23)
Failed command: iw phy phy0 interface add wlan0 type __ap
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit ffa80bf5a7)
Currently, dynack was only tested upstream using AP/STA mode.
Testing it on IBSS, showed that late-ack detection was broken.
This is caused due to dynack using Association Request/Response
frames for late-ack detection, which IBSS does not use.
Also allowing Authentication frames here solves this.
A second issue also got fixed, which was also seen AP/STA mode:
When a station was added, the estimated value would be exponentially averaged
using 0 as a starting point.
This means that on larger distances, the ack timeout was still not high
enough before synchronizing would run out of late-ack's for estimation.
Fix this by using the initial estimated value as a baseline
and only start averaging in the following estimation rounds.
Test setup:
- 2x identical devices: RB912UAG-5HPnD + 19dB sector
- IBSS
- 2x2 802.11an (ar9340), HT20, long GI
- RSSI's -70 / -71
- Real distance: 23910 meter
Results (60s iperf runs):
Fixed coverage class 54 (up to 24300m):
* 21.5 Mbits/sec
Dynack:
* 28.9 Mbits/sec
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
This reverts the following commits:
24ca1cda387998963428
The update was reported to cause stability issues.
Revert until those are resolved
Signed-off-by: Felix Fietkau <nbd@nbd.name>
199d6bf mt76x2: skip station tx status for non-sta wcid entries
d83ac6e mt76: only override control->sta on sw-encrypted tx
23abe5d mt76: add support for reporting tx status with skb
f8ce59e mt7603: use common tx status handling code
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Since kernel 4.14.75 commit ("netfilter: xt_cluster: add dependency on conntrack module")
a dependency is required on kmod-nf-conntrack.
It seems this was already present for kmod-ipt-clusterip
but not yet for kmod-ipt-cluster
Add it fixing a build error when including kmod-ipt-cluster:
Package kmod-ipt-cluster is missing dependencies for the following libraries:
nf_conntrack.ko
modules/netfilter.mk:665: recipe for target '/mnt/ramdisk/koen/firmware/builds/openwrt/bin/targets/cns3xxx/generic/packages/kmod-ipt-cluster_4.14.75-1_arm_mpcore_vfp.ipk' failed
make[3]: *** [/mnt/ramdisk/koen/firmware/builds/openwrt/bin/targets/cns3xxx/generic/packages/kmod-ipt-cluster_4.14.75-1_arm_mpcore_vfp.ipk] Error 1
make[3]: Leaving directory '/mnt/ramdisk/koen/firmware/builds/openwrt/package/kernel/linux'
Command exited with non-zero status 2
time: package/kernel/linux/compile#1.80#0.05#2.07
package/Makefile:107: recipe for target 'package/kernel/linux/compile' failed
make[2]: *** [package/kernel/linux/compile] Error 2
make[2]: Leaving directory '/mnt/ramdisk/koen/firmware/builds/openwrt'
package/Makefile:103: recipe for target '/mnt/ramdisk/koen/firmware/builds/openwrt/staging_dir/target-arm_mpcore+vfp_musl_eabi/stamp/.package_compile' failed
make[1]: *** [/mnt/ramdisk/koen/firmware/builds/openwrt/staging_dir/target-arm_mpcore+vfp_musl_eabi/stamp/.package_compile] Error 2
make[1]: Leaving directory '/mnt/ramdisk/koen/firmware/builds/openwrt'
/mnt/ramdisk/koen/firmware/builds/openwrt/include/toplevel.mk:216: recipe for target 'world' failed
make: *** [world] Error 2
Fixes: bba743458e ("kernel: bump 4.14 to 4.14.75")
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
[1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v4.14.75&id=b969656b46626a674232c0eadf92a394b89df07c
Revert "Add workaround for wrong skb->mac_len values after splitting GSO"
Remove our local patch which did the same thing.
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
(cherry picked from commit 885052fbfb)
Kernels 4.14.73 & 4.9.140 include the gso fixup fix, so cake
doesn't need to do it. Let's not waste cpu cycles by doing it in
cake which could be really important on cpu constrained devices.
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
(cherry picked from commit b47614f9f1)
Software crypto wasn't working for management frames because the flag
indicating management frame crypto was missing
Signed-off-by: Felix Fietkau <nbd@nbd.name>
497c304 mt7603: fix wcid for frames sent via drv_tx
27af7a5 mt76: fix handling ps-poll frames
c3dba28 mt76: check aggregation sequence number for frames sent via drv_tx
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Registering a GPIO chip with the ath9k device as parent prevents unload,
because the gpiochip core increases the module use count.
Unfortunately, the only way to avoid this at the moment seems to be to
register the GPIO chip without a parent device
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Bump to latest upstream cake:
Add workaround for wrong skb->mac_len values after splitting GSO
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
(cherry picked from commit 66fd41ba79)
Expand filter flow mapping to include hosts as well
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
(cherry picked from commit d14ffdc307d36bd9abe908b46ff7baece54c9551)
(cherry picked from commit 721dfd4eb8)
Follow upstream kernel patch that restores always splitting gso packets
by default whilst making the option configurable from (tc) userspace.
No ABI/API change
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
(cherry picked from commit fe077d20e3b484e55ad49d5711673d05d7a301de)
This allows driver to support features that can't be dynamically
discovered.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit fecbd91c7c)
Monitor mode isn't supported yet with brcmfmac, it's just an early work.
This also prepares brcmfmac to work stable with new firmwares which use
updated struct for passing STA info.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit c0608c6a27)
7daf962 mt7603: add survey support
980c606 mt7603: add fix for CCA signal configuration
30b8371 mt7603: fix BAR rate
Signed-off-by: Felix Fietkau <nbd@nbd.name>
'In different versions of coreboot are different names of apu boardname.
No need to check boardname to load module.'
Signed-off-by: Lukas Mrtvy <lukas.mrtvy@gmail.com>
(cherry picked from commit f21bcb4db8)
'In different versions of coreboot are different names of apu boardname.
No need to check boardname to load module.'
Signed-off-by: Lukáš Mrtvý <lukas.mrtvy@gmail.com>
(cherry picked from commit d3b8e6b2a7)
The most important is probably regression fix in handling platform
NVRAM. That bug stopped hardware from being properly calibrated breaking
e.g. 5 GHz for Netgear R8000.
Other than that it triggers memory dumps when experiencing firmware
problems which is important for debugging purposes.
Fixes: 2811c97803 ("mac80211: backport brcmfmac firmware & clm_blob loading rework")
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit b26214adb5)
Bump to the latest cake recipe.
This backports tc class support to kernel 4.9 and other than conditional
kernel compilation pre-processor macros represents the cake that has
gone upstream into kernel 4.19. Loud cheer!
Fun may be had by changing cake tin classification for packets on
ingress. e.g.
tc filter add dev ifb4eth0 parent 800b: protocol ip u32 match \
ip dport 6981 0xffff action skbedit priority 800b:1
Where 800b: represents the filter handle for the ifb obtained by 'tc
qdisc' and the 1 from 800b:1 represents the cake tin number. So the
above example puts all incoming packets destined for port 6981 into the
BULK (lowest priority) tin.
f39ab9a Obey tin_order for tc filter classifiers
1e2473f Clean up after latest backport.
82531d0 Reorder includes to fix out of tree compilation
52cbc00 Code style cleanup
6cdb496 Fix argument order for NL_SET_ERR_MSG_ATTR()
cab17b6 Remove duplicate call to qdisc_watchdog_init()
71c7991 Merge branch 'backport-classful'
32aa7fb Fix compilation on Linux 4.9
9f8fe7a Fix compilation on Linux 4.14
ceab7a3 Rework filter classification
aad5436 Fixed version of class stats
be1c549 Add cake-specific class stats
483399d Use tin_order for class dumps
80dc129 Add class dumping
0c8e6c1 Fix dropping when using filters
c220493 Add the minimum class ops
5ed54d2 Start implementing tc filter/class support
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
(cherry picked from commit c729c43b39)
08719b1 mt76: use a per rx queue page fragment cache
4d2c565 mt76x2: reset HW before probe
f622975 mt76x2: fix CCK protection control frame rate
6780375 mt76x2: add frame protection support
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Enables support for Dynack feature.
When a remote station is far away, we need to compensate for the distance
by allowing more time for an ACK to arrive back before issueing a retransmission.
Currently, it needs to be set fixed to indicate the maximum distance the remote
station will ever be.
While this mostly works for static antennae, it introduces 2 issues:
- If the actual distance is less, speed is reduced due to a lot of wates wait-time
- If the distance becomes greater, retries start to occur and comms can get lost.
Allowing to set it dynamically using dynack ensures the best possible tradeoff
between speed vs distance.
This feature is currently only supported in ath9k.
it is also disabled by default.
Enabling it can be done in 2 ways:
- issue cmd: iw phy0 set distance auto
- sending the NL80211_ATTR_WIPHY_DYN_ACK flag to mac80211 driver using netlink
Disabling it can be done by providing a valid fixed value.
To give an idea of a practical example:
In my usecase, we have mesh wifi device installed on ships/platforms.
Currently, the coverage class is set at 12000m fixed.
When a vessel moved closer (ex. 1500m), the measured link capacity was a lot
lower compared to setting the coverage class fixed to 1500m
Dynack completely solved this, nearly providing double the bandwidth at closer range
compared to the fixed setting of 12000m being used.
Also when a vessel sailed to a distance greater than the fixed setting,
communication was lost as the ACK's never arrived within the max allowed timeframe.
Actual distance: 6010m
iperf 60s run avg
Fixed 12150m: 31 Mbit/s
Dynack: 58 Mbit/s
Fixed 6300m: 51 Mbit/s
Dynack: 59 Mbit/s
Fixed 3000m: 13 Mbit/s (lots of retries)
Dynack: 58 Mbit/s
Actual distance: 1504m
iperf 60s run avg
Fixed 12150m: 31 Mbit/s
Dynack: 86 Mbit/s
Fixed 6300m: 55 Mbit/s
Dynack: 87 Mbit/s
Fixed 3000m: 67 Mbit/s
Dynack: 87 Mbit/s
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
