Re: Invert wpad selection for mt7621
Hi Adrian, Op dinsdag 4 augustus 2020 om 16u54 schreef m...@adrianschmutzler.de: Hi, for ramips/mt7621, the wpad-basic package is not selected by default, but added for every device individually. While this might be technically correct if the SoC does not come with a Wifi module, only 18 of 97 devices for that platform are set up _without_ wpad-basic currently. Therefore, I wonder if it wouldn't be more convenient to add wpad-basic (or wpad-basic-wolfssl...) by default for the subtarget and then just remove it (-wpad-basic) for the 18 mentioned devices, instead of having to add it for about 60 times instead. This would also match the behavior of the other subtargets, where it is added by default anyway. Opinions? I think this makes a lot of sense. Best Adrian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: your mail
On Wed, Aug 05, 2020 at 04:51:00PM -0300, SAn via openwrt-devel wrote: > The sender domain has a DMARC Reject/Quarantine policy which disallows > sending mailing list messages using the original "From" header. > > To mitigate this problem, the original message has been wrapped > automatically by the mailing list software. > Date: Wed, 5 Aug 2020 16:51:00 -0300 > From: SAn > To: Daniel Golle > Cc: s@gmx.de, openwrt-devel@lists.openwrt.org > Subject: Re: your mail > > Hi Daniel > > On 8/5/20 6:04 AM, Daniel Golle wrote: > > On Tue, Aug 04, 2020 at 08:35:26PM -0300, SAn via openwrt-devel wrote: > >> The sender domain has a DMARC Reject/Quarantine policy which disallows > >> sending mailing list messages using the original "From" header. > >> > >> To mitigate this problem, the original message has been wrapped > >> automatically by the mailing list software. > > > >> Date: Tue, 4 Aug 2020 20:35:26 -0300 > >> From: SAn > >> To: Daniel Golle , s@gmx.de > >> Cc: openwrt-devel@lists.openwrt.org > >> Subject: Re: your mail > >> > >> Hi Stefan and Daniel, > >> > >> On 8/2/20 8:19 PM, Daniel Golle wrote: > >>> On Sun, Aug 02, 2020 at 07:49:40PM -0300, SAn via openwrt-devel wrote: > Subject: ath79 subtarget with cmdline from bootloader > > Hi! > > The LibreRouter uses a dual-boot scheme that relies on the bootloader > configuring the kernel cmdline. At ar71xx 18.06 it was possible to > select per device if the cmdline from the bootloader has to be honored > (using patch-cmdline). > AFAIK there is no such possibility on ath79. > > Would you consider accepting a patch that adds a new ath79 subtarget > with CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER (or > CONFIG_MIPS_CMDLINE_BUILTIN_EXTEND)? > > It would be valuable for the people using LibreRouter devices to be able > to use official OpenWrt 20.xx images with the dual-boot support. > Currently there are multiple mips targets that use > CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER (bcm47xx, octeon, malta, and a few > more). > >>> > >>> I don't think this justifies an extra subtarget just for the sake of > >>> having the kernel process cmdline arguments passed by an outdated > >>> (ie. non-DT, non-FIT) bootloader. > >>> If it really has to be that way (and eg. parsing uboot-env cannot be > >>> used instead and bootloader cannot be updated to properly pass this > >> . > >> > >> Another bootloader can be used, but I am not aware of a newer one with > >> QCA955x support, do you? The last time I checked u-boot there was upstream > >> support to qca956x and qca953x. Adding support to 955x seemed to me a lot > >> of work (there are thousands of undocumented constants everywhere in the > >> code), but maybe I am mistaken? > >> > >> I did not understand the "parsing uboot-env". Can you expand on this > >> please? :) > > > > You can hack a MTD partition parser(/-splitter) which evaluates the > > U-Boot environment and according to what it finds there sets partition > > names accordingly (ie. swap firmware with firmware2, then 'firmware' > > will be split into 'kernel' and 'rootfs' during boot). > > For sysupgrade you can then always use firmware2 (ie. the currently > > unused image) and toggle which image to load on boot by default (eg. > > by using fw_setenv) > > How does librerouter's vendor U-Boot decide which image to boot? > > If I understand you, that is how it is done at the moment, here [0] is > documented. Or are you saying to read this u-boot env from the kernel itself > to find out the mtd particions? Yes exactly. If updating U-Boot to something which can do FIT and DT is not an option that's kinda the only thing you got left. It's not terribly hard to do and has been done before :) > > > >> > >>> in dtb), I guess something along the lines of > >>> CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_MANGLE > >>> could work (would have to be implemented for MIPS first, obviously) > >> > >> If there is no other viable way I would go this way.. > >> Thanks Stefan for the pointers to the patches! > >> > >>> Alternatively, as a quick-and-dirty workaround, just move the whole > >>> librerouter.dts into a .dtsi and then have two .dts files referecing > >>> them, each setting different cmdline. Then generate two images. > >>> That'd be the same effect as what patch-cmdline used to do on non-DT > >>> targets. > >>> > >> > >> I think this is too complicated for end users. Maybe a friendlier way > >> could be to pack both images into a tarfile and then use the correct one > >> from a userspace tool to perform the upgrade. > > > > How have you been managing this on ar71xx until now? > > From the fork [1] we just don't have the patch-cmdline in the kernel for the > device, so the kernel load the mtd from the cmdline. So until now only images > provided by our fork can be installed properly using dual-boot. Official > OpenWrt images can be installed only in the first partition
[PATCH] kernel: fix mtd partition erase
This bug applied where mtd partition end address,
or erase start address, was not cleanly divisible by parent mtd erasesize.
This error would cause the bits following the end of the partition
to the next erasesize block boundary to be erased,
and this partition-overflow data to be written to the partition erase
address (missing additional partition offset address)
of the mtd (top) parent device.
Signed-off-by: John Thomson
--
4.19 also requires this fix
A little discussion here:
https://github.com/openwrt/openwrt/pull/3103#issuecomment-667610510
mtdpart.c should be made to work with 4K erase sectors, where available
Considering this here:
https://github.com/openwrt/openwrt/pull/3271
---
.../411-mtd-partial_eraseblock_write.patch | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git
a/target/linux/generic/pending-5.4/411-mtd-partial_eraseblock_write.patch
b/target/linux/generic/pending-5.4/411-mtd-partial_eraseblock_write.patch
index b46c3f5ed4..c48a144d3d 100644
--- a/target/linux/generic/pending-5.4/411-mtd-partial_eraseblock_write.patch
+++ b/target/linux/generic/pending-5.4/411-mtd-partial_eraseblock_write.patch
@@ -19,7 +19,7 @@ Signed-off-by: Felix Fietkau
/* Our partition linked list */
static LIST_HEAD(mtd_partitions);
static DEFINE_MUTEX(mtd_partitions_mutex);
-@@ -206,6 +208,53 @@ static int part_erase(struct mtd_info *m
+@@ -206,11 +208,77 @@ static int part_erase(struct mtd_info *m
{
struct mtd_part *part = mtd_to_part(mtd);
int ret;
@@ -73,10 +73,9 @@ Signed-off-by: Felix Fietkau
instr->addr += part->offset;
ret = part->parent->_erase(part->parent, instr);
-@@ -213,6 +262,24 @@ static int part_erase(struct mtd_info *m
+ if (instr->fail_addr != MTD_FAIL_ADDR_UNKNOWN)
instr->fail_addr -= part->offset;
- instr->addr -= part->offset;
-
++
+ if (mtd->flags & MTD_ERASE_PARTIAL) {
+ if (partial_start) {
+ part->parent->_write(part->parent,
@@ -95,10 +94,10 @@ Signed-off-by: Felix Fietkau
+ kfree(erase_buf);
+ }
+
- return ret;
- }
+ instr->addr -= part->offset;
-@@ -525,19 +592,22 @@ static struct mtd_part *allocate_partiti
+ return ret;
+@@ -525,19 +593,22 @@ static struct mtd_part *allocate_partiti
remainder = do_div(tmp, wr_alignment);
if ((slave->mtd.flags & MTD_WRITEABLE) && remainder) {
/* Doesn't start on a boundary of major erase size */
--
2.28.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] ramips: switch rt305x subtarget to kernel 5.4
RT3x5x seems to work fine with kernel 5.4. Set the default kernel version to 5.4 to bring this to a broader audience. Tested on ZyXEL Keenetic. Signed-off-by: Alexey Dobrovolsky --- target/linux/ramips/rt305x/target.mk | 1 + 1 file changed, 1 insertion(+) diff --git a/target/linux/ramips/rt305x/target.mk b/target/linux/ramips/rt305x/target.mk index 51edace592..7b6df744a0 100644 --- a/target/linux/ramips/rt305x/target.mk +++ b/target/linux/ramips/rt305x/target.mk @@ -8,6 +8,7 @@ FEATURES+=usb ramdisk small_flash CPU_TYPE:=24kc DEFAULT_PACKAGES += kmod-rt2800-soc wpad-mini swconfig +KERNEL_PATCHVER:=5.4 define Target/Description Build firmware images for Ralink RT3x5x/RT5350 based boards. -- 2.17.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[no subject]
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi Daniel On 8/5/20 6:04 AM, Daniel Golle wrote: > On Tue, Aug 04, 2020 at 08:35:26PM -0300, SAn via openwrt-devel wrote: >> The sender domain has a DMARC Reject/Quarantine policy which disallows >> sending mailing list messages using the original "From" header. >> >> To mitigate this problem, the original message has been wrapped >> automatically by the mailing list software. > >> Date: Tue, 4 Aug 2020 20:35:26 -0300 >> From: SAn >> To: Daniel Golle , s@gmx.de >> Cc: openwrt-devel@lists.openwrt.org >> Subject: Re: your mail >> >> Hi Stefan and Daniel, >> >> On 8/2/20 8:19 PM, Daniel Golle wrote: >>> On Sun, Aug 02, 2020 at 07:49:40PM -0300, SAn via openwrt-devel wrote: Subject: ath79 subtarget with cmdline from bootloader Hi! The LibreRouter uses a dual-boot scheme that relies on the bootloader configuring the kernel cmdline. At ar71xx 18.06 it was possible to select per device if the cmdline from the bootloader has to be honored (using patch-cmdline). AFAIK there is no such possibility on ath79. Would you consider accepting a patch that adds a new ath79 subtarget with CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER (or CONFIG_MIPS_CMDLINE_BUILTIN_EXTEND)? It would be valuable for the people using LibreRouter devices to be able to use official OpenWrt 20.xx images with the dual-boot support. Currently there are multiple mips targets that use CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER (bcm47xx, octeon, malta, and a few more). >>> >>> I don't think this justifies an extra subtarget just for the sake of >>> having the kernel process cmdline arguments passed by an outdated >>> (ie. non-DT, non-FIT) bootloader. >>> If it really has to be that way (and eg. parsing uboot-env cannot be >>> used instead and bootloader cannot be updated to properly pass this >> . >> >> Another bootloader can be used, but I am not aware of a newer one with >> QCA955x support, do you? The last time I checked u-boot there was upstream >> support to qca956x and qca953x. Adding support to 955x seemed to me a lot of >> work (there are thousands of undocumented constants everywhere in the code), >> but maybe I am mistaken? >> >> I did not understand the "parsing uboot-env". Can you expand on this please? >> :) > > You can hack a MTD partition parser(/-splitter) which evaluates the > U-Boot environment and according to what it finds there sets partition > names accordingly (ie. swap firmware with firmware2, then 'firmware' > will be split into 'kernel' and 'rootfs' during boot). > For sysupgrade you can then always use firmware2 (ie. the currently > unused image) and toggle which image to load on boot by default (eg. > by using fw_setenv) > How does librerouter's vendor U-Boot decide which image to boot? If I understand you, that is how it is done at the moment, here [0] is documented. Or are you saying to read this u-boot env from the kernel itself to find out the mtd particions? >> >>> in dtb), I guess something along the lines of >>> CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_MANGLE >>> could work (would have to be implemented for MIPS first, obviously) >> >> If there is no other viable way I would go this way.. >> Thanks Stefan for the pointers to the patches! >> >>> Alternatively, as a quick-and-dirty workaround, just move the whole >>> librerouter.dts into a .dtsi and then have two .dts files referecing >>> them, each setting different cmdline. Then generate two images. >>> That'd be the same effect as what patch-cmdline used to do on non-DT >>> targets. >>> >> >> I think this is too complicated for end users. Maybe a friendlier way could >> be to pack both images into a tarfile and then use the correct one from a >> userspace tool to perform the upgrade. > > How have you been managing this on ar71xx until now? >From the fork [1] we just don't have the patch-cmdline in the kernel for the >device, so the kernel load the mtd from the cmdline. So until now only images >provided by our fork can be installed properly using dual-boot. Official >OpenWrt images can be installed only in the first partition (and if usins >sysupgrade only from the first firmware partition also). [0] https://github.com/libremesh/lime-packages/blob/master/packages/safe-upgrade/Readme.md#how-safe-upgrade-works [1] https://gitlab.com/librerouter/librerouteros Thanks SAn --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] ath79: drop redundant kmods-leds-gpio
The ath79 target has CONFIG_LEDS_GPIO=y set in kernel config, so no need to pull the kmod-leds-gpio module for specific devices. Signed-off-by: Adrian Schmutzler --- target/linux/ath79/image/generic.mk | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/target/linux/ath79/image/generic.mk b/target/linux/ath79/image/generic.mk index 2e52be0959..6b7bfb4639 100644 --- a/target/linux/ath79/image/generic.mk +++ b/target/linux/ath79/image/generic.mk @@ -367,7 +367,7 @@ define Device/comfast_cf-e110n-v2 DEVICE_VENDOR := COMFAST DEVICE_MODEL := CF-E110N DEVICE_VARIANT := v2 - DEVICE_PACKAGES := rssileds kmod-leds-gpio -swconfig -uboot-envtools + DEVICE_PACKAGES := rssileds -swconfig -uboot-envtools IMAGE_SIZE := 16192k endef TARGET_DEVICES += comfast_cf-e110n-v2 @@ -377,7 +377,7 @@ define Device/comfast_cf-e120a-v3 DEVICE_VENDOR := COMFAST DEVICE_MODEL := CF-E120A DEVICE_VARIANT := v3 - DEVICE_PACKAGES := rssileds kmod-leds-gpio -uboot-envtools + DEVICE_PACKAGES := rssileds -uboot-envtools IMAGE_SIZE := 8000k endef TARGET_DEVICES += comfast_cf-e120a-v3 @@ -387,7 +387,7 @@ define Device/comfast_cf-e130n-v2 DEVICE_VENDOR := COMFAST DEVICE_MODEL := CF-E130N DEVICE_VARIANT := v2 - DEVICE_PACKAGES := rssileds kmod-leds-gpio -swconfig -uboot-envtools + DEVICE_PACKAGES := rssileds -swconfig -uboot-envtools IMAGE_SIZE := 7936k endef TARGET_DEVICES += comfast_cf-e130n-v2 @@ -396,7 +396,7 @@ define Device/comfast_cf-e313ac SOC := qca9531 DEVICE_VENDOR := COMFAST DEVICE_MODEL := CF-E313AC - DEVICE_PACKAGES := rssileds kmod-leds-gpio kmod-ath10k-ct-smallbuffers \ + DEVICE_PACKAGES := rssileds kmod-ath10k-ct-smallbuffers \ ath10k-firmware-qca9888-ct -swconfig -uboot-envtools IMAGE_SIZE := 7936k endef @@ -416,7 +416,7 @@ define Device/comfast_cf-e5 SOC := qca9531 DEVICE_VENDOR := COMFAST DEVICE_MODEL := CF-E5/E7 - DEVICE_PACKAGES := rssileds kmod-leds-gpio kmod-usb2 kmod-usb-net \ + DEVICE_PACKAGES := rssileds kmod-usb2 kmod-usb-net \ kmod-usb-net-qmi-wwan -swconfig -uboot-envtools IMAGE_SIZE := 16192k endef @@ -426,8 +426,7 @@ define Device/comfast_cf-e560ac SOC := qca9531 DEVICE_VENDOR := COMFAST DEVICE_MODEL := CF-E560AC - DEVICE_PACKAGES := kmod-leds-gpio kmod-usb2 kmod-ath10k-ct \ - ath10k-firmware-qca9888-ct + DEVICE_PACKAGES := kmod-usb2 kmod-ath10k-ct ath10k-firmware-qca9888-ct IMAGE_SIZE := 16128k endef TARGET_DEVICES += comfast_cf-e560ac -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2] treewide: make dependency on kmod-usb-net selective
A bunch of kernel modules depends on kmod-usb-net, but does not select it. Make AddDepends/usb-net selective, so we can drop some redundant +kmod-usb-net definitions for DEVICE_PACKAGES. Signed-off-by: Adrian Schmutzler --- Changes in v2: - actually include the package change this time --- package/kernel/linux/modules/usb.mk| 2 +- target/linux/ath79/image/generic-tp-link.mk| 2 +- target/linux/ath79/image/generic.mk| 4 ++-- target/linux/mxs/profiles/02-olinuxino-maxi.mk | 2 +- target/linux/omap/image/Makefile | 2 +- target/linux/omap/profiles/00-default.mk | 1 - target/linux/ramips/image/mt7620.mk| 2 +- target/linux/ramips/image/rt305x.mk| 2 +- target/linux/rockchip/image/armv8.mk | 2 +- target/linux/sunxi/image/cortexa7.mk | 2 +- 10 files changed, 10 insertions(+), 11 deletions(-) diff --git a/package/kernel/linux/modules/usb.mk b/package/kernel/linux/modules/usb.mk index e833c139a0..e4f6a226fd 100644 --- a/package/kernel/linux/modules/usb.mk +++ b/package/kernel/linux/modules/usb.mk @@ -1136,7 +1136,7 @@ $(eval $(call KernelPackage,usb-net)) define AddDepends/usb-net SUBMENU:=$(USB_MENU) - DEPENDS+=kmod-usb-net $(1) + DEPENDS+=+kmod-usb-net $(1) endef diff --git a/target/linux/ath79/image/generic-tp-link.mk b/target/linux/ath79/image/generic-tp-link.mk index 967eb2a7c3..d884d6f9c8 100644 --- a/target/linux/ath79/image/generic-tp-link.mk +++ b/target/linux/ath79/image/generic-tp-link.mk @@ -428,7 +428,7 @@ define Device/tplink_tl-mr6400-v1 DEVICE_MODEL := TL-MR6400 DEVICE_VARIANT := v1 TPLINK_HWID := 0x6401 - DEVICE_PACKAGES := kmod-usb2 kmod-usb-net kmod-usb-net-rndis kmod-usb-serial \ + DEVICE_PACKAGES := kmod-usb2 kmod-usb-net-rndis kmod-usb-serial \ kmod-usb-serial-option adb-enablemodem SUPPORTED_DEVICES += tl-mr6400 endef diff --git a/target/linux/ath79/image/generic.mk b/target/linux/ath79/image/generic.mk index 6b7bfb4639..7eaaa28ae9 100644 --- a/target/linux/ath79/image/generic.mk +++ b/target/linux/ath79/image/generic.mk @@ -416,8 +416,8 @@ define Device/comfast_cf-e5 SOC := qca9531 DEVICE_VENDOR := COMFAST DEVICE_MODEL := CF-E5/E7 - DEVICE_PACKAGES := rssileds kmod-usb2 kmod-usb-net \ - kmod-usb-net-qmi-wwan -swconfig -uboot-envtools + DEVICE_PACKAGES := rssileds kmod-usb2 kmod-usb-net-qmi-wwan -swconfig \ + -uboot-envtools IMAGE_SIZE := 16192k endef TARGET_DEVICES += comfast_cf-e5 diff --git a/target/linux/mxs/profiles/02-olinuxino-maxi.mk b/target/linux/mxs/profiles/02-olinuxino-maxi.mk index 59d0376689..e3d1c3b3c0 100644 --- a/target/linux/mxs/profiles/02-olinuxino-maxi.mk +++ b/target/linux/mxs/profiles/02-olinuxino-maxi.mk @@ -8,7 +8,7 @@ define Profile/olinuxino-maxi NAME:=Olimex OLinuXino Maxi/Mini boards PACKAGES += imx-bootlets uboot-mxs-mx23_olinuxino \ - kmod-usb-net kmod-usb-net-smsc95xx kmod-gpio-mcp23s08 \ + kmod-usb-net-smsc95xx kmod-gpio-mcp23s08 \ kmod-leds-gpio kmod-ledtrig-heartbeat kmod-sound-core endef diff --git a/target/linux/omap/image/Makefile b/target/linux/omap/image/Makefile index 3700788804..ce6377f29b 100644 --- a/target/linux/omap/image/Makefile +++ b/target/linux/omap/image/Makefile @@ -70,7 +70,7 @@ define Device/ti_omap3-beagle DEVICE_VENDOR := BeagleBoard.org DEVICE_MODEL := OMAP3 TI beagleboard # beagleboard doesn't have a network interface, support most common usb net - DEVICE_PACKAGES := kmod-usb-net \ + DEVICE_PACKAGES := \ kmod-usb-net-asix kmod-usb-net-asix-ax88179 kmod-usb-net-hso \ kmod-usb-net-kaweth kmod-usb-net-pegasus kmod-usb-net-mcs7830 \ kmod-usb-net-smsc95xx kmod-usb-net-dm9601-ether diff --git a/target/linux/omap/profiles/00-default.mk b/target/linux/omap/profiles/00-default.mk index 37c0761029..e33886d890 100644 --- a/target/linux/omap/profiles/00-default.mk +++ b/target/linux/omap/profiles/00-default.mk @@ -8,7 +8,6 @@ define Profile/Default NAME:=Default Profile PACKAGES:= \ - kmod-usb-net \ kmod-usb-net-asix kmod-usb-net-asix-ax88179 kmod-usb-net-hso \ kmod-usb-net-kaweth kmod-usb-net-pegasus kmod-usb-net-mcs7830 \ kmod-usb-net-smsc95xx kmod-usb-net-dm9601-ether \ diff --git a/target/linux/ramips/image/mt7620.mk b/target/linux/ramips/image/mt7620.mk index 7ebab8d757..20aafc95d6 100644 --- a/target/linux/ramips/image/mt7620.mk +++ b/target/linux/ramips/image/mt7620.mk @@ -1003,7 +1003,7 @@ define Device/tplink_archer-mr200 TPLINK_HWID := 0xd751 TPLINK_HWREV := 0x4a IMAGES := sysupgrade.bin - DEVICE_PACKAGES := kmod-mt76x0e kmod-usb2 kmod-usb-net kmod-usb-net-rndis \ + DEVICE_PACKAGES := kmod-mt76x0e kmod-usb2 kmod-usb-net-rndis \ kmod-usb-serial kmod-usb-serial-option adb-enablemodem DEVICE_MODEL := Archer MR200 SUPPORTED_DEVICES += mr200 diff --git a/target/linux/ramips/image/rt305x.mk b/target/linux/ramips/image/rt305x.mk ind
[PATCH] treewide: make dependency on kmod-usb-net selective
A bunch of kernel modules depends on kmod-usb-net, but does not select it. Make AddDepends/usb-net selective, so we can drop some redundant +kmod-usb-net definitions for DEVICE_PACKAGES. Signed-off-by: Adrian Schmutzler --- target/linux/ath79/image/generic-tp-link.mk| 2 +- target/linux/ath79/image/generic.mk| 4 ++-- target/linux/mxs/profiles/02-olinuxino-maxi.mk | 2 +- target/linux/omap/image/Makefile | 2 +- target/linux/omap/profiles/00-default.mk | 1 - target/linux/ramips/image/mt7620.mk| 2 +- target/linux/ramips/image/rt305x.mk| 2 +- target/linux/rockchip/image/armv8.mk | 2 +- target/linux/sunxi/image/cortexa7.mk | 2 +- 9 files changed, 9 insertions(+), 10 deletions(-) diff --git a/target/linux/ath79/image/generic-tp-link.mk b/target/linux/ath79/image/generic-tp-link.mk index 967eb2a7c3..d884d6f9c8 100644 --- a/target/linux/ath79/image/generic-tp-link.mk +++ b/target/linux/ath79/image/generic-tp-link.mk @@ -428,7 +428,7 @@ define Device/tplink_tl-mr6400-v1 DEVICE_MODEL := TL-MR6400 DEVICE_VARIANT := v1 TPLINK_HWID := 0x6401 - DEVICE_PACKAGES := kmod-usb2 kmod-usb-net kmod-usb-net-rndis kmod-usb-serial \ + DEVICE_PACKAGES := kmod-usb2 kmod-usb-net-rndis kmod-usb-serial \ kmod-usb-serial-option adb-enablemodem SUPPORTED_DEVICES += tl-mr6400 endef diff --git a/target/linux/ath79/image/generic.mk b/target/linux/ath79/image/generic.mk index 6b7bfb4639..7eaaa28ae9 100644 --- a/target/linux/ath79/image/generic.mk +++ b/target/linux/ath79/image/generic.mk @@ -416,8 +416,8 @@ define Device/comfast_cf-e5 SOC := qca9531 DEVICE_VENDOR := COMFAST DEVICE_MODEL := CF-E5/E7 - DEVICE_PACKAGES := rssileds kmod-usb2 kmod-usb-net \ - kmod-usb-net-qmi-wwan -swconfig -uboot-envtools + DEVICE_PACKAGES := rssileds kmod-usb2 kmod-usb-net-qmi-wwan -swconfig \ + -uboot-envtools IMAGE_SIZE := 16192k endef TARGET_DEVICES += comfast_cf-e5 diff --git a/target/linux/mxs/profiles/02-olinuxino-maxi.mk b/target/linux/mxs/profiles/02-olinuxino-maxi.mk index 59d0376689..e3d1c3b3c0 100644 --- a/target/linux/mxs/profiles/02-olinuxino-maxi.mk +++ b/target/linux/mxs/profiles/02-olinuxino-maxi.mk @@ -8,7 +8,7 @@ define Profile/olinuxino-maxi NAME:=Olimex OLinuXino Maxi/Mini boards PACKAGES += imx-bootlets uboot-mxs-mx23_olinuxino \ - kmod-usb-net kmod-usb-net-smsc95xx kmod-gpio-mcp23s08 \ + kmod-usb-net-smsc95xx kmod-gpio-mcp23s08 \ kmod-leds-gpio kmod-ledtrig-heartbeat kmod-sound-core endef diff --git a/target/linux/omap/image/Makefile b/target/linux/omap/image/Makefile index 3700788804..ce6377f29b 100644 --- a/target/linux/omap/image/Makefile +++ b/target/linux/omap/image/Makefile @@ -70,7 +70,7 @@ define Device/ti_omap3-beagle DEVICE_VENDOR := BeagleBoard.org DEVICE_MODEL := OMAP3 TI beagleboard # beagleboard doesn't have a network interface, support most common usb net - DEVICE_PACKAGES := kmod-usb-net \ + DEVICE_PACKAGES := \ kmod-usb-net-asix kmod-usb-net-asix-ax88179 kmod-usb-net-hso \ kmod-usb-net-kaweth kmod-usb-net-pegasus kmod-usb-net-mcs7830 \ kmod-usb-net-smsc95xx kmod-usb-net-dm9601-ether diff --git a/target/linux/omap/profiles/00-default.mk b/target/linux/omap/profiles/00-default.mk index 37c0761029..e33886d890 100644 --- a/target/linux/omap/profiles/00-default.mk +++ b/target/linux/omap/profiles/00-default.mk @@ -8,7 +8,6 @@ define Profile/Default NAME:=Default Profile PACKAGES:= \ - kmod-usb-net \ kmod-usb-net-asix kmod-usb-net-asix-ax88179 kmod-usb-net-hso \ kmod-usb-net-kaweth kmod-usb-net-pegasus kmod-usb-net-mcs7830 \ kmod-usb-net-smsc95xx kmod-usb-net-dm9601-ether \ diff --git a/target/linux/ramips/image/mt7620.mk b/target/linux/ramips/image/mt7620.mk index 7ebab8d757..20aafc95d6 100644 --- a/target/linux/ramips/image/mt7620.mk +++ b/target/linux/ramips/image/mt7620.mk @@ -1003,7 +1003,7 @@ define Device/tplink_archer-mr200 TPLINK_HWID := 0xd751 TPLINK_HWREV := 0x4a IMAGES := sysupgrade.bin - DEVICE_PACKAGES := kmod-mt76x0e kmod-usb2 kmod-usb-net kmod-usb-net-rndis \ + DEVICE_PACKAGES := kmod-mt76x0e kmod-usb2 kmod-usb-net-rndis \ kmod-usb-serial kmod-usb-serial-option adb-enablemodem DEVICE_MODEL := Archer MR200 SUPPORTED_DEVICES += mr200 diff --git a/target/linux/ramips/image/rt305x.mk b/target/linux/ramips/image/rt305x.mk index b75d9078e5..853c145cb4 100644 --- a/target/linux/ramips/image/rt305x.mk +++ b/target/linux/ramips/image/rt305x.mk @@ -474,7 +474,7 @@ define Device/dlink_dwr-512-b DEVICE_MODEL := DWR-512 DEVICE_VARIANT := B DEVICE_PACKAGES := jboot-tools kmod-usb2 kmod-spi-dev kmod-usb-serial \ - kmod-usb-serial-option kmod-usb-net kmod-usb-net-cdc-ether comgt-ncm + kmod-usb-serial-option kmod-usb-net-cdc-ether comgt-ncm DLINK_ROM_ID := DLK6E2412001 DLINK_FAMILY_MEMBER := 0x6E24 DLINK_FIRMWARE_SI
missing email header
Hi, somehow the titles of the emails from openwrt-devel@ do not contain a title prefix anymore. They appear to address me personally at first glance, which is a bit unsettling. Is this a temporary thing? thanks, Moritz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: your mail
On Tue, Aug 04, 2020 at 08:35:26PM -0300, SAn via openwrt-devel wrote: > The sender domain has a DMARC Reject/Quarantine policy which disallows > sending mailing list messages using the original "From" header. > > To mitigate this problem, the original message has been wrapped > automatically by the mailing list software. > Date: Tue, 4 Aug 2020 20:35:26 -0300 > From: SAn > To: Daniel Golle , s@gmx.de > Cc: openwrt-devel@lists.openwrt.org > Subject: Re: your mail > > Hi Stefan and Daniel, > > On 8/2/20 8:19 PM, Daniel Golle wrote: > > On Sun, Aug 02, 2020 at 07:49:40PM -0300, SAn via openwrt-devel wrote: > >> Subject: ath79 subtarget with cmdline from bootloader > >> > >> Hi! > >> > >> The LibreRouter uses a dual-boot scheme that relies on the bootloader > >> configuring the kernel cmdline. At ar71xx 18.06 it was possible to select > >> per device if the cmdline from the bootloader has to be honored (using > >> patch-cmdline). > >> AFAIK there is no such possibility on ath79. > >> > >> Would you consider accepting a patch that adds a new ath79 subtarget with > >> CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER (or > >> CONFIG_MIPS_CMDLINE_BUILTIN_EXTEND)? > >> > >> It would be valuable for the people using LibreRouter devices to be able > >> to use official OpenWrt 20.xx images with the dual-boot support. Currently > >> there are multiple mips targets that use > >> CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER (bcm47xx, octeon, malta, and a few > >> more). > > > > I don't think this justifies an extra subtarget just for the sake of > > having the kernel process cmdline arguments passed by an outdated > > (ie. non-DT, non-FIT) bootloader. > > If it really has to be that way (and eg. parsing uboot-env cannot be > > used instead and bootloader cannot be updated to properly pass this > . > > Another bootloader can be used, but I am not aware of a newer one with > QCA955x support, do you? The last time I checked u-boot there was upstream > support to qca956x and qca953x. Adding support to 955x seemed to me a lot of > work (there are thousands of undocumented constants everywhere in the code), > but maybe I am mistaken? > > I did not understand the "parsing uboot-env". Can you expand on this please? > :) You can hack a MTD partition parser(/-splitter) which evaluates the U-Boot environment and according to what it finds there sets partition names accordingly (ie. swap firmware with firmware2, then 'firmware' will be split into 'kernel' and 'rootfs' during boot). For sysupgrade you can then always use firmware2 (ie. the currently unused image) and toggle which image to load on boot by default (eg. by using fw_setenv) How does librerouter's vendor U-Boot decide which image to boot? > > > in dtb), I guess something along the lines of > > CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_MANGLE > > could work (would have to be implemented for MIPS first, obviously) > > If there is no other viable way I would go this way.. > Thanks Stefan for the pointers to the patches! > > > Alternatively, as a quick-and-dirty workaround, just move the whole > > librerouter.dts into a .dtsi and then have two .dts files referecing > > them, each setting different cmdline. Then generate two images. > > That'd be the same effect as what patch-cmdline used to do on non-DT > > targets. > > > > I think this is too complicated for end users. Maybe a friendlier way could > be to pack both images into a tarfile and then use the correct one from a > userspace tool to perform the upgrade. How have you been managing this on ar71xx until now? > > Thanks for the help! > SAn > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH V2 uhttpd] ubus: add new RESTful API
Hi!
Am 04.08.20 um 18:40 schrieb Rafał Miłecki:
> On 04.08.2020 09:43, Andre Valentin wrote:
>> Am 03.08.20 um 07:49 schrieb Rafał Miłecki:
>>> On 31.07.2020 13:02, Andre Valentin wrote:
this is really great stuff. It would help me to get forward with my wifi
controller.
Could it be possible to subsribe to multiple sources to limit the
connections to ubus?
2 SSIDs with 2.4 ad 5GHz would me 4 concurrent channels if I understand
right.
>>>
>>> I'm happy someone finds it useful!
>>>
>>> If you mean hostapd.* objects, that's right. That would require you to
>>> use:
>>> /ubus/subscribe/hostapd.wlan0
>>> /ubus/subscribe/hostapd.wlan0-1
>>> /ubus/subscribe/hostapd.wlan1
>>> /ubus/subscribe/hostapd.wlan1-1
>>>
>>> For subscribing to multiple objects we would need to:
>>> 1. Stick to GET due to the way EventSource works
>>> 2. Pick some more generic URL
>>> 3. Adjust output format ("event" and "data" fields)
>>>
>>> So my guess would be something like:
>>>
>>> $ curl
>>> http://192.168.1.1/ubus/subscribe?path=hostapd.wlan0&path=hostapd.wlan1
>>
>> Good idea!
>>
>>> event: hostapd.wlan1 status
>>> data: {"count":5}
>>>
>>> event: hostapd.wlan0-1 status
>>> data: {"count":5}
>>>
>>> event: hostapd.wlan1 status
>>> data: {"count":7}
>>>
>>>
>>> Regarding parsing events stream, event names with spaces seem to be OK:
>>> https://html.spec.whatwg.org/multipage/server-sent-events.html#parsing-an-event-stream
>>> field value can use any scalar value other than line break char.
>>
>> Why do you need the status there, is it part of the standard?
>
> That was meant to separate object name from notification name.
>
OK, I understand.
>
>>> We should use some special character as separator of object name and
>>> notification name. It must be something that ubus doesn't use in any of
>>> them. Should space be OK? Or should we use some more fancy char? I
>>> quickly tested space and it seems to work well in Firefox and Chromium.
>>
>> Oh, I'm nut sure. But I think space is fine.
>>
>> Did you use a special uhttpd version. I couldn't apply your patch to the
>> uhttpd in openwrt master.
>
> There are few more uhttpd pending patches that I sent, see:
> https://patchwork.ozlabs.org/project/openwrt/list/?series=&submitter=5824&state=*&q=uhttpd&archive=&delegate=
Okay, will give it a try again at the weekend.
Kind regards,
André
smime.p7s
Description: S/MIME Cryptographic Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Fate of 4.14 targets / samsung odroid HC1 support
Hi! Am 04.08.20 um 22:14 schrieb Adrian Schmutzler: >> -Original Message- >> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] >> On Behalf Of Andre Valentin >> Sent: Dienstag, 4. August 2020 17:48 >> To: openwrt-devel@lists.openwrt.org >> Subject: Re: Fate of 4.14 targets / samsung odroid HC1 support >> >> Hi! >> >> I've enabled support for the odoid HC1 in the samsung target a month ago, it >> only needs generic 5.4 kernel and is a subtarget. >> https://www.hardkernel.com/shop/odroid-hc1-home-cloud-one/ >> Only open thing is the boodloader on the sdcard, which is a binary for >> hardkernel. > > Just had a look, samsung target seems to use a custom nand driver. > > Based on what I remember from other targets, I don't think this will be fun > > to upgrade from 4.14 to 5.4 ... > > And in particular, we would need somebody interested with a device to do that > ... > I don't have that device either. I would wait for deletion of the samsung target and come back again. Thanks, André smime.p7s Description: S/MIME Cryptographic Signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH uhttpd] ubus: rename JSON-RPC format related functions
From: Rafał Miłecki
Use "_json_rpc_" in their names so it's clear they are related to the
JSON-RPC format. This cleans up code a bit and will allow adding more
formats in the future.
Signed-off-by: Rafał Miłecki
---
ubus.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/ubus.c b/ubus.c
index 062e973..c22e07a 100644
--- a/ubus.c
+++ b/ubus.c
@@ -189,7 +189,7 @@ static void uh_ubus_send_response(struct client *cl)
return ops->request_done(cl);
}
-static void uh_ubus_init_response(struct client *cl)
+static void uh_ubus_init_json_rpc_response(struct client *cl)
{
struct dispatch_ubus *du = &cl->dispatch.ubus;
struct json_object *obj = du->jsobj_cur, *obj2 = NULL;
@@ -205,11 +205,11 @@ static void uh_ubus_init_response(struct client *cl)
blobmsg_add_field(&buf, BLOBMSG_TYPE_UNSPEC, "id", NULL, 0);
}
-static void uh_ubus_json_error(struct client *cl, enum rpc_error type)
+static void uh_ubus_json_rpc_error(struct client *cl, enum rpc_error type)
{
void *c;
- uh_ubus_init_response(cl);
+ uh_ubus_init_json_rpc_response(cl);
c = blobmsg_open_table(&buf, "error");
blobmsg_add_u32(&buf, "code", json_errors[type].code);
blobmsg_add_string(&buf, "message", json_errors[type].msg);
@@ -235,7 +235,7 @@ uh_ubus_request_cb(struct ubus_request *req, int ret)
int rem;
uloop_timeout_cancel(&du->timeout);
- uh_ubus_init_response(cl);
+ uh_ubus_init_json_rpc_response(cl);
r = blobmsg_open_array(&buf, "result");
blobmsg_add_u32(&buf, "", ret);
blob_for_each_attr(cur, du->buf.head, rem)
@@ -251,7 +251,7 @@ uh_ubus_timeout_cb(struct uloop_timeout *timeout)
struct client *cl = container_of(du, struct client, dispatch.ubus);
ubus_abort_request(ctx, &du->req);
- uh_ubus_json_error(cl, ERROR_TIMEOUT);
+ uh_ubus_json_rpc_error(cl, ERROR_TIMEOUT);
}
static void uh_ubus_close_fds(struct client *cl)
@@ -283,7 +283,7 @@ static void uh_ubus_request_free(struct client *cl)
static void uh_ubus_single_error(struct client *cl, enum rpc_error type)
{
uh_ubus_send_header(cl);
- uh_ubus_json_error(cl, type);
+ uh_ubus_json_rpc_error(cl, type);
ops->request_done(cl);
}
@@ -298,7 +298,7 @@ static void uh_ubus_send_request(struct client *cl, const
char *sid, struct blob
blob_buf_init(&req, 0);
blobmsg_for_each_attr(cur, args, rem) {
if (!strcmp(blobmsg_name(cur), "ubus_rpc_session"))
- return uh_ubus_json_error(cl, ERROR_PARAMS);
+ return uh_ubus_json_rpc_error(cl, ERROR_PARAMS);
blobmsg_add_blob(&req, cur);
}
@@ -308,7 +308,7 @@ static void uh_ubus_send_request(struct client *cl, const
char *sid, struct blob
memset(&du->req, 0, sizeof(du->req));
ret = ubus_invoke_async(ctx, du->obj, du->func, req.head, &du->req);
if (ret)
- return uh_ubus_json_error(cl, ERROR_INTERNAL);
+ return uh_ubus_json_rpc_error(cl, ERROR_INTERNAL);
du->req.data_cb = uh_ubus_request_data_cb;
du->req.complete_cb = uh_ubus_request_cb;
@@ -401,7 +401,7 @@ static void uh_ubus_send_list(struct client *cl, struct
blob_attr *params)
uh_client_unref(cl);
- uh_ubus_init_response(cl);
+ uh_ubus_init_json_rpc_response(cl);
blobmsg_add_blob(&buf, blob_data(data.buf->head));
uh_ubus_send_response(cl);
}
@@ -564,7 +564,7 @@ static void uh_ubus_handle_request_object(struct client
*cl, struct json_object
}
error:
- uh_ubus_json_error(cl, err);
+ uh_ubus_json_rpc_error(cl, err);
out:
if (data.params)
free(data.params);
--
2.27.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
