Re: [PATCH] scripts: create kernel configuration upgrade script

[Stijn Segers]

Hi Elliott,

Op zondag 3 maart 2024 om 15:24:50 -08:00:00 schreef Elliott Mitchell 
:

Date: Tue, 6 Feb 2024 17:16:41 -0800

Create a script for automating kernel version changes.  This
generates a pair of commits which cause history to remain attached to
all versioned configuration files.

Crucially this makes `git blame` work without needing
--find-copies-harder, which is too slow for routine use.  This also
updates *everything*, which greatly simplifies rebasing patches
which effect multiple devices.

Credit to Christian Marangi who knew of the technique:


Signed-off-by: Elliott Mitchell 



Is there a way to bump a specific target to a new kernel with your 
script? It doesn't look like it, but I might be mistaken. Would it be a 
lot of work to integrate that? With the shell equivalent being merged, 
I can understand any reluctance to adding this functionality, but it's 
worth asking.


Thanks

Stijn



---
v3:
Dust off knowledge of PerlOO.  Confine the fast-importer interface
to an object.

Better layer the lowest I/O layer.  If fast-import grows a \0 command
separation mode, we should be mostly ready (issue will be the commit
message).

Switch to SPDX.  Try to match what the other scripts have.

I was kind of hoping for more review activity, the near-silence is
almost deafening.  Using a script to handle this job seems best.  I
feel what this script produces is rather easier for most developers
to handle.

v2:
Major tweaking.  No longer try to do `git merge --ff-only `,
but instead advise user to do so.

Add usage message.

Add statement about strategy.

Adjust commit messages.  Add advice to run `git bisect skip` if
someone ends up on that commit.
---
 scripts/kernel_upgrade.pl | 280 
++

 1 file changed, 280 insertions(+)
 create mode 100755 scripts/kernel_upgrade.pl

diff --git a/scripts/kernel_upgrade.pl b/scripts/kernel_upgrade.pl
new file mode 100755
index 00..c2e5fb6078
--- /dev/null
+++ b/scripts/kernel_upgrade.pl
@@ -0,0 +1,280 @@
+#!/usr/bin/env perl
+#
+# SPDX-License-Identifier: GPL-3.0-or-later#
+#  #
+# Copyright (C) 2024 Elliott Mitchell  #
+#
+
+use warnings;
+use strict;
+
+#
+# I'm not certain the technique originated here, but this comes from:
+# 
+#
+# Problem is copying a file in git causes the new file to be created
+# without any history.  Files can move around without losing their
+# history, but that only leaves the history on the new location.
+#
+# As such this can be solved with two commits.  The first commit 
moves

+# files from their old name to their new name.  The second merges the
+# original commit with the rename commit.  The merge commit then has
+# files in both locations with the full history.
+#
+#
+# Note, git handles discarded data by garbage collection.  When doing
+# development on this script, beware this script is an excellent
+# garbage generator.  Frequent use of `git gc` and `git prune` may be
+# needed.
+#
+
+
+sub gethead()
+{
+   open(my $fd, '-|', 'git', 'rev-parse', 'HEAD');
+   $_=<$fd>;
+   chop;
+   return $_;
+}
+
+sub getlist($$)
+{
+   my ($target, $from)=@_;
+   my $ret=[];
+
+   local $/="\0";
+	open(my $fd, '-| :raw :bytes', 'git', 'ls-tree', '-trz', 
'--full-name',
+'--name-only', 'HEAD', '--', $target)||die("failed to read git 
tree");

+
+   while(<$fd>) {
+   chop($_);
+   push(@$ret, substr($_, 0, -length($from)))
+if(substr($_, -length($from)) eq $from);
+   }
+
+   @$ret=sort({length($b)-length($a)} @$ret);
+
+   return $ret;
+}
+
+{ # start of interface to git fast-import
+package GitImporter;
+
+# git fast-import's protocol uses *linefeeds*
+local $/="\n";
+
+sub new()
+{
+   my $class=shift;
+   my $self={};
+   my @child;
+   (pipe($child[0], $self->{out})&($self->{in}, $child[1])) ||
+die("pipe() failed");
+   binmode($self->{out});
+   binmode($self->{in});
+
+   $self->{pid}=fork();
+   if($self->{pid}==0) {
+   close($self->{out});
+   close($self->{in});
+
+   open(STDIN, '<&', $child[0]);
+   close($child[0]);
+
+   open(STDOUT, '>&', $child[1]);
+   close($child[1]);
+
+   exec('git', 'fast-import', '--done');
+   die('exec() of git failed');
+   } elsif(!$self->{pid}) {
+   die('fork() failed');
+   }
+   close($child[0]);
+   close($child[1]);
+   $self->{out}->autoflush(1);
+
+   return bless($self, $class);
+}
+
+sub send($)
+{
+   my $self=shift;
+  

Re: [PATCH] realtek: fix zyxel-vers usage for XGS1250-12

[Stijn Segers]

Hi Sander,

Op zondag 4 februari 2024 om 13:35:48 +01:00:00 schreef Sander Vanheule 
:

Hi Stijn,

On Sun, 2024-02-04 at 13:20 +0100, Stijn Segers wrote:

 Commit daefc646e6d fixed a shell expansion issue with
 zyxel-vers usage. Commit 045baca10b1 took care of this


checkpatch.pl was complaining about the format of these references, 
so I amended that.



Sorry, I'll try to remember running that next time.




 for the rtl838x and rtl839x subtargets, but the single
 device officially supported in rtl930x - the XGS1250-12 -
 was overlooked. This commit updates the XGS1250-12
 build recipe as well.

 Signed-off-by: Stijn Segers 
 ---
  target/linux/realtek/image/rtl930x.mk | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)


Thanks! Merged on main and backported to 23.05.


Thanks!



Best,
Sander




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

[PATCH] realtek: fix zyxel-vers usage for XGS1250-12

[Stijn Segers]

Commit daefc646e6d fixed a shell expansion issue with
zyxel-vers usage. Commit 045baca10b1 took care of this
for the rtl838x and rtl839x subtargets, but the single
device officially supported in rtl930x - the XGS1250-12 -
was overlooked. This commit updates the XGS1250-12
build recipe as well.

Signed-off-by: Stijn Segers 
---
 target/linux/realtek/image/rtl930x.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/realtek/image/rtl930x.mk 
b/target/linux/realtek/image/rtl930x.mk
index f55c5c002b..891a18c517 100644
--- a/target/linux/realtek/image/rtl930x.mk
+++ b/target/linux/realtek/image/rtl930x.mk
@@ -11,7 +11,7 @@ define Device/zyxel_xgs1250-12
kernel-bin | \
append-dtb | \
gzip | \
-   zyxel-vers (ZYXEL_VERS) | \
+   zyxel-vers | \
uImage gzip
 endef
 TARGET_DEVICES += zyxel_xgs1250-12
-- 
2.43.0


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

Re: [VOTE] New member proposal: Robimarko (Robert Marko)

[Stijn Segers]

Hi,

Op dinsdag 30 januari 2024 om 19:15:54 +01:00:00 schreef Christian 
Marangi (Ansuel) :

Robert is active in OpenWrt since 2017 and with some recent stats, he
has more than 310 commits merged in OpenWrt.
He also have uncounted Reviewed-by tag on various PR and merged 
commits

and generally helps in everything related to IPQ (ipq806x, ipq40xx and
ipq807x) and some mvebu targets.

He did the conversion of ipq40xx target to DSA and made possible the
introduction of the ipq807x target by sorting all the QSDK downstream
patch and pushing them upstream.

With his help, also the ipq60xx is very close on getting merged and
actually used permitting support of even more device for OpenWrt.

Also he is almost always reachable on IRC openwrt-devel and never had
a problem in coordinating and collaborating with him.

I think Robert is a good addition to our team and would massively help
me (Ansuel) in maintaining each IPQ target and review all the related
PR on github and patchwork.
I would like to add Robert to the OpenWrt committers team.

The vote shall be concluded within 14 days. (13/02/2024)



I have no say/vote in this, but it would be a great addition to the 
team and well-deserved recognition for Robert.


So let's push that vote through B-)

Stijn



___
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: [PATCH] [23.05 / firmware-utils] tplink-safeloader: bump EAP615-Wall compat_level

[Stijn Segers]

Hi Sander,

Op zondag 7 januari 2024 om 12:18:51 +01:00:00 schreef Sander Vanheule 
:

On Sat, 2024-01-06 at 20:14 +0100, Stijn Segers wrote:

 Newer EAP615-Walls come with more recent firmware that requires a
 higher soft_ver_compat_level. Bump ours from 1 to 2 to keep in step.
 Tested on a newer EA615-Wall by grauheier - see forum topic:
 https://forum.openwrt.org/t/173424/13.

 Tested-by: Danny Scherer 
 Signed-off-by: Stijn Segers 
 (cherry picked from commit d87b6c4b6423201e595459840f51d0dced04a4eb)


Thanks! Applied to firmware-utils/openwrt-23.05.

I'll bump the firmware-utils tool in openwrt-23.05 as well. The 
firmware-utils package
(for on-target use) is tracking the firmware-utils/master branch, so 
I won't update that

one.


Thanks!

Stijn




Best,
Sander






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

[PATCH] [23.05 / firmware-utils] tplink-safeloader: bump EAP615-Wall compat_level

[Stijn Segers]

Newer EAP615-Walls come with more recent firmware that requires a
higher soft_ver_compat_level. Bump ours from 1 to 2 to keep in step.
Tested on a newer EA615-Wall by grauheier - see forum topic:
https://forum.openwrt.org/t/173424/13.

Tested-by: Danny Scherer 
Signed-off-by: Stijn Segers 
(cherry picked from commit d87b6c4b6423201e595459840f51d0dced04a4eb)
---
 src/tplink-safeloader.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/tplink-safeloader.c b/src/tplink-safeloader.c
index 53a42f7..5661e6f 100644
--- a/src/tplink-safeloader.c
+++ b/src/tplink-safeloader.c
@@ -2158,7 +2158,7 @@ static struct device_info boards[] = {
{
.id = "EAP615-WALL-V1",
.soft_ver = SOFT_VER_DEFAULT,
-   .soft_ver_compat_level = 1,
+   .soft_ver_compat_level = 2,
.support_list =
"SupportList:\r\n"
"EAP615-Wall(TP-Link|UN|AX1800-D):1.0\r\n"
-- 
2.39.2


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

Re: [PATCH] firmware-utils: bump compat_level for EAP615-Wall

[Stijn Segers]

Thanks!

Stijn

Op donderdag 23 november 2023 om 19:16:43 +01:00:00 schreef Sander 
Vanheule :

Hi Stijn,

On Wed, 2023-11-22 at 18:39 +0100, Stijn Segers wrote:

 Newer EAP615-Walls come with more recent firmware that requires a
 higher soft_ver_compat_level. Bump ours from 1 to 2 to keep in step.
 Tested on a newer EA615-Wall by grauheier - see forum topic:
 https://forum.openwrt.org/t/173424/13.

 Tested-by: Danny Scherer 
 Signed-off-by: Stijn Segers 
 ---


Thanks for the patch! Applied to firmware-utils with one minor change.

I've updated the title to
tplink-safeloader: bump EAP615-Wall compat_level

so it's in line with other commits on the firmware-utils repository.

Best,
Sander

___
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

[PATCH] firmware-utils: bump compat_level for EAP615-Wall

[Stijn Segers]

Newer EAP615-Walls come with more recent firmware that requires a
higher soft_ver_compat_level. Bump ours from 1 to 2 to keep in step.
Tested on a newer EA615-Wall by grauheier - see forum topic:
https://forum.openwrt.org/t/173424/13.

Tested-by: Danny Scherer 
Signed-off-by: Stijn Segers 
---
 src/tplink-safeloader.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/tplink-safeloader.c b/src/tplink-safeloader.c
index 994aed5..695550f 100644
--- a/src/tplink-safeloader.c
+++ b/src/tplink-safeloader.c
@@ -2160,7 +2160,7 @@ static struct device_info boards[] = {
{
.id = "EAP615-WALL-V1",
.soft_ver = SOFT_VER_DEFAULT,
-   .soft_ver_compat_level = 1,
+   .soft_ver_compat_level = 2,
.support_list =
"SupportList:\r\n"
"EAP615-Wall(TP-Link|UN|AX1800-D):1.0\r\n"
-- 
2.39.2


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

Re: Mark lantiq and omap as source only

[Stijn Segers]

Hi,

Robert Marko  schreef op 3 mei 2023 11:21:32 CEST:
>On Wed, 3 May 2023 at 11:08, Nick  wrote:
>>
>> I would also love to see a release. It is now already delayed more than
>> a month [0] (actual branching should be happening end of march).
>> However, I don't have a strong opinion on this. It's sad that lantiq
>> targets could be dropped. I will also try to fetch me some lantiq device
>> from somewhere to support fixing the fdb issues and re-adding it back to
>> 23.X or fixing it before the branch.
>
>I would also really like a new release to branch off sooner rather than later,
>there has been plenty of time for all targets to stabilize on 5.15.

I fully agree. Seems source-only is the jolt that omap and lantiq need (I know 
the latter is a popular target).

Lots of people pining for 6.1 support in main etc, so let's branch that baby so 
we can move on.

Stijn

>
>Regards,
>Robert
>
>>
>> If you branch soon, you could probably also give a talk about the new
>> OpenWrt release at Battlemesh v15. ;)
>>
>> Bests
>> Nick
>>
>> [0] - https://openwrt.org/meetings/20230124
>>
>> On 5/1/23 18:01, Paul Spooren wrote:
>> > Hi all,
>> >
>> > I haven’t seen much progress happening regarding bringing the targets 
>> > lantiq or omap to Kernel 5.15. That fact is currently the last blocker for 
>> > branching another release.
>> >
>> > Instead of postponing another release I’d like to mark both targets as 
>> > source-only and do the 23.05 branch, starting with a RC0. If either of the 
>> > two targets are fixed within the RC phase, they should be re-added, as 
>> > discussed during the last meeting.
>> >
>> > I’d value your feedback.
>> >
>> > Sunshine,
>> > Paul
>> > ___
>> > openwrt-devel mailing list
>> > openwrt-devel@lists.openwrt.org
>> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>>
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
>___
>openwrt-devel mailing list
>openwrt-devel@lists.openwrt.org
>https://lists.openwrt.org/mailman/listinfo/openwrt-devel

-- 
Verstuurd vanaf mijn Android apparaat met K-9 Mail. Excuseer mijn beknoptheid.

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

Re: snapshots mvebu/cortexa9 possible regression in initramfs boot after acd8e94d20

[Stijn Segers]

Hi Petr,

"Petr Štetiar"  schreef op 6 februari 2023 11:26:35 CET:
>Hi,
>
>I've just noticed, that Omnia fails to boot latest initramfs snapshots[1]:
>
>  ## Loading kernel from FIT Image at 0100 ...
> Using 'config-1' configuration
> Trying 'kernel-1' kernel subimage
>   Description:  ARM OpenWrt Linux-5.15.91
>   ...snip...
> Verifying Hash Integrity ... crc32+ sha1+ OK
>  ## Loading fdt from FIT Image at 0100 ...
> Using 'config-1' configuration
> Trying 'fdt-1' fdt subimage
>   Description:  ARM OpenWrt cznic_turris-omnia device tree blob
>   ...snip...
> Verifying Hash Integrity ... crc32+ sha1+ OK
>   Booting using the fdt blob at 0x1543900
>   Uncompressing Kernel Image
>   Loading Device Tree to 0fff8000, end 0dbe ... OK
>
>  Starting kernel ...
>
>acd8e94d20 seems to be the last working revision[2], so 5.15.90 booted fine,
>5.15.91 didn't, so maybe thats the culprit?


FWIW, a backported 5.15.91 boots fine here on a WRT1200AC with 22.03.

Cheers

Stijn

>
>1. 
>https://gitlab.com/ynezz/openwrt-device-runtime-testing/-/jobs/3718348826/artifacts/external_file/console_turris-omnia-initramfs.txt
>2. 
>https://gitlab.com/ynezz/openwrt-device-runtime-testing/-/jobs/3714932743#L66
>
>
>Cheers,
>
>Petr
>
>___
>openwrt-devel mailing list
>openwrt-devel@lists.openwrt.org
>https://lists.openwrt.org/mailman/listinfo/openwrt-devel

-- 
Verstuurd vanaf mijn Android apparaat met K-9 Mail. Excuseer mijn beknoptheid.

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

Re: LAN bridge is not working with 5.15.80 [Was: Re: [PATCH v2] mvebu: switch default kernel to 5.15]

[Stijn Segers]

Hi Petr,

Op zaterdag 3 december 2022 om 11:43:32 +01:00:00 schreef Petr Štetiar 
:

Stijn Segers  [2022-12-02 13:36:20]:

Hi,


 * cortexa9 (Turris Omnia - 03f41b1eb2f15ab06d5800274be6a67c64e2a629)


that is interesting, is the latest snapshot working for you?



That was taken from Rui's commit adding 5.15 as a testing kernel for 
mvebu.


Cheers

Stijn




I got notified this morning, that Turris Omnia CI job fails[1] as the 
CI DUT
bringup machinery is unable to confirm[2], that DUT's LAN network is 
available

after 60 seconds.

That availability check is simply doing following for 60 seconds and 
then gives

up:

  $ ifstatus lan | jsonfilter -qe "@.up"

It seems, that indeed `br-lan` is broken:

root@OpenWrt:/# ifstatus lan
{
"up": false,
"pending": false,
"available": false,
"autostart": true,
"dynamic": false,
"proto": "static",
"device": "br-lan",
"data": {

},
"errors": [
{
"subsystem": "interface",
"code": "NO_DEVICE"
}
]
}

More details from the board:

root@OpenWrt:/# ubus call system board
{
"kernel": "5.15.80",
"hostname": "OpenWrt",
"system": "ARMv7 Processor rev 1 (v7l)",
"model": "Turris Omnia",
"board_name": "cznic,turris-omnia",
"rootfs_type": "initramfs",
"release": {
"distribution": "OpenWrt",
"version": "SNAPSHOT",
"revision": "r21380-5429411f73",
"target": "mvebu/cortexa9",
"description": "OpenWrt SNAPSHOT r21380-5429411f73"
}
}

root@OpenWrt:/# cat /etc/config/network

config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'

config globals 'globals'
option ula_prefix 'fdd1:d3b1:e703::/48'

config device
option name 'br-lan'
option type 'bridge'
list ports 'lan0'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'

config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'

config interface 'wan'
option device 'eth2'
option proto 'dhcp'

config interface 'wan6'
option device 'eth2'
option proto 'dhcpv6'

dmesg is visible in console_turris-omnia-initramfs.txt[2]. It seems 
really

like 5.15 regression as:

 21.02 snapshot (5.4.225) 
https://gitlab.com/ynezz/openwrt-device-runtime-testing/-/jobs/3418109997
 22.03 snapshot (5.10.156) 
https://gitlab.com/ynezz/openwrt-device-runtime-testing/-/jobs/341811


Passed the tests fine this morning. Re-run of the job failed as well, 
so it

should be reproducible issue:

 
https://gitlab.com/ynezz/openwrt-device-runtime-testing/-/jobs/3418110003



1. 
https://gitlab.com/ynezz/openwrt-device-runtime-testing/-/jobs/3418152314
2. 
https://gitlab.com/ynezz/openwrt-device-runtime-testing/-/jobs/3418152314/artifacts/external_file/console_turris-omnia-initramfs.txt



Cheers,

Petr

___
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

[PATCH v2] mvebu: switch default kernel to 5.15

[Stijn Segers]

In light of https://github.com/openwrt/openwrt/issues/11077, switch mvebu
to 5.15 which has been the testing kernel on this target since April - over
half a year.

Run-tested on the following subtargets:
* cortexa9 (Turris Omnia - 03f41b1eb2f15ab06d5800274be6a67c64e2a629)
* cortexa72 (MikroTik RB5009UG+S+IN)

Signed-off-by: Stijn Segers 
---
 target/linux/mvebu/Makefile | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/target/linux/mvebu/Makefile b/target/linux/mvebu/Makefile
index 6a1e0f63f705..2971f3fcaf50 100644
--- a/target/linux/mvebu/Makefile
+++ b/target/linux/mvebu/Makefile
@@ -9,8 +9,7 @@ BOARDNAME:=Marvell EBU Armada
 FEATURES:=fpu usb pci pcie gpio nand squashfs ramdisk boot-part rootfs-part 
legacy-sdcard targz
 SUBTARGETS:=cortexa9 cortexa53 cortexa72
 
-KERNEL_PATCHVER:=5.10
-KERNEL_TESTING_PATCHVER:=5.15
+KERNEL_PATCHVER:=5.15
 
 include $(INCLUDE_DIR)/target.mk
 

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

[PATCH] mvebu: switch default kernel to 5.15

[Stijn Segers]

From: Borromini 

In light of https://github.com/openwrt/openwrt/issues/11077, switch mvebu
to 5.15 which has been the testing kernel on this target since April - over
half a year.

Run-tested on the following subtargets:
* cortexa9 (Turris Omnia - 03f41b1eb2f15ab06d5800274be6a67c64e2a629)
* cortexa72 (MikroTik RB5009UG+S+IN)

Signed-off-by: Stijn Segers 
---
 target/linux/mvebu/Makefile | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/target/linux/mvebu/Makefile b/target/linux/mvebu/Makefile
index 6a1e0f63f705..2971f3fcaf50 100644
--- a/target/linux/mvebu/Makefile
+++ b/target/linux/mvebu/Makefile
@@ -9,8 +9,7 @@ BOARDNAME:=Marvell EBU Armada
 FEATURES:=fpu usb pci pcie gpio nand squashfs ramdisk boot-part rootfs-part 
legacy-sdcard targz
 SUBTARGETS:=cortexa9 cortexa53 cortexa72
 
-KERNEL_PATCHVER:=5.10
-KERNEL_TESTING_PATCHVER:=5.15
+KERNEL_PATCHVER:=5.15
 
 include $(INCLUDE_DIR)/target.mk
 

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

Re: [PATCH] ramips: use Sercomm parser for R6800 and clones

[Stijn Segers]

Hi,

Op zondag 24 juli 2022 om 13:39:20 +02:00:00 schreef Stijn Segers 
:
Use the bad block parser introduced in 77692d6112 for the NETGEAR 
R6800
and its clones: R6700 v2, R6900 v2, R7200 and R7450. Tested on a 
R6800.


Signed-off-by: Stijn Segers 



Should have put this in the patch message probably, but I wanted to 
point out I have no bad blocks AFAIK on my R6800 (so I can't testify as 
to the functionality). I can confirm the device still works as before 
though.


I'm not sure how eager people are to backport the bad block parser to 
22.03 still at this stage, along with this patch. But it would be neat.


Cheers

Stijn


---
 target/linux/ramips/dts/mt7621_netgear_sercomm_bzv.dtsi | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/target/linux/ramips/dts/mt7621_netgear_sercomm_bzv.dtsi 
b/target/linux/ramips/dts/mt7621_netgear_sercomm_bzv.dtsi

index 2be3f87869..87b4872d33 100644
--- a/target/linux/ramips/dts/mt7621_netgear_sercomm_bzv.dtsi
+++ b/target/linux/ramips/dts/mt7621_netgear_sercomm_bzv.dtsi
@@ -215,47 +215,54 @@
status = "okay";

partitions {
-   compatible = "fixed-partitions";
+   compatible = "sercomm,sc-partitions", "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;

partition@0 {
label = "u-boot";
reg = <0x0 0x10>;
+   sercomm,scpart-id = <0>;
read-only;
};

partition@10 {
label = "SC PART_MAP";
reg = <0x10 0x10>;
+   sercomm,scpart-id = <1>;
read-only;
};

partition@20 {
label = "kernel";
reg = <0x20 0x40>;
+   sercomm,scpart-id = <2>;
};

partition@60 {
label = "ubi";
reg = <0x60 0x280>;
+   sercomm,scpart-id = <3>;
};

partition@2e0 {
label = "reserved0";
reg = <0x2e0 0x180>;
+   sercomm,scpart-id = <4>;
read-only;
};

factory: partition@460 {
label = "factory";
reg = <0x460 0x20>;
+   sercomm,scpart-id = <5>;
read-only;
};

partition@480 {
label = "reserved1";
reg = <0x480 0x380>;
+   sercomm,scpart-id = <6>;
read-only;
};
};
--
2.36.1


___
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

[PATCH] ramips: use Sercomm parser for R6800 and clones

[Stijn Segers]

Use the bad block parser introduced in 77692d6112 for the NETGEAR R6800
and its clones: R6700 v2, R6900 v2, R7200 and R7450. Tested on a R6800.

Signed-off-by: Stijn Segers 
---
 target/linux/ramips/dts/mt7621_netgear_sercomm_bzv.dtsi | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/target/linux/ramips/dts/mt7621_netgear_sercomm_bzv.dtsi 
b/target/linux/ramips/dts/mt7621_netgear_sercomm_bzv.dtsi
index 2be3f87869..87b4872d33 100644
--- a/target/linux/ramips/dts/mt7621_netgear_sercomm_bzv.dtsi
+++ b/target/linux/ramips/dts/mt7621_netgear_sercomm_bzv.dtsi
@@ -215,47 +215,54 @@
status = "okay";
 
partitions {
-   compatible = "fixed-partitions";
+   compatible = "sercomm,sc-partitions", "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;
 
partition@0 {
label = "u-boot";
reg = <0x0 0x10>;
+   sercomm,scpart-id = <0>;
read-only;
};
 
partition@10 {
label = "SC PART_MAP";
reg = <0x10 0x10>;
+   sercomm,scpart-id = <1>;
read-only;
};
 
partition@20 {
label = "kernel";
reg = <0x20 0x40>;
+   sercomm,scpart-id = <2>;
};
 
partition@60 {
label = "ubi";
reg = <0x60 0x280>;
+   sercomm,scpart-id = <3>;
};
 
partition@2e0 {
label = "reserved0";
reg = <0x2e0 0x180>;
+   sercomm,scpart-id = <4>;
read-only;
};
 
factory: partition@460 {
label = "factory";
reg = <0x460 0x20>;
+   sercomm,scpart-id = <5>;
read-only;
};
 
partition@480 {
label = "reserved1";
reg = <0x480 0x380>;
+   sercomm,scpart-id = <6>;
read-only;
};
};
-- 
2.36.1


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

RE: [PATCH] x86/c3000: Add Intel SoC C3000 series

[Stijn Segers]

Hi,

"Lu, JialeX"  schreef op 24 juni 2022 12:11:40 CEST:
>Hi Rui,
>  1.   X64 is too broad to cover all platform varieties.
>2. Intel C3000 is a Network SoC, with integration of QAT (QuickAssist 
>engine for crypto & compression) and NICs in addition to x86. More 
>expandability with richer I/O. 
>3. At device level, C3000 h/w design and ODM/OEM ecosystem are different 
>from generic x86 platform like Core and Celeron. 
>4. C3000 support team is fully committed to enable technology innovation 
>around OpenWRT ecosystem.

That sounds awesome. Does this full commitment mean Intel will be contributing 
resources, or donating to compensate for the added maintenance burden?

Asking for a friend.

Cheers

Stijn 

>5.   We want to keep some C3000 features on the subtarget. Some X86 
>openwrt is  Soft-routing. We don't want our changes to affect these 
>Soft-routing. 
>
>
>
>-Original Message-
>From: Rui Salvaterra  
>Sent: Friday, June 24, 2022 6:07 PM
>To: Lu, JialeX 
>Cc: openwrt-devel@lists.openwrt.org; Yang, Tao Y ; 
>Zhang, Yang6 
>Subject: Re: [PATCH] x86/c3000: Add Intel SoC C3000 series
>
>Hi, jialelux,
>
>On Fri, 24 Jun 2022 at 09:50,  wrote:
>>
>
>[snipped]
>
>> +SUBTARGETS:=generic legacy geode 64 c3000
>
>[snipped]
>
>The Atom C3000 is a x86-64 CPU. What makes it so special as to require a 
>dedicated subtarget?
>
>Cheers,
>Rui
>___
>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: [PATCH] realtek: make Netgear GS108T v3 u-boot env partition writable

[Stijn Segers]

Hi,

Op vrijdag 17 juni 2022 om 09:54:56 +02:00:00 schreef Bjørn Mork 
:

Sander Vanheule  writes:

 On Thu, 2022-06-16 at 22:28 +0200, Stijn Segers wrote:

 Signed-off-by: Stijn Segers 


 You need to add at least one line describing why this change is 
needed; now you
 only have a commit title. Just mentioning that you want to be able 
to modify the

 u-boot-env from userspace should be enough.


Could even use the real usecase example from the forum as body. Then 
we

have that documented here as well.


Bjørn


Thank you both, clearly my gitiquette is not up to snuff :^).

Sent in a v2, also changed the title since it applies to a shared DTSI.

Cheers

Stijn








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

[PATCH v2] realtek: make Netgear GS1xx u-boot env partition writable

[Stijn Segers]

Make the u-boot environment partition for the NETGEAR
GS108T v3 and GS110TPP writable (they share a DTS), so
the values can be manipulated from userspace.

See https://forum.openwrt.org/t/57875/1567 for a real
world example.

Signed-off-by: Stijn Segers 
---
 target/linux/realtek/dts-5.10/rtl8380_netgear_gigabit_1xx.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/target/linux/realtek/dts-5.10/rtl8380_netgear_gigabit_1xx.dtsi 
b/target/linux/realtek/dts-5.10/rtl8380_netgear_gigabit_1xx.dtsi
index 7eccfcb5a2..fd44543bb4 100644
--- a/target/linux/realtek/dts-5.10/rtl8380_netgear_gigabit_1xx.dtsi
+++ b/target/linux/realtek/dts-5.10/rtl8380_netgear_gigabit_1xx.dtsi
@@ -24,7 +24,6 @@
partition@e {
label = "u-boot-env";
reg = <0x00e 0x001>;
-   read-only;
};
 
partition@f {
-- 
2.36.1


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

[PATCH] realtek: make Netgear GS108T v3 u-boot env partition writable

[Stijn Segers]

Signed-off-by: Stijn Segers 
---
 target/linux/realtek/dts-5.10/rtl8380_netgear_gigabit_1xx.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/target/linux/realtek/dts-5.10/rtl8380_netgear_gigabit_1xx.dtsi 
b/target/linux/realtek/dts-5.10/rtl8380_netgear_gigabit_1xx.dtsi
index 7eccfcb5a2..fd44543bb4 100644
--- a/target/linux/realtek/dts-5.10/rtl8380_netgear_gigabit_1xx.dtsi
+++ b/target/linux/realtek/dts-5.10/rtl8380_netgear_gigabit_1xx.dtsi
@@ -24,7 +24,6 @@
partition@e {
label = "u-boot-env";
reg = <0x00e 0x001>;
-   read-only;
};
 
partition@f {
-- 
2.30.2


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

Re: [PATCH v3] ath79: D-Link DAP-2680: select QCA9984 firmware

[Stijn Segers]

Hi Sander,

Op vrijdag 27 mei 2022 om 14:18:19 +02:00:00 schreef Sander Vanheule 
:

Hi Stijn, Allesandro,

On Sat, 2022-05-21 at 22:59 +0200, Stijn Segers wrote:

 The DAP-2680 has a QCA9984 radio [1], but the commit adding support
 mistakenly adds the QCA99x0 firmware package. See forum topic [2].

 [1] https://wikidevi.wi-cat.ru/D-Link_DAP-2680_rev_A1
 [2] 
https://forum.openwrt.org/t/missing-5ghz-radio-on-dlink-dap-2680/


This link doesn't work anymore, since the thread title has been 
(auto-)modified to "[SOLVED] ...".

The shortest working link is https://forum.openwrt.org/t/128025



 Fixes: 5b58710fad21 ("ath79: add support for D-Link DAP-2680 A1")

 Signed-off-by: Stijn Segers 
 Tested-by: Alessandro Fellin 
 ---

 v2: Fix typo (QCA998x -> QCA99x0)
 v3: Proper 'Fixes' tag (thanks svanheule)

  target/linux/ath79/image/generic.mk | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/target/linux/ath79/image/generic.mk 
b/target/linux/ath79/image/generic.mk

 index 4f36a08ff4..9729eb7555 100644
 --- a/target/linux/ath79/image/generic.mk
 +++ b/target/linux/ath79/image/generic.mk
 @@ -896,7 +896,7 @@ define Device/dlink_dap-2680-a1
DEVICE_VENDOR := D-Link
DEVICE_MODEL := DAP-2680
DEVICE_VARIANT := A1
 -  DEVICE_PACKAGES := ath10k-firmware-qca99x0-ct kmod-ath10k-ct
 +  DEVICE_PACKAGES := ath10k-firmware-qca9984-ct kmod-ath10k-ct
IMAGE_SIZE := 15232k
DAP_SIGNATURE := wapac36_dkbs_dap2680
  endef


The caldata extraction places the calibration data in a QCA9888 
directory [1], while for
xiaomi,aiot-ac2350 (with QCA9988 radio) [2] this is placed in a 
QCA9984 directory. The ath10k-
firmware-qca9984-ct package also puts the firmware files in the 
QCA9984 directory. Does the device

actually work properly in the 5GHz band with only this change?



Alessandro owns the device, hopefully he can comment on that.



If the caldata extraction needs to be modified too, this may be a 
good opportunity to convert to the
nvmem-cells method. See for example commit 297bceeecf29 ("ath79: 
convert TP-Link Archer C7v1/2 Wifis

to nvmem-cells").


I'm afraid that's out of my league :-/

Cheers

Stijn



[1] Commit 5b58710fad21 ("ath79: add support for D-Link DAP-2680 A1")
[2] Commit 6c148116f778 ("ath79: add support for Xiaomi AIoT Router 
AC2350")


Best,
Sander




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

[PATCH v3] ath79: D-Link DAP-2680: select QCA9984 firmware

[Stijn Segers]

The DAP-2680 has a QCA9984 radio [1], but the commit adding support
mistakenly adds the QCA99x0 firmware package. See forum topic [2].

[1] https://wikidevi.wi-cat.ru/D-Link_DAP-2680_rev_A1
[2] https://forum.openwrt.org/t/missing-5ghz-radio-on-dlink-dap-2680/

Fixes: 5b58710fad21 ("ath79: add support for D-Link DAP-2680 A1")

Signed-off-by: Stijn Segers 
Tested-by: Alessandro Fellin 
---

v2: Fix typo (QCA998x -> QCA99x0)
v3: Proper 'Fixes' tag (thanks svanheule)

 target/linux/ath79/image/generic.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/ath79/image/generic.mk 
b/target/linux/ath79/image/generic.mk
index 4f36a08ff4..9729eb7555 100644
--- a/target/linux/ath79/image/generic.mk
+++ b/target/linux/ath79/image/generic.mk
@@ -896,7 +896,7 @@ define Device/dlink_dap-2680-a1
   DEVICE_VENDOR := D-Link
   DEVICE_MODEL := DAP-2680
   DEVICE_VARIANT := A1
-  DEVICE_PACKAGES := ath10k-firmware-qca99x0-ct kmod-ath10k-ct
+  DEVICE_PACKAGES := ath10k-firmware-qca9984-ct kmod-ath10k-ct
   IMAGE_SIZE := 15232k
   DAP_SIGNATURE := wapac36_dkbs_dap2680
 endef
-- 
2.30.2


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

[PATCH v2] ath79: D-Link DAP-2680: select QCA9984 firmware

[Stijn Segers]

The DAP-2680 has a QCA9984 radio [1], but the commit adding support
mistakenly adds the QCA99x0 firmware package. See forum topic [2].

Fixes 5b58710fad2137eedad874f0fe8fe22082d1edc6.

[1] https://wikidevi.wi-cat.ru/D-Link_DAP-2680_rev_A1
[2] https://forum.openwrt.org/t/missing-5ghz-radio-on-dlink-dap-2680/

Signed-off-by: Stijn Segers 
Tested-by: Alessandro Fellin 
---
 target/linux/ath79/image/generic.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/ath79/image/generic.mk 
b/target/linux/ath79/image/generic.mk
index 4f36a08ff4..9729eb7555 100644
--- a/target/linux/ath79/image/generic.mk
+++ b/target/linux/ath79/image/generic.mk
@@ -896,7 +896,7 @@ define Device/dlink_dap-2680-a1
   DEVICE_VENDOR := D-Link
   DEVICE_MODEL := DAP-2680
   DEVICE_VARIANT := A1
-  DEVICE_PACKAGES := ath10k-firmware-qca99x0-ct kmod-ath10k-ct
+  DEVICE_PACKAGES := ath10k-firmware-qca9984-ct kmod-ath10k-ct
   IMAGE_SIZE := 15232k
   DAP_SIGNATURE := wapac36_dkbs_dap2680
 endef
-- 
2.30.2


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

[PATCH] ath79: D-Link DAP-2680: select QCA9984 firmware

[Stijn Segers]

The DAP-2680 has a QCA9984 radio [1], but the commit adding support
mistakenly adds the QCA998x firmware package. See forum topic [2].

Fixes 5b58710fad2137eedad874f0fe8fe22082d1edc6.

[1] https://wikidevi.wi-cat.ru/D-Link_DAP-2680_rev_A1
[2] https://forum.openwrt.org/t/missing-5ghz-radio-on-dlink-dap-2680/

Signed-off-by: Stijn Segers 
Tested-by: Alessandro Fellin 
---
 target/linux/ath79/image/generic.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/ath79/image/generic.mk 
b/target/linux/ath79/image/generic.mk
index 4f36a08ff4..9729eb7555 100644
--- a/target/linux/ath79/image/generic.mk
+++ b/target/linux/ath79/image/generic.mk
@@ -896,7 +896,7 @@ define Device/dlink_dap-2680-a1
   DEVICE_VENDOR := D-Link
   DEVICE_MODEL := DAP-2680
   DEVICE_VARIANT := A1
-  DEVICE_PACKAGES := ath10k-firmware-qca99x0-ct kmod-ath10k-ct
+  DEVICE_PACKAGES := ath10k-firmware-qca9984-ct kmod-ath10k-ct
   IMAGE_SIZE := 15232k
   DAP_SIGNATURE := wapac36_dkbs_dap2680
 endef
-- 
2.30.2


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

Re: [PATCH] ramips: use hotplug script for EAP615-Wall MACs

[Stijn Segers]

Hi Stijn,

Op dinsdag 17 mei 2022 om 17u57 schreef Stijn Tintel 
:

Using nvmem-cells to set the MAC address for a DBDC device results in
both PHY devices using the same MAC address. This in turn will result 
in

multiple BSSes using the same BSSID, which can cause various problems.

Use the hotplug script for the EAP615-Wall instead to avoid this.

Fixes: a1b8a4d7b3ff ("ramips: support TP-Link EAP615-Wall")
Signed-off-by: Stijn Tintel 



As advertised ;-). Tested on 22.03 branch, both radios use different 
MAC now.


Tested-by: Stijn Segers 


---
 target/linux/ramips/dts/mt7621_tplink_eap615-wall-v1.dts  | 2 --
 .../mt7621/base-files/etc/hotplug.d/ieee80211/10_fix_wifi_mac | 4 


 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/target/linux/ramips/dts/mt7621_tplink_eap615-wall-v1.dts 
b/target/linux/ramips/dts/mt7621_tplink_eap615-wall-v1.dts

index a0c3912d8e..0be4af39e8 100644
--- a/target/linux/ramips/dts/mt7621_tplink_eap615-wall-v1.dts
+++ b/target/linux/ramips/dts/mt7621_tplink_eap615-wall-v1.dts
@@ -144,8 +144,6 @@
compatible = "mediatek,mt76";
reg = <0x 0 0 0 0>;
mediatek,mtd-eeprom = < 0x0>;
-   nvmem-cells = <_info_8>;
-   nvmem-cell-names = "mac-address";
};
 };

diff --git 
a/target/linux/ramips/mt7621/base-files/etc/hotplug.d/ieee80211/10_fix_wifi_mac 
b/target/linux/ramips/mt7621/base-files/etc/hotplug.d/ieee80211/10_fix_wifi_mac

index a35e9dcc28..5b12416872 100644
--- 
a/target/linux/ramips/mt7621/base-files/etc/hotplug.d/ieee80211/10_fix_wifi_mac
+++ 
b/target/linux/ramips/mt7621/base-files/etc/hotplug.d/ieee80211/10_fix_wifi_mac

@@ -90,6 +90,10 @@ case "$board" in
hw_mac_addr="$(mtd_get_mac_binary factory 0x4)"
 		[ "$PHYNBR" = "1" ] &&  macaddr_add $hw_mac_addr "0x10" > 
/sys${DEVPATH}/macaddress

;;
+   tplink,eap615-wall-v1)
+   hw_mac_addr="$(mtd_get_mac_binary product-info 0x8)"
+   macaddr_add "$hw_mac_addr" "$PHYNBR" > 
"/sys${DEVPATH}/macaddress"
+   ;;
yuncore,ax820)
[ "$PHYNBR" = "1" ] && \
 			macaddr_setbit_la "$(mtd_get_mac_binary Factory 0xe000)" > 
/sys${DEVPATH}/macaddress

--
2.35.1


___
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

[PATCH] firmware-utils: tplink-safeloader: add support for Archer A6 v2 (EU)

[Stijn Segers]

The Archer A6 v2 (EU) matches the C6 v2 (EU) and uses the same firmware ID.
See also 
https://forum.openwrt.org/t/tp-link-archer-a6-v2-0-cannot-install/119403/34.

Tested-by: Kamil Jońca 
Signed-off-by: Stijn Segers 
---
 src/tplink-safeloader.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/tplink-safeloader.c b/src/tplink-safeloader.c
index 49775e4..fa8daa8 100644
--- a/src/tplink-safeloader.c
+++ b/src/tplink-safeloader.c
@@ -1026,6 +1026,7 @@ static struct device_info boards[] = {
.vendor = "",
.support_list =
"SupportList:\r\n"
+   "{product_name:Archer 
A6,product_ver:2.0.0,special_id:4555}\r\n"
"{product_name:Archer 
C6,product_ver:2.0.0,special_id:4555}\r\n"
"{product_name:Archer 
C6,product_ver:2.0.0,special_id:5255}\r\n"
"{product_name:Archer 
C6,product_ver:2.0.0,special_id:4A50}\r\n",
-- 
2.30.2


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

