Re: [LEDE-DEV] can't install luci

2016-10-16 Thread Torbjorn Jansson

On 2016-10-16 14:35, Matthias Schiffer wrote:

On 10/16/2016 09:18 AM, Torbjorn Jansson wrote:

On 2016-10-15 18:55, Matthias Schiffer wrote:

On 10/15/2016 06:30 PM, Torbjorn Jansson wrote:

On 2016-10-15 17:39, Matthias Schiffer wrote:

On 10/15/2016 05:19 PM, Matthias Schiffer wrote:

On 10/15/2016 05:04 PM, Torbjorn Jansson wrote:

Hello

i decided to give lede a try on one of my rasberry pi computers and i
almost immediately ran into problems.

opkg update works fine, but when i do:
opkg install luci-ssl

i get:

root@lede:~# opkg install luci-ssl
Installing luci-ssl (git-16.288.36935-1e1a706-1) to root...
Downloading
http://downloads.lede-project.org/snapshots/packages/arm_arm1176jzf-s_vfp/luci/luci-ssl_git-16.288.36935-1e1a706-1_all.ipk.



Collected errors:
 * satisfy_dependencies_for: Cannot satisfy the following
dependencies for
luci-ssl:
 *  luci-mod-admin-full *
 * opkg_install_cmd: Cannot install package luci-ssl.

i checked the url and luci-mod-admin-full is indeed missing.
can someone explain whats going on and how to fix it?


Hi,
a recent patch caused the libnl-tiny build to fail [1], which in turn
broke
a lot of other packages that directly or indirectly depend on it.

We're working on fixing this ASAP.

Regards,
Matthias


I've just had a closer look at the issue, it was caused by a dependency
issue of our 2-phase build bot setup:

Phase 2 tried to build the packages based on an outdated SDK version, as
Phase 1 has not finished building the newest version the SDK yet. This
broke some packages, as patches depending on SDK changes were added
together with the SDK changes themselves.

The issue will fix itself as soon as the build bots have finished the next
round of builds. Sorry for the inconvenience!



and how often do the build bots rebuild things?
once a day?



Phase 1 rebuilds are triggered for each master commit, but there are many
targets and builds take some time. You can find the current build status on
http://phase1.builds.lede-project.org/grid . Phase 2 builds can be seen on
http://phase2.builds.lede-project.org/grid .

The issue will disappear as soon as phase 1 has finished for your target
(and thus produced a new SDK), and the next phase 2 build after that has
finished, too. This should be done in less than a day.



phase 1 & 2 is done for my target in question (an rpi) but i suspect it was
still done in wrong order or something because there is still lots of
missing packages including those making luci-ssl work.


Yes, that's the case. The next arm_arm1176jzf-s_vfp build should finally
fix everything.



it did fix the issue and i got it working.

i did notice one odd thing while trying to mount an extra sd card.
when i click save and apply in luci in the block mount page all mounts 
get screwed up and i have to reboot.
after reboot it works as intended, it is just the apply step that goes 
wrong for some reason, i suspect it removed mounts it is not supposed to 
mess with like /proc and /sys (ran mount manually after and it 
complained about missing mtab)





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


Re: [LEDE-DEV] [RFC 0/1] x86: Add support for the PC Engines APU2 Board

2016-10-16 Thread Alberto Bursi


On 10/16/2016 05:30 PM, STR . wrote:
>> I'd rather like to see the bcp38 stuff a default, but although we made the 
>> code work right for one layer of nat, too many people have more than that. :(
> Double NAT?
>

Common for fibre providers, and 3G/4G, where the "modem" isn't a modem 
but a router and the only thing you can do is placing your lede device 
in a DMZ, but you cannot remove the nat without hacking (for 3G/4G) or 
at all for fibre providers.
Or without disabling any routing on the lede device and let the other 
device take over the router role.

-Alberto

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


Re: [LEDE-DEV] [RFC 0/1] x86: Add support for the PC Engines APU2 Board

2016-10-16 Thread Ben Greear



On 10/16/2016 08:30 AM, STR . wrote:

BQL + fq_codel kills bufferbloat at line rate (10,100,1000mbit) on ethernet 
cards. It also works if you have hardware flow control on the the ethernet.
It can't do anything on downloads.
If your connection is not at line rate  or the download is overbuffered (looks 
like 20Mbit here), you need a soft shaper like the ones in sqm-scripts (htb + 
fq_codel or cake) set 5-15% below the observed rate to win.

So I was misreading it. Thanks for clearing that up, this was tested on an 8M 
down ADSL, I'll check out the sqm-scripts.


Do you know of someone making a bigger better case for it? I'd like one with 6 
antenna slots for just that reason - and better heat management.

This has been a gripe for everyone owning an APU2 it seems. 6 holes for 
antenna? I know none.


You can find $30 hand punches on Amazon/Ebay and their largest punch size is 
typically perfect for
SMA connectors.  The APU2 case is easily punched since it is aluminum.

https://www.amazon.com/Neiko-02612A-Multi-Purpose-Power-Punch/dp/B0002T87CW/ref=sr_1_3?ie=UTF8=1476634765=8-3=metal+punch

Also, I've run these systems at full load (500Mbps+) for 24 hours and though 
the case gets warm,
system has remained stable.  A warm case actually means it is transferring 
heat...

Thanks,
Ben



--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

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


Re: [LEDE-DEV] [RFC 0/1] x86: Add support for the PC Engines APU2 Board

2016-10-16 Thread STR .
> BQL + fq_codel kills bufferbloat at line rate (10,100,1000mbit) on ethernet 
> cards. It also works if you have hardware flow control on the the ethernet.
> It can't do anything on downloads.
> If your connection is not at line rate  or the download is overbuffered 
> (looks like 20Mbit here), you need a soft shaper like the ones in sqm-scripts 
> (htb + fq_codel or cake) set 5-15% below the observed rate to win.
So I was misreading it. Thanks for clearing that up, this was tested on an 8M 
down ADSL, I'll check out the sqm-scripts.

> Do you know of someone making a bigger better case for it? I'd like one with 
> 6 antenna slots for just that reason - and better heat management.
This has been a gripe for everyone owning an APU2 it seems. 6 holes for 
antenna? I know none.
The Calexium case can definitely do better thermal management but useless for 
you since you can't add all the radios+antenna - 
http://store.calexium.com/en/boitiers/324-pc-engines-alix-2d3-2d13-or-openvox-ipc100-110-120-case-with-hdd-wifi-black.html
Check the last post on this page for ideas on thermal management - 
http://pcengines.info/forums/?page=post=795B2ACC-F4B0-4181-9B4A-54EC757D4001=DF5ACB70-99C4-4C61-AFA6-4C0E0DB05B2A=2

> I'd rather like to see the bcp38 stuff a default, but although we made the 
> code work right for one layer of nat, too many people have more than that. :(
Double NAT?

> ... after we finish up the airtime fairness code and rip out some more wifi 
> latencies.
Eagerly looking forward to this!
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev


[LEDE-DEV] LEDE Reboot r1588+145 vs LEDE Reboot r1588+257 on TP-Link Archer C7 v2 / constant bootloop on 257

2016-10-16 Thread Břetislav Kubesa

Hi,

i tried to upgrade my TP-Link Archer C7 v2 from 145 to 257 and router 
seems to be in constant reboot cycle. When I reset the config via 
recovery, the router boots fine, currently I'm back on v145.


Unfortunately I don't have serial (and AP is under warranty), so I guess 
I can't investigate it (the network ping holds only like 5 secs, not 
enough time for log..). I tried it flashing twice - same results.


Using the same sources (but different config), others sets like 
tl-mr3020-v1,-tl-wa850re-v1,tl-wr841-v11 etc. are absolutely fine.


I know it's very vague description but any idea what could be causing 
this between 145 and 257 versions ?


My TP-Link Archer C7 v2 config if it helps : http://pastebin.com/zBeRpczT

PS : Yes, I know I can start from scratch and see, when it broke 
unfortunately I can't break internet connectivity except of night...
PS2 : Reason I would like to update are random lost of Wifi connectivity 
(I didn't investigate more yet, LEDs are blinking but WiFi seems to be 
gone), versions prior to 145 were also fine.


Thank you.

Bretislav


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


Re: [LEDE-DEV] [PATCH]fstools: added xfs and f2fs to block-mount

2016-10-16 Thread Alberto Bursi
Damn, while this patch adds only partial xfs support to fstools (it 
allows to mount xfs by block mount).

Most of fstools have code to use f2fs too already so the fact that block 
mount couldn't mount f2fs is 100% a bug and this patch fixes that.

I'm going to add xfs support to other fstools components in a following 
patch.

-Alberto

On 10/15/2016 07:25 PM, Alberto Bursi wrote:
> added the code to recognize the filesystem checkers for xfs and f2fs
> added xfs and f2fs to the filesystem whitelist of block.
>
> Signed-off-by: Alberto Bursi 
> -
>
> --- fstools/block.c   2016-10-15 19:15:31.916714011 +0200
> +++ fstools/block.c   2016-10-15 19:22:44.164702448 +0200
> @@ -702,6 +702,8 @@ static void check_filesystem(struct blki
>   {
>   pid_t pid;
>   struct stat statbuf;
> + const char *xfsck = "/sbin/xfs_repair";
> + const char *f2fsck = "/usr/sbin/fsck.f2fs";
>   const char *e2fsck = "/usr/sbin/e2fsck";
>   const char *dosfsck = "/usr/sbin/dosfsck";
>   const char *ckfs;
> @@ -712,6 +714,10 @@ static void check_filesystem(struct blki
>
>   if (!strncmp(pr->id->name, "vfat", 4)) {
>   ckfs = dosfsck;
> + } else if (!strncmp(pr->id->name, "f2fs", 4)) {
> + ckfs = f2fsck;
> + } else if (!strncmp(pr->id->name, "xfs", 3)) {
> + ckfs = xfsck;
>   } else if (!strncmp(pr->id->name, "ext", 3)) {
>   ckfs = e2fsck;
>   } else {
> @@ -1170,8 +1176,10 @@ static int mount_extroot(char *cfg)
>   }
>   if (pr) {
>   if (strncmp(pr->id->name, "ext", 3) &&
> - strncmp(pr->id->name, "ubifs", 5)) {
> - ULOG_ERR("extroot: unsupported filesystem %s, try 
> ext4\n",
> pr->id->name);
> +strncmp(pr->id->name, "xfs", 3) &&
> +strncmp(pr->id->name, "f2fs", 4) &&
> +strncmp(pr->id->name, "ubifs", 5)) {
> +ULOG_ERR("extroot: unsupported filesystem %s, try ext4,
> xfs, f2fs, ubifs\n", pr->id->name);
>   return -1;
>   }
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
>

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


Re: [LEDE-DEV] [RFC 1/1] x86: Add support for the PC Engines APU2 Board

2016-10-16 Thread Chris Blake
Hey Stijn,

Thanks for the feedback, will get this fixed up for the next RFC as well.

Please keep the feedback coming. :)

- Chris B

On Sat, Oct 15, 2016 at 9:41 AM, Stijn Tintel  wrote:
> On 14-10-16 20:19, Chris Blake wrote:
>> The following patch adds support for the PC Engines APU2 Embedded Board
>> as a profile under the X86_64 target. More information on this board can
>> be found at www.pcengines.ch/apu2c4.htm
>>
>> Note that this patch is a part of an RFC, and should not be merged yet.
>>
>> Signed-off-by: Chris Blake 
>> ---
>>  target/linux/x86/64/config-default |  12 +
>>  target/linux/x86/64/profiles/001-PCEngines.mk  |  20 +
>>  target/linux/x86/base-files/etc/board.d/01_leds|  22 ++
>>  target/linux/x86/base-files/etc/board.d/02_network |  26 ++
>>  target/linux/x86/base-files/etc/diag.sh|  37 ++
>>  target/linux/x86/base-files/lib/x86.sh |  13 +
>>  target/linux/x86/config-4.4|   1 +
>>  .../linux/x86/files/drivers/gpio/gpio-nct5104d.c   | 432 
>> +
>>  target/linux/x86/files/drivers/leds/leds-apu2.c| 371 ++
>>  target/linux/x86/modules.mk|  36 ++
>>  .../x86/patches-4.4/800-add-apu2-led-driver.patch  |  29 ++
>>  .../801-sp5100_tco-add-apu2-support.patch  |  91 +
>>  .../patches-4.4/802-add-nct5104d-gpio-driver.patch |  27 ++
>>  13 files changed, 1117 insertions(+)
>>  create mode 100644 target/linux/x86/64/profiles/001-PCEngines.mk
>>  create mode 100755 target/linux/x86/base-files/etc/board.d/01_leds
>>  create mode 100755 target/linux/x86/base-files/etc/board.d/02_network
>>  create mode 100755 target/linux/x86/base-files/etc/diag.sh
>>  create mode 100755 target/linux/x86/base-files/lib/x86.sh
>>  create mode 100644 target/linux/x86/files/drivers/gpio/gpio-nct5104d.c
>>  create mode 100644 target/linux/x86/files/drivers/leds/leds-apu2.c
>>  create mode 100644 target/linux/x86/modules.mk
>>  create mode 100644 
>> target/linux/x86/patches-4.4/800-add-apu2-led-driver.patch
>>  create mode 100644 
>> target/linux/x86/patches-4.4/801-sp5100_tco-add-apu2-support.patch
>>  create mode 100644 
>> target/linux/x86/patches-4.4/802-add-nct5104d-gpio-driver.patch
> Please use the correct prefix for patches, see
> https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/generic/PATCHES
> I would add the watchdog patches like this instead of squashing them,
> created with git format-patch:
> target/linux/generic/patches-4.4/097-0001-sp5100_tco-Add-AMD-Mullins-platform-support.patch
> target/linux/generic/patches-4.4/097-0002-sp5100_tco-Add-AMD-Mullins-platform-support.patch
> target/linux/generic/patches-4.4/097-0003-sp5100_tco-fix-the-device-check-for-SB800-and-later-chipsets.patch
> target/linux/generic/patches-4.4/097-0004-watchdog-sp5100_tco-properly-check-for-new-register-.patch
>
> Thanks,
> Stijn

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


Re: [LEDE-DEV] [RFC 0/1] x86: Add support for the PC Engines APU2 Board

2016-10-16 Thread Dave Taht
Everything important in CeroWrt long ago made it upstream - the apu2
(which, btw, I have been using as my main test platform for the
make-wifi-fast work) has BQL on the intel network drivers, already,
fq_codel is the default in lede, sch_cake is available as an optional
package, and the make-wifo-fast ath9k work is partially upstream in
lede, with only the airtime fairness patches remaining to get folded
in (http://blog.cerowrt.org/post/real_results/ more detail here:
https://blog.tohojo.dk/2016/06/fixing-the-wifi-performance-anomaly-on-ath9k.html
).

dnsmasq-dnssec is an optional package in lede as are the sqm-scripts,
luci-app-sqm, and the bcp38 support.

So all that is pretty generic to lede/openwrt now. Ath10k needs work,
mt72 needs work, but in neither case is that specific to the apu2.

What never made it to openwrt from cerowrt was:

A) the controversial "rename the devices to reflect the security
model" portion of the firewall code. That code allowed for never
having to reload the firewall as it used a pattern match on the device
name to dynamically add devices to a secure or guest zone. Instead of
having one rule for eth0, eth1, eth2, I renamed devices to se00, se01,
ge00, and used "s+" as the match.

I never figured out how to make that work with vlans, and it was my
hope we'd end up with something using nftables that did the same
thing. Not huge on reloading firewall rules all the time

B) homenet support - that's available in openwrt but not well
incorporated. That's hnetd, and babeld and the mdns-proxy stuff.

C) routing, not bridging, by default, Routing makes a lot of sense in
a lot of cases, and making sure openwrt does that well is something
that should be on-going tested - with batman, babel, olsr, etc. The
rest of the time bridging is generally faster and simpler.

There may well be other cerowrt features I'm forgetting, but that's
all I can think of.

I look forward to migrating my apu2s to lede soon!

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


Re: [LEDE-DEV] [RFC 0/1] x86: Add support for the PC Engines APU2 Board

2016-10-16 Thread Alberto Bursi


On 10/16/2016 11:49 AM, STR . wrote:
> Could we also build 'lsusb' along with lspci? I'd recommend bundling the
> usb-serial-kmod too as a lot of mini-pci devices present themselves as USB.

Yes to this. Many 3G/4G modems on mini-pcie port are using usb lines of 
mini-pcie port and not pcie lines.

-Alberto

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


[LEDE-DEV] [RFC 0/1] x86: Add support for the PC Engines APU2 Board

2016-10-16 Thread STR .
My 2c on USB, lm-sensors and the NCT chip on this board.

> This is an RFC to port the PC Engines APU2 board to LEDE. Currently this
is based on my unofficial repo at https://github.com/riptidewave93/LEDE-APU2
and after a discussion on the lede-dev IRC on the best plan of action, which
was to move this device to a profile under x86_64.
> Default Packages:
> - flashrom - BIOS Upgrades
> - lm-sensors - Temp Monitoring

lm-sensors does not report individual core temps. FreeBSD/PFsense reports
all 4 core temps correctly.

root@lede:/# sensors
k10temp-pci-00c3
Adapter: PCI adapter
temp1:+62.0°C  (high = +70.0°C)
   (crit = +105.0°C, hyst = +104.0°C)
root@lede:/# sensors -u
k10temp-pci-00c3
Adapter: PCI adapter
temp1:
  temp1_input: 62.375
  temp1_max: 70.000
  temp1_crit: 105.000
  temp1_crit_hyst: 104.000

Could this be an issue of missing PCI device IDs? From
https://github.com/torvalds/linux/blob/master/include/linux/pci_ids.h
k10temp.c has these missing:
#define PCI_DEVICE_ID_AMD_16H_NB_F3 0x1533
#define PCI_DEVICE_ID_AMD_16H_NB_F4 0x1534
#define PCI_DEVICE_ID_AMD_16H_M30H_NB_F3 0x1583
#define PCI_DEVICE_ID_AMD_16H_M30H_NB_F4 0x1584

temp1max is set to 70C, the AMD GX-412TC in the APU uses the PCengines case
as a heatsink via thermal pads. If ambient temps are high (=>30C), I've seen
the CPU go as high as 73C, AMD rates the GX-412TC from 0C - 90C so should
temp1max be set to something like 75C?


The board has 2x USB3.0 ports at the rear and 2x USB 2 header on the SoC.
Could we also build 'lsusb' along with lspci? I'd recommend bundling the
usb-serial-kmod too as a lot of mini-pci devices present themselves as USB.
USB 3.0 seems to be working:
root@lede:/# lspci | grep XHCI
00:10.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI
Controller (rev 11)

/* According to the USB 3.0 spec, all USB 3.0 devices must support LPM.
However, there are some that don't, and they set the U1/U2 exit latencies to
zero.
With some quirks?
root@lede:/# dmesg|grep LPM
[1.324138] usb usb3: We don't know the algorithms for LPM for this host,
disabling LPM.


> - NCT5104D GPIO Driver
This is simply good to know info.
The NCT5104D I/O controller with an alternate BIOS (work in progress,
provided by PCengines support on request) can provide 2 more serial ports
(com3/4) while disabling GPIO/I2C. This is useful in some situations as COM1
is generally tied to serial console and sadly com2/UART b provided via
headers on the board does not provide all the signals. "UART-b is brought to
J3 unshifted.  Even though J3 has five pins only transmit, receive and
ground are connected. - Paul"

Likely unrelated, perhaps at some point changes from CeroWRT could be
incorporated as the APU2 does suffer from buffer bloat -
https://www.bufferbloat.net/projects/cerowrt/wiki/How_is_CeroWrt_different_f
rom_OpenWrt/

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


Re: [LEDE-DEV] Adding support for dlink dwr-512

2016-10-16 Thread Giuseppe Lippolis
Mathias,
Thanks for the tips.
I'm going to work on it.

Bye.

> -Ursprüngliche Nachricht-
> Von: Mathias Kresin [mailto:d...@kresin.me]
> Gesendet: Sonntag, 16. Oktober 2016 09:54
> An: Giuseppe Lippolis ; lede-
> d...@lists.infradead.org
> Betreff: Re: [LEDE-DEV] Adding support for dlink dwr-512
> 
> Hi Giuseppe,
> 
> find a few remarks inline.
> 
> 16.10.2016 00:03, Giuseppe Lippolis:
> > Hi all,
> > I'm proceeding to finalize the support:
> > Now the wifi is enabled, the LEDs and the buttons are supported.
> >
> > To complete the device support I need to:
> > 1. enable the 3G modem
> > 2. crack the header file to generate the factory image
> 
> Run the strings command on the binboy binary. The binary includes some
> text which looks to me like the description of different headers.
> 
> It might be possible that there is already a tool for writing the binboy
header
> in tools/firmware-utils.
> 
> >
> > Will take some time.
> >
> > In the meantime, here the patch:
> >
> > 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 c8b57ca..719078c 100755
> > --- a/target/linux/ramips/base-files/etc/board.d/02_network
> > +++ b/target/linux/ramips/base-files/etc/board.d/02_network
> > @@ -71,6 +71,7 @@ ramips_setup_interfaces()
> > dir-320-b1|\
> > dir-610-a1|\
> > dir-615-h1|\
> > +   dwr-512-b|\
> > firewrt|\
> > hlk-rm04|\
> > mac1200rv2|\
> > diff --git a/target/linux/ramips/base-files/lib/ramips.sh
> > b/target/linux/ramips/base-files/lib/ramips.sh
> > index bb379f7..a0f041e 100755
> > --- a/target/linux/ramips/base-files/lib/ramips.sh
> > +++ b/target/linux/ramips/base-files/lib/ramips.sh
> > @@ -154,6 +154,9 @@ ramips_board_detect() {
> > *"DIR-860L B1")
> > name="dir-860l-b1"
> > ;;
> > +   *"DWR-512 B")
> > +   name="dwr-512-b"
> > +   ;;
> > *"Dovado Tiny AC")
> > name="tiny-ac"
> > ;;
> > diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh
> > b/target/linux/ramips/base-files/lib/upgrade/platform.sh
> > index 0ef2308..36ea469 100755
> > --- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
> > +++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
> > @@ -50,6 +50,7 @@ platform_check_image() {
> > dir-620-a1|\
> > dir-620-d1|\
> > dir-810l|\
> > +   dwr-512-b|\
> > duzun-dm06|\
> > e1700|\
> > esr-9753|\
> > diff --git a/target/linux/ramips/dts/DWR-512-B.dts
> > b/target/linux/ramips/dts/DWR-512-B.dts
> > index e69de29..2a69ce7 100644
> > --- a/target/linux/ramips/dts/DWR-512-B.dts
> > +++ b/target/linux/ramips/dts/DWR-512-B.dts
> > @@ -0,0 +1,109 @@
> > +/dts-v1/;
> > +
> > +/include/ "rt5350.dtsi"
> > +
> > +/ {
> > +   compatible = "ralink,rt5350-soc";
> > +   model = "D-Link DWR-512 B";
> > +
> > +   gpio-keys-polled {
> > +   compatible = "gpio-keys-polled";
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +   poll-interval = <20>;
> > +
> > +   wps {
> > +   label = "wps";
> > +   gpios = < 0 1>;
> > +   linux,code = <0x211>;
> > +   };
> > +   };
> > +
> > +   gpio-leds {
> > +   compatible = "gpio-leds";
> > +
> > +   sms {
> > +   label = "dwr-512-b:green:sms";
> > +   gpios = < 8 1>;
> > +   };
> > +   status {
> > +   label = "dwr-512-b:green:status";
> > +   gpios = < 9 1>;
> > +   };
> > +   2g {
> > +   label = "dwr-512-b:green:2g";
> > +   gpios = < 17 1>;
> > +   };
> > +   3g {
> > +   label = "dwr-512-b:green:3g";
> > +   gpios = < 19 1>;
> > +   };
> > +   sstrengthr {
> > +   label = "dwr-512-b:red:sigstrength";
> > +   gpios = < 20 1>;
> > +   };
> > +   sstrengthg {
> > +   label = "dwr-512-b:green:sigstrength";
> > +   gpios = < 21 1>;
> > +   };
> > +   };
> > +};
> > +
> > + {
> > +   status = "okay";
> > +
> > +   mx25l6405d@0 {
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +   compatible = "macronix,mx25l6405d", "jedec,spi-nor";
> > +   reg = <0>;
> > +   spi-max-frequency = <3000>;
> > +   fast-read;
> > +
> > +   partition@0 {
> > +   label = "bootloader";
> > +   reg = <0x0 0x1>;
> > +   read-only;
> > +   };
> > +
> > +   partition@1 {
> > +   label = "Kernel";
> > +   reg = <0x1 0x14>;
> > +   read-only;
> > +   };
> > +
> > +   partition@15 {
> > +   label = "rootfs";
>