[OpenWrt-Devel] [PATCH 3/3] brcm63xx: VH4032N: add the SPROM fixups

2018-11-13 Thread Daniel Gonzalez Cabanelas 
Add the SPROM fixups for the onboard BCM43222 wifi on the Observa
VH4032N

Signed-off-by: Daniel Gonzalez Cabanelas 
---
 .../brcm63xx/patches-4.14/577-board_VH4032N.patch  | 70 --
 .../brcm63xx/patches-4.14/578-board_R1000H.patch   |  4 +-
 .../brcm63xx/patches-4.14/579-board_AR-5315u.patch |  4 +-
 .../brcm63xx/patches-4.14/580-board_AD1018.patch   |  4 +-
 .../brcm63xx/patches-4.14/598-board_sr102.patch|  6 +-
 5 files changed, 75 insertions(+), 13 deletions(-)

diff --git a/target/linux/brcm63xx/patches-4.14/577-board_VH4032N.patch 
b/target/linux/brcm63xx/patches-4.14/577-board_VH4032N.patch
index e9bf9a7..8339d42 100644
--- a/target/linux/brcm63xx/patches-4.14/577-board_VH4032N.patch
+++ b/target/linux/brcm63xx/patches-4.14/577-board_VH4032N.patch
@@ -1,14 +1,70 @@
 --- a/arch/mips/bcm63xx/boards/board_bcm963xx.c
 +++ b/arch/mips/bcm63xx/boards/board_bcm963xx.c
-@@ -2266,6 +2266,44 @@ static struct board_info __initdata boar
+@@ -2266,6 +2266,106 @@ static struct board_info __initdata boar
},
  };
  
++static struct sprom_fixup __initdata vh4032n_fixups[] = {
++  { .offset = 2, .value = 0x04d2 },
++  { .offset = 4, .value = 0x4350 },
++  { .offset = 65, .value = 0x1300 },
++  { .offset = 68, .value = 0x0402 },
++  { .offset = 70, .value = 0x0090 },
++  { .offset = 71, .value = 0x4c19 },
++  { .offset = 72, .value = 0x2345 },
++  { .offset = 87, .value = 0x0315 },
++  { .offset = 88, .value = 0x0315 },
++  { .offset = 96, .value = 0x2048 },
++  { .offset = 97, .value = 0xfed7 },
++  { .offset = 98, .value = 0x15a6 },
++  { .offset = 99, .value = 0xfaee },
++  { .offset = 100, .value = 0x3e3a },
++  { .offset = 101, .value = 0x3a36 },
++  { .offset = 102, .value = 0xff7f },
++  { .offset = 103, .value = 0x11b9 },
++  { .offset = 104, .value = 0xfc53 },
++  { .offset = 105, .value = 0xffe6 },
++  { .offset = 106, .value = 0xfdd2 },
++  { .offset = 107, .value = 0xfe49 },
++  { .offset = 108, .value = 0xff6a },
++  { .offset = 109, .value = 0x136e },
++  { .offset = 110, .value = 0xfbed },
++  { .offset = 111, .value = 0x },
++  { .offset = 112, .value = 0x2048 },
++  { .offset = 113, .value = 0xfee2 },
++  { .offset = 114, .value = 0x15e5 },
++  { .offset = 115, .value = 0xfaed },
++  { .offset = 116, .value = 0x3e3a },
++  { .offset = 117, .value = 0x3a36 },
++  { .offset = 118, .value = 0xffc8 },
++  { .offset = 119, .value = 0x12b8 },
++  { .offset = 120, .value = 0xfca1 },
++  { .offset = 121, .value = 0xff9b },
++  { .offset = 122, .value = 0x122a },
++  { .offset = 123, .value = 0xfcc8 },
++  { .offset = 124, .value = 0xff95 },
++  { .offset = 125, .value = 0x146b },
++  { .offset = 126, .value = 0xfbba },
++  { .offset = 127, .value = 0x },
++  { .offset = 161, .value = 0x },
++  { .offset = 162, .value = 0x },
++  { .offset = 169, .value = 0x },
++  { .offset = 170, .value = 0x },
++  { .offset = 171, .value = 0x },
++  { .offset = 172, .value = 0x },
++  { .offset = 173, .value = 0x },
++  { .offset = 174, .value = 0x },
++  { .offset = 175, .value = 0x },
++  { .offset = 176, .value = 0x },
++  { .offset = 219, .value = 0x1108 },
++};
++
 +static struct board_info __initdata board_VH4032N = {
 +  .name   = "VH4032N",
 +  .expected_cpu_id= 0x6368,
 +
 +  .has_pci= 1,
++  .use_fallback_sprom = 1,
 +  .has_ohci0  = 1,
 +  .has_ehci0  = 1,
 +  .num_usbh_ports = 2,
@@ -39,13 +95,19 @@
 +  },
 +  },
 +
