Re: [LEDE-DEV] [OpenWrt-Devel] 18.03/4

2018-03-04 Thread Alif M. Ahmad 
On Fri, Feb 16, 2018 at 01:46:31PM +0100, John Crispin wrote:
> Hi,
> 
> whats on the critical todo list for the upcoming release ? i still have 
> a few minor things that I'll be adding shortly, apart from that I am 
> currently not aware of any huge problems. the release will be a mix 
> between 4.9 and 4.14 afaik !?
> 
>      John

I would like to have uefi-gpt image for x86_64. For this feature, uefi
related changes on Jow's staging repository should be merged.

I have fixed kernel panic issue when booting gpt image on bios based
systems with my previous patch series.


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] mwan3 status: missing graphic status boxes

2018-03-04 Thread Mauro Mozzarelli 
I noticed that in the latest builds (from r6375 and onwards) mwan3 
status cgi-bin/luci/admin/status/mwan is missing the graphic traffic 
light boxes. Is this an error or have they been removed?


The last build I have with the graphics is r6320 - git-18.062.27847-1e46a67



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] Revert "firmware: ath10k-firmware: update QCA988x firmware to 10.2.4-1.0-00033"

2018-03-04 Thread Stefan Lippers-Hollmann 
Hi

On 2018-03-04, Hauke Mehrtens wrote:
> On 03/04/2018 06:40 PM, Rosen Penev wrote:
[...]
> > On Sun, Mar 4, 2018 at 9:31 AM, Rosen Penev  wrote:  
[...]
> I also saw problems with the 10.2.4-1.0-00033 FW on my BT HH5, the
> ath10k wifi was just not available after some time.
> I am now trying the FW 10.2.4-1.0-00037, see this commit:
> https://github.com/kvalo/ath10k-firmware/commit/31695fbc77f81391f579747bb8e51c50a581c3cd

10.2.4-1.0-00037 has been fine for me on the BT Business Hub 5 Type A
for the last couple of days, however my uptimes haven't been much higher
than 3-4 days each (for unrelated reasons).

Regards
Stefan Lippers-Hollmann


pgpgFYTgZJNEt.pgp
Description: Digitale Signatur von OpenPGP
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Can ramips use mt7530 switch driver from mainline?

2018-03-04 Thread Rosen Penev 
On Sun, Mar 4, 2018 at 5:57 AM, Hauke Mehrtens  wrote:
> On 02/28/2018 11:34 AM, Marek Behun wrote:
>> Hello,
>>
>> the mt7530 switch driver is now in mainline kernel as a DSA driver. The
>> LEDE ramips target ethernet driver though doesn't use it yet, and I've
>> been thinking what all would have to be done to port the ethernet
>> driver to use it, if it even is possible.
>>
>> For example, the mt7530 dsa driver device tree binding needs
>> regulator definitions (core-supply, io-supply). I haven't seen these
>> nowhere in the mt7621 device trees nor in the code. Any ideas?
>
> I think the biggest missing part is a good migration path. Currently the
> users have some configurations based on swconfig and this has to be
> ported to the DSA configuration model. If someone could create a script
> which does the migration of an existing swconfig configuration to a DSA
> based configuration that would be very helpful.
This is probably not popular, but since LEDE is getting renamed to
OpenWrt, can we break compatibility?
OpenWrt CC is already not sysupgrade compatible with OpenWrt or LEDE
because of the dnsmasq change and maybe others.
>
> Hauke
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] Revert "firmware: ath10k-firmware: update QCA988x firmware to 10.2.4-1.0-00033"

2018-03-04 Thread Rosen Penev 
On Sun, Mar 4, 2018 at 1:58 PM, Hauke Mehrtens  wrote:
> On 03/04/2018 06:40 PM, Rosen Penev wrote:
>> I would like this to be backported to 17.01 as well. The mentioned
>> Archer C7v2 runs 17.01. No impact between 17.01 and master.
>>
>> On Sun, Mar 4, 2018 at 9:31 AM, Rosen Penev  wrote:
>>> This reverts commit 8d755ef052dca29db3b8da74149d9c7d74a54842.
>>>
>>> The 33 firmware for QCA988x is not stable for me on both my Turris Omnia 
>>> and my Archer C7v2. With version 33, I cannot get uptime longer than 2 days 
>>> before the ath10k driver crashes. With version 29, I've gotten 49 days 
>>> uptime with 29 of those days having a properly working 5GHz interface.
>>>
>>> I have also tested version 37 but that one behaves similar to 33 with the 
>>> ath10k driver crashing.
>>>
>>> Other reports indicate similar findings: 
>>> https://forum.lede-project.org/t/archer-c7-v4-support/3924/152
>>>
>>> Signed-off-by: Rosen Penev 
>>> ---
>>>  package/firmware/ath10k-firmware/Makefile | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/package/firmware/ath10k-firmware/Makefile 
>>> b/package/firmware/ath10k-firmware/Makefile
>>> index 5b582085a4..2fc3618995 100644
>>> --- a/package/firmware/ath10k-firmware/Makefile
>>> +++ b/package/firmware/ath10k-firmware/Makefile
>>> @@ -253,7 +253,7 @@ define Package/ath10k-firmware-qca988x/install
>>> $(PKG_BUILD_DIR)/QCA988X/hw2.0/board.bin \
>>> $(1)/lib/firmware/ath10k/QCA988X/hw2.0/
>>> $(INSTALL_DATA) \
>>> -   
>>> $(PKG_BUILD_DIR)/QCA988X/hw2.0/10.2.4-1.0/firmware-5.bin_10.2.4-1.0-00033 \
>>> +   
>>> $(PKG_BUILD_DIR)/QCA988X/hw2.0/10.2.4-1.0/firmware-5.bin_10.2.4-1.0-00029 \
>>> $(1)/lib/firmware/ath10k/QCA988X/hw2.0/firmware-5.bin
>>>  endef
>
> I also saw problems with the 10.2.4-1.0-00033 FW on my BT HH5, the
> ath10k wifi was just not available after some time.
> I am now trying the FW 10.2.4-1.0-00037, see this commit:
> https://github.com/kvalo/ath10k-firmware/commit/31695fbc77f81391f579747bb8e51c50a581c3cd
>
I mentioned in the  commit message that I tried version 37 but it
gives me similar results to 33. Unfortunately, there seems to be no
quality control at Qualcomm...

Firmware 29 is somewhat recent and mostly stable.
> Hauke

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] sunxi: bpi-r1 switch configuration missing in latest development trunk for 18.0x