Re: Pre-install MiniUPnPd on OpenWrt by default

[Stijn Segers]

Hi Sergey,

Op dinsdag 25 januari 2022 om 15u27 schreef Sergey Ponomarev 
:

Hi,

Most routers support port forwarding via UPnP IDG or/and NAT-PMP/PCP.
And many vendors use the MiniUPnPd http://miniupnp.free.fr This daemon
is kind of standard de-facto.
This is necessary for any p2p application but OpenWrt builds don't
have it pre-installed and pre-configured. While it's not so difficult
to install, this is an additional step and still something that users
must know. For example, I didn't know about it for about two years
while already using OpenWrt. For many users this makes life after
switching to OpenWrt worse than it was before because, for example,
now their gaming console works slower. Even if someone will try to
install it there is a risk to configure it incorrectly and expose WAN
to LAN forwarding.

Could you include the MiniUPnPd into OpenWrt?


Given the inherent flaws and threats the concept of UPnP poses, I don't 
think it stands a chance to be included by default. Just the fact that 
any application in your LAN can open ports and poke holes at will in 
your firewall is reason enough to *never* do that.


A lot of people in the community advise users to find out what ports 
they need to open and do that manually, keeping control over what's 
open and what not, instead of relying on an easy (but risky) protocol 
like UPnP.


Of course, that's just my 2 cents.

Cheers

Stijn




There may be few concerns:
1. The UPnP IDG protocol has a very bad reputation. See "Universal Pwn
n Play" talk.
2. The MiniUPnPd also had a security issue in 2014 when the WAN to LAN
forwarding was enabled for NAT-PMP.
3. A disk space usage: I checked on OpenWrt with WR1043N  (MIPS) and
after installing the miniupnpd and it's dependency libcap-ng the disk
size usage increased to 72Kb. The binary itself is 98565 bytes, in
contrast with uhttpd 46212 and lighttpd 221413. Maybe for Tiny builds
this may be too much.

To make it smaller and easier for a code audit we may strip the UPnP
and leave only NAT-PMP/PCP. See
https://github.com/miniupnp/miniupnp/issues/545

In July 2014 there was two discussions about IPv6 firewall policy for
direct connections:
"OpenWRT IPv6 firewall"
http://lists.openwrt.org/pipermail/openwrt-devel/2014-July/000763.html
"IPv6 firewall and Port Control Protocol"
http://lists.openwrt.org/pipermail/openwrt-devel/2014-July/000671.html

The MiniUPnPd can solve the problem at least partially.

See also: a forum discussion
https://forum.openwrt.org/t/port-control-protocol-support/114411

Regards,
Sergey

___
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: [PATCH v4 5/5] realtek: Remove _machine_restart and _machine_halt

[Stijn Segers]

Hi Sander,

Op zondag 14 november 2021 om 19u45 schreef Sander Vanheule 
:

By dropping _machine_restart, users can provide more reliable or
device-specific restart modes.

