from:"Linus Walleij"

[PATCH v2 3/4] uboot-bmips: Add U-Boot for the BMIPS target

2024-04-25 Thread Linus Walleij

This is needed to boot the BCM6238-based Inteno XG6846.
Currently this is restricted to the XG6846 board.

Signed-off-by: Linus Walleij 
---
 .github/labeler.yml   |  1 +
 package/boot/uboot-bmips/Makefile | 32 
 2 files changed, 33 insertions(+)

diff --git a/.github/labeler.yml b/.github/labeler.yml
index fd26dd7f3831..beb7787d34b2 100644
--- a/.github/labeler.yml
+++ b/.github/labeler.yml
@@ -30,6 +30,7 @@
   - "package/boot/arm-trusted-firmware-bcm63xx/**"
 "target/bmips":
   - "target/linux/bmips/**"
+  - "package/boot/uboot-bmips/**"
 "target/d1":
   - "target/linux/d1/**"
   - "package/boot/uboot-d1/**"
diff --git a/package/boot/uboot-bmips/Makefile 
b/package/boot/uboot-bmips/Makefile
new file mode 100644
index ..5581a6fbfc9b
--- /dev/null
+++ b/package/boot/uboot-bmips/Makefile
@@ -0,0 +1,32 @@
+include $(TOPDIR)/rules.mk
+
+PKG_VERSION:=2024.04
+PKG_HASH:=18a853fe39fad7ad03a90cc2d4275aeaed6da69735defac3492b80508843dd4a
+PKG_RELEASE:=$(AUTORELEASE)
+
+include $(INCLUDE_DIR)/u-boot.mk
+include $(INCLUDE_DIR)/package.mk
+
+define U-Boot/Default
+  BUILD_TARGET:=bmips
+  BUILD_SUBTARGET:=bcm6328
+  UBOOT_CONFIG:=inteno_xg6846_ram
+  UBOOT_BOARD:=$(1)
+endef
+
+define U-Boot/xg6846
+  NAME:=Inteno XG6846
+  BUILD_DEVICES:=inteno_xg6846
+endef
+
+UBOOT_TARGETS := xg6846
+
+define Build/InstallDev
+   $(INSTALL_DIR) $(STAGING_DIR_IMAGE)
+   $(CP) $(PKG_BUILD_DIR)/$(UBOOT_IMAGE) 
$(STAGING_DIR_IMAGE)/$(BUILD_DEVICES)-u-boot.bin
+endef
+
+define Package/u-boot/install/default
+endef
+
+$(eval $(call BuildPackage/U-Boot))

-- 
2.44.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v2 4/4] bmips: Build U-Boot into the XG6846 target

2024-04-25 Thread Linus Walleij

It appears that the CFE boot loader found in the XG6846
cannot load kernels over a certain size, and the old
relocate hack is not working.

What to do? We can build a small U-Boot into the image,
make CFE boot that, place the kernel immediately after
U-Boot, and use U-Boot to boot the system instead.

The compiled u-boot.bin becomes around ~300KB and with
LZMA compression it will swiftly fit into 128KB, so
we use two 64KB erase blocks right after the CFE to
store an imagetag:ed U-Boot.

Signed-off-by: Linus Walleij 
---
 target/linux/bmips/dts/bcm6328-inteno-xg6846.dts |   3 ++-
 target/linux/bmips/image/Makefile|  31 +++
 target/linux/bmips/image/bcm6328.mk  |   2 +-
 target/linux/bmips/image/null-initrd |   1 +
 target/linux/bmips/image/u-boot.bin  | Bin 0 -> 289149 bytes
 5 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/target/linux/bmips/dts/bcm6328-inteno-xg6846.dts 
b/target/linux/bmips/dts/bcm6328-inteno-xg6846.dts
index ee9d19839ccd..72f85a53ca7c 100644
--- a/target/linux/bmips/dts/bcm6328-inteno-xg6846.dts
+++ b/target/linux/bmips/dts/bcm6328-inteno-xg6846.dts
@@ -117,9 +117,10 @@
};
 
partition@1 {
-   compatible = "brcm,bcm963xx-imagetag";
+   compatible = "openwrt,uimage", "denx,uimage";
reg = <0x01 0xfe>;
label = "firmware";
+   openwrt,offset = <0x3>;
};
 
partition@ff {
diff --git a/target/linux/bmips/image/Makefile 
b/target/linux/bmips/image/Makefile
index 9311e2df096f..b79974931d48 100644
--- a/target/linux/bmips/image/Makefile
+++ b/target/linux/bmips/image/Makefile
@@ -4,6 +4,7 @@ include $(TOPDIR)/rules.mk
 include $(INCLUDE_DIR)/image.mk
 
 KERNEL_LOADADDR := 0x8001  # RAM start + 64K
+UBOOT_ENTRY := 0x81c0
 LOADER_ENTRY := 0x8100 # RAM start + 16M, for relocate
 LZMA_TEXT_START := 0x8200  # RAM start + 32M
 
@@ -94,6 +95,21 @@ define Build/cfe-bin
$(CFE_EXTRAS) $(1)
 endef
 
+# Build a CFE image with just U-Boot
+define Build/cfe-bin-uboot
+   cp $(STAGING_DIR_IMAGE)/$(DEVICE_NAME)-u-boot.bin $@
+   $(call Build/lzma)
+   mv $@ $@.uboot.lzma
+   echo "dummy" > $@.dummyfs
+   $(STAGING_DIR_HOST)/bin/imagetag -i $@.uboot.lzma -f $@.dummyfs \
+   --output $@ --boardid $(CFE_BOARD_ID) --chipid $(CHIP_ID) \
+   --entry $(UBOOT_ENTRY) --load-addr $(UBOOT_ENTRY) \
+   --info1 "$(call ModelNameLimit16,$(DEVICE_NAME))" \
+   $(CFE_EXTRAS) $(1)
+   rm $@.uboot.lzma
+   rm $@.dummyfs
+endef
+
 define Build/cfe-jffs2
$(STAGING_DIR_HOST)/bin/mkfs.jffs2 \
--big-endian \
@@ -284,6 +300,21 @@ define Device/bcm63xx-cfe-legacy
   KERNEL := kernel-bin | append-dtb | relocate-kernel | lzma-cfe
 endef
 
+# CFE images with U-Boot in front of the kernel, these will execute
+# U-Boot instead of the kernel and U-Boot will then proceed to load
+# the kernel. The reason to do this is that CFE is sometimes unable to
+# load big kernels even with the lzma loader tricks.
+define Device/bcm63xx-cfe-uboot
+  $(Device/bcm63xx-cfe)
+  KERNEL := kernel-bin | append-dtb | lzma | uImage lzma
+  IMAGE/cfe.bin := cfe-bin-uboot | pad-to (($$(BLOCKSIZE))) | \
+append-kernel | pad-to (($$(BLOCKSIZE))) | \
+append-rootfs (if (FLASH_MB),--pad (shell expr (FLASH_MB) 
/ 2))
+  IMAGE/sysupgrade.bin := cfe-bin-uboot | pad-to (($$(BLOCKSIZE))) | \
+append-kernel | pad-to (($$(BLOCKSIZE))) | \
+append-rootfs | append-metadata
+endef
+
 # CFE expects a single JFFS2 partition with cferam and kernel. However,
 # it's possible to fool CFE into properly loading both cferam and kernel
 # from two different JFFS2 partitions by adding dummy files (see
diff --git a/target/linux/bmips/image/bcm6328.mk 
b/target/linux/bmips/image/bcm6328.mk
index 0e249fa96e45..b85b6ac7a88f 100644
--- a/target/linux/bmips/image/bcm6328.mk
+++ b/target/linux/bmips/image/bcm6328.mk
@@ -52,7 +52,7 @@ endef
 TARGET_DEVICES += innacomm_w3400v6
 
 define Device/inteno_xg6846
-  $(Device/bcm63xx-cfe-legacy)
+  $(Device/bcm63xx-cfe-uboot)
   DEVICE_VENDOR := Inteno
   DEVICE_MODEL := XG6846
   CHIP_ID := 6328
diff --git a/target/linux/bmips/image/null-initrd 
b/target/linux/bmips/image/null-initrd
new file mode 100644
index ..421376db9e8a
--- /dev/null
+++ b/target/linux/bmips/image/null-initrd
@@ -0,0 +1 @@
+dummy
diff --git a/target/linux/bmips/image/u-boot.bin 
b/target/linux/bmips/image/u-boot.bin
new file mode 100644
index ..2d74a169da6e
Binar

[PATCH v2 1/4] bmips: bcm6328: Compile in uImage splitter

2024-04-25 Thread Linus Walleij

Since we split the Inteno XG6846 "firmware" partition with the
uImage MTD splitter, we need to compile in support for this
splitting method into the BCM6328.

Signed-off-by: Linus Walleij 
---
 target/linux/bmips/bcm6328/config-6.1 | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/linux/bmips/bcm6328/config-6.1 
b/target/linux/bmips/bcm6328/config-6.1
index 5b33e932360f..de7784e80ab1 100644
--- a/target/linux/bmips/bcm6328/config-6.1
+++ b/target/linux/bmips/bcm6328/config-6.1
@@ -170,6 +170,7 @@ CONFIG_MTD_RAW_NAND=y
 CONFIG_MTD_SPI_NOR=y
 CONFIG_MTD_SPLIT_BCM63XX_FW=y
 CONFIG_MTD_SPLIT_BCM_WFI_FW=y
+CONFIG_MTD_SPLIT_UIMAGE_FW=y
 CONFIG_MTD_UBI=y
 CONFIG_MTD_UBI_BEB_LIMIT=20
 CONFIG_MTD_UBI_BLOCK=y

-- 
2.44.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v2 2/4] bmips: Add Inteno XG6846 target

2024-04-25 Thread Linus Walleij

This add a device tree and build options for the XG6846
switch/router to the BMIPS target.

Hardware:
 - SoC: Broadcom BCM6328
 - CPU: BMIPS4350 V7.5
 - RAM: 64 MB DDR
 - NOR Flash: 16 MB parallel (CFE and OS)
 - Ethernet LAN: 4x 1Gbit
 - Ethernet WAN: 2x 1Gbit, fiber and TP
 - Buttons: reset
 - LEDs: 7 or 8, power and USB LEDs are GPIO-based, the
   LAN LEDs are controlled by the Marvell DSA Switch.
 - USB: on some versions
 - UART: yes

The device ODM (original device manufacturer) is XAVi
http://www.xavi.com.tw/

It is possible to boot the initramfs version
openwrt-bmips-bcm6328-inteno_xg6846-initramfs.elf from
CFE by breaking the boot on the UART console and download
it from a TFTP server such as:
CFE> r 192.168.1.2:openwrt-bmips-bcm6328-inteno_xg6846-initramfs.elf

Installation to target flash is not possible using CFE because
the image becomes too big for the CFE version found in these
devices. A separate U-Boot two-stage solution exists for
actually booting the device.

This device is called a "managed ethernet switch" by the vendor
and "media converter" or "fiber modem" by some of the ISPs
using it: the main purpose is to convert fiber connections to
ethernet, most devices just act as switches bridging the
fiber SFP to ethernet TP.

The device has a Marvell MV88E6352 DSA switch managed by
a BCM6328 BMIPS SoC.

This port makes it possible to use the XG6846 to grab an IP
number from the fiber connection and use all four LAN
connections out, turning it into a proper router.

This support is based mostly on the observations by the people on
the forum thread "Help with Inteno XG6846" where users NPeca75,
mrhaav, systemcrash and csom helped out to reverse engineer the
device. Then I made it work on the BMIPS target, figured out
the two-level switch hierarchy and settings.

Link: https://forum.openwrt.org/t/help-with-inteno-xg6846/68276/14
Signed-off-by: Linus Walleij 
---
 .../bcm6328/base-files/etc/board.d/02_network  |   3 +
 target/linux/bmips/dts/bcm6328-inteno-xg6846.dts   | 312 +
 target/linux/bmips/image/bcm6328.mk|  14 +
 3 files changed, 329 insertions(+)

diff --git a/target/linux/bmips/bcm6328/base-files/etc/board.d/02_network 
b/target/linux/bmips/bcm6328/base-files/etc/board.d/02_network
index 104f20ef0e23..78c0794f2311 100644
--- a/target/linux/bmips/bcm6328/base-files/etc/board.d/02_network
+++ b/target/linux/bmips/bcm6328/base-files/etc/board.d/02_network
@@ -9,6 +9,9 @@ arcadyan,ar7516)
ucidef_set_bridge_device switch
ucidef_set_interfaces_lan_wan "lan1 lan2 lan3" "wan"
;;
+inteno,xg6846)
+   ucidef_set_interfaces_lan_wan "lan1 lan2 lan3 lan4" "wan ext1"
+   ;;
 comtrend,ar-5381u |\
 comtrend,ar-5387un |\
 innacomm,w3400v6 |\
diff --git a/target/linux/bmips/dts/bcm6328-inteno-xg6846.dts 
b/target/linux/bmips/dts/bcm6328-inteno-xg6846.dts
new file mode 100644
index ..ee9d19839ccd
--- /dev/null
+++ b/target/linux/bmips/dts/bcm6328-inteno-xg6846.dts
@@ -0,0 +1,312 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+
+/*
+ * Devicetree for the Inteno XG6846 router, mostly used as a
+ * media converter from fiber to twisted pair ethernet
+ * "fiber modem" in many households in Sweden. The Marvell
+ * switch has one of its ports connected to an SFP (Small Form
+ * Factor pluggable) optical fiber receiver, which is bridged
+ * to the twisted pair connector LAN1.
+ *
+ * This device tree is inspired by research from the OpenWrt
+ * and Sweclockers forums, including contributions from
+ * NPeca75, mrhaav and csom.
+ *
+ * Some devices have a USB type A host receptacle mounted,
+ * some do not.
+ */
+#include "bcm6328.dtsi"
+#include 
+#include 
+
+/ {
+   model = "Inteno XG6846";
+   compatible = "inteno,xg6846", "brcm,bcm6328";
+
+   /* OpenWrt-specific aliases */
+   aliases {
+   led-boot = _pwr_red;
+   led-failsafe = _pwr_red;
+   led-running = _pwr_green;
+   led-upgrade = _pwr_red;
+   led-usb = _usb_green;
+   };
+
+   chosen {
+   bootargs = "rootfstype=squashfs,jffs2 noinitrd 
console=ttyS0,115200";
+   stdout-path = "serial0:115200n8";
+   };
+
+   /*
+* This I2C port is connected to the SFP and reflects the EEPROM etc
+* inside the SFP module. If the module is not plugged in, consequently
+* nothing will be found on the bus.
+*/
+   i2c0: i2c-sfp {
+   compatible = "i2c-gpio";
+   sda-gpios = < 1 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+   scl-gpios = < 19 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
+   /* This I2C bus is used for the external CATV c

[PATCH v2 0/4] Base support for Inteno XG6846

2024-04-25 Thread Linus Walleij

These patches have been cooking for some time, let's
get them moving.

The idea is to merge this base so we have base support
for the target and then try to work out remaining issues
such as the LED handling.

To: 

Signed-off-by: Linus Walleij 
---
Changes in v2:
- Include U-Boot for BMIPS patch (2024.04)
- Separate patch to activate U-Boot with the target.
- Use a kmod for the Marvell switch to hold down the footprint
  of the generic BCM6328 support.
- Link to v1: 
http://lists.openwrt.org/pipermail/openwrt-devel/2023-August/041387.html

---
Linus Walleij (4):
  bmips: bcm6328: Compile in uImage splitter
  bmips: Add Inteno XG6846 target
  uboot-bmips: Add U-Boot for the BMIPS target
  bmips: Build U-Boot into the XG6846 target

 .github/labeler.yml|   1 +
 package/boot/uboot-bmips/Makefile  |  32 +++
 .../bcm6328/base-files/etc/board.d/02_network  |   3 +
 target/linux/bmips/bcm6328/config-6.1  |   1 +
 target/linux/bmips/dts/bcm6328-inteno-xg6846.dts   | 313 +
 target/linux/bmips/image/Makefile  |  31 ++
 target/linux/bmips/image/bcm6328.mk|  14 +
 target/linux/bmips/image/null-initrd   |   1 +
 target/linux/bmips/image/u-boot.bin| Bin 0 -> 289149 bytes
 9 files changed, 396 insertions(+)
---
base-commit: 84a48ce400b2c7b0779f51e83c68de5f8ec58ffd
change-id: 20240425-xg6846-base-9853a92b11f7

Best regards,
-- 
Linus Walleij 


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] kirkwood: Add Marvell RTC to all machines with nothing else

2024-02-22 Thread Linus Walleij

The Kirkwood SoCs all have an onchip RTC that can hold the time
over e.g. a reboot which will help if no NTP servers are available.

Create a kernel module package for the Marvell RTC, and add it to
all Kirkwood devices that do not have their own discrete
battery-backed RTC. Adding it to platforms with a proper RTC
is just surplus.

All Kirkwoods have at least one RTC so add RTC to the features
list for Kirkwood as well.

Signed-off-by: Linus Walleij 
---
 package/kernel/linux/modules/other.mk | 17 +
 target/linux/kirkwood/Makefile|  2 +-
 target/linux/kirkwood/image/Makefile  | 30 +-
 3 files changed, 35 insertions(+), 14 deletions(-)

diff --git a/package/kernel/linux/modules/other.mk 
b/package/kernel/linux/modules/other.mk
index 4a061974c333..e227fd6a0f98 100644
--- a/package/kernel/linux/modules/other.mk
+++ b/package/kernel/linux/modules/other.mk
@@ -578,6 +578,23 @@ endef
 $(eval $(call KernelPackage,rtc-isl1208))
 
 
+define KernelPackage/rtc-mv
+  SUBMENU:=$(OTHER_MENU)
+  TITLE:=Marvell SoC RTC support
+  DEFAULT:=m if ALL_KMODS && RTC_SUPPORT
+  KCONFIG:=CONFIG_RTC_DRV_MV \
+   CONFIG_RTC_CLASS=y
+  FILES:=$(LINUX_DIR)/drivers/rtc/rtc-mv.ko
+  AUTOLOAD:=$(call AutoProbe,rtc-mv)
+endef
+
+define KernelPackage/rtc-mv/description
+ Kernel module for Marvell SoC RTC.
+endef
+
+$(eval $(call KernelPackage,rtc-mv))
+
+
 define KernelPackage/rtc-pcf8563
   SUBMENU:=$(OTHER_MENU)
   TITLE:=Philips PCF8563/Epson RTC8564 RTC support
diff --git a/target/linux/kirkwood/Makefile b/target/linux/kirkwood/Makefile
index 54f26281a497..424e699157bf 100644
--- a/target/linux/kirkwood/Makefile
+++ b/target/linux/kirkwood/Makefile
@@ -7,7 +7,7 @@ include $(TOPDIR)/rules.mk
 ARCH:=arm
 BOARD:=kirkwood
 BOARDNAME:=Marvell Kirkwood
-FEATURES:=usb nand squashfs ramdisk
+FEATURES:=rtc usb nand squashfs ramdisk
 CPU_TYPE:=xscale
 SUBTARGETS:=generic
 
diff --git a/target/linux/kirkwood/image/Makefile 
b/target/linux/kirkwood/image/Makefile
index 0fa14b89f32c..49d0124f43a0 100644
--- a/target/linux/kirkwood/image/Makefile
+++ b/target/linux/kirkwood/image/Makefile
@@ -105,7 +105,7 @@ define Device/cisco_on100
   KERNEL_IN_UBI :=
   UBINIZE_OPTS := -E 5
   IMAGE/factory.bin := append-kernel | pad-to (KERNEL_SIZE) | append-ubi
-  DEVICE_PACKAGES := kmod-mvsdio
+  DEVICE_PACKAGES := kmod-mvsdio kmod-rtc-mv
   SUPPORTED_DEVICES += on100
 endef
 TARGET_DEVICES += cisco_on100
@@ -114,6 +114,7 @@ define Device/cloudengines_pogoe02
   DEVICE_VENDOR := Cloud Engines
   DEVICE_MODEL := Pogoplug E02
   DEVICE_DTS := kirkwood-pogo_e02
+  DEVICE_PACKAGES := kmod-rtc-mv
   SUPPORTED_DEVICES += pogo_e02
 endef
 TARGET_DEVICES += cloudengines_pogoe02
@@ -123,7 +124,7 @@ define Device/cloudengines_pogoplugv4
   DEVICE_MODEL := Pogoplug V4
   DEVICE_DTS := kirkwood-pogoplug-series-4
   DEVICE_PACKAGES := kmod-ata-marvell-sata kmod-fs-ext4 kmod-mvsdio kmod-usb3 \
-   kmod-gpio-button-hotplug
+   kmod-gpio-button-hotplug kmod-rtc-mv
 endef
 TARGET_DEVICES += cloudengines_pogoplugv4
 
@@ -145,7 +146,7 @@ define Device/endian_4i-edge-200
   DEVICE_MODEL := 4i Edge 200
   DEVICE_ALT0_VENDOR := Endian
   DEVICE_ALT0_MODEL := UTM Mini Firewall
-  DEVICE_PACKAGES := kmod-ath9k kmod-mvsdio wpad-basic-mbedtls
+  DEVICE_PACKAGES := kmod-ath9k kmod-mvsdio wpad-basic-mbedtls kmod-rtc-mv
   KERNEL_SIZE := 4096k
   IMAGES := sysupgrade.bin
 endef
@@ -154,13 +155,14 @@ TARGET_DEVICES += endian_4i-edge-200
 define Device/globalscale_sheevaplug
   DEVICE_VENDOR := Globalscale
   DEVICE_MODEL := Sheevaplug
-  DEVICE_PACKAGES := kmod-mvsdio
+  DEVICE_PACKAGES := kmod-mvsdio kmod-rtc-mv
 endef
 TARGET_DEVICES += globalscale_sheevaplug
 
 define Device/iom_iconnect-1.1
   DEVICE_VENDOR := Iomega
   DEVICE_MODEL := Iconnect
+  DEVICE_PACKAGES := kmod-rtc-mv
   DEVICE_DTS := kirkwood-iconnect
   SUPPORTED_DEVICES += iconnect
 endef
@@ -171,7 +173,7 @@ define Device/iom_ix2-200
   DEVICE_MODEL := StorCenter ix2-200
   DEVICE_DTS := kirkwood-iomega_ix2_200
   DEVICE_PACKAGES := kmod-ata-marvell-sata kmod-fs-ext4 \
-   kmod-gpio-button-hotplug kmod-hwmon-lm63
+   kmod-gpio-button-hotplug kmod-hwmon-lm63 kmod-rtc-mv
   PAGESIZE := 512
   SUBPAGESIZE := 256
   BLOCKSIZE := 16k
@@ -189,7 +191,7 @@ define Device/iom_ix4-200d
   DEVICE_MODEL := StorCenter ix4-200d
   DEVICE_PACKAGES := kmod-ata-marvell-sata kmod-fs-ext4 \
kmod-gpio-button-hotplug kmod-gpio-nxp-74hc164 \
-   kmod-hwmon-adt7475 kmod-mvsdio kmod-spi-gpio
+   kmod-hwmon-adt7475 kmod-mvsdio kmod-spi-gpio kmod-rtc-mv
   PAGESIZE := 512
   SUBPAGESIZE := 256
   BLOCKSIZE := 16k
@@ -207,7 +209,7 @@ define Device/iptime_nas1
   DEVICE_MODEL := NAS1
   DEVICE_PACKAGES := kmod-ata-marvell-sata kmod-fs-ext4 \
kmod-gpio-button-hotplug kmod-gpio-pca953x kmod-hwmon-drivetemp \
-   kmod-hwmon-gpiofan kmod-usb-ledtrig-usbport -uboot-envtools
+   kmod-hwmon-gpiofan kmod-usb-ledtrig-usbport kmod-rtc-m

Re: [PATCH] modules: Add kernel module for MV88E6xxx DSA switch

2024-01-31 Thread Linus Walleij

On Wed, Jan 31, 2024 at 1:35 PM Paul D  wrote:

> Is this what we tested on 6846? Or this is what you've been cooking? :)
>
> I'm almost certain it's the latter.

Yeah I have it in my new patch set for the 6846, so we don't
have to unconditionally compile in the mv88e6xxx switch into all
bcm6328 kernels. (Those are footprint-sensitive.)

I updated the initramfs and sysupgrade images on my site especially
for you so you can test it :)

I try to trickle in the required patches a bit at the time.

Yours,
Linus Walleij

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] modules: Add kernel module for MV88E6xxx DSA switch

2024-01-30 Thread Linus Walleij

This adds a kernel module package for the Marvell
MV88E6XXX DSA switch and a separate module package for
the DSA tagger since it can in theory be used by multiple
DSA switches. Enable both DSA and EDSA tags in the
tagger.

We can't just compile this in because just a few devices
has this DSA, and it depends on e.g. the I2C and SFP
to be loaded as modules first.

We have no examples of DSA switches being packaged as
modules before, all seem to be compiled in, but it
actually works just fine to do this.

Signed-off-by: Linus Walleij 
---
 package/kernel/linux/modules/netdevices.mk | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/package/kernel/linux/modules/netdevices.mk 
b/package/kernel/linux/modules/netdevices.mk
index 63f75e959145..fb6d565a86af 100644
--- a/package/kernel/linux/modules/netdevices.mk
+++ b/package/kernel/linux/modules/netdevices.mk
@@ -390,6 +390,40 @@ endef
 
 $(eval $(call KernelPackage,phy-aquantia))
 
+define KernelPackage/dsa-tag-dsa
+  SUBMENU:=$(NETWORK_DEVICES_MENU)
+  TITLE:=Marvell DSA type DSA and EDSA taggers
+  KCONFIG:= CONFIG_NET_DSA_TAG_DSA_COMMON \
+   CONFIG_NET_DSA_TAG_DSA \
+   CONFIG_NET_DSA_TAG_EDSA \
+   CONFIG_NET_DSA=y
+  FILES:=$(LINUX_DIR)/net/dsa/tag_dsa.ko
+  AUTOLOAD:=$(call AutoLoad,40,tag_dsa,1)
+endef
+
+define KernelPackage/dsa-tag-dsa/description
+  Kernel modules for Marvell DSA and EDSA tagging
+endef
+
+$(eval $(call KernelPackage,dsa-tag-dsa))
+
+define KernelPackage/dsa-mv88e6xxx
+  SUBMENU:=$(NETWORK_DEVICES_MENU)
+  TITLE:=Marvell MV88E6XXX DSA Switch
+  DEPENDS:=+kmod-ptp +kmod-phy-marvell +kmod-dsa-tag-dsa
+  KCONFIG:=CONFIG_NET_DSA_MV88E6XXX \
+   CONFIG_NET_DSA_MV88E6XXX_PTP=y \
+   CONFIG_NET_DSA=y
+  FILES:=$(LINUX_DIR)/drivers/net/dsa/mv88e6xxx/mv88e6xxx.ko
+  AUTOLOAD:=$(call AutoLoad,41,mv88e6xxx,1)
+endef
+
+define KernelPackage/dsa-mv88e6xxx/description
+  Kernel modules for MV88E6XXX DSA switches
+endef
+
+$(eval $(call KernelPackage,dsa-mv88e6xxx))
+
 
 define KernelPackage/swconfig
   SUBMENU:=$(NETWORK_DEVICES_MENU)

---
base-commit: 3a073a021286bef3fed0ca7884872c5890420d60
change-id: 20240130-mv88e6xxx-dsa-modules-2ba74a4cf70a

Best regards,
-- 
Linus Walleij 


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] mtdsplit_uimage: Split also after offsetted uImage

2024-01-28 Thread Linus Walleij

On Fri, Jan 26, 2024 at 9:56 AM INAGAKI Hiroshi
 wrote:

> This is just a question: doesn't it work with "openwrt,offset"
> property of mtdsplit_uimage parser instead of modifying that parser?

It works actually...
The U-Boot takes up 3 64k erase blocks so if I just set offset to
0x3 it works like a charm.

I first thought that maybe it's not as flexible (for example if U-Boot
becomes bigger and pass a 64K boundary) but it doesn't really
affect this system as I control this pretty tightly anyway.

Thanks, I'll drop this patch!

Yours,
Linus Walleij

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] mtdsplit_uimage: Split also after offsetted uImage

2024-01-25 Thread Linus Walleij

On Fri, Jan 26, 2024 at 12:21 AM Paul D  wrote:

> BTW: was this what I tested in your factory and sysimages for the XG6846?
>
> If so can you roll a fresh one with this patch?

It has been used in all of them, but I made a new one on top
of the OpenWrt main branch!
https://dflund.se/~triad/krad/inteno-xg6846/

> > The reason why this is needed is because on the
> > BCM6328-based Inteno XG6846 we need to put a small
> > U-Boot binary first in the partition, then the uImage,
> > then the rootfs.
>
> Suggest rewording to:
>
> This is necessary because the BCM6328-based Inteno XG6846 won't boot an
> image without a small U-Boot binary first in the partition followed by
> the uImage, then the rootfs.

OK changed it.

Yours,
Linus Walleij

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH v7] bmips: bcm6368-enetsw: Bump max MTU

2024-01-25 Thread Linus Walleij

On Wed, Jan 24, 2024 at 8:32 PM Álvaro Fernández Rojas
 wrote:

> I tested this:
> - Comtrend AR-5381u (bcm6328 with internal switch only).
> - Netgear DGND3700v2 (bcm6362 with external BCM53125 switch).
> And there were no regressions on any of them.
>
> So I merged it @ 3cf1fe5508ee8a2a2c6e33a829bfb6c81381ccd0
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=3cf1fe5508ee8a2a2c6e33a829bfb6c81381ccd0
> https://github.com/openwrt/openwrt/commit/3cf1fe5508ee8a2a2c6e33a829bfb6c81381ccd0

Thanks Álvaro!

Yours,
Linus Walleij

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v7] bmips: bcm6368-enetsw: Bump max MTU

2024-01-24 Thread Linus Walleij

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 
Tested-by: Paul Donald 
Signed-off-by: Linus Walleij 
---
ChangeLog v6->v7:
- Rebase on master.
- Perhaps we can merge this now?
ChangeLog v5->v6:
- Rewrite thoroughly after discussing with Jonas that the safe
  MTU is probably 1532 without DSA tag and extra VLAN header.
- Reword comm

[PATCH] mtdsplit_uimage: Split also after offsetted uImage

2024-01-23 Thread Linus Walleij

The uImage splitter recognizes a rootfs either:

1. Right after the uImage if it comes first in the
   partition or
2. Before the uImage if it is located at an offset
   inside the partition.

Add a third case:

3. After the uImage also at an offset inside the
   partition, if and only if 1 and 2 fails.

The reason why this is needed is because on the
BCM6328-based Inteno XG6846 we need to put a small
U-Boot binary first in the partition, then the uImage,
then the rootfs.

The U-Boot binary that comes first cannot be split off
into its own partition in this case because it needs
to be part of the bigger "firmware" partition. Which
we use for installation and upgrades.

Signed-off-by: Linus Walleij 
---
 .../files/drivers/mtd/mtdsplit/mtdsplit_uimage.c  | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_uimage.c 
b/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_uimage.c
index a3e55fb1fe38..de043fb9f702 100644
--- a/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_uimage.c
+++ b/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_uimage.c
@@ -217,11 +217,22 @@ static int __mtdsplit_parse_uimage(struct mtd_info 
*master,
if (ret) {
pr_debug("no rootfs before uImage in \"%s\"\n",
 master->name);
-   goto err_free_buf;
-   }
 
-   rootfs_offset = 0;
-   rootfs_size = uimage_offset;
+   /* Try after the uImage */
+   ret = mtd_find_rootfs_from(master, uimage_offset + 
uimage_size,
+  master->size, 
_offset, );
+   if (ret) {
+   pr_debug("no rootfs after uImage either in 
\"%s\"\n",
+master->name);
+   goto err_free_buf;
+   }
+
+   rootfs_size = master->size - rootfs_offset;
+   uimage_size = rootfs_offset - uimage_offset;
+   } else {
+   rootfs_offset = 0;
+   rootfs_size = uimage_offset;
+   }
}
 
if (rootfs_size == 0) {

---
base-commit: 1b7e62b20b1735fcdc498a35e005afcd775abcf4
change-id: 20240123-offsetted-uimage-splitter-f5b65f0df2ed

Best regards,
-- 
Linus Walleij 


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v2] gemini: Backport upstream TSO disable patch

2024-01-23 Thread Linus Walleij

This patch is needed for ethernet to work on most Gemini
devices so backport it.

Signed-off-by: Linus Walleij 
---
Changes in v2:
- Also send the patch to openwrt-devel :/
- Link to v1: 
https://lore.kernel.org/r/20240123-gemini-ethernet-fix-v1-1-0bbe0b272...@linaro.org
---
 ...6.8-net-ethernet-cortina-Drop-TSO-support.patch | 78 ++
 1 file changed, 78 insertions(+)

diff --git 
a/target/linux/gemini/patches-6.1/0030-v6.8-net-ethernet-cortina-Drop-TSO-support.patch
 
b/target/linux/gemini/patches-6.1/0030-v6.8-net-ethernet-cortina-Drop-TSO-support.patch
new file mode 100644
index ..41364804f845
--- /dev/null
+++ 
b/target/linux/gemini/patches-6.1/0030-v6.8-net-ethernet-cortina-Drop-TSO-support.patch
@@ -0,0 +1,78 @@
+From ac631873c9e7a50d2a8de457cfc4b9f8403e Mon Sep 17 00:00:00 2001
+From: Linus Walleij 
+Date: Sat, 6 Jan 2024 01:12:22 +0100
+Subject: [PATCH] net: ethernet: cortina: Drop TSO support
+
+The recent change to allow large frames without hardware checksumming
+slotted in software checksumming in the driver if hardware could not
+do it.
+
+This will however upset TSO (TCP Segment Offloading). Typical
+error dumps includes this:
+
+skb len=2961 headroom=222 headlen=66 tailroom=0
+(...)
+WARNING: CPU: 0 PID: 956 at net/core/dev.c:3259 skb_warn_bad_offload+0x7c/0x108
+gemini-ethernet-port: caps=(0x01154813, 0x2007ffdd7889)
+
+And the packets do not go through.
+
+The TSO implementation is bogus: a TSO enabled driver must propagate
+the skb_shinfo(skb)->gso_size value to the TSO engine on the NIC.
+
+Drop the size check and TSO offloading features for now: this
+needs to be fixed up properly.
+
+After this ethernet works fine on Gemini devices with a direct connected
+PHY such as D-Link DNS-313.
+
+Also tested to still be working with a DSA switch using the Gemini
+ethernet as conduit interface.
+
+Link: 
https://lore.kernel.org/netdev/cann89ijlfxng1syl5zk0mknxpyyqpcp83m3kgd2kj2_hkcp...@mail.gmail.com/
+Suggested-by: Eric Dumazet 
+Fixes: d4d0c5b4d279 ("net: ethernet: cortina: Handle large frames")
+Signed-off-by: Linus Walleij 
+Reviewed-by: Eric Dumazet 
+Signed-off-by: David S. Miller 
+---
+ drivers/net/ethernet/cortina/gemini.c | 15 ++-
+ 1 file changed, 2 insertions(+), 13 deletions(-)
+
+--- a/drivers/net/ethernet/cortina/gemini.c
 b/drivers/net/ethernet/cortina/gemini.c
+@@ -79,8 +79,7 @@ MODULE_PARM_DESC(debug, "Debug level (0=
+ #define GMAC0_IRQ4_8 (GMAC0_MIB_INT_BIT | GMAC0_RX_OVERRUN_INT_BIT)
+ 
+ #define GMAC_OFFLOAD_FEATURES (NETIF_F_SG | NETIF_F_IP_CSUM | \
+-  NETIF_F_IPV6_CSUM | NETIF_F_RXCSUM | \
+-  NETIF_F_TSO | NETIF_F_TSO_ECN | NETIF_F_TSO6)
++ NETIF_F_IPV6_CSUM | NETIF_F_RXCSUM)
+ 
+ /**
+  * struct gmac_queue_page - page buffer per-page info
+@@ -1143,23 +1142,13 @@ static int gmac_map_tx_bufs(struct net_d
+   struct gmac_txdesc *txd;
+   skb_frag_t *skb_frag;
+   dma_addr_t mapping;
+-  unsigned short mtu;
+   void *buffer;
+   int ret;
+ 
+-  mtu  = ETH_HLEN;
+-  mtu += netdev->mtu;
+-  if (skb->protocol == htons(ETH_P_8021Q))
+-  mtu += VLAN_HLEN;
+-
++  /* TODO: implement proper TSO using MTU in word3 */
+   word1 = skb->len;
+   word3 = SOF_BIT;
+ 
+-  if (word1 > mtu) {
+-  word1 |= TSS_MTU_ENABLE_BIT;
+-  word3 |= mtu;
+-  }
+-
+   if (skb->len >= ETH_FRAME_LEN) {
+   /* Hardware offloaded checksumming isn't working on frames
+* bigger than 1514 bytes. A hypothesis about this is that the

---
base-commit: 65fb97b4507bcff3f98739975e9cc7df53137b12
change-id: 20240123-gemini-ethernet-fix-d161681eeb45

Best regards,
-- 
Linus Walleij 


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] boot: Bump the BCM53xx U-Boot to 2024.01

2024-01-19 Thread Linus Walleij

Bump the U-Boot version used for BCM53xx to the 2024.01
version that includes all the needed patches upstream, so we
can get rid of those in the process.

Signed-off-by: Linus Walleij 
---
 package/boot/uboot-bcm53xx/Makefile|   4 +-
 .../0001-nand-brcmnand-add-iproc-support.patch | 199 ---
 ...nand-nand_base-Handle-algorithm-selection.patch |  80 ---
 ...Import-device-tree-for-Broadcom-Northstar.patch | 659 -
 ...d-support-for-the-Broadcom-Northstar-SoCs.patch |  66 ---
 ...05-board-Add-new-Broadcom-Northstar-board.patch | 372 
 6 files changed, 2 insertions(+), 1378 deletions(-)

diff --git a/package/boot/uboot-bcm53xx/Makefile 
b/package/boot/uboot-bcm53xx/Makefile
index ab80b9608adc..f1c026e25b34 100644
--- a/package/boot/uboot-bcm53xx/Makefile
+++ b/package/boot/uboot-bcm53xx/Makefile
@@ -1,7 +1,7 @@
 include $(TOPDIR)/rules.mk
 
-PKG_VERSION:=2023.04
-PKG_HASH:=e31cac91545ff41b71cec5d8c22afd695645cd6e2a442ccdacacd60534069341
+PKG_VERSION:=2024.01
+PKG_HASH:=b99611f1ed237bf3541bdc8434b68c96a6e05967061f992443cb30aabebef5b3
 PKG_RELEASE:=$(AUTORELEASE)
 
 include $(INCLUDE_DIR)/u-boot.mk
diff --git 
a/package/boot/uboot-bcm53xx/patches/0001-nand-brcmnand-add-iproc-support.patch 
b/package/boot/uboot-bcm53xx/patches/0001-nand-brcmnand-add-iproc-support.patch
deleted file mode 100644
index fe6f4d944afe..
--- 
a/package/boot/uboot-bcm53xx/patches/0001-nand-brcmnand-add-iproc-support.patch
+++ /dev/null
@@ -1,199 +0,0 @@
-From 854dc4b790ce1291326d52b8405ebe771bff2edd Mon Sep 17 00:00:00 2001
-From: Linus Walleij 
-Date: Wed, 8 Mar 2023 22:42:31 +0100
-Subject: [PATCH 1/5] nand: brcmnand: add iproc support
-
-Add support for the iproc Broadcom NAND controller,
-used in Northstar SoCs for example. Based on the Linux
-driver.
-
-Cc: Philippe Reynes 
-Cc: Dario Binacchi 
-Reviewed-by: Michael Trimarchi 
-Signed-off-by: Linus Walleij 
-Acked-by: William Zhang 
-Link: 
https://lore.kernel.org/all/20230308214231.378013-1-linus.wall...@linaro.org/
-Signed-off-by: Dario Binacchi 

- drivers/mtd/nand/raw/Kconfig   |   7 +
- drivers/mtd/nand/raw/brcmnand/Makefile |   1 +
- drivers/mtd/nand/raw/brcmnand/iproc_nand.c | 148 +
- 3 files changed, 156 insertions(+)
- create mode 100644 drivers/mtd/nand/raw/brcmnand/iproc_nand.c
-
 a/drivers/mtd/nand/raw/Kconfig
-+++ b/drivers/mtd/nand/raw/Kconfig
-@@ -156,6 +156,13 @@ config NAND_BRCMNAND_63158
-help
-  Enable support for broadcom nand driver on bcm63158.
- 
-+config NAND_BRCMNAND_IPROC
-+   bool "Support Broadcom NAND controller on the iproc family"
-+   depends on NAND_BRCMNAND
-+   help
-+ Enable support for broadcom nand driver on the Broadcom
-+ iproc family such as Northstar (BCM5301x, BCM4708...)
-+
- config NAND_DAVINCI
-   bool "Support TI Davinci NAND controller"
-   select SYS_NAND_SELF_INIT if TARGET_DA850EVM
 a/drivers/mtd/nand/raw/brcmnand/Makefile
-+++ b/drivers/mtd/nand/raw/brcmnand/Makefile
-@@ -6,5 +6,6 @@ obj-$(CONFIG_NAND_BRCMNAND_6753) += bcm6
- obj-$(CONFIG_NAND_BRCMNAND_68360) += bcm68360_nand.o
- obj-$(CONFIG_NAND_BRCMNAND_6838) += bcm6838_nand.o
- obj-$(CONFIG_NAND_BRCMNAND_6858) += bcm6858_nand.o
-+obj-$(CONFIG_NAND_BRCMNAND_IPROC) += iproc_nand.o
- obj-$(CONFIG_NAND_BRCMNAND) += brcmnand.o
- obj-$(CONFIG_NAND_BRCMNAND) += brcmnand_compat.o
 /dev/null
-+++ b/drivers/mtd/nand/raw/brcmnand/iproc_nand.c
-@@ -0,0 +1,148 @@
-+// SPDX-License-Identifier: GPL-2.0
-+/*
-+ * Code borrowed from the Linux driver
-+ * Copyright (C) 2015 Broadcom Corporation
-+ */
-+
-+#include 
-+#include 
-+#include 
-+#include 
-+#include 
-+#include 
-+#include 
-+#include 
-+#include 
-+#include 
-+
-+#include "brcmnand.h"
-+
-+struct iproc_nand_soc {
-+  struct brcmnand_soc soc;
-+  void __iomem *idm_base;
-+  void __iomem *ext_base;
-+};
-+
-+#define IPROC_NAND_CTLR_READY_OFFSET  0x10
-+#define IPROC_NAND_CTLR_READY BIT(0)
-+
-+#define IPROC_NAND_IO_CTRL_OFFSET 0x00
-+#define IPROC_NAND_APB_LE_MODEBIT(24)
-+#define IPROC_NAND_INT_CTRL_READ_ENABLE   BIT(6)
-+
-+static bool iproc_nand_intc_ack(struct brcmnand_soc *soc)
-+{
-+  struct iproc_nand_soc *priv =
-+  container_of(soc, struct iproc_nand_soc, soc);
-+  void __iomem *mmio = priv->ext_base + IPROC_NAND_CTLR_READY_OFFSET;
-+  u32 val = brcmnand_readl(mmio);
-+
-+  if (val & IPROC_NAND_CTLR_READY) {
-+  brcmnand_writel(IPROC_NAND_CTLR_READY, mmio);
-+  return true;
-+  }
-+
-+  return false;
-+}
-+
-+static void iproc_nand_intc_set(struct brcmnand_soc *soc, bool en)
-+{
-+  struct iproc_nand_soc *priv =
-+  container_of(soc, struct iproc_nand_soc, soc);
-+  void __iomem *mmio = priv->idm_base + IPROC_NAND_IO_CTRL_OFFSET;
-+  u32 val = brcmnand_readl(mmio)

Re: [PATCH 1/2] kernel: usb: Autoprobe g_serial

2023-11-24 Thread Linus Walleij

On Sun, Nov 19, 2023 at 2:27 PM Chuanhong Guo  wrote:
> On Sun, Nov 12, 2023 at 6:04 AM Linus Walleij  
> wrote:
> >
> > For devices using USB gadget serial we need to probe the modules
> > usb_f_acm and g_serial in order, then the available UDC (USB device
> > controller) interface will be hooked up to a serial port as
> > /dev/ttyGS0. (On the host side this appears as /dev/ttyACM0
> > when plugging in the USB cable.)
> >
> > I don't quite understand why this wasn't done before for the
> > module explicitly called kmod-usb-serial.
>
> The g_*.ko gadget modules conflict with each other. I think
> it isn't loaded by default to prevent that when users decided
> to install multiple of them.
>
> I made an init script to setup USB gadget using the "modern"
> configfs approach:
> https://github.com/openwrt/openwrt/pull/14005
> Maybe you can make use of this one instead? :)

This is a step in the right direction as it moves toward using configfs
as is custom these days, approved.

I think I would need an example of how to utilize this for the serial
gadget though...

Yours,
Linus Walleij

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 1/2] kernel: usb: Autoprobe g_serial

2023-11-11 Thread Linus Walleij

For devices using USB gadget serial we need to probe the modules
usb_f_acm and g_serial in order, then the available UDC (USB device
controller) interface will be hooked up to a serial port as
/dev/ttyGS0. (On the host side this appears as /dev/ttyACM0
when plugging in the USB cable.)

I don't quite understand why this wasn't done before for the
module explicitly called kmod-usb-serial.

Before this patch we have to enter a console and type

  modprobe g_serial

To get a serial console on /dev/ttyGS0, after this it is
automatic.

Since you might only have the serial console, it is a bit
catch 22 to have to use a serial console to activate the
serial console.

Signed-off-by: Linus Walleij 
---
 package/kernel/linux/modules/usb.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/kernel/linux/modules/usb.mk 
b/package/kernel/linux/modules/usb.mk
index 0a5f5a8993c9..f54dc4380737 100644
--- a/package/kernel/linux/modules/usb.mk
+++ b/package/kernel/linux/modules/usb.mk
@@ -207,7 +207,7 @@ define KernelPackage/usb-gadget-serial
$(LINUX_DIR)/drivers/usb/gadget/function/usb_f_obex.ko \
$(LINUX_DIR)/drivers/usb/gadget/function/usb_f_serial.ko \
$(LINUX_DIR)/drivers/usb/gadget/legacy/g_serial.ko
-  AUTOLOAD:=$(call AutoLoad,52,usb_f_acm)
+  AUTOLOAD:=$(call AutoLoad,52,usb_f_acm g_serial)
   $(call AddDepends/usb)
 endef
 

-- 
2.34.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 2/2] gemini: Activate serial USB console on the DNS-313

2023-11-11 Thread Linus Walleij

This brings up a serial console on the USB device port of
the DNS-313.

Signed-off-by: Linus Walleij 
---
 target/linux/gemini/Makefile   | 2 +-
 target/linux/gemini/base-files/etc/inittab | 4 
 target/linux/gemini/image/Makefile | 2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/target/linux/gemini/Makefile b/target/linux/gemini/Makefile
index b7f1962c9a59..238d8c4f0c4d 100644
--- a/target/linux/gemini/Makefile
+++ b/target/linux/gemini/Makefile
@@ -7,7 +7,7 @@ include $(TOPDIR)/rules.mk
 ARCH:=arm
 BOARD:=gemini
 BOARDNAME:=Cortina Systems CS351x
-FEATURES:=squashfs pci rtc usb dt gpio display ext4 rootfs-part boot-part
+FEATURES:=squashfs pci rtc usb usbgadget dt gpio display ext4 rootfs-part 
boot-part
 CPU_TYPE:=fa526
 SUBTARGETS:=generic
 
diff --git a/target/linux/gemini/base-files/etc/inittab 
b/target/linux/gemini/base-files/etc/inittab
new file mode 100644
index ..253036402d83
--- /dev/null
+++ b/target/linux/gemini/base-files/etc/inittab
@@ -0,0 +1,4 @@
+::sysinit:/etc/init.d/rcS S boot
+::shutdown:/etc/init.d/rcS K shutdown
+::askconsole:/usr/libexec/login.sh
+ttyGS0::askfirst:/usr/libexec/login.sh
diff --git a/target/linux/gemini/image/Makefile 
b/target/linux/gemini/image/Makefile
index 3fce3172ed63..6a0397e0503f 100644
--- a/target/linux/gemini/image/Makefile
+++ b/target/linux/gemini/image/Makefile
@@ -168,7 +168,7 @@ define Device/dlink_dns-313
DEVICE_VENDOR := D-Link
DEVICE_MODEL := DNS-313 1-Bay Network Storage Enclosure
DEVICE_DTS := gemini-dlink-dns-313
-   DEVICE_PACKAGES := $(GEMINI_NAS_PACKAGES)
+   DEVICE_PACKAGES := $(GEMINI_NAS_PACKAGES) kmod-usb-gadget 
kmod-usb-gadget-serial
BLOCKSIZE := 1k
FILESYSTEMS := ext4
IMAGES := factory.bin.gz

-- 
2.34.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 0/2] Enable USB serial console on the D-Link DNS-313

2023-11-11 Thread Linus Walleij

This patch set makes it possible to plug in a USB cable
into the device USB B receptacle on the DNS-313 and
it will appear as /dev/ttyACM0 on the host and there will
be a serial console on it, at 115200 baud.

This is useful for users who don't like to solder in
their device to get a serial console.

The custom inittab is a bit ugly, but I've seen that this
seems to be what other devices do, other ideas welcome.

Signed-off-by: Linus Walleij 
---
Linus Walleij (2):
  kernel: usb: Autoprobe g_serial
  gemini: Activate serial USB console on the DNS-313

 package/kernel/linux/modules/usb.mk| 2 +-
 target/linux/gemini/Makefile   | 2 +-
 target/linux/gemini/base-files/etc/inittab | 4 
 target/linux/gemini/image/Makefile | 2 +-
 4 files changed, 7 insertions(+), 3 deletions(-)
---
base-commit: b7cf706539eb3a788441c8a8debaa8c36e5c54cf
change-id: 2023-dns313-usb-serial-b9ac47e3a27e

Best regards,
-- 
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

2023-10-25 Thread Linus Walleij

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

[PATCH v4 7/7] ixp4xx: Add USRobotics USR8200 support

2023-10-23 Thread Linus Walleij

This brings back USRobotics USR8200 support to the IXP4xx
target.

Signed-off-by: Linus Walleij 
---
 .../linux/ixp4xx/base-files/etc/board.d/02_network |   5 +
 target/linux/ixp4xx/config-6.1 |   1 +
 target/linux/ixp4xx/image/Makefile |  13 ++
 ...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 ++
 8 files changed, 650 insertions(+)

diff --git a/target/linux/ixp4xx/base-files/etc/board.d/02_network 
b/target/linux/ixp4xx/base-files/etc/board.d/02_network
index 45d7cbc75a4a..864328d6bcf1 100644
--- a/target/linux/ixp4xx/base-files/etc/board.d/02_network
+++ b/target/linux/ixp4xx/base-files/etc/board.d/02_network
@@ -11,6 +11,11 @@ gateworks,gw2358)
 linksys,nslu2)
ucidef_set_interface_lan "eth0" "dhcp"
;;
+usr,usr8200)
+   # LAN ports connected to eth1 thru the MV88E6060 DSA switch
+   ucidef_set_interface "eth" device "eth1" protocol "none"
+   ucidef_set_interfaces_lan_wan "lan1 lan2 lan3 lan4" "eth0"
+   ;;
 *)
ucidef_set_interface_lan "eth0" "dhcp"
;;
diff --git a/target/linux/ixp4xx/config-6.1 b/target/linux/ixp4xx/config-6.1
index 3b47385d6b8d..4c4aa11969ea 100644
--- a/target/linux/ixp4xx/config-6.1
+++ b/target/linux/ixp4xx/config-6.1
@@ -1,4 +1,5 @@
 CONFIG_ALIGNMENT_TRAP=y
+CONFIG_AMD_PHY=y
 CONFIG_ARCH_32BIT_OFF_T=y
 CONFIG_ARCH_HIBERNATION_POSSIBLE=y
 CONFIG_ARCH_IXP4XX=y
diff --git a/target/linux/ixp4xx/image/Makefile 
b/target/linux/ixp4xx/image/Makefile
index 0bcabe2db143..c6d4817c966f 100644
--- a/target/linux/ixp4xx/image/Makefile
+++ b/target/linux/ixp4xx/image/Makefile
@@ -74,4 +74,17 @@ define Device/linksys_nslu2
 endef
 TARGET_DEVICES += linksys_nslu2
 
+define Device/usrobotics_usr8200
+   DEVICE_VENDOR := USRobotics
+   DEVICE_MODEL := USR8200
+   # USB2 is compiled in and needs no package
+   DEVICE_PACKAGES := ixp4xx-microcode-ethernet kmod-rtc-r7301 
kmod-firewire kmod-firewire-ohci
+   DEVICE_DTS := intel-ixp42x-usrobotics-usr8200
+   KERNEL := kernel-bin | append-dtb
+   IMAGES := kernel.bin rootfs.bin
+   IMAGE/kernel.bin := append-kernel
+   IMAGE/rootfs.bin := append-rootfs | pad-rootfs | pad-to 128k
+endef
+TARGET_DEVICES += usrobotics_usr8200
+
 $(eval $(call BuildImage))
diff --git 
a/target/linux/ixp4xx/patches-6.1/0002-gpio-ixp4xx-Handle-clock-output-on-pin-14-and-15.patch
 
b/target/linux/ixp4xx/patches-6.1/0002-gpio-ixp4xx-Handle-clock-output-on-pin-14-and-15.patch
new file mode 100644
index ..38adecd64fff
--- /dev/null
+++ 
b/target/linux/ixp4xx/patches-6.1/0002-gpio-ixp4xx-Handle-clock-output-on-pin-14-and-15.patch
@@ -0,0 +1,93 @@
+From fc58944733a2082e3290eda240eb3247a00ad73a Mon Sep 17 00:00:00 2001
+From: Linus Walleij 
+Date: Thu, 21 Sep 2023 00:12:42 +0200
+Subject: [PATCH] gpio: ixp4xx: Handle clock output on pin 14 and 15
+
+This makes it possible to provide basic clock output on pins
+14 and 15. The clocks are typically used by random electronics,
+not modeled in the device tree, so they just need to be provided
+on request.
+
+In order to not disturb old systems that require that the
+hardware defaults are kept in the clock setting bits, we only
+manipulate these if either device tree property is present.
+Once we know a device needs one of the clocks we can set it
+in the device tree.
+
+Signed-off-by: Linus Walleij 
+---
+ drivers/gpio/gpio-ixp4xx.c | 49 +-
+ 1 file changed, 48 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpio/gpio-ixp4xx.c
 b/drivers/gpio/gpio-ixp4xx.c
