Re: [OpenWrt-Devel] Issue connecting with Quectel EM20-G modem on openwrt

[Nick via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
FWIW, I’m able to use this modem just fine on a USB3.0 M.2 slot with the 
current version of MM and libqmi.  Let me know if you need any details.
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] build: always use -minterlink-mips16 if USE_MIPS16

[Eneas U de Queiroz]

Individual packages may turn off MIPS16 ISA individually with
PKG_USE_MIPS16.  However, they may link to a library compiled with
MIPS16.  In such cases, the -minterlink-mips16 is needed to ensure there
are no direct jumps to code compiled with a different ISA.

Instead of adding -minterlink-mips16 only when PKG_USE_MIPS16 is on, add
it when global USE_MIPS16 is on.

Signed-off-by: Eneas U de Queiroz 
---
Tested by compiling all packages in base, packages, routing and
telephony feeds for mips_74kc, with MIPS16 enabled.

This was discovered while working on lxc fixes 
(https://github.com/openwrt/packages/pull/12241), where compilation with
mips16 would fail because of '-fstack-check=specific not implemented for
MIPS16', and it would fail with PKG_USE_MIPS16=0 because of jumping to a
different ISA mode:

lxc-4.0.2/src/lxc/caps.c:24:(.text+0xa4): unsupported jump between ISA
modes; consider recompiling with interlinking enabled

In theory this could happen in more places, so set interlinking on
whenever MIPS16 is turned on globally.

diff --git a/include/package.mk b/include/package.mk
index 0575692742..f2c699ef2f 100644
--- a/include/package.mk
+++ b/include/package.mk
@@ -25,10 +25,11 @@ else
 PKG_JOBS?=$(if $(PKG_BUILD_PARALLEL),$(MAKE_J),-j1)
 endif
 ifdef CONFIG_USE_MIPS16
+  TARGET_ASFLAGS_DEFAULT = $(filter-out -mips16 
-minterlink-mips16,$(TARGET_CFLAGS))
   ifeq ($(strip $(PKG_USE_MIPS16)),1)
-TARGET_ASFLAGS_DEFAULT = $(filter-out -mips16 
-minterlink-mips16,$(TARGET_CFLAGS))
-TARGET_CFLAGS += -mips16 -minterlink-mips16
+TARGET_CFLAGS += -mips16
   endif
+  TARGET_CFLAGS += -minterlink-mips16
 endif
 ifeq ($(strip $(PKG_IREMAP)),1)
   IREMAP_CFLAGS = $(call iremap,$(PKG_BUILD_DIR),$(notdir $(PKG_BUILD_DIR)))

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [sdwalker/sdwalker.github.io] a33bb0: This week's update

[Stephen Walker]

  Branch: refs/heads/master
  Home:   https://github.com/sdwalker/sdwalker.github.io
  Commit: a33bb0d72905082885c013e87c28e8bcbde808d5
  
https://github.com/sdwalker/sdwalker.github.io/commit/a33bb0d72905082885c013e87c28e8bcbde808d5
  Author: Stephen Walker 
  Date:   2020-05-24 (Sun, 24 May 2020)

  Changed paths:
M uscan/index-18.06.html
M uscan/index-19.07.html
M uscan/index.html

  Log Message:
  ---
  This week's update



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v4] ramips: add support for TRENDnet TEW-810DR

[mail]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Heppler, J. Scott
> Sent: Donnerstag, 7. Mai 2020 18:03
> To: openwrt-de...@openwrt.org
> Subject: [OpenWrt-Devel] [PATCH v4] ramips: add support for TRENDnet
> TEW-810DR
> 
> Information for reviewers:
> By report, FCCid and board photos, this device shares a Cameo manufactured
> board with the D-Link DIR-810L.  The DIR-810L dts does not enable GPIO40 for
> the Green Internet/Globe lan led. The TEW-810DR dts should be applicable
> to the DIR-810L and would provide improved Green Internet/Globe lan led
> configurability.  I believe that it would be efficient to test the potential 
> DIR-
> 810L changes prior to generating a *.dtsi.  I do not have a DIR-810L to test. 
>  I
> also reverted the spi-max-frequency to <1000> based on a forum report
> of instability.  Forum links detailing development:
> https://forum.openwrt.org/t/trendnet-tew-810dr-leds/56601
> https://forum.openwrt.org/t/trendnet-tew-810dr-mtd-partition/59676
> 
> Changes to be committed:
>   new file:   target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts
>   modified:   target/linux/ramips/image/mt7620.mk
>   modified:   target/linux/ramips/mt7620/base-
> files/etc/board.d/01_leds
>   modified:   target/linux/ramips/mt7620/base-
> files/etc/board.d/02_network

These comments should be added after the body of the commit message, separated 
by a line containing "---", so the patchwork will cut it off automatically when 
the patch is added to the repository.

> 
> Specification:
> 
> * MediaTek MT7620A (580 Mhz)
> * 8 MB of FLASH
> * 64 MB of RAM
> * 2.4Ghz and 5.0Ghz radios functional
> * 5x 10/100 Mbps Ethernet (1 WAN and 4 LAN)
> * UART header on PCB (57600 8n1)
> * Green/Orange Power LEDs illuminating a Power-Button Lens
>   Green/Orange Internet LEDs GPIO controlled illuminating a Globe/Internet
> Lens
> * 3x button - wps, power and reset
> * U-boot bootloader
> 
> Installation:
> 
> The sysupgrade.bin image is reported to be OEM web flashed with an
> ncc_att_hwid appended.  ncc_att_hwid is available in the GPL Source
> download for either the TEW-810DR or DIR-810L and is located at
> source/user/wolf/cameo/ncc/hostTools.
> In Debian 10 amd64, 32bit libs are needed.  The invocation is:
> ncc_att_hwid -f tew-810-squashfs-factory.bin -a -m “TEW-810DR” -H “1.0R” -r
> “WW” -c “1.0”.  This may need to be altered if your hardware version is
> "1.1R".
> More information is available in the device page for TEW-810DR.  See the
> device pages for the DIR-810L and TEW-810DR for more information.  The
> image can also be reliable flashed via tftpboot as described in this OpenWrt
> forum
> thread:
> https://forum.openwrt.org/t/trendnet-tew-810dr-mtd-partition/59676.

I don't think a forum thread is a good source for a manual (it might be if you 
want to document discussion).

Please just add the additional information to the commit message, or add it to 
the device Wiki page if it's too long (I prefer the former).

Please also try to structure the installation comments so they are easier to 
read.

You are also missing a Signed-off-by for this patch.

> ---
>  .../ramips/dts/mt7620a_trendnet_tew-810dr.dts | 166
> ++
>  target/linux/ramips/image/mt7620.mk   |  10 ++
>  .../mt7620/base-files/etc/board.d/01_leds |   3 +
>  .../mt7620/base-files/etc/board.d/02_network  |   4 +-
>  4 files changed, 182 insertions(+), 1 deletion(-)  create mode 100644
> target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts
> 
> diff --git a/target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts
> b/target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts
> new file mode 100644
> index 00..cba646f76e
> --- /dev/null
> +++ b/target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts
> @@ -0,0 +1,166 @@
> +/dts-v1/;

Please add an SPDX license identifier.

