Re: [OpenWrt-Devel] node.js

[Russell Senior]

> "Levente" == Levente   writes:

Levente> After selecting x86 platform, I can see the menu items. Is this
Levente> intentional to include node only in x86 platform builds?

Once upon a time, node.js was dependent on v8 (the javascript
interpretter), and v8 was only available on particular architectures
because of unported assembly components, or something vaguely like that.


-- 
Russell Senior, President
russ...@personaltelco.net

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

Re: [OpenWrt-Devel] Moving the mailing lists

[Daniel F. Dickinson]

On 2018-05-23 02:45 PM, David Woodhouse wrote:

On Wed, 2018-05-23 at 17:24 +0200, Torbjörn Jansson wrote:

PS: Remove this annoying tag '[OpenWrt-Devel]' from subject. XXI century in
the world - all email clients already know how filters messages based on
List-Id header.



Not everyone, plus lede mailing list also had prefix on subject line.


Nevertheless, we shouldn't pander to the lowest common denominator.


1) How many people have their own mail server and can do *server-side* 
mail filtering
2) In the absence of server-side mail filtering, what happens on mobile 
email clients (I don't use mobile for email, but it's a very popular 
thing among those who actually do more than make phone calls with their 
phone and/or tablets with data) re: filtering.  Are there readily 
available email clients for mobile than are reasonably easy to configure 
to do filtering by List-Id?  In the failing to accommodate for mobile 
access is a good way for a project to die a slow painful death.  For 
that matter in 2018 there is a lot more cross-platform development, 
including using Windows (and there Outlook/365 as primary email) even 
for things like Openwrt development; again unless you want slow painful 
death and irrelevance.


Regards,

Daniel

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

Re: [OpenWrt-Devel] [PATCH 1/2] ramips: Use generic board detect for GnuBee devices

[Rosen Penev]

On Fri, May 25, 2018 at 3:23 AM, Mathias Kresin  wrote:
> 2018-05-25 6:43 GMT+03:00 Rosen Penev :
>> This is a port of an old commit from mkresin's tree:
>>
>> 09260cdf3e9332978c2a474a58e93a6f2b55f4a8
>>
>> This has the potential to break sysupgrade but it should be fine as
>> there is no stable release of LEDE or OpenWrt that support these devices.
>>
>> Signed-off-by: Rosen Penev 
>> ---
>>  target/linux/ramips/base-files/etc/board.d/01_leds | 4 ++--
>>  target/linux/ramips/base-files/etc/board.d/02_network  | 4 ++--
>>  target/linux/ramips/base-files/etc/diag.sh | 4 ++--
>>  target/linux/ramips/base-files/lib/ramips.sh   | 3 ---
>>  target/linux/ramips/base-files/lib/upgrade/platform.sh | 4 ++--
>>  target/linux/ramips/dts/GB-PC1.dts | 2 +-
>>  target/linux/ramips/dts/GB-PC2.dts | 2 +-
>>  target/linux/ramips/image/mt7621.mk| 8 
>>  8 files changed, 14 insertions(+), 17 deletions(-)
>>
>> diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds 
>> b/target/linux/ramips/base-files/etc/board.d/01_leds
>> index 88e4c2b7fe..79f2cc2b87 100755
>> --- a/target/linux/ramips/base-files/etc/board.d/01_leds
>> +++ b/target/linux/ramips/base-files/etc/board.d/01_leds
>> @@ -196,8 +196,8 @@ fonera20n)
>> set_usb_led "$boardname:orange:usb"
>> set_wifi_led "$boardname:orange:wifi"
>> ;;
>> -gb-pc1|\
>> -gnubee,gb-pc2)
>> +gnubee,pc1|\
>> +gnubee,pc2)
>> ucidef_set_led_switch "lan1" "lan1" "$boardname:green:lan1" 
>> "switch0" "0x01"
>> ucidef_set_led_switch "lan2" "lan2" "$boardname:green:lan2" 
>> "switch0" "0x10"
>> ;;
>
> This will not work. You need to rename the LEDs from gb-pc[1|2]:green:
> to pc[1|2]:green: in the devicetree source files.
>
> But instead of doing so, please drop the compatible changes, and use
> "gnubee,gb-pc1". I don't see much gain in changing them.
It's a bit clearer but sure, I'll drop.
>
> Mathias

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

Re: [OpenWrt-Devel] 18.06 Bug: Baby Jumbo Frames on mt7621

[Kristian Evensen]

Hi,

> I know how to fix the issue by recovery, however, from the responses
> in the topic on the Lede forum it seems more people are running into
> this issue. This definitely needs to be fixed before a 18.06 release.
> Is there someone with a mt7621 device that can reproduce the problem,
> and that has serial access? We might be able to figure out what is
> going wrong.

I am seeing the same on my mt7621-based devices. It seems that upgrade
works roughly every second time. Here is output from serial one
sysupgrade that went wrong (i.e., no effect):

Sending TERM to remaining processes ... logd rpcd netifd odhcpd crond
hostapd ntpd hostapd nginx nginx dnsmasq ubusd sh sh sh sh sshd [
416.897350] device wlan0 left promiscuous mode
[  416.902098] br-lan: port 2(wlan0) entered disabled state
ssh [  416.915527] device wlan1 left promiscuous mode
[  416.920286] br-lan: port 3(wlan1) entered disabled state
ssh sleep sleep sleep
Sending KILL to remaining processes ... hostapd chostapd hostapd
hostapd hostapd hostapd hostapd hostapd hostapd /lib/upgrade/stage2:
line 132: can't open /proc/3469/cmdline: no such file

Failed to kill a[  420.497042] reboot: Restarting system
ll processes.
sysupgrade aborted with return code: 256

-Kristian

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

Re: [OpenWrt-Devel] node.js

[Levente]

After selecting x86 platform, I can see the menu items. Is this
intentional to include node only in x86 platform builds?


Thanks,
Levente

On Fri, May 25, 2018 at 4:03 PM, Levente  wrote:
> Yes, as I said, it is there.
>
> I can only see vala in the Languages menu.
>
>
> Lev
>
> On Fri, May 25, 2018 at 3:55 PM, Alberto Bursi
>  wrote:
>>
>>
>> On 25/05/2018 15:39, Levente wrote:
>>>
>>> Hi all,
>>>
>>>
>>> There is a tutorial here:
>>>
>>> https://wiki.openwrt.org/doc/howto/nodejs
>>>
>>> on how to compile node.js into OpenWRT, but the that configuration
>>> item is missing from menuconfig.
>>>
>>> I checked the feed, and it is there in the build tree. There is a
>>> dependency for the package, which is the FPU. So I made
>>> kernel_menuconfig and ticked the MIPS FPU emulation.
>>>
>>> I then went back to menuconfig, but there is still no sign of node.js.
>>>
>>>
>>> Could you please help how to build node for OpenWRT?
>>>
>>>
>>> Thanks,
>>> Levente
>>>
>>> ___
>>> openwrt-devel mailing list
>>> openwrt-devel@lists.openwrt.org
>>> http://lists.infradead.org/mailman/listinfo/openwrt-devel
>>
>>
>> node.js is in "packages" feed. Did you enable that feed?
>> see here to enable OpenWrt feeds
>> https://openwrt.org/docs/guide-developer/feeds
>>
>> -Alberto
>>
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> http://lists.infradead.org/mailman/listinfo/openwrt-devel

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

Re: [OpenWrt-Devel] node.js

[Levente]

Yes, as I said, it is there.

I can only see vala in the Languages menu.


Lev

On Fri, May 25, 2018 at 3:55 PM, Alberto Bursi
 wrote:
>
>
> On 25/05/2018 15:39, Levente wrote:
>>
>> Hi all,
>>
>>
>> There is a tutorial here:
>>
>> https://wiki.openwrt.org/doc/howto/nodejs
>>
>> on how to compile node.js into OpenWRT, but the that configuration
>> item is missing from menuconfig.
>>
>> I checked the feed, and it is there in the build tree. There is a
>> dependency for the package, which is the FPU. So I made
>> kernel_menuconfig and ticked the MIPS FPU emulation.
>>
>> I then went back to menuconfig, but there is still no sign of node.js.
>>
>>
>> Could you please help how to build node for OpenWRT?
>>
>>
>> Thanks,
>> Levente
>>
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> http://lists.infradead.org/mailman/listinfo/openwrt-devel
>
>
> node.js is in "packages" feed. Did you enable that feed?
> see here to enable OpenWrt feeds
> https://openwrt.org/docs/guide-developer/feeds
>
> -Alberto
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> http://lists.infradead.org/mailman/listinfo/openwrt-devel

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

Re: [OpenWrt-Devel] node.js

[Alberto Bursi]

On 25/05/2018 15:39, Levente wrote:

Hi all,


There is a tutorial here:

https://wiki.openwrt.org/doc/howto/nodejs

on how to compile node.js into OpenWRT, but the that configuration
item is missing from menuconfig.

I checked the feed, and it is there in the build tree. There is a
dependency for the package, which is the FPU. So I made
kernel_menuconfig and ticked the MIPS FPU emulation.

I then went back to menuconfig, but there is still no sign of node.js.


Could you please help how to build node for OpenWRT?


Thanks,
Levente

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


node.js is in "packages" feed. Did you enable that feed?
see here to enable OpenWrt feeds 
https://openwrt.org/docs/guide-developer/feeds


-Alberto

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

Re: [OpenWrt-Devel] 18.06 Bug: Baby Jumbo Frames on mt7621

[Jaap Buurman]

On Fri, May 25, 2018 at 1:35 PM, Levente  wrote:
> Try upgrading the sysupgrade image using your bootloader.
>
> Lev
>
> On Fri, May 25, 2018 at 1:25 PM, Jaap Buurman  wrote:
>> On Fri, May 25, 2018 at 1:14 PM, Jaap Buurman  wrote:
>>> On Fri, May 25, 2018 at 12:43 PM, Mathias Kresin  wrote:
 2018-05-25 12:48 GMT+03:00 Jaap Buurman :
> Dear Martin, Mathias and the rest,
>
> Please scratch my previous message. It seems like the flash was not
> successful, and hence I was still running the old firmware. However, I
> have tried flashing 3 different times now, without any luck. The
> router ends up rebooting and boots right into the old firmware. This
> seems to be a major bug. Is there anything I can do to help debug this
> particular issue?

 First of all, Martin is right. The commit in my staging tree should
 fix the MTU issue but I don't have the hardware to test it on my own.

 So far you never mentioned which board you have. Hence it's quite
 difficult to have a look at the code about what could be wrong. It
 would be helpful if you can name the last working revision to limit
 the number of commits to look at.

> Seems like a dealbreaker for 18.06 (which I am
> running now) to me. I could simply use recovery and flash a firmware
> like that, but I would prefer to get to the bottom of this issue so
> that end users won't end up stuck on a particular firmware. Any ideas
> what I could do to debug this?

 Your best bet is to attach the/a serial console and check the console
 for errors.

 Mathias
>>>
>>> My apologies for leaving out important details. I am using a Dir-860L
>>> B1. I used to be running Lede 17.01.4, until last Tuesday. At that day
>>> I upgraded to OpenWrt 18.06-SNAPSHOT r6917-8948a78 via Luci. Flashing
>>> any other firmware seems to be broken now: I have tried flashing a
>>> build compiled from your staging tree, I've tried reverting back to
>>> 17.01.4 and I've tried reflashing 18.06. All end up in the exact same
>>> spot: Still on the OpenWrt 18.06-SNAPSHOT r6917-8948a78 with all
>>> manually installed packages still present. I've tried flashing via
>>> Luci and via the sysupgrade command (with the -v switch for more
>>> verbosity), but no useful information there. The last line that is
>>> output is simply:
>>>
>>> Commencing upgrade. All shell sessions will be closed now.
>>>
>>> One particular weird thing that I do remember on this build, is the
>>> fact that I tried to update all upgradable packages via OPKG (I know
>>> this is discouraged). One of those packages was "base-files". The
>>> upgrade failed with a weird error (can't remember what exactly), but
>>> nothing seemed wrong at that time, so I didn't really think much about
>>> it. Is there anyone more knowledgeable than me that knows whether this
>>> could influence the sysupgrade functionality?
>>>
>>> Lastly, I do not have a serial cable unfortunately, so I think
>>> debugging will be difficult for me. I could use recovery to reflash a
>>> fresh 18.06 build, and see if upgrade functionality is still broken in
>>> that case. I will report back with my findings.
>>>
>>> Yours sincerely,
>>>
>>> Jaap Buurman
>>
>> Dear all,
>>
>> This just popped up on the Lede forum:
>> https://forum.lede-project.org/t/xiaomi-wifi-router-3g/5377/879
>>
>> So this might simply be a (mt7621 specific?) bug that prevents
>> sysupgrade from working properly. I am still awaiting his answers to
>> verify that he is indeed also running into the same issue where to
>> firmware won't upgrade.
>>
>> Yours sincerely,
>>
>> Jaap Buurman
>>
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> http://lists.infradead.org/mailman/listinfo/openwrt-devel

I know how to fix the issue by recovery, however, from the responses
in the topic on the Lede forum it seems more people are running into
this issue. This definitely needs to be fixed before a 18.06 release.
Is there someone with a mt7621 device that can reproduce the problem,
and that has serial access? We might be able to figure out what is
going wrong.

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

[OpenWrt-Devel] node.js

[Levente]

Hi all,


There is a tutorial here:

https://wiki.openwrt.org/doc/howto/nodejs

on how to compile node.js into OpenWRT, but the that configuration
item is missing from menuconfig.

I checked the feed, and it is there in the build tree. There is a
dependency for the package, which is the FPU. So I made
kernel_menuconfig and ticked the MIPS FPU emulation.

I then went back to menuconfig, but there is still no sign of node.js.


Could you please help how to build node for OpenWRT?


Thanks,
Levente

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

[OpenWrt-Devel] [PATCH] mvebu: fix broken console on WRT32X (venom)

[michael . gray]

From: Michael Gray 

The console bootarg is being corrupted on boot, causing various issues
including broken sysupgrade.
Utilising the bootargs mangle patch from other targets, hardcode the console
arguments and fetch the rootfs from the bootloader.

Kernel command line: console=ttyS0,115200 root=/dev/mtdblock8

Bootloader command line (ignored): console= root=/dev/mtdblock8

Please cherry pick to 18.06 too

Signed-off-by: Michael Gray 
---
 target/linux/mvebu/config-4.14|   1 +
 .../arm/boot/dts/armada-385-linksys-venom.dts |   6 +
 ...Mangle-bootloader-s-kernel-arguments.patch | 189 ++
 3 files changed, 196 insertions(+)
 create mode 100644 
target/linux/mvebu/patches-4.14/006-generic-Mangle-bootloader-s-kernel-arguments.patch

diff --git a/target/linux/mvebu/config-4.14 b/target/linux/mvebu/config-4.14
index a48a3c8c5e..694ecdfb82 100644
--- a/target/linux/mvebu/config-4.14
+++ b/target/linux/mvebu/config-4.14
@@ -42,6 +42,7 @@ CONFIG_ARM_APPENDED_DTB=y
 CONFIG_ARM_ATAG_DTB_COMPAT=y
 # CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set
 CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y
+CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_MANGLE=y
 CONFIG_ARM_CPU_SUSPEND=y
 CONFIG_ARM_CRYPTO=y
 CONFIG_ARM_ERRATA_720789=y
diff --git 
a/target/linux/mvebu/files-4.14/arch/arm/boot/dts/armada-385-linksys-venom.dts 
b/target/linux/mvebu/files-4.14/arch/arm/boot/dts/armada-385-linksys-venom.dts
index ea44c8f0d2..00a4ee9f39 100644
--- 
a/target/linux/mvebu/files-4.14/arch/arm/boot/dts/armada-385-linksys-venom.dts
+++ 
b/target/linux/mvebu/files-4.14/arch/arm/boot/dts/armada-385-linksys-venom.dts
@@ -46,7 +46,13 @@
model = "Linksys WRT32X";
compatible = "linksys,venom", "linksys,armada385", "marvell,armada385",
 "marvell,armada380";
+
+   chosen {
+   bootargs = "console=ttyS0,115200";
+   stdout-path = "serial0:115200n8";
+   append-rootblock = "root=/dev/mtdblock";
};
+};
 
 {
wan_amber@0 {
diff --git 
a/target/linux/mvebu/patches-4.14/006-generic-Mangle-bootloader-s-kernel-arguments.patch
 
b/target/linux/mvebu/patches-4.14/006-generic-Mangle-bootloader-s-kernel-arguments.patch
new file mode 100644
index 00..be1a7e5648
--- /dev/null
+++ 
b/target/linux/mvebu/patches-4.14/006-generic-Mangle-bootloader-s-kernel-arguments.patch
@@ -0,0 +1,189 @@
+From 71270226b14733a4b1f2cde58ea9265caa50b38d Mon Sep 17 00:00:00 2001
+From: Adrian Panella 
+Date: Thu, 9 Mar 2017 09:37:17 +0100
+Subject: [PATCH 67/69] generic: Mangle bootloader's kernel arguments
+
+The command-line arguments provided by the boot loader will be
+appended to a new device tree property: bootloader-args.
+If there is a property "append-rootblock" in DT under /chosen
+and a root= option in bootloaders command line it will be parsed
+and added to DT bootargs with the form: XX.
+Only command line ATAG will be processed, the rest of the ATAGs
+sent by bootloader will be ignored.
+This is usefull in dual boot systems, to get the current root partition
+without afecting the rest of the system.
+
+Signed-off-by: Adrian Panella 
+---
+ arch/arm/Kconfig| 11 +
+ arch/arm/boot/compressed/atags_to_fdt.c | 72 -
+ init/main.c | 16 
+ 3 files changed, 98 insertions(+), 1 deletion(-)
+
+--- a/arch/arm/Kconfig
 b/arch/arm/Kconfig
+@@ -1948,6 +1948,17 @@ config ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEN
+ The command-line arguments provided by the boot loader will be
+ appended to the the device tree bootargs property.
+ 
++config ARM_ATAG_DTB_COMPAT_CMDLINE_MANGLE
++  bool "Append rootblock parsing bootloader's kernel arguments"
++  help
++The command-line arguments provided by the boot loader will be
++appended to a new device tree property: bootloader-args.
++If there is a property "append-rootblock" in DT under /chosen 
++and a root= option in bootloaders command line it will be parsed 
++and added to DT bootargs with the form: XX.
++Only command line ATAG will be processed, the rest of the ATAGs
++sent by bootloader will be ignored.
++
+ endchoice
+ 
+ config CMDLINE
+--- a/arch/arm/boot/compressed/atags_to_fdt.c
 b/arch/arm/boot/compressed/atags_to_fdt.c
+@@ -3,6 +3,8 @@
+ 
+ #if defined(CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND)
+ #define do_extend_cmdline 1
++#elif defined(CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_MANGLE)
++#define do_extend_cmdline 1
+ #else
+ #define do_extend_cmdline 0
+ #endif
+@@ -66,6 +68,59 @@ static uint32_t get_cell_size(const void
+   return cell_size;
+ }
+ 
++#if defined(CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_MANGLE)
++
++static char *append_rootblock(char *dest, const char *str, int len, void *fdt)
++{
++  char 

Re: [OpenWrt-Devel] RT5350F WiFi interface performance issue

[Zoltan Gyarmati]

On 25.05.2018 14:03, Koen Vandeputte wrote:



On 2018-05-25 13:30, Zoltan Gyarmati wrote:

Dear All,

 I'm testing the current OpenWrt  (master/HEAD) on RT5350F Olinuxino. 
Unfortunately the WiFi interface doesn't seem to work properly in 
client mode. `iwinfo wlan0 scan` runs successfully and shows my AP, 
but when i configure the interface as client and try to connect, the 
authentication seems to be successful (according to dmesg), but the 
wlan0 interface never gets IP address, even if i explicitly call 
udhcpc. If i set a static IP address for wlan0, and ping my AP, i 
have around 88% packet loss. There is no any relevant message in 
dmesg which could give a hint about the reason.


As a counter-check, i flashed the an old OpenWrt image from the HW 
vendor with kernel 3.18, and with that one the WiFi interface works 
properly.
Does anyone else experience similar issues (either on this or any 
other RT5350F board)? Do you have any advice what to look into to 
sort this out?



Thanks,



Hi,

When you build master, did it already contain commit "hostapd: update 
to git HEAD of 2018-05-21, allow build against wolfssl" ?
Could you also try to build the 18.06 which does not contain this one 
and compare?


You never know..


No, it didn't have that commit yet. Now i build an image with this new 
hostapd version and  I'll report. Thanks for the hint!





Koen

[1] 
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=69f544937f8498e856690f9809a016f0d7f5f68b








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

Re: [OpenWrt-Devel] [PATCH v3] ar71xx: add support for GL.iNet GL-AR750S

[Lucian Cristian]

On 25.05.2018 13:06, Luochongjun wrote:

This patch adds supports for GL-AR750S.

Specification:
- SOC: QCA9563 (775MHz)
- Flash: 16 MiB (W25Q128FVSG)
- RAM: 128 MiB DDR2
- Ethernet: 2x 1Gbps LAN + 1x 1Gbps WAN
- Wireless: 2.4GHz (bgn) and 5GHz (ac)
- USB: 1x USB 2.0 port
- Button: 1x switch button, 1x reset button
- LED: 3x LEDS (green)

Flash instruction:
Apply factory image via web-gui.

Signed-off-by: Luo chongjun 
---
  target/linux/ar71xx/base-files/etc/board.d/01_leds |   4 +
  .../linux/ar71xx/base-files/etc/board.d/02_network |   4 +
  .../etc/hotplug.d/firmware/11-ath10k-caldata   |   1 +
  target/linux/ar71xx/base-files/lib/ar71xx.sh   |   3 +
  .../ar71xx/base-files/lib/upgrade/platform.sh  |   1 +
  target/linux/ar71xx/config-4.9 |   1 +
  .../ar71xx/files/arch/mips/ath79/Kconfig.openwrt   |  11 ++
  target/linux/ar71xx/files/arch/mips/ath79/Makefile |   1 +
  .../ar71xx/files/arch/mips/ath79/mach-gl-ar750s.c  | 193 +
  .../linux/ar71xx/files/arch/mips/ath79/machtypes.h |   1 +
  target/linux/ar71xx/generic/config-default |   1 +
  target/linux/ar71xx/image/generic.mk   |  13 ++
  12 files changed, 234 insertions(+)
  create mode 100755 target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar750s.c

diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds 
b/target/linux/ar71xx/base-files/etc/board.d/01_leds
index 52f1ac3..f436854 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
+++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
@@ -385,6 +385,10 @@ gl-ar750)
ucidef_set_led_wlan "wlan2g" "WLAN2G" "$board:white:wlan2g" "phy1tpt"
ucidef_set_led_wlan "wlan5g" "WLAN5G" "$board:white:wlan5g" "phy0tpt"
;;
+gl-ar750s)
+   ucidef_set_led_wlan "wlan2g" "WLAN2G" "$board:green:wlan2g" "phy1tpt"
+   ucidef_set_led_wlan "wlan5g" "WLAN5G" "$board:green:wlan5g" "phy0tpt"
+   ;;
  gl-mifi)
ucidef_set_led_wlan "wlan" "WLAN" "$board:green:wlan" "phy0tpt"
ucidef_set_led_netdev "wan" "WAN" "$board:green:wan" "eth0"
diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network 
b/target/linux/ar71xx/base-files/etc/board.d/02_network
index 5898261..5f87ab1 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/02_network
+++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
@@ -432,6 +432,10 @@ ar71xx_setup_interfaces()
ucidef_add_switch "switch0" \
"0@eth1" "1:lan" "2:lan"
;;
+   gl-ar750s)
+   ucidef_add_switch "switch0" \
+   "0@eth0" "2:lan:2" "3:lan:1" "1:wan"
+   ;;
jwap230)
ucidef_set_interfaces_lan_wan "eth0.1" "eth1.2"
ucidef_add_switch "switch0" \
diff --git 
a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata 
b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index 5d01701..f82026c 100644
--- a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -99,6 +99,7 @@ case "$FIRMWARE" in
ath10kcal_extract "caldata" 20480 2116
ath10kcal_patch_mac $(macaddr_add $(cat 
/sys/class/net/eth0/address) +1)
;;
+   gl-ar750s|\
gl-ar750|\
tl-wpa8630)
ath10kcal_extract "art" 20480 2116
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh 
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index 42bd80d..74aa21b 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -727,6 +727,9 @@ ar71xx_board_detect() {
*"GL-AR750")
name="gl-ar750"
;;
+   *"GL-AR750S")
+   name="gl-ar750s"
+   ;;
*"GL-CONNECT INET v1")
name="gl-inet"
  
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh

index 284582f..d0a3f30 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -260,6 +260,7 @@ platform_check_image() {
gl-ar300m|\
gl-ar300|\
gl-ar750|\
+   gl-ar750s|\
gl-domino|\
gl-mifi|\
gl-usb150|\
diff --git a/target/linux/ar71xx/config-4.9 b/target/linux/ar71xx/config-4.9
index 35efd17..a453e10 100644
--- a/target/linux/ar71xx/config-4.9
+++ b/target/linux/ar71xx/config-4.9
@@ -120,6 +120,7 @@ CONFIG_ATH79=y
  # CONFIG_ATH79_MACH_GL_AR300 is not set
  # CONFIG_ATH79_MACH_GL_AR300M is not set
  # CONFIG_ATH79_MACH_GL_AR750 is not set
+# CONFIG_ATH79_MACH_GL_AR750S is not set
  # CONFIG_ATH79_MACH_GL_DOMINO is not set
  # CONFIG_ATH79_MACH_GL_INET is not set
  # CONFIG_ATH79_MACH_GL_MIFI is not set
diff --git 

Re: [OpenWrt-Devel] RT5350F WiFi interface performance issue

[Koen Vandeputte]

On 2018-05-25 13:30, Zoltan Gyarmati wrote:

Dear All,

 I'm testing the current OpenWrt  (master/HEAD) on RT5350F Olinuxino. 
Unfortunately the WiFi interface doesn't seem to work properly in 
client mode. `iwinfo wlan0 scan` runs successfully and shows my AP, 
but when i configure the interface as client and try to connect, the 
authentication seems to be successful (according to dmesg), but the 
wlan0 interface never gets IP address, even if i explicitly call 
udhcpc. If i set a static IP address for wlan0, and ping my AP, i have 
around 88% packet loss. There is no any relevant message in dmesg 
which could give a hint about the reason.


As a counter-check, i flashed the an old OpenWrt image from the HW 
vendor with kernel 3.18, and with that one the WiFi interface works 
properly.
Does anyone else experience similar issues (either on this or any 
other RT5350F board)? Do you have any advice what to look into to sort 
this out?



Thanks,



Hi,

When you build master, did it already contain commit "hostapd: update to 
git HEAD of 2018-05-21, allow build against wolfssl" ?
Could you also try to build the 18.06 which does not contain this one 
and compare?


You never know..


Koen

[1] 
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=69f544937f8498e856690f9809a016f0d7f5f68b






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

Re: [OpenWrt-Devel] 18.06 Bug: Baby Jumbo Frames on mt7621

[Levente]

Try upgrading the sysupgrade image using your bootloader.

Lev

On Fri, May 25, 2018 at 1:25 PM, Jaap Buurman  wrote:
> On Fri, May 25, 2018 at 1:14 PM, Jaap Buurman  wrote:
>> On Fri, May 25, 2018 at 12:43 PM, Mathias Kresin  wrote:
>>> 2018-05-25 12:48 GMT+03:00 Jaap Buurman :
 Dear Martin, Mathias and the rest,

 Please scratch my previous message. It seems like the flash was not
 successful, and hence I was still running the old firmware. However, I
 have tried flashing 3 different times now, without any luck. The
 router ends up rebooting and boots right into the old firmware. This
 seems to be a major bug. Is there anything I can do to help debug this
 particular issue?
>>>
>>> First of all, Martin is right. The commit in my staging tree should
>>> fix the MTU issue but I don't have the hardware to test it on my own.
>>>
>>> So far you never mentioned which board you have. Hence it's quite
>>> difficult to have a look at the code about what could be wrong. It
>>> would be helpful if you can name the last working revision to limit
>>> the number of commits to look at.
>>>
 Seems like a dealbreaker for 18.06 (which I am
 running now) to me. I could simply use recovery and flash a firmware
 like that, but I would prefer to get to the bottom of this issue so
 that end users won't end up stuck on a particular firmware. Any ideas
 what I could do to debug this?
>>>
>>> Your best bet is to attach the/a serial console and check the console
>>> for errors.
>>>
>>> Mathias
>>
>> My apologies for leaving out important details. I am using a Dir-860L
>> B1. I used to be running Lede 17.01.4, until last Tuesday. At that day
>> I upgraded to OpenWrt 18.06-SNAPSHOT r6917-8948a78 via Luci. Flashing
>> any other firmware seems to be broken now: I have tried flashing a
>> build compiled from your staging tree, I've tried reverting back to
>> 17.01.4 and I've tried reflashing 18.06. All end up in the exact same
>> spot: Still on the OpenWrt 18.06-SNAPSHOT r6917-8948a78 with all
>> manually installed packages still present. I've tried flashing via
>> Luci and via the sysupgrade command (with the -v switch for more
>> verbosity), but no useful information there. The last line that is
>> output is simply:
>>
>> Commencing upgrade. All shell sessions will be closed now.
>>
>> One particular weird thing that I do remember on this build, is the
>> fact that I tried to update all upgradable packages via OPKG (I know
>> this is discouraged). One of those packages was "base-files". The
>> upgrade failed with a weird error (can't remember what exactly), but
>> nothing seemed wrong at that time, so I didn't really think much about
>> it. Is there anyone more knowledgeable than me that knows whether this
>> could influence the sysupgrade functionality?
>>
>> Lastly, I do not have a serial cable unfortunately, so I think
>> debugging will be difficult for me. I could use recovery to reflash a
>> fresh 18.06 build, and see if upgrade functionality is still broken in
>> that case. I will report back with my findings.
>>
>> Yours sincerely,
>>
>> Jaap Buurman
>
> Dear all,
>
> This just popped up on the Lede forum:
> https://forum.lede-project.org/t/xiaomi-wifi-router-3g/5377/879
>
> So this might simply be a (mt7621 specific?) bug that prevents
> sysupgrade from working properly. I am still awaiting his answers to
> verify that he is indeed also running into the same issue where to
> firmware won't upgrade.
>
> Yours sincerely,
>
> Jaap Buurman
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> http://lists.infradead.org/mailman/listinfo/openwrt-devel

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

[OpenWrt-Devel] RT5350F WiFi interface performance issue

[Zoltan Gyarmati]

Dear All,

 I'm testing the current OpenWrt  (master/HEAD) on RT5350F Olinuxino. 
Unfortunately the WiFi interface doesn't seem to work properly in client 
mode. `iwinfo wlan0 scan` runs successfully and shows my AP, but when i 
configure the interface as client and try to connect, the authentication 
seems to be successful (according to dmesg), but the wlan0 interface 
never gets IP address, even if i explicitly call udhcpc. If i set a 
static IP address for wlan0, and ping my AP, i have around 88% packet 
loss. There is no any relevant message in dmesg which could give a hint 
about the reason.


As a counter-check, i flashed the an old OpenWrt image from the HW 
vendor with kernel 3.18, and with that one the WiFi interface works 
properly.
Does anyone else experience similar issues (either on this or any other 
RT5350F board)? Do you have any advice what to look into to sort this out?



Thanks,

--
Zoltan Gyarmati
https://zgyarmati.de



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

Re: [OpenWrt-Devel] 18.06 Bug: Baby Jumbo Frames on mt7621

[Jaap Buurman]

On Fri, May 25, 2018 at 1:14 PM, Jaap Buurman  wrote:
> On Fri, May 25, 2018 at 12:43 PM, Mathias Kresin  wrote:
>> 2018-05-25 12:48 GMT+03:00 Jaap Buurman :
>>> Dear Martin, Mathias and the rest,
>>>
>>> Please scratch my previous message. It seems like the flash was not
>>> successful, and hence I was still running the old firmware. However, I
>>> have tried flashing 3 different times now, without any luck. The
>>> router ends up rebooting and boots right into the old firmware. This
>>> seems to be a major bug. Is there anything I can do to help debug this
>>> particular issue?
>>
>> First of all, Martin is right. The commit in my staging tree should
>> fix the MTU issue but I don't have the hardware to test it on my own.
>>
>> So far you never mentioned which board you have. Hence it's quite
>> difficult to have a look at the code about what could be wrong. It
>> would be helpful if you can name the last working revision to limit
>> the number of commits to look at.
>>
>>> Seems like a dealbreaker for 18.06 (which I am
>>> running now) to me. I could simply use recovery and flash a firmware
>>> like that, but I would prefer to get to the bottom of this issue so
>>> that end users won't end up stuck on a particular firmware. Any ideas
>>> what I could do to debug this?
>>
>> Your best bet is to attach the/a serial console and check the console
>> for errors.
>>
>> Mathias
>
> My apologies for leaving out important details. I am using a Dir-860L
> B1. I used to be running Lede 17.01.4, until last Tuesday. At that day
> I upgraded to OpenWrt 18.06-SNAPSHOT r6917-8948a78 via Luci. Flashing
> any other firmware seems to be broken now: I have tried flashing a
> build compiled from your staging tree, I've tried reverting back to
> 17.01.4 and I've tried reflashing 18.06. All end up in the exact same
> spot: Still on the OpenWrt 18.06-SNAPSHOT r6917-8948a78 with all
> manually installed packages still present. I've tried flashing via
> Luci and via the sysupgrade command (with the -v switch for more
> verbosity), but no useful information there. The last line that is
> output is simply:
>
> Commencing upgrade. All shell sessions will be closed now.
>
> One particular weird thing that I do remember on this build, is the
> fact that I tried to update all upgradable packages via OPKG (I know
> this is discouraged). One of those packages was "base-files". The
> upgrade failed with a weird error (can't remember what exactly), but
> nothing seemed wrong at that time, so I didn't really think much about
> it. Is there anyone more knowledgeable than me that knows whether this
> could influence the sysupgrade functionality?
>
> Lastly, I do not have a serial cable unfortunately, so I think
> debugging will be difficult for me. I could use recovery to reflash a
> fresh 18.06 build, and see if upgrade functionality is still broken in
> that case. I will report back with my findings.
>
> Yours sincerely,
>
> Jaap Buurman

Dear all,

This just popped up on the Lede forum:
https://forum.lede-project.org/t/xiaomi-wifi-router-3g/5377/879

So this might simply be a (mt7621 specific?) bug that prevents
sysupgrade from working properly. I am still awaiting his answers to
verify that he is indeed also running into the same issue where to
firmware won't upgrade.

Yours sincerely,

Jaap Buurman

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

Re: [OpenWrt-Devel] 18.06 Bug: Baby Jumbo Frames on mt7621

[Jaap Buurman]

On Fri, May 25, 2018 at 12:43 PM, Mathias Kresin  wrote:
> 2018-05-25 12:48 GMT+03:00 Jaap Buurman :
>> Dear Martin, Mathias and the rest,
>>
>> Please scratch my previous message. It seems like the flash was not
>> successful, and hence I was still running the old firmware. However, I
>> have tried flashing 3 different times now, without any luck. The
>> router ends up rebooting and boots right into the old firmware. This
>> seems to be a major bug. Is there anything I can do to help debug this
>> particular issue?
>
> First of all, Martin is right. The commit in my staging tree should
> fix the MTU issue but I don't have the hardware to test it on my own.
>
> So far you never mentioned which board you have. Hence it's quite
> difficult to have a look at the code about what could be wrong. It
> would be helpful if you can name the last working revision to limit
> the number of commits to look at.
>
>> Seems like a dealbreaker for 18.06 (which I am
>> running now) to me. I could simply use recovery and flash a firmware
>> like that, but I would prefer to get to the bottom of this issue so
>> that end users won't end up stuck on a particular firmware. Any ideas
>> what I could do to debug this?
>
> Your best bet is to attach the/a serial console and check the console
> for errors.
>
> Mathias

My apologies for leaving out important details. I am using a Dir-860L
B1. I used to be running Lede 17.01.4, until last Tuesday. At that day
I upgraded to OpenWrt 18.06-SNAPSHOT r6917-8948a78 via Luci. Flashing
any other firmware seems to be broken now: I have tried flashing a
build compiled from your staging tree, I've tried reverting back to
17.01.4 and I've tried reflashing 18.06. All end up in the exact same
spot: Still on the OpenWrt 18.06-SNAPSHOT r6917-8948a78 with all
manually installed packages still present. I've tried flashing via
Luci and via the sysupgrade command (with the -v switch for more
verbosity), but no useful information there. The last line that is
output is simply:

Commencing upgrade. All shell sessions will be closed now.

One particular weird thing that I do remember on this build, is the
fact that I tried to update all upgradable packages via OPKG (I know
this is discouraged). One of those packages was "base-files". The
upgrade failed with a weird error (can't remember what exactly), but
nothing seemed wrong at that time, so I didn't really think much about
it. Is there anyone more knowledgeable than me that knows whether this
could influence the sysupgrade functionality?

Lastly, I do not have a serial cable unfortunately, so I think
debugging will be difficult for me. I could use recovery to reflash a
fresh 18.06 build, and see if upgrade functionality is still broken in
that case. I will report back with my findings.

Yours sincerely,

Jaap Buurman

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

Re: [OpenWrt-Devel] 18.06 Bug: Baby Jumbo Frames on mt7621

[Mathias Kresin]

2018-05-25 12:48 GMT+03:00 Jaap Buurman :
> Dear Martin, Mathias and the rest,
>
> Please scratch my previous message. It seems like the flash was not
> successful, and hence I was still running the old firmware. However, I
> have tried flashing 3 different times now, without any luck. The
> router ends up rebooting and boots right into the old firmware. This
> seems to be a major bug. Is there anything I can do to help debug this
> particular issue?

First of all, Martin is right. The commit in my staging tree should
fix the MTU issue but I don't have the hardware to test it on my own.

So far you never mentioned which board you have. Hence it's quite
difficult to have a look at the code about what could be wrong. It
would be helpful if you can name the last working revision to limit
the number of commits to look at.

> Seems like a dealbreaker for 18.06 (which I am
> running now) to me. I could simply use recovery and flash a firmware
> like that, but I would prefer to get to the bottom of this issue so
> that end users won't end up stuck on a particular firmware. Any ideas
> what I could do to debug this?

Your best bet is to attach the/a serial console and check the console
for errors.

Mathias

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

Re: [OpenWrt-Devel] LEDE 17.01.5 release planning

[Stijn Segers]

Hauke Mehrtens  schreef op 24 mei 2018 21:06:55 CEST:
>We would like to create a lede 17.01.5 release soon, the last release,
>lede 17.01.4, was done on 18. October 2017 which was a long time ago.
>We are planning to do the build by end of next week, around 2. June
>2018.
>
>This release would be build form the lede-17.01 stable branch and
>contain all the fixes which are in this branch.
>For me this branch looks quite good, if there are any patches missing
>in
>the lede-17.01 branch which you think should be backported from the
>current master branch then please highlight this now, so we can have a
>look at this.
>
>I will update the kernel used in lede-17.01 to the latest version from
>the stable 4.4 kernel line sometime beginning next week.
>
>Please also report any regression which is in the current lede-17.01
>branch compared to the lede 17.01.4 release.
>
>Please do not hesitate to re report some request that something should
>be backported from master or some regression compared to lede-17.01, if
>it looks like they got ignored and didn't got a response.
>
Hi Hauke,

WNR2000v3 images are still being built but sysupgrading them from old versions 
seems broken, maybe someone could look into this? With 18.06 around the corner 
as well, might be handy to have this fixed.

https://bugs.openwrt.org/index.php?do=details_id=672=WNR2000

Stijn

>All the developers can cherry picking some commits from master by them
>self. ;-)
>
>The versions of the packages can be found here:
>https://sdwalker.github.io/uscan/index-17.01.html
>
>The current snapshot build from the lede-17.01 branch can be found
>here:
>https://downloads.lede-project.org/releases/17.01-SNAPSHOT/
>
>Hauke
>
>___
>openwrt-devel mailing list
>openwrt-devel@lists.openwrt.org
>http://lists.infradead.org/mailman/listinfo/openwrt-devel


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

Re: [OpenWrt-Devel] [PATCH 1/2] ramips: Use generic board detect for GnuBee devices

[Mathias Kresin]

2018-05-25 6:43 GMT+03:00 Rosen Penev :
> This is a port of an old commit from mkresin's tree:
>
> 09260cdf3e9332978c2a474a58e93a6f2b55f4a8
>
> This has the potential to break sysupgrade but it should be fine as
> there is no stable release of LEDE or OpenWrt that support these devices.
>
> Signed-off-by: Rosen Penev 
> ---
>  target/linux/ramips/base-files/etc/board.d/01_leds | 4 ++--
>  target/linux/ramips/base-files/etc/board.d/02_network  | 4 ++--
>  target/linux/ramips/base-files/etc/diag.sh | 4 ++--
>  target/linux/ramips/base-files/lib/ramips.sh   | 3 ---
>  target/linux/ramips/base-files/lib/upgrade/platform.sh | 4 ++--
>  target/linux/ramips/dts/GB-PC1.dts | 2 +-
>  target/linux/ramips/dts/GB-PC2.dts | 2 +-
>  target/linux/ramips/image/mt7621.mk| 8 
>  8 files changed, 14 insertions(+), 17 deletions(-)
>
> diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds 
> b/target/linux/ramips/base-files/etc/board.d/01_leds
> index 88e4c2b7fe..79f2cc2b87 100755
> --- a/target/linux/ramips/base-files/etc/board.d/01_leds
> +++ b/target/linux/ramips/base-files/etc/board.d/01_leds
> @@ -196,8 +196,8 @@ fonera20n)
> set_usb_led "$boardname:orange:usb"
> set_wifi_led "$boardname:orange:wifi"
> ;;
> -gb-pc1|\
> -gnubee,gb-pc2)
> +gnubee,pc1|\
> +gnubee,pc2)
> ucidef_set_led_switch "lan1" "lan1" "$boardname:green:lan1" "switch0" 
> "0x01"
> ucidef_set_led_switch "lan2" "lan2" "$boardname:green:lan2" "switch0" 
> "0x10"
> ;;

This will not work. You need to rename the LEDs from gb-pc[1|2]:green:
to pc[1|2]:green: in the devicetree source files.

But instead of doing so, please drop the compatible changes, and use
"gnubee,gb-pc1". I don't see much gain in changing them.

Mathias

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

[OpenWrt-Devel] [PATCH v3] ar71xx: add support for GL.iNet GL-AR750S

[Luochongjun]

This patch adds supports for GL-AR750S.

Specification:
- SOC: QCA9563 (775MHz)
- Flash: 16 MiB (W25Q128FVSG)
- RAM: 128 MiB DDR2
- Ethernet: 2x 1Gbps LAN + 1x 1Gbps WAN
- Wireless: 2.4GHz (bgn) and 5GHz (ac)
- USB: 1x USB 2.0 port
- Button: 1x switch button, 1x reset button
- LED: 3x LEDS (green)

Flash instruction:
Apply factory image via web-gui.

Signed-off-by: Luo chongjun 
---
 target/linux/ar71xx/base-files/etc/board.d/01_leds |   4 +
 .../linux/ar71xx/base-files/etc/board.d/02_network |   4 +
 .../etc/hotplug.d/firmware/11-ath10k-caldata   |   1 +
 target/linux/ar71xx/base-files/lib/ar71xx.sh   |   3 +
 .../ar71xx/base-files/lib/upgrade/platform.sh  |   1 +
 target/linux/ar71xx/config-4.9 |   1 +
 .../ar71xx/files/arch/mips/ath79/Kconfig.openwrt   |  11 ++
 target/linux/ar71xx/files/arch/mips/ath79/Makefile |   1 +
 .../ar71xx/files/arch/mips/ath79/mach-gl-ar750s.c  | 193 +
 .../linux/ar71xx/files/arch/mips/ath79/machtypes.h |   1 +
 target/linux/ar71xx/generic/config-default |   1 +
 target/linux/ar71xx/image/generic.mk   |  13 ++
 12 files changed, 234 insertions(+)
 create mode 100755 target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar750s.c

diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds 
b/target/linux/ar71xx/base-files/etc/board.d/01_leds
index 52f1ac3..f436854 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
+++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
@@ -385,6 +385,10 @@ gl-ar750)
ucidef_set_led_wlan "wlan2g" "WLAN2G" "$board:white:wlan2g" "phy1tpt"
ucidef_set_led_wlan "wlan5g" "WLAN5G" "$board:white:wlan5g" "phy0tpt"
;;
+gl-ar750s)
+   ucidef_set_led_wlan "wlan2g" "WLAN2G" "$board:green:wlan2g" "phy1tpt"
+   ucidef_set_led_wlan "wlan5g" "WLAN5G" "$board:green:wlan5g" "phy0tpt"
+   ;;
 gl-mifi)
ucidef_set_led_wlan "wlan" "WLAN" "$board:green:wlan" "phy0tpt"
ucidef_set_led_netdev "wan" "WAN" "$board:green:wan" "eth0"
diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network 
b/target/linux/ar71xx/base-files/etc/board.d/02_network
index 5898261..5f87ab1 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/02_network
+++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
@@ -432,6 +432,10 @@ ar71xx_setup_interfaces()
ucidef_add_switch "switch0" \
"0@eth1" "1:lan" "2:lan"
;;
+   gl-ar750s)
+   ucidef_add_switch "switch0" \
+   "0@eth0" "2:lan:2" "3:lan:1" "1:wan"
+   ;;
jwap230)
ucidef_set_interfaces_lan_wan "eth0.1" "eth1.2"
ucidef_add_switch "switch0" \
diff --git 
a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata 
b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index 5d01701..f82026c 100644
--- a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -99,6 +99,7 @@ case "$FIRMWARE" in
ath10kcal_extract "caldata" 20480 2116
ath10kcal_patch_mac $(macaddr_add $(cat 
/sys/class/net/eth0/address) +1)
;;
+   gl-ar750s|\
gl-ar750|\
tl-wpa8630)
ath10kcal_extract "art" 20480 2116
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh 
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index 42bd80d..74aa21b 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -727,6 +727,9 @@ ar71xx_board_detect() {
*"GL-AR750")
name="gl-ar750"
;;
+   *"GL-AR750S")
+   name="gl-ar750s"
+   ;;
*"GL-CONNECT INET v1")
name="gl-inet"
 
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh 
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 284582f..d0a3f30 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -260,6 +260,7 @@ platform_check_image() {
gl-ar300m|\
gl-ar300|\
gl-ar750|\
+   gl-ar750s|\
gl-domino|\
gl-mifi|\
gl-usb150|\
diff --git a/target/linux/ar71xx/config-4.9 b/target/linux/ar71xx/config-4.9
index 35efd17..a453e10 100644
--- a/target/linux/ar71xx/config-4.9
+++ b/target/linux/ar71xx/config-4.9
@@ -120,6 +120,7 @@ CONFIG_ATH79=y
 # CONFIG_ATH79_MACH_GL_AR300 is not set
 # CONFIG_ATH79_MACH_GL_AR300M is not set
 # CONFIG_ATH79_MACH_GL_AR750 is not set
+# CONFIG_ATH79_MACH_GL_AR750S is not set
 # CONFIG_ATH79_MACH_GL_DOMINO is not set
 # CONFIG_ATH79_MACH_GL_INET is not set
 # CONFIG_ATH79_MACH_GL_MIFI is not set
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt 

Re: [OpenWrt-Devel] 18.06 Bug: Baby Jumbo Frames on mt7621

[Jaap Buurman]

On Fri, May 25, 2018 at 11:30 AM, Jaap Buurman  wrote:
> On Thu, May 24, 2018 at 8:00 PM, Martin Blumenstingl
>  wrote:
>> Hello Jaap,
>>
>> On Thu, May 24, 2018 at 12:00 PM, Jaap Buurman  wrote:
>>> Dear all,
>>>
>>> I found some additional information in the system log: Thu May 24
>>> 11:38:39 2018 kern.err kernel: [83864.729458] eth0: Invalid MTU 1508
>>> requested, hw max 1500
>>> Digging deeper, this seems like a message that is spawned by a
>>> function in /net/core.dev.c of the linux kernel:
>>>
>>> if (dev->max_mtu > 0 && new_mtu > dev->max_mtu) {
>>> net_err_ratelimited("%s: Invalid MTU %d requested, hw max %d\n",
>>> dev->name, new_mtu, dev->max_mtu);
>>> return -EINVAL;
>>> }
>>>
>>> Is there anybody that happens to know where exactly this max_mtu value
>>> is set to 1500? For mt7621 devices this should be 2048 (Baby jambo
>>> frames).
>>>
>>> Thank you very much in advance.
>>>
>>> Yours sincerely,
>>>
>>> Jaap Buurman
>>>
>>> On Tue, May 22, 2018 at 3:05 PM, Jaap Buurman  wrote:
 Dear all,

 The switch to the 4.14 kernel apparently broke the baby jumbo frames
 support of 2048 bytes that the switch is capable off. I found out that
 changing the mtu above 1500 via Luci no longer applies properly.
 Trying to manually change the mtu via ssh also fails:

 root@LEDE:~# ifconfig eth0 mtu 1508 up
 ifconfig: SIOCSIFMTU: Invalid argument

 If there is any additional information that I can supply, please let
 me know. I am also more than willing to help test potential fixes :)
>> I *believe* Mathias has a fix for this in his tree (but I'm not sure
>> if he has the hardware to test it): [0]
>> maybe you can give it a go and report back?
>>
>>
>> Regards
>> Martin
>>
>>
>> [0] 
>> https://git.openwrt.org/?p=openwrt/staging/mkresin.git;a=commitdiff;h=cc5f1fe7aa02943f3b39ffbd9dc3b8fcad569c8f
>
> Dear Martin and Mathias,
>
> I have compiled and flashed an image from Mathias' tree checked out at
> the commit linked in Martin's previous message. Unfortunately, I am
> still seeing the following message in dmesg:
> [  243.845159] eth0: Invalid MTU 1508 requested, hw max 1500
>
> If there are additional tests you would like me to run, please do not
> hesitate to contact me :)
>
> Yours sincerely,
>
> Jaap Buurman

Dear Martin, Mathias and the rest,

Please scratch my previous message. It seems like the flash was not
successful, and hence I was still running the old firmware. However, I
have tried flashing 3 different times now, without any luck. The
router ends up rebooting and boots right into the old firmware. This
seems to be a major bug. Is there anything I can do to help debug this
particular issue? Seems like a dealbreaker for 18.06 (which I am
running now) to me. I could simply use recovery and flash a firmware
like that, but I would prefer to get to the bottom of this issue so
that end users won't end up stuck on a particular firmware. Any ideas
what I could do to debug this?

Yours sincerely,

Jaap Buurman

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

Re: [OpenWrt-Devel] 18.06 Bug: Baby Jumbo Frames on mt7621

[Jaap Buurman]

On Thu, May 24, 2018 at 8:00 PM, Martin Blumenstingl
 wrote:
> Hello Jaap,
>
> On Thu, May 24, 2018 at 12:00 PM, Jaap Buurman  wrote:
>> Dear all,
>>
>> I found some additional information in the system log: Thu May 24
>> 11:38:39 2018 kern.err kernel: [83864.729458] eth0: Invalid MTU 1508
>> requested, hw max 1500
>> Digging deeper, this seems like a message that is spawned by a
>> function in /net/core.dev.c of the linux kernel:
>>
>> if (dev->max_mtu > 0 && new_mtu > dev->max_mtu) {
>> net_err_ratelimited("%s: Invalid MTU %d requested, hw max %d\n",
>> dev->name, new_mtu, dev->max_mtu);
>> return -EINVAL;
>> }
>>
>> Is there anybody that happens to know where exactly this max_mtu value
>> is set to 1500? For mt7621 devices this should be 2048 (Baby jambo
>> frames).
>>
>> Thank you very much in advance.
>>
>> Yours sincerely,
>>
>> Jaap Buurman
>>
>> On Tue, May 22, 2018 at 3:05 PM, Jaap Buurman  wrote:
>>> Dear all,
>>>
>>> The switch to the 4.14 kernel apparently broke the baby jumbo frames
>>> support of 2048 bytes that the switch is capable off. I found out that
>>> changing the mtu above 1500 via Luci no longer applies properly.
>>> Trying to manually change the mtu via ssh also fails:
>>>
>>> root@LEDE:~# ifconfig eth0 mtu 1508 up
>>> ifconfig: SIOCSIFMTU: Invalid argument
>>>
>>> If there is any additional information that I can supply, please let
>>> me know. I am also more than willing to help test potential fixes :)
> I *believe* Mathias has a fix for this in his tree (but I'm not sure
> if he has the hardware to test it): [0]
> maybe you can give it a go and report back?
>
>
> Regards
> Martin
>
>
> [0] 
> https://git.openwrt.org/?p=openwrt/staging/mkresin.git;a=commitdiff;h=cc5f1fe7aa02943f3b39ffbd9dc3b8fcad569c8f

Dear Martin and Mathias,

I have compiled and flashed an image from Mathias' tree checked out at
the commit linked in Martin's previous message. Unfortunately, I am
still seeing the following message in dmesg:
[  243.845159] eth0: Invalid MTU 1508 requested, hw max 1500

If there are additional tests you would like me to run, please do not
hesitate to contact me :)

Yours sincerely,

Jaap Buurman

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

Re: [OpenWrt-Devel] [PATCH] wolfssl: update to version 3.14.4

[Alexandru Ardelean]

On Fri, May 25, 2018 at 1:18 AM, Daniel Golle  wrote:
> Hi!
>
> On Thu, May 24, 2018 at 10:38:45PM +0300, Alexandru Ardelean wrote:
>> On Thu, May 24, 2018 at 7:34 PM, Daniel Golle  wrote:
>> > Use download from github archive corresponding to v3.14.4 tag because
>> > the project's website apparently only offers 3.14.0-stable release
>> > downloads.
>> > Drop local patch for CVE-2017-13099 as it was merged upstream.
>> >
>>
>> Looks good.
>> On a related note, would you like to take over the package ?
>> I don't seem to find time for it at the moment.
>
> You had that nice patch to improve the build-time configuration half-
> ready. It'd really be nice to still incooperate that...
> I do believe you are doing a good job as a maintainer, however, if you
> feel burdened by the maintainership I'm also ok to take over.
>

Not so much burdened as much as I don't want to block other people.
So, if you don't feel blocked, I can still keep maintaining it.

I will make time for that configuration patch.

Thanks
Alex

>
> Cheers
>
>
> Daniel

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