Re: [LEDE-DEV] [PATCH] kernel: Backport net struct reduction from 4.16.

[Mathias Kresin]

23.03.2018 19:19, Rosen Penev:

This patch series shrinks the networking structs in order to reduce cache 
misses. This has performance benefits in routing.

Full details here: 
https://www.netdevconf.org/2.2/slides/miller-datastructurebloat-keynote.pdf

I'm keeping this for kernel 4.14 as it's easier to port.

I have tested this on mvebu for several days with no issues to report. mvebu is 
powerful enough for gigabit routing though.


I gave it a try on lantiq, as I benchmarked the flow offloading impact 
anyway.


Doing my usual iperf3 test, I wasn't able to notice any improvement with 
the patches applied. The differences are rather within the measuring 
tolerance:


=HEAD=

net to client   95.2 Mbits/sec routing
client to net   109 Mbits/sec  routing

net to client   85.6 Mbits/sec NAT
client to net   96.2 Mbits/sec NAT


=k4.16 net struct reduction=

net to client   92.4 Mbits/sec routing
client to net   107 Mbits/sec  routing

net to client   83.7 Mbits/sec NAT
client to net   93.4 Mbits/sec NAT


=FLOW_OFFLOADING=

net to client   129 Mbits/sec routing
client to net   144 Mbits/sec routing

net to client   124 Mbits/sec NAT
client to net   144 Mbits/sec NAT


=FLOW_OFFLOADING + k4.16 net struct reduction=

net to client   130 Mbits/sec routing
client to net   140 Mbits/sec routing

net to client   126 Mbits/sec NAT
client to net   140 Mbits/sec NAT


As long as nobody proves that there is a real performance gain, I don't 
see a reason to backport the datastruct debloat.


Mathias

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

Re: [LEDE-DEV] [PATCH v2] ramips: fix GL-inet GL-MT300N-V2 LAN MAC address

[Mathias Kresin]

20.03.2018 09:54, Kyson Lok:

Override the LAN MAC to use the same address as WAN.
The stock firmware uses the same MAC address for all
interfaces.

Signed-off-by: Kyson Lok 
---
  target/linux/ramips/base-files/etc/board.d/02_network | 1 +
  1 file changed, 1 insertion(+)

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 03f718e..c26d77f 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -441,6 +441,7 @@ ramips_setup_macs()
wan_mac=$(mtd_get_mac_ascii config WAN_MAC_ADDR)
;;
gl-mt300n-v2)
+   lan_mac=$(mtd_get_mac_binary factory 4)
wan_mac=$(mtd_get_mac_binary factory 4)
;;
hc5*61|\



This change looks unnecessary to me. The very same MAC-Address should be 
already assigned via the dts:


88  {
89 mtd-mac-address = < 0x4>;
90 };

As far as I remember, the WAN MAC-Address is only set because the switch 
driver autoincrements the base MAC-Address for the second vlan (if not 
for each vlan). Hopefully I don't mix the different switch drivers here, 
at least one of the ramips switch driver does this autoincrement.


Long story short, I either fail hard or this change triggers something 
else which fixes your customers issue.


Mathias

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

Re: [LEDE-DEV] [PATCH v2] ramips: fix GL-inet GL-MT300N-V2 LAN MAC address

[Mathias Kresin]

20.03.2018 10:22, Koen Vandeputte:



On 2018-03-20 09:54, Kyson Lok wrote:

Override the LAN MAC to use the same address as WAN.
The stock firmware uses the same MAC address for all
interfaces.

Besides blindly following the stock firmware behavior,
is there *any* advantage in doing this?


The general idea is to not use MAC-Addresses which are not assigned 
to/reserved for this particular board.


Mathias

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

Re: [LEDE-DEV] [PATCH 3/3] lantiq: add support for AVM FRITZ!Box 7412

[Mathias Kresin]

Hey Valentin,

I spotted only minor stuff. Find my review inline.

I added Stefan Koch, he is way familiar with the telephony stuff and 
might see why it doesn't work for you.


Mathias

09.03.2018 20:17, Valentin Spreckels:

Specification:
- SoC: Lantiq VRX 220
- CPU Cores: 2x MIPS 34Kc at 500 MHz
- RAM: 128 MiB 250 MHz
- Storage: 128 MiB NAND flash
- Ethernet: built-in Fast Ethernet switch, only port 2 is used
- Wireless: Atheros AR9287-BL1A b/g/n with 2 pcb antennas
- Modem: built-in A/VDSL2 modem
- DECT: Dialog SC14441
- LEDs: 1 two-color, 4 one-color
- Buttons: 2
- FXS: 1 port via TAE or RJ12 connector

Working:
- ethernet
- wifi
- leds
- buttons
- dsl

Not working:
- Second cpu core


The second core doesn't work due to the nosmp in the bootargs. The 
second core is used for the telephony stuff. It is an XOR, either 
telephony support or second cpu core available for linux.



- FXS


@Stefan, do you see anything missing to get FXS working with this board?


- DECT

Installation:

1. Use the eva_ramboot.py script to load an initramfs image on the
device. Run it a few seconds after turning the device on.
$ scripts/flashing eva_ramboot 192.168.178.1 
bin/targets/lantiq/xrx200/openwrt-lantiq-xrx200-avm_fritz7412-initramfs-kernel.bin

If it fails to find the device try the ip address 169.254.120.1.
(Firmware updates or the recovery tool apparently change it.)

2. The device will load it in ram and boot it. You can reach it under
the openwrt default ip address 192.168.1.1.

3. Check if the key linux_fs_start is not set to 1 in tffs:
$ fritz_tffs_nand -d /dev/mtd1 -n linux_fs_start
If it is set to 1, the bootloader will select the wrong set of
partitions. Restart the box and install an FritzOS upgrade or do a
recovery. Afterwards start again at step 1.

4. Run sysupgrade to persistently install OpenWRT.

Signed-off-by: Valentin Spreckels 

---
  .../linux/lantiq/base-files/etc/board.d/02_network |   8 +
  .../etc/hotplug.d/firmware/12-ath9k-eeprom |   3 +
  .../lantiq/base-files/lib/upgrade/platform.sh  |   2 +-
  .../files-4.14/arch/mips/boot/dts/FRITZ7412.dts| 241 
  .../files-4.9/arch/mips/boot/dts/FRITZ7412.dts | 242 +
  .../lantiq/files-4.9/arch/mips/boot/dts/vr9.dtsi   |   2 +-
  target/linux/lantiq/image/Makefile |  13 ++
  7 files changed, 509 insertions(+), 2 deletions(-)
  create mode 100644 
target/linux/lantiq/files-4.14/arch/mips/boot/dts/FRITZ7412.dts
  create mode 100644 
target/linux/lantiq/files-4.9/arch/mips/boot/dts/FRITZ7412.dts

diff --git a/target/linux/lantiq/base-files/etc/board.d/02_network 
b/target/linux/lantiq/base-files/etc/board.d/02_network
index ca974b071e..defdc1a94d 100755
--- a/target/linux/lantiq/base-files/etc/board.d/02_network
+++ b/target/linux/lantiq/base-files/etc/board.d/02_network
@@ -154,6 +154,14 @@ avm,fritz7360sl)
"0:lan:3" "1:lan:4" "2:lan:2" "4:lan:1" "6t@eth0"
;;
  
+avm,fritz7412)

+   tffsdev=$(find_mtd_chardev "nand-tffs")
+   annex="b"
+   lan_mac=$(/usr/bin/fritz_tffs_nand -d $tffsdev -n maca)
+   wan_mac=$(/usr/bin/fritz_tffs_nand -d $tffsdev -n macdsl)
+   ucidef_set_interface_lan 'eth0'
+   ;;
+
  siemens,gigaset-sx76x)
annex="b"
ucidef_add_switch "switch0" \
diff --git 
a/target/linux/lantiq/base-files/etc/hotplug.d/firmware/12-ath9k-eeprom 
b/target/linux/lantiq/base-files/etc/hotplug.d/firmware/12-ath9k-eeprom
index 498a509012..68181c7b87 100644
--- a/target/linux/lantiq/base-files/etc/hotplug.d/firmware/12-ath9k-eeprom
+++ b/target/linux/lantiq/base-files/etc/hotplug.d/firmware/12-ath9k-eeprom
@@ -141,6 +141,9 @@ case "$FIRMWARE" in
avm,fritz3370|avm,fritz7320|avm,fritz7360sl)
ath9k_eeprom_extract "urlader" 2437 0
;;
+   avm,fritz7412)
+   /usr/bin/fritz_cal_extract -i 1 -s 0x1e000 -e 0x207 -l 
4096 -o /lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader")
+   ;;
tplink,tdw8970|tplink,tdw8980)
ath9k_eeprom_extract "boardconfig" 135168 0
;;
diff --git a/target/linux/lantiq/base-files/lib/upgrade/platform.sh 
b/target/linux/lantiq/base-files/lib/upgrade/platform.sh
index 2e58cb799a..7a43e7e12e 100755
--- a/target/linux/lantiq/base-files/lib/upgrade/platform.sh
+++ b/target/linux/lantiq/base-files/lib/upgrade/platform.sh
@@ -9,7 +9,7 @@ platform_do_upgrade() {
local board=$(board_name)
  
  	case "$board" in

-   
bt,homehub-v2b|bt,homehub-v3a|bt,homehub-v5a|zyxel,p-2812hnu-f1|zyxel,p-2812hnu-f3)
+   
avm,fritz7412|bt,homehub-v2b|bt,homehub-v3a|bt,homehub-v5a|zyxel,p-2812hnu-f1|zyxel,p-2812hnu-f3)
nand_do_upgrade $1
;;
*)
diff --git 

Re: [LEDE-DEV] [PATCH] ar71xx: initial board support for tl-hs110

[Mathias Kresin]

2018-01-24 17:45 GMT+01:00 Arvid E. Picciani :
> Signed-off-by: Arvid E. Picciani 
> ---

I marked the patch as "superseded". The review of the very same patch
send as Pull Request has already started.

Please stick to one way of sending patches.

Mathias

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

Re: [LEDE-DEV] [PATCH] mt7621: Add back CONFIG_SCHED_HRTICK to kernel config

[Mathias Kresin]

15.01.2018 22:30, Rosen Penev:

It is defined in generic yes. From discussions on IRC, the issue may
be related to something else. I will do further testing to see whether
or not this is correct. Should take me another week or so...

I still have no idea why in 17.01 CONIG_SCHED_HRTICK is defined in
generic and in a bunch of architectures whereas it;'s only defined in
trunk in generic.


It is as simple as the 17.01 (sub)target kernel configs weren't updated 
at some point. A 'make kernel_menuconfig CONFIG_TARGET=subtarget' will 
drop the redundant kernel config symbol from the 17.01 (sub)target 
configs as well.


Mathias

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

Re: [LEDE-DEV] [PATCH] mt7621: Add back CONFIG_SCHED_HRTICK to kernel config

[Mathias Kresin]

15.01.2018 21:09, Rosen Penev:

Fixes FS #1242.

The way I figured this out was by using diff on config-4.4 from 17.01
and config-4.9 from trunk. First I removed CONFIG options. That did not work.
Then I started adding. This one seems to do the trick.

The issue is that anything in /dev/sdX starts returning bad data when read.
PCIe or USB does not matter. I have not tested NVME since I lack the hardware.
/dev/mtdblockX may or may not be impacted. No idea.

Signed-off-by: Rosen Penev 
---
  target/linux/ramips/mt7621/config-4.9 | 1 +
  1 file changed, 1 insertion(+)

diff --git a/target/linux/ramips/mt7621/config-4.9 
b/target/linux/ramips/mt7621/config-4.9
index f9765ed..0ea6798 100644
--- a/target/linux/ramips/mt7621/config-4.9
+++ b/target/linux/ramips/mt7621/config-4.9
@@ -233,6 +233,7 @@ CONFIG_RTC_CLASS=y
  CONFIG_RTC_DRV_PCF8563=y
  CONFIG_RTC_I2C_AND_SPI=y
  CONFIG_RTC_MC146818_LIB=y
+CONFIG_SCHED_HRTICK=y
  # CONFIG_SCHED_INFO is not set
  CONFIG_SCHED_SMT=y
  # CONFIG_SCSI_DMA is not set


What ever the root cause of your issue is, it isn't CONFIG_SCHED_HRTICK 
since it is already enabled for mt7621:


$ git grep CONFIG_SCHED_HRTICK
target/linux/gemini/config-4.4:# CONFIG_SCHED_HRTICK is not set
target/linux/generic/config-4.14:CONFIG_SCHED_HRTICK=y
target/linux/generic/config-4.4:CONFIG_SCHED_HRTICK=y
target/linux/generic/config-4.9:CONFIG_SCHED_HRTICK=y
target/linux/mcs814x/config-3.18:# CONFIG_SCHED_HRTICK is not set
target/linux/omap24xx/config-4.1:CONFIG_SCHED_HRTICK=y
target/linux/ppc40x/config-3.18:CONFIG_SCHED_HRTICK=y
target/linux/ppc44x/config-3.18:CONFIG_SCHED_HRTICK=y
target/linux/rb532/config-4.9:# CONFIG_SCHED_HRTICK is not set

For further patches, please explain in the commit message why the change 
fixes the issue and move the not commit message related text below the 
tear line.


Mathias

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

[LEDE-DEV] [PATCH] treewide: move nand_do_upgrade call to platform_do_upgrade

[Mathias Kresin]

Calling nand_do_upgrade() from platform_pre_upgrade() was deprecated
with 30f61a34b4cf ("base-files: always use staged sysupgrade").

Update the platform upgrade code to use platform_do_upgrade() for NAND
images as well.

Signed-off-by: Mathias Kresin <d...@kresin.me>
---
 .../apm821xx/base-files/lib/upgrade/platform.sh| 21 ++
 .../ar71xx/base-files/lib/upgrade/platform.sh  | 86 +++---
 .../linux/imx6/base-files/lib/upgrade/platform.sh  |  2 +-
 .../lantiq/base-files/lib/upgrade/platform.sh  |  7 +-
 .../mediatek/base-files/lib/upgrade/platform.sh| 27 ---
 .../linux/oxnas/base-files/lib/upgrade/platform.sh |  2 +-
 .../pistachio/base-files/lib/upgrade/platform.sh   |  2 +-
 .../linux/rb532/base-files/lib/upgrade/platform.sh |  6 +-
 8 files changed, 69 insertions(+), 84 deletions(-)

diff --git a/target/linux/apm821xx/base-files/lib/upgrade/platform.sh 
b/target/linux/apm821xx/base-files/lib/upgrade/platform.sh
index a45af7d..ced8ce1 100755
--- a/target/linux/apm821xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/apm821xx/base-files/lib/upgrade/platform.sh
@@ -18,21 +18,6 @@ platform_check_image() {
esac
 }
 
-platform_pre_upgrade() {
-   local board=$(board_name)
-
-   case "$board" in
-   meraki,mr24|\
-   meraki,mx60|\
-   netgear,wndr4700)
-   nand_do_upgrade "$1"
-   ;;
-
-   *)
-   ;;
-   esac
-}
-
 platform_do_upgrade() {
local board=$(board_name)
 
@@ -41,7 +26,11 @@ platform_do_upgrade() {
wd,mybooklive-duo)
mbl_do_upgrade "$ARGV"
;;
-
+   meraki,mr24|\
+   meraki,mx60|\
+   netgear,wndr4700)
+   nand_do_upgrade "$1"
+   ;;
*)
default_do_upgrade "$ARGV"
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh 
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 35c6886..6f48294 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -675,45 +675,6 @@ platform_pre_upgrade() {
local board=$(board_name)
 
case "$board" in
-   c-60|\
-   hiveap-121|\
-   nbg6716|\
-   r6100|\
-   rambutan|\
-   rb-411|\
-   rb-411u|\
-   rb-433|\
-   rb-433u|\
-   rb-435g|\
-   rb-450|\
-   rb-450g|\
-   rb-493|\
-   rb-493g|\
-   rb-750|\
-   rb-750gl|\
-   rb-751|\
-   rb-751g|\
-   rb-911g-2hpnd|\
-   rb-911g-5hpacd|\
-   rb-911g-5hpnd|\
-   rb-912uag-2hpnd|\
-   rb-912uag-5hpnd|\
-   rb-921gs-5hpacd-r2|\
-   rb-951g-2hnd|\
-   rb-951ui-2hnd|\
-   rb-2011il|\
-   rb-2011l|\
-   rb-2011uas|\
-   rb-2011uas-2hnd|\
-   rb-2011uias|\
-   rb-2011uias-2hnd|\
-   rb-sxt2n|\
-   rb-sxt5n|\
-   wi2a-ac200i|\
-   wndr3700v4|\
-   wndr4300)
-   nand_do_upgrade "$1"
-   ;;
rb-750-r2|\
rb-750p-pbr2|\
rb-750up-r2|\
@@ -728,10 +689,6 @@ platform_pre_upgrade() {
# erase firmware if booted from initramfs
[ -z "$(rootfs_type)" ] && mtd erase firmware
;;
-   mr18|\
-   z1)
-   merakinand_do_upgrade "$1"
-   ;;
esac
 }
 
@@ -820,6 +777,49 @@ platform_do_upgrade() {
om5p-an)
platform_do_upgrade_openmesh "$ARGV"
;;
+   c-60|\
+   hiveap-121|\
+   nbg6716|\
+   r6100|\
+   rambutan|\
+   rb-411|\
+   rb-411u|\
+   rb-433|\
+   rb-433u|\
+   rb-435g|\
+   rb-450|\
+   rb-450g|\
+   rb-493|\
+   rb-493g|\
+   rb-750|\
+   rb-750gl|\
+   rb-751|\
+   rb-751g|\
+   rb-911g-2hpnd|\
+   rb-911g-5hpacd|\
+   rb-911g-5hpnd|\
+   rb-912uag-2hpnd|\
+   rb-912uag-5hpnd|\
+   rb-921gs-5hpacd-r2
+   rb-951g-2hnd|\
+   rb-951ui-2hnd|\
+   rb-2011il|\
+   rb-2011l|\
+   rb-2011uas|\
+   rb-2011uas-2hnd|\
+   rb-2011uias|\
+   rb-2011uias-2hnd|\
+   rb-sxt2n|\
+   rb-sxt5n|\
+   wi2a-ac200i|\
+   wndr3700v4|\
+   wndr4300)
+   nand_do_upgrade "$1"
+   ;;
+   mr18|\
+   z1)
+   merakinand_do_upgrade "$1"
+   ;;
uap-pro|\
unifi-outdoor-plus)
MTD_CONFIG_ARGS="-s 0x18"
diff --git a/target/linux/imx6/base-files/lib/upgrade/platform.sh 
b/target/linux/imx6/base-files/lib/upgrade/platform.sh
index a9ca5ee..ab52291 100755
--- a/target/linux/imx6/base-files/lib/upgrade/platform.sh
+++ b/target/linux/imx6/base-files/lib/upgrade/platform.sh
@@ -16,7 +16,7 @@ platform_check_image() {
return 1

[LEDE-DEV] [PATCH] treewide: remove obsolete sysupgrade watchdog kill

[Mathias Kresin]

The watchdog kill command was meant for busybox watchdog. Busybox watchdog
was replaced by the procd watchdog mid 2013 with commit df7ce9301a25
("busybox: disable the watchdog utility by default"), which makes the kill
command obsolete since quite some time.

Signed-off-by: Mathias Kresin <d...@kresin.me>
---
 target/linux/adm5120/base-files/lib/upgrade/platform.sh  |  9 -
 target/linux/apm821xx/base-files/lib/upgrade/platform.sh | 10 --
 target/linux/ar71xx/base-files/lib/upgrade/platform.sh   | 10 --
 target/linux/au1000/base-files/lib/upgrade/platform.sh   | 10 --
 target/linux/cns3xxx/base-files/lib/upgrade/platform.sh  | 12 
 target/linux/ixp4xx/base-files/lib/upgrade/platform.sh   | 12 
 target/linux/lantiq/base-files/lib/upgrade/platform.sh   |  9 -
 target/linux/mpc85xx/base-files/lib/upgrade/platform.sh  | 10 --
 target/linux/mvebu/base-files/lib/upgrade/platform.sh| 10 --
 target/linux/oxnas/base-files/lib/upgrade/platform.sh| 10 --
 target/linux/ramips/base-files/lib/upgrade/platform.sh   |  9 -
 11 files changed, 111 deletions(-)

diff --git a/target/linux/adm5120/base-files/lib/upgrade/platform.sh 
b/target/linux/adm5120/base-files/lib/upgrade/platform.sh
index fab2b3d..b874a5e 100644
--- a/target/linux/adm5120/base-files/lib/upgrade/platform.sh
+++ b/target/linux/adm5120/base-files/lib/upgrade/platform.sh
@@ -33,12 +33,3 @@ platform_do_upgrade() {
PART_NAME="$sys_mtd_part"
default_do_upgrade "$ARGV"
 }
-
-disable_watchdog() {
-   killall watchdog
-   ( ps | grep -v 'grep' | grep '/dev/watchdog' ) && {
-   echo 'Could not disable watchdog'
-   return 1
-   }
-}
-append sysupgrade_pre_upgrade disable_watchdog
diff --git a/target/linux/apm821xx/base-files/lib/upgrade/platform.sh 
b/target/linux/apm821xx/base-files/lib/upgrade/platform.sh
index 5d2eee4..a45af7d 100755
--- a/target/linux/apm821xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/apm821xx/base-files/lib/upgrade/platform.sh
@@ -61,13 +61,3 @@ platform_copy_config() {
;;
esac
 }
-
-disable_watchdog() {
-   killall watchdog
-   ( ps | grep -v 'grep' | grep '/dev/watchdog' ) && {
-   echo 'Could not disable watchdog'
-   return 1
-   }
-}
-
-append sysupgrade_pre_upgrade disable_watchdog
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh 
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index ecf6820..35c6886 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -834,13 +834,3 @@ platform_do_upgrade() {
;;
esac
 }
-
-disable_watchdog() {
-   killall watchdog
-   ( ps | grep -v 'grep' | grep '/dev/watchdog' ) && {
-   echo 'Could not disable watchdog'
-   return 1
-   }
-}
-
-append sysupgrade_pre_upgrade disable_watchdog
diff --git a/target/linux/au1000/base-files/lib/upgrade/platform.sh 
b/target/linux/au1000/base-files/lib/upgrade/platform.sh
index 1a9d151..7beb4a0 100644
--- a/target/linux/au1000/base-files/lib/upgrade/platform.sh
+++ b/target/linux/au1000/base-files/lib/upgrade/platform.sh
@@ -24,13 +24,3 @@ platform_do_upgrade() {
get_image "$1" | tar -Oxvf - $KERNEL_IMG | mtd write - "kernel"
get_image "$1" | tar -Oxvf - $ROOTFS_IMG | mtd $conf write - "rootfs"
 }
-
-disable_watchdog() {
-killall watchdog
-( ps | grep -v 'grep' | grep '/dev/watchdog' ) && {
-echo 'Could not disable watchdog'
-return 1
-}
-}
-
-append sysupgrade_pre_upgrade disable_watchdog
diff --git a/target/linux/cns3xxx/base-files/lib/upgrade/platform.sh 
b/target/linux/cns3xxx/base-files/lib/upgrade/platform.sh
index 4efa47d..aa98b47 100644
--- a/target/linux/cns3xxx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/cns3xxx/base-files/lib/upgrade/platform.sh
@@ -17,15 +17,3 @@ platform_check_image() {
 platform_do_upgrade() {
default_do_upgrade "$ARGV"
 }
-
-disable_watchdog() {
-   v "killing watchdog"
-   killall watchdog
-   ( ps | grep -v 'grep' | grep '/dev/watchdog' ) && {
-   echo 'Could not disable watchdog'
-   return 1
-   }
-}
-
-# CONFIG_WATCHDOG_NOWAYOUT=y - can't kill watchdog unless kernel cmdline has a 
mpcore_wdt.nowayout=0
-#append sysupgrade_pre_upgrade disable_watchdog
diff --git a/target/linux/ixp4xx/base-files/lib/upgrade/platform.sh 
b/target/linux/ixp4xx/base-files/lib/upgrade/platform.sh
index e1e43cf..92eeaff 100644
--- a/target/linux/ixp4xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ixp4xx/base-files/lib/upgrade/platform.sh
@@ -135,15 +135,3 @@ platform_do_upgrade() {
;;

[LEDE-DEV] [PATCH 2/2] base-files: gpio switch: set output value with direction

[Mathias Kresin]

Use the "low" and "high" values to configure the GPIO as an output with
that initial value. It ensures that the gpio doesn't have a unwanted value
during the time the direction is set to ouput and the actual value is
applied.

We don't need to take care of the GPIO polarity for now, since our
exported GPIOs are always active low.

Cc: Lars Kruse <li...@sumpfralle.de>
Signed-off-by: Mathias Kresin <d...@kresin.me>
---
 package/base-files/Makefile | 2 +-
 package/base-files/files/etc/init.d/gpio_switch | 5 ++---
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/package/base-files/Makefile b/package/base-files/Makefile
index 728d787..d0c9d6b 100644
--- a/package/base-files/Makefile
+++ b/package/base-files/Makefile
@@ -12,7 +12,7 @@ include $(INCLUDE_DIR)/version.mk
 include $(INCLUDE_DIR)/feeds.mk
 
 PKG_NAME:=base-files
-PKG_RELEASE:=179
+PKG_RELEASE:=180
 PKG_FLAGS:=nonshared
 
 PKG_FILE_DEPENDS:=$(PLATFORM_DIR)/ $(GENERIC_PLATFORM_DIR)/base-files/
diff --git a/package/base-files/files/etc/init.d/gpio_switch 
b/package/base-files/files/etc/init.d/gpio_switch
index 5a62be9..b67950a 100755
--- a/package/base-files/files/etc/init.d/gpio_switch
+++ b/package/base-files/files/etc/init.d/gpio_switch
@@ -22,10 +22,9 @@ load_gpio_switch()
echo "$gpio_pin" >/sys/class/gpio/export
# we need to wait a bit until the GPIO appears
[ -d "$gpio_path" ] || sleep 1
-   echo out >"$gpio_path/direction"
}
-   # write 0 or 1 to the "value" field
-   { [ "$value" = "0" ] && echo "0" || echo "1"; } >"$gpio_path/value"
+   # set the pin to output with high or low pin value
+   { [ "$value" = "0" ] && echo "high" || echo "low"; } 
>"$gpio_path/direction"
 }
 
 service_triggers()
-- 
2.7.4


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

[LEDE-DEV] [PATCH 1/2] base-files: gpio_switch: start before boot state done is set

[Mathias Kresin]

Start gpio_switch before the boot state is set to up/initialised/done.
This way the exported GPIOs are available at the time rc.local is started.

Cc: Lars Kruse <li...@sumpfralle.de>
Signed-off-by: Mathias Kresin <d...@kresin.me>
---
 package/base-files/files/etc/init.d/gpio_switch | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/base-files/files/etc/init.d/gpio_switch 
b/package/base-files/files/etc/init.d/gpio_switch
index 1f1b44b..5a62be9 100755
--- a/package/base-files/files/etc/init.d/gpio_switch
+++ b/package/base-files/files/etc/init.d/gpio_switch
@@ -1,7 +1,7 @@
 #!/bin/sh /etc/rc.common
 # Copyright (C) 2015 OpenWrt.org
 
-START=98
+START=94
 STOP=10
 USE_PROCD=1
 
-- 
2.7.4


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

Re: [LEDE-DEV] [PATCH 1/3] busybox: enable flock by default

[Mathias Kresin]

18.12.2017 10:48, Roman Yeryomin:

On 2017-12-18 09:58, Mathias Kresin wrote:

17.12.2017 19:30, Roman Yeryomin:

This is needed for procd init script protection to work.
flock adds 4248 bytes to stripped busybox binary.

Signed-off-by: Roman Yeryomin <ro...@advem.lv>
---
  package/utils/busybox/Config-defaults.in | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/utils/busybox/Config-defaults.in
b/package/utils/busybox/Config-defaults.in
index 2a8d9dd397..6fc5093055 100644
--- a/package/utils/busybox/Config-defaults.in
+++ b/package/utils/busybox/Config-defaults.in
@@ -1497,7 +1497,7 @@ config BUSYBOX_DEFAULT_FINDFS
  default n
  config BUSYBOX_DEFAULT_FLOCK
  bool
-default n
+default y
  config BUSYBOX_DEFAULT_FDFLUSH
  bool
  default n



We have a custom (f)lock command in LEDE [0], which is used for
example during wireless detect.

I only had a brief lock at your patch series, but the existing lock
command might do the job.

I've no idea why we have a custom lock command instead of using the
busybox provided flock. But shipping two (f)lock implementations at
the same time seem to be a waste of flash space.

Mathias

[0]
https://git.lede-project.org/?p=source.git;a=blob;f=package/utils/busybox/patches/220-add_lock_util.patch;hb=60a39e8f5af7ed710c5c62b131fd9df6519b64e4




I think we should use stock flock instead of patching and adding another
custom wheel.
If something doesn't work in stock flock we should fix that and send the
fix upstream.


I had a closer look at the commit history to understand why we have a
custom (f)lock implementation. It is as simple as our custom lock dates
around 2006, while the busybox flock applet was added 2010.

At least I'm fine to switch to the upstream flock. As implied by using
the word "switch", our custom lock applet should be removed at the same
time.


Adding flock and procd_lock is intended to replace all init custom locks
and others.
(and fix the racing problem once and for all)


Locks aren't used only for init scripts. Within the packages directory 
the lock applet is used in:


package/network/config/ltq-vdsl-app/files/dsl_cpe_pipe.sh
package/base-files/files/lib/preinit/30_failsafe_wait
package/base-files/files/lib/preinit/40_run_failsafe_hook
package/base-files/files/sbin/sysupgrade

Most likely there are more scripts using lock.

Mathias



smime.p7s
Description: S/MIME Cryptographic Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 1/3] busybox: enable flock by default