> +
> +#include "mt7620a.dtsi"
> +
> +#include 
> +#include 
> +
> +/ {
> + compatible = "trendnet,tew-810dr", "ralink,mt7620a-soc";
> + model = "TRENDnet TEW-810DR";
> +
> + aliases {
> + led-boot = _power_green;
> + led-failsafe = _power_green;
> + led-running = _power_green;
> + led-upgrade = _power_green;
> + label-mac-device = 
> + };
> +
> + keys {
> + compatible = "gpio-keys-polled";
> + poll-interval = <20>;

Please try with gpio-keys instead (poll-interval can be dropped then).

> +
> + reset {
> + label = "reset";
> + gpios = < 1 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> +
> + wps {
> + label = "wps";
> + gpios = < 2 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led_power_green: 

Re: [OpenWrt-Devel] Fix for missing kernel stack-protector in x86_64 glibc builds

[Ian Cooper]

Hauke, patch in git format attached

Regarding uclibc, the only references I could find spoke about a SSP patch that 
was committed and then reverted. I'd have to browse the source to be sure 
whether it supports it or not. 

To note about this change: there is another symbol in toolchain/Config.in that 
I left untouched, mainly because the only place it was being used in the main 
repo was by the binutils Makefile, which is using it in a musl /gcc libssp 
specific way

toolchain/Config.in:

config SSP_SUPPORT
default y if USE_MUSL || GCC_LIBSSP
bool

toolchain/binutils/Makefile:

ifneq ($(CONFIG_SSP_SUPPORT),)
  HOST_CONFIGURE_ARGS+= \
--enable-libssp
else
  HOST_CONFIGURE_ARGS+= \
--disable-libssp
Endif

I'm not convinced that this option is required in any case, since this is for 
the host build. So not selecting it with USE_GLIBC is the right thing to do 
here.

Then there are 3 packages in the feeds that refer to this symbol:  avahi, tor 
and cjdns, all of them in a more or less erroneous way

feeds/packages/libs/avahi/Makefile:

TARGET_LDFLAGS += $(if $(CONFIG_SSP_SUPPORT),-lssp_nonshared

This is musl specific and I also question if it is needed since the build 
system should automatically link in ssp_nonshared for musl. There's a patch in 
toolchain/musl which adds libssp_nonshared to the ALL_LIBS symbol. So I suspect 
as well that this line can be removed from the package Makefile. It's also 
managed to work even with GCC_LIBSSP selecting CONFIG_SSP_SUPPORT even though 
the library won't exist, since libssp_nonshared is musl specific. So it can 
probably also be ignored for the meantime but should be fixed sometime, as it's 
wrong. 

Again, not setting the CONFIG_SSP_SUPPORT for USE_GLIBC  in this case is also 
correct. 

feeds/packages/net/tor/Makefile:

ifneq ($(CONFIG_SSP_SUPPORT),y)
CONFIGURE_ARGS += \
--disable-gcc-hardening
else
EXTRA_CFLAGS += $(FPIC)
Endif

According to the commit for tor that introduced this flag,

--enable-gcc-hardening
This turns on gcc compile time hardening options. It ensures that
signed ints have defined behavior (-fwrapv), -D_FORTIFY_SOURCE=2 is
enabled (requiring -O2), stack smashing protection with canaries
(-fstack-protector-all), ASLR protection if supported by the kernel
(-fPIE, -pie). Additional security related warnings are enabled.
Verified as working on Mac OS X and Debian Lenny.

So I'm not sure that even specifying this compiler option is the right thing to 
do as it's going to blindly enable a bunch of things that are all separately 
controlled by openwrt. The package will clearly compile without it enabled, but 
is likely to error out with it enabled, if for example, -O2 is not set. So once 
more, not setting CONFIG_SSP_SUPPORT is the right solution.

Feeds/routing/cjdns/Makefile:

It passes through a make variable to the cjdns build

define Build/Compile
$(INSTALL_DIR) $(BUILD_DIR)/$(PKG_SOURCE_VERSION)/tmp
(cd $(BUILD_DIR)/$(PKG_SOURCE_VERSION) && \
CROSS="true" \
CC="$(TARGET_CC)" \
AR="$(TARGET_AR)" \
RANLIB="$(TARGET_RANLIB)" \
CFLAGS="$(TARGET_CFLAGS) -U_FORTIFY_SOURCE" \
LDFLAGS="$(TARGET_LDFLAGS)" \
SYSTEM="linux" \
TARGET_ARCH="$(CONFIG_ARCH)" \
SSP_SUPPORT="$(CONFIG_SSP_SUPPORT)" \

Which is used in the package's make.js script thus

switch (process.env['SSP_SUPPORT']) {
case 'y':
case '1': libssp = true; break;
case 'n':
case '' :
case '0': libssp = false; break;
case undefined: break;
default: throw new Error();
}

So this usage is again gcc libssp specific. It will continue to work as 
designed since GCC_LIBSSP sets CONFIG_SSP_SUPPORT and might error is USE_GLIBC 
selects SSP_SUPPORT. But it should be changed in the future to 
SSP_SUPPORT="$(CONFIG_GCC_LIBSSP)"

So, this is why I left the symbol alone and didn't patch anything relating to 
it as everything continues to work as normal with it untouched, whereas 
changing it will introduce errors. 

That said, these usages in both the main repo and the feeds that I've listed 
are not clean and will need to be fixed sometime.


-Original Message-
From: Hauke Mehrtens [mailto:ha...@hauke-m.de] 
Sent: 24 May 2020 13:33
To: Ian Cooper ; openwrt-devel@lists.openwrt.org
Subject: Re: [OpenWrt-Devel] Fix for missing kernel stack-protector in x86_64 
glibc builds

On 5/24/20 2:04 PM, Ian Cooper wrote:
> Patch attached as my email client seems to have mangled it a bit when 
> inserted inline
> 
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] 
> On Behalf Of Ian Cooper
> Sent: 24 May 2020 12:35
> To: openwrt-devel@lists.openwrt.org
> Subject: [OpenWrt-Devel] Fix for missing kernel stack-protector in 
> x86_64 glibc builds
> 
> Hi all,
> 
> Forgive such a long post 

Re: [OpenWrt-Devel] procd fails to start /sbin/netifd randomly (libubox regression)

[Rafał Miłecki]

On 23.05.2020 12:22, Rafał Miłecki wrote:

On 22.05.2020 11:28, Rafał Miłecki wrote:

Failed restart:
Fri May 22 09:22:05 2020 daemon.err procd: [instance_fill_array] 
blobmsg_type(cur): 2 (BLOBMSG_TYPE_TABLE)
Fri May 22 09:22:05 2020 daemon.err procd: [instance_fill_array] BEFORE 
75e300aeec25:
Fri May 22 09:22:05 2020 daemon.err procd: [instance_fill_array] blob_len(cur): 
36
Fri May 22 09:22:05 2020 daemon.err procd: [instance_fill_array] 
blobmsg_check_attr_len(cur, false, 36): 1
Fri May 22 09:22:05 2020 daemon.err procd: [instance_fill_array] 
[for_each_attr] blobmsg_name(sub): core blobmsg_type(sub): 3 
(BLOBMSG_TYPE_STRING)
Fri May 22 09:22:05 2020 daemon.err procd: [instance_fill_array] 
[for_each_attr] blobmsg_name(sub):  blobmsg_type(sub): 5 (BLOBMSG_TYPE_INT32)
Fri May 22 09:22:05 2020 daemon.err procd: [instance_fill_array]  AFTER 
75e300aeec25:
Fri May 22 09:22:05 2020 daemon.err procd: [instance_fill_array] 
blobmsg_len(cur): 24
Fri May 22 09:22:05 2020 daemon.err procd: [instance_fill_array] 
blobmsg_check_attr_len(cur, false, 24): 1
Fri May 22 09:22:05 2020 daemon.err procd: [instance_fill_array] 
[for_each_attr] blobmsg_name(sub): core blobmsg_type(sub): 3 
(BLOBMSG_TYPE_STRING)
Fri May 22 09:22:05 2020 daemon.err procd: [instance_fill_array] blob_attr *cur as JSON: {  
"core": "unlimited" }
Fri May 22 09:22:05 2020 daemon.err procd: [instance_fill_array] 
blobmsg_check_attr_list() failed

As you can see, libubox fix resulted in blobmsg_check_array_len()
actually iterating over sub-attr-s but also failing occasionally.


My observation was reversed. After 75e300aeec25 libubox uses blob_len,
not blobmsg_len. It means that iteration over sub-attr-s in
blobmsg_check_array_len() actually got broken. It's because
__blobmsg_for_each_attr() macro expects *data* len to be passed to it.


Fixed in commit 5e75160f4878 ("blobmsg: fix attrs iteration in the
blobmsg_check_array_len()").

https://git.openwrt.org/?p=project/libubox.git;a=commitdiff;h=5e75160f48785464f9213c6bc8c72b9372c5318b

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Experimental "release goals" for 19.07.4

[Baptiste Jonglez]

On 23-05-20, Michael Jones wrote:
> On Sat, May 23, 2020, 13:01 Baptiste Jonglez 
> wrote:
> 
> > If the initial concept looks good, we can think about automating some of
> > it:
> > tag bug reports on Flyspray/Github/Gitlab as blocking for a specific
> > release, use "milestones", automatically find commits that satisfy a goal,
> > etc.
> >
> 
> 
> I find it very confusing that there are so many different places for bugs
> to live and be tracked.
> 
> What's going on with gitlab? Is that going to be the source of truth for
> OpenWRT? Or will we always have 3 different bug trackers?

Switching to Gitlab is a bigger discussion / project.

Whatever the tools, release goals can be useful, just more or less
difficult to implement / keep track of.  I mean, in any case, some people
need to keep an overview of regression / reports / work-in-progress work
of the different components, and gitlab won't solve all of that magically
even if it makes it easier.

Baptiste


signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v3] ath79/nand: add support for Netgear WNDR4300SW

[mail]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Stijn Segers
> Sent: Samstag, 23. Mai 2020 10:50
> To: openwrt-devel@lists.openwrt.org
> Subject: [OpenWrt-Devel] [PATCH v3] ath79/nand: add support for Netgear
> WNDR4300SW
> 
> This patch adds support for the WNDR4300SW, marketed by California ISP
> SureWest (hence the 'SW' suffix). Hardware wise, it's identical to the
> WNDR4300 v1.

I've merged your patch.

Note that the patch doesn't add an entry for uboot-envtools, maybe you can 
provide a separate patch for that if you care, should be something simple like 
https://github.com/openwrt/openwrt/commit/a09408fa576c6482c21f683662cb2d5a49e14ecf

Best

Adrian

> 
> Specifications:
> * SoC: Atheros AR9344
> * RAM: 128 MB
> * Flash: 128 MB NAND flash
> * WiFi: Atheros AR9580 (5 GHz) and AR9344 (2,4 GHz)
> * Ethernet: 5x 1000Base-T
> * LED: Power, WAN, LAN, WiFi, USB, WPS
> * UART: on board, to the right of the RF shield at the top of the board
> 
> Installation:
> 
> * Flashing through the OEM web interface:
>   + Connect your computer to the router with an ethernet cable and browse
> to http://192.168.1.1/
>   + Log in with the default credentials are admin:password
>   + Browse to Advanced > Administration > Firmware Upgrade in the Netgear
> interface
>   + Upload the Openwrt firmware: openwrt-ath79-nand-
> netgear_wndr4300sw-squashfs-factory.img
>   + Proceed with the firmware installation and give the device a few
> minutes to finish and reboot.
> 
> * Flashing through TFTP:
>   + Configure your wired client with a static IP in the 192.168.1.x range,
> e.g. 192.168.1.10 and netmask 255.255.255.0.
>   + Power off the router.
>   + Press and hold the RESET button (the factory reset button on the bottom
> of the device, with the red circle around it) and turn the router on
> while keeping the button pressed.
>   + The power LED will start flashing orange. You can release the button
> once it switches to flashing green.
>   + Transfer the image over TFTP:
> $ tftp 192.168.1.1 -m binary -c put openwrt-ath79-nand-
> netgear_wndr4300sw-squashfs-factory.img
> 
> Signed-off-by: Stijn Segers 
> ---
>  target/linux/ath79/dts/ar9344_netgear_wndr4300sw.dts   |  9 +
>  target/linux/ath79/image/nand.mk   | 10 ++
>  target/linux/ath79/nand/base-files/etc/board.d/01_leds |  1 +
> .../linux/ath79/nand/base-files/etc/board.d/02_network |  2 ++  .../base-
> files/etc/hotplug.d/firmware/10-ath9k-eeprom  |  2 ++
>  5 files changed, 24 insertions(+)
>  create mode 100644
> target/linux/ath79/dts/ar9344_netgear_wndr4300sw.dts
> 
> diff --git a/target/linux/ath79/dts/ar9344_netgear_wndr4300sw.dts
> b/target/linux/ath79/dts/ar9344_netgear_wndr4300sw.dts
> new file mode 100644
> index 00..fb90eee550
> --- /dev/null
> +++ b/target/linux/ath79/dts/ar9344_netgear_wndr4300sw.dts
> @@ -0,0 +1,9 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT /dts-v1/;
> +
> +#include "ar9344_netgear_wndr.dtsi"
> +
> +/ {
> + compatible = "netgear,wndr4300sw", "qca,ar9344";
> + model = "Netgear WNDR4300SW";
> +};
> diff --git a/target/linux/ath79/image/nand.mk
> b/target/linux/ath79/image/nand.mk
> index 3ccd19914f..dc06b65371 100644
> --- a/target/linux/ath79/image/nand.mk
> +++ b/target/linux/ath79/image/nand.mk
> @@ -172,6 +172,16 @@ define Device/netgear_wndr4300  endef
> TARGET_DEVICES += netgear_wndr4300
> 
> +define Device/netgear_wndr4300sw
> +  SOC := ar9344
> +  DEVICE_MODEL := WNDR4300SW
> +  NETGEAR_KERNEL_MAGIC := 0x33373033
> +  NETGEAR_BOARD_ID := WNDR4300SW
> +  NETGEAR_HW_ID := 29763948+0+128+128+2x2+3x3
> +  $(Device/netgear_ath79_nand)
> +endef
> +TARGET_DEVICES += netgear_wndr4300sw
> +
>  define Device/netgear_wndr4300-v2
>SOC := qca9563
>DEVICE_MODEL := WNDR4300
> diff --git a/target/linux/ath79/nand/base-files/etc/board.d/01_leds
> b/target/linux/ath79/nand/base-files/etc/board.d/01_leds
> index d9989ec538..4f601849fc 100755
> --- a/target/linux/ath79/nand/base-files/etc/board.d/01_leds
> +++ b/target/linux/ath79/nand/base-files/etc/board.d/01_leds
> @@ -14,6 +14,7 @@ glinet,gl-ar300m-nor)
>   ;;
>  netgear,wndr3700-v4|\
>  netgear,wndr4300|\
> +netgear,wndr4300sw|\
>  netgear,wndr4300-v2|\
>  netgear,wndr4500-v3)
>   ucidef_set_led_switch "wan-amber" "WAN (amber)"
> "netgear:amber:wan" "switch0" "0x20"
> diff --git a/target/linux/ath79/nand/base-files/etc/board.d/02_network
> b/target/linux/ath79/nand/base-files/etc/board.d/02_network
> index b2191eed92..84cdfd99bb 100755
> --- a/target/linux/ath79/nand/base-files/etc/board.d/02_network
> +++ b/target/linux/ath79/nand/base-files/etc/board.d/02_network
> @@ -22,6 +22,7 @@ ath79_setup_interfaces()
>   ;;
>   netgear,wndr3700-v4|\
>   netgear,wndr4300|\
> + netgear,wndr4300sw|\
>   netgear,wndr4300-v2|\
>   netgear,wndr4500-v3)
>   ucidef_add_switch "switch0" \
> 

Re: [OpenWrt-Devel] [PATCH] bcm63xx: DGND3700v1: device tree improvements

[Daniel González Cabanelas]

Hi Adrian

El dom., 24 may. 2020 a las 13:15,  escribió:
>
> Hi Daniel,
>
> > -Original Message-
> > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> > On Behalf Of Daniel González Cabanelas
> > Sent: Sonntag, 24. Mai 2020 11:06
> > To: m...@adrianschmutzler.de
> > Cc: openwrt-devel@lists.openwrt.org; Álvaro Fernández Rojas
> > 
> > Subject: Re: [OpenWrt-Devel] [PATCH] bcm63xx: DGND3700v1: device tree
> > improvements
> >
> > Hi Adrian:
> >
> > El dom., 24 may. 2020 a las 1:01,  escribió:
> > >
> > > Hi,
> > >
> > > > -Original Message-
> > > > From: openwrt-devel [mailto:openwrt-devel-
> > boun...@lists.openwrt.org]
> > > > On Behalf Of Daniel González Cabanelas
> > > > Sent: Sonntag, 24. Mai 2020 00:24
> > > > To: openwrt-devel@lists.openwrt.org
> > > > Cc: nolt...@gmail.com
> > > > Subject: [OpenWrt-Devel] [PATCH] bcm63xx: DGND3700v1: device tree
> > > > improvements
> > > >
> > > > Improve the device tree file and related board data for the
> > > > DGND3700v1/ DGND3800B router:
> > > >  - Improve LEDs definitions, use shorter names.
> > > >  - Make the board name more readable.
> > > >  - Fix the switch LAN labels, the order is reversed.
> > > >  - Use the real name of the board for the board name instead of device
> > > >name.
> > > >  - Use standarized names for partition nodes and leds.
> > >
> > > This deals with several different issues at the same time. I'd prefer to 
> > > have
> > it split up (e.g. separate board name change from LED changes and switch
> > changes).
> > >
> >
> > I can't see the benefit of flooding with commits on every negligible change.
> > These are just cosmetic changes which won't affect the behavior of the
> > device, and wont produce any unexpected bug, I've made the opportune
> > tests.
>
> Well, one of the possible bugs would be that LEDs won't work after 
> sysupgrade, see below.
> I don't think that everything should be separate, but I don't like completely 
> different things stuffed together.
>
Not really a bug, and the solution is easy from the point of view of
any user. It would be the reason for non backporting these changes,
not a good idea having a diferent behavior of leds on the same Openwrt
version. It's more intuitive for any user which decides to upgrade to
a new version and if something  isn't working, they think there is a
missconconfiguration issue somewhere. I'm almost sure 100% of users
make a reset to defaults on this case.

> >
> > > >
> > > > Signed-off-by: Daniel González Cabanelas 
> > > > ---
> > > >  .../bcm63xx/base-files/etc/board.d/01_leds| 12 ++--
> > > >  .../dts/bcm6368-netgear-dgnd3700-v1.dts   | 64 +--
> > > >  .../549-board_DGND3700v1_3800B.patch  |  2 +-
> > > >  3 files changed, 39 insertions(+), 39 deletions(-)
> > > >
> > > > diff --git a/target/linux/bcm63xx/base-files/etc/board.d/01_leds
> > > > b/target/linux/bcm63xx/base-files/etc/board.d/01_leds
> > > > index 91d67f0c0b..6b82d9e952 100755
> > > > --- a/target/linux/bcm63xx/base-files/etc/board.d/01_leds
> > > > +++ b/target/linux/bcm63xx/base-files/etc/board.d/01_leds
> > > > @@ -66,12 +66,12 @@ inventel,livebox-1)
> > > >   ucidef_set_led_netdev "wlan0" "WIFI" "Livebox1:red:wifi" "wlan0"
> > > >   ;;
> > > >  netgear,dgnd3700-v1)
> > > > - ucidef_set_led_netdev "lan" "LAN" "DGND3700v1_3800B:green:lan"
> > > > "eth0.1"
> > > > - ucidef_set_led_netdev "wan" "WAN"
> > > > "DGND3700v1_3800B:green:inet" "eth0.2"
> > > > - ucidef_set_led_netdev "wlan0" "WIFI2G"
> > > > "DGND3700v1_3800B:green:wifi2g" "wlan0"
> > > > - ucidef_set_led_netdev "wlan1" "WIFI5G"
> > > > "DGND3700v1_3800B:blue:wifi5g" "wlan1"
> > > > - ucidef_set_led_usbdev "usb1" "USB1"
> > > > "DGND3700v1_3800B:green:usb-back" "1-1"
> > > > - ucidef_set_led_usbdev "usb2" "USB2"
> > > > "DGND3700v1_3800B:green:usb-front" "1-2"
> > > > + ucidef_set_led_netdev "lan" "LAN" "$model:green:lan" "eth0.1"
> > > > + ucidef_set_led_netdev "wan" "WAN" "$model:green:inet" "eth0.2"
> > > > + ucidef_set_led_netdev "wlan0" "WIFI2G" "$model:green:wifi2g"
> > > > "wlan0"
> > > > + ucidef_set_led_netdev "wlan1" "WIFI5G" "$model:blue:wifi5g"
> > > > "wlan1"
> > > > + ucidef_set_led_usbdev "usb1" "USB1" "$model:green:usb-back"
> > > > + "1-
> > > > 1"
> > > > + ucidef_set_led_usbdev "usb2" "USB2" "$model:green:usb-front"
> > > > + "1-
> > > > 2"
> > >
> > > Is there any way to do sysupgrade on these devices? If yes, you will need
> > migration of the names in /etc/config/system ...
> > >
> >
> > The sysupgrade works out of the box using the default_do_upgrade. Not
> > sure what I need to review, can you be more specific?
>
> On a newly installed device there won't be a problem. 01_leds will generate 
> the LED entries in /etc/config/system on firstboot, and after that the names 
> used there won't change anymore, even on upgrade. In contrast, the LED names 
> in the device tree will change with every upgrade, 

