Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
On Sun, Mar 31, 2019 at 11:49 PM Lorenzo Bianconi
wrote:
>
> >
> > On Sun, Mar 31, 2019 at 12:15 PM Lorenzo Bianconi
> > wrote:
> > >
> > > >
> > > > On Sun, Mar 31, 2019 at 6:45 AM Lorenzo Bianconi
> > > > wrote:
> > > > >
> > > > > >
> > > > > > bump.
> > > > >
> > > > > Hi Joe,
> > > > >
> > > > > sorry for the delay
> > > > >
> > > > > >
> > > > > > On Mon, Mar 18, 2019 at 10:59 PM Joe Ayers
> > > > > > wrote:
> > > > > >>
> > > > > >> Lorenzo, I have tested dynack on a (real distance apart) ~60km
> > > > > >> link
> > > > > >> with some success. This is the code change made:
> > > > > >>
> > > > > >> --- a/drivers/net/wireless/ath/ath9k/dynack.c
> > > > > >> +++ b/drivers/net/wireless/ath/ath9k/dynack.c
> > > > > >> @@ -20,8 +20,9 @@
> > > > > >>
> > > > > >> #define COMPUTE_TO (5 * HZ)
> > > > > >> #define LATEACK_DELAY (10 * HZ)
> > > > > >> -#define LATEACK_TO 256
> > > > > >> -#define MAX_DELAY 300
> > > > > >> +#define LATEACK_TO 1054
> > > > > >> +/* AREDN max distance set to 150km */
> > > > > >> +#define MAX_DELAY 1054
> > > > > >> #define EWMA_LEVEL 96
> > > > > >> #define EWMA_DIV 128
> > > > > >>
> > > > > >> @@ -293,7 +294,8 @@
> > > > > >> void ath_dynack_node_init(struct ath_hw *ah, struct ath_node *an)
> > > > > >> {
> > > > > >> /* ackto = slottime + sifs + air delay */
> > > > > >> - u32 ackto = 9 + 16 + 64;
> > > > > >> + /* AREDN starting point is 20km */
> > > > > >> + u32 ackto = 9 + 16 + 171;
> > > > > >> struct ath_dynack *da = &ah->dynack;
> > > > > >>
> > > > > >> an->ackto = ackto;
> > > > > >> @@ -328,7 +330,8 @@
> > > > > >> void ath_dynack_reset(struct ath_hw *ah)
> > > > > >> {
> > > > > >> /* ackto = slottime + sifs + air delay */
> > > > > >> - u32 ackto = 9 + 16 + 64;
> > > > > >> + /* AREDN starting point is 20km */
> > > > > >> + u32 ackto = 9 + 16 + 171;
> > > > > >> struct ath_dynack *da = &ah->dynack;
> > > > > >>
> > > > > >> da->lto = jiffies;
> > > > > >>
> > > > > >> Notes:
> > > > > >>
> > > > > >> 1) The stations are showing ack_to between 525 up to 575 A. When
> > > > > >> static set at 60k distance, the timeout is set to 460 S.
> > > > > >> 2) significant performance improvement between these settings with
> > > > > >> iperf3 and back to back runs with reboot in the middle:
> > > > > >>
> > > > >
> > > > > could you please try to attached patch? The max distance the hw can
> > > > > support depends of channel width:
> > > > > e.g @20MHz (HT20, 5GHz)
> > > > >
> > > > > max distance is ~ 61Km
> > > > >
> > > >
> > > > Could these max distance specs be what the manufacture tested, not
> > > > necessarily a hardware limitation -- just not known?
> > > >
> > >
> > > https://github.com/torvalds/linux/blob/master/drivers/net/wireless/ath/ath9k/hw.c#L1006
> > >
> > > max timeout you can set is AR_TIME_OUT_ACK (0x3fff) / clock_rate
> > >
> > > > I suspect in the calculation for max_to, if the channel is 10MHz, the
> > > > max distance can be doubled for the hardware--do the specs only give
> > > > 20MHz values? This would be consistent with, for example, the symbol
> > > > lengths are doubled when cutting the bandwidth in half, hence half the
> > > > rates and still 64 bins or 64 point fft squeezed in the channel. SNR
> > > > is also 3dB higher given same energy in half the bandwidth. We don't
> > > > see 20MHz channels working at these long distances, rather use 10MHz
> > > > for it to work. Intuitively, as I understand it, more time is needed
> > > > with increased distance for reflection signals to not be received past
> > > > the symbol time and increased inter-symbol interference.
> > >
> > > yes, but it is already done in ath9k_hw_set_clockrate()
> > > https://github.com/torvalds/linux/blob/master/drivers/net/wireless/ath/ath9k/hw.c#L61
> > >
> > > >
> > > > > @Koen: do you have any chance to test the attached patch in your
> > > > > environment? Thx
> > > > >
> > > > > >> run 1 @ static 60km:
> > > > > >> [ 5] 0.00-10.00 sec 7.31 MBytes 6.13 Mbits/sec0
> > > > > >>sender
> > > > > >> [ 5] 0.00-10.08 sec 7.16 MBytes 5.95 Mbits/sec
> > > > > >>receiver
> > > > > >>
> > > > > >> run 2 @ static 60km:
> > > > > >> [ 5] 0.00-10.00 sec 5.88 MBytes 4.93 Mbits/sec0
> > > > > >>sender
> > > > > >> [ 5] 0.00-10.04 sec 5.77 MBytes 4.81 Mbits/sec
> > > > > >>receiver
> > > > > >>
> > > > > >> run 1 and 2 @ auto distance -- goes up to ~575us with data flow,
> > > > > >> floats back to ~525 otherwise:
> > > > > >> [ 5] 0.00-10.00 sec 20.0 MBytes 16.8 Mbits/sec0
> > > > > >>sender
> > > > > >> [ 5] 0.00-10.07 sec 19.8 MBytes 16.5 Mbits/sec
> > > > > >>receiver
> > > > > >>
> > > > > >> [ 5] 0.00-10.00 sec 21.4 MBytes 18.0 Mbits/sec0
> > > > > >>sender
> > > > > >> [ 5] 0.00-10.04 sec 21.2 MBytes 17.7 Mbits/sec
> > > > > >>receiver
> > > > > >>
>
Re: [OpenWrt-Devel] [PATCH] ath10k: reset chip after supported check
Tom Psyborg, check the bottom of this mail, it has the patch in it.
Thanks,
Ben
On 03/25/2019 02:34 PM, Michał Kazior wrote:
On Mon, 25 Mar 2019 at 21:23, Ben Greear wrote:
On 3/25/19 1:08 PM, Michał Kazior wrote:
On Mon, 25 Mar 2019 at 16:55, Ben Greear wrote:
On 3/25/19 5:14 AM, Michał Kazior wrote:
On Sat, 23 Mar 2019 at 08:20, Arend Van Spriel
wrote:
* resending with corrected email address from Kalle
+ Michał
Thanks!
On 3/22/2019 8:25 PM, Christian Lamparter wrote:
> On Friday, March 22, 2019 7:58:40 PM CET Tomislav Požega wrote:
>> When chip reset is done before the chip is checked if supported
>> there will be crash. Previous behaviour caused bootloops on
>> Archer C7 v1 units, this patch allows clean device boot without
>> excluding ath10k driver.
Can you elaborate more a bit? What kind of crashes are you seeing?
What does the bootloop look like? Do you have uart connected to
diagnose?
Didn't C7 v1 have the old QCA9880 hw v1 which isn't really supported
by ath10k? I recall the v1 chip was really buggy and required
hammering registers sometimes to get things working.
The crash is related to the v1 chip. Is there a good way to detect
that this is the chip in question and only apply this work-around
for the problem chip?
I don't know of any good way to do that.
You could consider device-tree but that would be no different from
having a module blacklist in the C7v1 build recipe, or to not build
the module at all. That is unless you actually want to make v1 chip
work with ath10k at which point there's more fun to be had before it
can actually work.
I remember v1, and I have no interest in trying to make it work :)
If we could blacklist certain pci slots in the ath10k driver, I guess
that would work?
I think the goal is to not use the v1 chip, but allow users to add a
v2 NIC to the platform, so driver still needs to load.
That makes sense, but I don't see how blacklisting pci slots would
help someone putting v2 nic into C7v1 mobo? Won't the slot be the same
regardless what nic is put?
The best thing I can come up with is something like this:
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -3629,6 +3629,19 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
goto err_deinit_irq;
}
+ if (hw_rev == ATH10K_HW_QCA988X) {
+ /* v1 can crash the system on chip_reset()
+* so all we can do is keep our fingers
+* crossed v2 never reports 0 without a
+* chip_reset()
+*/
+ if (ath10k_pci_soc_read32(ar, SOC_CHIP_ID_ADDRESS) == 0) {
+ ath10k_err(ar, "qca9880 v1 is chip not supported");
+ ret = -ENOTSUP;
+ goto err_free_irq;
+ }
+ }
+
ret = ath10k_pci_chip_reset(ar);
if (ret) {
ath10k_err(ar, "failed to reset chip: %d\n", ret);
I didn't test it. Someone needs to compile and test and make sure v2
doesn't regress when fw hangs and cold & warm host cpu resets are
mixed in.
Michał
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/3] mac80211: ath10k: reset chip after supported check
On 01/04/2019, Ben Greear wrote: >> please provide link. i did not get such patch in my inbox > > I forwarded it separately. If that fixes the problem, then I think it has > a decent change of being accepted upstream (as well as into my ath10k-ct > repo). forwarded to where?!? i can't find it on mailiing lists archive of both openwrt and linux-wireless. post it here >>> If you want to put in a hack like this for a particular platform, maybe >>> make it specific to that one platform so you don't risk instability on >>> a wide range of systems? >> >> since other devices use ath10k-ct i decided to switch to ath10k only >> on this specific platform so it shouldn't be a problem > > Just because some platforms use ath10k-ct as a default doesn't mean that > users > don't change the defaults and use the stock driver. i post this mainly to be included for upcoming release, so when you download image there is no need to install ath10k manually. users that change defaults and build own images will for sure find their way around in case something goes wrong. if there is no test results proving something is very wrong with this change i'd like to ask to stop speculations about consistency of this change. after all it doesn't even concern ath10k-ct driver/fw bootlog with QCA9880-AR1A: [0.00] Linux version 4.9.111 (ubuntu@ubuntu) (gcc version 7.3.0 (OpenWrt GCC 7.3.0 r7410-d3a7587) ) #0 Sat Jul 7 12:53:26 2018 [0.00] bootconsole [early0] enabled [0.00] CPU0 revision is: 00019750 (MIPS 74Kc) [0.00] SoC: Qualcomm Atheros QCA9558 ver 1 rev 0 [0.00] Determined physical RAM map: [0.00] memory: 0800 @ (usable) [0.00] Initrd not found or empty - disabling initrd [0.00] Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes. [0.00] Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 bytes [0.00] Zone ranges: [0.00] Normal [mem 0x-0x07ff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x-0x07ff] [0.00] Initmem setup node 0 [mem 0x-0x07ff] [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 [0.00] Kernel command line: board=ARCHER-C7 console=ttyS0,115200 rootfstype=squashfs,jffs2 noinitrd [0.00] PID hash table entries: 512 (order: -1, 2048 bytes) [0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) [0.00] Writing ErrCtl register= [0.00] Readback ErrCtl register= [0.00] Memory: 119372K/131072K available (3044K kernel code, 232K rwdata, 1012K rodata, 5624K init, 211K bss, 11700K reserved, 0K cma-reserved) [0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [0.00] NR_IRQS:51 [0.00] Clocks: CPU:720.000MHz, DDR:600.000MHz, AHB:200.000MHz, Ref:40.000MHz [0.00] clocksource: MIPS: mask: 0x max_cycles: 0x, max_idle_ns: 5309056796 ns [0.08] sched_clock: 32 bits at 360MHz, resolution 2ns, wraps every 5965232126ns [0.008279] Calibrating delay loop... 358.80 BogoMIPS (lpj=1794048) [0.071187] pid_max: default: 32768 minimum: 301 [0.076191] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) [0.083230] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes) [0.092718] clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 1911260446275 ns [0.103215] futex hash table entries: 256 (order: -1, 3072 bytes) [0.110162] NET: Registered protocol family 16 [0.116058] MIPS: machine is TP-LINK Archer C7 [0.123871] ar724x-pci ar724x-pci.0: PCIe link is down [0.129373] registering PCI controller with io_map_base unset [0.135596] registering PCI controller with io_map_base unset [0.632703] PCI host bridge to bus :00 [0.637073] pci_bus :00: root bus resource [mem 0x1000-0x11ff] [0.644418] pci_bus :00: root bus resource [io 0x] [0.650347] pci_bus :00: root bus resource [??? 0x flags 0x0] [0.657572] pci_bus :00: No busn resource found for root bus, will use [bus 00-ff] [0.666114] PCI host bridge to bus :01 [0.670488] pci_bus :01: root bus resource [mem 0x1200-0x13ff] [0.677797] pci_bus :01: root bus resource [io 0x0001] [0.683740] pci_bus :01: root bus resource [??? 0x flags 0x0] [0.690959] pci_bus :01: No busn resource found for root bus, will use [bus 01-ff] [0.699774] pci :01:00.0: BAR 0: assigned [mem 0x1200-0x121f 64bit] [0.707567] pci :01:00.0: BAR 6: assigned [mem 0x1220-0x1220 pref] [0.715275] pci :01:00.0: using irq 41 for pin 1 [0.721087] clocksource: Sw
Re: [OpenWrt-Devel] [PATCH v2] ath79: add support for OCEDO Ursus
markus.sche...@gmail.com [2019-03-21 16:43:27]:
Hi,
> + label = "ursus:green:wlan2";
> + label = "ursus:green:wlan5";
could we please make it wlan2g and wlan5g in order to stay consistent?
I found this old PR[1] for ar71xx, which makes me wonder if the stuff bellow
is correct.
> +&mdio0 {
> + status = "okay";
> +
> + phy1: ethernet-phy@1 {
> + reg = <1>;
> + };
> +
In that ar71xx code it seems, that phy2 is connected through GMAC1/SGMII. Can
you please explain in your commit message what is connected where in more
details?
> + phy2: ethernet-phy@2 {
> + reg = <2>;
> + };
> +};
> +
> +ð0 {
> + status = "okay";
add newline here
> + mtd-mac-address = <&art 0x00>;
> + phy-handle = <&phy1>;
> + pll-data = <0xa600 0x8101 0x80001313>;
pll-data = <0xae00 0xa101 0xa0001313>;
what is expected phy-mode here?
> +ð1 {
> + status = "okay";
add newline here
> + mtd-mac-address = <&art 0x12>;
mtd-mac-address = <&art 0xc>; ?
> + phy-handle = <&phy2>;
> + pll-data = <0x3000101 0x101 0x1313>;
what is expected phy-mode here?
pll-data = <0x030 0x101 0x1313>;
1.
https://github.com/openwrt/openwrt/pull/1016/commits/6bc138ec46ce956783aba7f8c83608982030a8be
-- ynezz
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/3] mac80211: ath10k: reset chip after supported check
On 4/1/19 2:07 PM, Tom Psyborg wrote: On 01/04/2019, Ben Greear wrote: On 4/1/19 1:32 PM, Tomislav Požega wrote: When chip reset is done before the chip is checked if supported there will be crash. Previous behaviour caused bootloops on Archer C7 v1 units, this patch allows clean device boot without excluding ath10k driver. Did you try the patch that Michal posted that checks the chip version ID and so might be a good and safe fix for all chips? please provide link. i did not get such patch in my inbox I forwarded it separately. If that fixes the problem, then I think it has a decent change of being accepted upstream (as well as into my ath10k-ct repo). If you want to put in a hack like this for a particular platform, maybe make it specific to that one platform so you don't risk instability on a wide range of systems? since other devices use ath10k-ct i decided to switch to ath10k only on this specific platform so it shouldn't be a problem Just because some platforms use ath10k-ct as a default doesn't mean that users don't change the defaults and use the stock driver. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/3] mac80211: ath10k: reset chip after supported check
On 01/04/2019, Ben Greear wrote: > On 4/1/19 1:32 PM, Tomislav Požega wrote: >> When chip reset is done before the chip is checked if supported >> there will be crash. Previous behaviour caused bootloops on >> Archer C7 v1 units, this patch allows clean device boot without >> excluding ath10k driver. > > Did you try the patch that Michal posted that checks the chip version > ID and so might be a good and safe fix for all chips? please provide link. i did not get such patch in my inbox > If you want to put in a hack like this for a particular platform, maybe > make it specific to that one platform so you don't risk instability on > a wide range of systems? since other devices use ath10k-ct i decided to switch to ath10k only on this specific platform so it shouldn't be a problem ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/3] mac80211: ath10k: reset chip after supported check
On 4/1/19 1:32 PM, Tomislav Požega wrote:
When chip reset is done before the chip is checked if supported
there will be crash. Previous behaviour caused bootloops on
Archer C7 v1 units, this patch allows clean device boot without
excluding ath10k driver.
Did you try the patch that Michal posted that checks the chip version
ID and so might be a good and safe fix for all chips?
If you want to put in a hack like this for a particular platform, maybe
make it specific to that one platform so you don't risk instability on
a wide range of systems?
Thanks,
Ben
Signed-off-by: Tomislav Požega
---
...0-ath10k-reset-chip-after-supported-check.patch | 39
1 files changed, 39 insertions(+), 0 deletions(-)
create mode 100644
package/kernel/mac80211/patches/ath/980-ath10k-reset-chip-after-supported-check.patch
diff --git
a/package/kernel/mac80211/patches/ath/980-ath10k-reset-chip-after-supported-check.patch
b/package/kernel/mac80211/patches/ath/980-ath10k-reset-chip-after-supported-check.patch
new file mode 100644
index 000..81ca5e1
--- /dev/null
+++
b/package/kernel/mac80211/patches/ath/980-ath10k-reset-chip-after-supported-check.patch
@@ -0,0 +1,39 @@
+From: Tomislav Požega
+Date: Fri, 22 Mar 2019 19:06:25 +0100
+Subject: [PATCH] ath10k: reset chip after supported check
+
+When chip reset is done before the chip is checked if supported
+there will be crash. Previous behaviour caused bootloops on
+Archer C7 v1 units, this patch allows clean device boot without
+excluding ath10k driver.
+
+Signed-off-by: Tomislav Požega
+
+--- a/drivers/net/wireless/ath/ath10k/pci.c
b/drivers/net/wireless/ath/ath10k/pci.c
+@@ -3612,12 +3612,6 @@ static int ath10k_pci_probe(struct pci_d
+ goto err_deinit_irq;
+ }
+
+- ret = ath10k_pci_chip_reset(ar);
+- if (ret) {
+- ath10k_err(ar, "failed to reset chip: %d\n", ret);
+- goto err_free_irq;
+- }
+-
+ chip_id = ath10k_pci_soc_read32(ar, SOC_CHIP_ID_ADDRESS);
+ if (chip_id == 0x) {
+ ath10k_err(ar, "failed to get chip id\n");
+@@ -3630,6 +3624,12 @@ static int ath10k_pci_probe(struct pci_d
+ goto err_free_irq;
+ }
+
++ ret = ath10k_pci_chip_reset(ar);
++ if (ret) {
++ ath10k_err(ar, "failed to reset chip: %d\n", ret);
++ goto err_free_irq;
++ }
++
+ ret = ath10k_core_register(ar, chip_id);
+ if (ret) {
+ ath10k_err(ar, "failed to register driver core: %d\n", ret);
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 3/3] mac80211: ath10k: reset chip after supported check
When chip reset is done before the chip is checked if supported
there will be crash. Previous behaviour caused bootloops on
Archer C7 v1 units, this patch allows clean device boot without
excluding ath10k driver.
Signed-off-by: Tomislav Požega
---
...0-ath10k-reset-chip-after-supported-check.patch | 39
1 files changed, 39 insertions(+), 0 deletions(-)
create mode 100644
package/kernel/mac80211/patches/ath/980-ath10k-reset-chip-after-supported-check.patch
diff --git
a/package/kernel/mac80211/patches/ath/980-ath10k-reset-chip-after-supported-check.patch
b/package/kernel/mac80211/patches/ath/980-ath10k-reset-chip-after-supported-check.patch
new file mode 100644
index 000..81ca5e1
--- /dev/null
+++
b/package/kernel/mac80211/patches/ath/980-ath10k-reset-chip-after-supported-check.patch
@@ -0,0 +1,39 @@
+From: Tomislav Požega
+Date: Fri, 22 Mar 2019 19:06:25 +0100
+Subject: [PATCH] ath10k: reset chip after supported check
+
+When chip reset is done before the chip is checked if supported
+there will be crash. Previous behaviour caused bootloops on
+Archer C7 v1 units, this patch allows clean device boot without
+excluding ath10k driver.
+
+Signed-off-by: Tomislav Požega
+
+--- a/drivers/net/wireless/ath/ath10k/pci.c
b/drivers/net/wireless/ath/ath10k/pci.c
+@@ -3612,12 +3612,6 @@ static int ath10k_pci_probe(struct pci_d
+ goto err_deinit_irq;
+ }
+
+- ret = ath10k_pci_chip_reset(ar);
+- if (ret) {
+- ath10k_err(ar, "failed to reset chip: %d\n", ret);
+- goto err_free_irq;
+- }
+-
+ chip_id = ath10k_pci_soc_read32(ar, SOC_CHIP_ID_ADDRESS);
+ if (chip_id == 0x) {
+ ath10k_err(ar, "failed to get chip id\n");
+@@ -3630,6 +3624,12 @@ static int ath10k_pci_probe(struct pci_d
+ goto err_free_irq;
+ }
+
++ ret = ath10k_pci_chip_reset(ar);
++ if (ret) {
++ ath10k_err(ar, "failed to reset chip: %d\n", ret);
++ goto err_free_irq;
++ }
++
+ ret = ath10k_core_register(ar, chip_id);
+ if (ret) {
+ ath10k_err(ar, "failed to register driver core: %d\n", ret);
--
1.7.0.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/3] ath79: switch back to ath10k driver and firmware
Switch Archer C7 v1 back to regular ath10k driver and firmware since it contains fix for bootloop issue present with QCA9880-AR1A. Signed-off-by: Tomislav Požega --- target/linux/ath79/image/generic-tp-link.mk |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/target/linux/ath79/image/generic-tp-link.mk b/target/linux/ath79/image/generic-tp-link.mk index 19a156b..2642f16 100644 --- a/target/linux/ath79/image/generic-tp-link.mk +++ b/target/linux/ath79/image/generic-tp-link.mk @@ -68,7 +68,7 @@ define Device/tplink_archer-c7-v1 $(Device/tplink-8mlzma) ATH_SOC := qca9558 DEVICE_TITLE := TP-Link Archer C7 v1 - DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-ledtrig-usbport kmod-ath10k-ct ath10k-firmware-qca988x-ct + DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-ledtrig-usbport kmod-ath10k ath10k-firmware-qca988x TPLINK_HWID := 0x7501 endef TARGET_DEVICES += tplink_archer-c7-v1 -- 1.7.0.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/3] ar71xx: add ath10k package for Archer C7 v1
This series patch fixes bootloop issue and device starts normally with QCA9880-AR1A in mPCIe slot. Another card tested is QCA9862 and is detected and starts properly. Signed-off-by: Tomislav Požega --- target/linux/ar71xx/image/generic-tp-link.mk |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/target/linux/ar71xx/image/generic-tp-link.mk b/target/linux/ar71xx/image/generic-tp-link.mk index 6fda7f3..d4345e2 100644 --- a/target/linux/ar71xx/image/generic-tp-link.mk +++ b/target/linux/ar71xx/image/generic-tp-link.mk @@ -95,7 +95,7 @@ TARGET_DEVICES += archer-c5-v1 define Device/archer-c7-v1 $(Device/tplink-8mlzma) DEVICE_TITLE := TP-LINK Archer C7 v1 - DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-ledtrig-usbport + DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-ledtrig-usbport kmod-ath10k ath10k-firmware-qca988x BOARDNAME := ARCHER-C7 DEVICE_PROFILE := ARCHERC7 TPLINK_HWID := 0x7501 -- 1.7.0.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v4 7/7] tegra: add kernel 4.19 support
Signed-off-by: Tomasz Maciej Nowak --- target/linux/generic/config-4.19 | 1 + target/linux/tegra/config-4.19| 558 ++ ...interrupts-due-to-tegra2-silicon-bug.patch | 77 +++ ...enable-front-panel-leds-in-TrimSlice.patch | 46 ++ 4 files changed, 682 insertions(+) create mode 100644 target/linux/tegra/config-4.19 create mode 100644 target/linux/tegra/patches-4.19/100-serial8250-on-tegra-hsuart-recover-from-spurious-interrupts-due-to-tegra2-silicon-bug.patch create mode 100644 target/linux/tegra/patches-4.19/101-ARM-dtc-tegra-enable-front-panel-leds-in-TrimSlice.patch diff --git a/target/linux/generic/config-4.19 b/target/linux/generic/config-4.19 index 288c2c5836..e187241567 100644 --- a/target/linux/generic/config-4.19 +++ b/target/linux/generic/config-4.19 @@ -2397,6 +2397,7 @@ CONFIG_KERNFS=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_TCA6416 is not set # CONFIG_KEYBOARD_TCA8418 is not set +# CONFIG_KEYBOARD_TEGRA is not set # CONFIG_KEYBOARD_TM2_TOUCHKEY is not set # CONFIG_KEYBOARD_TWL4030 is not set # CONFIG_KEYBOARD_XTKBD is not set diff --git a/target/linux/tegra/config-4.19 b/target/linux/tegra/config-4.19 new file mode 100644 index 00..b42958a943 --- /dev/null +++ b/target/linux/tegra/config-4.19 @@ -0,0 +1,558 @@ +CONFIG_AC97_BUS=y +# CONFIG_AHCI_TEGRA is not set +CONFIG_ALIGNMENT_TRAP=y +CONFIG_ARCH_CLOCKSOURCE_DATA=y +CONFIG_ARCH_HAS_DEBUG_VIRTUAL=y +CONFIG_ARCH_HAS_ELF_RANDOMIZE=y +CONFIG_ARCH_HAS_FORTIFY_SOURCE=y +CONFIG_ARCH_HAS_GCOV_PROFILE_ALL=y +CONFIG_ARCH_HAS_KCOV=y +CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE=y +CONFIG_ARCH_HAS_PHYS_TO_DMA=y +CONFIG_ARCH_HAS_RESET_CONTROLLER=y +CONFIG_ARCH_HAS_SET_MEMORY=y +CONFIG_ARCH_HAS_SG_CHAIN=y +CONFIG_ARCH_HAS_STRICT_KERNEL_RWX=y +CONFIG_ARCH_HAS_STRICT_MODULE_RWX=y +CONFIG_ARCH_HAS_TICK_BROADCAST=y +CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y +CONFIG_ARCH_HIBERNATION_POSSIBLE=y +CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y +CONFIG_ARCH_MULTIPLATFORM=y +CONFIG_ARCH_MULTI_V6_V7=y +CONFIG_ARCH_MULTI_V7=y +CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED=y +CONFIG_ARCH_NR_GPIO=1024 +CONFIG_ARCH_OPTIONAL_KERNEL_RWX=y +CONFIG_ARCH_OPTIONAL_KERNEL_RWX_DEFAULT=y +CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y +CONFIG_ARCH_SUPPORTS_FIRMWARE=y +CONFIG_ARCH_SUPPORTS_TRUSTED_FOUNDATIONS=y +CONFIG_ARCH_SUPPORTS_UPROBES=y +CONFIG_ARCH_SUSPEND_POSSIBLE=y +CONFIG_ARCH_TEGRA=y +# CONFIG_ARCH_TEGRA_114_SOC is not set +# CONFIG_ARCH_TEGRA_124_SOC is not set +CONFIG_ARCH_TEGRA_2x_SOC=y +# CONFIG_ARCH_TEGRA_3x_SOC is not set +CONFIG_ARCH_USE_BUILTIN_BSWAP=y +CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y +CONFIG_ARCH_WANT_GENERAL_HUGETLB=y +CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y +CONFIG_ARM=y +CONFIG_ARM_AMBA=y +CONFIG_ARM_ARCH_TIMER=y +CONFIG_ARM_ARCH_TIMER_EVTSTREAM=y +CONFIG_ARM_CPU_SUSPEND=y +CONFIG_ARM_CRYPTO=y +CONFIG_ARM_ERRATA_720789=y +CONFIG_ARM_ERRATA_754327=y +CONFIG_ARM_ERRATA_764369=y +CONFIG_ARM_GIC=y +CONFIG_ARM_HAS_SG_CHAIN=y +CONFIG_ARM_HEAVY_MB=y +CONFIG_ARM_L1_CACHE_SHIFT=6 +CONFIG_ARM_L1_CACHE_SHIFT_6=y +# CONFIG_ARM_LPAE is not set +CONFIG_ARM_PATCH_IDIV=y +CONFIG_ARM_PATCH_PHYS_VIRT=y +# CONFIG_ARM_PL172_MPMC is not set +# CONFIG_ARM_SMMU is not set +# CONFIG_ARM_SP805_WATCHDOG is not set +CONFIG_ARM_TEGRA20_CPUFREQ=y +CONFIG_ARM_THUMB=y +CONFIG_ARM_THUMBEE=y +CONFIG_ARM_VIRT_EXT=y +CONFIG_ASN1=y +CONFIG_ATA=y +CONFIG_ATAGS=y +CONFIG_AUTO_ZRELADDR=y +CONFIG_BLK_DEV_BSG=y +CONFIG_BLK_DEV_LOOP=y +CONFIG_BLK_MQ_PCI=y +CONFIG_BLK_SCSI_REQUEST=y +CONFIG_BOUNCE=y +CONFIG_CACHE_L2X0=y +CONFIG_CLKDEV_LOOKUP=y +CONFIG_CLKSRC_MMIO=y +CONFIG_CLONE_BACKWARDS=y +CONFIG_CLZ_TAB=y +CONFIG_CMA=y +CONFIG_CMA_ALIGNMENT=8 +CONFIG_CMA_AREAS=7 +# CONFIG_CMA_DEBUG is not set +# CONFIG_CMA_DEBUGFS is not set +CONFIG_CMA_SIZE_MBYTES=16 +# CONFIG_CMA_SIZE_SEL_MAX is not set +CONFIG_CMA_SIZE_SEL_MBYTES=y +# CONFIG_CMA_SIZE_SEL_MIN is not set +# CONFIG_CMA_SIZE_SEL_PERCENTAGE is not set +CONFIG_COMMON_CLK=y +# CONFIG_CPUFREQ_DT is not set +CONFIG_CPU_32v6K=y +CONFIG_CPU_32v7=y +CONFIG_CPU_ABRT_EV7=y +# CONFIG_CPU_BPREDICT_DISABLE is not set +CONFIG_CPU_CACHE_V7=y +CONFIG_CPU_CACHE_VIPT=y +CONFIG_CPU_COPY_V6=y +CONFIG_CPU_CP15=y +CONFIG_CPU_CP15_MMU=y +CONFIG_CPU_FREQ=y +CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y +# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set +CONFIG_CPU_FREQ_GOV_ATTR_SET=y +CONFIG_CPU_FREQ_GOV_COMMON=y +CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y +CONFIG_CPU_FREQ_GOV_ONDEMAND=y +CONFIG_CPU_FREQ_GOV_PERFORMANCE=y +CONFIG_CPU_FREQ_GOV_POWERSAVE=y +CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y +CONFIG_CPU_FREQ_GOV_USERSPACE=y +# CONFIG_CPU_FREQ_STAT is not set +CONFIG_CPU_HAS_ASID=y +# CONFIG_CPU_HOTPLUG_STATE_CONTROL is not set +# CONFIG_CPU_ICACHE_DISABLE is not set +CONFIG_CPU_IDLE=y +CONFIG_CPU_IDLE_GOV_LADDER=y +CONFIG_CPU_PABRT_V7=y +CONFIG_CPU_PM=y +CONFIG_CPU_RMAP=y +CONFIG_CPU_SPECTRE=y +CONFIG_CPU_THUMB_CAPABLE=y +CONFIG_CPU_TLB_V7=y +CONFIG_CPU_V7=y +CONFIG_CRC16=y +# CONFIG_CRC32_SARWATE is not set +CONFIG_CRC32_SLICEBY8=y +CONFIG_CROSS_MEMORY_ATTAC
[OpenWrt-Devel] [PATCH v4 1/7] tegra: add new target
New target introduces initial support for NVIDIA Tegra SoC based devices. It focuses on Tegra 2 CPUs, for successors supporting NEON instruction set the target should be split in two subtargets. This initial commit doesn't create any device image, it's groundwork for further additions. Signed-off-by: Tomasz Maciej Nowak --- package/kernel/linux/modules/netdevices.mk| 4 +- target/linux/generic/config-4.14 | 2 + target/linux/tegra/Makefile | 29 + target/linux/tegra/base-files/etc/inittab | 4 + .../base-files/lib/preinit/79_move_config | 22 + .../tegra/base-files/lib/upgrade/platform.sh | 103 target/linux/tegra/config-4.14| 556 ++ target/linux/tegra/image/Makefile | 47 ++ target/linux/tegra/image/generic-bootscript | 6 + ...interrupts-due-to-tegra2-silicon-bug.patch | 77 +++ 10 files changed, 848 insertions(+), 2 deletions(-) create mode 100644 target/linux/tegra/Makefile create mode 100644 target/linux/tegra/base-files/etc/inittab create mode 100644 target/linux/tegra/base-files/lib/preinit/79_move_config create mode 100644 target/linux/tegra/base-files/lib/upgrade/platform.sh create mode 100644 target/linux/tegra/config-4.14 create mode 100644 target/linux/tegra/image/Makefile create mode 100644 target/linux/tegra/image/generic-bootscript create mode 100644 target/linux/tegra/patches-4.14/100-serial8250-on-tegra-hsuart-recover-from-spurious-interrupts-due-to-tegra2-silicon-bug.patch diff --git a/package/kernel/linux/modules/netdevices.mk b/package/kernel/linux/modules/netdevices.mk index fbc24b8405..2e29a5441f 100644 --- a/package/kernel/linux/modules/netdevices.mk +++ b/package/kernel/linux/modules/netdevices.mk @@ -113,7 +113,7 @@ $(eval $(call KernelPackage,mii)) define KernelPackage/mdio-gpio SUBMENU:=$(NETWORK_DEVICES_MENU) TITLE:= Supports GPIO lib-based MDIO busses - DEPENDS:=+kmod-libphy @GPIO_SUPPORT +(TARGET_armvirt||TARGET_brcm2708_bcm2708||TARGET_samsung):kmod-of-mdio + DEPENDS:=+kmod-libphy @GPIO_SUPPORT +(TARGET_armvirt||TARGET_brcm2708_bcm2708||TARGET_samsung||TARGET_tegra):kmod-of-mdio KCONFIG:= \ CONFIG_MDIO_BITBANG \ CONFIG_MDIO_GPIO @@ -261,7 +261,7 @@ $(eval $(call KernelPackage,switch-rtl8306)) define KernelPackage/switch-rtl8366-smi SUBMENU:=$(NETWORK_DEVICES_MENU) TITLE:=Realtek RTL8366 SMI switch interface support - DEPENDS:=@GPIO_SUPPORT +kmod-swconfig +(TARGET_armvirt||TARGET_brcm2708_bcm2708||TARGET_samsung):kmod-of-mdio + DEPENDS:=@GPIO_SUPPORT +kmod-swconfig +(TARGET_armvirt||TARGET_brcm2708_bcm2708||TARGET_samsung||TARGET_tegra):kmod-of-mdio KCONFIG:=CONFIG_RTL8366_SMI FILES:=$(LINUX_DIR)/drivers/net/phy/rtl8366_smi.ko AUTOLOAD:=$(call AutoLoad,42,rtl8366_smi) diff --git a/target/linux/generic/config-4.14 b/target/linux/generic/config-4.14 index cabdd9d01d..b8f46c0e8c 100644 --- a/target/linux/generic/config-4.14 +++ b/target/linux/generic/config-4.14 @@ -2280,6 +2280,7 @@ CONFIG_KERNFS=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_TCA6416 is not set # CONFIG_KEYBOARD_TCA8418 is not set +# CONFIG_KEYBOARD_TEGRA is not set # CONFIG_KEYBOARD_TM2_TOUCHKEY is not set # CONFIG_KEYBOARD_TWL4030 is not set # CONFIG_KEYBOARD_XTKBD is not set @@ -5498,6 +5499,7 @@ CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV=y # CONFIG_USB_WUSB is not set # CONFIG_USB_WUSB_CBAF is not set # CONFIG_USB_XHCI_HCD is not set +# CONFIG_USB_XHCI_TEGRA is not set # CONFIG_USB_XUSBATM is not set # CONFIG_USB_YUREX is not set # CONFIG_USB_ZD1201 is not set diff --git a/target/linux/tegra/Makefile b/target/linux/tegra/Makefile new file mode 100644 index 00..57cb902cfd --- /dev/null +++ b/target/linux/tegra/Makefile @@ -0,0 +1,29 @@ +# +# Copyright (C) 2017-2019 Tomasz Maciej Nowak +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# +include $(TOPDIR)/rules.mk + +ARCH := arm +BOARD := tegra +BOARDNAME := NVIDIA Tegra +FEATURES := audio boot-part display ext4 fpu gpio pci pcie rootfs-part rtc squashfs usb +CPU_TYPE := cortex-a9 +CPU_SUBTYPE := vfpv3 +MAINTAINER := Tomasz Maciej Nowak + +KERNEL_PATCHVER := 4.14 + +include $(INCLUDE_DIR)/target.mk + +KERNELNAME := zImage dtbs + +DEFAULT_PACKAGES += e2fsprogs mkf2fs partx-utils + +define Target/Description + Build firmware image for NVIDIA Tegra SoC devices. +endef + +$(eval $(call BuildTarget)) diff --git a/target/linux/tegra/base-files/etc/inittab b/target/linux/tegra/base-files/etc/inittab new file mode 100644 index 00..b944a93ada --- /dev/null +++ b/target/linux/tegra/base-files/etc/inittab @@ -0,0 +1,4 @@ +::sysinit:/etc/init.d/rcS S boot +::shutdown:/etc/init.d/rcS K shutdown +::askconsole:/usr/libexec/login.sh +tty1::askfirst:/usr/libexec/login.sh diff --git a/target/linux/tegra/base-files/lib/preinit/79_move_config b/target/linux/tegra/base-files/lib/preinit/79_move_config new
[OpenWrt-Devel] [PATCH v4 2/7] tools: add cbootimage for tegra
Tegra BCT and bootable flash image generator/compiler >From documentation: This project provides a tool which compiles BCT (Boot Configuration Table) images to place into the boot flash of a Tegra-based device. The tool will either: a) Compile a textual representation of a BCT into a binary image. b) Generate an entire boot image from a previously compiled BCT and a bootloader binary. Signed-off-by: Tomasz Maciej Nowak --- tools/Makefile| 2 ++ tools/cbootimage/Makefile | 31 +++ 2 files changed, 33 insertions(+) create mode 100644 tools/cbootimage/Makefile diff --git a/tools/Makefile b/tools/Makefile index f7ff2db361..182821e66d 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -38,6 +38,7 @@ tools-$(BUILD_B43_TOOLS) += b43-tools tools-$(BUILD_ISL) += isl tools-$(CONFIG_USE_SPARSE) += sparse tools-$(CONFIG_TARGET_apm821xx)$(CONFIG_TARGET_gemini) += genext2fs +tools-$(CONFIG_TARGET_tegra) += cbootimage # builddir dependencies $(curdir)/bison/compile := $(curdir)/flex/compile @@ -76,6 +77,7 @@ $(curdir)/zlib/compile := $(curdir)/cmake/compile $(curdir)/wrt350nv2-builder/compile := $(curdir)/zlib/compile $(curdir)/lzma-old/compile := $(curdir)/zlib/compile $(curdir)/make-ext4fs/compile := $(curdir)/zlib/compile +$(curdir)/cbootimage/compile += $(curdir)/autoconf/compile ifneq ($(HOST_OS),Linux) $(curdir)/squashfskit4/compile += $(curdir)/coreutils/compile diff --git a/tools/cbootimage/Makefile b/tools/cbootimage/Makefile new file mode 100644 index 00..42640eab36 --- /dev/null +++ b/tools/cbootimage/Makefile @@ -0,0 +1,31 @@ +# +# Copyright (c) 2017-2019 Tomasz Maciej Nowak +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# +include $(TOPDIR)/rules.mk + +PKG_NAME := cbootimage +PKG_VERSION := 1.8 + +PKG_SOURCE_PROTO := git +PKG_SOURCE_URL := https://github.com/NVIDIA/cbootimage.git +PKG_SOURCE_VERSION := 7c9db585d06cce9efffa2a82245f233233680060 +PKG_MIRROR_HASH := 84d9abaaa3eddde05f506dc16effe1c9e18eb94727ed59c5e0a879baeb04e0b2 + +HOST_BUILD_PARALLEL := 1 + +include $(INCLUDE_DIR)/host-build.mk + +define Host/Configure + (cd $(HOST_BUILD_DIR); autoreconf --install --symlink) + $(call Host/Configure/Default) +endef + +define Host/Clean + rm -f $(STAGING_DIR_HOST)/bin/$(PKG_NAME) \ + $(STAGING_DIR_HOST)/share/man/man1/$(PKG_NAME).1 +endef + +$(eval $(call HostBuild)) -- 2.21.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v4 4/7] uboot-tegra: add U-Boot for tegra boards
Add U-Boot for NVIDIA Tegra based boards, with the first being CompuLab
TrimSlice. This is part of initial support for this board.
Signed-off-by: Tomasz Maciej Nowak
---
package/boot/uboot-tegra/Makefile | 64 +++
.../tegra/base-files/lib/upgrade/platform.sh | 2 +
target/linux/tegra/image/Makefile | 4 +-
3 files changed, 69 insertions(+), 1 deletion(-)
create mode 100644 package/boot/uboot-tegra/Makefile
diff --git a/package/boot/uboot-tegra/Makefile
b/package/boot/uboot-tegra/Makefile
new file mode 100644
index 00..191d108771
--- /dev/null
+++ b/package/boot/uboot-tegra/Makefile
@@ -0,0 +1,64 @@
+#
+# Copyright (C) 2017-2019 Tomasz Maciej Nowak
+#
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE for more information.
+#
+include $(TOPDIR)/rules.mk
+
+PKG_VERSION := 2019.01
+PKG_RELEASE := 1
+
+PKG_HASH := 50bd7e5a466ab828914d080d5f6a432345b500e8fba1ad3b7b61e95e60d51c22
+
+PKG_MAINTAINER := Tomasz Maciej Nowak
+
+include $(INCLUDE_DIR)/u-boot.mk
+include $(INCLUDE_DIR)/package.mk
+
+define U-Boot/Default
+ BUILD_TARGET := tegra
+ HIDDEN := y
+endef
+
+define U-Boot/trimslice
+ NAME := CompuLab TrimSlice
+ BUILD_DEVICES := trimslice
+ UBOOT_IMAGE := trimslice-mmc.img trimslice-spi.img
+ SOC := tegra20
+ VENDOR := compulab
+endef
+
+UBOOT_TARGETS := trimslice
+
+define Build/bct-image
+ $(CP) $(PKG_BUILD_DIR)/u-boot-dtb-tegra.bin $(PKG_BUILD_DIR)/u-boot.bin
+ $(foreach bct,$(basename $(UBOOT_IMAGE)), \
+ cd $(PKG_BUILD_DIR); \
+ cbootimage -s $(SOC) -gbct \
+
$(STAGING_DIR_HOST)/share/cbootimage-configs/$(SOC)/$(VENDOR)/$(VARIANT)/$(bct).bct.cfg
\
+ $(bct).bct; \
+ cbootimage -s $(SOC) \
+
$(STAGING_DIR_HOST)/share/cbootimage-configs/$(SOC)/$(VENDOR)/$(VARIANT)/$(bct).img.cfg
\
+ $(PKG_BUILD_DIR)/$(bct).img; \
+ rm -f $(bct).bct; \
+ )
+endef
+
+define Build/Configure
+ sed '/select BINMAN/d' -i $(PKG_BUILD_DIR)/arch/arm/mach-tegra/Kconfig
+ $(call Build/Configure/U-Boot)
+endef
+
+define Build/Compile
+ $(call Build/Compile/U-Boot)
+ $(call Build/bct-image)
+endef
+
+define Build/InstallDev
+ $(INSTALL_DIR) $(STAGING_DIR_IMAGE)
+ $(foreach img,$(UBOOT_IMAGE), \
+ $(CP) $(PKG_BUILD_DIR)/$(img) $(STAGING_DIR_IMAGE)/;)
+endef
+
+$(eval $(call BuildPackage/U-Boot))
diff --git a/target/linux/tegra/base-files/lib/upgrade/platform.sh
b/target/linux/tegra/base-files/lib/upgrade/platform.sh
index be453bdf9f..97dd381041 100644
--- a/target/linux/tegra/base-files/lib/upgrade/platform.sh
+++ b/target/linux/tegra/base-files/lib/upgrade/platform.sh
@@ -87,6 +87,8 @@ platform_do_upgrade() {
return 0
fi
+ #write uboot image
+ get_image "$@" | dd of="$diskdev" bs=512 skip=1 seek=1 count=4097
conv=fsync,notrunc
#iterate over each partition from the image and write it to the boot
disk
while read part start size; do
if export_partdevice partdev $part; then
diff --git a/target/linux/tegra/image/Makefile
b/target/linux/tegra/image/Makefile
index 757e5b823f..5e3427ad27 100644
--- a/target/linux/tegra/image/Makefile
+++ b/target/linux/tegra/image/Makefile
@@ -32,9 +32,11 @@ define Build/tegra-sdcard
$(CONFIG_TARGET_KERNEL_PARTSIZE) $@.boot \
$(CONFIG_TARGET_ROOTFS_PARTSIZE) $(IMAGE_ROOTFS) \
2048
+
+ $(if $(UBOOT),dd if=$(STAGING_DIR_IMAGE)/$(UBOOT).img of=$@ bs=512
skip=1 seek=1 conv=notrunc)
endef
-DEVICE_VARS += BOOT_SCRIPT
+DEVICE_VARS += BOOT_SCRIPT UBOOT
define Device/Default
BOOT_SCRIPT := generic-bootscript
IMAGES := sdcard.img.gz
--
2.21.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v4 5/7] kernel: package rtc-em3027 module
Support for Microelectronic EM3027 real time clock chip. Signed-off-by: Tomasz Maciej Nowak --- package/kernel/linux/modules/other.mk | 18 ++ 1 file changed, 18 insertions(+) diff --git a/package/kernel/linux/modules/other.mk b/package/kernel/linux/modules/other.mk index 220452df9b..e279616f20 100644 --- a/package/kernel/linux/modules/other.mk +++ b/package/kernel/linux/modules/other.mk @@ -528,6 +528,24 @@ endef $(eval $(call KernelPackage,rtc-ds1672)) +define KernelPackage/rtc-em3027 + SUBMENU:=$(OTHER_MENU) + TITLE:=Microelectronic EM3027 RTC support + DEFAULT:=m if ALL_KMODS && RTC_SUPPORT + DEPENDS:=+kmod-i2c-core + KCONFIG:=CONFIG_RTC_DRV_EM3027 \ + CONFIG_RTC_CLASS=y + FILES:=$(LINUX_DIR)/drivers/rtc/rtc-em3027.ko + AUTOLOAD:=$(call AutoProbe,rtc-em3027) +endef + +define KernelPackage/rtc-em3027/description + Kernel module for Microelectronic EM3027 RTC. +endef + +$(eval $(call KernelPackage,rtc-em3027)) + + define KernelPackage/rtc-isl1208 SUBMENU:=$(OTHER_MENU) TITLE:=Intersil ISL1208 RTC support -- 2.21.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v4 3/7] tools: add cbootimage-configs for tegra
This provides board configuraion tables for various Tegra boards needed by cbootimage tool to create flashable bootloader images. Signed-off-by: Tomasz Maciej Nowak --- tools/Makefile| 2 +- tools/cbootimage-configs/Makefile | 32 +++ 2 files changed, 33 insertions(+), 1 deletion(-) create mode 100644 tools/cbootimage-configs/Makefile diff --git a/tools/Makefile b/tools/Makefile index 182821e66d..cee9c0bf8a 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -38,7 +38,7 @@ tools-$(BUILD_B43_TOOLS) += b43-tools tools-$(BUILD_ISL) += isl tools-$(CONFIG_USE_SPARSE) += sparse tools-$(CONFIG_TARGET_apm821xx)$(CONFIG_TARGET_gemini) += genext2fs -tools-$(CONFIG_TARGET_tegra) += cbootimage +tools-$(CONFIG_TARGET_tegra) += cbootimage cbootimage-configs # builddir dependencies $(curdir)/bison/compile := $(curdir)/flex/compile diff --git a/tools/cbootimage-configs/Makefile b/tools/cbootimage-configs/Makefile new file mode 100644 index 00..5a1fc568cb --- /dev/null +++ b/tools/cbootimage-configs/Makefile @@ -0,0 +1,32 @@ +# +# Copyright (c) 2017-2019 Tomasz Maciej Nowak +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# +include $(TOPDIR)/rules.mk + +PKG_NAME := cbootimage-configs + +PKG_SOURCE_DATE := 2017-04-13 +PKG_SOURCE_PROTO := git +PKG_SOURCE_URL := https://github.com/NVIDIA/cbootimage-configs.git +PKG_SOURCE_VERSION := 7c3b458b93ed6947cd083623f543e93f9103cc0f +PKG_MIRROR_HASH := 1d24421af8cf74ec2d625e237aa8121b1273774c4380ad333e2954e052a5a4fe + +include $(INCLUDE_DIR)/host-build.mk + +define Host/Compile +endef + +define Host/Install + $(INSTALL_DIR) $(STAGING_DIR_HOST)/share/$(PKG_NAME) + $(CP) $(HOST_BUILD_DIR)/* \ + $(STAGING_DIR_HOST)/share/$(PKG_NAME) +endef + +define Host/Clean + rm -fR $(STAGING_DIR_HOST)/share/$(PKG_NAME) +endef + +$(eval $(call HostBuild)) -- 2.21.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v4 6/7] tegra: add support for CompuLab TrimSlice
It is a small form factor computer with rich amount of expansion ports.
Some hardware specs and supported features in this commit:
CPU: NVIDIA Tegra 2 @ 1GHz
RAM: 1GB DDR2-667
Storage: SDHC card slot
µSDHC card slot
USB to SATA bridge (depends on model)
1MB SPI NOR flash for bootloader (single partition)
LAN: RTL8111DL GbE
WIFI: RT3070 b/g/n with external antenna (depends on model)
RTC: EM3027 (mapped as rtc0; with battery backup)
Tegra 2 built-in (mapped as rtc1)
Sound: Analog/Digital (TLV320AIC23b; S/PDIF not tested)
Connectors: 4x USB 2.0
RS232 (mini serial)
HDMI
DVI-D (depends on model, not supported atm)
Extension connector (24 pin ZIF, 0.5mm pitch):
2X UART
SPI
JTAG (1.8V)
Other: power button with green led (not functional for early revisions
without programmed PMIC)
2x GPIO configurable green led
TrimSlice uses U-Boot placed in NOR flash. Boots Linux from any media
connected to USB, SATA or SD card inserted in slot. Can also boot from
TFTP. To run OpenWrt one needs to update U-Boot to fairly recent version
(the versions, pre-dts/dts provided by CompuLab won't suffice):
1. Boot TrimSlice into Your current linux distro,
2. Download trimslice-spi.img from u-boot-trimslice subdir,
3. Install mtd-utils,
4. Run following commands:
flash_erase /dev/mtd0 0 256
nandwrite /dev/mtd0 trimslice-spi.img
5. Poweroff, insert SD card with OpenWrt, boot and enjoy.
If by some obstacle You can't follow those instructions, it is possible
to flash U-Boot using serial console.
1. Insert FAT or EXT2/EXT3 formatted SD card with trimslice-spi.img,
2. Interrupt boot process to enter U-Boot command line,
3. Run following commands:
${fs}load mmc 0 0x0408 trimslice-spi.img
sf probe 0
sf erase 0 0x10
sf write 0x0408 0x0 ${filesize}
reset
4. Poweroff, insert SD card with OpenWrt, boot and enjoy.
If something went wrong with one of above steps, there is simple
recovery option:
1. Open the µSD slot security door to access the recovery-boot button,
2. Insert SD card with OpenWrt to the front slot while unpowered,
3. Power on the TrimSlice while pressing the recovery-boot button,
4. With this it should boot straigth to OpenWrt, from there download
trimslice-spi.img and execute following commands:
mtd erase /dev/mtd0
mtd write trimslice-spi.img /dev/mtd0
5. Reboot, now it should boot straigth to OpenWrt, without pressing the
recovery-boot button, with proper U-Boot flashed.
Signed-off-by: Tomasz Maciej Nowak
---
target/linux/tegra/config-4.14| 4 +-
target/linux/tegra/image/Makefile | 10
...enable-front-panel-leds-in-TrimSlice.patch | 46 +++
3 files changed, 59 insertions(+), 1 deletion(-)
create mode 100644
target/linux/tegra/patches-4.14/101-ARM-dtc-tegra-enable-front-panel-leds-in-TrimSlice.patch
diff --git a/target/linux/tegra/config-4.14 b/target/linux/tegra/config-4.14
index 3df360d1fc..42547da301 100644
--- a/target/linux/tegra/config-4.14
+++ b/target/linux/tegra/config-4.14
@@ -482,10 +482,12 @@ CONFIG_SND_SOC_TEGRA20_SPDIF=y
# CONFIG_SND_SOC_TEGRA_RT5640 is not set
# CONFIG_SND_SOC_TEGRA_RT5677 is not set
# CONFIG_SND_SOC_TEGRA_SGTL5000 is not set
-# CONFIG_SND_SOC_TEGRA_TRIMSLICE is not set
+CONFIG_SND_SOC_TEGRA_TRIMSLICE=y
# CONFIG_SND_SOC_TEGRA_WM8753 is not set
# CONFIG_SND_SOC_TEGRA_WM8903 is not set
# CONFIG_SND_SOC_TEGRA_WM9712 is not set
+CONFIG_SND_SOC_TLV320AIC23=y
+CONFIG_SND_SOC_TLV320AIC23_I2C=y
# CONFIG_SND_USB is not set
CONFIG_SOC_BUS=y
CONFIG_SOC_TEGRA_FLOWCTRL=y
diff --git a/target/linux/tegra/image/Makefile
b/target/linux/tegra/image/Makefile
index 5e3427ad27..706cc65d92 100644
--- a/target/linux/tegra/image/Makefile
+++ b/target/linux/tegra/image/Makefile
@@ -46,4 +46,14 @@ define Device/Default
PROFILES := Default
endef
+define Device/trimslice
+ DEVICE_TITLE := CompuLab TrimSlice
+ DEVICE_DTS := tegra20-trimslice
+ DEVICE_PACKAGES := kmod-r8169 kmod-rt2800-usb kmod-rtc-em3027 \
+ kmod-usb-storage wpad-mini
+ SUPPORTED_DEVICES := compulab,trimslice
+ UBOOT := trimslice-mmc
+endef
+TARGET_DEVICES += trimslice
+
$(eval $(call BuildImage))
diff --git
a/target/linux/tegra/patches-4.14/101-ARM-dtc-tegra-enable-front-panel-leds-in-TrimSlice.patch
b/target/linux/tegra/patches-4.14/101-ARM-dtc-tegra-enable-front-panel-leds-in-TrimSlice.patch
new file mode 100644
index 00..ae48e8d862
--- /dev/null
+++
b/target/linux/tegra/patches-4.14/101-ARM-dtc-tegra-enable-front-panel-leds-in-TrimSlice.patch
@@ -0,0 +1,46 @@
+--- a/arch/arm/boot/dts/tegra20-trimslice.dts
b/arch/arm/boot/dts/tegra20-trimslice.dts
+@@ -200,16 +200,17 @@
+ conf_ata {
+ nvidia,pins = "ata", "atc", "atd", "ate",
+ "crtp", "dap2", "dap3", "dap4", "d
[OpenWrt-Devel] [PATCH v4 0/7] tegra: add new target with support for CompuLab TrimSlice
This is continuation of effort in [1] PR to old LEDE source tree. It received few improvement and some commits got split. Main changes worth mentioning: - update tools and U-Boot to recent versions, - added support for 4.19 kernel - now SD card image is also an rescue image with embedded U-Boot - the SD card creation process is more generic which makes adding basic support for other boards/devices trivial 1. https://github.com/lede-project/source/pull/1252 Changes in v4 - disable binman when creating U-Boot images, otherwise it would require swig on host side or in OpenWrt tools to build, pointed out by Hauke Mehrtens Changes in v3 - clean-up kernel configs in result of review by Hauke Mehrtens Changes in v2 - there are no drastic storage space constraints for this target, so instead of creating packages for target speciffic modules, build them in the kernel, requested by Felix Fietkau - since video drivers are now built-in I enabled also USB keyboard related drivers, because most users with connected monitors would expect to interact with the device OOTB Tomasz Maciej Nowak (7): tegra: add new target tools: add cbootimage for tegra tools: add cbootimage-configs for tegra uboot-tegra: add U-Boot for tegra boards kernel: package rtc-em3027 module tegra: add support for CompuLab TrimSlice tegra: add kernel 4.19 support package/boot/uboot-tegra/Makefile | 64 ++ package/kernel/linux/modules/netdevices.mk| 4 +- package/kernel/linux/modules/other.mk | 18 + target/linux/generic/config-4.14 | 2 + target/linux/generic/config-4.19 | 1 + target/linux/tegra/Makefile | 29 + target/linux/tegra/base-files/etc/inittab | 4 + .../base-files/lib/preinit/79_move_config | 22 + .../tegra/base-files/lib/upgrade/platform.sh | 105 target/linux/tegra/config-4.14| 558 ++ target/linux/tegra/config-4.19| 558 ++ target/linux/tegra/image/Makefile | 59 ++ target/linux/tegra/image/generic-bootscript | 6 + ...interrupts-due-to-tegra2-silicon-bug.patch | 77 +++ ...enable-front-panel-leds-in-TrimSlice.patch | 46 ++ ...interrupts-due-to-tegra2-silicon-bug.patch | 77 +++ ...enable-front-panel-leds-in-TrimSlice.patch | 46 ++ tools/Makefile| 2 + tools/cbootimage-configs/Makefile | 32 + tools/cbootimage/Makefile | 31 + 20 files changed, 1739 insertions(+), 2 deletions(-) create mode 100644 package/boot/uboot-tegra/Makefile create mode 100644 target/linux/tegra/Makefile create mode 100644 target/linux/tegra/base-files/etc/inittab create mode 100644 target/linux/tegra/base-files/lib/preinit/79_move_config create mode 100644 target/linux/tegra/base-files/lib/upgrade/platform.sh create mode 100644 target/linux/tegra/config-4.14 create mode 100644 target/linux/tegra/config-4.19 create mode 100644 target/linux/tegra/image/Makefile create mode 100644 target/linux/tegra/image/generic-bootscript create mode 100644 target/linux/tegra/patches-4.14/100-serial8250-on-tegra-hsuart-recover-from-spurious-interrupts-due-to-tegra2-silicon-bug.patch create mode 100644 target/linux/tegra/patches-4.14/101-ARM-dtc-tegra-enable-front-panel-leds-in-TrimSlice.patch create mode 100644 target/linux/tegra/patches-4.19/100-serial8250-on-tegra-hsuart-recover-from-spurious-interrupts-due-to-tegra2-silicon-bug.patch create mode 100644 target/linux/tegra/patches-4.19/101-ARM-dtc-tegra-enable-front-panel-leds-in-TrimSlice.patch create mode 100644 tools/cbootimage-configs/Makefile create mode 100644 tools/cbootimage/Makefile -- 2.21.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] qca8x DSA: Configured Switch Sends Packets Out Wrong Interface
qca8x DSA: Configured Switch Sends Packets Out Wrong Interface
Using qca8k and ipqess on an EA8300 (ipq40xx) under Linux 4.19 based
on patches from chunkeey's staging tree[1] as well as a patch to
resolve the NPE issue[2].
Once the switch has been configured (this is *after* the power-on
config has been overridden), I see that packets are being sent out
over ports that aren't associated with the bridge. As these packets
are not seen with tcpdump on the underlying interface, I believe that
they are traveling through the switch fabric.
* Am I configuring the bridge as expected?
* Are there patches that I am missing?
I have tried configuring the bridge both using /etc/config/network (no
switch-related sections) as well as "manually" with iproute2
commands and see the same behavior in both cases. In both cases,
`brctl show` and `bridge link` output is consistent with that
expected; the expected interfaces are present and those not involved
in the bridge are not present.
The initial test was for the "desired" configuration:
* lan1 stand-alone 192.168.1.1/24
* lan2 -|
* lan3 -| -- bridged
* lan4 -|
* wan0.10 -|
* wan0. -- other trunked VLANs -- to Cisco SG300
config interface 'lan'
option type 'bridge'
option ifname 'lan2 lan3 lan4 wan0.10'
option proto 'static'
option stp '1'
option ipaddr '10.X.Y.Z'
option netmask '255.255.255.0'
(wan0.10 configured and brought up elsewhere)
This appeared to work for connectivity to the device itself, but a
wired client plugged into lan2 was unable to obtain a DHCP lease from
the DHCP server connected to the Cisco SG300, leading to this exploration.
Examining the packets seen by this client suggested that they were
being sent out lan2-4 as tagged VLAN 10 (unexpected).
(I need to re-confirm this as the EA8300 at the time "won" STP root.)
I then removed wan.10 from the bridge and connected lan4 to
an untagged source of the 10.X.Y.Z/24 traffic from the SG300
* lan1 - stand-alone 192.168.1.1/24
* lan2 -|
* lan3 -| -- bridged
* lan4 -|
config interface 'lan'
option type 'bridge'
option ifname 'lan2 lan3 lan4'
option proto 'static'
option stp '1'
option ipaddr '10.X.Y.Z'
option netmask '255.255.255.0'
Looking at the packets on the lan1 port, traffic that was clearly from
the subnet associated with the 10 VLAN was being seen (unexpected).
Looking at lan1 with `tcpdump -ni lan1` only showed an occasional ARP
related to the 192.168.1.1/24 subnet (as expected).
This suggests to me that the packets are flowing through the switch
fabric, not the CPU.
Configuring lan1 as a bridge rather than a direct-accessed interface
did not change the behavior.
(This continued to occur after changing the STP priority of the SG300,
rebooting the router, and confirming that the SG300 was the STP root.)
Configuring with iproute2 commands after removing the applicable
interface section from /etc/config/network did not change the behavior
#!/bin/sh
ip addr add 192.168.1.1/24 dev lan1
for if in lan1 lan2 lan3 lan4 wan0 ; do
ip link set ${if} up
done
ip link add name lan-br type bridge
ip link set lan-br type bridge stp_state 1
ip addr add 10.X.Y.Z/24 dev lan-br
ip link set lan-br up
for if in lan2 lan3 lan4 ; do
ip link set ${if} master lan-br
done
Based on these observations, I believe that the switch fabric is not
being properly configured, that I am missing patches causing the
former, or that I am somehow not configuring the bridge properly.
Any suggestions as to how to proceed?
Jeff
[1] Patches from chunkeey's staging tree:
f42d8ea703 ipq40xx: include ipq40xx-ized qca8k version
35cacbdc1e ipq40xx: fix NPE related to bogus use of fixed phy
b696da2763 ipq40xx: extend DT mdio node to be more accessible
1c8d4e491b ipq40xx: add ipqess ethernet driver
23cf41880f ipq40xx: add resets for individual MAC1-5 and PSGMII
7bf4edca65 ipq40xx: decouple mdio-ipq40xx and ar40xx
415f2c04c4 phytool: add phytool utility
merge-base with master is b61495409b
CommitDate: Thu Mar 14 22:55:06 2019 +0100
[2] 730-HACK-prevent-panic-adding-vlan-to-bridge.patch
after Florian Fainelli,
[PATCH] net: dsa: Add ndo_vlan_rx_{add, kill}_vid implementation
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -255,7 +255,10 @@ int dsa_port_vlan_add(struct dsa_port *d
if (netif_is_bridge_master(vlan->obj.orig_dev))
return -EOPNOTSUPP;
- if (br_vlan_enabled(dp->bridge_dev))
+ /* Can be called from dsa_slave_port_obj_add() or
+ * dsa_slave_vlan_rx_add_vid()
+ */
+ if (!dp->bridge_dev || br_vlan_enabled(dp->bridge_dev))
return dsa_port_notify(dp, DSA_NOTIFIER_VLAN_ADD, &info);
return 0;
@@ -270,10 +273,13 @@ int dsa_port_vlan_del(struct dsa_port *d
.vlan = vlan,
};
- if (netif_is_bridge_master(vlan->obj.orig_dev))
+ if (vlan->obj.orig_dev && netif_is_bridge_m
[OpenWrt-Devel] [PATCH v2 2/2 netifd] proto-shell: return error in case setup fails
In case PROTO_CMD_SETUP cannot be handled due to an invalid state; return -1 so the calling functions are aware the PROTO_CMD_SETUP has failed. Signed-off-by: Hans Dedecker --- V1 -> V2: Remove S_SETUP_ABORT, S_TEARDOWN and S_SETUP cases proto-shell.c | 5 - 1 file changed, 5 deletions(-) diff --git a/proto-shell.c b/proto-shell.c index 9653f4c..47a9568 100644 --- a/proto-shell.c +++ b/proto-shell.c @@ -181,11 +181,6 @@ proto_shell_handler(struct interface_proto_state *proto, state->sm = S_SETUP; break; - case S_SETUP_ABORT: - case S_TEARDOWN: - case S_SETUP: - return 0; - default: return -1; } -- 2.19.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2 netifd] proto-shell: return error in case setup fails
On Mon, Apr 1, 2019 at 11:25 AM Jo-Philipp Wich wrote: > > Hi, > > minor nitpick below > > On 4/1/19 10:34 AM, Hans Dedecker wrote: > > In case PROTO_CMD_SETUP cannot be handled due to an invalid state; return > > -1 so the calling functions are aware the PROTO_CMD_SETUP has failed. > > > > Signed-off-by: Hans Dedecker > > --- > > proto-shell.c | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/proto-shell.c b/proto-shell.c > > index 9653f4c..fd9cad4 100644 > > --- a/proto-shell.c > > +++ b/proto-shell.c > > @@ -184,8 +184,6 @@ proto_shell_handler(struct interface_proto_state *proto, > > case S_SETUP_ABORT: > > case S_TEARDOWN: > > case S_SETUP: > > - return 0; > > - > > If I'm reading this correctly, this would join the above cases with the > default case, so it is probably better to either drop the other "case" > statements and only leave the "default:" one or to keep explicit > redundancy by having two "return -1". Correct this joins the above cases with the default cases. For readability I agree it would be better to drop the other "case" statements; I will send a follow-up patch Hans > > > default: > > return -1; > > } > > > > > ~ Jo > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2 netifd] proto-shell: return error in case setup fails
On Mon, Apr 1, 2019 at 11:25 AM Jo-Philipp Wich wrote: > > Hi, > > minor nitpick below > > On 4/1/19 10:34 AM, Hans Dedecker wrote: > > In case PROTO_CMD_SETUP cannot be handled due to an invalid state; return > > -1 so the calling functions are aware the PROTO_CMD_SETUP has failed. > > > > Signed-off-by: Hans Dedecker > > --- > > proto-shell.c | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/proto-shell.c b/proto-shell.c > > index 9653f4c..fd9cad4 100644 > > --- a/proto-shell.c > > +++ b/proto-shell.c > > @@ -184,8 +184,6 @@ proto_shell_handler(struct interface_proto_state *proto, > > case S_SETUP_ABORT: > > case S_TEARDOWN: > > case S_SETUP: > > - return 0; > > - > > If I'm reading this correctly, this would join the above cases with the > default case, so it is probably better to either drop the other "case" > statements and only leave the "default:" one or to keep explicit > redundancy by having two "return -1". > > > default: > > return -1; > > } > > > > > ~ Jo > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/5] build: image: Add pad-to and pad-rootfs-squashfs helpers
Jo-Philipp Wich [2019-04-01 11:18:55]: > > Felix had a good point about sysupgrade, where we would needlesly write few > > dozen MBs of 0s. In order to avoid that, I would simply add following qemu > > variants to x86: > > I wonder what kind of storage media on x86 is so brittle that writing a > few dozen MB of 0s will cause any noticeable effect. SD cards could be slow. So it's going to make a difference if you're going to write 20M or 273M combined image. On my apu2 with some noname SDHC SD card (~6MB/s write max) I get ~15s difference in writting squashfs image (unpadded=0.29s Vs padded=15s). I'm not sure if this is negligible or acceptable tradeoff, considering how minor is the QEMU use case. > Not opposed to that, but that nullifies the entire "save space on servers" > argument. It wasn't my argument. > Instead of having one set of images a few MB larger, we have a completely > new set of larger images *and* the existing ones. I'm all in for having usable images out of the box, without any additional post-processing steps, but on the other hand I understand, that this might slow down noticeably some existing use cases. BTW, we're talking on x86 probably about additional 40M (~10M per each of 4 subtargets) and 8 additional QEMU ready images. On armvirt/malta we're going to produce(if agreed upon) padded images by default, so no difference there. -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2 netifd] proto-shell: return error in case setup fails
Hi, minor nitpick below On 4/1/19 10:34 AM, Hans Dedecker wrote: > In case PROTO_CMD_SETUP cannot be handled due to an invalid state; return > -1 so the calling functions are aware the PROTO_CMD_SETUP has failed. > > Signed-off-by: Hans Dedecker > --- > proto-shell.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/proto-shell.c b/proto-shell.c > index 9653f4c..fd9cad4 100644 > --- a/proto-shell.c > +++ b/proto-shell.c > @@ -184,8 +184,6 @@ proto_shell_handler(struct interface_proto_state *proto, > case S_SETUP_ABORT: > case S_TEARDOWN: > case S_SETUP: > - return 0; > - If I'm reading this correctly, this would join the above cases with the default case, so it is probably better to either drop the other "case" statements and only leave the "default:" one or to keep explicit redundancy by having two "return -1". > default: > return -1; > } > ~ Jo signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/5] build: image: Add pad-to and pad-rootfs-squashfs helpers
Hi,
> Felix had a good point about sysupgrade, where we would needlesly write few
> dozen MBs of 0s. In order to avoid that, I would simply add following qemu
> variants to x86:
I wonder what kind of storage media on x86 is so brittle that writing a
few dozen MB of 0s will cause any noticeable effect.
> openwrt-x86-{64,generic,geode,legacy}-qemu-{rootfs,combined}-squashfs.img
Not opposed to that, but that nullifies the entire "save space on
servers" argument. Instead of having one set of images a few MB larger,
we have a completely new set of larger images *and* the existing ones.
> I'm wondering if we should introduce CONFIG_QEMU_SQUASHFS_PARTSIZE=32 and use
> this information for generating of images for QEMU.
>
> Without this config option I don't see, how could we handle this on x86. On
> armvirt/malta we could probably just set already available option
> CONFIG_TARGET_ROOTFS_PARTSIZE=32 and use that to pad the images.
>
> Or should we just forget about this QEMU specific
> CONFIG_QEMU_SQUASHFS_PARTSIZE
> and use CONFIG_TARGET_ROOTFS_PARTSIZE for QEMU images as well? We can decrease
> the default 256M to 32M on armvirt/malta.
I'd prefer the later option.
~ Jo
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/5] build: image: Add pad-to and pad-rootfs-squashfs helpers
Jo-Philipp Wich [2019-04-01 07:33:40]:
> Most other targets ship image artifacts which are usable ootb, requiring
> one extra step to pad the combined images is a waste of user resources
> every single time. It also causes recurring confusion among users
> wanting to use x86 builds
x86, armvirt and malta builds to be more specific
> I really don't see the huge problem with conservatively padding the
> combined image artifacts to something like 32 or 48MB, it must not even
> be 256M or more.
Felix had a good point about sysupgrade, where we would needlesly write few
dozen MBs of 0s. In order to avoid that, I would simply add following qemu
variants to x86:
openwrt-x86-{64,generic,geode,legacy}-qemu-{rootfs,combined}-squashfs.img
and produce padded squashfs rootfs images for QEMU only targets by default:
openwrt-armvirt-{32,64}-rootfs-squashfs.img
openwrt-malta-{be,be64,le,le64}-rootfs-squashfs.img
I'm wondering if we should introduce CONFIG_QEMU_SQUASHFS_PARTSIZE=32 and use
this information for generating of images for QEMU.
Without this config option I don't see, how could we handle this on x86. On
armvirt/malta we could probably just set already available option
CONFIG_TARGET_ROOTFS_PARTSIZE=32 and use that to pad the images.
Or should we just forget about this QEMU specific CONFIG_QEMU_SQUASHFS_PARTSIZE
and use CONFIG_TARGET_ROOTFS_PARTSIZE for QEMU images as well? We can decrease
the default 256M to 32M on armvirt/malta.
-- ynezz
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/2 netifd] proto-shell: return error in case setup fails
In case PROTO_CMD_SETUP cannot be handled due to an invalid state; return -1 so the calling functions are aware the PROTO_CMD_SETUP has failed. Signed-off-by: Hans Dedecker --- proto-shell.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/proto-shell.c b/proto-shell.c index 9653f4c..fd9cad4 100644 --- a/proto-shell.c +++ b/proto-shell.c @@ -184,8 +184,6 @@ proto_shell_handler(struct interface_proto_state *proto, case S_SETUP_ABORT: case S_TEARDOWN: case S_SETUP: - return 0; - default: return -1; } -- 2.19.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/2 netifd] interface: set interface in TEARDOWN state when checking link state
From: Hans dedecker
When launching PROTO_CMD_TEARDOWN in interface_check_state() the interface
was set in IFS_DOWN state. In case an interface is now brought into IFS_SETUP
state in __interface_set_up() it will launch PROTO_CMD_SETUP trying to
bring the proto shell handler in S_SETUP state which will fail as the proto
shell handler is still in the S_TEARDOWN state.
Fix this by setting the interface in IFS_TEARDOWN state when the
PROTO_CMD_TEARDOWN
event is launched which will prevent the interface being brought into IFS_SETUP
state
as long as it's not in the IFS_DOWN state.
Signed-off-by: Hans Dedecker
---
interface.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/interface.c b/interface.c
index b8c4ae2..fd7a826 100644
--- a/interface.c
+++ b/interface.c
@@ -342,11 +342,11 @@ interface_check_state(struct interface *iface)
case IFS_UP:
case IFS_SETUP:
if (!iface->enabled || !link_state) {
- interface_proto_event(iface->proto, PROTO_CMD_TEARDOWN,
false);
+ iface->state = IFS_TEARDOWN;
if (iface->dynamic)
__set_config_state(iface, IFC_REMOVE);
- mark_interface_down(iface);
+ interface_proto_event(iface->proto, PROTO_CMD_TEARDOWN,
false);
}
break;
case IFS_DOWN:
--
2.19.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
On 31.03.19 15:45, Lorenzo Bianconi wrote: could you please try to attached patch? The max distance the hw can support depends of channel width: e.g @20MHz (HT20, 5GHz) max distance is ~ 61Km @Koen: do you have any chance to test the attached patch in your environment? Thx Hi Lorenzo, I don't have the 24km link anymore, as that offshore high-voltage station received it's fiber uplink some time ago. This rendered the wifi link obsolete and it got dismounted. I'll see if I can get something similar using other installed equipment offshore. Regards, Koen ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] fq_codel and sch_cake improvements for openwrt
I have been busy on other stuff than embedded routing for quite some time, but I'd like to start folding in some new stuff into openwrt related to fq_codel starting in the next week or so (I am currently in prague, heading to berlin next week) - with some new code that looks quite promising in the out of tree https://github.com/dtaht/fq_codel_fast and https://github.com/dtaht/sch_cake repos. repos, related to the new SCE concept, that we spoke about also, at ietf. Some background on that here: https://lwn.net/SubscriberLink/783673/0e7d178ea322e386/ Anybody got any time to hang with me next week? Is it too late for the freeze? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] OpenWrt and HOMENET talk at IETF recording
Is now up here: https://www.youtube.com/watch?v=y-7G2ItPwco&t=5m55 I was unaware of how far behind homenet had fallen on the openwrt integration front until ted talked to me... and I then "threatened to help". :P The outline of all that remains in homenet left to do is in his talk. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/5] build: image: Add pad-to and pad-rootfs-squashfs helpers
Felix Fietkau [2019-03-31 22:21:59]: > >> I just came up with this simple script, which takes an existing image and > >> pads it to full size: http://nbd.name/pad-image.pl With this, shipping > >> padded images should be unnecessary. > > > BTW that script needs some tweaking, it's producing here 2TB images from > > this file > > > > http://downloads.openwrt.org/snapshots/targets/x86/64/openwrt-x86-64-rootfs-squashfs.img.gz > > That's just the rootfs image, you're supposed to run the script on a > combined image. It wasn't obvious to me, that it should be used on combined image. > What do you need that rootfs image for? That rootfs for x86 was just improperly chosen example, so to be more specific, how are we going to pad rootfs squashfs images for armvirt and malta, where we don't have combined image, just separate kernel and rootfs. -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