[Mathias Kresin]

17.12.2017 19:30, Roman Yeryomin:

This is needed for procd init script protection to work.
flock adds 4248 bytes to stripped busybox binary.

Signed-off-by: Roman Yeryomin 
---
  package/utils/busybox/Config-defaults.in | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/utils/busybox/Config-defaults.in 
b/package/utils/busybox/Config-defaults.in
index 2a8d9dd397..6fc5093055 100644
--- a/package/utils/busybox/Config-defaults.in
+++ b/package/utils/busybox/Config-defaults.in
@@ -1497,7 +1497,7 @@ config BUSYBOX_DEFAULT_FINDFS
default n
  config BUSYBOX_DEFAULT_FLOCK
bool
-   default n
+   default y
  config BUSYBOX_DEFAULT_FDFLUSH
bool
default n



We have a custom (f)lock command in LEDE [0], which is used for example 
during wireless detect.


I only had a brief lock at your patch series, but the existing lock 
command might do the job.


I've no idea why we have a custom lock command instead of using the 
busybox provided flock. But shipping two (f)lock implementations at the 
same time seem to be a waste of flash space.


Mathias

[0] 
https://git.lede-project.org/?p=source.git;a=blob;f=package/utils/busybox/patches/220-add_lock_util.patch;hb=60a39e8f5af7ed710c5c62b131fd9df6519b64e4


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

Re: [LEDE-DEV] firewall question

[Mathias Kresin]

15.12.2017 09:24, e9hack:

Hi,

I did set-up a openvpn server on my router. /etc/config/network contains the 
interface definition:

config interface 'vpn'
option proto 'none'
option ifname 'tun1'

In /etc/config/firewall, I've the following definitions related to vpn, lan and 
wan:

config zone
option name 'lan'
list network 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'

config zone
option name 'wan'
list network 'wan'
list network 'wan_6'
option input 'DROP'
option output 'ACCEPT'
option forward 'DROP'
option masq '1'
option mtu_fix '1'
option conntrack '1'

config zone
option name 'vpn'
option network 'vpn'
option input 'ACCEPT'
option forward 'REJECT'
option output 'ACCEPT'


You vpn zone configuration has to be read as:

  - allow traffic from vpn zone to firewall (INPUT)
  - allow traffic from firewall to vpn zone (OUTPUT)



config forwarding
option src 'lan'
option dest 'wan'

config rule
option name 'Allow OpenVPN Inbound on wan'
option src 'wan'
option proto 'tcpudp'
option dest_port '1194'
option extra '-m conntrack --ctstate NEW'
option target 'ACCEPT'

config forwarding
option src 'vpn'
option dest 'wan'

config rule
option name 'Block NetBios from vpn to wan'
option src 'vpn'
option dest 'wan'
list dest_port '135'
list dest_port '137-139'
list dest_port '445'
list dest_port '3389'
option proto 'tcpudp'
option target 'DROP'

This are not the complete firewall definitions, but it doesn't exist any other 
rule with the zone or network vpn.

I did not define any forwarding rule between vpn and lan. The lan ip range is 
192.168.x.x. and a client, which is
connected to the openvpn server, gets an ip address from the range 10.8.y.y. 
From an openvpn client, I can access the
web interface of the router via 192.168.x.1. Why is this possible?


It is possible because your traffic targets the firewall (INPUT) and not 
the lan zone (FORWARD). The destination ip address doesn't really mater 
as long as it is an interface of the fireall. Consider the firewall as 
something like a special zone.


Following an excerpt of the firewall configuration I'm using to restrict 
IoT devices. My complete configuration is more complex, since ipset is 
involved to limit forwarding of IoT traffic to WAN based on the 
destination fqdn/domain. But it should give you are start.


config zone
option name iot
list   network  'iot'
option inputREJECT
option output   ACCEPT
option forward  REJECT

config forwarding
option src  lan
option dest iot

config rule
option name Allow-iot-DHCPv4-Input
option src  iot
option protoudp
option dest_port67
option target   ACCEPT
option family   ipv4

config rule
option name Allow-iot-DHCPv6-Input
option src  iot
option protoudp
option dest_port547
option target   ACCEPT
option family   ipv6

config rule
option name Allow-iot-DNS-Input
option src  iot
option dest_port53
option proto'udp tcp'
option target   ACCEPT

Mathias

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

Re: [LEDE-DEV] fixing of image file names

[Mathias Kresin]

12.12.2017 23:01, Jonas Gorski:
> On 12 December 2017 at 21:03, Jo-Philipp Wich  wrote:
>> Hi Piotr,
>>
>> my rough idea was to somehow tie the manifest generation to the "define
>> Device/*" macros present in the image building code because there you
>> have all required information in a central place:
>>
>>   - unique board identifier
>>   - image name / build steps
>>   - default package selection
>
> I also think this is the easiest to achieve way for creating a way to
> lookup board_name => image_name.

I guess we are mixing different topics here. My primary intention is to 
have unique boardnames across all targets and mainly prevent collisions 
within targets.


Using a dts compat string based manufacture and product name in the 
image filename is only meant for humans to easier find what they are 
looking for.


It might allow to do a prediction on the image filename based on the 
userspace boardname. But it is rather a side effect than something they 
I'm really targeting. Nice if it works, but fine if not. Which doesn't 
mean we should "break" it wilfully.


To do a reliable mapping, we indeed need a mapping file with userspace 
boardname and image filename(s). But creating such a global mapping file 
doesn't make much sense to me as long as the userspace boardnames are 
not unique.


> We already define BOARD_NAME or SUPPORTED_DEVICES for many devices, we
> just need to set these consistently for all targets. Then we can
> easily create a manifest based on that.
>
> That way we also have no restrictions on how we name the images; what
> is part of the images etc.
>
>
> Regards
> Jonas
>
> P.S: We should also deprecate one of these for the other, we don't
> need two different variables for the same purpose.

NAK. They serve a different purpose and aren't necessarily set to the 
same value.


The value of the BOARD_NAME variable for example is preferred over the 
DEVICE_NAME for the subdirectory created within sysupgrade.tar archives.


If you change the DEVICE_NAME variable for boards with a sysupgrade.tar 
image file format, you need to add the BOARD_NAME variable with the 
former used name to not break sysupgrade from stable versions. I only 
changed the dependency on a correct named subdirectory recently.


Since by default the image filename is created based on the DEVICE_NAME 
contents, you need to touch this variable to have a more descriptive 
image filename.


SUPPORTED_DEVICES on the other hand is only used for the image metadata 
and should contain the current boardname as well as the boardname used 
in 17.01 if it was a different one.


So far it seems really trick to me to find the unique value that is 
required. SUPPORTED_DEVICES might contain a (global) duplicate boardname 
due backward compatibility. BOARD_NAME is definitely the wrong variable 
to look at.


Mathias

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

Re: [LEDE-DEV] fixing of image file names

[Mathias Kresin]

12.12.2017 21:02, Piotr Dymacz:

On 01.12.2017 16:12, Mathias Kresin wrote:

I really doubt that upstream is going to accept vendor prefixes if
they aren't used anywhere. I would prefer to use what already exists,
add our own prefixes where required and upstream them at the time the
dts is send upstream.


I don't know but have a look at "opalkelly" [1] (recent example).


Thanks for the pointer. I have to admit I'm surprised to see this commit.

I've not yet decided how to deal with upstreaming vendor prefixes used 
in our devicetree source files. But most likely I will postpone it to a 
later point.



So far I have only seen a handful of distortions in compat strings,
like underlines. Never noticed any (special) charter beside [a-z],
[0-9] and [-_].


I was able to find also examples of: '+' in [2], '.' in [3] and '/' in 
[4]. What's more, we have '+', '@' and '/' in our tree: [5], [6], [7].


At least the distortions in our tree can be fixed. For everything else 
we need to accept that a compat string to image name mapping doesn't 
work that easy or isn't possible at all. Depends on how far someone is 
willing to go with replacing special chars.



For now I tend to leave it as it is. Of course, it doesn't improve the
situation for the mentioned boards, but it doesn't make it worse
either. Otherwise I would be busy with fixing all the corner cases
instead of improving the situation for the (majority) of the boards
where it is already easily possible. Yeah, call me lazy ;-).


You are the last person I would call lazy ;)
Thanks for your hard work on this!


Looks like it's safe to commit the first batch of related commits from 
my staging tree.


Mathias

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

Re: [LEDE-DEV] fixing of image file names

[Mathias Kresin]

Hey Daniel,

sorry for the late reply, I totally missed your mail and only spotted it 
due to the recent replies.


01.12.2017 22:20, Daniel Golle:

On Wed, Nov 29, 2017 at 09:33:39AM +0100, Mathias Kresin wrote:

28.11.2017 19:24, Daniel Golle:

Hi Moritz,

thanks for stepping forward and adressing this issue.
It'd be good to include the two assertions added to your list beelow.

On Tue, Nov 28, 2017 at 07:05:23PM +0100, Moritz Warning wrote:

Hi,

I noticed that there are some image file names that do not follow the "common" 
name scheme.
Is it ok to change it? I would like to submit a patch.

Some examples:
- all lower case image names
- lede-ipq806x-EA8500-squashfs-sysupgrade.tar => 
lede-ipq806x-ea8500-squashfs-sysupgrade.tar
- revision between -
- lede-mvebu-linksys-wrt1900acv2-squashfs-sysupgrade.bin => 
lede-mvebu-linksys-wrt1900ac-v2-squashfs-sysupgrade.bin
- region specific images with region identifiers (us, eu, il, ...)
   - lede-ramips-rt305x-wnce2001-squashfs-factory-northamerica.bin => 
lede-ramips-rt305x-wnce2001-us-squashfs-factory.bin
- separate images for each version
- lede-brcm47xx-mips74k-linksys-e1000-v1-v2-v2.1-squashfs.bin => 
lede-brcm47xx-mips74k-linksys-e1000-v1-squashfs.bin, ...


   - board_name (in target userspace) == profile (in imagebuilder) == DTS name

   - image_filename == 
${distro}-${target}-${subtarget}-${board_name}-${fstype}-${imgtype}

that would make identifying sysupgrade images much more straight
forward (and hence automatizable).

See also
https://github.com/aparcar/attendedsysupgrade-server/issues/80


I would like to propose something different which basically aims the same.

1. fix the compatible strings in the DTS files
2. use the compatible string from the DTS in userspace (boardname)
3. use the compatible string for the image filename (board_name in above
example)


There was only board_name (with underscore), no boardname (without
underscore) in the example... (?)


boardname as well as board_name are referring in my above list to 
/tmp/sysinfo/board_name. Typo + missing path isn't a good combination. 
Sorry for the confusion.




The DTS compatible string is supposed to be unique across the whole kernel
and this way we can prevent duplicates in big targets like ramips.

The compatible string includes the vendor, which will make it way easier to
find a particular image in directories with a lot of images. In theory, it
should be even possible to provide all images in a single directory without
target/subtarget prefix.

Since the underscore isn't a valid character in compatible strings, we can
use it in the image filename as replacement for the comma to split vendor
from boardname.

Due to the sync of runtime boardname and the boardname used in the image
filename, it should be possible to guess the used image filename more
reliably as requested.


I used '-' to replace the ',' chars in
https://git.lede-project.org/?p=project/procd.git;a=commitdiff;h=453116e08e6a9349374bbff427b75f57ce5387c9


Oh, I wasn't aware of this code and I'm curious under which conditions 
the else if branch is required.


A generic preinit script which populates
/tmp/sysinfo/board_name with the values from the devicetree compat 
string - if the file wasn't created before - is around since April 2015 [0].


To my understanding, if a devicetree compat string exists, 
/tmp/sysinfo/board_name should exists as well.


The only difference is that the shell code doesn't alter the compat 
string as I neither intend to do.




However, it was based on a mere feeling... I wouldn't mind changing it
to '_' instead.


The comma should be only replaced for the image filename. The reason is 
as simple as make doesn't like "Device/manufacture,productname" due to 
the comma. We're using the Device define for the image filename by default.


Mathias

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

Re: [LEDE-DEV] odhcpd vs odhcpd-ipv6only

[Mathias Kresin]

2017-12-12 11:15 GMT+01:00 Mauro Mozzarelli :
> Hello,
>
> I understand that odhcpd-ipv6only has now become the default and it
> conflicts with odhcpd.
>
> Please could you let me know if odhcpd-ipv6only supports the existing
> configuration file /etc/config/dhcp?

Yes, the default config works as before.

> And what if I have an ipv4 only LAN?

Nothing will change. dnsmasq is and was the default DHCPv4 server in LEDE.

> What was the rationale for the switch?

To not ship two DHCPv4 servers by default and save some bytes.

> And finally in case of changes that impact the default configuration, could
> you make visible, prominent announcements in advance documenting also the
> migration steps?

If you are using a development snapshot, you should expect that stuff
breaks/changes from time to time. If there are any groundbreaking
changes, they will be most likely mentioned in the release notes of a
_stable_ release.

Mathias

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

Re: [LEDE-DEV] [PATCH] brcm47xx: proper region code in image name

[Mathias Kresin]

11.12.2017 20:37, txt.file:

Didn't you want to use 'us' as image identifier? In your patch it is
still north america just shortened to 2 letters.

kind regards
txt.file


Please don't top-post.

The way it was done is correct. North america != us. I fixed the commit 
message before I merged the patch.


Mathias



Moritz Warning:

Replace 'north-america' by 'us' and remove 'other-regions' in image files for 
Netgear WGR614 v10.

Signed-off-by: Moritz Warning 
---
  target/linux/brcm47xx/image/Makefile | 18 +-
  1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/target/linux/brcm47xx/image/Makefile 
b/target/linux/brcm47xx/image/Makefile
index 8c681ac345..ccd6f4dc44 100644
--- a/target/linux/brcm47xx/image/Makefile
+++ b/target/linux/brcm47xx/image/Makefile
@@ -806,21 +806,21 @@ define Device/linksys-e4200-v1
  endef
  TARGET_DEVICES += linksys-e4200-v1
  
-define Device/netgear-wgr614-v10_north-america

+define Device/netgear-wgr614-v10-na
DEVICE_TITLE := Netgear WGR614 v10 North America
$(Device/netgear)
NETGEAR_BOARD_ID := U12H139T01_NETGEAR
NETGEAR_REGION := 2
  endef
-TARGET_DEVICES += netgear-wgr614-v10_north-america
+TARGET_DEVICES += netgear-wgr614-v10-na
  
-define Device/netgear-wgr614-v10_other-regions

-  DEVICE_TITLE := Netgear WGR614 v10 Other Regions
+define Device/netgear-wgr614-v10
+  DEVICE_TITLE := Netgear WGR614 v10
$(Device/netgear)
NETGEAR_BOARD_ID := U12H139T01_NETGEAR
NETGEAR_REGION := 1
  endef
-TARGET_DEVICES += netgear-wgr614-v10_other-regions
+TARGET_DEVICES += netgear-wgr614-v10
  
  define Device/netgear-wn2500rp-v1

DEVICE_TITLE := Netgear WN2500RP v1
@@ -910,23 +910,23 @@ define Device/netgear-wnr2000v2
  endef
  TARGET_DEVICES += netgear-wnr2000v2
  
-define Device/netgear-wnr3500l-v1-north-america

+define Device/netgear-wnr3500l-v1-na
DEVICE_TITLE := Netgear WNR3500L v1 North America
DEVICE_PACKAGES := kmod-b43 $(USB2_PACKAGES)
$(Device/netgear)
NETGEAR_BOARD_ID := U12H136T99_NETGEAR
NETGEAR_REGION := 2
  endef
-TARGET_DEVICES += netgear-wnr3500l-v1-north-america
+TARGET_DEVICES += netgear-wnr3500l-v1-na
  
-define Device/netgear-wnr3500l-v1-other-regions

+define Device/netgear-wnr3500l-v1
DEVICE_TITLE := Netgear WNR3500L v1 Other Regions
DEVICE_PACKAGES := kmod-b43 $(USB2_PACKAGES)
$(Device/netgear)
NETGEAR_BOARD_ID := U12H136T99_NETGEAR
NETGEAR_REGION := 1
  endef
-TARGET_DEVICES += netgear-wnr3500l-v1-other-regions
+TARGET_DEVICES += netgear-wnr3500l-v1
  
  define Device/netgear-wnr3500l-v2

DEVICE_TITLE := Netgear WNR3500L v2





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




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

Re: [LEDE-DEV] [PATCH] netifd: always send DHCPv4 hostname

[Mathias Kresin]

08.12.2017 21:14, Daniel Golle:

Hi Mathias,

On Fri, Dec 08, 2017 at 09:35:26AM +0100, Mathias Kresin wrote:

udhcpc doesn't send a hostname by default. Use the system hostname if
nothing else is specified, to always send a hostname.

It syncs the behaviour to odhcpc, which always sends a hostname.


Could we somehow allow to deliberately not send any hostname?


At least in context of this patch it's to late. I pushed the patch 
minutes prior your mail.



ISC dhcpcd allows setting it to 'null' or 'localhost' for that
purpose.
There are two possible uses for not sending the hostname in the DHCP
request:
  i) expecting the hostname to be assigned by the DHCP server


Shouldn't work it anyway by using the request hostname option?


ii) minimizing the amount of identifyable bits being sent, e.g.
 when connecting to public networks


Exactly that was the reason why I send the patch to the mailing list 
first. I wasn't sure if the absence of a default send hostname is 
considered as feature or a bug. After receiving the ACKs it was pretty 
much clear to me that it's considered as bug by others as well.


Nevertheless I thought about this use case as well, but couldn't find a 
satisfying solution using the existing hostname uci option. I consider 
the strings 'null' and 'localhost' as valid hostnames.


To my knowledge it isn't possible to pass NULL via uci and therefore 
it's impossible to distinguish whether the hostname was intentional set 
to nothing or it's expected that the systems hostname is send by default 
(as it's done by all dhcp clients I have seen so far).


I was surprised to see that there was a mismatch in what is done for 
DHCPv4 (udhcpc) and DHCPv6 (odhcpc). I prefer to have the possible to 
create a DNS record - based on the send hostname - for dhcp clients by 
default and considered this issue as more pressing. But as usual, it 
depends on the use case.


Mathias

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

[LEDE-DEV] [PATCH] netifd: always send DHCPv4 hostname

[Mathias Kresin]

udhcpc doesn't send a hostname by default. Use the system hostname if
nothing else is specified, to always send a hostname.

It syncs the behaviour to odhcpc, which always sends a hostname.

Signed-off-by: Mathias Kresin <d...@kresin.me>
---
 package/network/config/netifd/files/lib/netifd/proto/dhcp.sh | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/network/config/netifd/files/lib/netifd/proto/dhcp.sh 
b/package/network/config/netifd/files/lib/netifd/proto/dhcp.sh
index ea02d68..143e445 100755
--- a/package/network/config/netifd/files/lib/netifd/proto/dhcp.sh
+++ b/package/network/config/netifd/files/lib/netifd/proto/dhcp.sh
@@ -40,6 +40,7 @@ proto_dhcp_setup() {
append dhcpopts "-x $opt"
done
 
+   [ -z "$hostname" ] && hostname="$(cat /proc/sys/kernel/hostname)"
[ "$broadcast" = 1 ] && broadcast="-B" || broadcast=
[ "$release" = 1 ] && release="-R" || release=
[ -n "$clientid" ] && clientid="-x 0x3d:${clientid//:/}" || 
clientid="-C"
-- 
2.7.4


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

Re: [LEDE-DEV] fixing of image file names

[Mathias Kresin]

30.11.2017 04:20, Luis Araneda:

That seems like the correct way to go, but is a lot of work as you mentioned.
I can start with the ipq806x and sunxi targets, since they are the
ones I am most familiar with.

@Mathias: Should I send you the patches to be applied to your staging
tree, or to the mailing list?



Please base your patches on master and send the patches to the mailing 
list/github. It will allow me to do a public review and other people - 
who might send a similar patch - can learn from possible mistakes done 
by you.


Please send two patches. One for switching the target/board to 
devicetree based board names and if interested another one on top for 
the new image filename.


Keep in mind, that [0] needs to be applied to master first, to use a 
different boardname for boards with NAND flash/ubi images.


Please hold on with sending the patches for the moment. I would like to 
wait a few more days to give everyone a chance to comment on my 
proposal. Same for my approach in [0]. Might be that I missed something.


Usually I wait for feedback two weeks. If I don't received any feedback 
within the time frame, I consider it as silent ACK/don't care.


Mathias

[0] http://patchwork.ozlabs.org/patch/842685/

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

Re: [LEDE-DEV] [PATCH] ar71xx: add support for TP-Link TL-WDR7500v6

[Mathias Kresin]

30.11.2017 22:06, Bill Moffitt:

On 11/29/2017 12:03 PM, Piotr Dymacz wrote:

On 29.11.2017 20:17, Bill Moffitt wrote:
Swapping bootloader isn't the only issue I see here. Moving ART which 
is essential and unique per device might end up in a data loss which 
cannot be recovered in any way.

Yes, that's true. But the only other option is not use the hardware.


Not using the hardware is a valid option and so far no veto from any 
other dev.


But I'd still rather endorse a notation in the ToH and the wiki than 
just prevent the patch from being accepted.


Forget about it! People don't read. Instead we will be flooded on all 
public and private (!) channels with request for help similar to:


 - how to install LEDE on the board
 - where to get the custom bootloader
 - i bricked my board help! help!

It is good and necessary to look out for the naive beginner (as we all 
were at one time). But, at the same time, there is value in supporting 
the wisened and experienced user who can go to some extra effort and 
undertake some risk for a particular purpose.


Well, your patch can be now found by $searchengine and anyone how is 
brave enough, can add support for this board to a local clone.


I'm perfect fine with the decision made by Piotr. If it is to hard to 
get LEDE installed on a board/to error prone, we do not necessarily need 
to add support for this board to a target with > 100 already supported 
boards of all kinds.


Mathias

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

[LEDE-DEV] [PATCH] procd: nand: dont rely on boardname in nand_upgrade_tar

[Mathias Kresin]

Kernel and rootfs in a subdirectory matching the userspace boardname
was intended to use a single sysupgrade-tar archive for multiple boards
with different kernel/rootfs images. This feature was never used.

Use the first found directory in the tar archive instead of relying on
a directory named according to the userspace boardname.

It allows to change the boardname without adding another compatibility
layer - using the nand_board_name() function - for (sub)targets using
the metadata based image validation in favour to
nand_do_platform_check().

Signed-off-by: Mathias Kresin <d...@kresin.me>
---
 package/base-files/files/lib/upgrade/nand.sh | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/package/base-files/files/lib/upgrade/nand.sh 
b/package/base-files/files/lib/upgrade/nand.sh
index 563db4c..1c6b86b 100644
--- a/package/base-files/files/lib/upgrade/nand.sh
+++ b/package/base-files/files/lib/upgrade/nand.sh
@@ -250,19 +250,21 @@ nand_board_name() {
 
 nand_upgrade_tar() {
local tar_file="$1"
-   local board_name="$(nand_board_name)"
local kernel_mtd="$(find_mtd_index $CI_KERNPART)"
 
-   local kernel_length=`(tar xf $tar_file sysupgrade-$board_name/kernel -O 
| wc -c) 2> /dev/null`
-   local rootfs_length=`(tar xf $tar_file sysupgrade-$board_name/root -O | 
wc -c) 2> /dev/null`
+   local board_dir=$(tar tf $tar_file | grep -m 1 '^sysupgrade-.*/$')
+   board_dir=${board_dir%/}
 