-+  .use_fallback_sprom = 1,
++  .fallback_sprom = {
++  .type   = SPROM_BCM43222,
++  .pci_bus= 0,
++  .pci_dev= 1,
++  .board_fixups   = vh4032n_fixups,
++  .num_board_fixups   = ARRAY_SIZE(vh4032n_fixups),
++  },
 +};
 +
  static struct sprom_fixup __initdata wap5813n_fixups[] = {
{ .offset = 97, .value = 0xfeed },
{ .offset = 98, .value = 0x15d1 },
-@@ -2548,6 +2586,7 @@ static const struct board_info __initcon
+@@ -2548,6 +2648,7 @@ static const struct board_info __initcon
_HG622,
_HG655b,
_P870HW51A_V2,
@@ -53,7 +115,7 @@
_VR3025u,
_VR3025un,
_VR3026e,
-@@ -2659,6 +2698,7 @@ static struct of_device_id const bcm963x
+@@ -2659,6 +2760,7 @@ static struct of_device_id const bcm963x
{ .compatible = "huawei,hg655b", .data = _HG655b, },
{ .compatible = "netgear,dgnd3700v1", .data = _DGND3700v1_3800B, 
},
{ .compatible = "netgear,evg2000", .data = _EVG2000, },
diff --git

[OpenWrt-Devel] [PATCH 1/3] brcm63xx: VH4032N: fix issues with pinctrl

2018-11-13 Thread Daniel Gonzalez Cabanelas 
The Observa VH4032N has some troubles related to the pinctrl since the adoption
of this driver:  

  - missing pinctrl avoiding to operate the wifi correctly
  - missing pinctrls avoiding the LAN LEDs to be hardware controlled
  - the GPIO hog doesn't work, and as a result of this the onboard USB HUB 
isn't 
pulled out of reset. Also the GPIO chip fails to register and the LEDs 
won't work.

Fix it by adding the missing pincontrols. And workaround the USB HUB issue
by pulling it out of reset using a fake LED on the GPIO pin.

Leave the GPIO hog code disabled until this feature works with the
brcm63xx GPIO pinctrl.

Signed-off-by: Daniel Gonzalez Cabanelas 
---
This patch superseeds: "brcm63xx: VH4032N: add missing pinctrl"

 target/linux/brcm63xx/dts/vh4032n.dts | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/target/linux/brcm63xx/dts/vh4032n.dts 
b/target/linux/brcm63xx/dts/vh4032n.dts
index 1296fbf..156d103 100644
--- a/target/linux/brcm63xx/dts/vh4032n.dts
+++ b/target/linux/brcm63xx/dts/vh4032n.dts
@@ -68,16 +68,27 @@
label = "VH4032N:red:voice";
gpios = < 26 1>;
};
+   /* Use this workaround until the gpio-hog works again */
+   usb_hub_reset {
+   label = "usb-hub-reset-gpio";
+   gpios = < 27 0>;
+   default-state = "on";
+   };
};
 };
 
  {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pci _ephy0_led _ephy1_led
+_ephy2_led _ephy3_led>;
+#if 0
usb_hub_reset {
gpio-hog;
gpios = <27 0>;
output-high;
line-name = "usb-hub-reset-gpio";
};
+#endif
 };
 
  {
-- 
2.6.4



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

[OpenWrt-Devel] [PATCH 2/3] brcm63xx: VH4032N: fix the power led and the wlan button

2018-11-13 Thread Daniel Gonzalez Cabanelas 
  - use the blue LED for power, since the red LED is already used by
CFE in emergency mode.
  - use the correct code for the wlan button

Signed-off-by: Daniel Gonzalez Cabanelas 
---
 target/linux/brcm63xx/base-files/etc/diag.sh | 2 +-
 target/linux/brcm63xx/dts/vh4032n.dts| 8 
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/target/linux/brcm63xx/base-files/etc/diag.sh 
b/target/linux/brcm63xx/base-files/etc/diag.sh
index afb3478..34464ec 100644
--- a/target/linux/brcm63xx/base-files/etc/diag.sh
+++ b/target/linux/brcm63xx/base-files/etc/diag.sh
@@ -43,7 +43,7 @@ set_state() {
status_led="spw303v:green:power+adsl"
;;
vh4032n)
-   status_led="VH4032N:red:power"
+   status_led="VH4032N:blue:power"
;;
vr-3025un)
status_led="VR-3025un:green:power"
diff --git a/target/linux/brcm63xx/dts/vh4032n.dts 
b/target/linux/brcm63xx/dts/vh4032n.dts
index 156d103..682d9d6 100644
--- a/target/linux/brcm63xx/dts/vh4032n.dts
+++ b/target/linux/brcm63xx/dts/vh4032n.dts
@@ -25,10 +25,10 @@
gpios = < 34 1>;
linux,code = ;
};
-   wps {
-   label = "wps";
+   wlan {
+   label = "wlan";
gpios = < 35 1>;
-   linux,code = ;
+   linux,code = ;
};
};
 