_machine_halt was already removed in commit f4b687d1f053 ("realtek: 
use

kernel defined halt"), but quietly reintroduced in commit 8faffa00cb6b
("realtek: add support for the RTL9300 timer"). Let's remove it again.



Reboot works reliably on my GS1900-8HP v1. Thanks!

Tested-by: Stijn Segers 



Signed-off-by: Sander Vanheule 
---
 .../files-5.10/arch/mips/rtl838x/setup.c  | 85 
---

 1 file changed, 85 deletions(-)

diff --git 
a/target/linux/realtek/files-5.10/arch/mips/rtl838x/setup.c 
b/target/linux/realtek/files-5.10/arch/mips/rtl838x/setup.c

index 752a85643728..55419c7b0b7a 100644
--- a/target/linux/realtek/files-5.10/arch/mips/rtl838x/setup.c
+++ b/target/linux/realtek/files-5.10/arch/mips/rtl838x/setup.c
@@ -20,7 +20,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -29,100 +28,20 @@

 extern struct rtl83xx_soc_info soc_info;

-u32 pll_reset_value;
-
-static void rtl838x_restart(char *command)
-{
-   u32 pll = sw_r32(RTL838X_PLL_CML_CTRL);
-
-   pr_info("System restart.\n");
-   pr_info("PLL control register: %x, applying reset value %x\n",
-   pll, pll_reset_value);
-
-   sw_w32(3, RTL838X_INT_RW_CTRL);
-   sw_w32(pll_reset_value, RTL838X_PLL_CML_CTRL);
-   sw_w32(0, RTL838X_INT_RW_CTRL);
-
-   /* Reset Global Control1 Register */
-   sw_w32(1, RTL838X_RST_GLB_CTRL_1);
-}
-
-static void rtl839x_restart(char *command)
-{
-	/* SoC reset vector (in flash memory): on RTL839x platform 
preferred way to reset */

-   void (*f)(void) = (void *) 0xbfc0;
-
-   pr_info("System restart.\n");
-   /* Reset SoC */
-   sw_w32(0x, RTL839X_RST_GLB_CTRL);
-   /* and call reset vector */
-   f();
-   /* If this fails, halt the CPU */
-   while
-   (1);
-}
-
-static void rtl930x_restart(char *command)
-{
-   pr_info("System restart.\n");
-   sw_w32(0x1, RTL930X_RST_GLB_CTRL_0);
-   while
-   (1);
-}
-
-static void rtl931x_restart(char *command)
-{
-   u32 v;
-
-   pr_info("System restart.\n");
-   sw_w32(1, RTL931X_RST_GLB_CTRL);
-   v = sw_r32(RTL931X_RST_GLB_CTRL);
-   sw_w32(0x101, RTL931X_RST_GLB_CTRL);
-   msleep(15);
-   sw_w32(v, RTL931X_RST_GLB_CTRL);
-   msleep(15);
-   sw_w32(0x101, RTL931X_RST_GLB_CTRL);
-}
-
-static void rtl838x_halt(void)
-{
-   pr_info("System halted.\n");
-   while
-   (1);
-}
-
 static void __init rtl838x_setup(void)
 {
-   pr_info("Registering _machine_restart\n");
-   _machine_restart = rtl838x_restart;
-   _machine_halt = rtl838x_halt;
-
-	/* This PLL value needs to be restored before a reset and will then 
be

-* preserved over a SoC reset. A wrong value prevents the SoC from
-* connecting to the SPI flash controller at boot and reading the
-* reset routine */
-   pll_reset_value = sw_r32(RTL838X_PLL_CML_CTRL);
-
/* Setup System LED. Bit 15 then allows to toggle it */
sw_w32_mask(0, 3 << 16, RTL838X_LED_GLB_CTRL);
 }

 static void __init rtl839x_setup(void)
 {
-   pr_info("Registering _machine_restart\n");
-   _machine_restart = rtl839x_restart;
-   _machine_halt = rtl838x_halt;
-
 	/* Setup System LED. Bit 14 of RTL839X_LED_GLB_CTRL then allows to 
toggle it */

sw_w32_mask(0, 3 << 15, RTL839X_LED_GLB_CTRL);
 }

 static void __init rtl930x_setup(void)
 {
-   pr_info("Registering _machine_restart\n");
-   _machine_restart = rtl930x_restart;
-   _machine_halt = rtl838x_halt;
-
if (soc_info.id == 0x9302)
sw_w32_mask(0, 3 << 13, RTL9302_LED_GLB_CTRL);
else
@@ -131,9 +50,6 @@ static void __init rtl930x_setup(void)

 static void __init rtl931x_setup(void)
 {
-   pr_info("Registering _machine_restart\n");
-   _machine_restart = rtl931x_restart;
-   _machine_halt = rtl838x_halt;
sw_w32_mask(0, 3 << 12, RTL931X_LED_GLB_CTRL);
 }

@@ -142,7 +58,6 @@ void __init plat_mem_setup(void)
void *dtb;

set_io_port_base(KSEG1);
-   _machine_restart = rtl838x_restart;

if (fw_passed_dtb) /* UHI interface */
dtb = (void *)fw_passed_dtb;
--
2.33.1


___
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

Mutt configuration options being auto-enabled by default

[Stijn Segers]

Hi Matthew,

It looks like you expanded Mutt support with commit 
19877a952d1136e134547835d335ffc771917ccc.


I just refreshed my config on master and was a bit surprised to see 
Mutt configuration options enabled by default. I haven't enabled mutt 
as a package, so I don't think these should be popping up?


I'm noticing those three options have each a 'default y', but shouldn't 
these options be exposed (and activated) only when Mutt is selected as 
a package?


@@ -4298,6 +4311,18 @@ CONFIG_PACKAGE_luci-lib-nixio_notls=y
# CONFIG_PACKAGE_msmtp-nossl is not set
# CONFIG_PACKAGE_msmtp-queue is not set
# CONFIG_PACKAGE_mutt is not set
+
+#
+# Select mutt build options
+#
+CONFIG_MUTT_POP=y
+CONFIG_MUTT_IMAP=y
+# CONFIG_MUTT_SMTP is not set
+# CONFIG_MUTT_SASL is not set
+# CONFIG_MUTT_GNUTLS is not set
+CONFIG_MUTT_OPENSSL=y
+# end of Select mutt build options
+
# CONFIG_PACKAGE_nail is not set
# CONFIG_PACKAGE_opendkim is not set
# CONFIG_PACKAGE_opendkim-tools is not set

Thanks

Stijn



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

Re: Release goals for 22.XX

[Stijn Segers]

Hi Hauke,

Op woensdag 29 september 2021 om 22u28 schreef Hauke Mehrtens 
:

Hi,

The OpenWrt 21.02 release is done and we should plan the next release.
We already talked about this in the last meeting, see 
https://openwrt.org/meetings/20210920


To monitor the current state I created this wiki page based on the 
wiki page from the previous release:

https://openwrt.org/docs/guide-developer/releases/goals/22.xx

I would like to get an overview about the "big" changes, if an 
additional board is added or something is improved we do not need to 
plan it.


I would like to get the following:

kernel 5.10:
We should get all targets to kernel 5.10. All targets which are not 
on kernel 5.10 when we branch off should get removed.


Kernel version for all targets:
Kernel 5.10 (only):
 bmips
Kernel 5.10 (5.4 still present):
 bcm27xx bcm53xx gemini ipq806x mediatek mvebu x86
Testing 5.10:
 apm821xx armvirt ath79 bcm63xx imx6 ipq40xx kirkwood lantiq malta
 mpc85xx mxs octeon octeontx oxnas ramips realtek rockchip sunxi tegra
Kernel 5.4 only:
 arc770 archs38 at91 ath25 bcm47xx bcm4908 ipq807x layerscape omap 
pistachio uml zynq



Not sure if you missed this, but there's a 5.10 for OMAP: 
https://github.com/openwrt/openwrt/pull/4539. There's a 5.10 PR for 
lantiq as well, and lantiq is in your 'Testing 5.10' list, so 
mentioning just it in case.


Cheers

Stijn



toolchain:
We already updated the toolchain in master to GCC 11.2, binutils 2.37 
and musl 1.2.2. This looks good to me. Minor version updates of musl 
libc later should be ok. gdb and glibc could also be update later if 
someone wants to do it.


mac80211:
I would like to update the mac80211 version we use to match the code 
from kernel 5.15 or whatever will be the next LTS kernel. I haven't 
started yet.


DSA:
We will migrate some more boards to DSA, the lantiq/xrx200 target is 
using DSA in master now. It looks like some boards with qca8k would 
switch. These changes should be local to one target or even board 
anyway. The infrastructure is already provided. This can continue 
without much coordination and we can see what is finished when we 
branch.


firewall4:
OpenWrt master contains firewall4 optionally which uses nftables 
instead of iptables. It uses the same configuration as firewall3, the 
old configuration should still work. Custom iptables extensions 
should also still work when we use iptables-nft which supports the 
iptables user interface and generates nftables rules, even Debian 
stable uses iptables-nft by default. Flow offloading (software and 
hardware) is supported by upstream kernel when nftables is used, we 
are currently using a patch to make it "work" with iptables too.


We have to activate it by default and deactivate firewall3.
We probably need some minor modifications to LuCi to show the current 
nftables firewall status. This is not device depended like DSA, we 
can easily test this on one device and it should work the same way on 
all others.


LuCi:
What is still needed in LuCi?


Is there anything else which is blocking, should be added or needs a 
discussion?


Hauke
___
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: [PATCH] ramips: switch to kernel 5.10

[Stijn Segers]

Hi Ilya,

Op maandag 27 september 2021 om 19u11 schreef Ilya Lipnitskiy 
:

Hi Stijn,


 >>  >all mt7620 JBOOT devices will be broken.

...

 $ grep \ KERNEL_SIZE image/mt7620.mk|wc -l
 1
That one is under "define Device/amit_jboot", searching for that 
yields:

$ git grep "\$(Device/amit_jboot)" | wc -l
8

So all JBOOT devices look covered.

Which mt76x8 device(s) is missing a KERNEL_SIZE or fails to boot with 
5.10?


The single mt76x8 device I have works, my reasoning was that maybe 
those needed further checks because most (all?) of them are small flash 
devices. That worry was triggered by the odd report of people bricking 
their device by flashing images with too big a kernel. That being said, 
that even seems to happen to beefy modern hardware like the mvebu 
platform, so... I may have been overly cautious (and worried).


By now it's clear I am not wholly familiar with the finer points, so 
I'm happy with the answers I got (and what I learned) and I'll leave it 
at that.


Thank you!

Stijn



Ilya

___
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: [PATCH] ramips: switch to kernel 5.10

[Stijn Segers]

Hi Adrian,

Op zondag 26 september 2021 om 23u45 schreef Adrian Schmutzler 
:

Hi,


 -Original Message-
 From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
 On Behalf Of Stijn Segers
 Sent: Donnerstag, 9. September 2021 14:26
 To: openwrt-devel@lists.openwrt.org; Paweł Dembicki
 ; Rui Salvaterra 
 Cc: OpenWrt Development List ; 
Adrian

 Schmutzler ; David Bauer 
 Subject: Re: [PATCH] ramips: switch to kernel 5.10

 "Paweł Dembicki"  schreef op 9 september
 2021 13:47:36 CEST:
 >czw., 9 wrz 2021 o 10:49 Rui Salvaterra  
napisał(a):

 >>
 >> Tested on mt7621 (Redmi AC2100) and running stable for several 
months.

 >>
 >
 >Hi Rui,
 >
 >Please remember, if this patch will be merged before my PR #4255 
[1],

 >all mt7620 JBOOT devices will be broken.
 >
 >The reason is simple: The 5.10 kernel will be > 2MB. My PR will 
switch

 >all mt7620 JBOOT devices to the OKLI loader.

 Would something similar need to be done for the mt76x8 subtarget?

 I just have a single one of these but I reckon they are equally 
flash-starved...


But if KERNEL_SIZE/IMAGE_SIZE is set properly there, those would just 
fail to build, so no harm could be done?



That is a valid point. I checked master:

$ grep "define Device" image/mt7620.mk|wc -l
119
$ grep \ KERNEL_SIZE image/mt7620.mk|wc -l
1
$ grep "define Device" image/mt76x8.mk|wc -l
80
$ grep \ KERNEL_SIZE image/mt76x8.mk|wc -l
0

That's not encouraging I guess :-P. And just having IMAGE_SIZE defined 
won't prevent the bootloader from choking on an oversized kernel, or am 
I wrong about that?


Cheers

Stijn



Best

Adrian



 Cheers

 Stijn

 >
 >Best Regards,
 >Pawel
 >
 >[1] https://github.com/openwrt/openwrt/pull/4255
 >
 >> Signed-off-by: Rui Salvaterra 
 >> ---
 >>  target/linux/ramips/Makefile | 3 +--
 >>  1 file changed, 1 insertion(+), 2 deletions(-)
 >>
 >> diff --git a/target/linux/ramips/Makefile
 >> b/target/linux/ramips/Makefile index d3f2d4b8fc..c9fc1aa58a 
100644

 >> --- a/target/linux/ramips/Makefile
 >> +++ b/target/linux/ramips/Makefile
 >> @@ -10,8 +10,7 @@ BOARDNAME:=MediaTek Ralink MIPS
 >>  SUBTARGETS:=mt7620 mt7621 mt76x8 rt288x rt305x rt3883
 >> FEATURES:=squashfs gpio
 >>
 >> -KERNEL_PATCHVER:=5.4
 >> -KERNEL_TESTING_PATCHVER:=5.10
 >> +KERNEL_PATCHVER:=5.10
 >>
 >>  define Target/Description
 >> Build firmware images for Ralink RT288x/RT3xxx based 
boards.

 >> --
 >> 2.33.0
 >>
 >>
 >> ___
 >> 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

 Hi,
 --
 Sent from my smartphone with K-9 Mail. Please excuse my brevity.

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

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




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

Re: [PATCH] ramips: switch to kernel 5.10

[Stijn Segers]

Hi,

Op donderdag 9 september 2021 om 9u44 schreef Rui Salvaterra 
:

Tested on mt7621 (Redmi AC2100) and running stable for several months.

Signed-off-by: Rui Salvaterra 



Tested on:
- mt7620: TP-Link Archer C2 AC750
- mt7621: Asus RT-AC57U v1
- mt76x8: TP-Link RE305 v3

Pawel raised a valid point though, and I think my similar question 
about mt76x8 deserves consideration as well.


Tested-by: Stijn Segers 


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

diff --git a/target/linux/ramips/Makefile 
b/target/linux/ramips/Makefile

index d3f2d4b8fc..c9fc1aa58a 100644
--- a/target/linux/ramips/Makefile
+++ b/target/linux/ramips/Makefile
@@ -10,8 +10,7 @@ BOARDNAME:=MediaTek Ralink MIPS
 SUBTARGETS:=mt7620 mt7621 mt76x8 rt288x rt305x rt3883
 FEATURES:=squashfs gpio

-KERNEL_PATCHVER:=5.4
-KERNEL_TESTING_PATCHVER:=5.10
+KERNEL_PATCHVER:=5.10

 define Target/Description
Build firmware images for Ralink RT288x/RT3xxx based boards.
--
2.33.0


___
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: [PATCH] ramips: switch to kernel 5.10

[Stijn Segers]

"Paweł Dembicki"  schreef op 9 september 2021 13:47:36 
CEST:
>czw., 9 wrz 2021 o 10:49 Rui Salvaterra  napisał(a):
>>
>> Tested on mt7621 (Redmi AC2100) and running stable for several months.
>>
>
>Hi Rui,
>
>Please remember, if this patch will be merged before my PR #4255 [1],
>all mt7620 JBOOT devices will be broken.
>
>The reason is simple: The 5.10 kernel will be > 2MB. My PR will switch
>all mt7620 JBOOT devices to the OKLI loader.

Would something similar need to be done for the mt76x8 subtarget?

I just have a single one of these but I reckon they are equally flash-starved...

Cheers

Stijn

>
>Best Regards,
>Pawel
>
>[1] https://github.com/openwrt/openwrt/pull/4255
>
>> Signed-off-by: Rui Salvaterra 
>> ---
>>  target/linux/ramips/Makefile | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/target/linux/ramips/Makefile b/target/linux/ramips/Makefile
>> index d3f2d4b8fc..c9fc1aa58a 100644
>> --- a/target/linux/ramips/Makefile
>> +++ b/target/linux/ramips/Makefile
>> @@ -10,8 +10,7 @@ BOARDNAME:=MediaTek Ralink MIPS
>>  SUBTARGETS:=mt7620 mt7621 mt76x8 rt288x rt305x rt3883
>>  FEATURES:=squashfs gpio
>>
>> -KERNEL_PATCHVER:=5.4
>> -KERNEL_TESTING_PATCHVER:=5.10
>> +KERNEL_PATCHVER:=5.10
>>
>>  define Target/Description
>> Build firmware images for Ralink RT288x/RT3xxx based boards.
>> --
>> 2.33.0
>>
>>
>> ___
>> 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

Hi,
-- 
Sent from my smartphone with K-9 Mail. Please excuse my brevity.

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

Re: OpenWrt 21.02 status

[Stijn Segers]

Hi Hauke

Op zondag 29 augustus 2021 om 11u53 schreef Hauke Mehrtens 
:

Hi,

We did the 21.02-rc4, but there is still a problem with flow 
offloading as this was not fixed. The other problems should be fixed 
now.


On 7/17/21 5:45 PM, Hauke Mehrtens wrote:

Currently we still have these problem:

- IPv6 broken with flow offloading (according to reports, 
potentially related to hw flow offloading)
- PPPoE allegedly broken (according to reports, not fully 
reproducible, likely related to hw flow offloading too)

   - https://bugs.openwrt.org/index.php?do=details_id=3909
   - https://bugs.openwrt.org/index.php?do=details_id=3835




I'd like to add that disabling IPv6 with PPP on 21.02 will not fully 
disable IPv6 as per jow's tip here [1], would be neat if that could be 
fixed (and backported to a .1, this is not a showstopper for 21.02 
final in any way). Just wanted to put it on the radar. An unintentional 
side effect with a local ISP here is that it breaks IPv4 a well.


Cheers

Stijn


[1] 
https://forum.openwrt.org/t/21-02-snapshot-ipv4-pppoe-session-keeps-terminating/90552/4






Some more information can be found here:
https://forum.openwrt.org/t/software-flow-offloading-and-conntrack-timeouts/74588
https://bugs.openwrt.org/index.php?do=details_id=3373
https://bugs.openwrt.org/index.php?do=details_id=3759

It could be that this change causes the problems:
https://patchwork.ozlabs.org/project/netdev/patch/20180720130906.27687-3-pa...@netfilter.org/

I do not know how much time and interest I have in debugging and 
fixing this problem. If someone wants to have a closer look into this 
problem it would be really nice. even when you can make it easier to 
reproduce it in a test environment it would be nice.


Should we just release with this as a known problem?

Other than this problem I am not aware of any other critical problem.

Hauke
___
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: [PATCH] kernel-5.4: backport latest patches for wireguard

[Stijn Segers]

Hi,

Op zondag 6 juni 2021 om 12u37 schreef Jason A. Donenfeld 
:
These are the latest patches that just landed upstream for 5.13, will 
be

backported by Greg into 5.10 (because of stable@), and are now in the
5.4 backport branch of wireguard: 
https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.4.y




Probably not the most kosher way, but I've runtested this patch set on 
21.02 HEAD, octeon (EdgeRouter 4), not on master. Works as expected.


Thank you for the hard work!


Cc: Ilya Lipnitskiy 
Signed-off-by: Jason A. Donenfeld 


Tested-by: Stijn Segers 


---
 ...y1305-enable-for-all-MIPS-processors.patch |  60 ++
 ...ps-add-poly1305-core.S-to-.gitignore.patch |  24 +
 ...fix-poly1305_core_setkey-declaration.patch | 172 ++
 ...sts-remove-old-conntrack-kconfig-val.patch |  29 +
 ...sts-make-sure-rp_filter-is-disabled-.patch |  31 ++
 ...reguard-0129-wireguard-do-not-use-O3.patch |  33 ++
 ...nchronize_net-rather-than-synchroniz.patch |  66 +++
 ...ireguard-peer-allocate-in-kmem_cache.patch | 125 +
 ...dips-initialize-list-head-in-selftes.patch |  43 ++
 ...guard-allowedips-remove-nodes-in-O-1.patch | 237 
 ...owedips-allocate-nodes-in-kmem_cache.patch | 173 ++
 ...dips-free-empty-intermediate-nodes-w.patch | 521 
++

 12 files changed, 1514 insertions(+)
 create mode 100644 
target/linux/generic/backport-5.4/080-wireguard-0124-crypto-mips-poly1305-enable-for-all-MIPS-processors.patch
 create mode 100644 
target/linux/generic/backport-5.4/080-wireguard-0125-crypto-mips-add-poly1305-core.S-to-.gitignore.patch
 create mode 100644 
target/linux/generic/backport-5.4/080-wireguard-0126-crypto-poly1305-fix-poly1305_core_setkey-declaration.patch
 create mode 100644 
target/linux/generic/backport-5.4/080-wireguard-0127-wireguard-selftests-remove-old-conntrack-kconfig-val.patch
 create mode 100644 
target/linux/generic/backport-5.4/080-wireguard-0128-wireguard-selftests-make-sure-rp_filter-is-disabled-.patch
 create mode 100644 
target/linux/generic/backport-5.4/080-wireguard-0129-wireguard-do-not-use-O3.patch
 create mode 100644 
target/linux/generic/backport-5.4/080-wireguard-0130-wireguard-use-synchronize_net-rather-than-synchroniz.patch
 create mode 100644 
target/linux/generic/backport-5.4/080-wireguard-0131-wireguard-peer-allocate-in-kmem_cache.patch
 create mode 100644 
target/linux/generic/backport-5.4/080-wireguard-0132-wireguard-allowedips-initialize-list-head-in-selftes.patch
 create mode 100644 
target/linux/generic/backport-5.4/080-wireguard-0133-wireguard-allowedips-remove-nodes-in-O-1.patch
 create mode 100644 
target/linux/generic/backport-5.4/080-wireguard-0134-wireguard-allowedips-allocate-nodes-in-kmem_cache.patch
 create mode 100644 
target/linux/generic/backport-5.4/080-wireguard-0135-wireguard-allowedips-free-empty-intermediate-nodes-w.patch


diff --git 
a/target/linux/generic/backport-5.4/080-wireguard-0124-crypto-mips-poly1305-enable-for-all-MIPS-processors.patch 
b/target/linux/generic/backport-5.4/080-wireguard-0124-crypto-mips-poly1305-enable-for-all-MIPS-processors.patch

new file mode 100644
index 00..c0ee841b02
--- /dev/null
+++ 
b/target/linux/generic/backport-5.4/080-wireguard-0124-crypto-mips-poly1305-enable-for-all-MIPS-processors.patch

@@ -0,0 +1,60 @@
+From  Mon Sep 17 00:00:00 
2001

+From: "Maciej W. Rozycki" 
+Date: Thu, 11 Mar 2021 21:50:47 -0700
+Subject: [PATCH] crypto: mips/poly1305 - enable for all MIPS 
processors

+
+commit 6c810cf20feef0d4338e9b424ab7f2644a8b353e upstream.
+
+The MIPS Poly1305 implementation is generic MIPS code written such 
as to
+support down to the original MIPS I and MIPS III ISA for the 32-bit 
and
+64-bit variant respectively.  Lift the current limitation then to 
enable
+code for MIPSr1 ISA or newer processors only and have it available 
for

+all MIPS processors.
+
+Signed-off-by: Maciej W. Rozycki 
+Fixes: a11d055e7a64 ("crypto: mips/poly1305 - incorporate 
OpenSSL/CRYPTOGAMS optimized implementation")

+Cc: sta...@vger.kernel.org # v5.5+
+Acked-by: Jason A. Donenfeld 
+Signed-off-by: Thomas Bogendoerfer 
+Signed-off-by: Jason A. Donenfeld 
+---
+ arch/mips/crypto/Makefile | 4 ++--
+ crypto/Kconfig| 2 +-
+ drivers/net/Kconfig   | 2 +-
+ 3 files changed, 4 insertions(+), 4 deletions(-)
+
+--- a/arch/mips/crypto/Makefile
 b/arch/mips/crypto/Makefile
+@@ -12,8 +12,8 @@ AFLAGS_chacha-core.o += -O2 # needed to
+ obj-$(CONFIG_CRYPTO_POLY1305_MIPS) += poly1305-mips.o
+ poly1305-mips-y := poly1305-core.o poly1305-glue.o
+
+-perlasm-flavour-$(CONFIG_CPU_MIPS32) := o32
+-perlasm-flavour-$(CONFIG_CPU_MIPS64) := 64
++perlasm-flavour-$(CONFIG_32BIT) := o32
++perlasm-flavour-$(CONFIG_64BIT) := 64
+
+ quiet_cmd_perlasm = PERLASM $@
+   cmd_perlasm = $(PERL) $(<) $(perlasm-flavour-y) $(@)
+--- a/crypto/Kconfig
 b/crypto/Kconfig
+@@ -740,7 +740,7 @@ config CRYPTO_POLY1305_X86_64
+
+ config CRYPTO_POLY1305_MIPS
+  

[PATCH] firmware-utils: tplink-safeloader: support Archer A6 v3 CA

[Stijn Segers]

The Canadian edition of the TP-Link Archer A6 v3 uses a different header, but
otherwise it's identical to the already supported EU/US editions.

Signed-off-by: Stijn Segers 
Tested-by: Brian Lee 
---
 tools/firmware-utils/src/tplink-safeloader.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/firmware-utils/src/tplink-safeloader.c 
b/tools/firmware-utils/src/tplink-safeloader.c
index 86d51db269..fd154e7e0a 100644
--- a/tools/firmware-utils/src/tplink-safeloader.c
+++ b/tools/firmware-utils/src/tplink-safeloader.c
@@ -1097,6 +1097,7 @@ static struct device_info boards[] = {
.vendor = "",
.support_list =
"SupportList:\n"
+   "{product_name:Archer 
A6,product_ver:3.0.0,special_id:4341}\n"
"{product_name:Archer 
A6,product_ver:3.0.0,special_id:5553}\n"
"{product_name:Archer 
A6,product_ver:3.0.0,special_id:5457}\n",
.part_trail = 0x00,
-- 
2.30.2


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

Re: Flagship AX routers

[Stijn Segers]

Hi,

Mike Bernardo  schreef op 21 mei 2021 13:46:25 CEST:
>Would be great if we could get openwrt running on these, with 2.5gigE and AX.
>
>https://www.fs.com/products/115390.html
>
>It is a BCM47622, I wonder how difficult this would be?

Oh you'd provably get the board up and running in a jiffy. I suppose the 
multi-gigabit PHYs might already be supported as well - not in the loop in 
those. The wireless? Just look at Broadcom's FOSS track record with 
802.11g/n/ac. And vote with your wallet.

Stijn

> I'd be tempted to buy one to give it a try.
>
>Mike
>
>> On 2021/05/21, at 04:58:46 CDT (-05:00), Daniel Golle 
>>  wrote:
>> 
>> On Thu, May 20, 2021 at 11:26:58PM -0600, Philip Prindeville wrote:
>>> 
>>> 
 On May 18, 2021, at 10:57 PM, John Crispin  wrote:
 
 On 19.05.21 00:09, Paul Spooren wrote:
> Hi,
> 
> On 5/18/21 11:52 PM, Philip Prindeville wrote:
>> Hi all,
>> 
>> I noticed that there are several AX routers from TP-Link, Netgear, 
>> D-Link, etc. and some of them have even had OpenWRT ported to them.
>> 
>> Which of these various platforms has the most CPU/RAM/FLASH? A few are 
>> discussed, but I'm not seeing consensus on "the best one currently is 
>> this..."
> 
> I'm using both a Belkin RT3200 and a Linksys AX3200 (aka E8450), which 
> are conveniently pretty much the same thing and I'm having a pretty good 
> time. Would flash again.
> 
> Best,
> Paul
> 
 
 this is the goto unit for AX right now ...
 
 https://openwrt.org/toh/linksys/linksys_e8450
 
 consider using this to flash the unit
 
 https://github.com/dangowrt/linksys-e8450-openwrt-installer
 
John
 
>>> 
>>> 
>>> Thanks, both of you.
>>> 
>>> Is that the one that only has USB 2.0, so if you wanted to add a hard drive 
>>> for NAS or DLNA, you're bandwidth limited?
>> 
>> Yes, it got only USB 2.0, I guess because for USB 3.x you got to decide
>> to either live with 2.4~2.5GHz interference (like most IPQ devices I've
>> seen having USB 3.0 so far) or spend more for filters and evaluating a
>> board design.
>> It's definitely not meant to be a NAS, it's just an AP/Router, not even
>> too useful as a modem-router (USB 2.0 port supplies only 500mAh afair).
>> When using as dual-band AP, also the Gigabit Ethernet of the E8450 can
>> become a bottle-kneck, UniFi 6 LR got that Aquantina 2.5GBase-T PHY
>> (and also combines MT7622x with MT7915E, like the E8450).
>> 
>> ___
>> 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

-- 
Verstuurd vanaf mijn Android apparaat met K-9 Mail. Excuseer mijn beknoptheid.

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

Re: Installing OpenWrt 21.02 on the TP-Link AD7200

[Stijn Segers]

Hi,

Alex Henrie  schreef op 20 april 2021 07:28:32 CEST:
>Hello everyone,
>
>OpenWrt 21.02 adds support for the TP-Link AD7200,[1][2] but in
>practice I have not been able to install it. When I try uploading any
>of the three images (uImage, factory, sysupgrade) through the web
>interface, it just says "Firmware file error."
>
>I also tried setting my computer's IP address to 192.168.0.66, making
>the image available over TFTP with the name
>AD7200_1.0_tp_recovery.bin, and booting up the router with the reset
>button held down. I had Wireshark open and watched the file being
>transferred, but when the transfer was complete, the router just
>rebooted into its stock firmware again.
>
>So, what is the correct procedure for installing OpenWrt on the AD7200?


Try downgrading to an older firmware. If that does not work then you'll need to 
hook up serial to see the messages the flashing process spits out.

Chances are OEM firmware checks for a software version now e.g., which is unset 
at this point (see tplink-safeloader.c code).

Stijn

>
>-Alex
>
>[1] 
>https://git.openwrt.org/?p=openwrt%2Fopenwrt.git=search=HEAD=commit=ad7200
>[2] 
>https://downloads.openwrt.org/releases/21.02-SNAPSHOT/targets/ipq806x/generic/
>
>___
>openwrt-devel mailing list
>openwrt-devel@lists.openwrt.org
>https://lists.openwrt.org/mailman/listinfo/openwrt-devel

-- 
Verstuurd vanaf mijn Android apparaat met K-9 Mail. Excuseer mijn beknoptheid.

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

[PATCH v3 1/3] realtek: correct GS110TPP v1 PoE budget, add rtl83xx-poe package

[Stijn Segers]

Set the right PoE power budget and add the rtl83xx-poe package to
control PoE with OpenWrt.

According to multiple sources (Netgear web page [1], Wikidevi [2] and Biot's
wiki [3]) this switch has a 120W PoE power budget, not a 130W one.

[1] https://www.netgear.com/business/wired/switches/smart-cloud/gs110tpp/
[2] https://wikidevi.wi-cat.ru/Netgear_GS110TPP
[3] https://biot.com/switches/gs110tpp

Signed-off-by: Stijn Segers 
---
 target/linux/realtek/base-files/etc/board.d/02_network | 2 +-
 target/linux/realtek/image/Makefile| 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/target/linux/realtek/base-files/etc/board.d/02_network 
b/target/linux/realtek/base-files/etc/board.d/02_network
index 1e199db589..b27bed9a63 100644
--- a/target/linux/realtek/base-files/etc/board.d/02_network
+++ b/target/linux/realtek/base-files/etc/board.d/02_network
@@ -49,7 +49,7 @@ done
 
 case $board in
 netgear,gs110tpp-v1)
-   ucidef_set_poe 130 "$lan_list"
+   ucidef_set_poe 120 "$lan_list"
;;
 zyxel,gs1900-10hp)
ucidef_set_poe 77 "$lan_list"
diff --git a/target/linux/realtek/image/Makefile 
b/target/linux/realtek/image/Makefile
index 18e5fedb9b..429548391d 100644
--- a/target/linux/realtek/image/Makefile
+++ b/target/linux/realtek/image/Makefile
@@ -83,6 +83,7 @@ define Device/netgear_gs110tpp-v1
   $(Device/netgear_nge)
   DEVICE_MODEL := GS110TPP
   DEVICE_VARIANT := v1
+  DEVICE_PACKAGES += rtl83xx-poe
 endef
 TARGET_DEVICES += netgear_gs110tpp-v1
 
-- 
2.30.2


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

[PATCH v3 0/3] realtek: PoE budgets and rtl83xx-poe package

[Stijn Segers]

This is a set of assorted fixes and improvements for the realtek target.
All patches depend on the rtl83xx-poe package sitting in Patchwork.

If we keep the realtek target for 21.02, please backport these from
master.

Stijn Segers (3):
  realtek: correct GS110TPP v1 PoE budget, add rtl83xx-poe package
  realtek: add rtl83xx-poe to GS1900-8HP & GS1900-10HP profile
  realtek: add PoE budget and rtl83xx-poe package for DGS-1210-10P

 target/linux/realtek/base-files/etc/board.d/02_network | 5 -
 target/linux/realtek/image/Makefile| 8 +---
 2 files changed, 9 insertions(+), 4 deletions(-)

-- 
2.30.2


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

[PATCH v3 2/3] realtek: add rtl83xx-poe to GS1900-8HP & GS1900-10HP profile

[Stijn Segers]

Add the rtl83xx-poe package to the device profiles for the
ZyXEL PoE switches that are currently supported:
- GS1900-10HP
- GS1900-8HP v1
- GS1900-8HP v2

Signed-off-by: Stijn Segers 
---
 target/linux/realtek/image/Makefile | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/target/linux/realtek/image/Makefile 
b/target/linux/realtek/image/Makefile
index 429548391d..4d34aabd5e 100644
--- a/target/linux/realtek/image/Makefile
+++ b/target/linux/realtek/image/Makefile
@@ -99,6 +99,7 @@ endef
 define Device/zyxel_gs1900-10hp
   $(Device/zyxel_gs1900)
   DEVICE_MODEL := GS1900-10HP
+  DEVICE_PACKAGES += rtl83xx-poe
   ZYXEL_VERS := AAZI
 endef
 TARGET_DEVICES += zyxel_gs1900-10hp
@@ -114,8 +115,8 @@ define Device/zyxel_gs1900-8hp-v1
   $(Device/zyxel_gs1900)
   DEVICE_MODEL := GS1900-8HP
   DEVICE_VARIANT := v1