-   local rootfs_type="$(identify_tar "$tar_file" 
sysupgrade-$board_name/root)"
+   local kernel_length=`(tar xf $tar_file ${board_dir}/kernel -O | wc -c) 
2> /dev/null`
+   local rootfs_length=`(tar xf $tar_file ${board_dir}/root -O | wc -c) 2> 
/dev/null`
+
+   local rootfs_type="$(identify_tar "$tar_file" ${board_dir}/root)"
 
local has_kernel=1
local has_env=0
 
[ "$kernel_length" != 0 -a -n "$kernel_mtd" ] && {
-   tar xf $tar_file sysupgrade-$board_name/kernel -O | mtd write - 
$CI_KERNPART
+   tar xf $tar_file ${board_dir}/kernel -O | mtd write - 
$CI_KERNPART
}
[ "$kernel_length" = 0 -o ! -z "$kernel_mtd" ] && has_kernel=0
 
@@ -271,12 +273,12 @@ nand_upgrade_tar() {
local ubidev="$( nand_find_ubi "$CI_UBIPART" )"
[ "$has_kernel" = "1" ] && {
local kern_ubivol="$(nand_find_volume $ubidev $CI_KERNPART)"
-   tar xf $tar_file sysupgrade-$board_name/kernel -O | \
+   tar xf $tar_file ${board_dir}/kernel -O | \
ubiupdatevol /dev/$kern_ubivol -s $kernel_length -
}
 
local root_ubivol="$(nand_find_volume $ubidev rootfs)"
-   tar xf $tar_file sysupgrade-$board_name/root -O | \
+   tar xf $tar_file ${board_dir}/root -O | \
ubiupdatevol /dev/$root_ubivol -s $rootfs_length -
 
nand_do_upgrade_success
-- 
2.7.4


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

Re: [LEDE-DEV] fixing of image file names

[Mathias Kresin]

28.11.2017 19:24, Daniel Golle:

Hi Moritz,

thanks for stepping forward and adressing this issue.
It'd be good to include the two assertions added to your list beelow.

On Tue, Nov 28, 2017 at 07:05:23PM +0100, Moritz Warning wrote:

Hi,

I noticed that there are some image file names that do not follow the "common" 
name scheme.
Is it ok to change it? I would like to submit a patch.

Some examples:
- all lower case image names
   - lede-ipq806x-EA8500-squashfs-sysupgrade.tar => 
lede-ipq806x-ea8500-squashfs-sysupgrade.tar
- revision between -
   - lede-mvebu-linksys-wrt1900acv2-squashfs-sysupgrade.bin => 
lede-mvebu-linksys-wrt1900ac-v2-squashfs-sysupgrade.bin
- region specific images with region identifiers (us, eu, il, ...)
  - lede-ramips-rt305x-wnce2001-squashfs-factory-northamerica.bin => 
lede-ramips-rt305x-wnce2001-us-squashfs-factory.bin
- separate images for each version
   - lede-brcm47xx-mips74k-linksys-e1000-v1-v2-v2.1-squashfs.bin => 
lede-brcm47xx-mips74k-linksys-e1000-v1-squashfs.bin, ...


  - board_name (in target userspace) == profile (in imagebuilder) == DTS name

  - image_filename == 
${distro}-${target}-${subtarget}-${board_name}-${fstype}-${imgtype}

that would make identifying sysupgrade images much more straight
forward (and hence automatizable).

See also
https://github.com/aparcar/attendedsysupgrade-server/issues/80


I would like to propose something different which basically aims the same.

1. fix the compatible strings in the DTS files
2. use the compatible string from the DTS in userspace (boardname)
3. use the compatible string for the image filename (board_name in above 
example)


The DTS compatible string is supposed to be unique across the whole 
kernel and this way we can prevent duplicates in big targets like ramips.


The compatible string includes the vendor, which will make it way easier 
to find a particular image in directories with a lot of images. In 
theory, it should be even possible to provide all images in a single 
directory without target/subtarget prefix.


Since the underscore isn't a valid character in compatible strings, we 
can use it in the image filename as replacement for the comma to split 
vendor from boardname.


Due to the sync of runtime boardname and the boardname used in the image 
filename, it should be possible to guess the used image filename more 
reliably as requested.


I'm working on to do so since a while, with the following status:

1. is already done for the ramips target, more fixes are in the 
boarddetection branch of my staging tree


2. done for some targets in the boarddetection branch of my staging 
tree; done for a handful of ramips boards in the ramips branch of my 
staging tree


3. done for a handful of ramips boards in the ramips branch of my 
staging tree


Using the TP-Link TL-WR840N v5 as an example, the userspace boardname 
would be "tplink,tl-wr840n-v5" and the image filename would change from


  lede-ramips-mt76x8-tl-wr840n-v4-squashfs-sysupgrade.bin

to

  lede-ramips-mt76x8-tplink_tl-wr840n-v4-squashfs-sysupgrade.bin

Target and subtarget can be found in /etc/os_release of the running system.

I started working on the compat string in userspace thingy to get rid of 
another layer of glue code 
(target/linux/ramips/base-files/lib/ramips.sh), to unify the creation of 
the userspace boardname across all targets.


Initially it was meant to make the review of board support patches 
easier for me. But I noticed that it has more benefits than that as we 
can see with this mail thread.


But fixing the compat strings and migrating the userspace boardname to a 
DTS compat string based one is a hugh task and time consuming.


The first commits in my staging tree regarding the topic are from April 
this year and I'm still not finished. As all of us, I'm time constrained 
as well.


Any feedback on this approach (and help in migrating exists boards of 
course) is highly welcome.


Mathias

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

Re: [LEDE-DEV] [PATCH] ramips: Add support for the Unielec U7621-6

[Mathias Kresin]

05.11.2017 22:24, Piotr Dymacz:

Hello Kristian,

On 04.11.2017 21:53, Kristian Evensen wrote:

The Unielec U7621-6
(http://www.unielecinc.com/q/news/cn/p/product/detail.html?qd_guid=pyrEjfTmYf) 


is an MT7621-based router with the following specifications:


I got the same board last week and had some initial support ready 
locally. I pushed it now to my staging tree, please have a look:


https://git.lede-project.org/?p=lede/pepe2k/staging.git;a=shortlog;h=refs/heads/ramips_unielec-u7621-06 



Maybe we can combine our patches and work out a common version.
Please, find also my comments below.

--
Cheers,
Piotr

[snip]


Notes:
* According to the specifications on the Unielec website, two LEDs
should be controllable via GPIO. I was not able to find the pins.


GPIOs 10, 11 and 12 control LEDs 3, 4 and 5 in top row. At least on my 
board, some of these LEDs were rotated (wrong polarization).



* The device can be delivered with different amounts of RAM and
storage. I have only added support for devices with 256MB RAM and 16MB
storage, as that is the configuration of my device. However, I have
added all the required infrastructure for making adding support for the
other configurations easy.


AFAIK, board with 256/16 MB is the default one (mass production?). Any 
change means MOQ and customized version. The default one can be easily 
purchased from Ali..., directly from the vendor.


It is the same as with some of the ZBT boards. They're advertised with 
different RAM sizes, but so far all known boards have the same amount of 
ram.


Not sure about the flash size. Especially for the ZBT boards it is known 
that they are shipped with different sized flash chips.


But since you pepe have a way better insight what the OEMs/ODMs tend to 
do, it would be the best to follow your advice.




* I have assumed that the placement of wifi cards will be as on the 
image on

the Unielec website linked to above.


I have problem with this and I don't know how we should proceed here 
(Mathias, what do you think?).


Actually, the board by default comes without any Wi-Fi card installed 
and they need to be ordered separately (if someone needs them at all).


Oh, I missed that detail.



Personally, I don't think we should force any type of card and/or order 
in slots. The board comes with two miniPCIe slots which can be used for 
almost anything. I've been testing it with ath9k and mt7603 based cards, 
a different configuration than yours :)


I totally agree. If the board isn't ship with a particular set of 
wireless cards, we shouldn't enforce anything.





* The factory firmware reads the MAC address from offset e000 on the
factory partition. On my device, this offset contains 0xffs, but I have
chosen to keep the offset in the dts to ensure we are consistent with
the factory firmware.


AFAIK, the firmware vendor provides board with doesn't come from them. 
They installed some version dedicated for PandoraBox PBR-M1.


There is also some dedicated Padavan version but I have no idea where it 
can be downloaded from.




Installation:

See Recovery below. The router comes pre-installed with OpenWRT (Pandora
Box), but sysupgrade fails due to board name mismatch.


sysupgrade -F ...



Recovery:
The U7621-6 supports web recovery. If you keep the reset-button pressed
for ~5 seconds during boot, a webserver is started.Your machine will be
assigned an IP through DHCP, and the router has address 192.168.1.1. The
recovery website is in Chinese, but is easy to use. Click on the second
item in the list to access the recovery page, then the second item on
the next page is where you select the firmware. In order to start the
recovery, you click the button at the bottom.


At least on my board, button just stops autobooting process. Web server 
seems to be enabled in the bootloader all the time - with a static IP on 
my PC I can access it even during autobooting countdown.


Pepe, are you fine if I handle this patch over to you? Doesn't make much 
sense to me if I do the review, while you are having the hardware.


Mathias

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

Re: [LEDE-DEV] [PATCH] ramips: Add support for the Unielec U7621-6

[Mathias Kresin]

05.11.2017 13:56, Kristian Evensen:

Hi again,

On Sun, Nov 5, 2017 at 12:14 PM, Mathias Kresin <d...@kresin.me> wrote:

diff --git a/target/linux/ramips/image/mt7621.mk
b/target/linux/ramips/image/mt7621.mk
index 8bd7e0318f..1bdd0024e4 100644
--- a/target/linux/ramips/image/mt7621.mk
+++ b/target/linux/ramips/image/mt7621.mk
@@ -225,6 +225,15 @@ define Device/timecloud
   endef
   TARGET_DEVICES += timecloud
   +define Device/u7621-6-256M-16M
+  DTS := U7621-6-256M-16M
+  IMAGE_SIZE := 16777216



Looks wrong to me. The firmware partition has a size of 0xfb, which is
16449536 bytes or 16064k to be better readable.


I think maybe I was a bit quick in my previous email. Are you sure
about this comment? I am happy to change the size, but the firmware
partition starts at 0x5 and 0x5 + 0xfb == 16777216. So
that is why I sat the image size to the current value.

-Kristian



Yes I am. The firmware partition has a size of 0xfb (0x5 is the 
offset of the partition relative to the start of the flash), hence the 
image written to the firmware partition can't be bigger than that.


16777216 bytes would cover the whole flash chip but you do not intend to 
write to the u-boot, u-boot-env and factory partitions.


Mathias

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

Re: [LEDE-DEV] [LUCI] [PATCH 0/2] wifi: 80211r psk_generate_local and ft_ver_ds

[Mathias Kresin]

02.11.2017 21:24, Lorenzo Santina:

When using a PSK, with ft_psk_generate_local the PMK is
generate locally simplifing the configuration of 80211r.

With ft_over_ds support the user can now choose if use
FT over DS protocol or FT over the Air protocol.

Lorenzo Santina (2):
   wifi: (80211r) add ft_psk_generate_local support
   wifi: (80211r) add ft_over_ds support

  .../luasrc/model/cbi/admin_network/wifi.lua| 38 ++
  1 file changed, 24 insertions(+), 14 deletions(-)


Hey Lorenzo,

LuCI is an independent project and not part of LEDE base system. It is 
maintained at https://github.com/openwrt/luci/. Do not get confused by 
the fact that it is in the OpenWrt repository. LuCI is compatible to and 
used by OpenWrt as well as LEDE.


Would you please create pull requests at 
https://github.com/openwrt/luci/pulls to make sure that the appropriate 
people get aware of your patches.


Mathias

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

Re: [LEDE-DEV] [PATCH] ramips: Add support for the Unielec U7621-6

[Mathias Kresin]

Hey Christian,

find my comments inline.

04.11.2017 21:53, Kristian Evensen:

Notes:
* According to the specifications on the Unielec website, two LEDs
should be controllable via GPIO. I was not able to find the pins.


Have you tired to set more/all pinmux groups to function GPIO?

Given the fact that your pincntrl node doesn't look like the usual 
copy'n'paste, I would guess you know what you're doing here and the 
answer is yes.




--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -508,6 +508,9 @@ ramips_board_detect() {
*"U25AWF-H1")
name="u25awf-h1"
;;
+   *"Unielec U7621-6 (256M RAM/16M flash)")
+   name="u7621-6-256M-16M"
+   ;;
*"UBNT-ERX")
name="ubnt-erx"
;;


Doesn't look like the correct alphabetical order.


