RE: Fate of 4.14 targets / samsung odroid HC1 support

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Andre Valentin
> Sent: Dienstag, 4. August 2020 17:48
> To: openwrt-devel@lists.openwrt.org
> Subject: Re: Fate of 4.14 targets / samsung odroid HC1 support
> 
> Hi!
> 
> I've enabled support for the odoid HC1 in the samsung target a month ago, it
> only needs generic 5.4 kernel and is a subtarget.
> https://www.hardkernel.com/shop/odroid-hc1-home-cloud-one/
> Only open thing is the boodloader on the sdcard, which is a binary for
> hardkernel.

Well, at the moment the main issue is 5.4. If nobody sends 5.4 support for the 
target, it will be dropped.

Everything else can only happen after that.

Best

Adrian

> 
> If there is interest I could send a patch.
> 
> Otherwise I would keep it private.
> 
> Kind regards,
> 
> André
> 
> 
> 
> Am 04.08.20 um 16:43 schrieb m...@adrianschmutzler.de:
> > Hi together,
> >
> > with bcm47xx/bcm53xx bumped to 5.4 now (thanks!), we are left we the
> following targets that (most likely) won't be moved to 5.4 anymore:
> >
> > 4.19: cns3xxx
> > 4.14: ar71xx, at91, ath25, pistachio, rb532, samsung, uml
> >
> > Now, where 20.xx comes closer, I wonder whether we should remove the
> 4.14 targets _before_ branching.
> > Those are already two LTS kernel versions behind, the probability that
> somebody will bump them to an even newer kernel after 20.xx is quite small.
> > Despite, if we drop them before the branch, we only have to drop them
> > once. :-) After having reminded about the situation of the named targets
> several times, I don't think anything will change if we wait any longer with
> this step.
> >
> > The only remaining targets with 4.14 support would be ramips and arc770
> then.
> >
> > Thoughts/opinions?
> >
> > Best
> >
> > Adrian
> >
> >
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> >
> 
> 
> --
> Mit freundlichen Grüßen
> André Valentin
> 
> Systemadministration - Projektkoordination
> 
> 
> --
> MarcanT AG, Herforder Straße 163a, D - 33609 Bielefeld
> Fon: +49 (521) 95945-0 | Fax: +49 (521) 95945-18
> URL: http://www.marcant.net  |
> http://www.global-m2m.com 
> 
> Internet * Netzwerk * Mobile Daten
> 
> Vorstand:
> Thorsten Hojas (Vorsitzender)
> Marc-Henrik Delker
> Dr. Anja-Christina Padberg
> Handelsregister: AG Bielefeld, HRB 42260 USt-ID Nr.: DE 190203238
> 
> 
> 
> __
> _
> Ausserhalb unserer Geschäftszeiten (Montag bis Freitag von 8:30 Uhr bis
> 17:30 Uhr, ausgenommen gesetzliche Feiertage in NRW) stehen wir Ihnen
> gemäß Ihrer jeweiligen Service-Level-Agreements unter der Ihnen
> mitgeteilten Telefonnummer für Störungen und Notfälle zur Verfügung.
> Sie können natürlich auch gerne jederzeit unter supp...@marcant.net ein
> Ticket eröffnen, welches am nächsten Arbeitstag bearbeitet wird.
> 
> 
> 


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: Upcoming 19.07.4 and 18.07.9 stable releases

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Baptiste Jonglez
> Sent: Donnerstag, 30. Juli 2020 20:58
> To: openwrt-devel@lists.openwrt.org
> Cc: Thomas Endt 
> Subject: Upcoming 19.07.4 and 18.07.9 stable releases
> 
> Hi,
> 
> New point releases for 19.07 and 18.06 are starting to be overdue, and I
> would like to help 19.07.4 and 18.06.9 get released somewhere around mid-
> August.
> 
> The main motivation are fixes for a libubox regression and for the musl
> synchronisation bug, as well as a LuCI regression (see "release goals"
> below).  But there are many other fixes, mostly device-related, that also
> motivate these new point releases.  If you have more fixes to backport,
> please consider doing so soon, especially for 18.06.9 which will likely be the
> last release for 18.06.

In addition to the stated goals, we should also do a kernel bump.
Currently we have 4.14.187 and 4.9.229.


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Invert wpad selection for mt7621

[mail]

Hi,

for ramips/mt7621, the wpad-basic package is not selected by default, but added 
for every device individually.

While this might be technically correct if the SoC does not come with a Wifi 
module, only 18 of 97 devices for that platform are set up _without_ wpad-basic 
currently.

Therefore, I wonder if it wouldn't be more convenient to add wpad-basic (or 
wpad-basic-wolfssl...) by default for the subtarget and then just remove it 
(-wpad-basic) for the 18 mentioned devices, instead of having to add it for 
about 60 times instead.
This would also match the behavior of the other subtargets, where it is added 
by default anyway.

Opinions?

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Fate of 4.14 targets

[mail]

Hi together,

with bcm47xx/bcm53xx bumped to 5.4 now (thanks!), we are left we the following 
targets that (most likely) won't be moved to 5.4 anymore:

4.19: cns3xxx
4.14: ar71xx, at91, ath25, pistachio, rb532, samsung, uml

Now, where 20.xx comes closer, I wonder whether we should remove the 4.14 
targets _before_ branching.
Those are already two LTS kernel versions behind, the probability that somebody 
will bump them to an even newer kernel after 20.xx is quite small.
Despite, if we drop them before the branch, we only have to drop them once. :-)
After having reminded about the situation of the named targets several times, I 
don't think anything will change if we wait any longer with this step.

The only remaining targets with 4.14 support would be ramips and arc770 then.

Thoughts/opinions?

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: Restoring (old) config backups and

[mail]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Paul Oranje
> Sent: Samstag, 1. August 2020 16:06
> To: m...@adrianschmutzler.de
> Cc: Alberto Bursi ; openwrt-
> de...@lists.openwrt.org
> Subject: Re: Restoring (old) config backups and
> 
> 
> 
> > Op 21 jul. 2020, om 11:06 heeft m...@adrianschmutzler.de het volgende
> geschreven:
> >
> >> -Original Message-
> >> From: openwrt-devel [mailto:openwrt-devel-
> boun...@lists.openwrt.org]
> >> On Behalf Of Alberto Bursi
> >> Sent: Dienstag, 21. Juli 2020 09:48
> >> To: openwrt-devel@lists.openwrt.org; m...@adrianschmutzler.de
> >> Subject: Re: Restoring (old) config backups and
> >>
> >>
> >> On 20/07/20 19:32, Henrique de Moraes Holschuh wrote:
> >>>
> >>>
> >>> Any thoughts on this?  I am certainly to have overlooked a lot of
> >>> stuff, especially if it is present only on master.  Also, handling
> >>> of an uci-defaults "reset" (so that they'd run again) in
> >>> non-initramfs/overlayfs based system is likely to pose some
> >>> challenges depending on how it is implemented...
> >>>
> >>
> >> Adrian Shmultzer has been recently adding some infrastructure in the
> >> sysupgrade to stop it if there are incompatible features that would
> >> break core functionality, so that the user won't just sysupgrade with
> >> the same config and land in an inaccessible device. Maybe his work
> >> can/should be extended to alter the creating/restoring config backups
> >> logic too, as it's really doing more or less the same thing already.
> >
> > Actually, my solution implements the config "on device" as a uci parameter,
> so the "on device" version is actually not the version of the firmware
> installed, but of the config installed. Therefore, one may indeed go that road
> to prevent flashing an incompatible backup. However, I don't think you can
> use it for much else.
> >
> > Despite, I still have received no positive feedback about that change at 
> > all,
> so I'm not sure whether it will go in at all.
> Good reason to chime in. That proposal for compatibility checks seemed very
> well thought over and as such I would welcome its implementation.

I've already merged this a few days ago and added some documentation here:
https://openwrt.org/docs/guide-user/installation/generic.sysupgrade#upgrade_compatibility

Note that with the different manuals on the sysupgrade process, I haven't 
really found a natural place for that, so if somebody has a better idea, I'm 
open to suggestions.

However, this only remotely touches your initial subject, of course.

Best

Adrian

> Bye,
> Paul
> 
> >
> > Best
> >
> > Adrian
> >
> >>
> >> -Alberto
> >>
> >>
> >> ___
> >> 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


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [PATCH v2] scripts: Add Buildbot dump-target-info.pl script

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Paul Spooren
> Sent: Montag, 3. August 2020 10:11
> To: openwrt-devel@lists.openwrt.org
> Cc: Paul Spooren 
> Subject: [PATCH v2] scripts: Add Buildbot dump-target-info.pl script
> 
> The script comes from buildbot.git[0] and is used to print available targets
> and architectures, which are then build.
> 
> As the buildbot clones openwrt.git anyway, the script might as well live here
> to be used for other cases as well, e.g. determining what architectures are
> available when building Docker containers or show developers an overview
> which architectures are used by which target.
> 
> It's called with either the parameter `architectures` or `targets`, showing
> architectures followed by supported targets or targets, followed by the
> supported architectures:
> 
> $ ./scripts/dumpinfo.pl architectures
> aarch64_cortex-a53 bcm27xx/bcm2710 mediatek/mt7622 mvebu/cortexa53
> sunxi/cortexa53
> aarch64_cortex-a72 bcm27xx/bcm2711 mvebu/cortexa72 ...
> 
> $ ./scripts/dumpinfo.pl targets
> apm821xx/nand powerpc_464fp
> apm821xx/sata powerpc_464fp

Name should be updated in the examples as well ...

Best

Adrian

> ...
> 
> In the future the the script could be removed from the buildbot repository
> and maintained only here.
> 
> Rename `dumpinfo.pl` to `dump-target-info.pl` to improve verbosity of
> filename.
> 
> [0]:
> https://git.openwrt.org/?p=buildbot.git;a=blob;f=scripts/dumpinfo.pl;h=aa9
> 7f8d60379076a41b968402e9337cea824ece5;hb=HEAD
> 
> Signed-off-by: Paul Spooren 
> ---
>  scripts/dump-target-info.pl | 91
> +
>  1 file changed, 91 insertions(+)
>  create mode 100755 scripts/dump-target-info.pl
> 
> diff --git a/scripts/dump-target-info.pl b/scripts/dump-target-info.pl new 
> file
> mode 100755 index 00..aa97f8d603
> --- /dev/null
> +++ b/scripts/dump-target-info.pl
> @@ -0,0 +1,91 @@
> +#!/usr/bin/env perl
> +
> +use strict;
> +use warnings;
> +use Cwd;
> +
> +my (%targets, %architectures);
> +
> +$ENV{'TOPDIR'} = Cwd::getcwd();
> +
> +
> +sub parse_targetinfo {
> + my ($target_dir, $subtarget) = @_;
> +
> + if (open M, "make -C '$target_dir' --no-print-directory DUMP=1
> TARGET_BUILD=1 SUBTARGET='$subtarget' |") {
> + my ($target_name, $target_arch, @target_features);
> + while (defined(my $line = readline M)) {
> + chomp $line;
> +
> + if ($line =~ /^Target: (.+)$/) {
> + $target_name = $1;
> + }
> + elsif ($line =~ /^Target-Arch-Packages: (.+)$/) {
> + $target_arch = $1;
> + }
> + elsif ($line =~ /^Target-Features: (.+)$/) {
> + @target_features = split /\s+/, $1;
> + }
> + elsif ($line =~ /^@\@$/) {
> + if ($target_name && $target_arch &&
> + !grep { $_ eq 'broken' or $_ eq 
> 'source-only'
> } @target_features) {
> + $targets{$target_name} =
> $target_arch;
> + $architectures{$target_arch} ||= [];
> + push @{$architectures{$target_arch}},
> $target_name;
> + }
> +
> + undef $target_name;
> + undef $target_arch;
> + @target_features = ();
> + }
> + }
> + close M;
> + }
> +}
> +
> +sub get_targetinfo {
> + foreach my $target_makefile (glob "target/linux/*/Makefile") {
> + my ($target_dir) = $target_makefile =~ m!^(.+)/Makefile$!;
> + my @subtargets;
> +
> + if (open M, "make -C '$target_dir' --no-print-directory
> DUMP=1 TARGET_BUILD=1 val.FEATURES V=s 2>/dev/null |") {
> + if (defined(my $line = readline M)) {
> + chomp $line;
> + if (grep { $_ eq 'broken' or $_ eq 'source-only'
> } split /\s+/, $line) {
> + next;
> + }
> + }
> + }
> +
> + if (open M, "make -C '$target_dir' --no-print-directory
> DUMP=1 TARGET_BUILD=1 val.SUBTARGETS V=s 2>/dev/null |") {
> + if (defined(my $line = readline M)) {
> + chomp $line;
> + @subtargets = split /\s+/, $line;
> + }
> + close M;
> + }
> +
> + push @subtargets, 'generic' if @subtargets == 0;
> +
> + foreach my $subtarget (@subtargets) {
> + parse_targetinfo($target_dir, $subtarget);
> + }
> + }
> +}
> +
> +if 

4K_SECTORS_LIMIT / partial writes problems

[mail]

Hi,

when discussing support for Mikrotik devices, I have repeatedly been made aware 
of a 4K_SECTORS_LIMIT / partial writes problem that seems to have been 
introduced in 4.17, so from our view with kernel 4.19 after the 19.07 release.

This seems to be a general problem, discussed here:
https://github.com/openwrt/openwrt/pull/3094#issuecomment-667557585
https://github.com/openwrt/openwrt/pull/3103#issuecomment-663894347

In the latter thread, the author tried to further investigate the issue, and 
finally came up with an RFC pull request here:
https://github.com/openwrt/openwrt/pull/3271

My understanding of that issue is only superficial, I'd be quite happy if 
somebody could provide some feedback there, as this might be a release blocker 
for 20.xx as it appears to me.

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: Missing ar71xx devices in ath79 before 20.xx

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Russell Senior
> Sent: Sonntag, 2. August 2020 04:47
> To: m...@adrianschmutzler.de
> Cc: openwrt-devel@lists.openwrt.org
> Subject: Re: Missing ar71xx devices in ath79 before 20.xx
> 
> >writes:
> 
> > Hi, I just did a quick comparison which ar71xx devices are still
> > missing in ath79. This has also been posted in the forum here:
> > https://forum.openwrt.org/t/missing-ar71xx-devices-in-ath79-before-20-
> > xx/70687
> 
> > [...]
> 
> > wzr-600dhp
> 
> I have a bunch of these and they are the same board as "buffalo,wzr-hp-
> ag300h", which has had ath79 support for a good long while.

Since the names are different, I'd prefer to add it as clone anyway ...

> 
> 
> --
> Russell Senior, President
> russ...@personaltelco.net
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Bump bcm47xx/bcm53xx to 5.4 by default

[mail]

Hi,

the targets bcm47xx and bcm53xx are still on 4.19 with 5.4 only set as testing 
kernel.

With a 20.xx branch coming closer, it might be good to switch these to 5.4 by 
default so they can receive some wider-audience testing beforehand, unless 
there are any blockers.

Since I'm not too familiar with these targets, I'd be happy if some of the 
"maintainers" could take care or post an Acked-by here for me to bump them.

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

ramips/rt**** and kernel 5.4

[mail]

Hi,

with a 20.xx branch coming closer, we still have 3 of 6 ramips subtargets 
(rt288x, rt305x, rt3883) on kernel 4.14 by default (though 5.4 testing support 
is available in principle).

I've recently tried to build those with 5.4 and buildbot settings (including 
packages), they all compile nicely (4M devices have already been disabled) 
out-of-the-box.

However, I don't have any devices for these platforms, and I have not followed 
the ramips 5.4 transitions closely enough to know which problems might appear 
on the devices.

At the moment, we have the following number of supported devices (i.e. > 4M):
rt288x: 1 device
rt305x: 57 devices
rt3883: 10 devices

So, any input on the situation on those platform and/or on-device testing would 
be quite helpful.

Otherwise, we would have to drop these subtargets for 20.xx release.

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Missing ar71xx devices in ath79 before 20.xx

[mail]

Hi, I just did a quick comparison which ar71xx devices are still missing in 
ath79. This has also been posted in the forum here:

https://forum.openwrt.org/t/missing-ar71xx-devices-in-ath79-before-20-xx/70687

19.07 will be the last release to include ar71xx. With 20.xx coming closer, 
I've made a stupid comparison to check which ar71xx devices are still missing 
in ath79. This has been created by taking the image names from ar71xx@19.07 and 
comparing them against ath79@master.

This should be taken as a last reminder to try to port one of those devices, so 
they still might have a chance to get into a 20.xx release.

The list is created by a stupid comparison, so it does not tell anything about 
whether it would actually make sense to port a particular device (I excluded 
all tiny devices, though). If you want to take action, please also check for 
existing forum thread or Pull Requests first.

Note that this ignores mikrotik.

nand:

c-60
mr18
r6100
wi2a-ac200i
z1

generic:

NBG6616
a60
alfa-ap96
alfa-nx
all0258n
all0305
all0315n
antminer-s1
antminer-s3
antrouter-r1
ap121-16M
ap121-8M
ap531b0
ap90q
bsb
c-55
cf-e316n-v2
cf-e320n-v2
cf-e355ac-v1
cf-e355ac-v2
cf-e375ac
cf-e380ac-v1
cf-e380ac-v2
cf-e385ac
cf-e520n
cf-e530n
cpe505n
cpe830
cpe870
dgl-5500-a1
dhp-1565-a1
dir-869-a1
dlan-hotspot
dlan-pro-1200-ac
dlan-pro-500-wp
dlrtdev01
dr342
dr531
dragino2
e1700ac-v2-16M
e1700ac-v2-8M
e558-v2-16M
e558-v2-8M
e600g-v2-16M
e600g-v2-8M
e600gac-v2-16M
e600gac-v2-8M
e750a-v4-16M
e750a-v4-8M
e750g-v8-16M
e750g-v8-8M
eap300v2
eap7660d
el-m150
el-mini
ew-balin
gl-domino
gl-usb150
hiwifi-hc6361
hornet-ub
hornet-ub-x2
ja76pf
jwap003
jwap230
lan-turtle
mc-mac1200r
minibox-v1
minibox-v3.2
mr12
mr16
mr1750
mr600
mr900
mw4530r-v1
mynet-n600
mynet-rext
mzk-w04nu
mzk-w300nh
n5q
om2p
om5p
om5pac
omy-g1
omy-x1
onion-omega
oolite-v1
oolite-v5.2
packet-squirrel
pb42
pb44
r36a
r602n
rut900
rw2458n
sc1750
sc300m
sc450
smart-300
som9331
sr3200
t830
tellstick-znet-lite
tew-673gru
tew-732br
tl-wdr6500-v2
tl-wdr7500-v3
tl-wpa8630-v1
tl-wr710n-v2.1
tl-wr942n-v1
tube2h-16M
tube2h-8M
ubdev01
ubnt-air-gateway-pro
ubnt-air-gateway
ubnt-lbe-m5
ubnt-ls-sr71
ubnt-rocket-m-ti
ubnt-rocket-m-xw
ubnt-uap-pro
ubnt-unifi-outdoor-plus
ubnt-unifi-outdoor
wam250
weio
wifi-pineapple-nano
wndap360
wp543
wpe72
wpj342
wpj558
wrt160nl
wrtnode2q
wzr-450hp2
wzr-600dhp
wzr-hp-g300nh
wzr-hp-g300nh2
xd3200

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: Notes on ath79 RouterBoard 493G image

[mail]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of W. Michael Petullo
> Sent: Samstag, 1. August 2020 06:57
> To: openwrt-devel@lists.openwrt.org
> Subject: Notes on ath79 RouterBoard 493G image
> 
> I have some feedback about the ATH79 RouterBoard 493G image built from
> master, as documented at:
> 
>   https://github.com/openwrt/openwrt/pull/3026
> 
> First, I was unable to update to the sysupgrade image at:
> 
>   https://downloads.openwrt.org/snapshots/targets/ath79/mikrotik/o
> penwrt-ath79-mikrotik-mikrotik_routerboard-493g-squashfs-sysupgrade.bin
> 
> while running 19.07.2, although the initial comments on the pull request
> above indicate this is possible. I fixed this by untarring the sysupgrade 
> image,
> renaming its top-level directory from sysupgrade-mikrotik_routerboard-
> rb493g/ to sysupgrade-routerboard/, and retarring the sysupgrade image.

This has been "fixed" for ar71xx @19.07 here:
https://github.com/openwrt/openwrt/commit/6ffd4d8a4de2a7c35a841a21c4b4116dfe54b754

This is in 19.07.3, but not in 19.07.2. So, if you had updated to 19.07.3 
before going for master, it would have worked.
The problem is that ar71xx hardcoded a certain name here, and that code is 
taken from the "old" device.

I cannot comment on your second issue.

Best

Adrian 


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: Release goals for 20.XX

[mail]

> 3) organisational: switch to gitlab?
> 
>While there was a vote about it, I don't know if this is planned
>for 20.XX.  I think it makes sense: we could start using gitlab to
>track 20.XX bug reports, and possibly drop 18.06 bug reports from
>flyspray.  But if it is not ready, it should probably not block the
>20.XX release.

I personally don't think we should link this to the release.

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

compat-version for mt7621

[mail]

Hi,

I just finally merged my compat-version patchset to master. This already takes 
care of bumping the compat-version for the kirkwood/mvebu devices affected by 
the DSA introduction.

However, the biggest swap (based on number of devices) from swconfig to DSA has 
been done for ramips/mt7621. Since the entire subtarget is affected here, we 
essentially have two options how two address this, which I'd like to discuss.

Generally, increasing the compat-version needs two changes:

1. adding the following to image/mt7621.mk for the affected devices (used for 
the image metadata):

  DEVICE_COMPAT_VERSION := 1.1
  DEVICE_COMPAT_MESSAGE := Config cannot be migrated from swconfig to DSA

2. adding the following to a board.d file (used for the compat version "on the 
device")

  ucidef_set_compat_version "1.1"

While this is straightforward for the devices actually affected by the 
migration, the question is how to deal with the devices that were added _after_ 
that, i.e. those that have been added with DSA in the first place, as well as 
new devices added in the future.
This is where the two options become available:

Option 1. Only bump actually migrated devices:

Strictly, the version bump only is meant for _changed_ devices, so devices 
added with DSA in the first place would be 1.0, i.e. the first version added to 
OpenWrt.
This would save us from specifying DEVICE_COMPAT_VERSION := 1.1 for these in 
image/mt7621.mk, but would require to list all 1.1 devices in the switch-case 
in a board.d file.

Option 2. Set all mt7621 devices to 1.1 from the start

The obvious alternative is to have _all_ mt7621 devices set to compat version 
1.1, even those that have been added after DSA introduction and those that will 
be added in the future.
While this is less strict in applying the compat version, it's actually easier 
to grasp for the user and easier to implement.

Advantages:
- No need to add a lot of devices to switch-case in board.d file (unless 
something else requires a 1.2 etc.)
- "DSA = 1.1" without having to look at the specific device (for this subtarget)
- DEVICE_COMPAT_VERSION can be moved to common/shared definitions (as that will 
also affect new devices), i.e. is stated less often
- If somebody backports a device to 19.07 (locally) by switching to swconfig, 
the compat-version mechanism would also cover his/her case (as the 19.07 
swconfig device would be 1.0) for a future upgrade

Disadvantages:
- DEVICE_COMPAT_VERSION = 1.1 in image/mt7621.mk would need to be added to 
every new device added to this subtarget in the future
- There would be no official version 1.0 for the "newer" devices
- DSA would be linked to 1.1 in the mind of people, while technically other 
reasons could lead to a compat-version bump to 1.1 as well (and DSA could then 
be 1.2 if that other things happens before)

Personally, I prefer option 2, as I think the advantages outweigh the 
disadvantages and I think it is easier to maintain the DEVICE_COMPAT_VERSION in 
Makefile that a big switch-case in board.d.

I'd be happy about your opinions on this one.

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [PATCH v2 1/3] hostapd: add wpad-basic-wolfssl variant

[mail]

Hi Petr,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Petr Štetiar
> Sent: Montag, 27. Juli 2020 11:57
> To: openwrt-devel@lists.openwrt.org
> Cc: Petr Štetiar 
> Subject: [PATCH v2 1/3] hostapd: add wpad-basic-wolfssl variant
> 
> Add package which provides size optimized wpad with support for just WPA-
> PSK, SAE (WPA3-Personal), 802.11r and 802.11w.

a few comments below.

> 
> Signed-off-by: Petr Štetiar 
> ---
> 
> changed in v2: no changes
> 
>  include/target.mk  |  2 +-
>  package/network/services/hostapd/Config.in |  2 ++
> package/network/services/hostapd/Makefile  | 20
> 
>  3 files changed, 23 insertions(+), 1 deletion(-)
> 
> diff --git a/include/target.mk b/include/target.mk index
> aba477e83b8b..6ed6565bdaa2 100644
> --- a/include/target.mk
> +++ b/include/target.mk
> @@ -56,7 +56,7 @@ endif
>  DEFAULT_PACKAGES += $(DEFAULT_PACKAGES.$(DEVICE_TYPE))
> 
>  filter_packages = $(filter-out -% $(patsubst -%,%,$(filter -%,$(1))),$(1)) -
> extra_packages = $(if $(filter wpad-mini wpad-basic wpad nas,$(1)),iwinfo)
> +extra_packages = $(if $(filter wpad-mini wpad-basic wpad-basic-wolfssl
> +wpad nas,$(1)),iwinfo)
> 
>  define ProfileDefault
>NAME:=
> diff --git a/package/network/services/hostapd/Config.in
> b/package/network/services/hostapd/Config.in
> index 81a374c6525a..aa2a4bc41b5b 100644
> --- a/package/network/services/hostapd/Config.in
> +++ b/package/network/services/hostapd/Config.in
> @@ -13,6 +13,7 @@ config WPA_RFKILL_SUPPORT
>  PACKAGE_wpad-openssl || \
>  PACKAGE_wpad-wolfssl || \
>  PACKAGE_wpad-basic || \
> +PACKAGE_wpad-basic-wolfssl || \
>  PACKAGE_wpad-mini || \
>  PACKAGE_wpad-mesh-openssl || \
>  PACKAGE_wpad-mesh-wolfssl
> @@ -32,6 +33,7 @@ config WPA_MSG_MIN_PRIORITY
>  PACKAGE_wpad-openssl || \
>  PACKAGE_wpad-wolfssl || \
>  PACKAGE_wpad-basic || \
> +PACKAGE_wpad-basic-wolfssl || \
>  PACKAGE_wpad-mini || \
>  PACKAGE_wpad-mesh-openssl || \
>  PACKAGE_wpad-mesh-wolfssl

I think the package also needs to be added to "WPA_WOLFSSL" in the same file?

> diff --git a/package/network/services/hostapd/Makefile
> b/package/network/services/hostapd/Makefile
> index d754f19857ea..df1a80d3dabb 100644
> --- a/package/network/services/hostapd/Makefile
> +++ b/package/network/services/hostapd/Makefile
> @@ -109,6 +109,13 @@ ifeq ($(LOCAL_VARIANT),full)
>endif
>  endif
> 
> +ifeq ($(LOCAL_VARIANT),basic)
> +  ifeq ($(SSL_VARIANT),wolfssl)
> +DRIVER_MAKEOPTS += CONFIG_TLS=wolfssl CONFIG_SAE=y
> +TARGET_LDFLAGS += -lwolfssl
> +  endif
> +endif

I've just pushed my patch to rearrange this setup. You can just drop this added 
"block" entirely now, as your case should be covered by the existing conditions.

> +
>  ifneq ($(LOCAL_TYPE),hostapd)
>ifeq ($(LOCAL_VARIANT),mesh)
>  ifeq ($(SSL_VARIANT),openssl)
> @@ -248,6 +255,17 @@ define Package/wpad-basic/description
>   This package contains a basic IEEE 802.1x/WPA Authenticator and Supplicant
> with WPA-PSK, 802.11r and 802.11w support.
>  endef
> 
> +define Package/wpad-basic-wolfssl
> +$(call Package/wpad/Default,$(1))
> +  TITLE+= (WPA3-Personal, 11r and 11w)

I'd use the shorter (wolfSSL, 11r, 11w) or similar now to stay in line with 
updated TITLE variables.

Despite, we didn't refer to WPA3 as such anywhere else in the file.

I'd also like the wpad-basic-wolfssl variant backported to 19.07 (optional, of 
course). Do you have an opinion about that?

Best

Adrian

> +  VARIANT:=wpad-basic-wolfssl
> +  DEPENDS+=+libwolfssl
> +endef
> +
> +define Package/wpad-basic-wolfssl/description
> + This package contains a basic IEEE 802.1x/WPA Authenticator and
> Supplicant with WPA-PSK, SAE (WPA3-Personal), 802.11r and 802.11w
> support.
> +endef
> +
>  define Package/wpad-mini
>  $(call Package/wpad/Default,$(1))
>TITLE+= (WPA-PSK only)
> @@ -567,6 +585,7 @@ define Package/wpad/install
>   $(LN) wpad $(1)/usr/sbin/wpa_supplicant  endef  Package/wpad-
> basic/install = $(Package/wpad/install)
> +Package/wpad-basic-wolfssl/install = $(Package/wpad/install)
>  Package/wpad-mini/install = $(Package/wpad/install)  Package/wpad-
> openssl/install = $(Package/wpad/install)  Package/wpad-wolfssl/install =
> $(Package/wpad/install) @@ -622,6 +641,7 @@ $(eval $(call
> BuildPackage,wpad))  $(eval $(call BuildPackage,wpad-mesh-openssl))  $(eval
> $(call BuildPackage,wpad-mesh-wolfssl))  $(eval $(call BuildPackage,wpad-
> basic))
> +$(eval $(call BuildPackage,wpad-basic-wolfssl))
>  $(eval $(call BuildPackage,wpad-mini))
>  $(eval $(call BuildPackage,wpad-openssl))  $(eval $(call BuildPackage,wpad-
> wolfssl))
> 
> ___
> openwrt-devel mailing list
> 

RE: [PATCH] hostapd: improve TITLE for packages

[mail]

Hi,

> >  define Package/wpa-supplicant-openssl  $(call
> > Package/wpa-supplicant/Default,$(1))
> > +  TITLE+= (OpenSSL)
> 
> shouldn't this rather be '(OpenSSL full)' as well then?
> 
> >VARIANT:=supplicant-full-openssl
> >DEPENDS+=+libopenssl
> >  endef
> >
> >  define Package/wpa-supplicant-wolfssl  $(call
> > Package/wpa-supplicant/Default,$(1))
> > +  TITLE+= (wolfSSL)
> 
> shouldn't this rather be '(wolfSSL full)' as well then?

Indeed, good find, will change both cases above as suggested.

> And what about the '(built-in full)' variant of wpa_supplicant?

Err, yes, to follow the current scheme I should add a "(full)" there as well.

Would you prefer to use "(built-in full)" instead of plain "(full)" in all 
non-SSL cases?
This might actually be more helpful to differentiate.

Thanks

Adrian 


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: RE: [PATCH v7] ramips: add support for JS76x8 series DEV boards

[mail]

Hi,

in order to bring this to an ending that somehow will satisfy both of us, I've 
applied a few changes (which are necessary/helpful in my opinion) on top of 
your v7 and pushed the result to my staging tree:

https://git.openwrt.org/?p=openwrt/staging/adrian.git;a=shortlog;h=refs/heads/js76x8

The only thing missing is the port assignment of the three ethernet ports that 
are actually used.

The current case sets up the following:
"0:lan" "1:lan" "2:lan" "3:lan" "4:wan" "6@eth0"

So, which three of 0-4 are actually used, and which should be set to wan (or 
should we have 3xlan)?

Without an answer to that, I cannot merge it. Just answer here, and I will take 
care of implementing it myself.

As a bonus, if you provide the GPIOs of the two user-defined buttons, I'd also 
implement those in the DTS, so users can assign tasks to them.
I'd call them user1 and user2 unless told differently. However, note that the 
buttons are optional, only the network setup is really required for this be 
move forward.

I'd be happy to get this into a state where we can finally merge it, so both of 
our time is not entirely wasted.

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: Transform OpenWRT to a Yocto / openembedded layer (was: Re: dm-verity support)

[mail]

> -Original Message-
> From: Bas Mevissen [mailto:ab...@basmevissen.nl]
> Sent: Donnerstag, 30. Juli 2020 10:54
> To: Thomas Petazzoni 
> Cc: m...@adrianschmutzler.de; openwrt-devel@lists.openwrt.org
> Subject: Transform OpenWRT to a Yocto / openembedded layer (was: Re:
> dm-verity support)
> 
> On 2020-07-30 09:13, Thomas Petazzoni wrote:
> > Hello,
> >
> > On Thu, 30 Jul 2020 00:17:28 +0200
> >  wrote:
> >
> >> your dm-verity patchset is in our patchwork since November 2019 (v2).
> >> Unfortunately, nobody seemed to be particularly interested in
> >> reviewing/merging it.
> >>
> >> Since I don't see a reason why this should change in another 8
> >> months, I'm going to finally mark it as Rejected now. After all, our
> >> resources are limited.
> >>
> 
> Isn't there some deferred or other state that better expresses the actual
> situation?

For me, "deferred" means essentially "we don't do it now, but we will do it 
later".

However, there is no indication that the situation will be different in a year 
or two. So I chose "rejected", as a waiting time of 8 months without any 
response indicate that the feature is not wanted.

As Thomas stated himself, this surely is "unfortunate", but I'm just putting 
into effect what's obvious here.

However, since it doesn't matter much after all, I can also change the patchset 
to Deferred if you really desire.
Or I could try to apply it, which would certainly fail after 8 months, and then 
mark it as "Not Applicable", which IIRC has been done for the SELinux changeset 
already.

But none of that would actually change the situation. I'm (actually) sorry, but 
I don't see a point in keeping features open for years. The interest will 
certainly not increase, but rather decrease if the patchset becomes older and 
older.

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: dm-verity support

[mail]

Hi Thomas,

your dm-verity patchset is in our patchwork since November 2019 (v2). 
Unfortunately, nobody seemed to be particularly interested in reviewing/merging 
it.

Since I don't see a reason why this should change in another 8 months, I'm 
going to finally mark it as Rejected now. After all, our resources are limited.

I'm sorry, and although I fear a similar fate will hit the SELinux effort, I 
still hope you will not feel repelled and continue to contribute to OpenWrt in 
the future.

All the best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [PATCH] hostapd: reorganize config selection hierarchy for WPA3

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Adrian Schmutzler
> Sent: Mittwoch, 29. Juli 2020 22:09
> To: openwrt-devel@lists.openwrt.org
> Subject: [PATCH] hostapd: reorganize config selection hierarchy for WPA3
> 
> The current selection of DRIVER_MAKEOPTS and TARGET_LDFLAGS is
> exceptionally hard to read. This tries to make things a little easier by 
> inverting
> the hierarchy of the conditions, so SSL_VARIANT is checked first and
> LOCAL_VARIANT is checked second.
> 
> This exploits the fact that some of the previous conditions were
> unnecessary, e.g. openssl is only available for mesh/full and not available 
> for
> hostapd, so we don't need to check that.

This paragraph of the commit message is wrong, but the implementation should be 
correct ...

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [PATCH 2/2] build: image: return sizes if check-size fails

[mail]

> -Original Message-
> From: Paul Spooren [mailto:m...@aparcar.org]
> Sent: Mittwoch, 29. Juli 2020 21:05
> To: Adrian Schmutzler ; openwrt-
> de...@lists.openwrt.org
> Subject: Re: [PATCH 2/2] build: image: return sizes if check-size fails
> 
> Is there an easy way to test this? As in, how do I force the Kernel to be to
> big?

Just pick a device and set KERNEL_SIZE to a smaller value than what the kernel 
image gets, e.g. 1024k.

Same can be done with IMAGE_SIZE to check explizit use of check-size in 
image/Makefile...

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [PATCH v7] ramips: add support for JS76x8 series DEV boards

[mail]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Robinson Wu
> Sent: Freitag, 17. Juli 2020 09:33
> To: openwrt-devel@lists.openwrt.org
> Cc: Robinson Wu 
> Subject: [PATCH v7] ramips: add support for JS76x8 series DEV boards

sorry for coming up with another bunch of remarks; I'm confident that we at 
least have everything covered now.

> 
> This commit adds support for the Jotale JS76x8 series development boards.
> These devices have the following specifications:
> 
> - SOC: MT7628AN/NN, MT7688AN, MT7628DAN
> - RAM of MT7628AN/NN and MT7688AN: 64/128/256 MB (DDR2)
> - RAM of MT7628DAN: 64 MB (DDR2)
> - FLASH:8/16/32 MB (SPI NOR)
> - Ethernet:3x 10/100 Mbps ethernet ports (MT76x8 built-in switch)
> - WIFI:1x 2T2R 2.4 GHz Wi-Fi
> - LEDs:1x system status green LED, 1x wifi green LED,
>3x ethernet green LED
> - Buttons:1x reset button, 2x user defined button

User-defined buttons are not set up in DTS?

