[PATCH v6] bmips: bcm6368-enetsw: Bump max MTU
The safe max frame size for this ethernet switch is 1532 bytes, excluding the DSA TAG and extra VLAN header, so the maximum outgoing frame is 1542 bytes. The available overhead is needed when using the DSA switch with a cascaded Marvell DSA switch, which is something that exist in real products, in this case the Inteno XG6846. Use defines at the top of the size for max MTU so it is clear how we think about this, add comments. We need to adjust the RX buffer size to fit the new max frame size, which is 1542 when the DSA tag (6 bytes) and VLAN header (4 extra bytes) is added. We also drop this default MTU: #define ENETSW_TAG_SIZE (6 + VLAN_HLEN) ndev->mtu = ETH_DATA_LEN + ENETSW_TAG_SIZE; in favor of just: ndev->mtu = ETH_DATA_LEN; I don't know why the default MTU is trying to second guess the overhead required by DSA and VLAN but the framework will also try to bump the MTU for e.g. DSA tags, and the VLAN overhead is not supposed to be included in the MTU, so this is clearly not right. Before this patch (on the lan1 DSA port in this case): dsa_slave_change_mtu: master->max_mtu = 9724, dev->max_mtu = 10218, DSA overhead = 8 dsa_slave_change_mtu: master = extsw, dev = lan1 dsa_slave_change_mtu: master->max_mtu = 1510, dev->max_mtu = 9724, DSA overhead = 6 dsa_slave_change_mtu: master = eth0, dev = extsw dsa_slave_change_mtu new_master_mtu 1514 > mtu_limit 1510 mdio_mux-0.1:00: nonfatal error -34 setting MTU to 1500 on port 0 My added debug prints before the nonfatal error: the first switch from the top is the Marvell switch, the second in the bcm6368-enetsw with its 1510 limit. After this patch the error is gone. OpenWrt adds a VLAN to each port so we get VLAN tags on all frames. On this setup we even have 4 more bytes left after the two DSA tags and VLAN so we can go all the way up to 1532 as MTU. Testing the new 1532 MTU: eth0 ext1 enp7s0 .. .---. cable .--. | enetsw | <-> | mv88e6152 | <-> | host | `´ `---´ `--´ On the router we set the max MTU for test: ifconfig eth0 mtu 1520 ifconfig br-wan mtu 1520 ifconfig ext1 mtu 1506 An MTU of 1506 on ext1 is a logic consequence of the above setup: this is the max bytes actually transferred. The framing added will be: - 18 bytes standard ethernet header - 4 bytes VLAN header - 6 bytes DSA tag for enetsw - 8 bytes DSA tag for mv88e6152 Sum: 1506 + 18 + 4 + 6 + 8 = 1542 which is out max frame size. Test pinging from host: ping -s 1478 -M do 192.168.1.220 PING 192.168.1.220 (192.168.1.220) 1478(1506) bytes of data. 1486 bytes from 192.168.1.220: icmp_seq=1 ttl=64 time=0.696 ms 1486 bytes from 192.168.1.220: icmp_seq=2 ttl=64 time=0.615 ms Test pinging from router: PING 192.168.1.2 (192.168.1.2): 1478 data bytes 1486 bytes from 192.168.1.2: seq=0 ttl=64 time=0.931 ms 1486 bytes from 192.168.1.2: seq=1 ttl=64 time=0.810 ms The max IP packet without headers is 1478, the outgoing ICMP packet is 1506 bytes. Then the DSA, VLAN and ethernet overhead is added. Let us verify the contents of the resulting ethernet frame of 1542 bytes. Ping packet on router side as viewed with tcpdump: 00:54:51.900869 AF Unknown (1429722180), length 1538: 0x: 3d93 bcae c56b a83d 8874 0300 0004 8100 =k.=.t.. 0x0010: dada c020 0fff 0800 4500 05e2 E... 0x0020: 4000 4001 b0ec c0a8 0102 c0a8 01dc ..@.@... 0x0030: 0800 7628 00c3 0001 f5da 1d65 ..v(...e 0x0040: ce65 0a00 1011 1213 1415 1617 .e.. 0x0050: 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 .!"#$%&' 0x0060: 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ()*+,-./0123456 (...) - 3d93 = First four bytes are the last two bytes of the destination ethernet address I don't know why the first four are missing, but it sure explains why the paket is 1538 bytes and not 1542 which is the actual max frame size. - bcae c56b a83b = source ethernet address - 8874 0300 0004 = Broadcom enetsw DSA tag - 8100 = VLAN 802.1Q header - dada c020 0fff = EDSA tag for the Marvell (outer) switch, - 0800 is the ethertype (part of the EDSA tag technically) - Next follows the contents of the ping packet as it appears if we dump it on the DSA interface such as tcpdump -i lan1 etc, there we get the stripped out packet, 1506 bytes. - At the end 4 bytes of FCS. This clearly illustrates that the DSA tag is included in the MTU which we set up in Linux, but the VLAN tag and ethernet headers and checksum is not. Cc: Álvaro Fernández Rojas Cc: Jonas Gorski Signed-off-by: Linus Walleij --- ChangeLog v5->v6: - Rewrite thoroughly after discussing with Jonas that the safe MTU is probably 1532 without DSA tag and extra VLAN header. - Reword commit message and redo tests so it is crystal clear what is going on, as illustrated by tcpdump. ChangeLog v4->v5: - Drop the confusing
Re: [PATCH v2 0/9] Resurrect OpenWrt IXP4xx support
W dniu 4.10.2023 o 19:11, Jonas Gorski pisze: > Hi, > > On Thu, 28 Sept 2023 at 15:29, Linus Walleij wrote: >> >> XP4xx was deleted because of lack of maintenance in 2020. >> >> In the years since, the upstream Linux support for IXP4xx has >> been rewritten from scratch. It is now pretty well supported >> using device tree and modern subsystems that didn't exist >> 20 years ago when the first IXP4xx port was done. >> >> With the switch to kernel v6.1, OpenWrt has the required >> baseline to bring IXP4xx back. >> >> With the (suspiciously similarly named!) IPQ4xxx now supporting >> v6.1 exclusively, the door should be open for IXP4xx! >> >> This is a reimplementation of the IXP4xx support which is >> using all the contemporary abstractions, the only thing >> actually resurrected is the APEX boot loader. The port is >> thus "slim" and not patching a lot on the mainline kernel >> as pretty much everything is upstream. >> >> As a starter, we bring back two Gateworks reference designs, >> one for IXP42x and one for IXP43x, and the classic NSLU2 >> NAS. We also bring back USRobotics USR8200 because it has >> active users and testers. >> >> Here you find binaries and illustrations if you want to check >> out how the support works right now, if you have an NSLU2 >> you can flash the binary and rootfs and it "just works", >> though NSLU2 is not a default build: >> https://dflund.se/~triad/krad/ixp4xx/ >> >> Thanks to Imre Kaloz add Krzysztof Halasa for all cheering >> and reference designs :) >> >> Thanks to Howard Harte and Joseph for stepping in and helping >> out with device support and debugging. >> >> Thanks for Hauke for the the in-depth review of the v1 >> patch set. >> >> I am pretty confident that we can bring back any IXP4xx with >> this, they just need some time and focus. I will add more >> routers as time permits. >> >> I don't know who can import this from patches or pull request: >> it may be best if I just apply for commit access to the >> OpenWrt git repository and import it myself perhaps? > > Fails to build for me when enabling all kmods: > > Package kmod-crypto-lib-chacha20poly1305 is missing dependencies for > the following libraries: > chacha-neon.ko > poly1305-arm.ko > make[3]: *** [modules/crypto.mk:570: > /home/jonas/git/openwrt/bin/targets/ixp4xx/generic/packages/kmod-crypto-lib-chacha20poly1305_6.1.55-1_armeb_xscale.ipk] > Error 1 This is because armeb is not defined in crypto.mk, fix should look something like this: --- a/package/kernel/linux/modules/crypto.mk +++ b/package/kernel/linux/modules/crypto.mk @@ -517,6 +517,8 @@ define KernelPackage/crypto-lib-chacha20/mips32r2 FILES:=$(LINUX_DIR)/arch/mips/crypto/chacha-mips.ko endef +KernelPackage/crypto-lib-chacha20/armeb=$(KernelPackage/crypto-lib-chacha20/arm) + ifeq ($(CONFIG_CPU_MIPS32_R2),y) KernelPackage/crypto-lib-chacha20/$(ARCH)=\ $(KernelPackage/crypto-lib-chacha20/mips32r2) @@ -610,6 +612,7 @@ define KernelPackage/crypto-lib-poly1305/mips FILES:=$(LINUX_DIR)/arch/mips/crypto/poly1305-mips.ko endef +KernelPackage/crypto-lib-poly1305/armeb=$(KernelPackage/crypto-lib-poly1305/arm) KernelPackage/crypto-lib-poly1305/mipsel=$(KernelPackage/crypto-lib-poly1305/mips) KernelPackage/crypto-lib-poly1305/mips64=$(KernelPackage/crypto-lib-poly1305/mips) KernelPackage/crypto-lib-poly1305/mips64el=$(KernelPackage/crypto-lib-poly1305/mips) For the record, pushing this repository to GitHub (no need to create PR) will trigger various checks which could show this error. Regards -- TMN ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 5/9] ixp4xx: Resurrect IXP4xx support using device tree
Hi,
some comments inline.
W dniu 28.09.2023 o 15:28, Linus Walleij pisze:
> This resurrects the support for IXP4xx using device tree
> rather than the old (deleted) board files. The final pieces
> of IXP4xx board files were deleted in Linux v5.19.
>
> Ext4 root filesystems on CF and USB are supported by the
> default config.
>
> We support these three initial targets:
>
> - The Gateworks Avila GW2348 reference design has 64MB of RAM
> and 32MB of flash and also supports USB and CompactFlash.
>
> - The Gateworks Cambria GW2358 reference design has 128MB of
> RAM and 32MB of flash and also supports USB and CompactFlash.
>
> - The old and stable Linksys NSLU2 works fine as well, albeit
> it only has 32MB of RAM so it has been marked as non-default.
> The 8MB of flash can only fit the kernel, so it has been
> patched to boot from exteral media on USB. I have used
> it successfully as a NAS with ksmbd and LUCI web API, see:
> https://dflund.se/~triad/krad/ixp4xx/
What I'm lacking is sysupgrade image. Currently, as I see it, if kernel grows
beyond what's stored in FIS table, user will need to go back to bootloader
console
to update whole system. That's not very convenient. We have devices with RedBoot
which support sysupgrade, alas only for devices which have FIS table and RedBoot
config on separate erase block, if that's the case for ones in this target,
check how we create sysupgrade image for adtran_bsap1880 in ath79 target.
The paths of interest would be:
target/linux/ath79/image/generic.mk
target/linux/ath79/generic/base-files/lib/upgrade/platform.sh
target/linux/ath79/generic/base-files/lib/upgrade/redboot-fis.sh
The "slug" seems to be different one, but it has access to the flash from
running
OpenWrt, so definitely sysupgrade path could be created for it.
>
> Signed-off-by: Howard Harte
> Signed-off-by: Linus Walleij
> ---
> ChangeLog v1->v2:
> - Have NSLU2 select the apex boot loader instead of having
> it default built for all targets.
> - SPDX header for the microcode package.
> - Set microcode package version back to 1.
> - Split the microcode firmware package in two, one for
> just regular ethernet, one for WAN/HSS and select the
> right package for each device, ridding us one useless
> firmware file per device.
> - Cleanup Kconfig using make kernel_oldconfig.
> - Remove several surplus kernel Kconfig options, some
> pointless 8250 extensions for example.
> - Drop all the RTCs from the Kconfig and use the corresponding
> kernel modules for each device instead, saving space.
> - Drop all the HWMON drivers from the Kconfig and use the
> corresponding kernel modules for each device instead.
> - Use a kernel module for EEPROM access on Gateworks devices.
> - Fold in an ethernet numbering fix from Howard Harte
> - Activate Marvell MV88E6060 DSA switch as used by
> USRobotics USR8200.
> ---
> package/firmware/ixp4xx-microcode/Makefile | 77 +++
> .../firmware/ixp4xx-microcode/src/IxNpeMicrocode.h | 148
> package/firmware/ixp4xx-microcode/src/LICENSE.IPL | 27 +++
> target/linux/ixp4xx/Makefile | 27 +++
> .../linux/ixp4xx/base-files/etc/board.d/02_network | 21 ++
> .../base-files/lib/preinit/05_set_ether_mac_ixp4xx | 45
> target/linux/ixp4xx/config-6.1 | 252
> +
> target/linux/ixp4xx/image/Makefile | 76 +++
> ...01-mtd-cfi_cmdset_0001-Byte-swap-OTP-info.patch | 74 ++
> ...-ARM-dts-ixp4xx-Boot-NSLU2-from-harddrive.patch | 24 ++
> 10 files changed, 771 insertions(+)
>
[...]
> diff --git
> a/target/linux/ixp4xx/base-files/lib/preinit/05_set_ether_mac_ixp4xx
> b/target/linux/ixp4xx/base-files/lib/preinit/05_set_ether_mac_ixp4xx
> new file mode 100644
> index ..2feacbfe313e
> --- /dev/null
> +++ b/target/linux/ixp4xx/base-files/lib/preinit/05_set_ether_mac_ixp4xx
> @@ -0,0 +1,45 @@
> +#!/bin/sh
> +. /lib/functions.sh
> +. /lib/functions/system.sh
> +
> +set_from_redboot () {
> + for npe in eth0 eth1 eth2
> + do
> + if ifconfig $npe > /dev/null 2>&1; then
Small nitpick, here "ifconfig" but later "ip", I know it's just an applet
but some consistency would be nice.
> + ip link set dev $npe address $(fconfig -s -r -d /dev/$1
> -n npe_"$npe"_esa)
> + fi
> + done
> +
> + # -- Fixup for the WG302v1, need someone with a WAG302v1 to fix that,
> too
Patch doesn't introduce support for this board, so remove cases for boards which
are not included in this patch.
> +
> + if [ "$(ifconfig eth0 2>/dev/null | grep -c 00:00:00:00:00:00)" = "1"
> ]; then
> + ip link set dev $npe address $(fconfig -s -r -d /dev/$1 -n
> zcom_npe_esa)
> + fi
> +
> + # Others (*cough*, Tonze) are not handling mac addresses at all
> +
> + if [ "$(ifconfig eth0 2>/dev/null | grep -c 00:00:00:00:00:00)" = "1"
> ]; then
> + ip link set dev eth0 address
Re: [PATCH v2 0/9] Resurrect OpenWrt IXP4xx support
Hi, On Thu, 28 Sept 2023 at 15:29, Linus Walleij wrote: > > XP4xx was deleted because of lack of maintenance in 2020. > > In the years since, the upstream Linux support for IXP4xx has > been rewritten from scratch. It is now pretty well supported > using device tree and modern subsystems that didn't exist > 20 years ago when the first IXP4xx port was done. > > With the switch to kernel v6.1, OpenWrt has the required > baseline to bring IXP4xx back. > > With the (suspiciously similarly named!) IPQ4xxx now supporting > v6.1 exclusively, the door should be open for IXP4xx! > > This is a reimplementation of the IXP4xx support which is > using all the contemporary abstractions, the only thing > actually resurrected is the APEX boot loader. The port is > thus "slim" and not patching a lot on the mainline kernel > as pretty much everything is upstream. > > As a starter, we bring back two Gateworks reference designs, > one for IXP42x and one for IXP43x, and the classic NSLU2 > NAS. We also bring back USRobotics USR8200 because it has > active users and testers. > > Here you find binaries and illustrations if you want to check > out how the support works right now, if you have an NSLU2 > you can flash the binary and rootfs and it "just works", > though NSLU2 is not a default build: > https://dflund.se/~triad/krad/ixp4xx/ > > Thanks to Imre Kaloz add Krzysztof Halasa for all cheering > and reference designs :) > > Thanks to Howard Harte and Joseph for stepping in and helping > out with device support and debugging. > > Thanks for Hauke for the the in-depth review of the v1 > patch set. > > I am pretty confident that we can bring back any IXP4xx with > this, they just need some time and focus. I will add more > routers as time permits. > > I don't know who can import this from patches or pull request: > it may be best if I just apply for commit access to the > OpenWrt git repository and import it myself perhaps? Fails to build for me when enabling all kmods: Package kmod-crypto-lib-chacha20poly1305 is missing dependencies for the following libraries: chacha-neon.ko poly1305-arm.ko make[3]: *** [modules/crypto.mk:570: /home/jonas/git/openwrt/bin/targets/ixp4xx/generic/packages/kmod-crypto-lib-chacha20poly1305_6.1.55-1_armeb_xscale.ipk] Error 1 .config: CONFIG_TARGET_ixp4xx=y CONFIG_ALL_KMODS=y Best Regards, Jonas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v5] bmips: bcm6368-enetsw: Bump max MTU
The max frame size "jumbo" for this ethernet switch is 2048 bytes, excluding the VLAN headers, which is 2048 - VLAN_ETH_HLEN - VLAN_HLEN = 2048 - 18 - 4 = 2026 not ETH_DATA_LEN + ENETSW_TAG_SIZE = 1500 + 4 + 6 = 1510 as it is right now. The available overhead is needed when using the DSA switch with a cascaded Marvell DSA switch, which is something that exist in real products, in this case the Inteno XG6846. We need to adjust the RX buffer size to fit the new max frame size. Before this patch (on the lan1 DSA port in this case): dsa_slave_change_mtu: master->max_mtu = 9724, dev->max_mtu = 10218, DSA overhead = 8 dsa_slave_change_mtu: master = extsw, dev = lan1 dsa_slave_change_mtu: master->max_mtu = 1510, dev->max_mtu = 9724, DSA overhead = 6 dsa_slave_change_mtu: master = eth0, dev = extsw dsa_slave_change_mtu new_master_mtu 1514 > mtu_limit 1510 mdio_mux-0.1:00: nonfatal error -34 setting MTU to 1500 on port 0 My added debug prints before the nonfatal error: the first switch from the top is the Marvell switch, the second in the bcm6368-enetsw with its 1510 limit. After this patch the error is gone. OpenWrt adds a VLAN to each port so we get VLAN tags on all frames. Testing the new 2026 MTU: eth0 ext1 enp7s0 .. .---. .--. | enetsw | <-> | mv88e8152 | <-> | host | `´ `---´ `--´ On the router: Notice that the max MTU for the ext1 switch (mv88e8152)needs to be 18 bytes less than the eth0 (enetsw). That's the VLAN overhead since OpenWrt sets up one VLAN per external port. On the host we just set the max MTU for test: Test pininging from host: PING 192.168.1.220 (192.168.1.220) 1984(2012) bytes of data. 1992 bytes from 192.168.1.220: icmp_seq=1 ttl=64 time=0.687 ms 1992 bytes from 192.168.1.220: icmp_seq=2 ttl=64 time=0.670 ms Test pinging from router: PING 192.168.1.2 (192.168.1.2): 1984 data bytes 1992 bytes from 192.168.1.2: seq=0 ttl=64 time=1.021 ms 1992 bytes from 192.168.1.2: seq=1 ttl=64 time=0.909 ms The max IP packet without headers is 1984, the outgoing ICMP packet is 1992 bytes, then 32 bytes are added up to 2048 as described below. Ping packet on router side as viewed with tcpdump: 00:15:13.516325 AF Unknown (1429722180), length 2044: 0x: 3d93 bcae c56b a83d 8874 03fd 0004 8100 =k.=.t.. 0x0010: dada c020 0fff 0800 4500 07dc E... 0x0020: 4000 4001 aef2 c0a8 0102 c0a8 01dc ..@.@... 0x0030: 0800 43b6 0092 0001 9c4c 1c65 ..C..L.e 0x0040: 2963 0400 1011 1213 1415 1617 )c.. 0x0050: 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 .!"#$%&' 3d93 = First four bytes are the last two bytes of the destination ethernet address I don't know why the first four are missing, but it sure explains why the paket is 2044 bytes and not 2048 which is the actual max MTU. bcae c56b a83b = source ethernet address 8874 03fd 0004 = Broadcom enetsw DSA tag 8100 = VLAN 802.1Q header dada c020 0fff 0800 = EDSA tag for the Marvell (outer) switch, 0800 is the ethertype obviously included in the tag Next follows the contents of the ping packet as it appears if we dump it on the DSA interface such as tcpdump -i lan1 etc, there we get the stripped out packet. At the end 4 bytes of FCS. Cc: Álvaro Fernández Rojas Cc: Jonas Gorski Signed-off-by: Linus Walleij --- ChangeLog v4->v5: - Drop the confusing ENETSW_MTU_OVERHEAD altogether after discussing with Jonas. ChangeLog v3->v4: - Adjust the RX buffer size and we can use the max "jumbo" frame size 2048. ChangeLog v2->v3: - Make a more believable case for the max MTU with tcpdump example. ChangeLog v1->v2: - Do some better research after help on IRC, did some ping tests. --- .../drivers/net/ethernet/broadcom/bcm6368-enetsw.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/target/linux/bmips/files/drivers/net/ethernet/broadcom/bcm6368-enetsw.c b/target/linux/bmips/files/drivers/net/ethernet/broadcom/bcm6368-enetsw.c index 321e95dbbb3d..aa09c1707819 100644 --- a/target/linux/bmips/files/drivers/net/ethernet/broadcom/bcm6368-enetsw.c +++ b/target/linux/bmips/files/drivers/net/ethernet/broadcom/bcm6368-enetsw.c @@ -22,10 +22,10 @@ #include #include -/* MTU */ +/* The max frame size is 2048 including VLAN headers but excluding the 6 byte DSA tag */ +#define ENETSW_MAX_FRAME 2048 +#define ENETSW_MAX_MTU (ENETSW_MAX_FRAME - VLAN_ETH_HLEN - VLAN_HLEN) #define ENETSW_TAG_SIZE(6 + VLAN_HLEN) -#define ENETSW_MTU_OVERHEAD(VLAN_ETH_HLEN + VLAN_HLEN + \ -ENETSW_TAG_SIZE) #define ENETSW_FRAG_SIZE(x)(SKB_DATA_ALIGN(NET_SKB_PAD + x + \ SKB_DATA_ALIGN(sizeof(struct skb_shared_info @@ -1006,7 +1006,7 @@
Re: [PATCH v2 1/9] boot/apex: Restore the APEX boot loader
On Wed, 4 Oct 2023 at 14:51, Robert Marko wrote: > > On Thu, 28 Sept 2023 at 15:29, Linus Walleij wrote: > > > > This is a partial revert of the deletion of the IXP4xx > > target: we restore the APEX boot loader so we can use it > > for the NSLU2 and related targets. > > > > The APEX upstream is as dead as it gets so I have applied > > OpenWrts old patches on top of the never released > > v1.6.10 version and forked it into an OpenWrt variant > > on GitHub. If the upstream comes back alive I will > > happily switch over to it. > > > > The file refers to the external GitHub, I suppose when > > integrating this patch the file should be copied to OpenWrts > > file repository and the file link changed. > > > > Signed-off-by: Linus Walleij > > --- > > ChangeLog v1->v2: > > - Do not default to "y", instead make the device target > > select apex by default. > > - Do not package the boot loader into the rootfs image. > > Who wants that. > > --- > > package/boot/apex/Makefile | 55 > > ++ > > 1 file changed, 55 insertions(+) > > > > diff --git a/package/boot/apex/Makefile b/package/boot/apex/Makefile > > new file mode 100644 > > index ..817e15d8e643 > > --- /dev/null > > +++ b/package/boot/apex/Makefile > > @@ -0,0 +1,55 @@ > > +# SPDX-License-Identifier: GPL-2.0-only > > +# > > +# Copyright (C) 2006-2023 OpenWrt.org > > + > > +include $(TOPDIR)/rules.mk > > +include $(INCLUDE_DIR)/kernel.mk > > + > > +PKG_NAME:=apex > > +# This version was created from the stalled and unreleased v1.6.10 > > +# with some patches on top. > > +PKG_VERSION:=1.6.10-openwrt > > +PKG_RELEASE:=1 > > + > > +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz > > +PKG_SOURCE_URL:=https://github.com/linusw/apex/releases/download/v1.6.10-openwrt/ > > +PKG_HASH:=034baa99574014f4bcb8d36baf830fa942bef816b22e228eabd7c5663612c640 > > +PKG_TARGETS:=bin > > + > > +include $(INCLUDE_DIR)/package.mk > > + > > +export GCC_HONOUR_COPTS=s > > + > > +define Package/apex > > + SECTION:=boot > > + CATEGORY:=Boot Loaders > > + DEPENDS:=@TARGET_ixp4xx > > This will probably break the package if one tries to bisect as there > is no ixp4xx target yet. No it's fine, it just depends on a non-existing symbol, so will be unselectable until the ixp4xx target is added. So exactly the right order here. Best Regards, Jonas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 8/9] Delete arm-magic script
On Thu, Sep 28, 2023 at 03:28:31PM +0200, Linus Walleij wrote: > This script was used to modify the wrong machine type passed > from the boot loader to the kernel. The device tree kernels > does not use the machine type so this script is no longer > needed. > > Signed-off-by: Linus Walleij Can you change the commit title to something like scripts/arm-magic.sh: drop unused script ? -- Ansuel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 6/9] ixp4xx: Add a ixp4xx hardware crypto kernel module
On Thu, 28 Sept 2023 at 15:29, Linus Walleij wrote: > > The IXP4xx crypto module must be loaded after the rootfs is > up as it depends on loading some NPE microcode from the file > system. > > Signed-off-by: Linus Walleij > --- > package/kernel/linux/modules/crypto.mk | 13 + > target/linux/ixp4xx/Makefile | 1 + > 2 files changed, 14 insertions(+) > > diff --git a/package/kernel/linux/modules/crypto.mk > b/package/kernel/linux/modules/crypto.mk > index 501be4b0a02c..bfb70f0344fb 100644 > --- a/package/kernel/linux/modules/crypto.mk > +++ b/package/kernel/linux/modules/crypto.mk > @@ -399,6 +399,19 @@ endef > > $(eval $(call KernelPackage,crypto-hw-hifn-795x)) > > +define KernelPackage/crypto-hw-ixp4xx > + TITLE:=Intel IXP4xx crypto accelerator > + DEPENDS:=@TARGET_ixp4xx +kmod-random-core +kmod-crypto-manager > +kmod-crypto-authenc +kmod-crypto-des > + KCONFIG:= \ > + CONFIG_CRYPTO_HW=y \ > + CONFIG_CRYPTO_DEV_IXP4XX > + FILES:=$(LINUX_DIR)/drivers/crypto/ixp4xx_crypto.ko > + AUTOLOAD:=$(call AutoLoad,09,ixp4xx_crypto) AutoProbe should work here since its now DT-based and can be probed against the compatible instead of manually loading it. Regards Robert > + $(call AddDepends/crypto) > +endef > + > +$(eval $(call KernelPackage,crypto-hw-ixp4xx)) > + > > define KernelPackage/crypto-hw-padlock >TITLE:=VIA PadLock ACE with AES/SHA hw crypto module > diff --git a/target/linux/ixp4xx/Makefile b/target/linux/ixp4xx/Makefile > index 89a1b2407bfe..6cd30877 100644 > --- a/target/linux/ixp4xx/Makefile > +++ b/target/linux/ixp4xx/Makefile > @@ -21,6 +21,7 @@ KERNELNAME:=zImage dtbs > include $(INCLUDE_DIR)/target.mk > > DEFAULT_PACKAGES += fconfig \ > + kmod-crypto-hw-ixp4xx \ > kmod-usb-ledtrig-usbport \ > kmod-leds-gpio > > > -- > 2.34.1 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 1/9] boot/apex: Restore the APEX boot loader
On Thu, 28 Sept 2023 at 15:29, Linus Walleij wrote: > > This is a partial revert of the deletion of the IXP4xx > target: we restore the APEX boot loader so we can use it > for the NSLU2 and related targets. > > The APEX upstream is as dead as it gets so I have applied > OpenWrts old patches on top of the never released > v1.6.10 version and forked it into an OpenWrt variant > on GitHub. If the upstream comes back alive I will > happily switch over to it. > > The file refers to the external GitHub, I suppose when > integrating this patch the file should be copied to OpenWrts > file repository and the file link changed. > > Signed-off-by: Linus Walleij > --- > ChangeLog v1->v2: > - Do not default to "y", instead make the device target > select apex by default. > - Do not package the boot loader into the rootfs image. > Who wants that. > --- > package/boot/apex/Makefile | 55 > ++ > 1 file changed, 55 insertions(+) > > diff --git a/package/boot/apex/Makefile b/package/boot/apex/Makefile > new file mode 100644 > index ..817e15d8e643 > --- /dev/null > +++ b/package/boot/apex/Makefile > @@ -0,0 +1,55 @@ > +# SPDX-License-Identifier: GPL-2.0-only > +# > +# Copyright (C) 2006-2023 OpenWrt.org > + > +include $(TOPDIR)/rules.mk > +include $(INCLUDE_DIR)/kernel.mk > + > +PKG_NAME:=apex > +# This version was created from the stalled and unreleased v1.6.10 > +# with some patches on top. > +PKG_VERSION:=1.6.10-openwrt > +PKG_RELEASE:=1 > + > +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz > +PKG_SOURCE_URL:=https://github.com/linusw/apex/releases/download/v1.6.10-openwrt/ > +PKG_HASH:=034baa99574014f4bcb8d36baf830fa942bef816b22e228eabd7c5663612c640 > +PKG_TARGETS:=bin > + > +include $(INCLUDE_DIR)/package.mk > + > +export GCC_HONOUR_COPTS=s > + > +define Package/apex > + SECTION:=boot > + CATEGORY:=Boot Loaders > + DEPENDS:=@TARGET_ixp4xx This will probably break the package if one tries to bisect as there is no ixp4xx target yet. Regards, Robert > + TITLE:=Boot loader for NSLU2, FSG3, NAS100D and others > +endef > + > +define build_apex > + $(MAKE) -C $(PKG_BUILD_DIR) \ > + ARCH=arm \ > + $(1)_config > + $(MAKE) -C $(PKG_BUILD_DIR) \ > + $(TARGET_CONFIGURE_OPTS) \ > + KBUILD_HAVE_NLS=no \ > + ARCH=arm \ > + clean all > + $(INSTALL_BIN) $(PKG_BUILD_DIR)/apex.bin > $(PKG_BUILD_DIR)/out/apex-$(2).bin > +endef > + > +define Build/Compile > + $(INSTALL_DIR) $(PKG_BUILD_DIR)/out > + $(call build_apex,openwrt-nslu2-armeb,nslu2-armeb) > + $(call build_apex,openwrt-nslu2-16mb-armeb,nslu2-16mb-armeb) > + $(call build_apex,openwrt-fsg3-armeb,fsg3-armeb) > + $(call build_apex,openwrt-nas100d-armeb,nas100d-armeb) > +endef > + > +define Package/apex/install > + $(INSTALL_DIR) $(STAGING_DIR)/apex > + $(CP) $(PKG_BUILD_DIR)/out/*.bin $(1)/ > +endef > + > +$(eval $(call BuildPackage,apex)) > > -- > 2.34.1 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 3/9] kernel: Add kmod-rtc-r7301
On Thu, 28 Sept 2023 at 15:29, Linus Walleij wrote: > > To support the IXP42x platforms we need a kernel module > for the Epson R7301 RTC so we can load it as an optional > module. > > Signed-off-by: Linus Walleij > --- > package/kernel/linux/modules/other.mk | 15 +++ > 1 file changed, 15 insertions(+) > > diff --git a/package/kernel/linux/modules/other.mk > b/package/kernel/linux/modules/other.mk > index 187c0c56f0bb..8e7da1ca2c6f 100644 > --- a/package/kernel/linux/modules/other.mk > +++ b/package/kernel/linux/modules/other.mk > @@ -728,6 +728,21 @@ endef > > $(eval $(call KernelPackage,rtc-pcf2127)) > > +define KernelPackage/rtc-r7301 > + SUBMENU:=$(OTHER_MENU) > + TITLE:=Epson RTC7301 support > + DEFAULT:=m if ALL_KMODS && RTC_SUPPORT > + KCONFIG:=CONFIG_RTC_DRV_R7301 \ > + CONFIG_RTC_CLASS=y > + FILES:=$(LINUX_DIR)/drivers/rtc/rtc-r7301.ko > + AUTOLOAD:=$(call AutoLoad,50,rtc-r7301,1) Same question as for the other RTC kmod: Any reason why this cannot be probed instead, also why does it have to be included in preinit as well? Regards, Robert > +endef > + > +define KernelPackage/rtc-r7301/description > + Kernel module for Epson RTC7301 RTC chip > +endef > + > +$(eval $(call KernelPackage,rtc-r7301)) > > define KernelPackage/rtc-rs5c372a >SUBMENU:=$(OTHER_MENU) > > -- > 2.34.1 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 2/9] kernel: Add kmod-rtc-x1205
On Thu, 28 Sept 2023 at 15:29, Linus Walleij wrote: > > To support the IXP42x platforms we need a kernel module > for the X1205 RTC so we can load it as an optional module. > > Signed-off-by: Linus Walleij > --- > package/kernel/linux/modules/other.mk | 16 > 1 file changed, 16 insertions(+) > > diff --git a/package/kernel/linux/modules/other.mk > b/package/kernel/linux/modules/other.mk > index ac26c2a15037..187c0c56f0bb 100644 > --- a/package/kernel/linux/modules/other.mk > +++ b/package/kernel/linux/modules/other.mk > @@ -780,6 +780,22 @@ endef > > $(eval $(call KernelPackage,rtc-s35390a)) > > +define KernelPackage/rtc-x1205 > + SUBMENU:=$(OTHER_MENU) > + TITLE:=Xicor Intersil X1205 > + DEFAULT:=m if ALL_KMODS && RTC_SUPPORT > + DEPENDS:=+kmod-i2c-core > + KCONFIG:=CONFIG_RTC_DRV_X1205 \ > + CONFIG_RTC_CLASS=y > + FILES:=$(LINUX_DIR)/drivers/rtc/rtc-x1205.ko > + AUTOLOAD:=$(call AutoLoad,50,rtc-x1205,1) Any reason why this cannot be probed instead, also why does it have to be included in preinit as well? Regards, Robert > +endef > + > +define KernelPackage/rtc-x1205/description > + Kernel module for Xicor Intersil X1205 I2C RTC chip > +endef > + > +$(eval $(call KernelPackage,rtc-x1205)) > > define KernelPackage/mtdtests >SUBMENU:=$(OTHER_MENU) > > -- > 2.34.1 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 4/9] kernel: netdevices: Package AMD PHY
On Thu, 28 Sept 2023 at 15:29, Linus Walleij wrote: > > This adds a package for the AMD and Altima PHY, found in some > odd devices. > > Signed-off-by: Linus Walleij > --- > package/kernel/linux/modules/netdevices.mk | 16 > 1 file changed, 16 insertions(+) > > diff --git a/package/kernel/linux/modules/netdevices.mk > b/package/kernel/linux/modules/netdevices.mk > index b0d69e022069..392bc176f491 100644 > --- a/package/kernel/linux/modules/netdevices.mk > +++ b/package/kernel/linux/modules/netdevices.mk > @@ -224,6 +224,22 @@ endef > $(eval $(call KernelPackage,phylib-broadcom)) > > > +define KernelPackage/phy-amd > + SUBMENU:=$(NETWORK_DEVICES_MENU) > + TITLE:=AMD PHY driver > + KCONFIG:=CONFIG_AMD_PHY > + DEPENDS:=+kmod-libphy > + FILES:=$(LINUX_DIR)/drivers/net/phy/amd.ko > + AUTOLOAD:=$(call AutoProbe,and) Is this PHY used on the only networking interface on any board? Cause if so, then it would make sense to include it in preinit so that failsafe will also work. Regards, Robert > +endef > + > +define KernelPackage/phy-amd/description > + Currently supports the AMD and Altima PHYs. > +endef > + > +$(eval $(call KernelPackage,phy-amd)) > + > + > define KernelPackage/phy-ax88796b > SUBMENU:=$(NETWORK_DEVICES_MENU) > TITLE:=Asix PHY driver > > -- > 2.34.1 > > > ___ > 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
Słowa kluczowe do wypozycjonowania
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Dzień dobry, zapoznałem się z Państwa ofertą i z przyjemnością przyznaję, że przyciąga uwagę i zachęca do dalszych rozmów. Pomyślałem, że może mógłbym mieć swój wkład w Państwa rozwój i pomóc dotrzeć z tą ofertą do większego grona odbiorców. Pozycjonuję strony www, dzięki czemu generują świetny ruch w sieci. Możemy porozmawiać w najbliższym czasie? Pozdrawiam Kamil Tralewski --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