+@@ -38,6 +38,18 @@
+ #define IXP4XX_GPIO_STYLE_MASKGENMASK(2, 0)
+ #define IXP4XX_GPIO_STYLE_SIZE3
+ 
++/*
++ * Clock output control register defines.
++ */
++#define IXP4XX_GPCLK_CLK0DC_SHIFT 0
++#define IXP4XX_GPCLK_CLK0TC_SHIFT 4
++#define IXP4XX_GPCLK_CLK0_MASKGENMASK(7, 0)
++#define IXP4XX_GPCLK_MUX14BIT(8)
++#define IXP4XX_GPCLK_CLK1DC_SHIFT 16
++#define IXP4XX_GPCLK_CLK1TC_SHIFT 20
++#define IXP4XX_GPCLK_CLK1_MASKGENMASK(23, 16)
++#define IXP4XX_GPCLK_MUX15BIT(24)
++
+ /**
+  * struct ixp4xx_gpio - IXP4 GPIO state container
+  * @dev: containing device for this instance
+@@ -203,6 +215,8 @@ static int ixp4xx_gpio_probe(struct plat
+   struct ixp4xx_gpio *g;
+   struct gpio_irq_chip *girq;
+   struct device_node *irq_parent;
++  bool clk_14, clk_15;
++  u32 val;
+   int ret;
+ 
+   g = devm_kzalloc(dev, sizeof(*g), GFP_KERNEL);
+@@ -233,7 +247,40 @@ static int ixp4

[PATCH v4 1/7] kernel: netdevices: Package AMD PHY

2023-10-23 Thread Linus Walleij

This adds a package for the AMD and Altima PHY, found in some
odd devices.

Signed-off-by: Linus Walleij 
---
ChangeLog v1->v4:
- Add preinit flag since the network interface may be the only
  and primary network interface of the platform.
---
 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..9057ec561515 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,amd,1)
+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

[PATCH v4 0/7] Resurrect OpenWrt IXP4xx support

2023-10-23 Thread Linus Walleij

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 mailin

[PATCH v4 5/7] ixp4xx: Resurrect IXP4xx support using device tree

2023-10-23 Thread Linus Walleij

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/

Signed-off-by: Howard Harte 
Signed-off-by: Linus Walleij 
---
ChangeLog v2->v3:
- Don't add the apex package on the NSLU2, the dependency
  is resolved in the other direction, apex should only build
  itself for the targets that need it.
- Alter the path for the apex binaries slightly.
- Split out resurrection of the microcode package to its
  own patch.
- Use only the ip command and not both ip and ifconfig in
  the MAC setup script.
- Drop unsupported device from the MAC setup script.
- Name devices with device tuples like gateworks_avila.
- Fix name confusion Gateway -> Gateworks.
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.
---
 target/linux/ixp4xx/Makefile   |  27 +++
 .../linux/ixp4xx/base-files/etc/board.d/02_network |  21 ++
 .../base-files/lib/preinit/05_set_ether_mac_ixp4xx |  38 
 target/linux/ixp4xx/config-6.1 | 252 +
 target/linux/ixp4xx/image/Makefile |  77 +++
 ...01-mtd-cfi_cmdset_0001-Byte-swap-OTP-info.patch |  74 ++
 ...-ARM-dts-ixp4xx-Boot-NSLU2-from-harddrive.patch |  24 ++
 7 files changed, 513 insertions(+)

diff --git a/target/linux/ixp4xx/Makefile b/target/linux/ixp4xx/Makefile
new file mode 100644
index ..89a1b2407bfe
--- /dev/null
+++ b/target/linux/ixp4xx/Makefile
@@ -0,0 +1,27 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Copyright (C) 2006-2023 OpenWrt.org
+
+include $(TOPDIR)/rules.mk
+
+ARCH:=armeb
+BOARD:=ixp4xx
+BOARDNAME:=Intel XScale IXP4xx
+FEATURES:=dt squashfs gpio
+CPU_TYPE:=xscale
+
+KERNEL_PATCHVER:=6.1
+
+define Target/Description
+   Build firmware images for the IXP4xx XScale CPU
+endef
+
+KERNELNAME:=zImage dtbs
+
+include $(INCLUDE_DIR)/target.mk
+
+DEFAULT_PACKAGES += fconfig \
+   kmod-usb-ledtrig-usbport \
+   kmod-leds-gpio
+
+$(eval $(call BuildTarget))
diff --git a/target/linux/ixp4xx/base-files/etc/board.d/02_network 
b/target/linux/ixp4xx/base-files/etc/board.d/02_network
new file mode 100644
index ..45d7cbc75a4a
--- /dev/null
+++ b/target/linux/ixp4xx/base-files/etc/board.d/02_network
@@ -0,0 +1,21 @@
+# SPDX-License-Identifier: GPL-2.0-only
+. /lib/functions/uci-defaults.sh
+
+board_config_update
+
+case "$(board_name)" in
+gateworks,gw2348|\
+gateworks,gw2358)
+   ucidef_set_interfaces_lan_wan "eth0" "eth1"
+   ;;
+linksys,nslu2)
+   ucidef_set_interface_lan "eth0" "dhcp"
+   ;;
+*)
+   ucidef_set_interface_lan "eth0" "dhcp"
+   ;;
+esac
+
+board_config_flush
+
+exit 0
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 ..9e7ff4629830
--- /dev/null
+++ b/target/linux/ixp4xx/base-files/lib/preinit/05_set_ether_mac_ixp4xx
@@ -0,0 +1,38 @@
+#!/bin/sh
+. /lib/functions.sh
+. /lib/functions/system.sh
+
+set_from_redboot () {
+   for npe in eth0 eth1 eth2
+   do
+   if ip link show dev $npe > /dev/null 2>&1; then
+   ip link set dev $npe address $(fconfig -s -r -d /dev/$1 
-n npe_"

[PATCH v4 6/7] ixp4xx: Add a ixp4xx hardware crypto kernel module

2023-10-23 Thread Linus Walleij

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 
---
ChangeLog v1->v3:
- Use AutoProbe for loading the module.
---
 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 c0ccdaa3dfe6..dd17d868fa15 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 AutoProbe,ixp4xx_crypto)
+  $(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

[PATCH v4 2/7] generic: RTC7301 byte-addressed IO

2023-10-23 Thread Linus Walleij

This is a backport of the patch for byte addressed IO to the
Epson RTC7301 driver. This is used by the IXP4xx-based
USRobotics USR8200.

Signed-off-by: Linus Walleij 
---
 ...6.7-rtc-rtc7301-Support-byte-addressed-IO.patch | 93 ++
 1 file changed, 93 insertions(+)

diff --git 
a/target/linux/generic/backport-6.1/831-v6.7-rtc-rtc7301-Support-byte-addressed-IO.patch
 
b/target/linux/generic/backport-6.1/831-v6.7-rtc-rtc7301-Support-byte-addressed-IO.patch
new file mode 100644
index ..ddda6e4e7832
--- /dev/null
+++ 
b/target/linux/generic/backport-6.1/831-v6.7-rtc-rtc7301-Support-byte-addressed-IO.patch
@@ -0,0 +1,93 @@
+From edd25a77e69b7c546c28077e5dffe72c54c0afe8 Mon Sep 17 00:00:00 2001
+From: Linus Walleij 
+Date: Thu, 21 Sep 2023 22:18:12 +0200
+Subject: [PATCH 2/4] rtc: rtc7301: Support byte-addressed IO
+
+The old RTC7301 driver in OpenWrt used byte access, but the
+current mainline Linux driver uses 32bit word access.
+
+Make this configurable using device properties using the
+standard property "reg-io-width" in e.g. device tree.
+
+This is needed for the USRobotics USR8200 which has the
+chip connected using byte accesses.
+
+Debugging and testing by Howard Harte.
+
+Signed-off-by: Linus Walleij 
+---
+ drivers/rtc/rtc-r7301.c | 35 +--
+ 1 file changed, 33 insertions(+), 2 deletions(-)
+
+--- a/drivers/rtc/rtc-r7301.c
 b/drivers/rtc/rtc-r7301.c
+@@ -14,6 +14,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #include 
+ #include 
+ #include 
+@@ -55,12 +56,23 @@ struct rtc7301_priv {
+   u8 bank;
+ };
+ 
+-static const struct regmap_config rtc7301_regmap_config = {
++/*
++ * When the device is memory-mapped, some platforms pack the registers into
++ * 32-bit access using the lower 8 bits at each 4-byte stride, while others
++ * expose them as simply consecutive bytes.
++ */
++static const struct regmap_config rtc7301_regmap_32_config = {
+   .reg_bits = 32,
+   .val_bits = 8,
+   .reg_stride = 4,
+ };
+ 
++static const struct regmap_config rtc7301_regmap_8_config = {
++  .reg_bits = 8,
++  .val_bits = 8,
++  .reg_stride = 1,
++};
++
+ static u8 rtc7301_read(struct rtc7301_priv *priv, unsigned int reg)
+ {
+   int reg_stride = regmap_get_reg_stride(priv->regmap);
+@@ -356,7 +368,9 @@ static int __init rtc7301_rtc_probe(stru
+   void __iomem *regs;
+   struct rtc7301_priv *priv;
+   struct rtc_device *rtc;
++  static const struct regmap_config *mapconf;
+   int ret;
++  u32 val;
+ 
+   priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
+   if (!priv)
+@@ -366,8 +380,25 @@ static int __init rtc7301_rtc_probe(stru
+   if (IS_ERR(regs))
+   return PTR_ERR(regs);
+ 
++  ret = device_property_read_u32(>dev, "reg-io-width", );
++  if (ret)
++  /* Default to 32bit accesses */
++  val = 4;
++
++  switch (val) {
++  case 1:
++  mapconf = _regmap_8_config;
++  break;
++  case 4:
++  mapconf = _regmap_32_config;
++  break;
++  default:
++  dev_err(>dev, "invalid reg-io-width %d\n", val);
++  return -EINVAL;
++  }
++
+   priv->regmap = devm_regmap_init_mmio(>dev, regs,
+-   _regmap_config);
++   mapconf);
+   if (IS_ERR(priv->regmap))
+   return PTR_ERR(priv->regmap);
+ 

-- 
2.34.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v4 3/7] generic: Support Altima AMI101L PHY

2023-10-23 Thread Linus Walleij

This is a backport of the patch to support the Altima AMI101L
PHY which is merged for the v6.7 kernel. This PHY is used in the
IXP4xx-based USRobotics USR8200.

Signed-off-by: Linus Walleij 
---
 7-net-phy-amd-Support-the-Altima-AMI101L.patch | 82 ++
 1 file changed, 82 insertions(+)

diff --git 
a/target/linux/generic/backport-6.1/832-v6.7-net-phy-amd-Support-the-Altima-AMI101L.patch
 
b/target/linux/generic/backport-6.1/832-v6.7-net-phy-amd-Support-the-Altima-AMI101L.patch
new file mode 100644
index ..c2ecc5bfff8b
--- /dev/null
+++ 
b/target/linux/generic/backport-6.1/832-v6.7-net-phy-amd-Support-the-Altima-AMI101L.patch
@@ -0,0 +1,82 @@
+From 49e5663b505070424e18099841943f34342aa405 Mon Sep 17 00:00:00 2001
+From: Linus Walleij 
+Date: Sun, 24 Sep 2023 01:09:01 +0200
+Subject: [PATCH] net: phy: amd: Support the Altima AMI101L
+
+The Altima AC101L is obviously compatible with the AMD PHY,
+as seen by reading the datasheet.
+
+Datasheet: https://docs.broadcom.com/doc/AC101L-DS05-405-RDS.pdf
+
+Signed-off-by: Linus Walleij 
+---
+ drivers/net/phy/Kconfig |  4 ++--
+ drivers/net/phy/amd.c   | 33 +++--
+ 2 files changed, 25 insertions(+), 12 deletions(-)
+
+--- a/drivers/net/phy/Kconfig
 b/drivers/net/phy/Kconfig
+@@ -146,9 +146,9 @@ endif # RTL8366_SMI
+ comment "MII PHY device drivers"
+ 
+ config AMD_PHY
+-  tristate "AMD PHYs"
++  tristate "AMD and Altima PHYs"
+   help
+-Currently supports the am79c874
++Currently supports the AMD am79c874 and Altima AC101L.
+ 
+ config MESON_GXL_PHY
+   tristate "Amlogic Meson GXL Internal PHY"
+--- a/drivers/net/phy/amd.c
 b/drivers/net/phy/amd.c
+@@ -13,6 +13,7 @@
+ #include 
+ #include 
+ 
++#define PHY_ID_AC101L 0x00225520
+ #define PHY_ID_AM79C874   0x0022561b
+ 
+ #define MII_AM79C_IR  17  /* Interrupt Status/Control Register */
+@@ -87,19 +88,31 @@ static irqreturn_t am79c_handle_interrup
+   return IRQ_HANDLED;
+ }
+ 
+-static struct phy_driver am79c_driver[] = { {
+-  .phy_id = PHY_ID_AM79C874,
+-  .name   = "AM79C874",
+-  .phy_id_mask= 0xfff0,
+-  /* PHY_BASIC_FEATURES */
+-  .config_init= am79c_config_init,
+-  .config_intr= am79c_config_intr,
+-  .handle_interrupt = am79c_handle_interrupt,
+-} };
++static struct phy_driver am79c_drivers[] = {
++  {
++  .phy_id = PHY_ID_AM79C874,
++  .name   = "AM79C874",
++  .phy_id_mask= 0xfff0,
++  /* PHY_BASIC_FEATURES */
++  .config_init= am79c_config_init,
++  .config_intr= am79c_config_intr,
++  .handle_interrupt = am79c_handle_interrupt,
++  },
++  {
++  .phy_id = PHY_ID_AC101L,
++  .name   = "AC101L",
++  .phy_id_mask= 0xfff0,
++  /* PHY_BASIC_FEATURES */
++  .config_init= am79c_config_init,
++  .config_intr= am79c_config_intr,
++  .handle_interrupt = am79c_handle_interrupt,
++  },
++};
+ 
+-module_phy_driver(am79c_driver);
++module_phy_driver(am79c_drivers);
+ 
+ static struct mdio_device_id __maybe_unused amd_tbl[] = {
++  { PHY_ID_AC101L, 0xfff0 },
+   { PHY_ID_AM79C874, 0xfff0 },
+   { }
+ };

-- 
2.34.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v4 4/7] firmware: Resurrect the ixp4xx microcode package

2023-10-23 Thread Linus Walleij

The firmware package for the IXP4xx microcode was deleted but
the source files are still in the file cache so we can easily
resurrect it.

The firmware either supports ethernet (the most common) or
WAN (less common), image targets select the firmware they
want depending on usecase.

Signed-off-by: Linus Walleij 
---
 package/firmware/ixp4xx-microcode/Makefile |  77 +++
 .../firmware/ixp4xx-microcode/src/IxNpeMicrocode.h | 148 +
 package/firmware/ixp4xx-microcode/src/LICENSE.IPL  |  27 
 3 files changed, 252 insertions(+)

diff --git a/package/firmware/ixp4xx-microcode/Makefile 
b/package/firmware/ixp4xx-microcode/Makefile
new file mode 100644
index ..5ee04a757a2c
--- /dev/null
+++ b/package/firmware/ixp4xx-microcode/Makefile
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Copyright (C) 2007-2023 OpenWrt.org
+
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=ixp4xx-microcode
+PKG_VERSION:=2.4
+PKG_RELEASE:=1
+
+PKG_SOURCE:=IPL_ixp400NpeLibraryWithCrypto-2_4.zip
+PKG_SOURCE_URL:=http://downloads.openwrt.org/sources
+PKG_HASH:=1b1170d0657847248589d946048c0aeaa9cd671966fc5bec5933283309485eaa
+
+PKG_FLAGS:=nonshared
+
+include $(INCLUDE_DIR)/package.mk
+
+# Ethernet or WAN support, pick one
+define Package/ixp4xx-microcode-ethernet
+  SECTION:=firmware
+  CATEGORY:=Firmware
+  TITLE:=IXP4xx ethernet firmware
+  DEPENDS:=@TARGET_ixp4xx
+endef
+define Package/ixp4xx-microcode-wan
+  SECTION:=firmware
+  CATEGORY:=Firmware
+  TITLE:=IXP4xx WAN firmware
+  DEPENDS:=@TARGET_ixp4xx
+endef
+
+define Package/ixp4xx-microcode-ethernet/description
+ This package contains the microcode needed to use the network engines in
+ IXP4xx CPUs for ethernet on all three NPEs.
+endef
+define Package/ixp4xx-microcode-wan/description
+ This package contains the microcode needed to use the network engines in
+ IXP4xx CPUs for ethernet on NPE-A and NPE-B and WAN (HSS) on NPE-C.
+endef
+
+define Build/Prepare
+   rm -rf $(PKG_BUILD_DIR)
+   mkdir -p $(PKG_BUILD_DIR)
+   unzip -d $(PKG_BUILD_DIR)/ $(DL_DIR)/$(PKG_SOURCE)
+   mv $(PKG_BUILD_DIR)/ixp400_xscale_sw/src/npeDl/IxNpeMicrocode.c 
$(PKG_BUILD_DIR)/
+   rm -rf $(PKG_BUILD_DIR)/ixp400_xscale_sw
+   $(CP) ./src/* $(PKG_BUILD_DIR)/
+endef
+
+define Build/Compile
+   (cd $(PKG_BUILD_DIR); \
+   $(HOSTCC) -Wall -I$(STAGING_DIR_HOST)/include IxNpeMicrocode.c 
-o IxNpeMicrocode; \
+   ./IxNpeMicrocode -be \
+   )
+endef
+
+define Package/ixp4xx-microcode-ethernet/install
+   $(INSTALL_DIR) $(1)/lib/firmware
+   $(INSTALL_DIR) $(1)/usr/share/doc
+   $(INSTALL_BIN) $(PKG_BUILD_DIR)/NPE-A $(1)/lib/firmware/
+   $(INSTALL_BIN) $(PKG_BUILD_DIR)/NPE-B $(1)/lib/firmware/
+   $(INSTALL_BIN) $(PKG_BUILD_DIR)/NPE-C $(1)/lib/firmware/
+   $(INSTALL_DATA) $(PKG_BUILD_DIR)/LICENSE.IPL $(1)/usr/share/doc/
+endef
+define Package/ixp4xx-microcode-wan/install
+   $(INSTALL_DIR) $(1)/lib/firmware
+   $(INSTALL_DIR) $(1)/usr/share/doc
+   $(INSTALL_BIN) $(PKG_BUILD_DIR)/NPE-A-HSS $(1)/lib/firmware/
+   $(INSTALL_BIN) $(PKG_BUILD_DIR)/NPE-B $(1)/lib/firmware/
+   $(INSTALL_BIN) $(PKG_BUILD_DIR)/NPE-C $(1)/lib/firmware/
+   $(INSTALL_DATA) $(PKG_BUILD_DIR)/LICENSE.IPL $(1)/usr/share/doc/
+endef
+
+
+$(eval $(call BuildPackage,ixp4xx-microcode-ethernet))
+$(eval $(call BuildPackage,ixp4xx-microcode-wan))
diff --git a/package/firmware/ixp4xx-microcode/src/IxNpeMicrocode.h 
b/package/firmware/ixp4xx-microcode/src/IxNpeMicrocode.h
new file mode 100644
index ..4a843db104f9
--- /dev/null
+++ b/package/firmware/ixp4xx-microcode/src/IxNpeMicrocode.h
@@ -0,0 +1,148 @@
+/*
+ * IxNpeMicrocode.h - Headerfile for compiling the Intel microcode C file
+ *
+ * Copyright (C) 2006 Christian Hohnstaedt 
+ *
+ * This file is released under the GPLv2
+ *
+ *
+ * compile with
+ *
+ * gcc -Wall IxNpeMicrocode.c -o IxNpeMicrocode
+ *
+ * Executing the resulting binary on your build-host creates the
+ * "NPE-[ABC]." files containing the selected microcode
+ *
+ * fetch the IxNpeMicrocode.c from the Intel Access Library.
+ * It will include this header.
+ *
+ * select Images for every NPE from the following
+ * (used C++ comments for easy uncommenting )
+ */
+
+// #define 
IX_NPEDL_NPEIMAGE_NPEA_ETH_SPAN_MASK_FIREWALL_VLAN_QOS_HDR_CONV_EXTMIB
+// #define IX_NPEDL_NPEIMAGE_NPEA_ETH_SPAN_VLAN_QOS_HDR_CONV_EXTMIB
+// #define 
IX_NPEDL_NPEIMAGE_NPEA_ETH_LEARN_FILTER_SPAN_MASK_FIREWALL_VLAN_QOS_EXTMIB
+// #define IX_NPEDL_NPEIMAGE_NPEA_HSS_TSLOT_SWITCH
+#define IX_NPEDL_NPEIMAGE_NPEA_ETH_SPAN_FIREWALL_VLAN_QOS_HDR_CONV
+// #define IX_NPEDL_NPEIMAGE_NPEA_ETH_LEARN_FILTER_SPAN_FIREWALL_VLAN_QOS
+// #define IX_NPEDL_NPEIMAGE_NPEA_ETH_LEARN_FILTER_SPAN_FIREWALL
+#define IX_NPEDL_NPEIMAGE_NPEA_HSS_2_PORT
+// #define IX_NPEDL_NPEIMAGE_NPEA_DMA
+// #define IX_NPEDL_NPEIMAGE_NPEA_ATM_MPHY_12_PORT
+// #define IX_NPEDL_NPEIMAGE_NPEA_HSS0_ATM_M

Re: [PATCH v3 00/10] Resurrect OpenWrt IXP4xx support

2023-10-20 Thread Linus Walleij

On Fri, Oct 20, 2023 at 2:52 PM Christian Marangi  wrote:
> On Fri, Oct 20, 2023 at 02:48:33PM +0200, Linus Walleij wrote:
> > On Fri, Oct 20, 2023 at 2:32 PM Christian Marangi  
> > wrote:
> >
> > > Yes! Would be ideal then we can just bump the linux-firmware package and
> > > reference it there.
> >
> > OK I'll try this.
> >
> > > What would happen to the additional source tho? Would it be included in
> > > the submitted fw?
> >
> > Yes there are several things like that in linux-firmware.
> >
>
> In the meantime we can totally merge the rest of the series and set it
> as BROKEN/SOURCE ONLY while we handle it.

Yeah, the .tar.gz has been in the OpenWrt files cache for 20 years
or something so it's not like it's gonna disappear :D

Yours,
Linus Walleij

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH v3 00/10] Resurrect OpenWrt IXP4xx support

2023-10-20 Thread Linus Walleij

On Fri, Oct 20, 2023 at 2:32 PM Christian Marangi  wrote:

> Yes! Would be ideal then we can just bump the linux-firmware package and
> reference it there.

OK I'll try this.

> What would happen to the additional source tho? Would it be included in
> the submitted fw?

Yes there are several things like that in linux-firmware.

Yours,
Linus Walleij

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH v3 00/10] Resurrect OpenWrt IXP4xx support

2023-10-20 Thread Linus Walleij

On Fri, Oct 20, 2023 at 1:33 PM Christian Marangi  wrote:
> On Fri, Oct 20, 2023 at 01:15:51PM +0200, Linus Walleij wrote:

> > If there is some rough consensus on this, could someone start
> > applying these patches, apart from patch 10/10 where we might
> > want to do something different?
> >
>
> I started to merge the first trivial patch that just adds packages and
> minor changes. We really need to understand how to handle the microcode
> package source... We can consider hosting the content on a git
> repository?

Actually the license is free enough that it can be included with
linux-firmware, shall I just submit it for inclusion there?

Yours,
Linus Walleij

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH v3 00/10] Resurrect OpenWrt IXP4xx support

2023-10-20 Thread Linus Walleij

If there is some rough consensus on this, could someone start
applying these patches, apart from patch 10/10 where we might
want to do something different?

If no-one is willing to shepherd IXP4xx I am willing to do commits
but that requires commit access, and I don't think I can
self-nominate for that.

Yours,
Linus Walleij

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH v3 10/10] ixp4xx: Add hdparm script

2023-10-13 Thread Linus Walleij

On Fri, Oct 13, 2023 at 12:28 AM Andrey Jr. Melnikov
 wrote:
> Linus Walleij  wrote:

> > This script will make sure to spin down harddrives on IXP4xx
> > NAS devices such as the NSLU2 and siblings after 1 minute
> > of inactivity.
>
> Why not use hotplug events?

Could be a good idea! Do you have a pointer to how we do these
in OpenWrt?

Yours,
Linus Walleij

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v3 09/10] ixp4xx: Add USRobotics USR8200 support

2023-10-12 Thread Linus Walleij

This brings back USRobotics USR8200 support to the IXP4xx
target.

Signed-off-by: Linus Walleij 
---
 .../linux/ixp4xx/base-files/etc/board.d/02_network |   5 +
 target/linux/ixp4xx/config-6.1 |   1 +
 target/linux/ixp4xx/image/Makefile |  13 ++
 ...p4xx-Handle-clock-output-on-pin-14-and-15.patch |  93 
 ...003-rtc-rtc7301-Support-byte-addressed-IO.patch |  93 
 ...ixp4xx-Add-USRobotics-USR8200-device-tree.patch | 260 +
 ...5-net-ixp4xx_eth-Support-changing-the-MTU.patch | 132 +++
 ...06-net-phy-amd-Support-the-Altima-AMI101L.patch |  82 +++
 ...dog-ixp4xx-Make-sure-restart-always-works.patch |  79 +++
 9 files changed, 758 insertions(+)

diff --git a/target/linux/ixp4xx/base-files/etc/board.d/02_network 
b/target/linux/ixp4xx/base-files/etc/board.d/02_network
index 45d7cbc75a4a..864328d6bcf1 100644
--- a/target/linux/ixp4xx/base-files/etc/board.d/02_network
+++ b/target/linux/ixp4xx/base-files/etc/board.d/02_network
@@ -11,6 +11,11 @@ gateworks,gw2358)
 linksys,nslu2)
ucidef_set_interface_lan "eth0" "dhcp"
;;
+usr,usr8200)
+   # LAN ports connected to eth1 thru the MV88E6060 DSA switch
+   ucidef_set_interface "eth" device "eth1" protocol "none"
+   ucidef_set_interfaces_lan_wan "lan1 lan2 lan3 lan4" "eth0"
+   ;;
 *)
ucidef_set_interface_lan "eth0" "dhcp"
;;
diff --git a/target/linux/ixp4xx/config-6.1 b/target/linux/ixp4xx/config-6.1
index 3b47385d6b8d..4c4aa11969ea 100644
--- a/target/linux/ixp4xx/config-6.1
+++ b/target/linux/ixp4xx/config-6.1
@@ -1,4 +1,5 @@
 CONFIG_ALIGNMENT_TRAP=y
+CONFIG_AMD_PHY=y
 CONFIG_ARCH_32BIT_OFF_T=y
 CONFIG_ARCH_HIBERNATION_POSSIBLE=y
 CONFIG_ARCH_IXP4XX=y
diff --git a/target/linux/ixp4xx/image/Makefile 
b/target/linux/ixp4xx/image/Makefile
index 0bcabe2db143..c6d4817c966f 100644
--- a/target/linux/ixp4xx/image/Makefile
+++ b/target/linux/ixp4xx/image/Makefile
@@ -74,4 +74,17 @@ define Device/linksys_nslu2
 endef
 TARGET_DEVICES += linksys_nslu2
 