@@ -54,11 +54,11 @@
power_blue {
label = "VH4032N:blue:power";
gpios = < 22 0>;
+   default-state = "on";
};
power_red {
label = "VH4032N:red:power";
gpios = < 24 0>;
-   default-state = "on";

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

[OpenWrt-Devel] [PATCH] flex: Add a lex symlink

2018-11-13 Thread Rosen Penev 
Some packages like libpfring assume the presense of lex, which on some
other systems is a symlink to flex but not all. Symlink flex to fix
compilation.

Arch Linux and Fedora do this as far as I know.

Signed-off-by: Rosen Penev 
---
 tools/flex/Makefile | 5 +
 1 file changed, 5 insertions(+)

diff --git a/tools/flex/Makefile b/tools/flex/Makefile
index 1eff81f345..bb5aecbdfe 100644
--- a/tools/flex/Makefile
+++ b/tools/flex/Makefile
@@ -21,6 +21,11 @@ include $(INCLUDE_DIR)/host-build.mk
 
 HOST_CONFIGURE_ARGS += --disable-shared
 
+define Host/Install
+   $(call Host/Install/Default)
+   $(LN) flex $(STAGING_DIR_HOST)/bin/lex
+endef
+
 define Host/Clean
-$(MAKE) -C $(HOST_BUILD_DIR) uninstall
$(call Host/Clean/Default)
-- 
2.19.1


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

Re: [OpenWrt-Devel] OpenWrt Roadmap

2018-11-13 Thread Rosen Penev 
On Tue, Nov 13, 2018 at 10:13 AM Fernando Frediani  wrote:
>
> Hi.
>
> I think there is a little misunderstanding about this topic.
> As many know here for OpenWrt doesn't quiet work as the same for a
> company's project where you may have dedicated people to a project.
> People work in the stuff they get interested and give some attention to
> whatever is agreed by the project guidelines.
> I am sure developers will continue to dedicate most of their time to the
> newer and trunk versions and if agreed to extend LEDE 17.01 EOL to it as
> well whenever is strictly necessary.
It would be very nice for people still working on 17.01 to post their changes.
>
> The idea put is to extend LEDE 17.01 EOL a little while (not forever)
> because it has been reported by a significant amount of people that
> 18.06 is not an option anymore for a large amount of older but still
> usable devices due its bigger footprint. Also to minimize the amount of
> attention it may require the idea is not to have new features but only
> critical security and bug fixes. If 18.06 was an option this would not
> be necessary but as there has been significant improvements to this
> version then extending LEDE 17.01 EOL becomes justifiable given the
> number of active devices that still benefit for it.
>
> Best regards
> Fernando
>
> On 12/11/2018 20:39, Alberto Bursi wrote:
> >
> > On 12/11/18 21:57, Fernando Frediani wrote:
> >> Totally agree with Luiz. That was the idea behind this proposal and
> >> you managed to even easier words.
> >>
> >> Alberto, the tiny subtarget you mentioned doesn't really seem to run
> >> well or stably for 18.06 on many of these devices regardless the
> >> flash size, that's the main point.
> >> As mentioned there are many new devices still coming with 32MB of RAM
> >> and which can take benefit of OpenWrt for various reasons and usages.
> >> I think for many of us here are completely fine to put some extra
> >> cash and buy a newer hardware to cope with OpenWrt evolution but the
> >> reality is that majority of people are not. Another example I wanted
> >> to put to illustrate is an ISP that has thousands of existing devices
> >> with similar specs running, being still able to keep using OpenWrt
> >> more securely while they start to introduce newer hardware to their
> >> customer base allowing to make a more smooth transition to these more
> >> powerful hardware.
> >
> >
> > I quite frankly don't believe it's worth allocating what limited
> > manpower there is. While I'm not a OpenWrt developer and I don't speak
> > on behalf of the project, I really believe that you are
> > underestimating the effort required behind even a basic LTS release
> > like a "only core packages" or such. I think that if translated into
> > man-hours (and therefore money) it would amount to much higher than
> > just letting devices go EOL and have people replace them.
> >
> > The ISP can pay for someone to do this job if they think really need
> > it (but imho it would be better to spend their funds in newer
> > hardware, besides they should have planned for hardware obsolescence
> > already).
> >
> > As a point of comparison, even Debian that is far larger than OpenWrt
> > only agreed to extend the support period for its old release (which is
> > a "mostly core packages" affair too, kernel, basic userspace and
> > server software) after some sponsors showed up and paid for it.
> >
> > -Alberto
> >
> >
> >>
> >> Regards
> >> Fernando
> >>
> >> On 12/11/2018 18:20, Luiz Angelo Daros de Luca wrote:
> >>> Hello,
> >>>
> >>> There are a significant amount of devices out there that has 4/32
> >>> specs. Even brand new ones.
> >>> If there is stability issues with newer OpenWrt versions on those
> >>> devices, we should rethink LEDE EOL.
> >>>
> >>> Maintenance burden is directly related to the amount of software to
> >>> maintain. At the same time, low specs means they might have no
> >>> interest in most packages.
> >>> Maybe 15.05 life could be extend with a lower cost by limiting
> >>> maintenance to a subset of packages (core? even less?). We could
> >>> release LEDE 15.05.(x+1) LTS with feeds configured to use only that
> >>> subset of packages. We could also limit the images to those low spec
> >>> models.
> >>>
> >>> EOL is not really a big deal until it requires a new HW. Routers are
> >>> things that die hard, even after a decade. It just doesn't seem right
> >>> to turn old working hw into electronic waste because of software.
> >>> Keeping old stuff running is even on of the reasons to use OSS.
> >>>
> >>> Regards,
> >>>
> >>> ___
> >>> openwrt-devel mailing list
> >>> openwrt-devel@lists.openwrt.org
> >>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> >>
> >> ___
> >> openwrt-devel mailing list
> >> openwrt-devel@lists.openwrt.org
> >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> >
> >

Re: [OpenWrt-Devel] OpenWrt Roadmap

2018-11-13 Thread Fernando Frediani 

Hi.

I think there is a little misunderstanding about this topic.
As many know here for OpenWrt doesn't quiet work as the same for a 
company's project where you may have dedicated people to a project. 
People work in the stuff they get interested and give some attention to 
whatever is agreed by the project guidelines.
I am sure developers will continue to dedicate most of their time to the 
newer and trunk versions and if agreed to extend LEDE 17.01 EOL to it as 
well whenever is strictly necessary.


The idea put is to extend LEDE 17.01 EOL a little while (not forever) 
because it has been reported by a significant amount of people that 
18.06 is not an option anymore for a large amount of older but still 
usable devices due its bigger footprint. Also to minimize the amount of 
attention it may require the idea is not to have new features but only 
critical security and bug fixes. If 18.06 was an option this would not 
be necessary but as there has been significant improvements to this 
version then extending LEDE 17.01 EOL becomes justifiable given the 
number of active devices that still benefit for it.


Best regards
Fernando

On 12/11/2018 20:39, Alberto Bursi wrote:


On 12/11/18 21:57, Fernando Frediani wrote:
Totally agree with Luiz. That was the idea behind this proposal and 
you managed to even easier words.


Alberto, the tiny subtarget you mentioned doesn't really seem to run 
well or stably for 18.06 on many of these devices regardless the 
flash size, that's the main point.
As mentioned there are many new devices still coming with 32MB of RAM 
and which can take benefit of OpenWrt for various reasons and usages. 
I think for many of us here are completely fine to put some extra 
cash and buy a newer hardware to cope with OpenWrt evolution but the 
reality is that majority of people are not. Another example I wanted 
to put to illustrate is an ISP that has thousands of existing devices 
with similar specs running, being still able to keep using OpenWrt 
more securely while they start to introduce newer hardware to their 
customer base allowing to make a more smooth transition to these more 
powerful hardware.



I quite frankly don't believe it's worth allocating what limited 
manpower there is. While I'm not a OpenWrt developer and I don't speak 
on behalf of the project, I really believe that you are 
underestimating the effort required behind even a basic LTS release 
like a "only core packages" or such. I think that if translated into 
man-hours (and therefore money) it would amount to much higher than 
just letting devices go EOL and have people replace them.


The ISP can pay for someone to do this job if they think really need 
it (but imho it would be better to spend their funds in newer 
hardware, besides they should have planned for hardware obsolescence 
already).


As a point of comparison, even Debian that is far larger than OpenWrt 
only agreed to extend the support period for its old release (which is 
a "mostly core packages" affair too, kernel, basic userspace and 
server software) after some sponsors showed up and paid for it.


-Alberto




Regards
Fernando

On 12/11/2018 18:20, Luiz Angelo Daros de Luca wrote:

Hello,

There are a significant amount of devices out there that has 4/32
specs. Even brand new ones.
If there is stability issues with newer OpenWrt versions on those
devices, we should rethink LEDE EOL.

Maintenance burden is directly related to the amount of software to
maintain. At the same time, low specs means they might have no
interest in most packages.
Maybe 15.05 life could be extend with a lower cost by limiting
maintenance to a subset of packages (core? even less?). We could
release LEDE 15.05.(x+1) LTS with feeds configured to use only that
subset of packages. We could also limit the images to those low spec
models.

EOL is not really a big deal until it requires a new HW. Routers are
things that die hard, even after a decade. It just doesn't seem right
to turn old working hw into electronic waste because of software.
Keeping old stuff running is even on of the reasons to use OSS.

Regards,

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


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


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


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

[OpenWrt-Devel] [PATCH v2] octeon: Allow sysupgrade restore on ER

2018-11-13 Thread Jonathan Thibault 
This is a very simple patch that completes sysupgrade functionality on 
UBNT ER8.


Default layout leaves about 128MB free on the kernel partition so there 
is plenty of space for temporary config backups.


This version checks board names in alphabetical order.


diff --git a/target/linux/octeon/base-files/lib/preinit/79_move_config 
b/target/linux/octeon/base-files/lib/preinit/79_move_config

index ec63d9f5ff..470cbfe005 100644
--- a/target/linux/octeon/base-files/lib/preinit/79_move_config
+++ b/target/linux/octeon/base-files/lib/preinit/79_move_config
@@ -5,6 +5,11 @@ move_config() {
. /lib/functions.sh

case "$(board_name)" in
+   er)
+   mount -t vfat /dev/mmcblk0p1 /mnt
+   [ -f /mnt/sysupgrade.tgz ] && mv -f 
/mnt/sysupgrade.tgz /

+   umount /mnt
+   ;;
erlite)
mount -t vfat /dev/sda1 /mnt
[ -f /mnt/sysupgrade.tgz ] && mv -f 
/mnt/sysupgrade.tgz /
diff --git a/target/linux/octeon/base-files/lib/upgrade/platform.sh 
b/target/linux/octeon/base-files/lib/upgrade/platform.sh