Re: [OpenWrt-Devel] Fix for missing kernel stack-protector in x86_64 glibc builds

[Hauke Mehrtens]

On 5/24/20 2:04 PM, Ian Cooper wrote:
> Patch attached as my email client seems to have mangled it a bit when 
> inserted inline
> 
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On 
> Behalf Of Ian Cooper
> Sent: 24 May 2020 12:35
> To: openwrt-devel@lists.openwrt.org
> Subject: [OpenWrt-Devel] Fix for missing kernel stack-protector in x86_64 
> glibc builds
> 
> Hi all,
> 
> Forgive such a long post on my first posting to this list.
> 
> I have a change to propose that, while trivial in the actual patch to the 
> build system, affects the toolchain, kernel and every package, so I don't 
> want to just create a PR for it without some discussion and agreement 
> beforehand that it's the right thing to do, even if it seems obvious to me 
> that it is. Perhaps I'm missing something here...
> 
> I run a x86_64 build with glibc. I noticed that my build (based on master) 
> did not have kernel stack smashing protection enabled. Since most distros 
> ship with it enabled by default, I got to questioning why. My Ubuntu 20.04 
> has CONFIG_STACKPROTECTOR_STRONG enabled in the kernel, so there's no 
> technical reason why it can't be used on a x86_64 platform.
> 
> It turns out after looking at `config/Config-build.in` that there is explicit 
> code to disable it in the kernel config if we're not using musl and we're on 
> a x86* platform. Moreover, there is also code to enforce use of gcc's 
> standalone libssp for userspace stack protection:
> 
>   choice
>   prompt "User space Stack-Smashing Protection"
>   depends on USE_MUSL
>   default PKG_CC_STACKPROTECTOR_REGULAR
>   help
> Enable GCC Stack Smashing Protection (SSP) for userspace 
> applications
>   config PKG_CC_STACKPROTECTOR_NONE
>   bool "None"
>   config PKG_CC_STACKPROTECTOR_REGULAR
>   bool "Regular"
>   select GCC_LIBSSP if !USE_MUSL
>   depends on KERNEL_CC_STACKPROTECTOR_REGULAR
>   config PKG_CC_STACKPROTECTOR_STRONG
>   bool "Strong"
>   select GCC_LIBSSP if !USE_MUSL
>   depends on KERNEL_CC_STACKPROTECTOR_STRONG
>   endchoice
> 
>   choice
>   prompt "Kernel space Stack-Smashing Protection"
>   default KERNEL_CC_STACKPROTECTOR_REGULAR
>   depends on USE_MUSL || !(x86_64 || i386)
>   help
> Enable GCC Stack-Smashing Protection (SSP) for the kernel
>   config KERNEL_CC_STACKPROTECTOR_NONE
>   bool "None"
>   config KERNEL_CC_STACKPROTECTOR_REGULAR
>   bool "Regular"
>   config KERNEL_CC_STACKPROTECTOR_STRONG
>   bool "Strong"
>   endchoice
> 
> 
> The commit messages that accompany this code are respectively 5 years old and 
> 2.5 years old. A lot has changed since then and the reasons these exclusions 
> were put in place are no longer valid.
> 
> commit bf82deff7069599c9f130f5bb0222acd171fd19d
> Author: Felix Fietkau 
> Date:   Sun Aug 2 07:40:12 2015 +
> 
> build: disable kernel stack protector support for i386/x86_64
> 
> When stack protector support is disabled in libc (always the case for
> !musl), gcc assumes that it needs to use __stack_chk_guard for the stack
> canary.
> This causes kernel build errors, because the kernel is only set up to
> handle TLS stack canaries.
> 
> Signed-off-by: Felix Fietkau 
> 
> SVN-Revision: 46543
> 
> 
> commit 241e6dd3e92c4f215b8ac75379a4b5aeaeb92171
> Author: Julien Dusser 
> Date:   Sun Jan 7 18:47:21 2018 +0100
> 
> build: cleanup SSP_SUPPORT configure option
> 
> Configure variable SSP_SUPPORT is ambiguous for packages (tor, openssh,
> avahi, freeswitch). It means 'toolchain supporting SSP', but for toolchain
> and depends it means 'build gcc with libssp'.
> 
> Musl no longer uses libssp (1877bc9d8f), it has internal support, so
> SSP_SUPPORT was disabled leading some package to not use SSP.
> 
> No information why Glibc and uClibc use libssp, but they may also provide
> their own SSP support. uClibc used it own with commit 933b588e25 but it 
> was
> reverted in f3cacb9e84 without details.
> 
> Create an new configure GCC_LIBSSP and automatically enable SSP_SUPPORT
> if either USE_MUSL or GCC_LIBSSP.
> 
> Signed-off-by: Julien Dusser 
> 
> 
> I started to modify the build system to see if I could get kernel stack 
> protection enabled and working.  Just removing the line "depends on USE_MUSL 
> || !(x86_64 || i386)" didn't work. The kernel config itself disables the 
> stack protection at configure time.
> 
> After a bit of digging, the reason for this is that the script in the kernel 
> source directory 

