Re: [PATCH v4 0/7] Resurrect OpenWrt IXP4xx support
On Wed, Oct 25, 2023 at 11:31 AM Christian Marangi wrote: > Hi, I merged this series on main. Thanks Christian! (I hope it doesn't explode...) > I hope to have followup for the firmware (hoping it will ever be > accepted upstream) Yeah I am working on that. > and for the hotplug script for the disk? That I think > was dropped from the series? Yes I have to check if I can rework it to a generic hotplug script and drop the corresponding thing in Gemini, it's useful for any NAS setup. Yours, Linus Walleij ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v4 0/7] Resurrect OpenWrt IXP4xx support
On Mon, Oct 23, 2023 at 08:43:02AM +0200, 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. Thanks to Christian Marangi, Robert Marko and > Jonas Gorski for reviewing the v2 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? > > Signed-off-by: Linus Walleij Hi, I merged this series on main. I hope to have followup for the firmware (hoping it will ever be accepted upstream) and for the hotplug script for the disk? That I think was dropped from the series? -- Ansuel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v4 0/7] Resurrect OpenWrt IXP4xx support
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. Thanks to Christian Marangi, Robert Marko and Jonas Gorski for reviewing the v2 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? Signed-off-by: Linus Walleij --- Changes in v4: - Bring the AMD Phy online at preinit, since this may sit on a primary network interface. - Split off some USR8200 patches to generic kernel patches and moved these to the front of the series so they can be applied. - Drop applied patches. - Link to v3: https://lore.kernel.org/r/20231012-ixp4xx-v3-0-e09c74712...@linaro.org Changes in v3: - Drop applied patch. - Move APEX to build from a git URL (Ansuel) - Add a build rule for lib-chacha20 for armeb - Split microcode firmware resurrection to its own patch - Use AutoProbe on RTC modules and crypto module - Name devices with vendor_device tuples - Fix network script for MAC to use just ip not ifconfig - Add a separate patch for the USRobotics USR8200 router. - Deferring system upgrade for later since it is a major implementation and can be done on top (I still plan to do it!) - Pushed to github and no build complaints. I suppose no news is good news. - Link to v2: https://lore.kernel.org/r/20230928-ixp4xx-v2-0-ce011eef8...@linaro.org Changes in v2: - See details in patches, most feedback is adressed. - Link to v1: http://lists.openwrt.org/pipermail/openwrt-devel/2023-June/041193.html --- Linus Walleij (7): kernel: netdevices: Package AMD PHY generic: RTC7301 byte-addressed IO generic: Support Altima AMI101L PHY firmware: Resurrect the ixp4xx microcode package ixp4xx: Resurrect IXP4xx support using device tree ixp4xx: Add a ixp4xx hardware crypto kernel module ixp4xx: Add USRobotics USR8200 support package/firmware/ixp4xx-microcode/Makefile | 77 ++ .../firmware/ixp4xx-microcode/src/IxNpeMicrocode.h | 148 package/firmware/ixp4xx-microcode/src/LICENSE.IPL | 27 +++ package/kernel/linux/modules/crypto.mk | 13 ++ package/kernel/linux/modules/netdevices.mk | 16 ++ ...6.7-rtc-rtc7301-Support-byte-addressed-IO.patch | 93 7-net-phy-amd-Support-the-Altima-AMI101L.patch | 82 +++ target/linux/ixp4xx/Makefile | 28 +++ .../linux/ixp4xx/base-files/etc/board.d/02_network | 26 +++ .../base-files/lib/preinit/05_set_ether_mac_ixp4xx | 38 +++ target/linux/ixp4xx/config-6.1 | 253 target/linux/ixp4xx/image/Makefile | 90 +++ ...01-mtd-cfi_cmdset_0001-Byte-swap-OTP-info.patch | 74 ++ ...p4xx-Handle-clock-output-on-pin-14-and-15.patch | 93 ...ixp4xx-Add-USRobotics-USR8200-device-tree.patch | 260 + ...5-net-ixp4xx_eth-Support-changing-the-MTU.patch | 132 +++ ...dog-ixp4xx-Make-sure-restart-always-works.patch | 79 +++ .../0008-ARM-dts-usr8200-Fix-phy-registers.patch | 67 ++ ...-ARM-dts-ixp4xx-Boot-NSLU2-from-harddrive.patch | 24 ++ 19 files changed, 1620 insertions(+) --- base-commit: ef9641f7799b82bb4b00e94c6db5298a77065038 change-id: 20230928-ixp4xx-a393c84d9468 Best regards, -- Linus Walleij ___ openwrt-devel mailing list
