Re: Job board support on openwrt.org?

[Sam Kuper]

On Sat, Jan 23, 2021 at 06:57:53PM -0500, Etienne Champetier wrote:
> Le sam. 23 janv. 2021 à 18:09, Sam Kuper a écrit :
>> I suggest that if a vote is held, it should be a three-way vote
>> between the following outcomes (which should probably be mutually
>> exclusive):
>>
>> - OpenWRT Jobs wiki page;
>>
>> - openwrt-jobs mailing list;
> 
> - OpenWrt Jobs forum section, with a "non endorsement" disclaimer at
>   the top
>>
>> - Do nothing.

Thanks, fair point.  I forgot the forum.  (I mostly avoid Discourse.)

So, a vote between four possible outcomes.

-- 
A: When it messes up the order in which people normally read text.
Q: When is top-posting a bad thing?

()  ASCII ribbon campaign. Please avoid HTML emails & proprietary
/\  file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.

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

Re: Job board support on openwrt.org?

[Etienne Champetier]

Hi All,

Le sam. 23 janv. 2021 à 18:09, Sam Kuper  a écrit :
>
> On Sat, Jan 23, 2021 at 02:55:05PM +, Ted Hess wrote:
> > [T]here must be some sort of criteria (contributions, legitimate
> > business site or references) to get your name/outfit listed. And, as
> > Daniel said, we don't want to be in the business of certifying
> > contractors.
>
> Those two sentences seem to be slightly contradictory ;)
>
>
>
> Anyway, an alternative approach to the whole question of how to connect
> potential clients and contractors would be a mailing list, e.g.:
> openwrt-j...@openwrt.org .
>
> This would be a place for potential *clients/employers* to post
> jobs/tenders (to which potential contractors/employees could then reply
> on- or off-list).
>
> It would therefore place responsibility for establishing the credentials
> of the would-be employee or contractor entirely onto the potential
> employer or client, rather than onto the OpenWRT project.
>
> I.e. it is an inversion of the wiki page idea.
>
> I suggest that if a vote is held, it should be a three-way vote between
> the following outcomes (which should probably be mutually exclusive):
>
> - OpenWRT Jobs wiki page;
>
> - openwrt-jobs mailing list;

- OpenWrt Jobs forum section, with a "non endorsement" disclaimer at the top

My 2 cents
Etienne

>
> - Do nothing.
>
> Sam
>
> P.S.  I don't have an opinion on whether such a vote should be under
> FPTP or AV or Condorcet or some other voting method.  For reference, I
> think Debian uses "Condorcet/Clone Proof SSD":
> https://www.debian.org/vote/2003/vote_0002 .

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

Re: Job board support on openwrt.org?

[Sam Kuper]

On Sat, Jan 23, 2021 at 02:55:05PM +, Ted Hess wrote:
> [T]here must be some sort of criteria (contributions, legitimate
> business site or references) to get your name/outfit listed. And, as
> Daniel said, we don't want to be in the business of certifying
> contractors.

Those two sentences seem to be slightly contradictory ;)



Anyway, an alternative approach to the whole question of how to connect
potential clients and contractors would be a mailing list, e.g.:
openwrt-j...@openwrt.org .

This would be a place for potential *clients/employers* to post
jobs/tenders (to which potential contractors/employees could then reply
on- or off-list).

It would therefore place responsibility for establishing the credentials
of the would-be employee or contractor entirely onto the potential
employer or client, rather than onto the OpenWRT project.

I.e. it is an inversion of the wiki page idea.

I suggest that if a vote is held, it should be a three-way vote between
the following outcomes (which should probably be mutually exclusive):

- OpenWRT Jobs wiki page;

- openwrt-jobs mailing list;

- Do nothing.

Sam

P.S.  I don't have an opinion on whether such a vote should be under
FPTP or AV or Condorcet or some other voting method.  For reference, I
think Debian uses "Condorcet/Clone Proof SSD":
https://www.debian.org/vote/2003/vote_0002 .

-- 
A: When it messes up the order in which people normally read text.
Q: When is top-posting a bad thing?

()  ASCII ribbon campaign. Please avoid HTML emails & proprietary
/\  file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.

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

[PATCH] base-files: mount pstore if present

[Brian Norris]

Pstore (persistent store) can be used to stash debug information (kernel
console, panics, ftrace) across reboots or crashes. If the filesystem is
present, mount it.

Signed-off-by: Brian Norris 
---
 package/base-files/files/etc/init.d/boot | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/base-files/files/etc/init.d/boot 
b/package/base-files/files/etc/init.d/boot
index b36323a97e2a..a1e8e828dd2b 100755
--- a/package/base-files/files/etc/init.d/boot
+++ b/package/base-files/files/etc/init.d/boot
@@ -35,6 +35,7 @@ boot() {
ln -sf /tmp/resolv.conf.d/resolv.conf.auto /tmp/resolv.conf
grep -q debugfs /proc/filesystems && /bin/mount -o noatime -t debugfs 
debugfs /sys/kernel/debug
grep -q bpf /proc/filesystems && /bin/mount -o 
nosuid,nodev,noexec,noatime,mode=0700 -t bpf bpffs /sys/fs/bpf
+   grep -q pstore /proc/filesystems && /bin/mount -o noatime -t pstore 
pstore /sys/fs/pstore
[ "$FAILSAFE" = "true" ] && touch /tmp/.failsafe
 
/sbin/kmodloader
-- 
2.29.2


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

Re: Job board support on openwrt.org?

[Ted Hess]

On 1/23/2021 11:06:53 AM, "Petr Štetiar"  wrote:


Ted Hess  [2021-01-23 14:55:05]:

Hi,


 we don't want to be in the business of certifying contractors.


exactly.


 If we get complaints


Do we want new source for a potential bad press?


 their reference gets reviewed and most likely removed.


You can't review business cases as patches, this is quite different territory.



Point taken
/ted


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

Re: Job board support on openwrt.org?

[John Crispin]

Hi,

I do not think this is a good idea. The project should remain 
commercially and politically independent in order to guarantee its 
sovereignty. Hauke gave some good pointers on how to contact individuals 
devs.


    John


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

Re: Job board support on openwrt.org?

[Hauke Mehrtens]

On 1/23/21 6:07 PM, Ibrahim Tachijian wrote:
What do the NACK people say is the best way to find people that is 
willing to do OpenWRT work ?


Surely, emailing this mailing list is not enough, or?


Hi,

I would suggest to look into the git history of the part which interests 
you and write a mail to the people who contributed there if they would 
do contract work for you.


This is not really management or HR compatible, but if you have an 
engineer in your organization they can help you with that.


Hauke



On Sat, Jan 23, 2021, 17:27 Hauke Mehrtens > wrote:


On 1/23/21 2:24 PM, Jo-Philipp Wich wrote:
 > Hi,
 >
 > I don't think this is a good idea due to legal obligations,
 > administrative hassle, quality of work issues and so on.
 >
 > NACK from me.

I agree with Jo.

NACK from me too.

Such a page will also be seen as some sort of endorsement and people
could blame OpenWrt for bad work done by these people listed there. I
just do not want to handle this.

Hauke

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





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

Re: Job board support on openwrt.org?

[Hauke Mehrtens]

On 1/23/21 2:24 PM, Jo-Philipp Wich wrote:

Hi,

I don't think this is a good idea due to legal obligations,
administrative hassle, quality of work issues and so on.

NACK from me.


I agree with Jo.

NACK from me too.

Such a page will also be seen as some sort of endorsement and people 
could blame OpenWrt for bad work done by these people listed there. I 
just do not want to handle this.


Hauke



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

Re: Job board support on openwrt.org?

[Petr Štetiar]

Ted Hess  [2021-01-23 14:55:05]:

Hi,

> we don't want to be in the business of certifying contractors.

exactly.

> If we get complaints

Do we want new source for a potential bad press?

> their reference gets reviewed and most likely removed.

You can't review business cases as patches, this is quite different territory.

Cheers,

Petr

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

Re: Job board support on openwrt.org?

[Alberto Bursi]

On 23/01/21 09:49, Paul Spooren wrote:



On Sa, Jan 23, 2021 at 07:25, Alberto Bursi  
wrote:



On 22/01/21 20:03, Daniel Golle wrote:

Hi Philip,

On Fri, Jan 22, 2021 at 11:23:42AM -0700, Philip Prindeville wrote:

Hi,

Is anyone interested in adding a page to the openwrt.org site about 
developers willing to do commercial work?


It could be as simple as:

* name
* email address
* mobile (if wanted)
* packages/platforms/architectures you maintain or have competence in
* whether you're available full-time, part-time, or currently 
unavailable


Might be useful for matching up devs with work.


While I like the idea and would probably benefit from it myself, I'm
a bit sceptical when it comes to making OpenWrt.org an institution
certifying developers. Too much trouble was caused over having
'@openwrt.org' addresses and I doubt we are able to handle the
moderation needs (think: classic fraud, fishing, ...) of such a thing
if it is even a wiki, ie. free to edit for all.


the site/wiki has user-restricted pages already (the front page, the 
releases page and personal developer pages I think, probably more) 
because otherwise it would be a field day for spambots.
So this would not be a "free to edit for all", and more of a "ask a 
wiki admin to add your data to the page".
I and Tmomas won't be able to do a through vetting process on anybody, 
but we are more than enough to stop basic spammers and such, and can 
also respond to complaints and remove somebody in case issues arise 
later.
I'm also thinking about having some rules of thumb to limit access to 
people that have actually been involved in OpenWrt for a bit and can 
prove it (some relevant commits, some useful mail in the list, a core 
developer vouching for them, whatever).


-Alberto


I'm generally pro this but before this gets implemented (and after 
sufficiently discussed) please start a vote.




I was just explaining what can actually be done in practice.

I'm just a wiki maintainer/admin and very casual contributor to OpenWrt, 
I think that a vote about this should be started by someone in the 
Developer list.

https://openwrt.org/about#people

-Alberto





Things like a wiki with only volunteer moderation somehow work because
there is little to no commercial interest in manipulation and it is
usually easy to recognize (ie. classic spam). In the moment that we
change that, we have to be prepared to also face a different quality
of manipulation attempts.

Just my 2 cents...



Just an idea to help our community prosper.

Thanks,

-Philip


___
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





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

Re: Job board support on openwrt.org?

[Ted Hess]

On 1/23/2021 1:25:31 AM, "Alberto Bursi"  
wrote:





On 22/01/21 20:03, Daniel Golle wrote:

Hi Philip,

On Fri, Jan 22, 2021 at 11:23:42AM -0700, Philip Prindeville wrote:

Hi,

Is anyone interested in adding a page to the openwrt.org site about developers 
willing to do commercial work?

It could be as simple as:

* name
* email address
* mobile (if wanted)
* packages/platforms/architectures you maintain or have competence in
* whether you're available full-time, part-time, or currently unavailable

Might be useful for matching up devs with work.


While I like the idea and would probably benefit from it myself, I'm
a bit sceptical when it comes to making OpenWrt.org an institution
certifying developers. Too much trouble was caused over having
'@openwrt.org' addresses and I doubt we are able to handle the
moderation needs (think: classic fraud, fishing, ...) of such a thing
if it is even a wiki, ie. free to edit for all.


the site/wiki has user-restricted pages already (the front page, the releases 
page and personal developer pages I think, probably more) because otherwise it 
would be a field day for spambots.
So this would not be a "free to edit for all", and more of a "ask a wiki admin to 
add your data to the page".
I and Tmomas won't be able to do a through vetting process on anybody, but we 
are more than enough to stop basic spammers and such, and can also respond to 
complaints and remove somebody in case issues arise later.
I'm also thinking about having some rules of thumb to limit access to people 
that have actually been involved in OpenWrt for a bit and can prove it (some 
relevant commits, some useful mail in the list, a core developer vouching for 
them, whatever).


I pretty much agree with Alberto here - It seems like a good idea. 
Additionally, there must be some sort of criteria (contributions, 
legitimate business site or references) to get your name/outfit listed. 
And, as Daniel said, we don't want to be in the business of certifying 
contractors. If we get complaints, their reference gets reviewed and 
most likely removed.


My 2 cents,
/ted


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

Re: Job board support on openwrt.org?

[Jo-Philipp Wich]

Hi,

I don't think this is a good idea due to legal obligations,
administrative hassle, quality of work issues and so on.

NACK from me.

~ Jo

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

Re: [PATCH 1/2] mac80211: convert UniFi Outdoor+ HSR support to OF

[Matthias Schiffer]

On 1/23/21 1:58 AM, David Bauer wrote:

Enable support for the Ubiquiti UniFi Outdoor+ RF filter via
device-tree. The old way of using platform data is not required anymore,
as it was only used on the now removed ar71xx target.

Signed-off-by: David Bauer 
---
  .../ath/551-ath9k_ubnt_uap_plus_hsr.patch | 35 ++-
  .../files/include/linux/ath9k_platform.h  |  2 --
  2 files changed, 10 insertions(+), 27 deletions(-)

diff --git 
a/package/kernel/mac80211/patches/ath/551-ath9k_ubnt_uap_plus_hsr.patch 
b/package/kernel/mac80211/patches/ath/551-ath9k_ubnt_uap_plus_hsr.patch
index 4454baeef1..24cffb0e0e 100644
--- a/package/kernel/mac80211/patches/ath/551-ath9k_ubnt_uap_plus_hsr.patch
+++ b/package/kernel/mac80211/patches/ath/551-ath9k_ubnt_uap_plus_hsr.patch
@@ -1,27 +1,26 @@
  --- a/drivers/net/wireless/ath/ath9k/channel.c
  +++ b/drivers/net/wireless/ath/ath9k/channel.c
-@@ -15,6 +15,8 @@
+@@ -15,6 +15,7 @@
*/
   
   #include "ath9k.h"

-+#include 
  +#include "hsr.h"
   
   /* Set/change channels.  If the channel is really being changed, it's done

* by reseting the chip.  To accomplish this we must first cleanup any 
pending
-@@ -22,6 +24,7 @@
+@@ -22,6 +23,7 @@
*/
   static int ath_set_channel(struct ath_softc *sc)
   {
-+  struct ath9k_platform_data *pdata = sc->dev->platform_data;
++  struct device_node *np = sc->dev->of_node;
struct ath_hw *ah = sc->sc_ah;
struct ath_common *common = ath9k_hw_common(ah);
struct ieee80211_hw *hw = sc->hw;
-@@ -42,6 +45,11 @@ static int ath_set_channel(struct ath_so
+@@ -42,6 +44,11 @@ static int ath_set_channel(struct ath_so
ath_dbg(common, CONFIG, "Set channel: %d MHz width: %d\n",
chan->center_freq, chandef->width);
   
-+	if (pdata && pdata->ubnt_hsr) {

++  if (of_property_read_bool(np, "ath9k,ubnt-hsr")) {


The vendor prefix should be "ubnt", not "ath9k"
(see Documentation/devicetree/bindings/vendor-prefixes.yaml for the
official list.)



  + ath9k_hsr_enable(ah, chandef->width, chan->center_freq);
  + ath9k_hsr_status(ah);
  + }
@@ -332,30 +331,27 @@
  +#endif /* HSR_H */
  --- a/drivers/net/wireless/ath/ath9k/main.c
  +++ b/drivers/net/wireless/ath/ath9k/main.c
-@@ -16,8 +16,10 @@
-


[...]




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

[PATCH v2 1/2] bcm4908: sort and wrap build recipes

[Adrian Schmutzler]

This sorts the Build recipes alphabetically, wraps some long lines
and moves the DEVICE_VARS to the top like common on several other
targets.

Cc: Rafał Miłecki 

Signed-off-by: Adrian Schmutzler 
---
Changes in v2:
- new patch
---
 target/linux/bcm4908/image/Makefile | 28 
 1 file changed, 16 insertions(+), 12 deletions(-)

diff --git a/target/linux/bcm4908/image/Makefile 
b/target/linux/bcm4908/image/Makefile
index b744839e5b..8a40a1e6a9 100644
--- a/target/linux/bcm4908/image/Makefile
+++ b/target/linux/bcm4908/image/Makefile
@@ -3,14 +3,12 @@
 include $(TOPDIR)/rules.mk
 include $(INCLUDE_DIR)/image.mk
 
-define Build/bcm4908lzma
-   $(STAGING_DIR_HOST)/bin/lzma e -lc1 -lp2 -pb2 -d22 $@ $@.new
-   mv $@.new $@
-endef
+DEVICE_VARS += ASUS_PRODUCTID ASUS_BUILD_NO ASUS_FW_REV ASUS_EXT_NO
 
-define Build/bcm4908kernel
-   $(STAGING_DIR_HOST)/bin/bcm4908kernel -i $@ -o $@.new
-   mv $@.new $@
+define Build/bcm4908asus
+   $(STAGING_DIR_HOST)/bin/bcm4908asus create -i $@ \
+   -p $(ASUS_PRODUCTID) -b $(ASUS_BUILD_NO) -f $(ASUS_FW_REV) \
+   -e $(ASUS_EXT_NO)
 endef
 
 define Build/bcm4908img
@@ -22,16 +20,22 @@ define Build/bcm4908img
cp $(KDIR)/bcm63xx-cfe/$(subst _,$(comma),$(DEVICE_NAME))/cferam.000 
$@-bootfs/
cp $(IMAGE_KERNEL) $@-bootfs/vmlinux.lz
 
-   $(STAGING_DIR_HOST)/bin/mkfs.jffs2 --pad --little-endian --squash-uids 
-v -e 128KiB -o $@-bootfs.jffs2 -d $@-bootfs -m none -n
-   $(STAGING_DIR_HOST)/bin/bcm4908img create $@.new -f $@-bootfs.jffs2 -a 
0x2 -f $@
+   $(STAGING_DIR_HOST)/bin/mkfs.jffs2 --pad --little-endian --squash-uids \
+   -v -e 128KiB -o $@-bootfs.jffs2 -d $@-bootfs -m none -n
+   $(STAGING_DIR_HOST)/bin/bcm4908img create $@.new -f $@-bootfs.jffs2 \
+   -a 0x2 -f $@
mv $@.new $@
 endef
 
-define Build/bcm4908asus
-   $(STAGING_DIR_HOST)/bin/bcm4908asus create -i $@ -p $(ASUS_PRODUCTID) 
-b $(ASUS_BUILD_NO) -f $(ASUS_FW_REV) -e $(ASUS_EXT_NO)
+define Build/bcm4908kernel
+   $(STAGING_DIR_HOST)/bin/bcm4908kernel -i $@ -o $@.new
+   mv $@.new $@
 endef
 
-DEVICE_VARS += ASUS_PRODUCTID ASUS_BUILD_NO ASUS_FW_REV ASUS_EXT_NO
+define Build/bcm4908lzma
+   $(STAGING_DIR_HOST)/bin/lzma e -lc1 -lp2 -pb2 -d22 $@ $@.new
+   mv $@.new $@
+endef
 
 define Device/Default
   KERNEL := kernel-bin | bcm4908lzma | bcm4908kernel
-- 
2.20.1


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

[PATCH v2 2/2] bcm4908: automatically set DEVICE_DTS from device name

[Adrian Schmutzler]

This sets the DTS paths automatically based on their device definition
name. Devices where this is not possible may still be served by simply
overwriting DEVICE_DTS in their respective definition.

Cc: Rafał Miłecki 

Signed-off-by: Adrian Schmutzler 

---
Changes in v2:
- rebase
---
 target/linux/bcm4908/image/Makefile | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/target/linux/bcm4908/image/Makefile 
b/target/linux/bcm4908/image/Makefile
index 8a40a1e6a9..559f60faf1 100644
--- a/target/linux/bcm4908/image/Makefile
+++ b/target/linux/bcm4908/image/Makefile
@@ -37,6 +37,8 @@ define Build/bcm4908lzma
mv $@.new $@
 endef
 
+DTS_DIR := $(DTS_DIR)/broadcom/bcm4908
+
 define Device/Default
   KERNEL := kernel-bin | bcm4908lzma | bcm4908kernel
   KERNEL_DEPENDS = $$(wildcard $(DTS_DIR)/$$(DEVICE_DTS).dts)
@@ -44,15 +46,16 @@ define Device/Default
   KERNEL_INITRAMFS := kernel-bin | bcm4908lzma | bcm4908kernel
   FILESYSTEMS := squashfs
   KERNEL_NAME := Image
+  DEVICE_DTS = $$(SOC)-$(subst _,-,$(1))
   IMAGE_NAME = $$(IMAGE_PREFIX)-$$(1).$$(2)
   BLOCKSIZE := 128k
   PAGESIZE := 2048
 endef
 
 define Device/asus_gt-ac5300
+  SOC := bcm4908
   DEVICE_VENDOR := Asus
   DEVICE_MODEL := GT-AC5300
-  DEVICE_DTS := broadcom/bcm4908/bcm4908-asus-gt-ac5300
   IMAGES := bin
   IMAGE/bin := append-ubi | bcm4908img | bcm4908asus
   ASUS_PRODUCTID := GT-AC5300
@@ -63,9 +66,9 @@ endef
 TARGET_DEVICES += asus_gt-ac5300
 
 define Device/netgear_r8000p
+  SOC := bcm4906
   DEVICE_VENDOR := Netgear
   DEVICE_MODEL := R8000P
-  DEVICE_DTS := broadcom/bcm4908/bcm4906-netgear-r8000p
   IMAGES := bin
   IMAGE/bin := append-ubi | bcm4908img
 endef
-- 
2.20.1


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

RE: [PATCH 2/2] ath79: add support for Ubiquiti UniFi AP Outdoor+

[Adrian Schmutzler]

Hi,

two comments below.

> + leds {
> + compatible = "gpio-leds";
> +
> + led_white: white {
> + label = "blue";
> + gpios = < 0 GPIO_ACTIVE_HIGH>;
> + };
> +
> + blue {
> + label = "white";
> + gpios = < 1 GPIO_ACTIVE_HIGH>;
> + };

Labels and nodes are swapped?

[...]

> --- a/target/linux/ath79/image/generic-ubnt.mk
> +++ b/target/linux/ath79/image/generic-ubnt.mk
> @@ -120,6 +120,18 @@ define Device/ubnt-xw
>UBNT_VERSION := 6.0.4
>  endef
> 
> +define Device/ubnt-unifi-jffs2
> +  $(Device/ubnt)
> +  KERNEL_SIZE := 3072k
> +  IMAGE_SIZE := 15744k
> +  UBNT_TYPE := BZ
> +  KERNEL := kernel-bin | append-dtb | lzma | uImage lzma | jffs2
> +kernel0
> +  IMAGES := sysupgrade.bin factory.bin
> +  IMAGE/sysupgrade.bin := append-kernel | pad-to (KERNEL_SIZE) |
> append-rootfs |\
> + pad-rootfs | append-metadata | check-size
> +  IMAGE/factory.bin := $$(IMAGE/sysupgrade.bin) | mkubntimage2 endef
> +
>  define Device/ubnt-acb
>$(Device/ubnt)
>IMAGE_SIZE := 15744k
> @@ -420,19 +432,19 @@ define Device/ubnt_unifiac-pro  endef
> TARGET_DEVICES += ubnt_unifiac-pro
> 
> +define Device/ubnt_unifi-ap-outdoor-plus
> +  $(Device/ubnt-bz)
> +  $(Device/ubnt-unifi-jffs2)

I found it rather confusing to mix these two includes here. I'd personally 
prefer to just use ubnt-unifi-jffs2 here (like for the ap-pro) and add the 
other few surviving variables from ubnt-bz here directly. This is also more 
consistent with ap-pro and should thus be quicker to grasp ...

Best

Adrian

> +  DEVICE_MODEL := UniFi AP Outdoor+
> +  SUPPORTED_DEVICES += unifi-outdoor-plus endef TARGET_DEVICES +=
> +ubnt_unifi-ap-outdoor-plus
> +
>  define Device/ubnt_unifi-ap-pro
> +  $(Device/ubnt-unifi-jffs2)
>SOC := ar9344
> -  DEVICE_VENDOR := Ubiquiti
>DEVICE_MODEL := UniFi AP Pro
> -  UBNT_TYPE := BZ
>UBNT_CHIP := ar934x
> -  KERNEL_SIZE := 3072k
> -  IMAGE_SIZE := 15744k
> -  KERNEL := kernel-bin | append-dtb | lzma | uImage lzma | jffs2 kernel0
> -  IMAGES := sysupgrade.bin factory.bin
> -  IMAGE/sysupgrade.bin := append-kernel | pad-to (KERNEL_SIZE) |
> append-rootfs |\
> - pad-rootfs | append-metadata | check-size
> -  IMAGE/factory.bin := $$(IMAGE/sysupgrade.bin) | mkubntimage2
>SUPPORTED_DEVICES += uap-pro
>  endef
>  TARGET_DEVICES += ubnt_unifi-ap-pro
> --
> 2.30.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: Job board support on openwrt.org?

[Paul Spooren]

On Sa, Jan 23, 2021 at 07:25, Alberto Bursi  
wrote:



On 22/01/21 20:03, Daniel Golle wrote:

Hi Philip,

On Fri, Jan 22, 2021 at 11:23:42AM -0700, Philip Prindeville wrote:

Hi,

Is anyone interested in adding a page to the openwrt.org site about 
developers willing to do commercial work?


It could be as simple as:

* name
* email address
* mobile (if wanted)
* packages/platforms/architectures you maintain or have competence 
in
* whether you're available full-time, part-time, or currently 
unavailable


Might be useful for matching up devs with work.


While I like the idea and would probably benefit from it myself, I'm
a bit sceptical when it comes to making OpenWrt.org an institution
certifying developers. Too much trouble was caused over having
'@openwrt.org' addresses and I doubt we are able to handle the
moderation needs (think: classic fraud, fishing, ...) of such a thing
if it is even a wiki, ie. free to edit for all.


the site/wiki has user-restricted pages already (the front page, the 
releases page and personal developer pages I think, probably more) 
because otherwise it would be a field day for spambots.
So this would not be a "free to edit for all", and more of a "ask a 
wiki admin to add your data to the page".
I and Tmomas won't be able to do a through vetting process on 
anybody, but we are more than enough to stop basic spammers and such, 
and can also respond to complaints and remove somebody in case issues 
arise later.
I'm also thinking about having some rules of thumb to limit access to 
people that have actually been involved in OpenWrt for a bit and can 
prove it (some relevant commits, some useful mail in the list, a core 
developer vouching for them, whatever).


-Alberto


I'm generally pro this but before this gets implemented (and after 
sufficiently discussed) please start a vote.




Things like a wiki with only volunteer moderation somehow work 
because

there is little to no commercial interest in manipulation and it is
usually easy to recognize (ie. classic spam). In the moment that we
change that, we have to be prepared to also face a different quality
of manipulation attempts.

Just my 2 cents...



Just an idea to help our community prosper.

Thanks,

-Philip


___
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




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

[PATCH 1/2] realtek: use vendor-specific magic for ZyXEL

[Bjørn Mork]

The stock firmware of the ZyXEL GS1900 series use a non-standard
u-image magic.  This is not enforced by the stock u-boot, which is
why we could boot images with the default magic.  The flash
management application of the stock firmware will however verify
the magic, and refuse any image with another value.

Convert to vendor-specific value to get flash management support
in stock firmware, including the ability to upgrade to OpenWrt
directly from stock web UI.

Signed-off-by: Bjørn Mork 
---
 target/linux/realtek/dts/rtl8380_zyxel_gs1900.dtsi | 3 ++-
 target/linux/realtek/image/Makefile| 3 +++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/target/linux/realtek/dts/rtl8380_zyxel_gs1900.dtsi 
b/target/linux/realtek/dts/rtl8380_zyxel_gs1900.dtsi
index 5f06339d13bf..c4441ec30eef 100644
--- a/target/linux/realtek/dts/rtl8380_zyxel_gs1900.dtsi
+++ b/target/linux/realtek/dts/rtl8380_zyxel_gs1900.dtsi
@@ -92,7 +92,8 @@
partition@b26 {
label = "firmware";
reg = <0x26 0x6d>;
-   compatible = "denx,uimage";
+   compatible = "openwrt,uimage", "denx,uimage";
+   openwrt,ih-magic = <0x8380>;
};
partition@93 {
label = "runtime2";
diff --git a/target/linux/realtek/image/Makefile 
b/target/linux/realtek/image/Makefile
index 1251b47c933d..c0ae8be36d98 100644
--- a/target/linux/realtek/image/Makefile
+++ b/target/linux/realtek/image/Makefile
@@ -70,6 +70,7 @@ define Device/zyxel_gs1900-10hp
   IMAGE_SIZE := 6976k
   DEVICE_VENDOR := ZyXEL
   DEVICE_MODEL := GS1900-10HP
+  UIMAGE_MAGIC := 0x8380
 endef
 TARGET_DEVICES += zyxel_gs1900-10hp
 
@@ -80,6 +81,7 @@ define Device/zyxel_gs1900-8hp-v1
   DEVICE_MODEL := GS1900-8HP
   DEVICE_VARIANT := v1
   DEVICE_PACKAGES += lua-rs232
+  UIMAGE_MAGIC := 0x8380
 endef
 TARGET_DEVICES += zyxel_gs1900-8hp-v1
 
@@ -90,6 +92,7 @@ define Device/zyxel_gs1900-8hp-v2
   DEVICE_MODEL := GS1900-8HP
   DEVICE_VARIANT := v2
   DEVICE_PACKAGES += lua-rs232
+  UIMAGE_MAGIC := 0x8380
 endef
 TARGET_DEVICES += zyxel_gs1900-8hp-v2
 
-- 
2.20.1


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

[PATCH 2/2] realtek: build ZyXEL vendor firmware compatible initramfs

[Bjørn Mork]

Append a device specific version trailer used by the stock
firmware upgrade application to validate firmwares.

The trailer contains a list of ZyXEL firmware version
numbers, which includes a four letter hardware identifier.
The stock web UI requires that the current hardware matches
one of the listed versions, and that the version number is
larger than a model specific minimum value. The minimum
version varies between V1.00 and V2.60 for the currently
known GS1900 models. The number is not used anywhere else
to our knowlege, and has no direct relation to the version
info in the u-image header.  We can therefore use an
arbitrary value larger than V2.60.

The stock firmware upgrade application will only load and
flash the part of the file specified in the u-image header,
regardless of file size.  It can therefore not be used to
flash images with an appended rootfs. There is therefore no
need to include the trailer in other images than the
initramfs. This prevents accidentally bricking by attempts
to flash other images from the stock web UI.

Stock images support all models in the series, listing
all of them in the version trailer.  OpenWrt provide model
specific images.  We therefore only list the single supported
hardware identifier for each image.  This eliminates the risk
of flashing the wrong OpenWrt image from stock web UI.

OpenWrt can be installed from stock firmware in two steps:

   1) flash OpenWrt initramfs image from stock web gui
   2) boot OpenWrt and sysupgrade to a squasfs image

The OpenWrt squashfs image depends on a static partition
map in the DTS.  It can only be installed to the "firmware"
partition.  This partition is labeled "RUNTIME1" in u-boot
and in stock firmware, and is referred to as "image 0" in
the stock flash management tool.  The OpenWrt initramfs
can be installed and run from either partitions. But if
you want to keep stock irmware in the spare system partition,
then you must make sure stock firmware is installed to the
"RUNTIME2" partition referred to as "image 1" in the stock
web UI. And the initial OpenWrt initramfs must be flashed
to "RUNTIME1"/"image 0".

The stock flash management application supports direct
selection of both which partition to flash and which
partition to boot next.  This allows software controlled
"dual-boot" between OpenWrt and stock firmware, without
using console access to u-boot. u-boot use the "bootpartition"
variable stored in the second u-boot environment to select
which of the two system partitions to boot.  This variable
is set by the stock flash management application, by direct
user input.  It can also be set in OpenWrt using e.g

 fw_setsys bootpartition 1

to select "RUNTIME2"/"image 1" as default, assuming a
stock firmware version is installed in that partition.

Signed-off-by: Bjørn Mork 
---
 target/linux/realtek/image/Makefile | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/target/linux/realtek/image/Makefile 
b/target/linux/realtek/image/Makefile
index c0ae8be36d98..e1716a95a571 100644
--- a/target/linux/realtek/image/Makefile
+++ b/target/linux/realtek/image/Makefile
@@ -7,6 +7,14 @@ include $(INCLUDE_DIR)/image.mk
 KERNEL_LOADADDR = 0x8000
 KERNEL_ENTRY = 0x8400
 
+define Build/zyxel-vers
+   ( echo VERS;\
+   for hw in $(1); do\
+   echo -n "V9.99($$hw.0) | ";\
+   date -d @$(SOURCE_DATE_EPOCH) +%m/%d/%Y;\
+   done ) >> $@
+endef
+
 define Device/Default
   PROFILES = Default
   KERNEL := kernel-bin | append-dtb | gzip | uImage gzip
@@ -71,6 +79,7 @@ define Device/zyxel_gs1900-10hp
   DEVICE_VENDOR := ZyXEL
   DEVICE_MODEL := GS1900-10HP
   UIMAGE_MAGIC := 0x8380
+  KERNEL_INITRAMFS := kernel-bin | append-dtb | gzip | zyxel-vers AAZI | 
uImage gzip
 endef
 TARGET_DEVICES += zyxel_gs1900-10hp
 
@@ -82,6 +91,7 @@ define Device/zyxel_gs1900-8hp-v1
   DEVICE_VARIANT := v1
   DEVICE_PACKAGES += lua-rs232
   UIMAGE_MAGIC := 0x8380
+  KERNEL_INITRAMFS := kernel-bin | append-dtb | gzip | zyxel-vers AAHI | 
uImage gzip
 endef
 TARGET_DEVICES += zyxel_gs1900-8hp-v1
 
@@ -93,6 +103,7 @@ define Device/zyxel_gs1900-8hp-v2
   DEVICE_VARIANT := v2
   DEVICE_PACKAGES += lua-rs232
   UIMAGE_MAGIC := 0x8380
+  KERNEL_INITRAMFS := kernel-bin | append-dtb | gzip | zyxel-vers AAHI | 
uImage gzip
 endef
 TARGET_DEVICES += zyxel_gs1900-8hp-v2
 
-- 
2.20.1


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

[PATCH 0/2] realtek: support OpenWrt flashing from ZyXEL firmware

[Bjørn Mork]

Only two minor changes is required to make our initramfs image
flashable from stock web UI.  This allows upgrades to OpenWrt
without using console access.

In theory, the u-image magic could be different for the
initramfs and the squashfs image, since it is not validated by
u-boot and the stock web UI does not allow direct flashing of
squasfs images. But this would be unnecessarily confusing. It
would also prevent an installed OpenWrt squasfs image from being
recognized by the stock flash management application.

So this patchset uses the new mtdsplit_uimage configurability
to allow the vendor specific magic used by stock images for
these devices.

These patches are only build tested for now. An earlier version
has been thoroughly run tested with flashing from stock web UI.
But my GS1900-10HP is currently in use for my path to the
Internet, so testing on it is a bit inconvient.  I am therefore
leaning on other brave testers as usual...


Bjørn


Bjørn Mork (2):
  realtek: use vendor-specific magic for ZyXEL
  realtek: build ZyXEL vendor firmware compatible initramfs

 target/linux/realtek/dts/rtl8380_zyxel_gs1900.dtsi |  3 ++-
 target/linux/realtek/image/Makefile| 14 ++
 2 files changed, 16 insertions(+), 1 deletion(-)

-- 
2.20.1


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