+define Device/usrobotics_usr8200
+   DEVICE_VENDOR := USRobotics
+   DEVICE_MODEL := USR8200
+   # USB2 is compiled in and needs no package
+   DEVICE_PACKAGES := ixp4xx-microcode-ethernet kmod-rtc-r7301 
kmod-firewire kmod-firewire-ohci
+   DEVICE_DTS := intel-ixp42x-usrobotics-usr8200
+   KERNEL := kernel-bin | append-dtb
+   IMAGES := kernel.bin rootfs.bin
+   IMAGE/kernel.bin := append-kernel
+   IMAGE/rootfs.bin := append-rootfs | pad-rootfs | pad-to 128k
+endef
+TARGET_DEVICES += usrobotics_usr8200
+
 $(eval $(call BuildImage))
diff --git 
a/target/linux/ixp4xx/patches-6.1/0002-gpio-ixp4xx-Handle-clock-output-on-pin-14-and-15.patch
 
b/target/linux/ixp4xx/patches-6.1/0002-gpio-ixp4xx-Handle-clock-output-on-pin-14-and-15.patch
new file mode 100644
index ..38adecd64fff
--- /dev/null
+++ 
b/target/linux/ixp4xx/patches-6.1/0002-gpio-ixp4xx-Handle-clock-output-on-pin-14-and-15.patch
@@ -0,0 +1,93 @@
+From fc58944733a2082e3290eda240eb3247a00ad73a Mon Sep 17 00:00:00 2001
+From: Linus Walleij 
+Date: Thu, 21 Sep 2023 00:12:42 +0200
+Subject: [PATCH] gpio: ixp4xx: Handle clock output on pin 14 and 15
+
+This makes it possible to provide basic clock output on pins
+14 and 15. The clocks are typically used by random electronics,
+not modeled in the device tree, so they just need to be provided
+on request.
+
+In order to not disturb old systems that require that the
+hardware defaults are kept in the clock setting bits, we only
+manipulate these if either device tree property is present.
+Once we know a device needs one of the clocks we can set it
+in the device tree.
+
+Signed-off-by: Linus Walleij 
+---
+ drivers/gpio/gpio-ixp4xx.c | 49 +-
+ 1 file changed, 48 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpio/gpio-ixp4xx.c
 b/drivers/gpio/gpio-ixp4xx.c
+@@ -38,6 +38,18 @@
+ #define IXP4XX_GPIO_STYLE_MASKGENMASK(2, 0)
+ #define IXP4XX_GPIO_STYLE_SIZE3
+ 
++/*
++ * Clock output control register defines.
++ */
++#define IXP4XX_GPCLK_CLK0DC_SHIFT 0
++#define IXP4XX_GPCLK_CLK0TC_SHIFT 4
++#define IXP4XX_GPCLK_CLK0_MASKGENMASK(7, 0)
++#define IXP4XX_GPCLK_MUX14BIT(8)
++#define IXP4XX_GPCLK_CLK1DC_SHIFT 16
++#define IXP4XX_GPCLK_CLK1TC_SHIFT 20
++#define IXP4XX_GPCLK_CLK1_MASKGENMASK(23, 16)
++#define IXP4XX_GPCLK_MUX15BIT(24)
++
+ /**
+  * struct ixp4xx_gpio - IXP4 GPIO state container
+  * @dev: containing device for this instance
+@@ -203,6 +215,8 @@ static int ixp4xx_gpio_probe(struct plat
+   struct ixp4xx_gpio *g;
+   struct gpio_irq_chip *girq;
+   struct device_node *irq_parent;
++  bool clk_14, clk_15;
++  u32 val;
+   int ret;
+ 
+   g = devm_kzalloc(de

[PATCH v3 07/10] ixp4xx: Resurrect IXP4xx support using device tree

2023-10-12 Thread Linus Walleij

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/

Signed-off-by: Howard Harte 
Signed-off-by: Linus Walleij 
---
ChangeLog v2->v3:
- Don't add the apex package on the NSLU2, the dependency
  is resolved in the other direction, apex should only build
  itself for the targets that need it.
- Alter the path for the apex binaries slightly.
- Split out resurrection of the microcode package to its
  own patch.
- Use only the ip command and not both ip and ifconfig in
  the MAC setup script.
- Drop unsupported device from the MAC setup script.
- Name devices with device tuples like gateworks_avila.
- Fix name confusion Gateway -> Gateworks.
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.
---
 target/linux/ixp4xx/Makefile   |  27 +++
 .../linux/ixp4xx/base-files/etc/board.d/02_network |  21 ++
 .../base-files/lib/preinit/05_set_ether_mac_ixp4xx |  38 
 target/linux/ixp4xx/config-6.1 | 252 +
 target/linux/ixp4xx/image/Makefile |  77 +++
 ...01-mtd-cfi_cmdset_0001-Byte-swap-OTP-info.patch |  74 ++
 ...-ARM-dts-ixp4xx-Boot-NSLU2-from-harddrive.patch |  24 ++
 7 files changed, 513 insertions(+)

diff --git a/target/linux/ixp4xx/Makefile b/target/linux/ixp4xx/Makefile
new file mode 100644
index ..89a1b2407bfe
--- /dev/null
+++ b/target/linux/ixp4xx/Makefile
@@ -0,0 +1,27 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Copyright (C) 2006-2023 OpenWrt.org
+
+include $(TOPDIR)/rules.mk
+
+ARCH:=armeb
+BOARD:=ixp4xx
+BOARDNAME:=Intel XScale IXP4xx
+FEATURES:=dt squashfs gpio
+CPU_TYPE:=xscale
+
+KERNEL_PATCHVER:=6.1
+
+define Target/Description
+   Build firmware images for the IXP4xx XScale CPU
+endef
+
+KERNELNAME:=zImage dtbs
+
+include $(INCLUDE_DIR)/target.mk
+
+DEFAULT_PACKAGES += fconfig \
+   kmod-usb-ledtrig-usbport \
+   kmod-leds-gpio
+
+$(eval $(call BuildTarget))
diff --git a/target/linux/ixp4xx/base-files/etc/board.d/02_network 
b/target/linux/ixp4xx/base-files/etc/board.d/02_network
new file mode 100644
index ..45d7cbc75a4a
--- /dev/null
+++ b/target/linux/ixp4xx/base-files/etc/board.d/02_network
@@ -0,0 +1,21 @@
+# SPDX-License-Identifier: GPL-2.0-only
+. /lib/functions/uci-defaults.sh
+
+board_config_update
+
+case "$(board_name)" in
+gateworks,gw2348|\
+gateworks,gw2358)
+   ucidef_set_interfaces_lan_wan "eth0" "eth1"
+   ;;
+linksys,nslu2)
+   ucidef_set_interface_lan "eth0" "dhcp"
+   ;;
+*)
+   ucidef_set_interface_lan "eth0" "dhcp"
+   ;;
+esac
+
+board_config_flush
+
+exit 0
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 ..9e7ff4629830
--- /dev/null
+++ b/target/linux/ixp4xx/base-files/lib/preinit/05_set_ether_mac_ixp4xx
@@ -0,0 +1,38 @@
+#!/bin/sh
+. /lib/functions.sh
+. /lib/functions/system.sh
+
+set_from_redboot () {
+   for npe in eth0 eth1 eth2
+   do
+   if ip link show dev $npe > /dev/null 2>&1; then
+   ip link set dev $npe address $(fconfig -s -r -d /dev/$1 
-n npe_"

[PATCH v3 03/10] kernel: Add kmod-rtc-x1205

2023-10-12 Thread Linus Walleij

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 
---
ChangeLog v1->v3:
- Use autoprobe, exclude from preinit.
---
 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..2cd01d84d516 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 AutoProbe,rtc-x1205)
+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

[PATCH v3 08/10] ixp4xx: Add a ixp4xx hardware crypto kernel module

2023-10-12 Thread Linus Walleij

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 
---
ChangeLog v1->v3:
- Use AutoProbe for loading the module.
---
 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 c0ccdaa3dfe6..dd17d868fa15 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 AutoProbe,ixp4xx_crypto)
+  $(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

[PATCH v3 04/10] kernel: Add kmod-rtc-r7301

2023-10-12 Thread Linus Walleij

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 
---
ChangeLog v1->v3:
- Use AutoProbe, drop preinit hook.
---
 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 2cd01d84d516..feee39602db9 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 AutoProbe,rtc-r7301)
+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

[PATCH v3 06/10] firmware: Resurrect the ixp4xx microcode package

2023-10-12 Thread Linus Walleij

The firmware package for the IXP4xx microcode was deleted but
the source files are still in the file cache so we can easily
resurrect it.

The firmware either supports ethernet (the most common) or
WAN (less common), image targets select the firmware they
want depending on usecase.

Signed-off-by: Linus Walleij 
---
 package/firmware/ixp4xx-microcode/Makefile |  77 +++
 .../firmware/ixp4xx-microcode/src/IxNpeMicrocode.h | 148 +
 package/firmware/ixp4xx-microcode/src/LICENSE.IPL  |  27 
 3 files changed, 252 insertions(+)

diff --git a/package/firmware/ixp4xx-microcode/Makefile 
b/package/firmware/ixp4xx-microcode/Makefile
new file mode 100644
index ..5ee04a757a2c
--- /dev/null
+++ b/package/firmware/ixp4xx-microcode/Makefile
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Copyright (C) 2007-2023 OpenWrt.org
+
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=ixp4xx-microcode
+PKG_VERSION:=2.4
+PKG_RELEASE:=1
+
+PKG_SOURCE:=IPL_ixp400NpeLibraryWithCrypto-2_4.zip
+PKG_SOURCE_URL:=http://downloads.openwrt.org/sources
+PKG_HASH:=1b1170d0657847248589d946048c0aeaa9cd671966fc5bec5933283309485eaa
+
+PKG_FLAGS:=nonshared
+
+include $(INCLUDE_DIR)/package.mk
+
+# Ethernet or WAN support, pick one
+define Package/ixp4xx-microcode-ethernet
+  SECTION:=firmware
+  CATEGORY:=Firmware
+  TITLE:=IXP4xx ethernet firmware
+  DEPENDS:=@TARGET_ixp4xx
+endef
+define Package/ixp4xx-microcode-wan
+  SECTION:=firmware
+  CATEGORY:=Firmware
+  TITLE:=IXP4xx WAN firmware
+  DEPENDS:=@TARGET_ixp4xx
+endef
+
+define Package/ixp4xx-microcode-ethernet/description
+ This package contains the microcode needed to use the network engines in
+ IXP4xx CPUs for ethernet on all three NPEs.
+endef
+define Package/ixp4xx-microcode-wan/description
+ This package contains the microcode needed to use the network engines in
+ IXP4xx CPUs for ethernet on NPE-A and NPE-B and WAN (HSS) on NPE-C.
+endef
+
+define Build/Prepare
+   rm -rf $(PKG_BUILD_DIR)
+   mkdir -p $(PKG_BUILD_DIR)
+   unzip -d $(PKG_BUILD_DIR)/ $(DL_DIR)/$(PKG_SOURCE)
+   mv $(PKG_BUILD_DIR)/ixp400_xscale_sw/src/npeDl/IxNpeMicrocode.c 
$(PKG_BUILD_DIR)/
+   rm -rf $(PKG_BUILD_DIR)/ixp400_xscale_sw
+   $(CP) ./src/* $(PKG_BUILD_DIR)/
+endef
+
+define Build/Compile
+   (cd $(PKG_BUILD_DIR); \
+   $(HOSTCC) -Wall -I$(STAGING_DIR_HOST)/include IxNpeMicrocode.c 
-o IxNpeMicrocode; \
+   ./IxNpeMicrocode -be \
+   )
+endef
+
+define Package/ixp4xx-microcode-ethernet/install
+   $(INSTALL_DIR) $(1)/lib/firmware
+   $(INSTALL_DIR) $(1)/usr/share/doc
+   $(INSTALL_BIN) $(PKG_BUILD_DIR)/NPE-A $(1)/lib/firmware/
+   $(INSTALL_BIN) $(PKG_BUILD_DIR)/NPE-B $(1)/lib/firmware/
+   $(INSTALL_BIN) $(PKG_BUILD_DIR)/NPE-C $(1)/lib/firmware/
+   $(INSTALL_DATA) $(PKG_BUILD_DIR)/LICENSE.IPL $(1)/usr/share/doc/
+endef
+define Package/ixp4xx-microcode-wan/install
+   $(INSTALL_DIR) $(1)/lib/firmware
+   $(INSTALL_DIR) $(1)/usr/share/doc
+   $(INSTALL_BIN) $(PKG_BUILD_DIR)/NPE-A-HSS $(1)/lib/firmware/
+   $(INSTALL_BIN) $(PKG_BUILD_DIR)/NPE-B $(1)/lib/firmware/
+   $(INSTALL_BIN) $(PKG_BUILD_DIR)/NPE-C $(1)/lib/firmware/
+   $(INSTALL_DATA) $(PKG_BUILD_DIR)/LICENSE.IPL $(1)/usr/share/doc/
+endef
+
+
+$(eval $(call BuildPackage,ixp4xx-microcode-ethernet))
+$(eval $(call BuildPackage,ixp4xx-microcode-wan))
diff --git a/package/firmware/ixp4xx-microcode/src/IxNpeMicrocode.h 
b/package/firmware/ixp4xx-microcode/src/IxNpeMicrocode.h
new file mode 100644
index ..4a843db104f9
--- /dev/null
+++ b/package/firmware/ixp4xx-microcode/src/IxNpeMicrocode.h
@@ -0,0 +1,148 @@
+/*
+ * IxNpeMicrocode.h - Headerfile for compiling the Intel microcode C file
+ *
+ * Copyright (C) 2006 Christian Hohnstaedt 
+ *
+ * This file is released under the GPLv2
+ *
+ *
+ * compile with
+ *
+ * gcc -Wall IxNpeMicrocode.c -o IxNpeMicrocode
+ *
+ * Executing the resulting binary on your build-host creates the
+ * "NPE-[ABC]." files containing the selected microcode
+ *
+ * fetch the IxNpeMicrocode.c from the Intel Access Library.
+ * It will include this header.
+ *
+ * select Images for every NPE from the following
+ * (used C++ comments for easy uncommenting )
+ */
+
+// #define 
IX_NPEDL_NPEIMAGE_NPEA_ETH_SPAN_MASK_FIREWALL_VLAN_QOS_HDR_CONV_EXTMIB
+// #define IX_NPEDL_NPEIMAGE_NPEA_ETH_SPAN_VLAN_QOS_HDR_CONV_EXTMIB
+// #define 
IX_NPEDL_NPEIMAGE_NPEA_ETH_LEARN_FILTER_SPAN_MASK_FIREWALL_VLAN_QOS_EXTMIB
+// #define IX_NPEDL_NPEIMAGE_NPEA_HSS_TSLOT_SWITCH
+#define IX_NPEDL_NPEIMAGE_NPEA_ETH_SPAN_FIREWALL_VLAN_QOS_HDR_CONV
+// #define IX_NPEDL_NPEIMAGE_NPEA_ETH_LEARN_FILTER_SPAN_FIREWALL_VLAN_QOS
+// #define IX_NPEDL_NPEIMAGE_NPEA_ETH_LEARN_FILTER_SPAN_FIREWALL
+#define IX_NPEDL_NPEIMAGE_NPEA_HSS_2_PORT
+// #define IX_NPEDL_NPEIMAGE_NPEA_DMA
+// #define IX_NPEDL_NPEIMAGE_NPEA_ATM_MPHY_12_PORT
+// #define IX_NPEDL_NPEIMAGE_NPEA_HSS0_ATM_M

[PATCH v3 01/10] boot/apex: Restore the APEX boot loader

2023-10-12 Thread Linus Walleij

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 v2->v3:
- Build APEX from git URL.
- Use the Build/InstallDev makerule to build the binaries
  like all other boot loader do.
- Add PKG_LICENSE and PKG_LICENSE_FILES
- Add DEPENDS on !IN_SDK
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 | 61 ++
 1 file changed, 61 insertions(+)

diff --git a/package/boot/apex/Makefile b/package/boot/apex/Makefile
new file mode 100644
index ..66a1b7667eb0
--- /dev/null
+++ b/package/boot/apex/Makefile
@@ -0,0 +1,61 @@
+# 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_PROTO:=git
+PKG_SOURCE_URL:=https://github.com/linusw/apex.git
+PKG_SOURCE_VERSION:=483e18aa133d5e25866570c29b124530b2d1e0d3
+PKG_MIRROR_HASH:=42230bb436f5590447ca55e8befb8927e6ea74c1e6953c043bbbef986c411704
+
+PKG_TARGETS:=bin
+PKG_FLAGS:=nonshared
+PKG_LICENSE:=GPL-2.0
+PKG_LICENSE_FILES:=COPYING
+
+include $(INCLUDE_DIR)/package.mk
+
+export GCC_HONOUR_COPTS=s
+
+define Package/apex
+  SECTION:=boot
+  CATEGORY:=Boot Loaders
+  DEPENDS:=@TARGET_ixp4xx @!IN_SDK
+  DEFAULT:=y
+  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 Build/InstallDev
+   $(INSTALL_DIR) $(STAGING_DIR_IMAGE)/apex
+   $(CP) $(PKG_BUILD_DIR)/out/*.bin $(STAGING_DIR_IMAGE)/apex
+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

[PATCH v3 00/10] Resurrect OpenWrt IXP4xx support

2023-10-12 Thread Linus Walleij

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 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 (10):
  boot/apex: Restore the APEX boot loader
  kernel: crypto: armeb build rules for lib-chacha20
  kernel: Add kmod-rtc-x1205
  kernel: Add kmod-rtc-r7301
  kernel: netdevices: Package AMD 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
  ixp4xx: Add hdparm script

 package/boot/apex/Makefile |  61 +
 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 |  17 ++
 package/kernel/linux/modules/netdevices.mk |  16 ++
 package/kernel/linux/modules/other.mk  |  31 +++
 target/linux/ixp4xx/Makefile   |  28 +++
 .../linux/ixp4xx/base-files/etc/board.d/02_network |  26 +++
 .../linux/ixp4xx/base-files/etc/board.d/03_hdparm  |  14 ++
 .../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 
 ...003-rtc-rtc7301-Support-byte-addressed-IO.patch |  93 
 ...ixp4xx-Add-USRobotics-USR8200-device-tree.patch | 260 +
 ...5-net-ixp4xx_eth-Support-changing-the-MTU.patch | 132 +++
 ...06-net-phy-amd-Support-the-Altima-AMI101L.patch |  82 +++
 ...dog-ixp4xx-Make-sure-restart-always-works.patch |  79 +++
 ...-ARM-dts-ixp4xx-Boot-NSLU2-from-harddrive.patch |  24 ++
 21 files changed, 1663 insertions(+)
---
base-commit: 66f6c20e45aa0eb2649d1e0552eab9e138e38601
change-id: 20230928-ixp4xx-a393c84d9468

Best regards,
-- 
Linus Walleij 


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v3 02/10] kernel: crypto: armeb build rules for lib-chacha20

2023-10-12 Thread Linus Walleij

The lib-chacha20 library is missing build rules for big endian
ARM, and since IXP4xx is big endian ARM we need those rules to
build for IXP4xx.

Suggested-by: Tomasz Maciej Nowak 
Signed-off-by: Linus Walleij 
---
ChangeLog v1->v3:
- New patch to fix build error.
---
 package/kernel/linux/modules/crypto.mk | 4 
 1 file changed, 4 insertions(+)

diff --git a/package/kernel/linux/modules/crypto.mk 
b/package/kernel/linux/modules/crypto.mk
index 501be4b0a02c..c0ccdaa3dfe6 100644
--- a/package/kernel/linux/modules/crypto.mk
+++ b/package/kernel/linux/modules/crypto.mk
@@ -523,6 +523,8 @@ define KernelPackage/crypto-lib-chacha20/arm
   FILES:=$(LINUX_DIR)/arch/arm/crypto/chacha-neon.ko
 endef
 
+KernelPackage/crypto-lib-chacha20/armeb=$(KernelPackage/crypto-lib-chacha20/arm)
+
 define KernelPackage/crypto-lib-chacha20/aarch64
   KCONFIG+=CONFIG_CRYPTO_CHACHA20_NEON
   FILES+=$(LINUX_DIR)/arch/arm64/crypto/chacha-neon.ko
@@ -616,6 +618,8 @@ define KernelPackage/crypto-lib-poly1305/arm
   FILES:=$(LINUX_DIR)/arch/arm/crypto/poly1305-arm.ko
 endef
 
+KernelPackage/crypto-lib-poly1305/armeb=$(KernelPackage/crypto-lib-poly1305/arm)
+
 define KernelPackage/crypto-lib-poly1305/aarch64
   KCONFIG+=CONFIG_CRYPTO_POLY1305_NEON
   FILES:=$(LINUX_DIR)/arch/arm64/crypto/poly1305-neon.ko

-- 
2.34.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v3 10/10] ixp4xx: Add hdparm script

2023-10-12 Thread Linus Walleij

This script will make sure to spin down harddrives on IXP4xx
NAS devices such as the NSLU2 and siblings after 1 minute
of inactivity.

Signed-off-by: Linus Walleij 
---
 target/linux/ixp4xx/base-files/etc/board.d/03_hdparm | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/target/linux/ixp4xx/base-files/etc/board.d/03_hdparm 
b/target/linux/ixp4xx/base-files/etc/board.d/03_hdparm
new file mode 100644
index ..27f2b760420e
--- /dev/null
+++ b/target/linux/ixp4xx/base-files/etc/board.d/03_hdparm
@@ -0,0 +1,14 @@
+# SPDX-License-Identifier: GPL-2.0-only
+# Spin down drives after one minute if inactive
+
+if [ ! -n "$(command -v hdparm)" ]; then
+   exit 0
+fi
+
+DISKS=$(find /dev/sd[a-z] 2>/dev/null)
+for DISK in $DISKS
+do
+   if [ -b $DISK ] ; then
+   hdparm -S 12 $DISK > /dev/null
+   fi
+done

-- 
2.34.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v3 05/10] kernel: netdevices: Package AMD PHY

2023-10-12 Thread Linus Walleij

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,amd)
+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

Re: Device Support Inquiry

2023-10-09 Thread Linus Walleij

On Mon, Oct 9, 2023 at 11:41 AM Nagumalla Venkata Uday Bhaskar
 wrote:

> Thank you for your response. I appreciate your guidance. I am interested
> in working on this and would like to get started. However, I'm not very
> experienced with hardware hacking, so I could use some more specific
> instructions or resources to help me get started.
>
> Could you provide more details on how to access the UART on this device
> or point me to any documentation or resources that might be useful for
> this task? Additionally, if there are any specific steps or precautions
> I should be aware of, I would greatly appreciate your insights.

We are always in shortage of developers so just get to it :)

Some electronics and soldering is needed. For this you need
support from local enthusiasts because people can't really help
with hands-on remotely.

Locating serial ports:
https://openwrt.org/docs/techref/hardware/port.serial
See section "Finding Serial Console".

Developing OpenWrt:
https://openwrt.org/docs/guide-developer/start

On the OFTC IRC network, there is the channel #openwrt-devel where
you can chat to get help with misc stuff.
https://openwrt.org/irc

Yours,
Linus Walleij

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Device Support Inquiry

2023-10-06 Thread Linus Walleij

On Fri, Oct 6, 2023 at 8:18 AM Nagumalla Venkata Uday Bhaskar via
openwrt-devel  wrote:

> Hardware Specifications:: SOC - RTL9310, CPU - 1000MHz, LX - 200MHz, DDR

That SoC is technically supported but definitely not that device,
would have been in this file:

target/linux/realtek/image/rtl931x.mk

If you're interested in the job, time to open the case, figure out the
UART and start hacking!

Yours,
Linus Walleij

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v6] bmips: bcm6368-enetsw: Bump max MTU

2023-10-04 Thread Linus Walleij

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 tc

[PATCH v5] bmips: bcm6368-enetsw: Bump max MTU

2023-10-04 Thread Linus Walleij

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 + \
 SK

[PATCH v4] bmips: bcm6368-enetsw: Bump max MTU

2023-10-03 Thread Linus Walleij

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 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.
---
 .../files/drivers/net/ethernet/broadcom/bcm6368-enetsw.c  | 8 +---
 1 file changed, 5 insertions(+), 3 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..879089a4a3c4 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,7 +22,9 @@
 #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)
@@ -1006,7 +1008,7 @@ static int bcm6368_enetsw_probe(struct platform_device 
*pdev)
dev_info(dev, "random mac\n");
}
 
-   priv->rx_buf_size = ALIGN(ndev-

[PATCH v3] bmips: bcm6368-enetsw: Bump max MTU

2023-10-02 Thread Linus Walleij

The max frame size for this ethernet switch is 1536 bytes, excluding the
VLAN headers, which is

1536 - VLAN_ETH_HLEN - VLAN_HLEN = 1536 - 18 - 4 = 1514

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.

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.

So when we ping with ping -s 1472 -M do 192.168.1.220
this first turns into a 1500 byte ICMP package, when it
reaches the Marvell switch it adds VLAN_ETH_HLEN + VLAN_HLEN
1500 + 18 + 4 = 1522 and then 6 more bytes for DSA tag ending up
with 1528 bytes. Then the Broadcom switch adds another DSA tag
of 8 bytes, resulting in 1536 bytes reaching Linux, the maximum.

tcpdump (on the target eth0) gives this confirming the suspicion:

00:05:03.678271 AF Unknown (1429722180), length 1532:
0x:  3d93 bcae c56b a83d 8874 02fd 0004 8100  =k.=.t..
0x0010:   dada  c000 0fff 0800 4500 05dc  E...
0x0020:   4000 4001 b146 c0a8 0189 c0a8 0101  ..@.@..F
0x0030:  0800 1fd0 0068 001f 7231 1b65    .h..r1.e
0x0040:  f6ef 0600   1011 1213 1415 1617  
0x0050:  1819 1a1b 1c1d 1e1f 2021 2223 2425 2627  .!"#$%&'
0x0060:  2829 2a2b 2c2d 2e2f 3031 3233 3435 3637  ()*+,-./01234567
0x0070:  3839 3a3b 3c3d 3e3f 4041 4243 4445 4647  89:;<=>?@ABCDEFG

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 1532 bytes and not 1536.

bcae c56b a83b = source ethernet address

8874 02fd 0004 = Broadcom enetsw DSA tag

8100  = VLAN 802.1Q header

dada  c000 0fff 0800 = EDSA tag for the Marvell (outer) switch,
 0800 is the ethertype obviously

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.

Tests with larger MTUs have not been successful so this is likely the actual
hardware max MTU.

Cc: Álvaro Fernández Rojas 
Cc: Jonas Gorski 
Signed-off-by: Linus Walleij 
---
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.
---
 .../files/drivers/net/ethernet/broadcom/bcm6368-enetsw.c | 5 +++--
 1 file changed, 3 insertions(+), 2 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..01e4723c176d 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,7 +22,8 @@
 #include 
 #include 
 
-/* MTU */
+/* The max frame size is 1536 including VLAN headers but excluding the 6 byte 
DSA tag */
+#define ENETSW_MAX_MTU (1536 - VLAN_ETH_HLEN - VLAN_HLEN)
 #define ENETSW_TAG_SIZE(6 + VLAN_HLEN)
 #define ENETSW_MTU_OVERHEAD(VLAN_ETH_HLEN + VLAN_HLEN + \
 ENETSW_TAG_SIZE)
@@ -1067,7 +1068,7 @@ static int bcm6368_enetsw_probe(struct platform_device 
*pdev)
ndev->netdev_ops = _enetsw_ops;
ndev->min_mtu = ETH_ZLEN;
ndev->mtu = ETH_DATA_LEN + ENETSW_TAG_SIZE;
-   ndev->max_mtu = ETH_DATA_LEN + ENETSW_TAG_SIZE;
+   ndev->max_mtu = ENETSW_MAX_MTU;
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(6,1,0)
netif_napi_add(ndev, >napi, bcm6368_enetsw_poll);
 #else
-- 
2.34.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH v2] bmips: bcm6368-enetsw: Bump max MTU

2023-10-02 Thread Linus Walleij

On Mon, Oct 2, 2023 at 12:25 AM Linus Walleij  wrote:

> Test with ping from host:
>
> PING 192.168.1.220 (192.168.1.220) 1472(1500) bytes of data.
> 1480 bytes from 192.168.1.220: icmp_seq=1 ttl=64 time=0.723 ms
> 1480 bytes from 192.168.1.220: icmp_seq=2 ttl=64 time=0.562 ms
> 1480 bytes from 192.168.1.220: icmp_seq=3 ttl=64 time=0.555 ms
>
> When this ping reaches the device, the Marvell switch adds 8 bytes of DSA 
> overhead,
> and the Broadcom enetsw adds 6 bytes, resulting in exactly 1514 bytes which 
> is what
> the switch can handle.

No wait this isn't correctly stated. I was too tired.

OpenWrt adds a VLAN to each port so we get VLAN tags on all frames.

So when I ping with ping -s 1472 -M do 192.168.1.220 (command missing)
this first turns into a 1500 byte ICMP package (as seen), when it
reaches the Marvell switch it adds VLAN_ETH_HLEN + VLAN_HLEN
1500 + 18 + 4 = 1522 and then 6 more bytes for DSA tag ending up
with 1528 bytes. Then the Broadcom switch adds another DSA tag
of 8 bytes, resulting in 1536 bytes reaching Linux, the maximum.

tcpdump (on the target) gives this confirming the suspicion:

00:05:03.678271 AF Unknown (1429722180), length 1532:
0x:  3d93 bcae c56b a83d 8874 02fd 0004 8100  =k.=.t..
0x0010:   dada  c000 0fff 0800 4500 05dc  E...
0x0020:   4000 4001 b146 c0a8 0189 c0a8 0101  ..@.@..F
0x0030:  0800 1fd0 0068 001f 7231 1b65    .h..r1.e
0x0040:  f6ef 0600   1011 1213 1415 1617  
0x0050:  1819 1a1b 1c1d 1e1f 2021 2223 2425 2627  .!"#$%&'
0x0060:  2829 2a2b 2c2d 2e2f 3031 3233 3435 3637  ()*+,-./01234567
0x0070:  3839 3a3b 3c3d 3e3f 4041 4243 4445 4647  89:;<=>?@ABCDEFG

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 1532 bytes and not 1536.

bcae c56b a83b = source ethernet address

8874 02fd 0004 = Broadcom enetsw DSA tag

8100  = VLAN 802.1Q header

dada  c000 0fff 0800 = EDSA tag for the Marvell (outer) switch,
 0800 is the ethertype obviously

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.

I will add this to the commit so it's clear how this works...

Yours,
Linus Walleij

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] bmips: bcm6368-enetsw: Bump max MTU to 1536

2023-10-01 Thread Linus Walleij

On Sun, Oct 1, 2023 at 10:55 PM Jonas Gorski  wrote:
> On Sun, 1 Oct 2023 at 22:40, Linus Walleij  wrote:
> >
> > The max MTU for this ethernet switch is 1536 bytes, not 1510 as it is
>
> The maximum *frame* size accepted is 1536 bytes, not MTU. A difference
> of 14 bytes.

Darn. I sent a new version which is tested and hopefully better.
Let's take it from there (it may have more/other bugs...)

Yours,
Linus Walleij

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v2] bmips: bcm6368-enetsw: Bump max MTU

2023-10-01 Thread Linus Walleij

The max frame size for this ethernet switch is 1536 bytes, excluding the
VLAN headers, which is

1536 - VLAN_ETH_HLEN - VLAN_HLEN = 1536 - 18 - 4 = 1514

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.

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.

Test with ping from host:

PING 192.168.1.220 (192.168.1.220) 1472(1500) bytes of data.
1480 bytes from 192.168.1.220: icmp_seq=1 ttl=64 time=0.723 ms
1480 bytes from 192.168.1.220: icmp_seq=2 ttl=64 time=0.562 ms
1480 bytes from 192.168.1.220: icmp_seq=3 ttl=64 time=0.555 ms

When this ping reaches the device, the Marvell switch adds 8 bytes of DSA 
overhead,
and the Broadcom enetsw adds 6 bytes, resulting in exactly 1514 bytes which is 
what
the switch can handle.

Tests with larger MTUs have not been successful so this is likely the actual
hardware max MTU.

Cc: Álvaro Fernández Rojas 
Cc: Jonas Gorski 
Signed-off-by: Linus Walleij 
---
ChangeLog v1->v2:
- Do some better research after help on IRC, did some ping tests.
---
 .../files/drivers/net/ethernet/broadcom/bcm6368-enetsw.c | 5 +++--
 1 file changed, 3 insertions(+), 2 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..01e4723c176d 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,7 +22,8 @@
 #include 
 #include 
 
-/* MTU */
+/* The max frame size is 1536 including VLAN headers but excluding the 6 byte 
DSA tag */
+#define ENETSW_MAX_MTU (1536 - VLAN_ETH_HLEN - VLAN_HLEN)
 #define ENETSW_TAG_SIZE(6 + VLAN_HLEN)
 #define ENETSW_MTU_OVERHEAD(VLAN_ETH_HLEN + VLAN_HLEN + \
 ENETSW_TAG_SIZE)
@@ -1067,7 +1068,7 @@ static int bcm6368_enetsw_probe(struct platform_device 
*pdev)
ndev->netdev_ops = _enetsw_ops;
ndev->min_mtu = ETH_ZLEN;
ndev->mtu = ETH_DATA_LEN + ENETSW_TAG_SIZE;
-   ndev->max_mtu = ETH_DATA_LEN + ENETSW_TAG_SIZE;
+   ndev->max_mtu = ENETSW_MAX_MTU;
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(6,1,0)
netif_napi_add(ndev, >napi, bcm6368_enetsw_poll);
 #else
-- 
2.34.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] bmips: bcm6368-enetsw: Bump max MTU to 1536

2023-10-01 Thread Linus Walleij

The max MTU for this ethernet switch is 1536 bytes, not 1510 as it is
right now. The available overhead is needed when using the DSA switch with
a cascaded DSA switch, which is something that exist in real products,
in this case the Inteno XG6846.

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

After this patch the error is gone.

Cc: Álvaro Fernández Rojas 
Cc: Jonas Gorski 
Signed-off-by: Linus Walleij 
---
 .../bmips/files/drivers/net/ethernet/broadcom/bcm6368-enetsw.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

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..96f4c303a433 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
@@ -24,6 +24,7 @@
 
 /* MTU */
 #define ENETSW_TAG_SIZE(6 + VLAN_HLEN)
+#define ENETSW_MAX_MTU 1536
 #define ENETSW_MTU_OVERHEAD(VLAN_ETH_HLEN + VLAN_HLEN + \
 ENETSW_TAG_SIZE)
 #define ENETSW_FRAG_SIZE(x)(SKB_DATA_ALIGN(NET_SKB_PAD + x + \
@@ -1067,7 +1068,7 @@ static int bcm6368_enetsw_probe(struct platform_device 
*pdev)
ndev->netdev_ops = _enetsw_ops;
ndev->min_mtu = ETH_ZLEN;
ndev->mtu = ETH_DATA_LEN + ENETSW_TAG_SIZE;
-   ndev->max_mtu = ETH_DATA_LEN + ENETSW_TAG_SIZE;
+   ndev->max_mtu = ENETSW_MAX_MTU;
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(6,1,0)
netif_napi_add(ndev, >napi, bcm6368_enetsw_poll);
 #else
-- 
2.34.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] bcm53xx: Unconditionally build U-Boot for DIR-890L

2023-09-30 Thread Linus Walleij

On Sat, Sep 2, 2023 at 6:33 PM Linus Walleij  wrote:

> Building the DIR-890L image requires U-Boot to be built
> so list it as a device package.
>
> Reported-by: Arınç ÜNAL 
> Signed-off-by: Linus Walleij 

Scratch this, Rani has made a proper solution to the problem, see:
https://github.com/openwrt/openwrt/pull/13577

Please review/merge.

Yours,
Linus Walleij

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] gemini: Drop kernel v5.15 and default to v6.1

2023-09-28 Thread Linus Walleij

There is no point in keeping the v5.15 kernel around for Gemini,
we are maintaining the platform with a strong upstream focus and
newer is always better.

Now that OpenWrt can support pure v6.1 kernels, switch up to
v6.1 and drop v5.15 so we don't need to migrate configs and
patches for no reason.

The USB FOTG2 module handling can be simplified as a result.

Signed-off-by: Linus Walleij 
---
 target/linux/gemini/Makefile   |   3 +-
 target/linux/gemini/config-5.15| 420 -
 target/linux/gemini/modules.mk |   7 +-
 ...b-host-fotg2-add-Gemini-specific-handling.patch | 131 ---
 ...gment-DIR-685-partition-table-for-OpenWrt.patch |  37 --
 5 files changed, 3 insertions(+), 595 deletions(-)

diff --git a/target/linux/gemini/Makefile b/target/linux/gemini/Makefile
index 284d1247cb23..b7f1962c9a59 100644
--- a/target/linux/gemini/Makefile
+++ b/target/linux/gemini/Makefile
@@ -11,8 +11,7 @@ FEATURES:=squashfs pci rtc usb dt gpio display ext4 
rootfs-part boot-part
 CPU_TYPE:=fa526
 SUBTARGETS:=generic
 
-KERNEL_PATCHVER:=5.15
-KERNEL_TESTING_PATCHVER:=6.1
+KERNEL_PATCHVER:=6.1
 
 define Target/Description
Build firmware images for the StorLink/Cortina Gemini CS351x ARM FA526 
CPU
diff --git a/target/linux/gemini/config-5.15 b/target/linux/gemini/config-5.15
deleted file mode 100644
index b0c3afbf9db6..
--- a/target/linux/gemini/config-5.15
+++ /dev/null
@@ -1,420 +0,0 @@
-CONFIG_ALIGNMENT_TRAP=y
-CONFIG_AMBA_PL08X=y
-CONFIG_ARCH_32BIT_OFF_T=y
-CONFIG_ARCH_GEMINI=y
-CONFIG_ARCH_KEEP_MEMBLOCK=y
-CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y
-# CONFIG_ARCH_MOXART is not set
-CONFIG_ARCH_MULTIPLATFORM=y
-CONFIG_ARCH_MULTI_V4=y
-# CONFIG_ARCH_MULTI_V4T is not set
-CONFIG_ARCH_MULTI_V4_V5=y
-# CONFIG_ARCH_MULTI_V5 is not set
-CONFIG_ARCH_NR_GPIO=0
-CONFIG_ARCH_OPTIONAL_KERNEL_RWX=y
-CONFIG_ARCH_SELECT_MEMORY_MODEL=y
-CONFIG_ARCH_SPARSEMEM_ENABLE=y
-CONFIG_ARM=y
-CONFIG_ARM_AMBA=y
-CONFIG_ARM_APPENDED_DTB=y
-# CONFIG_ARM_ATAG_DTB_COMPAT is not set
-CONFIG_ARM_CRYPTO=y
-CONFIG_ARM_HAS_SG_CHAIN=y
-CONFIG_ARM_L1_CACHE_SHIFT=5
-CONFIG_ARM_PATCH_PHYS_VIRT=y
-# CONFIG_ARM_SMMU is not set
-CONFIG_ARM_UNWIND=y
-CONFIG_ATA=y
-CONFIG_ATAGS=y
-CONFIG_ATA_FORCE=y
-CONFIG_ATA_VERBOSE_ERROR=y
-CONFIG_AUTO_ZRELADDR=y
-CONFIG_BINFMT_FLAT_ARGVP_ENVP_ON_STACK=y
-CONFIG_BLK_DEV_SD=y
-CONFIG_BLK_MQ_PCI=y
-CONFIG_BLK_PM=y
-CONFIG_BOUNCE=y
-CONFIG_CLKSRC_MMIO=y
-CONFIG_CLONE_BACKWARDS=y
-CONFIG_CMA=y
-CONFIG_CMA_ALIGNMENT=8
-CONFIG_CMA_AREAS=7
-# CONFIG_CMA_DEBUG is not set
-# CONFIG_CMA_DEBUGFS is not set
-CONFIG_CMA_SIZE_PERCENTAGE=10
-# CONFIG_CMA_SIZE_SEL_MAX is not set
-# CONFIG_CMA_SIZE_SEL_MBYTES is not set
-# CONFIG_CMA_SIZE_SEL_MIN is not set
-CONFIG_CMA_SIZE_SEL_PERCENTAGE=y
-# CONFIG_CMA_SYSFS is not set
-CONFIG_COMMON_CLK=y
-CONFIG_COMMON_CLK_GEMINI=y
-CONFIG_COMPAT_32BIT_TIME=y
-CONFIG_CONSOLE_TRANSLATIONS=y
-CONFIG_CONTIG_ALLOC=y
-CONFIG_COREDUMP=y
-CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
-CONFIG_CPU_32v4=y
-CONFIG_CPU_ABRT_EV4=y
-CONFIG_CPU_CACHE_FA=y
-CONFIG_CPU_CACHE_VIVT=y
-CONFIG_CPU_COPY_FA=y
-CONFIG_CPU_CP15=y
-CONFIG_CPU_CP15_MMU=y
-# CONFIG_CPU_DCACHE_WRITETHROUGH is not set
-CONFIG_CPU_FA526=y
-CONFIG_CPU_NO_EFFICIENT_FFS=y
-CONFIG_CPU_PABRT_LEGACY=y
-CONFIG_CPU_THERMAL=y
-CONFIG_CPU_TLB_FA=y
-CONFIG_CPU_USE_DOMAINS=y
-CONFIG_CRASH_CORE=y
-CONFIG_CRC16=y
-# CONFIG_CRC32_SARWATE is not set
-CONFIG_CRC32_SLICEBY8=y
-CONFIG_CRC_CCITT=y
-CONFIG_CRC_ITU_T=y
-CONFIG_CROSS_MEMORY_ATTACH=y
-CONFIG_CRYPTO_CMAC=y
-CONFIG_CRYPTO_CRC32C=y
-CONFIG_CRYPTO_DES=y
-CONFIG_CRYPTO_DEV_SL3516=y
-# CONFIG_CRYPTO_DEV_SL3516_DEBUG is not set
-CONFIG_CRYPTO_DRBG=y
-CONFIG_CRYPTO_DRBG_HMAC=y
-CONFIG_CRYPTO_DRBG_MENU=y
-CONFIG_CRYPTO_ECB=y
-CONFIG_CRYPTO_ECHAINIV=y
-CONFIG_CRYPTO_ENGINE=y
-CONFIG_CRYPTO_HMAC=y
-CONFIG_CRYPTO_HW=y
-CONFIG_CRYPTO_JITTERENTROPY=y
-CONFIG_CRYPTO_LIB_BLAKE2S_GENERIC=y
-CONFIG_CRYPTO_LIB_DES=y
-CONFIG_CRYPTO_LIB_SHA256=y
-CONFIG_CRYPTO_MD4=y
-CONFIG_CRYPTO_MD5=y
-CONFIG_CRYPTO_RNG=y
-CONFIG_CRYPTO_RNG2=y
-CONFIG_CRYPTO_RNG_DEFAULT=y
-CONFIG_CRYPTO_SEQIV=y
-CONFIG_CRYPTO_SHA256=y
-CONFIG_CRYPTO_SHA512=y
-CONFIG_DEBUG_BUGVERBOSE=y
-CONFIG_DEBUG_LL_INCLUDE="mach/debug-macro.S"
-CONFIG_DEBUG_MEMORY_INIT=y
-CONFIG_DECOMPRESS_BZIP2=y
-CONFIG_DECOMPRESS_GZIP=y
-CONFIG_DECOMPRESS_LZ4=y
-CONFIG_DECOMPRESS_LZMA=y
-CONFIG_DECOMPRESS_LZO=y
-CONFIG_DECOMPRESS_XZ=y
-CONFIG_DMADEVICES=y
-CONFIG_DMATEST=y
-CONFIG_DMA_CMA=y
-CONFIG_DMA_ENGINE=y
-CONFIG_DMA_ENGINE_RAID=y
-CONFIG_DMA_OF=y
-CONFIG_DMA_OPS=y
-CONFIG_DMA_REMAP=y
-CONFIG_DMA_SHARED_BUFFER=y
-CONFIG_DMA_VIRTUAL_CHANNELS=y
-CONFIG_DRM=y
-CONFIG_DRM_BRIDGE=y
-CONFIG_DRM_FBDEV_EMULATION=y
-CONFIG_DRM_FBDEV_OVERALLOC=100
-CONFIG_DRM_GEM_CMA_HELPER=y
-CONFIG_DRM_KMS_CMA_HELPER=y
-CONFIG_DRM_KMS_HELPER=y
-CONFIG_DRM_PANEL=y
-CONFIG_DRM_PANEL_BRIDGE=y
-CONFIG_DRM_PANEL_ILITEK_IL9322=y
-CONFIG_DRM_PANEL_ORIENTATION_QUIRKS=y
-CONFIG_DRM_TVE200=y
-CONFIG_DTC=y
-CONFIG_DUMMY

[PATCH v2 9/9] ixp4xx: Add USRobotics USR8200 support

2023-09-28 Thread Linus Walleij

This brings back USRobotics USR8200 support to the IXP4xx
target.

Signed-off-by: Linus Walleij 
---
 .../linux/ixp4xx/base-files/etc/board.d/02_network |   5 +
 target/linux/ixp4xx/config-6.1 |   1 +
 target/linux/ixp4xx/image/Makefile |  14 ++
 ...p4xx-Handle-clock-output-on-pin-14-and-15.patch |  98 
 ...003-rtc-rtc7301-Support-byte-addressed-IO.patch |  93 +++
 ...ixp4xx-Add-USRobotics-USR8200-device-tree.patch | 268 +
 ...5-net-ixp4xx_eth-Support-changing-the-MTU.patch | 135 +++
 ...06-net-phy-amd-Support-the-Altima-AMI101L.patch |  89 +++
 ...dog-ixp4xx-Make-sure-restart-always-works.patch |  84 +++
 9 files changed, 787 insertions(+)

diff --git a/target/linux/ixp4xx/base-files/etc/board.d/02_network 
b/target/linux/ixp4xx/base-files/etc/board.d/02_network
index 45d7cbc75a4a..864328d6bcf1 100644
--- a/target/linux/ixp4xx/base-files/etc/board.d/02_network
+++ b/target/linux/ixp4xx/base-files/etc/board.d/02_network
@@ -11,6 +11,11 @@ gateworks,gw2358)
 linksys,nslu2)
ucidef_set_interface_lan "eth0" "dhcp"
;;
+usr,usr8200)
+   # LAN ports connected to eth1 thru the MV88E6060 DSA switch
+   ucidef_set_interface "eth" device "eth1" protocol "none"
+   ucidef_set_interfaces_lan_wan "lan1 lan2 lan3 lan4" "eth0"
+   ;;
 *)
ucidef_set_interface_lan "eth0" "dhcp"
;;
diff --git a/target/linux/ixp4xx/config-6.1 b/target/linux/ixp4xx/config-6.1
index 3b47385d6b8d..4c4aa11969ea 100644
--- a/target/linux/ixp4xx/config-6.1
+++ b/target/linux/ixp4xx/config-6.1
@@ -1,4 +1,5 @@
 CONFIG_ALIGNMENT_TRAP=y
+CONFIG_AMD_PHY=y
 CONFIG_ARCH_32BIT_OFF_T=y
 CONFIG_ARCH_HIBERNATION_POSSIBLE=y
 CONFIG_ARCH_IXP4XX=y
diff --git a/target/linux/ixp4xx/image/Makefile 
b/target/linux/ixp4xx/image/Makefile
index d61189d09b24..4caf20ded88d 100644
--- a/target/linux/ixp4xx/image/Makefile
+++ b/target/linux/ixp4xx/image/Makefile
@@ -62,6 +62,7 @@ TARGET_DEVICES += cambria
 define Device/nslu2
DEVICE_VENDOR := Linksys
DEVICE_MODEL := NSLU2
+   # USB2 is compiled in and needs no package
DEVICE_PACKAGES := apex ixp4xx-microcode-ethernet kmod-rtc-x1205
# Only 32 MB of RAM so not building by default
DEFAULT := n
@@ -73,4 +74,17 @@ define Device/nslu2
 endef
 TARGET_DEVICES += nslu2
 
+define Device/usr8200
+   DEVICE_VENDOR := USRobotics
+   DEVICE_MODEL := USR8200
+   # USB2 is compiled in and needs no package
+   DEVICE_PACKAGES := ixp4xx-microcode-ethernet kmod-rtc-r7301 
kmod-firewire kmod-firewire-ohci
+   DEVICE_DTS := intel-ixp42x-usrobotics-usr8200
+   KERNEL := kernel-bin | append-dtb
+   IMAGES := kernel.bin rootfs.bin
+   IMAGE/kernel.bin := append-kernel
+   IMAGE/rootfs.bin := append-rootfs | pad-rootfs | pad-to 128k
+endef
+TARGET_DEVICES += usr8200
+
 $(eval $(call BuildImage))
diff --git 
a/target/linux/ixp4xx/patches-6.1/0002-gpio-ixp4xx-Handle-clock-output-on-pin-14-and-15.patch
 
b/target/linux/ixp4xx/patches-6.1/0002-gpio-ixp4xx-Handle-clock-output-on-pin-14-and-15.patch
new file mode 100644
index ..78a3df0ab1f3
--- /dev/null
+++ 
b/target/linux/ixp4xx/patches-6.1/0002-gpio-ixp4xx-Handle-clock-output-on-pin-14-and-15.patch
@@ -0,0 +1,98 @@
+From fc58944733a2082e3290eda240eb3247a00ad73a Mon Sep 17 00:00:00 2001
+From: Linus Walleij 
+Date: Thu, 21 Sep 2023 00:12:42 +0200
+Subject: [PATCH] gpio: ixp4xx: Handle clock output on pin 14 and 15
+
+This makes it possible to provide basic clock output on pins
+14 and 15. The clocks are typically used by random electronics,
+not modeled in the device tree, so they just need to be provided
+on request.
+
+In order to not disturb old systems that require that the
+hardware defaults are kept in the clock setting bits, we only
+manipulate these if either device tree property is present.
+Once we know a device needs one of the clocks we can set it
+in the device tree.
+
+Signed-off-by: Linus Walleij 
+---
+ drivers/gpio/gpio-ixp4xx.c | 49 +-
+ 1 file changed, 48 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/gpio/gpio-ixp4xx.c b/drivers/gpio/gpio-ixp4xx.c
+index dde6cf3a5779..1ca3217d0aab 100644
+--- a/drivers/gpio/gpio-ixp4xx.c
 b/drivers/gpio/gpio-ixp4xx.c
+@@ -38,6 +38,18 @@
+ #define IXP4XX_GPIO_STYLE_MASKGENMASK(2, 0)
+ #define IXP4XX_GPIO_STYLE_SIZE3
+ 
++/*
++ * Clock output control register defines.
++ */
++#define IXP4XX_GPCLK_CLK0DC_SHIFT 0
++#define IXP4XX_GPCLK_CLK0TC_SHIFT 4
++#define IXP4XX_GPCLK_CLK0_MASKGENMASK(7, 0)
++#define IXP4XX_GPCLK_MUX14BIT(8)
++#define IXP4XX_GPCLK_CLK1DC_SHIFT 16
++#define IXP4XX_GPCLK_CLK1TC_SHIFT 20
++#define IXP4XX_GPCLK_CLK1_MASKGENMASK(23, 16)
++#define IXP4XX_GPCLK_MUX15BIT(24)

[PATCH v2 5/9] ixp4xx: Resurrect IXP4xx support using device tree