index cd49c0da36..009eae7a2c 100755
--- a/target/linux/octeon/base-files/lib/upgrade/platform.sh
+++ b/target/linux/octeon/base-files/lib/upgrade/platform.sh
@@ -23,6 +23,11 @@ platform_get_rootfs() {

 platform_copy_config() {
case "$(board_name)" in
+   er)
+   mount -t vfat /dev/mmcblk0p1 /mnt
+   cp -af "$CONF_TAR" /mnt/
+   umount /mnt
+   ;;
erlite)
mount -t vfat /dev/sda1 /mnt
cp -af "$CONF_TAR" /mnt/
@@ -62,12 +67,12 @@ platform_do_upgrade() {

[ -b "${rootfs}" ] || return 1
case "$board" in
-   erlite)
-   kernel=sda1
-   ;;
er)
kernel=mmcblk0p1
;;
+   erlite)
+   kernel=sda1
+   ;;
*)
return 1
esac
@@ -82,8 +87,8 @@ platform_check_image() {
local board=$(board_name)

case "$board" in
-   erlite | \
-   er)
+   er | \
+   erlite)
local tar_file="$1"
local kernel_length=`(tar xf $tar_file 
sysupgrade-$board/kernel -O | wc -c) 2> /dev/null`
local rootfs_length=`(tar xf $tar_file 
sysupgrade-$board/root -O | wc -c) 2> /dev/null`




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