> - 1x microSD slot
> - 4x USB 2.0 port
> - 1x mini-usb debug UART
> - 1x DC jack for main power (DC 5V)
> - 1x TTL/RS232 UART
> - 1x TTL/RS485 UART
> - 13x GPIO header
> - 1x audio codec(wm8960)
> 
> Installation via OpenWrt:
> 
> The original firmware is OpenWrt, so both LuCI and sysupgrade can be used.
> 
> Installation via U-boot web:
> 
> 1. Power on board with reset button pressed, release it
>after wifi led start blinking.
> 2. Setup static IP 192.168.1.123/4 on your PC.
> 3. Go to 192.168.1.8 in browser and upload "sysupgrade" image.
> 
> Installation via U-boot tftp:
> 1. Connect to serial console at the mini usb, which has been connected to
> UART0
>on board (115200 8N1)
> 2. Setup static IP 192.168.1.123/4 on your PC.
> 3. Place openwrt-firmware.bin on your PC tftp server (192.168.1.123).
> 3. Connect one of LAN ports on board to your PC.
> 4. Start terminal software (e.g. screen /dev/ttyUSB0 115200) on PC.
> 5. Apply power to board.
> 6. Interrupt U-boot with keypress of "2".
> 7. At u-boot prompts:
>Warning!! Erase Linux in Flash then burn new one. Are you sure?(Y/N) Y
>Input device IP (192.168.1.8) ==:192.168.1.8
>Input server IP (192.168.1.123) ==:192.168.1.123
>Input Linux Kernel filename (root_uImage) ==:openwrt-firmware.bin 8.
> board will download file from tftp server, write it to flash and reboot.
> 
> Signed-off-by: Robinson Wu 
> ---
>  .../ramips/dts/mt7628an_jotale_js76x8-16m.dts  |  12 ++
>  .../ramips/dts/mt7628an_jotale_js76x8-32m.dts  |  12 ++
>  .../linux/ramips/dts/mt7628an_jotale_js76x8-8m.dts |  12 ++
>  .../linux/ramips/dts/mt7628an_jotale_js76x8.dtsi   | 145
> +
>  target/linux/ramips/image/mt76x8.mk|  27 
>  .../ramips/mt76x8/base-files/etc/board.d/01_leds   |   6 +
>  .../mt76x8/base-files/etc/board.d/02_network   |   6 +
>  7 files changed, 220 insertions(+)
>  create mode 100644 target/linux/ramips/dts/mt7628an_jotale_js76x8-
> 16m.dts
>  create mode 100644 target/linux/ramips/dts/mt7628an_jotale_js76x8-
> 32m.dts
>  create mode 100644 target/linux/ramips/dts/mt7628an_jotale_js76x8-
> 8m.dts
>  create mode 100644 target/linux/ramips/dts/mt7628an_jotale_js76x8.dtsi
> 
> diff --git a/target/linux/ramips/dts/mt7628an_jotale_js76x8-16m.dts
> b/target/linux/ramips/dts/mt7628an_jotale_js76x8-16m.dts
> new file mode 100644
> index 000..53ed6d8
> --- /dev/null
> +++ b/target/linux/ramips/dts/mt7628an_jotale_js76x8-16m.dts
> @@ -0,0 +1,12 @@
> +/dts-v1/;

Please add an SPDX license identifier to the top of all DTS(I) files.

The typical/default choice is
// SPDX-License-Identifier: GPL-2.0-or-later OR MIT

Look e.g. in 
https://github.com/openwrt/openwrt/blob/master/target/linux/ramips/dts/mt7628an_tplink_archer-c20-v5.dts

> +
> +#include "mt7628an_jotale_js76x8.dtsi"
> +
> +/ {
> + compatible = "jotale,js76x8-16m", "jotale,js76x8",
> "mediatek,mt7628an-soc";
> + model = "Jotale JS76x8 (16M)";
> +};
> +
> + {
> + reg = <0x5 0xfb>;
> +};
> diff --git a/target/linux/ramips/dts/mt7628an_jotale_js76x8-32m.dts
> b/target/linux/ramips/dts/mt7628an_jotale_js76x8-32m.dts
> new file mode 100644
> index 000..851e6db
> --- /dev/null
> +++ b/target/linux/ramips/dts/mt7628an_jotale_js76x8-32m.dts
> @@ -0,0 +1,12 @@
> +/dts-v1/;
> +
> +#include "mt7628an_jotale_js76x8.dtsi"
> +
> +/ {
> + compatible = "jotale,js76x8-32m", "jotale,js76x8",
> "mediatek,mt7628an-soc";
> + model = "Jotale JS76x8 (32M)";
> +};
> +
> + {
> + reg = <0x5 0x1fb>;
> +};
> diff --git a/target/linux/ramips/dts/mt7628an_jotale_js76x8-8m.dts
> b/target/linux/ramips/dts/mt7628an_jotale_js76x8-8m.dts
> new file mode 100644
> index 000..8cac3fb
> --- /dev/null
> +++ b/target/linux/ramips/dts/mt7628an_jotale_js76x8-8m.dts
> @@ -0,0 +1,12 @@
> +/dts-v1/;
> +
> +#include "mt7628an_jotale_js76x8.dtsi"
> +
> +/ {
> + compatible = "jotale,js76x8-8m", "mediatek,mt7628an-soc";
> + model = "Jotale JS76x8 (8M)";
> +};
> +
> 

RE: [PATCH] toolchain: treewide add PKG_RELEASE if local files

[mail]

Hi Paul,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Paul Spooren
> Sent: Donnerstag, 23. Juli 2020 22:21
> To: openwrt-devel@lists.openwrt.org
> Cc: Paul Spooren 
> Subject: [PATCH] toolchain: treewide add PKG_RELEASE if local files
> 
> The toolchain packages partly contain local code like patches and
> configuration files. These files are not tracked via PKG_VERSION as this
> variable only covers the upstream package version.
> 
> To allow versioning of the buildsystem, this commit adds PKG_RELEASE:=1 to
> all toolchain packages with local files. Whenever a local file is changed the
> release must be increased.

This makes sense for the latter three, but I'm not sure whether it is a good 
idea for binutils and gcc, as those are effectively "multi-version" packages.

I will cut out the latter three and apply it for them for now.

Best

Adrian

> 
> Also update the copyright of touched files to 2020.
> 
> Signed-off-by: Paul Spooren 
> ---
>  toolchain/binutils/Makefile | 3 ++-
>  toolchain/gcc/common.mk | 3 ++-
>  toolchain/gdb/Makefile  | 3 ++-
>  toolchain/glibc/common.mk   | 3 ++-
>  toolchain/uClibc/common.mk  | 3 ++-
>  5 files changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/toolchain/binutils/Makefile b/toolchain/binutils/Makefile index
> c5c8bf588c..bb4fb73546 100644
> --- a/toolchain/binutils/Makefile
> +++ b/toolchain/binutils/Makefile
> @@ -1,5 +1,5 @@
>  #
> -# Copyright (C) 2006-2013 OpenWrt.org
> +# Copyright (C) 2006-2020 OpenWrt.org
>  #
>  # This is free software, licensed under the GNU General Public License v2.
>  # See /LICENSE for more information.
> @@ -8,6 +8,7 @@ include $(TOPDIR)/rules.mk
> 
>  PKG_NAME:=binutils
>  PKG_VERSION:=$(call qstrip,$(CONFIG_BINUTILS_VERSION))
> +PKG_RELEASE:=1
>  BIN_VERSION:=$(PKG_VERSION)
> 
>  PKG_SOURCE_URL:=@GNU/binutils/
> diff --git a/toolchain/gcc/common.mk b/toolchain/gcc/common.mk index
> eb0ddbf2d9..b45e14770b 100644
> --- a/toolchain/gcc/common.mk
> +++ b/toolchain/gcc/common.mk
> @@ -2,7 +2,7 @@
>  # Copyright (C) 2002-2003 Erik Andersen   # Copyright
> (C) 2004 Manuel Novoa III   # Copyright (C) 2005-2006 Felix
> Fietkau  -# Copyright (C) 2006-2014 OpenWrt.org
> +# Copyright (C) 2006-2020 OpenWrt.org
>  #
>  # This program is free software; you can redistribute it and/or modify  # it
> under the terms of the GNU General Public License as published by @@ -
> 23,6 +23,7 @@ include $(TOPDIR)/rules.mk  PKG_NAME:=gcc
> GCC_VERSION:=$(call qstrip,$(CONFIG_GCC_VERSION))
> PKG_VERSION:=$(firstword $(subst +, ,$(GCC_VERSION)))
> +PKG_RELEASE:=1
>  GCC_DIR:=$(PKG_NAME)-$(PKG_VERSION)
> 
>  PKG_SOURCE_URL:=@GNU/gcc/gcc-$(PKG_VERSION)
> diff --git a/toolchain/gdb/Makefile b/toolchain/gdb/Makefile index
> c25d181990..3452ac4dc7 100644
> --- a/toolchain/gdb/Makefile
> +++ b/toolchain/gdb/Makefile
> @@ -1,5 +1,5 @@
>  #
> -# Copyright (C) 2006-2016 OpenWrt.org
> +# Copyright (C) 2006-2020 OpenWrt.org
>  #
>  # This is free software, licensed under the GNU General Public License v2.
>  # See /LICENSE for more information.
> @@ -8,6 +8,7 @@ include $(TOPDIR)/rules.mk
> 
>  PKG_NAME:=gdb
>  PKG_VERSION:=8.3.1
> +PKG_RELEASE:=1
> 
>  PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
>  PKG_SOURCE_URL:=@GNU/gdb
> diff --git a/toolchain/glibc/common.mk b/toolchain/glibc/common.mk index
> 1a084d0862..9a9c4a5343 100644
> --- a/toolchain/glibc/common.mk
> +++ b/toolchain/glibc/common.mk
> @@ -1,5 +1,5 @@
>  #
> -# Copyright (C) 2006-2016 OpenWrt.org
> +# Copyright (C) 2006-2020 OpenWrt.org
>  #
>  # This is free software, licensed under the GNU General Public License v2.
>  # See /LICENSE for more information.
> @@ -8,6 +8,7 @@ include $(TOPDIR)/rules.mk
> 
>  PKG_NAME:=glibc
>  PKG_VERSION:=2.31
> +PKG_RELEASE:=1
> 
>  PKG_SOURCE_PROTO:=git
>  PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
> diff --git a/toolchain/uClibc/common.mk b/toolchain/uClibc/common.mk
> index 6f4c50c380..a79a838be4 100644
> --- a/toolchain/uClibc/common.mk
> +++ b/toolchain/uClibc/common.mk
> @@ -1,5 +1,5 @@
>  #
> -# Copyright (C) 2006-2012 OpenWrt.org
> +# Copyright (C) 2006-2020 OpenWrt.org
>  #
>  # This is free software, licensed under the GNU General Public License v2.
>  # See /LICENSE for more information.
> @@ -8,6 +8,7 @@ include $(TOPDIR)/rules.mk  include
> $(INCLUDE_DIR)/target.mk
> 
>  PKG_VERSION:=1.0.31
> +PKG_RELEASE:=1
> 
>  PKG_NAME:=uClibc-ng
>  PKG_SOURCE_URL = http://downloads.uclibc-
> ng.org/releases/$(PKG_VERSION)/
> --
> 2.25.1
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [PATCH] treewide: consistenly disable building of devices

[mail]

Hi Petr,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Petr Štetiar
> Sent: Montag, 27. Juli 2020 12:53
> To: openwrt-devel@lists.openwrt.org
> Cc: Petr Štetiar 
> Subject: [PATCH] treewide: consistenly disable building of devices
> 
> Since commit 7546be60074e ("build: allow overriding default selection state
> for devices") we can disable building of devices with `DEFAULT := n` construct
> which is prefered as those devices would still be available for use with Image
> Builder for example.

since it's only a few, I've actually looked at the individual devices and added 
my findings below.

If you are fine with that, I'd like to pick this up and do the following:

1. Create a treewide patch now for those cases where "DEFAULT := n" seems 
appropriate to me (size issues and "test support"), and add the findings (and 
commit references) below to the commit message for future reference.

2. Deal with the remaining "broken" devices separately later (and keep them 
commented out for now). I consider adding a BROKEN := y or similar for those 
devices, which then would hide devices unless a specific CONFIG option is set, 
similar to how we deal with broken packages right now. This will be assigned 
low priority on my to-do list, though.

Are you fine with that?

Device-specific comments below ...

> 
> Signed-off-by: Petr Štetiar 
> ---
>  target/linux/at91/image/sam9x.mk  |  3 ++-
>  target/linux/ath25/image/Makefile |  6 --
>  target/linux/bcm47xx/image/mips74k.mk | 12 
>  target/linux/bcm53xx/image/Makefile   | 18 --
>  4 files changed, 26 insertions(+), 13 deletions(-)
> 
> diff --git a/target/linux/at91/image/sam9x.mk
> b/target/linux/at91/image/sam9x.mk
> index 8fd6b4506f32..beff346725e6 100644
> --- a/target/linux/at91/image/sam9x.mk
> +++ b/target/linux/at91/image/sam9x.mk
> @@ -173,8 +173,9 @@ define Device/at91-q5xr5
>DEVICE_VENDOR := Exegin
>DEVICE_MODEL := Q5XR5
>KERNEL_SIZE := 2048k
> +  DEFAULT := n
>  endef
> -#TARGET_DEVICES += at91-q5xr5
> +TARGET_DEVICES += at91-q5xr5

too big: 
https://github.com/openwrt/openwrt/commit/31aeae07748254abf611f578efaced469c942dee

> 
>  define Device/wb45n
>$(Device/evaluation-fit)
> diff --git a/target/linux/ath25/image/Makefile
> b/target/linux/ath25/image/Makefile
> index e1ebb159cda6..5bfbaa38e68e 100644
> --- a/target/linux/ath25/image/Makefile
> +++ b/target/linux/ath25/image/Makefile
> @@ -99,15 +99,17 @@ define Device/np25g
>DEVICE_MODEL := NP25G
>KERNEL := kernel-bin | gzip-kernel
>IMAGE/sysupgrade.bin := append-rootfs | pad-rootfs | pad-to 128k |
> mkmylofw np25g
> +  DEFAULT := n
>  endef
> -#TARGET_DEVICES += np25g
> +TARGET_DEVICES += np25g
> 
>  define Device/wpe53g
>DEVICE_VENDOR := Compex
>DEVICE_MODEL := WPE53G
>KERNEL := kernel-bin | gzip-kernel
>IMAGE/sysupgrade.bin := append-rootfs | pad-rootfs | pad-to 128k |
> mkmylofw wpe53g
> +  DEFAULT := n
>  endef
> -#TARGET_DEVICES += wpe53g
> +TARGET_DEVICES += wpe53g

both ath25 devices disabled during kernel bump 3.18->4.4 without reason given:
https://github.com/openwrt/openwrt/commit/f89a20a89aebe4767c606b4e04a6a3906e1ee26c

> 
>  $(eval $(call BuildImage))
> diff --git a/target/linux/bcm47xx/image/mips74k.mk
> b/target/linux/bcm47xx/image/mips74k.mk
> index 6ca4d21e1f30..fb3c594c03c2 100644
> --- a/target/linux/bcm47xx/image/mips74k.mk
> +++ b/target/linux/bcm47xx/image/mips74k.mk
> @@ -15,8 +15,9 @@ define Device/asus-rt-ac66u
>DEVICE_PACKAGES := kmod-b43 $(USB2_PACKAGES)
>$(Device/asus)
>PRODUCTID := RT-AC66U
> +  DEFAULT := n
>  endef
> -#  TARGET_DEVICES += asus-rt-ac66u
> +TARGET_DEVICES += asus-rt-ac66u

This is commented out since it was added in 2015:
https://github.com/openwrt/openwrt/commit/69aefc771fd8a7d7450e856a5432fcc15cfc8fc9

I'd use DEFAULT := n here.

> 
>  define Device/asus-rt-n10
>DEVICE_MODEL := RT-N10
> @@ -399,8 +400,9 @@ define Device/netgear-wndr3400-vcna
>$(Device/netgear)
>NETGEAR_BOARD_ID := U12H155T01_NETGEAR
>NETGEAR_REGION := 2
> +  DEFAULT := n
>  endef
> -#  TARGET_DEVICES += netgear-wndr3400-vcna
> +TARGET_DEVICES += netgear-wndr3400-vcna
> 
>  define Device/netgear-wndr4000
>DEVICE_MODEL := WNDR4000
> @@ -467,8 +469,9 @@ define Device/netgear-wnr3500u
>$(Device/netgear)
>NETGEAR_BOARD_ID := U12H136T00_NETGEAR
>NETGEAR_REGION := 2
> +  DEFAULT := n
>  endef
> -#  TARGET_DEVICES += netgear-wnr3500u
> +TARGET_DEVICES += netgear-wnr3500u
> 
>  define Device/netgear-wnr3500-v2
>DEVICE_MODEL := WNR3500
> @@ -487,7 +490,8 @@ define Device/netgear-wnr3500-v2-vc
>$(Device/netgear)
>NETGEAR_BOARD_ID := U12H127T70_NETGEAR
>NETGEAR_REGION := 2
> +  DEFAULT := n
>  endef
> -#  TARGET_DEVICES += netgear-wnr3500-v2-vc
> +TARGET_DEVICES += netgear-wnr3500-v2-vc
> 

These have been added "without test" in 2012, and thus have been disabled from 
the beginning as well.

RE: [OpenWrt-Devel] [RFT PATCH] arc770: bump kernel to 5.4

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of m...@adrianschmutzler.de
> Sent: Montag, 27. Juli 2020 15:39
> To: 'Evgeniy Didin' ; 'Hauke Mehrtens'
> ; 'Alexey Brodkin' 
> Cc: openwrt-devel@lists.openwrt.org
> Subject: RE: [OpenWrt-Devel] [RFT PATCH] arc770: bump kernel to 5.4
> 
> > > @Evgeniy and @Alexey: Could you please test if this update to kernel
> > > 5.4
> > for the arc770 works basically.
> >
> > Thank you a lot for updating kernel to 5.4 for arc770! Unfortunately
> > we do not have access to boards with arc770, so we are not able to
> > test the image right now. By the way we ran Linux kernel v5.4(built by
> > buildroot)  on arc770 board and it worked well. I guess we can apply
> > this patch and if any issue appears we will fix it.
> 
> Just tried to build it based on recent master and with buildbot settings,
> ended with this error, though:
> 
> checking if we should build libunwind-ptrace... yes checking if we should
> build libunwind-setjmp... yes checking for build architecture... x86_64
> checking for host architecture... arc checking for target architecture... arc
> checking for target operating system... linux-gnu checking for ELF helper
> width... configure: error: Unknown ELF target: arc
> make[3]: *** [Makefile:65: /data/openwrt/build_dir/target-
> arc_arc700_uClibc/libunwind-
> 1.3.1/.configured_68b329da9893e34099c7d8ad5cb9c940] Error 1
> make[3]: Leaving directory '/data/openwrt/package/libs/libunwind'
> time: package/libs/libunwind/compile#11.36#1.63#14.15
> make[2]: *** [package/Makefile:113: package/libs/libunwind/compile] Error
> 2
> make[2]: Leaving directory '/data/openwrt'
> make[1]: *** [package/Makefile:107: /data/openwrt/staging_dir/target-
> arc_arc700_uClibc/stamp/.package_compile] Error 2
> make[1]: Leaving directory '/data/openwrt'
> make: *** [/data/openwrt/include/toplevel.mk:235: world] Error 2

I've found that the root cause is openvswitch selecting libunwind, and due to 
some mechanism I don't understand openvswitch isn't built anymore for 4.14 on 
buildbots already (though only for the most recent 4.14.x kernel version).

Since everything else is working, I decided to push 5.4 support now and will be 
curious whether buildbots run through or not.

Best

Adrian

> 
> Best
> 
> Adrian
> 
> >
> > Thanks and best regards,
> > Evgeniy Didin
> >
> > > If someone else has this hardware and can try this out, some
> > > feedback
> > would be nice.
> > >
> > > Hauke
> >
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [OpenWrt-Devel] [RFT PATCH] arc770: bump kernel to 5.4

[mail]

> > @Evgeniy and @Alexey: Could you please test if this update to kernel 5.4
> for the arc770 works basically.
> 
> Thank you a lot for updating kernel to 5.4 for arc770! Unfortunately we do
> not have access to boards with arc770, so we are not able to test the image
> right now. By the way we ran Linux kernel v5.4(built by buildroot)  on arc770
> board and it worked well. I guess we can apply this patch and if any issue
> appears we will fix it.

Just tried to build it based on recent master and with buildbot settings, ended 
with this error, though:

checking if we should build libunwind-ptrace... yes
checking if we should build libunwind-setjmp... yes
checking for build architecture... x86_64
checking for host architecture... arc
checking for target architecture... arc
checking for target operating system... linux-gnu
checking for ELF helper width... configure: error: Unknown ELF target: arc
make[3]: *** [Makefile:65: 
/data/openwrt/build_dir/target-arc_arc700_uClibc/libunwind-1.3.1/.configured_68b329da9893e34099c7d8ad5cb9c940]
 Error 1
make[3]: Leaving directory '/data/openwrt/package/libs/libunwind'
time: package/libs/libunwind/compile#11.36#1.63#14.15
make[2]: *** [package/Makefile:113: package/libs/libunwind/compile] Error 2
make[2]: Leaving directory '/data/openwrt'
make[1]: *** [package/Makefile:107: 
/data/openwrt/staging_dir/target-arc_arc700_uClibc/stamp/.package_compile] 
Error 2
make[1]: Leaving directory '/data/openwrt'
make: *** [/data/openwrt/include/toplevel.mk:235: world] Error 2

Best

Adrian

> 
> Thanks and best regards,
> Evgeniy Didin
> 
> > If someone else has this hardware and can try this out, some feedback
> would be nice.
> >
> > Hauke
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [PATCH] treewide: consistenly disable building of devices

[mail]

Hi Petr,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Petr Štetiar
> Sent: Montag, 27. Juli 2020 12:53
> To: openwrt-devel@lists.openwrt.org
> Cc: Petr Štetiar 
> Subject: [PATCH] treewide: consistenly disable building of devices

Typo: consistenly -> consistently

> 
> Since commit 7546be60074e ("build: allow overriding default selection state
> for devices") we can disable building of devices with `DEFAULT := n` construct
> which is prefered as those devices would still be available for use with Image
> Builder for example.

Generally, be aware that there are at least two reasons for devices being 
disabled:

1. The can't be built by buildbots because kernel/image gets too large
2. Device support is broken, e.g. after a kernel bump (That seems to be the 
case for tplink-archer-cx in bcm53xx)

I'm not sure whether it makes sense to use DEFAULT := n for all of the cases in 
category 2. E.g. I once disabled ath79/nand GL.inet images in 19.07 this way 
(by commenting out), as nand support for ath79 with 4.14 kernel is just broken 
and it simply does not make sense to build these devices there.

So, I generally think that there are cases where disabling a device by 
commenting it out makes sense. Unfortunately, following that idea would mean 
having to check the circumstances for all affected devices individually, i.e. 
much more work than needed for the current state of this PR.

I'm not sure yet whether my distinction between those two categories is really 
that much important, but I'd like to share these thoughts for discussion.

Best

Adrian



> 
> Signed-off-by: Petr Štetiar 
> ---
>  target/linux/at91/image/sam9x.mk  |  3 ++-
>  target/linux/ath25/image/Makefile |  6 --
>  target/linux/bcm47xx/image/mips74k.mk | 12 
>  target/linux/bcm53xx/image/Makefile   | 18 --
>  4 files changed, 26 insertions(+), 13 deletions(-)
> 
> diff --git a/target/linux/at91/image/sam9x.mk
> b/target/linux/at91/image/sam9x.mk
> index 8fd6b4506f32..beff346725e6 100644
> --- a/target/linux/at91/image/sam9x.mk
> +++ b/target/linux/at91/image/sam9x.mk
> @@ -173,8 +173,9 @@ define Device/at91-q5xr5
>DEVICE_VENDOR := Exegin
>DEVICE_MODEL := Q5XR5
>KERNEL_SIZE := 2048k
> +  DEFAULT := n
>  endef
> -#TARGET_DEVICES += at91-q5xr5
> +TARGET_DEVICES += at91-q5xr5
> 
>  define Device/wb45n
>$(Device/evaluation-fit)
> diff --git a/target/linux/ath25/image/Makefile
> b/target/linux/ath25/image/Makefile
> index e1ebb159cda6..5bfbaa38e68e 100644
> --- a/target/linux/ath25/image/Makefile
> +++ b/target/linux/ath25/image/Makefile
> @@ -99,15 +99,17 @@ define Device/np25g
>DEVICE_MODEL := NP25G
>KERNEL := kernel-bin | gzip-kernel
>IMAGE/sysupgrade.bin := append-rootfs | pad-rootfs | pad-to 128k |
> mkmylofw np25g
> +  DEFAULT := n
>  endef
> -#TARGET_DEVICES += np25g
> +TARGET_DEVICES += np25g
> 
>  define Device/wpe53g
>DEVICE_VENDOR := Compex
>DEVICE_MODEL := WPE53G
>KERNEL := kernel-bin | gzip-kernel
>IMAGE/sysupgrade.bin := append-rootfs | pad-rootfs | pad-to 128k |
> mkmylofw wpe53g
> +  DEFAULT := n
>  endef
> -#TARGET_DEVICES += wpe53g
> +TARGET_DEVICES += wpe53g
> 
>  $(eval $(call BuildImage))
> diff --git a/target/linux/bcm47xx/image/mips74k.mk
> b/target/linux/bcm47xx/image/mips74k.mk
> index 6ca4d21e1f30..fb3c594c03c2 100644
> --- a/target/linux/bcm47xx/image/mips74k.mk
> +++ b/target/linux/bcm47xx/image/mips74k.mk
> @@ -15,8 +15,9 @@ define Device/asus-rt-ac66u
>DEVICE_PACKAGES := kmod-b43 $(USB2_PACKAGES)
>$(Device/asus)
>PRODUCTID := RT-AC66U
> +  DEFAULT := n
>  endef
> -#  TARGET_DEVICES += asus-rt-ac66u
> +TARGET_DEVICES += asus-rt-ac66u
> 
>  define Device/asus-rt-n10
>DEVICE_MODEL := RT-N10
> @@ -399,8 +400,9 @@ define Device/netgear-wndr3400-vcna
>$(Device/netgear)
>NETGEAR_BOARD_ID := U12H155T01_NETGEAR
>NETGEAR_REGION := 2
> +  DEFAULT := n
>  endef
> -#  TARGET_DEVICES += netgear-wndr3400-vcna
> +TARGET_DEVICES += netgear-wndr3400-vcna
> 
>  define Device/netgear-wndr4000
>DEVICE_MODEL := WNDR4000
> @@ -467,8 +469,9 @@ define Device/netgear-wnr3500u
>$(Device/netgear)
>NETGEAR_BOARD_ID := U12H136T00_NETGEAR
>NETGEAR_REGION := 2
> +  DEFAULT := n
>  endef
> -#  TARGET_DEVICES += netgear-wnr3500u
> +TARGET_DEVICES += netgear-wnr3500u
> 
>  define Device/netgear-wnr3500-v2
>DEVICE_MODEL := WNR3500
> @@ -487,7 +490,8 @@ define Device/netgear-wnr3500-v2-vc
>$(Device/netgear)
>NETGEAR_BOARD_ID := U12H127T70_NETGEAR
>NETGEAR_REGION := 2
> +  DEFAULT := n
>  endef
> -#  TARGET_DEVICES += netgear-wnr3500-v2-vc
> +TARGET_DEVICES += netgear-wnr3500-v2-vc
> 
>  TARGET_DEVICES += standard standard-noloader-nodictionarylzma
> diff --git a/target/linux/bcm53xx/image/Makefile
> b/target/linux/bcm53xx/image/Makefile
> index 0e3779080233..90b3474fb885 100644
> --- a/target/linux/bcm53xx/image/Makefile
> +++ 

RE: [PATCH v2 0/6] sysupgrade: introduce compatibility version for devices

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Adrian Schmutzler
> Sent: Dienstag, 14. Juli 2020 16:28
> To: openwrt-devel@lists.openwrt.org
> Subject: [PATCH v2 0/6] sysupgrade: introduce compatibility version for
> devices

This has been lying around for two weeks now (plus the time since the v1 
submission), but unfortunately there has been not much feedback on it.

Since I think this really solves an important open issue not taken care of so 
far, I'm very eager to merge it.
I also considered to wait for the DSA config patch, but actually there have 
been several cases where I'd have needed this functionality already and I'm 
starting to lose track.

I'd thus add it to master end of this week, until somebody explicitly NAKs it 
or requests delay.
Note that I don't want to force it in, I just try to push it forward in case 
nobody really cares (as it appears to my ATM).

Best

Adrian

> 
> This revised patchset provides some polishing to the initial submission.
> 
> It does not change the mechanics substantially, but just provides some
> aesthetic improvements.
> 
> Notable functional changes:
> - compat version check is now executed _after_ the supported_devices
> check
> - the DEVICE_COMPAT_MESSAGE is now also printed for the legacy
> sysupgrade hack
> 
> Cosmetic changes:
> - The "error" message have been reworded to be more conclusive and
> provide
>   more information.
> 
> Further additions:
> - Instead of the example implementation patch for ath79, this now features
>   the actual implementation for swconfig->DSA change in mvebu and
> kirkwood.
>   (adding mt7621 will be considered after merge)
> 
> While v1 has been device-tested, I have not run-tested this patchset so far,
> as changes between them are mostly cosmetic and I want to wait for
> feedback first.
> 
> Adrian Schmutzler (6):
>   build: add DEVICE_COMPAT_VERSION and DEVICE_COMPAT_MESSAGE
>   base-files: add support for compat_version on device
>   base-files: fwtool: implement compatibility check for images
>   base-files: fwtool: make compat_version backward compatible
>   mvebu: implement compatibility version for DSA migration
>   kirkwood: implement compatibility version for DSA migration
> 
>  include/image-commands.mk | 10 --
>  include/image.mk  |  3 ++
>  package/base-files/files/bin/config_generate  |  7 +
>  .../files/lib/functions/uci-defaults.sh   |  6 
>  .../base-files/files/lib/upgrade/fwtool.sh| 31 +--
>  .../base-files/etc/board.d/02_network |  1 +
>  target/linux/kirkwood/image/Makefile  |  7 +
>  .../base-files/etc/board.d/02_network | 14 +
>  target/linux/mvebu/image/cortexa9.mk  | 19 
>  9 files changed, 88 insertions(+), 10 deletions(-)
> 
> --
> 2.20.1
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: ramips: mt7621 novel art_block partition

[mail]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Piotr Dymacz
> Sent: Montag, 27. Juli 2020 09:53
> To: Heppler, J. Scott ; openwrt-
> de...@openwrt.org
> Subject: Re: ramips: mt7621 novel art_block partition
> 
> Hi,
> 
> On 27.07.2020 03:30, Heppler, J. Scott wrote:
> > I came onto a Trendnet TEW-827DRU Version 2 that is MT7621an with
> > MT7615E x 2 wifi chips.  I was able to get UART output and stock has
> > these partitions:
> >
> > [2.512000] 0x-0x0100 : "ALL"
> > [2.52] 0x-0x0003 : "Bootloader"
> > [2.532000] 0x0003-0x0004 : "Config"
> > [2.544000] 0x0004-0x0005 : "Factory"
> > [2.552000] 0x0005-0x00ef : "firmware"
> > [2.564000] 0x0005-0x0038 : "kernel"
> > [2.576000] 0x0038-0x00ef : "rootfs"
> > [2.584000] 0x00ef-0x00ff : "rootfs_data"
> > [2.596000] 0x00ff-0x0100 : "art_block"
> >
> > I reviewed all the mt7621 *dts files and none have an art_block.
> 
> grep -rn "art_block" target/linux/ramips/dts/
> 
> target/linux/ramips/dts/mt7621_elecom_wrc-1900gst.dts:31: label =
> "art_block";
> target/linux/ramips/dts/mt7621_elecom_wrc-2533gst.dts:30: label =
> "art_block";
> target/linux/ramips/dts/mt7621_elecom_wrc-1750gs.dts:31:  label =
> "art_block";

Note that there might also be several cases where a partition labelled 
"art_block" has just been renamed to "art" for consistency within OpenWrt.

Best

Adrian

> 
> > My understanding is that for Qualcomm, the art* partition contains
> > Atheros calibration data. I'm lost as to what and art_block is on a
> > mediatek device.  Trendnet can be lazy with partition naming - the
> > TEW-810 has a partion referred to a D-Link.
> 
> Does this partition contain any data or is empty? I suppose you can just
> ignore it (keep it as read-only), it looks like copy mistake made by
> original board manufacturer.
> 
> --
> Cheers,
> Piotr
> 
> > I did find a "firmware2" partition -
> > mt7621_asus_rt-acx5p.dtsi, a "second_config" - mt7621_mtc_wr1201.dts
> > that are about the same size and position.
> >
> >
> > Are there any Mediatek experts that can enlighten me and point me in
> > the right direction?
> >
> > Thanks in advance
> >
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [PATCH v2 2/3] treewide: use wpad-basic-wolfssl as default

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Petr Štetiar
> Sent: Montag, 27. Juli 2020 11:57
> To: openwrt-devel@lists.openwrt.org
> Cc: Petr Štetiar 
> Subject: [PATCH v2 2/3] treewide: use wpad-basic-wolfssl as default
> 
> In order to support SAE/WPA3-Personal in default images. Replaced all
> occurencies of wpad-basic and wpad-mini with wpad-basic-wolfssl for
> consistency.

Hi,

as stated earlier, I'm fine with covering ath79/tiny etc. as well, but I'd 
personally not touch ar71xx.

Just in case you overlooked that beforehand; if this is also intentional 
(=consistency) it won't cry if you keep it, though.

Thanks for taking care of this stuff BTW.

Best

Adrian



> 
> Signed-off-by: Petr Štetiar 
> ---
> 
> changed in v2:
> 
>  * replacement of wpad-mini with wpad-basic-wolfssl for consistency
> 
>  target/linux/apm821xx/image/sata.mk   |   2 +-
>  target/linux/apm821xx/nand/target.mk  |   2 +-
>  .../apm821xx/sata/profiles/00-default.mk  |   2 +-
>  target/linux/ar71xx/generic/target.mk |   2 +-
>  target/linux/ar71xx/image/generic.mk  |   4 +-
>  target/linux/ar71xx/mikrotik/target.mk|   2 +-
>  target/linux/ar71xx/nand/target.mk|   2 +-
>  target/linux/ar71xx/tiny/target.mk|   2 +-
>  .../arc770/generic/profiles/00-default.mk |   2 +-
>  .../archs38/generic/profiles/00-default.mk|   2 +-
>  target/linux/ath25/Makefile   |   2 +-
>  target/linux/ath79/generic/target.mk  |   2 +-
>  target/linux/ath79/image/generic-ubnt.mk  |   2 +-
>  target/linux/ath79/image/generic.mk   |   4 +-
>  target/linux/ath79/mikrotik/target.mk |   2 +-
>  target/linux/ath79/nand/target.mk |   2 +-
>  target/linux/ath79/tiny/target.mk |   2 +-
>  target/linux/bcm27xx/image/Makefile   |   8 +-
>  .../generic/profiles/101-Broadcom-wl.mk   |   2 +-
>  .../generic/profiles/105-Broadcom-none.mk |   2 +-
>  .../generic/profiles/201-Broadcom-b44-wl.mk   |   2 +-
>  .../generic/profiles/205-Broadcom-b44-none.mk |   2 +-
>  .../generic/profiles/211-Broadcom-tg3-wl.mk   |   2 +-
>  .../generic/profiles/215-Broadcom-tg3-none.mk |   2 +-
>  .../generic/profiles/221-Broadcom-bgmac-wl.mk |   2 +-
>  .../profiles/225-Broadcom-bgmac-none.mk   |   2 +-
>  .../bcm47xx/generic/profiles/PS-1208MFG.mk|   2 +-
>  target/linux/bcm47xx/generic/target.mk|   2 +-
>  .../legacy/profiles/101-Broadcom-wl.mk|   2 +-
>  target/linux/bcm47xx/legacy/target.mk |   2 +-
>  .../mips74k/profiles/102-Broadcom-wl.mk   |   2 +-
>  .../mips74k/profiles/103-Broadcom-none.mk |   2 +-
>  target/linux/bcm47xx/mips74k/target.mk|   2 +-
>  target/linux/bcm53xx/image/Makefile   |   2 +-
>  target/linux/bcm63xx/image/Makefile   |  10 +-
>  target/linux/bcm63xx/profiles/default.mk  |   2 +-
>  target/linux/cns3xxx/Makefile |   2 +-
>  target/linux/ipq40xx/Makefile |   2 +-
>  target/linux/ipq806x/Makefile |   2 +-
>  target/linux/kirkwood/image/Makefile  |   6 +-
>  target/linux/kirkwood/profiles/00-default.mk  |   2 +-
>  target/linux/lantiq/image/ar9.mk  |  18 +--
>  target/linux/lantiq/image/danube.mk   |  24 ++--
>  target/linux/lantiq/image/tp-link.mk  |   8 +-
>  target/linux/lantiq/image/vr9.mk  |  30 ++---
>  target/linux/lantiq/image/xway_legacy.mk  |  10 +-
>  target/linux/malta/Makefile   |   2 +-
>  target/linux/mediatek/mt7622/target.mk|   2 +-
>  target/linux/mpc85xx/Makefile |   2 +-
>  target/linux/mvebu/image/cortexa9.mk  |   4 +-
>  target/linux/omap/profiles/00-default.mk  |   2 +-
>  target/linux/oxnas/image/ox820.mk |   2 +-
>  target/linux/ramips/image/mt7620.mk   |   2 +-
>  target/linux/ramips/image/mt7621.mk   | 124 +-
>  target/linux/ramips/mt7620/target.mk  |   2 +-
>  target/linux/ramips/mt76x8/target.mk  |   2 +-
>  target/linux/ramips/rt288x/target.mk  |   2 +-
>  target/linux/ramips/rt305x/target.mk  |   2 +-
>  target/linux/ramips/rt3883/target.mk  |   2 +-
>  target/linux/rb532/Makefile   |   2 +-
>  target/linux/sunxi/image/cortexa7.mk  |   8 +-
>  target/linux/sunxi/profiles/00-default.mk |   2 +-
>  target/linux/tegra/image/Makefile |   2 +-
>  target/linux/uml/Makefile |   2 +-
>  64 files changed, 180 insertions(+), 180 deletions(-)
> 
> diff --git a/target/linux/apm821xx/image/sata.mk
> b/target/linux/apm821xx/image/sata.mk
> index 6fe8324b93ac..bcb612c22f1d 100644
> --- a/target/linux/apm821xx/image/sata.mk
> +++ b/target/linux/apm821xx/image/sata.mk
> @@ -6,7 +6,7 @@ endef
>  define Device/wd_mybooklive
>DEVICE_VENDOR := Western Digital
>

RE: [PATCH 4/4] lantiq: disable default build for devices with 4M flash

[mail]

> -Original Message-
> From: Paul Spooren [mailto:m...@aparcar.org]
> Sent: Samstag, 25. Juli 2020 23:19
> To: Adrian Schmutzler ; openwrt-
> de...@lists.openwrt.org
> Subject: Re: [PATCH 4/4] lantiq: disable default build for devices with 4M
> flash
> 
> On 25.07.20 08:29, Adrian Schmutzler wrote:
> > It has been decided that the 19.07 release will be last one to include
> > 4/32 devices.
> >
> > This disables default build for all devices with 4M flash on lantiq.
> > Note that this will affect _all_ devices for amazonse ("ase") and
> > xway_legacy subtarget.
> Isn't it cleaner to add the "source-only" feature to xway_legacy/target.mk
> and ase/target.mk? Or is it device specific because new devices for either
> subtarget are expected?

I'm not sure what source-only exactly does. I'll look it up.

The aim is that users are still able to build those devices with adjusted 
settings, both with imagebuilder and make menuconfig, at least in principle.

Best

Adrian

> >
> > Signed-off-by: Adrian Schmutzler 
> >
> > ---
> >
> > As this will effectively empty ase und xway_legacy subtarget, we
> > essentially can disable the buildbots on master for those right away.
> > ---
> >   target/linux/lantiq/image/amazonse.mk| 4 +++-
> >   target/linux/lantiq/image/danube.mk  | 3 +++
> >   target/linux/lantiq/image/falcon.mk  | 2 ++
> >   target/linux/lantiq/image/xway_legacy.mk | 5 +
> >   4 files changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/target/linux/lantiq/image/amazonse.mk
> > b/target/linux/lantiq/image/amazonse.mk
> > index 4a23a68e40..1fd714dee4 100644
> > --- a/target/linux/lantiq/image/amazonse.mk
> > +++ b/target/linux/lantiq/image/amazonse.mk
> > @@ -5,16 +5,18 @@ define Device/allnet_all0333cj
> > DEVICE_PACKAGES := kmod-ltq-adsl-ase kmod-ltq-adsl-ase-mei \
> > kmod-ltq-adsl-ase-fw-b kmod-ltq-atm-ase \
> > ltq-adsl-app ppp-mod-pppoe
> > +  DEFAULT := n
> >   endef
> >   TARGET_DEVICES += allnet_all0333cj
> >
> >   define Device/netgear_dgn1000b
> > DEVICE_VENDOR := NETGEAR
> > DEVICE_MODEL := DGN1000B
> > -  IMAGE_SIZE := 6000k
> > +  IMAGE_SIZE := 3712k
> > DEVICE_PACKAGES := kmod-ltq-adsl-ase kmod-ltq-adsl-ase-mei \
> > kmod-ltq-adsl-ase-fw-b kmod-ltq-atm-ase \
> > ltq-adsl-app ppp-mod-pppoe
> > SUPPORTED_DEVICES += DGN1000B
> > +  DEFAULT := n
> >   endef
> >   TARGET_DEVICES += netgear_dgn1000b
> > diff --git a/target/linux/lantiq/image/danube.mk
> > b/target/linux/lantiq/image/danube.mk
> > index 2fb5ea061f..6ba9a91fb2 100644
> > --- a/target/linux/lantiq/image/danube.mk
> > +++ b/target/linux/lantiq/image/danube.mk
> > @@ -29,6 +29,7 @@ define Device/arcadyan_arv4519pw
> > kmod-ltq-adsl-danube-fw-a kmod-ltq-atm-danube \
> > ltq-adsl-app ppp-mod-pppoa
> > SUPPORTED_DEVICES += ARV4519PW
> > +  DEFAULT := n
> >   endef
> >   TARGET_DEVICES += arcadyan_arv4519pw
> >
> > @@ -110,6 +111,7 @@ define Device/arcadyan_arv7525pw
> > kmod-ltq-adsl-danube-fw-b kmod-ltq-atm-danube \
> > ltq-adsl-app ppp-mod-pppoa -swconfig
> > SUPPORTED_DEVICES += ARV4510PW
> > +  DEFAULT := n
> >   endef
> >   TARGET_DEVICES += arcadyan_arv7525pw
> >
> > @@ -201,6 +203,7 @@ define Device/lantiq_easy50712
> > DEVICE_MODEL := Danube (EASY50712)
> > SOC := danube
> > IMAGE_SIZE := 3776k
> > +  DEFAULT := n
> >   endef
> >   TARGET_DEVICES += lantiq_easy50712
> >
> > diff --git a/target/linux/lantiq/image/falcon.mk
> > b/target/linux/lantiq/image/falcon.mk
> > index a5490f6e68..6269cf6858 100644
> > --- a/target/linux/lantiq/image/falcon.mk
> > +++ b/target/linux/lantiq/image/falcon.mk
> > @@ -57,6 +57,7 @@ define Device/lantiq_easy98000-nand
> > DEVICE_VARIANT := NAND
> > IMAGE_SIZE := 3904k
> > DEVICE_PACKAGES := kmod-dm9000 kmod-i2c-lantiq kmod-eeprom-at24
> > +  DEFAULT := n
> >   endef
> >   TARGET_DEVICES += lantiq_easy98000-nand
> >
> > @@ -66,6 +67,7 @@ define Device/lantiq_easy98000-nor
> > DEVICE_VARIANT := NOR
> > IMAGE_SIZE := 3904k
> > DEVICE_PACKAGES := kmod-dm9000 kmod-i2c-lantiq kmod-eeprom-at24
> > +  DEFAULT := n
> >   endef
> >   TARGET_DEVICES += lantiq_easy98000-nor
> >
> > diff --git a/target/linux/lantiq/image/xway_legacy.mk
> > b/target/linux/lantiq/image/xway_legacy.mk
> > index 52a29ab2f0..2eaefd2cdd 100644
> > --- a/target/linux/lantiq/image/xway_legacy.mk
> > +++ b/target/linux/lantiq/image/xway_legacy.mk
> > @@ -8,6 +8,7 @@ define Device/arcadyan_arv4518pwr01
> > ltq-adsl-app ppp-mod-pppoa \
> > kmod-ath5k wpad-mini
> > SUPPORTED_DEVICES += ARV4518PWR01
> > +  DEFAULT := n
> >   endef
> >   TARGET_DEVICES += arcadyan_arv4518pwr01
> >
> > @@ -21,6 +22,7 @@ define Device/arcadyan_arv4518pwr01a
> > ltq-adsl-app ppp-mod-pppoa \
> > kmod-ath5k wpad-basic
> > SUPPORTED_DEVICES += ARV4518PWR01A
> > +  DEFAULT := n
> >   endef
> >   TARGET_DEVICES += arcadyan_arv4518pwr01a
> >
> > @@ -38,6 +40,7 @@ define Device/arcadyan_arv4520pw
> > ltq-adsl-app 

RE: [PATCH 1/1] tools: add firmware utils for linksys-addfwhdr generation. Needed for openwrt-factory flashing over the stock WEB interface for Linksys E8350-v1(and other linksys devices) The tool sou

[mail]

Hi Todor,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Todor Colov
> Sent: Samstag, 25. Juli 2020 18:30
> To: openwrt-devel@lists.openwrt.org
> Cc: Todor Colov 
> Subject: [PATCH 1/1] tools: add firmware utils for linksys-addfwhdr
> generation. Needed for openwrt-factory flashing over the stock WEB
> interface for Linksys E8350-v1(and other linksys devices) The tool source 
> files
> for "addfwhdr" are placed in a separate sub-direc

some formal advice for submitting patches, now that you have resubmitted some 
of yours a few times:

1. If you send the same patch with changes, please add a v2, v3 etc. to the 
[PATCH] prefix, so everyone can see which is the most recent version.
As some help for the reviewers, it is convenient to add the changes in each 
version below a line with "---" after the commit message.
This can be done automatically with "git format-patch -v2", where the "-v2" 
adds a "v2" to the patches.

2. Cover-letters are meant for patchsets with several changes. If you send a 
single patch, it is more convenient to include the information in the commit 
message of the patch; either before the "---" for relevant information that 
should be included when the patch is merged, or after the "---" for 
remotely/less important additional info that will be removed automatically when 
somebody picks that patch. The cover letter then is not necessary at all.
However, in your case, it appears that you should actually should send your 
patches together as a "patchset", as they depend on each other. In that case, a 
single cover letter for multiple patches actually makes sense, to explain the 
aim of the patchset as a whole, while the commit message describes the 
individual patches. This is achieved by running format-patch on a set of 
patches, e.g. "git format-patch @~3 -v2 --cover-letter" to format the last 
three patches relative to your current checkout.

3. Please format your commit message properly. In this patch, all you commit 
message is recognized as title, as you see by the mail subject. I never had 
this case myself, but I suspect it is created if you don't have an empty line 
after the commit title.

Best

Adrian


> 
> Signed-off-by: Todor Colov 
> ---
>  tools/firmware-utils/Makefile |   4 +-
>  tools/firmware-utils/src/linksys/addfwhdr.c   | 195 
>  tools/firmware-utils/src/linksys/bcmdefs.h| 318 +
>  .../firmware-utils/src/linksys/code_pattern.h | 396 
>  tools/firmware-utils/src/linksys/crc.c| 290 
>  tools/firmware-utils/src/linksys/crc.h|  69 +++
>  tools/firmware-utils/src/linksys/cyutils.h| 348 ++
>  tools/firmware-utils/src/linksys/typedefs.h   | 447 ++
>  8 files changed, 2066 insertions(+), 1 deletion(-)
>  create mode 100644 tools/firmware-utils/src/linksys/addfwhdr.c
>  create mode 100644 tools/firmware-utils/src/linksys/bcmdefs.h
>  create mode 100644 tools/firmware-utils/src/linksys/code_pattern.h
>  create mode 100644 tools/firmware-utils/src/linksys/crc.c
>  create mode 100644 tools/firmware-utils/src/linksys/crc.h
>  create mode 100644 tools/firmware-utils/src/linksys/cyutils.h
>  create mode 100644 tools/firmware-utils/src/linksys/typedefs.h
> 
> diff --git a/tools/firmware-utils/Makefile b/tools/firmware-utils/Makefile
> index 3dd9ac5c2c..0948e69013 100644
> --- a/tools/firmware-utils/Makefile
> +++ b/tools/firmware-utils/Makefile
> @@ -23,6 +23,8 @@ endef
> 
>  define Host/Compile
>   mkdir -p $(HOST_BUILD_DIR)/bin
> + mkdir -p $(HOST_BUILD_DIR)/bin/linksys
> + $(call cc,linksys/addfwhdr linksys/crc )
>   $(call cc,add_header)
>   $(call cc,addpattern)
>   $(call cc,asustrx)
> @@ -97,7 +99,7 @@ define Host/Compile
>  endef
> 
>  define Host/Install
> - $(INSTALL_BIN) $(HOST_BUILD_DIR)/bin/*
> $(STAGING_DIR_HOST)/bin/
> + $(CP) $(HOST_BUILD_DIR)/bin/* $(STAGING_DIR_HOST)/bin/
>  endef
> 
>  $(eval $(call HostBuild))
> diff --git a/tools/firmware-utils/src/linksys/addfwhdr.c b/tools/firmware-
> utils/src/linksys/addfwhdr.c
> new file mode 100644
> index 00..6e2896c62d
> --- /dev/null
> +++ b/tools/firmware-utils/src/linksys/addfwhdr.c
> @@ -0,0 +1,195 @@
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "cyutils.h"
> +#include "code_pattern.h"
> +
> +#include "typedefs.h"
> +
> +#define MAX_BUF  1024
> +#define CRC32_INIT_VALUE 0x  /* Initial CRC32 checksum
> value */
> +
> +ex

RE: [PATCH 2/3] treewide: use wpad-basic-wolfssl as default

[mail]

> Understandably so. But like you said, they already have limited functionality
> at this point: wpad-mini versus wpad-basic. At the same time, a lot of those
> devices are EOL with 19.07, as you pointed out. So it would make more sense
> to just keep them on wpad-mini - and maybe, to make the end of support
> crystal clear, to disable builds for 4/32 images altogether from 20.0x on.

That's mostly been done already; many if not the majority of at least 4 MB 
flash devices already have DEFAULT := n set.
This has been applied in bunches already as well, e.g.:

https://github.com/openwrt/openwrt/commit/d7d46da938e3f5c4ace815870c95f67d8b663ebe
https://github.com/openwrt/openwrt/commit/8819faff47ff20cfe81d58ef26c6a9054b142b74

This fact was the essence of my initial thought: if we have an entire subtarget 
like ath79/tiny that won't be built _by default_, we don't need to apply this 
patch there, as we won't built any images with these settings anyway.

However, I also see the point of the adverse argument that if it has to be 
altered by people for local builds anyway, there is no need to keep it 
inconsistent with recent changes (in contrast to ar71xx, which is not supposed 
to be built with master at all); people can just remove wpad-basic-wolfssl and 
switch back to wpad-mini again, as long as that's generally possible. (For a 
downstream project we have been switching to hostapd-mini already due to size 
constraints, so it won't matter much what exactly we remove there then.)

So, after all, 1. there won't be any 4 MB images build be default in 20.xx 
release, and 2. I personally can live with both options, keeping wpad-mini or 
replacing it for ath79/tiny and similar.

> devices like those in ath79/tiny, bcm47xx/legacy, lantiq/xway_legacy, 
> rt288x, rt305x,
> rt3883 and tegra (all those with wpad-mini).

Note that ramips/rt are still on 4.14 kernel, and if that's not changed 
soon they will be removed for 20.xx release entirely (i.e. deleted in stable 
branch, not just set to DEFAULT := n).

Best

Adrian 


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [PATCH 2/3] treewide: use wpad-basic-wolfssl as default

[mail]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Petr Štetiar
> Sent: Freitag, 24. Juli 2020 16:30
> To: openwrt-devel@lists.openwrt.org
> Cc: Petr Štetiar 
> Subject: [PATCH 2/3] treewide: use wpad-basic-wolfssl as default
> 
> In order to support SAE/WPA3-Personal in default images.

just a side-note:

I would prefer to not touch ar71xx here, as this is essentially only used for 
backporting, and changing stuff would only make these backports more 
complicated, while not really providing a benefit. (I'm not sure whether it can 
be still built with master at all.)

Despite, is my impression correct that this patchset won't affect the size of 
pure "tiny" targets, like ath79/tiny?

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [PATCH] tools: Add PKG_VERSION to sstrip

[mail]

> > This obviously applies to all the similar patches you sent in parallel.
> > Despite, note that the common practice for PKG_RELEASE is to use plain
> integer numbers, so no major.minor. I don't think that's as important as my
> first point, but I'd say only deviate from the plain integer numbers when
> having a reason (since, actually, if the code remains untouched for several
> years, nobody will maintain a reasonable major/minor versioning anyway,
> and it's easier to just bump by "1" on each change).
> >
> > Personally, to be honest, I'd just add PKG_RELEASE := 1 to all of the
> previously unversioned packages.
> Isn't it cleaner to state the upstream version of a package in the Makefile
> even if the code is stored locally? I know sstrip is locally patch-hacked but 
> I
> think it's better to state version 2.0 instead of release 1. Let's say 
> version 3.1a
> brings some legit binary size improvements, no one could tell by reading
> release 1.

If there really is an upstream version and the local code is still in a state 
where tracking that version makes sense, I'm all in for using that.
I'd even use PKG_VERSION and PKG_RELEASE then, as for any real package with 
upstream content.

If the code is truly local, or in a state where it cannot be compared with an 
"upstream" version reasonably, I'd go for plain PKG_RELEASE.

Best

Adrian

> >> Motivation is the tracking of changes in the buildsystem, which
> >> requires versioning of packages.
> >>
> >> [0]:
> >>
> https://github.com/BR903/ELFkickers/commit/df4426a0f0ada861064d75c08c
> >> bebaac7c16b3ae#diff-d3ba694d91432a068d5d3b36abf8cd0f
> >>
> >> Signed-off-by: Paul Spooren 
> >> ---
> >>   tools/sstrip/Makefile | 1 +
> >>   1 file changed, 1 insertion(+)
> >>
> >> diff --git a/tools/sstrip/Makefile b/tools/sstrip/Makefile index
> >> 180bd1743e..99be063f4c 100644
> >> --- a/tools/sstrip/Makefile
> >> +++ b/tools/sstrip/Makefile
> >> @@ -7,6 +7,7 @@
> >>   include $(TOPDIR)/rules.mk
> >>
> >>   PKG_NAME:=sstrip
> >> +PKG_VERSION:=2.0
> >>
> >>   include $(INCLUDE_DIR)/host-build.mk
> >>
> >> --
> >> 2.25.1
> >>
> >>
> >> ___
> >> openwrt-devel mailing list
> >> openwrt-devel@lists.openwrt.org
> >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [PATCH] tools: Add PKG_VERSION to sstrip

[mail]

Hi Paul,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Paul Spooren
> Sent: Donnerstag, 23. Juli 2020 00:15
> To: openwrt-devel@lists.openwrt.org
> Cc: Paul Spooren 
> Subject: [PATCH] tools: Add PKG_VERSION to sstrip
> 
> Comparing the in tree stored source file of sstrip suggests it's version 
> 2.0[0],
> reflect that in the Makefile.

note that conceptually, PKG_VERSION is for _external_ packages:

https://openwrt.org/docs/guide-developer/packages#buildpackage_variables

"PKG_VERSION - The upstream version number that we're downloading"

So, effectively this is to be used when there is some PKG_SOURCE_URL in the 
file.

For packages that just consist of "local" code, one should just use 
"PKG_RELEASE".

Actually, I've only recently enforced that for the package directory:

https://github.com/openwrt/openwrt/commit/9c170cb92f4fbb316592c11567a080eb3f6a1fc3

I'd be happy if we could (continue to) follow that same scheme for the packages 
in tools as well.

For your ultimate goal, it shouldn't matter anyway, just replace the 
PKG_VERSION by PKG_RELEASE where we are using local code/there is no external 
code pulled.

This obviously applies to all the similar patches you sent in parallel.

Despite, note that the common practice for PKG_RELEASE is to use plain integer 
numbers, so no major.minor. I don't think that's as important as my first 
point, but I'd say only deviate from the plain integer numbers when having a 
reason (since, actually, if the code remains untouched for several years, 
nobody will maintain a reasonable major/minor versioning anyway, and it's 
easier to just bump by "1" on each change).

Personally, to be honest, I'd just add PKG_RELEASE := 1 to all of the 
previously unversioned packages.

Best

Adrian


> 
> Motivation is the tracking of changes in the buildsystem, which requires
> versioning of packages.
> 
> [0]:
> https://github.com/BR903/ELFkickers/commit/df4426a0f0ada861064d75c08c
> bebaac7c16b3ae#diff-d3ba694d91432a068d5d3b36abf8cd0f
> 
> Signed-off-by: Paul Spooren 
> ---
>  tools/sstrip/Makefile | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tools/sstrip/Makefile b/tools/sstrip/Makefile index
> 180bd1743e..99be063f4c 100644
> --- a/tools/sstrip/Makefile
> +++ b/tools/sstrip/Makefile
> @@ -7,6 +7,7 @@
>  include $(TOPDIR)/rules.mk
> 
>  PKG_NAME:=sstrip
> +PKG_VERSION:=2.0
> 
>  include $(INCLUDE_DIR)/host-build.mk
> 
> --
> 2.25.1
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [OpenWrt-Devel] [RFT PATCH] arc770: bump kernel to 5.4

[mail]

Hi Hauke,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Hauke Mehrtens
> Sent: Montag, 25. Mai 2020 15:56
> To: Evgeniy Didin ; Alexey Brodkin
> 
> Cc: Adrian Schmutzler ; openwrt-
> de...@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] [RFT PATCH] arc770: bump kernel to 5.4
> 
> On 4/13/20 12:33 PM, Adrian Schmutzler wrote:
> > Update config with make kernel_oldconfig and copy patch.
> >
> > Directly switch to kernel 5.4.
> >
> > Signed-off-by: Adrian Schmutzler 
> >
> > ---
> >
> > I just stupidly copied/refreshed the patch and the config.
> >
> > Build-tested, run-test required as I have no hardware.
> 
> Hi Evgeniy and Alexey,
> 
> Could you please test, if this patch works?
> 
> We would like to get all targets to kernel 5.4 for the next release and this 
> is
> one of the targets still at an older kernel. Adrian and I do not have any
> hardware to test this.

just looked at this one again. This target appears to be upstream with almost 
no local adjustments.

I wonder whether I should just push the kernel bump to master if it builds 
fine, without a device test. (would do a new refresh and build-test beforehand, 
of course). Nobody seems to care anyway.

Do you have an opinion here?

Best

Adrian


> 
> You can find this patch also on patchwork:
> https://patchwork.ozlabs.org/project/openwrt/patch/20200413103352.7429-
> 1-freif...@adrianschmutzler.de/
> 
> Hauke
> 
> >
> > ---
> >  target/linux/arc770/Makefile  |   2 +-
> >  target/linux/arc770/config-5.4| 198 ++
> >  ...c-Disable-frame-filtering-completely.patch |  31 +++
> >  3 files changed, 230 insertions(+), 1 deletion(-)  create mode 100644
> > target/linux/arc770/config-5.4  create mode 100644
> > target/linux/arc770/patches-5.4/700-stmmac-Disable-frame-filtering-com
> > pletely.patch
> >
> > diff --git a/target/linux/arc770/Makefile
> > b/target/linux/arc770/Makefile index 8150f147c5..a182ef16a5 100644
> > --- a/target/linux/arc770/Makefile
> > +++ b/target/linux/arc770/Makefile
> > @@ -11,7 +11,7 @@ BOARD:=arc770
> >  BOARDNAME:=Synopsys DesignWare ARC 770D  SUBTARGETS:=generic
> >
> > -KERNEL_PATCHVER:=4.14
> > +KERNEL_PATCHVER:=5.4
> >
> >  DEVICE_TYPE:=developerboard
> >
> > diff --git a/target/linux/arc770/config-5.4
> > b/target/linux/arc770/config-5.4 new file mode 100644 index
> > 00..ce712b4c34
> > --- /dev/null
> > +++ b/target/linux/arc770/config-5.4
> > @@ -0,0 +1,198 @@
> > +# CONFIG_16KSTACKS is not set
> > +CONFIG_ARC=y
> > +CONFIG_ARCH_32BIT_OFF_T=y
> > +CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
> > +CONFIG_ARCH_HAS_DMA_COHERENT_TO_PFN=y
> > +CONFIG_ARCH_HAS_DMA_PREP_COHERENT=y
> > +CONFIG_ARCH_HAS_PTE_SPECIAL=y
> > +CONFIG_ARCH_HAS_SETUP_DMA_OPS=y
> > +CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU=y
> > +CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE=y
> > +CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y
> > +CONFIG_ARC_BUILTIN_DTB_NAME=""
> > +CONFIG_ARC_CACHE=y
> > +CONFIG_ARC_CACHE_LINE_SHIFT=5
> > +CONFIG_ARC_CACHE_PAGES=y
> > +# CONFIG_ARC_CACHE_VIPT_ALIASING is not set #
> > +CONFIG_ARC_COMPACT_IRQ_LEVELS is not set #
> CONFIG_ARC_CPU_750D is not
> > +set CONFIG_ARC_CPU_770=y CONFIG_ARC_CURR_IN_REG=y
> CONFIG_ARC_DBG=y #
> > +CONFIG_ARC_DBG_TLB_PARANOIA is not set
> CONFIG_ARC_DW2_UNWIND=y
> > +CONFIG_ARC_EMUL_UNALIGNED=y #
> CONFIG_ARC_FPU_SAVE_RESTORE is not set
> > +CONFIG_ARC_HAS_DCACHE=y # CONFIG_ARC_HAS_DCCM is not set
> > +CONFIG_ARC_HAS_ICACHE=y # CONFIG_ARC_HAS_ICCM is not set
> > +CONFIG_ARC_HAS_LLSC=y CONFIG_ARC_HAS_SWAPE=y
> > +CONFIG_ARC_KVADDR_SIZE=256
> > +# CONFIG_ARC_METAWARE_HLINK is not set # CONFIG_ARC_MMU_V1
> is not set
> > +# CONFIG_ARC_MMU_V2 is not set CONFIG_ARC_MMU_V3=y #
> > +CONFIG_ARC_PAGE_SIZE_16K is not set # CONFIG_ARC_PAGE_SIZE_4K is
> not
> > +set CONFIG_ARC_PAGE_SIZE_8K=y CONFIG_ARC_PLAT_AXS10X=y #
> > +CONFIG_ARC_PLAT_EZNPS is not set # CONFIG_ARC_PLAT_TB10X is not
> set
> > +CONFIG_ARC_TIMERS=y CONFIG_AXS101=y
> CONFIG_CC_HAS_KASAN_GENERIC=y #
> > +CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE_O3 is not set
> > +CONFIG_CLKDEV_LOOKUP=y CONFIG_CLONE_BACKWARDS=y
> CONFIG_COMMON_CLK=y
> > +CONFIG_COMPAT_32BIT_TIME=y CONFIG_CPU_NO_EFFICIENT_FFS=y
> > +CONFIG_CRC16=y CONFIG_CRYPTO_CRC32C=y
> CONFIG_CRYPTO_HASH=y
> > +CONFIG_CRYPTO_HASH2=y CONFIG_CRYPTO_RNG2=y
> CONFIG_DMA_DIRECT_REMAP=y
> > +CONFIG_DMA_REMAP=y CONFIG_DTC=y CONFIG_DWMAC_ANARION=y
> > +CONFIG_DWMAC_GENERIC=y CONFIG_DW_APB_ICTL=y
> CONFIG_EXT4_FS=y #
> > +CONFIG_EZNPS_GIC is not set CONFIG_FIXED_PHY=y
> CONFIG_FS_IOMAP=y
> > +CONFIG_FS_MBCACHE=y CONFIG_FW_LOADER_PAGED_BUF=y
> > +CONFIG_GENERIC_ALLOCATOR=y CONFIG_GENERIC_ATOMIC64=y
> > +CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CSUM=y
> > +CONFIG_GENERIC_FIND_FIRST_BIT=y CONFIG_GENERIC_IRQ_CHIP=y
> > +CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_PCI_IOMAP=y
> > +CONFIG_GENERIC_SCHED_CLOCK=y
> CONFIG_GENERIC_SMP_IDLE_THREAD=y
> > +CONFIG_GPIOLIB=y CONFIG_GPIO_DWAPB=y
> CONFIG_GPIO_GENERIC=y #
> > 

RE: [PATCH 19.07] ramips: add support for Asus RT-N10P V3 / RT-N11P B1 / RT-N12 VP B1

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Ernst Spielmann
> Sent: Samstag, 18. Juli 2020 14:24
> To: openwrt-devel@lists.openwrt.org
> Cc: Ernst Spielmann 
> Subject: [PATCH 19.07] ramips: add support for Asus RT-N10P V3 / RT-N11P
> B1 / RT-N12 VP B1

Hi,

device support backport typically does not happen:

https://openwrt.org/docs/guide-developer/device-support-policies#backports

I will leave this open in case one of the committers is specifically 
interested, and will mark it "Rejected" if nothing happens for a few weeks.

Best

Adrian

> 
> Specifications:
> 
> - MT7628NN @ 580 MHz
> - 32 MB RAM
> - 8 MB Flash
> - 5x 10/100 Mbps Ethernet (built-in switch)
> - 2.4 GHz WLAN
> - 2x external, non-detachable antennas (1x for RT-N10P V3)
> 
> Flash instructions:
> 
> 1. Set PC network interface to 192.168.1.75/24.
> 2. Connect PC to the router via LAN.
> 3. Turn router off, press and hold reset button, then turn it on.
> 4. Keep the button pressed till power led starts to blink.
> 5. Upload the firmware file via TFTP. (Any filename is accepted.) 6. Wait 
> until
> the router reboots.
> 
> Signed-off-by: Ernst Spielmann 
> ---
> Backport commit c3dc52e39ac83704b7a376d8d5610bdb91807e3f
>  .../ramips/base-files/etc/board.d/01_leds |   6 ++
>  .../ramips/base-files/etc/board.d/02_network  |   3 +
>  .../ramips/dts/mt7628an_asus_rt-n10p-v3.dts   |  34 ++
>  .../ramips/dts/mt7628an_asus_rt-n11p-b1.dts   |  34 ++
>  .../ramips/dts/mt7628an_asus_rt-n12-vp-b1.dts |  34 ++
>  .../ramips/dts/mt7628an_asus_rt-n1x.dtsi  | 100 ++
>  target/linux/ramips/image/mt76x8.mk   |  21 
>  7 files changed, 232 insertions(+)
>  create mode 100644 target/linux/ramips/dts/mt7628an_asus_rt-n10p-v3.dts
>  create mode 100644 target/linux/ramips/dts/mt7628an_asus_rt-n11p-b1.dts
>  create mode 100644 target/linux/ramips/dts/mt7628an_asus_rt-n12-vp-
> b1.dts
>  create mode 100644 target/linux/ramips/dts/mt7628an_asus_rt-n1x.dtsi
> 
> diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds
> b/target/linux/ramips/base-files/etc/board.d/01_leds
> index 5c005db0c1..f040f53359 100755
> --- a/target/linux/ramips/base-files/etc/board.d/01_leds
> +++ b/target/linux/ramips/base-files/etc/board.d/01_leds
> @@ -65,6 +65,12 @@ asl26555-16M)
>   ucidef_set_led_netdev "eth" "ETH" "asl26555:green:eth" "eth0"
>   set_wifi_led "asl26555:green:wlan"
>   ;;
> +asus,rt-n10p-v3|\
> +asus,rt-n11p-b1|\
> +asus,rt-n12-vp-b1)
> + ucidef_set_led_switch "lan" "lan" "$boardname:green:lan" "switch0"
> "0xf"
> + ucidef_set_led_switch "wan" "wan" "$boardname:green:wan"
> "switch0" "0x10"
> + ;;
>  bdcom,wap2100-sk|\
>  hiwifi,hc5861b)
>   set_wifi_led "$boardname:green:wlan2g"
> diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
> b/target/linux/ramips/base-files/etc/board.d/02_network
> index f743ce851a..ef18da0ef8 100755
> --- a/target/linux/ramips/base-files/etc/board.d/02_network
> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
> @@ -80,6 +80,9 @@ ramips_setup_interfaces()
>   3g-6200n|\
>   ai-br100|\
>   alfa-network,ac1200rm|\
> + asus,rt-n10p-v3|\
> + asus,rt-n11p-b1|\
> + asus,rt-n12-vp-b1|\
>   mediatek,ap-mt7621a-v60|\
>   xzwifi,creativebox-v1|\
>   d240|\
> diff --git a/target/linux/ramips/dts/mt7628an_asus_rt-n10p-v3.dts
> b/target/linux/ramips/dts/mt7628an_asus_rt-n10p-v3.dts
> new file mode 100644
> index 00..ec00030cf2
> --- /dev/null
> +++ b/target/linux/ramips/dts/mt7628an_asus_rt-n10p-v3.dts
> @@ -0,0 +1,34 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/dts-v1/;
> +
> +#include "mt7628an_asus_rt-n1x.dtsi"
> +
> +/ {
> + compatible = "asus,rt-n10p-v3", "mediatek,mt7628an-soc";
> + model = "Asus RT-N10P V3";
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led_power: power {
> + label = "rt-n10p-v3:green:power";
> + gpios = < 5 GPIO_ACTIVE_LOW>;
> + };
> +
> + wlan {
> + label = "rt-n10p-v3:green:wlan";
> + gpios = < 12 GPIO_ACTIVE_LOW>;
> + linux,default-trigger = "phy0tpt";
> + };
> +
> + wan {
> + label = "rt-n10p-v3:green:wan";
> + gpios = < 11 GPIO_ACTIVE_LOW>;
> + };
> +
> + lan {
> + label = "rt-n10p-v3:green:lan";
> + gpios = < 10 GPIO_ACTIVE_LOW>;
> + };
> + };
> +};
> diff --git a/target/linux/ramips/dts/mt7628an_asus_rt-n11p-b1.dts
> b/target/linux/ramips/dts/mt7628an_asus_rt-n11p-b1.dts
> new file mode 100644
> index 00..8aee2f73aa
> --- /dev/null
> +++ b/target/linux/ramips/dts/mt7628an_asus_rt-n11p-b1.dts
> @@ -0,0 +1,34 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/dts-v1/;
> +
> +#include 

RE: [PATCH 1/1] update factory reset for generic handling of all type of devices(jffs2, ubi, etc)

[mail]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Todor Colov
> Sent: Montag, 20. Juli 2020 21:19
> To: openwrt-devel@lists.openwrt.org
> Cc: Todor Colov 
> Subject: [PATCH 1/1] update factory reset for generic handling of all type of
> devices(jffs2, ubi, etc)

Despite the formal requirements not met (commit title/message), one comment 
below.

> 
> Signed-off-by: Todor Colov 
> ---
>  package/base-files/files/etc/rc.button/reset | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/package/base-files/files/etc/rc.button/reset b/package/base-
> files/files/etc/rc.button/reset
> index 2403122ad2..0c11bfe462 100755
> --- a/package/base-files/files/etc/rc.button/reset
> +++ b/package/base-files/files/etc/rc.button/reset
> @@ -23,7 +23,7 @@ released)
>   elif [ "$SEEN" -ge 5 -a -n "$OVERLAY" ]
>   then
>   echo "FACTORY RESET" > /dev/console
> - jffs2reset -y && reboot &
> + rm -f /etc/config/* && cp -a /rom/etc/* /etc/. ; sync ; reboot

As far as I understand it, jffs2reset will really reset the file system, just 
throwing away all diffs to the "rom". What you do here looks to me like it will 
essentially remove the files, and then recreate them, both increasing the diff 
between the overlay fs and the rom part, eating up precious space.
Or is this healed somewhere magically I'm not aware of?

Best

Adrian

>   fi
>  ;;
>  esac
> --
> 2.27.0
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [RFC PATCH 5/5] ipq40xx: add target for Google WiFi (Gale)

[mail]

> I'll spin up a new revision sooner or later, but I'm hoping I'll get some 
> opinion
> on the RFC portion (cover letter / first ~3 patches) before doing that.

Yes, just wait for some comments on the actual content. :-)

> > I'd like a bit more detailed flashing instructions here. What you have right
> now only works if the reader knows what to do anyway.
> 
> Well, it's not exactly trivial, but I guess not that difficult, relative to 
> the
> average device OpenWRT supports. As luck would have it, somebody has
> already documented it:
> 
> https://github.com/marcosscriven/galeforce#how-to-apply-an-image
> 
> Would it be best to summarize, link, or both?

Both. I'm a fan of putting information directly into the commit message, as 
that is the safest way of preserving it when links change, content changes etc.

The linked resources seem to be too much content for just pasting, though, so a 
helpful summary seems to be appropriate here.

Despite, also consider adding the full information to our Wiki's device page.

> 
> > > +++ b/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-gale-
> v2.
> > > +++ dts
> > > @@ -0,0 +1,402 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * Copyright (c) 2016, 2018 The Linux Foundation. All rights reserved.
> > > + * Copyright (c) 2016 Google, Inc
> > > + */
> > > +
> > > +#include "qcom-ipq4019.dtsi"
> > > +#include  #include
> > > +
> > > +
> > > + {
> >
> > I'd have expected the root node first.
> 
> I've learned muscle memory to put things like pinctrl first, because they're
> often referenced by other nodes (possibly including in the root node) via
> phandle, and at least in the past, DTC would not support out-of-order
> references for phandles.
> 
> But that doesn't apply here (no phandles from the root section), so that
> doesn't apply. Will change.
> 
> > > +/ {
> > > + model = "Google IPQ4019/Gale";
> >
> > This should be generally consistent with what you choose for
> DEVICE_MODEL. See my others comments there below.
> >
> > > + compatible = "google,gale-v2", "qcom,ipq4019";
> ...
> > > --- a/target/linux/ipq40xx/image/Makefile
> > > +++ b/target/linux/ipq40xx/image/Makefile
> > > @@ -218,6 +218,20 @@ define Device/avm_fritzbox-4040  endef
> > > TARGET_DEVICES += avm_fritzbox-4040
> > >
> > > +define Device/google_gale-v2
> >
> > Alphabetic sorting.
> >
> > > + DEVICE_VENDOR := Google
> > > + DEVICE_MODEL := WiFi (Gale)
> >
> > This uses yet another name compared to device definition/compatible and
> model in DTS.
> > Please be more consistent. Despite, if the device node (and thus the
> > image) has a v2 in it, please also add
> >
> > DEVICE_VARIANT := v2
> >
> > here.
> 
> Thanks for the scrutiny! I do have some questions here: is the
> VENDOR/MODEL supposed to match closer to a marketing-friendly/user-
> friendly name, or a developer/low-level name?

I typically prefer something that the user can read on the device, as 
everything else will add to the confusion.

> Or just some balance of both? Because there's several constraints
> here:
> * The bootloader recognizes compatible="google,gale-v2" -- I don't believe I
> can reliably drop the "v2" there, but I suppose that doesn't require the file
> names, etc., to include it
> * There really is no v1 publicly-available; as noted in the commit message, I
> believe that was pre-release hardware, and the revisions just stuck around
> through development
> * the "v2" here does *not* mean second generation, as in
> https://en.wikipedia.org/wiki/Google_Nest_Wifi#Second_generation

I don't think we have to care too much about the v1 here; however, if there is 
a different "second generation" with the same name, then we should include a 
"1st-gen" in the name somewhere, maybe even instead of the v2 if there is no v3 
to be expected for the "1st-gen".

The Wiki article is not entirely precise here, so is the gale-v2 the "first 
generation" in the nest article or is there actually a 1st and 2nd generation 
of that Nest devices and gale something even different?

> * "WiFi" doesn't really make for a good MODEL on its own, although it's OK
> when paired with the VENDOR. But I still preferred sticking the codename
> (Gale) around, since that's the unambiguous way hackers can recognize the
> model.
> 
> What do you think? Should I try to keep the keywords "google", "wifi", and
> "gale" in all of the config, image, and DTS name? And I'll avoid the "v2"
> labeling (and DEVICE_VARIANT) outside of "compatible", because I think that
> would be misleading.

If you call this gale, the question is how you proceed with the nest series 
then. Will you switch to marketing-based "nest" then, or will you use the 
internal name though the user will read something different on the device?

Unfortunately, this stuff is never easy to decide. Personally, I always lean 
towards what's printed on the thing.

Best

Adrian

> 
> Anyway, I'll try to figure out a better balance of the above on the next
> 

RE: [PATCH] ramips: increase SPI frequency for MT7620 Archer

[mail]

> -Original Message-
> From: David Bauer [mailto:m...@david-bauer.net]
> Sent: Mittwoch, 22. Juli 2020 14:21
> To: m...@adrianschmutzler.de
> Cc: openwrt-devel@lists.openwrt.org
> Subject: Re: [PATCH] ramips: increase SPI frequency for MT7620 Archer
> 
> Hello Adrian,
> 
> On 7/22/20 11:29 AM, m...@adrianschmutzler.de wrote:
> >> -Original Message-
> >> From: openwrt-devel [mailto:openwrt-devel-
> boun...@lists.openwrt.org]
> >> On Behalf Of David Bauer
> >> Sent: Dienstag, 21. Juli 2020 23:40
> >> To: openwrt-devel@lists.openwrt.org
> >> Subject: [PATCH] ramips: increase SPI frequency for MT7620 Archer
> >>
> >> Increase the SPI frequency for the MT7620 based TP-Link Archer series
> >> to 30MHz.
> >
> > Acked-by: Adrian Schmutzler 
> >
> > I'm not sure which are the frequency steps actually observed on that
> target, but raising it above the abundant copy/pasted 10 MHz seems a good
> idea in any case.
> 
> The SPI master can be operated in a range of {2..128}/SYS_CLK. (2..128 has to
> be power of two). So in the end it will transfer at around 18 MHz.
> 
> I don't want to crank this up further, as TP-Link uses a broad selection of 
> SPI
> chips on a single hardware revision on many of their devices.
> Increasing performance might come at the cost of compatibility here.

Yes, no objection.

I just asked in case the next step would have been close, e.g. 33 MHz, then one 
could have thought about raising it a little more.

But I'm fine with anything faster than the 10 Mhz :-)

Best

Adrian

> 
> Best wishes
> David
> 
> >
> > Best
> >
> > Adrian
> >
> >>
> >> TP-Link uses different SPI flash chips for the same board revision,
> >> so be conservative to not break boards with a different chip. 30MHz
> >> should be well supported by all chips.
> >>
> >> Tested on Archer C2 v1 (GD25Q64B) and Archer C20i (W25Q64FV).
> >>
> >> Archer C20i (before)
> >> 
> >> root@OpenWrt:~# time dd if=/dev/mtd1 of=/tmp/test.bin bs=64k
> >> 122+0 records in
> >> 122+0 records out
> >> real   0m 15.30s
> >> user   0m 0.00s
> >> sys0m 15.29s
> >>
> >> Archer C20i (after)
> >> ===
> >> root@OpenWrt:~# time dd if=/dev/mtd1 of=/tmp/test.bin bs=64k
> >> 122+0 records in
> >> 122+0 records out
> >> real   0m 5.99s
> >> user   0m 0.00s
> >> sys0m 5.98s
> >>
> >> Signed-off-by: David Bauer 
> >> ---
> >>   target/linux/ramips/dts/mt7620a_tplink_archer-c2-v1.dts | 2 +-
> >> target/linux/ramips/dts/mt7620a_tplink_archer-mr200.dts | 2 +-
> >>   target/linux/ramips/dts/mt7620a_tplink_archer.dtsi  | 2 +-
> >>   3 files changed, 3 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/target/linux/ramips/dts/mt7620a_tplink_archer-c2-v1.dts
> >> b/target/linux/ramips/dts/mt7620a_tplink_archer-c2-v1.dts
> >> index c0b2c1ae92..75ddc5fb5d 100644
> >> --- a/target/linux/ramips/dts/mt7620a_tplink_archer-c2-v1.dts
> >> +++ b/target/linux/ramips/dts/mt7620a_tplink_archer-c2-v1.dts
> >> @@ -82,7 +82,7 @@
> >>flash@0 {
> >>compatible = "jedec,spi-nor";
> >>reg = <0>;
> >> -  spi-max-frequency = <1000>;
> >> +  spi-max-frequency = <3000>;
> >>
> >>partitions {
> >>compatible = "fixed-partitions"; diff --git
> >> a/target/linux/ramips/dts/mt7620a_tplink_archer-mr200.dts
> >> b/target/linux/ramips/dts/mt7620a_tplink_archer-mr200.dts
> >> index c3c0efdfe6..0c0f4bb8e9 100644
> >> --- a/target/linux/ramips/dts/mt7620a_tplink_archer-mr200.dts
> >> +++ b/target/linux/ramips/dts/mt7620a_tplink_archer-mr200.dts
> >> @@ -121,7 +121,7 @@
> >>flash@0 {
> >>compatible = "jedec,spi-nor";
> >>reg = <0>;
> >> -  spi-max-frequency = <1000>;
> >> +  spi-max-frequency = <3000>;
> >>
> >>partitions {
> >>compatible = "fixed-partitions"; diff --git
> >> a/target/linux/ramips/dts/mt7620a_tplink_archer.dtsi
> >> b/target/linux/ramips/dts/mt7620a_tplink_archer.dtsi
> >> index 184627b9f4..670bad615d 100644
> >> --- a/target/linux/ramips/dts/mt7620a_tplink_archer.dtsi
> >> +++ b/target/linux/ramips/dts/mt7620a_tplink_archer.dtsi
> >> @@ -43,7 +43,7 @@
> >>flash@0 {
> >>compatible = "jedec,spi-nor";
> >>reg = <0>;
> >> -  spi-max-frequency = <1000>;
> >> +  spi-max-frequency = <3000>;
> >>
> >>partitions {
> >>compatible = "fixed-partitions";
> >> --
> >> 2.27.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


openpgp-digital-signature.asc
Description: PGP signature
___

RE: [PATCH] ramips: increase SPI frequency for MT7620 Archer

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of David Bauer
> Sent: Dienstag, 21. Juli 2020 23:40
> To: openwrt-devel@lists.openwrt.org
> Subject: [PATCH] ramips: increase SPI frequency for MT7620 Archer
> 
> Increase the SPI frequency for the MT7620 based TP-Link Archer series to
> 30MHz.

Acked-by: Adrian Schmutzler 

I'm not sure which are the frequency steps actually observed on that target, 
but raising it above the abundant copy/pasted 10 MHz seems a good idea in any 
case.

Best

Adrian

> 
> TP-Link uses different SPI flash chips for the same board revision, so be
> conservative to not break boards with a different chip. 30MHz should be well
> supported by all chips.
> 
> Tested on Archer C2 v1 (GD25Q64B) and Archer C20i (W25Q64FV).
> 
> Archer C20i (before)
> 
> root@OpenWrt:~# time dd if=/dev/mtd1 of=/tmp/test.bin bs=64k
> 122+0 records in
> 122+0 records out
> real  0m 15.30s
> user  0m 0.00s
> sys   0m 15.29s
> 
> Archer C20i (after)
> ===
> root@OpenWrt:~# time dd if=/dev/mtd1 of=/tmp/test.bin bs=64k
> 122+0 records in
> 122+0 records out
> real  0m 5.99s
> user  0m 0.00s
> sys   0m 5.98s
> 
> Signed-off-by: David Bauer 
> ---
>  target/linux/ramips/dts/mt7620a_tplink_archer-c2-v1.dts | 2 +-
> target/linux/ramips/dts/mt7620a_tplink_archer-mr200.dts | 2 +-
>  target/linux/ramips/dts/mt7620a_tplink_archer.dtsi  | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/target/linux/ramips/dts/mt7620a_tplink_archer-c2-v1.dts
> b/target/linux/ramips/dts/mt7620a_tplink_archer-c2-v1.dts
> index c0b2c1ae92..75ddc5fb5d 100644
> --- a/target/linux/ramips/dts/mt7620a_tplink_archer-c2-v1.dts
> +++ b/target/linux/ramips/dts/mt7620a_tplink_archer-c2-v1.dts
> @@ -82,7 +82,7 @@
>   flash@0 {
>   compatible = "jedec,spi-nor";
>   reg = <0>;
> - spi-max-frequency = <1000>;
> + spi-max-frequency = <3000>;
> 
>   partitions {
>   compatible = "fixed-partitions";
> diff --git a/target/linux/ramips/dts/mt7620a_tplink_archer-mr200.dts
> b/target/linux/ramips/dts/mt7620a_tplink_archer-mr200.dts
> index c3c0efdfe6..0c0f4bb8e9 100644
> --- a/target/linux/ramips/dts/mt7620a_tplink_archer-mr200.dts
> +++ b/target/linux/ramips/dts/mt7620a_tplink_archer-mr200.dts
> @@ -121,7 +121,7 @@
>   flash@0 {
>   compatible = "jedec,spi-nor";
>   reg = <0>;
> - spi-max-frequency = <1000>;
> + spi-max-frequency = <3000>;
> 
>   partitions {
>   compatible = "fixed-partitions";
> diff --git a/target/linux/ramips/dts/mt7620a_tplink_archer.dtsi
> b/target/linux/ramips/dts/mt7620a_tplink_archer.dtsi
> index 184627b9f4..670bad615d 100644
> --- a/target/linux/ramips/dts/mt7620a_tplink_archer.dtsi
> +++ b/target/linux/ramips/dts/mt7620a_tplink_archer.dtsi
> @@ -43,7 +43,7 @@
>   flash@0 {
>   compatible = "jedec,spi-nor";
>   reg = <0>;
> - spi-max-frequency = <1000>;
> + spi-max-frequency = <3000>;
> 
>   partitions {
>   compatible = "fixed-partitions";
> --
> 2.27.0
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [PATCH] ramips: switch MT7620 subtarget to 5.4

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of David Bauer
> Sent: Dienstag, 21. Juli 2020 23:41
> To: openwrt-devel@lists.openwrt.org
> Subject: [PATCH] ramips: switch MT7620 subtarget to 5.4
> 
> MT7620 seems to work fine with kernel 5.4. Set the default kernel version to
> 5.4 to bring this to a broader audience.
> 
> Tested on Archer C2 v1 / Archer C20i
> 
> Signed-off-by: David Bauer 
> ---
>  target/linux/ramips/mt7620/target.mk | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/target/linux/ramips/mt7620/target.mk
> b/target/linux/ramips/mt7620/target.mk
> index 56ceaee37f..ff890c5540 100644
> --- a/target/linux/ramips/mt7620/target.mk
> +++ b/target/linux/ramips/mt7620/target.mk
> @@ -9,6 +9,8 @@ CPU_TYPE:=24kc
> 
>  DEFAULT_PACKAGES += kmod-rt2800-soc wpad-basic swconfig
> 
> +KERNEL_PATCHVER:=5.4
> +

Hi David,

thanks for taking care.

I wonder whether it would be better to invert the statements, i.e. have

KERNEL_PATCHVER:=5.4

in target Makefile and

KERNEL_PATCHVER:=4.14
KERNEL_TESTING_PATCHVER:=5.4

in the rt subtarget Makefiles, as in the meantime those have become the 
"exceptions" after all.

It's a mere matter of taste, though, feel free to ignore it.

Best

Adrian

>  define Target/Description
>   Build firmware images for Ralink MT7620 based boards.
>  endef
> --
> 2.27.0
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: Restoring (old) config backups and

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Alberto Bursi
> Sent: Dienstag, 21. Juli 2020 09:48
> To: openwrt-devel@lists.openwrt.org; m...@adrianschmutzler.de
> Subject: Re: Restoring (old) config backups and
> 
> 
> On 20/07/20 19:32, Henrique de Moraes Holschuh wrote:
> >
> >
> > Any thoughts on this?  I am certainly to have overlooked a lot of
> > stuff, especially if it is present only on master.  Also, handling of
> > an uci-defaults "reset" (so that they'd run again) in
> > non-initramfs/overlayfs based system is likely to pose some challenges
> > depending on how it is implemented...
> >
> 
> Adrian Shmultzer has been recently adding some infrastructure in the
> sysupgrade to stop it if there are incompatible features that would break
> core functionality, so that the user won't just sysupgrade with the same
> config and land in an inaccessible device. Maybe his work can/should be
> extended to alter the creating/restoring config backups logic too, as it's 
> really
> doing more or less the same thing already.

Actually, my solution implements the config "on device" as a uci parameter, so 
the "on device" version is actually not the version of the firmware installed, 
but of the config installed. Therefore, one may indeed go that road to prevent 
flashing an incompatible backup. However, I don't think you can use it for much 
else.

Despite, I still have received no positive feedback about that change at all, 
so I'm not sure whether it will go in at all.

Best

Adrian

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


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [RFC PATCH v2 4/6] ath79: support for TP-Link EAP245 v1

[mail]

> > Tested on the EAP245 v1 running the latest firmware (v1.4.0). The
> > binary patch might not apply to uclited from other firmware versions.
> >
> > Signed-off-by: Sander Vanheule 
> 
> Seems like I was overdue on a proper read of the kernel patch submission
> guidelines. My understanding from the guidelines and your previous mail [1],
> is that these lines aren't about the literal patch contents per se, but also
> about the intention of the patch and the provided functionality.
> 
> So the fact that the bulk of the EAP245 v1's DTS was moved to the 1- port
> DTSI, shouldn't be an issue to attribute device support to Julien in this 
> patch,
> right?

I see that differently. For me, providing device support for a device A and 
using similar code for a bunch of devices B to D is a different patch.

I don't think a Signed-off-by is correct here, as Julien is _not_ an author of 
your patch, as he intended to provide support for the EAP245 and not for the 
1-port EAP2x5 devices.

> 
> Would you consider the following appropriate for this patch?
> 
>EAP245 v1 support originally implemented by Julien Dusser.

That's nice but irrelevant without proper explanation ("why is EAP245 relevant 
at all").

If you really want to refer to that prior work, IMO a proper solution would be 
to just add something like "Implementation of these devices is based on the 
prior work of XY supporting device YZ in commit x."

Then, everybody can look up what XY has done and will see the proper authorship 
in the reference.

>SoC MDIO integration, factory flashing method, and final patch by
>Sander Vanheule.
> 
>Co-developed-by: Julien Dusser 
>Signed-of-By: Julien Dusser 

The initial author needs no Co-developed-by, as he is mentioned in the From 
field.
From/Co-developed-by is about authorship, Signed-off-by is about legal 
accountability.

The latter is one reason why you technically actually can only add Juliens 
Signed-off-by if this patch is combined submission of both of you, where both 
people have actually checked the final patch for correctness. If that's not the 
case, it's not Co-developed-by, but Julien would be the author, and you would 
have to note every single change before your Signed-off-by to make obvious 
which parts are covered by his SoB and what has been changed since then and 
thus is covered by your SoB.
(example for the latter may be found here: 
https://github.com/openwrt/openwrt/commit/ed087cba8a8e41f76f9487caa34eff926ea8a065)

Since this appears to me to be "your" patch, and not a submission by both of 
you, for me it would be more correct to just have your SoB/From: only.
If the original patch was mine, I'd actually be quite mad at you if you used my 
Signed-off-by for a different submission.

Best

Adrian 


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [RFC PATCH v2 3/6] ath79: prepare for 1-port TP-Link EAP2x5 devices

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Sander Vanheule
> Sent: Montag, 20. Juli 2020 18:28
> To: m...@adrianschmutzler.de
> Cc: yn...@true.cz; openwrt-devel@lists.openwrt.org; Julien Dusser
> 
> Subject: Re: [RFC PATCH v2 3/6] ath79: prepare for 1-port TP-Link EAP2x5
> devices
> 
> Hi Adrian,
> 
> On Mon, 2020-07-20 at 00:25 +0200, m...@adrianschmutzler.de wrote:
> > Hi,
> >
> > > Signed-off-by: Julien Dusser 
> > > Signed-off-by: Sander Vanheule 
> >
> > technically, if Julien is first SoB, you should also put him in the
> > author (From:) field.
> 
> The DTSI is derived from Julien's DTS for the EAP245 v1 [1]. By now I've made
> so many modifications, that I don't think Julien should be the person
> responsible for this file any more. But I would still like to credit his 
> work. I'll
> swap the SoB order to reflect this.

Swapping is not such a good idea IMO.
The Series of SoB statements (and possibly Co-developed-by) should essentially 
give the history of what happened to a patch from top to bottom.

However, in that particular case you are not reusing/updating a patch from 
Julien, but you are just using something he "invented" for a different purpose. 
In that context, adding his Signed-off-by is actually wrong if you are strict, 
unless he has explicit provided it for this subject.

So, for this _separate_ subject - adding a DTSI for 1-port devices - I 
personally think it should just bear your name. Julien will receive credit for 
the EAP245 v1 device support.

Same argument goes for similar cases in your patchset I'm currently not aware 
of:

If the initial patch for the subject at hand is from Julien, he should be 
author and first SoB.
If you picked up something he did and applied it to a different purpose, you 
are the author. You may mentioned him in the commit message text then (if 
necessary, for the DTSI I wouldn't even consider that necessary).

Best

Adrian

> 
> [1] https://github.com/j-d-
> r/openwrt/blob/ae7dc9bf871cd9f27ccc1f4bff335ab5e79bcae9/target/linux/a
> th79/dts/qca9563_tplink_eap245-v1.dts
> 
> 
> > > ---
> > >  .../dts/qca9563_tplink_eap2x5_1port.dtsi  | 139
> > > ++
> > >  target/linux/ath79/image/generic-tp-link.mk   |  10 ++
> > >  2 files changed, 149 insertions(+)
> > >  create mode 100644
> > > target/linux/ath79/dts/qca9563_tplink_eap2x5_1port.dtsi
> > >
> > > diff --git
> > > a/target/linux/ath79/dts/qca9563_tplink_eap2x5_1port.dtsi
> > > b/target/linux/ath79/dts/qca9563_tplink_eap2x5_1port.dtsi
> > > new file mode 100644
> > > index 00..24f0b4f0ce
> > > --- /dev/null
> > > +++ b/target/linux/ath79/dts/qca9563_tplink_eap2x5_1port.dtsi
> > > @@ -0,0 +1,139 @@
> > > +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT #include
> >
> > Not really important, but I'd prefer an empty line after the license.
> > (Broken in my mail anyway, but I looked at it in patchwork.)
> 
> Fixed.
> 
> 
> > > + {
> > > + mdio_pins: pinux_mdio_pins {
> >
> > Typo for the node name (pinux). Despite, including pinmux for the node
> > name actually doesn't make much sense, as it's part of  anyway.
> > If you want it, it would make sense to add it to the DT label, as this
> > one is actually used in global context.
> >
> > I'd be fine with "mdio_pins: mdio_pins" as well, though, as "pins"
> > already tells whats going on.
> 
> I went with your suggestion and changed it to "mdio_pins: mdio_pins".
> 
> 
> > > + /* GPIO 8 as MDC(0x21), GPIO 10 as MDIO(0x20) */
> > > + pinctrl-single,bits = <0x8 0x0021 0x00ff>,
> > > +   <0x8 0x0020 0x00ff>;
> >
> > Err, is there a specific reason why you don't use:
> >
> > pinctrl-single,bits = <0x8 0x00200021 0x00ff00ff>;
> >
> > Or is the second offset supposed to 0xc or something?
> 
> The lines are correct and entirely as intended. But I just didn't think about
> merging the two lines... *facepalm* Merged, and swapped the order in the
> comment to 10/8 to have the same order as in the specified bits.
> 
> 
> > > diff --git a/target/linux/ath79/image/generic-tp-link.mk
> > > b/target/linux/ath79/image/generic-tp-link.mk
> > > index 8a26e4bebe..d2cc8d09bd 100644
> > > --- a/target/linux/ath79/image/generic-tp-link.mk
> > > +++ b/target/linux/ath79/image/generic-tp-link.mk
> > > @@ -362,6 +362,16 @@ define Device/tplink_cpe610-v2  e

RE: [PATCH 1/1] TARGET: Add new device support under target IPQ806x for Linksys E8350

[mail]

> > --- /dev/null
> > +++ b/target/linux/ipq806x/base-files/etc/rc.button/reset
>
> What's that for? Implementation of reset button is available with KEY_RESTART 
> OOTB.
> -> NOTE: Linksys E8350 uses ubi volumes not jffs2 . Until the "factory reset" 
> script properly handle such volumes(which is not the case at the moment). 
> I've made ipq806x copy of it with added specific actions for linksys,e8350. 
> The ipq806x copy of "reset" > script do not break any old dependencies and 
> have to be removed as redundant once there is a proper factory reset script 
> for UBI volumes is in place. This have to be assigned as task to the 
> maintainer of the "reset" script. It is not a bug but lacking of new features 
> of the current reset script.

So, what you want to tell me is that the reset button is broken on _all_ 
devices using ubi volumes? Then, please fix it for all of them (in a separate 
patch, like you did for the wifi up issue), instead of adding a "workaround" 
just for your device at hand.

> > --- /dev/null
> > +++ b/target/linux/ipq806x/base-files/lib/upgrade/fwtool.sh
>
> Same here. Why do you copy that stuff over?
> -> NEED DEFINITION: the device uses one main "UBI" volume with 
> kernel,roofs,rootfs_data in it. The sysupgrade script has lack of feature to 
> remove the "metadata" trailer: "nand.sh" -> nand_upgrade_ubinized -> no 
> medata in the sysupgrade image should be there before "ubiformat "${mtddev}" 
> -y -f "${ubi_file}"" command!
>
> -> To overcome this limitation I use "fwtool" with option -t. 
> -> fwtool.sh is coping the fwtool to /tmp location ( all the rest is not 
> touched ) and than the metadata is removed from platform.sh script running 
> fwtool -t option. fwtool is not available after the switch to sysupgrade 
> ramfs rootfs and the copy to /tmp directory preserves it.
> May be there is a better approach (use variable to remove the "metadata" 
> before "nand_upgrade_ubinized") but this has to be assigned to the maintainer 
> of "nand.sh" script which does not properly handle the removal of metadata in 
> "nand_upgrade_ubinized" function. (nand.sh bug or feature?)

I'm not an UBI/NAND expert. However, I don't really believe that there is no 
better way to achieve this, particularly given that this is not the first ubi 
device added to OpenWrt.
As with my previous comment, this looks to me like a general, not 
single-device-related problem, so please address it that way.

This is particularly important if you touch sysupgrade components. This is 
really complicated enough, I don't want to see different local flavors of 
certain scripts on top of that.

Please note that it appears your responses never made it to the openwrt-devel 
list. Either your address is subject to some kind of greylisting and they will 
just be delayed, or there is another problem there. The mail address in Cc 
seems correct, though.

Best

Adrian


> @@ -0,0 +1,67 @@
> +fwtool_check_signature() {
> + [ $# -gt 1 ] && return 1
> +
> + [ ! -x /usr/bin/ucert ] && {
> + if [ "$REQUIRE_IMAGE_SIGNATURE" = 1 ]; then
> + return 1
> + else
> + return 0
> + fi
> + }
> +
> + if ! fwtool -q -s /tmp/sysupgrade.ucert "$1"; then
> + echo "Image signature not found"
> + [ "$REQUIRE_IMAGE_SIGNATURE" = 1 -a "$FORCE" != 1 ] && {
> + echo "Use sysupgrade -F to override this check when
> downgrading or flashing to vendor firmware"
> + }
> + [ "$REQUIRE_IMAGE_SIGNATURE" = 1 ] && return 1
> + return 0
> + fi
> +
> + fwtool -q -T -s /dev/null "$1" | \
> + ucert -V -m - -c "/tmp/sysupgrade.ucert" -P /etc/opkg/keys
> +
> + return $?
> +}
> +
> +fwtool_check_image() {
> + [ $# -gt 1 ] && return 1
> +
> + . /usr/share/libubox/jshn.sh
> +
> + if ! fwtool -q -i /tmp/sysupgrade.meta "$1"; then
> + echo "Image metadata not found"
> + [ "$REQUIRE_IMAGE_METADATA" = 1 -a "$FORCE" != 1 ] && {
> + echo "Use sysupgrade -F to override this check when
> downgrading or flashing to vendor firmware"
> + }
> + [ "$REQUIRE_IMAGE_METADATA" = 1 ] && return 1
> + return 0
> + fi
> + # For UBI volumes we need fwtool on later stage to remove the
> metadata - via platform.sh!!!
> + cp /usr/bin/fwtool /tmp/.
> +
> + json_load "$(cat /tmp/sysupgrade.meta)" || {
> + echo "Invalid image metadata"
> + return 1
> + }
> +
> + device="$(cat /tmp/sysinfo/board_name)"
> +
> + json_select sup

RE: [PATCH 1/1] tools -> firmware-utils -> Add Linksys E8350 firmware header generator for native openwrt WEB factory image

[mail]

> - My opinion is that the current approach for specific firmware utils is 
> lacking of scalability. All custom fw tools are in the same directory, what 
> if they become 1000 or more?

I don't see how scalability will be better if every piece of non-specific code 
is copied in _again_ for every new device. This will just make it easy for the 
submitter, but will create a maintenance nightmare.
We are not a collection of GPL sources.

If that code is meant for several devices like the different strings and model 
selection in the content tell of, and can be used that way - implement it that 
way.

If you are really sure that this will only be required for that particular 
single device - throw out all the other crap.

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [PATCH 1/1] TARGET: Add new device support under target IPQ806x for Linksys E8350

[mail]

> > + model = "Linksys EA8300 V1 WiFi Router";
>
> So, is it V1? Then add that to the compatible etc.: linksys,e8350-v1
> -> I've not sen V2 yet, so I can remove the versioning of this device in the 
> updated patch.

Well, the question is not whether a v2 is there _yet_, but whether you are 
absolutely sure that there will never be a v2.

Otherwise, we will end up with linksys,e8350 and linksys,e8350-v2, which is not 
desirable, while having a lone linksys,e8350-v1 won't hurt.

> > + BOARD_NAME = e8350
> > + SUPPORTED_DEVICES += e8350
> Drop BOARD_NAME and SUPPORTED_DEVICES.
> -> what about the metadata generation, will it be affected?

Metadata will of course work, as this line is just adding _another_ string 
required for backwards compatibility. This second string e8350 is not used 
anywhere for this device, you just invented it by believing you were following 
a pattern.

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [PATCH v2 1/2] vxlan: remove mandatory peeraddr

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Johannes Kimmel
> Sent: Montag, 20. Juli 2020 08:05
> To: openwrt-devel@lists.openwrt.org
> Cc: Johannes Kimmel ; mschiffer@universe-
> factory.net
> Subject: [PATCH v2 1/2] vxlan: remove mandatory peeraddr
> 
> vxlan can be configured without a peer address. This is used to prepare an
> interface and add peers later.
> 
> Fixes: FS#2743
> 
> Signed-off-by: Johannes Kimmel 

You already received an

Acked-by: Matthias Schiffer 

on this one for the v1, which is the same as this one except for the Fixes: 
line added.

This kind of feedback is valuable, so you should keep/add it for newer versions 
(if there are any; for patchwork, the Acked-by should be picked up as I posted 
it here).

Best

Adrian

> ---
>  package/network/config/vxlan/files/vxlan.sh | 12 
>  1 file changed, 12 deletions(-)
> 
> diff --git a/package/network/config/vxlan/files/vxlan.sh
> b/package/network/config/vxlan/files/vxlan.sh
> index 7b1c703..bdcaa62 100755
> --- a/package/network/config/vxlan/files/vxlan.sh
> +++ b/package/network/config/vxlan/files/vxlan.sh
> @@ -55,12 +55,6 @@ proto_vxlan_setup() {
>   local ipaddr peeraddr
>   json_get_vars ipaddr peeraddr tunlink
> 
> - [ -z "$peeraddr" ] && {
> - proto_notify_error "$cfg" "MISSING_ADDRESS"
> - proto_block_restart "$cfg"
> - exit
> - }
> -
>   ( proto_add_host_dependency "$cfg" '' "$tunlink" )
> 
>   [ -z "$ipaddr" ] && {
> @@ -85,12 +79,6 @@ proto_vxlan6_setup() {
>   local ip6addr peer6addr
>   json_get_vars ip6addr peer6addr tunlink
> 
> - [ -z "$peer6addr" ] && {
> - proto_notify_error "$cfg" "MISSING_ADDRESS"
> - proto_block_restart "$cfg"
> - exit
> - }
> -
>   ( proto_add_host_dependency "$cfg" '' "$tunlink" )
> 
>   [ -z "$ip6addr" ] && {
> --
> 2.27.0
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Wiki: Device support policies/best practices

[mail]

Hi,

inspired by a discussion on IRC, I have created a Wiki page to collect some 
common/best practices for device support submissions:

https://openwrt.org/docs/guide-developer/device-support-policies

I've so far linked this here:
https://openwrt.org/submitting-patches#dts_checklist
https://openwrt.org/docs/guide-developer/add.new.device

This is meant to provide some ideas on how things can be done nicely, but it is 
_not_ meant as a new set of rules.

Essentially, most of the stuff there is a collection of things I have written 
more than 20 times when reviewing device support PRs somewhere.
Now, I have the ability to link to the extensive description instead of writing 
it another time.

If somebody disagrees with something stated there, feel free to add a different 
view, weaken the statement, or remove it entirely.

Of course, you may also add stuff I didn't think of for this first version. :-)

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [PATCH 1/1] Fix Wifi Button - off function not working

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Henrique de Moraes Holschuh
> Sent: Montag, 20. Juli 2020 00:51
> To: openwrt-devel@lists.openwrt.org
> Subject: Re: [PATCH 1/1] Fix Wifi Button - off function not working
> 
> >   config_foreach wifi_rfkill_set wifi-device
> >   uci commit wireless
> 
> I've always hated this "uci commit" in the wifi on/off button handling, it
> causes FLASH wear for no good reason IMHO.
> 
> But that is orthogonal to this patch, of course.

Yes, but as you say it, I wonder whether we really need wifi here or 
reload_config if we touch uci config anyway.

Refering to your actual subject, for me pressing WiFi button has always been an 
extremely rare case, so I'm not too concerned about that flash wear personally.

Best

Adrian

> 
> --
> Henrique de Moraes Holschuh
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [RFC PATCH v2 0/6] ath79: support for TP-Link EAP2x5 1-port devices

[mail]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Sander Vanheule
> Sent: Sonntag, 19. Juli 2020 23:24
> To: openwrt-devel@lists.openwrt.org
> Cc: Sander Vanheule 
> Subject: [RFC PATCH v2 0/6] ath79: support for TP-Link EAP2x5 1-port devices
> 
> This patch series seeks to add support for the following devices:
>  * TP-Link EAP245 v1
>  * TP-Link EAP225 v3
>  * TP-Link EAP225-Outdoor v1
> Currently not included:
>  * TP-Link EAP225 v1/v2

Since I lost overview in the meantime, I've pushed all relevant changes into my 
staging tree here:

https://git.openwrt.org/?p=openwrt/staging/adrian.git;a=shortlog;h=refs/heads/eap

This is provided just for convenience as I created it for myself anyway, it 
doesn't mean that I will merge it or take care.

Best

Adrian

> 
> Note that the patches cannot be applied straight to master, but require (at
> least) the first four patches (elf splitter and tplink safeloader) of my pull
> request for the EAP245 v3. (CC ynezz, rmilecki) For these patches, see
> https://github.com/openwrt/openwrt/pull/3130 and
> https://patchwork.ozlabs.org/project/openwrt/patch/c429526040b8753011f
> c905af8d32747c8da6d1b.1594471105.git.san...@svanheule.net/
> 
> The first patches of this series are (derived from) work done by Julien Dusser
> and were submitted earlier in the following pull requests (reviewed by
> blogic, blocktrron, CodeFetch)
>  * ar71xx: add support for TP-Link EAP245 v1
>https://github.com/openwrt/openwrt/pull/599
>  * ath79: extra gmac configurations from DT on qca956x
>https://github.com/openwrt/openwrt/pull/2441
> 
> Some extra work since has led to a reduced set of patches to provide support
> for the EAP245 v1 on ath79. Since the other devices are so similar, they are
> also included in this series. There were objections in pulling in support 
> earlier
> due to the badly configured bootloader and firmware upload protections.
> 
> The main work-around for the broken bootloader is in patch 2/6, which adds
> an initialisation sequence for the SGMII SERDES. Patch 1/6 ensures the SGMII
> interface is enabled when required.
> 
> A work-around for the firmware protection was found by using a debug
> mode that doesn't perform firmware RSA signature checks. On earlier
> firmwares (EAP245 v1 and EAP225 v1/v2), a binary patch is required to
> prevent a crash, but more recent firmwares (EAP225 v3, EAP225-Outdoor v1,
> EAP245 v3) can enable the debug mode by using a simple command.
> 
> Questions:
>  * The EAP245 v1 factory partition layout is different from, though
>compatible with, the layout provided in patch 3/6. The only difference
>this makes, is a slightly smaller firmware partition and perhaps
>the odd confused user seeking to extract the original user-config
>partition. Using only one layout does simplify the DTs, which is why
>I went with the current approach. Is this okay, or should I stay closer to
>the original layout?
>  * I can probably provide working support for the EAP225 v1/v2, given
>the minimal differences between the devices. However, I do not have
>this device to test an image, nor has anyone offered to test on the
>forums. This device would have a similar flashing procedure as the
>EAP245 v1. Would you nevertheless want me to provide a patch?
> 
> Changes in v2:
>  * Implemented DTS/DTSI header changes.
>  * Moved LED definitions.
>  * eap245-v1 ath10k MAC address now comes from flash.
>  * Renamed EAP225OD to EAP225-Outdoor throughout the patches.
>  * The patch providing extra #define's for QCA956X SoCs was dropped.
>Most of it has been available upstream since 2018 with kernel commit
>a95f4b1c28932ca4.
>  * Put phy-mode in the correct device node (eth0, not phy4)
>  * Ensure QCA956X_ETH_CFG_GE0_SGMII is set when required. Removes
> the need for
>the device tree extension patch.
> 
> Julien Dusser (1):
>   ath79: add QCA956x SERDES init workaround
> 
> Sander Vanheule (5):
>   ath79: ensure QCA956x gmac0 mux selects sgmii
>   ath79: prepare for 1-port TP-Link EAP2x5 devices
>   ath79: support for TP-Link EAP245 v1
>   ath79: support for TP-Link EAP225-Outdoor v1
>   ath79: support for TP-Link EAP225 v3
> 
>  .../dts/qca9563_tplink_eap225-outdoor-v1.dts  |  31 
>  .../ath79/dts/qca9563_tplink_eap225-v3.dts|  31 
>  .../ath79/dts/qca9563_tplink_eap245-v1.dts|  36 +
>  .../dts/qca9563_tplink_eap2x5_1port.dtsi  | 139 ++
>  .../net/ethernet/atheros/ag71xx/ag71xx_main.c | 116 +++
>  .../generic/base-files/etc/board.d/02_network |   3 +
>  .../etc/hotplug.d/firmware/11-ath10k-caldata  |   8 +
>  target/linux/ath79/image/generic-tp-link.mk   |  37 +
>  tools/firmware-utils/src/tplink-safeloader.c  |  85 +++
>  9 files changed, 486 insertions(+)
>  create mode 100644 target/linux/ath79/dts/qca9563_tplink_eap225-
> outdoor-v1.dts
>  create mode 100644 

RE: [RFC PATCH v2 6/6] ath79: support for TP-Link EAP225 v3

[mail]

> + tplink,eap225-v3|\
>   tplink,eap225-outdoor-v1|\

"v" comes after "o". Same everywhere below, including tplink-safeloader.

Best

Adrian 


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [RFC PATCH v2 3/6] ath79: prepare for 1-port TP-Link EAP2x5 devices

[mail]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Sander Vanheule
> Sent: Sonntag, 19. Juli 2020 23:24
> To: openwrt-devel@lists.openwrt.org
> Cc: Sander Vanheule ; Julien Dusser
> 
> Subject: [RFC PATCH v2 3/6] ath79: prepare for 1-port TP-Link EAP2x5 devices
> 
> TP-Link has developed a number of access points based on the AP152
> reference board. In the EAP-series of 802.11ac access points, this includes
> the following devices with one ethernet port:
> * EAP225 v1/v2
> * EAP225 v3
> * EAP225-Outdoor v1
> * EAP245 v1
> 
> Since the only differences between these devices are the ath10k wireless
> radios and LEDs, a common base is provided for the overlapping support
> requirements.
> 
> Hardware commonalities:
> * SoC: QCA9563-AL3A MIPS 74kc v5.0 @ 775MHz, AHB @ 258MHz
> * RAM: 128MiB DDR2 @ 650MHz
> * Flash: 16MiB SPI NOR
> * Wi-Fi 2.4GHz: provided by SoC
> * Wi-Fi 5Ghz: ath10k chip on PCIe
> * Ethernet: AR8033-AL1A, one 1GbE port (802.3at PoE)
> 
> This patch was originally developed by Julien Dusser for the EAP245 v1, and
> was adapted by Sander Vanheule to support more devices.
> 
> Signed-off-by: Julien Dusser 
> Signed-off-by: Sander Vanheule 

technically, if Julien is first SoB, you should also put him in the author 
(From:) field.

> ---
>  .../dts/qca9563_tplink_eap2x5_1port.dtsi  | 139 ++
>  target/linux/ath79/image/generic-tp-link.mk   |  10 ++
>  2 files changed, 149 insertions(+)
>  create mode 100644
> target/linux/ath79/dts/qca9563_tplink_eap2x5_1port.dtsi
> 
> diff --git a/target/linux/ath79/dts/qca9563_tplink_eap2x5_1port.dtsi
> b/target/linux/ath79/dts/qca9563_tplink_eap2x5_1port.dtsi
> new file mode 100644
> index 00..24f0b4f0ce
> --- /dev/null
> +++ b/target/linux/ath79/dts/qca9563_tplink_eap2x5_1port.dtsi
> @@ -0,0 +1,139 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT #include

Not really important, but I'd prefer an empty line after the license. (Broken 
in my mail anyway, but I looked at it in patchwork.)

> + #include 
> +
> +#include "qca956x.dtsi"
> +
> +/ {
> + aliases {
> + label-mac-device = 
> + };
> +
> + keys {
> + compatible = "gpio-keys";
> +
> + reset {
> + label = "Reset button";
> + linux,code = ;
> + gpios = < 2 GPIO_ACTIVE_LOW>;
> + debounce-interval = <60>;
> + };
> + };
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> + num-cs = <1>;
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <2500>;
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition@0 {
> + label = "u-boot";
> + reg = <0x00 0x02>;
> + read-only;
> + };
> +
> + partition@2 {
> + label = "partition-table";
> + reg = <0x02 0x01>;
> + read-only;
> + };
> +
> + info: partition@3 {
> + label = "info";
> + reg = <0x03 0x01>;
> + read-only;
> + };
> +
> + partition@4 {
> + compatible = "openwrt,elf";
> + label = "firmware";
> + reg = <0x04 0xec>;
> + };
> +
> + partition@f0 {
> + label = "config";
> + reg = <0xf0 0x03>;
> + read-only;
> + };
> +
> + partition@f3 {
> + label = "mutil-log";
> + reg = <0xf3 0x08>;
> + read-only;
> + };
> +
> + 

RE: [RFC PATCH v2 0/6] ath79: support for TP-Link EAP2x5 1-port devices

[mail]

>  * I can probably provide working support for the EAP225 v1/v2, given
>the minimal differences between the devices. However, I do not have
>this device to test an image, nor has anyone offered to test on the
>forums. This device would have a similar flashing procedure as the
>EAP245 v1. Would you nevertheless want me to provide a patch?

Didn't really read that for the v1:
If it's not tested, we won't add it.
So, remove these devices for now (as you did in v2 anyway).
If this patchset is merged, you can open a PR in GitHub (or send a patch) for 
these devices and look for testers. Even if that one is closed later due to 
lack of testers, the code is at least preserved for later in case someone is 
looking for it.

Best

Adrian 


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [PATCH 1/1] Fix Wifi Button - off function not working

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Todor Colov
> Sent: Sonntag, 19. Juli 2020 10:28
> To: openwrt-devel@lists.openwrt.org
> Cc: Todor Colov 
> Subject: [PATCH 1/1] Fix Wifi Button - off function not working

This one looks valid from first look, however I wonder why it was working for 
me so far.

Anyway, please adjust based on formal requirement, e.g. format title properly 
and add a commit message.

Best

Adrian

> 
> Signed-off-by: Todor Colov 
> ---
>  package/base-files/files/etc/rc.button/rfkill | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/package/base-files/files/etc/rc.button/rfkill b/package/base-
> files/files/etc/rc.button/rfkill
> index fbdda40ed5..2d4f0f86ff 100755
> --- a/package/base-files/files/etc/rc.button/rfkill
> +++ b/package/base-files/files/etc/rc.button/rfkill
> @@ -27,6 +27,6 @@ case "${TYPE}" in
>  esac
>  config_foreach wifi_rfkill_set wifi-device  uci commit wireless -wifi up
> +wifi
> 
>  return 0
> --
> 2.27.0
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [PATCH 1/1] tools -> firmware-utils -> Add Linksys E8350 firmware header generator for native openwrt WEB factory image

[mail]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Todor Colov
> Sent: Sonntag, 19. Juli 2020 10:59
> To: openwrt-devel@lists.openwrt.org
> Cc: Todor Colov 
> Subject: [PATCH 1/1] tools -> firmware-utils -> Add Linksys E8350 firmware
> header generator for native openwrt WEB factory image

This doesn't follow our formal guidelines:
https://openwrt.org/submitting-patches

> 
> Signed-off-by: Todor Colov 
> ---
>  tools/firmware-utils/Makefile |   4 +-
>  .../src/linksys/e8350/addfwhdr.c  | 195 
>  .../src/linksys/e8350/bcmdefs.h   | 318 +
>  .../src/linksys/e8350/code_pattern.h  | 396 
>  tools/firmware-utils/src/linksys/e8350/crc.c  | 290 
>  tools/firmware-utils/src/linksys/e8350/crc.h  |  69 +++
>  .../src/linksys/e8350/cyutils.h   | 348 ++
>  .../src/linksys/e8350/typedefs.h  | 447 ++
>  8 files changed, 2066 insertions(+), 1 deletion(-)
>  create mode 100644 tools/firmware-utils/src/linksys/e8350/addfwhdr.c
>  create mode 100644 tools/firmware-utils/src/linksys/e8350/bcmdefs.h
>  create mode 100644 tools/firmware-utils/src/linksys/e8350/code_pattern.h
>  create mode 100644 tools/firmware-utils/src/linksys/e8350/crc.c
>  create mode 100644 tools/firmware-utils/src/linksys/e8350/crc.h
>  create mode 100644 tools/firmware-utils/src/linksys/e8350/cyutils.h
>  create mode 100644 tools/firmware-utils/src/linksys/e8350/typedefs.h
> 
> diff --git a/tools/firmware-utils/Makefile b/tools/firmware-utils/Makefile
> index 3dd9ac5c2c..14b47d1391 100644
> --- a/tools/firmware-utils/Makefile
> +++ b/tools/firmware-utils/Makefile
> @@ -23,6 +23,8 @@ endef
> 
>  define Host/Compile
>   mkdir -p $(HOST_BUILD_DIR)/bin
> + mkdir -p $(HOST_BUILD_DIR)/bin/linksys/e8350
> + $(call cc,linksys/e8350/addfwhdr linksys/e8350/crc )

Are you serious?

Create these files which are named specifically after one device, break the 
entire logic of this Makefile, and then just fill in a lot of code that is 
mostly unrelated to that specific device?

Please come back when you take it seriously.

Best

Adrian

>   $(call cc,add_header)
>   $(call cc,addpattern)
>   $(call cc,asustrx)
> @@ -97,7 +99,7 @@ define Host/Compile
>  endef
> 
>  define Host/Install
> - $(INSTALL_BIN) $(HOST_BUILD_DIR)/bin/*
> $(STAGING_DIR_HOST)/bin/
> + $(CP) $(HOST_BUILD_DIR)/bin/* $(STAGING_DIR_HOST)/bin/
>  endef
> 
>  $(eval $(call HostBuild))
> diff --git a/tools/firmware-utils/src/linksys/e8350/addfwhdr.c
> b/tools/firmware-utils/src/linksys/e8350/addfwhdr.c
> new file mode 100644
> index 00..6e2896c62d
> --- /dev/null
> +++ b/tools/firmware-utils/src/linksys/e8350/addfwhdr.c
> @@ -0,0 +1,195 @@
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "cyutils.h"
> +#include "code_pattern.h"
> +
> +#include "typedefs.h"
> +
> +#define MAX_BUF  1024
> +#define CRC32_INIT_VALUE 0x  /* Initial CRC32 checksum
> value */
> +
> +extern uint32 crc32(uint8 *pdata, uint nbytes, uint32 crc);
> +
> +int fd, fd_w;
> +
> +void die(const char * str, ...)
> +{
> + va_list args;
> + va_start(args, str);
> + vfprintf(stderr, str, args);
> + fputc('\n', stderr);
> + exit(1);
> +}
> +
> +int
> +fill_null0(int size)
> +{
> + unsigned char buf[1];
> + int i;
> +
> + fprintf(stderr,"Fill null\n");
> +
> + buf[0] = 0xff;
> + for (i=0 ; i< size; i++ )
> + if (write(fd_w, buf, 1) != 1)
> + return 0;
> +
> + return 1;
> +}
> +
> +long
> +file_open(const char *name)
> +{
> + struct stat sb;
> + if ((fd = open(name, O_RDONLY, 0)) < 0){
> + die("Unable to open `%s' : %m", name);
> + }
> +
> + if (fstat (fd, ))
> + die("Unable to stat `%s' : %m", name);
> +
> + return sb.st_size;
> +}
> +
> +void usage(void)
> +{
> + die("Usage: addfwhdr [-i|--input] sysupgrade.o [-o|--output]
> code.bin\n");
> +}
> +
> +int main(int argc, char ** argv)
> +{
> + uint input_size,c;
> + char *input_file=NULL, *output_file=NULL;
> +int opt;
> +int option_index=0;
> + int garbage = 0;
> + char *buf = NULL;
> +extern char *optarg;
> +extern int optind, opterr, optopt;
> +
> + struct cbt_fw_header *fwhdr;
> + uint32 crc;
> +
> +static struct option long_options[] =
> + {
> + {"input", 1, 0, 'i'},
> + {"output", 1, 0, 'o'},
> + {"garbage", 0, 0, 'g'},
> + {0, 0, 0, 0}
> + };
> +
> + printf("\n-- add fw header \n");
> +
> +fwhdr  = malloc(sizeof(struct cbt_fw_header));
> + memset(fwhdr, 0, sizeof(struct cbt_fw_header));
> +
> + while(1){
> + opt = getopt_long(argc, argv, 

RE: [PATCH 1/1] TARGET: Add new device support under target IPQ806x for Linksys E8350

[mail]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Todor Colov
> Sent: Sonntag, 19. Juli 2020 11:05
> To: openwrt-devel@lists.openwrt.org
> Cc: Todor Colov 
> Subject: [PATCH 1/1] TARGET: Add new device support under target IPQ806x
> for Linksys E8350
> 
> Signed-off-by: Todor Colov 

this patch has several formal issues, please have another look at 
https://openwrt.org/submitting-patches

What I see right away:
- commit title prefix
- title too long (e.g. just use "ipq806x: add support for Linksys E8350")
- missing commit description (Specifications, Flashing instructions, MAC 
address assignment, further notes)

> ---
>  .../ipq806x/base-files/etc/board.d/01_leds|   3 +
>  .../ipq806x/base-files/etc/board.d/02_network |   1 +
>  .../ipq806x/base-files/etc/rc.button/reset|  44 +++
>  .../ipq806x/base-files/lib/upgrade/fwtool.sh  |  67 +
>  .../base-files/lib/upgrade/platform.sh|   5 +
>  .../arch/arm/boot/dts/qcom-ipq8064-e8350.dts  | 265
> ++
>  target/linux/ipq806x/image/Makefile   |  31 ++
>  .../0069-arm-boot-add-dts-files.patch |   3 +-
>  8 files changed, 418 insertions(+), 1 deletion(-)  create mode 100644
> target/linux/ipq806x/base-files/etc/rc.button/reset
>  create mode 100644 target/linux/ipq806x/base-files/lib/upgrade/fwtool.sh
>  create mode 100644 target/linux/ipq806x/files-
> 5.4/arch/arm/boot/dts/qcom-ipq8064-e8350.dts
> 
> diff --git a/target/linux/ipq806x/base-files/etc/board.d/01_leds
> b/target/linux/ipq806x/base-files/etc/board.d/01_leds
> index f8b6c32358..892dab88c8 100755
> --- a/target/linux/ipq806x/base-files/etc/board.d/01_leds
> +++ b/target/linux/ipq806x/base-files/etc/board.d/01_leds
> @@ -11,6 +11,9 @@ board=$(board_name)
>  boardname="${board##*,}"
> 
>  case "$board" in
> +linksys,e8350)

Please take care of alphabetic sorting. Check whether this can be merged with 
other cases (can't see this from the mere patch).

> + ucidef_set_led_wlan "wlan" "WLAN" "${boardname}:green:wifi"
> "phy0tpt"
> + ;;
>  buffalo,wxr-2533dhp)
>   ucidef_set_led_wlan "wlan" "WLAN" "${boardname}:white:wireless"
> "phy0tpt"
>   ucidef_set_led_switch "wan" "WAN" "${boardname}:white:internet"
> "switch0" "0x20"
> diff --git a/target/linux/ipq806x/base-files/etc/board.d/02_network
> b/target/linux/ipq806x/base-files/etc/board.d/02_network
> index 529a8d9f39..60c68da020 100755
> --- a/target/linux/ipq806x/base-files/etc/board.d/02_network
> +++ b/target/linux/ipq806x/base-files/etc/board.d/02_network
> @@ -18,6 +18,7 @@ netgear,d7800 |\
>  netgear,r7500 |\
>  netgear,r7500v2 |\
>  qcom,ipq8064-ap148 |\
> +linksys,e8350 |\

sorting.

>  tplink,vr2600v)
>   ucidef_add_switch "switch0" \
>   "1:lan" "2:lan" "3:lan" "4:lan" "6@eth1" "5:wan" "0@eth0"
> diff --git a/target/linux/ipq806x/base-files/etc/rc.button/reset
> b/target/linux/ipq806x/base-files/etc/rc.button/reset
> new file mode 100644
> index 00..e6bdcb4cdc
> --- /dev/null
> +++ b/target/linux/ipq806x/base-files/etc/rc.button/reset

What's that for? Implementation of reset button is available with KEY_RESTART 
OOTB.

> @@ -0,0 +1,44 @@
> +#!/bin/sh
> +
> +. /lib/functions.sh
> +. /lib/functions/uci-defaults.sh
> +. /lib/functions/system.sh
> +
> +board_config_update
> +board=$(board_name)
> +
> +
> +OVERLAY="$( grep ' /overlay ' /proc/mounts )"
> +
> +case "$ACTION" in
> +pressed)
> + [ -z "$OVERLAY" ] && return 0
> +
> + return 5
> +;;
> +timeout)
> + . /etc/diag.sh
> + set_state failsafe
> +;;
> +released)
> + if [ "$SEEN" -lt 1 ]
> + then
> + echo "REBOOT" > /dev/console
> + sync
> + reboot
> + elif [ "$SEEN" -ge 5 -a -n "$OVERLAY" ]
> + then
> + echo "FACTORY RESET" > /dev/console
> + case "$board" in
> + linksys,e8350)
> + rm -f /etc/config/* ; cp -a /rom/etc/* /etc/. ;
> sync ; reboot
> + ;;
> + *)
> + jffs2reset -y && reboot &
> + ;;
> + esac
> + fi
> +;;
> +esac
> +
> +return 0
> diff --git a/target/linux/ipq806x/base-files/lib/upgrade/fwtool.sh
> b/target/linux/ipq806x/base-files/lib/upgrade/fwtool.sh
> new file mode 100644
> index 00..6929518204
> --- /dev/null
> +++ b/target/linux/ipq806x/base-files/lib/upgrade/fwtool.sh

Same here. Why do you copy that stuff over?

> @@ -0,0 +1,67 @@
> +fwtool_check_signature() {
> + [ $# -gt 1 ] && return 1
> +
> + [ ! -x /usr/bin/ucert ] && {
> + if [ "$REQUIRE_IMAGE_SIGNATURE" = 1 ]; then
> + return 1
> + else
> + return 0
> + fi
> + }
> +
> + if ! fwtool -q -s /tmp/sysupgrade.ucert "$1"; then
> + echo "Image signature not found"
> + [ "$REQUIRE_IMAGE_SIGNATURE" 

RE: [RFC PATCH 5/5] ipq40xx: add target for Google WiFi (Gale)

[mail]

Hi,

just some formal stuff below.

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Brian Norris
> Sent: Samstag, 18. Juli 2020 22:52
> To: openwrt-devel@lists.openwrt.org
> Cc: Brian Norris 
> Subject: [RFC PATCH 5/5] ipq40xx: add target for Google WiFi (Gale)
> 
> Google WiFi (codename: Gale) is an IPQ4019-based AP, with 2 Ethernet
> ports, 2x2 2.4+5GHz WiFi, 512 MB RAM, 4 GB eMMC, and a USB type C port.
> In its stock configuration, it runs a Chromium OS-based system, but you
> wouldn't know it, since you can only manage it via a "cloud" + mobile-app
> system.
> 
> The "v2" label is coded into the bootloader, which prefers the "google,gale-
> v2" compatible string. I believe "v1" must have been pre-release hardware.
> 
> Note: this is *not* the Google Nest WiFi, released in 2019.
> 
> I include "factory.bin" support, where we generate a GPT-based disk image
> with 2 partitions -- a kernel partition (using the custom "Chrome OS kernel"
> GUID type) and a root filesystem partition. If the AP is in Developer Mode,
> the stock bootloader can boot it via a USB disk or (after gaining access via 
> USB
> boot) flashed to the eMMC.

I'd like a bit more detailed flashing instructions here. What you have right 
now only works if the reader knows what to do anyway.

> 
> Sysupgrade also seems to work OK, although I've omitted some of the
> (re)partitioning handling. I also hard-code /dev/mmcblk0 -- while MMC
> device numbering can technically change, there's no other MMC controller
> present (e.g., no SD card slot).
> 
> "FEATURES=boot-part rootfs-part" is required to get kernel and rootfs
> partition sizes established. This adds extra (unused) configuration
> parameters for other ipq40xx targets, so I'm not sure if this is the "right"
> thing to do either.
> 
> Features I have tested:
> 
>  * Ethernet, both WAN and LAN ports
>  * eMMC
>  * USB-C (hub, power-delivery, peripherals)
>  * LED0 (R/G/B)
>  * WiFi (limited testing)
>  * SPI flash
>  * Serial console: once in developer mode, console can be accessed via
>the USB-C port with SuzyQable, or other similar "Closed Case
>Debugging" tools:
> 
> https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/
> master/docs/ccd.md#suzyq-suzyqable
> 
> Not tested:
> 
>  * TPM
>  * LED1, LED2: I'm not even confident they are actually populated
>anywhere
> 
> Known not working:
> 
>  * Reboot: this seems to require some additional TrustZone / SCM
>configuration; with additional local patches, I have this working,
>but I'm still trying to figure out exactly the right way I should
>integrate this. Ideally, I could propose it upstream, instead of just
>adding a custom OpenWRT patch. Without this patch, reboot just hangs
>the system. (NB: I've found at least one other user report of this on
>an "IPQ4019" device, but I don't know yet if that's the same.)
>  * There's a single external button, and a few useful internal GPIO
>switches. I haven't hooked them up.
> 
> Much of the DTS is pulled from the Chrome OS kernel 3.18 branch, which the
> manufacturer image uses.
> 
> Note: the manufacturer bootloader knows how to patch in calibration data
> via the wifi{0,1} aliases in the DTB, so while these properties aren't 
> present in
> the DTS, they are available at runtime:
> 
>   # ls -l
> /sys/firmware/devicetree/base/soc/wifi@a*/qcom,ath10k-pre-calibration-
> data
>   -r--r--r--1 root root 12064 Jul 15 19:11
> /sys/firmware/devicetree/base/soc/wifi@a00/qcom,ath10k-pre-
> calibration-data
>   -r--r--r--1 root root 12064 Jul 15 19:11
> /sys/firmware/devicetree/base/soc/wifi@a80/qcom,ath10k-pre-
> calibration-data
> 
> Ethernet MAC addresses are similarly patched in via the ethernet{0,1}
> aliases.
> 
> Signed-off-by: Brian Norris 
> ---
>  target/linux/ipq40xx/Makefile |   2 +-
>  .../ipq40xx/base-files/etc/board.d/02_network |   1 +
>  .../base-files/lib/upgrade/platform.sh|  13 +
>  .../arm/boot/dts/qcom-ipq4019-gale-v2.dts | 402 ++
>  target/linux/ipq40xx/image/Makefile   |  14 +
>  .../901-arm-boot-add-dts-files.patch  |   3 +-
>  6 files changed, 433 insertions(+), 2 deletions(-)  create mode 100644
> target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-gale-v2.dts
> 
> diff --git a/target/linux/ipq40xx/Makefile b/target/linux/ipq40xx/Makefile
> index 94b47c4c96de..c114df620d5c 100644
> --- a/target/linux/ipq40xx/Makefile
> +++ b/target/linux/ipq40xx/Makefile
> @@ -3,7 +3,7 @@ include $(TOPDIR)/rules.mk  ARCH:=arm  BOARD:=ipq40xx
> BOARDNAME:=Qualcomm Atheros IPQ40XX -FEATURES:=squashfs fpu
> ramdisk nand
> +FEATURES:=squashfs fpu ramdisk nand boot-part rootfs-part
>  CPU_TYPE:=cortex-a7
>  CPU_SUBTYPE:=neon-vfpv4
>  SUBTARGETS:=generic
> diff --git a/target/linux/ipq40xx/base-files/etc/board.d/02_network
> 

RE: [RFC PATCH 3/5] image-commands: support Chromium OS image-type creation

[mail]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Brian Norris
> Sent: Samstag, 18. Juli 2020 22:52
> To: openwrt-devel@lists.openwrt.org
> Cc: Brian Norris 
> Subject: [RFC PATCH 3/5] image-commands: support Chromium OS image-
> type creation
> 
> See the previous patches, which implemented the cros-vbutil verified-boot
> payload-packing tool, and extended ptgen for the CrOS kernel partition type.
> With these, it's now possible to package kernel + rootfs to make disk images
> that can boot a Chrome OS-based system (e.g., Chromebooks, or even a few
> AP models).
> 
> gen_image_vboot.sh borrows a bit of structure from gen_image_generic.sh,
> but I didn't feel it fit well to try and add new flags to the latter, given 
> the
> difference in its FAT kernel packaging and our raw kernel partition packing.
> 
> Signed-off-by: Brian Norris 
> ---
>  include/image-commands.mk  | 17 +
> scripts/gen_image_vboot.sh | 29 +
>  2 files changed, 46 insertions(+)
>  create mode 100755 scripts/gen_image_vboot.sh
> 
> diff --git a/include/image-commands.mk b/include/image-commands.mk
> index e7db7128b4ca..ca8e826ffb1e 100644
> --- a/include/image-commands.mk
> +++ b/include/image-commands.mk

Why is this added globally and not just for ipq40xx (same for the script)?

Do you plan to use it for other targets?

Best

Adrian

> @@ -164,6 +164,23 @@ define Build/fit
>   @mv $@.new $@
>  endef
> 
> +define Build/cros-image
> + $(SCRIPT_DIR)/gen_image_vboot.sh \
> +   $@ \
> +   $(CONFIG_TARGET_KERNEL_PARTSIZE) $(IMAGE_KERNEL) \
> +   $(CONFIG_TARGET_ROOTFS_PARTSIZE) $(IMAGE_ROOTFS)
> endef
> +
> +# NB: Chrome OS bootloaders replace the '%U' in command lines with the
> +UUID of # the kernel partition it chooses to boot from. This gives a
> +flexible way to # consistently build and sign kernels that always use
> +the subsequent # (PARTNROFF=1) partition as their rootfs.
> +define Build/cros-vboot
> + $(STAGING_DIR_HOST)/bin/cros-vbutil \
> + -k $@ -c "root=PARTUUID=%U/PARTNROFF=1" -o $@.new
> + @mv $@.new $@
> +endef
> +
>  define Build/lzma
>   $(call Build/lzma-no-dict,-lc1 -lp2 -pb2 $(1))  endef diff --git
> a/scripts/gen_image_vboot.sh b/scripts/gen_image_vboot.sh new file
> mode 100755 index ..acded33de654
> --- /dev/null
> +++ b/scripts/gen_image_vboot.sh
> @@ -0,0 +1,29 @@
> +#!/usr/bin/env bash
> +# Copyright (C) 2020 OpenWrt.org
> +set -e -x
> +[ $# == 5 ] || {
> +echo "SYNTAX: $0
> "
> +exit 1
> +}
> +
> +OUTPUT="$1"
> +KERNELSIZE="$2"
> +KERNELIMAGE="$3"
> +ROOTFSSIZE="$4"
> +ROOTFSIMAGE="$5"
> +
> +rm -f "${OUTPUT}"
> +
> +head=16
> +sect=63
> +
> +# create partition table
> +set $(ptgen -o "$OUTPUT" -h $head -s $sect -g -T cros_kernel -p
> +${KERNELSIZE}m -p ${ROOTFSSIZE}m)
> +
> +KERNELOFFSET="$(($1 / 512))"
> +KERNELSIZE="$2"
> +ROOTFSOFFSET="$(($3 / 512))"
> +ROOTFSSIZE="$(($4 / 512))"
> +
> +dd if="${KERNELIMAGE}" of="${OUTPUT}" bs=512
> seek="${KERNELOFFSET}"
> +conv=notrunc dd if="${ROOTFSIMAGE}" of="${OUTPUT}" bs=512
> +seek="${ROOTFSOFFSET}" conv=notrunc
> --
> 2.27.0
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [OpenWrt-Devel] [PATCH 3/3] vxlan: add capability for multiple fdb entries

[mail]

If you resend this with adjustments, please also bump PKG_RELEASE then as well.

Since both patches received positive feedback, I think it should be enough to 
bump it once for the 3/3 patch.

Best

Adrian

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Matthias Schiffer
> Sent: Samstag, 18. Juli 2020 17:34
> To: Johannes Kimmel 
> Cc: openwrt-devel@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] [PATCH 3/3] vxlan: add capability for multiple
> fdb entries
> 
> On 6/8/20 4:14 PM, Johannes Kimmel wrote:
> > Similar to wireguard, vxlan can configure multiple peers or add
> > specific entries to the fdb for a single mac address.
> >
> > While you can still use peeraddr/peer6addr option within the proto
> > vxlan/vxlan6 section to not break existing configurations, this patch
> > allows to add multiple sections that conigure fdb entries via the
> > bridge command. As such, the bridge command is now a dependency of
> the
> > vxlan package. (To be honest without the bridge command available,
> > vxlan isn't very much fun to use or debug at all)
> 
> I have added two comments below; apart from this, the patch is looking
> good.
> 
> >
> > Field names are taken direclty from the bridge command.
> >
> > Example with all supported parameters, since this hasn't been
> > documented so
> > far:
> >
> >   config interface 'vx0'
> >   option proto 'vxlan6'  # use vxlan over ipv6
> >
> >   # main options
> >   option ip6addr   '2001:db8::1' # listen address
> >   option tunlink   'wan6'# optional if listen address given
> >   option peer6addr '2001:db8::2' # now optional
> >   option port  '8472'# this is the standard port under linux
> >   option vid   '42'  # VXLAN Network Identifier to use
> >   option mtu   '1430'# vxlan6 has 70 bytes overhead
> >
> >   # extra options
> >   option rxcsum  '0'  # allow receiving packets without checksum
> >   option txcsum  '0'  # send packets without checksum
> >   option ttl '16' # specifies the TTL value for outgoing packets
> >   option tos '0'  # specifies the TOS value for outgoing packets
> >   option macaddr '11:22:33:44:55:66' # optional, manually specify mac
> >  # default is a random address
> >
> > Single peer with head-end replication. Corresponds to the following
> > call to bridge:
> >
> >   $ bridge fdb append 00:00:00:00:00:00 dev vx0 dst 2001:db8::3
> >
> >   config vxlan_vx0
> 
> We usually keep the UCI section name a constant string, and `vxlan_*` is not
> very descriptive.
> 
> Let's call this 'vxlan_peer' or 'vxlan_dst'. The reference to the interface
> should be specified as a separate option, for example:
> 
>   option vxlan 'vx0'
> 
> 
> 
> >   option dst '2001:db8::3' # always required
> >
> > It's possible to specify a multicast address as destination. Useful
> > when multicast routing is available or within one lan segment:
> >
> >   config vxlan_vx0
> >   option dst 'ff02::1337' # multicast group to join.
> >   # all bum traffic will be send there
> >   option via 'eth1'   # for multicast, an outgoing interface needs
> >   # to be specified
> >
> > All available peer options for completeness:
> >
> >   config vxlan_vx0
> >   option lladdr  'aa:bb:cc:dd:ee:ff' # specific mac,
> >   option dst '2001:db8::4'   # connected to this peer
> >   option via 'eth0.1'# use this interface only
> >   option port'4789'  # use different port for this peer
> >   option vni '23'# override vni for this peer
> >   option src_vni '123'   # see man 3 bridge
> >
> > Signed-off-by: Johannes Kimmel > ---
> >  package/network/config/vxlan/Makefile   |  2 +-
> >  package/network/config/vxlan/files/vxlan.sh | 36
> > -
> >  2 files changed, 36 insertions(+), 2 deletions(-)
> >
> > diff --git a/package/network/config/vxlan/Makefile
> > b/package/network/config/vxlan/Makefile
> > index 5850c44..46970d9 100644
> > --- a/package/network/config/vxlan/Makefile
> > +++ b/package/network/config/vxlan/Makefile
> > @@ -11,7 +11,7 @@ define Package/vxlan
> >CATEGORY:=Network
> >MAINTAINER:=Matthias Schiffer 
> >TITLE:=Virtual eXtensible LAN config support
> > -  DEPENDS:=+kmod-vxlan
> > +  DEPENDS:=+kmod-vxlan +ip-bridge
> 
> I'd like to avoid making this dependency mandatory, as we're using the vxlan
> package in Gluon on devices with small flash.
> 
> Let's just call proto_notify_error from proto_vxlan_setup_peer when
> `bridge` is not available.
> 
> 
> >PKGARCH:=all
> >  endef
> >
> > diff --git a/package/network/config/vxlan/files/vxlan.sh
> > b/package/network/config/vxlan/files/vxlan.sh
> > index bdcaa62..319d95c 100755
> > --- 

RE: [RFC PATCH 4/7] ath79: prepare for 1-port TP-Link EAP2x5 devices

[mail]

> I tried 80MHz and 65MHz, but that didn't result in proper reads. 50MHz,
> 55MHz, and 60MHz do appear to work on my eap245-v1, so I really wouldn't
> risk going above 50MHz.

If you've taken the 25 MHz somewhere reasonable, as you stated, I'd also be 
fine with that.

My motivation is mainly to prevent copy/pasting that value from other devices 
without thinking, ending up with slower read speed without a real reason.

So, either do a simple read test whether 50 MHz is faster, and take it if there 
is relevant improvement, or stick to the 25 Mhz from GPL sources anyway.

Best

Adrian

> 
> [1] https://github.com/Deoptim/atheros
> [2]
> https://www.semiconductorstore.com/pages/asp/DownloadDirect.asp?sid=
> 1594989703348
> 
> 
> Best,
> Sander
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [RFC PATCH 6/7] ath79: support for TP-Link EAP225-Outdoor v1

[mail]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Sander Vanheule
> Sent: Freitag, 17. Juli 2020 13:38
> To: openwrt-devel@lists.openwrt.org
> Cc: Sander Vanheule ; m...@bibbl.com;
> julien.dus...@free.fr; j...@phrozen.org; ra...@milecki.pl; yn...@true.cz;
> m...@david-bauer.net
> Subject: [RFC PATCH 6/7] ath79: support for TP-Link EAP225-Outdoor v1
> 
> TP-Link EAP225-Outdoor v1 is an AC1200 (802.11ac Wave-2) pole or wall
> mount access point.
> 
> Device specifications:
> * SoC: QCA9563 @ 775MHz
> * Memory: 128MiB DDR2
> * Flash: 16MiB SPI-NOR
> * Wireless 2.4GHz (SoC): b/g/n 2x2
> * Wireless 5GHz (QCA9886): a/n/ac 2x2 MU-MIMO
> * Ethernet (AR8033): 1× 1GbE, PoE
> 
> Flashing instructions:
> * ssh into target device with recent (>= v1.6.0) firmware
> * run `cliclientd stopcs` on target device
> * upload factory image via web interface
> 
> MAC addresses:
> MAC address (as on device label) is stored in device info partition at an 
> offset
> of 8 bytes. ath9k device has same address as ethernet, ath10k uses address
> incremented by 1.
> From stock ifconfig:
> 
> ath0  Link encap:Ethernet  HWaddr D8:...:2E
> ath10 Link encap:Ethernet  HWaddr D8:...:2F
> br0   Link encap:Ethernet  HWaddr D8:...:2E
> eth0  Link encap:Ethernet  HWaddr D8:...:2E
> 
> Tested by forum user PolynomialDivision on firmware v1.7.0.
> 
> Signed-off-by: Sander Vanheule 
> ---
>  .../ath79/dts/qca9563_tplink_eap225od-v1.dts  | 21 ++
> .../generic/base-files/etc/board.d/02_network |  1 +
> .../etc/hotplug.d/firmware/11-ath10k-caldata  |  6 
>  target/linux/ath79/image/generic-tp-link.mk   | 10 +++
>  tools/firmware-utils/src/tplink-safeloader.c  | 29 +++
>  5 files changed, 67 insertions(+)
>  create mode 100644 target/linux/ath79/dts/qca9563_tplink_eap225od-
> v1.dts
> 
> diff --git a/target/linux/ath79/dts/qca9563_tplink_eap225od-v1.dts
> b/target/linux/ath79/dts/qca9563_tplink_eap225od-v1.dts
> new file mode 100644
> index 00..dcfdb7e524
> --- /dev/null
> +++ b/target/linux/ath79/dts/qca9563_tplink_eap225od-v1.dts
> @@ -0,0 +1,21 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT /dts-v1/;
> +
> +#include 

in DTSI.

> +
> +#include "qca9563_tplink_eap2x5_1port.dtsi"
> +
> +/ {
> + compatible = "tplink,eap225od-v1", "qca,qca9563";

No abbreviations, please. Replace by tplink,eap225-outdoor-v1 (everywhere).

> + model = "TP-Link EAP225-Outdoor v1";
> +};
> +
> +_status_green {
> + status = "okay";
> + gpios = < 7 GPIO_ACTIVE_LOW>;
> +};
> +
> +_status_amber {
> + status = "okay";
> + gpios = < 9 GPIO_ACTIVE_LOW>;
> +};
> diff --git a/target/linux/ath79/generic/base-files/etc/board.d/02_network
> b/target/linux/ath79/generic/base-files/etc/board.d/02_network
> index d19f885e27..9bcee6da0e 100755
> --- a/target/linux/ath79/generic/base-files/etc/board.d/02_network
> +++ b/target/linux/ath79/generic/base-files/etc/board.d/02_network
> @@ -38,6 +38,7 @@ ath79_setup_interfaces()
>   pisen,wmb001n|\
>   pisen,wmm003n|\
>   siemens,ws-ap3610|\
> + tplink,eap225od-v1|\
>   tplink,eap245-v1|\
>   tplink,cpe210-v2|\
>   tplink,cpe210-v3|\
> diff --git a/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/11-
> ath10k-caldata b/target/linux/ath79/generic/base-
> files/etc/hotplug.d/firmware/11-ath10k-caldata
> index d722f2dcaf..b964c302d5 100644
> --- a/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/11-
> ath10k-caldata
> +++ b/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/11-at
> +++ h10k-caldata
> @@ -194,6 +194,12 @@ case "$FIRMWARE" in
>   ln -sf /lib/firmware/ath10k/pre-cal-pci-\:00\:00.0.bin \
>   /lib/firmware/ath10k/QCA9888/hw2.0/board.bin
>   ;;
> + tplink,eap225od-v1)
> + caldata_extract "art" 0x5000 0x2f20
> + ath10k_patch_mac $(macaddr_add $(mtd_get_mac_binary
> info 0x8) +1)
> + ln -sf /lib/firmware/ath10k/pre-cal-pci-\:00\:00.0.bin \
> + /lib/firmware/ath10k/QCA9888/hw2.0/board.bin
> + ;;
>   tplink,eap245-v3)
>   caldata_extract "art" 0x5000 0x2f20
>   ath10k_patch_mac $(macaddr_add $(mtd_get_mac_binary
> info 0x8) +1) diff --git a/target/linux/ath79/image/generic-tp-link.mk
> b/target/linux/ath79/image/generic-tp-link.mk
> index a4a14ed889..9ac24908fe 100644
> --- a/target/linux/ath79/image/generic-tp-link.mk
> +++ b/target/linux/ath79/image/generic-tp-link.mk
> @@ -372,6 +372,16 @@ define Device/tplink_eap2x5_1port
>IMAGE/factory.bin := append-rootfs | tplink-safeloader factory | pad-extra
> 128  endef
> 
> +define Device/tplink_eap225od-v1
> +  $(Device/tplink_eap2x5_1port)
> +  DEVICE_MODEL := EAP225-Outdoor
> +  DEVICE_VARIANT := v1
> +  TPLINK_BOARD_ID := EAP225OD-V1
> +  DEVICE_PACKAGES := kmod-ath10k-ct ath10k-firmware-qca9888-ct 

RE: [RFC PATCH 5/7] ath79: support for TP-Link EAP245 v1

[mail]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Sander Vanheule
> Sent: Freitag, 17. Juli 2020 13:38
> To: openwrt-devel@lists.openwrt.org
> Cc: Sander Vanheule ; m...@bibbl.com;
> julien.dus...@free.fr; j...@phrozen.org; ra...@milecki.pl; yn...@true.cz;
> m...@david-bauer.net
> Subject: [RFC PATCH 5/7] ath79: support for TP-Link EAP245 v1
> 
> TP-Link EAP245 v1 is an AC1750 (802.11ac Wave-1) ceiling mount access point.
> 
> Device specifications:
> * SoC: QCA9563 @ 775MHz
> * RAM: 128MiB DDR2
> * Flash: 16MiB SPI-NOR
> * Wireless 2.4GHz (SoC): b/g/n, 3x3
> * Wireless 5Ghz (QCA9880): a/n/ac, 3x3
> * Ethernet (AR8033): 1× 1GbE, 803.2at PoE
> 
> Flashing instructions:
> * Extract /usr/bin/uclited from the device via ssh and apply the binary
>   patch listed below. The patch is required to prevent `uclited -u` in
>   the last step from crashing.
> * Exploit the user management page in the web interface to start telnetd
>   by changing the username to `;/usr/sbin/telnetd -l/bin/sh&`.
> * Immediately change the malformed username back to something valid
>   (e.g. 'admin') to make ssh work again.
> * Use the root shell via telnet to make /tmp world writeable (chmod 777)
> * Copy the patched uclited programme back to the device at /tmp/uclited
>   (via ssh)
> * Upload the factory image to /tmp/upgrade.bin (via ssh)
> * Run `chmod +x /tmp/uclited && /tmp/uclited -u` to flash OpenWrt.
> 
> --- xxd uclited
> +++ xxd uclited-patched
> @@ -53796,7 +53796,7 @@
>  000d2240: 8c44  0320 f809   8fbc 0010  .D... ..
>  000d2250: 8fa6 0a4c 02c0 2821 8f82 87b8    ...L..(!
> -000d2260: 8c44  0c13 45e0 27a7 0018 8fbc 0010  .DE.'...
> +000d2260: 8c44  2402    8fbc 0010  .D..$...
>  000d2270: 1040 001d  1821 8f99 8374 3c04 0058  .@.!...t<..X
>  000d2280: 3c05 0056 2484 a898 24a5 9a30 0320 f809  <..V$...$..0. ..
> 
> Debricking:
> * Serial port can be soldered on PCB J3 (1: TXD, 2: RXD, 3: GND, 4: VCC)
> * Bridge unpopulated resistors R225 (TXD) and R237 (RXD).
>   Do NOT bridge R230.
> * Use 3.3V, 115200 baud, 8n1
> * Interrupt bootloader with by holding CTRL+B during boot
> * tftp initramfs to flash via Luci web-interface
> 
> Tested on the EAP245v1 running the latest firmware (v1.4.0). The binary
> patch might not apply to uclited from other firmware versions.
> 
> Signed-off-by: Sander Vanheule 
> ---
>  .../ath79/dts/qca9563_tplink_eap245-v1.dts| 26 +
>  .../generic/base-files/etc/board.d/02_network |  1 +
> .../etc/hotplug.d/firmware/11-ath10k-caldata  |  3 +-
>  target/linux/ath79/image/generic-tp-link.mk   |  9 ++
>  tools/firmware-utils/src/tplink-safeloader.c  | 28 +++
>  5 files changed, 66 insertions(+), 1 deletion(-)  create mode 100644
> target/linux/ath79/dts/qca9563_tplink_eap245-v1.dts
> 
> diff --git a/target/linux/ath79/dts/qca9563_tplink_eap245-v1.dts
> b/target/linux/ath79/dts/qca9563_tplink_eap245-v1.dts
> new file mode 100644
> index 00..8a11d2e469
> --- /dev/null
> +++ b/target/linux/ath79/dts/qca9563_tplink_eap245-v1.dts
> @@ -0,0 +1,26 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT /dts-v1/;
> +
> +#include 

This line is already in the DTSI.

> +
> +#include "qca9563_tplink_eap2x5_1port.dtsi"
> +
> +/ {
> + compatible = "tplink,eap245-v1", "qca,qca9563";
> + model = "TP-Link EAP245 v1";
> +};
> +
> +_status_green {
> + status = "okay";
> + gpios = < 7 GPIO_ACTIVE_HIGH>;
> +};
> +
> +_status_amber {
> + status = "okay";
> + gpios = < 9 GPIO_ACTIVE_HIGH>;
> +};
> +
> +_status_red {
> + status = "okay";
> + gpios = < 1 GPIO_ACTIVE_HIGH>;
> +};

Use the whole LED block in the root node here, see my comment on the DTSI ...

> diff --git a/target/linux/ath79/generic/base-files/etc/board.d/02_network
> b/target/linux/ath79/generic/base-files/etc/board.d/02_network
> index 7524806d72..d19f885e27 100755
> --- a/target/linux/ath79/generic/base-files/etc/board.d/02_network
> +++ b/target/linux/ath79/generic/base-files/etc/board.d/02_network
> @@ -38,6 +38,7 @@ ath79_setup_interfaces()
>   pisen,wmb001n|\
>   pisen,wmm003n|\
>   siemens,ws-ap3610|\
> + tplink,eap245-v1|\
>   tplink,cpe210-v2|\
>   tplink,cpe210-v3|\
>   tplink,cpe510-v2|\
> diff --git a/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/11-
> ath10k-caldata b/target/linux/ath79/generic/base-
> files/etc/hotplug.d/firmware/11-ath10k-caldata
> index 2926796d65..d722f2dcaf 100644
> --- a/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/11-
> ath10k-caldata
> +++ b/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/11-at
> +++ h10k-caldata
> @@ -63,7 +63,8 @@ case "$FIRMWARE" in
>   caldata_extract "art" 0x5000 0x844
>   ath10k_patch_mac $(macaddr_add $(mtd_get_mac_ascii u-
> boot-env 

RE: [RFC PATCH 4/7] ath79: prepare for 1-port TP-Link EAP2x5 devices

[mail]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Sander Vanheule
> Sent: Freitag, 17. Juli 2020 13:38
> To: openwrt-devel@lists.openwrt.org
> Cc: Sander Vanheule ; m...@bibbl.com;
> julien.dus...@free.fr; j...@phrozen.org; ra...@milecki.pl; yn...@true.cz;
> m...@david-bauer.net
> Subject: [RFC PATCH 4/7] ath79: prepare for 1-port TP-Link EAP2x5 devices
> 
> TP-Link has developed a number of access points based on the AP152
> reference board. In the EAP-series of 802.11ac access points, this includes
> the following devices with one ethernet port:
> * EAP225 v1/v2
> * EAP225 v3
> * EAP225-Outdoor v1
> * EAP245 v1
> 
> Since the only differences between these devices are the ath10k wireless
> radios and LEDs, a common base is provided for the overlapping support
> requirements.
> 
> Hardware commonalities:
> * SoC: QCA9563-AL3A MIPS 74kc v5.0 @ 775MHz
> * RAM: 128MiB DDR2 @ 650MHz
> * Flash: 16MiB SPI NOR
> * Wi-Fi 2.4GHz: provided by SoC
> * Wi-Fi 5Ghz: ath10k chip on PCIe
> * Ethernet: AR8033-AL1A, one 1GbE port (802.3at PoE)
> 
> This patch was originally developed by Julien Dusser for the EAP245 v1, and
> was adapted by Sander Vanheule to support more devices.
> 
> Signed-off-by: Julien Dusser 
> Signed-off-by: Sander Vanheule 
> ---
>  .../dts/qca9563_tplink_eap2x5_1port.dtsi  | 174 ++
>  target/linux/ath79/image/generic-tp-link.mk   |  10 +
>  2 files changed, 184 insertions(+)
>  create mode 100644
> target/linux/ath79/dts/qca9563_tplink_eap2x5_1port.dtsi
> 
> diff --git a/target/linux/ath79/dts/qca9563_tplink_eap2x5_1port.dtsi
> b/target/linux/ath79/dts/qca9563_tplink_eap2x5_1port.dtsi
> new file mode 100644
> index 00..1b55bb855c
> --- /dev/null
> +++ b/target/linux/ath79/dts/qca9563_tplink_eap2x5_1port.dtsi
> @@ -0,0 +1,174 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT /dts-v1/;

dts-v1 should only be defined once, please remove it in the DTSI and keep it in 
the DTS (so we ensure we have it once and always at beginning of the DTS).

> +
> +#include 
> +#include 
> +
> +#include "qca956x.dtsi"
> +
> +/ {
> + aliases {
> + label-device-mac = 

label-mac-device?

> + led-boot = _status_green;
> + led-failsafe = _status_amber;
> + led-running = _status_green;
> + led-upgrade = _status_amber;
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led_status_green: status_green {
> + status = "disabled";
> + label = "tp-link:green:status";
> + default-state = "on";
> + };
> +
> + led_status_amber: status_amber {
> + status = "disabled";
> + label = "tp-link:amber:status";
> + };
> +
> + led_status_red: status_red {
> + status = "disabled";
> + label = "tp-link:red:status";
> + };
> + };

Since what you add in the DTS files is not much less than what you have here, 
I'd prefer to just put the entire led node into the DTS file.
It will be much easier to read and you won't need that status lines at all.

> +
> + keys {
> + compatible = "gpio-keys";
> +
> + reset {
> + label = "Reset button";
> + linux,code = ;
> + gpios = < 2 GPIO_ACTIVE_LOW>;
> + debounce-interval = <60>;
> + };
> + };
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};

This block can be dropped, gpio is not disabled in qca956x.dtsi

> +
> + {
> + status = "okay";
> + num-cs = <1>;
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <2500>;

Can this go faster?

Best

Adrian

> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition@0 {
> + label = "u-boot";
> + reg = <0x00 0x02>;
> + read-only;
> + };
> +
> + partition@2 {
> + label = "partition-table";
> + reg = <0x02 0x01>;
> + read-only;
> + };
> +
> + info: partition@3 {
> + label = "info";
> + reg = <0x03 0x01>;
> + read-only;
> + };
> +
> + partition@4 {
> + compatible = "openwrt,elf";
> +  

RE: [PATCH] iftop: fix compilation with GCC 10

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Petr Štetiar
> Sent: Freitag, 17. Juli 2020 11:50
> To: Rosen Penev 
> Cc: openwrt-devel@lists.openwrt.org
> Subject: Re: [PATCH] iftop: fix compilation with GCC 10
> 
> Rosen Penev  [2020-07-13 22:43:51]:
> 
> Hi,
> 
> > GCC 10 defaults to fno-common, which demains unique defenitions.
> 
> whats the exact error here? Wouldn't it make sense to move this into
> packages feed?

I couldn't find any reference to/dependency on that package anywhere in main 
repo, and description there also describes it as something 
nice-to-have-when-you-need-it. Sounds like packages feed material to me.

Best

Adrian

> What about upstream, looks like they might find this patch handy.
> 
> -- ynezz
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [PATCH v2 3/6] base-files: fwtool: implement compatibility check for images

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Bjørn Mork
> Sent: Donnerstag, 16. Juli 2020 10:10
> To: Paul Spooren 
> Cc: Adrian Schmutzler ; openwrt-
> de...@lists.openwrt.org
> Subject: Re: [PATCH v2 3/6] base-files: fwtool: implement compatibility check
> for images
> 
> Paul Spooren  writes:
> 
> >> Major version increment:
> >> This is meant for potential (rare) cases where sysupgrade is not
> >> possible at all, because it would break the device.
> >> In this case, a warning will be printed, and -n won't help.
> >
> > What are those rare cases? I just can't think of anything where not
> > even a clean sysupgrade would be possible. Would it mean to go back to
> > stock firmware and then upgrade a 2.x version? If there isn't a
> > scenario maybe a single integer is easier to handle than a pseudo
> > float.
> 
> Changing partition layout maybe?
> 
> I don't think it's necessary to specify the exact upgrade method for every
> possible device/scenario.  The important part is to prevent semi-bricking and
> issue a warning, which should make the user go look for further upgrade
> instructions.

Indeed, this is not really designed with a precise case in mind already.

The honor for the initial idea of having X.Y versions actually goes to Paweł 
Dembicki:
http://lists.infradead.org/pipermail/openwrt-devel/2020-June/029508.html
He even provided links for the major revision case there.

I picked it up thankfully, as this makes the concept more powerful and general 
without having a real downside.

An easy way of reflashing without sysupgrade for many devices could be e.g. 
TFTP, where you are able to just flash the factory.bin again without caring 
about really going back to vendor firmware.
Of course, what's actually recommended here depends on the situation and will 
be very specific to the devices affected, and one could even provide 
instructions via COMPAT_MESSAGE then (e.g. flash via TFTP).

After all, it may also be possible that we will never need this, but I still 
think it makes sense to put it in place when we are touching this now anyway.

Best

Adrian 


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [PATCH v2 5/6] mvebu: implement compatibility version for DSA migration

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Paul Spooren
> Sent: Donnerstag, 16. Juli 2020 06:18
> To: Adrian Schmutzler ; openwrt-
> de...@lists.openwrt.org
> Subject: Re: [PATCH v2 5/6] mvebu: implement compatibility version for DSA
> migration
> 
> 
> On 14.07.20 04:28, Adrian Schmutzler wrote:
> > This implements the newly introduced compat-version to prevent upgrade
> > between swconfig and DSA for mvebu.
> >
> > Just define a compat version with minor increment and an appropriate
> > message for both image (in Makefile) and device (in base-files).
> >
> > Having taken care of sysupgrade, we can put back the
> SUPPORTED_DEVICES
> > that have been removed in previous patches to prevent broken config.
> >
> > While at it, fix alphabetic sorting in 02_network.
> >
> > Signed-off-by: Adrian Schmutzler 
> >
> > ---
> >
> > Added in v2
> > ---
> >   .../base-files/etc/board.d/02_network | 14 --
> >   target/linux/mvebu/image/cortexa9.mk  | 19
> +++
> >   2 files changed, 27 insertions(+), 6 deletions(-)
> >
> > diff --git
> > a/target/linux/mvebu/cortexa9/base-files/etc/board.d/02_network
> > b/target/linux/mvebu/cortexa9/base-files/etc/board.d/02_network
> > index 9718b332a7..9255f2535e 100755
> > --- a/target/linux/mvebu/cortexa9/base-files/etc/board.d/02_network
> > +++ b/target/linux/mvebu/cortexa9/base-files/etc/board.d/02_network
> > @@ -23,6 +23,7 @@ mvebu_setup_interfaces()
> > linksys,wrt3200acm|\
> > linksys,wrt32x)
> > ucidef_set_interfaces_lan_wan "lan1 lan2 lan3 lan4" "wan"
> > +   ucidef_set_compat_version "1.1"
> > ;;
> > marvell,a385-db-ap)
> > ucidef_set_interfaces_lan_wan "eth0 eth1" "eth2"
> > @@ -30,18 +31,19 @@ mvebu_setup_interfaces()
> > marvell,axp-gp)
> > ucidef_set_interface_lan "eth0 eth1 eth2 eth3"
> > ;;
> > -   solidrun,clearfog-pro-a1)
> > -   # eth0 is standalone ethernet
> > -   # eth1 is switch
> > -   # eth2 is SFP
> > -   ucidef_set_interfaces_lan_wan "lan1 lan2 lan3 lan4 lan5 lan6"
> "eth0 eth2"
> > -   ;;
> > solidrun,clearfog-base-a1)
> > # eth0 is standalone ethernet
> > # eth1 is standalone ethernet
> > # eth2 is SFP
> > ucidef_set_interfaces_lan_wan "eth1" "eth0 eth2"
> > ;;
> > +   solidrun,clearfog-pro-a1)
> > +   # eth0 is standalone ethernet
> > +   # eth1 is switch
> > +   # eth2 is SFP
> > +   ucidef_set_interfaces_lan_wan "lan1 lan2 lan3 lan4 lan5 lan6"
> "eth0 eth2"
> > +   ucidef_set_compat_version "1.1"
> > +   ;;
> > *)
> > ucidef_set_interface_lan "eth0"
> > ;;
> > diff --git a/target/linux/mvebu/image/cortexa9.mk
> > b/target/linux/mvebu/image/cortexa9.mk
> > index 7f0a2fe697..1a4c43d133 100644
> > --- a/target/linux/mvebu/image/cortexa9.mk
> > +++ b/target/linux/mvebu/image/cortexa9.mk
> > @@ -6,6 +6,11 @@
> >   # See /LICENSE for more information.
> >   #
> >
> > +define Device/dsa-migration
> > +  DEVICE_COMPAT_VERSION := 1.1
> > +  DEVICE_COMPAT_MESSAGE := Config cannot be migrated from swconfig
> to
> > +DSA endef
> Shouldn't this be defined in a more central place as it at least impacts two,
> later more targets?

Thanks for having a look and thinking through my patchset.

I thought about this myself and ended up with a clear "No.".

compat-version is not just about DSA, but about incompatible changes to a 
certain device.
Nobody tells you that the first incompatible change, and thus version bump, 
will be due to DSA for all devices.
It may practically be the case that this will be similar for a lot of devices 
when doing DSA migration, but later there might be other bumps for other 
reasons that possibly won't be that global, so I don't want to move that 
definition too far away from the affected devices.

If we really end up with the majority of devices being migrated, and still have 
1.1 for all of them, we might still consider to move this somewhere else.

Best

Adrian

> > +
> >   define Device/buffalo_ls421de
> > $(Device/NAND-128K)
> > DEVICE_VENDOR := Buffalo
> > @@ -63,16 +68,19 @@ endef
> >
> >   define Device/linksys_wrt1200ac
> > $(call Device/linksys)
> > +  $(Device/dsa-migration)
> > DEVICE_MODEL := WRT1200AC
> > DEVICE_ALT0_VENDOR := Linksys
> > DEVICE_ALT0_MODEL := Caiman
> > DEVICE_DTS := armada-385-linksys-caiman
> > DEVICE_PACKAGES += mwlwifi-firmware-88w8864
> > +  SUPPORTED_DEVICES += armada-385-linksys-caiman linksys,caiman
> >   endef
> >   TARGET_DEVICES += linksys_wrt1200ac
> >
> >   define Device/linksys_wrt1900acs
> > $(call Device/linksys)
> > +  $(Device/dsa-migration)
> > DEVICE_MODEL := WRT1900ACS
> > DEVICE_VARIANT := v1
> > DEVICE_ALT0_VENDOR := Linksys
> > @@ -82,11 +90,13 @@ define 

RE: [PATCH v2 4/6] base-files: fwtool: make compat_version backward compatible

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Paul Spooren
> Sent: Donnerstag, 16. Juli 2020 06:16
> To: Adrian Schmutzler ; openwrt-
> de...@lists.openwrt.org
> Subject: Re: [PATCH v2 4/6] base-files: fwtool: make compat_version
> backward compatible
> 
> On 14.07.20 04:28, Adrian Schmutzler wrote:
> 
> > So far, the compatibility mechanism only works if both device and
> > image are already updated to the new routines. This patch extends the
> > sysupgrade metadata and fwtool_check_image() to account for "older"
> > images as well:
> >
> > The basic mechanism for older devices to check for image compatibility
> > is the supported_devices entry. This can be exploited by putting a
> > custom message into this variable of the metadata, so older FW will
> > produce a mismatch and print the message as it thinks it's the list of
> > supported devices. So, we have two cases:
> >
> > device 1.0, image 1.0:
> >The metadata will just contain supported_devices as before.
> >
> > device 1.0, image 1.1:
> >The metadata will contain:
> >
> >"new_supported_devices":["device_string1", "device_string2", ...],
> >"supported_devices":["Upgrade incompatible. Please check Wiki ..."]
> 
> Does that mean starting from 1.1 all sysupgrade images will carry a
> informative only "supported_device" array until the end of time?

Yes. That's the only way I could think of to make this "backwards-compatible".
I just don't think it will hurt much, except for aesthetic reasons.

> This is maybe a bit of a big request but as there will be 19.07.4 release
> without DSA, couldn't some firmware migration patches be added there and
> anyone trying to upgrade from 19.07.x will receive a message like "Please
> upgrade to 19.07.4 before installing 20.x"? Maybe it's not feasible, but as

Despite, that I generally don't like the "update-to-X-first approach", I don't 
see how we will gain anything there for user before 19.07.4?
How would they receive the message then?

> ideally all (correct?) devices move to DSA, we will have compat 1.1
> everywhere and `supported_devices` is useless.

Generally yes, we have some devices that maybe won't be touched; but this 
change isn't really limited to DSA.
We just don't have any mechanism to prevent sysupgrade with kept config so far, 
and therefore I tried to implement this as general as possible.
Just think of the eth0/eth1 swap for ar71xx->ath79 without migration - that 
would be another example where we could have used such a mechanism if we 
already had it back then.
Maybe some devices will be at 1.3 in five years, as we introduce other 
incompatible changes.

It's just that so far we have nothing to treat incompatible changes, and I've 
been missing a comparable feature quite frequently already.

We just have to start at some point, and abusing supported_devices for 
backwards compatibility here seems to be the least painful way, as it won't 
hurt us practically, but just be a little bit ugly after all.

> 
> >If the device is "legacy", i.e. does not have the updated fwtool.sh,
> >it will just fail with image check and print the content of
> >supported_devices. Upgrade can still be performed with -F like when
> >SUPPORTED_DEVICES has been removed to prevent bricking.
> >
> >If the device has updated fwtool.sh (but is 1.0), it will just use
> >the new_supported_devices instead, and work as intended (flashing
> >with -n will work, flashing without will print the appropriate
> >warning).
> >
> > This mechanism should provide a fair tradeoff between simplicity and
> > functionality.
> >
> > Signed-off-by: Adrian Schmutzler 
> >
> > ---
> >
> > Changes in v2:
> > - Add DEVICE_COMPAT_MESSAGE and reword comment for legacy
> warning.
> > ---
> >   include/image-commands.mk  | 5 -
> >   package/base-files/files/lib/upgrade/fwtool.sh | 7 ++-
> >   2 files changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/image-commands.mk b/include/image-commands.mk
> > index 9da712e733..e21472a659 100644
> > --- a/include/image-commands.mk
> > +++ b/include/image-commands.mk
> > @@ -393,7 +393,10 @@ metadata_json = \
> > "metadata_version": "1.0", \
> By replacing the meaning of `supported_devices` to
> `new_supported_devices` we should also modify `metadata_version`.

Fair point. I have to check where it's actually used.

Best

Adrian

> > "compat_version": "$(call json_quote,$(compat_version))", \
> > $(if $(DEVICE_COMPAT_MESSAGE),"compat_message":
> "$(call json_quote,$(DEVICE_COMPAT_MESSAGE))"$(comma)) \
> > -   "supported_devices":[$(call
> metadata_devices,$(SUPPORTED_DEVICES))], \
> > +   $(if $(filter-out
> 1.0,$(compat_version)),"new_supported_devices":[$(call
> metadata_devices,$(SUPPORTED_DEVICES))]$(comma)) \
> > +   $(if $(filter-out 1.0,$(compat_version)),"supported_devices":
> \
> > +

RE: [OpenWrt-Devel] Targets without 5.4 support yet

[mail]

> > At least for the 4.14 targets, I expect them to be archived if there is no
> update until after the next release (or at the latest after the one following 
> it).
> >
> I'm working on bringing pistachio up to 5.4, apart from the spi-nand (which is
> quite a core item obviously, so I thought about reaching out to Boris for some
> guidance) it's looking good so far. If anyone's interested in helping, I'll 
> share
> what I have. Also, if there is no one else interested in cns3xxx, I'm happy to
> take a look at that, I've got two devboards in the shed for that.

Any success with pistachio and 5.4?


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Jo-Philipp Wich
> Sent: Mittwoch, 15. Juli 2020 14:19
> To: m...@adrianschmutzler.de; openwrt-devel@lists.openwrt.org
> Subject: Re: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA
> VLAN filter rules
> 
> Hi,
> 
> > I'm not sure whether using an asterisk is wise here, as it might pose
> > interesting problems when people use scripts to set/evaluate uci
> > config (as you have to be extra careful to not have it treated as a
> > wildcard.) I'd be happy if we could find another symbol here.
> 
> hm, can you elaborate on the problem here? Scripts which use uci values
> verbatim without quoting are prone to any kind of shell injection flaws, not
> sure if papering over such deficiencies is the way to go here.

I'm not having a specific case in mind; and of course you are right about 
unquoted values.
However, I just tend to not use certain special characters as a symbol without 
need as there always will be a case where "problems" show up later. For 
example, one might create interesting effects when using sed on uci config 
values (same would be true for the dot in swconfig at the moment, I admit).

Of course, this is just for consideration, I won't insist on it if you think 
the asterisk is a superior solution here.

Best

Adrian

> 
> ~ Jo


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules

[mail]

> - For denoting pvid I used a trailing asterisk, like the old roboswitch config

I'm not sure whether using an asterisk is wise here, as it might pose 
interesting problems when people use scripts to set/evaluate uci config (as you 
have to be extra careful to not have it treated as a wildcard.)
I'd be happy if we could find another symbol here.

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: Re: [OpenWrt-Devel] [PATCH v6] ramips: add support for JS76x8 series DEV boards

[mail]

> 2.About "missing reg property".
> Adrian Schmutzler wrote a letter to me about that, then I tested as he said, 
> it was ok. Here is the letter from him.

@Petr: The reg property is in the DTS files, while everything else is in the 
DTSI. It's also a case of DRY :-)

> 5.About "Be DRY, use some common Device and just change IMAGE_SIZE and 
> DEVICE_VARIANT".
> Here are three real type of boards by my hand, each has different flash, I 
> don't think it's good way to change board types by modifying the DTS file, 
> it's better to do that by selecting in menuconfig.

@Robinson Wu: That's a misunderstanding from your side. What Petr meant was 
just to rearrange the definitions inside mt76x8.mk like this, so you define a 
common blueprint and then use that for the actual device definitions (note that 
MTK_SOC is not required anymore, as it's defined globally at the top of the 
file):

+define Device/jotale_js76x8
+  DEVICE_VENDOR := Jotale
+  DEVICE_MODEL := JS76x8
+  DEVICE_PACKAGES := kmod-usb2 kmod-usb-ohci
+endef

+define Device/jotale_js76x8-16m
+  $(Device/jotale_js76x8)
+  IMAGE_SIZE := 16064k
+  DEVICE_VARIANT := 16M
+endef
+TARGET_DEVICES += jotale_js76x8-16m

and so on for the other two devices.

I just didn't request that as I personally prefer individual statement if it's 
"just" three lines for the common definition.

Apart from that, please note these additional comments:

7. In master, gpio setup has changed, so you only have one  now. So you 
will need to convert e.g.
< 5 GPIO_ACTIVE_LOW>;
to
< 37 GPIO_ACTIVE_LOW>;

8. pinctrl property rename:
Convert
+   ralink,group = "p1led_an";
+   ralink,function = "p1led_an";
to
+   groups = "p1led_an";
+   ralink,function = "p1led_an";

Sorry for not having taken care earlier, but I can review only 80 % of your PR, 
and that's just not enough to merge it.

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [PATCH] build: put DT "compatible" value as "board_name" in profiles.json

[mail]

Hi,

> -Original Message-
> From: Paul Spooren [mailto:m...@aparcar.org]
> Sent: Montag, 13. Juli 2020 11:46
> To: m...@adrianschmutzler.de; 'Rafał Miłecki' ;
> openwrt-devel@lists.openwrt.org
> Cc: 'Rafał Miłecki' ; 'Petr Štetiar' ; 
> 'Moritz
> Warning' 
> Subject: Re: [PATCH] build: put DT "compatible" value as "board_name" in
> profiles.json
> 
> 
> On 10.07.20 04:23, m...@adrianschmutzler.de wrote:
> >> -Original Message-
> >> From: openwrt-devel [mailto:openwrt-devel-
> boun...@lists.openwrt.org]
> >> On Behalf Of Rafal Milecki
> >> Sent: Mittwoch, 8. Juli 2020 17:10
> >> To: openwrt-devel@lists.openwrt.org
> >> Cc: Rafał Miłecki ; Adrian Schmutzler
> >> ; Petr Štetiar ; Moritz
> >> Warning ; Paul Spooren 
> >> Subject: [PATCH] build: put DT "compatible" value as "board_name" in
> >> profiles.json
> >>
> >> From: Rafał Miłecki 
> >>
> >> The purpose of "board_name" in JSON is matchine OpenWrt running
> >> device with JSON profile entry. Right now it gets filled for devices using
> DT.
> >> Other targets will require custom solutions or just speciyfing that
> >> value manually.
> >>
> >> Signed-off-by: Rafał Miłecki 
> >> ---
> >>   include/image.mk   |  3 +++
> >>   scripts/json_add_image_info.py | 19 +++
> >>   2 files changed, 22 insertions(+)
> >>
> >> diff --git a/include/image.mk b/include/image.mk index
> >> 15f4fe9d3b..b33c1032f8 100644
> >> --- a/include/image.mk
> >> +++ b/include/image.mk
> >> @@ -532,10 +532,13 @@ define Device/Build/image
> >>@mkdir -p $$(shell dirname $$@)
> >>DEVICE_ID="$(DEVICE_NAME)" \
> >>BIN_DIR="$(BIN_DIR)" \
> >> +  LINUX_DIR="$(LINUX_DIR)" \
> >> +  KDIR="$(KDIR)" \
> >>IMAGE_NAME="$(IMAGE_NAME)" \
> >>IMAGE_TYPE=$(word 1,$(subst ., ,$(2))) \
> >>IMAGE_PREFIX="$(IMAGE_PREFIX)" \
> >>DEVICE_TITLE="$(DEVICE_TITLE)" \
> >> +  DEVICE_DTS="$(DEVICE_DTS)" \
> >>TARGET="$(BOARD)" \
> >>SUBTARGET="$(if $(SUBTARGET),$(SUBTARGET),generic)" \
> >>VERSION_NUMBER="$(VERSION_NUMBER)" \ diff --git
> >> a/scripts/json_add_image_info.py b/scripts/json_add_image_info.py
> >> index b4d2dd8d71..5df4bf2a2a 100755
> >> --- a/scripts/json_add_image_info.py
> >> +++ b/scripts/json_add_image_info.py
> >> @@ -5,6 +5,8 @@ from pathlib import Path  from sys import argv
> >> import hashlib  import json
> >> +import re
> >> +import subprocess
> >>
> >>   if len(argv) != 2:
> >>   print("ERROR: JSON info script requires output arg") @@ -22,6
> >> +24,20 @@ if not image_file.is_file():
> >>   def get_titles():
> >>   return [{"title": getenv("DEVICE_TITLE")}]
> >>
> >> +def get_board_name():
> >> +device_dts = getenv("DEVICE_DTS")
> >> +if device_dts is not None:
> >> +dtc = getenv("LINUX_DIR") + "/scripts/dtc/dtc"
> >> +dtb_file = getenv("KDIR") + "/image-" + device_dts + ".dtb"
> >> +dts = subprocess.run([dtc, "-q", "-I", "dtb", "-O", "dts",
> >> +"-o", "-",
> >> dtb_file], capture_output=True, text=True)
> >> +if dts.returncode != 0:
> >> +return None
> >> +match = re.search("compatible = \"([^\"]*)", dts.stdout)
> >> +if match is None:
> >> +return None
> >> +return match[1]
> >> +return None
> >> +
> >>
> >>   device_id = getenv("DEVICE_ID")
> >>   image_hash = hashlib.sha256(image_file.read_bytes()).hexdigest()
> >> @@ -46,5 +62,8 @@ image_info = {
> >>   }
> >>   },
> >>   }
> >> +board_name = get_board_name()
> >> +if board_name is not None:
> >> +image_info["profiles"][device_id]["board_name"] = board_name
> > Hi,
> >
> > coming back to the initial subject of your patch:
> >
> > As stated earlier in the discussion (I think), we have
> "SUPPORTED_DEVICES" on many devices that will essentially give us the
> board name.
> > So, one could say, the first entry of SUPPORTED_DEVICES just happens to
> be the board name (as that one is designed to match the current compatible
> ...).
> >
> > So, instead of establishing another mechanism to retrieve the board name
> in this patch (which might have several special cases etc.), I'd vote for just
> providing SUPPORTED_DEVICES for the remaining devices, even if it's not
> required for the upgrade mechanism itself.
> I'm also in favor for using the first entry of SUPPORTED_DEVICES.
> > This would allow us to benefit from what's set up already, and would allow
> to make target-specific solutions for the remaining cases (in some cases it
> might be just a one-liner in Device/Default).
> 
> I guess the only way which doesn't require per image root filesystems is to
> use a file like Adrian mentioned before[0] which ideally uses the very same
> schema as DT does (vendor_model).
> 
> [0]:
> https://github.com/openwrt/openwrt/blob/openwrt-
> 19.07/target/linux/ramips/base-files/lib/ramips.sh

Just to state that explicitly: That's a lot of work, and not something you 
quickly put together in one hour.

> 
> Adrian/Rafal do you have an overview which targets 

RE: [OpenWrt-Devel] [PATCH] ramips: add support for netgear r6020

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Evan Jobling
> Sent: Freitag, 5. Juni 2020 08:28
> To: openwrt-devel@lists.openwrt.org
> Cc: yn...@true.cz; m...@adrianschmutzler.de
> Subject: [OpenWrt-Devel] [PATCH] ramips: add support for netgear r6020

Hi,

in the meantime, this device has been merged (based on somebody else's PR):

https://github.com/openwrt/openwrt/commit/edbc8e5512dccc2e0b6925258e34b3f21d66679c

Best

Adrian

> 
> Hi,
> 
> It seems that the older patches got put into patchwork, and assigned to Petr
> Štetiar?
> Apologies for the mess I created.
> I tried to put those patches to superseded?
> 
> Responses to feedback on my original patches, as well as the patch at the
> end.
> Additional feedback and requests for changes/tests welcome.
> 
> >Typically, frequency can be raised with substantial gains in read speed.
> 
> I can increase if required.
> Not sure how fast is reasonable/required?
> 
> At this stage I would rather not set up an oscilloscope to experiment with
> how fast I can push it?
> 
> Datasheet of flash ic is 80MHz or so?
> Not sure how fast the mt7628an can go?
> 
> >> mtd-mac-address = < 0x100b0>;
> >
> >Are these necessary, or will the address be correct if you just drop them?
> 
> It appears I need this line for the ethernet, otherwise random mac address is
> created.
> 
> >
> >Despite, can you please check whether there are addresses in factory 0x28,
> 0x2e, 0xe000, 0xe006, 0x4, 0x8004?
> >
> >Which addresses are assigned on OEM firmware (lan, wan, 2g, 5g)?
> 
> You would like me to flash the OEM firmware, look at MAC addresses?
> All the devices I have on hand are flashed to openwrt.
> I can flash latest factory firmware?
> 
> I have it set up to be same mac address on wired and wlan.
> It is the same one that is written on the device sticker.
> The bootloader uses that mac address on the lan hardware.
> 
> >> ucidef_set_led_wlan "wlan2g" "WiFi 2.4GHz"
> "$boardname:green:wlan2g" "phy0tpt"
> >
> >Please use a DTS trigger instead (for both 2g and 5g).
> 
> I don't understand.  R6120 lines look similar?
> Do I need to remove the 2g/5g lines?
> I tried to search for some documentation. I found [1], [2] ?
> 
> >The old PR has been closed quite some time ago due to inactivity. If there is
> new progress now, it would be fine to just open a new PR by the "new
> author".
> 
> Is patch via email acceptable?
> Alternatively,
> I would need to create github account, and do pull request there?
> 
> I'm assuming keeping the same thread at this stage is the best way forward?
> I understand the subject should have been something like
> "Subject: [PATCH] ramips: add support for netgear r6020"
> 
> Cheers,
> Evan.
> 
> [1] https://openwrt.org/docs/guide-user/base-system/led_configuration
> [2]
> https://www.kernel.org/doc/Documentation/devicetree/bindings/leds/leds
> -gpio.txt
> 
> From 8a2cf974be374612e8ea32d2182226d542ebbcdf Mon Sep 17 00:00:00
> 2001
> From: Evan Jobling 
> Date: Sat, 30 May 2020 20:39:47 +1000
> Subject: [PATCH] ramips: add support for netgear r6020
> 
> Signed-off-by: Evan Jobling 
> ---
>  .../ramips/dts/mt7628an_netgear_r6020.dts | 144 ++
>  target/linux/ramips/image/mt76x8.mk   |  24 +++
>  .../mt76x8/base-files/etc/board.d/01_leds |   5 +
>  .../mt76x8/base-files/etc/board.d/02_network  |   1 +
>  4 files changed, 174 insertions(+)
>  create mode 100644 target/linux/ramips/dts/mt7628an_netgear_r6020.dts
> 
> diff --git a/target/linux/ramips/dts/mt7628an_netgear_r6020.dts
> b/target/linux/ramips/dts/mt7628an_netgear_r6020.dts
> new file mode 100644
> index 00..717fdde3fa
> --- /dev/null
> +++ b/target/linux/ramips/dts/mt7628an_netgear_r6020.dts
> @@ -0,0 +1,144 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT /dts-v1/;
> +
> +#include "mt7628an.dtsi"
> +
> +#include 
> +#include 
> +
> +/ {
> +   compatible = "netgear,r6020", "mediatek,mt7628an-soc";
> +   model = "Netgear  R6020 (AC750)";
> +
> +   aliases {
> +   led-boot = _power;
> +   led-failsafe = _power;
> +   led-running = _power;
> +   led-upgrade = _power;
> +   };
> +
> +   keys {
> +   compatible = "gpio-keys";
> +
> +   reset {
> +   label = "reset";
> +   gpios = < 6 GPIO_ACTIVE_LOW>;
> +   linux,code = ;
> +   };
> +   };
> +
> +   leds {
> +   compatible = "gpio-leds";
> +
> +   lan {
> +   label = "r6020:green:lan";
> +   gpios = < 12 GPIO_ACTIVE_LOW>;
> +   };
> +
> +   led_power: power {
> +   label = "r6020:green:power";
> +   gpios = < 11 GPIO_ACTIVE_LOW>;
> +   };
> +
> +   wlan {
> +   label = "r6020:green:wlan2g";
> +   

RE: [OpenWrt-Devel] [PATCH] .gitignore: ignore all .config* files

[mail]

Hi,

since nobody else took care so far:

In my opinion, this does not solve a problem with OpenWrt, but with your 
particular use case.

However, we cannot cover each individual use case in our default settings.
Despite, it would be relatively easy to either keep that change locally or just 
not add the relevant files when doing a commit.

(Personally, I have 10+ files in my OpenWrt root I just never touch when 
working with git.)

So, I'm marking this a Rejected.

I hope you don't feel repelled and continue to contribute to the project.

Best

Adrian

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Catrinel Catrinescu
> Sent: Dienstag, 10. März 2020 13:33
> To: Adrian Schmutzler ; openwrt-
> de...@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] [PATCH] .gitignore: ignore all .config* files
> 
> Hi Adrian
> 
> After successful testing, I always save the .config files, attaching the 
> revision
> number, like .config_r12345.
> 
> And it is a cosmetic replacement too.
> 
> 
> Thanks
> Catrinel
> 
> 
> -Original Message-
> From: Adrian Schmutzler 
> Sent: Tuesday, 10 March 2020 13:26
> To: Catrinel Catrinescu ; openwrt-devel@lists.openwrt.org
> Subject: RE: [OpenWrt-Devel] [PATCH] .gitignore: ignore all .config* files
> 
> > -Original Message-
> > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> > On Behalf Of c...@80211.de
> > Sent: Dienstag, 10. März 2020 13:02
> > To: openwrt-devel@lists.openwrt.org
> > Cc: Catrinel Catrinescu 
> > Subject: [OpenWrt-Devel] [PATCH] .gitignore: ignore all .config* files
> 
> Why is this necessary (-> commit message)?
> 
> Or is it just a cosmetic replacement of two lines by one? (In that case, I'd
> prefer the specific lines).
> 
> Best
> 
> Adrian
> 
> >
> > From: Catrinel Catrinescu 
> >
> > Signed-off-by: Catrinel Catrinescu 
> > ---
> >  .gitignore | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/.gitignore b/.gitignore
> > index 6549af83be..edffba9c05 100644
> > --- a/.gitignore
> > +++ b/.gitignore
> > @@ -3,8 +3,7 @@
> >  .*.swp
> >  /env
> >  /dl
> > -/.config
> > -/.config.old
> > +/.config*
> >  /bin
> >  /build_dir
> >  /staging_dir
> > --
> > 2.17.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


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [PATCH v2] mvebu: add support for MACCHIATObin Single Shot

[mail]

> From: Alexandra Alth [mailto:alexan...@alth.de] 
> Sent: Samstag, 11. Juli 2020 15:31
> To: Tomasz Maciej Nowak 
> Cc: m...@adrianschmutzler.de; openwrt-devel@lists.openwrt.org
> Subject: Re: [PATCH v2] mvebu: add support for MACCHIATObin Single Shot
>
> I can confirm that the provided image from TMN is working on my Singleshot 
> right out of the box.

So, can we add

Tested-by: Alexandra Alth 

to the patch?

Despite, this is essentially adding support for a "new" device, so I would be 
happy if one of you could add specifications and (updated) flashing 
instructions either here or as part of a v3.

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

arc770 and ath25 bump marked as deferred

[mail]

Hi,

since nobody seemed to be interested in continuing, I just marked my kernel 
bump patches for arc770 (RFT) and ath25 (broken) as deferred, so they don't 
crowd patchwork any longer.

https://patchwork.ozlabs.org/project/openwrt/patch/20200413103352.7429-1-freif...@adrianschmutzler.de/

https://patchwork.ozlabs.org/project/openwrt/list/?series=169991=*

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [PATCH v2] ath79: add support for gl-e750

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Luochongjun
> Sent: Samstag, 11. Juli 2020 10:59
> To: openwrt-devel@lists.openwrt.org
> Cc: Luochongjun 
> Subject: [PATCH v2] ath79: add support for gl-e750
> 
> The gl-e750 is a portable travel router that gives you safe access to the
> internet while traveling.
> 
> Specifications:
> - SoC: Qualcomm Atheros AR9531 (650MHz)
> - RAM: 128 MB DDR2
> - Flash: 16 MB SPI NOR (W25Q128FVSG) + 128 MB SPI NAND
> (GD5F1GQ4UFYIG)
> - Ethernet: 10/100: 1xLAN
> - Wireless: QCA9531 2.4GHz (bgn) + QCA9887 5GHz (ac)
> - USB: 1x USB 2.0 port
> - Switch: 1x switch
> - Button: 1x reset button
> - OLED Screen: 128*64 px
> 
> MAC addresses based on vendor firmware:
> LAN *:a0 art 0x0
> 2.4GHz *:a1 art 0x1002
> 5GHz *:a2 art calculated from art 0x0 + 2
> 
> Flash firmware:
> Since openwrt's kernel already exceeds 2MB, upgrading from the official
> version of GL-inet (v3.100) using the sysupgrade command will break the
> kernel image. Users who are using version 3.100 can only upgrade via uboot.
> The official guidance for GL-inet is as follows:
> https://docs.gl-inet.com/en/3/troubleshooting/debrick/
> 
> In the future, GL-inet will modify the firmware to support the sysupgrade
> command, so users will be able to upgrade directly with the sysupgrade
> command in future releases.
> 
> OLED screen control:
> OLED controller is connected to QCA9531 through serial port, and can send
> instructions to OLED controller directly through serial port.
> Refer to the links below for a list of supported instructions:
> https://github.com/gl-inet/GL-E750-MCU-instruction

a few nitpicks still below.

> 
> Signed-off-by: Luochongjun 
> ---
>  target/linux/ath79/dts/qca9531_glinet_gl-e750.dts  | 140
> +
>  target/linux/ath79/image/nand.mk   |  18 +++
>  .../ath79/nand/base-files/etc/board.d/02_network   |   3 +
>  .../etc/hotplug.d/ieee80211/10-fix-wifi-mac|   8 ++
>  4 files changed, 169 insertions(+)
>  create mode 100644 target/linux/ath79/dts/qca9531_glinet_gl-e750.dts
> 
> diff --git a/target/linux/ath79/dts/qca9531_glinet_gl-e750.dts
> b/target/linux/ath79/dts/qca9531_glinet_gl-e750.dts
> new file mode 100644
> index 000..aba2087
> --- /dev/null
> +++ b/target/linux/ath79/dts/qca9531_glinet_gl-e750.dts
> @@ -0,0 +1,140 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT /dts-v1/;
> +
> +#include 
> +#include 
> +
> +#include "qca953x.dtsi"
> +
> +/ {
> + compatible = "glinet,gl-e750", "qca,qca9531";
> + model = "GL.iNet GL-E750";
> +
> + aliases {
> + label-mac-device = 
> + };
> +
> + keys {
> + compatible = "gpio-keys";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_disable_pins>;
> +
> + reset {
> + label = "reset";
> + linux,code = ;
> + gpios = < 3 GPIO_ACTIVE_LOW>;
> + };
> +
> + switch {
> + label = "switch";
> + linux,code = ;
> + gpios = < 1 GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> + gpio-export {
> + compatible = "gpio-export";
> + #size-cells = <0>;

I think size-cells can be dropped here, at least this is frequently done.

> +
> + gpio_lte_power {
> + gpio-export,name = "lte_power";
> + gpio-export,output = <1>;
> + gpios = < 0 GPIO_ACTIVE_HIGH>;
> + };
> +  };
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> +_phy {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> + num-cs = <2>;
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <2500>;
> +
> + 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>;
> + };
> +
> + art: partition@5 {
> + label = "art";
> + reg = <0x5 0x1>;
> + read-only;
> + };
> +
> + partition@6 {
> + label = "kernel";
> + reg = <0x6 0x40>;
> + };
> +
> +  

RE: RE: [PATCH] ath79: add support for gl-e750

[mail]

> BTW: Would the following DTS statement work for your device _instead_ of the 
> code in 10-fix-wifi-mac:
> 
>  {
> status = "okay";
> 
> wifi@0,0 {
> compatible = "qcom,ath10k";
> reg = <0x 0 0 0 0>;
> mtd-mac-address = < 0x0>;
> mtd-mac-address-increment = <2>;
> };
> };
> --->I added the above configuration to the DTS file, and the MAC address was 
> not set correctly, so I will keep the current MAC address setting method.

Okay.

> 
> If that's caused by  being enabled in device tree, you can try to put 
> the following in DTS:
>
>  {
> compatible = "syscon", "simple-mfd";
> };
> --->As you said, after I added the above configuration to DTS, the system 
> only generated eth0 and it worked.

Okay, fine.

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [PATCH v2] mvebu: add support for MACCHIATObin Single Shot

[mail]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Tomasz Maciej Nowak
> Sent: Freitag, 10. Juli 2020 19:35
> To: openwrt-devel@lists.openwrt.org
> Cc: Alexandra Alth 
> Subject: [PATCH v2] mvebu: add support for MACCHIATObin Single Shot
> 
> The currently supported Double Shot variant provides dts which is not
> entirely compatible with Single Shot variant. The symptoms are that SFP
> ports are not working. To remedy this, add two images to distinguish both
> boards, wich have proper dtb assigned.
> 
> Reported-by: Alexandra Alth 
> Signed-off-by: Tomasz Maciej Nowak 
> ---
> 
> v1 -> v2
> - Rebase onto "mvebu: fix support for Marvell 8040 MACCHIATOBin".
> - Add missing cases for network, sysupgrade and U-Boot environment
>   location.
> - Fix Double Shot case in U-Boot evironment location.

thanks for updating.

Does the state of your v1 indicate that this is _not_ tested on device?

> 
>  package/boot/uboot-envtools/files/mvebu   |  3 ++-
>  .../base-files/etc/board.d/02_network |  3 ++-
>  .../base-files/lib/upgrade/platform.sh|  9 ++---
>  target/linux/mvebu/image/cortexa72.mk | 20 +--
>  4 files changed, 28 insertions(+), 7 deletions(-)
> 
> diff --git a/package/boot/uboot-envtools/files/mvebu
> b/package/boot/uboot-envtools/files/mvebu
> index 72e2df5d1982..8ed1f87ead46 100644
> --- a/package/boot/uboot-envtools/files/mvebu
> +++ b/package/boot/uboot-envtools/files/mvebu
> @@ -24,7 +24,8 @@ globalscale,espressobin|\  globalscale,espressobin-
> emmc|\  globalscale,espressobin-v7|\  globalscale,espressobin-v7-emmc|\
> -marvell,armada8040-mcbin)
> +marvell,armada8040-mcbin-doubleshot|\
> +marvell,armada8040-mcbin-singleshot)
>   ubootenv_add_uci_config "/dev/mtd0" "0x3f" "0x1"
> "0x1" "1"

Oh, I overlooked that part. I will move the doubleshot change to my patch.

Best

Adrian

>   ;;
>  linksys,wrt1200ac|\
> diff --git a/target/linux/mvebu/cortexa72/base-
> files/etc/board.d/02_network b/target/linux/mvebu/cortexa72/base-
> files/etc/board.d/02_network
> index 32053d74e85f..9ab3c8174d96 100755
> --- a/target/linux/mvebu/cortexa72/base-files/etc/board.d/02_network
> +++ b/target/linux/mvebu/cortexa72/base-files/etc/board.d/02_network
> @@ -11,7 +11,8 @@ board_config_update
>  board=$(board_name)
> 
>  case "$board" in
> -marvell,armada8040-mcbin-doubleshot)
> +marvell,armada8040-mcbin-doubleshot|\
> +marvell,armada8040-mcbin-singleshot)
>   ucidef_set_interfaces_lan_wan "eth0 eth1 eth3" "eth2"
>   ;;
>  marvell,armada8040-db)
> diff --git a/target/linux/mvebu/cortexa72/base-
> files/lib/upgrade/platform.sh b/target/linux/mvebu/cortexa72/base-
> files/lib/upgrade/platform.sh
> index 75d2933f058f..04ea634097a1 100755
> --- a/target/linux/mvebu/cortexa72/base-files/lib/upgrade/platform.sh
> +++ b/target/linux/mvebu/cortexa72/base-files/lib/upgrade/platform.sh
> @@ -9,7 +9,8 @@ REQUIRE_IMAGE_METADATA=1
> 
>  platform_check_image() {
>   case "$(board_name)" in
> - marvell,armada8040-mcbin-doubleshot)
> + marvell,armada8040-mcbin-doubleshot|\
> + marvell,armada8040-mcbin-singleshot)
>   platform_check_image_sdcard "$1"
>   ;;
>   *)
> @@ -20,7 +21,8 @@ platform_check_image() {
> 
>  platform_do_upgrade() {
>   case "$(board_name)" in
> - marvell,armada8040-mcbin-doubleshot)
> + marvell,armada8040-mcbin-doubleshot|\
> + marvell,armada8040-mcbin-singleshot)
>   platform_do_upgrade_sdcard "$1"
>   ;;
>   *)
> @@ -30,7 +32,8 @@ platform_do_upgrade() {  }
>  platform_copy_config() {
>   case "$(board_name)" in
> - marvell,armada8040-mcbin-doubleshot)
> + marvell,armada8040-mcbin-doubleshot|\
> + marvell,armada8040-mcbin-singleshot)
>   platform_copy_config_sdcard
>   ;;
>   esac
> diff --git a/target/linux/mvebu/image/cortexa72.mk
> b/target/linux/mvebu/image/cortexa72.mk
> index 6e52109237cf..1440c07a0b5f 100644
> --- a/target/linux/mvebu/image/cortexa72.mk
> +++ b/target/linux/mvebu/image/cortexa72.mk
> @@ -16,14 +16,30 @@ define Device/marvell_armada8040-db  endef
> TARGET_DEVICES += marvell_armada8040-db
> 
> -define Device/marvell_macchiatobin
> +define Device/marvell_macchiatobin-doubleshot
>$(call Device/Default-arm64)
>DEVICE_VENDOR := SolidRun
>DEVICE_MODEL := MACCHIATObin
> +  DEVICE_VARIANT := Double Shot
>DEVICE_ALT0_VENDOR := SolidRun
>DEVICE_ALT0_MODEL := Armada 8040 Community Board
> +  DEVICE_ALT0_VARIANT := Double Shot
>DEVICE_PACKAGES += kmod-i2c-mux-pca954x
>DEVICE_DTS := armada-8040-mcbin
>SUPPORTED_DEVICES := marvell,armada8040-mcbin-doubleshot
> marvell,armada8040-mcbin  endef -TARGET_DEVICES +=
> marvell_macchiatobin
> +TARGET_DEVICES += marvell_macchiatobin-doubleshot
> +
> +define Device/marvell_macchiatobin-singleshot
> +  $(call Device/Default-arm64)
> +  DEVICE_VENDOR := SolidRun

RE: [PATCH] mvebu: add support for MACCHIATObin Single Shot

[mail]

> -Original Message-
> From: Tomasz Maciej Nowak [mailto:tome...@o2.pl]
> Sent: Freitag, 10. Juli 2020 19:30
> To: m...@adrianschmutzler.de; openwrt-devel@lists.openwrt.org
> Cc: 'Alexandra Alth' 
> Subject: Re: [PATCH] mvebu: add support for MACCHIATObin Single Shot
> 
> Hi.
> 
> W dniu 10.07.2020 o 10:33, m...@adrianschmutzler.de pisze:
> >>> -Original Message-
> >>> From: openwrt-devel [mailto:openwrt-devel-
> boun...@lists.openwrt.org]
> >>> On Behalf Of Tomasz Maciej Nowak
> >>> Sent: Donnerstag, 9. Juli 2020 21:16
> >>> To: openwrt-devel@lists.openwrt.org
> >>> Cc: Alexandra Alth 
> >>> Subject: [PATCH] mvebu: add support for MACCHIATObin Single Shot
> >>>
> >>> The currently supported Double Shot variant provides dts which is
> >>> not entirely compatible with Single Shot variant. The symptoms are
> >>> that SFP ports are not working. To remedy this, add two images to
> >>> distinguish both boards, wich have proper dtb assigned.
> >>>
> >>> Reported-by: Alexandra Alth 
> >>> Signed-off-by: Tomasz Maciej Nowak 
> >>> ---
> >>>   target/linux/mvebu/image/cortexa72.mk | 20 ++--
> >>>   1 file changed, 18 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/target/linux/mvebu/image/cortexa72.mk
> >>> b/target/linux/mvebu/image/cortexa72.mk
> >>> index 50233540ed2e..cab2ffcaa251 100644
> >>> --- a/target/linux/mvebu/image/cortexa72.mk
> >>> +++ b/target/linux/mvebu/image/cortexa72.mk
> >>> @@ -16,14 +16,30 @@ define Device/marvell_armada8040-db  endef
> >>> TARGET_DEVICES += marvell_armada8040-db
> >>>
> >>> -define Device/marvell_macchiatobin
> >>> +define Device/marvell_macchiatobin-doubleshot
> >>>     $(call Device/Default-arm64)
> >>>     DEVICE_VENDOR := SolidRun
> >>>     DEVICE_MODEL := MACCHIATObin
> >>> +  DEVICE_VARIANT := Double Shot
> >>>     DEVICE_ALT0_VENDOR := SolidRun
> >>>     DEVICE_ALT0_MODEL := Armada 8040 Community Board
> >>> +  DEVICE_ALT0_VARIANT := Double Shot
> >>>     DEVICE_PACKAGES += kmod-i2c-mux-pca954x
> >>>     DEVICE_DTS := armada-8040-mcbin
> >>>     SUPPORTED_DEVICES := marvell,armada8040-mcbin  endef -
> >>> TARGET_DEVICES += marvell_macchiatobin
> >>> +TARGET_DEVICES += marvell_macchiatobin-doubleshot
> >>> +
> >>> +define Device/marvell_macchiatobin-singleshot
> >>> +  $(call Device/Default-arm64)
> >>> +  DEVICE_VENDOR := SolidRun
> >>> +  DEVICE_MODEL := MACCHIATObin
> >>> +  DEVICE_VARIANT := Single Shot
> >>> +  DEVICE_ALT0_VENDOR := SolidRun
> >>> +  DEVICE_ALT0_MODEL := Armada 8040 Community Board
> >>> +  DEVICE_ALT0_VARIANT := Single Shot
> >>> +  DEVICE_PACKAGES += kmod-i2c-mux-pca954x
> >>> +  DEVICE_DTS := armada-8040-mcbin-singleshot
> >>> +  SUPPORTED_DEVICES := marvell,armada8040-mcbin-singleshot
> >>> +endef
> >>> +TARGET_DEVICES += marvell_macchiatobin-singleshot
> >> Kernel tells me that the compatible for these devices is
> >> marvell,armada8040-mcbin-doubleshot
> >> and
> >> marvell,armada8040-mcbin-singleshot
> >> However, we seem to implement something different:
> >> adsc@buildfff:/data/openwrt$ grep -rn "mcbin" target/linux/mvebu/ |
> >> sort
> >> target/linux/mvebu/cortexa72/base-
> files/etc/board.d/02_network:14:mar
> >> vell,armada8040-mcbin)
> >> target/linux/mvebu/cortexa72/base-files/lib/upgrade/platform.sh:12:
> >> marvell,armada8040-mcbin)
> >> target/linux/mvebu/cortexa72/base-files/lib/upgrade/platform.sh:23:
> >> marvell,armada8040-mcbin)
> >> target/linux/mvebu/cortexa72/base-files/lib/upgrade/platform.sh:33:
> >> marvell,armada8040-mcbin)
> >> target/linux/mvebu/image/cortexa72.mk:26:  DEVICE_DTS :=
> >> armada-8040-mcbin
> >> target/linux/mvebu/image/cortexa72.mk:27:  SUPPORTED_DEVICES :=
> >> marvell,armada8040-mcbin So, ...
> >> 1. is the current setup broken for the doubleshot already?
> >> 2. If yes, the relevant sections seem to be updated for the singleshot as
> well ...
> >> Best
> >> Adrian
> >
> > Had a look at the kernel and actually option 1 is true, they added a new
> primary compatible for the doubleshot when introducing the singleshot.
> 
> Indeed, I have overlooked that change.
> 
> >
> > I sent a patch for that already a minute ago, just fixing doubleshot with 
> > the
> current implementation.
> 
> I'll base v2 on Your patch.

Thanks for your feedback. You might speed things up by providing Reviewed-by 
and/or Tested-by for my other patch. :-)

Best

Adrian

> 
> >
> > Consequently, your patch should be updated to also provide the correct
> board name for singleshot in 02_network and platform.sh.
> 
> Yeah, I was really narrow sighted to provide the image, that forgot to add
> those.
> 
> >
> > Despite, I cannot judge how the SFP port will affect network config with
> respect to 02_network.
> 
> It seems that the setup is correct for both boards and in Double Shot variant
> one uses SFP cages or 10 Gb copper ports.
> 
> >
> > Best
> >
> > Adrian
> >
> 
> Regards
> 
> --
> TMN


openpgp-digital-signature.asc
Description: PGP signature

RE: [PATCH] build: put DT "compatible" value as "board_name" in profiles.json

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Rafal Milecki
> Sent: Mittwoch, 8. Juli 2020 17:10
> To: openwrt-devel@lists.openwrt.org
> Cc: Rafał Miłecki ; Adrian Schmutzler
> ; Petr Štetiar ; Moritz
> Warning ; Paul Spooren 
> Subject: [PATCH] build: put DT "compatible" value as "board_name" in
> profiles.json
> 
> From: Rafał Miłecki 
> 
> The purpose of "board_name" in JSON is matchine OpenWrt running device
> with JSON profile entry. Right now it gets filled for devices using DT.
> Other targets will require custom solutions or just speciyfing that value
> manually.
> 
> Signed-off-by: Rafał Miłecki 
> ---
>  include/image.mk   |  3 +++
>  scripts/json_add_image_info.py | 19 +++
>  2 files changed, 22 insertions(+)
> 
> diff --git a/include/image.mk b/include/image.mk index
> 15f4fe9d3b..b33c1032f8 100644
> --- a/include/image.mk
> +++ b/include/image.mk
> @@ -532,10 +532,13 @@ define Device/Build/image
>   @mkdir -p $$(shell dirname $$@)
>   DEVICE_ID="$(DEVICE_NAME)" \
>   BIN_DIR="$(BIN_DIR)" \
> + LINUX_DIR="$(LINUX_DIR)" \
> + KDIR="$(KDIR)" \
>   IMAGE_NAME="$(IMAGE_NAME)" \
>   IMAGE_TYPE=$(word 1,$(subst ., ,$(2))) \
>   IMAGE_PREFIX="$(IMAGE_PREFIX)" \
>   DEVICE_TITLE="$(DEVICE_TITLE)" \
> + DEVICE_DTS="$(DEVICE_DTS)" \
>   TARGET="$(BOARD)" \
>   SUBTARGET="$(if $(SUBTARGET),$(SUBTARGET),generic)" \
>   VERSION_NUMBER="$(VERSION_NUMBER)" \
> diff --git a/scripts/json_add_image_info.py
> b/scripts/json_add_image_info.py index b4d2dd8d71..5df4bf2a2a 100755
> --- a/scripts/json_add_image_info.py
> +++ b/scripts/json_add_image_info.py
> @@ -5,6 +5,8 @@ from pathlib import Path  from sys import argv  import
> hashlib  import json
> +import re
> +import subprocess
> 
>  if len(argv) != 2:
>  print("ERROR: JSON info script requires output arg") @@ -22,6 +24,20 @@
> if not image_file.is_file():
>  def get_titles():
>  return [{"title": getenv("DEVICE_TITLE")}]
> 
> +def get_board_name():
> +device_dts = getenv("DEVICE_DTS")
> +if device_dts is not None:
> +dtc = getenv("LINUX_DIR") + "/scripts/dtc/dtc"
> +dtb_file = getenv("KDIR") + "/image-" + device_dts + ".dtb"
> +dts = subprocess.run([dtc, "-q", "-I", "dtb", "-O", "dts", "-o", "-",
> dtb_file], capture_output=True, text=True)
> +if dts.returncode != 0:
> +return None
> +match = re.search("compatible = \"([^\"]*)", dts.stdout)
> +if match is None:
> +return None
> +return match[1]
> +return None
> +
> 
>  device_id = getenv("DEVICE_ID")
>  image_hash = hashlib.sha256(image_file.read_bytes()).hexdigest()
> @@ -46,5 +62,8 @@ image_info = {
>  }
>  },
>  }
> +board_name = get_board_name()
> +if board_name is not None:
> +image_info["profiles"][device_id]["board_name"] = board_name

Hi,

coming back to the initial subject of your patch:

As stated earlier in the discussion (I think), we have "SUPPORTED_DEVICES" on 
many devices that will essentially give us the board name.
So, one could say, the first entry of SUPPORTED_DEVICES just happens to be the 
board name (as that one is designed to match the current compatible ...).

So, instead of establishing another mechanism to retrieve the board name in 
this patch (which might have several special cases etc.), I'd vote for just 
providing SUPPORTED_DEVICES for the remaining devices, even if it's not 
required for the upgrade mechanism itself.
This would allow us to benefit from what's set up already, and would allow to 
make target-specific solutions for the remaining cases (in some cases it might 
be just a one-liner in Device/Default).

Best

Adrian

> 
>  json_path.write_text(json.dumps(image_info, separators=(",", ":")))
> --
> 2.26.1
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [PATCH] build: put DT "compatible" value as "board_name" in profiles.json

[mail]

> -Original Message-
> From: Rafał Miłecki [mailto:zaj...@gmail.com]
> Sent: Mittwoch, 8. Juli 2020 23:40
> To: m...@adrianschmutzler.de; 'Paul Spooren' ; openwrt-
> de...@lists.openwrt.org
> Cc: 'Rafał Miłecki' ; 'Adrian Schmutzler'
> ; 'Petr Štetiar' ; 'Moritz
> Warning' ; 'Daniel Golle' 
> Subject: Re: [PATCH] build: put DT "compatible" value as "board_name" in
> profiles.json
> 
> On 08.07.2020 21:41, m...@adrianschmutzler.de wrote:
> >> -Original Message-
> >> From: Paul Spooren [mailto:m...@aparcar.org]
> >> Sent: Mittwoch, 8. Juli 2020 21:34
> >> To: Rafał Miłecki ; openwrt-devel@lists.openwrt.org
> >> Cc: Rafał Miłecki ; Adrian Schmutzler
> >> ; Petr Štetiar ; Moritz
> >> Warning ; Daniel Golle
> 
> >> Subject: Re: [PATCH] build: put DT "compatible" value as "board_name"
> >> in profiles.json
> >>
> >> I think the question is therefore more on how to deal with devices
> >> that do not use DT? If we use a per device rootfs a line could be
> >> added to /etc/os- release containing something like
> >> OPENWRT_PROFILE="SpEcIaL-CaSEv100",
> >> which is then shown via `ubus call system borad`.
> >
> > Well, one could just use something like this, which we had before the
> compatible was used:
> >
> > https://github.com/openwrt/openwrt/blob/openwrt-
> 19.07/target/linux/ram
> > ips/base-files/lib/ramips.sh
> 
> That's exactly what I was thinking about. That file does:
> echo "$name" > /tmp/sysinfo/board_name
> which means device-specific identifier will appear as $(board_name)
> 
> 
> > There, one could just use the "profile names" instead, with "_" replaced by
> "," for the few non-DT targets.
> > However, this assumes a 1-to-1 relation between boards and profiles, and
> I'm not sure whether that always exists.
> > And somebody would have to create that by hand.
> 
> Right. That list should be easy to verify by looking at Makefile and 
> platform.sh
> / ramips.sh.
> 
> 
> > But I somehow lost track what's the ultimate goal of the proposed changes
> here, so maybe I'm not going into the right direction with this.
> 
> I described it shortly in commit message as:
> 
>  > The purpose of "board_name" in JSON is matchine OpenWrt running
> device  > with JSON profile entry.
> 
> More details: we are working on firmware updating apps that find device
> appropriate firmware automatically. See luci-app-attendedsysupgrade for
> example.
> 
> We need a way for such apps to:
> 1. Get device identifier (like $(board_name)) 2. Easily find matching firmware
> in profiles.json using above identifier

I just had a look into bcm47xx.

Is my observation correct that, at least for mips74k subtarget, there also are 
multiple profiles for the same board, e.g.

define Device/netgear-wnr3500l-v2
  DEVICE_MODEL := WNR3500L
  DEVICE_VARIANT := v2
  DEVICE_PACKAGES := $(USB2_PACKAGES)
  $(Device/netgear)
  NETGEAR_BOARD_ID := U12H172T00_NETGEAR
  NETGEAR_REGION := 1
endef
TARGET_DEVICES += netgear-wnr3500l-v2

define Device/netgear-wnr3500-v2
  DEVICE_MODEL := WNR3500
  DEVICE_VARIANT := v2
  DEVICE_PACKAGES := kmod-b43
  $(Device/netgear)
  NETGEAR_BOARD_ID := U12H127T00_NETGEAR
  NETGEAR_REGION := 2
endef
TARGET_DEVICES += netgear-wnr3500-v2

Do these really only differ in packages and region, or is there a parameter to 
determine which is used from the running device?

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: RE: [PATCH] ath79: add support for gl-e750

[mail]

> > What about caldata? Is there a valid address in 0x5006?
> > ---> Calibration data for the E750 is not stored in flash, therefore, the 
> > MAC
> address is not read from 0x5006.
> > ---> In the production process of GL router, a basic MAC address will be
> written at the beginning of ART, and I calculate the MAC address of 5G
> through this MAC address.
> 
> Okay, then please consolidate the MAC address setup like the following:
> 
> > +   glinet,gl-e750)
> > +   # Set mac address for 5g device
> > +   [ "$PHYNBR" -eq 0 ] && \
> > +   macaddr_add $(mtd_get_mac_binary art 0x0) 2) >
> /sys${DEVPATH}/macaddress
> > +   ;;

BTW: Would the following DTS statement work for your device _instead_ of the 
code in 10-fix-wifi-mac:

 {
status = "okay";

wifi@0,0 {
compatible = "qcom,ath10k";
reg = <0x 0 0 0 0>;
mtd-mac-address = < 0x0>;
mtd-mac-address-increment = <2>;
};
};

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: RE: [PATCH] ath79: add support for gl-e750

[mail]

> Thank you for pointing out my problem.
> Part of the problem I need to explain.
>
> No LEDs?
> --->Yes, no leds
>
> Why eth1?
> 
> If that's caused by  being enabled in device tree, you can try to put 
> the following in DTS:
> 
>  {
> compatible = "syscon", "simple-mfd";
> };
> 
> With this, you might be able to use
> ucidef_set_interface_lan "eth0"
> --->the E750 has only one ethernet port, but this port corresponds to eth1 in 
> the system.

I still think if there is only one port, it should be eth0 on the running 
system. I do not see a point to use eth1 and have a non-working eth0 there.
And I assume that putting the above node into DTS should achieve just this.

> --->In E750, we only use GMAC0, but in ATH79 target, I had to initialize P4 
> via GMAC1 connected to the Ethernet switch, the GMAC0 corresponds to eth1 and 
> the GMAC1  corresponds to eth0.
> --->I have tried to use GMAC0 to initialize P4 directly, but after 
> initializing P4 in this way, the speed of P4 can only be 100M, not 100M/10M.
>
> This should be done properly in 
> generic/base-files/etc/hotplug.d/firmware/11-ath10k-caldata instead.
> --->E750 block using eeprom storage calibration data of 9887, when the 
> driving load, also won't call /etc/hotplug.d/firmware/11-ath10k-caldata.
>
> What about caldata? Is there a valid address in 0x5006?
> ---> Calibration data for the E750 is not stored in flash, therefore, the MAC 
> address is not read from 0x5006.
> ---> In the production process of GL router, a basic MAC address will be 
> written at the beginning of ART, and I calculate the MAC address of 5G 
> through this MAC address.

Okay, then please consolidate the MAC address setup like the following:

> + glinet,gl-e750)
> + # Set mac address for 5g device
> + [ "$PHYNBR" -eq 0 ] && \
> + macaddr_add $(mtd_get_mac_binary art 0x0) 2) > 
> /sys${DEVPATH}/macaddress
> + ;;

Despite, I'm always happy about a MAC address overview in the commit message, 
e.g. like here:
https://github.com/openwrt/openwrt/commit/edbc8e5512dccc2e0b6925258e34b3f21d66679c

Instead of the last byte from an actual address, you might just include the 
offset relative to one of the addresses. This will help a lot for understanding 
the setup when looking at the commit in a few years.

Despite, if the device has a "label MAC address" printed on a label/the case 
somewhere, it would be nice to mention which one it is (i.e. which interface 
has the same address) in the commit message and to implement it in the code 
(see https://openwrt.org/docs/guide-developer/mac.address#label_mac_address).

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [PATCH] ath79: add support for gl-e750

[mail]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Luochongjun
> Sent: Freitag, 10. Juli 2020 11:32
> To: openwrt-devel@lists.openwrt.org
> Cc: Luochongjun 
> Subject: [PATCH] ath79: add support for gl-e750
> 
> The gl-e750 is a portable travel router that gives you safe access to the
> internet while traveling.
> 
> Specifications:
> - SoC: Qualcomm Atheros AR9531 (650MHz)
> - RAM: 128 MB DDR2
> - Flash: 16 MB SPI NOR (W25Q128FVSG) + 128 MB SPI NAND
> (GD5F1GQ4UFYIG)
> - Ethernet: 10/100: 1xLAN
> - Wireless: QCA9531 2.4GHz (bgn) + QCA9887 5GHz (ac)
> - USB: 1x USB 2.0 port
> - Switch: 1x switch
> - Button: 1x reset button
> - OLED Screen: 128*64 px
> 
> Flash firmware:
> Since openwrt's kernel already exceeds 2MB, upgrading from the official
> version of GL-inet (v3.100) using the sysupgrade command will break the
> kernel image. Users who are using version 3.100 can only upgrade via uboot.
> The official guidance for GL-inet is as follows:
> https://docs.gl-inet.com/en/3/troubleshooting/debrick/
> 
> In the future, GL-inet will modify the firmware to support the sysupgrade
> command, so users will be able to upgrade directly with the sysupgrade
> command in future releases.
> 
> OLED screen control:
> OLED controller is connected to QCA9531 through serial port, and can send
> instructions to OLED controller directly through serial port.
> Refer to the links below for a list of supported instructions:
> https://github.com/gl-inet/GL-E750-MCU-instruction
> 
> Signed-off-by: Luochongjun 
> ---
>  target/linux/ath79/dts/qca9531_glinet_gl-e750.dts  | 140
> +
>  target/linux/ath79/image/nand.mk   |  19 +++
>  .../ath79/nand/base-files/etc/board.d/02_network   |   3 +
>  .../etc/hotplug.d/ieee80211/10-fix-wifi-mac|   8 ++
>  4 files changed, 170 insertions(+)
>  create mode 100644 target/linux/ath79/dts/qca9531_glinet_gl-e750.dts
> 
> diff --git a/target/linux/ath79/dts/qca9531_glinet_gl-e750.dts
> b/target/linux/ath79/dts/qca9531_glinet_gl-e750.dts
> new file mode 100644
> index 000..fc88bbd
> --- /dev/null
> +++ b/target/linux/ath79/dts/qca9531_glinet_gl-e750.dts
> @@ -0,0 +1,140 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT /dts-v1/;
> +
> +#include 
> +#include 
> +
> +#include "qca953x.dtsi"
> +
> +/ {
> + compatible = "glinet,gl-e750", "qca,qca9531";
> + model = "GL.iNet GL-E750";
> +
> + keys {
> + compatible = "gpio-keys";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_disable_pins>;
> +
> + reset {
> + label = "reset";
> + linux,code = ;
> + gpios = < 3 GPIO_ACTIVE_LOW>;
> + };
> +
> + switch {
> + label = "switch";
> + linux,code = ;
> + gpios = < 1 GPIO_ACTIVE_LOW>;
> + };
> + };

No LEDs?

> +
> +gpio-export {
> +compatible = "gpio-export";
> +#size-cells = <0>;
> +
> +gpio_lte_power {
> +gpio-export,name = "lte_power";
> +gpio-export,output = <1>;
> +gpios = < 0 GPIO_ACTIVE_HIGH>;
> +};
> +};

Looks like indent issues here. DTS file should be tabs-only.
And remove this empty line here, please.

> +
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "okay";
> +
> + hub_port: port@1 {
> + reg = <1>;
> + #trigger-source-cells = <0>;
> + };
> +};

If there is no USB LED, it is enough to just put:

 {
status = "okay";
};

> +
> +_phy {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> + num-cs = <2>;
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <2500>;
> +
> + 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>;
> + };
> +
> + art: partition@5 {
> + label = "art";
> + reg = <0x5 0x1>;
> + read-only;
> + };
> +
> + partition@6 {
> + label = "kernel";
> + 

RE: [PATCH] mvebu: add support for MACCHIATObin Single Shot

[mail]

> > -Original Message- 
> > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] 
> > On Behalf Of Tomasz Maciej Nowak 
> > Sent: Donnerstag, 9. Juli 2020 21:16 
> > To: openwrt-devel@lists.openwrt.org 
> > Cc: Alexandra Alth  
> > Subject: [PATCH] mvebu: add support for MACCHIATObin Single Shot 
> > 
> > The currently supported Double Shot variant provides dts which is not 
> > entirely compatible with Single Shot variant. The symptoms are that SFP 
> > ports are not working. To remedy this, add two images to distinguish both 
> > boards, wich have proper dtb assigned. 
> > 
> > Reported-by: Alexandra Alth  
> > Signed-off-by: Tomasz Maciej Nowak  
> > --- 
> >  target/linux/mvebu/image/cortexa72.mk | 20 ++-- 
> >  1 file changed, 18 insertions(+), 2 deletions(-) 
> > 
> > diff --git a/target/linux/mvebu/image/cortexa72.mk 
> > b/target/linux/mvebu/image/cortexa72.mk 
> > index 50233540ed2e..cab2ffcaa251 100644 
> > --- a/target/linux/mvebu/image/cortexa72.mk 
> > +++ b/target/linux/mvebu/image/cortexa72.mk 
> > @@ -16,14 +16,30 @@ define Device/marvell_armada8040-db  endef 
> > TARGET_DEVICES += marvell_armada8040-db 
> > 
> > -define Device/marvell_macchiatobin 
> > +define Device/marvell_macchiatobin-doubleshot 
> >    $(call Device/Default-arm64) 
> >    DEVICE_VENDOR := SolidRun 
> >    DEVICE_MODEL := MACCHIATObin 
> > +  DEVICE_VARIANT := Double Shot 
> >    DEVICE_ALT0_VENDOR := SolidRun 
> >    DEVICE_ALT0_MODEL := Armada 8040 Community Board 
> > +  DEVICE_ALT0_VARIANT := Double Shot 
> >    DEVICE_PACKAGES += kmod-i2c-mux-pca954x 
> >    DEVICE_DTS := armada-8040-mcbin 
> >    SUPPORTED_DEVICES := marvell,armada8040-mcbin  endef - 
> > TARGET_DEVICES += marvell_macchiatobin 
> > +TARGET_DEVICES += marvell_macchiatobin-doubleshot 
> > + 
> > +define Device/marvell_macchiatobin-singleshot 
> > +  $(call Device/Default-arm64) 
> > +  DEVICE_VENDOR := SolidRun 
> > +  DEVICE_MODEL := MACCHIATObin 
> > +  DEVICE_VARIANT := Single Shot 
> > +  DEVICE_ALT0_VENDOR := SolidRun 
> > +  DEVICE_ALT0_MODEL := Armada 8040 Community Board 
> > +  DEVICE_ALT0_VARIANT := Single Shot 
> > +  DEVICE_PACKAGES += kmod-i2c-mux-pca954x 
> > +  DEVICE_DTS := armada-8040-mcbin-singleshot 
> > +  SUPPORTED_DEVICES := marvell,armada8040-mcbin-singleshot 
> > +endef 
> > +TARGET_DEVICES += marvell_macchiatobin-singleshot 
> Kernel tells me that the compatible for these devices is 
> marvell,armada8040-mcbin-doubleshot 
> and 
> marvell,armada8040-mcbin-singleshot 
> However, we seem to implement something different: 
> adsc@buildfff:/data/openwrt$ grep -rn "mcbin" target/linux/mvebu/ | sort 
> target/linux/mvebu/cortexa72/base-files/etc/board.d/02_network:14:marvell,armada8040-mcbin)
>  
> target/linux/mvebu/cortexa72/base-files/lib/upgrade/platform.sh:12: 
> marvell,armada8040-mcbin) 
> target/linux/mvebu/cortexa72/base-files/lib/upgrade/platform.sh:23: 
> marvell,armada8040-mcbin) 
> target/linux/mvebu/cortexa72/base-files/lib/upgrade/platform.sh:33: 
> marvell,armada8040-mcbin) 
> target/linux/mvebu/image/cortexa72.mk:26:  DEVICE_DTS := armada-8040-mcbin 
> target/linux/mvebu/image/cortexa72.mk:27:  SUPPORTED_DEVICES := 
> marvell,armada8040-mcbin 
> So, ... 
> 1. is the current setup broken for the doubleshot already? 
> 2. If yes, the relevant sections seem to be updated for the singleshot as 
> well ... 
> Best 
> Adrian 

Had a look at the kernel and actually option 1 is true, they added a new 
primary compatible for the doubleshot when introducing the singleshot.

I sent a patch for that already a minute ago, just fixing doubleshot with the 
current implementation.

Consequently, your patch should be updated to also provide the correct board 
name for singleshot in 02_network and platform.sh.

Despite, I cannot judge how the SFP port will affect network config with 
respect to 02_network.

Best

Adrian


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


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [PATCH] mvebu: add support for MACCHIATObin Single Shot

[mail]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Tomasz Maciej Nowak
> Sent: Donnerstag, 9. Juli 2020 21:16
> To: openwrt-devel@lists.openwrt.org
> Cc: Alexandra Alth 
> Subject: [PATCH] mvebu: add support for MACCHIATObin Single Shot
> 
> The currently supported Double Shot variant provides dts which is not
> entirely compatible with Single Shot variant. The symptoms are that SFP
> ports are not working. To remedy this, add two images to distinguish both
> boards, wich have proper dtb assigned.
> 
> Reported-by: Alexandra Alth 
> Signed-off-by: Tomasz Maciej Nowak 
> ---
>  target/linux/mvebu/image/cortexa72.mk | 20 ++--
>  1 file changed, 18 insertions(+), 2 deletions(-)
> 
> diff --git a/target/linux/mvebu/image/cortexa72.mk
> b/target/linux/mvebu/image/cortexa72.mk
> index 50233540ed2e..cab2ffcaa251 100644
> --- a/target/linux/mvebu/image/cortexa72.mk
> +++ b/target/linux/mvebu/image/cortexa72.mk
> @@ -16,14 +16,30 @@ define Device/marvell_armada8040-db  endef
> TARGET_DEVICES += marvell_armada8040-db
> 
> -define Device/marvell_macchiatobin
> +define Device/marvell_macchiatobin-doubleshot
>$(call Device/Default-arm64)
>DEVICE_VENDOR := SolidRun
>DEVICE_MODEL := MACCHIATObin
> +  DEVICE_VARIANT := Double Shot
>DEVICE_ALT0_VENDOR := SolidRun
>DEVICE_ALT0_MODEL := Armada 8040 Community Board
> +  DEVICE_ALT0_VARIANT := Double Shot
>DEVICE_PACKAGES += kmod-i2c-mux-pca954x
>DEVICE_DTS := armada-8040-mcbin
>SUPPORTED_DEVICES := marvell,armada8040-mcbin  endef -
> TARGET_DEVICES += marvell_macchiatobin
> +TARGET_DEVICES += marvell_macchiatobin-doubleshot
> +
> +define Device/marvell_macchiatobin-singleshot
> +  $(call Device/Default-arm64)
> +  DEVICE_VENDOR := SolidRun
> +  DEVICE_MODEL := MACCHIATObin
> +  DEVICE_VARIANT := Single Shot
> +  DEVICE_ALT0_VENDOR := SolidRun
> +  DEVICE_ALT0_MODEL := Armada 8040 Community Board
> +  DEVICE_ALT0_VARIANT := Single Shot
> +  DEVICE_PACKAGES += kmod-i2c-mux-pca954x
> +  DEVICE_DTS := armada-8040-mcbin-singleshot
> +  SUPPORTED_DEVICES := marvell,armada8040-mcbin-singleshot
> +endef
> +TARGET_DEVICES += marvell_macchiatobin-singleshot

Kernel tells me that the compatible for these devices is
marvell,armada8040-mcbin-doubleshot
and
marvell,armada8040-mcbin-singleshot

However, we seem to implement something different:
adsc@buildfff:/data/openwrt$ grep -rn "mcbin" target/linux/mvebu/ | sort
target/linux/mvebu/cortexa72/base-files/etc/board.d/02_network:14:marvell,armada8040-mcbin)
target/linux/mvebu/cortexa72/base-files/lib/upgrade/platform.sh:12: 
marvell,armada8040-mcbin)
target/linux/mvebu/cortexa72/base-files/lib/upgrade/platform.sh:23: 
marvell,armada8040-mcbin)
target/linux/mvebu/cortexa72/base-files/lib/upgrade/platform.sh:33: 
marvell,armada8040-mcbin)
target/linux/mvebu/image/cortexa72.mk:26:  DEVICE_DTS := armada-8040-mcbin
target/linux/mvebu/image/cortexa72.mk:27:  SUPPORTED_DEVICES := 
marvell,armada8040-mcbin

