Re: [LEDE-DEV] [OpenWrt-Devel] Wifi-related kernel-oops on mt7621 after 4.14 update

[Kristian Evensen]

Hello,

On Wed, Apr 18, 2018 at 11:34 AM, Kristian Evensen
<kristian.even...@gmail.com> wrote:
> I will keep an eye on this router, just in case, but it seems the
> problem is gone. Thanks for fixing it so fast!

The router (WG3526) has been running fine for a while now, but after
changing configuration from client to access point (for both
interfaces) and updating I started seeing kernel oopses + reboot loops
again. The error messages is as follows:

[   30.665207] CPU 1 Unable to handle kernel paging request at virtual
address ea09a0dd, epc == 8f3a060c, ra == 8ed06fac
[   30.676034] Oops[#1]:
[   30.678341] CPU: 1 PID: 27 Comm: kworker/u8:1 Not tainted 4.14.37 #0
[   30.684852] Workqueue: phy0 ieee80211_ibss_leave [mac80211]
[   30.690409] task: 8fce8000 task.stack: 8fce4000
[   30.694922] $ 0   :  0001 7ac0ae80 0020
[   30.700149] $ 4   : 8ec4cbc0 8ee83c20 ea099ae0 8f79f400
[   30.705373] $ 8   :  80452db0 0007 00096a93
[   30.710593] $12   :  0264 000390fa 77f5d3c0
[   30.715812] $16   : 8ec4d560 8f581000 8ee83480 8ec4cbc0
[   30.721033] $20   :   8056 fffe
[   30.726252] $24   : 0fa3 80058514
[   30.731475] $28   : 8fce4000 8fce5ce8 8057 8ed06fac
[   30.736697] Hi: 000a
[   30.739562] Lo: 6669
[   30.742470] epc   : 8f3a060c 0x8f3a060c
[   30.746401] ra: 8ed06fac sta_set_sinfo+0xcc/0xbb0 [mac80211]
[   30.752380] Status: 11007c03 KERNEL EXL IE
[   30.756561] Cause : 4088 (ExcCode 02)
[   30.760550] BadVA : ea09a0dd
[   30.763418] PrId  : 0001992f (MIPS 1004Kc)
[   30.767492] Modules linked in: rt2800pci rt2800mmio rt2800lib
qcserial ppp_async option usb_wwan rt2x00pci rt2x00mmio rt2x00lib
rndis_host qmi_wwan ppp_generic nf_nat_pptp nf_conntrack_pptp
nf_conntrack_ipv6p
[   30.838554]  nf_nat_snmp_basic nf_nat_sip nf_nat_redirect
nf_nat_proto_gre nf_nat_masquerade_ipv4 nf_nat_irc nf_conntrack_ipv4
nf_nat_ipv4 nf_nat_h323 nf_nat_ftp nf_nat_amanda nf_nat nf_log_ipv4
nf_flow_table
[   30.909546]  ip_set_hash_netport ip_set_hash_netnet ip_set_hash_net
ip_set_hash_netportnet ip_set_hash_mac ip_set_hash_ipportnet
ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ipmark
ip_set_hash_ip ip_sd
[   30.979947]  ehci_platform sd_mod scsi_mod ehci_hcd
gpio_button_hotplug usbcore nls_base usb_common mii
[   30.989345] Process kworker/u8:1 (pid: 27, threadinfo=8fce4000,
task=8fce8000, tls=)
[   30.997742] Stack : 0200  8fce5d78  8fce5d78
80081240 8f79f400 8f581000
[   31.006092] 8ee83480 8ec4cbc0 8f581130  8056
fffe 8057 8ed06fac
[   31.014443]  8f581000 8fc06000 8ee834ac 8f581000
8ec4cbc0 8f581000 8f79f400
[   31.022793] 8ee83480 8ee834ac 8ec4cbc0  8056
8ed07a10 8f148a80 8007be74
[   31.031143]   8fce5d70 8fce5d70 
8f581000 8fc06000 8ed07ac0
[   31.039491] ...
[   31.041940] Call Trace:
[   31.044386] [<8f3a060c>] 0x8f3a060c
[   31.047866] Code: 000630c0  02063021  94f40002 <90d205fd> 00e0b025
1682  3253  2414001f  96d50004
[   31.057611]
[   31.059362] ---[ end trace 7868a781b307fb50 ]---
[   31.068983] Kernel panic - not syncing: Fatal exception
[   31.076144] Rebooting in 3 seconds..

I will try to compile an image with KALLMSYS and see if I can
reproduce the issue. My firmware is based on latest nightly.

BR,
Kristian

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

Re: [LEDE-DEV] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue...?

[Kristian Evensen]

Hi,

On Mon, May 14, 2018 at 9:03 AM, Jamie Stuart  wrote:
> Hi Everyone,
> Just wondering if anyone had made any progress into integrating this in trunk 
> OpenWRT.
> It’s out of my skillset unfortunately!

I don't know if the patch mentioned in the original email is in
Daniel's tree or not, but I have been running several mt7620-devices
(so rt2800) with the additional rt2x00 patches since they were pushed
(mid-March). Since then, I have not had any issues with wifi on my
devices. Also, my sure-fire way of crashing (or at least triggering
errors) the driver was to run a wifi-scan tool provided by Apple. I am
no longer able to trigger any errors when using this tool.

BR,
Kristian

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

Re: [LEDE-DEV] Firewall restart crashes routers with kernel 4.14

[Kristian Evensen]

Hi,

Thanks for your reply, good to know that I am not alone :)

On Sat, May 5, 2018 at 9:45 PM, Lucian Cristian  wrote:
> do you have hardware offloading enabled and multiwan ?
>
> I have the same problem when I enable them

The routers do support hardware offloading (ZBT WG3526 so mt7621), but
it is not enabled. At least I can't see a FLOWOFFLOAD-rule. The
routers do, however, have multiple active interfaces (WAN port +
modem). I have now compiled an image with rtcache again and tested the
following combinations:

- WAN port + modem active: Crash.
- Only WAN port active (disconnected modem from router): Crash.
- Removed xt_FLOWOFFLOAD module: Crash.

On an image with rtcache disabled, I don't see the crash. I don't know
it matters or not, but the router always crashes after "Zone 'wan'"
has been written to screen (in the "Populating IPv4 filter table"
step).

BR,
Kristian

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

[LEDE-DEV] Firewall restart crashes routers with kernel 4.14

[Kristian Evensen]

Hello,

When restarting the firewall on routers running latest nightly, I
frequently get the following warning:

[   74.952854] [ cut here ]
[   74.952874] WARNING: CPU: 2 PID: 0 at
net/netfilter/nf_conntrack_rtcache.c:197 0x8f6293f0
[   74.952876] Modules linked in: rt2800pci rt2800mmio rt2800lib
qcserial ppp_async option usb_wwan rt2x00pci rt2x00mmio rt2x00lib
rndis_host qmi_wwan ppp_generic nf_nat_pptp nf_conntrack_pptp
nf_conntrack_ipv6p
[   74.953097]  nf_nat_snmp_basic nf_nat_sip nf_nat_redirect
nf_nat_proto_gre nf_nat_masquerade_ipv4 nf_nat_irc nf_conntrack_ipv4
nf_nat_ipv4 nf_nat_h323 nf_nat_ftp nf_nat_amanda nf_nat nf_log_ipv4
nf_flow_tablt
[   74.953279]  ip_set_hash_netiface ip_set_hash_netport
ip_set_hash_netnet ip_set_hash_net ip_set_hash_netportnet
ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip
ip_set_hash_ipport ip_set_hash_ipmarm
[   74.953472]  ohci_hcd ehci_platform sd_mod scsi_mod ehci_hcd
gpio_button_hotplug usbcore nls_base usb_common mii
[   74.953512] CPU: 2 PID: 0 Comm: swapper/2 Tainted: GW
4.14.37 #0
[   74.953515] Stack :     805c7ad2
0042  8052c580
[   74.953542] 8fc44834 805668e7 804f59fc 0002 
0001 8fc11c38 
[   74.953569]   805c 1233d908 0004
80452cac 7d0b0d06 000c2bff
[   74.953597]  8057 935d 805f 
 8059 8f6293f0
[   74.953625] 0009 00c5 0001 0003 0002
8036a504 0008 805c0008
[   74.953652] ...
[   74.953660] Call Trace:
[   74.953674] [<800103f8>] show_stack+0x58/0x100
[   74.953689] [<8043c03c>] dump_stack+0x9c/0xe0
[   74.953700] [<8002e190>] __warn+0xe0/0x114
[   74.953711] [<8002e254>] warn_slowpath_null+0x1c/0x28
[   74.953739] [<8f6293f0>] 0x8f6293f0
[   74.953754] ---[ end trace 6b009cc1611edaa4 ]---

The router then seems to spin on this warning, becomes
unreachable/unresponsive and never reboots. If I compile an image with
rtcache disabled (doing rmmod on the module triggers an oops),
firewall restarts works fine.

I tried to take a look at the code to check if I could spot anything
obvious, but couldn't see anything.

BR,
Kristian

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

[LEDE-DEV] Transmit timeouts on MT7621 with kernel 4.14

[Kristian Evensen]

Hello,

I have been doing some tests with kernel 4.14 on some MT7621-based
devices (ZBT WG2926 and WG3526). Sometimes, seemingly out of the blue,
I get the following oops:

[   95.073332] [ cut here ]
[   95.077988] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:320
dev_watchdog+0x1ac/0x324
[   95.086240] NETDEV WATCHDOG: eth0 (mtk_soc_eth): transmit queue 0 timed out
[   95.093166] Modules linked in: rt2800pci rt2800mmio rt2800lib
qcserial ppp_async option usb_wwan rt2x00pci rt2x00mmio rt2x00lib
rndis_host qmi_wwan ppp_generic nf_nat_pptp nf_conntrack_pptp
nf_conntrack_ipv6 mt76x2e mt7603e mt76 mac80211 iptable_nat ipt_REJECT
ipt_MASQUERADE huawei_cdc_ncm cfg80211 cdc_ncm cdc_ether ax88179_178a
asix xt_time xt_tcpudp xt_tcpmss xt_string xt_statistic xt_state
xt_recent xt_quota xt_policy xt_pkttype xt_owner xt_nfacct xt_nat
xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_helper xt_esp
xt_ecn xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connlabel
xt_connbytes xt_comment xt_addrtype xt_TCPMSS xt_REDIRECT xt_NFQUEUE
xt_LOG xt_HL xt_FLOWOFFLOAD xt_DSCP xt_CT xt_CLASSIFY usbserial usbnet
ts_fsm ts_bm slhc nfnetlink_queue nfnetlink_acct nf_reject_ipv4
nf_nat_tftp
[   95.164255]  nf_nat_snmp_basic nf_nat_sip nf_nat_redirect
nf_nat_proto_gre nf_nat_masquerade_ipv4 nf_nat_irc nf_conntrack_ipv4
nf_nat_ipv4 nf_nat_h323 nf_nat_ftp nf_nat_amanda nf_nat nf_log_ipv4
nf_flow_table_hw nf_flow_table nf_defrag_ipv6 nf_defrag_ipv4
nf_conntrack_tftp nf_conntrack_snmp nf_conntrack_sip
nf_conntrack_rtcache nf_conntrack_proto_gre nf_conntrack_netlink
nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp
nf_conntrack_broadcast ts_kmp nf_conntrack_amanda iptable_raw
iptable_mangle iptable_filter ipt_ah ipt_ECN ip6table_raw ip_tables
crc_itu_t crc_ccitt compat_xtables compat cdc_wdm cdc_acm br_netfilter
sch_cake act_connmark nf_conntrack act_skbedit act_mirred em_u32
cls_u32 cls_tcindex cls_flow cls_route cls_fw sch_tbf sch_htb sch_hfsc
sch_ingress ledtrig_usbport xt_set ip_set_list_set
[   95.235207]  ip_set_hash_netiface ip_set_hash_netport
ip_set_hash_netnet ip_set_hash_net ip_set_hash_netportnet
ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip
ip_set_hash_ipport ip_set_hash_ipmark ip_set_hash_ip
ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set
nfnetlink ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common
ip6table_mangle ip6table_filter ip6_tables x_tables ifb ipcomp6
xfrm6_tunnel xfrm6_mode_tunnel xfrm6_mode_transport xfrm6_mode_beet
esp6 ah6 ipcomp xfrm4_tunnel xfrm4_mode_tunnel xfrm4_mode_transport
xfrm4_mode_beet esp4 ah4 tunnel6 tunnel4 tun af_key xfrm_user
xfrm_ipcomp xfrm_algo eeprom_93cx6 sha256_generic sha1_generic
jitterentropy_rng drbg md5 hmac echainiv des_generic cmac cbc authenc
leds_gpio xhci_mtk xhci_plat_hcd xhci_pci xhci_hcd uhci_hcd
ohci_platform
[   95.306669]  ohci_hcd ehci_platform sd_mod scsi_mod ehci_hcd
gpio_button_hotplug usbcore nls_base usb_common mii
[   95.316933] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.14.34 #0
[   95.322940] Stack :     805c7ada
0034  8052c54c
[   95.331300] 8fc441f4 805668e7 804f5a2c 0001 
0001 8fc0dd68 0007
[   95.339655]   805c 7cd0 
0165 0007 
[   95.348003]  8057 0004d605  
 8059 8034d5a8
