[OpenWrt-Devel] Dropbear DSA keys
Hi Felix, in svn commit 46814 / git commit 095c30687c75ede2d25918b on Tue Sep 8 08:55:10 2015 + you wrote: dropbear: disable 3des, cbc mode, dss support, saves about 5k gzipped While technically required by the RFC, they are usually completely unused (DSA), or have security issues (3DES, CBC) While I agree with you on dropping 3DES and CBC modes, the claim that DSA is "completely unused" is a fairly bold assumption IMHO. First, as you mentioned, it is part of the standard(!) and has no technical issues. Second, it used to be the default type for keys generated by OpenSSH for some extended time period, IIRC. Wouldn't it save a lot more space to consolidate SSH, SSL, WPA and VPN onto a single, shared crypto library? At least dropbear uses its own... The main problem I see with this change however is that it needs to be *documented* somewhere prominently, a ChangeLog at least, if not release notes. While at it, why not switch to ECC completely? A few 4096-bit RSA keys quickly outweight the smaller image size. Torsten ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[PATCH 21.02] Fix HifiBerry DAC+ / DAC+ Pro / Amp2 packaging
Hi all! According to the vendor [1] these HATs share the same DT overlay, hifiberry-dacplus. The PCM512x-compatible control unit is attached to I²C, so the additional snd-soc-pcm512x-i2c kernel module is required. Also explicitly note the Amp2 support to reduce confusion for those users. [1] https://www.hifiberry.com/docs/software/configuring-linux-3-18-x/ Signed-off-by: Torsten Duwe -- diff --git a/target/linux/bcm27xx/modules/sound.mk b/target/linux/bcm27xx/modules/sound.mk index dab31d8132..1d3165ed2f 100644 --- a/target/linux/bcm27xx/modules/sound.mk +++ b/target/linux/bcm27xx/modules/sound.mk @@ -509,24 +509,27 @@ $(eval $(call KernelPackage,sound-soc-hifiberry-dac)) define KernelPackage/sound-soc-hifiberry-dacplus - TITLE:=Support for HifiBerry DAC+ / DAC+ Pro + TITLE:=Support for HifiBerry DAC+ / DAC+ Pro / Amp2 KCONFIG:= \ CONFIG_SND_BCM2708_SOC_HIFIBERRY_DACPLUS \ -CONFIG_SND_SOC_PCM512x +CONFIG_SND_SOC_PCM512x \ +CONFIG_SND_SOC_PCM512x_I2C FILES:= \ $(LINUX_DIR)/drivers/clk/clk-hifiberry-dacpro.ko \ $(LINUX_DIR)/sound/soc/bcm/snd-soc-hifiberry-dacplus.ko \ -$(LINUX_DIR)/sound/soc/codecs/snd-soc-pcm512x.ko +$(LINUX_DIR)/sound/soc/codecs/snd-soc-pcm512x.ko \ +$(LINUX_DIR)/sound/soc/codecs/snd-soc-pcm512x-i2c.ko AUTOLOAD:=$(call AutoLoad,68,clk-hifiberry-dacpro snd-soc-pcm512x \ -snd-soc-hifiberry-dacplus) +snd-soc-pcm512x-i2c snd-soc-hifiberry-dacplus) DEPENDS:= \ kmod-sound-soc-bcm2835-i2s \ -+kmod-i2c-bcm2835 ++kmod-i2c-bcm2835 \ ++kmod-regmap-i2c $(call AddDepends/sound) endef define KernelPackage/sound-soc-hifiberry-dacplus/description - This package contains support for HifiBerry DAC+ / DAC+ Pro + This package contains support for HifiBerry DAC+ / DAC+ Pro / Amp2 endef $(eval $(call KernelPackage,sound-soc-hifiberry-dacplus)) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Best VSDL modem-router to target?
On Fri, 3 Dec 2021 23:13:17 +0100 Christian Lamparter wrote: > On 03/12/2021 22:21, Stefan Lippers-Hollmann wrote: > > Hi > > > > On 2021-12-03, Andrew Punch wrote: > >> Spoke too soon Fritzbox 7490 has been discontinued. Might be able > >> to get one from the US if I use the freight forwarder but I don't > >> like my chances. If you're living in (continental) Europe there still seem to be some left: https://geizhals.de/a992918.html (this link won't age well ;) > > The Fritz!Box 7490 is rather special, two SOCs on one board (lantiq > > base, with an ath79 board dealing with the wireless on top and > > special VLANs between them), while there has been progress to get > > this working, it has never been merged (or submitted for potential > > merging) to OpenWrt. (It's pretty complex, you'd need to build two > > image, one lantiq, and a specially crafted initramfs image for > > ath79, using a special configuration conduit between them, to > > initialize and run the wireless on the ath79 SOC). Additionally > > DECT and FXS of the AVM devices is not supported by OpenWrt (DECT > > isn't at all, for FXS uses a different approach than other lantiq > > devices). I have a 3490 and a 7490 and have extracted a small patch set from Andreas Böhler / Daniel Kestrel to run 21.02 on these. However I don't need Wifi nor the DECT, so it's just for the basic DSL router functionality. If there's interest I can post it here or maybe provide the equivalent for the master branch. Torsten ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: IP-PBX users?
On Wed, 5 Jan 2022 17:09:19 -0700 Philip Prindeville wrote: > Anyone have documentation on getting started? > Or strong arguments to use Freeswitch over Asterisk or vice versa? My personal impression is that the mature Asterisk is good at combining POTS with VoIP, with very limited support for video, whereas the rather new FreeSwitch focuses on VoIP, has some ambitions towards video conferencing (Big Blue Button prefers it, FWIW), and seems to have limited support for POTS. Around 2019 I had to switch from Asterisk to FreeSwitch because Deutsche Telekom is rather picky about their DNS setup; you must use their SRV records, otherwise phone service will fail in an obscure way, occasionally. Only FreeSwitch was able to do the proper DNS SRV lookup. I also found that it handles the forced DSL disconnects very gracefully. FreeSwitch is being quite actively developed, and documentation (mostly the wiki) lags behind, more or less, so RTFS was inevitable back then. Torsten ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: IP-PBX users?
On Mon, 10 Jan 2022 21:17:26 -0800 Bruce Ferrell wrote: > On 1/10/22 8:08 PM, Philip Prindeville wrote: > >> On Jan 7, 2022, at 7:49 AM, Torsten Duwe wrote: > >> Only FreeSwitch was able to do the > >> proper DNS SRV lookup. I also found that it handles the forced DSL > >> disconnects very gracefully. > > Bruce & Torsten: what packages/resources/functions, etc. do you > > enable in Asterisk? There's a bazillion of them... Yes indeed. I guesstimated most decisions based on some faint background knowledge and gut feeling. See below. > > And which ones to stay away from because of their potential > > security exposure? I tried to restrict the code base to what I had intended to use, hoping for the best, as the alternatives in my situation back then were even worse (i.e. closed-source IP phones directly in the net). > > Thanks, > > > > -Philip > > Oh gawd! what an open question. > > To answer that I'd need to know what your needs are. Very true. All I really needed was a replacement for ISDN back then, which they forcibly shut down. I always wanted to try some private phone conferencing, but never got at that. As Bruce already mentioned: YMMV. I'll send you the asterisk part of my last 19.07.3 config in a PM. It worked quite well, besides the DNS problem I mentioned (above). Moving to FreeSwitch was the right thing to do, at least for me. Torsten ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 0/7] lantiq: initial support for x490 Fritzboxes
With the latest advancements, especially the move to kernel-5.10,
basic support for the {3,5,7}490 Fritz!Boxes has become rather low
hanging fruit. Building on the previous research done by Andreas
Böhler (subscribed here), Daniel Kestrel (Cc'ed) and others, I
identified and collected all the pieces, verified and fixed the detail
information as far as I could, and refined the changes into a
hopefully acceptable patch set.
The hardware telephony on the {5,7}490 remains unsupported, of course.
The WiFi on these systems is moved to a secondary SoC; some effort has
been made to build an appropriate OpenWRT image for that as well in
one run, but I'm ignoring that here for simplicity's sake. The extra
image is a major step, which should rather be discussed and postponed,
and should IMHO not hinder the inclusion of these devices. Neither did
I consider performance patches yet.
On the plus side, thanks to the DSA move in Linux mainline, all 4 LAN
ports can be used now. Likewise, the USB3 ports are working, once an
xHCI firmware blob is provided [1].
These patches are tested on 7490 and 3490, one specimen each. I can't
verify the 5490 fiber box, but I include it here because of the
similarity. Any feedback is appreciated. Especially the GPIO lines and
switch ports remain to be filled in at the DTS. The 7490 I have uses a
Micron NAND chip with 128k PEBs and 2k IO size. The 3490 has a Toshiba
Chip with 256k PEBs and 4k IO. Anybody with a different combination
please speak up!
Torsten
[1] https://forum.openwrt.org/t/2071
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/7] lantiq: fix endianess for PCIe slave XBAR
On some targets the AHB slave XBAR is wired up big endian.
Allow specific targets to trigger a byte swap via a device tree
property. Discussed in https://forum.openwrt.org/t/53620
Signed-off-by: Torsten Duwe
---
I found this in Daniel's repo, merged into
0001-MIPS-lantiq-add-pcie-driver.patch,
but I'd rather keep it separate, for clarity. The original commit message was
lost
in the merge; I wouldn't mind another signed-off by the original author ;-)
---
...q-ifxmips_pcie-fix-slave-XBAR-endian.patch | 45 +++
1 file changed, 45 insertions(+)
create mode 100644
target/linux/lantiq/patches-5.10/0156-lantiq-ifxmips_pcie-fix-slave-XBAR-endian.patch
diff --git
a/target/linux/lantiq/patches-5.10/0156-lantiq-ifxmips_pcie-fix-slave-XBAR-endian.patch
b/target/linux/lantiq/patches-5.10/0156-lantiq-ifxmips_pcie-fix-slave-XBAR-endian.patch
new file mode 100644
index 00..f6c7e757c9
--- /dev/null
+++
b/target/linux/lantiq/patches-5.10/0156-lantiq-ifxmips_pcie-fix-slave-XBAR-endian.patch
@@ -0,0 +1,45 @@
+--- a/arch/mips/pci/ifxmips_pcie_vr9.h
b/arch/mips/pci/ifxmips_pcie_vr9.h
+@@ -33,6 +33,7 @@
+ #define IFX_RCU_AHB_BE_PCIE_M0x0001 /* Configure AHB
master port that connects to PCIe RC in big endian */
+ #define IFX_RCU_AHB_BE_PCIE_S0x0010 /* Configure AHB
slave port that connects to PCIe RC in little endian */
+ #define IFX_RCU_AHB_BE_XBAR_M0x0002 /* Configure AHB
master port that connects to XBAR in big endian */
++#define IFX_RCU_AHB_BE_XBAR_S0x0008 /* Configure AHB
slave port that connects to XBAR in big endian */
+ #define CONFIG_IFX_PCIE_PHY_36MHZ_MODE
+
+ #define IFX_PMU1_MODULE_PCIE_PHY (0)
+--- a/arch/mips/pci/ifxmips_pcie.c
b/arch/mips/pci/ifxmips_pcie.c
+@@ -51,6 +51,7 @@ static int pcie_reset_gpio;
+ static struct phy *ltq_pcie_phy;
+ static struct reset_control *ltq_pcie_reset;
+ static struct regmap *ltq_rcu_regmap;
++static bool switch_pcie_endianess;
+
+ static ifx_pcie_irq_t pcie_irqs[IFX_PCIE_CORE_NR] = {
+ {
+@@ -1024,6 +1025,10 @@ pcie_rc_initialize(int pcie_port)
+ #ifdef CONFIG_IFX_PCIE_HW_SWAP
+ regmap_update_bits(ltq_rcu_regmap, 0x4c, IFX_RCU_AHB_BE_PCIE_S,
+ IFX_RCU_AHB_BE_PCIE_S);
++ if (switch_pcie_endianess) {
++ regmap_update_bits(ltq_rcu_regmap, 0x4c, IFX_RCU_AHB_BE_XBAR_S,
++ IFX_RCU_AHB_BE_XBAR_S);
++ }
+ #else
+ regmap_update_bits(ltq_rcu_regmap, 0x4c, IFX_RCU_AHB_BE_PCIE_S,
+ 0x0);
+@@ -1124,6 +1129,13 @@ static int ifx_pcie_bios_probe(struct pl
+ return PTR_ERR(ltq_pcie_phy);
+ }
+
++if(of_property_read_bool(node, "lantiq,switch-pcie-endianess")) {
++switch_pcie_endianess = true;
++dev_info(&pdev->dev, "switch pcie endianess requested\n");
++} else {
++switch_pcie_endianess = false;
++}
++
+ ltq_pcie_reset = devm_reset_control_get_shared(&pdev->dev, NULL);
+ if (IS_ERR(ltq_pcie_reset)) {
+ dev_err(&pdev->dev, "failed to get the PCIe reset line\n");
--
2.34.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/7] lantiq: add common device tree template for x490 Fritzboxes
Based on xrx200/VR9, these devices replace the internal dwc2 USB2
with an external renesas USB3 controller, attached via PCIe.
The whole wireless hardware is offloaded to a secondary SoC with
an ethernet connection to the built-in switch.
This DTS describes the GSWIP in the new DSA mode, and defaults
to UBI for the NAND flash.
Signed-off-by: Torsten Duwe
---
.../boot/dts/lantiq/vr9_avm_fritzx490.dtsi| 240 ++
1 file changed, 240 insertions(+)
create mode 100644
target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritzx490.dtsi
diff --git
a/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritzx490.dtsi
b/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritzx490.dtsi
new file mode 100644
index 00..8462b24363
--- /dev/null
+++ b/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritzx490.dtsi
@@ -0,0 +1,240 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "vr9.dtsi"
+
+#include
+#include
+
+/ {
+ compatible = "avm,fritzx490", "lantiq,xway", "lantiq,vr9";
+
+ chosen {
+ bootargs = "console=ttyLTQ0,115200 ubi.mtd=ubi root=ubi0:rootfs
rootfstype=ubifs";
+ };
+
+ memory@0 {
+device_type = "memory";
+reg = <0x0 0x1000>;
+ };
+
+ keys {
+ compatible = "gpio-keys-polled";
+ poll-interval = <100>;
+
+ wps {
+ // boxes with (unsupported) telephony HW have DECT here
+ label = "wps";
+ gpios = <&gpio 1 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+
+ wifi {
+ label = "wifi";
+ gpios = <&gpio 29 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+ };
+
+ gpio-export {
+ compatible = "gpio-export";
+
+ gpio_wasp_reset {
+ gpio-export,name = "wasp:reset";
+ gpio-export,output = <1>;
+ gpios = <&gpio 34 GPIO_ACTIVE_HIGH>;
+ };
+
+ gpio_wasp_wakeup {
+ gpio-export,name = "wasp:wakeup";
+ gpio-export,output = <1>;
+ gpios = <&gpio 5 GPIO_ACTIVE_HIGH>;
+ };
+ };
+};
+
+ð0 {
+ mtd-mac-address = <&urlader 0xcc>;
+ mtd-mac-address-increment = <1>;
+};
+
+&gphy0 {
+ lantiq,gphy-mode = ;
+};
+
+&gphy1 {
+ lantiq,gphy-mode = ;
+};
+
+&gpio {
+ pinctrl-names = "default";
+ pinctrl-0 = <&state_default>;
+ gpio-ranges = <&gpio 0 0 56>;
+
+ state_default: pinmux {
+ phy-rst {
+ lantiq,pins = "io32", "io44";
+ lantiq,pull = <0>;
+ lantiq,open-drain;
+ lantiq,output = <1>;
+ };
+
+ pcie-rst {
+ lantiq,pins = "io21";
+ lantiq,open-drain;
+ lantiq,output = <1>;
+ };
+ };
+
+ pcie-rst-dev {
+ gpio-hog;
+ line-name = "pcie-rst-dev";
+ gpios = <22 GPIO_ACTIVE_LOW>;
+ output-low;
+ };
+
+ usb-vbus {
+ gpio-hog;
+ line-name = "usb-vbus";
+ gpios = <14 GPIO_ACTIVE_HIGH>;
+ output-high;
+ };
+};
+
+&gswip {
+pinctrl-0 = <&mdio_pins>;
+pinctrl-names = "default";
+};
+
+&gswip_mdio {
+phy0: ethernet-phy@0 {
+reg = <0x00>;
+reset-gpios = <&gpio 32 GPIO_ACTIVE_LOW>;
+};
+
+phy1: ethernet-phy@1 {
+reg = <0x01>;
+reset-gpios = <&gpio 44 GPIO_ACTIVE_LOW>;
+};
+
+phy11: ethernet-phy@11 {
+reg = <0x11>;
+};
+
+phy13: ethernet-phy@13 {
+reg = <0x13>;
+};
+};
+
+&gswip_ports {
+port@0 {
+reg = <0>;
+label = "lan3";
+phy-mode = "rgmii-rxid";
+phy-handle = <&phy0>;
+};
+
+port@1 {
+reg = <1>;
+label = "lan4";
+phy-mode = "rgmii-rxid";
+phy-handle = <&phy1>;
+};
+
+port@2 {
+reg = <2>;
+label = "lan2";
+
[PATCH 3/7] lantiq: add DTS for Fritzbox 3490
Signed-off-by: Torsten Duwe
---
.../boot/dts/lantiq/vr9_avm_fritz3490.dts | 58 +++
1 file changed, 58 insertions(+)
create mode 100644
target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritz3490.dts
diff --git
a/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritz3490.dts
b/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritz3490.dts
new file mode 100644
index 00..3e140a59cc
--- /dev/null
+++ b/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritz3490.dts
@@ -0,0 +1,58 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "vr9_avm_fritzx490.dtsi"
+
+/ {
+ compatible = "avm,fritz3490", "avm,fritzx490", "lantiq,xway",
"lantiq,vr9";
+ model = "AVM FRITZ!Box 3490";
+
+ aliases {
+ led-boot = &led_power;
+ led-failsafe = &led_info_red;
+ led-running = &led_power;
+ led-upgrade = &led_info_red;
+
+ led-dsl = &led_dsl;
+ led-internet = &led_lan;
+ led-wifi = &led_wlan;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ // led 5 "Power"
+ led_power: power {
+ label = "green:power";
+ gpios = <&gpio 45 GPIO_ACTIVE_LOW>;
+ default-state = "keep";
+ };
+
+ // led 4 "LAN"
+ led_lan: lan {
+ label = "green:lan";
+ gpios = <&gpio 47 GPIO_ACTIVE_LOW>;
+ };
+
+ // led 3 "WLAN"
+ led_wlan: wlan {
+ label = "green:wlan";
+ gpios = <&gpio 36 GPIO_ACTIVE_LOW>;
+ };
+
+ // led 2 "DSL"
+ led_dsl: dsl {
+ label = "green:dsl";
+ gpios = <&gpio 35 GPIO_ACTIVE_LOW>;
+ };
+
+ // led 1 "Info"
+ led_info_green: info_green {
+ label = "green:info";
+ gpios = <&gpio 33 GPIO_ACTIVE_LOW>;
+ };
+ led_info_red: info_red {
+ label = "red:info";
+ gpios = <&gpio 46 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
--
2.34.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 4/7] lantiq: add DTS for Fritzbox 5490
Signed-off-by: Torsten Duwe
---
.../boot/dts/lantiq/vr9_avm_fritz5490.dts | 98 +++
1 file changed, 98 insertions(+)
create mode 100644
target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritz5490.dts
diff --git
a/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritz5490.dts
b/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritz5490.dts
new file mode 100644
index 00..67933ff4a1
--- /dev/null
+++ b/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritz5490.dts
@@ -0,0 +1,98 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "vr9_avm_fritzx490.dtsi"
+
+/ {
+ compatible = "avm,fritz5490", "lantiq,xway", "lantiq,vr9";
+ model = "AVM FRITZ!Box 5490";
+
+ aliases {
+ led-boot = &led_power;
+ led-failsafe = &led_info_red;
+ led-running = &led_power;
+ led-upgrade = &led_info_red;
+
+ led-dsl = &led_info_green;
+ led-internet = &led_fon;
+ led-wifi = &led_wlan;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ // led 5 "Power"
+ led_power: power {
+ label = "green:power";
+ gpios = <&gpio 45 GPIO_ACTIVE_LOW>;
+ default-state = "keep";
+ };
+
+ // led 4 "Fiber"
+ led_fiber: fiber {
+ label = "green:fiber";
+ gpios = <&gpio 47 GPIO_ACTIVE_LOW>;
+ };
+
+ // led 3 "WLAN"
+ led_wlan: wlan {
+ label = "green:wlan";
+ gpios = <&gpio 36 GPIO_ACTIVE_LOW>;
+ };
+
+ // led 2 "Fon"
+ led_fon: fon {
+ label = "green:fon";
+ gpios = <&gpio 35 GPIO_ACTIVE_LOW>;
+ };
+
+ // led 1 "Info"
+ led_info_green: info_green {
+ label = "green:info";
+ gpios = <&gpio 33 GPIO_ACTIVE_LOW>;
+ };
+ led_info_red: info_red {
+ label = "red:info";
+ gpios = <&gpio 46 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
+
+&gswip_mdio {
+ phy0: ethernet-phy@0 {
+ status = "disabled";
+ };
+
+ phy1: ethernet-phy@1 {
+ status = "disabled";
+ };
+
+ phy5: ethernet-phy@5 {
+ reg = <0x05>;
+ // reset-gpios = <&gpio ?? GPIO_ACTIVE_LOW>;
+ };
+
+ // fiber - qca8033 (serdes transceiver) - port0
+ phy6: ethernet-phy@6 {
+ reg = <0x06>;
+ reset-gpios = <&gpio 32 GPIO_ACTIVE_LOW>;
+ };
+ phy9: ethernet-phy@9 {
+ reg = <0x09>;
+ // reset-gpios = <&gpio ?? GPIO_ACTIVE_LOW>;
+ };
+
+};
+
+&gswip_ports {
+ // FIXME: this is guesswork!
+ port@0 {
+ reg = <0>;
+ label = "fiber";
+ phy-mode = "rgmii-rxid";
+ phy-handle = <&phy6>;
+ };
+ port@1 { // ? label = "lan?";
+ phy-handle = <&phy5>;
+ };
+ // port@? { label = "lan?"; phy-handle = <&phy9>;
+};
--
2.34.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 5/7] lantiq: add DTS for Fritzbox 7490
Signed-off-by: Torsten Duwe
---
.../boot/dts/lantiq/vr9_avm_fritz7490.dts | 61 +++
1 file changed, 61 insertions(+)
create mode 100644
target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritz7490.dts
diff --git
a/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritz7490.dts
b/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritz7490.dts
new file mode 100644
index 00..55d6b92523
--- /dev/null
+++ b/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritz7490.dts
@@ -0,0 +1,61 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "vr9_avm_fritzx490.dtsi"
+
+#include
+#include
+
+/ {
+ compatible = "avm,fritz7490", "avm,fritzx490", "lantiq,xway",
"lantiq,vr9";
+ model = "AVM FRITZ!Box 7490";
+
+ aliases {
+ led-boot = &led_power;
+ led-failsafe = &led_info_red;
+ led-running = &led_power;
+ led-upgrade = &led_info_red;
+
+ led-dsl = &led_info_green;
+ led-internet = &led_internet;
+ led-wifi = &led_wlan;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ // led 5 "Power/DSL"
+ led_power: power {
+ label = "green:power";
+ gpios = <&gpio 45 GPIO_ACTIVE_LOW>;
+ default-state = "keep";
+ };
+
+ // led 4 "Internet"
+ led_internet: internet {
+ label = "green:internet";
+ gpios = <&gpio 47 GPIO_ACTIVE_LOW>;
+ };
+
+ // led 3 "FixedLine"
+ led_fixedline: fixedline {
+ label = "green:fixedline";
+ gpios = <&gpio 36 GPIO_ACTIVE_LOW>;
+ };
+
+ // led 2 "WLAN"
+ led_wlan: wlan {
+ label = "green:wlan";
+ gpios = <&gpio 35 GPIO_ACTIVE_LOW>;
+ };
+
+ // led 1 "Info"
+ led_info_green: info_green {
+ label = "green:info";
+ gpios = <&gpio 33 GPIO_ACTIVE_LOW>;
+ };
+ led_info_red: info_red {
+ label = "red:info";
+ gpios = <&gpio 46 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
--
2.34.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 6/7] lantiq: add image handling for x490 Fritzboxes
Enable building Fritzbox x490 images, with UBI. The default is 252KiB LEB size and 4k I/O, and the 7490 overriding it with half of those values. Signed-off-by: Torsten Duwe --- I'm uncertain about the difference between UBIFS_OPTS and MKUBIFS_OPTS. MKUBIFS_OPTS is declared per device, but UBIFS_OPTS are always prepended, even with some ubinize calls. The final sysupgrade-tar uses an FS image made with UBIFS_OPTS (?). As a result, I was unable to build working ubifs-sysupgrades for multiple targets in one run. Am I missing something or is this a bug? The benefits of those eva-*.bin files are also unclear to me; I left them in as they were. --- target/linux/lantiq/image/vr9.mk | 45 +++ .../xrx200/base-files/etc/board.d/01_leds | 3 +- .../xrx200/base-files/etc/board.d/02_network | 10 - .../xrx200/base-files/lib/upgrade/platform.sh | 3 ++ target/linux/lantiq/xrx200/target.mk | 2 +- 5 files changed, 60 insertions(+), 3 deletions(-) diff --git a/target/linux/lantiq/image/vr9.mk b/target/linux/lantiq/image/vr9.mk index d17045b6db..9ebb981811 100644 --- a/target/linux/lantiq/image/vr9.mk +++ b/target/linux/lantiq/image/vr9.mk @@ -147,6 +147,37 @@ define Device/avm_fritz3390 endef TARGET_DEVICES += avm_fritz3390 +define Device/avm_fritzx490 + $(Device/dsa-migration) + $(Device/AVM) + $(Device/NAND) + KERNEL_SIZE := 4096k + IMAGE_SIZE := 49152k + BLOCKSIZE := 256k + PAGESIZE:= 4096 + UBIFS_OPTS := -m 4096 -e 252KiB -c 256 + MKUBIFS_OPTS := -m 4096 -e 252KiB -c 256 + UBINIZE_OPTS := -E 5 + DEVICE_PACKAGES := kmod-usb3 fritz-tffs wasp_uploader +endef + +define Device/avm_fritz3490 + $(Device/avm_fritzx490) + DEVICE_MODEL := FRITZ!Box 3490 + DEVICE_PACKAGES += -kmod-owl-loader -dsl-vrx200-firmware-xdsl-a -dsl-vrx200-firmware-xdsl-b-patch +endef +TARGET_DEVICES += avm_fritz3490 + +define Device/avm_fritz5490 + $(Device/avm_fritzx490) + DEVICE_MODEL := FRITZ!Box 5490 + DEVICE_PACKAGES += -kmod-owl-loader + IMAGES += eva-kernel.bin eva-filesystem.bin + IMAGE/eva-kernel.bin := append-kernel + IMAGE/eva-filesystem.bin := append-ubi +endef +TARGET_DEVICES += avm_fritz5490 + define Device/avm_fritz7360sl $(Device/dsa-migration) $(Device/AVM) @@ -201,6 +232,20 @@ define Device/avm_fritz7430 endef TARGET_DEVICES += avm_fritz7430 +define Device/avm_fritz7490 + $(Device/avm_fritzx490) + DEVICE_MODEL := FRITZ!Box 7490 + BLOCKSIZE := 128k + PAGESIZE := 2048 + UBIFS_OPTS := -m 2048 -e 126KiB -c 512 + MKUBIFS_OPTS := -m 2048 -e 126KiB -c 512 + DEVICE_PACKAGES += -kmod-owl-loader -dsl-vrx200-firmware-xdsl-a -dsl-vrx200-firmware-xdsl-b-patch + IMAGES += eva-kernel.bin eva-filesystem.bin + IMAGE/eva-kernel.bin := append-kernel + IMAGE/eva-filesystem.bin := append-ubi +endef +TARGET_DEVICES += avm_fritz7490 + define Device/bt_homehub-v5a $(Device/dsa-migration) $(Device/NAND) diff --git a/target/linux/lantiq/xrx200/base-files/etc/board.d/01_leds b/target/linux/lantiq/xrx200/base-files/etc/board.d/01_leds index bac3ed2b53..a01b5e6b67 100644 --- a/target/linux/lantiq/xrx200/base-files/etc/board.d/01_leds +++ b/target/linux/lantiq/xrx200/base-files/etc/board.d/01_leds @@ -39,7 +39,8 @@ arcadyan,vgv7519-brn) ;; avm,fritz3370-rev2-hynix|\ avm,fritz3370-rev2-micron|\ -avm,fritz3390) +avm,fritz3390|\ +avm,fritz7490) ucidef_set_led_switch "lan" "LAN" "green:lan" "switch0" "0x17" ;; bt,homehub-v5a) diff --git a/target/linux/lantiq/xrx200/base-files/etc/board.d/02_network b/target/linux/lantiq/xrx200/base-files/etc/board.d/02_network index 3122d40c92..d92e7718d1 100644 --- a/target/linux/lantiq/xrx200/base-files/etc/board.d/02_network +++ b/target/linux/lantiq/xrx200/base-files/etc/board.d/02_network @@ -32,10 +32,13 @@ lantiq_setup_interfaces() avm,fritz3370-rev2-hynix|\ avm,fritz3370-rev2-micron|\ avm,fritz3390|\ + avm,fritz3490|\ + avm,fritz5490|\ avm,fritz7360sl|\ avm,fritz7360-v2|\ avm,fritz7362sl|\ avm,fritz7430|\ + avm,fritz7490|\ buffalo,wbmr-300hpd|\ tplink,tdw8970|\ tplink,tdw8980|\ @@ -64,10 +67,13 @@ lantiq_setup_dsl() avm,fritz3370-rev2-hynix|\ avm,fritz3370-rev2-micron|\ avm,fritz3390|\ + avm,fritz3490|\ + avm,fritz5490|\ avm,fritz7360sl|\ avm,fritz7362sl|\ avm,fritz7412|\ - avm,fritz7430) + avm,fritz7430|\ + avm,fritz7490) annex="b" ;; esac @@ -114,6 +120,8 @@ lantiq_setup_macs() wan_mac=$(macaddr_add "$(mtd_get_mac_binary urlader 0xa91)" 1) ;; avm,fritz3390|\ + avm,fritz3490|\ + avm,fritz7490|\ avm,fritz7362sl) lan_mac=$(fritz_tffs -n maca -i $(find_mtd_part "tffs (1)")) wan_mac=$(fritz_tffs -
[PATCH 7/7] lantiq: add renesas USB3 support
Enable the USB_XHCI_PCI_RENESAS config option on lantiq and note the usb3 dependency. The XHCI host controller requires a firmware blob, see https://forum.openwrt.org/t/2071 Signed-off-by: Torsten Duwe --- package/kernel/linux/modules/usb.mk | 1 + target/linux/lantiq/config-5.10 | 2 ++ 2 files changed, 3 insertions(+) diff --git a/package/kernel/linux/modules/usb.mk b/package/kernel/linux/modules/usb.mk index f74c02a99f..72bdce4bd8 100644 --- a/package/kernel/linux/modules/usb.mk +++ b/package/kernel/linux/modules/usb.mk @@ -1713,6 +1713,7 @@ define KernelPackage/usb3 +TARGET_bcm53xx:kmod-phy-bcm-ns-usb3 \ +TARGET_ramips_mt7621:kmod-usb-xhci-mtk \ +(TARGET_apm821xx_nand&&LINUX_5_10):kmod-usb-xhci-pci-renesas \ + +TARGET_lantiq:kmod-usb-xhci-pci-renesas \ +TARGET_mvebu_cortexa9:kmod-usb-xhci-pci-renesas KCONFIG:= \ CONFIG_USB_PCI=y \ diff --git a/target/linux/lantiq/config-5.10 b/target/linux/lantiq/config-5.10 index a830689e23..9e7874bd5d 100644 --- a/target/linux/lantiq/config-5.10 +++ b/target/linux/lantiq/config-5.10 @@ -220,5 +220,7 @@ CONFIG_SYS_SUPPORTS_VPE_LOADER=y CONFIG_TARGET_ISA_REV=2 CONFIG_TICK_CPU_ACCOUNTING=y CONFIG_TINY_SRCU=y +CONFIG_USB_XHCI_PCI=y +CONFIG_USB_XHCI_PCI_RENESAS=y CONFIG_USE_OF=y CONFIG_WATCHDOG_CORE=y -- 2.34.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 6/7] lantiq: add image handling for x490 Fritzboxes
On Thu, 3 Feb 2022 07:12:40 +0100 Andreas Böhler wrote: > > + DEVICE_PACKAGES := kmod-usb3 fritz-tffs wasp_uploader > > +endef > > + > Is wasp_uploader really in an official package feed? I don't know. As mentioned, I mostly ignored the secondary system for now, and -master, with exactly these 7 patches, compiled and ran fine here. I have not used any additional feeds. I'd really like to leave those "loose ends", so it is clear where the WIFI system, once provided, should hook in (see gswip port, reset etc. in the DTs). Torsten ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 0/7] lantiq: initial support for x490 Fritzboxes
On Sat, 12 Feb 2022 02:05:17 +0100 Mathias Kresin wrote: > > 2/11/22 23:39, kestrel1...@t-online.de: > > Hi, > > > > I have created a new PR: > > https://github.com/openwrt/openwrt/pull/5074 > > > > Which also includes a remote processor framework kernel module, Cramming it all into one big commit makes it hard to review and test. LKML is therefore pretty strict to receive minimal changes that do not break anything (-> bisect); I tried to transform the required changes accordingly. The WiFi system has the same architecture, sure, so it can be compiled by the same toolchain. OTOH, the main system has everything but WiFi, and the secondary system has nothing but WiFi, so I doubt that compiling both kernels from one source is a good thing, unless the kernel code memory can be physically shared (haven't checked), or the whole kernel can be properly modularised. This should be discussed first, and in the meantime discrete support patches for the main system should be acceptable. [...] > > Looking at your submitted patches, many fritzbox devices have > > different NAND manufacturers. The question is, does their geometry differ across specimen of the same model? Maybe with different manufacturing runs? > > So the best way is to support all. No contradiction from my side. > > I created a DTB and image configuration for Micron and non Micron > > NAND. This is probably the best way and not supporting just one > > NAND type per device. Unfortunately auto detection was not accepted > > by the kernel maintainers, so there is no other solution. > > > > I also saw the addition of ubifs. I have not used this so far and I > > wonder what the advantage is over using squashfs with overlay? > > Let me cite https://en.wikipedia.org/wiki/UBIFS > > - tracking NAND flash bad blocks > - providing wear leveling > > NAND is a rather unreliable type of flash, hence some special > treatment has to be done to make it last as long as possible. Yes, I somehow had gotten the impression that UBI was mandatory for OpenWRT ports to new devices with NAND, so I went that way. Is sysupgrade prepared for squashfs+overlay as UBI volumes? Torsten ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Bridge-vlan bug? (mt7621/DSA)
On Sat, 6 Aug 2022 11:58:49 +0200 Thibaut wrote: > > > Le 6 août 2022 à 00:50, Mark Mentovai a écrit : > > Thanks a lot for these details. Based on your input and looking at > our current 5.10 source and the current upstream, it seems this might > have already been fixed upstream: > > https://github.com/torvalds/linux/commit/0b69c54c74bcb60e834013ccaf596caf05156a8e > > I’ll check if this can be backported without too much fuss. FWIW, I think I have tracked down a similar issue on lantiq xrx200, abused as a simple AP. Roaming / handover to it resulted in a ~30% chance of described blackout. All WiFi traffic is tagged. I found that the packets directed at the station disappeared inside the lantiq HW switch. MAC address query on the switch showed the station's MAC was still on the outside, upstream LAN port (Layer 2 bridge of all APs) When I replaced the xrx200 with an Atheros QCA9563 (same OpenWRT-22.03, similar configuration) the issue went away, so I concluded an unfixable hardware issue. Didn't know there was a workaround. Long story short: lantiq might also benefit from this. Thanks, Torsten ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] base-files: Don't enable ULA IPv6 addresses by default in new config
On Thu, 8 Sep 2022 19:51:06 +0200
Thibaut wrote:
> The issue was random. The client had a GUA assigned, below is the ipv6
> routing table at the time of the issue:
>
> $ ip -6 route
> 2a0e:e701:11c2::/64 dev bond0 proto kernel metric 256 expires 7082sec pref
> medium
> fdc9:6d06:832a::/64 dev bond0 proto kernel metric 256 pref medium
So AFAICS here lies the problem. Same metric, same preference.
The addresses below are usually tagged link local somewhere, but
I assume the ULA is not.
> fe80::/64 dev bond0 proto kernel metric 256 pref medium
> fe80::/64 dev bond0.10 proto kernel metric 256 pref medium
> default via fe80::184f:a7ff:fe21:d230 dev bond0 proto ra metric 1024 expires
> 1793sec mtu 1492 hoplimit 64 pref medium
>
> For that matter, this setup only uses SLAAC (no DHCPv6 on LAN).
>
> Disabling ULA « fixes » this issue.
Sure. Above, it looks like a game of chance which address is used.
From my understanding, router.lan would need to be told to do IPv6 NAT
if clients are to reach outside with their ULAs, right?
If I get a vote, I'd enable ULA generation only iff an IPv6 NAT was also
configured, and, last but not least, I wouldn't randomise it. I'd go for
e.g. fd00:4f57:5254 ("OWRT"), like all AVR use 192.168.178.0/24 on v4.
Torsten
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: qoriq: Problem with u-boot compilation (dual arch issue)
On Wed, 5 Oct 2022 16:13:30 +0200 Paweł Dembicki wrote: > Hi everybody, > > I am preparing support for the T4240RDB board. But I'm stuck with one problem: > > Qoriq target is powerpc64. But T4240RDB in u-boot is supported as > mpc85xx family and requires a 32-bit compiler. > > I tried setting OpenWrt config: EXTRA_TARGET_ARCH to y and > EXTRA_TARGET_ARCH_NAME to powerpc32. But it didn't work: Depending on the context, the name may also be something like "ppc", "ppc64" or "ppc64le", JFYI. [...] > I see two possible solutions: > 1. Compile u-boot with regular powerpc compiler > 2. Fix settings in powerpc64 linker to allow build 32-bit arch binary. > > Can I ask for help with it? Without looking at the details (makes suggestions easier ;-) you may get by with dropping "-m32" or "-m64" into CFLAGS here and there, presumed your toolchain has support for both. Torsten ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 0/7] 22.03 lantiq: add support for x490 Fritzboxes
Hi all,
Here is my second attempt for initial FritzBox x490 support. 22.03 now
has all the necessary prerequisites, so support can be added according
to the rules.
The original code snippets were submitted by John Crispin (IIRC),
Andreas Böhler and Daniel Kestrel. I carved out the changes I
considered necessary, integrated and tested them and cleaned them up
(hopefully ;)
These are the minimal changes required to run the FB {3,7}490 as DSL
router (tested!). The 5490 is reported to be similar, so I included
it, but could not test it due to lack of hardware.
The wireless on these boxes is offloaded to a secondary SoC which
needs to be provided its own OS. This feature is explicitly left out
here in order to go step by step. I kept some loose ends where they
don't hurt, for future reference.
Changes from v1:
* return to squashfs for the rootfs; ubifs causes too much complexity
esp. for updates, when even the same model can be equipped with
varying flash chip geometries. UBI partitioning and volumes are kept
though.
Torsten Duwe (7):
lantiq: fix endianess for PCIe slave XBAR
lantiq: add common device tree template for x490 Fritzboxes
lantiq: add DTS for Fritzbox 3490
lantiq: add DTS for Fritzbox 5490
lantiq: add DTS for Fritzbox 7490
lantiq: add image handling for x490 Fritzboxes
lantiq: add renesas USB3 support
package/kernel/linux/modules/usb.mk | 1 +
target/linux/lantiq/config-5.10 | 2 +
.../boot/dts/lantiq/vr9_avm_fritz3490.dts | 58 +
.../boot/dts/lantiq/vr9_avm_fritz5490.dts | 98 +++
.../boot/dts/lantiq/vr9_avm_fritz7490.dts | 61 +
.../boot/dts/lantiq/vr9_avm_fritzx490.dtsi| 240 ++
target/linux/lantiq/image/vr9.mk | 30 +++
...q-ifxmips_pcie-fix-slave-XBAR-endian.patch | 45
.../xrx200/base-files/etc/board.d/01_leds | 3 +-
.../xrx200/base-files/etc/board.d/02_network | 10 +-
.../xrx200/base-files/lib/upgrade/platform.sh | 3 +
11 files changed, 549 insertions(+), 2 deletions(-)
create mode 100644
target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritz3490.dts
create mode 100644
target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritz5490.dts
create mode 100644
target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritz7490.dts
create mode 100644
target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritzx490.dtsi
create mode 100644
target/linux/lantiq/patches-5.10/0156-lantiq-ifxmips_pcie-fix-slave-XBAR-endian.patch
--
2.35.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 1/7] lantiq: fix endianess for PCIe slave XBAR
On some lantiq targets the AHB slave XBAR is wired up big endian.
Allow specific targets to trigger a byte swap via a device tree
property when this is required.
Signed-off-by: Torsten Duwe
---
...q-ifxmips_pcie-fix-slave-XBAR-endian.patch | 45 +++
1 file changed, 45 insertions(+)
create mode 100644
target/linux/lantiq/patches-5.10/0156-lantiq-ifxmips_pcie-fix-slave-XBAR-endian.patch
diff --git
a/target/linux/lantiq/patches-5.10/0156-lantiq-ifxmips_pcie-fix-slave-XBAR-endian.patch
b/target/linux/lantiq/patches-5.10/0156-lantiq-ifxmips_pcie-fix-slave-XBAR-endian.patch
new file mode 100644
index 00..f6c7e757c9
--- /dev/null
+++
b/target/linux/lantiq/patches-5.10/0156-lantiq-ifxmips_pcie-fix-slave-XBAR-endian.patch
@@ -0,0 +1,45 @@
+--- a/arch/mips/pci/ifxmips_pcie_vr9.h
b/arch/mips/pci/ifxmips_pcie_vr9.h
+@@ -33,6 +33,7 @@
+ #define IFX_RCU_AHB_BE_PCIE_M0x0001 /* Configure AHB
master port that connects to PCIe RC in big endian */
+ #define IFX_RCU_AHB_BE_PCIE_S0x0010 /* Configure AHB
slave port that connects to PCIe RC in little endian */
+ #define IFX_RCU_AHB_BE_XBAR_M0x0002 /* Configure AHB
master port that connects to XBAR in big endian */
++#define IFX_RCU_AHB_BE_XBAR_S0x0008 /* Configure AHB
slave port that connects to XBAR in big endian */
+ #define CONFIG_IFX_PCIE_PHY_36MHZ_MODE
+
+ #define IFX_PMU1_MODULE_PCIE_PHY (0)
+--- a/arch/mips/pci/ifxmips_pcie.c
b/arch/mips/pci/ifxmips_pcie.c
+@@ -51,6 +51,7 @@ static int pcie_reset_gpio;
+ static struct phy *ltq_pcie_phy;
+ static struct reset_control *ltq_pcie_reset;
+ static struct regmap *ltq_rcu_regmap;
++static bool switch_pcie_endianess;
+
+ static ifx_pcie_irq_t pcie_irqs[IFX_PCIE_CORE_NR] = {
+ {
+@@ -1024,6 +1025,10 @@ pcie_rc_initialize(int pcie_port)
+ #ifdef CONFIG_IFX_PCIE_HW_SWAP
+ regmap_update_bits(ltq_rcu_regmap, 0x4c, IFX_RCU_AHB_BE_PCIE_S,
+ IFX_RCU_AHB_BE_PCIE_S);
++ if (switch_pcie_endianess) {
++ regmap_update_bits(ltq_rcu_regmap, 0x4c, IFX_RCU_AHB_BE_XBAR_S,
++ IFX_RCU_AHB_BE_XBAR_S);
++ }
+ #else
+ regmap_update_bits(ltq_rcu_regmap, 0x4c, IFX_RCU_AHB_BE_PCIE_S,
+ 0x0);
+@@ -1124,6 +1129,13 @@ static int ifx_pcie_bios_probe(struct pl
+ return PTR_ERR(ltq_pcie_phy);
+ }
+
++if(of_property_read_bool(node, "lantiq,switch-pcie-endianess")) {
++switch_pcie_endianess = true;
++dev_info(&pdev->dev, "switch pcie endianess requested\n");
++} else {
++switch_pcie_endianess = false;
++}
++
+ ltq_pcie_reset = devm_reset_control_get_shared(&pdev->dev, NULL);
+ if (IS_ERR(ltq_pcie_reset)) {
+ dev_err(&pdev->dev, "failed to get the PCIe reset line\n");
--
2.35.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 2/7] lantiq: add common device tree template for x490 Fritzboxes
These devices (based on xrx200/VR9) replace the internal dwc2 USB2
with an external renesas USB3 controller, attached via PCIe.
The whole wireless hardware is offloaded to a secondary SoC with
an ethernet connection from the built-in switch.
This DTS describes the GSWIP in DSA mode, and defaults to UBI
for the major part of the NAND flash.
Signed-off-by: Torsten Duwe
---
.../boot/dts/lantiq/vr9_avm_fritzx490.dtsi| 240 ++
1 file changed, 240 insertions(+)
create mode 100644
target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritzx490.dtsi
diff --git
a/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritzx490.dtsi
b/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritzx490.dtsi
new file mode 100644
index 00..057bcf6b93
--- /dev/null
+++ b/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritzx490.dtsi
@@ -0,0 +1,240 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "vr9.dtsi"
+
+#include
+#include
+
+/ {
+ compatible = "avm,fritzx490", "lantiq,xway", "lantiq,vr9";
+
+ chosen {
+ bootargs = "console=ttyLTQ0,115200";
+ };
+
+ memory@0 {
+device_type = "memory";
+reg = <0x0 0x1000>;
+ };
+
+ keys {
+ compatible = "gpio-keys-polled";
+ poll-interval = <100>;
+
+ wps {
+ // boxes with (unsupported) telephony HW have DECT here
+ label = "wps";
+ gpios = <&gpio 1 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+
+ wifi {
+ label = "wifi";
+ gpios = <&gpio 29 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+ };
+
+ gpio-export {
+ compatible = "gpio-export";
+
+ gpio_wasp_reset {
+ gpio-export,name = "wasp:reset";
+ gpio-export,output = <1>;
+ gpios = <&gpio 34 GPIO_ACTIVE_HIGH>;
+ };
+
+ gpio_wasp_wakeup {
+ gpio-export,name = "wasp:wakeup";
+ gpio-export,output = <1>;
+ gpios = <&gpio 5 GPIO_ACTIVE_HIGH>;
+ };
+ };
+};
+
+ð0 {
+ mtd-mac-address = <&urlader 0xcc>;
+ mtd-mac-address-increment = <1>;
+};
+
+&gphy0 {
+ lantiq,gphy-mode = ;
+};
+
+&gphy1 {
+ lantiq,gphy-mode = ;
+};
+
+&gpio {
+ pinctrl-names = "default";
+ pinctrl-0 = <&state_default>;
+ gpio-ranges = <&gpio 0 0 56>;
+
+ state_default: pinmux {
+ phy-rst {
+ lantiq,pins = "io32", "io44";
+ lantiq,pull = <0>;
+ lantiq,open-drain;
+ lantiq,output = <1>;
+ };
+
+ pcie-rst {
+ lantiq,pins = "io21";
+ lantiq,open-drain;
+ lantiq,output = <1>;
+ };
+ };
+
+ pcie-rst-dev {
+ gpio-hog;
+ line-name = "pcie-rst-dev";
+ gpios = <22 GPIO_ACTIVE_LOW>;
+ output-low;
+ };
+
+ usb-vbus {
+ gpio-hog;
+ line-name = "usb-vbus";
+ gpios = <14 GPIO_ACTIVE_HIGH>;
+ output-high;
+ };
+};
+
+&gswip {
+pinctrl-0 = <&mdio_pins>;
+pinctrl-names = "default";
+};
+
+&gswip_mdio {
+phy0: ethernet-phy@0 {
+reg = <0x00>;
+reset-gpios = <&gpio 32 GPIO_ACTIVE_LOW>;
+};
+
+phy1: ethernet-phy@1 {
+reg = <0x01>;
+reset-gpios = <&gpio 44 GPIO_ACTIVE_LOW>;
+};
+
+phy11: ethernet-phy@11 {
+reg = <0x11>;
+};
+
+phy13: ethernet-phy@13 {
+reg = <0x13>;
+};
+};
+
+&gswip_ports {
+port@0 {
+reg = <0>;
+label = "lan3";
+phy-mode = "rgmii-rxid";
+phy-handle = <&phy0>;
+};
+
+port@1 {
+reg = <1>;
+label = "lan4";
+phy-mode = "rgmii-rxid";
+phy-handle = <&phy1>;
+};
+
+port@2 {
+reg = <2>;
+label = "lan2";
+phy-mode = "interna
[PATCH v2 3/7] lantiq: add DTS for Fritzbox 3490
Signed-off-by: Torsten Duwe
---
.../boot/dts/lantiq/vr9_avm_fritz3490.dts | 58 +++
1 file changed, 58 insertions(+)
create mode 100644
target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritz3490.dts
diff --git
a/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritz3490.dts
b/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritz3490.dts
new file mode 100644
index 00..3e140a59cc
--- /dev/null
+++ b/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritz3490.dts
@@ -0,0 +1,58 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "vr9_avm_fritzx490.dtsi"
+
+/ {
+ compatible = "avm,fritz3490", "avm,fritzx490", "lantiq,xway",
"lantiq,vr9";
+ model = "AVM FRITZ!Box 3490";
+
+ aliases {
+ led-boot = &led_power;
+ led-failsafe = &led_info_red;
+ led-running = &led_power;
+ led-upgrade = &led_info_red;
+
+ led-dsl = &led_dsl;
+ led-internet = &led_lan;
+ led-wifi = &led_wlan;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ // led 5 "Power"
+ led_power: power {
+ label = "green:power";
+ gpios = <&gpio 45 GPIO_ACTIVE_LOW>;
+ default-state = "keep";
+ };
+
+ // led 4 "LAN"
+ led_lan: lan {
+ label = "green:lan";
+ gpios = <&gpio 47 GPIO_ACTIVE_LOW>;
+ };
+
+ // led 3 "WLAN"
+ led_wlan: wlan {
+ label = "green:wlan";
+ gpios = <&gpio 36 GPIO_ACTIVE_LOW>;
+ };
+
+ // led 2 "DSL"
+ led_dsl: dsl {
+ label = "green:dsl";
+ gpios = <&gpio 35 GPIO_ACTIVE_LOW>;
+ };
+
+ // led 1 "Info"
+ led_info_green: info_green {
+ label = "green:info";
+ gpios = <&gpio 33 GPIO_ACTIVE_LOW>;
+ };
+ led_info_red: info_red {
+ label = "red:info";
+ gpios = <&gpio 46 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
--
2.35.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 4/7] lantiq: add DTS for Fritzbox 5490
Signed-off-by: Torsten Duwe
---
.../boot/dts/lantiq/vr9_avm_fritz5490.dts | 98 +++
1 file changed, 98 insertions(+)
create mode 100644
target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritz5490.dts
diff --git
a/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritz5490.dts
b/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritz5490.dts
new file mode 100644
index 00..67933ff4a1
--- /dev/null
+++ b/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritz5490.dts
@@ -0,0 +1,98 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "vr9_avm_fritzx490.dtsi"
+
+/ {
+ compatible = "avm,fritz5490", "lantiq,xway", "lantiq,vr9";
+ model = "AVM FRITZ!Box 5490";
+
+ aliases {
+ led-boot = &led_power;
+ led-failsafe = &led_info_red;
+ led-running = &led_power;
+ led-upgrade = &led_info_red;
+
+ led-dsl = &led_info_green;
+ led-internet = &led_fon;
+ led-wifi = &led_wlan;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ // led 5 "Power"
+ led_power: power {
+ label = "green:power";
+ gpios = <&gpio 45 GPIO_ACTIVE_LOW>;
+ default-state = "keep";
+ };
+
+ // led 4 "Fiber"
+ led_fiber: fiber {
+ label = "green:fiber";
+ gpios = <&gpio 47 GPIO_ACTIVE_LOW>;
+ };
+
+ // led 3 "WLAN"
+ led_wlan: wlan {
+ label = "green:wlan";
+ gpios = <&gpio 36 GPIO_ACTIVE_LOW>;
+ };
+
+ // led 2 "Fon"
+ led_fon: fon {
+ label = "green:fon";
+ gpios = <&gpio 35 GPIO_ACTIVE_LOW>;
+ };
+
+ // led 1 "Info"
+ led_info_green: info_green {
+ label = "green:info";
+ gpios = <&gpio 33 GPIO_ACTIVE_LOW>;
+ };
+ led_info_red: info_red {
+ label = "red:info";
+ gpios = <&gpio 46 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
+
+&gswip_mdio {
+ phy0: ethernet-phy@0 {
+ status = "disabled";
+ };
+
+ phy1: ethernet-phy@1 {
+ status = "disabled";
+ };
+
+ phy5: ethernet-phy@5 {
+ reg = <0x05>;
+ // reset-gpios = <&gpio ?? GPIO_ACTIVE_LOW>;
+ };
+
+ // fiber - qca8033 (serdes transciever) - port0
+ phy6: ethernet-phy@6 {
+ reg = <0x06>;
+ reset-gpios = <&gpio 32 GPIO_ACTIVE_LOW>;
+ };
+ phy9: ethernet-phy@9 {
+ reg = <0x09>;
+ // reset-gpios = <&gpio ?? GPIO_ACTIVE_LOW>;
+ };
+
+};
+
+&gswip_ports {
+ // FIXME: this is guesswork!
+ port@0 {
+ reg = <0>;
+ label = "fiber";
+ phy-mode = "rgmii-rxid";
+ phy-handle = <&phy6>;
+ };
+ port@1 { // ? label = "lan?";
+ phy-handle = <&phy5>;
+ };
+ // port@? { label = "lan?"; phy-handle = <&phy9>;
+};
--
2.35.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 5/7] lantiq: add DTS for Fritzbox 7490
Signed-off-by: Torsten Duwe
---
.../boot/dts/lantiq/vr9_avm_fritz7490.dts | 61 +++
1 file changed, 61 insertions(+)
create mode 100644
target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritz7490.dts
diff --git
a/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritz7490.dts
b/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritz7490.dts
new file mode 100644
index 00..55d6b92523
--- /dev/null
+++ b/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritz7490.dts
@@ -0,0 +1,61 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "vr9_avm_fritzx490.dtsi"
+
+#include
+#include
+
+/ {
+ compatible = "avm,fritz7490", "avm,fritzx490", "lantiq,xway",
"lantiq,vr9";
+ model = "AVM FRITZ!Box 7490";
+
+ aliases {
+ led-boot = &led_power;
+ led-failsafe = &led_info_red;
+ led-running = &led_power;
+ led-upgrade = &led_info_red;
+
+ led-dsl = &led_info_green;
+ led-internet = &led_internet;
+ led-wifi = &led_wlan;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ // led 5 "Power/DSL"
+ led_power: power {
+ label = "green:power";
+ gpios = <&gpio 45 GPIO_ACTIVE_LOW>;
+ default-state = "keep";
+ };
+
+ // led 4 "Internet"
+ led_internet: internet {
+ label = "green:internet";
+ gpios = <&gpio 47 GPIO_ACTIVE_LOW>;
+ };
+
+ // led 3 "FixedLine"
+ led_fixedline: fixedline {
+ label = "green:fixedline";
+ gpios = <&gpio 36 GPIO_ACTIVE_LOW>;
+ };
+
+ // led 2 "WLAN"
+ led_wlan: wlan {
+ label = "green:wlan";
+ gpios = <&gpio 35 GPIO_ACTIVE_LOW>;
+ };
+
+ // led 1 "Info"
+ led_info_green: info_green {
+ label = "green:info";
+ gpios = <&gpio 33 GPIO_ACTIVE_LOW>;
+ };
+ led_info_red: info_red {
+ label = "red:info";
+ gpios = <&gpio 46 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
--
2.35.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 6/7] lantiq: add image handling for x490 Fritzboxes
Introduce FritzBox {3,5,7}490 model numbers to image makefiles
and startup configuration scripts where appropriate.
Signed-off-by: Torsten Duwe
---
target/linux/lantiq/image/vr9.mk | 30 +++
.../xrx200/base-files/etc/board.d/01_leds | 3 +-
.../xrx200/base-files/etc/board.d/02_network | 10 ++-
.../xrx200/base-files/lib/upgrade/platform.sh | 3 ++
4 files changed, 44 insertions(+), 2 deletions(-)
diff --git a/target/linux/lantiq/image/vr9.mk b/target/linux/lantiq/image/vr9.mk
index d17045b6db..df13ac73bc 100644
--- a/target/linux/lantiq/image/vr9.mk
+++ b/target/linux/lantiq/image/vr9.mk
@@ -147,6 +147,29 @@ define Device/avm_fritz3390
endef
TARGET_DEVICES += avm_fritz3390
+define Device/avm_fritzx490
+ $(Device/dsa-migration)
+ $(Device/AVM)
+ $(Device/NAND)
+ KERNEL_SIZE := 4096k
+ IMAGE_SIZE := 49152k
+ DEVICE_PACKAGES := kmod-usb3 fritz-tffs wasp_uploader
+endef
+
+define Device/avm_fritz3490
+ $(Device/avm_fritzx490)
+ DEVICE_MODEL := FRITZ!Box 3490
+ DEVICE_PACKAGES += -kmod-owl-loader
+endef
+TARGET_DEVICES += avm_fritz3490
+
+define Device/avm_fritz5490
+ $(Device/avm_fritzx490)
+ DEVICE_MODEL := FRITZ!Box 5490
+ DEVICE_PACKAGES += -kmod-owl-loader -dsl-vrx200-firmware-xdsl-a
-dsl-vrx200-firmware-xdsl-b-patch
+endef
+TARGET_DEVICES += avm_fritz5490
+
define Device/avm_fritz7360sl
$(Device/dsa-migration)
$(Device/AVM)
@@ -201,6 +224,13 @@ define Device/avm_fritz7430
endef
TARGET_DEVICES += avm_fritz7430
+define Device/avm_fritz7490
+ $(Device/avm_fritzx490)
+ DEVICE_MODEL := FRITZ!Box 7490
+ DEVICE_PACKAGES += -kmod-owl-loader
+endef
+TARGET_DEVICES += avm_fritz7490
+
define Device/bt_homehub-v5a
$(Device/dsa-migration)
$(Device/NAND)
diff --git a/target/linux/lantiq/xrx200/base-files/etc/board.d/01_leds
b/target/linux/lantiq/xrx200/base-files/etc/board.d/01_leds
index bac3ed2b53..a01b5e6b67 100644
--- a/target/linux/lantiq/xrx200/base-files/etc/board.d/01_leds
+++ b/target/linux/lantiq/xrx200/base-files/etc/board.d/01_leds
@@ -39,7 +39,8 @@ arcadyan,vgv7519-brn)
;;
avm,fritz3370-rev2-hynix|\
avm,fritz3370-rev2-micron|\
-avm,fritz3390)
+avm,fritz3390|\
+avm,fritz7490)
ucidef_set_led_switch "lan" "LAN" "green:lan" "switch0" "0x17"
;;
bt,homehub-v5a)
diff --git a/target/linux/lantiq/xrx200/base-files/etc/board.d/02_network
b/target/linux/lantiq/xrx200/base-files/etc/board.d/02_network
index 3122d40c92..d92e7718d1 100644
--- a/target/linux/lantiq/xrx200/base-files/etc/board.d/02_network
+++ b/target/linux/lantiq/xrx200/base-files/etc/board.d/02_network
@@ -32,10 +32,13 @@ lantiq_setup_interfaces()
avm,fritz3370-rev2-hynix|\
avm,fritz3370-rev2-micron|\
avm,fritz3390|\
+ avm,fritz3490|\
+ avm,fritz5490|\
avm,fritz7360sl|\
avm,fritz7360-v2|\
avm,fritz7362sl|\
avm,fritz7430|\
+ avm,fritz7490|\
buffalo,wbmr-300hpd|\
tplink,tdw8970|\
tplink,tdw8980|\
@@ -64,10 +67,13 @@ lantiq_setup_dsl()
avm,fritz3370-rev2-hynix|\
avm,fritz3370-rev2-micron|\
avm,fritz3390|\
+ avm,fritz3490|\
+ avm,fritz5490|\
avm,fritz7360sl|\
avm,fritz7362sl|\
avm,fritz7412|\
- avm,fritz7430)
+ avm,fritz7430|\
+ avm,fritz7490)
annex="b"
;;
esac
@@ -114,6 +120,8 @@ lantiq_setup_macs()
wan_mac=$(macaddr_add "$(mtd_get_mac_binary urlader 0xa91)" 1)
;;
avm,fritz3390|\
+ avm,fritz3490|\
+ avm,fritz7490|\
avm,fritz7362sl)
lan_mac=$(fritz_tffs -n maca -i $(find_mtd_part "tffs (1)"))
wan_mac=$(fritz_tffs -n macdsl -i $(find_mtd_part "tffs (1)"))
diff --git a/target/linux/lantiq/xrx200/base-files/lib/upgrade/platform.sh
b/target/linux/lantiq/xrx200/base-files/lib/upgrade/platform.sh
index ab01d3bbf7..bc4c1f1330 100755
--- a/target/linux/lantiq/xrx200/base-files/lib/upgrade/platform.sh
+++ b/target/linux/lantiq/xrx200/base-files/lib/upgrade/platform.sh
@@ -12,9 +12,12 @@ platform_do_upgrade() {
avm,fritz3370-rev2-hynix|\
avm,fritz3370-rev2-micron|\
avm,fritz3390|\
+ avm,fritz3490|\
+ avm,fritz5490|\
avm,fritz7362sl|\
avm,fritz7412|\
avm,fritz7430|\
+ avm,fritz7490|\
bt,homehub-v5a|\
zyxel,p-2812hnu-f1|\
zyxel,p-2812hnu-f3)
--
2.35.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 7/7] lantiq: add renesas USB3 support
Consider xhci-pci-renesas for USB3 on lantiq. Signed-off-by: Torsten Duwe --- package/kernel/linux/modules/usb.mk | 1 + target/linux/lantiq/config-5.10 | 2 ++ 2 files changed, 3 insertions(+) diff --git a/package/kernel/linux/modules/usb.mk b/package/kernel/linux/modules/usb.mk index 1fc3541f10..85045e93c1 100644 --- a/package/kernel/linux/modules/usb.mk +++ b/package/kernel/linux/modules/usb.mk @@ -1713,6 +1713,7 @@ define KernelPackage/usb3 +TARGET_bcm53xx:kmod-phy-bcm-ns-usb3 \ +TARGET_ramips_mt7621:kmod-usb-xhci-mtk \ +TARGET_apm821xx_nand:kmod-usb-xhci-pci-renesas \ + +TARGET_lantiq:kmod-usb-xhci-pci-renesas \ +TARGET_mvebu_cortexa9:kmod-usb-xhci-pci-renesas KCONFIG:= \ CONFIG_USB_PCI=y \ diff --git a/target/linux/lantiq/config-5.10 b/target/linux/lantiq/config-5.10 index 651a58f5cf..271fa736b6 100644 --- a/target/linux/lantiq/config-5.10 +++ b/target/linux/lantiq/config-5.10 @@ -222,5 +222,7 @@ CONFIG_SYS_SUPPORTS_VPE_LOADER=y CONFIG_TARGET_ISA_REV=2 CONFIG_TICK_CPU_ACCOUNTING=y CONFIG_TINY_SRCU=y +CONFIG_USB_XHCI_PCI=y +CONFIG_USB_XHCI_PCI_RENESAS=y CONFIG_USE_OF=y CONFIG_WATCHDOG_CORE=y -- 2.35.3 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 0/7] 22.03 lantiq: add support for x490 Fritzboxes
git neatly preserved all the time stamps :( patchwork however got the series: https://patchwork.ozlabs.org/project/openwrt/list/?series=324150 Sorry for the confusion. Torsten ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 0/7] 22.03 lantiq: add support for x490 Fritzboxes
On Tue, 25 Oct 2022 00:24:49 +0200 Hauke Mehrtens wrote: > On 10/23/22 13:19, Torsten Duwe wrote: > > Changes from v1: > > > > > > * return to squashfs for the rootfs; ubifs causes too much > > complexity esp. for updates, when even the same model can be > > equipped with varying flash chip geometries. UBI partitioning and > > volumes are kept though. > > Hi, > > How is this related to the pull request adding support for these > devices on github? > https://github.com/openwrt/openwrt/pull/5075 > > The pull request on github looks mostly ok to me, I just had some > minor questions. There's 2 major differences: most importantly, I ignore the secondary system for the WiFi, which I do not need. And secondly, see above, I returned the build to squashfs, which eliminates the need to look at the actual flash geometry (the -micron.dts variants in Daniel's version). Daniel goes for the 100% solution, including WiFi. My patch set is thus smaller, and IMHO suited for 22.03, whereas Daniel correctly targets master. Maybe we can at least unify the device tree source. Torsten ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH ustream-ssl] ustream-mbedtls: Use getrandom() instead of /dev/urandom
On Sat, 28 Jan 2023 19:41:13 +0100
Hauke Mehrtens wrote:
> Instead of keeping a file descriptor open just use the getrandom syscall
> to get random data. This is supported by the musl, glibc and Linux for
> some time now.
>
> This also improves the error handling in case this function returns not
> as many bytes as expected.
>
> Signed-off-by: Hauke Mehrtens
> ---
> ustream-mbedtls.c | 23 +--
> 1 file changed, 5 insertions(+), 18 deletions(-)
>
> diff --git a/ustream-mbedtls.c b/ustream-mbedtls.c
> index e79e37b..51ba2fa 100644
> --- a/ustream-mbedtls.c
> +++ b/ustream-mbedtls.c
> @@ -17,6 +17,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -25,8 +26,6 @@
> #include "ustream-ssl.h"
> #include "ustream-internal.h"
>
> -static int urandom_fd = -1;
> -
> static int s_ustream_read(void *ctx, unsigned char *buf, size_t len)
> {
> struct ustream *s = ctx;
> @@ -66,21 +65,12 @@ __hidden void ustream_set_io(struct ustream_ssl_ctx *ctx,
> void *ssl, struct ustr
> mbedtls_ssl_set_bio(ssl, conn, s_ustream_write, s_ustream_read, NULL);
> }
>
> -static bool urandom_init(void)
> -{
> - if (urandom_fd > -1)
> - return true;
> -
> - urandom_fd = open("/dev/urandom", O_RDONLY);
> - if (urandom_fd < 0)
> - return false;
> -
> - return true;
> -}
> -
> static int _urandom(void *ctx, unsigned char *out, size_t len)
> {
> - if (read(urandom_fd, out, len) < 0)
> + ssize_t ret;
> +
> + ret = getrandom(out, len, 0);
> + if (ret < 0 || (size_t)ret != len)
> return MBEDTLS_ERR_ENTROPY_SOURCE_FAILED;
[...]
drivers/char/random.c lines 1240- ...
* Reading from /dev/urandom has the same functionality as calling
* getrandom(2) with flags=GRND_INSECURE. Because it does not block
* waiting for the RNG to be ready, it should not be used.
Haven't audited mbedtls, but I assume it reads urandom for "lesser"
entropy when needed. In any case, getrandom(out, len, GRND_INSECURE)
would be the proper replacement.
Torsten
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH ustream-ssl] ustream-mbedtls: Use getrandom() instead of /dev/urandom
Hi Hauke! On Sun, 29 Jan 2023 17:08:38 +0100 Hauke Mehrtens wrote: > > drivers/char/random.c lines 1240- ... > > * Reading from /dev/urandom has the same functionality as calling > > * getrandom(2) with flags=GRND_INSECURE. Because it does not block > > * waiting for the RNG to be ready, it should not be used. > > > > Haven't audited mbedtls, but I assume it reads urandom for "lesser" > > entropy when needed. In any case, getrandom(out, len, GRND_INSECURE) > > would be the proper replacement. > > > > Torsten > > Hi Torsten, > > The mapage says this: > > By default, getrandom() draws entropy from the urandom source > > (i.e., the same source as the /dev/urandom device). This > > behavior can be changed via the flags argument. > https://man7.org/linux/man-pages/man2/getrandom.2.html > > GRND_INSECURE is also not documented in the man page. Well, it exists in the kernel source and headers... > The option was added to the Linux kernel 5.6 here: > https://git.kernel.org/linus/75551dbf112c992bc6c99a972990b3f272247e23 > > The documentation says > > GRND_INSECURE Return non-cryptographic random bytes > We want to use the random bytes in mbedtls for cryptographic > operations. I think giving no flags is the correct option here. > > I think the behavior of /dev/random changed some years ago. This > article described it a bit: https://lwn.net/Articles/808575/ That's only the internal workings. BTW, the mentioned quote of Andy Lutomirski applies here in some sense. You read away the true entropy and might even block on it when pseudo- randomness might suffice, see below. > As far as I understood the code, giving no flags will guarantee that > the random pool is initialized (crng_ready() returns true) and > otherwise it is the same as using GRND_INSECURE. As we use it for > cryptographic operations I think we should give no flags. "cryptographic operations" is a wide area. Some randomness is required, to varying degrees, for long-term keys, session keys, IVs and padding. Especially for long living keys, each end every bit should be totally unpredictable, which should correspond to read an appropriate amount from /dev/random. IVs and padding can be generated from a pseudo-RNG whose initial state is "uncertain enough", usually /dev/urandom. GIT is cool. c6e9d6f388947986 2014-Jul-17 tytso: introduce getrandom(2) system call 75551dbf112c992b 2019-Dec-23 luto: add GRND_INSECURE ... 48446f198f9adcb4 2019-Dec-23 luto: ignore GRND_RANDOM The first commit also has a man page in the comment, which is probably what was recorded. The second one changes the no-flags behaviour, away from the man page text you quoted. Someone once mentioned on LKML that drivers/char/random.c needs better maintenance... ;) I had a quick look at mbedtls and its usage of the provided rng function. It generates not only padding and IVs, but also session keys. Especially on OpenWRT these are a trade-off IMHO. OpenWRT supports a lot of hardware that is low on entropy at boot (MIPS anyone?) Do you want to block early ssh sessions, maybe even for minutes, or would you rather risk eavesdropping on those early connections? Depending on your choice for ustream, you can keep the proposed code, but please rename the functions to "random", not "urandom". Or you want to stick with the current urandom behaviour but then please add Luto's GRND_INSECURE flag to achieve that. HTH, Torsten ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH ustream-ssl] ustream-mbedtls: Use getrandom() instead of /dev/urandom
Hi Hauke! On Sun, 19 Feb 2023 21:06:15 +0100 Hauke Mehrtens wrote: > Hi Torsten, > > Sorry for the late answer, I forgot about this mail thread. No problem. > > On Sun, 29 Jan 2023 17:08:38 +0100 > > Hauke Mehrtens wrote: [...] > ustreamss uses the randomness to generate session keys (including > ephemeral keys), IVs and padding. The long term keys are generated in a > different application. [...] > > I think we should wait with creating TLS sessions till we have enough > random data to do it securely. I tested this on a lantiq xrx200 (MIPS) > device and it was initialized much before the LAN interface was up. ^^^ Yes. Good that it works out this way. Otherwise you'd have had a tough decision to make. > The code in ustream-mbedtls.c was probably initially written when > /dev/random was still blocking when too much entropy was read out of the > pool. I guess so, too. > I will rename the function. Cool. You can add my review tag if you want... Torsten ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH ustream-ssl v2] ustream-mbedtls: Use getrandom() instead of /dev/urandom
On Sun, 19 Feb 2023 21:11:12 +0100
Hauke Mehrtens wrote:
> Instead of keeping a file descriptor open just use the getrandom syscall
> to get random data. This is supported by the musl, glibc and Linux for
> some time now.
>
> This also improves the error handling in case this function returns not
> as many bytes as expected.
>
> Signed-off-by: Hauke Mehrtens
Reviewed-by: Torsten Duwe
> ---
> ustream-mbedtls.c | 25 ++---
> 1 file changed, 6 insertions(+), 19 deletions(-)
>
> changes since v1:
> * rename _urandom to _random
>
> diff --git a/ustream-mbedtls.c b/ustream-mbedtls.c
> index e79e37b..7fc7874 100644
> --- a/ustream-mbedtls.c
> +++ b/ustream-mbedtls.c
> @@ -17,6 +17,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -25,8 +26,6 @@
> #include "ustream-ssl.h"
> #include "ustream-internal.h"
>
> -static int urandom_fd = -1;
> -
> static int s_ustream_read(void *ctx, unsigned char *buf, size_t len)
> {
> struct ustream *s = ctx;
> @@ -66,21 +65,12 @@ __hidden void ustream_set_io(struct ustream_ssl_ctx *ctx,
> void *ssl, struct ustr
> mbedtls_ssl_set_bio(ssl, conn, s_ustream_write, s_ustream_read, NULL);
> }
>
> -static bool urandom_init(void)
> +static int _random(void *ctx, unsigned char *out, size_t len)
> {
> - if (urandom_fd > -1)
> - return true;
> + ssize_t ret;
>
> - urandom_fd = open("/dev/urandom", O_RDONLY);
> - if (urandom_fd < 0)
> - return false;
> -
> - return true;
> -}
> -
> -static int _urandom(void *ctx, unsigned char *out, size_t len)
> -{
> - if (read(urandom_fd, out, len) < 0)
> + ret = getrandom(out, len, 0);
> + if (ret < 0 || (size_t)ret != len)
> return MBEDTLS_ERR_ENTROPY_SOURCE_FAILED;
>
> return 0;
> @@ -134,9 +124,6 @@ __ustream_ssl_context_new(bool server)
> mbedtls_ssl_config *conf;
> int ep;
>
> - if (!urandom_init())
> - return NULL;
> -
> ctx = calloc(1, sizeof(*ctx));
> if (!ctx)
> return NULL;
> @@ -159,7 +146,7 @@ __ustream_ssl_context_new(bool server)
>
> mbedtls_ssl_config_defaults(conf, ep, MBEDTLS_SSL_TRANSPORT_STREAM,
> MBEDTLS_SSL_PRESET_DEFAULT);
> - mbedtls_ssl_conf_rng(conf, _urandom, NULL);
> + mbedtls_ssl_conf_rng(conf, _random, NULL);
>
> if (server) {
> mbedtls_ssl_conf_authmode(conf, MBEDTLS_SSL_VERIFY_NONE);
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] VDSL with TP-link tdw8970 / tdw8980
Hi all, I've been running both above boxes with ADSL Annex-B without problems, but now the Telekomedians changed the line to VDSL (Annex-J ?). I tried various settings with the xDSL firmware and startup, but keep getting at best: DOWN [0x300: handshake] DOWN [0x380: full_init] DOWN [0x1: exception] IOW: no "showtime". The box is marketed as "ADSL Annex-B", but the chipset is said to be VDSL-capable. OpenWRT lets me configure it so I can think of 2 possible reasons: 1. wrong xDSL firmware blob or configuration in the official download image openwrt-18.06.1-lantiq-xrx200-tplink_tdw8970-squashfs-sysupgrade.bin (tried that so we have some common ground for comparison) 2. TP-Link boxes will happily filter anything below 100kHz or so http://lists.infradead.org/pipermail/openwrt-devel/2017-July/008238.html Any pointers or definite arguments why it cannot work? Torsten ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] VDSL with TP-link tdw8970 / tdw8980
On Wed, 26 Sep 2018 13:08:22 +0200 Daniel Golle wrote: > The safe path is to use the VDSL-firmware-blob which is shipped in > T-Com's own Speedport router firmware. Sounds tempting... > See > https://xdarklight.github.io/lantiq-xdsl-firmware-info/ > Downloads for 5.6.8.4.1.7-5.6.7.2.1.2 > https://www.telekom.de/dlp/eki/downloads/Speedport/Speedport%20W%20921V/Firmware_Speedport_W921V_1.39.000.bin As we found out off-list, this blob got updated and has moved: https://github.com/xdarklight/lantiq-xdsl-firmware-info/issues/13 It establishes the connection here (slower than the blob below), with interleave, and then drops it almost immediately again! Sebastian Moeller suggested I use " 5.8.1.5.0.7-5.8.0.9.0.1 29de7210958de4ba57464685f680dd66e6fb5b36 898856 8.1.5 8.0.9 VDSL over ISDN incl. vectoring support " from the list, which did the trick. Thank you both for your quick and accurate help! (even if the speedport FW didn't quite work out -- maybe it does elsewhere) Thanks a lot! Torsten ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] kirkwood: DT flash partitioning broken
Hi all! I'm currently (re-)activating dockstars and found strange contents in OpenWRT's /proc/mtd. The root cause seem to be git commits 1447784a8c3 and 9808b9ae024, respectively. To my knowledge, the "reg" property in a device tree node is always of the form , _not_ . Could you please have a look? Torsten ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Adding a new platform: renesas rz
On Mon, 30 Oct 2023 21:40:02 +0100 Robert Marko wrote: > On Mon, 30 Oct 2023 at 10:40, Michele Bisogno > wrote: > > > > Hi, > > > > I've been a happy OpenWRT user for many years now, always buying > > routers that could allow me to run it easily. Same here :-) [...] > > > > For example, naming (renesas? renesas-rz? rz?) and structure of the > > subfolders. There are other variants I would like to add: RZ/G2LC, > > RZ/G2UL and maybe others. > > To me, just "renesas" sounds good and then you can introduce the > individual SoC families as subtargets. Renesas offers different architectures in their portfolio[1], I haven't dug into the OpenWRT build system for this issue yet to tell whether it is able to handle that at this folder level. Much of the above is "legacy" and does not run OpenWRT(?), but they also seem to aim for Risc-V. There is a platform called "ramips" and the broadcoms each have their own subdirectory. None of them have punctuation yet. Maybe call it "renesasrz"? They're also offering other ARM-based SoCs, and building common kernels might become difficult. Torsten [1] https://www.renesas.com/eu/en/products/microcontrollers-microprocessors/other-mcus-mpus ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Adding a new platform: renesas rz
Hi Michele, On Fri, 3 Nov 2023 09:04:08 +0100 Michele Bisogno wrote: > > is able to handle that at this folder level. Much of the above is > > "legacy" and does not run OpenWRT(?), but they also seem to aim for > > Risc-V. There is a platform called "ramips" and the broadcoms each > > have their own subdirectory. [...] > > what is listed there is old stuff. I thought so, thanks for the confirmation. > Renesas MPUs are now all under the RZ umbrella. The question then is: are they similar enough to build from one kernel source, or will they require different sets of patches? > Well, actually there are also the rcar devices, but these are > automotive SoCs. Yes, there is an RZ device that is not Arm: RZ/Five. > For now it is a single device based on a Andes core. Have you looked at the peripherials on the SoCs? Is RZ/Five identical to RZ/Arm in that respect? I've seen this at WinChipHead, for microcontrollers. The reasoning again would be whether it could be built from the same source code base. If not, how about "rzarm", leaving room for future "rzfive"? I know this sounds like bike shedding, but it might actually save some renaming work in the future. Naming it just "renesas" does not feel right, IMHO. Torsten ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / project update
On Mon, 29 Apr 2024 21:05:15 +0100
Daniel Golle wrote:
> Hi Michael,
>
> On Mon, Apr 29, 2024 at 03:04:37PM -0400, Michael Richardson wrote:
> >
> > {sorry for the long delay, been unwell}
> >
> > Bjørn Mork wrote:
> > > Maybe it is possible to deploy the system with secure boot
> > > and a protected IDevId key by default, but allowing the
> > > user/owner to erase the key and disable secure boot? This
> > > way all use cases could be supported, including playing with
> > > the BL2 code etc.
> >
> > It won't work that way. If someone can easily turn off secure
> > boot, then so can malware.
>
> Malware cannot remove or add a physical jumper or press a physical
> button on the board (we got a jumper to write-protect the SPI-NOR
> flash).
Correct, and IIRC a switch to choose which on-board flash to boot from?
This, plus the lockable boot block feature found in about all modern
flash chips is really all it takes to implement a really secure boot. It
is only a question of U-Boot patches, which can be 100% free and open
source software, absolutely no NDA required.
> Believing that secure boot could provide protection from malware also
> misses an important point: Most malware nowadays doesn't even strive
> for persistency but rather relies on exploitable run-time
> vulnerabilities. We are in an always-online world, the classic "boot
> sector virus" is an archaic thing from the 1980s.
Exactly. Thanks for the public reminder!
Torsten
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