+  DEVICE_PACKAGES += rtl83xx-poe
   ZYXEL_VERS := AAHI
-  DEVICE_PACKAGES += lua-rs232
 endef
 TARGET_DEVICES += zyxel_gs1900-8hp-v1
 
@@ -123,8 +124,8 @@ define Device/zyxel_gs1900-8hp-v2
   $(Device/zyxel_gs1900)
   DEVICE_MODEL := GS1900-8HP
   DEVICE_VARIANT := v2
+  DEVICE_PACKAGES += rtl83xx-poe
   ZYXEL_VERS := AAHI
-  DEVICE_PACKAGES += lua-rs232
 endef
 TARGET_DEVICES += zyxel_gs1900-8hp-v2
 
-- 
2.30.2


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

[PATCH v3 3/3] realtek: add PoE budget and rtl83xx-poe package for DGS-1210-10P

[Stijn Segers]

The PoE power budget for the DGS-1210-10P is known to be 65W, so set it.
Also add the rtl83xx-poe package to the device profile so we can manage
PoE with OpenWrt just like one would with the vendor firmware.

Signed-off-by: Stijn Segers 
---
 target/linux/realtek/base-files/etc/board.d/02_network | 3 +++
 target/linux/realtek/image/Makefile| 2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/target/linux/realtek/base-files/etc/board.d/02_network 
b/target/linux/realtek/base-files/etc/board.d/02_network
index b27bed9a63..a65066a522 100644
--- a/target/linux/realtek/base-files/etc/board.d/02_network
+++ b/target/linux/realtek/base-files/etc/board.d/02_network
@@ -48,6 +48,9 @@ done
 [ -n "$label_mac" ] && ucidef_set_label_macaddr $label_mac
 
 case $board in
+d-link,dgs-1210-10p)
+   ucidef_set_poe 65 "$lan_list"
+   ;;
 netgear,gs110tpp-v1)
ucidef_set_poe 120 "$lan_list"
;;
diff --git a/target/linux/realtek/image/Makefile 
b/target/linux/realtek/image/Makefile
index 4d34aabd5e..da1b5fb2ed 100644
--- a/target/linux/realtek/image/Makefile
+++ b/target/linux/realtek/image/Makefile
@@ -56,7 +56,7 @@ endef
 define Device/d-link_dgs-1210-10p
   $(Device/d-link_dgs-1210)
   DEVICE_MODEL := DGS-1210-10P
-  DEVICE_PACKAGES += lua-rs232
+  DEVICE_PACKAGES += rtl83xx-poe
 endef
 TARGET_DEVICES += d-link_dgs-1210-10p
 
-- 
2.30.2


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

Re: [PATCH v2 3/3] realtek: add rtl83xx-poe for GS1900-8HP & GS1900-10HP

[Stijn Segers]

Hi,



Op maandag 12 april 2021 om 15u31 schreef Bjørn Mork :

Stijn Segers  writes:


 Add the rtl83xx-poe package to the device profiles for the
 ZyXEL PoE switches that are currently supported:
 - GS1900-10HP
 - GS1900-8HP v1
 - GS1900-8HP v2

 Signed-off-by: Stijn Segers 
 ---
 This patch depends on the rtl83xx-poe package sitting in Patchwork:
 https://patchwork.ozlabs.org/project/openwrt/list/?series=233826


Wondering a bit about the status here? Did I miss some change request 
or

is there something else wrong?

This package is required to use the PoE feature of the supported
switches. Releasing 21.02 without it will probably result in 
frustrated
users looking for a way to use a feature which used to work before 
they

upgraded to OpenWrt. We can easily make it work by default with the
rtl83xx-poe package and Stijn's patch.

The package works very well, and no one has yet made any alternative
implementation in other languages or whatver, as far as I know.



I'll be sending in a revised patch set that covers non-ZyXEL devices as 
well, these patches are rather trivial so would be nice to see them 
merged.


Cheers

Stijn



Bjørn



___
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: [PATCH v2 1/3] uboot-envtools: add support for GS108T v3 & GS110TPP v1

[Stijn Segers]

Hi,

Op donderdag 8 april 2021 om 12u33 schreef Stijn Segers 
:
The Netgear GS108T v3 and its GS110TPP v1 sibling apparently label 
their

u-boot environment parition 'bdinfo' instead of 'u-boot-env'.



I was still carrying prior to Bjorn's last rebase, but this isn't 
needed anymore. Both devices fully match the generic case. Will update 
accordingly in Patchwork.


Cheers

Stijn




Signed-off-by: Stijn Segers 
---
 package/boot/uboot-envtools/files/realtek | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/package/boot/uboot-envtools/files/realtek 
b/package/boot/uboot-envtools/files/realtek

index 75a399208e..0ee81fe791 100644
--- a/package/boot/uboot-envtools/files/realtek
+++ b/package/boot/uboot-envtools/files/realtek
@@ -22,6 +22,12 @@ zyxel,gs1900-10hp)
[ -n "$idx2" ] && \
 		ubootenv_add_uci_sys_config "/dev/mtd$idx2" "0x0" "0x1000" 
"0x1"

;;
+netgear,gs108t-v3|\
+netgear,gs110tpp-v1)
+   idx="$(find_mtd_index u-boot-env)"
+   [ -n "$idx" ] && \
+   ubootenv_add_uci_config "/dev/mtd$idx" "0x0" "0x1" "0x1"
+   ;;
 *)
idx="$(find_mtd_index u-boot-env)"
[ -n "$idx" ] && \
--
2.30.2


___
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

[PATCH v2 0/3] Realtek: various fixes

[Stijn Segers]

This is a set of assorted fixes and improvements for the realtek target.
Patch #3 depends on the rtl83xx-poe package sitting in Patchwork.

If we keep the realtek target for 21.02, please backport these from
master. 

Stijn Segers (3):
  uboot-envtools: add support for GS108T v3 & GS110TPP v1
  realtek: correct PoE power budget for GS110TPP v1
  realtek: add rtl83xx-poe to GS1900-8HP & GS1900-10HP

 package/boot/uboot-envtools/files/realtek  | 6 ++
 target/linux/realtek/base-files/etc/board.d/02_network | 2 +-
 target/linux/realtek/image/Makefile| 5 +++--
 3 files changed, 10 insertions(+), 3 deletions(-)

-- 
2.30.2


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

[PATCH v2 3/3] realtek: add rtl83xx-poe for GS1900-8HP & GS1900-10HP

[Stijn Segers]

Add the rtl83xx-poe package to the device profiles for the
ZyXEL PoE switches that are currently supported:
- GS1900-10HP
- GS1900-8HP v1
- GS1900-8HP v2

Signed-off-by: Stijn Segers 
---
This patch depends on the rtl83xx-poe package sitting in Patchwork:
https://patchwork.ozlabs.org/project/openwrt/list/?series=233826
---
 target/linux/realtek/image/Makefile | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/target/linux/realtek/image/Makefile 
b/target/linux/realtek/image/Makefile
index 18e5fedb9b..65aeed6a5e 100644
--- a/target/linux/realtek/image/Makefile
+++ b/target/linux/realtek/image/Makefile
@@ -98,6 +98,7 @@ endef
 define Device/zyxel_gs1900-10hp
   $(Device/zyxel_gs1900)
   DEVICE_MODEL := GS1900-10HP
+  DEVICE_PACKAGES += rtl83xx-poe
   ZYXEL_VERS := AAZI
 endef
 TARGET_DEVICES += zyxel_gs1900-10hp
@@ -113,8 +114,8 @@ define Device/zyxel_gs1900-8hp-v1
   $(Device/zyxel_gs1900)
   DEVICE_MODEL := GS1900-8HP
   DEVICE_VARIANT := v1
+  DEVICE_PACKAGES += rtl83xx-poe
   ZYXEL_VERS := AAHI
-  DEVICE_PACKAGES += lua-rs232
 endef
 TARGET_DEVICES += zyxel_gs1900-8hp-v1
 
@@ -122,8 +123,8 @@ define Device/zyxel_gs1900-8hp-v2
   $(Device/zyxel_gs1900)
   DEVICE_MODEL := GS1900-8HP
   DEVICE_VARIANT := v2
+  DEVICE_PACKAGES += rtl83xx-poe
   ZYXEL_VERS := AAHI
-  DEVICE_PACKAGES += lua-rs232
 endef
 TARGET_DEVICES += zyxel_gs1900-8hp-v2
 
-- 
2.30.2


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

[PATCH v2 1/3] uboot-envtools: add support for GS108T v3 & GS110TPP v1

[Stijn Segers]

The Netgear GS108T v3 and its GS110TPP v1 sibling apparently label their
u-boot environment parition 'bdinfo' instead of 'u-boot-env'.

Signed-off-by: Stijn Segers 
---
 package/boot/uboot-envtools/files/realtek | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/package/boot/uboot-envtools/files/realtek 
b/package/boot/uboot-envtools/files/realtek
index 75a399208e..0ee81fe791 100644
--- a/package/boot/uboot-envtools/files/realtek
+++ b/package/boot/uboot-envtools/files/realtek
@@ -22,6 +22,12 @@ zyxel,gs1900-10hp)
[ -n "$idx2" ] && \
ubootenv_add_uci_sys_config "/dev/mtd$idx2" "0x0" "0x1000" 
"0x1"
;;
+netgear,gs108t-v3|\
+netgear,gs110tpp-v1)
+   idx="$(find_mtd_index u-boot-env)"
+   [ -n "$idx" ] && \
+   ubootenv_add_uci_config "/dev/mtd$idx" "0x0" "0x1" "0x1"
+   ;;
 *)
idx="$(find_mtd_index u-boot-env)"
[ -n "$idx" ] && \
-- 
2.30.2


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

[PATCH v2 2/3] realtek: correct PoE power budget for GS110TPP v1

[Stijn Segers]

According to multiple sources (Netgear web page [1], Wikidevi [2] and Biot's
wiki [3] this switch has a 120W PoE power budget, not a 130W one.

[1] https://www.netgear.com/business/wired/switches/smart-cloud/gs110tpp/
[2] https://wikidevi.wi-cat.ru/Netgear_GS110TPP
[3] https://biot.com/switches/gs110tpp

Signed-off-by: Stijn Segers 
---
 target/linux/realtek/base-files/etc/board.d/02_network | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/realtek/base-files/etc/board.d/02_network 
b/target/linux/realtek/base-files/etc/board.d/02_network
index 1e199db589..b27bed9a63 100644
--- a/target/linux/realtek/base-files/etc/board.d/02_network
+++ b/target/linux/realtek/base-files/etc/board.d/02_network
@@ -49,7 +49,7 @@ done
 
 case $board in
 netgear,gs110tpp-v1)
-   ucidef_set_poe 130 "$lan_list"
+   ucidef_set_poe 120 "$lan_list"
;;
 zyxel,gs1900-10hp)
ucidef_set_poe 77 "$lan_list"
-- 
2.30.2


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

Re: OpenWrt 21.02-rc1 - realtek and mediatek targets

[Stijn Segers]

Hi,

Op donderdag 8 april 2021 om 8u35 schreef Bjørn Mork :

Stijn Segers  writes:

 A vote for keeping the realtek target here, I have three devices 
here

 in production. Very happy with them. The main catch I see with
 relegating the realtek target to master would be less uptake on the
 end user side (not everyone will want to run hardware that needs
 OpenWrt master), but I am unqualified to judge the code quality.

 All I can say is it runs nicely here (including PoE).


I agree.  The feature set of the realtek target is pretty complete, 
and

the anticipated fast movement of the target in master has not happened
yet.

So please keep realtek for 21.02.

There is one pending series applicable to realtek which I had hoped to
get in before exposing the target to innocent users, but this might be
too late by now?:
https://patchwork.ozlabs.org/project/openwrt/list/?series=237587

Being able to adjust the "bootpartition" variable is crucial to 
support
console-less installation IMHO.  Which makes the target more 
accessible

to non-developers.


I see Petr just merged them into master (thanks!). I'll be sending in a 
few fixes that depend on them too, would be good if they could make it 
into 21.02 as well.


Cheers

Stijn





Bjørn




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

Re: OpenWrt 21.02-rc1 - realtek and mediatek targets

[Stijn Segers]

Hi Hauke,

Op woensdag 7 april 2021 om 22u27 schreef Hauke Mehrtens 
:

On 4/7/21 12:29 AM, Hauke Mehrtens wrote:

Hi,

How do we want to go forward with OpenWrt 21.02-rc1?

* I think the base system is ok.
* The http (original wolfssl) problem reported by jow is fixed
* LuCI in the 21.02 branch still misses DSA support, this was merged 
into master some time ago as far as I understood.


Jow reported this end of March:

I found some serious regressions in the luci device config support.
not sure yet how long it'll take to sort out. The netifd uci config
grew so complex that it'll take a while to try all cases
* changing interface settings after previously enabling certain
  options results in a brick
* wireless networks with custom ifnames are improperly bridged
* option ipv6 for ppp based protocols is broken because it clashes
  with option ipv6 in device sections


I would like to merge this update of iproute2 if Russel is fine with 
it, but I do not see this blocking 21.02-rc1:

https://github.com/openwrt/openwrt/pull/4025

If there are some other bugs in the 21.02 branch which are fixed in 
master, we can backport the fixed as long as they are not so big. 
If there is something missing, just ask on the mainling list.


In would like to get 21.02-rc1 soon, so more users start testing it 
and we get more bug reports.


How should we continue?
1. Tag 21.02-rc1 and do the release in the next days with the current
   state.

2. Merge the LuCI DSA changes from master to 21.02 branch now and do
   21.02-rc1 ~3 days to see if some big problems come up.

3. Wait till the problems reported by jow are fixed and do the 
21.02-rc1

   them.

4. Wait an other 2 weeks and see how it looks them.


I would prefer if we merge the LuCI DSA changes from master to 21.02 
branch now and do 21.02-rc1 soon. We should list the problems as 
known problems.


It would be nice if someone else could also look into these problems 
and propose fixes.


Hauke


Hi,

Do we want to keep the realtek and mediatek targets in the 21.02 
branch and release or do we want to remove them link the ipq807x 
target?




A vote for keeping the realtek target here, I have three devices here 
in production. Very happy with them. The main catch I see with 
relegating the realtek target to master would be less uptake on the end 
user side (not everyone will want to run hardware that needs OpenWrt 
master), but I am unqualified to judge the code quality.


All I can say is it runs nicely here (including PoE).

Cheers

Stijn


Hauke

___
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 21.02-rc1 (backport request, WireGuard, DSA roaming, iproute2 5.11)

[Stijn Segers]

Hi Hauke,


Op woensdag 7 april 2021 om 23u58 schreef Hauke Mehrtens 
:

On 4/7/21 12:29 AM, Hauke Mehrtens wrote:

Hi,

How do we want to go forward with OpenWrt 21.02-rc1?

* I think the base system is ok.
* The http (original wolfssl) problem reported by jow is fixed
* LuCI in the 21.02 branch still misses DSA support, this was merged 
into master some time ago as far as I understood.


Jow reported this end of March:

I found some serious regressions in the luci device config support.
not sure yet how long it'll take to sort out. The netifd uci config
grew so complex that it'll take a while to try all cases
* changing interface settings after previously enabling certain
  options results in a brick
* wireless networks with custom ifnames are improperly bridged
* option ipv6 for ppp based protocols is broken because it clashes
  with option ipv6 in device sections


I would like to merge this update of iproute2 if Russel is fine with 
it, but I do not see this blocking 21.02-rc1:

https://github.com/openwrt/openwrt/pull/4025

If there are some other bugs in the 21.02 branch which are fixed in 
master, we can backport the fixed as long as they are not so big. 
If there is something missing, just ask on the mainling list.


In would like to get 21.02-rc1 soon, so more users start testing it 
and we get more bug reports.


How should we continue?
1. Tag 21.02-rc1 and do the release in the next days with the current
   state.

2. Merge the LuCI DSA changes from master to 21.02 branch now and do
   21.02-rc1 ~3 days to see if some big problems come up.

3. Wait till the problems reported by jow are fixed and do the 
21.02-rc1

   them.

4. Wait an other 2 weeks and see how it looks them.


I would prefer if we merge the LuCI DSA changes from master to 21.02 
branch now and do 21.02-rc1 soon. We should list the problems as 
known problems.


It would be nice if someone else could also look into these problems 
and propose fixes.


Hauke


Hi,

There are requests for some pretty big changes to get merged into 
21.02:


Bring WireGuard in-tree for 21.02 #3960
https://github.com/openwrt/openwrt/pull/3960
Adding 63482 lines, mostly backported kernel patches.

kernel: DSA roaming fix for Marvell mv88e6xxx
https://git.openwrt.org/920eaab1d8179035d0ae1047e75cf9a50da6a6eb
Adding 1180 lines of kernel patches

build: make sure asm gets built with -DPIC
https://git.openwrt.org/af22991e03cae55f96b06996df2ff16752cec5d5

iproute2: backport 5.11 update and improvements, related NLS fixes 
#4025

https://github.com/openwrt/openwrt/pull/4025
multiple patches for packages

Are there any objections to backporting these changes? If no one 
complains I will merge them into 21.02 in on Friday.



Thanks for getting the RC going. I have been running the WireGuard PR 
on 21.02 for a few weeks now, no issues here. Same for the iproute2 PR 
but I have done no specific testing on it (just running pretty default 
configs on DSA devices). No complaints about that PR either.


Cheers

Stijn


Hauke

___
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: [PATCH v2] rtl83xx-poe: add package

[Stijn Segers]

"Bjørn Mork"  schreef op 13 maart 2021 17:54:19 CET:
>From: John Crispin 
>
>This package implements the microcontroller protocol used to
>talk Broadcom PSE controllers on a number of realtek switches.
>It is required to enable PoE ouput on supported hardware.
>
>The implemented ABI allows individial control and monitoring
>of each PoE port using ubus.  Example from a ZyXEL GS1900-10HP:
>
>root@gs1900-10hp:~# ubus -v list poe
>'poe' @3c3a28fb
>"info":{}
>"port":{"enable":"Boolean","port":"Integer"}
>root@gs1900-10hp:~# ubus call poe info
>{
>"ports": [
>"enabled",
>"enabled",
>"0W",
>"enabled",
>"enabled",
>"enabled",
>"4.6W",
>"4W"
>],
>"power_budget": "77W",
>"power_consumption": "7.8W"
>}
>
>Tested-by: Birger Koblitz 
>Signed-off-by: John Crispin 
>Signed-off-by: Bjørn Mork  [commit message, release number]