[   95.356355] 0009 0140 0001 8ff15940 0003
8027c368 0004 805c0004
[   95.364707] ...
[   95.367150] Call Trace:
[   95.369622] [<800103e8>] show_stack+0x58/0x100
[   95.374080] [<8043bfcc>] dump_stack+0x9c/0xe0
[   95.378428] [<8002e170>] __warn+0xe0/0x114
[   95.382511] [<8002e1d4>] warn_slowpath_fmt+0x30/0x3c
[   95.387476] [<8034d5a8>] dev_watchdog+0x1ac/0x324
[   95.392184] [<80085b94>] call_timer_fn.isra.3+0x24/0x84
[   95.397395] [<80085dac>] run_timer_softirq+0x1b8/0x244
[   95.402543] [<804590d0>] __do_softirq+0x128/0x2ec
[   95.407241] [<80032870>] irq_exit+0x98/0xcc
[   95.411434] [<8023944c>] plat_irq_dispatch+0xfc/0x138
[   95.416477] [<8000b508>] except_vec_vi_end+0xb8/0xc4
[   95.421427] [<8000ced0>] r4k_wait_irqoff+0x1c/0x24
[   95.426230] [<80065f3c>] do_idle+0xe4/0x168
[   95.430402] [<800661b8>] cpu_startup_entry+0x24/0x2c
[   95.435451] ---[ end trace b6fed008f9c0705a ]---
[   95.440096] mtk_soc_eth 1e10.ethernet eth0: transmit timed out
[   95.446363] mtk_soc_eth 1e10.ethernet eth0: dma_cfg:8067
[   95.452456] mtk_soc_eth 1e10.ethernet eth0: tx_ring=0,
base=0e84, max=0, ctx=1241, dtx=1164, fdx=1164, next=1241
[   95.463414] mtk_soc_eth 1e10.ethernet eth0: rx_ring=0,
base=0e7c, max=0, calc=1472, drx=1473
[   95.78] mtk_soc_eth 1e10.ethernet eth0: port 3 link down
[   95.745171] mtk_soc_eth 1e10.ethernet eth0: port 4 link down
[   95.886802] mtk_soc_eth 1e10.ethernet: 0x100 = 0x5160030c,
0x10c = 0x80818
[   95.908574] mtk_soc_eth 1e10.ethernet: PPE 

Re: [LEDE-DEV] [OpenWrt-Devel] Wifi-related kernel-oops on mt7621 after 4.14 update

[Kristian Evensen]

Hi,

On Tue, Apr 17, 2018 at 3:34 PM, Kristian Evensen
<kristian.even...@gmail.com> wrote:
> Thanks, great. I just started building a new image for my router, will
> test and let you know if I still see the issue.

I think I have finished my testing, at least for now, and it seems the
problem is fixed. I compiled an image with the latest changes to mt76,
installed the image on one of my WG3526-routers showing the issue,
configured both radios as clients and updated the router ~10 times,
rebooted, etc. I did not see the crash, wifi was rock solid. I then
"updated" to the older image without the latest changes and the oops
appeared right away.

I will keep an eye on this router, just in case, but it seems the
problem is gone. Thanks for fixing it so fast!

BR,
Kristian

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

Re: [LEDE-DEV] [OpenWrt-Devel] Wifi-related kernel-oops on mt7621 after 4.14 update

[Kristian Evensen]

On Tue, Apr 17, 2018 at 2:56 PM, Felix Fietkau <n...@nbd.name> wrote:
> On 2018-04-17 13:50, Kristian Evensen wrote:
>> This is with the same image as last time (commit
>> f6e6eadc99c6274207f8f2ebc739063549959a1f) and configuration (radios
>> used as clients). I see that mt76 has been updated during the weekend
>> so I will go ahead and compile a new image with the latest updates.
> I'm about to push another update in a minute. Please wait for that and
> test it. I fixed some more issues in the code.

Thanks, great. I just started building a new image for my router, will
test and let you know if I still see the issue.

BR,
Kristian

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

Re: [LEDE-DEV] [OpenWrt-Devel] Wifi-related kernel-oops on mt7621 after 4.14 update

[Kristian Evensen]

Hi,

On Thu, Apr 12, 2018 at 3:28 PM, Kristian Evensen
<kristian.even...@gmail.com> wrote:
> Thanks for the pointer. I compiled a new image KALLSYMS, but now I am
> not able to reproduce the error. Perhaps there was something dirty in
> my build directory. I will keep the image KALLSYMS on the routers and
> keep checking for the error.

The error came back after I updated my router again. Here are the
oops'es with KALLMSYS enabled:

[   36.714334] CPU 1 Unable to handle kernel paging request at virtual
address f32f0c10, epc == 8f391304, ra == 8f391304
[   36.724966] Oops[#1]:
[   36.727246] CPU: 1 PID: 33 Comm: kworker/u8:2 Tainted: GW
4.14.32 #0
[   36.734949] Workqueue: phy1 ieee80211_ibss_leave [mac80211]
[   36.740523] task: 8fd48000 task.stack: 8fd36000
[   36.745037] $ 0   :  0001 000e 0001
[   36.750270] $ 4   : 8f37957c   
[   36.755506] $ 8   :  80452970 0001 00122121
[   36.760726] $12   :   0010 77ec6230
[   36.765946] $16   : 8f37957c 8fd37d58 f32f0c10 94573690
[   36.771173] $20   : 0001 0040 00ff 8f378bc0
[   36.776394] $24   : 10d9 8f391218
[   36.781615] $28   : 8fd36000 8fd37d10  8f391304
[   36.786837] Hi: 969d
[   36.789701] Lo: 0110
[   36.792603] epc   : 8f391304 mt76_get_survey+0xec/0x31c [mt76]
[   36.798417] ra: 8f391304 mt76_get_survey+0xec/0x31c [mt76]
[   36.804220] Status: 11007c03 KERNEL EXL IE
[   36.808399] Cause : 4088 (ExcCode 02)
[   36.812389] BadVA : f32f0c10
[   36.815257] PrId  : 0001992f (MIPS 1004Kc)
[   36.819331] Modules linked in: rt2800pci rt2800mmio rt2800lib
qcserial ppp_async option usb_wwan rt2x00pci rt2x00mmio rt2x00lib
rndis_host qmi_wwan ppp_generic nf_nat_pptp nf_conntrack_pptp
nf_conntrack_ipv6p
[   36.890390]  nf_nat_snmp_basic nf_nat_sip nf_nat_redirect
nf_nat_proto_gre nf_nat_masquerade_ipv4 nf_nat_irc nf_conntrack_ipv4
nf_nat_ipv4 nf_nat_h323 nf_nat_ftp nf_nat_amanda nf_nat nf_log_ipv4
nf_flow_tablt
[   36.961381]  ip_set_hash_netiface ip_set_hash_netport
ip_set_hash_netnet ip_set_hash_net ip_set_hash_netportnet
ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip
ip_set_hash_ipport ip_set_hash_ipmarm
[   37.032821]  ohci_hcd ehci_platform sd_mod scsi_mod ehci_hcd
gpio_button_hotplug usbcore nls_base usb_common mii
[   37.043006] Process kworker/u8:2 (pid: 33, threadinfo=8fd36000,
task=8fd48000, tls=)
[   37.051404] Stack : 0001 80051a40 81494dc0  0400
8f57c000  
[   37.059753]  8ec110dc 002f113b  8fc2a500
81494dc0  0001
[   37.068100] 814a2dc0 8fc2a614 94573690  
  
[   37.076449]     
  
[   37.084797] 000c   8ec113a0 0020
8149d2ec 814a2dc0 8fc2a500
[   37.093147] ...
[   37.095597] Call Trace:
[   37.098045] [<8f391304>] mt76_get_survey+0xec/0x31c [mt76]
[   37.103671] [<8ec110dc>]
___ieee80211_start_rx_ba_session+0x15c/0x39c [mac80211]
[   37.27] [<8ec113a0>] __ieee80211_start_rx_ba_session+0x84/0xb8 [mac80211]
[   37.118315] [<8ec1144c>] ieee80211_process_addba_request+0x78/0x8c [mac80211]
[   37.125507] [<8ec152a0>] ieee80211_ibss_leave+0x44c/0x19c8 [mac80211]
[   37.132067] Code: 2610001c  0c116236  02002025 <8e44> 3c058d4f
34a5df3b  00850019  3012  3810
[   37.141817]
[   37.143582] ---[ end trace 5af5293c693da408 ]---
[   37.151753] Kernel panic - not syncing: Fatal exception in interrupt
[   37.160354] Rebooting in 3 seconds..

[   30.252516] CPU 0 Unable to handle kernel paging request at virtual
address eb44a0d5, epc == 8ed40ba4, ra == 8ec86fac
[   30.263189] Oops[#1]:
[   30.265506] CPU: 0 PID: 33 Comm: kworker/u8:2 Tainted: GW
4.14.32 #0
[   30.273244] Workqueue: phy1 ieee80211_ibss_leave [mac80211]
[   30.278811] task: 8fd48000 task.stack: 8fd36000
[   30.283321] $ 0   :  0001 7adc6e80 
[   30.288546] $ 4   : 8f3d8bc0 8fd27c20 eb449ae0 8e03a800
[   30.293766] $ 8   :  80452970 0007 0006edf8
[   30.298985] $12   :  8ee8d0c0 0007 1dcd6501
[   30.304205] $16   : 8f3d9560 8f5b8800 8fd27480 8f3d8bc0
[   30.309425] $20   : 8e03a800  8056 fffe
[   30.314645] $24   :  
[   30.319865] $28   : 8fd36000 8fd37cf8 8056 8ec86fac
[   30.325085] Hi: 329d
[   30.327951] Lo: 010e
[   30.330849] epc   : 8ed40ba4 mt76x2_dma_cleanup+0x478/0x1128 [mt76x2e]
[   30.337408] ra: 8ec86fac sta_set_sinfo+0xcc/0xbb0 [mac80211]
[   30.343386] Status: 11008403 KERNEL EXL IE
[   30.347565] Cause : c088 (ExcCode 02)
[   30.351553] BadVA : eb44a0d5
[   30.354421] PrId  : 0001992f (MIPS 1004Kc)
[   30.358494] Modules linked in: rt2800pci rt2800mmio rt2800lib
qcserial ppp_async option usb_wwan rt2x00pci rt2x00mmio

Re: [LEDE-DEV] [OpenWrt-Devel] Wifi-related kernel-oops on mt7621 after 4.14 update

[Kristian Evensen]

Hi,

On Thu, Apr 12, 2018 at 1:02 PM, John Crispin  wrote:
> try enabling KALLSYMS to get a verbose stack trace.

Thanks for the pointer. I compiled a new image KALLSYMS, but now I am
not able to reproduce the error. Perhaps there was something dirty in
my build directory. I will keep the image KALLSYMS on the routers and
keep checking for the error.

BR,
Kristian

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

[LEDE-DEV] Wifi-related kernel-oops on mt7621 after 4.14 update

[Kristian Evensen]

Hello,

I have recently updated some ramips mt7621-devices (ZBT WG3526) to the
latest nightly. Almost everything seems to work fine, but using either
wifi interface in client mode seems triggers an oops. I see two
different oops-messages:

Message 1:
[   66.442802] CPU 1 Unable to handle kernel paging request at virtual
address e9e9e0d5, epc == 8f3e060c, ra == 8ec86fac
[   66.453460] Oops[#1]:
[   66.455743] CPU: 1 PID: 3679 Comm: wifib Tainted: GW   4.14.32 #0
[   66.462857] task: 8e223200 task.stack: 8e1b4000
[   66.467374] $ 0   :  0001 7abc2e80 0020
[   66.472612] $ 4   : 8ec48bc0 8e76dc20 e9e9dae0 8e1b5848
[   66.477847] $ 8   : 8ec4902c 80452968 00ee4000 ff80
[   66.483061] $12   : 80583f8c 0040  77f0f3c0
[   66.488276] $16   : 8ec49560 8f578000 8e76d480 8ec48bc0
[   66.493493] $20   :  0002 8e1b5cb8 0008
[   66.498711] $24   :  77e74ff0
[   66.503937] $28   : 8e1b4000 8e1b5780  8ec86fac
[   66.509153] Hi: 
[   66.512020] Lo: 0068
[   66.514913] epc   : 8f3e060c 0x8f3e060c
[   66.518866] ra: 8ec86fac sta_set_sinfo+0xcc/0xbb0 [mac80211]
[   66.524843] Status: 11007c03 KERNEL EXL IE
[   66.529015] Cause : 4088 (ExcCode 02)
[   66.533005] BadVA : e9e9e0d5
[   66.535869] PrId  : 0001992f (MIPS 1004Kc)
[   66.539941] Modules linked in: rt2800pci rt2800mmio rt2800lib
qcserial ppp_async option usb_wwan rt2x00pci rt2x00mmio rt2x00lib
rndis_host qmi_wwan ppp_generic nf_nat_pptp nf_conntrack_pptp
nf_conntrack_ipv6p
[   66.610889]  nf_nat_snmp_basic nf_nat_sip nf_nat_redirect
nf_nat_proto_gre nf_nat_masquerade_ipv4 nf_nat_irc nf_conntrack_ipv4
nf_nat_ipv4 nf_nat_h323 nf_nat_ftp nf_nat_amanda nf_nat nf_log_ipv4
nf_flow_tablt
[   66.681822]  ip_set_hash_netiface ip_set_hash_netport
ip_set_hash_netnet ip_set_hash_net ip_set_hash_netportnet
ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip
ip_set_hash_ipport ip_set_hash_ipmarm
[   66.753184]  ohci_hcd ehci_platform sd_mod scsi_mod ehci_hcd
gpio_button_hotplug usbcore nls_base usb_common mii
[   66.763357] Process wifib (pid: 3679, threadinfo=8e1b4000,
task=8e223200, tls=77f10ec0)
[   66.771321] Stack :     
 8e1b5848 8f578000
[   66.779654] 8e76d480 8ec48bc0 8f578130 0002 8e1b5cb8
0008  8ec86fac
[   66.787987] 0100 8e134628 0007 8e1b5b98 8e134628
 8e1b5b90 8ec49014
[   66.796325] 8e76d000  fffe 0002 8e1b5cb8
8ec9e338 8ec315ac 
[   66.804661] 01d2 8058   
8e134628 8e068840 8ec1fb28
[   66.812996] ...
[   66.815446] Call Trace:
[   66.817894] [<8f3e060c>] 0x8f3e060c
[   66.821370] Code: 000630c0  02063021  94f40002 <90d205f5> 00e0b025
1682  3253  2414001f  96d50004
[   66.831098]
[   66.833187] ---[ end trace 8c8a003de3eabcd8 ]---
[   66.841897] Kernel panic - not syncing: Fatal exception
[   66.849317] Rebooting in 3 seconds..

Message 2:
[  132.613293] CPU 0 Unable to handle kernel paging request at virtual
address ea9160d5, epc == 8f2c060c, ra == 8ec86fac
[  132.623927] Oops[#1]:
[  132.626199] CPU: 0 PID: 41 Comm: kworker/u8:3 Tainted: GW
4.14.32 #0
[  132.633882] Workqueue: phy0 ieee80211_ibss_leave [mac80211]
[  132.639431] task: 8fd48c80 task.stack: 8fd94000
[  132.643933] $ 0   :  0001 7ac52e80 0020
[  132.649141] $ 4   : 8f2d0bc0 8e04dc20 ea915ae0 8f122400
[  132.654350] $ 8   :  80452970 8fc02b00 0005376b
[  132.659558] $12   : 12d8   001c
[  132.664766] $16   : 8f2d1560 8f58a000 8e04d480 8f2d0bc0
[  132.669973] $20   :  0001 8f2d1014 
[  132.675181] $24   : 3b9aca00 
[  132.680390] $28   : 8fd94000 8fd95c88 8ece1618 8ec86fac
[  132.685605] Hi: 07d0
[  132.688473] Lo: 0bb8
[  132.691357] epc   : 8f2c060c 0x8f2c060c
[  132.695235] ra: 8ec86fac sta_set_sinfo+0xcc/0xbb0 [mac80211]
[  132.701212] Status: 11008403 KERNEL EXL IE
[  132.705391] Cause : 4088 (ExcCode 02)
[  132.709380] BadVA : ea9160d5
[  132.712247] PrId  : 0001992f (MIPS 1004Kc)
[  132.716320] Modules linked in: rt2800pci rt2800mmio rt2800lib
qcserial ppp_async option usb_wwan rt2x00pci rt2x00mmio rt2x00lib
rndis_host qmi_wwan ppp_generic nf_nat_pptp nf_conntrack_pptp
nf_conntrack_ipv6p
[  132.787381]  nf_nat_snmp_basic nf_nat_sip nf_nat_redirect
nf_nat_proto_gre nf_nat_masquerade_ipv4 nf_nat_irc nf_conntrack_ipv4
nf_nat_ipv4 nf_nat_h323 nf_nat_ftp nf_nat_amanda nf_nat nf_log_ipv4
nf_flow_tablt
[  132.858369]  ip_set_hash_netiface ip_set_hash_netport
ip_set_hash_netnet ip_set_hash_net ip_set_hash_netportnet
ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip
ip_set_hash_ipport ip_set_hash_ipmarm
[  132.929808]  ohci_hcd ehci_platform sd_mod scsi_mod ehci_hcd
gpio_button_hotplug usbcore nls_base usb_common mii
[  132.939989] Process kworker/u8:3 (pid: 41, threadinfo=8fd94000,

Re: [LEDE-DEV] [PATCH] procd: Restore respawn on SIGTERM timeout

[Kristian Evensen]

On Thu, Oct 19, 2017 at 3:02 PM, Kristian Evensen
<kristian.even...@gmail.com> wrote:
> When SIGTERM times out, procd sends SIGKILL and then restarts the
> process once SIGCHLD has been received. This all works fine, with one
> exception - respawn is not restored when instance_start() is called from
> instance_exit(). The reason is that respawn is always set to false in
> instance_stop(), and the same service_instance struct is used for the
> instance_start()-call.
>
> The consequence is that if the process is killed/crashes again, it will
> not respawn. Solve this issue by adding a variable used to store the
> original value of respawn in instance_stop(), and then restore the
> original respawn-value in instance_exit().
>
> Signed-off-by: Kristian Evensen <kristian.even...@gmail.com>
> ---

Ping on this patch :)

-Kristian

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

Re: [LEDE-DEV] [PATCH] procd: Restore respawn on SIGTERM timeout

[Kristian Evensen]

Hi Karl,

Sorry for my extremely late reply. For some reason, it was not picked
up by Gmail and I did not see it before today. Since it was not picked
up by Gmail, I had to do some creative c, sorry in advance for weird
formatting.

>>Kristian Evensen <kristian.even...@gmail.com> wrote:
>> When SIGTERM times out, procd sends SIGKILL and then restarts
>> the process once SIGCHLD has been received. This all works
>> fine, with one exception - respawn is not restored when
>> instance_start() is called from instance_exit(). The reason is
>> that respawn is always set to false in instance_stop(), and the
>> same service_instance struct is used for the
>> instance_start()-call.
>>
>> The consequence is that if the process is killed/crashes again,
>> it will not respawn. Solve this issue by adding a variable used
>> to store the original value of respawn in instance_stop(), and
>> then restore the original respawn-value in instance_exit().
>
> It smells like this likely applies to many other fields. Is there
> a path here that's not using the copy/compare routines for a
> service/instance? Should they be? Does your path even restore all
> the parameters of respawn?

As far as I can tell (and based on my tests), only in->respawn is
overwritten and not recovered. All other fields keep their value. The
rc.local restart-operation seems to be a stop() and then a
start()-call, so in->restart is correctly set to false.

BR,
Kristian

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

Re: [LEDE-DEV] Transmit timeouts with mtk_eth_soc and MT7621

[Kristian Evensen]

Hello,

On Thu, Nov 9, 2017 at 8:42 PM, Kristian Evensen
<kristian.even...@gmail.com> wrote:
> I replaced the 3526 with other devices containing the mt7530 switch
> (both mt7621 and mt7623-based boards), and the issues seems to be
> related to the switch rather than the SoC. I am able to reliably
> trigger the timeout on all devices I have tested, both running
> proprietary drivers/firmware and LEDE. I guess this points to that
> there is some traffic pattern or network behavior that triggers an
> error in the MT7530 and causes TX to freeze. Restarting the ports
> makes the switch work again, but as long as the "bad" device is
> connected to the mt7530 then it is just a matter of time before the
> timeout is back.

I think I am ready to conclude on this issue. First of all, I have
discovered that I made an incorrect statement earlier. I have not seen
the problem with flow control disabled. After finding a network tap
and a device which passes for example pause frames to the driver so I
can see them with tcpdump, I think I finally see what is going on.

I connected the tap between router #1 and router #2, and performed the
test described earlier with flow control enabled and disabled. When
triggering the RCU stall, I see a continuous flood of pause frames
coming from router #2. This flood happens irrespective of if flow
control is enabled or not. However, with flow control enabled, I see
that the RxPause- and TxPause-counters increase. With flow control
disabled, they remain at 0. In other words, it seems that the switch
filters out pause frames if the bit is unset in the feature register
(it would be great if someone could confirm/deny this).

The MT7530 switch seems to use one buffer for all ports, so what I
have seen all along is head of line blocking. Since I use iperf in UDP
mode, the traffic destined for router #2 never slows down and fills up
the buffer. Thus, all other traffic is blocked. When disabling the
port used by route #2, the buffer is cleared and packets can flow as
normal again. With flow control disabled, I do not see the head of
line blocking. If I am connected to router #1, I can always reach it.
If flow control is enabled, router #1 stops replying to for example
ping when the pause flood starts.

I don't know what is the correct "solution" for this problem. I asked
Piotr to mark my patch for always disabling flow control as not
applicable, but perhaps it should be brought back if everyone agrees
that disabling flow control is ok. If not, then perhaps the following
patch should be accepted so that it is possible to switch flow control
on/off: https://lists.openwrt.org/pipermail/openwrt-devel/2016-April/040705.html

BR,
Kristian

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

Re: [LEDE-DEV] Transmit timeouts with mtk_eth_soc and MT7621

[Kristian Evensen]

On Thu, Nov 9, 2017 at 5:21 PM, Kristian Evensen
<kristian.even...@gmail.com> wrote:
> I have been hammering away on this issue during the day, and it seems
> that the DMA engine, TX, etc. works just fine. However, for some
> reason, the port with the router that has hung is able to stop the
> whole switch. If I disable the port (or disconnect the cable), then TX
> works again and I can for example reach 192.168.1.1 from 192.168.1.2
> in my testbed. When running ping (from 192.168.1.2 to 192.168.1.1)
> while disconnecting the cable, the first packets had a very high RTT
> (~20ms). Running tcpdump showed that the reply arrived immediately, so
> it seems the packets are stuck in a TX buffer for a really long time.
> Could it be that there is a cache or something internally on the
> switch that is causing packets to be held back, and that this cache is
> invalidated and buffers flushed when I disable the port? I cleared
> switch, DIP and SIP tables without any effect.
>
> If I enable the port, then the problem appears again after a little
> while (~30 seconds).

I replaced the 3526 with other devices containing the mt7530 switch
(both mt7621 and mt7623-based boards), and the issues seems to be
related to the switch rather than the SoC. I am able to reliably
trigger the timeout on all devices I have tested, both running
proprietary drivers/firmware and LEDE. I guess this points to that
there is some traffic pattern or network behavior that triggers an
error in the MT7530 and causes TX to freeze. Restarting the ports
makes the switch work again, but as long as the "bad" device is
connected to the mt7530 then it is just a matter of time before the
timeout is back.

-Kristian

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

Re: [LEDE-DEV] Transmit timeouts with mtk_eth_soc and MT7621

[Kristian Evensen]

On Thu, Nov 9, 2017 at 12:06 PM, Kristian Evensen
<kristian.even...@gmail.com> wrote:
> I see that the CPU txds [384-511] have DDONE set and no SKB, while
> DDONE is not set for the DMA txds [0-383] and an skb is attached. I
> also looked at the content of the skb, and as far as I can see it is
> valid. Looking at the content of the SKB also shows that
> fe_reset_pending() does its job. For every timeout, there is a new set
> of packets on the ring. So new packets are put on the ring, but none
> are sent.

I have been hammering away on this issue during the day, and it seems
that the DMA engine, TX, etc. works just fine. However, for some
reason, the port with the router that has hung is able to stop the
whole switch. If I disable the port (or disconnect the cable), then TX
works again and I can for example reach 192.168.1.1 from 192.168.1.2
in my testbed. When running ping (from 192.168.1.2 to 192.168.1.1)
while disconnecting the cable, the first packets had a very high RTT
(~20ms). Running tcpdump showed that the reply arrived immediately, so
it seems the packets are stuck in a TX buffer for a really long time.
Could it be that there is a cache or something internally on the
switch that is causing packets to be held back, and that this cache is
invalidated and buffers flushed when I disable the port? I cleared
switch, DIP and SIP tables without any effect.

If I enable the port, then the problem appears again after a little
while (~30 seconds).

-Kristian

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

Re: [LEDE-DEV] Transmit timeouts with mtk_eth_soc and MT7621

[Kristian Evensen]

Hello,

On Wed, Nov 8, 2017 at 10:56 PM, Kristian Evensen
<kristian.even...@gmail.com> wrote:
> I have been trying to solve this myself for a couple of days, but I am
> starting to run out of idea. Could it be that there is some traffic
> destined for the client (via. the 2626) that gets stuck in the TX
> queue on the 3526? Any help, pointers on where to look or ideas for
> what could be wrong would be much appreciated.

I have been doing some more debugging during the day today, and it
seems that the problem is that the hardware for some reason stops
transmitting data. I dumped the content of the TX ring on every
timeout, and the output seems to indicate that the state of the ring
is sane. For example, with the following error:

[  325.650638] mtk_soc_eth 1e10.ethernet eth0: transmit timed out
[  325.656857] mtk_soc_eth 1e10.ethernet eth0: dma_cfg:8067
[  325.662902] mtk_soc_eth 1e10.ethernet eth0: tx_ring=0,
base=0ef58000, max=512, ctx=384, dtx=0, fdx=0, next=384
[  325.673234] mtk_soc_eth 1e10.ethernet eth0: rx_ring=0,
base=0ef5e000, max=512, calc=5, drx=6

I see that the CPU txds [384-511] have DDONE set and no SKB, while
DDONE is not set for the DMA txds [0-383] and an skb is attached. I
also looked at the content of the skb, and as far as I can see it is
valid. Looking at the content of the SKB also shows that
fe_reset_pending() does its job. For every timeout, there is a new set
of packets on the ring. So new packets are put on the ring, but none
are sent.

-Kristian

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

Re: [LEDE-DEV] Transmit timeouts with mtk_eth_soc and MT7621

[Kristian Evensen]

Hello,

It turns out that the assumption that the "transmit timed out"-issue
was related to pause frames/flow control was incorrect. I have
recently started to see the error again, with flow control disabled.
However, unlike last time, I am now able to reliably trigger the
issue.

The timeout seems to be triggered by connectivity problems between
MT7621-based routers (not sure if it applies to other devices with the
MT7530 switch) and the next hop. I checked each client connected to
some of the routers exhibiting this issue, and turns out that some had
bad cables, etc.. In order to check the theory in a more controlled
fashion, I set up the following small testbed:

NUC (192.168.1.1) <-> (192.168.1.2) ZBT 3526 (192.168.2.1) <->
(192.168.2.2) ZBT 2626 (192.168.3.1) <-> (192.168.3.2) Client

I then configured port forwarding from the 3526 and all the way to the
client and hammered the client with small UDP packets. Then, at random
points, I intentionally hung the kernel on the 2626 by triggering an
RCU error causing a stall. L2 was still up, but the 2626 does not
reply to any packets, including ARP (so the neighbor-table entry for
192.168.2.2 is quickly lost). More or less as soon as the kernel hung,
the transmit timeout-error message started showing up. If I restart
networking or enable/disable the ports, then everything works fine for
a bit (I can for example ping 192.168.1.1 from 192.168.1.2), but after
some time the error appears again.

I have been trying to solve this myself for a couple of days, but I am
starting to run out of idea. Could it be that there is some traffic
destined for the client (via. the 2626) that gets stuck in the TX
queue on the 3526? Any help, pointers on where to look or ideas for
what could be wrong would be much appreciated.

Thanks in advance for the help,
Kristian

___
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

[Kristian Evensen]

Hi Piotr and Mathias,

On Sun, Nov 5, 2017 at 10:24 PM, Piotr Dymacz <pep...@gmail.com> wrote:
> 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.

Sure, that sounds great. I will take a look and reply in a separate email.

> 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).

Ok, then my test was bogus. Thanks for letting me know.

>
>> * 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.

I agree with Mathias comments in his reply to you. While the default
sample board has 256/16, based on my discussions with Unielec it seems
that the other configurations are also easy to get hold of. I think we
should keep my (minimum) attempt at making it easy to support the
other configurations.

>
>> * 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).
>
> 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 agree and have no problem removing the mt76-part from the pcie node.
One thing I am unsure of is how to specify the EEPROM offset for mt76
cards, since the driver reads that from the dts. There seems to be no
other way to pass configuration data to the driver. However, since
there are so many potential configurations, perhaps some customization
has to be required in order to support specific configs.

>
>> * 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.

Yeah, I know. There is a MAC at e006, but that one is the same for my
two boards at least.

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

True, but I would argue that using web recovery is quicker than scp +
ssh. However, explaining both options sounds good to me.

>
>>
>> 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.

Yes, that is true, so the text should be rewritten a bit I guess.

>
>>
>> Signed-off-by: Kristian Evensen <kristian.even...@gmail.com>
>> ---
>>   .../lin

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

[Kristian Evensen]

Hi,

On Sun, Nov 5, 2017 at 1:47 PM, Kristian Evensen
<kristian.even...@gmail.com> wrote:
> By the way, I sometimes see the board cough up different
> memory-related errors. For example, I have seen seg. faults for
> applications that are run on startup, messages like "CPU 3 Unable to
> handle kernel paging request at virtual address 1f9c, epc ==
> 80109d2c, ra == 8010a548" and "page dumped because: nonzero _count". I
> have compared the memory layout, etc. of LEDE to that of the factory
> firmware and it all seems to match up. Do you have any ideas what
> might be wrong? I did a search and found some similar ramips-related
> issues, but they all seem to have dealt with.

Please ignore this one, as the problem seems to be caused by faulty
hardware. I have two boards and one always displays these errors after
~5 reboots, while the other has now survived 20+ reboots and
re-flashes. Now that I was looking for these errors, I also see them
when using the factory firmware.

-Kristian

___
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

[Kristian Evensen]

Hi again,

On Sun, Nov 5, 2017 at 12:14 PM, Mathias Kresin  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

___
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

[Kristian Evensen]

Hi Mathias,

Thanks for your comments.

On Sun, Nov 5, 2017 at 12:14 PM, Mathias Kresin <d...@kresin.me> wrote:
> 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.

I hope I know what I am doing at least :) The factory firmware
supports exporting all pins, so I checked each one and the only one
that triggered a reaction was 16. I also checked the different LEDs in
/sys/class/led. 18 was verified using the bootloader.

>> --- 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.

Thanks for pointing this out. I had originally left "Unielec" out of
the model and forgot to update this file when I added the name.

>
>
>> 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 <kristian.even...@gmail.com>.
>> + *  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 w

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

[Kristian Evensen]

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:

* CPU: MT7621 (880Mhz)
* 5x 10/100/1000Mbps ports.
* 8/16/32/64 MB Flash.
* 256/512 MB RAM.
* 1x USB 3.0 port.
* 1x mini-PCIe slot intended for either a modem or an mSata disk.
* 2x normal mini-PCIe slots.
* 1x SIM slots.
* 1x button.
* 1x mico SD-card reader.

Works:
* Wifi.
* Switch.
* The normal mini-PCIe slots.
* The modem/mSata mini-PCIe slot (only tested with a modem).
* SIM slot.
* Sysupgrade.
* Button (reset).
* micro SD-card reader.

Not working:
-

Notes:
* According to the specifications on the Unielec website, two LEDs
should be controllable via GPIO. I was not able to find the pins.
* 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.
* I have assumed that the placement of wifi cards will be as on the image on
the Unielec website linked to above.
* 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.

Installation:

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

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.

Signed-off-by: Kristian Evensen <kristian.even...@gmail.com>
---
 .../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/U7621-6-256M-16M.dts   |  54 
 target/linux/ramips/dts/U7621-6.dtsi   | 147 +
 target/linux/ramips/image/mt7621.mk|   9 ++
 6 files changed, 215 insertions(+)
 create mode 100644 target/linux/ramips/dts/U7621-6-256M-16M.dts
 create mode 100644 target/linux/ramips/dts/U7621-6.dtsi

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 1c8505e8c7..8530ca5170 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -102,6 +102,7 @@ ramips_setup_interfaces()
r6220|\
sap-g3200u3|\
sk-wb8|\
+   u7621-6-256M-16M|\
vr500|\
wf-2881|\
witi|\
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index 07e776cb0c..e937fa5701 100755
--- 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"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index 99ebe35b44..0eb808c3ce 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -145,6 +145,7 @@ platform_check_image() {
timecloud|\
tiny-ac|\
u25awf-h1|\
+   u7621-6-256M-16M|\
ur-326n4g|\
ur-336un|\
v22rw-2x2|\
diff --git a/target/linux/ramips/dts/U7621-6-256M-16M.dts 
b/target/linux/ramips/dts/U7621-6-256M-16M.dts
new file mode 100644
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 <kristian.even...@gmail.com>.
+ *  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 f

Re: [LEDE-DEV] Transmit timeouts with mtk_eth_soc and MT7621

[Kristian Evensen]

Hi John,

On Sat, Aug 19, 2017 at 8:16 PM, John Crispin  wrote:
> Hi All,
>
> i have a staged commit on my laptop that makes all the (upstream) ethernet
> fixes that i pushed to mt7623 work on mt7621. please hang on for a few more
> days till i finished testing the support. this will add latest upstream
> ethernet support + DSA

Any update on these patches?

Best regards,
Kristian

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

[LEDE-DEV] [PATCH] procd: Restore respawn on SIGTERM timeout

[Kristian Evensen]

When SIGTERM times out, procd sends SIGKILL and then restarts the
process once SIGCHLD has been received. This all works fine, with one
exception - respawn is not restored when instance_start() is called from
instance_exit(). The reason is that respawn is always set to false in
instance_stop(), and the same service_instance struct is used for the
instance_start()-call.

The consequence is that if the process is killed/crashes again, it will
not respawn. Solve this issue by adding a variable used to store the
original value of respawn in instance_stop(), and then restore the
original respawn-value in instance_exit().

Signed-off-by: Kristian Evensen <kristian.even...@gmail.com>
---
 service/instance.c | 6 --
 service/instance.h | 1 +
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/service/instance.c b/service/instance.c
index b7cb523..76c74ed 100644
--- a/service/instance.c
+++ b/service/instance.c
@@ -532,9 +532,10 @@ instance_exit(struct uloop_process *p, int ret)
 
if (in->halt) {
instance_removepid(in);
-   if (in->restart)
+   if (in->restart) {
+   in->respawn = in->respawn_org;
instance_start(in);
-   else {
+   } else {
struct service *s = in->srv;
 
avl_delete(>instances.avl, >node.avl);
@@ -567,6 +568,7 @@ instance_stop(struct service_instance *in, bool halt)
if (!in->proc.pending)
return;
in->halt = halt;
+   in->respawn_org = in->respawn;
in->restart = in->respawn = false;
kill(in->proc.pid, SIGTERM);
uloop_timeout_set(>timeout, in->term_timeout * 1000);
diff --git a/service/instance.h b/service/instance.h
index bdd14de..a0ac302 100644
--- a/service/instance.h
+++ b/service/instance.h
@@ -48,6 +48,7 @@ struct service_instance {
bool halt;
bool restart;
bool respawn;
+   bool respawn_org;
int respawn_count;
int reload_signal;
struct timespec start;
-- 
2.11.0


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

[LEDE-DEV] [PATCH] ramips: Add support for ZBT WE1026-5G

[Kristian Evensen]

The ZBT WE1026-5G
(http://www.zbtlink.com/products/router/WE1026-5G.html) is the follow-up
to the ZBT WE1026 and is based on MT7620. For the previous WE1026, the
ZBT WE826 image could be used. However, as the name implies, the -5G
comes equipped with a 5GHz wifi radio. As the WE826 only has a 2.4GHz
radio, the addition of 5GHz means that a separate image is needed for
the WE1026-5G. I suspect that this image will also work on the previous
WE1026, but I don't have a device to test with.

The WE1026-5G has 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 5GHz wifi (MT7612)
* 1x button.
* 3x controllable LEDs.

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

Not working:
* The 5GHz WIFI LED is completely dead. I suspect the issue is the same
as on other devices with Mediatek 5Ghz wifi-cards/chips. The LED is
controlled by the driver, and mt76 (currently) does not support this.

Not tested:
* SD card reader.

Notes:
* The modem (labeled 3G/4G) and power LEDs are controlled by the
hardware.
* There is a 32MB version of this device available, but I do not have
access to it. I have therefor only added support for the 16MB version,
but added all the required infrastructure to make adding support for the
32MB version easy.

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 WE1026-5G supports recovery using HTTP. Keep the
reset button pressed for ~5sec when booting to start the web server. Set the
address of the network interface on your machine to 192.168.1.2/24, and
point your browser to 192.168.1.1 to access the recovery UI. From the
recovery UI you can upload a firmware image.

Signed-off-by: Kristian Evensen <kristian.even...@gmail.com>
---
 target/linux/ramips/base-files/etc/board.d/01_leds |   5 +
 .../linux/ramips/base-files/etc/board.d/02_network |   3 +-
 target/linux/ramips/base-files/lib/ramips.sh   |   3 +
 .../ramips/base-files/lib/upgrade/platform.sh  |   1 +
 target/linux/ramips/dts/WE1026-5G-16M.dts  |  76 +
 target/linux/ramips/dts/WE1026-5G.dtsi | 124 +
 target/linux/ramips/image/mt7620.mk|   9 ++
 7 files changed, 220 insertions(+), 1 deletion(-)
 create mode 100644 target/linux/ramips/dts/WE1026-5G-16M.dts
 create mode 100644 target/linux/ramips/dts/WE1026-5G.dtsi

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 83e1a94000..f6a7bac81a 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -379,6 +379,11 @@ w502u)
 wcr-150gn)
set_usb_led "$board:amber:user"
;;
+we1026-5g-16m)
+   ucidef_set_led_netdev "lan" "LAN" "we1026-5g:green:lan" "eth0"
+   set_wifi_led "we1026-5g:green:wifi"
+   set_usb_led "we1026-5g:green:usb" "1-1.1"
+   ;;
 whr-1166d|\
 whr-300hp2|\
 whr-600d)
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 9284b1812f..6f05259467 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -323,7 +323,8 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"3:lan" "4:wan" "6@eth0"
;;
-   wcr-150gn)
+   wcr-150gn|\
+   we1026-5g-16m)
ucidef_add_switch "switch0" \
"0:lan" "6t@eth0"
;;
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index 174e29e434..d0055d422b 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() {
*"WCR-150GN")
name="wcr-150gn"
;;
+   *"WE1026-5G (16M)")
+   name="we1026-5g-16m"
+   ;;
*"WF-2881")
name="wf-2881"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index 5cfca52ab1..09a7dae394 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/u

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

[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. Only power is connected, this port is meant for
charging other devices.
* 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 (also applies to the factory firmware):
* Wifi LED. It is always switched on, there is no relation to the
up/down state or activity of the wireless interface.

Not tested:
* SD card reader.

Notes:
* The C108 has no dedicated status LED. I therefore set the LAN LED as
status LED.

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.

v3->v4:
* Fixed typo in diag.sh.

v2->v3:
* Update description of USB port after discussing with factory.
* Updated Wifi LED description (thanks Mathias Kresin).
* Removed non-used GPIO bank and invalid portmap from dts, as well as
using absolute value for the gpio output value (thanks Mathias Kresin).
* Update size of firmware parition in Makefile to match factory firmware
(thanks Mathias Kresin).
* Respect ordering in diag.sh (thanks Mathias Kresin).

v1->v2:
* Update "Not working" based on more testing with factory firmware.
* Changed offset of LAN MAC address.

Signed-off-by: Kristian Evensen <kristian.even...@gmail.com>
---
 target/linux/ramips/base-files/etc/board.d/01_leds |   4 +
 .../linux/ramips/base-files/etc/board.d/02_network |   1 +
 target/linux/ramips/base-files/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   | 177 +
 target/linux/ramips/image/mt7620.mk|   8 +
 7 files changed, 197 insertions(+)
 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
index ff5d156f2c..83e1a94000 100755
--- 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..9284b1812f 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"
diff --git a/target/linux/ramips/base-files/etc/diag.sh 
b/target/linux/ramips/base-files/etc/diag.sh
index 960e189283..75171673bb 100644
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -103,6 +103,9 @@ get_status_led() {
wrh-300cr)
status_led="$board:green:wps"
;;
+   c108)
+   status_led="$board:green:lan"
+   ;;
cf-wr800n|\
psg1208)
status_led="$board:white:wps"
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index fe66a87c2e..174e29e434 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-fi

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

[Kristian Evensen]

On Wed, Sep 6, 2017 at 10:35 AM, Kristian Evensen
<kristian.even...@gmail.com> wrote:
> 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. Only power is connected, this port is meant for
> charging other devices.
> * 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 (also applies to the factory firmware):
> * Wifi LED. It is always switched on, there is no relation to the
> up/down state or activity of the wireless interface.
>
> Not tested:
> * SD card reader.
>
> Notes:
> * The C108 has no dedicated status LED. I therefore set the LAN LED as
> status LED.
>
> 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.
>
> v2->v3:
> * Update description of USB port after discussing with factory.
> * Updated Wifi LED description (thanks Mathias Kresin).
> * Removed non-used GPIO bank and invalid portmap from dts, as well as
> using absolute value for the gpio output value (thanks Mathias Kresin).
> * Update size of firmware parition in Makefile to match factory firmware
> (thanks Mathias Kresin).
> * Respect ordering in diag.sh (thanks Mathias Kresin).
>
> v1->v2:
> * Update "Not working" based on more testing with factory firmware.
> * Changed offset of LAN MAC address.
>
> Signed-off-by: Kristian Evensen <kristian.even...@gmail.com>
> ---
>  target/linux/ramips/base-files/etc/board.d/01_leds |   4 +
>  .../linux/ramips/base-files/etc/board.d/02_network |   1 +
>  target/linux/ramips/base-files/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   | 177 
> +
>  target/linux/ramips/image/mt7620.mk|   8 +
>  7 files changed, 197 insertions(+)
>  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
> index ff5d156f2c..83e1a94000 100755
> --- 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..9284b1812f 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"
> diff --git a/target/linux/ramips/base-files/etc/diag.sh 
> b/target/linux/ramips/base-files/etc/diag.sh
> index 960e189283..74352530b0 100644
> --- a/target/linux/ramips/base-files/etc/diag.sh
&g

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

