RE: [PATCH 2/3] rtl838x: d-link_dgs-1210: refactor common family bits
Hi Petr,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Petr Štetiar
> Sent: Mittwoch, 4. November 2020 13:11
> To: openwrt-devel@lists.openwrt.org
> Cc: Petr Štetiar
> Subject: [PATCH 2/3] rtl838x: d-link_dgs-1210: refactor common family bits
>
> So it can be easily shared with other boards in the family and while at it add
> missing SPDX license identifiers into the DTS files.
Acked-by: Adrian Schmutzler
for the patchset.
One comment on this patch below.
>
> Signed-off-by: Petr Štetiar
> ---
> .../dts/rtl8382_d-link_dgs-1210-16.dts| 81 +-
> .../rtl838x/dts/rtl8382_d-link_dgs-1210.dtsi | 84 +++
> target/linux/rtl838x/image/Makefile | 14 ++--
> 3 files changed, 94 insertions(+), 85 deletions(-) create mode 100644
> target/linux/rtl838x/dts/rtl8382_d-link_dgs-1210.dtsi
>
> diff --git a/target/linux/rtl838x/dts/rtl8382_d-link_dgs-1210-16.dts
> b/target/linux/rtl838x/dts/rtl8382_d-link_dgs-1210-16.dts
> index 3fb3cfb35346..3843af1371a7 100644
> --- a/target/linux/rtl838x/dts/rtl8382_d-link_dgs-1210-16.dts
> +++ b/target/linux/rtl838x/dts/rtl8382_d-link_dgs-1210-16.dts
> @@ -1,87 +1,10 @@
> -#include "rtl838x.dtsi"
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
>
> -#include
> -#include
> +#include "rtl8382_d-link_dgs-1210.dtsi"
>
> / {
> compatible = "d-link,dgs-1210-16", "realtek,rtl838x-soc";
> model = "D-Link DGS-1210-16";
> -
> - aliases {
> - led-boot = &led_power;
> - led-failsafe = &led_power;
> - led-running = &led_power;
> - led-upgrade = &led_power;
> - };
> -
> - chosen {
> - bootargs = "console=ttyS0,115200";
> - };
> -
> - leds {
> - compatible = "gpio-leds";
> -
> - led_power: power {
> - label = "green:power";
> - gpios = <&gpio0 24 GPIO_ACTIVE_LOW>;
> - };
> - };
> -};
> -
> -&gpio0 {
> - indirect-access-bus-id = <0>;
> -};
> -
> -&spi0 {
> - status = "okay";
> - flash@0 {
> - compatible = "jedec,spi-nor";
> - reg = <0>;
> - spi-max-frequency = <1000>;
> -
> - partitions {
> - compatible = "fixed-partitions";
> - #address-cells = <1>;
> - #size-cells = <1>;
> -
> - partition@0 {
> - label = "u-boot";
> - reg = <0x 0x8>;
> - read-only;
> - };
> - partition@8 {
> - label = "u-boot-env";
> - reg = <0x0008 0x4>;
> - read-only;
> - };
> - partition@c {
> - label = "u-boot-env2";
> - reg = <0x000c 0x4>;
> - read-only;
> - };
> - partition@28 {
> - label = "firmware";
> - compatible = "denx,uimage";
> - reg = <0x0010 0xd8>;
> - };
> - partition@be8 {
> - label = "kernel2";
> - reg = <0x00e8 0x18>;
> - };
> - partition@100 {
> - label = "sysinfo";
> - reg = <0x0100 0x4>;
> - };
> - partition@104 {
> - label = "rootfs2";
> - reg = <0x0104 0xc0>;
> - };
> - partition@1c4 {
> - label = "jffs2";
> - reg = <0x01c4 0x3c>;
> - };
> - };
> - };
> };
>
> ðernet0 {
> diff --git a/target/linux/rtl838x/dts/rtl8382_d-link_dgs-1210.dtsi
> b/target/linux/rtl838x/dts/rtl8382_d-link_dgs-1210.dtsi
> new file mode 100644
> index 000
RE: [PATCH 2/5] ramips: mt7621: drop custom uImage function
Hi Sander, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Sander Vanheule > Sent: Mittwoch, 4. November 2020 10:21 > To: openwrt-devel@lists.openwrt.org > Cc: Sander Vanheule > Subject: [PATCH 2/5] ramips: mt7621: drop custom uImage function > > Use the mkimage argument overrides provided by uImage to implement the > customisations required for the initramfs, instead of the near-identical > custom function. > > Signed-off-by: Sander Vanheule > --- > Build tested for iodata_wn1167gr2, where > uImage lzma -M 0x434f4d42 -n '3.10(XBC.1)b10' > > ... results in the following call made to mkimage: > mkimage -A mips -O linux -T kernel -C lzma -a 0x80001000 > -e 0x80001000 -n 'MIPS OpenWrt Linux-5.4.74' -M 0x434f4d42 > -n '3.10(XBC.1)b10' -d initramfs-kernel.bin initramfs-kernel.bin.new And you are perfectly sure that there is no harm from specifying -n twice? Apart from that, the question is whether we should rely on such behavior? (As much as I would like to have the redundancy gone, too). Best Adrian > > target/linux/ramips/image/mt7621.mk | 31 ++--- > 1 file changed, 10 insertions(+), 21 deletions(-) > > diff --git a/target/linux/ramips/image/mt7621.mk > b/target/linux/ramips/image/mt7621.mk > index bb7e5a0d48..9b6c7d2311 100644 > --- a/target/linux/ramips/image/mt7621.mk > +++ b/target/linux/ramips/image/mt7621.mk > @@ -7,21 +7,7 @@ include ./common-tp-link.mk DEFAULT_SOC := mt7621 > > KERNEL_DTB += -d21 > -DEVICE_VARS += UIMAGE_MAGIC ELECOM_HWNAME LINKSYS_HWNAME > - > -# The OEM webinterface expects an kernel with initramfs which has the > uImage -# header field ih_name. > -# We don't want to set the header name field for the kernel include in the - > # sysupgrade image as well, as this image shouldn't be accepted by the OEM > -# webinterface. It will soft-brick the board. > -define Build/custom-initramfs-uimage > - mkimage -A $(LINUX_KARCH) \ > - -O linux -T kernel \ > - -C lzma -a $(KERNEL_LOADADDR) $(if $(UIMAGE_MAGIC),-M > $(UIMAGE_MAGIC),) \ > - -e $(if > $(KERNEL_ENTRY),$(KERNEL_ENTRY),$(KERNEL_LOADADDR)) \ > - -n '$(1)' -d $@ $@.new > - mv $@.new $@ > -endef > +DEVICE_VARS += ELECOM_HWNAME LINKSYS_HWNAME > > define Build/elecom-wrc-gs-factory > $(eval product=$(word 1,$(1))) > @@ -531,32 +517,35 @@ define Device/iodata_nand >IMAGE/sysupgrade.bin := sysupgrade-tar | append-metadata endef > > +# The OEM webinterface expects an kernel with initramfs which has the > +uImage # header field ih_name. > +# We don't want to set the header name field for the kernel include in > +the # sysupgrade image as well, as this image shouldn't be accepted by > +the OEM # webinterface. It will soft-brick the board. > + > define Device/iodata_wn-ax1167gr2 >$(Device/iodata_nand) > - UIMAGE_MAGIC := 0x434f4d42 >DEVICE_MODEL := WN-AX1167GR2 >KERNEL_INITRAMFS := $(KERNEL_DTB) | loader-kernel | lzma | \ > - custom-initramfs-uimage 3.10(XBC.1)b10 | iodata-mstc-header > + uImage lzma -M 0x434f4d42 -n '3.10(XBC.1)b10' | iodata-mstc-header >DEVICE_PACKAGES := kmod-mt7615e kmod-mt7615-firmware endef > TARGET_DEVICES += iodata_wn-ax1167gr2 > > define Device/iodata_wn-ax2033gr >$(Device/iodata_nand) > - UIMAGE_MAGIC := 0x434f4d42 >DEVICE_MODEL := WN-AX2033GR >KERNEL_INITRAMFS := $(KERNEL_DTB) | loader-kernel | lzma | \ > - custom-initramfs-uimage 3.10(VST.1)C10 | iodata-mstc-header > + uImage lzma -M 0x434f4d42 -n '3.10(VST.1)C10' | iodata-mstc-header >DEVICE_PACKAGES := kmod-mt7603 kmod-mt7615e kmod-mt7615- > firmware endef TARGET_DEVICES += iodata_wn-ax2033gr > > define Device/iodata_wn-dx1167r >$(Device/iodata_nand) > - UIMAGE_MAGIC := 0x434f4d43 >DEVICE_MODEL := WN-DX1167R >KERNEL_INITRAMFS := $(KERNEL_DTB) | loader-kernel | lzma | \ > - custom-initramfs-uimage 3.10(XIK.1)b10 | iodata-mstc-header > + uImage lzma -M 0x434f4d43 -n '3.10(XIK.1)b10' | iodata-mstc-header >DEVICE_PACKAGES := kmod-mt7615e kmod-mt7615-firmware endef > TARGET_DEVICES += iodata_wn-dx1167r > -- > 2.28.0 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH v2 04/10] base-files: upgrade: fwtool.sh: use v for log lines
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Yousong Zhou
> Sent: Dienstag, 10. November 2020 03:22
> To: Adrian Schmutzler ; Philip Prindeville
>
> Cc: Yousong Zhou ; OpenWrt Development List
>
> Subject: [PATCH v2 04/10] base-files: upgrade: fwtool.sh: use v for log lines
>
> This will have at least the following effects
>
> - Log lines will have common prefix
> - They will be output to stderr instead of stdout
>
> Signed-off-by: Yousong Zhou
> ---
> .../base-files/files/lib/upgrade/fwtool.sh| 24 +--
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/package/base-files/files/lib/upgrade/fwtool.sh b/package/base-
> files/files/lib/upgrade/fwtool.sh
> index 3a74c72bba..d30b37c4f0 100644
> --- a/package/base-files/files/lib/upgrade/fwtool.sh
> +++ b/package/base-files/files/lib/upgrade/fwtool.sh
> @@ -10,9 +10,9 @@ fwtool_check_signature() {
> }
>
> if ! fwtool -q -s /tmp/sysupgrade.ucert "$1"; then
> - echo "Image signature not found"
> + v "Image signature not found"
> [ "$REQUIRE_IMAGE_SIGNATURE" = 1 -a "$FORCE" != 1 ] && {
> - echo "Use sysupgrade -F to override this check when
> downgrading or flashing to vendor firmware"
> + v "Use sysupgrade -F to override this check when
> downgrading or flashing to vendor firmware"
> }
> [ "$REQUIRE_IMAGE_SIGNATURE" = 1 ] && return 1
> return 0
> @@ -30,16 +30,16 @@ fwtool_check_image() {
> . /usr/share/libubox/jshn.sh
>
> if ! fwtool -q -i /tmp/sysupgrade.meta "$1"; then
> - echo "Image metadata not found"
> + v "Image metadata not found"
> [ "$REQUIRE_IMAGE_METADATA" = 1 -a "$FORCE" != 1 ] && {
> - echo "Use sysupgrade -F to override this check when
> downgrading or flashing to vendor firmware"
> + v "Use sysupgrade -F to override this check when
> downgrading or flashing to vendor firmware"
> }
> [ "$REQUIRE_IMAGE_METADATA" = 1 ] && return 1
> return 0
> fi
>
> json_load "$(cat /tmp/sysupgrade.meta)" || {
> - echo "Invalid image metadata"
> + v "Invalid image metadata"
> return 1
> }
>
> @@ -64,15 +64,15 @@ fwtool_check_image() {
> if [ "$dev" = "$device" ]; then
> # major compat version -> no sysupgrade
> if [ "${devicecompat%.*}" != "${imagecompat%.*}" ];
> then
> - echo "The device is supported, but this image
> is incompatible for sysupgrade based on the image version ($devicecompat-
> >$imagecompat)."
> - [ -n "$compatmessage" ] && echo
> "$compatmessage"
> + v "The device is supported, but this image is
> incompatible for sysupgrade based on the image version ($devicecompat-
> >$imagecompat)."
> + [ -n "$compatmessage" ] && v
> "$compatmessage"
> return 1
> fi
>
> # minor compat version -> sysupgrade with -n
> required
> if [ "${devicecompat#.*}" != "${imagecompat#.*}" ]
> && [ "$SAVE_CONFIG" = "1" ]; then
> - echo "The device is supported, but the config
> is incompatible to the new image ($devicecompat->$imagecompat). Please
> upgrade without keeping config (sysupgrade -n)."
> - [ -n "$compatmessage" ] && echo
> "$compatmessage"
> + v "The device is supported, but the config is
> incompatible to the new image ($devicecompat->$imagecompat). Please
> upgrade without keeping config (sysupgrade -n)."
> + [ -n "$compatmessage" ] && v
> "$compatmessage"
> return 1
> fi
>
> @@ -80,11 +80,11 @@ fwtool_check_image() {
> fi
> done
>
> - echo "Device $device not supported by this image"
> -
RE: [PATCH v2 10/10] x86: upgrade: make code comment appear as log lines
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Yousong Zhou
> Sent: Dienstag, 10. November 2020 03:22
> To: Adrian Schmutzler ; Philip Prindeville
>
> Cc: Yousong Zhou ; OpenWrt Development List
>
> Subject: [PATCH v2 10/10] x86: upgrade: make code comment appear as log
> lines
>
> This is mainly to make it clear records in/out in the following lines are for
> extracting boot sectors
>
> Before
>
> == upgrade: Reading partition table from bootdisk...
> 37+26 records in
> 37+26 records out
> == upgrade: Reading partition table from image...
>
> After
>
> == upgrade: Reading partition table from bootdisk...
> == upgrade: Extract boot sector from the image
> 37+26 records in
> 37+26 records out
> == upgrade: Reading partition table from image...
technically, the commit message would need to be updated from "==" to date.
However, having seen the updated output I'm not so sure anymore whether date
really makes it nicer.
For this patch it's just a nitpick, though, I'm sure everybody will understand
without changing the message as well.
Best
Adrian
>
> Signed-off-by: Yousong Zhou
> ---
> target/linux/x86/base-files/lib/upgrade/platform.sh | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/target/linux/x86/base-files/lib/upgrade/platform.sh
> b/target/linux/x86/base-files/lib/upgrade/platform.sh
> index 0b54caea29..d8f2eba97e 100644
> --- a/target/linux/x86/base-files/lib/upgrade/platform.sh
> +++ b/target/linux/x86/base-files/lib/upgrade/platform.sh
> @@ -19,7 +19,7 @@ platform_check_image() {
>
> get_partitions "/dev/$diskdev" bootdisk
>
> - #extract the boot sector from the image
> + v "Extract boot sector from the image"
> get_image_dd "$1" of=/tmp/image.bs count=63 bs=512b
>
> get_partitions /tmp/image.bs image
> @@ -82,7 +82,7 @@ platform_do_upgrade() {
> if [ "$UPGRADE_OPT_SAVE_PARTITIONS" = "1" ]; then
> get_partitions "/dev/$diskdev" bootdisk
>
> - #extract the boot sector from the image
> + v "Extract boot sector from the image"
> get_image_dd "$1" of=/tmp/image.bs count=63 bs=512b
>
> get_partitions /tmp/image.bs image
> @@ -114,7 +114,6 @@ platform_do_upgrade() {
> fi
> done < /tmp/partmap.image
>
> - #copy partition uuid
> v "Writing new UUID to /dev/$diskdev..."
> get_image_dd "$1" of="/dev/$diskdev" bs=1 skip=440 count=4
> seek=440 conv=fsync
>
> @@ -129,5 +128,4 @@ platform_do_upgrade() {
> sed -i "s/\(PARTUUID=\)[a-f0-9-]\+/\1$4$3$2$1-$6$5-$8$7-
> $9/ig" /mnt/boot/grub/grub.cfg
> umount /mnt
> fi
> -
> }
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH v2 00/10] sysupgrade: reword and organize log lines
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Yousong Zhou > Sent: Dienstag, 10. November 2020 03:22 > To: Adrian Schmutzler ; Philip Prindeville > > Cc: Yousong Zhou ; OpenWrt Development List > > Subject: [PATCH v2 00/10] sysupgrade: reword and organize log lines > > The series mainly aims to make sysupgrade log output more organized and > less disturbing, in the following aspects > > - Hide "write error: Broken pipe" from cat command and its friends > - Hide "F+P records in/out" lines from dd command > - Make log lines from sysupgrade command itself more distinguishable >than other commands by using common.sh function "v" Thanks, this patchset should be an improvement to the process. I'm still unsure what's the best variant for the output prefix (having seen the "date variant", the "==" actually seems more pronounced to me). However, since we can change this by altering one line now, I would just ignore that matter and not delay the patchset due to that question. Note my separate comments on two individual patches. Thanks Adrian > > The series should at least partially address concerns raised at FS#3140 > > Ref: https://bugs.openwrt.org/index.php?do=details&task_id=3140 > > v2 <- v1 > > - Make date command available in ramdisk and prefix log lines with datetime > - Hide "F+P records in/out" stderr output from dd command > > Sysupgrade stdio dumps attached below for comparison > > v2 > > Tue Nov 10 02:04:04 UTC 2020 upgrade: Image metadata not present > Tue Nov 10 02:04:04 UTC 2020 upgrade: Reading partition table from > bootdisk... > Tue Nov 10 02:04:04 UTC 2020 upgrade: Extract boot sector from the image > Tue Nov 10 02:04:05 UTC 2020 upgrade: Reading partition table from image... > Tue Nov 10 02:04:05 UTC 2020 upgrade: Commencing upgrade. Closing all > shell sessions. > killall: telnetd: no process killed > Sending TERM to remaining processes ... ubusd askfirst urngd logd netifd > odhcpd xl2tpd ntpd dnsmasq > Sending KILL to remaining processes ... > Tue Nov 10 02:04:09 UTC 2020 upgrade: Switching to ramdisk... > [ 25.995408] EXT4-fs (vda2): re-mounted. Opts: (null) > Tue Nov 10 02:04:09 UTC 2020 upgrade: Performing system upgrade... > Tue Nov 10 02:04:09 UTC 2020 upgrade: Reading partition table from > bootdisk... > Tue Nov 10 02:04:10 UTC 2020 upgrade: Extract boot sector from the image > Tue Nov 10 02:04:10 UTC 2020 upgrade: Reading partition table from image... > Tue Nov 10 02:04:10 UTC 2020 upgrade: Writing image to /dev/vda1... > Tue Nov 10 02:04:11 UTC 2020 upgrade: Writing image to /dev/vda2... > Tue Nov 10 02:04:15 UTC 2020 upgrade: Writing new UUID to /dev/vda... > [ 31.582751] F2FS-fs (vda1): Magic Mismatch, valid(0xf2f52010) - read(0x0) > [ 31.598842] F2FS-fs (vda1): Can't find valid F2FS filesystem in 1th > superblock > [ 31.613440] F2FS-fs (vda1): Magic Mismatch, valid(0xf2f52010) - > read(0x6020601) > [ 31.623241] F2FS-fs (vda1): Can't find valid F2FS filesystem in 2th > superblock > Tue Nov 10 02:04:15 UTC 2020 upgrade: Upgrading bootloader on > /dev/vda... > Tue Nov 10 02:04:22 UTC 2020 upgrade: Upgrade completed > Tue Nov 10 02:04:23 UTC 2020 upgrade: Rebooting system... > umount: can't unmount /dev: Resource busy > umount: can't unmount /tmp: Resource busy > [ 39.168155] Unregister pv shared memory for cpu 0 > [ 39.177657] reboot: Restarting system > [ 39.183596] reboot: machine restart > > v1 > > root@OpenWrt:/# sysupgrade -n -v /tmp/x86.gz > == upgrade: Image metadata not present > == upgrade: Reading partition table from bootdisk... > == upgrade: Extract boot sector from the image > 54+9 records in > 54+9 records out > == upgrade: Reading partition table from image... > == upgrade: Commencing upgrade. Closing all shell sessions. > killall: telnetd: no process killed > Sending TERM to remaining processes ... ubusd askfirst urngd logd netifd > odhcpd xl2tpd ntpd dnsmasq > Sending KILL to remaining processes ... > == upgrade: Switching to ramdisk... > == upgrade: Performing system upgrade... > == upgrade: Reading partition table from bootdisk... > == upgrade: Extract boot sector from the image > 0+63 records in > 0+63 records out > == upgrade: Reading partition table from image... > == upgrade: Writing image to /dev/vda1... > 65535+0 records in > 31+1 records out > == upgrade: Writing image to /dev/vda2... > 262143+0 records in > 127+1 records out > == upgrade: Writing new UUI
RE: Upcoming 19.07.4 and 18.07.9 stable releases
> I would wait for the build bot results and then do it at the weekend. > > Should we also do an other 19.07 release now? "ath79: ar8216: make switch register access atomic" could be a big deal for ath79 users, and several ramips users might be happy about "Revert "ramips: ethernet: fix to interrupt handling". We should at least consider it. (But we probably should bump the kernel again if we do.) Best Adrian > > Hauke openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: Upcoming 19.07.4 and 18.07.9 stable releases
> -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Baptiste Jonglez > Sent: Mittwoch, 11. November 2020 13:15 > To: Hauke Mehrtens > Cc: openwrt-devel@lists.openwrt.org; Thomas Endt > Subject: Re: Upcoming 19.07.4 and 18.07.9 stable releases > > On 11-11-20, Hauke Mehrtens wrote: > > Hi, > > > > Currently 18.06 looks good for me and I would really like to do the > > final release and call it then officially end of life. > > > > I would wait for the build bot results and then do it at the weekend. > > Yes, I fully agree, it's ready. > > Looking at buildbot, only layerscape/armv8_64b fails to build, but it seems to > have been broken for a long time. Had a quick look, might be solvable with a small patch refresh (manually). Will report back. Adrian > > I have updated the release notes at > https://openwrt.org/releases/18.06/notes-18.06.9 > > > Should we also do an other 19.07 release now? > > I agree with Adrian, this ath79 switch driver issue was a long-standing issue > and it's very good news that it's fixed. > > However, there were 3 regressions identified in 19.07.4, one has been fixed > but two of them are still there: > > https://openwrt.org/releases/19.07/notes-19.07.4#regressions > > For the VLAN tagging issue, I think the offending commit needs to be > reverted. > > For the ramips stability issue (frequent device reboot on several different > models), does anybody have an idea? Maybe a kernel issue? > Or could it be the same issue as FS#3332 that could cause crashes? > > Thanks, > Baptiste openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH 2/2] mvebu: LS421DE: improve the HDD leds
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Daniel González Cabanelas
> Sent: Mittwoch, 11. November 2020 23:25
> To: openwrt-devel@lists.openwrt.org
> Subject: [PATCH 2/2] mvebu: LS421DE: improve the HDD leds
>
> Improve the HDD LEDs used for disk activity:
> - Use the labels of the casing for better identification
> - Use the trigger activity per ata channel
I'd rather not change the LED label for a weak cosmetic reason like this.
If you insist, please add a migration script in case somebody defined a custom
trigger, similar to
https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/generic/base-files/etc/uci-defaults/04_led_migration
Best
Adrian
>
> Signed-off-by: Daniel González Cabanelas
> ---
> .../arch/arm/boot/dts/armada-370-buffalo-ls421de.dts | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/target/linux/mvebu/files/arch/arm/boot/dts/armada-370-
> buffalo-ls421de.dts b/target/linux/mvebu/files/arch/arm/boot/dts/armada-
> 370-buffalo-ls421de.dts
> index 7e070f49dc..d05f290b9d 100644
> --- a/target/linux/mvebu/files/arch/arm/boot/dts/armada-370-buffalo-
> ls421de.dts
> +++ b/target/linux/mvebu/files/arch/arm/boot/dts/armada-370-buffalo-
> ls421de.dts
> @@ -149,18 +149,18 @@
> gpios = <&gpio1 27 GPIO_ACTIVE_HIGH>;
> };
>
> - hdd1_red {
> - label = "ls421de:red:hdd1";
> + disk1_red {
> + label = "ls421de:red:disk1";
> gpios = <&gpio1 29 GPIO_ACTIVE_HIGH>;
> default-state = "off";
> - linux,default-trigger = "disk-activity";
> + linux,default-trigger = "ata1";
> };
>
> - hdd2_red {
> - label = "ls421de:red:hdd2";
> + disk2_red {
> + label = "ls421de:red:disk2";
> gpios = <&gpio1 30 GPIO_ACTIVE_HIGH>;
> default-state = "off";
> - linux,default-trigger = "disk-activity";
> + linux,default-trigger = "ata2";
> };
> };
>
> --
> 2.29.2
>
>
>
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH] Adds support for Comfast CF-E538AC
Hi Sven,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Sven Danner
> Sent: Mittwoch, 11. November 2020 06:05
> To: j...@phrozen.org
> Cc: openwrt-devel@lists.openwrt.org
> Subject: [PATCH] Adds support for Comfast CF-E538AC
>
> Comfast CF-E538AC is an wall mounted access point with an
> additional Ethernet LAN access port. It supports
> 802.11AC Wave2 MU-MIMO
>
> Serial port access for debricking requires simple soldering of 4 pins.
this is based on an outdated version of OpenWrt, please submit the patch based
on current master.
A few additional comments above.
>
> Device specifications:
> * SoC: MT7620DA @ 580MHz
> * RAM: 64MiB DDR2
> * Flash: 8iB SPI
> * Wireless 2.4GHz (SoC): b/g/n
> * Wireless 5Ghz (MT7612E): n/ac, 2x2 MU-MINO
> * Ethernet (RTL8211F): 1× 1GbE, 802.3af PoE
> * Ethernet (RTL8211F): 1× 1GbE
>
> Flashing instructions:
> * Upgrade using web interface
>
> Debricking:
> * Serial port can be soldered on top PCB (marked as 1)
> (1: VCC, 2: GND, 3: TX, 4: RX)
> * Use 3.3V, 115200 baud, 8n1
> * Recovery only possible via TFTP
> * Modified U-Boot environment does not allow recovery via serial
> (will not commit it to flash)
> * Bootloader will show a menu for 1 seconds
> * Select 2: Load system code then write to Flash via TFTP.
> ---
> .../ramips/base-files/etc/board.d/01_leds | 3 +
> .../ramips/base-files/etc/board.d/02_network | 9 +
> target/linux/ramips/base-files/lib/ramips.sh | 3 +
> target/linux/ramips/dts/CF-E538AC.dts | 161 ++
> target/linux/ramips/image/mt7620.mk | 7 +
> 5 files changed, 183 insertions(+)
> create mode 100644 target/linux/ramips/dts/CF-E538AC.dts
>
> diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds
> b/target/linux/ramips/base-files/etc/board.d/01_leds
> index 5c005db0c1..16c012d827 100755
> --- a/target/linux/ramips/base-files/etc/board.d/01_leds
> +++ b/target/linux/ramips/base-files/etc/board.d/01_leds
> @@ -88,6 +88,9 @@ c50)
> ucidef_set_led_switch "lan" "lan" "$boardname:green:lan" "switch0"
> "0x1e"
> ucidef_set_led_switch "wan" "wan" "$boardname:green:wan"
> "switch0" "0x01"
> ;;
> +cf-e538ac)
> + set_wifi_led "$boardname:white:wifi"
Use DT trigger instead.
> + ;;
> cf-wr800n)
> ucidef_set_led_netdev "lan" "lan" "$boardname:white:ethernet"
> eth0.1
> set_wifi_led "$boardname:white:wifi"
> diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
> b/target/linux/ramips/base-files/etc/board.d/02_network
> index 8ca1831afe..637a4fd6a1 100755
> --- a/target/linux/ramips/base-files/etc/board.d/02_network
> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
> @@ -310,6 +310,11 @@ ramips_setup_interfaces()
> ucidef_add_switch "switch0" \
> "4:lan" "6t@eth0"
> ;;
> + cf-e538ac)
> + ucidef_set_interfaces_lan_wan "eth0.1" "eth0.2"
This can be dropped, ucidef_add_switch will do that automatically.
> + ucidef_add_switch "switch0" \
> + "4:wan" "5:lan" "6@eth0"
> + ;;
> cudy,wr1000)
> ucidef_add_switch "switch0" \
> "2:lan:2" "3:lan:1" "4:wan" "6@eth0"
> @@ -548,6 +553,10 @@ ramips_setup_macs()
> lan_mac=$(cat /sys/class/net/eth0/address)
> wan_mac=$(mtd_get_mac_binary devdata 7)
> ;;
> + cf-e538ac)
> + lan_mac=$(mtd_get_mac_binary factory 57344)
This can be done with mtd_mac_address in DTS.
> + wan_mac=$(macaddr_add "$lan_mac" 1)
No additional address on flash (0xe006, 0x28, 0x2e)?
What's the MAC address assignment on stock FW?
> + ;;
> cy-swr1100|\
> dir-645)
> lan_mac=$(mtd_get_mac_ascii nvram lanmac) diff --git
> a/target/linux/ramips/base-files/lib/ramips.sh b/target/linux/ramips/base-
> files/lib/ramips.sh
> index 093303892c..5e9b8fdb09 100755
> --- a/target/linux/ramips/base-files/lib/ramips.sh
> +++ b/target/linux/ramips/base-files/lib/ramips.sh
> @@ -97,6 +97,9 @@ ramips_board_detect() {
> *"CF-WR800N")
> name="cf-wr800n"
> ;;
> + *"CF-E538AC")
> + name="cf-e538ac"
> + ;;
> *"CS-QR10")
> name="cs-qr10"
> ;;
> diff --git a/target/linux/ramips/dts/CF-E538AC.dts
> b/target/linux/ramips/dts/CF-E538AC.dts
> new file mode 100644
> index 00..9a2504203b
> --- /dev/null
> +++ b/target/linux/ramips/dts/CF-E538AC.dts
> @@ -0,0 +1,161 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT /dts-v1/;
> +
> +#include "mt7620a.dtsi"
> +
> +#include
> +#include
> +
> +/ {
> + compatible = "comfast,cf-e538ac", "ralink,mt7620n-soc";
> + model = "Comfast CF-E538AC";
> +
> + aliases {
> + led
RE: [PATCH 2/2] mvebu: LS421DE: improve the HDD leds
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Daniel González Cabanelas
> Sent: Donnerstag, 12. November 2020 00:20
> To: Adrian Schmutzler
> Cc: openwrt-devel@lists.openwrt.org
> Subject: Re: [PATCH 2/2] mvebu: LS421DE: improve the HDD leds
>
> Hi Adrian,
>
> El mié., 11 nov. 2020 a las 23:50, Adrian Schmutzler
> () escribió:
> >
> > Hi,
> >
> > > -Original Message-
> > > From: openwrt-devel [mailto:openwrt-devel-
> boun...@lists.openwrt.org]
> > > On Behalf Of Daniel González Cabanelas
> > > Sent: Mittwoch, 11. November 2020 23:25
> > > To: openwrt-devel@lists.openwrt.org
> > > Subject: [PATCH 2/2] mvebu: LS421DE: improve the HDD leds
> > >
> > > Improve the HDD LEDs used for disk activity:
> > > - Use the labels of the casing for better identification
> > > - Use the trigger activity per ata channel
> >
> > I'd rather not change the LED label for a weak cosmetic reason like this.
> >
> Ok, discard the patch.
I was referring to the labels, you may still change the triggers ...
Best
Adrian
>
> Regards
>
> > If you insist, please add a migration script in case somebody defined
> > a custom trigger, similar to
> >
> https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/gen
> e
> > ric/base-files/etc/uci-defaults/04_led_migration
> >
> > Best
> >
> > Adrian
> >
> > >
> > > Signed-off-by: Daniel González Cabanelas
> > > ---
> > > .../arch/arm/boot/dts/armada-370-buffalo-ls421de.dts | 12
> > > ++--
> > > 1 file changed, 6 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/target/linux/mvebu/files/arch/arm/boot/dts/armada-370-
> > > buffalo-ls421de.dts
> > > b/target/linux/mvebu/files/arch/arm/boot/dts/armada-
> > > 370-buffalo-ls421de.dts
> > > index 7e070f49dc..d05f290b9d 100644
> > > --- a/target/linux/mvebu/files/arch/arm/boot/dts/armada-370-buffalo-
> > > ls421de.dts
> > > +++ b/target/linux/mvebu/files/arch/arm/boot/dts/armada-370-buffalo-
> > > ls421de.dts
> > > @@ -149,18 +149,18 @@
> > > gpios = <&gpio1 27 GPIO_ACTIVE_HIGH>;
> > > };
> > >
> > > - hdd1_red {
> > > - label = "ls421de:red:hdd1";
> > > + disk1_red {
> > > + label = "ls421de:red:disk1";
> > > gpios = <&gpio1 29 GPIO_ACTIVE_HIGH>;
> > > default-state = "off";
> > > - linux,default-trigger = "disk-activity";
> > > + linux,default-trigger = "ata1";
> > > };
> > >
> > > - hdd2_red {
> > > - label = "ls421de:red:hdd2";
> > > + disk2_red {
> > > + label = "ls421de:red:disk2";
> > > gpios = <&gpio1 30 GPIO_ACTIVE_HIGH>;
> > > default-state = "off";
> > > - linux,default-trigger = "disk-activity";
> > > + linux,default-trigger = "ata2";
> > > };
> > > };
> > >
> > > --
> > > 2.29.2
> > >
> > >
> > >
> > >
> > >
> > > ___
> > > 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
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH 1016/1016] Fix Netgear D7800 eth0 WAN Port not working with 100Mbit
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of pe...@cardoe.co.uk
> Sent: Dienstag, 3. November 2020 20:30
> To: openwrt-devel@lists.openwrt.org
> Cc: Peter Cardoe
> Subject: [PATCH 1016/1016] Fix Netgear D7800 eth0 WAN Port not working
> with 100Mbit
>
> From: Peter Cardoe
>
> Signed-off-by: Peter Cardoe
> ---
> .../ipq806x/files-4.14/arch/arm/boot/dts/qcom-ipq8064-d7800.dts | 6
This is based on an outdated version of OpenWrt. Please send a patch based on
recent master, add a proper description to the commit message, and update the
commit title to correspond to our guidelines:
https://openwrt.org/submitting-patches
Thanks!
Adrian
> +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/target/linux/ipq806x/files-4.14/arch/arm/boot/dts/qcom-ipq8064-
> d7800.dts b/target/linux/ipq806x/files-4.14/arch/arm/boot/dts/qcom-
> ipq8064-d7800.dts
> index 1760b19..d96f062 100644
> --- a/target/linux/ipq806x/files-4.14/arch/arm/boot/dts/qcom-ipq8064-
> d7800.dts
> +++ b/target/linux/ipq806x/files-4.14/arch/arm/boot/dts/qcom-ipq8064-
> d7800.dts
> @@ -303,13 +303,17 @@
> gmac1: ethernet@3720 {
> status = "ok";
> phy-mode = "rgmii";
> - phy-handle = <&phy4>;
> qcom,id = <1>;
>
> pinctrl-0 = <&rgmii2_pins>;
> pinctrl-names = "default";
>
> mtd-mac-address = <&art 6>;
> +
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> };
>
> gmac2: ethernet@3740 {
> --
> 1.9.1
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH 19.07] kernel: Update kernel 4.14 to version 4.14.206
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Josef Schlehofer
> Sent: Freitag, 13. November 2020 09:33
> To: openwrt-devel@lists.openwrt.org
> Cc: Hauke Mehrtens
> Subject: [PATCH 19.07] kernel: Update kernel 4.14 to version 4.14.206
>
> From: Hauke Mehrtens
>
> This is a security update as currently in OpenWrt 19.07, there is version
> 4.14.202 it means that it is vulnerable against vulnerability known as Sad DNS
> (DNS cache poisoning). Since kernel 4.14.203, there is present mitigation to
> this attack by randomizing ICMP global rate limit.
>
> More details can be found here: https://www.saddns.net/
>
> Compile and runtime tested on x86/64.
> Also compile and run tested on all Turris devices (Turris 1.x - powerpc 8540,
> Turris Omnia - mvebu/cortex-a9_vfpv3-d16, Turris MOX -
> mvebu/aarch64_cortex-a53)
>
> Signed-off-by: Hauke Mehrtens (cherry picked from
> commit 9cdc02be88d5c25791664b1baaf9a7c1a4382c95)
> Signed-off-by: Josef Schlehofer [added
> commit message about run testing on Turris devices, added mention about
> Sad DNS]
Did you just pick the patch or properly refresh patches again?
Best
Adrian
> ---
> include/kernel-version.mk | 4 ++--
> target/linux/cns3xxx/patches-4.14/210-dwc2_defaults.patch | 2 +-
> ...030-USB-serial-option-fix-dwm-158-3g-modem-interface.patch | 2 +-
> target/linux/generic/hack-4.14/204-module_strip.patch | 2 +-
> target/linux/generic/hack-4.14/930-crashlog.patch | 2 +-
> .../generic/pending-4.14/203-kallsyms_uncompressed.patch | 2 +-
> target/linux/generic/pending-4.14/920-mangle_bootargs.patch | 2 +-
> .../0067-generic-Mangle-bootloader-s-kernel-arguments.patch | 2 +-
> target/linux/mediatek/patches-4.14/0064-dts.patch | 2 +-
> ...arm64-mediatek-cleanup-message-for-platform-selectio.patch | 2 +-
> .../006-mvebu-Mangle-bootloader-s-kernel-arguments.patch | 2 +-
> .../linux/mvebu/patches-4.14/411-sfp-add-sfp-compatible.patch | 2 +-
> ...arm64-dts-armada-3720-espressobin-set-max-link-to-ge.patch | 2 +-
> .../octeon/patches-4.14/110-er200-ethernet_probe_order.patch | 4 ++--
> .../996-generic-Mangle-bootloader-s-kernel-arguments.patch| 2 +-
> 15 files changed, 17 insertions(+), 17 deletions(-)
>
> diff --git a/include/kernel-version.mk b/include/kernel-version.mk index
> a58b17fbf4..e581897dc1 100644
> --- a/include/kernel-version.mk
> +++ b/include/kernel-version.mk
> @@ -6,9 +6,9 @@ ifdef CONFIG_TESTING_KERNEL
>KERNEL_PATCHVER:=$(KERNEL_TESTING_PATCHVER)
> endif
>
> -LINUX_VERSION-4.14 = .202
> +LINUX_VERSION-4.14 = .206
>
> -LINUX_KERNEL_HASH-4.14.202 =
> 95c717ab5b0bdd2333e829f0507385fbe3424ceee810727f3a8551a0c74be328
> +LINUX_KERNEL_HASH-4.14.206 =
> +1c233efaa5063983293a02d4692acc9ced9c03e18857364855d4f612347086ac
>
> remove_uri_prefix=$(subst git://,,$(subst http://,,$(subst https://,,$(1
> sanitize_uri=$(call qstrip,$(subst @,_,$(subst :,_,$(subst .,_,$(subst -
> ,_,$(subst /,_,$(1))) diff --git a/target/linux/cns3xxx/patches-4.14/210-
> dwc2_defaults.patch b/target/linux/cns3xxx/patches-4.14/210-
> dwc2_defaults.patch
> index 67f152f43d..0cc4dd1830 100644
> --- a/target/linux/cns3xxx/patches-4.14/210-dwc2_defaults.patch
> +++ b/target/linux/cns3xxx/patches-4.14/210-dwc2_defaults.patch
> @@ -43,7 +43,7 @@
> {
> +/*
> const struct of_device_id *match;
> - void (*set_params)(void *data);
> + void (*set_params)(struct dwc2_hsotg *data);
> +*/
>
> dwc2_set_default_params(hsotg);
> diff --git a/target/linux/generic/backport-4.14/030-USB-serial-option-fix-
> dwm-158-3g-modem-interface.patch b/target/linux/generic/backport-
> 4.14/030-USB-serial-option-fix-dwm-158-3g-modem-interface.patch
> index ebd90a8ef2..4ad22b3de1 100644
> --- a/target/linux/generic/backport-4.14/030-USB-serial-option-fix-dwm-158-
> 3g-modem-interface.patch
> +++ b/target/linux/generic/backport-4.14/030-USB-serial-option-fix-dwm-1
> +++ 58-3g-modem-interface.patch
> @@ -30,7 +30,7 @@ Signed-off-by: Johan Hovold
>
> --- a/drivers/usb/serial/option.c
> +++ b/drivers/usb/serial/option.c
> -@@ -2001,7 +2001,8 @@ static const struct usb_device_id option
> +@@ -2011,7 +2011,8 @@ static const struct usb_device_id option
> { USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d01, 0xff) },
> /* D-Link DWM-156 (variant) */
> { USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d02, 0xff) },
> { USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d03, 0xff) }, diff --git
> a/target/linux/generic/hack-4.14/204-module_strip.patch
> b/target/linux/generic/hack-4.14/204-module_strip.patch
> index c53963c530..d93b545b7c 100644
> --- a/target/linux/generic/hack-4.14/204-module_strip.patch
> +++ b/target/linux/generic/hack-4.14/204-module_strip.patch
> @@ -98,7 +98,7 @@ Signed-off-by: Felix Fietkau
>
> --- a/init/Kconfig
> +++ b/init/Kconfig
> -@@ -1903,6 +1903,13 @@ config TRIM_UNUSED_KSYMS
>
RE: RE: Upcoming 19.07.4 and 18.07.9 stable releases
> -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Hannu Nyman > Sent: Samstag, 14. November 2020 10:08 > To: openwrt-devel@lists.openwrt.org > Subject: Re: RE: Upcoming 19.07.4 and 18.07.9 stable releases > > I wonder why there seems to be practically no discussion about preparations > for the 20.0x release (or actually 20.1x now...). > > I think that last time it was mentioned in August: > > http://lists.openwrt.org/pipermail/openwrt-adm/2020-August/001639.html > > > Is there any hope for a release, or will 2020 be a lost year? Are there any real blockers left? > > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH v1 4/4] ramips: add support for TP-Link MR6400 v4
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Filip Moc
> Sent: Dienstag, 17. November 2020 12:34
> To: openwrt-devel@lists.openwrt.org
> Subject: [PATCH v1 4/4] ramips: add support for TP-Link MR6400 v4
>
> You can flash via tftp recovery:
> - serve tftp-recovery image as /tp_recovery.bin on 192.168.0.225/24
> - connect to any ethernet port
> - power on the device while holding the reset button
> - wait at least 8 seconds before releasing reset button
>
> Flashing via OEM web interface does not work.
>
> LTE module does not support DHCP so it must be configured via QMI.
>
> Hardware Specification (v4.0 EU):
> - SoC: MT7628NN
> - Flash: Winbond W25Q64JVS (8MiB)
> - RAM: ESMT M14D5121632A (64MiB)
> - Wireless: SoC platform only (2.4GHz b/g/n, 2x internal antenna)
> - Ethernet: 1NIC (4x100M)
> - WWAN: TP-LINK LTE MODULE (2x external detachable antenna)
> - Power: DC 9V 0.85A
>
> Signed-off-by: Filip Moc
> ---
>
> Notes:
> Bugs:
> This device is affected by first uqmi command hang.
> This causes qmi proto to hang sometimes when setting up wwan
> connection for
> the first time after boot.
> There is already a patch [1] which aims to fix this.
> So far it can be manually restarted or workarounded by editing qmi.sh
> [2].
>
> There are also some other issues with LTE module which are addressed by
> preceding patches.
>
> [1]
> https://patchwork.ozlabs.org/project/openwrt/patch/20191107115408.1301
> 3-1-zefir.kurt...@neratec.com/
> [2] https://forum.openwrt.org/t/solved-lte-qmi-troubles/28379
>
> .../dts/mt7628an_tplink_tl-mr6400-v4.dts | 97 +++
> target/linux/ramips/image/mt76x8.mk | 16 +++
> .../mt76x8/base-files/etc/board.d/01_leds | 5 +
> .../mt76x8/base-files/etc/board.d/02_network | 4 +
> 4 files changed, 122 insertions(+)
> create mode 100644 target/linux/ramips/dts/mt7628an_tplink_tl-mr6400-
> v4.dts
>
> diff --git a/target/linux/ramips/dts/mt7628an_tplink_tl-mr6400-v4.dts
> b/target/linux/ramips/dts/mt7628an_tplink_tl-mr6400-v4.dts
> new file mode 100644
> index 00..9dc71ffd9e
> --- /dev/null
> +++ b/target/linux/ramips/dts/mt7628an_tplink_tl-mr6400-v4.dts
> @@ -0,0 +1,97 @@
> +#include "mt7628an_tplink_8m.dtsi"
> +
> +/ {
> + compatible = "tplink,tl-mr6400-v4", "mediatek,mt7628an-soc";
> + model = "TP-Link TL-MR6400 v4";
> +
> + aliases {
> + led-boot = &led_power;
> + led-failsafe = &led_power;
> + led-running = &led_power;
> + led-upgrade = &led_power;
> + };
> +
> + keys {
> + compatible = "gpio-keys";
> +
> + reset {
> + label = "reset";
> + gpios = <&gpio 38 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> +
> + rfkill {
> + label = "rfkill";
> + gpios = <&gpio 46 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led_power: power {
> + label = "white:power";
> + gpios = <&gpio 37 GPIO_ACTIVE_LOW>;
> + };
> +
> + wan {
> + label = "white:wan";
> + gpios = <&gpio 39 GPIO_ACTIVE_LOW>;
> + };
> +
> + wlan {
> + label = "white:wlan";
> + gpios = <&gpio 40 GPIO_ACTIVE_LOW>;
> + };
> +
> + lan {
> + label = "white:lan";
> + gpios = <&gpio 41 GPIO_ACTIVE_LOW>;
> + };
> +
> + signal1 {
> + label = "white:signal1";
> + gpios = <&gpio 42 GPIO_ACTIVE_LOW>;
> + };
> +
> + signal2 {
> + label = "white:signal2";
> + gpios = <&gpio 43 GPIO_ACTIVE_LOW>;
> + };
> +
> + signal3 {
> + label = "white:signal3";
> + gpios = <&gpio 44 GPIO_ACTIVE_LOW>;
> + };
> + };
> +};
> +
> +&ehci {
> + status = "okay";
> +};
> +
> +&ohci {
> + status = "okay";
> +};
> +
> +&state_default {
> + gpio {
> + groups = "p0led_an", "p1led_an", "p2led_an", "p3led_an",
> "p4led_an", "refclk", "uart1", "wdt", "wled_an";
> + function = "gpio";
> + };
> +};
> +
> +&esw {
> + mediatek,portmap = <0x2f>;
> + mediatek,portdisable = <0x21>;
> +};
> +
> +
Remove second empty line here.
> +&wmac {
> + mtd-mac-address = <&factory 0x1f100>;
> +};
> +
> +ðernet {
> + mtd-mac-address = <&factory 0x1f100>;
> +};
> diff --git a/target/linux/ramips/image/mt76x8.mk
> b/target/linux/ramips/image/mt76x8.mk
> index 6327c95bb0..f3b25bf189 100644
> --- a/t
RE: [PATCH v1 2/4] uqmi: set device-operating-mode to online
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Filip Moc
> Sent: Dienstag, 17. November 2020 12:33
> To: openwrt-devel@lists.openwrt.org
> Subject: [PATCH v1 2/4] uqmi: set device-operating-mode to online
>
> This is required for LTE module MR400 (in TL-MR6400 v4).
> Otherwise LTE module won't register to GSM network.
Please bump PKG_RELEASE for this package.
Can't review the change itself.
Best
Adrian
>
> Signed-off-by: Filip Moc
> ---
> package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
> b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
> index 7870eb7382..dbfcdcb098 100755
> --- a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
> +++ b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
> @@ -174,6 +174,9 @@ proto_qmi_setup() {
> # Cleanup current state if any
> uqmi -s -d "$device" --stop-network 0x --autoconnect >
> /dev/null 2>&1
>
> + # Go online
> + uqmi -s -d "$device" --set-device-operating-mode online > /dev/null
> 2>&1
> +
> # Set IP format
> uqmi -s -d "$device" --set-data-format 802.3 > /dev/null 2>&1
> uqmi -s -d "$device" --wda-set-data-format 802.3 > /dev/null 2>&1
> --
> 2.28.0
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH v1 3/4] generic: add DTR quirk patch for MR400 LTE
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Filip Moc
> Sent: Dienstag, 17. November 2020 12:33
> To: openwrt-devel@lists.openwrt.org
> Subject: [PATCH v1 3/4] generic: add DTR quirk patch for MR400 LTE
>
> This is required for LTE module MR400 in TL-MR6400 v4.
>
> Signed-off-by: Filip Moc
> ---
>
> Notes:
> Perhaps it would be better to go upstream with this?
Always :-)
If accepted, you could add it in the backports folder ...
Best
Adrian
>
> ...usb-qmi_wwan-Set-DTR-quirk-for-MR400.patch | 28
> +++
> 1 file changed, 28 insertions(+)
> create mode 100644 target/linux/generic/hack-5.4/789-net-usb-qmi_wwan-
> Set-DTR-quirk-for-MR400.patch
>
> diff --git a/target/linux/generic/hack-5.4/789-net-usb-qmi_wwan-Set-DTR-
> quirk-for-MR400.patch b/target/linux/generic/hack-5.4/789-net-usb-
> qmi_wwan-Set-DTR-quirk-for-MR400.patch
> new file mode 100644
> index 00..9c15f01345
> --- /dev/null
> +++ b/target/linux/generic/hack-5.4/789-net-usb-qmi_wwan-Set-DTR-quirk-
> f
> +++ or-MR400.patch
> @@ -0,0 +1,28 @@
> +From a661d0b88c6de286f0b861ace670cb31776aadd6 Mon Sep 17 00:00:00
> 2001
> +From: Filip Moc
> +Date: Wed, 11 Nov 2020 20:39:09 +0100
> +Subject: [PATCH] net: usb: qmi_wwan: Set DTR quirk for MR400
> +
> +LTE module MR400 embedded in TL-MR6400 v4 requires DTR to be set.
> +
> +Signed-off-by: Filip Moc
> +---
> + drivers/net/usb/qmi_wwan.c | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
> +index 21d905d..da6f10a 100644
> +--- a/drivers/net/usb/qmi_wwan.c
> b/drivers/net/usb/qmi_wwan.c
> +@@ -1092,7 +1092,7 @@ static const struct usb_device_id products[] = {
> + {QMI_FIXED_INTF(0x05c6, 0x9011, 4)},
> + {QMI_FIXED_INTF(0x05c6, 0x9021, 1)},
> + {QMI_FIXED_INTF(0x05c6, 0x9022, 2)},
> +-{QMI_FIXED_INTF(0x05c6, 0x9025, 4)},/* Alcatel-sbell ASB
> TL131 TDD LTE (China Mobile) */
> ++{QMI_QUIRK_SET_DTR(0x05c6, 0x9025, 4)}, /* Alcatel-sbell ASB
> TL131 TDD LTE (China Mobile) */
> + {QMI_FIXED_INTF(0x05c6, 0x9026, 3)},
> + {QMI_FIXED_INTF(0x05c6, 0x902e, 5)},
> + {QMI_FIXED_INTF(0x05c6, 0x9031, 5)},
> +--
> +2.28.0
> +
> --
> 2.28.0
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH 19.07] ipq40xx: Revert "ipq40xx: fix ethernet vlan double tagging"
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Baptiste Jonglez
> Sent: Freitag, 20. November 2020 11:21
> To: openwrt-devel@lists.openwrt.org; John Crispin
> Cc: Baptiste Jonglez
> Subject: [PATCH 19.07] ipq40xx: Revert "ipq40xx: fix ethernet vlan double
> tagging"
>
> From: Baptiste Jonglez
>
> This change has been causing several issues on ipq40xx devices, including:
this seems to lack a Signed-off-by?
Best
Adrian
>
> - VLAN tagging no longer works correctly:
> https://bugs.openwrt.org/index.php?do=details&task_id=3239
> - poor performance with tagged VLANs:
> https://bugs.openwrt.org/index.php?do=details&task_id=3457
>
> See also https://forum.openwrt.org/t/vlan-tagging-on-ipq40xx-gl-b1300-no-
> longer-works/69569
>
> There are have been discussions on ways to fix the issue in the links above
> (including switching to DSA), but nothing that can realistically be
> introduced in
> the 19.07 branch.
>
> This reverts commit 8c191712558ce94 ("ipq40xx: fix ethernet vlan double
> tagging")
>
> Note that it's not a clean revert because this patch was touched in
> 148d59c67edd5 ("kernel: update kernel 4.14 to version 4.14.193") even
> though the semantic of the patch was left unchanged.
>
> Fixes: FS#3239
> Fixes: FS#3457
> ---
> .../716-essedma-vlan-double-tag.patch | 128 --
> 1 file changed, 128 deletions(-)
> delete mode 100644 target/linux/ipq40xx/patches-4.14/716-essedma-vlan-
> double-tag.patch
>
> diff --git a/target/linux/ipq40xx/patches-4.14/716-essedma-vlan-double-
> tag.patch b/target/linux/ipq40xx/patches-4.14/716-essedma-vlan-double-
> tag.patch
> deleted file mode 100644
> index e268351273..00
> --- a/target/linux/ipq40xx/patches-4.14/716-essedma-vlan-double-tag.patch
> +++ /dev/null
> @@ -1,128 +0,0 @@
> -From: Sven Eckelmann
> -Date: Wed, 8 Feb 2017 16:26:00 +0100
> -Subject: [PATCH] ipq40xx: Fix ar40xx port separation
> -
> -It is currently not possible to submit (or receive) VLAN tagged frames over -
> the ar40xx PHY switch and the edma ethernet device.
> -
> -This can be worked around by disabling enable_vlan. The separation of the
> -eth0 and eth1 ports is then done by the vlan_tag information from the -
> device tree. But the ar40xx PHY switch then also has to parse the word3 -port
> bitmap (word3) from the TDP when data was received from the CPU port -
> (0).
> -
> -IssueID: #2857
> -
> -Forwarded: no
> - The ar40xx.c change was forwarded to Xiaofei Shen
>
> - (QCA). But John Crispin will rewrite the driver anyway and we have to check
> - later if this change is required in his driver too.
>
> - drivers/net/phy/ar40xx.c | 6 +-
> - 1 file changed, 5 insertions(+), 1 deletion(-)
> -
> a/drivers/net/phy/ar40xx.c
> -+++ b/drivers/net/phy/ar40xx.c
> -@@ -1200,7 +1200,11 @@ ar40xx_init_port(struct ar40xx_priv *pri
> - ar40xx_rmw(priv, AR40XX_REG_PORT_STATUS(port),
> - AR40XX_PORT_AUTO_LINK_EN, 0);
> -
> --ar40xx_write(priv, AR40XX_REG_PORT_HEADER(port), 0);
> -+/* CPU port is setting headers to limit output ports */
> -+if (port == 0)
> -+ar40xx_write(priv, AR40XX_REG_PORT_HEADER(port), 0x8);
> -+else
> -+ar40xx_write(priv, AR40XX_REG_PORT_HEADER(port), 0);
> -
> - ar40xx_write(priv, AR40XX_REG_PORT_VLAN0(port), 0);
> -
> -@@ -1243,6 +1247,10 @@ ar40xx_init_globals(struct ar40xx_priv *
> - t = (AR40XX_PORT0_FC_THRESH_ON_DFLT << 16) |
> - AR40XX_PORT0_FC_THRESH_OFF_DFLT;
> - ar40xx_write(priv, AR40XX_REG_PORT_FLOWCTRL_THRESH(0), t);
> -+
> -+/* set service tag to 802.1q */
> -+t = ETH_P_8021Q | AR40XX_ESS_SERVICE_TAG_STAG;
> -+ar40xx_write(priv, AR40XX_ESS_SERVICE_TAG, t);
> - }
> -
> - static void
> -@@ -1568,7 +1576,11 @@ ar40xx_setup_port(struct ar40xx_priv *pr
> - u32 pvid = priv->vlan_id[priv->pvid[port]];
> -
> - if (priv->vlan) {
> --egress = AR40XX_PORT_VLAN1_OUT_MODE_UNMOD;
> -+if (priv->vlan_tagged & BIT(port))
> -+egress = AR40XX_PORT_VLAN1_OUT_MODE_TAG;
> -+else
> -+egress =
> AR40XX_PORT_VLAN1_OUT_MODE_UNMOD;
> -+
> - ingress = AR40XX_IN_SECURE;
> - } else {
> - egress = AR40XX_PORT_VLAN1_OUT_MODE_UNTOUCH;
> -@@ -1579,8 +1591,17 @@ ar40xx_setup_port(struct ar40xx_priv *pr
> - t |= pvid << AR40XX_PORT_VLAN0_DEF_CVID_S;
> - ar40xx_write(priv, AR40XX_REG_PORT_VLAN0(port), t);
> -
> --t = AR40XX_PORT_VLAN1_PORT_VLAN_PROP;
> --t |= egress << AR40XX_PORT_VLAN1_OUT_MODE_S;
> -+t = egress << AR40XX_PORT_VLAN1_OUT_MODE_S;
> -+
> -+/* set CPU port to core port */
> -+if (port == 0)
> -+t |= AR40XX_PORT_VLAN1_CORE_PORT;
> -+
> -+if (priv->vlan_tagged & BIT(port))
> -+t |= AR40XX_PORT_VLAN1_PORT_VLAN_PROP;
> -+else
> -+t |= AR40XX_PORT_VLAN1_PORT_TLS_MODE;
> -+
> - ar40xx_writ
RE: 20.xx: state of the DSA
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Paul Spooren > Sent: Freitag, 20. November 2020 01:36 > To: openwrt-devel@lists.openwrt.org > Subject: 20.xx: state of the DSA > > Hi all, > > DSA (Distributed Switch Architecture)[0] is a main feature of 20.xx and one of > the last blockers for a branch. The goal states[1] support where possible, not > necessarily every target. since we discuss this in the context of the next stable release, I don't think the focus should be on which targets are supported and which are not. 20.xx/21.xx will be a mixed release in that context. Our main interest should be to clarify what needs to be done in order to release DSA with proper support (on the platforms that already have it), and then get these things done quickly. Best Adrian > > This mail thread should be used to get an overview of the missing bits. > > The following targets seem use `swconfig`, should/can they be ported? > Please post states and links to work in progress migrations: > > * apm821xx/nand > * ath25 > * ath79 > * bcm47xx > * bcm53xx > * bcm63xx > * ipq40xx > * ipq806x > * kirkwood > * lantiq/xrx200 > * lantiq/xway > * lantiq/xway_legacy > * mediatek > * mpc85xx > * ramips/mt7620 > * ramips/mt76x8 > * ramips/rt288x > * ramips/rt305x > * ramips/rt3883 > > All other targets can be considered as DSA targets? If you're working or > testing around that, please comment and share the status. > > LuCI support is added via a PR[2] on GitHub. > > Best, > Paul > > [0]: https://www.kernel.org/doc/html/latest/networking/dsa/dsa.html > [1]: https://openwrt.org/docs/guide-developer/releases/goals/20.xx > [2]: https://github.com/openwrt/luci/pull/4307 > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: 20.xx: postponse LuCI HTTPS per default
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Alberto Bursi > Sent: Freitag, 20. November 2020 17:32 > To: openwrt-devel@lists.openwrt.org > Subject: Re: 20.xx: postponse LuCI HTTPS per default > > > > On 20/11/20 17:17, Fernando Frediani wrote: > > Hi Alberto > > > > On 20/11/2020 13:09, Alberto Bursi wrote: > >> > >> > >> > >> The only thing I can accept as a valid complaint against https by > >> default is the increased minimum space requirements, everything else > >> I really don't understand nor agree with. > > > > It's exactly this I am referring to when I talk about the extras not > > the steps the user will take to enable it. So why I mentioned to leave > > it as optional and easy to do for those who wish (and have space) to have > it. > > > > Devices with low flash space (and RAM) are already receiving special > treatment (different compile options, different default packages) to lower > space footprint. > > These devices can (should?) be left out of the "https by default" easily. No, this is not an option. We certainly won't have (read "maintain") _two_ defaults for a matter like this. Apart from that, this discussion was not intended to discuss the various options _again_, but to ask whether we should have "https by default" as a _blocker_ for the next release. Personally, since the discussion seems to be as open and unresolved as a few months ago, I'm against making this a blocker. I'm curious where the whole topic evolves to, but that's not the subject of this thread. Best Adrian > > But I would be strongly against degrading security for everyone just because > of these devices. > > -Alberto > > > Regards > > Fernando > > > >> > >> > >>> Yes it is nice to have everything ready and automated to be done > >>> with a few clicks for those cases that require it. In fact I think > >>> this would be a better solution for now so it will be possible to > >>> gather gradually this transition (or not) from HTTP to HTTPS even > >>> for local/lan applications and see how often people would opt to use it. > >>> > >>> Still should it end up having HTTPS by default I see self-signed > >>> certificates are the way to go. Yes there are the warnings and I > >>> really don't think there is any issue with it. > >>> Those accessing the router Web Interface are not 'normal' Internet > >>> users and they know what they are doing so the warning from > >>> self-signed certificates should not be a surprise for them. > >>> And those cases when admins prefer they can always replace the > >>> self-signed one for Let's Encrypt for example. > >>> > >>> Regards > >>> Fernando > >> > >> > >> -Alberto > >> > >> ___ > >> 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 > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH] Adds support for Comfast CF-E538AC
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Sven Danner
> Sent: Montag, 23. November 2020 03:23
> To: j...@phrozen.org
> Cc: openwrt-devel@lists.openwrt.org
> Subject: [PATCH] Adds support for Comfast CF-E538AC
Please use proper title prefix according to submitting-patches guidelines.
>
> Comfast CF-E538AC is an wall mounted access point with an additional
> Ethernet LAN access port. It supports 802.11AC Wave2 MU-MIMO
>
> Serial port access for debricking requires simple soldering of 4 pins.
>
> Device specifications:
> * SoC: MT7620DA @ 580MHz
> * RAM: 64MiB DDR2
> * Flash: 8iB SPI
> * Wireless 2.4GHz (SoC): b/g/n
> * Wireless 5Ghz (MT7612E): n/ac, 2x2 MU-MINO
> * Ethernet (RTL8211F): 1× 1GbE, 802.3af PoE
> * Ethernet (RTL8211F): 1× 1GbE
>
> Flashing instructions:
> * Upgrade using web interface
>
> Debricking:
> * Serial port can be soldered on top PCB (marked as 1)
> (1: VCC, 2: GND, 3: TX, 4: RX)
> * Use 3.3V, 115200 baud, 8n1
> * Recovery only possible via TFTP
> * Modified U-Boot environment does not allow recovery via serial
> (will not commit it to flash)
> * Bootloader will show a menu for 1 seconds
> * Select 2: Load system code then write to Flash via TFTP.
Missing Signed-off-by.
> ---
> .../ramips/dts/mt7620a_comfast_cf-e538ac.dts | 158
> ++
> target/linux/ramips/image/mt7620.mk | 11 ++
> .../mt7620/base-files/etc/board.d/01_leds | 3 +
> .../mt7620/base-files/etc/board.d/02_network | 4 +
> 4 files changed, 176 insertions(+)
> create mode 100644 target/linux/ramips/dts/mt7620a_comfast_cf-
> e538ac.dts
>
> diff --git a/target/linux/ramips/dts/mt7620a_comfast_cf-e538ac.dts
> b/target/linux/ramips/dts/mt7620a_comfast_cf-e538ac.dts
> new file mode 100644
> index 00..b857c8db9c
> --- /dev/null
> +++ b/target/linux/ramips/dts/mt7620a_comfast_cf-e538ac.dts
> @@ -0,0 +1,158 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT /dts-v1/;
dts-v1 can be dropped here.
> +
> +#include "mt7620a.dtsi"
> +
> +#include
> +#include
> +
> +/ {
> + compatible = "comfast,cf-e538ac", "ralink,mt7620a-soc";
> + model = "Comfast CF-E538AC";
> +
> + aliases {
> + led-boot = &led_wifi;
> + led-failsafe = &led_wifi;
> + led-running = &led_wifi;
> + led-upgrade = &led_wifi;
> + };
> +
> + chosen {
> + bootargs = "console=ttyS0,115200";
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led_wifi: wifi {
> + label = "white:wifi";
> + gpios = <&gpio3 0x00 GPIO_ACTIVE_LOW>;
We prefer numeric (decimal) values for the GPIO.
> + };
> + };
> +
> + keys {
> + compatible = "gpio-keys-polled";
> + poll-interval = <0x14>;
Try "gpio-keys" without poll-interval, please.
> +
> + reset {
> + label = "reset";
> + gpios = <&gpio0 0x0d GPIO_ACTIVE_LOW>;
decimal ...
> + linux,code = ;
> + };
> + };
> +
> +};
> +
> +&gpio0 {
> + status = "okay";
> +};
> +
> +&gpio2 {
> + status = "okay";
> +};
What do you need that for?
> +
> +&gpio3 {
> + status = "okay";
> +};
> +
> +&spi0 {
> + status = "okay";
> +
> + m25p80@0 {
flash@0
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <1000>;
Can this go faster?
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition@0 {
> + label = "u-boot";
> + reg = <0x0 0x3>;
> + read-only;
> + };
> +
> + partition@3 {
> + label = "u-boot-env";
> + reg = <0x3 0x1>;
> + read-only;
> + };
> +
> + factory: partition@4 {
> + label = "factory";
> + reg = <0x4 0x1>;
> + read-only;
> + };
> +
> + partition@5 {
> + compatible = "denx,uimage";
> + label = "firmware";
> + reg = <0x5 0x7b>;
> + };
> + };
> + };
> +};
> +
> +ðernet {
> + status = "okay";
> + pinctrl-names = "default";
> + mtd-mac-address = <&factory 0xe000>;
> + pinctrl-0 = <&rgmii1_pins &rgmii2_pins &mdio_pins>;
> + mediatek,portmap = "w";
This doesn't make sense if WAN is on port 5.
> +
> + port@4 {
> + status = "o
RE: [PATCH] ipq806x: Fix FS#3086 - Netgear D7800 eth0 WAN Port not working with 100Mbit Make &gmac1 and &gmac2 same as R7500v2.dts
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of pe...@cardoe.co.uk
> Sent: Dienstag, 24. November 2020 14:55
> To: openwrt-devel@lists.openwrt.org
> Cc: Peter Cardoe
> Subject: [PATCH] ipq806x: Fix FS#3086 - Netgear D7800 eth0 WAN Port not
> working with 100Mbit Make &gmac1 and &gmac2 same as R7500v2.dts
>
> From: Peter Cardoe
This lacks proper title and commit message.
See: https://openwrt.org/submitting-patches
Apart from that, if unsure, it's always a good idea to look at git history to
see what people did before you.
Best
Adrian
>
> Signed-off-by: Peter Cardoe
> ---
> target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8064-d7800.dts | 6
> +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8064-
> d7800.dts b/target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8064-
> d7800.dts
> index 7fb871b..229596b 100644
> --- a/target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8064-d7800.dts
> +++ b/target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8064-
> d7800.dts
> @@ -283,13 +283,17 @@
> &gmac1 {
> status = "okay";
> phy-mode = "rgmii";
> - phy-handle = <&phy4>;
> qcom,id = <1>;
>
> pinctrl-0 = <&rgmii2_pins>;
> pinctrl-names = "default";
>
> mtd-mac-address = <&art 6>;
> +
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> };
>
> &gmac2 {
> --
> 2.7.4
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH] ramips: add support for TP-Link MR6400 v5
Hi,
a few minor comments:
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Filip Moc
> Sent: Dienstag, 24. November 2020 10:01
> To: openwrt-devel@lists.openwrt.org
> Subject: [PATCH] ramips: add support for TP-Link MR6400 v5
>
> You can flash via tftp recovery:
> - serve tftp-recovery image as /tp_recovery.bin on 192.168.0.225/24
> - connect to any ethernet port
> - power on the device while holding the reset button
> - wait at least 8 seconds before releasing reset button
>
> Flashing via OEM web interface does not work.
>
> LTE module does not support DHCP so it must be configured via QMI.
>
> Hardware Specification (v5.0 EU):
> - SoC: MT7628NN
> - Flash: Winbond W25Q64JVS (8MiB)
> - RAM: ESMT M14D5121632A (64MiB)
> - Wireless: SoC platform only (2.4GHz b/g/n, 2x internal antenna)
> - Ethernet: 1NIC (4x100M)
> - WWAN: TP-LINK LTE MODULE (2x external detachable antenna)
> - Power: DC 9V 0.85A
Since it looks from the commit message like v4 is a 100% clone of v5, maybe add
two simple sentences about the differences: LED GPIOs and switch connections.
>
> Signed-off-by: Filip Moc
> ---
>
> Notes:
> Bugs:
> This device is affected by first uqmi command hang.
> This causes qmi proto to hang sometimes when setting up wwan
> connection for
> the first time after boot.
> There is already a patch [1] applied which aims to fix this. But update
> of
> qmi.sh is still needed to make use of it.
> So far it can be manually restarted or workarounded by editing qmi.sh.
>
> [1]
> https://git.openwrt.org/?p=project/uqmi.git;a=commitdiff;h=0a19b5b77140
> 465c29e2afa7d611fe93abc9672f
>
> .../dts/mt7628an_tplink_tl-mr6400-v5.dts | 97 +++
> target/linux/ramips/image/mt76x8.mk | 16 +++
> .../mt76x8/base-files/etc/board.d/01_leds | 4 +
> .../mt76x8/base-files/etc/board.d/02_network | 4 +
> 4 files changed, 121 insertions(+)
> create mode 100644 target/linux/ramips/dts/mt7628an_tplink_tl-mr6400-
> v5.dts
>
> diff --git a/target/linux/ramips/dts/mt7628an_tplink_tl-mr6400-v5.dts
> b/target/linux/ramips/dts/mt7628an_tplink_tl-mr6400-v5.dts
> new file mode 100644
> index 00..09e8be9547
> --- /dev/null
> +++ b/target/linux/ramips/dts/mt7628an_tplink_tl-mr6400-v5.dts
> @@ -0,0 +1,97 @@
> +#include "mt7628an_tplink_8m.dtsi"
Please add an SPDX license identifier (it would be nice if you also added one
for v4 in a separate patch).
> +
> +/ {
> + compatible = "tplink,tl-mr6400-v5", "mediatek,mt7628an-soc";
> + model = "TP-Link TL-MR6400 v5";
> +
> + aliases {
> + led-boot = &led_power;
> + led-failsafe = &led_power;
> + led-running = &led_power;
> + led-upgrade = &led_power;
> + };
> +
> + keys {
> + compatible = "gpio-keys";
> +
> + reset {
> + label = "reset";
> + gpios = <&gpio 38 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> +
> + rfkill {
> + label = "rfkill";
> + gpios = <&gpio 46 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + wlan {
> + label = "white:wlan";
> + gpios = <&gpio 4 GPIO_ACTIVE_LOW>;
> + linux,default-trigger = "phy0tpt";
> + };
> +
> + lan {
> + label = "white:lan";
> + gpios = <&gpio 5 GPIO_ACTIVE_LOW>;
> + };
> +
> + led_power: power {
> + label = "white:power";
> + gpios = <&gpio 39 GPIO_ACTIVE_LOW>;
> + };
> +
> + wan {
> + label = "white:wan";
> + gpios = <&gpio 40 GPIO_ACTIVE_LOW>;
> + };
> +
> + signal1 {
> + label = "white:signal1";
> + gpios = <&gpio 41 GPIO_ACTIVE_LOW>;
> + };
> +
> + signal2 {
> + label = "white:signal2";
> + gpios = <&gpio 42 GPIO_ACTIVE_LOW>;
> + };
> +
> + signal3 {
> + label = "white:signal3";
> + gpios = <&gpio 43 GPIO_ACTIVE_LOW>;
> + };
> + };
> +};
> +
> +&ehci {
> + status = "okay";
> +};
> +
> +&ohci {
> + status = "okay";
> +};
> +
> +&state_default {
> + gpio {
> + groups = "i2c", "i2s", "p0led_an", "p1led_an", "p2led_an",
> "p3led_an", "p4led_an", "uart1", "wdt";
Don't see i2s required anywhere?
Best
Adrian
> + function = "gpio";
> + };
> +};
> +
> +&esw {
> + mediatek,portmap = <0x37>;
> + mediatek,portdisable = <0x30>;
> +};
> +
> +&wmac {
> + mtd-mac-
RE: [PATCH] treewide: replace my o2.pl email address
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Tomasz Maciej Nowak > Sent: Freitag, 20. November 2020 19:47 > To: openwrt-devel@lists.openwrt.org > Subject: [PATCH] treewide: replace my o2.pl email address > > I'm still available at the old address. > > Signed-off-by: Tomasz Maciej Nowak I've merged this one. Is it your intend that you still sign off with the old address? Best Adrian > --- > package/boot/uboot-tegra/Makefile | 4 ++-- > target/linux/tegra/Makefile | 2 +- > target/linux/tegra/image/Makefile | 2 +- tools/cbootimage- > configs/Makefile | 2 +- > tools/cbootimage/Makefile | 2 +- > 5 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/package/boot/uboot-tegra/Makefile b/package/boot/uboot- > tegra/Makefile > index 4b9f7876f80e..778019257da0 100644 > --- a/package/boot/uboot-tegra/Makefile > +++ b/package/boot/uboot-tegra/Makefile > @@ -1,5 +1,5 @@ > # > -# Copyright (C) 2017-2019 Tomasz Maciej Nowak > +# Copyright (C) 2017-2019 Tomasz Maciej Nowak > # > # This is free software, licensed under the GNU General Public License v2. > # See /LICENSE for more information. > @@ -11,7 +11,7 @@ PKG_RELEASE := 1 > > PKG_HASH := > 76b7772d156b3ddd7644c8a1736081e55b78828537ff714065d21dbade229bef > > -PKG_MAINTAINER := Tomasz Maciej Nowak > +PKG_MAINTAINER := Tomasz Maciej Nowak > > include $(INCLUDE_DIR)/u-boot.mk > include $(INCLUDE_DIR)/package.mk > diff --git a/target/linux/tegra/Makefile b/target/linux/tegra/Makefile index > 5dd4d439849e..cf929fb0f104 100644 > --- a/target/linux/tegra/Makefile > +++ b/target/linux/tegra/Makefile > @@ -1,5 +1,5 @@ > # > -# Copyright (C) 2017-2019 Tomasz Maciej Nowak > +# Copyright (C) 2017-2019 Tomasz Maciej Nowak > # > # This is free software, licensed under the GNU General Public License v2. > # See /LICENSE for more information. > diff --git a/target/linux/tegra/image/Makefile > b/target/linux/tegra/image/Makefile > index 33e7b508d966..aa0083f9ae47 100644 > --- a/target/linux/tegra/image/Makefile > +++ b/target/linux/tegra/image/Makefile > @@ -1,5 +1,5 @@ > # > -# Copyright (C) 2017-2019 Tomasz Maciej Nowak > +# Copyright (C) 2017-2019 Tomasz Maciej Nowak > # > # This is free software, licensed under the GNU General Public License v2. > # See /LICENSE for more information. > diff --git a/tools/cbootimage-configs/Makefile b/tools/cbootimage- > configs/Makefile > index 5a1fc568cb4c..cafd4e5a20dd 100644 > --- a/tools/cbootimage-configs/Makefile > +++ b/tools/cbootimage-configs/Makefile > @@ -1,5 +1,5 @@ > # > -# Copyright (c) 2017-2019 Tomasz Maciej Nowak > +# Copyright (c) 2017-2019 Tomasz Maciej Nowak > # > # This is free software, licensed under the GNU General Public License v2. > # See /LICENSE for more information. > diff --git a/tools/cbootimage/Makefile b/tools/cbootimage/Makefile index > 42640eab363b..71fdb5768c29 100644 > --- a/tools/cbootimage/Makefile > +++ b/tools/cbootimage/Makefile > @@ -1,5 +1,5 @@ > # > -# Copyright (c) 2017-2019 Tomasz Maciej Nowak > +# Copyright (c) 2017-2019 Tomasz Maciej Nowak > # > # This is free software, licensed under the GNU General Public License v2. > # See /LICENSE for more information. > -- > 2.29.2 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH 0/8] kernel: mtdsplit_uimage: use device tree properties for non-standard uimage parsing
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Bjørn Mork > Sent: Mittwoch, 25. November 2020 12:45 > To: openwrt-devel@lists.openwrt.org > Cc: Bjørn Mork > Subject: [PATCH 0/8] kernel: mtdsplit_uimage: use device tree properties for > non-standard uimage parsing > > This ended up a bit more invasive than I imagined, but here goes.. > > I wanted to add a couple of new rtl83xx devices. They both use standard > uimages, but with device specific magic values. Like most devices in this > target, it seems. > > The easy route would be to just add another magic to one of the existing > parsers in mtdsplit_uimage, or maybe even a new parser grouping devices > "belonging together" on some scale. But this seems so unnecessary > complicated to add something which is basically a device specific > configuration and nothing more. Not to mention that it does have some side > effects. New parsers make the code grow. > Adding new magic numbers to existing parsers make them less fool proof, > allowing any of the magic values to match while there is only one correct > value most of the time. > > So I thought I'd rather put these magic values in the device tree, for the > cases > where the parser is otherwise identical to the generic "denx,uimage" parser. > I believe this makes sense. > > No so sure about the rest of the series. But the snow ball rolled, and I > thought "why not do the same for the other device specific parameters?". > So I added device tree properties for those as well. > And ended up removing all the parsers except for the generic one. I like the general idea, it feels elegant. However, I wonder whether - strictly - these parameter belong into device tree, i.e. "describe the hardware". (this is meant as an open question, I do not want to express any rejection with that) And probably we would need to involve upstream (devicetree-spec) for the naming of the properties? Or is this irrelevant as mtdsplit_uimage is just "our stuff" anyway? Best Adrian > > Still not sure that was a good idea. In particular because it's hard to test > this > without having the hardware, which I don't have. And console is required if > something breaks. > > Anyway, here it is. Please be gentle :-) > > > > Bjørn > --- > > Bjørn Mork (8): > kernel: mtdsplit_uimage: read extralen from device tree > kernel: mtdsplit_uimage: replace "fonfxc" and "sge" parsers > kernel: mtdsplit_uimage: add "ih-magic" device-tree property > kernel: mtdsplit_uimage: replace "openwrt,okli" parser > kernel: mtdsplit_uimage: replace "allnet,uimage" parser > kernel: mtdsplit_uimage: add "ih-type" device-tree property > kernel: mtdsplit_uimage: replace "netgear,uimage" parser > kernel: mtdsplit_uimage: replace "edimax,uimage" parser > > .../ath79/dts/ar7161_netgear_wndr3700-v2.dts | 4 +- > .../ath79/dts/ar7161_netgear_wndr3700.dts | 4 +- > .../ath79/dts/ar7161_netgear_wndr3800.dts | 4 +- > .../ath79/dts/ar7161_netgear_wndr3800ch.dts | 4 +- > .../ath79/dts/ar7161_netgear_wndrmac-v1.dts | 4 +- > .../ath79/dts/ar7161_netgear_wndrmac-v2.dts | 4 +- > .../ath79/dts/ar7240_engenius_enh202-v1.dts | 3 +- > .../ath79/dts/ar7240_netgear_wnr1000-v2.dts | 4 +- > .../ath79/dts/ar7240_netgear_wnr612-v2.dtsi | 4 +- > .../ath79/dts/ar7241_netgear_wnr2000-v3.dts | 4 +- > .../ath79/dts/ar7241_netgear_wnr2200-16m.dts | 4 +- > .../ath79/dts/ar7241_netgear_wnr2200-8m.dts | 4 +- > .../dts/ar9341_engenius_ens202ext-v1.dts | 3 +- > .../linux/ath79/dts/ar9341_pisen_wmb001n.dts | 3 +- > .../linux/ath79/dts/ar9344_netgear_wndr.dtsi | 4 +- > .../drivers/mtd/mtdsplit/mtdsplit_uimage.c| 418 +++--- > .../dts/mt7620a_edimax_br-6478ac-v2.dts | 4 +- > .../ramips/dts/mt7620a_edimax_ew-7478apc.dts | 4 +- > .../linux/ramips/dts/mt7620a_fon_fon2601.dts | 3 +- > .../ramips/dts/mt7620n_sunvalley_filehub.dtsi | 3 +- > .../ramips/dts/mt7621_dlink_dir-8xx-a1.dtsi | 3 +- > .../ramips/dts/mt7621_dlink_dir-xx60-a1.dtsi | 6 +- > .../linux/ramips/dts/mt7621_edimax_re23s.dts | 4 +- > .../ramips/dts/rt3050_edimax_3g-6200n.dts | 4 +- > .../ramips/dts/rt3050_edimax_3g-6200nl.dts| 4 +- > .../ramips/dts/rt3662_edimax_br-6475nd.dts| 4 +- > .../dts/rtl8382_allnet_all-sg8208m.dts| 3 +- > 27 files changed, 140 insertions(+), 377 deletions(-) > > -- > 2.20.1 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH 2/8] mvebu: sysupgrade: use v function for writing logs
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Tomasz Maciej Nowak
> Sent: Mittwoch, 25. November 2020 17:34
> To: openwrt-devel@lists.openwrt.org
> Subject: [PATCH 2/8] mvebu: sysupgrade: use v function for writing logs
>
> Signed-off-by: Tomasz Maciej Nowak
would you please add a commit message for this one and resend it?
You may just send this one without the rest of the patches, I will pick it
then. (Just going through the rest at the moment, will probably take most/all
of it as well.)
Or, if you prefer, just send the commit message as an answer to this mail and I
will insert it.
Best
Adrian
> ---
> target/linux/mvebu/base-files/lib/upgrade/sdcard.sh | 12 ++--
> .../mvebu/cortexa9/base-files/lib/upgrade/linksys.sh | 2 +-
> 2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/target/linux/mvebu/base-files/lib/upgrade/sdcard.sh
> b/target/linux/mvebu/base-files/lib/upgrade/sdcard.sh
> index d16ddc500079..f189c240cf09 100644
> --- a/target/linux/mvebu/base-files/lib/upgrade/sdcard.sh
> +++ b/target/linux/mvebu/base-files/lib/upgrade/sdcard.sh
> @@ -3,7 +3,7 @@ platform_check_image_sdcard() {
> local magic diskdev partdev diff
>
> export_bootdevice && export_partdevice diskdev 0 || {
> - echo "Unable to determine upgrade device"
> + v "Unable to determine upgrade device"
> return 1
> }
>
> @@ -20,7 +20,7 @@ platform_check_image_sdcard() {
> rm -f /tmp/image.bs /tmp/partmap.bootdisk /tmp/partmap.image
>
> if [ -n "$diff" ]; then
> - echo "Partition layout has changed. Full image will be
> written."
> + v "Partition layout has changed. Full image will be written."
> ask_bool 0 "Abort" && exit 1
> return 0
> fi
> @@ -31,7 +31,7 @@ platform_do_upgrade_sdcard() {
> local diskdev partdev diff
>
> export_bootdevice && export_partdevice diskdev 0 || {
> - echo "Unable to determine upgrade device"
> + v "Unable to determine upgrade device"
> return 1
> }
>
> @@ -64,15 +64,15 @@ platform_do_upgrade_sdcard() {
> #iterate over each partition from the image and write it to the
> boot disk
> while read part start size; do
> if export_partdevice partdev $part; then
> - echo "Writing image to /dev/$partdev..."
> + v "Writing image to /dev/$partdev..."
> get_image "$@" | dd of="/dev/$partdev"
> ibs="512" obs=1M skip="$start" count="$size" conv=fsync
> else
> - echo "Unable to find partition $part device,
> skipped."
> + v "Unable to find partition $part device,
> skipped."
> fi
> done < /tmp/partmap.image
>
> #copy partition uuid
> - echo "Writing new UUID to /dev/$diskdev..."
> + v "Writing new UUID to /dev/$diskdev..."
> get_image "$@" | dd of="/dev/$diskdev" bs=1 skip=440
> count=4 seek=440 conv=fsync
> fi
>
> diff --git a/target/linux/mvebu/cortexa9/base-files/lib/upgrade/linksys.sh
> b/target/linux/mvebu/cortexa9/base-files/lib/upgrade/linksys.sh
> index 6ccfdd0768da..c5da471d76f1 100644
> --- a/target/linux/mvebu/cortexa9/base-files/lib/upgrade/linksys.sh
> +++ b/target/linux/mvebu/cortexa9/base-files/lib/upgrade/linksys.sh
> @@ -57,7 +57,7 @@ platform_do_upgrade_linksys() {
>
> if [ ! -n "$part_label" ]
> then
> - echo "cannot find target partition"
> + v "cannot find target partition"
> exit 1
> fi
>
> --
> 2.29.2
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH 6/8] tegra: sysupgrade: use v function for writing logs
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Tomasz Maciej Nowak
> Sent: Mittwoch, 25. November 2020 17:34
> To: openwrt-devel@lists.openwrt.org
> Subject: [PATCH 6/8] tegra: sysupgrade: use v function for writing logs
>
> Signed-off-by: Tomasz Maciej Nowak
same as for mvebu, I need a commit message somehow ...
Best
Adrian
> ---
> .../linux/tegra/base-files/lib/upgrade/platform.sh | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/target/linux/tegra/base-files/lib/upgrade/platform.sh
> b/target/linux/tegra/base-files/lib/upgrade/platform.sh
> index 05b48cd50a8a..5c729de1a4b5 100644
> --- a/target/linux/tegra/base-files/lib/upgrade/platform.sh
> +++ b/target/linux/tegra/base-files/lib/upgrade/platform.sh
> @@ -6,7 +6,7 @@ platform_check_image() {
> [ "$#" -gt 1 ] && return 1
>
> export_bootdevice && export_partdevice diskdev 0 || {
> - echo "Unable to determine upgrade device"
> + v "Unable to determine upgrade device"
> return 1
> }
>
> @@ -23,7 +23,7 @@ platform_check_image() {
> rm -f /tmp/image.bs /tmp/partmap.bootdisk /tmp/partmap.image
>
> if [ -n "$diff" ]; then
> - echo "Partition layout has changed. Full image will be
> written."
> + v "Partition layout has changed. Full image will be written."
> ask_bool 0 "Abort" && exit 1
> return 0
> fi
> @@ -43,7 +43,7 @@ platform_do_upgrade() {
> local diskdev partdev diff
>
> export_bootdevice && export_partdevice diskdev 0 || {
> - echo "Unable to determine upgrade device"
> + v "Unable to determine upgrade device"
> return 1
> }
>
> @@ -79,14 +79,14 @@ platform_do_upgrade() {
> #iterate over each partition from the image and write it to the boot
> disk
> while read part start size; do
> if export_partdevice partdev $part; then
> - echo "Writing image to /dev/$partdev..."
> + v "Writing image to /dev/$partdev..."
> get_image "$@" | dd of="/dev/$partdev" ibs="512"
> obs=1M skip="$start" count="$size" conv=fsync
> else
> - echo "Unable to find partition $part device, skipped."
> + v "Unable to find partition $part device, skipped."
> fi
> done < /tmp/partmap.image
>
> #copy partition uuid
> - echo "Writing new UUID to /dev/$diskdev..."
> + v "Writing new UUID to /dev/$diskdev..."
> get_image "$@" | dd of="/dev/$diskdev" bs=1 skip=440 count=4
> seek=440 conv=fsync }
> --
> 2.29.2
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH 7/8] tegra: sysupgrade: use get_image_dd wrapper
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Tomasz Maciej Nowak
> Sent: Mittwoch, 25. November 2020 17:34
> To: openwrt-devel@lists.openwrt.org
> Subject: [PATCH 7/8] tegra: sysupgrade: use get_image_dd wrapper
>
> This function eliminates false-positive erros emited by dd. Also remove check
> for number of arguments, as that's not needed anymore.
>
> Signed-off-by: Tomasz Maciej Nowak
> ---
> .../linux/tegra/base-files/lib/upgrade/platform.sh | 14 ++
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/target/linux/tegra/base-files/lib/upgrade/platform.sh
> b/target/linux/tegra/base-files/lib/upgrade/platform.sh
> index 5c729de1a4b5..715d1c1b8046 100644
> --- a/target/linux/tegra/base-files/lib/upgrade/platform.sh
> +++ b/target/linux/tegra/base-files/lib/upgrade/platform.sh
> @@ -3,8 +3,6 @@ REQUIRE_IMAGE_METADATA=1
> platform_check_image() {
> local diskdev partdev diff
>
> - [ "$#" -gt 1 ] && return 1
> -
I will merge this patch without the argument number change for now.
Please submit that one separately if the rest is in master.
Best
Adrian
> export_bootdevice && export_partdevice diskdev 0 || {
> v "Unable to determine upgrade device"
> return 1
> @@ -13,7 +11,7 @@ platform_check_image() {
> get_partitions "/dev/$diskdev" bootdisk
>
> #extract the boot sector from the image
> - get_image "$@" | dd of=/tmp/image.bs count=1 bs=512b
> 2>/dev/null
> + get_image_dd "$1" of=/tmp/image.bs count=1 bs=512b
>
> get_partitions /tmp/image.bs image
>
> @@ -53,7 +51,7 @@ platform_do_upgrade() {
> get_partitions "/dev/$diskdev" bootdisk
>
> #extract the boot sector from the image
> - get_image "$@" | dd of=/tmp/image.bs count=1 bs=512b
> + get_image_dd "$1" of=/tmp/image.bs count=1 bs=512b
>
> get_partitions /tmp/image.bs image
>
> @@ -64,7 +62,7 @@ platform_do_upgrade() {
> fi
>
> if [ -n "$diff" ]; then
> - get_image "$@" | dd of="/dev/$diskdev" bs=4096
> conv=fsync
> + get_image_dd "$1" of="/dev/$diskdev" bs=4096 conv=fsync
>
> # Separate removal and addtion is necessary; otherwise,
> partition 1
> # will be missing if it overlaps with the old partition 2 @@ -
> 75,12 +73,12 @@ platform_do_upgrade() {
> fi
>
> #write uboot image
> - get_image "$@" | dd of="$diskdev" bs=512 skip=1 seek=1
> count=4097 conv=fsync,notrunc
> + get_image_dd "$1" of="$diskdev" bs=512 skip=1 seek=1 count=4097
> +conv=fsync,notrunc
> #iterate over each partition from the image and write it to the boot
> disk
> while read part start size; do
> if export_partdevice partdev $part; then
> v "Writing image to /dev/$partdev..."
> - get_image "$@" | dd of="/dev/$partdev" ibs="512"
> obs=1M skip="$start" count="$size" conv=fsync
> + get_image_dd "$1" of="/dev/$partdev" ibs="512"
> obs=1M skip="$start"
> +count="$size" conv=fsync
> else
> v "Unable to find partition $part device, skipped."
> fi
> @@ -88,5 +86,5 @@ platform_do_upgrade() {
>
> #copy partition uuid
> v "Writing new UUID to /dev/$diskdev..."
> - get_image "$@" | dd of="/dev/$diskdev" bs=1 skip=440 count=4
> seek=440 conv=fsync
> + get_image_dd "$1" of="/dev/$diskdev" bs=1 skip=440 count=4
> seek=440
> +conv=fsync
> }
> --
> 2.29.2
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH v2] tools/sstrip: update to latest version
Hi, > -Original Message- > From: Paul Spooren [mailto:m...@aparcar.org] > Sent: Mittwoch, 25. November 2020 19:21 > To: Rui Salvaterra ; openwrt- > de...@lists.openwrt.org > Cc: freif...@adrianschmutzler.de > Subject: Re: [PATCH v2] tools/sstrip: update to latest version > > On Wed Nov 25, 2020 at 6:48 AM HST, Rui Salvaterra wrote: > > Drop our local sstrip copy and use the current ELFKickers upstream > > version. > > > > Patch the original makefile in order to avoid building elftoc, since > > it fails with musl's elf.h. This is fine, since we only need sstrip > > anyway. > > > > Finally, add the possibility to pass additional arguments to sstrip > > and pass -z (remove trailing zeros) by default, which matches the > > behaviour of the previous version. > > > > Signed-off-by: Rui Salvaterra > > --- > > Thanks, added to my staging tree. > > > v2: squshed all changes in a single patch. > > > > Although the upstream project is called ELFKickers, I haven't changed > > PKG_NAME. > > Should we do it, or leave it as it is? > > I'd keep it as sstrip as we do not use the other tools. Then make sure you _change_ it back. :-) Best Adrian > > > > config/Config-build.in | 8 + > > rules.mk | 2 +- > > tools/sstrip/Makefile | 15 +- > > .../001-disable-elftoc-compilation.patch | 28 ++ > > tools/sstrip/src/sstrip.c | 466 -- > > 5 files changed, 45 insertions(+), 474 deletions(-) create mode 100644 > > tools/sstrip/patches/001-disable-elftoc-compilation.patch > > delete mode 100644 tools/sstrip/src/sstrip.c > > > > diff --git a/config/Config-build.in b/config/Config-build.in index > > 8e12199cbd..3448d46726 100644 > > --- a/config/Config-build.in > > +++ b/config/Config-build.in > > @@ -182,6 +182,14 @@ menu "Global build settings" > > help > > Specifies arguments passed to the strip command when stripping binaries. > > > > + config SSTRIP_ARGS > > + string > > + prompt "Sstrip arguments" > > + depends on USE_SSTRIP > > + default "-z" > > + help > > + Specifies arguments passed to the sstrip command when stripping > > binaries. > > + > > config STRIP_KERNEL_EXPORTS > > bool "Strip unnecessary exports from the kernel image" > > help > > diff --git a/rules.mk b/rules.mk > > index e416126030..5c1c141c11 100644 > > --- a/rules.mk > > +++ b/rules.mk > > @@ -328,7 +328,7 @@ else > > STRIP:=$(TARGET_CROSS)strip $(call qstrip,$(CONFIG_STRIP_ARGS)) else > > ifneq ($(CONFIG_USE_SSTRIP),) > > - STRIP:=$(STAGING_DIR_HOST)/bin/sstrip > > + STRIP:=$(STAGING_DIR_HOST)/bin/sstrip $(call > > qstrip,$(CONFIG_SSTRIP_ARGS)) > > endif > > endif > > RSTRIP= \ > > diff --git a/tools/sstrip/Makefile b/tools/sstrip/Makefile index > > bab172a95a..590d183db0 100644 > > --- a/tools/sstrip/Makefile > > +++ b/tools/sstrip/Makefile > > @@ -6,18 +6,19 @@ > > # > > include $(TOPDIR)/rules.mk > > > > -PKG_NAME:=sstrip > > -PKG_VERSION:=2.0 > > +PKG_NAME:=ELFkickers > > +PKG_VERSION:=3.1a > > + > > > +PKG_SOURCE_URL:=https://www.muppetlabs.com/~breadbox/pub/softw > are > > +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz > > > +PKG_HASH:=06430880aaf4919c5f99fc629da7000347421668c2cf32bced2d401 > aac2 > > +76508 > > + > > PKG_RELEASE:=1 > > > > include $(INCLUDE_DIR)/host-build.mk > > > > -define Host/Compile > > - $(HOSTCC) $(HOST_CFLAGS) -include endian.h -o > > $(HOST_BUILD_DIR)/sstrip src/sstrip.c -endef > > - > > define Host/Install > > - $(CP) $(HOST_BUILD_DIR)/sstrip $(STAGING_DIR_HOST)/bin/ > > + $(CP) $(HOST_BUILD_DIR)/bin/sstrip $(STAGING_DIR_HOST)/bin/ > > endef > > > > define Host/Clean > > diff --git a/tools/sstrip/patches/001-disable-elftoc-compilation.patch > > b/tools/sstrip/patches/001-disable-elftoc-compilation.patch > > new file mode 100644 > > index 00..787c51ce5b > > --- /dev/null > > +++ b/tools/sstrip/patches/001-disable-elftoc-compilation.patch > > @@ -0,0 +1,28 @@ > > +From: Rui Salvaterra > > +Subject: sstrip: don't try to compile elftoc > > + > > +We only need sstrip itself and elftoc doesn't compile with musl's > > elf.h, so > > +disable the elftoc compilation in the makefile. > > + > > +Signed-off-by: Rui Salvaterra > > +--- > > + > > +--- a/Makefile > > b/Makefile > > +@@ -2,7 +2,7 @@ > > + > > + prefix = /usr/local > > + > > +-PROGRAMS = elfls objres rebind sstrip elftoc ebfc infect > > ++PROGRAMS = elfls objres rebind sstrip ebfc infect > > + > > + all: $(PROGRAMS) > > + > > +@@ -19,7 +19,6 @@ elfls: bin/elfls doc/elfls.1 > > + objres: bin/objres doc/objres.1 > > + rebind: bin/rebind doc/rebind.1 > > + sstrip: bin/sstrip doc/sstrip.1 > > +-elftoc: bin/elftoc doc/elftoc.1 > > + ebfc: bin/ebfc doc/ebfc.1 > > + infect: bin/infect doc/infect.1 > > + > > diff --git a/tools/sstrip/src/sstrip.c b/tools/sstrip/src/sstrip.c > > deleted file mode 100644 index 12cf12e095..00 > > --- a/tools/sstrip/src/sstrip.c > > +++ /dev/null > > @@ -1,466 +0,0 @@ > > -/* http://www.muppetlabs.com/~breadbox/software/elfkickers.html */ > > - > > -/* sstrip: Copyright (C) 1999-2001 by Brian Raiter, unde
RE: [PATCH v2] wireguard: Make IPv6 addrs available for automatic prefix assignment
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Daniel Gröber
> Sent: Mittwoch, 25. November 2020 18:47
> To: openwrt-devel@lists.openwrt.org
> Subject: [PATCH v2] wireguard: Make IPv6 addrs available for automatic
> prefix assignment
>
> Currently when assigning IPv6 addresses with large prefixes to a wireguard
> interface, like
>
> config interface 'wg'
> option proto 'wireguard'
> list addresses 'fd::/48'
>
> and having, say, a LAN interface such as
>
> config interface 'lan'
> option proto 'static'
> option ip6assign '60'
>
> as is default the interface does not automatically receive the wg interface's
> prefix.
>
> For this to happen the proto needs to use proto_add_ipv6_prefix to register
> the fact that a prefix is available for assignment which is simple enough.
>
> Note that the addresses configured here usually include a non-zero host part
> but currently netifd handles this poorly when more than one interface
> should receive a sub-prefix.
>
> The required fix can be found in "[PATCH netifd] interface-ip: Normalise
> prefix address using netmask before using it" (Message-Id:
> <20201125173536.1175-1-d...@darkboxed.org>)
This should not land in the final commit message. To make sure of that, and
have it in patchwork anyway, please add a line with only "---" after your
Signed-off-by and then add anything like that after that line.
Apart from that, please also bump the PKG_RELEASE for wireguard-tools for any
change of the content.
So, I fear this will need a v3. ;-)
Best
Adrian
>
> Signed-off-by: Daniel Gröber
> ---
> package/network/utils/wireguard-tools/files/wireguard.sh | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/package/network/utils/wireguard-tools/files/wireguard.sh
> b/package/network/utils/wireguard-tools/files/wireguard.sh
> index 63261aea71..a18d09eaed 100644
> --- a/package/network/utils/wireguard-tools/files/wireguard.sh
> +++ b/package/network/utils/wireguard-tools/files/wireguard.sh
> @@ -151,6 +151,7 @@ proto_wireguard_setup() {
> case "${address}" in
> *:*/*)
> proto_add_ipv6_address "${address%%/*}"
> "${address##*/}"
> + proto_add_ipv6_prefix "${address}"
> ;;
> *.*/*)
> proto_add_ipv4_address "${address%%/*}"
> "${address##*/}"
> --
> 2.20.1
>
> v2: Remove netifd patch and submit it separately.
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH v2] wireguard: Make IPv6 addrs available for automatic prefix assignment
Hi, > > This should not land in the final commit message. To make sure of that, and > have it in patchwork anyway, please add a line with only "---" after your > Signed-off-by and then add anything like that after that line. > > Are you mainly talking about the message-id bit or about the entire two > paragraphs about the netifd problem? > > If the first one I would still like to at least have some kind of linkage to > the fix > commit in the commit message here. I figured since this hasn't been > comitted yet the msgid is the next best thing. > I'm talking about changing " [...] Note that the addresses configured here usually include a non-zero host part but currently netifd handles this poorly when more than one interface should receive a sub-prefix. The required fix can be found in "[PATCH netifd] interface-ip: Normalise prefix address using netmask before using it" (Message-Id: <20201125173536.1175-1-d...@darkboxed.org>) Signed-off-by: Daniel Gröber " into " [...] Note that the addresses configured here usually include a non-zero host part but currently netifd handles this poorly when more than one interface should receive a sub-prefix. Signed-off-by: Daniel Gröber --- The required fix can be found in "[PATCH netifd] interface-ip: Normalise prefix address using netmask before using it" (Message-Id: <20201125173536.1175-1-d...@darkboxed.org>) " Best Adrian openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] ath79: remove num-chipselects from SPI controller
The num-chipselects property is only valid for bit-banged spi-gpio [1].
For the generic SPI controller bindings, num-cs would be the correct
property [2].
Since the value does not seem to be required anyway, though, let's
just remove it.
[1]
https://www.kernel.org/doc/Documentation/devicetree/bindings/spi/spi-gpio.yaml
[2]
https://www.kernel.org/doc/Documentation/devicetree/bindings/spi/spi-controller.yaml
Signed-off-by: Adrian Schmutzler
---
target/linux/ath79/dts/ar9330_dlink_dir-505.dts | 1 -
target/linux/ath79/dts/ar9330_glinet_gl-ar150.dts| 2 --
target/linux/ath79/dts/ar9331_8dev_carambola2.dts| 1 -
target/linux/ath79/dts/ar9331_embeddedwireless_dorin.dts | 2 --
target/linux/ath79/dts/ar9331_etactica_eg200.dts | 1 -
target/linux/ath79/dts/ar9331_glinet_gl-mifi.dts | 2 --
target/linux/ath79/dts/ar9331_tplink_tl-mr3020-v1.dts| 2 --
target/linux/ath79/dts/ar9331_tplink_tl-mr3040-v2.dts| 2 --
target/linux/ath79/dts/ar9344_zbtlink_zbt-wd323.dts | 1 -
9 files changed, 14 deletions(-)
diff --git a/target/linux/ath79/dts/ar9330_dlink_dir-505.dts
b/target/linux/ath79/dts/ar9330_dlink_dir-505.dts
index 15e29f552e..574165b748 100644
--- a/target/linux/ath79/dts/ar9330_dlink_dir-505.dts
+++ b/target/linux/ath79/dts/ar9330_dlink_dir-505.dts
@@ -88,7 +88,6 @@
};
&spi {
- num-chipselects = <1>;
status = "okay";
flash@0 {
diff --git a/target/linux/ath79/dts/ar9330_glinet_gl-ar150.dts
b/target/linux/ath79/dts/ar9330_glinet_gl-ar150.dts
index 26b3b3f04c..20c9a8fdd4 100644
--- a/target/linux/ath79/dts/ar9330_glinet_gl-ar150.dts
+++ b/target/linux/ath79/dts/ar9330_glinet_gl-ar150.dts
@@ -79,8 +79,6 @@
&spi {
status = "okay";
- num-chipselects = <1>;
-
flash@0 {
compatible = "jedec,spi-nor";
spi-max-frequency = <5000>;
diff --git a/target/linux/ath79/dts/ar9331_8dev_carambola2.dts
b/target/linux/ath79/dts/ar9331_8dev_carambola2.dts
index 85e70495fc..42193f857c 100644
--- a/target/linux/ath79/dts/ar9331_8dev_carambola2.dts
+++ b/target/linux/ath79/dts/ar9331_8dev_carambola2.dts
@@ -63,7 +63,6 @@
};
&spi {
- num-chipselects = <0>;
status = "okay";
flash@0 {
diff --git a/target/linux/ath79/dts/ar9331_embeddedwireless_dorin.dts
b/target/linux/ath79/dts/ar9331_embeddedwireless_dorin.dts
index 9303121408..12f1e93d44 100644
--- a/target/linux/ath79/dts/ar9331_embeddedwireless_dorin.dts
+++ b/target/linux/ath79/dts/ar9331_embeddedwireless_dorin.dts
@@ -59,8 +59,6 @@
&spi {
status = "okay";
- num-chipselects = <1>;
-
flash@0 {
compatible = "jedec,spi-nor";
spi-max-frequency = <5000>;
diff --git a/target/linux/ath79/dts/ar9331_etactica_eg200.dts
b/target/linux/ath79/dts/ar9331_etactica_eg200.dts
index 0d7b7cfb84..e6feb54fcd 100644
--- a/target/linux/ath79/dts/ar9331_etactica_eg200.dts
+++ b/target/linux/ath79/dts/ar9331_etactica_eg200.dts
@@ -83,7 +83,6 @@
};
&spi {
- num-chipselects = <1>;
status = "okay";
flash@0 {
diff --git a/target/linux/ath79/dts/ar9331_glinet_gl-mifi.dts
b/target/linux/ath79/dts/ar9331_glinet_gl-mifi.dts
index d62bdd9d67..67b587ab6e 100644
--- a/target/linux/ath79/dts/ar9331_glinet_gl-mifi.dts
+++ b/target/linux/ath79/dts/ar9331_glinet_gl-mifi.dts
@@ -87,8 +87,6 @@
&spi {
status = "okay";
- num-chipselects = <1>;
-
flash@0 {
compatible = "jedec,spi-nor";
spi-max-frequency = <3300>;
diff --git a/target/linux/ath79/dts/ar9331_tplink_tl-mr3020-v1.dts
b/target/linux/ath79/dts/ar9331_tplink_tl-mr3020-v1.dts
index 7c52ae1617..e9533553a1 100644
--- a/target/linux/ath79/dts/ar9331_tplink_tl-mr3020-v1.dts
+++ b/target/linux/ath79/dts/ar9331_tplink_tl-mr3020-v1.dts
@@ -110,8 +110,6 @@
&spi {
status = "okay";
- num-chipselects = <1>;
-
/* Spansion S25FL032PIF SPI flash */
flash@0 {
compatible = "jedec,spi-nor";
diff --git a/target/linux/ath79/dts/ar9331_tplink_tl-mr3040-v2.dts
b/target/linux/ath79/dts/ar9331_tplink_tl-mr3040-v2.dts
index da04aad6cb..c5f7a4fe76 100644
--- a/target/linux/ath79/dts/ar9331_tplink_tl-mr3040-v2.dts
+++ b/target/linux/ath79/dts/ar9331_tplink_tl-mr3040-v2.dts
@@ -106,8 +106,6 @@
&spi {
status = "okay";
- num-chipselects = <1>;
-
flash@0 {
compatible = "jedec,spi-nor";
spi-max-frequency = <5000>;
diff --git a/target/linux/ath79/dts/ar9344_zbtlink_zbt-wd323.dts
b/target/linux/ath79/dts/ar9344_zbtlink_zbt-wd323.dts
index f2cb35eae9..5f24bf23d6 100644
--- a/target/linux/ath79/dts/ar9344_zbtlink_zbt-wd323.dts
+
[PATCH] ath79: drop num-cs for SPI controller
None of the spi drivers on ath79 uses the num-cs property. Cc: Chuanhong Guo Signed-off-by: Adrian Schmutzler --- target/linux/ath79/dts/ar1022_iodata_wn-ag300dgr.dts | 2 -- target/linux/ath79/dts/ar1022_sitecom_wlr-7100.dts | 2 -- target/linux/ath79/dts/ar7161_adtran_bsap1880.dtsi | 2 -- target/linux/ath79/dts/ar7161_aruba_ap-105.dts | 2 -- target/linux/ath79/dts/ar7161_buffalo_wzr-hp-ag300h.dtsi | 1 - target/linux/ath79/dts/ar7161_dlink_dir-825-b1.dts | 2 -- target/linux/ath79/dts/ar7161_jjplus_ja76pf2.dts | 2 -- target/linux/ath79/dts/ar7161_meraki_mr16.dts| 1 - target/linux/ath79/dts/ar7161_netgear_wndr.dtsi | 2 -- target/linux/ath79/dts/ar7161_siemens_ws-ap3610.dts | 2 -- target/linux/ath79/dts/ar7161_ubnt_routerstation.dtsi| 1 - target/linux/ath79/dts/ar7240_buffalo_whr-g301n.dts | 2 -- target/linux/ath79/dts/ar7240_dlink_dir-615-e4.dts | 2 -- target/linux/ath79/dts/ar7240_engenius_enh202-v1.dts | 2 -- target/linux/ath79/dts/ar7240_netgear_wnr1000-v2.dts | 2 -- target/linux/ath79/dts/ar7240_netgear_wnr612-v2.dtsi | 2 -- target/linux/ath79/dts/ar7240_tplink.dtsi| 2 -- target/linux/ath79/dts/ar7241_netgear_wnr2000-v3.dts | 2 -- target/linux/ath79/dts/ar7241_netgear_wnr2200.dtsi | 1 - target/linux/ath79/dts/ar7241_tplink.dtsi| 2 -- target/linux/ath79/dts/ar7241_tplink_tl-wr842n-v1.dts| 2 -- target/linux/ath79/dts/ar7241_ubnt_unifi.dts | 2 -- target/linux/ath79/dts/ar7242_avm_fritz300e.dts | 2 -- target/linux/ath79/dts/ar7242_buffalo_wzr-bhr.dtsi | 1 - target/linux/ath79/dts/ar7242_buffalo_wzr-hp-g302h-a1a0.dts | 1 - target/linux/ath79/dts/ar7242_tplink_tl-wr2543-v1.dts| 2 -- target/linux/ath79/dts/ar7242_ubnt_sw.dtsi | 2 -- target/linux/ath79/dts/ar724x_ubnt_xm.dtsi | 2 -- target/linux/ath79/dts/ar9132_tplink_tl-wa901nd-v2.dts | 2 -- target/linux/ath79/dts/ar9132_tplink_tl-wr1043nd-v1.dts | 2 -- target/linux/ath79/dts/ar9330_pqi_air-pen.dts| 2 -- target/linux/ath79/dts/ar9331_alfa-network_ap121f.dtsi | 2 -- target/linux/ath79/dts/ar9331_arduino_yun.dts| 2 -- target/linux/ath79/dts/ar9331_glinet_6408.dts| 2 -- target/linux/ath79/dts/ar9331_glinet_6416.dts| 2 -- target/linux/ath79/dts/ar9331_hak5_lan-turtle.dtsi | 2 -- target/linux/ath79/dts/ar9331_hak5_wifi-pineapple-nano.dts | 2 -- target/linux/ath79/dts/ar9331_pisen_wmm003n.dts | 1 - target/linux/ath79/dts/ar9331_tplink_tl-wr703n_tl-mr10u.dtsi | 2 -- target/linux/ath79/dts/ar9331_tplink_tl-wr710n-8m.dtsi | 2 -- target/linux/ath79/dts/ar9331_tplink_tl-wr741nd-v4.dtsi | 2 -- target/linux/ath79/dts/ar9341_engenius_eap300-v2.dts | 2 -- target/linux/ath79/dts/ar9341_engenius_ens202ext-v1.dts | 2 -- target/linux/ath79/dts/ar9341_pcs_cr3000.dts | 2 -- target/linux/ath79/dts/ar9341_pisen_wmb001n.dts | 2 -- target/linux/ath79/dts/ar9341_tplink_tl-mr3420-v2.dts| 2 -- target/linux/ath79/dts/ar9341_tplink_tl-wa.dtsi | 2 -- target/linux/ath79/dts/ar9341_tplink_tl-wr841-v8.dts | 2 -- target/linux/ath79/dts/ar9341_tplink_tl-wr842n-v2.dts| 2 -- target/linux/ath79/dts/ar9342_iodata_etg3-r.dts | 2 -- target/linux/ath79/dts/ar9342_ubnt_wa.dtsi | 1 - target/linux/ath79/dts/ar9342_ubnt_xw.dtsi | 1 - target/linux/ath79/dts/ar9344_aerohive_hiveap-121.dts| 2 -- target/linux/ath79/dts/ar9344_alfa-network_n5q.dts | 2 -- target/linux/ath79/dts/ar9344_comfast_cf-e120a-v3.dts| 2 -- target/linux/ath79/dts/ar9344_compex_wpj344-16m.dts | 2 -- target/linux/ath79/dts/ar9344_devolo_magic-2-wifi.dts| 2 -- target/linux/ath79/dts/ar9344_dlink_dir-8x5.dtsi | 1 - target/linux/ath79/dts/ar9344_enterasys_ws-ap3705i.dts | 1 - .../linux/ath79/dts/ar9344_mikrotik_routerboard-sxt-5n.dtsi | 2 -- target/linux/ath79/dts/ar9344_ocedo_raccoon.dts | 2 -- target/linux/ath79/dts/ar9344_pcs_cap324.dts | 2 -- target/linux/ath79/dts/ar9344_pcs_cr5000.dts | 2 -- target/linux/ath79/dts/ar9344_qihoo_c301.dts | 5 ++--- target/linux/ath79/dts/ar9344_qxwlan_e750x.dtsi | 2 -- target/linux/ath79/dts/ar9344_samsung_wam250.dts | 2 -- target/linux/ath79/dts/ar9344_teltonika_rut955.dts | 1 - target/linux/ath79/dts/ar9344_teltonika_rut9xx.dtsi | 2 +- target/linux/ath79/dts/ar9344_tplink_cpe.dtsi| 2 -- target/linux/ath79/dts/ar9344_tplink_tl-wdr.dtsi | 2 -- target/linux/ath79/dts/ar9344_ubnt_unifi-ap-pro.dts
RE: Octeon snapshot builds missing EdgeRouter artifacts
Hi, > -Original Message- > From: Raylynn Knight [mailto:raykni...@me.com] > Sent: Dienstag, 1. Dezember 2020 06:58 > To: OpenWrt Development List > Subject: Octeon snapshot builds missing EdgeRouter artifacts > > The snapshot builds for Octeon are missing the artifacts for the EdgeRouter > and EdgeRouter Pro devices (artifacts should be identical). I couldn’t figure > out exactly what is wrong with the make file, but if I build locally and > select: > > * Target System (Cavium Networks Octeon) > * Target Profile (Multiple Devices) > * Target Devices > (*) Enable all profiles by default > > All of the profiles except the Ubiquiti EdgeRouter profile are selected. So > whatever mechanism is used to determine all profiles is missing the Ubiquiti > EdgeRouter profile. The EdgeRouter is broken at the moment and can't be fixed easily, so it was disabled by default: https://github.com/openwrt/openwrt/commit/3824fa26d256d162fc0e02e46714eda7816cae4a If you want to build it, you should build this device only with the option named in the commit description. Best Adrian > > Hoping someone more familiar with the build system constructs can fix this. > > Thank you, > Ray > openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] ramips: drop redundant status for gpio/gpio0
The first gpio controller (gpio or gpio0) is always enabled by
default in the SoC DTSI files. No need to set status=okay in the
device DTS files a second time.
Remove the redundant statements.
Signed-off-by: Adrian Schmutzler
---
target/linux/ramips/dts/mt7620a_alfa-network_tube-e4g.dts | 4
target/linux/ramips/dts/mt7620a_bdcom_wap2100-sk.dts | 4
target/linux/ramips/dts/mt7620a_dlink_dch-m225.dts| 4
target/linux/ramips/dts/mt7620a_dlink_dir-510l.dts| 4
target/linux/ramips/dts/mt7620a_dovado_tiny-ac.dts| 4
target/linux/ramips/dts/mt7620a_glinet_gl-mt300a.dts | 4
target/linux/ramips/dts/mt7620a_glinet_gl-mt300n.dts | 4
target/linux/ramips/dts/mt7620a_glinet_gl-mt750.dts | 4
target/linux/ramips/dts/mt7620a_head-weblink_hdrm200.dts | 4
target/linux/ramips/dts/mt7620a_hiwifi_hc5x61.dtsi| 4
target/linux/ramips/dts/mt7620a_lava_lr-25g001.dts| 4
target/linux/ramips/dts/mt7620a_lenovo_newifi-y1.dtsi | 4
target/linux/ramips/dts/mt7620a_netgear_ex3x00_ex61xx.dtsi| 4
target/linux/ramips/dts/mt7620a_phicomm_psg1218.dtsi | 4
target/linux/ramips/dts/mt7620a_planex_cs-qr10.dts| 4
.../linux/ramips/dts/mt7620a_ralink_mt7620a-mt7610e-evb.dts | 4
target/linux/ramips/dts/mt7620a_xiaomi_miwifi-mini.dts| 4
target/linux/ramips/dts/mt7620a_youku_yk1.dts | 4
target/linux/ramips/dts/mt7620a_yukai_bocco.dts | 4
target/linux/ramips/dts/mt7620a_zbtlink_zbt-ape522ii.dts | 4
target/linux/ramips/dts/mt7620a_zbtlink_zbt-we826.dtsi| 4
target/linux/ramips/dts/mt7620a_zte_q7.dts| 4
target/linux/ramips/dts/mt7620n_comfast_cf-wr800n.dts | 4
target/linux/ramips/dts/mt7620n_kingston_mlw221.dts | 4
target/linux/ramips/dts/mt7620n_kingston_mlwg2.dts| 4
target/linux/ramips/dts/mt7620n_vonets_var11n-300.dts | 4
target/linux/ramips/dts/mt7621_telco-electronics_x1.dts | 4
target/linux/ramips/dts/mt7621_unielec_u7621-06.dtsi | 4
target/linux/ramips/dts/rt2880_airlink101_ar670w.dts | 4
target/linux/ramips/dts/rt2880_airlink101_ar725w.dts | 4
target/linux/ramips/dts/rt2880_asus_rt-n15.dts| 4
target/linux/ramips/dts/rt2880_belkin_f5d8235-v1.dts | 4
target/linux/ramips/dts/rt2880_buffalo_wli-tx4-ag300n.dts | 4
target/linux/ramips/dts/rt2880_buffalo_wzr-agl300nh.dts | 4
target/linux/ramips/dts/rt2880_dlink_dap-1522-a1.dts | 4
target/linux/ramips/dts/rt2880_ralink_v11st-fe.dts| 4
target/linux/ramips/dts/rt3050_allnet_all0256n.dtsi | 4
target/linux/ramips/dts/rt3050_alphanetworks_asl26555.dtsi| 4
target/linux/ramips/dts/rt3352_allnet_all5002.dts | 4
target/linux/ramips/dts/rt5350_airlive_air3gii.dts| 4
target/linux/ramips/dts/rt5350_allnet_all5003.dts | 4
target/linux/ramips/dts/rt5350_easyacc_wizard-8800.dts| 4
target/linux/ramips/dts/rt5350_hootoo_ht-tm02.dts | 4
target/linux/ramips/dts/rt5350_nixcore_x1.dtsi| 4
target/linux/ramips/dts/rt5350_omnima_miniembplug.dts | 4
45 files changed, 180 deletions(-)
diff --git a/target/linux/ramips/dts/mt7620a_alfa-network_tube-e4g.dts
b/target/linux/ramips/dts/mt7620a_alfa-network_tube-e4g.dts
index 42047390b0..30a0201c39 100644
--- a/target/linux/ramips/dts/mt7620a_alfa-network_tube-e4g.dts
+++ b/target/linux/ramips/dts/mt7620a_alfa-network_tube-e4g.dts
@@ -106,10 +106,6 @@
mtd-mac-address = <&factory 0x28>;
};
-&gpio0 {
- status = "okay";
-};
-
&gpio1 {
status = "okay";
};
diff --git a/target/linux/ramips/dts/mt7620a_bdcom_wap2100-sk.dts
b/target/linux/ramips/dts/mt7620a_bdcom_wap2100-sk.dts
index 07586f6922..fc2b74db2a 100644
--- a/target/linux/ramips/dts/mt7620a_bdcom_wap2100-sk.dts
+++ b/target/linux/ramips/dts/mt7620a_bdcom_wap2100-sk.dts
@@ -96,10 +96,6 @@
};
};
-&gpio0 {
- status = "okay";
-};
-
&gpio1 {
status = "okay";
};
diff --git a/target/linux/ramips/dts/mt7620a_dlink_dch-m225.dts
b/target/linux/ramips/dts/mt7620a_dlink_dch-m225.dts
index bbd193b4ac..63667da281 100644
--- a/target/linux/ramips/dts/mt7620a_dlink_dch-m225.dts
+++ b/target/linux/ramips/dts/mt7620a_dlink_dch-m225.dts
@@ -69,10 +69,6 @@
};
};
-&gpio0 {
- status = "okay";
-};
-
&gpio1 {
status = "okay";
};
diff --git a/target/linux/ramips/dts/mt7620a_dlink_dir-510l.dts
b/target/linux/ramips/dts/mt7620a_dlink_dir-510l.dts
index 6ad3f41560..f4db67648a 100644
--- a/targ
[PATCH 1/2] ramips: simplify status for ehci/ohci on mt7628 TP-Link devices
At the moment, ehci/ohci is enabled in mt7628an SoC DTSI, then
disabled in the TP-Link-specific DTSI files, and finally enabled
again in the DTS files of the devices needing it.
This on-off-on scheme is hard to grasp on a quick look. Thus, this
patch drops the status in the TP-Link-specific DTSI files, having
the TP-Link devices treated like the rest of mt7628an DTSes, i.e.
ehci/ohci is enabled by default and needs to be disabled explicitly
where needed.
Signed-off-by: Adrian Schmutzler
---
.../linux/ramips/dts/mt7628an_tplink_8m-split-uboot.dtsi | 8
target/linux/ramips/dts/mt7628an_tplink_8m.dtsi | 8
target/linux/ramips/dts/mt7628an_tplink_archer-c20-v4.dts | 8
target/linux/ramips/dts/mt7628an_tplink_archer-c20-v5.dts | 8
target/linux/ramips/dts/mt7628an_tplink_archer-c50-v3.dts | 8
target/linux/ramips/dts/mt7628an_tplink_archer-c50-v4.dts | 8
target/linux/ramips/dts/mt7628an_tplink_tl-mr3420-v5.dts | 8
target/linux/ramips/dts/mt7628an_tplink_tl-mr6400-v4.dts | 8
target/linux/ramips/dts/mt7628an_tplink_tl-mr6400-v5.dts | 8
target/linux/ramips/dts/mt7628an_tplink_tl-wa801nd-v5.dts | 8
target/linux/ramips/dts/mt7628an_tplink_tl-wr802n-v4.dts | 8
target/linux/ramips/dts/mt7628an_tplink_tl-wr840n-v4.dts | 8
target/linux/ramips/dts/mt7628an_tplink_tl-wr841n-v13.dts | 8
target/linux/ramips/dts/mt7628an_tplink_tl-wr842n-v5.dts | 8
target/linux/ramips/dts/mt7628an_tplink_tl-wr850n-v2.dts | 8
target/linux/ramips/dts/mt7628an_tplink_tl-wr902ac-v3.dts | 8
16 files changed, 72 insertions(+), 56 deletions(-)
diff --git a/target/linux/ramips/dts/mt7628an_tplink_8m-split-uboot.dtsi
b/target/linux/ramips/dts/mt7628an_tplink_8m-split-uboot.dtsi
index 7f7e5ac8b4..b6ce7b1f56 100644
--- a/target/linux/ramips/dts/mt7628an_tplink_8m-split-uboot.dtsi
+++ b/target/linux/ramips/dts/mt7628an_tplink_8m-split-uboot.dtsi
@@ -72,14 +72,6 @@
};
};
-&ehci {
- status = "disabled";
-};
-
-&ohci {
- status = "disabled";
-};
-
&wmac {
status = "okay";
mtd-mac-address = <&rom 0xf100>;
diff --git a/target/linux/ramips/dts/mt7628an_tplink_8m.dtsi
b/target/linux/ramips/dts/mt7628an_tplink_8m.dtsi
index b134badb15..2faf8a87fe 100644
--- a/target/linux/ramips/dts/mt7628an_tplink_8m.dtsi
+++ b/target/linux/ramips/dts/mt7628an_tplink_8m.dtsi
@@ -53,14 +53,6 @@
};
};
-&ehci {
- status = "disabled";
-};
-
-&ohci {
- status = "disabled";
-};
-
&wmac {
status = "okay";
mtd-mac-address = <&factory 0xf100>;
diff --git a/target/linux/ramips/dts/mt7628an_tplink_archer-c20-v4.dts
b/target/linux/ramips/dts/mt7628an_tplink_archer-c20-v4.dts
index f6321bb15f..58743db6b4 100644
--- a/target/linux/ramips/dts/mt7628an_tplink_archer-c20-v4.dts
+++ b/target/linux/ramips/dts/mt7628an_tplink_archer-c20-v4.dts
@@ -69,6 +69,14 @@
};
};
+&ehci {
+ status = "disabled";
+};
+
+&ohci {
+ status = "disabled";
+};
+
&wmac {
mtd-mac-address-increment = <(-2)>;
};
diff --git a/target/linux/ramips/dts/mt7628an_tplink_archer-c20-v5.dts
b/target/linux/ramips/dts/mt7628an_tplink_archer-c20-v5.dts
index 7969bfc733..d76ce34ca9 100644
--- a/target/linux/ramips/dts/mt7628an_tplink_archer-c20-v5.dts
+++ b/target/linux/ramips/dts/mt7628an_tplink_archer-c20-v5.dts
@@ -71,6 +71,14 @@
};
};
+&ehci {
+ status = "disabled";
+};
+
+&ohci {
+ status = "disabled";
+};
+
&state_default {
gpio {
groups = "i2s", "gpio", "refclk", "p0led_an", "p1led_an",
diff --git a/target/linux/ramips/dts/mt7628an_tplink_archer-c50-v3.dts
b/target/linux/ramips/dts/mt7628an_tplink_archer-c50-v3.dts
index ea53870eeb..4966d56a68 100644
--- a/target/linux/ramips/dts/mt7628an_tplink_archer-c50-v3.dts
+++ b/target/linux/ramips/dts/mt7628an_tplink_archer-c50-v3.dts
@@ -67,6 +67,14 @@
};
};
+&ehci {
+ status = "disabled";
+};
+
+&ohci {
+ status = "disabled";
+};
+
&state_default {
gpio {
groups = "i2c", "gpio", "p0led_an", "p1led_an", "p2led_an",
diff --git a/target/linux/ramips/dts/mt7628an_tplink_archer-c50-v4.dts
b/target/linux/ramips/dts/mt7628an_tplink_archer-c50-v4.dts
index 4ca0cd61a5..11bf903531 100644
--- a/target/linux/ramips/dts/mt7628an_tplink_archer-c50-v4.dts
+++ b/target/linux/ramips/dts/mt7628an_tplink_archer-c50-v4.dts
@@ -69,6 +69,14 @@
};
};
+&ehci {
+ status = "disabled";
+};
+
+&ohci {
+ status = "disabled";
+};
+
&state_default {
gpio {
[PATCH 2/2] ramips: remove redundant status for USB controllers
mt7621, mt7628an and rt5350 have USB controllers (ehci/ohci or xhci)
enabled by default. Thus, this patch drops redundant status=okay
statements in derived device DTS files.
While at it, also drop an explicit status=okay in mt7621.dtsi, as
this is default.
Note:
For rt5350, about 50 % of the devices enabled ehci/ohci in the DTS
files, and there is actually no device actively disabling it.
It looks like only a few people are aware that the controllers are
enabled by default here.
Signed-off-by: Adrian Schmutzler
---
target/linux/ramips/dts/mt7621.dtsi | 1 -
target/linux/ramips/dts/mt7621_youku_yk-l2.dts| 4
target/linux/ramips/dts/mt7628an_glinet_gl-mt300n-v2.dts | 8
target/linux/ramips/dts/mt7628an_ravpower_rp-wd009.dts| 8
target/linux/ramips/dts/mt7628an_skylab_skw92a.dts| 8
target/linux/ramips/dts/mt7628an_tama_w06.dts | 8
target/linux/ramips/dts/mt7628an_tplink_tl-mr3020-v3.dts | 8
.../linux/ramips/dts/mt7628an_zyxel_keenetic-extra-ii.dts | 8
target/linux/ramips/dts/rt5350_allnet_all5003.dts | 8
target/linux/ramips/dts/rt5350_asiarf_awm002-evb.dtsi | 8
target/linux/ramips/dts/rt5350_dlink_dcs-930l-b1.dts | 8
target/linux/ramips/dts/rt5350_dlink_dir-320-b1.dts | 8
target/linux/ramips/dts/rt5350_easyacc_wizard-8800.dts| 8
target/linux/ramips/dts/rt5350_hame_mpr-a1.dts| 8
target/linux/ramips/dts/rt5350_hame_mpr-a2.dts| 8
target/linux/ramips/dts/rt5350_hilink_hlk-rm04.dts| 8
target/linux/ramips/dts/rt5350_hootoo_ht-tm02.dts | 8
target/linux/ramips/dts/rt5350_intenso_memory2move.dts| 8
target/linux/ramips/dts/rt5350_nexx_wt1520.dtsi | 8
target/linux/ramips/dts/rt5350_nixcore_x1.dtsi| 8
.../linux/ramips/dts/rt5350_olimex_rt5350f-olinuxino.dtsi | 8
target/linux/ramips/dts/rt5350_omnima_miniembplug.dts | 8
target/linux/ramips/dts/rt5350_poray_m3.dts | 8
target/linux/ramips/dts/rt5350_poray_m4.dtsi | 8
target/linux/ramips/dts/rt5350_poray_x5.dts | 8
target/linux/ramips/dts/rt5350_poray_x8.dts | 8
target/linux/ramips/dts/rt5350_tenda_3g150b.dts | 8
target/linux/ramips/dts/rt5350_trendnet_tew-714tru.dts| 8
target/linux/ramips/dts/rt5350_unbranded_a5-v11.dts | 8
target/linux/ramips/dts/rt5350_vocore_vocore.dtsi | 8
target/linux/ramips/dts/rt5350_wansview_ncs601w.dts | 8
target/linux/ramips/dts/rt5350_wiznet_wizfi630a.dts | 8
32 files changed, 245 deletions(-)
diff --git a/target/linux/ramips/dts/mt7621.dtsi
b/target/linux/ramips/dts/mt7621.dtsi
index 1c19545443..7636f9d800 100644
--- a/target/linux/ramips/dts/mt7621.dtsi
+++ b/target/linux/ramips/dts/mt7621.dtsi
@@ -371,7 +371,6 @@
xhci: xhci@1E1C {
#address-cells = <1>;
#size-cells = <0>;
- status = "okay";
compatible = "mediatek,mt8173-xhci";
reg = <0x1e1c 0x1000
diff --git a/target/linux/ramips/dts/mt7621_youku_yk-l2.dts
b/target/linux/ramips/dts/mt7621_youku_yk-l2.dts
index fd4395985c..627188873d 100644
--- a/target/linux/ramips/dts/mt7621_youku_yk-l2.dts
+++ b/target/linux/ramips/dts/mt7621_youku_yk-l2.dts
@@ -63,10 +63,6 @@
status = "okay";
};
-&xhci {
- status = "okay";
-};
-
&spi0 {
status = "okay";
diff --git a/target/linux/ramips/dts/mt7628an_glinet_gl-mt300n-v2.dts
b/target/linux/ramips/dts/mt7628an_glinet_gl-mt300n-v2.dts
index 4ebe0cf11f..c5e0c2e02b 100644
--- a/target/linux/ramips/dts/mt7628an_glinet_gl-mt300n-v2.dts
+++ b/target/linux/ramips/dts/mt7628an_glinet_gl-mt300n-v2.dts
@@ -131,11 +131,3 @@
&uart1 {
status = "okay";
};
-
-&ehci {
- status = "okay";
-};
-
-&ohci {
- status = "okay";
-};
diff --git a/target/linux/ramips/dts/mt7628an_ravpower_rp-wd009.dts
b/target/linux/ramips/dts/mt7628an_ravpower_rp-wd009.dts
index 95d7750be0..6962651e1b 100644
--- a/target/linux/ramips/dts/mt7628an_ravpower_rp-wd009.dts
+++ b/target/linux/ramips/dts/mt7628an_ravpower_rp-wd009.dts
@@ -93,14 +93,6 @@
};
};
-&ehci {
- status = "okay";
-};
-
-&ohci {
- status = "okay";
-};
-
&sdhci {
status = "okay";
};
diff --git a/target/linux/ramips/dts/mt7628an_skylab_skw92a.dts
b/target/linux/ramips/dts/mt7628an_skylab_skw92a.dts
index 111f70a8d5..6e1cb396b8 100644
--- a/target/linux/ramips/dts/mt7628an_skylab_skw92a.dts
+++ b/target/linux/ramips/dts/mt7628an_skylab_skw92a.dts
@@ -97
[RFC PATCH] ramips: do not enable unused GPIO controllers
Several devices enable GPIO controllers not used in the DTS files.
Drop them.
Signed-off-by: Adrian Schmutzler
---
Is it really that simple or am I moving along the wrong path here?
---
target/linux/ramips/dts/mt7620a_engenius_esr600.dts | 4
target/linux/ramips/dts/mt7620a_glinet_gl-mt300a.dts | 4
target/linux/ramips/dts/mt7620a_glinet_gl-mt300n.dts | 4
target/linux/ramips/dts/mt7620a_glinet_gl-mt750.dts | 4
target/linux/ramips/dts/mt7620a_hiwifi_hc5x61.dtsi| 4
target/linux/ramips/dts/mt7620a_microduino_microwrt.dts | 8
target/linux/ramips/dts/mt7620a_ohyeah_oy-0001.dts| 4
target/linux/ramips/dts/mt7620a_planex_cs-qr10.dts| 8
target/linux/ramips/dts/mt7620a_sercomm_na930.dts | 4
target/linux/ramips/dts/mt7620a_xiaomi_miwifi-mini.dts| 4
target/linux/ramips/dts/mt7620a_yukai_bocco.dts | 8
target/linux/ramips/dts/mt7620a_zbtlink_zbt-ape522ii.dts | 8
target/linux/ramips/dts/mt7620n_dlink_dwr-116-a1.dts | 4
target/linux/ramips/dts/mt7620n_elecom_wrh-300cr.dts | 4
target/linux/ramips/dts/mt7620n_nexx_wt3020.dtsi | 4
target/linux/ramips/dts/mt7620n_wrtnode_wrtnode.dts | 8
target/linux/ramips/dts/mt7620n_zbtlink_zbt-cpe102.dts| 8
target/linux/ramips/dts/mt7620n_zbtlink_zbt-wa05.dts | 4
target/linux/ramips/dts/rt3662_edimax_br-6475nd.dts | 4
target/linux/ramips/dts/rt3883_belkin_f9k110x.dtsi| 4
target/linux/ramips/dts/rt5350_easyacc_wizard-8800.dts| 4
target/linux/ramips/dts/rt5350_hame_mpr-a1.dts| 4
.../linux/ramips/dts/rt5350_olimex_rt5350f-olinuxino.dtsi | 4
target/linux/ramips/dts/rt5350_planex_mzk-dp150n.dts | 4
target/linux/ramips/dts/rt5350_tenda_3g150b.dts | 4
target/linux/ramips/dts/rt5350_unbranded_a5-v11.dts | 4
target/linux/ramips/dts/rt5350_wiznet_wizfi630a.dts | 4
27 files changed, 132 deletions(-)
diff --git a/target/linux/ramips/dts/mt7620a_engenius_esr600.dts
b/target/linux/ramips/dts/mt7620a_engenius_esr600.dts
index 807e18d62b..b8fe2f8cdb 100644
--- a/target/linux/ramips/dts/mt7620a_engenius_esr600.dts
+++ b/target/linux/ramips/dts/mt7620a_engenius_esr600.dts
@@ -63,10 +63,6 @@
};
};
-&gpio1 {
- status = "okay";
-};
-
&gpio2 {
status = "okay";
};
diff --git a/target/linux/ramips/dts/mt7620a_glinet_gl-mt300a.dts
b/target/linux/ramips/dts/mt7620a_glinet_gl-mt300a.dts
index 00153fab64..545e11a83f 100644
--- a/target/linux/ramips/dts/mt7620a_glinet_gl-mt300a.dts
+++ b/target/linux/ramips/dts/mt7620a_glinet_gl-mt300a.dts
@@ -62,10 +62,6 @@
};
};
-&gpio1 {
- status = "okay";
-};
-
&gpio2 {
status = "okay";
};
diff --git a/target/linux/ramips/dts/mt7620a_glinet_gl-mt300n.dts
b/target/linux/ramips/dts/mt7620a_glinet_gl-mt300n.dts
index 43dfa0d5f5..575566c5fa 100644
--- a/target/linux/ramips/dts/mt7620a_glinet_gl-mt300n.dts
+++ b/target/linux/ramips/dts/mt7620a_glinet_gl-mt300n.dts
@@ -57,10 +57,6 @@
};
};
-&gpio1 {
- status = "okay";
-};
-
&gpio2 {
status = "okay";
};
diff --git a/target/linux/ramips/dts/mt7620a_glinet_gl-mt750.dts
b/target/linux/ramips/dts/mt7620a_glinet_gl-mt750.dts
index e3189a2f9b..75823787bf 100644
--- a/target/linux/ramips/dts/mt7620a_glinet_gl-mt750.dts
+++ b/target/linux/ramips/dts/mt7620a_glinet_gl-mt750.dts
@@ -57,10 +57,6 @@
};
};
-&gpio1 {
- status = "okay";
-};
-
&gpio2 {
status = "okay";
};
diff --git a/target/linux/ramips/dts/mt7620a_hiwifi_hc5x61.dtsi
b/target/linux/ramips/dts/mt7620a_hiwifi_hc5x61.dtsi
index 06f4054c50..6349ec5365 100644
--- a/target/linux/ramips/dts/mt7620a_hiwifi_hc5x61.dtsi
+++ b/target/linux/ramips/dts/mt7620a_hiwifi_hc5x61.dtsi
@@ -38,10 +38,6 @@
ralink,wdtmux = <1>;
};
-&gpio2 {
- status = "okay";
-};
-
&gpio3 {
status = "okay";
};
diff --git a/target/linux/ramips/dts/mt7620a_microduino_microwrt.dts
b/target/linux/ramips/dts/mt7620a_microduino_microwrt.dts
index b1602a98a1..4307d51424 100644
--- a/target/linux/ramips/dts/mt7620a_microduino_microwrt.dts
+++ b/target/linux/ramips/dts/mt7620a_microduino_microwrt.dts
@@ -28,14 +28,6 @@
};
};
-&gpio2 {
- status = "okay";
-};
-
-&gpio3 {
- status = "okay";
-};
-
&spi0 {
status = "okay";
diff --git a/target/linux/ramips/dts/mt7620a_ohyeah_oy-0001.dts
b/target/linux/ramips/dts/mt7620a_ohyeah_oy-0001.dts
index 908f89d149..07f606fce4 100644
--- a/target/linux/ramips/dts/mt7620a_ohyeah_oy-0001.dts
+++ b/target/linux/ramips/dts/mt7620a_ohyeah_oy-0001.dts
@@ -43,10 +43,6 @@
};
};
-&gpi
RE: Makefile warnings on master branch
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of X Xiao > Sent: Dienstag, 1. Dezember 2020 18:53 > To: openwrt-devel@lists.openwrt.org > Subject: Makefile warnings on master branch > > I did a git pull yesterday and saw the below warnings: > > WARNING: Makefile 'package/feeds/packages/apcupsd/Makefile' has a > dependency on 'libusb-compat', which does not exist > WARNING: Makefile 'package/feeds/packages/avrdude/Makefile' has a > dependency on 'libusb-compat', which does not exist > WARNING: Makefile 'package/feeds/packages/conntrack-tools/Makefile' > has a dependency on 'libnetfilter-cttimeout', which does not > existWARNING: Makefile > 'package/feeds/packages/conntrack-tools/Makefile' has a dependency on > 'libnetfilter-cthelper', which does not exist > WARNING: Makefile 'package/feeds/packages/conntrack-tools/Makefile' > has a dependency on 'libnetfilter-queue', which does not exist > WARNING: Makefile 'package/feeds/packages/conntrack-tools/Makefile' > has a dependency on 'libnetfilter-cttimeout', which does not exist > WARNING: Makefile 'package/feeds/packages/conntrack-tools/Makefile' > has a dependency on 'libnetfilter-cthelper', which does not exist > WARNING: Makefile 'package/feeds/packages/conntrack-tools/Makefile' > has a dependency on 'libnetfilter-queue', which does not exist > WARNING: Makefile 'package/feeds/packages/ulogd/Makefile' has a > dependency on 'libnetfilter-log', which does not exist these packages have been moved from main repo to feeds, so you need to update the feeds (and possibly install the new packages if you have actual dependencies on them). Best Adrian > > Recently related packages are removed from openwrt core base, but those > changes should not lead to warnings like above. How can I get rid of them? > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH] ath79: restore sysupgrade support for ja76pf2 and routerstations
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Tomasz Maciej Nowak
> Sent: Dienstag, 1. Dezember 2020 18:30
> To: openwrt-devel@lists.openwrt.org
> Subject: [PATCH] ath79: restore sysupgrade support for ja76pf2 and
> routerstations
>
> Because the bug described in FS#2428 has been fixed with bf2870c
> ("kernel: fix mtd partition erase < parent_erasesize writes") these devices
> can now safely do sysupgrade. Restore sysupgrade support disabled
> in:
> 0cc87b3 ("ath79: image: disable sysupgrade images for routerstations and
> ja76pf2")
> and
> cc5256a ("ath79: base-files: disable sysupgrade for routerstations and
> ja76pf2")
I'm merging this one with a few minor adjustments.
> +define Build/combined-image
> + sh $(TOPDIR)/scripts/combined-image.sh \
> + "$(IMAGE_KERNEL)" \
> + "$@" \
> + "$@.new"
> + @mv $@.new $@
> +endef
I wonder whether we can merge this with the similar function from ath25 and put
it back into image-commands.mk.
The only difference seems that ath25 uses the $(IMAGE_ROOTFS) argument, while
we use the rootfs set up in $@.
Do you have an opinion on that?
Best
Adrian
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH] ath79: restore sysupgrade support for ja76pf2 and routerstations
> I'm fine with using that command and moving it to image.mk. I'm planing to > move both ja76pf2 and routerstations images to use sysupgrade-tar, after > first ath79-only stable release, so I don't know if we should bother moving > the combine-image command. Ah, then it's probably a waste of time and I won't touch it. Best Adrian openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH 1/2] ath79: add support for Mojo Networks AirTight C-75
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Tomasz Maciej Nowak
> Sent: Dienstag, 1. Dezember 2020 18:36
> To: openwrt-devel@lists.openwrt.org
> Cc: Vladimir Georgievsky
> Subject: [PATCH 1/2] ath79: add support for Mojo Networks AirTight C-75
>
> Mojo Networks AirTight C-75 is a dual-band access point, also sold by
> WatchGuard under name AP320.
>
> Specification
> SoC: Qualcomm Atheros QCA9550
> RAM: 128 MiB DDR2
> Flash: 2x 16 MiB SPI NOR
> WIFI: 2.4 GHz 3T3R integrated
> 5 GHz 3T3R QCA9890 oversized Mini PCIe card
> Ethernet: 2x 10/100/1000 Mbps QCA8334
> port labeled LAN1 is PoE capable (802.3at)
> USB: 1x 2.0
> LEDs: 7x which two are GPIO controlled, four switch controlled, one
> controlled by wireless driver
> Buttons: 1x GPIO controlled
> Serial: RJ-45 port, Cisco pinout
> baud: 115200, parity: none, flow control: none
> JTAG: Yes, pins marked J1 on PCB
>
> Installation
> 1. Prepare TFTP server with OpenWrt initramfs-kernel image.
> 2. Connect to one of LAN ports.
> 3. Connect to serial port.
> 4. Power on the device and when prompted to stop autoboot, hit any key.
> 5. Adjust "ipaddr" and "serverip" addresses in U-Boot environment, use
>'setenv' to do that, then run following commands:
> tftpboot 0x8100
> bootm 0x8100
> 6. Wait about 1 minute for OpenWrt to boot.
> 7. Transfer OpenWrt sysupgrade image to /tmp directory and flash it
>with:
> sysupgrade -n /tmp/
> 8. After flashing, the access point will reboot to OpenWrt. Wait few
>minutes, until the Power LED stops blinking, then it's ready for
>configuration.
>
> Known issues
> Green power LED does not work.
>
> Additional information
> The U-Boot fails to initialise ethernet ports correctly when a UART adapter is
> attached to UART pins (marked J3 on PCB).
>
> Cc: Vladimir Georgievsky
> Signed-of-by: Tomasz Maciej Nowak
> ---
> package/boot/uboot-envtools/files/ath79 | 1 +
> target/linux/ath79/dts/qca9550_mojo_c-75.dts | 173
> ++
> .../generic/base-files/etc/board.d/02_network | 4 +
> target/linux/ath79/image/generic.mk | 11 ++
> 4 files changed, 189 insertions(+)
> create mode 100644 target/linux/ath79/dts/qca9550_mojo_c-75.dts
>
> diff --git a/package/boot/uboot-envtools/files/ath79
> b/package/boot/uboot-envtools/files/ath79
> index 259c52c77034..a6b52b370530 100644
> --- a/package/boot/uboot-envtools/files/ath79
> +++ b/package/boot/uboot-envtools/files/ath79
> @@ -20,6 +20,7 @@ alfa-network,n5q|\
> alfa-network,pi-wifi4|\
> alfa-network,r36a|\
> allnet,all-wap02860ac|\
> +airtight,c-75|\
This is inconsistent with the other names. See more detailed comment below.
> arduino,yun|\
> buffalo,bhr-4grv2|\
> devolo,magic-2-wifi|\
> diff --git a/target/linux/ath79/dts/qca9550_mojo_c-75.dts
> b/target/linux/ath79/dts/qca9550_mojo_c-75.dts
> new file mode 100644
> index ..51046a740a02
> --- /dev/null
> +++ b/target/linux/ath79/dts/qca9550_mojo_c-75.dts
> @@ -0,0 +1,173 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +
> +#include
> +#include
> +
> +#include "qca955x.dtsi"
This include needs to be first (after the license).
> +
> +/ {
> + model = "Mojo Networks AirTight C-75";
> + compatible = "mojo,c-75", "qca,qca9550", "qca,qca9558";
Please decide for one name and then use that consistently. It appears to me
that both Mojo Networks and Airtight Networks are different _vendor_ names (due
to a rename)?
Then please decide for one and use that one consistently, i.e.
either
model = "Mojo Networks C-75";
compatible = "mojo,c-75", "qca,qca9550", "qca,qca9558";
or
model = "Airtight Networks C-75";
compatible = "airtight,c-75", "qca,qca9550", "qca,qca9558";
> +
> + aliases {
> + label-mac-device = ð0;
> + led-boot = &led_power;
> + led-failsafe = &led_power;
> + led-upgrade = &led_power;
No led-running?
> + };
> +
> + keys {
> + compatible = "gpio-keys";
> +
> + reset {
> + linux,code = ;
> + gpios = <&gpio 17 GPIO_ACTIVE_LOW>;
missing label?
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led_power: power {
> + label = "amber:power";
> + gpios = <&gpio 14 GPIO_ACTIVE_HIGH>;
> + default-state = "on";
> + };
> +
> + wlan2g {
> + label = "green:wlan2g";
> + gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
> + linux,default-trigger = "phy1tpt";
> + };
> + };
> +};
> +
> +ð0 {
> + status = "okay";
> +
> + mtd-mac-address = <&art 0x0>;
> + phy-handle = <&phy0>;
> + phy-mode = "rgmii";
> + pll-data = <0xa600 0x0101 0x1616>; };
>
RE: [PATCH 2/2] ath79: mojo c-75: use second flash chip
> diff --git a/target/linux/ath79/image/generic.mk > b/target/linux/ath79/image/generic.mk > index 0f90c00b9c43..b7618a8ab33c 100644 > --- a/target/linux/ath79/image/generic.mk > +++ b/target/linux/ath79/image/generic.mk > @@ -1199,7 +1199,7 @@ define Device/mojo_c-75 >DEVICE_ALT0_VENDOR := WatchGuard >DEVICE_ALT0_MODEL := AP320 >DEVICE_PACKAGES := ath10k-firmware-qca988x kmod-ath10k-ct kmod- > usb2 > - IMAGE_SIZE := 15936k > + IMAGE_SIZE := 32320k I'm not sure whether that's possible or whether the image itself is restricted to a single consecutive area to be written to (i.e. the flash can be concatenated and used, but the _image_ is limited to the first partition _in_ it) Best Adrian > endef > TARGET_DEVICES += mojo_c-75 > > -- > 2.29.2 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH 19.07 6/6] toolchain: kernel-headers: kernel Git tree mirror hash
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Petr Štetiar > Sent: Mittwoch, 2. Dezember 2020 11:34 > To: openwrt-devel@lists.openwrt.org > Cc: Petr Štetiar > Subject: [PATCH 19.07 6/6] toolchain: kernel-headers: kernel Git tree mirror > hash > > Allow setting of mirror hash for Git kernel tree. Not sure whether backporting this very patch is absolutely necessary, but it shouldn't hurt either. Best Adrian > > Signed-off-by: Petr Štetiar (cherry picked from commit > 796d51834c5be85771d26e433fd509cd3bef72e3) > --- > config/Config-devel.in| 5 + > toolchain/kernel-headers/Makefile | 1 + > 2 files changed, 6 insertions(+) > > diff --git a/config/Config-devel.in b/config/Config-devel.in index > fd7c3ead1e8e..1c514f86d424 100644 > --- a/config/Config-devel.in > +++ b/config/Config-devel.in > @@ -100,6 +100,11 @@ menuconfig DEVEL > It can be a git hash or a branch name. > If unused, the clone's repository HEAD will be checked-out. > > + config KERNEL_GIT_MIRROR_HASH > + string "Enter hash of Git kernel tree source checkout tarball" > if DEVEL > + depends on (KERNEL_GIT_CLONE_URI != "") > + default "" > + > config BUILD_LOG > bool "Enable log files during build process" if DEVEL > help > diff --git a/toolchain/kernel-headers/Makefile b/toolchain/kernel- > headers/Makefile > index 1da1946a149c..69318814937a 100644 > --- a/toolchain/kernel-headers/Makefile > +++ b/toolchain/kernel-headers/Makefile > @@ -21,6 +21,7 @@ ifneq ($(call > qstrip,$(CONFIG_KERNEL_GIT_CLONE_URI)),) >PKG_SOURCE_PROTO:=git >PKG_SOURCE_URL:=$(call qstrip,$(CONFIG_KERNEL_GIT_CLONE_URI)) >PKG_SOURCE_VERSION:=$(call qstrip,$(CONFIG_KERNEL_GIT_REF)) > + PKG_MIRROR_HASH:=$(call > qstrip,$(CONFIG_KERNEL_GIT_MIRROR_HASH)) > ifdef CHECK >include $(INCLUDE_DIR)/kernel-version.mk >PKG_VERSION:=$(LINUX_VERSION) > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [RFC PATCH 0/4] mac80211: Update to version 5.10-rc6
> > Hauke Mehrtens (4): > > mac80211: Update to version 5.8.18-test2 > > mac80211: Update to version 5.9.11-test3 > > mac80211: Update to version 5.10-rc6-test5 > Can you squash these three commints into one? Having each major version separate might be helpful to track changes more easily ... Best Adrian > > > iw: Update to version 5.9 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH] ramips/mt7621: refresh the kernel config
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Rui Salvaterra > Sent: Mittwoch, 2. Dezember 2020 16:42 > To: openwrt-devel@lists.openwrt.org > Cc: Rui Salvaterra > Subject: [PATCH] ramips/mt7621: refresh the kernel config > > The removed config symbols are already enabled by the generic kernel > configuration (or by default), while the added ones are forcefully enabled by > the specific architecture. as already discussed on IRC, this is removing a lot of symbols, which makes not much sense to me. It appears that this commit broke the behavior of "make kernel_oldconfig": https://github.com/openwrt/openwrt/commit/a8fb12a7d62c94fd1bbda332752e0f8c794f3702 Just reverting that commit results in something that "looks reasonable" after make kernel_oldconfig. I'm marking that patch with "changes requested", though it's not really Rui's fault in the first place. Let's see where this evolves to. Best Adrian > > Signed-off-by: Rui Salvaterra > --- > Trivial make kernel_oldconfig CONFIG_TARGET=subtarget. > > target/linux/ramips/mt7621/config-5.4 | 54 ++- > 1 file changed, 4 insertions(+), 50 deletions(-) > > diff --git a/target/linux/ramips/mt7621/config-5.4 > b/target/linux/ramips/mt7621/config-5.4 > index b4c8ab1f1c..eaef2e40d1 100644 > --- a/target/linux/ramips/mt7621/config-5.4 > +++ b/target/linux/ramips/mt7621/config-5.4 > @@ -1,24 +1,9 @@ > CONFIG_ARCH_32BIT_OFF_T=y > CONFIG_ARCH_CLOCKSOURCE_DATA=y > -CONFIG_ARCH_HAS_DMA_COHERENT_TO_PFN=y > -CONFIG_ARCH_HAS_DMA_PREP_COHERENT=y > -CONFIG_ARCH_HAS_DMA_WRITE_COMBINE=y > -CONFIG_ARCH_HAS_ELF_RANDOMIZE=y > -CONFIG_ARCH_HAS_RESET_CONTROLLER=y > -CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE=y > -CONFIG_ARCH_HAS_TICK_BROADCAST=y > -CONFIG_ARCH_HAS_UNCACHED_SEGMENT=y > CONFIG_ARCH_HIBERNATION_POSSIBLE=y > CONFIG_ARCH_MMAP_RND_BITS_MAX=15 > CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=15 > -CONFIG_ARCH_SUPPORTS_UPROBES=y > CONFIG_ARCH_SUSPEND_POSSIBLE=y > -CONFIG_ARCH_USE_BUILTIN_BSWAP=y > -CONFIG_ARCH_USE_MEMREMAP_PROT=y > -CONFIG_ARCH_USE_QUEUED_RWLOCKS=y > -CONFIG_ARCH_USE_QUEUED_SPINLOCKS=y > -CONFIG_ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT=y > -CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y > CONFIG_AT803X_PHY=y > CONFIG_BLK_MQ_PCI=y > CONFIG_BOARD_SCACHE=y > @@ -65,6 +50,7 @@ CONFIG_CRYPTO_NULL2=y > CONFIG_CRYPTO_RNG2=y > CONFIG_CSRC_R4K=y > CONFIG_DEBUG_PINCTRL=y > +CONFIG_DIMLIB=y > CONFIG_DMA_NONCOHERENT=y > CONFIG_DMA_NONCOHERENT_CACHE_SYNC=y > # CONFIG_DMA_RALINK is not set > @@ -108,46 +94,12 @@ CONFIG_GPIO_MT7621=y # CONFIG_GPIO_RALINK > is not set CONFIG_GPIO_WATCHDOG=y # > CONFIG_GPIO_WATCHDOG_ARCH_INITCALL is not set > +CONFIG_GRO_CELLS=y > CONFIG_HANDLE_DOMAIN_IRQ=y > CONFIG_HARDWARE_WATCHPOINTS=y > CONFIG_HAS_DMA=y > CONFIG_HAS_IOMEM=y > CONFIG_HAS_IOPORT_MAP=y > -CONFIG_HAVE_ARCH_COMPILER_H=y > -CONFIG_HAVE_ARCH_JUMP_LABEL=y > -CONFIG_HAVE_ARCH_KGDB=y > -CONFIG_HAVE_ARCH_SECCOMP_FILTER=y > -CONFIG_HAVE_ARCH_TRACEHOOK=y > -CONFIG_HAVE_ASM_MODVERSIONS=y > -CONFIG_HAVE_CLK=y > -CONFIG_HAVE_CLK_PREPARE=y > -CONFIG_HAVE_CONTEXT_TRACKING=y > -CONFIG_HAVE_COPY_THREAD_TLS=y > -CONFIG_HAVE_C_RECORDMCOUNT=y > -CONFIG_HAVE_DEBUG_KMEMLEAK=y > -CONFIG_HAVE_DEBUG_STACKOVERFLOW=y > -CONFIG_HAVE_DMA_CONTIGUOUS=y > -CONFIG_HAVE_DYNAMIC_FTRACE=y > -CONFIG_HAVE_FAST_GUP=y > -CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y > -CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y > -CONFIG_HAVE_FUNCTION_TRACER=y > -CONFIG_HAVE_GENERIC_VDSO=y > -CONFIG_HAVE_IDE=y > -CONFIG_HAVE_IOREMAP_PROT=y > -CONFIG_HAVE_IRQ_EXIT_ON_IRQ_STACK=y > -CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y > -CONFIG_HAVE_KVM=y > -CONFIG_HAVE_LD_DEAD_CODE_DATA_ELIMINATION=y > -CONFIG_HAVE_MEMBLOCK_NODE_MAP=y > -CONFIG_HAVE_MOD_ARCH_SPECIFIC=y > -CONFIG_HAVE_NET_DSA=y > -CONFIG_HAVE_OPROFILE=y > -CONFIG_HAVE_PCI=y > -CONFIG_HAVE_PERF_EVENTS=y > -CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y > -CONFIG_HAVE_RSEQ=y > -CONFIG_HAVE_SYSCALL_TRACEPOINTS=y > CONFIG_HIGHMEM=y > CONFIG_HZ=250 > CONFIG_HZ_250=y > @@ -177,6 +129,7 @@ CONFIG_MIKROTIK_RB_SYSFS=y CONFIG_MIPS=y > CONFIG_MIPS_ASID_BITS=8 > CONFIG_MIPS_ASID_SHIFT=0 > +CONFIG_MIPS_CBPF_JIT=y > CONFIG_MIPS_CLOCK_VSYSCALL=y > CONFIG_MIPS_CM=y > # CONFIG_MIPS_CMDLINE_BUILTIN_EXTEND is not set @@ -316,6 +269,7 > @@ CONFIG_SYS_SUPPORTS_MIPS_CPS=y > CONFIG_SYS_SUPPORTS_MULTITHREADING=y > CONFIG_SYS_SUPPORTS_SCHED_SMT=y > CONFIG_SYS_SUPPORTS_SMP=y > +CONFIG_SYS_SUPPORTS_ZBOOT=y > CONFIG_TARGET_ISA_REV=2 > CONFIG_TICK_CPU_ACCOUNTING=y > CONFIG_TIMER_OF=y > -- > 2.29.2 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH] ramips/mt7621: refresh the kernel config
> -Original Message- > From: Felix Fietkau [mailto:n...@nbd.name] > Sent: Mittwoch, 2. Dezember 2020 19:25 > To: Adrian Schmutzler ; 'Rui Salvaterra' > ; openwrt-devel@lists.openwrt.org > Subject: Re: [PATCH] ramips/mt7621: refresh the kernel config > > > Hi, > > > On 2020-12-02 18:32, Adrian Schmutzler wrote: > >> -Original Message- > >> From: openwrt-devel [mailto:openwrt-devel- > boun...@lists.openwrt.org] > >> On Behalf Of Rui Salvaterra > >> Sent: Mittwoch, 2. Dezember 2020 16:42 > >> To: openwrt-devel@lists.openwrt.org > >> Cc: Rui Salvaterra > >> Subject: [PATCH] ramips/mt7621: refresh the kernel config > >> > >> The removed config symbols are already enabled by the generic kernel > >> configuration (or by default), while the added ones are forcefully > >> enabled by the specific architecture. > > > > as already discussed on IRC, this is removing a lot of symbols, which makes > not much sense to me. > > > > It appears that this commit broke the behavior of "make kernel_oldconfig": > > > > > https://github.com/openwrt/openwrt/commit/a8fb12a7d62c94fd1bbda3327 > 52e > > 0f8c794f3702 > > > > Just reverting that commit results in something that "looks reasonable" > after make kernel_oldconfig. > > > > I'm marking that patch with "changes requested", though it's not really > Rui's fault in the first place. > > > > Let's see where this evolves to. > Removing a lot of symbols was the whole point behind my commit, and it > makes sense that any subsequent refresh has a big negative delta. > > I tried to be careful about only filtering out auto-generated symbols. But then I don't understand why target/linux/generic/config-filter contains all patterns followed by "is not set", when it's meant to match =y as well? Best Adrian > Did I accidentally hit any symbol with a prompt that shows up on make > afterwards? > > - Felix openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH] ramips/mt7621: refresh the kernel config
> -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Felix Fietkau > Sent: Mittwoch, 2. Dezember 2020 19:46 > To: Adrian Schmutzler ; 'Rui Salvaterra' > ; openwrt-devel@lists.openwrt.org > Subject: Re: [PATCH] ramips/mt7621: refresh the kernel config > > > On 2020-12-02 19:45, Adrian Schmutzler wrote: > >> -Original Message- > >> From: Felix Fietkau [mailto:n...@nbd.name] > >> Sent: Mittwoch, 2. Dezember 2020 19:25 > >> To: Adrian Schmutzler ; 'Rui Salvaterra' > >> ; openwrt-devel@lists.openwrt.org > >> Subject: Re: [PATCH] ramips/mt7621: refresh the kernel config > >> > >> > >> Hi, > >> > >> > >> On 2020-12-02 18:32, Adrian Schmutzler wrote: > >> >> -Original Message- > >> >> From: openwrt-devel [mailto:openwrt-devel- > >> boun...@lists.openwrt.org] > >> >> On Behalf Of Rui Salvaterra > >> >> Sent: Mittwoch, 2. Dezember 2020 16:42 > >> >> To: openwrt-devel@lists.openwrt.org > >> >> Cc: Rui Salvaterra > >> >> Subject: [PATCH] ramips/mt7621: refresh the kernel config > >> >> > >> >> The removed config symbols are already enabled by the generic > >> >> kernel configuration (or by default), while the added ones are > >> >> forcefully enabled by the specific architecture. > >> > > >> > as already discussed on IRC, this is removing a lot of symbols, > >> > which makes > >> not much sense to me. > >> > > >> > It appears that this commit broke the behavior of "make > kernel_oldconfig": > >> > > >> > > >> > https://github.com/openwrt/openwrt/commit/a8fb12a7d62c94fd1bbda3327 > >> 52e > >> > 0f8c794f3702 > >> > > >> > Just reverting that commit results in something that "looks reasonable" > >> after make kernel_oldconfig. > >> > > >> > I'm marking that patch with "changes requested", though it's not > >> > really > >> Rui's fault in the first place. > >> > > >> > Let's see where this evolves to. > >> Removing a lot of symbols was the whole point behind my commit, and > >> it makes sense that any subsequent refresh has a big negative delta. > >> > >> I tried to be careful about only filtering out auto-generated symbols. > > > > But then I don't understand why target/linux/generic/config-filter > > contains all patterns followed by "is not set", when it's meant to > > match =y as well? > That's just an artifact to keep it in kconfig.pl syntax (since that's what's > being > used to filter). The value of the symbols is irrelevant, symbols matching the > name will be filtered. Okay, thanks. So, this is essentially a misunderstanding from my side then, as the new concept is not really explained in detail ;-) I will set the patch from Rui back to "New" then, as it's technically not wrong, but I was misled in my judgement. Best Adrian > > - Felix > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH] ramips: Adds support for Comfast CF-E538AC
Hi,
several comments below in addition to what Daniel stated.
As a general comment:
It would have been quicker if you asked the questions first, because now you
will have to send another version ...
Please use versions on your patch (-v parameter to git format-patch) so we can
track the changes more easily.
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Sven Danner
> Sent: Donnerstag, 3. Dezember 2020 06:57
> To: j...@phrozen.org
> Cc: openwrt-devel@lists.openwrt.org
> Subject: [PATCH] ramips: Adds support for Comfast CF-E538AC
>
> From: Sven Danner
>
> Comfast CF-E538AC is a wall mounted access point with an additional
> Ethernet LAN access port. It supports 802.11AC Wave2 MU-MIMO.
>
> Serial port access for debricking requires simple soldering of 4 pins.
>
> Device specifications:
> * SoC: MT7620DA @ 580MHz
> * RAM: 64MiB DDR2
> * Flash: 8iB SPI
> * Wireless 2.4GHz (SoC): b/g/n
> * Wireless 5Ghz (MT7612E): n/ac, 2x2 MU-MINO
> * Ethernet connection back (RTL8211F - port 4): 1× 1GbE, 802.3af PoE
> * Ethernet connection front (RTL8211F - port 5): 1× 1GbE
>
> Flashing instructions:
> * Upgrade using stock web interface's update feature
>
> Debricking:
> * Serial port can be soldered on top PCB (marked as 1)
> (1: VCC, 2: GND, 3: TX, 4: RX)
> * Use 3.3V, 115200 baud, 8N1
> * Recovery only possible via TFTP
> * Modified U-Boot environment does not allow recovery via serial
> data transfer (will not commit it to flash)
> * Bootloader will show a menu for 1 seconds
> * Select 2: Load system code then write to Flash via TFTP.
>
> Signed-off-by: Sven Danner
> ---
> This is my third submission.
> I hope I have successfully incorporated any feedback that I have received
> and am following the right format.
> Apologies for any inconvenience caused.
>
> A couple of notes:
> This speed (which 47 of 68 mt7620a devices use) comes straight from the
> stock firmware's DTS file:
> spi-max-frequency = <1000>;
> At this point I rather not increase it unless necessary.
Yes, this is a copy-paste thing. It's just always kept slow unnecessarily,
although it could be considerably faster on most devices.
>
> This line was suggested to be dropped, but every device in
> /target/linux/ramips/image/mt7620.mk
> is defining that as well:
> + SUPPORTED_DEVICES += cf-e538ac
> I have left it in for this submission.
>
> I have still defined LED white:wifi so it will appear in LuCI for users as the
If you insist on not using DT trigger, please at least convert this to the
appropriate phy0tpt/phy0radio trigger in 01_leds. With the current setup, the
LED is restricted to a specific name of the WiFi interface, which is an
unnecessary drawback.
> device drivers seem to automatically create 4 LEDs in /sys/class/leds that are
> not physically connected:
>
> mt76-phy0
> rt2800soc-phy1::quality
> rt2800soc-phy1::assoc
> rt2800soc-phy1::radio
>
> I appreciate all feedback, please be kind and assume honest mistakes not
> maliciousness.
> ---
>
> .../ramips/dts/mt7620a_comfast_cf-e538ac.dts | 149
> ++
> target/linux/ramips/image/mt7620.mk | 10 ++
> .../mt7620/base-files/etc/board.d/01_leds | 3 +
> .../mt7620/base-files/etc/board.d/02_network | 4 +
> 4 files changed, 166 insertions(+)
> create mode 100644 target/linux/ramips/dts/mt7620a_comfast_cf-
> e538ac.dts
> diff --git a/target/linux/ramips/dts/mt7620a_comfast_cf-e538ac.dts
> b/target/linux/ramips/dts/mt7620a_comfast_cf-e538ac.dts
> new file mode 100644
> index 00..6ccf06531d
> --- /dev/null
> +++ b/target/linux/ramips/dts/mt7620a_comfast_cf-e538ac.dts
> @@ -0,0 +1,149 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT #include
> +"mt7620a.dtsi"
> +
> +#include
> +#include
> +
> +/ {
> + compatible = "comfast,cf-e538ac", "ralink,mt7620a-soc";
> + model = "Comfast CF-E538AC";
> +
> + aliases {
> + led-boot = &led_wifi;
> + led-failsafe = &led_wifi;
> + led-running = &led_wifi;
> + led-upgrade = &led_wifi;
> + };
> +
> + chosen {
> + bootargs = "console=ttyS0,115200";
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led_wifi: wifi {
> + label = "white:wifi";
> + gpios = <&gpio3 0 GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> + keys {
> + compatible = "gpio-keys";
> +
> + reset {
> + label = "reset";
> + gpios = <&gpio0 13 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> + };
> +};
> +
> +&gpio0 {
> + status = "okay";
> +};
> +
> +&gpio3 {
> + status = "okay";
> +};
> +
> +&spi0 {
> + status = "okay";
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <1000>;
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <
RE: [PATCH] ltq-dsl-base: only lock the dsl pipe once for all stats
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Andre Heider
> Sent: Freitag, 4. Dezember 2020 08:44
> To: openwrt-devel@lists.openwrt.org
> Subject: [PATCH] ltq-dsl-base: only lock the dsl pipe once for all stats
>
> Instead of locking/unlocking it for every command.
please bump PKG_RELEASE.
Best
Adrian
>
> Reduces the runtime for the dslstat/lucistat commands to ~66%.
>
> Before:
> real 0m 2.66s
> user 0m 0.90s
> sys 0m 1.76s
>
> After:
> real 0m 1.76s
> user 0m 0.63s
> sys 0m 1.13s
>
> Signed-off-by: Andre Heider
> ---
> .../files/lib/functions/lantiq_dsl.sh | 21 +--
> 1 file changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/package/network/utils/ltq-dsl-
> base/files/lib/functions/lantiq_dsl.sh b/package/network/utils/ltq-dsl-
> base/files/lib/functions/lantiq_dsl.sh
> index 39011f134f..89dc5c25c9 100755
> --- a/package/network/utils/ltq-dsl-base/files/lib/functions/lantiq_dsl.sh
> +++ b/package/network/utils/ltq-dsl-base/files/lib/functions/lantiq_dsl.
> +++ sh
> @@ -7,16 +7,24 @@ else
> XDSL_CTRL=dsl_cpe_control
> fi
>
> +DSL_PIPE_LOCKED=0
> +
> #
> # Basic functions to send CLI commands to the vdsl_cpe_control daemon #
> +dsl_init() {
> + killall -q -0 ${XDSL_CTRL} && lock /var/lock/dsl_pipe &&
> DSL_PIPE_LOCKED=1
> + trap dsl_deinit EXIT INT KILL TERM
> +}
> +dsl_deinit() {
> + test $DSL_PIPE_LOCKED -gt 0 && lock -u /var/lock/dsl_pipe &&
> DSL_PIPE_LOCKED=0
> + exit
> +}
> dsl_cmd() {
> - killall -q -0 ${XDSL_CTRL} && (
> - lock /var/lock/dsl_pipe
> - echo "$@" > /tmp/pipe/dsl_cpe0_cmd
> - cat /tmp/pipe/dsl_cpe0_ack
> - lock -u /var/lock/dsl_pipe
> - )
> + test $DSL_PIPE_LOCKED -eq 0 && return
> +
> + echo "$@" > /tmp/pipe/dsl_cpe0_cmd
> + cat /tmp/pipe/dsl_cpe0_ack
> }
> dsl_val() {
> expr "$1" : '.*'$2'=\([-\.[:alnum:]]*\).*'
> @@ -783,6 +791,7 @@ line_features() {
> }
>
> dslstat() {
> + dsl_init
> vendor
> chipset
> xtse
> --
> 2.29.2
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH] mvebu: macchiatobin-singleshot: enable heartbeat LED
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Alexandra Alth
> Sent: Freitag, 4. Dezember 2020 13:59
> To: Tomasz Maciej Nowak
> Cc: openwrt-devel@lists.openwrt.org
> Subject: Re: [PATCH] mvebu: macchiatobin-singleshot: enable heartbeat LED
>
> Is this now approved and integrated in the nightly? tnx alexandra
Did anyone say so?
>
> > Am 25.11.2020 um 17:53 schrieb Tomasz Maciej Nowak
> :
> >
> > With board revision 1.3, SolidRun moved the power LED to the middle of
> > the board. In old place of power LED a GPIO controllable heartbeat LED
> > was added. This commit touches only Single Shot variant, because all
> > have revision 1.3. Some boards could be placed in an enclosure,
> > therefore the LED0 is enabled by default, since that'll be the only
> > visible indicator that the board is operating.
> >
> > Ref:
> > http://wiki.macchiatobin.net/tiki-index.php?page=Schematics#Revision1.
> > 3_Electrical_Design_Changes
> > Ref:
> > http://macchiatobin.net/wp-content/uploads/2017/11/MACCHIATOBin-
> rev-1_
> > 3.pdf
> >
> > Reported-by: Alexandra Alth
> > Signed-off-by: Tomasz Maciej Nowak
> > ---
> > target/linux/mvebu/image/cortexa72.mk | 2 +-
> > ...s-mcbin-singleshot-add-heartbeat-LED.patch | 59
> +++
> > 2 files changed, 60 insertions(+), 1 deletion(-) create mode 100644
> > target/linux/mvebu/patches-5.4/100-arm64-dts-mcbin-singleshot-add-
> hear
> > tbeat-LED.patch
> >
> > diff --git a/target/linux/mvebu/image/cortexa72.mk
> > b/target/linux/mvebu/image/cortexa72.mk
> > index 1440c07a0b5f..8bd4581766c2 100644
> > --- a/target/linux/mvebu/image/cortexa72.mk
> > +++ b/target/linux/mvebu/image/cortexa72.mk
> > @@ -38,7 +38,7 @@ define Device/marvell_macchiatobin-singleshot
> > DEVICE_ALT0_VENDOR := SolidRun
> > DEVICE_ALT0_MODEL := Armada 8040 Community Board
> > DEVICE_ALT0_VARIANT := Single Shot
> > - DEVICE_PACKAGES += kmod-i2c-mux-pca954x
> > + DEVICE_PACKAGES += kmod-i2c-mux-pca954x kmod-ledtrig-heartbeat
> > DEVICE_DTS := armada-8040-mcbin-singleshot
> > SUPPORTED_DEVICES := marvell,armada8040-mcbin-singleshot
> > endef
> > diff --git
> > a/target/linux/mvebu/patches-5.4/100-arm64-dts-mcbin-singleshot-add-
> he
> > artbeat-LED.patch
> > b/target/linux/mvebu/patches-5.4/100-arm64-dts-mcbin-singleshot-add-
> he
> > artbeat-LED.patch
> > new file mode 100644
> > index ..a5f37461360b
> > --- /dev/null
> > +++ b/target/linux/mvebu/patches-5.4/100-arm64-dts-mcbin-singleshot-
> ad
> > +++ d-heartbeat-LED.patch
> > @@ -0,0 +1,59 @@
> > +From 310b7883b64993da355ad5cc3e45f515ac2bef2f Mon Sep 17 00:00:00
> > +2001
> > +From: Tomasz Maciej Nowak
> > +Date: Sat, 17 Oct 2020 16:53:20 +0200
> > +Subject: [PATCH] arm64: dts: mcbin-singleshot: add heartbeat LED
> > +
> > +With board revision 1.3, SolidRun moved the power LED to the middle
> > +of the board. In old place of power LED a GPIO controllable heartbeat
> > +LED was added. This commit only touches Single Shot variant, since
> > +only this variant is all revision 1.3.
> > +
> > +Reported-by: Alexandra Alth
> > +Signed-off-by: Tomasz Maciej Nowak
> > +---
> > + .../marvell/armada-8040-mcbin-singleshot.dts | 22
> >
> > + 1 file changed, 22 insertions(+)
> > +
> > +--- a/arch/arm64/boot/dts/marvell/armada-8040-mcbin-singleshot.dts
> > b/arch/arm64/boot/dts/marvell/armada-8040-mcbin-singleshot.dts
> > +@@ -5,6 +5,8 @@
> > + * Device Tree file for MACCHIATOBin Armada 8040 community board
> > +platform
> > + */
> > +
> > ++#include
> > ++
> > + #include "armada-8040-mcbin.dtsi"
> > +
> > + / {
> > +@@ -12,6 +14,20 @@
> > + compatible = "marvell,armada8040-mcbin-singleshot",
> > + "marvell,armada8040-mcbin", "marvell,armada8040",
> > + "marvell,armada-ap806-quad", "marvell,armada-
> ap806";
> > ++
> > ++ leds {
> > ++ compatible = "gpio-leds";
> > ++ pinctrl-0 = <&cp0_led18_pins>;
> > ++ pinctrl-names = "default";
> > ++
> > ++ led18 {
> > ++ gpios = <&cp0_gpio2 1 GPIO_ACTIVE_LOW>;
> > ++ function = LED_FUNCTION_HEARTBEAT;
> > ++ color = ;
> > ++ linux,default-trigger = "heartbeat";
> > ++ default-state = "on";
> > ++ };
> > ++ };
> > + };
> > +
> > + &cp0_eth0 {
> > +@@ -27,3 +43,10 @@
> > + managed = "in-band-status";
> > + sfp = <&sfp_eth1>;
> > + };
> > ++
> > ++&cp0_pinctrl {
> > ++ cp0_led18_pins: led18-pins {
> > ++ marvell,pins = "mpp33";
> > ++ marvell,function = "gpio";
> > ++ };
> > ++};
> > --
> > 2.29.2
> >
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing l
RE: What happened to 18.06.9? (Re: Upcoming 19.07.4 and 18.07.9 stable releases
> -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Hannu Nyman > Sent: Freitag, 4. Dezember 2020 15:27 > To: openwrt-devel@lists.openwrt.org; Hauke Mehrtens m.de> > Subject: What happened to 18.06.9? (Re: Upcoming 19.07.4 and 18.07.9 > stable releases > > *Hauke Mehrtens* wrote on /Tue Nov 10 18:58:52 EST 2020: > / > > /> /Currently 18.06 looks good for me and I would really like to do the final > release and call it then officially end of life. I would wait for the build > bot > results and then do it at the weekend. > > > What happened to 18.06.9? > It was tagged and built over two weeks ago, but was never officially > released? > (no trace of it in either forum, mailing list or > https://downloads.openwrt.org/* )* It's in downloads, it's just not linked: https://downloads.openwrt.org/releases/18.06.9/ (Just an observation, I've not taken part in the process of making that release.) > > > Ps. Is 18.06 now EoL ? > > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: ramips: add support for Xiaomi Mi Router 4AC (100M Edition)
> -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Sorin Pop > Sent: Sonntag, 6. Dezember 2020 00:54 > To: openwrt-devel@lists.openwrt.org > Subject: ramips: add support for Xiaomi Mi Router 4AC (100M Edition) > > - SoC: MediaTek MT7628AN > - Flash:16MB (Winbond W25Q128JV) > - RAM: 64MB > - Serial: As marked on PCB, 3V3 logic, baudrate is 115200 > - Ethernet: 3x 10/100 Mbps (switched, 2x LAN + WAN) > - WIFI0:MT7628AN 2.4GHz 802.11b/g/n > - WIFI1:MT7612EN 5GHz 802.11ac > - Antennas: 4x external (2 per radio), non-detachable > - LEDs: Programmable power-LED (two-colored, yellow/blue) > Non-programmable internet-LED (shows WAN-activity) > - Buttons: Reset So, the only difference in implementation is the size of overlay/firmware partitions? Best Adrian > > INSTALLATION: > > 1. Connect to the serial port of the router and power it up. >If you get a prompt asking for boot-mode, go to step 3. > 2. Unplug the router after >> Erasing SPI Flash... >> raspi_erase: offs:2 len:1 >occurs on the serial port. Plug the router back in. > 3. At the prompt select option 2 (Load system code then >write to Flash via TFTP.) > 4. Enter 192.168.1.1 as the device IP and 192.168.1.2 as the >Server-IP. > 5. Connect your computer to LAN1 and assign it as 192.168.1.2/24. > 6. Serve the sysupgrade image via TFTP > > This router seems to have the same hardware as Xiaomi Mi Router 4A (100M > Edition) but it uses a different U-Boot. > > Signed-off-by: Sorin Pop openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [RFC PATCH 1/5] ath79: put some 8/32MB devices to tiny subtarget
> --- a/target/linux/ath79/image/common-tp-link.mk > +++ b/target/linux/ath79/image/common-tp-link.mk > @@ -40,6 +40,7 @@ define Device/tplink-4m >$(Device/tplink-nolzma) >TPLINK_FLASHLAYOUT := 4M >IMAGE_SIZE := 3904k > + FEATURES := small_flash Features are a target property, defining them per-device is wrong and won't work as expected. Best Adrian >DEFAULT := n > endef > > @@ -47,6 +48,7 @@ define Device/tplink-4mlzma >$(Device/tplink-v1) >TPLINK_FLASHLAYOUT := 4Mlzma >IMAGE_SIZE := 3904k > + FEATURES := small_flash >DEFAULT := n > endef > > diff --git a/target/linux/ath79/image/tiny-tp-link.mk > b/target/linux/ath79/image/tiny-tp-link.mk > index c918c6baa6..d5b36de577 100644 > --- a/target/linux/ath79/image/tiny-tp-link.mk > +++ b/target/linux/ath79/image/tiny-tp-link.mk > @@ -223,6 +223,17 @@ define Device/tplink_tl-wa901nd-v5 endef > TARGET_DEVICES += tplink_tl-wa901nd-v5 > > +define Device/tplink_tl-wr1043nd-v1 > + $(Device/tplink-8m) > + SOC := ar9132 > + DEVICE_MODEL := TL-WR1043N/ND > + DEVICE_VARIANT := v1 > + DEVICE_PACKAGES := kmod-usb2 kmod-usb-ledtrig-usbport > + TPLINK_HWID := 0x10430001 > + SUPPORTED_DEVICES += tl-wr1043nd > +endef > +TARGET_DEVICES += tplink_tl-wr1043nd-v1 > + > define Device/tplink_tl-wr703n >$(Device/tplink-4mlzma) >SOC := ar9331 > @@ -243,6 +254,29 @@ define Device/tplink_tl-wr740n-v1 endef > TARGET_DEVICES += tplink_tl-wr740n-v1 > > +define Device/tplink_tl-wr710n-v1 > + $(Device/tplink-8mlzma) > + SOC := ar9331 > + DEVICE_MODEL := TL-WR710N > + DEVICE_VARIANT := v1 > + DEVICE_PACKAGES := kmod-usb-chipidea2 kmod-usb-ledtrig-usbport > + TPLINK_HWID := 0x0711 > + SUPPORTED_DEVICES += tl-wr710n > +endef > +TARGET_DEVICES += tplink_tl-wr710n-v1 > + > +define Device/tplink_tl-wr710n-v2.1 > + $(Device/tplink-8mlzma) > + SOC := ar9331 > + DEVICE_MODEL := TL-WR710N > + DEVICE_VARIANT := v2.1 > + DEVICE_PACKAGES := kmod-usb-chipidea2 kmod-usb-ledtrig-usbport > + TPLINK_HWID := 0x0712 > + TPLINK_HWREV := 0x2 > + SUPPORTED_DEVICES += tl-wr710n > +endef > +TARGET_DEVICES += tplink_tl-wr710n-v2.1 > + > define Device/tplink_tl-wr740n-v3 >$(Device/tplink-4m) >SOC := ar7240 > @@ -327,6 +361,16 @@ define Device/tplink_tl-wr802n-v2 endef > TARGET_DEVICES += tplink_tl-wr802n-v2 > > +define Device/tplink_tl-wr810n-v2 > + $(Device/tplink-8mlzma) > + SOC := qca9533 > + DEVICE_MODEL := TL-WR810N > + DEVICE_VARIANT := v2 > + TPLINK_HWID := 0x812 > + SUPPORTED_DEVICES += tl-wr810n-v2 > +endef > +TARGET_DEVICES += tplink_tl-wr810n-v2 > + > define Device/tplink_tl-wr841-v5 >$(Device/tplink-4m) >SOC := ar7240 > @@ -403,6 +447,28 @@ define Device/tplink_tl-wr841-v12 endef > TARGET_DEVICES += tplink_tl-wr841-v12 > > +define Device/tplink_tl-wr842n-v1 > + $(Device/tplink-8m) > + SOC := ar7241 > + DEVICE_MODEL := TL-WR842N/ND > + DEVICE_VARIANT := v1 > + DEVICE_PACKAGES := kmod-usb2 kmod-usb-ledtrig-usbport > + TPLINK_HWID := 0x8420001 > + SUPPORTED_DEVICES += tl-mr3420 > +endef > +TARGET_DEVICES += tplink_tl-wr842n-v1 > + > +define Device/tplink_tl-wr842n-v2 > + $(Device/tplink-8mlzma) > + SOC := ar9341 > + DEVICE_MODEL := TL-WR842N/ND > + DEVICE_VARIANT := v2 > + DEVICE_PACKAGES := kmod-usb2 kmod-usb-ledtrig-usbport > + TPLINK_HWID := 0x8420002 > + SUPPORTED_DEVICES += tl-wr842n-v2 > +endef > +TARGET_DEVICES += tplink_tl-wr842n-v2 > + > define Device/tplink_tl-wr940n-v3 >$(Device/tplink-4mlzma) >SOC := tp9343 > diff --git a/target/linux/ath79/image/tiny-ubnt.mk > b/target/linux/ath79/image/tiny-ubnt.mk > new file mode 100644 > index 00..a8c5a2cf68 > --- /dev/null > +++ b/target/linux/ath79/image/tiny-ubnt.mk > @@ -0,0 +1,132 @@ > +DEVICE_VARS += UBNT_BOARD UBNT_CHIP UBNT_TYPE UBNT_VERSION > +UBNT_REVISION > + > +# On M (XW) devices the U-Boot as of version 1.1.4-s1039 doesn't like # > +VERSION_DIST being on the place of major(?) version number, so we need > +to # use some number. > +UBNT_REVISION := $(VERSION_DIST)-$(REVISION) > + > +# mkubntimage is using the kernel image direct # routerboard creates > +partitions out of the ubnt header define Build/mkubntimage > + -$(STAGING_DIR_HOST)/bin/mkfwimage -B $(UBNT_BOARD) \ > + -v $(UBNT_TYPE).$(UBNT_CHIP).v6.0.0-$(VERSION_DIST)- > $(REVISION) \ > + -k $(IMAGE_KERNEL) -r $@ -o $@ > +endef > + > +# all UBNT XM/WA devices expect the kernel image to have 1024k while > +flash, when # booting the image, the size doesn't matter. > +define Build/mkubntimage-split > + -[ -f $@ ] && ( \ > + dd if=$@ of=$@.old1 bs=1024k count=1; \ > + dd if=$@ of=$@.old2 bs=1024k skip=1; \ > + $(STAGING_DIR_HOST)/bin/mkfwimage -B $(UBNT_BOARD) \ > + -v $(UBNT_TYPE).$(UBNT_CHIP).v$(UBNT_VERSION)- > $(UBNT_REVISION) \ > + -k $@.old1 -r $@.old2 -o $@; \ > + rm $@.old1 $@.old2 ) > +endef > + > +# UBNT_BOARD e.g. one of (XS2, XS5, RS, XM) # UBNT_TYPE e.g. one of > +(B
RE: [RFC 0/5] ath79: add a lower RAM-using version of 8/32 devices
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Sven Roederer
> Sent: Sonntag, 6. Dezember 2020 02:07
> To: openwrt-devel@lists.openwrt.org
> Subject: [RFC 0/5] ath79: add a lower RAM-using version of 8/32 devices
>
> Currently 8MB flash / 32MB RAM devices are fully supported in OpenWrt, as
> they work quite well for basic usage (including full LuCI).
> On some projects with advanced features (e.g. Freifunk) the lack of RAM
> turns them into unstable devices. Mostly caused by several OOM problems
> per day.
> This series tries to prolong the usage of these boards by moving them to the
> ath79-tiny target. Indeed it makes these boards available on ath79-tiny in
> addition to the current ath79-generic variant.
> To improve the low RAM situation the default kernel-config for the tiny sub-
> target will also disable some uncommon features. So the kernel image
> becomes smaller, which results in lower flash- and RAM-footprint.
As stated in the earlier discussion, I never liked mixing low-flash ("tiny")
and low-RAM (???) devices.
In contrast, David has made clear that this also is not possible due to
conflicting goals for both approaches.
So, rather than mixing things up here and making it even harder to understand
what "tiny" is supposed to be, this proposal IMO should rather aim at
introducing a new subtarget aiming specifically at low-RAM devices. One could
then just stop building "tiny" by default (there is only one device left, and I
doubt people will have much benefit from prebuilt packages when they have to
strip stuff anyway), and build the new subtarget _instead_ (i.e. no additional
building overhead).
You still will have problems to find allies for your proposal, but that way it
would make much more sense that now IMO.
Best
Adrian
>
> [RFC PATCH 1/5] ath79: put some 8/32MB devices to tiny subtarget [RFC
> PATCH 2/5] kernel: deactivate usb on ath79-tiny [RFC PATCH 3/5] ath79:
> deactivate PARTITION_ADVANCED [RFC PATCH 4/5] kernel: ath79-tiny
> deactivate usually not needed features [RFC PATCH 5/5] kernel: ath79-tiny:
> enable CONFIG_BLOCK
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [RFC PATCH 2/5] kernel: deactivate usb on ath79-tiny
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Sven Roederer > Sent: Sonntag, 6. Dezember 2020 02:07 > To: openwrt-devel@lists.openwrt.org > Cc: adminuser > Subject: [RFC PATCH 2/5] kernel: deactivate usb on ath79-tiny > > From: adminuser This has various obvious formal shortcomings: - From without name - Missing SOB - Missing description (why?) Apart from that, I don't see disabling basic features like USB on a device with USB ports as an option for pure OpenWrt. If the basic configuration does not run or build, we should simply put "DEFAULT := n" and have the user select the configuration he/she needs. One might reorganize features between kernel and modules or remove really optional stuff, but this patch is too much of forcing here. Best Adrian > > --- > target/linux/ath79/image/tiny-tp-link.mk | 4 > target/linux/ath79/image/tiny-ubnt.mk| 2 -- > target/linux/ath79/image/tiny.mk | 1 - > target/linux/ath79/tiny/config-default | 5 +++-- > 4 files changed, 3 insertions(+), 9 deletions(-) > > diff --git a/target/linux/ath79/image/tiny-tp-link.mk > b/target/linux/ath79/image/tiny-tp-link.mk > index d5b36de577..ab931f02fb 100644 > --- a/target/linux/ath79/image/tiny-tp-link.mk > +++ b/target/linux/ath79/image/tiny-tp-link.mk > @@ -16,7 +16,6 @@ define Device/tplink_tl-mr3020-v1 >SOC := ar9331 >DEVICE_MODEL := TL-MR3020 >DEVICE_VARIANT := v1 > - DEVICE_PACKAGES := kmod-usb-chipidea2 kmod-usb-ledtrig-usbport >TPLINK_HWID := 0x3021 >SUPPORTED_DEVICES += tl-mr3020 > endef > @@ -27,7 +26,6 @@ define Device/tplink_tl-mr3040-v2 >SOC := ar9331 >DEVICE_MODEL := TL-MR3040 >DEVICE_VARIANT := v2 > - DEVICE_PACKAGES := kmod-usb-chipidea2 kmod-usb-ledtrig-usbport >TPLINK_HWID := 0x3042 >SUPPORTED_DEVICES += tl-mr3040-v2 > endef > @@ -39,7 +37,6 @@ define Device/tplink_tl-mr3220-v1 >DEVICE_MODEL := TL-MR3220 >DEVICE_VARIANT := v1 >TPLINK_HWID := 0x3221 > - DEVICE_PACKAGES := kmod-usb2 kmod-usb-ledtrig-usbport >SUPPORTED_DEVICES += tl-mr3220 > endef > TARGET_DEVICES += tplink_tl-mr3220-v1 > @@ -238,7 +235,6 @@ define Device/tplink_tl-wr703n >$(Device/tplink-4mlzma) >SOC := ar9331 >DEVICE_MODEL := TL-WR703N > - DEVICE_PACKAGES := kmod-usb-chipidea2 >TPLINK_HWID := 0x07030101 >SUPPORTED_DEVICES += tl-wr703n > endef > diff --git a/target/linux/ath79/image/tiny-ubnt.mk > b/target/linux/ath79/image/tiny-ubnt.mk > index a8c5a2cf68..be7dd46761 100644 > --- a/target/linux/ath79/image/tiny-ubnt.mk > +++ b/target/linux/ath79/image/tiny-ubnt.mk > @@ -31,7 +31,6 @@ endef > # UBNT_VERSION e.g. one of (6.0.0, 8.5.3) define Device/ubnt >DEVICE_VENDOR := Ubiquiti > - DEVICE_PACKAGES := kmod-usb2 >IMAGES += factory.bin >IMAGE/factory.bin := append-kernel | pad-to (BLOCKSIZE) | \ > append-rootfs | pad-rootfs | check-size | mkubntimage-split @@ - > 40,7 +39,6 @@ endef define Device/ubnt-xm >$(Device/ubnt) >DEVICE_VARIANT := XM > - DEVICE_PACKAGES += kmod-usb-ohci >IMAGE_SIZE := 7448k >UBNT_BOARD := XM >UBNT_CHIP := ar7240 > diff --git a/target/linux/ath79/image/tiny.mk > b/target/linux/ath79/image/tiny.mk > index 83c34d718b..800b2055db 100644 > --- a/target/linux/ath79/image/tiny.mk > +++ b/target/linux/ath79/image/tiny.mk > @@ -34,7 +34,6 @@ define Device/pqi_air-pen >SOC := ar9330 >DEVICE_VENDOR := PQI >DEVICE_MODEL := Air-Pen > - DEVICE_PACKAGES := kmod-usb2 >IMAGE_SIZE := 7680k >SUPPORTED_DEVICES += pqi-air-pen > endef > diff --git a/target/linux/ath79/tiny/config-default > b/target/linux/ath79/tiny/config-default > index 42243cfc48..8a83323bc2 100644 > --- a/target/linux/ath79/tiny/config-default > +++ b/target/linux/ath79/tiny/config-default > @@ -7,7 +7,8 @@ CONFIG_NET_DSA_MV88E6060=y > CONFIG_NET_DSA_TAG_TRAILER=y CONFIG_NET_SWITCHDEV=y > CONFIG_PHYLINK=y -CONFIG_PHY_AR7100_USB=y - > CONFIG_PHY_AR7200_USB=y > +# CONFIG_PHY_AR7100_USB is not set > +# CONFIG_PHY_AR7200_USB is not set > CONFIG_REGULATOR=y > CONFIG_REGULATOR_FIXED_VOLTAGE=y > +# CONFIG_USB_SUPPORT is not set > -- > 2.20.1 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [RFC 0/5] ath79: add a lower RAM-using version of 8/32 devices
> I agree, that some of the "small_flash" defaults are probably not the optimal > choice for 8MB-flash devices. > A new subtarget might be an option, but is it really worth to define a new > one for "deprecated" boards? Esp. as it's to be expected that both will vanish > in the release following 20.xx. A new subtarget feels to me like just adding > additional maintenance and additional confusion to the users. IMO it's simply like this: "Do we want to specifically put efforts into providing a better _default_ experience for this subgroup of devices for a limited time." YES: Do it properly (which IMO means having a low-mem target for low-mem devices) NO: Leave the stuff as it is right now. I personally lean towards "No.". If people still want to use these devices, they are the ones who know best where they can disable stuff and where they can't. This is all perfectly possible with the current implementation as it is right now. As you state yourself, the devices still work well with standard OpenWrt. The problems arise when you add additional features to them. So, it seems logical to me that you address the results of these additional features at the place where you introduce them, as you will actually know the precise nature of the use case (while we can just provide a framework for a myriad of possible scenarios). > > Adrian, as you mentioned there is currently only one board build for ath79- > tiny at all. So it's a target that might not be interesting for the average > user at > all. For this it might be a good idea to stop now building this target anyway > in > favor of using the build ressouces more effectively. Getting more images for > the tiny-subtarget will only change when customizing the config . > > By writing this I wonder if it gives sense to add a new subtarget "deprecated" > (to all relevant targets) to include all boards that might fall out of support > "soon" as of limited ressources? This will be a clear statement to the users > and even easy to determ, when a board belonge to this subtarget. As we > currently see "tiny" was introduced for the 4/32MB boards but in the > meanwhile should include the 8/32MB boards, too. In the "next wave" I > assume 8/64MB boards will belong to this category in some years. Very likely > the 4/32 and > 8/32 boards have become unsupportable then anyway and removed from > the code- basis. That's the task of documentation, not of code. Again, we have to distinguish between default builds (buildbots) and support itself. If a device can't be built anymore by buildbots (or is really broken otherwise), it gets disabled via "DEFAULT := n". Any other action of rearrangement would just increase the chance of breaking it with no reason. A deprecated target would even more increase the necessity to maintain config etc. for devices nobody uses anymore. In contrast, with the current setup we essentially still maintain the 8/32 accidentally as we maintain the rest and they benefit from it. I do see no reason to change that. > > > I also ran a quick check on the usage of the "small_flash" and "low_mem" flag > features. They are defined for some targets and used to set the > "SMALL_FLASH" > and "LOW_MEMORY_FOOTPRINT" config-features. But there seems no > other use of them, or did I miss something? If I'm right, the most difference > between generic and tiny is the "config-default" file. > When there is no further use of the features, it's nor probably an option to > think of combining both into something like "low_ressources". Based on this > some default config-choices can be changed, like "optimize for size", > disabling some "comfort features". As said before, a smaller binary / kernel > will save flash-space and RAM-space, even the flash-space might not be > relevant for all "low_ressources" boards. Yes, but what falls into which category is always a matter of judgement. Otherwise, we would just enable small_flash and low_mem for all devices ... Best Adrian > > Sven > > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [RFC 0/5] ath79: add a lower RAM-using version of 8/32 devices
> Having all this features diabled gives for the kernel of a Nanostation M XM > ubnt_nanostation-m-kernel.bin: > - ath79-generic: 1792151 > - ath79-tiny: 1500108 > vmlinux: > - ath79-generic: 5588220 > - ath79-tiny: 4687644 > > So a bit more than 16% smaller size, or 900k absolute. A direct runtime > comparision I can't provide at the moment, as my test device is running other > stuff already. This doesn't look like buildbot settings. If we discuss default setup/images here, we should discuss buildbot figures as this will involve a lot of additional symbols enabled that might change the situation drastically. So, buildbot settings and all feeds installed should be the setup. Best Adrian > > Sven > > > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: ramips: add support for Xiaomi Mi Router 4AC (100M Edition)
> -Original Message- > From: Sorin Pop [mailto:alexsorin...@gmail.com] > Sent: Sonntag, 6. Dezember 2020 02:06 > To: Adrian Schmutzler > Cc: openwrt-devel@lists.openwrt.org > Subject: Re: ramips: add support for Xiaomi Mi Router 4AC (100M Edition) > > The difference is the size of the overlay and partition table and the uboot > that is used on the devices. > > xiaomi_mir4a-100m uses bc16 as entry point and xiaomi_mir4ac-100m > uses bc26 as entry point > > from what I have seen mir4a is a CN version of MIR4AC which is EU. What about WAN MAC address? Do you deviate from the MIR4A setup by intention there? Can you link to any documentation about the MIR4AC? Best Adrian > > On Sun, Dec 6, 2020 at 2:38 AM Adrian Schmutzler > wrote: > > > > > -Original Message- > > > From: openwrt-devel [mailto:openwrt-devel- > boun...@lists.openwrt.org] > > > On Behalf Of Sorin Pop > > > Sent: Sonntag, 6. Dezember 2020 00:54 > > > To: openwrt-devel@lists.openwrt.org > > > Subject: ramips: add support for Xiaomi Mi Router 4AC (100M Edition) > > > > > > - SoC: MediaTek MT7628AN > > > - Flash:16MB (Winbond W25Q128JV) > > > - RAM: 64MB > > > - Serial: As marked on PCB, 3V3 logic, baudrate is 115200 > > > - Ethernet: 3x 10/100 Mbps (switched, 2x LAN + WAN) > > > - WIFI0:MT7628AN 2.4GHz 802.11b/g/n > > > - WIFI1:MT7612EN 5GHz 802.11ac > > > - Antennas: 4x external (2 per radio), non-detachable > > > - LEDs: Programmable power-LED (two-colored, yellow/blue) > > > Non-programmable internet-LED (shows WAN-activity) > > > - Buttons: Reset > > > > So, the only difference in implementation is the size of overlay/firmware > partitions? > > > > Best > > > > Adrian > > > > > > > > INSTALLATION: > > > > > > 1. Connect to the serial port of the router and power it up. > > >If you get a prompt asking for boot-mode, go to step 3. > > > 2. Unplug the router after > > >> Erasing SPI Flash... > > >> raspi_erase: offs:2 len:1 > > >occurs on the serial port. Plug the router back in. > > > 3. At the prompt select option 2 (Load system code then > > >write to Flash via TFTP.) > > > 4. Enter 192.168.1.1 as the device IP and 192.168.1.2 as the > > >Server-IP. > > > 5. Connect your computer to LAN1 and assign it as 192.168.1.2/24. > > > 6. Serve the sysupgrade image via TFTP > > > > > > This router seems to have the same hardware as Xiaomi Mi Router 4A > > > (100M > > > Edition) but it uses a different U-Boot. > > > > > > Signed-off-by: Sorin Pop > > > > -- > Sorin Alexandru Pop > Tel: +40-723-346437 openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: ramips: add support for Xiaomi Mi Router 4AC (100M Edition)
> -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Sorin Pop > Sent: Sonntag, 6. Dezember 2020 02:06 > To: Adrian Schmutzler > Cc: openwrt-devel@lists.openwrt.org > Subject: Re: ramips: add support for Xiaomi Mi Router 4AC (100M Edition) > > The difference is the size of the overlay and partition table and the uboot > that is used on the devices. > > xiaomi_mir4a-100m uses bc16 as entry point and xiaomi_mir4ac-100m > uses bc26 as entry point > > from what I have seen mir4a is a CN version of MIR4AC which is EU. And could you please check whether this runs with spi-max-frequency = 40 MHz like mi-router-4c does? Best Adrian > > On Sun, Dec 6, 2020 at 2:38 AM Adrian Schmutzler > wrote: > > > > > -Original Message- > > > From: openwrt-devel [mailto:openwrt-devel- > boun...@lists.openwrt.org] > > > On Behalf Of Sorin Pop > > > Sent: Sonntag, 6. Dezember 2020 00:54 > > > To: openwrt-devel@lists.openwrt.org > > > Subject: ramips: add support for Xiaomi Mi Router 4AC (100M Edition) > > > > > > - SoC: MediaTek MT7628AN > > > - Flash:16MB (Winbond W25Q128JV) > > > - RAM: 64MB > > > - Serial: As marked on PCB, 3V3 logic, baudrate is 115200 > > > - Ethernet: 3x 10/100 Mbps (switched, 2x LAN + WAN) > > > - WIFI0:MT7628AN 2.4GHz 802.11b/g/n > > > - WIFI1:MT7612EN 5GHz 802.11ac > > > - Antennas: 4x external (2 per radio), non-detachable > > > - LEDs: Programmable power-LED (two-colored, yellow/blue) > > > Non-programmable internet-LED (shows WAN-activity) > > > - Buttons: Reset > > > > So, the only difference in implementation is the size of overlay/firmware > partitions? > > > > Best > > > > Adrian > > > > > > > > INSTALLATION: > > > > > > 1. Connect to the serial port of the router and power it up. > > >If you get a prompt asking for boot-mode, go to step 3. > > > 2. Unplug the router after > > >> Erasing SPI Flash... > > >> raspi_erase: offs:2 len:1 > > >occurs on the serial port. Plug the router back in. > > > 3. At the prompt select option 2 (Load system code then > > >write to Flash via TFTP.) > > > 4. Enter 192.168.1.1 as the device IP and 192.168.1.2 as the > > >Server-IP. > > > 5. Connect your computer to LAN1 and assign it as 192.168.1.2/24. > > > 6. Serve the sysupgrade image via TFTP > > > > > > This router seems to have the same hardware as Xiaomi Mi Router 4A > > > (100M > > > Edition) but it uses a different U-Boot. > > > > > > Signed-off-by: Sorin Pop > > > > -- > Sorin Alexandru Pop > Tel: +40-723-346437 > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: ramips: Strange boot failures on TP-Link RE200v1
> -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Andreas Böhler > Sent: Dienstag, 8. Dezember 2020 19:43 > To: openwrt-devel@lists.openwrt.org > Subject: Re: ramips: Strange boot failures on TP-Link RE200v1 > > On 08/12/2020 00:53, Alberto Bursi wrote: > > > > On 08/12/20 00:12, Andreas Böhler wrote: > >> I added TP-Link RE200v1 device support a few months ago. Currently, > >> the snapshot builds are broken - they started to break about 4 weeks ago. > >> The system does not even boot, the last output on serial is "Starting > >> kernel ..." from U-Boot. The initramfs image works fine. > >> > >> The interesting thing is: all my local builds run perfectly fine, > >> from RAM or from flash. If I sysupgrade to snapshot, even the > >> snapshot build boots and runs fine as long as the device is not > >> unplugged for longer than about a minute. > >> > >> As I can't reproduce this behaviour with my build, I'm out of ideas. > >> Can someone give me an idea on what might cause this? > >> > > maybe the build defaults for buildbot are broken. > > > > You can enable that in the menu > > > > Global build settings ---> > > > > and then select > > > > Set build defaults for automatic builds (e.g. via buildbot) > > Interesting option that I wasn't aware of. Didn't change anything, > though: my build still works properly. Can be different again if you pull and install all feeds (like the buildbots actually do). > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH 1/2] uboot-envtools: add support for multiple config partitions
Please bump PKG_RELEASE
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Bjørn Mork
> Sent: Donnerstag, 10. Dezember 2020 13:40
> To: openwrt-devel@lists.openwrt.org
> Cc: Bjørn Mork
> Subject: [PATCH 1/2] uboot-envtools: add support for multiple config
> partitions
>
> Most (all?) of the realtek devices have two u-boot config partitions with a
> different set of variables in each. The U-Boot shell provides two sets of apps
> to manipulate these:
>
> printenv- print environment variables
> printsys- printsys - print system information variables saveenv - save
> environment variables to persistent storage savesys - savesys - save system
> information variables to persistent storage setenv - set environment
> variables setsys - setsys - set system information variables
>
> Add support for multiple ubootenv configuration types, allowing more than
> one configuration file.
>
> Section names are not suitable for naming the different configurations since
> each file can be the result of multiple sections in case of backup partitions.
>
> Signed-off-by: Bjørn Mork
> ---
> package/boot/uboot-envtools/Makefile | 1 +
> package/boot/uboot-envtools/files/realtek | 8 +++-
> .../uboot-envtools/files/uboot-envtools.sh| 38 ---
> 3 files changed, 32 insertions(+), 15 deletions(-)
>
> diff --git a/package/boot/uboot-envtools/Makefile b/package/boot/uboot-
> envtools/Makefile
> index 590e38d8831a..601627011d56 100644
> --- a/package/boot/uboot-envtools/Makefile
> +++ b/package/boot/uboot-envtools/Makefile
> @@ -61,6 +61,7 @@ MAKE_FLAGS += \
> define Package/uboot-envtools/conffiles /etc/config/ubootenv
> /etc/fw_env.config
> +/etc/fw_sys.config
> endef
>
> define Package/uboot-envtools/install
> diff --git a/package/boot/uboot-envtools/files/realtek
> b/package/boot/uboot-envtools/files/realtek
> index cce0628ffcbb..b64bb23b0747 100644
> --- a/package/boot/uboot-envtools/files/realtek
> +++ b/package/boot/uboot-envtools/files/realtek
> @@ -15,15 +15,21 @@ zyxel,gs1900-10hp)
> idx="$(find_mtd_index u-boot-env)"
> [ -n "$idx" ] && \
> ubootenv_add_uci_config "/dev/mtd$idx" "0x0" "0x400"
> "0x1"
> + idx="$(find_mtd_index u-boot-env2)"
> + [ -n "$idx" ] && \
> + ubootenv_add_uci_sys_config "/dev/mtd$idx" "0x0"
> "0x1000" "0x1"
> ;;
> *)
> idx="$(find_mtd_index u-boot-env)"
> [ -n "$idx" ] && \
> ubootenv_add_uci_config "/dev/mtd$idx" "0x0" "0x1"
> "0x1"
> + idx="$(find_mtd_index u-boot-env2)"
> + [ -n "$idx" ] && \
> + ubootenv_add_uci_sys_config "/dev/mtd$idx" "0x0"
> "0x1000" "0x1"
> ;;
> esac
>
> config_load ubootenv
> -config_foreach ubootenv_add_app_config ubootenv
> +config_foreach ubootenv_add_app_config
>
> exit 0
> diff --git a/package/boot/uboot-envtools/files/uboot-envtools.sh
> b/package/boot/uboot-envtools/files/uboot-envtools.sh
> index 9218bc4e3912..980c9962b17c 100644
> --- a/package/boot/uboot-envtools/files/uboot-envtools.sh
> +++ b/package/boot/uboot-envtools/files/uboot-envtools.sh
> @@ -3,34 +3,44 @@
> # Copyright (C) 2011-2012 OpenWrt.org
> #
>
> -ubootenv_add_uci_config() {
> - local dev=$1
> - local offset=$2
> - local envsize=$3
> - local secsize=$4
> - local numsec=$5
> +_ubootenv_add_uci_config() {
> + local cfgtype=$1
> + local dev=$2
> + local offset=$3
> + local envsize=$4
> + local secsize=$5
> + local numsec=$6
> uci batch < -add ubootenv ubootenv
> -set ubootenv.@ubootenv[-1].dev='$dev'
> -set ubootenv.@ubootenv[-1].offset='$offset'
> -set ubootenv.@ubootenv[-1].envsize='$envsize'
> -set ubootenv.@ubootenv[-1].secsize='$secsize'
> -set ubootenv.@ubootenv[-1].numsec='$numsec'
> +add ubootenv $cfgtype
> +set ubootenv.@$cfgtype[-1].dev='$dev'
> +set ubootenv.@$cfgtype[-1].offset='$offset'
> +set ubootenv.@$cfgtype[-1].envsize='$envsize'
> +set ubootenv.@$cfgtype[-1].secsize='$secsize'
> +set ubootenv.@$cfgtype[-1].numsec='$numsec'
> EOF
> uci commit ubootenv
> }
>
> +ubootenv_add_uci_config() {
> + _ubootenv_add_uci_config "ubootenv" "$@"
> +}
> +
> +ubootenv_add_uci_sys_config() {
> + _ubootenv_add_uci_config "ubootsys" "$@"
> +}
> +
> ubootenv_add_app_config() {
> + local cfgtype
> local dev
> local offset
> local envsize
> local secsize
> local numsec
> + config_get cfgtype "$1" TYPE
> config_get dev "$1" dev
> config_get offset "$1" offset
> config_get envsize "$1" envsize
> config_get secsize "$1" secsize
> config_get numsec "$1" numsec
> - grep -q "^[[:space:]]*${dev}[[:space:]]*${offset}"
> /etc/fw_env.config || echo "$dev $offset $envsize $secsize $numsec"
> >>/etc/fw_env.config
> + grep -q "^[[:space:]]*${dev}[[:space:]]*${offset}"
> "/etc/fw_${cfgtype#uboot}.config" || echo "$dev $of
RE: [PATCH] build/prereq: requie make 4.1 or later
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Paul Spooren > Sent: Sonntag, 13. Dezember 2020 08:17 > To: openwrt-devel@lists.openwrt.org > Cc: Paul Spooren > Subject: [PATCH] build/prereq: requie make 4.1 or later there is a typo in the title. Best Adrian > > FS#2086 "IS_TTY in the makefile is broken" reports flawed detection of > stdout piping to a file. The issue describes how e.g. terminal color codes and > up in log files if running make like `make > log.txt`. > > The proposed solution uses the make variable "MAKE_TERMOUT", which > was introduced in make 4.1. All major distributions seem to updated to 4.1 or > later, so this ideally dosn't break anything. > > Signed-off-by: Paul Spooren > --- > include/prereq-build.mk | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/include/prereq-build.mk b/include/prereq-build.mk index > 5045fabdfb..ad204e95e8 100644 > --- a/include/prereq-build.mk > +++ b/include/prereq-build.mk > @@ -14,8 +14,8 @@ PKG_NAME:=Build dependency > > # Required for the toolchain > $(eval $(call TestHostCommand,working-make, \ > - Please install GNU make v3.82 or later. (This version has bugs), \ > - $(MAKE) -v | grep -E 'Make (3\.8[2-9]|3\.9[0-9]|[4-9]\.)')) > + Please install GNU make v4.1 or later., \ > + $(MAKE) -v | grep -E 'Make (4\.[1-9]|[5-9]\.)')) > > $(eval $(call TestHostCommand,case-sensitive-fs, \ > OpenWrt can only be built on a case-sensitive filesystem, \ > -- > 2.29.2 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH] procd: add info json output
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Florian Eckert
> Sent: Montag, 14. Dezember 2020 13:36
> To: dan...@makrotopia.org
> Cc: openwrt-devel@lists.openwrt.org; Florian Eckert ;
> florian.eck...@googlemail.com
> Subject: [PATCH] procd: add info json output
please bump PKG_RELEASE for both packages.
Best
Adrian
>
> By adding the extra command `info` it is now possible to retrieve all relevant
> data from a procd started service directly via the init script.
>
> Until now, you have to query the ubus with the command:
> ubus call service list '{"name":"","verbose":true}'
>
> With this change, the init script is now used with the command:
> /etc/init.d/ info
>
> Signed-off-by: Florian Eckert
> ---
> package/base-files/files/etc/rc.common | 5 +
> package/system/procd/files/procd.sh| 14 ++
> 2 files changed, 19 insertions(+)
>
> diff --git a/package/base-files/files/etc/rc.common b/package/base-
> files/files/etc/rc.common
> index f39b69464e..c7fde31d41 100755
> --- a/package/base-files/files/etc/rc.common
> +++ b/package/base-files/files/etc/rc.common
> @@ -121,6 +121,7 @@ extra_command "enabled" "Check if service is started
> on boot"
> extra_command "running" "Check if service is running"
> extra_command "status" "Service status"
> extra_command "trace" "Start with syscall trace"
> + extra_command "info" "Dump service info as json"
>
> . $IPKG_INSTROOT/lib/functions/procd.sh
> basescript=$(readlink "$initscript")
> @@ -173,6 +174,10 @@ extra_command "enabled" "Check if service is
> started on boot"
> _procd_status "$(basename ${basescript:-
> $initscript})" "$1"
> fi
> }
> +
> + info() {
> + _procd_info "$(basename ${basescript:-$initscript})"
> + }
> }
>
> ALL_COMMANDS="${ALL_COMMANDS} ${EXTRA_COMMANDS}"
> diff --git a/package/system/procd/files/procd.sh
> b/package/system/procd/files/procd.sh
> index d86b7219da..1969cdf973 100644
> --- a/package/system/procd/files/procd.sh
> +++ b/package/system/procd/files/procd.sh
> @@ -474,6 +474,20 @@ _procd_status() {
> fi
> }
>
> +_procd_info() {
> + local service="$1"
> + local data
> +
> + data=$(_procd_ubus_call list | jsonfilter -e '@["'"$service"'"]')
> + [ -z "$data" ] && { echo "not found"; return 3; }
> +
> + json_init
> + json_add_string name "$service"
> + json_add_boolean verbose "1"
> + json_add_string name "$service"
> + _procd_ubus_call list
> +}
> +
> procd_open_data() {
> local name="$1"
> json_set_namespace procd __procd_old_cb
> --
> 2.20.1
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH] ramips: add support for GL.iNet GL-MT1300
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of xinfa.d...@gl-inet.com
> Sent: Montag, 14. Dezember 2020 10:55
> To: openwrt-devel@lists.openwrt.org
> Cc: GL.iNet-Xinfa.Deng
> Subject: [PATCH] ramips: add support for GL.iNet GL-MT1300
>
> From: "GL.iNet-Xinfa.Deng"
Please use a proper name of a person only both for From: and Signed-off-by:.
>
> The GL-MT1300 is a high-performance new generation pocket-sized router
> that offers a powerful hardware and first-class cybersecurity protocol with
> unique and modern design.
>
> Specifications:
> - SoC: MT7621A, Dual-Core @880MHz
> - RAM: 256 MB DDR3
> - Flash: 32 MB
> - Ethernet: 3 x 10/100/1000: 2 x LAN + 1 x WAN
> - Wireless: 1 x MT7615D Dual-Band 2.4GHz(400Mbps) + 5GHz(867Mbps)
> - USB: 1 x USB 3.0 port
> - Slot: 1 x MicroSD card slot
> - Button: 1 x Reset button
> - Switch: 1 x Mode switch
> - LED: 1 x Blue LED + 1 x White LED
>
> MAC addresses based on vendor firmware:
> WAN : factory 0x4000
> LAN : Mac from factory 0x4000 + 1
> 2.4GHz : factory 0x04
> 5GHz : Mac form factory 0x04 + 1
>
> For more information on GL-MT1300, see the OFFICIAL GL.iNet website:
> https://www.gl-inet.com/products/gl-mt1300/
>
> Signed-off-by: GL.iNet-Xinfa.Deng
> ---
> .../linux/ramips/dts/mt7621_glinet_gl-mt1300.dts | 157
> +
> target/linux/ramips/image/mt7621.mk| 9 ++
> .../mt7621/base-files/etc/board.d/02_network | 1 +
> .../etc/hotplug.d/ieee80211/10_fix_wifi_mac| 3 +
> 4 files changed, 170 insertions(+)
> create mode 100644 target/linux/ramips/dts/mt7621_glinet_gl-mt1300.dts
>
> diff --git a/target/linux/ramips/dts/mt7621_glinet_gl-mt1300.dts
> b/target/linux/ramips/dts/mt7621_glinet_gl-mt1300.dts
> new file mode 100644
> index 000..317a8f8
> --- /dev/null
> +++ b/target/linux/ramips/dts/mt7621_glinet_gl-mt1300.dts
> @@ -0,0 +1,157 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT /dts-v1/;
dts-v1 is in mt7621.dtsi now and can be dropped here.
> +
> +#include "mt7621.dtsi"
> +
> +#include
> +#include
> +
> +/ {
> + compatible = "glinet,gl-mt1300", "mediatek,mt7621-soc";
> + model = "GL.iNet GL-MT1300";
> +
> + aliases {
> + led-boot = &led_run;
> + led-failsafe = &led_run;
> + led-running = &led_run;
> + led-upgrade = &led_run;
> + };
Can you provide a label-mac-device here? Would be probably either &gmac or &wan
based on which interface matches the (first) MAC address on the device's
label/box.
> +
> + chosen {
> + bootargs = "console=ttyS0,115200";
> + };
> +
> + palmbus: palmbus@1E00 {
> + i2c@900 {
> + status = "okay";
> + };
> + };
Just use
&i2c {
status = "okay";
}
instead.
> +
> + keys {
> + compatible = "gpio-keys-polled";
> + poll-interval = <20>;
Using "gpio-keys" is preferred here.
> +
> + reset {
> + label = "reset";
> + gpios = <&gpio 18 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> +
> + BTN_0 {
> + label = "BTN_0";
It would be nice to use a more friendly name here. Might be just something
generic like "user" or "configurable" ...
> + gpios = <&gpio 16 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led_run: blue {
> + label = "gl-mt1300:blue";
The LED labels should be "color:function". Thus, you might probably want
something like "blue:run", "blue:system", "blue:power" or similar here.
> + gpios = <&gpio 14 GPIO_ACTIVE_HIGH>;
> + };
> +
> + white {
> + label = "gl-mt1300:white";
See above.
> + gpios = <&gpio 13 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +};
> +
> +&sdhci {
> + status = "okay";
> +};
> +
> +&spi0 {
> + status = "okay";
> +
> + m25p80@0 {
flash@0
> + compatible = "mx25l25635f", "jedec,spi-nor";
Is the first compatible value required?
> + reg = <0>;
> + spi-max-frequency = <1000>;
This probably can go much faster ...?
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition@0 {
> + label = "u-boot";
> + reg = <0x0 0x3>;
> + read-only;
> + };
> +
> + partition@3 {
> + label = "u-boot-env";
> + reg = <0x3 0x1>;
> +
RE: [PATCH 2/2] ath79: mojo c-75: use second flash chip
Hi, > -Original Message- > From: Tomasz Maciej Nowak [mailto:tmn...@gmail.com] > Sent: Dienstag, 8. Dezember 2020 18:05 > To: Adrian Schmutzler ; openwrt- > de...@lists.openwrt.org > Cc: 'Vladimir Georgievsky' > Subject: Re: [PATCH 2/2] ath79: mojo c-75: use second flash chip > > W dniu 01.12.2020 o 20:50, Adrian Schmutzler pisze: > >> diff --git a/target/linux/ath79/image/generic.mk > >> b/target/linux/ath79/image/generic.mk > >> index 0f90c00b9c43..b7618a8ab33c 100644 > >> --- a/target/linux/ath79/image/generic.mk > >> +++ b/target/linux/ath79/image/generic.mk > >> @@ -1199,7 +1199,7 @@ define Device/mojo_c-75 > >>DEVICE_ALT0_VENDOR := WatchGuard > >>DEVICE_ALT0_MODEL := AP320 > >>DEVICE_PACKAGES := ath10k-firmware-qca988x kmod-ath10k-ct kmod- > >> usb2 > >> - IMAGE_SIZE := 15936k > >> + IMAGE_SIZE := 32320k > > > > I'm not sure whether that's possible or whether the image itself is > restricted to a single consecutive area to be written to (i.e. the flash can > be > concatenated and used, but the _image_ is limited to the first partition _in_ > it) > > The mtd-concat creates virtual mtd device, which whole space we name as > 'firmware' partiton, and for kernel it's completely transparent, as for mtd- > splitter and mtd command. That might hold for OpenWrt-internal sysupgrade (I'm actually not sure here), but will it also be true for initial flashing? Best Adrian > > > > > Best > > > > Adrian > > Regards. > > -- > TMN openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH 1/2] ath79: add support for Mojo Networks AirTight C-75
Hi, only have time for a quick subset of answers: > -Original Message- > From: Tomasz Maciej Nowak [mailto:tmn...@gmail.com] > Sent: Dienstag, 8. Dezember 2020 17:53 > To: Adrian Schmutzler ; openwrt- > de...@lists.openwrt.org > Cc: 'Vladimir Georgievsky' > Subject: Re: [PATCH 1/2] ath79: add support for Mojo Networks AirTight C-75 > > Hi. > > W dniu 01.12.2020 o 20:47, Adrian Schmutzler pisze: > > Hi, > > > >> -Original Message- > >> From: openwrt-devel [mailto:openwrt-devel- > boun...@lists.openwrt.org] > >> On Behalf Of Tomasz Maciej Nowak > >> Sent: Dienstag, 1. Dezember 2020 18:36 > >> To: openwrt-devel@lists.openwrt.org > >> Cc: Vladimir Georgievsky > >> Subject: [PATCH 1/2] ath79: add support for Mojo Networks AirTight > >> C-75 > >> > >> Mojo Networks AirTight C-75 is a dual-band access point, also sold by > >> WatchGuard under name AP320. > >> > >> Specification > >> SoC: Qualcomm Atheros QCA9550 > >> RAM: 128 MiB DDR2 > >> Flash: 2x 16 MiB SPI NOR > >> WIFI: 2.4 GHz 3T3R integrated > >> 5 GHz 3T3R QCA9890 oversized Mini PCIe card > >> Ethernet: 2x 10/100/1000 Mbps QCA8334 > >> port labeled LAN1 is PoE capable (802.3at) > >> USB: 1x 2.0 > >> LEDs: 7x which two are GPIO controlled, four switch controlled, one > >> controlled by wireless driver > >> Buttons: 1x GPIO controlled > >> Serial: RJ-45 port, Cisco pinout > >> baud: 115200, parity: none, flow control: none > >> JTAG: Yes, pins marked J1 on PCB > >> > >> Installation > >> 1. Prepare TFTP server with OpenWrt initramfs-kernel image. > >> 2. Connect to one of LAN ports. > >> 3. Connect to serial port. > >> 4. Power on the device and when prompted to stop autoboot, hit any > key. > >> 5. Adjust "ipaddr" and "serverip" addresses in U-Boot environment, use > >>'setenv' to do that, then run following commands: > >> tftpboot 0x8100 > >> bootm 0x8100 > >> 6. Wait about 1 minute for OpenWrt to boot. > >> 7. Transfer OpenWrt sysupgrade image to /tmp directory and flash it > >>with: > >> sysupgrade -n /tmp/ > >> 8. After flashing, the access point will reboot to OpenWrt. Wait few > >>minutes, until the Power LED stops blinking, then it's ready for > >>configuration. > >> > >> Known issues > >> Green power LED does not work. > >> > >> Additional information > >> The U-Boot fails to initialise ethernet ports correctly when a UART > >> adapter is attached to UART pins (marked J3 on PCB). > >> > >> Cc: Vladimir Georgievsky > >> Signed-of-by: Tomasz Maciej Nowak > >> --- > >> package/boot/uboot-envtools/files/ath79 | 1 + > >> target/linux/ath79/dts/qca9550_mojo_c-75.dts | 173 > >> ++ > >> .../generic/base-files/etc/board.d/02_network | 4 + > >> target/linux/ath79/image/generic.mk | 11 ++ > >> 4 files changed, 189 insertions(+) > >> create mode 100644 target/linux/ath79/dts/qca9550_mojo_c-75.dts > >> > >> diff --git a/package/boot/uboot-envtools/files/ath79 > >> b/package/boot/uboot-envtools/files/ath79 > >> index 259c52c77034..a6b52b370530 100644 > >> --- a/package/boot/uboot-envtools/files/ath79 > >> +++ b/package/boot/uboot-envtools/files/ath79 > >> @@ -20,6 +20,7 @@ alfa-network,n5q|\ > >> alfa-network,pi-wifi4|\ > >> alfa-network,r36a|\ > >> allnet,all-wap02860ac|\ > >> +airtight,c-75|\ > > > > This is inconsistent with the other names. See more detailed comment > below. > > Oops, that chunk should have been removed. We don't alter U-Boot > environment on OpenWrt installation, so users don't need access to that. > > > > >> arduino,yun|\ > >> buffalo,bhr-4grv2|\ > >> devolo,magic-2-wifi|\ > >> diff --git a/target/linux/ath79/dts/qca9550_mojo_c-75.dts > >> b/target/linux/ath79/dts/qca9550_mojo_c-75.dts > >> new file mode 100644 > >> index ..51046a740a02 > >> --- /dev/null > >> +++ b/target/linux/ath79/dts/qca9550_mojo_c-75.dts > >> @@ -0,0 +1,173 @@ > >> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT > >> + > >> +#include > >> +#include > >> + > >> +#include "qca955
RE: Preparing commit description for "ramips: disable default build for HooToo HT-TM02"
Sorry, I don't understand what this is about.
Do you want to disable that device by default? Then just put DEFAULT := n into
the device definition.
Do you want to improve the support? Then you might need to rephrase the
"question".
Best
Adrian
> -Original Message-
> From: Szabolcs Hubai [mailto:szab...@gmail.com]
> Sent: Dienstag, 8. Dezember 2020 01:37
> To: openwrt-devel@lists.openwrt.org
> Cc: Russell Morris ; Adrian Schmutzler
> ; David Bauer
> Subject: Re: Preparing commit description for "ramips: disable default build
> for HooToo HT-TM02"
>
> On 12/8/20 12:08 AM, Szabolcs Hubai wrote:
> > Hi,
> >
> >
> > I planned to refresh the support of a rt305x SunValley Filehub device:
> > HooToo HT-TM02.
> >
> > I wanted to follow Adrian's and Russel's work for HooToo HT-TM05 and
> > RAVPower RP-WD03 in mt7620 [0].
> >
> >
> > I toought disabling the image generation would be easy, as binwalk
> > showed an oversized kernel: "image size: 1624829 bytes", so it won't
> > boot anyway.
> >
> > DECIMAL HEXADECIMAL DESCRIPTION
> >
> > 0 0x0 uImage header, header size: 64 bytes,
> > header CRC: 0xCB63E9C7, created: 2020-12-06 08:18:07, image size:
> > 1624829 bytes, Data Address: 0x8000, Entry Point: 0x8000, data
> > CRC: 0x10379393, OS: Linux, CPU: MIPS, image type: OS Kernel Image,
> > compression type: lzma, image name: "MIPS OpenWrt Linux-5.4.81"
> > 640x40LZMA compressed data, properties: 0x6D,
> > dictionary size: 8388608 bytes, uncompressed size: 5182719 bytes
> > 5493110x861BF Cisco IOS microcode, for ""
> >
> >
> > But I was unable to verify this because of the following:
> > - wingspinner's uboot [1],[2],[3] reads successfully the whole kernel,
> > but throws "LZMA ERROR 1 - must RESET board to recover" - which is
> > maybe fixable by $(Device/uimage-lzma-loader)
> > - original u-boot loads and boots nicely the oversized kernel
>
> To be correct:
> - original u-boot is able to boot the oversized kernel only when it was
> flashed
> through serial access ("IOVST MAIN MENU" -> "U SPIFlash Upgrade")
> - original u-boot throws "Bad Data CRC" when the oversized kernel is flashed
> through reset button TFTP recovery (10.10.10.254 + "kernel").
>
>
> Cheers,
> Szabolcs
>
>
> >
> >
> > And all compatible rt305x devices (HT-TM02, HT-TM01, RP-WD02 and
> maybe
> > RP-WD01) uses wingspinner's image, as it is installable through the
> > OEM web interface. And it comes with he's custom uboot.
> >
> >
> > What should I write in the commit description now?
> >
> >
> > My plans on refreshing have bad times too as the OKLI Loader is unable
> > to find the "OKLI" magic as the device doesn't map the flash to any
> > memory address.
> >
> > While David ported official U-Boot to ramips target already with the
> > RAVPower RP-WD009 support, I'm little bit afraid of my success porting
> > it to rt305x as U-Boot doesn't have "rt5350.dtsi" to start with.
> >
> >
> >
> > May I ask for help not just for commit description but for creating a
> > second stage loader for ramips/rt305x too?
> >
> >
> >
> > Thanks,
> > Szabolcs
> >
> >
> >
> > [0]:
> >
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=log;h=c4110a524e9a026
> > cf570b6dadf325c037b7527d0
> > [1]: https://openwrt.org/toh/hootoo/tripmate-nano#supported_versions
> > [2]: https://forum.archive.openwrt.org/viewtopic.php?id=53014
> > [3]:
> > https://github.com/wingspinner/HooToo-Tripmate-HT-TM02-
> OpenWRT/tree/ma
> > ster/uboot
> >
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH 1/2] ramips: add support for ELECOM WRC-1167GS2-B
Hi,
>
> I've tested it, but doesn't work.
Okay, it was worth a try. Maybe it's a similar driver issue on ramips like that
one we had about one year ago, where a similar case was not "picked up" from
10_fix_wifi_mac for a single radio ...
Best
Adrian
>
> I made the following change,
>
> ```
>
> diff --git
> a/target/linux/ramips/mt7621/base-
> files/etc/hotplug.d/ieee80211/10_fix_wifi_mac
> b/target/linux/ramips/mt7621/base-
> files/etc/hotplug.d/ieee80211/10_fix_wifi_mac
> index b7a41f038c..f0093d4337 100644
> ---
> a/target/linux/ramips/mt7621/base-
> files/etc/hotplug.d/ieee80211/10_fix_wifi_mac
> +++
> b/target/linux/ramips/mt7621/base-
> files/etc/hotplug.d/ieee80211/10_fix_wifi_mac
> @@ -10,6 +10,14 @@ PHYNBR=${DEVPATH##*/phy}
> board=$(board_name)
>
> case "$board" in
> + elecom,wrc-1167gs2-b)
> + [ "$PHYNBR" = "1" ] && \
> + $(mtd_get_mac_binary factory 0x4) >
> /sys${DEVPATH}/macaddress
> + ;;
> + elecom,wrc-1167gst2)
> + [ "$PHYNBR" = "1" ] && \
> + macaddr_add $(mtd_get_mac_binary factory
> 0xe006) 2 > /sys${DEVPATH}/macaddress
> + ;;
> linksys,ea7300-v1|\
> linksys,ea7300-v2|\
> linksys,ea7500-v2)
>
> ```
>
> but iwinfo still reports the MAC address generated from phy0 by mt76
>
> driver.
>
> ```
>
> (WRC-1167GS2-B)
>
> root@OpenWrt:/# iwinfo
> wlan0 ESSID: unknown
> Access Point: 04:AB:18:58:2F:15
> Mode: Client Channel: unknown (unknown)
> Tx-Power: 3 dBm Link Quality: unknown/70
> Signal: unknown Noise: unknown
> Bit Rate: unknown
> Encryption: unknown
> Type: nl80211 HW Mode(s): 802.11bgnac
> Hardware: 14C3:7615 7615:14C3 [MediaTek MT7615E]
> TX power offset: none
> Frequency offset: none
> Supports VAPs: yes PHY name: phy0
>
> wlan1 ESSID: unknown
> Access Point: 86:AB:18:58:2F:15
> Mode: Client Channel: unknown (unknown)
> Tx-Power: 3 dBm Link Quality: unknown/70
> Signal: unknown Noise: unknown
> Bit Rate: unknown
> Encryption: unknown
> Type: nl80211 HW Mode(s): 802.11nac
> Hardware: 14C3:7615 7615:14C3 [MediaTek MT7615E]
> TX power offset: none
> Frequency offset: none
> Supports VAPs: yes PHY name: phy1
>
> root@OpenWrt:/# cat /sys/class/ieee80211/phy1/macaddress
> 86:ab:18:58:2f:15
>
> ```
>
> >> - Wi-Fi band on primary phy (2.4GHz) cannot be limitted by specifying
> >>ieee80211-freq-limit
> >>(fail to register secondary phy due to error)
> >> - mtd-mac-address in the wifi node is required for using
> >>mtd-mac-address-increment
> >>
> >> Signed-off-by: INAGAKI Hiroshi
> >> ---
> >> .../dts/mt7621_elecom_wrc-1167gs2-b.dts | 57 ++
> >> .../dts/mt7621_elecom_wrc-1167gsxx.dtsi | 179
> ++
> >> target/linux/ramips/image/mt7621.mk | 8 +
> >> 3 files changed, 244 insertions(+)
> >> create mode 100644
> >> target/linux/ramips/dts/mt7621_elecom_wrc-1167gs2-
> >> b.dts
> >> create mode 100644 target/linux/ramips/dts/mt7621_elecom_wrc-
> >> 1167gsxx.dtsi
> >>
> >> diff --git a/target/linux/ramips/dts/mt7621_elecom_wrc-1167gs2-b.dts
> >> b/target/linux/ramips/dts/mt7621_elecom_wrc-1167gs2-b.dts
> >> new file mode 100644
> >> index 00..af0c580c64
> >> --- /dev/null
> >> +++ b/target/linux/ramips/dts/mt7621_elecom_wrc-1167gs2-b.dts
> >> @@ -0,0 +1,57 @@
> >> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> >> +
> >> +#include "mt7621_elecom_wrc-1167gsxx.dtsi"
> >> +
> >> +/ {
> >> + compatible = "elecom,wrc-1167gs2-b", "mediatek,mt7621-soc";
> >> + model = "ELECOM WRC-1167GS2-B";
> >> +
> >> + aliases {
> >> + label-mac-device = &wan;
> >> + };
> >> +};
> >> +
> >> +&gmac0 {
> >> + mtd-mac-address = <&factory 0xfff4>; };
> >> +
> >> +&wan {
> >> + mtd-mac-address = <&factory 0xfffa>; };
> >> +
> >> +&partitions {
> >> + partition@5 {
> >> + compatible = "denx,uimage";
> >> + label = "firmware";
> >> + reg = <0x5 0xb0>;
> >> + };
> >> +
> >> + partition@b5 {
> >> + label = "tm_pattern";
> >> + reg = <0xb5 0x38>;
> >> + read-only;
> >> + };
> >> +
> >> + partition@ed {
> >> + label = "tm_key";
> >> + reg = <0xed 0x8>;
> >> + read-only;
> >> + };
> >> +
> >> + partition@f5 {
> >> + label = "nvram";
> >> + reg = <0xf5 0x3>;
> >> + read-only;
> >> + };
> >> +
> >> + partition@f8 {
> >> + label = "user_data";
> >> + reg = <0xf8 0x8>;
> >> + read-only;
> >> + };
> >> +};
> >> +
> >> +&wifi {
> >> + mtd-mac-address = <&factory 0x4>;
> >> + mtd-mac-address-increment = <(-1)>; };
> >> diff -
RE: [PATCH] ramips: add support for GL.iNet GL-MT1300
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of xinfa.d...@gl-inet.com
> Sent: Dienstag, 15. Dezember 2020 05:15
> To: openwrt-devel@lists.openwrt.org
> Cc: Xinfa Deng
> Subject: [PATCH] ramips: add support for GL.iNet GL-MT1300
>
> From: "Xinfa Deng"
>
> The GL-MT1300 is a high-performance new generation pocket-sized router
> that offers a powerful hardware and first-class cybersecurity protocol with
> unique and modern design.
>
> Specifications:
> - SoC: MT7621A, Dual-Core @880MHz
> - RAM: 256 MB DDR3
> - Flash: 32 MB
> - Ethernet: 3 x 10/100/1000: 2 x LAN + 1 x WAN
> - Wireless: 1 x MT7615D Dual-Band 2.4GHz(400Mbps) + 5GHz(867Mbps)
> - USB: 1 x USB 3.0 port
> - Slot: 1 x MicroSD card slot
> - Button: 1 x Reset button
> - Switch: 1 x Mode switch
> - LED: 1 x Blue LED + 1 x White LED
>
> MAC addresses based on vendor firmware:
> WAN : factory 0x4000
> LAN : Mac from factory 0x4000 + 1
> 2.4GHz : factory 0x4
> 5GHz : Mac form factory 0x4 + 1
Please add flashing instructions to the commit message, I assume they will be
short and relatively easy for this device ...
Three minor comments below.
> + leds {
> + compatible = "gpio-leds";
> +
> + led_run: blue {
Use function for node name instead, i.e.
led_run: run {
> + label = "blue:run";
> + gpios = <&gpio 14 GPIO_ACTIVE_HIGH>;
> + };
> +
> + white {
system {
> + label = "white:system";
> + gpios = <&gpio 13 GPIO_ACTIVE_HIGH>;
> + };
[...]
> case "$board" in
> + glinet,gl-mt1300)
> + [ "$PHYNBR" = "1" ] && macaddr_add
> "$(mtd_get_mac_binary factory 0x4)" 1 > /sys${DEVPATH}/macaddress
> + ;;
Have you verified that this is working (i.e. assigning the correct MAC address
to the second WiFi interface)?
Thanks
Adrian
> linksys,ea7300-v1|\
> linksys,ea7300-v2|\
> linksys,ea7500-v2)
> --
> 2.7.4
>
>
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH v2 1/2] uboot-envtools: add support for multiple config partitions
Hi, just a taste nitpick: > --- a/package/boot/uboot-envtools/files/realtek > +++ b/package/boot/uboot-envtools/files/realtek > @@ -15,15 +15,21 @@ zyxel,gs1900-10hp) > idx="$(find_mtd_index u-boot-env)" > [ -n "$idx" ] && \ > ubootenv_add_uci_config "/dev/mtd$idx" "0x0" "0x400" > "0x1" > + idx="$(find_mtd_index u-boot-env2)" > + [ -n "$idx" ] && \ > + ubootenv_add_uci_sys_config "/dev/mtd$idx" "0x0" I'd personally use a different variable name here, e.g. idx2, so it's clearly separated. BTW, if you only need the variable once, you can directly use logic on the assignment: + idx2="$(find_mtd_index u-boot-env2)" && + ubootenv_add_uci_sys_config "/dev/mtd$idx2" "0x0" Best Adrian openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH] ramips: add support for GL.iNet GL-MT1300
Hi,
quick final question, answer via e-mail should be enough, I'll change at my
tree then:
> + switch {
> + label = "switch";
> + gpios = <&gpio 16 GPIO_ACTIVE_LOW>;
> + linux,code = ;
If this is a "switch", I probably should add
linux,input-type = ;
here?
Best
Adrian
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH v2 2/2] ath79: airtight c-75: use second flash chip
Hi again,
one comment and a slightly conceptual question:
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Tomasz Maciej Nowak
> Sent: Dienstag, 15. Dezember 2020 18:17
> To: openwrt-devel@lists.openwrt.org
> Cc: Vladimir Georgievsky
> Subject: [PATCH v2 2/2] ath79: airtight c-75: use second flash chip
>
> The flash capacity is divided in two flash chips and currently only first is
> used.
> Increase available space for OpenWrt by additional 16 MiB using mtd-concat
> driver. Because U-Boot might not be able to load kernel image spanned
> through two flash chips, the size of kernel is limited to space available on
> first
> chip.
>
> Cc: Vladimir Georgievsky
> Signed-off-by: Tomasz Maciej Nowak
> ---
> v1 -> v2
>
> - add kernel size constraints
>
> .../linux/ath79/dts/qca9550_airtight_c-75.dts | 24 +++
> target/linux/ath79/image/generic.mk | 3 ++-
> 2 files changed, 21 insertions(+), 6 deletions(-)
>
> diff --git a/target/linux/ath79/dts/qca9550_airtight_c-75.dts
> b/target/linux/ath79/dts/qca9550_airtight_c-75.dts
> index 34d4c32b3562..c380a109c96b 100644
> --- a/target/linux/ath79/dts/qca9550_airtight_c-75.dts
> +++ b/target/linux/ath79/dts/qca9550_airtight_c-75.dts
> @@ -41,6 +41,23 @@
> linux,default-trigger = "phy1tpt";
> };
> };
> +
> + mtd-concat {
I think I will change the node name to virtual_flash, as that's the most common
case so far and I personally like it more.
> + compatible = "mtd-concat";
> + devices = <&concat0 &concat1>;
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition@0 {
> + label = "firmware";
> + reg = <0x0 0x1f9>;
> + compatible = "denx,uimage";
> + };
> + };
> + };
> };
>
> ð0 {
> @@ -120,10 +137,8 @@
> read-only;
> };
>
> - partition@6 {
> - label = "firmware";
> + concat0: partition@6 {
> reg = <0x06 0xf9>;
> - compatible = "denx,uimage";
> };
>
> art: partition@ff {
> @@ -144,8 +159,7 @@
> #address-cells = <1>;
> #size-cells = <1>;
>
> - partition@0 {
> - label = "opt";
I wonder what's best practice here:
Many devices keep a label here and just use names like "firmware1", "firmware2"
or similar.
Does it make sense to keep the concatenated partitions available under such a
name (because the user might want to do something with it) or would it be
better to remove the label and thus "hide" the partition (because the user
might want to do something with it)?
Best
Adrian
> + concat1: partition@0 {
> reg = <0x0 0x100>;
> };
> };
> diff --git a/target/linux/ath79/image/generic.mk
> b/target/linux/ath79/image/generic.mk
> index 177caafa2253..bdc35823c66c 100644
> --- a/target/linux/ath79/image/generic.mk
> +++ b/target/linux/ath79/image/generic.mk
> @@ -246,7 +246,8 @@ define Device/airtight_c-75
>DEVICE_ALT1_VENDOR := WatchGuard
>DEVICE_ALT1_MODEL := AP320
>DEVICE_PACKAGES := ath10k-firmware-qca988x kmod-ath10k-ct kmod-
> usb2
> - IMAGE_SIZE := 15936k
> + IMAGE_SIZE := 32320k
> + KERNEL_SIZE := 15936k
> endef
> TARGET_DEVICES += airtight_c-75
>
> --
> 2.29.2
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH v2 1/2] ath79: add support for AirTight C-75
Hi,
a few last-minute remarks. I plan to merge this afterwards.
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Tomasz Maciej Nowak
> Sent: Dienstag, 15. Dezember 2020 18:17
> To: openwrt-devel@lists.openwrt.org
> Cc: Vladimir Georgievsky
> Subject: [PATCH v2 1/2] ath79: add support for AirTight C-75
>
> AirTight Networks (later renamed to Mojo Networks) C-75 is a dual-band
> access point, also sold by WatchGuard under name AP320.
>
> Specification
> SoC: Qualcomm Atheros QCA9550
> RAM: 128 MiB DDR2
> Flash: 2x 16 MiB SPI NOR
> WIFI: 2.4 GHz 3T3R integrated
> 5 GHz 3T3R QCA9890 oversized Mini PCIe card
> Ethernet: 2x 10/100/1000 Mbps QCA8334
> port labeled LAN1 is PoE capable (802.3at)
> USB: 1x 2.0
> LEDs: 7x which two are GPIO controlled, four switch controlled, one
> controlled by wireless driver
> Buttons: 1x GPIO controlled
> Serial: RJ-45 port, Cisco pinout
> baud: 115200, parity: none, flow control: none
> JTAG: Yes, pins marked J1 on PCB
>
> Installation
> 1. Prepare TFTP server with OpenWrt initramfs-kernel image.
> 2. Connect to one of LAN ports.
> 3. Connect to serial port.
> 4. Power on the device and when prompted to stop autoboot, hit any key.
> 5. Adjust "ipaddr" and "serverip" addresses in U-Boot environment, use
>'setenv' to do that, then run following commands:
> tftpboot 0x8100
> bootm 0x8100
> 6. Wait about 1 minute for OpenWrt to boot.
> 7. Transfer OpenWrt sysupgrade image to /tmp directory and flash it
>with:
> sysupgrade -n /tmp/
> 8. After flashing, the access point will reboot to OpenWrt. Wait few
>minutes, until the Power LED stops blinking, then it's ready for
>configuration.
>
> Known issues
> Green power LED does not work.
>
> Additional information
> The U-Boot fails to initialise ethernet ports correctly when a UART adapter is
> attached to UART pins (marked J3 on PCB).
>
> Cc: Vladimir Georgievsky
> Signed-of-by: Tomasz Maciej Nowak
> ---
> v1 -> v2
>
> - rename primary device vendor (Mojo -> AirTight)
> - remove U-Boot environment definition
> - minor dts adjustments (no functional changes)
> - add additional DEVICE_ALTn variable
>
> .../linux/ath79/dts/qca9550_airtight_c-75.dts | 171 ++
> .../generic/base-files/etc/board.d/02_network | 4 +
> target/linux/ath79/image/generic.mk | 13 ++
> 3 files changed, 188 insertions(+)
> create mode 100644 target/linux/ath79/dts/qca9550_airtight_c-75.dts
>
> diff --git a/target/linux/ath79/dts/qca9550_airtight_c-75.dts
> b/target/linux/ath79/dts/qca9550_airtight_c-75.dts
> new file mode 100644
> index ..34d4c32b3562
> --- /dev/null
> +++ b/target/linux/ath79/dts/qca9550_airtight_c-75.dts
> @@ -0,0 +1,171 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +
> +#include "qca955x.dtsi"
> +
> +#include
> +#include
> +
> +/ {
> + model = "AirTight Networks C-75";
> + compatible = "airtight,c-75", "qca,qca9550", "qca,qca9558";
> +
> + aliases {
> + label-mac-device = ð0;
> + led-boot = &led_power;
> + led-failsafe = &led_power;
> + led-upgrade = &led_power;
> + };
> +
> + keys {
> + compatible = "gpio-keys";
> +
> + reset {
> + label = "reset";
> + linux,code = ;
> + gpios = <&gpio 17 GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led_power: power {
> + label = "amber:power";
> + gpios = <&gpio 14 GPIO_ACTIVE_HIGH>;
> + default-state = "on";
> + };
> +
> + wlan2g {
> + label = "green:wlan2g";
> + gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
> + linux,default-trigger = "phy1tpt";
> + };
> + };
> +};
> +
> +ð0 {
> + status = "okay";
> +
> + mtd-mac-address = <&art 0x0>;
> + phy-handle = <&phy0>;
> + phy-mode = "rgmii";
phy-mode is already set in qca955x.dtsi and can be removed here.
> + pll-data = <0xa600 0x0101 0x1616>; };
> +
> +&mdio0 {
> + status = "okay";
> +
> + phy0: ethernet-phy@0 {
> + reg = <0>;
> + qca,ar8327-initvals = <
> + 0x0c 0x00080080
> + 0x04 0x0760
> + 0x58 0xc935c935
> + 0x5c 0x0300
> + 0x7c 0x007e
> + 0x94 0x007e
> + >;
Please add comments here to help the reader, like other devices do, e.g.:
qca,ar8327-initvals = <
0x04 0x8760 /* PORT0 PAD MODE CTRL */
0x0c 0x00080080 /* PORT6 PAD MODE CTRL */
0x7c 0x007e /* PORT0_STATUS */
RE: [PATCHv2] ath79: Add support for Ubiquiti Bullet AC
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Russell Senior
> Sent: Mittwoch, 16. Dezember 2020 12:01
> To: openwrt-devel@lists.openwrt.org
> Subject: [PATCHv2] ath79: Add support for Ubiquiti Bullet AC
>
>
> CPU: Atheros AR9342 rev 3 SoC
> RAM: 64 MB DDR2
> Flash: 16 MB NOR SPI
> WLAN 2.4GHz: Atheros AR9342 v3 (ath9k)
> WLAN 5.0GHz: QCA988X
> Ports: 1x GbE
>
> Flashing procedure is identical to other ubnt devices.
> https://openwrt.org/toh/ubiquiti/common
>
> Flashing through factory firmware
> 1. Ensure firmware version v8.7.0 is installed.
>Up/downgrade to this exact version.
> 2. Patch fwupdate.real binary using
>`hexdump -Cv /bin/ubntbox | sed 's/14 40 fe 27/00 00 00 00/g' | \
> hexdump -R > /tmp/fwupdate.real`
> 3. Make the patched fwupdate.real binary executable using
>`chmod +x /tmp/fwupdate.real`
> 4. Copy the squashfs factory image to /tmp on the device 5. Flash OpenWrt
> using `/tmp/fwupdate.real -m ` 6. Wait for the
> device to reboot (copied from Ubiquiti NanoBeam AC and modified)
>
> Flashing from serial console
> 1. Connect serial console (115200 baud)
> 2. Connect ethernet to a network with a TFTP server, through a
>passive PoE injector.
> 3. Press a key to obtain a u-boot prompt 4. Set your TFTP server's ip address,
> with:
>setenv serverip 5. Set the Bullet AC's ip address,
> with:
>setenv ipaddr
> 6. Set the boot file, with:
>setenv bootfile
> 7. Fetch the binary with tftp:
>tftpboot
> 8. Boot the initramfs binary:
>bootm
> 9. From the initramfs, fetch the sysupgrade binary, and flash it with
>sysupgrade.
>
> Phy0 is QCA988X which can tune either band (2.4 or 5GHz). Phy1 is AR9342,
> on which 5GHz is disabled. It isn't currently known whether phy1 is routed to
> the N connector at all.
>
> Signed-off-by: Russell Senior
> ---
> v2:
> - Make "Flashing through factory firmware" instructions actually work by
> changing UBNT_TYPE to 2WA
> ---
> .../linux/ath79/dts/ar9342_ubnt_bullet-ac.dts | 38 +++
> .../generic/base-files/etc/board.d/01_leds| 1 +
> .../generic/base-files/etc/board.d/02_network | 1 +
> .../etc/hotplug.d/firmware/11-ath10k-caldata | 1 +
> target/linux/ath79/image/generic-ubnt.mk | 17 +
> 5 files changed, 58 insertions(+)
> create mode 100644 target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
>
> diff --git a/target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
> b/target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
> new file mode 100644
> index 00..be0b0792bb
> --- /dev/null
> +++ b/target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
> @@ -0,0 +1,38 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +#include "ar9342_ubnt_wa_1port.dtsi"
> +
> +/ {
> + compatible = "ubnt,bullet-ac", "ubnt,wa", "qca,ar9342";
> + model = "Ubiquiti Bullet AC (2WA)";
would you provide some details about that odd "2WA"?
> +
> + aliases {
> + led-boot = &led_rssi3;
> + led-failsafe = &led_rssi3;
> + led-upgrade = &led_rssi3;
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + rssi0 {
> + label = "blue:rssi0";
> + gpios = <&gpio 11 GPIO_ACTIVE_LOW>;
> + };
> +
> + rssi1 {
> + label = "blue:rssi1";
> + gpios = <&gpio 16 GPIO_ACTIVE_LOW>;
> + };
> +
> + rssi2 {
> + label = "blue:rssi2";
> + gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
> + };
> +
> + led_rssi3: rssi3 {
> + label = "blue:rssi3";
> + gpios = <&gpio 14 GPIO_ACTIVE_LOW>;
> + };
> + };
> +};
> diff --git a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
> b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
> index a0ed21e318..46d4650eac 100755
> --- a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
> +++ b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
> @@ -366,6 +366,7 @@ ubnt,rocket-m)
> ucidef_set_led_rssi "rssimediumhigh" "RSSIMEDIUMHIGH"
> "green:link3" "wlan0" "51" "100"
> ucidef_set_led_rssi "rssihigh" "RSSIHIGH" "green:link4" "wlan0" "76"
> "100"
> ;;
> +ubnt,bullet-ac|\
This requires to move the block to keep sorting.
> ubnt,nanobeam-ac|\
> ubnt,nanobeam-ac-gen2|\
> ubnt,nanostation-ac|\
> diff --git a/target/linux/ath79/generic/base-files/etc/board.d/02_network
> b/target/linux/ath79/generic/base-files/etc/board.d/02_network
> index 905848a2ba..9293e5522b 100755
> --- a/target/linux/ath79/generic/base-files/etc/board.d/02_network
> +++ b/target/linux/ath79/generic/base-files/etc/board.d/02_network
> @@ -58,6 +58,7 @@ ath79_setup_interfaces()
> tplink,re450-v2|\
> tplink,re450-v3|\
> tplink,tl-wr902ac-v1|\
> + ubnt,bullet-ac|\
>
RE: [PATCH 1/2] ramips: add support for ELECOM WRC-1167GS2-B
Hi,
> >> Notes:
> >>
> >> - there is no way to configure the correct MAC address for secondary phy
> >>(5GHz) on MT7615D
> > This one seems to address a similar case (just scroll to the very bottom):
> >
> > https://patchwork.ozlabs.org/project/openwrt/patch/1607939702-85475-
> 1-
> > git-send-email-xinfa.d...@gl-inet.com/
> >
> > Would this work for you as well (at least for the MAC address)?
> >
> > Best
> >
> > Adrian
>
> I've tested it, but doesn't work.
>
> I made the following change,
sorry, but would you test again please with the 10_fix_wifi_mac changes and
recent master?
There have been several changes to mt76 in
b837534f029da10abbd1069392867e0700134ace that might be relevant/helping.
Best
Adrian
>
> ```
>
> diff --git
> a/target/linux/ramips/mt7621/base-
> files/etc/hotplug.d/ieee80211/10_fix_wifi_mac
> b/target/linux/ramips/mt7621/base-
> files/etc/hotplug.d/ieee80211/10_fix_wifi_mac
> index b7a41f038c..f0093d4337 100644
> ---
> a/target/linux/ramips/mt7621/base-
> files/etc/hotplug.d/ieee80211/10_fix_wifi_mac
> +++
> b/target/linux/ramips/mt7621/base-
> files/etc/hotplug.d/ieee80211/10_fix_wifi_mac
> @@ -10,6 +10,14 @@ PHYNBR=${DEVPATH##*/phy}
> board=$(board_name)
>
> case "$board" in
> + elecom,wrc-1167gs2-b)
> + [ "$PHYNBR" = "1" ] && \
> + $(mtd_get_mac_binary factory 0x4) >
> /sys${DEVPATH}/macaddress
> + ;;
> + elecom,wrc-1167gst2)
> + [ "$PHYNBR" = "1" ] && \
> + macaddr_add $(mtd_get_mac_binary factory
> 0xe006) 2 > /sys${DEVPATH}/macaddress
> + ;;
> linksys,ea7300-v1|\
> linksys,ea7300-v2|\
> linksys,ea7500-v2)
>
> ```
>
> but iwinfo still reports the MAC address generated from phy0 by mt76
>
> driver.
>
> ```
>
> (WRC-1167GS2-B)
>
> root@OpenWrt:/# iwinfo
> wlan0 ESSID: unknown
> Access Point: 04:AB:18:58:2F:15
> Mode: Client Channel: unknown (unknown)
> Tx-Power: 3 dBm Link Quality: unknown/70
> Signal: unknown Noise: unknown
> Bit Rate: unknown
> Encryption: unknown
> Type: nl80211 HW Mode(s): 802.11bgnac
> Hardware: 14C3:7615 7615:14C3 [MediaTek MT7615E]
> TX power offset: none
> Frequency offset: none
> Supports VAPs: yes PHY name: phy0
>
> wlan1 ESSID: unknown
> Access Point: 86:AB:18:58:2F:15
> Mode: Client Channel: unknown (unknown)
> Tx-Power: 3 dBm Link Quality: unknown/70
> Signal: unknown Noise: unknown
> Bit Rate: unknown
> Encryption: unknown
> Type: nl80211 HW Mode(s): 802.11nac
> Hardware: 14C3:7615 7615:14C3 [MediaTek MT7615E]
> TX power offset: none
> Frequency offset: none
> Supports VAPs: yes PHY name: phy1
>
> root@OpenWrt:/# cat /sys/class/ieee80211/phy1/macaddress
> 86:ab:18:58:2f:15
>
> ```
>
> >> - Wi-Fi band on primary phy (2.4GHz) cannot be limitted by specifying
> >>ieee80211-freq-limit
> >>(fail to register secondary phy due to error)
> >> - mtd-mac-address in the wifi node is required for using
> >>mtd-mac-address-increment
> >>
> >> Signed-off-by: INAGAKI Hiroshi
> >> ---
> >> .../dts/mt7621_elecom_wrc-1167gs2-b.dts | 57 ++
> >> .../dts/mt7621_elecom_wrc-1167gsxx.dtsi | 179
> ++
> >> target/linux/ramips/image/mt7621.mk | 8 +
> >> 3 files changed, 244 insertions(+)
> >> create mode 100644
> >> target/linux/ramips/dts/mt7621_elecom_wrc-1167gs2-
> >> b.dts
> >> create mode 100644 target/linux/ramips/dts/mt7621_elecom_wrc-
> >> 1167gsxx.dtsi
> >>
> >> diff --git a/target/linux/ramips/dts/mt7621_elecom_wrc-1167gs2-b.dts
> >> b/target/linux/ramips/dts/mt7621_elecom_wrc-1167gs2-b.dts
> >> new file mode 100644
> >> index 00..af0c580c64
> >> --- /dev/null
> >> +++ b/target/linux/ramips/dts/mt7621_elecom_wrc-1167gs2-b.dts
> >> @@ -0,0 +1,57 @@
> >> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> >> +
> >> +#include "mt7621_elecom_wrc-1167gsxx.dtsi"
> >> +
> >> +/ {
> >> + compatible = "elecom,wrc-1167gs2-b", "mediatek,mt7621-soc";
> >> + model = "ELECOM WRC-1167GS2-B";
> >> +
> >> + aliases {
> >> + label-mac-device = &wan;
> >> + };
> >> +};
> >> +
> >> +&gmac0 {
> >> + mtd-mac-address = <&factory 0xfff4>; };
> >> +
> >> +&wan {
> >> + mtd-mac-address = <&factory 0xfffa>; };
> >> +
> >> +&partitions {
> >> + partition@5 {
> >> + compatible = "denx,uimage";
> >> + label = "firmware";
> >> + reg = <0x5 0xb0>;
> >> + };
> >> +
> >> + partition@b5 {
> >> + label = "tm_pattern";
> >> + reg = <0xb5 0x38>;
> >> + read-only;
> >> + };
> >> +
> >> + partition@ed {
> >> + label = "tm_key";
> >> + reg = <0xed 0x8>;
> >> + read-only;
>
RE: [PATCH 1/2] ramips: add support for ELECOM WRC-1167GS2-B
Hi,
> -Original Message-
> From: INAGAKI Hiroshi [mailto:musashino.o...@gmail.com]
> Sent: Samstag, 19. Dezember 2020 14:54
> To: Adrian Schmutzler ; openwrt-
> de...@lists.openwrt.org
> Subject: Re: [PATCH 1/2] ramips: add support for ELECOM WRC-1167GS2-B
okay, looks like we can't fix it for now.
I'm considering to merge it in the current state, as the only unfixed issues
appear to be the MAC address and the frequency limiting, so the device is
generally working?
I've tried to mess with the DTSI files so we can reuse the existing
mt7621_elecom_wrc-gs.dtsi. The result has been pushed to my staging:
https://git.openwrt.org/?p=openwrt/staging/adrian.git;a=shortlog;h=refs/heads/staging
Please tell me whether you like it or not. Not liking it is also okay ;-)
Best
Adrian
>
> Hello,
>
> On 2020/12/19 9:22, Adrian Schmutzler wrote:
> > Hi,
> >
> >>>> Notes:
> >>>>
> >>>> - there is no way to configure the correct MAC address for secondary
> phy
> >>>> (5GHz) on MT7615D
> >>> This one seems to address a similar case (just scroll to the very bottom):
> >>>
> >>> https://patchwork.ozlabs.org/project/openwrt/patch/1607939702-
> 85475-
> >> 1-
> >>> git-send-email-xinfa.d...@gl-inet.com/
> >>>
> >>> Would this work for you as well (at least for the MAC address)?
> >>>
> >>> Best
> >>>
> >>> Adrian
> >> I've tested it, but doesn't work.
> >>
> >> I made the following change,
> > sorry, but would you test again please with the 10_fix_wifi_mac changes
> and recent master?
> >
> > There have been several changes to mt76 in
> b837534f029da10abbd1069392867e0700134ace that might be
> relevant/helping.
> >
> > Best
> >
> > Adrian
>
> Thank you for letting me know.
>
> I tried the same modification I did, but it still doesn't works. After that
>
> bumping of mt76, secondary phy (ext_phy) uses the same MAC address with
> primary
>
> phy (for 2.4GHz) and the address for secondary phy cannot be configured by
>
> 10_fix_wifi_mac...
>
>
> ```
>
> (WRC-1167GS2-B)
>
> root@OpenWrt:/# iwinfo
> wlan0 ESSID: unknown
> Access Point: 04:AB:18:58:2F:15
> Mode: Client Channel: unknown (unknown)
> Tx-Power: 3 dBm Link Quality: unknown/70
> Signal: unknown Noise: -92 dBm
> Bit Rate: unknown
> Encryption: unknown
> Type: nl80211 HW Mode(s): 802.11bgnac
> Hardware: 14C3:7615 7615:14C3 [MediaTek MT7615E]
> TX power offset: none
> Frequency offset: none
> Supports VAPs: yes PHY name: phy0
>
> wlan1 ESSID: unknown
> Access Point: 04:AB:18:58:2F:15
> Mode: Client Channel: unknown (unknown)
> Tx-Power: 20 dBm Link Quality: unknown/70
> Signal: unknown Noise: -92 dBm
> Bit Rate: unknown
> Encryption: unknown
> Type: nl80211 HW Mode(s): 802.11nac
> Hardware: 14C3:7615 7615:14C3 [MediaTek MT7615E]
> TX power offset: none
> Frequency offset: none
> Supports VAPs: yes PHY name: phy1
>
> root@OpenWrt:/# cat /sys/class/ieee80211/phy1/macaddress
> 04:ab:18:58:2f:15
> root@OpenWrt:/# . /lib/functions.sh; . /lib/functions/system.sh
> root@OpenWrt:/# mtd_get_mac_binary factory 0x4
> 04:ab:18:58:2f:16root@OpenWrt:/#
>
> ```
>
> regards,
>
> Hiroshi
>
> >> ```
> >>
> >> diff --git
> >> a/target/linux/ramips/mt7621/base-
> >> files/etc/hotplug.d/ieee80211/10_fix_wifi_mac
> >> b/target/linux/ramips/mt7621/base-
> >> files/etc/hotplug.d/ieee80211/10_fix_wifi_mac
> >> index b7a41f038c..f0093d4337 100644
> >> ---
> >> a/target/linux/ramips/mt7621/base-
> >> files/etc/hotplug.d/ieee80211/10_fix_wifi_mac
> >> +++
> >> b/target/linux/ramips/mt7621/base-
> >> files/etc/hotplug.d/ieee80211/10_fix_wifi_mac
> >> @@ -10,6 +10,14 @@ PHYNBR=${DEVPATH##*/phy}
> >> board=$(board_name)
> >>
> >> case "$board" in
> >> + elecom,wrc-1167gs2-b)
> >> + [ "$PHYNBR" = "1" ] && \
> >> + $(mtd_get_mac_binary factory 0x4) >
> >> /sys${DEVPATH}/macaddress
> >> + ;;
> >> + elecom,wrc-1167gst2)
> >> + [ "$PHYNBR" = "1" ] &am
RE: [PATCH] build: replace which with Bash command built-in
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Petr Štetiar
> Sent: Dienstag, 22. Dezember 2020 10:47
> To: openwrt-devel@lists.openwrt.org
> Cc: Petr Štetiar
> Subject: [PATCH] build: replace which with Bash command built-in
>
> `which` utility is not shipped by default for example on recent Arch Linux and
> then any steps relying on its presence fails, like for example following
> Python3 prereq build check:
>
> $ python3 --version
> Python 3.9.1
>
> $ make
> /bin/sh: line 1: which: command not found
> /bin/sh: line 1: which: command not found
> /bin/sh: line 1: which: command not found ...
> Checking 'python3'... failed.
> ...
>
> Fix this by switching to Bash builtin `command` which should provide same
> functionality.
>
> Fixes: FS#3525
> Signed-off-by: Petr Štetiar
> ---
>
> Other option is to check for `which` util presence in prereq-build and adding
> `which` to the list of required host build utils.
>
> Makefile | 3 ++-
> include/cmake.mk | 2 +-
> include/prereq.mk | 4 ++--
> 3 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 24f5955c9066..f4519e00d28d 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -18,7 +18,8 @@ $(if $(findstring $(space),$(TOPDIR)),$(error ERROR: The
> path to the OpenWrt dir
>
> world:
>
> -DISTRO_PKG_CONFIG:=$(shell which -a pkg-config | grep -E '\/usr' | head -n
> 1)
> +WHICH:=command -pv
> +DISTRO_PKG_CONFIG:=$(shell $(WHICH) pkg-config | grep -E '\/usr' | head
> +-n 1)
Since we have to replace 'which' everywhere anyway, I'd personally prefer to
have/see the actual command in place.
$(WHICH) implies that 'which' is still used, and I don't see a reason to not
just use command -pv/-v directly so everybody knows what's happening.
Best
Adrian
> export PATH:=$(TOPDIR)/staging_dir/host/bin:$(PATH)
>
> ifneq ($(OPENWRT_BUILD),1)
> diff --git a/include/cmake.mk b/include/cmake.mk index
> 0a20530a16fe..ff00b5e779b5 100644
> --- a/include/cmake.mk
> +++ b/include/cmake.mk
> @@ -15,7 +15,7 @@ MAKE_PATH = $(firstword $(CMAKE_BINARY_SUBDIR)
> .) ifeq ($(CONFIG_EXTERNAL_TOOLCHAIN),)
>cmake_tool=$(TOOLCHAIN_DIR)/bin/$(1)
> else
> - cmake_tool=$(shell which $(1))
> + cmake_tool=$(shell $(WHICH) $(1))
> endif
>
> ifeq ($(CONFIG_CCACHE),)
> diff --git a/include/prereq.mk b/include/prereq.mk index
> 83ac21242c65..a6ee2bb637f5 100644
> --- a/include/prereq.mk
> +++ b/include/prereq.mk
> @@ -52,7 +52,7 @@ endef
>
> define RequireCommand
>define Require/$(1)
> -which $(1)
> +$(WHICH) $(1)
>endef
>
>$$(eval $$(call Require,$(1),$(2)))
> @@ -106,7 +106,7 @@ define SetupHostCommand
> $(call QuoteHostCommand,$(11)) $(call
> QuoteHostCommand,$(12)); do \
> if [ -n "cmd" ]; then \
> bin="(PATH="$(subst $(space),:,$(filter-out
> $(STAGING_DIR_HOST)/%,$(subst :,$(space),$(PATH" \
> - which "{cmd%% *}")"; \
> + $(WHICH) "{cmd%% *}")"; \
> if [ -x "bin" ] && eval "cmd"
> >/dev/null 2>/dev/null; then \
> mkdir -p "$(STAGING_DIR_HOST)/bin"; \
> ln -sf "bin"
> "$(STAGING_DIR_HOST)/bin/$(strip $(1))"; \
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] treewide: use more descriptive names for concatenated partitions
A few devices in ath79 and ramips use mtd-concat to concatenate
individual partitions into a bigger "firmware" or "ubi" partition.
However, the original partitions are still present and visible,
and one can write to them directly although this might break the
actual virtual, concatenated partition.
As we cannot do much about the former, let's at least choose more
descriptive names than just "firmwareX" in order to indicate the
concatenation to the user. He might be less tempted into overwriting
a "fwconcat1" than a "firmware1", which might be perceived as an
alternate firmware for dual boot etc.
This applies the new naming consistently for all relevant devices,
i.e. fwconcatX for virtual "firmware" members and ubiconcatX for
"ubi" members.
While at it, use DT labels and label property consistently, and
also use consistent zero-based indexing.
Signed-off-by: Adrian Schmutzler
---
.../linux/ath79/dts/ar7240_engenius_enh202-v1.dts | 10 +-
.../linux/ath79/dts/ar9341_engenius_eap300-v2.dts | 10 +-
.../ath79/dts/ar9341_engenius_ens202ext-v1.dts | 10 +-
target/linux/ath79/dts/ar9341_pisen_wmb001n.dts| 10 +-
.../ath79/dts/ar9344_enterasys_ws-ap3705i.dts | 10 +-
target/linux/ath79/dts/ar9344_netgear_wndr.dtsi| 10 +-
target/linux/ath79/dts/qca9550_airtight_c-75.dts | 10 +-
target/linux/ath79/dts/qca9558_belkin_f9x-v2.dtsi | 10 +-
.../ramips/dts/mt7620n_sunvalley_filehub.dtsi | 14 +++---
target/linux/ramips/dts/mt7621_hiwifi_hc5962.dts | 10 +-
10 files changed, 52 insertions(+), 52 deletions(-)
diff --git a/target/linux/ath79/dts/ar7240_engenius_enh202-v1.dts
b/target/linux/ath79/dts/ar7240_engenius_enh202-v1.dts
index aeb1e9e424..77b2f3fa1a 100644
--- a/target/linux/ath79/dts/ar7240_engenius_enh202-v1.dts
+++ b/target/linux/ath79/dts/ar7240_engenius_enh202-v1.dts
@@ -72,7 +72,7 @@
virtual_flash {
compatible = "mtd-concat";
- devices = <&firmware1 &firmware2>;
+ devices = <&fwconcat0 &fwconcat1>;
partitions {
compatible = "fixed-partitions";
@@ -128,8 +128,8 @@
read-only;
};
- firmware2: partition@b {
- label = "firmware2";
+ fwconcat1: partition@b {
+ label = "fwconcat1";
reg = <0xb 0xf>;
};
@@ -138,8 +138,8 @@
reg = <0x1a 0x1>;
};
- firmware1: partition@1b {
- label = "firmware1";
+ fwconcat0: partition@1b {
+ label = "fwconcat0";
reg = <0x1b 0x4c>;
};
diff --git a/target/linux/ath79/dts/ar9341_engenius_eap300-v2.dts
b/target/linux/ath79/dts/ar9341_engenius_eap300-v2.dts
index e299c8529d..3121ec0e01 100644
--- a/target/linux/ath79/dts/ar9341_engenius_eap300-v2.dts
+++ b/target/linux/ath79/dts/ar9341_engenius_eap300-v2.dts
@@ -52,7 +52,7 @@
virtual_flash {
compatible = "mtd-concat";
- devices = <&firmware1 &firmware2>;
+ devices = <&fwconcat0 &fwconcat1>;
partitions {
compatible = "fixed-partitions";
@@ -112,8 +112,8 @@
read-only;
};
- firmware2: partition@b {
- label = "firmware2";
+ fwconcat1: partition@b {
+ label = "fwconcat1";
reg = <0x0b 0x17>;
};
@@ -123,8 +123,8 @@
read-only;
};
- firmware1: partition@23 {
- label = "firmware1";
+ fwconcat0: partition@23 {
+ label = "fwconcat0";
reg = <0x23 0xbc>;
};
diff --git a/target/linux/ath79/dts/ar9341_engenius_ens202ext-v1.dts
b/target/linux/ath79/dts/ar9341_engenius_ens202ext-v1.dts
index 94b079f94d..8b28d581b1 100644
--- a/target/linux/ath79/dts/ar9341_engenius_ens202ext-v1.dts
+++ b/target/linux/ath79/dts/ar9341_engenius_ens202ext-v1.dts
@@ -62,7 +62,7 @@
virtual_flash {
RE: [PATCH 3/3] ramips: add RT6855A SoC Linux support patches
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Rafaël Carré > Sent: Donnerstag, 24. Dezember 2020 09:33 > To: Chuanhong Guo > Cc: OpenWrt Development List > Subject: Re: [PATCH 3/3] ramips: add RT6855A SoC Linux support patches > > Hi, > > On 12/24/20 03:12, Chuanhong Guo wrote: > > Hi! > > > > On Thu, Dec 24, 2020 at 12:52 AM Rafaël Carré > wrote: > >> > >> TODO: the spi-mt7621 patches will break support for other targets > > > > > And please try your best to finish the TODOs before sending them for > > review. Or send it as RFC instead. > > No problem. Should I replace [PATCH] by [RFC] in each e-mail? > Or only the first e-mail? [RFC PATCH] instead of [PATCH], on all patches. For later revisions, you then increase versions, like [RFC PATCH v2] etc. automatically with git format-patch -v2 etc. Best Adrian > > > I'm marking this patch rejected for the exact reasons you've realized > > yourself in those TODOs: > > 1. adding the old vendor pci drivers > > Late yesterday I could modify pci-rt3883.c until wlan works. > Now I "just" need to clean up my changes. > > > 2. breaking the spi driver for mt7621/mt7628. > > Thanks for the explanations and the datasheet in your other e-mail. > I will have a look at this too. > > Give me a couple weeks because there is still a lot of TODOs! > > > Regards, > > Chuanhong Guo > > > > > ___ > 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] scripts/feed: no warn on toolchain/linux overwrite
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Paul Spooren
> Sent: Sonntag, 27. Dezember 2020 22:31
> To: openwrt-devel@lists.openwrt.org
> Cc: Paul Spooren ; ~aparcar/openwrt-de...@lists.sr.ht
> Subject: [PATCH] scripts/feed: no warn on toolchain/linux overwrite
>
> The recent 7f285d "scripts/feeds: warn when skipping core package
> override" floats SDK output with warning of overwriting "linux" and
> "toolchain" core packages. This should be ignored as these are not regular
> packages added via feeds.
Makes me wonder whether the original patch actually was the right answer to the
problem ...
Best
Adrian
>
> While at it slightly improve the warning string.
>
> Signed-off-by: Paul Spooren
> ---
> scripts/feeds | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/feeds b/scripts/feeds index 122f8568cb..eee0a50717
> 100755
> --- a/scripts/feeds
> +++ b/scripts/feeds
> @@ -537,7 +537,9 @@ sub install_src {
> my $override = 0;
> if (is_core_src($name)) {
> if (!$force) {
> - warn "Not overriding core package $name; use -f to
> force\n";
> + if ($name ne "toolchain" && $name ne "linux") {
> + warn "WARNING: Not overriding core package
> '$name'; use -f to force\n";
> + }
> return 0;
> }
> $override = 1;
> --
> 2.29.2
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [RFC PATCH v2 1/3] ramips: add support for the RT6855A SoC
Hi,
some additional (general) remarks below.
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Rafaël Carré
> Sent: Montag, 28. Dezember 2020 01:25
> To: openwrt-devel@lists.openwrt.org
> Cc: Rafaël Carré
> Subject: [RFC PATCH v2 1/3] ramips: add support for the RT6855A SoC
>
> Add Linksys WAP300N target
>
> Signed-off-by: Rafaël Carré
> ---
> Changes since v1:
> - Use OpenWrt .dts (CONFIG_MIPS_RAW_APPENDED_DTB)
> - clean up rt6855a.mk
> - add case/esac in /etc/board.d/*
> - tidy up config-5.4
>
> target/linux/ramips/Makefile | 2 +-
> target/linux/ramips/dts/rt6855a.dtsi | 190 ++
> .../ramips/dts/rt6855a_linksys_wap300n.dts| 22 ++
> target/linux/ramips/image/Makefile| 1 +
> target/linux/ramips/image/rt6855a.mk | 12 +
> .../rt6855a/base-files/etc/board.d/01_leds| 17 +
> .../rt6855a/base-files/etc/board.d/02_network | 17 +
> .../base-files/etc/board.d/03_gpio_switches | 16 +
> target/linux/ramips/rt6855a/config-5.4| 344 ++
> .../ramips/rt6855a/profiles/00-default.mk | 17 +
> target/linux/ramips/rt6855a/target.mk | 15 +
> 11 files changed, 652 insertions(+), 1 deletion(-) create mode 100644
> target/linux/ramips/dts/rt6855a.dtsi
> create mode 100644 target/linux/ramips/dts/rt6855a_linksys_wap300n.dts
> create mode 100644 target/linux/ramips/image/rt6855a.mk
> create mode 100755 target/linux/ramips/rt6855a/base-
> files/etc/board.d/01_leds
> create mode 100755 target/linux/ramips/rt6855a/base-
> files/etc/board.d/02_network
> create mode 100755 target/linux/ramips/rt6855a/base-
> files/etc/board.d/03_gpio_switches
> create mode 100644 target/linux/ramips/rt6855a/config-5.4
> create mode 100644 target/linux/ramips/rt6855a/profiles/00-default.mk
> create mode 100644 target/linux/ramips/rt6855a/target.mk
>
> diff --git a/target/linux/ramips/Makefile b/target/linux/ramips/Makefile
> index c3d118b2ab..f03118c1aa 100644
> --- a/target/linux/ramips/Makefile
> +++ b/target/linux/ramips/Makefile
> @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk ARCH:=mipsel
> BOARD:=ramips BOARDNAME:=MediaTek Ralink MIPS
> -SUBTARGETS:=mt7620 mt7621 mt76x8 rt288x rt305x rt3883
> +SUBTARGETS:=mt7620 mt7621 mt76x8 rt288x rt305x rt3883 rt6855a
> FEATURES:=squashfs gpio
>
> KERNEL_PATCHVER:=5.4
> diff --git a/target/linux/ramips/dts/rt6855a.dtsi
> b/target/linux/ramips/dts/rt6855a.dtsi
> new file mode 100644
> index 00..76cd3da568
> --- /dev/null
> +++ b/target/linux/ramips/dts/rt6855a.dtsi
> @@ -0,0 +1,190 @@
> +// SPDX-License-Identifier: GPL-2.0
Please add /dts-v1/; here, with empty line before and after.
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "ralink,rt6855a-soc";
> +
> + cpus {
> + cpu@0 {
> + compatible = "mips,mips34Kc";
> + };
> + };
> +
> + cpuintc: cpuintc {
> + #address-cells = <0>;
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + compatible = "mti,cpu-interrupt-controller";
> + };
> +
> + palmbus@1fb0 {
> + compatible = "palmbus";
> + reg = <0x1fb0 0xe>;
> + ranges = <0x0 0x1fb0 0x10>;
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + sysc@800 {
> + compatible = "ralink,rt6855a-sysc";
> + reg = <0x800 0x100>;
> + };
> +
> + intc: intc@4 {
> + compatible = "ralink,rt6855a-intc";
> + reg = <0x4 0x100>;
> +
> + interrupt-controller;
> + #interrupt-cells = <1>;
> +
> + interrupt-parent = <&cpuintc>;
> + };
> +
> + memc@300 {
> + compatible = "ralink,rt6855a-memc", "ralink,rt3050-
> memc";
> + reg = <0x300 0x100>;
> + };
> +
> + watchdog@f0100 {
> + compatible = "ralink,rt6855a-wdt";
> + reg = <0xf0100 0x10>;
> + };
> +
> + uart: uart@f {
> + compatible = "ns8250";
> + reg = <0xf 0x30>;
> + interrupts = <0>;
> +
> + clock-frequency = <921600>;
> +
> + reg-io-width = <4>;
> + reg-shift = <2>;
> + no-loopback-test;
> +
> + status = "okay";
> +
> + interrupt-parent = <&intc>;
> + };
> +
> + gdma: gdma@3 {
> + compatible = "ralink,gdma-rt2880";
> + reg = <0x3 0x100>;
> + };
> +
> +ethernet: ethernet@5{
> +compatible = "ralink,rt6855a-eth";
> +
RE: [RFC PATCH v2 3/3] ramips: add RT6855A SoC Linux support patches
> -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Rafaël Carré > Sent: Montag, 28. Dezember 2020 01:25 > To: openwrt-devel@lists.openwrt.org > Cc: Rafaël Carré > Subject: [RFC PATCH v2 3/3] ramips: add RT6855A SoC Linux support patches I don't get why you add the DTS files here _another_ time ... Best Adrian > > TODO: the spi-mt7621 patches will break support for other targets > > Signed-off-by: Rafaël Carré > --- > Changes since v1: > - Change sysc address, this seems to make resetting devices possible > - Remove watchdog driver as it is buggy and maybe not needed? > - Use pci-rt3883.c rather than vendor's pci.c > > The pci-rt3883.c modifications will also break support for other targets. > I'm looking for feedback whether I should modify this driver like I did the > OpenWrt mediatek_eth_soc driver, or if I should write a new one. > > The .dts structure for pci-rt3883 seems quite complex, it seems the > pci@1014 node is a 'controller', pci@0 would be the host bridge, and > child nodes are the different slots? > > I'm also confused by the pcie_ready checks in rt3883_pci_config_read and > rt3883_pci_config_write, I am not sure what they mean exactly. > > > Chuanhong Guo also advised me to write a new SPI driver, and a GPIO driver > is still missing. > > > It might also be possible to reset devices with ralink_reset_device(), > although it still needs some testing. > > ...-ralink-adds-support-for-RT6855A-SoC.patch | 686 ++ > .../304-HACK-spi-mt7621-rt6855a-fix.patch | 35 + > ...HACK-spi-mt7621.c-hardcode-frequency.patch | 69 ++ > .../307-pci-rt3883-run-on-RT6855A.patch | 271 +++ > 4 files changed, 1061 insertions(+) > create mode 100644 target/linux/ramips/patches-5.4/303-MIPS-ralink-adds- > support-for-RT6855A-SoC.patch > create mode 100644 target/linux/ramips/patches-5.4/304-HACK-spi-mt7621- > rt6855a-fix.patch > create mode 100644 target/linux/ramips/patches-5.4/305-HACK-spi- > mt7621.c-hardcode-frequency.patch > create mode 100644 target/linux/ramips/patches-5.4/307-pci-rt3883-run-on- > RT6855A.patch > > diff --git a/target/linux/ramips/patches-5.4/303-MIPS-ralink-adds-support- > for-RT6855A-SoC.patch b/target/linux/ramips/patches-5.4/303-MIPS-ralink- > adds-support-for-RT6855A-SoC.patch > new file mode 100644 > index 00..50cb757da5 > --- /dev/null > +++ b/target/linux/ramips/patches-5.4/303-MIPS-ralink-adds-support-for- > RT6855A-SoC.patch > @@ -0,0 +1,686 @@ > +From 5ba1ea2583e59d5d426412ea4f2982a40229ab13 Mon Sep 17 00:00:00 > 2001 > +From: =?UTF-8?q?Rafa=C3=ABl=20Carr=C3=A9?= > +Date: Wed, 23 Dec 2020 14:16:37 +0100 > +Subject: [PATCH 1/4] MIPS: ralink: adds support for RT6855A SoC > +MIME-Version: 1.0 > +Content-Type: text/plain; charset=UTF-8 > +Content-Transfer-Encoding: 8bit > + > +TODO: > +- clean up dts file > +some things are OpenWrt-only (mtd mac / eeprom) > +some things might be removed (gdma?) > +spi / pci should be moved to other commits > +ethernet should go in OpenWrt dts > + > +All code is my own or based on existing in-tree files. > + > +Signed-off-by: Rafaël Carré > +--- > + arch/mips/boot/dts/ralink/Makefile| 1 + > + arch/mips/boot/dts/ralink/rt6855.dtsi | 207 ++ > + arch/mips/boot/dts/ralink/wap300n.dts | 22 ++ > + .../include/asm/mach-ralink/ralink_regs.h | 1 + > + arch/mips/ralink/Kconfig | 13 +- > + arch/mips/ralink/Makefile | 6 +- > + arch/mips/ralink/Platform | 5 + > + arch/mips/ralink/early_printk.c | 5 +- > + arch/mips/ralink/irq-rt6855a.c| 172 +++ > + arch/mips/ralink/reset.c | 22 ++ > + arch/mips/ralink/rt6855a.c| 57 + > + 11 files changed, 508 insertions(+), 3 deletions(-) > + create mode 100644 arch/mips/boot/dts/ralink/rt6855.dtsi > + create mode 100644 arch/mips/boot/dts/ralink/wap300n.dts > + create mode 100644 arch/mips/ralink/irq-rt6855a.c > + create mode 100644 arch/mips/ralink/rt6855a.c > + > +diff --git a/arch/mips/boot/dts/ralink/Makefile > b/arch/mips/boot/dts/ralink/Makefile > +index 6c26dfa0a903..08c612190936 100644 > +--- a/arch/mips/boot/dts/ralink/Makefile > b/arch/mips/boot/dts/ralink/Makefile > +@@ -3,6 +3,7 @@ dtb-$(CONFIG_DTB_RT2880_EVAL)+= > rt2880_eval.dtb > + dtb-$(CONFIG_DTB_RT305X_EVAL) += rt3052_eval.dtb > + dtb-$(CONFIG_DTB_RT3883_EVAL) += rt3883_eval.dtb > + dtb-$(CONFIG_DTB_MT7620A_EVAL) += mt7620a_eval.dtb > ++dtb-$(CONFIG_DTB_WAP300N) += wap300n.dtb > + dtb-$(CONFIG_DTB_OMEGA2P) += omega2p.dtb > + dtb-$(CONFIG_DTB_VOCORE2) += vocore2.dtb > + > +diff --git a/arch/mips/boot/dts/ralink/rt6855.dtsi > b/arch/mips/boot/dts/ralink/rt6855.dtsi > +new file mode 100644 > +index ..d083d1d1b984 > +--- /dev/null > b/arch/mips/boot/dts/ralink/rt685
RE: Please revert 98b86296e6 as it breaks several ipq806x devices
> -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Hannu Nyman > Sent: Montag, 28. Dezember 2020 10:12 > To: OpenWrt Development List > Cc: Petr Štetiar ; Christian Lamparter > > Subject: Please revert 98b86296e6 as it breaks several ipq806x devices https://github.com/openwrt/openwrt/commit/57e4cc8261ca6f0b32e4da6922a8f52ef82c4dc6 This is meant as an emergency measure (thus no "Fixes"), and should be properly addressed at some point. Best Adrian > > Please revert commit 98b86296e6 "ipq806x: add support for ASRock G10" as > it breaks several popular ipq806x devices. > > 98b86296e6 adds a new kernel config symbol CONFIG_CMDLINE_OVERRIDE > for ipq806x and enables it for all ipq806x devices. > > Based on forum discussion and my own experience, that new symbol > apparently changes the kernel command line and breaks several ipq806x > devices. Either the devices do not boot or there are other symptoms. > > > Symptoms in my own R7800: > > * serial console is disabled. It works during u-boot but is silent after > kernel > takes over (as console gets assigned to wrong tty) > > * sysupgrade FROM builds with commit 98b86296e6 included does not work. > Debugging that is not feasible, as serial console is broken... > > > > Bug report in: > > https://bugs.openwrt.org/index.php?do=details&task_id=3540 > > and in > > https://github.com/openwrt/openwrt/commit/98b86296e67dd2b467212fe1 > a577656e6d3725da#commitcomment-45455875 > > > Things get fixed by reverting the kernel symbol part from 98b86296e6: > > > |--- a/target/linux/ipq806x/config-5.4 +++ > |b/target/linux/ipq806x/config-5.4 > @@ -78,7 +78,7 @@ CONFIG_CC_HAS_KASAN_GENERIC=y > CONFIG_CLKDEV_LOOKUP=y CONFIG_CLKSRC_QCOM=y > CONFIG_CLONE_BACKWARDS=y -CONFIG_CMDLINE_OVERRIDE=y +# > CONFIG_CMDLINE_OVERRIDE is not set CONFIG_COMMON_CLK=y > CONFIG_COMMON_CLK_QCOM=y CONFIG_COMPAT_32BIT_TIME=y| > > > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: Please revert 98b86296e6 as it breaks several ipq806x devices
> -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Christian Lamparter > Sent: Montag, 28. Dezember 2020 16:00 > To: Adrian Schmutzler ; 'Hannu Nyman' > ; 'OpenWrt Development List' de...@lists.openwrt.org> > Cc: 'Petr Štetiar' > Subject: Re: Please revert 98b86296e6 as it breaks several ipq806x devices > > On 28/12/2020 15:27, Adrian Schmutzler wrote: > >> -Original Message- > >> From: openwrt-devel [mailto:openwrt-devel- > boun...@lists.openwrt.org] > >> On Behalf Of Hannu Nyman > >> Sent: Montag, 28. Dezember 2020 10:12 > >> To: OpenWrt Development List > >> Cc: Petr Štetiar ; Christian Lamparter > >> > >> Subject: Please revert 98b86296e6 as it breaks several ipq806x > >> devices > > > > > https://github.com/openwrt/openwrt/commit/57e4cc8261ca6f0b32e4da692 > 2a8 > > f52ef82c4dc6 > > > > This is meant as an emergency measure (thus no "Fixes"), and should be > properly addressed at some point. > > > > hmm, the R7800 must have some crazy bootargs-overrides when these > impact sysupgrade as well. Let's hope there isn't an issue with the > platform.sh + asrock.sh changes. I had a quick look there as well and didn't see anything obvious. In the bug report, people stated that solely the CONFIG_CMDLINE_OVERRIDE was enough to fix the problem (as Hannu did via mail). So, I decided to just touch that for the quick fix. Best Adrian > > @hannu: can you please post your R7800's /proc/device-tree/chosen/ files > (name + content) for reference? > > Cheers > Christian > > > > >> > >> Please revert commit 98b86296e6 "ipq806x: add support for ASRock G10" > >> as it breaks several popular ipq806x devices. > >> > >> 98b86296e6 adds a new kernel config symbol > CONFIG_CMDLINE_OVERRIDE > >> for ipq806x and enables it for all ipq806x devices. > >> > >> Based on forum discussion and my own experience, that new symbol > >> apparently changes the kernel command line and breaks several ipq806x > >> devices. Either the devices do not boot or there are other symptoms. > >> > >> > >> Symptoms in my own R7800: > >> > >> * serial console is disabled. It works during u-boot but is silent > >> after kernel takes over (as console gets assigned to wrong tty) > >> > >> * sysupgrade FROM builds with commit 98b86296e6 included does not > work. > >> Debugging that is not feasible, as serial console is broken... > >> > >> > >> > >> Bug report in: > >> > >> https://bugs.openwrt.org/index.php?do=details&task_id=3540 > >> > >> and in > >> > >> > https://github.com/openwrt/openwrt/commit/98b86296e67dd2b467212fe1 > >> a577656e6d3725da#commitcomment-45455875 > >> > >> > >> Things get fixed by reverting the kernel symbol part from 98b86296e6: > >> > >> > >> |--- a/target/linux/ipq806x/config-5.4 +++ > >> |b/target/linux/ipq806x/config-5.4 > >> @@ -78,7 +78,7 @@ CONFIG_CC_HAS_KASAN_GENERIC=y > >> CONFIG_CLKDEV_LOOKUP=y CONFIG_CLKSRC_QCOM=y > CONFIG_CLONE_BACKWARDS=y > >> -CONFIG_CMDLINE_OVERRIDE=y +# CONFIG_CMDLINE_OVERRIDE is not > set > >> CONFIG_COMMON_CLK=y CONFIG_COMMON_CLK_QCOM=y > >> CONFIG_COMPAT_32BIT_TIME=y| > >> > >> > >> > >> > >> ___ > >> 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 openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: Please revert 98b86296e6 as it breaks several ipq806x devices
Hi, Pawel hasn't been in the recipients list, so I added him: @Pawel: If you haven't followed the thread via openwrt-devel anyway, you should definitely have a look, particularly at the latest findings by Hannu (below; thanks!). http://lists.openwrt.org/pipermail/openwrt-devel/2020-December/032960.html Best Adrian > -Original Message- > From: Hannu Nyman [mailto:hannu.ny...@iki.fi] > Sent: Donnerstag, 31. Dezember 2020 13:49 > To: Christian Lamparter ; Adrian Schmutzler > ; 'OpenWrt Development List' de...@lists.openwrt.org> > Cc: 'Petr Štetiar' > Subject: Re: Please revert 98b86296e6 as it breaks several ipq806x devices > > Hannu Nyman kirjoitti 31.12.2020 klo 14.32: > > ... > > > > I did some further debugging, and noticed something. > > > > In short: Possibly the definition of CONFIG_CMDLINE_OVERRIDE has been > > placed into a slightly wrong place in arch/arm/Kconfig. > > > > > > I compared the kernel build log with the working code (without > > CONFIG_CMDLINE_OVERRIDE=y) to log with the faulty code, and there is > > only a small difference: > > > > In the faulty version, there is a one-line warning: > > warning: override: CMDLINE_OVERRIDE changes choice state > > > > context: > > > > HOSTCC scripts/kconfig/symbol.o > > HOSTLD scripts/kconfig/conf > > scripts/kconfig/conf --syncconfig Kconfig > > net/sched/Kconfig:45: warning: menuconfig statement without prompt > > .config:987:warning: override: CMDLINE_OVERRIDE changes choice state > > HOSTCC scripts/dtc/dtc.o > > > > > > So, the new option changes something else. > > > > I looked at > > build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux- > ipq806x_gen > > eric/linux-5.4.85/arch/arm/Kconfig > > and noticed that the new definition of CONFIG_CMDLINE_OVERRIDE has > > been placed into end of a multi-option choice block. Enabling this > > option may now change the selected value of the choice of > > ARM_ATAG_DTB_COMPAT_CMDLINE... options. > > ... > > > > Possibly the new definition should be after the "endchoice" line, so > > that ARM_ATAG_DTB_COMPAT_CMDLINE things do not change. > > > > Or possibly it should be inside the next choice block about CMDLINE > > > One more observation: The faulty Asrock commit's commit messages says: > > - 900-arm-add-cmdline-override.patch was copied from 102-powerpc-add- > cmdline-override.patch from powerpc target. > > But looking at > > https://github.com/openwrt/openwrt/blob/master/target/linux/mpc85xx/p > atches-5.4/102-powerpc-add-cmdline-override.patch > > shows that there the code there is apparently placed outside any choice > block, just before "config EXTRA_TARGETS" > > > So, looks like the author has accidentally placed the block into inside a > choice block and it has worked for him. openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH] ramips: add support for Ubiquiti UniFi 6 Lite
Hi David,
a few minor comments below.
> +&spi0 {
> + status = "okay";
> +
> + flash@0 {
> + compatible = "mx25l25635f", "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <5000>;
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition@0 {
> + label = "u-boot";
> + reg = <0x0 0x6>;
> + read-only;
> + };
> +
> + partition@6 {
> + label = "u-boot-env";
> + reg = <0x6 0x1>;
> + read-only;
> + };
> +
> + factory: partition@7 {
> + label = "factory";
> + reg = <0x7 0x4>;
> + read-only;
> + };
> +
> + eeprom: partition@8 {
Wrong offset in node name, also below.
> + label = "eeprom";
> + reg = <0xb 0x1>;
> + read-only;
> + };
> +
> + partition@9 {
> + label = "bs";
> + reg = <0xc 0x1>;
> + };
> +
> + partition@a {
> + label = "cfg";
> + reg = <0xd 0x10>;
> + read-only;
> + };
> +
> + partition@1a {
> + compatible = "denx,fit";
> + label = "firmware";
> + reg = <0x1d 0xf1>;
> + };
> +
> + partition@10d {
> + label = "kernel1";
> + reg = <0x10e 0xf1>;
Partitioning ends at 0x1ff and not at 0x200?
> + };
> + };
> + };
> +};
> +
> +&wlan_2g {
> + mtd-mac-address = <&eeprom 0x0>;
> +};
> +
> +&wlan_5g {
> + mediatek,mtd-eeprom = <&factory 0x2>;
> + mtd-mac-address = <&eeprom 0x6>;
> +};
[...]
> --- a/target/linux/ramips/image/mt7621.mk
> +++ b/target/linux/ramips/image/mt7621.mk
> @@ -1139,6 +1139,16 @@ define Device/ubnt_unifi-nanohd endef
> TARGET_DEVICES += ubnt_unifi-nanohd
>
> +define Device/ubnt_unifi-6-lite
"unifi-6" should be before "unifi-nanohd"?
> + $(Device/dsa-migration)
> + DEVICE_VENDOR := Ubiquiti
> + DEVICE_MODEL := UniFi 6 Lite
> + DEVICE_PACKAGES += kmod-mt7603 kmod-mt7915e
> + KERNEL := kernel-bin | lzma | fit lzma $$(KDIR)/image-$$(firstword
> +$$(DEVICE_DTS)).dtb
> + IMAGE_SIZE := 15424k
> +endef
> +TARGET_DEVICES += ubnt_unifi-6-lite
> +
> define Device/unielec_u7621-06-16m
>$(Device/dsa-migration)
>$(Device/uimage-lzma-loader)
> diff --git a/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
> b/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
> index bca4cc23dc..cf8b9671f0 100755
> --- a/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
> +++ b/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
> @@ -29,7 +29,8 @@ ramips_setup_interfaces()
> tplink,re350-v1|\
> tplink,re500-v1|\
> tplink,re650-v1|\
> - ubnt,unifi-nanohd)
> + ubnt,unifi-nanohd|\
> + ubnt,unifi-6-lite)
Alphabetic sorting, see above.
Best
Adrian
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH] kernel/pending-5.4: enable DCDE for x86(-64)
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Rui Salvaterra
> Sent: Sonntag, 3. Januar 2021 01:33
> To: openwrt-devel@lists.openwrt.org
> Cc: ha...@hauke-m.de; dan...@makrotopia.org; Rui Salvaterra
>
> Subject: [PATCH] kernel/pending-5.4: enable DCDE for x86(-64)
>
> Port and adapt Nick Piggin's original patch [1]. This enables dead code and
> data elimination at linking time (gc-sections) on x86(-64).
Shouldn't it be in target/linux/x86 then?
Best
Adrian
>
> openwrt-x86-64-generic-kernel.bin size, with my config:
>
> Before: 3138048 bytes
> After:2937344 bytes
>
> In other words, we save about 100 kB.
>
> [1] https://lore.kernel.org/lkml/20170709031333.29443-1-
> npig...@gmail.com/
>
> Signed-off-by: Rui Salvaterra
> ---
> ...nable-dead-code-and-data-elimination.patch | 127
> ++
> 1 file changed, 127 insertions(+)
> create mode 100644 target/linux/generic/pending-5.4/350-x86-enable-
> dead-code-and-data-elimination.patch
>
> diff --git a/target/linux/generic/pending-5.4/350-x86-enable-dead-code-
> and-data-elimination.patch b/target/linux/generic/pending-5.4/350-x86-
> enable-dead-code-and-data-elimination.patch
> new file mode 100644
> index 00..392ddd71ce
> --- /dev/null
> +++ b/target/linux/generic/pending-5.4/350-x86-enable-dead-code-and-
> data
> +++ -elimination.patch
> @@ -0,0 +1,127 @@
> +From f08a0e4e59f92b4a88501653761cbca08935b9b6 Mon Sep 17 00:00:00
> 2001
> +From: Rui Salvaterra
> +Date: Wed, 4 Nov 2020 19:45:04 +
> +Subject: [PATCH] x86: enable dead code and data elimination
> +
> +Adapt Nick Piggin's original patch [1]. This saves nearly 300 kiB on
> +the final vmlinuz (zstd-compressed).
> +
> +[1]
> +https://lore.kernel.org/lkml/20170709031333.29443-1-npig...@gmail.com/
> +
> +Signed-off-by: Rui Salvaterra
> +---
> + arch/x86/Kconfig | 1 +
> + arch/x86/kernel/vmlinux.lds.S | 24
> + 2 files changed, 13 insertions(+), 12 deletions(-)
> +
> +--- a/arch/x86/Kconfig
> b/arch/x86/Kconfig
> +@@ -184,6 +184,7 @@ config X86
> + select HAVE_FUNCTION_ERROR_INJECTION
> + select HAVE_KRETPROBES
> + select HAVE_KVM
> ++select HAVE_LD_DEAD_CODE_DATA_ELIMINATION
> + select HAVE_LIVEPATCH if X86_64
> + select HAVE_MEMBLOCK_NODE_MAP
> + select HAVE_MIXED_BREAKPOINTS_REGS
> +--- a/arch/x86/kernel/vmlinux.lds.S
> b/arch/x86/kernel/vmlinux.lds.S
> +@@ -242,14 +242,14 @@ SECTIONS
> + * See static_cpu_has() for an example.
> + */
> + .altinstr_aux : AT(ADDR(.altinstr_aux) - LOAD_OFFSET) {
> +-*(.altinstr_aux)
> ++KEEP(*(.altinstr_aux))
> + }
> +
> + INIT_DATA_SECTION(16)
> +
> + .x86_cpu_dev.init : AT(ADDR(.x86_cpu_dev.init) - LOAD_OFFSET) {
> + __x86_cpu_dev_start = .;
> +-*(.x86_cpu_dev.init)
> ++KEEP(*(.x86_cpu_dev.init))
> + __x86_cpu_dev_end = .;
> + }
> +
> +@@ -257,7 +257,7 @@ SECTIONS
> + .x86_intel_mid_dev.init : AT(ADDR(.x86_intel_mid_dev.init) - \
> + LOAD_OFFSET)
> {
> + __x86_intel_mid_dev_start = .;
> +-*(.x86_intel_mid_dev.init)
> ++KEEP(*(.x86_intel_mid_dev.init))
> + __x86_intel_mid_dev_end = .;
> + }
> + #endif
> +@@ -271,7 +271,7 @@ SECTIONS
> + . = ALIGN(8);
> + .parainstructions : AT(ADDR(.parainstructions) - LOAD_OFFSET) {
> + __parainstructions = .;
> +-*(.parainstructions)
> ++KEEP(*(.parainstructions))
> + __parainstructions_end = .;
> + }
> +
> +@@ -283,7 +283,7 @@ SECTIONS
> + . = ALIGN(8);
> + .altinstructions : AT(ADDR(.altinstructions) - LOAD_OFFSET) {
> + __alt_instructions = .;
> +-*(.altinstructions)
> ++KEEP(*(.altinstructions))
> + __alt_instructions_end = .;
> + }
> +
> +@@ -293,7 +293,7 @@ SECTIONS
> + * get the address and the length of them to patch the kernel safely.
> + */
> + .altinstr_replacement : AT(ADDR(.altinstr_replacement) -
> LOAD_OFFSET) {
> +-*(.altinstr_replacement)
> ++KEEP(*(.altinstr_replacement))
> + }
> +
> + /*
> +@@ -304,14 +304,14 @@ SECTIONS
> + */
> + .iommu_table : AT(ADDR(.iommu_table) - LOAD_OFFSET) {
> + __iommu_table = .;
> +-*(.iommu_table)
> ++KEEP(*(.iommu_table))
> + __iommu_table_end = .;
> + }
> +
> + . = ALIGN(8);
> + .apicdrivers : AT(ADDR(.apicdrivers) - LOAD_OFFSET) {
> + __apicdrivers = .;
> +-*(.apicdrivers);
> ++KEEP(*(.apicdrivers))
> + __apicdrivers_end = .;
> + }
> +
> +@@ -346,7 +346,7 @@ SECTIONS
> + . = ALIGN(PAGE_SIZE);
> + .smp_locks : AT(ADDR(.smp_locks) - LOAD_OFFSET) {
> + __smp_lo
[PATCH] base-files: read all 3 bytes in get_magic_vfat() at once
While the speed improvement might be negligible, there is still no
reason to read individual bytes.
Signed-off-by: Adrian Schmutzler
---
package/base-files/Makefile| 2 +-
package/base-files/files/lib/upgrade/common.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/package/base-files/Makefile b/package/base-files/Makefile
index da3976424f..8d40eb0e49 100644
--- a/package/base-files/Makefile
+++ b/package/base-files/Makefile
@@ -12,7 +12,7 @@ include $(INCLUDE_DIR)/version.mk
include $(INCLUDE_DIR)/feeds.mk
PKG_NAME:=base-files
-PKG_RELEASE:=244
+PKG_RELEASE:=245
PKG_FLAGS:=nonshared
PKG_FILE_DEPENDS:=$(PLATFORM_DIR)/ $(GENERIC_PLATFORM_DIR)/base-files/
diff --git a/package/base-files/files/lib/upgrade/common.sh
b/package/base-files/files/lib/upgrade/common.sh
index e8a28f4138..c28bae48a1 100644
--- a/package/base-files/files/lib/upgrade/common.sh
+++ b/package/base-files/files/lib/upgrade/common.sh
@@ -130,7 +130,7 @@ get_magic_gpt() {
}
get_magic_vfat() {
- (get_image "$@" | dd bs=1 count=3 skip=54) 2>/dev/null
+ (get_image "$@" | dd bs=3 count=1 skip=18) 2>/dev/null
}
get_magic_fat32() {
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] base-files: read all 5 bytes in get_magic_fat32() at once
While the speed improvement might be negligible, there is still no
reason to read individual bytes.
Suggested-by: Paul Spooren
Signed-off-by: Adrian Schmutzler
---
package/base-files/Makefile| 2 +-
package/base-files/files/lib/upgrade/common.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/package/base-files/Makefile b/package/base-files/Makefile
index 8d40eb0e49..f18f221129 100644
--- a/package/base-files/Makefile
+++ b/package/base-files/Makefile
@@ -12,7 +12,7 @@ include $(INCLUDE_DIR)/version.mk
include $(INCLUDE_DIR)/feeds.mk
PKG_NAME:=base-files
-PKG_RELEASE:=245
+PKG_RELEASE:=246
PKG_FLAGS:=nonshared
PKG_FILE_DEPENDS:=$(PLATFORM_DIR)/ $(GENERIC_PLATFORM_DIR)/base-files/
diff --git a/package/base-files/files/lib/upgrade/common.sh
b/package/base-files/files/lib/upgrade/common.sh
index c28bae48a1..9b17e2ac5d 100644
--- a/package/base-files/files/lib/upgrade/common.sh
+++ b/package/base-files/files/lib/upgrade/common.sh
@@ -134,7 +134,7 @@ get_magic_vfat() {
}
get_magic_fat32() {
- (get_image "$@" | dd bs=1 count=5 skip=82) 2>/dev/null
+ (get_image "$@" | dd iflag=skip_bytes bs=5 count=1 skip=82) 2>/dev/null
}
part_magic_efi() {
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH] libpcap: update to 1.10.0
> > And where did CONFIG_PCAP_HAS_NETFILTER go? > Oversight. Will add. > > > > I don't understand why you do these unnecessary style changes while > > updating package versions. You're obviously not testing them. And you > > do add bugs. But whatever. While one can discuss about the tone, there is some truth in this comment. At least for some package bumps, it would be helpful for review, for dealing with errors, and for users trying to understand the changes if those are split into a bump and the "cleanup" separately afterwards. To be clear: I don't want to separate every tiny adjustment, but if it's more than just tiny adjustment, separating it might be helpful. Thanks for taking care of all these package bumps. Best Adrian > > > > > > Bjørn > > > > ___ > > openwrt-devel mailing list > > openwrt-devel@lists.openwrt.org > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH] base-files: read all 5 bytes in get_magic_fat32() at once
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Karl Palsson
> Sent: Montag, 4. Januar 2021 12:58
> To: Adrian Schmutzler
> Cc: openwrt-devel
> Subject: Re: [PATCH] base-files: read all 5 bytes in get_magic_fat32() at once
>
> The fact that you had to introduce iflags to work around changing IBS/OBS
> which afffected skip size would make me consider this sort of patch to be of
> incredibly marginal utilty, largely even negative value if this isn't some
> sort of
> hot path. You've made it more complicated for an _extremely_ small, un
> measured pseudo gain.
Indeed, that's why I initially only touched vfat, until Paul "requested" to
update this one as well.
I do not care terribly about this, I just noticed it when looking at the
relevant section.
I'd merge the "first" patch for vfat, as there is really no drawback there, but
I don't really care what happens to this one.
Best
Adrian
>
> I'd kinda imagine that the underlying layer already read a bigger block
> anyway...
>
> Sincerely,
> Karl Palsson
>
>
> Adrian Schmutzler wrote:
> > While the speed improvement might be negligible, there is still no
> > reason to read individual bytes.
> >
> > Suggested-by: Paul Spooren
> > Signed-off-by: Adrian Schmutzler
> -
> >
> > get_magic_fat32() {
> > - (get_image "$@" | dd bs=1 count=5 skip=82) 2>/dev/null
> > + (get_image "$@" | dd iflag=skip_bytes bs=5 count=1 skip=82)
> > +2>/dev/null
> > }
> >
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH v2 1/2] mac80211: add 802.11ad-support
Hi Daniel,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Daniel Golle
> Sent: Montag, 4. Januar 2021 20:19
> To: Paul Fertser
> Cc: Gary Cooper ; openwrt-devel@lists.openwrt.org
> Subject: Re: [PATCH v2 1/2] mac80211: add 802.11ad-support
>
> Hi Paul,
> Hi Gary,
>
> On Mon, Jan 04, 2021 at 08:27:49PM +0300, Paul Fertser wrote:
> > From: Gary Cooper
> >
> > This adds some logic to properly populate defaults in
> > /etc/config/wireless and support for WPA*-GCMP. TP-Link AD7200,
> > Mikrotik WAP60g, LHGG-60ad, etc
>
> I've split this thing up a bit more and merged it with what lynxis already
> had in
> his staging tree.
> Plus missing PKG_RELEASE bumps added where needed.
>
> Please review and test the 80211ad branch of my staging tree:
> https://git.openwrt.org/?p=openwrt/staging/dangole.git;a=shortlog;h=refs/
> heads/80211ad
A few remarks on the device-support part:
> +tplink,ad7200)
> + ucidef_set_led_usbport "usb1" "USB 1" "blue:usb_1" "usb1-port1"
> "usb2-port1"
> + ucidef_set_led_usbport "usb2" "USB 2" "blue:usb_3" "usb3-port1"
> "usb4-port1"
> + ucidef_set_led_switch "wan" "wan" "blue:wan" "switch0" "0x02"
> + ucidef_set_led_switch "lan" "lan" "blue:lan" "switch0" "0x3c"
> + ucidef_set_led_wlan "wlan2g" "wlan2g" "blue:wlan2g" "phy2tpt"
> + ucidef_set_led_wlan "wlan5g" "wlan5g" "blue:wlan5g" "phy1tpt"
> + ucidef_set_led_netdev "wlan60g" "wlan60g" "blue:wlan60g" "wlan0"
> + ;;
I'm not sure what's the state with ipq806x, but probably one can move the USB
and/or Wifi triggers to DTS.
If possible, the wlan60g trigger should be converted to phy0something, as that
will make it independent of the interface name.
Apart from that, I only found caldata extraction for two of three radios. Is
that correct or a mistake?
> + model = "TP-Link Talon AD7200";
> + compatible = "tplink,ad7200", "qcom,ipq8064";
I'd decide for one name (either with or without "Talon"), but not mix them. If
"Talon" is an alternate name ("nickname"), it should be put behind the proper
name in brackets ("TP-Link AD7200 (Talon)").
> + keys {
[...]
> + ledgeneral {
> + label = "ledswitch";
One should decide for one name in both label and node name. I'd recommend
"led-enable", as "ledswitch" had me think of a networking switch LED until I
read the linux,code property.
> + gpios = <&qcom_pinmux 53 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> + };
> + leds {
[...]
> + usb1 {
> + label = "blue:usb_1";
I'd remove the underscore here, same for usb_3 directly following here.
Apart from that, one could sort all those LEDs by $something
[...]
> + m25p80@0 {
flash@0
[...]
> + SBL1@0 {
This should be partition@0 and so on for the following partitions.
> +define Device/tplink_ad7200
> + $(call Device/TpSafeImage)
> + DEVICE_VENDOR := TP-Link
> + DEVICE_MODEL := Talon AD7200
With or without Talon, see above.
> + DEVICE_VARIANT := v1
Either we only have v1 and can drop this line, or the device should be named
tplink,ad7200-v1.
> + SOC := qcom-ipq8064
> + BLOCKSIZE := 128k
> + PAGESIZE := 2048
> + BOARD_NAME := ad7200
This can be dropped.
> + SUPPORTED_DEVICES += ad7200
This can be dropped.
Thanks for finally taking care of the 11ad support.
Best
Adrian
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH v2 1/2] mac80211: add 802.11ad-support
> -Original Message- > From: Adrian Schmutzler [mailto:m...@adrianschmutzler.de] > Sent: Montag, 4. Januar 2021 22:31 > To: 'Daniel Golle' ; 'Paul Fertser' > > Cc: 'Gary Cooper' ; 'openwrt- > de...@lists.openwrt.org' > Subject: RE: [PATCH v2 1/2] mac80211: add 802.11ad-support > > Hi Daniel, > > > -Original Message- > > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > > On Behalf Of Daniel Golle > > Sent: Montag, 4. Januar 2021 20:19 > > To: Paul Fertser > > Cc: Gary Cooper ; openwrt- > de...@lists.openwrt.org > > Subject: Re: [PATCH v2 1/2] mac80211: add 802.11ad-support > > > > Hi Paul, > > Hi Gary, > > > > On Mon, Jan 04, 2021 at 08:27:49PM +0300, Paul Fertser wrote: > > > From: Gary Cooper > > > > > > This adds some logic to properly populate defaults in > > > /etc/config/wireless and support for WPA*-GCMP. TP-Link AD7200, > > > Mikrotik WAP60g, LHGG-60ad, etc > > > > I've split this thing up a bit more and merged it with what lynxis > > already had in his staging tree. > > Plus missing PKG_RELEASE bumps added where needed. > > > > Please review and test the 80211ad branch of my staging tree: > > https://git.openwrt.org/?p=openwrt/staging/dangole.git;a=shortlog;h=re > > fs/ > > heads/80211ad > > A few remarks on the device-support part: Or lets just merge the current crappy state ... openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH 2/3] realtek: introduce common DTSI for ZyXEL GS1900-10HP and GS1900-8HP.
Hi,
> Subject: [PATCH 2/3] realtek: introduce common DTSI for ZyXEL GS1900-10HP
> and GS1900-8HP.
Please, no full stop after the commit title. Looks too long by the way.
> Memory node is moved out of the rtl838.dtsi and into the device DTS as well.
Please do that separately (= in a separate commit). BTW, it looks to me like
this will leave all the other devices without a memory node then?
>
> We also uppercase the vendor name like they carry it themselves (ZyXEL)
> and like used elsewhere in the OpenWrt tree.
>
> Signed-off-by: Stijn Segers
> ---
> .../realtek/dts/rtl8380_zyxel_gs1900-10hp.dts | 233 +-
> .../realtek/dts/rtl8380_zyxel_gs1900.dtsi | 143 +++
> target/linux/realtek/dts/rtl838x.dtsi | 5 -
> target/linux/realtek/image/Makefile | 2 +-
> 4 files changed, 153 insertions(+), 230 deletions(-) create mode 100644
> target/linux/realtek/dts/rtl8380_zyxel_gs1900.dtsi
>
> diff --git a/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts
> b/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts
> index 4458acee2e..0ecd8bd991 100644
> --- a/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts
> +++ b/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts
> @@ -1,54 +1,15 @@
> // SPDX-License-Identifier: GPL-2.0-or-later /dts-v1/;
If you touch this anyway, please remove the dts-v1 here which is already in
rtl838x.dtsi.
>
> -#include "rtl838x.dtsi"
> -
> -#include
> -#include
> +#include "rtl8380_zyxel_gs1900.dtsi"
>
> / {
> compatible = "zyxel,gs1900-10hp", "realtek,rtl838x-soc";
> - model = "Zyxel GS1900-10HP Switch";
> -
> - aliases {
> - led-boot = &led_sys;
> - led-failsafe = &led_sys;
> - led-running = &led_sys;
> - led-upgrade = &led_sys;
> - };
> + model = "ZyXEL GS1900-10HP Switch";
It would be cleaner to have the ZyXEL rename in a separate commit as well.
However, that's by far the thing I care least about in this context.
[...]
> diff --git a/target/linux/realtek/dts/rtl8380_zyxel_gs1900.dtsi
> b/target/linux/realtek/dts/rtl8380_zyxel_gs1900.dtsi
> new file mode 100644
> index 00..515081008b
> --- /dev/null
> +++ b/target/linux/realtek/dts/rtl8380_zyxel_gs1900.dtsi
> @@ -0,0 +1,143 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later /dts-v1/;
another dts-v1 that should be removed.
> +
> +#include "rtl838x.dtsi"
> +
> +#include
> +#include
> +
> +/ {
> + aliases {
> + led-boot = &led_sys;
> + led-failsafe = &led_sys;
> + led-running = &led_sys;
> + led-upgrade = &led_sys;
> + };
> +
> + chosen {
> + bootargs = "console=ttyS0,115200";
> + };
> +
> + gpio1: rtl8231-gpio {
> + status = "okay";
> +
> + poe_enable {
> + gpio-hog;
> + gpios = <13 0>;
> + output-high;
> + };
> + };
> +
> + keys {
> + compatible = "gpio-keys-polled";
> + poll-interval = <20>;
> +
> + reset {
> + label = "reset";
> + gpios = <&gpio1 3 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led_sys: sys {
> + label = "gs1900:green:sys";
Maybe not in this patch, but one should consider to remove the model prefix
here (particularly since this is used as sysled anyway, and thus probably not
linked otherwise).
> + gpios = <&gpio0 47 GPIO_ACTIVE_HIGH>;
> + };
> + };
Best
Adrian
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH 3/3] realtek: add support for ZyXEL GS1900-8HP.
Hi, essentially the same comments as in the 2/3: > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Stijn Segers > Sent: Mittwoch, 6. Januar 2021 01:45 > To: openwrt-devel@lists.openwrt.org > Subject: [PATCH 3/3] realtek: add support for ZyXEL GS1900-8HP. Remove the full stop at the end of the title. > > The ZyXEL GS1900-8HP is an 8 port gigabit switch with PoE+ support. > There are two versions on the market (v1 & v2) which share the same specs > (same flash size and flash layout, same RAM size, same PoE+ power > envelope) but each have a different case and board layout that they share > with other GS1900 siblings. As such, adding support for the non-PoE GS1900- > 8 would probably be trivial. With different board layout, it might be safer to have separate v1/v2 ... > > The v1 seems to share its PCB and case with non-PoE GS1900-8; the v2 with > its already supported bigger brother, the GS1900-10HP - its board looks the > same, except for two holes where the GS1900-10 has its SFP ports. > > Like their 10 port sibling, both devices have a dual firmware layout. > > Both GS1900-8HP boards have the same 70W PoE+ power budget. > > Specifications (v1) > --- > * SoC: Realtek RTL8380M 500 MHz MIPS 4KEc > * Flash: Macronix MX25L12835F 16 MiB > * RAM: Nanya NT5TU128M8HE-AC 128 MiB DDR2 SDRAM > * Ethernet: 8x 10/100/1000 Mbit > * PoE+: Broadcom BCM59111KMLG (IEEE 802.3at-2009 compliant, 2x) > * UART: 1 serial header with populated standard pin connector on the > left side of the PCB, towards the bottom. Pins are labeled: > + VCC (3.3V) > + TX > + RX > + GND > > Specifications (v2) > --- > > * SoC: Realtek RTL8380M 500 MHz MIPS 4KEc > * Flash: Macronix MX25L12835F 16 MiB > * RAM: Samsung K4B1G0846G 128 MiB DDR3 SDRAM > * Ethernet: 8x 10/100/1000 Mbit > * PoE+: Broadcom BCM59121B0KMLG (IEEE 802.3at-2009 compliant) > * UART: 1 angled serial header with populated standard pin connector > accessible from outside through the ventilation slits on the > side. Pins from top to bottom are clearly marked on the PCB: > + VCC (3.3V) > + TX > + RX > + GND > > Connection parameters for serial on both devices: 115200 8N1. > > Installation > > > * Configure your client with a static 192.168.1.x IP (e.g. 192.168.1.10). > * Set up a TFTP server on your client and make it serve the initramfs > image. > * Connect serial, power up the switch, interrupt U-boot by hitting the > space bar, and enable the network: > # rtk network on > * Since the GS1900-10HP is a dual-partition device, you want to keep the > OEM firmware on the backup partition for the time being. OpenWrt can > only boot off the first partition anyway (hardcoded in the DTS). To > make sure we are manipulating the first partition, issue the following > commands: > # setsys bootpartition 0 > # savesys > * Download the image onto the device and boot from it: > # tftpboot 0x84f0 192.168.1.10:openwrt-realtek-generic-zyxel_gs1900- > 8hp-initramfs-kernel.bin > # bootm > * Once OpenWrt has booted, scp the sysupgrade image to /tmp and flash it: > # sysupgrade /tmp//tmp/openwrt-realtek-generic-zyxel_gs1900-8hp- > squashfs-sysupgrade.bin > > Signed-off-by: Stijn Segers > --- > .../realtek/base-files/etc/board.d/02_network | 3 +++ > .../linux/realtek/dts/rtl8380_zyxel_gs1900-8hp.dts | 14 ++ > target/linux/realtek/image/Makefile| 9 + > 3 files changed, 26 insertions(+) > create mode 100644 target/linux/realtek/dts/rtl8380_zyxel_gs1900-8hp.dts > > 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 84fefa536d..8054adc60a 100755 > --- a/target/linux/realtek/base-files/etc/board.d/02_network > +++ b/target/linux/realtek/base-files/etc/board.d/02_network > @@ -52,6 +52,9 @@ case $board in > netgear,gs110tpp-v1) > ucidef_set_poe 130 "$lan_list" > ;; > +zyxel,gs1900-8hp) > + ucidef_set_poe 70 "$lan_list" > + ;; > zyxel,gs1900-10hp) > ucidef_set_poe 77 "$lan_list" > ;; > diff --git a/target/linux/realtek/dts/rtl8380_zyxel_gs1900-8hp.dts > b/target/linux/realtek/dts/rtl8380_zyxel_gs1900-8hp.dts > new file mode 100644 > index 00..c5813227ac > --- /dev/null > +++ b/target/linux/realtek/dts/rtl8380_zyxel_gs1900-8hp.dts > @@ -0,0 +1,14 @@ > +// SPDX-License-Identifier: GPL-2.0-or-later /dts-v1/; Drop dts-v1. Best Adrian openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH v2 2/2] ipq806x: add support for TP-Link Talon AD7200
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Paul Fertser
> Sent: Montag, 4. Januar 2021 18:28
> To: openwrt-devel@lists.openwrt.org
> Cc: Gary Cooper
> Subject: [PATCH v2 2/2] ipq806x: add support for TP-Link Talon AD7200
[...]
> + /** Firmware layout for the AD7200 */
> + {
> + .id = "AD7200",
> + .vendor = "",
> + .support_list =
> + "SupportList:\r\n"
> + "{product_name:Talon
> AD7200,product_ver:1.0.0,special_id:}\r\n",
Has factory-flashing ever been tested with this device? I found the following
strings in the TP-Link image (both 2016 and 2017 DE firmware):
{product_name:AD7200,product_ver:1.0.0,special_id:,
hw_id:284E1627019840260D1674D30C3107C0, oem_id:4C03E5D5C4A8822F49E515FC319B208B}
Apart from the product_name being wrong in our code, I have no idea whether we
need to care about the hw_id/oem_id values?
Best
Adrian
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH 3/3] realtek: add support for ZyXEL GS1900-8HP.
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Stijn Segers > Sent: Mittwoch, 6. Januar 2021 19:25 > To: Adrian Schmutzler > Cc: openwrt-devel@lists.openwrt.org > Subject: RE: [PATCH 3/3] realtek: add support for ZyXEL GS1900-8HP. > > Hi Adrian, > > > Op woensdag 6 januari 2021 om 14:22 schreef Adrian Schmutzler > : > > Hi, > > > > essentially the same comments as in the 2/3: > > > >> -Original Message- > >> From: openwrt-devel [mailto:openwrt-devel- > boun...@lists.openwrt.org] > >> On Behalf Of Stijn Segers > >> Sent: Mittwoch, 6. Januar 2021 01:45 > >> To: openwrt-devel@lists.openwrt.org > >> Subject: [PATCH 3/3] realtek: add support for ZyXEL GS1900-8HP. > > > > Remove the full stop at the end of the title. > > > >> > >> The ZyXEL GS1900-8HP is an 8 port gigabit switch with PoE+ support. > >> There are two versions on the market (v1 & v2) which share the same > >> specs (same flash size and flash layout, same RAM size, same PoE+ > >> power > >> envelope) but each have a different case and board layout that they > >> share with other GS1900 siblings. As such, adding support for the > >> non-PoE > >> GS1900- > >> 8 would probably be trivial. > > > > With different board layout, it might be safer to have separate v1/v2 > > ... > > > I have brought this up on the Realtek thread on the forum. The same > GS1900-8HP image has been tested by me on a v1 and by user Kroon40 on a > v2. Same amount of flash and RAM. Same flash layout. In the forum thread I don't doubt that. I've just watched this too often, where initial tests appear like devices are similar and then somebody discovers a difference half a year later, where it is hard to "split" them again. > the conclusion seemed to be that ZyXEL uses a unified image for both "Unified image" could be one image with different instructions or really the same image for both devices. The verdict would be different in each case. > versions (possibly even for the higher-port 10HP, 16, 24HP, ... versions (the > HP suffixes indicating PoE support). > > Link: > https://forum.openwrt.org/t/support-for-rtl838x-based-managed- > switches/57875/263 > > Let me know what I should do for the v3. I'll happily send in separate > patches, but it looks like the boards don't care. You can flash and run e.g. a > 10HP image on an 8HP. It will work. Of course, but how does the ability to flash wrong images help us for this discussion? I'm probably over-careful here, but I have the idea of images that exactly match one device, and not just some rough general generic image that can be flashed on a variety of devices and will work somehow in the end. Best Adrian > > Thanks > > Stijn > > > > >> > >> The v1 seems to share its PCB and case with non-PoE GS1900-8; the > >> v2 with > >> its already supported bigger brother, the GS1900-10HP - its board > >> looks the same, except for two holes where the GS1900-10 has its SFP > >> ports. > >> > >> Like their 10 port sibling, both devices have a dual firmware > >> layout. > >> > >> Both GS1900-8HP boards have the same 70W PoE+ power budget. > >> > >> Specifications (v1) > >> --- > >> * SoC: Realtek RTL8380M 500 MHz MIPS 4KEc > >> * Flash: Macronix MX25L12835F 16 MiB > >> * RAM: Nanya NT5TU128M8HE-AC 128 MiB DDR2 SDRAM > >> * Ethernet: 8x 10/100/1000 Mbit > >> * PoE+: Broadcom BCM59111KMLG (IEEE 802.3at-2009 compliant, 2x) > >> * UART: 1 serial header with populated standard pin connector > >> on the > >> left side of the PCB, towards the bottom. Pins are > >> labeled: > >> + VCC (3.3V) > >> + TX > >> + RX > >> + GND > >> > >> Specifications (v2) > >> --- > >> > >> * SoC: Realtek RTL8380M 500 MHz MIPS 4KEc > >> * Flash: Macronix MX25L12835F 16 MiB > >> * RAM: Samsung K4B1G0846G 128 MiB DDR3 SDRAM > >> * Ethernet: 8x 10/100/1000 Mbit > >> * PoE+: Broadcom BCM59121B0KMLG (IEEE 802.3at-2009 compliant) > >> * UART: 1 angled serial header with populated standard pin > >> connector > >> accessible from outside through the ventilation slits > >
RE: [PATCH 3/3] realtek: add support for ZyXEL GS1900-8HP.
Hi, > > Alright, I'll split them out then. Can I refer to the v1 commit for the > flashing > procedure or would you like me to include it in full in the v2 commit message > as well? If you make two patches out of it, I'd prefer to have the flashing instructions twice (just copy them). That's another thing I've learned; once linking is allowed, you will end up with link chains over 10 similar devices ... In this very simple case I'd also accept a single commit adding v1 and v2, though. I'd leave you to choose which version (1 or 2 commits) you prefer. Best Adrian > > Cheers > > Stijn > > > > >> the conclusion seemed to be that ZyXEL uses a unified image for both > > > > "Unified image" could be one image with different instructions or > > really the same image for both devices. The verdict would be different > > in each case. > > > >> versions (possibly even for the higher-port 10HP, 16, 24HP, ... > >> versions (the > >> HP suffixes indicating PoE support). > >> > >> Link: > >> https://forum.openwrt.org/t/support-for-rtl838x-based-managed- > >> switches/57875/263 > >> > >> Let me know what I should do for the v3. I'll happily send in > >> separate patches, but it looks like the boards don't care. You can > >> flash and run e.g. a 10HP image on an 8HP. It will work. > > > > Of course, but how does the ability to flash wrong images help us for > > this discussion? > > > > I'm probably over-careful here, but I have the idea of images that > > exactly match one device, and not just some rough general generic > > image that can be flashed on a variety of devices and will work > > somehow in the end. > > > > Best > > > > Adrian > > > >> > >> Thanks > >> > >> Stijn > >> > >> > > >> >> > >> >> The v1 seems to share its PCB and case with non-PoE GS1900-8; > >> the >> v2 with >> its already supported bigger brother, the > >> GS1900-10HP - its board >> looks the same, except for two holes > >> where the GS1900-10 has its SFP >> ports. > >> >> > >> >> Like their 10 port sibling, both devices have a dual firmware > >> >> layout. > >> >> > >> >> Both GS1900-8HP boards have the same 70W PoE+ power budget. > >> >> > >> >> Specifications (v1) > >> >> --- > >> >> * SoC: Realtek RTL8380M 500 MHz MIPS 4KEc > >> >> * Flash: Macronix MX25L12835F 16 MiB > >> >> * RAM: Nanya NT5TU128M8HE-AC 128 MiB DDR2 SDRAM > >> >> * Ethernet: 8x 10/100/1000 Mbit > >> >> * PoE+: Broadcom BCM59111KMLG (IEEE 802.3at-2009 > >> compliant, 2x) > >> >> * UART: 1 serial header with populated standard pin > >> connector > >> >> on the > >> >> left side of the PCB, towards the bottom. Pins are > >> >> labeled: > >> >> + VCC (3.3V) > >> >> + TX > >> >> + RX > >> >> + GND > >> >> > >> >> Specifications (v2) > >> >> --- > >> >> > >> >> * SoC: Realtek RTL8380M 500 MHz MIPS 4KEc > >> >> * Flash: Macronix MX25L12835F 16 MiB > >> >> * RAM: Samsung K4B1G0846G 128 MiB DDR3 SDRAM > >> >> * Ethernet: 8x 10/100/1000 Mbit > >> >> * PoE+: Broadcom BCM59121B0KMLG (IEEE 802.3at-2009 > >> compliant) > >> >> * UART: 1 angled serial header with populated standard pin > >> >> connector > >> >> accessible from outside through the ventilation > >> slits > >> >> on the > >> >> side. Pins from top to bottom are clearly marked > >> on the > >> >> PCB: > >> >> + VCC (3.3V) > >> >> + TX > >> >> + RX > >> >> + GND > >> >> > >> >> Connection parameters for serial on both devices: 115200 8N1. > >> >> > >> >> Installation > >> >> > >> >> > >> >> * Configure your client with a static 192.168.1.x IP (e.g. > >> >> 192.168.1.10). > >> >> * Set up a TFTP server on your client and make it serve the >> > >> initramfs > >> >>image. > >> >> * Connect serial, power up the switch, interrupt U-boot by > >> hitting >> the > >> >>space bar, and enable the network: > >> >># rtk network on > >> >> * Since the GS1900-10HP is a dual-partition device, you want to > >> keep >> the > >> >>OEM firmware on the backup partition for the time being. > >> OpenWrt > >> >> can > >> >>only boot off the first partition anyway (hardcoded in the > >> DTS). > >> >> To > >> >>make sure we are manipulating the first partition, issue the > >> >> following > >> >>commands: > >> >># setsys bootpartition 0 > >> >># savesys > >> >> * Download the image onto the device and boot from it: > >> >># tftpboot 0x84f0 > >> >> 192.168.1.10:openwrt-realtek-generic-zyxel_gs1900- > >> >> 8hp-initramfs-kernel.bin > >> >># bootm > >> >> * Once OpenWrt has booted, scp the sysupgrade image to /tmp and > >> >> flash it: > >> >># sysupgrade > >> /tmp//tmp/openwrt-realtek-generic-zyxel_gs1900-8hp- > >> >> squa
RE: [PATCH 4/5] realtek: introduce shared DTSI for GS1900-HP series
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Stijn Segers
> Sent: Mittwoch, 6. Januar 2021 22:45
> To: openwrt-devel@lists.openwrt.org
> Subject: [PATCH 4/5] realtek: introduce shared DTSI for GS1900-HP series
>
> The ZyXEL GS1900-8HP v1, v2 and GS1900-10HP are all built on a similar
> Realtek RTL8380M platform. Create a common DTSI in preparation for
> GS1900-8HP support, and switch to the macros defined in rtl838x.dtsi.
I've merged 1 to 3 with minor adjustments/fixes, but for this one the removed
and added sections don't match at all.
Please fix/rebase (and also changed the DTSI include in the DTS).
Best
Adrian
>
> Signed-off-by: Stijn Segers
> ---
> .../realtek/dts/rtl8380_zyxel_gs1900-10hp.dts | 190 +-
> .../realtek/dts/rtl8380_zyxel_gs1900.dtsi | 147 ++
> 2 files changed, 151 insertions(+), 186 deletions(-) create mode 100644
> target/linux/realtek/dts/rtl8380_zyxel_gs1900.dtsi
>
> diff --git a/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts
> b/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts
> index 0fb78926d9..5c53385020 100644
> --- a/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts
> +++ b/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts
> @@ -1,5 +1,4 @@
> // SPDX-License-Identifier: GPL-2.0-or-later -/dts-v1/;
>
> #include "rtl838x.dtsi"
>
> @@ -10,11 +9,6 @@
> compatible = "zyxel,gs1900-10hp", "realtek,rtl838x-soc";
> model = "ZyXEL GS1900-10HP Switch";
>
> - memory@0 {
> - device_type = "memory";
> - reg = <0x0 0x800>;
> - };
> -
> aliases {
> led-boot = &led_sys;
> led-failsafe = &led_sys;
> @@ -96,192 +90,16 @@
>
> };
>
> -&spi0 {
> - status = "okay";
> - flash@0 {
> - compatible = "jedec,spi-nor";
> - reg = <0>;
> - spi-max-frequency = <1000>;
> -
> - partitions {
> - compatible = "fixed-partitions";
> - #address-cells = <1>;
> - #size-cells = <1>;
> -
> - partition@0 {
> - label = "u-boot";
> - reg = <0x0 0x4>;
> - read-only;
> - };
> - partition@4 {
> - label = "u-boot-env";
> - reg = <0x4 0x1>;
> - read-only;
> - };
> - partition@5 {
> - label = "u-boot-env2";
> - reg = <0x5 0x1>;
> - read-only;
> - };
> - partition@6 {
> - label = "jffs";
> - reg = <0x6 0x10>;
> - };
> - partition@16 {
> - label = "jffs2";
> - reg = <0x16 0x10>;
> - };
> - partition@b26 {
> - label = "firmware";
> - reg = <0x26 0x6d>;
> - compatible = "denx,uimage";
> - };
> - partition@93 {
> - label = "runtime2";
> - reg = <0x93 0x6d>;
> - };
> - };
> - };
> -};
> -
> ðernet0 {
> mdio: mdio-bus {
> - compatible = "realtek,rtl838x-mdio";
> - regmap = <ðernet0>;
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - /* Internal phy */
> - phy8: ethernet-phy@8 {
> - reg = <8>;
> - compatible = "ethernet-phy-ieee802.3-c22";
> - };
> - phy9: ethernet-phy@9 {
> - reg = <9>;
> - compatible = "ethernet-phy-ieee802.3-c22";
> - };
> - phy10: ethernet-phy@10 {
> - reg = <10>;
> - compatible = "ethernet-phy-ieee802.3-c22";
> - };
> - phy11: ethernet-phy@11 {
> - reg = <11>;
> - compatible = "ethernet-phy-ieee802.3-c22";
> - };
> - phy12: ethernet-phy@12 {
> - reg = <12>;
> - compatible = "ethernet-phy-ieee802.3-c22";
> - };
> - phy13: ethernet-phy@13 {
> - reg = <13>;
> - compatible = "ethernet-phy-ieee802.3-c22";
> - };
> - phy14: ethernet-phy@14 {
> - reg = <14>;
> - compatible = "ethernet-phy-ieee802.3-c22";
> -
RE: [PATCH 4/5] realtek: introduce shared DTSI for GS1900-HP series
Hi,
> -Original Message-
> From: Stijn Segers [mailto:f...@volatilesystems.org]
> Sent: Donnerstag, 7. Januar 2021 22:23
> To: Adrian Schmutzler
> Cc: openwrt-devel@lists.openwrt.org
> Subject: RE: [PATCH 4/5] realtek: introduce shared DTSI for GS1900-HP series
>
> Hi Adrian,
>
> Op donderdag 7 januari 2021 om 19:54 schreef Adrian Schmutzler
> :
> > Hi,
> >
> >> -Original Message-
> >> From: openwrt-devel [mailto:openwrt-devel-
> boun...@lists.openwrt.org]
> >> On Behalf Of Stijn Segers
> >> Sent: Mittwoch, 6. Januar 2021 22:45
> >> To: openwrt-devel@lists.openwrt.org
> >> Subject: [PATCH 4/5] realtek: introduce shared DTSI for GS1900-HP
> >> series
> >>
> >> The ZyXEL GS1900-8HP v1, v2 and GS1900-10HP are all built on a
> >> similar Realtek RTL8380M platform. Create a common DTSI in
> >> preparation for GS1900-8HP support, and switch to the macros defined
> >> in rtl838x.dtsi.
> >
> > I've merged 1 to 3 with minor adjustments/fixes, but for this one the
> > removed and added sections don't match at all.
>
> I think your shuffling around the memory blocks (rightfully so) and the fact
> my patches already had some dts-v1 lines removed might have been a factor
> in that?
>
> Have sent in a v4 for the remaining two patches :-)
you still don't use the DTSI in the DTS, and only copy a part of it ...
This is still broken.
Best
Adrian
>
> Thank you
>
> Stijn
>
> >
> > Please fix/rebase (and also changed the DTSI include in the DTS).
> >
> > Best
> >
> > Adrian
> >
> >>
> >> Signed-off-by: Stijn Segers
> >> ---
> >> .../realtek/dts/rtl8380_zyxel_gs1900-10hp.dts | 190
> >> +-
> >> .../realtek/dts/rtl8380_zyxel_gs1900.dtsi | 147 ++
> >> 2 files changed, 151 insertions(+), 186 deletions(-) create mode
> >> 100644
> >> target/linux/realtek/dts/rtl8380_zyxel_gs1900.dtsi
> >>
> >> diff --git a/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts
> >> b/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts
> >> index 0fb78926d9..5c53385020 100644
> >> --- a/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts
> >> +++ b/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts
> >> @@ -1,5 +1,4 @@
> >> // SPDX-License-Identifier: GPL-2.0-or-later -/dts-v1/;
> >>
> >> #include "rtl838x.dtsi"
> >>
> >> @@ -10,11 +9,6 @@
> >>compatible = "zyxel,gs1900-10hp", "realtek,rtl838x-soc";
> >>model = "ZyXEL GS1900-10HP Switch";
> >>
> >> - memory@0 {
> >> - device_type = "memory";
> >> - reg = <0x0 0x800>;
> >> - };
> >> -
> >>aliases {
> >>led-boot = &led_sys;
> >>led-failsafe = &led_sys;
> >> @@ -96,192 +90,16 @@
> >>
> >> };
> >>
> >> -&spi0 {
> >> - status = "okay";
> >> - flash@0 {
> >> - compatible = "jedec,spi-nor";
> >> - reg = <0>;
> >> - spi-max-frequency = <1000>;
> >> -
> >> - partitions {
> >> - compatible = "fixed-partitions";
> >> - #address-cells = <1>;
> >> - #size-cells = <1>;
> >> -
> >> - partition@0 {
> >> - label = "u-boot";
> >> - reg = <0x0 0x4>;
> >> - read-only;
> >> - };
> >> - partition@4 {
> >> - label = "u-boot-env";
> >> - reg = <0x4 0x1>;
> >> - read-only;
> >> - };
> >> - partition@5 {
> >> - label = "u-boot-env2";
> >> - reg = <0x5 0x1>;
> >> - read-only;
> >> - };
> >> - partition@6 {
> >> - label = "jffs";
> >> - reg = <0x6 0x10>;
> >> - };
> >> -
