Re: [PATCH] kernal: skip hpower setting for the module which has no revs
照山周一郎 writes: > Thank you for your quick response. > It worked without any problems. Thanks for testing! I submitted this to netdev with a stable hint now. So it should end up in Linux v5.10.x, and therefore also OpenWrt, in a few weeks unless there are objections. Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] kernal: skip hpower setting for the module which has no revs
Thank you for your quick response. It worked without any problems. Attached is the log. Thanks for your great work! 2021年11月29日月曜日 Bjørn Mork : 2021年11月29日(月) 23:22 Bjørn Mork : > > Could you test if the attached patch fixes the issue for you? This > rearranges the tests in sfp_module_parse_power() so that your module is > silently accepted without reconfiguration - like it was before commit > 7cfa9c92d0a3. > > The module will still be rejected as EINVAL in case the host doesn't > support high power. > > We don't try to configure modules modules requiring the unsupported > Address Change Sequence. I see no reason to reject such modules even if > the host doesn't support high power, so I moved that block up in front > of the host power check. Completely untested since I don't have any > such module... > > This should not change anything for other types of modules. > > > Bjørn > -- 株式会社スプリングボード 照山 周一郎 teruy...@springboard-inc.jp http://www.springboard-inc.jp/ 〒110-0005 東京都台東区上野3丁目2番2号 アイオス秋葉原505号室 Tue Nov 30 06:58:18 UTC 2021 upgrade: Writing new UUID to /dev/mmcblk1... [47427.752887] EXT4-fs (mmcblk1p1): mounted filesystem without journal. Opts: (null) Tue Nov 30 06:58:19 UTC 2021 upgrade: Upgrade completed Tue Nov 30 06:58:20 UTC 2021 upgrade: Rebooting system... umount: can't unmount /dev: Resource busy umount: ca[47428.787596] reboot: Restarting system n't unmount /tmp BootROM - 2.03 Starting CP-1 IOROM 1.07 Booting from SPI NOR flash 1 (0x32) Found valid image at boot postion 0x000 lNOTICE: Starting binary extension NOTICE: SVC: DEV ID: 8040, FREQ Mode: 0xd NOTICE: SVC: AVS work point changed from 0x29 to 0x29 mv_ddr: mv_ddr-devel-18.12.0-g618dadd (Aug 15 2019 - 14:59:15) warning: mv_ddr4_dq_vref_calibration: subphy 1 vref tap 67 voltage noise mv_ddr: completed successfully NOTICE: Cold boot NOTICE: Booting Trusted Firmware NOTICE: BL1: v1.5(release):1f8ca7e0 (Marvell-devel-18.12.2) NOTICE: BL1: Built : 14:59:21, Aug 15 2019 NOTICE: BL1: Booting BL2 NOTICE: BL2: v1.5(release):1f8ca7e0 (Marvell-devel-18.12.2) NOTICE: BL2: Built : 14:59:23, Aug 15 2019 BL2: Initiating SCP_BL2 transfer to SCP NOTICE: SCP_BL2 contains 5 concatenated images NOTICE: Skipping MSS CP3 related image NOTICE: Skipping MSS CP2 related image NOTICE: Load image to CP1 MSS AP0 NOTICE: Loading MSS image from addr. 0x40269f4 Size 0x1cd8 to MSS at 0xf428 NOTICE: Done NOTICE: Load image to CP0 MSS AP0 NOTICE: Loading MSS image from addr. 0x40286cc Size 0x1cd8 to MSS at 0xf228 NOTICE: Done NOTICE: Load image to AP0 MSS NOTICE: Loading MSS image from addr. 0x402a3a4 Size 0x5420 to MSS at 0xf058 NOTICE: Done NOTICE: SCP Image doesn't contain PM firmware NOTICE: BL1: Booting BL31 lNOTICE: MSS PM is not supported in this build NOTICE: BL31: v1.5(release):1f8ca7e0 (Marvell-devel-18.12.2) NOTICE: BL31: Built : 14:59:27, Aug 15 2019 U-Boot 2019.07-5-ge0f089f802 (Aug 20 2019 - 15:10:29 +) DRAM: 16 GiB Comphy chip #0: Comphy-0: PEX0 Comphy-1: PEX0 Comphy-2: PEX0 Comphy-3: PEX0 Comphy-4: SFI Comphy-5: SATA1 Comphy chip #1: Comphy-0: SGMII11.25 Gbps Comphy-1: SATA0 Comphy-2: USB3_HOST0 Comphy-3: SATA1 Comphy-4: SFI Comphy-5: UNCONNECTED UTMI PHY 0 initialized to USB Host0 UTMI PHY 1 initialized to USB Host1 UTMI PHY 2 initialized to USB Host0 SATA link 0 timeout. SATA link 1 timeout. AHCI 0001. 32 slots 2 ports 6 Gbps 0x3 impl SATA mode flags: 64bit ncq led only pmp fbss pio slum part sxs PCIE-0: Link down MMC: sdhci@6e: 0, sdhci@78: 1 Loading Environment from SPI Flash... SF: Detected w25q32 with page size 256 Bytes, erase size 4 KiB, total 4 MiB OK Model: MACCHIATOBin-8040 Net: eth0: mvpp2-1 Hit any key to stop autoboot: 2 1 0 switch to partitions #0, OK mmc1 is current device 10184712 bytes read in 944 ms (10.3 MiB/s) 32171 bytes read in 16 ms (1.9 MiB/s) ## Flattened Device Tree blob at 04d0 Booting using the fdt blob at 0x4d0 Using Device Tree in place at 04d0, end 04d0adaa Starting kernel ... [0.00] Booting Linux on physical CPU 0x00 [0x410fd081] [0.00] Linux version 5.4.143 (pot.jp@mac-mini-server.local) (gcc version 8.4.0 (OpenWrt GCC 8.4.0 r16279-5cc0535800)) #0 SMP Tue Aug 31 22:20:08 2021 [0.00] Machine model: Marvell 8040 MACCHIATOBin Double-shot [0.00] psci: probing for conduit method from DT. [0.00] psci: PSCIv1.1 detected in firmware. [0.00] psci: Using standard PSCI v0.2 function IDs [0.00] psci: MIGRATE_INFO_TYPE not supported. [0.00] psci: SMC Calling Convention v1.1 [0.00] percpu: Embedded 16 pages/cpu s26584 r8192 d30760 u65536 [0.00] Detected PIPT I-cache on CPU0 [0.00] CPU features: detected: EL2 vector hardening [0.00] CPU features: detected: Branch predictor hardening [0.00] Speculative Store
Re: [PATCH 0/3] realtek: add support for Panasonic Switch-M8eG PN28080K
Hi Hauke, Thank you for the guidance. On 2021/11/30 6:37, Hauke Mehrtens wrote: On 11/12/21 10:00 PM, Sander Vanheule wrote: Hi, On Sun, 2021-10-03 at 15:53 +0900, INAGAKI Hiroshi wrote: [...] INAGAKI Hiroshi (3): realtek: enable pca953x driver for target realtek: enable gpio-restart driver in target realtek: add support for Panasonic Switch-M8eG PN28080K target/linux/realtek/config-5.10 | 4 + target/linux/realtek/config-5.4 | 4 + .../rtl8380_panasonic_m8eg-pn28080k.dts | 103 .../rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi | 216 + .../rtl8380_panasonic_m8eg-pn28080k.dts | 107 + .../rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi | 220 ++ target/linux/realtek/image/Makefile | 10 + 7 files changed, 664 insertions(+) create mode 100644 target/linux/realtek/dts-5.10/rtl8380_panasonic_m8eg-pn28080k.dts create mode 100644 target/linux/realtek/dts-5.10/rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi create mode 100644 target/linux/realtek/dts-5.4/rtl8380_panasonic_m8eg-pn28080k.dts create mode 100644 target/linux/realtek/dts-5.4/rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi I guess this is more a question for the maintainers: Since the realtek target now uses the 5.10 kernel in master, does it still make sense to add support for 5.4? Hiroshi has backported the upstream drivers for 5.10 (thanks again!), so both kernel version now have different quirks. Personnaly, I would prefer not to have to put any energy in 5.4 anymore. The realtek target already has KERNEL_PATCHVER set to 5.10 now. You do not have to add support for kernel 5.4 in your patches any more, if you want to it is fine with me, but we will probability delete the support for kernel 5.4 in 1 or 2 months anyway. If you need special workarounds for kernel 5.4 I would suggest to go with kernel 5.10 only. @Hiroshi I added some of the GPIO patches from Sander, could you please rebase your patch on top of that. I see, OK. I'm preparing the v2 patch rebased from master, without 5.4 changes :) Hauke Regards, Hiroshi ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ramips: add support for Zbtlink ZBT-WG1602
On Tue, Nov 16, 2021 at 2:14 AM Sergey Ryazanov wrote:
>
> Zbtlink ZBT-WG1602 is a Wi-Fi router intendent to use with WWAN
> (UMTS/LTE/3G/4G) modems. The router board offsers a couple of miniPCIe
> slots with USB and SIM only and another one pure miniPCIe slot as well
> as five Gigabit Ethernet ports (4xLAN + WAN).
>
> Specification:
>
> * SoC: MT7621A
> * RAM: 256/512 MiB
> * Flash: 16/32 MiB (SPI NOR)
> * external watchdog (looks like Torexsemi XC6131B)
> * Eth: 10/100/100 Mbps Ethernet x5 ports (4xLAN + WAN)
> * WLAN 2GHz: MT7603EN (.11n, MIMO 2x2)
> * WLAN 5GHz: MT7612EN (.11ac, MIMO 2x2)
> * WLAN Ants: detachable x2, shared by 2GHz & 5GHz radios
> * miniPCIe: 2x slots with USB + 1x slot with regular PCIe bus
> * WWAN Ants: detachable x4
> * External storage: microSD (SDXC) slot
> * USB: 2.0 Type-A port
> * LED: 11 (5 per Eth phy, 3 SoC controlled, 2 WLAN 2/5 controlled, 1
>power indicator)
switch LEDs can be controlled now. See
https://github.com/openwrt/openwrt/commit/360c181dd747f033cb61f83915ce277c6497720f
> * Button: 1 (reset)
> * UART: console (115200 baud)
> * Power: DC jack (12 V / 2.5 A)
>
> Additional HW information:
>
> * SoC USB port #1 is shared by internal miniPCIe slot and external
> Type-A USB port, USB D+/D- lines are toggled between ports using a
> GPIO controlled DPDT switch.
> * Power of the USB enabled miniPCIe slots can be individually controlled
> using dedicated GPIO lines.
> * Vendor firmware feeds the external watchdog with 1s pulses. GPIO
> watchdog driver is able to either generate a 1us pulses or toggle the
> output line. 1us is not enough for the external watchod timer, so
> the line toggling driver mode is utilized.
>
> Installation:
>
> Vendor's firmware is OpenWrt (LEDE) based, so the sysupgrade image can
> be directly used to install OpenWrt. Firmware must be upgraded using the
> 'force' and 'do not save configuration' command line options (or
> correspondig web interface checkboxes) since the vendor firmware is from
> the pre-DSA era.
>
> Signed-off-by: Sergey Ryazanov
> ---
> .../dts/mt7621_zbtlink_zbt-wg1602-16m.dts | 10 +
> .../ramips/dts/mt7621_zbtlink_zbt-wg1602.dtsi | 206 ++
> target/linux/ramips/image/mt7621.mk | 12 +
> 3 files changed, 228 insertions(+)
> create mode 100644 target/linux/ramips/dts/mt7621_zbtlink_zbt-wg1602-16m.dts
> create mode 100644 target/linux/ramips/dts/mt7621_zbtlink_zbt-wg1602.dtsi
>
> diff --git a/target/linux/ramips/dts/mt7621_zbtlink_zbt-wg1602-16m.dts
> b/target/linux/ramips/dts/mt7621_zbtlink_zbt-wg1602-16m.dts
> new file mode 100644
> index 00..216c7b3cf0
> --- /dev/null
> +++ b/target/linux/ramips/dts/mt7621_zbtlink_zbt-wg1602-16m.dts
> @@ -0,0 +1,10 @@
> +#include "mt7621_zbtlink_zbt-wg1602.dtsi"
> +
> +/ {
> + compatible = "zbtlink,zbt-wg1602-16m", "zbtlink,zbt-wg1602",
> "mediatek,mt7621-soc";
> + model = "Zbtlink ZBT-WG1602 (16M)";
> +};
> +
> + {
> + reg = <0x5 0xfb>;
> +};
> diff --git a/target/linux/ramips/dts/mt7621_zbtlink_zbt-wg1602.dtsi
> b/target/linux/ramips/dts/mt7621_zbtlink_zbt-wg1602.dtsi
> new file mode 100644
> index 00..e377a13444
> --- /dev/null
> +++ b/target/linux/ramips/dts/mt7621_zbtlink_zbt-wg1602.dtsi
> @@ -0,0 +1,206 @@
> +#include "mt7621.dtsi"
> +
> +#include
> +#include
> +
> +/ {
> + compatible = "zbtlink,zbt-wg1602", "mediatek,mt7621-soc";
> +
> + aliases {
> + led-boot = _sm;
> + led-failsafe = _sm;
> + led-running = _sm;
> + led-upgrade = _sm;
> + label-mac-device =
> + };
> +
> + chosen {
> + bootargs = "console=ttyS0,115200";
> + };
> +
> + keys {
> + compatible = "gpio-keys";
> +
> + reset {
> + label = "reset";
> + gpios = < 18 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led_sm: sm {
> + label = "green:sm";
> + gpios = < 4 GPIO_ACTIVE_LOW>;
> + };
> +
> + 4g1 {
> + label = "green:4g1";
> + gpios = < 10 GPIO_ACTIVE_LOW>;
> + };
> +
> + 4g2 {
> + label = "green:4g2";
> + gpios = < 12 GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> + watchdog {
> + compatible = "linux,wdt-gpio";
> + gpios = < 3 GPIO_ACTIVE_HIGH>;
> + hw_algo = "toggle";
> + /* hw_margin_ms is actually ~120s but driver limits it to 60s
> */
> + hw_margin_ms = <6>;
> + always-running;
> + };
> +
> + gpio-export {
> + compatible = "gpio-export";
> + #size-cells = <0>;
> +
> +
Re: [PATCH] ramips: add support for Zbtlink ZBT-WG1602
On Wed, Nov 24, 2021 at 12:51 AM Sergey Ryazanov wrote: > On Tue, Nov 16, 2021 at 1:09 PM Sergey Ryazanov > wrote: >> Zbtlink ZBT-WG1602 is a Wi-Fi router intendent to use with WWAN >> (UMTS/LTE/3G/4G) modems. The router board offsers a couple of miniPCIe >> slots with USB and SIM only and another one pure miniPCIe slot as well >> as five Gigabit Ethernet ports (4xLAN + WAN). > > Could the devs invest some time and apply this, please? If anything is > wrong with the patch, please, let me know. Another one friendly ping. Or are all devs busy and I should be more patient? -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/2 v2] ARM: dts: Add Goramo MultiLink device tree
This adds a device tree for the Goramo MultiLink IXP425-based
WAN router.
Cc: Krzysztof Hałasa
Cc: openwrt-devel@lists.openwrt.org
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Amend to the final merged bidings.
- I have added bindings for this set-up of the HDLC WAN,
and they are merged to the netdev tree.
---
arch/arm/boot/dts/Makefile| 1 +
.../dts/intel-ixp42x-goramo-multilink.dts | 180 ++
arch/arm/boot/dts/intel-ixp4xx.dtsi | 17 ++
3 files changed, 198 insertions(+)
create mode 100644 arch/arm/boot/dts/intel-ixp42x-goramo-multilink.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 0de64f237cd8..4084535c6489 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -263,6 +263,7 @@ dtb-$(CONFIG_ARCH_IXP4XX) += \
intel-ixp46x-ixdp465.dtb \
intel-ixp42x-adi-coyote.dtb \
intel-ixp42x-ixdpg425.dtb \
+ intel-ixp42x-goramo-multilink.dtb \
intel-ixp42x-iomega-nas100d.dtb \
intel-ixp42x-dlink-dsm-g600.dtb \
intel-ixp42x-gateworks-gw2348.dtb \
diff --git a/arch/arm/boot/dts/intel-ixp42x-goramo-multilink.dts
b/arch/arm/boot/dts/intel-ixp42x-goramo-multilink.dts
new file mode 100644
index ..f80388b17a9e
--- /dev/null
+++ b/arch/arm/boot/dts/intel-ixp42x-goramo-multilink.dts
@@ -0,0 +1,180 @@
+// SPDX-License-Identifier: ISC
+/*
+ * Device Tree file for the Goramo MultiLink Router
+ * There are two variants:
+ * - MultiLink Basic (a box)
+ * - MultiLink Max (19" rack mount)
+ * This device tree supports MultiLink Basic.
+ * This machine is based on IXP425.
+ * This is one of the few devices supporting the IXP4xx High-Speed Serial
+ * (HSS) link for a V.35 WAN interface.
+ * The hardware originates in Poland.
+ */
+
+/dts-v1/;
+
+#include "intel-ixp42x.dtsi"
+#include
+
+/ {
+ model = "Goramo MultiLink Router";
+ compatible = "goramo,multilink-router", "intel,ixp42x";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ memory@0 {
+ /*
+* 64 MB of RAM according to the manual. The MultiLink
+* Max has 128 MB.
+*/
+ device_type = "memory";
+ reg = <0x 0x400>;
+ };
+
+ chosen {
+ bootargs = "console=ttyS0,115200n8";
+ stdout-path = "uart0:115200n8";
+ };
+
+ aliases {
+ serial0 =
+ serial1 =
+ };
+
+ /*
+* 74HC4094 which is used as a rudimentary GPIO expander
+* FIXME:
+* - Create device tree bindings for this as GPIO expander
+* - Write a pure DT GPIO driver using these bindings
+* - Support cascading in the style of gpio-74x164.c (cannot be reused,
very different)
+*/
+ gpio_74: gpio-74hc4094 {
+ compatible = "nxp,74hc4094";
+ cp-gpios = < 0 GPIO_ACTIVE_HIGH>;
+ d-gpios = < 1 GPIO_ACTIVE_HIGH>;
+ str-gpios = < 2 GPIO_ACTIVE_HIGH>;
+ /* oe-gpios is optional */
+ gpio-controller;
+ #gpio-cells = <2>;
+ /* We are not cascaded */
+ registers-number = <1>;
+ gpio-line-names = "CONTROL_HSS0_CLK_INT",
"CONTROL_HSS1_CLK_INT", "CONTROL_HSS0_DTR_N",
+ "CONTROL_HSS1_DTR_N", "CONTROL_EXT",
"CONTROL_AUTO_RESET",
+ "CONTROL_PCI_RESET_N", "CONTROL_EEPROM_WC_N";
+ };
+
+ soc {
+ bus@c400 {
+ flash@0,0 {
+ compatible = "intel,ixp4xx-flash", "cfi-flash";
+ bank-width = <2>;
+ /* Enable writes on the expansion bus */
+ intel,ixp4xx-eb-write-enable = <1>;
+ /* 16 MB of Flash mapped in at CS0 */
+ reg = <0 0x 0x100>;
+
+ partitions {
+ compatible = "redboot-fis";
+ /* Eraseblock at 0x0fe */
+ fis-index-block = <0x7f>;
+ };
+ };
+ };
+
+ pci@c000 {
+ status = "ok";
+
+ /*
+* The device has 4 slots (IDSEL) with one dedicated
IRQ per slot.
+* The slots have Ethernet, Ethernet, NEC and MPCI.
+* The IDSELs are 11, 12, 13, 14.
+*/
+ interrupt-map =
+ /* IDSEL 11 - Ethernet A */
+ <0x5800 0 0 1 4 IRQ_TYPE_LEVEL_LOW>, /* INT A on
slot 11 is irq 4 */
+ <0x5800 0 0 2 4 IRQ_TYPE_LEVEL_LOW>, /* INT B
Re: [PATCH 0/3] realtek: add support for Panasonic Switch-M8eG PN28080K
On 11/12/21 10:00 PM, Sander Vanheule wrote: Hi, On Sun, 2021-10-03 at 15:53 +0900, INAGAKI Hiroshi wrote: [...] INAGAKI Hiroshi (3): realtek: enable pca953x driver for target realtek: enable gpio-restart driver in target realtek: add support for Panasonic Switch-M8eG PN28080K target/linux/realtek/config-5.10 | 4 + target/linux/realtek/config-5.4 | 4 + .../rtl8380_panasonic_m8eg-pn28080k.dts | 103 .../rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi | 216 + .../rtl8380_panasonic_m8eg-pn28080k.dts | 107 + .../rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi | 220 ++ target/linux/realtek/image/Makefile | 10 + 7 files changed, 664 insertions(+) create mode 100644 target/linux/realtek/dts-5.10/rtl8380_panasonic_m8eg-pn28080k.dts create mode 100644 target/linux/realtek/dts-5.10/rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi create mode 100644 target/linux/realtek/dts-5.4/rtl8380_panasonic_m8eg-pn28080k.dts create mode 100644 target/linux/realtek/dts-5.4/rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi I guess this is more a question for the maintainers: Since the realtek target now uses the 5.10 kernel in master, does it still make sense to add support for 5.4? Hiroshi has backported the upstream drivers for 5.10 (thanks again!), so both kernel version now have different quirks. Personnaly, I would prefer not to have to put any energy in 5.4 anymore. The realtek target already has KERNEL_PATCHVER set to 5.10 now. You do not have to add support for kernel 5.4 in your patches any more, if you want to it is fine with me, but we will probability delete the support for kernel 5.4 in 1 or 2 months anyway. If you need special workarounds for kernel 5.4 I would suggest to go with kernel 5.10 only. @Hiroshi I added some of the GPIO patches from Sander, could you please rebase your patch on top of that. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] realtek: sort the port list numerically
On 11/29/21 2:18 PM, Bjørn Mork wrote: Mac adresses are assigned in the order given by the port list. The interfaces are also brought up in this order. This target supports devices with up to 52 ports. Sorting these alphabetically is very confusing, and assigning mac addresses in alphabetic order does not match stock firmware behaviour. Suggested-by: Sander Vanheule Signed-off-by: Bjørn Mork --- Hauke Mehrtens writes: I applied the first and the last patch, could you please resend the reworked patch "realtek: sort the port list numerically ". Thanks! Crossing fingers that this won't break too much for those who have gotten used to the odd defaults... I hope so too. I do not know how many users the realtek target already has, but new users will probably be happy that they do not have to use a specific port and VLAN 100. Here's a new version of the remaining patch, using Sander's much nicer implementation. I did a quick "sysupgrade -n" test on my GS108Tv3 and it seems to work. Although that one has too few ports for this to really make any difference... Could someone with a switch with more ports please test this and report back. My switch only has 8 ports. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC PATCH] treewide: drop librt and libpthread packages
On 11/18/21 12:58 PM, Jo-Philipp Wich wrote: Since OpenWrt's main libc library, musl, does not provide separate shared object files for libpthread and librt, the existing binary packages for them are empty placeholders which provide no runtime functionality and frequently cause confusion among users who attempt to build software linking -lrt or -lpthread on target. To clean this situation up somewhat and to simplify binary package dependecies for all of the potential musl, glibc and uclibc cases, drop those packages and move libpthread.so as well as librt.so into the main libc package for those libc implementations that happen ship them as extra shared libraries. Signed-off-by: Jo-Philipp Wich --- This looks good. glibc 2.34 also uses a single binary like musl, we are currently using 2.33. We can later upgrade also the glibc. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[firmware-utils v2] asus_qca_fix_checksum: new tool for ASUS QCA/QCN uImage
From: Alisha Kim
Fix checksum of Asus QCA/QCN devices.
Tested on ac59u v1
Signed-off-by: Alisha Kim
---
CMakeLists.txt | 1 +
src/asus_qca_fix_checksum.c | 205
2 files changed, 206 insertions(+)
create mode 100644 src/asus_qca_fix_checksum.c
diff --git a/CMakeLists.txt b/CMakeLists.txt
index f406520..f551b88 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -28,6 +28,7 @@ ENDMACRO(FW_UTIL)
FW_UTIL(add_header "" "" "")
FW_UTIL(addpattern "" "" "")
+FW_UTIL(asus_qca_fix_checksum "" "" "${ZLIB_LIBRARIES}")
FW_UTIL(asustrx "" "" "")
FW_UTIL(bcm4908asus "" "" "")
FW_UTIL(bcm4908kernel "" "" "")
diff --git a/src/asus_qca_fix_checksum.c b/src/asus_qca_fix_checksum.c
new file mode 100644
index 000..511f101
--- /dev/null
+++ b/src/asus_qca_fix_checksum.c
@@ -0,0 +1,205 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * asus_qca_fix_checksum.c : checksum fix for ASUS QCA/QCN SoC uImage
+ *
+ * Copyright (C) 2021 Alisha Kim
+ *
+ * Based on:
+ * uimage_padhdr.c : add zero paddings after the tail of uimage
header
+ * Copyright (C) 2019 NOGUCHI Hiroshi
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* from asuswrt opensource */
+#define MAX_STRING 12
+#define MAX_VER 5
+
+typedef struct
+{
+ uint8_t major;
+ uint8_t minor;
+} version_t;
+
+/*
+ * ASUS QCA/QCN Custom Header
+ */
+typedef struct
+{
+ version_t kernel;
+ version_t fs;
+ char productid[MAX_STRING];
+ uint16_t sn;
+ uint16_t en;
+ uint8_t pkey;
+ uint8_t key;
+ version_t hw[MAX_VER];
+} TAIL;
+
+/* from u-boot/include/image.h */
+#define IH_MAGIC 0x27051956 /* Image Magic Number */
+#define IH_NMLEN 32/* Image Name Length*/
+
+/*
+ * Legacy format image header,
+ * all data in network byte order (aka natural aka bigendian).
+ */
+typedef struct image_header
+{
+ uint32_t ih_magic; /* Image Header Magic Number */
+ uint32_t ih_hcrc; /* Image Header CRC Checksum */
+ uint32_t ih_time; /* Image Creation Timestamp */
+ uint32_t ih_size; /* Image Data Size */
+ uint32_t ih_load; /* Data Load Address */
+ uint32_t ih_ep;/* Entry Point Address */
+ uint32_t ih_dcrc; /* Image Data CRC Checksum */
+ uint8_t ih_os; /* Operating System */
+ uint8_t ih_arch; /* CPU architecture */
+ uint8_t ih_type; /* Image Type*/
+ uint8_t ih_comp; /* Compression Type */
+ union
+ {
+ uint8_t ih_name[IH_NMLEN]; /* Image Name
*/
+ TAIL tail; /* Asuswrt Custom
Tail */
+ } u;
+} image_header_t;
+
+void fix_checksum(uint8_t *image, off_t image_len, TAIL *tail)
+{
+ image_header_t *header = (image_header_t *)image;
+
+ uint32_t checksum_a_offset = 0; // image first byte
+ uint32_t checksum_b_offset = (ntohl(header->ih_size) +
sizeof(image_header_t)) >> 1;
+
+ uint8_t checksum_a = image[checksum_a_offset];
+ uint8_t checksum_b;
+
+ uint32_t recalc_crc;
+
+ if (image_len < checksum_b_offset)
+ {
+ fprintf(stderr, "too small uImage size\n");
+ exit(1);
+ }
+
+ checksum_b = image[checksum_b_offset];
+
+ tail->key = checksum_a + ~checksum_b;
+
+ // copy an existing image name
+ memcpy(>productid, >u.ih_name, sizeof(tail->productid) -
1);
+
+ // overwrite asus custom header to image name field
+ header->u.tail = *tail;
+
+ header->ih_hcrc = 0;
+ recalc_crc = crc32(0, image, sizeof(image_header_t));
+ header->ih_hcrc = htonl(recalc_crc);
+}
+
+void usage(char *prog)
+{
+ fprintf(stderr, "%s -i -o \n", prog);
+ fprintf(stderr, " -v ");
+}
+
+int main(int argc, char *argv[])
+{
+ struct stat statbuf;
+ uint8_t *filebuf;
+ int ifd;
+ int ofd;
+ ssize_t rsz;
+ int opt;
+ char *infname = NULL;
+ char *outfname = NULL;
+ char *version = NULL;
+ TAIL tail = {};
+
+ while ((opt = getopt(argc, argv, "i:o:v:")) != -1)
+ {
+ switch (opt)
+ {
+ case 'i':
+ infname = optarg;
+ break;
+ case 'o':
+ outfname = optarg;
+ break;
+ case 'v':
+ version = optarg;
+ if (6 != sscanf(
+version,
"%hhu.%hhu.%hhu.%hhu.%hu.%hu",
+,
,
+, ,
+
[firmware-utils v2] asus_qca_fix_checksum: new tool for ASUS QCA/QCN uImage
From: daebo01
Fix checksum of Asus QCA/QCN devices.
Tested on ac59u v1
Signed-off-by: Alisha Kim
---
CMakeLists.txt | 1 +
src/asus_qca_fix_checksum.c | 205
2 files changed, 206 insertions(+)
create mode 100644 src/asus_qca_fix_checksum.c
diff --git a/CMakeLists.txt b/CMakeLists.txt
index f406520..f551b88 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -28,6 +28,7 @@ ENDMACRO(FW_UTIL)
FW_UTIL(add_header "" "" "")
FW_UTIL(addpattern "" "" "")
+FW_UTIL(asus_qca_fix_checksum "" "" "${ZLIB_LIBRARIES}")
FW_UTIL(asustrx "" "" "")
FW_UTIL(bcm4908asus "" "" "")
FW_UTIL(bcm4908kernel "" "" "")
diff --git a/src/asus_qca_fix_checksum.c b/src/asus_qca_fix_checksum.c
new file mode 100644
index 000..511f101
--- /dev/null
+++ b/src/asus_qca_fix_checksum.c
@@ -0,0 +1,205 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * asus_qca_fix_checksum.c : checksum fix for ASUS QCA/QCN SoC uImage
+ *
+ * Copyright (C) 2021 Alisha Kim
+ *
+ * Based on:
+ * uimage_padhdr.c : add zero paddings after the tail of uimage
header
+ * Copyright (C) 2019 NOGUCHI Hiroshi
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* from asuswrt opensource */
+#define MAX_STRING 12
+#define MAX_VER 5
+
+typedef struct
+{
+ uint8_t major;
+ uint8_t minor;
+} version_t;
+
+/*
+ * ASUS QCA/QCN Custom Header
+ */
+typedef struct
+{
+ version_t kernel;
+ version_t fs;
+ char productid[MAX_STRING];
+ uint16_t sn;
+ uint16_t en;
+ uint8_t pkey;
+ uint8_t key;
+ version_t hw[MAX_VER];
+} TAIL;
+
+/* from u-boot/include/image.h */
+#define IH_MAGIC 0x27051956 /* Image Magic Number */
+#define IH_NMLEN 32/* Image Name Length*/
+
+/*
+ * Legacy format image header,
+ * all data in network byte order (aka natural aka bigendian).
+ */
+typedef struct image_header
+{
+ uint32_t ih_magic; /* Image Header Magic Number */
+ uint32_t ih_hcrc; /* Image Header CRC Checksum */
+ uint32_t ih_time; /* Image Creation Timestamp */
+ uint32_t ih_size; /* Image Data Size */
+ uint32_t ih_load; /* Data Load Address */
+ uint32_t ih_ep;/* Entry Point Address */
+ uint32_t ih_dcrc; /* Image Data CRC Checksum */
+ uint8_t ih_os; /* Operating System */
+ uint8_t ih_arch; /* CPU architecture */
+ uint8_t ih_type; /* Image Type*/
+ uint8_t ih_comp; /* Compression Type */
+ union
+ {
+ uint8_t ih_name[IH_NMLEN]; /* Image Name
*/
+ TAIL tail; /* Asuswrt Custom
Tail */
+ } u;
+} image_header_t;
+
+void fix_checksum(uint8_t *image, off_t image_len, TAIL *tail)
+{
+ image_header_t *header = (image_header_t *)image;
+
+ uint32_t checksum_a_offset = 0; // image first byte
+ uint32_t checksum_b_offset = (ntohl(header->ih_size) +
sizeof(image_header_t)) >> 1;
+
+ uint8_t checksum_a = image[checksum_a_offset];
+ uint8_t checksum_b;
+
+ uint32_t recalc_crc;
+
+ if (image_len < checksum_b_offset)
+ {
+ fprintf(stderr, "too small uImage size\n");
+ exit(1);
+ }
+
+ checksum_b = image[checksum_b_offset];
+
+ tail->key = checksum_a + ~checksum_b;
+
+ // copy an existing image name
+ memcpy(>productid, >u.ih_name, sizeof(tail->productid) -
1);
+
+ // overwrite asus custom header to image name field
+ header->u.tail = *tail;
+
+ header->ih_hcrc = 0;
+ recalc_crc = crc32(0, image, sizeof(image_header_t));
+ header->ih_hcrc = htonl(recalc_crc);
+}
+
+void usage(char *prog)
+{
+ fprintf(stderr, "%s -i -o \n", prog);
+ fprintf(stderr, " -v ");
+}
+
+int main(int argc, char *argv[])
+{
+ struct stat statbuf;
+ uint8_t *filebuf;
+ int ifd;
+ int ofd;
+ ssize_t rsz;
+ int opt;
+ char *infname = NULL;
+ char *outfname = NULL;
+ char *version = NULL;
+ TAIL tail = {};
+
+ while ((opt = getopt(argc, argv, "i:o:v:")) != -1)
+ {
+ switch (opt)
+ {
+ case 'i':
+ infname = optarg;
+ break;
+ case 'o':
+ outfname = optarg;
+ break;
+ case 'v':
+ version = optarg;
+ if (6 != sscanf(
+version,
"%hhu.%hhu.%hhu.%hhu.%hu.%hu",
+,
,
+, ,
+
Re: [PATCH] kernal: skip hpower setting for the module which has no revs
Could you test if the attached patch fixes the issue for you? This
rearranges the tests in sfp_module_parse_power() so that your module is
silently accepted without reconfiguration - like it was before commit
7cfa9c92d0a3.
The module will still be rejected as EINVAL in case the host doesn't
support high power.
We don't try to configure modules modules requiring the unsupported
Address Change Sequence. I see no reason to reject such modules even if
the host doesn't support high power, so I moved that block up in front
of the host power check. Completely untested since I don't have any
such module...
This should not change anything for other types of modules.
Bjørn
>From f232c37c94239b56aeebfec26da26faf7df39b93 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B8rn=20Mork?=
Date: Mon, 29 Nov 2021 14:43:38 +0100
Subject: [PATCH] phy: sfp: fix high power modules without diag mode
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Commit 7cfa9c92d0a3 ("net: sfp: avoid power switch on address-change
modules") changed semantics for high power modules without diag mode.
We repeatedly try to read the current power status from the non-existing
0xa2 address, in the futile hope this failure is temporary:
[8.856051] sfp sfp-eth3: module NTT rev sn dc 160408
[8.865843] mvpp2 f400.ethernet eth3: switched to inband/1000base-x link mode
[8.873469] sfp sfp-eth3: Failed to read EEPROM: -5
[8.983251] sfp sfp-eth3: Failed to read EEPROM: -5
[9.103250] sfp sfp-eth3: Failed to read EEPROM: -5
Eeprom dump:
0x: 03 04 01 00 00 00 80 00 00 00 00 01 0d 00 0a 64
0x0010: 00 00 00 00 4e 54 54 20 20 20 20 20 20 20 20 20
0x0020: 20 20 20 20 00 00 00 00 30 30 30 30 30 30 30 30
0x0030: 30 30 30 30 30 30 30 30 30 30 30 30 05 1e 00 7d
0x0040: 02 00 00 00 30 30 30 30 30 30 30 30 30 30 30 30
0x0050: 30 30 30 30 31 36 30 34 30 38 20 20 00 00 00 75
0x0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Previously we assumed such modules were powered up in the correct
mode, continuing without further configuration as long as the
required power class was supported by the host.
Revert to that behaviour, refactoring to keep the improved
diagnostic messages.
Fixes: 7cfa9c92d0a3 ("net: sfp: avoid power switch on address-change modules")
Reported-by: 照山周一郎
Signed-off-by: Bjørn Mork
---
drivers/net/phy/sfp.c | 42 +-
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index 32c34c728c7a..126c955714cb 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -1595,27 +1595,6 @@ static int sfp_module_parse_power(struct sfp *sfp)
if (sfp->id.ext.options & cpu_to_be16(SFP_OPTIONS_HIGH_POWER_LEVEL))
power_mW = 2000;
- if (power_mW > sfp->max_power_mW) {
- /* Module power specification exceeds the allowed maximum. */
- if (sfp->id.ext.sff8472_compliance ==
- SFP_SFF8472_COMPLIANCE_NONE &&
- !(sfp->id.ext.diagmon & SFP_DIAGMON_DDM)) {
- /* The module appears not to implement bus address
- * 0xa2, so assume that the module powers up in the
- * indicated mode.
- */
- dev_err(sfp->dev,
-"Host does not support %u.%uW modules\n",
-power_mW / 1000, (power_mW / 100) % 10);
- return -EINVAL;
- } else {
- dev_warn(sfp->dev,
- "Host does not support %u.%uW modules, module left in power mode 1\n",
- power_mW / 1000, (power_mW / 100) % 10);
- return 0;
- }
- }
-
/* If the module requires a higher power mode, but also requires
* an address change sequence, warn the user that the module may
* not be functional.
@@ -1627,6 +1606,27 @@ static int sfp_module_parse_power(struct sfp *sfp)
return 0;
}
+ if (sfp->id.ext.sff8472_compliance == SFP_SFF8472_COMPLIANCE_NONE &&
+ !(sfp->id.ext.diagmon & SFP_DIAGMON_DDM)) {
+ /* The module appears not to implement bus address
+ * 0xa2, so assume that the module powers up in the
+ * indicated mode.
+ */
+ if (power_mW <= sfp->max_power_mW)
+ return 0;
+
+ dev_err(sfp->dev, "Host does not support %u.%uW modules\n",
+ power_mW / 1000, (power_mW / 100) % 10);
+ return -EINVAL;
+ }
+
+ if (power_mW > sfp->max_power_mW) {
+ dev_warn(sfp->dev,
+ "Host does not support %u.%uW modules, module left in power mode 1\n",
+ power_mW / 1000, (power_mW / 100) % 10);
+ return 0;
+ }
+
sfp->module_power_mW = power_mW;
return
Re: [PATCH] kernal: skip hpower setting for the module which has no revs
Thank you for the very clear explanation.
I now understand that this issue should be feedback to the mainline as
well as OpenWRT.
However, I am ashamed to say that my technical skills are not useful
enough to contribute to the improvement of the mainline, so it would
be very helpful if you could take over if possible.
2021年11月29日(月) 21:18 Bjørn Mork :
>
> 照山周一郎 writes:
>
> > Thanks for all the helpful advice.
> >
> > The EEPROM dump is as follows.
> >
> > ーーー
> >
> > Offset Values
> > ---— ———
> > 0x: 03 04 01 00 00 00 80 00 00 00 00 01 0d 00 0a 64
> > 0x0010: 00 00 00 00 4e 54 54 20 20 20 20 20 20 20 20 20
> > 0x0020: 20 20 20 20 00 00 00 00 30 30 30 30 30 30 30 30
> > 0x0030: 30 30 30 30 30 30 30 30 30 30 30 30 05 1e 00 7d
> > 0x0040: 02 00 00 00 30 30 30 30 30 30 30 30 30 30 30 30
>
> So id.ext.options is 0x0200, meaning that SFP_OPTIONS_POWER_DECL is set
> and nothing else.
>
> > 0x0050: 30 30 30 30 31 36 30 34 30 38 20 20 00 00 00 75
>
> And both id.ext.diagmon and id.ext.sff8472_compliance are 0x00. Not
> sure why they'd want that with such a new module, but I guess it's
> fine..
>
> Anyway, this means that your module would have matched the old
>
> if (sfp->id.ext.sff8472_compliance == SFP_SFF8472_COMPLIANCE_NONE &&
> (sfp->id.ext.diagmon & (SFP_DIAGMON_DDM | SFP_DIAGMON_ADDRMODE))
> !=
> SFP_DIAGMON_DDM) {
>
> test and therefore have been accepted by the driver.
>
>
> > 0x0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 0x0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 0x0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 0x0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 0x00a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 0x00b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 0x00c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 0x00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 0x00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 0x00f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > ーーー
> >
> > The log is as follows.
> >
> > ーーー
> >
> > [8.583797] kmodloader: done loading kernel modules from /etc/modules.d/*
> > [8.834704] sfp sfp-eth1: module OEM 10G-SFP-PCU1M
> > rev Gsn HS18100810001dc 181008
> > [8.856051] sfp sfp-eth3: module NTT
> > rev sn dc 160408
> > [8.865843] mvpp2 f400.ethernet eth3: switched to
> > inband/1000base-x link mode
> > [8.873469] sfp sfp-eth3: Failed to read EEPROM: -5
> > [8.983251] sfp sfp-eth3: Failed to read EEPROM: -5
> > [9.103250] sfp sfp-eth3: Failed to read EEPROM: -5
> > ーーー
> >
> > "Failed to read EEPROM: -5" output in a loop.
>
> Thanks. Just wanted to be sure that even read access to EXT_STATUS
> failed. That's as expected when SFP_DIAGMON_DDM is not set.
>
> The loop makes the problem even worse. It's not like this is going to
> fix itself. But I guess it makes sense for the temporary access
> problems this was intended to catch.
>
>
> > Its caused here.
> >
> > https://github.com/torvalds/linux/blob/master/drivers/net/phy/sfp.c#L1694
> >
> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/phy/sfp.c?id=7cfa9c92d0a325f97ac13f894a7b47d37bd2040
> >> if (power_mW > sfp->max_power_mW) {
> >
> > I think the above modification is wrong too.
> >
> > However, I don't have the SFP module that returns the appropriate
> > revision, and I don't have the environment to verify it, so I can't
> > fix the above patch myself.
>
> Well. I have a few modules with revisions 0x00, 0x01, 0x03 but none of
> them set any of the high power flags. So I can't really verify this
> either. Still, I think we understand the issue well enough now to make
> an attempt. Review by netdev, including a CC to the original author,
> should be plenty enough for a fix. It was enough to introduce the bug
> :-)
>
> > The NTT OCU that I want to run this time is widely used in Japan, so I
> > would like to apply the patch with the method I applied.
>
> Even more reason to fix this properly in mainline + stable and not just
> in OpenWrt. I can make an attempt with you as reporter, if you don't
> want to submit this yourself?
>
> I think the bug you found here might affect many other high power
> modules too. Any high power module without diagnostics will fail
> AFAICS.
>
> It's a great catch. Thanks!
>
>
> Bjørn
--
株式会社スプリングボード
照山 周一郎
teruy...@springboard-inc.jp
http://www.springboard-inc.jp/
〒110-0005
東京都台東区上野3丁目2番2号
アイオス秋葉原505号室
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2] realtek: sort the port list numerically
Mac adresses are assigned in the order given by the port list. The
interfaces are also brought up in this order. This target supports
devices with up to 52 ports. Sorting these alphabetically is very
confusing, and assigning mac addresses in alphabetic order does not
match stock firmware behaviour.
Suggested-by: Sander Vanheule
Signed-off-by: Bjørn Mork
---
Hauke Mehrtens writes:
> I applied the first and the last patch, could you please resend the
> reworked patch "realtek: sort the port list numerically ".
Thanks! Crossing fingers that this won't break too much for those who
have gotten used to the odd defaults...
Here's a new version of the remaining patch, using Sander's much nicer
implementation. I did a quick "sysupgrade -n" test on my GS108Tv3 and
it seems to work. Although that one has too few ports for this to
really make any difference...
Bjørn
target/linux/realtek/base-files/etc/board.d/02_network | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/target/linux/realtek/base-files/etc/board.d/02_network
b/target/linux/realtek/base-files/etc/board.d/02_network
index 93d6d4bd1e73..e8e3f6035d56 100644
--- a/target/linux/realtek/base-files/etc/board.d/02_network
+++ b/target/linux/realtek/base-files/etc/board.d/02_network
@@ -17,10 +17,7 @@ ucidef_set_poe() {
board=$(board_name)
board_config_update
-lan_list=""
-for lan in /sys/class/net/lan*; do
- lan_list="$lan_list $(basename $lan)"
-done
+lan_list=$(ls -1 -v -d /sys/class/net/lan* | xargs -n1 basename | xargs)
ucidef_set_bridge_device switch
ucidef_set_interface_lan "$lan_list"
--
2.30.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [firmware-utils] asus_qca_fix_checksum: new tool for ASUS QCA/QCN uImage
Sorry, the real name is required to be specified in the commit.
Enrico
On Mon, 29 Nov 2021, webmas...@playmp3.kr wrote:
Date: Mon, 29 Nov 2021 11:56:09
From: webmas...@playmp3.kr
To: openwrt-devel@lists.openwrt.org
Cc: daebo01
Subject: [firmware-utils] asus_qca_fix_checksum: new tool for ASUS QCA/QCN
uImage
From: daebo01
Fix checksum of Asus QCA/QCN devices.
Tested on ac59u v1
Signed-off-by: daebo01
---
CMakeLists.txt | 1 +
src/asus_qca_fix_checksum.c | 205
2 files changed, 206 insertions(+)
create mode 100644 src/asus_qca_fix_checksum.c
diff --git a/CMakeLists.txt b/CMakeLists.txt
index f406520..f551b88 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -28,6 +28,7 @@ ENDMACRO(FW_UTIL)
FW_UTIL(add_header "" "" "")
FW_UTIL(addpattern "" "" "")
+FW_UTIL(asus_qca_fix_checksum "" "" "${ZLIB_LIBRARIES}")
FW_UTIL(asustrx "" "" "")
FW_UTIL(bcm4908asus "" "" "")
FW_UTIL(bcm4908kernel "" "" "")
diff --git a/src/asus_qca_fix_checksum.c b/src/asus_qca_fix_checksum.c
new file mode 100644
index 000..8bb4420
--- /dev/null
+++ b/src/asus_qca_fix_checksum.c
@@ -0,0 +1,205 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * asus_qca_fix_checksum.c : checksum fix for ASUS QCA/QCN SoC uImage
+ *
+ * Copyright (C) 2021 daebo01
+ *
+ * Based on:
+ * uimage_padhdr.c : add zero paddings after the tail of uimage
header
+ * Copyright (C) 2019 NOGUCHI Hiroshi
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* from asuswrt opensource */
+#define MAX_STRING 12
+#define MAX_VER 5
+
+typedef struct
+{
+ uint8_t major;
+ uint8_t minor;
+} version_t;
+
+/*
+ * ASUS QCA/QCN Custom Header
+ */
+typedef struct
+{
+ version_t kernel;
+ version_t fs;
+ char productid[MAX_STRING];
+ uint16_t sn;
+ uint16_t en;
+ uint8_t pkey;
+ uint8_t key;
+ version_t hw[MAX_VER];
+} TAIL;
+
+/* from u-boot/include/image.h */
+#define IH_MAGIC 0x27051956 /* Image Magic Number */
+#define IH_NMLEN 32/* Image Name Length*/
+
+/*
+ * Legacy format image header,
+ * all data in network byte order (aka natural aka bigendian).
+ */
+typedef struct image_header
+{
+ uint32_t ih_magic; /* Image Header Magic Number */
+ uint32_t ih_hcrc; /* Image Header CRC Checksum */
+ uint32_t ih_time; /* Image Creation Timestamp */
+ uint32_t ih_size; /* Image Data Size */
+ uint32_t ih_load; /* Data Load Address */
+ uint32_t ih_ep;/* Entry Point Address */
+ uint32_t ih_dcrc; /* Image Data CRC Checksum */
+ uint8_t ih_os; /* Operating System */
+ uint8_t ih_arch; /* CPU architecture */
+ uint8_t ih_type; /* Image Type*/
+ uint8_t ih_comp; /* Compression Type */
+ union
+ {
+ uint8_t ih_name[IH_NMLEN]; /* Image Name
*/
+ TAIL tail; /* Asuswrt Custom
Tail */
+ } u;
+} image_header_t;
+
+void fix_checksum(uint8_t *image, off_t image_len, TAIL *tail)
+{
+ image_header_t *header = (image_header_t *)image;
+
+ uint32_t checksum_a_offset = 0; // image first byte
+ uint32_t checksum_b_offset = (ntohl(header->ih_size) +
sizeof(image_header_t)) >> 1;
+
+ uint8_t checksum_a = image[checksum_a_offset];
+ uint8_t checksum_b;
+
+ uint32_t recalc_crc;
+
+ if (image_len < checksum_b_offset)
+ {
+ fprintf(stderr, "too small uImage size\n");
+ exit(1);
+ }
+
+ checksum_b = image[checksum_b_offset];
+
+ tail->key = checksum_a + ~checksum_b;
+
+ // copy an existing image name
+ memcpy(>productid, >u.ih_name, sizeof(tail->productid) -
1);
+
+ // overwrite asus custom header to image name field
+ header->u.tail = *tail;
+
+ header->ih_hcrc = 0;
+ recalc_crc = crc32(0, image, sizeof(image_header_t));
+ header->ih_hcrc = htonl(recalc_crc);
+}
+
+void usage(char *prog)
+{
+ fprintf(stderr, "%s -i -o \n", prog);
+ fprintf(stderr, " -v ");
+}
+
+int main(int argc, char *argv[])
+{
+ struct stat statbuf;
+ uint8_t *filebuf;
+ int ifd;
+ int ofd;
+ ssize_t rsz;
+ int opt;
+ char *infname = NULL;
+ char *outfname = NULL;
+ char *version = NULL;
+ TAIL tail = {};
+
+ while ((opt = getopt(argc, argv, "i:o:v:")) != -1)
+ {
+ switch (opt)
+ {
+ case 'i':
+ infname = optarg;
+ break;
+ case 'o':
+ outfname = optarg;
+ break;
+ case 'v':
+
Re: [PATCH] kernal: skip hpower setting for the module which has no revs
照山周一郎 writes:
> Thanks for all the helpful advice.
>
> The EEPROM dump is as follows.
>
> ーーー
>
> Offset Values
> ---— ———
> 0x: 03 04 01 00 00 00 80 00 00 00 00 01 0d 00 0a 64
> 0x0010: 00 00 00 00 4e 54 54 20 20 20 20 20 20 20 20 20
> 0x0020: 20 20 20 20 00 00 00 00 30 30 30 30 30 30 30 30
> 0x0030: 30 30 30 30 30 30 30 30 30 30 30 30 05 1e 00 7d
> 0x0040: 02 00 00 00 30 30 30 30 30 30 30 30 30 30 30 30
So id.ext.options is 0x0200, meaning that SFP_OPTIONS_POWER_DECL is set
and nothing else.
> 0x0050: 30 30 30 30 31 36 30 34 30 38 20 20 00 00 00 75
And both id.ext.diagmon and id.ext.sff8472_compliance are 0x00. Not
sure why they'd want that with such a new module, but I guess it's
fine..
Anyway, this means that your module would have matched the old
if (sfp->id.ext.sff8472_compliance == SFP_SFF8472_COMPLIANCE_NONE &&
(sfp->id.ext.diagmon & (SFP_DIAGMON_DDM | SFP_DIAGMON_ADDRMODE)) !=
SFP_DIAGMON_DDM) {
test and therefore have been accepted by the driver.
> 0x0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x00a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x00b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x00c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x00f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ーーー
>
> The log is as follows.
>
> ーーー
>
> [8.583797] kmodloader: done loading kernel modules from /etc/modules.d/*
> [8.834704] sfp sfp-eth1: module OEM 10G-SFP-PCU1M
> rev Gsn HS18100810001dc 181008
> [8.856051] sfp sfp-eth3: module NTT
> rev sn dc 160408
> [8.865843] mvpp2 f400.ethernet eth3: switched to
> inband/1000base-x link mode
> [8.873469] sfp sfp-eth3: Failed to read EEPROM: -5
> [8.983251] sfp sfp-eth3: Failed to read EEPROM: -5
> [9.103250] sfp sfp-eth3: Failed to read EEPROM: -5
> ーーー
>
> "Failed to read EEPROM: -5" output in a loop.
Thanks. Just wanted to be sure that even read access to EXT_STATUS
failed. That's as expected when SFP_DIAGMON_DDM is not set.
The loop makes the problem even worse. It's not like this is going to
fix itself. But I guess it makes sense for the temporary access
problems this was intended to catch.
> Its caused here.
>
> https://github.com/torvalds/linux/blob/master/drivers/net/phy/sfp.c#L1694
>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/phy/sfp.c?id=7cfa9c92d0a325f97ac13f894a7b47d37bd2040
>> if (power_mW > sfp->max_power_mW) {
>
> I think the above modification is wrong too.
>
> However, I don't have the SFP module that returns the appropriate
> revision, and I don't have the environment to verify it, so I can't
> fix the above patch myself.
Well. I have a few modules with revisions 0x00, 0x01, 0x03 but none of
them set any of the high power flags. So I can't really verify this
either. Still, I think we understand the issue well enough now to make
an attempt. Review by netdev, including a CC to the original author,
should be plenty enough for a fix. It was enough to introduce the bug
:-)
> The NTT OCU that I want to run this time is widely used in Japan, so I
> would like to apply the patch with the method I applied.
Even more reason to fix this properly in mainline + stable and not just
in OpenWrt. I can make an attempt with you as reporter, if you don't
want to submit this yourself?
I think the bug you found here might affect many other high power
modules too. Any high power module without diagnostics will fail
AFAICS.
It's a great catch. Thanks!
Bjørn
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] ath10k-ct: Fix spectral scan NULL pointer
If spectral scan support is enabled then ath10k-ct will cause a NULL
pointer due to relay_open() being called with a const callback struct
which is only supported in kernel 5.11 and later.
So, simply check the kernel version and if 5.11 and newer use the const
callback struct, otherwise use the regular struct.
Fixes: 553a3ac ("ath10k-ct: use 5.15 version")
Signed-off-by: Robert Marko
---
...0k-ct-Fix-spectral-scan-NULL-pointer.patch | 32 +++
1 file changed, 32 insertions(+)
create mode 100644
package/kernel/ath10k-ct/patches/300-ath10k-ct-Fix-spectral-scan-NULL-pointer.patch
diff --git
a/package/kernel/ath10k-ct/patches/300-ath10k-ct-Fix-spectral-scan-NULL-pointer.patch
b/package/kernel/ath10k-ct/patches/300-ath10k-ct-Fix-spectral-scan-NULL-pointer.patch
new file mode 100644
index 00..a3822a7e49
--- /dev/null
+++
b/package/kernel/ath10k-ct/patches/300-ath10k-ct-Fix-spectral-scan-NULL-pointer.patch
@@ -0,0 +1,32 @@
+From 0d2e335d780bda1432a9ba719c8200f796d27854 Mon Sep 17 00:00:00 2001
+From: Robert Marko
+Date: Mon, 29 Nov 2021 12:27:12 +0100
+Subject: [PATCH] ath10k-ct: Fix spectral scan NULL pointer
+
+If spectral scan support is enabled then ath10k-ct will cause a NULL
+pointer due to relay_open() being called with a const callback struct
+which is only supported in kernel 5.11 and later.
+
+So, simply check the kernel version and if 5.11 and newer use the const
+callback struct, otherwise use the regular struct.
+
+Fixes: 553a3ac ("ath10k-ct: use 5.15 version")
+Signed-off-by: Robert Marko
+---
+ ath10k-5.15/spectral.c | 4
+ 1 file changed, 4 insertions(+)
+
+--- a/ath10k-5.15/spectral.c
b/ath10k-5.15/spectral.c
+@@ -497,7 +497,11 @@ static int remove_buf_file_handler(struc
+ return 0;
+ }
+
++#if LINUX_VERSION_IS_GEQ(5,11,0)
+ static const struct rchan_callbacks rfs_spec_scan_cb = {
++#else
++static struct rchan_callbacks rfs_spec_scan_cb = {
++#endif
+ .create_buf_file = create_buf_file_handler,
+ .remove_buf_file = remove_buf_file_handler,
+ };
--
2.33.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[firmware-utils] asus_qca_fix_checksum: new tool for ASUS QCA/QCN uImage
From: daebo01
Fix checksum of Asus QCA/QCN devices.
Tested on ac59u v1
Signed-off-by: daebo01
---
CMakeLists.txt | 1 +
src/asus_qca_fix_checksum.c | 205
2 files changed, 206 insertions(+)
create mode 100644 src/asus_qca_fix_checksum.c
diff --git a/CMakeLists.txt b/CMakeLists.txt
index f406520..f551b88 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -28,6 +28,7 @@ ENDMACRO(FW_UTIL)
FW_UTIL(add_header "" "" "")
FW_UTIL(addpattern "" "" "")
+FW_UTIL(asus_qca_fix_checksum "" "" "${ZLIB_LIBRARIES}")
FW_UTIL(asustrx "" "" "")
FW_UTIL(bcm4908asus "" "" "")
FW_UTIL(bcm4908kernel "" "" "")
diff --git a/src/asus_qca_fix_checksum.c b/src/asus_qca_fix_checksum.c
new file mode 100644
index 000..8bb4420
--- /dev/null
+++ b/src/asus_qca_fix_checksum.c
@@ -0,0 +1,205 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * asus_qca_fix_checksum.c : checksum fix for ASUS QCA/QCN SoC uImage
+ *
+ * Copyright (C) 2021 daebo01
+ *
+ * Based on:
+ * uimage_padhdr.c : add zero paddings after the tail of uimage
header
+ * Copyright (C) 2019 NOGUCHI Hiroshi
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* from asuswrt opensource */
+#define MAX_STRING 12
+#define MAX_VER 5
+
+typedef struct
+{
+ uint8_t major;
+ uint8_t minor;
+} version_t;
+
+/*
+ * ASUS QCA/QCN Custom Header
+ */
+typedef struct
+{
+ version_t kernel;
+ version_t fs;
+ char productid[MAX_STRING];
+ uint16_t sn;
+ uint16_t en;
+ uint8_t pkey;
+ uint8_t key;
+ version_t hw[MAX_VER];
+} TAIL;
+
+/* from u-boot/include/image.h */
+#define IH_MAGIC 0x27051956 /* Image Magic Number */
+#define IH_NMLEN 32/* Image Name Length*/
+
+/*
+ * Legacy format image header,
+ * all data in network byte order (aka natural aka bigendian).
+ */
+typedef struct image_header
+{
+ uint32_t ih_magic; /* Image Header Magic Number */
+ uint32_t ih_hcrc; /* Image Header CRC Checksum */
+ uint32_t ih_time; /* Image Creation Timestamp */
+ uint32_t ih_size; /* Image Data Size */
+ uint32_t ih_load; /* Data Load Address */
+ uint32_t ih_ep;/* Entry Point Address */
+ uint32_t ih_dcrc; /* Image Data CRC Checksum */
+ uint8_t ih_os; /* Operating System */
+ uint8_t ih_arch; /* CPU architecture */
+ uint8_t ih_type; /* Image Type*/
+ uint8_t ih_comp; /* Compression Type */
+ union
+ {
+ uint8_t ih_name[IH_NMLEN]; /* Image Name
*/
+ TAIL tail; /* Asuswrt Custom
Tail */
+ } u;
+} image_header_t;
+
+void fix_checksum(uint8_t *image, off_t image_len, TAIL *tail)
+{
+ image_header_t *header = (image_header_t *)image;
+
+ uint32_t checksum_a_offset = 0; // image first byte
+ uint32_t checksum_b_offset = (ntohl(header->ih_size) +
sizeof(image_header_t)) >> 1;
+
+ uint8_t checksum_a = image[checksum_a_offset];
+ uint8_t checksum_b;
+
+ uint32_t recalc_crc;
+
+ if (image_len < checksum_b_offset)
+ {
+ fprintf(stderr, "too small uImage size\n");
+ exit(1);
+ }
+
+ checksum_b = image[checksum_b_offset];
+
+ tail->key = checksum_a + ~checksum_b;
+
+ // copy an existing image name
+ memcpy(>productid, >u.ih_name, sizeof(tail->productid) -
1);
+
+ // overwrite asus custom header to image name field
+ header->u.tail = *tail;
+
+ header->ih_hcrc = 0;
+ recalc_crc = crc32(0, image, sizeof(image_header_t));
+ header->ih_hcrc = htonl(recalc_crc);
+}
+
+void usage(char *prog)
+{
+ fprintf(stderr, "%s -i -o \n", prog);
+ fprintf(stderr, " -v ");
+}
+
+int main(int argc, char *argv[])
+{
+ struct stat statbuf;
+ uint8_t *filebuf;
+ int ifd;
+ int ofd;
+ ssize_t rsz;
+ int opt;
+ char *infname = NULL;
+ char *outfname = NULL;
+ char *version = NULL;
+ TAIL tail = {};
+
+ while ((opt = getopt(argc, argv, "i:o:v:")) != -1)
+ {
+ switch (opt)
+ {
+ case 'i':
+ infname = optarg;
+ break;
+ case 'o':
+ outfname = optarg;
+ break;
+ case 'v':
+ version = optarg;
+ if (6 != sscanf(
+version,
"%hhu.%hhu.%hhu.%hhu.%hu.%hu",
+,
,
+, ,
+
Re: [PATCH] kernal: skip hpower setting for the module which has no revs
Thanks for all the helpful advice.
The EEPROM dump is as follows.
ーーー
Offset Values
---— ———
0x: 03 04 01 00 00 00 80 00 00 00 00 01 0d 00 0a 64
0x0010: 00 00 00 00 4e 54 54 20 20 20 20 20 20 20 20 20
0x0020: 20 20 20 20 00 00 00 00 30 30 30 30 30 30 30 30
0x0030: 30 30 30 30 30 30 30 30 30 30 30 30 05 1e 00 7d
0x0040: 02 00 00 00 30 30 30 30 30 30 30 30 30 30 30 30
0x0050: 30 30 30 30 31 36 30 34 30 38 20 20 00 00 00 75
0x0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ーーー
The log is as follows.
ーーー
[8.583797] kmodloader: done loading kernel modules from /etc/modules.d/*
[8.834704] sfp sfp-eth1: module OEM 10G-SFP-PCU1M
rev Gsn HS18100810001dc 181008
[8.856051] sfp sfp-eth3: module NTT
rev sn dc 160408
[8.865843] mvpp2 f400.ethernet eth3: switched to
inband/1000base-x link mode
[8.873469] sfp sfp-eth3: Failed to read EEPROM: -5
[8.983251] sfp sfp-eth3: Failed to read EEPROM: -5
[9.103250] sfp sfp-eth3: Failed to read EEPROM: -5
ーーー
"Failed to read EEPROM: -5" output in a loop.
Its caused here.
https://github.com/torvalds/linux/blob/master/drivers/net/phy/sfp.c#L1694
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/phy/sfp.c?id=7cfa9c92d0a325f97ac13f894a7b47d37bd2040
> if (power_mW > sfp->max_power_mW) {
I think the above modification is wrong too.
However, I don't have the SFP module that returns the appropriate
revision, and I don't have the environment to verify it, so I can't
fix the above patch myself.
The NTT OCU that I want to run this time is widely used in Japan, so I
would like to apply the patch with the method I applied.
The build warnings will be fixed later.
Translated with www.DeepL.com/Translator (free version)
2021年11月29日(月) 18:30 Bjørn Mork :
>
> 照山周一郎 writes:
>
> > Thanks for the advice.
> >
> > This is a fix for a Japanese NTT OCU, which always outputs 2W, even
> > though the chip revision always returns 0. This is not a bug, but a
> > specification.
> > https://business.ntt-east.co.jp/service/onu/pdf/interface.pdf
> >
> > Therefore, since the situation is too special to be handled by
> > sfp_module_parse_power(), the existing code was implemented to exit
> > the process in the process just before the error occurs.
>
> It would help understanding if you included the actual error, and maybe
> an eeprom dump. Something like this (on a patched host where the module
> is supported, of course...):
>
> ethtool -m ethX raw on | hexdump -C
>
> > The SF-8472 does not normally return 0, so there is no effect on other
> > devices.
> > https://members.snia.org/document/dl/25916
>
> I see. This makes sense. I wonder if this is actually a bug in mainline
> introduced by commit 7cfa9c92d0a3 ("net: sfp: avoid power switch on
> address-change modules")?
>
> See
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/phy/sfp.c?id=7cfa9c92d0a325f97ac13f894a7b47d37bd2040
>
> If I read that correctly, then the original behaviour was the way you
> want it: We assumed that a module mathcing
>
> (sfp->id.ext.sff8472_compliance == SFP_SFF8472_COMPLIANCE_NONE &&
> (sfp->id.ext.diagmon & (SFP_DIAGMON_DDM | SFP_DIAGMON_ADDRMODE)) !=
> SFP_DIAGMON_DDM)
>
> already was in the indicated power mode and skipped the EXT_STATUS
> register update. But the patch moved most of that logic inside a
>
> if (power_mW > sfp->max_power_mW) {}
>
> block. Which I believe is a bug. We're now failing in case the host
> supports higher power but the module doesn't support DOM.
>
> If you think my analysis is correct, then you could you try to revert
> that patch to verify that it fixes your problem. There is a trivial
> string conflict but otherwise it reverts just fine.
>
> Is verified then a proper fix should go upstream.
>
> > If possible, I would appreciate some practical advice on compile-time
> > warnings.
>
> No warnings before patching:
>
> bjorn@miraculix:/usr/local/src/git/linux$ make -C /lib/modules/$(uname
> -r)/build M=$(pwd)/drivers/net/phy sfp.ko
> make: Entering directory '/usr/src/linux-headers-5.10.0-9-amd64'
> CC [M] /usr/local/src/git/linux/drivers/net/phy/sfp.o
> MODPOST /usr/local/src/git/linux/drivers/net/phy/Module.symvers
> CC [M] /usr/local/src/git/linux/drivers/net/phy/sfp.mod.o
> LD [M] /usr/local/src/git/linux/drivers/net/phy/sfp.ko
> make: Leaving directory
Re: zram-swap: default to lzo instead of lzo-rle compression
Hi, Sven, On Sun, 28 Nov 2021 at 01:40, Sven Roederer wrote: > > Rui, not sure if to call it a bug. At the end there is a hardcoded default > algo in the module, that is used initially when creating the device. The check > for the valid algo is done later at device-activation. > I spend some time in this code and have a patch ready, which checks for algos > before announcing them. It's not a bug, but it's also not exactly an unsurprising behaviour. This is the real issue: https://elixir.bootlin.com/linux/v5.10.82/source/crypto/Makefile#L153 obj-$(CONFIG_CRYPTO_LZO) += lzo.o lzo-rle.o Even though they're built as separate modules, they depend on a single kconfig symbol. Moreover, lzo-rle uses most of the original lzo functions (adding just RLE on top), so they should arguably just be merged. I don't know how receptive upstream is to that idea, but it seems logical to me. Thanks, Rui ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] kernal: skip hpower setting for the module which has no revs
照山周一郎 writes:
> Thanks for the advice.
>
> This is a fix for a Japanese NTT OCU, which always outputs 2W, even
> though the chip revision always returns 0. This is not a bug, but a
> specification.
> https://business.ntt-east.co.jp/service/onu/pdf/interface.pdf
>
> Therefore, since the situation is too special to be handled by
> sfp_module_parse_power(), the existing code was implemented to exit
> the process in the process just before the error occurs.
It would help understanding if you included the actual error, and maybe
an eeprom dump. Something like this (on a patched host where the module
is supported, of course...):
ethtool -m ethX raw on | hexdump -C
> The SF-8472 does not normally return 0, so there is no effect on other
> devices.
> https://members.snia.org/document/dl/25916
I see. This makes sense. I wonder if this is actually a bug in mainline
introduced by commit 7cfa9c92d0a3 ("net: sfp: avoid power switch on
address-change modules")?
See
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/phy/sfp.c?id=7cfa9c92d0a325f97ac13f894a7b47d37bd2040
If I read that correctly, then the original behaviour was the way you
want it: We assumed that a module mathcing
(sfp->id.ext.sff8472_compliance == SFP_SFF8472_COMPLIANCE_NONE &&
(sfp->id.ext.diagmon & (SFP_DIAGMON_DDM | SFP_DIAGMON_ADDRMODE)) !=
SFP_DIAGMON_DDM)
already was in the indicated power mode and skipped the EXT_STATUS
register update. But the patch moved most of that logic inside a
if (power_mW > sfp->max_power_mW) {}
block. Which I believe is a bug. We're now failing in case the host
supports higher power but the module doesn't support DOM.
If you think my analysis is correct, then you could you try to revert
that patch to verify that it fixes your problem. There is a trivial
string conflict but otherwise it reverts just fine.
Is verified then a proper fix should go upstream.
> If possible, I would appreciate some practical advice on compile-time
> warnings.
No warnings before patching:
bjorn@miraculix:/usr/local/src/git/linux$ make -C /lib/modules/$(uname
-r)/build M=$(pwd)/drivers/net/phy sfp.ko
make: Entering directory '/usr/src/linux-headers-5.10.0-9-amd64'
CC [M] /usr/local/src/git/linux/drivers/net/phy/sfp.o
MODPOST /usr/local/src/git/linux/drivers/net/phy/Module.symvers
CC [M] /usr/local/src/git/linux/drivers/net/phy/sfp.mod.o
LD [M] /usr/local/src/git/linux/drivers/net/phy/sfp.ko
make: Leaving directory '/usr/src/linux-headers-5.10.0-9-amd64'
Apply your patch:
bjorn@miraculix:/usr/local/src/git/linux$ patch -p1 <
/tmp/771-net-sfp-skip-hpowr-if-no-revision.patch
patching file drivers/net/phy/sfp.c
Hunk #1 succeeded at 1634 (offset 44 lines).
Verify it:
bjorn@miraculix:/usr/local/src/git/linux$ git diff
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index 32c34c728c7a..4099752dbcd0 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -1634,6 +1634,8 @@ static int sfp_module_parse_power(struct sfp *sfp)
static int sfp_sm_mod_hpower(struct sfp *sfp, bool enable)
{
+ if (sfp->id.ext.sff8472_compliance == SFP_SFF8472_COMPLIANCE_NONE)
+ return 0;
u8 val;
int err;
Build again and notice a new warning:
bjorn@miraculix:/usr/local/src/git/linux$ make -C /lib/modules/$(uname
-r)/build M=$(pwd)/drivers/net/phy sfp.ko
make: Entering directory '/usr/src/linux-headers-5.10.0-9-amd64'
CC [M] /usr/local/src/git/linux/drivers/net/phy/sfp.o
/usr/local/src/git/linux/drivers/net/phy/sfp.c: In function ‘sfp_sm_mod_hpower’:
/usr/local/src/git/linux/drivers/net/phy/sfp.c:1639:2: warning: ISO C90 forbids
mixed declarations and code [-Wdeclaration-after-statement]
1639 | u8 val;
| ^~
MODPOST /usr/local/src/git/linux/drivers/net/phy/Module.symvers
CC [M] /usr/local/src/git/linux/drivers/net/phy/sfp.mod.o
LD [M] /usr/local/src/git/linux/drivers/net/phy/sfp.ko
make: Leaving directory '/usr/src/linux-headers-5.10.0-9-amd64'
Bjørn
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] bcm4908: sysupgrade: refactor handling different firmware formats
From: Rafał Miłecki
This results in setting format specific data (format info, extract
commands) in a single function. It should help maintaining sysupgrade
code.
This change has been tested on Asus GT-AC5300 and Netgear R8000P.
Signed-off-by: Rafał Miłecki
---
.../base-files/lib/upgrade/platform.sh| 108 --
1 file changed, 76 insertions(+), 32 deletions(-)
diff --git a/target/linux/bcm4908/base-files/lib/upgrade/platform.sh
b/target/linux/bcm4908/base-files/lib/upgrade/platform.sh
index ee43e3a713..c057f2dc58 100644
--- a/target/linux/bcm4908/base-files/lib/upgrade/platform.sh
+++ b/target/linux/bcm4908/base-files/lib/upgrade/platform.sh
@@ -4,6 +4,10 @@ RAMFS_COPY_BIN="bcm4908img expr"
PART_NAME=firmware
+BCM4908_FW_FORMAT=
+BCM4908_FW_BOARD_ID=
+BCM4908_FW_INT_IMG_FORMAT=
+
# $(1): file to read from
# $(2): offset in bytes
# $(3): length in bytes
@@ -34,7 +38,12 @@ platform_identify() {
magic=$(get_hex_u32_be "$1" 0)
case "$magic" in
2a23245e)
- echo "chk"
+ local header_len=$((0x$(get_hex_u32_be "$1" 4)))
+ local board_id_len=$(($header_len - 40))
+
+ BCM4908_FW_FORMAT="chk"
+ BCM4908_FW_BOARD_ID=$(dd if="$1" skip=40 bs=1
count=$board_id_len 2>/dev/null | hexdump -v -e '1/1 "%c"')
+ BCM4908_FW_INT_IMG_FORMAT="bcm4908img"
return
;;
esac
@@ -44,12 +53,22 @@ platform_identify() {
magic=$(get_content "$1" $((size - 20 - 64 + 8)) 12)
case "$magic" in
GT-AC5300)
- echo "asus"
+ local size=$(wc -c "$1" | cut -d ' ' -f 1)
+
+ BCM4908_FW_FORMAT="asus"
+ BCM4908_FW_BOARD_ID=$(get_content "$1" $((size - 20 -
64 + 8)) 12)
+ BCM4908_FW_INT_IMG_FORMAT="bcm4908img"
return
;;
esac
- echo "unknown"
+ # Detecting native format is a bit complex (it may start with CFE or
+ # JFFS2) so just use bcm4908img instead of bash hacks.
+ # Make it the last attempt as bcm4908img detects also vendor formats.
+ bcm4908img info -i "$1" > /dev/null && {
+ BCM4908_FW_FORMAT="bcm4908img"
+ return
+ }
}
platform_check_image() {
@@ -58,43 +77,51 @@ platform_check_image() {
local expected_image=$(platform_expected_image)
local error=0
- bcm4908img info -i "$1" > /dev/null || {
- echo "Failed to validate BCM4908 image" >&2
+ platform_identify "$1"
+ [ -z "$BCM4908_FW_FORMAT" ] && {
+ echo "Invalid image type. Please use firmware specific for this
device."
notify_firmware_broken
return 1
}
+ echo "Found $BCM4908_FW_FORMAT firmware for device
${BCM4908_FW_BOARD_ID:}"
- bcm4908img bootfs -i "$1" ls | grep -q "1-openwrt" || {
- # OpenWrt images have 1-openwrt dummy file in the bootfs.
- # Don't allow backup if it's missing
- notify_firmware_no_backup
+ local expected_image="$(platform_expected_image)"
+ [ -n "$expected_image" -a -n "$BCM4908_FW_BOARD_ID" -a
"$BCM4908_FW_FORMAT $BCM4908_FW_BOARD_ID" != "$expected_image" ] && {
+ echo "Firmware doesn't match device ($expected_image)"
+ error=1
}
- case "$(platform_identify "$1")" in
- asus)
- local size=$(wc -c "$1" | cut -d ' ' -f 1)
- local productid=$(get_content "$1" $((size - 20 - 64 +
8)) 12)
-
- [ -n "$expected_image" -a "asus $productid" !=
"$expected_image" ] && {
- echo "Firmware productid mismatch ($productid)"
>&2
- error=1
+ case "$BCM4908_FW_FORMAT" in
+ "bcm4908img")
+ bcm4908img info -i "$1" > /dev/null || {
+ echo "Failed to validate BCM4908 image" >&2
+ notify_firmware_broken
+ return 1
}
- ;;
- chk)
- local header_len=$((0x$(get_hex_u32_be "$1" 4)))
- local board_id_len=$(($header_len - 40))
- local board_id=$(dd if="$1" skip=40 bs=1
count=$board_id_len 2>/dev/null | hexdump -v -e '1/1 "%c"')
- [ -n "$expected_image" -a "chk $board_id" !=
"$expected_image" ] && {
- echo "Firmware board_id mismatch ($board_id)"
>&2
- error=1
+ bcm4908img bootfs -i "$1" ls | grep -q "1-openwrt" || {
+ # OpenWrt images have 1-openwrt dummy file in
the