[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. Only power is connected, this port is meant for
charging other devices.
* 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 (also applies to the factory firmware):
* Wifi LED. It is always switched on, there is no relation to the
up/down state or activity of the wireless interface.

Not tested:
* SD card reader.

Notes:
* The C108 has no dedicated status LED. I therefore set the LAN LED as
status LED.

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.

v2->v3:
* Update description of USB port after discussing with factory.
* Updated Wifi LED description (thanks Mathias Kresin).
* Removed non-used GPIO bank and invalid portmap from dts, as well as
using absolute value for the gpio output value (thanks Mathias Kresin).
* Update size of firmware parition in Makefile to match factory firmware
(thanks Mathias Kresin).
* Respect ordering in diag.sh (thanks Mathias Kresin).

v1->v2:
* Update "Not working" based on more testing with factory firmware.
* Changed offset of LAN MAC address.

Signed-off-by: Kristian Evensen <kristian.even...@gmail.com>
---
 target/linux/ramips/base-files/etc/board.d/01_leds |   4 +
 .../linux/ramips/base-files/etc/board.d/02_network |   1 +
 target/linux/ramips/base-files/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   | 177 +
 target/linux/ramips/image/mt7620.mk|   8 +
 7 files changed, 197 insertions(+)
 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
index ff5d156f2c..83e1a94000 100755
--- 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..9284b1812f 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"
diff --git a/target/linux/ramips/base-files/etc/diag.sh 
b/target/linux/ramips/base-files/etc/diag.sh
index 960e189283..74352530b0 100644
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -103,6 +103,9 @@ get_status_led() {
wrh-300cr)
status_led="$board:green:wps"
;;
+   c108)
+   status_len="$board:green:lan"
+   ;;
cf-wr800n|\
psg1208)
status_led="$board:white:wps"
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index fe66a87c2e..174e29e434 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -85,6 +85,9 @@ ram

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

[Kristian Evensen]

On Wed, Sep 6, 2017 at 10:07 AM, Mathias Kresin <d...@kresin.me> wrote:
> 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.

Thanks for the comments. Preparing a v3 now, will send it after some
quick testing.

-Kristian

___
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

[Kristian Evensen]

Hi,

On Wed, Sep 6, 2017 at 9:46 AM, John Crispin  wrote:
> the mt7620 only has 1 usb port. if the minipcie usb works, then its wired
> there. maybe there is a gpio to switch between internal modem port and
> external port ?

Thanks for the help! I just spoke to the factory and it turns out that
port is meant for charging other devices, so data is not connected.

-Kristian

___
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

[Kristian Evensen]

Hi,

Thanks for the feedback.

On Wed, Sep 6, 2017 at 9:03 AM, Mathias Kresin  wrote:
>> 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?

Not detected and no error messages, so it seems to be completely dead.
I see the same with the default firmware. Will update comment. If you
have any hints or tips on how to enable it, then that would be great.

>
>> * 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.

>> 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.

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.

>> + {
>> +   status = "okay";
>> +};
>
>
> gpio3 is enabled but not used. either use the only available GPIO on this
> gpio bank or drop it.

Thanks, will remove it.

>> + {
>> +   mtd-mac-address = < 0x4>;
>> +   mediatek,portmap = "l";
>
>
> Beside that fact that I'm not sure if the property is supported by the
> driver, it looks wrong. The mediatek,portmap property can be only "w" or
> "w".

Yes, that is correct, but I saw that for another device (MR200) a
non-supported portmap is used (""). So I thought it was ok to add,
in case the portmap will in the future support more values (the driver
anyway ignores maps different than the two you mention). But I will
remove it for v3.

>> diff --git a/target/linux/ramips/image/mt7620.mk
>> b/target/linux/ramips/image/mt7620.mk
>> index f9a9fdb84c..0061a018b9 100644
>> --- a/target/linux/ramips/image/mt7620.mk
>> +++ b/target/linux/ramips/image/mt7620.mk
>> @@ -62,6 +62,14 @@ define Device/ArcherMR200
>>   endef
>>   TARGET_DEVICES += ArcherMR200
>>   +define Device/c108
>> +  DTS := C108
>> +  IMAGE_SIZE := $(ralink_default_fw_size_16M)
>
>
> Doesn't match the size of your firmware partition.
>
> ralink_default_fw_size_16M == 16121856 == 0xF6

Good catch, thanks. I based the dts on the dts of another 16MB mt7620
device. I will take a look at the bootlog of the default firmware and
correct firmware size.

Thanks again for all the feedback.

-Kristian

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

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

[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 (both of these also applies to the factory firmware):
* USB port.
* Wifi LED. It is always switched on.

Not tested:
* SD card reader.

Notes:
* The C108 has no dedicated status LED. I therefore set the LAN LED as
status LED.
* 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.

v1->v2:
* Update "Not working" based on more testing with factory firmware.
* Changed offset of LAN MAC address.

Signed-off-by: Kristian Evensen <kristian.even...@gmail.com>
---
 target/linux/ramips/base-files/etc/board.d/01_leds |   4 +
 .../linux/ramips/base-files/etc/board.d/02_network |   1 +
 target/linux/ramips/base-files/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, 202 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..9284b1812f 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"
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"
+   ;;
esac
 }
 
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index fe66a87c2e..174e29e434 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -85,6 +85,9 @@ ramips_board_detect() {
*"Broadway")
name="broadway"
;;
+   *"C108")
+   name="c108"
+   ;;
*"C20i")
name="c20i"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-file

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

[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.
* Wifi LED. It is always switched on.

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 <kristian.even...@gmail.com>
---
 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
+++ 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"
+   ;;
esac
 }

[LEDE-DEV] [PATCH] ramips: Improve stability of the mt7621 switch

[Kristian Evensen]

The switch on the mt7621 soc seems to sometimes struggle with Ethernet
pause frames. If a pause frame is received at the incorrect time, the
switch will for some reason hang and no data can be sent. Most of the
time, a router has to be rebooted before the switch will work again,
while sometimes the switch recovers by itself. I am able to reliably
trigger this error on the ZBT WG2926 and 3526 by saturating the
router/switch with small (<100B) packets, or by spamming the router with
pause frames while sending traffic. The error message looks something
like this (and will in most cases loop over and over):

[10203960.26] mtk_soc_eth 1e10.ethernet eth0: transmit timed out
[10203960.26] mtk_soc_eth 1e10.ethernet eth0: dma_cfg:8065
[10203960.27] mtk_soc_eth 1e10.ethernet eth0: tx_ring=0,
base=0ef1, max=512, ctx=118, dtx=118, fdx=117, next=118
[10203960.28] mtk_soc_eth 1e10.ethernet eth0: rx_ring=0,
base=0ef12000, max=512, calc=380, drx=381

This commit works around the issue by not advertising pause frame
support during auto negotiation. However, I have found at least one
switch which sends pause frames anyway. In case a pause frame is sent
and triggers the error, we reset all ports on the switch. This also
makes the switch work properly again.

Without this change, my routers would crash within 15 minutes when
testing. With the change, the same test has been running for three days
without any problems. Disabling pause frames is maybe not ideal, but
since this error only happens when the router/switch is completely
swamped, then users/protocols/applications should not notice a
difference. It might even be better to drop packets right away, than to
buffer them for a given time.

Signed-off-by: Kristian Evensen <kristian.even...@gmail.com>
---
 .../drivers/net/ethernet/mtk/gsw_mt7621.c  |  8 +++
 .../drivers/net/ethernet/mtk/mtk_eth_soc.c |  3 +++
 .../drivers/net/ethernet/mtk/mtk_eth_soc.h |  1 +
 .../drivers/net/ethernet/mtk/soc_mt7621.c  | 26 ++
 4 files changed, 38 insertions(+)

diff --git 
a/target/linux/ramips/files-4.9/drivers/net/ethernet/mtk/gsw_mt7621.c 
b/target/linux/ramips/files-4.9/drivers/net/ethernet/mtk/gsw_mt7621.c
index 3adad48c88..9814dae8fa 100644
--- a/target/linux/ramips/files-4.9/drivers/net/ethernet/mtk/gsw_mt7621.c
+++ b/target/linux/ramips/files-4.9/drivers/net/ethernet/mtk/gsw_mt7621.c
@@ -186,6 +186,14 @@ static void mt7621_hw_init(struct mt7620_gsw *gsw, struct 
device_node *np)
mt7530_mdio_w32(gsw, 0x7a74, 0x44);
mt7530_mdio_w32(gsw, 0x7a7c, 0x44);
 
+   /* Disable pause frame  */
+   for (i = 0; i <= 4; i++) {
+   val = _mt7620_mii_read(gsw, i, 0x04);
+   pr_info("Auto-negotiate register: %u %x\n", i, val);
+   val &= ~BIT(10);
+   _mt7620_mii_write(gsw, i, 0x04, val);
+   }
+
/* turn on all PHYs */
for (i = 0; i <= 4; i++) {
val = _mt7620_mii_read(gsw, i, 0);
diff --git 
a/target/linux/ramips/files-4.9/drivers/net/ethernet/mtk/mtk_eth_soc.c 
b/target/linux/ramips/files-4.9/drivers/net/ethernet/mtk/mtk_eth_soc.c
index 5f4afade06..de5b97a996 100644
--- a/target/linux/ramips/files-4.9/drivers/net/ethernet/mtk/mtk_eth_soc.c
+++ b/target/linux/ramips/files-4.9/drivers/net/ethernet/mtk/mtk_eth_soc.c
@@ -1426,6 +1426,9 @@ static void fe_reset_pending(struct fe_priv *priv)
dev_close(dev);
}
rtnl_unlock();
+
+   if (priv->soc->reset_ports)
+   priv->soc->reset_ports(priv);
 }
 
 static const struct fe_work_t fe_work[] = {
diff --git 
a/target/linux/ramips/files-4.9/drivers/net/ethernet/mtk/mtk_eth_soc.h 
b/target/linux/ramips/files-4.9/drivers/net/ethernet/mtk/mtk_eth_soc.h
index 05f550fa26..0539ce4761 100644
--- a/target/linux/ramips/files-4.9/drivers/net/ethernet/mtk/mtk_eth_soc.h
+++ b/target/linux/ramips/files-4.9/drivers/net/ethernet/mtk/mtk_eth_soc.h
@@ -392,6 +392,7 @@ struct fe_soc_data {
  u16 val);
int (*mdio_read)(struct mii_bus *bus, int phy_addr, int phy_reg);
void (*mdio_adjust_link)(struct fe_priv *priv, int port);
+   void (*reset_ports)(struct fe_priv *priv);
 
void *swpriv;
u32 pdma_glo_cfg;
diff --git 
a/target/linux/ramips/files-4.9/drivers/net/ethernet/mtk/soc_mt7621.c 
b/target/linux/ramips/files-4.9/drivers/net/ethernet/mtk/soc_mt7621.c
index ce41b342e7..8f9dc35875 100644
--- a/target/linux/ramips/files-4.9/drivers/net/ethernet/mtk/soc_mt7621.c
+++ b/target/linux/ramips/files-4.9/drivers/net/ethernet/mtk/soc_mt7621.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -157,6 +158,30 @@ static void mt7621_set_mac(struct fe_priv *priv, unsigned 
char *mac)
spin_unlock_irqrestore(>page_lock, flags);
 }
 