2023-09-28 Thread Linus Walleij

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/

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/package/firmware/ixp4xx-microcode/Makefile 
b/package/firmware/ixp4xx-microcode/Makefile
new file mode 100644
index ..5ee04a757a2c
--- /dev/null
+++ b/package/firmware/ixp4xx-microcode/Makefile
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Copyright (C) 2007-2023 OpenWrt.org
+
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=ixp4xx-microcode
+PKG_VERSION:=2.4
+PKG_RELEASE:=1
+
+PKG_SOURCE:=IPL_ixp400NpeLibraryWithCrypto-2_4.zip
+PKG_SOURCE_URL:=http://downloads.openwrt.org/sources
+PKG_HASH:=1b1170d0657847248589d946048c0aeaa9cd671966fc5bec5933283309485eaa
+
+PKG_FLAGS:=nonshared
+
+include $(INCLUDE_DIR)/package.mk
+
+# Ethernet or WAN support, pick one
+define Package/ixp4xx-microcode-ethernet
+  SECTION:=firmware
+  CATEGORY:=Firmware
+  TITLE:=IXP4xx ethernet firmware
+  DEPENDS:=@TARGET_ixp4xx
+endef
+define Package/ixp4xx-microcode-wan
+  SECTION:=firmware
+  CATEGORY:=Firmware
+  TITLE:=IXP4xx WAN firmware
+  DEPENDS:=@TARGET_ixp4xx
+endef
+
+define Package/ixp4xx-microcode-ethernet/description
+ This package contains the microcode needed to use the network engines in
+ IXP4xx CPUs for ethernet on all three NPEs.
+endef
+define Package/ixp4xx-microcode-wan/description
+ This package contains the microcode needed to use the network engines in
+ IXP4xx CPUs for ethernet on NPE-A and NPE-B and WAN (HSS) on NPE-C.
+endef
+
+define Build/Prepare
+   rm -rf $(PKG_BUILD_DIR)
+   mkdir -p $(PKG_BUILD_DIR)
+   unzip -d $(PKG_BUILD_DIR)/ $(DL_DIR)/$(PKG_SOURCE)
+   mv $(PKG_BUILD_DIR)/ixp400_xscale_sw/src/npeDl/IxNpeMicrocode.c 
$(PKG_BUILD_DIR)/
+   rm -rf $(PKG_BUILD_DIR)/ixp400_xscale_sw
+   $(CP) ./src/* $(PKG_BUILD_DIR)/
+endef
+
+define Build/Compile
+   (cd $(PKG_BUILD_DIR); \
+   $(HOSTCC) -Wall -I$(STAGING_DIR_HOST)/include IxNpeMicrocode.c 
-o IxNpeMicrocode; \
+   ./IxNpeMicrocode -be \
+   )
+endef
+
+define Package/ixp4xx-microcode-ethernet/install
+   $(INSTALL_DIR) $(1)/lib/firmware
+   $(INSTALL_DIR) $(1)/usr/share/doc
+   $(INSTALL_BIN) $(PKG_BUILD_DIR)/NPE-A $(1)/lib/firmware/
+   $(INSTALL_BIN) $(PKG_BUILD_DIR)/NPE-B $(1)/lib/firmware/
+   $(INSTALL_BIN) $(PKG_BUILD_DIR)/NPE-C $(1)/lib/firmware/
+   $(INSTALL_DATA) $(PKG_BUILD_DIR)/LICENSE.IPL $(1)/usr/share/doc/
+endef
+define Package/ixp4xx-microcode-wan/inst

[PATCH v2 6/9] ixp4xx: Add a ixp4xx hardware crypto kernel module

2023-09-28 Thread Linus Walleij

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)
+  $(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

[PATCH v2 3/9] kernel: Add kmod-rtc-r7301

2023-09-28 Thread Linus Walleij

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)
+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

[PATCH v2 4/9] kernel: netdevices: Package AMD PHY

2023-09-28 Thread Linus Walleij

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,amd)
+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

[PATCH v2 1/9] boot/apex: Restore the APEX boot loader

2023-09-28 Thread Linus Walleij

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
+  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

[PATCH v2 7/9] ixp4xx: Add hdparm script

2023-09-28 Thread Linus Walleij

This script will make sure to spin down harddrives on IXP4xx
NAS devices such as the NSLU2 and siblings after 1 minute
of inactivity.

Signed-off-by: Linus Walleij 
---
 target/linux/ixp4xx/base-files/etc/board.d/03_hdparm | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/target/linux/ixp4xx/base-files/etc/board.d/03_hdparm 
b/target/linux/ixp4xx/base-files/etc/board.d/03_hdparm
new file mode 100644
index ..27f2b760420e
--- /dev/null
+++ b/target/linux/ixp4xx/base-files/etc/board.d/03_hdparm
@@ -0,0 +1,14 @@
+# SPDX-License-Identifier: GPL-2.0-only
+# Spin down drives after one minute if inactive
+
+if [ ! -n "$(command -v hdparm)" ]; then
+   exit 0
+fi
+
+DISKS=$(find /dev/sd[a-z] 2>/dev/null)
+for DISK in $DISKS
+do
+   if [ -b $DISK ] ; then
+   hdparm -S 12 $DISK > /dev/null
+   fi
+done

-- 
2.34.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v2 2/9] kernel: Add kmod-rtc-x1205

2023-09-28 Thread Linus Walleij

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)
+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

[PATCH v2 8/9] Delete arm-magic script

2023-09-28 Thread Linus Walleij

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 
---
 scripts/arm-magic.sh | 42 --
 1 file changed, 42 deletions(-)

diff --git a/scripts/arm-magic.sh b/scripts/arm-magic.sh
deleted file mode 100755
index b4b0fa94f574..
--- a/scripts/arm-magic.sh
+++ /dev/null
@@ -1,42 +0,0 @@
-#!/bin/sh
-#
-#   Empty/wrong machtype-workaround generator
-#
-#   Copyright (C) 2006-2012 Imre Kaloz 
-#   based on linux/arch/arm/boot/compressed/head-xscale.S
-#
-#   This program is free software; you can redistribute it and/or modify
-#   it under the terms of the GNU General Public License as published by
-#   the Free Software Foundation; either version 2 of the License, or
-#   (at your option) any later version.
-#
-#   This program is distributed in the hope that it will be useful,
-#   but WITHOUT ANY WARRANTY; without even the implied warranty of
-#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-#   GNU General Public License for more details.
-#
-#   You should have received a copy of the GNU General Public License
-#   along with this program; if not, write to the Free Software
-#   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
-
-# NOTE: for now it's for only IXP4xx in big endian mode
-
-# list of supported boards, in "boardname machtypeid" format
-for board in "avila 526" "gateway7001 731" "nslu2 597" "nas100d 865" "wg302v1 
889" "wg302v2 890" "pronghorn 928" "pronghornmetro 1040" "compex 1273" 
"wrt300nv2 1077" "loft 849" "dsmg600 964" "fsg3 1091" "ap1000 1543" "tw2662 
1658" "tw5334 1664" "ixdpg425 604" "cambria 1468" "sidewinder 1041" "ap42x 4418"
-do
-  set -- $board
-  hexid=$(printf %x\\n $2)
-  if [ "$2" -lt "256" ]; then
-# we have a low machtypeid, we just need a "mov" (e3a)
-printf "\xe3\xa0\x10\x$hexid" > $BIN_DIR/$IMG_PREFIX-$1-zImage
-  else
-# we have a high machtypeid, we need a "mov" (e3a) and an "orr" (e38)
-if [ "$2" -lt "4096" ]; then
-  printf "\xe3\xa0\x10\x$(echo $hexid|cut -b "2 3")\xe3\x81\x1c\x$(echo 
$hexid|cut -b 1)" > $BIN_DIR/$IMG_PREFIX-$1-zImage
-else
-  printf "\xe3\xa0\x10\x$(echo $hexid|cut -b "3 4")\xe3\x81\x1c\x$(echo 
$hexid|cut -b "1 2")" > $BIN_DIR/$IMG_PREFIX-$1-zImage
-fi
-  fi
-# generate the image
-cat $BIN_DIR/$IMG_PREFIX-zImage >> $BIN_DIR/$IMG_PREFIX-$1-zImage
-done

-- 
2.34.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v2 0/9] Resurrect OpenWrt IXP4xx support

2023-09-28 Thread Linus Walleij

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?

Signed-off-by: Linus Walleij 
---
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 (9):
  boot/apex: Restore the APEX boot loader
  kernel: Add kmod-rtc-x1205
  kernel: Add kmod-rtc-r7301
  kernel: netdevices: Package AMD PHY
  ixp4xx: Resurrect IXP4xx support using device tree
  ixp4xx: Add a ixp4xx hardware crypto kernel module
  ixp4xx: Add hdparm script
  Delete arm-magic script
  ixp4xx: Add USRobotics USR8200 support

 package/boot/apex/Makefile |  55 +
 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 ++
 package/kernel/linux/modules/other.mk  |  31 +++
 scripts/arm-magic.sh   |  42 
 target/linux/ixp4xx/Makefile   |  28 +++
 .../linux/ixp4xx/base-files/etc/board.d/02_network |  26 ++
 .../linux/ixp4xx/base-files/etc/board.d/03_hdparm  |  14 ++
 .../base-files/lib/preinit/05_set_ether_mac_ixp4xx |  45 
 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 |  98 
 ...003-rtc-rtc7301-Support-byte-addressed-IO.patch |  93 +++
 ...ixp4xx-Add-USRobotics-USR8200-device-tree.patch | 268 +
 ...5-net-ixp4xx_eth-Support-changing-the-MTU.patch | 135 +++
 ...06-net-phy-amd-Support-the-Altima-AMI101L.patch |  89 +++
 ...dog-ixp4xx-Make-sure-restart-always-works.patch |  84 +++
 ...-ARM-dts-ixp4xx-Boot-NSLU2-from-harddrive.patch |  24 ++
 22 files changed, 1688 insertions(+), 42 deletions(-)
---
base-commit: 10867ec4bc170709f89595ec4c3a2c7d9a7b13d2
change-id: 20230928-ixp4xx-a393c84d9468

Best regards,
-- 
Linus Walleij 


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] bcm53xx: Unconditionally build U-Boot for DIR-890L

2023-09-05 Thread Linus Walleij

On Tue, Sep 5, 2023 at 10:27 AM Arınç ÜNAL  wrote:

> To make it clear, what needs fixing is making OpenWrt SDK not compile an
> image for the devices that are not selected on menuconfig.

You're right it does, that's really weird!
The BMIPS target doesn't behave like this at all.

Yours,
Linus Walleij

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] bcm53xx: Unconditionally build U-Boot for DIR-890L

2023-09-04 Thread Linus Walleij

On Mon, Sep 4, 2023 at 12:03 PM Rafał Miłecki  wrote:

> I don't see anything incorrect with Linus's original patch. Maybe we
> just have some dependency handling issue in u-boot generic .mk code?

I have transient problem with the dependencies at times, then
I just chose another target (entirely different!) in menuconfig and
then back to the intended target. Problem fixed, dependency
selected. It feels a bit shaky though, but usually all autobuilds
work fine.

Yours,
Linus Walleij

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH v3 3/5] bcm53xx: Add support for D-Link DIR-890L

2023-09-02 Thread Linus Walleij

On Sat, Sep 2, 2023 at 3:46 PM Arınç ÜNAL  wrote:

> > +# Outputs a lzma compressed U-Boot that start at 0x8000
> > +# just like the D-Link boot loaders expect
> > +define Build/dlink-uboot-bin
> > + $(STAGING_DIR_HOST)/bin/lzma e 
> > $(STAGING_DIR_IMAGE)/$(DEVICE_NAME)-u-boot.bin -d16 $@
> > +endef
>
> I see this patch is applied. $(STAGING_DIR_IMAGE)/$(DEVICE_NAME)-u-boot.bin
> won't be created unless PACKAGE_u-boot-dir-890l is enabled.

I'm sorry if I get anything wrong here, default-selecting packages
for targets isn't my strong game and sometime I don't know if I
can ever get it right ...

package/boot/uboot-bcm53xx/Makefile looks like this:

define U-Boot/dir-890l
  NAME:=D-Link DIR-890L
  BUILD_DEVICES:=dlink_dir-890l
endef

So my understanding of was BUILD_DEVICES that this will make
sure the package is built for the listed device(s) and thus
$(STAGING_DIR_IMAGE)/$(DEVICE_NAME)-u-boot.bin
will be there. But I guess it doesn't work as expected.

> For some
> reason, regardless of which device is selected on menuconfig, the OpenWrt
> SDK will compile an image for every device on the target. So if any device
> other than D-Link DIR-890L is selected on menuconfig,
> PACKAGE_u-boot-dir-890l won't be enabled. Therefore, the compilation
> process will fail while preparing an image for DIR-890L.

I suppose this oneliner is needed:

diff --git a/target/linux/bcm53xx/image/Makefile
b/target/linux/bcm53xx/image/Makefile
index 39b7efbef789..9483812facca 100644
--- a/target/linux/bcm53xx/image/Makefile
+++ b/target/linux/bcm53xx/image/Makefile
@@ -283,7 +283,7 @@ TARGET_DEVICES += dlink_dir-885l
 define Device/dlink_dir-890l
   DEVICE_VENDOR := D-Link
   DEVICE_MODEL := DIR-890L
-  DEVICE_PACKAGES := $(BRCMFMAC_43602A1) $(USB2_PACKAGES) $(USB3_PACKAGES)
+  DEVICE_PACKAGES := uboot-bcm53xx $(BRCMFMAC_43602A1)
$(USB2_PACKAGES) $(USB3_PACKAGES)
   # Layout: U-boot (128kb max) followed by kernel and appended DTB.
   # This is done because the boot loader will only read the first 2 MB
   # from the flash and decompress the LZMA it finds there after the

I sent a patch!

Yours,
Linus Walleij

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] bcm53xx: Unconditionally build U-Boot for DIR-890L

2023-09-02 Thread Linus Walleij

Building the DIR-890L image requires U-Boot to be built
so list it as a device package.

Reported-by: Arınç ÜNAL 
Signed-off-by: Linus Walleij 
---
Missed to enforce U-Boot build. Mea Culpa.
---
 target/linux/bcm53xx/image/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/bcm53xx/image/Makefile 
b/target/linux/bcm53xx/image/Makefile
index 39b7efbef789..9483812facca 100644
--- a/target/linux/bcm53xx/image/Makefile
+++ b/target/linux/bcm53xx/image/Makefile
@@ -283,7 +283,7 @@ TARGET_DEVICES += dlink_dir-885l
 define Device/dlink_dir-890l
   DEVICE_VENDOR := D-Link
   DEVICE_MODEL := DIR-890L
-  DEVICE_PACKAGES := $(BRCMFMAC_43602A1) $(USB2_PACKAGES) $(USB3_PACKAGES)
+  DEVICE_PACKAGES := uboot-bcm53xx $(BRCMFMAC_43602A1) $(USB2_PACKAGES) 
$(USB3_PACKAGES)
   # Layout: U-boot (128kb max) followed by kernel and appended DTB.
   # This is done because the boot loader will only read the first 2 MB
   # from the flash and decompress the LZMA it finds there after the

---
base-commit: 02214ab8dce59ee6b599f8dfdacb0297dc5dcc24
change-id: 20230902-bcm53xx-dir890l-fix-6fec290afa97

Best regards,
-- 
Linus Walleij 


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH v3 1/5] bcm53xx: Fix kernel v6.1 config

2023-08-28 Thread Linus Walleij

On Mon, Aug 28, 2023 at 8:10 AM Rafał Miłecki  wrote:
> On 19.06.2023 08:36, Linus Walleij wrote:
> > The v6.1 kernel does not build for me, building with -j1 V=s
> > reveals that it is prompting for a kernel config option.
> > I also needed to add CONFIG_MTD_SPLIT_FIRMWARE for splitting
> > to work.
> >
> > This make the v6.1 config work nicely as a baseline for my
> > DIR-890L patches.
> >
> > Signed-off-by: Linus Walleij 
>
> I've dropped MTD_SPLIT_FIRMWARE for bcm53xx years ago in the commit
> d3381b5a6401 ("bcm53xx: request Seama parser on DIR-885L directly").
>
> Is is really needed? Can you explain why? What device needs that
> semi-guess-based splitting of the "firmware" partition?

Just skip it for now, it was probably just a mistake during development.
I bet it works fine just like this.

Thanks for looking into this!

Yours,
Linus Walleij

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] kernel: add unset CONFIG_INPUT_IBM_PANEL symbol to config-6.1

2023-08-28 Thread Linus Walleij

On Sat, Aug 26, 2023 at 6:08 PM Rafał Miłecki  wrote:

> From: Rafał Miłecki 
>
> This symbol was added by commit 2e6f34faa7e0 ("Input: Add IBM Operation
> Panel driver") to v6.1. It depends on I2C so it's available to limited
> amount of targets. It needs to be specified thought to allow kernel
> configuration.
>
> For bcm53xx this fixes:
> IBM Operation Panel driver (INPUT_IBM_PANEL) [N/m/?] (NEW)
>
> Signed-off-by: Rafał Miłecki 

Reviewed-by: Linus Walleij 

Yours,
Linus Walleij

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH v3 5/5] bcm53xx: Add network configuration for DIR-890L

2023-08-20 Thread Linus Walleij

On Sun, Aug 20, 2023 at 4:17 PM Rafał Miłecki  wrote:
> pon., 19 cze 2023 o 08:39 Linus Walleij  napisał(a):
> > This adds the lan/wan default bridge config and also the MAC
> > NVRAM read-out for et2.
> >
> > DIR-885L was missing a default bridge config so I just added
> > that too while I was at it.
>
> Why do you need to handle D-Link devices individually at all? Your
> code seems to be identical to the default switch case "*)".

Oh right, I don't know what I was thinking.
Skip this patch!

Yours,
Linus Walleij

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH v1 2/5] ixp4xx: Resurrect IXP4xx support using device tree

2023-08-17 Thread Linus Walleij

Thanks for reviewing this Hauke!

I fixed most things, will post v2 as time permits.

On Fri, Aug 11, 2023 at 4:27 PM Hauke Mehrtens  wrote:

> Do you still have the fconfig tool which access something in /dev/ to
> get the mac addresses?

Yes it was one of the leftovers that just stayed around after the
removal of the unmaintained ixp4xx boardfile machines. So I
just select it from the top-level makefile and things work fine.

Another thing left behind was the python build script for NSLU2
images.

But I needed them so it's all good when we bring IXP4xx back.
(Please don't delete them...)

I deleted one minor useless script though (patch 5).

Yours,
Linus Walleij

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH v3 0/5] bcm53xx: Support D-Link DIR-890L

2023-08-08 Thread Linus Walleij

On Tue, Aug 1, 2023 at 10:20 AM Felix Baumann
 wrote:

> The overall problem is that not all patches are being looked at immediately 
> and
> then they are being forgotten about. Not enough reviewers, yes. :/
>
> I added some people to CC, that might be able to take a look at this. (mostly 
> because
> I know that they are working with broadcom devices)

Hm, lack of reviewers is a universal problem, but also lack of reviewers
who are also comitters. A lot of patches are simply applied without
review by maintainers who know what they are doing, and that is what
one has to do when the community isn't big enough.

In the Linux DRM community we solved it by liberally handing out
commit access. It works there.

I'm pretty sure I can handle commit access but I have no idea how that
is handled out in the OpenWrt community. Some level of trust I suppose.

Yours,
Linus Walleij

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] gemini: Fix up kernel v6.1 config

2023-08-07 Thread Linus Walleij

The v6.1 kernel has moved around the options for the RTL8366RB
DSA switch used in the DIR-685 so it was missing when building
the kernel. Fix it up by adding the right Kconfig options.

Signed-off-by: Linus Walleij 
---
 target/linux/gemini/config-6.1 | 4 
 1 file changed, 4 insertions(+)

diff --git a/target/linux/gemini/config-6.1 b/target/linux/gemini/config-6.1
index a4f2cba85124..09b7b97d1659 100644
--- a/target/linux/gemini/config-6.1
+++ b/target/linux/gemini/config-6.1
@@ -271,6 +271,10 @@ CONFIG_NEED_KUSER_HELPERS=y
 CONFIG_NEED_PER_CPU_KM=y
 CONFIG_NET_DEVLINK=y
 CONFIG_NET_DSA=y
+CONFIG_NET_DSA_REALTEK=y
+# CONFIG_NET_DSA_REALTEK_MDIO is not set
+# CONFIG_NET_DSA_REALTEK_RTL8365MB is not set
+CONFIG_NET_DSA_REALTEK_RTL8366RB=y
 CONFIG_NET_DSA_REALTEK_SMI=y
 CONFIG_NET_DSA_TAG_RTL4_A=y
 CONFIG_NET_NS=y
-- 
2.34.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 0/2] Initial support for the Inteno XG6846

2023-08-06 Thread Linus Walleij

We have this router booting fine from initramfs so we just
need to figure out how to fix the firmware format to reflash
the thing.

Let's upstream what we have so we can focus on the firmware
format.

Álvaro: you seem to be looking after bmips, could you merge
this?

Signed-off-by: Linus Walleij 
---
Linus Walleij (2):
  bmips: bcm6328: Compile in MV88E6XXX DSA support
  bmips: Add Inteno XG6846 target

 .../bcm6328/base-files/etc/board.d/02_network  |   3 +
 target/linux/bmips/bcm6328/config-5.15 |   6 +
 target/linux/bmips/bcm6328/config-6.1  |   6 +
 target/linux/bmips/dts/bcm6328-inteno-xg6846.dts   | 307 +
 target/linux/bmips/image/bcm6328.mk|  13 +
 5 files changed, 335 insertions(+)
---
base-commit: 7e7eb5312d7810084547bb54a4b6867c2da08182
change-id: 20230806-xg6846-91627c4d8182

Best regards,
-- 
Linus Walleij 


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 2/2] bmips: Add Inteno XG6846 target

2023-08-06 Thread Linus Walleij

This add a device tree and build options for the XG6846
switch/router to the BMIPS target.

Hardware:
 - SoC: Broadcom BCM6328
 - CPU: BMIPS4350 V7.5
 - RAM: 64 MB DDR
 - NOR Flash: 16 MB parallel (CFE and OS)
 - Ethernet LAN: 4x 1Gbit
 - Ethernet WAN: 2x 1Gbit, fiber and TP
 - Buttons: reset
 - LEDs: 7 or 8, power and USB LEDs are GPIO-based, the
   LAN LEDs are controlled by the Marvell DSA Switch.
 - USB: on some versions
 - UART: yes

It is possible to boot the initramfs version
openwrt-bmips-bcm6328-inteno_xg6846-initramfs.elf from
CFE by breaking the boot on the UART console and download
it from a TFTP server such as:
CFE> r 192.168.1.2:openwrt-bmips-bcm6328-inteno_xg6846-initramfs.elf

Installation to target flash is not yet possible because
the firmware format deviates from the Broadcom standard:
it is based on the standard format generated by the
"imagetag" tool, but some stuff is off and images don't flash
or boot so this needs further work. The Broadcom image creation
tool bcmImageBuilder has been patched to take a new command line
option such as this:
--image-version 4125XG6846_ITT12023725
then this ends up as a string at offset 142-191 in the BCM tag
normally used for "rsa-signature" and "information1". There
may be other differences as well. We will need to work on this.

This device is called a "managed ethernet switch" by the vendor
and "media converter" or "fiber modem" by some of the ISPs
using it: the main purpose is to convert fiber connections to
ethernet, most devices just act as switches bridging the
fiber SFP to ethernet TP.

The device has a Marvell MV88E6352 DSA switch managed by
a BCM6328 BMIPS SoC.

This port makes it possible to use the XG6846 to grab an IP
number from the fiber connection and use all four LAN
connections out, turning it into a proper router.

This support is based mostly on the observations by the people on
the forum thread "Help with Inteno XG6846" where users NPeca75,
mrhaav, systemcrash and csom helped out to reverse engineer the
device. Then I made it work on the BMIPS target, figured out
the two-level switch hierarchy and settings.

Link: https://forum.openwrt.org/t/help-with-inteno-xg6846/68276/14
Signed-off-by: Linus Walleij 
---
 .../bcm6328/base-files/etc/board.d/02_network  |   3 +
 target/linux/bmips/dts/bcm6328-inteno-xg6846.dts   | 307 +
 target/linux/bmips/image/bcm6328.mk|  13 +
 3 files changed, 323 insertions(+)

diff --git a/target/linux/bmips/bcm6328/base-files/etc/board.d/02_network 
b/target/linux/bmips/bcm6328/base-files/etc/board.d/02_network
index 391e38c4dcb9..5b908cd9677e 100644
--- a/target/linux/bmips/bcm6328/base-files/etc/board.d/02_network
+++ b/target/linux/bmips/bcm6328/base-files/etc/board.d/02_network
@@ -9,6 +9,9 @@ arcadyan,ar7516)
ucidef_set_bridge_device switch
ucidef_set_interfaces_lan_wan "lan1 lan2 lan3" "wan"
;;
+inteno,xg6846)
+   ucidef_set_interfaces_lan_wan "lan1 lan2 lan3 lan4" "wan ext1"
+   ;;
 comtrend,ar-5381u |\
 comtrend,ar-5387un |\
 nucom,r5010unv2)
diff --git a/target/linux/bmips/dts/bcm6328-inteno-xg6846.dts 
b/target/linux/bmips/dts/bcm6328-inteno-xg6846.dts
new file mode 100644
index ..cf1a4eecd4eb
--- /dev/null
+++ b/target/linux/bmips/dts/bcm6328-inteno-xg6846.dts
@@ -0,0 +1,307 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+
+/*
+ * Devicetree for the Inteno XG6846 router, mostly used as a
+ * media converter from fiber to twisted pair ethernet
+ * "fiber modem" in many households in Sweden. The Marvell
+ * switch has one of its ports connected to an SFP (Small Form
+ * Factor pluggable) optical fiber receiver, which is bridged
+ * to the twisted pair connector LAN1.
+ *
+ * This device tree is inspired by research from the OpenWrt
+ * and Sweclockers forums, including contributions from
+ * NPeca75, mrhaav and csom.
+ *
+ * Some devices have a USB type A host receptacle mounted,
+ * some do not.
+ */
+#include "bcm6328.dtsi"
+#include 
+#include 
+
+/ {
+   model = "Inteno XG6846";
+   compatible = "inteno,xg6846", "brcm,bcm6328";
+
+   /* OpenWrt-specific aliases */
+   aliases {
+   led-boot = _pwr_red;
+   led-failsafe = _pwr_red;
+   led-running = _pwr_green;
+   led-upgrade = _pwr_red;
+   };
+
+   chosen {
+   bootargs = "rootfstype=squashfs,jffs2 noinitrd 
console=ttyS0,115200";
+   stdout-path = "serial0:115200n8";
+   };
+
+   /*
+* This I2C port is connected to the SFP and reflects the EEPROM etc
+* inside the SFP module. If the module is not plugged in, consequently
+* nothing will be found on the bus.
+*/
+   i2c0: i2c-sfp {
+   compatible = "i

[PATCH 1/2] bmips: bcm6328: Compile in MV88E6XXX DSA support

2023-08-06 Thread Linus Walleij

The Inteno XG6846 is using an external MV88E6352 switch to
deal with a fiber connection. Compile in support for this DSA
switch to the BCM6328 target.

Signed-off-by: Linus Walleij 
---
 target/linux/bmips/bcm6328/config-5.15 | 6 ++
 target/linux/bmips/bcm6328/config-6.1  | 6 ++
 2 files changed, 12 insertions(+)

diff --git a/target/linux/bmips/bcm6328/config-5.15 
b/target/linux/bmips/bcm6328/config-5.15
index 1e7712ead69d..8780fd68f3e8 100644
--- a/target/linux/bmips/bcm6328/config-5.15
+++ b/target/linux/bmips/bcm6328/config-5.15
@@ -119,6 +119,7 @@ CONFIG_LIBFDT=y
 CONFIG_LOCK_DEBUGGING_SUPPORT=y
 CONFIG_LZO_COMPRESS=y
 CONFIG_LZO_DECOMPRESS=y
+CONFIG_MARVELL_PHY=y
 CONFIG_MDIO_BUS=y
 CONFIG_MDIO_BUS_MUX=y
 CONFIG_MDIO_BUS_MUX_BCM6368=y
@@ -169,10 +170,15 @@ CONFIG_MTD_UBI_WL_THRESHOLD=4096
 CONFIG_NEED_DMA_MAP_STATE=y
 CONFIG_NET_DEVLINK=y
 CONFIG_NET_DSA=y
+CONFIG_NET_DSA_MV88E6XXX=y
+CONFIG_NET_DSA_MV88E6XXX_PTP=y
 CONFIG_NET_DSA_TAG_BRCM=y
 CONFIG_NET_DSA_TAG_BRCM_COMMON=y
 CONFIG_NET_DSA_TAG_BRCM_LEGACY=y
 CONFIG_NET_DSA_TAG_BRCM_PREPEND=y
+CONFIG_NET_DSA_TAG_DSA_COMMON=y
+CONFIG_NET_DSA_TAG_DSA=y
+CONFIG_NET_DSA_TAG_EDSA=y
 CONFIG_NET_FLOW_LIMIT=y
 CONFIG_NET_SELFTESTS=y
 CONFIG_NET_SWITCHDEV=y
diff --git a/target/linux/bmips/bcm6328/config-6.1 
b/target/linux/bmips/bcm6328/config-6.1
index 5b33e932360f..ae3941f4d763 100644
--- a/target/linux/bmips/bcm6328/config-6.1
+++ b/target/linux/bmips/bcm6328/config-6.1
@@ -128,6 +128,7 @@ CONFIG_LIBFDT=y
 CONFIG_LOCK_DEBUGGING_SUPPORT=y
 CONFIG_LZO_COMPRESS=y
 CONFIG_LZO_DECOMPRESS=y
+CONFIG_MARVELL_PHY=y
 CONFIG_MDIO_BUS=y
 CONFIG_MDIO_BUS_MUX=y
 CONFIG_MDIO_BUS_MUX_BCM6368=y
@@ -177,10 +178,15 @@ CONFIG_MTD_UBI_WL_THRESHOLD=4096
 CONFIG_NEED_DMA_MAP_STATE=y
 CONFIG_NET_DEVLINK=y
 CONFIG_NET_DSA=y
+CONFIG_NET_DSA_MV88E6XXX=y
+CONFIG_NET_DSA_MV88E6XXX_PTP=y
 CONFIG_NET_DSA_TAG_BRCM=y
 CONFIG_NET_DSA_TAG_BRCM_COMMON=y
 CONFIG_NET_DSA_TAG_BRCM_LEGACY=y
 CONFIG_NET_DSA_TAG_BRCM_PREPEND=y
+CONFIG_NET_DSA_TAG_DSA_COMMON=y
+CONFIG_NET_DSA_TAG_DSA=y
+CONFIG_NET_DSA_TAG_EDSA=y
 CONFIG_NET_FLOW_LIMIT=y
 CONFIG_NET_SELFTESTS=y
 CONFIG_NET_SWITCHDEV=y

-- 
2.34.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH v3 0/5] bcm53xx: Support D-Link DIR-890L

2023-07-31 Thread Linus Walleij

On Mon, Jun 19, 2023 at 8:36 AM Linus Walleij  wrote:

> This adds support for the D-Link DIR-890L router.
>
> Linus Walleij (5):
>   bcm53xx: Fix kernel v6.1 config
>   uboot-bcm53xx: Add U-Boot for NorthStar BCM53xx
>   bcm53xx: Add support for D-Link DIR-890L
>   bcm53xx: dir885/dir890: Tag both partitions as SEAMA
>   bcm53xx: Add network configuration for DIR-890L

Hints on how to proceed with this?

Any problem with the patches?

I can also create a pull request on github if it helps?

Yours,
Linus Walleij

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH v1 0/5] Resurrect IXP4xx

2023-06-20 Thread Linus Walleij

On Tue, Jun 20, 2023 at 8:50 AM Raylynn Knight  wrote:
> > On Jun 19, 2023, at 7:31 AM, Linus Walleij  wrote:

> I see that the ADI Coyote was included, but not the ADI Pronghorn
> which actually has sufficient RAM (64MB) and flash (16MB) to run OpenWrt.
> I’ll be looking at using the ADI Coyote as a base to eventually create a pull
> request to get the ADI Pronghorn supported! I can also test the D-Link
>  DSM-G600 and Gateworks GW2348 support.

Thanks Raylynn!

It's nice to see that there is actually a bit of community here. I have the
Pronghorn board, but I don't know if it works, because as far as I can
see it appears that it needs a 48V (!) DC source and I just didn't have
any such in my stash.

If you make patches I can carry them in my series until v6.1 is mature
enough that we can merge the new IXP4xx support.

Yours,
Linus Walleij

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v1 2/5] ixp4xx: Resurrect IXP4xx support using device tree

2023-06-19 Thread Linus Walleij

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/

Signed-off-by: Linus Walleij 
---
 package/firmware/ixp4xx-microcode/Makefile|  59 +
 .../ixp4xx-microcode/src/IxNpeMicrocode.h | 148 +++
 .../firmware/ixp4xx-microcode/src/LICENSE.IPL |  27 ++
 target/linux/ixp4xx/Makefile  |  28 ++
 .../ixp4xx/base-files/etc/board.d/02_network  |  21 ++
 .../lib/preinit/05_set_ether_mac_ixp4xx   |  45 
 target/linux/ixp4xx/config-6.1| 246 ++
 target/linux/ixp4xx/image/Makefile|  73 ++
 ...d-cfi_cmdset_0001-Byte-swap-OTP-info.patch |  74 ++
 ...dts-ixp4xx-Boot-NSLU2-from-harddrive.patch |  24 ++
 10 files changed, 745 insertions(+)
 create mode 100644 package/firmware/ixp4xx-microcode/Makefile
 create mode 100644 package/firmware/ixp4xx-microcode/src/IxNpeMicrocode.h
 create mode 100644 package/firmware/ixp4xx-microcode/src/LICENSE.IPL
 create mode 100644 target/linux/ixp4xx/Makefile
 create mode 100644 target/linux/ixp4xx/base-files/etc/board.d/02_network
 create mode 100644 
target/linux/ixp4xx/base-files/lib/preinit/05_set_ether_mac_ixp4xx
 create mode 100644 target/linux/ixp4xx/config-6.1
 create mode 100644 target/linux/ixp4xx/image/Makefile
 create mode 100644 
target/linux/ixp4xx/patches-6.1/0001-mtd-cfi_cmdset_0001-Byte-swap-OTP-info.patch
 create mode 100644 
target/linux/ixp4xx/patches-6.1/301-ARM-dts-ixp4xx-Boot-NSLU2-from-harddrive.patch

diff --git a/package/firmware/ixp4xx-microcode/Makefile 
b/package/firmware/ixp4xx-microcode/Makefile
new file mode 100644
index ..78fedfd1aaf1
--- /dev/null
+++ b/package/firmware/ixp4xx-microcode/Makefile
@@ -0,0 +1,59 @@
+#
+# Copyright (C) 2007 OpenWrt.org
+#
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE for more information.
+#
+
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=ixp4xx-microcode
+PKG_VERSION:=2.4
+PKG_RELEASE:=2
+
+PKG_SOURCE:=IPL_ixp400NpeLibraryWithCrypto-2_4.zip
+PKG_SOURCE_URL:=http://downloads.openwrt.org/sources
+PKG_HASH:=1b1170d0657847248589d946048c0aeaa9cd671966fc5bec5933283309485eaa
+
+PKG_FLAGS:=nonshared
+
+include $(INCLUDE_DIR)/package.mk
+
+define Package/ixp4xx-microcode
+  SECTION:=net
+  CATEGORY:=Network
+  TITLE:=Microcode for the IXP4xx network engines
+  DEPENDS:=@TARGET_ixp4xx
+endef
+
+define Package/ixp4xx-microcode/description
+ This package contains the microcode needed to use the network engines in 
IXP4xx CPUs
+endef
+
+define Build/Prepare
+   rm -rf $(PKG_BUILD_DIR)
+   mkdir -p $(PKG_BUILD_DIR)
+   unzip -d $(PKG_BUILD_DIR)/ $(DL_DIR)/$(PKG_SOURCE)
+   mv $(PKG_BUILD_DIR)/ixp400_xscale_sw/src/npeDl/IxNpeMicrocode.c 
$(PKG_BUILD_DIR)/
+   rm -rf $(PKG_BUILD_DIR)/ixp400_xscale_sw
+   $(CP) ./src/* $(PKG_BUILD_DIR)/
+endef
+
+define Build/Compile
+   (cd $(PKG_BUILD_DIR); \
+   $(HOSTCC) -Wall -I$(STAGING_DIR_HOST)/include IxNpeMicrocode.c 
-o IxNpeMicrocode; \
+   ./IxNpeMicrocode -be \
+   )
+endef
+
+define Package/ixp4xx-microcode/install
+   $(INSTALL_DIR) $(1)/lib/firmware
+   $(INSTALL_DIR) $(1)/usr/share/doc
+   $(INSTALL_BIN) $(PKG_BUILD_DIR)/NPE-A $(1)/lib/firmware/
+   $(INSTALL_BIN) $(PKG_BUILD_DIR)/NPE-A-HSS $(1)/lib/firmware/
+   $(INSTALL_BIN) $(PKG_BUILD_DIR)/NPE-B $(1)/lib/firmware/
+   $(INSTALL_BIN) $(PKG_BUILD_DIR)/NPE-C $(1)/lib/firmware/
+   $(INSTALL_DATA) $(PKG_BUILD_DIR)/LICENSE.IPL $(1)/usr/share/doc/
+endef
+
+$(eval $(call BuildPackage,ixp4xx-microcode))
diff --git a/package/firmware/ixp4xx-microcode/src/IxNpeMicrocode.h 
b/package/firmware/ixp4xx-microcode/src/IxNpeMicrocode.h
new file mode 100644
index ..4a843db104f9
--- /dev/null
+++ b/package/firmware/ixp4xx-microcode/src/IxNpeMicrocode.h
@@ -0,0 +1,148 @@
+/*
+ * IxNpeMicrocode.h - Headerfile for compiling the Intel microcode C file
+ *
+ * Copyright (C) 2006 Christian Hohnstaedt 
+ *
+ * This file is released under the GPLv2
+ *
+ *
+ * compile with
+ *
+ * gcc -Wall IxNpeMicrocode.c -o IxNpeMicrocode
+ *
+ * Executing the resulting binary on your build-host creates the
+ * "NPE-[ABC].xxx

[PATCH v1 0/5] Resurrect IXP4xx

2023-06-19 Thread Linus Walleij

IXP4xx 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 not pretty well supported
using device tree and such.

With the switch to kernel v6.1, OpenWrt has the required
baseline to bring IXP4xx back.

I have heard that the v6.1 target can still not be used by
default, but let's start reviewing, so we can merge this
as soon as v6.1 builds are ripe!

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.

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 :)

I am pretty back any IXP4xx can be brought online with this,
they just need some time and focus. I will add more routers
as time permits.

Linus Walleij (5):
  boot/apex: Restore the APEX boot loader
  ixp4xx: Resurrect IXP4xx support using device tree
  ixp4xx: Add a ixp4xx hardware crypto kernel module
  ixp4xx: Add hdparm script
  Delete arm-magic script

 package/boot/apex/Makefile|  61 +
 package/firmware/ixp4xx-microcode/Makefile|  59 +
 .../ixp4xx-microcode/src/IxNpeMicrocode.h | 148 +++
 .../firmware/ixp4xx-microcode/src/LICENSE.IPL |  27 ++
 package/kernel/linux/modules/crypto.mk|  13 +
 scripts/arm-magic.sh  |  42 ---
 target/linux/ixp4xx/Makefile  |  29 +++
 .../ixp4xx/base-files/etc/board.d/02_network  |  21 ++
 .../ixp4xx/base-files/etc/board.d/03_hdparm   |  14 +
 .../lib/preinit/05_set_ether_mac_ixp4xx   |  45 
 target/linux/ixp4xx/config-6.1| 246 ++
 target/linux/ixp4xx/image/Makefile|  73 ++
 ...d-cfi_cmdset_0001-Byte-swap-OTP-info.patch |  74 ++
 ...dts-ixp4xx-Boot-NSLU2-from-harddrive.patch |  24 ++
 14 files changed, 834 insertions(+), 42 deletions(-)
 create mode 100644 package/boot/apex/Makefile
 create mode 100644 package/firmware/ixp4xx-microcode/Makefile
 create mode 100644 package/firmware/ixp4xx-microcode/src/IxNpeMicrocode.h
 create mode 100644 package/firmware/ixp4xx-microcode/src/LICENSE.IPL
 delete mode 100755 scripts/arm-magic.sh
 create mode 100644 target/linux/ixp4xx/Makefile
 create mode 100644 target/linux/ixp4xx/base-files/etc/board.d/02_network
 create mode 100644 target/linux/ixp4xx/base-files/etc/board.d/03_hdparm
 create mode 100644 
target/linux/ixp4xx/base-files/lib/preinit/05_set_ether_mac_ixp4xx
 create mode 100644 target/linux/ixp4xx/config-6.1
 create mode 100644 target/linux/ixp4xx/image/Makefile
 create mode 100644 
target/linux/ixp4xx/patches-6.1/0001-mtd-cfi_cmdset_0001-Byte-swap-OTP-info.patch
 create mode 100644 
target/linux/ixp4xx/patches-6.1/301-ARM-dts-ixp4xx-Boot-NSLU2-from-harddrive.patch

-- 
2.34.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 1/5] boot/apex: Restore the APEX boot loader

2023-06-19 Thread Linus Walleij

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 
---
 package/boot/apex/Makefile | 61 ++
 1 file changed, 61 insertions(+)
 create mode 100644 package/boot/apex/Makefile

diff --git a/package/boot/apex/Makefile b/package/boot/apex/Makefile
new file mode 100644
index ..f4ce5811b024
--- /dev/null
+++ b/package/boot/apex/Makefile
@@ -0,0 +1,61 @@
+# 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
+  DEFAULT:=y
+  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
+
+define Build/InstallDev
+   $(INSTALL_DIR) $(STAGING_DIR_IMAGE)
+   $(CP) $(PKG_BUILD_DIR)/out/*.bin $(STAGING_DIR_IMAGE)/
+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

[PATCH v1 3/5] ixp4xx: Add a ixp4xx hardware crypto kernel module

2023-06-19 Thread Linus Walleij

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 248b4d68f9e1..1c83f07330a5 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)
+  $(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 546964a6a876..080576beb237 100644
--- a/target/linux/ixp4xx/Makefile
+++ b/target/linux/ixp4xx/Makefile
@@ -22,6 +22,7 @@ include $(INCLUDE_DIR)/target.mk
 
 DEFAULT_PACKAGES += ixp4xx-microcode \
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

[PATCH v1 5/5] Delete arm-magic script

2023-06-19 Thread Linus Walleij

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 
---
 scripts/arm-magic.sh | 42 --
 1 file changed, 42 deletions(-)
 delete mode 100755 scripts/arm-magic.sh

diff --git a/scripts/arm-magic.sh b/scripts/arm-magic.sh
deleted file mode 100755
index b4b0fa94f574..
--- a/scripts/arm-magic.sh
+++ /dev/null
@@ -1,42 +0,0 @@
-#!/bin/sh
-#
-#   Empty/wrong machtype-workaround generator
-#
-#   Copyright (C) 2006-2012 Imre Kaloz 
-#   based on linux/arch/arm/boot/compressed/head-xscale.S
-#
-#   This program is free software; you can redistribute it and/or modify
-#   it under the terms of the GNU General Public License as published by
-#   the Free Software Foundation; either version 2 of the License, or
-#   (at your option) any later version.
-#
-#   This program is distributed in the hope that it will be useful,
-#   but WITHOUT ANY WARRANTY; without even the implied warranty of
-#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-#   GNU General Public License for more details.
-#
-#   You should have received a copy of the GNU General Public License
-#   along with this program; if not, write to the Free Software
-#   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
-
-# NOTE: for now it's for only IXP4xx in big endian mode
-
-# list of supported boards, in "boardname machtypeid" format
-for board in "avila 526" "gateway7001 731" "nslu2 597" "nas100d 865" "wg302v1 
889" "wg302v2 890" "pronghorn 928" "pronghornmetro 1040" "compex 1273" 
"wrt300nv2 1077" "loft 849" "dsmg600 964" "fsg3 1091" "ap1000 1543" "tw2662 
1658" "tw5334 1664" "ixdpg425 604" "cambria 1468" "sidewinder 1041" "ap42x 4418"
-do
-  set -- $board
-  hexid=$(printf %x\\n $2)
-  if [ "$2" -lt "256" ]; then
-# we have a low machtypeid, we just need a "mov" (e3a)
-printf "\xe3\xa0\x10\x$hexid" > $BIN_DIR/$IMG_PREFIX-$1-zImage
-  else
-# we have a high machtypeid, we need a "mov" (e3a) and an "orr" (e38)
-if [ "$2" -lt "4096" ]; then
-  printf "\xe3\xa0\x10\x$(echo $hexid|cut -b "2 3")\xe3\x81\x1c\x$(echo 
$hexid|cut -b 1)" > $BIN_DIR/$IMG_PREFIX-$1-zImage
-else
-  printf "\xe3\xa0\x10\x$(echo $hexid|cut -b "3 4")\xe3\x81\x1c\x$(echo 
$hexid|cut -b "1 2")" > $BIN_DIR/$IMG_PREFIX-$1-zImage
-fi
-  fi
-# generate the image
-cat $BIN_DIR/$IMG_PREFIX-zImage >> $BIN_DIR/$IMG_PREFIX-$1-zImage
-done
-- 
2.34.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v1 4/5] ixp4xx: Add hdparm script

2023-06-19 Thread Linus Walleij

This script will make sure to spin down harddrives on IXP4xx
NAS devices such as the NSLU2 and siblings after 1 minute
of inactivity.

Signed-off-by: Linus Walleij 
---
 .../linux/ixp4xx/base-files/etc/board.d/03_hdparm  | 14 ++
 1 file changed, 14 insertions(+)
 create mode 100644 target/linux/ixp4xx/base-files/etc/board.d/03_hdparm

diff --git a/target/linux/ixp4xx/base-files/etc/board.d/03_hdparm 
b/target/linux/ixp4xx/base-files/etc/board.d/03_hdparm
new file mode 100644
index ..27f2b760420e
--- /dev/null
+++ b/target/linux/ixp4xx/base-files/etc/board.d/03_hdparm
@@ -0,0 +1,14 @@
+# SPDX-License-Identifier: GPL-2.0-only
+# Spin down drives after one minute if inactive
+
+if [ ! -n "$(command -v hdparm)" ]; then
+   exit 0
+fi
+
+DISKS=$(find /dev/sd[a-z] 2>/dev/null)
+for DISK in $DISKS
+do
+   if [ -b $DISK ] ; then
+   hdparm -S 12 $DISK > /dev/null
+   fi
+done
-- 
2.34.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v3 2/5] uboot-bcm53xx: Add U-Boot for NorthStar BCM53xx

2023-06-19 Thread Linus Walleij

I recently added support for the NorthStar ARM BCM53xx SoCs
to the upstream U-Boot. This is a back port on top of the
2023.04 version already imported to OpenWrt with the 5 necessary
upstream patches.

This is needed to create a small U-Boot for the BCM53xx-based
D-Link DIR-890L and I think also the DIR-885L, so that a
recent (bigger) kernel can be loaded and executed from the
SEAMA partitions on these devices.

Signed-off-by: Linus Walleij 
---
ChangeLog v2->v3:
- Rebased on master
ChangeLog v1->v2:
- Rebased on master
---
 .github/labeler.yml   |   1 +
 package/boot/uboot-bcm53xx/Makefile   |  37 +
 ...0001-nand-brcmnand-add-iproc-support.patch | 199 ++
 ...nand_base-Handle-algorithm-selection.patch |  80 +++
 ...t-device-tree-for-Broadcom-Northstar.patch | 659 ++
 ...port-for-the-Broadcom-Northstar-SoCs.patch |  66 ++
 ...ard-Add-new-Broadcom-Northstar-board.patch | 372 ++
 7 files changed, 1414 insertions(+)
 create mode 100644 package/boot/uboot-bcm53xx/Makefile
 create mode 100644 
package/boot/uboot-bcm53xx/patches/0001-nand-brcmnand-add-iproc-support.patch
 create mode 100644 
package/boot/uboot-bcm53xx/patches/0002-mtd-rawnand-nand_base-Handle-algorithm-selection.patch
 create mode 100644 
package/boot/uboot-bcm53xx/patches/0003-arm-dts-Import-device-tree-for-Broadcom-Northstar.patch
 create mode 100644 
package/boot/uboot-bcm53xx/patches/0004-arm-Add-support-for-the-Broadcom-Northstar-SoCs.patch
 create mode 100644 
package/boot/uboot-bcm53xx/patches/0005-board-Add-new-Broadcom-Northstar-board.patch

diff --git a/.github/labeler.yml b/.github/labeler.yml
index e22f074604fe..c8f8466d4a61 100644
--- a/.github/labeler.yml
+++ b/.github/labeler.yml
@@ -25,6 +25,7 @@
   - "package/boot/uboot-bcm4908/**"
 "target/bcm53xx":
   - "target/linux/bcm53xx/**"
+  - "package/boot/uboot-bcm53xx/**"
 "target/bcm63xx":
   - "target/linux/bcm63xx/**"
   - "package/kernel/bcm63xx-cfe/**"
diff --git a/package/boot/uboot-bcm53xx/Makefile 
b/package/boot/uboot-bcm53xx/Makefile
new file mode 100644
index ..ab80b9608adc
--- /dev/null
+++ b/package/boot/uboot-bcm53xx/Makefile
@@ -0,0 +1,37 @@
+include $(TOPDIR)/rules.mk
+
+PKG_VERSION:=2023.04
+PKG_HASH:=e31cac91545ff41b71cec5d8c22afd695645cd6e2a442ccdacacd60534069341
+PKG_RELEASE:=$(AUTORELEASE)
+
+include $(INCLUDE_DIR)/u-boot.mk
+include $(INCLUDE_DIR)/package.mk
+
+define U-Boot/Default
+  BUILD_TARGET:=bcm53xx
+  BUILD_SUBTARGET:=generic
+  UBOOT_CONFIG:=bcmns
+  UBOOT_BOARD:=$(1)
+endef
+
+define U-Boot/dir-885l
+  NAME:=D-Link DIR-885L
+  BUILD_DEVICES:=dlink_dir-885l
+endef
+
+define U-Boot/dir-890l
+  NAME:=D-Link DIR-890L
+  BUILD_DEVICES:=dlink_dir-890l
+endef
+
+UBOOT_TARGETS := dir-885l dir-890l
+
+define Build/InstallDev
+   $(INSTALL_DIR) $(STAGING_DIR_IMAGE)
+   $(CP) $(PKG_BUILD_DIR)/$(UBOOT_IMAGE) 
$(STAGING_DIR_IMAGE)/$(BUILD_DEVICES)-u-boot.bin
+endef
+
+define Package/u-boot/install/default
+endef
+
+$(eval $(call BuildPackage/U-Boot))
diff --git 
a/package/boot/uboot-bcm53xx/patches/0001-nand-brcmnand-add-iproc-support.patch 
b/package/boot/uboot-bcm53xx/patches/0001-nand-brcmnand-add-iproc-support.patch
new file mode 100644
index ..fe6f4d944afe
--- /dev/null
+++ 
b/package/boot/uboot-bcm53xx/patches/0001-nand-brcmnand-add-iproc-support.patch
@@ -0,0 +1,199 @@
+From 854dc4b790ce1291326d52b8405ebe771bff2edd Mon Sep 17 00:00:00 2001
+From: Linus Walleij 
+Date: Wed, 8 Mar 2023 22:42:31 +0100
+Subject: [PATCH 1/5] nand: brcmnand: add iproc support
+
+Add support for the iproc Broadcom NAND controller,
+used in Northstar SoCs for example. Based on the Linux
+driver.
+
+Cc: Philippe Reynes 
+Cc: Dario Binacchi 
+Reviewed-by: Michael Trimarchi 
+Signed-off-by: Linus Walleij 
+Acked-by: William Zhang 
+Link: 
https://lore.kernel.org/all/20230308214231.378013-1-linus.wall...@linaro.org/
+Signed-off-by: Dario Binacchi 
+---
+ drivers/mtd/nand/raw/Kconfig   |   7 +
+ drivers/mtd/nand/raw/brcmnand/Makefile |   1 +
+ drivers/mtd/nand/raw/brcmnand/iproc_nand.c | 148 +
+ 3 files changed, 156 insertions(+)
+ create mode 100644 drivers/mtd/nand/raw/brcmnand/iproc_nand.c
+
+--- a/drivers/mtd/nand/raw/Kconfig
 b/drivers/mtd/nand/raw/Kconfig
+@@ -156,6 +156,13 @@ config NAND_BRCMNAND_63158
+help
+  Enable support for broadcom nand driver on bcm63158.
+ 
++config NAND_BRCMNAND_IPROC
++   bool "Support Broadcom NAND controller on the iproc family"
++   depends on NAND_BRCMNAND
++   help
++ Enable support for broadcom nand driver on the Broadcom
++ iproc family such as Northstar (BCM5301x, BCM4708...)
++
+ config NAND_DAVINCI
+   bool "Support TI Davinci NAND controller"
+   select SYS_NAND_SELF_INIT if TARGET_DA850EVM
+--- a/drivers/mtd/nand/raw/brcmnand/Makefile
 b/driver

[PATCH v3 5/5] bcm53xx: Add network configuration for DIR-890L

2023-06-19 Thread Linus Walleij

This adds the lan/wan default bridge config and also the MAC
NVRAM read-out for et2.

DIR-885L was missing a default bridge config so I just added
that too while I was at it.

Signed-off-by: Linus Walleij 
---
ChangeLog v2->v3:
- Rebased on master
ChangeLog v1->v2:
- The DIR-890L sets up the Mac address from the NVRAM
  indicated in the device tree so drop that oneliner.
---
 target/linux/bcm53xx/base-files/etc/board.d/02_network | 4 
 1 file changed, 4 insertions(+)

diff --git a/target/linux/bcm53xx/base-files/etc/board.d/02_network 
b/target/linux/bcm53xx/base-files/etc/board.d/02_network
index 6bec600540ea..ba1cf7ac8d94 100644
--- a/target/linux/bcm53xx/base-files/etc/board.d/02_network
+++ b/target/linux/bcm53xx/base-files/etc/board.d/02_network
@@ -16,6 +16,10 @@ bcm53xx_setup_interfaces()
asus,rt-ac88u)
ucidef_set_interfaces_lan_wan "lan1 lan2 lan3 lan4 extsw" "wan"
;;
+   dlink,dir-885l | \
+   dlink,dir-890l)
+   ucidef_set_interfaces_lan_wan "lan1 lan2 lan3 lan4" "wan"
+   ;;
dlink,dwl-8610ap)
ucidef_set_interface_lan "eth0 eth1" "dhcp"
;;
-- 
2.34.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v3 3/5] bcm53xx: Add support for D-Link DIR-890L

2023-06-19 Thread Linus Walleij

The DIR-890L is very similar to DIR-885L, but has both USB2
and USB3. The signature for the wrgac36 board was copied from
DD-Wrt.

The DIR-890L bootstrap will only load the first 2 MB after
the SEAMA header in the NAND flash, uncompress it with LZMA
and execute it. Since the compressed kernel will not fit in
2 MB we have a problem. Solve this by putting a LZMA
compressed U-Boot into the first 128 KB of the flash
followed by the kernel. The bootstrap will then uncompress
and execute U-Boot and then we let U-Boot read the kernel
from flash and execute it.

Signed-off-by: Linus Walleij 
---
ChangeLog v2->v3:
- Rebased on master
- Test with kernel v6.1
ChangeLog v1->v2:
- Rebased on master
---
 .../base-files/etc/uci-defaults/09_fix_crc|  3 ++-
 .../base-files/lib/upgrade/platform.sh|  1 +
 target/linux/bcm53xx/image/Makefile   | 21 +++
 3 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/target/linux/bcm53xx/base-files/etc/uci-defaults/09_fix_crc 
b/target/linux/bcm53xx/base-files/etc/uci-defaults/09_fix_crc
index 89ce8970d75a..c39625b86536 100644
--- a/target/linux/bcm53xx/base-files/etc/uci-defaults/09_fix_crc
+++ b/target/linux/bcm53xx/base-files/etc/uci-defaults/09_fix_crc
@@ -13,7 +13,8 @@ fixseama() {
 }
 
 case "$board" in
-dlink,dir-885l)
+dlink,dir-885l | \
+dlink,dir-890l)
fixseama
;;
 *)
diff --git a/target/linux/bcm53xx/base-files/lib/upgrade/platform.sh 
b/target/linux/bcm53xx/base-files/lib/upgrade/platform.sh
index 3ebde77d3f94..958a9fd247ab 100644
--- a/target/linux/bcm53xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/bcm53xx/base-files/lib/upgrade/platform.sh
@@ -37,6 +37,7 @@ platform_expected_image() {
 
case "$machine" in
"dlink,dir-885l")   echo "seamaseal 
wrgac42_dlink.2015_dir885l"; return;;
+   "dlink,dir-890l")   echo "seamaseal 
wrgac36_dlink.2013gui_dir890"; return;;
"luxul,abr-4500-v1")echo "lxl ABR-4500"; return;;
"luxul,xap-810-v1") echo "lxl XAP-810"; return;;
"luxul,xap-1410v1") echo "lxl XAP-1410"; return;;
diff --git a/target/linux/bcm53xx/image/Makefile 
b/target/linux/bcm53xx/image/Makefile
index defa68e59f98..eb9f27c91eb5 100644
--- a/target/linux/bcm53xx/image/Makefile
+++ b/target/linux/bcm53xx/image/Makefile
@@ -88,6 +88,12 @@ define Build/luxul-lxl
mv $@.new $@
 endef
 
+# Outputs a lzma compressed U-Boot that start at 0x8000
+# just like the D-Link boot loaders expect
+define Build/dlink-uboot-bin
+   $(STAGING_DIR_HOST)/bin/lzma e 
$(STAGING_DIR_IMAGE)/$(DEVICE_NAME)-u-boot.bin -d16 $@
+endef
+
 define Build/seama-nand
# Seama entity
$(STAGING_DIR_HOST)/bin/oseama \
@@ -266,6 +272,21 @@ define Device/dlink_dir-885l
 endef
 TARGET_DEVICES += dlink_dir-885l
 
+define Device/dlink_dir-890l
+  DEVICE_VENDOR := D-Link
+  DEVICE_MODEL := DIR-890L
+  DEVICE_PACKAGES := $(BRCMFMAC_43602A1) $(USB2_PACKAGES) $(USB3_PACKAGES)
+  # Layout: U-boot (128kb max) followed by kernel and appended DTB.
+  # This is done because the boot loader will only read the first 2 MB
+  # from the flash and decompress the LZMA it finds there after the
+  # SEAMA header. Since the compressed kernel will not fit in 2 MB,
+  # we put U-Boot there and let U-Boot read and execute the kernel.
+  KERNEL := dlink-uboot-bin | pad-to 128k | append-kernel | append-dtb
+  $(Device/dlink)
+  SIGNATURE := wrgac36_dlink.2013gui_dir890
+endef
+TARGET_DEVICES += dlink_dir-890l
+
 define Device/dlink_dwl-8610ap
   DEVICE_VENDOR := D-Link
   DEVICE_MODEL := DWL-8610AP
-- 
2.34.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v3 4/5] bcm53xx: dir885/dir890: Tag both partitions as SEAMA

2023-06-19 Thread Linus Walleij

The newly added D-Link DIR-890L also needs to have a seama
tag on its partition so that it will be split properly by
mtdsplit.

Signed-off-by: Linus Walleij 
---
ChangeLog v2->v3:
- Add patch for kernel v6.1
- Test with kernel v6.1
ChangeLog v1->v2:
- Rebased on master
---
 ...-dts-BCM5301X-Describe-partition-formats.patch | 15 +--
 ...-dts-BCM5301X-Describe-partition-formats.patch | 15 +--
 2 files changed, 26 insertions(+), 4 deletions(-)

diff --git 
a/target/linux/bcm53xx/patches-5.15/321-ARM-dts-BCM5301X-Describe-partition-formats.patch
 
b/target/linux/bcm53xx/patches-5.15/321-ARM-dts-BCM5301X-Describe-partition-formats.patch
index f2861177dd1d..185db3960761 100644
--- 
a/target/linux/bcm53xx/patches-5.15/321-ARM-dts-BCM5301X-Describe-partition-formats.patch
+++ 
b/target/linux/bcm53xx/patches-5.15/321-ARM-dts-BCM5301X-Describe-partition-formats.patch
@@ -1,4 +1,4 @@
-From 7166207bd1d8c46d09d640d46afc685df9bb9083 Mon Sep 17 00:00:00 2001
+From a054e2fe2d00bd32f308986de654b66f054083d2 Mon Sep 17 00:00:00 2001
 From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= 
 Date: Thu, 22 Nov 2018 09:21:49 +0100
 Subject: [PATCH] ARM: dts: BCM5301X: Describe partition formats
@@ -11,7 +11,8 @@ It's needed by OpenWrt for custom partitioning.
 Signed-off-by: Rafał Miłecki 
 ---
  arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts | 1 +
- 1 file changed, 1 insertion(+)
+ arch/arm/boot/dts/bcm47094-dlink-dir-890l.dts | 1 +
+ 2 files changed, 2 insertions(+)
 
 --- a/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
 +++ b/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
@@ -23,3 +24,13 @@ Signed-off-by: Rafał Miłecki 
};
};
};
+--- a/arch/arm/boot/dts/bcm47094-dlink-dir-890l.dts
 b/arch/arm/boot/dts/bcm47094-dlink-dir-890l.dts
+@@ -151,6 +151,7 @@
+   firmware@0 {
+   label = "firmware";
+   reg = <0x 0x0800>;
++  compatible = "seama";
+   };
+   };
+ };
diff --git 
a/target/linux/bcm53xx/patches-6.1/321-ARM-dts-BCM5301X-Describe-partition-formats.patch
 
b/target/linux/bcm53xx/patches-6.1/321-ARM-dts-BCM5301X-Describe-partition-formats.patch
index f2861177dd1d..185db3960761 100644
--- 
a/target/linux/bcm53xx/patches-6.1/321-ARM-dts-BCM5301X-Describe-partition-formats.patch
+++ 
b/target/linux/bcm53xx/patches-6.1/321-ARM-dts-BCM5301X-Describe-partition-formats.patch
@@ -1,4 +1,4 @@
-From 7166207bd1d8c46d09d640d46afc685df9bb9083 Mon Sep 17 00:00:00 2001
+From a054e2fe2d00bd32f308986de654b66f054083d2 Mon Sep 17 00:00:00 2001
 From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= 
 Date: Thu, 22 Nov 2018 09:21:49 +0100
 Subject: [PATCH] ARM: dts: BCM5301X: Describe partition formats
@@ -11,7 +11,8 @@ It's needed by OpenWrt for custom partitioning.
 Signed-off-by: Rafał Miłecki 
 ---
  arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts | 1 +
- 1 file changed, 1 insertion(+)
+ arch/arm/boot/dts/bcm47094-dlink-dir-890l.dts | 1 +
+ 2 files changed, 2 insertions(+)
 
 --- a/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
 +++ b/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
@@ -23,3 +24,13 @@ Signed-off-by: Rafał Miłecki 
};
};
};
+--- a/arch/arm/boot/dts/bcm47094-dlink-dir-890l.dts
 b/arch/arm/boot/dts/bcm47094-dlink-dir-890l.dts
+@@ -151,6 +151,7 @@
+   firmware@0 {
+   label = "firmware";
+   reg = <0x 0x0800>;
++  compatible = "seama";
+   };
+   };
+ };
-- 
2.34.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v3 0/5] bcm53xx: Support D-Link DIR-890L

2023-06-19 Thread Linus Walleij

This adds support for the D-Link DIR-890L router.

Linus Walleij (5):
  bcm53xx: Fix kernel v6.1 config
  uboot-bcm53xx: Add U-Boot for NorthStar BCM53xx
  bcm53xx: Add support for D-Link DIR-890L
  bcm53xx: dir885/dir890: Tag both partitions as SEAMA
  bcm53xx: Add network configuration for DIR-890L

 .github/labeler.yml   |   1 +
 package/boot/uboot-bcm53xx/Makefile   |  37 +
 ...0001-nand-brcmnand-add-iproc-support.patch | 199 ++
 ...nand_base-Handle-algorithm-selection.patch |  80 +++
 ...t-device-tree-for-Broadcom-Northstar.patch | 659 ++
 ...port-for-the-Broadcom-Northstar-SoCs.patch |  66 ++
 ...ard-Add-new-Broadcom-Northstar-board.patch | 372 ++
 .../bcm53xx/base-files/etc/board.d/02_network |   4 +
 .../base-files/etc/uci-defaults/09_fix_crc|   3 +-
 .../base-files/lib/upgrade/platform.sh|   1 +
 target/linux/bcm53xx/config-6.1   |   2 +
 target/linux/bcm53xx/image/Makefile   |  21 +
 ...-BCM5301X-Describe-partition-formats.patch |  15 +-
 ...-BCM5301X-Describe-partition-formats.patch |  15 +-
 14 files changed, 1470 insertions(+), 5 deletions(-)
 create mode 100644 package/boot/uboot-bcm53xx/Makefile
 create mode 100644 
package/boot/uboot-bcm53xx/patches/0001-nand-brcmnand-add-iproc-support.patch
 create mode 100644 
package/boot/uboot-bcm53xx/patches/0002-mtd-rawnand-nand_base-Handle-algorithm-selection.patch
 create mode 100644 
package/boot/uboot-bcm53xx/patches/0003-arm-dts-Import-device-tree-for-Broadcom-Northstar.patch
 create mode 100644 
package/boot/uboot-bcm53xx/patches/0004-arm-Add-support-for-the-Broadcom-Northstar-SoCs.patch
 create mode 100644 
package/boot/uboot-bcm53xx/patches/0005-board-Add-new-Broadcom-Northstar-board.patch

-- 
2.34.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v3 1/5] bcm53xx: Fix kernel v6.1 config

2023-06-19 Thread Linus Walleij

The v6.1 kernel does not build for me, building with -j1 V=s
reveals that it is prompting for a kernel config option.
I also needed to add CONFIG_MTD_SPLIT_FIRMWARE for splitting
to work.

This make the v6.1 config work nicely as a baseline for my
DIR-890L patches.

Signed-off-by: Linus Walleij 
---
ChangeLog ->v3:
- New patch to make kernel v6.1 work
---
 target/linux/bcm53xx/config-6.1 | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/target/linux/bcm53xx/config-6.1 b/target/linux/bcm53xx/config-6.1
index d96beb687df0..0ffd90b64d1c 100644
--- a/target/linux/bcm53xx/config-6.1
+++ b/target/linux/bcm53xx/config-6.1
@@ -5,6 +5,7 @@ CONFIG_ARCH_BCM_5301X=y
 CONFIG_ARCH_BCM_53573=y
 # CONFIG_ARCH_BCM_HR2 is not set
 CONFIG_ARCH_BCM_IPROC=y
+CONFIG_ARCH_FORCE_MAX_ORDER=11
 CONFIG_ARCH_HIBERNATION_POSSIBLE=y
 CONFIG_ARCH_KEEP_MEMBLOCK=y
 CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y
@@ -207,6 +208,7 @@ CONFIG_MTD_PARSER_TPLINK_SAFELOADER=y
 CONFIG_MTD_PARSER_TRX=y
 CONFIG_MTD_RAW_NAND=y
 CONFIG_MTD_SPI_NOR=y
+CONFIG_MTD_SPLIT_FIRMWARE=y
 CONFIG_MTD_SPLIT_SEAMA_FW=y
 CONFIG_MTD_UBI=y
 CONFIG_MTD_UBI_BEB_LIMIT=20
-- 
2.34.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: OpenWrt 23.05.0-rc1 first release candidate

2023-06-14 Thread Linus Walleij

On Fri, Jun 9, 2023 at 5:36 PM Hauke Mehrtens  wrote:

> The OpenWrt community is proud to announce the first release candidate
> of the upcoming OpenWrt 23.05 stable series.

Thanks Hauke,

feeling responsible to test this thing I sysupgraded our primary office
router Netgear Nighthawk X4R R7800 with -rc1 and it upgraded without
any problems and works like a charm.

Yours,
Linus Walleij

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH 4/4] gemini: Bump to kernel v6.1

2023-06-03 Thread Linus Walleij

On Sat, Jun 3, 2023 at 10:44 AM Arınç ÜNAL  wrote:

> I prefer to stay away from backporting features to older Linux versions.
> The reasons being:
>
> - OpenWrt will eventually use a kernel version by default which will
> have the feature. It doesn't satisfy me to do all that work just for
> some OpenWrt devices to use this feature earlier. I would rather just
> make OpenWrt use the kernel version that's already got the feature. I
> already have some efforts to improve the current way to do this, I had a
> presentation on Battlemesh v15 regarding this and more.
>
> - The backporting process can become messy, and the backported code is
> prone to all sorts of possible issues. I don't want to debug any issues
> either caused or possibly caused by backporting features.

My sympathies. Coming to OpenWrt from the outside I was amazed
by the amount of out-of-tree efforts. But people have their reasons,
such as making hardware useful for a wider audience.

I personally try to compromise a bit, I backport if it
is easy and effortless, otherwise I wait, that works for me.

Yours,
Linus Walleij

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH 4/4] gemini: Bump to kernel v6.1

2023-06-02 Thread Linus Walleij

On Thu, Jun 1, 2023 at 11:20 PM Christian Lamparter  wrote:

> I looked into "how to get the old and new usb-fotg210" into one
> "define KernelPackage/usb-fotg210". Thing is, you put backported
> fotg's 6.2 infrastructure into your gemini's patches:
> 0002-usb-fotg210-Collect-pieces-of-dual-mode-controller.patch
> (that's a big one!)
> ...
>
> So, your gemini's 6.1 isn't the same as every other target in
> regard to fotg210 there (that said, gemini is currently the
> only user due to @TARGET_gemini. phew!). Due to the Makefile
> and KConfig changes: in OpenWrt's vanilla 6.1 the module is still
> fotg210-hcd(.ko), whereas gemini's 6.1 its been changed to fotg210(.ko).
> So, to deal with this at least a little bit, I just moved it to
> target/linux/gemini/modules.mk .

I checked it, wow these @lt6.1 etc I would never have figured out
so thanks a lot for stepping in on this!

> That said: This should be worth it? Reason being that since all
> this extra time spend, should make the target+fotg210 ready for
> the upcoming, next stable release (v6.6/7?), right?

Apart from tidying up the code, it makes the device mode work on
the DNS-313 actually, so it's not just cosmetic, I have been able
to use the USB port for serial, I just need to figure out how to get
OpenWrt to open a secondary console on it and people can get
serial access without soldering.

(The original use of the device USB port on that device is USB mass
storage, but that was an extreme hack on the original device, including
a plastic cover that shift over the USB port when connected to network
so you cannot use network and USB at the same time to access the
same file partition...)

> BTW: Do you have some time to look into realtek's DSA for the
> RTL8363SB? I'm converting some of the APM821xx Devices
> to DSA and the rtl8365mb seems promising. I've seen that you did
> some major work there. But there are some snags that I'm not sure
> are limited to the RTL8363SB (access through MDIO needs different
> code. And what's up with the CPU-Port or Extif?) or not.
> (will post to the appropriate ML for that in the "upcoming months")

I don't have any device with this DSA on it, but certainly I'm available
for questions and review. But Alvin Šipraga 
and Luiz Angelo Daros de Luca  have been very
helpful with the upstream code for RTL8365MB, and it also "should"
support RTL8363SC so I would be surprised if RTL8363SB is any
different.

So best case if you can boot the upstream kernel (or backport all the
patches to drivers/net/dsa/realtek...) the RTL8365MB driver:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/dsa/realtek/rtl8365mb.c
just edit rtl8365mb_chip_infos[] to include the magic for RTL8363SB
and see if it magically works. You probably need a jam table magic
sequence from the vendor driver if you have that.

The upstream device tree for ASUS RT AC88U has the
8365MB courtesy of Arınç ÜNAL :
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/bcm47094-asus-rt-ac88u.dts

If you just copy/paste that +/- some changes it should probe, all
devices use compatible = "realtek,rtl8365mb"; no matter which
variant it is. Arınç has also been very helpful with this code, and I
think we wanna bring in the RTL8365MB patches at least for
BCM53xx for v6.1 (but I think we should probably put them into
linux/generic).

I think Arınç already has plans to bring this to OpenWrt for v6.1
though, Arınç?

Yours,
Linus Walleij

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH 4/4] gemini: Bump to kernel v6.1

2023-06-01 Thread Linus Walleij

On Thu, Jun 1, 2023 at 3:48 PM Christian Lamparter  wrote:

> Hmpf. Unfortunately, OpenWrt's 6.1 isn't ready yet. If I just
> set the KERNEL_VERSION to 6.1 then the build-bots will fail to
> produce images.

Aha how typical.

> If you want to look: There's this fortify-source bug in mac80211
> ath9k that needs to be fixed first:
> https://github.com/openwrt/openwrt/pull/12764#issuecomment-1568297522
> https://github.com/openwrt/openwrt/pull/12764#issuecomment-1568856473
> https://github.com/openwrt/openwrt/pull/12764#issuecomment-1569473000
>
> (And it looks like not all modules dependencies have been sorted out yet).

Oh I really don't know my way around that code...

> For the time being. I could just change this to
> KERNEL_TESTING_PATCHVER=6.1 and leave KERNEL_PATCHVER at 5.15.
>
> (So, people can pick 6.1 when they do their own builds until the
> 6.1 woes have been sorted out?)

This works for me, it's nice to have it upstream rather than in my odd
trees.

Yours,
Linus Walleij

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 2/4] gemini: Create a config for kernel v6.1

2023-05-31 Thread Linus Walleij

This creates a config for the v6.1 kernel for Gemini.

Signed-off-by: Linus Walleij 
---
 target/linux/gemini/config-6.1 | 427 +
 1 file changed, 427 insertions(+)
 create mode 100644 target/linux/gemini/config-6.1

diff --git a/target/linux/gemini/config-6.1 b/target/linux/gemini/config-6.1
new file mode 100644
index ..41f7093c1cef
--- /dev/null
+++ b/target/linux/gemini/config-6.1
@@ -0,0 +1,427 @@
+CONFIG_ALIGNMENT_TRAP=y
+CONFIG_AMBA_PL08X=y
+CONFIG_ARCH_32BIT_OFF_T=y
+CONFIG_ARCH_FORCE_MAX_ORDER=11
+CONFIG_ARCH_GEMINI=y
+CONFIG_ARCH_KEEP_MEMBLOCK=y
+CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y
+# CONFIG_ARCH_MOXART is not set
+CONFIG_ARCH_MULTIPLATFORM=y
+CONFIG_ARCH_MULTI_V4=y
+# CONFIG_ARCH_MULTI_V4T is not set
+CONFIG_ARCH_MULTI_V4_V5=y
+# CONFIG_ARCH_MULTI_V5 is not set
+CONFIG_ARCH_NR_GPIO=0
+CONFIG_ARCH_OPTIONAL_KERNEL_RWX=y
+CONFIG_ARCH_SELECT_MEMORY_MODEL=y
+CONFIG_ARCH_SPARSEMEM_ENABLE=y
+CONFIG_ARM=y
+CONFIG_ARM_AMBA=y
+CONFIG_ARM_APPENDED_DTB=y
+# CONFIG_ARM_ATAG_DTB_COMPAT is not set
+CONFIG_ARM_CRYPTO=y
+CONFIG_ARM_HAS_SG_CHAIN=y
+CONFIG_ARM_L1_CACHE_SHIFT=5
+CONFIG_ARM_PATCH_PHYS_VIRT=y
+# CONFIG_ARM_SMMU is not set
+CONFIG_ARM_UNWIND=y
+CONFIG_ATA=y
+CONFIG_ATAGS=y
+CONFIG_ATA_FORCE=y
+CONFIG_ATA_VERBOSE_ERROR=y
+CONFIG_AUTO_ZRELADDR=y
+CONFIG_BINFMT_FLAT_ARGVP_ENVP_ON_STACK=y
+CONFIG_BLK_DEV_SD=y
+CONFIG_BLK_MQ_PCI=y
+CONFIG_BLK_PM=y
+CONFIG_BOUNCE=y
+CONFIG_CLKSRC_MMIO=y
+CONFIG_CLONE_BACKWARDS=y
+CONFIG_CMA=y
+CONFIG_CMA_ALIGNMENT=8
+CONFIG_CMA_AREAS=7
+# CONFIG_CMA_DEBUG is not set
+# CONFIG_CMA_DEBUGFS is not set
+CONFIG_CMA_SIZE_PERCENTAGE=10
+# CONFIG_CMA_SIZE_SEL_MAX is not set
+# CONFIG_CMA_SIZE_SEL_MBYTES is not set
+# CONFIG_CMA_SIZE_SEL_MIN is not set
+CONFIG_CMA_SIZE_SEL_PERCENTAGE=y
+# CONFIG_CMA_SYSFS is not set
+CONFIG_COMMON_CLK=y
+CONFIG_COMMON_CLK_GEMINI=y
+CONFIG_COMPAT_32BIT_TIME=y
+CONFIG_CONSOLE_TRANSLATIONS=y
+CONFIG_CONTIG_ALLOC=y
+CONFIG_COREDUMP=y
+CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
+CONFIG_CPU_32v4=y
+CONFIG_CPU_ABRT_EV4=y
+CONFIG_CPU_CACHE_FA=y
+CONFIG_CPU_CACHE_VIVT=y
+CONFIG_CPU_COPY_FA=y
+CONFIG_CPU_CP15=y
+CONFIG_CPU_CP15_MMU=y
+# CONFIG_CPU_DCACHE_WRITETHROUGH is not set
+CONFIG_CPU_FA526=y
+CONFIG_CPU_NO_EFFICIENT_FFS=y
+CONFIG_CPU_PABRT_LEGACY=y
+CONFIG_CPU_THERMAL=y
+CONFIG_CPU_TLB_FA=y
+CONFIG_CPU_USE_DOMAINS=y
+CONFIG_CRASH_CORE=y
+CONFIG_CRC16=y
+# CONFIG_CRC32_SARWATE is not set
+CONFIG_CRC32_SLICEBY8=y
+CONFIG_CRC_CCITT=y
+CONFIG_CRC_ITU_T=y
+CONFIG_CROSS_MEMORY_ATTACH=y
+CONFIG_CRYPTO_CMAC=y
+CONFIG_CRYPTO_CRC32C=y
+CONFIG_CRYPTO_DES=y
+CONFIG_CRYPTO_DEV_SL3516=y
+# CONFIG_CRYPTO_DEV_SL3516_DEBUG is not set
+CONFIG_CRYPTO_DRBG=y
+CONFIG_CRYPTO_DRBG_HMAC=y
+CONFIG_CRYPTO_DRBG_MENU=y
+CONFIG_CRYPTO_ECB=y
+CONFIG_CRYPTO_ECHAINIV=y
+CONFIG_CRYPTO_ENGINE=y
+CONFIG_CRYPTO_HMAC=y
+CONFIG_CRYPTO_HW=y
+CONFIG_CRYPTO_JITTERENTROPY=y
+CONFIG_CRYPTO_LIB_BLAKE2S_GENERIC=y
+CONFIG_CRYPTO_LIB_DES=y
+CONFIG_CRYPTO_LIB_SHA256=y
+CONFIG_CRYPTO_MD4=y
+CONFIG_CRYPTO_MD5=y
+CONFIG_CRYPTO_RNG=y
+CONFIG_CRYPTO_RNG2=y
+CONFIG_CRYPTO_RNG_DEFAULT=y
+CONFIG_CRYPTO_SEQIV=y
+CONFIG_CRYPTO_SHA256=y
+CONFIG_CRYPTO_SHA512=y
+CONFIG_DEBUG_BUGVERBOSE=y
+CONFIG_DEBUG_LL_INCLUDE="mach/debug-macro.S"
+CONFIG_DEBUG_MEMORY_INIT=y
+CONFIG_DECOMPRESS_BZIP2=y
+CONFIG_DECOMPRESS_GZIP=y
+CONFIG_DECOMPRESS_LZ4=y
+CONFIG_DECOMPRESS_LZMA=y
+CONFIG_DECOMPRESS_LZO=y
+CONFIG_DECOMPRESS_XZ=y
+CONFIG_DMADEVICES=y
+CONFIG_DMATEST=y
+CONFIG_DMA_CMA=y
+CONFIG_DMA_ENGINE=y
+CONFIG_DMA_ENGINE_RAID=y
+CONFIG_DMA_OF=y
+CONFIG_DMA_OPS=y
+CONFIG_DMA_REMAP=y
+CONFIG_DMA_SHARED_BUFFER=y
+CONFIG_DMA_VIRTUAL_CHANNELS=y
+CONFIG_DRM=y
+CONFIG_DRM_BRIDGE=y
+CONFIG_DRM_FBDEV_EMULATION=y
+CONFIG_DRM_FBDEV_OVERALLOC=100
+CONFIG_DRM_GEM_CMA_HELPER=y
+CONFIG_DRM_KMS_CMA_HELPER=y
+CONFIG_DRM_KMS_HELPER=y
+CONFIG_DRM_PANEL=y
+CONFIG_DRM_PANEL_BRIDGE=y
+CONFIG_DRM_PANEL_ILITEK_IL9322=y
+CONFIG_DRM_PANEL_ORIENTATION_QUIRKS=y
+CONFIG_DRM_TVE200=y
+CONFIG_DTC=y
+CONFIG_DUMMY_CONSOLE=y
+CONFIG_EDAC_ATOMIC_SCRUB=y
+CONFIG_EDAC_SUPPORT=y
+CONFIG_EEPROM_93CX6=y
+CONFIG_ELF_CORE=y
+# CONFIG_EMBEDDED is not set
+# CONFIG_EXPERT is not set
+CONFIG_EXT4_FS=y
+CONFIG_FARADAY_FTINTC010=y
+CONFIG_FB=y
+CONFIG_FB_CFB_COPYAREA=y
+CONFIG_FB_CFB_FILLRECT=y
+CONFIG_FB_CFB_IMAGEBLIT=y
+CONFIG_FB_CMDLINE=y
+CONFIG_FB_DEFERRED_IO=y
+CONFIG_FB_SYS_COPYAREA=y
+CONFIG_FB_SYS_FILLRECT=y
+CONFIG_FB_SYS_FOPS=y
+CONFIG_FB_SYS_IMAGEBLIT=y
+CONFIG_FHANDLE=y
+CONFIG_FIXED_PHY=y
+CONFIG_FIX_EARLYCON_MEM=y
+CONFIG_FONT_8x16=y
+CONFIG_FONT_8x8=y
+CONFIG_FONT_SUPPORT=y
+CONFIG_FRAMEBUFFER_CONSOLE=y
+CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
+# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
+CONFIG_FS_IOMAP=y
+CONFIG_FS_MBCACHE=y
+CONFIG_FS_POSIX_ACL=y
+CONFIG_FTTMR010_TIMER=y
+CONFIG_FTWDT010_WATCHDOG=y
+CONFIG_FWNODE_MDIO=y
+CONFIG_FW_LOADER_PAGED_BUF=y
+# CONFIG_FW_LOADER_USER_HELPER_FALLBACK is not set
+CONFIG_GEMINI_ETHERNET=y
+CONFIG_GENERIC_ALLOCATOR=y
+CONFIG_GENERIC_ATOMIC64=y
+CONFIG_GEN

[PATCH 3/4] kernel: Package the new FOTG210 module properly

2023-05-31 Thread Linus Walleij

When using the Gemini, we apply patches that create a single
module that support both host and device mode these days.

Signed-off-by: Linus Walleij 
---
 package/kernel/linux/modules/usb.mk | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/package/kernel/linux/modules/usb.mk 
b/package/kernel/linux/modules/usb.mk
index 721e17f97087..287a48212153 100644
--- a/package/kernel/linux/modules/usb.mk
+++ b/package/kernel/linux/modules/usb.mk
@@ -332,12 +332,12 @@ endef
 $(eval $(call KernelPackage,usb-bcma))
 
 define KernelPackage/usb-fotg210
-  TITLE:=Support for FOTG210 USB host controllers
+  TITLE:=Support for FOTG210 USB host and device controllers
   DEPENDS:=@USB_SUPPORT @TARGET_gemini
-  KCONFIG:=CONFIG_USB_FOTG210_HCD
+  KCONFIG:=CONFIG_USB_FOTG210
   FILES:= \
-   $(if 
$(CONFIG_USB_FOTG210_HCD),$(LINUX_DIR)/drivers/usb/host/fotg210-hcd.ko)
-  AUTOLOAD:=$(call AutoLoad,50,fotg210-hcd,1)
+   $(if $(CONFIG_USB_FOTG210),$(LINUX_DIR)/drivers/usb/fotg210/fotg210.ko)
+  AUTOLOAD:=$(call AutoLoad,50,fotg210,1)
   $(call AddDepends/usb)
 endef
 $(eval $(call KernelPackage,usb-fotg210))
-- 
2.34.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 4/4] gemini: Bump to kernel v6.1

2023-05-31 Thread Linus Walleij

This bumps the Gemini kernel to use v6.1. There is no
reason to stay with v5.15, I personally use newer upstream
kernels constantly and they are tested and work well.

Signed-off-by: Linus Walleij 
---
 target/linux/gemini/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/gemini/Makefile b/target/linux/gemini/Makefile
index 4266db16cd37..b7f1962c9a59 100644
--- a/target/linux/gemini/Makefile
+++ b/target/linux/gemini/Makefile
@@ -11,7 +11,7 @@ FEATURES:=squashfs pci rtc usb dt gpio display ext4 
rootfs-part boot-part
 CPU_TYPE:=fa526
 SUBTARGETS:=generic
 
-KERNEL_PATCHVER:=5.15
+KERNEL_PATCHVER:=6.1
 
 define Target/Description
Build firmware images for the StorLink/Cortina Gemini CS351x ARM FA526 
CPU
-- 
2.34.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

1 2 3 4 5 6 >

1 - 100 of 527 matches

Mail list logo