So, ...
1. is the current setup broken for the doubleshot already?
2. If yes, the relevant sections seem to be updated for the singleshot as well 
...

Best

Adrian


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


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [PATCH] build: put DT "compatible" value as "board_name" in profiles.json

[mail]

> -Original Message-
> From: Rafał Miłecki [mailto:ra...@milecki.pl]
> Sent: Donnerstag, 9. Juli 2020 11:12
> To: Daniel Golle 
> Cc: Rafał Miłecki ; Paul Spooren ;
> openwrt-devel@lists.openwrt.org; Adrian Schmutzler
> ; Petr Štetiar ; Moritz
> Warning ; Imre Kaloz 
> Subject: Re: [PATCH] build: put DT "compatible" value as "board_name" in
> profiles.json
> 
> On 2020-07-09 10:49, Daniel Golle wrote:
> > On Wed, Jul 08, 2020 at 11:32:43PM +0200, Rafał Miłecki wrote:
> >> On 08.07.2020 21:34, Paul Spooren wrote:
> >> > I think there is a policy for new DT devices to use the compatible string
> as profile.
> >> >
> >> > Multiple targets contain the following line in the target Makefile, which
> automatically adds the profile name as supported device:
> >> >
> >> > SUPPORTED_DEVICES := $(subst _,$(comma),$(1))
> >> >
> >> > So ideally for all devices using DT, the profile and compatible string 
> >> > are
> the same except for '_' replaced by ','.
> >> >
> >> > For instance, the "Linksys WRT3200ACM" has the profile ID
> `linksys_wrt3200acm` and the automatically added compatible string
> `linksys,wrt3200acm`. So if that device wanted to search the
> `mvebu/cortexa9/profiles.json` for available sysupgrades, it takes the first
> entry from /proc/device-tree/compatible, replaces ',' with '_' find images in
> profiles.json['profiles']['linksys_wrt3200acm']['images'].
> >> >
> >> > For cases where DT compatible and OpenWrt profile ID/name where
> different either one was patched[0].
> >>
> >> There are still few exceptions like:
> >> linksys-ea9500 vs. compatible = "linksys,panamera"
> >> luxul-xwr-3150 vs. compatible = "luxul,xwr-3150-v1"
> >> luxul-xbr-4500 vs. compatible = "luxul,xbr-4500-v1"

Essentially, we should be able to exploit SUPPORTED_DEVICES for that. Even if 
there is no sysupgrade with metadata available on the target, the 
SUPPORTED_DEVICES could indicate which board names would be possible for 
upgrade.
This would also enable the possibility of a 1:n relationship (instead of a 
1:1), i.e. one profile might be used for multiple "board names" (e.g. if you 
look at x86).

The problem will arise from the opposite situation: e.g. in ar71xx, the same 
board name might be used for many profiles. With a board-name-based approach, 
we will never be able to support these for auto-upgrade or similar.
However, I think ar71xx has been the last target that does this to a big 
extent. There are rare cases where the same DTS is used for more than one 
profile, but I think we can just ignore those for the moment.
However, if we exploit the board name for that purpose, we should be aware that 
we move its use away from the initial intention (as in ar71xx, where it really 
described a board, not a device). I'm fine with that, as that's what I'm trying 
to enforce lately anyway, but not everyone might be.

The implementation of "proper" board names for the non-DT targets then is not 
much more than some boring work to do (though e.g. bcm47xx could actually 
benefit from it).

Best

Adrian

> >>
> >> This is a bit of problem because:
> >> 1. I can't change "panamera" to "ea9500" as I was explicitly asked to
> >>stick to "panamera" by Imre when upstreaming that DTS
> >
> > I agree we should respect the artistic preferences of contributors to
> > some degree.
> > However, in this case, is there any reason for that somehow secretive
> > naming scheme beyond personal preference?
> > Having a consistent and easy to understand codebase also weights a bit
> > higher than that to me.
> 
> For Linksys, as said, I was told by Imre to use that magic "paramera"
> string. The only explanation I got was that it was "discussed for other
> platforms". For reference, see:
> 
> [PATCH] ARM: dts: BCM5301X: Add basic DT for Linksys EA9500
> https://patchwork.kernel.org/patch/9588095/
> 
> For Luxul devices "-v1" suffix was initially used (during development) and
> later it was decided V2 won't ever appear. So filename got simplified.


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [PATCH] build: put DT "compatible" value as "board_name" in profiles.json

[mail]

> -Original Message-
> From: Paul Spooren [mailto:m...@aparcar.org]
> Sent: Mittwoch, 8. Juli 2020 21:34
> To: Rafał Miłecki ; openwrt-devel@lists.openwrt.org
> Cc: Rafał Miłecki ; Adrian Schmutzler
> ; Petr Štetiar ; Moritz
> Warning ; Daniel Golle 
> Subject: Re: [PATCH] build: put DT "compatible" value as "board_name" in
> profiles.json
> 
> TL;DR: I think the issue is solved for devices using DT, the problem are the
> other targets with custom solutions.
> 
> I think there is a policy for new DT devices to use the compatible string as
> profile.
> 
> Multiple targets contain the following line in the target Makefile, which
> automatically adds the profile name as supported device:
> 
> SUPPORTED_DEVICES := $(subst _,$(comma),$(1))
> 
> So ideally for all devices using DT, the profile and compatible string are the
> same except for '_' replaced by ','.
> 
> For instance, the "Linksys WRT3200ACM" has the profile ID
> `linksys_wrt3200acm` and the automatically added compatible string
> `linksys,wrt3200acm`. So if that device wanted to search the
> `mvebu/cortexa9/profiles.json` for available sysupgrades, it takes the first
> entry from /proc/device-tree/compatible, replaces ',' with '_'
> find images in profiles.json['profiles']['linksys_wrt3200acm']['images'].
> 
> For cases where DT compatible and OpenWrt profile ID/name where
> different either one was patched[0].
> 
> I think the question is therefore more on how to deal with devices that do
> not use DT? If we use a per device rootfs a line could be added to /etc/os-
> release containing something like OPENWRT_PROFILE="SpEcIaL-CaSEv100",
> which is then shown via `ubus call system borad`.

Well, one could just use something like this, which we had before the 
compatible was used:

https://github.com/openwrt/openwrt/blob/openwrt-19.07/target/linux/ramips/base-files/lib/ramips.sh

There, one could just use the "profile names" instead, with "_" replaced by "," 
for the few non-DT targets.
However, this assumes a 1-to-1 relation between boards and profiles, and I'm 
not sure whether that always exists.
And somebody would have to create that by hand.

But I somehow lost track what's the ultimate goal of the proposed changes here, 
so maybe I'm not going into the right direction with this.

Best

Adrian

> 
> Another hack could be to add it to /proc/cmdline?
> 
> [0]:
> https://github.com/openwrt/openwrt/commit/df6f3090c48e3bafa0ace7450
> 488b0a20a8074fb
> 
> On 08.07.20 05:09, Rafał Miłecki wrote:
> > From: Rafał Miłecki 
> >
> > The purpose of "board_name" in JSON is matchine OpenWrt running
> device
> > with JSON profile entry. Right now it gets filled for devices using DT.
> > Other targets will require custom solutions or just speciyfing that
> > value manually.
> >
> > Signed-off-by: Rafał Miłecki 
> > ---
> >   include/image.mk   |  3 +++
> >   scripts/json_add_image_info.py | 19 +++
> >   2 files changed, 22 insertions(+)
> >
> > diff --git a/include/image.mk b/include/image.mk index
> > 15f4fe9d3b..b33c1032f8 100644
> > --- a/include/image.mk
> > +++ b/include/image.mk
> > @@ -532,10 +532,13 @@ define Device/Build/image
> > @mkdir -p $$(shell dirname $$@)
> > DEVICE_ID="$(DEVICE_NAME)" \
> > BIN_DIR="$(BIN_DIR)" \
> > +   LINUX_DIR="$(LINUX_DIR)" \
> > +   KDIR="$(KDIR)" \
> > IMAGE_NAME="$(IMAGE_NAME)" \
> > IMAGE_TYPE=$(word 1,$(subst ., ,$(2))) \
> > IMAGE_PREFIX="$(IMAGE_PREFIX)" \
> > DEVICE_TITLE="$(DEVICE_TITLE)" \
> > +   DEVICE_DTS="$(DEVICE_DTS)" \
> > TARGET="$(BOARD)" \
> > SUBTARGET="$(if $(SUBTARGET),$(SUBTARGET),generic)" \
> > VERSION_NUMBER="$(VERSION_NUMBER)" \ diff --git
> > a/scripts/json_add_image_info.py b/scripts/json_add_image_info.py
> > index b4d2dd8d71..5df4bf2a2a 100755
> > --- a/scripts/json_add_image_info.py
> > +++ b/scripts/json_add_image_info.py
> > @@ -5,6 +5,8 @@ from pathlib import Path
> >   from sys import argv
> >   import hashlib
> >   import json
> > +import re
> > +import subprocess
> >
> >   if len(argv) != 2:
> >   print("ERROR: JSON info script requires output arg") @@ -22,6
> > +24,20 @@ if not image_file.is_file():
> >   def get_titles():
> >   return [{"title": getenv("DEVICE_TITLE")}]
> >
> > +def get_board_name():
> > +device_dts = getenv("DEVICE_DTS")
> > +if device_dts is not None:
> > +dtc = getenv("LINUX_DIR") + "/scripts/dtc/dtc"
> > +dtb_file = getenv("KDIR") + "/image-" + device_dts + ".dtb"
> > +dts = subprocess.run([dtc, "-q", "-I", "dtb", "-O", "dts", "-o", 
> > "-",
> dtb_file], capture_output=True, text=True)
> > +if dts.returncode != 0:
> > +return None
> > +match = re.search("compatible = \"([^\"]*)", dts.stdout)
> > +if match is None:
> > +return None
> > +return match[1]
> > +return None
> > +
> >
> >   device_id = getenv("DEVICE_ID")
> >   image_hash = hashlib.sha256(image_file.read_bytes()).hexdigest()
> > 

RE: [RFC PATCH] Introduce UCI support for configuring DSA VLAN filter rules

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Jo-Philipp Wich
> Sent: Dienstag, 7. Juli 2020 15:35
> To: j...@mein.io; openwrt-devel@lists.openwrt.org
> Subject: [RFC PATCH] Introduce UCI support for configuring DSA VLAN filter
> rules
> 
> This patch series introduces a new package "dsaconfig" which provides the
> necessary logic to allow configuration of bridge vlan filter rules for DSA
> switches.

Hi, thanks for taking care of that.

[...]

>  - Consider changing the types of the UCI sections from
>switch/switch_vlan/switch_port to dsa/dsa_vlan/dsa_port

Using new names for DSA would have the benefit that migration would be much 
easier, as we always knew what the config is meant for (and we wouldn't need 
another migration_done=1 variable or similar.)
However, it might create some code duplication in other tools/packages that 
alter uci network config. This might be seen as drawback (duplication) or 
advantage (separate code based on separate setup, as there might be differences 
anyway).

I currently have a weak to moderate tendency for the dsa_* scheme.

Best

Adrian

> 
>  - Investigate potential MTU issues regarding the CPU port
> 
> Jo-Philipp Wich (1):
>   dsaconfig: introduce package for UCI configuration of VLAN filter
> rules
> 
>  package/network/config/dsaconfig/Makefile |  40 +++
>  .../config/dsaconfig/files/dsaconfig.hotplug  |   7 +
>  .../config/dsaconfig/files/dsaconfig.include  |  11 +
>  .../config/dsaconfig/files/dsaconfig.sh   | 296 ++
>  4 files changed, 354 insertions(+)
>  create mode 100644 package/network/config/dsaconfig/Makefile
>  create mode 100644
> package/network/config/dsaconfig/files/dsaconfig.hotplug
>  create mode 100755
> package/network/config/dsaconfig/files/dsaconfig.include
>  create mode 100755 package/network/config/dsaconfig/files/dsaconfig.sh
> 
> --
> 2.20.1
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [PATCH] build: conditionally enable testing-kernel feature

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of David Bauer
> Sent: Montag, 6. Juli 2020 11:05
> To: openwrt-devel@lists.openwrt.org
> Subject: [PATCH] build: conditionally enable testing-kernel feature
> 
> Only enable the testing-kernel feature for the target when the testing kernel
> version does not match the stable kernel version.
> 
> This way, the option for building the testing kernel in the build config menu 
> is
> only exposed when there's a testing kernel available.

Acked-by: Adrian Schmutzler 

I also quickly "tested" it.

I think this should go in no matter how you finally decide to go on with the 
ath79 bump.

Best

Adrian

> 
> Signed-off-by: David Bauer 
> ---
>  include/target.mk | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/include/target.mk b/include/target.mk index
> a2ceb7f783..64292138b7 100644
> --- a/include/target.mk
> +++ b/include/target.mk
> @@ -223,7 +223,9 @@ ifeq ($(DUMP),1)
>  .PRECIOUS: $(TMP_CONFIG)
> 
>  ifdef KERNEL_TESTING_PATCHVER
> -  FEATURES += testing-kernel
> +  ifneq ($(KERNEL_TESTING_PATCHVER),$(KERNEL_PATCHVER))
> +FEATURES += testing-kernel
> +  endif
>  endif
>  ifneq ($(CONFIG_OF),)
>FEATURES += dt
> --
> 2.27.0
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [OpenWrt-Devel] [PATCH] ath79: switch to kernel 5.4

[mail]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Daniel Golle
> Sent: Montag, 6. Juli 2020 01:03
> To: David Bauer 
> Cc: Hauke Mehrtens ; openwrt-
> de...@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] [PATCH] ath79: switch to kernel 5.4
> 
> Hi David,
> 
> On Mon, Jul 06, 2020 at 12:37:06AM +0200, David Bauer wrote:
> > Hi Daniel,
> >
> > On 7/5/20 10:50 PM, Daniel Golle wrote:
> > > I suggest to completely remove KERNEL_TESTING_PATCHVER instead of
> > > setting it to the same version as KERNEL_PATCHVER.
> >
> > As most targets have it included, I've decided to specifically keep it.
> 
> Setting KERNEL_TESTING_PATCHVER enables the option in menuconfig to
> build with testing kernel. If set to the same version as KERNEL_PATCHVER,
> this is misleading as despite suggesting the use of a newer/testing version,
> obviously the exact same kernel version will be built.
> 
> You are right in that keeping it became the pattern once KERNEL_PATCHVER
> was bumped to the same level as KERNEL_TESTING_PATCHVER. I assume
> this was not deliberate (please scream now if it was!) we should also remove
> it from all other targets with KERNEL_PATCHVER ==
> KERNEL_TESTING_PATCHVER.

I also was a fan of keeping KERNEL_TESTING_PATCHVER recently, as this 
adding-and-removing-again seemed a bit unnecessary to me. However, your 
argument about menuconfig is valid.

I just wonder whether we, alternatively, could just check for KERNEL_PATCHVER 
== KERNEL_TESTING_PATCHVER in the code setting up menuconfig, and thus defeat 
the root cause

Best

Adrian

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


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [PATCH] dropbear: init: replace backticks with $()

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Rui Salvaterra
> Sent: Dienstag, 30. Juni 2020 18:22
> To: openwrt-devel@lists.openwrt.org
> Cc: Rui Salvaterra 
> Subject: [PATCH] dropbear: init: replace backticks with $()

Merged your two patches, please add a commit description next time.

Best

Adrian 


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

RE: [PATCH] ath79: replace custom uImageArcher generation

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of David Bauer
> Sent: Sonntag, 28. Juni 2020 18:26
> To: openwrt-devel@lists.openwrt.org
> Subject: [PATCH] ath79: replace custom uImageArcher generation
> 
> The replaces the custom uImageArcher build step with the generic uImage
> build step. The only different between these two is the difference in the
> generated name.

Acked-by: Adrian Schmutzler 

> 
> Tested on: TP-Link Archer C59 v1
> 
> Signed-off-by: David Bauer 
> ---
>  target/linux/ath79/image/common-tp-link.mk | 10 +-
>  1 file changed, 1 insertion(+), 9 deletions(-)
> 
> diff --git a/target/linux/ath79/image/common-tp-link.mk
> b/target/linux/ath79/image/common-tp-link.mk
> index 81a557df48..ab10920402 100644
> --- a/target/linux/ath79/image/common-tp-link.mk
> +++ b/target/linux/ath79/image/common-tp-link.mk
> @@ -1,14 +1,6 @@
>  DEVICE_VARS += TPLINK_HWID TPLINK_HWREV TPLINK_FLASHLAYOUT
> TPLINK_HEADER_VERSION  DEVICE_VARS += TPLINK_BOARD_ID
> TPLINK_HWREVADD TPLINK_HVERSION
> 
> -define Build/uImageArcher
> - mkimage -A $(LINUX_KARCH) \
> - -O linux -T kernel -C $(1) -a $(KERNEL_LOADADDR) \
> - -e $(if
> $(KERNEL_ENTRY),$(KERNEL_ENTRY),$(KERNEL_LOADADDR)) \
> - -n '$(call toupper,$(LINUX_KARCH)) OpenWrt Linux-
> $(LINUX_VERSION)' -d $@ $@.new
> - @mv $@.new $@
> -endef
> -
>  define Device/tplink-v1
>DEVICE_VENDOR := TP-Link
>TPLINK_HWID := 0x0
> @@ -86,7 +78,7 @@ endef
> 
>  define Device/tplink-safeloader-uimage
>$(Device/tplink-safeloader)
> -  KERNEL := kernel-bin | append-dtb | lzma | uImageArcher lzma
> +  KERNEL := kernel-bin | append-dtb | lzma | uImage lzma
>KERNEL_INITRAMFS := $$(KERNEL)
>  endef
> 
> --
> 2.27.0
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> http://lists.infradead.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

RE: [OpenWrt-Devel] [PATCH] ath79: switch to kernel 5.4

[mail]

> > > See here for some more details:
> > > https://bugs.openwrt.org/index.php?do=details_id=2928
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94506
> >
> > What's the status on this issue? Is it still there, and do we still have a
> blocker for 5.4 on ath79?
> 
> This issue is still open as of yesterday's master/ r13611-3f27a6e640, tested 
> on
> both tl-wdr3600 and tl-wdr4300 with kernel v5.4.48. The device bootloops
> very early and in close succession, requiring tftp recovery[0].

I think we should find some way to go on here. ath79 is quite a big target, and 
even after having it switched to 5.4 one should give it some time for tests and 
possible other necessary fixes before thinking about branching a release. So 
far, I see three possible options:

1. Just use Hauke's hack
2. Use a different GCC version for the target, since problems are limited to 
8.4.0
3. Find out the real reason for the problem

Am I getting this right? Any opinions or additional ideas?

Best

Adrian 


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

RE: [PATCH] ramips: add support for NETGEAR WAC124

[mail]

Hi,

> -Original Message-
> From: Jan Hoffmann [mailto:j...@3e8.eu]
> Sent: Freitag, 26. Juni 2020 13:57
> To: openwrt-devel@lists.openwrt.org
> Cc: Jan Hoffmann 
> Subject: [PATCH] ramips: add support for NETGEAR WAC124
> 
> The hardware appears to be identical to R6260/R6350/R6850.
> 
> The factory image has been confirmed to work with nmrpflash.

Looks good so far.

Please add specifications and flashing instructions to your commit message.

For the license, I think the proper string is GPL-2.0-only instead of GPL-2.0.

Best

Adrian

> 
> Signed-off-by: Jan Hoffmann 
> ---
>  .../ramips/dts/mt7621_netgear_wac124.dts  | 25 +++
>  target/linux/ramips/image/mt7621.mk   | 12 +
>  .../mt7621/base-files/etc/board.d/01_leds |  1 +
>  .../mt7621/base-files/lib/upgrade/platform.sh |  1 +
>  4 files changed, 39 insertions(+)
>  create mode 100644 target/linux/ramips/dts/mt7621_netgear_wac124.dts
> 
> diff --git a/target/linux/ramips/dts/mt7621_netgear_wac124.dts
> b/target/linux/ramips/dts/mt7621_netgear_wac124.dts
> new file mode 100644
> index 00..b59fa1f539
> --- /dev/null
> +++ b/target/linux/ramips/dts/mt7621_netgear_wac124.dts
> @@ -0,0 +1,25 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/dts-v1/;
> +
> +#include "mt7621_netgear_sercomm_chj.dtsi"
> +
> +/ {
> + compatible = "netgear,wac124", "mediatek,mt7621-soc";
> + model = "Netgear WAC124";
> +};
> +
> +_power {
> + label = "wac124:green:power";
> +};
> +
> +_usb {
> + label = "wac124:green:usb";
> +};
> +
> +_internet {
> + label = "wac124:green:wan";
> +};
> +
> +_wifi {
> + label = "wac124:green:wifi";
> +};
> diff --git a/target/linux/ramips/image/mt7621.mk
> b/target/linux/ramips/image/mt7621.mk
> index d6423f81d9..de20934598 100644
> --- a/target/linux/ramips/image/mt7621.mk
> +++ b/target/linux/ramips/image/mt7621.mk
> @@ -702,6 +702,18 @@ define Device/netgear_wac104  endef
> TARGET_DEVICES += netgear_wac104
> 
> +define Device/netgear_wac124
> +  $(Device/netgear_sercomm_nand)
> +  DEVICE_MODEL := WAC124
> +  SERCOMM_HWNAME := WAC124
> +  SERCOMM_HWID := CTL
> +  SERCOMM_HWVER := A003
> +  SERCOMM_SWVER := 0x0402
> +  IMAGE_SIZE := 40960k
> +  DEVICE_PACKAGES += kmod-mt7615e kmod-mt7615-firmware endef
> +TARGET_DEVICES += netgear_wac124
> +
>  define Device/netgear_wndr3700-v5
>$(Device/uimage-lzma-loader)
>BLOCKSIZE := 64k
> diff --git a/target/linux/ramips/mt7621/base-files/etc/board.d/01_leds
> b/target/linux/ramips/mt7621/base-files/etc/board.d/01_leds
> index fdfd29d011..716bc6e462 100755
> --- a/target/linux/ramips/mt7621/base-files/etc/board.d/01_leds
> +++ b/target/linux/ramips/mt7621/base-files/etc/board.d/01_leds
> @@ -56,6 +56,7 @@ netgear,r6220|\
>  netgear,r6260|\
>  netgear,r6350|\
>  netgear,r6850|\
> +netgear,wac124|\
>  netgear,wndr3700-v5)
>   ucidef_set_led_netdev "wan" "wan" "$boardname:green:wan"
> "wan"
>   ;;
> diff --git a/target/linux/ramips/mt7621/base-files/lib/upgrade/platform.sh
> b/target/linux/ramips/mt7621/base-files/lib/upgrade/platform.sh
> index cb26b7745b..233ed80b4e 100755
> --- a/target/linux/ramips/mt7621/base-files/lib/upgrade/platform.sh
> +++ b/target/linux/ramips/mt7621/base-files/lib/upgrade/platform.sh
> @@ -53,6 +53,7 @@ platform_do_upgrade() {
>   netgear,r6800|\
>   netgear,r6850|\
>   netgear,wac104|\
> + netgear,wac124|\
>   netis,wf2881|\
>   xiaomi,mir3g|\
>   xiaomi,mir3p|\
> --
> 2.27.0
> 


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

[no subject]

[mail--- via openwrt-devel]

--- Begin Message ---
Hi,

the subtarget mpc85xx/generic has been renamed to mpc85xx/p1010 in commit:

https://github.com/openwrt/openwrt/commit/564f87ef5bea16d5d1d8a9a80e8de77429159f26

Unfortunately, nobody has though of updating the buildbots, so images are 
frozen at that date and the buildbot fails for every run:

http://buildbot.openwrt.org/master/images/builders/mpc85xx%2Fgeneric

Maybe somebody with access can update that, or give me access and a short 
introduction so I can fix this myself.

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel