date:20200227

Re: [OpenWrt-Devel] [PATCH] kirkwood: convert DTS patches into plain DTS files

2020-02-27 Thread Raylynn Knight via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Don’t know how successful I’ll be at upstreaming as the last time I had code 
accepted into the kernel was back in 2002/2003 when I was active in the m68k 
Mac port.   It will probably be late March before I will have time I can commit 
to the effort, but I have a large collection of Kirkwood based devices that I 
would like to see upstreamed and supported by OpenWrt.  I just need to find the 
time to work on them!

Ray

> On Feb 27, 2020, at 3:44 AM, Alberto Bursi  wrote:
> 
> 
> 
> On 27/02/20 06:16, Raylynn Knight via openwrt-devel wrote:
>> The sender domain has a DMARC Reject/Quarantine policy which disallows
>> sending mailing list messages using the original "From" header.
>> 
>> To mitigate this problem, the original message has been wrapped
>> automatically by the mailing list software.
>> 
>> 
>> Sorry, I did intend the email for the list.
>> 
>> I actually have an example of all of the devices affected by this patch 
>> except the nsa310b.  Would there be any issue with me trying to get the 
>> OpenWrt patches upstreamed?
>> 
>> Ray
>>  
>> 
>> 
>> 
>> ___
>> openwrt-devel mailing list
>> 
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 
> 
> I have a nsa310b and I can test things on it, if you want to upstream its 
> patches.
> 
> If you are good at upstreaming, could you also consider upstreaming the 
> ledtrig-libata patch?
> 
> https://github.com/openwrt/openwrt/blob/master/target/linux/generic/pending-4.19/834-ledtrig-libata.patch
> 
> It's about creating a led trigger for each SATA port and it would be nice to 
> have upstream too.
> 
> -Alberto
> 

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

[OpenWrt-Devel] 4k sectors in ath79's SPI NOR for MikroTik devices

2020-02-27 Thread Roger Pueyo Centelles | Guifi.net via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hi,

Recently, a couple of MikroTik devices have been ported from the ar71xx
target to the ath79 one (the ath79/generic RB wAP G-5HacT2HnD (wAP AC)

[1] and the ath79/nand RB 922UAGS-5HPacD

[2]).

Only after the commits were merged upstream I realised that, since some
of the partitions on the SPI NOR storage are sized 4 kB, the
CONFIG_MTD_SPI_NOR_USE_4K_SECTORS kernel configuration item is needed.
Otherwise, the soft_config partition (it contains the bootloader's
settings) can't be modified or, in the worse case, other partitions are
accidentally erased when modifying it (you can see the discussion at
GitHub's pull request #2791
 [3]).

CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not enabled by default on
ath79/generic or ath79/nand, but used to be in ar71xx/mikrotik and is
also in ath79/tiny

[4] (there was discussion on the mailing list

also [5]).

In order to allow these MikroTik devices correctly write to the
partitions (reading works OK right now), as far as I know, there would
be three options:

1- Adding the CONFIG_MTD_SPI_NOR_USE_4K_SECTORS to ath79/generic and
ath79/nand (i.e., to the whole ath79 target)
 · PROS: it works
 · CONS: probably breaks sysupgrade for other devices (?)

2- Forcing conflicting small partitions as read-only
 · PROS: nothing can be broken
 · CONS: bootloader settings won't be modifiable (e.g., with rbcfg
 [6])

3- Creating a new ath79/mikrotik subtarget
 · PROS: it works, and all MikroTik-specific features and tweaks are
concentrated there, no technical problems or missing features should arise
 · CONS: mostly looks like a manufacturer-specific subtarget...


Therefore, I would like to ask for your advice, so we can together
decide on how to proceed:

Q1- Does adding CONFIG_MTD_SPI_NOR_USE_4K_SECTORS now to ath79/generic
and ath79/nand break sysupgrade?

Q2- Which option among the three ones, or any other, is the best?


Thanks,

Roger

--

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

[2]
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=8f93c05a591bd68e4d8eaa0a8468ce2263762004

[3] https://github.com/openwrt/openwrt/pull/2791

[4]
http://lists.infradead.org/pipermail/openwrt-devel/2019-November/020358.html

[5]
http://lists.infradead.org/pipermail/openwrt-devel/2019-December/020864.html

[6] https://openwrt.org/packages/pkgdata/rbcfg



signature.asc
Description: OpenPGP digital signature
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/2] kirkwood: switch to kernel 4.19

2020-02-27 Thread Adrian Schmutzler

From: Pawel Dembicki 

Signed-off-by: Pawel Dembicki 
---

Since I've mostly done cosmetic changes on this target,
I'd be happy about an Acked-by so I can push this bump.
The patch for adding 4.19 support on this target is actually
from 2018.

Adrian

---
 target/linux/kirkwood/Makefile | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/target/linux/kirkwood/Makefile b/target/linux/kirkwood/Makefile
index adc7a496e1..2e615e42bd 100644
--- a/target/linux/kirkwood/Makefile
+++ b/target/linux/kirkwood/Makefile
@@ -13,8 +13,7 @@ FEATURES:=usb nand squashfs ramdisk
 CPU_TYPE:=xscale
 MAINTAINER:=Luka Perkov 
 
-KERNEL_PATCHVER:=4.14
-KERNEL_TESTING_PATCHVER := 4.19
+KERNEL_PATCHVER:=4.19
 
 include $(INCLUDE_DIR)/target.mk
 
-- 
2.20.1


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

[OpenWrt-Devel] [PATCH 1/2] kirkwood: fix switch DTS node for EA4500 and EA3500

2020-02-27 Thread Adrian Schmutzler

From: Pawel Dembicki 

Changes made in switch nodes in d42c9ce commit cause problems with
correct mvsw61xx detection. This commit undoes those changes.

Fixes: d42c9ce326aa ("kirkwood: add kernel 4.19 support")

Tested-by: Marcin Fedan  [EA4500]
Signed-off-by: Pawel Dembicki 
[rebased, minor commit message/title adjustments]
Signed-off-by: Adrian Schmutzler 
---
 .../arm/boot/dts/kirkwood-linksys-audi.dts| 23 ++
 .../kirkwood/patches-4.19/105-ea4500.patch| 31 ---
 2 files changed, 22 insertions(+), 32 deletions(-)

diff --git 
a/target/linux/kirkwood/files-4.19/arch/arm/boot/dts/kirkwood-linksys-audi.dts 
b/target/linux/kirkwood/files-4.19/arch/arm/boot/dts/kirkwood-linksys-audi.dts
index 0d00943dfd..05e24aa93f 100644
--- 
a/target/linux/kirkwood/files-4.19/arch/arm/boot/dts/kirkwood-linksys-audi.dts
+++ 
b/target/linux/kirkwood/files-4.19/arch/arm/boot/dts/kirkwood-linksys-audi.dts
@@ -67,20 +67,15 @@
};
};
 
-   switches {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   mvsw61xx@10 {
-   compatible = "marvell,88e6171";
-   status = "okay";
-   reg = <0x10>;
-
-   mii-bus = <>;
-   cpu-port-0 = <5>;
-   cpu-port-1 = <6>;
-   is-indirect;
-   };
+   mvsw61xx {
+   compatible = "marvell,88e6171";
+   status = "okay";
+   reg = <0x10>;
+
+   mii-bus = <>;
+   cpu-port-0 = <5>;
+   cpu-port-1 = <6>;
+   is-indirect;
};
 
dsa {
diff --git a/target/linux/kirkwood/patches-4.19/105-ea4500.patch 
b/target/linux/kirkwood/patches-4.19/105-ea4500.patch
index 5948a1bdf1..3e6f936c5a 100644
--- a/target/linux/kirkwood/patches-4.19/105-ea4500.patch
+++ b/target/linux/kirkwood/patches-4.19/105-ea4500.patch
@@ -23,33 +23,28 @@
};
  
white-pulse {
-@@ -67,9 +72,23 @@
+@@ -67,9 +72,18 @@
};
};
  
 -  dsa {
 -  status = "disabled";
-+  switches {
-+  #address-cells = <1>;
-+  #size-cells = <0>;
- 
-+  mvsw61xx@10 {
-+  compatible = "marvell,88e6171";
-+  status = "okay";
-+  reg = <0x10>;
++  mvsw61xx@10 {
++  compatible = "marvell,88e6171";
++  status = "okay";
++  reg = <0x10>;
 +
-+  mii-bus = <>;
-+  cpu-port-0 = <5>;
-+  cpu-port-1 = <6>;
-+  is-indirect;
-+  };
++  mii-bus = <>;
++  cpu-port-0 = <5>;
++  cpu-port-1 = <6>;
++  is-indirect;
 +  };
-+
+ 
 +  dsa {
compatible = "marvell,dsa";
#address-cells = <2>;
#size-cells = <0>;
-@@ -161,22 +180,22 @@
+@@ -161,22 +175,22 @@
};
  
partition@20 {
@@ -76,7 +71,7 @@
reg = <0x1EA 0x176>;
};
  
-@@ -207,53 +226,6 @@
+@@ -207,53 +221,6 @@
  
   {
status = "okay";
@@ -130,7 +125,7 @@
  };
  
   {
-@@ -272,10 +244,14 @@
+@@ -272,10 +239,14 @@
  };
  
  /* eth1 is connected to the switch at port 6. However DSA only supports a
-- 
2.20.1


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

Re: [OpenWrt-Devel] [PATCH v2] ramips: add TRENDnet TEW-810DR support

2020-02-27 Thread Adrian Schmutzler

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
> Behalf Of Heppler, J. Scott
> Sent: Donnerstag, 27. Februar 2020 14:29
> To: openwrt-de...@openwrt.org
> Subject: Re: [OpenWrt-Devel] [PATCH v2] ramips: add TRENDnet TEW-810DR
> support
> 
> On Feb 27, 2020: 13:37, Adrian Schmutzler wrote:
> >Hi,
> >
> >> -Original Message-
> >> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
> >> Behalf Of Heppler, J. Scott
> >> Sent: Donnerstag, 27. Februar 2020 03:39
> >> To: openwrt-de...@openwrt.org
> >> Subject: [OpenWrt-Devel] [PATCH v2] ramips: add TRENDnet TEW-810DR
> support
> >>
> >> Signed-off-by: J. Scott Heppler 
> >>
> >> ramips: add support for TRENDnet TEW-810DR
> >>
> >> Exact hardware clone for the D-Link DIR-810L.  See OpenWRT device pages
> >> and review the PCB photos, boot logs and MTP flash partitions.
> >> https://openwrt.org/toh/trendnet/trendnet_tew-810dr_1.0_1.1
> >> https://openwrt.org/toh/d-link/dir-810l
> >>
> >> Specification:
> >>
> >> * MediaTek MT7620A (580 Mhz)
> >> * 8 MB of FLASH
> >> * 64 MB of RAM
> >> * 5x 10/100 Mbps Ethernet (1 WAN and 4 LAN)
> >> * UART header on PCB (57600 8n1)
> >> * 2x BiColor LED (GPIO-controlled)
> >> * 2x button - power and reset
> >> * U-boot bootloader
> >>
> >> Installation:
> >>
> >> The sysupgrade.bin image needs to have a cameo hardware ID appended
> >> with ncc_att_hwid.  ncc_att_hwid is available in the GPL Source
> >> download for either the TEW-810DR or DIR-810L and is located at
> >> source/user/wolf/cameo/ncc/hostTools
> >> The invocation is:
> >> ncc_att_hwid -f tew-810-squashfs-factory.bin -a -m “TEW-810DR”
> >> -H “1.0R” -r “WW” -c “1.0”
> >> More information is available in the device page for TEW-810DR linked
> >> above The appended image can then be flash via the Web rescue interface
> >> 192.168.10.1 or TFTP's to the same IP address.  Subsequent upgrades
> >> can be done using the Luci web interface or the ssh command line per the
> >> OpenWRT documentation
> >> ---
> >>  .../ramips/dts/mt7620a_trendnet_tew-810dr.dts | 157
> ++
> >>  target/linux/ramips/image/mt7620.mk   |  10 ++
> >>  .../mt7620/base-files/etc/board.d/02_network  |   3 +-
> >>  3 files changed, 169 insertions(+), 1 deletion(-)
> >>  create mode 100644 target/linux/ramips/dts/mt7620a_trendnet_tew-
> 810dr.dts
> >>
> >> diff --git a/target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts
> >> b/target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts
> >> new file mode 100644
> >> index 00..eb38110801
> >> --- /dev/null
> >> +++ b/target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts
> >
> >shared DTSI with dir-810l ?
> 
> I'm worried about altering the DIR-810L code.  I do not have the D-Link
> to test and it was submitted by someone else.

I will send a some patches for the DIR-810L in a minute. Those should make it 
easier to move a lot of code into a shared DTSI. Obviously, stuff that still 
deviates would be kept in the DTSes.

> >
> >> @@ -0,0 +1,157 @@
> >> +/dts-v1/;
> >> +
> >> +#include "mt7620a.dtsi"
> >> +
> >> +#include 
> >> +#include 
> >> +
> >> +/ {
> >> +  compatible = "trendnet,tew-810dr", "ralink,mt7620a-soc";
> >> +  model = "TRENDnet TEW-810DR";
> >> +
> >> +  aliases {
> >> +  led-boot = _power_green;
> >> +  led-failsafe = _power_green;
> >> +  led-running = _power_green;
> >> +  led-upgrade = _power_green;
> >> +  label-mac-device = 
> >> +  };
> >> +
> >> +  keys {
> >> +  compatible = "gpio-keys";
> >> +
> >> +  reset {
> >> +  label = "reset";
> >> +  gpios = < 1 GPIO_ACTIVE_LOW>;
> >> +  linux,code = ;
> >> +  };
> >> +
> >> +  wps {
> >> +  label = "wps";
> >> +  gpios = < 2 GPIO_ACTIVE_LOW>;
> >> +  linux,code = ;
> >
> >Why not use the proper codes on these?  Would the code also need to be
> >altered on the DIR-810L?  Can you point me to reference?

See my patch for DIR-810L coming in a minute.

> >
> >> +  };
> >> +  };
> >> +
> >> +  leds {
> >> +  compatible = "gpio-leds";
> >> +
> >> +  led_power_green: power {
> >
> >led_power_green: power_green {
> >
> >> +  label = "dir-810l:green:power";
> >
> >That would be one of the few parts where both devices will be different (and
> which would not belong into a shared DTSI). But if you didn't even change the
> name, have you actually checked whether the LED GPIOs are the same?
> The Trendnet also has 2 pairs of green/orange LEDs

So, what's the second green LED then?

> >
> >> +  gpios = < 9 GPIO_ACTIVE_HIGH>;
> >> +  };
> >> +
> >> +  wan {
> >> +  label = "dir-810l:orange:wan";
> >> +  gpios = < 12 GPIO_ACTIVE_HIGH>;
> >> +  };
> >> +
> >> +  power2 {
> >
> >power_orange
> >
> >> +

[OpenWrt-Devel] [PATCH 1/2] ramips: fix partition offset for D-Link DIR-810L

2020-02-27 Thread Adrian Schmutzler

The Jffs2 partition for the D-Link DIR-810L is currently off by
0x1. Apply the correct offset based on the other partitions'
size/offset and the information about stock OS from the Wiki.

This is just based on the named information and _not_ verified
on device.

Fixes: 36e3424fa520 ("ramips: add support for dir810l and asus rp-n53")

Signed-off-by: Adrian Schmutzler 
---
 target/linux/ramips/dts/mt7620a_dlink_dir-810l.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/target/linux/ramips/dts/mt7620a_dlink_dir-810l.dts 
b/target/linux/ramips/dts/mt7620a_dlink_dir-810l.dts
index da8d2238a1..0b1ca26ba4 100644
--- a/target/linux/ramips/dts/mt7620a_dlink_dir-810l.dts
+++ b/target/linux/ramips/dts/mt7620a_dlink_dir-810l.dts
@@ -102,9 +102,9 @@
read-only;
};
 
-   partition@e {
+   partition@f {
label = "Jffs2";
-   reg = <0xe 0x8>;
+   reg = <0xf 0x8>;
read-only;
};
 
-- 
2.20.1


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

[OpenWrt-Devel] [PATCH 2/2] ramips: fix and tidy up DTS for D-Link DIR-810L

2020-02-27 Thread Adrian Schmutzler

This patch addresses several issues for D-Link DIR-810L:

- add correct button codes
- harmonize button node names
- use generic flash@0
- remove unused pin groups from state_default
- improve sorting of properties

The patch is only build-tested.

Signed-off-by: Adrian Schmutzler 

---

If somebody owns this device, I'd be delighted about a test of both patches
in general as well as if somebody would test if higher SPI frequency is
possible.

---
 .../ramips/dts/mt7620a_dlink_dir-810l.dts  | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/target/linux/ramips/dts/mt7620a_dlink_dir-810l.dts 
b/target/linux/ramips/dts/mt7620a_dlink_dir-810l.dts
index 0b1ca26ba4..514e9cc354 100644
--- a/target/linux/ramips/dts/mt7620a_dlink_dir-810l.dts
+++ b/target/linux/ramips/dts/mt7620a_dlink_dir-810l.dts
@@ -23,20 +23,20 @@
reset {
label = "reset";
gpios = < 1 GPIO_ACTIVE_LOW>;
-   linux,code = ;
+   linux,code = ;
};
 
wps {
label = "wps";
gpios = < 2 GPIO_ACTIVE_LOW>;
-   linux,code = ;
+   linux,code = ;
};
};
 
leds {
compatible = "gpio-leds";
 
-   led_power_green: power {
+   led_power_green: power_green {
label = "dir-810l:green:power";
gpios = < 9 GPIO_ACTIVE_HIGH>;
};
@@ -46,7 +46,7 @@
gpios = < 12 GPIO_ACTIVE_HIGH>;
};
 
-   power2 {
+   power_orange {
label = "dir-810l:orange:power";
gpios = < 13 GPIO_ACTIVE_HIGH>;
};
@@ -56,7 +56,7 @@
  {
status = "okay";
 
-   m25p80@0 {
+   flash@0 {
compatible = "jedec,spi-nor";
reg = <0>;
spi-max-frequency = <1000>;
@@ -119,7 +119,7 @@
 
 _default {
gpio {
-   ralink,group = "mdio", "rgmii1", "i2c", "wled", "uartf";
+   ralink,group = "i2c", "uartf";
ralink,function = "gpio";
};
 };
@@ -130,9 +130,10 @@
 };
 
  {
-   mediatek,port4 = "ephy";
pinctrl-names = "default";
pinctrl-0 = <_pins>;
+
+   mediatek,port4 = "ephy";
 };
 
  {
@@ -140,9 +141,10 @@
 };
 
  {
-   ralink,mtd-eeprom = < 0x0>;
pinctrl-names = "default";
pinctrl-0 = <_pins>;
+
+   ralink,mtd-eeprom = < 0x0>;
mtd-mac-address = < 0x28>;
 };
 
-- 
2.20.1


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

Re: [OpenWrt-Devel] [PATCH v2] ramips: add TRENDnet TEW-810DR support

2020-02-27 Thread Heppler, J. Scott


On Feb 27, 2020: 13:37, Adrian Schmutzler wrote:

Hi,


-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
Behalf Of Heppler, J. Scott
Sent: Donnerstag, 27. Februar 2020 03:39
To: openwrt-de...@openwrt.org
Subject: [OpenWrt-Devel] [PATCH v2] ramips: add TRENDnet TEW-810DR support

Signed-off-by: J. Scott Heppler 

ramips: add support for TRENDnet TEW-810DR

Exact hardware clone for the D-Link DIR-810L.  See OpenWRT device pages
and review the PCB photos, boot logs and MTP flash partitions.
https://openwrt.org/toh/trendnet/trendnet_tew-810dr_1.0_1.1
https://openwrt.org/toh/d-link/dir-810l

Specification:

* MediaTek MT7620A (580 Mhz)
* 8 MB of FLASH
* 64 MB of RAM
* 5x 10/100 Mbps Ethernet (1 WAN and 4 LAN)
* UART header on PCB (57600 8n1)
* 2x BiColor LED (GPIO-controlled)
* 2x button - power and reset
* U-boot bootloader

Installation:

The sysupgrade.bin image needs to have a cameo hardware ID appended
with ncc_att_hwid.  ncc_att_hwid is available in the GPL Source
download for either the TEW-810DR or DIR-810L and is located at
source/user/wolf/cameo/ncc/hostTools
The invocation is:
ncc_att_hwid -f tew-810-squashfs-factory.bin -a -m “TEW-810DR”
-H “1.0R” -r “WW” -c “1.0”
More information is available in the device page for TEW-810DR linked
above The appended image can then be flash via the Web rescue interface
192.168.10.1 or TFTP's to the same IP address.  Subsequent upgrades
can be done using the Luci web interface or the ssh command line per the
OpenWRT documentation
---
 .../ramips/dts/mt7620a_trendnet_tew-810dr.dts | 157 ++
 target/linux/ramips/image/mt7620.mk   |  10 ++
 .../mt7620/base-files/etc/board.d/02_network  |   3 +-
 3 files changed, 169 insertions(+), 1 deletion(-)
 create mode 100644 target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts

diff --git a/target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts
b/target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts
new file mode 100644
index 00..eb38110801
--- /dev/null
+++ b/target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts


shared DTSI with dir-810l ?


I'm worried about altering the DIR-810L code.  I do not have the D-Link
to test and it was submitted by someone else.



@@ -0,0 +1,157 @@
+/dts-v1/;
+
+#include "mt7620a.dtsi"
+
+#include 
+#include 
+
+/ {
+   compatible = "trendnet,tew-810dr", "ralink,mt7620a-soc";
+   model = "TRENDnet TEW-810DR";
+
+   aliases {
+   led-boot = _power_green;
+   led-failsafe = _power_green;
+   led-running = _power_green;
+   led-upgrade = _power_green;
+   label-mac-device = 
+   };
+
+   keys {
+   compatible = "gpio-keys";
+
+   reset {
+   label = "reset";
+   gpios = < 1 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+
+   wps {
+   label = "wps";
+   gpios = < 2 GPIO_ACTIVE_LOW>;
+   linux,code = ;


Why not use the proper codes on these?  Would the code also need to be
altered on the DIR-810L?  Can you point me to reference?


+   };
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   led_power_green: power {


led_power_green: power_green {


+   label = "dir-810l:green:power";


That would be one of the few parts where both devices will be different (and 
which would not belong into a shared DTSI). But if you didn't even change the 
name, have you actually checked whether the LED GPIOs are the same?

The Trendnet also has 2 pairs of green/orange LEDs



+   gpios = < 9 GPIO_ACTIVE_HIGH>;
+   };
+
+   wan {
+   label = "dir-810l:orange:wan";
+   gpios = < 12 GPIO_ACTIVE_HIGH>;
+   };
+
+   power2 {


power_orange


+   label = "dir-810l:orange:power";
+   gpios = < 13 GPIO_ACTIVE_HIGH>;
+   };
+   };
+};
+
+ {
+   status = "okay";
+
+   m25p80@0 {


flash@0


+   compatible = "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <1000>;


Can this go faster?

Would this would go in a shared dtsi.  Should I make a change on a
device I do not have access to?



+
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   partition@0 {
+   label = "u-boot";
+   reg = <0x0 0x3>;
+   read-only;
+   };
+
+   partition@3 {
+   label = "u-boot-env";
+   reg = <0x3

Re: [OpenWrt-Devel] [PATCH RFC] ath79: add support for the ar7240 version of the ubiquiti bullet

2020-02-27 Thread Russell Senior

Sorry for the accidental sidetrack to private mail. Returning the thread to
the mailing list.

On Thu, Feb 27, 2020 at 5:16 AM Adrian Schmutzler 
wrote:

> Hi,
> > What happens if you flash the "wrong" image? Do you see any chance to
> have one of the images as "default" without suffix or would this make
> things worse?
> >
> > Currently only the ar7241 is supported in ath79. If you flash an ar7241
> image on an ar7240 device, the wireless works but the ethernet does not. I
> have not tried the other way around, but I'd expect the same thing. I >
> don't actually have ready access to an ar7241-based ubnt-bullet-m to try an
> ar7240 image on to confirm that expectation.
>
> I have a Picostation M2HP (XM) where I could technically try an ar7240
> bullet-m image. However, I do not think we will learn much from that, as
> essentially the difference between ar7240.dtsi and ar7241.dtsi are a few
> compatibles and that mdio1 is used instead of mdio0, so I'd expect similar
> results to what you described for the opposite case.
> My main reason for the question was damage assessment, but with Wifi
> disabled by default and Ethernet broken one would still need TFTP for
> recovery as this sounds to me.
>
> I also briefly considered providing a mixed ar7240/ar7241 support as for
> ar71xx, but I quickly quit on that as it's hard to achieve and terribly
> ugly.
>
> So, I still do not have a better idea than the different names/variants at
> the moment.
>

Yeah. I am not seeing a particularly better path either, although I dislike
the duplication of the dtsi's.


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

Re: [OpenWrt-Devel] [PATCH v2] ramips: add TRENDnet TEW-810DR support

2020-02-27 Thread Adrian Schmutzler

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
> Behalf Of Heppler, J. Scott
> Sent: Donnerstag, 27. Februar 2020 03:39
> To: openwrt-de...@openwrt.org
> Subject: [OpenWrt-Devel] [PATCH v2] ramips: add TRENDnet TEW-810DR support
> 
> Signed-off-by: J. Scott Heppler 
> 
> ramips: add support for TRENDnet TEW-810DR
> 
> Exact hardware clone for the D-Link DIR-810L.  See OpenWRT device pages
> and review the PCB photos, boot logs and MTP flash partitions.
> https://openwrt.org/toh/trendnet/trendnet_tew-810dr_1.0_1.1
> https://openwrt.org/toh/d-link/dir-810l
> 
> Specification:
> 
> * MediaTek MT7620A (580 Mhz)
> * 8 MB of FLASH
> * 64 MB of RAM
> * 5x 10/100 Mbps Ethernet (1 WAN and 4 LAN)
> * UART header on PCB (57600 8n1)
> * 2x BiColor LED (GPIO-controlled)
> * 2x button - power and reset
> * U-boot bootloader
> 
> Installation:
> 
> The sysupgrade.bin image needs to have a cameo hardware ID appended
> with ncc_att_hwid.  ncc_att_hwid is available in the GPL Source
> download for either the TEW-810DR or DIR-810L and is located at
> source/user/wolf/cameo/ncc/hostTools
> The invocation is:
> ncc_att_hwid -f tew-810-squashfs-factory.bin -a -m “TEW-810DR”
> -H “1.0R” -r “WW” -c “1.0”
> More information is available in the device page for TEW-810DR linked
> above The appended image can then be flash via the Web rescue interface
> 192.168.10.1 or TFTP's to the same IP address.  Subsequent upgrades
> can be done using the Luci web interface or the ssh command line per the
> OpenWRT documentation
> ---
>  .../ramips/dts/mt7620a_trendnet_tew-810dr.dts | 157 ++
>  target/linux/ramips/image/mt7620.mk   |  10 ++
>  .../mt7620/base-files/etc/board.d/02_network  |   3 +-
>  3 files changed, 169 insertions(+), 1 deletion(-)
>  create mode 100644 target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts
> 
> diff --git a/target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts
> b/target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts
> new file mode 100644
> index 00..eb38110801
> --- /dev/null
> +++ b/target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts

shared DTSI with dir-810l ?

> @@ -0,0 +1,157 @@
> +/dts-v1/;
> +
> +#include "mt7620a.dtsi"
> +
> +#include 
> +#include 
> +
> +/ {
> + compatible = "trendnet,tew-810dr", "ralink,mt7620a-soc";
> + model = "TRENDnet TEW-810DR";
> +
> + aliases {
> + led-boot = _power_green;
> + led-failsafe = _power_green;
> + led-running = _power_green;
> + led-upgrade = _power_green;
> + label-mac-device = 
> + };
> +
> + keys {
> + compatible = "gpio-keys";
> +
> + reset {
> + label = "reset";
> + gpios = < 1 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> +
> + wps {
> + label = "wps";
> + gpios = < 2 GPIO_ACTIVE_LOW>;
> + linux,code = ;

Why not use the proper codes on these?

> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led_power_green: power {

led_power_green: power_green {

> + label = "dir-810l:green:power";

That would be one of the few parts where both devices will be different (and 
which would not belong into a shared DTSI). But if you didn't even change the 
name, have you actually checked whether the LED GPIOs are the same?

> + gpios = < 9 GPIO_ACTIVE_HIGH>;
> + };
> +
> + wan {
> + label = "dir-810l:orange:wan";
> + gpios = < 12 GPIO_ACTIVE_HIGH>;
> + };
> +
> + power2 {

power_orange

> + label = "dir-810l:orange:power";
> + gpios = < 13 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +};
> +
> + {
> + status = "okay";
> +
> + m25p80@0 {

flash@0

> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <1000>;

Can this go faster?

> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition@0 {
> + label = "u-boot";
> + reg = <0x0 0x3>;
> + read-only;
> + };
> +
> + partition@3 {
> + label = "u-boot-env";
> + reg = <0x3 0x1>;
> + read-only;
> + };
> +
> + factory: partition@4 {
> + label = "factory";
> + reg = <0x4 0x1>;
> +

Re: [OpenWrt-Devel] ipq40xx: QCE/crypto fixes & enhancements (PR #2518)

2020-02-27 Thread Paul Oranje

Op 26 feb. 2020, om 16:13 heeft Eneas Queiroz  het 
volgende geschreven:
> 
> On Wed, Feb 26, 2020 at 10:48 AM Paul Oranje  wrote:
>> 
>> Having read the whole conversation: an impressive piece of work.
>> 
>> Could this helps with ipq806x ?
>> On ipq806x qce isn't available on all SOCs (supposedly only on ipq8064) and 
>> therefore support has been removed from the kernel [1].
>> 
>> 
>> [1] commit ad07166ea7286f350628f1093e4385db9be63d31 (ipq806x: remove 
>> unsupported hw-crypto qce driver)
>> 
>> Regards,
>> Paul
>> 
> 
> Hi Paul
> 
> I'm glad you like it, thanks.
> 
> I don't know much about the ipq8064 crypto engine, other than it is
> not compatible with the ipq40xx one, and that's why I removed it from
> the image.  I looked into it superficially, but couldn't find much
> information about it.
> 
> What we can do right away is to enable the neon/arm-asm modules, as I
> did for ipq40xx.  I'll wait for ipq40xx's fate, before I apply the
> same logic to ipq806x, and perhaps others.  If I were to just grep for
> CONFIG_NEON=y, but not CONFIG_ARM_CRYPTO=y:
> $ git grep -L '^CONFIG_ARM_CRYPTO=y' -- $(git grep -l '^CONFIG_NEON=y'
> -- target/linux/) | xargs -r dirname | sort -u
> target/linux/armvirt/32
> target/linux/at91
> target/linux/bcm27xx/bcm2709
> target/linux/ipq40xx
> target/linux/ipq806x
> target/linux/layerscape/armv7
> target/linux/mediatek/mt7623
> target/linux/omap
> target/linux/samsung/s5pv210
> target/linux/sunxi
> target/linux/zynq
> 
> Cheers,
> 
> Eneas

So I shall patiently await the "fate".
Thanks,
Paul


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

Re: [OpenWrt-Devel] [PATCH RFC] ath79: add support for the ar7240 version of the ubiquiti bullet

2020-02-27 Thread Adrian Schmutzler

> > What's the base for the v0/v1 distinction? Is that visible to the user 
> > somehow?
> > I fear that meaningful naming will be the biggest problem here...
> 
> v0 and v1 mostly come from the need to distinguish between them. You could 
> think of the digit as the least significant digit of the SoC. We could make 
> them -7240 and -7241 instead of -v0 and -v1 to be slightly clearer what the 
> names mean, but that seemed ugly. And, no, as far as I know, the SoC is not 
> indicated on the exterior of the device at all. The user will have to figure 
> out the right version to use somehow.

That's what I feared. I do not like the -v0/-v1 very much because this is 
somewhat "reserved" by hardware revisions as TP-Link uses them, and will have 
everyone looking for a printed version on the device. So, I'd actually prefer 
-ar7240/-ar7241 suffixes (which will also clearly state what's the difference) 
unless we can find some identifier from Ubiquiti.

What happens if you flash the "wrong" image? Do you see any chance to have one 
of the images as "default" without suffix or would this make things worse? 

Best

Adrian 


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

Re: [OpenWrt-Devel] [PATCH] kirkwood: convert DTS patches into plain DTS files

2020-02-27 Thread Adrian Schmutzler

> -Original Message-
> From: Raylynn Knight [mailto:raykni...@me.com]
> Sent: Donnerstag, 27. Februar 2020 06:16
> To: Adrian Schmutzler 
> Cc: openWrt Development List 
> Subject: Re: [OpenWrt-Devel] [PATCH] kirkwood: convert DTS patches into plain
> DTS files
> 
> Sorry, I did intend the email for the list.
> 
> I actually have an example of all of the devices affected by this patch except
the
> nsa310b.  Would there be any issue with me trying to get the OpenWrt patches
> upstreamed?

You are welcome. I'd consider trying to contact the initial authors of the
patches beforehand for they maybe can provide help or additional insights.

I will merge this patch soon anyway, and will do a quick (partial) cosmetic
fixup on top as well. Maybe you wait for this so we get the "nicer" version into
kernel?

Best

Adrian

> 
> Ray
> 
> 
> > On Feb 25, 2020, at 5:55 AM, Adrian Schmutzler 
> wrote:
> >
> > Hi Ray,
> >
> > was this a private message by intention?
> >
> > This patch only reorganizes the existing files in OpenWrt's kirkwood. While
I've
> > been involved in cleaning up the kirkwood target recently, this not even my
> > patch.
> >
> > I personally don't think that upstreaming DTS files for devices I've never
even
> > touched is a good idea. For that, I think the best way would be to contact
the
> > original authors of device support or at least find somebody who really has
the
> > device.
> >
> > So, while I would welcome to upstream the code in general, I do not see that
> > this would be Sungbo Eo's or my job right now.
> >
> > In contrast, it might be a good idea to mention this in the currently
pending
> > device support PRs for Kirkwood if you think it would be worth it.
> >
> > Best
> >
> > Adrian
> >
> >> -Original Message-
> >> From: Raylynn Knight [mailto:raykni...@me.com]
> >> Sent: Dienstag, 25. Februar 2020 04:39
> >> To: Adrian Schmutzler 
> >> Subject: Re: [OpenWrt-Devel] [PATCH] kirkwood: convert DTS patches into
> plain
> >> DTS files
> >>
> >> What is the reason that these DTS files are not submitted upstream to the
> >> kernel?
> >>
> >> Ray
> >>
> >>
> >>> On Feb 24, 2020, at 8:23 AM, Adrian Schmutzler 
> >> wrote:
> >>>
> >>> Hi,
> >>>
>  -Original Message-
>  From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On
>  Behalf Of Sungbo Eo
>  Sent: Montag, 24. Februar 2020 13:06
>  To: openwrt-devel@lists.openwrt.org
>  Cc: Sungbo Eo 
>  Subject: [OpenWrt-Devel] [PATCH] kirkwood: convert DTS patches into
> plain
> >> DTS
>  files
> 
>  Move DTS files newly created by patch files to files directory. This will
> > make
>  these files much more maintainable.
> 
>  Patching the kernel Makefile is unnecessary, as the DTS files specified
in
>  DEVICE_DTS will be compiled by OpenWrt buildroot anyway.
> >>>
> >>> I personally see it the same way, though I'm aware this in handled
> > differently
> >>> for different targets.
> >>> This change will just remove one layer of complexity.
> >>>
> >>> Acked-by: Adrian Schmutzler 
> >>>
> >>> Best
> >>>
> >>> Adrian
> >>>
> >>>
> >>> ___
> >>> openwrt-devel mailing list
> >>> openwrt-devel@lists.openwrt.org
> >>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> >
> >



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

Re: [OpenWrt-Devel] [PATCH] kirkwood: convert DTS patches into plain DTS files

2020-02-27 Thread Alberto Bursi



On 27/02/20 06:16, Raylynn Knight via openwrt-devel wrote:

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.

Sorry, I did intend the email for the list.

I actually have an example of all of the devices affected by this patch except 
the nsa310b.  Would there be any issue with me trying to get the OpenWrt 
patches upstreamed?

Ray
  


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



I have a nsa310b and I can test things on it, if you want to upstream 
its patches.


If you are good at upstreaming, could you also consider upstreaming the 
ledtrig-libata patch?


https://github.com/openwrt/openwrt/blob/master/target/linux/generic/pending-4.19/834-ledtrig-libata.patch

It's about creating a led trigger for each SATA port and it would be 
nice to have upstream too.


-Alberto

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

Re: [OpenWrt-Devel] [PATCH RFC] ath79: add support for the ar7240 version of the ubiquiti bullet

2020-02-27 Thread Russell Senior

On Wed, Feb 26, 2020 at 5:19 AM Adrian Schmutzler 
wrote:

> Hi,
>
> > -Original Message-
> > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
> > Behalf Of Russell Senior
> > Sent: Mittwoch, 26. Februar 2020 11:20
> > To: openwrt-devel@lists.openwrt.org
> > Subject: [OpenWrt-Devel] [PATCH RFC] ath79: add support for the ar7240
> version
> > of the ubiquiti bullet
> >
> >
> > The Ubiquiti Bullet M2HP come in two flavors, based on ar7240 and
> > ar7241. Both are supported by ar71xx, despite the different SoCs. The
> > ath79 target, however, currently supports only the ar7241. The ar7240
> > version apparently has a differently wired ethernet interface and the
> > ar7241-based image comes up on the ar7240-based versions without a
> > working ethernet interface.
> >
> > This is an attempt to support both flavors of ubnt-bullet-m,
> > separately. Some of the choices I made may be considered dubious and/or
> > harmful.
>
> Interesting. Do you have any indications whether this will also affect the
> Loco
> M and Picostation XM devices?
>

I have some Loco's deployed (all of them are AR7241) but no picostations,
so I don't know about the latter.

>
> What's the base for the v0/v1 distinction? Is that visible to the user
> somehow?
> I fear that meaningful naming will be the biggest problem here...
>

v0 and v1 mostly come from the need to distinguish between them. You could
think of the digit as the least significant digit of the SoC. We could make
them -7240 and -7241 instead of -v0 and -v1 to be slightly clearer what the
names mean, but that seemed ugly. And, no, as far as I know, the SoC is not
indicated on the exterior of the device at all. The user will have to
figure out the right version to use somehow.

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

Re: [OpenWrt-Devel] [PATCH] kirkwood: convert DTS patches into plain DTS files

[OpenWrt-Devel] 4k sectors in ath79's SPI NOR for MikroTik devices

[OpenWrt-Devel] [PATCH 2/2] kirkwood: switch to kernel 4.19

[OpenWrt-Devel] [PATCH 1/2] kirkwood: fix switch DTS node for EA4500 and EA3500

Re: [OpenWrt-Devel] [PATCH v2] ramips: add TRENDnet TEW-810DR support

[OpenWrt-Devel] [PATCH 1/2] ramips: fix partition offset for D-Link DIR-810L

[OpenWrt-Devel] [PATCH 2/2] ramips: fix and tidy up DTS for D-Link DIR-810L

Re: [OpenWrt-Devel] [PATCH v2] ramips: add TRENDnet TEW-810DR support

Re: [OpenWrt-Devel] [PATCH RFC] ath79: add support for the ar7240 version of the ubiquiti bullet

Re: [OpenWrt-Devel] [PATCH v2] ramips: add TRENDnet TEW-810DR support

Re: [OpenWrt-Devel] ipq40xx: QCE/crypto fixes & enhancements (PR #2518)

Re: [OpenWrt-Devel] [PATCH RFC] ath79: add support for the ar7240 version of the ubiquiti bullet

Re: [OpenWrt-Devel] [PATCH] kirkwood: convert DTS patches into plain DTS files

Re: [OpenWrt-Devel] [PATCH] kirkwood: convert DTS patches into plain DTS files

Re: [OpenWrt-Devel] [PATCH RFC] ath79: add support for the ar7240 version of the ubiquiti bullet

15 matches

Site Navigation

Mail list logo

Footer information