index 00..fff6206e44
--- /dev/null
+++ b/target/linux/ramips/dts/U7621-6-256M-16M.dts
@@ -0,0 +1,54 @@
+/*
+ *  BSD LICENSE
+ *
+ *  Copyright(c) 2017 Kristian Evensen .
+ *  All rights reserved.
+ *
+ *  Redistribution and use in source and binary forms, with or without
+ *  modification, are permitted provided that the following conditions
+ *  are met:
+ *
+ ** Redistributions of source code must retain the above copyright
+ *  notice, this list of conditions and the following disclaimer.
+ ** Redistributions in binary form must reproduce the above copyright
+ *  notice, this list of conditions and the following disclaimer in
+ *  the documentation and/or other materials provided with the
+ *  distribution.
+ ** Neither the name of Broadcom Corporation nor the names of its
+ *  contributors may be used to endorse or promote products derived
+ *  from this software without specific prior written permission.
+ *
+ *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/dts-v1/;
+
+#include "U7621-6.dtsi"
+
+#include 
+#include 
+
+/ {
+   compatible = "unielec,u7621-6-256m-16m", "unielec,u7621-6", 
"mediatek,mt7621-soc";
+   model = "Unielec U7621-6 (256M RAM/16M flash)";
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x1000>;
+   };
+};
+
+ {
+   reg = <0x5 0xfb>;
+};


I know, I've done it the same way in the past, but it turned out to be 
really hard to read. I would prefer to have the full spi node in the 
U7621-6-256M-16M.dts.


If someone adds support for more memory/flash size variants, we can create:

- U7621-6.dtsi
- U7621-6-256M-ram.dtsi containing only the memory@ node
- U7621-6-16M-flash.dtsi containing only the spi@ node

and include the files in that order in a U7621-6-256M-16M.dts. This way 
we should be able to cover all variants without any duplications.



diff --git a/target/linux/ramips/image/mt7621.mk 
b/target/linux/ramips/image/mt7621.mk
index 8bd7e0318f..1bdd0024e4 100644
--- a/target/linux/ramips/image/mt7621.mk
+++ b/target/linux/ramips/image/mt7621.mk
@@ -225,6 +225,15 @@ define Device/timecloud
  endef
  TARGET_DEVICES += timecloud
  
+define Device/u7621-6-256M-16M

+  DTS := U7621-6-256M-16M
+  IMAGE_SIZE := 16777216


Looks wrong to me. The firmware partition has a size of 0xfb, which 
is 16449536 bytes or 16064k to be better readable.


Mathias

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

Re: [LEDE-DEV] [PATCH] base-files: Don't deconfigure IP settings while using NFS root

[Mathias Kresin]

05.11.2017 11:14, Petr Štetiar:

Signed-off-by: Petr Štetiar 
---


Hey Petr,

your patch doesn't have a commit message. The commit message should 
explain why the change is required/what gets fixed by the patch.


Please send a v2 with a proper commit message.

Mathias

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

Re: [LEDE-DEV] [OpenWrt-Devel] merge: add OpenWrt branding

[Mathias Kresin]

2017-10-24 16:59 GMT+02:00 Zoltan HERPAI :
> Hi Jo,
>
> On Tue, 24 Oct 2017, Jo-Philipp Wich wrote:
>
>> Hi,
>>
>> comments inline.
>>
>>> Signed-off-by: Imre Kaloz 
>>
>>
>> Given the fact that we explicitely wanted to avoid @openwrt.org mails
>> and that this was one of the discussion points leading to the split I
>> find it delicate to seal the merging commit with exactly such a S-o-b.
>>
>> Combined with ...
>>
>>  $ git log --author "Imre Kaloz " --format=%cD -1
>>  Tue, 18 Oct 2016 11:42:06 +0200
>>
>> ... this looks to me like nothing was learned from past experiences and
>> that all that matters here is having the own name attached to the work
>> being done.
>
>
> LEDE does have patches in the tree s-o-b-ed and accepted like this dated
> January '17. (f24ffb901e0408917748773b883841eca52eea05)
>
> "*) email accounts
> - currently there are around ~20 active openwrt.org mail accounts (the 3
> owrt devs would like to keep theirs active)
> - turn all the webmaster@, hostmaster@, ... accounts into aliases that
> anyone with voting rights can be subscribed to
> - ask those people that are no longer active to voluntarily give up their
> accounts
> - mail addresses may under no conditions be used for any personal business,
> consultancy, applying for jobs, ... purposes
> - any mail sent from an openwrt.org account needs to adhere the trademark
> policy and should only be used for FOSS purposes"
>
> In my view, this is FOSS purpose rather than anything else.

Can't we just find some kind of gentleman/ladies agreement to not use
the mail addresses in public? I mean, I never got why these three
people insists on using their mail addresses for anything other than
receiving mail/as a forwarder.

As soon as someone starts to use a @openwrt.org mail address,
basically all other are forced to do so as well. Otherwise the way it
comes across is N @openwrt.org core devs + X people committing as
well. Which I'm quite sure is what nobody wants to see.

my two cents
Mathias

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

Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 8/9] ramips: add Devolo WiFi Repeater (mt2681)

[Mathias Kresin]

22.10.2017 22:21, Zoltan HERPAI:

This is pretty much the same as the ALL0256N-8M but with different LED settings.

Based on Matt Jenkins' patch, with additional reworks.
https://github.com/openwrt/openwrt/pull/491

Signed-off-by: Zoltan HERPAI 


Hey Zoltan,

I'm not sure how proceed with the patch. It has bunch of issues and if 
someone else would send this patch I wouldn't merge it as it is.


Some of the issues are:

- missing hardware description in the commit message
- missing initial install instructions in the commit message
- bad board naming (the name looks like a mediatek reference board)
- wrong use of wifi led
- outdated syntax in the dts

Since you most likely do not have this board, I'm not sure if it does 
make any sense to do the full review => request changes cycle.


Any suggestions how to proceed with this one?

Mathias

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

Re: [LEDE-DEV] [OpenWrt-Devel] OpenWrt -> LEDE git tree merge

[Mathias Kresin]

22.10.2017 22:56, Hauke Mehrtens:

On 10/22/2017 10:28 PM, Zoltan HERPAI wrote:

Hi,

Zoltan HERPAI wrote:

Hi Hauke,

On Sun, 22 Oct 2017, Hauke Mehrtens wrote:


I am working on merging the missing commits from the OpenWrt git
repository into the LEDE repository.

Here is a list of all non merge commits from the OpenWrt git repository
and their corresponding LEDE commit IDs:
https://github.com/hauke/openwrt-lede-merge/blob/master/commits.csv

I only looked into the non merge commits and assumed that commits with
the same title are the same, if this is wrong please point me to some
place where this causes problems.

I used this script to generate the csv table:
https://github.com/hauke/openwrt-lede-merge/blob/master/openwrt-merge.py

The bigger topics I see are:
* addition of SoCFPGA target with kernel 4.4 support
* Will someone port this to kernel 4.9 or provide me with hardware so I
   can try to port this and test it?
* There are some commits without a Signed-off-by line, I will contact
  the authors.
* The realview target was removed from LEDE, but it got an update to
  kernel 4.4 in OpenWrt, how do we want to handle this? Does anyone need
  the realview target?


As discussed earlier, I've prepared manually a list of commits that
are missing from LEDE. I was about to send:

  - a set of patches that probably don't need any discussion and can be
merged right away,
  - a set of patches that are RFC, and should be discussed.

Let me know if that should still happen.

The series has been sent as discussed on irc. I don't recall any more
required - also based on checking the CSV, thanks for prepping that.

The RFC patches/PRs are:




...


- https://github.com/openwrt/openwrt/pull/312
ar71xx: add support for Zsun WiFi SD Card Reader


This is missing a Singed-of-by line


A few days ago a similar PR was created (and unfortunately already 
closed): https://github.com/lede-project/source/pull/1422.


The OpenWrt PR has a lot of issues, like enabling unencrypted wireless 
for the whole target.





https://github.com/openwrt/openwrt/commit/4f997727aef0603f02e9320ba787ea1b894747c0

lantiq: td-w8980: fix failsafe mode via ethernet.


This looks correct to me, but I do not have this board.


This one isn't required. The wrong interface in failsafe was fixed for 
the whole target with f080cfab72d8801856fa01f0476f1fc9b920a9d9.


Mathias

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

[LEDE-DEV] [PATCH] base-files: remove bridge firewalling defaults

[Mathias Kresin]

Since Linux kernel 3.18-rc1, the settings are moved to br_netfilter. If
the kmod is installed and loaded one would most like expect that
{ip,ip6,arp}tables see bridged traffic.

Fixes the following error messages reported in FS#1073 when
running sysctl -p:

 sysctl: error: 'net.bridge.bridge-nf-call-arptables' is an unknown key
 sysctl: error: 'net.bridge.bridge-nf-call-ip6tables' is an unknown key
 sysctl: error: 'net.bridge.bridge-nf-call-iptables' is an unknown key

Signed-off-by: Mathias Kresin <d...@kresin.me>
---
 package/base-files/Makefile  | 2 +-
 package/base-files/files/etc/sysctl.conf | 5 -
 2 files changed, 1 insertion(+), 6 deletions(-)

diff --git a/package/base-files/Makefile b/package/base-files/Makefile
index 216e457..e6c53e9 100644
--- a/package/base-files/Makefile
+++ b/package/base-files/Makefile
@@ -11,7 +11,7 @@ include $(INCLUDE_DIR)/kernel.mk
 include $(INCLUDE_DIR)/version.mk
 
 PKG_NAME:=base-files
-PKG_RELEASE:=176
+PKG_RELEASE:=177
 PKG_FLAGS:=nonshared
 
 PKG_FILE_DEPENDS:=$(PLATFORM_DIR)/ $(GENERIC_PLATFORM_DIR)/base-files/
diff --git a/package/base-files/files/etc/sysctl.conf 
b/package/base-files/files/etc/sysctl.conf
index ddc7a9b..992385a 100644
--- a/package/base-files/files/etc/sysctl.conf
+++ b/package/base-files/files/etc/sysctl.conf
@@ -24,8 +24,3 @@ net.netfilter.nf_conntrack_max=16384
 net.netfilter.nf_conntrack_tcp_timeout_established=7440
 net.netfilter.nf_conntrack_udp_timeout=60
 net.netfilter.nf_conntrack_udp_timeout_stream=180
-
-# disable bridge firewalling by default
-net.bridge.bridge-nf-call-arptables=0
-net.bridge.bridge-nf-call-ip6tables=0
-net.bridge.bridge-nf-call-iptables=0
-- 
2.7.4


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

Re: [LEDE-DEV] [RFC] at91: fix build of legacy target

[Mathias Kresin]

16.10.2017 00:44, Hauke Mehrtens:

Changing the order of the devices fixes the build problem seen by the
build bot. I do not understand why this is making any difference at all,
this is probably only hiding a different bug.

Signed-off-by: Hauke Mehrtens 
---

Without this patch I am getting the following error message:

cat 
/home/hauke/openwrt/lede/build_dir/target-arm_arm926ej-s_musl_eabi/linux-at91_legacy/tmp/lede-at91-legacy-tny_a9260-squashfs-factory.bin.dtb
 >> 
/home/hauke/openwrt/lede/build_dir/target-arm_arm926ej-s_musl_eabi/linux-at91_legacy/tmp/lede-at91-legacy-tny_a9260-squashfs-factory.bin
dd 
if=/home/hauke/openwrt/lede/build_dir/target-arm_arm926ej-s_musl_eabi/linux-at91_legacy/tmp/lede-at91-legacy-tny_a9260-squashfs-factory.bin
 
of=/home/hauke/openwrt/lede/build_dir/target-arm_arm926ej-s_musl_eabi/linux-at91_legacy/tmp/lede-at91-legacy-tny_a9260-squashfs-factory.bin.new
 bs= conv=sync
dd: invalid number: ''
Makefile:74: recipe for target 
'/home/hauke/openwrt/lede/build_dir/target-arm_arm926ej-s_musl_eabi/linux-at91_legacy/tmp/lede-at91-legacy-tny_a9260-squashfs-factory.bin'
 failed
make[5]: *** 
[/home/hauke/openwrt/lede/build_dir/target-arm_arm926ej-s_musl_eabi/linux-at91_legacy/tmp/lede-at91-legacy-tny_a9260-squashfs-factory.bin]
 Error 1
make[5]: Leaving directory '/home/hauke/openwrt/lede/target/linux/at91/image'
Makefile:24: recipe for target 'install' failed


Hey Hauke,

your issue is:

define Device/Default
  DTB_SIZE :=
endef

define Device/production-dtb
  $(Device/production)
  $(Device/dtb)
  DTB_SIZE := 128k
  IMAGE/factory.bin := append-dtb | pad-to (DTB_SIZE) \
  | append-kernel | pad-to (KERNEL_SIZE) | append-ubi
endef

The pad-to (DTB_SIZE) references the DTB_SIZE variable from 
Device/Default instead of Device/production-dtb.


The best would be to move DTB_SIZE := 128k to Device/Default (which is 
safe since we don't have different DTB_SIZE values). Another way to fix 
the issue is to change the pad-to parameter to pad-to $$(DTB_SIZE).


But I've to admit, I fail to see why it works as intended if you change 
the order of the build code and it's most likely the reason why I didn't 
noticed the issue at the time I merged 
c2f052acaeb480e89d3ce39c47f49ad16b3464ac.


Mathias

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

Re: [LEDE-DEV] [PATCH] ipq806x: add ap.dk01.1 board support

[Mathias Kresin]

15.10.2017 20:32, Roman Yeryomin:

- add partitions
- enable wifi and ethernet
- set max cpu speed to 710MHz
- set memory size to 256MB
- add image generation
- extract pre-cal data from ART partition

Wirespeed NAT can be achieved with spreading rx interrupts over different cores.
Wifi needs love -- too slow. Could be that latest ath10k helps, didn't test yet.

Signed-off-by: Roman Yeryomin 


Hey Roman,

would you please follow https://lede-project.org/submitting-patches and 
include in your commit message a short description of the hardware and 
how to install LEDE on it. Have a look at the recent additions for some 
examples.


Recently it has been once more shown that it's unnecessary hard to fix 
issues/bugs of a particular board if no one knows what kind 
flash/wifi/phy/whatever chip is used on a board.


Furthermore, without these informations a proper review of your patch is 
impossible.


Is this patch for the/a QCA reference board or for an off the shelf 
board based on the reference design?


Mathias

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

Re: [LEDE-DEV] No wireless on TDW8970 due to lack of PCI_SUPPORT

[Mathias Kresin]

05.10.2017 09:00, David Woodhouse:

I updated my TDW8970 from 17.01.1 to 17.01.3 last night and it came up
without wireless. It looks like I *couldn't* enable kmod-ath9k.

Config at http://david.woodhou.se/tdw8970.config-20171005


Your config works for me with 17.01.3. kmod-ath9k is selected as build-in.

I'm using 17.01.3 on a different xrx200 board with ath9k and ath10k 
without the reported issue. The PCI_SUPPORT flag is derived from the 
kernel config (CONFIG_PCI?) which is the same for all xrx200 boards.


Something in your local tree/build_dir is most likely dirty. Try to 
remove the tmp/ dir and if it doesn't fix the issue do a distclean.


Btw. your config looks a bit more custom than necessary to me. Could it 
be that you are using the same .config instead only the output of 
./scripts/diffconfig.sh + make defconfig as base for new builds?


Mathias

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

Re: [LEDE-DEV] [PATCH 1/3] mktplinkfw2: use hw rev for board detection too

[Mathias Kresin]

05.10.2017 01:20, Sergey Ryazanov:

On Mon, Oct 2, 2017 at 2:33 AM, Sergey Ryazanov  wrote:

Some boards have identical hardware id and differ only in hardware
revision (e.g. Acher C20 and Archer C20i). Such case confuse image
inspection code and it selects wrong board info structure.

Rework the board detection code to make it consider the hw revision
field. Now it returns best match board info:
* if possible then return board info with matched hw_id & hw_rev
* otherwise return first board info with matched hw_id (fallback to old
   behaviour)



This patch by some cause is not picked up by patchwork. Should I resend it?


Hey Sergey,

please hold on with resending the patch.

At the moment I'm reviewing 
https://github.com/lede-project/source/pull/1399 which will make your 
patch obsolete by removing the code you're patching.


The PR drops any hardcoded board params from mktplinkfw2.c in favour of 
commandline arguments, to provide only one way of creating tp-link 
images. It has the nice benefit that this file most likely doesn't need 
to be touched any more if new tp-link boards gets added.


Would be nice if you can give the PR a try to test for regressions.

Mathias

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

Re: [LEDE-DEV] [PATCH] procd: service_handle_set() should use SERVICE_SET_NAME rather than SERVICE_ATTR_NAME

[Mathias Kresin]

2017-10-04 12:49 GMT+02:00  :
> From: Pierre Lebleu 
>

^^^ and here should be an explanation why SERVICE_SET_NAME should be
used in favour of SERVICE_ATTR_NAME.

> Signed-off-by: Pierre Lebleu 
> ---
>  service/service.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/service/service.c b/service/service.c
> index 02a29fa..9c798aa 100644
> --- a/service/service.c
> +++ b/service/service.c
> @@ -267,7 +267,7 @@ service_handle_set(struct ubus_context *ctx, struct 
> ubus_object *obj,
> int ret;
>
> blobmsg_parse(service_set_attrs, __SERVICE_SET_MAX, tb, 
> blob_data(msg), blob_len(msg));
> -   cur = tb[SERVICE_ATTR_NAME];
> +   cur = tb[SERVICE_SET_NAME];
> if (!cur)
> return UBUS_STATUS_INVALID_ARGUMENT;
>
> --
> 1.9.1
>
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

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

Re: [LEDE-DEV] [PATCH 3/3] ramips: backport TP-Link image checks from AR71xx

[Mathias Kresin]

2017-10-02 11:10 GMT+02:00 Sergey Ryazanov <ryazanov@gmail.com>:
> On Mon, Oct 2, 2017 at 9:43 AM, Mathias Kresin <d...@kresin.me> wrote:
>> 02.10.2017 01:33, Sergey Ryazanov:
>>>
>>> Backport TP-Link image compatibility checks (verify hardware id &
>>> revision) from AR71xx platform and adopt it for v2/v3 image header.
>>>
>>> Use new functionality for Archer C20/C20i sysupgrade image verification.
>>
>>
>> NAK.
>>
>> The image metadata (more precisely the boardname) are used to ensure that
>> the image matches the board. We do not need any additional board checks.
>>
>> Even if the image metadata are not yet enforced on ramips (due to handful of
>> boards still using the old image build code), flashing an image with
>> metadata not matching the current board is refused. Flashing an image
>> without metadata is still possible till metadata are enforced.
>>
>
> Ok. This code path is also used to flash vendor firmware (return back
> to original firmware). By forbidding checks of vendor image header do
> we say to users that the selection of proper image (e.g. without
> bootloader) is on their own risk?

If you ask for my personal opinion, yes it is up to the user to ensure
(s)he is using a matching stock firmware image file.

Otherwise we have to add/keep/maintain barely used code for each
vendor image format. I'm really glad that we got rid of all the vendor
image checks already for some targets. It makes the whole sysupgrade
code way easier to read and better to understand.

Mathias

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

Re: [LEDE-DEV] [PATCH 3/3] ramips: backport TP-Link image checks from AR71xx

[Mathias Kresin]

02.10.2017 01:33, Sergey Ryazanov:

Backport TP-Link image compatibility checks (verify hardware id &
revision) from AR71xx platform and adopt it for v2/v3 image header.

Use new functionality for Archer C20/C20i sysupgrade image verification.


NAK.

The image metadata (more precisely the boardname) are used to ensure 
that the image matches the board. We do not need any additional board 
checks.


Even if the image metadata are not yet enforced on ramips (due to 
handful of boards still using the old image build code), flashing an 
image with metadata not matching the current board is refused. Flashing 
an image without metadata is still possible till metadata are enforced.


Mathias

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

Re: [LEDE-DEV] Add asterisk13-chan-lantiq to LEDE packages mips_24kc

[Mathias Kresin]

21.09.2017 20:35, Sebastian Kemper:

Hi all,

So now we have a broken-out asterisk-chan-lantiq package:
https://github.com/openwrt/telephony/tree/master/net/asterisk-chan-lantiq

I thought it would work like that, but the package still does not show
up in the target snapshot folder, e.g.
https://downloads.lede-project.org/snapshots/targets/lantiq/xrx200/packages/.

I looked it over again but couldn't spot the issue. But there must be
something wrong with it. There is one other nonshared package in the
feed, "usbip", and its packages show up fine.


With the config used by the buildbots [0], it can be seen that 
asterisk-chan-lantiq isn't build because it depends on asterisk.


The asterisk package is a shared package and not selected by 
CONFIG_ALL_NONSHARED=y.


Mathias

[0] 
https://downloads.lede-project.org/snapshots/targets/lantiq/xrx200/config.seed


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

Re: [LEDE-DEV] [PATCH] ipq806x: Archer C2600: fix switch ports numbering

[Mathias Kresin]

14.09.2017 11:36, Baptiste Jonglez:

Can this be merged to lede-17.01?  As I mentioned in the commit, it
applies cleanly.


Done!

Mathias

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

Re: [LEDE-DEV] Add asterisk13-chan-lantiq to LEDE packages mips_24kc

[Mathias Kresin]

12.09.2017 20:28, Sebastian Kemper:

On Tue, Sep 12, 2017 at 12:49:54PM +0200, sca...@arcor.de wrote:

Hello all,

can you please add asterisk13-chan-lantiq to the LEDE packages for
mips_24kc? It's possible to build this package via the SDK and I would
appreciate if you can build it automatically.


Hi Tim,

The package depends on TARGET_lantiq being set. Apparently that is not
correct (as the package isn't built). There are subtargets available, eg
TARGET_lantiq_falcon, TARGET_lantiq_xway and TARGET_lantiq_xrx200.
Maybe specifying one of these would work.

Do you know the subtarget for your board?


The subtarget isn't the issue here. It is the way packages are build by 
the LEDE buildbots.


We are building the packages only once for each combination of CPU 
architecture and CPU type. ar71xx and lantiq have mips-24kc set. Since 
ar71xx comes first in the alphabet, this target is most likely used to 
build all target independent packages.


The issue is that asterisk-13.x (or more precisely 
asterisk13-chan-lantiq) is a target specific package since it has a 
dependency on target lantiq.


Long story short, asterisk (if possible only the lantiq modules) need 
PKG_FLAGS:=nonshared.


Please use the bugtracker of the telephony feed[0] for reporting 
asterisk bugs. asterisk is not part of the LEDE base system, it is 
maintained as part of the telephony feed. Do not get confused by the 
fact that it is in the OpenWrt repository. The packages feed is 
compatible to and used by OpenWrt as well as LEDE.


I've added the asterisk maintainer in CC, to make him aware of the issue.

Mathias

[0] https://github.com/openwrt/telephony/issues

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

Re: [LEDE-DEV] [PATCH] ramips: Add support for the HNET C108

[Mathias Kresin]

06.09.2017 09:26, Kristian Evensen:

On Wed, Sep 6, 2017 at 9:03 AM, Mathias Kresin <d...@kresin.me> wrote:

* Wifi LED. It is always switched on.



Always switched on in terms of no relation to the up/down state of the
wireless interface or it doesn't blink on activity?

Is the LED connected to the SoC? Have you tried to set the "wled" group to
the gpio function? The wled group is only GPIO#72 ( 0).


No relation to the state. I tried to set the wled group + set gpio 72
to high/low, but it had no effect. Will update comment.


Might be that the LED is connected to VCC and not controllable at all. 
Strange hw design but who knows..





diff --git a/target/linux/ramips/base-files/etc/diag.sh
b/target/linux/ramips/base-files/etc/diag.sh
index 960e189283..7b267a6854 100644
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -296,6 +296,9 @@ get_status_led() {
 zbt-wg3526-32M)
 status_led="zbt-wg3526:green:status"
 ;;
+   c108)
+   status_len="$board:green:lan"
+   ;;



Please keep alphabetical order!


I was trying to figure out the lexicographical order in this file :)
The different cases seems to group together devices with different
names, so I thought it safest to place my entry at the end since I did
not find another device with same LED name. Any suggestions for a
different location (or LED name) are more than welcome.


Yeah, the file is out of alphabetical order again. Please add the c108 
to line 106, right before the block starting with cf-wr800n.




I missed the typo ("status_len"), so I will fix that for a v3.


+   power_modem {
+   gpio-export,name = "power_modem";
+   gpio-export,output = ;



You set the output value to 1 here. Please use gpio-export,output = 1.


Based on feedback I have got on earlier patches, it is preferred to
use the _LOW/_HIGH constants than 0/1 directly.


Most likely it was me who gave that advice. It was meant for the gpios 
device tree property. Here you are setting a value instead of describing 
active state. If there would be a macro, it should be something like 
GPIO_LOW or just LOW.


Mathias

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

Re: [LEDE-DEV] [PATCH] ramips: Add support for the HNET C108

[Mathias Kresin]

Hey Kristian,

I've picked your 01_leds file permission fix since it fixes an bug that 
I'm searching for a few days already.


Find comments from a first brief review inline.

Mathias

05.09.2017 21:48, Kristian Evensen:

The HNET C108
(http://www.szhwtech88.com/Product-product-cid-100-id-4374.html) is a
mifi based on MT7602A, which has the following specifications:

* CPU: MT7620A
* 1x 10/100Mbps Ethernet.
* 16 MB Flash.
* 64 MB RAM.
* 1x USB 2.0 port.
* 1x mini-PCIe slots.
* 1x SIM slots.
* 1x 2.4Ghz WIFI.
* 1x button.
* 6000 mAh battery.
* 5x controllable LEDs.

Works:
* Wifi.
* Switch.
* mini-PCIe slot. Only tested with a USB device (a modem).
* SIM slot.
* Sysupgrade.
* Button (reset).

Not working:
* USB port.


What does not working means? Not detected? USB devices not powered (but 
are working with an external powered hub)? Any error messages?



* Wifi LED. It is always switched on.


Always switched on in terms of no relation to the up/down state of the 
wireless interface or it doesn't blink on activity?


Is the LED connected to the SoC? Have you tried to set the "wled" group 
to the gpio function? The wled group is only GPIO#72 ( 0).




Not tested:
* SD card reader.

Notes:
* The C108 has no dedicated status LED. I therefore set the LAN LED as
status LED.
* By default, both the LAN and Wifi interface has the same MAC address.
The factory firmware sets the MAC address of the Wifi interface to (LAN
+ 2) in order to avoid having the same MAC. I did not find an easy way
to accomplish this using the existing LEDE infrastructure. Instead, I
implemented the opposite, i.e., the MAC address of the LAN interface is
increased by two.
* In commit 77645ffcd9ad767be02ea6d5cfe042928a3565d1, the mode of
01_leds was set to 0644. This patch changes that back 0755.

Installation:
The router comes pre-installed with OpenWRT, including a variant of
Luci. The initial firmware install can be done through this UI,
following normal procedure. I.e., access the UI and update the firmware
using the sysupgrade-image. Remember to select that you do not want to
keep existing settings.

Recovery:
If you brick the device, the C108 supports recovery using TFTP. Keep the
reset button pressed for ~5sec when booting to trigger TFTP. Set the
address of the network interface on your machine to 10.10.10.3/24, and
rename your image file to Kernal.bin.

Signed-off-by: Kristian Evensen 
---
  target/linux/ramips/base-files/etc/board.d/01_leds |   4 +
  .../linux/ramips/base-files/etc/board.d/02_network |   5 +
  target/linux/ramips/base-files/etc/diag.sh |   3 +
  target/linux/ramips/base-files/lib/ramips.sh   |   3 +
  .../ramips/base-files/lib/upgrade/platform.sh  |   1 +
  target/linux/ramips/dts/C108.dts   | 182 +
  target/linux/ramips/image/mt7620.mk|   8 +
  7 files changed, 206 insertions(+)
  mode change 100644 => 100755 
target/linux/ramips/base-files/etc/board.d/01_leds
  create mode 100644 target/linux/ramips/dts/C108.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
old mode 100644
new mode 100755
index ff5d156f2c..83e1a94000
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -82,6 +82,10 @@ broadway)
set_usb_led "$board:red:diskmounted"
set_wifi_led "$board:red:wps_active"
;;
+c108)
+   ucidef_set_led_netdev "lan" "lan" "$board:green:lan" "eth0"
+   ucidef_set_led_netdev "modem" "modem" "$board:green:modem" "wwan0"
+   ;;
  c20i)
ucidef_set_led_switch "lan" "lan" "$board:blue:lan" "switch0" "0x1e"
ucidef_set_led_switch "wan" "wan" "$board:blue:wan" "switch0" "0x01"
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 df70a8b2ec..273a0a75c9 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -217,6 +217,7 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"1:lan" "2:lan" "3:lan" "4:lan" "0:wan" "9@eth0"
;;
+   c108|\
cf-wr800n)
ucidef_add_switch "switch0" \
"4:lan" "6t@eth0"
@@ -386,6 +387,10 @@ ramips_setup_macs()
lan_mac=$(cat /sys/class/net/eth0/address)
wan_mac=$(mtd_get_mac_binary devdata 7)
;;
+   c108)
+   lan_mac=$(cat /sys/class/net/eth0/address)
+   lan_mac=$(macaddr_add "$lan_mac" 2)
+   ;;
cy-swr1100|\
dch-m225)
lan_mac=$(mtd_get_mac_ascii factory lanmac)
diff --git a/target/linux/ramips/base-files/etc/diag.sh 
b/target/linux/ramips/base-files/etc/diag.sh
index 960e189283..7b267a6854 100644
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ 

Re: [LEDE-DEV] build system question

[Mathias Kresin]

20.07.2017 09:59, Torbjorn Jansson:

hi

how do you convince the build system to continue building even if one of 
the packages from the feeds fails?


'make IGNORE_ERRORS=1' is what you are looking for. Use BUILD_LOG=1 to 
see why packages fail to compile.


Mathias

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

Re: [LEDE-DEV] [PATCH] ramips: add support for Loewe WMDR-143N

[Mathias Kresin]

2017-07-18 21:15 GMT+02:00 Oliver Fleischmann :
>>> + {
>>> +   state_default: pinctrl0 {
>>> +   gpio {
>>> +   ralink,group = "i2c", "jtag", "uartf";
>>> +   ralink,function = "gpio";
>>> +   };
>>> +   };
>>> +};
>>
>> Same as above. None if the pins in these groups are used as GPIO.
>
> But if I remove this part, the kernel hangs during boot reproducibly:
>
> (...)
> [0.134508] clocksource: jiffies: mask: 0x max_cycles:
> 0x, max_idle_ns: 1911260446275 ns
> [0.154048] futex hash table entries: 256 (order: -1, 3072 bytes)
> [0.166222] pinctrl core: initialized pinctrl subsystem
> [0.177541] NET: Registered protocol family 16
>
> and gone. It doesn't matter if I leave all three groups or only one of them,
> but as soon as I remove them all, it hangs. So I'd prefer to keep this...

I'm not entirely sure, but It rather looks like a (driver) bug to me.
If it is a bug, I prefer to see this bug fixed instead of adding not
required pinmuxes to workaround a possible bug.

>>> + {
>>> +   mtd-mac-address = < 0x4>;
>>> +
>>> +   port@0 {
>>> +   phy-handle = <>;
>>> +   phy-mode = "mii";
>>> +   };
>>> +   mdio-bus {
>>> +   status = "okay";
>>> +
>>> +   phy0: ethernet-phy@0 {
>>> +   reg = <0>;
>>> +   phy-mode = "mii";
>>> +   };
>>> +   };
>>> +};
>>> +
>>> + {
>>> +   status = "okay";
>>> +   ralink,mtd-eeprom = < 0>;
>>> +   mtd-mac-address = < 0x4>;
>>> +   mtd-mac-address-increment = <1>;
>>
>>
>> Have you validated against the original firmware that wireless and
>> ethernet have different mac addresses? Is it the wireless mac address
>> that is incremented? I'm somehow in doubt here, since there is no
>> ethernet by default for this board.
>
>
> With the original firmware, both interfaces do indeed have different mac
> addresses. The wireless interface uses the one from the "Factory"
> partition (e.g. F8:35:DD:C9:1B:19), not incremented (sorry).
>
> The ethernet interface has a completely different address (e.g.
> 00:0C:43:28:80:0F). I have no idea where it comes from, I can't find it in
> any of the configuration partitions wether in binary or in ASCII. It gets
> set by a kernel module (raeth.ko). In the hexdump of this binary module, I
> can find a part of this address (00 0c 43 28 80 00) hardcoded.
>
> So I thought, just incrementing the given address for the second interface
> would do for the beginning. Do you have a suggestion for a better solution?

00:0C:43 is the RaLink mac prefix and 00:0C:43:28:80:0F is set as
default mac address by the proprietary driver. Most likely it is the
same for all WMDR-143N boards.

Long story short, there is no designated mac address for the ethernet
interface and we should not use the incremented wireless mac address
for the ethernet interface. The resulting mac address might be used by
other boards. Just drop  mtd-mac-address* from the dts. This way a
random one is used. Not a perfect solution, but IMHO better than what
you have at the moment.

Alternatively, it would be possible to set 00:0C:43:28:80:0F for the
ethernet of all WMDR-143N boards by using

  mac-address = [ 00 0C 43 28 80 0F ];

in the dts. Use whatever you prefer.

Mathias

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

Re: [LEDE-DEV] [PATCH] ar71xx: add ew-balin platform from Embedded Wireless

[Mathias Kresin]

2017-07-19 14:19 GMT+02:00 Catrinel Catrinescu :
> Add the Embedded Wireless Balin platform, based on AR9344
>
> Signed-off-by: Catrinel Catrinescu 

Please include in your commit message a short description of the
hardware and how to install LEDE on it. Have a look at the recent
additions for some examples and our "Submitting patches guideline"
[0].

Mathias

[0] https://lede-project.org/submitting-patches

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

Re: [LEDE-DEV] [PATCH] ramips: add support for Loewe WMDR-143N

[Mathias Kresin]

Hey Oliver,

thanks a lot for your patch. Find my comments inline.

2017-07-17 20:20 GMT+02:00 Oliver Fleischmann :
> The WMDR-143N is a small module originally used as a Wifi client
> in some Loewe smart TV sets. It is sold cheaply at german surplus
> shops. The module contains a RT3662 SOC.
>
> Specifications:
>
> - 500 MHz CPU Clock
> - 1x 10/100Mbps Ethernet (pin header)
> - 32 MB of RAM
> - 8 MB of FLASH
> - 2T3R 2.4/5 GHz (SOC internal)
> - 3 Antennas on PCB
> - UART pads on PCB (J3: 1 = +5V, 2 = RX, 3 = TX, 4 = GND), TX and
>   RX are 3,3V only! The square hole is pin 1
> - Power supply pads on PCB (J6: 1 and 2 = +5V, 3 and 4 = GND)
>   The square hole is pin 1
>
> The original firmware has two identical kernel/rootfs images and
> two "Factory" calibration data blocks in flash. The LEDE image
> leaves only the first "Factory" block in place and uses both
> "Kernel" blocks and the redundant "Factory" block together to gain
> enough space for the jffs2 partition.
>
> Flash instructions:
>
> You need UART and Ethernet connections to flash the board. Use
> the LEDE "factory" image with tftp.
>
> Apply power to the board and in the first 5 seconds, hit 2 to
> select TFTP upload. The bootloader asks for board- and server IP
> addresses and filename.
>
> Alternate method: With the vendor firmware running, assign an IP
> address to the ethernet port, tftp the firmware image to
> /tmp and write to mtd4 ("KernelA").
>
> Signed-off-by: Oliver Fleischmann 
> ---
>  .../linux/ramips/base-files/etc/board.d/02_network |  4 +-
>  target/linux/ramips/base-files/lib/ramips.sh   |  3 +
>  .../ramips/base-files/lib/upgrade/platform.sh  |  1 +
>  target/linux/ramips/dts/WMDR-143N.dts  | 82 
> ++
>  target/linux/ramips/image/rt3883.mk| 14 
>  5 files changed, 103 insertions(+), 1 deletion(-)
>  create mode 100644 target/linux/ramips/dts/WMDR-143N.dts

[snip]

> diff --git a/target/linux/ramips/dts/WMDR-143N.dts 
> b/target/linux/ramips/dts/WMDR-143N.dts
> new file mode 100644
> index 00..66db0c8ea8
> --- /dev/null
> +++ b/target/linux/ramips/dts/WMDR-143N.dts
> @@ -0,0 +1,82 @@
> +/dts-v1/;
> +
> +#include "rt3883.dtsi"
> +
> +#include 

You can drop this include. You don't have any input devices (buttons)
in your dts.

> +
> +/ {
> +   compatible = "WMDR-143N", "ralink,rt3883-soc";

should be: compatible = "loewe,wmdr-143n", "ralink,rt3883-soc";

> +   model = "Loewe WMDR-143N";
> +};
> +
> + {
> +status = "okay";
> +
> +m25p80@0 {
> +#address-cells = <1>;
> +#size-cells = <1>;
> +compatible = "jedec,spi-nor";
> +reg = <0>;
> +spi-max-frequency = <2500>;
> +
> +partition@0 {
> +label = "u-boot";
> +reg = <0x0 0x3>;
> +read-only;
> +};
> +
> +partition@3 {
> +label = "u-boot-env";
> +reg = <0x3 0x0001>;
> +read-only;
> +};
> +
> +factory: partition@4 {
> +label = "factory";
> +reg = <0x4 0x1>;
> +read-only;
> +};
> +
> +partition@5 {
> +label = "firmware";
> +reg = <0x5 0x7b>;
> +};
> +};
> +};
> +
> + {
> +   status = "okay";
> +};

The gpio1 node can be dropped. None of the SoC pins are used as GPIOs
for this board.

> +
> + {
> +   state_default: pinctrl0 {
> +   gpio {
> +   ralink,group = "i2c", "jtag", "uartf";
> +   ralink,function = "gpio";
> +   };
> +   };
> +};

Same as above. None if the pins in these groups are used as GPIO.

> +
> + {
> +   mtd-mac-address = < 0x4>;
> +
> +   port@0 {
> +   phy-handle = <>;
> +   phy-mode = "mii";
> +   };
> +   mdio-bus {
> +   status = "okay";
> +
> +   phy0: ethernet-phy@0 {
> +   reg = <0>;
> +   phy-mode = "mii";
> +   };
> +   };
> +};
> +
> + {
> +   status = "okay";
> +   ralink,mtd-eeprom = < 0>;
> +   mtd-mac-address = < 0x4>;
> +   mtd-mac-address-increment = <1>;

Have you validated against the original firmware that wireless and
ethernet have different mac addresses? Is it the wireless mac address
that is incremented? I'm somehow in doubt here, since there is no
ethernet by default for this board.

> +};
> diff --git a/target/linux/ramips/image/rt3883.mk 
> b/target/linux/ramips/image/rt3883.mk
> index 2cd60f3858..c21a2cad1b 100644
> --- a/target/linux/ramips/image/rt3883.mk
> +++ 

Re: [LEDE-DEV] [PATCH] ramips: fix GPIOs for Ubiquiti EdgeRouter X-SFP

[Mathias Kresin]

2017-06-08 20:11 GMT+02:00 Sven Roederer :
> This adds the i2c-gpio and i2c-pca95xx module to the default kernel.
> Even they are listed in the dependencies of the board, they are not
> built and for this missing in the imagefile. This causes that the
> accessed hardware is not avail.

Hey Sven,

I had a look at the sysupgrade.tar snapshot image. gpio-pca953x.ko and
i2c-gpio.ko are included. Could it be that you hit the issue that
DEVICE_PACKAGES are not included in ramdisk images?

Mathias

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

Re: [LEDE-DEV] [PATCH] firmware-utils: mktplinkfw2: fix MD5 salt

[Mathias Kresin]

02.07.2017 17:17, Rafał Miłecki:

From: Rafał Miłecki <ra...@milecki.pl>

LEDE supports 6 devices using TP-Link firmware format (V2 or V3):
ArcherC20i, ArcherC50, ArcherMR200, TDW8970, TDW8980 and VR200v.

Testing mktplinkfw2 tool with official (vendor generated) firmware files
for all above devices has shown an error when comparing calculated and
included MD5 sum, e.g.:

mktplinkfw2 -i 
Archer_C20iv1_0.9.1_3.2_up_boot\(170221\)_2017-02-21_17.14.03.bin | grep -A 1 
MD5Sum1

Header MD5Sum1 : 22 5a cb 92 10 d2 95 7b df 62 9a f8 62 17 37 10 
(*ERROR*)
   --> expected : ad 19 11 d1 78 98 a7 42 5f 2e 64 da 8a 34 ec cb

This problem has been verified to occur with:
Archer_C20iv1_0.9.1_3.2_up_boot(170221)_2017-02-21_17.14.03.bin
Archer_C50v3_EU_0.9.1_0.3_up_boot[170417-rel52298].bin
Archer MR200v1_0.9.1_1.1_up_boot_v004a.0 Build 160905 Rel.60037n.bin
TD-W8970v3_0.9.1_2.0_up_boot(160816)_2016-08-16_10.40.57.bin
TD-W8980v1_0.6.0_1.8_up_boot(150514)_2015-05-14_11.16.43.bin
Archer_VR200vv2_0.2.0_0.8.0_up_boot(161202)_2016-12-05_14.39.06.bin

It's most likely that MD5 salt used in mktplinkfw2 has been always wrong
(and it's not a matter of e.g. a vendor change). Update it to fix MD5
calculation.

One problem that remains is zero MD5 sum calculated for:
Archer_C50v3_EU_0.9.1_0.3_up_boot[170417-rel52298].bin

Signed-off-by: Rafał Miłecki <ra...@milecki.pl>
---
  tools/firmware-utils/src/mktplinkfw2.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/firmware-utils/src/mktplinkfw2.c 
b/tools/firmware-utils/src/mktplinkfw2.c
index cfedf81d3b..ae7c6b7875 100644
--- a/tools/firmware-utils/src/mktplinkfw2.c
+++ b/tools/firmware-utils/src/mktplinkfw2.c
@@ -153,8 +153,8 @@ char md5salt_normal[MD5SUM_LEN] = {
  };
  
  char md5salt_boot[MD5SUM_LEN] = {

-   0x8c, 0xef, 0x33, 0x5b, 0xd5, 0xc5, 0xce, 0xfa,
-   0xa7, 0x9c, 0x28, 0xda, 0xb2, 0xe9, 0x0f, 0x42,
+   0x8c, 0xef, 0x33, 0x5f, 0xd5, 0xc5, 0xce, 0xfa,
+   0xac, 0x9c, 0x28, 0xda, 0xb2, 0xe9, 0x0f, 0x42,
  };
  
  static struct flash_layout layouts[] = {



Matches the values [0] I found while disassembling the TD-W8980v1 
bootloader.


Acked-by: Mathias Kresin <d...@kresin.me>

[0] https://github.com/xdarklight/mktplinkfw3

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

Re: [LEDE-DEV] [PATCH v3] ramips: add support for GL-inet GL-MT300N-V2

[Mathias Kresin]

2017-05-17 12:18 GMT+02:00 kysonlok :
> This patch adds supports for the GL-inet GL-MT300N-V2.
>
> Specification:
> - SoC: MediaTek MT7628AN
> - Flash: 16 MiB (W25Q128FVSG)
> - RAM: 128 MiB DDR
> - Ethernet: 1 x WAN (100 Mbps) and 1 x LAN (100 Mbps)
> - USB: 1 x USB 2.0 port
> - Button: 1 x switch button, 1 x reset button
> - LED: 3 x LEDS (system power led is not GPIO controller)
> - UART: 1 x UART on PCB (JP1: 3.3V, RX, TX, GND)
>
> Installation through Luci:
> - The original firmware is LEDE, so both LuCI or sysupgrade can be used.
> - Do not keep settings, for sysupgrade please use the -n option.
>
> Installation through bootloader webserver:
> - Plug power and hold reset button until red LED blink to bright.
> - Install sysupgrade image using web interface on 192.168.1.1.
>
> Signed-off-by: kyson Lok 
> ---
>  target/linux/ramips/base-files/etc/board.d/01_leds |   3 +
>  .../linux/ramips/base-files/etc/board.d/02_network |   4 +
>  target/linux/ramips/base-files/etc/diag.sh |   3 +
>  target/linux/ramips/base-files/lib/ramips.sh   |   3 +
>  .../ramips/base-files/lib/upgrade/platform.sh  |   1 +
>  target/linux/ramips/dts/GL-MT300N-V2.dts   | 133 
> +
>  target/linux/ramips/image/mt7628.mk|   8 ++
>  7 files changed, 155 insertions(+)
>  create mode 100644 target/linux/ramips/dts/GL-MT300N-V2.dts

Merged to my staging tree with a little bugfix. Will push it to master
during the next days.

Thanks!

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

Re: [LEDE-DEV] [PATCH v2 2/3] base-files: put board_name into separate file

[Mathias Kresin]

17.05.2017 21:08, Roman Yeryomin:

On 17 May 2017 at 21:39, Roman Yeryomin <leroi.li...@gmail.com> wrote:

On 17 May 2017 at 16:19, Mathias Kresin <d...@kresin.me> wrote:

Hey Roman.,

independent of the work done by you, I worked on exactly the same
topic. But I've pushed it a bit further by switching all targets to
the generic boardname function and a few targets to the generic board
detection in basefiles/preinit.

Furthermore I've converted some targets to get the boardname from the
device tree compatible string as suggested by John. Till now I wasn't
comfortable to push it somewhere, but with my latest changes it should
work in theory. You can find the changes at
https://git.lede-project.org/?p=lede/mkresin/staging.git;a=shortlog;h=refs/heads/boarddetection.
What is missing: testing!


Some of your changes would be ok to me if:
- board.sh would be used instead of functions.sh (which I would like
to split into several files anyway) for $(board_name)


I guess we all got your point. But I'm sorry to say, that isn't subject 
of my changes.



- related changes would be squashed into one commit, otherwise it's
hard to perceive/track the changes, IMO more commits is not always
better


The commits will be most likely squashed before I commit them. But at 
least during review I prefer smaller changes instead of a single patch 
with >100 lines.




also this one is a fail:
https://git.lede-project.org/?p=lede/mkresin/staging.git;a=commitdiff;h=af3ef20591e6e9e4ee2cf1b1fc58012df68445ba


Hopefully someone beats me with a stick if I every reply during a review 
with "fail" and without any explanation what is wrong. This isn't 
helpful in any kind and just a waste of your and my time.


But I can give you a quick summary why the commit is required:

No target_board_name() => target_board_detect() isn't called => 
/tmp/sysinfo/board_name isn't populated => board_name() has nothing to 
return.


And as the commit message states, it is also meant to unify the way the 
board detection is done between targets (to not fool more people like I 
was fooled because of these target specifics).


Mathias

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

Re: [LEDE-DEV] [PATCH v2 2/3] base-files: put board_name into separate file

[Mathias Kresin]

Hey Roman.,

independent of the work done by you, I worked on exactly the same
topic. But I've pushed it a bit further by switching all targets to
the generic boardname function and a few targets to the generic board
detection in basefiles/preinit.

Furthermore I've converted some targets to get the boardname from the
device tree compatible string as suggested by John. Till now I wasn't
comfortable to push it somewhere, but with my latest changes it should
work in theory. You can find the changes at
https://git.lede-project.org/?p=lede/mkresin/staging.git;a=shortlog;h=refs/heads/boarddetection.
What is missing: testing!

2017-05-17 13:49 GMT+02:00 Roman Yeryomin :
> Hi John,
>
> the reasoning is that most scripts which need board_name, don't need
> anything else, and those which do need more, they need only a fraction
> of functions.sh

Due to the fact that I had to touch all scripts using the board name,
I feel confident enough to reply here. I don't see any benefit in
moving the board_name function into an extra script. Most of the
scripts include (and require) functions.sh anyway.

I would be happy I've you can review and runtime test the boardname
branch from my staging tree.

Mathias

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

Re: [LEDE-DEV] [PATCH 2/3] ramips-mt7621: add GPIO-config for Ubiquiti-EdgeRouterX(-SFP)

[Mathias Kresin]

14.05.2017 21:22, Sven Roederer:

I just gave it another try, as I like the idea of having it in the DTS. As my 
test ERX is gone I continue testing on ERX-SFP.
Please se below ...

On Sonntag, 14. Mai 2017 16:24:15 CEST Mathias Kresin wrote:


If you use the gpio-export node in the device tree source file, the gpio
pin should appear at /sys/class/gpio/. Most likely you have done
something wrong. Could it be that you used exactly the same gpio pin
number as you have it in your 03_gpio_export file? You need to decrement
the gpio pin number by the gpio base as it is done for all gpios in the
dts.


for the "gpio in dts" I used this branch
https://github.com/SvenRoederer/lede-project-source/commits/ERX-SFP_gpio-
in-dts --> see the last 2 commits. Code only changed for ERX for this
test.
Did I miss something?


Yes you did. The gpio-export,output value is wrong. It has to be either
0 or 1, similar to the values set for the gpio_switch config in
/e/c/system.



I removed the 03_gpio_export and added this to the dts:
gpio_export {
compatible = "gpio-export";
#size-cells = <0>;

poe_passthrough {
gpio-export,name = "poe_power_port0";
gpio-export,output = <1>;
gpios = < 496 0>;


Your GPIO number is wrong.

The device tree is some kind of abstraction layer to the hardware and in 
terms of GPIOs you are only using "logical/virtual" GPIO numbers.


The mt7621 has two GPIO banks: gpio0 and gpio1 (yes I know there is a 
gpio2 in the mt7621.dtsi, but the SoC has only 61 GPIOs). Each GPIO bank 
has 32 GPIOs and is exported to the sysfs at /sys/class/gpio/gpiochipNNN.


/sys/class/gpio/gpiochipNNN/base is the first (physical/real) GPIO 
number managed by this chip. If the gpiochips base is 462,  0 to 
31 refers to the physical GPIOs 462 to 493.  0 to 28 refers to the 
physical GPIOs 494 to 522.


But it is still not the whole story. The pins of the SoC can have 
different functions. Via the pinmux node you specify the purpose of the 
pins[0]. For the ERX the following groups are set to GPIO mode:


uart2:  9 to 12
uart3:  5 to 8
i2c:  3 to 4
pcie:  19
rgmii2:  22 to 31,  0 to 1
jtag:  13 to 17

It kinda looks like copy/paste from the MT7621.dts. Most of the GPIOs 
are not used at all.


Mathias

[0] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/mips/ralink/mt7621.c


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

Re: [LEDE-DEV] [PATCH 2/3] ramips-mt7621: add GPIO-config for Ubiquiti-EdgeRouterX(-SFP)

[Mathias Kresin]

13.05.2017 20:09, Sven Roederer:

On Montag, 8. Mai 2017 08:23:50 CEST Mathias Kresin wrote:

07.05.2017 23:24, Sven Roederer:

On Sonntag, 7. Mai 2017 12:25:39 CEST you wrote:

Just an opinion: being able to disable/enable PoE for each port is really
useful when you want to remotely reboot a device plugged into your PoE
switch/router.  Most PoE-capable devices expose this option with the
stock
firmware.

Does your approach with the gpio-export node allow to change the state of
the GPIO at runtime? (i.e. probably from userspace)


Baptiste,

right, that's the point I'm also looking for. To have da clean way of
controlling the state of the PoE-voltage (24V passive PoE) for the ports.
As it's passive PoE there might be a big risk that having the power
enabled
all the time might cause some problems.

When defining in dts I don't see them in uci or even in /sys/class/gpio.
So via "board.d/03_gpio_switches" seems the best way to bring them to
userspace for user-interaction.


If you use the gpio-export node in the device tree source file, the gpio
pin should appear at /sys/class/gpio/. Most likely you have done
something wrong. Could it be that you used exactly the same gpio pin
number as you have it in your 03_gpio_export file? You need to decrement
the gpio pin number by the gpio base as it is done for all gpios in the dts.

Correct me if I'm wrong, but as far I can see (and confirmed by testing
it) the exported gpio in UCI doesn't have any benefit for your restart
usecase. If I change the gpio value via uci and restart
/etc/init.d/system the gpio value is still the same. Means, the value is
only set during the actual export (on boot).

Mathias


Mathias,

for the "gpio in dts" I used this branch 
https://github.com/SvenRoederer/lede-project-source/commits/ERX-SFP_gpio-in-dts --> see 
the last 2 commits. Code
only changed for ERX for this test.
Did I miss something?


Yes you did. The gpio-export,output value is wrong. It has to be either 
0 or 1, similar to the values set for the gpio_switch config in 
/e/c/system.


To make it as easy as possible for people to help, please paste your 
patch next time into the e-mail body of your reply.




You are correct, that this uci-config only gets applied on boot. but changing
uci and calling "reload-config" will do the "magic".


Oh indeed, reload_config does the job. I wasn't aware of this little helper.

As I already wrote the last time, I'll leave it up to you to add what 
you are the opinion is the best for the use case. I just wanted to 
ensure that is wasn't added because of lack of knowledge about the 
alternatives.


Mathias

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

Re: [LEDE-DEV] [PATCH] iwinfo get scan results from wpa_supplicant in station mode. wpa_supplicant return some other info before return results. Loop recv until get real scan results.

[Mathias Kresin]

12.05.2017 07:40, Adams:

---
 .../utils/iwinfo/patches/002-wds-scan.patch|   26 
 1 file changed, 26 insertions(+)
 create mode 100644 package/network/utils/iwinfo/patches/002-wds-scan.patch

diff --git a/package/network/utils/iwinfo/patches/002-wds-scan.patch 
b/package/network/utils/iwinfo/patches/002-wds-scan.patch
new file mode 100644
index 000..46d7a61
--- /dev/null
+++ b/package/network/utils/iwinfo/patches/002-wds-scan.patch
@@ -0,0 +1,26 @@
+Index: libiwinfo-2016-09-21-fd9e17be/iwinfo_nl80211.c
+===
+--- libiwinfo-2016-09-21-fd9e17be.orig/iwinfo_nl80211.c2017-05-12 
09:15:36.572930342 +0800
 libiwinfo-2016-09-21-fd9e17be/iwinfo_nl80211.c 2017-05-12 
09:19:58.311845210 +0800
+@@ -2241,6 +2241,12 @@
+   /* receive and parse scan results if the wait above didn't time out */
+   if (ready && nl80211_wpactl_recv(sock, reply, sizeof(reply)) > 0)
+   {
++
++  while(!strstr(reply, "bssid")) {
++  if(nl80211_wpactl_recv(sock, reply, sizeof(reply)) <= 0)
++  goto end;
++  }
++
+   nl80211_get_quality_max(ifname, );
+
+   for (line = strtok_r(reply, "\n", );
+@@ -2319,7 +2325,7 @@
+
+   *len = count * sizeof(struct iwinfo_scanlist_entry);
+   }
+-
++end:
+   close(sock);
+   unlink(local.sun_path);
+



Hey,

your "Signed-off-by" is missing and it seams the text intended to be the 
commit message made it into to the commit subject. Please have a look at 
our "submitting patches" guideline[0].


Please fix both issues and send an updated version of your patch.

Mathias

[0] https://lede-project.org/submitting-patches

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

Re: [LEDE-DEV] [PATCH v2] ramips: add support for GL-inet GL-MT300N-V2

[Mathias Kresin]

12.05.2017 03:37, kyson lok:

On Fri, May 12, 2017 at 6:18 AM, L. D. Pinney  wrote:

+ {
+   status = "okay";
+
+   m25p80@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <1000>;
+   m25p,chunked-io = <32>;
+
+   partition@0 {
+   label = "u-boot";
+   reg = <0x0 0x3>;
+   read-only;
+   };
+
+   partition@3 {
+   label = "u-boot-env";
+   reg = <0x3 0x1>;
+   read-only;


Is there a reason that users can not or should not write to the
uboot-env partition?


Yes, to prevent the user to shout them self into the foot. If it ain't 
broke don't fix it.




   partition@3 {
  label = "u-boot-env";
  reg = <0x3 0x1>;
  read-only; < remove this line IF it is
OK for user to write here.


I don't think user can write to uboot-env, other vendor does not.




+   };
+
+   factory: partition@4 {
+   label = "factory";
+   reg = <0x4 0x1>;
+   read-only;
+   };
+
+   partition@5 {
+   label = "firmware";
+   reg = <0x5 0xf0>;


Is this correct? other mt76x8 devices with 16MB SPI Flash use :

partition@5 {
label = "firmware";
reg = <0x5 0xfb>;



I think it doesn't matter. I only use 15MB for firmware.


But why don't you use all available flash space? As far as I can see, 
there isn't anything in the last 704 KB of the flash. If possible expand 
the firmware partition to use all of the remaining flash space.


Please update the IMAGE_SIZE in the build code to the value set here.

Mathias

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

Re: [LEDE-DEV] openwrt and lede - remerge proposal

[Mathias Kresin]

12.05.2017 23:45, Val Kulkov:

On 12 May 2017 at 17:40, David Lang  wrote:

On Fri, 12 May 2017, Val Kulkov wrote:


I should also note that it is extremely important to ask the right
question. You get what you ask for. Apparently, the developers voted
on this question: "Re-brand LEDE to OpenWrt?" (see the link above)
IMHO the question should have been "Should the merged project be
called OpenWrt?"



the vote was not "should lede be re-branded", it was "what should the merged
project be named"



David, please see the exact question here:
http://lists.infradead.org/pipermail/lede-adm/2017-March/000436.html


It might not be easy to get for people which were not involved in the 
whole process, but let me assure you as a LEDE developer the question 
was "what should the merged project be named". Anyway, thanks a lot for 
explaining to use what we have voted about.






Because the issue is not whether to re-brand LEDE to OpenWrt, the
issue is the whether the merged project should retain the old name
that quite a few people consider to be tainted now.



yes, there are some people who hold very strong opinions on the topic, but
the vote was held and the majority voted for the name openwrt.


The majority? There was a tie. Please see the above link.


No it was a +1 for OpenWrt. What you are linking to was a (preliminary) 
summary. The last vote about the topic was 
http://lists.infradead.org/pipermail/lede-adm/2017-March/000437.html, 
which makes it +1. There were no more votes in the following two month.


Now that all ambiguities are cleared, everyone can go back to work 
instead of writing/reading pointless mails.


Mathias

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

Re: [LEDE-DEV] [PATCH] lantiq: dsl_notify: also restart pppoe interfaces

[Mathias Kresin]

09.05.2017 00:44, Valentin Spreckels:

Signed-off-by: Valentin Spreckels 

---


Thanks a lot for your patch. Would you please add a commit message which 
describes the issue you are trying to fix. At the moment I fail to see 
why this change is required.


I rather suspect that the whole pppoa interface handling can be removed 
from dsl_notify.sh. Isn't it handled by netifd now days?


Mathias


 target/linux/lantiq/base-files/sbin/dsl_notify.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/lantiq/base-files/sbin/dsl_notify.sh 
b/target/linux/lantiq/base-files/sbin/dsl_notify.sh
index 11ada92..8503ab4 100755
--- a/target/linux/lantiq/base-files/sbin/dsl_notify.sh
+++ b/target/linux/lantiq/base-files/sbin/dsl_notify.sh
@@ -33,7 +33,7 @@ for ifc in $interfaces; do
json_load "$(ifstatus $ifc)"

json_get_var proto proto
-   if [ "$proto" != "pppoa" ]; then
+   if [ "$proto" != "pppoa" -a "$proto" != "pppoe" ]; then
continue
fi





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

Re: [LEDE-DEV] [PATCH] Add missing packages for WeVO 11AC NAS

[Mathias Kresin]

07.05.2017 05:24, perillamint:

mt7621.mk does not include all required packages for WeVO 11AC NAS,
so official image does not support 5GHz WiFi(mt76x2) out of the box.
This patch fixes that.


Your Signed-off-by is missing. Please have a look at 
https://lede-project.org/submitting-patches.



---
 target/linux/ramips/image/mt7621.mk | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/target/linux/ramips/image/mt7621.mk
b/target/linux/ramips/image/mt7621.mk
index 733fb08..f5e5b34 100644
--- a/target/linux/ramips/image/mt7621.mk
+++ b/target/linux/ramips/image/mt7621.mk
@@ -30,7 +30,9 @@ define Device/11acnas
   DTS := 11ACNAS
   IMAGE_SIZE := $(ralink_default_fw_size_16M)
   DEVICE_TITLE := WeVO 11AC NAS Router
-  DEVICE_PACKAGES := kmod-mt7603 kmod-usb3 kmod-usb-ledtrig-usbport
wpad-mini
+  DEVICE_PACKAGES := \
+   kmod-mt7603 kmod-mt76x2 kmod-usb3 kmod-usb-ledtrig-usbport
kmod-mt76 \


Adding kmod-mt76x2 should be enough to get the 5GHz WiFi(mt76x2) 
working. No need to add kmod-mt76.



+   wpad-mini
 endef
 TARGET_DEVICES += 11acnas
 -- 2.1.4






smime.p7s
Description: S/MIME Cryptographic Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] ramips: Add support for the VoCore2 Lite

[Mathias Kresin]

Hey Laray,

Please split the patch. One patch for the minor corrections of the 
VoCore2 an one adding the VoCore2 lite to make the review easier.


Find some comments inline.

07.05.2017 03:41, L. D. Pinney:

The VoCore2 Lite uses the same PCB as the Vocore2 with a MT7688A and 8M 
Flash/64M RAM
https://www.indiegogo.com/projects/vocore2-4-coin-sized-linux-computer-with-wifi#/
http://vocore.io/
http://vonger.net/

This patch uses a common dtsi and includes minor corrections for the VoCore2.

- Installing from the bootloader is recommended.
- The original firmware is LEDE/OpenWrt, so both LuCI or sysupgrade can be used.
- However you may need to edit /sys/sysinfo/board_name and 
/lib/upgrade/platform.sh
- If using luci/sysupgrade use the -n option (do not keep settings)
- Reverting to the factory firmware one may need to edit the same files or use 
the bootloader.

Signed-off-by: L. D. Pinney 
Tested-by: Noble Pepper 

---
 target/linux/ramips/base-files/etc/board.d/01_leds |  5 -
 target/linux/ramips/base-files/etc/board.d/02_network  |  3 ++-
 target/linux/ramips/base-files/etc/diag.sh |  5 -
 target/linux/ramips/base-files/lib/ramips.sh   |  3 +++
 target/linux/ramips/base-files/lib/upgrade/platform.sh |  1 +
 target/linux/ramips/dts/VOCORE2.dts| 79 
--
 target/linux/ramips/dts/VOCORE2.dtsi   | 79 
++
 target/linux/ramips/dts/VOCORE2L.dts   | 52 
+++
 target/linux/ramips/image/mt7688.mk|  9 
 9 files changed, 158 insertions(+), 78 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 52542ec265..c4d46cf31a 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -334,7 +334,10 @@ vocore-16M)
set_wifi_led "vocore:green:status"
;;
 vocore2)
-   set_wifi_led "$board:fuchsia:status"
+   set_wifi_led "$board:pink:status"
+   ;;


Fuchsia is pink, please omit the LED colour rename.


+vocore2l)
+   set_wifi_led "$board:green:status"
;;
 w502u)
set_usb_led "$board:blue:usb"
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 80a3bc2c51..57245ef737 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -272,7 +272,8 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"1:lan" "2:lan" "3:lan" "4:lan" "5:wan" "0@eth0"
;;
-   vocore2)
+   vocore2|\
+   vocore2l)
ucidef_add_switch "switch0" \
"0:lan" "2:lan" "6t@eth0"
;;
diff --git a/target/linux/ramips/base-files/etc/diag.sh 
b/target/linux/ramips/base-files/etc/diag.sh
index 461f46c26b..aff27cb3c0 100644
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -228,7 +228,10 @@ get_status_led() {
status_led="vocore:green:status"
;;
vocore2)
-   status_led="$board:fuchsia:status"
+   status_led="$board:pink:status"
+   ;;
+   vocore2l)
+   status_led="$board:green:status"
;;
w306r-v20|\
witi|\
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index 87cb7ffb91..3738d8ead1 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -502,6 +502,9 @@ ramips_board_detect() {
*"VoCore2")
name="vocore2"
;;
+   *"VoCore2-Lite")
+   name="vocore2l"


Please use "vocore2lite".


+   ;;
*"VR500")
name="vr500"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index adad8dae75..a7958f3a19 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -147,6 +147,7 @@ platform_check_image() {
vocore-8M|\
vocore-16M|\
vocore2|\
+   vocore2l|\
vr500|\
w150m|\
w2914nsv2|\
diff --git a/target/linux/ramips/dts/VOCORE2.dts 
b/target/linux/ramips/dts/VOCORE2.dts
index 297cd1bb99..087d16ea69 100644
--- a/target/linux/ramips/dts/VOCORE2.dts
+++ b/target/linux/ramips/dts/VOCORE2.dts
@@ -1,64 +1,18 @@
 /dts-v1/;

-#include "mt7628an.dtsi"
-
-#include 
-#include 
+#include "VOCORE2.dtsi"

 / {
-   compatible = 

Re: [LEDE-DEV] [PATCH 2/3] ramips-mt7621: add GPIO-config for Ubiquiti-EdgeRouterX(-SFP)

[Mathias Kresin]

06.05.2017 14:31, Sven Roederer:

On Freitag, 5. Mai 2017 14:32:12 CEST Mathias Kresin wrote:

Is it necessary to control the GPIOs from userspace/via config files?
If not, add a gpio_export node to the dts and set the output value
this way [0].


> Or is there something better?

Yes there is. Please add a gpio-export node to the dts (see 
target/linux/ramips/dts/A5-V11.dts). It does basically the same but 
allows to set the polarity and uses the gpio-export,name for the actual 
export. And it doesn't add userspace stuff to the image which is 
included for all images.




To have it in userspace is the best (only?) option to enable / disable or
power-cycle the attached PoE-equipment.


The question is more or less whether it is necessary to disable PoE for 
the ports. The gpio-export node for example, is used in most cases for 
enabling something like usb power.


I have no strong opinion on this and I'll leave it up to you to add what 
you are the opinion is the best.


Mathias

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

Re: [LEDE-DEV] [PATCH 3/3] ramips-mt7621: add dts for UBNT-ERX-SFP

[Mathias Kresin]

06.05.2017 16:23, Sven Roederer:

On Freitag, 5. Mai 2017 14:34:18 CEST Mathias Kresin wrote:

+#include "mt7621.dtsi"
+
+/ {
+   model = "UBNT-ERX-SFP";
+
+   memory@0 {


In some of the other dts-files I found the "compatible"-property. Which is not
defined for this board.

should I include something like compatible = "ubiquiti,edgerouterx"; to the
dtsi-file?
And then consequently compatible = "ubiquiti,edgerouterx-sfp" to the UBNT-ERX-
SFP.dts?


Yes, please do it exactly this way.

Mathias

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

Re: [LEDE-DEV] [PATCH] imx6: add gw560x support

[Mathias Kresin]

05.05.2017 22:15, Tim Harvey:

Signed-off-by: Tim Harvey 


Hey Tim,

would you please include a short description about the hardware and how 
to install LEDE on the board in your commit message! Have a look at the 
recent board additions for some examples.


I prefer to have backports (even for device tree files) as patches in 
patches-*. But I've no strong opinion on this. But please mention in the 
commit message in case something is a backport.


Beside of that, look good to me.
Mathias



---
 .../linux/imx6/base-files/etc/board.d/02_network   |   1 +
 target/linux/imx6/base-files/lib/imx6.sh   |   5 +
 .../files-4.9/arch/arm/boot/dts/imx6dl-gw560x.dts  |  55 ++
 .../files-4.9/arch/arm/boot/dts/imx6q-gw560x.dts   |  59 ++
 .../arch/arm/boot/dts/imx6qdl-gw560x.dtsi  | 750 +
 target/linux/imx6/image/Makefile   |   4 +-
 ...-imx-add-gateworks-ventana-gw560x-support.patch |  18 +
 7 files changed, 891 insertions(+), 1 deletion(-)
 create mode 100644 
target/linux/imx6/files-4.9/arch/arm/boot/dts/imx6dl-gw560x.dts
 create mode 100644 
target/linux/imx6/files-4.9/arch/arm/boot/dts/imx6q-gw560x.dts
 create mode 100644 
target/linux/imx6/files-4.9/arch/arm/boot/dts/imx6qdl-gw560x.dtsi
 create mode 100644 
target/linux/imx6/patches-4.9/0002-arm-dts-imx-add-gateworks-ventana-gw560x-support.patch

diff --git a/target/linux/imx6/base-files/etc/board.d/02_network 
b/target/linux/imx6/base-files/etc/board.d/02_network
index fbe3eea..e315a48 100755
--- a/target/linux/imx6/base-files/etc/board.d/02_network
+++ b/target/linux/imx6/base-files/etc/board.d/02_network
@@ -13,6 +13,7 @@ board_config_update
 case "$board" in
 *gw51xx |\
 *gw52xx |\
+*gw560x |\
 *gw5904)
ucidef_set_interface_lan 'eth0'
;;
diff --git a/target/linux/imx6/base-files/lib/imx6.sh 
b/target/linux/imx6/base-files/lib/imx6.sh
index 8254cac..0e8c343 100755
--- a/target/linux/imx6/base-files/lib/imx6.sh
+++ b/target/linux/imx6/base-files/lib/imx6.sh
@@ -49,6 +49,11 @@ imx6_board_detect() {
name="gw553x"
;;

+   "Gateworks Ventana i.MX6 DualLite/Solo GW560X" |\
+   "Gateworks Ventana i.MX6 Dual/Quad GW560X")
+   name="gw560x"
+   ;;
+
"Gateworks Ventana i.MX6 DualLite/Solo GW5904" |\
"Gateworks Ventana i.MX6 Dual/Quad GW5904")
name="gw5904"
diff --git a/target/linux/imx6/files-4.9/arch/arm/boot/dts/imx6dl-gw560x.dts 
b/target/linux/imx6/files-4.9/arch/arm/boot/dts/imx6dl-gw560x.dts
new file mode 100644
index 000..21bdfaf
--- /dev/null
+++ b/target/linux/imx6/files-4.9/arch/arm/boot/dts/imx6dl-gw560x.dts
@@ -0,0 +1,55 @@
+/*
+ * Copyright 2017 Gateworks Corporation
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this file; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "imx6dl.dtsi"

Re: [LEDE-DEV] [PATCH 3/3] ramips-mt7621: add dts for UBNT-ERX-SFP

[Mathias Kresin]

2017-05-04 1:41 GMT+02:00 Sven Roederer :
> * use a copy and modify version of the  UBNT-ERX for the UBNT-ERX-SFP
> * define i2c-gpio via DTS 
> (Linux/Documentation/devicetree/bindings/i2c/i2c-gpio.txt)
> * also define PCA9555 for PoE-switching in DTS

Please, make sure to add a proper SoB line as described in "Submitting
patches": [1].

Also, would you please include in your commit message a short
description about the hardware and how to install LEDE on it? Have a
look at the recent ramips board additions for some examples[2].

Please merge all ubnt-erx-sfp related commits into one. They do not
really work on its own and it does not make any sense to split the
changes. Patch 1/3 for example adds the ubnt-erx-sfp image by using
the ubnt-erx dts. It is fixed later with an extra commit which is hard
to review.

I haven't checked how similar the ubnt-erx and ubnt-erx-sfp device
tree source files are. But it might be more elegant to move stuff
which is the same between both boards to a dtsi, include the dtsi for
the ubnt-erx* and add all missing stuff in the ubnt-erx-sfp dts.

Depending on what is really required, there might be the following
commits in the end:

- split ubnt-erx into dtsi
- add ubnt-erx poe passthrough gpios
- add ubnt-erx-stp support

Find more comments inline.

> ---
>  target/linux/ramips/dts/UBNT-ERX-SFP.dts | 121 
> +++
>  target/linux/ramips/image/mt7621.mk  |   2 +-
>  2 files changed, 122 insertions(+), 1 deletion(-)
>  create mode 100644 target/linux/ramips/dts/UBNT-ERX-SFP.dts
>
> diff --git a/target/linux/ramips/dts/UBNT-ERX-SFP.dts 
> b/target/linux/ramips/dts/UBNT-ERX-SFP.dts
> new file mode 100644
> index 000..808086a
> --- /dev/null
> +++ b/target/linux/ramips/dts/UBNT-ERX-SFP.dts
> @@ -0,0 +1,121 @@
> +#include 

Move this line below the include "mt7621.dtsi". Please include
dt-bindings/gpio/gpio.h here as well and keep alphabetical order.

Use the GPIO_ACTIVE_LOW and GPIO_ACTIVE_HIGH macros afterwards in
stead of 1 and 0 in the gpio parameters.

Check the recent ramips board additions for examples.

> +
> +/dts-v1/;
> +
> +#include "mt7621.dtsi"
> +
> +/ {
> +   model = "UBNT-ERX-SFP";
> +
> +   memory@0 {
> +   device_type = "memory";
> +   reg = <0x0 0x1000>;
> +   };
> +
> +   chosen {
> +   bootargs = "console=ttyS0,57600";
> +   };
> +
> +   gpio-keys-polled {
> +   compatible = "gpio-keys-polled";
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   poll-interval = <20>;
> +
> +   reset {
> +   label = "reset";
> +   gpios = < 12 1>;
> +   linux,code = ;
> +   };
> +   };
> +
> +   i2c-gpio {
> +   compatible = "i2c-gpio";
> +   gpios = < 3 0 /* sda */
> + 4 0 /* scl */
> +   >;
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   pca9555@25 {
> +   compatible = "pca9555";
> +   reg = <0x25>;
> +   };
> +   };
> +};
> +
> + {
> +   mtd-mac-address = < 0x22>;
> +};
> +
> + {
> +   status = "okay";
> +
> +   partition@0 {
> +   label = "u-boot";
> +   reg = <0x0 0x8>;
> +   read-only;
> +   };
> +
> +   partition@8 {
> +   label = "u-boot-env";
> +   reg = <0x8 0x6>;
> +   read-only;
> +   };
> +
> +   factory: partition@e {
> +   label = "factory";
> +   reg = <0xe 0x6>;
> +   };
> +
> +   partition@14 {
> +   label = "kernel1";
> +   reg = <0x14 0x30>;
> +   };
> +
> +   partition@44 {
> +   label = "kernel2";
> +   reg = <0x44 0x30>;
> +   };
> +
> +   partition@74 {
> +   label = "ubi";
> +   reg = <0x74 0xf7c>;
> +   };
> +};
> +
> + {
> +   state_default: pinctrl0 {
> +   gpio {
> +   ralink,group = "uart2", "uart3", "i2c", "pcie", 
> "rgmii2", "jtag";
> +   ralink,function = "gpio";
> +   };
> +   };
> +};
> +
> + {
> +   /* This board has 2Mb spi flash soldered in and visible
> +  from manufacturer's firmware.
> +  But this SoC shares spi and nand pins,
> +  and current driver does't handle this sharing well */
> +   status = "disabled";
> +
> +   m25p80@0 {
> +   #address-cells = <1>;
> +   #size-cells = <1>;
> +   compatible = "jedec,spi-nor";
> +   reg = <1>;
> +   spi-max-frequency = <1000>;
> +   m25p,chunked-io = <32>;
> +
> +   partition@0 {
> +

Re: [LEDE-DEV] [PATCH 2/3] ramips-mt7621: add GPIO-config for Ubiquiti-EdgeRouterX(-SFP)

[Mathias Kresin]

2017-05-04 1:41 GMT+02:00 Sven Roederer :
> define GPIOs for ubnt-erx and ubnt-erx-sfp
> ---
>  .../ramips/base-files/etc/board.d/03_gpio_switches | 28 
> ++
>  1 file changed, 28 insertions(+)
>  create mode 100755 
> target/linux/ramips/base-files/etc/board.d/03_gpio_switches
>
> diff --git a/target/linux/ramips/base-files/etc/board.d/03_gpio_switches 
> b/target/linux/ramips/base-files/etc/board.d/03_gpio_switches
> new file mode 100755
> index 000..21d1aa2
> --- /dev/null
> +++ b/target/linux/ramips/base-files/etc/board.d/03_gpio_switches
> @@ -0,0 +1,28 @@
> +#!/bin/sh
> +#
> +# Copyright (C) 2017 LEDE-project.org
> +#
> +
> +. /lib/functions/uci-defaults.sh
> +. /lib/ramips.sh
> +
> +board_config_update
> +
> +board=$(ramips_board_name)
> +
> +case "$board" in
> +ubnt-erx)
> +   ucidef_add_gpio_switch "poe_passthrough" "PoE Passthrough" "4"
> +   ;;
> +ubnt-erx-sfp)
> +   ucidef_add_gpio_switch "poe_power_port0" "PoE Power Port0" "496"
> +   ucidef_add_gpio_switch "poe_power_port1" "PoE Power Port1" "497"
> +   ucidef_add_gpio_switch "poe_power_port2" "PoE Power Port2" "498"
> +   ucidef_add_gpio_switch "poe_power_port3" "PoE Power Port3" "499"
> +   ucidef_add_gpio_switch "poe_power_port4" "PoE Power Port4" "500"
> +   ;;
> +esac
> +
> +board_config_flush

Is it necessary to control the GPIOs from userspace/via config files?
If not, add a gpio_export node to the dts and set the output value
this way [0].

Mathias

[0] 
https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/ramips/dts/A5-V11.dts;hb=ddbb036bbb8a1030dd8f6fae0004d390b5f2b8a5#l38

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

Re: [LEDE-DEV] [PATCH] ramips: add support for GL-inet GL-MT300N-V2

[Mathias Kresin]

2017-05-05 11:28 GMT+02:00 kysonlok :
> This patch adds supports for the GL-inet GL-MT300N-V2.
>
> Specification:
> - SoC: MediaTek MT7628AN
> - Flash: 16 MiB (W25Q128FVSG)
> - RAM: 128 MiB DDR
> - Ethernet: 1 x WAN (100 Mbps) and 1 x LAN (100 Mbps)
> - USB: 1 x USB 2.0 port
> - Button: 1 x switch button, 1 x reset button
> - LED: 3 x LEDS
> - UART: 1 x UART on PCB (JP1: 3.3V, RX, TX, GND)
>
> Installation through Luci:
> - The original firmware is LEDE, so both LuCI or sysupgrade can be used.
> - Do not keep settings, for sysupgrade please use the -n option.
>
> Installation through bootloader webserver:
> - Plug power and hold reset button until red LED blink to bright.
> - Install sysupgrade image using web interface on 192.168.1.1.
>
> Signed-off-by: kysonlok 

It seams to me you have missed my review of your patch. Would you
please fix the issues I've outlined in
http://lists.infradead.org/pipermail/lede-dev/2017-May/007293.html.

Mathias

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

Re: [LEDE-DEV] Proper way to deal with "dual firmware" ar71xx devices

[Mathias Kresin]

2017-04-23 20:40 GMT+02:00 Bjørn Mork :

Hello,

Many devices make use of "dual firmware" configurations, splitting the
available flash and allowing two complete and independent installations.
This works fine for devices like the Linksys WRT1900AC etc, where the
boot loader make sure the kernel command line "root=" parameter matches
the booted kernel.

It does not work so well with ar71xx devices like the Ubiquiti UniFi AC
Pro. The original firmware use this layout:

dev:size   erasesize  name
mtd0: 0006 0001 "u-boot"
mtd1: 0001 0001 "u-boot-env"
mtd2: 0079 0001 "kernel0"
mtd3: 0079 0001 "kernel1"
mtd4: 0002 0001 "bs"
mtd5: 0004 0001 "cfg"
mtd6: 0001 0001 "EEPROM"


The current LEDE images configure this as:
  MTDPARTS = 
spi0.0:384k(u-boot)ro,64k(u-boot-env)ro,7744k(firmware),7744k(ubnt-airos)ro,128k(bs)ro,256k(cfg)ro,64k(EEPROM)ro


Note that "kernel0" is statically mapped to "firmware", and that
"kernel1" (or "ubnt-airos") is made read-only.  This sort of works as
long as LEDE is installed on "kernel0". But LEDE/OpenWrt does its magic
partition splitting based of the "firmware" partifion name.  And it will
do this even if the currently booting LEDE kernel is located on
"ubnt-airos"/"kernel1".

Due to limited understanding of how the Ubiquiti U-Boot selects between
"kernel0" and "kernel1", there are instructions out there telling users
to try to install LEDE on both "kernel0" and "kernel1".  But what
happens if the boot loader is actually loading the "kernel1" image? We
will then have a system with the kernel loaded from "kernel1" but the
rootfs loaded from "kernel0".  This is bad.  When sysupgrading, the
image on "kernel0" (aka "firmare") is replaced, But the boot loader will
still continue to load the old LEDE kernel from "kernel1".  If you are
lucky, it will boot successfully using the new rootfs.  You can then use
the mtd-rw package to make "ubnt-airos" writeable and copy the new
kernel there.  Extremely confusing and unfriendly to users...

This should be fixed somehow.  But I don't know how.  The best would be
to make the kernel dynamically figure out which of the partitions it
booted from and then force the rootfs there.  But I don't know if this
can be done without the help of the boot loader?


Hey Bjørn,

I had a similar problem with the dual image feature of brnboot in 
lantiq. It resulted in the following two patches:


https://git.lede-project.org/d7438ce3152e2e0dc1678dcb24ca050dbc2733c8
https://git.lede-project.org/60ac4852745c69ae13a770dc343b648925b73ca2

Since lantiq uses the device tree it is a device tree focused solution. 
It is for sure not the holy grial in terms of reusability and there 
might be more elegant ways to do it. But it might give you an idea.


As there is no sysupgrade support for the board at all, I never had to 
think about ways to change the active partition bit from userspace. But 
as far as I understand your mail, replicating the dual boot feature in 
LEDE isn't your primary objective.


Mathias



smime.p7s
Description: S/MIME Cryptographic Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] ramips: Add support for GL-MT300N-V2

[Mathias Kresin]

Hey kysonlok,

thanks a lot for your contribution. Find my comments inline.

04.05.2017 08:41, kysonlok:

This patches adds support for GL-MT300N-V2 router.

Signed-off-by: kysonlok 


We have a realname policy for signed off by lines.


---
 target/linux/ramips/base-files/etc/board.d/01_leds |   1 +
 .../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/GL-MT300N-V2.dts   | 135 +
 target/linux/ramips/image/mt7628.mk|   8 ++
 6 files changed, 149 insertions(+)
 create mode 100644 target/linux/ramips/dts/GL-MT300N-V2.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 52542ec..101c1c2 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -186,6 +186,7 @@ fonera20n)
;;
 gl-mt300a|\
 gl-mt300n|\
+gl-mt300n-v2|\
 gl-mt750)
set_wifi_led "$board:wlan"
;;
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 80a3bc2..6af0065 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -156,6 +156,7 @@ ramips_setup_interfaces()
f5d8235-v2|\
gl-mt300a|\
gl-mt300n|\
+   gl-mt300n-v2|\
gl-mt750|\
hg255d|\
jhr-n805r|\
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index 87cb7ff..1e031cd 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -214,6 +214,9 @@ ramips_board_detect() {
*"GL-MT300N")
name="gl-mt300n"
;;
+   *"GL-MT300N-V2")
+   name="gl-mt300n-v2"
+   ;;
*"GL-MT750")
name="gl-mt750"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index adad8da..2c50c3c 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -64,6 +64,7 @@ platform_check_image() {
freestation5|\
gl-mt300a|\
gl-mt300n|\
+   gl-mt300n-v2|\
gl-mt750|\
hc5*61|\
hc5661a|\
diff --git a/target/linux/ramips/dts/GL-MT300N-V2.dts 
b/target/linux/ramips/dts/GL-MT300N-V2.dts
new file mode 100644
index 000..bf64c99
--- /dev/null
+++ b/target/linux/ramips/dts/GL-MT300N-V2.dts
@@ -0,0 +1,135 @@
+/dts-v1/;
+
+#include "mt7628an.dtsi"
+
+#include 
+#include 
+
+/{
+   compatible = "GL-MT300N-V2", "ralink,mt7620an-soc";


The compatible string is "vendor,boardname":

compatible = "gli,gl-mt300n-v2", "ralink,mt7620an-soc";


+   model = "GL-MT300N-V2";
+
+   chosen {
+   bootargs = "console=ttyS0,115200";
+   };
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x400>;
+   };
+
+   gpio-leds {
+   compatible = "gpio-leds";
+
+   usbpow {
+   label = "gl-mt300n-v2:usbpow";


Please add the led colour to the label. The format has to be 
device:colour:function.


I couldn't find any information about the gl-mt300n-v2, but I would be 
surprised if they dropped the lan LED and added a usb led instead. Would 
you please ensure that this LED is really meant to be used for usb.



+   gpios = < 11 1>;


Please use the GPIO_ACTIVE_LOW and GPIO_ACTIVE_HIGH macros provided by 
dt-bindings/gpio/gpio.h instead of 1 and 0 in the gpio parameters (as 
you have done it for the reset button).



+   };
+
+   wan {
+   label = "gl-mt300n-v2:wan";
+   gpios = < 11 1>;
+   };
+
+   wlan {
+   label = "gl-mt300n-v2:wlan";
+   gpios = < 12 1>;
+   };
+   };
+
+   gpio-keys {
+   compatible = "gpio-keys-polled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   poll-interval = <20>;
+
+   reset {
+   label = "reset";
+   gpios = < 6 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+
+   BIT_0 {


Typo? Could it be that this should be BTN_0 and BTN_1


+   label = "BIT_0";
+   gpios = < 0 1>;
+   linux,code = <0x100>;


Please use the BTN_0 and BTN_1 macro from


+   };
+
+   BIT_1 {
+   label = "BIT_1";
+   gpios = < 3 1>;
+  

Re: [LEDE-DEV] RFC: files included in initramfs images

[Mathias Kresin]

Hey Daniel, Hey Thomas,

following my toughs regarding backports of commits to stable.

04.05.2017 17:53, Daniel Golle:

When it came to backport this to lede-17.01 I noticed that several
boards have been added to master since and are not yet present in the
lede-17.01 branch. Also the ZBT WG3526 has been split-up into a
16MB flash and 32MB flash variant and Digineo AC1200 Pro has been
renamed/merged with ZBT-WG3625-16M.


The reason why I haven't merged the (ramips) commits to the stable 
branch is my understanding of the dot releases. From my point of view 
the dot releases are bugfix releases and I will not add new features or 
improvements as long as they do not fix bugs. Especially since the plan 
is to release a major version every six month.


But we do not have any written rules regarding backports and/or commits 
to stable branches. In the end, it is up to each developer to commit 
what he is the opinion is the best for a dot release.



Should I cherry-pick all added boards to lede-17.01, including the
rename of the Digineo device?
Or just backport the commit changing the default packages from master
and skip the boards which are not preset in lede-17.01 (which obviously
makes future backporting of the commits adding those boards harder)?


Most likely not really surprising, but I prefer to not backport any of 
the mentioned commits and focus on stabilisation/bugfixing instead.


Mathias

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

Re: [LEDE-DEV] [PATCH] ramips: add support for AsiaRF AWM688

[Mathias Kresin]

2017-04-10 11:46 GMT+02:00 Russell Senior :
>>2017-04-05 5:38 GMT+02:00 Russell Senior :
>>> +
>>> +/ {
>>> +   compatible = "mediatek,awm688", "mediatek,mt7628an-soc";
>>> +   model = "AsiaRF AWM688";
>>> +
>>> +   chosen {
>>> +   bootargs = "console=ttyS0,57600";
>>> +   };
>>> +
>>> +   aliases {
>>> +   serial0 = 
>>> +   };
>>> +
>>> +   memory@0 {
>>> +   device_type = "memory";
>>> +   reg = <0x0 0x400>;
>>> +   };
>>> +
>>> +   bootstrap {
>>> +   compatible = "mediatek,awm688";
>>> +
>>> +   status = "okay";
>>> +   };
>>> +
>>> +   gpio-leds {
>>> +   compatible = "gpio-leds";
>>> +
>>> +   wifi {
>>> +   label = "mediatek:orange:wifi";
>>> +   gpios = < 0 0>;
>>> +   default-state = "on";
>>
>>Why do you switch the led to default on? Could it be that the polarity
>>is wrong for this led (active low instead of active high) and you are
>>trying to switch the led to off?
>
> This is an artifact of the LinkIt7688 DTS.

Please get rid off all the copy/paste stuff like this led, the
bootstrap device tree node and the u-boot env tools. I'm quite sure
there are more copy/paste leftovers in the dts which I haven't noticed
during my brief review. Please take care of these as well to make sure
you don't need to send a v3.

Mathias

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

Re: [LEDE-DEV] [PATCH] ramips: add support for AsiaRF AWM688

[Mathias Kresin]

Hey Russell,

thanks a lot for your contribution. Find my comments inline.

2017-04-05 5:38 GMT+02:00 Russell Senior :
>
> Add initial support for an mtk7688 board from Asia RF.
>
> It boots, flashes and runs.
>
> Signed-off-by: Russell Senior 

As you wrote initial support, what does not work?

Would you please add a brief description of the hardware and outline how
LEDE can be installed on the board. Have a look at the recent ramips
board additions for some good examples.

> ---
>
> diff --git a/package/boot/uboot-envtools/files/ramips 
> b/package/boot/uboot-envtools/files/ramips
> index 3216b300c1..9327bcbcf4 100644
> --- a/package/boot/uboot-envtools/files/ramips
> +++ b/package/boot/uboot-envtools/files/ramips
> @@ -19,6 +19,7 @@ all0256n|\
>  all5002)
> ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x1" "0x1"
> ;;
> +awm688|\
>  br-6425|\
>  linkits7688|\
>  linkits7688d|\

Why is access to the u-boot env from userspace required?

> 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 7bdebbe97f..19ff14df83 100755
> --- a/target/linux/ramips/base-files/etc/board.d/02_network
> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
> @@ -44,6 +44,7 @@ ramips_setup_interfaces()
> all0256n|\
> all5002|\
> all5003|\
> +   awm688|\
> broadway|\
> dcs-930|\
> dcs-930l-b1|\
> diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
> b/target/linux/ramips/base-files/lib/ramips.sh
> index 786aecb99b..cd944ed207 100755
> --- a/target/linux/ramips/base-files/lib/ramips.sh
> +++ b/target/linux/ramips/base-files/lib/ramips.sh
> @@ -79,6 +79,9 @@ ramips_board_detect() {
> *"AWM003 EVB")
> name="awm003-evb"
> ;;
> +   *"AWM688")
> +   name="awm688"
> +   ;;
> *"BC2")
> name="bc2"
> ;;
> diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
> b/target/linux/ramips/base-files/lib/upgrade/platform.sh
> index 08fa45ad98..6360fe83a0 100755
> --- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
> +++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
> @@ -29,6 +29,7 @@ platform_check_image() {
> awapn2403|\
> awm002-evb|\
> awm003-evb|\
> +   awm688|\
> bc2|\
> broadway|\
> carambola|\
> diff --git a/target/linux/ramips/dts/AWM688.dts 
> b/target/linux/ramips/dts/AWM688.dts
> new file mode 100644
> index 00..1c5230ed84
> --- /dev/null
> +++ b/target/linux/ramips/dts/AWM688.dts
> @@ -0,0 +1,183 @@
> +/dts-v1/;
> +
> +#include "mt7628an.dtsi"
> +
> +#include 

Please include dt-bindings/gpio/gpio.h here as well and keep
alphabetical order.

Use the GPIO_ACTIVE_LOW and GPIO_ACTIVE_HIGH macros afterwards instead
of 1 and 0 in the gpio parameters.

Check the recent ramips board additions for examples.

> +
> +/ {
> +   compatible = "mediatek,awm688", "mediatek,mt7628an-soc";
> +   model = "AsiaRF AWM688";
> +
> +   chosen {
> +   bootargs = "console=ttyS0,57600";
> +   };
> +
> +   aliases {
> +   serial0 = 
> +   };
> +
> +   memory@0 {
> +   device_type = "memory";
> +   reg = <0x0 0x400>;
> +   };
> +
> +   bootstrap {
> +   compatible = "mediatek,awm688";
> +
> +   status = "okay";
> +   };
> +
> +   gpio-leds {
> +   compatible = "gpio-leds";
> +
> +   wifi {
> +   label = "mediatek:orange:wifi";
> +   gpios = < 0 0>;
> +   default-state = "on";

Why do you switch the led to default on? Could it be that the polarity
is wrong for this led (active low instead of active high) and you are
trying to switch the led to off?

> +   };
> +   };
> +
> +   gpio-keys-polled {
> +   compatible = "gpio-keys-polled";
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   poll-interval = <20>;
> +
> +   wps {
> +   label = "reset";
> +   gpios = < 6 1>;
> +   linux,code = ;
> +   };
> +   };
> +
> +   wgpio: gpio-wifi {
> +   compatible = "mediatek,gpio-wifi";
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   gpio-controller;
> +   #gpio-cells = <2>;
> +   };
> +};
> +
> + {
> +   state_default: pinctrl0 {
> +   gpio {
> +   ralink,group = "gpio";
> +   ralink,function = "gpio";
> +   };
> +
> +   perst {
> +   ralink,group = "perst";
> +   ralink,function = "gpio";
> +  

Re: [LEDE-DEV] [PATCH] ar8327: Add workarounds for AR8337 switch.

[Mathias Kresin]

25.03.2017 18:08, Vittorio Gambaletta (VittGam):

Backported from Code Aurora QSDK

Signed-off-by: Vittorio Gambaletta 


Please describe in the commit message what kind of issues need a 
workaround. Yes, I noticed the comments in the patch, but nevertheless 
it should go into the commit message.


IMHO the changes to the HOL register need an explanation. At least I've 
no idea what the magic values mean and what kind of issue is fixed by 
applying them.


Mathias

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

Re: [LEDE-DEV] [PATCH] ar71xx: change image version for ubiquiti devices

[Mathias Kresin]

03.03.2017 16:51, txt.file:

changes the image version from hardcoded OpenWrt to
$VERSION_DIST. AirOS shows a notification with the image version
during a firmware upgrade.

fixes #582

Signed-off-by: Matthias Fritzsche 
---
 target/linux/ar71xx/image/ubnt.mk | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/target/linux/ar71xx/image/ubnt.mk 
b/target/linux/ar71xx/image/ubnt.mk
index 7a1fc80..c633ca1 100644
--- a/target/linux/ar71xx/image/ubnt.mk
+++ b/target/linux/ar71xx/image/ubnt.mk
@@ -6,7 +6,7 @@
 # routerboard creates partitions out of the ubnt header
 define Build/mkubntimage
-$(STAGING_DIR_HOST)/bin/mkfwimage \
-   -B $(UBNT_BOARD) -v 
$(UBNT_TYPE).$(UBNT_CHIP).v6.0.0-OpenWrt-$(REVISION) \
+   -B $(UBNT_BOARD) -v 
$(UBNT_TYPE).$(UBNT_CHIP).v6.0.0-$(VERSION_DIST)-$(REVISION) \
-k $(IMAGE_KERNEL) \
-r $@ \
-o $@
@@ -19,7 +19,7 @@ define Build/mkubntimage-split
dd if=$@ of=$@.old1 bs=1024k count=1; \
dd if=$@ of=$@.old2 bs=1024k skip=1; \
$(STAGING_DIR_HOST)/bin/mkfwimage \
-   -B $(UBNT_BOARD) -v 
$(UBNT_TYPE).$(UBNT_CHIP).v6.0.0-OpenWrt-$(REVISION) \
+   -B $(UBNT_BOARD) -v 
$(UBNT_TYPE).$(UBNT_CHIP).v6.0.0-$(VERSION_DIST)-$(REVISION) \
-k $@.old1 \
-r $@.old2 \
-o $@; \
@@ -28,7 +28,7 @@ endef

 define Build/mkubntimage2
-$(STAGING_DIR_HOST)/bin/mkfwimage2 -f 0x9f00 \
-   -v $(UBNT_TYPE).$(UBNT_CHIP).v6.0.0-OpenWrt-$(REVISION) \
+   -v $(UBNT_TYPE).$(UBNT_CHIP).v6.0.0-$(VERSION_DIST)-$(REVISION) 
\
-p jffs2:0x5:0xf6:0:0:$@ \
-o $@.new
@mv $@.new $@



Your patch doesn't apply:

wget -q -O- "http://patchwork.ozlabs.org/patch/735156/mbox/; | git am

Applying: ar71xx: change image version for ubiquiti devices
error: patch failed: target/linux/ar71xx/image/ubnt.mk:6
error: target/linux/ar71xx/image/ubnt.mk: patch does not apply
Patch failed at 0001 ar71xx: change image version for ubiquiti devices

Please consider using git send-mail for submissions to prevent all kinds 
of whitespace damages and unexpected linebreaks.


Mathias

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

Re: [LEDE-DEV] NAND JFFS2 question

[Mathias Kresin]

08.03.2017 23:01, hams...@freenet.de:

Hi!

I currently work to assembly a fullimage.img for the Easybox 904xdsl.
Actually there are some differences to upstream made by the vendor.
I take over some code and now I'm able to update the firmware, or at
least the kernel via the recovery method within the uboot.

As I wrote, the kernel and also the rootfs is flashed without errors.
When I try to boot the image, or mount the partition it is not possible
due some strange ECC errors.

So I did some investigations: When I boot into the target system
via sdcard as rootfs and then I perform a


 flash_eraseall /dev/mtd1
 nand_write /dev/mtd1 /root/image.jffs2

 mkdir /tmp/disk
 mount -t jffs2 /dev/mtdblock1 /tmp/disk




Using jffs2 on NAND flash isn't the best idea. jffs2 doesn't work that 
good with NAND flash. Use ubi instead!


I worked on the Easybox 904xdsl as well but stopped after realising that:

- Arcadian decided to use their own bad block table patterns instead of 
the ones which are used by the kernel and an unmodified u-boots. Means a 
kernel patch is required just for this board.


- to support the wireless a complete protocol needs to be reverse 
engineered and a lot of missing code needs to be added to the rt2x00 driver


The rt3883 wireless chip of the Easybox 904xdsl is not a usual wireless 
chip, it is a full SoC which is supported as own suptarget in LEDE 
(ramips/rt3883). In case of the 904 a complete realtime operating system 
is uploaded/runs on the rt3883 instead of a "normal" Operating System 
like OpenWrt/LEDE. Since it is a full SoC it has subsystems like PCI and 
so on. The rt5392 wireless is attached via PCI to the rt3883 SoC.


The internal ethernet of the rt3883 SoC is connected to the internal 
lantiq switch via MDIO/RGMII. The whole communication and configuration 
of the rt3883/rt5392 is done via a proprietary protocol, which is based 
on ethernet frames. The way the protocol really works is unknown and 
there is no support for that protocol in the rt2x00 wireless driver.


Vitaly Chekryzhev send patch to add MDIO support to the rtl8367b used by 
the 904 [0]. This patch wasn't merged since it caused issues. My last 
update about this was that he is going to fix the issues and will send a 
new patch.


Long story short, I got the following working:

- LAN
- ethernet WAN (the DSL port is ethernet and dsl at the same time)
- LEDs
- Buttons
- Flash without bad block support
- usb port on the back
- ram boot u-boot for recovery

You can find my code at https://github.com/mkresin/lede/tree/904xdsl.

Feel free to use it or to rebase your work on it. Would be nice if you 
publish what you have so far as well.


Supporting the build in display should be possible. The driver for the 
display is in the staging section of the kernel for a while now [1].


Mathias

[0] https://github.com/lede-project/source/pull/537
[1] 
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/staging/fbtft?h=linux-4.4.y


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

Re: [LEDE-DEV] using sata-port-specific led triggers

[Mathias Kresin]

08.03.2017 22:59, Alberto Bursi:

Hi, I'm trying to use the functionality added by this patch [1] (it
should generate different led triggers for each Sata port) for a few
kirkwood device that have multiple Sata Leds.

This patch is currently used only by some oxnas NAS devices, that seem
to have not been fully ported to device tree.

After reading its description and the oxnas files I have added

CONFIG_ARCH_WANT_LIBATA_LEDS=y
CONFIG_ATA_LEDS=y

to the target/linux/kirkwood/config-4.4

but after I made a distclean, recompiled and booted the initramfs image,
I can't see any sata trigger
---
root@LEDE:/# cat
/sys/devices/platform/gpio-leds/leds/nsa310:green:esata/trigger
[none] nand-disk timer default-on netdev usbport
---

Does anyone have some ideas on why this does not work?

[1]
https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/generic/patches-4.9/834-ledtrig-libata.patch


In my opinion it would makes more sense to switch kirkwood to kernel 4.9 
and use the upstream LED Disk Trigger [0][1] which was introduced with 
kernel 4.8.


Mathias


[0] https://git.lede-project.org/3d0bd150565767f395eae333bcbca7bbe89edf48
[1] https://git.lede-project.org/2261c9cc7715e6d590952989ebef96e08cc019fc

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

Re: [LEDE-DEV] [PATCH] ar71xx: change image version to LEDE for ubiquiti devices

[Mathias Kresin]

2017-03-03 14:52 GMT+01:00 txt.file :
> ar71xx: change image version to LEDE for ubiquiti devices
>
> Signed-off-by: txt.file 

Fullname in Signed-off-by please.

Please add a commit message. Describe where the change is visible and
mention the feature request you've creating in flyspray, similar to
how it's done in
https://git.lede-project.org/9e740fa5a51fee102671209273f01798ea1d7694.

> ---
>  target/linux/ar71xx/image/ubnt.mk | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/target/linux/ar71xx/image/ubnt.mk 
> b/target/linux/ar71xx/image/ubnt.mk
> index 7a1fc80..cf6a70c 100644
> --- a/target/linux/ar71xx/image/ubnt.mk
> +++ b/target/linux/ar71xx/image/ubnt.mk
> @@ -6,7 +6,7 @@
>  # routerboard creates partitions out of the ubnt header
>  define Build/mkubntimage
> -$(STAGING_DIR_HOST)/bin/mkfwimage \
> -   -B $(UBNT_BOARD) -v 
> $(UBNT_TYPE).$(UBNT_CHIP).v6.0.0-OpenWrt-$(REVISION) \
> +   -B $(UBNT_BOARD) -v 
> $(UBNT_TYPE).$(UBNT_CHIP).v6.0.0-LEDE-$(REVISION) \

Replacing one hardcoded value with another hardcoded value doesn't
seam to me the smartest idea. Please use the VERSION_DIST variable
instead.

Mathias

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

Re: [LEDE-DEV] [PATCH odhcpd] dhcpv6-ia: Check lockf return value

[Mathias Kresin]

2017-02-28 6:53 GMT+01:00 Florian Fainelli :
> Signed-off-by: Florian Fainelli 
> ---
>  src/dhcpv6-ia.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/src/dhcpv6-ia.c b/src/dhcpv6-ia.c
> index 888634fe1f29..fb5044884441 100644
> --- a/src/dhcpv6-ia.c
> +++ b/src/dhcpv6-ia.c
> @@ -242,8 +242,12 @@ void dhcpv6_write_statefile(void)
> int fd = open(config.dhcp_statefile, O_CREAT | O_WRONLY | 
> O_CLOEXEC, 0644);
> if (fd < 0)
> return;
> -
> -   lockf(fd, F_LOCK, 0);
> +   int ret;
> +   ret = lockf(fd, F_LOCK, 0);
> +   if (ret < 0) {
> +   close(fd);
> +   return;
> +   }
> if (ftruncate(fd, 0) < 0) {}
>
> FILE *fp = fdopen(fd, "w");

Hey Florian,

would you please add a commit message which describes why this patch
is required, respectively what issue gets fixed with the patch.

I've added Hans to CC since he is the one working on odhcpd work at the moment.

Mathias

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

Re: [LEDE-DEV] [RFC] ipq806x: Add USB Type Selector for R7500

[Mathias Kresin]

2017-02-27 13:34 GMT+01:00 Thomas Reifferscheid :
> The patch enables the primary USB port on R7500. Because of the
> missing general IPQ8064x TCSR initialisation functions a workaround
> using pinctrl,single was chosen. It allows us to set 1a4000b0 from
> .0010 to .0011 thus enabling the primary USB port - prior
> to the dwc3-phy initialisation. Needs to be reworked once Qualcomm
> adds TCSR initialisation functionality from their 3.x kernel into 4.x
> kernels.
>
> The patch fixes FS#497 and partially backs off
> 45bf3d4f248ea2d770a1625fdee8899dc40329af which had the right idea but
> was missing the syscon-tcsr handler - which by the time of the upstream
> patch attempt (January 2015) was trying to set the TCSR USB Type
> selector at the wrong part of the kernel.
>
> Signed-off-by: Thomas Reifferscheid 
> ---
>  ...ipq806x-add-usbtypesel-required-for-r7500.patch | 56 
> ++
>  1 file changed, 56 insertions(+)
>  create mode 100644 
> target/linux/ipq806x/patches-4.4/716-ipq806x-add-usbtypesel-required-for-r7500.patch
>
> diff --git 
> a/target/linux/ipq806x/patches-4.4/716-ipq806x-add-usbtypesel-required-for-r7500.patch
>  
> b/target/linux/ipq806x/patches-4.4/716-ipq806x-add-usbtypesel-required-for-r7500.patch
> new file mode 100644
> index 000..4927708
> --- /dev/null
> +++ 
> b/target/linux/ipq806x/patches-4.4/716-ipq806x-add-usbtypesel-required-for-r7500.patch
> @@ -0,0 +1,56 @@
> +diff -Naur a/arch/arm/boot/dts/qcom-ipq8064.dtsi 
> b/arch/arm/boot/dts/qcom-ipq8064.dtsi
> +--- a/arch/arm/boot/dts/qcom-ipq8064.dtsi  2017-02-27 12:34:58.669161969 
> +0100
>  b/arch/arm/boot/dts/qcom-ipq8064.dtsi  2017-02-27 12:40:51.253172676 
> +0100
> +@@ -626,6 +626,13 @@
> +   reg = <0x1a40 0x100>;
> +   };
> +
> ++usbtypesel: pinmux@1a4000b0 {
> ++compatible = "pinctrl-single";
> ++pinctrl-single,register-width = <32>;   /* u32  
> */
> ++pinctrl-single,function-mask = <0x03>;  /* only 
> allow to set the 2 LSBs */
> ++reg = <0x1a4000b0 0x04>;/* u32  
> */
> ++};
> ++
> +   lcc: clock-controller@2800 {
> +   compatible = "qcom,lcc-ipq8064";
> +   reg = <0x2800 0x1000>;
> +@@ -685,8 +692,6 @@
> +   clocks = < USB30_0_MASTER_CLK>;
> +   clock-names = "core";
> +
> +-  syscon-tcsr = < 0xb0 1>;
> +-
> +   ranges;
> +
> +   status = "disabled";
> +@@ -709,8 +714,6 @@
> +   clocks = < USB30_1_MASTER_CLK>;
> +   clock-names = "core";
> +
> +-  syscon-tcsr = < 0xb0 0>;
> +-
> +   ranges;
> +
> +   status = "disabled";
> +diff -Naur a/arch/arm/boot/dts/qcom-ipq8064-r7500.dts 
> b/arch/arm/boot/dts/qcom-ipq8064-r7500.dts
> +--- a/arch/arm/boot/dts/qcom-ipq8064-r7500.dts 2017-02-27 12:35:08.693162274 
> +0100
>  b/arch/arm/boot/dts/qcom-ipq8064-r7500.dts 2017-02-27 12:35:12.677162395 
> +0100
> +@@ -131,6 +131,17 @@
> +   status = "ok";
> +   };
> +
> ++pinmux@1a4000b0 {
> ++pinctrl-names = "default";
> ++pinctrl-0 = <_pins>;
> ++
> ++board_pins: pinmux_board_pins {
> ++pinctrl-single,pins = <
> ++0x00 0x03 /* 
> IPQ_TCSR_USB_CONTROLLER_TYPE_SEL TCSR_USB_SELECT_USB3_DUAL */
> ++>;
> ++};
> ++};
> ++
> +   phy@100f8800 {  /* USB3 port 1 HS phy */
> +   status = "ok";
> +   };

In my opinion it is a hack/workaround for missing kernel code. The
TCSR isn't related to the pinctrl/pinmux and you are only using
pinctrl-single since it allows you to manipulate the register (or
better any register) you are interested in.

Mathias.

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

Re: [LEDE-DEV] [PATCH] BT Home Hub 5A: configure Red Ethernet as DMZ interface (FS#490) and fix Red Ethernet switch port (FS#390)

[Mathias Kresin]

18.02.2017 19:05, Felix Fietkau:

On 2017-02-18 16:57, Mathias Kresin wrote:

@Felix: Would you please do a review of my changes. You added the
function in question with c536da3 "lantiq: add VLAN handling fixes to
xrx200 ethernet driver" but unfortunately without commit message.

I'm not sure about the purpose of the introduced function or which
(reproducible) issue gets fixed with the function. Might be that there
is some kind of logic bug in the function that I workaround for
broadcast packages now. The best case would be if you only missed that
is_multicast_ether_addr() is true for the broadcast address as well and
the function was never intended to handle broadcast packages.

This function actually was intended to handle broadcast packets, and in
the tests that I made back when I wrote the patch, it resolved an issue
pretty much like you're describing.

So the patch in your staging tree which adds the is_broadcast_ether_addr
check is wrong, and we need to look into why the portmap feature for
multicast packets doesn't work properly.

If you can reproduce the issue, please add a printk to show the data of
the special tag for packets which are leaking onto the wrong vlan, as
well as the switch configuration and the values of hw->vlan_port_map.


Hey Felix,

here are the requested printks:

special tag pre multicast cond:  0x0201
special tag post multicast cond: 0x0200c0af
special tag final:   0x0200c0ef

I observed leaking spanning tree protocol packages as well, which made 
it obvious that my patch doesn't properly fix the issue.


It should be fairly easy to reproduce the issue. Create two vlans, ping 
a not assigned ipv4 address in one of the vlans ipv4 subnets to force 
the arp packages => arp request is send to both vlans/all ports. The STP 
packages leak to the wan interface as soon as STP is enabled for the lan 
bridge.


As soon as I remove the whole "is multicast" condition the special tag 
variable has the following values:


special tag pre multicast cond:  0x0201
special tag post multicast cond: 0x0201
special tag final:   0x026f

and I'm no longer able to observe any package leakage. I've tested with 
local broadcast (ARP) and with STP packages. To test whether this change 
causes package leaks for external send packages, I've send ARP packages 
and IGMPv3 packages from an client to the router. But still no package 
leakage.


I've reverted my setup to have the lantiq,wan eth1 interface again and 
even in this setup I wasn't able cause package leakage between vlans 
with the whole "is multicast" condition removed.


Mathias

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

Re: [LEDE-DEV] Is there a Image for TP-Link TL-WA854RE (WiFi Range Extender) ?

[Mathias Kresin]

19.02.2017 13:10, Alberto Bursi:

After Mathias's commit (as noted by other mails above) the devices we
are talking about have wifi disabled by default but you can enable it
with the wps button.
https://github.com/lede-project/source/commit/bcfbeae79f799cf1087d692e4869589eb20d2080

Imho makes no sense as in most cases you will have to configure them
anyway to be of any use (you can't just place them in a network with
default config as they lack a ethernet port), so this "wifi off by
default" and "remapping wps button to rfkill" imho is only an annoyance
and removal of a potentially useful button that could be used for other
things (enabling/disabling something else with scripts after user setup).


I'm still the opinion that bringing up an unencrypted wireless without 
user interaction is really bad idea.


The commit fixed the following problem: A user flashes one of the 
mentioned devices and is not aware that the flash is finished or (s)he 
get distracted in between. During this time period anyone can connect to 
the AP and can do harmful things.


My assumption is that if the user has to proactive enable the wireless 
(s)he will properly configure the wireless afterwards.


What you are describing as annoyance is from my point of view a 
protection. It is the usual trade-off between security and usability.


Mathias

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

Re: [LEDE-DEV] [PATCH] BT Home Hub 5A: configure Red Ethernet as DMZ interface (FS#490) and fix Red Ethernet switch port (FS#390)

[Mathias Kresin]

17.02.2017 11:42, Mauro Mozzarelli:

The BT Home Hub routers described in the scenario(s) below are connected
also on the LAN side.

I ran further tests in the first SCENARIO (Red Ethernet as eth0.2)
monitoring the red Ethernet WAN end with wireshark and I saw arp
requests coming from the Red Ethernet that have both mac address and IP
that belong to the LAN port. I saw also arp requests with the correct
mac and IP from the Red Ethernet, but these requests did not get a reply
when the destination was another BT Home Hub 5 with the same
configuration (and only in that case). Both routers were on the same
subnets on LAN on the Yellow switch and WAN on the Red Ethernet.

This does not happen with the unmodified code where the Red Ethernet is
configured as eth1.2.

It looks like the Ethernet ports get into an identity crisis with the
patch.


So what you are length trying to describe is that ARP packages from the 
router are send to all vlans, right?


That bug isn't strictly related to my patch, it is just that my changes 
make the bug more obvious.


I added "lantiq: fix arp package leaking in xrx200 ethernet driver" to 
my staging tree to fix this issue as well. Would you please add this 
patch to your tree and test if it fixes the ARP package leakage for you. 
A word of warning, it might be that the patch introduces new issues.


@Felix: Would you please do a review of my changes. You added the 
function in question with c536da3 "lantiq: add VLAN handling fixes to 
xrx200 ethernet driver" but unfortunately without commit message.


I'm not sure about the purpose of the introduced function or which 
(reproducible) issue gets fixed with the function. Might be that there 
is some kind of logic bug in the function that I workaround for 
broadcast packages now. The best case would be if you only missed that 
is_multicast_ether_addr() is true for the broadcast address as well and 
the function was never intended to handle broadcast packages.


Mathias

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

Re: [LEDE-DEV] [PATCH] BT Home Hub 5A: configure Red Ethernet as DMZ interface (FS#490) and fix Red Ethernet switch port (FS#390)

[Mathias Kresin]

12.02.2017 17:40, Mauro Mozzarelli:

You are correct that the name does not matter, however if we have
routers already configured to associate the xDSL or Ethernet to WAN,
when we flash the new firmware we will have to reconfigure them to
rename the device. This is all good if the routers are physically there,
but when the routers are in remote unmanaged locations (like I have) it
becomes a problem. Renaming the interface is a small thing, but it will
impact many end users. I advocate to maintain WAN for xDSL out of my use
case interest and also because personally I think an xDSL is truly a WAN
interface whilst an Ethernet can be anything.


Please keep in mind that your existing config is not touched and the wan 
network still exists with my patches applied. I fail to see how it 
should break existing xDSL configs.


But you are right, the ethernet wan config will most likely not work any 
longer for people who managed to workaround all the outlined issues. But 
the same applies to your patch, since you are moving the ethernet wan 
from eth1 to eth0 as well. Lets hope that only the minority of the uses 
managed to configure a working ethernet wan.


Mathias

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

Re: [LEDE-DEV] [PATCH] BT Home Hub 5A: configure Red Ethernet as DMZ interface (FS#490) and fix Red Ethernet switch port (FS#390)

[Mathias Kresin]

12.02.2017 15:55, Felix Fietkau:

@Mathias: could you perhaps refactor the commits to put the wan->xwan
rename *after* the ethernet port VLAN change?
I'm also a bit sceptical about the interface rename and would like to
discuss this further, but I think the VLAN change is important enough to
get it in the tree soon.


I'm not entirely sure if I got your concerns right.

The overall objective is to have an out of the box usable ethernet wan 
port beside the xdsl wan. My approach is to use the wan network name for 
ethernet wan ports only. A few month ago, we had already a discussion 
about renaming wan to ewan to make clear that it is the ethernet wan 
network. But I was the only one who was the opinion that it was a good 
idea and I discarded this approach.


The xwan network is intended to be used for router having an ethernet 
wan port and a 3G/4G modem as well.


None of the commits should break anything. The xwan network has the same 
default firewall settings as the wan network. In the end it doesn't 
really matter to which network an interface belongs. It should work the 
same way for both. Existing configs should work as before, since the it 
isn't really a rename of the wan network. I just add a new network and 
old configs would use the still existing wan network.


It is quite unlikely that the vlan change breaks anything. The default 
vlan config is only changed for devices which are having the lantiq,wan 
device tree property. The port with this dt property is exposed as eth1 
but not configured/considered by default in any way.


It is even more worse. The eth1 interface can not be used as it is. Due 
to xrx200 switch driver oddities, the lantiq,wan interface gets the vlan 
2 assigned without being mentioned in ucidef_add_switch. If the user 
wants to use this interface (s)he need to add a not that obvious 
configuration (eth1.2 instead of eth1). To use a different vlan than 2 
for the lantiq,wan interface, the user needs to change the default vlan 
config despite the lantiq,wan interface doesn't look like related to the 
switch config (eth1 instead of eth0.n).


I'm fine to discuss any ideas to fix/workaround the limitations. I have 
this commit in my staging tree since a few months and so far I have no 
idea how to fix/workaround the limitations in a better way.


Mathias

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

Re: [LEDE-DEV] [PATCH] BT Home Hub 5A: configure Red Ethernet as DMZ interface (FS#490) and fix Red Ethernet switch port (FS#390)

[Mathias Kresin]

11.02.2017 18:55, Mauro M.:

This proposed patch applies to BT Home Hub 5 Type A and:

1) it includes configuration for the Red Ethernet port as an additional
"dmz" interface (feature request FS#490)


NAK.

It's a WAN port and not a DMZ port. It should be used by default as WAN 
port. If you need it as DMZ port, feel free to add your own _local_ 
configuration.



2) it fixes FS#390 providing the ability to associate port 5 to the main
switch VLAN.


Looks exactly like one part of the changes I've in my staging tree to 
which I pointed you to. Or to be more clear, thanks for copying my code 
without mention the author.


Consider your patch as rejected. I pointed you to the commits in my 
staging tree which are properly fixing the issues you are seeing and 
some others you are not aware of.


I can only please you once more (the third time?) to test my staging 
tree as it is and report if there are still issues left or new issues 
introduced.


Mathias

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

Re: [LEDE-DEV] [PATCH v2] ramips: add support for RATOC REX-WIFISD2

[Mathias Kresin]

28.01.2017 17:03, FUKAUMI Naoki:

diff --git a/target/linux/ramips/image/mt7620.mk 
b/target/linux/ramips/image/mt7620.mk
index 50eae2f..0728d93 100644
--- a/target/linux/ramips/image/mt7620.mk
+++ b/target/linux/ramips/image/mt7620.mk
@@ -465,3 +465,13 @@ define Device/kng_rc
zyimage -d 8997 -v "ZyXEL Keenetic Viva"
 endef
 TARGET_DEVICES += kng_rc
+
+define Device/rex-wifisd2
+  DTS := REX-WIFISD2
+  IMAGES := kernel.bin rootfs.bin
+  IMAGE/kernel.bin := append-kernel
+  IMAGE/rootfs.bin := append-rootfs | pad-rootfs
+  DEVICE_TITLE := RATOC REX-WIFISD2
+  DEVICE_PACKAGES := kmod-usb2 kmod-usb-ohci
+endef
+TARGET_DEVICES += rex-wifisd2


Please add support for a sysupgrade image as well. Have a look at 
platform_do_upgrade_combined() in 
target/linux/ar71xx/base-files/lib/upgrade/platform.sh for an example on 
how to do it.


Mathias

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

Re: [LEDE-DEV] FS#490 - BT Home Hub 5 Ethernet WAN Port configuration

[Mathias Kresin]

2017-02-10 14:01 GMT+01:00 Mauro M. :
> In response to Mathias:
>
>
> Let's have a look at the use cases for the Red Ethernet Port:
>
> 1) Classic case: Internet Home user with xDSL WAN + Wired and Wireless
> Devices
>
> SCENARIO: In this case my WAN is the xDSL port, my router has 4 Ethernet
> (yellow) ports, but I have 5 devices, so I want to BRIDGE my Red Ethernet to
> extend the available Yellow Ethernet (LAN) ports
>
> STATUS: this does not work today, see FS#390
>
>
> 2) Small Office User with xDSL and Fixed IP Subnet
>
> SCENARIO: In this case I have to disable Masquerading for my servers on the
> subnet to be addressable, also in this use case scenario I have 5 or more
> wired servers and I want to extend my switch to bridge the Red Ethernet port
>
> STATUS: as above this does not work today FS#390
>
>
> 3) Small Office User Intranet: this extends SCENARIO 2
>
> SCENARIO: I use a second router, the Red Ethernet (that I name "ewan") is
> connected to my router at (2) and is assigned a fixed IP on the subnet. The
> Yellow Ethernet switch is bridged to WiFi as "LAN". The firewall is
> configured to SNAT LAN to EWAN.
>
> STATUS: today this works by editing /etc/board.json to add port 5 to the
> switch, adding a new VLAN to Switch0 to cover port 5, creating a new network
> interface EWAN. However it works only if I create a bridge br-ewan and I add
> eth1.2 to it, it does not work if I configure eth1.2 directly to EWAN. I
> would like eth1.2 to be available in the list of interfaces (now I have to
> "know" that it exists and I have to configure it manually). Newbies might
> bang their head trying to use eth0.2 which is created by the additional
> VLAN, but it does not work.
>
>
> 4) Small Office Multi Wan: this extends SCENARIO 2 and 3
>
> SCENARIO: I have 2 xDSL WANs, one is as at (2), the second is an xDSL. The
> WAN port on my router is  configured as ADSL with pppoa-wan/pppoe-wan. The
> EWAN is connected to a router with Internet access and is assigned a fixed
> WAN IP.
>
> STATUS: as per SCENARIO 3, the Red Ethernet is configured manually by
> editing /etc/board.json
>
>
> 5) WiFi repeater: I configure the router just as a WiFi repeater, I need
> extra wired ports and I want to bridge the Red Ethernet to my LAN
>
> STATUS: as per SCENARIO 1 and 2
>
>
> 6) Home or Office user with separate xDSL Modem
>
> SCENARIO: I have an xDSL modem and I want to use pppoe over the Red Ethernet
>
> STATUS: I have never tried this scenario, but I believe this is what is
> covered by the default configuration on most routers with Ethernet WAN (I
> wonder why since I find this the least useful use case) and thus it is
> supposed to work
>
>
> SCENARIO 3 and 4 describe what are my current use cases
>
> In my 2 use cases it does not really matter whether the Red Ethernet is
> recognized as WAN. In case 3 it is sufficient that it is configurable with
> an IP, thus, whatever the name we give the interface, I would like it to
> appear by default on a fresh firmware install. To support CASES 1, 2 and 5,
> where I want to bridge my Red Ethernet to extend the ports on the switch, I
> need this to work (FS#390)
>
> I hope this helps.

No it doesn't.

What I wrote is that in case you already have a patch to fix the
issue, you should submit your patch instead of attaching it to a bug
report/feature request. If you're unsure about your approach, you
should send your patch and ask for feedback. What I not wrote is that
you should send an extended version of your bugreport/feature request
to the mailing list. I'm in doubt that anyone then me understands what
you are talking about.

But it seams to me you read only half of my response. I wrote that
I've already a fix for FS#390 and FS#490 in my staging tree and I
asked you to test my commits and send _me_ feedback via mail.

Mathias

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

Re: [LEDE-DEV] [PATCH] ramips: fix AR670W partition alignment

[Mathias Kresin]

05.02.2017 10:15, John Crispin:



On 05/02/2017 09:59, Claudio Leite wrote:

mtdsplit_lzma requires that the rootfs be aligned to a block boundary.
Pad the kernel partition to make this so.

Signed-off-by: Claudio Leite 
---
 target/linux/ramips/image/rt288x.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/ramips/image/rt288x.mk 
b/target/linux/ramips/image/rt288x.mk
index 4a0d6d4..86a5063 100644
--- a/target/linux/ramips/image/rt288x.mk
+++ b/target/linux/ramips/image/rt288x.mk
@@ -14,7 +14,7 @@ define Device/ar670w
   BLOCKSIZE := 64k
   DEVICE_TITLE := Airlink AR670W
   IMAGE_SIZE := $(ralink_default_fw_size_4M)
-  KERNEL := $(KERNEL_DTB)
+  KERNEL := $(KERNEL_DTB) | pad-to $$(BLOCKSIZE)
   IMAGES += factory.bin
   IMAGE/factory.bin := $$(sysupgrade_bin) | check-size (IMAGE_SIZE) | \
wrg-header wrgn16a_airlink_ar670w



Hi

although technically correct, the lzma splitter needs to be fixed to not
have this requirement, instead of adding these patches for all boards.
there is no need for any padding beyond 4byte padding.


I'm in doubt that the lzma splitter can be fixed.

The dependency to align the rootfs isn't specific to the lzma splitter. 
mtd_find_rootfs_from() in mtdsplit.c uses the erase block size as step size.


For the other splitter an not erase block size aligned rootfs works only 
because the headers provide informations about the kernel size and we 
can pass the kernel size as offset to mtd_find_rootfs_from() to prevent 
stepping over the mtd.


But the lzma header doesn't provide any informations about 
kernel/compressed size. Only the uncompressed size is stored in the 
header. According to the LZMA SDK, the LZMA decoder simply stops 
decompressing as soon as the amount of decompressed data matches the 
value stored in the header.


The only fix I can think of, would be to change the step size in 
mtd_find_rootfs_from() to 1 byte. But that would introduce a huge 
performance penalty.


Hopefully I missed the obvious solution for the problem.

Mathias

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

Re: [LEDE-DEV] [PATCH v2] ramips: Add support for Sanlinking D240

[Mathias Kresin]

2017-02-03 11:49 GMT+01:00 Kristian Evensen :
> Hi
>
> On Fri, Feb 3, 2017 at 11:02 AM, Piotr Dymacz  wrote:
>> Hi Kristian,
>>
>> My two cents: the general convention for board name is to not include
>> the manufacturer name (Sanlinking here).
>> As you can see, (almost) all other boards follow this rule, so please
>> use "d240" instead of "sanlinking-d240" (also for dts filename).
>>
>
> I have no strong feelings for the manufacturer name, so I will remove
> it if that is what it takes to get the patch accepted. However, I can
> easily imagine a second manufacturer naming their device something
> something D240, so perhaps shortening the name to for example SL- is a
> good compromise between the two?

I'm for using SL-D240. I share Kristians concerns about possible name
collisions in targets supporting a lot of boards like ar71xx and
ramips. Piotr, are fine with SL-D240?

Kristian, if you send a v3, please add some information on how to
install LEDE to the Sanlinking D240 to the commit message. Have a look
at https://git.lede-project.org/fd62fa752bbff9ae5277098152e7960a14d241e1
for a good example how it could look like.

Mathias

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

Re: [LEDE-DEV] [PATCH 1/2] ipq806x/nbg6817: fixup internal mmc and switch configuration in DTS

[Mathias Kresin]

01.02.2017 22:08, André Valentin:

The setting mmc-ddr-1_8v in the platform dts leads to read errors. The
device is unusable and system reboots in a loop. Because NBG6817 is the
only mmc device, I commented mmc-ddr-1_8v out in base dts.

The second change removes settings now present in base dts.

The third change references was a wrong conversion of constants in the switch 
settings.
Switch now initializes again.

Signed-off-by: André Valentin 
---
 target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8065-nbg6817.dts | 4 +---
 target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8065.dtsi| 2 +-
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8065.dtsi 
b/target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8065.dtsi
index 8721577..411ffc3 100644
--- a/target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8065.dtsi
+++ b/target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8065.dtsi
@@ -123,7 +123,7 @@
non-removable;
cap-sd-highspeed;
cap-mmc-highspeed;
-   mmc-ddr-1_8v;
+   #mmc-ddr-1_8v;


Please remove the line instead of making it a comment.

Mathias

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

Re: [LEDE-DEV] [PATCH] Add Friendly Interactive Shell

[Mathias Kresin]

01.02.2017 23:36, Shane Peelar:

Signed-off-by: Shane Peelar 
---
 utils/fish/Makefile | 71 +
 utils/fish/patches/0001-configure.patch | 11 +
 2 files changed, 82 insertions(+)
 create mode 100644 utils/fish/Makefile
 create mode 100644 utils/fish/patches/0001-configure.patch


This package as well as the PCRE2 libraries should go into the OpenWrt 
community packages repository at https://github.com/openwrt/packages.


Only essential packages are in the LEDE repository.

Mathias



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

Re: [LEDE-DEV] [PATCH] Upgrade Vim to 8.0.0.69

[Mathias Kresin]

01.02.2017 23:35, Shane Peelar:

Signed-off-by: Shane Peelar 
---
 utils/vim/Makefile  |  8 
 utils/vim/patches/001-compile.patch | 41 -
 2 files changed, 4 insertions(+), 45 deletions(-)
 delete mode 100644 utils/vim/patches/001-compile.patch

diff --git a/utils/vim/Makefile b/utils/vim/Makefile
index 2e9f96a..4961c8a 100644


Please create a pull request at the https://github.com/openwrt/packages 
repository to get the vim package updated.


The OpenWrt packages repository is shared between OpenWrt and LEDE. If 
you patch it there, the updated version will be available in LEDE as well.


Mathias

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

Re: [LEDE-DEV] [PATCH] This patch adds support for the Netgear WN3000RPv3 N300 repeater.

[Mathias Kresin]

Hey Thibaut,

see my comment inline.

Mathias

17.01.2017 23:12, ha...@slashdirt.org:

From: Thibaut VARENE 

It uses the same trick as for the EX2700 to pass the Second Part
Magic Check from the bootloader (as described here
https://forum.openwrt.org/viewtopic.php?pid=312577#p312577 )

Specifications:
- SoC: MediaTek MT7620A (580MHz, ramips)
- RAM: 32MB
- Storage: 8MB NOR SPI flash
- Wireless: builtin MT7620A
- Ethernet: 1x100M

Stock firmware is based on OpenWRT Kamikaze snapshot. To install
LEDE, use the factory.bin image. Once LEDE is installed, subsequent
updates can use the sysupgrade.bin image.

Signed-off-by: Thibaut VARENE 
---
 target/linux/ramips/base-files/etc/board.d/01_leds |   3 +-
 .../linux/ramips/base-files/etc/board.d/02_network |   1 +
 target/linux/ramips/base-files/etc/diag.sh |   3 +-
 target/linux/ramips/base-files/lib/ramips.sh   |   3 +
 .../ramips/base-files/lib/upgrade/platform.sh  |   1 +
 target/linux/ramips/dts/WN3000RPV3.dts | 148 +
 target/linux/ramips/image/mt7620.mk|  11 ++
 7 files changed, 168 insertions(+), 2 deletions(-)
 create mode 100644 target/linux/ramips/dts/WN3000RPV3.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 3d3aa0a..545d6a4 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -155,7 +155,8 @@ vr500)
 dir-860l-b1)
ucidef_set_led_netdev "wan" "wan" "$board:green:net" "eth0.2"
;;
-ex2700)
+ex2700|\
+wn3000rpv3)
ucidef_set_led_default "power_r" "POWER (red)" "$board:red:power" "0"
set_wifi_led "$board:green:router"
;;
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 baf619f..4c94fba 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -58,6 +58,7 @@ ramips_setup_interfaces()
timecloud|\
w150m|\
widora-neo|\
+   wn3000rpv3|\
wnce2001|\
zbt-cpe102|\
zte-q7)
diff --git a/target/linux/ramips/base-files/etc/diag.sh 
b/target/linux/ramips/base-files/etc/diag.sh
index 5367e65..9499833 100644
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -53,7 +53,8 @@ get_status_led() {
jhr-n825r|\
mpr-a1|\
mpr-a2|\
-   mzk-ex750np)
+   mzk-ex750np|\
+   wn3000rpv3)
status_led="$board:red:power"