+static void mt7621_reset_ports(struct fe_priv *priv)
+{
+   struct mt762

Re: [LEDE-DEV] Transmit timeouts with mtk_eth_soc and MT7621

[Kristian Evensen]

Hello again,

On Sat, Aug 26, 2017 at 4:57 PM, Kristian Evensen
<kristian.even...@gmail.com> wrote:
> I did not have to wait very long before anything. Unfortunately, my
> router crashed right after I sent the previous email. So I guess that
> means back to the drawing board.

I have kept working on this issue throughout the weekend and have
noticed something strange. I don't know if this observation is
relevant or not, and I still haven't found out why the queue times out
(why the queue is stopped), but perhaps the observation can help point
us in the right direction.

I noticed that TX_WB_DDONE is set, so I decided to dump the state of
each txd when the timeout occurs. When I do this (and the timeout has
been triggered), I see that dtx always point to txds with DDONE set,
while ctx points to txds where DDONE is not set. To me, this seems to
be the inverse of how it should be. I.e., dtx should point to a txd
where DDONE is not set, while ctx to should point to a txd with DDONE
set. Could it be that these counters/indexes for some reason goes out
of sync and that this triggers the timeout? There is data to be sent,
but it is not seen.

To give a more complete example, say we have the following error:
[ 1816.133130] mtk_soc_eth 1e10.ethernet eth0: transmit timed out
[ 1816.139304] mtk_soc_eth 1e10.ethernet eth0: dma_cfg:8067
[ 1816.145288] mtk_soc_eth 1e10.ethernet eth0: tx_ring=0,
base=0ee44000, max=512, ctx=302, dtx=202, fdx=202, next=302
[ 1816.155968] mtk_soc_eth 1e10.ethernet eth0: rx_ring=0,
base=0ec0e000, max=512, calc=486, drx=484

Here, txd[202-301] have DDONE set, while DDONE is not set for txd[302-201].

Thanks in advance for all the help so far,
Kristian

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

Re: [LEDE-DEV] Transmit timeouts with mtk_eth_soc and MT7621

[Kristian Evensen]

Hi,

On Sat, Aug 26, 2017 at 4:47 PM, Kristian Evensen
<kristian.even...@gmail.com> wrote:
> I guess our common theory is that something is causing TX interrupts
> not to be enabled again. After reading up on NAPI
> (https://wiki.linuxfoundation.org/networking/napi), it seems that the
> recommended way of using NAPI on clear-on-write devices (like the
> RT5350) is to use NAPI for RX and do TX in the interrupt handler. In
> the current driver, both TX and RX is handled in the NAPI-callback
> fe_poll(). I have modified the driver to split RX and TX, so now
> fe_poll() only deals with RX and TX is dealt with in fe_handle_irq().
> I have attached the (messy) patch I am currently testing. If this is
> an OK solution, I will clean up the patch and submit is to the list. I
> will leave my tests running overnight and report back if anything pops
> up.

I did not have to wait very long before anything. Unfortunately, my
router crashed right after I sent the previous email. So I guess that
means back to the drawing board.

-Kristian

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

Re: [LEDE-DEV] Transmit timeouts with mtk_eth_soc and MT7621

[Kristian Evensen]

Hello again,

On Sat, Aug 26, 2017 at 12:38 PM, Kristian Evensen
<kristian.even...@gmail.com> wrote:
> Hi,
>
> On Sat, Aug 26, 2017 at 7:43 AM, Mingyu Li <igv...@gmail.com> wrote:
>> Hi.
>>
>> i check the code again. found xmit_more can cause tx timeout. you can
>> reference this.
>> https://www.mail-archive.com/netdev@vger.kernel.org/msg123334.html
>> so the patch should be like this. edit mtk_eth_soc.c
>>
>> tx_num = fe_cal_txd_req(skb);
>> if (unlikely(fe_empty_txd(ring) <= tx_num)) {
>> +if (skb->xmit_more)
>> +fe_reg_w32(ring->tx_next_idx, FE_REG_TX_CTX_IDX0);
>> netif_stop_queue(dev);
>> netif_err(priv, tx_queued, dev,
>>   "Tx Ring full when queue awake!\n");
>>
>> but i am not sure. maybe the pause frame cause the problem.
>
> Thanks for the patch. I tested it, but I unfortunately still see the
> error. I also added a print-statement inside the conditional and can
> see that the condition is never hit. I also don't see the "Tx Ring
> full"-message. One difference which I noticed now though, is that I
> don't see the bursty bandwidth pattern I described earlier (32, 0, 32,
> 0, ...). With your patch, it is always 32, 0, crash.

I spent some more time looking into this today and think I might have
been able to solve the issue. My test has been running for ~2 hours
now without any errors (before it would best-case work for 10-15
minutes), and I do not see any performance regressions. Before going
into detail, I should probably point out that I am not very familiar
with driver development, so my observation changes might not be
appropriate/correct :)

I guess our common theory is that something is causing TX interrupts
not to be enabled again. After reading up on NAPI
(https://wiki.linuxfoundation.org/networking/napi), it seems that the
recommended way of using NAPI on clear-on-write devices (like the
RT5350) is to use NAPI for RX and do TX in the interrupt handler. In
the current driver, both TX and RX is handled in the NAPI-callback
fe_poll(). I have modified the driver to split RX and TX, so now
fe_poll() only deals with RX and TX is dealt with in fe_handle_irq().
I have attached the (messy) patch I am currently testing. If this is
an OK solution, I will clean up the patch and submit is to the list. I
will leave my tests running overnight and report back if anything pops
up.

I guess that Johns new driver is the future for mtk_sock_eth, but I
believe that fixing this issue for the current driver is worthwhile.
As things are now, is it possible to DDOS RT5350-based routers running
LEDE 17.01 by just sending the correct type of traffic.

-Kristian
From 98ce0313cd8654fe69028c19b6f08da1d0671d75 Mon Sep 17 00:00:00 2001
From: Kristian Evensen <kristian.even...@gmail.com>
Date: Sat, 26 Aug 2017 16:05:44 +0200
Subject: [PATCH] [FIX] Move TX out of Napi

This is a broken patch only meant for backup.
---
 .../drivers/net/ethernet/mtk/mtk_eth_soc.c | 36 +-
 1 file changed, 28 insertions(+), 8 deletions(-)

diff --git a/target/linux/ramips/files-4.9/drivers/net/ethernet/mtk/mtk_eth_soc.c b/target/linux/ramips/files-4.9/drivers/net/ethernet/mtk/mtk_eth_soc.c
index 5b354a6563..af865826e8 100644
--- a/target/linux/ramips/files-4.9/drivers/net/ethernet/mtk/mtk_eth_soc.c
+++ b/target/linux/ramips/files-4.9/drivers/net/ethernet/mtk/mtk_eth_soc.c
@@ -684,10 +684,13 @@ static int fe_tx_map_dma(struct sk_buff *skb, struct net_device *dev,
 	 */
 	wmb();
 	if (unlikely(fe_empty_txd(ring) <= ring->tx_thresh)) {
+pr_info_ratelimited("netif_stop_queue %u %u\n", fe_empty_txd(ring), ring->tx_thresh);
 		netif_stop_queue(dev);
 		smp_mb();
-		if (unlikely(fe_empty_txd(ring) > ring->tx_thresh))
+		if (unlikely(fe_empty_txd(ring) > ring->tx_thresh)) {
+pr_info_ratelimited("netif_wake_queue\n");
 			netif_wake_queue(dev);
+}
 	}
 
 	if (netif_xmit_stopped(netdev_get_tx_queue(dev, 0)) || !skb->xmit_more)
@@ -781,6 +784,10 @@ static int fe_start_xmit(struct sk_buff *skb, struct net_device *dev)
 
 	tx_num = fe_cal_txd_req(skb);
 	if (unlikely(fe_empty_txd(ring) <= tx_num)) {
+if (skb->xmit_more) {
+pr_info_ratelimited("SKB XMIT_MORE\n");
+fe_reg_w32(ring->tx_next_idx, FE_REG_TX_CTX_IDX0);
+}
 		netif_stop_queue(dev);
 		netif_err(priv, tx_queued, dev,
 			  "Tx Ring full when queue awake!\n");
@@ -967,11 +974,12 @@ static int fe_poll(struct napi_struct *napi, int budget)
 		status_reg = FE_REG_FE_INT_STATUS;
 	}
 
+/*
if (status & tx_intr) {
fe_reg_w32(tx_intr, FE_REG_FE_INT_STATUS);
tx_done = fe_poll_tx(priv);
status = fe_reg_r32(FE

Re: [LEDE-DEV] Transmit timeouts with mtk_eth_soc and MT7621

[Kristian Evensen]

Hi,

On Sat, Aug 26, 2017 at 7:43 AM, Mingyu Li  wrote:
> Hi.
>
> i check the code again. found xmit_more can cause tx timeout. you can
> reference this.
> https://www.mail-archive.com/netdev@vger.kernel.org/msg123334.html
> so the patch should be like this. edit mtk_eth_soc.c
>
> tx_num = fe_cal_txd_req(skb);
> if (unlikely(fe_empty_txd(ring) <= tx_num)) {
> +if (skb->xmit_more)
> +fe_reg_w32(ring->tx_next_idx, FE_REG_TX_CTX_IDX0);
> netif_stop_queue(dev);
> netif_err(priv, tx_queued, dev,
>   "Tx Ring full when queue awake!\n");
>
> but i am not sure. maybe the pause frame cause the problem.

Thanks for the patch. I tested it, but I unfortunately still see the
error. I also added a print-statement inside the conditional and can
see that the condition is never hit. I also don't see the "Tx Ring
full"-message. One difference which I noticed now though, is that I
don't see the bursty bandwidth pattern I described earlier (32, 0, 32,
0, ...). With your patch, it is always 32, 0, crash.

-Kristian

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

Re: [LEDE-DEV] Transmit timeouts with mtk_eth_soc and MT7621

[Kristian Evensen]

Hi all,

On Sun, Aug 20, 2017 at 12:30 AM, John Crispin  wrote:
> correct, in my testing i have been ... with 200 parallel flows ... on
> MT7623, we'll have to find out what mt7621 can achieve ... this is all using
> hwnat ...
> 1) tcp - at 50 byte frames i am able to pass 720 MBit which is > 1M FPS
> 2) udp - at 128 byte frames i am able to pass ~450k FPS at ~10% packet loss
> .. at near wirespeed

I have spent the last two days looking into this. My testing was based
on LEDE master as of yesterday morning and my initial test setup was
the following:

Server (Intel NUC) <-> Gbit Switch <-> ZBT 2926 <-> Client

The switch was tested and confirmed working at gigabit speeds. I used
iperf for my tests, with a payload of 100B and configured port
forwarding of UDP port 1203 from ZBT to client. I then ran the
following command on the NUC in a loop:

iperf -u -c 10.1.2.63 -t 3600 -d -p 1203 -l 100B -b 1000M

I left the test running over night (around 16 hours of pushing data),
but no error had been triggered as of this morning. Using bwm-ng, I
saw that the NUC was able to push around 40 Mbit/s, which, based on
earlier tests I have done where I have used the NUC as traffic
generator, seemed a bit low. I don't know if it is relevant, but when
capturing traffic (on both NUC and client) I saw pause packets quite
frequently.

Since this tests did not yield any result, and throughput was low, I
looked at some of the setups where I have seen this error. In all
setups, there is always something placed in front of the 2926 (a
router, switch, ...). I therefore modified my test setup to be as
follows:

Server (Intel NUC) <-> Gbit Switch <-> ZBT 2926 #1 <-> ZBT 2926 #2 <-> Client

I forwarded port 1203 on the new ZBT router and repeated the
experiment. Using this setup, the NUC pushed about 260Mbit/s and I am
reliably able to trigger the error within ~1000 seconds. The error is
always seen on ZBT #1, and sometimes on ZBT #2. If I see the error on
#2 it is always at a later time than #1, so it seems that the two
routers somehow affect each other. When looking at the RX bandwidth on
the client (using bwm-ng), I see that it is very bursty. I receive
data at about 32Mbit/s, then no data for a while, then back to around
32 Mbit/s, and so on, until the error is triggered and switch (TX) on
the router(s) die. Pause frames are also seen on both server and
client in this experiment.

After having found a way to reliably trigger the issue, I tested the
patch provided by Mingyu. With this patch, the error is triggered much
faster, usually after around 300 seconds.

Mingyu, do you have any other ideas on what could be wrong or how to fix this?

John, would it be possible to get access to your staged commit, so
that I can repeat the test using your new code?

Thanks for all the help,
Kristian

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

[LEDE-DEV] [PATCH] Add missing APU1 reference to x86 board.d

[Kristian Evensen]

x86 board.d only contains a case for the APU2, not the APU1. This
causes, for example, network configuration not to be created correctly.
Even though the APU1 seems to reaching EOL, there a still a lot of them
out there.

The APU1 and APU2 is configured in the same way and this patch should
also be considered for stable, as the error also exists there.

Signed-off-by: Kristian Evensen <kristian.even...@gmail.com>
---
 target/linux/x86/base-files/etc/board.d/01_leds| 2 +-
 target/linux/x86/base-files/etc/board.d/02_network | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/target/linux/x86/base-files/etc/board.d/01_leds 
b/target/linux/x86/base-files/etc/board.d/01_leds
index 03df810972..6a5ff03b37 100755
--- a/target/linux/x86/base-files/etc/board.d/01_leds
+++ b/target/linux/x86/base-files/etc/board.d/01_leds
@@ -10,7 +10,7 @@ board_config_update
 board=$(cat /tmp/sysinfo/board_name) 2>/dev/null
 
 case "$board" in
-pc-engines-apu2)
+pc-engines-apu|pc-engines-apu2)
ucidef_set_led_netdev "wan" "WAN" "apu2:green:led3" "eth0"
ucidef_set_led_netdev "lan" "LAN" "apu2:green:led2" "br-lan"
ucidef_set_led_default "diag" "DIAG" "apu2:green:power" "1"
diff --git a/target/linux/x86/base-files/etc/board.d/02_network 
b/target/linux/x86/base-files/etc/board.d/02_network
index c2af64336b..5bfe609740 100755
--- a/target/linux/x86/base-files/etc/board.d/02_network
+++ b/target/linux/x86/base-files/etc/board.d/02_network
@@ -11,7 +11,7 @@ board_config_update
 board="$(cat /tmp/sysinfo/board_name)" 2>/dev/null
 
 case "$board" in
-pc-engines-apu2)
+pc-engines-apu|pc-engines-apu2)
ucidef_set_interfaces_lan_wan "eth1 eth2" "eth0"
;;
 traverse-technologies-geos)
-- 
2.11.0


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

Re: [LEDE-DEV] WG: [source] ramips: add support for Sanlinking D240

[Kristian Evensen]

Hi,

On Fri, Apr 28, 2017 at 8:39 PM, Thomas Endt  wrote:
> When will there be a precompiled 17.01 image for this device? With 17.01.2
> or with the next major release?
> I'm asking because there were some devices with snapshot support that I
> would have expected to have a 17.01.1 image available, but there is none.

While I am not sure about the policies about what can be added to a
stable-release through minor release, there is nothing technically
that prevents adding support for the D240 to 17.01. The patch works
as-is, I am building my own 17.01 for the device and has has no
problems with the device.

-Kristian

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

Re: [LEDE-DEV] [PATCH v3] ramips: Improve Sanlinking D240 config

[Kristian Evensen]

A gentle ping for this patch :)

-Kristian

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

[LEDE-DEV] [PATCH v3] ramips: Improve Sanlinking D240 config

[Kristian Evensen]

* The left most mini-PCIe slot (the one attached to SIM2) can be
power-cycled by setting GPIO 0 to high/low.

* The D240 only needs the MT76x2 module, so update makefile to reflect this.
Note that until the default mt7620 target is updated, then kmod-mt76 (and thus
kmod-mt7603) will be selected by default.

v2->v3:
* Indentation error.

v1->v2:
* Rename gpio and remove redundant comment (thanks Piotr Dymacz)

Signed-off-by: Kristian Evensen <kristian.even...@gmail.com>
---
 target/linux/ramips/dts/D240.dts| 11 +++
 target/linux/ramips/image/mt7620.mk |  2 +-
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/target/linux/ramips/dts/D240.dts b/target/linux/ramips/dts/D240.dts
index ef45d38..46d0141 100644
--- a/target/linux/ramips/dts/D240.dts
+++ b/target/linux/ramips/dts/D240.dts
@@ -46,6 +46,17 @@
bootargs = "console=ttyS0,115200";
};
 
+   gpio-export {
+   compatible = "gpio-export";
+   #size-cells = <0>;
+
+   power_mpcie2 {
+   gpio-export,name = "power_mpcie2";
+   gpio-export,output = ;
+   gpios = < 0 GPIO_ACTIVE_HIGH>;
+   };
+   };
+
gpio-leds {
compatible = "gpio-leds";
 
diff --git a/target/linux/ramips/image/mt7620.mk 
b/target/linux/ramips/image/mt7620.mk
index 4a76ab3..0410a9a 100644
--- a/target/linux/ramips/image/mt7620.mk
+++ b/target/linux/ramips/image/mt7620.mk
@@ -471,6 +471,6 @@ define Device/d240
   DTS := D240
   IMAGE_SIZE := $(ralink_default_fw_size_16M)
   DEVICE_TITLE := Sanlinking Technologies D240
-  DEVICE_PACKAGES := kmod-usb2 kmod-usb-ohci kmod-mt76 kmod-sdhci-mt7620
+  DEVICE_PACKAGES := kmod-usb2 kmod-usb-ohci kmod-mt76-core kmod-mt76x2 
kmod-sdhci-mt7620
 endef
 TARGET_DEVICES += d240
-- 
2.9.3


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

Re: [LEDE-DEV] [PATCH v2] ramips: Improve Sanlinking D240 config

[Kristian Evensen]

On Thu, Mar 2, 2017 at 1:37 PM, Kristian Evensen
<kristian.even...@gmail.com> wrote:
>
> +   gpio-export {
> +   compatible = "gpio-export";
> +   #size-cells = <0>;
> +
> +power_mpcie2 {
> +   gpio-export,name = "power_mpcie2";

[..]

Missed this indentation error, will send a v3.

-Kristian

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

[LEDE-DEV] [PATCH v2] ramips: Improve Sanlinking D240 config

[Kristian Evensen]

* The left most mini-PCIe slot (the one attached to SIM2) can be
power-cycled by setting GPIO 0 to high/low.

* The D240 only needs the MT76x2 module, so update makefile to reflect this.
Note that until the default mt7620 target is updated, then kmod-mt76 (and thus
kmod-mt7603) will be selected by default.

v1->v2:
* Rename gpio and remove redundant comment (thanks Piotr Dymacz)

Signed-off-by: Kristian Evensen <kristian.even...@gmail.com>
---
 target/linux/ramips/dts/D240.dts| 11 +++
 target/linux/ramips/image/mt7620.mk |  2 +-
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/target/linux/ramips/dts/D240.dts b/target/linux/ramips/dts/D240.dts
index ef45d38..dbf061c 100644
--- a/target/linux/ramips/dts/D240.dts
+++ b/target/linux/ramips/dts/D240.dts
@@ -46,6 +46,17 @@
bootargs = "console=ttyS0,115200";
};
 
+   gpio-export {
+   compatible = "gpio-export";
+   #size-cells = <0>;
+
+power_mpcie2 {
+   gpio-export,name = "power_mpcie2";
+   gpio-export,output = ;
+   gpios = < 0 GPIO_ACTIVE_HIGH>;
+   };
+   };
+
gpio-leds {
compatible = "gpio-leds";
 
diff --git a/target/linux/ramips/image/mt7620.mk 
b/target/linux/ramips/image/mt7620.mk
index 4a76ab3..0410a9a 100644
--- a/target/linux/ramips/image/mt7620.mk
+++ b/target/linux/ramips/image/mt7620.mk
@@ -471,6 +471,6 @@ define Device/d240
   DTS := D240
   IMAGE_SIZE := $(ralink_default_fw_size_16M)
   DEVICE_TITLE := Sanlinking Technologies D240
-  DEVICE_PACKAGES := kmod-usb2 kmod-usb-ohci kmod-mt76 kmod-sdhci-mt7620
+  DEVICE_PACKAGES := kmod-usb2 kmod-usb-ohci kmod-mt76-core kmod-mt76x2 
kmod-sdhci-mt7620
 endef
 TARGET_DEVICES += d240
-- 
2.9.3


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

Re: [LEDE-DEV] [PATCH] ramips: Improve Sanlinking D240 config

[Kristian Evensen]

Hi,

On Thu, Mar 2, 2017 at 12:39 PM, Piotr Dymacz  wrote:
> What about "power_mpcieX" (or something similar), where X is 1 or 2,
> depending on what is printed on the PCB (I wasn't able to find hi-res
> photo)?

Good idea and thanks for the pointer. There does not seem to be any
easy-to-find value or id printed on the PCB. However, in some material
I was sent from Sanlinking then the slot that can be power-cycled is
referred to as mini PCIe 2, so I will rename the slot to power_mpcie_2
and send a v2.

-Kristian

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

[LEDE-DEV] [PATCH] ramips: Improve Sanlinking D240 config

[Kristian Evensen]

* The left most mini-PCIe (USB) slot (the one attached to SIM2) can be
power-cycled by setting GPIO 0 to high/low. I have no strong opinion on the
name, but since the slot can be used for other things than modems I went for
usb2.

* The D240 only needs the MT76x2 module, so update makefile to reflect this.
Note that until the default mt7620 target is updated, then kmod-mt76 (and thus
kmod-mt7603) will be selected by default.

Signed-off-by: Kristian Evensen <kristian.even...@gmail.com>
---
 target/linux/ramips/dts/D240.dts| 14 ++
 target/linux/ramips/image/mt7620.mk |  2 +-
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/target/linux/ramips/dts/D240.dts b/target/linux/ramips/dts/D240.dts
index ef45d38..4abf7f5 100644
--- a/target/linux/ramips/dts/D240.dts
+++ b/target/linux/ramips/dts/D240.dts
@@ -46,6 +46,20 @@
bootargs = "console=ttyS0,115200";
};
 
+   gpio-export {
+   compatible = "gpio-export";
+   #size-cells = <0>;
+   /*
+* The modem ("usb port") connected with the SIM2 slot can be 
power
+* controlled by setting gpio 0 to high/low.
+*/
+   usb2 {
+   gpio-export,name = "usb2";
+   gpio-export,output = ;
+   gpios = < 0 GPIO_ACTIVE_HIGH>;
+   };
+   };
+
gpio-leds {
compatible = "gpio-leds";
 
diff --git a/target/linux/ramips/image/mt7620.mk 
b/target/linux/ramips/image/mt7620.mk
index 4a76ab3..0410a9a 100644
--- a/target/linux/ramips/image/mt7620.mk
+++ b/target/linux/ramips/image/mt7620.mk
@@ -471,6 +471,6 @@ define Device/d240
   DTS := D240
   IMAGE_SIZE := $(ralink_default_fw_size_16M)
   DEVICE_TITLE := Sanlinking Technologies D240
-  DEVICE_PACKAGES := kmod-usb2 kmod-usb-ohci kmod-mt76 kmod-sdhci-mt7620
+  DEVICE_PACKAGES := kmod-usb2 kmod-usb-ohci kmod-mt76-core kmod-mt76x2 
kmod-sdhci-mt7620
 endef
 TARGET_DEVICES += d240
-- 
2.9.3


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

[LEDE-DEV] [PATCH v4] ramips: Add support for Sanlinking D240

[Kristian Evensen]

The Sanlinking Technologies D240
(http://www.sanlinking.com/en/29-dual-4g-wifi-router.html) is basically the same
device as the ZBT WE826, so adding support for it in LEDE is straight forward.
The differences is that the D240 has two mini-PCIe slots (instead of one), blue
LEDs and supports PoE.

Specification:
* CPU: MT7620A
* 1x 10/100Mbps POE (802.3af/802.3at) Ethernet, 4x 10/100Mbps.
* 16 MB Flash.
* 128 MB RAM.
* 1x USB 2.0 port.
* 2x mini-PCIe slots.
* 2x SIM slots.
* 1x 2.4Ghz WIFI.
* 1x button.

Wifi, USB, switch and both mini-PCIe slots are working. I have not been able to
test the SD card reader.

The device comes pre-installed with an older version of OpenWRT, including Luci.
In order to install LEDE, you need to follow the existing procedure for updating
OpenWRT/LEDE using Luci. I.e., you need to access the UI and update the firmware
using the sysupgrade-image. Remember to select that you do not want to keep
existing settings. The default router address is 192.168.10.1 and
username/password admin/root (at least on my devices).

If you brick the device, the procedure for recovery is the same as for the
WE826. Please see the wiki page for that device for instructions.

v3->v4:
* Fixed formatting of dts file (thanks Piotr Dymacz).

v2->v3:
* Rename Sanlinking-D240 to D240 in order to follow convention that board name
should not contain manufacturer name (thanks Piotr Dymacz).
* Add BSD license to DTS file (thanks Rafał Miłecki).
* Add details on how to install LEDE on the router (thanks Mathias Kresin).

v1->v2:
* Misc. code cleanup (thanks Mathias Kresin)

Signed-off-by: Kristian Evensen <kristian.even...@gmail.com>

blabla
---
 target/linux/ramips/base-files/etc/board.d/01_leds |   4 +
 .../linux/ramips/base-files/etc/board.d/02_network |   1 +
 target/linux/ramips/base-files/etc/diag.sh |   1 +
 target/linux/ramips/base-files/lib/ramips.sh   |   3 +
 .../ramips/base-files/lib/upgrade/platform.sh  |   1 +
 target/linux/ramips/dts/D240.dts   | 157 +
 target/linux/ramips/image/mt7620.mk|   8 ++
 7 files changed, 175 insertions(+)
 create mode 100644 target/linux/ramips/dts/D240.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 545d6a4..4e6eeb2 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -109,6 +109,10 @@ d105)
ucidef_set_led_default "power" "POWER" "$board:red:power" "1"
set_usb_led "$board:green:usb"
;;
+d240)
+   set_wifi_led "$board:blue:wifi"
+   set_usb_led "$board:blue:usb"
+   ;;
 db-wrt01)
ucidef_set_led_default "power" "power" "$board:orange:power" "1"
;;
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 c001dfe..3ef04e6 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -73,6 +73,7 @@ ramips_setup_interfaces()
3g-6200n|\
ac1200pro|\
ai-br100|\
+   d240|\
db-wrt01|\
dir-300-b7|\
dir-320-b1|\
diff --git a/target/linux/ramips/base-files/etc/diag.sh 
b/target/linux/ramips/base-files/etc/diag.sh
index 5fb2213..744ff3c 100644
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -108,6 +108,7 @@ get_status_led() {
w502u)
status_led="$board:blue:wps"
;;
+   d240|\
dap-1350|\
na930|\
pbr-m1|\
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index d9918cc..3072531 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -112,6 +112,9 @@ ramips_board_detect() {
*"D105")
name="d105"
;;
+   *"D240")
+   name="d240"
+   ;;
*"DAP-1350")
name="dap-1350"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index d83e5c1..acdfdaf 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -35,6 +35,7 @@ platform_check_image() {
cf-wr800n|\
cs-qr10|\
d105|\
+   d240|\
dap-1350|\
db-wrt01|\
dcs-930|\
diff --git a/target/linux/ramips/dts/D240.dts b/target/linux/ramips/dts/D240.dts
new file mode 100644
index 000..2f11ce9
--- /dev/null
+++ b/target/linux/ramips/dts/D240.dts
@@ -0,0 +1,157 @@
+

[LEDE-DEV] [PATCH v3] ramips: Add support for Sanlinking D240

[Kristian Evensen]

The Sanlinking Technologies D240
(http://www.sanlinking.com/en/29-dual-4g-wifi-router.html) is basically the same
device as the ZBT WE826, so adding support for it in LEDE is straight forward.
The differences is that the D240 has two mini-PCIe slots (instead of one), blue
LEDs and supports PoE.

Specification:
* CPU: MT7620A
* 1x 10/100Mbps POE (802.3af/802.3at) Ethernet, 4x 10/100Mbps.
* 16 MB Flash.
* 128 MB RAM.
* 1x USB 2.0 port.
* 2x mini-PCIe slots.
* 2x SIM slots.
* 1x 2.4Ghz WIFI.
* 1x button.

Wifi, USB, switch and both mini-PCIe slots are working. I have not been able to
test the SD card reader.

The device comes pre-installed with an older version of OpenWRT, including Luci.
In order to install LEDE, you need to follow the existing procedure for updating
OpenWRT/LEDE using Luci. I.e., you need to access the UI and update the firmware
using the sysupgrade-image. Remember to select that you do not want to keep
existing settings. The default router address is 192.168.10.1 and
username/password admin/root (at least on my devices).

If you brick the device, the procedure for recovery is the same as for the
WE826. Please see the wiki page for that device for instructions.

v2->v3:
* Rename Sanlinking-D240 to D240 in order to follow convention that board name
should not contain manufacturer name (thanks Piotr Dymacz).
* Add BSD license to DTS file (thanks Rafał Miłecki).
* Add details on how to install LEDE on the router (thanks Mathias Kresin).

v1->v2:
* Misc. code cleanup (thanks Mathias Kresin)

Signed-off-by: Kristian Evensen <kristian.even...@gmail.com>
---
 target/linux/ramips/base-files/etc/board.d/01_leds |   4 +
 .../linux/ramips/base-files/etc/board.d/02_network |   1 +
 target/linux/ramips/base-files/etc/diag.sh |   1 +
 target/linux/ramips/base-files/lib/ramips.sh   |   3 +
 .../ramips/base-files/lib/upgrade/platform.sh  |   1 +
 target/linux/ramips/dts/D240.dts   | 153 +
 target/linux/ramips/image/mt7620.mk|   8 ++
 7 files changed, 171 insertions(+)
 create mode 100644 target/linux/ramips/dts/D240.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 545d6a4..4e6eeb2 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -109,6 +109,10 @@ d105)
ucidef_set_led_default "power" "POWER" "$board:red:power" "1"
set_usb_led "$board:green:usb"
;;
+d240)
+   set_wifi_led "$board:blue:wifi"
+   set_usb_led "$board:blue:usb"
+   ;;
 db-wrt01)
ucidef_set_led_default "power" "power" "$board:orange:power" "1"
;;
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 c001dfe..3ef04e6 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -73,6 +73,7 @@ ramips_setup_interfaces()
3g-6200n|\
ac1200pro|\
ai-br100|\
+   d240|\
db-wrt01|\
dir-300-b7|\
dir-320-b1|\
diff --git a/target/linux/ramips/base-files/etc/diag.sh 
b/target/linux/ramips/base-files/etc/diag.sh
index 5fb2213..744ff3c 100644
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -108,6 +108,7 @@ get_status_led() {
w502u)
status_led="$board:blue:wps"
;;
+   d240|\
dap-1350|\
na930|\
pbr-m1|\
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index d9918cc..3072531 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -112,6 +112,9 @@ ramips_board_detect() {
*"D105")
name="d105"
;;
+   *"D240")
+   name="d240"
+   ;;
*"DAP-1350")
name="dap-1350"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index d83e5c1..acdfdaf 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -35,6 +35,7 @@ platform_check_image() {
cf-wr800n|\
cs-qr10|\
d105|\
+   d240|\
dap-1350|\
db-wrt01|\
dcs-930|\
diff --git a/target/linux/ramips/dts/D240.dts b/target/linux/ramips/dts/D240.dts
new file mode 100644
index 000..051204a
--- /dev/null
+++ b/target/linux/ramips/dts/D240.dts
@@ -0,0 +1,153 @@
+/*
+ *  BSD LICENSE
+ *
+ *  Copyright(c) 2017 Kristian Evensen <kristian.even...@gma

Re: [LEDE-DEV] [PATCH v2] ramips: Add support for Sanlinking D240

[Kristian Evensen]

On Fri, Feb 3, 2017 at 12:52 PM, Piotr Dymacz  wrote:
> As this is a general problem and I'm sure it's going to grow in time,
> maybe we should start thinking about different approach for naming
> boards in system, dts files and image filenames? Including there also
> the manufacturer name would be one of possible options, but... I'm
> pretty sure this problem is also kernel related (upstream dts
> filenames convention).

I will submit a v3 with the renaming + licensing later this evening.
Everything is ready, but need to test changes on an actual device.

-Kristian

___
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

[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?

-Kristian

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

[LEDE-DEV] [PATCH v2] ramips: Add support for Sanlinking D240

[Kristian Evensen]

The Sanlinking Technologies D240
(http://www.sanlinking.com/en/29-dual-4g-wifi-router.html) is basically the same
device as the ZBT WE826, so adding support for it in LEDE is straight forward.
The differences is that the D240 has two mini-PCIe slots (instead of one), blue
LEDs and supports PoE.

Wifi, USB, switch and both mini-PCIe slots are working. I have not been able to
test the SD card reader on the device.

v1->v2:

* Misc. code cleanup (thanks Mathias Kresin)

Signed-off-by: Kristian Evensen <kristian.even...@gmail.com>

Cleanup
---
 target/linux/ramips/base-files/etc/board.d/01_leds |   4 +
 .../linux/ramips/base-files/etc/board.d/02_network |   1 +
 target/linux/ramips/base-files/etc/diag.sh |   1 +
 target/linux/ramips/base-files/lib/ramips.sh   |   3 +
 .../ramips/base-files/lib/upgrade/platform.sh  |   1 +
 target/linux/ramips/dts/SANLINKING-D240.dts| 120 +
 target/linux/ramips/image/mt7620.mk|   8 ++
 7 files changed, 138 insertions(+)
 create mode 100644 target/linux/ramips/dts/SANLINKING-D240.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 545d6a4..409854f 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -300,6 +300,10 @@ rt-n14u)
set_wifi_led "$board:blue:air"
set_usb_led "$board:blue:usb"
;;
+sanlinking-d240)
+   set_wifi_led "$board:blue:wifi"
+   set_usb_led "$board:blue:usb"
+   ;;
 tew-714tru)
set_usb_led "$board:red:usb"
set_wifi_led "$board:green:wifi"
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index c001dfe..bf2edf0 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -92,6 +92,7 @@ ramips_setup_interfaces()
pbr-m1|\
psg1208|\
psg1218|\
+   sanlinking-d240|\
sap-g3200u3|\
sk-wb8|\
vr500|\
diff --git a/target/linux/ramips/base-files/etc/diag.sh 
b/target/linux/ramips/base-files/etc/diag.sh
index 5fb2213..b92d871 100644
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -115,6 +115,7 @@ get_status_led() {
rt-n14u|\
rt-n15|\
rt-n56u|\
+   sanlinking-d240|\
wl-330n|\
wl-330n3g|\
wli-tx4-ag300n|\
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index d9918cc..dc86a82 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -442,6 +442,9 @@ ramips_board_detect() {
*"SamKnows Whitebox 8")
name="sk-wb8"
;;
+   *"SANLINKING-D240")
+   name="sanlinking-d240"
+   ;;
*"SAP-G3200U3")
name="sap-g3200u3"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index d83e5c1..afc6014 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -123,6 +123,7 @@ platform_check_image() {
rt-n15|\
rt-n56u|\
rut5xx|\
+   sanlinking-d240|\
sap-g3200u3|\
sk-wb8|\
sl-r7205|\
diff --git a/target/linux/ramips/dts/SANLINKING-D240.dts 
b/target/linux/ramips/dts/SANLINKING-D240.dts
new file mode 100644
index 000..888f5aa
--- /dev/null
+++ b/target/linux/ramips/dts/SANLINKING-D240.dts
@@ -0,0 +1,120 @@
+/dts-v1/;
+
+#include "mt7620a.dtsi"
+
+#include 
+#include 
+
+/ {
+   compatible = "sanlinking,sanlinking-d240", "ralink,mt7620a-soc";
+   model = "SANLINKING-D240";
+
+   chosen {
+   bootargs = "console=ttyS0,115200";
+   };
+
+   gpio-leds {
+   compatible = "gpio-leds";
+   power {
+   label = "sanlinking-d240:blue:power";
+   gpios = < 14 GPIO_ACTIVE_HIGH>;
+   };
+   usb {
+   label = "sanlinking-d240:blue:usb";
+   gpios = < 15 GPIO_ACTIVE_HIGH>;
+   };
+   air {
+   label = "sanlinking-d240:blue:wifi";
+   gpios = < 0 GPIO_ACTIVE_LOW>;
+   };
+   };
+
+   gpio-keys-polled {
+   compatible = "gpio-keys-polled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   poll-interval = &l

Re: [LEDE-DEV] [PATCH] ramips: Add support for Sanlinking D240

[Kristian Evensen]

On Thu, Feb 2, 2017 at 8:13 PM, Mathias Kresin  wrote:
> Hey Kristian,
>
> thanks a lot for the patch. Find my comments inline.

Thanks a lot! Will submit a v2 soon.

-Kristian

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

[LEDE-DEV] [PATCH] ramips: Add support for Sanlinking D240

[Kristian Evensen]

The Sanlinking Technologies D240
(http://www.sanlinking.com/en/29-dual-4g-wifi-router.html) is basically the same
device as the ZBT WE826, so adding support for it in LEDE is straight forward.
The differences is that the D240 has two mini-PCIe slots (instead of one), blue
LEDs and supports PoE.

Wifi, USB, switch and both mini-PCIe slots are working. I have not been able to
test the SD card reader on the device.

Signed-off-by: Kristian Evensen <kristian.even...@gmail.com>
---
 target/linux/ramips/base-files/etc/board.d/01_leds |   5 +
 .../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/SANLINKING-D240.dts| 124 +
 target/linux/ramips/image/mt7620.mk|   8 ++
 7 files changed, 145 insertions(+)
 create mode 100644 target/linux/ramips/dts/SANLINKING-D240.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 545d6a4..1238a50 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -300,6 +300,11 @@ rt-n14u)
set_wifi_led "$board:blue:air"
set_usb_led "$board:blue:usb"
;;
+sanlinking-d240)
+   ucidef_set_led_default "power" "power" "$board:blue:power" "1"
+   set_wifi_led "$board:blue:wifi"
+   set_usb_led "$board:blue:usb"
+   ;;
 tew-714tru)
set_usb_led "$board:red:usb"
set_wifi_led "$board:green:wifi"
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index c001dfe..bf2edf0 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -92,6 +92,7 @@ ramips_setup_interfaces()
pbr-m1|\
psg1208|\
psg1218|\
+   sanlinking-d240|\
sap-g3200u3|\
sk-wb8|\
vr500|\
diff --git a/target/linux/ramips/base-files/etc/diag.sh 
b/target/linux/ramips/base-files/etc/diag.sh
index 5fb2213..83a9353 100644
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -247,6 +247,9 @@ get_status_led() {
zbt-cpe102)
status_led="$board:green:4g-0"
;;
+   sanlinking-d240)
+   status_led="$board:blue:wifi"
+   ;;
esac
 }
 
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index d9918cc..dc86a82 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -442,6 +442,9 @@ ramips_board_detect() {
*"SamKnows Whitebox 8")
name="sk-wb8"
;;
+   *"SANLINKING-D240")
+   name="sanlinking-d240"
+   ;;
*"SAP-G3200U3")
name="sap-g3200u3"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index d83e5c1..afc6014 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -123,6 +123,7 @@ platform_check_image() {
rt-n15|\
rt-n56u|\
rut5xx|\
+   sanlinking-d240|\
sap-g3200u3|\
sk-wb8|\
sl-r7205|\
diff --git a/target/linux/ramips/dts/SANLINKING-D240.dts 
b/target/linux/ramips/dts/SANLINKING-D240.dts
new file mode 100644
index 000..522b36d
--- /dev/null
+++ b/target/linux/ramips/dts/SANLINKING-D240.dts
@@ -0,0 +1,124 @@
+/dts-v1/;
+
+#include "mt7620a.dtsi"
+
+#include 
+
+/ {
+   compatible = "sanlinking,sanlinking-d240", "ralink,mt7620a-soc";
+   model = "SANLINKING-D240";
+
+   chosen {
+   bootargs = "console=ttyS0,115200";
+   };
+
+   gpio-leds {
+   compatible = "gpio-leds";
+   power {
+   label = "sanlinking-d240:blue:power";
+   gpios = < 14 0>;
+   };
+   usb {
+   label = "sanlinking-d240:blue:usb";
+   gpios = < 15 0>;
+   };
+   air {
+   label = "sanlinking-d240:blue:wifi";
+   gpios = < 0 1>;
+   };
+   };
+
+   gpio-keys-polled {
+   compatible = "gpio-keys-polled";
+   #address-cells = <1>;
+   

[LEDE-DEV] [PATCH] netifd: Set source address for static address routes

[Kristian Evensen]

When using UCI to configure static addresses, netifd does not set the source
address of the gateway route. In order to be consistent, also set the source
address for subnet routes (this applies to all protocols).

Signed-off-by: Kristian Evensen <kristian.even...@gmail.com>
---
 interface-ip.c |  4 
 proto.c| 32 ++--
 2 files changed, 26 insertions(+), 10 deletions(-)

diff --git a/interface-ip.c b/interface-ip.c
index 24ea054..7fce833 100644
--- a/interface-ip.c
+++ b/interface-ip.c
@@ -457,6 +457,7 @@ prefix_cmp(const void *k1, const void *k2, void *ptr)
 static void
 interface_handle_subnet_route(struct interface *iface, struct device_addr 
*addr, bool add)
 {
+   bool v6 = ((addr->flags & DEVADDR_FAMILY) == DEVADDR_INET6);
struct device *dev = iface->l3_dev.dev;
struct device_route *r = >subnet;
 
@@ -484,6 +485,9 @@ interface_handle_subnet_route(struct interface *iface, 
struct device_addr *addr,
r->flags &= ~DEVADDR_KERNEL;
interface_set_route_info(iface, r);
 
+   r->sourcemask = v6 ? 128 : 32;
+   r->source = addr->addr;
+
system_add_route(dev, r);
 }
 
diff --git a/proto.c b/proto.c
index 23304f3..03973e5 100644
--- a/proto.c
+++ b/proto.c
@@ -113,7 +113,7 @@ alloc_device_addr(bool v6, bool ext)
 
 static bool
 parse_addr(struct interface *iface, const char *str, bool v6, int mask,
-  bool ext, uint32_t broadcast)
+  bool ext, uint32_t broadcast, struct device_addr **addr_to_set)
 {
struct device_addr *addr;
int af = v6 ? AF_INET6 : AF_INET;
@@ -137,6 +137,10 @@ parse_addr(struct interface *iface, const char *str, bool 
v6, int mask,
addr->broadcast = broadcast;
 
vlist_add(>proto_ip.addr, >node, >flags);
+
+   if (addr_to_set)
+   *addr_to_set = addr;
+
return true;
 
 error:
@@ -148,7 +152,8 @@ error:
 
 static int
 parse_static_address_option(struct interface *iface, struct blob_attr *attr,
-   bool v6, int netmask, bool ext, uint32_t broadcast)
+   bool v6, int netmask, bool ext, uint32_t broadcast,
+   struct device_addr **addr_to_set)
 {
struct blob_attr *cur;
int n_addr = 0;
@@ -160,7 +165,7 @@ parse_static_address_option(struct interface *iface, struct 
blob_attr *attr,
 
n_addr++;
if (!parse_addr(iface, blobmsg_data(cur), v6, netmask, ext,
-   broadcast))
+   broadcast, addr_to_set))
return -1;
}
 
@@ -268,7 +273,8 @@ parse_address_list(struct interface *iface, struct 
blob_attr *attr, bool v6,
 }
 
 static bool
-parse_gateway_option(struct interface *iface, struct blob_attr *attr, bool v6)
+parse_gateway_option(struct interface *iface, struct blob_attr *attr, bool v6,
+   struct device_addr *addr_to_set)
 {
struct device_route *route;
const char *str = blobmsg_data(attr);
@@ -294,6 +300,11 @@ parse_gateway_option(struct interface *iface, struct 
blob_attr *attr, bool v6)
route->flags |= DEVROUTE_SRCTABLE;
}
 
+   if (addr_to_set) {
+   route->sourcemask = v6 ? 128 : 32;
+   route->source = addr_to_set->addr;
+   }
+
vlist_add(>proto_ip.route, >node, route);
 
return true;
@@ -402,6 +413,7 @@ proto_apply_static_ip_settings(struct interface *iface, 
struct blob_attr *attr)
unsigned int netmask = 32;
int n_v4 = 0, n_v6 = 0;
struct in_addr bcast = {};
+   struct device_addr *addr_to_set;
 
blobmsg_parse(proto_ip_attributes, __OPT_MAX, tb, blob_data(attr), 
blob_len(attr));
 
@@ -422,11 +434,11 @@ proto_apply_static_ip_settings(struct interface *iface, 
struct blob_attr *attr)
 
if ((cur = tb[OPT_IPADDR]))
n_v4 = parse_static_address_option(iface, cur, false,
-   netmask, false, bcast.s_addr);
+   netmask, false, bcast.s_addr, _to_set);
 
if ((cur = tb[OPT_IP6ADDR]))
n_v6 = parse_static_address_option(iface, cur, true,
-   128, false, 0);
+   128, false, 0, _to_set);
 
if ((cur = tb[OPT_IP6PREFIX]))
if (parse_prefix_list(iface, cur) < 0)
@@ -436,12 +448,12 @@ proto_apply_static_ip_settings(struct interface *iface, 
struct blob_attr *attr)
goto out;
 
if ((cur = tb[OPT_GATEWAY])) {
-   if (n_v4 && !parse_gateway_option(iface, cur, false))
+   if (n_v4 && !parse_gateway_option(iface, cur, false, 
addr_to_set))
goto out;
}
 
if ((cur = tb[OPT_IP6GW])) {
-   if (n_v6 && !parse_gateway_option(iface,