Tested-by: Stijn Segers 
>---
>"Adrian Schmutzler"  writes:
>
>> Is this needed in core repo?
>
>I believe it is.  This package (or another implementation of the protocol) is
>required to turn on the PoE hardware on a number of realtek switches.  I must
>admit that I'm not completely sure about the policies wrt core vs packages,
>but my understanding is that hardware enabling packages belong in core.
>
>Will follow-up with a patch adding this to DEVICE_PACKAGES of the affected
>hardware, replacing the current lua-rs232 dependency (which is really this
>package).
>
>
>Bjørn
>
> package/rtl83xx-poe/Makefile |  29 +++
> package/rtl83xx-poe/files/bin/poe.lua| 316 +++
> package/rtl83xx-poe/files/etc/config/poe |  10 +
> package/rtl83xx-poe/files/etc/init.d/poe |  18 ++
> 4 files changed, 373 insertions(+)
> create mode 100644 package/rtl83xx-poe/Makefile
> create mode 100755 package/rtl83xx-poe/files/bin/poe.lua
> create mode 100644 package/rtl83xx-poe/files/etc/config/poe
> create mode 100755 package/rtl83xx-poe/files/etc/init.d/poe
>
>diff --git a/package/rtl83xx-poe/Makefile b/package/rtl83xx-poe/Makefile
>new file mode 100644
>index ..226e6ce694c4
>--- /dev/null
>+++ b/package/rtl83xx-poe/Makefile
>@@ -0,0 +1,29 @@
>+include $(TOPDIR)/rules.mk
>+
>+PKG_NAME:=rtl83xx-poe
>+PKG_RELEASE:=1
>+
>+PKG_LICENSE:=GPL-2.0-or-later
>+
>+include $(INCLUDE_DIR)/package.mk
>+
>+define Package/rtl83xx-poe
>+  SECTION:=utils
>+  CATEGORY:=Utilities
>+  DEPENDS:=+libubox-lua +libubus-lua +libuci-lua +lua-rs232
>+  TITLE:=PoE daemon for realtek switches
>+endef
>+
>+define Package/rtl83xx-poe/description
>+ This package contains an utility to allow triggering the PoE state of 
>realtek switch ports.
>+endef
>+
>+define Build/Compile
>+
>+endef
>+
>+define Package/rtl83xx-poe/install
>+  $(CP) ./files/* $(1)/
>+endef
>+
>+$(eval $(call BuildPackage,rtl83xx-poe))
>diff --git a/package/rtl83xx-poe/files/bin/poe.lua 
>b/package/rtl83xx-poe/files/bin/poe.lua
>new file mode 100755
>index ..86dafe13cd01
>--- /dev/null
>+++ b/package/rtl83xx-poe/files/bin/poe.lua
>@@ -0,0 +1,316 @@
>+#!/usr/bin/lua
>+local rs = require "luars232"
>+
>+port_name = "/dev/ttyS1"
>+out = io.stderr
>+nseq = 0
>+
>+budget = 65.0
>+port_power = {0, 0, 0, 0, 0, 0, 0, 0 }
>+
>+if arg[1] ~= nil then
>+  budget = tonumber(arg[1])
>+end
>+for i = 1, 8 do
>+  port_power[i] = arg[i + 1]
>+end
>+
>+function initSerial(p)
>+  local e, p = rs.open(p)
>+  if e ~= rs.RS232_ERR_NOERROR then
>+  -- handle error
>+  out:write(string.format("can't open serial port '%s', error: 
>'%s'\n",
>+  port_name, rs.error_tostring(e)))
>+  return
>+  end
>+
>+  assert(p:set_baud_rate(rs.RS232_BAUD_19200) == rs.RS232_ERR_NOERROR)
>+  assert(p:set_data_bits(rs.RS232_DATA_8) == rs.RS232_ERR_NOERROR)
>+  assert(p:set_parity(rs.RS232_PARITY_NONE) == rs.RS232_ERR_NOERROR)
>+  assert(p:set_stop_bits(rs.RS232_STOP_1) == rs.RS232_ERR_NOERROR)
>+  assert(p:set_flow_control(rs.RS232_FLOW_OFF)  == rs.RS232_ERR_NOERROR)
>+
>+  out:write(string.format("OK, port open with values '%s'\n", 
>tostring(p)))
>+
>+  return p
>+end
>+
>+function receive(pCon)
>+  local repl

RE: [PATCH] ramips: mt7621: fix R6850 EEPROM offsets

[Stijn Segers]

Hi Adrian,

Op vrijdag 12 maart 2021 om 22u01 schreef Adrian Schmutzler 
:

Hi,


 -Original Message-
 From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
 On Behalf Of Stijn Segers
 Sent: Freitag, 12. März 2021 12:45
 To: openwrt-devel@lists.openwrt.org
 Cc: m...@david-bauer.net; Bernt Ø . Thorvaldsen
 
 Subject: [PATCH] ramips: mt7621: fix R6850 EEPROM offsets

 The Netgear R6850 has its EEPROM data sitting at 0x28000 for the 5 
GHz radio
 and at 0x2 for the 2,4 GHz radio. See forum topic for a hex 
dump [1].


The commit title/message does not really fit the code changes here.
You are adding full pcieX block, not just swapping EEPROM data. 
Please update to make clear what's going on.




I was advised to override the whole block on IRC, rather than just 
overriding the  block EEPROM property.

So just overriding that is enough?

Thanks

Stijn



Best

Adrian



 [1]  
https://forum.openwrt.org/t/netgear-r6850-very-low-transmit-power-

 on-5ghz/90984

 Signed-off-by: Stijn Segers 
 Tested-by: Bernt Ø. Thorvaldsen 
 ---
  .../linux/ramips/dts/mt7621_netgear_r6850.dts  | 18 
++

  1 file changed, 18 insertions(+)

 diff --git a/target/linux/ramips/dts/mt7621_netgear_r6850.dts
 b/target/linux/ramips/dts/mt7621_netgear_r6850.dts
 index 78e9093216..313fecf936 100644
 --- a/target/linux/ramips/dts/mt7621_netgear_r6850.dts
 +++ b/target/linux/ramips/dts/mt7621_netgear_r6850.dts
 @@ -6,3 +6,21 @@
compatible = "netgear,r6850", "mediatek,mt7621-soc";
model = "Netgear R6850";
  };
 +
 + {
 +  wifi@0,0 {
 +  compatible = "mediatek,mt76";
 +  reg = <0x0 0 0 0 0>;
 +  mediatek,mtd-eeprom = < 0x28000>;
 +  ieee80211-freq-limit = <500 600>;
 +  };
 +};
 +
 + {
 +  wifi@0,0 {
 +  compatible = "mediatek,mt76";
 +  reg = <0x0 0 0 0 0>;
 +  mediatek,mtd-eeprom = < 0x2>;
 +  ieee80211-freq-limit = <240 250>;
 +  };
 +};
 --
 2.30.1


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

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




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

[PATCH] ramips: mt7621: fix R6850 EEPROM offsets

[Stijn Segers]

The Netgear R6850 has its EEPROM data sitting at 0x28000 for the 5 GHz radio
and at 0x2 for the 2,4 GHz radio. See forum topic for a hex dump [1].

[1]  
https://forum.openwrt.org/t/netgear-r6850-very-low-transmit-power-on-5ghz/90984

Signed-off-by: Stijn Segers 
Tested-by: Bernt Ø. Thorvaldsen 
---
 .../linux/ramips/dts/mt7621_netgear_r6850.dts  | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/target/linux/ramips/dts/mt7621_netgear_r6850.dts 
b/target/linux/ramips/dts/mt7621_netgear_r6850.dts
index 78e9093216..313fecf936 100644
--- a/target/linux/ramips/dts/mt7621_netgear_r6850.dts
+++ b/target/linux/ramips/dts/mt7621_netgear_r6850.dts
@@ -6,3 +6,21 @@
compatible = "netgear,r6850", "mediatek,mt7621-soc";
model = "Netgear R6850";
 };
+
+ {
+   wifi@0,0 {
+   compatible = "mediatek,mt76";
+   reg = <0x0 0 0 0 0>;
+   mediatek,mtd-eeprom = < 0x28000>;
+   ieee80211-freq-limit = <500 600>;
+   };
+};
+
+ {
+   wifi@0,0 {
+   compatible = "mediatek,mt76";
+   reg = <0x0 0 0 0 0>;
+   mediatek,mtd-eeprom = < 0x2>;
+   ieee80211-freq-limit = <240 250>;
+   };
+};
-- 
2.30.1


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

Re: [PATCH] rtl83xx-poe: add package

[Stijn Segers]

Working brilliantly for weeks here as well.

Tested-by: Stijn Segers 



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

[PATCH 3/3] realtek: correct PoE power budget for GS110TPP v1

[Stijn Segers]

According to multiple sources (Netgear web page [1], Wikidevi [2] and Biot's
wiki [3] this switch has a 120W PoE power budget, not a 130W one.

[1] https://www.netgear.com/business/wired/switches/smart-cloud/gs110tpp/
[2] https://wikidevi.wi-cat.ru/Netgear_GS110TPP
[3] https://biot.com/switches/gs110tpp

Signed-off-by: Stijn Segers 
---
 target/linux/realtek/base-files/etc/board.d/02_network | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/realtek/base-files/etc/board.d/02_network 
b/target/linux/realtek/base-files/etc/board.d/02_network
index 1e199db589..b27bed9a63 100644
--- a/target/linux/realtek/base-files/etc/board.d/02_network
+++ b/target/linux/realtek/base-files/etc/board.d/02_network
@@ -49,7 +49,7 @@ done
 
 case $board in
 netgear,gs110tpp-v1)
-   ucidef_set_poe 130 "$lan_list"
+   ucidef_set_poe 120 "$lan_list"
;;
 zyxel,gs1900-10hp)
ucidef_set_poe 77 "$lan_list"
-- 
2.30.1


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

[PATCH 2/3] realtek: add lua-rs232 to GS110TPP v1 profile

[Stijn Segers]

The GS110TPP v1 has 8 PoE+ ports so it needs the lua-rs232 package
for PoE manipulation.

Signed-off-by: Stijn Segers 
---
 target/linux/realtek/image/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/linux/realtek/image/Makefile 
b/target/linux/realtek/image/Makefile
index fdc7769560..c19915aadd 100644
--- a/target/linux/realtek/image/Makefile
+++ b/target/linux/realtek/image/Makefile
@@ -81,6 +81,7 @@ define Device/netgear_gs110tpp-v1
   $(Device/netgear_nge)
   DEVICE_MODEL := GS110TPP
   DEVICE_VARIANT := v1
+  DEVICE_PACKAGES += lua-rs232
 endef
 TARGET_DEVICES += netgear_gs110tpp-v1
 
-- 
2.30.1


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

[PATCH 1/3] realtek: add lua-rs232 to GS1900-10HP profile

[Stijn Segers]

Somehow all the other supported ZyXEL switches have the lua-rs232 package
defined as an extra package, needed for PoE manipulation, but the
GS1900-10HP does not. Rectify this.

Signed-off-by: Stijn Segers 
---
 target/linux/realtek/image/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/linux/realtek/image/Makefile 
b/target/linux/realtek/image/Makefile
index 424726c8a9..fdc7769560 100644
--- a/target/linux/realtek/image/Makefile
+++ b/target/linux/realtek/image/Makefile
@@ -89,6 +89,7 @@ define Device/zyxel_gs1900-10hp
   IMAGE_SIZE := 6976k
   DEVICE_VENDOR := ZyXEL
   DEVICE_MODEL := GS1900-10HP
+  DEVICE_PACKAGES += lua-rs232
   UIMAGE_MAGIC := 0x8380
   KERNEL_INITRAMFS := kernel-bin | append-dtb | gzip | zyxel-vers AAZI | 
uImage gzip
 endef
-- 
2.30.1


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

[PATCH 0/3] realtek: various fixes

[Stijn Segers]

This patch set fixes a few loose ends on the Realtek
target. Please backport these to 21.02 as well if we
decide to keep it around for the 21.02 release.

Stijn Segers (3):
  realtek: add lua-rs232 to GS1900-10HP profile
  realtek: add lua-rs232 to GS110TPP v1 profile
  realtek: correct PoE power budget for GS110TPP v1

 target/linux/realtek/base-files/etc/board.d/02_network | 2 +-
 target/linux/realtek/image/Makefile| 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

-- 
2.30.1


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

[PATCH] realtek: rename partitions in Netgear DTSI

[Stijn Segers]

Switch the Netgear DTSI for the Realtek target from the OEM partition
naming scheme to accepted OpenWrt naming practices. A quick git grep for
'u-boot-env' e.g. in the OpenWrt tree turns up almost 500 hits whereas
grepping for 'bdinfo' (the OEM equivalent) returns a meagre 14.

Signed-off-by: Stijn Segers 
---
 target/linux/realtek/dts/rtl8380_netgear_gigabit.dtsi | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/target/linux/realtek/dts/rtl8380_netgear_gigabit.dtsi 
b/target/linux/realtek/dts/rtl8380_netgear_gigabit.dtsi
index 2cda3c15a3..d31eb74001 100644
--- a/target/linux/realtek/dts/rtl8380_netgear_gigabit.dtsi
+++ b/target/linux/realtek/dts/rtl8380_netgear_gigabit.dtsi
@@ -47,31 +47,31 @@
#size-cells = <1>;
 
partition@0 {
-   label = "loader";
+   label = "u-boot";
reg = <0x000 0x00e>;
read-only;
};
 
partition@e {
-   label = "bdinfo";
+   label = "u-boot-env";
reg = <0x00e 0x001>;
read-only;
};
 
partition@f {
-   label = "sysinfo";
+   label = "u-boot-env2";
reg = <0x00f 0x001>;
read-only;
};
 
partition@10 {
-   label = "jffs2_cfg";
+   label = "jffs";
reg = <0x010 0x010>;
read-only;
};
 
partition@20 {
-   label = "jffs2_log";
+   label = "jffs2";
reg = <0x020 0x010>;
read-only;
};
-- 
2.30.1


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

Re: [PATCH] uboot-envtools: add support for GS108T v3 & GS110TPP v1

[Stijn Segers]

Hi Bjørn,

Op zondag 28 februari 2021 om 17u03 schreef Bjørn Mork :

Stijn Segers  writes:

 Op zondag 28 februari 2021 om 10u19 schreef Sander Vanheule
 :

 Hi Stijn
 On Sat, 2021-02-27 at 23:05 +0100, Stijn Segers wrote:
  The Netgear GS108T v3 and its GS110TPP v1 sibling apparently 
label
  their u-boot environment parition 'bdinfo' instead of 
'u-boot-env'.

 Alternatively, the u-boot data partition could also just be renamed
 to
 'u-boot-env', to match naming on other devices. Then, 
uboot-envtools

 appears to work without further modification.


 I don't know what is best practice when it comes the partition
 names. Is this something one is supposed to copy from the OEM image?
 Since those namings only influence behaviour within OpenWrt I 
suppose

 one could name them however one sees fit.

 I can change the naming in the DTS, but a separate entry would be
 needed either way, since the second u-boot partition of the GS108T 
v3
 / GS110TPP v1 has different settings than the already existing 
matches
 (see second patch). So we might as well just stick with the DTS as 
it

 is now.

 Thoughts?


I believe all(?) the realtek devices from all vendors use the same
partition names in stock firmware and u-boot.  I would prefer that we
kept as close as possible to those names as well, to avoid unnecessary
confusion.  But if we divert, like for the 'u-boot-env' partition, 
then

we should at least use the same name for all the devices.


ZyXEL GS1900-10HP U-Boot:

RTL838x# flshow
=== FLASH Partition Layout ===
Index  Name   Size   Address
--
 0 LOADER 0x40xb400-0xb403
 1 BDINFO 0x10xb404-0xb404
 2 SYSINFO0x10xb405-0xb405
 3 JFFS2_CFG  0x10   0xb406-0xb415
 4 JFFS2_LOG  0x10   0xb416-0xb425
 5 RUNTIME1   0x6d   0xb426-0xb492
 6 RUNTIME2   0x6d   0xb493-0xb4ff
==

ZyXEL GS1900-10HP OEM firmware (from bootlog without 'quiet'):


Creating 7 MTD partitions on "Total SPI FLASH":
0x-0x0004 : "LOADER"
0x0004-0x0005 : "BDINFO"
0x0005-0x0006 : "SYSINFO"
0x0006-0x0016 : "JFFS2 CFG"
0x0016-0x0026 : "JFFS2 LOG"
0x0026-0x0093 : "RUNTIME"
0x0093-0x0100 : "RUNTIME2"


Netgear GS108Tv3 U-Boot:

RTL838x# flshow
=== FLASH Partition Layout ===
Index  Name   Size   Address
--
 0 LOADER 0xe0xb400-0xb40d
 1 BDINFO 0x10xb40e-0xb40e
 2 SYSINFO0x10xb40f-0xb40f
 3 JFFS2_CFG  0x10   0xb410-0xb41f
 4 JFFS2_LOG  0x10   0xb420-0xb42f
 5 RUNTIME1   0xe8   0xb430-0xb517
 6 RUNTIME2   0xe8   0xb518-0xb5ff
==


Netgear GS108Tv3 OEM firmware (from show tech-support).  This is how 
it
is displayed - I assume mtd3 and mtd4 are named like the ZyXEL, with 
the

firmware confusing itself with those space chars:


-- MTD Information --

mtd0: 0xbd00-0xbd0d "LOADER"
mtd1: 0xbd0e-0xbd0e "BDINFO"
mtd2: 0xbd0f-0xbd0f "SYSINFO"
mtd3: 0xbd10-0xbd1f "JFFS2
mtd4: 0xbd20-0xbd2f "JFFS2
mtd5: 0xbd30-0xbe17 "RUNTIME"
mtd6: 0xbe18-0xbeff "RUNTIME2"




Anyway, the names are pretty consistent acreoss vendors here.  OpenWrt
should alsow be consistent, whether we decide on 'bdinfo' or
'u-boot-env'.



Thanks for sharing, I'll send in a patch to modify the Netgear DTSI. A 
quick git grep shows close to 500 hits for u-boot-env, and a meagre 14 
for bdinfo. I think that picture is pretty clear.


Cheers

Stijn






Bjørn

___
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: [PATCH] uboot-envtools: add support for GS108T v3 & GS110TPP v1

[Stijn Segers]

Hi!

Op zondag 28 februari 2021 om 10u19 schreef Sander Vanheule 
:

Hi Stijn

On Sat, 2021-02-27 at 23:05 +0100, Stijn Segers wrote:

 The Netgear GS108T v3 and its GS110TPP v1 sibling apparently label
 their u-boot environment parition 'bdinfo' instead of 'u-boot-env'.


Alternatively, the u-boot data partition could also just be renamed to
'u-boot-env', to match naming on other devices. Then, uboot-envtools
appears to work without further modification.


I don't know what is best practice when it comes the partition names. 
Is this something one is supposed to copy from the OEM image? Since 
those namings only influence behaviour within OpenWrt I suppose one 
could name them however one sees fit.


I can change the naming in the DTS, but a separate entry would be 
needed either way, since the second u-boot partition of the GS108T v3 / 
GS110TPP v1 has different settings than the already existing matches 
(see second patch). So we might as well just stick with the DTS as it 
is now.


Thoughts?

Stijn



Best,
Sander







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

[PATCH] uboot-envtools: support sysinfo on GS108T v3 & GS110TPP v1

[Stijn Segers]

This patch depends on Patchwork series #220259 [1] to add support for
the alternate configuration partition on the Netgear GS108T v3 and
GS110TPP v1 switches. This partition can be used to manipulate
boot image (like most supported Realtek switches, these have a dual
firmware image setup).

Again, Netgear sticks to its own naming scheme here.

[1] https://patchwork.ozlabs.org/project/openwrt/list/?series=220259

Signed-off-by: Stijn Segers 
---
 package/boot/uboot-envtools/files/realtek | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/package/boot/uboot-envtools/files/realtek 
b/package/boot/uboot-envtools/files/realtek
index 5752b772a9..4d3aa4f286 100644
--- a/package/boot/uboot-envtools/files/realtek
+++ b/package/boot/uboot-envtools/files/realtek
@@ -26,6 +26,9 @@ netgear,gs110tpp-v1)
idx="$(find_mtd_index bdinfo)"
[ -n "$idx" ] && \
ubootenv_add_uci_config "/dev/mtd$idx" "0x0" "0x1" "0x1"
+   idx="$(find_mtd_index sysinfo)"
+   [ -n "$idx" ] && \
+   ubootenv_add_uci_sys_config "/dev/mtd$idx" "0x0" "0x1000"
;;
 *)
idx="$(find_mtd_index u-boot-env)"
-- 
2.30.1


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

[PATCH] uboot-envtools: add support for GS108T v3 & GS110TPP v1

[Stijn Segers]

The Netgear GS108T v3 and its GS110TPP v1 sibling apparently label their
u-boot environment parition 'bdinfo' instead of 'u-boot-env'.

Signed-off-by: Stijn Segers 
---
 package/boot/uboot-envtools/files/realtek | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/package/boot/uboot-envtools/files/realtek 
b/package/boot/uboot-envtools/files/realtek
index 9573e8944f..966c8509c8 100644
--- a/package/boot/uboot-envtools/files/realtek
+++ b/package/boot/uboot-envtools/files/realtek
@@ -18,6 +18,12 @@ zyxel,gs1900-10hp)
[ -n "$idx" ] && \
ubootenv_add_uci_config "/dev/mtd$idx" "0x0" "0x400" "0x1"
;;
+netgear,gs108t-v3|\
+netgear,gs110tpp-v1)
+   idx="$(find_mtd_index bdinfo)"
+   [ -n "$idx" ] && \
+   ubootenv_add_uci_config "/dev/mtd$idx" "0x0" "0x1" "0x1"
+   ;;
 *)
idx="$(find_mtd_index u-boot-env)"
[ -n "$idx" ] && \
-- 
2.30.1


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

Re: [PATCH] ramips: mt7621: enable SX150x driver

[Stijn Segers]

Hi,

Sander Vanheule  schreef op 20 februari 2021 14:45:26 CET:
>The Netgear R6800 and R6700v2 devices have a Semtech SX1503 GPIO
>expander controlling the device LEDs. This expander was initially
>supported on 4.14, but support was lost in the transition to 5.4.
>
>Since this driver cannot be built as a kernel module, enable it in the
>kernel config for all mt7621 devices.
>
>Run-tested on a Netgear R6800.

Works fine here too.
>
>Cc: Stijn Segers 
>Cc: Hauke Mehrtens 
>Signed-off-by: Sander Vanheule 

Tested-by: Stijn Segers 

>---
> target/linux/ramips/mt7621/config-5.4 | 1 +
> 1 file changed, 1 insertion(+)
>
>diff --git a/target/linux/ramips/mt7621/config-5.4 
>b/target/linux/ramips/mt7621/config-5.4
>index fba22a39cf..057c782760 100644
>--- a/target/linux/ramips/mt7621/config-5.4
>+++ b/target/linux/ramips/mt7621/config-5.4
>@@ -210,6 +210,7 @@ CONFIG_PHYLINK=y
> CONFIG_PINCTRL=y
> CONFIG_PINCTRL_RT2880=y
> # CONFIG_PINCTRL_SINGLE is not set
>+CONFIG_PINCTRL_SX150X=y
> CONFIG_POWER_RESET=y
> CONFIG_POWER_RESET_GPIO=y
> CONFIG_POWER_SUPPLY=y

-- 
Verstuurd vanaf mijn Android apparaat met K-9 Mail. Excuseer mijn beknoptheid.

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

[PATCH] ramips: overwrite reset gpio properties in EX6150 DTS.

[Stijn Segers]

The Netgear EX6150 can, just like the D-Link DIR-860L rev B1, fail to
initialise both radios in some cases. Add the reset GPIOs explicitly
so the PCI-E devices get re-initialised properly. See also FS #3632.

Error shows up in dmesg as follows:

  [1.560764] mt7621-pci 1e14.pcie: pcie1 no card, disable it (RST & CLK)

Tested-by: Kurt Roeckx 
Signed-off-by: Stijn Segers 
---
 target/linux/ramips/dts/mt7621_netgear_ex6150.dts | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/target/linux/ramips/dts/mt7621_netgear_ex6150.dts 
b/target/linux/ramips/dts/mt7621_netgear_ex6150.dts
index 2bf858b226..0da8f6b30c 100644
--- a/target/linux/ramips/dts/mt7621_netgear_ex6150.dts
+++ b/target/linux/ramips/dts/mt7621_netgear_ex6150.dts
@@ -206,6 +206,9 @@
 
  {
status = "okay";
+
+   reset-gpios = < 19 GPIO_ACTIVE_LOW>,
+ < 8 GPIO_ACTIVE_LOW>;
 };
 
  {
-- 
2.30.0


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

[PATCH] ramips: remove factory image for TP-Link Archer C20 v1

[Stijn Segers]

Similarly to the Archer C2 v1, the Archer C20 v1 will brick when one
tries to flash an OpenWrt factory image through the TP-Link web UI.
The wiki page contains an explicit warning about this [1].

Disable the factory image altogether since it serves no purpose.

[1] https://openwrt.org/toh/tp-link/tp-link_archer_c20_v1#installation

Signed-off-by: Stijn Segers 
---
 target/linux/ramips/image/mt7620.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/linux/ramips/image/mt7620.mk 
b/target/linux/ramips/image/mt7620.mk
index 7f649aff88..f8905ad2b7 100644
--- a/target/linux/ramips/image/mt7620.mk
+++ b/target/linux/ramips/image/mt7620.mk
@@ -981,6 +981,7 @@ define Device/tplink_archer-c20-v1
   TPLINK_HWID := 0xc201
   TPLINK_HWREV := 0x44
   TPLINK_HWREVADD := 0x1
+  IMAGES := sysupgrade.bin
   DEVICE_MODEL := Archer C20
   DEVICE_VARIANT := v1
   DEVICE_PACKAGES := kmod-mt76x0e kmod-usb2 kmod-usb-ohci \
-- 
2.30.0


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

[PATCH v2] uboot-envtools: add support for ZyXEL GS-1900-8HP v1 and v2

[Stijn Segers]

This adds the necessary nuts and bolts for the uboot settings for both the 
ZyXEL GS1900-8HP v1 and v2.

Signed-off-by: Stijn Segers 
---
Changes in v2: fix syntax error, better English.
---
 package/boot/uboot-envtools/files/realtek | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/package/boot/uboot-envtools/files/realtek 
b/package/boot/uboot-envtools/files/realtek
index b64bb23b07..b415fcedc9 100644
--- a/package/boot/uboot-envtools/files/realtek
+++ b/package/boot/uboot-envtools/files/realtek
@@ -11,6 +11,8 @@ case "$board" in
 d-link,dgs-1210-16|\
 d-link,dgs-1210-28|\
 d-link,dgs-1210-10p|\
+zyxel,gs1900-8hp-v1|\
+zyxel,gs1900-8hp-v2|\
 zyxel,gs1900-10hp)
idx="$(find_mtd_index u-boot-env)"
[ -n "$idx" ] && \
-- 
2.30.0


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

[PATCH] uboot-envtools: add support for ZyXEL GS1900-8HP v1 and v2

[Stijn Segers]

Adds the bits and bolts for the uboot settings for both the ZyXEL
GS1900-8HP v1 and v2.

Signed-off-by: Stijn Segers 
---
 package/boot/uboot-envtools/files/realtek | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/package/boot/uboot-envtools/files/realtek 
b/package/boot/uboot-envtools/files/realtek
index b64bb23b07..6507f34349 100644
--- a/package/boot/uboot-envtools/files/realtek
+++ b/package/boot/uboot-envtools/files/realtek
@@ -11,6 +11,8 @@ case "$board" in
 d-link,dgs-1210-16|\
 d-link,dgs-1210-28|\
 d-link,dgs-1210-10p|\
+zyxel,gs1900-8hp-v1\
+zyxel,gs1900-8hp-v2|\
 zyxel,gs1900-10hp)
idx="$(find_mtd_index u-boot-env)"
[ -n "$idx" ] && \
-- 
2.30.0


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

[PATCH v2] ramips: overwrite reset gpio properties in DIR-860L DTS

[Stijn Segers]

As suggested by Sergio, this adds GPIOs 19 and 8 explicitly into the
DIR-860L DTS, so the PCI-E ports get reset and the N radio (radio1)
on PCI-E port 1 comes up reliably.

Fixes the following error that popped up in dmesg:

[1.638942] mt7621-pci 1e14.pcie: pcie1 no card, disable it (RST & 
CLK)

Suggested-by: Sergio Paracuellos 
Signed-off-by: Stijn Segers 
---
 target/linux/ramips/dts/mt7621_dlink_dir-860l-b1.dts | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/target/linux/ramips/dts/mt7621_dlink_dir-860l-b1.dts 
b/target/linux/ramips/dts/mt7621_dlink_dir-860l-b1.dts
index 5d1c336736..f843f62801 100644
--- a/target/linux/ramips/dts/mt7621_dlink_dir-860l-b1.dts
+++ b/target/linux/ramips/dts/mt7621_dlink_dir-860l-b1.dts
@@ -143,6 +143,9 @@
 
  {
status = "okay";
+
+   reset-gpios = < 19 GPIO_ACTIVE_LOW>,
+ < 8 GPIO_ACTIVE_LOW>;
 };
 
  {
-- 
2.30.0


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

RE: Commit e95b1b23f1b6951318d6c6caf3803fb933f71a6c kernel: bump 5.4 to 5.4.97 kills mt7621/dir860l

[Stijn Segers]

Hi,

Op zaterdag 13 februari 2021 om 18u05 schreef Adrian Schmutzler 
:

 [1.176208] mt7621-pci 1e14.pcie: Parsing DT failed


Is this introduced with the commit or has it been there before on 
this device?



This has been around for quite a while on MT7621. See also this comment 
on the ramips 5.10

PR of the MT7621 PCI driver author as to why this can be safely ignored:

https://github.com/openwrt/openwrt/pull/3693#issuecomment-750436483

I am seeing this message on all three MT7621 devices I have in 
production with master builds,
every single time. I thought it was an issue as well until Sergio 
pointed out it really isn't.


Cheers

Stijn



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: [PATCH] ramips: overwrite reset gpio properties in DIR-860L DTS

[Stijn Segers]

Hi,

Op zaterdag 13 februari 2021 om 18u23 schreef Chuanhong Guo 
:

Hi!

On Sat, Feb 13, 2021 at 5:55 PM Stijn Segers 
 wrote:


 As suggested by Sergio, this adds GPIOs 19 and 8 explicitly into the
 DIR-860L DTS, so the PCI-E ports get reset and the N radio (radio1)
 on PCI-E port 1 comes up reliably.

 Fixes the following error that popped up in dmesg:

 [1.638942] mt7621-pci 1e14.pcie: pcie1 no card, disable 
it (RST & CLK)


 Suggested-by: Sergio Paracuellos 
 Signed-off-by: Stijn Segers 
 ---
  target/linux/ramips/dts/mt7621_dlink_dir-860l-b1.dts | 6 ++
  1 file changed, 6 insertions(+)

 diff --git a/target/linux/ramips/dts/mt7621_dlink_dir-860l-b1.dts 
b/target/linux/ramips/dts/mt7621_dlink_dir-860l-b1.dts

 index 5d1c336736..65d53e4ef4 100644
 --- a/target/linux/ramips/dts/mt7621_dlink_dir-860l-b1.dts
 +++ b/target/linux/ramips/dts/mt7621_dlink_dir-860l-b1.dts
 @@ -142,6 +142,12 @@
  };

   {
 +   pinctrl-names = "default";


pinctrl-names is already "default" in mt7621.dtsi.


 +   pinctrl-0 = <_pins>;


pinctrl-0 is already pcie_pins in mt7621.dtsi as well.
I'm fine with just dropping these two lines due to the fact that
we mainly used state_default to set up pinctrl in ramips.


Noted, will remove both in v2.


(Ideally a separated pinctrl node with uart3 as gpio should be
defined and referenced here.)



Not completely familiar with that, so I looked at other MT7621 DTSes. 
Would this be how it should be done?


 {
uart3_gpio: uart3-gpio {
uart3 {
groups = "uart3";
function = "gpio";
};
};
};


Would this still go together with the code below from the DIR-860L DTS 
though? Or would that need adapting as well?


_default {
gpio {
groups = "uart3", "jtag", "wdt";
function = "gpio";
};
};


Thanks

Stijn





 +
 +   reset-gpios = < 19 GPIO_ACTIVE_LOW>,
 + < 8 GPIO_ACTIVE_LOW>;
 +
 status = "okay";
  };



--
Regards,
Chuanhong Guo




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

[PATCH] ramips: overwrite reset gpio properties in DIR-860L DTS

[Stijn Segers]

As suggested by Sergio, this adds GPIOs 19 and 8 explicitly into the
DIR-860L DTS, so the PCI-E ports get reset and the N radio (radio1)
on PCI-E port 1 comes up reliably.

Fixes the following error that popped up in dmesg:

[1.638942] mt7621-pci 1e14.pcie: pcie1 no card, disable it (RST & 
CLK)

Suggested-by: Sergio Paracuellos 
Signed-off-by: Stijn Segers 
---
 target/linux/ramips/dts/mt7621_dlink_dir-860l-b1.dts | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/target/linux/ramips/dts/mt7621_dlink_dir-860l-b1.dts 
b/target/linux/ramips/dts/mt7621_dlink_dir-860l-b1.dts
index 5d1c336736..65d53e4ef4 100644
--- a/target/linux/ramips/dts/mt7621_dlink_dir-860l-b1.dts
+++ b/target/linux/ramips/dts/mt7621_dlink_dir-860l-b1.dts
@@ -142,6 +142,12 @@
 };
 
  {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   reset-gpios = < 19 GPIO_ACTIVE_LOW>,
+ < 8 GPIO_ACTIVE_LOW>;
+
status = "okay";
 };
 
-- 
2.30.0


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

[PATCH] ramips: remove factory image for TP-Link Archer C2 v1

[Stijn Segers]

Initial commit 8375623a06 contains detailed installation instructions,
which do not mention a factory image. From what I can see, no support
to install OpenWrt through the vendor web interface has been added
since. The factory image is also conspicuously absent from the device
page in the wiki. Yet, it is available for download.

I bricked my Archer C2 loading the factory image through the web UI.
Serial showed this error during bootloop:

  Uncompressing Kernel Image ... LZMA ERROR 1 - must RESET board to recover

This patch disables the undocumented factory image so users won't get
tricked into thinking easy web UI flashing actually works.

Signed-off-by: Stijn Segers 
---
 target/linux/ramips/image/mt7620.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/linux/ramips/image/mt7620.mk 
b/target/linux/ramips/image/mt7620.mk
index 2d0050f986..7f649aff88 100644
--- a/target/linux/ramips/image/mt7620.mk
+++ b/target/linux/ramips/image/mt7620.mk
@@ -996,6 +996,7 @@ define Device/tplink_archer-c2-v1
   TPLINK_FLASHLAYOUT := 8Mmtk
   TPLINK_HWID := 0xc751
   TPLINK_HWREV := 50
+  IMAGES := sysupgrade.bin
   DEVICE_MODEL := Archer C2
   DEVICE_VARIANT := v1
   DEVICE_PACKAGES := kmod-mt76x0e kmod-usb2 kmod-usb-ohci \
-- 
2.30.0


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

[PATCH] iwinfo: add PCI ID for MediaTek MT7613BE

[Stijn Segers]

This adds the PCI ID for the MT7613BE series, found in e.g.
the TP-Link EAP235-Wall v1.

Signed-off-by: Stijn Segers 
---
 hardware.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hardware.txt b/hardware.txt
index da843be..ea74929 100644
--- a/hardware.txt
+++ b/hardware.txt
@@ -187,6 +187,7 @@
 0x14c3 0x7603 0x14c3 0x76030  0  "MediaTek" "MT7603E"
 0x14c3 0x7610 0x14c3 0x76100  0  "MediaTek" "MT7610E"
 0x14c3 0x7612 0x14c3 0x76120  0  "MediaTek" "MT7612E"
+0x14c3 0x7663 0x14c3 0x76630  0  "MediaTek" "MT7613BE"
 0x14c3 0x7615 0x7615 0x14c30  0  "MediaTek" "MT7615E"
 0x14c3 0x7620 0x14c3 0x000c0  0  "MediaTek" "MT7620"
 0x14c3 0x7622 0x14c3 0x76220  0  "MediaTek" "MT7622"
-- 
2.29.2


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

Re: [PATCH v4 03/10] kernel: mtdsplit_uimage: replace "fonfxc" and "sge" parsers

[Stijn Segers]

Hi Bjorn,


Op woensdag 20 januari 2021 om 18:36 schreef Bjørn Mork 
:

Convert users of the "fonfxc" and "sge" parsers to the generic
"openwrt,uimage", using device specific "openwrt,padding" properties.

Signed-off-by: Bjørn Mork 



I gave the v4 a few tries on my DIR-878 A1, and it works. Both 
sysupgrading
with and without keeping settings works (been going back and forth 
between

builds with and without the patch set to double check since I was seeing
some unrelated weirdness earlier this week while testing this).

Would be neat to get some people with a DIR-882 A1 to confirm as well (I
know there are some).

Cheers

Stijn

Tested-by: Stijn Segers 


---
 .../drivers/mtd/mtdsplit/mtdsplit_uimage.c| 93 
++-

 .../linux/ramips/dts/mt7620a_fon_fon2601.dts  |  3 +-
 .../ramips/dts/mt7621_dlink_dir-8xx-a1.dtsi   |  3 +-
 .../ramips/dts/mt7621_dlink_dir-xx60-a1.dtsi  |  6 +-
 4 files changed, 16 insertions(+), 89 deletions(-)

diff --git 
a/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_uimage.c 
b/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_uimage.c

index f9544ec382e3..f5e48c661e8f 100644
--- 
a/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_uimage.c
+++ 
b/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_uimage.c
@@ -87,7 +87,7 @@ static void uimage_parse_dt(struct mtd_info 
*master, int *extralen)

 static int __mtdsplit_parse_uimage(struct mtd_info *master,
   const struct mtd_partition **pparts,
   struct mtd_part_parser_data *data,
-  ssize_t (*find_header)(u_char *buf, size_t len, int 
*extralen))
+  ssize_t (*find_header)(u_char *buf, size_t len))
 {
struct mtd_partition *parts;
u_char *buf;
@@ -125,7 +125,7 @@ static int __mtdsplit_parse_uimage(struct 
mtd_info *master,

if (ret)
continue;

-   ret = find_header(buf, MAX_HEADER_LEN, );
+   ret = find_header(buf, MAX_HEADER_LEN);
if (ret < 0) {
pr_debug("no valid uImage found in \"%s\" at offset 
%llx\n",
 master->name, (unsigned long long) offset);
@@ -213,7 +213,7 @@ err_free_parts:
return ret;
 }

-static ssize_t uimage_verify_default(u_char *buf, size_t len, int 
*extralen)

+static ssize_t uimage_verify_default(u_char *buf, size_t len)
 {
struct uimage_header *header = (struct uimage_header *)buf;

@@ -274,7 +274,7 @@ static struct mtd_part_parser 
uimage_generic_parser = {

 #define FW_MAGIC_WNDR3700V20x33373031
 #define FW_MAGIC_WPN824N   0x31313030

-static ssize_t uimage_verify_wndr3700(u_char *buf, size_t len, int 
*extralen)

+static ssize_t uimage_verify_wndr3700(u_char *buf, size_t len)
 {
struct uimage_header *header = (struct uimage_header *)buf;
uint8_t expected_type = IH_TYPE_FILESYSTEM;
@@ -336,7 +336,7 @@ static struct mtd_part_parser 
uimage_netgear_parser = {

 #define FW_MAGIC_SG8208M   0x0006
 #define FW_MAGIC_SG8310PM  0x8306

-static ssize_t uimage_verify_allnet(u_char *buf, size_t len, int 
*extralen)

+static ssize_t uimage_verify_allnet(u_char *buf, size_t len)
 {
struct uimage_header *header = (struct uimage_header *)buf;

@@ -383,7 +383,7 @@ static struct mtd_part_parser 
uimage_allnet_parser = {

 #define FW_EDIMAX_OFFSET   20
 #define FW_MAGIC_EDIMAX0x43535953

-static ssize_t uimage_find_edimax(u_char *buf, size_t len, int 
*extralen)

+static ssize_t uimage_find_edimax(u_char *buf, size_t len)
 {
u32 *magic;

@@ -396,7 +396,7 @@ static ssize_t uimage_find_edimax(u_char *buf, 
size_t len, int *extralen)

if (be32_to_cpu(*magic) != FW_MAGIC_EDIMAX)
return -EINVAL;

-   if (!uimage_verify_default(buf + FW_EDIMAX_OFFSET, len, extralen))
+   if (!uimage_verify_default(buf + FW_EDIMAX_OFFSET, len))
return FW_EDIMAX_OFFSET;

return -EINVAL;
@@ -424,88 +424,13 @@ static struct mtd_part_parser 
uimage_edimax_parser = {

.type = MTD_PARSER_TYPE_FIRMWARE,
 };

-
-/**
- * Fon(Foxconn)
- **/
-
-#define FONFXC_PAD_LEN 32
-
-static ssize_t uimage_find_fonfxc(u_char *buf, size_t len, int 
*extralen)

-{
-   if (uimage_verify_default(buf, len, extralen) < 0)
-   return -EINVAL;
-
-   *extralen = FONFXC_PAD_LEN;
-
-   return 0;
-}
-
-static int
-mtdsplit_uimage_parse_fonfxc(struct mtd_info *master,
- const struct mtd_partition **pparts,
- struct mtd_part_parser_data *data)
-{
-   return __mtdsplit_parse_uimage(master, pparts, data,
-  uimage_find_fonfxc);
-}
-
-static const struct of_device_id 
mtdsplit_uimag

Re: [PATCH v2 00/10] kernel: mtdsplit_uimage: use device tree properties for non-standard uimage parsing

[Stijn Segers]

Hi Bjorn,


Op woensdag 20 januari 2021 om 15u09 schreef Bjørn Mork 
:

Stijn Segers  writes:


 - ramips/mt7621 (DIR-860L B1): with sysupgrade (both with and
   whithout-n)


Thanks.

Going through this now, I see that this device is using the "seama"
partition comptabile and splitter.  Which I didn't touch since it was 
in

a spearate file and therefore outside my tunnel view.



I have an RT-AC57U here that doesn't use that SEAMA stuff, will give it 
a try later this week.


Stijn


Had a quick glance now and I guess it is a candidate for the shared
parser as well. But let's do that later.


Bjørn




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

Re: [PATCH v2 00/10] kernel: mtdsplit_uimage: use device tree properties for non-standard uimage parsing

[Stijn Segers]

Hi Peter, Bjorn,

Op woensdag 13 januari 2021 om 18u43 schreef Sander Vanheule 
:

Hi,

On Mon, 2020-11-30 at 23:19 +0100, Bjørn Mork wrote:

 Bjørn Mork (10):
   dt-bindings: mtd: partitions: add OpenWrt defined U-Boot Image
   kernel: mtdsplit_uimage: read extralen from device tree
   kernel: mtdsplit_uimage: replace "fonfxc" and "sge" parsers
   kernel: mtdsplit_uimage: add "openwrt,ih-magic" device-tree
 property
   kernel: mtdsplit_uimage: replace "openwrt,okli" parser
   kernel: mtdsplit_uimage: replace "allnet,uimage" parser
   kernel: mtdsplit_uimage: add "openwrt,ih-type" device-tree 
property

   kernel: mtdsplit_uimage: replace "netgear,uimage" parser
   kernel: mtdsplit_uimage: add "openwrt,offset" and
 "openwrt,partition-magic"
   kernel: mtdsplit_uimage: replace "edimax,uimage" parser


Using Petr's builds and my own builds, I've run-tested this on my
WNDR3700v2 (ath79/generic). Flashing first Petr's build, I ended up in
a boot loop, although booting only failed after the partitions were
correctly processed, similar to [1]. My own build and a second flash
with ynezz's test build have  produced no issues, so I think the boot-
loop is unrelated to the patches.

Tested-by: Sander Vanheule 



I've run-tested this with my own builds (latest master) on the following
targets:
- ath79/generic (WNDR3700v1): with sysupgrade -n
- ramips/mt7621 (DIR-860L B1): with sysupgrade (both with and 
whithout-n)


Works fine here.

Tested-by: Stijn Segers 





[1] https://bugs.openwrt.org/index.php?do=details_id=478

Best,
Sander



___
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: base-files: flush kernel memory cache during sysupgrade

[Stijn Segers]

Hi,

Have tested this on a few low-RAM devices, among which a TL-WR841N v7 
(32 MiB) and a WNDR3700 v2 (64 MiB).


No idea if this is still necessary/wanted but would be nice to see this 
end up in master (and trickle down to 21.xx :-D ).


Tested-by: Stijn Segers 



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

Re: [PATCH] base-files: sysupgrade: store status of system-services

[Stijn Segers]

Hi Alberto,

Alberto Bursi  schreef op 11 januari 2021 03:56:23 
CET:
>
>
>On 10/01/21 22:50, Stijn Segers wrote:
>> Hi Sven,
>> 
>> Op zondag 10 januari 2021 om 22u28 schreef Sven Roederer 
>> :
>>> Am Samstag, 9. Januar 2021, 12:28:31 CET schrieb Stijn Segers:
>>>>  > @@ -228,6 +229,7 @@ do_save_conffiles() {
>>>>  >
>>>>  > if [ "$SAVE_INSTALLED_PKGS" -eq 1 ]; then
>>>>  > echo "${INSTALLED_PACKAGES}" >> "$CONFFILES"
>>>>  > +   echo "${SERVICE_STATUS}" >> "$CONFFILES"
>>>>  > mkdir -p "$ETCBACKUP_DIR"
>>>>
>>>>  Am I reading this correctly and is this only keeping track of service
>>>>  status if you tell sysupgrade to save packages? What's the rationale
>>>>  behind that?
>>>>
>>>>  I have a personal build with all packages preinstalled, so I don't need
>>>>  that. Would like to keep track of service status though. Can those two
>>>>  things be entangled?
>>>>
>>>
>>> Stijn,
>>>
>>> my intention was to not change the current behavior by default, so an 
>>> extra
>>> switch or extending an existing switch looked like the way. I've 
>>> choosen the
>>> lazy one, based on "when the user is storing the packages-list, he is 
>>> for sure
>>> interested in the services".
>>> But I'm happy to add a separate switch to sysupgrade. Any preference 
>>> of the
>>> letter? What about using "-s"?
>>>
>>> Sven
>> 
>> Yes, that's still free and the most intuitive I think.
>> 
>> Thanks!
>> 
>> Stijn
>> 
>
>Since we (me, Andre Heider and Paul Spooren) are discussing/asking about 
>enabling this by default, do you have any opinion on that?
>
>-Alberto

That would be great, as Adrian pointed out it's something you'd expect would be 
saved when you tell sysupgrade to keep settings.

So +1 from me on making it default. All my AP/testing devices now have 
scripting to disable e.g. DHCP and DNS again after an upgrade.

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

-- 
Verstuurd vanaf mijn Android apparaat met K-9 Mail. Excuseer mijn beknoptheid.

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

Re: [PATCH] base-files: sysupgrade: store status of system-services

[Stijn Segers]

Hi Sven,

Op zondag 10 januari 2021 om 22u28 schreef Sven Roederer 
:

Am Samstag, 9. Januar 2021, 12:28:31 CET schrieb Stijn Segers:

 > @@ -228,6 +229,7 @@ do_save_conffiles() {
 >
 > if [ "$SAVE_INSTALLED_PKGS" -eq 1 ]; then
 > echo "${INSTALLED_PACKAGES}" >> "$CONFFILES"
 > +   echo "${SERVICE_STATUS}" >> "$CONFFILES"
 > mkdir -p "$ETCBACKUP_DIR"

 Am I reading this correctly and is this only keeping track of 
service

 status if you tell sysupgrade to save packages? What's the rationale
 behind that?

 I have a personal build with all packages preinstalled, so I don't 
need
 that. Would like to keep track of service status though. Can those 
two

 things be entangled?



Stijn,

my intention was to not change the current behavior by default, so an 
extra
switch or extending an existing switch looked like the way. I've 
choosen the
lazy one, based on "when the user is storing the packages-list, he is 
for sure

interested in the services".
But I'm happy to add a separate switch to sysupgrade. Any preference 
of the

letter? What about using "-s"?

Sven


Yes, that's still free and the most intuitive I think.

Thanks!

Stijn





___
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: [PATCH] base-files: sysupgrade: store status of system-services

[Stijn Segers]

Hi,

Op zondag 3 januari 2021 om 23u14 schreef Sven Roederer 
:

When saving the list of installed pkgs, also store the status of the
system services. The list is created in the etc/backup folder also
and formated as:

/etc/init.d/ {enable|disable}

This way it can be sourced after sysupgrade, to restore the previous
state.

Signed-off-by: Sven Roederer 
---

Currently all services get enabled during image creation. This can 
cause

issues after upgrade with services explicitly disabled by the user.
With this created list sourced by a simple uci-defaults script the 
state

can be restored automatically.
Not including such a uci-defaults script by default, as currently the
stored package list is also not reinstalled.


 package/base-files/Makefile  |  2 +-
 package/base-files/files/sbin/sysupgrade | 11 +++
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/package/base-files/Makefile b/package/base-files/Makefile
index 0c612b73ca..fbcb694592 100644
--- a/package/base-files/Makefile
+++ b/package/base-files/Makefile
@@ -12,7 +12,7 @@ include $(INCLUDE_DIR)/version.mk
 include $(INCLUDE_DIR)/feeds.mk

 PKG_NAME:=base-files
-PKG_RELEASE:=239
+PKG_RELEASE:=240
 PKG_FLAGS:=nonshared

 PKG_FILE_DEPENDS:=$(PLATFORM_DIR)/ 
$(GENERIC_PLATFORM_DIR)/base-files/
diff --git a/package/base-files/files/sbin/sysupgrade 
b/package/base-files/files/sbin/sysupgrade

index 79927a2b5c..cadce36172 100755
--- a/package/base-files/files/sbin/sysupgrade
+++ b/package/base-files/files/sbin/sysupgrade
@@ -57,6 +57,7 @@ export CONFFILES=/tmp/sysupgrade.conffiles
 export CONF_TAR=/tmp/sysupgrade.tgz
 export ETCBACKUP_DIR=/etc/backup
 export INSTALLED_PACKAGES=${ETCBACKUP_DIR}/installed_packages.txt
+export SERVICE_STATUS=${ETCBACKUP_DIR}/service_status.txt

 IMAGE="$1"

@@ -228,6 +229,7 @@ do_save_conffiles() {

if [ "$SAVE_INSTALLED_PKGS" -eq 1 ]; then
echo "${INSTALLED_PACKAGES}" >> "$CONFFILES"
+   echo "${SERVICE_STATUS}" >> "$CONFFILES"
mkdir -p "$ETCBACKUP_DIR"



Am I reading this correctly and is this only keeping track of service 
status if you tell sysupgrade to save packages? What's the rationale 
behind that?


I have a personal build with all packages preinstalled, so I don't need 
that. Would like to keep track of service status though. Can those two 
things be entangled?


Cheers

Stijn


# Avoid touching filesystem on each backup
RAMFS="$(mktemp -d -t sysupgrade.XX)"
@@ -245,6 +247,15 @@ do_save_conffiles() {
 			\( -exec test -f /overlay/upper/{} \; -exec echo {} overlay \; \) 
-o \

\( -exec echo {} unknown \; \) \
\) | sed -e 's,.*/,,;s/\.control /\t/' > 
${INSTALLED_PACKAGES}
+
+   # Format: /etc/init.d/servicename {enable,disable}
+   rm -f ${SERVICE_STATUS}
+   for service in /etc/init.d/* ; do \
+   ${service} enabled && \
+   echo >> ${SERVICE_STATUS} "$service" "enable" 
|| \
+   echo >> ${SERVICE_STATUS} "$service" "disable" \
+   ; \
+   done
fi

v "Saving config files..."
--
2.20.1


___
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

[PATCH v2] octeon: rename erlite to ubnt,edgerouter-lite

[Stijn Segers]

Rename EdgeRouter Lite board_name value and prefix it with vendor abbreviation
UBNT, as done for other Ubiquiti devices in the tree. Ensure backward sysupgrade
compatibility as well.

Signed-off-by: Stijn Segers 
---
 .../octeon/base-files/lib/preinit/01_sysinfo |  2 +-
 .../octeon/base-files/lib/preinit/79_move_config |  2 +-
 .../octeon/base-files/lib/upgrade/platform.sh| 16 
 target/linux/octeon/image/Makefile   |  1 +
 4 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/target/linux/octeon/base-files/lib/preinit/01_sysinfo 
b/target/linux/octeon/base-files/lib/preinit/01_sysinfo
index d66618b0cf..3512bd7321 100644
--- a/target/linux/octeon/base-files/lib/preinit/01_sysinfo
+++ b/target/linux/octeon/base-files/lib/preinit/01_sysinfo
@@ -6,7 +6,7 @@ do_sysinfo_octeon() {
 
case "$machine" in
"UBNT_E100"*)
-   name="erlite"
+   name="ubnt,edgerouter-lite"
;;
 
"UBNT_E200"*)
diff --git a/target/linux/octeon/base-files/lib/preinit/79_move_config 
b/target/linux/octeon/base-files/lib/preinit/79_move_config
index 5a84e6f18a..07b6585470 100644
--- a/target/linux/octeon/base-files/lib/preinit/79_move_config
+++ b/target/linux/octeon/base-files/lib/preinit/79_move_config
@@ -15,7 +15,7 @@ octeon_move_config() {
. /lib/functions.sh
 
case "$(board_name)" in
-   erlite)
+   ubnt,edgerouter-lite)
move_config "/dev/sda1"
;;
itus,shield-router)
diff --git a/target/linux/octeon/base-files/lib/upgrade/platform.sh 
b/target/linux/octeon/base-files/lib/upgrade/platform.sh
index ad5baef4a1..11e598c10b 100755
--- a/target/linux/octeon/base-files/lib/upgrade/platform.sh
+++ b/target/linux/octeon/base-files/lib/upgrade/platform.sh
@@ -19,11 +19,6 @@ platform_get_rootfs() {
 
 platform_copy_config() {
case "$(board_name)" in
-   erlite)
-   mount -t vfat /dev/sda1 /mnt
-   cp -af "$UPGRADE_BACKUP" "/mnt/$BACKUP_FILE"
-   umount /mnt
-   ;;
itus,shield-router)
mount -t vfat /dev/mmcblk1p1 /mnt
cp -af "$UPGRADE_BACKUP" "/mnt/$BACKUP_FILE"
@@ -34,6 +29,11 @@ platform_copy_config() {
cp -af "$UPGRADE_BACKUP" "/mnt/$BACKUP_FILE"
umount /mnt
;;
+   ubnt,edgerouter-lite)
+   mount -t vfat /dev/sda1 /mnt
+   cp -af "$UPGRADE_BACKUP" "/mnt/$BACKUP_FILE"
+   umount /mnt
+   ;;
esac
 }
 
@@ -87,7 +87,7 @@ platform_do_upgrade() {
ubnt,edgerouter-4)
kernel=mmcblk0p1
;;
-   erlite)
+   ubnt,edgerouter-lite)
kernel=sda1
;;
itus,shield-router)
@@ -112,9 +112,9 @@ platform_check_image() {
 
case "$board" in
er | \
-   erlite | \
itus,shield-router | \
-   ubnt,edgerouter-4)
+   ubnt,edgerouter-4 | \
+   ubnt,edgerouter-lite)
local kernel_length=$(tar xf $tar_file $board_dir/kernel -O | 
wc -c 2> /dev/null)
local rootfs_length=$(tar xf $tar_file $board_dir/root -O | wc 
-c 2> /dev/null)
[ "$kernel_length" = 0 -o "$rootfs_length" = 0 ] && {
diff --git a/target/linux/octeon/image/Makefile 
b/target/linux/octeon/image/Makefile
index b91c262447..83a3274587 100644
--- a/target/linux/octeon/image/Makefile
+++ b/target/linux/octeon/image/Makefile
@@ -71,6 +71,7 @@ define Device/ubnt_edgerouter-lite
   DEVICE_MODEL := EdgeRouter Lite
   BOARD_NAME := erlite
   CMDLINE := $(ERLITE_CMDLINE)
+SUPPORTED_DEVICES := erlite ubnt,edgerouter-lite
 endef
 TARGET_DEVICES += ubnt_edgerouter-lite
 
-- 
2.20.1


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

Re: [PATCH 1/2] octeon: rename erlite to ubnt,erlite

[Stijn Segers]

Hi Roman,

Op vrijdag 8 januari 2021 om 19:31 schreef Roman Kuzmitskii 
:
there is no good way to differentiate between devices in runtime if 
they

  use the same platform.

custom dts would be a better solution in case of edgerouter lite since
  upstream (kernel) already have one for e100 (edgerouter lite).

could we reuse it?



I have no idea if it's possible, but I was thinking about an additional 
DTS that overrides the 'compatible' property. Haven't yet found if this 
is possible at all though, overriding that value.


Stijn



On Jan 8, 2021, at 10:11 PM, Stijn Segers  
wrote:


Hi,

Op vrijdag 8 januari 2021 om 13u29 schreef Adrian Schmutzler 
:

Hi,

-Original Message-
From: openwrt-devel 
[mailto:openwrt-devel-boun...@lists.openwrt.org]

On Behalf Of Stijn Segers
Sent: Freitag, 8. Januar 2021 11:28
To: openwrt-devel@lists.openwrt.org
Subject: [PATCH 1/2] octeon: rename erlite to ubnt,erlite
Prefix EdgeRouter Lite board_name value with vendor abbreviation 
UBNT, as
other Ubiquiti devices do, and use full name "Ubiquiti EdgeRouter 
Lite" as

model value.
If we touch this, please use ubnt,edgerouter-lite to match the 
devices in other targets.


Will do.

I always wanted to do this but never did it because I don't have 
the device to test and breaking sysupgrade was not an option for me 
here.
However, with BOARD_NAME in place I'm not sure whether sysupgrade 
would still break if you also add SUPPORTED_DEVICES properly.


I'll add SUPPORTED_DEVICES to the v2 just to be on the safe side.


Additional comments below.

Signed-off-by: Stijn Segers 
---
 .../octeon/base-files/lib/preinit/01_sysinfo | 10 --
 .../octeon/base-files/lib/preinit/79_move_config |  2 +-
 .../octeon/base-files/lib/upgrade/platform.sh| 16 


 3 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/target/linux/octeon/base-files/lib/preinit/01_sysinfo
b/target/linux/octeon/base-files/lib/preinit/01_sysinfo
index d66618b0cf..497116b2c7 100644
--- a/target/linux/octeon/base-files/lib/preinit/01_sysinfo
+++ b/target/linux/octeon/base-files/lib/preinit/01_sysinfo
@@ -6,7 +6,8 @@ do_sysinfo_octeon() {
case "$machine" in
"UBNT_E100"*)
-   name="erlite"
+   name="ubnt,erlite"
+   model="Ubiquiti EdgeRouter Lite"
;;
"UBNT_E200"*)
@@ -34,7 +35,12 @@ do_sysinfo_octeon() {
[ -e "/tmp/sysinfo/" ] || mkdir -p "/tmp/sysinfo/"
echo "$name" > /tmp/sysinfo/board_name
-   echo "$machine" > /tmp/sysinfo/model
+   if [ -z "$model" ]
+   then
+   echo "$machine" > /tmp/sysinfo/model
+   else
+   echo "$model" > /tmp/sysinfo/model
+   fi
What's the purpose of this change? If it just "adds a friendly 
name" it should probably be separate, as the rest is about changing 
the board_name.


I'll split this out into a separate patch. This is cosmetic indeed, 
so /tmp/sysinfo/model (and LuCI) don't display the architecture as 
'model'. The EdgeRouter 4 e.g. does not suffer from this because it 
uses an external DTS that sets the model value.


I could do the same for the other machine matches, but it looks like 
the UBNT_E[0-9][0-9]0 values are crude indicators of what device 
OpenWrt is running on...


A quick online search gave this:
- UBNT E100: EdgeRouter Lite (ERLite-3), but also EdgeRouter PoE 
(ERPoe-5) e.g.

- UBNT E200: EdgeRouter (ER-8) & EdgeRouter Pro (ERPro-8)
- UBNT E220: UniFi Security Gateway Pro 4 (USG Pro-4), but also 
EdgeRouter


So what's the best way to deduplicate this? A custom DTS per device 
that overrides upstream board_name and model, but inherits the 
remainder of the DTS?


Thanks

Stijn


Best
Adrian

 }
 boot_hook_add preinit_main do_sysinfo_octeon diff --git
a/target/linux/octeon/base-files/lib/preinit/79_move_config
b/target/linux/octeon/base-files/lib/preinit/79_move_config
index 5a84e6f18a..fb917ec39e 100644
--- a/target/linux/octeon/base-files/lib/preinit/79_move_config
+++ b/target/linux/octeon/base-files/lib/preinit/79_move_config
@@ -15,7 +15,7 @@ octeon_move_config() {
. /lib/functions.sh
case "$(board_name)" in
-   erlite)
+   ubnt,erlite)
move_config "/dev/sda1"
;;
itus,shield-router)
diff --git a/target/linux/octeon/base-files/lib/upgrade/platform.sh
b/target/linux/octeon/base-files/lib/upgrade/platform.sh
index ad5baef4a1..5e5f33b719 100755
--- a/target/linux/octeon/base-files/lib/upgrade/platform.sh
+++ b/target/linux/octeon/base-files/lib/upgrade/platform.sh
@@ -19,11 +19,6 @@ platform_get_rootfs() {
 platform_copy_config() {
case "$(board_name)" in
-   erlite)
-   mount -t vfat /dev/sda1 /mnt
-   

RE: [PATCH 2/2] octeon: add EdgeRouter Lite specific network config

[Stijn Segers]

Hi Adrian,

Op vrijdag 8 januari 2021 om 13u30 schreef Adrian Schmutzler 
:

Hi,


 -Original Message-
 From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
 On Behalf Of Stijn Segers
 Sent: Freitag, 8. Januar 2021 11:28
 To: openwrt-devel@lists.openwrt.org
 Subject: [PATCH 2/2] octeon: add EdgeRouter Lite specific network 
config


 The Ubiquiti EdgeRouter Lite has three network interfaces. Add a 
specific

 match in /etc/board.d/01_network so they all get set up.
 Default to eth0 for WAN and an eth1 + eth2 bridge for LAN.


Why this particular assignment?



The EdgeRouter 4 (same Octeon target) uses a similar set-up; the PC 
Engines APU has a similar setup as well: 3 Ethernet ports, eth0 being 
set as WAN - see [2].


I can invert it and set eth2 as WAN port, if you'd like. The fallback 
setup for Octeon at this point is just as weird, to set eth0 as LAN 
(which is logical) and eth1 as WAN, and leave other ports unconfigured.


There's no perfect solution, but I think leaving a port unused makes 
even less sense than this.


Stijn

[1] 
https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/octeon/base-files/etc/board.d/01_network;h=749d99be1d11802fbc442a11b1d3312b806ea9fb;hb=HEAD
[2] 
https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/x86/base-files/etc/board.d/02_network;h=c6e381b946d03887cb941e90db2ccbb2f918fca4;hb=HEAD




Best

Adrian



 Signed-off-by: Stijn Segers 
 ---
  target/linux/octeon/base-files/etc/board.d/01_network | 3 +++
  1 file changed, 3 insertions(+)

 diff --git a/target/linux/octeon/base-files/etc/board.d/01_network
 b/target/linux/octeon/base-files/etc/board.d/01_network
 index 749d99be1d..4ad5f95598 100755
 --- a/target/linux/octeon/base-files/etc/board.d/01_network
 +++ b/target/linux/octeon/base-files/etc/board.d/01_network
 @@ -14,6 +14,9 @@ itus,shield-router)
  ubnt,edgerouter-4)
ucidef_set_interfaces_lan_wan "lan1 lan2 lan3" "lan0"
;;
 +ubnt,erlite)
 +  ucidef_set_interfaces_lan_wan "eth1 eth2" "eth0"
 +  ;;
  *)
ucidef_set_interfaces_lan_wan "eth0" "eth1"
;;
 --
 2.20.1


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

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




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

RE: [PATCH 1/2] octeon: rename erlite to ubnt,erlite

[Stijn Segers]

Hi,

Op vrijdag 8 januari 2021 om 13u29 schreef Adrian Schmutzler 
:

Hi,


 -Original Message-
 From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
 On Behalf Of Stijn Segers
 Sent: Freitag, 8. Januar 2021 11:28
 To: openwrt-devel@lists.openwrt.org
 Subject: [PATCH 1/2] octeon: rename erlite to ubnt,erlite

 Prefix EdgeRouter Lite board_name value with vendor abbreviation 
UBNT, as
 other Ubiquiti devices do, and use full name "Ubiquiti EdgeRouter 
Lite" as

 model value.


If we touch this, please use ubnt,edgerouter-lite to match the 
devices in other targets.


Will do.



I always wanted to do this but never did it because I don't have the 
device to test and breaking sysupgrade was not an option for me here.


However, with BOARD_NAME in place I'm not sure whether sysupgrade 
would still break if you also add SUPPORTED_DEVICES properly.


I'll add SUPPORTED_DEVICES to the v2 just to be on the safe side.



Additional comments below.



 Signed-off-by: Stijn Segers 
 ---
  .../octeon/base-files/lib/preinit/01_sysinfo | 10 --
  .../octeon/base-files/lib/preinit/79_move_config |  2 +-
  .../octeon/base-files/lib/upgrade/platform.sh| 16 


  3 files changed, 17 insertions(+), 11 deletions(-)

 diff --git a/target/linux/octeon/base-files/lib/preinit/01_sysinfo
 b/target/linux/octeon/base-files/lib/preinit/01_sysinfo
 index d66618b0cf..497116b2c7 100644
 --- a/target/linux/octeon/base-files/lib/preinit/01_sysinfo
 +++ b/target/linux/octeon/base-files/lib/preinit/01_sysinfo
 @@ -6,7 +6,8 @@ do_sysinfo_octeon() {

case "$machine" in
"UBNT_E100"*)
 -  name="erlite"
 +  name="ubnt,erlite"
 +  model="Ubiquiti EdgeRouter Lite"
;;

"UBNT_E200"*)
 @@ -34,7 +35,12 @@ do_sysinfo_octeon() {
[ -e "/tmp/sysinfo/" ] || mkdir -p "/tmp/sysinfo/"

echo "$name" > /tmp/sysinfo/board_name
 -  echo "$machine" > /tmp/sysinfo/model
 +  if [ -z "$model" ]
 +  then
 +  echo "$machine" > /tmp/sysinfo/model
 +  else
 +  echo "$model" > /tmp/sysinfo/model
 +  fi


What's the purpose of this change? If it just "adds a friendly name" 
it should probably be separate, as the rest is about changing the 
board_name.




I'll split this out into a separate patch. This is cosmetic indeed, so 
/tmp/sysinfo/model (and LuCI) don't display the architecture as 
'model'. The EdgeRouter 4 e.g. does not suffer from this because it 
uses an external DTS that sets the model value.


I could do the same for the other machine matches, but it looks like 
the UBNT_E[0-9][0-9]0 values are crude indicators of what device 
OpenWrt is running on...


A quick online search gave this:
- UBNT E100: EdgeRouter Lite (ERLite-3), but also EdgeRouter PoE 
(ERPoe-5) e.g.

- UBNT E200: EdgeRouter (ER-8) & EdgeRouter Pro (ERPro-8)
- UBNT E220: UniFi Security Gateway Pro 4 (USG Pro-4), but also 
EdgeRouter


So what's the best way to deduplicate this? A custom DTS per device 
that overrides upstream board_name and model, but inherits the 
remainder of the DTS?


Thanks

Stijn


Best

Adrian


  }

  boot_hook_add preinit_main do_sysinfo_octeon diff --git
 a/target/linux/octeon/base-files/lib/preinit/79_move_config
 b/target/linux/octeon/base-files/lib/preinit/79_move_config
 index 5a84e6f18a..fb917ec39e 100644
 --- a/target/linux/octeon/base-files/lib/preinit/79_move_config
 +++ b/target/linux/octeon/base-files/lib/preinit/79_move_config
 @@ -15,7 +15,7 @@ octeon_move_config() {
. /lib/functions.sh

case "$(board_name)" in
 -  erlite)
 +  ubnt,erlite)
move_config "/dev/sda1"
;;
itus,shield-router)
 diff --git a/target/linux/octeon/base-files/lib/upgrade/platform.sh
 b/target/linux/octeon/base-files/lib/upgrade/platform.sh
 index ad5baef4a1..5e5f33b719 100755
 --- a/target/linux/octeon/base-files/lib/upgrade/platform.sh
 +++ b/target/linux/octeon/base-files/lib/upgrade/platform.sh
 @@ -19,11 +19,6 @@ platform_get_rootfs() {

  platform_copy_config() {
case "$(board_name)" in
 -  erlite)
 -  mount -t vfat /dev/sda1 /mnt
 -  cp -af "$UPGRADE_BACKUP" "/mnt/$BACKUP_FILE"
 -  umount /mnt
 -  ;;
itus,shield-router)
mount -t vfat /dev/mmcblk1p1 /mnt
cp -af "$UPGRADE_BACKUP" "/mnt/$BACKUP_FILE"
 @@ -34,6 +29,11 @@ platform_copy_config() {
cp -af "$UPGRADE_BACKUP" "/mnt/$BACKUP_FILE"
umount /mnt
;;
 +  ubnt,erlite)
 +  mount -t vfat /dev/sda1 /mnt
 +  cp -af &quo

Re: [PATCH v5 2/2] realtek: add support for ZyXEL GS1900-8HP v1 and v2

[Stijn Segers]

Hi,

Op vrijdag 8 januari 2021 om 16u19 schreef Sander Vanheule 
:

Hi Stijn,

On Fri, 2021-01-08 at 14:32 +0100, Stijn Segers wrote:

 diff --git a/target/linux/realtek/image/Makefile
 b/target/linux/realtek/image/Makefile
 index 765e516a0a..39b28b6c67 100644
 --- a/target/linux/realtek/image/Makefile
 +++ b/target/linux/realtek/image/Makefile
 @@ -65,11 +65,33 @@ define Device/netgear_gs110tpp-v1
  endef
  TARGET_DEVICES += netgear_gs110tpp-v1

 -define Device/zyxel_gs1900-10hp
 +define Device/zyxel_gs1900
SOC := rtl8380


There are also GS1900 models with a RTL8382M (24 ports), or RTL8393M
(48 ports) SoC, so maybe 'Device/zyxel_gs1900' is a bit too broad 
here.

You've used 'rtl8380_zyxel_gs1900' for the DTSI, would something
similar be an option here?


Smart thinking!

Adrian, what is your take on this? Should I rename the 'base recipe' to 
rtl8380_zyxel_gs1900?


We could also do something like zyxel_gs1900_lower, since it's the 
lower segment of the range?


I'm all ears :-)

Stijn



Best,
Sander



___
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

[PATCH v5 2/2] realtek: add support for ZyXEL GS1900-8HP v1 and v2

[Stijn Segers]

The ZyXEL GS1900-8HP is an 8 port gigabit switch with PoE+ support.
There are two versions on the market (v1 & v2) which share similar
specs (same flash size and flash layout, same RAM size, same PoE+ power
envelope) but have a different case and board layout that they each
share with other GS1900 siblings.

The v1 seems to share its PCB and case with non-PoE GS1900-8; as such,
adding support for the GS1900-8 would probably be trivial. The v2 seems
to share its casing and platform with its already supported bigger
brother, the GS1900-10HP - its board looks the same, except for two
holes where the GS1900-10 has its SFP ports.

Like their 10 port sibling, both devices have a dual firmware layout.
Both GS1900-8HP boards have the same 70W PoE+ power budget. In order to
manipulate the PoE+, one needs the rtl83xx-poe package [1].

After careful consideration it was decided to go with separate images
for each version.

Specifications (v1)
---
* SoC:   Realtek RTL8380M 500 MHz MIPS 4KEc
* Flash: Macronix MX25L12835F 16 MiB
* RAM:   Nanya NT5TU128M8HE-AC 128 MiB DDR2 SDRAM
* Ethernet:  8x 10/100/1000 Mbit
* PoE+:  Broadcom BCM59111KMLG (IEEE 802.3at-2009 compliant, 2x)
* UART:  1 serial header with populated standard pin connector on the
 left side of the PCB, towards the bottom. Pins are labeled:
 + VCC (3.3V)
 + TX
 + RX
 + GND

Specifications (v2)
---
* SoC:   Realtek RTL8380M 500 MHz MIPS 4KEc
* Flash: Macronix MX25L12835F 16 MiB
* RAM:   Samsung K4B1G0846G 128 MiB DDR3 SDRAM
* Ethernet:  8x 10/100/1000 Mbit
* PoE+:  Broadcom BCM59121B0KMLG (IEEE 802.3at-2009 compliant)
* UART:  1 angled serial header with populated standard pin connector
 accessible from outside through the ventilation slits on the
 side. Pins from top to bottom are clearly marked on the PCB:
 + VCC (3.3V)
 + TX
 + RX
 + GND

Serial connection parameters for both devices: 115200 8N1.

Installation

Instructions are identical to those for the GS1900-10HP and apply both
to the GS1900-8HP v1 and v2 as well.

* Configure your client with a static 192.168.1.x IP (e.g. 192.168.1.10).
* Set up a TFTP server on your client and make it serve the initramfs
  image.
* Connect serial, power up the switch, interrupt U-boot by hitting the
  space bar, and enable the network:
  # rtk network on
* Since the GS1900-10HP is a dual-partition device, you want to keep the
  OEM firmware on the backup partition for the time being. OpenWrt can
  only boot off the first partition anyway (hardcoded in the DTS). To
  make sure we are manipulating the first partition, issue the following
  commands:
  # setsys bootpartition 0
  # savesys
* Download the image onto the device and boot from it:
  # tftpboot 0x84f0 
192.168.1.10:openwrt-realtek-generic-zyxel_gs1900-8hp-v{1,2}-initramfs-kernel.bin
  # bootm
* Once OpenWrt has booted, scp the sysupgrade image to /tmp and flash it:
  # sysupgrade 
/tmp//tmp/openwrt-realtek-generic-zyxel_gs1900-8hp-v{1,2}-squashfs-sysupgrade.bin

Signed-off-by: Stijn Segers 
---
 .../realtek/base-files/etc/board.d/02_network |  6 +
 .../dts/rtl8380_zyxel_gs1900-8hp-v1.dts   |  8 +++
 .../dts/rtl8380_zyxel_gs1900-8hp-v2.dts   |  8 +++
 target/linux/realtek/image/Makefile   | 24 ++-
 4 files changed, 45 insertions(+), 1 deletion(-)
 create mode 100644 target/linux/realtek/dts/rtl8380_zyxel_gs1900-8hp-v1.dts
 create mode 100644 target/linux/realtek/dts/rtl8380_zyxel_gs1900-8hp-v2.dts

diff --git a/target/linux/realtek/base-files/etc/board.d/02_network 
b/target/linux/realtek/base-files/etc/board.d/02_network
index 84fefa536d..cc8beb1c95 100755
--- a/target/linux/realtek/base-files/etc/board.d/02_network
+++ b/target/linux/realtek/base-files/etc/board.d/02_network
@@ -52,6 +52,12 @@ case $board in
 netgear,gs110tpp-v1)
ucidef_set_poe 130 "$lan_list"
;;
+zyxel,gs1900-8hp-v1)
+   ucidef_set_poe 70 "$lan_list"
+   ;;
+zyxel,gs1900-8hp-v2)
+   ucidef_set_poe 70 "$lan_list"
+   ;;
 zyxel,gs1900-10hp)
ucidef_set_poe 77 "$lan_list"
;;
diff --git a/target/linux/realtek/dts/rtl8380_zyxel_gs1900-8hp-v1.dts 
b/target/linux/realtek/dts/rtl8380_zyxel_gs1900-8hp-v1.dts
new file mode 100644
index 00..0d9b7c97c0
--- /dev/null
+++ b/target/linux/realtek/dts/rtl8380_zyxel_gs1900-8hp-v1.dts
@@ -0,0 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+
+#include "rtl8380_zyxel_gs1900.dtsi"
+
+/ {
+   compatible = "zyxel,gs1900-8hp-v1", "realtek,rtl838x-soc";
+   model = "ZyXEL GS1900-8HP v1 Switch";
+};
diff --git a/target/linux/realtek/dts/rtl8380_zyxel_gs1900-8hp-v2.dts 
b/target/linux/realtek/dts/rtl8380_zyxel_gs1900-8hp-v2.dts
new file m

[PATCH v5 0/2] Add GS1900-8HP v1/v2 support and GS1900 DTSI

[Stijn Segers]

Hi Adrian, 

This should be the final round. Run-tested on a GS1900-10HP. It's still
alive :-).

Thank you!

Stijn

Stijn Segers (2):
  realtek: introduce shared DTSI for GS1900 series
  realtek: add support for ZyXEL GS1900-8HP v1 and v2

 .../realtek/base-files/etc/board.d/02_network |   6 +
 .../realtek/dts/rtl8380_zyxel_gs1900-10hp.dts | 233 +-
 .../dts/rtl8380_zyxel_gs1900-8hp-v1.dts   |   8 +
 .../dts/rtl8380_zyxel_gs1900-8hp-v2.dts   |   8 +
 .../realtek/dts/rtl8380_zyxel_gs1900.dtsi | 146 +++
 target/linux/realtek/image/Makefile   |  24 +-
 6 files changed, 196 insertions(+), 229 deletions(-)
 create mode 100644 target/linux/realtek/dts/rtl8380_zyxel_gs1900-8hp-v1.dts
 create mode 100644 target/linux/realtek/dts/rtl8380_zyxel_gs1900-8hp-v2.dts
 create mode 100644 target/linux/realtek/dts/rtl8380_zyxel_gs1900.dtsi

-- 
2.20.1


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

[PATCH v5 1/2] realtek: introduce shared DTSI for GS1900 series

[Stijn Segers]

The ZyXEL GS1900-8HP v1, v2 and GS1900-10HP are all built on a similar
Realtek RTL8380M platform. Create a common DTSI in preparation for
GS1900-8HP support, and switch to the macros defined in rtl838x.dtsi.

Signed-off-by: Stijn Segers 
---
 .../realtek/dts/rtl8380_zyxel_gs1900-10hp.dts | 233 +-
 .../realtek/dts/rtl8380_zyxel_gs1900.dtsi | 146 +++
 2 files changed, 151 insertions(+), 228 deletions(-)
 create mode 100644 target/linux/realtek/dts/rtl8380_zyxel_gs1900.dtsi

diff --git a/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts 
b/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts
index b114cb6b5a..58c387d053 100644
--- a/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts
+++ b/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0-or-later
 
-#include "rtl838x.dtsi"
+#include "rtl8380_zyxel_gs1900.dtsi"
 
 #include 
 #include 
@@ -9,52 +9,6 @@
compatible = "zyxel,gs1900-10hp", "realtek,rtl838x-soc";
model = "ZyXEL GS1900-10HP Switch";
 
-   aliases {
-   led-boot = _sys;
-   led-failsafe = _sys;
-   led-running = _sys;
-   led-upgrade = _sys;
-   };
-
-   chosen {
-   bootargs = "console=ttyS0,115200";
-   };
-
-   memory@0 {
-   device_type = "memory";
-   reg = <0x0 0x800>;
-   };
-
-   gpio1: rtl8231-gpio {
-   status = "okay";
-
-   poe_enable {
-   gpio-hog;
-   gpios = <13 0>;
-   output-high;
-   };
-   };
-
-   keys {
-   compatible = "gpio-keys-polled";
-   poll-interval = <20>;
-
-   reset {
-   label = "reset";
-   gpios = < 3 GPIO_ACTIVE_LOW>;
-   linux,code = ;
-   };
-   };
-
-   leds {
-   compatible = "gpio-leds";
-
-   led_sys: sys {
-   label = "gs1900:green:sys";
-   gpios = < 47 GPIO_ACTIVE_HIGH>;
-   };
-   };
-
/* i2c of the left SFP cage: port 9 */
i2c0: i2c-gpio-0 {
compatible = "i2c-gpio";
@@ -92,195 +46,18 @@
mod-def0-gpio = < 32 GPIO_ACTIVE_LOW>;
tx-disable-gpio = < 29 GPIO_ACTIVE_HIGH>;
};
-
-};
-
- {
-   status = "okay";
-   flash@0 {
-   compatible = "jedec,spi-nor";
-   reg = <0>;
-   spi-max-frequency = <1000>;
-
-   partitions {
-   compatible = "fixed-partitions";
-   #address-cells = <1>;
-   #size-cells = <1>;
-
-   partition@0 {
-   label = "u-boot";
-   reg = <0x0 0x4>;
-   read-only;
-   };
-   partition@4 {
-   label = "u-boot-env";
-   reg = <0x4 0x1>;
-   read-only;
-   };
-   partition@5 {
-   label = "u-boot-env2";
-   reg = <0x5 0x1>;
-   read-only;
-   };
-   partition@6 {
-   label = "jffs";
-   reg = <0x6 0x10>;
-   };
-   partition@16 {
-   label = "jffs2";
-   reg = <0x16 0x10>;
-   };
-   partition@b26 {
-   label = "firmware";
-   reg = <0x26 0x6d>;
-   compatible = "denx,uimage";
-   };
-   partition@93 {
-   label = "runtime2";
-   reg = <0x93 0x6d>;
-   };
-   };
-   };
 };
 
  {
mdio: mdio-bus {
-   compatible = "realtek,rtl838x-mdio";
-   regmap = <>;
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   /* Internal phy */
-   phy8: ethernet-phy@8 {
-   reg = <8>;
-

[PATCH 1/2] octeon: rename erlite to ubnt,erlite

[Stijn Segers]

Prefix EdgeRouter Lite board_name value with vendor abbreviation UBNT, as other 
Ubiquiti
devices do, and use full name "Ubiquiti EdgeRouter Lite" as model value.

Signed-off-by: Stijn Segers 
---
 .../octeon/base-files/lib/preinit/01_sysinfo | 10 --
 .../octeon/base-files/lib/preinit/79_move_config |  2 +-
 .../octeon/base-files/lib/upgrade/platform.sh| 16 
 3 files changed, 17 insertions(+), 11 deletions(-)

diff --git a/target/linux/octeon/base-files/lib/preinit/01_sysinfo 
b/target/linux/octeon/base-files/lib/preinit/01_sysinfo
index d66618b0cf..497116b2c7 100644
--- a/target/linux/octeon/base-files/lib/preinit/01_sysinfo
+++ b/target/linux/octeon/base-files/lib/preinit/01_sysinfo
@@ -6,7 +6,8 @@ do_sysinfo_octeon() {
 
case "$machine" in
"UBNT_E100"*)
-   name="erlite"
+   name="ubnt,erlite"
+   model="Ubiquiti EdgeRouter Lite"
;;
 
"UBNT_E200"*)
@@ -34,7 +35,12 @@ do_sysinfo_octeon() {
[ -e "/tmp/sysinfo/" ] || mkdir -p "/tmp/sysinfo/"
 
echo "$name" > /tmp/sysinfo/board_name
-   echo "$machine" > /tmp/sysinfo/model
+   if [ -z "$model" ]
+   then
+   echo "$machine" > /tmp/sysinfo/model
+   else
+   echo "$model" > /tmp/sysinfo/model
+   fi
 }
 
 boot_hook_add preinit_main do_sysinfo_octeon
diff --git a/target/linux/octeon/base-files/lib/preinit/79_move_config 
b/target/linux/octeon/base-files/lib/preinit/79_move_config
index 5a84e6f18a..fb917ec39e 100644
--- a/target/linux/octeon/base-files/lib/preinit/79_move_config
+++ b/target/linux/octeon/base-files/lib/preinit/79_move_config
@@ -15,7 +15,7 @@ octeon_move_config() {
. /lib/functions.sh
 
case "$(board_name)" in
-   erlite)
+   ubnt,erlite)
move_config "/dev/sda1"
;;
itus,shield-router)
diff --git a/target/linux/octeon/base-files/lib/upgrade/platform.sh 
b/target/linux/octeon/base-files/lib/upgrade/platform.sh
index ad5baef4a1..5e5f33b719 100755
--- a/target/linux/octeon/base-files/lib/upgrade/platform.sh
+++ b/target/linux/octeon/base-files/lib/upgrade/platform.sh
@@ -19,11 +19,6 @@ platform_get_rootfs() {
 
 platform_copy_config() {
case "$(board_name)" in
-   erlite)
-   mount -t vfat /dev/sda1 /mnt
-   cp -af "$UPGRADE_BACKUP" "/mnt/$BACKUP_FILE"
-   umount /mnt
-   ;;
itus,shield-router)
mount -t vfat /dev/mmcblk1p1 /mnt
cp -af "$UPGRADE_BACKUP" "/mnt/$BACKUP_FILE"
@@ -34,6 +29,11 @@ platform_copy_config() {
cp -af "$UPGRADE_BACKUP" "/mnt/$BACKUP_FILE"
umount /mnt
;;
+   ubnt,erlite)
+   mount -t vfat /dev/sda1 /mnt
+   cp -af "$UPGRADE_BACKUP" "/mnt/$BACKUP_FILE"
+   umount /mnt
+   ;;
esac
 }
 
@@ -87,7 +87,7 @@ platform_do_upgrade() {
ubnt,edgerouter-4)
kernel=mmcblk0p1
;;
-   erlite)
+   ubnt,erlite)
kernel=sda1
;;
itus,shield-router)
@@ -112,9 +112,9 @@ platform_check_image() {
 
case "$board" in
er | \
-   erlite | \
itus,shield-router | \
-   ubnt,edgerouter-4)
+   ubnt,edgerouter-4 | \
+   ubnt,erlite)
local kernel_length=$(tar xf $tar_file $board_dir/kernel -O | 
wc -c 2> /dev/null)
local rootfs_length=$(tar xf $tar_file $board_dir/root -O | wc 
-c 2> /dev/null)
[ "$kernel_length" = 0 -o "$rootfs_length" = 0 ] && {
-- 
2.20.1


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

[RFC] Octeon: EdgeRouter Lite fixes

[Stijn Segers]

These patches align the EdgeRouter Lite device with modern OpenWrt
practices:
- Use vendor prefix for board_name: ubnt,erlite instead of erlite.
- Set the model to "Ubiquiti EdgeRouter Lite".
- Add an EdgeRouter Lite match in /etc/board.d/01_network so all
  network interfaces get configured: eth0 as WAN, eth1 and eth2 as a LAN
  bridge. This is similar to what is done for the PC Engines APU line
  and for the Ubiquiti EdgeRouter 4 (also octeon).

I've made this an RFC because of the hackish way I set the model,
but I think this is the cleanest way to do it (short of overwriting the
machine variable altogether). Also, lots of Ubiquiti devices seem to use
shortened codenames in board_name, but recent addition EdgeRouter 4 e.g.
does not, so I'm not sure what's best practice here. It doesn't look
like the codenames are needed for anything?

This will of course break sysupgrade, but since the default network
layout changes, I'm not sure if we want to keep compatibility?

Thanks

Stijn



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

[PATCH 2/2] octeon: add EdgeRouter Lite specific network config

[Stijn Segers]

The Ubiquiti EdgeRouter Lite has three network interfaces. Add a
specific match in /etc/board.d/01_network so they all get set up.
Default to eth0 for WAN and an eth1 + eth2 bridge for LAN.

Signed-off-by: Stijn Segers 
---
 target/linux/octeon/base-files/etc/board.d/01_network | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/target/linux/octeon/base-files/etc/board.d/01_network 
b/target/linux/octeon/base-files/etc/board.d/01_network
index 749d99be1d..4ad5f95598 100755
--- a/target/linux/octeon/base-files/etc/board.d/01_network
+++ b/target/linux/octeon/base-files/etc/board.d/01_network
@@ -14,6 +14,9 @@ itus,shield-router)
 ubnt,edgerouter-4)