Any specific reason why you are using the red led here? I mean, you are 
switching on the green led already in the dts and red is at least for me 
some kind of warning signal, which I would not expect to see if 
everything is fine.


If you decide to use the green led, you can remove the red power off led 
from /etc/board.d/01_leds.




;;
ac1200pro|\
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index 6afe709..8292da1 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() {
*"WMR-300")
name="wmr-300"
;;
+   *"WN3000RPv3")
+   name="wn3000rpv3"
+   ;;
*"WNCE2001")
name="wnce2001"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index 0f2510c..c6ad8ca 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -157,6 +157,7 @@ platform_check_image() {
wli-tx4-ag300n|\
wlr-6000|\
wmr-300|\
+   wn3000rpv3|\
wnce2001|\
wndr3700v5|\
wr512-3gn|\
diff --git a/target/linux/ramips/dts/WN3000RPV3.dts 
b/target/linux/ramips/dts/WN3000RPV3.dts
new file mode 100644
index 000..8dc4249
--- /dev/null
+++ b/target/linux/ramips/dts/WN3000RPV3.dts
@@ -0,0 +1,148 @@
+/dts-v1/;
+
+#include "mt7620a.dtsi"
+


Please include  here as well.

Use the GPIO_ACTIVE_LOW and GPIO_ACTIVE_HIGH macros afterwards in stead 
of 1 and 0 in the gpio parameters.


Check the recent ramips board additions for examples.


+#include 
+
+/ {
+   compatible = "ralink,mt7620a-soc";
+   model = "Netgear WN3000RPv3";
+
+   chosen {
+   bootargs = "console=ttyS0,57600";
+   };
+
+   gpio-leds {
+   compatible = "gpio-leds";
+
+   power_g {
+   label = "wn3000rpv3:green:power";
+   gpios = < 9 1>;
+   default-state = "on";
+   };
+
+   power_r {
+   label = "wn3000rpv3:red:power";
+   

Re: [LEDE-DEV] [PATCH] mtd: Fix the soft reboot problem found on MediaTek devices with 32M Flash.

[Mathias Kresin]

2017-01-11 14:25 GMT+01:00 L. D. Pinney :
> This patch resets the spi to 3 byte mode needed for devices with more than 
> 16M Flash.
> Tested on the Onion Omega2+ (MT7688)
>
> Signed-off-by: L. D. Pinney 
> Tested-by: Nita Vesa 
>
> ---
>
> diff --git 
> a/target/linux/ramips/patches-4.4/101-spi-reset-to-3-byte-mode.patch 
> b/target/linux/ramips/patches-4.4/101-spi-reset-to-3-byte-mode.patch
> new file mode 100644
> index 000..b126411
> --- /dev/null
> +++ b/target/linux/ramips/patches-4.4/101-spi-reset-to-3-byte-mode.patch
> @@ -0,0 +1,24 @@
> +Index: linux-4.4.40/drivers/mtd/devices/m25p80.c
> +===
> +--- linux-4.4.40.orig/drivers/mtd/devices/m25p80.c
>  linux-4.4.40/drivers/mtd/devices/m25p80.c
> +@@ -261,6 +261,11 @@ static int m25p_remove(struct spi_device
> + {
> +   struct m25p *flash = spi_get_drvdata(spi);
> +
> ++  flash->command[0] = 0x66;
> ++  spi_write(flash->spi, flash->command, 1);
> ++  flash->command[0] = 0x99;
> ++  spi_write(flash->spi, flash->command, 1);
> ++
> +   /* Clean up MTD stuff. */
> +   return mtd_device_unregister(>spi_nor.mtd);
> + }
> +@@ -328,6 +333,7 @@ static struct spi_driver m25p80_driver =
> +   .id_table   = m25p_ids,
> +   .probe  = m25p_probe,
> +   .remove = m25p_remove,
> ++  .shutdown = m25p_remove,
> +
> +   /* REVISIT: many of these chips have deep power-down modes, which
> +* should clearly be entered on suspend() to minimize power use.

NAK!

This patch was already send as Github PR and dropped in favour of
backporting a patch that was send to linux-mtd. Have a look at
https://github.com/lede-project/source/pull/620 for details.

Mathias

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

Re: [LEDE-DEV] per-device rootfs generated on buildbots

[Mathias Kresin]

08.01.2017 15:35, Daniel Golle:

Hi!

While testing the current snapshot builds I realized that for some
reason the additional default packages to be included for each board
aren't selected, ie. DEVICE_PACKAGES seems to be ignored in snapshot
builds.
Ie. eventhough kmod-rtc-ds1307 is set in DEVICE_PACKAGES for the akitio
board (oxnas), the package doesn't end up in the generated rootfs and
initramfs image for that device. Looking at config.seed, everything
looks fine:
CONFIG_TARGET_MULTI_PROFILE=y
CONFIG_TARGET_ALL_PROFILES=y
...
CONFIG_TARGET_PER_DEVICE_ROOTFS=y

Any idea? Does that happen on purpose? Is it a bug or a feature?

Cheers

Daniel


Hey Daniel,

I'm not sure if you are talking about a specific image or all build 
akitio images.


For initramfs images only the DEFAULT_PACKAGES are included if 
TARGET_PER_DEVICE_ROOTFS is set. I hit this limitation/bug already and 
according to felix it isn't easily fixable. I can not remember all the 
details but his recommendation was to move essential packages to 
DEFAULT_PACKAGES.


In my case the switch driver was added via DEVICE_PACKAGES, finally 
missing in the initramfs and the network did not worked. Since the 
initramfs image in question is only required for the first install, it 
was enough to move the switch driver to the DEFAULT_PACKAGES. All the 
other missing (device) packages are not relevant for the first install 
in my case.


Mathias

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

Re: [LEDE-DEV] [PATCH] lantiq: set the usb clock source

[Mathias Kresin]

01.01.2017 11:21, Mathias Kresin:

The clock source is set by the ltq-hcd driver but are not by the
dwc2 driver. Without having the correct clock set the dwc driver
fails to reset the usb core and errors out. The values for supported
lantiq targets are exactly the same as set by the ltq-hcd driver and
should not cause any regressions.

Fixes FS#351

Signed-off-by: Mathias Kresin <d...@kresin.me>


Failed to set the correct subject prefix. This one is a RFC.

Mathias

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

[LEDE-DEV] [PATCH] lantiq: set the usb clock source

[Mathias Kresin]

The clock source is set by the ltq-hcd driver but are not by the
dwc2 driver. Without having the correct clock set the dwc driver
fails to reset the usb core and errors out. The values for supported
lantiq targets are exactly the same as set by the ltq-hcd driver and
should not cause any regressions.

Fixes FS#351

Signed-off-by: Mathias Kresin <d...@kresin.me>
---

Well the code works but is not really a beauty. But I need some input
to _possibly_ improve the code or at least the commit message.

Based on the disabled code in the ltq-hcd driver I guess for all
targets two bits are used to set the clock source.

I know that on vr9 the bits set to 00 or 11 means "XTAL 36 MHz input
devide by 3" where 00 is the default value.

After playing a bit with the bits, I'm the opinion the same applies to
Danube a well.

It's kinda strange that for Amazon only one bit is cleared within the
ltq-hcd driver. It looks more like an error or yet unknown workaround.
Setting the interface clock bits to 00 (default) does make more sense
to me. I've changed this in contrast to the ltq-hcd driver but do not
have any hardware to check this change or the dwc2 at all on Amazon.

For some reason the usb clock source has already the correct value on
vr9. I'm not sure if any vr9 board uses a clock source different than
the default "XTAL 36 MHz input devide by 3". For completeness I tend to
add the clock source for vr9 as well. Any opinions?

Albeit we obviously don't have an alien board which need a different
clock source than the others, setting the clock source to a fixed value
seams to me a really bad idea. And since it is the second time I had to
touch the CGU_IFCCR register [0][1] I've somehow the impression we need
some glue code to set the different clock sources via some kind of glue
code. I'm not sure what is the best way to do this. Should I add
something similar to the lantiq,phy-clk-src? Is there any chance that
this code is accepted upstream or should we consider it as LEDE hack?
Is the common clock framework maybe the saviour?

Would anyone with access to the datasheets be so kind to confirm:

- all lantiq targets are using two bits to set the clock source
- the meaning of the usbclk bit combinations are the same for all
  lantiq targets (including 00 == 11)
- it is safe to set the usb clock to 00 or 11 for Amazon

If 00 == 11 on Amazon/Danube, the lantiq,ase and lantiq,danube
conditions can be merged.

The lantiq,ar9 can be extended to cover vr9 as well.

[0] https://git.lede-project.org/44cace4dabe186a486d6713de6196bc7cea2228b
[1] https://git.lede-project.org/d4de9f72f31c4716f78fea8950261a3bdafdbccb

 .../0032-lantiq-set-the-usb-clock-source.patch | 52 ++
 ...MIPS-lantiq-danube-initialize-usb-on-boot.patch |  2 +-
 .../linux/lantiq/patches-4.4/0047-poweroff.patch   |  4 +-
 3 files changed, 55 insertions(+), 3 deletions(-)
 create mode 100644 
target/linux/lantiq/patches-4.4/0032-lantiq-set-the-usb-clock-source.patch

diff --git 
a/target/linux/lantiq/patches-4.4/0032-lantiq-set-the-usb-clock-source.patch 
b/target/linux/lantiq/patches-4.4/0032-lantiq-set-the-usb-clock-source.patch
new file mode 100644
index 000..bfc41aa
--- /dev/null
+++ b/target/linux/lantiq/patches-4.4/0032-lantiq-set-the-usb-clock-source.patch
@@ -0,0 +1,52 @@
+From 6e6569954319ef5f3e8c6a2c56056a90dd3c4ca0 Mon Sep 17 00:00:00 2001
+From: Mathias Kresin <d...@kresin.me>
+Date: Sat, 31 Dec 2016 10:46:18 +0100
+Subject: [PATCH] MIPS: lantiq: set the usb clock source
+
+The clock source is set by the ltq-hcd driver but are not by the
+dwc2 driver. Without having the correct clock set the dwc driver
+fails to reset the usb core and errors out. The values for supported
+lantiq targets are exactly the same as set by the ltq-hcd driver and
+should not cause any regressions.
+
+Signed-off-by: Mathias Kresin <d...@kresin.me>
+---
+
+ arch/mips/lantiq/xway/reset.c | 14 ++
+ 1 file changed, 14 insertions(+)
+
+--- a/arch/mips/lantiq/xway/reset.c
 b/arch/mips/lantiq/xway/reset.c
+@@ -95,6 +95,14 @@
+ #define PMU_USB0_PBIT(0)
+ #define PMU_USB1_PBIT(26)
+ 
++/* USB clock */
++#define CGU_IFCCR 0x0018
++#define CGU_USBCLK_MASK   0x3
++#define CGU_USBCLK_DEFAULT0x0
++#define CGU_USBCLK_DIRECT 0x1
++#define CGU_USBCLK_PPL0   0x2
++#define CGU_USBCLK_XTAL   0x3
++
+ /* remapped base addr of the reset control unit */
+ static void __iomem *ltq_rcu_membase;
+ static struct device_node *ltq_rcu_np;
+@@ -317,6 +325,17 @@ static void ltq_usb_init(void)
+   ltq_rcu_w32(ltq_rcu_r32(RCU_CFG1A) | BIT(0), RCU_CFG1A);
+   ltq_rcu_w32(ltq_rcu_r32(RCU_CFG1B) | BIT(0), RCU_CFG1B);
+ 
++  /* set usb clock source */
++  if (of_machine_is_compatible("lantiq,ase"))
++  ltq_cgu_w32((ltq_cgu_r32(CGU_IFCCR) & ~(CGU_USBCLK_MASK << 4))
++ 

Re: [LEDE-DEV] [PATCH] ramips: MiWiFi-Nano add the reset button

[Mathias Kresin]

28.12.2016 01:13, L. D. Pinney:

This patch defines the reset button in the MIWIFI-NANO.dts

Signed-off-by: L. D. Pinney 
---

diff --git a/target/linux/ramips/dts/MIWIFI-NANO.dts 
b/target/linux/ramips/dts/MIWIFI-NANO.dts
index 6906ef3..9b1ca42 100644
--- a/target/linux/ramips/dts/MIWIFI-NANO.dts
+++ b/target/linux/ramips/dts/MIWIFI-NANO.dts
@@ -34,6 +34,19 @@
default-state = "1";
};
};
+
+   gpio-keys-polled {
+   compatible = "gpio-keys-polled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   poll-interval = <20>;
+
+   reset {
+   label = "reset";
+   gpios = < 6 1>;
+   linux,code = <0x198>;


Please include the dt-bindings/gpio/gpio.h and dt-bindings/input/input.h 
headers. Use the macros from input.h for the linux,code and the 
GPIO_ACTIVE_HIGH/GPIO_ACTIVE_LOW macros from gpio.h. Have a look at the 
F5D8235_V1.dts for an example.


It would be great if you update the GPIO_ACTIVE of the existing gpio 
properties as well.


It seams to me the GPIO_ACTIVE value of the leds for this board are 
wrong. At least it would explain why they all are switch on by default. 
Would you please have a look at this as well.


Mathias

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