2018-03-04 Thread Hauke Mehrtens 
On 03/04/2018 07:44 PM, Florian Fainelli wrote:
> +Jonas,
> 
> On 03/04/2018 05:09 AM, TheWerthFam wrote:
>> Full kernel log below. I remove the 8192cu wifi driver since it doesn't
>> work in AP mode and use a rt2800 base usb dongle.. Additionally grep
>> output of config-4.14 for SWCONFIG
>> grep SWCONFIG target/linux/sunxi/config-4.14
>> CONFIG_SWCONFIG=y
>> CONFIG_SWCONFIG_B53=y
>> # CONFIG_SWCONFIG_B53_MMAP_DRIVER is not set
>> CONFIG_SWCONFIG_B53_PHY_DRIVER=y
>> CONFIG_SWCONFIG_B53_PHY_FIXUP=y
>> # CONFIG_SWCONFIG_B53_SRAB_DRIVER is not set
> 
> (please don't top post). I thought somehow that:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d7b9eaff5f0ca00726336b4c0c3c29decf30412a
> 
> could be responsible for what you are seeing, but this was already
> included in 4.9, so this must be something else.

lede-17.01 used kernel 4.4, did kernel 4.9 worked for you?
If you also had the same problem in kernel 4.9 please try to revert the
commit Florian showed.

Hauke

> 
>>
>> kernel log
>> [    0.00] Booting Linux on physical CPU 0x0
>> [    0.00] Linux version 4.14.20 (dandv@t420s) (gcc version 5.5.0
>> (OpenWrt GCC 5.5.0 r6351-694f0bb5af)) #0 SMP PREEMPT Fri Mar 2 14:58:09
>> 2018
>> [    0.00] CPU: ARMv7 Processor [410fc074] revision 4 (ARMv7),
>> cr=30c5387d
>> [    0.00] CPU: div instructions available: patching division code
>> [    0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
>> instruction cache
>> [    0.00] OF: fdt: Machine model: Lamobo R1
>> [    0.00] Memory policy: Data cache writealloc
>> [    0.00] On node 0 totalpages: 262144
>> [    0.00] free_area_init_node: node 0, pgdat c0c4f040, node_mem_map
>> ef7fa000
>> [    0.00]   Normal zone: 1536 pages used for memmap
>> [    0.00]   Normal zone: 0 pages reserved
>> [    0.00]   Normal zone: 196608 pages, LIFO batch:31
>> [    0.00]   HighMem zone: 65536 pages, LIFO batch:15
>> [    0.00] psci: probing for conduit method from DT.
>> [    0.00] psci: Using PSCI v0.1 Function IDs from DT
>> [    0.00] random: get_random_bytes called from
>> start_kernel+0x90/0x400 with crng_init=0
>> [    0.00] percpu: Embedded 16 pages/cpu @ef7be000 s34188 r8192
>> d23156 u65536
>> [    0.00] pcpu-alloc: s34188 r8192 d23156 u65536 alloc=16*4096
>> [    0.00] pcpu-alloc: [0] 0 [0] 1
>> [    0.00] Built 1 zonelists, mobility grouping on.  Total pages:
>> 260608
>> [    0.00] Kernel command line: console=ttyS0,115200 earlyprintk
>> root=/dev/mmcblk0p2 rootwait
>> [    0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
>> [    0.00] Dentry cache hash table entries: 131072 (order: 7, 524288
>> bytes)
>> [    0.00] Inode-cache hash table entries: 65536 (order: 6, 262144
>> bytes)
>> [    0.00] Memory: 1028452K/1048576K available (4766K kernel code,
>> 318K rwdata, 1368K rodata, 2048K init, 245K bss, 20124K reserved, 0K
>> cma-reserved, 262144K highmem)
>> [    0.00] Virtual kernel memory layout:
>> [    0.00] vector  : 0x - 0x1000   (   4 kB)
>> [    0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
>> [    0.00] vmalloc : 0xf080 - 0xff80   ( 240 MB)
>> [    0.00] lowmem  : 0xc000 - 0xf000   ( 768 MB)
>> [    0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
>> [    0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
>> [    0.00]   .text : 0xc0008000 - 0xc06a78e0   (6783 kB)
>> [    0.00]   .init : 0xc0a0 - 0xc0c0   (2048 kB)
>> [    0.00]   .data : 0xc0c0 - 0xc0c4f940   ( 319 kB)
>> [    0.00]    .bss : 0xc0c55d7c - 0xc0c9344c   ( 246 kB)
>> [    0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
>> [    0.00] Preemptible hierarchical RCU implementation.
>> [    0.00]     RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=2.
>> [    0.00]     Tasks RCU enabled.
>> [    0.00] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
>> [    0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
>> [    0.00] GIC: Using split EOI/Deactivate mode
>> [    0.00] arch_timer: cp15 timer(s) running at 24.00MHz (phys).
>> [    0.00] clocksource: arch_sys_counter: mask: 0xff
>> max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns
>> [    0.08] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps
>> every 4398046511097ns
>> [    0.21] Switching to timer-based delay loop, resolution 41ns
>> [    0.000560] clocksource: timer: mask: 0x max_cycles:
>> 0x, max_idle_ns: 79635851949 ns
>> [    0.000843] clocksource: hstimer: mask: 0x max_cycles:
>> 0x, max_idle_ns: 12741736309 ns
>> [    0.001002] Console: colour dummy device 80x30
>> [    0.001040] Calibrating delay loop (skipped), value calculated using
>> timer frequency.. 48.00 BogoMIPS (lpj=24)
>> [    0.001057] pid_max: default: 32768

Re: [LEDE-DEV] [PATCH] Revert "firmware: ath10k-firmware: update QCA988x firmware to 10.2.4-1.0-00033"

2018-03-04 Thread Hauke Mehrtens 
On 03/04/2018 06:40 PM, Rosen Penev wrote:
> I would like this to be backported to 17.01 as well. The mentioned
> Archer C7v2 runs 17.01. No impact between 17.01 and master.
> 
> On Sun, Mar 4, 2018 at 9:31 AM, Rosen Penev  wrote:
>> This reverts commit 8d755ef052dca29db3b8da74149d9c7d74a54842.
>>
>> The 33 firmware for QCA988x is not stable for me on both my Turris Omnia and 
>> my Archer C7v2. With version 33, I cannot get uptime longer than 2 days 
>> before the ath10k driver crashes. With version 29, I've gotten 49 days 
>> uptime with 29 of those days having a properly working 5GHz interface.
>>
>> I have also tested version 37 but that one behaves similar to 33 with the 
>> ath10k driver crashing.
>>
>> Other reports indicate similar findings: 
>> https://forum.lede-project.org/t/archer-c7-v4-support/3924/152
>>
>> Signed-off-by: Rosen Penev 
>> ---
>>  package/firmware/ath10k-firmware/Makefile | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/package/firmware/ath10k-firmware/Makefile 
>> b/package/firmware/ath10k-firmware/Makefile
>> index 5b582085a4..2fc3618995 100644
>> --- a/package/firmware/ath10k-firmware/Makefile
>> +++ b/package/firmware/ath10k-firmware/Makefile
>> @@ -253,7 +253,7 @@ define Package/ath10k-firmware-qca988x/install
>> $(PKG_BUILD_DIR)/QCA988X/hw2.0/board.bin \
>> $(1)/lib/firmware/ath10k/QCA988X/hw2.0/
>> $(INSTALL_DATA) \
>> -   
>> $(PKG_BUILD_DIR)/QCA988X/hw2.0/10.2.4-1.0/firmware-5.bin_10.2.4-1.0-00033 \
>> +   
>> $(PKG_BUILD_DIR)/QCA988X/hw2.0/10.2.4-1.0/firmware-5.bin_10.2.4-1.0-00029 \
>> $(1)/lib/firmware/ath10k/QCA988X/hw2.0/firmware-5.bin
>>  endef

I also saw problems with the 10.2.4-1.0-00033 FW on my BT HH5, the
ath10k wifi was just not available after some time.
I am now trying the FW 10.2.4-1.0-00037, see this commit:
https://github.com/kvalo/ath10k-firmware/commit/31695fbc77f81391f579747bb8e51c50a581c3cd

Hauke

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH][lede-17.01] mbedtls: update to version 2.7.0

2018-03-04 Thread Hauke Mehrtens 
This fixes the following security problems:
* CVE-2018-0488: Risk of remote code execution when truncated HMAC is enabled
* CVE-2018-0487: Risk of remote code execution when verifying RSASSA-PSS 
signatures

This release is also ABI incompatible with the previous one, but it is
API compatible.

Some functions used by a lot of other software was renamed and the old
function names are provided as a static inline now, but they are only
active when deprecated functions are allowed, deactivate the removal of
deprecated functions for now.

Also increase the PKG_RELEASE version to force a rebuild and update of
packages depending on mbedtls to handle the changed ABI.

Signed-off-by: Hauke Mehrtens 
---
 package/libs/mbedtls/Makefile |  4 +-
 package/libs/mbedtls/patches/200-config.patch | 83 ---
 package/libs/ustream-ssl/Makefile |  2 +-
 package/network/services/openvpn/Makefile |  2 +-
 package/network/utils/curl/Makefile   |  2 +-
 package/utils/px5g/Makefile   |  2 +-
 6 files changed, 42 insertions(+), 53 deletions(-)

diff --git a/package/libs/mbedtls/Makefile b/package/libs/mbedtls/Makefile
index 0e3383150d..4ffe04cd4d 100644
--- a/package/libs/mbedtls/Makefile
+++ b/package/libs/mbedtls/Makefile
@@ -8,13 +8,13 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=mbedtls
-PKG_VERSION:=2.6.0
+PKG_VERSION:=2.7.0
 PKG_RELEASE:=1
 PKG_USE_MIPS16:=0
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-gpl.tgz
 PKG_SOURCE_URL:=https://tls.mbed.org/download/
-PKG_HASH:=a99959d7360def22f9108d2d487c9de384fe76c349697176b1f22370080d5810
+PKG_HASH:=2c6fe289b4b50bf67b4839e81b07fcf52a19f5129d0241d2aa4d49cb1ef11e4f
 
 PKG_BUILD_PARALLEL:=1
 PKG_LICENSE:=GPL-2.0+
diff --git a/package/libs/mbedtls/patches/200-config.patch 
b/package/libs/mbedtls/patches/200-config.patch
index ce32be76a5..55403c9b5b 100644
--- a/package/libs/mbedtls/patches/200-config.patch
+++ b/package/libs/mbedtls/patches/200-config.patch
@@ -1,15 +1,6 @@
 --- a/include/mbedtls/config.h
 +++ b/include/mbedtls/config.h
-@@ -220,7 +220,7 @@
-  *
-  * Uncomment to get errors on using deprecated functions.
-  */
--//#define MBEDTLS_DEPRECATED_REMOVED
-+#define MBEDTLS_DEPRECATED_REMOVED
- 
- /* \} name SECTION: System support */
- 
-@@ -539,17 +539,17 @@
+@@ -566,17 +566,17 @@
   *
   * Comment macros to disable the curve and functions for it
   */
@@ -35,7 +26,7 @@
  #define MBEDTLS_ECP_DP_CURVE25519_ENABLED
  
  /**
-@@ -574,8 +574,8 @@
+@@ -601,8 +601,8 @@
   * Requires: MBEDTLS_HMAC_DRBG_C
   *
   * Comment this macro to disable deterministic ECDSA.
@@ -45,16 +36,16 @@
  
  /**
   * \def MBEDTLS_KEY_EXCHANGE_PSK_ENABLED
-@@ -621,7 +621,7 @@
-  *  MBEDTLS_TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA
-  *  MBEDTLS_TLS_DHE_PSK_WITH_RC4_128_SHA
+@@ -655,7 +655,7 @@
+  * See dhm.h for more details.
+  *
   */
 -#define MBEDTLS_KEY_EXCHANGE_DHE_PSK_ENABLED
 +//#define MBEDTLS_KEY_EXCHANGE_DHE_PSK_ENABLED
  
  /**
   * \def MBEDTLS_KEY_EXCHANGE_ECDHE_PSK_ENABLED
-@@ -640,8 +640,8 @@
+@@ -674,8 +674,8 @@
   *  MBEDTLS_TLS_ECDHE_PSK_WITH_CAMELLIA_128_CBC_SHA256
   *  MBEDTLS_TLS_ECDHE_PSK_WITH_3DES_EDE_CBC_SHA
   *  MBEDTLS_TLS_ECDHE_PSK_WITH_RC4_128_SHA
@@ -64,7 +55,7 @@
  
  /**
   * \def MBEDTLS_KEY_EXCHANGE_RSA_PSK_ENABLED
-@@ -666,7 +666,7 @@
+@@ -700,7 +700,7 @@
   *  MBEDTLS_TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA
   *  MBEDTLS_TLS_RSA_PSK_WITH_RC4_128_SHA
   */
@@ -73,7 +64,7 @@
  
  /**
   * \def MBEDTLS_KEY_EXCHANGE_RSA_ENABLED
-@@ -793,7 +793,7 @@
+@@ -834,7 +834,7 @@
   *  MBEDTLS_TLS_ECDH_ECDSA_WITH_CAMELLIA_128_GCM_SHA256
   *  MBEDTLS_TLS_ECDH_ECDSA_WITH_CAMELLIA_256_GCM_SHA384
   */
@@ -82,7 +73,7 @@
  
  /**
   * \def MBEDTLS_KEY_EXCHANGE_ECDH_RSA_ENABLED
-@@ -817,7 +817,7 @@
+@@ -858,7 +858,7 @@
   *  MBEDTLS_TLS_ECDH_RSA_WITH_CAMELLIA_128_GCM_SHA256
   *  MBEDTLS_TLS_ECDH_RSA_WITH_CAMELLIA_256_GCM_SHA384
   */
@@ -91,7 +82,7 @@
  
  /**
   * \def MBEDTLS_KEY_EXCHANGE_ECJPAKE_ENABLED
-@@ -921,7 +921,7 @@
+@@ -962,7 +962,7 @@
   * This option is only useful if both MBEDTLS_SHA256_C and
   * MBEDTLS_SHA512_C are defined. Otherwise the available hash module is used.
   */
@@ -100,7 +91,7 @@
  
  /**
   * \def MBEDTLS_ENTROPY_NV_SEED
-@@ -1015,14 +1015,14 @@
+@@ -1056,14 +1056,14 @@
   * Uncomment this macro to disable the use of CRT in RSA.
   *
   */
@@ -117,7 +108,7 @@
  
  /**
   * \def MBEDTLS_SHA256_SMALLER
-@@ -1038,7 +1038,7 @@
+@@ -1079,7 +1079,7 @@
   *
   * Uncomment to enable the smaller implementation of SHA256.
   */
@@ -126,17 +117,16 @@
  
  /**
   * \def MBEDTLS_SSL_ALL_ALERT_MESSAGES
-@@ -1157,8 +1157,8 @@
-  * misuse/misunderstand.
+@@ -1206,7 +1206,7 @@
+  *  configuration of this extension).
   *
-  * Comment this to disable support for renegotiation.
-- */
- #define MBEDTLS_SSL_RENEGOTIATION
-+ */
+  */
+-#define MBEDTLS_SSL_RENEGOTIATION
++//#define MBEDTLS_SSL_RENEGOTIATION
  
  /**
   * \def

Re: [LEDE-DEV] sunxi: bpi-r1 switch configuration missing in latest development trunk for 18.0x

2018-03-04 Thread Florian Fainelli 
+Jonas,

On 03/04/2018 05:09 AM, TheWerthFam wrote:
> Full kernel log below. I remove the 8192cu wifi driver since it doesn't
> work in AP mode and use a rt2800 base usb dongle.. Additionally grep
> output of config-4.14 for SWCONFIG
> grep SWCONFIG target/linux/sunxi/config-4.14
> CONFIG_SWCONFIG=y
> CONFIG_SWCONFIG_B53=y
> # CONFIG_SWCONFIG_B53_MMAP_DRIVER is not set
> CONFIG_SWCONFIG_B53_PHY_DRIVER=y
> CONFIG_SWCONFIG_B53_PHY_FIXUP=y
> # CONFIG_SWCONFIG_B53_SRAB_DRIVER is not set

(please don't top post). I thought somehow that:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d7b9eaff5f0ca00726336b4c0c3c29decf30412a

could be responsible for what you are seeing, but this was already
included in 4.9, so this must be something else.

> 
> kernel log
> [    0.00] Booting Linux on physical CPU 0x0
> [    0.00] Linux version 4.14.20 (dandv@t420s) (gcc version 5.5.0
> (OpenWrt GCC 5.5.0 r6351-694f0bb5af)) #0 SMP PREEMPT Fri Mar 2 14:58:09
> 2018
> [    0.00] CPU: ARMv7 Processor [410fc074] revision 4 (ARMv7),
> cr=30c5387d
> [    0.00] CPU: div instructions available: patching division code
> [    0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
> instruction cache
> [    0.00] OF: fdt: Machine model: Lamobo R1
> [    0.00] Memory policy: Data cache writealloc
> [    0.00] On node 0 totalpages: 262144
> [    0.00] free_area_init_node: node 0, pgdat c0c4f040, node_mem_map
> ef7fa000
> [    0.00]   Normal zone: 1536 pages used for memmap
> [    0.00]   Normal zone: 0 pages reserved
> [    0.00]   Normal zone: 196608 pages, LIFO batch:31
> [    0.00]   HighMem zone: 65536 pages, LIFO batch:15
> [    0.00] psci: probing for conduit method from DT.
> [    0.00] psci: Using PSCI v0.1 Function IDs from DT
> [    0.00] random: get_random_bytes called from
> start_kernel+0x90/0x400 with crng_init=0
> [    0.00] percpu: Embedded 16 pages/cpu @ef7be000 s34188 r8192
> d23156 u65536
> [    0.00] pcpu-alloc: s34188 r8192 d23156 u65536 alloc=16*4096
> [    0.00] pcpu-alloc: [0] 0 [0] 1
> [    0.00] Built 1 zonelists, mobility grouping on.  Total pages:
> 260608
> [    0.00] Kernel command line: console=ttyS0,115200 earlyprintk
> root=/dev/mmcblk0p2 rootwait
> [    0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
> [    0.00] Dentry cache hash table entries: 131072 (order: 7, 524288
> bytes)
> [    0.00] Inode-cache hash table entries: 65536 (order: 6, 262144
> bytes)
> [    0.00] Memory: 1028452K/1048576K available (4766K kernel code,
> 318K rwdata, 1368K rodata, 2048K init, 245K bss, 20124K reserved, 0K
> cma-reserved, 262144K highmem)
> [    0.00] Virtual kernel memory layout:
> [    0.00] vector  : 0x - 0x1000   (   4 kB)
> [    0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
> [    0.00] vmalloc : 0xf080 - 0xff80   ( 240 MB)
> [    0.00] lowmem  : 0xc000 - 0xf000   ( 768 MB)
> [    0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
> [    0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
> [    0.00]   .text : 0xc0008000 - 0xc06a78e0   (6783 kB)
> [    0.00]   .init : 0xc0a0 - 0xc0c0   (2048 kB)
> [    0.00]   .data : 0xc0c0 - 0xc0c4f940   ( 319 kB)
> [    0.00]    .bss : 0xc0c55d7c - 0xc0c9344c   ( 246 kB)
> [    0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
> [    0.00] Preemptible hierarchical RCU implementation.
> [    0.00]     RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=2.
> [    0.00]     Tasks RCU enabled.
> [    0.00] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
> [    0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
> [    0.00] GIC: Using split EOI/Deactivate mode
> [    0.00] arch_timer: cp15 timer(s) running at 24.00MHz (phys).
> [    0.00] clocksource: arch_sys_counter: mask: 0xff
> max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns
> [    0.08] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps
> every 4398046511097ns
> [    0.21] Switching to timer-based delay loop, resolution 41ns
> [    0.000560] clocksource: timer: mask: 0x max_cycles:
> 0x, max_idle_ns: 79635851949 ns
> [    0.000843] clocksource: hstimer: mask: 0x max_cycles:
> 0x, max_idle_ns: 12741736309 ns
> [    0.001002] Console: colour dummy device 80x30
> [    0.001040] Calibrating delay loop (skipped), value calculated using
> timer frequency.. 48.00 BogoMIPS (lpj=24)
> [    0.001057] pid_max: default: 32768 minimum: 301
> [    0.001195] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
> [    0.001212] Mountpoint-cache hash table entries: 2048 (order: 1, 8192
> bytes)
> [    0.001763] CPU: Testing write buffer coherency: ok
> [    0.002112] /cpus/cpu@0 missing clock-frequency property
> [    0.002133]

Re: [LEDE-DEV] Spectre vulnerability & LEDE 17.01 release

2018-03-04 Thread Rosen Penev 
On Sun, Mar 4, 2018 at 6:36 AM, Hauke Mehrtens  wrote:
> On 02/27/2018 11:37 AM, Rafał Miłecki wrote:
>> There has been some talk on upcoming 17.01 fix release and Meltdown/Spectre.
>>
>> Quick summary:
>> 1) Most of LEDE supported devices aren't affected
>> 2) For most LEDE use cases these vulnerabilities don't matter
>> 3) 17.01 uses 4.4.116 which includes Meltdown fixes
>> 4) Spectre mitigation requires newer GCC and CPU microcode update
>> 5) Zoltan did some progress on x86 microcode update support
>>
>> So right now in some specific cases (mostly when running an unverified
>> software) Spectre may be a problem.
>>
>> There are two problems solving it:
>>
>> 1) Microcode updates are not (fully) available yet
>> It's unclear how long it will take Intel to release updates microcodes.
>>
>> 2) GCC officially supports Spectre mitigation in 7.2 and 8.0
>> LEDE 17.01 uses GCC 5.4. It seems fixes are unofficially backported to the 
>> 5.5:
>> https://github.com/hjl-tools/gcc/commits/hjl/indirect/gcc-5-branch/master
>> So the only solution for LEDE is to switch from 5.4 to 5.5 and apply
>> backported fixes. I'm not sure how safe it's going to be (possible
>> regressions caused by 5.5 update).
>>
>> If I'm wrong about anything, please let me know.
>>
>> In this situation my suggestion it to release 17.01.5 now and take
>> care of Spectre in another release in few months from now. What do you
>> think? Any objections?
>
> I agree with you. We should do the LEDE 17.01.5 release now with the
> current state, there are already many other bugfixes in the the lede
> 17.01 branch some for security problems which probably can be abused
> much easier in most of the common OpenWrt uses cases that Spectre.
>
> I would also wait with the ARM Spectre fixes till this code hits the 4.4
> LTS kernel tree and then we can release it in lede 17.01.6 in some months.
>
> I am, not sure if we should update the GCC at all or if users that
> really want these fixes should go to OpenWrt 18.X.
The MIPS SATA data corruption issue affects kernels 4.9 and above.
17.01 uses 4.4 i believe.

I vote for leaving GCC at 5.5.
>
> mbedtls 2.7 fixed 2 security problems in their last release, but this
> version is ABI incompatible but API compatible with the previous
> version, should I backport the commits or should I increase the
> PKG_RELEASE number for all depended packages?
>
> This is my personal opinion on this topic.
>
> Hauke
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] Revert "firmware: ath10k-firmware: update QCA988x firmware to 10.2.4-1.0-00033"

2018-03-04 Thread Rosen Penev 
I would like this to be backported to 17.01 as well. The mentioned
Archer C7v2 runs 17.01. No impact between 17.01 and master.

On Sun, Mar 4, 2018 at 9:31 AM, Rosen Penev  wrote:
> This reverts commit 8d755ef052dca29db3b8da74149d9c7d74a54842.
>
> The 33 firmware for QCA988x is not stable for me on both my Turris Omnia and 
> my Archer C7v2. With version 33, I cannot get uptime longer than 2 days 
> before the ath10k driver crashes. With version 29, I've gotten 49 days uptime 
> with 29 of those days having a properly working 5GHz interface.
>
> I have also tested version 37 but that one behaves similar to 33 with the 
> ath10k driver crashing.
>
> Other reports indicate similar findings: 
> https://forum.lede-project.org/t/archer-c7-v4-support/3924/152
>
> Signed-off-by: Rosen Penev 
> ---
>  package/firmware/ath10k-firmware/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/package/firmware/ath10k-firmware/Makefile 
> b/package/firmware/ath10k-firmware/Makefile
> index 5b582085a4..2fc3618995 100644
> --- a/package/firmware/ath10k-firmware/Makefile
> +++ b/package/firmware/ath10k-firmware/Makefile
> @@ -253,7 +253,7 @@ define Package/ath10k-firmware-qca988x/install
> $(PKG_BUILD_DIR)/QCA988X/hw2.0/board.bin \
> $(1)/lib/firmware/ath10k/QCA988X/hw2.0/
> $(INSTALL_DATA) \
> -   
> $(PKG_BUILD_DIR)/QCA988X/hw2.0/10.2.4-1.0/firmware-5.bin_10.2.4-1.0-00033 \
> +   
> $(PKG_BUILD_DIR)/QCA988X/hw2.0/10.2.4-1.0/firmware-5.bin_10.2.4-1.0-00029 \
> $(1)/lib/firmware/ath10k/QCA988X/hw2.0/firmware-5.bin
>  endef
>
> --
> 2.14.3
>

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] Revert "firmware: ath10k-firmware: update QCA988x firmware to 10.2.4-1.0-00033"

2018-03-04 Thread Rosen Penev 
This reverts commit 8d755ef052dca29db3b8da74149d9c7d74a54842.

The 33 firmware for QCA988x is not stable for me on both my Turris Omnia and my 
Archer C7v2. With version 33, I cannot get uptime longer than 2 days before the 
ath10k driver crashes. With version 29, I've gotten 49 days uptime with 29 of 
those days having a properly working 5GHz interface.

I have also tested version 37 but that one behaves similar to 33 with the 
ath10k driver crashing.

Other reports indicate similar findings: 
https://forum.lede-project.org/t/archer-c7-v4-support/3924/152

Signed-off-by: Rosen Penev 
---
 package/firmware/ath10k-firmware/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/firmware/ath10k-firmware/Makefile 
b/package/firmware/ath10k-firmware/Makefile
index 5b582085a4..2fc3618995 100644
--- a/package/firmware/ath10k-firmware/Makefile
+++ b/package/firmware/ath10k-firmware/Makefile
@@ -253,7 +253,7 @@ define Package/ath10k-firmware-qca988x/install
$(PKG_BUILD_DIR)/QCA988X/hw2.0/board.bin \
$(1)/lib/firmware/ath10k/QCA988X/hw2.0/
$(INSTALL_DATA) \
-   
$(PKG_BUILD_DIR)/QCA988X/hw2.0/10.2.4-1.0/firmware-5.bin_10.2.4-1.0-00033 \
+   
$(PKG_BUILD_DIR)/QCA988X/hw2.0/10.2.4-1.0/firmware-5.bin_10.2.4-1.0-00029 \
$(1)/lib/firmware/ath10k/QCA988X/hw2.0/firmware-5.bin
 endef
 
-- 
2.14.3


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] 18.03/4 -> GCC 5 or 7

2018-03-04 Thread Rosen Penev 
On Sun, Mar 4, 2018 at 7:15 AM, Hauke Mehrtens  wrote:
> On 02/16/2018 01:46 PM, John Crispin wrote:
>> Hi,
>>
>> whats on the critical todo list for the upcoming release ? i still have
>> a few minor things that I'll be adding shortly, apart from that I am
>> currently not aware of any huge problems. the release will be a mix
>> between 4.9 and 4.14 afaik !?
>
> I think the kernel situation is ok now and not blocking a release, we
> will have a mixed kernel 4.9 and 4.14 release. All important targets are
> on one of these two kernel versions by now.
> The patches for the gemini target will probably get included soon.
> Some targets will probably be updated from 4.9 to 4.14, but this is not
> blocking.
>
>
> What do we want to do with GCC 5.5 versus 7.3?
> GCC 5.5 is getting old, we have multiple problems with it, the big
> blocker for GCC 7 was just fixed upstream and we backported that fix.
> see: http://git.openwrt.org/25aaff9100065dba881be71b9dcab1e9cc8a7b5f
> The x86 and x86_64 architectures are already on GCC 7.3, the ARC
> architecture uses their own GCC fork based on version 7.X all other
> architectures are on GCC 5.5.

Preliminary testing with GCC 7.3 reveals that it fixes the SATA data
corruption issue on MIPS (at least ramips and ar71xx, possibly
others). @dissent1 started seeing the issue after going back to 5.5 in
his builds.

Both GCC 5.5 and 7.3 fail with -O3, but that's beyond the scope of OpenWrt.
>
> We have the following problems with GCC 5.5:
>  * U-Boot depends on GCC 6 or higher since version 2018.01 on ARM and ARM64
>   * GCC 5 and older are producing too big binaries, e.g. the SPL on the
> Allwinner A64 (sunxi, ARM64) is getting too big starting with U-Boot
> 2017.09 and does not fit into the SRAM any more, GCC 7 solves this problem.
>  * busybox on the gemini target updated to kernel 4.14 does not work
> correctly.
>  * GCC 5.5 only has out of tree fixes for Spectre, GCC 7.3 already has
> the retpoline fixes against Spectre included
>
> As the x86 target use GCC 7.3 now, there are multiple pull requests
> fixing some build problems in some packages with GCC 7.
> I am not aware of any regressions in GCC 7 compared to GCC 5.
> Changing the default compiler from GCC 5 to GCC 7 is no big problem, the
> problems are the regressions we are not aware of by now, if we change
> the default compiler for all architectures to GCC 7 we should probably
> wait 4 weeks before doing an RC release to be sure most of the runtime
> problems with GCC 7 are found.
>
> If we do the switch to GCC 7 I think we should also change binutils from
> 2.28 to 2.28.1 or 2.29.1. I found this problem with binutils 2.28 which
> was already fixed in 2.28.1:
> https://git.openwrt.org/bcd17ce9a3308accc30d99f4dd43f2062bb3fabc
> The minor versions contains more bugfixes.
>
>
> There is also a pull request for busybox 2.28.1 at github, this will
> probably also introduce some more regressions, so I am not sure if we
> should take it before or after the release.
> https://github.com/openwrt/openwrt/pull/733
> I do not have a real opinion on this and I am probably the wrong person
> to judge this.
Likewise. I vote for getting it in.
>
>
> I do not know what the status of the software fast path patches are, but
> they are looking interesting.
>
>
> My proposal would be to update all targets to GCC 7.3 and also use
> binutils 2.29.1 and musl 1.1.19. This change would be done as soon as
> possible and then we branch of end of March or beginning of April for
> 18.X and do a RC1 one week after creating the branch.
>
> Hauke
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] kernel: bump 4.4 to 4.4.120 for 17.01

2018-03-04 Thread Stijn Segers 
Bump the 4.4 kernel for the 17.01 release to 4.4.119. Refresh patches.

Compile-tested: ar71xx, ramips/mt7621, x86/64
Run-tested: ar71xx, x86/64

Signed-off-by: Stijn Segers 
---
 include/kernel-version.mk  |  4 +--
 .../patches-4.4/910-unaligned_access_hacks.patch   |  2 +-
 .../patches-4.4/0029-Add-dwc_otg-driver.patch  |  2 +-
 ...fd-Add-Raspberry-Pi-Sense-HAT-core-driver.patch |  2 +-
 .../patches-4.4/0551-kbuild-add-fno-PIE.patch  |  2 +-
 ...d-Steal-gcc-s-pie-from-the-very-beginning.patch |  2 +-
 .../patches-4.4/201-extra_optimization.patch   |  2 +-
 .../patches-4.4/202-reduce_module_size.patch   |  2 +-
 .../generic/patches-4.4/204-module_strip.patch | 13 ---
 .../666-Add-support-for-MAP-E-FMRs-mesh-mode.patch | 40 +++---
 ...jecting-with-source-address-failed-policy.patch | 18 +-
 .../patches-4.4/901-debloat_sock_diag.patch|  2 +-
 .../096-08-usb-dwc3-remove-num_event_buffers.patch | 12 +++
 .../096-09-usb-dwc3-drop-ev_buffs-array.patch  |  4 +--
 ...Added-FSL-MC-specific-member-to-the-msi_d.patch |  4 +--
 ...-dts-mediatek-add-xHCI-usb-phy-for-mt8173.patch |  2 +-
 ...mtd-backport-v4.7-0day-patches-from-Boris.patch |  9 ++---
 ...mtd-backport-v4.7-0day-patches-from-Boris.patch |  9 ++---
 .../linux/oxnas/patches-4.4/800-oxnas-ehci.patch   |  2 +-
 19 files changed, 63 insertions(+), 70 deletions(-)

diff --git a/include/kernel-version.mk b/include/kernel-version.mk
index 7fe6e7910b..5cc0200893 100644
--- a/include/kernel-version.mk
+++ b/include/kernel-version.mk
@@ -3,10 +3,10 @@
 LINUX_RELEASE?=1
 
 LINUX_VERSION-3.18 = .43
-LINUX_VERSION-4.4 = .116
+LINUX_VERSION-4.4 = .120
 
 LINUX_KERNEL_HASH-3.18.43 = 
1236e8123a6ce537d5029232560966feed054ae31776fe8481dd7d18cdd5492c
-LINUX_KERNEL_HASH-4.4.116 = 
566fea5814627ee65cc1e6b9c4bfe2f7642ac36b6185e2a3dcb9e8ba1e325fa3
+LINUX_KERNEL_HASH-4.4.120 = 
a25f07372a2661c577e3c8a395bfb4a9f277518a01d097275604eccd3689f478
 
 ifdef KERNEL_PATCHVER
   LINUX_VERSION:=$(KERNEL_PATCHVER)$(strip $(LINUX_VERSION-$(KERNEL_PATCHVER)))
diff --git a/target/linux/ar71xx/patches-4.4/910-unaligned_access_hacks.patch 
b/target/linux/ar71xx/patches-4.4/910-unaligned_access_hacks.patch
index 9a440b4505..72d964df63 100644
--- a/target/linux/ar71xx/patches-4.4/910-unaligned_access_hacks.patch
+++ b/target/linux/ar71xx/patches-4.4/910-unaligned_access_hacks.patch
@@ -310,7 +310,7 @@
if (t->parms.flags & IP6_TNL_F_USE_ORIG_FWMARK)
 --- a/net/ipv6/ip6_tunnel.c
 +++ b/net/ipv6/ip6_tunnel.c
-@@ -1410,7 +1410,7 @@ ip6ip6_tnl_xmit(struct sk_buff *skb, str
+@@ -1307,7 +1307,7 @@ ip6ip6_tnl_xmit(struct sk_buff *skb, str
  
dsfield = ipv6_get_dsfield(ipv6h);
if (t->parms.flags & IP6_TNL_F_USE_ORIG_TCLASS)
diff --git a/target/linux/brcm2708/patches-4.4/0029-Add-dwc_otg-driver.patch 
b/target/linux/brcm2708/patches-4.4/0029-Add-dwc_otg-driver.patch
index 1f652dc998..561fcaed10 100644
--- a/target/linux/brcm2708/patches-4.4/0029-Add-dwc_otg-driver.patch
+++ b/target/linux/brcm2708/patches-4.4/0029-Add-dwc_otg-driver.patch
@@ -4592,7 +4592,7 @@ dwc_otg: Remove duplicate gadget probe/unregister function
 +module_exit(fsg_cleanup);
 --- a/drivers/usb/host/Kconfig
 +++ b/drivers/usb/host/Kconfig
-@@ -735,6 +735,19 @@ config USB_HWA_HCD
+@@ -737,6 +737,19 @@ config USB_HWA_HCD
  To compile this driver a module, choose M here: the module
  will be called "hwa-hc".
  
diff --git 
a/target/linux/brcm2708/patches-4.4/0083-mfd-Add-Raspberry-Pi-Sense-HAT-core-driver.patch
 
b/target/linux/brcm2708/patches-4.4/0083-mfd-Add-Raspberry-Pi-Sense-HAT-core-driver.patch
index e3101e0131..859a08db3a 100644
--- 
a/target/linux/brcm2708/patches-4.4/0083-mfd-Add-Raspberry-Pi-Sense-HAT-core-driver.patch
+++ 
b/target/linux/brcm2708/patches-4.4/0083-mfd-Add-Raspberry-Pi-Sense-HAT-core-driver.patch
@@ -390,7 +390,7 @@ Subject: [PATCH] mfd: Add Raspberry Pi Sense HAT core driver
 +
 --- a/drivers/video/fbdev/Kconfig
 +++ b/drivers/video/fbdev/Kconfig
-@@ -2505,3 +2505,16 @@ config FB_SM712
+@@ -2506,3 +2506,16 @@ config FB_SM712
  This driver is also available as a module. The module will be
  called sm712fb. If you want to compile it as a module, say M
  here and read .
diff --git a/target/linux/brcm2708/patches-4.4/0551-kbuild-add-fno-PIE.patch 
b/target/linux/brcm2708/patches-4.4/0551-kbuild-add-fno-PIE.patch
index 5bfbbf667c..c3b5adc7c4 100644
--- a/target/linux/brcm2708/patches-4.4/0551-kbuild-add-fno-PIE.patch
+++ b/target/linux/brcm2708/patches-4.4/0551-kbuild-add-fno-PIE.patch
@@ -29,7 +29,7 @@ Signed-off-by: Greg Kroah-Hartman 
 
 --- a/Makefile
 +++ b/Makefile
-@@ -622,6 +622,8 @@ KBUILD_CFLAGS  += $(call cc-disable-warni
+@@ -624,6 +624,8 @@ KBUILD_CFLAGS  += $(call cc-disable-warni
  KBUILD_CFLAGS += $(call cc-disable-warning, format-truncation)
  KBUILD_CFLAGS += $(call cc-disable-warning,

Re: [LEDE-DEV] 18.03/4 -> GCC 5 or 7

2018-03-04 Thread Hauke Mehrtens 
On 03/04/2018 04:40 PM, Felix Fietkau wrote:
> On 2018-03-04 16:15, Hauke Mehrtens wrote:
>> There is also a pull request for busybox 2.28.1 at github, this will
>> probably also introduce some more regressions, so I am not sure if we
>> should take it before or after the release.
>> https://github.com/openwrt/openwrt/pull/733
>> I do not have a real opinion on this and I am probably the wrong person
>> to judge this.
> Anything useful in there?

I haven't seen there anything useful, except support for some new MIPS
ISAs, but I do not know if they ever will be relevant.
binutils:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=binutils/NEWS;hb=refs/tags/binutils-2_30
gas:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=gas/NEWS;hb=refs/tags/binutils-2_30
ld:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=ld/NEWS;hb=refs/tags/binutils-2_30

>> I do not know what the status of the software fast path patches are, but
>> they are looking interesting.
> I think the flow offload support will be ready soon. So far it's looking
> good aside from some issues with TCP connection timeout handling that
> I'm going to deal with soon. We should make it clear that those patches
> are still experimental though.
> 
>> My proposal would be to update all targets to GCC 7.3 and also use
>> binutils 2.29.1 and musl 1.1.19. This change would be done as soon as
>> possible and then we branch of end of March or beginning of April for
>> 18.X and do a RC1 one week after creating the branch.
> Fine with me. I'll run some more test builds for various architectures.

Hauke

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] 18.03/4 -> GCC 5 or 7

2018-03-04 Thread Felix Fietkau 
On 2018-03-04 16:15, Hauke Mehrtens wrote:
> There is also a pull request for busybox 2.28.1 at github, this will
> probably also introduce some more regressions, so I am not sure if we
> should take it before or after the release.
> https://github.com/openwrt/openwrt/pull/733
> I do not have a real opinion on this and I am probably the wrong person
> to judge this.
Anything useful in there?

> I do not know what the status of the software fast path patches are, but
> they are looking interesting.
I think the flow offload support will be ready soon. So far it's looking
good aside from some issues with TCP connection timeout handling that
I'm going to deal with soon. We should make it clear that those patches
are still experimental though.

> My proposal would be to update all targets to GCC 7.3 and also use
> binutils 2.29.1 and musl 1.1.19. This change would be done as soon as
> possible and then we branch of end of March or beginning of April for
> 18.X and do a RC1 one week after creating the branch.
Fine with me. I'll run some more test builds for various architectures.

- Felix

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] 18.03/4 -> GCC 5 or 7

2018-03-04 Thread Hauke Mehrtens 
On 02/16/2018 01:46 PM, John Crispin wrote:
> Hi,
> 
> whats on the critical todo list for the upcoming release ? i still have
> a few minor things that I'll be adding shortly, apart from that I am
> currently not aware of any huge problems. the release will be a mix
> between 4.9 and 4.14 afaik !?

I think the kernel situation is ok now and not blocking a release, we
will have a mixed kernel 4.9 and 4.14 release. All important targets are
on one of these two kernel versions by now.
The patches for the gemini target will probably get included soon.
Some targets will probably be updated from 4.9 to 4.14, but this is not
blocking.


What do we want to do with GCC 5.5 versus 7.3?
GCC 5.5 is getting old, we have multiple problems with it, the big
blocker for GCC 7 was just fixed upstream and we backported that fix.
see: http://git.openwrt.org/25aaff9100065dba881be71b9dcab1e9cc8a7b5f
The x86 and x86_64 architectures are already on GCC 7.3, the ARC
architecture uses their own GCC fork based on version 7.X all other
architectures are on GCC 5.5.

We have the following problems with GCC 5.5:
 * U-Boot depends on GCC 6 or higher since version 2018.01 on ARM and ARM64
  * GCC 5 and older are producing too big binaries, e.g. the SPL on the
Allwinner A64 (sunxi, ARM64) is getting too big starting with U-Boot
2017.09 and does not fit into the SRAM any more, GCC 7 solves this problem.
 * busybox on the gemini target updated to kernel 4.14 does not work
correctly.
 * GCC 5.5 only has out of tree fixes for Spectre, GCC 7.3 already has
the retpoline fixes against Spectre included

As the x86 target use GCC 7.3 now, there are multiple pull requests
fixing some build problems in some packages with GCC 7.
I am not aware of any regressions in GCC 7 compared to GCC 5.
Changing the default compiler from GCC 5 to GCC 7 is no big problem, the
problems are the regressions we are not aware of by now, if we change
the default compiler for all architectures to GCC 7 we should probably
wait 4 weeks before doing an RC release to be sure most of the runtime
problems with GCC 7 are found.

If we do the switch to GCC 7 I think we should also change binutils from
2.28 to 2.28.1 or 2.29.1. I found this problem with binutils 2.28 which
was already fixed in 2.28.1:
https://git.openwrt.org/bcd17ce9a3308accc30d99f4dd43f2062bb3fabc
The minor versions contains more bugfixes.


There is also a pull request for busybox 2.28.1 at github, this will
probably also introduce some more regressions, so I am not sure if we
should take it before or after the release.
https://github.com/openwrt/openwrt/pull/733
I do not have a real opinion on this and I am probably the wrong person
to judge this.


I do not know what the status of the software fast path patches are, but
they are looking interesting.


My proposal would be to update all targets to GCC 7.3 and also use
binutils 2.29.1 and musl 1.1.19. This change would be done as soon as
possible and then we branch of end of March or beginning of April for
18.X and do a RC1 one week after creating the branch.

Hauke

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Spectre vulnerability & LEDE 17.01 release

2018-03-04 Thread Hauke Mehrtens 
On 02/27/2018 11:37 AM, Rafał Miłecki wrote:
> There has been some talk on upcoming 17.01 fix release and Meltdown/Spectre.
> 
> Quick summary:
> 1) Most of LEDE supported devices aren't affected
> 2) For most LEDE use cases these vulnerabilities don't matter
> 3) 17.01 uses 4.4.116 which includes Meltdown fixes
> 4) Spectre mitigation requires newer GCC and CPU microcode update
> 5) Zoltan did some progress on x86 microcode update support
> 
> So right now in some specific cases (mostly when running an unverified
> software) Spectre may be a problem.
> 
> There are two problems solving it:
> 
> 1) Microcode updates are not (fully) available yet
> It's unclear how long it will take Intel to release updates microcodes.
> 
> 2) GCC officially supports Spectre mitigation in 7.2 and 8.0
> LEDE 17.01 uses GCC 5.4. It seems fixes are unofficially backported to the 
> 5.5:
> https://github.com/hjl-tools/gcc/commits/hjl/indirect/gcc-5-branch/master
> So the only solution for LEDE is to switch from 5.4 to 5.5 and apply
> backported fixes. I'm not sure how safe it's going to be (possible
> regressions caused by 5.5 update).
> 
> If I'm wrong about anything, please let me know.
> 
> In this situation my suggestion it to release 17.01.5 now and take
> care of Spectre in another release in few months from now. What do you
> think? Any objections?

I agree with you. We should do the LEDE 17.01.5 release now with the
current state, there are already many other bugfixes in the the lede
17.01 branch some for security problems which probably can be abused
much easier in most of the common OpenWrt uses cases that Spectre.

I would also wait with the ARM Spectre fixes till this code hits the 4.4
LTS kernel tree and then we can release it in lede 17.01.6 in some months.

I am, not sure if we should update the GCC at all or if users that
really want these fixes should go to OpenWrt 18.X.

mbedtls 2.7 fixed 2 security problems in their last release, but this
version is ABI incompatible but API compatible with the previous
version, should I backport the commits or should I increase the
PKG_RELEASE number for all depended packages?

This is my personal opinion on this topic.

Hauke

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Can ramips use mt7530 switch driver from mainline?

2018-03-04 Thread Hauke Mehrtens 
On 02/28/2018 11:34 AM, Marek Behun wrote:
> Hello,
> 
> the mt7530 switch driver is now in mainline kernel as a DSA driver. The
> LEDE ramips target ethernet driver though doesn't use it yet, and I've
> been thinking what all would have to be done to port the ethernet
> driver to use it, if it even is possible.
> 
> For example, the mt7530 dsa driver device tree binding needs
> regulator definitions (core-supply, io-supply). I haven't seen these
> nowhere in the mt7621 device trees nor in the code. Any ideas?

I think the biggest missing part is a good migration path. Currently the
users have some configurations based on swconfig and this has to be
ported to the DSA configuration model. If someone could create a script
which does the migration of an existing swconfig configuration to a DSA
based configuration that would be very helpful.

Hauke

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH hauke/kernel-4.14-sunxi 0/4] add LEDE support for NanoPi NEO Plus2 board

2018-03-04 Thread Hauke Mehrtens 
On 03/02/2018 03:09 PM, Antony Antony wrote:
> Hi Hauke,
> 
> I am glad to see you are testig "NanoPi Neo Plus2" support in OpenWRT.
> Here is a patch instead of b7a1aa4df2a983, with Gigabit Ethernet support.
> 
> https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=blob;f=target/linux/sunxi/patches-4.14/061-arm-dts-sun50i-support-for-nanopi-neo-plus2-board.patch;h=535c8b6d1f816480eb2938f54e520f7b4311b970;hb=b7a1aa4df2a9834bb7339712670abbe1a05dc01c
> 
> do not have emac node.
> 
> regards,
> -antony

Hi Antony,

Your patch is already integrated in the OpenWrt master branch. Can you
please send a patch which adds the additional settings to the device
tree on top of the current OpenWrt master branch.

Hauke

> 
> On Fri, Dec 29, 2017 at 01:53:46PM +0100, Hauke Mehrtens wrote:
>> Hi antony,
>>
>> On 12/28/2017 06:21 PM, Antony Antony wrote:
>>> Hi Hauke,
>>>
>>> This will add initial LEDE support for a new board, NanoPi NEO Plus2 board.
>>>
>>> LEDE menu options, u-boot, and kernel DT files. The patches are against 
>>> hauke/kernel-4.14-sunxi branch.
>>
>> Ok this is my development branch, now I send the patches to the list.
>>
>>> The patches are in upstream.
>>> Kernel DT initial support is in 4.15 and Gigabit support is queued for 4.16.
>>> u-boot support is #master, it will be in 2018.01
>>
>> You split the patches in a strange way.
>> I would suggest to have only two patches, one adding the changes needed
>> for U-Boot and one for the kernel and image build. Your current split
>> will have problems with git bisect when only your first patch is applied.
>>
>> Otherwise these patches are looking good.
>>
>>> regards,
>>> -antony
>>>
>>> Antony Antony (4):
>>>   sunxi: add support for NanoPi NEO Plus2 board
>>>   sunxi: add u-boot DT for NanoPi NEO Plus2 board
>>>   sunxi: add DT node, dwmac ethernet for Nano Pi Neo Plus2
>>>   sunxi: add kernel DT for NanoPi NEO Plus2 board
>>>
>>>  package/boot/uboot-sunxi/Makefile  |   9 +
>>>  .../210-add-sunxi50i-nanopi-neo-plus2.patch| 176 
>>>  target/linux/sunxi/image/cortex-a53.mk |  10 +
>>>  ...sun50i-support-for-nanopi-neo-plus2-board.patch | 229 
>>> +
>>>  ...-dts-sun50i-nanopi-neo-plus2-add-ethernet.patch |  46 +
>>>  5 files changed, 470 insertions(+)
>>>  create mode 100644 
>>> package/boot/uboot-sunxi/patches/210-add-sunxi50i-nanopi-neo-plus2.patch
>>>  create mode 100644 
>>> target/linux/sunxi/patches-4.14/061-arm-dts-sun50i-support-for-nanopi-neo-plus2-board.patch
>>>  create mode 100644 
>>> target/linux/sunxi/patches-4.14/062-arm-dts-sun50i-nanopi-neo-plus2-add-ethernet.patch
>>>


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] Migrating packages from oldpackages to packages

2018-03-04 Thread Hauke Mehrtens 
On 03/04/2018 11:39 AM, Peter Denison wrote:
> When migrating a package from the unmaintained 'oldpackages' feed to the
> main 'packages' feed:
> 
> 1) Should I try to preserve history? If so, how do I do that on just one
> directory (my git-fu is not that good)?

No this is not needed, you can add this in one commit. Just mention in
the commit message where you have copied it from.

> 2) Is it acceptable / preferable to do two commits, one to move the
> package as is, and a second to bring it up to date and fix its building,
> or should it just be a single commit?

You can do this in one commit.

> 3) Do I need to do anything other than a pull request on github to offer
> to maintain a package? (Presumably also a pull request to delete it from
> oldpackages)

No not really, you should probably update the package to a more recent
version I assume that version in oldpackage is outdated.

Hauke

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] sunxi: bpi-r1 switch configuration missing in latest development trunk for 18.0x

2018-03-04 Thread TheWerthFam 
Full kernel log below. I remove the 8192cu wifi driver since it doesn't 
work in AP mode and use a rt2800 base usb dongle.. Additionally grep 
output of config-4.14 for SWCONFIG

grep SWCONFIG target/linux/sunxi/config-4.14
CONFIG_SWCONFIG=y
CONFIG_SWCONFIG_B53=y
# CONFIG_SWCONFIG_B53_MMAP_DRIVER is not set
CONFIG_SWCONFIG_B53_PHY_DRIVER=y
CONFIG_SWCONFIG_B53_PHY_FIXUP=y
# CONFIG_SWCONFIG_B53_SRAB_DRIVER is not set

kernel log
[    0.00] Booting Linux on physical CPU 0x0
[    0.00] Linux version 4.14.20 (dandv@t420s) (gcc version 5.5.0 
(OpenWrt GCC 5.5.0 r6351-694f0bb5af)) #0 SMP PREEMPT Fri Mar 2 14:58:09 2018
[    0.00] CPU: ARMv7 Processor [410fc074] revision 4 (ARMv7), 
cr=30c5387d

[    0.00] CPU: div instructions available: patching division code
[    0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache

[    0.00] OF: fdt: Machine model: Lamobo R1
[    0.00] Memory policy: Data cache writealloc
[    0.00] On node 0 totalpages: 262144
[    0.00] free_area_init_node: node 0, pgdat c0c4f040, node_mem_map 
ef7fa000

[    0.00]   Normal zone: 1536 pages used for memmap
[    0.00]   Normal zone: 0 pages reserved
[    0.00]   Normal zone: 196608 pages, LIFO batch:31
[    0.00]   HighMem zone: 65536 pages, LIFO batch:15
[    0.00] psci: probing for conduit method from DT.
[    0.00] psci: Using PSCI v0.1 Function IDs from DT
[    0.00] random: get_random_bytes called from 
start_kernel+0x90/0x400 with crng_init=0
[    0.00] percpu: Embedded 16 pages/cpu @ef7be000 s34188 r8192 
d23156 u65536

[    0.00] pcpu-alloc: s34188 r8192 d23156 u65536 alloc=16*4096
[    0.00] pcpu-alloc: [0] 0 [0] 1
[    0.00] Built 1 zonelists, mobility grouping on.  Total pages: 260608
[    0.00] Kernel command line: console=ttyS0,115200 earlyprintk 
root=/dev/mmcblk0p2 rootwait

[    0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
[    0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 
bytes)
[    0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 
bytes)
[    0.00] Memory: 1028452K/1048576K available (4766K kernel code, 
318K rwdata, 1368K rodata, 2048K init, 245K bss, 20124K reserved, 0K 
cma-reserved, 262144K highmem)

[    0.00] Virtual kernel memory layout:
[    0.00] vector  : 0x - 0x1000   (   4 kB)
[    0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
[    0.00] vmalloc : 0xf080 - 0xff80   ( 240 MB)
[    0.00] lowmem  : 0xc000 - 0xf000   ( 768 MB)
[    0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
[    0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
[    0.00]   .text : 0xc0008000 - 0xc06a78e0   (6783 kB)
[    0.00]   .init : 0xc0a0 - 0xc0c0   (2048 kB)
[    0.00]   .data : 0xc0c0 - 0xc0c4f940   ( 319 kB)
[    0.00]    .bss : 0xc0c55d7c - 0xc0c9344c   ( 246 kB)
[    0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[    0.00] Preemptible hierarchical RCU implementation.
[    0.00]     RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=2.
[    0.00]     Tasks RCU enabled.
[    0.00] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
[    0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[    0.00] GIC: Using split EOI/Deactivate mode
[    0.00] arch_timer: cp15 timer(s) running at 24.00MHz (phys).
[    0.00] clocksource: arch_sys_counter: mask: 0xff 
max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns
[    0.08] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps 
every 4398046511097ns

[    0.21] Switching to timer-based delay loop, resolution 41ns
[    0.000560] clocksource: timer: mask: 0x max_cycles: 
0x, max_idle_ns: 79635851949 ns
[    0.000843] clocksource: hstimer: mask: 0x max_cycles: 
0x, max_idle_ns: 12741736309 ns

[    0.001002] Console: colour dummy device 80x30
[    0.001040] Calibrating delay loop (skipped), value calculated using 
timer frequency.. 48.00 BogoMIPS (lpj=24)

[    0.001057] pid_max: default: 32768 minimum: 301
[    0.001195] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.001212] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 
bytes)

[    0.001763] CPU: Testing write buffer coherency: ok
[    0.002112] /cpus/cpu@0 missing clock-frequency property
[    0.002133] /cpus/cpu@1 missing clock-frequency property
[    0.002149] CPU0: thread -1, cpu 0, socket 0, mpidr 8000
[    0.039933] Setting up static identity map for 0x4020 - 0x40200060
[    0.059925] Hierarchical SRCU implementation.
[    0.099986] smp: Bringing up secondary CPUs ...
[    0.180401] CPU1: thread -1, cpu 1, socket 0, mpidr 8001
[    0.180532] smp: Brought up 1 node, 2 CPUs
[    0.180549] SMP: Total of 2 processors activated (96.00 BogoMIPS).
[    0.180557] CPU: All CPU(s)