Re: [OpenWrt-Devel] Experimental "release goals" for 19.07.4

[Vincent Wiemann]

On 23.05.20 21:34, Michael Jones wrote:
> 
> 
> On Sat, May 23, 2020, 13:01 Baptiste Jonglez  > wrote: 
> 
> If the initial concept looks good, we can think about automating some of 
> it:
> tag bug reports on Flyspray/Github/Gitlab as blocking for a specific
> release, use "milestones", automatically find commits that satisfy a 
> goal, etc.
> 
> 
> 
> I find it very confusing that there are so many different places for bugs to 
> live and be tracked.
> 
> What's going on with gitlab? Is that going to be the source of truth for 
> OpenWRT? Or will we always have 3 different bug trackers?
> 


The outcome of the discussions was quite clear. Gitlab will likely become the 
"source of truth" mirroring/merging everything as you said.
You can still create issues on Github/Flyspray and you'll find all of them on 
Gitlab.
But that still needs a lot of work. It would be great if you could participate 
in the evaluation process if you are familiar with Gitlab.
https://github.com/openwrt/openwrt/pull/2218

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Fix for missing kernel stack-protector in x86_64 glibc builds

[Ian Cooper]

Patch attached as my email client seems to have mangled it a bit when inserted 
inline

-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf 
Of Ian Cooper
Sent: 24 May 2020 12:35
To: openwrt-devel@lists.openwrt.org
Subject: [OpenWrt-Devel] Fix for missing kernel stack-protector in x86_64 glibc 
builds

Hi all,

Forgive such a long post on my first posting to this list.

I have a change to propose that, while trivial in the actual patch to the build 
system, affects the toolchain, kernel and every package, so I don't want to 
just create a PR for it without some discussion and agreement beforehand that 
it's the right thing to do, even if it seems obvious to me that it is. Perhaps 
I'm missing something here...

I run a x86_64 build with glibc. I noticed that my build (based on master) did 
not have kernel stack smashing protection enabled. Since most distros ship with 
it enabled by default, I got to questioning why. My Ubuntu 20.04 has 
CONFIG_STACKPROTECTOR_STRONG enabled in the kernel, so there's no technical 
reason why it can't be used on a x86_64 platform.

It turns out after looking at `config/Config-build.in` that there is explicit 
code to disable it in the kernel config if we're not using musl and we're on a 
x86* platform. Moreover, there is also code to enforce use of gcc's standalone 
libssp for userspace stack protection:

choice
prompt "User space Stack-Smashing Protection"
depends on USE_MUSL
default PKG_CC_STACKPROTECTOR_REGULAR
help
  Enable GCC Stack Smashing Protection (SSP) for userspace 
applications
config PKG_CC_STACKPROTECTOR_NONE
bool "None"
config PKG_CC_STACKPROTECTOR_REGULAR
bool "Regular"
select GCC_LIBSSP if !USE_MUSL
depends on KERNEL_CC_STACKPROTECTOR_REGULAR
config PKG_CC_STACKPROTECTOR_STRONG
bool "Strong"
select GCC_LIBSSP if !USE_MUSL
depends on KERNEL_CC_STACKPROTECTOR_STRONG
endchoice

choice
prompt "Kernel space Stack-Smashing Protection"
default KERNEL_CC_STACKPROTECTOR_REGULAR
depends on USE_MUSL || !(x86_64 || i386)
help
  Enable GCC Stack-Smashing Protection (SSP) for the kernel
config KERNEL_CC_STACKPROTECTOR_NONE
bool "None"
config KERNEL_CC_STACKPROTECTOR_REGULAR
bool "Regular"
config KERNEL_CC_STACKPROTECTOR_STRONG
bool "Strong"
endchoice


The commit messages that accompany this code are respectively 5 years old and 
2.5 years old. A lot has changed since then and the reasons these exclusions 
were put in place are no longer valid.

commit bf82deff7069599c9f130f5bb0222acd171fd19d
Author: Felix Fietkau 
Date:   Sun Aug 2 07:40:12 2015 +

build: disable kernel stack protector support for i386/x86_64

When stack protector support is disabled in libc (always the case for
!musl), gcc assumes that it needs to use __stack_chk_guard for the stack
canary.
This causes kernel build errors, because the kernel is only set up to
handle TLS stack canaries.

Signed-off-by: Felix Fietkau 

SVN-Revision: 46543


commit 241e6dd3e92c4f215b8ac75379a4b5aeaeb92171
Author: Julien Dusser 
Date:   Sun Jan 7 18:47:21 2018 +0100

build: cleanup SSP_SUPPORT configure option

Configure variable SSP_SUPPORT is ambiguous for packages (tor, openssh,
avahi, freeswitch). It means 'toolchain supporting SSP', but for toolchain
and depends it means 'build gcc with libssp'.

Musl no longer uses libssp (1877bc9d8f), it has internal support, so
SSP_SUPPORT was disabled leading some package to not use SSP.

No information why Glibc and uClibc use libssp, but they may also provide
their own SSP support. uClibc used it own with commit 933b588e25 but it was
reverted in f3cacb9e84 without details.

Create an new configure GCC_LIBSSP and automatically enable SSP_SUPPORT
if either USE_MUSL or GCC_LIBSSP.

Signed-off-by: Julien Dusser 


I started to modify the build system to see if I could get kernel stack 
protection enabled and working.  Just removing the line "depends on USE_MUSL || 
!(x86_64 || i386)" didn't work. The kernel config itself disables the stack 
protection at configure time.

After a bit of digging, the reason for this is that the script in the kernel 
source directory `scripts/gcc-x86_64-has-stack-protector.sh` fails its check. 
This script does the following check

#!/bin/sh
# SPDX-License-Identifier: GPL-2.0

echo "int foo(void) { char X[200]; return 3; }" | $* -S -x c -c 

Re: [OpenWrt-Devel] [PATCH v6] ath79: add support for COMFAST CF-E130N v2

[mail]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of ad...@kryma.net
> Sent: Freitag, 27. März 2020 04:33
> To: openwrt-devel@lists.openwrt.org
> Cc: Pavel Balan 
> Subject: [OpenWrt-Devel] [PATCH v6] ath79: add support for COMFAST CF-
> E130N v2
> 
> From: Pavel Balan 
> 
> This patch adds support for the COMFAST CF-E130N v2, an outdoor wireless
> CPE with a single Ethernet port and a 802.11bgn radio.
> 
> Specifications:
> 
>  - QCA9531 SoC
>  - 1x 10/100 Mbps Ethernet with PoE-in support
>  - 64 MB of RAM (DDR2)
>  - 16 MB of FLASH
>  - 5 dBi built-in antenna
>  - POWER/LAN/WLAN green LEDs
>  - 4x RSSI LEDs (2x red, 2x green)
>  - UART (115200 8N1) and GPIO (J9) headers on PCB
> 
> Flashing instructions:
> 
>  The original firmware is based on OpenWrt so a sysupgrade image can be
> installed via the stock web GUI.
> 
>  The U-boot bootloader also contains a backup TFTP client to upload the
> firmware from. Upon boot, it checks its ethernet network for the IP
> 192.168.1.10. Host a TFTP server and provide the image to be flashed as  file
> firmware_auto.bin.
> 
> Signed-off-by: Pavel Balan 
> ---
> Run-tested on hardware.
> 
> Changes since v5:
> 
>  Made partition@7e read-only.
> 
>  Changed IMAGE_SIZE to 7936k.

it looks like you have actually sent the v5 version of your patch again, as the 
v6-changes you report are not included. Anyway, I've added these (and a few 
others) myself and pushed the result to my staging tree here:

https://git.openwrt.org/?p=openwrt/staging/adrian.git;a=shortlog;h=refs/heads/staging

Please run this on your device and check whether everything is okay, so I can 
merge this.

Despite, I'd be interested whether the MAC address from calibration data (art 
0x1002) is actually the same as art 0x0, so we can drop mtd-mac-address from 
wmac.

Best

Adrian

> 
> ---
>  .../ath79/dts/qca9531_comfast_cf-e130n-v2.dts | 150
> ++
>  .../generic/base-files/etc/board.d/01_leds|   8 +
>  .../generic/base-files/etc/board.d/02_network |   1 +
>  target/linux/ath79/image/generic.mk   |  10 ++
>  4 files changed, 169 insertions(+)
>  create mode 100644 target/linux/ath79/dts/qca9531_comfast_cf-e130n-
> v2.dts
> 
> diff --git a/target/linux/ath79/dts/qca9531_comfast_cf-e130n-v2.dts
> b/target/linux/ath79/dts/qca9531_comfast_cf-e130n-v2.dts
> new file mode 100644
> index 00..dc1e037307
> --- /dev/null
> +++ b/target/linux/ath79/dts/qca9531_comfast_cf-e130n-v2.dts
> @@ -0,0 +1,150 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT /dts-v1/;
> +
> +#include 
> +#include 
> +
> +#include "qca953x.dtsi"
> +
> +/ {
> + compatible = "comfast,cf-e130n-v2", "qca,qca9531";
> + model = "COMFAST CF-E130N v2";
> +
> + aliases {
> + serial0 = 
> + led-boot = _rssihigh;
> + led-failsafe = _rssihigh;
> + led-upgrade = _rssihigh;
> + label-mac-device = 
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + pinctrl-names = "default";
> +
> + wlan {
> + label = "cf-e130n-v2:green:wlan";
> + gpios = < 0 GPIO_ACTIVE_LOW>;
> + linux,default-trigger = "phy0tpt";
> + };
> +
> + lan {
> + label = "cf-e130n-v2:green:lan";
> + gpios = < 2 GPIO_ACTIVE_LOW>;
> + };
> +
> + unused {
> + label = "cf-e130n-v2:green:unused";
> + gpios = < 3 GPIO_ACTIVE_LOW>;
> + };
> +
> + rssilow {
> + label = "cf-e130n-v2:red:rssilow";
> + gpios = < 11 GPIO_ACTIVE_LOW>;
> + };
> +
> + rssimediumlow {
> + label = "cf-e130n-v2:red:rssimediumlow";
> + gpios = < 12 GPIO_ACTIVE_LOW>;
> + };
> +
> + rssimediumhigh {
> + label = "cf-e130n-v2:green:rssimediumhigh";
> + gpios = < 14 GPIO_ACTIVE_LOW>;
> + };
> +
> + led_rssihigh: rssihigh {
> + label = "cf-e130n-v2:green:rssihigh";
> + gpios = < 16 GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> + keys {
> + compatible = "gpio-keys";
> +
> + reset {
> + label = "reset";
> + linux,code = ;
> + gpios = < 17 GPIO_ACTIVE_LOW>;
> + debounce-interval = <60>;
> + };
> + };
> +};
> +
> + {
> + status = "okay";
> +
> + num-cs = <1>;
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <2500>;
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;

[OpenWrt-Devel] Fix for missing kernel stack-protector in x86_64 glibc builds

[Ian Cooper]

Hi all,

Forgive such a long post on my first posting to this list.

I have a change to propose that, while trivial in the actual patch to the build 
system, affects the toolchain, kernel and every package, so I don't want to 
just create a PR for it without some discussion and agreement beforehand that 
it's the right thing to do, even if it seems obvious to me that it is. Perhaps 
I'm missing something here...

I run a x86_64 build with glibc. I noticed that my build (based on master) did 
not have kernel stack smashing protection enabled. Since most distros ship with 
it enabled by default, I got to questioning why. My Ubuntu 20.04 has 
CONFIG_STACKPROTECTOR_STRONG enabled in the kernel, so there's no technical 
reason why it can't be used on a x86_64 platform.

It turns out after looking at `config/Config-build.in` that there is explicit 
code to disable it in the kernel config if we're not using musl and we're on a 
x86* platform. Moreover, there is also code to enforce use of gcc's standalone 
libssp for userspace stack protection:

choice
prompt "User space Stack-Smashing Protection"
depends on USE_MUSL
default PKG_CC_STACKPROTECTOR_REGULAR
help
  Enable GCC Stack Smashing Protection (SSP) for userspace 
applications
config PKG_CC_STACKPROTECTOR_NONE
bool "None"
config PKG_CC_STACKPROTECTOR_REGULAR
bool "Regular"
select GCC_LIBSSP if !USE_MUSL
depends on KERNEL_CC_STACKPROTECTOR_REGULAR
config PKG_CC_STACKPROTECTOR_STRONG
bool "Strong"
select GCC_LIBSSP if !USE_MUSL
depends on KERNEL_CC_STACKPROTECTOR_STRONG
endchoice

choice
prompt "Kernel space Stack-Smashing Protection"
default KERNEL_CC_STACKPROTECTOR_REGULAR
depends on USE_MUSL || !(x86_64 || i386)
help
  Enable GCC Stack-Smashing Protection (SSP) for the kernel
config KERNEL_CC_STACKPROTECTOR_NONE
bool "None"
config KERNEL_CC_STACKPROTECTOR_REGULAR
bool "Regular"
config KERNEL_CC_STACKPROTECTOR_STRONG
bool "Strong"
endchoice


The commit messages that accompany this code are respectively 5 years old and 
2.5 years old. A lot has changed since then and the reasons these exclusions 
were put in place are no longer valid.

commit bf82deff7069599c9f130f5bb0222acd171fd19d
Author: Felix Fietkau 
Date:   Sun Aug 2 07:40:12 2015 +

build: disable kernel stack protector support for i386/x86_64

When stack protector support is disabled in libc (always the case for
!musl), gcc assumes that it needs to use __stack_chk_guard for the stack
canary.
This causes kernel build errors, because the kernel is only set up to
handle TLS stack canaries.

Signed-off-by: Felix Fietkau 

SVN-Revision: 46543


commit 241e6dd3e92c4f215b8ac75379a4b5aeaeb92171
Author: Julien Dusser 
Date:   Sun Jan 7 18:47:21 2018 +0100

build: cleanup SSP_SUPPORT configure option

Configure variable SSP_SUPPORT is ambiguous for packages (tor, openssh,
avahi, freeswitch). It means 'toolchain supporting SSP', but for toolchain
and depends it means 'build gcc with libssp'.

Musl no longer uses libssp (1877bc9d8f), it has internal support, so
SSP_SUPPORT was disabled leading some package to not use SSP.

No information why Glibc and uClibc use libssp, but they may also provide
their own SSP support. uClibc used it own with commit 933b588e25 but it was
reverted in f3cacb9e84 without details.

Create an new configure GCC_LIBSSP and automatically enable SSP_SUPPORT
if either USE_MUSL or GCC_LIBSSP.

Signed-off-by: Julien Dusser 


I started to modify the build system to see if I could get kernel stack 
protection enabled and working.  Just removing the line "depends on USE_MUSL || 
!(x86_64 || i386)" didn't work. The kernel config itself disables the stack 
protection at configure time.

After a bit of digging, the reason for this is that the script in the kernel 
source directory `scripts/gcc-x86_64-has-stack-protector.sh` fails its check. 
This script does the following check

#!/bin/sh
# SPDX-License-Identifier: GPL-2.0

echo "int foo(void) { char X[200]; return 3; }" | $* -S -x c -c -m32 
-O0 -fstack-protector - -o - 2> /dev/null | grep -q "%gs"

The code produced by the default openwrt x86_64_glibc toolchain from this 
command is as follows:

.file   ""
.text
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
pushq   %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16

Re: [OpenWrt-Devel] [PATCH] bcm63xx: DGND3700v1: device tree improvements

[mail]

Hi Daniel,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Daniel González Cabanelas
> Sent: Sonntag, 24. Mai 2020 11:06
> To: m...@adrianschmutzler.de
> Cc: openwrt-devel@lists.openwrt.org; Álvaro Fernández Rojas
> 
> Subject: Re: [OpenWrt-Devel] [PATCH] bcm63xx: DGND3700v1: device tree
> improvements
> 
> Hi Adrian:
> 
> El dom., 24 may. 2020 a las 1:01,  escribió:
> >
> > Hi,
> >
> > > -Original Message-
> > > From: openwrt-devel [mailto:openwrt-devel-
> boun...@lists.openwrt.org]
> > > On Behalf Of Daniel González Cabanelas
> > > Sent: Sonntag, 24. Mai 2020 00:24
> > > To: openwrt-devel@lists.openwrt.org
> > > Cc: nolt...@gmail.com
> > > Subject: [OpenWrt-Devel] [PATCH] bcm63xx: DGND3700v1: device tree
> > > improvements
> > >
> > > Improve the device tree file and related board data for the
> > > DGND3700v1/ DGND3800B router:
> > >  - Improve LEDs definitions, use shorter names.
> > >  - Make the board name more readable.
> > >  - Fix the switch LAN labels, the order is reversed.
> > >  - Use the real name of the board for the board name instead of device
> > >name.
> > >  - Use standarized names for partition nodes and leds.
> >
> > This deals with several different issues at the same time. I'd prefer to 
> > have
> it split up (e.g. separate board name change from LED changes and switch
> changes).
> >
> 
> I can't see the benefit of flooding with commits on every negligible change.
> These are just cosmetic changes which won't affect the behavior of the
> device, and wont produce any unexpected bug, I've made the opportune
> tests.

Well, one of the possible bugs would be that LEDs won't work after sysupgrade, 
see below.
I don't think that everything should be separate, but I don't like completely 
different things stuffed together.

> 
> > >
> > > Signed-off-by: Daniel González Cabanelas 
> > > ---
> > >  .../bcm63xx/base-files/etc/board.d/01_leds| 12 ++--
> > >  .../dts/bcm6368-netgear-dgnd3700-v1.dts   | 64 +--
> > >  .../549-board_DGND3700v1_3800B.patch  |  2 +-
> > >  3 files changed, 39 insertions(+), 39 deletions(-)
> > >
> > > diff --git a/target/linux/bcm63xx/base-files/etc/board.d/01_leds
> > > b/target/linux/bcm63xx/base-files/etc/board.d/01_leds
> > > index 91d67f0c0b..6b82d9e952 100755
> > > --- a/target/linux/bcm63xx/base-files/etc/board.d/01_leds
> > > +++ b/target/linux/bcm63xx/base-files/etc/board.d/01_leds
> > > @@ -66,12 +66,12 @@ inventel,livebox-1)
> > >   ucidef_set_led_netdev "wlan0" "WIFI" "Livebox1:red:wifi" "wlan0"
> > >   ;;
> > >  netgear,dgnd3700-v1)
> > > - ucidef_set_led_netdev "lan" "LAN" "DGND3700v1_3800B:green:lan"
> > > "eth0.1"
> > > - ucidef_set_led_netdev "wan" "WAN"
> > > "DGND3700v1_3800B:green:inet" "eth0.2"
> > > - ucidef_set_led_netdev "wlan0" "WIFI2G"
> > > "DGND3700v1_3800B:green:wifi2g" "wlan0"
> > > - ucidef_set_led_netdev "wlan1" "WIFI5G"
> > > "DGND3700v1_3800B:blue:wifi5g" "wlan1"
> > > - ucidef_set_led_usbdev "usb1" "USB1"
> > > "DGND3700v1_3800B:green:usb-back" "1-1"
> > > - ucidef_set_led_usbdev "usb2" "USB2"
> > > "DGND3700v1_3800B:green:usb-front" "1-2"
> > > + ucidef_set_led_netdev "lan" "LAN" "$model:green:lan" "eth0.1"
> > > + ucidef_set_led_netdev "wan" "WAN" "$model:green:inet" "eth0.2"
> > > + ucidef_set_led_netdev "wlan0" "WIFI2G" "$model:green:wifi2g"
> > > "wlan0"
> > > + ucidef_set_led_netdev "wlan1" "WIFI5G" "$model:blue:wifi5g"
> > > "wlan1"
> > > + ucidef_set_led_usbdev "usb1" "USB1" "$model:green:usb-back"
> > > + "1-
> > > 1"
> > > + ucidef_set_led_usbdev "usb2" "USB2" "$model:green:usb-front"
> > > + "1-
> > > 2"
> >
> > Is there any way to do sysupgrade on these devices? If yes, you will need
> migration of the names in /etc/config/system ...
> >
> 
> The sysupgrade works out of the box using the default_do_upgrade. Not
> sure what I need to review, can you be more specific?

On a newly installed device there won't be a problem. 01_leds will generate the 
LED entries in /etc/config/system on firstboot, and after that the names used 
there won't change anymore, even on upgrade. In contrast, the LED names in the 
device tree will change with every upgrade, so that this change results in the 
LED settings becoming broken without a reset of config files. This can be 
healed with a migration script, e.g.
https://github.com/openwrt/openwrt/blob/master/target/linux/ramips/mt76x8/base-files/etc/uci-defaults/04_led_migration

That's BTW the reason why we haven't changed these for consistency so far on 
this target.

> 
> > >   ;;
> > >  netgear,dgnd3700-v2)
> > >   ucidef_set_led_netdev "lan" "LAN" "$model:green:ethernet" "eth0"
> > > diff --git
> > > a/target/linux/bcm63xx/dts/bcm6368-netgear-dgnd3700-v1.dts
> > > b/target/linux/bcm63xx/dts/bcm6368-netgear-dgnd3700-v1.dts
> > > index 546b0b1f60..c17bb3a600 100644
> > > --- 

Re: [OpenWrt-Devel] [PATCH] bcm63xx: DGND3700v1: device tree improvements

[Daniel González Cabanelas]

Hi Adrian:

El dom., 24 may. 2020 a las 1:01,  escribió:
>
> Hi,
>
> > -Original Message-
> > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> > On Behalf Of Daniel González Cabanelas
> > Sent: Sonntag, 24. Mai 2020 00:24
> > To: openwrt-devel@lists.openwrt.org
> > Cc: nolt...@gmail.com
> > Subject: [OpenWrt-Devel] [PATCH] bcm63xx: DGND3700v1: device tree
> > improvements
> >
> > Improve the device tree file and related board data for the DGND3700v1/
> > DGND3800B router:
> >  - Improve LEDs definitions, use shorter names.
> >  - Make the board name more readable.
> >  - Fix the switch LAN labels, the order is reversed.
> >  - Use the real name of the board for the board name instead of device
> >name.
> >  - Use standarized names for partition nodes and leds.
>
> This deals with several different issues at the same time. I'd prefer to have 
> it split up (e.g. separate board name change from LED changes and switch 
> changes).
>

I can't see the benefit of flooding with commits on every negligible
change. These are just cosmetic changes which won't affect the
behavior of the device, and wont produce any unexpected bug, I've made
the opportune tests.

> >
> > Signed-off-by: Daniel González Cabanelas 
> > ---
> >  .../bcm63xx/base-files/etc/board.d/01_leds| 12 ++--
> >  .../dts/bcm6368-netgear-dgnd3700-v1.dts   | 64 +--
> >  .../549-board_DGND3700v1_3800B.patch  |  2 +-
> >  3 files changed, 39 insertions(+), 39 deletions(-)
> >
> > diff --git a/target/linux/bcm63xx/base-files/etc/board.d/01_leds
> > b/target/linux/bcm63xx/base-files/etc/board.d/01_leds
> > index 91d67f0c0b..6b82d9e952 100755
> > --- a/target/linux/bcm63xx/base-files/etc/board.d/01_leds
> > +++ b/target/linux/bcm63xx/base-files/etc/board.d/01_leds
> > @@ -66,12 +66,12 @@ inventel,livebox-1)
> >   ucidef_set_led_netdev "wlan0" "WIFI" "Livebox1:red:wifi" "wlan0"
> >   ;;
> >  netgear,dgnd3700-v1)
> > - ucidef_set_led_netdev "lan" "LAN" "DGND3700v1_3800B:green:lan"
> > "eth0.1"
> > - ucidef_set_led_netdev "wan" "WAN"
> > "DGND3700v1_3800B:green:inet" "eth0.2"
> > - ucidef_set_led_netdev "wlan0" "WIFI2G"
> > "DGND3700v1_3800B:green:wifi2g" "wlan0"
> > - ucidef_set_led_netdev "wlan1" "WIFI5G"
> > "DGND3700v1_3800B:blue:wifi5g" "wlan1"
> > - ucidef_set_led_usbdev "usb1" "USB1"
> > "DGND3700v1_3800B:green:usb-back" "1-1"
> > - ucidef_set_led_usbdev "usb2" "USB2"
> > "DGND3700v1_3800B:green:usb-front" "1-2"
> > + ucidef_set_led_netdev "lan" "LAN" "$model:green:lan" "eth0.1"
> > + ucidef_set_led_netdev "wan" "WAN" "$model:green:inet" "eth0.2"
> > + ucidef_set_led_netdev "wlan0" "WIFI2G" "$model:green:wifi2g"
> > "wlan0"
> > + ucidef_set_led_netdev "wlan1" "WIFI5G" "$model:blue:wifi5g"
> > "wlan1"
> > + ucidef_set_led_usbdev "usb1" "USB1" "$model:green:usb-back" "1-
> > 1"
> > + ucidef_set_led_usbdev "usb2" "USB2" "$model:green:usb-front" "1-
> > 2"
>
> Is there any way to do sysupgrade on these devices? If yes, you will need 
> migration of the names in /etc/config/system ...
>

The sysupgrade works out of the box using the default_do_upgrade. Not
sure what I need to review, can you be more specific?

> >   ;;
> >  netgear,dgnd3700-v2)
> >   ucidef_set_led_netdev "lan" "LAN" "$model:green:ethernet" "eth0"
> > diff --git a/target/linux/bcm63xx/dts/bcm6368-netgear-dgnd3700-v1.dts
> > b/target/linux/bcm63xx/dts/bcm6368-netgear-dgnd3700-v1.dts
> > index 546b0b1f60..c17bb3a600 100644
> > --- a/target/linux/bcm63xx/dts/bcm6368-netgear-dgnd3700-v1.dts
> > +++ b/target/linux/bcm63xx/dts/bcm6368-netgear-dgnd3700-v1.dts
> > @@ -5,12 +5,12 @@
> >  #include 
> >
> >  / {
> > - model = "Netgear DGND3700v1/DGND3800B";
> > + model = "Netgear DGND3700v1 / DGND3800B";
>
> I don't think this is really necessary ...
>
> >   compatible = "netgear,dgnd3700-v1", "brcm,bcm6368";
> >
> >   aliases {
> >   led-boot = _power_green;
> > - led-failsafe = _power_green;
> > + led-failsafe = _power_red;
>
> This should be a separate commit again.
>

One commit per line, on the same file, really?, again this is a minor change.

> >   led-running = _power_green;
> >   led-upgrade = _power_green;
> >   };
> > @@ -51,49 +51,49 @@
> >   leds {
> >   compatible = "gpio-leds";
> >
> > - dsl_green {
> > - label = "DGND3700v1_3800B:green:dsl";
> > + led@2 {
>
> I don't know whether this is different on bcm63xx, but based on what I'm used 
> to the old node name is preferred (dsl_green).
>

Well, I'll never know what's the best way for naming a led node. I've
taken the partitions nodes as a reference, and the LEDs device tree
documentation also use this way as an example.

Regards

> Best
>
> Adrian
>
> > + label = "dgnd3700-v1:green:dsl";
> >   gpios = < 2 1>;
> >   };
> 

[OpenWrt-Devel] ath79: add support for COMFAST CF-E130N v2

[Yaroslav Petrov]

Hi Pavel,


What about you patch ? It will be great to add COMFAST CF-E130N v2 to 
openwrt master. Do you need help ?



Best regards
Yaroslav Petrov


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel