Re: [RFC PATCH 0/5] add support mikrotik routerboard hex poe
On 1/13/2022 9:46 AM, Oskari Lemmelä wrote: Hi, On 1/4/22 23:28, Sander Vanheule wrote: Hi, On Sun, 2021-12-26 at 20:41 +0200, Oskari Lemmela wrote: RFC patchset because of following open questions: --- [...] POE driver is implemented as a kernel module. Every port is separate hwmon device with same label as the DSA port. [...] Should this be implemented in Realtek POE switches as well? I haven't created any userspace tools for ubus integration yet Because I'm not sure if this is the right way to go. The hwmon part should be upstremable. Only thing is two non-standard sysfs controls (force_enable, port_state). They are also possible to implement as debugfs files if they are not accepted by the upstream. A short general comment, as this would be at least the fourth way to manage PoE devices in OpenWrt (GPIO controlled, realtek poe tool, ubiquiti poe tool). So this is more related to how OpenWrt could interface with PoE hardware in a more generic way, rather than this specific implementation (and I'm certainly not asking you to rewrite anything, Oskari). For controlling the outputs of PoE PSE ports, I had actually been thinking of using the the regulator framework in some way. This could range from simple GPIO controlled PoE ports (fixed-regulator), to actual PoE-controllers with current limits (PoE, PoE+...) and overload detection. That way existing interfaces could be used to manage (regulator) and monitor (regulator or hwmon) the outputs. I fear that adding custom hwmon interfaces for every type of PoE PSE out there just won't scale very well. I do not think the regulatory framework is the best for PoE control. It is more for displaying power dependencies and controlling power for power saving purposes. The best option could be to extend the netlink ethtool interface to support PoE standard data. This is quite similar to what SFP support has today. Ethtool is used to read EEPROM / FEC statistics and hwmon to display monitoring data. A GPIO controlled passive POE could only implement some parts of the ethtool netlink interface. IMHO, passive POE should never have been introduced, but I understand that the price of a product is more important than safety. Maybe getting feedback from the upstream Linux kernel maintainers would be a good way to move forward, assuming you would want these PoE drivers to land upstream as some point. From a quick look it seems to me that these PoE controllers should actually be modeled by a combination of regulator (for control) + hwmon (for reporting), possibly linked from a single parent device. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] ath79: use lzma-loader for ZyXEL NBG6716
Since gzip-compressed kernel image stopped fitting on 4MB kernel
partition on the device, use lzma-loader wrapping LZMA-compressed
kernel. This yields bootable device once again, and saves a very
substantial amount of space, the kernel size decreasing from about 4.4MB
to about 2.5MB for 5.10 kernel. This avoids changing of the flash layout
for the device.
While at that, reactivate the build for the device.
Fixes: 5d8ea6d34f9 ("ath79: Deactivate ZyXEL NBG6716 by default")
Cc: André Valentin
Cc: Hauke Mehrtens
Tested-by: Alex Henrie
Signed-off-by: Lech Perczak
---
target/linux/ath79/image/nand.mk | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/target/linux/ath79/image/nand.mk b/target/linux/ath79/image/nand.mk
index 91fd7ec301..d31aba1abc 100644
--- a/target/linux/ath79/image/nand.mk
+++ b/target/linux/ath79/image/nand.mk
@@ -301,8 +301,9 @@ define Device/zyxel_nbg6716
KERNEL_SIZE := 4096k
BLOCKSIZE := 128k
PAGESIZE := 2048
- KERNEL := kernel-bin | append-dtb | uImage none | zyxel-buildkerneljffs | \
- check-size 4096k
+ LOADER_TYPE := bin
+ KERNEL := kernel-bin | append-dtb | lzma | loader-kernel | uImage none | \
+ zyxel-buildkerneljffs | check-size 4096k
IMAGES := sysupgrade.tar sysupgrade-4M-Kernel.bin factory.bin
IMAGE/sysupgrade.tar/squashfs := append-rootfs | pad-to (BLOCKSIZE) | \
sysupgrade-tar rootfs=@ | append-metadata
@@ -311,6 +312,5 @@ define Device/zyxel_nbg6716
IMAGE/factory.bin := append-kernel | pad-to (KERNEL_SIZE) | append-ubi |
\
zyxel-factory
UBINIZE_OPTS := -E 5
- DEFAULT := n
endef
TARGET_DEVICES += zyxel_nbg6716
--
2.30.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC PATCH 0/5] add support mikrotik routerboard hex poe
Hi, On 1/4/22 23:28, Sander Vanheule wrote: Hi, On Sun, 2021-12-26 at 20:41 +0200, Oskari Lemmela wrote: RFC patchset because of following open questions: --- [...] POE driver is implemented as a kernel module. Every port is separate hwmon device with same label as the DSA port. [...] Should this be implemented in Realtek POE switches as well? I haven't created any userspace tools for ubus integration yet Because I'm not sure if this is the right way to go. The hwmon part should be upstremable. Only thing is two non-standard sysfs controls (force_enable, port_state). They are also possible to implement as debugfs files if they are not accepted by the upstream. A short general comment, as this would be at least the fourth way to manage PoE devices in OpenWrt (GPIO controlled, realtek poe tool, ubiquiti poe tool). So this is more related to how OpenWrt could interface with PoE hardware in a more generic way, rather than this specific implementation (and I'm certainly not asking you to rewrite anything, Oskari). For controlling the outputs of PoE PSE ports, I had actually been thinking of using the the regulator framework in some way. This could range from simple GPIO controlled PoE ports (fixed-regulator), to actual PoE-controllers with current limits (PoE, PoE+...) and overload detection. That way existing interfaces could be used to manage (regulator) and monitor (regulator or hwmon) the outputs. I fear that adding custom hwmon interfaces for every type of PoE PSE out there just won't scale very well. I do not think the regulatory framework is the best for PoE control. It is more for displaying power dependencies and controlling power for power saving purposes. The best option could be to extend the netlink ethtool interface to support PoE standard data. This is quite similar to what SFP support has today. Ethtool is used to read EEPROM / FEC statistics and hwmon to display monitoring data. A GPIO controlled passive POE could only implement some parts of the ethtool netlink interface. IMHO, passive POE should never have been introduced, but I understand that the price of a product is more important than safety. Oskari Not that I've ever actually worked with a regulator driver, so maybe I'm just talking nonsense. I would be happy to hear other opinions about this. :-) Best, Sander ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] ltq-deu: add ltq-deu back to default packages
From: Daniel Kestrel
After enhancing ltq-deu, build it by default for the devices
using it.
Reverts: 964863b ("ltq-deu: Mark lantiq DEU broken")
Signed-off-by: Daniel Kestrel
---
target/linux/lantiq/image/ar9.mk | 13 +++--
target/linux/lantiq/image/danube.mk | 2 +-
target/linux/lantiq/xrx200/target.mk | 1 +
3 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/target/linux/lantiq/image/ar9.mk b/target/linux/lantiq/image/ar9.mk
index d30e1ee492..434dacb121 100644
--- a/target/linux/lantiq/image/ar9.mk
+++ b/target/linux/lantiq/image/ar9.mk
@@ -8,7 +8,7 @@ define Device/avm_fritz7312
kmod-ltq-adsl-ar9-mei kmod-ltq-adsl-ar9 \
kmod-ltq-adsl-ar9-fw-b kmod-ltq-atm-ar9 \
ltq-adsl-app ppp-mod-pppoa \
- -swconfig
+ kmod-ltq-deu-ar9 -swconfig
endef
TARGET_DEVICES += avm_fritz7312
@@ -24,7 +24,7 @@ define Device/avm_fritz7320
kmod-ltq-adsl-ar9-mei kmod-ltq-adsl-ar9 \
kmod-ltq-adsl-ar9-fw-b kmod-ltq-atm-ar9 \
ltq-adsl-app ppp-mod-pppoa \
- kmod-usb-dwc2 -swconfig
+ kmod-ltq-deu-ar9 kmod-usb-dwc2 -swconfig
SUPPORTED_DEVICES += FRITZ7320
endef
TARGET_DEVICES += avm_fritz7320
@@ -40,6 +40,7 @@ define Device/bt_homehub-v3a
DEVICE_PACKAGES := kmod-usb-dwc2 \
kmod-ltq-adsl-ar9-mei kmod-ltq-adsl-ar9 \
kmod-ltq-adsl-ar9-fw-a kmod-ltq-atm-ar9 \
+ kmod-ltq-deu-ar9 \
ltq-adsl-app ppp-mod-pppoa \
kmod-ath9k kmod-owl-loader wpad-basic-wolfssl \
uboot-envtools
@@ -108,7 +109,7 @@ define Device/netgear_dgn3500
kmod-ath9k kmod-owl-loader wpad-basic-wolfssl \
kmod-ltq-adsl-ar9-mei kmod-ltq-adsl-ar9 \
kmod-ltq-adsl-ar9-fw-a kmod-ltq-atm-ar9 \
- ltq-adsl-app ppp-mod-pppoa
+ kmod-ltq-deu-ar9 ltq-adsl-app ppp-mod-pppoa
SUPPORTED_DEVICES += DGN3500
endef
TARGET_DEVICES += netgear_dgn3500
@@ -130,7 +131,7 @@ define Device/netgear_dgn3500b
kmod-ath9k kmod-owl-loader wpad-basic-wolfssl \
kmod-ltq-adsl-ar9-mei kmod-ltq-adsl-ar9 \
kmod-ltq-adsl-ar9-fw-b kmod-ltq-atm-ar9 \
- ltq-adsl-app ppp-mod-pppoa
+ kmod-ltq-deu-ar9 ltq-adsl-app ppp-mod-pppoa
SUPPORTED_DEVICES += DGN3500B
endef
TARGET_DEVICES += netgear_dgn3500b
@@ -143,7 +144,7 @@ define Device/zte_h201l
DEVICE_PACKAGES := kmod-ath9k-htc wpad-basic-wolfssl \
kmod-ltq-adsl-ar9-mei kmod-ltq-adsl-ar9 \
kmod-ltq-adsl-ar9-fw-b kmod-ltq-atm-ar9 \
- ltq-adsl-app ppp-mod-pppoe \
+ kmod-ltq-deu-ar9 ltq-adsl-app ppp-mod-pppoe \
kmod-usb-dwc2 kmod-usb-ledtrig-usbport \
kmod-ltq-tapi kmod-ltq-vmmc
SUPPORTED_DEVICES += H201L
@@ -159,7 +160,7 @@ define Device/zyxel_p-2601hn
DEVICE_PACKAGES := kmod-rt2800-usb wpad-basic-wolfssl \
kmod-ltq-adsl-ar9-mei kmod-ltq-adsl-ar9 \
kmod-ltq-adsl-ar9-fw-b kmod-ltq-atm-ar9 \
- ltq-adsl-app ppp-mod-pppoe \
+ kmod-ltq-deu-ar9 ltq-adsl-app ppp-mod-pppoe \
kmod-usb-dwc2
SUPPORTED_DEVICES += P2601HNFX
endef
diff --git a/target/linux/lantiq/image/danube.mk
b/target/linux/lantiq/image/danube.mk
index 9b37bfb595..9cafd2b258 100644
--- a/target/linux/lantiq/image/danube.mk
+++ b/target/linux/lantiq/image/danube.mk
@@ -192,7 +192,7 @@ define Device/bt_homehub-v2b
DEVICE_PACKAGES := kmod-usb-dwc2 \
kmod-ltq-adsl-danube-mei kmod-ltq-adsl-danube \
kmod-ltq-adsl-danube-fw-a kmod-ltq-atm-danube \
- ltq-adsl-app ppp-mod-pppoa \
+ kmod-ltq-deu-danube ltq-adsl-app ppp-mod-pppoa \
kmod-ath9k kmod-owl-loader wpad-basic-wolfssl
SUPPORTED_DEVICES += BTHOMEHUBV2B
DEFAULT := n
diff --git a/target/linux/lantiq/xrx200/target.mk
b/target/linux/lantiq/xrx200/target.mk
index 55299f632f..8813de8d04 100644
--- a/target/linux/lantiq/xrx200/target.mk
+++ b/target/linux/lantiq/xrx200/target.mk
@@ -10,6 +10,7 @@ DEFAULT_PACKAGES+=kmod-leds-gpio \
kmod-ltq-vdsl-vr9-mei \
kmod-ltq-vdsl-vr9 \
kmod-ltq-atm-vr9 \
+ kmod-ltq-deu-vr9 \
kmod-ltq-ptm-vr9 \
ltq-vdsl-app \
dsl-vrx200-firmware-xdsl-a \
--
2.17.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] firmware-utils: support checksum for AVM fritzbox wasp SOCs
From: Daniel Kestrel
This patch adds creating the checksum to be able to create an
image and boot the secondary ath79 based wireless assist (WASP)
SoC with a second instance of OpenWrt for some AVM Fritzbox
devices (3390, 3490, 5490, 7490).
The utility is called avm-wasp-checksum and was originally
created by Andreas Boehler.
Signed-off-by: Daniel Kestrel
---
CMakeLists.txt | 1 +
src/avm-wasp-checksum.c | 141
2 files changed, 142 insertions(+)
create mode 100644 src/avm-wasp-checksum.c
diff --git a/CMakeLists.txt b/CMakeLists.txt
index f406520..5f886ba 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -29,6 +29,7 @@ ENDMACRO(FW_UTIL)
FW_UTIL(add_header "" "" "")
FW_UTIL(addpattern "" "" "")
FW_UTIL(asustrx "" "" "")
+FW_UTIL(avm-wasp-checksum "" --std=gnu99 "")
FW_UTIL(bcm4908asus "" "" "")
FW_UTIL(bcm4908kernel "" "" "")
FW_UTIL(buffalo-enc src/buffalo-lib.c "" "")
diff --git a/src/avm-wasp-checksum.c b/src/avm-wasp-checksum.c
new file mode 100644
index 000..cbf6a19
--- /dev/null
+++ b/src/avm-wasp-checksum.c
@@ -0,0 +1,141 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2020 Andreas Boehler
+ *
+ * This tool was based on:
+ * firmware-crc.pl by Atheros Communications
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include /* for getopt() */
+#include
+
+char *infile;
+char *outfile;
+char *progname;
+enum {
+ MODEL_3390,
+ MODEL_X490
+} model;
+
+#define CHUNK_SIZE 256
+
+uint32_t crc32_for_byte(uint32_t r)
+{
+ for (int j = 0; j < 8; ++j)
+ r = (r & 1 ? 0 : (uint32_t)0xEDB88320L) ^ r >> 1;
+ return r ^ (uint32_t)0xFF00L;
+}
+
+void crc32(const void *data, size_t n_bytes, uint32_t *crc)
+{
+ static uint32_t table[0x100];
+
+ if (!*table)
+ for (size_t i = 0; i < 0x100; ++i)
+ table[i] = crc32_for_byte(i);
+ for (size_t i = 0; i < n_bytes; ++i)
+ *crc = table[(uint8_t)*crc ^ ((uint8_t *)data)[i]] ^ *crc >> 8;
+}
+
+static void usage(int status)
+{
+ fprintf(stderr, "Usage: %s [OPTIONS...]\n", progname);
+ fprintf(stderr,
+ "\n"
+ "Options:\n"
+ " -i input file name\n"
+ " -o output file name\n"
+ " -m model (3390, x490 for 3490/5490/7490)\n"
+ " -h show this screen\n"
+ );
+
+ exit(status);
+}
+
+int main(int argc, char *argv[])
+{
+ uint32_t crc = 0;
+ FILE *in_fp;
+ FILE *out_fp;
+ uint32_t buf[CHUNK_SIZE];
+ ssize_t read;
+
+ progname = argv[0];
+
+ while (1) {
+ int c;
+
+ c = getopt(argc, argv, "i:o:m:h");
+ if (c == -1)
+ break;
+
+ switch (c) {
+ case 'i':
+ infile = optarg;
+ break;
+ case 'o':
+ outfile = optarg;
+ break;
+ case 'm':
+ if (strcmp(optarg, "3390") == 0)
+ model = MODEL_3390;
+ else if (strcmp(optarg, "x490") == 0)
+ model = MODEL_X490;
+ else
+ usage(EXIT_FAILURE);
+ break;
+ case 'h':
+ usage(EXIT_SUCCESS);
+ default:
+ usage(EXIT_FAILURE);
+ break;
+ }
+ }
+
+ if (!infile || !outfile)
+ usage(EXIT_FAILURE);
+
+ in_fp = fopen(infile, "r");
+ if (!in_fp) {
+ fprintf(stderr, "Error opening input file: %s\n", infile);
+ return EXIT_FAILURE;
+ }
+ out_fp = fopen(outfile, "w");
+ if (!out_fp) {
+ fprintf(stderr, "Error opening output file: %s\n", outfile);
+ fclose(in_fp);
+ return EXIT_FAILURE;
+ }
+
+ while (!feof(in_fp)) {
+ switch (model) {
+ case MODEL_3390:
+ read = fread(buf, sizeof(uint32_t), CHUNK_SIZE, in_fp);
+ for (int i = 0; i < read; i++)
+ crc = crc ^ buf[i];
+ fwrite(buf, sizeof(uint32_t), read, out_fp);
+ break;
+ case MODEL_X490:
+ read = fread(buf, 1, sizeof(uint32_t) * CHUNK_SIZE,
in_fp);
+ crc32(buf, read, );
+ fwrite(buf, 1, read, out_fp);
+ break;
+ }
+ }
+