ucidef_set_interfaces_lan_wan "lan1 lan2 lan3" "lan0"
;;
+ubnt,erlite)
+   ucidef_set_interfaces_lan_wan "eth1 eth2" "eth0"
+   ;;
 *)
ucidef_set_interfaces_lan_wan "eth0" "eth1"
;;
-- 
2.20.1


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

[PATCH 1/2] realtek: introduce shared DTSI for GS1900-HP series

[Stijn Segers]

The ZyXEL GS1900-8HP v1, v2 and GS1900-10HP are all built on a similar
Realtek RTL8380M platform. Create a common DTSI in preparation for
GS1900-8HP support, and switch to the macros defined in rtl838x.dtsi.

Signed-off-by: Stijn Segers 
---
 .../realtek/dts/rtl8380_zyxel_gs1900-10hp.dts | 189 +-
 .../realtek/dts/rtl8380_zyxel_gs1900.dtsi | 147 ++
 2 files changed, 151 insertions(+), 185 deletions(-)
 create mode 100644 target/linux/realtek/dts/rtl8380_zyxel_gs1900.dtsi

diff --git a/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts 
b/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts
index b114cb6b5a..5c53385020 100644
--- a/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts
+++ b/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts
@@ -20,11 +20,6 @@
bootargs = "console=ttyS0,115200";
};
 
-   memory@0 {
-   device_type = "memory";
-   reg = <0x0 0x800>;
-   };
-
gpio1: rtl8231-gpio {
status = "okay";
 
@@ -95,192 +90,16 @@
 
 };
 
- {
-   status = "okay";
-   flash@0 {
-   compatible = "jedec,spi-nor";
-   reg = <0>;
-   spi-max-frequency = <1000>;
-
-   partitions {
-   compatible = "fixed-partitions";
-   #address-cells = <1>;
-   #size-cells = <1>;
-
-   partition@0 {
-   label = "u-boot";
-   reg = <0x0 0x4>;
-   read-only;
-   };
-   partition@4 {
-   label = "u-boot-env";
-   reg = <0x4 0x1>;
-   read-only;
-   };
-   partition@5 {
-   label = "u-boot-env2";
-   reg = <0x5 0x1>;
-   read-only;
-   };
-   partition@6 {
-   label = "jffs";
-   reg = <0x6 0x10>;
-   };
-   partition@16 {
-   label = "jffs2";
-   reg = <0x16 0x10>;
-   };
-   partition@b26 {
-   label = "firmware";
-   reg = <0x26 0x6d>;
-   compatible = "denx,uimage";
-   };
-   partition@93 {
-   label = "runtime2";
-   reg = <0x93 0x6d>;
-   };
-   };
-   };
-};
-
  {
mdio: mdio-bus {
-   compatible = "realtek,rtl838x-mdio";
-   regmap = <>;
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   /* Internal phy */
-   phy8: ethernet-phy@8 {
-   reg = <8>;
-   compatible = "ethernet-phy-ieee802.3-c22";
-   };
-   phy9: ethernet-phy@9 {
-   reg = <9>;
-   compatible = "ethernet-phy-ieee802.3-c22";
-   };
-   phy10: ethernet-phy@10 {
-   reg = <10>;
-   compatible = "ethernet-phy-ieee802.3-c22";
-   };
-   phy11: ethernet-phy@11 {
-   reg = <11>;
-   compatible = "ethernet-phy-ieee802.3-c22";
-   };
-   phy12: ethernet-phy@12 {
-   reg = <12>;
-   compatible = "ethernet-phy-ieee802.3-c22";
-   };
-   phy13: ethernet-phy@13 {
-   reg = <13>;
-   compatible = "ethernet-phy-ieee802.3-c22";
-   };
-   phy14: ethernet-phy@14 {
-   reg = <14>;
-   compatible = "ethernet-phy-ieee802.3-c22";
-   };
-   phy15: ethernet-phy@15 {
-   reg = <15>;
-   compatible = "ethernet-phy-ieee802.3-c22";
-   };
-   phy24: ethernet-phy@24 {
-   compatible = "ethernet-phy-ieee802.3-c22";
-   reg = <24>;
-   };
- 

RE: [PATCH 4/5] realtek: introduce shared DTSI for GS1900-HP series

[Stijn Segers]

Hi Adrian,

Op donderdag 7 januari 2021 om 19:54 schreef Adrian Schmutzler 
:

Hi,


 -Original Message-
 From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
 On Behalf Of Stijn Segers
 Sent: Mittwoch, 6. Januar 2021 22:45
 To: openwrt-devel@lists.openwrt.org
 Subject: [PATCH 4/5] realtek: introduce shared DTSI for GS1900-HP 
series


 The ZyXEL GS1900-8HP v1, v2 and GS1900-10HP are all built on a 
similar

 Realtek RTL8380M platform. Create a common DTSI in preparation for
 GS1900-8HP support, and switch to the macros defined in 
rtl838x.dtsi.


I've merged 1 to 3 with minor adjustments/fixes, but for this one the 
removed and added sections don't match at all.


I think your shuffling around the memory blocks (rightfully so) and the 
fact my patches already had some dts-v1 lines removed might have been a 
factor in that?


Have sent in a v4 for the remaining two patches :-)

Thank you

Stijn



Please fix/rebase (and also changed the DTSI include in the DTS).

Best

Adrian



 Signed-off-by: Stijn Segers 
 ---
  .../realtek/dts/rtl8380_zyxel_gs1900-10hp.dts | 190 
+-

  .../realtek/dts/rtl8380_zyxel_gs1900.dtsi | 147 ++
  2 files changed, 151 insertions(+), 186 deletions(-)  create mode 
100644

 target/linux/realtek/dts/rtl8380_zyxel_gs1900.dtsi

 diff --git a/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts
 b/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts
 index 0fb78926d9..5c53385020 100644
 --- a/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts
 +++ b/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts
 @@ -1,5 +1,4 @@
  // SPDX-License-Identifier: GPL-2.0-or-later -/dts-v1/;

  #include "rtl838x.dtsi"

 @@ -10,11 +9,6 @@
compatible = "zyxel,gs1900-10hp", "realtek,rtl838x-soc";
model = "ZyXEL GS1900-10HP Switch";

 -  memory@0 {
 -  device_type = "memory";
 -  reg = <0x0 0x800>;
 -  };
 -
aliases {
led-boot = _sys;
led-failsafe = _sys;
 @@ -96,192 +90,16 @@

  };

 - {
 -  status = "okay";
 -  flash@0 {
 -  compatible = "jedec,spi-nor";
 -  reg = <0>;
 -  spi-max-frequency = <1000>;
 -
 -  partitions {
 -  compatible = "fixed-partitions";
 -  #address-cells = <1>;
 -  #size-cells = <1>;
 -
 -  partition@0 {
 -  label = "u-boot";
 -  reg = <0x0 0x4>;
 -  read-only;
 -  };
 -  partition@4 {
 -  label = "u-boot-env";
 -  reg = <0x4 0x1>;
 -  read-only;
 -  };
 -  partition@5 {
 -  label = "u-boot-env2";
 -  reg = <0x5 0x1>;
 -  read-only;
 -  };
 -  partition@6 {
 -  label = "jffs";
 -  reg = <0x6 0x10>;
 -  };
 -  partition@16 {
 -  label = "jffs2";
 -  reg = <0x16 0x10>;
 -  };
 -  partition@b26 {
 -  label = "firmware";
 -  reg = <0x26 0x6d>;
 -  compatible = "denx,uimage";
 -  };
 -  partition@93 {
 -  label = "runtime2";
 -  reg = <0x93 0x6d>;
 -  };
 -  };
 -  };
 -};
 -
   {
mdio: mdio-bus {
 -  compatible = "realtek,rtl838x-mdio";
 -  regmap = <>;
 -  #address-cells = <1>;
 -  #size-cells = <0>;
 -
 -  /* Internal phy */
 -  phy8: ethernet-phy@8 {
 -  reg = <8>;
 -  compatible = "ethernet-phy-ieee802.3-c22";
 -  };
 -  phy9: ethernet-phy@9 {
 -  reg = <9>;
 -  compatible = "ethernet-phy-ieee802.3-c22";
 -  };
 -  phy10: ethernet-phy@10 {
 -  reg = <10>;
 -  compatible = "ethernet-phy-ieee802.3-c22";
 -  };
 -  phy11: ethernet-phy@11 {
 - 

[PATCH 2/2] realtek: add support for ZyXEL GS1900-8HP v1 and v2

[Stijn Segers]

The ZyXEL GS1900-8HP is an 8 port gigabit switch with PoE+ support.
There are two versions on the market (v1 & v2) which share similar
specs (same flash size and flash layout, same RAM size, same PoE+ power
envelope) but have a different case and board layout that they each
share with other GS1900 siblings.

The v1 seems to share its PCB and case with non-PoE GS1900-8; as such,
adding support for the GS1900-8 would probably be trivial. The v2 seems
to share its casing and platform with its already supported bigger
brother, the GS1900-10HP - its board looks the same, except for two
holes where the GS1900-10 has its SFP ports.

Like their 10 port sibling, both devices have a dual firmware layout.
Both GS1900-8HP boards have the same 70W PoE+ power budget. In order to
manipulate the PoE+, one needs the rtl83xx-poe package [1].

After careful consideration it was decided to go with separate images
for each version.

Specifications (v1)
---
* SoC:   Realtek RTL8380M 500 MHz MIPS 4KEc
* Flash: Macronix MX25L12835F 16 MiB
* RAM:   Nanya NT5TU128M8HE-AC 128 MiB DDR2 SDRAM
* Ethernet:  8x 10/100/1000 Mbit
* PoE+:  Broadcom BCM59111KMLG (IEEE 802.3at-2009 compliant, 2x)
* UART:  1 serial header with populated standard pin connector on the
 left side of the PCB, towards the bottom. Pins are labeled:
 + VCC (3.3V)
 + TX
 + RX
 + GND

Specifications (v2)
---
* SoC:   Realtek RTL8380M 500 MHz MIPS 4KEc
* Flash: Macronix MX25L12835F 16 MiB
* RAM:   Samsung K4B1G0846G 128 MiB DDR3 SDRAM
* Ethernet:  8x 10/100/1000 Mbit
* PoE+:  Broadcom BCM59121B0KMLG (IEEE 802.3at-2009 compliant)
* UART:  1 angled serial header with populated standard pin connector
 accessible from outside through the ventilation slits on the
 side. Pins from top to bottom are clearly marked on the PCB:
 + VCC (3.3V)
 + TX
 + RX
 + GND

Serial connection parameters for both devices: 115200 8N1.

Installation

Instructions are identical to those for the GS1900-10HP and apply both
to the GS1900-8HP v1 and v2 as well.

* Configure your client with a static 192.168.1.x IP (e.g. 192.168.1.10).
* Set up a TFTP server on your client and make it serve the initramfs
  image.
* Connect serial, power up the switch, interrupt U-boot by hitting the
  space bar, and enable the network:
  # rtk network on
* Since the GS1900-10HP is a dual-partition device, you want to keep the
  OEM firmware on the backup partition for the time being. OpenWrt can
  only boot off the first partition anyway (hardcoded in the DTS). To
  make sure we are manipulating the first partition, issue the following
  commands:
  # setsys bootpartition 0
  # savesys
* Download the image onto the device and boot from it:
  # tftpboot 0x84f0 
192.168.1.10:openwrt-realtek-generic-zyxel_gs1900-8hp-v{1,2}-initramfs-kernel.bin
  # bootm
* Once OpenWrt has booted, scp the sysupgrade image to /tmp and flash it:
  # sysupgrade 
/tmp//tmp/openwrt-realtek-generic-zyxel_gs1900-8hp-v{1,2}-squashfs-sysupgrade.bin

Signed-off-by: Stijn Segers 
---
 .../realtek/base-files/etc/board.d/02_network |  6 +
 .../dts/rtl8380_zyxel_gs1900-8hp-v1.dts   |  8 +++
 .../dts/rtl8380_zyxel_gs1900-8hp-v2.dts   |  8 +++
 target/linux/realtek/image/Makefile   | 24 ++-
 4 files changed, 45 insertions(+), 1 deletion(-)
 create mode 100644 target/linux/realtek/dts/rtl8380_zyxel_gs1900-8hp-v1.dts
 create mode 100644 target/linux/realtek/dts/rtl8380_zyxel_gs1900-8hp-v2.dts

diff --git a/target/linux/realtek/base-files/etc/board.d/02_network 
b/target/linux/realtek/base-files/etc/board.d/02_network
index 84fefa536d..cc8beb1c95 100755
--- a/target/linux/realtek/base-files/etc/board.d/02_network
+++ b/target/linux/realtek/base-files/etc/board.d/02_network
@@ -52,6 +52,12 @@ case $board in
 netgear,gs110tpp-v1)
ucidef_set_poe 130 "$lan_list"
;;
+zyxel,gs1900-8hp-v1)
+   ucidef_set_poe 70 "$lan_list"
+   ;;
+zyxel,gs1900-8hp-v2)
+   ucidef_set_poe 70 "$lan_list"
+   ;;
 zyxel,gs1900-10hp)
ucidef_set_poe 77 "$lan_list"
;;
diff --git a/target/linux/realtek/dts/rtl8380_zyxel_gs1900-8hp-v1.dts 
b/target/linux/realtek/dts/rtl8380_zyxel_gs1900-8hp-v1.dts
new file mode 100644
index 00..0d9b7c97c0
--- /dev/null
+++ b/target/linux/realtek/dts/rtl8380_zyxel_gs1900-8hp-v1.dts
@@ -0,0 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+
+#include "rtl8380_zyxel_gs1900.dtsi"
+
+/ {
+   compatible = "zyxel,gs1900-8hp-v1", "realtek,rtl838x-soc";
+   model = "ZyXEL GS1900-8HP v1 Switch";
+};
diff --git a/target/linux/realtek/dts/rtl8380_zyxel_gs1900-8hp-v2.dts 
b/target/linux/realtek/dts/rtl8380_zyxel_gs1900-8hp-v2.dts
new file m

RE: [PATCH 3/3] realtek: add support for ZyXEL GS1900-8HP.

[Stijn Segers]

.
 >>  >>  * Connect serial, power up the switch, interrupt U-boot by
 >> hitting  >> the
 >>  >>space bar, and enable the network:
 >>  >># rtk network on
 >>  >>  * Since the GS1900-10HP is a dual-partition device, you 
want to

 >> keep  >> the
 >>  >>OEM firmware on the backup partition for the time being.
 >> OpenWrt
 >>  >> can
 >>  >>only boot off the first partition anyway (hardcoded in the
 >> DTS).
 >>  >> To
 >>  >>make sure we are manipulating the first partition, issue 
the

 >>  >> following
 >>  >>commands:
 >>  >># setsys bootpartition 0
 >>  >># savesys
 >>  >>  * Download the image onto the device and boot from it:
 >>  >># tftpboot 0x84f0
 >>  >> 192.168.1.10:openwrt-realtek-generic-zyxel_gs1900-
 >>  >>  8hp-initramfs-kernel.bin
 >>  >># bootm
 >>  >>  * Once OpenWrt has booted, scp the sysupgrade image to /tmp 
and

 >> >> flash it:
 >>  >># sysupgrade
 >> /tmp//tmp/openwrt-realtek-generic-zyxel_gs1900-8hp-
 >>  >>  squashfs-sysupgrade.bin
 >>  >>
 >>  >>  Signed-off-by: Stijn Segers   >>  
---

 >>  >>   .../realtek/base-files/etc/board.d/02_network  |  3 +++
 >>  >>   .../linux/realtek/dts/rtl8380_zyxel_gs1900-8hp.dts | 14
 >>  >> ++
 >>  >>   target/linux/realtek/image/Makefile|  9
 >> +
 >>  >>   3 files changed, 26 insertions(+)
 >>  >>   create mode 100644
 >>  >> target/linux/realtek/dts/rtl8380_zyxel_gs1900-8hp.dts
 >>  >>
 >>  >>  diff --git
 >> a/target/linux/realtek/base-files/etc/board.d/02_network
 >>  >>  b/target/linux/realtek/base-files/etc/board.d/02_network
 >>  >>  index 84fefa536d..8054adc60a 100755  >>  ---
 >> a/target/linux/realtek/base-files/etc/board.d/02_network
 >>  >>  +++ b/target/linux/realtek/base-files/etc/board.d/02_network
 >>  >>  @@ -52,6 +52,9 @@ case $board in
 >>  >>   netgear,gs110tpp-v1)
 >>  >> ucidef_set_poe 130 "$lan_list"
 >>  >> ;;
 >>  >>  +zyxel,gs1900-8hp)
 >>  >>  +  ucidef_set_poe 70 "$lan_list"
 >>  >>  +  ;;
 >>  >>   zyxel,gs1900-10hp)
 >>  >> ucidef_set_poe 77 "$lan_list"
 >>  >> ;;
 >>  >>  diff --git
 >> a/target/linux/realtek/dts/rtl8380_zyxel_gs1900-8hp.dts
 >>  >>  b/target/linux/realtek/dts/rtl8380_zyxel_gs1900-8hp.dts
 >>  >>  new file mode 100644
 >>  >>  index 00..c5813227ac
 >>  >>  --- /dev/null
 >>  >>  +++ b/target/linux/realtek/dts/rtl8380_zyxel_gs1900-8hp.dts
 >>  >>  @@ -0,0 +1,14 @@
 >>  >>  +// SPDX-License-Identifier: GPL-2.0-or-later /dts-v1/;  >  
>

 >> Drop dts-v1.
 >>  >
 >>  > 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




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

[PATCH 2/5] realtek: move memory node to device DTS

[Stijn Segers]

Move the memory out of the rtl838x.dtsi and into the device family DTSI
or device DTS if applicable. This aligns with upstream practice.

Signed-off-by: Stijn Segers 
---
 target/linux/realtek/dts/rtl8380_netgear_gs110tpp-v1.dts | 6 +-
 target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts   | 5 +
 target/linux/realtek/dts/rtl8382_allnet_all-sg8208m.dts  | 5 +
 target/linux/realtek/dts/rtl8382_d-link_dgs-1210.dtsi| 5 +
 target/linux/realtek/dts/rtl838x.dtsi| 5 -
 5 files changed, 20 insertions(+), 6 deletions(-)

diff --git a/target/linux/realtek/dts/rtl8380_netgear_gs110tpp-v1.dts 
b/target/linux/realtek/dts/rtl8380_netgear_gs110tpp-v1.dts
index 1bf175b7bf..46b79d658a 100644
--- a/target/linux/realtek/dts/rtl8380_netgear_gs110tpp-v1.dts
+++ b/target/linux/realtek/dts/rtl8380_netgear_gs110tpp-v1.dts
@@ -1,5 +1,4 @@
 // SPDX-License-Identifier: GPL-2.0-or-later
-/dts-v1/;
 
 #include "rtl838x.dtsi"
 
@@ -10,6 +9,11 @@
compatible = "netgear,gs110tpp-v1", "realtek,rtl838x-soc";
model = "Netgear GS110TPP";
 
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x800>;
+   };
+
chosen {
bootargs = "console=ttyS0,115200";
};
diff --git a/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts 
b/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts
index 4458acee2e..90368c77a3 100644
--- a/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts
+++ b/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts
@@ -10,6 +10,11 @@
compatible = "zyxel,gs1900-10hp", "realtek,rtl838x-soc";
model = "Zyxel GS1900-10HP Switch";
 
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x800>;
+   };
+
aliases {
led-boot = _sys;
led-failsafe = _sys;
diff --git a/target/linux/realtek/dts/rtl8382_allnet_all-sg8208m.dts 
b/target/linux/realtek/dts/rtl8382_allnet_all-sg8208m.dts
index a5dd3be0a4..939db72e38 100644
--- a/target/linux/realtek/dts/rtl8382_allnet_all-sg8208m.dts
+++ b/target/linux/realtek/dts/rtl8382_allnet_all-sg8208m.dts
@@ -9,6 +9,11 @@
compatible = "allnet,all-sg8208m", "realtek,rtl838x-soc";
model = "ALLNET ALL-SG8208M";
 
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x800>;
+   };
+
aliases {
led-boot = _sys;
led-failsafe = _sys;
diff --git a/target/linux/realtek/dts/rtl8382_d-link_dgs-1210.dtsi 
b/target/linux/realtek/dts/rtl8382_d-link_dgs-1210.dtsi
index 74043c097a..480f84e3f5 100644
--- a/target/linux/realtek/dts/rtl8382_d-link_dgs-1210.dtsi
+++ b/target/linux/realtek/dts/rtl8382_d-link_dgs-1210.dtsi
@@ -6,6 +6,11 @@
 #include 
 
 / {
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x800>;
+   };
+
aliases {
led-boot = _power;
led-failsafe = _power;
diff --git a/target/linux/realtek/dts/rtl838x.dtsi 
b/target/linux/realtek/dts/rtl838x.dtsi
index 15d518578b..36d8847a15 100644
--- a/target/linux/realtek/dts/rtl838x.dtsi
+++ b/target/linux/realtek/dts/rtl838x.dtsi
@@ -64,11 +64,6 @@
};
};
 
-   memory@0 {
-   device_type = "memory";
-   reg = <0x0 0x800>;
-   };
-
chosen {
bootargs = "console=ttyS0,38400";
};
-- 
2.20.1


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

[PATCH 3/5] realtek: ZyXEL: spell as done by manufacturer

[Stijn Segers]

ZyXEL spells its own name all uppercase with just the Y lowercase. Adapt
the realtek target to follow this (other OpenWrt targets already do so).

Signed-off-by: Stijn Segers 
---
 target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts | 2 +-
 target/linux/realtek/image/Makefile| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts 
b/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts
index 90368c77a3..0fb78926d9 100644
--- a/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts
+++ b/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts
@@ -8,7 +8,7 @@
 
 / {
compatible = "zyxel,gs1900-10hp", "realtek,rtl838x-soc";
-   model = "Zyxel GS1900-10HP Switch";
+   model = "ZyXEL GS1900-10HP Switch";
 
memory@0 {
device_type = "memory";
diff --git a/target/linux/realtek/image/Makefile 
b/target/linux/realtek/image/Makefile
index 85b30aae1e..765e516a0a 100644
--- a/target/linux/realtek/image/Makefile
+++ b/target/linux/realtek/image/Makefile
@@ -68,7 +68,7 @@ TARGET_DEVICES += netgear_gs110tpp-v1
 define Device/zyxel_gs1900-10hp
   SOC := rtl8380
   IMAGE_SIZE := 6976k
-  DEVICE_VENDOR := Zyxel
+  DEVICE_VENDOR := ZyXEL
   DEVICE_MODEL := GS1900-10HP
 endef
 TARGET_DEVICES += zyxel_gs1900-10hp
-- 
2.20.1


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

[PATCH 4/5] realtek: introduce shared DTSI for GS1900-HP series

[Stijn Segers]

The ZyXEL GS1900-8HP v1, v2 and GS1900-10HP are all built on a similar
Realtek RTL8380M platform. Create a common DTSI in preparation for
GS1900-8HP support, and switch to the macros defined in rtl838x.dtsi.

Signed-off-by: Stijn Segers 
---
 .../realtek/dts/rtl8380_zyxel_gs1900-10hp.dts | 190 +-
 .../realtek/dts/rtl8380_zyxel_gs1900.dtsi | 147 ++
 2 files changed, 151 insertions(+), 186 deletions(-)
 create mode 100644 target/linux/realtek/dts/rtl8380_zyxel_gs1900.dtsi

diff --git a/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts 
b/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts
index 0fb78926d9..5c53385020 100644
--- a/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts
+++ b/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts
@@ -1,5 +1,4 @@
 // SPDX-License-Identifier: GPL-2.0-or-later
-/dts-v1/;
 
 #include "rtl838x.dtsi"
 
@@ -10,11 +9,6 @@
compatible = "zyxel,gs1900-10hp", "realtek,rtl838x-soc";
model = "ZyXEL GS1900-10HP Switch";
 
-   memory@0 {
-   device_type = "memory";
-   reg = <0x0 0x800>;
-   };
-
aliases {
led-boot = _sys;
led-failsafe = _sys;
@@ -96,192 +90,16 @@
 
 };
 
- {
-   status = "okay";
-   flash@0 {
-   compatible = "jedec,spi-nor";
-   reg = <0>;
-   spi-max-frequency = <1000>;
-
-   partitions {
-   compatible = "fixed-partitions";
-   #address-cells = <1>;
-   #size-cells = <1>;
-
-   partition@0 {
-   label = "u-boot";
-   reg = <0x0 0x4>;
-   read-only;
-   };
-   partition@4 {
-   label = "u-boot-env";
-   reg = <0x4 0x1>;
-   read-only;
-   };
-   partition@5 {
-   label = "u-boot-env2";
-   reg = <0x5 0x1>;
-   read-only;
-   };
-   partition@6 {
-   label = "jffs";
-   reg = <0x6 0x10>;
-   };
-   partition@16 {
-   label = "jffs2";
-   reg = <0x16 0x10>;
-   };
-   partition@b26 {
-   label = "firmware";
-   reg = <0x26 0x6d>;
-   compatible = "denx,uimage";
-   };
-   partition@93 {
-   label = "runtime2";
-   reg = <0x93 0x6d>;
-   };
-   };
-   };
-};
-
  {
mdio: mdio-bus {
-   compatible = "realtek,rtl838x-mdio";
-   regmap = <>;
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   /* Internal phy */
-   phy8: ethernet-phy@8 {
-   reg = <8>;
-   compatible = "ethernet-phy-ieee802.3-c22";
-   };
-   phy9: ethernet-phy@9 {
-   reg = <9>;
-   compatible = "ethernet-phy-ieee802.3-c22";
-   };
-   phy10: ethernet-phy@10 {
-   reg = <10>;
-   compatible = "ethernet-phy-ieee802.3-c22";
-   };
-   phy11: ethernet-phy@11 {
-   reg = <11>;
-   compatible = "ethernet-phy-ieee802.3-c22";
-   };
-   phy12: ethernet-phy@12 {
-   reg = <12>;
-   compatible = "ethernet-phy-ieee802.3-c22";
-   };
-   phy13: ethernet-phy@13 {
-   reg = <13>;
-   compatible = "ethernet-phy-ieee802.3-c22";
-   };
-   phy14: ethernet-phy@14 {
-   reg = <14>;
-   compatible = "ethernet-phy-ieee802.3-c22";
-   };
-   phy15: ethernet-phy@15 {
-   reg = <15>;
-   compatible = "ethernet-phy-ieee802.3-c22";
-   };
-