[PATCH] ramips: add support for GL.iNet GL-MT1300
From: Xinfa Deng
The GL-MT1300 is a high-performance new generation pocket-sized router
that offers a powerful hardware and first-class cybersecurity protocol
with unique and modern design.
Specifications:
- SoC: MT7621A, Dual-Core @880MHz
- RAM: 256 MB DDR3
- Flash: 32 MB
- Ethernet: 3 x 10/100/1000: 2 x LAN + 1 x WAN
- Wireless: 1 x MT7615D Dual-Band 2.4GHz(400Mbps) + 5GHz(867Mbps)
- USB: 1 x USB 3.0 port
- Slot: 1 x MicroSD card slot
- Button: 1 x Reset button
- Switch: 1 x Mode switch
- LED: 1 x Blue LED + 1 x White LED
MAC addresses based on vendor firmware:
WAN : factory 0x4000
LAN : Mac from factory 0x4000 + 1
2.4GHz : factory 0x4
5GHz : Mac form factory 0x4 + 1
Flashing instructions:
1.Connect to one of LAN ports.
2.Set the static IP on the PC to 192.168.1.2.
3.Press the Reset button and power the device (do not release the button).
After waiting for the blue led to flash 5 times, the white led will
come on and release the button.
4.Browse the 192.168.1.1 web page and update firmware according to web
tips.
5.The blue led will flash when the firmware is being upgraded.
6.The blue led stops blinking to indicate that the firmware upgrade is
complete and U-Boot automatically starts the firmware.
For more information on GL-MT1300, see the OFFICIAL GL.iNet website:
https://www.gl-inet.com/products/gl-mt1300/
Signed-off-by: Xinfa Deng
---
.../linux/ramips/dts/mt7621_glinet_gl-mt1300.dts | 150 +
target/linux/ramips/image/mt7621.mk| 9 ++
.../mt7621/base-files/etc/board.d/02_network | 1 +
.../etc/hotplug.d/ieee80211/10_fix_wifi_mac| 3 +
4 files changed, 163 insertions(+)
create mode 100644 target/linux/ramips/dts/mt7621_glinet_gl-mt1300.dts
diff --git a/target/linux/ramips/dts/mt7621_glinet_gl-mt1300.dts
b/target/linux/ramips/dts/mt7621_glinet_gl-mt1300.dts
new file mode 100644
index 000..8762e4c
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_glinet_gl-mt1300.dts
@@ -0,0 +1,150 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "mt7621.dtsi"
+
+#include
+#include
+
+/ {
+ compatible = "glinet,gl-mt1300", "mediatek,mt7621-soc";
+ model = "GL.iNet GL-MT1300";
+
+ aliases {
+ led-boot = &led_run;
+ led-failsafe = &led_run;
+ led-running = &led_run;
+ led-upgrade = &led_run;
+ label-mac-device = &wan;
+ };
+
+ chosen {
+ bootargs = "console=ttyS0,115200";
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ reset {
+ label = "reset";
+ gpios = <&gpio 18 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+
+ switch {
+ label = "switch";
+ gpios = <&gpio 16 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led_run: run {
+ label = "blue:run";
+ gpios = <&gpio 14 GPIO_ACTIVE_HIGH>;
+ };
+
+ system {
+ label = "white:system";
+ gpios = <&gpio 13 GPIO_ACTIVE_HIGH>;
+ };
+ };
+};
+
+&i2c {
+ status = "okay";
+};
+
+&sdhci {
+ status = "okay";
+};
+
+&spi0 {
+ status = "okay";
+
+ flash@0 {
+ compatible = "mx25l25635f", "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <8000>;
+ m25p,fast-read;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "u-boot";
+ reg = <0x0 0x3>;
+ read-only;
+ };
+
+ partition@3 {
+ label = "u-boot-env";
+ reg = <0x3 0x1>;
+ read-only;
+ };
+
+ factory: partition@4 {
+ label = "factory";
+ reg = <0x4 0x1>;
+ read-only;
+ };
+
+ partition@5 {
+ compatible = "denx,uimage";
+ label = "firmware";
+ reg = <0x5 0x1fb>;
+ };
+ };
+ };
+};
+
+&pcie {
+ status = "okay";
+};
+
+&pcie0 {
+ wifi@0,0 {
+ compatible = "mediatek,mt76";
+ reg = <0x 0 0 0 0>;
+ mediatek,mtd-eeprom = <&factory 0x0>;
+ };
Re: Bind + ISC dhcpd integration (for intranet split-horizon, etc)
Philip Prindeville writes:
>> On Dec 15, 2020, at 1:22 AM, Bjørn Mork wrote:
>>
>> Philip Prindeville writes:
>>
>>> I’m trying to do the integration “glue” to allow one to operate a DNS
>>> private zone inside your intranet (aka “split horizon”) and prime it
>>> with both static data as well as DHCP lease information.
>>
>> “split horizon” is a very bad idea, and should not be encouraged.
>
>
> Can you say more about that?
It breaks the basic DNS premise: There is one distributed database.
The fallout is broken DNSSEC, lame delegations, failing services, broken
caches etc. Most of these are results of the added operational
complexity. Feeble attempts to simplify split DNS also often involve
breaking best practices, like having authoritative servers in more than
one AS.
All this might have been acceptable if it solved a real problem. It
doesn't.
> I don’t see why the converse would be any better, i.e. publishing
> RFC-1918 addresses of NATted hosts behind a firewall,
This is not a problem. There is nothing special about RFC 1918, or any
other, addresses in DNS. DNS replies comes without any guarantee about
firewalls, routing or provided public services. Software which assumes
otherwise is buggy, with very few exceptions.
The classic example of such bugs is the claimed "rebind protection" in
dnsmasq. Which
a) breaks valid configurations
b) doesn't do rebind protection
> and disclosing more information than is necessary anyway…
I realize this is important to some. But split DNS will not protect
this information. You should not put anything you don't want to
disclose in DNS.
> See here:
>
> https://github.com/openwrt/packages/pull/14233
Huh? Can't find anything related to dynamic DNS in either BIND or ISC
dhcp there?
> Well, doing an RTFM I see:
>
> The ddns-update-style parameter
>
> ddns-update-style style;
>
> The style parameter must be one of ad-hoc, interim or none. The
> ddns-update-style statement is only meaningful in the outer scope
> - it is evaluated once after reading the dhcpd.conf file, rather
> than each time a client is assigned an IP address, so there is no
> way to use different DNS update styles for different clients. The
> default is none.
My manual says
ddns-update-style style;
The style parameter must be one of standard, interim or
none. The ddns-update-style statement is only meaningful in
the outer scope - it is evaluated once after reading the
dhcpd.conf file, rather than each time a client is assigned
an IP address, so there is no way to use different DNS
update styles for different clients. The default is none.
The "standard" style was introduced in commit d7d9c0c7c36d ("-n [master]
Add code to support the standards version of DDNS") in 2013. It was
released with version 4.3 in 2014.
Bjørn
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCHv2] ath79: Add support for Ubiquiti Bullet AC
CPU: Atheros AR9342 rev 3 SoC
RAM: 64 MB DDR2
Flash: 16 MB NOR SPI
WLAN 2.4GHz: Atheros AR9342 v3 (ath9k)
WLAN 5.0GHz: QCA988X
Ports: 1x GbE
Flashing procedure is identical to other ubnt devices.
https://openwrt.org/toh/ubiquiti/common
Flashing through factory firmware
1. Ensure firmware version v8.7.0 is installed.
Up/downgrade to this exact version.
2. Patch fwupdate.real binary using
`hexdump -Cv /bin/ubntbox | sed 's/14 40 fe 27/00 00 00 00/g' | \
hexdump -R > /tmp/fwupdate.real`
3. Make the patched fwupdate.real binary executable using
`chmod +x /tmp/fwupdate.real`
4. Copy the squashfs factory image to /tmp on the device
5. Flash OpenWrt using `/tmp/fwupdate.real -m `
6. Wait for the device to reboot
(copied from Ubiquiti NanoBeam AC and modified)
Flashing from serial console
1. Connect serial console (115200 baud)
2. Connect ethernet to a network with a TFTP server, through a
passive PoE injector.
3. Press a key to obtain a u-boot prompt
4. Set your TFTP server's ip address, with:
setenv serverip
5. Set the Bullet AC's ip address, with:
setenv ipaddr
6. Set the boot file, with:
setenv bootfile
7. Fetch the binary with tftp:
tftpboot
8. Boot the initramfs binary:
bootm
9. From the initramfs, fetch the sysupgrade binary, and flash it with
sysupgrade.
Phy0 is QCA988X which can tune either band (2.4 or 5GHz). Phy1 is AR9342,
on which 5GHz is disabled. It isn't currently known whether phy1 is
routed to the N connector at all.
Signed-off-by: Russell Senior
---
v2:
- Make "Flashing through factory firmware" instructions actually work by
changing UBNT_TYPE to 2WA
---
.../linux/ath79/dts/ar9342_ubnt_bullet-ac.dts | 38 +++
.../generic/base-files/etc/board.d/01_leds| 1 +
.../generic/base-files/etc/board.d/02_network | 1 +
.../etc/hotplug.d/firmware/11-ath10k-caldata | 1 +
target/linux/ath79/image/generic-ubnt.mk | 17 +
5 files changed, 58 insertions(+)
create mode 100644 target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
diff --git a/target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
b/target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
new file mode 100644
index 00..be0b0792bb
--- /dev/null
+++ b/target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
@@ -0,0 +1,38 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include "ar9342_ubnt_wa_1port.dtsi"
+
+/ {
+ compatible = "ubnt,bullet-ac", "ubnt,wa", "qca,ar9342";
+ model = "Ubiquiti Bullet AC (2WA)";
+
+ aliases {
+ led-boot = &led_rssi3;
+ led-failsafe = &led_rssi3;
+ led-upgrade = &led_rssi3;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ rssi0 {
+ label = "blue:rssi0";
+ gpios = <&gpio 11 GPIO_ACTIVE_LOW>;
+ };
+
+ rssi1 {
+ label = "blue:rssi1";
+ gpios = <&gpio 16 GPIO_ACTIVE_LOW>;
+ };
+
+ rssi2 {
+ label = "blue:rssi2";
+ gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
+ };
+
+ led_rssi3: rssi3 {
+ label = "blue:rssi3";
+ gpios = <&gpio 14 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
diff --git a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
index a0ed21e318..46d4650eac 100755
--- a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
+++ b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
@@ -366,6 +366,7 @@ ubnt,rocket-m)
ucidef_set_led_rssi "rssimediumhigh" "RSSIMEDIUMHIGH" "green:link3"
"wlan0" "51" "100"
ucidef_set_led_rssi "rssihigh" "RSSIHIGH" "green:link4" "wlan0" "76"
"100"
;;
+ubnt,bullet-ac|\
ubnt,nanobeam-ac|\
ubnt,nanobeam-ac-gen2|\
ubnt,nanostation-ac|\
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 905848a2ba..9293e5522b 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
@@ -58,6 +58,7 @@ ath79_setup_interfaces()
tplink,re450-v2|\
tplink,re450-v3|\
tplink,tl-wr902ac-v1|\
+ ubnt,bullet-ac|\
ubnt,bullet-m-ar7240|\
ubnt,bullet-m-ar7241|\
ubnt,bullet-m-xw|\
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 0d09cd3140..be62e52480 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-ath10k-caldata
@@ -26,6 +26,7 @@ case "$FIRMWARE" in
qxwlan,e1700ac-v2-16m|\
qxwlan,e600gac-v2-8m|\
Re: [PATCH] openssl: update to 1.1.1i
Hi! Op vrijdag 11 december 2020 om 8u39 schreef Eneas U de Queiroz : Fixes: CVE-2020-1971, defined as high severity, summarized as: NULL pointer deref in GENERAL_NAME_cmp function can lead to a DOS attack. Signed-off-by: Eneas U de Queiroz --- This was run-tested in a WRT-3200ACM Can this be backported to 19.O7? I cherry-picked it from master locally here, applies cleanly afaict. Thanks! Stijn diff --git a/package/libs/openssl/Makefile b/package/libs/openssl/Makefile index 77c6d41cec..714ce2059a 100644 --- a/package/libs/openssl/Makefile +++ b/package/libs/openssl/Makefile @@ -9,9 +9,9 @@ include $(TOPDIR)/rules.mk PKG_NAME:=openssl PKG_BASE:=1.1.1 -PKG_BUGFIX:=h +PKG_BUGFIX:=i PKG_VERSION:=$(PKG_BASE)$(PKG_BUGFIX) -PKG_RELEASE:=2 +PKG_RELEASE:=1 PKG_USE_MIPS16:=0 ENGINES_DIR=engines-1.1 @@ -24,7 +24,7 @@ PKG_SOURCE_URL:= \ ftp://ftp.pca.dfn.de/pub/tools/net/openssl/source/ \ http://www.openssl.org/source/ \ http://www.openssl.org/source/old/$(PKG_BASE)/ -PKG_HASH:=5c9ca8774bd7b03e5784f26ae9e9e6d749c9da2438545077e6b3d755a06595d9 +PKG_HASH:=e8be6a35fe41d10603c3cc635e93289ed00bf34b79671a3a4de64fcee00d5242 PKG_LICENSE:=OpenSSL PKG_LICENSE_FILES:=LICENSE ___ 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: [RFC] raise gcc/make versions for 20.x
On Wed, 16 Dec 2020 at 13:11, Petr Štetiar wrote: > > Paul Spooren [2020-12-15 16:26:14]: > > Hi, > > > I've seen two patches for version raises of build requirements and would > > like to know if we should merge them before or after 20.x. > > > > make: 3.81.x -> 4.1.x > > gcc: 4.8 -> 6.x > > > > I'm in favor to merge both *before* the branch. > > it would probably help to know the reason as well. "I'm in favor" might not be > enough in this almost pre-release stage. > > AFAIK that Make version bump fixes an issue with possibly few stray ANSI color > escapes (workaround is to use NO_COLOR=1 in this case) and \r characters in > the > log file. Is it really that big issue to do this last minute version bump? > > FYI that gcc6+ one was NACKed[1] by Yousong and I'm fine with that for 20.12 > release. I plan to rebase/resend that patch once 20.12 is branched. > > 1. > https://patchwork.ozlabs.org/project/openwrt/patch/20191112081625.27695-1-yn...@true.cz/#2301662 > I still hold the belief that a system such as CentOS could deserve a work-out-of-the-box experience ;) But now that CentOS like the old day is not an option anymore in the future, I say we move on in the next release. Regards, yousong ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] toolchain: gcc: Remove support for GCC 5
On 12/16/20 4:00 AM, Rosen Penev wrote: On Tue, Dec 15, 2020 at 5:14 PM Hauke Mehrtens wrote: On 12/16/20 1:21 AM, Paul Spooren wrote: On Mi, Dez 16, 2020 at 00:24, Hauke Mehrtens wrote: GCC was used in 17.01 as the default compiler the last time. We do not test this old GCC version any more and there are some known problems it fails to compile the U-Boot for the Allwinner A64 SoC. Just remove it to make it clear that we will not support this old GCC version any more. Signed-off-by: Hauke Mehrtens --- Acked-by: Paul Spooren This goes hand in hand with Petrs gcc6+ patches. I'm wondering if these major version requirement changes should happen before or after the 20.x change, I'd like the former. In do not want to support gcc 5 in the next major release and think we should remove this before branching. I am still unsure about gcc 7. Some packages in the packages feed do not build with GCC7. gerbera comes to mind (requires GCC8 because of C++17). Thanks for the information, I do not see this as a problem. The older compiler versions could be used to check if a problem also existed with the older compiler version, but if not everything compiles on the older versions this is fine with me. We switched to GCC 8 in October 2019, so more than a year ago, I do not expect there many regressions which we haven't found yet. 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: [RFC] raise gcc/make versions for 20.x
On 12/16/20 4:03 AM, Rosen Penev wrote: On Tue, Dec 15, 2020 at 6:31 PM Paul Spooren wrote: Hi, I've seen two patches for version raises of build requirements and would like to know if we should merge them before or after 20.x. make: 3.81.x -> 4.1.x gcc: 4.8 -> 6.x The issue is with EL7. That would break the ability to compile. No idea about the former in terms of bugs. In terms of the latter, there's a clang warning to fix the GCC 4.8 issue: -Werror=gnu-empty-initializer . Does OpenWrt master build with GCC 4.8 from RHEL 7 and we just see some additional warnings? If we see an error message could you please post it. 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: [PATCH v2 0/2] uboot-envtools: support for multiple config partitions
Hi Bjørn! Op zondag 13 december 2020 om 20u07 schreef Bjørn Mork : Changes since v1: - incremented PKG_RELEASE - using wrapper scripts instead of patching the tool Bjørn Mork (2): uboot-envtools: add support for multiple config partitions uboot-envtools: add wrapper scripts for alternate config package/boot/uboot-envtools/Makefile | 5 ++- package/boot/uboot-envtools/files/fw_printsys | 2 + package/boot/uboot-envtools/files/fw_setsys | 2 + package/boot/uboot-envtools/files/realtek | 8 +++- .../uboot-envtools/files/uboot-envtools.sh| 38 --- 5 files changed, 39 insertions(+), 16 deletions(-) create mode 100644 package/boot/uboot-envtools/files/fw_printsys create mode 100644 package/boot/uboot-envtools/files/fw_setsys -- 2.20.1 I'm giving this a spin (since I have a Realtek switch now :^) ). Fw_printenv prints info as expected but fw_printsys comes up empty. Not sure if this is expected behaviour. There's no /etc/fw_sys.config after installing the new uboot-envtools package (revision 10). # fw_printenv baudrate=115200 boardmodel=ZyXEL_GS1900_10HP bootargs=console=ttyS0,115200 mem=64M quiet bootcmd=cst fcTest; boota bootdelay=0 ethact=rtl8380#0 ethaddr=BC:CF:4F:74:3C:15 ipaddr=192.168.1.1 netmask=255.255.255.0 serverip=192.168.1.111 stderr=serial stdin=serial stdout=serial # fw_printsys # ls /etc/fw* /etc/fw_env.config Calling 'fw_setsys bootpartition 0' e.g. exits silently. No /etc/fw_sys.config gets created. When I create /etc/fw_sys.config manually then try to set a value again, it errors: # fw_setsys bootpartition 0 Cannot parse config file '/etc/fw_sys.config': Invalid argument Error: environment not initialized root@OpenWrt:~# ls /etc/fw_sys.config /etc/fw_sys.config # Cheers Stijn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 0/2] uboot-envtools: support for multiple config partitions
Stijn Segers writes: > I'm giving this a spin (since I have a Realtek switch now :^) Great! Thanks for testing > ). Fw_printenv prints info as expected but fw_printsys comes up > empty. Not sure if this is expected behaviour. There's no > /etc/fw_sys.config after installing the new uboot-envtools package > (revision 10). > > # fw_printenv > baudrate=115200 > boardmodel=ZyXEL_GS1900_10HP > bootargs=console=ttyS0,115200 mem=64M quiet > bootcmd=cst fcTest; boota > bootdelay=0 > ethact=rtl8380#0 > ethaddr=BC:CF:4F:74:3C:15 > ipaddr=192.168.1.1 > netmask=255.255.255.0 > serverip=192.168.1.111 > stderr=serial > stdin=serial > stdout=serial > # fw_printsys > # ls /etc/fw* > /etc/fw_env.config > > Calling 'fw_setsys bootpartition 0' e.g. exits silently. No > /etc/fw_sys.config gets created. The /etc/fw_sys.config is supposed to be created on first installation, just like the /etc/fw_env.config. I wasn't quite sure what to do in the wrapper if it doesn't exist. The wrapper cannot know if the config is supposed to be there or not. So the current version will just exit silently, as you've observed. Maybe not the best solution? I am open to ideas. Anyway, the config files will only be generated if /etc/config/ubootenv doesn't exist. If you installed to flash you can look at /rom/etc/uci-defaults/30_uboot-envtools The first line is "[ -e /etc/config/ubootenv ] && exit 0" This is how the package has been working all the time. It should probably be fixed. But I guess the assumption was that the environment partition config is a hardware property which will not change? > When I create /etc/fw_sys.config manually then try to set a value > again, it errors: > > # fw_setsys bootpartition 0 > Cannot parse config file '/etc/fw_sys.config': Invalid argument > Error: environment not initialized > root@OpenWrt:~# ls /etc/fw_sys.config > /etc/fw_sys.config > # > That's strange. What does the file look like? FWIW, here is mine from the same switch model: root@gs1900-10hp:/# cat /etc/fw_sys.config /dev/mtd2 0x0 0x1000 0x1 And it works: root@gs1900-10hp:/# fw_printsys resetdefault=0 mac_start=BC:CF:4F:D1:6B:32 mac_end=BC:CF:4F:D1:6B:3C sn=S202L28001735 dualfname1=2.60(AAZI.2)C0.bix dualfname0=x.bin bootpartition=0 This is my ubootenv (which is irrelevant as it isn't be used by anything after first install): root@gs1900-10hp:/# cat /etc/config/ubootenv config ubootenv option dev '/dev/mtd1' option offset '0x0' option envsize '0x400' option secsize '0x1' config ubootsys option dev '/dev/mtd2' option offset '0x0' option envsize '0x1000' option secsize '0x1' Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC] raise gcc/make versions for 20.x
Le mer. 16 déc. 2020 à 07:33, Yousong Zhou a écrit : > > On Wed, 16 Dec 2020 at 13:11, Petr Štetiar wrote: > > > > Paul Spooren [2020-12-15 16:26:14]: > > > > Hi, > > > > > I've seen two patches for version raises of build requirements and would > > > like to know if we should merge them before or after 20.x. > > > > > > make: 3.81.x -> 4.1.x > > > gcc: 4.8 -> 6.x > > > > > > I'm in favor to merge both *before* the branch. > > > > it would probably help to know the reason as well. "I'm in favor" might not > > be > > enough in this almost pre-release stage. > > > > AFAIK that Make version bump fixes an issue with possibly few stray ANSI > > color > > escapes (workaround is to use NO_COLOR=1 in this case) and \r characters in > > the > > log file. Is it really that big issue to do this last minute version bump? > > > > FYI that gcc6+ one was NACKed[1] by Yousong and I'm fine with that for 20.12 > > release. I plan to rebase/resend that patch once 20.12 is branched. > > > > 1. > > https://patchwork.ozlabs.org/project/openwrt/patch/20191112081625.27695-1-yn...@true.cz/#2301662 > > > > I still hold the belief that a system such as CentOS could deserve a > work-out-of-the-box experience ;) But now that CentOS like the old > day is not an option anymore in the future, I say we move on in the > next release. Why not just install devtoolset, up to date gcc supported by RedHat people ? Or use a build container ? There are a lot of options to not be stuck with a 7 years old version of GCC ;) Etienne > > Regards, > yousong ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH v2 1/2] uboot-envtools: add support for multiple config partitions
Hi, just a taste nitpick: > --- a/package/boot/uboot-envtools/files/realtek > +++ b/package/boot/uboot-envtools/files/realtek > @@ -15,15 +15,21 @@ zyxel,gs1900-10hp) > idx="$(find_mtd_index u-boot-env)" > [ -n "$idx" ] && \ > ubootenv_add_uci_config "/dev/mtd$idx" "0x0" "0x400" > "0x1" > + idx="$(find_mtd_index u-boot-env2)" > + [ -n "$idx" ] && \ > + ubootenv_add_uci_sys_config "/dev/mtd$idx" "0x0" I'd personally use a different variable name here, e.g. idx2, so it's clearly separated. BTW, if you only need the variable once, you can directly use logic on the assignment: + idx2="$(find_mtd_index u-boot-env2)" && + ubootenv_add_uci_sys_config "/dev/mtd$idx2" "0x0" 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] ramips: add support for GL.iNet GL-MT1300
Hi,
quick final question, answer via e-mail should be enough, I'll change at my
tree then:
> + switch {
> + label = "switch";
> + gpios = <&gpio 16 GPIO_ACTIVE_LOW>;
> + linux,code = ;
If this is a "switch", I probably should add
linux,input-type = ;
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: [PATCH v2 2/2] ath79: airtight c-75: use second flash chip
Hi again,
one comment and a slightly conceptual question:
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Tomasz Maciej Nowak
> Sent: Dienstag, 15. Dezember 2020 18:17
> To: openwrt-devel@lists.openwrt.org
> Cc: Vladimir Georgievsky
> Subject: [PATCH v2 2/2] ath79: airtight c-75: use second flash chip
>
> The flash capacity is divided in two flash chips and currently only first is
> used.
> Increase available space for OpenWrt by additional 16 MiB using mtd-concat
> driver. Because U-Boot might not be able to load kernel image spanned
> through two flash chips, the size of kernel is limited to space available on
> first
> chip.
>
> Cc: Vladimir Georgievsky
> Signed-off-by: Tomasz Maciej Nowak
> ---
> v1 -> v2
>
> - add kernel size constraints
>
> .../linux/ath79/dts/qca9550_airtight_c-75.dts | 24 +++
> target/linux/ath79/image/generic.mk | 3 ++-
> 2 files changed, 21 insertions(+), 6 deletions(-)
>
> diff --git a/target/linux/ath79/dts/qca9550_airtight_c-75.dts
> b/target/linux/ath79/dts/qca9550_airtight_c-75.dts
> index 34d4c32b3562..c380a109c96b 100644
> --- a/target/linux/ath79/dts/qca9550_airtight_c-75.dts
> +++ b/target/linux/ath79/dts/qca9550_airtight_c-75.dts
> @@ -41,6 +41,23 @@
> linux,default-trigger = "phy1tpt";
> };
> };
> +
> + mtd-concat {
I think I will change the node name to virtual_flash, as that's the most common
case so far and I personally like it more.
> + compatible = "mtd-concat";
> + devices = <&concat0 &concat1>;
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition@0 {
> + label = "firmware";
> + reg = <0x0 0x1f9>;
> + compatible = "denx,uimage";
> + };
> + };
> + };
> };
>
> ð0 {
> @@ -120,10 +137,8 @@
> read-only;
> };
>
> - partition@6 {
> - label = "firmware";
> + concat0: partition@6 {
> reg = <0x06 0xf9>;
> - compatible = "denx,uimage";
> };
>
> art: partition@ff {
> @@ -144,8 +159,7 @@
> #address-cells = <1>;
> #size-cells = <1>;
>
> - partition@0 {
> - label = "opt";
I wonder what's best practice here:
Many devices keep a label here and just use names like "firmware1", "firmware2"
or similar.
Does it make sense to keep the concatenated partitions available under such a
name (because the user might want to do something with it) or would it be
better to remove the label and thus "hide" the partition (because the user
might want to do something with it)?
Best
Adrian
> + concat1: partition@0 {
> reg = <0x0 0x100>;
> };
> };
> diff --git a/target/linux/ath79/image/generic.mk
> b/target/linux/ath79/image/generic.mk
> index 177caafa2253..bdc35823c66c 100644
> --- a/target/linux/ath79/image/generic.mk
> +++ b/target/linux/ath79/image/generic.mk
> @@ -246,7 +246,8 @@ define Device/airtight_c-75
>DEVICE_ALT1_VENDOR := WatchGuard
>DEVICE_ALT1_MODEL := AP320
>DEVICE_PACKAGES := ath10k-firmware-qca988x kmod-ath10k-ct kmod-
> usb2
> - IMAGE_SIZE := 15936k
> + IMAGE_SIZE := 32320k
> + KERNEL_SIZE := 15936k
> endef
> TARGET_DEVICES += airtight_c-75
>
> --
> 2.29.2
>
>
> ___
> 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 1/2] ath79: add support for AirTight C-75
Hi,
a few last-minute remarks. I plan to merge this afterwards.
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Tomasz Maciej Nowak
> Sent: Dienstag, 15. Dezember 2020 18:17
> To: openwrt-devel@lists.openwrt.org
> Cc: Vladimir Georgievsky
> Subject: [PATCH v2 1/2] ath79: add support for AirTight C-75
>
> AirTight Networks (later renamed to Mojo Networks) C-75 is a dual-band
> access point, also sold by WatchGuard under name AP320.
>
> Specification
> SoC: Qualcomm Atheros QCA9550
> RAM: 128 MiB DDR2
> Flash: 2x 16 MiB SPI NOR
> WIFI: 2.4 GHz 3T3R integrated
> 5 GHz 3T3R QCA9890 oversized Mini PCIe card
> Ethernet: 2x 10/100/1000 Mbps QCA8334
> port labeled LAN1 is PoE capable (802.3at)
> USB: 1x 2.0
> LEDs: 7x which two are GPIO controlled, four switch controlled, one
> controlled by wireless driver
> Buttons: 1x GPIO controlled
> Serial: RJ-45 port, Cisco pinout
> baud: 115200, parity: none, flow control: none
> JTAG: Yes, pins marked J1 on PCB
>
> Installation
> 1. Prepare TFTP server with OpenWrt initramfs-kernel image.
> 2. Connect to one of LAN ports.
> 3. Connect to serial port.
> 4. Power on the device and when prompted to stop autoboot, hit any key.
> 5. Adjust "ipaddr" and "serverip" addresses in U-Boot environment, use
>'setenv' to do that, then run following commands:
> tftpboot 0x8100
> bootm 0x8100
> 6. Wait about 1 minute for OpenWrt to boot.
> 7. Transfer OpenWrt sysupgrade image to /tmp directory and flash it
>with:
> sysupgrade -n /tmp/
> 8. After flashing, the access point will reboot to OpenWrt. Wait few
>minutes, until the Power LED stops blinking, then it's ready for
>configuration.
>
> Known issues
> Green power LED does not work.
>
> Additional information
> The U-Boot fails to initialise ethernet ports correctly when a UART adapter is
> attached to UART pins (marked J3 on PCB).
>
> Cc: Vladimir Georgievsky
> Signed-of-by: Tomasz Maciej Nowak
> ---
> v1 -> v2
>
> - rename primary device vendor (Mojo -> AirTight)
> - remove U-Boot environment definition
> - minor dts adjustments (no functional changes)
> - add additional DEVICE_ALTn variable
>
> .../linux/ath79/dts/qca9550_airtight_c-75.dts | 171 ++
> .../generic/base-files/etc/board.d/02_network | 4 +
> target/linux/ath79/image/generic.mk | 13 ++
> 3 files changed, 188 insertions(+)
> create mode 100644 target/linux/ath79/dts/qca9550_airtight_c-75.dts
>
> diff --git a/target/linux/ath79/dts/qca9550_airtight_c-75.dts
> b/target/linux/ath79/dts/qca9550_airtight_c-75.dts
> new file mode 100644
> index ..34d4c32b3562
> --- /dev/null
> +++ b/target/linux/ath79/dts/qca9550_airtight_c-75.dts
> @@ -0,0 +1,171 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +
> +#include "qca955x.dtsi"
> +
> +#include
> +#include
> +
> +/ {
> + model = "AirTight Networks C-75";
> + compatible = "airtight,c-75", "qca,qca9550", "qca,qca9558";
> +
> + aliases {
> + label-mac-device = ð0;
> + led-boot = &led_power;
> + led-failsafe = &led_power;
> + led-upgrade = &led_power;
> + };
> +
> + keys {
> + compatible = "gpio-keys";
> +
> + reset {
> + label = "reset";
> + linux,code = ;
> + gpios = <&gpio 17 GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led_power: power {
> + label = "amber:power";
> + gpios = <&gpio 14 GPIO_ACTIVE_HIGH>;
> + default-state = "on";
> + };
> +
> + wlan2g {
> + label = "green:wlan2g";
> + gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
> + linux,default-trigger = "phy1tpt";
> + };
> + };
> +};
> +
> +ð0 {
> + status = "okay";
> +
> + mtd-mac-address = <&art 0x0>;
> + phy-handle = <&phy0>;
> + phy-mode = "rgmii";
phy-mode is already set in qca955x.dtsi and can be removed here.
> + pll-data = <0xa600 0x0101 0x1616>; };
> +
> +&mdio0 {
> + status = "okay";
> +
> + phy0: ethernet-phy@0 {
> + reg = <0>;
> + qca,ar8327-initvals = <
> + 0x0c 0x00080080
> + 0x04 0x0760
> + 0x58 0xc935c935
> + 0x5c 0x0300
> + 0x7c 0x007e
> + 0x94 0x007e
> + >;
Please add comments here to help the reader, like other devices do, e.g.:
qca,ar8327-initvals = <
0x04 0x8760 /* PORT0 PAD MODE CTRL */
0x0c 0x00080080 /* PORT6 PAD MODE CTRL */
0x7c 0x007e /* PORT0_STATUS */
RE: [PATCHv2] ath79: Add support for Ubiquiti Bullet AC
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Russell Senior
> Sent: Mittwoch, 16. Dezember 2020 12:01
> To: openwrt-devel@lists.openwrt.org
> Subject: [PATCHv2] ath79: Add support for Ubiquiti Bullet AC
>
>
> CPU: Atheros AR9342 rev 3 SoC
> RAM: 64 MB DDR2
> Flash: 16 MB NOR SPI
> WLAN 2.4GHz: Atheros AR9342 v3 (ath9k)
> WLAN 5.0GHz: QCA988X
> Ports: 1x GbE
>
> Flashing procedure is identical to other ubnt devices.
> https://openwrt.org/toh/ubiquiti/common
>
> Flashing through factory firmware
> 1. Ensure firmware version v8.7.0 is installed.
>Up/downgrade to this exact version.
> 2. Patch fwupdate.real binary using
>`hexdump -Cv /bin/ubntbox | sed 's/14 40 fe 27/00 00 00 00/g' | \
> hexdump -R > /tmp/fwupdate.real`
> 3. Make the patched fwupdate.real binary executable using
>`chmod +x /tmp/fwupdate.real`
> 4. Copy the squashfs factory image to /tmp on the device 5. Flash OpenWrt
> using `/tmp/fwupdate.real -m ` 6. Wait for the
> device to reboot (copied from Ubiquiti NanoBeam AC and modified)
>
> Flashing from serial console
> 1. Connect serial console (115200 baud)
> 2. Connect ethernet to a network with a TFTP server, through a
>passive PoE injector.
> 3. Press a key to obtain a u-boot prompt 4. Set your TFTP server's ip address,
> with:
>setenv serverip 5. Set the Bullet AC's ip address,
> with:
>setenv ipaddr
> 6. Set the boot file, with:
>setenv bootfile
> 7. Fetch the binary with tftp:
>tftpboot
> 8. Boot the initramfs binary:
>bootm
> 9. From the initramfs, fetch the sysupgrade binary, and flash it with
>sysupgrade.
>
> Phy0 is QCA988X which can tune either band (2.4 or 5GHz). Phy1 is AR9342,
> on which 5GHz is disabled. It isn't currently known whether phy1 is routed to
> the N connector at all.
>
> Signed-off-by: Russell Senior
> ---
> v2:
> - Make "Flashing through factory firmware" instructions actually work by
> changing UBNT_TYPE to 2WA
> ---
> .../linux/ath79/dts/ar9342_ubnt_bullet-ac.dts | 38 +++
> .../generic/base-files/etc/board.d/01_leds| 1 +
> .../generic/base-files/etc/board.d/02_network | 1 +
> .../etc/hotplug.d/firmware/11-ath10k-caldata | 1 +
> target/linux/ath79/image/generic-ubnt.mk | 17 +
> 5 files changed, 58 insertions(+)
> create mode 100644 target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
>
> diff --git a/target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
> b/target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
> new file mode 100644
> index 00..be0b0792bb
> --- /dev/null
> +++ b/target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
> @@ -0,0 +1,38 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +#include "ar9342_ubnt_wa_1port.dtsi"
> +
> +/ {
> + compatible = "ubnt,bullet-ac", "ubnt,wa", "qca,ar9342";
> + model = "Ubiquiti Bullet AC (2WA)";
would you provide some details about that odd "2WA"?
> +
> + aliases {
> + led-boot = &led_rssi3;
> + led-failsafe = &led_rssi3;
> + led-upgrade = &led_rssi3;
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + rssi0 {
> + label = "blue:rssi0";
> + gpios = <&gpio 11 GPIO_ACTIVE_LOW>;
> + };
> +
> + rssi1 {
> + label = "blue:rssi1";
> + gpios = <&gpio 16 GPIO_ACTIVE_LOW>;
> + };
> +
> + rssi2 {
> + label = "blue:rssi2";
> + gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
> + };
> +
> + led_rssi3: rssi3 {
> + label = "blue:rssi3";
> + gpios = <&gpio 14 GPIO_ACTIVE_LOW>;
> + };
> + };
> +};
> diff --git a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
> b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
> index a0ed21e318..46d4650eac 100755
> --- a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
> +++ b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
> @@ -366,6 +366,7 @@ ubnt,rocket-m)
> ucidef_set_led_rssi "rssimediumhigh" "RSSIMEDIUMHIGH"
> "green:link3" "wlan0" "51" "100"
> ucidef_set_led_rssi "rssihigh" "RSSIHIGH" "green:link4" "wlan0" "76"
> "100"
> ;;
> +ubnt,bullet-ac|\
This requires to move the block to keep sorting.
> ubnt,nanobeam-ac|\
> ubnt,nanobeam-ac-gen2|\
> ubnt,nanostation-ac|\
> 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 905848a2ba..9293e5522b 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
> @@ -58,6 +58,7 @@ ath79_setup_interfaces()
> tplink,re450-v2|\
> tplink,re450-v3|\
> tplink,tl-wr902ac-v1|\
> + ubnt,bullet-ac|\
>
Re: Bind + ISC dhcpd integration (for intranet split-horizon, etc)
> On Dec 16, 2020, at 12:59 AM, Bjørn Mork wrote:
>
> Philip Prindeville writes:
>>> On Dec 15, 2020, at 1:22 AM, Bjørn Mork wrote:
>>>
>>> Philip Prindeville writes:
>>>
I’m trying to do the integration “glue” to allow one to operate a DNS
private zone inside your intranet (aka “split horizon”) and prime it
with both static data as well as DHCP lease information.
>>>
>>> “split horizon” is a very bad idea, and should not be encouraged.
>>
>>
>> Can you say more about that?
>
> It breaks the basic DNS premise: There is one distributed database.
I don’t know how concrete that premise is: why would Bind have ‘views’ if there
was a single, global version of the database?
> The fallout is broken DNSSEC, lame delegations, failing services, broken
> caches etc. Most of these are results of the added operational
> complexity. Feeble attempts to simplify split DNS also often involve
> breaking best practices, like having authoritative servers in more than
> one AS.
This is for the SoHo scenario where the firewall provides both DNS, DNS
forwarding, DHCP, and connectivity. If that device fails, everything does
anyway.
> All this might have been acceptable if it solved a real problem. It
> doesn't.
>
>> I don’t see why the converse would be any better, i.e. publishing
>> RFC-1918 addresses of NATted hosts behind a firewall,
>
> This is not a problem. There is nothing special about RFC 1918, or any
> other, addresses in DNS. DNS replies comes without any guarantee about
> firewalls, routing or provided public services. Software which assumes
> otherwise is buggy, with very few exceptions.
That’s not my concern. I don’t want to admit the existence of devices which
aren’t reachable to begin with, if (a) they have unroutable addresses and (b)
there is no port-forwarding to reach them.
Disclosing information about internal resources… possibly critical or sensitive
resources… without any need to do so is a mistake. Why give potential
attackers additional information with which to prepare an attack?
> The classic example of such bugs is the claimed "rebind protection" in
> dnsmasq. Which
> a) breaks valid configurations
> b) doesn't do rebind protection
>
>> and disclosing more information than is necessary anyway…
>
> I realize this is important to some. But split DNS will not protect
> this information. You should not put anything you don't want to
> disclose in DNS.
Sure it protects it. The name server that contains this information about my
hosts also serves that information to the only hosts that need it. It’s
configured as:
options {
...
allow-query {
localhost;
192.168.1.0/24;
192.168.2.0/24;
192.168.3.0/24;
};
...
};
>
>> See here:
>>
>> https://github.com/openwrt/packages/pull/14233
>
> Huh? Can't find anything related to dynamic DNS in either BIND or ISC
> dhcp there?
Doh. Wrong PR:
https://github.com/openwrt/packages/pull/14240
The previous one is a precursor for getting Bind to start before DHCPD.
>
>> Well, doing an RTFM I see:
>>
>> The ddns-update-style parameter
>>
>> ddns-update-style style;
>>
>>The style parameter must be one of ad-hoc, interim or none. The
>>ddns-update-style statement is only meaningful in the outer scope
>>- it is evaluated once after reading the dhcpd.conf file, rather
>>than each time a client is assigned an IP address, so there is no
>>way to use different DNS update styles for different clients. The
>>default is none.
>
> My manual says
>
>ddns-update-style style;
>
>The style parameter must be one of standard, interim or
>none. The ddns-update-style statement is only meaningful in
>the outer scope - it is evaluated once after reading the
>dhcpd.conf file, rather than each time a client is assigned
>an IP address, so there is no way to use different DNS
>update styles for different clients. The default is none.
Serves me right for looking at the Ubuntu 18.04 LTS man page…
Okay, fixed to use “standard”.
Thanks for that.
-Philip
>
> The "standard" style was introduced in commit d7d9c0c7c36d ("-n [master]
> Add code to support the standards version of DDNS") in 2013. It was
> released with version 4.3 in 2014.
>
>
>
> Bjørn
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] wireless-regdb: Update to version 2020.11.20
9efa1da wireless-regdb: update regulatory rules for Egypt (EG) ede87f5 wireless-regdb: restore channel 12 & 13 limitation in the US 5bcafa3 wireless-regdb: Update regulatory rules for Croatia (HR) 4e052f1 wireless-regdb: Update regulatory rules for Pakistan (PK) on 5GHz f9dfc58 wireless-regdb: update 5.8 GHz regulatory rule for GB c19aad0 wireless-regdb: Update regulatory rules for Kazakhstan (KZ) 07057d3 wireless-regdb: update regulatory database based on preceding changes Signed-off-by: Hauke Mehrtens --- package/firmware/wireless-regdb/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/package/firmware/wireless-regdb/Makefile b/package/firmware/wireless-regdb/Makefile index fc18d159b166..308ca40e22d6 100644 --- a/package/firmware/wireless-regdb/Makefile +++ b/package/firmware/wireless-regdb/Makefile @@ -1,12 +1,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=wireless-regdb -PKG_VERSION:=2020.04.29 +PKG_VERSION:=2020.11.20 PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz PKG_SOURCE_URL:=@KERNEL/software/network/wireless-regdb/ -PKG_HASH:=89fd031aed5977c219a71501e144375a10e7c90d1005d5d086ea7972886a2c7a +PKG_HASH:=b4164490d82ff7b0086e812ac42ab27baf57be24324d4c0ee1c5dd6ba27f2a52 PKG_MAINTAINER:=Felix Fietkau -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCHv2] ath79: Add support for Ubiquiti Bullet AC
responses in-line.
On Wed, Dec 16, 2020 at 8:20 AM Adrian Schmutzler
wrote:
>
> Hi,
>
> > -Original Message-
> > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> > On Behalf Of Russell Senior
> > Sent: Mittwoch, 16. Dezember 2020 12:01
> > To: openwrt-devel@lists.openwrt.org
> > Subject: [PATCHv2] ath79: Add support for Ubiquiti Bullet AC
> >
> >
> > CPU: Atheros AR9342 rev 3 SoC
> > RAM: 64 MB DDR2
> > Flash: 16 MB NOR SPI
> > WLAN 2.4GHz: Atheros AR9342 v3 (ath9k)
> > WLAN 5.0GHz: QCA988X
> > Ports: 1x GbE
> >
> > Flashing procedure is identical to other ubnt devices.
> > https://openwrt.org/toh/ubiquiti/common
> >
> > Flashing through factory firmware
> > 1. Ensure firmware version v8.7.0 is installed.
> >Up/downgrade to this exact version.
> > 2. Patch fwupdate.real binary using
> >`hexdump -Cv /bin/ubntbox | sed 's/14 40 fe 27/00 00 00 00/g' | \
> > hexdump -R > /tmp/fwupdate.real`
> > 3. Make the patched fwupdate.real binary executable using
> >`chmod +x /tmp/fwupdate.real`
> > 4. Copy the squashfs factory image to /tmp on the device 5. Flash OpenWrt
> > using `/tmp/fwupdate.real -m ` 6. Wait for the
> > device to reboot (copied from Ubiquiti NanoBeam AC and modified)
> >
> > Flashing from serial console
> > 1. Connect serial console (115200 baud)
> > 2. Connect ethernet to a network with a TFTP server, through a
> >passive PoE injector.
> > 3. Press a key to obtain a u-boot prompt 4. Set your TFTP server's ip
> > address,
> > with:
> >setenv serverip 5. Set the Bullet AC's ip address,
> > with:
> >setenv ipaddr
> > 6. Set the boot file, with:
> >setenv bootfile
> > 7. Fetch the binary with tftp:
> >tftpboot
> > 8. Boot the initramfs binary:
> >bootm
> > 9. From the initramfs, fetch the sysupgrade binary, and flash it with
> >sysupgrade.
> >
> > Phy0 is QCA988X which can tune either band (2.4 or 5GHz). Phy1 is AR9342,
> > on which 5GHz is disabled. It isn't currently known whether phy1 is routed
> > to
> > the N connector at all.
> >
> > Signed-off-by: Russell Senior
> > ---
> > v2:
> > - Make "Flashing through factory firmware" instructions actually work by
> > changing UBNT_TYPE to 2WA
> > ---
> > .../linux/ath79/dts/ar9342_ubnt_bullet-ac.dts | 38 +++
> > .../generic/base-files/etc/board.d/01_leds| 1 +
> > .../generic/base-files/etc/board.d/02_network | 1 +
> > .../etc/hotplug.d/firmware/11-ath10k-caldata | 1 +
> > target/linux/ath79/image/generic-ubnt.mk | 17 +
> > 5 files changed, 58 insertions(+)
> > create mode 100644 target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
> >
> > diff --git a/target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
> > b/target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
> > new file mode 100644
> > index 00..be0b0792bb
> > --- /dev/null
> > +++ b/target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
> > @@ -0,0 +1,38 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +
> > +#include "ar9342_ubnt_wa_1port.dtsi"
> > +
> > +/ {
> > + compatible = "ubnt,bullet-ac", "ubnt,wa", "qca,ar9342";
> > + model = "Ubiquiti Bullet AC (2WA)";
>
> would you provide some details about that odd "2WA"?
2WA is what Ubiquiti calls it. It is needed in UBNT_TYPE in order for
the patched fwupdate.real to match and accept the factory.bin
There are two other 2WA devices supported by the same Ubiquiti
firmware. The 2 in 2WA seems to represent the 2.4GHz band (despite the
Bullet AC being able to use either band).
>
> > +
> > + aliases {
> > + led-boot = &led_rssi3;
> > + led-failsafe = &led_rssi3;
> > + led-upgrade = &led_rssi3;
> > + };
> > +
> > + leds {
> > + compatible = "gpio-leds";
> > +
> > + rssi0 {
> > + label = "blue:rssi0";
> > + gpios = <&gpio 11 GPIO_ACTIVE_LOW>;
> > + };
> > +
> > + rssi1 {
> > + label = "blue:rssi1";
> > + gpios = <&gpio 16 GPIO_ACTIVE_LOW>;
> > + };
> > +
> > + rssi2 {
> > + label = "blue:rssi2";
> > + gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
> > + };
> > +
> > + led_rssi3: rssi3 {
> > + label = "blue:rssi3";
> > + gpios = <&gpio 14 GPIO_ACTIVE_LOW>;
> > + };
> > + };
> > +};
> > diff --git a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
> > b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
> > index a0ed21e318..46d4650eac 100755
> > --- a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
> > +++ b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
> > @@ -366,6 +366,7 @@ ubnt,rocket-m)
> > ucidef_set_led_rssi "rssimediumhigh" "RSSIMEDIUMHIGH"
> > "green:link3" "wlan0" "51" "100"
> > ucidef_set_led_rssi "rssihigh" "RSSIHIGH" "green:link4" "wlan0" "
[PATCH] lantiq: falcon: mark as source only sub target
The sub target does not support network and there are not so many users out there, just mark it as source only, so we do jot have to build it. The quality is not worse than before, it just does not make much sense to build this automatically. Signed-off-by: Hauke Mehrtens --- target/linux/lantiq/falcon/target.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/lantiq/falcon/target.mk b/target/linux/lantiq/falcon/target.mk index 90f81d25ca86..c07c8c2d82bc 100644 --- a/target/linux/lantiq/falcon/target.mk +++ b/target/linux/lantiq/falcon/target.mk @@ -1,7 +1,7 @@ ARCH:=mips SUBTARGET:=falcon BOARDNAME:=Falcon -FEATURES+=nand +FEATURES+=nand source-only CPU_TYPE:=24kc DEFAULT_PACKAGES+= kmod-leds-gpio \ -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCHv2] ath79: Add support for Ubiquiti Bullet AC
I would suggest doing the re-ordering to maintain lexical ordering in
a separate commit, to keep the functional changes more clear.
On Wed, Dec 16, 2020 at 12:27 PM Russell Senior
wrote:
>
> responses in-line.
>
> On Wed, Dec 16, 2020 at 8:20 AM Adrian Schmutzler
> wrote:
> >
> > Hi,
> >
> > > -Original Message-
> > > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> > > On Behalf Of Russell Senior
> > > Sent: Mittwoch, 16. Dezember 2020 12:01
> > > To: openwrt-devel@lists.openwrt.org
> > > Subject: [PATCHv2] ath79: Add support for Ubiquiti Bullet AC
> > >
> > >
> > > CPU: Atheros AR9342 rev 3 SoC
> > > RAM: 64 MB DDR2
> > > Flash: 16 MB NOR SPI
> > > WLAN 2.4GHz: Atheros AR9342 v3 (ath9k)
> > > WLAN 5.0GHz: QCA988X
> > > Ports: 1x GbE
> > >
> > > Flashing procedure is identical to other ubnt devices.
> > > https://openwrt.org/toh/ubiquiti/common
> > >
> > > Flashing through factory firmware
> > > 1. Ensure firmware version v8.7.0 is installed.
> > >Up/downgrade to this exact version.
> > > 2. Patch fwupdate.real binary using
> > >`hexdump -Cv /bin/ubntbox | sed 's/14 40 fe 27/00 00 00 00/g' | \
> > > hexdump -R > /tmp/fwupdate.real`
> > > 3. Make the patched fwupdate.real binary executable using
> > >`chmod +x /tmp/fwupdate.real`
> > > 4. Copy the squashfs factory image to /tmp on the device 5. Flash OpenWrt
> > > using `/tmp/fwupdate.real -m ` 6. Wait for the
> > > device to reboot (copied from Ubiquiti NanoBeam AC and modified)
> > >
> > > Flashing from serial console
> > > 1. Connect serial console (115200 baud)
> > > 2. Connect ethernet to a network with a TFTP server, through a
> > >passive PoE injector.
> > > 3. Press a key to obtain a u-boot prompt 4. Set your TFTP server's ip
> > > address,
> > > with:
> > >setenv serverip 5. Set the Bullet AC's ip
> > > address,
> > > with:
> > >setenv ipaddr
> > > 6. Set the boot file, with:
> > >setenv bootfile
> > > 7. Fetch the binary with tftp:
> > >tftpboot
> > > 8. Boot the initramfs binary:
> > >bootm
> > > 9. From the initramfs, fetch the sysupgrade binary, and flash it with
> > >sysupgrade.
> > >
> > > Phy0 is QCA988X which can tune either band (2.4 or 5GHz). Phy1 is AR9342,
> > > on which 5GHz is disabled. It isn't currently known whether phy1 is
> > > routed to
> > > the N connector at all.
> > >
> > > Signed-off-by: Russell Senior
> > > ---
> > > v2:
> > > - Make "Flashing through factory firmware" instructions actually work by
> > > changing UBNT_TYPE to 2WA
> > > ---
> > > .../linux/ath79/dts/ar9342_ubnt_bullet-ac.dts | 38 +++
> > > .../generic/base-files/etc/board.d/01_leds| 1 +
> > > .../generic/base-files/etc/board.d/02_network | 1 +
> > > .../etc/hotplug.d/firmware/11-ath10k-caldata | 1 +
> > > target/linux/ath79/image/generic-ubnt.mk | 17 +
> > > 5 files changed, 58 insertions(+)
> > > create mode 100644 target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
> > >
> > > diff --git a/target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
> > > b/target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
> > > new file mode 100644
> > > index 00..be0b0792bb
> > > --- /dev/null
> > > +++ b/target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
> > > @@ -0,0 +1,38 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +
> > > +#include "ar9342_ubnt_wa_1port.dtsi"
> > > +
> > > +/ {
> > > + compatible = "ubnt,bullet-ac", "ubnt,wa", "qca,ar9342";
> > > + model = "Ubiquiti Bullet AC (2WA)";
> >
> > would you provide some details about that odd "2WA"?
>
> 2WA is what Ubiquiti calls it. It is needed in UBNT_TYPE in order for
> the patched fwupdate.real to match and accept the factory.bin
>
> There are two other 2WA devices supported by the same Ubiquiti
> firmware. The 2 in 2WA seems to represent the 2.4GHz band (despite the
> Bullet AC being able to use either band).
>
> >
> > > +
> > > + aliases {
> > > + led-boot = &led_rssi3;
> > > + led-failsafe = &led_rssi3;
> > > + led-upgrade = &led_rssi3;
> > > + };
> > > +
> > > + leds {
> > > + compatible = "gpio-leds";
> > > +
> > > + rssi0 {
> > > + label = "blue:rssi0";
> > > + gpios = <&gpio 11 GPIO_ACTIVE_LOW>;
> > > + };
> > > +
> > > + rssi1 {
> > > + label = "blue:rssi1";
> > > + gpios = <&gpio 16 GPIO_ACTIVE_LOW>;
> > > + };
> > > +
> > > + rssi2 {
> > > + label = "blue:rssi2";
> > > + gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
> > > + };
> > > +
> > > + led_rssi3: rssi3 {
> > > + label = "blue:rssi3";
> > > + gpios = <&gpio 14 GPIO_ACTIVE_LOW>;
> > > + };
> > > + };
> > > +};
> > > diff --git a/target/linux/ath79/generic/base-files/etc/board.d/01_le
Re: Corruption in ext4 root
Hi Michael, On Tue, Dec 15, 2020 at 09:16:50PM -0600, W. Michael Petullo wrote: > I often find the OpenWrt image's root filesystem corrupt after running > "poweroff" and then restarting the DomU VM. What exactly do you mean by "corrupt"? Are files that you create before the poweroff just gone or does the kernel actually complain about errors in the FS on the next boot? If it's the former I might be able to help as I've had a similar problem: what I found is that the mount_root command, which mounts the rootfs on bootup, has logic that will wipe your entire overlay FS if there isn't a .fs_state symlink in the overlay mountpoint containing the string "2". See https://git.openwrt.org/?p=project/fstools.git;a=blob;f=libfstools/overlay.c;h=eadafcf4391f36658c26f94c5fec770aeb6c743a;hb=HEAD#l438, the fs_state_get() function reads the .fs_state link and the overlay_delete() call deletes the overlay FS recursively. Basically the solution in my case was to simply wait until /etc/rc.d/S95done was run, as this runs `mount_root done` which will set the .fs_state such that this doesn't happen on the next bootup. --Daniel PS: This hack took me a good two days to debug and frankly making fs_state a hidden file just adds insult to injury. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC] raise gcc/make versions for 20.x
On Wed, Dec 16, 2020 at 4:34 AM Yousong Zhou wrote: > > On Wed, 16 Dec 2020 at 13:11, Petr Štetiar wrote: > > > > Paul Spooren [2020-12-15 16:26:14]: > > > > Hi, > > > > > I've seen two patches for version raises of build requirements and would > > > like to know if we should merge them before or after 20.x. > > > > > > make: 3.81.x -> 4.1.x > > > gcc: 4.8 -> 6.x > > > > > > I'm in favor to merge both *before* the branch. > > > > it would probably help to know the reason as well. "I'm in favor" might not > > be > > enough in this almost pre-release stage. > > > > AFAIK that Make version bump fixes an issue with possibly few stray ANSI > > color > > escapes (workaround is to use NO_COLOR=1 in this case) and \r characters in > > the > > log file. Is it really that big issue to do this last minute version bump? > > > > FYI that gcc6+ one was NACKed[1] by Yousong and I'm fine with that for 20.12 > > release. I plan to rebase/resend that patch once 20.12 is branched. > > > > 1. > > https://patchwork.ozlabs.org/project/openwrt/patch/20191112081625.27695-1-yn...@true.cz/#2301662 > > > > I still hold the belief that a system such as CentOS could deserve a > work-out-of-the-box experience ;) But now that CentOS like the old > day is not an option anymore in the future, I say we move on in the > next release. Assuming you're referring to the CentOS Stream announcement, I don't see how that's relevant. CentOS 7 is supported until 2024. > > Regards, > yousong > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 0/2] uboot-envtools: support for multiple config partitions
Hi, Op woensdag 16 december 2020 om 15u14 schreef Bjørn Mork : Stijn Segers writes: I'm giving this a spin (since I have a Realtek switch now :^) Great! Thanks for testing ). Fw_printenv prints info as expected but fw_printsys comes up empty. Not sure if this is expected behaviour. There's no /etc/fw_sys.config after installing the new uboot-envtools package (revision 10). # fw_printenv baudrate=115200 boardmodel=ZyXEL_GS1900_10HP bootargs=console=ttyS0,115200 mem=64M quiet bootcmd=cst fcTest; boota bootdelay=0 ethact=rtl8380#0 ethaddr=BC:CF:4F:74:3C:15 ipaddr=192.168.1.1 netmask=255.255.255.0 serverip=192.168.1.111 stderr=serial stdin=serial stdout=serial # fw_printsys # ls /etc/fw* /etc/fw_env.config Calling 'fw_setsys bootpartition 0' e.g. exits silently. No /etc/fw_sys.config gets created. The /etc/fw_sys.config is supposed to be created on first installation, just like the /etc/fw_env.config. I wasn't quite sure what to do in the wrapper if it doesn't exist. The wrapper cannot know if the config is supposed to be there or not. So the current version will just exit silently, as you've observed. Maybe not the best solution? I am open to ideas. Anyway, the config files will only be generated if /etc/config/ubootenv doesn't exist. If you installed to flash you can look at /rom/etc/uci-defaults/30_uboot-envtools The first line is "[ -e /etc/config/ubootenv ] && exit 0" This is how the package has been working all the time. It should probably be fixed. But I guess the assumption was that the environment partition config is a hardware property which will not change? Yeah I reckon that's the issue. It doesn't check for any settings,so technically even an empty file would do. Which is pretty coarse. One could do a nested check to see first if ubootenv UCI values exist, and only then probe for UCI ubootsys values - but that would mean more lines of code for checks etc.? On the other hand, the situation I was in is one that won't be too widespread - switches aren't as hot as 802.11ax devices, so this is probably an edge case. The curse of the early adopter :-). When I create /etc/fw_sys.config manually then try to set a value again, it errors: # fw_setsys bootpartition 0 Cannot parse config file '/etc/fw_sys.config': Invalid argument Error: environment not initialized root@OpenWrt:~# ls /etc/fw_sys.config /etc/fw_sys.config # That's strange. What does the file look like? FWIW, here is mine from the same switch model: root@gs1900-10hp:/# cat /etc/fw_sys.config /dev/mtd2 0x0 0x1000 0x1 Yeah mine was completely empty (I just touched it to see if I'd get any meaningful output). And it works: root@gs1900-10hp:/# fw_printsys resetdefault=0 mac_start=BC:CF:4F:D1:6B:32 mac_end=BC:CF:4F:D1:6B:3C sn=S202L28001735 dualfname1=2.60(AAZI.2)C0.bix dualfname0=x.bin bootpartition=0 Yeah, after filling /etc/fw_sys.config with the right values, it works here too. Thanks for pointing me at the /rom/etc/uci-defaults/ script. It was staring me in the face in the file list of uboot-envtools but still. This is my ubootenv (which is irrelevant as it isn't be used by anything after first install): root@gs1900-10hp:/# cat /etc/config/ubootenv config ubootenv option dev '/dev/mtd1' option offset '0x0' option envsize '0x400' option secsize '0x1' config ubootsys option dev '/dev/mtd2' option offset '0x0' option envsize '0x1000' option secsize '0x1' Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 0/2] uboot-envtools: support for multiple config partitions
Stijn Segers writes: > Yeah, after filling /etc/fw_sys.config with the right values, it works > here too. Good to know. Note that the partition currently is marked as read-only in the dts. So you will have to chacnge that or use kmod-mtd-rw if you want to change any variable. Thanks to the stock firmware web gui providing direct control of the "active image", i.e the bootpartition variable, it is possible to switch back and forth between OpenWrt installed in "firmware" and stock installed in "runtime2". So you can manage a "dual-boot" installation without using the console. Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] tools/pkgconf: update to 1.7.3
Remove upstreamed patch.
Signed-off-by: Rosen Penev
---
tools/pkgconf/Makefile| 4 +--
...move-version-to-modversion-remapping.patch | 36 ---
2 files changed, 2 insertions(+), 38 deletions(-)
delete mode 100644
tools/pkgconf/patches/0001-cli-remove-version-to-modversion-remapping.patch
diff --git a/tools/pkgconf/Makefile b/tools/pkgconf/Makefile
index cefee1edf0..7d785aae39 100644
--- a/tools/pkgconf/Makefile
+++ b/tools/pkgconf/Makefile
@@ -7,11 +7,11 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=pkgconf
-PKG_VERSION:=1.6.3
+PKG_VERSION:=1.7.3
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
PKG_SOURCE_URL:=https://distfiles.dereferenced.org/pkgconf
-PKG_HASH:=61f0b31b0d5ea0e862b454a80c170f57bad47879c0c42bd8de89200ff62ea210
+PKG_HASH:=b846aea51cf696c3392a0ae58bef93e2e72f8e7073ca6ad1ed8b01c85871f9c0
HOST_BUILD_PARALLEL:=1
diff --git
a/tools/pkgconf/patches/0001-cli-remove-version-to-modversion-remapping.patch
b/tools/pkgconf/patches/0001-cli-remove-version-to-modversion-remapping.patch
deleted file mode 100644
index b2c538d24e..00
---
a/tools/pkgconf/patches/0001-cli-remove-version-to-modversion-remapping.patch
+++ /dev/null
@@ -1,36 +0,0 @@
-From 62bbd3b664d4b03011a4b382ed20353a91c30406 Mon Sep 17 00:00:00 2001
-From: Ariadne Conill
-Date: Tue, 21 Jan 2020 10:32:36 -0600
-Subject: [PATCH] cli: remove --version to --modversion remapping
-
-This has been a source of frequent complaints, so we drop it.
-Resolves: https://todo.sr.ht/~kaniini/pkgconf/6
- cli/main.c | 14 ++
- 1 file changed, 2 insertions(+), 12 deletions(-)
-
-diff --git a/cli/main.c b/cli/main.c
-index 563ec8f0cfcd..fc698a4f9191 100644
a/cli/main.c
-+++ b/cli/main.c
-@@ -1005,18 +1005,8 @@ main(int argc, char *argv[])
-
- if ((want_flags & PKG_VERSION) == PKG_VERSION)
- {
-- if (argc > 2)
-- {
-- fprintf(stderr, "%s: --version specified with other
options or module names, assuming --modversion.\n", argv[0]);
--
-- want_flags &= ~PKG_VERSION;
-- want_flags |= PKG_MODVERSION;
-- }
-- else
-- {
-- version();
-- return EXIT_SUCCESS;
-- }
-+ version();
-+ return EXIT_SUCCESS;
- }
-
- if ((want_flags & PKG_HELP) == PKG_HELP)
--
2.29.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