Re: [OpenWrt-Devel] [PATCH] octeon: Allow sysupgrade restore on ER

2018-11-13 Thread Jonathan Thibault 

On 12/11/18 03:45 PM, Stijn Tintel wrote:

On 12/11/18 17:56, Jonathan Thibault wrote:

This is a very simple patch that completes sysupgrade functionality on
UBNT ER8.

Default layout leaves about 128MB free on the kernel partition so
there is plenty of space for temporary config backups.


diff --git a/target/linux/octeon/base-files/lib/preinit/79_move_config
b/target/linux/octeon/base-files/lib/preinit/79_move_config
index ec63d9f5ff..d50bac081b 100644
--- a/target/linux/octeon/base-files/lib/preinit/79_move_config
+++ b/target/linux/octeon/base-files/lib/preinit/79_move_config
@@ -10,6 +10,11 @@ move_config() {
 [ -f /mnt/sysupgrade.tgz ] && mv -f
/mnt/sysupgrade.tgz /
 umount /mnt
 ;;
+   er)
+   mount -t vfat /dev/mmcblk0p1 /mnt
+   [ -f /mnt/sysupgrade.tgz ] && mv -f
/mnt/sysupgrade.tgz /
+   umount /mnt
+   ;;

Please order the options alphabetically.

 esac
  }

diff --git a/target/linux/octeon/base-files/lib/upgrade/platform.sh
b/target/linux/octeon/base-files/lib/upgrade/platform.sh
index cd49c0da36..2a2136f196 100755
--- a/target/linux/octeon/base-files/lib/upgrade/platform.sh
+++ b/target/linux/octeon/base-files/lib/upgrade/platform.sh
@@ -28,6 +28,11 @@ platform_copy_config() {
 cp -af "$CONF_TAR" /mnt/
 umount /mnt
 ;;
+   er)
+   mount -t vfat /dev/mmcblk0p1 /mnt
+   cp -af "$CONF_TAR" /mnt/
+   umount /mnt
+   ;;

Same here.

 esac
  }


Thanks,
Stijn

No problem.  I actually matched the order that was already in the file 
but I'll fix that as well and resubmit.



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

[OpenWrt-Devel] [PATCH] ramips: Add support for ZTE ZXECS EBG3130 aka BDCOM WAP2100-SK

2018-11-13 Thread Petr Štetiar 
From: Petr Štetiar 

On the bottom sticker it's branded as ZTE ZXECS EBG3130 device, but in factory
OpenWrt image it's referenced as BDCOM WAP2100-SK device.

Specifications:

- SoC: MediaTek MT7620A
- RAM: 128 MB
- Flash: 16 MB
- Ethernet: 5 FE ports
- Wireless radio: 2T2R 2.4 GHz and 1T1R 5 GHz (MT7610EN, unsupported)
- UART: 1 x UART on PCB marked as J2 (R=RX, T=TX, G=GND) with 115200 8N1 config
- LEDs: Power, FE ports 1-5, WPS, USB, RF 2.4G, RF 5G
- Other: USB port, SD card slot and 2x external antennas (non-detachable)

Flashing instructions:

A) The U-Boot has HTTP based firmware upgrade

  A1) Flashing notes

  We've identified so far two different batches of units, unfortunately
  each batch has different U-Boot bootloader flashed with different
  default environment variables, thus each batch has different IP address
  for accessing web based firmware updater.

  * First batch has web based bootloader IP address 1.1.1.1
  * Second batch has web based bootloader IP address 192.168.1.250

  In case you can't connect to either of those IPs, you can try to get
  the default IP address via two methods:

  A1.1) Serial console, then the IP address is visible during the boot

   ...
   HTTP server is starting at IP: 1.1.1.1
   raspi_read: from:40004 len:6
   HTTP server is ready!
   ...

  A1.2) Over telnet/SSH using this command:

   root@bdcom:/# grep ipaddr= /dev/mtd0
   ipaddr=1.1.1.1

  A2) Flashing with browser

  * Change IP address of PC to 1.1.1.2 with 255.255.255.0 netmask
  * Reboot the device and try to reach web based bootloader in the
browser with the following URL http://1.1.1.1

  * Quickly select the firmware sysupgrade file and click on the
`Update firmware` button, this all has to be done within 10 seconds,
bootloader doesn't wait any longer

   If done correctly, the web page should show UPDATE IN PROGRESS page
   with progress indicator. Once the flashing completes (it takes roughly
   around 1 minute), the device will reboot to the OpenWrt firmware

  A3) Flashing with curl

   sudo ip addr add 1.1.1.2/24 dev eth0
   curl \
  --verbose \
  --retry 3 \
  --retry-delay 1 \
  --retry-max-time 30 \
  --connect-timeout 30 \
  --form 
"firmware=@openwrt-ramips-mt7620-BDCOM-WAP2100-SK-squashfs-sysupgrade.bin" \
  http://1.1.1.1

   Now power on the router.

B) The U-boot is based on Ralink SDK so we can flash the firmware using UART.

   1. Configure PC with a static IP address and setup an TFTP server.
   2. Put the firmware into the tftp directory.
   3. Connect the UART line as described on the PCB (G=GND, R=RX, T=TX)
   4. Power up the device and press 2, follow the instruction to set device and
  tftp server IP address and input the firmware file name. U-boot will then 
load
  the firmware and write it into the flash.

Signed-off-by: Petr Štetiar 
---
 target/linux/ramips/base-files/etc/board.d/01_leds |   4 +
 .../linux/ramips/base-files/etc/board.d/02_network |   1 +
 target/linux/ramips/base-files/lib/ramips.sh   |   3 +
 .../ramips/base-files/lib/upgrade/platform.sh  |   1 +
 target/linux/ramips/dts/BDCOM-WAP2100-SK.dts   | 130 +
 target/linux/ramips/image/mt7620.mk|   9 ++
 6 files changed, 148 insertions(+)
 create mode 100644 target/linux/ramips/dts/BDCOM-WAP2100-SK.dts

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 2644bc0..aa6525d 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -364,6 +364,10 @@ vocore-16M)
 w502u)
set_wifi_led "rt2800pci-phy0::radio"
;;
+wap2100-sk)
+   set_usb_led "$boardname:green:usb"
+   set_wifi_led "$boardname:green:wlan2g"
+   ;;
 we1026-5g-16m)
ucidef_set_led_netdev "lan" "LAN" "we1026-5g:green:lan" "eth0"
set_wifi_led "we1026-5g:green:wifi"
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index 9e9ecbc..a7ebd04 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -224,6 +224,7 @@ ramips_setup_interfaces()
ubnt-erx|\
ubnt-erx-sfp|\
ur-326n4g|\
+   wap2100-sk|\
wrtnode|\
wrtnode2p | \
wrtnode2r | \
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index 5741cbd..ba6a13b 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -553,6 +553,9 @@ ramips_board_detect() {
*"W502U")
name="w502u"
;;
+   *"WAP2100-SK")
+   name="wap2100-sk"
+   ;;
*"WCR-1166DS")
name="wcr-1166ds"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh