From hannu.nyman at iki.fi Sun May 1 04:33:07 2016 From: hannu.nyman at iki.fi (Hannu Nyman) Date: Sun, 1 May 2016 11:33:07 +0300 Subject: [OpenWrt-Devel] r49252 (dnsmasq: run as dedicated UID/GID) causing major havoc In-Reply-To: References: Message-ID: <526435f2-9c35-2fe9-acd2-cec9d1f2c481@iki.fi> > i have just pushed a generic fix, please verify that it fixes the issue. > it seems to work for me. Yep, your fix works ok. Tested with a new build of r49276. Great that you figured out a generic solution, so that this kind of problems should be automagically fixed in future. _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From blogic at openwrt.org Sun May 1 05:48:41 2016 From: blogic at openwrt.org (John Crispin) Date: Sun, 1 May 2016 11:48:41 +0200 Subject: [OpenWrt-Devel] r49252 (dnsmasq: run as dedicated UID/GID) causing major havoc In-Reply-To: <526435f2-9c35-2fe9-acd2-cec9d1f2c481@iki.fi> References: <526435f2-9c35-2fe9-acd2-cec9d1f2c481@iki.fi> Message-ID: On 01/05/2016 10:33, Hannu Nyman wrote: >> i have just pushed a generic fix, please verify that it fixes the issue. >> it seems to work for me. > > Yep, your fix works ok. > Tested with a new build of r49276. > thanks for testing. those that see the error just need to sysupgrade with a current build. that will automatically fix the issue for them. _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From josua.mayer97 at gmail.com Sun May 1 09:26:28 2016 From: josua.mayer97 at gmail.com (Josua Mayer) Date: Sun, 1 May 2016 15:26:28 +0200 Subject: [OpenWrt-Devel] [PATCH v3 1/2] mvebu: config-4.1: make mmc drivers builtin In-Reply-To: <010001545ee1f9d7-e80e4bcf-6c52-461f-9076-c3be74ebbb06-000000@email.amazonses.com> References: <1461855802-15700-1-git-send-email-josua.mayer97@gmail.com> <010001545ee1f9d7-e80e4bcf-6c52-461f-9076-c3be74ebbb06-000000@email.amazonses.com> Message-ID: Hi Andrej, Am 28.04.2016 um 23:59 schrieb Andrej Vlasic: > Hi Josua, > > On 28.04.2016 17:03, josua.mayer97 at gmail.com wrote: >> From: Josua Mayer >> >> This is especially useful on the Clearfog board which boots from mmc by >> default. >> >> Signed-off-by: Josua Mayer >> --- >> target/linux/mvebu/config-4.1 | 24 ++++++++++++++++++++++++ >> 1 file changed, 24 insertions(+) >> >> diff --git a/target/linux/mvebu/config-4.1 >> b/target/linux/mvebu/config-4.1 >> index ee5c983..73319dd 100644 >> --- a/target/linux/mvebu/config-4.1 >> +++ b/target/linux/mvebu/config-4.1 >> @@ -362,3 +362,27 @@ CONFIG_ZBOOT_ROM_TEXT=0x0 >> CONFIG_ZLIB_DEFLATE=y >> CONFIG_ZLIB_INFLATE=y >> CONFIG_ZONE_DMA_FLAG=0 >> +CONFIG_MMC=y >> +CONFIG_MMC_BLOCK=y >> +CONFIG_MMC_BLOCK_BOUNCE=y >> +CONFIG_MMC_BLOCK_MINORS=8 >> +CONFIG_MMC_CB710=n >> +CONFIG_MMC_CLKGATE=n >> +CONFIG_MMC_DEBUG=n >> +CONFIG_MMC_DW=n >> +CONFIG_MMC_MVSDIO=y >> +CONFIG_MMC_SDHCI=n >> +CONFIG_MMC_TEST=n >> +CONFIG_MMC_TIFM_SD=n >> +CONFIG_MMC_TOSHIBA_PCI=n >> +CONFIG_MMC_USDHI6ROL0=n >> +CONFIG_MMC_USHC=n >> +CONFIG_MMC_VIA_SDMMC=n >> +CONFIG_MMC_VUB300=n >> +CONFIG_MMC_SDHCI=y >> +CONFIG_MMC_SDHCI_F_SDH30=n >> +CONFIG_MMC_SDHCI_OF_ARASAN=n >> +CONFIG_MMC_SDHCI_PCI=n >> +CONFIG_MMC_SDHCI_PLTFM=y >> +CONFIG_MMC_SDHCI_PXAV3=y >> +CONFIG_SDIO_UART=n >> > > Instead of adding those config options to default kernel config, it > would be better to create new mvebu subtarget, maybe called "harddisk" > that has support for external boot devices. Personally I would prefer not to create a new target, just for different boot storage. There can be spi flash, sdcard, emmc, sata, who-knows-what other flavours. But I suppose there are mvebu devices out there with very limited flash memory? So what do you think about making a new target mvebu_fat, which includes all the storage drivers that the supported SoCs have? I came up with the name because my target device, the clearfog has plenty of storage so it does not mind if the OpenWRT image grows fat. _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From xotic750 at gmail.com Sun May 1 16:12:20 2016 From: xotic750 at gmail.com (Graham Fairweather) Date: Sun, 1 May 2016 22:12:20 +0200 Subject: [OpenWrt-Devel] [PATCH 001/001] [brcm63xx] Add support for the NetGear EVG2000 Message-ID: From: Graham Fairweather This patch adds support for the NetGear EVG2000 to the bcm63xx target. More info on the device can be found at: https://wiki.openwrt.org/toh/netgear/evg2000 https://wikidevi.com/wiki/Netgear_EVG2000 https://github.com/Xotic750/openwrt/tree/evg2000 https://forum.openwrt.org/viewtopic.php?id=63950 Known issues: - b53 driver is unable to detect 53115 switch. Signed-off-by: Graham Fairweather --- target/linux/brcm63xx/base-files/etc/board.d/01_leds | 7 +++++ target/linux/brcm63xx/base-files/etc/board.d/02_network | 1 + target/linux/brcm63xx/base-files/lib/brcm63xx.sh | 3 ++ target/linux/brcm63xx/dts/evg2000.dts | 103 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ target/linux/brcm63xx/image/Makefile | 2 ++ target/linux/brcm63xx/patches-4.1/805-board_EVG2000.patch | 62 +++++++++++++++++++++++++++++++++++++++ target/linux/brcm63xx/patches-4.4/805-board_EVG2000.patch | 62 +++++++++++++++++++++++++++++++++++++++ target/linux/brcm63xx/profiles/netgear.mk | 11 +++++++ 8 files changed, 251 insertions(+) diff --git a/target/linux/brcm63xx/base-files/etc/board.d/01_leds b/target/linux/brcm63xx/base-files/etc/board.d/01_leds index 8339254..4163214 100755 --- a/target/linux/brcm63xx/base-files/etc/board.d/01_leds +++ b/target/linux/brcm63xx/base-files/etc/board.d/01_leds @@ -24,6 +24,13 @@ dgnd3700v1_dgnd3800b) ucidef_set_led_usbdev "usb1" "USB1" "DGND3700v1_3800B:green:usb-back" "1-1" ucidef_set_led_usbdev "usb2" "USB2" "DGND3700v1_3800B:green:usb-front" "1-2" ;; +evg2000) + ucidef_set_led_netdev "lan" "LAN" "EVG2000:green:lan" "eth0" + ucidef_set_led_netdev "wan" "WAN" "EVG2000:green:wan" "eth1" + ucidef_set_led_netdev "wlan0" "WIFI" "EVG2000:green:wireless" "wlan0" + ucidef_set_led_usbdev "usb1" "USB1" "EVG2000:green:voip1" "1-1" + ucidef_set_led_usbdev "usb2" "USB2" "EVG2000:green:voip2" "1-2" + ;; fast2704n) ucidef_set_led_netdev "wan" "WAN" "F at ST2704N:green:inet" "eth0.2" ;; diff --git a/target/linux/brcm63xx/base-files/etc/board.d/02_network b/target/linux/brcm63xx/base-files/etc/board.d/02_network index f96da08..83367c1 100755 --- a/target/linux/brcm63xx/base-files/etc/board.d/02_network +++ b/target/linux/brcm63xx/base-files/etc/board.d/02_network @@ -11,6 +11,7 @@ board_config_update case "$(brcm63xx_board_name)" in cvg834g |\ +evg2000 |\ rta770bw |\ rta770w |\ spw303v |\ diff --git a/target/linux/brcm63xx/base-files/lib/brcm63xx.sh b/target/linux/brcm63xx/base-files/lib/brcm63xx.sh index a2d6519..9cc0b2b 100755 --- a/target/linux/brcm63xx/base-files/lib/brcm63xx.sh +++ b/target/linux/brcm63xx/base-files/lib/brcm63xx.sh @@ -183,6 +183,9 @@ brcm63xx_dt_detect() { "Netgear DGND3700v1/DGND3800B") board_name="dgnd3700v1_dgnd3800b" ;; + "Netgear EVG2000") + board_name="evg2000" + ;; "NuCom R5010UN v2") board_name="r5010un_v2" ;; diff --git a/target/linux/brcm63xx/dts/evg2000.dts b/target/linux/brcm63xx/dts/evg2000.dts new file mode 100644 index 0000000..04f7b84 --- /dev/null +++ b/target/linux/brcm63xx/dts/evg2000.dts @@ -0,0 +1,103 @@ +/dts-v1/; + +#include "bcm6368.dtsi" + +#include + +/ { + model = "Netgear EVG2000"; + compatible = "netgear,evg2000", "brcm,bcm6368"; + + gpio-keys-polled { + compatible = "gpio-keys-polled"; + #address-cells = <1>; + #size-cells = <0>; + poll-interval = <20>; + debounce-interval = <60>; + + reset { + label = "reset"; + gpios = <&gpio0 25 1>; + linux,code = ; + }; + wps { + label = "wps"; + gpios = <&gpio0 26 1>; + linux,code = ; + }; + }; + + gpio-leds { + compatible = "gpio-leds"; + + voip1_green { + label = "EVG2000:green:voip1"; + gpios = <&gpio0 14 1>; + }; + voip2_green { + label = "EVG2000:green:voip2"; + gpios = <&gpio0 2 1>; + }; + inet_red { + label = "EVG2000:red:inet"; + gpios = <&gpio0 4 1>; + }; + inet_green { + label = "EVG2000:green:inet"; + gpios = <&gpio0 5 1>; + }; + usb_green { + label = "EVG2000:green:usb"; + gpios = <&gpio0 15 1>; + }; + power_green { + label = "EVG2000:green:power"; + gpios = <&gpio0 22 1>; + default-state = "on"; + }; + power_red { + label = "EVG2000:red:power"; + gpios = <&gpio0 23 1>; + }; + lan_green { + label = "EVG2000:green:lan"; + gpios = <&gpio0 24 1>; + }; + wireless_green { + label = "EVG2000:green:wireless"; + gpios = <&gpio0 26 1>; + }; + wan_green { + label = "EVG2000:green:wan"; + gpios = <&gpio0 27 1>; + }; + }; +}; + +&pflash { + status = "ok"; + + linux,part-probe = "bcm63xxpart"; + + cfe at 0 { + label = "CFE"; + reg = <0x00000000 0x00020000>; + read-only; + }; + + linux at 20000 { + label = "linux"; + reg = <0x00020000 0x00f40000>; + }; + + board_data at f60000 { + label = "board_data"; + reg = <0x00f60000 0x00080000>; + read-only; + }; + + nvram at fe0000 { + label = "nvram"; + reg = <0x00fe0000 0x00020000>; + }; +}; diff --git a/target/linux/brcm63xx/image/Makefile b/target/linux/brcm63xx/image/Makefile index e00b6fb..f1fb86b 100644 --- a/target/linux/brcm63xx/image/Makefile +++ b/target/linux/brcm63xx/image/Makefile @@ -593,6 +593,8 @@ $(eval $(call bcm63xxCfeRamdisk,DG834GV4,DG834GTv4,dg834g_v4,96348W3,6348)) $(eval $(call bcm63xxCfeNetgear,DGND3700v1_3800B,DGND3700v1,dgnd3700v1,96368MVWG,6368,--image-offset 0x20000 --block-size 0x20000,U12L144T01_NETGEAR_NEWLED,1)) # Netgear DGND3800B $(eval $(call bcm63xxCfeNetgear,DGND3700v1_3800B,DGND3800B,dgnd3700v1,96368MVWG,6368,--image-offset 0x20000 --block-size 0x20000,U12L144T11_NETGEAR_NEWLED,1)) +# Netgear EVG2000 +$(eval $(call bcm63xxCfeNetgear,EVG2000,EVG2000,evg2000,96369PVG,6369,--image-offset 0x20000 --block-size 0x20000,U12H154T90_NETGEAR,1)) # NuCom R5010UNv2 $(eval $(call bcm63xxCfe,R5010UNV2,R5010UNv2,r5010unv2,96328ang,6328,--pad 8)) # Pirelli Alice Gate VoIP 2 Plus Wi-Fi AGPF-S0 diff --git a/target/linux/brcm63xx/patches-4.1/805-board_EVG2000.patch b/target/linux/brcm63xx/patches-4.1/805-board_EVG2000.patch new file mode 100644 index 0000000..9339085 --- /dev/null +++ b/target/linux/brcm63xx/patches-4.1/805-board_EVG2000.patch @@ -0,0 +1,62 @@ +--- a/arch/mips/bcm63xx/boards/board_bcm963xx.c ++++ b/arch/mips/bcm63xx/boards/board_bcm963xx.c +@@ -2010,6 +2010,43 @@ static struct board_info __initdata boar + .num_spis = ARRAY_SIZE(DGND3700v1_3800B_spi_devices), + }; + ++static struct sprom_fixup __initdata EVG2000_fixups[] = { ++ { .offset = 219, .value = 0xec08 }, ++}; ++ ++static struct board_info __initdata board_EVG2000 = { ++ .name = "96369PVG", ++ .expected_cpu_id = 0x6368, ++ ++ .has_uart0 = 1, ++ .has_pci = 1, ++ .has_ohci0 = 1, ++ .has_ehci0 = 1, ++ .num_usbh_ports = 2, ++ ++ .has_enetsw = 1, ++ .enetsw = { ++ .used_ports = { ++ [5] = { ++ .used = 1, ++ .phy_id = 0xff, ++ .bypass_link = 1, ++ .force_speed = 1000, ++ .force_duplex_full = 1, ++ .name = "RGMII", ++ }, ++ }, ++ }, ++ .use_fallback_sprom = 1, ++ .fallback_sprom = { ++ .type = SPROM_BCM4322, ++ .pci_bus = 0, ++ .pci_dev = 1, ++ .board_fixups = EVG2000_fixups, ++ .num_board_fixups = ARRAY_SIZE(EVG2000_fixups), ++ }, ++}; ++ + static struct board_info __initdata board_HG655b = { + .name = "HW65x", + .expected_cpu_id = 0x6368, +@@ -2610,6 +2647,7 @@ static const struct board_info __initcon + &board_96368mvwg, + &board_96368mvngr, + &board_DGND3700v1_3800B, ++ &board_EVG2000, + &board_HG622, + &board_HG655b, + &board_P870HW51A_V2, +@@ -2722,6 +2760,7 @@ static struct of_device_id const bcm963x + { .compatible = "huawei,hg622", .data = &board_HG622, }, + { .compatible = "huawei,hg655b", .data = &board_HG655b, }, + { .compatible = "netgear,dgnd3700v1", .data = &board_DGND3700v1_3800B, }, ++ { .compatible = "netgear,evg2000", .data = &board_EVG2000, }, + { .compatible = "zyxel,p870hw-51a-v2", .data = &board_P870HW51A_V2, }, + #endif + #ifdef CONFIG_BCM63XX_CPU_63268 diff --git a/target/linux/brcm63xx/patches-4.4/805-board_EVG2000.patch b/target/linux/brcm63xx/patches-4.4/805-board_EVG2000.patch new file mode 100644 index 0000000..2f7e8be --- /dev/null +++ b/target/linux/brcm63xx/patches-4.4/805-board_EVG2000.patch @@ -0,0 +1,62 @@ +--- a/arch/mips/bcm63xx/boards/board_bcm963xx.c ++++ b/arch/mips/bcm63xx/boards/board_bcm963xx.c +@@ -2011,6 +2011,43 @@ static struct board_info __initdata boar + .num_spis = ARRAY_SIZE(DGND3700v1_3800B_spi_devices), + }; + ++static struct sprom_fixup __initdata EVG2000_fixups[] = { ++ { .offset = 219, .value = 0xec08 }, ++}; ++ ++static struct board_info __initdata board_EVG2000 = { ++ .name = "96369PVG", ++ .expected_cpu_id = 0x6368, ++ ++ .has_uart0 = 1, ++ .has_pci = 1, ++ .has_ohci0 = 1, ++ .has_ehci0 = 1, ++ .num_usbh_ports = 2, ++ ++ .has_enetsw = 1, ++ .enetsw = { ++ .used_ports = { ++ [5] = { ++ .used = 1, ++ .phy_id = 0xff, ++ .bypass_link = 1, ++ .force_speed = 1000, ++ .force_duplex_full = 1, ++ .name = "RGMII", ++ }, ++ }, ++ }, ++ .use_fallback_sprom = 1, ++ .fallback_sprom = { ++ .type = SPROM_BCM4322, ++ .pci_bus = 0, ++ .pci_dev = 1, ++ .board_fixups = EVG2000_fixups, ++ .num_board_fixups = ARRAY_SIZE(EVG2000_fixups), ++ }, ++}; ++ + static struct board_info __initdata board_HG655b = { + .name = "HW65x", + .expected_cpu_id = 0x6368, +@@ -2611,6 +2648,7 @@ static const struct board_info __initcon + &board_96368mvwg, + &board_96368mvngr, + &board_DGND3700v1_3800B, ++ &board_EVG2000, + &board_HG622, + &board_HG655b, + &board_P870HW51A_V2, +@@ -2722,6 +2761,7 @@ static struct of_device_id const bcm963x + { .compatible = "huawei,hg622", .data = &board_HG622, }, + { .compatible = "huawei,hg655b", .data = &board_HG655b, }, + { .compatible = "netgear,dgnd3700v1", .data = &board_DGND3700v1_3800B, }, ++ { .compatible = "netgear,evg2000", .data = &board_EVG2000, }, + { .compatible = "zyxel,p870hw-51a-v2", .data = &board_P870HW51A_V2, }, + #endif + #ifdef CONFIG_BCM63XX_CPU_63268 diff --git a/target/linux/brcm63xx/profiles/netgear.mk b/target/linux/brcm63xx/profiles/netgear.mk index bc345bb..5164d0c 100644 --- a/target/linux/brcm63xx/profiles/netgear.mk +++ b/target/linux/brcm63xx/profiles/netgear.mk @@ -36,8 +36,19 @@ define Profile/DGND3700v1_3800B NAME:=Netgear DGND3700 v1 / DGND3800B PACKAGES:=kmod-b43 wpad-mini \ kmod-usb2 kmod-usb-ohci kmod-ledtrig-usbdev + endef define Profile/DGND3700v1_3800B/Description Package set optimized for DGND3700 v1 / DGND3800B. endef $(eval $(call Profile,DGND3700v1_3800B)) + +define Profile/EVG2000 + NAME:=Netgear EVG2000 + PACKAGES:=kmod-b43 wpad-mini \ + kmod-usb2 kmod-usb-ohci kmod-ledtrig-usbdev +endef +define Profile/EVG2000/Description + Package set optimized for EVG2000. +endef +$(eval $(call Profile,EVG2000)) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From zioproto at gmail.com Sun May 1 17:36:05 2016 From: zioproto at gmail.com (Saverio Proto) Date: Sun, 1 May 2016 23:36:05 +0200 Subject: [OpenWrt-Devel] [PATCH] Chaos Calmer - ramips: Fix IPv6 neighbor discovery on RT5350 Message-ID: This patch is also available here: https://github.com/zioproto/openwrt15051-batman/commit/0281382bcaa139f0d1d3b589797af4c434747f3e commit 0281382bcaa139f0d1d3b589797af4c434747f3e Author: Saverio Proto Date: Sun May 1 23:14:19 2016 +0200 ramips: Fix IPv6 neighbor discovery on RT5350 IPv6 neighbor discovery needs working IPv6 multicast. The register FCT2 should be set to 0x2500C to let through "unknown IPv6 multicast" to all ports. This is based on datasheet information: https://cdn.sparkfun.com/datasheets/Wireless/WiFi/RT5350.pdf Signed-off-by: Saverio Proto diff --git a/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c b/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c index ef13d23..d09eaf3 100644 --- a/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c +++ b/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c @@ -1360,7 +1360,7 @@ static const struct switch_dev_ops esw_ops = { static struct rt305x_esw_platform_data rt3050_esw_data = { /* All ports are LAN ports. */ .vlan_config = RT305X_ESW_VLAN_CONFIG_NONE, - .reg_initval_fct2 = 0x00d6500c, + .reg_initval_fct2 = 0x0002500c, /* * ext phy base addr 31, enable port 5 polling, rx/tx clock skew 1, * turbo mii off, rgmi 3.3v off _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at vittgam.net Sun May 1 17:59:27 2016 From: openwrt at vittgam.net (Vittorio G (VittGam)) Date: Sun, 01 May 2016 23:59:27 +0200 Subject: [OpenWrt-Devel] [PATCH] Chaos Calmer - ramips: Fix IPv6 neighbor discovery on RT5350 In-Reply-To: References: Message-ID: On 01/05/2016 23:36:05 CEST, Saverio Proto wrote: > This patch is also available here: > https://github.com/zioproto/openwrt15051-batman/commit/0281382bcaa139f0d1d3b589797af4c434747f3e > > commit 0281382bcaa139f0d1d3b589797af4c434747f3e > Author: Saverio Proto > Date: Sun May 1 23:14:19 2016 +0200 > > ramips: Fix IPv6 neighbor discovery on RT5350 > > IPv6 neighbor discovery needs working IPv6 multicast. The register FCT2 > should be set to 0x2500C to let through "unknown IPv6 multicast" to > all ports. This is based on datasheet information: > https://cdn.sparkfun.com/datasheets/Wireless/WiFi/RT5350.pdf > > Signed-off-by: Saverio Proto Reviewed-by: Vittorio Gambaletta > > diff --git a/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c > b/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c > index ef13d23..d09eaf3 100644 > --- a/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c > +++ b/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c > @@ -1360,7 +1360,7 @@ static const struct switch_dev_ops esw_ops = { > static struct rt305x_esw_platform_data rt3050_esw_data = { > /* All ports are LAN ports. */ > .vlan_config = RT305X_ESW_VLAN_CONFIG_NONE, > - .reg_initval_fct2 = 0x00d6500c, > + .reg_initval_fct2 = 0x0002500c, > /* > * ext phy base addr 31, enable port 5 polling, rx/tx clock skew 1, > * turbo mii off, rgmi 3.3v off > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From jens.steinhauser at gmail.com Sun May 1 18:05:47 2016 From: jens.steinhauser at gmail.com (Jens Steinhauser) Date: Mon, 2 May 2016 00:05:47 +0200 Subject: [OpenWrt-Devel] [RFC] ar71xx: add TP-Link TL-WR810N support In-Reply-To: References: <1460289627-27414-1-git-send-email-jens.steinhauser@gmail.com> Message-ID: <8c695c12-c8bf-ce8d-8c5e-317c9a9d7dea@gmail.com> On 04/25/2016 10:02 PM, John Crispin wrote: > Hi > > On 10/04/2016 14:00, Jens Steinhauser wrote: >> This patch adds support for the TP-Link TL-WR810N. >> https://wiki.openwrt.org/toh/tp-link/tl-wr810n >> >> The device has a slide switch to select its mode of operation when using >> the stock firmware. After looking at how it's implemented for similar >> devices, I also used 'struct gpio_keys_button { .type = EV_SW, .code = BTN_... }' >> to support the switch, but both 'switch_b0' and 'switch_b1' are missing >> when using 'evtest' and 'thd', only the 'reset' button shows up in the >> output of the programs. >> >> Changing '.code' to some SW_ value, for example SW_LID and SW_TABLET_MODE, >> makes them usable with both 'evtest' and 'thd'. Am I missing something, >> or is EV_SW + BTN_... an invalid combination? > > i use EV_SW and KEY_RFKILL on various boards and it works well. look at > package/base-files/files/etc/rc.button/rfkill to see how to handle the > events in userland > > John Thanks for the hint, indeed the switches can be used like ordinary buttons with procd. What's missing is a way to get the initial switch state after start-up, but that seems to be a limitation of the gpio-button-hotplug driver and procd, not an error in the initialization code. I'll resend the patch rebased onto current git. Jens _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From jens.steinhauser at gmail.com Sun May 1 18:08:15 2016 From: jens.steinhauser at gmail.com (Jens Steinhauser) Date: Mon, 2 May 2016 00:08:15 +0200 Subject: [OpenWrt-Devel] [PATCH] ar71xx: add TP-Link TL-WR810N support In-Reply-To: <8c695c12-c8bf-ce8d-8c5e-317c9a9d7dea@gmail.com> References: <1460289627-27414-1-git-send-email-jens.steinhauser@gmail.com> <8c695c12-c8bf-ce8d-8c5e-317c9a9d7dea@gmail.com> Message-ID: <53695a82-50ec-dd04-1065-9a38bb205bbe@gmail.com> This patch adds support for the TP-Link TL-WR810N. https://wiki.openwrt.org/toh/tp-link/tl-wr810n Signed-off-by: Jens Steinhauser --- .../linux/ar71xx/base-files/etc/board.d/02_network | 1 + target/linux/ar71xx/base-files/etc/diag.sh | 1 + target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 + .../ar71xx/base-files/lib/upgrade/platform.sh | 1 + target/linux/ar71xx/config-4.1 | 1 + target/linux/ar71xx/config-4.4 | 1 + .../ar71xx/files/arch/mips/ath79/Kconfig.openwrt | 10 ++ target/linux/ar71xx/files/arch/mips/ath79/Makefile | 1 + .../ar71xx/files/arch/mips/ath79/mach-tl-wr810n.c | 135 +++++++++++++++++++++ .../linux/ar71xx/files/arch/mips/ath79/machtypes.h | 1 + target/linux/ar71xx/generic/profiles/tp-link.mk | 11 ++ target/linux/ar71xx/image/Makefile | 8 ++ 12 files changed, 174 insertions(+) create mode 100644 target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr810n.c diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network b/target/linux/ar71xx/base-files/etc/board.d/02_network index 7724a08..67adf33 100755 --- a/target/linux/ar71xx/base-files/etc/board.d/02_network +++ b/target/linux/ar71xx/base-files/etc/board.d/02_network @@ -397,6 +397,7 @@ pb44 |\ routerstation|\ tl-wr710n |\ tl-wr720n-v3|\ +tl-wr810n |\ wpe72) ucidef_set_interfaces_lan_wan "eth1" "eth0" ;; diff --git a/target/linux/ar71xx/base-files/etc/diag.sh b/target/linux/ar71xx/base-files/etc/diag.sh index 77fa398..f95a72d 100644 --- a/target/linux/ar71xx/base-files/etc/diag.sh +++ b/target/linux/ar71xx/base-files/etc/diag.sh @@ -335,6 +335,7 @@ get_status_led() { tl-wr703n | \ tl-wr710n | \ tl-wr720n-v3 | \ + tl-wr810n | \ tl-wr941nd-v6) status_led="tp-link:blue:system" ;; diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh b/target/linux/ar71xx/base-files/lib/ar71xx.sh index 588affd..d71b8ba 100755 --- a/target/linux/ar71xx/base-files/lib/ar71xx.sh +++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh @@ -928,6 +928,9 @@ ar71xx_board_detect() { *"TL-WR720N"*) name="tl-wr720n-v3" ;; + *"TL-WR810N") + name="tl-wr810n" + ;; *"TL-MR10U") name="tl-mr10u" ;; diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh index 5334600..9f8a14b 100755 --- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh +++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh @@ -378,6 +378,7 @@ platform_check_image() { tl-wr720n-v3 | \ tl-wr741nd | \ tl-wr741nd-v4 | \ + tl-wr810n | \ tl-wr841n-v1 | \ tl-wa830re-v2 | \ tl-wr841n-v7 | \ diff --git a/target/linux/ar71xx/config-4.1 b/target/linux/ar71xx/config-4.1 index 40cf453..5939891 100644 --- a/target/linux/ar71xx/config-4.1 +++ b/target/linux/ar71xx/config-4.1 @@ -158,6 +158,7 @@ CONFIG_ATH79_MACH_TL_WR703N=y CONFIG_ATH79_MACH_TL_WR720N_V3=y CONFIG_ATH79_MACH_TL_WR741ND=y CONFIG_ATH79_MACH_TL_WR741ND_V4=y +CONFIG_ATH79_MACH_TL_WR810N=y CONFIG_ATH79_MACH_TL_WR841N_V1=y CONFIG_ATH79_MACH_TL_WR841N_V8=y CONFIG_ATH79_MACH_TL_WR841N_V9=y diff --git a/target/linux/ar71xx/config-4.4 b/target/linux/ar71xx/config-4.4 index 9c0eac4..57ac5d8 100644 --- a/target/linux/ar71xx/config-4.4 +++ b/target/linux/ar71xx/config-4.4 @@ -161,6 +161,7 @@ CONFIG_ATH79_MACH_TL_WR703N=y CONFIG_ATH79_MACH_TL_WR720N_V3=y CONFIG_ATH79_MACH_TL_WR741ND=y CONFIG_ATH79_MACH_TL_WR741ND_V4=y +CONFIG_ATH79_MACH_TL_WR810N=y CONFIG_ATH79_MACH_TL_WR841N_V1=y CONFIG_ATH79_MACH_TL_WR841N_V8=y CONFIG_ATH79_MACH_TL_WR841N_V9=y diff --git a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt index e6879a9..0fb2df2 100644 --- a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt +++ b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt @@ -1284,6 +1284,16 @@ config ATH79_MACH_TL_WR741ND_V4 select ATH79_DEV_USB select ATH79_DEV_WMAC +config ATH79_MACH_TL_WR810N + bool "TP-LINK TL-WR810N support" + select SOC_QCA953X + select ATH79_DEV_ETH + select ATH79_DEV_GPIO_BUTTONS + select ATH79_DEV_LEDS_GPIO + select ATH79_DEV_M25P80 + select ATH79_DEV_USB + select ATH79_DEV_WMAC + config ATH79_MACH_TL_WR841N_V1 bool "TP-LINK TL-WR841N v1 support" select SOC_AR71XX diff --git a/target/linux/ar71xx/files/arch/mips/ath79/Makefile b/target/linux/ar71xx/files/arch/mips/ath79/Makefile index 61dfccc..6144e29 100644 --- a/target/linux/ar71xx/files/arch/mips/ath79/Makefile +++ b/target/linux/ar71xx/files/arch/mips/ath79/Makefile @@ -159,6 +159,7 @@ obj-$(CONFIG_ATH79_MACH_TL_WDR4300) += mach-tl-wdr4300.o obj-$(CONFIG_ATH79_MACH_TL_WDR6500_V2) += mach-tl-wdr6500-v2.o obj-$(CONFIG_ATH79_MACH_TL_WR741ND) += mach-tl-wr741nd.o obj-$(CONFIG_ATH79_MACH_TL_WR741ND_V4) += mach-tl-wr741nd-v4.o +obj-$(CONFIG_ATH79_MACH_TL_WR810N) += mach-tl-wr810n.o obj-$(CONFIG_ATH79_MACH_TL_WR841N_V1) += mach-tl-wr841n.o obj-$(CONFIG_ATH79_MACH_TL_WR841N_V8) += mach-tl-wr841n-v8.o obj-$(CONFIG_ATH79_MACH_TL_WR841N_V9) += mach-tl-wr841n-v9.o diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr810n.c b/target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr810n.c new file mode 100644 index 0000000..906c5f8 --- /dev/null +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr810n.c @@ -0,0 +1,135 @@ +/* + * TP-LINK TL-WR810N board support + * + * Copyright (c) 2012 Qualcomm Atheros + * Copyright (c) 2012 Gabor Juhos + * Copyright (c) 2016 Jens Steinhauser + * + * Permission to use, copy, modify, and/or distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + */ + +#include +#include +#include + +#include + +#include "common.h" +#include "dev-gpio-buttons.h" +#include "dev-eth.h" +#include "dev-leds-gpio.h" +#include "dev-m25p80.h" +#include "dev-usb.h" +#include "dev-wmac.h" +#include "machtypes.h" + +#define TL_WR810N_GPIO_SWITCH_B1 0 +#define TL_WR810N_GPIO_SWITCH_B0 1 +#define TL_WR810N_GPIO_USB_POWER 11 +#define TL_WR810N_GPIO_BTN_RESET 12 +#define TL_WR810N_GPIO_LED_SYSTEM 13 + +#define TL_WR810N_KEYS_POLL_INTERVAL 20 /* msecs */ +#define TL_WR810N_KEYS_DEBOUNCE_INTERVAL (3 * TL_WR810N_KEYS_POLL_INTERVAL) + +#define TL_WR810N_WMAC_CALDATA_OFFSET 0x1000 + +static const char *tl_wr810n_part_probes[] = { + "tp-link", + NULL, +}; + +static struct flash_platform_data tl_wr810n_flash_data = { + .part_probes = tl_wr810n_part_probes, +}; + +static struct gpio_led tl_wr810n_leds_gpio[] __initdata = { + { + .name = "tp-link:blue:system", + .gpio = TL_WR810N_GPIO_LED_SYSTEM, + .active_low = 1, + }, +}; + +static struct gpio_keys_button tl_wr810n_gpio_keys[] __initdata = { + { + .desc = "reset", + .type = EV_KEY, + .code = KEY_RESTART, + .debounce_interval = TL_WR810N_KEYS_DEBOUNCE_INTERVAL, + .gpio = TL_WR810N_GPIO_BTN_RESET, + .active_low = 1, + }, + { + .desc = "switch_b0", + .type = EV_SW, + .code = BTN_0, + .debounce_interval = TL_WR810N_KEYS_DEBOUNCE_INTERVAL, + .gpio = TL_WR810N_GPIO_SWITCH_B0, + .active_low = 0, + }, + { + .desc = "switch_b1", + .type = EV_SW, + .code = BTN_1, + .debounce_interval = TL_WR810N_KEYS_DEBOUNCE_INTERVAL, + .gpio = TL_WR810N_GPIO_SWITCH_B1, + .active_low = 0, + }, +}; + +static void __init tl_wr810n_setup(void) +{ + u8 *mac = (u8 *) KSEG1ADDR(0x1f01fc00); + u8 *art = (u8 *) KSEG1ADDR(0x1fff0000); + + ath79_setup_ar933x_phy4_switch(false, false); + + ath79_register_m25p80(&tl_wr810n_flash_data); + ath79_register_leds_gpio(-1, + ARRAY_SIZE(tl_wr810n_leds_gpio), + tl_wr810n_leds_gpio); + ath79_register_gpio_keys_polled(-1, + TL_WR810N_KEYS_POLL_INTERVAL, + ARRAY_SIZE(tl_wr810n_gpio_keys), + tl_wr810n_gpio_keys); + + ath79_register_mdio(0, 0x0); + + /* WAN */ + ath79_eth0_data.duplex = DUPLEX_FULL; + ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_MII; + ath79_eth0_data.speed = SPEED_100; + ath79_eth0_data.phy_mask = BIT(4); + ath79_init_mac(ath79_eth0_data.mac_addr, mac, 1); + ath79_register_eth(0); + + /* LAN */ + ath79_switch_data.phy4_mii_en = 1; + ath79_eth1_data.duplex = DUPLEX_FULL; + ath79_eth1_data.phy_if_mode = PHY_INTERFACE_MODE_GMII; + ath79_eth1_data.speed = SPEED_1000; + ath79_switch_data.phy_poll_mask |= BIT(4); + ath79_init_mac(ath79_eth1_data.mac_addr, mac, -1); + ath79_register_eth(1); + + ath79_register_wmac(art + TL_WR810N_WMAC_CALDATA_OFFSET, mac); + + gpio_request_one(TL_WR810N_GPIO_USB_POWER, + GPIOF_OUT_INIT_HIGH | GPIOF_EXPORT_DIR_FIXED, + "USB power"); + ath79_register_usb(); +} + +MIPS_MACHINE(ATH79_MACH_TL_WR810N, "TL-WR810N", "TP-LINK TL-WR810N", + tl_wr810n_setup); diff --git a/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h b/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h index b2df9c4..4879255 100644 --- a/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h +++ b/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h @@ -193,6 +193,7 @@ enum ath79_mach_type { ATH79_MACH_TL_WR720N_V3, /* TP-LINK TL-WR720N v3/v4 */ ATH79_MACH_TL_WR741ND, /* TP-LINK TL-WR741ND */ ATH79_MACH_TL_WR741ND_V4, /* TP-LINK TL-WR741ND v4 */ + ATH79_MACH_TL_WR810N, /* TP-LINK TL-WR810N */ ATH79_MACH_TL_WR841N_V1, /* TP-LINK TL-WR841N v1 */ ATH79_MACH_TL_WR841N_V7, /* TP-LINK TL-WR841N/ND v7 */ ATH79_MACH_TL_WR841N_V8, /* TP-LINK TL-WR841N/ND v8 */ diff --git a/target/linux/ar71xx/generic/profiles/tp-link.mk b/target/linux/ar71xx/generic/profiles/tp-link.mk index 2875290..c44b22c 100644 --- a/target/linux/ar71xx/generic/profiles/tp-link.mk +++ b/target/linux/ar71xx/generic/profiles/tp-link.mk @@ -332,6 +332,17 @@ endef $(eval $(call Profile,TLWR743)) +define Profile/TLWR810 + NAME:=TP-Link TL-WR810N + PACKAGES:=kmod-usb-core kmod-usb2 +endef + +define Profile/TLWR810/Description + Package set optimized for the TP-LINK TL-WR810N. +endef +$(eval $(call Profile,TLWR810)) + + define Profile/TLWR841 NAME:=TP-LINK TL-WR841N/ND PACKAGES:= diff --git a/target/linux/ar71xx/image/Makefile b/target/linux/ar71xx/image/Makefile index 3bf005f..bc8a4a8 100644 --- a/target/linux/ar71xx/image/Makefile +++ b/target/linux/ar71xx/image/Makefile @@ -799,6 +799,14 @@ define Device/tl-wr741nd-v5 CONSOLE := ttyATH0,115200 endef +define Device/tl-wr810n + $(Device/tplink-8mlzma) + BOARDNAME := TL-WR810N + DEVICE_PROFILE := TLWR810 + TPLINK_HWID := 0x08100001 +endef +TARGET_DEVICES += tl-wr810n + define Device/tl-wr743nd-v1 $(Device/tplink-4m) BOARDNAME := TL-WR741ND -- 2.5.5 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From mail.gery at gmail.com Sun May 1 20:46:33 2016 From: mail.gery at gmail.com (Gergely Kiss) Date: Mon, 2 May 2016 02:46:33 +0200 Subject: [OpenWrt-Devel] [PATCH] libiconv: add all ASCII aliases Message-ID: <5726A369.1090704@gmail.com> This patch adds missing ASCII aliases to the libiconv stub in order to avoid conversion errors like https://github.com/openwrt/packages/issues/2373 Signed-off-by: Gergely Kiss --- package/libs/libiconv/Makefile | 2 +- package/libs/libiconv/src/iconv.c | 9 +++++++++ 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/package/libs/libiconv/Makefile b/package/libs/libiconv/Makefile index 7d9ba4c..9716261 100644 --- a/package/libs/libiconv/Makefile +++ b/package/libs/libiconv/Makefile @@ -11,7 +11,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=libiconv -PKG_RELEASE:=7 +PKG_RELEASE:=8 PKG_LICENSE:=LGPL-2.1 PKG_LICENSE_FILES:=LICENSE diff --git a/package/libs/libiconv/src/iconv.c b/package/libs/libiconv/src/iconv.c index d2e19e3..c3cfefa 100644 --- a/package/libs/libiconv/src/iconv.c +++ b/package/libs/libiconv/src/iconv.c @@ -44,6 +44,15 @@ static const unsigned char charsets[] = "\003" "UTF-32LE" "\0" "\006" "ASCII" "\0" "\006" "US-ASCII" "\0" + "\006" "ISO646-US" "\0" + "\006" "ISO_646.IRV:1991" "\0" + "\006" "ISO-IR-6" "\0" + "\006" "ANSI_X3.4-1968" "\0" + "\006" "ANSI_X3.4-1986" "\0" + "\006" "CP367" "\0" + "\006" "IBM367" "\0" + "\006" "US" "\0" + "\006" "CSASCII" "\0" "\007" "ISO-8859-1" "\0" "\007" "LATIN1" "\0" "\010" "ISO-8859-15""\0" -- 1.8.3.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at vittgam.net Sun May 1 23:28:12 2016 From: openwrt at vittgam.net (Vittorio Gambaletta (VittGam)) Date: Mon, 2 May 2016 05:28:12 +0200 Subject: [OpenWrt-Devel] [PATCH] base-files: Fix config_generate when there are no switch VLANs or ports configured in board.json. Message-ID: The json_select call fails when there are no roles or ports objects in board.json. "json_select .." must not be executed after failing. This fixes for example LEDs not being set up in /etc/config/system. Signed-off-by: Vittorio Gambaletta --- --- a/package/base-files/files/bin/config_generate +++ b/package/base-files/files/bin/config_generate @@ -144,22 +144,24 @@ generate_switch_vlans_ports() { # json_get_keys roles roles - json_select roles + if [ -n "$roles" ]; then + json_select roles - for role in $roles; do - json_select "$role" - json_get_vars ports - json_select .. + for role in $roles; do + json_select "$role" + json_get_vars ports + json_select .. - uci -q batch <<-EOF - add network switch_vlan - set network. at switch_vlan[-1].device='$switch' - set network. at switch_vlan[-1].vlan='$role' - set network. at switch_vlan[-1].ports='$ports' - EOF - done + uci -q batch <<-EOF + add network switch_vlan + set network. at switch_vlan[-1].device='$switch' + set network. at switch_vlan[-1].vlan='$role' + set network. at switch_vlan[-1].ports='$ports' + EOF + done - json_select .. + json_select .. + fi # @@ -167,31 +169,33 @@ generate_switch_vlans_ports() { # json_get_keys ports ports - json_select ports + if [ -n "$ports" ]; then + json_select ports + + for port in $ports; do + json_select "$port" + json_get_vars num + + if json_is_a attr object; then + json_get_keys attr attr + json_select attr + uci -q batch <<-EOF + add network switch_port + set network. at switch_port[-1].device='$switch' + set network. at switch_port[-1].port=$num + EOF + + for attr in $attr; do + json_get_var val "$attr" + uci -q set network. at switch_port[-1].$attr="$val" + done + json_select .. + fi + json_select .. + done - for port in $ports; do - json_select "$port" - json_get_vars num - - if json_is_a attr object; then - json_get_keys attr attr - json_select attr - uci -q batch <<-EOF - add network switch_port - set network. at switch_port[-1].device='$switch' - set network. at switch_port[-1].port=$num - EOF - - for attr in $attr; do - json_get_var val "$attr" - uci -q set network. at switch_port[-1].$attr="$val" - done - json_select .. - fi json_select .. - done - - json_select .. + fi } generate_switch() { _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at vittgam.net Sun May 1 23:28:41 2016 From: openwrt at vittgam.net (Vittorio Gambaletta (VittGam)) Date: Mon, 2 May 2016 05:28:41 +0200 Subject: [OpenWrt-Devel] [PATCH] ramips: Drop hacky switch workaround for failsafe on rt3x5x and rt5350. Message-ID: The new rt3050 switch driver doesn't have problems with TCP when not using VLANs. This piece of code also broke failsafe for all routers where the LAN port is not wired to port 0 of the internal switch. Signed-off-by: Vittorio Gambaletta --- --- a/target/linux/ramips/base-files/lib/preinit/07_set_preinit_iface_ramips +++ b/target/linux/ramips/base-files/lib/preinit/07_set_preinit_iface_ramips @@ -6,43 +6,24 @@ . /lib/ramips.sh ramips_set_preinit_iface() { - RT3X5X=`cat /proc/cpuinfo | egrep "(RT3.5|RT5350|MT7628|MT7688)"` - MT762X=`cat /proc/cpuinfo | egrep "MT7620"` + RT3X5X=`cat /proc/cpuinfo | egrep "(RT3.5|RT5350|MT7628|MT7688|MT7620)"` if [ -n "${RT3X5X}" ]; then - swconfig dev rt305x set reset 1 - elif [ -n "${MT762X}" ]; then - # The mt7530 switch driver enables VLAN by default, but + # The ethernet switch driver enables VLAN by default, but # failsafe uses eth0, making the device unreachable: # https://dev.openwrt.org/ticket/18768 - case "${MT762X}" in + ralink_switchdev=rt305x + case "${RT3X5X}" in *MT7620*) - mt762x_switchdev=mt7620 + ralink_switchdev=mt7620 ;; esac - swconfig dev $mt762x_switchdev set reset 1 - swconfig dev $mt762x_switchdev set enable_vlan 0 - swconfig dev $mt762x_switchdev set apply 1 + swconfig dev $ralink_switchdev set reset 1 + swconfig dev $ralink_switchdev set enable_vlan 0 + swconfig dev $ralink_switchdev set apply 1 fi - if echo $RT3X5X | egrep -q "(RT5350|MT7628|MT7688)"; then - # This is a dirty hack to get by while the switch - # problem is investigated. When VLAN is disabled, ICMP - # pings work as expected, but TCP connections time - # out, so telnetting in failsafe is impossible. The - # likely reason is TCP checksumming hardware getting - # disabled: - # https://www.mail-archive.com/openwrt-devel at lists.openwrt.org/msg19870.html - swconfig dev rt305x set enable_vlan 1 - swconfig dev rt305x vlan 1 set ports "0 6" - swconfig dev rt305x port 6 set untag 0 - swconfig dev rt305x set apply 1 - ip link add link eth0 name eth0.1 type vlan id 1 - ip link set eth0 up - ifname=eth0.1 - else - ifname=eth0 - fi + ifname=eth0 } boot_hook_add preinit_main ramips_set_preinit_iface _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at vittgam.net Sun May 1 23:29:58 2016 From: openwrt at vittgam.net (Vittorio Gambaletta (VittGam)) Date: Mon, 2 May 2016 05:29:58 +0200 Subject: [OpenWrt-Devel] [PATCH] firewall3: Fix multicast ICMPv6 replies not being sent by default anymore. Message-ID: Since drop_invalid has been turned on by default, ICMPv6 echo requests to well-known multicast addresses, such as ff02::1, are not replied to by the router anymore, because conntrack considers those outgoing reply packets to be invalid. Fix this by not having the INVALID rule in the OUTPUT chain match IPv6 packets destined to link-local addresses (fe80::/10). Signed-off-by: Vittorio Gambaletta --- --- a/defaults.c +++ b/defaults.c @@ -222,6 +222,16 @@ fw3_print_default_head_rules(struct fw3_ if (defs->drop_invalid) { r = fw3_ipt_rule_new(handle); + if (i == 2 && handle->family == FW3_FAMILY_V6) { + struct fw3_address mcdst = { + .set = true, + .invert = true, + .family = FW3_FAMILY_V6, + .address.v6.s6_addr = { 0xfe, 0x80 }, + .mask.v6.s6_addr = { 0xff, 0xc0 }, + }; + fw3_ipt_rule_src_dest(r, NULL, &mcdst); + } fw3_ipt_rule_extra(r, "-m conntrack --ctstate INVALID"); fw3_ipt_rule_target(r, "DROP"); fw3_ipt_rule_append(r, chains[i]); _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at vittgam.net Sun May 1 23:34:52 2016 From: openwrt at vittgam.net (Vittorio Gambaletta (VittGam)) Date: Mon, 2 May 2016 05:34:52 +0200 Subject: [OpenWrt-Devel] [PATCH 1/6] ramips: Fix multicast ICMPv6 for the rt3050 ethernet switch. Message-ID: The FCT2 esw register should be set to 0x2500C to have "unknown IPv6 multicast" packets broadcasted to every port, instead of dropped. The previous value only let those packets go through ports 1 and 3. "Unknown IPv6 multicast" packets include packets needed by ICMPv6 echo requests addressed to well-known addresses, such as ff02::1 (MAC address is 33:33:00:00:00:01 in this case). Please note that by default ICMPv6 echo requests to ff02::1 are not replied to by the router because of ip6tables considering those packets to be invalid. But this is another bug/patch. ;) Signed-off-by: Vittorio Gambaletta --- --- /dev/null +++ b/target/linux/ramips/patches-4.4/0515-net-mediatek-fix-multicast-icmpv6-for-the-rt3050-eth.patch @@ -0,0 +1,26 @@ +From: Vittorio Gambaletta +Date: Mon, 02 May 2016 04:55:48 +0200 +Subject: [PATCH] net: mediatek: Fix multicast ICMPv6 for the rt3050 ethernet switch. + +The FCT2 esw register should be set to 0x2500C to have "unknown IPv6 +multicast" packets broadcasted to every port, instead of dropped. +The previous value only let those packets go through ports 1 and 3. + +"Unknown IPv6 multicast" packets include packets needed by ICMPv6 echo +requests addressed to well-known addresses, such as ff02::1 (MAC address +is 33:33:00:00:00:01 in this case). + +Signed-off-by: Vittorio Gambaletta +--- + +--- a/drivers/net/ethernet/mediatek/esw_rt3050.c ++++ b/drivers/net/ethernet/mediatek/esw_rt3050.c +@@ -450,7 +450,7 @@ static void esw_hw_init(struct rt305x_es + (RT305X_ESW_PORTS_NOCPU << RT305X_ESW_POC2_UNTAG_EN_S)), + RT305X_ESW_REG_POC2); + +- esw_w32(esw, 0x00d6500c, RT305X_ESW_REG_FCT2); ++ esw_w32(esw, 0x0002500c, RT305X_ESW_REG_FCT2); + + /* 300s aging timer, max packet len 1536, broadcast storm prevention + * disabled, disable collision abort, mac xor48 hash, 10 packet back _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at vittgam.net Sun May 1 23:34:52 2016 From: openwrt at vittgam.net (Vittorio Gambaletta (VittGam)) Date: Mon, 2 May 2016 05:34:52 +0200 Subject: [OpenWrt-Devel] [PATCH 2/6] ramips: Fix documentation for the rt3050 switch driver. In-Reply-To: References: Message-ID: The prefix used in the driver is now "mediatek" instead of "ralink". Signed-off-by: Vittorio Gambaletta --- --- /dev/null +++ b/target/linux/ramips/patches-4.4/0516-Documentation-DT-net-mediatek-fix-documentation-for-.patch @@ -0,0 +1,23 @@ +From: Vittorio Gambaletta +Date: Fri, 01 Jan 2016 00:00:00 +0100 +Subject: [PATCH 1/3] Documentation: DT: net: mediatek: Fix documentation for the rt3050 switch driver. + +The prefix used in the driver is now "mediatek" instead of "ralink". + +Signed-off-by: Vittorio Gambaletta +--- + +--- a/Documentation/devicetree/bindings/net/ralink,rt3050-esw.txt ++++ b/Documentation/devicetree/bindings/net/ralink,rt3050-esw.txt +@@ -14,9 +14,9 @@ Required properties: + - reset-names: Should contain the reset names "esw" + + Optional properties: +-- ralink,portmap: can be used to choose if the default switch setup is ++- mediatek,portmap: can be used to choose if the default switch setup is + llllw or wllll +-- ralink,led_polarity: override the active high/low settings of the leds ++- mediatek,led_polarity: override the active high/low settings of the leds + + Example: + _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at vittgam.net Sun May 1 23:34:53 2016 From: openwrt at vittgam.net (Vittorio Gambaletta (VittGam)) Date: Mon, 2 May 2016 05:34:53 +0200 Subject: [OpenWrt-Devel] [PATCH 3/6] ramips: Fix comment in rt3050 ethernet switch driver. In-Reply-To: References: Message-ID: Line 444 is actually enabling all switch ports by setting the disable bits to 0. This needs to be done because the bootloader sets all ports to disabled by default (which is the case for at least one router based on RT5350). So, this patch fixes the comment in line 443. Signed-off-by: Vittorio Gambaletta --- --- /dev/null +++ b/target/linux/ramips/patches-4.4/0517-net-mediatek-fix-comment-in-rt3050-ethernet-switch-d.patch @@ -0,0 +1,24 @@ +From: Vittorio Gambaletta +Date: Fri, 01 Jan 2016 00:00:01 +0100 +Subject: [PATCH 2/3] net: mediatek: Fix comment in rt3050 ethernet switch driver. + +Line 444 is actually enabling all switch ports by setting the disable bits +to 0. This needs to be done because the bootloader sets all ports to disabled +by default (which is the case for at least one router based on RT5350). + +So, this patch fixes the comment in line 443. + +Signed-off-by: Vittorio Gambaletta +--- + +--- a/drivers/net/ethernet/mediatek/esw_rt3050.c ++++ b/drivers/net/ethernet/mediatek/esw_rt3050.c +@@ -440,7 +440,7 @@ static void esw_hw_init(struct rt305x_es + (RT305X_ESW_PORTS_ALL << RT305X_ESW_PFC1_EN_VLAN_S), + RT305X_ESW_REG_PFC1); + +- /* Enable Back Pressure, and Flow Control */ ++ /* Enable all ports, Back Pressure and Flow Control */ + esw_w32(esw, ((RT305X_ESW_PORTS_ALL << RT305X_ESW_POC0_EN_BP_S) | + (RT305X_ESW_PORTS_ALL << RT305X_ESW_POC0_EN_FC_S)), + RT305X_ESW_REG_POC0); _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at vittgam.net Sun May 1 23:34:53 2016 From: openwrt at vittgam.net (Vittorio Gambaletta (VittGam)) Date: Mon, 2 May 2016 05:34:53 +0200 Subject: [OpenWrt-Devel] [PATCH 4/6] ramips: Get rt3050 ethernet ports to be disabled from the device tree. In-Reply-To: References: Message-ID: This patch allows configuring ports to be disabled in the device tree; this saves power, since disabling ports here actually disables power to ethernet PHYs. Line 444 enables all ethernet ports, so line 487 is getting zero ports to be disabled, except for port 5 in SoCs where this is not implemented as it will be sticky disabled in register POC0. Because of this, the code will still read the switch configuration and OR it to the device tree setting. Signed-off-by: Vittorio Gambaletta --- --- /dev/null +++ b/target/linux/ramips/patches-4.4/0518-net-mediatek-get-rt3050-ethernet-ports-to-be-disable.patch @@ -0,0 +1,81 @@ +From: Vittorio Gambaletta +Date: Fri, 01 Jan 2016 00:00:02 +0100 +Subject: [PATCH 3/3] net: mediatek: Get rt3050 ethernet ports to be disabled from the device tree. + +This patch allows configuring ports to be disabled in the device tree; this +saves power, since disabling ports here actually disables power to ethernet +PHYs. + +Line 444 enables all ethernet ports, so line 487 is getting zero ports to be +disabled, except for port 5 in SoCs where this is not implemented as it will +be sticky disabled in register POC0. Because of this, the code will still read +the switch configuration and OR it to the device tree setting. + +Signed-off-by: Vittorio Gambaletta +--- + +--- a/drivers/net/ethernet/mediatek/esw_rt3050.c ++++ b/drivers/net/ethernet/mediatek/esw_rt3050.c +@@ -10,6 +10,7 @@ + * Copyright (C) 2009-2015 John Crispin + * Copyright (C) 2009-2015 Felix Fietkau + * Copyright (C) 2013-2015 Michael Lee ++ * Copyright (C) 2016 Vittorio Gambaletta + */ + + #include +@@ -219,6 +220,7 @@ struct rt305x_esw { + spinlock_t reg_rw_lock; + + unsigned char port_map; ++ unsigned char port_disable; + unsigned int reg_led_polarity; + + struct switch_dev swdev; +@@ -483,8 +485,14 @@ static void esw_hw_init(struct rt305x_es + esw_w32(esw, 0x00000005, RT305X_ESW_REG_P3LED); + esw_w32(esw, 0x00000005, RT305X_ESW_REG_P4LED); + +- /* Copy disabled port configuration from bootloader setup */ +- port_disable = esw_get_port_disable(esw); ++ /* Copy disabled port configuration from device tree setup */ ++ port_disable = esw->port_disable; ++ ++ /* Disable nonexistent ports by reading the switch config ++ * after having enabled all possible ports above ++ */ ++ port_disable |= esw_get_port_disable(esw); ++ + for (i = 0; i < 6; i++) + esw->ports[i].disable = (port_disable & (1 << i)) != 0; + +@@ -1330,7 +1338,7 @@ static int esw_probe(struct platform_dev + { + struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + struct device_node *np = pdev->dev.of_node; +- const __be32 *port_map, *reg_init; ++ const __be32 *port_map, *port_disable, *reg_init; + struct switch_dev *swdev; + struct rt305x_esw *esw; + int ret; +@@ -1349,6 +1357,10 @@ static int esw_probe(struct platform_dev + if (port_map) + esw->port_map = be32_to_cpu(*port_map); + ++ port_disable = of_get_property(np, "mediatek,portdisable", NULL); ++ if (port_disable) ++ esw->port_disable = be32_to_cpu(*port_disable); ++ + reg_init = of_get_property(np, "mediatek,led_polarity", NULL); + if (reg_init) + esw->reg_led_polarity = be32_to_cpu(*reg_init); +--- a/Documentation/devicetree/bindings/net/ralink,rt3050-esw.txt ++++ b/Documentation/devicetree/bindings/net/ralink,rt3050-esw.txt +@@ -16,6 +16,7 @@ Required properties: + Optional properties: + - mediatek,portmap: can be used to choose if the default switch setup is + llllw or wllll ++- mediatek,portdisable: disable unused ethernet PHYs to save power + - mediatek,led_polarity: override the active high/low settings of the leds + + Example: _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at vittgam.net Sun May 1 23:34:54 2016 From: openwrt at vittgam.net (Vittorio Gambaletta (VittGam)) Date: Mon, 2 May 2016 05:34:54 +0200 Subject: [OpenWrt-Devel] [PATCH 5/6] ramips: Disable all ethernet ports except port 4 on HT-TM02. In-Reply-To: References: Message-ID: Port 4 is the only ethernet port on this router, so disable all other PHYs in order to save power. Signed-off-by: Vittorio Gambaletta --- --- a/target/linux/ramips/dts/HT-TM02.dts +++ b/target/linux/ramips/dts/HT-TM02.dts @@ -63,6 +63,7 @@ esw at 10110000 { mediatek,portmap = <0x10>; + mediatek,portdisable = <0x2f>; }; wmac at 10180000 { _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at vittgam.net Sun May 1 23:34:54 2016 From: openwrt at vittgam.net (Vittorio Gambaletta (VittGam)) Date: Mon, 2 May 2016 05:34:54 +0200 Subject: [OpenWrt-Devel] [PATCH 6/6] ramips: Disable all ethernet ports except port 0 on A5-V11. In-Reply-To: References: Message-ID: Port 0 is the only ethernet port on this router, so disable all other PHYs in order to save power. Signed-off-by: Vittorio Gambaletta --- --- a/target/linux/ramips/dts/A5-V11.dts +++ b/target/linux/ramips/dts/A5-V11.dts @@ -62,7 +62,8 @@ }; esw at 10110000 { - mediatek,portmap = <0x2f>; + mediatek,portmap = <0x1>; + mediatek,portdisable = <0x3e>; }; wmac at 10180000 { _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at vittgam.net Sun May 1 23:50:34 2016 From: openwrt at vittgam.net (Vittorio Gambaletta (VittGam)) Date: Mon, 2 May 2016 05:50:34 +0200 Subject: [OpenWrt-Devel] [PATCH 1/2] ramips: Fix network for routers without VLANs on eth0. Message-ID: Some routers only have one port, so eth0 is used without VLANs for them. Revision r47720 introduced some changes, but wrongly confused "enable" with "reset". VLANs need to be disabled for those routers, and the switch may be reset. Fix this, by explicitly disabling VLANs instead of resetting the switch for these routers. Also merge duplicate configuration for the "m2m". Signed-off-by: Vittorio Gambaletta --- --- a/target/linux/ramips/base-files/etc/board.d/02_network +++ b/target/linux/ramips/base-files/etc/board.d/02_network @@ -44,13 +44,14 @@ ramips_setup_interfaces() ht-tm02|\ linkits7688 | \ linkits7688d | \ + m2m|\ microwrt|\ ncs601w|\ w150m|\ wnce2001|\ zte-q7) ucidef_add_switch "switch0" - ucidef_add_switch_attr "switch0" "reset" "false" + ucidef_add_switch_attr "switch0" "enable" "false" ucidef_set_interface_lan "eth0" ;; 3g-6200nl|\ @@ -180,11 +181,6 @@ ramips_setup_interfaces() ucidef_add_switch "switch0" \ "1:lan" "2:lan" "3:lan" "4:lan" "5:lan" "0:wan" "6 at eth0" ;; - m2m) - ucidef_add_switch "switch0" - ucidef_add_switch_attr "switch0" "reset" "false" - ucidef_set_interface_lan "eth0" - ;; mlwg2|\ wizard8800|\ wl-330n|\ _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at vittgam.net Sun May 1 23:50:35 2016 From: openwrt at vittgam.net (Vittorio Gambaletta (VittGam)) Date: Mon, 2 May 2016 05:50:35 +0200 Subject: [OpenWrt-Devel] [PATCH 2/2] ramips: Don't use a VLAN for the single ethernet port of the A5-V11. In-Reply-To: References: Message-ID: This router only has one ethernet port, so a VLAN is useless here, now that the rt3050 TCP bug that happened without VLANs has been fixed for a very long time. Add this router to the VLAN-less config that is used by other single-port routers. Also fix MAC address detection code since this router has no WAN port. Signed-off-by: Vittorio Gambaletta --- --- a/target/linux/ramips/base-files/etc/board.d/02_network +++ b/target/linux/ramips/base-files/etc/board.d/02_network @@ -35,6 +35,7 @@ ramips_setup_interfaces() case $board in 3g150b|\ 3g300m|\ + a5-v11|\ all0256n|\ all5002|\ all5003|\ @@ -93,10 +94,6 @@ ramips_setup_interfaces() ucidef_add_switch "switch0" \ "0:lan" "1:lan" "2:lan" "3:lan" "4:wan" "6 at eth0" ;; - a5-v11) - ucidef_add_switch "switch0" \ - "0:lan" "6t at eth0" - ;; ar670w|\ ar725w|\ rt-n15|\ @@ -241,7 +238,6 @@ ramips_setup_macs() local wan_mac="" case $board in - a5-v11|\ bc2|\ broadway|\ d105|\ @@ -285,6 +281,7 @@ ramips_setup_macs() [ -n "$lan_mac" ] || lan_mac=$(cat /sys/class/net/eth0/address) wan_mac=$(macaddr_add "$lan_mac" 1) ;; + a5-v11|\ ht-tm02) lan_mac=$(cat /sys/class/net/eth0/address) ;; _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at vittgam.net Mon May 2 00:20:14 2016 From: openwrt at vittgam.net (Vittorio Gambaletta (VittGam)) Date: Mon, 2 May 2016 06:20:14 +0200 Subject: [OpenWrt-Devel] [PATCH] [CC] ramips: Backport changes to 07_set_preinit_iface_ramips from trunk. Message-ID: Fix failsafe for all rt3050 routers where the LAN port is not wired to port 0 of the internal switch. Fix failsafe for MT7620-based routers. Fix ticket #18768. Signed-off-by: Vittorio Gambaletta --- --- a/target/linux/ramips/base-files/lib/preinit/07_set_preinit_iface_ramips +++ b/target/linux/ramips/base-files/lib/preinit/07_set_preinit_iface_ramips @@ -6,29 +6,24 @@ . /lib/ramips.sh ramips_set_preinit_iface() { - RT3X5X=`cat /proc/cpuinfo | egrep "(RT3.5|RT5350|MT7628|MT7688)"` + RT3X5X=`cat /proc/cpuinfo | egrep "(RT3.5|RT5350|MT7628|MT7688|MT7620)"` + if [ -n "${RT3X5X}" ]; then - swconfig dev rt305x set reset 1 + # The ethernet switch driver enables VLAN by default, but + # failsafe uses eth0, making the device unreachable: + # https://dev.openwrt.org/ticket/18768 + ralink_switchdev=rt305x + case "${RT3X5X}" in + *MT7620*) + ralink_switchdev=mt7620 + ;; + esac + swconfig dev $ralink_switchdev set reset 1 + swconfig dev $ralink_switchdev set enable_vlan 0 + swconfig dev $ralink_switchdev set apply 1 fi - if echo $RT3X5X | egrep -q "(RT5350|MT7628|MT7688)"; then - # This is a dirty hack to get by while the switch - # problem is investigated. When VLAN is disabled, ICMP - # pings work as expected, but TCP connections time - # out, so telnetting in failsafe is impossible. The - # likely reason is TCP checksumming hardware getting - # disabled: - # https://www.mail-archive.com/openwrt-devel at lists.openwrt.org/msg19870.html - swconfig dev rt305x set enable_vlan 1 - swconfig dev rt305x vlan 1 set ports "0 6" - swconfig dev rt305x port 6 set untag 0 - swconfig dev rt305x set apply 1 - vconfig add eth0 1 - ifconfig eth0 up - ifname=eth0.1 - else - ifname=eth0 - fi + ifname=eth0 } boot_hook_add preinit_main ramips_set_preinit_iface _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at vittgam.net Mon May 2 00:32:58 2016 From: openwrt at vittgam.net (Vittorio Gambaletta (VittGam)) Date: Mon, 2 May 2016 06:32:58 +0200 Subject: [OpenWrt-Devel] [PATCH] [CC] ramips: Backport changes to 02_network. Message-ID: The A5-V11 only has one ethernet port, so a VLAN is useless here, now that the rt3050 TCP bug that happened without VLANs has been fixed for a very long time. Add this router to the VLAN-less config that is used by other single-port routers. Also fix MAC address detection code since this router has no WAN port. Also merge duplicate configuration for the "m2m". Signed-off-by: Vittorio Gambaletta --- --- a/target/linux/ramips/base-files/etc/board.d/02_network +++ b/target/linux/ramips/base-files/etc/board.d/02_network @@ -37,14 +37,9 @@ ramips_setup_interfaces() ucidef_set_interface_loopback case $board in - a5-v11) - ucidef_set_interface_lan "eth0.1" - ucidef_add_switch "switch0" "1" "1" - ucidef_add_switch_vlan "switch0" "1" "0 6t" - ;; - 3g150b | \ 3g300m | \ + a5-v11 | \ linkits7688 | \ linkits7688d | \ microwrt | \ @@ -57,6 +52,7 @@ ramips_setup_interfaces() dcs-930| \ dcs-930l-b1| \ ht-tm02| \ + m2m| \ ncs601w | \ wnce2001) ucidef_add_switch "switch0" "1" "0" @@ -72,11 +68,6 @@ ramips_setup_interfaces() ucidef_set_interface_lan "eth0.1" ;; - m2m) - ucidef_add_switch "switch0" "4" - ucidef_set_interface_lan "eth0" - ;; - wizard8800 | \ wl-330n | \ wmr300) @@ -315,7 +306,6 @@ ramips_setup_macs() lan_mac=$(macaddr_add "$lan_mac" -2) ;; - a5-v11 |\ bc2 |\ broadway |\ d105 |\ @@ -336,6 +326,7 @@ ramips_setup_macs() wan_mac=$(macaddr_add "$lan_mac" 1) ;; + a5-v11|\ ht-tm02) lan_mac=$(cat /sys/class/net/eth0/address) ;; _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at vittgam.net Mon May 2 00:32:59 2016 From: openwrt at vittgam.net (Vittorio Gambaletta (VittGam)) Date: Mon, 2 May 2016 06:32:59 +0200 Subject: [OpenWrt-Devel] [PATCH] [CC] ramips: Disable all ethernet ports except port 0 on A5-V11. Message-ID: Port 0 is the only ethernet port on this router, so disable all other PHYs in order to save power. Signed-off-by: Vittorio Gambaletta --- --- a/target/linux/ramips/dts/A5-V11.dts +++ b/target/linux/ramips/dts/A5-V11.dts @@ -60,7 +60,8 @@ }; esw at 10110000 { - ralink,portmap = <0x2f>; + ralink,portmap = <0x1>; + ralink,portdisable = <0x3e>; }; wmac at 10180000 { _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at vittgam.net Mon May 2 03:55:32 2016 From: openwrt at vittgam.net (Vittorio G (VittGam)) Date: Mon, 02 May 2016 09:55:32 +0200 Subject: [OpenWrt-Devel] [PATCH] Chaos Calmer - ramips: Fix IPv6 neighbor discovery on RT5350 In-Reply-To: References: Message-ID: <0fa35def69d9bd654e723c8963fec5a6@vittgam.net> Actually there's a problem with this patch: the tabs have been converted to spaces by your mailer, so it does not apply directly... The patch on GitHub is fine by the way. Cheers, Vittorio On 01/05/2016 23:59:27 CEST, Vittorio G (VittGam) wrote: > On 01/05/2016 23:36:05 CEST, Saverio Proto wrote: >> This patch is also available here: >> https://github.com/zioproto/openwrt15051-batman/commit/0281382bcaa139f0d1d3b589797af4c434747f3e >> >> commit 0281382bcaa139f0d1d3b589797af4c434747f3e >> Author: Saverio Proto >> Date: Sun May 1 23:14:19 2016 +0200 >> >> ramips: Fix IPv6 neighbor discovery on RT5350 >> >> IPv6 neighbor discovery needs working IPv6 multicast. The register FCT2 >> should be set to 0x2500C to let through "unknown IPv6 multicast" to >> all ports. This is based on datasheet information: >> https://cdn.sparkfun.com/datasheets/Wireless/WiFi/RT5350.pdf >> >> Signed-off-by: Saverio Proto > > Reviewed-by: Vittorio Gambaletta > >> >> diff --git a/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c >> b/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c >> index ef13d23..d09eaf3 100644 >> --- a/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c >> +++ b/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c >> @@ -1360,7 +1360,7 @@ static const struct switch_dev_ops esw_ops = { >> static struct rt305x_esw_platform_data rt3050_esw_data = { >> /* All ports are LAN ports. */ >> .vlan_config = RT305X_ESW_VLAN_CONFIG_NONE, >> - .reg_initval_fct2 = 0x00d6500c, >> + .reg_initval_fct2 = 0x0002500c, >> /* >> * ext phy base addr 31, enable port 5 polling, rx/tx clock skew 1, >> * turbo mii off, rgmi 3.3v off >> _______________________________________________ >> openwrt-devel mailing list >> openwrt-devel at lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From john at phrozen.org Mon May 2 04:06:49 2016 From: john at phrozen.org (John Crispin) Date: Mon, 2 May 2016 10:06:49 +0200 Subject: [OpenWrt-Devel] [PATCH] Chaos Calmer - ramips: Fix IPv6 neighbor discovery on RT5350 In-Reply-To: <0fa35def69d9bd654e723c8963fec5a6@vittgam.net> References: <0fa35def69d9bd654e723c8963fec5a6@vittgam.net> Message-ID: <42c65ea8-8d83-a895-b29d-0733b4fbe5dc@phrozen.org> On 02/05/2016 09:55, Vittorio G (VittGam) wrote: > Actually there's a problem with this patch: the tabs have been converted > to spaces by your mailer, so it does not apply directly... > > The patch on GitHub is fine by the way. > > Cheers, > Vittorio you seem to have sent the same patch which does not look whitespace broken. i'll use that one instead. John > > On 01/05/2016 23:59:27 CEST, Vittorio G (VittGam) wrote: >> On 01/05/2016 23:36:05 CEST, Saverio Proto wrote: >>> This patch is also available here: >>> https://github.com/zioproto/openwrt15051-batman/commit/0281382bcaa139f0d1d3b589797af4c434747f3e >>> >>> >>> commit 0281382bcaa139f0d1d3b589797af4c434747f3e >>> Author: Saverio Proto >>> Date: Sun May 1 23:14:19 2016 +0200 >>> >>> ramips: Fix IPv6 neighbor discovery on RT5350 >>> >>> IPv6 neighbor discovery needs working IPv6 multicast. The >>> register FCT2 >>> should be set to 0x2500C to let through "unknown IPv6 multicast" to >>> all ports. This is based on datasheet information: >>> https://cdn.sparkfun.com/datasheets/Wireless/WiFi/RT5350.pdf >>> >>> Signed-off-by: Saverio Proto >> >> Reviewed-by: Vittorio Gambaletta >> >>> >>> diff --git >>> a/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c >>> b/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c >>> index ef13d23..d09eaf3 100644 >>> --- a/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c >>> +++ b/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c >>> @@ -1360,7 +1360,7 @@ static const struct switch_dev_ops esw_ops = { >>> static struct rt305x_esw_platform_data rt3050_esw_data = { >>> /* All ports are LAN ports. */ >>> .vlan_config = RT305X_ESW_VLAN_CONFIG_NONE, >>> - .reg_initval_fct2 = 0x00d6500c, >>> + .reg_initval_fct2 = 0x0002500c, >>> /* >>> * ext phy base addr 31, enable port 5 polling, rx/tx clock >>> skew 1, >>> * turbo mii off, rgmi 3.3v off >>> _______________________________________________ >>> openwrt-devel mailing list >>> openwrt-devel at lists.openwrt.org >>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >> _______________________________________________ >> openwrt-devel mailing list >> openwrt-devel at lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at vittgam.net Mon May 2 04:09:21 2016 From: openwrt at vittgam.net (Vittorio G (VittGam)) Date: Mon, 02 May 2016 10:09:21 +0200 Subject: [OpenWrt-Devel] [PATCH] Chaos Calmer - ramips: Fix IPv6 neighbor discovery on RT5350 In-Reply-To: <42c65ea8-8d83-a895-b29d-0733b4fbe5dc@phrozen.org> References: <0fa35def69d9bd654e723c8963fec5a6@vittgam.net> <42c65ea8-8d83-a895-b29d-0733b4fbe5dc@phrozen.org> Message-ID: <124733f074b171c252e9f78aaa432836@vittgam.net> On 02/05/2016 10:06:49 CEST, John Crispin wrote: > On 02/05/2016 09:55, Vittorio G (VittGam) wrote: >> Actually there's a problem with this patch: the tabs have been converted >> to spaces by your mailer, so it does not apply directly... >> >> The patch on GitHub is fine by the way. >> >> Cheers, >> Vittorio > > you seem to have sent the same patch which does not look whitespace > broken. i'll use that one instead. My patch is not for CC... it's for trunk which uses the newer rt305x driver. Cheers, Vittorio > > John > >> >> On 01/05/2016 23:59:27 CEST, Vittorio G (VittGam) wrote: >>> On 01/05/2016 23:36:05 CEST, Saverio Proto wrote: >>>> This patch is also available here: >>>> https://github.com/zioproto/openwrt15051-batman/commit/0281382bcaa139f0d1d3b589797af4c434747f3e >>>> >>>> >>>> commit 0281382bcaa139f0d1d3b589797af4c434747f3e >>>> Author: Saverio Proto >>>> Date: Sun May 1 23:14:19 2016 +0200 >>>> >>>> ramips: Fix IPv6 neighbor discovery on RT5350 >>>> >>>> IPv6 neighbor discovery needs working IPv6 multicast. The >>>> register FCT2 >>>> should be set to 0x2500C to let through "unknown IPv6 multicast" to >>>> all ports. This is based on datasheet information: >>>> https://cdn.sparkfun.com/datasheets/Wireless/WiFi/RT5350.pdf >>>> >>>> Signed-off-by: Saverio Proto >>> >>> Reviewed-by: Vittorio Gambaletta >>> >>>> >>>> diff --git >>>> a/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c >>>> b/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c >>>> index ef13d23..d09eaf3 100644 >>>> --- a/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c >>>> +++ b/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c >>>> @@ -1360,7 +1360,7 @@ static const struct switch_dev_ops esw_ops = { >>>> static struct rt305x_esw_platform_data rt3050_esw_data = { >>>> /* All ports are LAN ports. */ >>>> .vlan_config = RT305X_ESW_VLAN_CONFIG_NONE, >>>> - .reg_initval_fct2 = 0x00d6500c, >>>> + .reg_initval_fct2 = 0x0002500c, >>>> /* >>>> * ext phy base addr 31, enable port 5 polling, rx/tx clock >>>> skew 1, >>>> * turbo mii off, rgmi 3.3v off >>>> _______________________________________________ >>>> openwrt-devel mailing list >>>> openwrt-devel at lists.openwrt.org >>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >>> _______________________________________________ >>> openwrt-devel mailing list >>> openwrt-devel at lists.openwrt.org >>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >> _______________________________________________ >> openwrt-devel mailing list >> openwrt-devel at lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From john at phrozen.org Mon May 2 04:55:50 2016 From: john at phrozen.org (John Crispin) Date: Mon, 2 May 2016 10:55:50 +0200 Subject: [OpenWrt-Devel] [RFC] ar71xx: add TP-Link TL-WR810N support In-Reply-To: <8c695c12-c8bf-ce8d-8c5e-317c9a9d7dea@gmail.com> References: <1460289627-27414-1-git-send-email-jens.steinhauser@gmail.com> <8c695c12-c8bf-ce8d-8c5e-317c9a9d7dea@gmail.com> Message-ID: On 02/05/2016 00:05, Jens Steinhauser wrote: > On 04/25/2016 10:02 PM, John Crispin wrote: >> Hi >> >> On 10/04/2016 14:00, Jens Steinhauser wrote: >>> This patch adds support for the TP-Link TL-WR810N. >>> https://wiki.openwrt.org/toh/tp-link/tl-wr810n >>> >>> The device has a slide switch to select its mode of operation when using >>> the stock firmware. After looking at how it's implemented for similar >>> devices, I also used 'struct gpio_keys_button { .type = EV_SW, .code = BTN_... }' >>> to support the switch, but both 'switch_b0' and 'switch_b1' are missing >>> when using 'evtest' and 'thd', only the 'reset' button shows up in the >>> output of the programs. >>> >>> Changing '.code' to some SW_ value, for example SW_LID and SW_TABLET_MODE, >>> makes them usable with both 'evtest' and 'thd'. Am I missing something, >>> or is EV_SW + BTN_... an invalid combination? >> >> i use EV_SW and KEY_RFKILL on various boards and it works well. look at >> package/base-files/files/etc/rc.button/rfkill to see how to handle the >> events in userland >> >> John > > Thanks for the hint, indeed the switches can be used like ordinary buttons with procd. What's missing is a way to get the initial switch state after start-up, but that seems to be a limitation of the gpio-button-hotplug driver and procd, not an error in the initialization code. > when using EV_SW it should send one initial event with the starting state. i am sure i added that at some point. i've just put a task onto my todo list. i'll have a look at it the next days. John _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From dedeckeh at gmail.com Mon May 2 05:57:59 2016 From: dedeckeh at gmail.com (Hans Dedecker) Date: Mon, 2 May 2016 11:57:59 +0200 Subject: [OpenWrt-Devel] [PATCH] xtables-addons: Avoid redefinition of SHRT_MAX in lua packet script Message-ID: <1462183079-6979-1-git-send-email-dedeckeh@gmail.com> Patch Lua packet script defines SHRT_MAX which is already defined in and is included indirectly by lauxlib.h. Fix the redefintion as it leads to compile failure on systems which treat macro redefinition as an error Signed-off-by: Hans Dedecker --- .../utils/xtables-addons/patches/201-fix-lua-packetscript.patch | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/package/network/utils/xtables-addons/patches/201-fix-lua-packetscript.patch b/package/network/utils/xtables-addons/patches/201-fix-lua-packetscript.patch index ebc952b..02250ec 100644 --- a/package/network/utils/xtables-addons/patches/201-fix-lua-packetscript.patch +++ b/package/network/utils/xtables-addons/patches/201-fix-lua-packetscript.patch @@ -82,17 +82,20 @@ #define ltable_c --- a/extensions/LUA/lua/luaconf.h +++ b/extensions/LUA/lua/luaconf.h -@@ -13,6 +13,10 @@ +@@ -13,8 +13,12 @@ #if !defined(__KERNEL__) #include #else ++#include ++ +#undef UCHAR_MAX -+#undef SHRT_MAX +#undef BUFSIZ +#undef NO_FPU #define UCHAR_MAX 255 - #define SHRT_MAX 32767 +-#define SHRT_MAX 32767 #define BUFSIZ 8192 + #define NO_FPU + #endif @@ -637,6 +641,8 @@ union luai_Cast { double l_d; long l_l; */ #if defined(__KERNEL__) -- 1.9.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From pannen at gmail.com Mon May 2 13:23:37 2016 From: pannen at gmail.com (Rick P.) Date: Mon, 2 May 2016 19:23:37 +0200 Subject: [OpenWrt-Devel] [PATCH] Device support for TP-Link WR802N Message-ID: <3BBD5BED-DA64-4C69-902C-026CFD57BD43@gmail.com> From: Rick Pannen > Resubmitting patch for the TP-Link WR802N - I hope the format is OK now. Tested on three different devices. Installs, boots and runs. Signed-off-by: Rick Pannen > --- target/linux/ar71xx/base-files/etc/board.d/01_leds | 4 + .../linux/ar71xx/base-files/etc/board.d/02_network | 1 + target/linux/ar71xx/base-files/etc/diag.sh | 3 + target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 + .../ar71xx/base-files/lib/upgrade/platform.sh | 1 + target/linux/ar71xx/config-4.1 | 1 + .../ar71xx/files/arch/mips/ath79/Kconfig.openwrt | 9 ++ target/linux/ar71xx/files/arch/mips/ath79/Makefile | 1 + .../ar71xx/files/arch/mips/ath79/mach-tl-wr802n.c | 98 ++++++++++++++++++++++ .../linux/ar71xx/files/arch/mips/ath79/machtypes.h | 1 + target/linux/ar71xx/generic/profiles/tp-link.mk | 9 ++ target/linux/ar71xx/image/Makefile | 9 ++ target/linux/ar71xx/mikrotik/config-default | 1 + 13 files changed, 141 insertions(+) create mode 100644 target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr802n.c diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds b/target/linux/ar71xx/base-files/etc/board.d/01_leds index 39b21ca..8e94887 100755 --- a/target/linux/ar71xx/base-files/etc/board.d/01_leds +++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds @@ -583,6 +583,10 @@ tl-wr741nd-v4) ucidef_set_led_wlan "wlan" "WLAN" "tp-link:green:wlan" "phy0tpt" ;; +tl-wr802n) + ucidef_set_led_wlan "wlan" "WLAN" "tp-link:blue:system" "phy0tpt" + ;; + tl-wr841n-v8 | \ tl-wr941nd-v5) ucidef_set_led_netdev "wan" "WAN" "tp-link:green:wan" "eth0" diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network b/target/linux/ar71xx/base-files/etc/board.d/02_network index 7724a08..1e44608 100755 --- a/target/linux/ar71xx/base-files/etc/board.d/02_network +++ b/target/linux/ar71xx/base-files/etc/board.d/02_network @@ -367,6 +367,7 @@ tl-wa901nd-v2 |\ tl-wa901nd-v3 |\ tl-wa901nd-v4 |\ tl-wr703n |\ +tl-wr802n |\ tube2h |\ unifiac |\ wndap360 |\ diff --git a/target/linux/ar71xx/base-files/etc/diag.sh b/target/linux/ar71xx/base-files/etc/diag.sh index 77fa398..d41f802 100644 --- a/target/linux/ar71xx/base-files/etc/diag.sh +++ b/target/linux/ar71xx/base-files/etc/diag.sh @@ -316,6 +316,9 @@ get_status_led() { tl-wr1043nd-v2 | \ tl-wr741nd | \ tl-wr741nd-v4 | \ + tl-wr802n) + status_led="tp-link:blue:system" + ;; tl-wr841n-v1 | \ tl-wr841n-v7 | \ tl-wr841n-v8 | \ diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh b/target/linux/ar71xx/base-files/lib/ar71xx.sh index 588affd..2e43eb4 100755 --- a/target/linux/ar71xx/base-files/lib/ar71xx.sh +++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh @@ -175,6 +175,9 @@ tplink_board_detect() { "080100"*) model="TP-Link TL-WA801N/ND" ;; + "080200"*) + model="TP-Link TL-WR802N" + ;; "083000"*) model="TP-Link TL-WA830RE" diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh index 5334600..fb601c1 100755 --- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh +++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh @@ -378,6 +378,7 @@ platform_check_image() { tl-wr720n-v3 | \ tl-wr741nd | \ tl-wr741nd-v4 | \ + tl-wr802n | \ tl-wr841n-v1 | \ tl-wa830re-v2 | \ tl-wr841n-v7 | \ diff --git a/target/linux/ar71xx/config-4.1 b/target/linux/ar71xx/config-4.1 index 40cf453..a65f911 100644 --- a/target/linux/ar71xx/config-4.1 +++ b/target/linux/ar71xx/config-4.1 @@ -158,6 +158,7 @@ CONFIG_ATH79_MACH_TL_WR703N=y CONFIG_ATH79_MACH_TL_WR720N_V3=y CONFIG_ATH79_MACH_TL_WR741ND=y CONFIG_ATH79_MACH_TL_WR741ND_V4=y +CONFIG_ATH79_MACH_TL_WR802N=y CONFIG_ATH79_MACH_TL_WR841N_V1=y CONFIG_ATH79_MACH_TL_WR841N_V8=y CONFIG_ATH79_MACH_TL_WR841N_V9=y diff --git a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt index e6879a9..f24648b 100644 --- a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt +++ b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt @@ -1284,6 +1284,15 @@ config ATH79_MACH_TL_WR741ND_V4 select ATH79_DEV_USB select ATH79_DEV_WMAC +config ATH79_MACH_TL_WR802N + bool "TP-LINK TL-WR802N support" + select SOC_QCA953X + select ATH79_DEV_ETH + select ATH79_DEV_GPIO_BUTTONS + select ATH79_DEV_LEDS_GPIO + select ATH79_DEV_M25P80 + select ATH79 + config ATH79_MACH_TL_WR841N_V1 bool "TP-LINK TL-WR841N v1 support" select SOC_AR71XX diff --git a/target/linux/ar71xx/files/arch/mips/ath79/Makefile b/target/linux/ar71xx/files/arch/mips/ath79/Makefile index 61dfccc..c3d274a 100644 --- a/target/linux/ar71xx/files/arch/mips/ath79/Makefile +++ b/target/linux/ar71xx/files/arch/mips/ath79/Makefile @@ -159,6 +159,7 @@ obj-$(CONFIG_ATH79_MACH_TL_WDR4300) += mach-tl-wdr4300.o obj-$(CONFIG_ATH79_MACH_TL_WDR6500_V2) += mach-tl-wdr6500-v2.o obj-$(CONFIG_ATH79_MACH_TL_WR741ND) += mach-tl-wr741nd.o obj-$(CONFIG_ATH79_MACH_TL_WR741ND_V4) += mach-tl-wr741nd-v4.o +obj-$(CONFIG_ATH79_MACH_TL_WR802N) += mach-tl-wr802n.o obj-$(CONFIG_ATH79_MACH_TL_WR841N_V1) += mach-tl-wr841n.o obj-$(CONFIG_ATH79_MACH_TL_WR841N_V8) += mach-tl-wr841n-v8.o obj-$(CONFIG_ATH79_MACH_TL_WR841N_V9) += mach-tl-wr841n-v9.o diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr802n.c b/target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr802n.c new file mode 100644 index 0000000..d97d7f9 --- /dev/null +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr802n.c @@ -0,0 +1,98 @@ +/* + * TP-LINK TL-WR802N + * + * Copyright (C) 2015 Rick Pannen > + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 as published + * by the Free Software Foundation. + */ + +#include +#include + +#include +#include + +#include "common.h" +#include "dev-eth.h" +#include "dev-gpio-buttons.h" +#include "dev-leds-gpio.h" +#include "dev-m25p80.h" +#include "dev-wmac.h" +#include "machtypes.h" + +#define TL_WR802N_GPIO_LED_SYSTEM 13 +#define TL_WR802N_GPIO_BTN_RESET 11 + +#define TL_WR802N_KEYS_POLL_INTERVAL 20 /* msecs */ +#define TL_WR802N_KEYS_DEBOUNCE_INTERVAL (3 * TL_WR802N_KEYS_POLL_INTERVAL) + +static const char *tl_wr802n_part_probes[] = { + "tp-link", + NULL, +}; + +static struct flash_platform_data tl_wr802n_flash_data = { + .part_probes = tl_wr802n_part_probes, +}; + +static struct gpio_led tl_wr802n_leds_gpio[] __initdata = { + { + .name = "tp-link:blue:system", + .gpio = TL_WR802N_GPIO_LED_SYSTEM, + .active_low = 1, + }, +}; + +static struct gpio_keys_button tl_wr802n_gpio_keys[] __initdata = { + { + .desc = "reset", + .type = EV_KEY, + .code = KEY_RESTART, + .debounce_interval = TL_WR802N_KEYS_DEBOUNCE_INTERVAL, + .gpio = TL_WR802N_GPIO_BTN_RESET, + .active_low = 0, + } +}; + +static void __init tl_ap143_setup(void) +{ + u8 *mac = (u8 *) KSEG1ADDR(0x1f01fc00); + u8 *ee = (u8 *) KSEG1ADDR(0x1fff1000); + u8 tmpmac[ETH_ALEN]; + + ath79_register_m25p80(&tl_wr802n_flash_data); + + ath79_setup_ar933x_phy4_switch(false, false); + + ath79_register_mdio(0, 0x0); + + /* LAN */ + ath79_switch_data.phy4_mii_en = 1; + ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_MII; + ath79_eth0_data.duplex = DUPLEX_FULL; + ath79_eth0_data.speed = SPEED_100; + ath79_eth0_data.phy_mask = BIT(4); + ath79_init_mac(ath79_eth0_data.mac_addr, mac, 1); + ath79_register_eth(0); + + ath79_init_mac(tmpmac, mac, 0); + ath79_register_wmac(ee, tmpmac); +}; + +static void __init tl_wr802n_setup(void) +{ + tl_ap143_setup(); + + ath79_register_leds_gpio(-1, ARRAY_SIZE(tl_wr802n_leds_gpio), + tl_wr802n_leds_gpio); + + ath79_register_gpio_keys_polled(1, TL_WR802N_KEYS_POLL_INTERVAL, + ARRAY_SIZE(tl_wr802n_gpio_keys), + tl_wr802n_gpio_keys); +} + +MIPS_MACHINE(ATH79_MACH_TL_WR802N, "TL-WR802N", "TP-LINK TL-WR802N", + tl_wr802n_setup); + diff --git a/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h b/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h index b2df9c4..62d5d6d 100644 --- a/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h +++ b/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h @@ -193,6 +193,7 @@ enum ath79_mach_type { ATH79_MACH_TL_WR720N_V3, /* TP-LINK TL-WR720N v3/v4 */ ATH79_MACH_TL_WR741ND, /* TP-LINK TL-WR741ND */ ATH79_MACH_TL_WR741ND_V4, /* TP-LINK TL-WR741ND v4 */ + ATH79_MACH_TL_WR802N, /* TP-LINK TL-WR802N */ ATH79_MACH_TL_WR841N_V1, /* TP-LINK TL-WR841N v1 */ ATH79_MACH_TL_WR841N_V7, /* TP-LINK TL-WR841N/ND v7 */ ATH79_MACH_TL_WR841N_V8, /* TP-LINK TL-WR841N/ND v8 */ diff --git a/target/linux/ar71xx/generic/profiles/tp-link.mk b/target/linux/ar71xx/generic/profiles/tp-link.mk index 2875290..ced7ba8 100644 --- a/target/linux/ar71xx/generic/profiles/tp-link.mk +++ b/target/linux/ar71xx/generic/profiles/tp-link.mk @@ -331,6 +331,15 @@ define Profile/TLWR743/Description endef $(eval $(call Profile,TLWR743)) +define Profile/TLWR802 + NAME:=TP-LINK TL-WR802N + PACKAGES:= +endef + +define Profile/TLWR802/Description + Package set optimized for the TP-LINK TL-WR802N. +endef +$(eval $(call Profile,TLWR802)) define Profile/TLWR841 NAME:=TP-LINK TL-WR841N/ND diff --git a/target/linux/ar71xx/image/Makefile b/target/linux/ar71xx/image/Makefile index 3bf005f..08a501d 100644 --- a/target/linux/ar71xx/image/Makefile +++ b/target/linux/ar71xx/image/Makefile @@ -815,6 +815,15 @@ define Device/tl-wr743nd-v2 endef TARGET_DEVICES += tl-wr740n-v1 tl-wr740n-v3 tl-wr740n-v4 tl-wr740n-v5 tl-wr740n-v6 tl-wr741nd-v1 tl-wr741nd-v2 tl-wr741nd-v4 tl-wr741nd-v5 tl-wr743nd-v1 tl-wr743nd-v2 +define Device/tl-wr802n + $(Device/tplink-4mlzma) + BOARDNAME := TL-WR802N + DEVICE_PROFILE := TLWR802 + TPLINK_HWID := 0x08020001 + TPLINK_HWREV := 1 +endef +TARGET_DEVICES += tl-wr802n + define Device/tl-wr841-v1.5 $(Device/tplink-4m) BOARDNAME := TL-WR841N-v1.5 diff --git a/target/linux/ar71xx/mikrotik/config-default b/target/linux/ar71xx/mikrotik/config-default index 094f2ae..7ce48b4 100644 --- a/target/linux/ar71xx/mikrotik/config-default +++ b/target/linux/ar71xx/mikrotik/config-default @@ -97,6 +97,7 @@ CONFIG_ATH79_MACH_RBSXTLITE=y # CONFIG_ATH79_MACH_TL_WR720N_V3 is not set # CONFIG_ATH79_MACH_TL_WR741ND is not set # CONFIG_ATH79_MACH_TL_WR741ND_V4 is not set +# CONFIG_ATH79_MACH_TL_WR802N is not set # CONFIG_ATH79_MACH_TL_WR841N_V1 is not set # CONFIG_ATH79_MACH_TL_WR841N_V8 is not set # CONFIG_ATH79_MACH_TL_WR841N_V9 is not set -- 1.9.1 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From jow at openwrt.org Mon May 2 13:31:44 2016 From: jow at openwrt.org (Jo-Philipp Wich) Date: Mon, 2 May 2016 18:31:44 +0100 Subject: [OpenWrt-Devel] [PATCH] firewall3: Fix multicast ICMPv6 replies not being sent by default anymore. In-Reply-To: References: Message-ID: <934a8701-c572-8c11-e9cf-91e3b3512840@openwrt.org> Hi Vittorio, can you move the "mcdst" declaration to the top of the function? ~ Jo _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From jow at openwrt.org Mon May 2 13:41:35 2016 From: jow at openwrt.org (Jo-Philipp Wich) Date: Mon, 2 May 2016 18:41:35 +0100 Subject: [OpenWrt-Devel] [PATCH] load running state after lock is acquired In-Reply-To: <1461934801-17620-1-git-send-email-alin.nastac@gmail.com> References: <1461934801-17620-1-git-send-email-alin.nastac@gmail.com> Message-ID: <41a5e4ca-e1f5-7cd3-0e82-d631394f529d@openwrt.org> Hi Alin, thanks! Pushed to firewall3.git. ~ Jo _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at vittgam.net Mon May 2 14:17:48 2016 From: openwrt at vittgam.net (Vittorio Gambaletta (VittGam)) Date: Mon, 2 May 2016 20:17:48 +0200 Subject: [OpenWrt-Devel] [PATCH v2] firewall3: Fix multicast ICMPv6 replies not being sent by default anymore. In-Reply-To: <934a8701-c572-8c11-e9cf-91e3b3512840@openwrt.org> References: <934a8701-c572-8c11-e9cf-91e3b3512840@openwrt.org> Message-ID: Since drop_invalid has been turned on by default, ICMPv6 echo requests to well-known multicast addresses, such as ff02::1, are not replied to by the router anymore, because conntrack considers those outgoing reply packets to be invalid. Fix this by not having the INVALID rule in the OUTPUT chain match IPv6 packets destined to link-local addresses (fe80::/10). Signed-off-by: Vittorio Gambaletta --- diff --git a/defaults.c b/defaults.c index 3d210f9..ea905e0 100644 --- a/defaults.c +++ b/defaults.c @@ -180,6 +180,14 @@ fw3_print_default_head_rules(struct fw3_ipt_handle *handle, "FORWARD", "forwarding", }; + struct fw3_address mcdst = { + .set = true, + .invert = true, + .family = FW3_FAMILY_V6, + .address.v6.s6_addr = { 0xfe, 0x80 }, + .mask.v6.s6_addr = { 0xff, 0xc0 }, + }; + switch (handle->table) { case FW3_TABLE_FILTER: @@ -215,6 +223,8 @@ fw3_print_default_head_rules(struct fw3_ipt_handle *handle, if (defs->drop_invalid) { r = fw3_ipt_rule_new(handle); + if (i == 2 && handle->family == FW3_FAMILY_V6) + fw3_ipt_rule_src_dest(r, NULL, &mcdst); fw3_ipt_rule_extra(r, "-m conntrack --ctstate INVALID"); fw3_ipt_rule_target(r, "DROP"); fw3_ipt_rule_append(r, chains[i]); _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From agermar at gmail.com Mon May 2 14:27:52 2016 From: agermar at gmail.com (August Germar) Date: Mon, 2 May 2016 11:27:52 -0700 Subject: [OpenWrt-Devel] [PATCH] Device Support for Anonabox-Pro (Aug. G.) Message-ID: <57279C28.9070108@gmail.com> Submitting patch for anonabox privacy router, tested with DD, does not seem to work in CC. https://raw.githubusercontent.com/anonabox/openwrt-patch/master/anonabox_pro.patch Thoughts, comments questions welcome. I'll be in the IRC with the handle torouter. Thanks. _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From jens.steinhauser at gmail.com Mon May 2 14:50:56 2016 From: jens.steinhauser at gmail.com (Jens Steinhauser) Date: Mon, 2 May 2016 20:50:56 +0200 Subject: [OpenWrt-Devel] [RFC] ar71xx: add TP-Link TL-WR810N support In-Reply-To: References: <1460289627-27414-1-git-send-email-jens.steinhauser@gmail.com> <8c695c12-c8bf-ce8d-8c5e-317c9a9d7dea@gmail.com> Message-ID: On 05/02/2016 10:55 AM, John Crispin wrote: > On 02/05/2016 00:05, Jens Steinhauser wrote: >> On 04/25/2016 10:02 PM, John Crispin wrote: >>> Hi >>> >>> On 10/04/2016 14:00, Jens Steinhauser wrote: >>>> This patch adds support for the TP-Link TL-WR810N. >>>> https://wiki.openwrt.org/toh/tp-link/tl-wr810n >>>> >>>> The device has a slide switch to select its mode of operation when using >>>> the stock firmware. After looking at how it's implemented for similar >>>> devices, I also used 'struct gpio_keys_button { .type = EV_SW, .code = BTN_... }' >>>> to support the switch, but both 'switch_b0' and 'switch_b1' are missing >>>> when using 'evtest' and 'thd', only the 'reset' button shows up in the >>>> output of the programs. >>>> >>>> Changing '.code' to some SW_ value, for example SW_LID and SW_TABLET_MODE, >>>> makes them usable with both 'evtest' and 'thd'. Am I missing something, >>>> or is EV_SW + BTN_... an invalid combination? >>> >>> i use EV_SW and KEY_RFKILL on various boards and it works well. look at >>> package/base-files/files/etc/rc.button/rfkill to see how to handle the >>> events in userland >>> >>> John >> >> Thanks for the hint, indeed the switches can be used like ordinary buttons with procd. What's missing is a way to get the initial switch state after start-up, but that seems to be a limitation of the gpio-button-hotplug driver and procd, not an error in the initialization code. >> > > when using EV_SW it should send one initial event with the starting > state. i am sure i added that at some point. i've just put a task onto > my todo list. i'll have a look at it the next days. I used the following script to react on switch changes: root at OpenWrt:/# cat /etc/hotplug.d/button/btn #!/bin/sh logger "$0 $BUTTON $ACTION" echo "$0 $BUTTON $ACTION" >>/tmp/btn Directly after start-up the file /tmp/btn is empty and no messages got logged. Enabling the debug messages of the driver shows that it generates some events after it is loaded: [ 4.263157] gpio-keys: event type=5, code=256, value=0 [ 4.263179] gpio-keys: create event, name=BTN_0, seen=42949377, pressed=0 [ 4.263192] gpio-keys: event type=5, code=257, value=1 [ 4.263203] gpio-keys: create event, name=BTN_1, seen=42949377, pressed=1 [ 4.263231] gpio-keys: added variable 'released@' [ 4.263241] gpio-keys: added variable 'HOME=/' [ 4.263252] gpio-keys: added variable 'PATH=/sbin:/bin:/usr/sbin:/usr/bin' [ 4.263263] gpio-keys: added variable 'SUBSYSTEM=button' [ 4.263273] gpio-keys: added variable 'ACTION=released' [ 4.263283] gpio-keys: added variable 'BUTTON=BTN_0' [ 4.263293] gpio-keys: added variable 'TYPE=switch' [ 4.263303] gpio-keys: added variable 'SEEN=42949377' [ 4.263314] gpio-keys: added variable 'SEQNUM=258' [ 4.263340] gpio-keys: added variable 'pressed@' [ 4.263349] gpio-keys: added variable 'HOME=/' [ 4.263360] gpio-keys: added variable 'PATH=/sbin:/bin:/usr/sbin:/usr/bin' [ 4.263371] gpio-keys: added variable 'SUBSYSTEM=button' [ 4.263381] gpio-keys: added variable 'ACTION=pressed' [ 4.263390] gpio-keys: added variable 'BUTTON=BTN_1' [ 4.263400] gpio-keys: added variable 'TYPE=switch' [ 4.263410] gpio-keys: added variable 'SEEN=42949377' [ 4.263420] gpio-keys: added variable 'SEQNUM=259' [ 4.263455] ehci-platform ehci-platform: USB 2.0 started, EHCI 1.00 [ 4.270905] hub 1-0:1.0: USB hub found [ 4.275308] hub 1-0:1.0: 1 port detected [ 4.282975] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 4.291082] ohci-platform: OHCI generic platform driver [ 4.299513] uhci_hcd: USB Universal Host Controller Interface driver [ 4.316930] init: - preinit - [ 5.025936] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 5.054558] random: procd urandom read with 8 bits of entropy available [ 8.292207] jffs2: notice: (359) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found. [ 8.310100] mount_root: switching to jffs2 overlay [ 8.358949] procd: - early - [ 8.362073] procd: - watchdog - [ 9.052180] procd: - ubus - [ 9.172024] procd: - init - The procd messages come a few seconds after the messages from the driver, so maybe it's just to early for userspace to react? When I reload the driver, the events are processed by procd/the button handling script: root at OpenWrt:/# cat /tmp/btn cat: can't open '/tmp/btn': No such file or directory root at OpenWrt:/# rmmod gpio_button_hotplug root at OpenWrt:/# modprobe gpio_button_hotplug root at OpenWrt:/# cat /tmp/btn /etc/rc.button/BTN_0 BTN_0 released /sbin/hotplug-call BTN_0 released /etc/rc.button/BTN_1 BTN_1 pressed /sbin/hotplug-call BTN_1 pressed Jens _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From john at phrozen.org Mon May 2 15:12:34 2016 From: john at phrozen.org (John Crispin) Date: Mon, 2 May 2016 21:12:34 +0200 Subject: [OpenWrt-Devel] [RFC] ar71xx: add TP-Link TL-WR810N support In-Reply-To: References: <1460289627-27414-1-git-send-email-jens.steinhauser@gmail.com> <8c695c12-c8bf-ce8d-8c5e-317c9a9d7dea@gmail.com> Message-ID: <39c2eae3-bb0c-61e4-2a51-ffa4f6b596cb@phrozen.org> On 02/05/2016 20:50, Jens Steinhauser wrote: > On 05/02/2016 10:55 AM, John Crispin wrote: >> On 02/05/2016 00:05, Jens Steinhauser wrote: >>> On 04/25/2016 10:02 PM, John Crispin wrote: >>>> Hi >>>> >>>> On 10/04/2016 14:00, Jens Steinhauser wrote: >>>>> This patch adds support for the TP-Link TL-WR810N. >>>>> https://wiki.openwrt.org/toh/tp-link/tl-wr810n >>>>> >>>>> The device has a slide switch to select its mode of operation when using >>>>> the stock firmware. After looking at how it's implemented for similar >>>>> devices, I also used 'struct gpio_keys_button { .type = EV_SW, .code = BTN_... }' >>>>> to support the switch, but both 'switch_b0' and 'switch_b1' are missing >>>>> when using 'evtest' and 'thd', only the 'reset' button shows up in the >>>>> output of the programs. >>>>> >>>>> Changing '.code' to some SW_ value, for example SW_LID and SW_TABLET_MODE, >>>>> makes them usable with both 'evtest' and 'thd'. Am I missing something, >>>>> or is EV_SW + BTN_... an invalid combination? >>>> >>>> i use EV_SW and KEY_RFKILL on various boards and it works well. look at >>>> package/base-files/files/etc/rc.button/rfkill to see how to handle the >>>> events in userland >>>> >>>> John >>> >>> Thanks for the hint, indeed the switches can be used like ordinary buttons with procd. What's missing is a way to get the initial switch state after start-up, but that seems to be a limitation of the gpio-button-hotplug driver and procd, not an error in the initialization code. >>> >> >> when using EV_SW it should send one initial event with the starting >> state. i am sure i added that at some point. i've just put a task onto >> my todo list. i'll have a look at it the next days. > > I used the following script to react on switch changes: > > root at OpenWrt:/# cat /etc/hotplug.d/button/btn > #!/bin/sh > logger "$0 $BUTTON $ACTION" > echo "$0 $BUTTON $ACTION" >>/tmp/btn > > Directly after start-up the file /tmp/btn is empty and no messages got logged. Enabling the debug messages of the driver shows that it generates some events after it is loaded: > > [ 4.263157] gpio-keys: event type=5, code=256, value=0 > [ 4.263179] gpio-keys: create event, name=BTN_0, seen=42949377, pressed=0 > [ 4.263192] gpio-keys: event type=5, code=257, value=1 > [ 4.263203] gpio-keys: create event, name=BTN_1, seen=42949377, pressed=1 > [ 4.263231] gpio-keys: added variable 'released@' > [ 4.263241] gpio-keys: added variable 'HOME=/' > [ 4.263252] gpio-keys: added variable 'PATH=/sbin:/bin:/usr/sbin:/usr/bin' > [ 4.263263] gpio-keys: added variable 'SUBSYSTEM=button' > [ 4.263273] gpio-keys: added variable 'ACTION=released' > [ 4.263283] gpio-keys: added variable 'BUTTON=BTN_0' > [ 4.263293] gpio-keys: added variable 'TYPE=switch' > [ 4.263303] gpio-keys: added variable 'SEEN=42949377' > [ 4.263314] gpio-keys: added variable 'SEQNUM=258' > [ 4.263340] gpio-keys: added variable 'pressed@' > [ 4.263349] gpio-keys: added variable 'HOME=/' > [ 4.263360] gpio-keys: added variable 'PATH=/sbin:/bin:/usr/sbin:/usr/bin' > [ 4.263371] gpio-keys: added variable 'SUBSYSTEM=button' > [ 4.263381] gpio-keys: added variable 'ACTION=pressed' > [ 4.263390] gpio-keys: added variable 'BUTTON=BTN_1' > [ 4.263400] gpio-keys: added variable 'TYPE=switch' > [ 4.263410] gpio-keys: added variable 'SEEN=42949377' > [ 4.263420] gpio-keys: added variable 'SEQNUM=259' > [ 4.263455] ehci-platform ehci-platform: USB 2.0 started, EHCI 1.00 > [ 4.270905] hub 1-0:1.0: USB hub found > [ 4.275308] hub 1-0:1.0: 1 port detected > [ 4.282975] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver > [ 4.291082] ohci-platform: OHCI generic platform driver > [ 4.299513] uhci_hcd: USB Universal Host Controller Interface driver > [ 4.316930] init: - preinit - > [ 5.025936] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready > [ 5.054558] random: procd urandom read with 8 bits of entropy available > [ 8.292207] jffs2: notice: (359) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found. > [ 8.310100] mount_root: switching to jffs2 overlay > [ 8.358949] procd: - early - > [ 8.362073] procd: - watchdog - > [ 9.052180] procd: - ubus - > [ 9.172024] procd: - init - > > The procd messages come a few seconds after the messages from the driver, so maybe it's just to early for userspace to react? > > When I reload the driver, the events are processed by procd/the button handling script: > > root at OpenWrt:/# cat /tmp/btn > cat: can't open '/tmp/btn': No such file or directory > root at OpenWrt:/# rmmod gpio_button_hotplug > root at OpenWrt:/# modprobe gpio_button_hotplug > root at OpenWrt:/# cat /tmp/btn > /etc/rc.button/BTN_0 BTN_0 released > /sbin/hotplug-call BTN_0 released > /etc/rc.button/BTN_1 BTN_1 pressed > /sbin/hotplug-call BTN_1 pressed > > Jens > thanks for debugging, looks like a regression, this used to work for sure. i'll have a look at it. John _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From baptiste at bitsofnetworks.org Mon May 2 15:37:07 2016 From: baptiste at bitsofnetworks.org (Baptiste Jonglez) Date: Mon, 2 May 2016 21:37:07 +0200 Subject: [OpenWrt-Devel] [PATCH v2] firewall3: Fix multicast ICMPv6 replies not being sent by default anymore. In-Reply-To: References: <934a8701-c572-8c11-e9cf-91e3b3512840@openwrt.org> Message-ID: <20160502193706.GE17354@lud.polynome.dn42> Hi Vittorio, On Mon, May 02, 2016 at 08:17:48PM +0200, Vittorio Gambaletta (VittGam) wrote: > Since drop_invalid has been turned on by default, ICMPv6 echo requests > to well-known multicast addresses, such as ff02::1, are not replied to > by the router anymore, because conntrack considers those outgoing reply > packets to be invalid. > > Fix this by not having the INVALID rule in the OUTPUT chain match IPv6 > packets destined to link-local addresses (fe80::/10). I'm not sure I understand: the multicast ICMP packets you mention have a destination address of ff02::1, which is not in fe80::/10. Did you intend to allow all of ff00::/8 as destination (which is probably much too permissive), or did I miss something? Baptiste > Signed-off-by: Vittorio Gambaletta > --- > > diff --git a/defaults.c b/defaults.c > index 3d210f9..ea905e0 100644 > --- a/defaults.c > +++ b/defaults.c > @@ -180,6 +180,14 @@ fw3_print_default_head_rules(struct fw3_ipt_handle *handle, > "FORWARD", "forwarding", > }; > > + struct fw3_address mcdst = { > + .set = true, > + .invert = true, > + .family = FW3_FAMILY_V6, > + .address.v6.s6_addr = { 0xfe, 0x80 }, > + .mask.v6.s6_addr = { 0xff, 0xc0 }, > + }; > + > switch (handle->table) > { > case FW3_TABLE_FILTER: > @@ -215,6 +223,8 @@ fw3_print_default_head_rules(struct fw3_ipt_handle *handle, > if (defs->drop_invalid) > { > r = fw3_ipt_rule_new(handle); > + if (i == 2 && handle->family == FW3_FAMILY_V6) > + fw3_ipt_rule_src_dest(r, NULL, &mcdst); > fw3_ipt_rule_extra(r, "-m conntrack --ctstate INVALID"); > fw3_ipt_rule_target(r, "DROP"); > fw3_ipt_rule_append(r, chains[i]); > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From baptiste at bitsofnetworks.org Mon May 2 15:54:06 2016 From: baptiste at bitsofnetworks.org (Baptiste Jonglez) Date: Mon, 2 May 2016 21:54:06 +0200 Subject: [OpenWrt-Devel] [PATCH v2] firewall3: Fix multicast ICMPv6 replies not being sent by default anymore. In-Reply-To: <20160502193706.GE17354@lud.polynome.dn42> References: <934a8701-c572-8c11-e9cf-91e3b3512840@openwrt.org> <20160502193706.GE17354@lud.polynome.dn42> Message-ID: <20160502195406.GG17354@lud.polynome.dn42> On Mon, May 02, 2016 at 09:37:07PM +0200, Baptiste Jonglez wrote: > On Mon, May 02, 2016 at 08:17:48PM +0200, Vittorio Gambaletta (VittGam) wrote: > > Since drop_invalid has been turned on by default, ICMPv6 echo requests > > to well-known multicast addresses, such as ff02::1, are not replied to > > by the router anymore, because conntrack considers those outgoing reply > > packets to be invalid. > > > > Fix this by not having the INVALID rule in the OUTPUT chain match IPv6 > > packets destined to link-local addresses (fe80::/10). > > I'm not sure I understand: the multicast ICMP packets you mention have a > destination address of ff02::1, which is not in fe80::/10. Did you intend > to allow all of ff00::/8 as destination (which is probably much too > permissive), or did I miss something? I *did* miss something: this rule is added to the output path, not the input path. Sorry for the noise. I wonder if it's the only legimitate kind of traffic that gets dropped by the INVALID rule, though. > > Signed-off-by: Vittorio Gambaletta > > --- > > > > diff --git a/defaults.c b/defaults.c > > index 3d210f9..ea905e0 100644 > > --- a/defaults.c > > +++ b/defaults.c > > @@ -180,6 +180,14 @@ fw3_print_default_head_rules(struct fw3_ipt_handle *handle, > > "FORWARD", "forwarding", > > }; > > > > + struct fw3_address mcdst = { > > + .set = true, > > + .invert = true, > > + .family = FW3_FAMILY_V6, > > + .address.v6.s6_addr = { 0xfe, 0x80 }, > > + .mask.v6.s6_addr = { 0xff, 0xc0 }, > > + }; > > + > > switch (handle->table) > > { > > case FW3_TABLE_FILTER: > > @@ -215,6 +223,8 @@ fw3_print_default_head_rules(struct fw3_ipt_handle *handle, > > if (defs->drop_invalid) > > { > > r = fw3_ipt_rule_new(handle); > > + if (i == 2 && handle->family == FW3_FAMILY_V6) > > + fw3_ipt_rule_src_dest(r, NULL, &mcdst); > > fw3_ipt_rule_extra(r, "-m conntrack --ctstate INVALID"); > > fw3_ipt_rule_target(r, "DROP"); > > fw3_ipt_rule_append(r, chains[i]); > > _______________________________________________ > > openwrt-devel mailing list > > openwrt-devel at lists.openwrt.org > > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From zioproto at gmail.com Mon May 2 16:20:42 2016 From: zioproto at gmail.com (Saverio Proto) Date: Mon, 2 May 2016 22:20:42 +0200 Subject: [OpenWrt-Devel] [PATCH] Chaos Calmer - ramips: Fix IPv6 neighbor discovery on RT5350 In-Reply-To: <124733f074b171c252e9f78aaa432836@vittgam.net> References: <0fa35def69d9bd654e723c8963fec5a6@vittgam.net> <42c65ea8-8d83-a895-b29d-0733b4fbe5dc@phrozen.org> <124733f074b171c252e9f78aaa432836@vittgam.net> Message-ID: I attach the patch in this email so should be without whitespace problem. thank you Saverio 2016-05-02 10:09 GMT+02:00 Vittorio G (VittGam) : > On 02/05/2016 10:06:49 CEST, John Crispin wrote: >> >> On 02/05/2016 09:55, Vittorio G (VittGam) wrote: >>> >>> Actually there's a problem with this patch: the tabs have been converted >>> to spaces by your mailer, so it does not apply directly... >>> >>> The patch on GitHub is fine by the way. >>> >>> Cheers, >>> Vittorio >> >> >> you seem to have sent the same patch which does not look whitespace >> broken. i'll use that one instead. > > > My patch is not for CC... it's for trunk which uses the newer rt305x driver. > > Cheers, > Vittorio > > >> >> John >> >>> >>> On 01/05/2016 23:59:27 CEST, Vittorio G (VittGam) wrote: >>>> >>>> On 01/05/2016 23:36:05 CEST, Saverio Proto wrote: >>>>> >>>>> This patch is also available here: >>>>> >>>>> https://github.com/zioproto/openwrt15051-batman/commit/0281382bcaa139f0d1d3b589797af4c434747f3e >>>>> >>>>> >>>>> commit 0281382bcaa139f0d1d3b589797af4c434747f3e >>>>> Author: Saverio Proto >>>>> Date: Sun May 1 23:14:19 2016 +0200 >>>>> >>>>> ramips: Fix IPv6 neighbor discovery on RT5350 >>>>> >>>>> IPv6 neighbor discovery needs working IPv6 multicast. The >>>>> register FCT2 >>>>> should be set to 0x2500C to let through "unknown IPv6 multicast" to >>>>> all ports. This is based on datasheet information: >>>>> https://cdn.sparkfun.com/datasheets/Wireless/WiFi/RT5350.pdf >>>>> >>>>> Signed-off-by: Saverio Proto >>>> >>>> >>>> Reviewed-by: Vittorio Gambaletta >>>> >>>>> >>>>> diff --git >>>>> a/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c >>>>> b/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c >>>>> index ef13d23..d09eaf3 100644 >>>>> --- >>>>> a/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c >>>>> +++ >>>>> b/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c >>>>> @@ -1360,7 +1360,7 @@ static const struct switch_dev_ops esw_ops = { >>>>> static struct rt305x_esw_platform_data rt3050_esw_data = { >>>>> /* All ports are LAN ports. */ >>>>> .vlan_config = RT305X_ESW_VLAN_CONFIG_NONE, >>>>> - .reg_initval_fct2 = 0x00d6500c, >>>>> + .reg_initval_fct2 = 0x0002500c, >>>>> /* >>>>> * ext phy base addr 31, enable port 5 polling, rx/tx clock >>>>> skew 1, >>>>> * turbo mii off, rgmi 3.3v off >>>>> _______________________________________________ >>>>> openwrt-devel mailing list >>>>> openwrt-devel at lists.openwrt.org >>>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >>>> >>>> _______________________________________________ >>>> openwrt-devel mailing list >>>> openwrt-devel at lists.openwrt.org >>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >>> >>> _______________________________________________ >>> openwrt-devel mailing list >>> openwrt-devel at lists.openwrt.org >>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >> >> _______________________________________________ >> openwrt-devel mailing list >> openwrt-devel at lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: fix-ipv6-multicast-rt3050.patch Type: application/octet-stream Size: 1246 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From marex at denx.de Mon May 2 16:42:09 2016 From: marex at denx.de (Marek Vasut) Date: Mon, 2 May 2016 22:42:09 +0200 Subject: [OpenWrt-Devel] [PATCH 1/4] package: kernel: modules: Enable Dual-Role support for DWC2 USB Message-ID: <1462221732-8027-1-git-send-email-marex@denx.de> Enable configuration option which allows DWC2 USB OTG core to operate in Dual-Role mode. Signed-off-by: Marek Vasut --- package/kernel/linux/modules/usb.mk | 1 + 1 file changed, 1 insertion(+) diff --git a/package/kernel/linux/modules/usb.mk b/package/kernel/linux/modules/usb.mk index 8c5a2ab..b41880b 100644 --- a/package/kernel/linux/modules/usb.mk +++ b/package/kernel/linux/modules/usb.mk @@ -488,6 +488,7 @@ define KernelPackage/usb-dwc2 CONFIG_USB_DWC2_VERBOSE=n \ CONFIG_USB_DWC2_TRACK_MISSED_SOFS=n \ CONFIG_USB_DWC2_DEBUG_PERIODIC=n + CONFIG_USB_DWC2_DUAL_ROLE=y FILES:= \ $(LINUX_DIR)/drivers/usb/dwc2/dwc2.ko \ $(LINUX_DIR)/drivers/usb/dwc2/dwc2_platform.ko at lt4.3 -- 2.7.0 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From marex at denx.de Mon May 2 16:42:10 2016 From: marex at denx.de (Marek Vasut) Date: Mon, 2 May 2016 22:42:10 +0200 Subject: [OpenWrt-Devel] [PATCH 2/4] package: kernel: modules: Add USB Mass Storage package In-Reply-To: <1462221732-8027-1-git-send-email-marex@denx.de> References: <1462221732-8027-1-git-send-email-marex@denx.de> Message-ID: <1462221732-8027-2-git-send-email-marex@denx.de> Add package which enables building of the USB Mass Storage support kernel modules (USB MSG). Signed-off-by: Marek Vasut --- package/kernel/linux/modules/usb.mk | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/package/kernel/linux/modules/usb.mk b/package/kernel/linux/modules/usb.mk index b41880b..0343cbb 100644 --- a/package/kernel/linux/modules/usb.mk +++ b/package/kernel/linux/modules/usb.mk @@ -297,6 +297,24 @@ endef $(eval $(call KernelPackage,usb-mass-storage-gadget)) +define KernelPackage/usb-storage-gadget + TITLE:=USB Mass Storage Gadget support + KCONFIG:=CONFIG_USB_F_MASS_STORAGE + DEPENDS:=+kmod-usb-gadget +kmod-usb-lib-composite + FILES:= \ + $(LINUX_DIR)/drivers/usb/gadget/function/usb_f_mass_storage.ko \ + $(LINUX_DIR)/drivers/usb/gadget/legacy/g_storage.ko + AUTOLOAD:=$(call AutoLoad,52,usb_f_mass_storage g_storage) + $(call AddDepends/usb) +endef + +define KernelPackage/usb-storage-gadget/description + Kernel support for USB Mass Storage Gadget. +endef + +$(eval $(call KernelPackage,usb-storage-gadget)) + + define KernelPackage/usb-uhci TITLE:=Support for UHCI controllers KCONFIG:= \ -- 2.7.0 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From marex at denx.de Mon May 2 16:42:11 2016 From: marex at denx.de (Marek Vasut) Date: Mon, 2 May 2016 22:42:11 +0200 Subject: [OpenWrt-Devel] [PATCH 3/4] package: kernel: Enable support for DWC2 USB on SoCFPGA In-Reply-To: <1462221732-8027-1-git-send-email-marex@denx.de> References: <1462221732-8027-1-git-send-email-marex@denx.de> Message-ID: <1462221732-8027-3-git-send-email-marex@denx.de> This patch enables the DWC2 modules for the Altera SoCFPGA target. Signed-off-by: Marek Vasut --- 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 0343cbb..22b7f64 100644 --- a/package/kernel/linux/modules/usb.mk +++ b/package/kernel/linux/modules/usb.mk @@ -497,7 +497,7 @@ $(eval $(call KernelPackage,usb2-pci)) define KernelPackage/usb-dwc2 TITLE:=DWC2 USB controller driver - DEPENDS:=+(TARGET_brcm2708||TARGET_at91||TARGET_brcm63xx||TARGET_mxs||TARGET_imx6||TARGET_omap):kmod-usb-gadget + DEPENDS:=+(TARGET_brcm2708||TARGET_at91||TARGET_brcm63xx||TARGET_mxs||TARGET_imx6||TARGET_omap||TARGET_socfpga):kmod-usb-gadget KCONFIG:= \ CONFIG_USB_DWC2 \ CONFIG_USB_DWC2_PCI \ -- 2.7.0 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From marex at denx.de Mon May 2 16:42:12 2016 From: marex at denx.de (Marek Vasut) Date: Mon, 2 May 2016 22:42:12 +0200 Subject: [OpenWrt-Devel] [PATCH 4/4] target: socfpga: Add Altera SoCFPGA support In-Reply-To: <1462221732-8027-1-git-send-email-marex@denx.de> References: <1462221732-8027-1-git-send-email-marex@denx.de> Message-ID: <1462221732-8027-4-git-send-email-marex@denx.de> This patch adds support for the Altera SoCFPGA target. Both generic target and Terasic SoCkit boards are supported. Signed-off-by: Marek Vasut --- package/boot/uboot-socfpga/Makefile | 97 +++ ...ga-Drop-space-after-loadaddr-in-extra-env.patch | 101 +++ ...fpga-Tweak-SoCkit-default-env-for-OpenWRT.patch | 65 ++ package/kernel/linux/modules/usb.mk | 4 +- target/linux/socfpga/Makefile | 39 ++ target/linux/socfpga/base-files.mk | 3 + target/linux/socfpga/base-files/etc/fw_env.config | 3 + .../socfpga/base-files/etc/init.d/sockit_vtcon | 15 + .../socfpga/base-files/etc/uci-defaults/01_leds | 22 + .../socfpga/base-files/etc/uci-defaults/02_network | 25 + .../base-files/lib/preinit/03_socfpga_detect | 9 + .../socfpga/base-files/lib/preinit/79_move_config | 18 + target/linux/socfpga/base-files/lib/socfpga.sh | 48 ++ .../socfpga/base-files/lib/upgrade/platform.sh | 37 ++ .../linux/socfpga/base-files/lib/upgrade/sockit.sh | 88 +++ target/linux/socfpga/config-4.4 | 695 +++++++++++++++++++++ target/linux/socfpga/image/Config.in | 5 + target/linux/socfpga/image/Makefile | 135 ++++ .../linux/socfpga/image/gen_socfpga_sdcard_img.sh | 41 ++ target/linux/socfpga/image/ubinize.cfg | 13 + ...-gpio-altera-Fix-altr-interrupt-type-prop.patch | 45 ++ ...dwc2-gadget-Repair-DSTS-register-decoding.patch | 36 ++ ...-dts-Enable-MMC-support-at-correct-place-.patch | 90 +++ ...ocfpga-Add-support-for-HPS-LEDs-on-SoCKit.patch | 66 ++ ...ga-Add-support-for-HPS-KEYs-SWs-on-SoCKit.patch | 100 +++ target/linux/socfpga/profiles/100-generic.mk | 17 + .../linux/socfpga/profiles/110-socfpga_sockit.mk | 28 + 27 files changed, 1843 insertions(+), 2 deletions(-) create mode 100644 package/boot/uboot-socfpga/Makefile create mode 100644 package/boot/uboot-socfpga/patches/0001-arm-socfpga-Drop-space-after-loadaddr-in-extra-env.patch create mode 100644 package/boot/uboot-socfpga/patches/0002-arm-socfpga-Tweak-SoCkit-default-env-for-OpenWRT.patch create mode 100644 target/linux/socfpga/Makefile create mode 100644 target/linux/socfpga/base-files.mk create mode 100644 target/linux/socfpga/base-files/etc/fw_env.config create mode 100755 target/linux/socfpga/base-files/etc/init.d/sockit_vtcon create mode 100644 target/linux/socfpga/base-files/etc/uci-defaults/01_leds create mode 100644 target/linux/socfpga/base-files/etc/uci-defaults/02_network create mode 100644 target/linux/socfpga/base-files/lib/preinit/03_socfpga_detect create mode 100644 target/linux/socfpga/base-files/lib/preinit/79_move_config create mode 100755 target/linux/socfpga/base-files/lib/socfpga.sh create mode 100755 target/linux/socfpga/base-files/lib/upgrade/platform.sh create mode 100644 target/linux/socfpga/base-files/lib/upgrade/sockit.sh create mode 100644 target/linux/socfpga/config-4.4 create mode 100644 target/linux/socfpga/image/Config.in create mode 100644 target/linux/socfpga/image/Makefile create mode 100755 target/linux/socfpga/image/gen_socfpga_sdcard_img.sh create mode 100644 target/linux/socfpga/image/ubinize.cfg create mode 100644 target/linux/socfpga/patches-4.4/0001-dt-bindings-gpio-altera-Fix-altr-interrupt-type-prop.patch create mode 100644 target/linux/socfpga/patches-4.4/0002-usb-dwc2-gadget-Repair-DSTS-register-decoding.patch create mode 100644 target/linux/socfpga/patches-4.4/0003-ARM-socfpga-dts-Enable-MMC-support-at-correct-place-.patch create mode 100644 target/linux/socfpga/patches-4.4/0004-ARM-socfpga-Add-support-for-HPS-LEDs-on-SoCKit.patch create mode 100644 target/linux/socfpga/patches-4.4/0005-ARM-socfpga-Add-support-for-HPS-KEYs-SWs-on-SoCKit.patch create mode 100644 target/linux/socfpga/profiles/100-generic.mk create mode 100644 target/linux/socfpga/profiles/110-socfpga_sockit.mk diff --git a/package/boot/uboot-socfpga/Makefile b/package/boot/uboot-socfpga/Makefile new file mode 100644 index 0000000..42fcb43 --- /dev/null +++ b/package/boot/uboot-socfpga/Makefile @@ -0,0 +1,97 @@ +# +# Copyright (C) 2015 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:=u-boot +PKG_VERSION:=2016.03 +PKG_RELEASE:=1 + +PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME)-$(BUILD_VARIANT)/$(PKG_NAME)-$(PKG_VERSION) +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2 +PKG_SOURCE_URL:= \ + http://mirror2.openwrt.org/sources \ + ftp://ftp.denx.de/pub/u-boot +PKG_MD5SUM:=973c1d896be751321cc3aafa564f64b2 + +PKG_LICENSE:=GPL-2.0 GPL-2.0+ +PKG_LICENSE_FILES:=Licenses/README +PKG_BUILD_PARALLEL:=1 + +include $(INCLUDE_DIR)/package.mk + +define uboot/Default + TITLE:= + CONFIG:= + IMAGE:= +endef + +define uboot/socfpga_cyclone5_sockit + TITLE := U-Boot for Terasic SoCkit board + CONFIG := socfpga_sockit + IMAGE := u-boot-with-spl.sfp +endef + +UBOOTS := \ + socfpga_cyclone5_sockit + +define Package/uboot/template +define Package/uboot-socfpga-$(1) + SECTION:=boot + CATEGORY:=Boot Loaders + DEPENDS:=@TARGET_socfpga + TITLE:=$(2) + URL:=http://www.denx.de/wiki/U-Boot + VARIANT:=$(1) + MAINTAINER:=Marek Vasut +endef +endef + +define BuildUBootPackage + $(eval $(uboot/Default)) + $(eval $(uboot/$(1))) + $(call Package/uboot/template,$(1),$(TITLE)) +endef + +ifdef BUILD_VARIANT +$(eval $(call uboot/$(BUILD_VARIANT))) +UBOOT_CONFIG:=$(if $(CONFIG),$(CONFIG),$(BUILD_VARIANT)) +UBOOT_IMAGE:=$(if $(IMAGE),$(IMAGE),openwrt-$(BOARD)-$(BUILD_VARIANT)-u-boot.bin) +endif + +define Build/Configure + +$(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR) $(UBOOT_CONFIG)_config +endef + +define Build/Compile + +$(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR) CROSS_COMPILE=$(TARGET_CROSS) $(IMAGE) +endef + +define Package/uboot/install/default + $(INSTALL_DIR) $(BIN_DIR)/uboot-$(BOARD)-$(1) + $(CP) $(PKG_BUILD_DIR)/u-boot.bin \ + $(BIN_DIR)/uboot-$(BOARD)-$(1)/openwrt-$(BOARD)-$(1)-u-boot.bin + $(CP) $(PKG_BUILD_DIR)/spl/u-boot-spl.bin \ + $(BIN_DIR)/uboot-$(BOARD)-$(1)/openwrt-$(BOARD)-$(1)-u-boot-spl.bin + $(CP) $(PKG_BUILD_DIR)/u-boot-with-spl.sfp \ + $(BIN_DIR)/uboot-$(BOARD)-$(1)/openwrt-$(BOARD)-$(1)-u-boot-with-spl.sfp +endef + +define Package/uboot/install/template +define Package/uboot-socfpga-$(1)/install + $(call Package/uboot/install/default,$(2)) +endef +endef + +$(foreach u,$(UBOOTS), \ + $(eval $(call Package/uboot/install/template,$(u),$(u))) \ +) + +$(foreach u,$(UBOOTS), \ + $(eval $(call BuildUBootPackage,$(u))) \ + $(eval $(call BuildPackage,uboot-socfpga-$(u))) \ +) diff --git a/package/boot/uboot-socfpga/patches/0001-arm-socfpga-Drop-space-after-loadaddr-in-extra-env.patch b/package/boot/uboot-socfpga/patches/0001-arm-socfpga-Drop-space-after-loadaddr-in-extra-env.patch new file mode 100644 index 0000000..261afef --- /dev/null +++ b/package/boot/uboot-socfpga/patches/0001-arm-socfpga-Drop-space-after-loadaddr-in-extra-env.patch @@ -0,0 +1,101 @@ +From 04a4c90fee75c95130af1e40880c0927d56b0b61 Mon Sep 17 00:00:00 2001 +From: Marek Vasut +Date: Sun, 3 Apr 2016 19:11:12 +0200 +Subject: [PATCH 1/2] arm: socfpga: Drop space after 'loadaddr=' in extra env + +There is an incorrect space after loadaddr= in the extra environment, +so drop it. + +Signed-off-by: Marek Vasut +Cc: Dinh Nguyen +Cc: Chin Liang See +--- + include/configs/socfpga_arria5_socdk.h | 2 +- + include/configs/socfpga_cyclone5_socdk.h | 2 +- + include/configs/socfpga_de0_nano_soc.h | 2 +- + include/configs/socfpga_sockit.h | 2 +- + include/configs/socfpga_socrates.h | 2 +- + include/configs/socfpga_sr1500.h | 2 +- + 6 files changed, 6 insertions(+), 6 deletions(-) + +diff --git a/include/configs/socfpga_arria5_socdk.h b/include/configs/socfpga_arria5_socdk.h +index a0161bc..153f9f8 100644 +--- a/include/configs/socfpga_arria5_socdk.h ++++ b/include/configs/socfpga_arria5_socdk.h +@@ -56,7 +56,7 @@ + /* Extra Environment */ + #define CONFIG_EXTRA_ENV_SETTINGS \ + "verify=n\0" \ +- "loadaddr= " __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \ ++ "loadaddr=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \ + "ramboot=setenv bootargs " CONFIG_BOOTARGS ";" \ + "bootm ${loadaddr} - ${fdt_addr}\0" \ + "bootimage=zImage\0" \ +diff --git a/include/configs/socfpga_cyclone5_socdk.h b/include/configs/socfpga_cyclone5_socdk.h +index c4c4ecb..d7c339e 100644 +--- a/include/configs/socfpga_cyclone5_socdk.h ++++ b/include/configs/socfpga_cyclone5_socdk.h +@@ -56,7 +56,7 @@ + /* Extra Environment */ + #define CONFIG_EXTRA_ENV_SETTINGS \ + "verify=n\0" \ +- "loadaddr= " __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \ ++ "loadaddr=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \ + "ramboot=setenv bootargs " CONFIG_BOOTARGS ";" \ + "bootm ${loadaddr} - ${fdt_addr}\0" \ + "bootimage=zImage\0" \ +diff --git a/include/configs/socfpga_de0_nano_soc.h b/include/configs/socfpga_de0_nano_soc.h +index cbc7396..314b9bf 100644 +--- a/include/configs/socfpga_de0_nano_soc.h ++++ b/include/configs/socfpga_de0_nano_soc.h +@@ -51,7 +51,7 @@ + + /* Extra Environment */ + #define CONFIG_EXTRA_ENV_SETTINGS \ +- "loadaddr= " __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \ ++ "loadaddr=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \ + "ramboot=setenv bootargs " CONFIG_BOOTARGS ";" \ + "bootm ${loadaddr} - ${fdt_addr}\0" \ + "bootimage=zImage\0" \ +diff --git a/include/configs/socfpga_sockit.h b/include/configs/socfpga_sockit.h +index 95e7ba6..07cfcbf 100644 +--- a/include/configs/socfpga_sockit.h ++++ b/include/configs/socfpga_sockit.h +@@ -52,7 +52,7 @@ + /* Extra Environment */ + #define CONFIG_EXTRA_ENV_SETTINGS \ + "verify=n\0" \ +- "loadaddr= " __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \ ++ "loadaddr=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \ + "ramboot=setenv bootargs " CONFIG_BOOTARGS ";" \ + "bootm ${loadaddr} - ${fdt_addr}\0" \ + "bootimage=zImage\0" \ +diff --git a/include/configs/socfpga_socrates.h b/include/configs/socfpga_socrates.h +index c32a40a..02ea0c5 100644 +--- a/include/configs/socfpga_socrates.h ++++ b/include/configs/socfpga_socrates.h +@@ -52,7 +52,7 @@ + /* Extra Environment */ + #define CONFIG_EXTRA_ENV_SETTINGS \ + "verify=n\0" \ +- "loadaddr= " __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \ ++ "loadaddr=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \ + "ramboot=setenv bootargs " CONFIG_BOOTARGS ";" \ + "bootm ${loadaddr} - ${fdt_addr}\0" \ + "bootimage=zImage\0" \ +diff --git a/include/configs/socfpga_sr1500.h b/include/configs/socfpga_sr1500.h +index 6414eeb..e43b5cf 100644 +--- a/include/configs/socfpga_sr1500.h ++++ b/include/configs/socfpga_sr1500.h +@@ -55,7 +55,7 @@ + + #define CONFIG_EXTRA_ENV_SETTINGS \ + "verify=n\0" \ +- "loadaddr= " __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \ ++ "loadaddr=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \ + "ramboot=setenv bootargs " CONFIG_BOOTARGS ";" \ + "bootm ${loadaddr} - ${fdt_addr}\0" \ + "bootimage=zImage\0" \ +-- +2.8.0.rc3 + diff --git a/package/boot/uboot-socfpga/patches/0002-arm-socfpga-Tweak-SoCkit-default-env-for-OpenWRT.patch b/package/boot/uboot-socfpga/patches/0002-arm-socfpga-Tweak-SoCkit-default-env-for-OpenWRT.patch new file mode 100644 index 0000000..64ffea2 --- /dev/null +++ b/package/boot/uboot-socfpga/patches/0002-arm-socfpga-Tweak-SoCkit-default-env-for-OpenWRT.patch @@ -0,0 +1,65 @@ +From 3a0e4875b00e9e487b0081116a81ed17cfd5143f Mon Sep 17 00:00:00 2001 +From: Marek Vasut +Date: Sun, 3 Apr 2016 19:27:23 +0200 +Subject: [PATCH 2/2] arm: socfpga: Tweak SoCkit default env for OpenWRT + +Tweak the default environment on SoCFPGA SoCkit to match OpenWRT. +This means switching to fitImage, which is already available, but +not used by the environment and weeding out completely dysfunctional +pieces of the environment. + +Signed-off-by: Marek Vasut +--- + include/configs/socfpga_sockit.h | 20 ++++++-------------- + 1 file changed, 6 insertions(+), 14 deletions(-) + +diff --git a/include/configs/socfpga_sockit.h b/include/configs/socfpga_sockit.h +index 07cfcbf..5a90105 100644 +--- a/include/configs/socfpga_sockit.h ++++ b/include/configs/socfpga_sockit.h +@@ -35,7 +35,7 @@ + + /* Booting Linux */ + #define CONFIG_BOOTDELAY 3 +-#define CONFIG_BOOTFILE "fitImage" ++#define CONFIG_BOOTFILE "openwrt-socfpga-socfpga_cyclone5_sockit-fit-uImage.itb" + #define CONFIG_BOOTARGS "console=ttyS0," __stringify(CONFIG_BAUDRATE) + #define CONFIG_BOOTCOMMAND "run mmcload; run mmcboot" + #define CONFIG_LOADADDR 0x01000000 +@@ -51,28 +51,20 @@ + + /* Extra Environment */ + #define CONFIG_EXTRA_ENV_SETTINGS \ +- "verify=n\0" \ + "loadaddr=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \ + "ramboot=setenv bootargs " CONFIG_BOOTARGS ";" \ +- "bootm ${loadaddr} - ${fdt_addr}\0" \ +- "bootimage=zImage\0" \ +- "fdt_addr=100\0" \ +- "fdtimage=socfpga.dtb\0" \ +- "bootm ${loadaddr} - ${fdt_addr}\0" \ ++ "bootm ${loadaddr}\0" \ + "mmcroot=/dev/mmcblk0p2\0" \ + "mmcboot=setenv bootargs " CONFIG_BOOTARGS \ + " root=${mmcroot} rw rootwait;" \ +- "bootz ${loadaddr} - ${fdt_addr}\0" \ +- "mmcload=mmc rescan;" \ +- "load mmc 0:1 ${loadaddr} ${bootimage};" \ +- "load mmc 0:1 ${fdt_addr} ${fdtimage}\0" \ ++ "bootm ${loadaddr}\0" \ ++ "mmcload=mmc rescan && load mmc 0:2 ${loadaddr} /boot/${bootfile}\0" \ + "qspiload=sf probe && mtdparts default && run ubiload\0" \ + "qspiboot=setenv bootargs " CONFIG_BOOTARGS \ + " ubi.mtd=1,64 root=ubi0:rootfs rw rootfstype=ubifs;"\ +- "bootz ${loadaddr} - ${fdt_addr}\0" \ ++ "bootz ${loadaddr}\0" \ + "ubiload=ubi part UBI && ubifsmount ubi0 && " \ +- "ubifsload ${loadaddr} /boot/${bootimage} && " \ +- "ubifsload ${fdt_addr} /boot/${fdtimage}\0" ++ "ubifsload ${loadaddr} /boot/${bootfile}\0" + + /* The rest of the configuration is shared */ + #include +-- +2.8.0.rc3 + diff --git a/package/kernel/linux/modules/usb.mk b/package/kernel/linux/modules/usb.mk index 22b7f64..cfd5b11 100644 --- a/package/kernel/linux/modules/usb.mk +++ b/package/kernel/linux/modules/usb.mk @@ -303,8 +303,8 @@ define KernelPackage/usb-storage-gadget DEPENDS:=+kmod-usb-gadget +kmod-usb-lib-composite FILES:= \ $(LINUX_DIR)/drivers/usb/gadget/function/usb_f_mass_storage.ko \ - $(LINUX_DIR)/drivers/usb/gadget/legacy/g_storage.ko - AUTOLOAD:=$(call AutoLoad,52,usb_f_mass_storage g_storage) + $(LINUX_DIR)/drivers/usb/gadget/legacy/g_mass_storage.ko + AUTOLOAD:=$(call AutoLoad,52,usb_f_mass_storage g_mass_storage) $(call AddDepends/usb) endef diff --git a/target/linux/socfpga/Makefile b/target/linux/socfpga/Makefile new file mode 100644 index 0000000..6d75a4b --- /dev/null +++ b/target/linux/socfpga/Makefile @@ -0,0 +1,39 @@ +# +# Copyright (C) 2015 OpenWrt.org +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# +include $(TOPDIR)/rules.mk + +ARCH:=arm +BOARD:=socfpga +BOARDNAME:=Altera SoCFPGA +FEATURES:=display fpu gpio rtc usb usbgadget targz ext4 ubifs ramdisk +CPU_TYPE:=cortex-a9 +CPU_SUBTYPE:=neon +MAINTAINER:=Marek Vasut +DEVICE_TYPE:=other + +KERNEL_PATCHVER:=4.4 +KERNELNAME:=zImage dtbs + +include $(INCLUDE_DIR)/target.mk + +DEFAULT_PACKAGES += \ + uboot-envtools \ + ubi-utils \ + kmod-button-hotplug \ + kmod-ledtrig-netdev \ + kmod-usb-core \ + kmod-usb-dwc2 \ + kmod-usb-phy-nop \ + kmod-usb-gadget \ + kmod-usb-lib-composite \ + kmod-usb-storage \ + kmod-usb-storage-gadget \ + dnsmasq iptables ip6tables \ + kmod-nf-nathelper firewall \ + odhcpd odhcp6c + +$(eval $(call BuildTarget)) diff --git a/target/linux/socfpga/base-files.mk b/target/linux/socfpga/base-files.mk new file mode 100644 index 0000000..fdd2c71 --- /dev/null +++ b/target/linux/socfpga/base-files.mk @@ -0,0 +1,3 @@ +define Package/base-files/install-target + rm -f $(1)/etc/config/network +endef diff --git a/target/linux/socfpga/base-files/etc/fw_env.config b/target/linux/socfpga/base-files/etc/fw_env.config new file mode 100644 index 0000000..f6fe3f9 --- /dev/null +++ b/target/linux/socfpga/base-files/etc/fw_env.config @@ -0,0 +1,3 @@ +# MTD device name Device offset Env. size Flash sector size +/dev/mtd1 0x0 0x1000 0x10000 +/dev/mtd2 0x0 0x1000 0x10000 diff --git a/target/linux/socfpga/base-files/etc/init.d/sockit_vtcon b/target/linux/socfpga/base-files/etc/init.d/sockit_vtcon new file mode 100755 index 0000000..6555f5b --- /dev/null +++ b/target/linux/socfpga/base-files/etc/init.d/sockit_vtcon @@ -0,0 +1,15 @@ +#!/bin/sh /etc/rc.common + +START=99 + +start() { + . /lib/socfpga.sh + + local board=$(socfpga_board_name) + + # Print something nice on the VTcon (the SPI LCD) + if [ "${board}" = "socfpga-sockit" ] ; then + echo "OpenWRT" > /dev/tty0 + uci show network.lan.ipaddr > /dev/tty0 + fi +} diff --git a/target/linux/socfpga/base-files/etc/uci-defaults/01_leds b/target/linux/socfpga/base-files/etc/uci-defaults/01_leds new file mode 100644 index 0000000..a04de3b --- /dev/null +++ b/target/linux/socfpga/base-files/etc/uci-defaults/01_leds @@ -0,0 +1,22 @@ +#!/bin/sh +# +# Copyright (C) 2015 OpenWrt.org +# + +. /lib/functions/uci-defaults.sh +. /lib/socfpga.sh + +board=$(socfpga_board_name) + +case "$board" in +"socfpga-sockit") + ucidef_set_led_netdev "lan" "LAN" "hps:blue:led0" "eth0" + ucidef_set_led_mmc "mmc" "MMC" "hps:blue:led1" "mmc0" + ucidef_set_led_default "health" "health" "hps:blue:led2" "1" + ucidef_set_led_default "fault" "fault" "hps:blue:led3" "1" + ;; +esac + +ucidef_commit_leds + +exit 0 diff --git a/target/linux/socfpga/base-files/etc/uci-defaults/02_network b/target/linux/socfpga/base-files/etc/uci-defaults/02_network new file mode 100644 index 0000000..479e820 --- /dev/null +++ b/target/linux/socfpga/base-files/etc/uci-defaults/02_network @@ -0,0 +1,25 @@ +#!/bin/sh +# +# Copyright (C) 2015 OpenWrt.org +# + +[ -e /etc/config/network ] && exit 0 + +touch /etc/config/network + +. /lib/functions/uci-defaults.sh +. /lib/socfpga.sh + +board=$(socfpga_board_name) + +ucidef_set_interface_loopback + +case "$board" in +"socfpga-sockit") + ucidef_set_interface_lan 'eth0' + ;; +esac + +uci commit network + +exit 0 diff --git a/target/linux/socfpga/base-files/lib/preinit/03_socfpga_detect b/target/linux/socfpga/base-files/lib/preinit/03_socfpga_detect new file mode 100644 index 0000000..fc2f20a --- /dev/null +++ b/target/linux/socfpga/base-files/lib/preinit/03_socfpga_detect @@ -0,0 +1,9 @@ +#!/bin/sh + +do_socfpga_detect() { + . /lib/socfpga.sh + + socfpga_board_detect +} + +boot_hook_add preinit_main do_socfpga_detect diff --git a/target/linux/socfpga/base-files/lib/preinit/79_move_config b/target/linux/socfpga/base-files/lib/preinit/79_move_config new file mode 100644 index 0000000..89f62d5 --- /dev/null +++ b/target/linux/socfpga/base-files/lib/preinit/79_move_config @@ -0,0 +1,18 @@ +#!/bin/sh +# Copyright (C) 2015 OpenWrt.org + +move_config() { + . /lib/socfpga.sh + . /lib/upgrade/sockit.sh + + local board=$(socfpga_board_name) + + # Restore configuration + if [ "${board}" = "socfpga-sockit" ] ; then + mount -o rw,noatime "$CFGPART" /mnt + [ -e "/mnt/sysupgrade.tgz" ] && mv -f /mnt/sysupgrade.tgz / + umount /mnt + fi +} + +boot_hook_add preinit_mount_root move_config diff --git a/target/linux/socfpga/base-files/lib/socfpga.sh b/target/linux/socfpga/base-files/lib/socfpga.sh new file mode 100755 index 0000000..26735ac --- /dev/null +++ b/target/linux/socfpga/base-files/lib/socfpga.sh @@ -0,0 +1,48 @@ +#!/bin/sh +# +# Copyright (C) 2010-2013 OpenWrt.org +# + +SOCFPGA_BOARD_NAME= +SOCFPGA_MODEL= + +socfpga_board_detect() { + local machine + local name + + machine=$(cat /proc/device-tree/model) + + case "$machine" in + "Terasic SoCkit") + name="socfpga-sockit" + ;; + *) + name="generic" + ;; + esac + + [ -z "$SOCFPGA_BOARD_NAME" ] && SOCFPGA_BOARD_NAME="$name" + [ -z "$SOCFPGA_MODEL" ] && SOCFPGA_MODEL="$machine" + + [ -e "/tmp/sysinfo/" ] || mkdir -p "/tmp/sysinfo/" + + echo "$SOCFPGA_BOARD_NAME" > /tmp/sysinfo/board_name + echo "$SOCFPGA_MODEL" > /tmp/sysinfo/model +} + +socfpga_board_name() { + local name + + [ -f /tmp/sysinfo/board_name ] || socfpga_board_detect + [ -f /tmp/sysinfo/board_name ] && name=$(cat /tmp/sysinfo/board_name) + + # Name is too generic, use model + if [ "$name" = "altr,socfpga-cyclone5" ] ; then + socfpga_board_detect + name=$(cat /tmp/sysinfo/board_name) + fi + + [ -z "$name" ] && name="unknown" + + echo "$name" +} diff --git a/target/linux/socfpga/base-files/lib/upgrade/platform.sh b/target/linux/socfpga/base-files/lib/upgrade/platform.sh new file mode 100755 index 0000000..d65e11e --- /dev/null +++ b/target/linux/socfpga/base-files/lib/upgrade/platform.sh @@ -0,0 +1,37 @@ +# +# Copyright (C) 2014 OpenWrt.org +# + +. /lib/socfpga.sh + +RAMFS_COPY_BIN="/bin/mkdir /bin/touch /bin/mknod" +RAMFS_COPY_DATA=/lib/socfpga.sh + +platform_check_image() { + local board=$(socfpga_board_name) + + [ "$#" -gt 1 ] && return 1 + + case "$board" in + "socfpga-sockit") + platform_do_check_sockit "$ARGV" + return 0; + ;; + esac + + echo "Sysupgrade is not yet supported on $board." + return 1 +} + +platform_do_upgrade() { + local board=$(socfpga_board_name) + + case "$board" in + "socfpga-sockit") + platform_do_upgrade_sockit "$ARGV" + ;; + *) + default_do_upgrade "$ARGV" + ;; + esac +} diff --git a/target/linux/socfpga/base-files/lib/upgrade/sockit.sh b/target/linux/socfpga/base-files/lib/upgrade/sockit.sh new file mode 100644 index 0000000..e9268cf --- /dev/null +++ b/target/linux/socfpga/base-files/lib/upgrade/sockit.sh @@ -0,0 +1,88 @@ +# +# Copyright (C) 2014-2015 OpenWrt.org +# + +BOOTPART=/dev/mmcblk0p2 +CFGPART=/dev/mmcblk0p3 + +identify_magic() { + local magic=$1 + case "$magic" in + "55424923") + echo "ubi" + ;; + "31181006") + echo "ubifs" + ;; + "68737173") + echo "squashfs" + ;; + "d00dfeed") + echo "fit" + ;; + "00000000") + echo "ext4" + ;; + "4349"*) + echo "combined" + ;; + *) + echo "unknown $magic" + ;; + esac +} + +get_magic_long_tar() { + ( tar xf $1 $2 -O | dd bs=4 count=1 | hexdump -v -n 4 -e '1/1 "%02x"') 2> /dev/null +} + +identify_tar() { + identify_magic $(get_magic_long_tar "$1" "$2") +} + +platform_do_check_sockit() { + local board=$(socfpga_board_name) + local magic_long="$(get_magic_long "$1")" + echo "magic = $magic_long" + + if [ "$magic_long" = "73797375" ] ; then + local rootfs_type="$(identify_tar "$1" sysupgrade-$board/root)" + if [ "$rootfs_type" = "ubifs" ] ; then + nand_do_platform_check $board $1 + return 0; + fi + [ "$rootfs_type" = "ext4" ] && return 0 + + echo "Unknown rootfs type $rootfs_type !" + fi + + return 1 +} + +platform_do_upgrade_sockit() { + local board=$(socfpga_board_name) + local magic_long="$(get_magic_long "$1")" + echo "magic = $magic_long" + + if [ "$magic_long" = "73797375" ] ; then + local rootfs_type="$(identify_tar "$1" sysupgrade-$board/root)" + if [ "$rootfs_type" = "ext4" ] ; then + sync + tar xf "$1" sysupgrade-$board/root -O | \ + dd of="$BOOTPART" bs=512 conv=fsync + return 0 + fi + + echo "Unknown rootfs type $rootfs_type !" + fi + + return 1 +} + +platform_copy_config() { + if [ -b "$CFGPART" ]; then + mount -o rw,noatime "$CFGPART" /mnt + cp -af "$CONF_TAR" /mnt/ + umount /mnt + fi +} diff --git a/target/linux/socfpga/config-4.4 b/target/linux/socfpga/config-4.4 new file mode 100644 index 0000000..15cac52 --- /dev/null +++ b/target/linux/socfpga/config-4.4 @@ -0,0 +1,695 @@ +CONFIG_ALIGNMENT_TRAP=y +CONFIG_ALTERA_TSE=y +# CONFIG_APM_EMULATION is not set +CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y +CONFIG_ARCH_HAS_ELF_RANDOMIZE=y +CONFIG_ARCH_HAS_GCOV_PROFILE_ALL=y +CONFIG_ARCH_HAS_SG_CHAIN=y +CONFIG_ARCH_HAS_TICK_BROADCAST=y +CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y +CONFIG_ARCH_HIBERNATION_POSSIBLE=y +CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y +CONFIG_ARCH_MULTIPLATFORM=y +# CONFIG_ARCH_MULTI_CPU_AUTO is not set +CONFIG_ARCH_MULTI_V6_V7=y +CONFIG_ARCH_MULTI_V7=y +CONFIG_ARCH_NR_GPIO=0 +# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set +CONFIG_ARCH_SOCFPGA=y +# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set +CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y +CONFIG_ARCH_SUPPORTS_BIG_ENDIAN=y +CONFIG_ARCH_SUPPORTS_UPROBES=y +CONFIG_ARCH_SUSPEND_POSSIBLE=y +CONFIG_ARCH_USE_BUILTIN_BSWAP=y +CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y +CONFIG_ARCH_WANT_GENERAL_HUGETLB=y +CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y +CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y +CONFIG_ARM=y +CONFIG_ARM_AMBA=y +CONFIG_ARM_CCI=y +CONFIG_ARM_CCI400_COMMON=y +CONFIG_ARM_CCI400_PMU=y +CONFIG_ARM_CCI_PMU=y +CONFIG_ARM_CPU_SUSPEND=y +CONFIG_ARM_ERRATA_643719=y +CONFIG_ARM_GIC=y +CONFIG_ARM_HAS_SG_CHAIN=y +CONFIG_ARM_HEAVY_MB=y +CONFIG_ARM_L1_CACHE_SHIFT=6 +CONFIG_ARM_L1_CACHE_SHIFT_6=y +# CONFIG_ARM_LPAE is not set +CONFIG_ARM_PATCH_PHYS_VIRT=y +CONFIG_ARM_PMU=y +# CONFIG_ARM_SP805_WATCHDOG is not set +CONFIG_ARM_THUMB=y +CONFIG_ARM_THUMBEE=y +CONFIG_ARM_VIRT_EXT=y +CONFIG_ASSOCIATIVE_ARRAY=y +CONFIG_AT803X_PHY=y +CONFIG_ATAGS=y +CONFIG_AUTO_ZRELADDR=y +CONFIG_BACKLIGHT_CLASS_DEVICE=y +CONFIG_BACKLIGHT_GPIO=y +CONFIG_BACKLIGHT_LCD_SUPPORT=y +# CONFIG_BLK_CGROUP is not set +CONFIG_BLK_DEV_LOOP=y +CONFIG_BLK_DEV_RAM=y +CONFIG_BLK_DEV_RAM_COUNT=2 +CONFIG_BLK_DEV_RAM_SIZE=8192 +CONFIG_BLK_DEV_SD=y +# CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set +CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0 +CONFIG_BOUNCE=y +CONFIG_BUILD_BIN2C=y +CONFIG_CACHE_L2X0=y +CONFIG_CAN=y +# CONFIG_CAN_8DEV_USB is not set +CONFIG_CAN_BCM=y +CONFIG_CAN_CALC_BITTIMING=y +# CONFIG_CAN_CC770 is not set +CONFIG_CAN_C_CAN=y +CONFIG_CAN_C_CAN_PLATFORM=y +CONFIG_CAN_DEBUG_DEVICES=y +CONFIG_CAN_DEV=y +# CONFIG_CAN_EMS_USB is not set +# CONFIG_CAN_ESD_USB2 is not set +# CONFIG_CAN_FLEXCAN is not set +# CONFIG_CAN_GRCAN is not set +CONFIG_CAN_GW=y +# CONFIG_CAN_KVASER_USB is not set +# CONFIG_CAN_LEDS is not set +# CONFIG_CAN_MCP251X is not set +# CONFIG_CAN_PEAK_USB is not set +CONFIG_CAN_RAW=y +# CONFIG_CAN_SJA1000 is not set +# CONFIG_CAN_SOFTING is not set +# CONFIG_CAN_TI_HECC is not set +CONFIG_CGROUPS=y +# CONFIG_CGROUP_CPUACCT is not set +# CONFIG_CGROUP_DEVICE is not set +# CONFIG_CGROUP_FREEZER is not set +# CONFIG_CGROUP_NET_CLASSID is not set +# CONFIG_CGROUP_PERF is not set +# CONFIG_CGROUP_PIDS is not set +# CONFIG_CGROUP_SCHED is not set +CONFIG_CLKDEV_LOOKUP=y +CONFIG_CLKSRC_OF=y +CONFIG_CLKSRC_PROBE=y +CONFIG_CLONE_BACKWARDS=y +CONFIG_COMMON_CLK=y +CONFIG_COMPACTION=y +CONFIG_CONFIGFS_FS=y +CONFIG_CONSOLE_TRANSLATIONS=y +CONFIG_COREDUMP=y +CONFIG_CPUSETS=y +CONFIG_CPU_32v6K=y +CONFIG_CPU_32v7=y +CONFIG_CPU_ABRT_EV7=y +# CONFIG_CPU_BIG_ENDIAN is not set +# CONFIG_CPU_BPREDICT_DISABLE is not set +CONFIG_CPU_CACHE_V7=y +CONFIG_CPU_CACHE_VIPT=y +CONFIG_CPU_COPY_V6=y +CONFIG_CPU_CP15=y +CONFIG_CPU_CP15_MMU=y +CONFIG_CPU_HAS_ASID=y +# CONFIG_CPU_ICACHE_DISABLE is not set +CONFIG_CPU_PABRT_V7=y +CONFIG_CPU_PM=y +CONFIG_CPU_RMAP=y +CONFIG_CPU_TLB_V7=y +CONFIG_CPU_V7=y +CONFIG_CRC16=y +CONFIG_CRYPTO_AEAD=m +CONFIG_CRYPTO_AEAD2=m +CONFIG_CRYPTO_CRC32C=y +CONFIG_CRYPTO_DEFLATE=y +CONFIG_CRYPTO_DRBG=m +CONFIG_CRYPTO_DRBG_HMAC=y +CONFIG_CRYPTO_DRBG_MENU=m +CONFIG_CRYPTO_ECHAINIV=m +CONFIG_CRYPTO_HASH=y +CONFIG_CRYPTO_HASH2=y +CONFIG_CRYPTO_HMAC=m +CONFIG_CRYPTO_JITTERENTROPY=m +CONFIG_CRYPTO_LZO=y +CONFIG_CRYPTO_MANAGER=m +CONFIG_CRYPTO_MANAGER2=y +CONFIG_CRYPTO_NULL=m +CONFIG_CRYPTO_NULL2=m +CONFIG_CRYPTO_RNG=m +CONFIG_CRYPTO_RNG2=y +CONFIG_CRYPTO_RNG_DEFAULT=m +CONFIG_CRYPTO_SHA256=m +CONFIG_CRYPTO_WORKQUEUE=y +CONFIG_CRYPTO_XZ=y +CONFIG_DCACHE_WORD_ACCESS=y +CONFIG_DEBUG_INFO=y +CONFIG_DEBUG_LL_INCLUDE="mach/debug-macro.S" +# CONFIG_DEBUG_UART_8250 is not set +CONFIG_DEBUG_USER=y +# CONFIG_DEFAULT_CFQ is not set +# CONFIG_DEFAULT_DEADLINE is not set +CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120 +CONFIG_DEFAULT_IOSCHED="noop" +CONFIG_DEFAULT_NOOP=y +CONFIG_DETECT_HUNG_TASK=y +CONFIG_DEVKMEM=y +CONFIG_DEVMEM=y +CONFIG_DEVTMPFS=y +CONFIG_DEVTMPFS_MOUNT=y +CONFIG_DNS_RESOLVER=y +# CONFIG_DP83640_PHY is not set +CONFIG_DTC=y +CONFIG_DUMMY_CONSOLE=y +CONFIG_DWMAC_GENERIC=y +CONFIG_DWMAC_SOCFPGA=y +# CONFIG_DWMAC_SUNXI is not set +CONFIG_DW_APB_TIMER=y +CONFIG_DW_APB_TIMER_OF=y +CONFIG_DW_WATCHDOG=y +CONFIG_EDAC_ATOMIC_SCRUB=y +CONFIG_EDAC_SUPPORT=y +CONFIG_EEPROM_AT24=y +CONFIG_EXPORTFS=y +CONFIG_EXT2_FS=y +CONFIG_EXT2_FS_POSIX_ACL=y +# CONFIG_EXT2_FS_SECURITY is not set +CONFIG_EXT2_FS_XATTR=y +CONFIG_EXT3_FS=y +# CONFIG_EXT3_FS_POSIX_ACL is not set +# CONFIG_EXT3_FS_SECURITY is not set +CONFIG_EXT4_FS=y +CONFIG_FAT_FS=y +CONFIG_FB=y +CONFIG_FB_BACKLIGHT=y +CONFIG_FB_CMDLINE=y +CONFIG_FB_DEFERRED_IO=y +# CONFIG_FB_FLEX is not set +CONFIG_FB_SYS_COPYAREA=y +CONFIG_FB_SYS_FILLRECT=y +CONFIG_FB_SYS_FOPS=y +CONFIG_FB_SYS_IMAGEBLIT=y +CONFIG_FB_TFT=y +# CONFIG_FB_TFT_AGM1264K_FL is not set +# CONFIG_FB_TFT_BD663474 is not set +# CONFIG_FB_TFT_FBTFT_DEVICE is not set +# CONFIG_FB_TFT_HX8340BN is not set +# CONFIG_FB_TFT_HX8347D is not set +# CONFIG_FB_TFT_HX8353D is not set +# CONFIG_FB_TFT_HX8357D is not set +# CONFIG_FB_TFT_ILI9163 is not set +# CONFIG_FB_TFT_ILI9320 is not set +# CONFIG_FB_TFT_ILI9325 is not set +# CONFIG_FB_TFT_ILI9340 is not set +# CONFIG_FB_TFT_ILI9341 is not set +# CONFIG_FB_TFT_ILI9481 is not set +# CONFIG_FB_TFT_ILI9486 is not set +# CONFIG_FB_TFT_PCD8544 is not set +# CONFIG_FB_TFT_RA8875 is not set +# CONFIG_FB_TFT_S6D02A1 is not set +# CONFIG_FB_TFT_S6D1121 is not set +# CONFIG_FB_TFT_SSD1289 is not set +# CONFIG_FB_TFT_SSD1306 is not set +# CONFIG_FB_TFT_SSD1331 is not set +# CONFIG_FB_TFT_SSD1351 is not set +# CONFIG_FB_TFT_ST7735R is not set +# CONFIG_FB_TFT_ST7789V is not set +# CONFIG_FB_TFT_TINYLCD is not set +# CONFIG_FB_TFT_TLS8204 is not set +# CONFIG_FB_TFT_UC1611 is not set +CONFIG_FB_TFT_UC1701=y +# CONFIG_FB_TFT_UPD161704 is not set +# CONFIG_FB_TFT_WATTEROTT is not set +CONFIG_FHANDLE=y +CONFIG_FIX_EARLYCON_MEM=y +# CONFIG_FONTS is not set +CONFIG_FONT_8x16=y +CONFIG_FONT_8x8=y +CONFIG_FONT_SUPPORT=y +CONFIG_FPGA=y +CONFIG_FPGA_MGR_SOCFPGA=y +# CONFIG_FPGA_MGR_ZYNQ_FPGA is not set +CONFIG_FRAMEBUFFER_CONSOLE=y +CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y +CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y +CONFIG_FRAME_POINTER=y +CONFIG_FREEZER=y +CONFIG_FS_MBCACHE=y +CONFIG_FS_POSIX_ACL=y +CONFIG_GARP=y +CONFIG_GENERIC_ALLOCATOR=y +CONFIG_GENERIC_BUG=y +CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y +CONFIG_GENERIC_IDLE_POLL_SETUP=y +CONFIG_GENERIC_IO=y +CONFIG_GENERIC_IRQ_CHIP=y +CONFIG_GENERIC_IRQ_SHOW=y +CONFIG_GENERIC_IRQ_SHOW_LEVEL=y +CONFIG_GENERIC_PCI_IOMAP=y +CONFIG_GENERIC_SCHED_CLOCK=y +CONFIG_GENERIC_SMP_IDLE_THREAD=y +CONFIG_GENERIC_STRNCPY_FROM_USER=y +CONFIG_GENERIC_STRNLEN_USER=y +CONFIG_GPIOLIB=y +CONFIG_GPIOLIB_IRQCHIP=y +CONFIG_GPIO_ALTERA=y +CONFIG_GPIO_DEVRES=y +CONFIG_GPIO_DWAPB=y +CONFIG_GPIO_GENERIC=y +CONFIG_GPIO_MCP23S08=y +CONFIG_GPIO_PCA953X=y +# CONFIG_GPIO_PCA953X_IRQ is not set +CONFIG_GPIO_PL061=y +CONFIG_GPIO_SYSFS=y +CONFIG_GRACE_PERIOD=y +CONFIG_HANDLE_DOMAIN_IRQ=y +CONFIG_HARDIRQS_SW_RESEND=y +CONFIG_HAS_DMA=y +CONFIG_HAS_IOMEM=y +CONFIG_HAS_IOPORT_MAP=y +# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set +CONFIG_HAVE_ARCH_AUDITSYSCALL=y +CONFIG_HAVE_ARCH_BITREVERSE=y +CONFIG_HAVE_ARCH_JUMP_LABEL=y +CONFIG_HAVE_ARCH_KGDB=y +CONFIG_HAVE_ARCH_PFN_VALID=y +CONFIG_HAVE_ARCH_SECCOMP_FILTER=y +CONFIG_HAVE_ARCH_TRACEHOOK=y +CONFIG_HAVE_ARM_SCU=y +CONFIG_HAVE_ARM_TWD=y +# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set +CONFIG_HAVE_BPF_JIT=y +CONFIG_HAVE_CC_STACKPROTECTOR=y +CONFIG_HAVE_CLK=y +CONFIG_HAVE_CLK_PREPARE=y +CONFIG_HAVE_CONTEXT_TRACKING=y +CONFIG_HAVE_C_RECORDMCOUNT=y +CONFIG_HAVE_DEBUG_KMEMLEAK=y +CONFIG_HAVE_DMA_API_DEBUG=y +CONFIG_HAVE_DMA_ATTRS=y +CONFIG_HAVE_DMA_CONTIGUOUS=y +CONFIG_HAVE_DYNAMIC_FTRACE=y +CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y +CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y +CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y +CONFIG_HAVE_FUNCTION_TRACER=y +CONFIG_HAVE_GENERIC_DMA_COHERENT=y +CONFIG_HAVE_HW_BREAKPOINT=y +CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y +CONFIG_HAVE_KERNEL_GZIP=y +CONFIG_HAVE_KERNEL_LZ4=y +CONFIG_HAVE_KERNEL_LZMA=y +CONFIG_HAVE_KERNEL_LZO=y +CONFIG_HAVE_KERNEL_XZ=y +CONFIG_HAVE_MEMBLOCK=y +CONFIG_HAVE_MOD_ARCH_SPECIFIC=y +CONFIG_HAVE_NET_DSA=y +CONFIG_HAVE_OPROFILE=y +CONFIG_HAVE_OPTPROBES=y +CONFIG_HAVE_PERF_EVENTS=y +CONFIG_HAVE_PERF_REGS=y +CONFIG_HAVE_PERF_USER_STACK_DUMP=y +CONFIG_HAVE_PROC_CPU=y +CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y +CONFIG_HAVE_SMP=y +CONFIG_HAVE_SYSCALL_TRACEPOINTS=y +CONFIG_HAVE_UID16=y +CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y +CONFIG_HIGHMEM=y +# CONFIG_HIGHPTE is not set +CONFIG_HOTPLUG_CPU=y +CONFIG_HWMON=y +CONFIG_HW_CONSOLE=y +CONFIG_HW_RANDOM=m +CONFIG_HZ=250 +# CONFIG_HZ_100 is not set +CONFIG_HZ_250=y +CONFIG_HZ_FIXED=0 +CONFIG_HZ_PERIODIC=y +CONFIG_I2C=y +CONFIG_I2C_BOARDINFO=y +CONFIG_I2C_CHARDEV=y +CONFIG_I2C_DESIGNWARE_CORE=y +CONFIG_I2C_DESIGNWARE_PLATFORM=y +CONFIG_I2C_MUX=y +CONFIG_I2C_MUX_PCA954x=y +CONFIG_IIO=y +CONFIG_IIO_BUFFER=y +CONFIG_IIO_BUFFER_CB=y +CONFIG_IIO_KFIFO_BUF=y +CONFIG_IIO_TRIGGER=y +CONFIG_IIO_TRIGGERED_BUFFER=y +CONFIG_IKCONFIG=y +CONFIG_IKCONFIG_PROC=y +CONFIG_INITRAMFS_SOURCE="" +CONFIG_INPUT=y +CONFIG_INPUT_ADXL34X=y +CONFIG_INPUT_ADXL34X_I2C=y +CONFIG_INPUT_ADXL34X_SPI=y +CONFIG_INPUT_EVDEV=y +CONFIG_INPUT_KEYBOARD=y +CONFIG_INPUT_LEDS=y +CONFIG_IOMMU_HELPER=y +CONFIG_IOSCHED_CFQ=y +CONFIG_IP6_NF_FILTER=m +CONFIG_IP6_NF_IPTABLES=m +CONFIG_IP6_NF_MANGLE=m +CONFIG_IP6_NF_MATCH_IPV6HEADER=m +CONFIG_IP6_NF_RAW=m +CONFIG_IP6_NF_TARGET_REJECT=m +CONFIG_IPV6=y +# CONFIG_IPV6_GRE is not set +CONFIG_IP_NF_FILTER=m +CONFIG_IP_NF_IPTABLES=m +CONFIG_IP_NF_MANGLE=m +CONFIG_IP_NF_NAT=m +CONFIG_IP_NF_RAW=m +CONFIG_IP_NF_TARGET_MASQUERADE=m +CONFIG_IP_NF_TARGET_REJECT=m +CONFIG_IP_PNP=y +CONFIG_IP_PNP_BOOTP=y +CONFIG_IP_PNP_DHCP=y +CONFIG_IP_PNP_RARP=y +CONFIG_IRQCHIP=y +CONFIG_IRQ_DOMAIN=y +CONFIG_IRQ_DOMAIN_HIERARCHY=y +CONFIG_IRQ_FORCED_THREADING=y +CONFIG_IRQ_WORK=y +# CONFIG_ISDN is not set +CONFIG_JBD2=y +# CONFIG_JFFS2_FS is not set +# CONFIG_KERNEL_MODE_NEON is not set +CONFIG_KEYBOARD_GPIO=y +CONFIG_KEYS=y +# CONFIG_LBDAF is not set +# CONFIG_LCD_CLASS_DEVICE is not set +CONFIG_LEDS_GPIO=y +CONFIG_LEDS_TRIGGER_HEARTBEAT=y +CONFIG_LEGACY_PTYS=y +CONFIG_LEGACY_PTY_COUNT=256 +CONFIG_LIBFDT=y +CONFIG_LOCKD=y +CONFIG_LOCK_SPIN_ON_OWNER=y +CONFIG_LOG_BUF_SHIFT=14 +CONFIG_LZO_COMPRESS=y +CONFIG_LZO_DECOMPRESS=y +CONFIG_MAGIC_SYSRQ=y +CONFIG_MAX1363=y +CONFIG_MCP4531=y +CONFIG_MDIO_BOARDINFO=y +# CONFIG_MEMCG is not set +CONFIG_MFD_SYSCON=y +CONFIG_MICREL_PHY=y +CONFIG_MIGHT_HAVE_CACHE_L2X0=y +CONFIG_MIGHT_HAVE_PCI=y +CONFIG_MIGRATION=y +CONFIG_MMC=y +CONFIG_MMC_BLOCK=y +CONFIG_MMC_DW=y +# CONFIG_MMC_DW_EXYNOS is not set +# CONFIG_MMC_DW_K3 is not set +CONFIG_MMC_DW_PLTFM=y +CONFIG_MODULES_TREE_LOOKUP=y +CONFIG_MODULES_USE_ELF_REL=y +CONFIG_MTD_CMDLINE_PARTS=y +CONFIG_MTD_SPI_NOR=y +CONFIG_MTD_UBI=y +CONFIG_MTD_UBI_BEB_LIMIT=20 +CONFIG_MTD_UBI_BLOCK=y +CONFIG_MTD_UBI_FASTMAP=y +# CONFIG_MTD_UBI_GLUEBI is not set +CONFIG_MTD_UBI_WL_THRESHOLD=4096 +CONFIG_MULTI_IRQ_HANDLER=y +CONFIG_MUTEX_SPIN_ON_OWNER=y +CONFIG_NAMESPACES=y +CONFIG_NEED_DMA_MAP_STATE=y +CONFIG_NEON=y +CONFIG_NETFILTER=y +CONFIG_NETFILTER_INGRESS=y +CONFIG_NETFILTER_NETLINK=m +CONFIG_NETFILTER_NETLINK_GLUE_CT=y +CONFIG_NETFILTER_NETLINK_LOG=m +CONFIG_NETFILTER_XTABLES=m +CONFIG_NETFILTER_XT_MARK=m +CONFIG_NETFILTER_XT_MATCH_ADDRTYPE=m +CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m +CONFIG_NETFILTER_XT_MATCH_POLICY=m +CONFIG_NETFILTER_XT_MATCH_STATE=m +CONFIG_NETFILTER_XT_NAT=m +CONFIG_NETFILTER_XT_TARGET_LOG=m +CONFIG_NETFILTER_XT_TARGET_NETMAP=m +CONFIG_NETFILTER_XT_TARGET_NFLOG=m +CONFIG_NETFILTER_XT_TARGET_REDIRECT=m +CONFIG_NETFILTER_XT_TARGET_TCPMSS=m +CONFIG_NETWORK_PHY_TIMESTAMPING=y +# CONFIG_NET_CADENCE is not set +# CONFIG_NET_CLS_CGROUP is not set +CONFIG_NET_FLOW_LIMIT=y +CONFIG_NET_INGRESS=y +CONFIG_NET_KEY=y +CONFIG_NET_KEY_MIGRATE=y +CONFIG_NET_NS=y +CONFIG_NET_PTP_CLASSIFY=y +# CONFIG_NET_VENDOR_ARC is not set +# CONFIG_NET_VENDOR_AURORA is not set +# CONFIG_NET_VENDOR_BROADCOM is not set +# CONFIG_NET_VENDOR_CIRRUS is not set +# CONFIG_NET_VENDOR_FARADAY is not set +# CONFIG_NET_VENDOR_HISILICON is not set +# CONFIG_NET_VENDOR_INTEL is not set +# CONFIG_NET_VENDOR_MARVELL is not set +# CONFIG_NET_VENDOR_MICREL is not set +# CONFIG_NET_VENDOR_MICROCHIP is not set +# CONFIG_NET_VENDOR_NATSEMI is not set +# CONFIG_NET_VENDOR_QUALCOMM is not set +# CONFIG_NET_VENDOR_ROCKER is not set +# CONFIG_NET_VENDOR_SAMSUNG is not set +# CONFIG_NET_VENDOR_SEEQ is not set +# CONFIG_NET_VENDOR_SMSC is not set +# CONFIG_NET_VENDOR_VIA is not set +CONFIG_NFS_FS=y +CONFIG_NFS_USE_KERNEL_DNS=y +# CONFIG_NFS_USE_LEGACY_DNS is not set +CONFIG_NFS_V4=y +CONFIG_NFT_CHAIN_NAT_IPV4=m +CONFIG_NFT_CHAIN_ROUTE_IPV4=m +CONFIG_NFT_CHAIN_ROUTE_IPV6=m +# CONFIG_NFT_COMPAT is not set +CONFIG_NFT_COUNTER=m +CONFIG_NFT_CT=m +CONFIG_NFT_DUP_IPV4=m +CONFIG_NFT_DUP_IPV6=m +CONFIG_NFT_EXTHDR=m +CONFIG_NFT_HASH=m +CONFIG_NFT_LIMIT=m +CONFIG_NFT_LOG=m +CONFIG_NFT_MASQ=m +CONFIG_NFT_MASQ_IPV4=m +CONFIG_NFT_META=m +CONFIG_NFT_NAT=m +CONFIG_NFT_RBTREE=m +CONFIG_NFT_REDIR=m +CONFIG_NFT_REDIR_IPV4=m +CONFIG_NFT_REJECT=m +CONFIG_NFT_REJECT_INET=m +CONFIG_NFT_REJECT_IPV4=m +CONFIG_NFT_REJECT_IPV6=m +CONFIG_NF_CONNTRACK=m +CONFIG_NF_CONNTRACK_BROADCAST=m +CONFIG_NF_CONNTRACK_FTP=m +CONFIG_NF_CONNTRACK_IPV4=m +CONFIG_NF_CONNTRACK_IPV6=m +CONFIG_NF_CONNTRACK_IRC=m +CONFIG_NF_CONNTRACK_NETBIOS_NS=m +CONFIG_NF_CONNTRACK_SIP=m +CONFIG_NF_CT_NETLINK=m +CONFIG_NF_DEFRAG_IPV4=m +CONFIG_NF_DEFRAG_IPV6=m +CONFIG_NF_DUP_IPV4=m +CONFIG_NF_DUP_IPV6=m +CONFIG_NF_LOG_ARP=m +CONFIG_NF_LOG_COMMON=m +CONFIG_NF_LOG_IPV4=m +CONFIG_NF_LOG_IPV6=m +CONFIG_NF_NAT=m +CONFIG_NF_NAT_FTP=m +CONFIG_NF_NAT_IPV4=m +CONFIG_NF_NAT_IRC=m +CONFIG_NF_NAT_MASQUERADE_IPV4=m +CONFIG_NF_NAT_NEEDED=y +CONFIG_NF_NAT_REDIRECT=m +CONFIG_NF_NAT_SIP=m +CONFIG_NF_REJECT_IPV4=m +CONFIG_NF_REJECT_IPV6=m +CONFIG_NF_TABLES=m +CONFIG_NF_TABLES_ARP=m +# CONFIG_NF_TABLES_BRIDGE is not set +CONFIG_NF_TABLES_INET=m +CONFIG_NF_TABLES_IPV4=m +CONFIG_NF_TABLES_IPV6=m +CONFIG_NF_TABLES_NETDEV=m +CONFIG_NLS=y +CONFIG_NLS_CODEPAGE_437=y +CONFIG_NLS_ISO8859_1=y +CONFIG_NO_BOOTMEM=y +CONFIG_NR_CPUS=2 +CONFIG_NTFS_FS=y +CONFIG_NTFS_RW=y +CONFIG_OF=y +CONFIG_OF_ADDRESS=y +CONFIG_OF_DYNAMIC=y +CONFIG_OF_EARLY_FLATTREE=y +CONFIG_OF_FLATTREE=y +CONFIG_OF_GPIO=y +CONFIG_OF_IRQ=y +CONFIG_OF_MDIO=y +CONFIG_OF_MTD=y +CONFIG_OF_NET=y +CONFIG_OF_OVERLAY=y +CONFIG_OF_RESERVED_MEM=y +CONFIG_OF_RESOLVE=y +CONFIG_OID_REGISTRY=y +CONFIG_OLD_SIGACTION=y +CONFIG_OLD_SIGSUSPEND3=y +CONFIG_OPROFILE=y +CONFIG_OUTER_CACHE=y +CONFIG_OUTER_CACHE_SYNC=y +CONFIG_PAGE_OFFSET=0xC0000000 +# CONFIG_PCI is not set +# CONFIG_PCI_DOMAINS_GENERIC is not set +# CONFIG_PCI_SYSCALL is not set +CONFIG_PERF_EVENTS=y +CONFIG_PERF_USE_VMALLOC=y +CONFIG_PGTABLE_LEVELS=2 +CONFIG_PHYLIB=y +# CONFIG_PL310_ERRATA_588369 is not set +# CONFIG_PL310_ERRATA_727915 is not set +# CONFIG_PL310_ERRATA_753970 is not set +# CONFIG_PL310_ERRATA_769419 is not set +CONFIG_PM=y +CONFIG_PM_CLK=y +# CONFIG_PM_DEBUG is not set +CONFIG_PM_SLEEP=y +CONFIG_PM_SLEEP_SMP=y +CONFIG_PPS=y +CONFIG_PREEMPT=y +CONFIG_PREEMPT_COUNT=y +# CONFIG_PREEMPT_NONE is not set +CONFIG_PREEMPT_RCU=y +CONFIG_PRINTK_TIME=y +CONFIG_PROC_PID_CPUSET=y +CONFIG_PROFILING=y +CONFIG_PTP_1588_CLOCK=y +CONFIG_RATIONAL=y +# CONFIG_RCU_EXPERT is not set +CONFIG_RCU_STALL_COMMON=y +CONFIG_REGMAP=y +CONFIG_REGMAP_MMIO=y +CONFIG_REGULATOR=y +CONFIG_REGULATOR_FIXED_VOLTAGE=y +CONFIG_RESET_CONTROLLER=y +CONFIG_RFS_ACCEL=y +CONFIG_RING_BUFFER=y +CONFIG_RING_BUFFER_ALLOW_SWAP=y +CONFIG_ROOT_NFS=y +CONFIG_RPS=y +CONFIG_RWSEM_SPIN_ON_OWNER=y +CONFIG_RWSEM_XCHGADD_ALGORITHM=y +CONFIG_SCHED_HRTICK=y +# CONFIG_SCHED_INFO is not set +CONFIG_SCSI=y +# CONFIG_SCSI_LOWLEVEL is not set +# CONFIG_SCSI_PROC_FS is not set +CONFIG_SENSORS_LM75=y +CONFIG_SERIAL_8250_DW=y +CONFIG_SERIAL_8250_FSL=y +CONFIG_SERIAL_8250_NR_UARTS=16 +CONFIG_SERIAL_8250_RUNTIME_UARTS=16 +# CONFIG_SERIAL_AMBA_PL010 is not set +# CONFIG_SERIAL_AMBA_PL011 is not set +CONFIG_SERIAL_OF_PLATFORM=y +CONFIG_SERIO=y +CONFIG_SERIO_AMBAKMI=y +CONFIG_SMP=y +CONFIG_SMP_ON_UP=y +# CONFIG_SOCFPGA_SUSPEND is not set +CONFIG_SPARSE_IRQ=y +CONFIG_SPI=y +CONFIG_SPI_ALTERA=y +CONFIG_SPI_BITBANG=y +CONFIG_SPI_DESIGNWARE=y +CONFIG_SPI_DW_MMIO=y +CONFIG_SPI_MASTER=y +CONFIG_SRAM=y +CONFIG_SRCU=y +CONFIG_STMMAC_ETH=y +CONFIG_STMMAC_PLATFORM=y +CONFIG_SUNRPC=y +CONFIG_SUNRPC_GSS=y +CONFIG_SUSPEND=y +CONFIG_SUSPEND_FREEZER=y +CONFIG_SWIOTLB=y +CONFIG_SWP_EMULATE=y +CONFIG_SYS_SUPPORTS_APM_EMULATION=y +# CONFIG_THUMB2_KERNEL is not set +CONFIG_TICK_CPU_ACCOUNTING=y +CONFIG_TRACE_CLOCK=y +CONFIG_UBIFS_FS=y +CONFIG_UBIFS_FS_ADVANCED_COMPR=y +CONFIG_UBIFS_FS_LZO=y +CONFIG_UBIFS_FS_XZ=y +CONFIG_UBIFS_FS_ZLIB=y +CONFIG_UNCOMPRESS_INCLUDE="debug/uncompress.h" +CONFIG_UNINLINE_SPIN_UNLOCK=y +CONFIG_USB=m +CONFIG_USB_CDC_COMPOSITE=m +CONFIG_USB_COMMON=m +CONFIG_USB_DWC2=m +CONFIG_USB_DWC2_DUAL_ROLE=y +# CONFIG_USB_DWC2_TRACK_MISSED_SOFS is not set +# CONFIG_USB_EHCI_HCD is not set +# CONFIG_USB_ETH is not set +CONFIG_USB_FUNCTIONFS=m +# CONFIG_USB_FUNCTIONFS_ETH is not set +CONFIG_USB_FUNCTIONFS_GENERIC=y +# CONFIG_USB_FUNCTIONFS_RNDIS is not set +CONFIG_USB_F_ACM=m +CONFIG_USB_F_ECM=m +CONFIG_USB_F_FS=m +CONFIG_USB_F_MASS_STORAGE=m +CONFIG_USB_F_SS_LB=m +CONFIG_USB_GADGET=m +CONFIG_USB_LIBCOMPOSITE=m +CONFIG_USB_MASS_STORAGE=m +CONFIG_USB_OTG=y +CONFIG_USB_STORAGE=m +CONFIG_USB_SUPPORT=y +CONFIG_USB_U_ETHER=m +CONFIG_USB_U_SERIAL=m +CONFIG_USB_ZERO=m +# CONFIG_USB_ZERO_HNPTEST is not set +# CONFIG_USERIO is not set +# CONFIG_USER_NS is not set +CONFIG_USE_OF=y +CONFIG_VECTORS_BASE=0xffff0000 +CONFIG_VFAT_FS=y +CONFIG_VFP=y +CONFIG_VFPv3=y +CONFIG_VLAN_8021Q_GVRP=y +CONFIG_VT=y +CONFIG_VT_CONSOLE=y +CONFIG_VT_CONSOLE_SLEEP=y +CONFIG_VT_HW_CONSOLE_BINDING=y +# CONFIG_WQ_POWER_EFFICIENT_DEFAULT is not set +CONFIG_XFRM_ALGO=y +CONFIG_XFRM_MIGRATE=y +CONFIG_XPS=y +CONFIG_ZBOOT_ROM_BSS=0x0 +CONFIG_ZBOOT_ROM_TEXT=0x0 +CONFIG_ZLIB_DEFLATE=y +CONFIG_ZLIB_INFLATE=y +CONFIG_ZONE_DMA_FLAG=0 diff --git a/target/linux/socfpga/image/Config.in b/target/linux/socfpga/image/Config.in new file mode 100644 index 0000000..c6875e3 --- /dev/null +++ b/target/linux/socfpga/image/Config.in @@ -0,0 +1,5 @@ +config SOCFPGA_SD_BOOT_PARTSIZE + int "Boot (SD Card) filesystem partition size (in MB)" + depends on TARGET_socfpga + default 20 + diff --git a/target/linux/socfpga/image/Makefile b/target/linux/socfpga/image/Makefile new file mode 100644 index 0000000..7919ace --- /dev/null +++ b/target/linux/socfpga/image/Makefile @@ -0,0 +1,135 @@ +# +# Copyright (C) 2015 OpenWrt.org +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# +include $(TOPDIR)/rules.mk +include $(INCLUDE_DIR)/image.mk + +FAT32_BLOCK_SIZE=1024 +FAT32_BLOCKS=$(shell echo $$(($(CONFIG_SOCFPGA_SD_BOOT_PARTSIZE)*1024*1024/$(FAT32_BLOCK_SIZE)))) +KDIR_TMP:=$(KDIR)/tmp +KDIR_TMP_EXT4:=$(KDIR)/tmp-ext4 + +# Terasic SoCkit: QSPI NOR, N25Q00A +SOCFPGA_SOCKIT_UBIFS_OPTS="-m 1 -e 65408 -c 2040" +SOCFPGA_SOCKIT_UBI_OPTS="-m 1 -p 64KiB -s 1" + +define sanitize_profile_name +$(shell echo $(PROFILE) | tr '[:upper:]' '[:lower:]' | sed 's/_/-/g') +endef + +define Image/BuildKernel/Template + + ifneq ($(1),) + $(CP) $(DTS_DIR)/$(1).dtb $(BIN_DIR)/$(IMG_PREFIX)-$(1).dtb + + $(call Image/BuildKernel/MkFIT,$(1),$(KDIR)/zImage,$(BIN_DIR)/$(IMG_PREFIX)-$(1).dtb,none,0x00008000,0x00008000) + $(CP) $(KDIR)/fit-$(1).itb $(BIN_DIR)/$(IMG_PREFIX)-$(1)-fit-uImage.itb + + ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),) + $(call Image/BuildKernel/MkFIT,$(1),$(KDIR)/zImage-initramfs,$(BIN_DIR)/$(IMG_PREFIX)-$(1).dtb,none,0x00008000,0x00008000,-initramfs) + $(CP) $(KDIR)/fit-$(1)-initramfs.itb $(BIN_DIR)/$(IMG_PREFIX)-$(1)-fit-uImage-initramfs.itb + endif + endif + + $(CP) $(KDIR)/zImage $(BIN_DIR)/$(IMG_PREFIX)-zImage + $(call Image/BuildKernel/MkuImage, \ + none, 0x00008000, 0x00008000, \ + $(BIN_DIR)/$(IMG_PREFIX)-zImage, \ + $(BIN_DIR)/$(IMG_PREFIX)-uImage \ + ) + + ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),) + $(CP) $(KDIR)/zImage-initramfs $(BIN_DIR)/$(IMG_PREFIX)-zImage-initramfs + $(call Image/BuildKernel/MkuImage, \ + none, 0x00008000, 0x00008000, \ + $(BIN_DIR)/$(IMG_PREFIX)-zImage-initramfs, \ + $(BIN_DIR)/$(IMG_PREFIX)-uImage-initramfs \ + ) + endif +endef + +define Image/InstallKernel/Template + + ifneq ($(CONFIG_TARGET_ROOTFS_INCLUDE_KERNEL)$(CONFIG_TARGET_socfpga_SOCFPGA_SOCKIT),) + $(INSTALL_DIR) $(TARGET_DIR)/boot + ifneq ($(CONFIG_TARGET_ROOTFS_INCLUDE_UIMAGE)$(CONFIG_TARGET_socfpga_SOCFPGA_SOCKIT),) + $(CP) $(BIN_DIR)/$(IMG_PREFIX)-uImage $(TARGET_DIR)/boot/ + ln -sf $(IMG_PREFIX)-uImage $(TARGET_DIR)/boot/uImage + endif + ifneq ($(CONFIG_TARGET_ROOTFS_INCLUDE_ZIMAGE),) + $(CP) $(BIN_DIR)/$(IMG_PREFIX)-zImage $(TARGET_DIR)/boot/ + ln -sf $(IMG_PREFIX)-zImage $(TARGET_DIR)/boot/zImage + endif + ifneq ($(CONFIG_TARGET_ROOTFS_INCLUDE_FIT),) + $(foreach dts,$(shell echo $(1)), + $(CP) $(BIN_DIR)/$(IMG_PREFIX)-$(dts)-fit-uImage.itb $(TARGET_DIR)/boot/ + ) + endif + endif + + ifneq ($(CONFIG_TARGET_ROOTFS_INCLUDE_DTB)$(CONFIG_TARGET_socfpga_SOCFPGA_SOCKIT),) + $(INSTALL_DIR) $(TARGET_DIR)/boot + $(foreach dts,$(shell echo $(1)), + $(CP) $(BIN_DIR)/$(IMG_PREFIX)-$(dts).dtb $(TARGET_DIR)/boot/, + ln -sf $(IMG_PREFIX)-$(dts).dtb $(TARGET_DIR)/boot/$(dts).dtb + ) + endif +endef + +define Image/Build/SDCard + + ifeq ($(1),ext4) + ./gen_socfpga_sdcard_img.sh \ + $(BIN_DIR)/$(IMG_PREFIX)-$(call sanitize_profile_name)-sdcard-vfat-$(1).img \ + $(KDIR)/root.$(1) \ + $(CONFIG_TARGET_ROOTFS_PARTSIZE) \ + $(BIN_DIR)/uboot-socfpga-$(2)/$(IMG_PREFIX)-$(2)-u-boot-with-spl.sfp \ + $(KDIR)/cfg.img + endif +endef + +define Image/mkfs/targz + $(TAR) -czpf $(BIN_DIR)/$(IMG_PREFIX)-$(call sanitize_profile_name)-rootfs.tar.gz --numeric-owner --owner=0 --group=0 -C $(TARGET_DIR)/ . +endef + +Image/BuildKernel/Template/Generic=$(call Image/BuildKernel/Template) +Image/InstallKernel/Template/Generic=$(call Image/InstallKernel/Template) + +Image/BuildKernel/Template/SOCFPGA_SOCKIT=$(foreach dts,$(shell echo $(SOCFPGA_SOCKIT_DTS)),$(call Image/BuildKernel/Template,$(dts))) +Image/InstallKernel/Template/SOCFPGA_SOCKIT=$(call Image/InstallKernel/Template,$(SOCFPGA_SOCKIT_DTS)) + +define Image/BuildKernel + $(call Image/BuildKernel/Template/$(PROFILE)) +endef + +define Image/InstallKernel + $(call Image/InstallKernel/Template/$(PROFILE)) +endef + +define Image/Build/Profile/SOCFPGA_SOCKIT + + ifeq ($(1),ext4) + $(call Image/Build/SDCard,$(1),socfpga_cyclone5_sockit) + $(call Image/Build/SysupgradeNAND,$(call sanitize_profile_name),ext4,) + endif + ifeq ($(1),ubifs) + $(call Image/Build/SysupgradeNAND,$(call sanitize_profile_name),ubifs,) + endif +endef + +define Image/Build + $(if $(Image/Build/$(1)), \ + $(call Image/Build/$(1),$(1)), \ + $(CP) $(KDIR)/root.$(1) $(BIN_DIR)/$(IMG_PREFIX)-$(call sanitize_profile_name)-$(1).img \ + ) + + $(if $(Image/Build/Profile/$(PROFILE)), \ + $(call Image/Build/Profile/$(PROFILE),$(1)), \ + $(CP) $(KDIR)/root.$(1) $(BIN_DIR)/$(IMG_PREFIX)-$(call sanitize_profile_name)-$(1).img \ + ) +endef + +$(eval $(call BuildImage)) diff --git a/target/linux/socfpga/image/gen_socfpga_sdcard_img.sh b/target/linux/socfpga/image/gen_socfpga_sdcard_img.sh new file mode 100755 index 0000000..420e4b6 --- /dev/null +++ b/target/linux/socfpga/image/gen_socfpga_sdcard_img.sh @@ -0,0 +1,41 @@ +#!/usr/bin/env bash + +# +# Copyright (C) 2015 OpenWrt.org +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# + +set -x +[ $# -eq 5 ] || { + echo "SYNTAX: $0 " + exit 1 +} + +OUTPUT="$1" +ROOTFS="$2" +ROOTFSSIZE="$3" +UBOOT="$4" +CFGFS="$5" + +head=4 +sect=63 + +set `ptgen -o $OUTPUT -h $head -s $sect -l 1024 \ + -t a2 -p 1M \ + -t 83 -p ${ROOTFSSIZE}M \ + -t 83 -p 1M` + +UBOOTOFFSET="$(($1 / 512))" +UBOOTSIZE="$(($2 / 512))" +ROOTFSOFFSET="$(($3 / 512))" +ROOTFSSIZE="$(($4 / 512))" +CFGFSOFFSET="$(($5 / 512))" +CFGFSSIZE="$(($6 / 512))" + +dd bs=512 if="$UBOOT" of="$OUTPUT" seek="$UBOOTOFFSET" conv=notrunc +dd bs=512 if="$ROOTFS" of="$OUTPUT" seek="$ROOTFSOFFSET" conv=notrunc + +mkdosfs "$CFGFS" -C 1024 +dd bs=512 if="$CFGFS" of="$OUTPUT" seek="$CFGFSOFFSET" conv=notrunc diff --git a/target/linux/socfpga/image/ubinize.cfg b/target/linux/socfpga/image/ubinize.cfg new file mode 100644 index 0000000..e4149ec --- /dev/null +++ b/target/linux/socfpga/image/ubinize.cfg @@ -0,0 +1,13 @@ +[rootfs] +# Volume mode (other option is static) +mode=ubi +# Source image +image=root.ubifs +# Volume ID in UBI image +vol_id=0 +# Allow for dynamic resize +vol_type=dynamic +# Volume name +vol_name=rootfs +# Autoresize volume at first mount +vol_flags=autoresize diff --git a/target/linux/socfpga/patches-4.4/0001-dt-bindings-gpio-altera-Fix-altr-interrupt-type-prop.patch b/target/linux/socfpga/patches-4.4/0001-dt-bindings-gpio-altera-Fix-altr-interrupt-type-prop.patch new file mode 100644 index 0000000..b89793a --- /dev/null +++ b/target/linux/socfpga/patches-4.4/0001-dt-bindings-gpio-altera-Fix-altr-interrupt-type-prop.patch @@ -0,0 +1,45 @@ +From b32732e51a774e8514f40975f2600f02ef9db0b4 Mon Sep 17 00:00:00 2001 +From: Marek Vasut +Date: Mon, 29 Feb 2016 17:19:59 +0100 +Subject: [PATCH 1/5] dt-bindings: gpio: altera: Fix altr,interrupt-type + property + +The altr,interrupt-trigger property is not used by the driver. +Instead, altr,interrupt-type is used by the driver and the driver +does not probe if this property is not specified. Therefore, it +is expected that there are no users of the -trigger property in +the wild and that this is a typo in the documentation for the +altera-pio controller. This patch fixes the typo. + +Signed-off-by: Marek Vasut +Cc: Tien Hock Loh +Cc: Linus Walleij +--- + Documentation/devicetree/bindings/gpio/gpio-altera.txt | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/Documentation/devicetree/bindings/gpio/gpio-altera.txt b/Documentation/devicetree/bindings/gpio/gpio-altera.txt +index 12f5014..826a720 100644 +--- a/Documentation/devicetree/bindings/gpio/gpio-altera.txt ++++ b/Documentation/devicetree/bindings/gpio/gpio-altera.txt +@@ -12,7 +12,7 @@ Required properties: + - #interrupt-cells : Should be 1. The interrupt type is fixed in the hardware. + - The first cell is the GPIO offset number within the GPIO controller. + - interrupts: Specify the interrupt. +-- altr,interrupt-trigger: Specifies the interrupt trigger type the GPIO ++- altr,interrupt-type: Specifies the interrupt trigger type the GPIO + hardware is synthesized. This field is required if the Altera GPIO controller + used has IRQ enabled as the interrupt type is not software controlled, + but hardware synthesized. Required if GPIO is used as an interrupt +@@ -35,7 +35,7 @@ gpio_altr: gpio at 0xff200000 { + reg = <0xff200000 0x10>; + interrupts = <0 45 4>; + altr,ngpio = <32>; +- altr,interrupt-trigger = ; ++ altr,interrupt-type = ; + #gpio-cells = <2>; + gpio-controller; + #interrupt-cells = <1>; +-- +2.7.0 + diff --git a/target/linux/socfpga/patches-4.4/0002-usb-dwc2-gadget-Repair-DSTS-register-decoding.patch b/target/linux/socfpga/patches-4.4/0002-usb-dwc2-gadget-Repair-DSTS-register-decoding.patch new file mode 100644 index 0000000..9be3834 --- /dev/null +++ b/target/linux/socfpga/patches-4.4/0002-usb-dwc2-gadget-Repair-DSTS-register-decoding.patch @@ -0,0 +1,36 @@ +From e5cbd23e4f40181c907a1abc136b17de8cb86809 Mon Sep 17 00:00:00 2001 +From: Marek Vasut +Date: Thu, 17 Dec 2015 23:42:35 +0100 +Subject: [PATCH 2/5] usb: dwc2: gadget: Repair DSTS register decoding + +The "enumspd" field is located in register DSTS[2:1], but the code +which checks the bitfield does not shift the value accordingly. This +in turn causes incorrect detection of gadget link partner speed in +dwc2_hsotg_irq_enumdone() . + +Shift the value accordingly to fix the problem with speed detection. + +Signed-off-by: Marek Vasut +Cc: Felipe Balbi +Cc: Greg Kroah-Hartman +Cc: John Youn +--- + drivers/usb/dwc2/gadget.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c +index 0abf73c..48e47c1 100644 +--- a/drivers/usb/dwc2/gadget.c ++++ b/drivers/usb/dwc2/gadget.c +@@ -2095,7 +2095,7 @@ static void dwc2_hsotg_irq_enumdone(struct dwc2_hsotg *hsotg) + */ + + /* catch both EnumSpd_FS and EnumSpd_FS48 */ +- switch (dsts & DSTS_ENUMSPD_MASK) { ++ switch ((dsts & DSTS_ENUMSPD_MASK) >> DSTS_ENUMSPD_SHIFT) { + case DSTS_ENUMSPD_FS: + case DSTS_ENUMSPD_FS48: + hsotg->gadget.speed = USB_SPEED_FULL; +-- +2.7.0 + diff --git a/target/linux/socfpga/patches-4.4/0003-ARM-socfpga-dts-Enable-MMC-support-at-correct-place-.patch b/target/linux/socfpga/patches-4.4/0003-ARM-socfpga-dts-Enable-MMC-support-at-correct-place-.patch new file mode 100644 index 0000000..b12de6d --- /dev/null +++ b/target/linux/socfpga/patches-4.4/0003-ARM-socfpga-dts-Enable-MMC-support-at-correct-place-.patch @@ -0,0 +1,90 @@ +From 6b8c64eb90e5d958f32524ff2d0571b3b6ac92df Mon Sep 17 00:00:00 2001 +From: Marek Vasut +Date: Mon, 21 Dec 2015 00:42:01 -0600 +Subject: [PATCH 3/5] ARM: socfpga: dts: Enable MMC support at correct place in + the DT + +The socfpga.dtsi explicitly enabled MMC support, but not all boards are +equiped with an MMC card. There are setups which only have QSPI NOR. +Therefore, disable the MMC support on socfpga.dtsi level and enable it +on per-board basis. + +Signed-off-by: Marek Vasut +Cc: Alan Tull +Cc: Dinh Nguyen +Cc: Marek Vasut +Cc: Olof Johansson +Cc: Thor Thayer +Cc: Vince Bridgers +Signed-off-by: Dinh Nguyen +--- + arch/arm/boot/dts/socfpga.dtsi | 1 + + arch/arm/boot/dts/socfpga_arria5_socdk.dts | 1 + + arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts | 1 + + arch/arm/boot/dts/socfpga_cyclone5_socdk.dts | 1 + + arch/arm/boot/dts/socfpga_cyclone5_sockit.dts | 1 + + 5 files changed, 5 insertions(+) + +diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi +index 39c470e..3ed4abd 100644 +--- a/arch/arm/boot/dts/socfpga.dtsi ++++ b/arch/arm/boot/dts/socfpga.dtsi +@@ -677,6 +677,7 @@ + #size-cells = <0>; + clocks = <&l4_mp_clk>, <&sdmmc_clk_divided>; + clock-names = "biu", "ciu"; ++ status = "disabled"; + }; + + ocram: sram at ffff0000 { +diff --git a/arch/arm/boot/dts/socfpga_arria5_socdk.dts b/arch/arm/boot/dts/socfpga_arria5_socdk.dts +index a75a666..3c88678 100644 +--- a/arch/arm/boot/dts/socfpga_arria5_socdk.dts ++++ b/arch/arm/boot/dts/socfpga_arria5_socdk.dts +@@ -79,6 +79,7 @@ + &mmc0 { + vmmc-supply = <®ulator_3_3v>; + vqmmc-supply = <®ulator_3_3v>; ++ status = "okay"; + }; + + &usb1 { +diff --git a/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts b/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts +index 555e9ca..afea364 100644 +--- a/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts ++++ b/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts +@@ -100,6 +100,7 @@ + &mmc0 { + vmmc-supply = <®ulator_3_3v>; + vqmmc-supply = <®ulator_3_3v>; ++ status = "okay"; + }; + + &uart0 { +diff --git a/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts b/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts +index d4d0a28..15e43f4 100644 +--- a/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts ++++ b/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts +@@ -84,6 +84,7 @@ + cd-gpios = <&portb 18 0>; + vmmc-supply = <®ulator_3_3v>; + vqmmc-supply = <®ulator_3_3v>; ++ status = "okay"; + }; + + &usb1 { +diff --git a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts +index 48bf651..b61f22f 100644 +--- a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts ++++ b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts +@@ -80,6 +80,7 @@ + &mmc0 { + vmmc-supply = <®ulator_3_3v>; + vqmmc-supply = <®ulator_3_3v>; ++ status = "okay"; + }; + + &usb1 { +-- +2.7.0 + diff --git a/target/linux/socfpga/patches-4.4/0004-ARM-socfpga-Add-support-for-HPS-LEDs-on-SoCKit.patch b/target/linux/socfpga/patches-4.4/0004-ARM-socfpga-Add-support-for-HPS-LEDs-on-SoCKit.patch new file mode 100644 index 0000000..954f03e --- /dev/null +++ b/target/linux/socfpga/patches-4.4/0004-ARM-socfpga-Add-support-for-HPS-LEDs-on-SoCKit.patch @@ -0,0 +1,66 @@ +From e56e545745dc42cba743dab549d0afb1a39d14b4 Mon Sep 17 00:00:00 2001 +From: Marek Vasut +Date: Mon, 22 Jun 2015 23:37:47 +0200 +Subject: [PATCH 4/5] ARM: socfpga: Add support for HPS LEDs on SoCKit + +Add support for the blue LEDs on the SoCFPGA SoCkit board. + +Signed-off-by: Marek Vasut +Cc: Dinh Nguyen +--- + arch/arm/boot/dts/socfpga_cyclone5_sockit.dts | 32 +++++++++++++++++++++++++++ + 1 file changed, 32 insertions(+) + +diff --git a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts +index b61f22f..1461690 100644 +--- a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts ++++ b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts +@@ -39,6 +39,34 @@ + ethernet0 = &gmac1; + }; + ++ leds { ++ compatible = "gpio-leds"; ++ ++ hps_led0 { ++ label = "hps:blue:led0"; ++ gpios = <&portb 24 0>; /* HPS_GPIO53 */ ++ linux,default-trigger = "heartbeat"; ++ }; ++ ++ hps_led1 { ++ label = "hps:blue:led1"; ++ gpios = <&portb 25 0>; /* HPS_GPIO54 */ ++ linux,default-trigger = "heartbeat"; ++ }; ++ ++ hps_led2 { ++ label = "hps:blue:led2"; ++ gpios = <&portb 26 0>; /* HPS_GPIO55 */ ++ linux,default-trigger = "heartbeat"; ++ }; ++ ++ hps_led3 { ++ label = "hps:blue:led3"; ++ gpios = <&portb 27 0>; /* HPS_GPIO56 */ ++ linux,default-trigger = "heartbeat"; ++ }; ++ }; ++ + regulator_3_3v: vcc3p3-regulator { + compatible = "regulator-fixed"; + regulator-name = "VCC3P3"; +@@ -61,6 +89,10 @@ + rxc-skew-ps = <2000>; + }; + ++&gpio1 { /* GPIO 30..57 */ ++ status = "okay"; ++}; ++ + &gpio2 { + status = "okay"; + }; +-- +2.7.0 + diff --git a/target/linux/socfpga/patches-4.4/0005-ARM-socfpga-Add-support-for-HPS-KEYs-SWs-on-SoCKit.patch b/target/linux/socfpga/patches-4.4/0005-ARM-socfpga-Add-support-for-HPS-KEYs-SWs-on-SoCKit.patch new file mode 100644 index 0000000..a5e53f5 --- /dev/null +++ b/target/linux/socfpga/patches-4.4/0005-ARM-socfpga-Add-support-for-HPS-KEYs-SWs-on-SoCKit.patch @@ -0,0 +1,100 @@ +From a953c0800246e99c9b449bd9ec0b26682a82700c Mon Sep 17 00:00:00 2001 +From: Marek Vasut +Date: Tue, 23 Jun 2015 00:41:08 +0200 +Subject: [PATCH 5/5] ARM: socfpga: Add support for HPS KEYs/SWs on SoCKit + +Add support for the keys and flip-switches on the SoCFPGA SoCkit board. + +Signed-off-by: Marek Vasut +Cc: Dinh Nguyen +--- + arch/arm/boot/dts/socfpga_cyclone5_sockit.dts | 62 ++++++++++++++++++++++++++- + 1 file changed, 61 insertions(+), 1 deletion(-) + +diff --git a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts +index 1461690..02e22f5 100644 +--- a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts ++++ b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts +@@ -67,6 +67,62 @@ + }; + }; + ++ gpio-keys { ++ compatible = "gpio-keys"; ++ ++ hps_sw0 { ++ label = "hps_sw0"; ++ gpios = <&portc 20 0>; /* HPS_GPI7 */ ++ linux,input-type = <5>; /* EV_SW */ ++ linux,code = <0x0>; /* SW_LID */ ++ }; ++ ++ hps_sw1 { ++ label = "hps_sw1"; ++ gpios = <&portc 19 0>; /* HPS_GPI6 */ ++ linux,input-type = <5>; /* EV_SW */ ++ linux,code = <0x5>; /* SW_DOCK */ ++ }; ++ ++ hps_sw2 { ++ label = "hps_sw2"; ++ gpios = <&portc 18 0>; /* HPS_GPI5 */ ++ linux,input-type = <5>; /* EV_SW */ ++ linux,code = <0xa>; /* SW_KEYPAD_SLIDE */ ++ }; ++ ++ hps_sw3 { ++ label = "hps_sw3"; ++ gpios = <&portc 17 0>; /* HPS_GPI4 */ ++ linux,input-type = <5>; /* EV_SW */ ++ linux,code = <0xc>; /* SW_ROTATE_LOCK */ ++ }; ++ ++ hps_hkey0 { ++ label = "hps_hkey0"; ++ gpios = <&portc 21 1>; /* HPS_GPI8 */ ++ linux,code = <187>; /* KEY_F17 */ ++ }; ++ ++ hps_hkey1 { ++ label = "hps_hkey1"; ++ gpios = <&portc 22 1>; /* HPS_GPI9 */ ++ linux,code = <188>; /* KEY_F18 */ ++ }; ++ ++ hps_hkey2 { ++ label = "hps_hkey2"; ++ gpios = <&portc 23 1>; /* HPS_GPI10 */ ++ linux,code = <189>; /* KEY_F19 */ ++ }; ++ ++ hps_hkey3 { ++ label = "hps_hkey3"; ++ gpios = <&portc 24 1>; /* HPS_GPI11 */ ++ linux,code = <190>; /* KEY_F20 */ ++ }; ++ }; ++ + regulator_3_3v: vcc3p3-regulator { + compatible = "regulator-fixed"; + regulator-name = "VCC3P3"; +@@ -89,11 +145,15 @@ + rxc-skew-ps = <2000>; + }; + ++&gpio0 { /* GPIO 0..29 */ ++ status = "okay"; ++}; ++ + &gpio1 { /* GPIO 30..57 */ + status = "okay"; + }; + +-&gpio2 { ++&gpio2 { /* GPIO 58..66 (HLGPI 0..13 at offset 13) */ + status = "okay"; + }; + +-- +2.7.0 + diff --git a/target/linux/socfpga/profiles/100-generic.mk b/target/linux/socfpga/profiles/100-generic.mk new file mode 100644 index 0000000..9a238f2 --- /dev/null +++ b/target/linux/socfpga/profiles/100-generic.mk @@ -0,0 +1,17 @@ +# +# Copyright (C) 2015 OpenWrt.org +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# + +define Profile/Generic + NAME:=Generic (default) + PACKAGES:= +endef + +define Profile/Generic/Description + Package set compatible with most Altera SoCFPGA based boards. +endef + +$(eval $(call Profile,Generic)) diff --git a/target/linux/socfpga/profiles/110-socfpga_sockit.mk b/target/linux/socfpga/profiles/110-socfpga_sockit.mk new file mode 100644 index 0000000..73eb295 --- /dev/null +++ b/target/linux/socfpga/profiles/110-socfpga_sockit.mk @@ -0,0 +1,28 @@ +# +# Copyright (C) 2015 OpenWrt.org +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# + +define Profile/SOCFPGA_SOCKIT + NAME:=Terasic SoCKit + PACKAGES:=uboot-socfpga-socfpga_cyclone5_sockit + DEPENDS:=+ at TARGET_ROOTFS_INCLUDE_KERNEL + at TARGET_ROOTFS_INCLUDE_DTB +endef + +define Profile/SOCFPGA_SOCKIT/Description + The Terasic SoCKit is based on the Altera Cyclone V SoC + and offers a large variety of peripherals such as: + + * DDR3 + * NAND or SPI flash + * USB EHCI + * USB OTG + * User GPIO +endef + +SOCFPGA_SOCKIT_DTS := \ + socfpga_cyclone5_sockit + +$(eval $(call Profile,SOCFPGA_SOCKIT)) -- 2.7.0 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From psidhu at gateworks.com Mon May 2 19:05:28 2016 From: psidhu at gateworks.com (Pushpal Sidhu) Date: Mon, 2 May 2016 16:05:28 -0700 Subject: [OpenWrt-Devel] [PATCH] image.mk: Create a manifest file of installed packages as a build artifact Message-ID: <1462230328-16024-1-git-send-email-psidhu@gateworks.com> A few linux BSP's create a manifest file of installed packages for a given target in order to help them understand exactly what's on their images. Create one for OpenWrt as well as a build artifact since many users have an affinity to prune down on packages to save valuable flash space. Signed-off-by: Pushpal Sidhu --- include/image.mk | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/include/image.mk b/include/image.mk index bc383e6..c3c6f5a 100644 --- a/include/image.mk +++ b/include/image.mk @@ -280,6 +280,13 @@ define Image/mkfs/prepare $(call Image/mkfs/prepare/default) endef +define Image/Manifest + $(STAGING_DIR_HOST)/bin/opkg \ + --offline-root $(TARGET_DIR) \ + --add-arch all:100 \ + --add-arch $(if $(ARCH_PACKAGES),$(ARCH_PACKAGES),$(BOARD)):200 list-installed > \ + $(BIN_DIR)/$(IMG_PREFIX)$(if $(PROFILE_SANITIZED),-$(PROFILE_SANITIZED)).manifest +endef define Image/Checksum ( cd ${BIN_DIR} ; \ @@ -597,6 +604,7 @@ define BuildImage $(call Image/Build,$(fs)) ) $(call Image/mkfs/ubifs) + $(call Image/Manifest) $(call Image/Checksum,md5sum --binary,md5sums) $(call Image/Checksum,openssl dgst -sha256,sha256sums) -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From lazar at onion.io Mon May 2 19:52:59 2016 From: lazar at onion.io (Lazar Demin) Date: Mon, 2 May 2016 19:52:59 -0400 Subject: [OpenWrt-Devel] mt76 wifi module on mt7688 board, no interface In-Reply-To: References: <570FB001.8030507@phrozen.org> <1461265121.8314.4.camel@noblepepper.com> Message-ID: Marc, Can you expand on what you did to get the AP to work? I'm completely stumped... Any luck on the STA? Thanks On Thu, Apr 21, 2016 at 3:00 PM, Marc Nicholas wrote: > Is the firmware getting loaded (/lib/firmware/mt7628_e2.bin)? It looks > like the fix in 48958 for this is in github.com/openwrt-mirror/ but not > in github.com/openwrt/. > > Yes, the firmware is getting loaded based on the boot logs. > > I?ve gotten a bit further and have AP mode running. But can?t for the life > of me get STA to work?.can?t even scan for APs. :-/ > > Thanks! > > -m > -- > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From reinoudkoornstra at gmail.com Mon May 2 20:45:13 2016 From: reinoudkoornstra at gmail.com (Reinoud Koornstra) Date: Mon, 2 May 2016 18:45:13 -0600 Subject: [OpenWrt-Devel] Comfast board Message-ID: Hi Everyone, I want to buld openwrt for this cpu: CPU0 revision is: 00019750 (MIPS 74Kc). Clocks: CPU:720.000MHz, DDR:600.000MHz, AHB:200.000MHz, Ref:40.000MHz Currently I cannot find the correct options for this. The board that is reported is this: board=COMFAST-CF-WR650AC It carries this chipset: SoC: Qualcomm Atheros QCA9558 ver 1 rev 0 It reports this switch: [ 0.830000] switch0: Atheros AR8337 rev. 2 switch registered on ag71xx-mdio.0 [ 0.920000] libphy: ag71xx_mdio: probed [ 1.520000] ag71xx ag71xx.0: connected to PHY at ag71xx-mdio.0:00 [uid=004dd036, driver=Atheros AR8216/AR8236/AR8316] [ 1.530000] eth0: Atheros AG71xx at 0xb9000000, irq 4, mode:RGMII [ 2.120000] eth1: Atheros AG71xx at 0xba000000, irq 5, mode:SGMII Any hints as to what to chose to make this happen? Thanks, Reinoud. _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From kathy.giori at gmail.com Tue May 3 00:39:48 2016 From: kathy.giori at gmail.com (Kathy Giori) Date: Mon, 2 May 2016 21:39:48 -0700 Subject: [OpenWrt-Devel] OpenWrt enhancement ideas -- opportunity for prpl funding -- deadline May 18 Message-ID: To the community of OpenWrt developers: The deadline for submitting an idea to enhance OpenWrt, and to receive funding assistance to do the work, is a short two weeks away. Since we have been discussing the idea of such a program for several weeks, we hope you have been thinking about a good idea you'd like to propose. Now is your chance. :) If interested, follow this link for submission details. http://wiki.prplfoundation.org/wiki/OpenWrt_Funding If you have any questions or concerns, feel free to contact me directly by replying to this e-mail. kathy _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From greearb at candelatech.com Tue May 3 12:21:50 2016 From: greearb at candelatech.com (Ben Greear) Date: Tue, 3 May 2016 09:21:50 -0700 Subject: [OpenWrt-Devel] OpenWrt enhancement ideas -- opportunity for prpl funding -- deadline May 18 In-Reply-To: References: Message-ID: <5728D01E.6020800@candelatech.com> On 05/02/2016 09:39 PM, Kathy Giori wrote: > To the community of OpenWrt developers: > > The deadline for submitting an idea to enhance OpenWrt, and to receive > funding assistance to do the work, is a short two weeks away. Since we > have been discussing the idea of such a program for several weeks, we > hope you have been thinking about a good idea you'd like to propose. > Now is your chance. :) > > If interested, follow this link for submission details. > http://wiki.prplfoundation.org/wiki/OpenWrt_Funding Is there any general interest in adding support for my CT ath10k firmware? My basic proposal would be something like: * Port at least most of my ath10k related patches to whatever is the latest openwrt kernel. * In particular, the patches I have to enable loading different firmware images and different firmware options on a per NIC basis. * Package my firmware image(s) so they can be easily installed in openwrt. * Configuration can be done manually and/or someone else could write the needed front-end if they cared. I don't know a great deal about the specifics of openwrt, so I could use some help with making this easy to configure. * This is probably 1-2 weeks worth of effort, and we would work cheap, especially if we could get a bit of assistance here and there. Thanks, Ben > > If you have any questions or concerns, feel free to contact me > directly by replying to this e-mail. > kathy > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > -- Ben Greear Candela Technologies Inc http://www.candelatech.com _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From jow at openwrt.org Tue May 3 13:59:55 2016 From: jow at openwrt.org (Jo-Philipp Wich) Date: Tue, 3 May 2016 18:59:55 +0100 Subject: [OpenWrt-Devel] Introducing the LEDE project Message-ID: <5179f6d1-283a-1b40-d717-2730c3408326@openwrt.org> Hi, we'd like to introduce LEDE, a reboot of the OpenWrt community . The project is founded as a spin-off of the OpenWrt project and shares many of the same goals. We are building an embedded Linux distribution that makes it easy for developers, system administrators or other Linux enthusiasts to build and customize software for embedded devices, especially wireless routers. The name 'LEDE' stands for 'Linux Embedded Development Environment'. Members of the project already include a significant share of the most active members of the OpenWrt community. We intend to bring new life to Embedded Linux development by creating a community with a strong focus on transparency, collaboration and decentralisation. LEDE?s stated goals are: - Building a great embedded Linux distribution with focus on stability and functionality. - Having regular, predictable release cycles coupled with community provided device testing feedback. - Establishing transparent decision processes with broad community participation and public meetings. We decided to create this new project because of long standing issues that we were unable to fix from within the OpenWrt project/community: 1. Number of active core developers at an all time low, no process for getting more new people involved. 2. Unreliable infrastructure, fixes prevented by internal disagreements and single points of failure. 3. Lack of communication, transparency and coordination in the OpenWrt project, both inside the core team and between the core team and the rest of the community. 4. Not enough people with commit access to handle the incoming flow of patches, too little attention to testing and regular builds. 5. Lack of focus on stability and documentation. To address these issues we set up the LEDE project in a different way compared to OpenWrt: 1. All our communication channels are public, some read-only to non-members to maintain a good signal-to-noise ratio. 2. Our decision making process is more open, with an approximate 50/50 mix of developers and power users with voting rights. 3. Our infrastructure is simplified a lot, to ensure that it creates less maintenance work for us. 4. We have made our merge policy more liberal, based on our experience with the OpenWrt package github feed. 5. We have a strong focus on automated testing combined with a simplified release process If you're interested in participating or want to learn more about the project, check out https://www.lede-project.org/. Sincerely, Jo-Philipp Wich, John Crispin, Daniel Golle, Felix Fietkau, Hauke Mehrtens John Crispin Matthias Schiffer, Steven Barth _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From j.lancett at ntlworld.com Tue May 3 14:02:24 2016 From: j.lancett at ntlworld.com (tapper) Date: Tue, 3 May 2016 19:02:24 +0100 Subject: [OpenWrt-Devel] OpenWrt enhancement ideas -- opportunity for prpl funding -- deadline May 18 In-Reply-To: <5728D01E.6020800@candelatech.com> References: <5728D01E.6020800@candelatech.com> Message-ID: OpenWRT Gets Forked By Some Of Its Own Developers As LEDE Project http://www.phoronix.com/scan.php?page=news_item&px=OpenWRT-Forked-As-LEDE On 03/05/2016 17:21, Ben Greear wrote: > On 05/02/2016 09:39 PM, Kathy Giori wrote: >> To the community of OpenWrt developers: >> >> The deadline for submitting an idea to enhance OpenWrt, and to receive >> funding assistance to do the work, is a short two weeks away. Since we >> have been discussing the idea of such a program for several weeks, we >> hope you have been thinking about a good idea you'd like to propose. >> Now is your chance. :) >> >> If interested, follow this link for submission details. >> http://wiki.prplfoundation.org/wiki/OpenWrt_Funding > > Is there any general interest in adding support for my CT > ath10k firmware? My basic proposal would be something like: > > * Port at least most of my ath10k related patches to whatever is > the latest openwrt kernel. > > * In particular, the patches I have to enable loading different firmware > images and different firmware options on a per NIC basis. > > * Package my firmware image(s) so they can be easily installed in openwrt. > > * Configuration can be done manually and/or someone else could write the > needed front-end if they cared. I don't know a great deal about the > specifics > of openwrt, so I could use some help with making this easy to configure. > > * This is probably 1-2 weeks worth of effort, and we would work cheap, > especially if we could get a bit of assistance here and there. > > Thanks, > Ben > >> >> If you have any questions or concerns, feel free to contact me >> directly by replying to this e-mail. >> kathy >> _______________________________________________ >> openwrt-devel mailing list >> openwrt-devel at lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >> > > _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From devel-sven at geroedel.de Tue May 3 15:53:32 2016 From: devel-sven at geroedel.de (Sven Roederer) Date: Tue, 3 May 2016 21:53:32 +0200 Subject: [OpenWrt-Devel] [PATCH] ramips: mt7620 - add image-profile for Nexx-routers Message-ID: <1462305212-4118-1-git-send-email-devel-sven@geroedel.de> - this covers the WT3020-routers - so this target can be even used in Imagebuilder Signed-off-by: Sven Roederer --- target/linux/ramips/mt7620/profiles/nexx.mk | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 target/linux/ramips/mt7620/profiles/nexx.mk diff --git a/target/linux/ramips/mt7620/profiles/nexx.mk b/target/linux/ramips/mt7620/profiles/nexx.mk new file mode 100644 index 0000000..9c668c5 --- /dev/null +++ b/target/linux/ramips/mt7620/profiles/nexx.mk @@ -0,0 +1,17 @@ +# +# Copyright (C) 2016 OpenWrt.org +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# + +define Profile/WT3020 + NAME:=Nexx WT3020 + PACKAGES:=kmod-usb-core kmod-usb2 kmod-usb-ohci -kmod-ledtrig-usbdev \ + kmod-mt76 +endef + +define Profile/WT3020/Description + Support for Nexx WT3020-series +endef +$(eval $(call Profile,WT3020)) -- 2.1.4 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From br1 at einfach.org Tue May 3 16:19:28 2016 From: br1 at einfach.org (Bruno Randolf) Date: Tue, 3 May 2016 21:19:28 +0100 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <5179f6d1-283a-1b40-d717-2730c3408326@openwrt.org> References: <5179f6d1-283a-1b40-d717-2730c3408326@openwrt.org> Message-ID: <572907D0.8080700@einfach.org> On 03/05/16 18:59, Jo-Philipp Wich wrote: > we'd like to introduce LEDE, a reboot of the OpenWrt community > ... > Jo-Philipp Wich, > John Crispin, > Daniel Golle, > Felix Fietkau, > Hauke Mehrtens > John Crispin > Matthias Schiffer, > Steven Barth While a fresh start and a more open process is good move, given this list of supporters it sounds a bit ridiculous... who is left in the OpenWRT boat and why not do it as OpenWRT (V2 or whatever)??? Anyhow I am excited to see some important problems in the OpenWRT community being addressed! Regards, bruno _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From pepe2k at gmail.com Tue May 3 16:37:35 2016 From: pepe2k at gmail.com (Piotr Dymacz) Date: Tue, 3 May 2016 22:37:35 +0200 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <572907D0.8080700@einfach.org> References: <5179f6d1-283a-1b40-d717-2730c3408326@openwrt.org> <572907D0.8080700@einfach.org> Message-ID: Hello, 2016-05-03 22:19 GMT+02:00 Bruno Randolf : > On 03/05/16 18:59, Jo-Philipp Wich wrote: >> we'd like to introduce LEDE, a reboot of the OpenWrt community >> ... >> Jo-Philipp Wich, >> John Crispin, >> Daniel Golle, >> Felix Fietkau, >> Hauke Mehrtens >> John Crispin >> Matthias Schiffer, >> Steven Barth > > While a fresh start and a more open process is good move, given this > list of supporters it sounds a bit ridiculous... who is left in the > OpenWRT boat and why not do it as OpenWRT (V2 or whatever)??? > [...] Same question here. Plus, does it still make sense to send patches here? Cheers, Piotr _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From leroi.lists at gmail.com Tue May 3 18:50:57 2016 From: leroi.lists at gmail.com (Roman Yeryomin) Date: Wed, 4 May 2016 01:50:57 +0300 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <572907D0.8080700@einfach.org> References: <5179f6d1-283a-1b40-d717-2730c3408326@openwrt.org> <572907D0.8080700@einfach.org> Message-ID: On 3 May 2016 at 23:19, Bruno Randolf wrote: > On 03/05/16 18:59, Jo-Philipp Wich wrote: >> we'd like to introduce LEDE, a reboot of the OpenWrt community >> ... >> Jo-Philipp Wich, >> John Crispin, >> Daniel Golle, >> Felix Fietkau, >> Hauke Mehrtens >> John Crispin >> Matthias Schiffer, >> Steven Barth > > While a fresh start and a more open process is good move, given this > list of supporters it sounds a bit ridiculous... who is left in the > OpenWRT boat and why not do it as OpenWRT (V2 or whatever)??? Indeed. Looks like silent rebranding. Without public discussion of the issues (and possible ways to fix them) in mailing list Same people, rules and methods. Could you elaborate more and explain how exactly LEDE is going to fix the listed problems? And why it's not possible to fix them inside existing project? Regards, Roman _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From outbackdingo at gmail.com Tue May 3 21:54:33 2016 From: outbackdingo at gmail.com (Outback Dingo) Date: Wed, 4 May 2016 03:54:33 +0200 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: References: <5179f6d1-283a-1b40-d717-2730c3408326@openwrt.org> <572907D0.8080700@einfach.org> Message-ID: On Wed, May 4, 2016 at 12:50 AM, Roman Yeryomin wrote: > On 3 May 2016 at 23:19, Bruno Randolf wrote: > > On 03/05/16 18:59, Jo-Philipp Wich wrote: > >> we'd like to introduce LEDE, a reboot of the OpenWrt community > >> ... > >> Jo-Philipp Wich, > >> John Crispin, > >> Daniel Golle, > >> Felix Fietkau, > >> Hauke Mehrtens > >> John Crispin > >> Matthias Schiffer, > >> Steven Barth > > > > While a fresh start and a more open process is good move, given this > > list of supporters it sounds a bit ridiculous... who is left in the > > OpenWRT boat and why not do it as OpenWRT (V2 or whatever)??? > come on.. is this a joke? same names, same faces, if you sliced this list off from the current dev group, who is actually left.... anyway.... on that note, if its legit, ill jump onboard and throw my hat in the ring also due to my trust and respect for those that are listed. > > Indeed. Looks like silent rebranding. Without public discussion of the > issues (and possible ways to fix them) in mailing list Same people, > rules and methods. > Could you elaborate more and explain how exactly LEDE is going to fix > the listed problems? And why it's not possible to fix them inside > existing project? > > > Regards, > Roman > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From kevlo at kevlo.org Tue May 3 22:16:36 2016 From: kevlo at kevlo.org (Kevin Lo) Date: Wed, 4 May 2016 10:16:36 +0800 Subject: [OpenWrt-Devel] [PATCH] ramips: Enable wmac to WRTnode2 device tree Message-ID: <20160504021636.GA87848@ns.kevlo.org> This patch enables MT7628 WMAC to WRTnode2 device tree. Signed-off-by: Kevin Lo --- diff --git a/target/linux/ramips/dts/WRTNODE2.dtsi b/target/linux/ramips/dts/WRTNODE2.dtsi index d9aaba8..00040a2 100644 --- a/target/linux/ramips/dts/WRTNODE2.dtsi +++ b/target/linux/ramips/dts/WRTNODE2.dtsi @@ -89,5 +89,8 @@ }; }; -}; + wmac at 10300000 { + status = "okay"; + }; +}; _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From alzhao at gmail.com Tue May 3 22:44:12 2016 From: alzhao at gmail.com (alzhao) Date: Wed, 4 May 2016 10:44:12 +0800 Subject: [OpenWrt-Devel] How to initialize multiple phy radios In-Reply-To: References: <87potd3e9j.fsf@kamboji.qca.qualcomm.com> <112436203.W4fT509tru@debian64> Message-ID: Hi David, Can you share you current patch? I am working on the same chips, QCA9531+9887 and hope to get some progress. I'm glad to know that scan is working. --Alfie On 26 April 2016 at 06:14, David Hutchison wrote: > Scanning appears to work ( iw dev wlan1 scan ) , > > As soon as I try to use hostapd to run as an AP I get: > > [20475.140000] ath10k_pci 0000:00:00.0: firmware crashed! (uuid > b826d45e-e51f-4beb-a489-6b7a4d5c6f76) > [20475.150000] ath10k_pci 0000:00:00.0: qca988x hw2.0 (0x4100016d, > 0x004000ff sub 0000:0000) fw 10.2.3.31.7-1 fwapi 5 bdapi 1 htt-ver 2.1 > wmi-op 5 htt-op 2 cal file max-sta 1p > [20475.170000] ath10k_pci 0000:00:00.0: debug 1 debugfs 1 tracing 0 > dfs 0 testmode 1 > [20475.180000] ath10k_pci 0000:00:00.0: firmware register dump: > [20475.180000] ath10k_pci 0000:00:00.0: [00]: 0x4100016D 0x00000000 > 0x004146C8 0x004146C8 > [20475.190000] ath10k_pci 0000:00:00.0: [04]: 0x004146C8 0x00060530 > 0x0000001F 0x00955A00 > [20475.200000] ath10k_pci 0000:00:00.0: [08]: 0x0040AE04 0x00400000 > 0x00000007 0x00000000 > [20475.210000] ath10k_pci 0000:00:00.0: [12]: 0x00000002 0xFFFFFFFF > 0x00958360 0x0095836B > [20475.210000] ath10k_pci 0000:00:00.0: [16]: 0x809ACDE0 0x0040AD94 > 0x0040AE04 0x00400000 > [20475.220000] ath10k_pci 0000:00:00.0: [20]: 0x00000000 0x00000000 > 0x00000000 0x0040E830 > [20475.230000] ath10k_pci 0000:00:00.0: [24]: 0x809AC4E2 0x0040ADC4 > 0x00000001 0x0040AE04 > [20475.240000] ath10k_pci 0000:00:00.0: [28]: 0x004133E0 0x00000001 > 0x0040AE08 0x00000000 > [20475.250000] ath10k_pci 0000:00:00.0: [32]: 0x00000007 0x00000000 > 0x00000000 0x004133C8 > [20475.260000] ath10k_pci 0000:00:00.0: [36]: 0x809B9C49 0x0040ADE4 > 0x00411568 0x0041158C > [20475.260000] ath10k_pci 0000:00:00.0: [40]: 0x00000001 0x00000000 > 0x00955A00 0x0040E840 > [20475.270000] ath10k_pci 0000:00:00.0: [44]: 0x809B944C 0x0040AE04 > 0x00000001 0x00000000 > [20475.280000] ath10k_pci 0000:00:00.0: [48]: 0x0040AE04 0x00000001 > 0x004133C8 0x004117AC > [20475.290000] ath10k_pci 0000:00:00.0: [52]: 0x809B9263 0x0040AEA4 > 0x0041ECF8 0x00411BC8 > [20475.300000] ath10k_pci 0000:00:00.0: [56]: 0x004133C8 0x0040AE34 > 0x00411F08 0x00411F08 > [20475.410000] ieee80211 phy1: Hardware restart was requested > > -- Davey > > On Mon, Apr 25, 2016 at 1:01 PM, Christian Lamparter > wrote: > > Hello, > > > > On Monday, April 25, 2016 10:53:41 AM David Hutchison wrote: > >> So with some modifications to pci.c, hw.h and core.c I was able to get > >> the radio initialized! :) > > > > Hey, that's nice! Can you make and post a patch for that? > > I'm sure if it's just a matter of adding the new pci and chip > > ids to the tables. You could just go ahead and post it, so it > > will be picked up. > > > >> pci.c: added QCA9887_DEVICE_ID, modified ath10k_pci_id_table and > >> ath10k_pci_supp_chips > >> core.c: Duplicated QCA988X entry in ath10k_hw_params_list and passed > >> 0x4100016d as the ID ( left everything else the same ) > >> hw.h: added definitions for QCA9887 > >> > >> I found " > https://github.com/kvalo/ath10k-firmware/blob/master/QCA9887/firmware-5.bin_10.2.3.31.7-1 > " > >> on your github and replaced > >> /lib/firmware/ath10k/QCA988X/hw2.0/firmware-5.bin on my board. > >> hotplug.d then loaded QCA9887 firmware on next boot. > >> > >> Of course my approach was very much a hack. If there is anything I can > >> contribute to creating a patch for ath10k, please let me know. I would > >> love to help! > >> > >> dmesg > >> [ 18.920000] ath10k_pci 0000:00:00.0: pci irq legacy interrupts 0 > >> irq_mode 0 reset_mode 0 > >> [ 19.030000] rev_id 00000000 QCA9887 > >> [ 19.030000] dev_id 00000050 QCA9887 > >> [ 20.460000] ath10k_pci 0000:00:00.0: qca988x hw2.0 (0x4100016d, > >> 0x004000ff sub 0000:0000) fw 10.2.3.31.7-1 fwapi 5 bdapi 1 htt-ver 2.1 > >> wmi-op 5 htt-op 2 cal file max-sta 1p > >> [ 20.480000] ath10k_pci 0000:00:00.0: debug 1 debugfs 1 tracing 0 > >> dfs 0 testmode 1 > >> > > ... > > > > Does the device work? Can you scan for networks, connect to networks > > and create networks? That would be good to know. > > > > Regards, > > Christian > > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From reinoudkoornstra at gmail.com Wed May 4 02:13:24 2016 From: reinoudkoornstra at gmail.com (Reinoud Koornstra) Date: Wed, 4 May 2016 00:13:24 -0600 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: References: <5179f6d1-283a-1b40-d717-2730c3408326@openwrt.org> <572907D0.8080700@einfach.org> Message-ID: On Tue, May 3, 2016 at 7:54 PM, Outback Dingo wrote: > > > On Wed, May 4, 2016 at 12:50 AM, Roman Yeryomin > wrote: >> >> On 3 May 2016 at 23:19, Bruno Randolf wrote: >> > On 03/05/16 18:59, Jo-Philipp Wich wrote: >> >> we'd like to introduce LEDE, a reboot of the OpenWrt community >> >> ... >> >> Jo-Philipp Wich, >> >> John Crispin, >> >> Daniel Golle, >> >> Felix Fietkau, >> >> Hauke Mehrtens >> >> John Crispin >> >> Matthias Schiffer, >> >> Steven Barth >> > >> > While a fresh start and a more open process is good move, given this >> > list of supporters it sounds a bit ridiculous... who is left in the >> > OpenWRT boat and why not do it as OpenWRT (V2 or whatever)??? > > > come on.. is this a joke? same names, same faces, if you sliced this list > off from the current dev group, who is actually left.... anyway.... on that > note, if its legit, ill jump onboard and throw my hat in the ring also due > to my trust and respect for those that are listed. I am kind of surprised. There are still daily checkins in the tree. Still some people are adding support for boards. Hence I must not understand the notion of inactiveness. The value of openwrt is still invaluable. If rebranding helps pumping additional life into it, why not... > >> >> >> Indeed. Looks like silent rebranding. Without public discussion of the >> issues (and possible ways to fix them) in mailing list Same people, >> rules and methods. >> Could you elaborate more and explain how exactly LEDE is going to fix >> the listed problems? And why it's not possible to fix them inside >> existing project? >> >> >> Regards, >> Roman >> _______________________________________________ >> openwrt-devel mailing list >> openwrt-devel at lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > > > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From leroi.lists at gmail.com Wed May 4 03:31:28 2016 From: leroi.lists at gmail.com (Roman Yeryomin) Date: Wed, 4 May 2016 10:31:28 +0300 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: References: <5179f6d1-283a-1b40-d717-2730c3408326@openwrt.org> <572907D0.8080700@einfach.org> Message-ID: On 4 May 2016 at 09:13, Reinoud Koornstra wrote: > On Tue, May 3, 2016 at 7:54 PM, Outback Dingo wrote: >> >> >> On Wed, May 4, 2016 at 12:50 AM, Roman Yeryomin >> wrote: >>> >>> On 3 May 2016 at 23:19, Bruno Randolf wrote: >>> > On 03/05/16 18:59, Jo-Philipp Wich wrote: >>> >> we'd like to introduce LEDE, a reboot of the OpenWrt community >>> >> ... >>> >> Jo-Philipp Wich, >>> >> John Crispin, >>> >> Daniel Golle, >>> >> Felix Fietkau, >>> >> Hauke Mehrtens >>> >> John Crispin >>> >> Matthias Schiffer, >>> >> Steven Barth >>> > >>> > While a fresh start and a more open process is good move, given this >>> > list of supporters it sounds a bit ridiculous... who is left in the >>> > OpenWRT boat and why not do it as OpenWRT (V2 or whatever)??? >> >> >> come on.. is this a joke? same names, same faces, if you sliced this list >> off from the current dev group, who is actually left.... anyway.... on that >> note, if its legit, ill jump onboard and throw my hat in the ring also due >> to my trust and respect for those that are listed. > > I am kind of surprised. > There are still daily checkins in the tree. > Still some people are adding support for boards. > Hence I must not understand the notion of inactiveness. > The value of openwrt is still invaluable. > If rebranding helps pumping additional life into it, why not... I'm not against rebranding but I don't see how it fixes the problem. IMO it only makes it worse. >> >>> >>> >>> Indeed. Looks like silent rebranding. Without public discussion of the >>> issues (and possible ways to fix them) in mailing list Same people, >>> rules and methods. >>> Could you elaborate more and explain how exactly LEDE is going to fix >>> the listed problems? And why it's not possible to fix them inside >>> existing project? >>> >>> _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From amine.ahd at gmail.com Wed May 4 03:52:24 2016 From: amine.ahd at gmail.com (amine.ahd) Date: Wed, 4 May 2016 09:52:24 +0200 Subject: [OpenWrt-Devel] [PATCH] Hostapd: Add support for multiple RADIUS servers In-Reply-To: <1461220774-16115-1-git-send-email-amine.ahd@gmail.com> References: <1461220774-16115-1-git-send-email-amine.ahd@gmail.com> Message-ID: <1462348344-7173-1-git-send-email-amine.ahd@gmail.com> Hostapd allows more than one RADIUS server to be added in case the main server goes down. This allows netifd to load a list of RADIUS servers from the wireless confid file and add them to hostapd. The format of the list in the config file is as follow: list auth_servers 'secret at server_addr[:port]' The old syntax is still supported. Signed-off-by: Amine Hamed --- .../network/services/hostapd/files/netifd.sh | 29 +++++++++++++++++++--- 1 file changed, 26 insertions(+), 3 deletions(-) diff --git a/package/network/services/hostapd/files/netifd.sh b/package/network/services/hostapd/files/netifd.sh index 417cc42..9da39f9 100644 --- a/package/network/services/hostapd/files/netifd.sh +++ b/package/network/services/hostapd/files/netifd.sh @@ -125,6 +125,8 @@ hostapd_common_add_bss_config() { config_add_string auth_secret config_add_int 'auth_port:port' 'port:port' + config_add_array auth_servers + config_add_string acct_server config_add_string acct_secret config_add_int acct_port @@ -269,10 +271,31 @@ hostapd_set_bss_options() { set_default vlan_naming 1 - append bss_conf "auth_server_addr=$auth_server" "$N" - append bss_conf "auth_server_port=$auth_port" "$N" - append bss_conf "auth_server_shared_secret=$auth_secret" "$N" + # leave the default option for legacy compatibility + [ -z "$auth_server" ] || append bss_conf "auth_server_addr=$auth_server" "$N" + [ -z "$auth_server" ] || append bss_conf "auth_server_port=$auth_port" "$N" + [ -z "$auth_secret" ] || append bss_conf "auth_server_shared_secret=$auth_secret" "$N" + + # List of fallback RADIUS servers, ip_add at secret[:port] + json_select "auth_servers" + local Index="1" + while json_get_type Var $Index && [ "$Var" = string ]; do + json_get_var Var "$((Index++))" + + ip_addr=$(echo "$Var" | cut -d"@" -f2 | cut -d":" -f1) + append bss_conf "auth_server_addr=$ip_addr" "$N" + port=$(echo "$Var" | cut -d"@" -f2 | cut -d":" -f2) + if ! echo "$port" | egrep -q '^[0-9]+$' ; then + port=1812 + fi + append bss_conf "auth_server_port=$port" "$N" + + secret=$(echo "$Var" | cut -d"@" -f1) + append bss_conf "auth_server_shared_secret=$secret" "$N" + done + json_select ".." + [ -n "$acct_server" ] && { append bss_conf "acct_server_addr=$acct_server" "$N" append bss_conf "acct_server_port=$acct_port" "$N" -- 2.6.6 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From leroi.lists at gmail.com Wed May 4 04:50:01 2016 From: leroi.lists at gmail.com (Roman Yeryomin) Date: Wed, 4 May 2016 11:50:01 +0300 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: References: <5179f6d1-283a-1b40-d717-2730c3408326@openwrt.org> <572907D0.8080700@einfach.org> Message-ID: On 4 May 2016 at 10:31, Roman Yeryomin wrote: > On 4 May 2016 at 09:13, Reinoud Koornstra wrote: >> On Tue, May 3, 2016 at 7:54 PM, Outback Dingo wrote: >>> >>> >>> On Wed, May 4, 2016 at 12:50 AM, Roman Yeryomin >>> wrote: >>>> >>>> On 3 May 2016 at 23:19, Bruno Randolf wrote: >>>> > On 03/05/16 18:59, Jo-Philipp Wich wrote: >>>> >> we'd like to introduce LEDE, a reboot of the OpenWrt community >>>> >> ... >>>> >> Jo-Philipp Wich, >>>> >> John Crispin, >>>> >> Daniel Golle, >>>> >> Felix Fietkau, >>>> >> Hauke Mehrtens >>>> >> John Crispin >>>> >> Matthias Schiffer, >>>> >> Steven Barth >>>> > >>>> > While a fresh start and a more open process is good move, given this >>>> > list of supporters it sounds a bit ridiculous... who is left in the >>>> > OpenWRT boat and why not do it as OpenWRT (V2 or whatever)??? >>> >>> >>> come on.. is this a joke? same names, same faces, if you sliced this list >>> off from the current dev group, who is actually left.... anyway.... on that >>> note, if its legit, ill jump onboard and throw my hat in the ring also due >>> to my trust and respect for those that are listed. >> >> I am kind of surprised. >> There are still daily checkins in the tree. >> Still some people are adding support for boards. >> Hence I must not understand the notion of inactiveness. >> The value of openwrt is still invaluable. >> If rebranding helps pumping additional life into it, why not... > > I'm not against rebranding but I don't see how it fixes the problem. > IMO it only makes it worse. > >>> >>>> >>>> >>>> Indeed. Looks like silent rebranding. Without public discussion of the >>>> issues (and possible ways to fix them) in mailing list Same people, >>>> rules and methods. >>>> Could you elaborate more and explain how exactly LEDE is going to fix >>>> the listed problems? And why it's not possible to fix them inside >>>> existing project? >>>> >>>> John, others, "The name LEDE stands for Linux Embedded Development Environment." sounds like build system only. I would vote for separating build system into separate project. Actually, if you remember, I was proposing this several years ago. It would make more sense and would better fit LEDE name. Though "Linux" can be subtracted from there as it's capable of building also MCU projects. Regards, Roman _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From pannen at gmail.com Wed May 4 05:00:49 2016 From: pannen at gmail.com (Rick Pannen) Date: Wed, 4 May 2016 11:00:49 +0200 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: References: <5179f6d1-283a-1b40-d717-2730c3408326@openwrt.org> <572907D0.8080700@einfach.org> Message-ID: <0998F7CD-4F9A-46A3-A715-C56B03E946EB@gmail.com> The only thing that seems to improve from my perspective is normal git pull requests instead of antiquated email patches. The name change and that 90's style website will only confuse the users. > Am 04.05.2016 um 00:50 schrieb Roman Yeryomin : > >> On 3 May 2016 at 23:19, Bruno Randolf wrote: >>> On 03/05/16 18:59, Jo-Philipp Wich wrote: >>> we'd like to introduce LEDE, a reboot of the OpenWrt community >>> ... >>> Jo-Philipp Wich, >>> John Crispin, >>> Daniel Golle, >>> Felix Fietkau, >>> Hauke Mehrtens >>> John Crispin >>> Matthias Schiffer, >>> Steven Barth >> >> While a fresh start and a more open process is good move, given this >> list of supporters it sounds a bit ridiculous... who is left in the >> OpenWRT boat and why not do it as OpenWRT (V2 or whatever)??? > > Indeed. Looks like silent rebranding. Without public discussion of the > issues (and possible ways to fix them) in mailing list Same people, > rules and methods. > Could you elaborate more and explain how exactly LEDE is going to fix > the listed problems? And why it's not possible to fix them inside > existing project? > > > Regards, > Roman > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From gareth41 at orcon.net.nz Wed May 4 06:57:16 2016 From: gareth41 at orcon.net.nz (Gareth Parker) Date: Wed, 4 May 2016 22:57:16 +1200 Subject: [OpenWrt-Devel] [PATCH] Chaos Calmer - ath71xx: Add support for the Comfast CF-WR650AC Message-ID: <000101d1a5f3$b9739210$2c5ab630$@orcon.net.nz> This patch adds support for the Comfast CF-WR650AC to Chaos Calmer. More information is located at: http://en.comfast.com.cn/product/SmartRepeater/item-217.html I haven't been able to add this to Trunk as mac06_exchange_en is required and was changed in r47956. Without it the router hangs then reboots when accessing anything switch related, either through swconfig or luci. Signed-off-by: Gareth Parker diff --git a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata index e6fcec8..751b685 100644 --- a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata +++ b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata @@ -47,6 +47,10 @@ board=$(ar71xx_board_name) case "$FIRMWARE" in "ath10k/cal-pci-0000:00:00.0.bin") case $board in + cf-wr650ac) + ath10kcal_extract "art" 20480 2116 + ath10kcal_patch_mac $(macaddr_add $(cat /sys/class/net/eth0/address) +3) + ;; dlan-pro-1200-ac) ath10kcal_extract "art" 20480 2116 ;; diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds index a4b355a..6fa4813 100644 --- a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds @@ -50,6 +50,11 @@ bsb) ucidef_set_led_default "sys" "SYS" "bsb:red:sys" "1" ;; +cf-wr650ac) + ucidef_set_led_wlan "wlan2g" "WLAN 2.4 GHz" "comfast:blue:24g" "phy1tpt" + ucidef_set_led_wlan "wlan5g" "WLAN 5 GHz" "comfast:blue:58g" "phy0tpt" + ;; + bullet-m | \ nanostation-m | \ rocket-m | \ diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network index b2e15bb..3ed8cf1 100755 --- a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network @@ -64,6 +64,13 @@ tl-wdr4900-v2) ucidef_add_switch_vlan "switch0" "2" "1 6" ;; +cf-wr650ac) + ucidef_set_interfaces_lan_wan "eth0" "eth1" + ucidef_add_switch "switch0" "1" "1" + ucidef_add_switch_vlan "switch0" "1" "0 2 3 4 5" + ucidef_add_switch_vlan "switch0" "2" "1 6" + ;; + bsb) ucidef_set_interfaces_lan_wan "eth1" "eth0" ucidef_add_switch "switch0" "1" "1" diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh b/target/linux/ar71xx/base-files/lib/ar71xx.sh index dab4d2c..bdd76f9 100755 --- a/target/linux/ar71xx/base-files/lib/ar71xx.sh +++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh @@ -396,6 +396,9 @@ ar71xx_board_detect() { *CAP4200AG) name="cap4200ag" ;; + *"CF-WR650AC") + name="cf-wr650ac" + ;; *"CPE210/220/510/520") name="cpe510" tplink_pharos_board_detect diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh index d025632..bbc06ab 100755 --- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh +++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh @@ -400,6 +400,15 @@ platform_check_image() { } return 0 ;; + + cf-wr650ac) + [ "$magic_long" != "27051956" ] && { + echo "Invalid image type." + return 1 + } + return 0 + ;; + wndr3700 | \ wnr2000-v3 | \ wnr612-v2 | \ @@ -531,6 +540,7 @@ platform_do_upgrade() { om5p-an) platform_do_upgrade_openmesh "$ARGV" ;; + cf-wr650ac | \ unifi-outdoor-plus | \ uap-pro) MTD_CONFIG_ARGS="-s 0x180000" diff --git a/target/linux/ar71xx/config-3.18 b/target/linux/ar71xx/config-3.18 index e2ff826..11cd969 100644 --- a/target/linux/ar71xx/config-3.18 +++ b/target/linux/ar71xx/config-3.18 @@ -48,6 +48,7 @@ CONFIG_ATH79_MACH_BSB=y CONFIG_ATH79_MACH_CAP4200AG=y CONFIG_ATH79_MACH_CARAMBOLA2=y CONFIG_ATH79_MACH_CPE510=y +CONFIG_ATH79_MACH_CF_WR650AC=y CONFIG_ATH79_MACH_DB120=y CONFIG_ATH79_MACH_DGL_5500_A1=y CONFIG_ATH79_MACH_DHP_1565_A1=y diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-cf-wr650ac.c b/target/linux/ar71xx/files/arch/mips/ath79/mach-cf-wr650ac.c new file mode 100644 index 0000000..2ffec13 --- /dev/null +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-cf-wr650ac.c @@ -0,0 +1,196 @@ +/* + * COMFAST CF-WR650AC board support + * + * Copyright (C) 2016 Gareth Parker + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 as published + * by the Free Software Foundation. + */ + +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#include "common.h" +#include "dev-ap9x-pci.h" +#include "dev-eth.h" +#include "dev-gpio-buttons.h" +#include "dev-leds-gpio.h" +#include "dev-m25p80.h" +#include "dev-usb.h" +#include "dev-wmac.h" +#include "dev-nfc.h" +#include "gpio.h" +#include "machtypes.h" +#include "pci.h" + +#define CF_WR650AC_KEYS_POLL_INTERVAL 20 /* msecs */ +#define CF_WR650AC_KEYS_DEBOUNCE_INTERVAL (3 * CF_WR650AC_KEYS_POLL_INTERVAL) + +#define CF_WR650AC_WATCHDOG_GPIO 17 + +#define CF_WR650AC_GPIO_BTN_RESET_WPS 19 + +#define CF_WR650AC_GPIO_LED_NETWORK 4 +#define CF_WR650AC_GPIO_LED_24G 13 +#define CF_WR650AC_GPIO_LED_58G 2 +#define CF_WR650AC_GPIO_LED_WPS 20 + +#define CF_WR650AC_WMAC_CALDATA_OFFSET 0x1000 +#define CF_WR650AC_PCIE_CALDATA_OFFSET 0x5000 + +#define CF_WR650AC_LAN_PHYMASK BIT(0) +#define CF_WR650AC_WAN_PHYMASK BIT(5) + +static struct gpio_led cf_wr650ac_leds_gpio[] __initdata = { + { + .name = "comfast:blue:network", + .gpio = CF_WR650AC_GPIO_LED_NETWORK, + .active_low = 1, + }, + { + .name = "comfast:blue:24g", + .gpio = CF_WR650AC_GPIO_LED_24G, + .active_low = 1, + }, + { + .name = "comfast:blue:58g", + .gpio = CF_WR650AC_GPIO_LED_58G, + .active_low = 1, + }, + { + .name = "comfast:blue:wps", + .gpio = CF_WR650AC_GPIO_LED_WPS, + .active_low = 1, + }, +}; + +static struct gpio_keys_button cf_wr650ac_gpio_keys[] __initdata = { + { + .desc = "Reset button/WPS button", + .type = EV_KEY, + .code = KEY_RESTART, + .debounce_interval = CF_WR650AC_KEYS_DEBOUNCE_INTERVAL, + .gpio = CF_WR650AC_GPIO_BTN_RESET_WPS, + .active_low = 1, + }, +}; + +static struct ar8327_pad_cfg cf_wr650ac_ar8327_pad0_cfg = { + /* GMAC0 of the AR8337 switch is connected to GMAC0 via RGMII */ + .mode = AR8327_PAD_MAC_RGMII, + .txclk_delay_en = true, + .rxclk_delay_en = true, + .txclk_delay_sel = AR8327_CLK_DELAY_SEL1, + .rxclk_delay_sel = AR8327_CLK_DELAY_SEL2, + .mac06_exchange_en = true, +}; + +static struct ar8327_pad_cfg cf_wr650ac_ar8327_pad6_cfg = { + /* GMAC6 of the AR8337 switch is connected to GMAC1 via SGMII */ + .mode = AR8327_PAD_MAC_SGMII, + .rxclk_delay_en = true, + .rxclk_delay_sel = AR8327_CLK_DELAY_SEL0, +}; + +static struct ar8327_platform_data cf_wr650ac_ar8327_data = { + .pad0_cfg = &cf_wr650ac_ar8327_pad0_cfg, + .pad6_cfg = &cf_wr650ac_ar8327_pad6_cfg, + .port0_cfg = { + .force_link = 1, + .speed = AR8327_PORT_SPEED_1000, + .duplex = 1, + .txpause = 1, + .rxpause = 1, + }, + .port6_cfg = { + .force_link = 1, + .speed = AR8327_PORT_SPEED_1000, + .duplex = 1, + .txpause = 1, + .rxpause = 1, + }, +}; + +static struct mdio_board_info cf_wr650ac_mdio0_info[] = { + { + .bus_id = "ag71xx-mdio.0", + .phy_addr = 0, + .platform_data = &cf_wr650ac_ar8327_data, + }, +}; + +static struct timer_list watchdog_timer; + +static void watchdog_gpio(unsigned long period) +{ + static int state; + state = !state; + gpio_set_value(CF_WR650AC_WATCHDOG_GPIO, state); + mod_timer(&watchdog_timer, jiffies + period); +} + +static void __init cf_wr650ac_setup(void) +{ + u8 *art = (u8 *) KSEG1ADDR(0x1f020000); + u8 wlan0_mac[ETH_ALEN]; + u8 wlan1_mac[ETH_ALEN]; + + gpio_request(CF_WR650AC_WATCHDOG_GPIO, "watchdog timer gpio"); + gpio_direction_output(CF_WR650AC_WATCHDOG_GPIO, 0); + setup_timer(&watchdog_timer, watchdog_gpio, msecs_to_jiffies(500)); + watchdog_gpio(msecs_to_jiffies(1)); + + ath79_register_m25p80(NULL); + ath79_register_leds_gpio(-1, ARRAY_SIZE(cf_wr650ac_leds_gpio), + cf_wr650ac_leds_gpio); + ath79_register_gpio_keys_polled(-1, CF_WR650AC_KEYS_POLL_INTERVAL, + ARRAY_SIZE(cf_wr650ac_gpio_keys), + cf_wr650ac_gpio_keys); + + ath79_register_usb(); + + ath79_init_mac(wlan0_mac, art, 1); + ath79_init_mac(wlan1_mac, art, 3); + + ath79_register_wmac(art + CF_WR650AC_WMAC_CALDATA_OFFSET, wlan0_mac); + + ath79_setup_qca955x_eth_cfg(QCA955X_ETH_CFG_RGMII_EN); + + ath79_register_mdio(0, 0x0); + + mdiobus_register_board_info(cf_wr650ac_mdio0_info, + ARRAY_SIZE(cf_wr650ac_mdio0_info)); + + /* GMAC0 is connected to the RMGII interface */ + ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_RGMII; + ath79_eth0_data.phy_mask = CF_WR650AC_LAN_PHYMASK; + ath79_eth0_data.mii_bus_dev = &ath79_mdio0_device.dev; + ath79_eth0_pll_data.pll_1000 = 0xa6000000; + + ath79_init_mac(ath79_eth0_data.mac_addr, art, 0); + ath79_register_eth(0); + + /* GMAC1 is connected to the SGMII interface */ + ath79_eth1_data.phy_if_mode = PHY_INTERFACE_MODE_SGMII; + ath79_eth1_data.speed = SPEED_1000; + ath79_eth1_data.duplex = DUPLEX_FULL; + ath79_eth1_pll_data.pll_1000 = 0x03000101; + + ath79_init_mac(ath79_eth1_data.mac_addr, art, 2); + ath79_register_eth(1); + + ap91_pci_init(art + CF_WR650AC_PCIE_CALDATA_OFFSET, wlan1_mac); +} + +MIPS_MACHINE(ATH79_MACH_CF_WR650AC, "CF-WR650AC", "COMFAST CF-WR650AC", + cf_wr650ac_setup); diff --git a/target/linux/ar71xx/generic/profiles/comfast.mk b/target/linux/ar71xx/generic/profiles/comfast.mk new file mode 100644 index 0000000..e79c475 --- /dev/null +++ b/target/linux/ar71xx/generic/profiles/comfast.mk @@ -0,0 +1,14 @@ +# +# Copyright (C) 2009 OpenWrt.org +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# +define Profile/CF-WR650AC + NAME:=COMFAST CF-WR650AC + PACKAGES:= +endef +define Profile/CF-WR650AC/Description + Package set optimized for the COMFAST CF-WR650AC. +endef +$(eval $(call Profile,CF-WR650AC)) diff --git a/target/linux/ar71xx/image/Makefile b/target/linux/ar71xx/image/Makefile index 9a7acbd..81e8cd7 100644 --- a/target/linux/ar71xx/image/Makefile +++ b/target/linux/ar71xx/image/Makefile @@ -1043,6 +1043,7 @@ pb92_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,2752k(rootfs ),89 planex_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,7744k(firm ware),128k(art)ro ubntxm_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,7552k(firm ware),256k(cfg)ro,64k(EEPROM)ro uap_pro_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,1536k(ker nel),14208k(rootfs),256k(cfg)ro,64k(EEPROM)ro,15744k at 0x50000(firmware) +qca9558_cf_wr650ac_mtdlayout=mtdparts=spi0.0:128k(u-boot)ro,64k(art)ro,1536 k(kernel),14592k(rootfs),64k(nvram)ro,16128k at 0x30000(firmware) ubdev_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,7488k(firmw are),64k(certs),256k(cfg)ro,64k(EEPROM)ro whrhpg300n_mtdlayout=mtdparts=spi0.0:248k(u-boot)ro,8k(u-boot-env)ro,3712k(f irmware),64k(art)ro wlr8100_mtdlayout=mtdparts=spi0.0:192k(u-boot)ro,64k(u-boot-env)ro,1408k(ker nel),14080k(rootfs),192k(unknown)ro,64k(art)ro,384k(unknown2)ro,15488k at 0x400 00(firmware) @@ -1396,6 +1397,16 @@ define Image/Build/UAPPRO -o $(call factoryname,$(1),$(2)) endef +define Image/Build/COMFAST + $(call MkuImageLzma,$(2),$(3) $(4)) + dd if=$(KDIR_TMP)/vmlinux-$(2).uImage \ + of=$(call imgname,kernel,$(2)).bin bs=64k conv=sync; \ + dd if=$(KDIR)/root.$(1) \ + of=$(call imgname,$(1),$(2)-rootfs).bin bs=128k conv=sync; \ + ( dd if=$(KDIR_TMP)/vmlinux-$(2).uImage bs=1572864 conv=sync; dd if=$(KDIR)/root.$(1) ) \ + > $(call imgname,$(1),$(2))-sysupgrade.bin +endef + # $(4) = board (XS2, XS5, RS, XM) # $(5) = series (BZ, XM, XW) # $(6) = chip (ar7240, ar934x) @@ -2064,6 +2075,8 @@ $(eval $(call SingleProfile,TPLINK-SAFELOADER,64kraw,CPE510,cpe210-220-510-520,C $(eval $(call SingleProfile,UAPPRO,64k,UAPPRO,ubnt-uap-pro,UAP-PRO,ttyS0,115200,BZ,BZ,ar93 4x)) $(eval $(call SingleProfile,UAPPRO,64k,UBNTUNIFIOUTDOORPLUS,ubnt-unifi-outdoor-plus,UBNT-U OP,ttyS0,115200,BZ,BZ,ar7240)) +$(eval $(call SingleProfile,COMFAST,64k,CF-WR650AC,cf-wr650ac,CF-WR650AC,ttyS0,115200,$$(q ca9558_cf_wr650ac_mtdlayout),CF-WR650AC,qca955x)) + $(eval $(call SingleProfile,UBDEV,64kraw,UBDEV01,ubdev01,UBNT-UF,ttyS0,115200,UBDEV01,XM,a r7240)) $(eval $(call SingleProfile,UBNT,64k,UBNTRS,ubnt-rs,UBNT-RS,ttyS0,115200,RS,RSx,ar7100)) diff --git a/target/linux/ar71xx/patches-3.18/610-MIPS-ath79-openwrt-machines.patch b/target/linux/ar71xx/patches-3.18/610-MIPS-ath79-openwrt-machines.patch index d6e786d..c33a838 100644 --- a/target/linux/ar71xx/patches-3.18/610-MIPS-ath79-openwrt-machines.patch +++ b/target/linux/ar71xx/patches-3.18/610-MIPS-ath79-openwrt-machines.patch @@ -1,6 +1,6 @@ --- a/arch/mips/ath79/machtypes.h +++ b/arch/mips/ath79/machtypes.h -@@ -16,22 +16,199 @@ +@@ -16,22 +16,200 @@ enum ath79_mach_type { ATH79_MACH_GENERIC = 0, @@ -26,6 +26,7 @@ + ATH79_MACH_BHU_BXU2000N2_A1, /* BHU BXU2000n-2 A1 */ + ATH79_MACH_CAP4200AG, /* Senao CAP4200AG */ + ATH79_MACH_CARAMBOLA2, /* 8devices Carambola2 */ ++ ATH79_MACH_CF_WR650AC, /* COMFAST CF-WR650AC */ + ATH79_MACH_CPE510, /* TP-LINK CPE510 */ ATH79_MACH_DB120, /* Atheros DB120 reference board */ ATH79_MACH_PB44, /* Atheros PB44 reference board */ @@ -282,7 +283,7 @@ config ATH79_MACH_AP121 bool "Atheros AP121 reference board" select SOC_AR933X -@@ -11,62 +84,1050 @@ config ATH79_MACH_AP121 +@@ -11,62 +84,1060 @@ config ATH79_MACH_AP121 select ATH79_DEV_M25P80 select ATH79_DEV_USB select ATH79_DEV_WMAC @@ -349,6 +350,16 @@ + select ATH79_DEV_M25P80 + select ATH79_DEV_USB + ++config ATH79_MACH_CF_WR650AC ++ bool "COMFAST CF-WR650AC board support" ++ select SOC_QCA955X ++ select ATH79_DEV_ETH ++ select ATH79_DEV_GPIO_BUTTONS ++ select ATH79_DEV_LEDS_GPIO ++ select ATH79_DEV_M25P80 ++ select ATH79_DEV_USB ++ select ATH79_DEV_WMAC ++ +config ATH79_MACH_DB120 + bool "Atheros DB120 reference board" + select SOC_AR934X @@ -1494,7 +1505,7 @@ endif --- a/arch/mips/ath79/Makefile +++ b/arch/mips/ath79/Makefile -@@ -38,9 +38,128 @@ obj-$(CONFIG_ATH79_ROUTERBOOT) += route +@@ -38,9 +38,129 @@ obj-$(CONFIG_ATH79_ROUTERBOOT) += route # # Machines # @@ -1514,6 +1525,7 @@ +obj-$(CONFIG_ATH79_MACH_AW_NR580) += mach-aw-nr580.o +obj-$(CONFIG_ATH79_MACH_BHU_BXU2000N2_A)+= mach-bhu-bxu2000n2-a.o +obj-$(CONFIG_ATH79_MACH_CAP4200AG) += mach-cap4200ag.o ++obj-$(CONFIG_ATH79_MACH_CF_WR650AC) += mach-cf-wr650ac.o +obj-$(CONFIG_ATH79_MACH_CPE510) += mach-cpe510.o obj-$(CONFIG_ATH79_MACH_DB120) += mach-db120.o +obj-$(CONFIG_ATH79_MACH_DLAN_PRO_500_WP) += mach-dlan-pro-500-wp.o _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From carlosmf.pt at gmail.com Wed May 4 07:35:16 2016 From: carlosmf.pt at gmail.com (Carlos Ferreira) Date: Wed, 4 May 2016 12:35:16 +0100 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <0998F7CD-4F9A-46A3-A715-C56B03E946EB@gmail.com> References: <5179f6d1-283a-1b40-d717-2730c3408326@openwrt.org> <572907D0.8080700@einfach.org> <0998F7CD-4F9A-46A3-A715-C56B03E946EB@gmail.com> Message-ID: From michal.hrusecky at nic.cz Wed May 4 07:53:27 2016 From: michal.hrusecky at nic.cz (Michal Hrusecky) Date: Wed, 4 May 2016 13:53:27 +0200 Subject: [OpenWrt-Devel] [PATCH] [package] openssl: Update to version 1.0.2h Message-ID: <20160504115327.GA2676@workbook.ipv6.hrusecky.net> Bump to the latest version, fixes several security issues: * CVE-2016-2107, CVE-2016-2105, CVE-2016-2106, CVE-2016-2109, CVE-2016-2176 More details at https://www.openssl.org/news/openssl-1.0.2-notes.html Signed-off-by: Michal Hrusecky --- package/libs/openssl/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/package/libs/openssl/Makefile b/package/libs/openssl/Makefile index db5d740..faa2460 100644 --- a/package/libs/openssl/Makefile +++ b/package/libs/openssl/Makefile @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=openssl PKG_BASE:=1.0.2 -PKG_BUGFIX:=g +PKG_BUGFIX:=h PKG_VERSION:=$(PKG_BASE)$(PKG_BUGFIX) PKG_RELEASE:=1 PKG_USE_MIPS16:=0 @@ -22,7 +22,7 @@ PKG_SOURCE_URL:=http://www.openssl.org/source/ \ http://www.openssl.org/source/old/$(PKG_BASE)/ \ ftp://ftp.funet.fi/pub/crypt/mirrors/ftp.openssl.org/source \ ftp://ftp.sunet.se/pub/security/tools/net/openssl/source/ -PKG_MD5SUM:=b784b1b3907ce39abf4098702dade6365522a253ad1552e267a9a0e89594aa33 +PKG_MD5SUM:=9392e65072ce4b614c1392eefc1f23d0 PKG_LICENSE:=OpenSSL PKG_LICENSE_FILES:=LICENSE -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From post at lespocky.de Wed May 4 08:21:50 2016 From: post at lespocky.de (Alexander Dahl) Date: Wed, 04 May 2016 14:21:50 +0200 Subject: [OpenWrt-Devel] [PATCH] [package] openssl: Update to version 1.0.2h In-Reply-To: <20160504115327.GA2676@workbook.ipv6.hrusecky.net> References: <20160504115327.GA2676@workbook.ipv6.hrusecky.net> Message-ID: <32fa0d0d08bf9d0f5bdbbba25f17f339@idefix.lespocky.dyndns.org> Hei hei, Am 2016-05-04 13:53, schrieb Michal Hrusecky: > -PKG_MD5SUM:=b784b1b3907ce39abf4098702dade6365522a253ad1552e267a9a0e89594aa33 > +PKG_MD5SUM:=9392e65072ce4b614c1392eefc1f23d0 You replaced the sha256sum of openssl-1.0.2g.tar.gz with the md5sum of openssl-1.0.2h.tar.gz. Why the "downgrade" of the hash sum? FWIW: the sha256sum I found on https://openssl.org/source/ would be 1d4007e53aad94a5b2002fe045ee7bb0b3d98f1a47f8b2bc851dcd1c74332919 and is the same I computed locally. Greets Alex -- ?With the first link, the chain is forged. The first speech censured, the first thought forbidden, the first freedom denied, chains us all irrevocably.? (Jean-Luc Picard, quoting Judge Aaron Satie) *** GnuPG-FP: C28E E6B9 0263 95CF 8FAF 08FA 34AD CD00 7221 5CC6 *** _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From Michal.Hrusecky at nic.cz Wed May 4 08:38:36 2016 From: Michal.Hrusecky at nic.cz (Michal Hrusecky) Date: Wed, 4 May 2016 14:38:36 +0200 Subject: [OpenWrt-Devel] [PATCH] [package] openssl: Update to version 1.0.2h In-Reply-To: <32fa0d0d08bf9d0f5bdbbba25f17f339@idefix.lespocky.dyndns.org> References: <20160504115327.GA2676@workbook.ipv6.hrusecky.net> <32fa0d0d08bf9d0f5bdbbba25f17f339@idefix.lespocky.dyndns.org> Message-ID: <20160504123836.GQ3368@workbook.ipv6.hrusecky.net> Alexander Dahl - 14:21 4.05.16 wrote: > Hei hei, > > Am 2016-05-04 13:53, schrieb Michal Hrusecky: > > -PKG_MD5SUM:=b784b1b3907ce39abf4098702dade6365522a253ad1552e267a9a0e89594aa33 > > +PKG_MD5SUM:=9392e65072ce4b614c1392eefc1f23d0 > > You replaced the sha256sum of openssl-1.0.2g.tar.gz with the md5sum of > openssl-1.0.2h.tar.gz. Why the "downgrade" of the hash sum? Because the field says MD5 :-) > FWIW: the sha256sum I found on https://openssl.org/source/ would be > 1d4007e53aad94a5b2002fe045ee7bb0b3d98f1a47f8b2bc851dcd1c74332919 and is > the same I computed locally. If it works with sha256, I have no problem using that. _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From michal.hrusecky at nic.cz Wed May 4 08:38:46 2016 From: michal.hrusecky at nic.cz (Michal Hrusecky) Date: Wed, 4 May 2016 14:38:46 +0200 Subject: [OpenWrt-Devel] [PATCHv2] [package] openssl: Update to version 1.0.2h Message-ID: <20160504123846.GA31350@workbook.ipv6.hrusecky.net> Bump to the latest version, fixes several security issues: * CVE-2016-2107, CVE-2016-2105, CVE-2016-2106, CVE-2016-2109, CVE-2016-2176 Signed-off-by: Michal Hrusecky --- package/libs/openssl/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/package/libs/openssl/Makefile b/package/libs/openssl/Makefile index db5d740..faa2460 100644 --- a/package/libs/openssl/Makefile +++ b/package/libs/openssl/Makefile @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=openssl PKG_BASE:=1.0.2 -PKG_BUGFIX:=g +PKG_BUGFIX:=h PKG_VERSION:=$(PKG_BASE)$(PKG_BUGFIX) PKG_RELEASE:=1 PKG_USE_MIPS16:=0 @@ -22,7 +22,7 @@ PKG_SOURCE_URL:=http://www.openssl.org/source/ \ http://www.openssl.org/source/old/$(PKG_BASE)/ \ ftp://ftp.funet.fi/pub/crypt/mirrors/ftp.openssl.org/source \ ftp://ftp.sunet.se/pub/security/tools/net/openssl/source/ -PKG_MD5SUM:=b784b1b3907ce39abf4098702dade6365522a253ad1552e267a9a0e89594aa33 +PKG_MD5SUM:=1d4007e53aad94a5b2002fe045ee7bb0b3d98f1a47f8b2bc851dcd1c74332919 PKG_LICENSE:=OpenSSL PKG_LICENSE_FILES:=LICENSE -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From josua.mayer97 at gmail.com Wed May 4 08:42:53 2016 From: josua.mayer97 at gmail.com (Josua Mayer) Date: Wed, 4 May 2016 14:42:53 +0200 Subject: [OpenWrt-Devel] [PATCH v2 2/3] ext4_part_match: fix bug that prevented matching names In-Reply-To: <008501d1a213$a0a3e930$e1ebbb90$@codeaurora.org> References: <1461867621-4055-1-git-send-email-josua.mayer97@gmail.com> <1461867621-4055-2-git-send-email-josua.mayer97@gmail.com> <008501d1a213$a0a3e930$e1ebbb90$@codeaurora.org> Message-ID: <5729EE4D.5070204@gmail.com> Hi Ram, Thanks for your comments. Now it appears I misunderstood what the code is supposed to match. So if there is a PARTNAME= line, it can be matched. However on my system I dont have PARTNAME. Here a real-life sample: root at OpenWrt:/# cat /sys/block/mmcblk0/mmcblk0p3/uevent MAJOR=179 MINOR=3 DEVNAME=mmcblk0p3 DEVTYPE=partition What is partname and how can I set it? fdisk? filesystem label? br Josua Mayer Am 29.04.2016 um 14:35 schrieb Ram Chandra Jangir: > Thanks Josua Mayer. > > Devname and partname both are different. Devname is holding the device node(ex. mmcblkXpY) and given name(or partname) is the partition name(ex. rootfs or rootfs_data). > For below uevent sysfs entries, it tries to populate the device node(mmcblkXpY) in devname variable and tries to match the given name with the PARTNAME(buf will have this value("PARTNAME=rootfs_data") at n'th iteration). > If it is found then the loop will break, and we will get the given name's device node(/dev/mmcblkXpY) which will be mounted later. > > Example: > root at OpenWrt:/# cat /sys/block/mmcblk0/mmcblk0p3/uevent > MAJOR=179 > MINOR=3 > DEVNAME=mmcblk0p3 <-- device node: /dev/mmcblk0p3 > DEVTYPE=partition > PARTN=3 > PARTNAME=rootfs_data > > This is required, because the emmc card may have multiple partitions too. So our aim is to get the device node from the given name's uevent file. > > Thanks, > Ram > > -----Original Message----- > From: openwrt-devel [mailto:openwrt-devel-bounces at lists.openwrt.org] On Behalf Of josua.mayer97 at gmail.com > Sent: Thursday, April 28, 2016 11:50 PM > To: openwrt-devel at lists.openwrt.org > Cc: Josua Mayer > Subject: [OpenWrt-Devel] [PATCH v2 2/3] ext4_part_match: fix bug that prevented matching names > > From: Josua Mayer > > Actually use the populated devname variable to compare against given name, instead of the buf variable, which incidentally contains either: > MAJOR=xyz, MINOR=x, or DEVTYPE=partition, none of which ever match a name. > > Signed-off-by: Josua Mayer > --- > libfstools/ext4.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libfstools/ext4.c b/libfstools/ext4.c index f648aa8..b9401c3 100644 > --- a/libfstools/ext4.c > +++ b/libfstools/ext4.c > @@ -78,7 +78,7 @@ ext4_part_match(char *dev, char *name, char *filename) > continue; > } > /* Match partition name */ > - if (strstr(buf, name)) { > + if (strstr(devname, name)) { > ret = 0; > break; > } > -- > 2.6.6 > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From josua.mayer97 at gmail.com Wed May 4 08:45:07 2016 From: josua.mayer97 at gmail.com (josua.mayer97 at gmail.com) Date: Wed, 4 May 2016 14:45:07 +0200 Subject: [OpenWrt-Devel] [PATCH 1/2] mount_root: implement overlay= boot option Message-ID: <1462365908-6696-1-git-send-email-josua.mayer97@gmail.com> From: Josua Mayer This change adds code to handle a new option on cmdline: overlay= This is used to find the rootfs_data partition / disk when it has a non-standard name or location. It takes either the device node name, or the full path to the device node: i.e. /dev/mmcblk0p3 or mmcblk0p3 This option has precedence over the default name "rootfs_data", and extroot. Signed-off-by: Josua Mayer . --- mount_root.c | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/mount_root.c b/mount_root.c index 47a3409..446e3cc 100644 --- a/mount_root.c +++ b/mount_root.c @@ -33,6 +33,35 @@ start(int argc, char *argv[1]) if (!getenv("PREINIT")) return -1; + /* + * Check cmdline for a hint about overlay device + */ + if (!data) { + FILE *fp; + char buffer[100] = {0}; + + fp = fopen("/proc/cmdline", "r"); + while (!feof(fp)) { + if(fscanf(fp, "overlay=%s", buffer)) + break; + + fseek(fp, 1, SEEK_CUR); + } + fclose(fp); + + // overlay= argument was found + if (buffer[0]) { + // strip /dev/ prefix if any + int offset = 0; + if (strstr(buffer, "/dev/")) + offset = 5; + + // try to find the volume + ULOG_NOTE("Looking for overlay device given on commandline\n"); + data = volume_find(buffer + offset); + } + } + if (!data) { root = volume_find("rootfs"); volume_init(root); -- 2.6.6 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From josua.mayer97 at gmail.com Wed May 4 08:45:08 2016 From: josua.mayer97 at gmail.com (josua.mayer97 at gmail.com) Date: Wed, 4 May 2016 14:45:08 +0200 Subject: [OpenWrt-Devel] [PATCH 2/2] mount_root: Also handle new overlay= option in done() In-Reply-To: <1462365908-6696-1-git-send-email-josua.mayer97@gmail.com> References: <1462365908-6696-1-git-send-email-josua.mayer97@gmail.com> Message-ID: <1462365908-6696-2-git-send-email-josua.mayer97@gmail.com> From: Josua Mayer The done()-function is used both to initialize rootfs_data when there is no filesystem yet, but also to set ready-state on fresh filesystems. Make sure to also do that when a non-standard overlay device is specified. Signed-off-by: Josua Mayer --- mount_root.c | 33 ++++++++++++++++++++++++++++++++- 1 file changed, 32 insertions(+), 1 deletion(-) diff --git a/mount_root.c b/mount_root.c index 446e3cc..7084e3d 100644 --- a/mount_root.c +++ b/mount_root.c @@ -124,8 +124,39 @@ stop(int argc, char *argv[1]) static int done(int argc, char *argv[1]) { - struct volume *v = volume_find("rootfs_data"); + struct volume *v = NULL; + FILE *fp; + char buffer[100] = {0}; + /* + * First check if there is an overlay device hint in cmdline + */ + fp = fopen("/proc/cmdline", "r"); + while (!feof(fp)) { + if (fscanf(fp, "overlay=%s", buffer)) + break; + + fseek(fp, 1, SEEK_CUR); + } + fclose(fp); + if (buffer[0]) { + // strip /dev/ prefix if any + int offset = 0; + if(strstr(buffer, "/dev/")) + offset = 5; + + v = volume_find(buffer + offset); + } + + /* + * Now look for standard overlay device name + */ + if (!v) + v = volume_find("rootfs_data"); + + /* + * If no overlay device exists, then there is nothing to do here + */ if (!v) return -1; -- 2.6.6 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From josua.mayer97 at gmail.com Wed May 4 08:45:53 2016 From: josua.mayer97 at gmail.com (josua.mayer97 at gmail.com) Date: Wed, 4 May 2016 14:45:53 +0200 Subject: [OpenWrt-Devel] [PATCH v3 1/2] mount_root: implement overlay= boot option Message-ID: <1462365954-6758-1-git-send-email-josua.mayer97@gmail.com> From: Josua Mayer This change adds code to handle a new option on cmdline: overlay= This is used to find the rootfs_data partition / disk when it has a non-standard name or location. It takes either the device node name, or the full path to the device node: i.e. /dev/mmcblk0p3 or mmcblk0p3 This option has precedence over the default name "rootfs_data", and extroot. Signed-off-by: Josua Mayer . --- mount_root.c | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/mount_root.c b/mount_root.c index 47a3409..446e3cc 100644 --- a/mount_root.c +++ b/mount_root.c @@ -33,6 +33,35 @@ start(int argc, char *argv[1]) if (!getenv("PREINIT")) return -1; + /* + * Check cmdline for a hint about overlay device + */ + if (!data) { + FILE *fp; + char buffer[100] = {0}; + + fp = fopen("/proc/cmdline", "r"); + while (!feof(fp)) { + if(fscanf(fp, "overlay=%s", buffer)) + break; + + fseek(fp, 1, SEEK_CUR); + } + fclose(fp); + + // overlay= argument was found + if (buffer[0]) { + // strip /dev/ prefix if any + int offset = 0; + if (strstr(buffer, "/dev/")) + offset = 5; + + // try to find the volume + ULOG_NOTE("Looking for overlay device given on commandline\n"); + data = volume_find(buffer + offset); + } + } + if (!data) { root = volume_find("rootfs"); volume_init(root); -- 2.6.6 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From josua.mayer97 at gmail.com Wed May 4 08:45:54 2016 From: josua.mayer97 at gmail.com (josua.mayer97 at gmail.com) Date: Wed, 4 May 2016 14:45:54 +0200 Subject: [OpenWrt-Devel] [PATCH v3 2/2] mount_root: Also handle new overlay= option in done() In-Reply-To: <1462365954-6758-1-git-send-email-josua.mayer97@gmail.com> References: <1462365954-6758-1-git-send-email-josua.mayer97@gmail.com> Message-ID: <1462365954-6758-2-git-send-email-josua.mayer97@gmail.com> From: Josua Mayer The done()-function is used both to initialize rootfs_data when there is no filesystem yet, but also to set ready-state on fresh filesystems. Make sure to also do that when a non-standard overlay device is specified. Signed-off-by: Josua Mayer --- mount_root.c | 33 ++++++++++++++++++++++++++++++++- 1 file changed, 32 insertions(+), 1 deletion(-) diff --git a/mount_root.c b/mount_root.c index 446e3cc..7084e3d 100644 --- a/mount_root.c +++ b/mount_root.c @@ -124,8 +124,39 @@ stop(int argc, char *argv[1]) static int done(int argc, char *argv[1]) { - struct volume *v = volume_find("rootfs_data"); + struct volume *v = NULL; + FILE *fp; + char buffer[100] = {0}; + /* + * First check if there is an overlay device hint in cmdline + */ + fp = fopen("/proc/cmdline", "r"); + while (!feof(fp)) { + if (fscanf(fp, "overlay=%s", buffer)) + break; + + fseek(fp, 1, SEEK_CUR); + } + fclose(fp); + if (buffer[0]) { + // strip /dev/ prefix if any + int offset = 0; + if(strstr(buffer, "/dev/")) + offset = 5; + + v = volume_find(buffer + offset); + } + + /* + * Now look for standard overlay device name + */ + if (!v) + v = volume_find("rootfs_data"); + + /* + * If no overlay device exists, then there is nothing to do here + */ if (!v) return -1; -- 2.6.6 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From josua.mayer97 at gmail.com Wed May 4 08:49:30 2016 From: josua.mayer97 at gmail.com (Josua Mayer) Date: Wed, 4 May 2016 14:49:30 +0200 Subject: [OpenWrt-Devel] [PATCH v3 1/2] mount_root: implement overlay= boot option In-Reply-To: <1462365954-6758-1-git-send-email-josua.mayer97@gmail.com> References: <1462365954-6758-1-git-send-email-josua.mayer97@gmail.com> Message-ID: <5729EFDA.6060606@gmail.com> Hi everyone, please note that this patch is not final in that the code does not look for device-node-names, but for a partition name. But don't hesitate to comment anyway! Am 04.05.2016 um 14:45 schrieb josua.mayer97 at gmail.com: > From: Josua Mayer > > This change adds code to handle a new option on cmdline: overlay= > This is used to find the rootfs_data partition / disk when it has a > non-standard name or location. > > It takes either the device node name, or the full path to the device node: > i.e. /dev/mmcblk0p3 or mmcblk0p3 > > This option has precedence over the default name "rootfs_data", and extroot. > > Signed-off-by: Josua Mayer . > --- > mount_root.c | 29 +++++++++++++++++++++++++++++ > 1 file changed, 29 insertions(+) > > diff --git a/mount_root.c b/mount_root.c > index 47a3409..446e3cc 100644 > --- a/mount_root.c > +++ b/mount_root.c > @@ -33,6 +33,35 @@ start(int argc, char *argv[1]) > if (!getenv("PREINIT")) > return -1; > > + /* > + * Check cmdline for a hint about overlay device > + */ > + if (!data) { > + FILE *fp; > + char buffer[100] = {0}; > + > + fp = fopen("/proc/cmdline", "r"); > + while (!feof(fp)) { > + if(fscanf(fp, "overlay=%s", buffer)) > + break; > + > + fseek(fp, 1, SEEK_CUR); > + } > + fclose(fp); > + > + // overlay= argument was found > + if (buffer[0]) { > + // strip /dev/ prefix if any > + int offset = 0; > + if (strstr(buffer, "/dev/")) > + offset = 5; > + > + // try to find the volume > + ULOG_NOTE("Looking for overlay device given on commandline\n"); > + data = volume_find(buffer + offset); > + } > + } > + > if (!data) { > root = volume_find("rootfs"); > volume_init(root); > _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From ianchi74 at outlook.com Wed May 4 09:44:17 2016 From: ianchi74 at outlook.com (Adrian Panella) Date: Wed, 4 May 2016 08:44:17 -0500 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <0998F7CD-4F9A-46A3-A715-C56B03E946EB@gmail.com> References: <5179f6d1-283a-1b40-d717-2730c3408326@openwrt.org> <572907D0.8080700@einfach.org> <0998F7CD-4F9A-46A3-A715-C56B03E946EB@gmail.com> Message-ID: I'm a new comer to this community, and first experiencing with the use of OpenWrt both as firmware and developing it, so I don't feel much entitled to have a word here. But I find it is a great product and want to contribute to the project, so I'll share my perspective as someone who would like to join the boat. So far in my (very limited) experience porting OpenWrt to a new device I see some of the proposed changes very promising. I don't know if the best way is a rebranding or a v2, but in either case for me so far the two main aspects would be: + the possibility of doing pull requests, and if there is more active response to them (even if it is a rejection); much more like it seems to be in the feeds/packages area. + another aspect that would help a lot new comers like myself is better documentation. The current Wiki/Doc is incomplete and has a lot of mixture of information from old features which have been superseded or are outdated. Core services (like procd) are very briefly outlined. You really have to invest a lot of time to go thru the code base to understand the underlying picture. For documentation I find a platform more like Wikipedia, where changes can be tracked and discussions can take place, a great option. Thanks for the great work you've done so far! Regards, Adri?n -----Original Message----- From: openwrt-devel [mailto:openwrt-devel-bounces at lists.openwrt.org] On Behalf Of Rick Pannen Sent: mi?rcoles, 04 de mayo de 2016 04:01 a.m. To: Roman Yeryomin; Roman Yeryomin Cc: Bruno Randolf; OpenWrt Development List; Bruno Randolf; OpenWrt Development List Subject: Re: [OpenWrt-Devel] Introducing the LEDE project The only thing that seems to improve from my perspective is normal git pull requests instead of antiquated email patches. The name change and that 90's style website will only confuse the users. > Am 04.05.2016 um 00:50 schrieb Roman Yeryomin : > >> On 3 May 2016 at 23:19, Bruno Randolf wrote: >>> On 03/05/16 18:59, Jo-Philipp Wich wrote: >>> we'd like to introduce LEDE, a reboot of the OpenWrt community ... >>> Jo-Philipp Wich, >>> John Crispin, >>> Daniel Golle, >>> Felix Fietkau, >>> Hauke Mehrtens >>> John Crispin >>> Matthias Schiffer, >>> Steven Barth >> >> While a fresh start and a more open process is good move, given this >> list of supporters it sounds a bit ridiculous... who is left in the >> OpenWRT boat and why not do it as OpenWRT (V2 or whatever)??? > > Indeed. Looks like silent rebranding. Without public discussion of the > issues (and possible ways to fix them) in mailing list Same people, > rules and methods. > Could you elaborate more and explain how exactly LEDE is going to fix > the listed problems? And why it's not possible to fix them inside > existing project? > > > Regards, > Roman > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From xotic750 at gmail.com Wed May 4 11:40:08 2016 From: xotic750 at gmail.com (Graham Fairweather) Date: Wed, 4 May 2016 17:40:08 +0200 Subject: [OpenWrt-Devel] [PATCH 001/001] [brcm63xx] Display the correct detected CPU ID Message-ID: From: Graham Fairweather This patch fixes the logged detected CPU ID when an equivalent is used, like in the case where we have a bcm6369 and configuration for a bcm6368 is used. More info can be found at:https://forum.openwrt.org/viewtopic.php?id=64621https://github.com/Xotic750/openwrt/tree/fix_logged_cpu_id_bcm63xx Signed-off-by: Graham Fairweather --- target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch | 9 +++++++++ target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch | 9 +++++++++ 2 files changed, 18 insertions(+) diff --git a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch index 661abf6..23491aa 100644 --- a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch +++ b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch @@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu variant helper bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT; switch (bcm63xx_cpu_id) { +@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void) + bcm63xx_memory_size = detect_memory_size(); + + printk(KERN_INFO "Detected Broadcom 0x%04x CPU revision %02x\n", +- bcm63xx_cpu_id, bcm63xx_cpu_rev); ++ bcm63xx_cpu_variant, bcm63xx_cpu_rev); + printk(KERN_INFO "CPU frequency is %u MHz\n", + bcm63xx_cpu_freq / 1000000); + printk(KERN_INFO "%uMB of RAM installed\n", --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h @@ -19,6 +19,7 @@ diff --git a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch index 661abf6..23491aa 100644 --- a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch +++ b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch @@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu variant helper bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT; switch (bcm63xx_cpu_id) { +@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void) + bcm63xx_memory_size = detect_memory_size(); + + printk(KERN_INFO "Detected Broadcom 0x%04x CPU revision %02x\n", +- bcm63xx_cpu_id, bcm63xx_cpu_rev); ++ bcm63xx_cpu_variant, bcm63xx_cpu_rev); + printk(KERN_INFO "CPU frequency is %u MHz\n", + bcm63xx_cpu_freq / 1000000); + printk(KERN_INFO "%uMB of RAM installed\n", --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h @@ -19,6 +19,7 @@ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From karlp at tweak.net.au Wed May 4 12:13:30 2016 From: karlp at tweak.net.au (Karl Palsson) Date: Wed, 04 May 2016 16:13:30 -0000 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <5179f6d1-283a-1b40-d717-2730c3408326@openwrt.org> References: <5179f6d1-283a-1b40-d717-2730c3408326@openwrt.org> Message-ID: Jo-Philipp Wich wrote: > Hi, > > we'd like to introduce LEDE, a reboot of the OpenWrt community On a purely logistical note, is there any purpose in sending patches/pulls/bugs to _openwrt-devel_ any more? It sounds like there's effectively no-one left to read them. What about procd, fstools, libubox/libubus, (lib)uci, uhttpd, ustream, uclient, jsonpath? Some of those had only recently finally moved to git.openwrt.org after being held on nbd.name. Where are those projects going to be maintained? openwrt-devel? git.openwrt.org? Somewhere else? Cheers, Karl P -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP Digital Signature URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From kathy.giori at gmail.com Wed May 4 12:25:51 2016 From: kathy.giori at gmail.com (Kathy Giori) Date: Wed, 4 May 2016 09:25:51 -0700 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <5179f6d1-283a-1b40-d717-2730c3408326@openwrt.org> References: <5179f6d1-283a-1b40-d717-2730c3408326@openwrt.org> Message-ID: On Tue, May 3, 2016 at 10:59 AM, Jo-Philipp Wich wrote: > Hi, > > we'd like to introduce LEDE, a reboot of the OpenWrt community > . > > The project is founded as a spin-off of the OpenWrt project and shares > many of the same goals. While I appreciate the enthusiasm, I do not see why you cannot apply these same "principles" of openness and transparency to the OpenWrt project. Makes no sense to me to branch the project. That simply divides the resources in the community into fewer numbers working on each fork. Also wearing my hat within the prpl Foundation, which is funded by industry sponsorships that in turn provides financial support for OpenWrt, no one I have spoken to in prpl understands the reason for this spin-off either. It'll cause more confusion and inefficiency in industry. prpl will stick with OpenWrt, and I expect most companies who follow and/or contribute to OpenWrt will stick with it too. kathy _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From mcr at sandelman.ca Wed May 4 12:35:06 2016 From: mcr at sandelman.ca (Michael Richardson) Date: Wed, 04 May 2016 12:35:06 -0400 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <572907D0.8080700@einfach.org> References: <5179f6d1-283a-1b40-d717-2730c3408326@openwrt.org> <572907D0.8080700@einfach.org> Message-ID: <24909.1462379706@obiwan.sandelman.ca> Bruno Randolf wrote: > On 03/05/16 18:59, Jo-Philipp Wich wrote: >> we'd like to introduce LEDE, a reboot of the OpenWrt community >> ... >> Jo-Philipp Wich, >> John Crispin, >> Daniel Golle, >> Felix Fietkau, >> Hauke Mehrtens >> John Crispin >> Matthias Schiffer, >> Steven Barth > While a fresh start and a more open process is good move, given this > list of supporters it sounds a bit ridiculous... who is left in the > OpenWRT boat and why not do it as OpenWRT (V2 or whatever)??? I read the rest of the thread before replying. I understand the need for a reboot and rename. I also don't know who is left, or is being pushed out, or... maybe they left already and didn't leave the keys? Given the FCC-inspired lockdowns, I wonder if one has interest in GPLv3-like statements about keys. I don't much like the name LEDE; it will be hard to explain to end users. Reminds me too much of: https://en.wikipedia.org/wiki/Leadership_in_Energy_and_Environmental_Design and http://www.leedsunited.com/ Maybe do an Apple on the case lEDE, or leDE (en francais!) or something. asciidoc for the web site content is okay; maybe someone will contribute a snazier style sheet (but not me; I'm pathetic at CSS too) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 464 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From psidhu at gateworks.com Wed May 4 13:28:16 2016 From: psidhu at gateworks.com (Pushpal Sidhu) Date: Wed, 4 May 2016 10:28:16 -0700 Subject: [OpenWrt-Devel] [PATCH v2] image.mk: Create a manifest file of installed packages as a build artifact Message-ID: <1462382896-15469-1-git-send-email-psidhu@gateworks.com> A few linux BSP's create a manifest file of installed packages for a given target in order to help them understand exactly what's on their images. Create one for OpenWrt as well as a build artifact since many users have an affinity to prune down on packages to save valuable flash space. Signed-off-by: Pushpal Sidhu --- include/image.mk | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/include/image.mk b/include/image.mk index bc383e6..2606c77 100644 --- a/include/image.mk +++ b/include/image.mk @@ -280,6 +280,13 @@ define Image/mkfs/prepare $(call Image/mkfs/prepare/default) endef +define Image/Manifest + $(STAGING_DIR_HOST)/bin/opkg \ + --offline-root $(TARGET_DIR) \ + --add-arch all:100 \ + --add-arch $(if $(ARCH_PACKAGES),$(ARCH_PACKAGES),$(BOARD)):200 list-installed > \ + $(BIN_DIR)/$(IMG_PREFIX)$(if $(PROFILE_SANITIZED),-$(PROFILE_SANITIZED)).manifest +endef define Image/Checksum ( cd ${BIN_DIR} ; \ @@ -597,6 +604,7 @@ define BuildImage $(call Image/Build,$(fs)) ) $(call Image/mkfs/ubifs) + $(call Image/Manifest) $(call Image/Checksum,md5sum --binary,md5sums) $(call Image/Checksum,openssl dgst -sha256,sha256sums) -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From leroi.lists at gmail.com Wed May 4 13:50:29 2016 From: leroi.lists at gmail.com (Roman Yeryomin) Date: Wed, 4 May 2016 20:50:29 +0300 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: References: <5179f6d1-283a-1b40-d717-2730c3408326@openwrt.org> Message-ID: On 4 May 2016 at 19:25, Kathy Giori wrote: > On Tue, May 3, 2016 at 10:59 AM, Jo-Philipp Wich wrote: >> Hi, >> >> we'd like to introduce LEDE, a reboot of the OpenWrt community >> . >> >> The project is founded as a spin-off of the OpenWrt project and shares >> many of the same goals. > > While I appreciate the enthusiasm, I do not see why you cannot apply > these same "principles" of openness and transparency to the OpenWrt > project. Makes no sense to me to branch the project. That simply > divides the resources in the community into fewer numbers working on > each fork. Exactly, tearing down the project and community without any real explanations (and plans to solve the stated issues) is just wrong. > Also wearing my hat within the prpl Foundation, which is funded by > industry sponsorships that in turn provides financial support for > OpenWrt, no one I have spoken to in prpl understands the reason for > this spin-off either. It'll cause more confusion and inefficiency in > industry. prpl will stick with OpenWrt, and I expect most companies > who follow and/or contribute to OpenWrt will stick with it too. > > kathy > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From luizluca at gmail.com Wed May 4 14:35:23 2016 From: luizluca at gmail.com (Luiz Angelo Daros de Luca) Date: Wed, 04 May 2016 18:35:23 +0000 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: References: <5179f6d1-283a-1b40-d717-2730c3408326@openwrt.org> Message-ID: It is really strange that the decision to create a new project was so opaque when it was motivated to be a more "transparent project". They could've started to be more transparent already with the decision to create a new project. Maybe the answer for the need of an external reboot might be not in the names that jumped into but on those left behind. Maybe it was easier to create a new project than to boot out the problems. My 2 cents, Em qua, 4 de mai de 2016 ?s 14:50, Roman Yeryomin escreveu: > On 4 May 2016 at 19:25, Kathy Giori wrote: > > On Tue, May 3, 2016 at 10:59 AM, Jo-Philipp Wich > wrote: > >> Hi, > >> > >> we'd like to introduce LEDE, a reboot of the OpenWrt community > >> . > >> > >> The project is founded as a spin-off of the OpenWrt project and shares > >> many of the same goals. > > > > While I appreciate the enthusiasm, I do not see why you cannot apply > > these same "principles" of openness and transparency to the OpenWrt > > project. Makes no sense to me to branch the project. That simply > > divides the resources in the community into fewer numbers working on > > each fork. > > Exactly, tearing down the project and community without any real > explanations (and plans to solve the stated issues) is just wrong. > > > Also wearing my hat within the prpl Foundation, which is funded by > > industry sponsorships that in turn provides financial support for > > OpenWrt, no one I have spoken to in prpl understands the reason for > > this spin-off either. It'll cause more confusion and inefficiency in > > industry. prpl will stick with OpenWrt, and I expect most companies > > who follow and/or contribute to OpenWrt will stick with it too. > > > > kathy > > _______________________________________________ > > openwrt-devel mailing list > > openwrt-devel at lists.openwrt.org > > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > -- Luiz Angelo Daros de Luca luizluca at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From leroi.lists at gmail.com Wed May 4 14:57:26 2016 From: leroi.lists at gmail.com (Roman Yeryomin) Date: Wed, 4 May 2016 21:57:26 +0300 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: References: <5179f6d1-283a-1b40-d717-2730c3408326@openwrt.org> Message-ID: On 4 May 2016 at 21:35, Luiz Angelo Daros de Luca wrote: > It is really strange that the decision to create a new project was so opaque > when it was motivated to be a more "transparent project". > They could've started to be more transparent already with the decision to > create a new project. > > Maybe the answer for the need of an external reboot might be not in the > names that jumped into but on those left behind. > Maybe it was easier to create a new project than to boot out the problems. Well, like you said yourself, why they didn't start discussing the problems (and possible solutions) in open space then? Then the reasons would be more or less clear. But now it seems that community will be confused a lot. At least I'm completely confused. > My 2 cents, > > Em qua, 4 de mai de 2016 ?s 14:50, Roman Yeryomin > escreveu: >> >> On 4 May 2016 at 19:25, Kathy Giori wrote: >> > On Tue, May 3, 2016 at 10:59 AM, Jo-Philipp Wich >> > wrote: >> >> Hi, >> >> >> >> we'd like to introduce LEDE, a reboot of the OpenWrt community >> >> . >> >> >> >> The project is founded as a spin-off of the OpenWrt project and shares >> >> many of the same goals. >> > >> > While I appreciate the enthusiasm, I do not see why you cannot apply >> > these same "principles" of openness and transparency to the OpenWrt >> > project. Makes no sense to me to branch the project. That simply >> > divides the resources in the community into fewer numbers working on >> > each fork. >> >> Exactly, tearing down the project and community without any real >> explanations (and plans to solve the stated issues) is just wrong. >> >> > Also wearing my hat within the prpl Foundation, which is funded by >> > industry sponsorships that in turn provides financial support for >> > OpenWrt, no one I have spoken to in prpl understands the reason for >> > this spin-off either. It'll cause more confusion and inefficiency in >> > industry. prpl will stick with OpenWrt, and I expect most companies >> > who follow and/or contribute to OpenWrt will stick with it too. >> > >> > kathy >> > _______________________________________________ >> > openwrt-devel mailing list >> > openwrt-devel at lists.openwrt.org >> > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >> _______________________________________________ >> openwrt-devel mailing list >> openwrt-devel at lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > > -- > > Luiz Angelo Daros de Luca > luizluca at gmail.com _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From david at lang.hm Wed May 4 15:04:47 2016 From: david at lang.hm (David Lang) Date: Wed, 4 May 2016 12:04:47 -0700 (PDT) Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: References: <5179f6d1-283a-1b40-d717-2730c3408326@openwrt.org> Message-ID: It's not unusual for developers who disagree with project management issues to fork a project. I am also interested in who is left in OpenWRT and what their viewpoint is. Have the developers who are founding LEDE given up their commit privileges in OpenWRT? or are they going to be workting a bit in both for a while? It will take time to see what effect this is really going to end up having. It could be a permanent fork, it could be a replacement for OpenWRT, it could be a dead end, and it could be something that ends up merging back in later. It's clear that the issues are management, not technical. David Lang On Wed, 4 May 2016, Luiz Angelo Daros de Luca wrote: > It is really strange that the decision to create a new project was so > opaque when it was motivated to be a more "transparent project". > They could've started to be more transparent already with the decision to > create a new project. > > Maybe the answer for the need of an external reboot might be not in the > names that jumped into but on those left behind. > Maybe it was easier to create a new project than to boot out the problems. > > My 2 cents, > > Em qua, 4 de mai de 2016 ?s 14:50, Roman Yeryomin > escreveu: > >> On 4 May 2016 at 19:25, Kathy Giori wrote: >>> On Tue, May 3, 2016 at 10:59 AM, Jo-Philipp Wich >> wrote: >>>> Hi, >>>> >>>> we'd like to introduce LEDE, a reboot of the OpenWrt community >>>> . >>>> >>>> The project is founded as a spin-off of the OpenWrt project and shares >>>> many of the same goals. >>> >>> While I appreciate the enthusiasm, I do not see why you cannot apply >>> these same "principles" of openness and transparency to the OpenWrt >>> project. Makes no sense to me to branch the project. That simply >>> divides the resources in the community into fewer numbers working on >>> each fork. >> >> Exactly, tearing down the project and community without any real >> explanations (and plans to solve the stated issues) is just wrong. >> >>> Also wearing my hat within the prpl Foundation, which is funded by >>> industry sponsorships that in turn provides financial support for >>> OpenWrt, no one I have spoken to in prpl understands the reason for >>> this spin-off either. It'll cause more confusion and inefficiency in >>> industry. prpl will stick with OpenWrt, and I expect most companies >>> who follow and/or contribute to OpenWrt will stick with it too. >>> >>> kathy >>> _______________________________________________ >>> openwrt-devel mailing list >>> openwrt-devel at lists.openwrt.org >>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >> _______________________________________________ >> openwrt-devel mailing list >> openwrt-devel at lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >> > -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From josua.mayer97 at gmail.com Wed May 4 15:24:25 2016 From: josua.mayer97 at gmail.com (josua.mayer97 at gmail.com) Date: Wed, 4 May 2016 21:24:25 +0200 Subject: [OpenWrt-Devel] [PATCH v4 1/4] mvebu: add squashfs image type to MMCProfile Message-ID: <1462389868-18371-1-git-send-email-josua.mayer97@gmail.com> From: Josua Mayer Added gen_mvebu_sdcard_img.sh to create bootable sdcard images. It takes the bootloader and partition images to create a bootable sdcard image. Partition Layout: p1: fat32: for kernel, dtb and boot config files if any p2: squashfs: for openwrt This change is developed for the Clearfog, but should work on all A38x SoCs that can boot from mmc. Signed-off-by: Josua Mayer --- target/linux/mvebu/image/Makefile | 16 ++++ target/linux/mvebu/image/gen_mvebu_sdcard_img.sh | 100 +++++++++++++++++++++++ tools/Makefile | 1 + 3 files changed, 117 insertions(+) create mode 100755 target/linux/mvebu/image/gen_mvebu_sdcard_img.sh diff --git a/target/linux/mvebu/image/Makefile b/target/linux/mvebu/image/Makefile index cb73c3b..fc5fded 100644 --- a/target/linux/mvebu/image/Makefile +++ b/target/linux/mvebu/image/Makefile @@ -107,6 +107,9 @@ define MMCProfile ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),) $(call Image/Build/Profile,$(1)/Initramfs) endif + ifneq ($(CONFIG_TARGET_ROOTFS_SQUASHFS),) + $(call Image/Build/squashfs) + endif endef define Image/Build/Profile/$(1)/Initramfs @@ -114,6 +117,19 @@ define MMCProfile cp $(KDIR)/uImage-initramfs-$(2) $(BIN_DIR)/$(IMG_PREFIX)-$(2)-initramfs endef + define Image/Build/Profile/$(1)/squashfs + $(call prepare_generic_squashfs,$(KDIR)/root.squashfs) + cp $(KDIR)/root.squashfs $(BIN_DIR)/$(IMG_PREFIX)-$(2)-root.squashfs + rm -f $(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32 + mkfs.fat -C $(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32 $(shell echo $$((4*1024)) # 4MB) + mcopy -i $(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32 $(KDIR)/zImage :: + mcopy -i $(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32 $(DTS_DIR)/$(2).dtb :: + ./gen_mvebu_sdcard_img.sh "$(BIN_DIR)/$(IMG_PREFIX)-$(2)-squashfs-sdcard.img" \ + "$(BIN_DIR)/uboot-mvebu-clearfog/openwrt-mvebu-clearfog-u-boot-spl.kwb" \ + c "$(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32" \ + 83 "$(BIN_DIR)/$(IMG_PREFIX)-$(2)-root.squashfs" + endef + PROFILES_LIST += $(1) endef diff --git a/target/linux/mvebu/image/gen_mvebu_sdcard_img.sh b/target/linux/mvebu/image/gen_mvebu_sdcard_img.sh new file mode 100755 index 0000000..88d017a --- /dev/null +++ b/target/linux/mvebu/image/gen_mvebu_sdcard_img.sh @@ -0,0 +1,100 @@ +#!/bin/bash -x +# +# Copyright (C) 2016 Josua Mayer +# +# 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., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. +# + +usage() { + echo "$0 [ ]?" +} + +# always require first 2 arguments +# then in pairs up to 8 more for a total of up to 4 partitions +if [ $# -lt 2 ] || [ $# -gt 10 ] || [ $((($#-2)%2)) -ne 0 ]; then + usage + exit 1 +fi + +# static settings +SDCARD_HEADS=16 +SDCARD_SECTORS=63 +SDCARD_ALIGNMENT=4096 + +# parameters +OUTFILE="$1" +BOOTLOADER="$2" +# up to 4 partitions +# when calculating size of images in Kilobytes, NEVER round down! +PART1_TYPE=$3 +PART1_IMG="$4" +PART1_SIZE=$((($(stat --print="%s" "$PART1_IMG")+1023)/1024))K +PART2_TYPE=$5 +PART2_IMG="$6" +PART2_SIZE=$((($(stat --print="%s" "$PART2_IMG")+1023)/1024))K +PART3_TYPE=$7 +PART3_IMG="$8" +PART3_SIZE=$((($(stat --print="%s" "$PART3_IMG")+1023)/1024))K +PART4_TYPE=$9 +PART4_IMG="${10}" +PART4_SIZE=$((($(stat --print="%s" "$PART4_IMG")+1023)/1024))K + +# So how many partitions were given? +numparts=$((($#-2)/2)) +case $numparts in + 0) + set `ptgen -o "$OUTFILE" \ + -h $SDCARD_HEADS -s $SDCARD_SECTORS -l $SDCARD_ALIGNMENT` + dd of="$OUTFILE" if="$BOOTLOADER" bs=512 seek=1 conv=notrunc + ;; + 1) + set `ptgen -o "$OUTFILE" \ + -h $SDCARD_HEADS -s $SDCARD_SECTORS -l $SDCARD_ALIGNMENT \ + -t $PART1_TYPE -p $PART1_SIZE` + dd of="$OUTFILE" if="$PART1_IMG" bs=512 seek=$(($1/512)) conv=notrunc + ;; + 2) + set `ptgen -o "$OUTFILE" \ + -h $SDCARD_HEADS -s $SDCARD_SECTORS -l $SDCARD_ALIGNMENT \ + -t $PART1_TYPE -p $PART1_SIZE \ + -t $PART2_TYPE -p $PART2_SIZE` + dd of="$OUTFILE" if="$BOOTLOADER" bs=512 seek=1 conv=notrunc + dd of="$OUTFILE" if="$PART1_IMG" bs=512 seek=$(($1/512)) conv=notrunc + dd of="$OUTFILE" if="$PART2_IMG" bs=512 seek=$(($2/512)) conv=notrunc + ;; + 3) + set `ptgen -o "$OUTFILE" \ + -h $SDCARD_HEADS -s $SDCARD_SECTORS -l $SDCARD_ALIGNMENT \ + -t $PART1_TYPE -p $PART1_SIZE \ + -t $PART2_TYPE -p $PART2_SIZE \ + -t $PART3_TYPE -p $PART3_SIZE` + dd of="$OUTFILE" if="$BOOTLOADER" bs=512 seek=1 conv=notrunc + dd of="$OUTFILE" if="$PART1_IMG" bs=512 seek=$(($1/512)) conv=notrunc + dd of="$OUTFILE" if="$PART2_IMG" bs=512 seek=$(($2/512)) conv=notrunc + dd of="$OUTFILE" if="$PART3_IMG" bs=512 seek=$(($3/512)) conv=notrunc + ;; + 4) + set `ptgen -o "$OUTFILE" \ + -h $SDCARD_HEADS -s $SDCARD_SECTORS -l $SDCARD_ALIGNMENT \ + -t $PART1_TYPE -p $PART1_SIZE \ + -t $PART2_TYPE -p $PART2_SIZE \ + -t $PART3_TYPE -p $PART3_SIZE \ + -t $PART4_TYPE -p $PART4_SIZE` + dd of="$OUTFILE" if="$BOOTLOADER" bs=512 seek=1 conv=notrunc + dd of="$OUTFILE" if="$PART1_IMG" bs=512 seek=$(($1/512)) conv=notrunc + dd of="$OUTFILE" if="$PART2_IMG" bs=512 seek=$(($2/512)) conv=notrunc + dd of="$OUTFILE" if="$PART3_IMG" bs=512 seek=$(($3/512)) conv=notrunc + dd of="$OUTFILE" if="$PART4_IMG" bs=512 seek=$(($4/512)) conv=notrunc +esac diff --git a/tools/Makefile b/tools/Makefile index 187655e..9a08573 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -38,6 +38,7 @@ tools-$(CONFIG_TARGET_x86) += qemu tools-$(CONFIG_TARGET_mxs) += elftosb sdimage tools-$(CONFIG_TARGET_brcm2708)$(CONFIG_TARGET_sunxi)$(CONFIG_TARGET_mxs) += mtools dosfstools tools-$(CONFIG_TARGET_ar71xx) += lzma-old squashfs +tools-$(CONFIG_TARGET_mvebu) += squashfs dosfstools tools-y += lzma squashfs4 tools-$(BUILD_B43_TOOLS) += b43-tools tools-$(BUILD_PPL_CLOOG) += ppl cloog -- 2.6.6 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From josua.mayer97 at gmail.com Wed May 4 15:24:26 2016 From: josua.mayer97 at gmail.com (josua.mayer97 at gmail.com) Date: Wed, 4 May 2016 21:24:26 +0200 Subject: [OpenWrt-Devel] [PATCH v4 2/4] mvebu: create target 'generic' for current boards In-Reply-To: <1462389868-18371-1-git-send-email-josua.mayer97@gmail.com> References: <1462389868-18371-1-git-send-email-josua.mayer97@gmail.com> Message-ID: <1462389868-18371-2-git-send-email-josua.mayer97@gmail.com> From: Josua Mayer This makes room to add other targets. Signed-off-by: Josua Mayer --- target/linux/mvebu/generic/profiles/000-Default.mk | 26 ++++++ target/linux/mvebu/generic/profiles/globalscale.mk | 21 +++++ target/linux/mvebu/generic/profiles/linksys.mk | 85 +++++++++++++++++++ target/linux/mvebu/generic/profiles/marvell.mk | 95 ++++++++++++++++++++++ target/linux/mvebu/generic/profiles/plathome.mk | 21 +++++ target/linux/mvebu/generic/profiles/solidrun.mk | 21 +++++ target/linux/mvebu/generic/target.mk | 6 ++ target/linux/mvebu/profiles/000-Default.mk | 26 ------ target/linux/mvebu/profiles/globalscale.mk | 21 ----- target/linux/mvebu/profiles/linksys.mk | 85 ------------------- target/linux/mvebu/profiles/marvell.mk | 95 ---------------------- target/linux/mvebu/profiles/plathome.mk | 21 ----- target/linux/mvebu/profiles/solidrun.mk | 21 ----- 13 files changed, 275 insertions(+), 269 deletions(-) create mode 100644 target/linux/mvebu/generic/profiles/000-Default.mk create mode 100644 target/linux/mvebu/generic/profiles/globalscale.mk create mode 100644 target/linux/mvebu/generic/profiles/linksys.mk create mode 100644 target/linux/mvebu/generic/profiles/marvell.mk create mode 100644 target/linux/mvebu/generic/profiles/plathome.mk create mode 100644 target/linux/mvebu/generic/profiles/solidrun.mk create mode 100644 target/linux/mvebu/generic/target.mk delete mode 100644 target/linux/mvebu/profiles/000-Default.mk delete mode 100644 target/linux/mvebu/profiles/globalscale.mk delete mode 100644 target/linux/mvebu/profiles/linksys.mk delete mode 100644 target/linux/mvebu/profiles/marvell.mk delete mode 100644 target/linux/mvebu/profiles/plathome.mk delete mode 100644 target/linux/mvebu/profiles/solidrun.mk diff --git a/target/linux/mvebu/generic/profiles/000-Default.mk b/target/linux/mvebu/generic/profiles/000-Default.mk new file mode 100644 index 0000000..5660836 --- /dev/null +++ b/target/linux/mvebu/generic/profiles/000-Default.mk @@ -0,0 +1,26 @@ +# +# Copyright (C) 2015 OpenWrt.org +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# + +define Profile/Default + NAME:=Default Profile (all drivers) + PACKAGES:= \ + kmod-mmc kmod-mvsdio swconfig \ + kmod-usb2 kmod-usb3 kmod-usb-storage \ + kmod-i2c-core kmod-i2c-mv64xxx \ + kmod-ata-core kmod-ata-marvell-sata \ + kmod-rtc-marvell kmod-thermal-armada \ + kmod-gpio-button-hotplug kmod-hwmon-tmp421 \ + kmod-hwmon-pwmfan kmod-leds-tlc59116 \ + kmod-ledtrig-usbdev kmod-mwlwifi wpad-mini \ + kmod-ata-mvebu-ahci +endef + +define Profile/Default/Description + Default package set compatible with most boards. +endef + +$(eval $(call Profile,Default)) diff --git a/target/linux/mvebu/generic/profiles/globalscale.mk b/target/linux/mvebu/generic/profiles/globalscale.mk new file mode 100644 index 0000000..7938c35 --- /dev/null +++ b/target/linux/mvebu/generic/profiles/globalscale.mk @@ -0,0 +1,21 @@ +# +# Copyright (C) 2015 OpenWrt.org +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# + +define Profile/Mirabox + NAME:=Globalscale Mirabox + PACKAGES:= \ + kmod-usb3 kmod-usb-storage \ + kmod-i2c-core kmod-i2c-mv64xxx \ + kmod-rtc-marvell kmod-thermal-armada \ + kmod-gpio-button-hotplug kmod-mmc kmod-mvsdio +endef + +define Profile/Mirabox/Description + Package set compatible with the Globalscale Mirabox. +endef + +$(eval $(call Profile,Mirabox)) diff --git a/target/linux/mvebu/generic/profiles/linksys.mk b/target/linux/mvebu/generic/profiles/linksys.mk new file mode 100644 index 0000000..9c954bd --- /dev/null +++ b/target/linux/mvebu/generic/profiles/linksys.mk @@ -0,0 +1,85 @@ +# +# Copyright (C) 2013-2015 OpenWrt.org +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# + +define Profile/Caiman + NAME:=Linksys WRT1200AC (Caiman) + PACKAGES:= \ + kmod-usb2 kmod-usb3 kmod-usb-storage \ + kmod-i2c-core kmod-i2c-mv64xxx \ + kmod-ata-core kmod-ata-mvebu-ahci \ + kmod-rtc-armada38x kmod-thermal-armada \ + kmod-gpio-button-hotplug kmod-hwmon-tmp421 \ + kmod-leds-pca963x \ + kmod-ledtrig-usbdev kmod-mwlwifi wpad-mini \ + swconfig +endef + +define Profile/Caiman/Description + Package set compatible with the Linksys WRT1200AC (Caiman). +endef + +$(eval $(call Profile,Caiman)) + + +define Profile/Cobra + NAME:=Linksys WRT1900ACv2 (Cobra) + PACKAGES:= \ + kmod-usb2 kmod-usb3 kmod-usb-storage \ + kmod-i2c-core kmod-i2c-mv64xxx \ + kmod-ata-core kmod-ata-mvebu-ahci \ + kmod-rtc-armada38x kmod-thermal-armada \ + kmod-gpio-button-hotplug kmod-hwmon-tmp421 \ + kmod-leds-pca963x \ + kmod-ledtrig-usbdev kmod-mwlwifi wpad-mini \ + swconfig +endef + +define Profile/Cobra/Description + Package set compatible with the Linksys WRT1900AC (Cobra). +endef + +$(eval $(call Profile,Cobra)) + + +define Profile/Mamba + NAME:=Linksys WRT1900AC (Mamba) + PACKAGES:= \ + kmod-usb2 kmod-usb3 kmod-usb-storage \ + kmod-i2c-core kmod-i2c-mv64xxx \ + kmod-ata-core kmod-ata-marvell-sata \ + kmod-rtc-marvell kmod-thermal-armada \ + kmod-gpio-button-hotplug kmod-hwmon-tmp421 \ + kmod-hwmon-pwmfan kmod-leds-tlc591xx \ + kmod-ledtrig-usbdev kmod-mwlwifi wpad-mini \ + swconfig +endef + +define Profile/Mamba/Description + Package set compatible with the Linksys WRT1900AC (Mamba). +endef + +$(eval $(call Profile,Mamba)) + + +define Profile/Shelby + NAME:=Linksys WRT1900ACS (Shelby) + PACKAGES:= \ + kmod-usb2 kmod-usb3 kmod-usb-storage \ + kmod-i2c-core kmod-i2c-mv64xxx \ + kmod-ata-core kmod-ata-mvebu-ahci \ + kmod-rtc-armada38x kmod-thermal-armada \ + kmod-gpio-button-hotplug kmod-hwmon-tmp421 \ + kmod-leds-pca963x \ + kmod-ledtrig-usbdev kmod-mwlwifi wpad-mini \ + swconfig +endef + +define Profile/Shelby/Description + Package set compatible with the Linksys WRT1900ACS (Shelby). +endef + +$(eval $(call Profile,Shelby)) diff --git a/target/linux/mvebu/generic/profiles/marvell.mk b/target/linux/mvebu/generic/profiles/marvell.mk new file mode 100644 index 0000000..e8ca9bd --- /dev/null +++ b/target/linux/mvebu/generic/profiles/marvell.mk @@ -0,0 +1,95 @@ +# +# Copyright (C) 2013-2015 OpenWrt.org +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# + +define Profile/370-DB + NAME:=Marvell Armada 370 DB (DB-88F6710-BP-DDR3) + PACKAGES:= \ + kmod-mmc kmod-mvsdio kmod-usb2 kmod-usb-storage \ + kmod-i2c-core kmod-i2c-mv64xxx \ + kmod-ata-core kmod-ata-marvell-sata \ + kmod-rtc-marvell kmod-thermal-armada +endef + +define Profile/370-DB/Description + Package set compatible with the Armada 370 evaluation board (DB-88F6710-BP-DDR3). +endef + +$(eval $(call Profile,370-DB)) + +define Profile/370-RD + NAME:=Marvell Armada 370 RD (RD-88F6710-A1) + PACKAGES:= \ + kmod-mmc kmod-mvsdio kmod-usb2 kmod-usb-storage \ + kmod-i2c-core kmod-i2c-mv64xxx \ + kmod-ata-core kmod-ata-marvell-sata \ + kmod-rtc-marvell kmod-thermal-armada +endef + +define Profile/370-RD/Description + Package set compatible with the Armada 370 reference design board (RD-88F6710-A1). +endef + +$(eval $(call Profile,370-RD)) + +define Profile/385-RD + NAME:=Marvell Armada 385 RD (RD-88F6820-AP) + PACKAGES:= \ + kmod-mmc kmod-mvsdio kmod-usb3 kmod-usb-storage \ + kmod-i2c-core kmod-i2c-mv64xxx \ + kmod-thermal-armada +endef + +define Profile/385-RD/Description + Package set compatible with the Armada 385 reference design board (RD-88F6820-AP). +endef + +$(eval $(call Profile,385-RD)) + +define Profile/385-DB-AP + NAME:=Marvell Armada 385 DB AP (DB-88F6820-AP) + PACKAGES:= \ + kmod-usb3 kmod-usb-storage \ + kmod-i2c-core kmod-i2c-mv64xxx \ + kmod-ata-core kmod-ata-marvell-sata \ + kmod-thermal-armada +endef + +define Profile/385-DB-AP/Description + Package set compatible with the Armada 385 access point development board (DB-88F6820-AP). +endef + +$(eval $(call Profile,385-DB-AP)) + +define Profile/XP-DB + NAME:=Marvell Armada XP DB (DB-78460-BP) + PACKAGES:= \ + kmod-mmc kmod-mvsdio kmod-usb2 kmod-usb-storage \ + kmod-i2c-core kmod-i2c-mv64xxx \ + kmod-ata-core kmod-ata-marvell-sata \ + kmod-rtc-marvell kmod-thermal-armada +endef + +define Profile/XP-DB/Description + Package set compatible with the Marvell Armada XP evaluation board (DB-78460-BP). +endef + +$(eval $(call Profile,XP-DB)) + +define Profile/XP-GP + NAME:=Marvell Armada XP GP (DB-MV784MP-GP) + PACKAGES:= \ + kmod-mmc kmod-mvsdio kmod-usb2 kmod-usb-storage \ + kmod-i2c-core kmod-i2c-mv64xxx \ + kmod-ata-core kmod-ata-marvell-sata \ + kmod-rtc-marvell kmod-thermal-armada +endef + +define Profile/XP-GP/Description + Package set compatible with the Armada XP development board (DB-MV784MP-GP). +endef + +$(eval $(call Profile,XP-GP)) diff --git a/target/linux/mvebu/generic/profiles/plathome.mk b/target/linux/mvebu/generic/profiles/plathome.mk new file mode 100644 index 0000000..63cdb71 --- /dev/null +++ b/target/linux/mvebu/generic/profiles/plathome.mk @@ -0,0 +1,21 @@ +# +# Copyright (C) 2015 OpenWrt.org +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# + +define Profile/OpenBlocks-AX-3-4 + NAME:=Plat'Home OpenBlocks AX3 + PACKAGES:= \ + kmod-usb2 kmod-usb-storage \ + kmod-i2c-core kmod-i2c-mv64xxx \ + kmod-ata-core kmod-ata-marvell-sata \ + kmod-rtc-marvell kmod-thermal-armada +endef + +define Profile/OpenBlocks-AX-3-4/Description + Package set compatible with the Plat'Home OpenBlocks AX3. +endef + +$(eval $(call Profile,OpenBlocks-AX-3-4)) diff --git a/target/linux/mvebu/generic/profiles/solidrun.mk b/target/linux/mvebu/generic/profiles/solidrun.mk new file mode 100644 index 0000000..5aa61e2 --- /dev/null +++ b/target/linux/mvebu/generic/profiles/solidrun.mk @@ -0,0 +1,21 @@ +# +# Copyright (C) 2016 OpenWrt.org +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# + +define Profile/Solidrun-Clearfog-A1 + NAME:=SolidRun ClearFog A1 board + PACKAGES:= \ + kmod-usb3 kmod-usb2 kmod-usb-storage \ + kmod-of-i2c kmod-i2c-core kmod-i2c-mv64xxx \ + kmod-ata-core kmod-ata-marvell-sata \ + kmod-thermal-armada kmod-rtc-marvell +endef + +define Profile/Solidrun-Clearfog-A1/Description + Package set compatible with the SolidRun ClearFog A1 board +endef + +$(eval $(call Profile,Solidrun-Clearfog-A1)) diff --git a/target/linux/mvebu/generic/target.mk b/target/linux/mvebu/generic/target.mk new file mode 100644 index 0000000..b4d531b --- /dev/null +++ b/target/linux/mvebu/generic/target.mk @@ -0,0 +1,6 @@ +BOARDNAME:=Generic + +define Target/Description + Build firmware images for mvebu based boards that boot from internal flash +endef + diff --git a/target/linux/mvebu/profiles/000-Default.mk b/target/linux/mvebu/profiles/000-Default.mk deleted file mode 100644 index 5660836..0000000 --- a/target/linux/mvebu/profiles/000-Default.mk +++ /dev/null @@ -1,26 +0,0 @@ -# -# Copyright (C) 2015 OpenWrt.org -# -# This is free software, licensed under the GNU General Public License v2. -# See /LICENSE for more information. -# - -define Profile/Default - NAME:=Default Profile (all drivers) - PACKAGES:= \ - kmod-mmc kmod-mvsdio swconfig \ - kmod-usb2 kmod-usb3 kmod-usb-storage \ - kmod-i2c-core kmod-i2c-mv64xxx \ - kmod-ata-core kmod-ata-marvell-sata \ - kmod-rtc-marvell kmod-thermal-armada \ - kmod-gpio-button-hotplug kmod-hwmon-tmp421 \ - kmod-hwmon-pwmfan kmod-leds-tlc59116 \ - kmod-ledtrig-usbdev kmod-mwlwifi wpad-mini \ - kmod-ata-mvebu-ahci -endef - -define Profile/Default/Description - Default package set compatible with most boards. -endef - -$(eval $(call Profile,Default)) diff --git a/target/linux/mvebu/profiles/globalscale.mk b/target/linux/mvebu/profiles/globalscale.mk deleted file mode 100644 index 7938c35..0000000 --- a/target/linux/mvebu/profiles/globalscale.mk +++ /dev/null @@ -1,21 +0,0 @@ -# -# Copyright (C) 2015 OpenWrt.org -# -# This is free software, licensed under the GNU General Public License v2. -# See /LICENSE for more information. -# - -define Profile/Mirabox - NAME:=Globalscale Mirabox - PACKAGES:= \ - kmod-usb3 kmod-usb-storage \ - kmod-i2c-core kmod-i2c-mv64xxx \ - kmod-rtc-marvell kmod-thermal-armada \ - kmod-gpio-button-hotplug kmod-mmc kmod-mvsdio -endef - -define Profile/Mirabox/Description - Package set compatible with the Globalscale Mirabox. -endef - -$(eval $(call Profile,Mirabox)) diff --git a/target/linux/mvebu/profiles/linksys.mk b/target/linux/mvebu/profiles/linksys.mk deleted file mode 100644 index 9c954bd..0000000 --- a/target/linux/mvebu/profiles/linksys.mk +++ /dev/null @@ -1,85 +0,0 @@ -# -# Copyright (C) 2013-2015 OpenWrt.org -# -# This is free software, licensed under the GNU General Public License v2. -# See /LICENSE for more information. -# - -define Profile/Caiman - NAME:=Linksys WRT1200AC (Caiman) - PACKAGES:= \ - kmod-usb2 kmod-usb3 kmod-usb-storage \ - kmod-i2c-core kmod-i2c-mv64xxx \ - kmod-ata-core kmod-ata-mvebu-ahci \ - kmod-rtc-armada38x kmod-thermal-armada \ - kmod-gpio-button-hotplug kmod-hwmon-tmp421 \ - kmod-leds-pca963x \ - kmod-ledtrig-usbdev kmod-mwlwifi wpad-mini \ - swconfig -endef - -define Profile/Caiman/Description - Package set compatible with the Linksys WRT1200AC (Caiman). -endef - -$(eval $(call Profile,Caiman)) - - -define Profile/Cobra - NAME:=Linksys WRT1900ACv2 (Cobra) - PACKAGES:= \ - kmod-usb2 kmod-usb3 kmod-usb-storage \ - kmod-i2c-core kmod-i2c-mv64xxx \ - kmod-ata-core kmod-ata-mvebu-ahci \ - kmod-rtc-armada38x kmod-thermal-armada \ - kmod-gpio-button-hotplug kmod-hwmon-tmp421 \ - kmod-leds-pca963x \ - kmod-ledtrig-usbdev kmod-mwlwifi wpad-mini \ - swconfig -endef - -define Profile/Cobra/Description - Package set compatible with the Linksys WRT1900AC (Cobra). -endef - -$(eval $(call Profile,Cobra)) - - -define Profile/Mamba - NAME:=Linksys WRT1900AC (Mamba) - PACKAGES:= \ - kmod-usb2 kmod-usb3 kmod-usb-storage \ - kmod-i2c-core kmod-i2c-mv64xxx \ - kmod-ata-core kmod-ata-marvell-sata \ - kmod-rtc-marvell kmod-thermal-armada \ - kmod-gpio-button-hotplug kmod-hwmon-tmp421 \ - kmod-hwmon-pwmfan kmod-leds-tlc591xx \ - kmod-ledtrig-usbdev kmod-mwlwifi wpad-mini \ - swconfig -endef - -define Profile/Mamba/Description - Package set compatible with the Linksys WRT1900AC (Mamba). -endef - -$(eval $(call Profile,Mamba)) - - -define Profile/Shelby - NAME:=Linksys WRT1900ACS (Shelby) - PACKAGES:= \ - kmod-usb2 kmod-usb3 kmod-usb-storage \ - kmod-i2c-core kmod-i2c-mv64xxx \ - kmod-ata-core kmod-ata-mvebu-ahci \ - kmod-rtc-armada38x kmod-thermal-armada \ - kmod-gpio-button-hotplug kmod-hwmon-tmp421 \ - kmod-leds-pca963x \ - kmod-ledtrig-usbdev kmod-mwlwifi wpad-mini \ - swconfig -endef - -define Profile/Shelby/Description - Package set compatible with the Linksys WRT1900ACS (Shelby). -endef - -$(eval $(call Profile,Shelby)) diff --git a/target/linux/mvebu/profiles/marvell.mk b/target/linux/mvebu/profiles/marvell.mk deleted file mode 100644 index e8ca9bd..0000000 --- a/target/linux/mvebu/profiles/marvell.mk +++ /dev/null @@ -1,95 +0,0 @@ -# -# Copyright (C) 2013-2015 OpenWrt.org -# -# This is free software, licensed under the GNU General Public License v2. -# See /LICENSE for more information. -# - -define Profile/370-DB - NAME:=Marvell Armada 370 DB (DB-88F6710-BP-DDR3) - PACKAGES:= \ - kmod-mmc kmod-mvsdio kmod-usb2 kmod-usb-storage \ - kmod-i2c-core kmod-i2c-mv64xxx \ - kmod-ata-core kmod-ata-marvell-sata \ - kmod-rtc-marvell kmod-thermal-armada -endef - -define Profile/370-DB/Description - Package set compatible with the Armada 370 evaluation board (DB-88F6710-BP-DDR3). -endef - -$(eval $(call Profile,370-DB)) - -define Profile/370-RD - NAME:=Marvell Armada 370 RD (RD-88F6710-A1) - PACKAGES:= \ - kmod-mmc kmod-mvsdio kmod-usb2 kmod-usb-storage \ - kmod-i2c-core kmod-i2c-mv64xxx \ - kmod-ata-core kmod-ata-marvell-sata \ - kmod-rtc-marvell kmod-thermal-armada -endef - -define Profile/370-RD/Description - Package set compatible with the Armada 370 reference design board (RD-88F6710-A1). -endef - -$(eval $(call Profile,370-RD)) - -define Profile/385-RD - NAME:=Marvell Armada 385 RD (RD-88F6820-AP) - PACKAGES:= \ - kmod-mmc kmod-mvsdio kmod-usb3 kmod-usb-storage \ - kmod-i2c-core kmod-i2c-mv64xxx \ - kmod-thermal-armada -endef - -define Profile/385-RD/Description - Package set compatible with the Armada 385 reference design board (RD-88F6820-AP). -endef - -$(eval $(call Profile,385-RD)) - -define Profile/385-DB-AP - NAME:=Marvell Armada 385 DB AP (DB-88F6820-AP) - PACKAGES:= \ - kmod-usb3 kmod-usb-storage \ - kmod-i2c-core kmod-i2c-mv64xxx \ - kmod-ata-core kmod-ata-marvell-sata \ - kmod-thermal-armada -endef - -define Profile/385-DB-AP/Description - Package set compatible with the Armada 385 access point development board (DB-88F6820-AP). -endef - -$(eval $(call Profile,385-DB-AP)) - -define Profile/XP-DB - NAME:=Marvell Armada XP DB (DB-78460-BP) - PACKAGES:= \ - kmod-mmc kmod-mvsdio kmod-usb2 kmod-usb-storage \ - kmod-i2c-core kmod-i2c-mv64xxx \ - kmod-ata-core kmod-ata-marvell-sata \ - kmod-rtc-marvell kmod-thermal-armada -endef - -define Profile/XP-DB/Description - Package set compatible with the Marvell Armada XP evaluation board (DB-78460-BP). -endef - -$(eval $(call Profile,XP-DB)) - -define Profile/XP-GP - NAME:=Marvell Armada XP GP (DB-MV784MP-GP) - PACKAGES:= \ - kmod-mmc kmod-mvsdio kmod-usb2 kmod-usb-storage \ - kmod-i2c-core kmod-i2c-mv64xxx \ - kmod-ata-core kmod-ata-marvell-sata \ - kmod-rtc-marvell kmod-thermal-armada -endef - -define Profile/XP-GP/Description - Package set compatible with the Armada XP development board (DB-MV784MP-GP). -endef - -$(eval $(call Profile,XP-GP)) diff --git a/target/linux/mvebu/profiles/plathome.mk b/target/linux/mvebu/profiles/plathome.mk deleted file mode 100644 index 63cdb71..0000000 --- a/target/linux/mvebu/profiles/plathome.mk +++ /dev/null @@ -1,21 +0,0 @@ -# -# Copyright (C) 2015 OpenWrt.org -# -# This is free software, licensed under the GNU General Public License v2. -# See /LICENSE for more information. -# - -define Profile/OpenBlocks-AX-3-4 - NAME:=Plat'Home OpenBlocks AX3 - PACKAGES:= \ - kmod-usb2 kmod-usb-storage \ - kmod-i2c-core kmod-i2c-mv64xxx \ - kmod-ata-core kmod-ata-marvell-sata \ - kmod-rtc-marvell kmod-thermal-armada -endef - -define Profile/OpenBlocks-AX-3-4/Description - Package set compatible with the Plat'Home OpenBlocks AX3. -endef - -$(eval $(call Profile,OpenBlocks-AX-3-4)) diff --git a/target/linux/mvebu/profiles/solidrun.mk b/target/linux/mvebu/profiles/solidrun.mk deleted file mode 100644 index 5aa61e2..0000000 --- a/target/linux/mvebu/profiles/solidrun.mk +++ /dev/null @@ -1,21 +0,0 @@ -# -# Copyright (C) 2016 OpenWrt.org -# -# This is free software, licensed under the GNU General Public License v2. -# See /LICENSE for more information. -# - -define Profile/Solidrun-Clearfog-A1 - NAME:=SolidRun ClearFog A1 board - PACKAGES:= \ - kmod-usb3 kmod-usb2 kmod-usb-storage \ - kmod-of-i2c kmod-i2c-core kmod-i2c-mv64xxx \ - kmod-ata-core kmod-ata-marvell-sata \ - kmod-thermal-armada kmod-rtc-marvell -endef - -define Profile/Solidrun-Clearfog-A1/Description - Package set compatible with the SolidRun ClearFog A1 board -endef - -$(eval $(call Profile,Solidrun-Clearfog-A1)) -- 2.6.6 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From josua.mayer97 at gmail.com Wed May 4 15:24:27 2016 From: josua.mayer97 at gmail.com (josua.mayer97 at gmail.com) Date: Wed, 4 May 2016 21:24:27 +0200 Subject: [OpenWrt-Devel] [PATCH v4 3/4] mvebu: add target 'harddisk' In-Reply-To: <1462389868-18371-1-git-send-email-josua.mayer97@gmail.com> References: <1462389868-18371-1-git-send-email-josua.mayer97@gmail.com> Message-ID: <1462389868-18371-3-git-send-email-josua.mayer97@gmail.com> From: Josua Mayer This target is meant for any mvebu-based boards that can boot from internal or external storage devices such as mmc, emmc, sata. The Clearfog board is the first one this profile was applied to. Signed-off-by: Josua Mayer --- target/linux/mvebu/generic/profiles/solidrun.mk | 21 --------------------- target/linux/mvebu/harddisk/profiles/solidrun.mk | 21 +++++++++++++++++++++ target/linux/mvebu/harddisk/target.mk | 6 ++++++ 3 files changed, 27 insertions(+), 21 deletions(-) delete mode 100644 target/linux/mvebu/generic/profiles/solidrun.mk create mode 100644 target/linux/mvebu/harddisk/profiles/solidrun.mk create mode 100644 target/linux/mvebu/harddisk/target.mk diff --git a/target/linux/mvebu/generic/profiles/solidrun.mk b/target/linux/mvebu/generic/profiles/solidrun.mk deleted file mode 100644 index 5aa61e2..0000000 --- a/target/linux/mvebu/generic/profiles/solidrun.mk +++ /dev/null @@ -1,21 +0,0 @@ -# -# Copyright (C) 2016 OpenWrt.org -# -# This is free software, licensed under the GNU General Public License v2. -# See /LICENSE for more information. -# - -define Profile/Solidrun-Clearfog-A1 - NAME:=SolidRun ClearFog A1 board - PACKAGES:= \ - kmod-usb3 kmod-usb2 kmod-usb-storage \ - kmod-of-i2c kmod-i2c-core kmod-i2c-mv64xxx \ - kmod-ata-core kmod-ata-marvell-sata \ - kmod-thermal-armada kmod-rtc-marvell -endef - -define Profile/Solidrun-Clearfog-A1/Description - Package set compatible with the SolidRun ClearFog A1 board -endef - -$(eval $(call Profile,Solidrun-Clearfog-A1)) diff --git a/target/linux/mvebu/harddisk/profiles/solidrun.mk b/target/linux/mvebu/harddisk/profiles/solidrun.mk new file mode 100644 index 0000000..5aa61e2 --- /dev/null +++ b/target/linux/mvebu/harddisk/profiles/solidrun.mk @@ -0,0 +1,21 @@ +# +# Copyright (C) 2016 OpenWrt.org +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# + +define Profile/Solidrun-Clearfog-A1 + NAME:=SolidRun ClearFog A1 board + PACKAGES:= \ + kmod-usb3 kmod-usb2 kmod-usb-storage \ + kmod-of-i2c kmod-i2c-core kmod-i2c-mv64xxx \ + kmod-ata-core kmod-ata-marvell-sata \ + kmod-thermal-armada kmod-rtc-marvell +endef + +define Profile/Solidrun-Clearfog-A1/Description + Package set compatible with the SolidRun ClearFog A1 board +endef + +$(eval $(call Profile,Solidrun-Clearfog-A1)) diff --git a/target/linux/mvebu/harddisk/target.mk b/target/linux/mvebu/harddisk/target.mk new file mode 100644 index 0000000..03c77e0 --- /dev/null +++ b/target/linux/mvebu/harddisk/target.mk @@ -0,0 +1,6 @@ +BOARDNAME:=Internal Hard-Disk + +define Target/Description + Build firmware images for mvebu based boards that boot directly from internal or external + disk storage (e.g : Clearfog) +endef -- 2.6.6 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From josua.mayer97 at gmail.com Wed May 4 15:24:28 2016 From: josua.mayer97 at gmail.com (josua.mayer97 at gmail.com) Date: Wed, 4 May 2016 21:24:28 +0200 Subject: [OpenWrt-Devel] [PATCH v4 4/4] mvebu: enable mmc driver for harddisk target In-Reply-To: <1462389868-18371-1-git-send-email-josua.mayer97@gmail.com> References: <1462389868-18371-1-git-send-email-josua.mayer97@gmail.com> Message-ID: <1462389868-18371-4-git-send-email-josua.mayer97@gmail.com> From: Josua Mayer The clearfog can boot from sdcard or emmc, so make the required driver builtin. Signed-off-by: Josua Mayer --- target/linux/mvebu/harddisk/config-default | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) create mode 100644 target/linux/mvebu/harddisk/config-default diff --git a/target/linux/mvebu/harddisk/config-default b/target/linux/mvebu/harddisk/config-default new file mode 100644 index 0000000..85e082e --- /dev/null +++ b/target/linux/mvebu/harddisk/config-default @@ -0,0 +1,21 @@ +CONFIG_MMC=y +CONFIG_MMC_BLOCK=y +CONFIG_MMC_BLOCK_BOUNCE=y +CONFIG_MMC_BLOCK_MINORS=8 +CONFIG_MMC_CB710=n +CONFIG_MMC_CLKGATE=n +CONFIG_MMC_DEBUG=n +CONFIG_MMC_DW=n +CONFIG_MMC_MVSDIO=n +CONFIG_MMC_SDHCI=y +CONFIG_MMC_SDHCI_F_SDH30=n +CONFIG_MMC_SDHCI_OF_ARASAN=n +CONFIG_MMC_SDHCI_PCI=n +CONFIG_MMC_SDHCI_PLTFM=y +CONFIG_MMC_SDHCI_PXAV3=y +CONFIG_MMC_TEST=n +CONFIG_MMC_TIFM_SD=n +CONFIG_MMC_TOSHIBA_PCI=n +CONFIG_MMC_USDHI6ROL0=n +CONFIG_MMC_VIA_SDMMC=n +CONFIG_SDIO_UART=n -- 2.6.6 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From josua.mayer97 at gmail.com Wed May 4 15:26:09 2016 From: josua.mayer97 at gmail.com (Josua Mayer) Date: Wed, 4 May 2016 21:26:09 +0200 Subject: [OpenWrt-Devel] [PATCH v3 1/2] mvebu: config-4.1: make mmc drivers builtin In-Reply-To: <010001545ee1f9d7-e80e4bcf-6c52-461f-9076-c3be74ebbb06-000000@email.amazonses.com> References: <1461855802-15700-1-git-send-email-josua.mayer97@gmail.com> <010001545ee1f9d7-e80e4bcf-6c52-461f-9076-c3be74ebbb06-000000@email.amazonses.com> Message-ID: <572A4CD1.1040703@gmail.com> Hi Andrej, Am 28.04.2016 um 23:59 schrieb Andrej Vlasic: > Hi Josua, > > On 28.04.2016 17:03, josua.mayer97 at gmail.com wrote: >> From: Josua Mayer >> >> This is especially useful on the Clearfog board which boots from mmc by >> default. >> >> Signed-off-by: Josua Mayer >> --- >> target/linux/mvebu/config-4.1 | 24 ++++++++++++++++++++++++ >> 1 file changed, 24 insertions(+) >> >> diff --git a/target/linux/mvebu/config-4.1 >> b/target/linux/mvebu/config-4.1 >> index ee5c983..73319dd 100644 >> --- a/target/linux/mvebu/config-4.1 >> +++ b/target/linux/mvebu/config-4.1 >> @@ -362,3 +362,27 @@ CONFIG_ZBOOT_ROM_TEXT=0x0 >> CONFIG_ZLIB_DEFLATE=y >> CONFIG_ZLIB_INFLATE=y >> CONFIG_ZONE_DMA_FLAG=0 >> +CONFIG_MMC=y >> +CONFIG_MMC_BLOCK=y >> +CONFIG_MMC_BLOCK_BOUNCE=y >> +CONFIG_MMC_BLOCK_MINORS=8 >> +CONFIG_MMC_CB710=n >> +CONFIG_MMC_CLKGATE=n >> +CONFIG_MMC_DEBUG=n >> +CONFIG_MMC_DW=n >> +CONFIG_MMC_MVSDIO=y >> +CONFIG_MMC_SDHCI=n >> +CONFIG_MMC_TEST=n >> +CONFIG_MMC_TIFM_SD=n >> +CONFIG_MMC_TOSHIBA_PCI=n >> +CONFIG_MMC_USDHI6ROL0=n >> +CONFIG_MMC_USHC=n >> +CONFIG_MMC_VIA_SDMMC=n >> +CONFIG_MMC_VUB300=n >> +CONFIG_MMC_SDHCI=y >> +CONFIG_MMC_SDHCI_F_SDH30=n >> +CONFIG_MMC_SDHCI_OF_ARASAN=n >> +CONFIG_MMC_SDHCI_PCI=n >> +CONFIG_MMC_SDHCI_PLTFM=y >> +CONFIG_MMC_SDHCI_PXAV3=y >> +CONFIG_SDIO_UART=n >> > > Instead of adding those config options to default kernel config, it > would be better to create new mvebu subtarget, maybe called "harddisk" > that has support for external boot devices. Thanks for your pointer at this. I now created such a target using ixp4xx as a template. Please let me know if the new approach is any better. br Josua Mayer _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From post at lespocky.de Wed May 4 15:40:26 2016 From: post at lespocky.de (Alexander Dahl) Date: Wed, 4 May 2016 21:40:26 +0200 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: References: <5179f6d1-283a-1b40-d717-2730c3408326@openwrt.org> Message-ID: <572A502A.5080404@lespocky.de> Hei hei, On 04.05.2016 20:57, Roman Yeryomin wrote: > Well, like you said yourself, why they didn't start discussing the > problems (and possible solutions) in open space then? I can not speak for OpenWRT or LEDE developers, but let me give an example on one topic I watched the last weeks, which several people tried to discuss openly: download mirrors. From my point of view the need for mirrors to be synced easily was communicated here on this list and at the forum. On neither place I saw any commitment from someone speaking for OpenWRT. There was just no feedback at all for weeks, although a lot of people offered help and tried to explain what is needed and why. If this is the usual way for OpenWRT, then I can understand the frustration which led to such a fork. Oh and I second the thoughts to the chosen new name. It's hart to image how to pronounce it correctly and you would probably end up spelling and explaining it all the time. ;-) Greets Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From mbm at openwrt.org Wed May 4 16:01:05 2016 From: mbm at openwrt.org (mbm) Date: Wed, 4 May 2016 13:01:05 -0700 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: References: Message-ID: <572A5501.3040807@openwrt.org> Dear OpenWrt community, It is with a great amount of surprise that, like all of you, we read about the announcement of the LEDE project yesterday, as there was no prior announcement nor clues this would happen. While we recognize the current OpenWrt project suffers from a number of issues outlined by Jo-Philip, in each of the 5 bullet points, we do not agree with the conclusions withdrawn, and even less so in deciding to spin off the OpenWrt project in the first place as a way to fix the project and its community. Also, the phrases such as a "reboot" are both vague and misleading and the LEDE project failed to identify its true nature. The LEDE announcement contains a number of very valid points which we hoped we had an opportunity to discuss and attempt to fix, in a public manner, before this more radical outcome. At this point, the email as well as actions taken are very confusing to a lot of us. OpenWrt is primarily developed by individuals who may have a day job more or less related to the purpose or the technologies of the project, but who strive to maintain OpenWrt as independent as possible from any company, organization or interest group, thus maintaining its own infrastructure (website, forums, mailing-lists, bugtracker...), which has been usually at the heart of all debates. We do acknowledge there has been internal disagreements, on several occasions about some directions of the project, about the release model, the lack of testing, the centralized infrastructure, however, there have been actual work going on under the hoods to solve things one step at a time, starting with a more decentralized infrastructure, which was discussed with the LEDE developers as well. At this point, we do not have much to offer to the LEDE developers but to encourage them to publicly discuss on openwrt-devel at lists.openwrt.org the different items we should all be fixing together, and avoid spinning off so that all decisions can be taken with the community's involvement, and accountability and transparency can rule us as one community. As a user, developer, contributor, or just community member, whatever choice you make, keep the choice that matters to you: the ability to utilize superior quality open source software to power whatever embedded device that matters to you! We would like to stress that we do want to have an open discussion and resolve matters at hand. Our goal is to work with all parties who can and want to contribute to OpenWrt, including the LEDE team. Sincerely, Your OpenWrt team _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From j.lancett at ntlworld.com Wed May 4 16:19:03 2016 From: j.lancett at ntlworld.com (tapper) Date: Wed, 4 May 2016 21:19:03 +0100 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <572A5501.3040807@openwrt.org> References: <572A5501.3040807@openwrt.org> Message-ID: <5d3aa102-0541-25ef-9d52-24115c7ae006@ntlworld.com> On 04/05/2016 21:01, mbm wrote: > Dear OpenWrt community, > > It is with a great amount of surprise that, like all of you, we read > about the announcement of the LEDE project yesterday, as there was no > prior announcement nor clues this would happen. > > While we recognize the current OpenWrt project suffers from a number of > issues outlined by Jo-Philip, in each of the 5 bullet points, we do not > agree with the conclusions withdrawn, and even less so in deciding to > spin off the OpenWrt project in the first place as a way to fix the > project and its community. Also, the phrases such as a "reboot" are both > vague and misleading and the LEDE project failed to identify its true > nature. The LEDE announcement contains a number of very valid points > which we hoped we had an opportunity to discuss and attempt to fix, in a > public manner, before this more radical outcome. At this point, the > email as well as actions taken are very confusing to a lot of us. > > OpenWrt is primarily developed by individuals who may have a day job > more or less related to the purpose or the technologies of the project, > but who strive to maintain OpenWrt as independent as possible from any > company, organization or interest group, thus maintaining its own > infrastructure (website, forums, mailing-lists, bugtracker...), which > has been usually at the heart of all debates. > > We do acknowledge there has been internal disagreements, on several > occasions about some directions of the project, about the release model, > the lack of testing, the centralized infrastructure, however, there have > been actual work going on under the hoods to solve things one step at a > time, starting with a more decentralized infrastructure, which was > discussed with the LEDE developers as well. > > At this point, we do not have much to offer to the LEDE developers but > to encourage them to publicly discuss on > openwrt-devel at lists.openwrt.org the different items we should all be > fixing together, and avoid spinning off so that all decisions can be > taken with the community's involvement, and accountability and > transparency can rule us as one community. > > As a user, developer, contributor, or just community member, whatever > choice you make, keep the choice that matters to you: the ability to > utilize superior quality open source software to power whatever embedded > device that matters to you! > > We would like to stress that we do want to have an open discussion and > resolve matters at hand. Our goal is to work with all parties who can > and want to contribute to OpenWrt, including the LEDE team. > > Sincerely, > Your OpenWrt team > ______________ But just who is "Your OpenWrt team?" After all the talk about fixing the website and the forum we as the openwrt end users got jack shit! Even wen we offered to do things for you. _________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From leroi.lists at gmail.com Wed May 4 17:00:32 2016 From: leroi.lists at gmail.com (Roman Yeryomin) Date: Thu, 5 May 2016 00:00:32 +0300 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <5d3aa102-0541-25ef-9d52-24115c7ae006@ntlworld.com> References: <572A5501.3040807@openwrt.org> <5d3aa102-0541-25ef-9d52-24115c7ae006@ntlworld.com> Message-ID: On 4 May 2016 at 23:19, tapper wrote: > On 04/05/2016 21:01, mbm wrote: >> >> Dear OpenWrt community, >> >> It is with a great amount of surprise that, like all of you, we read >> about the announcement of the LEDE project yesterday, as there was no >> prior announcement nor clues this would happen. >> >> While we recognize the current OpenWrt project suffers from a number of >> issues outlined by Jo-Philip, in each of the 5 bullet points, we do not >> agree with the conclusions withdrawn, and even less so in deciding to >> spin off the OpenWrt project in the first place as a way to fix the >> project and its community. Also, the phrases such as a "reboot" are both >> vague and misleading and the LEDE project failed to identify its true >> nature. The LEDE announcement contains a number of very valid points >> which we hoped we had an opportunity to discuss and attempt to fix, in a >> public manner, before this more radical outcome. At this point, the >> email as well as actions taken are very confusing to a lot of us. >> >> OpenWrt is primarily developed by individuals who may have a day job >> more or less related to the purpose or the technologies of the project, >> but who strive to maintain OpenWrt as independent as possible from any >> company, organization or interest group, thus maintaining its own >> infrastructure (website, forums, mailing-lists, bugtracker...), which >> has been usually at the heart of all debates. >> >> We do acknowledge there has been internal disagreements, on several >> occasions about some directions of the project, about the release model, >> the lack of testing, the centralized infrastructure, however, there have >> been actual work going on under the hoods to solve things one step at a >> time, starting with a more decentralized infrastructure, which was >> discussed with the LEDE developers as well. >> >> At this point, we do not have much to offer to the LEDE developers but >> to encourage them to publicly discuss on >> openwrt-devel at lists.openwrt.org the different items we should all be >> fixing together, and avoid spinning off so that all decisions can be >> taken with the community's involvement, and accountability and >> transparency can rule us as one community. >> >> As a user, developer, contributor, or just community member, whatever >> choice you make, keep the choice that matters to you: the ability to >> utilize superior quality open source software to power whatever embedded >> device that matters to you! >> >> We would like to stress that we do want to have an open discussion and >> resolve matters at hand. Our goal is to work with all parties who can >> and want to contribute to OpenWrt, including the LEDE team. >> >> Sincerely, >> Your OpenWrt team >> ______________ > > > But just who is "Your OpenWrt team?" > After all the talk about fixing the website and the forum we as the openwrt > end users got jack shit! Even wen we offered to do things for you. > Probably one of the problems is that not all read all communication channels. I think that developers are more used to mailing list. Blaming only those who left doesn't make any sense, IMO all are responsible. Regards, Roman _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Wed May 4 17:40:55 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Wed, 4 May 2016 17:40:55 -0400 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: References: <5179f6d1-283a-1b40-d717-2730c3408326@openwrt.org> Message-ID: <572A6C67.3040701@daniel.thecshore.com> On 16-05-04 12:25 PM, Kathy Giori wrote: > Also wearing my hat within the prpl Foundation, which is funded by > industry sponsorships that in turn provides financial support for > OpenWrt, no one I have spoken to in prpl understands the reason for > this spin-off either. It'll cause more confusion and inefficiency in > industry. prpl will stick with OpenWrt, and I expect most companies > who follow and/or contribute to OpenWrt will stick with it too. Silly question, but can you outline some specific examples of contributions that an outsider like me has somehow missed as being as concrete examples of companies contributing back to openwrt, rather than just benefiting from it? Regards, Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From noltari at gmail.com Wed May 4 17:57:50 2016 From: noltari at gmail.com (=?UTF-8?Q?=c3=81lvaro_Fern=c3=a1ndez_Rojas?=) Date: Wed, 4 May 2016 23:57:50 +0200 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <572A6C67.3040701@daniel.thecshore.com> References: <5179f6d1-283a-1b40-d717-2730c3408326@openwrt.org> <572A6C67.3040701@daniel.thecshore.com> Message-ID: <572A705E.20504@gmail.com> El 04/05/2016 a las 23:40, Daniel Dickinson escribi?: > On 16-05-04 12:25 PM, Kathy Giori wrote: >> Also wearing my hat within the prpl Foundation, which is funded by >> industry sponsorships that in turn provides financial support for >> OpenWrt, no one I have spoken to in prpl understands the reason for >> this spin-off either. It'll cause more confusion and inefficiency in >> industry. prpl will stick with OpenWrt, and I expect most companies >> who follow and/or contribute to OpenWrt will stick with it too. > Silly question, but can you outline some specific examples of > contributions that an outsider like me has somehow missed as being as > concrete examples of companies contributing back to openwrt, rather than > just benefiting from it? > > Regards, > > Daniel > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel +1 to Daniel's question. Regards, ?lvaro. _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From bob at librecmc.org Wed May 4 18:05:56 2016 From: bob at librecmc.org (Bob Call) Date: Wed, 04 May 2016 18:05:56 -0400 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <5d3aa102-0541-25ef-9d52-24115c7ae006@ntlworld.com> References: <572A5501.3040807@openwrt.org> <5d3aa102-0541-25ef-9d52-24115c7ae006@ntlworld.com> Message-ID: <1462399556.13511.49.camel@librecmc.org> On Wed, 2016-05-04 at 21:19 +0100, tapper wrote: > On 04/05/2016 21:01, mbm wrote: > > > > Dear OpenWrt community, > > > > It is with a great amount of surprise that, like all of you, we > > read > > about the announcement of the LEDE project yesterday, as there was > > no > > prior announcement nor clues this would happen. > > > > While we recognize the current OpenWrt project suffers from a > > number of > > issues outlined by Jo-Philip, in each of the 5 bullet points, we do > > not > > agree with the conclusions withdrawn, and even less so in deciding > > to > > spin off the OpenWrt project in the first place as a way to fix the > > project and its community. Also, the phrases such as a "reboot" are > > both > > vague and misleading and the LEDE project failed to identify its > > true > > nature. The LEDE announcement??contains a number of very valid > > points > > which we hoped we had an opportunity to discuss and attempt to fix, > > in a > > public manner, before this more radical outcome. At this point, the > > email as well as actions taken are very confusing to a lot of us. > > > > OpenWrt is primarily developed by individuals who may have a day > > job > > more or less related to the purpose or the technologies of the > > project, > > but who strive to maintain OpenWrt as independent as possible??from > > any > > company, organization or interest group, thus maintaining its own > > infrastructure (website, forums, mailing-lists, bugtracker...), > > which > > has been usually at the heart of all debates. > > > > We do acknowledge there has been internal disagreements, on several > > occasions about some directions of the project, about the release > > model, > > the lack of testing, the centralized infrastructure, however, there > > have > > been actual work going on under the hoods to solve things one step > > at a > > time, starting with a more decentralized infrastructure, which was > > discussed with the LEDE developers as well. > > > > At this point, we do not have much to offer to the LEDE developers > > but > > to encourage them to publicly discuss on > > openwrt-devel at lists.openwrt.org the different items we should all > > be > > fixing together, and avoid spinning off so that all decisions can > > be > > taken with the community's involvement, and accountability and > > transparency can rule us as one community. > > > > As a user, developer, contributor, or just community member, > > whatever > > choice you make, keep the choice that matters to you: the ability > > to > > utilize superior quality open source software to power whatever > > embedded > > device that matters to you! > > > > We would like to stress that we do want to have an open discussion > > and > > resolve matters at hand. Our goal is to work with all parties who > > can > > and want to contribute to OpenWrt, including the LEDE team. > > > > Sincerely, > > Your OpenWrt team > > ______________ > But just who is "Your OpenWrt team?" > After all the talk about fixing the website and the forum we as the? > openwrt end users got jack shit! Even wen we offered to do things for > you. > I'm kind of split on this issue because I run a faltering OpenWRT fork, feel that OpenWRT has grown beyond the scope of an "embedded" OS/distro and the goals of LEDE don't fix the faults with OpenWRT or its community. There are many issues that need to be addressed and maybe the only way that some could start the conversation was to start a fork. Sometimes, great things come out of forks and eventually make it back upstream (some cerowrt work comes to mind). Regardless of the reason for the fork, the community at large can start a conversation and work to resolve everyone's issues in a sane way. I started my fork due to philosophical and technical reasons with the intent of address concerns that many in the free software community have, but during my work on this fork, I've found that: * Many components in OpenWRT are becoming too bloated and make it difficult to use some lower-end routers/targets without neutering commonly wanted functionality. While this is not fully OpenWRT's fault, it would be good to start making an effort to get some upstream projects to work on reducing their footprint. * OpenWRT is still using md5 checks for their source packages and lacks signatures for most, if not all, of its source packages. * OpenWRT's documentation is non-free due to the CC-NC-SA licensing, which means that anyone who wanted to sell OpenWRT on a product with documentation would have to fully re-write it from scratch. * OpenWRT works to support too many devices and the quality is lacking on quite a few targets. While development focus is mainly on a hand full of targets, this does lead to bad experiences for many end-users who are not technical enough to help debug or fix issues. It would also help if poor hardware was not supported in the first place. Personally, I'd like to see a project which focuses on actual embedded systems (those with <4 MB of flash and < 16 MB of RAM) and is open to new ideas about what that might look like. The first step to actually making that happen is to be a bit more welcoming to new contributions or entertaining some crazy ideas. I wish both communities luck, wherever this may go. -- Robert Call (Bob) bob at librecmc.org _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From karlp at tweak.net.au Wed May 4 18:52:03 2016 From: karlp at tweak.net.au (Karl Palsson) Date: Wed, 04 May 2016 22:52:03 -0000 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <572A6C67.3040701@daniel.thecshore.com> References: <572A6C67.3040701@daniel.thecshore.com> Message-ID: Daniel Dickinson wrote: > > Silly question, but can you outline some specific examples of > contributions that an outsider like me has somehow missed as > being as concrete examples of companies contributing back to > openwrt, rather than just benefiting from it? Every commit from me. We're a tiny company who mostly works in userspace, but we occasionally find tings to fix and fix them. This apparently common idea that companies are running around using openwrt and never contributing anything back just doesn't seem to match any sort of reality. Sincerely, Karl P -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP Digital Signature URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Wed May 4 19:01:38 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Wed, 4 May 2016 19:01:38 -0400 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: References: <572A6C67.3040701@daniel.thecshore.com> Message-ID: <572A7F52.70408@daniel.thecshore.com> On 16-05-04 06:52 PM, Karl Palsson wrote: > > Daniel Dickinson wrote: >> >> Silly question, but can you outline some specific examples of >> contributions that an outsider like me has somehow missed as >> being as concrete examples of companies contributing back to >> openwrt, rather than just benefiting from it? > > Every commit from me. We're a tiny company who mostly works in > userspace, but we occasionally find tings to fix and fix them. > This apparently common idea that companies are running around > using openwrt and never contributing anything back just doesn't > seem to match any sort of reality. I can't mention specifics, but I've seen it happen, more than once. What doesn't seem to be clear is how common one vs. the other is (I mean it's not like anyone really seems to be advertising what they are doing either way). Regards, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Wed May 4 19:21:17 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Wed, 4 May 2016 19:21:17 -0400 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <572A7F52.70408@daniel.thecshore.com> References: <572A6C67.3040701@daniel.thecshore.com> <572A7F52.70408@daniel.thecshore.com> Message-ID: <572A83ED.6050204@daniel.thecshore.com> On 16-05-04 07:01 PM, Daniel Dickinson wrote: > On 16-05-04 06:52 PM, Karl Palsson wrote: >> >> Daniel Dickinson wrote: >>> >>> Silly question, but can you outline some specific examples of >>> contributions that an outsider like me has somehow missed as >>> being as concrete examples of companies contributing back to >>> openwrt, rather than just benefiting from it? >> >> Every commit from me. We're a tiny company who mostly works in >> userspace, but we occasionally find tings to fix and fix them. >> This apparently common idea that companies are running around >> using openwrt and never contributing anything back just doesn't >> seem to match any sort of reality. > > I can't mention specifics, but I've seen it happen, more than once. > What doesn't seem to be clear is how common one vs. the other is (I mean > it's not like anyone really seems to be advertising what they are doing > either way). It also seems to me (as an outsider) that those who do contribute are small open-source minded companies, and that's a fairly small pool to draw from IMO. Perhaps there is a lot more contributions than most of us not 'in-the-know' are aware of, but there is a reason for the impression you mention. Regards, Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From kathy.giori at gmail.com Wed May 4 19:32:04 2016 From: kathy.giori at gmail.com (Kathy Giori) Date: Wed, 4 May 2016 16:32:04 -0700 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <572A6C67.3040701@daniel.thecshore.com> References: <5179f6d1-283a-1b40-d717-2730c3408326@openwrt.org> <572A6C67.3040701@daniel.thecshore.com> Message-ID: On Wed, May 4, 2016 at 2:40 PM, Daniel Dickinson wrote: > On 16-05-04 12:25 PM, Kathy Giori wrote: >> Also wearing my hat within the prpl Foundation, which is funded by >> industry sponsorships that in turn provides financial support for >> OpenWrt, no one I have spoken to in prpl understands the reason for >> this spin-off either. It'll cause more confusion and inefficiency in >> industry. prpl will stick with OpenWrt, and I expect most companies >> who follow and/or contribute to OpenWrt will stick with it too. > > Silly question, but can you outline some specific examples of > contributions that an outsider like me has somehow missed as being as > concrete examples of companies contributing back to openwrt, rather than > just benefiting from it? > Daniel I fully concur that industry "give back" is severely lacking. It seems to me that the bigger the company, the less likely they are to give back. One of the goals of the prpl Foundation was to help big industry members to better "see" that problem, and to use prpl to help them do something about it. I see two main reasons for the lack of contributions problem (not developer fault). 1. short-term focus. Industry rushes to meet product release schedules and managers are too often not aware of the downstream maintenance burdens they will face later, by not integrating their changes properly into the Linux kernel (and OpenWrt). 2. legal. I could blab about this problem for days, but mainly there is a fear of open source licensing when compared to the value of giving back. This type of FUD problem is perhaps one that prpl could help address too, through educational efforts. As an example of a contribution, prpl is promoting the OpenWrt "board farm" project, intended to support automated testing (of trunk) on various platforms on a daily basis. The test framework was in fact contributed by industry. Now imagine the new problem that industry faces if they want to give back. Do they have to push changes back into two different/similar project branches? Do they need to setup two board farms or double the test time? Will some companies choose to push to OpenWrt and others to LEDE, leaving the end-user to figure out which project's software will run on their board? In my opinion, the OpenWrt core team members need to setup some policies and procedures (e.g., take ideas from the LEDE objectives) that allow the fairness and flexibility that is desired, so that only one OpenWrt development branch continues to be developed. Reducing the core team to the LEDE subgroup will take away from the diversity of the project at the core, and I don't see that as a good thing. Yes, collaboration in a diverse environment is harder, but research has shown repeatedly that companies with staff diversity perform better. kathy _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Wed May 4 19:45:46 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Wed, 4 May 2016 19:45:46 -0400 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: References: <5179f6d1-283a-1b40-d717-2730c3408326@openwrt.org> <572A6C67.3040701@daniel.thecshore.com> Message-ID: <572A89AA.1000006@daniel.thecshore.com> On 16-05-04 07:32 PM, Kathy Giori wrote: > > Daniel I fully concur that industry "give back" is severely lacking. > It seems to me that the bigger the company, the less likely they are > to give back. One of the goals of the prpl Foundation was to help big > industry members to better "see" that problem, and to use prpl to help > them do something about it. That is definitely a worthwhile goal, that I'd like come to fruition. > > I see two main reasons for the lack of contributions problem (not > developer fault). > 1. short-term focus. Industry rushes to meet product release schedules > and managers are too often not aware of the downstream maintenance > burdens they will face later, by not integrating their changes > properly into the Linux kernel (and OpenWrt). > 2. legal. I could blab about this problem for days, but mainly there > is a fear of open source licensing when compared to the value of > giving back. This type of FUD problem is perhaps one that prpl could > help address too, through educational efforts. That matches my experiences. > > As an example of a contribution, prpl is promoting the OpenWrt "board > farm" project, intended to support automated testing (of trunk) on > various platforms on a daily basis. The test framework was in fact > contributed by industry. > > Now imagine the new problem that industry faces if they want to give > back. Do they have to push changes back into two different/similar > project branches? Do they need to setup two board farms or double the > test time? Will some companies choose to push to OpenWrt and others to > LEDE, leaving the end-user to figure out which project's software will > run on their board? > > In my opinion, the OpenWrt core team members need to setup some > policies and procedures (e.g., take ideas from the LEDE objectives) Not being an insider this is only a guess, but it seems to me that efforts to reach an internal solution have been stymied by some part(y|ies) that balk at what the LEDE team wants to see happen, and the LEDE team is tired of fighting when they are the ones (at least to outside appearances) the ones doing the majority of the work. > that allow the fairness and flexibility that is desired, so that only TBH I don't think it's the LEDE team that needs to get that message. > one OpenWrt development branch continues to be developed. Reducing the > core team to the LEDE subgroup will take away from the diversity of > the project at the core, and I don't see that as a good thing. Yes, > collaboration in a diverse environment is harder, but research has > shown repeatedly that companies with staff diversity perform better. Collaboration requires the cooperation of those you are supposed to collaborate with, and willingness of both sides to be flexible. Not knowing the specifics I can't speak to whether this is a case of mutual inflexibility or one-sided. Certainly some of the members of the LEDE team seem to be people who attempt to reach mutual satisfactory conclusions, and one individual in particular emailed my privately when I was upset and expressed it on list, and helped me to see things differently, and I believe that individual is also part of the reason the problems listed as reasons for the fork have been publicly acknowledged. Regards, Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Wed May 4 19:47:18 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Wed, 4 May 2016 19:47:18 -0400 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <572A83ED.6050204@daniel.thecshore.com> References: <572A6C67.3040701@daniel.thecshore.com> <572A7F52.70408@daniel.thecshore.com> <572A83ED.6050204@daniel.thecshore.com> Message-ID: <572A8A06.3020605@daniel.thecshore.com> On 16-05-04 07:21 PM, Daniel Dickinson wrote: > On 16-05-04 07:01 PM, Daniel Dickinson wrote: >> On 16-05-04 06:52 PM, Karl Palsson wrote: >>> >>> Daniel Dickinson wrote: > It also seems to me (as an outsider) that those who do contribute are > small open-source minded companies, and that's a fairly small pool to > draw from IMO. Perhaps there is a lot more contributions than most of > us not 'in-the-know' are aware of, but there is a reason for the > impression you mention. To clarify: it's not that I don't think those contributions are important - every contribution helps, just that if's a choice between the LEDE developers and what is visible from other sources, LEDE seems to have more contributions. Regards, Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From fhfrediani at gmail.com Wed May 4 19:59:54 2016 From: fhfrediani at gmail.com (Fernando Frediani) Date: Wed, 4 May 2016 20:59:54 -0300 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <572A6C67.3040701@daniel.thecshore.com> References: <5179f6d1-283a-1b40-d717-2730c3408326@openwrt.org> <572A6C67.3040701@daniel.thecshore.com> Message-ID: Just curious to know by the names that signed the announcement of the new project being know OpenWrt Developers why weren't there enough votes inside OpenWrt to do this reboot and reorganize it completely under the LEDE Project ideas ? The LEDE ideas are great and the the long time and outstanding issues with OpenWrt are known to most people here, but I personally suspect if these changes were done inside the OpenWrt Project, even if there are disagreements would be more benefits in long term. May be wrong, but it?s my impression. Fernando On 4 May 2016 at 18:40, Daniel Dickinson wrote: > On 16-05-04 12:25 PM, Kathy Giori wrote: > > Also wearing my hat within the prpl Foundation, which is funded by > > industry sponsorships that in turn provides financial support for > > OpenWrt, no one I have spoken to in prpl understands the reason for > > this spin-off either. It'll cause more confusion and inefficiency in > > industry. prpl will stick with OpenWrt, and I expect most companies > > who follow and/or contribute to OpenWrt will stick with it too. > > Silly question, but can you outline some specific examples of > contributions that an outsider like me has somehow missed as being as > concrete examples of companies contributing back to openwrt, rather than > just benefiting from it? > > Regards, > > Daniel > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Wed May 4 20:00:29 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Wed, 4 May 2016 20:00:29 -0400 Subject: [OpenWrt-Devel] Getting in touch with Felix Message-ID: <572A8D1D.4060807@daniel.thecshore.com> Hi, How does one get in touch with Felix these days? nbd at openwrt.org bounces for me. Regards, Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Wed May 4 20:05:09 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Wed, 4 May 2016 20:05:09 -0400 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: References: <5179f6d1-283a-1b40-d717-2730c3408326@openwrt.org> <572A6C67.3040701@daniel.thecshore.com> Message-ID: <572A8E35.8090604@daniel.thecshore.com> On 16-05-04 07:59 PM, Fernando Frediani wrote: > Just curious to know by the names that signed the announcement of the > new project being know OpenWrt Developers why weren't there enough votes > inside OpenWrt to do this reboot and reorganize it completely under the > LEDE Project ideas ? I don't know if there is a project charter, but from when I was developer (I step aside because I was having personal issues not openwrt related) I wasn't aware of an actual voting mechanism or constitution that said majority rules. I'm not sure that there is an actual democratic method of decision making in the current framework. Regards, Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From fhfrediani at gmail.com Wed May 4 20:45:45 2016 From: fhfrediani at gmail.com (Fernando Frediani) Date: Wed, 4 May 2016 21:45:45 -0300 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <572A8E35.8090604@daniel.thecshore.com> References: <5179f6d1-283a-1b40-d717-2730c3408326@openwrt.org> <572A6C67.3040701@daniel.thecshore.com> <572A8E35.8090604@daniel.thecshore.com> Message-ID: Thanks Daniel. That explains a lot. I imagine if some digging is done it would be possible to find the holders of the critical resources and then re-organize it from scratch within the OpenWrt Project. But as the fork has already happened there is no much point in doing that. Regards, Fernando On 4 May 2016 at 21:05, Daniel Dickinson wrote: > On 16-05-04 07:59 PM, Fernando Frediani wrote: > > Just curious to know by the names that signed the announcement of the > > new project being know OpenWrt Developers why weren't there enough votes > > inside OpenWrt to do this reboot and reorganize it completely under the > > LEDE Project ideas ? > > I don't know if there is a project charter, but from when I was > developer (I step aside because I was having personal issues not openwrt > related) I wasn't aware of an actual voting mechanism or constitution > that said majority rules. I'm not sure that there is an actual > democratic method of decision making in the current framework. > > Regards, > > Daniel > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From kathy.giori at gmail.com Wed May 4 21:02:47 2016 From: kathy.giori at gmail.com (Kathy Giori) Date: Wed, 4 May 2016 18:02:47 -0700 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: References: <5179f6d1-283a-1b40-d717-2730c3408326@openwrt.org> <572A6C67.3040701@daniel.thecshore.com> <572A8E35.8090604@daniel.thecshore.com> Message-ID: On Wed, May 4, 2016 at 5:45 PM, Fernando Frediani wrote: > Thanks Daniel. That explains a lot. > I imagine if some digging is done it would be possible to find the holders > of the critical resources and then re-organize it from scratch within the > OpenWrt Project. > But as the fork has already happened there is no much point in doing that. If it is too late to stop the "project" teams from having their independence from each other, can there at least be a common core for both projects, where all the kernel and board support stuff lives for example? And whatever else makes sense not to be duplicated? Let the differences exist at a higher layer, ideally more cosmetic. Share as much as possible. Communicate ideas for the common core openly. Leverage each others skills for a greater overall benefit. Would this idea work? I recommend that both groups propose whatever solutions they can think of to reduce duplication of effort and to avoid further community confusion and frustration. kathy _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From alzhao at gmail.com Wed May 4 23:02:05 2016 From: alzhao at gmail.com (alzhao) Date: Thu, 5 May 2016 11:02:05 +0800 Subject: [OpenWrt-Devel] [PATCH 1/6] [CC] [backport] ar71xx: add GL-AR150 support Message-ID: <1462417330-12566-1-git-send-email-alzhao@gmail.com> Backport of changeset 47620, add support of GL-AR150 to cc Signed-off-by: Alfie Zhao --- .../ar71xx/base-files/etc/uci-defaults/01_leds | 4 + .../ar71xx/base-files/etc/uci-defaults/02_network | 1 + target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 + .../ar71xx/base-files/lib/upgrade/platform.sh | 1 + target/linux/ar71xx/config-3.18 | 1 + .../ar71xx/files/arch/mips/ath79/mach-gl-ar150.c | 125 +++++++++++++++++++++ target/linux/ar71xx/generic/profiles/gl-connect.mk | 17 --- target/linux/ar71xx/generic/profiles/gli.mk | 27 +++++ target/linux/ar71xx/image/Makefile | 8 ++ .../patches-3.18/911-MIPS-ath79-add-gl_ar150.patch | 39 +++++++ 10 files changed, 209 insertions(+), 17 deletions(-) create mode 100644 target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar150.c delete mode 100644 target/linux/ar71xx/generic/profiles/gl-connect.mk create mode 100644 target/linux/ar71xx/generic/profiles/gli.mk create mode 100644 target/linux/ar71xx/patches-3.18/911-MIPS-ath79-add-gl_ar150.patch diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds index a4b355a..0bd0b35 100644 --- a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds @@ -181,6 +181,10 @@ dlan-pro-1200-ac) ucidef_set_led_trigger_gpio "plcr" "dLAN" "devolo:error:dlan" "16" "0" ;; +gl-ar150) + ucidef_set_led_wlan "wlan" "WLAN" "gl_ar150:wlan" "phy0tpt" + ;; + gl-inet) ucidef_set_led_netdev "lan" "LAN" "gl-connect:green:lan" "eth1" ucidef_set_led_wlan "wlan" "WLAN" "gl-connect:red:wlan" "phy0tpt" diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network index b2e15bb..c7ba875 100755 --- a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network @@ -379,6 +379,7 @@ dir-505-a1) alfa-ap96 |\ alfa-nx |\ ap83 |\ +gl-ar150 |\ gl-inet |\ jwap003 |\ pb42 |\ diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh b/target/linux/ar71xx/base-files/lib/ar71xx.sh index dab4d2c..813ff91 100755 --- a/target/linux/ar71xx/base-files/lib/ar71xx.sh +++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh @@ -458,6 +458,9 @@ ar71xx_board_detect() { name="gl-inet" gl_inet_board_detect ;; + *"GL-AR150") + name="gl-ar150" + ;; *"EnGenius EPG5000") name="epg5000" ;; diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh index d025632..59ee053 100755 --- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh +++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh @@ -211,6 +211,7 @@ platform_check_image() { dlan-pro-500-wp | \ dlan-pro-1200-ac | \ dragino2 | \ + gl-ar150 | \ epg5000 | \ esr1750 | \ esr900 | \ diff --git a/target/linux/ar71xx/config-3.18 b/target/linux/ar71xx/config-3.18 index e2ff826..3598a55 100644 --- a/target/linux/ar71xx/config-3.18 +++ b/target/linux/ar71xx/config-3.18 @@ -69,6 +69,7 @@ CONFIG_ATH79_MACH_ESR1750=y CONFIG_ATH79_MACH_ESR900=y CONFIG_ATH79_MACH_EW_DORIN=y CONFIG_ATH79_MACH_F9K1115V2=y +CONFIG_ATH79_MACH_GL_AR150=y CONFIG_ATH79_MACH_GL_INET=y CONFIG_ATH79_MACH_GS_MINIBOX_V1=y CONFIG_ATH79_MACH_GS_OOLITE=y diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar150.c b/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar150.c new file mode 100644 index 0000000..1e5e6ca --- /dev/null +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar150.c @@ -0,0 +1,125 @@ +/* + * GL_ar150 board support + * + * Copyright (C) 2011 dongyuqi <729650915 at qq.com> + * Copyright (C) 2011-2012 Gabor Juhos + * Copyright (C) 2013 alzhao + * Copyright (C) 2014 Michel Stempin + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 as published + * by the Free Software Foundation. +*/ + +#include + +#include + +#include "dev-eth.h" +#include "dev-gpio-buttons.h" +#include "dev-leds-gpio.h" +#include "dev-m25p80.h" +#include "dev-usb.h" +#include "dev-wmac.h" +#include "machtypes.h" + +#define GL_AR150_GPIO_LED_WLAN 0 +#define GL_AR150_GPIO_LED_LAN 13 +#define GL_AR150_GPIO_LED_WAN 15 + +#define GL_AR150_GPIO_BIN_USB 6 +#define GL_AR150_GPIO_BTN_MANUAL 7 +#define GL_AR150_GPIO_BTN_AUTO 8 +#define GL_AR150_GPIO_BTN_RESET 11 + +#define GL_AR150_KEYS_POLL_INTERVAL 20 /* msecs */ +#define GL_AR150_KEYS_DEBOUNCE_INTERVAL (3 * GL_AR150_KEYS_POLL_INTERVAL) + +#define GL_AR150_MAC0_OFFSET 0x0000 +#define GL_AR150_MAC1_OFFSET 0x0000 +#define GL_AR150_CALDATA_OFFSET 0x1000 +#define GL_AR150_WMAC_MAC_OFFSET 0x0000 + +static struct gpio_led gl_ar150_leds_gpio[] __initdata = { + { + .name = "gl_ar150:wlan", + .gpio = GL_AR150_GPIO_LED_WLAN, + .active_low = 0, + }, + { + .name = "gl_ar150:lan", + .gpio = GL_AR150_GPIO_LED_LAN, + .active_low = 0, + }, + { + .name = "gl_ar150:wan", + .gpio = GL_AR150_GPIO_LED_WAN, + .active_low = 0, + .default_state = 1, + }, +}; + +static struct gpio_keys_button gl_ar150_gpio_keys[] __initdata = { + { + .desc = "BTN_7", + .type = EV_KEY, + .code = BTN_7, + .debounce_interval = GL_AR150_KEYS_DEBOUNCE_INTERVAL, + .gpio = GL_AR150_GPIO_BTN_MANUAL, + .active_low = 0, + }, + { + .desc = "BTN_8", + .type = EV_KEY, + .code = BTN_8, + .debounce_interval = GL_AR150_KEYS_DEBOUNCE_INTERVAL, + .gpio = GL_AR150_GPIO_BTN_AUTO, + .active_low = 0, + }, + { + .desc = "reset", + .type = EV_KEY, + .code = KEY_RESTART, + .debounce_interval = GL_AR150_KEYS_DEBOUNCE_INTERVAL, + .gpio = GL_AR150_GPIO_BTN_RESET, + .active_low = 0, + }, +}; + +static void __init gl_ar150_setup(void) +{ + + /* ART base address */ + u8 *art = (u8 *) KSEG1ADDR(0x1fff0000); + + /* disable PHY_SWAP and PHY_ADDR_SWAP bits */ + ath79_setup_ar933x_phy4_switch(false, false); + + /* register flash. */ + ath79_register_m25p80(NULL); + + /* register gpio LEDs and keys */ + ath79_register_leds_gpio(-1, ARRAY_SIZE(gl_ar150_leds_gpio), + gl_ar150_leds_gpio); + ath79_register_gpio_keys_polled(-1, GL_AR150_KEYS_POLL_INTERVAL, + ARRAY_SIZE(gl_ar150_gpio_keys), + gl_ar150_gpio_keys); + + /* enable usb */ + gpio_request_one(GL_AR150_GPIO_BIN_USB, + GPIOF_OUT_INIT_HIGH | GPIOF_EXPORT_DIR_FIXED, + "USB power"); + ath79_register_usb(); + + /* register eth0 as WAN, eth1 as LAN */ + ath79_init_mac(ath79_eth0_data.mac_addr, art+GL_AR150_MAC0_OFFSET, 0); + ath79_init_mac(ath79_eth1_data.mac_addr, art+GL_AR150_MAC1_OFFSET, 0); + ath79_register_mdio(0, 0x0); + ath79_register_eth(0); + ath79_register_eth(1); + + /* register wireless mac with cal data */ + ath79_register_wmac(art + GL_AR150_CALDATA_OFFSET, art + GL_AR150_WMAC_MAC_OFFSET); +} + +MIPS_MACHINE(ATH79_MACH_GL_AR150, "GL-AR150", "GL-AR150",gl_ar150_setup); diff --git a/target/linux/ar71xx/generic/profiles/gl-connect.mk b/target/linux/ar71xx/generic/profiles/gl-connect.mk deleted file mode 100644 index e9377db..0000000 --- a/target/linux/ar71xx/generic/profiles/gl-connect.mk +++ /dev/null @@ -1,17 +0,0 @@ -# -# Copyright (C) 2014 OpenWrt.org -# -# This is free software, licensed under the GNU General Public License v2. -# See /LICENSE for more information. -# - -define Profile/GLINET - NAME:=GL.iNet - PACKAGES:=kmod-usb-core kmod-usb2 -endef - -define Profile/GLINET/Description - Package set optimized for the GL-Connect GL.iNet v1. -endef - -$(eval $(call Profile,GLINET)) diff --git a/target/linux/ar71xx/generic/profiles/gli.mk b/target/linux/ar71xx/generic/profiles/gli.mk new file mode 100644 index 0000000..89b2ead --- /dev/null +++ b/target/linux/ar71xx/generic/profiles/gli.mk @@ -0,0 +1,27 @@ +# +# Copyright (C) 2013 OpenWrt.org +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# +define Profile/GLINET + NAME:=GL.iNet 6416 + PACKAGES:=kmod-usb-core kmod-usb2 +endef + +define Profile/GLINET/Description + Package set optimized for the GL-Connect GL.iNet v1. +endef + +$(eval $(call Profile,GLINET)) + +define Profile/GL-AR150 + NAME:=GL-AR150 + PACKAGES:=kmod-usb-core kmod-usb2 +endef + +define Profile/GL-AR150/Description + Configuration of GL-AR150. +endef + +$(eval $(call Profile,GL-AR150)) diff --git a/target/linux/ar71xx/image/Makefile b/target/linux/ar71xx/image/Makefile index 9a7acbd..fc932e6 100644 --- a/target/linux/ar71xx/image/Makefile +++ b/target/linux/ar71xx/image/Makefile @@ -144,6 +144,14 @@ define Device/weio endef TARGET_DEVICES += weio +define Device/gl-ar150 + BOARDNAME = GL-AR150 + IMAGE_SIZE = 16000k + CONSOLE = ttyATH0,115200 + MTDPARTS = spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,16000k(firmware),64k(art)ro +endef +TARGET_DEVICES += gl-ar150 + define Device/wndr3700 BOARDNAME = WNDR3700 NETGEAR_KERNEL_MAGIC = 0x33373030 diff --git a/target/linux/ar71xx/patches-3.18/911-MIPS-ath79-add-gl_ar150.patch b/target/linux/ar71xx/patches-3.18/911-MIPS-ath79-add-gl_ar150.patch new file mode 100644 index 0000000..31db581 --- /dev/null +++ b/target/linux/ar71xx/patches-3.18/911-MIPS-ath79-add-gl_ar150.patch @@ -0,0 +1,39 @@ +--- a/arch/mips/ath79/Kconfig ++++ b/arch/mips/ath79/Kconfig +@@ -533,6 +533,16 @@ config ATH79_MACH_GL_INET + select ATH79_DEV_USB + select ATH79_DEV_WMAC + ++config ATH79_MACH_GL_AR150 ++ bool "GL AR150 support" ++ select SOC_AR933X ++ select ATH79_DEV_ETH ++ select ATH79_DEV_GPIO_BUTTONS ++ select ATH79_DEV_LEDS_GPIO ++ select ATH79_DEV_M25P80 ++ select ATH79_DEV_USB ++ select ATH79_DEV_WMAC ++ + config ATH79_MACH_EAP300V2 + bool "EnGenius EAP300 v2 support" + select SOC_AR934X +--- a/arch/mips/ath79/Makefile ++++ b/arch/mips/ath79/Makefile +@@ -78,6 +78,7 @@ obj-$(CONFIG_ATH79_MACH_EL_MINI) += mach + obj-$(CONFIG_ATH79_MACH_EPG5000) += mach-epg5000.o + obj-$(CONFIG_ATH79_MACH_ESR1750) += mach-esr1750.o + obj-$(CONFIG_ATH79_MACH_F9K1115V2) += mach-f9k1115v2.o ++obj-$(CONFIG_ATH79_MACH_GL_AR150) += mach-gl-ar150.o + obj-$(CONFIG_ATH79_MACH_GL_INET) += mach-gl-inet.o + obj-$(CONFIG_ATH79_MACH_GS_MINIBOX_V1) += mach-gs-minibox-v1.o + obj-$(CONFIG_ATH79_MACH_GS_OOLITE) += mach-gs-oolite.o +--- a/arch/mips/ath79/machtypes.h ++++ b/arch/mips/ath79/machtypes.h +@@ -67,6 +67,7 @@ enum ath79_mach_type { + ATH79_MACH_ESR1750, /* EnGenius ESR1750 */ + ATH79_MACH_EPG5000, /* EnGenius EPG5000 */ + ATH79_MACH_F9K1115V2, /* Belkin AC1750DB */ ++ ATH79_MACH_GL_AR150, /* GL-AR150 support */ + ATH79_MACH_GL_INET, /* GL-CONNECT GL-INET */ + ATH79_MACH_GS_MINIBOX_V1, /* Gainstrong MiniBox V1.0 */ + ATH79_MACH_GS_OOLITE, /* GS OOLITE V1.0 */ -- 1.9.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From alzhao at gmail.com Wed May 4 23:02:06 2016 From: alzhao at gmail.com (alzhao) Date: Thu, 5 May 2016 11:02:06 +0800 Subject: [OpenWrt-Devel] [PATCH 2/6] [CC] [backport] ar71xx: add GL-AR300 support In-Reply-To: <1462417330-12566-1-git-send-email-alzhao@gmail.com> References: <1462417330-12566-1-git-send-email-alzhao@gmail.com> Message-ID: <1462417330-12566-2-git-send-email-alzhao@gmail.com> Backport of changeset 47621 Add support for GL-AR300 Signed-off-by: alzhao --- .../ar71xx/base-files/etc/uci-defaults/01_leds | 4 + .../ar71xx/base-files/etc/uci-defaults/02_network | 6 ++ target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 + .../ar71xx/base-files/lib/upgrade/platform.sh | 1 + target/linux/ar71xx/config-3.18 | 1 + .../ar71xx/files/arch/mips/ath79/mach-gl-ar300.c | 106 +++++++++++++++++++++ target/linux/ar71xx/generic/profiles/gli.mk | 11 +++ target/linux/ar71xx/image/Makefile | 8 ++ .../patches-3.18/912-MIPS-ath79-add-gl_ar300.patch | 39 ++++++++ 9 files changed, 179 insertions(+) create mode 100644 target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar300.c create mode 100644 target/linux/ar71xx/patches-3.18/912-MIPS-ath79-add-gl_ar300.patch diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds index 0bd0b35..7c00947 100644 --- a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds @@ -185,6 +185,10 @@ gl-ar150) ucidef_set_led_wlan "wlan" "WLAN" "gl_ar150:wlan" "phy0tpt" ;; +gl-ar300) + ucidef_set_led_wlan "wlan" "WLAN" "gl_ar300:wlan" "phy0tpt" + ;; + gl-inet) ucidef_set_led_netdev "lan" "LAN" "gl-connect:green:lan" "eth1" ucidef_set_led_wlan "wlan" "WLAN" "gl-connect:red:wlan" "phy0tpt" diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network index c7ba875..3cd97ec 100755 --- a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network @@ -391,6 +391,12 @@ wpe72) ucidef_set_interfaces_lan_wan "eth1" "eth0" ;; +gl-ar300) + ucidef_set_interfaces_lan_wan "eth1" "eth0" + ucidef_add_switch "switch0" "1" "1" + ucidef_add_switch_vlan "switch0" "1" "0 1 2 3 4" + ;; + wpj344) ucidef_set_interfaces_lan_wan "eth0.1" "eth0.2" ucidef_add_switch "switch0" "1" "1" diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh b/target/linux/ar71xx/base-files/lib/ar71xx.sh index 813ff91..bc5dc17 100755 --- a/target/linux/ar71xx/base-files/lib/ar71xx.sh +++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh @@ -442,6 +442,9 @@ ar71xx_board_detect() { *"Dragino v2") name="dragino2" ;; + *"GL-AR300") + name="gl-ar300" + ;; *"EAP300 v2") name="eap300v2" ;; diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh index 59ee053..0800642 100755 --- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh +++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh @@ -212,6 +212,7 @@ platform_check_image() { dlan-pro-1200-ac | \ dragino2 | \ gl-ar150 | \ + gl-ar300 | \ epg5000 | \ esr1750 | \ esr900 | \ diff --git a/target/linux/ar71xx/config-3.18 b/target/linux/ar71xx/config-3.18 index 3598a55..4365232 100644 --- a/target/linux/ar71xx/config-3.18 +++ b/target/linux/ar71xx/config-3.18 @@ -70,6 +70,7 @@ CONFIG_ATH79_MACH_ESR900=y CONFIG_ATH79_MACH_EW_DORIN=y CONFIG_ATH79_MACH_F9K1115V2=y CONFIG_ATH79_MACH_GL_AR150=y +CONFIG_ATH79_MACH_GL_AR300=y CONFIG_ATH79_MACH_GL_INET=y CONFIG_ATH79_MACH_GS_MINIBOX_V1=y CONFIG_ATH79_MACH_GS_OOLITE=y diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar300.c b/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar300.c new file mode 100644 index 0000000..62fafad --- /dev/null +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar300.c @@ -0,0 +1,106 @@ +/* + * Domino board support + * + * Copyright (C) 2011 dongyuqi <729650915 at qq.com> + * Copyright (C) 2011-2012 Gabor Juhos + * Copyright (C) 2013 alzhao + * Copyright (C) 2014 Michel Stempin + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 as published + * by the Free Software Foundation. +*/ + +#include +#include +#include +#include +#include + +#include "common.h" +#include "dev-eth.h" +#include "dev-gpio-buttons.h" +#include "dev-leds-gpio.h" +#include "dev-m25p80.h" +#include "dev-usb.h" +#include "dev-wmac.h" +#include "machtypes.h" + +#define GL_AR300_GPIO_LED_WLAN 13 +#define GL_AR300_GPIO_LED_WAN 14 +#define GL_AR300_GPIO_BTN_RESET 16 + + +#define GL_AR300_KEYS_POLL_INTERVAL 20 /* msecs */ +#define GL_AR300_KEYS_DEBOUNCE_INTERVAL (3 * GL_AR300_KEYS_POLL_INTERVAL) + +#define GL_AR300_MAC0_OFFSET 0x0000 +#define GL_AR300_MAC1_OFFSET 0x0000 +#define GL_AR300_CALDATA_OFFSET 0x1000 +#define GL_AR300_WMAC_MAC_OFFSET 0x0000 + +static struct gpio_led gl_ar300_leds_gpio[] __initdata = { + { + .name = "gl_ar300:wlan", + .gpio = GL_AR300_GPIO_LED_WLAN, + .active_low = 1, + }, + { + .name = "gl_ar300:wan", + .gpio = GL_AR300_GPIO_LED_WAN, + .active_low = 1, + }, +}; + +static struct gpio_keys_button gl_ar300_gpio_keys[] __initdata = { + { + .desc = "reset", + .type = EV_KEY, + .code = KEY_RESTART, + .debounce_interval = GL_AR300_KEYS_DEBOUNCE_INTERVAL, + .gpio = GL_AR300_GPIO_BTN_RESET, + .active_low = 1, + }, +}; + +static void __init gl_ar300_setup(void) +{ + + /* ART base address */ + u8 *art = (u8 *) KSEG1ADDR(0x1fff0000); + + /* disable PHY_SWAP and PHY_ADDR_SWAP bits */ + //ath79_setup_ar933x_phy4_switch(false, false); + + /* register flash. */ + ath79_register_m25p80(NULL); + + /* register gpio LEDs and keys */ + ath79_register_leds_gpio(-1, ARRAY_SIZE(gl_ar300_leds_gpio), + gl_ar300_leds_gpio); + ath79_register_gpio_keys_polled(-1, GL_AR300_KEYS_POLL_INTERVAL, + ARRAY_SIZE(gl_ar300_gpio_keys), + gl_ar300_gpio_keys); + + /* enable usb */ + ath79_register_usb(); + ath79_register_mdio(1, 0x0); + + /* register eth0 as WAN, eth1 as LAN */ + ath79_init_mac(ath79_eth0_data.mac_addr, art+GL_AR300_MAC0_OFFSET, 0); + ath79_switch_data.phy4_mii_en = 1; + ath79_switch_data.phy_poll_mask = BIT(4); + ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_MII; + ath79_eth0_data.phy_mask = BIT(4); + ath79_eth0_data.mii_bus_dev = &ath79_mdio1_device.dev; + ath79_register_eth(0); + + ath79_init_mac(ath79_eth1_data.mac_addr, art+GL_AR300_MAC1_OFFSET, 0); + ath79_eth1_data.phy_if_mode = PHY_INTERFACE_MODE_GMII; + ath79_register_eth(1); + + /* register wireless mac with cal data */ + ath79_register_wmac(art + GL_AR300_CALDATA_OFFSET, art + GL_AR300_WMAC_MAC_OFFSET); +} + +MIPS_MACHINE(ATH79_MACH_GL_AR300, "GL-AR300", "GL-AR300",gl_ar300_setup); diff --git a/target/linux/ar71xx/generic/profiles/gli.mk b/target/linux/ar71xx/generic/profiles/gli.mk index 89b2ead..e399739 100644 --- a/target/linux/ar71xx/generic/profiles/gli.mk +++ b/target/linux/ar71xx/generic/profiles/gli.mk @@ -25,3 +25,14 @@ define Profile/GL-AR150/Description endef $(eval $(call Profile,GL-AR150)) + +define Profile/GL-AR300 + NAME:=GL-AR300 + PACKAGES:=kmod-usb-core kmod-usb2 +endef + +define Profile/GL-AR300/Description + Configuration of GL-AR300. +endef + +$(eval $(call Profile,GL-AR300)) diff --git a/target/linux/ar71xx/image/Makefile b/target/linux/ar71xx/image/Makefile index fc932e6..59bc919 100644 --- a/target/linux/ar71xx/image/Makefile +++ b/target/linux/ar71xx/image/Makefile @@ -152,6 +152,14 @@ define Device/gl-ar150 endef TARGET_DEVICES += gl-ar150 +define Device/gl-ar300 + BOARDNAME = GL-AR300 + IMAGE_SIZE = 16000k + CONSOLE = ttyS0,115200 + MTDPARTS = spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,16000k(firmware),64k(art)ro +endef +TARGET_DEVICES += gl-ar300 + define Device/wndr3700 BOARDNAME = WNDR3700 NETGEAR_KERNEL_MAGIC = 0x33373030 diff --git a/target/linux/ar71xx/patches-3.18/912-MIPS-ath79-add-gl_ar300.patch b/target/linux/ar71xx/patches-3.18/912-MIPS-ath79-add-gl_ar300.patch new file mode 100644 index 0000000..f7cfb57 --- /dev/null +++ b/target/linux/ar71xx/patches-3.18/912-MIPS-ath79-add-gl_ar300.patch @@ -0,0 +1,39 @@ +--- a/arch/mips/ath79/Kconfig ++++ b/arch/mips/ath79/Kconfig +@@ -543,6 +543,16 @@ config ATH79_MACH_GL_AR150 + select ATH79_DEV_USB + select ATH79_DEV_WMAC + ++config ATH79_MACH_GL_AR300 ++ bool "GL_AR300 support" ++ select SOC_AR934X ++ select ATH79_DEV_ETH ++ select ATH79_DEV_GPIO_BUTTONS ++ select ATH79_DEV_LEDS_GPIO ++ select ATH79_DEV_M25P80 ++ select ATH79_DEV_USB ++ select ATH79_DEV_WMAC ++ + config ATH79_MACH_EAP300V2 + bool "EnGenius EAP300 v2 support" + select SOC_AR934X +--- a/arch/mips/ath79/Makefile ++++ b/arch/mips/ath79/Makefile +@@ -79,6 +79,7 @@ obj-$(CONFIG_ATH79_MACH_EPG5000) += mach + obj-$(CONFIG_ATH79_MACH_ESR1750) += mach-esr1750.o + obj-$(CONFIG_ATH79_MACH_F9K1115V2) += mach-f9k1115v2.o + obj-$(CONFIG_ATH79_MACH_GL_AR150) += mach-gl-ar150.o ++obj-$(CONFIG_ATH79_MACH_GL_AR300) += mach-gl-ar300.o + obj-$(CONFIG_ATH79_MACH_GL_INET) += mach-gl-inet.o + obj-$(CONFIG_ATH79_MACH_GS_MINIBOX_V1) += mach-gs-minibox-v1.o + obj-$(CONFIG_ATH79_MACH_GS_OOLITE) += mach-gs-oolite.o +--- a/arch/mips/ath79/machtypes.h ++++ b/arch/mips/ath79/machtypes.h +@@ -68,6 +68,7 @@ enum ath79_mach_type { + ATH79_MACH_EPG5000, /* EnGenius EPG5000 */ + ATH79_MACH_F9K1115V2, /* Belkin AC1750DB */ + ATH79_MACH_GL_AR150, /* GL-AR150 support */ ++ ATH79_MACH_GL_AR300, /* GL-AR300 */ + ATH79_MACH_GL_INET, /* GL-CONNECT GL-INET */ + ATH79_MACH_GS_MINIBOX_V1, /* Gainstrong MiniBox V1.0 */ + ATH79_MACH_GS_OOLITE, /* GS OOLITE V1.0 */ -- 1.9.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From alzhao at gmail.com Wed May 4 23:02:07 2016 From: alzhao at gmail.com (alzhao) Date: Thu, 5 May 2016 11:02:07 +0800 Subject: [OpenWrt-Devel] [PATCH 3/6] [CC] [backport] ar71xx: add GL-Domino Pi support In-Reply-To: <1462417330-12566-1-git-send-email-alzhao@gmail.com> References: <1462417330-12566-1-git-send-email-alzhao@gmail.com> Message-ID: <1462417330-12566-3-git-send-email-alzhao@gmail.com> Backport of changeset 47622 Add GL-Domino Pi dev board support Signed-off-by: alzhao --- .../ar71xx/base-files/etc/uci-defaults/01_leds | 4 + .../ar71xx/base-files/etc/uci-defaults/02_network | 1 + target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 + .../ar71xx/base-files/lib/upgrade/platform.sh | 1 + target/linux/ar71xx/config-3.18 | 1 + .../ar71xx/files/arch/mips/ath79/mach-gl-domino.c | 136 +++++++++++++++++++++ target/linux/ar71xx/generic/profiles/gli.mk | 11 ++ target/linux/ar71xx/image/Makefile | 8 ++ .../913-MIPS-ath79-add-domino-support.patch | 39 ++++++ 9 files changed, 204 insertions(+) create mode 100644 target/linux/ar71xx/files/arch/mips/ath79/mach-gl-domino.c create mode 100644 target/linux/ar71xx/patches-3.18/913-MIPS-ath79-add-domino-support.patch diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds index 7c00947..8f7a6f9 100644 --- a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds @@ -189,6 +189,10 @@ gl-ar300) ucidef_set_led_wlan "wlan" "WLAN" "gl_ar300:wlan" "phy0tpt" ;; +gl-domino) + ucidef_set_led_wlan "wlan" "WLAN" "domino:blue:wlan" "phy0tpt" + ;; + gl-inet) ucidef_set_led_netdev "lan" "LAN" "gl-connect:green:lan" "eth1" ucidef_set_led_wlan "wlan" "WLAN" "gl-connect:red:wlan" "phy0tpt" diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network index 3cd97ec..781172c 100755 --- a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network @@ -380,6 +380,7 @@ alfa-ap96 |\ alfa-nx |\ ap83 |\ gl-ar150 |\ +gl-domino |\ gl-inet |\ jwap003 |\ pb42 |\ diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh b/target/linux/ar71xx/base-files/lib/ar71xx.sh index bc5dc17..5349009 100755 --- a/target/linux/ar71xx/base-files/lib/ar71xx.sh +++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh @@ -442,6 +442,9 @@ ar71xx_board_detect() { *"Dragino v2") name="dragino2" ;; + *"Domino Pi") + name="gl-domino" + ;; *"GL-AR300") name="gl-ar300" ;; diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh index 0800642..699c27e 100755 --- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh +++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh @@ -213,6 +213,7 @@ platform_check_image() { dragino2 | \ gl-ar150 | \ gl-ar300 | \ + gl-domino | \ epg5000 | \ esr1750 | \ esr900 | \ diff --git a/target/linux/ar71xx/config-3.18 b/target/linux/ar71xx/config-3.18 index 4365232..3f713df 100644 --- a/target/linux/ar71xx/config-3.18 +++ b/target/linux/ar71xx/config-3.18 @@ -71,6 +71,7 @@ CONFIG_ATH79_MACH_EW_DORIN=y CONFIG_ATH79_MACH_F9K1115V2=y CONFIG_ATH79_MACH_GL_AR150=y CONFIG_ATH79_MACH_GL_AR300=y +CONFIG_ATH79_MACH_GL_DOMINO=y CONFIG_ATH79_MACH_GL_INET=y CONFIG_ATH79_MACH_GS_MINIBOX_V1=y CONFIG_ATH79_MACH_GS_OOLITE=y diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-domino.c b/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-domino.c new file mode 100644 index 0000000..a8a42ad --- /dev/null +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-domino.c @@ -0,0 +1,136 @@ +/* + * Domino board support + * + * Copyright (C) 2011 dongyuqi <729650915 at qq.com> + * Copyright (C) 2011-2012 Gabor Juhos + * Copyright (C) 2013 alzhao + * Copyright (C) 2014 Michel Stempin + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 as published + * by the Free Software Foundation. +*/ + +#include + +#include + +#include "dev-eth.h" +#include "dev-gpio-buttons.h" +#include "dev-leds-gpio.h" +#include "dev-m25p80.h" +#include "dev-usb.h" +#include "dev-wmac.h" +#include "machtypes.h" + +#define DOMINO_GPIO_LED_WLAN 0 +#define DOMINO_GPIO_LED_WAN 17 +#define DOMINO_GPIO_LED_USB 1 +#define DOMINO_GPIO_LED_LAN1 13 +#define DOMINO_GPIO_LED_LAN2 14 +#define DOMINO_GPIO_LED_LAN3 15 +#define DOMINO_GPIO_LED_LAN4 16 +#define DOMINO_GPIO_LED_SYS 27 +#define DOMINO_GPIO_LED_WPS 26 +#define DOMINO_GPIO_USB_POWER 6 + +#define DOMINO_GPIO_BTN_RESET 11 +#define DOMINO_GPIO_BTN_WPS 20 + +#define DOMINO_KEYS_POLL_INTERVAL 20 /* msecs */ +#define DOMINO_KEYS_DEBOUNCE_INTERVAL (3 * DOMINO_KEYS_POLL_INTERVAL) + +#define DOMINO_MAC0_OFFSET 0x0000 +#define DOMINO_MAC1_OFFSET 0x0000 +#define DOMINO_CALDATA_OFFSET 0x1000 +#define DOMINO_WMAC_MAC_OFFSET 0x0000 + +static struct gpio_led domino_leds_gpio[] __initdata = { + { + .name = "domino:blue:wlan", + .gpio = DOMINO_GPIO_LED_WLAN, + .active_low = 0, + }, + { + .name = "domino:red:wan", + .gpio = DOMINO_GPIO_LED_WAN, + .active_low = 1, + }, + { + .name = "domino:white:usb", + .gpio = DOMINO_GPIO_LED_USB, + .active_low = 0, + }, + { + .name = "domino:green:lan1", + .gpio = DOMINO_GPIO_LED_LAN1, + .active_low = 0, + }, + { + .name = "domino:yellow:wps", + .gpio = DOMINO_GPIO_LED_WPS, + .active_low = 1, + }, + { + .name = "domino:orange:sys", + .gpio = DOMINO_GPIO_LED_SYS, + .active_low = 1, + }, +}; + +static struct gpio_keys_button domino_gpio_keys[] __initdata = { + { + .desc = "reset", + .type = EV_KEY, + .code = KEY_RESTART, + .debounce_interval = DOMINO_KEYS_DEBOUNCE_INTERVAL, + .gpio = DOMINO_GPIO_BTN_RESET, + .active_low = 0, + }, + { + .desc = "wps", + .type = EV_KEY, + .code = KEY_WPS_BUTTON, + .debounce_interval = DOMINO_KEYS_DEBOUNCE_INTERVAL, + .gpio = DOMINO_GPIO_BTN_WPS, + .active_low = 0, + } +}; + +static void __init domino_setup(void) +{ + + /* ART base address */ + u8 *art = (u8 *) KSEG1ADDR(0x1fff0000); + + /* disable PHY_SWAP and PHY_ADDR_SWAP bits */ + ath79_setup_ar933x_phy4_switch(false, false); + + /* register flash. */ + ath79_register_m25p80(NULL); + + /* register gpio LEDs and keys */ + ath79_register_leds_gpio(-1, ARRAY_SIZE(domino_leds_gpio), + domino_leds_gpio); + ath79_register_gpio_keys_polled(-1, DOMINO_KEYS_POLL_INTERVAL, + ARRAY_SIZE(domino_gpio_keys), + domino_gpio_keys); + + gpio_request_one(DOMINO_GPIO_USB_POWER, + GPIOF_OUT_INIT_HIGH | GPIOF_EXPORT_DIR_FIXED, + "USB power"); + /* enable usb */ + ath79_register_usb(); + + /* register eth0 as WAN, eth1 as LAN */ + ath79_init_mac(ath79_eth0_data.mac_addr, art+DOMINO_MAC0_OFFSET, 0); + ath79_init_mac(ath79_eth1_data.mac_addr, art+DOMINO_MAC1_OFFSET, 0); + ath79_register_mdio(0, 0x0); + ath79_register_eth(0); + ath79_register_eth(1); + + /* register wireless mac with cal data */ + ath79_register_wmac(art + DOMINO_CALDATA_OFFSET, art + DOMINO_WMAC_MAC_OFFSET); +} + +MIPS_MACHINE(ATH79_MACH_GL_DOMINO, "DOMINO", "Domino Pi", domino_setup); diff --git a/target/linux/ar71xx/generic/profiles/gli.mk b/target/linux/ar71xx/generic/profiles/gli.mk index e399739..3ad1f9d 100644 --- a/target/linux/ar71xx/generic/profiles/gli.mk +++ b/target/linux/ar71xx/generic/profiles/gli.mk @@ -36,3 +36,14 @@ define Profile/GL-AR300/Description endef $(eval $(call Profile,GL-AR300)) + +define Profile/DOMINO + NAME:=GL Domino Pi + PACKAGES:=kmod-usb-core kmod-usb2 +endef + +define Profile/DOMINO/Description + Configuration of Domino, Wifi for everything. +endef + +$(eval $(call Profile,DOMINO)) diff --git a/target/linux/ar71xx/image/Makefile b/target/linux/ar71xx/image/Makefile index 59bc919..19f4bc0 100644 --- a/target/linux/ar71xx/image/Makefile +++ b/target/linux/ar71xx/image/Makefile @@ -160,6 +160,14 @@ define Device/gl-ar300 endef TARGET_DEVICES += gl-ar300 +define Device/gl-domino + BOARDNAME = DOMINO + IMAGE_SIZE = 16000k + CONSOLE = ttyATH0,115200 + MTDPARTS = spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,16000k(firmware),64k(art)ro +endef +TARGET_DEVICES += gl-domino + define Device/wndr3700 BOARDNAME = WNDR3700 NETGEAR_KERNEL_MAGIC = 0x33373030 diff --git a/target/linux/ar71xx/patches-3.18/913-MIPS-ath79-add-domino-support.patch b/target/linux/ar71xx/patches-3.18/913-MIPS-ath79-add-domino-support.patch new file mode 100644 index 0000000..69c3a0f --- /dev/null +++ b/target/linux/ar71xx/patches-3.18/913-MIPS-ath79-add-domino-support.patch @@ -0,0 +1,39 @@ +--- a/arch/mips/ath79/Kconfig ++++ b/arch/mips/ath79/Kconfig +@@ -553,6 +553,16 @@ config ATH79_MACH_GL_AR300 + select ATH79_DEV_USB + select ATH79_DEV_WMAC + ++config ATH79_MACH_GL_DOMINO ++ bool "DOMINO support" ++ select SOC_AR933X ++ select ATH79_DEV_ETH ++ select ATH79_DEV_GPIO_BUTTONS ++ select ATH79_DEV_LEDS_GPIO ++ select ATH79_DEV_M25P80 ++ select ATH79_DEV_USB ++ select ATH79_DEV_WMAC ++ + config ATH79_MACH_EAP300V2 + bool "EnGenius EAP300 v2 support" + select SOC_AR934X +--- a/arch/mips/ath79/Makefile ++++ b/arch/mips/ath79/Makefile +@@ -80,6 +80,7 @@ obj-$(CONFIG_ATH79_MACH_ESR1750) += mach + obj-$(CONFIG_ATH79_MACH_F9K1115V2) += mach-f9k1115v2.o + obj-$(CONFIG_ATH79_MACH_GL_AR150) += mach-gl-ar150.o + obj-$(CONFIG_ATH79_MACH_GL_AR300) += mach-gl-ar300.o ++obj-$(CONFIG_ATH79_MACH_GL_DOMINO) += mach-gl-domino.o + obj-$(CONFIG_ATH79_MACH_GL_INET) += mach-gl-inet.o + obj-$(CONFIG_ATH79_MACH_GS_MINIBOX_V1) += mach-gs-minibox-v1.o + obj-$(CONFIG_ATH79_MACH_GS_OOLITE) += mach-gs-oolite.o +--- a/arch/mips/ath79/machtypes.h ++++ b/arch/mips/ath79/machtypes.h +@@ -69,6 +69,7 @@ enum ath79_mach_type { + ATH79_MACH_F9K1115V2, /* Belkin AC1750DB */ + ATH79_MACH_GL_AR150, /* GL-AR150 support */ + ATH79_MACH_GL_AR300, /* GL-AR300 */ ++ ATH79_MACH_GL_DOMINO, /* Domino */ + ATH79_MACH_GL_INET, /* GL-CONNECT GL-INET */ + ATH79_MACH_GS_MINIBOX_V1, /* Gainstrong MiniBox V1.0 */ + ATH79_MACH_GS_OOLITE, /* GS OOLITE V1.0 */ -- 1.9.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From alzhao at gmail.com Wed May 4 23:02:08 2016 From: alzhao at gmail.com (alzhao) Date: Thu, 5 May 2016 11:02:08 +0800 Subject: [OpenWrt-Devel] [PATCH 4/6] [CC] [backport] ramips: Add GL-MT300A support In-Reply-To: <1462417330-12566-1-git-send-email-alzhao@gmail.com> References: <1462417330-12566-1-git-send-email-alzhao@gmail.com> Message-ID: <1462417330-12566-4-git-send-email-alzhao@gmail.com> Backport of changeset 48992 Add GL-MT300A support Signed-off-by: alzhao --- target/linux/ramips/base-files/etc/board.d/01_leds | 3 + .../linux/ramips/base-files/etc/board.d/02_network | 7 + target/linux/ramips/base-files/lib/ramips.sh | 3 + .../ramips/base-files/lib/upgrade/platform.sh | 1 + target/linux/ramips/dts/GL-MT300A.dts | 164 +++++++++++++++++++++ target/linux/ramips/image/Makefile | 2 + target/linux/ramips/mt7620/profiles/gli.mk | 16 ++ 7 files changed, 196 insertions(+) create mode 100644 target/linux/ramips/dts/GL-MT300A.dts create mode 100644 target/linux/ramips/mt7620/profiles/gli.mk diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds b/target/linux/ramips/base-files/etc/board.d/01_leds index 5327d00..a3661e8 100755 --- a/target/linux/ramips/base-files/etc/board.d/01_leds +++ b/target/linux/ramips/base-files/etc/board.d/01_leds @@ -147,6 +147,9 @@ case $board in mofi3500-3gn) set_usb_led "mofi3500-3gn:green:usb" ;; + gl-mt300a) + set_wifi_led "gl-mt300a:wlan" + ;; mpr-a1) set_wifi_led "hame:blue:system" ;; diff --git a/target/linux/ramips/base-files/etc/board.d/02_network b/target/linux/ramips/base-files/etc/board.d/02_network index a78912d..b5c2b81 100755 --- a/target/linux/ramips/base-files/etc/board.d/02_network +++ b/target/linux/ramips/base-files/etc/board.d/02_network @@ -153,6 +153,13 @@ ramips_setup_interfaces() ucidef_add_switch_vlan "switch0" "1" "0 1 2 3 6t" ucidef_add_switch_vlan "switch0" "2" "4 6t" ;; + + gl-mt300a) + ucidef_set_interfaces_lan_wan "eth0.1" "eth0.2" + ucidef_add_switch "switch0" "1" "1" + ucidef_add_switch_vlan "switch0" "2" "0 6t" + ucidef_add_switch_vlan "switch0" "1" "1 2 3 4 6t" + ;; whr-1166d) ucidef_set_interfaces_lan_wan "eth0.1" "eth0.2" diff --git a/target/linux/ramips/base-files/lib/ramips.sh b/target/linux/ramips/base-files/lib/ramips.sh index 8dc05b0..40c26e6 100755 --- a/target/linux/ramips/base-files/lib/ramips.sh +++ b/target/linux/ramips/base-files/lib/ramips.sh @@ -169,6 +169,9 @@ ramips_board_detect() { *"F5D8235 v2") name="f5d8235-v2" ;; + *"GL-MT300A") + name="gl-mt300a" + ;; *"Hauppauge Broadway") name="broadway" ;; diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh b/target/linux/ramips/base-files/lib/upgrade/platform.sh index a3d0175..cfd44d7 100755 --- a/target/linux/ramips/base-files/lib/upgrade/platform.sh +++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh @@ -55,6 +55,7 @@ platform_check_image() { fonera20n | \ freestation5 | \ firewrt |\ + gl-mt300a |\ pbr-m1 |\ hg255d | \ hlk-rm04 | \ diff --git a/target/linux/ramips/dts/GL-MT300A.dts b/target/linux/ramips/dts/GL-MT300A.dts new file mode 100644 index 0000000..c1eb0a9 --- /dev/null +++ b/target/linux/ramips/dts/GL-MT300A.dts @@ -0,0 +1,164 @@ +/dts-v1/; + +/include/ "mt7620a.dtsi" + +/ { + compatible = "GL-MT300A", "ralink,mt7620a-soc"; + model = "GL-MT300A"; + + chosen { + bootargs = "console=ttyS0,115200"; + }; + + palmbus at 10000000 { + gpio0: gpio at 600 { + status = "okay"; + }; + + gpio1: gpio at 638 { + status = "okay"; + }; + + gpio2: gpio at 660 { + status = "okay"; + }; + + gpio3: gpio at 688 { + status = "okay"; + }; + + spi at b00 { + status = "okay"; + + m25p80 at 0 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "w25q128"; + reg = <0 0>; + linux,modalias = "m25p80", "w25q128"; + spi-max-frequency = <10000000>; + + partition at 0 { + label = "u-boot"; + reg = <0x0 0x30000>; + }; + + partition at 30000 { + label = "u-boot-env"; + reg = <0x30000 0x10000>; + read-only; + }; + + factory: partition at 40000 { + label = "factory"; + reg = <0x40000 0x10000>; + read-only; + }; + + partition at 50000 { + label = "firmware"; + reg = <0x50000 0xf80000>; + }; + + partition at ff0000 { + label = "art"; + reg = <0xff0000 0x10000>; + }; + }; + }; + }; + + sdhci at 10130000 { + status = "okay"; + }; + + ehci at 101c0000 { + status = "okay"; + }; + + ohci at 101c1000 { + status = "okay"; + }; + + ethernet at 10100000 { + pinctrl-names = "default"; + pinctrl-0 = <&ephy_pins>; + mtd-mac-address = <&factory 0x4000>; + ralink,port-map = "wllll"; + }; + + wmac at 10180000 { + ralink,mtd-eeprom = <&factory 0>; + }; + + pcie at 10140000 { + status = "okay"; + + pcie-bridge { + mt76 at 0,0 { + reg = <0x0000 0 0 0 0>; + device_type = "pci"; + mediatek,mtd-eeprom = <&factory 0x8000>; + mediatek,2ghz = <0>; + }; + }; + }; + + pinctrl { + state_default: pinctrl0 { + gpio { + ralink,group = "wled","ephy","uartf","i2c"; + ralink,function = "gpio"; + }; + }; + }; + + gpio-leds { + compatible = "gpio-leds"; + + wan { + label = "gl-mt300a:wan"; + gpios = <&gpio2 0 1>; + }; + + lan { + label = "gl-mt300a:lan"; + gpios = <&gpio2 1 1>; + }; + + wlan { + label = "gl-mt300a:wlan"; + gpios = <&gpio3 0 1>; + }; + + usb { + label = "gl-mt300a:usb"; + gpios = <&gpio0 7 1>; + }; + + }; + + gpio-keys-polled { + compatible = "gpio-keys-polled"; + #address-cells = <1>; + #size-cells = <0>; + poll-interval = <20>; + reset { + label = "reset"; + gpios = <&gpio0 13 1>; + linux,code = <0x198>; + }; + + BTN_0 { + label = "BTN_0"; + gpios = <&gpio0 1 1>; + linux,code = <0x100>; + }; + + BTN_1 { + label = "BTN_1"; + gpios = <&gpio0 2 1>; + linux,code = <0x101>; + }; + }; +}; diff --git a/target/linux/ramips/image/Makefile b/target/linux/ramips/image/Makefile index c4f4028..d4991ad 100644 --- a/target/linux/ramips/image/Makefile +++ b/target/linux/ramips/image/Makefile @@ -910,6 +910,7 @@ Image/Build/Profile/WR8305RT=$(call BuildFirmware/Default8M/$(1),$(1),wr8305rt,W Image/Build/Profile/WRTNODE=$(call BuildFirmware/Default16M/$(1),$(1),wrtnode,WRTNODE) Image/Build/Profile/WT3020=$(call BuildFirmware/PorayDualSize/$(1),$(1),wt3020,WT3020) Image/Build/Profile/XIAOMI-MIWIFI-MINI=$(call BuildFirmware/Default16M/$(1),$(1),xiaomi-miwifi-mini,XIAOMI-MIWIFI-MINI) +Image/Build/Profile/GL-MT300A=$(call BuildFirmware/Default16M/$(1),$(1),gl-mt300a,GL-MT300A) Image/Build/Profile/ZTE-Q7=$(call BuildFirmware/Default8M/$(1),$(1),zte-q7,ZTE-Q7) Image/Build/Profile/ZBT-WA05=$(call BuildFirmware/Default8M/$(1),$(1),zbt-wa05,ZBT-WA05) Image/Build/Profile/ArcherC20i=$(call BuildFirmware/Tplink/$(1),$(1),ArcherC20i,ArcherC20i) @@ -944,6 +945,7 @@ define Image/Build/Profile/Default $(call Image/Build/Profile/WRTNODE,$(1)) $(call Image/Build/Profile/WT3020,$(1)) $(call Image/Build/Profile/XIAOMI-MIWIFI-MINI,$(1)) + $(call Image/Build/Profile/GL-MT300A,$(1)) $(call Image/Build/Profile/ZTE-Q7,$(1)) $(call Image/Build/Profile/ZBT-WA05,$(1)) $(call Image/Build/Profile/ArcherC20i,$(1)) diff --git a/target/linux/ramips/mt7620/profiles/gli.mk b/target/linux/ramips/mt7620/profiles/gli.mk new file mode 100644 index 0000000..53e2e9d --- /dev/null +++ b/target/linux/ramips/mt7620/profiles/gli.mk @@ -0,0 +1,16 @@ +# +# Copyright (C) 2015 OpenWrt.org +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# + +define Profile/GL-MT300A + NAME:=GL-MT300A + PACKAGES:=kmod-usb-core kmod-usb-dwc2 kmod-usb2 kmod-usb-ohci kmod-mt76 +endef + +define Profile/GL-MT300A/Description + Support for gl-mt300a Router +endef +$(eval $(call Profile,GL-MT300A)) -- 1.9.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From alzhao at gmail.com Wed May 4 23:02:09 2016 From: alzhao at gmail.com (alzhao) Date: Thu, 5 May 2016 11:02:09 +0800 Subject: [OpenWrt-Devel] [PATCH 5/6] [CC] [backport] ramips: add GL-MT300N support In-Reply-To: <1462417330-12566-1-git-send-email-alzhao@gmail.com> References: <1462417330-12566-1-git-send-email-alzhao@gmail.com> Message-ID: <1462417330-12566-5-git-send-email-alzhao@gmail.com> Backport changeset 48993 Add GL-MT300N support to CC Signed-off-by: alzhao --- target/linux/ramips/base-files/etc/board.d/01_leds | 3 + .../linux/ramips/base-files/etc/board.d/02_network | 7 + target/linux/ramips/base-files/lib/ramips.sh | 3 + .../ramips/base-files/lib/upgrade/platform.sh | 1 + target/linux/ramips/dts/GL-MT300N.dts | 153 +++++++++++++++++++++ target/linux/ramips/image/Makefile | 2 + target/linux/ramips/mt7620/profiles/gli.mk | 10 ++ 7 files changed, 179 insertions(+) create mode 100644 target/linux/ramips/dts/GL-MT300N.dts diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds b/target/linux/ramips/base-files/etc/board.d/01_leds index a3661e8..3886e49 100755 --- a/target/linux/ramips/base-files/etc/board.d/01_leds +++ b/target/linux/ramips/base-files/etc/board.d/01_leds @@ -150,6 +150,9 @@ case $board in gl-mt300a) set_wifi_led "gl-mt300a:wlan" ;; + gl-mt300n) + set_wifi_led "gl-mt300n:wlan" + ;; mpr-a1) set_wifi_led "hame:blue:system" ;; diff --git a/target/linux/ramips/base-files/etc/board.d/02_network b/target/linux/ramips/base-files/etc/board.d/02_network index b5c2b81..1e91039 100755 --- a/target/linux/ramips/base-files/etc/board.d/02_network +++ b/target/linux/ramips/base-files/etc/board.d/02_network @@ -160,6 +160,13 @@ ramips_setup_interfaces() ucidef_add_switch_vlan "switch0" "2" "0 6t" ucidef_add_switch_vlan "switch0" "1" "1 2 3 4 6t" ;; + + gl-mt300n) + ucidef_set_interfaces_lan_wan "eth0.1" "eth0.2" + ucidef_add_switch "switch0" "1" "1" + ucidef_add_switch_vlan "switch0" "2" "0 6t" + ucidef_add_switch_vlan "switch0" "1" "1 2 3 4 6t" + ;; whr-1166d) ucidef_set_interfaces_lan_wan "eth0.1" "eth0.2" diff --git a/target/linux/ramips/base-files/lib/ramips.sh b/target/linux/ramips/base-files/lib/ramips.sh index 40c26e6..3ebb1b0 100755 --- a/target/linux/ramips/base-files/lib/ramips.sh +++ b/target/linux/ramips/base-files/lib/ramips.sh @@ -172,6 +172,9 @@ ramips_board_detect() { *"GL-MT300A") name="gl-mt300a" ;; + *"GL-MT300N") + name="gl-mt300n" + ;; *"Hauppauge Broadway") name="broadway" ;; diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh b/target/linux/ramips/base-files/lib/upgrade/platform.sh index cfd44d7..7825af8 100755 --- a/target/linux/ramips/base-files/lib/upgrade/platform.sh +++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh @@ -56,6 +56,7 @@ platform_check_image() { freestation5 | \ firewrt |\ gl-mt300a |\ + gl-mt300n |\ pbr-m1 |\ hg255d | \ hlk-rm04 | \ diff --git a/target/linux/ramips/dts/GL-MT300N.dts b/target/linux/ramips/dts/GL-MT300N.dts new file mode 100644 index 0000000..82db37e --- /dev/null +++ b/target/linux/ramips/dts/GL-MT300N.dts @@ -0,0 +1,153 @@ +/dts-v1/; + +/include/ "mt7620n.dtsi" + +/ { + compatible = "GL-MT300N", "ralink,mt7620n-soc"; + model = "GL-MT300N"; + + chosen { + bootargs = "console=ttyS0,115200"; + }; + + palmbus at 10000000 { + gpio0: gpio at 600 { + status = "okay"; + }; + + gpio1: gpio at 638 { + status = "okay"; + }; + + gpio2: gpio at 660 { + status = "okay"; + }; + + gpio3: gpio at 688 { + status = "okay"; + }; + + spi at b00 { + status = "okay"; + + m25p80 at 0 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "w25q128"; + reg = <0 0>; + linux,modalias = "m25p80", "w25q128"; + spi-max-frequency = <10000000>; + + partition at 0 { + label = "u-boot"; + reg = <0x0 0x30000>; + }; + + partition at 30000 { + label = "u-boot-env"; + reg = <0x30000 0x10000>; + read-only; + }; + + factory: partition at 40000 { + label = "factory"; + reg = <0x40000 0x10000>; + read-only; + }; + + partition at 50000 { + label = "firmware"; + reg = <0x50000 0xf80000>; + }; + + partition at ff0000 { + label = "art"; + reg = <0xff0000 0x10000>; + }; + }; + }; + }; + + ehci at 101c0000 { + status = "okay"; + }; + + ohci at 101c1000 { + status = "okay"; + }; + + ethernet at 10100000 { + mtd-mac-address = <&factory 0x4000>; + ralink,port-map = "wllll"; + }; + + wmac at 10180000 { + ralink,mtd-eeprom = <&factory 0>; + }; + + pcie at 10140000 { + status = "okay"; + + pcie-bridge { + mt76 at 0,0 { + reg = <0x0000 0 0 0 0>; + device_type = "pci"; + mediatek,mtd-eeprom = <&factory 0x8000>; + mediatek,2ghz = <0>; + }; + }; + }; + + pinctrl { + state_default: pinctrl0 { + gpio { + ralink,group = "wled","ephy","i2c"; + ralink,function = "gpio"; + }; + }; + }; + + gpio-leds { + compatible = "gpio-leds"; + + wan { + label = "gl-mt300n:wan"; + gpios = <&gpio2 0 1>; + }; + + lan { + label = "gl-mt300n:lan"; + gpios = <&gpio2 1 1>; + }; + + wlan { + label = "gl-mt300n:wlan"; + gpios = <&gpio3 0 1>; + }; + + }; + + gpio-keys-polled { + compatible = "gpio-keys-polled"; + #address-cells = <1>; + #size-cells = <0>; + poll-interval = <20>; + reset { + label = "reset"; + gpios = <&gpio0 1 1>; + linux,code = <0x198>; + }; + + BTN_0 { + label = "BTN_0"; + gpios = <&gpio2 2 1>; + linux,code = <0x100>; + }; + + BTN_1 { + label = "BTN_1"; + gpios = <&gpio2 3 1>; + linux,code = <0x101>; + }; + }; +}; diff --git a/target/linux/ramips/image/Makefile b/target/linux/ramips/image/Makefile index d4991ad..9f83b1c 100644 --- a/target/linux/ramips/image/Makefile +++ b/target/linux/ramips/image/Makefile @@ -911,6 +911,7 @@ Image/Build/Profile/WRTNODE=$(call BuildFirmware/Default16M/$(1),$(1),wrtnode,WR Image/Build/Profile/WT3020=$(call BuildFirmware/PorayDualSize/$(1),$(1),wt3020,WT3020) Image/Build/Profile/XIAOMI-MIWIFI-MINI=$(call BuildFirmware/Default16M/$(1),$(1),xiaomi-miwifi-mini,XIAOMI-MIWIFI-MINI) Image/Build/Profile/GL-MT300A=$(call BuildFirmware/Default16M/$(1),$(1),gl-mt300a,GL-MT300A) +Image/Build/Profile/GL-MT300N=$(call BuildFirmware/Default16M/$(1),$(1),gl-mt300n,GL-MT300N) Image/Build/Profile/ZTE-Q7=$(call BuildFirmware/Default8M/$(1),$(1),zte-q7,ZTE-Q7) Image/Build/Profile/ZBT-WA05=$(call BuildFirmware/Default8M/$(1),$(1),zbt-wa05,ZBT-WA05) Image/Build/Profile/ArcherC20i=$(call BuildFirmware/Tplink/$(1),$(1),ArcherC20i,ArcherC20i) @@ -946,6 +947,7 @@ define Image/Build/Profile/Default $(call Image/Build/Profile/WT3020,$(1)) $(call Image/Build/Profile/XIAOMI-MIWIFI-MINI,$(1)) $(call Image/Build/Profile/GL-MT300A,$(1)) + $(call Image/Build/Profile/GL-MT300N,$(1)) $(call Image/Build/Profile/ZTE-Q7,$(1)) $(call Image/Build/Profile/ZBT-WA05,$(1)) $(call Image/Build/Profile/ArcherC20i,$(1)) diff --git a/target/linux/ramips/mt7620/profiles/gli.mk b/target/linux/ramips/mt7620/profiles/gli.mk index 53e2e9d..ce407e2 100644 --- a/target/linux/ramips/mt7620/profiles/gli.mk +++ b/target/linux/ramips/mt7620/profiles/gli.mk @@ -14,3 +14,13 @@ define Profile/GL-MT300A/Description Support for gl-mt300a Router endef $(eval $(call Profile,GL-MT300A)) + +define Profile/GL-MT300N + NAME:=GL-MT300N + PACKAGES:=kmod-usb-core kmod-usb-dwc2 kmod-usb2 kmod-usb-ohci kmod-mt76 +endef + +define Profile/GL-MT300N/Description + Support for gl-mt300n Router +endef +$(eval $(call Profile,GL-MT300N)) -- 1.9.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From alzhao at gmail.com Wed May 4 23:02:10 2016 From: alzhao at gmail.com (alzhao) Date: Thu, 5 May 2016 11:02:10 +0800 Subject: [OpenWrt-Devel] [PATCH 6/6] [CC] [backport] ramips: add GL-MT750 support In-Reply-To: <1462417330-12566-1-git-send-email-alzhao@gmail.com> References: <1462417330-12566-1-git-send-email-alzhao@gmail.com> Message-ID: <1462417330-12566-6-git-send-email-alzhao@gmail.com> Backport changeset 48994 Add GT-MT750 support to CC Signed-off-by: alzhao --- target/linux/ramips/base-files/etc/board.d/01_leds | 3 + .../linux/ramips/base-files/etc/board.d/02_network | 7 + target/linux/ramips/base-files/lib/ramips.sh | 3 + .../ramips/base-files/lib/upgrade/platform.sh | 1 + target/linux/ramips/dts/GL-MT750.dts | 159 +++++++++++++++++++++ target/linux/ramips/image/Makefile | 2 + target/linux/ramips/mt7620/profiles/gli.mk | 14 +- 7 files changed, 187 insertions(+), 2 deletions(-) create mode 100644 target/linux/ramips/dts/GL-MT750.dts diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds b/target/linux/ramips/base-files/etc/board.d/01_leds index 3886e49..643b3cc 100755 --- a/target/linux/ramips/base-files/etc/board.d/01_leds +++ b/target/linux/ramips/base-files/etc/board.d/01_leds @@ -153,6 +153,9 @@ case $board in gl-mt300n) set_wifi_led "gl-mt300n:wlan" ;; + gl-mt750) + set_wifi_led "gl-mt750:wlan" + ;; mpr-a1) set_wifi_led "hame:blue:system" ;; diff --git a/target/linux/ramips/base-files/etc/board.d/02_network b/target/linux/ramips/base-files/etc/board.d/02_network index 1e91039..227aa63 100755 --- a/target/linux/ramips/base-files/etc/board.d/02_network +++ b/target/linux/ramips/base-files/etc/board.d/02_network @@ -167,6 +167,13 @@ ramips_setup_interfaces() ucidef_add_switch_vlan "switch0" "2" "0 6t" ucidef_add_switch_vlan "switch0" "1" "1 2 3 4 6t" ;; + + gl-mt750) + ucidef_set_interfaces_lan_wan "eth0.1" "eth0.2" + ucidef_add_switch "switch0" "1" "1" + ucidef_add_switch_vlan "switch0" "2" "0 6t" + ucidef_add_switch_vlan "switch0" "1" "1 2 3 4 6t" + ;; whr-1166d) ucidef_set_interfaces_lan_wan "eth0.1" "eth0.2" diff --git a/target/linux/ramips/base-files/lib/ramips.sh b/target/linux/ramips/base-files/lib/ramips.sh index 3ebb1b0..fb5be8c 100755 --- a/target/linux/ramips/base-files/lib/ramips.sh +++ b/target/linux/ramips/base-files/lib/ramips.sh @@ -175,6 +175,9 @@ ramips_board_detect() { *"GL-MT300N") name="gl-mt300n" ;; + *"GL-MT750") + name="gl-mt750" + ;; *"Hauppauge Broadway") name="broadway" ;; diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh b/target/linux/ramips/base-files/lib/upgrade/platform.sh index 7825af8..7a84aab 100755 --- a/target/linux/ramips/base-files/lib/upgrade/platform.sh +++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh @@ -57,6 +57,7 @@ platform_check_image() { firewrt |\ gl-mt300a |\ gl-mt300n |\ + gl-mt750 |\ pbr-m1 |\ hg255d | \ hlk-rm04 | \ diff --git a/target/linux/ramips/dts/GL-MT750.dts b/target/linux/ramips/dts/GL-MT750.dts new file mode 100644 index 0000000..a36ae5e --- /dev/null +++ b/target/linux/ramips/dts/GL-MT750.dts @@ -0,0 +1,159 @@ +/dts-v1/; + +/include/ "mt7620a.dtsi" + +/ { + compatible = "GL-MT750", "ralink,mt7620a-soc"; + model = "GL-MT750"; + + chosen { + bootargs = "console=ttyS0,115200"; + }; + + palmbus at 10000000 { + gpio0: gpio at 600 { + status = "okay"; + }; + + gpio1: gpio at 638 { + status = "okay"; + }; + + gpio2: gpio at 660 { + status = "okay"; + }; + + gpio3: gpio at 688 { + status = "okay"; + }; + + spi at b00 { + status = "okay"; + + m25p80 at 0 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "w25q128"; + reg = <0 0>; + linux,modalias = "m25p80", "w25q128"; + spi-max-frequency = <10000000>; + + partition at 0 { + label = "u-boot"; + reg = <0x0 0x30000>; + }; + + partition at 30000 { + label = "u-boot-env"; + reg = <0x30000 0x10000>; + read-only; + }; + + factory: partition at 40000 { + label = "factory"; + reg = <0x40000 0x10000>; + read-only; + }; + + partition at 50000 { + label = "firmware"; + reg = <0x50000 0xf80000>; + }; + + partition at ff0000 { + label = "art"; + reg = <0xff0000 0x10000>; + }; + }; + }; + }; + + sdhci at 10130000 { + status = "okay"; + }; + + ehci at 101c0000 { + status = "okay"; + }; + + ohci at 101c1000 { + status = "okay"; + }; + + ethernet at 10100000 { + pinctrl-names = "default"; + pinctrl-0 = <&ephy_pins>; + mtd-mac-address = <&factory 0x4000>; + ralink,port-map = "llllw"; + }; + + wmac at 10180000 { + ralink,mtd-eeprom = <&factory 0>; + }; + + pcie at 10140000 { + status = "okay"; + + pcie-bridge { + mt76 at 0,0 { + reg = <0x0000 0 0 0 0>; + device_type = "pci"; + mediatek,mtd-eeprom = <&factory 0x8000>; + mediatek,2ghz = <0>; + }; + }; + }; + + pinctrl { + state_default: pinctrl0 { + gpio { + ralink,group = "wled","ephy","uartf"; + ralink,function = "gpio"; + }; + }; + }; + + gpio-leds { + compatible = "gpio-leds"; + + wan { + label = "gl-mt750:wan"; + gpios = <&gpio2 0 1>; + }; + + lan { + label = "gl-mt750:lan"; + gpios = <&gpio2 1 1>; + }; + + wlan { + label = "gl-mt750:wlan"; + gpios = <&gpio3 0 1>; + }; + + }; + + gpio-keys-polled { + compatible = "gpio-keys-polled"; + #address-cells = <1>; + #size-cells = <0>; + poll-interval = <20>; + reset { + label = "reset"; + gpios = <&gpio0 13 1>; + linux,code = <0x198>; + }; + + BTN_0 { + label = "BTN_0"; + gpios = <&gpio2 2 1>; + linux,code = <0x100>; + }; + + BTN_1 { + label = "BTN_1"; + gpios = <&gpio2 3 1>; + linux,code = <0x101>; + }; + }; +}; diff --git a/target/linux/ramips/image/Makefile b/target/linux/ramips/image/Makefile index 9f83b1c..b55b2b0 100644 --- a/target/linux/ramips/image/Makefile +++ b/target/linux/ramips/image/Makefile @@ -912,6 +912,7 @@ Image/Build/Profile/WT3020=$(call BuildFirmware/PorayDualSize/$(1),$(1),wt3020,W Image/Build/Profile/XIAOMI-MIWIFI-MINI=$(call BuildFirmware/Default16M/$(1),$(1),xiaomi-miwifi-mini,XIAOMI-MIWIFI-MINI) Image/Build/Profile/GL-MT300A=$(call BuildFirmware/Default16M/$(1),$(1),gl-mt300a,GL-MT300A) Image/Build/Profile/GL-MT300N=$(call BuildFirmware/Default16M/$(1),$(1),gl-mt300n,GL-MT300N) +Image/Build/Profile/GL-MT750=$(call BuildFirmware/Default16M/$(1),$(1),gl-mt750,GL-MT750) Image/Build/Profile/ZTE-Q7=$(call BuildFirmware/Default8M/$(1),$(1),zte-q7,ZTE-Q7) Image/Build/Profile/ZBT-WA05=$(call BuildFirmware/Default8M/$(1),$(1),zbt-wa05,ZBT-WA05) Image/Build/Profile/ArcherC20i=$(call BuildFirmware/Tplink/$(1),$(1),ArcherC20i,ArcherC20i) @@ -948,6 +949,7 @@ define Image/Build/Profile/Default $(call Image/Build/Profile/XIAOMI-MIWIFI-MINI,$(1)) $(call Image/Build/Profile/GL-MT300A,$(1)) $(call Image/Build/Profile/GL-MT300N,$(1)) + $(call Image/Build/Profile/GL-MT750,$(1)) $(call Image/Build/Profile/ZTE-Q7,$(1)) $(call Image/Build/Profile/ZBT-WA05,$(1)) $(call Image/Build/Profile/ArcherC20i,$(1)) diff --git a/target/linux/ramips/mt7620/profiles/gli.mk b/target/linux/ramips/mt7620/profiles/gli.mk index ce407e2..0154bbc 100644 --- a/target/linux/ramips/mt7620/profiles/gli.mk +++ b/target/linux/ramips/mt7620/profiles/gli.mk @@ -16,11 +16,21 @@ endef $(eval $(call Profile,GL-MT300A)) define Profile/GL-MT300N - NAME:=GL-MT300N - PACKAGES:=kmod-usb-core kmod-usb-dwc2 kmod-usb2 kmod-usb-ohci kmod-mt76 + NAME:=GL-MT300N + PACKAGES:=kmod-usb-core kmod-usb-dwc2 kmod-usb2 kmod-usb-ohci kmod-mt76 endef define Profile/GL-MT300N/Description Support for gl-mt300n Router endef $(eval $(call Profile,GL-MT300N)) + +define Profile/GL-MT750 + NAME:=GL-MT750 + PACKAGES:=kmod-usb-core kmod-usb-dwc2 kmod-usb2 kmod-usb-ohci kmod-mt76 kmod-mt7610e +endef + +define Profile/GL-MT750/Description + Support for gl-mt750 Router +endef +$(eval $(call Profile,GL-MT750)) -- 1.9.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Wed May 4 23:48:16 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Wed, 4 May 2016 23:48:16 -0400 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <572A5501.3040807@openwrt.org> References: <572A5501.3040807@openwrt.org> Message-ID: <572AC280.1000608@daniel.thecshore.com> On 16-05-04 04:01 PM, mbm wrote: > Dear OpenWrt community, > > spin off the OpenWrt project in the first place as a way to fix the > project and its community. Also, the phrases such as a "reboot" are both > vague and misleading and the LEDE project failed to identify its true > nature. The LEDE announcement contains a number of very valid points Can you be more specific about what you believe is LEDE's 'true nature'? > which we hoped we had an opportunity to discuss and attempt to fix, in a > public manner, before this more radical outcome. At this point, the > email as well as actions taken are very confusing to a lot of us. This is a guess: perhaps it is connected to the fact that Felix's nbd at openwrt.org address now bounces, and that actions were taken which were deemed to be over-the-top by the LEDE team? Certainly there is a great deal more doing on that either side is saying in public (which might be just as well since there seems to be a fair amount of bad feelings on both sides). > We do acknowledge there has been internal disagreements, on several > occasions about some directions of the project, about the release model, > the lack of testing, the centralized infrastructure, however, there have > been actual work going on under the hoods to solve things one step at a Perhaps 'under-the-hood' is the problem. Did everyone with concerns know or have insight into what steps were currently being taken and what was planned, and have planned actions been followed through on, once *agreed* as a solution? Also, is the decision making process egalitarian and democratic amongst those still actively in the project, or are some 'more equal' than others? Regards, Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at vittgam.net Thu May 5 00:49:10 2016 From: openwrt at vittgam.net (Vittorio G (VittGam)) Date: Thu, 05 May 2016 06:49:10 +0200 Subject: [OpenWrt-Devel] Getting in touch with Felix In-Reply-To: <572A8D1D.4060807@daniel.thecshore.com> References: <572A8D1D.4060807@daniel.thecshore.com> Message-ID: <321e223cf48693d12fe33f69f017b2a4@vittgam.net> Hi, Even jow at openwrt and blogic at openwrt do not exist anymore as of now. > Recipient address rejected: User unknown in virtual mailbox table While for example juhosg at openwrt still exists. I just hope this will not become another "ffmpeg vs libav"... Cheers, Vittorio On 05/05/2016 02:00:29 CEST, Daniel Dickinson wrote: > Hi, > > How does one get in touch with Felix these days? nbd at openwrt.org > bounces for me. > > Regards, > > Daniel > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From michal.hrusecky at nic.cz Thu May 5 04:58:57 2016 From: michal.hrusecky at nic.cz (Michal Hrusecky) Date: Thu, 5 May 2016 10:58:57 +0200 Subject: [OpenWrt-Devel] [PATCH] [generic] Checksum for all files inside package Message-ID: <20160505085857.GA7918@workbook.ipv6.hrusecky.net> This patch introduces possibility to have checksums of all files installed from packages calculated on build and be part of the package metadata. It could be useful to verify everything installed properly and that there are no errors on the storage. Signed-off-by: Michal Hrusecky --- config/Config-build.in | 9 +++ include/package-ipkg.mk | 5 ++ package/base-files/Makefile | 3 + package/base-files/files/sbin/pkg_check | 130 ++++++++++++++++++++++++++++++++ 4 files changed, 147 insertions(+) create mode 100755 package/base-files/files/sbin/pkg_check diff --git a/config/Config-build.in b/config/Config-build.in index 5ad940b..dd94fc5 100644 --- a/config/Config-build.in +++ b/config/Config-build.in @@ -55,6 +55,15 @@ menu "Global build settings" This removes all ipkg/opkg status data files from the target directory before building the root filesystem. + config FILES_MD5_SUM + bool + prompt "Provide checksums for all installed files" + default n + help + Enables computation of md5 checksums for all files that are part of + package. Can be used to verify that filesystem is intact and all + files were correctly installed. + config COLLECT_KERNEL_DEBUG bool prompt "Collect kernel debug information" diff --git a/include/package-ipkg.mk b/include/package-ipkg.mk index eb4c874..b3a0d6f 100644 --- a/include/package-ipkg.mk +++ b/include/package-ipkg.mk @@ -187,6 +187,11 @@ $(_endef) $(CheckDependencies) $(RSTRIP) $$(IDIR_$(1)) + if [ "$$(CONFIG_FILES_MD5_SUM)" = "y" ]; then \ + (cd $$(IDIR_$(1)); \ + find . -type f \! -path ./CONTROL/\* -exec md5sum \{\} \; | \ + sed 's|\([[:blank:]]\)\./|\1/|' > $$(IDIR_$(1))/CONTROL/files-md5sum ) \ + fi (cd $$(IDIR_$(1))/CONTROL; \ ( \ echo "$$$$CONTROL"; \ diff --git a/package/base-files/Makefile b/package/base-files/Makefile index 8bb6225..7e0e96f 100644 --- a/package/base-files/Makefile +++ b/package/base-files/Makefile @@ -180,6 +180,9 @@ define Package/base-files/install echo "$$$${conffile##$(1)}" >> $(1)/CONTROL/conffiles; \ fi \ done + ifneq ($(CONFIG_FILES_MD5_SUM),y) + rm $(1)/sbin/pkg_check + endif endef ifneq ($(DUMP),1) diff --git a/package/base-files/files/sbin/pkg_check b/package/base-files/files/sbin/pkg_check new file mode 100755 index 0000000..5dadb3f --- /dev/null +++ b/package/base-files/files/sbin/pkg_check @@ -0,0 +1,130 @@ +#!/bin/sh +# +# Package checksums checking script +# (C) 2016 CZ.NIC, z.s.p.o. +# +# 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 3 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, see . + + +ERRFATAL="no" +QUIET="yes" +MISSING="" +SUMMARY="" +NL=" +" + +# Arguments parsing +while expr "x$1" : "x-" > /dev/null; do + if [ "x$1" = "x-s" ]; then + ERRFATAL="yes" + shift + elif [ "x$1" = "x-v" ]; then + QUIET=" no" + shift + else + echo "Usage: $(basename $0) [-s] [-v] [pkg1 pkg2 ...]" + echo + echo " -s Stop on first change" + echo " -v Verbose" + if [ "x$1" = "x-h" ]; then + exit 0 + else + echo + echo "ERROR: Unknown option '$1'" + exit 1 + fi + fi +done + +# Check all packages by default +if [ -z "$1" ]; then + set $(cd /usr/lib/opkg/info/; for i in *.files-md5sum; do basename $i .files-md5sum; done) +fi + +# Iterate over packages +while [ "$1" ]; do + if [ \! -f "/usr/lib/opkg/info/$1.files-md5sum" ]; then + if [ "$ERRFATAL" = no ]; then + echo " * No checksums for $1 - skipping" + echo + else + echo " * No checksums for $1 - exiting" + exit 1 + fi + if [ -z "$MISSING" ]; then + MISSING="$1" + else + MISSING="$MISSING, $1" + fi + shift + continue + fi + [ $QUIET = yes ] || echo " * Checking package $1:" + ERR="" + CHECK="`md5sum -c /usr/lib/opkg/info/$1.files-md5sum 2> /dev/null`" + + # Are the changed files config files? + if [ $? -ne 0 ] && [ "`cat "/usr/lib/opkg/info/$1.files-md5sum"`" ]; then + NEWCHECK="`echo "$CHECK" | grep '^.*: OK$'`" + for i in `echo "$CHECK" | sed -n 's|^\(.*\): FAILED$|\1|p'`; do + if [ "`grep "^$i\$" "/usr/lib/opkg/info/$1.conffiles" 2> /dev/null`" ] || \ + [ "`echo "$i" | grep "^/etc/uci-defaults/"`" ]; then + NEWCHECK="${NEWCHECK}${NL}${i}: CONFIGURED" + else + NEWCHECK="${NEWCHECK}${NL}${i}: FAILED" + ERR="y" + fi + done + CHECK="$NEWCHECK" + fi + + # Do we have changed files or not? + if [ -z "$ERR" ]; then + [ $QUIET = yes ] || [ -z "`cat "/usr/lib/opkg/info/$1.files-md5sum"`" ] || echo "$CHECK" | sed 's|^| - |' + [ $QUIET = yes ] || echo " * Package $1 is ok" + [ $QUIET = yes ] || echo + else + if [ $QUIET = yes ]; then + echo " * Changes found in package $1:" + echo "$CHECK" | sed -n 's|^\(.*:[[:blank:]]*FAILED\)$| - \1|p' + else + echo "$CHECK" | sed 's|^| - |' + echo " * Changes found in package $1!" + fi + if [ "$ERRFATAL" = yes ]; then + echo + echo "Exiting on first change found!" + exit 1 + fi + for i in `echo "$CHECK" | sed -n 's|^\(.*\): FAILED$|\1|p'`; do + SUMMARY="${SUMMARY}${NL} - $1: $i" + done + echo + fi + shift +done + +# If there are changed files, report them +if [ "$SUMMARY" ]; then + echo "Some packages contain changed files!" + echo "Maybe something worth looking into?" + echo "Here is the list of packages and changed files:" + echo "$SUMMARY" +fi +if [ "$MISSING" ]; then + echo "Following packages are missing checksums: $MISSING" +fi +if [ "$MISSING" ] || [ "$SUMMARY" ]; then + exit 1 +fi -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From leroi.lists at gmail.com Thu May 5 05:34:50 2016 From: leroi.lists at gmail.com (Roman Yeryomin) Date: Thu, 5 May 2016 12:34:50 +0300 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <572AC280.1000608@daniel.thecshore.com> References: <572A5501.3040807@openwrt.org> <572AC280.1000608@daniel.thecshore.com> Message-ID: On 5 May 2016 at 06:48, Daniel Dickinson wrote: > On 16-05-04 04:01 PM, mbm wrote: >> Dear OpenWrt community, >> >> spin off the OpenWrt project in the first place as a way to fix the >> project and its community. Also, the phrases such as a "reboot" are both >> vague and misleading and the LEDE project failed to identify its true >> nature. The LEDE announcement contains a number of very valid points > > Can you be more specific about what you believe is LEDE's 'true nature'? > >> which we hoped we had an opportunity to discuss and attempt to fix, in a >> public manner, before this more radical outcome. At this point, the >> email as well as actions taken are very confusing to a lot of us. > > This is a guess: perhaps it is connected to the fact that Felix's > nbd at openwrt.org address now bounces, and that actions were taken which > were deemed to be over-the-top by the LEDE team? Certainly there is a > great deal more doing on that either side is saying in public (which > might be just as well since there seems to be a fair amount of bad > feelings on both sides). One simple question: If LEDE team members are the ones who were suffering from some non-democratic decisions, why didn't they bring it to public discussion for community? At least on devel maillist? If it was clear problem in remaining OpenWrt team then LEDE would win the community right away or maybe problematic people would just go away. Either way it would be more fair and open. And this is one of my biggest concerns - LEDE team is promoting openness but didn't do their moves openly (looking at maillists it seems they were hiding it for month at least). Hate double standards. >> We do acknowledge there has been internal disagreements, on several >> occasions about some directions of the project, about the release model, >> the lack of testing, the centralized infrastructure, however, there have >> been actual work going on under the hoods to solve things one step at a > > Perhaps 'under-the-hood' is the problem. Did everyone with concerns > know or have insight into what steps were currently being taken and what > was planned, and have planned actions been followed through on, once > *agreed* as a solution? > > Also, is the decision making process egalitarian and democratic amongst > those still actively in the project, or are some 'more equal' than others? > > Regards, > > Daniel > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From inindev at gmail.com Thu May 5 06:16:22 2016 From: inindev at gmail.com (John Clark) Date: Thu, 5 May 2016 06:16:22 -0400 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: References: <572A5501.3040807@openwrt.org> <572AC280.1000608@daniel.thecshore.com> Message-ID: >Could you elaborate more and explain how exactly LEDE is going to fix the listed problems? And why it's not possible to fix them inside existing project? The hasty reasons given and the secret and abrupt severing of ties make me wonder if a "follow the money" approach will yield more plausible answers to the questions being raised. On Thu, May 5, 2016 at 5:34 AM, Roman Yeryomin wrote: > On 5 May 2016 at 06:48, Daniel Dickinson > wrote: > > On 16-05-04 04:01 PM, mbm wrote: > >> Dear OpenWrt community, > >> > >> spin off the OpenWrt project in the first place as a way to fix the > >> project and its community. Also, the phrases such as a "reboot" are both > >> vague and misleading and the LEDE project failed to identify its true > >> nature. The LEDE announcement contains a number of very valid points > > > > Can you be more specific about what you believe is LEDE's 'true nature'? > > > >> which we hoped we had an opportunity to discuss and attempt to fix, in a > >> public manner, before this more radical outcome. At this point, the > >> email as well as actions taken are very confusing to a lot of us. > > > > This is a guess: perhaps it is connected to the fact that Felix's > > nbd at openwrt.org address now bounces, and that actions were taken which > > were deemed to be over-the-top by the LEDE team? Certainly there is a > > great deal more doing on that either side is saying in public (which > > might be just as well since there seems to be a fair amount of bad > > feelings on both sides). > > One simple question: > If LEDE team members are the ones who were suffering from some > non-democratic decisions, why didn't they bring it to public > discussion for community? At least on devel maillist? > > If it was clear problem in remaining OpenWrt team then LEDE would win > the community right away or maybe problematic people would just go > away. Either way it would be more fair and open. And this is one of my > biggest concerns - LEDE team is promoting openness but didn't do their > moves openly (looking at maillists it seems they were hiding it for > month at least). Hate double standards. > > > >> We do acknowledge there has been internal disagreements, on several > >> occasions about some directions of the project, about the release model, > >> the lack of testing, the centralized infrastructure, however, there have > >> been actual work going on under the hoods to solve things one step at a > > > > Perhaps 'under-the-hood' is the problem. Did everyone with concerns > > know or have insight into what steps were currently being taken and what > > was planned, and have planned actions been followed through on, once > > *agreed* as a solution? > > > > Also, is the decision making process egalitarian and democratic amongst > > those still actively in the project, or are some 'more equal' than > others? > > > > Regards, > > > > Daniel > > _______________________________________________ > > openwrt-devel mailing list > > openwrt-devel at lists.openwrt.org > > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From leroi.lists at gmail.com Thu May 5 06:25:20 2016 From: leroi.lists at gmail.com (Roman Yeryomin) Date: Thu, 5 May 2016 13:25:20 +0300 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: References: <572A5501.3040807@openwrt.org> <572AC280.1000608@daniel.thecshore.com> Message-ID: On 5 May 2016 at 13:16, John Clark wrote: >>Could you elaborate more and explain how exactly LEDE is going to fix > the listed problems? And why it's not possible to fix them inside > existing project? > > The hasty reasons given and the secret and abrupt severing of ties make me > wonder if a "follow the money" approach will yield more plausible answers to > the questions being raised. maybe a good point, how do you "follow the money"? > On Thu, May 5, 2016 at 5:34 AM, Roman Yeryomin > wrote: >> >> On 5 May 2016 at 06:48, Daniel Dickinson >> wrote: >> > On 16-05-04 04:01 PM, mbm wrote: >> >> Dear OpenWrt community, >> >> >> >> spin off the OpenWrt project in the first place as a way to fix the >> >> project and its community. Also, the phrases such as a "reboot" are >> >> both >> >> vague and misleading and the LEDE project failed to identify its true >> >> nature. The LEDE announcement contains a number of very valid points >> > >> > Can you be more specific about what you believe is LEDE's 'true nature'? >> > >> >> which we hoped we had an opportunity to discuss and attempt to fix, in >> >> a >> >> public manner, before this more radical outcome. At this point, the >> >> email as well as actions taken are very confusing to a lot of us. >> > >> > This is a guess: perhaps it is connected to the fact that Felix's >> > nbd at openwrt.org address now bounces, and that actions were taken which >> > were deemed to be over-the-top by the LEDE team? Certainly there is a >> > great deal more doing on that either side is saying in public (which >> > might be just as well since there seems to be a fair amount of bad >> > feelings on both sides). >> >> One simple question: >> If LEDE team members are the ones who were suffering from some >> non-democratic decisions, why didn't they bring it to public >> discussion for community? At least on devel maillist? >> >> If it was clear problem in remaining OpenWrt team then LEDE would win >> the community right away or maybe problematic people would just go >> away. Either way it would be more fair and open. And this is one of my >> biggest concerns - LEDE team is promoting openness but didn't do their >> moves openly (looking at maillists it seems they were hiding it for >> month at least). Hate double standards. >> >> >> >> We do acknowledge there has been internal disagreements, on several >> >> occasions about some directions of the project, about the release >> >> model, >> >> the lack of testing, the centralized infrastructure, however, there >> >> have >> >> been actual work going on under the hoods to solve things one step at a >> > >> > Perhaps 'under-the-hood' is the problem. Did everyone with concerns >> > know or have insight into what steps were currently being taken and what >> > was planned, and have planned actions been followed through on, once >> > *agreed* as a solution? >> > >> > Also, is the decision making process egalitarian and democratic amongst >> > those still actively in the project, or are some 'more equal' than >> > others? >> > >> > Regards, >> > >> > Daniel >> > _______________________________________________ >> > openwrt-devel mailing list >> > openwrt-devel at lists.openwrt.org >> > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >> _______________________________________________ >> openwrt-devel mailing list >> openwrt-devel at lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > > > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sgalabov at gmail.com Thu May 5 06:32:47 2016 From: sgalabov at gmail.com (Stanislav Galabov) Date: Thu, 5 May 2016 13:32:47 +0300 Subject: [OpenWrt-Devel] [PATCH] ramips: Introduce serial0 aliases for active console in dts Message-ID: <6EC7AF3A-69BB-403C-A03D-C91705D6AF7B@gmail.com> This patch introduces serial0 aliases in the ramips DTS files, which can then be used to denote the active console instead of relying on bootargs. Signed-off-by: Stanislav Galabov ? diff --git a/target/linux/ramips/dts/LINKIT7688.dts b/target/linux/ramips/dts/LINKIT7688.dts index 2dfb98c..bb38c88 100644 --- a/target/linux/ramips/dts/LINKIT7688.dts +++ b/target/linux/ramips/dts/LINKIT7688.dts @@ -10,6 +10,10 @@ bootargs = "console=ttyS2,57600"; }; + aliases { + serial0 = &uart2; + }; + memory at 0 { device_type = "memory"; reg = <0x0 0x8000000>; diff --git a/target/linux/ramips/dts/mt7620a.dtsi b/target/linux/ramips/dts/mt7620a.dtsi index 5edbdf9..3c89880 100644 --- a/target/linux/ramips/dts/mt7620a.dtsi +++ b/target/linux/ramips/dts/mt7620a.dtsi @@ -23,6 +23,7 @@ aliases { spi0 = &spi0; spi1 = &spi1; + serial0 = &uartlite; }; palmbus at 10000000 { @@ -239,7 +240,7 @@ pinctrl-0 = <&spi_cs1>; }; - uartlite at c00 { + uartlite: uartlite at c00 { compatible = "ralink,mt7620a-uart", "ralink,rt2880-uart", "ns16550a"; reg = <0xc00 0x100>; diff --git a/target/linux/ramips/dts/mt7620n.dtsi b/target/linux/ramips/dts/mt7620n.dtsi index e8ce3b2..7e66abe 100644 --- a/target/linux/ramips/dts/mt7620n.dtsi +++ b/target/linux/ramips/dts/mt7620n.dtsi @@ -23,6 +23,7 @@ aliases { spi0 = &spi0; spi1 = &spi1; + serial0 = &uartlite; }; palmbus at 10000000 { @@ -191,7 +192,7 @@ pinctrl-0 = <&spi_cs1>; }; - uartlite at c00 { + uartlite: uartlite at c00 { compatible = "ralink,mt7620a-uart", "ralink,rt2880-uart", "ns16550a"; reg = <0xc00 0x100>; diff --git a/target/linux/ramips/dts/mt7621.dtsi b/target/linux/ramips/dts/mt7621.dtsi index 24e0459..94cff26 100644 --- a/target/linux/ramips/dts/mt7621.dtsi +++ b/target/linux/ramips/dts/mt7621.dtsi @@ -5,6 +5,10 @@ #size-cells = <1>; compatible = "mediatek,mtk7621-soc"; + aliases { + serial0 = &uartlite; + }; + cpus { cpu at 0 { compatible = "mips,mips1004Kc"; @@ -100,7 +104,7 @@ reg = <0x1fbf8000 0x8000>; }; - uartlite at c00 { + uartlite: uartlite at c00 { compatible = "ns16550a"; reg = <0xc00 0x100>; diff --git a/target/linux/ramips/dts/mt7628an.dtsi b/target/linux/ramips/dts/mt7628an.dtsi index e120e56..c1f03fc 100644 --- a/target/linux/ramips/dts/mt7628an.dtsi +++ b/target/linux/ramips/dts/mt7628an.dtsi @@ -13,6 +13,10 @@ bootargs = "console=ttyS0,57600"; }; + aliases { + serial0 = &uartlite; + }; + cpuintc: cpuintc at 0 { #address-cells = <0>; #interrupt-cells = <1>; @@ -154,7 +158,7 @@ status = "disabled"; }; - uartlite at c00 { + uartlite: uartlite at c00 { compatible = "ns16550a"; reg = <0xc00 0x100>; @@ -192,7 +196,7 @@ status = "disabled"; }; - uart2 at e00 { + uart2: uart2 at e00 { compatible = "ns16550a"; reg = <0xe00 0x100>; diff --git a/target/linux/ramips/dts/rt2880.dtsi b/target/linux/ramips/dts/rt2880.dtsi index 47ea4c3..dc3f0ba 100644 --- a/target/linux/ramips/dts/rt2880.dtsi +++ b/target/linux/ramips/dts/rt2880.dtsi @@ -13,6 +13,10 @@ bootargs = "console=ttyS0,57600"; }; + aliases { + serial0 = &uartlite; + }; + cpuintc: cpuintc at 0 { #address-cells = <0>; #interrupt-cells = <1>; @@ -110,7 +114,7 @@ status = "disabled"; }; - uartlite at c00 { + uartlite: uartlite at c00 { compatible = "ralink,rt2880-uart", "ns16550a"; reg = <0xc00 0x100>; diff --git a/target/linux/ramips/dts/rt3050.dtsi b/target/linux/ramips/dts/rt3050.dtsi index 8fcdeed..0a4cf1e 100644 --- a/target/linux/ramips/dts/rt3050.dtsi +++ b/target/linux/ramips/dts/rt3050.dtsi @@ -15,6 +15,7 @@ aliases { spi0 = &spi0; + serial0 = &uartlite; }; cpuintc: cpuintc at 0 { @@ -164,7 +165,7 @@ status = "disabled"; }; - uartlite at c00 { + uartlite: uartlite at c00 { compatible = "ralink,rt3050-uart", "ralink,rt2880-uart", "ns16550a"; reg = <0xc00 0x100>; diff --git a/target/linux/ramips/dts/rt3352.dtsi b/target/linux/ramips/dts/rt3352.dtsi index 0932b52..f9721d8 100644 --- a/target/linux/ramips/dts/rt3352.dtsi +++ b/target/linux/ramips/dts/rt3352.dtsi @@ -23,6 +23,7 @@ aliases { spi0 = &spi0; spi1 = &spi1; + serial0 = &uartlite; }; palmbus at 10000000 { @@ -175,7 +176,7 @@ status = "disabled"; }; - uartlite at c00 { + uartlite: uartlite at c00 { compatible = "ralink,rt3352-uart", "ralink,rt2880-uart", "ns16550a"; reg = <0xc00 0x100>; diff --git a/target/linux/ramips/dts/rt3883.dtsi b/target/linux/ramips/dts/rt3883.dtsi index cd96b74..fa070a1 100644 --- a/target/linux/ramips/dts/rt3883.dtsi +++ b/target/linux/ramips/dts/rt3883.dtsi @@ -16,6 +16,7 @@ aliases { spi0 = &spi0; spi1 = &spi1; + serial0 = &uartlite; }; cpuintc: cpuintc at 0 { @@ -195,7 +196,7 @@ status = "disabled"; }; - uartlite at c00 { + uartlite: uartlite at c00 { compatible = "ralink,rt3883-uart", "ralink,rt2880-uart", "ns16550a"; reg = <0xc00 0x100>; diff --git a/target/linux/ramips/dts/rt5350.dtsi b/target/linux/ramips/dts/rt5350.dtsi index b8712e9..226d4a4 100644 --- a/target/linux/ramips/dts/rt5350.dtsi +++ b/target/linux/ramips/dts/rt5350.dtsi @@ -23,6 +23,7 @@ aliases { spi0 = &spi0; spi1 = &spi1; + serial0 = &uartlite; }; palmbus at 10000000 { @@ -184,7 +185,7 @@ status = "disabled"; }; - uartlite at c00 { + uartlite: uartlite at c00 { compatible = "ralink,rt5350-uart", "ralink,rt2880-uart", "ns16550a"; reg = <0xc00 0x100>; _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From adron at yapic.net Thu May 5 07:15:51 2016 From: adron at yapic.net (adron at yapic.net) Date: Thu, 5 May 2016 14:15:51 +0300 Subject: [OpenWrt-Devel] [PATCH] ar71xx: add Mikrotik's yaffs2 file system support. Message-ID: <1462446951-29739-1-git-send-email-adron@yapic.net> From: Sergey Sergeev This patch adds support of Mikrotik yaffs2 filesystem image for kernel file and tools/kernel2minor package. We neede this to boot kernel through RouterBoot on new Mikrotik NOR flash devices. Signed-off-by: Sergey Sergeev --- config/Config-images.in | 31 ++++++++++++++++++++++++++++++ scripts/metadata.pl | 1 + target/Config.in | 3 +++ target/linux/ar71xx/image/Makefile | 14 ++++++++++++++ target/linux/ar71xx/mikrotik/target.mk | 4 ++-- tools/Makefile | 1 + tools/kernel2minor/Makefile | 35 ++++++++++++++++++++++++++++++++++ 7 files changed, 87 insertions(+), 2 deletions(-) create mode 100644 tools/kernel2minor/Makefile diff --git a/config/Config-images.in b/config/Config-images.in index a60dd50..c7d1898 100644 --- a/config/Config-images.in +++ b/config/Config-images.in @@ -6,6 +6,37 @@ menu "Target Images" + menuconfig TARGET_KERNELFS_MIKROTIK_YAFFS2 + bool "kernel2mikrotikyaffs2" + default y if USES_KERNEL2MIKROTIKYAFFS2 + depends on USES_KERNEL2MIKROTIKYAFFS2 + help + Build a Mikrotik's version of Yaffs2 filesystem which contains only a single kernel file. + This is necessary for boot through RouterBoot boot loader. + + config TARGET_MIKROTIK_YAFFS2_NOR_FLASH_IMG + bool "NOR flash image" + depends on TARGET_KERNELFS_MIKROTIK_YAFFS2 + default "y" + help + Build Mikrotik's Yaffs2 filesystem image for NOR flash boards: + Mikrotik rb941-2nd(hAP lite) + And maby(not tested yet) all new routerboards with this strings in description: + Storage type FLASH + Storage size 16 MB + + config TARGET_MIKROTIK_YAFFS2_NAND_2048B_ECC_FLASH_IMG + bool "NAND flash (2048b with ECC) image" + depends on TARGET_KERNELFS_MIKROTIK_YAFFS2 + default "y" + help + Build Mikrotik's Yaffs2 filesystem image for NAND flash boards: + Mikrotik rb750 and rb751 + And maby(not tested yet) all routerboards with NAND flash parameters like this: + Eraseblock size: 131072 bytes, 128.0 KiB + Minimum input/output unit size: 2048 bytes + OOB size: 64 bytes + menuconfig TARGET_ROOTFS_INITRAMFS bool "ramdisk" default y if USES_INITRAMFS diff --git a/scripts/metadata.pl b/scripts/metadata.pl index 99fdba1..17c3176 100755 --- a/scripts/metadata.pl +++ b/scripts/metadata.pl @@ -134,6 +134,7 @@ sub target_config_features(@) { /ext4/ and $ret .= "\tselect USES_EXT4\n"; /targz/ and $ret .= "\tselect USES_TARGZ\n"; /cpiogz/ and $ret .= "\tselect USES_CPIOGZ\n"; + /kernel2mikrotikyaffs2/ and $ret .= "\tselect USES_KERNEL2MIKROTIKYAFFS2\n"; /ubifs/ and $ret .= "\tselect USES_UBIFS\n"; /fpu/ and $ret .= "\tselect HAS_FPU\n"; /spe_fpu/ and $ret .= "\tselect HAS_SPE_FPU\n"; diff --git a/target/Config.in b/target/Config.in index 571b06e..b9e10bd 100644 --- a/target/Config.in +++ b/target/Config.in @@ -63,6 +63,9 @@ config USES_TARGZ config USES_CPIOGZ bool +config USES_KERNEL2MIKROTIKYAFFS2 + bool + config USES_UBIFS bool select NAND_SUPPORT diff --git a/target/linux/ar71xx/image/Makefile b/target/linux/ar71xx/image/Makefile index bc8a4a8..9419c5f 100644 --- a/target/linux/ar71xx/image/Makefile +++ b/target/linux/ar71xx/image/Makefile @@ -1492,6 +1492,17 @@ define MkuImageOKLI endef endif +define kernel2mikrotikyaffs2 +#NOR flash +ifneq ($(CONFIG_TARGET_MIKROTIK_YAFFS2_NOR_FLASH_IMG),) + $(STAGING_DIR_HOST)/bin/kernel2minor -k $(KDIR)/loader-generic.elf -r $(VMLINUX)-lzma.nor-tik-yaffs2 -s 1024 -e +endif +#NAND flash 2048b with ECC +ifneq ($(CONFIG_TARGET_MIKROTIK_YAFFS2_NAND_2048B_ECC_FLASH_IMG),) + $(STAGING_DIR_HOST)/bin/kernel2minor -k $(KDIR)/loader-generic.elf -r $(VMLINUX)-lzma.nand-tik-yaffs2-2048b-ecc -s 2048 -c -e +endif +endef + # $(1): name of the 1st file. # $(2): size limit of the 1st file if it is greater than 262144, or # the erase size of the flash if it is greater than zero and less @@ -1682,6 +1693,9 @@ define Image/BuildKernel $(call MkuImage,gzip,,$(KDIR)/vmlinux.bin.gz,$(UIMAGE)-gzip.bin) $(call MkuImage,lzma,,$(KDIR)/vmlinux.bin.lzma,$(UIMAGE)-lzma.bin) cp $(KDIR)/loader-generic.elf $(VMLINUX)-lzma.elf +ifneq ($(CONFIG_TARGET_KERNELFS_MIKROTIK_YAFFS2),) + $(call kernel2mikrotikyaffs2) +endif -mkdir -p $(KDIR_TMP) $(call Image/Build/Profile/$(IMAGE_PROFILE),buildkernel) endef diff --git a/target/linux/ar71xx/mikrotik/target.mk b/target/linux/ar71xx/mikrotik/target.mk index b2fb0df..50a2903 100644 --- a/target/linux/ar71xx/mikrotik/target.mk +++ b/target/linux/ar71xx/mikrotik/target.mk @@ -1,5 +1,5 @@ -BOARDNAME:=Mikrotik devices with NAND flash -FEATURES += targz ramdisk +BOARDNAME:=Mikrotik devices with NAND/NOR flash +FEATURES += targz ramdisk kernel2mikrotikyaffs2 define Target/Description Build firmware images for Atheros AR71xx/AR913x based Mikrotik boards. diff --git a/tools/Makefile b/tools/Makefile index 187655e..0627ac2 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -38,6 +38,7 @@ tools-$(CONFIG_TARGET_x86) += qemu tools-$(CONFIG_TARGET_mxs) += elftosb sdimage tools-$(CONFIG_TARGET_brcm2708)$(CONFIG_TARGET_sunxi)$(CONFIG_TARGET_mxs) += mtools dosfstools tools-$(CONFIG_TARGET_ar71xx) += lzma-old squashfs +tools-$(CONFIG_USES_KERNEL2MIKROTIKYAFFS2) += kernel2minor tools-y += lzma squashfs4 tools-$(BUILD_B43_TOOLS) += b43-tools tools-$(BUILD_PPL_CLOOG) += ppl cloog diff --git a/tools/kernel2minor/Makefile b/tools/kernel2minor/Makefile new file mode 100644 index 0000000..e61ecbf --- /dev/null +++ b/tools/kernel2minor/Makefile @@ -0,0 +1,35 @@ +# +# Copyright (C) 2016 adron at yapic.net +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# +include $(TOPDIR)/rules.mk + +PKG_NAME:=kernel2minor +PKG_VERSION:=0.03 +PKG_RELEASE:=1 + +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz +PKG_SOURCE_URL:=https://github.com/adron-s/kernel2minor.git +PKG_SOURCE_PROTO:=git +PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION) +PKG_SOURCE_VERSION:=c52fa92855325a24fd850599d6b2d2ccf2bb9b31 + +HOST_BUILD_DIR:=$(BUILD_DIR_HOST)/$(PKG_NAME)-$(PKG_VERSION) + +include $(INCLUDE_DIR)/host-build.mk + +define Host/Compile + $(MAKE) -C $(HOST_BUILD_DIR) +endef + +define Host/Install + $(INSTALL_BIN) $(HOST_BUILD_DIR)/kernel2minor $(STAGING_DIR_HOST)/bin/ +endef + +define Host/Clean + rm -f $(STAGING_DIR_HOST)/bin/kernel2minor +endef + +$(eval $(call HostBuild)) -- 1.9.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From br1 at einfach.org Thu May 5 07:32:54 2016 From: br1 at einfach.org (Bruno Randolf) Date: Thu, 5 May 2016 12:32:54 +0100 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: References: <5179f6d1-283a-1b40-d717-2730c3408326@openwrt.org> <572A6C67.3040701@daniel.thecshore.com> <572A8E35.8090604@daniel.thecshore.com> Message-ID: <572B2F66.70003@einfach.org> On 05/05/16 02:02, Kathy Giori wrote: > On Wed, May 4, 2016 at 5:45 PM, Fernando Frediani wrote: >> Thanks Daniel. That explains a lot. >> I imagine if some digging is done it would be possible to find the holders >> of the critical resources and then re-organize it from scratch within the >> OpenWrt Project. >> But as the fork has already happened there is no much point in doing that. My conclusion is: As all active OpenWRT core developers have left the boat there must be something going on behind the scenes, which they feel can not be fixed within OpenWRT. If they don't change their mind, that's probably the end of OpenWRT, then... bruno _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From carlosmf.pt at gmail.com Thu May 5 07:47:24 2016 From: carlosmf.pt at gmail.com (Carlos Ferreira) Date: Thu, 5 May 2016 12:47:24 +0100 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <572B2F66.70003@einfach.org> References: <5179f6d1-283a-1b40-d717-2730c3408326@openwrt.org> <572A6C67.3040701@daniel.thecshore.com> <572A8E35.8090604@daniel.thecshore.com> <572B2F66.70003@einfach.org> Message-ID: I don't see the end of OpenWRT as a bad thing. If LEDE is basically a fork but without the development bottlenecks that seem to be affecting OpenwRT, then the change can be easily done by the industry segment that uses OpenWRT for their products. In fact, I see it as a good thing because it means that there are developers who care about the future of such embedded development environment. On 5 May 2016 at 12:32, Bruno Randolf wrote: > On 05/05/16 02:02, Kathy Giori wrote: > > On Wed, May 4, 2016 at 5:45 PM, Fernando Frediani > wrote: > >> Thanks Daniel. That explains a lot. > >> I imagine if some digging is done it would be possible to find the > holders > >> of the critical resources and then re-organize it from scratch within > the > >> OpenWrt Project. > >> But as the fork has already happened there is no much point in doing > that. > > My conclusion is: As all active OpenWRT core developers have left the > boat there must be something going on behind the scenes, which they feel > can not be fixed within OpenWRT. If they don't change their mind, that's > probably the end of OpenWRT, then... > > bruno > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > -- Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - cmf at av.it.pt Skype & GTalk -> carlosmf.pt at gmail.com LinkedIn -> http://www.linkedin.com/in/carlosmferreira -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From dgcbueu at gmail.com Thu May 5 08:42:27 2016 From: dgcbueu at gmail.com (dani) Date: Thu, 05 May 2016 14:42:27 +0200 Subject: [OpenWrt-Devel] [PATCH] brcm63xx: add Observa VH4032N support Message-ID: <2161761.QmDFQ3OGFv@tool> Add support for the Observa VH4032N router. It's a BCM6368 based board with 128MB RAM, 32MB flash. Equiped with an onboard USB hub. This hub has the RST# pin wired to the GPIO27 pin. For pulling the chip out of reset, we use ephy_reset since there isn't specific code for this function in the USB driver. The board has also switch LEDs, but they don't work as it happens with other bcm6368 boards. The GPIO pinmux still needs to be fixed for these hw controlled switch LEDs. Signed-off-by: Daniel Gonzalez diff -urN ./target/linux/brcm63xx/profiles/observa.mk ./target/linux/brcm63xx/profiles/observa.mk --- ./target/linux/brcm63xx/profiles/observa.mk 1970-01-01 01:00:00.000000000 +0100 +++ ./target/linux/brcm63xx/profiles/observa.mk 2016-04-20 21:13:56.680702590 +0200 @@ -0,0 +1,9 @@ +define Profile/VH4032N + NAME:=Observa Telecom VH4032N + PACKAGES:=kmod-b43 kmod-usb-core kmod-usb-ohci kmod-usb2 wpad-mini +endef +define Profile/VH4032N/Description + Package set for the Observa Telecom VH4032N +endef +$(eval $(call Profile,VH4032N)) + diff -urN ./target/linux/brcm63xx/base-files/etc/uci-defaults/09_fix_crc ./target/linux/brcm63xx/base-files/etc/uci-defaults/09_fix_crc --- ./target/linux/brcm63xx/base-files/etc/uci-defaults/09_fix_crc 2016-04-20 14:23:53.371339556 +0200 +++ ./target/linux/brcm63xx/base-files/etc/uci-defaults/09_fix_crc 2016-04-20 19:41:14.853717064 +0200 @@ -30,6 +30,7 @@ spw303v |\ v2110 |\ v2500v_bb |\ + vh4032n |\ vr-3025u |\ vr-3025un |\ vr-3026e |\ diff -urN ./target/linux/brcm63xx/base-files/etc/board.d/02_network ./target/linux/brcm63xx/base-files/etc/board.d/02_network --- ./target/linux/brcm63xx/base-files/etc/board.d/02_network 2016-04-20 14:23:53.371339556 +0200 +++ ./target/linux/brcm63xx/base-files/etc/board.d/02_network 2016-04-20 19:41:14.853717064 +0200 @@ -90,6 +90,7 @@ hg655b |\ p870hw-51a_v2 |\ r5010un_v2 |\ +vh4032n |\ vr-3025un |\ vr-3025u |\ vr-3026e) diff -urN ./target/linux/brcm63xx/base-files/etc/diag.sh ./target/linux/brcm63xx/base-files/etc/diag.sh --- ./target/linux/brcm63xx/base-files/etc/diag.sh 2016-04-20 14:23:53.371339556 +0200 +++ ./target/linux/brcm63xx/base-files/etc/diag.sh 2016-04-20 19:30:24.628933412 +0200 @@ -30,6 +30,9 @@ bcm96348gw-11) status_led="96348GW-11:green:power" ;; + vh4032n) + status_led="VH4032N:red:power" + ;; spw303v) status_led="spw303v:green:power+adsl" ;; diff -urN ./target/linux/brcm63xx/base-files/lib/brcm63xx.sh ./target/linux/brcm63xx/base-files/lib/brcm63xx.sh --- ./target/linux/brcm63xx/base-files/lib/brcm63xx.sh 2016-04-20 14:23:53.371339556 +0200 +++ ./target/linux/brcm63xx/base-files/lib/brcm63xx.sh 2016-04-20 20:53:21.196234734 +0200 @@ -186,6 +186,9 @@ "NuCom R5010UN v2") board_name="r5010un_v2" ;; + "Observa VH4032N") + board_name="vh4032n" + ;; "Pirelli A226G") board_name="a226g" ;; diff -urN ./target/linux/brcm63xx/dts/vh4032n.dts ./target/linux/brcm63xx/dts/vh4032n.dts --- ./target/linux/brcm63xx/dts/vh4032n.dts 1970-01-01 01:00:00.000000000 +0100 +++ ./target/linux/brcm63xx/dts/vh4032n.dts 2016-04-20 20:21:35.905231536 +0200 @@ -0,0 +1,89 @@ +/dts-v1/; + +#include "bcm6368.dtsi" + +#include + +/ { + model = "Observa VH4032N"; + compatible = "observa,vh4032n", "brcm,bcm6368"; + + gpio-keys-polled { + compatible = "gpio-keys-polled"; + #address-cells = <1>; + #size-cells = <0>; + poll-interval = <20>; + debounce-interval = <60>; + + reset { + label = "reset"; + gpios = <&gpio1 2 1>; + linux,code = ; + }; + wps { + label = "wps"; + gpios = <&gpio1 3 1>; + linux,code = ; + }; + }; + + gpio-leds { + compatible = "gpio-leds"; + + dsl_blue { + label = "VH4032N:blue:dsl"; + gpios = <&gpio0 2 1>; + }; + dsl_red { + label = "VH4032N:red:dsl"; + gpios = <&gpio0 5 1>; + }; + hspa_blue { + label = "VH4032N:blue:hspa"; + gpios = <&gpio0 11 1>; + }; + hspa_red { + label = "VH4032N:red:hspa"; + gpios = <&gpio0 12 1>; + }; + power_blue { + label = "VH4032N:blue:power"; + gpios = <&gpio0 22 0>; + }; + power_red { + label = "VH4032N:red:power"; + gpios = <&gpio0 24 0>; + default-state = "on"; + }; + voice_blue { + label = "VH4032N:blue:voice"; + gpios = <&gpio0 25 1>; + }; + voice_red { + label = "VH4032N:red:voice"; + gpios = <&gpio0 26 1>; + }; + }; +}; + +&pflash { + status = "ok"; + + linux,part-probe = "bcm63xxpart"; + + cfe at 0 { + label = "CFE"; + reg = <0x0000000 0x0020000>; + read-only; + }; + + linux at 20000 { + label = "linux"; + reg = <0x0020000 0x1fc0000>; + }; + + nvram at 1fe0000 { + label = "nvram"; + reg = <0x1fe0000 0x020000>; + }; +}; \ No newline at end of file diff -urN ./target/linux/brcm63xx/image/Makefile ./target/linux/brcm63xx/image/Makefile --- ./target/linux/brcm63xx/image/Makefile 2016-04-20 14:23:53.379343455 +0200 +++ ./target/linux/brcm63xx/image/Makefile 2016-04-20 20:59:38.543490836 +0200 @@ -595,6 +595,9 @@ $(eval $(call bcm63xxCfeNetgear,DGND3700v1_3800B,DGND3800B,dgnd3700v1,96368MVWG,6368,--image-offset 0x20000 --block-size 0x20000,U12L144T11_NETGEAR_NEWLED,1)) # NuCom R5010UNv2 $(eval $(call bcm63xxCfe,R5010UNV2,R5010UNv2,r5010unv2,96328ang,6328,--pad 8)) +# Observa VH4032N +$(eval $(call bcm63xxCfe,VH4032N,VH4032N,vh4032n,96368VVW,6368,--image-offset 0x20000 --block-size 0x20000 --pad 16)) +$(eval $(call bcm63xxCfe,VH4032N,VH4032N-sysupgrade,vh4032n,96368VVW,6368,--image-offset 0x20000 --block-size 0x20000)) # Pirelli Alice Gate VoIP 2 Plus Wi-Fi AGPF-S0 $(eval $(call bcm63xxCfe,AGPF_S0,AGV2+W,agpf-s0,AGPF-S0,6358,--block-size 0x20000 --image-offset 0x20000 --signature2 IMAGE --tag-version 8)) # Pirelli A226G diff -urN ./target/linux/brcm63xx/patches-4.1/575-board_VH4032N.patch ./target/linux/brcm63xx/patches-4.1/575-board_VH4032N.patch --- ./target/linux/brcm63xx/patches-4.1/575-board_VH4032N.patch 1970-01-01 01:00:00.000000000 +0100 +++ ./target/linux/brcm63xx/patches-4.1/575-board_VH4032N.patch 2016-04-20 21:09:05.696360759 +0200 @@ -0,0 +1,68 @@ +--- a/arch/mips/bcm63xx/boards/board_bcm963xx.c 2016-04-21 13:16:08.000000000 +0200 ++++ b/arch/mips/bcm63xx/boards/board_bcm963xx.c 2016-04-22 12:39:36.540538748 +0200 +@@ -2309,6 +2309,49 @@ + }, + }; + ++static struct board_info __initdata board_VH4032N = { ++ .name = "VH4032N", ++ .expected_cpu_id = 0x6368, ++ ++ .has_uart0 = 1, ++ .has_pci = 1, ++ .has_ohci0 = 1, ++ .has_ehci0 = 1, ++ .num_usbh_ports = 2, ++ ++ // Reset onboard USB hub chip using bcm63xx_enet driver. FIXME ++ .ephy_reset_gpio = 27, ++ .ephy_reset_gpio_flags = GPIO_ACTIVE_LOW, ++ ++ .has_enetsw = 1, ++ .enetsw = { ++ .used_ports = { ++ [0] = { ++ .used = 1, ++ .phy_id = 1, ++ .name = "port1", ++ }, ++ [1] = { ++ .used = 1, ++ .phy_id = 2, ++ .name = "port2", ++ }, ++ [2] = { ++ .used = 1, ++ .phy_id = 3, ++ .name = "port3", ++ }, ++ [3] = { ++ .used = 1, ++ .phy_id = 4, ++ .name = "port4", ++ }, ++ }, ++ }, ++ ++ .use_fallback_sprom = 1, ++}; ++ + static struct b53_platform_data WAP5813n_b53_pdata = { + .alias = "eth0", + }; +@@ -2613,6 +2672,7 @@ + &board_HG622, + &board_HG655b, + &board_P870HW51A_V2, ++ &board_VH4032N, + &board_VR3025u, + &board_VR3025un, + &board_VR3026e, +@@ -2722,6 +2782,7 @@ + { .compatible = "huawei,hg622", .data = &board_HG622, }, + { .compatible = "huawei,hg655b", .data = &board_HG655b, }, + { .compatible = "netgear,dgnd3700v1", .data = &board_DGND3700v1_3800B, }, ++ { .compatible = "observa,vh4032n", .data = &board_VH4032N, }, + { .compatible = "zyxel,p870hw-51a-v2", .data = &board_P870HW51A_V2, }, + #endif + #ifdef CONFIG_BCM63XX_CPU_63268 diff -urN ./target/linux/brcm63xx/patches-4.4/575-board_VH4032N.patch ./target/linux/brcm63xx/patches-4.4/575-board_VH4032N.patch --- ./target/linux/brcm63xx/patches-4.4/575-board_VH4032N.patch 1970-01-01 01:00:00.000000000 +0100 +++ ./target/linux/brcm63xx/patches-4.4/575-board_VH4032N.patch 2016-04-20 21:09:05.696360759 +0200 @@ -0,0 +1,68 @@ +--- a/arch/mips/bcm63xx/boards/board_bcm963xx.c 2016-04-21 13:16:08.000000000 +0200 ++++ b/arch/mips/bcm63xx/boards/board_bcm963xx.c 2016-04-22 12:39:36.540538748 +0200 +@@ -2310,6 +2310,49 @@ + }, + }; + ++static struct board_info __initdata board_VH4032N = { ++ .name = "VH4032N", ++ .expected_cpu_id = 0x6368, ++ ++ .has_uart0 = 1, ++ .has_pci = 1, ++ .has_ohci0 = 1, ++ .has_ehci0 = 1, ++ .num_usbh_ports = 2, ++ ++ // Reset onboard USB hub chip using bcm63xx_enet driver. FIXME ++ .ephy_reset_gpio = 27, ++ .ephy_reset_gpio_flags = GPIO_ACTIVE_LOW, ++ ++ .has_enetsw = 1, ++ .enetsw = { ++ .used_ports = { ++ [0] = { ++ .used = 1, ++ .phy_id = 1, ++ .name = "port1", ++ }, ++ [1] = { ++ .used = 1, ++ .phy_id = 2, ++ .name = "port2", ++ }, ++ [2] = { ++ .used = 1, ++ .phy_id = 3, ++ .name = "port3", ++ }, ++ [3] = { ++ .used = 1, ++ .phy_id = 4, ++ .name = "port4", ++ }, ++ }, ++ }, ++ ++ .use_fallback_sprom = 1, ++}; ++ + static struct b53_platform_data WAP5813n_b53_pdata = { + .alias = "eth0", + }; +@@ -2614,6 +2673,7 @@ + &board_HG622, + &board_HG655b, + &board_P870HW51A_V2, ++ &board_VH4032N, + &board_VR3025u, + &board_VR3025un, + &board_VR3026e, +@@ -2723,6 +2783,7 @@ + { .compatible = "huawei,hg622", .data = &board_HG622, }, + { .compatible = "huawei,hg655b", .data = &board_HG655b, }, + { .compatible = "netgear,dgnd3700v1", .data = &board_DGND3700v1_3800B, }, ++ { .compatible = "observa,vh4032n", .data = &board_VH4032N, }, + { .compatible = "zyxel,p870hw-51a-v2", .data = &board_P870HW51A_V2, }, + #endif + #ifdef CONFIG_BCM63XX_CPU_63268 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From wigyori at uid0.hu Thu May 5 08:48:35 2016 From: wigyori at uid0.hu (Zoltan HERPAI) Date: Thu, 5 May 2016 14:48:35 +0200 (CEST) Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <572B2F66.70003@einfach.org> References: <5179f6d1-283a-1b40-d717-2730c3408326@openwrt.org> <572A6C67.3040701@daniel.thecshore.com> <572A8E35.8090604@daniel.thecshore.com> <572B2F66.70003@einfach.org> Message-ID: Hi, On Thu, 5 May 2016, Bruno Randolf wrote: > On 05/05/16 02:02, Kathy Giori wrote: >> On Wed, May 4, 2016 at 5:45 PM, Fernando Frediani wrote: >>> Thanks Daniel. That explains a lot. >>> I imagine if some digging is done it would be possible to find the holders >>> of the critical resources and then re-organize it from scratch within the >>> OpenWrt Project. >>> But as the fork has already happened there is no much point in doing that. > > My conclusion is: As all active OpenWRT core developers have left the > boat there must be something going on behind the scenes, which they feel > can not be fixed within OpenWRT. If they don't change their mind, that's > probably the end of OpenWRT, then... I would not call "all active OpenWrt core developers" have left the boat. Take a look at this [1] page - some of them are active, some of them are not, but calling an end to the project is an overstatement at least. Also, refer to the mail Mike sent out last night. Thanks, -w- [1] https://dev.openwrt.org/wiki/people _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From br1 at einfach.org Thu May 5 09:06:02 2016 From: br1 at einfach.org (Bruno Randolf) Date: Thu, 5 May 2016 14:06:02 +0100 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: References: <5179f6d1-283a-1b40-d717-2730c3408326@openwrt.org> <572A6C67.3040701@daniel.thecshore.com> <572A8E35.8090604@daniel.thecshore.com> <572B2F66.70003@einfach.org> Message-ID: <572B453A.8020105@einfach.org> On 05/05/16 13:48, Zoltan HERPAI wrote: > I would not call "all active OpenWrt core developers" have left the > boat. Take a look at this [1] page - some of them are active, some of > them are not, but calling an end to the project is an overstatement at > least. Also, refer to the mail Mike sent out last night. Well, you are right, I should not make predictions of the future... ;) But as someone who is following, using, building upon and sometimes contributing to OpenWRT since ~10 years I can only say that the only developers who have been visible, reacting and committing stuff have left. I still wonder why, of course... bruno _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From aczlan+openwrt at gmail.com Thu May 5 09:08:33 2016 From: aczlan+openwrt at gmail.com (Aaron Z) Date: Thu, 5 May 2016 09:08:33 -0400 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <572B453A.8020105@einfach.org> References: <5179f6d1-283a-1b40-d717-2730c3408326@openwrt.org> <572A6C67.3040701@daniel.thecshore.com> <572A8E35.8090604@daniel.thecshore.com> <572B2F66.70003@einfach.org> <572B453A.8020105@einfach.org> Message-ID: On Thu, May 5, 2016 at 9:06 AM, Bruno Randolf wrote: > > But as someone who is following, using, building upon and sometimes > contributing to OpenWRT since ~10 years I can only say that the only > developers who have been visible, reacting and committing stuff have > left. I still wonder why, of course... +1 (although I might change "the only" to "the majority of the"). Aaron Z A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. ? Robert Heinlein, Time Enough for Love _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From nbd at nbd.name Thu May 5 10:40:47 2016 From: nbd at nbd.name (Felix Fietkau) Date: Thu, 5 May 2016 15:40:47 +0100 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <572A5501.3040807@openwrt.org> References: <572A5501.3040807@openwrt.org> Message-ID: <572B5B6F.7080203@nbd.name> Hi Mike, thank you for reaching out to us and for your interest in addressing these issues. On 2016-05-04 21:01, mbm wrote: > Dear OpenWrt community, > > It is with a great amount of surprise that, like all of you, we read > about the announcement of the LEDE project yesterday, as there was no > prior announcement nor clues this would happen. > > While we recognize the current OpenWrt project suffers from a number of > issues outlined by Jo-Philip, in each of the 5 bullet points, we do not > agree with the conclusions withdrawn, and even less so in deciding to > spin off the OpenWrt project in the first place as a way to fix the > project and its community. Also, the phrases such as a "reboot" are both > vague and misleading and the LEDE project failed to identify its true > nature. The LEDE announcement contains a number of very valid points > which we hoped we had an opportunity to discuss and attempt to fix, in a > public manner, before this more radical outcome. At this point, the > email as well as actions taken are very confusing to a lot of us. Many of the changes that we previously tried to introduce were often squashed by internal disagreements. Resulting discussions often turned toxic quickly and led to nothing being done to address the issues. Setting up the LEDE project was our way of creating a testbed for changes that we believe are important for the survival of the project. > OpenWrt is primarily developed by individuals who may have a day job > more or less related to the purpose or the technologies of the project, > but who strive to maintain OpenWrt as independent as possible from any > company, organization or interest group, thus maintaining its own > infrastructure (website, forums, mailing-lists, bugtracker...), which > has been usually at the heart of all debates. A critical part of many of these debates was the fact that people who were controlling critical pieces of the infrastructure flat out refused to allow other people to step up and help, even in the face of being unable to deal with important issues themselves in a timely manner. This kind of single-point-of-failure thing has been going on for years, with no significant progress on resolving it. In the LEDE project we decided to significantly simplify the infrastructure and spread out admin access enough to minimize the chance of this situation ever happening again. > We do acknowledge there has been internal disagreements, on several > occasions about some directions of the project, about the release model, > the lack of testing, the centralized infrastructure, however, there have > been actual work going on under the hoods to solve things one step at a > time, starting with a more decentralized infrastructure, which was > discussed with the LEDE developers as well. While we have pushed for and actively worked on decentralizing the infrastructure, we were also frequently asked to move back to centralizing things again. The excessive downtime of the main site this year is a good example of why we definitely don't want to go that way. > At this point, we do not have much to offer to the LEDE developers but > to encourage them to publicly discuss on > openwrt-devel at lists.openwrt.org the different items we should all be > fixing together, and avoid spinning off so that all decisions can be > taken with the community's involvement, and accountability and > transparency can rule us as one community. Do you think we can get the changes outlined by the LEDE project implement in OpenWrt? If so, how? > As a user, developer, contributor, or just community member, whatever > choice you make, keep the choice that matters to you: the ability to > utilize superior quality open source software to power whatever embedded > device that matters to you! > > We would like to stress that we do want to have an open discussion and > resolve matters at hand. Our goal is to work with all parties who can > and want to contribute to OpenWrt, including the LEDE team. We appreciate your effort to have an open discussion about this, however the sudden deletion of our widely published openwrt.org email addresses somewhat undermines this. We will not respond in kind and we will continue to maintain the critical parts of OpenWrt infrastructure that we control. Regards, Felix Fietkau Jo-Philipp Wich _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Thu May 5 10:43:17 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Thu, 5 May 2016 10:43:17 -0400 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: References: <572A5501.3040807@openwrt.org> <572AC280.1000608@daniel.thecshore.com> Message-ID: <572B5C05.8080306@daniel.thecshore.com> On 16-05-05 05:34 AM, Roman Yeryomin wrote: > On 5 May 2016 at 06:48, Daniel Dickinson wrote: >> On 16-05-04 04:01 PM, mbm wrote: >>> Dear OpenWrt community, >>> [snip] > > One simple question: > If LEDE team members are the ones who were suffering from some > non-democratic decisions, why didn't they bring it to public > discussion for community? At least on devel maillist? > > If it was clear problem in remaining OpenWrt team then LEDE would win > the community right away or maybe problematic people would just go > away. Either way it would be more fair and open. And this is one of my > biggest concerns - LEDE team is promoting openness but didn't do their > moves openly (looking at maillists it seems they were hiding it for > month at least). Hate double standards. Perhaps for fear of repercussions such as what has happened since the fork where all LEDE members @openwrt.org email addresses have been deleted? There are a number of people in the LEDE group I've found to be pretty decent people, and great to work with, so I find it unlikely that they simply acted without good reason. Regards, Daniel > > >>> We do acknowledge there has been internal disagreements, on several >>> occasions about some directions of the project, about the release model, >>> the lack of testing, the centralized infrastructure, however, there have >>> been actual work going on under the hoods to solve things one step at a >> >> Perhaps 'under-the-hood' is the problem. Did everyone with concerns >> know or have insight into what steps were currently being taken and what >> was planned, and have planned actions been followed through on, once >> *agreed* as a solution? >> >> Also, is the decision making process egalitarian and democratic amongst >> those still actively in the project, or are some 'more equal' than others? >> >> Regards, >> >> Daniel >> _______________________________________________ >> openwrt-devel mailing list >> openwrt-devel at lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From leroi.lists at gmail.com Thu May 5 11:04:24 2016 From: leroi.lists at gmail.com (Roman Yeryomin) Date: Thu, 5 May 2016 18:04:24 +0300 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <572B5C05.8080306@daniel.thecshore.com> References: <572A5501.3040807@openwrt.org> <572AC280.1000608@daniel.thecshore.com> <572B5C05.8080306@daniel.thecshore.com> Message-ID: On 5 May 2016 at 17:43, Daniel Dickinson wrote: > On 16-05-05 05:34 AM, Roman Yeryomin wrote: >> On 5 May 2016 at 06:48, Daniel Dickinson wrote: >>> On 16-05-04 04:01 PM, mbm wrote: >>>> Dear OpenWrt community, >>>> > [snip] >> >> One simple question: >> If LEDE team members are the ones who were suffering from some >> non-democratic decisions, why didn't they bring it to public >> discussion for community? At least on devel maillist? >> >> If it was clear problem in remaining OpenWrt team then LEDE would win >> the community right away or maybe problematic people would just go >> away. Either way it would be more fair and open. And this is one of my >> biggest concerns - LEDE team is promoting openness but didn't do their >> moves openly (looking at maillists it seems they were hiding it for >> month at least). Hate double standards. > > Perhaps for fear of repercussions such as what has happened since the > fork where all LEDE members @openwrt.org email addresses have been deleted? AFAIK, that was done after LEDE announcement but IMO was a wrong move anyway. > There are a number of people in the LEDE group I've found to be pretty > decent people, and great to work with, so I find it unlikely that they > simply acted without good reason. This only add more shock to the announcement. Regards, Roman _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From inindev at gmail.com Thu May 5 11:11:49 2016 From: inindev at gmail.com (John Clark) Date: Thu, 5 May 2016 11:11:49 -0400 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: References: <572A5501.3040807@openwrt.org> <572AC280.1000608@daniel.thecshore.com> <572B5C05.8080306@daniel.thecshore.com> Message-ID: <572B62B5.4000602@gmail.com> >>the sudden deletion of our widely published openwrt.org email addresses somewhat undermines this Just so I am not jumping to wrong conclusions, their *.openwrt.org email addresses were deleted in retaliation for forking OpenWrt? Seriously? How did you not think that wasn't going to go well after all they have done for OpenWrt? --John On 5/5/16 11:04 AM, Roman Yeryomin wrote: > On 5 May 2016 at 17:43, Daniel Dickinson wrote: >> On 16-05-05 05:34 AM, Roman Yeryomin wrote: >>> On 5 May 2016 at 06:48, Daniel Dickinson wrote: >>>> On 16-05-04 04:01 PM, mbm wrote: >>>>> Dear OpenWrt community, >>>>> >> [snip] >>> One simple question: >>> If LEDE team members are the ones who were suffering from some >>> non-democratic decisions, why didn't they bring it to public >>> discussion for community? At least on devel maillist? >>> >>> If it was clear problem in remaining OpenWrt team then LEDE would win >>> the community right away or maybe problematic people would just go >>> away. Either way it would be more fair and open. And this is one of my >>> biggest concerns - LEDE team is promoting openness but didn't do their >>> moves openly (looking at maillists it seems they were hiding it for >>> month at least). Hate double standards. >> Perhaps for fear of repercussions such as what has happened since the >> fork where all LEDE members @openwrt.org email addresses have been deleted? > AFAIK, that was done after LEDE announcement but IMO was a wrong move anyway. > >> There are a number of people in the LEDE group I've found to be pretty >> decent people, and great to work with, so I find it unlikely that they >> simply acted without good reason. > This only add more shock to the announcement. > > Regards, > Roman > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Thu May 5 11:24:52 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Thu, 5 May 2016 11:24:52 -0400 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <572B62B5.4000602@gmail.com> References: <572A5501.3040807@openwrt.org> <572AC280.1000608@daniel.thecshore.com> <572B5C05.8080306@daniel.thecshore.com> <572B62B5.4000602@gmail.com> Message-ID: <572B65C4.8040908@daniel.thecshore.com> On 16-05-05 11:11 AM, John Clark wrote: >>>the sudden deletion of our widely published openwrt.org email > addresses somewhat undermines this > > Just so I am not jumping to wrong conclusions, their *.openwrt.org email @openwrt.org actually > addresses were deleted in retaliation for forking OpenWrt? Seriously? Yep. > How did you not think that wasn't going to go well after all they have > done for OpenWrt? I think you mean "How did you think that wasn't *not* going to go well after all they have done for OpenWrt". Regards, Daniel > > --John > > > On 5/5/16 11:04 AM, Roman Yeryomin wrote: >> On 5 May 2016 at 17:43, Daniel Dickinson >> wrote: >>> On 16-05-05 05:34 AM, Roman Yeryomin wrote: >>>> On 5 May 2016 at 06:48, Daniel Dickinson >>>> wrote: >>>>> On 16-05-04 04:01 PM, mbm wrote: >>>>>> Dear OpenWrt community, >>>>>> >>> [snip] >>>> One simple question: >>>> If LEDE team members are the ones who were suffering from some >>>> non-democratic decisions, why didn't they bring it to public >>>> discussion for community? At least on devel maillist? >>>> >>>> If it was clear problem in remaining OpenWrt team then LEDE would win >>>> the community right away or maybe problematic people would just go >>>> away. Either way it would be more fair and open. And this is one of my >>>> biggest concerns - LEDE team is promoting openness but didn't do their >>>> moves openly (looking at maillists it seems they were hiding it for >>>> month at least). Hate double standards. >>> Perhaps for fear of repercussions such as what has happened since the >>> fork where all LEDE members @openwrt.org email addresses have been >>> deleted? >> AFAIK, that was done after LEDE announcement but IMO was a wrong move >> anyway. >> >>> There are a number of people in the LEDE group I've found to be pretty >>> decent people, and great to work with, so I find it unlikely that they >>> simply acted without good reason. >> This only add more shock to the announcement. >> >> Regards, >> Roman >> _______________________________________________ >> openwrt-devel mailing list >> openwrt-devel at lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Thu May 5 11:26:51 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Thu, 5 May 2016 11:26:51 -0400 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <572B65C4.8040908@daniel.thecshore.com> References: <572A5501.3040807@openwrt.org> <572AC280.1000608@daniel.thecshore.com> <572B5C05.8080306@daniel.thecshore.com> <572B62B5.4000602@gmail.com> <572B65C4.8040908@daniel.thecshore.com> Message-ID: <572B663B.7010308@daniel.thecshore.com> On 16-05-05 11:24 AM, Daniel Dickinson wrote: > On 16-05-05 11:11 AM, John Clark wrote: >>>> the sudden deletion of our widely published openwrt.org email >> addresses somewhat undermines this >> >> Just so I am not jumping to wrong conclusions, their *.openwrt.org email > > @openwrt.org actually > >> addresses were deleted in retaliation for forking OpenWrt? Seriously? > > Yep. > >> How did you not think that wasn't going to go well after all they have >> done for OpenWrt? > > I think you mean "How did you think that wasn't *not* going to go well > after all they have done for OpenWrt". > Sorry, my bad, I parsed you wrong, you had the right grammer. Regards, Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From jbscience87 at gmail.com Thu May 5 11:38:35 2016 From: jbscience87 at gmail.com (Jonathan Bennett) Date: Thu, 05 May 2016 15:38:35 +0000 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <572B62B5.4000602@gmail.com> References: <572A5501.3040807@openwrt.org> <572AC280.1000608@daniel.thecshore.com> <572B5C05.8080306@daniel.thecshore.com> <572B62B5.4000602@gmail.com> Message-ID: There is plenty of blame to go around, I think. Seems like the Lede guys should have had the decency to at least inform the Openwrt leadership privately that they were planning this venture. The surprise announcement must have felt very much like a stab in the back. "Et tu, brute?" and all that. I think they want a "friendly fork" as much as possible, but they dropped the ball in how they announced it. I suspect that a private email to mbm and kaloz could have gone a long ways towards heading off problems. As has been pointed out, the public announcement should not have come from an @openwrt.org email. That said, deleting their emails was totally uncalled for. Seems that those should be restored, perhaps with the caveat that they are more carefully used with regards to Lede, aka, not for publicizing or promoting it. Guys, for the love of the project, the users, and all else that is good, please don't make this a ffmpeg/libav split. Openwrt has been an amazing thing for a long time, and if mishandled, this has the potential to actually kill it. The changes that the Lede guys are suggesting would be welcome, but splitting the project and community with an ugly fork is very much not welcome. --Jonathan Bennett On Thu, May 5, 2016 at 10:12 AM John Clark wrote: > >>the sudden deletion of our widely published openwrt.org email > addresses somewhat undermines this > > Just so I am not jumping to wrong conclusions, their *.openwrt.org email > addresses were deleted in retaliation for forking OpenWrt? Seriously? > How did you not think that wasn't going to go well after all they have > done for OpenWrt? > > --John > > > On 5/5/16 11:04 AM, Roman Yeryomin wrote: > > On 5 May 2016 at 17:43, Daniel Dickinson > wrote: > >> On 16-05-05 05:34 AM, Roman Yeryomin wrote: > >>> On 5 May 2016 at 06:48, Daniel Dickinson > wrote: > >>>> On 16-05-04 04:01 PM, mbm wrote: > >>>>> Dear OpenWrt community, > >>>>> > >> [snip] > >>> One simple question: > >>> If LEDE team members are the ones who were suffering from some > >>> non-democratic decisions, why didn't they bring it to public > >>> discussion for community? At least on devel maillist? > >>> > >>> If it was clear problem in remaining OpenWrt team then LEDE would win > >>> the community right away or maybe problematic people would just go > >>> away. Either way it would be more fair and open. And this is one of my > >>> biggest concerns - LEDE team is promoting openness but didn't do their > >>> moves openly (looking at maillists it seems they were hiding it for > >>> month at least). Hate double standards. > >> Perhaps for fear of repercussions such as what has happened since the > >> fork where all LEDE members @openwrt.org email addresses have been > deleted? > > AFAIK, that was done after LEDE announcement but IMO was a wrong move > anyway. > > > >> There are a number of people in the LEDE group I've found to be pretty > >> decent people, and great to work with, so I find it unlikely that they > >> simply acted without good reason. > > This only add more shock to the announcement. > > > > Regards, > > Roman > > _______________________________________________ > > openwrt-devel mailing list > > openwrt-devel at lists.openwrt.org > > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From daniel.petre at posteo.net Thu May 5 11:44:43 2016 From: daniel.petre at posteo.net (Daniel Petre) Date: Thu, 5 May 2016 18:44:43 +0300 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: References: <572A5501.3040807@openwrt.org> <572AC280.1000608@daniel.thecshore.com> <572B5C05.8080306@daniel.thecshore.com> <572B62B5.4000602@gmail.com> Message-ID: <7e13620b-8d68-f587-eea2-ab97865d549f@posteo.net> On 05/05/2016 06:38 PM, Jonathan Bennett wrote: > There is plenty of blame to go around, I think. Seems like the Lede > guys should have had the decency to at least inform the Openwrt > leadership privately that they were planning this venture. If i read correctly the feedback from the LEDE guys (and many of the people in here) then it seems EVEN THEY did not had any serious real feedback since a while ago from the main OpenWrt "headquarters". So.. what do you do when you ask (probably several times) and do not get any answer at all.. ? _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Thu May 5 11:58:18 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Thu, 5 May 2016 11:58:18 -0400 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: References: <572A5501.3040807@openwrt.org> <572AC280.1000608@daniel.thecshore.com> <572B5C05.8080306@daniel.thecshore.com> <572B62B5.4000602@gmail.com> Message-ID: <572B6D9A.6030606@daniel.thecshore.com> On 16-05-05 11:38 AM, Jonathan Bennett wrote: > There is plenty of blame to go around, I think. Seems like the Lede > guys should have had the decency to at least inform the Openwrt > leadership privately that they were planning this venture. The surprise The problem is that LEDE is pretty much who should be considered "OpenWrt Leadership" IMO as they are the majority of ones doing the actual work. This isn't like working for some bad corp (I currently have good managers so it's better than for me even at work) where there are (supposed to be) execs making the decisions regardless of what those doing the work think. > announcement must have felt very much like a stab in the back. "Et tu, > brute?" and all that. I think they want a "friendly fork" as much as > possible, but they dropped the ball in how they announced it. I suspect > that a private email to mbm and kaloz could have gone a long ways > towards heading off problems. As has been pointed out, the public I think the reason for no private email was either fear of retaliation or something major had already happened 'behind-the-scenes' that made that moot. I'm not sure their silence is entirely their choice as well (as in I find the lack of any posts has me wondering if they can post). > announcement should not have come from an @openwrt.org > email. That much I agree with. > > That said, deleting their emails was totally uncalled for. Seems that > those should be restored, perhaps with the caveat that they are more > carefully used with regards to Lede, aka, not for publicizing or > promoting it. > > Guys, for the love of the project, the users, and all else that is good, > please don't make this a ffmpeg/libav split. Openwrt has been an > amazing thing for a long time, and if mishandled, this has the potential > to actually kill it. > > The changes that the Lede guys are suggesting would be welcome, but > splitting the project and community with an ugly fork is very much not > welcome. Let's just say that there are strong personalities who haven't been working well together and that this has been a long time coming; perhaps if something like using a mediator had been considered before things got to this point it would have helped. At this point I'm not sure there is a solution unless both sides are willing to bend a little (I'm really not sure who has been flexible and who has not, but as I have said I suspect a large part of the issue is that 'management' (who aren't and don't, really) has overruled those doing the majority of the work and in an open source project that doesn't fly). Regards, Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From jbscience87 at gmail.com Thu May 5 12:21:31 2016 From: jbscience87 at gmail.com (Jonathan Bennett) Date: Thu, 05 May 2016 16:21:31 +0000 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <572B6D9A.6030606@daniel.thecshore.com> References: <572A5501.3040807@openwrt.org> <572AC280.1000608@daniel.thecshore.com> <572B5C05.8080306@daniel.thecshore.com> <572B62B5.4000602@gmail.com> <572B6D9A.6030606@daniel.thecshore.com> Message-ID: On Thu, May 5, 2016 at 10:58 AM Daniel Dickinson < openwrt at daniel.thecshore.com> wrote: > On 16-05-05 11:38 AM, Jonathan Bennett wrote: > > There is plenty of blame to go around, I think. Seems like the Lede > > guys should have had the decency to at least inform the Openwrt > > leadership privately that they were planning this venture. The surprise > > The problem is that LEDE is pretty much who should be considered > "OpenWrt Leadership" IMO as they are the majority of ones doing the > actual work. This isn't like working for some bad corp (I currently > have good managers so it's better than for me even at work) where there > are (supposed to be) execs making the decisions regardless of what those > doing the work think. > > > announcement must have felt very much like a stab in the back. "Et tu, > > brute?" and all that. I think they want a "friendly fork" as much as > > possible, but they dropped the ball in how they announced it. I suspect > > that a private email to mbm and kaloz could have gone a long ways > > towards heading off problems. As has been pointed out, the public > > I think the reason for no private email was either fear of retaliation > or something major had already happened 'behind-the-scenes' that made > that moot. > > I'm not sure their silence is entirely their choice as well (as in I > find the lack of any posts has me wondering if they can post). > > > announcement should not have come from an @openwrt.org > > email. > > That much I agree with. > > > > > That said, deleting their emails was totally uncalled for. Seems that > > those should be restored, perhaps with the caveat that they are more > > carefully used with regards to Lede, aka, not for publicizing or > > promoting it. > > > > Guys, for the love of the project, the users, and all else that is good, > > please don't make this a ffmpeg/libav split. Openwrt has been an > > amazing thing for a long time, and if mishandled, this has the potential > > to actually kill it. > > > > The changes that the Lede guys are suggesting would be welcome, but > > splitting the project and community with an ugly fork is very much not > > welcome. > > Let's just say that there are strong personalities who haven't been > working well together and that this has been a long time coming; perhaps > if something like using a mediator had been considered before things got > to this point it would have helped. At this point I'm not sure there is a > solution unless both sides are willing to bend a little (I'm really not > sure who has been flexible and who has not, but as I have said I suspect > a large part of the issue is that 'management' (who aren't and don't, > really) has overruled those doing the majority of the work and in an > open source project that doesn't fly). > I don't disagree. I just see the current state of Openwrt/Lede as a mess for the community. > > Regards, > > Daniel > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Thu May 5 12:24:09 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Thu, 5 May 2016 12:24:09 -0400 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: References: <572A5501.3040807@openwrt.org> <572AC280.1000608@daniel.thecshore.com> <572B5C05.8080306@daniel.thecshore.com> <572B62B5.4000602@gmail.com> <572B6D9A.6030606@daniel.thecshore.com> Message-ID: <572B73A9.9070909@daniel.thecshore.com> On 16-05-05 12:21 PM, Jonathan Bennett wrote: [snip] > > The changes that the Lede guys are suggesting would be welcome, but > > splitting the project and community with an ugly fork is very much not > > welcome. > > Let's just say that there are strong personalities who haven't been > working well together and that this has been a long time coming; perhaps > if something like using a mediator had been considered before things got > to this point it would have helped. At this point I'm not sure > there is a > solution unless both sides are willing to bend a little (I'm really not > sure who has been flexible and who has not, but as I have said I suspect > a large part of the issue is that 'management' (who aren't and don't, > really) has overruled those doing the majority of the work and in an > open source project that doesn't fly). > > I don't disagree. I just see the current state of Openwrt/Lede as a > mess for the community. I agree, I just don't see how the LEDE team could have avoided it without giving up and accepting the broken status quo. Regards, Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Thu May 5 12:29:35 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Thu, 5 May 2016 12:29:35 -0400 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <572B73A9.9070909@daniel.thecshore.com> References: <572A5501.3040807@openwrt.org> <572AC280.1000608@daniel.thecshore.com> <572B5C05.8080306@daniel.thecshore.com> <572B62B5.4000602@gmail.com> <572B6D9A.6030606@daniel.thecshore.com> <572B73A9.9070909@daniel.thecshore.com> Message-ID: <572B74EF.6020805@daniel.thecshore.com> On 16-05-05 12:24 PM, Daniel Dickinson wrote: > On 16-05-05 12:21 PM, Jonathan Bennett wrote: > [snip] >> > The changes that the Lede guys are suggesting would be welcome, but >> > splitting the project and community with an ugly fork is very much not >> > welcome. >> >> Let's just say that there are strong personalities who haven't been >> working well together and that this has been a long time coming; perhaps >> if something like using a mediator had been considered before things got >> to this point it would have helped. At this point I'm not sure >> there is a >> solution unless both sides are willing to bend a little (I'm really not >> sure who has been flexible and who has not, but as I have said I suspect >> a large part of the issue is that 'management' (who aren't and don't, >> really) has overruled those doing the majority of the work and in an >> open source project that doesn't fly). >> >> I don't disagree. I just see the current state of Openwrt/Lede as a >> mess for the community. > > I agree, I just don't see how the LEDE team could have avoided it > without giving up and accepting the broken status quo. When I say broken I mean I think openwrt was dying and I pointed out not all that long ago that openwrt was in bad position and that something needed to change, and I think that may have been *part* of the reason accepting the status quo was no longer an acceptable answer. Regards, Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From bmoffitt at ayrstone.com Thu May 5 12:33:29 2016 From: bmoffitt at ayrstone.com (Bill) Date: Thu, 5 May 2016 09:33:29 -0700 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: References: Message-ID: I confess I am one of those people who has benefited much more than I have contributed to the OpenWRT development group. I run a small company in which I am the chief developer, administrator, customer support dude, marketer, and salesguy. I would LOVE to be able to contribute more to the OpenWRT community, and I do try to test things that are in my way and report what I find from those tests, but I certainly don't feel I pull my weight. However, in my defense, as you can probably surmise from the description of my job, we're not exactly rolling in extra money or time to contribute. Which I regret, but it is what it is. Anyone interested in joining a currently unfunded startup using OpenWRT, please get in touch. I recently purchased a WiFi access point that I realized upon plugging it in was running a somewhat restricted version of OpenWRT. I won't say who makes it, but it's a very clever, one might say ingenious, product that I like very much. However, when I looked at the OpenWRT tree, I could not find an OpenWRT build for this particular device. And that, I must say, has REALLY annoyed me - the company clearly expended some resources to port OpenWRT to their clever device, and certainly benefits from it, but they apparently did not contribute the work they did to support this device back to the community so it could be "officially" part of the OpenWRT ecosystem. I have also been painfully aware of the infrastructure difficulties that OpenWRT has faced, and I have been quietly admiring the work of those who keep it running as well as it does. As scary as it was when IBM got deeply involved in Linux back in the early 2000s, for instance, I would say their involvement has benefited both parties. OpenWRT is actually a pretty mature and popular codebase, and it deserves much better infrastructure than it has now. In order to get a better infrastructure, of course, we need, as a community, to attract partners with the ability to contribute that infrastructure. It's great to be in a project that is not beholden to any big companies UNTIL you actually want to get something significant done. Pragmatism has its place. That's why I was a bit taken aback at the reluctance to embrace prpl's offer. I would like to see an organization in which all possible partners should be welcomed into the community; while we should be appropriately cautious about accepting code from anyone, and subject it to strict review as to suitability, fit with mission and architecture, and quality, we should be pulling partners in, not holding them at arm's length. My hope is that LEDE will either bring this level of pragmatism or will enable OpenWRT to be more pragmatic. Of course, we have to be clear about the mission, architecture, and the standards of suitability and quality... perhaps that is the departure point for LEDE? I, for one, am eager to better understand, in full atomic granularity, the problems that have led to this departure and what, again, in atomic granularity, LEDE proposes to do differently. My thinking is that, if OpenWRT or LEDE is able to attract more support from the corporate world, it will serve as an example to those who are using OpenWRT/LEDE of what is expected of a larger company that is gaining from the use of the software, hopefully pressuring them to step up and be better members of the community. I also think that it will lead to more visibility, which can help bring in folks like me who have an idea and can leverage off of OpenWRT/LEDE to produce products that are out of the mainstream. I'm not privy to all, indeed, any, of the discussions that have led to this point of departure; I am commenting as a strict outsider. My simple desire is to see the codebase continue to grow, in both code and users, and the community to be as open and welcoming as possible. I hope that this move will help achieve that for at least one of the resultant groups. And I shall do what I can to help either or both. My last comment is that the more open of the two communities is likely to be the one where I can most easily see how I might contribute. -Bill -- Bill Moffitt Ayrstone Productivity LLC -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From leroi.lists at gmail.com Thu May 5 12:59:42 2016 From: leroi.lists at gmail.com (Roman Yeryomin) Date: Thu, 5 May 2016 19:59:42 +0300 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <572B74EF.6020805@daniel.thecshore.com> References: <572A5501.3040807@openwrt.org> <572AC280.1000608@daniel.thecshore.com> <572B5C05.8080306@daniel.thecshore.com> <572B62B5.4000602@gmail.com> <572B6D9A.6030606@daniel.thecshore.com> <572B73A9.9070909@daniel.thecshore.com> <572B74EF.6020805@daniel.thecshore.com> Message-ID: On 5 May 2016 at 19:29, Daniel Dickinson wrote: > On 16-05-05 12:24 PM, Daniel Dickinson wrote: >> On 16-05-05 12:21 PM, Jonathan Bennett wrote: >> [snip] >>> > The changes that the Lede guys are suggesting would be welcome, but >>> > splitting the project and community with an ugly fork is very much not >>> > welcome. >>> >>> Let's just say that there are strong personalities who haven't been >>> working well together and that this has been a long time coming; perhaps >>> if something like using a mediator had been considered before things got >>> to this point it would have helped. At this point I'm not sure >>> there is a >>> solution unless both sides are willing to bend a little (I'm really not >>> sure who has been flexible and who has not, but as I have said I suspect >>> a large part of the issue is that 'management' (who aren't and don't, >>> really) has overruled those doing the majority of the work and in an >>> open source project that doesn't fly). >>> >>> I don't disagree. I just see the current state of Openwrt/Lede as a >>> mess for the community. >> >> I agree, I just don't see how the LEDE team could have avoided it >> without giving up and accepting the broken status quo. > > When I say broken I mean I think openwrt was dying and I pointed out not > all that long ago that openwrt was in bad position and that something > needed to change, and I think that may have been *part* of the reason > accepting the status quo was no longer an acceptable answer. I don't believe that those who are in LEDE now couldn't do anything (that means is was dying in their hands). Actually I'm still under impression that they controlled pretty much everything. And the part they didn't control (what exactly?) was only important to them. But I guess we will never know full story, unless both parties are willing to disclose all their private conversations related to project. Regards, Roman _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Thu May 5 13:09:14 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Thu, 5 May 2016 13:09:14 -0400 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: References: <572A5501.3040807@openwrt.org> <572AC280.1000608@daniel.thecshore.com> <572B5C05.8080306@daniel.thecshore.com> <572B62B5.4000602@gmail.com> <572B6D9A.6030606@daniel.thecshore.com> <572B73A9.9070909@daniel.thecshore.com> <572B74EF.6020805@daniel.thecshore.com> Message-ID: <572B7E3A.8010706@daniel.thecshore.com> On 16-05-05 12:59 PM, Roman Yeryomin wrote: > On 5 May 2016 at 19:29, Daniel Dickinson wrote: >> On 16-05-05 12:24 PM, Daniel Dickinson wrote: >>> On 16-05-05 12:21 PM, Jonathan Bennett wrote: >>> [snip] [snip] >> When I say broken I mean I think openwrt was dying and I pointed out not >> all that long ago that openwrt was in bad position and that something >> needed to change, and I think that may have been *part* of the reason >> accepting the status quo was no longer an acceptable answer. > > I don't believe that those who are in LEDE now couldn't do anything > (that means is was dying in their hands). Actually I'm still under I guess the real test will be what happens going forward - if LEDE dies for the same reasons OpenWrt was dying then that puts paid to LEDE's story; it it succeeds then it vindicates them. > impression that they controlled pretty much everything. And the part > they didn't control (what exactly?) was only important to them. I have no clue about this part, I'm not exactly in the loop. I think part of the problem has been that there is no means to add new developers, and that suggestions for adding developers have been opposed (that's a guess though). > But I guess we will never know full story, unless both parties are > willing to disclose all their private conversations related to > project. Yeah, pretty much we're left guessing unless there is more information given. I'm thinking the LEDE split was not like a conspiratorial split where everything is carefully planned out and orchestrated, but more of a rapid response (given that this isn't part of paid work for the most of them, and even then the LEDE split wouldn't likely be part of the job/contract) to something behind the scenes. Even if the LEDE team is unable to post to this list, I hope they give more information using the avenues available to them, once they get the chance to do so. Regards, Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From leroi.lists at gmail.com Thu May 5 13:49:13 2016 From: leroi.lists at gmail.com (Roman Yeryomin) Date: Thu, 5 May 2016 20:49:13 +0300 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <572B7E3A.8010706@daniel.thecshore.com> References: <572A5501.3040807@openwrt.org> <572AC280.1000608@daniel.thecshore.com> <572B5C05.8080306@daniel.thecshore.com> <572B62B5.4000602@gmail.com> <572B6D9A.6030606@daniel.thecshore.com> <572B73A9.9070909@daniel.thecshore.com> <572B74EF.6020805@daniel.thecshore.com> <572B7E3A.8010706@daniel.thecshore.com> Message-ID: On 5 May 2016 at 20:09, Daniel Dickinson wrote: > On 16-05-05 12:59 PM, Roman Yeryomin wrote: >> On 5 May 2016 at 19:29, Daniel Dickinson wrote: >>> On 16-05-05 12:24 PM, Daniel Dickinson wrote: >>>> On 16-05-05 12:21 PM, Jonathan Bennett wrote: >>>> [snip] > [snip] >>> When I say broken I mean I think openwrt was dying and I pointed out not >>> all that long ago that openwrt was in bad position and that something >>> needed to change, and I think that may have been *part* of the reason >>> accepting the status quo was no longer an acceptable answer. >> >> I don't believe that those who are in LEDE now couldn't do anything >> (that means is was dying in their hands). Actually I'm still under > > I guess the real test will be what happens going forward - if LEDE dies > for the same reasons OpenWrt was dying then that puts paid to LEDE's > story; it it succeeds then it vindicates them. I hope the problems will be resolved and we will have one project. >> impression that they controlled pretty much everything. And the part >> they didn't control (what exactly?) was only important to them. > > I have no clue about this part, I'm not exactly in the loop. I think > part of the problem has been that there is no means to add new > developers, and that suggestions for adding developers have been opposed > (that's a guess though). I don't think it was opposed. And I don't think it was a major problem. >> But I guess we will never know full story, unless both parties are >> willing to disclose all their private conversations related to >> project. > > Yeah, pretty much we're left guessing unless there is more information > given. I'm thinking the LEDE split was not like a conspiratorial split > where everything is carefully planned out and orchestrated, but more of > a rapid response (given that this isn't part of paid work for the most > of them, and even then the LEDE split wouldn't likely be part of the > job/contract) to something behind the scenes. Even if the LEDE team is > unable to post to this list, I hope they give more information using the > avenues available to them, once they get the chance to do so. Look at mailing list, commits and domain. It was all started back in March and was not disclosed. That means the plans were even earlier. Regards, Roman _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Thu May 5 14:25:01 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Thu, 5 May 2016 14:25:01 -0400 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: References: <572A5501.3040807@openwrt.org> <572AC280.1000608@daniel.thecshore.com> <572B5C05.8080306@daniel.thecshore.com> <572B62B5.4000602@gmail.com> <572B6D9A.6030606@daniel.thecshore.com> <572B73A9.9070909@daniel.thecshore.com> <572B74EF.6020805@daniel.thecshore.com> <572B7E3A.8010706@daniel.thecshore.com> Message-ID: <572B8FFD.5070100@daniel.thecshore.com> On 16-05-05 01:49 PM, Roman Yeryomin wrote: > On 5 May 2016 at 20:09, Daniel Dickinson wrote: >> On 16-05-05 12:59 PM, Roman Yeryomin wrote: >>> On 5 May 2016 at 19:29, Daniel Dickinson wrote: >>>> On 16-05-05 12:24 PM, Daniel Dickinson wrote: >>>>> On 16-05-05 12:21 PM, Jonathan Bennett wrote: >>>>> [snip] >> [snip] >>>> When I say broken I mean I think openwrt was dying and I pointed out not >>>> all that long ago that openwrt was in bad position and that something >>>> needed to change, and I think that may have been *part* of the reason >>>> accepting the status quo was no longer an acceptable answer. >>> >>> I don't believe that those who are in LEDE now couldn't do anything >>> (that means is was dying in their hands). Actually I'm still under >> >> I guess the real test will be what happens going forward - if LEDE dies >> for the same reasons OpenWrt was dying then that puts paid to LEDE's >> story; it it succeeds then it vindicates them. > > I hope the problems will be resolved and we will have one project. That would be ideal, but I am doubtful, unless part(y|ies) involved have a major change of heart. > >>> impression that they controlled pretty much everything. And the part >>> they didn't control (what exactly?) was only important to them. >> >> I have no clue about this part, I'm not exactly in the loop. I think >> part of the problem has been that there is no means to add new >> developers, and that suggestions for adding developers have been opposed >> (that's a guess though). > > I don't think it was opposed. And I don't think it was a major problem. You sound like you know more than I about this. It was a guess. Only actual information will really answer the question. >>> But I guess we will never know full story, unless both parties are >>> willing to disclose all their private conversations related to >>> project. >> >> Yeah, pretty much we're left guessing unless there is more information >> given. I'm thinking the LEDE split was not like a conspiratorial split >> where everything is carefully planned out and orchestrated, but more of >> a rapid response (given that this isn't part of paid work for the most >> of them, and even then the LEDE split wouldn't likely be part of the >> job/contract) to something behind the scenes. Even if the LEDE team is >> unable to post to this list, I hope they give more information using the >> avenues available to them, once they get the chance to do so. > > Look at mailing list, commits and domain. > It was all started back in March and was not disclosed. That means the > plans were even earlier. Based on https://lede-project.org/wp-org at wwsnet.net.mbox it was merely an idea until early March, and again, to me indicates that things going on in the OpenWrt project that pushed the LEDE team to the breaking point, and which, contrary to Mike's email, were not being addressed (as Felix pointed out in his response, which I'm not sure if was accepted on this list, although it was in the To:). Regards, Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From daniel at makrotopia.org Thu May 5 15:08:10 2016 From: daniel at makrotopia.org (Daniel Golle) Date: Thu, 5 May 2016 20:08:10 +0100 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <572B8FFD.5070100@daniel.thecshore.com> References: <572B62B5.4000602@gmail.com> <572B6D9A.6030606@daniel.thecshore.com> <572B73A9.9070909@daniel.thecshore.com> <572B74EF.6020805@daniel.thecshore.com> <572B7E3A.8010706@daniel.thecshore.com> <572B8FFD.5070100@daniel.thecshore.com> Message-ID: <20160505190809.GA5168@makrotopia.org> Hi Daniel, I already merged lynxis series now that I see your comment. If you feel like it, it'd be nice if you point out the remaining places where the name needs to be replaced and submit (a) patch(es). Cheers Daniel On Thu, May 05, 2016 at 02:03:43PM -0400, Daniel Dickinson wrote: > If you're interested, I can send you examples of a full rebrand patchset > (there are *quite* a few places to change, and this patchset doesn't get > them all) which I used in a "Don't blame OpenWrt" patchset I created > when I forked (although never publicly announced as wasn't entirely > convinced of the worth, and it wasn't ready). > > Regards, > > Daniel > > On 16-05-05 01:33 PM, Alexander Couzens wrote: > > Signed-off-by: Alexander Couzens > > --- > > target/imagebuilder/Config.in | 2 +- > > target/imagebuilder/files/repositories.conf | 2 +- > > 2 files changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/target/imagebuilder/Config.in b/target/imagebuilder/Config.in > > index 1bc4533..245c715 100644 > > --- a/target/imagebuilder/Config.in > > +++ b/target/imagebuilder/Config.in > > @@ -1,5 +1,5 @@ > > config IB > > - bool "Build the OpenWrt Image Builder" > > + bool "Build the LEDE Image Builder" > > depends on !PROFILE_KCONFIG > > depends on !EXTERNAL_TOOLCHAIN > > help > > diff --git a/target/imagebuilder/files/repositories.conf b/target/imagebuilder/files/repositories.conf > > index 8f1f27f..93ed97b 100644 > > --- a/target/imagebuilder/files/repositories.conf > > +++ b/target/imagebuilder/files/repositories.conf > > @@ -1,4 +1,4 @@ > > ## Place your custom repositories here, they must match the architecture and version. > > # src/gz %n %U > > -# src custom file:///usr/src/openwrt/bin/%T/packages > > +# src custom file:///usr/src/lede/bin/%T/packages > > > > > > _______________________________________________ > Lede-dev mailing list > Lede-dev at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From mbm at openwrt.org Thu May 5 15:22:29 2016 From: mbm at openwrt.org (mbm) Date: Thu, 5 May 2016 12:22:29 -0700 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <572B5B6F.7080203@nbd.name> References: <572A5501.3040807@openwrt.org> <572B5B6F.7080203@nbd.name> Message-ID: <572B9D75.9010205@openwrt.org> On 5/5/2016 7:40 AM, Felix Fietkau wrote: > Many of the changes that we previously tried to introduce were often > squashed by internal disagreements. Resulting discussions often turned > toxic quickly and led to nothing being done to address the issues. > Setting up the LEDE project was our way of creating a testbed for > changes that we believe are important for the survival of the project. Change is not easy. Discussions need to happen. The problem is simply kicking out people you didn't agree with by starting a new organization in secret; you've created the public perception that we're somehow against you when really we all want the same things. > A critical part of many of these debates was the fact that people who > were controlling critical pieces of the infrastructure flat out > refused to allow other people to step up and help, even in the face of > being unable to deal with important issues themselves in a timely > manner. This kind of single-point-of-failure thing has been going on > for years, with no significant progress on resolving it. In the LEDE > project we decided to significantly simplify the infrastructure and > spread out admin access enough to minimize the chance of this > situation ever happening again. > While we have pushed for and actively worked on decentralizing the > infrastructure, we were also frequently asked to move back to > centralizing things again. > The excessive downtime of the main site this year is a good example of > why we definitely don't want to go that way. I'll let Kaloz address this personally. > Do you think we can get the changes outlined by the LEDE project > implement in OpenWrt? If so, how? We can start by having an actual conversation between the two groups. I'm not against what LEDE was trying to accomplish, but I am against how it was done. > We appreciate your effort to have an open discussion about this, > however the sudden deletion of our widely published openwrt.org email > addresses somewhat undermines this. We will not respond in kind and we > will continue to maintain the critical parts of OpenWrt infrastructure > that we control. Let's be clear on this subject; no commit access was revoked, you still have full read and write access to the entire OpenWrt tree. Email forwarding was temporarily disabled following the LEDE announcement - LEDE's own rules prohibit project based email addresses - It's unclear if LEDE still represents OpenWrt My hope is that this whole LEDE vs OpenWrt situation can be resolved. _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From david at lang.hm Thu May 5 15:25:33 2016 From: david at lang.hm (David Lang) Date: Thu, 5 May 2016 12:25:33 -0700 (PDT) Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: References: <5179f6d1-283a-1b40-d717-2730c3408326@openwrt.org> <572A6C67.3040701@daniel.thecshore.com> <572A8E35.8090604@daniel.thecshore.com> <572B2F66.70003@einfach.org> Message-ID: On Thu, 5 May 2016, Carlos Ferreira wrote: > I don't see the end of OpenWRT as a bad thing. > If LEDE is basically a fork but without the development bottlenecks that > seem to be affecting OpenwRT, then the change can be easily done by the > industry segment that uses OpenWRT for their products. In fact, I see it as > a good thing because it means that there are developers who care about the > future of such embedded development environment. The loss of brand recognition is a bad thing (see LibreOffice vs OpenOffice for example) but that said, this doesn't have to be permanent (see egcs vs gcc for example) David Lang -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Thu May 5 16:08:37 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Thu, 5 May 2016 16:08:37 -0400 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <572B9D75.9010205@openwrt.org> References: <572A5501.3040807@openwrt.org> <572B5B6F.7080203@nbd.name> <572B9D75.9010205@openwrt.org> Message-ID: <572BA845.2010001@daniel.thecshore.com> Might I submit that my impression is that Kaloz (at least) holds infrastructure hostage to maintain control, and that the fundamental problem here is that OpenWrt is *not* democratic and ignores what people who were ones visibly working on openwrt want and overrides their wishes because he/they has/have the keys. That doesn't work. Perhaps I'm wrong, but that is certainly my impression. There isn't management for openwrt except by democratic/meritocratic principles, and no one should try to force it to be otherwise. Regards, Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From mschiffer at universe-factory.net Thu May 5 16:17:13 2016 From: mschiffer at universe-factory.net (Matthias Schiffer) Date: Thu, 5 May 2016 22:17:13 +0200 Subject: [OpenWrt-Devel] [PATCH netifd] device: Don't process link events anymore in device user specific callback handlers In-Reply-To: <1446459372-19588-3-git-send-email-dedeckeh@gmail.com> References: <1446459372-19588-1-git-send-email-dedeckeh@gmail.com> <1446459372-19588-3-git-send-email-dedeckeh@gmail.com> Message-ID: <9e55f07d-23d9-a524-85f6-3963b437a749@universe-factory.net> On 11/02/2015 11:16 AM, Hans Dedecker wrote: > Set link_state for all device types via the device_set_link API as all devices are registered > in the device tree list making it possible to always get the device via device_get. > The decice link state parameter will now actually reflect the corresponding kernel device > carrier state in all cases. > Before this change a vlan/macvlan device could still have link_state enabled if an interface > was brought down; this was the case when the parent vlan/macvlan device was still enabled as > the netlink link_state event would be dropped for vlan/macvlan devices due to keep_link_state > in the function cb_rtnl_event. > > Signed-off-by: Hans Dedecker > --- This patch breaks the following setup: I have a WLAN device, and on top of it a VLAN device which uses a shell proto. Example: config interface 'test' option proto 'static' option ipaddr '192.168.2.1' option netmask '255.255.255.0' config interface 'test2' option ifname '@test.1' option proto 'dhcp' where 'test' is referenced by a wifi-iface. In this setup, wlan0.1 is created, but the DHCP client never comes up (other shell protos yield the same result). If I revert this patch, or change @test.1 to wlan0.1, everything works fine. Regards, Matthias -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Thu May 5 16:24:07 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Thu, 5 May 2016 16:24:07 -0400 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <572B9D75.9010205@openwrt.org> References: <572A5501.3040807@openwrt.org> <572B5B6F.7080203@nbd.name> <572B9D75.9010205@openwrt.org> Message-ID: <572BABE7.8080405@daniel.thecshore.com> On 16-05-05 03:22 PM, mbm wrote: > On 5/5/2016 7:40 AM, Felix Fietkau wrote: >> Many of the changes that we previously tried to introduce were often >> squashed by internal disagreements. Resulting discussions often turned >> toxic quickly and led to nothing being done to address the issues. >> Setting up the LEDE project was our way of creating a testbed for >> changes that we believe are important for the survival of the project. > > Change is not easy. Discussions need to happen. The problem is simply > kicking out people you didn't agree with by starting a new organization That depends - is 'people you don't agree with' a majority that is being sidelined by a new organization or a minority trying dictate to the majority? Regards, Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From nbd at nbd.name Thu May 5 16:43:54 2016 From: nbd at nbd.name (Felix Fietkau) Date: Thu, 5 May 2016 21:43:54 +0100 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <572B9D75.9010205@openwrt.org> References: <572A5501.3040807@openwrt.org> <572B5B6F.7080203@nbd.name> <572B9D75.9010205@openwrt.org> Message-ID: <572BB08A.90704@nbd.name> On 2016-05-05 20:22, mbm wrote: > On 5/5/2016 7:40 AM, Felix Fietkau wrote: >> Many of the changes that we previously tried to introduce were often >> squashed by internal disagreements. Resulting discussions often turned >> toxic quickly and led to nothing being done to address the issues. >> Setting up the LEDE project was our way of creating a testbed for >> changes that we believe are important for the survival of the project. > > Change is not easy. Discussions need to happen. The problem is simply > kicking out people you didn't agree with by starting a new organization > in secret; you've created the public perception that we're somehow > against you when really we all want the same things. Years of internal discussion led nowhere. Maybe it helps now that we're making the whole issue public. >> We appreciate your effort to have an open discussion about this, >> however the sudden deletion of our widely published openwrt.org email >> addresses somewhat undermines this. We will not respond in kind and we >> will continue to maintain the critical parts of OpenWrt infrastructure >> that we control. > > Let's be clear on this subject; no commit access was revoked, you still > have full read and write access to the entire OpenWrt tree. > > Email forwarding was temporarily disabled following the LEDE announcement > - LEDE's own rules prohibit project based email addresses No, they don't. They state that the LEDE project won't provide project email addresses. Interpreting that as meaning that we shouldn't be able to access our openwrt.org addresses is more than a bit of a stretch. > - It's unclear if LEDE still represents OpenWrt So? Asking us to not send any further emails about LEDE from our openwrt.org addresses should have been enough. > My hope is that this whole LEDE vs OpenWrt situation can be resolved. I hope so too. - Felix _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From knaack.h at gmx.de Thu May 5 19:04:01 2016 From: knaack.h at gmx.de (Hartmut Knaack) Date: Fri, 6 May 2016 01:04:01 +0200 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <572B9D75.9010205@openwrt.org> References: <572A5501.3040807@openwrt.org> <572B5B6F.7080203@nbd.name> <572B9D75.9010205@openwrt.org> Message-ID: <572BD161.7020107@gmx.de> mbm schrieb am 05.05.2016 um 21:22: > On 5/5/2016 7:40 AM, Felix Fietkau wrote: >> Many of the changes that we previously tried to introduce were often >> squashed by internal disagreements. Resulting discussions often turned >> toxic quickly and led to nothing being done to address the issues. >> Setting up the LEDE project was our way of creating a testbed for >> changes that we believe are important for the survival of the project. > > Change is not easy. Discussions need to happen. The problem is simply > kicking out people you didn't agree with by starting a new organization > in secret; you've created the public perception that we're somehow > against you when really we all want the same things. > >> A critical part of many of these debates was the fact that people who >> were controlling critical pieces of the infrastructure flat out >> refused to allow other people to step up and help, even in the face of >> being unable to deal with important issues themselves in a timely >> manner. This kind of single-point-of-failure thing has been going on >> for years, with no significant progress on resolving it. In the LEDE >> project we decided to significantly simplify the infrastructure and >> spread out admin access enough to minimize the chance of this >> situation ever happening again. >> While we have pushed for and actively worked on decentralizing the >> infrastructure, we were also frequently asked to move back to >> centralizing things again. >> The excessive downtime of the main site this year is a good example of >> why we definitely don't want to go that way. > > I'll let Kaloz address this personally. > >> Do you think we can get the changes outlined by the LEDE project >> implement in OpenWrt? If so, how? > > We can start by having an actual conversation between the two groups. > I'm not against what LEDE was trying to accomplish, but I am against how > it was done. > >> We appreciate your effort to have an open discussion about this, >> however the sudden deletion of our widely published openwrt.org email >> addresses somewhat undermines this. We will not respond in kind and we >> will continue to maintain the critical parts of OpenWrt infrastructure >> that we control. > > Let's be clear on this subject; no commit access was revoked, you still > have full read and write access to the entire OpenWrt tree. > > Email forwarding was temporarily disabled following the LEDE announcement > - LEDE's own rules prohibit project based email addresses > - It's unclear if LEDE still represents OpenWrt > Disabling someone's email-account without prior notice and a decent time frame just because you don't agree with that persons behavior is totally immature and inappropriate. The 'excuse' pointed out here just demonstrates this ridiculousness. Just my 2 cents. Hartmut > My hope is that this whole LEDE vs OpenWrt situation can be resolved. > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xFAC89148.asc Type: application/pgp-keys Size: 3104 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From andrej.vlasic at sartura.hr Thu May 5 20:04:27 2016 From: andrej.vlasic at sartura.hr (Andrej Vlasic) Date: Fri, 6 May 2016 00:04:27 +0000 Subject: [OpenWrt-Devel] [PATCH v4 1/4] mvebu: add squashfs image type to MMCProfile In-Reply-To: <1462389868-18371-1-git-send-email-josua.mayer97@gmail.com> References: <1462389868-18371-1-git-send-email-josua.mayer97@gmail.com> Message-ID: <010001548361368b-b6dcbdda-12e9-4999-8a4a-754cf736e8bf-000000@email.amazonses.com> Hi Josua, On 04.05.2016 21:24, josua.mayer97 at gmail.com wrote: > From: Josua Mayer > > Added gen_mvebu_sdcard_img.sh to create bootable sdcard images. It takes > the bootloader and partition images to create a bootable sdcard image. > > Partition Layout: > p1: fat32: for kernel, dtb and boot config files if any > p2: squashfs: for openwrt > > This change is developed for the Clearfog, but should work on all A38x > SoCs that can boot from mmc. > > Signed-off-by: Josua Mayer > --- > target/linux/mvebu/image/Makefile | 16 ++++ > target/linux/mvebu/image/gen_mvebu_sdcard_img.sh | 100 +++++++++++++++++++++++ > tools/Makefile | 1 + > 3 files changed, 117 insertions(+) > create mode 100755 target/linux/mvebu/image/gen_mvebu_sdcard_img.sh > > diff --git a/target/linux/mvebu/image/Makefile b/target/linux/mvebu/image/Makefile > index cb73c3b..fc5fded 100644 > --- a/target/linux/mvebu/image/Makefile > +++ b/target/linux/mvebu/image/Makefile > @@ -107,6 +107,9 @@ define MMCProfile > ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),) > $(call Image/Build/Profile,$(1)/Initramfs) > endif > + ifneq ($(CONFIG_TARGET_ROOTFS_SQUASHFS),) > + $(call Image/Build/squashfs) > + endif > endef > > define Image/Build/Profile/$(1)/Initramfs > @@ -114,6 +117,19 @@ define MMCProfile > cp $(KDIR)/uImage-initramfs-$(2) $(BIN_DIR)/$(IMG_PREFIX)-$(2)-initramfs > endef > > + define Image/Build/Profile/$(1)/squashfs > + $(call prepare_generic_squashfs,$(KDIR)/root.squashfs) > + cp $(KDIR)/root.squashfs $(BIN_DIR)/$(IMG_PREFIX)-$(2)-root.squashfs > + rm -f $(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32 > + mkfs.fat -C $(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32 $(shell echo $$((4*1024)) # 4MB) > + mcopy -i $(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32 $(KDIR)/zImage :: > + mcopy -i $(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32 $(DTS_DIR)/$(2).dtb :: > + ./gen_mvebu_sdcard_img.sh "$(BIN_DIR)/$(IMG_PREFIX)-$(2)-squashfs-sdcard.img" \ > + "$(BIN_DIR)/uboot-mvebu-clearfog/openwrt-mvebu-clearfog-u-boot-spl.kwb" \ > + c "$(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32" \ > + 83 "$(BIN_DIR)/$(IMG_PREFIX)-$(2)-root.squashfs" > + endef > + Image generation script here requires u-boot binary to exist, but what if one doesn't select u-boot to be generated? It would be better to exclude it from generated sdcard image, it can be flashed anyway with dd to beginning of the sd card. Also one ext4 partition for boot and second one for rootfs would be better than fat32 + squashfs on sdcard, both Marvell u-boot and uboot-mvebu have support for loading kernel from ext4. > PROFILES_LIST += $(1) > endef > > diff --git a/target/linux/mvebu/image/gen_mvebu_sdcard_img.sh b/target/linux/mvebu/image/gen_mvebu_sdcard_img.sh > new file mode 100755 > index 0000000..88d017a > --- /dev/null > +++ b/target/linux/mvebu/image/gen_mvebu_sdcard_img.sh > @@ -0,0 +1,100 @@ > +#!/bin/bash -x > +# > +# Copyright (C) 2016 Josua Mayer > +# > +# 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., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. > +# > + > +usage() { > + echo "$0 [ ]?" > +} > + > +# always require first 2 arguments > +# then in pairs up to 8 more for a total of up to 4 partitions > +if [ $# -lt 2 ] || [ $# -gt 10 ] || [ $((($#-2)%2)) -ne 0 ]; then > + usage > + exit 1 > +fi > + > +# static settings > +SDCARD_HEADS=16 > +SDCARD_SECTORS=63 > +SDCARD_ALIGNMENT=4096 > + > +# parameters > +OUTFILE="$1" > +BOOTLOADER="$2" > +# up to 4 partitions > +# when calculating size of images in Kilobytes, NEVER round down! > +PART1_TYPE=$3 > +PART1_IMG="$4" > +PART1_SIZE=$((($(stat --print="%s" "$PART1_IMG")+1023)/1024))K > +PART2_TYPE=$5 > +PART2_IMG="$6" > +PART2_SIZE=$((($(stat --print="%s" "$PART2_IMG")+1023)/1024))K > +PART3_TYPE=$7 > +PART3_IMG="$8" > +PART3_SIZE=$((($(stat --print="%s" "$PART3_IMG")+1023)/1024))K > +PART4_TYPE=$9 > +PART4_IMG="${10}" > +PART4_SIZE=$((($(stat --print="%s" "$PART4_IMG")+1023)/1024))K > + > +# So how many partitions were given? > +numparts=$((($#-2)/2)) > +case $numparts in > + 0) > + set `ptgen -o "$OUTFILE" \ > + -h $SDCARD_HEADS -s $SDCARD_SECTORS -l $SDCARD_ALIGNMENT` > + dd of="$OUTFILE" if="$BOOTLOADER" bs=512 seek=1 conv=notrunc > + ;; > + 1) > + set `ptgen -o "$OUTFILE" \ > + -h $SDCARD_HEADS -s $SDCARD_SECTORS -l $SDCARD_ALIGNMENT \ > + -t $PART1_TYPE -p $PART1_SIZE` > + dd of="$OUTFILE" if="$PART1_IMG" bs=512 seek=$(($1/512)) conv=notrunc > + ;; > + 2) > + set `ptgen -o "$OUTFILE" \ > + -h $SDCARD_HEADS -s $SDCARD_SECTORS -l $SDCARD_ALIGNMENT \ > + -t $PART1_TYPE -p $PART1_SIZE \ > + -t $PART2_TYPE -p $PART2_SIZE` > + dd of="$OUTFILE" if="$BOOTLOADER" bs=512 seek=1 conv=notrunc > + dd of="$OUTFILE" if="$PART1_IMG" bs=512 seek=$(($1/512)) conv=notrunc > + dd of="$OUTFILE" if="$PART2_IMG" bs=512 seek=$(($2/512)) conv=notrunc > + ;; > + 3) > + set `ptgen -o "$OUTFILE" \ > + -h $SDCARD_HEADS -s $SDCARD_SECTORS -l $SDCARD_ALIGNMENT \ > + -t $PART1_TYPE -p $PART1_SIZE \ > + -t $PART2_TYPE -p $PART2_SIZE \ > + -t $PART3_TYPE -p $PART3_SIZE` > + dd of="$OUTFILE" if="$BOOTLOADER" bs=512 seek=1 conv=notrunc > + dd of="$OUTFILE" if="$PART1_IMG" bs=512 seek=$(($1/512)) conv=notrunc > + dd of="$OUTFILE" if="$PART2_IMG" bs=512 seek=$(($2/512)) conv=notrunc > + dd of="$OUTFILE" if="$PART3_IMG" bs=512 seek=$(($3/512)) conv=notrunc > + ;; > + 4) > + set `ptgen -o "$OUTFILE" \ > + -h $SDCARD_HEADS -s $SDCARD_SECTORS -l $SDCARD_ALIGNMENT \ > + -t $PART1_TYPE -p $PART1_SIZE \ > + -t $PART2_TYPE -p $PART2_SIZE \ > + -t $PART3_TYPE -p $PART3_SIZE \ > + -t $PART4_TYPE -p $PART4_SIZE` > + dd of="$OUTFILE" if="$BOOTLOADER" bs=512 seek=1 conv=notrunc > + dd of="$OUTFILE" if="$PART1_IMG" bs=512 seek=$(($1/512)) conv=notrunc > + dd of="$OUTFILE" if="$PART2_IMG" bs=512 seek=$(($2/512)) conv=notrunc > + dd of="$OUTFILE" if="$PART3_IMG" bs=512 seek=$(($3/512)) conv=notrunc > + dd of="$OUTFILE" if="$PART4_IMG" bs=512 seek=$(($4/512)) conv=notrunc > +esac > diff --git a/tools/Makefile b/tools/Makefile > index 187655e..9a08573 100644 > --- a/tools/Makefile > +++ b/tools/Makefile > @@ -38,6 +38,7 @@ tools-$(CONFIG_TARGET_x86) += qemu > tools-$(CONFIG_TARGET_mxs) += elftosb sdimage > tools-$(CONFIG_TARGET_brcm2708)$(CONFIG_TARGET_sunxi)$(CONFIG_TARGET_mxs) += mtools dosfstools > tools-$(CONFIG_TARGET_ar71xx) += lzma-old squashfs > +tools-$(CONFIG_TARGET_mvebu) += squashfs dosfstools > tools-y += lzma squashfs4 > tools-$(BUILD_B43_TOOLS) += b43-tools > tools-$(BUILD_PPL_CLOOG) += ppl cloog > _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From josua.mayer97 at gmail.com Thu May 5 20:15:37 2016 From: josua.mayer97 at gmail.com (Josua Mayer) Date: Fri, 6 May 2016 02:15:37 +0200 Subject: [OpenWrt-Devel] [PATCH v4 1/4] mvebu: add squashfs image type to MMCProfile In-Reply-To: <010001548361368b-b6dcbdda-12e9-4999-8a4a-754cf736e8bf-000000@email.amazonses.com> References: <1462389868-18371-1-git-send-email-josua.mayer97@gmail.com> <010001548361368b-b6dcbdda-12e9-4999-8a4a-754cf736e8bf-000000@email.amazonses.com> Message-ID: <572BE229.7080102@gmail.com> Hi Andrej, First let me thank you for taking the time to review my proposals! Am 06.05.2016 um 02:04 schrieb Andrej Vlasic: > Hi Josua, > > On 04.05.2016 21:24, josua.mayer97 at gmail.com wrote: >> From: Josua Mayer >> >> Added gen_mvebu_sdcard_img.sh to create bootable sdcard images. It takes >> the bootloader and partition images to create a bootable sdcard image. >> >> Partition Layout: >> p1: fat32: for kernel, dtb and boot config files if any >> p2: squashfs: for openwrt >> >> This change is developed for the Clearfog, but should work on all A38x >> SoCs that can boot from mmc. >> >> Signed-off-by: Josua Mayer >> --- >> target/linux/mvebu/image/Makefile | 16 ++++ >> target/linux/mvebu/image/gen_mvebu_sdcard_img.sh | 100 >> +++++++++++++++++++++++ >> tools/Makefile | 1 + >> 3 files changed, 117 insertions(+) >> create mode 100755 target/linux/mvebu/image/gen_mvebu_sdcard_img.sh >> >> diff --git a/target/linux/mvebu/image/Makefile >> b/target/linux/mvebu/image/Makefile >> index cb73c3b..fc5fded 100644 >> --- a/target/linux/mvebu/image/Makefile >> +++ b/target/linux/mvebu/image/Makefile >> @@ -107,6 +107,9 @@ define MMCProfile >> ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),) >> $(call Image/Build/Profile,$(1)/Initramfs) >> endif >> + ifneq ($(CONFIG_TARGET_ROOTFS_SQUASHFS),) >> + $(call Image/Build/squashfs) >> + endif >> endef >> >> define Image/Build/Profile/$(1)/Initramfs >> @@ -114,6 +117,19 @@ define MMCProfile >> cp $(KDIR)/uImage-initramfs-$(2) >> $(BIN_DIR)/$(IMG_PREFIX)-$(2)-initramfs >> endef >> >> + define Image/Build/Profile/$(1)/squashfs >> + $(call prepare_generic_squashfs,$(KDIR)/root.squashfs) >> + cp $(KDIR)/root.squashfs $(BIN_DIR)/$(IMG_PREFIX)-$(2)-root.squashfs >> + rm -f $(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32 >> + mkfs.fat -C $(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32 $(shell echo >> $$((4*1024)) # 4MB) >> + mcopy -i $(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32 $(KDIR)/zImage :: >> + mcopy -i $(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32 >> $(DTS_DIR)/$(2).dtb :: >> + ./gen_mvebu_sdcard_img.sh >> "$(BIN_DIR)/$(IMG_PREFIX)-$(2)-squashfs-sdcard.img" \ >> + >> "$(BIN_DIR)/uboot-mvebu-clearfog/openwrt-mvebu-clearfog-u-boot-spl.kwb" \ >> + c "$(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32" \ >> + 83 "$(BIN_DIR)/$(IMG_PREFIX)-$(2)-root.squashfs" >> + endef >> + > > Image generation script here requires u-boot binary to exist, but what > if one doesn't select u-boot to be generated? It would be better to That would certainly be a problem. > exclude it from generated sdcard image, it can be flashed anyway with dd > to beginning of the sd card. While I agree that this would work, it does not give the one-click solution I would like to build. Why burden people with using dd to flash u-boot to some magic offset on sdcard? Maybe we can add u-boot as a dependency so it is always built when clearfog is selected? > > Also one ext4 partition for boot and second one for rootfs would be > better than fat32 + squashfs on sdcard, both Marvell u-boot and > uboot-mvebu have support for loading kernel from ext4. Very interesting you would argue on this part! So I will just outline the reasons why I made this choice: 1) fat32 make it easier to edit boot files for Windows users too. I think this will be very useful when somebody wants to supply bootargs or try a different kernel, but is not familiar with using unix. 2) squashfs I like the read-only nature of squashfs. What I am working towards is a system that feels like just any router out there. Factory wiping involves just clearing the read-write part of storage, while firmware updates replace the read-only parts. If anyone messes up, they can just mkfs.ext4, or rm -rf * on the data partition. Please let me know if you agree or disagree here. > >> PROFILES_LIST += $(1) >> endef >> >> diff --git a/target/linux/mvebu/image/gen_mvebu_sdcard_img.sh >> b/target/linux/mvebu/image/gen_mvebu_sdcard_img.sh >> new file mode 100755 >> index 0000000..88d017a >> --- /dev/null >> +++ b/target/linux/mvebu/image/gen_mvebu_sdcard_img.sh >> @@ -0,0 +1,100 @@ >> +#!/bin/bash -x >> +# >> +# Copyright (C) 2016 Josua Mayer >> +# >> +# 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., 51 Franklin Street, Fifth Floor, Boston, MA >> 02110-1301, USA. >> +# >> + >> +usage() { >> + echo "$0 [ >> ]?" >> +} >> + >> +# always require first 2 arguments >> +# then in pairs up to 8 more for a total of up to 4 partitions >> +if [ $# -lt 2 ] || [ $# -gt 10 ] || [ $((($#-2)%2)) -ne 0 ]; then >> + usage >> + exit 1 >> +fi >> + >> +# static settings >> +SDCARD_HEADS=16 >> +SDCARD_SECTORS=63 >> +SDCARD_ALIGNMENT=4096 >> + >> +# parameters >> +OUTFILE="$1" >> +BOOTLOADER="$2" >> +# up to 4 partitions >> +# when calculating size of images in Kilobytes, NEVER round down! >> +PART1_TYPE=$3 >> +PART1_IMG="$4" >> +PART1_SIZE=$((($(stat --print="%s" "$PART1_IMG")+1023)/1024))K >> +PART2_TYPE=$5 >> +PART2_IMG="$6" >> +PART2_SIZE=$((($(stat --print="%s" "$PART2_IMG")+1023)/1024))K >> +PART3_TYPE=$7 >> +PART3_IMG="$8" >> +PART3_SIZE=$((($(stat --print="%s" "$PART3_IMG")+1023)/1024))K >> +PART4_TYPE=$9 >> +PART4_IMG="${10}" >> +PART4_SIZE=$((($(stat --print="%s" "$PART4_IMG")+1023)/1024))K >> + >> +# So how many partitions were given? >> +numparts=$((($#-2)/2)) >> +case $numparts in >> + 0) >> + set `ptgen -o "$OUTFILE" \ >> + -h $SDCARD_HEADS -s $SDCARD_SECTORS -l $SDCARD_ALIGNMENT` >> + dd of="$OUTFILE" if="$BOOTLOADER" bs=512 seek=1 conv=notrunc >> + ;; >> + 1) >> + set `ptgen -o "$OUTFILE" \ >> + -h $SDCARD_HEADS -s $SDCARD_SECTORS -l $SDCARD_ALIGNMENT \ >> + -t $PART1_TYPE -p $PART1_SIZE` >> + dd of="$OUTFILE" if="$PART1_IMG" bs=512 seek=$(($1/512)) >> conv=notrunc >> + ;; >> + 2) >> + set `ptgen -o "$OUTFILE" \ >> + -h $SDCARD_HEADS -s $SDCARD_SECTORS -l $SDCARD_ALIGNMENT \ >> + -t $PART1_TYPE -p $PART1_SIZE \ >> + -t $PART2_TYPE -p $PART2_SIZE` >> + dd of="$OUTFILE" if="$BOOTLOADER" bs=512 seek=1 conv=notrunc >> + dd of="$OUTFILE" if="$PART1_IMG" bs=512 seek=$(($1/512)) >> conv=notrunc >> + dd of="$OUTFILE" if="$PART2_IMG" bs=512 seek=$(($2/512)) >> conv=notrunc >> + ;; >> + 3) >> + set `ptgen -o "$OUTFILE" \ >> + -h $SDCARD_HEADS -s $SDCARD_SECTORS -l $SDCARD_ALIGNMENT \ >> + -t $PART1_TYPE -p $PART1_SIZE \ >> + -t $PART2_TYPE -p $PART2_SIZE \ >> + -t $PART3_TYPE -p $PART3_SIZE` >> + dd of="$OUTFILE" if="$BOOTLOADER" bs=512 seek=1 conv=notrunc >> + dd of="$OUTFILE" if="$PART1_IMG" bs=512 seek=$(($1/512)) >> conv=notrunc >> + dd of="$OUTFILE" if="$PART2_IMG" bs=512 seek=$(($2/512)) >> conv=notrunc >> + dd of="$OUTFILE" if="$PART3_IMG" bs=512 seek=$(($3/512)) >> conv=notrunc >> + ;; >> + 4) >> + set `ptgen -o "$OUTFILE" \ >> + -h $SDCARD_HEADS -s $SDCARD_SECTORS -l $SDCARD_ALIGNMENT \ >> + -t $PART1_TYPE -p $PART1_SIZE \ >> + -t $PART2_TYPE -p $PART2_SIZE \ >> + -t $PART3_TYPE -p $PART3_SIZE \ >> + -t $PART4_TYPE -p $PART4_SIZE` >> + dd of="$OUTFILE" if="$BOOTLOADER" bs=512 seek=1 conv=notrunc >> + dd of="$OUTFILE" if="$PART1_IMG" bs=512 seek=$(($1/512)) >> conv=notrunc >> + dd of="$OUTFILE" if="$PART2_IMG" bs=512 seek=$(($2/512)) >> conv=notrunc >> + dd of="$OUTFILE" if="$PART3_IMG" bs=512 seek=$(($3/512)) >> conv=notrunc >> + dd of="$OUTFILE" if="$PART4_IMG" bs=512 seek=$(($4/512)) >> conv=notrunc >> +esac >> diff --git a/tools/Makefile b/tools/Makefile >> index 187655e..9a08573 100644 >> --- a/tools/Makefile >> +++ b/tools/Makefile >> @@ -38,6 +38,7 @@ tools-$(CONFIG_TARGET_x86) += qemu >> tools-$(CONFIG_TARGET_mxs) += elftosb sdimage >> tools-$(CONFIG_TARGET_brcm2708)$(CONFIG_TARGET_sunxi)$(CONFIG_TARGET_mxs) >> += mtools dosfstools >> tools-$(CONFIG_TARGET_ar71xx) += lzma-old squashfs >> +tools-$(CONFIG_TARGET_mvebu) += squashfs dosfstools >> tools-y += lzma squashfs4 >> tools-$(BUILD_B43_TOOLS) += b43-tools >> tools-$(BUILD_PPL_CLOOG) += ppl cloog >> _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From luka at openwrt.org Thu May 5 20:53:27 2016 From: luka at openwrt.org (Luka Perkov) Date: Fri, 6 May 2016 02:53:27 +0200 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <572BB08A.90704@nbd.name> References: <572A5501.3040807@openwrt.org> <572B5B6F.7080203@nbd.name> <572B9D75.9010205@openwrt.org> <572BB08A.90704@nbd.name> Message-ID: <20160506005327.GA21913@localhost.localdomain> >On 2016-05-05 20:22, mbm wrote: >> On 5/5/2016 7:40 AM, Felix Fietkau wrote: >>> Many of the changes that we previously tried to introduce were often >>> squashed by internal disagreements. Resulting discussions often turned >>> toxic quickly and led to nothing being done to address the issues. >>> Setting up the LEDE project was our way of creating a testbed for >>> changes that we believe are important for the survival of the project. >> >> Change is not easy. Discussions need to happen. The problem is simply >> kicking out people you didn't agree with by starting a new organization >> in secret; you've created the public perception that we're somehow >> against you when really we all want the same things. > > Years of internal discussion led nowhere. Maybe it helps now that we're > making the whole issue public. For the sake of transparency, we've had public discussions, about a number of things, for example switching to Git: - https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036390.html - https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036480.html - https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036486.html - https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036500.html And based on these inputs from you the switch was not made even though several OpenWrt developers wanted to switch. Also, server outages can happen to anybody: - https://lists.openwrt.org/pipermail/openwrt-devel/2016-January/038547.html However, we do not want to point fingers. What we do want is to make a great community around OpenWrt and to drive innovation - just like it has been done for more then a decade now. There has been a long history - mostly good, sometimes bad - since the project started from a garage project, to now having a project used by an awesome amount of users. This can be seen from the constructive discussions in this list on a daily basis, and in this very thread. Also, the project is used as the main SDK by many silicon vendors internally, and by vast number of companies on the embedded market. We are open for a discussion and would like to keep the OpenWrt's and it's community interests in the first place. Splitting the project does not make sense. Do you agree? >>> We appreciate your effort to have an open discussion about this, >>> however the sudden deletion of our widely published openwrt.org email >>> addresses somewhat undermines this. We will not respond in kind and we >>> will continue to maintain the critical parts of OpenWrt infrastructure >>> that we control. >> >> Let's be clear on this subject; no commit access was revoked, you still >> have full read and write access to the entire OpenWrt tree. >> >> Email forwarding was temporarily disabled following the LEDE announcement >> - LEDE's own rules prohibit project based email addresses > No, they don't. They state that the LEDE project won't provide project > email addresses. Interpreting that as meaning that we shouldn't be able > to access our openwrt.org addresses is more than a bit of a stretch. In any case, due to the events that happened and the fact that the OpenWrt name is being used in a manner opposite of the projects best interest, we felt that these actions were needed in order to avoid the further damages to the project. >> - It's unclear if LEDE still represents OpenWrt > So? Asking us to not send any further emails about LEDE from our > openwrt.org addresses should have been enough. Actually, this was discussed on #lede-adm. >> My hope is that this whole LEDE vs OpenWrt situation can be resolved. > I hope so too. That is good to hear. Bringing the issue to a more public discussion might speed up resolving them, but it is in everyone's best interest to get them resolved. Since so far there has not been a presented reason why the proposals made could not be incorporated in main OpenWrt as well it still remains unclear what benefits brings splitting the project. I propose we work together to come up with a unified solution that all the community will benefit from. Luka _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Thu May 5 22:01:55 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Thu, 5 May 2016 22:01:55 -0400 Subject: [OpenWrt-Devel] Calmer heads than mine... Message-ID: <572BFB13.1080503@daniel.thecshore.com> Hi all, Sorry for sounding off so much yet again. I've been trying to interpret events with a severe lack of information and have unfavourable guesses and impressions that may or may not be accurate. I do know that some of the developers have a history of not getting along, and that has hurt the project. I also know that there are members of both sides who are frustratingly obstinate and/or antagonistic or downright nasty to people they disagree with. Which is why I'm not sure this rift can be healed. I think it would be good if the saner elements (which is not me; I'm not on either side and I'm too impetuous and ready to make noise) who I think are the majority from both sides would communicate and come to an agreement that they imposed on the less reasonable elements of the groups they are currently part of. I think the calmer elements have gotten caught up in or the other of the less reasonable types battles, and that if the calmer elements could get it together it would benefit the community as a whole Regards, Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From david at lang.hm Thu May 5 23:25:44 2016 From: david at lang.hm (David Lang) Date: Thu, 5 May 2016 20:25:44 -0700 (PDT) Subject: [OpenWrt-Devel] Calmer heads than mine... In-Reply-To: <572BFB13.1080503@daniel.thecshore.com> References: <572BFB13.1080503@daniel.thecshore.com> Message-ID: I also think that it is utterly unreasonable to think that the differences are going to be resolved in the next few days/weeks. It took years to get to this point, and there are some very significant differences of opinion. There is going to need to be time for one side or the other to be proven right/wrong on various issues, and that is only going to happen with months/years of producing and maintaining the codebases. The licenses allow both projects to pull from the other, so most of the hard technical work will end up being shared in practice. The infrastructure and organizational work is a duplication of effort, but since that's where there is a lot of disagreement over the best way to do things, I think this is useful duplication, let time show which elements of each team's ideas work well. I think the key thing right now is to keep the split from becoming toxic the way it sometimes has with other projects. If people can calm down enough to let the split become reasonably friendly, then I think a merge in a year or two would be a real possibility, with the resulting organization being stronger for trying the different approaches. I was surprised and bothered by the extent of the posts announcing LEDE on so many different openwrt mailing lists and forum threads, and I was bothered by the OpenWRT response of shutting off the e-mail. The LEDE people still maintain some of the OpenWRT infrastructure and have said that they are willing to keep doing so. So now that both sides have stepped on each other's toes, can everyone take a deep breath and look forward. OpenWRT needs to fill holes left by the departing people, and think about what truth there is in their complaints, and plan how to deal with them while still maintaining progress. LEDE needs to get infrastructure setup, make a release, and show that they can maintain it and respond to bug reports. Let's let everyone get to work rather than defending themselves or lashing out at the other side, and see how things go over the next several months. David Lang On Thu, 5 May 2016, Daniel Dickinson wrote: > Hi all, > > Sorry for sounding off so much yet again. I've been trying to interpret > events with a severe lack of information and have unfavourable guesses > and impressions that may or may not be accurate. > > I do know that some of the developers have a history of not getting > along, and that has hurt the project. I also know that there are > members of both sides who are frustratingly obstinate and/or > antagonistic or downright nasty to people they disagree with. > > Which is why I'm not sure this rift can be healed. I think it would be > good if the saner elements (which is not me; I'm not on either side and > I'm too impetuous and ready to make noise) who I think are the majority > from both sides would communicate and come to an agreement that they > imposed on the less reasonable elements of the groups they are currently > part of. > > I think the calmer elements have gotten caught up in or the other of the > less reasonable types battles, and that if the calmer elements could get > it together it would benefit the community as a whole > > Regards, > > Daniel > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Thu May 5 23:28:52 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Thu, 5 May 2016 23:28:52 -0400 Subject: [OpenWrt-Devel] A request for more clarity on the fork Message-ID: <572C0F74.40708@daniel.thecshore.com> Hi all, I know other community members of complained about the lack of information about the reasons for the fork (they and I don't think LEDE's official announcement really provides enough information to really understand the situation) and I especially do badly in a vacuum - I tend to strain to find answers and don't necessarily come up with the right one(s) (that was also why I had such an amount of trouble with patches not getting a response, previously). In any event a great many of us would like to have a clearer picture of what lead up to the split, and more complete reasoning for why the problems couldn't be resolved within the current openwrt structure. I've had guesses but now I'm second guessing my guesses, and really it shouldn't be a guessing game, particularly since both sides claim to be interested in transparency and the best interests of the community. C'mon, can we have more than political statements, please? Regards, Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Thu May 5 23:42:23 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Thu, 5 May 2016 23:42:23 -0400 Subject: [OpenWrt-Devel] Scrap that, David makes sense (was Re: A request for more clarity on the fork) In-Reply-To: <572C0F74.40708@daniel.thecshore.com> References: <572C0F74.40708@daniel.thecshore.com> Message-ID: <572C129F.30006@daniel.thecshore.com> I think David Lang makes a lot of sense; it took years to reach this point, better to carry on independently, but working together as much as can be managed, and let time both settle the dust and demonstrate which ideas really pan out. Add to this that with years of toxic arguments (as acknowledged by both sides) behind this, there's likely to be too much acrimony in explanations given. Much as not knowing is something I personally have hard time with, and others have complained of, sometimes it's better to just put that behind, and move forward in a constructive way. Regards, Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From bmoffitt at ayrstone.com Thu May 5 23:49:21 2016 From: bmoffitt at ayrstone.com (Bill Moffitt) Date: Thu, 5 May 2016 20:49:21 -0700 Subject: [OpenWrt-Devel] [OpenWrt] #20982: jffs2-error / nanostation M5 xw / r47658 In-Reply-To: <067.d383ba16b44ec6c99f3b7a015d4eb142@lists.openwrt.org> References: <052.67cd77d5242a66eede09efb67f3e51f4@lists.openwrt.org> <067.d383ba16b44ec6c99f3b7a015d4eb142@lists.openwrt.org> Message-ID: <572C1441.7090700@ayrstone.com> On 05/05/16 19:16, OpenWrt wrote: > #20982: jffs2-error / nanostation M5 xw / r47658 > ------------------------+------------------------ > Reporter: bittorf@? | Owner: developers > Type: defect | Status: new > Priority: normal | Milestone: > Component: packages | Version: Trunk > Resolution: | Keywords: > ------------------------+------------------------ > > Comment (by johnv): > > Replying to [comment:31 bmoffitt]: > > > 1.) Recovery (tftp) flash AirOS 5.6.3 onto the radio; then > > 2.) Using the fwupdate command in AirOS, flash AirOS 5.5.11 onto the > radio; then > > 3.) Again using the fwupdate command, flash OpenWRT onto the radio. > > > > This sequence seems to work on every PicoStation and NanoStation Loco M2 > XM I have gotten SO FAR. Oddly, downgrading a radio that came with AirOS > 5.6 running on it to AirOS 5.5 DID NOT WORK - it appears that it is > necessary to do the recovery (tftp) flash of AirOS 5.6 before you > downgrade to 5.5. I honestly cannot explain it, but, so far, this sequence > seems the only way to reliably flash OpenWRT onto a PicoStation, Bullet, > or NanoStation Loco M2 that comes running AirOS 5.6. > > > Can you confirm the 5.6.X version that was installed on the units when you > received them? There is a Fix in the UBNT changelog for 5.6.4: > > - Fix: After FW downgrade to 5.5.6 device goes to read-only state (TFTP > recovery to previous airOS version is required to restore normal > operation) > > > So wondering if the ones that you have that you are unable to simply > downgrade back to 5.5.11, are prior to 5.6.4 or not. And if so, if you > could upgrade to 5.6.4, then downgrade to 5.5.11, and the OpenWRT. > Getting messier but still might be easier then tftp. Alas, I don't have any new ones at the moment, and probably won't for a few weeks. And I don't recall what the new ones I was testing came with. > > -- > Ticket URL: > OpenWrt > Opensource Wireless Router Technology -- Bill Moffitt Ayrstone Productivity http://ayrstone.com _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Thu May 5 23:53:29 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Thu, 5 May 2016 23:53:29 -0400 Subject: [OpenWrt-Devel] Scrap that, David makes sense (was Re: A request for more clarity on the fork) In-Reply-To: <572C129F.30006@daniel.thecshore.com> References: <572C0F74.40708@daniel.thecshore.com> <572C129F.30006@daniel.thecshore.com> Message-ID: <572C1539.1030901@daniel.thecshore.com> Below is the message referenced in the previous email, so that it makes more sense, but please remember: > Add to this that with years of toxic arguments (as acknowledged by both > sides) behind this, there's likely to be too much acrimony in > explanations given. > > Much as not knowing is something I personally have hard time with, and > others have complained of, sometimes it's better to just put that > behind, and move forward in a constructive way. Hi all, I know other community members of complained about the lack of information about the reasons for the fork (they and I don't think LEDE's official announcement really provides enough information to really understand the situation) and I especially do badly in a vacuum - I tend to strain to find answers and don't necessarily come up with the right one(s) (that was also why I had such an amount of trouble with patches not getting a response, previously). In any event a great many of us would like to have a clearer picture of what lead up to the split, and more complete reasoning for why the problems couldn't be resolved within the current openwrt structure. I've had guesses but now I'm second guessing my guesses, and really it shouldn't be a guessing game, particularly since both sides claim to be interested in transparency and the best interests of the community. C'mon, can we have more than political statements, please? On 16-05-05 11:42 PM, Daniel Dickinson wrote: > I think David Lang makes a lot of sense; it took years to reach this > point, better to carry on independently, but working together as much as > can be managed, and let time both settle the dust and demonstrate which > ideas really pan out. > > Add to this that with years of toxic arguments (as acknowledged by both > sides) behind this, there's likely to be too much acrimony in > explanations given. > > Much as not knowing is something I personally have hard time with, and > others have complained of, sometimes it's better to just put that > behind, and move forward in a constructive way. > > Regards, > > Daniel > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From luizluca at gmail.com Fri May 6 00:31:18 2016 From: luizluca at gmail.com (Luiz Angelo Daros de Luca) Date: Fri, 06 May 2016 04:31:18 +0000 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <20160506005327.GA21913@localhost.localdomain> References: <572A5501.3040807@openwrt.org> <572B5B6F.7080203@nbd.name> <572B9D75.9010205@openwrt.org> <572BB08A.90704@nbd.name> <20160506005327.GA21913@localhost.localdomain> Message-ID: I like to take decisions based more on "Realpolitik" than on ideology/feelings. I have no side and no feelings for any of people involved. I just want to have a good router distribution. What is a OSS project? It is the sum of work of people. So, the future of a project lies on how much people will work on it. Let's face: if you sum the commits count* of those leaving, you start to worry about OpenWRT: Core: 10815 nbd << 4531 juhosg 3649 blogic << 3436 florian 2654 nico 2183 jow << 1482 kaloz 1414 hauke << 925 wbx 718 cyrus << Packages: 512 Steven Barth << 469 Ted Hess << 256 Marcel Denia 250 Daniel Golle << 235 Nikos Mavrogiannopoulos 230 sbyx 214 Hannu Nyman 202 Alexandru Ardelean 162 Jo-Philipp Wich << 154 Nicolas Thill (git shortlog -s -n | head -10) *yes, I know that they are not the author of all commits but they were the ones that reviewed the patches and committed them. If you lose most of the committers, the project will REALLY lag behind, to a point of losing its self sustainability. Those leaving represents more than 50% of commits of all time and, since 2014, they are the top 6 devs with more than 80% of commits. (git shortlog -s -n 3328763a8d0abbcbcf79b5a91e6abbb0b55b3119..HEAD | head -10) They are(were) the ones currently working. One of the complaints was that there were no process of introducing new devs. So, when a bunch of them leave, what will happen? Ease the process of including new devs (which is one of the demanded changes)? Do we really think that there is a suppressed supply of developers wanting to replace the leaving devs? It seems that the decision power in OpenWRT does not match the amount of work each one is currently dedicating to the project. What might happen with the fork? OpenWRT loses 80% of its development power (not counting those that leave to LEDE after). LEDE might attract more devs with an open politic (as packages are much better at github). In the end, if LEDE succeeds on balance more devs, stability and new resources, everybody will use it and OpenWRT will start to rot. If it fails, both projects might die and everybody loses. This was already happened with OpenOffice/LibreOffice (I guess with ffmpeg/libav less devs left). They created a new project because of disagreement (with Oracle). Devs flew to the new project. The old one started to rot and ended dropped to the community. I guess most of the current downloaders of OpenOffice do not know LibreOffice and they are not power users. With OpenWRT, most of downloaders are power users. You can replace infrastructure in a matter of weeks. Replace a brand in months. However, you need years or decades to form a development team. What are the options for OpenWRT Decision Team (as the development team just left)? 1) Do nothing. Let LEDE take its chances. If it succeed, it will take the place of OpenWRT and OpenWRT will rot. If not, we'll might have a version of mutual assured destruction. 2) The remaining OpenWRT Core Team accept some (or all) terms of the LEDE Team. Face it. There were already most of the "OpenWRT Core Team". Now give them the corresponding decision power. Even if all the remaining of the OpenWRT Core Team resign now and give all the control to LEDE, OpenWRT will be less affected than the current situation. If I felt that my position would put in danger a project on which I dedicated and care so much, I would rather simply resign than let my work be gone. OpenWRT should be more than someone's project. However, there is no need to anyone to leave but a need of power transferring. The ones with current decision power at OpenWRT will either give away some of its power or they will lose it all (in favor of a rebooted OpenWRT leaded by LEAD or because it simply became irrelevant). Regards, -- Luiz Angelo Daros de Luca luizluca at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From david at lang.hm Fri May 6 01:04:27 2016 From: david at lang.hm (David Lang) Date: Thu, 5 May 2016 22:04:27 -0700 (PDT) Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: References: <572A5501.3040807@openwrt.org> <572B5B6F.7080203@nbd.name> <572B9D75.9010205@openwrt.org> <572BB08A.90704@nbd.name> <20160506005327.GA21913@localhost.localdomain> Message-ID: You may be right that OpenWRT is doomed, but we have seen time and time again that OpenSource software is not a zero-sum game. Yes, if OpenWRT does nothing, it will struggle, but that's unlikely to be the case. For that matter, even with no new manpower, OpenWRT could just copy everything that LEDE does and still survive for a long time based on brand recognition (after all, people are still downloading OpenOffice, and that hasn't even been pulling improvements from LibreOffice) There's no question that there is going to be disruption and a loss of progress in the short term, but before you count either side out, let them stabilize, and figure out what's really important to them going forward. Revisit the question in 6-9 months and things will probably be much clearer. Remember that the remaining OpenWRT folks haven't has weeks or months to plan what to do at this point. It will take them time for them to figure out what's going to end up happening. In the short term, they have to plug the holes and figure out if anything critical needs to be done to keep the lights on. Only after they are able to get past this short term crisis will they be able to really think about the larger issues and figure out what to do about them. And the LEDE folks have a lot of infrastructure to setup (and there will be a lot of bikeshedding going on while they do this), so they are going to take some time to get everything going and get a release out. David Lang _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From gareth41 at orcon.net.nz Fri May 6 04:06:45 2016 From: gareth41 at orcon.net.nz (Gareth Parker) Date: Fri, 6 May 2016 20:06:45 +1200 Subject: [OpenWrt-Devel] [OpenWrt] #20982: jffs2-error / nanostation M5 xw / r47658 In-Reply-To: <067.f0917b4dcd20f0fed38017b6a5c180b0@lists.openwrt.org> References: <052.67cd77d5242a66eede09efb67f3e51f4@lists.openwrt.org> <067.f0917b4dcd20f0fed38017b6a5c180b0@lists.openwrt.org> Message-ID: <00fa01d1a76e$3ba427b0$b2ec7710$@orcon.net.nz> I sent them one too and got a response back almost immediately: Hi Gareth, Thanks for getting in touch with us! I'll check with my internal team and get back to you once I have any updates. Thanks! Vann T Ubiquiti Networks That was a few hours ago, it will be interesting to see if they do give up the source code. I could also try contacting our local authorized distributor here in NZ and see if they can help. -----Original Message----- From: OpenWrt [mailto:openwrt-devel at lists.openwrt.org] Sent: Friday, 6 May 2016 7:34 p.m. Cc: openwrt-tickets at lists.openwrt.org Subject: Re: [OpenWrt] #20982: jffs2-error / nanostation M5 xw / r47658 #20982: jffs2-error / nanostation M5 xw / r47658 ------------------------+------------------------ Reporter: bittorf@? | Owner: developers Type: defect | Status: new Priority: normal | Milestone: Component: packages | Version: Trunk Resolution: | Keywords: ------------------------+------------------------ Comment (by LeSpocky): Replying to [comment:33 gareth41@?]: > I tried loading trunk over 5.6.2 and could not save any settings. It's something to do with this new u-boot version. I think someone needs to get hold of the source code of new u-boot from UBNT and analyze it, shouldn't be too difficult given its GPL licensed and providing that UBNT comply. I sent a mail to Ubiquiti support today requesting those sources, but after reading http://libertybsd.net/ubiquiti/ and http://community.ubnt.com/t5/Business-Talk/Any-update-on-GPL-licence- violation/m-p/1428448#M47832 I'm not so sure if this will work out. :-/ -- Ticket URL: OpenWrt Opensource Wireless Router Technology _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From leroi.lists at gmail.com Fri May 6 04:50:44 2016 From: leroi.lists at gmail.com (Roman Yeryomin) Date: Fri, 6 May 2016 11:50:44 +0300 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <20160506005327.GA21913@localhost.localdomain> References: <572A5501.3040807@openwrt.org> <572B5B6F.7080203@nbd.name> <572B9D75.9010205@openwrt.org> <572BB08A.90704@nbd.name> <20160506005327.GA21913@localhost.localdomain> Message-ID: On 6 May 2016 at 03:53, Luka Perkov wrote: >>On 2016-05-05 20:22, mbm wrote: >>> On 5/5/2016 7:40 AM, Felix Fietkau wrote: >>>> Many of the changes that we previously tried to introduce were often >>>> squashed by internal disagreements. Resulting discussions often turned >>>> toxic quickly and led to nothing being done to address the issues. >>>> Setting up the LEDE project was our way of creating a testbed for >>>> changes that we believe are important for the survival of the project. >>> >>> Change is not easy. Discussions need to happen. The problem is simply >>> kicking out people you didn't agree with by starting a new organization >>> in secret; you've created the public perception that we're somehow >>> against you when really we all want the same things. >> >> Years of internal discussion led nowhere. Maybe it helps now that we're >> making the whole issue public. > > For the sake of transparency, we've had public discussions, about a number of > things, for example switching to Git: > > - https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036390.html > - https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036480.html > - https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036486.html > - https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036500.html > > And based on these inputs from you the switch was not made even though several > OpenWrt developers wanted to switch. > > Also, server outages can happen to anybody: > - https://lists.openwrt.org/pipermail/openwrt-devel/2016-January/038547.html > > However, we do not want to point fingers. What we do want is to make a great > community around OpenWrt and to drive innovation - just like it has been done > for more then a decade now. > > There has been a long history - mostly good, sometimes bad - since the project > started from a garage project, to now having a project used by an awesome > amount of users. This can be seen from the constructive discussions in this > list on a daily basis, and in this very thread. Also, the project is used as > the main SDK by many silicon vendors internally, and by vast number of > companies on the embedded market. > > We are open for a discussion and would like to keep the OpenWrt's and it's > community interests in the first place. Splitting the project does not make > sense. Do you agree? > >>>> We appreciate your effort to have an open discussion about this, >>>> however the sudden deletion of our widely published openwrt.org email >>>> addresses somewhat undermines this. We will not respond in kind and we >>>> will continue to maintain the critical parts of OpenWrt infrastructure >>>> that we control. >>> >>> Let's be clear on this subject; no commit access was revoked, you still >>> have full read and write access to the entire OpenWrt tree. >>> >>> Email forwarding was temporarily disabled following the LEDE announcement >>> - LEDE's own rules prohibit project based email addresses >> No, they don't. They state that the LEDE project won't provide project >> email addresses. Interpreting that as meaning that we shouldn't be able >> to access our openwrt.org addresses is more than a bit of a stretch. > > In any case, due to the events that happened and the fact that the OpenWrt name > is being used in a manner opposite of the projects best interest, we felt that > these actions were needed in order to avoid the further damages to the project. > >>> - It's unclear if LEDE still represents OpenWrt >> So? Asking us to not send any further emails about LEDE from our >> openwrt.org addresses should have been enough. > > Actually, this was discussed on #lede-adm. IRC history is hard to follow, I'd better assume that something not written here never happened. Regards, Roman _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From valent at otvorenamreza.org Fri May 6 06:48:47 2016 From: valent at otvorenamreza.org (Valent Turkovic) Date: Fri, 6 May 2016 12:48:47 +0200 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <572BB08A.90704@nbd.name> References: <572A5501.3040807@openwrt.org> <572B5B6F.7080203@nbd.name> <572B9D75.9010205@openwrt.org> <572BB08A.90704@nbd.name> Message-ID: I'm an outsider, have nothing to do with OpenWrt developement but still work on few projects which depend on OpenWrt as awesome project that enables us to do our projects (wifi mesh networking) but also do professional jobs for clients using OpenWrt as embedded os for lots of different applications. We have "suffered" both on volunteers side (wifi mesh) and on professional side by infrastructure failing... mirrors, wiki, forum... you name it, all of it was down quite a lot in last few years, and on IRC or mailing list you couldn't get concrete and timely answers. This is a HUGE red flag for any size project. Also even if we hd really good developers who know what they were doing (I'm not that one) we couldn't get patches into trunk without knowing somebody in the inside circle who has commit access, so patches would get ignored... and kept in our own git... this is also a really huge red flag. I have convinced companies that I work for to donate money towards OpenWrt so you have some budget for infrastructure, and I'm sure that there are lots of other people who could also get some funding, but answers I got on IRC were really dissapointing - that there is now was to give donations towards better infrastructure or any other kind of collecting funds... These are all signs of poorly managed open source project/community and I welcome any change in any direction that aims to fix any of these issues... so fork away and make things better. Go LEDE team! _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From john at phrozen.org Fri May 6 06:50:32 2016 From: john at phrozen.org (John Crispin) Date: Fri, 6 May 2016 12:50:32 +0200 Subject: [OpenWrt-Devel] reboot Message-ID: <2a9c75b7-cd89-0aa7-8d54-976f53debaeb@phrozen.org> the reboot was not meant to be hostile or disruptive to OpenWrt. we are just code nerds and messed up the politics of the launch at some places, which in itself shows one of the reasons that motivated the reboot. the whole idea is to give up our control over parts of the politics and attract a new generation. a small none elected crowd has been making decisions that essentially are not ours to make but effect us all. these decisions have been made largely behind closed doors. the whole thing started by the workload becoming unbearable on a few. we felt the need to simply stop or make drastic changes. giving up and just letting it all bitrot seemed to be the easy way out, but we did feel that we had a debt to our own heritage. simply leaving seemed bad and unfair on the community. we decided to get the project back on track instead. we?ll be the first to agree that things where not peachy at times. this however does not boil down to one single event, one single person or one single flamewar. we are just many strong minded people that had different opinions on many matters. due to the governance rules that we setup and created and the way in which we managed the project it was hard to mitigate these problems. the reason for not involving everyone at the start is pretty simple and nerdy. when the idea came up we just looked at who was the most active in the various software trees the last 6 months and proposed our idea to the 5 most active core devs and power users. it was a simple choice of numbers and perceived activity. the feedback was rather overwhelming and things just picked up a certain momentum leading to the status quo. i guess the excitement for fixing long standing issues just took over. i have been asked by luka why we consider this a reboot rather than a fork. i actually had to think about that one. a fork for me means that one party splits with a second. that was not our intent. we wanted to split with the errors we have done ourselves in the past and the wrong management decision that were made at times. the gap between core developers, power users and endusers had grown way too big. hence i consider this more a ?We are forking ourselves? or as we put it, rebooting the system. to sum it up, my personal reasoning why i endorse this ? the now 20 year olds like social media, github, clouds and what nots. for me to continue shaping a development and political system that they should use in their future to run on their routers when i am already double their age is not ideal. the next generation should be given the freedom to shape their own future and learn from their mistakes the same way we shaped our future and learned form our mistakes. i sincerely hope that the reboot will encourage people to step up and not only have good ideas of what should be fixed but will start to shape their future themselves John _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From kaloz at openwrt.org Fri May 6 07:53:20 2016 From: kaloz at openwrt.org (Imre Kaloz) Date: Fri, 06 May 2016 13:53:20 +0200 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <572B73A9.9070909@daniel.thecshore.com> References: <572A5501.3040807@openwrt.org> <572AC280.1000608@daniel.thecshore.com> <572B5C05.8080306@daniel.thecshore.com> <572B62B5.4000602@gmail.com> <572B6D9A.6030606@daniel.thecshore.com> <572B73A9.9070909@daniel.thecshore.com> Message-ID: On Thu, 05 May 2016 18:24:09 +0200, Daniel Dickinson wrote: > On 16-05-05 12:21 PM, Jonathan Bennett wrote: > [snip] >> > The changes that the Lede guys are suggesting would be welcome, >> but >> > splitting the project and community with an ugly fork is very >> much not >> > welcome. >> >> Let's just say that there are strong personalities who haven't been >> working well together and that this has been a long time coming; >> perhaps >> if something like using a mediator had been considered before >> things got >> to this point it would have helped. At this point I'm not sure >> there is a >> solution unless both sides are willing to bend a little (I'm really >> not >> sure who has been flexible and who has not, but as I have said I >> suspect >> a large part of the issue is that 'management' (who aren't and >> don't, >> really) has overruled those doing the majority of the work and in an >> open source project that doesn't fly). >> >> I don't disagree. I just see the current state of Openwrt/Lede as a >> mess for the community. > > I agree, I just don't see how the LEDE team could have avoided it > without giving up and accepting the broken status quo. I hope you realize the LEDE team created most of that status quo. Imre _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From kaloz at openwrt.org Fri May 6 07:53:21 2016 From: kaloz at openwrt.org (Imre Kaloz) Date: Fri, 06 May 2016 13:53:21 +0200 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: <7e13620b-8d68-f587-eea2-ab97865d549f@posteo.net> References: <572A5501.3040807@openwrt.org> <572AC280.1000608@daniel.thecshore.com> <572B5C05.8080306@daniel.thecshore.com> <572B62B5.4000602@gmail.com> <7e13620b-8d68-f587-eea2-ab97865d549f@posteo.net> Message-ID: On Thu, 05 May 2016 17:44:43 +0200, Daniel Petre wrote: > > > On 05/05/2016 06:38 PM, Jonathan Bennett wrote: >> There is plenty of blame to go around, I think. Seems like the Lede >> guys should have had the decency to at least inform the Openwrt >> leadership privately that they were planning this venture. > > If i read correctly the feedback from the LEDE guys (and many of the > people in here) then it seems EVEN THEY did not had any serious real > feedback since a while ago from the main OpenWrt "headquarters". > > So.. what do you do when you ask (probably several times) and do not get > any answer at all.. ? They were in charge. When the lead developer and the release manager claim they had no power to change the way (yet both procd and netifd got introduced without prior discussion or agreement), you know something is fishy. Imre _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From kaloz at openwrt.org Fri May 6 07:53:21 2016 From: kaloz at openwrt.org (Imre Kaloz) Date: Fri, 06 May 2016 13:53:21 +0200 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: References: <572A5501.3040807@openwrt.org> <572B5B6F.7080203@nbd.name> <572B9D75.9010205@openwrt.org> <572BB08A.90704@nbd.name> <20160506005327.GA21913@localhost.localdomain> Message-ID: On Fri, 06 May 2016 06:31:18 +0200, Luiz Angelo Daros de Luca wrote: > (git shortlog -s -n | head -10) You can do statistics various ways to tell various truths ;) > 2) The remaining OpenWRT Core Team accept some (or all) terms of the LEDE > Team. Face it. There were already most of the "OpenWRT Core Team". Now > give > them the corresponding decision power. > The ones with current decision power at OpenWRT will either give away > some > of its power or they will lose it all (in favor of a rebooted OpenWRT > leaded by LEAD or because it simply became irrelevant). Well, blogic was the release manager and nbd was the lead developer. Please tell me what decision power did they lack. Let's see what technical changes has been introduced in LEDE (https://www.lede-project.org/development.html): - swithing to git - switching to timed releases - getting rid of trac - making patch submission easy - stop upgrading to kernels not fully tested These changes have been proposed by me and by others, blocked by nbd and blogic. Let's look at the rules (https://www.lede-project.org/rules.html): 1. sounds nice, already outruled by "2" 2. that was the case in openwrt from the beginning 3. same as "2" 4. I've proposed this with _1 year_ timeframe, blogic called me a fascist and blocked it with nbd 5. same in openwrt, the only exception back in time was when we didn't have a separate packages repo (so _package maintainers_ had access limited to own packages) 6. this was the case with openwrt from day 0. This is how even blogic became a developer fyi. 7. ok, the first difference - voted were not public, decisions became public 8. second difference - we've tried to be as independent as possible eve with the disadvantages that came as a price 9. some infra was in sole control of people in LEDE, others are not in their control (but almost never under a sinle person's control) 10. we do offer those - for developers representing the project 11. n/a Imre _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From kaloz at openwrt.org Fri May 6 08:23:08 2016 From: kaloz at openwrt.org (Imre Kaloz) Date: Fri, 06 May 2016 14:23:08 +0200 Subject: [OpenWrt-Devel] reboot In-Reply-To: <2a9c75b7-cd89-0aa7-8d54-976f53debaeb@phrozen.org> References: <2a9c75b7-cd89-0aa7-8d54-976f53debaeb@phrozen.org> Message-ID: On Fri, 06 May 2016 12:50:32 +0200, John Crispin wrote: > the reboot was not meant to be hostile or disruptive to OpenWrt. we are > just code nerds and messed up the politics of the launch at some places, > which in itself shows one of the reasons that motivated the reboot. the > whole idea is to give up our control over parts of the politics and > attract a new generation. a small none elected crowd has been making > decisions that essentially are not ours to make but effect us all. these > decisions have been made largely behind closed doors. You were part of the "small none elected crowd". > the whole thing started by the workload becoming unbearable on a few. we > felt the need to simply stop or make drastic changes. giving up and just > letting it all bitrot seemed to be the easy way out, but we did feel > that we had a debt to our own heritage. simply leaving seemed bad and > unfair on the community. we decided to get the project back on track > instead. So instead of exercising your right as a release manager or Felix his as the lead developer you've prepared LEDE. And don't tell me you didn't have the power, fro example procd and netifd were introduced without voting or everyone's agreement for example. Don't get me wrong, we're talking about how changes were introduced, not the nature of these changes. > we?ll be the first to agree that things where not peachy at times. this > however does not boil down to one single event, one single person or one > single flamewar. we are just many strong minded people that had > different opinions on many matters. due to the governance rules that we > setup and created and the way in which we managed the project it was > hard to mitigate these problems. Not true. You had the power, yet you didn't use it. You could have called for a vote but you did not. > the reason for not involving everyone at the start is pretty simple and > nerdy. when the idea came up we just looked at who was the most active > in the various software trees the last 6 months and proposed our idea to > the 5 most active core devs and power users. it was a simple choice of > numbers and perceived activity. the feedback was rather overwhelming and > things just picked up a certain momentum leading to the status quo. i > guess the excitement for fixing long standing issues just took over. Sure, playing democracy is easy if only the ones you agree on have the right to be included in decisions. > i have been asked by luka why we consider this a reboot rather than a > fork. i actually had to think about that one. a fork for me means that > one party splits with a second. that was not our intent. we wanted to > split with the errors we have done ourselves in the past and the wrong > management decision that were made at times. the gap between core > developers, power users and endusers had grown way too big. hence i > consider this more a ?We are forking ourselves? or as we put it, > rebooting the system. Again, as RM and LD, plus having the right to call a vote you had all the power you could need to make these changes in openwrt. Even the ones you turned down but introduced as modernization in LEDE. > to sum it up, my personal reasoning why i endorse this ? the now 20 year > olds like social media, github, clouds and what nots. for me to continue > shaping a development and political system that they should use in their > future to run on their routers when i am already double their age is not > ideal. the next generation should be given the freedom to shape their > own future and learn from their mistakes the same way we shaped our > future and learned form our mistakes. i sincerely hope that the reboot > will encourage people to step up and not only have good ideas of what > should be fixed but will start to shape their future themselves This is so full of political pr it makes me remember "make America great again".. Imre _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From zajec5 at gmail.com Fri May 6 08:50:13 2016 From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=) Date: Fri, 6 May 2016 14:50:13 +0200 Subject: [OpenWrt-Devel] [PATCH] mtd: add -c option for specifying amount of data to be used for checksum Message-ID: <1462539013-18188-1-git-send-email-zajec5@gmail.com> So far fixtrx was calculating checksum over amount of data matching partition erase size. It was mostly a workaround of checksum problem after changing anything in initial TRX content (e.g. formatting JFFS2). Its main purpose was to make bootloader accept modified TRX. This didn't provide much protection of flash data against corruption. This new option lets caller request calculating checksum over a bigger amount of data. It may be used e.g. to include whole kernel data for checksum and hopefully make bootloader go info failsafe mode if something goes wrong. Signed-off-by: Rafa? Mi?ecki --- package/system/mtd/src/mtd.c | 16 +++++++++++++--- package/system/mtd/src/mtd.h | 2 +- package/system/mtd/src/trx.c | 21 ++++++++++++--------- 3 files changed, 26 insertions(+), 13 deletions(-) diff --git a/package/system/mtd/src/mtd.c b/package/system/mtd/src/mtd.c index dae0514..f206c4f 100644 --- a/package/system/mtd/src/mtd.c +++ b/package/system/mtd/src/mtd.c @@ -737,6 +737,8 @@ static void usage(void) if (mtd_fixtrx) { fprintf(stderr, " -o offset offset of the image header in the partition(for fixtrx)\n"); + fprintf(stderr, + " -c datasize amount of data to be used for checksum calculation (for fixtrx)\n"); } fprintf(stderr, #ifdef FIS_SUPPORT @@ -769,7 +771,7 @@ int main (int argc, char **argv) int ch, i, boot, imagefd = 0, force, unlocked; char *erase[MAX_ARGS], *device = NULL; char *fis_layout = NULL; - size_t offset = 0, part_offset = 0, dump_len = 0; + size_t offset = 0, datasize = 0, part_offset = 0, dump_len = 0; enum { CMD_ERASE, CMD_WRITE, @@ -793,7 +795,7 @@ int main (int argc, char **argv) #ifdef FIS_SUPPORT "F:" #endif - "frnqe:d:s:j:p:o:l:")) != -1) + "frnqe:d:s:j:p:o:c:l:")) != -1) switch (ch) { case 'f': force = 1; @@ -853,6 +855,14 @@ int main (int argc, char **argv) usage(); } break; + case 'c': + errno = 0; + datasize = strtoul(optarg, 0, 0); + if (errno) { + fprintf(stderr, "-d: illegal numeric string\n"); + usage(); + } + break; #ifdef FIS_SUPPORT case 'F': fis_layout = optarg; @@ -967,7 +977,7 @@ int main (int argc, char **argv) break; case CMD_FIXTRX: if (mtd_fixtrx) { - mtd_fixtrx(device, offset); + mtd_fixtrx(device, offset, datasize); } case CMD_RESETBC: if (mtd_resetbc) { diff --git a/package/system/mtd/src/mtd.h b/package/system/mtd/src/mtd.h index 751b0d0..52074fc 100644 --- a/package/system/mtd/src/mtd.h +++ b/package/system/mtd/src/mtd.h @@ -25,7 +25,7 @@ extern void mtd_parse_jffs2data(const char *buf, const char *dir); /* target specific functions */ extern int trx_fixup(int fd, const char *name) __attribute__ ((weak)); extern int trx_check(int imagefd, const char *mtd, char *buf, int *len) __attribute__ ((weak)); -extern int mtd_fixtrx(const char *mtd, size_t offset) __attribute__ ((weak)); +extern int mtd_fixtrx(const char *mtd, size_t offset, size_t datasize) __attribute__ ((weak)); extern int mtd_fixseama(const char *mtd, size_t offset) __attribute__ ((weak)); extern int mtd_resetbc(const char *mtd) __attribute__ ((weak)); #endif /* __mtd_h */ diff --git a/package/system/mtd/src/trx.c b/package/system/mtd/src/trx.c index 00c4d6c..2a41e0f 100644 --- a/package/system/mtd/src/trx.c +++ b/package/system/mtd/src/trx.c @@ -148,7 +148,7 @@ trx_check(int imagefd, const char *mtd, char *buf, int *len) #endif int -mtd_fixtrx(const char *mtd, size_t offset) +mtd_fixtrx(const char *mtd, size_t offset, size_t datasize) { int fd; struct trx_header *trx; @@ -165,22 +165,25 @@ mtd_fixtrx(const char *mtd, size_t offset) exit(1); } + if (!datasize) + datasize = erasesize; + block_offset = offset & ~(erasesize - 1); offset -= block_offset; - if (block_offset + erasesize > mtdsize) { + if (block_offset + datasize > mtdsize) { fprintf(stderr, "Offset too large, device size 0x%x\n", mtdsize); exit(1); } - buf = malloc(erasesize); + buf = malloc(datasize); if (!buf) { perror("malloc"); exit(1); } - res = pread(fd, buf, erasesize, block_offset); - if (res != erasesize) { + res = pread(fd, buf, datasize, block_offset); + if (res != datasize) { perror("pread"); exit(1); } @@ -191,16 +194,16 @@ mtd_fixtrx(const char *mtd, size_t offset) exit(1); } - if (trx->len == STORE32_LE(erasesize - offset)) { + if (trx->len == STORE32_LE(datasize - offset)) { if (quiet < 2) fprintf(stderr, "Header already fixed, exiting\n"); close(fd); return 0; } - trx->len = STORE32_LE(erasesize - offset); + trx->len = STORE32_LE(datasize - offset); - trx->crc32 = STORE32_LE(crc32buf((char*) &trx->flag_version, erasesize - offset - 3*4)); + trx->crc32 = STORE32_LE(crc32buf((char*) &trx->flag_version, datasize - offset - 3*4)); if (mtd_erase_block(fd, block_offset)) { fprintf(stderr, "Can't erease block at 0x%x (%s)\n", block_offset, strerror(errno)); exit(1); @@ -209,7 +212,7 @@ mtd_fixtrx(const char *mtd, size_t offset) if (quiet < 2) fprintf(stderr, "New crc32: 0x%x, rewriting block\n", trx->crc32); - if (pwrite(fd, buf, erasesize, block_offset) != erasesize) { + if (pwrite(fd, buf, datasize, block_offset) != datasize) { fprintf(stderr, "Error writing block (%s)\n", strerror(errno)); exit(1); } -- 1.8.4.5 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Fri May 6 09:36:30 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Fri, 6 May 2016 09:36:30 -0400 Subject: [OpenWrt-Devel] Apology (was Re: Introducing the LEDE project) In-Reply-To: References: <572A5501.3040807@openwrt.org> <572AC280.1000608@daniel.thecshore.com> <572B5C05.8080306@daniel.thecshore.com> <572B62B5.4000602@gmail.com> <572B6D9A.6030606@daniel.thecshore.com> <572B73A9.9070909@daniel.thecshore.com> Message-ID: <572C9DDE.9020103@daniel.thecshore.com> Hi Imre, I'm doing this a lot lately. I'm sorry for publicly making guesses, stating impressions that were not fair to you. I do not know what the truth is and trying divine the information with the little information I have doesn't work, and is not fair. Sorry. Regards, Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Fri May 6 09:40:34 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Fri, 6 May 2016 09:40:34 -0400 Subject: [OpenWrt-Devel] Introducing the LEDE project In-Reply-To: References: <572A5501.3040807@openwrt.org> <572AC280.1000608@daniel.thecshore.com> <572B5C05.8080306@daniel.thecshore.com> <572B62B5.4000602@gmail.com> <572B6D9A.6030606@daniel.thecshore.com> <572B73A9.9070909@daniel.thecshore.com> Message-ID: <572C9ED2.30906@daniel.thecshore.com> On 16-05-06 07:53 AM, Imre Kaloz wrote: > On Thu, 05 May 2016 18:24:09 +0200, Daniel Dickinson > wrote: > >> On 16-05-05 12:21 PM, Jonathan Bennett wrote: >> [snip] >>> > The changes that the Lede guys are suggesting would be welcome, >>> but >>> > splitting the project and community with an ugly fork is very >>> much not >>> > welcome. >>> >>> Let's just say that there are strong personalities who haven't been >>> working well together and that this has been a long time coming; >>> perhaps >>> if something like using a mediator had been considered before >>> things got >>> to this point it would have helped. At this point I'm not sure >>> there is a >>> solution unless both sides are willing to bend a little (I'm >>> really not >>> sure who has been flexible and who has not, but as I have said I >>> suspect >>> a large part of the issue is that 'management' (who aren't and >>> don't, >>> really) has overruled those doing the majority of the work and in an >>> open source project that doesn't fly). >>> >>> I don't disagree. I just see the current state of Openwrt/Lede as a >>> mess for the community. >> >> I agree, I just don't see how the LEDE team could have avoided it >> without giving up and accepting the broken status quo. > > I hope you realize the LEDE team created most of that status quo. In part that is why I came to my senses and realized that in my attempts to understand the situation and make sense if it with insufficient information that I made guesses and had impressions that may not be accurate, and that calmer headers needed to prevail. I am not totally convinced that LEDE is really going to be different, for this very reason. As I've said elsewhere, at this point time is what will show the truth or falsehood of the claims made. Regards, Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From dantonov at gmail.com Fri May 6 12:02:44 2016 From: dantonov at gmail.com (Dmitry Antonov) Date: Fri, 6 May 2016 19:02:44 +0300 Subject: [OpenWrt-Devel] [PATCH] ramips: add WT3020 with 16MB flash Message-ID: A little HW-mod applied to WT3020 makes it more usable. Some people can buy it and need an updated OpenWRT. Signed-off-by: Dmitry Antonov --- diff --git a/openwrt_wt3020-16MB/target/linux/ramips/dts/WT3020-16M.dts b/openwrt_wt3020-16MB/target/linux/ramips/dts/WT3020-16M.dts new file mode 100644 index 0000000..ff13560 --- /dev/null +++ b/openwrt_wt3020-16MB/target/linux/ramips/dts/WT3020-16M.dts @@ -0,0 +1,102 @@ +/dts-v1/; + +/include/ "mt7620n.dtsi" + +/ { + compatible = "wt3020", "ralink,mt7620n-soc"; + model = "Nexx WT3020"; + + palmbus at 10000000 { + gpio2: gpio at 660 { + status = "okay"; + }; + + gpio3: gpio at 688 { + status = "okay"; + }; + + spi at b00 { + status = "okay"; + + m25p80 at 0 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "jedec,spi-nor"; + reg = <0 0>; + linux,modalias = "m25p80", "w25q128"; + spi-max-frequency = <10000000>; + + partition at 0 { + label = "u-boot"; + reg = <0x0 0x30000>; + read-only; + }; + + partition at 30000 { + label = "u-boot-env"; + reg = <0x30000 0x10000>; + read-only; + }; + + factory: partition at 40000 { + label = "factory"; + reg = <0x40000 0x10000>; + read-only; + }; + + partition at 50000 { + label = "firmware"; + reg = <0x50000 0xfb0000>; + }; + }; + }; + }; + + ehci at 101c0000 { + status = "okay"; + }; + + ohci at 101c1000 { + status = "okay"; + }; + + ethernet at 10100000 { + mtd-mac-address = <&factory 0x4>; + mediatek,portmap = "wllll"; + }; + + wmac at 10180000 { + ralink,mtd-eeprom = <&factory 0>; + }; + + pinctrl { + state_default: pinctrl0 { + default { + ralink,group = "ephy", "wled", "pa", "i2c", "wdt", "uartf"; + ralink,function = "gpio"; + }; + }; + }; + + gpio-keys-polled { + compatible = "gpio-keys-polled"; + #address-cells = <1>; + #size-cells = <0>; + poll-interval = <20>; + + reset { + label = "reset"; + gpios = <&gpio0 1 1>; + linux,code = <0x198>; + }; + }; + + gpio-leds { + compatible = "gpio-leds"; + + power { + label = "wt3020:blue:power"; + gpios = <&gpio3 0 0>; + }; + }; +}; diff --git a/openwrt/target/linux/ramips/image/Makefile b/openwrt_wt3020-16MB/target/linux/ramips/image/Makefile index 6e0349f..1d78c86 100644 --- a/openwrt/target/linux/ramips/image/Makefile +++ b/openwrt_wt3020-16MB/target/linux/ramips/image/Makefile @@ -145,24 +145,28 @@ endef # $(1) = squashfs/initramfs # $(2) = lowercase board name # $(3) = dts file +# $(4) = uImage header name field ralink_default_fw_size_4M=3866624 BuildFirmware/Default4M/squashfs=$(call BuildFirmware/OF,$(1),$(2),$(3),$(ralink_default_fw_size_4M),$(4)) BuildFirmware/Default4M/initramfs=$(call BuildFirmware/OF/initramfs,$(1),$(2),$(3),$(4)) # Build images for default ralink layout for 8MB flash # kernel + roots = 0x7b0000 -# $(1) = squashfs/initramfs -# $(2) = lowercase board name -# $(3) = dts file -# $(4) = uImage header name field +# parameters' descriptions the same as "... for 4MB flash" ralink_default_fw_size_8M=8060928 BuildFirmware/Default8M/squashfs=$(call BuildFirmware/OF,$(1),$(2),$(3),$(ralink_default_fw_size_8M),$(4)) BuildFirmware/Default8M/initramfs=$(call BuildFirmware/OF/initramfs,$(1),$(2),$(3),$(4)) -ralink_default_fw_size_16M=16121856 +# Build images for default ralink layout for 16MB flash +# kernel + roots = 0xfb0000 +# parameters' descriptions the same as "... for 4MB flash" +ralink_default_fw_size_16M=16449536 BuildFirmware/Default16M/squashfs=$(call BuildFirmware/OF,$(1),$(2),$(3),$(ralink_default_fw_size_16M),$(4)) BuildFirmware/Default16M/initramfs=$(call BuildFirmware/OF/initramfs,$(1),$(2),$(3),$(4)) +# Build images for default ralink layout for 32MB flash +# kernel + roots = 0x1fb0000 +# parameters' descriptions the same as "... for 4MB flash" ralink_default_fw_size_32M=33226752 BuildFirmware/Default32M/squashfs=$(call BuildFirmware/OF,$(1),$(2),$(3),$(ralink_default_fw_size_32M),$(4)) BuildFirmware/Default32M/initramfs=$(call BuildFirmware/OF/initramfs,$(1),$(2),$(3),$(4)) @@ -192,6 +196,18 @@ define BuildFirmware/DefaultDualSize/initramfs $(call BuildFirmware/OF/initramfs,$(1),$(2)-8M,$(3)-8M) endef +# wrappers for boards that have 4MB, 8MB and 16MB versions +define BuildFirmware/DefaultThreeSize/squashfs + $(call BuildFirmware/Default4M/$(1),$(1),$(2)-4M,$(3)-4M) + $(call BuildFirmware/Default8M/$(1),$(1),$(2)-8M,$(3)-8M) + $(call BuildFirmware/Default16M/$(1),$(1),$(2)-16M,$(3)-16M) +endef +define BuildFirmware/DefaultThreeSize/initramfs + $(call BuildFirmware/OF/initramfs,$(1),$(2)-4M,$(3)-4M) + $(call BuildFirmware/OF/initramfs,$(1),$(2)-8M,$(3)-8M) + $(call BuildFirmware/OF/initramfs,$(1),$(2)-16M,$(3)-16M) +endef + # build Seama header images define BuildFirmware/Seama/squashfs $(call MkImageLzmaDtb,$(2),$(3),$(5)) @@ -239,6 +255,25 @@ define BuildFirmware/PorayDualSize/squashfs endef BuildFirmware/PorayDualSize/initramfs=$(call BuildFirmware/DefaultDualSize/initramfs,$(1),$(2),$(3)) +define BuildFirmware/PorayThreeSize/squashfs + $(call BuildFirmware/DefaultThreeSize/$(1),$(1),$(2),$(3)) + if [ -e "$(call sysupname,$(1),$(2)-4M)" ]; then \ + mkporayfw -B $(3) -F 4M \ + -f $(call sysupname,$(1),$(2)-4M) \ + -o $(call imgname,$(1),$(2)-4M)-factory.bin; \ + fi + if [ -e "$(call sysupname,$(1),$(2)-8M)" ]; then \ + mkporayfw -B $(3) -F 8M \ + -f $(call sysupname,$(1),$(2)-8M) \ + -o $(call imgname,$(1),$(2)-8M)-factory.bin; \ + fi + if [ -e "$(call sysupname,$(1),$(2)-16M)" ]; then \ + mkporayfw -B $(3) -F 16M \ + -f $(call sysupname,$(1),$(2)-16M) \ + -o $(call imgname,$(1),$(2)-16M)-factory.bin; \ + fi +endef +BuildFirmware/PorayThreeSize/initramfs=$(call BuildFirmware/DefaultThreeSize/initramfs,$(1),$(2),$(3)) ifeq ($(SUBTARGET),rt288x) include rt288x.mk diff --git a/openwrt/target/linux/ramips/image/mt7620.mk b/openwrt_wt3020-16MB/target/linux/ramips/image/mt7620.mk index 09c0ec2..539149d 100644 --- a/openwrt/target/linux/ramips/image/mt7620.mk +++ b/openwrt_wt3020-16MB/target/linux/ramips/image/mt7620.mk @@ -116,7 +116,7 @@ Image/Build/Profile/WMR-300=$(call BuildFirmware/Default8M/$(1),$(1),wmr-300,WMR Image/Build/Profile/RT-N14U=$(call BuildFirmware/Default8M/$(1),$(1),rt-n14u,RT-N14U) Image/Build/Profile/WRH-300CR=$(call BuildFirmware/WRH-300CR/$(1),$(1),wrh-300cr,WRH-300CR) Image/Build/Profile/WRTNODE=$(call BuildFirmware/Default16M/$(1),$(1),wrtnode,WRTNODE) -Image/Build/Profile/WT3020=$(call BuildFirmware/PorayDualSize/$(1),$(1),wt3020,WT3020) +Image/Build/Profile/WT3020=$(call BuildFirmware/PorayThreeSize/$(1),$(1),wt3020,WT3020) Image/Build/Profile/MIWIFI-MINI=$(call BuildFirmware/Default16M/$(1),$(1),miwifi-mini,MIWIFI-MINI) Image/Build/Profile/GL-MT300A=$(call BuildFirmware/Default16M/$(1),$(1),gl-mt300a,GL-MT300A) Image/Build/Profile/GL-MT300N=$(call BuildFirmware/Default16M/$(1),$(1),gl-mt300n,GL-MT300N) diff --git a/openwrt/tools/firmware-utils/src/mkporayfw.c b/openwrt_wt3020-16MB/tools/firmware-utils/src/mkporayfw.c index 6ec4f32..1463e03 100644 --- a/openwrt/tools/firmware-utils/src/mkporayfw.c +++ b/openwrt_wt3020-16MB/tools/firmware-utils/src/mkporayfw.c @@ -136,6 +136,10 @@ static struct flash_layout layouts[] = { .id = "8M", .fw_max_len = 0x7c0000, }, { + .id = "16M", + .fw_max_len = 0xfc0000, + }, { /* terminating entry */ } }; -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From yeohchunyeow at gmail.com Fri May 6 12:35:17 2016 From: yeohchunyeow at gmail.com (Chun-Yeow Yeoh) Date: Sat, 7 May 2016 00:35:17 +0800 Subject: [OpenWrt-Devel] [PATCH] mac80211.sh: add support of VHT80 for mesh Message-ID: <1462552517-1670-1-git-send-email-yeohchunyeow@gmail.com> Add support of VHT80 setting for mesh interface Signed-off-by: Chun-Yeow Yeoh --- .../mac80211/files/lib/netifd/wireless/mac80211.sh | 33 +++++++++++----------- 1 file changed, 17 insertions(+), 16 deletions(-) diff --git a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh index 02c195e..d680ac2 100644 --- a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh +++ b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh @@ -473,7 +473,7 @@ mac80211_prepare_vif() { esac case "$mode" in - monitor|mesh) + monitor) [ "$auto_channel" -gt 0 ] || iw dev "$ifname" set channel "$channel" $htmode ;; esac @@ -495,40 +495,40 @@ mac80211_setup_supplicant() { wpa_supplicant_run "$ifname" ${hostapd_ctrl:+-H $hostapd_ctrl} } -mac80211_setup_adhoc_htmode() { +mac80211_setup_bss_htmode() { case "$htmode" in - VHT20|HT20) ibss_htmode=HT20;; + VHT20|HT20) bss_htmode=HT20;; HT40*|VHT40|VHT160) case "$hwmode" in a) case "$(( ($channel / 4) % 2 ))" in - 1) ibss_htmode="HT40+" ;; - 0) ibss_htmode="HT40-";; + 1) bss_htmode="HT40+" ;; + 0) bss_htmode="HT40-";; esac ;; *) case "$htmode" in - HT40+) ibss_htmode="HT40+";; - HT40-) ibss_htmode="HT40-";; + HT40+) bss_htmode="HT40+";; + HT40-) bss_htmode="HT40-";; *) if [ "$channel" -lt 7 ]; then - ibss_htmode="HT40+" + bss_htmode="HT40+" else - ibss_htmode="HT40-" + bss_htmode="HT40-" fi ;; esac ;; esac - [ "$auto_channel" -gt 0 ] && ibss_htmode="HT40+" + [ "$auto_channel" -gt 0 ] && bss_htmode="HT40+" ;; VHT80) - ibss_htmode="80MHZ" + bss_htmode="80MHZ" ;; NONE|NOHT) - ibss_htmode="NOHT" + bss_htmode="NOHT" ;; - *) ibss_htmode="" ;; + *) bss_htmode="" ;; esac } @@ -566,7 +566,7 @@ mac80211_setup_adhoc() { mcval= [ -n "$mcast_rate" ] && wpa_supplicant_add_rate mcval "$mcast_rate" - iw dev "$ifname" ibss join "$ssid" $freq $ibss_htmode fixed-freq $bssid \ + iw dev "$ifname" ibss join "$ssid" $freq $bss_htmode fixed-freq $bssid \ ${beacon_int:+beacon-interval $beacon_int} \ ${brstr:+basic-rates $brstr} \ ${mcval:+mcast-rate $mcval} \ @@ -612,7 +612,8 @@ mac80211_setup_vif() { mcval= [ -n "$mcast_rate" ] && wpa_supplicant_add_rate mcval "$mcast_rate" - iw dev "$ifname" mesh join "$mesh_id" ${mcval:+mcast-rate $mcval} + mac80211_setup_bss_htmode + iw dev "$ifname" mesh join "$mesh_id" freq "$freq" "$bss_htmode" ${mcval:+mcast-rate $mcval} fi for var in $MP_CONFIG_INT $MP_CONFIG_BOOL $MP_CONFIG_STRING; do @@ -622,7 +623,7 @@ mac80211_setup_vif() { ;; adhoc) wireless_vif_parse_encryption - mac80211_setup_adhoc_htmode + mac80211_setup_bss_htmode if [ "$wpa" -gt 0 -o "$auto_channel" -gt 0 ]; then mac80211_setup_supplicant || failed=1 else -- 2.3.0 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From daniel at makrotopia.org Fri May 6 12:53:49 2016 From: daniel at makrotopia.org (Daniel Golle) Date: Fri, 6 May 2016 17:53:49 +0100 Subject: [OpenWrt-Devel] [PATCH] mac80211.sh: add support of VHT80 for mesh In-Reply-To: <1462552517-1670-1-git-send-email-yeohchunyeow@gmail.com> References: <1462552517-1670-1-git-send-email-yeohchunyeow@gmail.com> Message-ID: <20160506165347.GA1710@makrotopia.org> Hi Chun-Yeow, On Sat, May 07, 2016 at 12:35:17AM +0800, Chun-Yeow Yeoh wrote: > Add support of VHT80 setting for mesh interface > > Signed-off-by: Chun-Yeow Yeoh > --- > .../mac80211/files/lib/netifd/wireless/mac80211.sh | 33 +++++++++++----------- > 1 file changed, 17 insertions(+), 16 deletions(-) > > diff --git a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh > index 02c195e..d680ac2 100644 > --- a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh > +++ b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh > @@ -473,7 +473,7 @@ mac80211_prepare_vif() { > esac > > case "$mode" in > - monitor|mesh) > + monitor) > [ "$auto_channel" -gt 0 ] || iw dev "$ifname" set channel "$channel" $htmode > ;; > esac > [...] > @@ -566,7 +566,7 @@ mac80211_setup_adhoc() { > mcval= > [ -n "$mcast_rate" ] && wpa_supplicant_add_rate mcval "$mcast_rate" > > - iw dev "$ifname" ibss join "$ssid" $freq $ibss_htmode fixed-freq $bssid \ > + iw dev "$ifname" ibss join "$ssid" $freq $bss_htmode fixed-freq $bssid \ > ${beacon_int:+beacon-interval $beacon_int} \ > ${brstr:+basic-rates $brstr} \ > ${mcval:+mcast-rate $mcval} \ > @@ -612,7 +612,8 @@ mac80211_setup_vif() { > mcval= > [ -n "$mcast_rate" ] && wpa_supplicant_add_rate mcval "$mcast_rate" > > - iw dev "$ifname" mesh join "$mesh_id" ${mcval:+mcast-rate $mcval} > + mac80211_setup_bss_htmode have you tested this with authsae AND wpa_supplicant as well? I haven't look into it but suspect that wpa_supplicant might expect those things to be set via its configuration file instead of using iw dev ... Cheers Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From yeohchunyeow at gmail.com Fri May 6 13:01:30 2016 From: yeohchunyeow at gmail.com (Yeoh Chun-Yeow) Date: Sat, 7 May 2016 01:01:30 +0800 Subject: [OpenWrt-Devel] [PATCH] mac80211.sh: add support of VHT80 for mesh In-Reply-To: <20160506165347.GA1710@makrotopia.org> References: <1462552517-1670-1-git-send-email-yeohchunyeow@gmail.com> <20160506165347.GA1710@makrotopia.org> Message-ID: authsae and wpa_supplicant only trigger if secured mesh. wpa_supplicant should work correctly for VHT80 but don't think authsae. But this patch is intended to allow open mesh to support VHT80. Thanks ---- Chun-Yeow On Sat, May 7, 2016 at 12:53 AM, Daniel Golle wrote: > Hi Chun-Yeow, > > On Sat, May 07, 2016 at 12:35:17AM +0800, Chun-Yeow Yeoh wrote: >> Add support of VHT80 setting for mesh interface >> >> Signed-off-by: Chun-Yeow Yeoh >> --- >> .../mac80211/files/lib/netifd/wireless/mac80211.sh | 33 +++++++++++----------- >> 1 file changed, 17 insertions(+), 16 deletions(-) >> >> diff --git a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh >> index 02c195e..d680ac2 100644 >> --- a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh >> +++ b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh >> @@ -473,7 +473,7 @@ mac80211_prepare_vif() { >> esac >> >> case "$mode" in >> - monitor|mesh) >> + monitor) >> [ "$auto_channel" -gt 0 ] || iw dev "$ifname" set channel "$channel" $htmode >> ;; >> esac >> [...] > >> @@ -566,7 +566,7 @@ mac80211_setup_adhoc() { >> mcval= >> [ -n "$mcast_rate" ] && wpa_supplicant_add_rate mcval "$mcast_rate" >> >> - iw dev "$ifname" ibss join "$ssid" $freq $ibss_htmode fixed-freq $bssid \ >> + iw dev "$ifname" ibss join "$ssid" $freq $bss_htmode fixed-freq $bssid \ >> ${beacon_int:+beacon-interval $beacon_int} \ >> ${brstr:+basic-rates $brstr} \ >> ${mcval:+mcast-rate $mcval} \ >> @@ -612,7 +612,8 @@ mac80211_setup_vif() { >> mcval= >> [ -n "$mcast_rate" ] && wpa_supplicant_add_rate mcval "$mcast_rate" >> >> - iw dev "$ifname" mesh join "$mesh_id" ${mcval:+mcast-rate $mcval} >> + mac80211_setup_bss_htmode > > have you tested this with authsae AND wpa_supplicant as well? > I haven't look into it but suspect that wpa_supplicant might expect > those things to be set via its configuration file instead of using > iw dev ... > > Cheers > > Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From daniel at makrotopia.org Fri May 6 13:16:51 2016 From: daniel at makrotopia.org (Daniel Golle) Date: Fri, 6 May 2016 18:16:51 +0100 Subject: [OpenWrt-Devel] [PATCH] mac80211.sh: add support of VHT80 for mesh In-Reply-To: References: <1462552517-1670-1-git-send-email-yeohchunyeow@gmail.com> <20160506165347.GA1710@makrotopia.org> Message-ID: <20160506171651.GB1710@makrotopia.org> On Sat, May 07, 2016 at 01:01:30AM +0800, Yeoh Chun-Yeow wrote: > authsae and wpa_supplicant only trigger if secured mesh. > wpa_supplicant should work correctly for VHT80 but don't think > authsae. > > But this patch is intended to allow open mesh to support VHT80. So maybe only enable it if $key isn't set and leave a comment in place that testing is needed before enabling it for authsae and/or wpa_supplicant. It might well break authsae and wpa_supplicant already handles up to VHT160, see http://w1.fi/cgit/hostap/commit/wpa_supplicant/mesh.c?id=a65efbfb243dda41518720f14724db055444bb56 and http://w1.fi/cgit/hostap/commit/wpa_supplicant/mesh.c?id=d06a35052f182d3aebc7b7e1c780cca7b386997d so no need to set it here again. > > Thanks > > ---- > Chun-Yeow > > On Sat, May 7, 2016 at 12:53 AM, Daniel Golle wrote: > > Hi Chun-Yeow, > > > > On Sat, May 07, 2016 at 12:35:17AM +0800, Chun-Yeow Yeoh wrote: > >> Add support of VHT80 setting for mesh interface > >> > >> Signed-off-by: Chun-Yeow Yeoh > >> --- > >> .../mac80211/files/lib/netifd/wireless/mac80211.sh | 33 +++++++++++----------- > >> 1 file changed, 17 insertions(+), 16 deletions(-) > >> > >> diff --git a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh > >> index 02c195e..d680ac2 100644 > >> --- a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh > >> +++ b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh > >> @@ -473,7 +473,7 @@ mac80211_prepare_vif() { > >> esac > >> > >> case "$mode" in > >> - monitor|mesh) > >> + monitor) > >> [ "$auto_channel" -gt 0 ] || iw dev "$ifname" set channel "$channel" $htmode > >> ;; > >> esac > >> [...] > > > >> @@ -566,7 +566,7 @@ mac80211_setup_adhoc() { > >> mcval= > >> [ -n "$mcast_rate" ] && wpa_supplicant_add_rate mcval "$mcast_rate" > >> > >> - iw dev "$ifname" ibss join "$ssid" $freq $ibss_htmode fixed-freq $bssid \ > >> + iw dev "$ifname" ibss join "$ssid" $freq $bss_htmode fixed-freq $bssid \ > >> ${beacon_int:+beacon-interval $beacon_int} \ > >> ${brstr:+basic-rates $brstr} \ > >> ${mcval:+mcast-rate $mcval} \ > >> @@ -612,7 +612,8 @@ mac80211_setup_vif() { > >> mcval= > >> [ -n "$mcast_rate" ] && wpa_supplicant_add_rate mcval "$mcast_rate" > >> > >> - iw dev "$ifname" mesh join "$mesh_id" ${mcval:+mcast-rate $mcval} > >> + mac80211_setup_bss_htmode > > > > have you tested this with authsae AND wpa_supplicant as well? > > I haven't look into it but suspect that wpa_supplicant might expect > > those things to be set via its configuration file instead of using > > iw dev ... > > > > Cheers > > > > Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From yeohchunyeow at gmail.com Fri May 6 13:31:24 2016 From: yeohchunyeow at gmail.com (Yeoh Chun-Yeow) Date: Sat, 7 May 2016 01:31:24 +0800 Subject: [OpenWrt-Devel] [PATCH] mac80211.sh: add support of VHT80 for mesh In-Reply-To: <20160506171651.GB1710@makrotopia.org> References: <1462552517-1670-1-git-send-email-yeohchunyeow@gmail.com> <20160506165347.GA1710@makrotopia.org> <20160506171651.GB1710@makrotopia.org> Message-ID: I think that it is alright if we solely depends on the wap_supplicant for both open mesh and secured mesh. ---- Chun-Yeow On Sat, May 7, 2016 at 1:16 AM, Daniel Golle wrote: > On Sat, May 07, 2016 at 01:01:30AM +0800, Yeoh Chun-Yeow wrote: >> authsae and wpa_supplicant only trigger if secured mesh. >> wpa_supplicant should work correctly for VHT80 but don't think >> authsae. >> >> But this patch is intended to allow open mesh to support VHT80. > So maybe only enable it if $key isn't set and leave a comment in place > that testing is needed before enabling it for authsae and/or > wpa_supplicant. > It might well break authsae and wpa_supplicant already handles up to > VHT160, see > http://w1.fi/cgit/hostap/commit/wpa_supplicant/mesh.c?id=a65efbfb243dda41518720f14724db055444bb56 > and > http://w1.fi/cgit/hostap/commit/wpa_supplicant/mesh.c?id=d06a35052f182d3aebc7b7e1c780cca7b386997d > so no need to set it here again. > > >> >> Thanks >> >> ---- >> Chun-Yeow >> >> On Sat, May 7, 2016 at 12:53 AM, Daniel Golle wrote: >> > Hi Chun-Yeow, >> > >> > On Sat, May 07, 2016 at 12:35:17AM +0800, Chun-Yeow Yeoh wrote: >> >> Add support of VHT80 setting for mesh interface >> >> >> >> Signed-off-by: Chun-Yeow Yeoh >> >> --- >> >> .../mac80211/files/lib/netifd/wireless/mac80211.sh | 33 +++++++++++----------- >> >> 1 file changed, 17 insertions(+), 16 deletions(-) >> >> >> >> diff --git a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh >> >> index 02c195e..d680ac2 100644 >> >> --- a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh >> >> +++ b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh >> >> @@ -473,7 +473,7 @@ mac80211_prepare_vif() { >> >> esac >> >> >> >> case "$mode" in >> >> - monitor|mesh) >> >> + monitor) >> >> [ "$auto_channel" -gt 0 ] || iw dev "$ifname" set channel "$channel" $htmode >> >> ;; >> >> esac >> >> [...] >> > >> >> @@ -566,7 +566,7 @@ mac80211_setup_adhoc() { >> >> mcval= >> >> [ -n "$mcast_rate" ] && wpa_supplicant_add_rate mcval "$mcast_rate" >> >> >> >> - iw dev "$ifname" ibss join "$ssid" $freq $ibss_htmode fixed-freq $bssid \ >> >> + iw dev "$ifname" ibss join "$ssid" $freq $bss_htmode fixed-freq $bssid \ >> >> ${beacon_int:+beacon-interval $beacon_int} \ >> >> ${brstr:+basic-rates $brstr} \ >> >> ${mcval:+mcast-rate $mcval} \ >> >> @@ -612,7 +612,8 @@ mac80211_setup_vif() { >> >> mcval= >> >> [ -n "$mcast_rate" ] && wpa_supplicant_add_rate mcval "$mcast_rate" >> >> >> >> - iw dev "$ifname" mesh join "$mesh_id" ${mcval:+mcast-rate $mcval} >> >> + mac80211_setup_bss_htmode >> > >> > have you tested this with authsae AND wpa_supplicant as well? >> > I haven't look into it but suspect that wpa_supplicant might expect >> > those things to be set via its configuration file instead of using >> > iw dev ... >> > >> > Cheers >> > >> > Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Fri May 6 13:32:16 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Fri, 6 May 2016 13:32:16 -0400 Subject: [OpenWrt-Devel] =?utf-8?q?Guest_who_is_using_openwrt_=28was_Fwd?= =?utf-8?q?=3A_Build_failed_in_Jenkins=3A_PandoraBoxFireware_=C2=BB_Pandor?= =?utf-8?b?YUJveF9CdWlsZF9CZXRhIMK7IE1UNzYyOCxMaW51eCAjMTQp?= In-Reply-To: <583291174.21.1462555400874.JavaMail.jenkins@Arylo-CI-Server> References: <583291174.21.1462555400874.JavaMail.jenkins@Arylo-CI-Server> Message-ID: <572CD520.7010204@daniel.thecshore.com> Hi List, For your amusement. Anyone want to PandoraBox is using OpenWrt ;-) (That is I have no affilation with PandoraBox; their CI screwed up). Regards, Daniel -------- Forwarded Message -------- Subject: Build failed in Jenkins: PandoraBoxFireware ? PandoraBox_Build_Beta ? MT7628,Linux #14 Date: Sat, 7 May 2016 01:23:20 +0800 (CST) From: Pandorabox Continuous Integration To: Lintel , Shawn , jo at mein.io, arylo.open at gmail.com, hannu.nyman at iki.fi, christian.schoenebeck at gmail.com, openwrt at daniel.thecshore.com, luca.debernardi at gmail.com, banglang.huang at foxmail.com, freifunk at it-solutions.geroedel.de, kevin at koconnor.net See Changes: [kevin] luci-mod-admin-full: Add option to set anonymous_identity field [openwrt] luci-base: utils: Make checklib return a boolean [christian.schoenebeck] fix problem not correctly handling "Bind Network" field [hannu.nyman] luci-app-transmission: remove dependency on transmission-daemon [hannu.nyman] luci-base: read odhcpd leasefile location via uci [luca.debernardi] luci-mod-admin-full: fix wrong dsl stats visualization [jo] luci-base: fix luci.model.network.ignore_interface() [jo] luci-base: add more ignore patterns to luci.model.network [jo] luci-base: fix syntax error in luci.model.network [hannu.nyman] luci-app-adblock: match adblock 1.1.0 [hannu.nyman] luci-app-adblock: adjust to change in option name [hannu.nyman] i18n: sync translations [hannu.nyman] luci-mod-admin-full: dnsmasq options quietdhcp and sequential_ip [freifunk] freifunk-profiles: remove depreciated profiles ------------------------------------------ [...truncated 280325 lines...] #define __NR_recvmmsg (__NR_Linux + 335) ^ In file included from /mnt/sdb:24:0, from /mnt/sdb:22, from /mnt/sdb:61, from util/util.h:58, from tests/dso-data.c:1: /mnt/sdb:1017:0: note: this is the location of the previous definition #define __NR_recvmmsg (4000 + 335) ^ In file included from util/../perf.h:4:0, from util/symbol.h:8, from tests/dso-data.c:10: /mnt/sdb:359:0: warning: "__NR_fanotify_init" redefined [enabled by default] #define __NR_fanotify_init (__NR_Linux + 336) ^ In file included from /mnt/sdb:24:0, from /mnt/sdb:22, from /mnt/sdb:61, from util/util.h:58, from tests/dso-data.c:1: /mnt/sdb:1020:0: note: this is the location of the previous definition #define __NR_fanotify_init (4000 + 336) ^ In file included from util/../perf.h:4:0, from util/symbol.h:8, from tests/dso-data.c:10: /mnt/sdb:360:0: warning: "__NR_fanotify_mark" redefined [enabled by default] #define __NR_fanotify_mark (__NR_Linux + 337) ^ In file included from /mnt/sdb:24:0, from /mnt/sdb:22, from /mnt/sdb:61, from util/util.h:58, from tests/dso-data.c:1: /mnt/sdb:1023:0: note: this is the location of the previous definition #define __NR_fanotify_mark (4000 + 337) ^ In file included from util/../perf.h:4:0, from util/symbol.h:8, from tests/dso-data.c:10: /mnt/sdb:361:0: warning: "__NR_prlimit64" redefined [enabled by default] #define __NR_prlimit64 (__NR_Linux + 338) ^ In file included from /mnt/sdb:24:0, from /mnt/sdb:22, from /mnt/sdb:61, from util/util.h:58, from tests/dso-data.c:1: /mnt/sdb:1026:0: note: this is the location of the previous definition #define __NR_prlimit64 (4000 + 338) ^ In file included from util/../perf.h:4:0, from util/symbol.h:8, from tests/dso-data.c:10: /mnt/sdb:362:0: warning: "__NR_name_to_handle_at" redefined [enabled by default] #define __NR_name_to_handle_at (__NR_Linux + 339) ^ In file included from /mnt/sdb:24:0, from /mnt/sdb:22, from /mnt/sdb:61, from util/util.h:58, from tests/dso-data.c:1: /mnt/sdb:1029:0: note: this is the location of the previous definition #define __NR_name_to_handle_at (4000 + 339) ^ In file included from util/../perf.h:4:0, from util/symbol.h:8, from tests/dso-data.c:10: /mnt/sdb:363:0: warning: "__NR_open_by_handle_at" redefined [enabled by default] #define __NR_open_by_handle_at (__NR_Linux + 340) ^ In file included from /mnt/sdb:24:0, from /mnt/sdb:22, from /mnt/sdb:61, from util/util.h:58, from tests/dso-data.c:1: /mnt/sdb:1032:0: note: this is the location of the previous definition #define __NR_open_by_handle_at (4000 + 340) ^ In file included from util/../perf.h:4:0, from util/symbol.h:8, from tests/dso-data.c:10: /mnt/sdb:364:0: warning: "__NR_clock_adjtime" redefined [enabled by default] #define __NR_clock_adjtime (__NR_Linux + 341) ^ In file included from /mnt/sdb:24:0, from /mnt/sdb:22, from /mnt/sdb:61, from util/util.h:58, from tests/dso-data.c:1: /mnt/sdb:1035:0: note: this is the location of the previous definition #define __NR_clock_adjtime (4000 + 341) ^ In file included from util/../perf.h:4:0, from util/symbol.h:8, from tests/dso-data.c:10: /mnt/sdb:365:0: warning: "__NR_syncfs" redefined [enabled by default] #define __NR_syncfs (__NR_Linux + 342) ^ In file included from /mnt/sdb:24:0, from /mnt/sdb:22, from /mnt/sdb:61, from util/util.h:58, from tests/dso-data.c:1: /mnt/sdb:1038:0: note: this is the location of the previous definition #define __NR_syncfs (4000 + 342) ^ In file included from util/../perf.h:4:0, from util/symbol.h:8, from tests/dso-data.c:10: /mnt/sdb:366:0: warning: "__NR_sendmmsg" redefined [enabled by default] #define __NR_sendmmsg (__NR_Linux + 343) ^ In file included from /mnt/sdb:24:0, from /mnt/sdb:22, from /mnt/sdb:61, from util/util.h:58, from tests/dso-data.c:1: /mnt/sdb:1041:0: note: this is the location of the previous definition #define __NR_sendmmsg (4000 + 343) ^ In file included from util/../perf.h:4:0, from util/symbol.h:8, from tests/dso-data.c:10: /mnt/sdb:367:0: warning: "__NR_setns" redefined [enabled by default] #define __NR_setns (__NR_Linux + 344) ^ In file included from /mnt/sdb:24:0, from /mnt/sdb:22, from /mnt/sdb:61, from util/util.h:58, from tests/dso-data.c:1: /mnt/sdb:1044:0: note: this is the location of the previous definition #define __NR_setns (4000 + 344) ^ In file included from util/../perf.h:4:0, from util/symbol.h:8, from tests/dso-data.c:10: /mnt/sdb:368:0: warning: "__NR_process_vm_readv" redefined [enabled by default] #define __NR_process_vm_readv (__NR_Linux + 345) ^ In file included from /mnt/sdb:24:0, from /mnt/sdb:22, from /mnt/sdb:61, from util/util.h:58, from tests/dso-data.c:1: /mnt/sdb:1047:0: note: this is the location of the previous definition #define __NR_process_vm_readv (4000 + 345) ^ In file included from util/../perf.h:4:0, from util/symbol.h:8, from tests/dso-data.c:10: /mnt/sdb:369:0: warning: "__NR_process_vm_writev" redefined [enabled by default] #define __NR_process_vm_writev (__NR_Linux + 346) ^ In file included from /mnt/sdb:24:0, from /mnt/sdb:22, from /mnt/sdb:61, from util/util.h:58, from tests/dso-data.c:1: /mnt/sdb:1050:0: note: this is the location of the previous definition #define __NR_process_vm_writev (4000 + 346) ^ In file included from util/../perf.h:4:0, from util/symbol.h:8, from tests/dso-data.c:10: /mnt/sdb:370:0: warning: "__NR_kcmp" redefined [enabled by default] #define __NR_kcmp (__NR_Linux + 347) ^ In file included from /mnt/sdb:24:0, from /mnt/sdb:22, from /mnt/sdb:61, from util/util.h:58, from tests/dso-data.c:1: /mnt/sdb:1053:0: note: this is the location of the previous definition #define __NR_kcmp (4000 + 347) ^ In file included from util/../perf.h:4:0, from util/symbol.h:8, from tests/dso-data.c:10: /mnt/sdb:371:0: warning: "__NR_finit_module" redefined [enabled by default] #define __NR_finit_module (__NR_Linux + 348) ^ In file included from /mnt/sdb:24:0, from /mnt/sdb:22, from /mnt/sdb:61, from util/util.h:58, from tests/dso-data.c:1: /mnt/sdb:1056:0: note: this is the location of the previous definition #define __NR_finit_module (4000 + 348) ^ mipsel-openwrt-linux-uclibc-gcc -o tests/attr.o -c -Os -pipe -mno-branch-likely -mips32r2 -mtune=24kec -mdsp -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -Iutil/include -Iarch/mips/include -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -Iutil -Iutil -I. -I../lib/traceevent/ -I../lib/ -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DLIBELF_SUPPORT -DLIBELF_MMAP -DNO_LIBPERL -DNO_LIBPYTHON -DHAVE_STRLCPY -DHAVE_ON_EXIT \ '-DBINDIR="/usr/bin"' -DPYTHON='"'/mnt/sdb \ tests/attr.c mipsel-openwrt-linux-uclibc-gcc -o tests/vmlinux-kallsyms.o -c -Os -pipe -mno-branch-likely -mips32r2 -mtune=24kec -mdsp -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -Iutil/include -Iarch/mips/include -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -Iutil -Iutil -I. -I../lib/traceevent/ -I../lib/ -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DLIBELF_SUPPORT -DLIBELF_MMAP -DNO_LIBPERL -DNO_LIBPYTHON -DHAVE_STRLCPY -DHAVE_ON_EXIT tests/vmlinux-kallsyms.c mipsel-openwrt-linux-uclibc-gcc -o tests/open-syscall.o -c -Os -pipe -mno-branch-likely -mips32r2 -mtune=24kec -mdsp -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -Iutil/include -Iarch/mips/include -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -Iutil -Iutil -I. -I../lib/traceevent/ -I../lib/ -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DLIBELF_SUPPORT -DLIBELF_MMAP -DNO_LIBPERL -DNO_LIBPYTHON -DHAVE_STRLCPY -DHAVE_ON_EXIT tests/open-syscall.c mipsel-openwrt-linux-uclibc-gcc -o tests/open-syscall-all-cpus.o -c -Os -pipe -mno-branch-likely -mips32r2 -mtune=24kec -mdsp -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -Iutil/include -Iarch/mips/include -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -Iutil -Iutil -I. -I../lib/traceevent/ -I../lib/ -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DLIBELF_SUPPORT -DLIBELF_MMAP -DNO_LIBPERL -DNO_LIBPYTHON -DHAVE_STRLCPY -DHAVE_ON_EXIT tests/open-syscall-all-cpus.c mipsel-openwrt-linux-uclibc-gcc -o tests/open-syscall-tp-fields.o -c -Os -pipe -mno-branch-likely -mips32r2 -mtune=24kec -mdsp -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -Iutil/include -Iarch/mips/include -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -Iutil -Iutil -I. -I../lib/traceevent/ -I../lib/ -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DLIBELF_SUPPORT -DLIBELF_MMAP -DNO_LIBPERL -DNO_LIBPYTHON -DHAVE_STRLCPY -DHAVE_ON_EXIT tests/open-syscall-tp-fields.c mipsel-openwrt-linux-uclibc-gcc -o tests/mmap-basic.o -c -Os -pipe -mno-branch-likely -mips32r2 -mtune=24kec -mdsp -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -Iutil/include -Iarch/mips/include -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -Iutil -Iutil -I. -I../lib/traceevent/ -I../lib/ -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DLIBELF_SUPPORT -DLIBELF_MMAP -DNO_LIBPERL -DNO_LIBPYTHON -DHAVE_STRLCPY -DHAVE_ON_EXIT tests/mmap-basic.c mipsel-openwrt-linux-uclibc-gcc -o tests/perf-record.o -c -Os -pipe -mno-branch-likely -mips32r2 -mtune=24kec -mdsp -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -Iutil/include -Iarch/mips/include -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -Iutil -Iutil -I. -I../lib/traceevent/ -I../lib/ -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DLIBELF_SUPPORT -DLIBELF_MMAP -DNO_LIBPERL -DNO_LIBPYTHON -DHAVE_STRLCPY -DHAVE_ON_EXIT tests/perf-record.c mipsel-openwrt-linux-uclibc-gcc -o tests/rdpmc.o -c -Os -pipe -mno-branch-likely -mips32r2 -mtune=24kec -mdsp -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -Iutil/include -Iarch/mips/include -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -Iutil -Iutil -I. -I../lib/traceevent/ -I../lib/ -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DLIBELF_SUPPORT -DLIBELF_MMAP -DNO_LIBPERL -DNO_LIBPYTHON -DHAVE_STRLCPY -DHAVE_ON_EXIT tests/rdpmc.c mipsel-openwrt-linux-uclibc-gcc -o tests/evsel-roundtrip-name.o -c -Os -pipe -mno-branch-likely -mips32r2 -mtune=24kec -mdsp -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -Iutil/include -Iarch/mips/include -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -Iutil -Iutil -I. -I../lib/traceevent/ -I../lib/ -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DLIBELF_SUPPORT -DLIBELF_MMAP -DNO_LIBPERL -DNO_LIBPYTHON -DHAVE_STRLCPY -DHAVE_ON_EXIT tests/evsel-roundtrip-name.c mipsel-openwrt-linux-uclibc-gcc -o tests/evsel-tp-sched.o -c -Os -pipe -mno-branch-likely -mips32r2 -mtune=24kec -mdsp -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -Iutil/include -Iarch/mips/include -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -Iutil -Iutil -I. -I../lib/traceevent/ -I../lib/ -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DLIBELF_SUPPORT -DLIBELF_MMAP -DNO_LIBPERL -DNO_LIBPYTHON -DHAVE_STRLCPY -DHAVE_ON_EXIT tests/evsel-tp-sched.c mipsel-openwrt-linux-uclibc-gcc -o tests/pmu.o -c -Os -pipe -mno-branch-likely -mips32r2 -mtune=24kec -mdsp -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -Iutil/include -Iarch/mips/include -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -Iutil -Iutil -I. -I../lib/traceevent/ -I../lib/ -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DLIBELF_SUPPORT -DLIBELF_MMAP -DNO_LIBPERL -DNO_LIBPYTHON -DHAVE_STRLCPY -DHAVE_ON_EXIT tests/pmu.c mipsel-openwrt-linux-uclibc-gcc -o tests/hists_link.o -c -Os -pipe -mno-branch-likely -mips32r2 -mtune=24kec -mdsp -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -Iutil/include -Iarch/mips/include -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -Iutil -Iutil -I. -I../lib/traceevent/ -I../lib/ -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DLIBELF_SUPPORT -DLIBELF_MMAP -DNO_LIBPERL -DNO_LIBPYTHON -DHAVE_STRLCPY -DHAVE_ON_EXIT tests/hists_link.c mipsel-openwrt-linux-uclibc-gcc -o tests/python-use.o -c -Os -pipe -mno-branch-likely -mips32r2 -mtune=24kec -mdsp -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -Iutil/include -Iarch/mips/include -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -Iutil -Iutil -I. -I../lib/traceevent/ -I../lib/ -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DLIBELF_SUPPORT -DLIBELF_MMAP -DNO_LIBPERL -DNO_LIBPYTHON -DHAVE_STRLCPY -DHAVE_ON_EXIT \ -DPYTHONPATH='"python"' \ -DPYTHON='"'/mnt/sdb \ tests/python-use.c mipsel-openwrt-linux-uclibc-gcc -o tests/bp_signal.o -c -Os -pipe -mno-branch-likely -mips32r2 -mtune=24kec -mdsp -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -Iutil/include -Iarch/mips/include -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -Iutil -Iutil -I. -I../lib/traceevent/ -I../lib/ -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DLIBELF_SUPPORT -DLIBELF_MMAP -DNO_LIBPERL -DNO_LIBPYTHON -DHAVE_STRLCPY -DHAVE_ON_EXIT tests/bp_signal.c mipsel-openwrt-linux-uclibc-gcc -o tests/bp_signal_overflow.o -c -Os -pipe -mno-branch-likely -mips32r2 -mtune=24kec -mdsp -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -Iutil/include -Iarch/mips/include -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -Iutil -Iutil -I. -I../lib/traceevent/ -I../lib/ -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DLIBELF_SUPPORT -DLIBELF_MMAP -DNO_LIBPERL -DNO_LIBPYTHON -DHAVE_STRLCPY -DHAVE_ON_EXIT tests/bp_signal_overflow.c mipsel-openwrt-linux-uclibc-gcc -o tests/task-exit.o -c -Os -pipe -mno-branch-likely -mips32r2 -mtune=24kec -mdsp -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -Iutil/include -Iarch/mips/include -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -Iutil -Iutil -I. -I../lib/traceevent/ -I../lib/ -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DLIBELF_SUPPORT -DLIBELF_MMAP -DNO_LIBPERL -DNO_LIBPYTHON -DHAVE_STRLCPY -DHAVE_ON_EXIT tests/task-exit.c mipsel-openwrt-linux-uclibc-gcc -o tests/sw-clock.o -c -Os -pipe -mno-branch-likely -mips32r2 -mtune=24kec -mdsp -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -Iutil/include -Iarch/mips/include -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -Iutil -Iutil -I. -I../lib/traceevent/ -I../lib/ -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DLIBELF_SUPPORT -DLIBELF_MMAP -DNO_LIBPERL -DNO_LIBPYTHON -DHAVE_STRLCPY -DHAVE_ON_EXIT tests/sw-clock.c rm -f libperf.a && mipsel-openwrt-linux-uclibc-ar rcs libperf.a util/abspath.o util/alias.o util/annotate.o util/build-id.o util/config.o util/ctype.o util/sysfs.o util/pmu.o util/environment.o util/event.o util/evlist.o util/evsel.o util/exec_cmd.o util/help.o util/levenshtein.o util/parse-options.o util/parse-events.o util/path.o util/rbtree.o util/bitmap.o util/hweight.o util/run-command.o util/quote.o util/strbuf.o util/string.o util/strlist.o util/strfilter.o util/top.o util/usage.o util/wrapper.o util/sigchain.o util/dso.o util/symbol.o util/symbol-elf.o util/color.o util/pager.o util/header.o util/callchain.o util/values.o util/debug.o util/machine.o util/map.o util/pstack.o util/session.o util/thread.o util/thread_map.o util/trace-event-parse.o util/parse-events-flex.o util/parse-events-bison.o util/pmu-flex.o util/pmu-bison.o util/trace-event-read.o util/trace-event-info.o util/trace-event-scripting.o util/svghelper.o util/sort.o util/hist.o util/probe-event.o util/util.o util/xyarray.o util/cpumap.o util/cgroup.o util/target.o util/rblist.o util/intlist.o util/vdso.o util/stat.o ui/setup.o ui/helpline.o ui/progress.o ui/util.o ui/hist.o ui/stdio/hist.o arch/common.o tests/parse-events.o tests/dso-data.o tests/attr.o tests/vmlinux-kallsyms.o tests/open-syscall.o tests/open-syscall-all-cpus.o tests/open-syscall-tp-fields.o tests/mmap-basic.o tests/perf-record.o tests/rdpmc.o tests/evsel-roundtrip-name.o tests/evsel-tp-sched.o tests/pmu.o tests/hists_link.o tests/python-use.o tests/bp_signal.o tests/bp_signal_overflow.o tests/task-exit.o tests/sw-clock.o make -C ../lib/lk/ O= liblk.a make[5]: Entering directory `/mnt/sdb mipsel-openwrt-linux-uclibc-gcc -o debugfs.o -c -Os -pipe -mno-branch-likely -mips32r2 -mtune=24kec -mdsp -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 debugfs.c rm -f liblk.a && ar rcs liblk.a debugfs.o make[5]: Leaving directory `/mnt/sdb make -C ../lib/traceevent/ O= libtraceevent.a make[5]: Entering directory `/mnt/sdb * new build flags or cross compiler ( mipsel-openwrt-linux-uclibc-gcc -c -Os -pipe -mno-branch-likely -mips32r2 -mtune=24kec -mdsp -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I. -D_GNU_SOURCE -std=gnu99 -fPIC /mnt/sdb -o event-parse.o) ( mipsel-openwrt-linux-uclibc-gcc -c -Os -pipe -mno-branch-likely -mips32r2 -mtune=24kec -mdsp -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I. -D_GNU_SOURCE -std=gnu99 -fPIC /mnt/sdb -o trace-seq.o) ( mipsel-openwrt-linux-uclibc-gcc -c -Os -pipe -mno-branch-likely -mips32r2 -mtune=24kec -mdsp -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I. -D_GNU_SOURCE -std=gnu99 -fPIC /mnt/sdb -o parse-filter.o) ( mipsel-openwrt-linux-uclibc-gcc -c -Os -pipe -mno-branch-likely -mips32r2 -mtune=24kec -mdsp -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I. -D_GNU_SOURCE -std=gnu99 -fPIC /mnt/sdb -o parse-utils.o) ( rm -f libtraceevent.a; mipsel-openwrt-linux-uclibc-ar rcs libtraceevent.a event-parse.o trace-seq.o parse-filter.o parse-utils.o) make[5]: Leaving directory `/mnt/sdb mipsel-openwrt-linux-uclibc-gcc -Os -pipe -mno-branch-likely -mips32r2 -mtune=24kec -mdsp -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -Iutil/include -Iarch/mips/include -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -I/mnt/sdb -Iutil -Iutil -I. -I../lib/traceevent/ -I../lib/ -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DLIBELF_SUPPORT -DLIBELF_MMAP -DNO_LIBPERL -DNO_LIBPYTHON -DHAVE_STRLCPY -DHAVE_ON_EXIT -L/mnt/sdb -L/mnt/sdb -L/mnt/sdb -L/mnt/sdb perf.o \ builtin-annotate.o builtin-bench.o bench/sched-messaging.o bench/sched-pipe.o bench/mem-memcpy.o bench/mem-memset.o builtin-diff.o builtin-evlist.o builtin-help.o builtin-sched.o builtin-buildid-list.o builtin-buildid-cache.o builtin-list.o builtin-record.o builtin-report.o builtin-stat.o builtin-timechart.o builtin-top.o builtin-script.o builtin-probe.o builtin-kmem.o builtin-lock.o builtin-kvm.o builtin-inject.o tests/builtin-test.o builtin-mem.o -Wl,--whole-archive libperf.a ../lib/lk/liblk.a ../lib/traceevent/libtraceevent.a -Wl,--no-whole-archive -Wl,--start-group -lpthread -lrt -lelf -lm -lbfd -Wl,--end-group -o perf install 'perf-archive.sh' 'perf-archive' make[4]: Leaving directory `/mnt/sdb touch /mnt/sdb mkdir -p /mnt/sdb /mnt/sdb /mnt/sdb install -d -m0755 /mnt/sdb install -m0755 /mnt/sdb /mnt/sdb find /mnt/sdb -name 'CVS' -o -name '.svn' -o -name '.#*' -o -name '*~'| xargs -r rm -rf Package perf-pandorabox is missing dependencies for the following libraries: libelf.so.1 make[3]: *** [/mnt/sdb Error 1 make[3]: Leaving directory `/mnt/sdb make[2]: *** [package/pandorabox/lang/perf-pandorabox/compile] Error 2 make[2]: Leaving directory `/mnt/sdb make[1]: *** [/mnt/sdb Error 2 make[1]: Leaving directory `/mnt/sdb make: *** [world] ?? 2 Build step 'Execute shell' marked build as failure Discard old builds... _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From leroi.lists at gmail.com Fri May 6 14:43:54 2016 From: leroi.lists at gmail.com (Roman Yeryomin) Date: Fri, 6 May 2016 21:43:54 +0300 Subject: [OpenWrt-Devel] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood) In-Reply-To: <20160506144740.210901f5@redhat.com> References: <1462125592.5535.194.camel@edumazet-glaptop3.roam.corp.google.com> <865DA393-262D-40B6-A9D3-1B978CD5F6C6@gmail.com> <1462128385.5535.200.camel@edumazet-glaptop3.roam.corp.google.com> <1462136140.5535.219.camel@edumazet-glaptop3.roam.corp.google.com> <1462201620.5535.250.camel@edumazet-glaptop3.roam.corp.google.com> <1462205669.5535.254.camel@edumazet-glaptop3.roam.corp.google.com> <1462464776.13075.18.camel@edumazet-glaptop3.roam.corp.google.com> <1462476207.13075.20.camel@edumazet-glaptop3.roam.corp.google.com> <20160506114243.4eb4f95e@redhat.com> <20160506144740.210901f5@redhat.com> Message-ID: On 6 May 2016 at 15:47, Jesper Dangaard Brouer wrote: > > I've created a OpenWRT ticket[1] on this issue, as it seems that someone[2] > closed Felix'es OpenWRT email account (bad choice! emails bouncing). > Sounds like OpenWRT and the LEDE https://www.lede-project.org/ project > is in some kind of conflict. > > OpenWRT ticket [1] https://dev.openwrt.org/ticket/22349 > > [2] http://thread.gmane.org/gmane.comp.embedded.openwrt.devel/40298/focus=40335 OK, so, after porting the patch to 4.1 openwrt kernel and playing a bit with fq_codel limits I was able to get 420Mbps UDP like this: tc qdisc replace dev wlan0 parent :1 fq_codel flows 16 limit 256 This is certainly better than 30Mbps but still more than two times less than before (900). TCP also improved a little (550 to ~590). Felix, others, do you want to see the ported patch, maybe I did something wrong? Doesn't look like it will save ath10k from performance regression. > > On Fri, 6 May 2016 11:42:43 +0200 > Jesper Dangaard Brouer wrote: > >> Hi Felix, >> >> This is an important fix for OpenWRT, please read! >> >> OpenWRT changed the default fq_codel sch->limit from 10240 to 1024, >> without also adjusting q->flows_cnt. Eric explains below that you must >> also adjust the buckets (q->flows_cnt) for this not to break. (Just >> adjust it to 128) >> >> Problematic OpenWRT commit in question: >> http://git.openwrt.org/?p=openwrt.git;a=patch;h=12cd6578084e >> 12cd6578084e ("kernel: revert fq_codel quantum override to prevent it from causing too much cpu load with higher speed (#21326)") >> >> >> I also highly recommend you cherry-pick this very recent commit: >> net-next: 9d18562a2278 ("fq_codel: add batch ability to fq_codel_drop()") >> https://git.kernel.org/davem/net-next/c/9d18562a227 >> >> This should fix very high CPU usage in-case fq_codel goes into drop mode. >> The problem is that drop mode was considered rare, and implementation >> wise it was chosen to be more expensive (to save cycles on normal mode). >> Unfortunately is it easy to trigger with an UDP flood. Drop mode is >> especially expensive for smaller devices, as it scans a 4K big array, >> thus 64 cache misses for small devices! >> >> The fix is to allow drop-mode to bulk-drop more packets when entering >> drop-mode (default 64 bulk drop). That way we don't suddenly >> experience a significantly higher processing cost per packet, but >> instead can amortize this. >> >> To Eric, should we recommend OpenWRT to adjust default (max) 64 bulk >> drop, given we also recommend bucket size to be 128 ? (thus the amount >> of memory to scan is less, but their CPU is also much smaller). >> >> --Jesper >> >> >> On Thu, 05 May 2016 12:23:27 -0700 Eric Dumazet wrote: >> >> > On Thu, 2016-05-05 at 19:25 +0300, Roman Yeryomin wrote: >> > > On 5 May 2016 at 19:12, Eric Dumazet wrote: >> > > > On Thu, 2016-05-05 at 17:53 +0300, Roman Yeryomin wrote: >> > > > >> > > >> >> > > >> qdisc fq_codel 0: dev eth0 root refcnt 2 limit 1024p flows 1024 >> > > >> quantum 1514 target 5.0ms interval 100.0ms ecn >> > > >> Sent 12306 bytes 128 pkt (dropped 0, overlimits 0 requeues 0) >> > > >> backlog 0b 0p requeues 0 >> > > >> maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 >> > > >> new_flows_len 0 old_flows_len 0 >> > > > >> > > > >> > > > Limit of 1024 packets and 1024 flows is not wise I think. >> > > > >> > > > (If all buckets are in use, each bucket has a virtual queue of 1 packet, >> > > > which is almost the same than having no queue at all) >> > > > >> > > > I suggest to have at least 8 packets per bucket, to let Codel have a >> > > > chance to trigger. >> > > > >> > > > So you could either reduce number of buckets to 128 (if memory is >> > > > tight), or increase limit to 8192. >> > > >> > > Will try, but what I've posted is default, I didn't change/configure that. >> > >> > fq_codel has a default of 10240 packets and 1024 buckets. >> > >> > http://lxr.free-electrons.com/source/net/sched/sch_fq_codel.c#L413 >> > >> > If someone changed that in the linux variant you use, he probably should >> > explain the rationale. > > -- > Best regards, > Jesper Dangaard Brouer > MSc.CS, Principal Kernel Engineer at Red Hat > Author of http://www.iptv-analyzer.org > LinkedIn: http://www.linkedin.com/in/brouer _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From leroi.lists at gmail.com Fri May 6 14:56:58 2016 From: leroi.lists at gmail.com (Roman Yeryomin) Date: Fri, 6 May 2016 21:56:58 +0300 Subject: [OpenWrt-Devel] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood) In-Reply-To: References: <1462125592.5535.194.camel@edumazet-glaptop3.roam.corp.google.com> <865DA393-262D-40B6-A9D3-1B978CD5F6C6@gmail.com> <1462128385.5535.200.camel@edumazet-glaptop3.roam.corp.google.com> <1462136140.5535.219.camel@edumazet-glaptop3.roam.corp.google.com> <1462201620.5535.250.camel@edumazet-glaptop3.roam.corp.google.com> <1462205669.5535.254.camel@edumazet-glaptop3.roam.corp.google.com> <1462464776.13075.18.camel@edumazet-glaptop3.roam.corp.google.com> <1462476207.13075.20.camel@edumazet-glaptop3.roam.corp.google.com> <20160506114243.4eb4f95e@redhat.com> <20160506144740.210901f5@redhat.com> Message-ID: On 6 May 2016 at 21:43, Roman Yeryomin wrote: > On 6 May 2016 at 15:47, Jesper Dangaard Brouer wrote: >> >> I've created a OpenWRT ticket[1] on this issue, as it seems that someone[2] >> closed Felix'es OpenWRT email account (bad choice! emails bouncing). >> Sounds like OpenWRT and the LEDE https://www.lede-project.org/ project >> is in some kind of conflict. >> >> OpenWRT ticket [1] https://dev.openwrt.org/ticket/22349 >> >> [2] http://thread.gmane.org/gmane.comp.embedded.openwrt.devel/40298/focus=40335 > > OK, so, after porting the patch to 4.1 openwrt kernel and playing a > bit with fq_codel limits I was able to get 420Mbps UDP like this: > tc qdisc replace dev wlan0 parent :1 fq_codel flows 16 limit 256 Forgot to mention, I've reduced drop_batch_size down to 32 > This is certainly better than 30Mbps but still more than two times > less than before (900). > TCP also improved a little (550 to ~590). > > Felix, others, do you want to see the ported patch, maybe I did something wrong? > Doesn't look like it will save ath10k from performance regression. > >> >> On Fri, 6 May 2016 11:42:43 +0200 >> Jesper Dangaard Brouer wrote: >> >>> Hi Felix, >>> >>> This is an important fix for OpenWRT, please read! >>> >>> OpenWRT changed the default fq_codel sch->limit from 10240 to 1024, >>> without also adjusting q->flows_cnt. Eric explains below that you must >>> also adjust the buckets (q->flows_cnt) for this not to break. (Just >>> adjust it to 128) >>> >>> Problematic OpenWRT commit in question: >>> http://git.openwrt.org/?p=openwrt.git;a=patch;h=12cd6578084e >>> 12cd6578084e ("kernel: revert fq_codel quantum override to prevent it from causing too much cpu load with higher speed (#21326)") >>> >>> >>> I also highly recommend you cherry-pick this very recent commit: >>> net-next: 9d18562a2278 ("fq_codel: add batch ability to fq_codel_drop()") >>> https://git.kernel.org/davem/net-next/c/9d18562a227 >>> >>> This should fix very high CPU usage in-case fq_codel goes into drop mode. >>> The problem is that drop mode was considered rare, and implementation >>> wise it was chosen to be more expensive (to save cycles on normal mode). >>> Unfortunately is it easy to trigger with an UDP flood. Drop mode is >>> especially expensive for smaller devices, as it scans a 4K big array, >>> thus 64 cache misses for small devices! >>> >>> The fix is to allow drop-mode to bulk-drop more packets when entering >>> drop-mode (default 64 bulk drop). That way we don't suddenly >>> experience a significantly higher processing cost per packet, but >>> instead can amortize this. >>> >>> To Eric, should we recommend OpenWRT to adjust default (max) 64 bulk >>> drop, given we also recommend bucket size to be 128 ? (thus the amount >>> of memory to scan is less, but their CPU is also much smaller). >>> >>> --Jesper >>> >>> >>> On Thu, 05 May 2016 12:23:27 -0700 Eric Dumazet wrote: >>> >>> > On Thu, 2016-05-05 at 19:25 +0300, Roman Yeryomin wrote: >>> > > On 5 May 2016 at 19:12, Eric Dumazet wrote: >>> > > > On Thu, 2016-05-05 at 17:53 +0300, Roman Yeryomin wrote: >>> > > > >>> > > >> >>> > > >> qdisc fq_codel 0: dev eth0 root refcnt 2 limit 1024p flows 1024 >>> > > >> quantum 1514 target 5.0ms interval 100.0ms ecn >>> > > >> Sent 12306 bytes 128 pkt (dropped 0, overlimits 0 requeues 0) >>> > > >> backlog 0b 0p requeues 0 >>> > > >> maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 >>> > > >> new_flows_len 0 old_flows_len 0 >>> > > > >>> > > > >>> > > > Limit of 1024 packets and 1024 flows is not wise I think. >>> > > > >>> > > > (If all buckets are in use, each bucket has a virtual queue of 1 packet, >>> > > > which is almost the same than having no queue at all) >>> > > > >>> > > > I suggest to have at least 8 packets per bucket, to let Codel have a >>> > > > chance to trigger. >>> > > > >>> > > > So you could either reduce number of buckets to 128 (if memory is >>> > > > tight), or increase limit to 8192. >>> > > >>> > > Will try, but what I've posted is default, I didn't change/configure that. >>> > >>> > fq_codel has a default of 10240 packets and 1024 buckets. >>> > >>> > http://lxr.free-electrons.com/source/net/sched/sch_fq_codel.c#L413 >>> > >>> > If someone changed that in the linux variant you use, he probably should >>> > explain the rationale. >> >> -- >> Best regards, >> Jesper Dangaard Brouer >> MSc.CS, Principal Kernel Engineer at Red Hat >> Author of http://www.iptv-analyzer.org >> LinkedIn: http://www.linkedin.com/in/brouer _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From daniel at makrotopia.org Fri May 6 15:44:20 2016 From: daniel at makrotopia.org (Daniel Golle) Date: Fri, 6 May 2016 20:44:20 +0100 Subject: [OpenWrt-Devel] [PATCH] mac80211.sh: add support of VHT80 for mesh In-Reply-To: References: <1462552517-1670-1-git-send-email-yeohchunyeow@gmail.com> <20160506165347.GA1710@makrotopia.org> <20160506171651.GB1710@makrotopia.org> Message-ID: <20160506194420.GA5808@makrotopia.org> Hi Chun-Yeow, On Sat, May 07, 2016 at 01:31:24AM +0800, Yeoh Chun-Yeow wrote: > I think that it is alright if we solely depends on the wap_supplicant > for both open mesh and secured mesh. That would certainly work just as well, however, it would require that people have wpa_supplicant-mesh or wpad-mesh installed even if all they need is an unencrypted 802.11s mesh which doesn't require that. As people might already use 802.11s unencrypted on devices with 4megs of flash and only wpad-mini installed, that would break their currently working use-case. Eventhough the current way of deciding whether or not to use wpa_supplicant (the same also applies to station mode) makes the setup scripts a bit more complex, in my opinion it's worth that extra complexity to at least allow basic functionality without the overhead of running a full-blown authenticator in scenarious where it isn't needed. On another page, I agree that we should drop authsae in favour of wpa_supplicant's SAE support in the long run. For now, this hasn't happened because wpa_supplicant's SAE support received less testing compared to authsae. The current hybrid setup allows to easily replace one for the other, thus making regression testing trivial. With regard to your patch, I suggest to only set HT and VHT paramters for unencrypted networks and leave it to wpa_supplicant to set them for encrypted ones. Once tested that setting the parameters with authsae already running doesn't break things, setting them in that case can also be enabled in a follow-up patch. Cheers Daniel > > ---- > Chun-Yeow > > On Sat, May 7, 2016 at 1:16 AM, Daniel Golle wrote: > > On Sat, May 07, 2016 at 01:01:30AM +0800, Yeoh Chun-Yeow wrote: > >> authsae and wpa_supplicant only trigger if secured mesh. > >> wpa_supplicant should work correctly for VHT80 but don't think > >> authsae. > >> > >> But this patch is intended to allow open mesh to support VHT80. > > So maybe only enable it if $key isn't set and leave a comment in place > > that testing is needed before enabling it for authsae and/or > > wpa_supplicant. > > It might well break authsae and wpa_supplicant already handles up to > > VHT160, see > > http://w1.fi/cgit/hostap/commit/wpa_supplicant/mesh.c?id=a65efbfb243dda41518720f14724db055444bb56 > > and > > http://w1.fi/cgit/hostap/commit/wpa_supplicant/mesh.c?id=d06a35052f182d3aebc7b7e1c780cca7b386997d > > so no need to set it here again. > > > > > >> > >> Thanks > >> > >> ---- > >> Chun-Yeow > >> > >> On Sat, May 7, 2016 at 12:53 AM, Daniel Golle wrote: > >> > Hi Chun-Yeow, > >> > > >> > On Sat, May 07, 2016 at 12:35:17AM +0800, Chun-Yeow Yeoh wrote: > >> >> Add support of VHT80 setting for mesh interface > >> >> > >> >> Signed-off-by: Chun-Yeow Yeoh > >> >> --- > >> >> .../mac80211/files/lib/netifd/wireless/mac80211.sh | 33 +++++++++++----------- > >> >> 1 file changed, 17 insertions(+), 16 deletions(-) > >> >> > >> >> diff --git a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh > >> >> index 02c195e..d680ac2 100644 > >> >> --- a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh > >> >> +++ b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh > >> >> @@ -473,7 +473,7 @@ mac80211_prepare_vif() { > >> >> esac > >> >> > >> >> case "$mode" in > >> >> - monitor|mesh) > >> >> + monitor) > >> >> [ "$auto_channel" -gt 0 ] || iw dev "$ifname" set channel "$channel" $htmode > >> >> ;; > >> >> esac > >> >> [...] > >> > > >> >> @@ -566,7 +566,7 @@ mac80211_setup_adhoc() { > >> >> mcval= > >> >> [ -n "$mcast_rate" ] && wpa_supplicant_add_rate mcval "$mcast_rate" > >> >> > >> >> - iw dev "$ifname" ibss join "$ssid" $freq $ibss_htmode fixed-freq $bssid \ > >> >> + iw dev "$ifname" ibss join "$ssid" $freq $bss_htmode fixed-freq $bssid \ > >> >> ${beacon_int:+beacon-interval $beacon_int} \ > >> >> ${brstr:+basic-rates $brstr} \ > >> >> ${mcval:+mcast-rate $mcval} \ > >> >> @@ -612,7 +612,8 @@ mac80211_setup_vif() { > >> >> mcval= > >> >> [ -n "$mcast_rate" ] && wpa_supplicant_add_rate mcval "$mcast_rate" > >> >> > >> >> - iw dev "$ifname" mesh join "$mesh_id" ${mcval:+mcast-rate $mcval} > >> >> + mac80211_setup_bss_htmode > >> > > >> > have you tested this with authsae AND wpa_supplicant as well? > >> > I haven't look into it but suspect that wpa_supplicant might expect > >> > those things to be set via its configuration file instead of using > >> > iw dev ... > >> > > >> > Cheers > >> > > >> > Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From kron at animeland.de Fri May 6 18:40:46 2016 From: kron at animeland.de (Sebastian Ortwein) Date: Sat, 7 May 2016 00:40:46 +0200 Subject: [OpenWrt-Devel] Add support for AVM Fritzbox 7360 SL Message-ID: <69086bb8-44aa-05e4-a550-ee1b13633b4a@animeland.de> Hey I have tried do get openwrt working on my Fritzbox. Openwrt will start Network and VDSL Modem is working. But WLAN ist not working. The Chip is supported bei the ath9k driver. Any hint how I can get Wifi working ? The board is based on a Lantiq vr9 soc. Here are my bootlogs and patches against Openwrt. root at OpenWrt:/# dmesg [ 0.000000] Linux version 4.4.7 (sebastian at sebastian-desktop) (gcc version 5.3.0 (OpenWrt GCC 5.3.0 r49296) ) #1 Fri May 6 22:23:36 UTC 2016 [ 0.000000] SoC: xRX200 rev 1.1 [ 0.000000] bootconsole [early0] enabled [ 0.000000] CPU0 revision is: 00019555 (MIPS 34Kc) [ 0.000000] MIPS: machine is FRITZ7360SL - 1&1 HomeServer [ 0.000000] Determined physical RAM map: [ 0.000000] memory: 08000000 @ 00000000 (usable) [ 0.000000] Initrd not found or empty - disabling initrd [ 0.000000] Zone ranges: [ 0.000000] Normal [mem 0x0000000000000000-0x0000000007ffffff] [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000000000000000-0x0000000007ffffff] [ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff] [ 0.000000] On node 0 totalpages: 32768 [ 0.000000] free_area_init_node: node 0, pgdat 804d6390, node_mem_map 81007a80 [ 0.000000] Normal zone: 256 pages used for memmap [ 0.000000] Normal zone: 0 pages reserved [ 0.000000] Normal zone: 32768 pages, LIFO batch:7 [ 0.000000] Primary instruction cache 32kB, VIPT, 4-way, linesize 32 bytes. [ 0.000000] Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 bytes [ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [ 0.000000] pcpu-alloc: [0] 0 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 [ 0.000000] Kernel command line: console=ttyLTQ0,115200 init=/etc/preinit [ 0.000000] PID hash table entries: 512 (order: -1, 2048 bytes) [ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) [ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) [ 0.000000] Writing ErrCtl register=00064202 [ 0.000000] Readback ErrCtl register=00064202 [ 0.000000] Memory: 123376K/131072K available (3764K kernel code, 164K rwdata, 1144K rodata, 1184K init, 211K bss, 7696K reserved, 0K cma-reserved) [ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [ 0.000000] NR_IRQS:256 [ 0.000000] CPU Clock: 500MHz [ 0.000000] clocksource: MIPS: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041786 ns [ 0.000012] sched_clock: 32 bits at 250MHz, resolution 4ns, wraps every 8589934590ns [ 0.007862] Calibrating delay loop... 332.54 BogoMIPS (lpj=665088) [ 0.042318] pid_max: default: 32768 minimum: 301 [ 0.047171] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) [ 0.053731] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes) [ 0.066663] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns [ 0.076441] pinctrl core: initialized pinctrl subsystem [ 0.082322] NET: Registered protocol family 16 [ 0.091448] pinctrl-xway 1e100b10.pinmux: Init done [ 0.096999] dma-xway 1e104100.dma: Init done - hw rev: 7, ports: 7, channels: 28 [ 0.206470] dcdc-xrx200 1f106a00.dcdc: Core Voltage : 1016 mV [ 0.347018] usbcore: registered new interface driver usbfs [ 0.352523] usbcore: registered new interface driver hub [ 0.357878] usbcore: registered new device driver usb [ 0.363254] PCI host bridge to bus 0000:00 [ 0.367244] pci_bus 0000:00: root bus resource [mem 0x1c000000-0x1cffffff] [ 0.374158] pci_bus 0000:00: root bus resource [io 0x1d800000-0x1d8fffff] [ 0.381101] pci_bus 0000:00: root bus resource [??? 0x00000000 flags 0x0] [ 0.387957] pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff] [ 0.395990] pci 0000:00:00.0: [15d1:0011] type 01 class 0x060000 [ 0.396028] ifx_pcie_rc_class_early_fixup: fixed pcie host bridge to pci-pci bridge [ 0.413669] ifx_pcie_fixup_resource: fixup host controller 0000:00:00.0 (15d1:0011) [ 0.421261] pci 0000:00:00.0: PME# supported from D0 D3hot [ 0.421831] pci 0000:01:00.0: [168c:ff1c] type 00 class 0x020000 [ 0.421921] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x0000ffff 64bit] [ 0.422076] pci 0000:01:00.0: supports D1 [ 0.422096] pci 0000:01:00.0: PME# supported from D0 D1 D3hot [ 0.422408] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01 [ 0.422448] pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 01 [ 0.422506] pci 0000:00:00.0: BAR 8: assigned [mem 0x1c000000-0x1c0fffff] [ 0.429195] pci 0000:01:00.0: BAR 0: assigned [mem 0x1c000000-0x1c00ffff 64bit] [ 0.436557] pci 0000:00:00.0: PCI bridge to [bus 01] [ 0.441574] pci 0000:00:00.0: bridge window [mem 0x1c000000-0x1c0fffff] [ 0.448451] ifx_pcie_bios_map_irq port 0 dev 0000:00:00.0 slot 0 pin 1 [ 0.455100] ifx_pcie_bios_map_irq dev 0000:00:00.0 irq 144 assigned [ 0.461453] ifx_pcie_bios_map_irq port 0 dev 0000:01:00.0 slot 0 pin 1 [ 0.468120] ifx_pcie_bios_map_irq dev 0000:01:00.0 irq 144 assigned [ 0.475465] clocksource: Switched to clocksource MIPS [ 0.482104] NET: Registered protocol family 2 [ 0.487318] TCP established hash table entries: 1024 (order: 0, 4096 bytes) [ 0.494218] TCP bind hash table entries: 1024 (order: 0, 4096 bytes) [ 0.500593] TCP: Hash tables configured (established 1024 bind 1024) [ 0.507105] UDP hash table entries: 256 (order: 0, 4096 bytes) [ 0.512945] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) [ 0.519566] NET: Registered protocol family 1 [ 0.523906] PCI: CLS 0 bytes, default 32 [ 0.524343] gptu: totally 6 16-bit timers/counters [ 0.529186] gptu: misc_register on minor 63 [ 0.533281] gptu: succeeded to request irq 126 [ 0.537770] gptu: succeeded to request irq 127 [ 0.542284] gptu: succeeded to request irq 128 [ 0.546798] gptu: succeeded to request irq 129 [ 0.551313] gptu: succeeded to request irq 130 [ 0.555829] gptu: succeeded to request irq 131 [ 0.561200] phy-xrx200 gphy-xrx200: requesting lantiq/vr9_phy11g_a1x.bin [ 0.568479] phy-xrx200 gphy-xrx200: booting GPHY0 firmware at 7940000 [ 0.574822] phy-xrx200 gphy-xrx200: booting GPHY1 firmware at 7940000 [ 0.682305] futex hash table entries: 256 (order: -1, 3072 bytes) [ 0.715662] squashfs: version 4.0 (2009/01/31) Phillip Lougher [ 0.721392] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc. [ 0.734808] io scheduler noop registered [ 0.738652] io scheduler deadline registered (default) [ 0.744497] 1e100c00.serial: ttyLTQ0 at MMIO 0x1e100c00 (irq = 112, base_baud = 0) is a lantiq,asc [ 0.753399] console [ttyLTQ0] enabled [ 0.760723] bootconsole [early0] disabled [ 0.769781] lantiq nor flash device: 01000000 at 10000000 [ 0.773915] ltq_nor: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0x000001 Chip ID 0x002101 [ 0.783349] Amd/Fujitsu Extended Query Table at 0x0040 [ 0.788476] Amd/Fujitsu Extended Query version 1.3. [ 0.793512] number of CFI chips: 1 [ 0.796942] 4 ofpart partitions found on MTD device ltq_nor [ 0.802478] Creating 4 MTD partitions on "ltq_nor": [ 0.807360] 0x000000000000-0x000000020000 : "urlader" [ 0.815754] 0x000000020000-0x000000f80000 : "firmware" [ 0.836761] 2 eva-fw partitions found on MTD device firmware [ 0.841008] 0x000000020000-0x0000001bfa74 : "kernel" [ 0.847817] 0x0000001c0100-0x000000f80000 : "rootfs" [ 0.853486] mtd: device 3 (rootfs) set to be root filesystem [ 0.857792] 1 squashfs-split partitions found on MTD device rootfs [ 0.863912] 0x000000460000-0x000000f80000 : "rootfs_data" [ 0.871543] 0x000000f80000-0x000000fc0000 : "tffs (1)" [ 0.877447] 0x000000fc0000-0x000001000000 : "tffs (2)" [ 0.986126] libphy: lantiq,xrx200-mdio: probed [ 0.996971] eth0: attached PHY [Generic PHY] (phy_addr=0:00, irq=-1) [ 1.002324] eth0: attached PHY [Generic PHY] (phy_addr=0:01, irq=-1) [ 1.072164] eth0: attached PHY [Lantiq XWAY VR9 GPHY 11G v1.4] (phy_addr=0:11, irq=-1) [ 1.140155] eth0: attached PHY [Lantiq XWAY VR9 GPHY 11G v1.4] (phy_addr=0:13, irq=-1) [ 1.148042] wdt 1f8803f0.watchdog: Init done [ 1.153878] NET: Registered protocol family 10 [ 1.162382] NET: Registered protocol family 17 [ 1.165538] bridge: automatic filtering via arp/ip/ip6tables has been deprecated. Update your scripts to load br_netfilter if you need this. [ 1.178060] 8021q: 802.1Q VLAN Support v1.8 [ 1.182319] found entry name -> annex=B [ 1.186088] found entry name -> maca=BC:05:43:D7:1E:7C [ 1.191177] found entry name -> macb=BC:05:43:D7:1E:7D [ 1.196312] found entry name -> macwlan=BC:05:43:D7:1E:7E [ 1.201706] found entry name -> macdsl=BC:05:43:D7:1E:7F [ 1.207069] found entry name -> macwlan2=BC:05:43:D7:1E:81 [ 1.212501] found entry name -> wlan_key=4004584479108575 [ 1.223899] UBIFS error (pid: 1): cannot open "ubi0:rootfs", error -19 [ 1.233871] VFS: Mounted root (squashfs filesystem) readonly on device 31:3. [ 1.241380] Freeing unused kernel memory: 1184K (804f8000 - 80620000) [ 2.417706] init: Console is alive [ 2.420017] init: - watchdog - [ 3.187559] eth0: port 1 got link [ 3.974342] SCSI subsystem initialized [ 3.989600] usbcore: registered new interface driver usb-storage [ 3.997229] init: - preinit - [ 4.510986] random: procd urandom read with 17 bits of entropy available [ 7.816027] mount_root: jffs2 not ready yet, using temporary tmpfs overlay [ 7.836202] procd: - early - [ 7.837807] procd: - watchdog - [ 8.572768] procd: - ubus - [ 8.627629] procd: - init - [ 9.476796] IFXOS, Version 1.5.19 (c) Copyright 2009, Lantiq Deutschland GmbH [ 9.486752] NET: Registered protocol family 8 [ 9.489719] NET: Registered protocol family 20 [ 9.500912] PPP generic driver version 2.4.2 [ 9.511937] ip6_tables: (C) 2000-2006 Netfilter Core Team [ 9.537506] Lantiq (VRX) DSL CPE MEI driver, version 1.4.8.5, (c) 2013 Lantiq Deutschland GmbH [ 9.537506] [ 9.537506] Lantiq CPE API Driver version: DSL CPE API V4.16.6.3 [ 9.558430] [ 9.558430] Predefined debug level: 3 [ 9.569131] Loading modules backported from Linux version v4.4-rc5-1913-gc8fdf68 [ 9.575144] Backport generated by backports.git backports-20151218-0-g2f58d9d [ 9.585694] ip_tables: (C) 2000-2006 Netfilter Core Team [ 9.596751] Infineon Technologies DEU driver version 2.0.0 [ 9.602828] IFX DEU DES initialized (multiblock). [ 9.607104] IFX DEU AES initialized (multiblock). [ 9.611236] IFX DEU ARC4 initialized (multiblock). [ 9.615898] IFX DEU SHA1 initialized. [ 9.619394] IFX DEU MD5 initialized. [ 9.623068] IFX DEU SHA1_HMAC initialized. [ 9.627173] IFX DEU MD5_HMAC initialized. [ 9.637542] nf_conntrack version 0.5.0 (1946 buckets, 7784 max) [ 9.663906] NET: Registered protocol family 24 [ 9.689430] xt_time: kernel timezone is -0000 [ 17.443364] jffs2_scan_eraseblock(): End of filesystem marker found at 0x0 [ 17.448921] jffs2_build_filesystem(): unlocking the mtd device... done. [ 17.455397] jffs2_build_filesystem(): erasing all blocks after the end marker... [ 32.627514] random: nonblocking pool is initialized [ 73.855188] done. [ 73.855719] jffs2: notice: (926) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found. root at OpenWrt:/# original bootlogs can bw found here: http://www.wehavemorefun.de/fritzbox/7360_Bootlogs Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: 7360SL.diff Type: text/x-patch Size: 5792 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From martin.blumenstingl at googlemail.com Sat May 7 03:53:51 2016 From: martin.blumenstingl at googlemail.com (Martin Blumenstingl) Date: Sat, 7 May 2016 09:53:51 +0200 Subject: [OpenWrt-Devel] Add support for AVM Fritzbox 7360 SL In-Reply-To: <69086bb8-44aa-05e4-a550-ee1b13633b4a@animeland.de> References: <69086bb8-44aa-05e4-a550-ee1b13633b4a@animeland.de> Message-ID: On Sat, May 7, 2016 at 12:40 AM, Sebastian Ortwein wrote: > Hey > > I have tried do get openwrt working on my Fritzbox. Openwrt will start > Network and VDSL Modem is working. But WLAN ist not working. The Chip is > supported bei the ath9k driver. Any hint how I can get Wifi working ? I see you already got most things working - see my comments inline. > root at OpenWrt:/# dmesg > [ 0.000000] Linux version 4.4.7 (sebastian at sebastian-desktop) (gcc > version 5.3.0 (OpenWrt GCC 5.3.0 r49296) ) #1 Fri May 6 22:23:36 UTC 2016 > [ 0.000000] SoC: xRX200 rev 1.1 > [ 0.000000] bootconsole [early0] enabled > [ 0.000000] CPU0 revision is: 00019555 (MIPS 34Kc) > [ 0.000000] MIPS: machine is FRITZ7360SL - 1&1 HomeServer > [ 0.000000] Determined physical RAM map: > [ 0.000000] memory: 08000000 @ 00000000 (usable) > [ 0.000000] Initrd not found or empty - disabling initrd > [ 0.000000] Zone ranges: > [ 0.000000] Normal [mem 0x0000000000000000-0x0000000007ffffff] > [ 0.000000] Movable zone start for each node > [ 0.000000] Early memory node ranges > [ 0.000000] node 0: [mem 0x0000000000000000-0x0000000007ffffff] > [ 0.000000] Initmem setup node 0 [mem > 0x0000000000000000-0x0000000007ffffff] > [ 0.000000] On node 0 totalpages: 32768 > [ 0.000000] free_area_init_node: node 0, pgdat 804d6390, node_mem_map > 81007a80 > [ 0.000000] Normal zone: 256 pages used for memmap > [ 0.000000] Normal zone: 0 pages reserved > [ 0.000000] Normal zone: 32768 pages, LIFO batch:7 > [ 0.000000] Primary instruction cache 32kB, VIPT, 4-way, linesize 32 > bytes. > [ 0.000000] Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize > 32 bytes > [ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 > [ 0.000000] pcpu-alloc: [0] 0 > [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total > pages: 32512 > [ 0.000000] Kernel command line: console=ttyLTQ0,115200 init=/etc/preinit > [ 0.000000] PID hash table entries: 512 (order: -1, 2048 bytes) > [ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 > bytes) > [ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) > [ 0.000000] Writing ErrCtl register=00064202 > [ 0.000000] Readback ErrCtl register=00064202 > [ 0.000000] Memory: 123376K/131072K available (3764K kernel code, 164K > rwdata, 1144K rodata, 1184K init, 211K bss, 7696K reserved, 0K cma-reserved) > [ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 > [ 0.000000] NR_IRQS:256 > [ 0.000000] CPU Clock: 500MHz > [ 0.000000] clocksource: MIPS: mask: 0xffffffff max_cycles: 0xffffffff, > max_idle_ns: 7645041786 ns > [ 0.000012] sched_clock: 32 bits at 250MHz, resolution 4ns, wraps every > 8589934590ns > [ 0.007862] Calibrating delay loop... 332.54 BogoMIPS (lpj=665088) > [ 0.042318] pid_max: default: 32768 minimum: 301 > [ 0.047171] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) > [ 0.053731] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 > bytes) > [ 0.066663] clocksource: jiffies: mask: 0xffffffff max_cycles: > 0xffffffff, max_idle_ns: 7645041785100000 ns > [ 0.076441] pinctrl core: initialized pinctrl subsystem > [ 0.082322] NET: Registered protocol family 16 > [ 0.091448] pinctrl-xway 1e100b10.pinmux: Init done > [ 0.096999] dma-xway 1e104100.dma: Init done - hw rev: 7, ports: 7, > channels: 28 > [ 0.206470] dcdc-xrx200 1f106a00.dcdc: Core Voltage : 1016 mV > [ 0.347018] usbcore: registered new interface driver usbfs > [ 0.352523] usbcore: registered new interface driver hub > [ 0.357878] usbcore: registered new device driver usb > [ 0.363254] PCI host bridge to bus 0000:00 > [ 0.367244] pci_bus 0000:00: root bus resource [mem 0x1c000000-0x1cffffff] > [ 0.374158] pci_bus 0000:00: root bus resource [io 0x1d800000-0x1d8fffff] > [ 0.381101] pci_bus 0000:00: root bus resource [??? 0x00000000 flags 0x0] > [ 0.387957] pci_bus 0000:00: No busn resource found for root bus, will use > [bus 00-ff] > [ 0.395990] pci 0000:00:00.0: [15d1:0011] type 01 class 0x060000 > [ 0.396028] ifx_pcie_rc_class_early_fixup: fixed pcie host bridge to pci-pci > bridge > [ 0.413669] ifx_pcie_fixup_resource: fixup host controller 0000:00:00.0 > (15d1:0011) > [ 0.421261] pci 0000:00:00.0: PME# supported from D0 D3hot > [ 0.421831] pci 0000:01:00.0: [168c:ff1c] type 00 class 0x020000 ff1c means that the calibration data was not loaded yet - see FRITZ3370.dts for example. > [ 0.421921] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x0000ffff 64bit] > [ 0.422076] pci 0000:01:00.0: supports D1 > [ 0.422096] pci 0000:01:00.0: PME# supported from D0 D1 D3hot > [ 0.422408] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01 > [ 0.422448] pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 01 > [ 0.422506] pci 0000:00:00.0: BAR 8: assigned [mem 0x1c000000-0x1c0fffff] > [ 0.429195] pci 0000:01:00.0: BAR 0: assigned [mem 0x1c000000-0x1c00ffff > 64bit] > [ 0.436557] pci 0000:00:00.0: PCI bridge to [bus 01] > [ 0.441574] pci 0000:00:00.0: bridge window [mem 0x1c000000-0x1c0fffff] > [ 0.448451] ifx_pcie_bios_map_irq port 0 dev 0000:00:00.0 slot 0 pin 1 > [ 0.455100] ifx_pcie_bios_map_irq dev 0000:00:00.0 irq 144 assigned > [ 0.461453] ifx_pcie_bios_map_irq port 0 dev 0000:01:00.0 slot 0 pin 1 > [ 0.468120] ifx_pcie_bios_map_irq dev 0000:01:00.0 irq 144 assigned > [ 0.475465] clocksource: Switched to clocksource MIPS > [ 0.482104] NET: Registered protocol family 2 > [ 0.487318] TCP established hash table entries: 1024 (order: 0, 4096 bytes) > [ 0.494218] TCP bind hash table entries: 1024 (order: 0, 4096 bytes) > [ 0.500593] TCP: Hash tables configured (established 1024 bind 1024) > [ 0.507105] UDP hash table entries: 256 (order: 0, 4096 bytes) > [ 0.512945] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) > [ 0.519566] NET: Registered protocol family 1 > [ 0.523906] PCI: CLS 0 bytes, default 32 > [ 0.524343] gptu: totally 6 16-bit timers/counters > [ 0.529186] gptu: misc_register on minor 63 > [ 0.533281] gptu: succeeded to request irq 126 > [ 0.537770] gptu: succeeded to request irq 127 > [ 0.542284] gptu: succeeded to request irq 128 > [ 0.546798] gptu: succeeded to request irq 129 > [ 0.551313] gptu: succeeded to request irq 130 > [ 0.555829] gptu: succeeded to request irq 131 > [ 0.561200] phy-xrx200 gphy-xrx200: requesting lantiq/vr9_phy11g_a1x.bin > [ 0.568479] phy-xrx200 gphy-xrx200: booting GPHY0 firmware at 7940000 > [ 0.574822] phy-xrx200 gphy-xrx200: booting GPHY1 firmware at 7940000 > [ 0.682305] futex hash table entries: 256 (order: -1, 3072 bytes) > [ 0.715662] squashfs: version 4.0 (2009/01/31) Phillip Lougher > [ 0.721392] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) > (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc. > [ 0.734808] io scheduler noop registered > [ 0.738652] io scheduler deadline registered (default) > [ 0.744497] 1e100c00.serial: ttyLTQ0 at MMIO 0x1e100c00 (irq = 112, > base_baud = 0) is a lantiq,asc > [ 0.753399] console [ttyLTQ0] enabled > [ 0.760723] bootconsole [early0] disabled > [ 0.769781] lantiq nor flash device: 01000000 at 10000000 > [ 0.773915] ltq_nor: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer > ID 0x000001 Chip ID 0x002101 > [ 0.783349] Amd/Fujitsu Extended Query Table at 0x0040 > [ 0.788476] Amd/Fujitsu Extended Query version 1.3. > [ 0.793512] number of CFI chips: 1 > [ 0.796942] 4 ofpart partitions found on MTD device ltq_nor > [ 0.802478] Creating 4 MTD partitions on "ltq_nor": > [ 0.807360] 0x000000000000-0x000000020000 : "urlader" > [ 0.815754] 0x000000020000-0x000000f80000 : "firmware" > [ 0.836761] 2 eva-fw partitions found on MTD device firmware > [ 0.841008] 0x000000020000-0x0000001bfa74 : "kernel" > [ 0.847817] 0x0000001c0100-0x000000f80000 : "rootfs" > [ 0.853486] mtd: device 3 (rootfs) set to be root filesystem > [ 0.857792] 1 squashfs-split partitions found on MTD device rootfs > [ 0.863912] 0x000000460000-0x000000f80000 : "rootfs_data" > [ 0.871543] 0x000000f80000-0x000000fc0000 : "tffs (1)" > [ 0.877447] 0x000000fc0000-0x000001000000 : "tffs (2)" > [ 0.986126] libphy: lantiq,xrx200-mdio: probed > [ 0.996971] eth0: attached PHY [Generic PHY] (phy_addr=0:00, irq=-1) > [ 1.002324] eth0: attached PHY [Generic PHY] (phy_addr=0:01, irq=-1) I remember reading somewhere that there are two AR8030 10/100 PHYs. I suggest you enable CONFIG_AT803X_PHY and assign the reset GPIOs to these PHYs, due to a hardware bug in them (see https://github.com/torvalds/linux/blob/master/drivers/net/phy/at803x.c#L351) > [ 1.072164] eth0: attached PHY [Lantiq XWAY VR9 GPHY 11G v1.4] > (phy_addr=0:11, irq=-1) > [ 1.140155] eth0: attached PHY [Lantiq XWAY VR9 GPHY 11G v1.4] > (phy_addr=0:13, irq=-1) > [ 1.148042] wdt 1f8803f0.watchdog: Init done > [ 1.153878] NET: Registered protocol family 10 > [ 1.162382] NET: Registered protocol family 17 > [ 1.165538] bridge: automatic filtering via arp/ip/ip6tables has been > deprecated. Update your scripts to load br_netfilter if you need this. > [ 1.178060] 8021q: 802.1Q VLAN Support v1.8 > [ 1.182319] found entry name -> annex=B > [ 1.186088] found entry name -> maca=BC:05:43:D7:1E:7C > [ 1.191177] found entry name -> macb=BC:05:43:D7:1E:7D > [ 1.196312] found entry name -> macwlan=BC:05:43:D7:1E:7E > [ 1.201706] found entry name -> macdsl=BC:05:43:D7:1E:7F > [ 1.207069] found entry name -> macwlan2=BC:05:43:D7:1E:81 > [ 1.212501] found entry name -> wlan_key=4004584479108575 > [ 1.223899] UBIFS error (pid: 1): cannot open "ubi0:rootfs", error -19 > [ 1.233871] VFS: Mounted root (squashfs filesystem) readonly on device > 31:3. > [ 1.241380] Freeing unused kernel memory: 1184K (804f8000 - 80620000) > [ 2.417706] init: Console is alive > [ 2.420017] init: - watchdog - > [ 3.187559] eth0: port 1 got link > [ 3.974342] SCSI subsystem initialized > [ 3.989600] usbcore: registered new interface driver usb-storage > [ 3.997229] init: - preinit - > [ 4.510986] random: procd urandom read with 17 bits of entropy available > [ 7.816027] mount_root: jffs2 not ready yet, using temporary tmpfs > overlay > [ 7.836202] procd: - early - > [ 7.837807] procd: - watchdog - > [ 8.572768] procd: - ubus - > [ 8.627629] procd: - init - > [ 9.476796] IFXOS, Version 1.5.19 (c) Copyright 2009, Lantiq Deutschland > GmbH > [ 9.486752] NET: Registered protocol family 8 > [ 9.489719] NET: Registered protocol family 20 > [ 9.500912] PPP generic driver version 2.4.2 > [ 9.511937] ip6_tables: (C) 2000-2006 Netfilter Core Team > [ 9.537506] Lantiq (VRX) DSL CPE MEI driver, version 1.4.8.5, (c) 2013 > Lantiq Deutschland GmbH > [ 9.537506] > [ 9.537506] Lantiq CPE API Driver version: DSL CPE API V4.16.6.3 > [ 9.558430] > [ 9.558430] Predefined debug level: 3 > [ 9.569131] Loading modules backported from Linux version > v4.4-rc5-1913-gc8fdf68 > [ 9.575144] Backport generated by backports.git > backports-20151218-0-g2f58d9d > [ 9.585694] ip_tables: (C) 2000-2006 Netfilter Core Team > [ 9.596751] Infineon Technologies DEU driver version 2.0.0 > [ 9.602828] IFX DEU DES initialized (multiblock). > [ 9.607104] IFX DEU AES initialized (multiblock). > [ 9.611236] IFX DEU ARC4 initialized (multiblock). > [ 9.615898] IFX DEU SHA1 initialized. > [ 9.619394] IFX DEU MD5 initialized. > [ 9.623068] IFX DEU SHA1_HMAC initialized. > [ 9.627173] IFX DEU MD5_HMAC initialized. > [ 9.637542] nf_conntrack version 0.5.0 (1946 buckets, 7784 max) > [ 9.663906] NET: Registered protocol family 24 > [ 9.689430] xt_time: kernel timezone is -0000 > [ 17.443364] jffs2_scan_eraseblock(): End of filesystem marker found at > 0x0 > [ 17.448921] jffs2_build_filesystem(): unlocking the mtd device... done. > [ 17.455397] jffs2_build_filesystem(): erasing all blocks after the end > marker... > [ 32.627514] random: nonblocking pool is initialized > [ 73.855188] done. > [ 73.855719] jffs2: notice: (926) jffs2_build_xattr_subsystem: complete > building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref > (0 dead, 0 orphan) found. > root at OpenWrt:/# Maybe you can create a common .dtsi file for FRITZ3370 and FRITZ7360SL. I haven't looked at it in detail, but AVM devices usually have a lot in common when they are based on the same platform (in this case: VRX200). One last note: I am not sure about the status of the current TFFS (the MAC addresses, etc are stored there) driver and how you can use it from userspace (to assign the correct MAC addresses for example). Some time ago I wrote a userspace replacement for the in-kernel TFFS driver, which you can find here: https://github.com/xdarklight/fritz_tffs_tools However, please note that my tool is basically untested! Martin _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From russell at personaltelco.net Sat May 7 05:32:13 2016 From: russell at personaltelco.net (Russell Senior) Date: Sat, 07 May 2016 02:32:13 -0700 Subject: [OpenWrt-Devel] [PATCH] brcm47xx: fix wgt634u port assignment, broken since openwrt r47866 Message-ID: <87mvo2mcwy.fsf@husum.klickitat.com> Signed-off-by: Russell Senior --- target/linux/brcm47xx/base-files/etc/board.d/01_detect | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/brcm47xx/base-files/etc/board.d/01_detect b/target/linux/brcm47xx/base-files/etc/board.d/01_detect index 91ac16e..16b81d4 100755 --- a/target/linux/brcm47xx/base-files/etc/board.d/01_detect +++ b/target/linux/brcm47xx/base-files/etc/board.d/01_detect @@ -124,7 +124,7 @@ detect_by_model() { # Netgear WGT634U exception if grep -sqE 'mtd0: 000(6|a)0000' /proc/mtd; then ucidef_add_switch "switch0" \ - "0:wan" "1:lan" "2:lan" "3:lan" "4:lan" "5 at eth0" + "0:lan" "1:lan" "2:lan" "3:lan" "4:wan" "5 at eth0" return fi -- 2.8.2 -- Russell Senior, President russell at personaltelco.net _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sscapi at gmail.com Sat May 7 13:26:38 2016 From: sscapi at gmail.com (Sylwek ScApi) Date: Sat, 7 May 2016 19:26:38 +0200 Subject: [OpenWrt-Devel] Add support for AVM Fritzbox 7360 SL In-Reply-To: References: <69086bb8-44aa-05e4-a550-ee1b13633b4a@animeland.de> Message-ID: <572E254E.4030409@gmail.com> W dniu 2016-05-07 o 09:53, Martin Blumenstingl pisze: > On Sat, May 7, 2016 at 12:40 AM, Sebastian Ortwein wrote: >> Hey >> >> I have tried do get openwrt working on my Fritzbox. Openwrt will start >> Network and VDSL Modem is working. But WLAN ist not working. The Chip is >> supported bei the ath9k driver. Any hint how I can get Wifi working ? > I see you already got most things working - see my comments inline. > >> root at OpenWrt:/# dmesg >> [ 0.000000] Linux version 4.4.7 (sebastian at sebastian-desktop) (gcc >> version 5.3.0 (OpenWrt GCC 5.3.0 r49296) ) #1 Fri May 6 22:23:36 UTC 2016 >> [ 0.000000] SoC: xRX200 rev 1.1 >> [ 0.000000] bootconsole [early0] enabled >> [ 0.000000] CPU0 revision is: 00019555 (MIPS 34Kc) >> [ 0.000000] MIPS: machine is FRITZ7360SL - 1&1 HomeServer >> [ 0.000000] Determined physical RAM map: >> [ 0.000000] memory: 08000000 @ 00000000 (usable) >> [ 0.000000] Initrd not found or empty - disabling initrd >> [ 0.000000] Zone ranges: >> [ 0.000000] Normal [mem 0x0000000000000000-0x0000000007ffffff] >> [ 0.000000] Movable zone start for each node >> [ 0.000000] Early memory node ranges >> [ 0.000000] node 0: [mem 0x0000000000000000-0x0000000007ffffff] >> [ 0.000000] Initmem setup node 0 [mem >> 0x0000000000000000-0x0000000007ffffff] >> [ 0.000000] On node 0 totalpages: 32768 >> [ 0.000000] free_area_init_node: node 0, pgdat 804d6390, node_mem_map >> 81007a80 >> [ 0.000000] Normal zone: 256 pages used for memmap >> [ 0.000000] Normal zone: 0 pages reserved >> [ 0.000000] Normal zone: 32768 pages, LIFO batch:7 >> [ 0.000000] Primary instruction cache 32kB, VIPT, 4-way, linesize 32 >> bytes. >> [ 0.000000] Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize >> 32 bytes >> [ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 >> [ 0.000000] pcpu-alloc: [0] 0 >> [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total >> pages: 32512 >> [ 0.000000] Kernel command line: console=ttyLTQ0,115200 init=/etc/preinit >> [ 0.000000] PID hash table entries: 512 (order: -1, 2048 bytes) >> [ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 >> bytes) >> [ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) >> [ 0.000000] Writing ErrCtl register=00064202 >> [ 0.000000] Readback ErrCtl register=00064202 >> [ 0.000000] Memory: 123376K/131072K available (3764K kernel code, 164K >> rwdata, 1144K rodata, 1184K init, 211K bss, 7696K reserved, 0K cma-reserved) >> [ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 >> [ 0.000000] NR_IRQS:256 >> [ 0.000000] CPU Clock: 500MHz >> [ 0.000000] clocksource: MIPS: mask: 0xffffffff max_cycles: 0xffffffff, >> max_idle_ns: 7645041786 ns >> [ 0.000012] sched_clock: 32 bits at 250MHz, resolution 4ns, wraps every >> 8589934590ns >> [ 0.007862] Calibrating delay loop... 332.54 BogoMIPS (lpj=665088) >> [ 0.042318] pid_max: default: 32768 minimum: 301 >> [ 0.047171] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) >> [ 0.053731] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 >> bytes) >> [ 0.066663] clocksource: jiffies: mask: 0xffffffff max_cycles: >> 0xffffffff, max_idle_ns: 7645041785100000 ns >> [ 0.076441] pinctrl core: initialized pinctrl subsystem >> [ 0.082322] NET: Registered protocol family 16 >> [ 0.091448] pinctrl-xway 1e100b10.pinmux: Init done >> [ 0.096999] dma-xway 1e104100.dma: Init done - hw rev: 7, ports: 7, >> channels: 28 >> [ 0.206470] dcdc-xrx200 1f106a00.dcdc: Core Voltage : 1016 mV >> [ 0.347018] usbcore: registered new interface driver usbfs >> [ 0.352523] usbcore: registered new interface driver hub >> [ 0.357878] usbcore: registered new device driver usb >> [ 0.363254] PCI host bridge to bus 0000:00 >> [ 0.367244] pci_bus 0000:00: root bus resource [mem 0x1c000000-0x1cffffff] >> [ 0.374158] pci_bus 0000:00: root bus resource [io 0x1d800000-0x1d8fffff] >> [ 0.381101] pci_bus 0000:00: root bus resource [??? 0x00000000 flags 0x0] >> [ 0.387957] pci_bus 0000:00: No busn resource found for root bus, will use >> [bus 00-ff] >> [ 0.395990] pci 0000:00:00.0: [15d1:0011] type 01 class 0x060000 >> [ 0.396028] ifx_pcie_rc_class_early_fixup: fixed pcie host bridge to pci-pci >> bridge >> [ 0.413669] ifx_pcie_fixup_resource: fixup host controller 0000:00:00.0 >> (15d1:0011) >> [ 0.421261] pci 0000:00:00.0: PME# supported from D0 D3hot >> [ 0.421831] pci 0000:01:00.0: [168c:ff1c] type 00 class 0x020000 > ff1c means that the calibration data was not loaded yet - see > FRITZ3370.dts for example. Agreed. >> [ 0.421921] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x0000ffff 64bit] >> [ 0.422076] pci 0000:01:00.0: supports D1 >> [ 0.422096] pci 0000:01:00.0: PME# supported from D0 D1 D3hot >> [ 0.422408] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01 >> [ 0.422448] pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 01 >> [ 0.422506] pci 0000:00:00.0: BAR 8: assigned [mem 0x1c000000-0x1c0fffff] >> [ 0.429195] pci 0000:01:00.0: BAR 0: assigned [mem 0x1c000000-0x1c00ffff >> 64bit] >> [ 0.436557] pci 0000:00:00.0: PCI bridge to [bus 01] >> [ 0.441574] pci 0000:00:00.0: bridge window [mem 0x1c000000-0x1c0fffff] >> [ 0.448451] ifx_pcie_bios_map_irq port 0 dev 0000:00:00.0 slot 0 pin 1 >> [ 0.455100] ifx_pcie_bios_map_irq dev 0000:00:00.0 irq 144 assigned >> [ 0.461453] ifx_pcie_bios_map_irq port 0 dev 0000:01:00.0 slot 0 pin 1 >> [ 0.468120] ifx_pcie_bios_map_irq dev 0000:01:00.0 irq 144 assigned >> [ 0.475465] clocksource: Switched to clocksource MIPS >> [ 0.482104] NET: Registered protocol family 2 >> [ 0.487318] TCP established hash table entries: 1024 (order: 0, 4096 bytes) >> [ 0.494218] TCP bind hash table entries: 1024 (order: 0, 4096 bytes) >> [ 0.500593] TCP: Hash tables configured (established 1024 bind 1024) >> [ 0.507105] UDP hash table entries: 256 (order: 0, 4096 bytes) >> [ 0.512945] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) >> [ 0.519566] NET: Registered protocol family 1 >> [ 0.523906] PCI: CLS 0 bytes, default 32 >> [ 0.524343] gptu: totally 6 16-bit timers/counters >> [ 0.529186] gptu: misc_register on minor 63 >> [ 0.533281] gptu: succeeded to request irq 126 >> [ 0.537770] gptu: succeeded to request irq 127 >> [ 0.542284] gptu: succeeded to request irq 128 >> [ 0.546798] gptu: succeeded to request irq 129 >> [ 0.551313] gptu: succeeded to request irq 130 >> [ 0.555829] gptu: succeeded to request irq 131 >> [ 0.561200] phy-xrx200 gphy-xrx200: requesting lantiq/vr9_phy11g_a1x.bin >> [ 0.568479] phy-xrx200 gphy-xrx200: booting GPHY0 firmware at 7940000 >> [ 0.574822] phy-xrx200 gphy-xrx200: booting GPHY1 firmware at 7940000 >> [ 0.682305] futex hash table entries: 256 (order: -1, 3072 bytes) >> [ 0.715662] squashfs: version 4.0 (2009/01/31) Phillip Lougher >> [ 0.721392] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) >> (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc. >> [ 0.734808] io scheduler noop registered >> [ 0.738652] io scheduler deadline registered (default) >> [ 0.744497] 1e100c00.serial: ttyLTQ0 at MMIO 0x1e100c00 (irq = 112, >> base_baud = 0) is a lantiq,asc >> [ 0.753399] console [ttyLTQ0] enabled >> [ 0.760723] bootconsole [early0] disabled >> [ 0.769781] lantiq nor flash device: 01000000 at 10000000 >> [ 0.773915] ltq_nor: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer >> ID 0x000001 Chip ID 0x002101 >> [ 0.783349] Amd/Fujitsu Extended Query Table at 0x0040 >> [ 0.788476] Amd/Fujitsu Extended Query version 1.3. >> [ 0.793512] number of CFI chips: 1 >> [ 0.796942] 4 ofpart partitions found on MTD device ltq_nor >> [ 0.802478] Creating 4 MTD partitions on "ltq_nor": >> [ 0.807360] 0x000000000000-0x000000020000 : "urlader" >> [ 0.815754] 0x000000020000-0x000000f80000 : "firmware" >> [ 0.836761] 2 eva-fw partitions found on MTD device firmware >> [ 0.841008] 0x000000020000-0x0000001bfa74 : "kernel" >> [ 0.847817] 0x0000001c0100-0x000000f80000 : "rootfs" >> [ 0.853486] mtd: device 3 (rootfs) set to be root filesystem >> [ 0.857792] 1 squashfs-split partitions found on MTD device rootfs >> [ 0.863912] 0x000000460000-0x000000f80000 : "rootfs_data" >> [ 0.871543] 0x000000f80000-0x000000fc0000 : "tffs (1)" >> [ 0.877447] 0x000000fc0000-0x000001000000 : "tffs (2)" >> [ 0.986126] libphy: lantiq,xrx200-mdio: probed >> [ 0.996971] eth0: attached PHY [Generic PHY] (phy_addr=0:00, irq=-1) >> [ 1.002324] eth0: attached PHY [Generic PHY] (phy_addr=0:01, irq=-1) > I remember reading somewhere that there are two AR8030 10/100 PHYs. > I suggest you enable CONFIG_AT803X_PHY and assign the reset GPIOs to > these PHYs, due to a hardware bug in them (see > https://github.com/torvalds/linux/blob/master/drivers/net/phy/at803x.c#L351) If wiki is right then there are : "VDSL2, 2x LAN 1Gbit, 2x LAN 100Mbit, WLAN 802.11 b/g/n 2.4 GHz bis 300 Mbit/s" I don't see any other chips on pcb. >> [ 1.072164] eth0: attached PHY [Lantiq XWAY VR9 GPHY 11G v1.4] >> (phy_addr=0:11, irq=-1) >> [ 1.140155] eth0: attached PHY [Lantiq XWAY VR9 GPHY 11G v1.4] >> (phy_addr=0:13, irq=-1) >> [ 1.148042] wdt 1f8803f0.watchdog: Init done >> [ 1.153878] NET: Registered protocol family 10 >> [ 1.162382] NET: Registered protocol family 17 >> [ 1.165538] bridge: automatic filtering via arp/ip/ip6tables has been >> deprecated. Update your scripts to load br_netfilter if you need this. >> [ 1.178060] 8021q: 802.1Q VLAN Support v1.8 >> [ 1.182319] found entry name -> annex=B >> [ 1.186088] found entry name -> maca=BC:05:43:D7:1E:7C >> [ 1.191177] found entry name -> macb=BC:05:43:D7:1E:7D >> [ 1.196312] found entry name -> macwlan=BC:05:43:D7:1E:7E >> [ 1.201706] found entry name -> macdsl=BC:05:43:D7:1E:7F >> [ 1.207069] found entry name -> macwlan2=BC:05:43:D7:1E:81 >> [ 1.212501] found entry name -> wlan_key=4004584479108575 >> [ 1.223899] UBIFS error (pid: 1): cannot open "ubi0:rootfs", error -19 >> [ 1.233871] VFS: Mounted root (squashfs filesystem) readonly on device >> 31:3. >> [ 1.241380] Freeing unused kernel memory: 1184K (804f8000 - 80620000) >> [ 2.417706] init: Console is alive >> [ 2.420017] init: - watchdog - >> [ 3.187559] eth0: port 1 got link >> [ 3.974342] SCSI subsystem initialized >> [ 3.989600] usbcore: registered new interface driver usb-storage >> [ 3.997229] init: - preinit - >> [ 4.510986] random: procd urandom read with 17 bits of entropy available >> [ 7.816027] mount_root: jffs2 not ready yet, using temporary tmpfs >> overlay >> [ 7.836202] procd: - early - >> [ 7.837807] procd: - watchdog - >> [ 8.572768] procd: - ubus - >> [ 8.627629] procd: - init - >> [ 9.476796] IFXOS, Version 1.5.19 (c) Copyright 2009, Lantiq Deutschland >> GmbH >> [ 9.486752] NET: Registered protocol family 8 >> [ 9.489719] NET: Registered protocol family 20 >> [ 9.500912] PPP generic driver version 2.4.2 >> [ 9.511937] ip6_tables: (C) 2000-2006 Netfilter Core Team >> [ 9.537506] Lantiq (VRX) DSL CPE MEI driver, version 1.4.8.5, (c) 2013 >> Lantiq Deutschland GmbH >> [ 9.537506] >> [ 9.537506] Lantiq CPE API Driver version: DSL CPE API V4.16.6.3 >> [ 9.558430] >> [ 9.558430] Predefined debug level: 3 >> [ 9.569131] Loading modules backported from Linux version >> v4.4-rc5-1913-gc8fdf68 >> [ 9.575144] Backport generated by backports.git >> backports-20151218-0-g2f58d9d >> [ 9.585694] ip_tables: (C) 2000-2006 Netfilter Core Team >> [ 9.596751] Infineon Technologies DEU driver version 2.0.0 >> [ 9.602828] IFX DEU DES initialized (multiblock). >> [ 9.607104] IFX DEU AES initialized (multiblock). >> [ 9.611236] IFX DEU ARC4 initialized (multiblock). >> [ 9.615898] IFX DEU SHA1 initialized. >> [ 9.619394] IFX DEU MD5 initialized. >> [ 9.623068] IFX DEU SHA1_HMAC initialized. >> [ 9.627173] IFX DEU MD5_HMAC initialized. >> [ 9.637542] nf_conntrack version 0.5.0 (1946 buckets, 7784 max) >> [ 9.663906] NET: Registered protocol family 24 >> [ 9.689430] xt_time: kernel timezone is -0000 >> [ 17.443364] jffs2_scan_eraseblock(): End of filesystem marker found at >> 0x0 >> [ 17.448921] jffs2_build_filesystem(): unlocking the mtd device... done. >> [ 17.455397] jffs2_build_filesystem(): erasing all blocks after the end >> marker... >> [ 32.627514] random: nonblocking pool is initialized >> [ 73.855188] done. >> [ 73.855719] jffs2: notice: (926) jffs2_build_xattr_subsystem: complete >> building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref >> (0 dead, 0 orphan) found. >> root at OpenWrt:/# > Maybe you can create a common .dtsi file for FRITZ3370 and FRITZ7360SL. > I haven't looked at it in detail, but AVM devices usually have a lot > in common when they are based on the same platform (in this case: > VRX200). > > One last note: I am not sure about the status of the current TFFS (the > MAC addresses, etc are stored there) driver and how you can use it > from userspace (to assign the correct MAC addresses for example). Some > time ago I wrote a userspace replacement for the in-kernel TFFS > driver, which you can find here: > https://github.com/xdarklight/fritz_tffs_tools > However, please note that my tool is basically untested! > > > Martin > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From kron at animeland.de Sun May 8 04:33:03 2016 From: kron at animeland.de (Sebastian Ortwein) Date: Sun, 8 May 2016 10:33:03 +0200 Subject: [OpenWrt-Devel] Add support for AVM Fritzbox 7360 SL In-Reply-To: <572E254E.4030409@gmail.com> References: <69086bb8-44aa-05e4-a550-ee1b13633b4a@animeland.de> <572E254E.4030409@gmail.com> Message-ID: <44031fa7-cb40-d37c-79bd-f338bfba8b68@animeland.de> Am 07.05.2016 um 19:26 schrieb Sylwek ScApi: > W dniu 2016-05-07 o 09:53, Martin Blumenstingl pisze: >> On Sat, May 7, 2016 at 12:40 AM, Sebastian Ortwein wrote: >>> Hey >>> >>> I have tried do get openwrt working on my Fritzbox. Openwrt will start >>> Network and VDSL Modem is working. But WLAN ist not working. The Chip is >>> supported bei the ath9k driver. Any hint how I can get Wifi working ? >> I see you already got most things working - see my comments inline. I get the eeprom from the ath9k driver working, but wifi will not showed. First, I get a error message that from the ath9k driver that the eeprom couldn't load. After PCI Bus is initialize the eeprom is loaded. .............. [ 0.332504] ath9k,eeprom ath9k_eep: failed to load eeprom address [ 0.353603] usbcore: registered new interface driver usbfs [ 0.359114] usbcore: registered new interface driver hub [ 0.364465] usbcore: registered new device driver usb [ 0.369845] PCI host bridge to bus 0000:00 [ 0.373843] pci_bus 0000:00: root bus resource [mem 0x1c000000-0x1cffffff] [ 0.380756] pci_bus 0000:00: root bus resource [io 0x1d800000-0x1d8fffff] [ 0.387699] pci_bus 0000:00: root bus resource [??? 0x00000000 flags 0x0] [ 0.394553] pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff] [ 0.402584] pci 0000:00:00.0: [15d1:0011] type 01 class 0x060000 [ 0.402621] ifx_pcie_rc_class_early_fixup: fixed pcie host bridge to pci-pci bridge [ 0.420266] ifx_pcie_fixup_resource: fixup host controller 0000:00:00.0 (15d1:0011) [ 0.427855] pci 0000:00:00.0: PME# supported from D0 D3hot [ 0.428422] pci 0000:01:00.0: [168c:ff1c] type 00 class 0x020000 [ 0.428512] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x0000ffff 64bit] [ 0.428665] pci 0000:01:00.0: supports D1 [ 0.428686] pci 0000:01:00.0: PME# supported from D0 D1 D3hot [ 0.428975] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01 [ 0.429015] pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 01 [ 0.429072] pci 0000:00:00.0: BAR 8: assigned [mem 0x1c000000-0x1c0fffff] [ 0.435760] pci 0000:01:00.0: BAR 0: assigned [mem 0x1c000000-0x1c00ffff 64bit] [ 0.443120] pci 0000:00:00.0: PCI bridge to [bus 01] [ 0.448137] pci 0000:00:00.0: bridge window [mem 0x1c000000-0x1c0fffff] ........... [ 1.188886] found entry name -> annex=B [ 1.192650] found entry name -> maca=BC:05:43:D7:1E:7C [ 1.197738] found entry name -> macb=BC:05:43:D7:1E:7D [ 1.202875] found entry name -> macwlan=BC:05:43:D7:1E:7E [ 1.208269] found entry name -> macdsl=BC:05:43:D7:1E:7F [ 1.213632] found entry name -> macwlan2=BC:05:43:D7:1E:81 [ 1.219063] found entry name -> wlan_key=4004584479108575 [ 1.227509] ath9k,eeprom ath9k_eep: endian check enabled. [ 1.231483] ath9k,eeprom ath9k_eep: using random mac [ 1.236475] ath9k,eeprom ath9k_eep: loaded ath9k eeprom [ 1.246508] UBIFS error (pid: 1): cannot open "ubi0:rootfs", error -19 [ 1.257496] VFS: Mounted root (squashfs filesystem) readonly on device 31:3. [ 1.265035] Freeing unused kernel memory: 1224K (804fe000 - 80630000) [ 2.475280] init: Console is alive ............. As you can see OpenWrt will find the mac-adesses from all devices, how can I asign it in the dts file? >>> root at OpenWrt:/# dmesg >>> [ 0.000000] Linux version 4.4.7 (sebastian at sebastian-desktop) (gcc >>> version 5.3.0 (OpenWrt GCC 5.3.0 r49296) ) #1 Fri May 6 22:23:36 UTC 2016 >>> [ 0.000000] SoC: xRX200 rev 1.1 >>> [ 0.000000] bootconsole [early0] enabled >>> [ 0.000000] CPU0 revision is: 00019555 (MIPS 34Kc) >>> [ 0.000000] MIPS: machine is FRITZ7360SL - 1&1 HomeServer >>> [ 0.000000] Determined physical RAM map: >>> [ 0.000000] memory: 08000000 @ 00000000 (usable) >>> [ 0.000000] Initrd not found or empty - disabling initrd >>> [ 0.000000] Zone ranges: >>> [ 0.000000] Normal [mem 0x0000000000000000-0x0000000007ffffff] >>> [ 0.000000] Movable zone start for each node >>> [ 0.000000] Early memory node ranges >>> [ 0.000000] node 0: [mem 0x0000000000000000-0x0000000007ffffff] >>> [ 0.000000] Initmem setup node 0 [mem >>> 0x0000000000000000-0x0000000007ffffff] >>> [ 0.000000] On node 0 totalpages: 32768 >>> [ 0.000000] free_area_init_node: node 0, pgdat 804d6390, node_mem_map >>> 81007a80 >>> [ 0.000000] Normal zone: 256 pages used for memmap >>> [ 0.000000] Normal zone: 0 pages reserved >>> [ 0.000000] Normal zone: 32768 pages, LIFO batch:7 >>> [ 0.000000] Primary instruction cache 32kB, VIPT, 4-way, linesize 32 >>> bytes. >>> [ 0.000000] Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize >>> 32 bytes >>> [ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 >>> [ 0.000000] pcpu-alloc: [0] 0 >>> [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total >>> pages: 32512 >>> [ 0.000000] Kernel command line: console=ttyLTQ0,115200 init=/etc/preinit >>> [ 0.000000] PID hash table entries: 512 (order: -1, 2048 bytes) >>> [ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 >>> bytes) >>> [ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) >>> [ 0.000000] Writing ErrCtl register=00064202 >>> [ 0.000000] Readback ErrCtl register=00064202 >>> [ 0.000000] Memory: 123376K/131072K available (3764K kernel code, 164K >>> rwdata, 1144K rodata, 1184K init, 211K bss, 7696K reserved, 0K cma-reserved) >>> [ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 >>> [ 0.000000] NR_IRQS:256 >>> [ 0.000000] CPU Clock: 500MHz >>> [ 0.000000] clocksource: MIPS: mask: 0xffffffff max_cycles: 0xffffffff, >>> max_idle_ns: 7645041786 ns >>> [ 0.000012] sched_clock: 32 bits at 250MHz, resolution 4ns, wraps every >>> 8589934590ns >>> [ 0.007862] Calibrating delay loop... 332.54 BogoMIPS (lpj=665088) >>> [ 0.042318] pid_max: default: 32768 minimum: 301 >>> [ 0.047171] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) >>> [ 0.053731] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 >>> bytes) >>> [ 0.066663] clocksource: jiffies: mask: 0xffffffff max_cycles: >>> 0xffffffff, max_idle_ns: 7645041785100000 ns >>> [ 0.076441] pinctrl core: initialized pinctrl subsystem >>> [ 0.082322] NET: Registered protocol family 16 >>> [ 0.091448] pinctrl-xway 1e100b10.pinmux: Init done >>> [ 0.096999] dma-xway 1e104100.dma: Init done - hw rev: 7, ports: 7, >>> channels: 28 >>> [ 0.206470] dcdc-xrx200 1f106a00.dcdc: Core Voltage : 1016 mV >>> [ 0.347018] usbcore: registered new interface driver usbfs >>> [ 0.352523] usbcore: registered new interface driver hub >>> [ 0.357878] usbcore: registered new device driver usb >>> [ 0.363254] PCI host bridge to bus 0000:00 >>> [ 0.367244] pci_bus 0000:00: root bus resource [mem 0x1c000000-0x1cffffff] >>> [ 0.374158] pci_bus 0000:00: root bus resource [io 0x1d800000-0x1d8fffff] >>> [ 0.381101] pci_bus 0000:00: root bus resource [??? 0x00000000 flags 0x0] >>> [ 0.387957] pci_bus 0000:00: No busn resource found for root bus, will use >>> [bus 00-ff] >>> [ 0.395990] pci 0000:00:00.0: [15d1:0011] type 01 class 0x060000 >>> [ 0.396028] ifx_pcie_rc_class_early_fixup: fixed pcie host bridge to pci-pci >>> bridge >>> [ 0.413669] ifx_pcie_fixup_resource: fixup host controller 0000:00:00.0 >>> (15d1:0011) >>> [ 0.421261] pci 0000:00:00.0: PME# supported from D0 D3hot >>> [ 0.421831] pci 0000:01:00.0: [168c:ff1c] type 00 class 0x020000 >> ff1c means that the calibration data was not loaded yet - see >> FRITZ3370.dts for example. > Agreed. >>> [ 0.421921] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x0000ffff 64bit] >>> [ 0.422076] pci 0000:01:00.0: supports D1 >>> [ 0.422096] pci 0000:01:00.0: PME# supported from D0 D1 D3hot >>> [ 0.422408] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01 >>> [ 0.422448] pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 01 >>> [ 0.422506] pci 0000:00:00.0: BAR 8: assigned [mem 0x1c000000-0x1c0fffff] >>> [ 0.429195] pci 0000:01:00.0: BAR 0: assigned [mem 0x1c000000-0x1c00ffff >>> 64bit] >>> [ 0.436557] pci 0000:00:00.0: PCI bridge to [bus 01] >>> [ 0.441574] pci 0000:00:00.0: bridge window [mem 0x1c000000-0x1c0fffff] >>> [ 0.448451] ifx_pcie_bios_map_irq port 0 dev 0000:00:00.0 slot 0 pin 1 >>> [ 0.455100] ifx_pcie_bios_map_irq dev 0000:00:00.0 irq 144 assigned >>> [ 0.461453] ifx_pcie_bios_map_irq port 0 dev 0000:01:00.0 slot 0 pin 1 >>> [ 0.468120] ifx_pcie_bios_map_irq dev 0000:01:00.0 irq 144 assigned >>> [ 0.475465] clocksource: Switched to clocksource MIPS >>> [ 0.482104] NET: Registered protocol family 2 >>> [ 0.487318] TCP established hash table entries: 1024 (order: 0, 4096 bytes) >>> [ 0.494218] TCP bind hash table entries: 1024 (order: 0, 4096 bytes) >>> [ 0.500593] TCP: Hash tables configured (established 1024 bind 1024) >>> [ 0.507105] UDP hash table entries: 256 (order: 0, 4096 bytes) >>> [ 0.512945] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) >>> [ 0.519566] NET: Registered protocol family 1 >>> [ 0.523906] PCI: CLS 0 bytes, default 32 >>> [ 0.524343] gptu: totally 6 16-bit timers/counters >>> [ 0.529186] gptu: misc_register on minor 63 >>> [ 0.533281] gptu: succeeded to request irq 126 >>> [ 0.537770] gptu: succeeded to request irq 127 >>> [ 0.542284] gptu: succeeded to request irq 128 >>> [ 0.546798] gptu: succeeded to request irq 129 >>> [ 0.551313] gptu: succeeded to request irq 130 >>> [ 0.555829] gptu: succeeded to request irq 131 >>> [ 0.561200] phy-xrx200 gphy-xrx200: requesting lantiq/vr9_phy11g_a1x.bin >>> [ 0.568479] phy-xrx200 gphy-xrx200: booting GPHY0 firmware at 7940000 >>> [ 0.574822] phy-xrx200 gphy-xrx200: booting GPHY1 firmware at 7940000 >>> [ 0.682305] futex hash table entries: 256 (order: -1, 3072 bytes) >>> [ 0.715662] squashfs: version 4.0 (2009/01/31) Phillip Lougher >>> [ 0.721392] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) >>> (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc. >>> [ 0.734808] io scheduler noop registered >>> [ 0.738652] io scheduler deadline registered (default) >>> [ 0.744497] 1e100c00.serial: ttyLTQ0 at MMIO 0x1e100c00 (irq = 112, >>> base_baud = 0) is a lantiq,asc >>> [ 0.753399] console [ttyLTQ0] enabled >>> [ 0.760723] bootconsole [early0] disabled >>> [ 0.769781] lantiq nor flash device: 01000000 at 10000000 >>> [ 0.773915] ltq_nor: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer >>> ID 0x000001 Chip ID 0x002101 >>> [ 0.783349] Amd/Fujitsu Extended Query Table at 0x0040 >>> [ 0.788476] Amd/Fujitsu Extended Query version 1.3. >>> [ 0.793512] number of CFI chips: 1 >>> [ 0.796942] 4 ofpart partitions found on MTD device ltq_nor >>> [ 0.802478] Creating 4 MTD partitions on "ltq_nor": >>> [ 0.807360] 0x000000000000-0x000000020000 : "urlader" >>> [ 0.815754] 0x000000020000-0x000000f80000 : "firmware" >>> [ 0.836761] 2 eva-fw partitions found on MTD device firmware >>> [ 0.841008] 0x000000020000-0x0000001bfa74 : "kernel" >>> [ 0.847817] 0x0000001c0100-0x000000f80000 : "rootfs" >>> [ 0.853486] mtd: device 3 (rootfs) set to be root filesystem >>> [ 0.857792] 1 squashfs-split partitions found on MTD device rootfs >>> [ 0.863912] 0x000000460000-0x000000f80000 : "rootfs_data" >>> [ 0.871543] 0x000000f80000-0x000000fc0000 : "tffs (1)" >>> [ 0.877447] 0x000000fc0000-0x000001000000 : "tffs (2)" >>> [ 0.986126] libphy: lantiq,xrx200-mdio: probed >>> [ 0.996971] eth0: attached PHY [Generic PHY] (phy_addr=0:00, irq=-1) >>> [ 1.002324] eth0: attached PHY [Generic PHY] (phy_addr=0:01, irq=-1) >> I remember reading somewhere that there are two AR8030 10/100 PHYs. >> I suggest you enable CONFIG_AT803X_PHY and assign the reset GPIOs to >> these PHYs, due to a hardware bug in them (see >> https://github.com/torvalds/linux/blob/master/drivers/net/phy/at803x.c#L351) > If wiki is right then there are : > > "VDSL2, 2x LAN 1Gbit, 2x LAN 100Mbit, WLAN 802.11 b/g/n 2.4 GHz bis > 300 Mbit/s" > > I don't see any other chips on pcb. The wiki is right. I will upload some images to the openwrt Wiki when the box is working. But phy0 and phy1 works only somtimes. In my dts file I assigned the reset GPIO's like in the FRITZ3370.dts file. I have take GPIO config from the AVM GPL sources. Is there anything I forgot orwrong in my new DTS file ? >>> [ 1.072164] eth0: attached PHY [Lantiq XWAY VR9 GPHY 11G v1.4] >>> (phy_addr=0:11, irq=-1) >>> [ 1.140155] eth0: attached PHY [Lantiq XWAY VR9 GPHY 11G v1.4] >>> (phy_addr=0:13, irq=-1) >>> [ 1.148042] wdt 1f8803f0.watchdog: Init done >>> [ 1.153878] NET: Registered protocol family 10 >>> [ 1.162382] NET: Registered protocol family 17 >>> [ 1.165538] bridge: automatic filtering via arp/ip/ip6tables has been >>> deprecated. Update your scripts to load br_netfilter if you need this. >>> [ 1.178060] 8021q: 802.1Q VLAN Support v1.8 >>> [ 1.182319] found entry name -> annex=B >>> [ 1.186088] found entry name -> maca=BC:05:43:D7:1E:7C >>> [ 1.191177] found entry name -> macb=BC:05:43:D7:1E:7D >>> [ 1.196312] found entry name -> macwlan=BC:05:43:D7:1E:7E >>> [ 1.201706] found entry name -> macdsl=BC:05:43:D7:1E:7F >>> [ 1.207069] found entry name -> macwlan2=BC:05:43:D7:1E:81 >>> [ 1.212501] found entry name -> wlan_key=4004584479108575 >>> [ 1.223899] UBIFS error (pid: 1): cannot open "ubi0:rootfs", error -19 >>> [ 1.233871] VFS: Mounted root (squashfs filesystem) readonly on device >>> 31:3. >>> [ 1.241380] Freeing unused kernel memory: 1184K (804f8000 - 80620000) >>> [ 2.417706] init: Console is alive >>> [ 2.420017] init: - watchdog - >>> [ 3.187559] eth0: port 1 got link >>> [ 3.974342] SCSI subsystem initialized >>> [ 3.989600] usbcore: registered new interface driver usb-storage >>> [ 3.997229] init: - preinit - >>> [ 4.510986] random: procd urandom read with 17 bits of entropy available >>> [ 7.816027] mount_root: jffs2 not ready yet, using temporary tmpfs >>> overlay >>> [ 7.836202] procd: - early - >>> [ 7.837807] procd: - watchdog - >>> [ 8.572768] procd: - ubus - >>> [ 8.627629] procd: - init - >>> [ 9.476796] IFXOS, Version 1.5.19 (c) Copyright 2009, Lantiq Deutschland >>> GmbH >>> [ 9.486752] NET: Registered protocol family 8 >>> [ 9.489719] NET: Registered protocol family 20 >>> [ 9.500912] PPP generic driver version 2.4.2 >>> [ 9.511937] ip6_tables: (C) 2000-2006 Netfilter Core Team >>> [ 9.537506] Lantiq (VRX) DSL CPE MEI driver, version 1.4.8.5, (c) 2013 >>> Lantiq Deutschland GmbH >>> [ 9.537506] >>> [ 9.537506] Lantiq CPE API Driver version: DSL CPE API V4.16.6.3 >>> [ 9.558430] >>> [ 9.558430] Predefined debug level: 3 >>> [ 9.569131] Loading modules backported from Linux version >>> v4.4-rc5-1913-gc8fdf68 >>> [ 9.575144] Backport generated by backports.git >>> backports-20151218-0-g2f58d9d >>> [ 9.585694] ip_tables: (C) 2000-2006 Netfilter Core Team >>> [ 9.596751] Infineon Technologies DEU driver version 2.0.0 >>> [ 9.602828] IFX DEU DES initialized (multiblock). >>> [ 9.607104] IFX DEU AES initialized (multiblock). >>> [ 9.611236] IFX DEU ARC4 initialized (multiblock). >>> [ 9.615898] IFX DEU SHA1 initialized. >>> [ 9.619394] IFX DEU MD5 initialized. >>> [ 9.623068] IFX DEU SHA1_HMAC initialized. >>> [ 9.627173] IFX DEU MD5_HMAC initialized. >>> [ 9.637542] nf_conntrack version 0.5.0 (1946 buckets, 7784 max) >>> [ 9.663906] NET: Registered protocol family 24 >>> [ 9.689430] xt_time: kernel timezone is -0000 >>> [ 17.443364] jffs2_scan_eraseblock(): End of filesystem marker found at >>> 0x0 >>> [ 17.448921] jffs2_build_filesystem(): unlocking the mtd device... done. >>> [ 17.455397] jffs2_build_filesystem(): erasing all blocks after the end >>> marker... >>> [ 32.627514] random: nonblocking pool is initialized >>> [ 73.855188] done. >>> [ 73.855719] jffs2: notice: (926) jffs2_build_xattr_subsystem: complete >>> building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref >>> (0 dead, 0 orphan) found. >>> root at OpenWrt:/# >> Maybe you can create a common .dtsi file for FRITZ3370 and FRITZ7360SL. >> I haven't looked at it in detail, but AVM devices usually have a lot >> in common when they are based on the same platform (in this case: >> VRX200). >> >> One last note: I am not sure about the status of the current TFFS (the >> MAC addresses, etc are stored there) driver and how you can use it >> from userspace (to assign the correct MAC addresses for example). Some >> time ago I wrote a userspace replacement for the in-kernel TFFS >> driver, which you can find here: >> https://github.com/xdarklight/fritz_tffs_tools >> However, please note that my tool is basically untested! >> >> >> Martin >> _______________________________________________ >> openwrt-devel mailing list >> openwrt-devel at lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: FRITZ7360SL.dts Type: audio/vnd.dts Size: 4004 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: avm_hw_config_hw181.h Type: text/x-chdr Size: 13518 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From mschiffer at universe-factory.net Sun May 8 06:44:59 2016 From: mschiffer at universe-factory.net (Matthias Schiffer) Date: Sun, 8 May 2016 12:44:59 +0200 Subject: [OpenWrt-Devel] [PATCH 01/??] [tools] make-ext4fs glibc >= 2.23 compat In-Reply-To: <571DE63E.2040405@gmail.com> References: <571DE63E.2040405@gmail.com> Message-ID: <6751cf75-9eeb-8d50-1740-93c297312718@universe-factory.net> On 04/25/2016 11:41 AM, Weedy wrote: > With the update to glibc 2.23, sys/types.h doesn't inherit > sys/sysmacros.h anymore. We need to include it manually. Hi, what kind of system are you building on? Many distributions have updated to glibc 2.23 (Arch Linux, Ubuntu), but don't seem to be affected by your issue. Regards, Matthias > > > --- /dev/null 2016-04-18 05:53:30.273258717 -0400 > +++ tools/make-ext4fs/patches/125-glibc-2.23-sysmacros.patch 2016-04-24 > 14:50:33.932873523 -0400 > @@ -0,0 +1,10 @@ > +--- a/ext4_utils.h 2016-04-24 14:47:50.207888150 -0400 > ++++ b/ext4_utils.h 2016-04-24 14:48:11.761438966 -0400 > +@@ -30,6 +30,7 @@ > + #include > + > + #include > ++#include > + #include > + #include > + #include > > > This is a test for my mail client. > Please tell me if I need to change anything. > I have patched the rest of the host packages this update broke. > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From martin.blumenstingl at googlemail.com Sun May 8 08:56:16 2016 From: martin.blumenstingl at googlemail.com (Martin Blumenstingl) Date: Sun, 8 May 2016 14:56:16 +0200 Subject: [OpenWrt-Devel] Add support for AVM Fritzbox 7360 SL In-Reply-To: <44031fa7-cb40-d37c-79bd-f338bfba8b68@animeland.de> References: <69086bb8-44aa-05e4-a550-ee1b13633b4a@animeland.de> <572E254E.4030409@gmail.com> <44031fa7-cb40-d37c-79bd-f338bfba8b68@animeland.de> Message-ID: On Sun, May 8, 2016 at 10:33 AM, Sebastian Ortwein wrote: > I get the eeprom from the ath9k driver working, but wifi will not showed. > First, I get a error message that from the ath9k driver that the eeprom > couldn't load. After PCI Bus is initialize the eeprom is loaded. That is "normal" - nothing to worry about here. > [ 1.188886] found entry name -> annex=B > [ 1.192650] found entry name -> maca=BC:05:43:D7:1E:7C > [ 1.197738] found entry name -> macb=BC:05:43:D7:1E:7D > [ 1.202875] found entry name -> macwlan=BC:05:43:D7:1E:7E > [ 1.208269] found entry name -> macdsl=BC:05:43:D7:1E:7F > [ 1.213632] found entry name -> macwlan2=BC:05:43:D7:1E:81 > [ 1.219063] found entry name -> wlan_key=4004584479108575 > [ 1.227509] ath9k,eeprom ath9k_eep: endian check enabled. > [ 1.231483] ath9k,eeprom ath9k_eep: using random mac > [ 1.236475] ath9k,eeprom ath9k_eep: loaded ath9k eeprom > [ 1.246508] UBIFS error (pid: 1): cannot open "ubi0:rootfs", error -19 > [ 1.257496] VFS: Mounted root (squashfs filesystem) readonly on device > 31:3. > [ 1.265035] Freeing unused kernel memory: 1224K (804fe000 - 80630000) > [ 2.475280] init: Console is alive > ............. > > As you can see OpenWrt will find the mac-adesses from all devices, how can I > asign it in the dts file? I think you can't (at least not with the current tffs driver). All it currently does is printing the mac addresses: [0] My fritz_tffs_read tool is userspace only. The only downside is that you currently cannot userspace tools to set the mac address in the ath9k calibration data. We would need a solution like Christian's OWL-loader, see [1] (or another TFFS kernel driver). > The wiki is right. I will upload some images to the openwrt Wiki when the > box is working. > But phy0 and phy1 works only somtimes. In my dts file I assigned the reset > GPIO's like in the FRITZ3370.dts file. > I have take GPIO config from the AVM GPL sources. Is there anything I forgot > orwrong in my new DTS file ? I think the GPIOs definition is in the wrong place - it has to be per PHY (thus you should put it into the mdio at 0 section below). I cannot see any ath9k messages in your kernel log - are you sure it's being installed (/lib/modules/*/ath9k.ko)? Your first patch lists kmod-ath9k, but if you added that after you generated your .config then you're probably still missing it. Please check "grep kmod-ath9k .config" and enable (set it to =y/built-in) it if it's missing. Martin [0] https://github.com/openwrt/openwrt/blob/master/target/linux/lantiq/patches-4.4/0007-MIPS-lantiq-add-basic-tffs-driver.patch [1] https://lists.openwrt.org/pipermail/openwrt-devel/2016-April/040755.html _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From kron at animeland.de Sun May 8 11:49:49 2016 From: kron at animeland.de (Sebastian Ortwein) Date: Sun, 8 May 2016 17:49:49 +0200 Subject: [OpenWrt-Devel] Add support for AVM Fritzbox 7360 SL In-Reply-To: References: <69086bb8-44aa-05e4-a550-ee1b13633b4a@animeland.de> <572E254E.4030409@gmail.com> <44031fa7-cb40-d37c-79bd-f338bfba8b68@animeland.de> Message-ID: <93a04c66-d6a4-1c5f-d16c-80db337b6d3c@animeland.de> Am 08.05.2016 um 14:56 schrieb Martin Blumenstingl: > On Sun, May 8, 2016 at 10:33 AM, Sebastian Ortwein wrote: >> I get the eeprom from the ath9k driver working, but wifi will not showed. >> First, I get a error message that from the ath9k driver that the eeprom >> couldn't load. After PCI Bus is initialize the eeprom is loaded. > That is "normal" - nothing to worry about here. > >> [ 1.188886] found entry name -> annex=B >> [ 1.192650] found entry name -> maca=BC:05:43:D7:1E:7C >> [ 1.197738] found entry name -> macb=BC:05:43:D7:1E:7D >> [ 1.202875] found entry name -> macwlan=BC:05:43:D7:1E:7E >> [ 1.208269] found entry name -> macdsl=BC:05:43:D7:1E:7F >> [ 1.213632] found entry name -> macwlan2=BC:05:43:D7:1E:81 >> [ 1.219063] found entry name -> wlan_key=4004584479108575 >> [ 1.227509] ath9k,eeprom ath9k_eep: endian check enabled. >> [ 1.231483] ath9k,eeprom ath9k_eep: using random mac >> [ 1.236475] ath9k,eeprom ath9k_eep: loaded ath9k eeprom >> [ 1.246508] UBIFS error (pid: 1): cannot open "ubi0:rootfs", error -19 >> [ 1.257496] VFS: Mounted root (squashfs filesystem) readonly on device >> 31:3. >> [ 1.265035] Freeing unused kernel memory: 1224K (804fe000 - 80630000) >> [ 2.475280] init: Console is alive >> ............. >> >> As you can see OpenWrt will find the mac-adesses from all devices, how can I >> asign it in the dts file? > I think you can't (at least not with the current tffs driver). All it > currently does is printing the mac addresses: [0] > My fritz_tffs_read tool is userspace only. The only downside is that > you currently cannot userspace tools to set the mac address in the > ath9k calibration data. We would need a solution like Christian's > OWL-loader, see [1] (or another TFFS kernel driver). > >> The wiki is right. I will upload some images to the openwrt Wiki when the >> box is working. >> But phy0 and phy1 works only somtimes. In my dts file I assigned the reset >> GPIO's like in the FRITZ3370.dts file. >> I have take GPIO config from the AVM GPL sources. Is there anything I forgot >> orwrong in my new DTS file ? > I think the GPIOs definition is in the wrong place - it has to be per > PHY (thus you should put it into the mdio at 0 section below). can I add it the following way ? mdio at 0 { #address-cells = <1>; #size-cells = <0>; compatible = "lantiq,xrx200-mdio"; phy0: ethernet-phy at 0 { reg = <0x0>; compatible = "lantiq,phy11g", "ethernet-phy-ieee802.3-c22"; gpios = <&gpio 37 0>; }; phy1: ethernet-phy at 1 { reg = <0x1>; compatible = "lantiq,phy11g", "ethernet-phy-ieee802.3-c22"; gpios = <&gpio 44 0>; }; phy11: ethernet-phy at 11 { reg = <0x11>; compatible = "lantiq,phy11g", "ethernet-phy-ieee802.3-c22"; }; phy13: ethernet-phy at 13 { reg = <0x13>; compatible = "lantiq,phy11g", "ethernet-phy-ieee802.3-c22"; }; > > I cannot see any ath9k messages in your kernel log - are you sure it's > being installed (/lib/modules/*/ath9k.ko)? > Your first patch lists kmod-ath9k, but if you added that after you > generated your .config then you're probably still missing it. > Please check "grep kmod-ath9k .config" and enable (set it to > =y/built-in) it if it's missing. I have not disable the ath9k driver. it is present and loaded. root at OpenWrt:/# ls /lib/modules/*/ath9k.ko /lib/modules/4.4.7/ath9k.ko root at OpenWrt:/# lsmod act_connmark 1712 0 act_mirred 2800 0 act_skbedit 1744 0 aead 3649 0 ath 21317 3 ath9k ath9k 101900 0 ath9k_common 20142 1 ath9k ath9k_hw 348113 2 ath9k atm 37986 2 pppoatm br2684 6544 0 cfg80211 230563 4 ath9k Sebastian > > > Martin > > > [0] https://github.com/openwrt/openwrt/blob/master/target/linux/lantiq/patches-4.4/0007-MIPS-lantiq-add-basic-tffs-driver.patch > [1] https://lists.openwrt.org/pipermail/openwrt-devel/2016-April/040755.html _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From martin.blumenstingl at googlemail.com Sun May 8 12:40:18 2016 From: martin.blumenstingl at googlemail.com (Martin Blumenstingl) Date: Sun, 8 May 2016 18:40:18 +0200 Subject: [OpenWrt-Devel] Add support for AVM Fritzbox 7360 SL In-Reply-To: <93a04c66-d6a4-1c5f-d16c-80db337b6d3c@animeland.de> References: <69086bb8-44aa-05e4-a550-ee1b13633b4a@animeland.de> <572E254E.4030409@gmail.com> <44031fa7-cb40-d37c-79bd-f338bfba8b68@animeland.de> <93a04c66-d6a4-1c5f-d16c-80db337b6d3c@animeland.de> Message-ID: On Sun, May 8, 2016 at 5:49 PM, Sebastian Ortwein wrote: > can I add it the following way ? > mdio at 0 { > #address-cells = <1>; > #size-cells = <0>; > compatible = "lantiq,xrx200-mdio"; > phy0: ethernet-phy at 0 { > reg = <0x0>; > compatible = "lantiq,phy11g", > "ethernet-phy-ieee802.3-c22"; > gpios = <&gpio 37 0>; > }; > phy1: ethernet-phy at 1 { > reg = <0x1>; > compatible = "lantiq,phy11g", > "ethernet-phy-ieee802.3-c22"; > gpios = <&gpio 44 0>; > }; > phy11: ethernet-phy at 11 { > reg = <0x11>; > compatible = "lantiq,phy11g", > "ethernet-phy-ieee802.3-c22"; > }; > phy13: ethernet-phy at 13 { > reg = <0x13>; > compatible = "lantiq,phy11g", > "ethernet-phy-ieee802.3-c22"; > }; I think you have to name the property "reset-gpios", but apart from that it looks good. >> I cannot see any ath9k messages in your kernel log - are you sure it's >> being installed (/lib/modules/*/ath9k.ko)? >> Your first patch lists kmod-ath9k, but if you added that after you >> generated your .config then you're probably still missing it. >> Please check "grep kmod-ath9k .config" and enable (set it to >> =y/built-in) it if it's missing. > > I have not disable the ath9k driver. it is present and loaded. I think I see the problem after looking at your .dts again: you *must* specify the ath,pci-slot property, otherwise the fixup is not executed. It seems that the wifi part is similar to the TD-W8980 (AR9287 behind the PCIe-to-PCI bridge), so "0" should be the right value. (otherwise it's pretty easy to find out by looking at sysfs: /sys/bus/pci/devices/0000\:00\:0e.0/ -> that's where the ath9k device on HH5A can be found, there we use ath,pci-slot = <0xe>;) Martin [0] https://github.com/openwrt/openwrt/blob/master/target/linux/lantiq/patches-4.4/0035-owrt-lantiq-wifi-and-ethernet-eeprom-handling.patch#L178 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From banglang.huang at foxmail.com Sun May 8 22:37:43 2016 From: banglang.huang at foxmail.com (=?utf-8?B?VHltb24=?=) Date: Mon, 9 May 2016 10:37:43 +0800 Subject: [OpenWrt-Devel] GCC-5.3.1 Build with Go language support, but can not find crti.o crt1.o file Message-ID: Hi all, I am using uClibc and trying to build GCC-5.3.1 (Linaro) with Go language support, however I meet a issue that "can not find crti.o crt1.o file". I'd tried the approaches which searched by google/stackoverflow(modified LIBRARY_PATH in ~/.bashrc), but none of them has effect. Any hints will be appreciated. ------------------ Regards, banglang huang _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From xotic750 at gmail.com Mon May 9 02:08:53 2016 From: xotic750 at gmail.com (Graham Fairweather) Date: Mon, 9 May 2016 08:08:53 +0200 Subject: [OpenWrt-Devel] [PATCH 001/001] [brcm63xx] [v2] Display the correct detected CPU ID Message-ID: From: Graham Fairweather This patch fixes the logged detected CPU ID when an equivalent is used, like in the case where we have a bcm6369 and configuration for a bcm6368 is used. More info can be found at: https://forum.openwrt.org/viewtopic.php?id=64621 https://github.com/Xotic750/openwrt/tree/fix_logged_cpu_id_bcm63xx Signed-off-by: Graham Fairweather --- v2 fixes an issue where the 4.4 kernel uses 'pr_info' rather than 'printk'. Missed the problem in my initial attempts with 'quilt'. --- target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch | 9 +++++++++ target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch | 9 +++++++++ 2 files changed, 18 insertions(+) diff --git a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch index 661abf6..23491aa 100644 --- a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch +++ b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch @@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu variant helper bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT; switch (bcm63xx_cpu_id) { +@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void) + bcm63xx_memory_size = detect_memory_size(); + + printk(KERN_INFO "Detected Broadcom 0x%04x CPU revision %02x\n", +- bcm63xx_cpu_id, bcm63xx_cpu_rev); ++ bcm63xx_cpu_variant, bcm63xx_cpu_rev); + printk(KERN_INFO "CPU frequency is %u MHz\n", + bcm63xx_cpu_freq / 1000000); + printk(KERN_INFO "%uMB of RAM installed\n", --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h @@ -19,6 +19,7 @@ diff --git a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch index 661abf6..330a9e6 100644 --- a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch +++ b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch @@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu variant helper bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT; switch (bcm63xx_cpu_id) { +@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void) + bcm63xx_memory_size = detect_memory_size(); + + pr_info("Detected Broadcom 0x%04x CPU revision %02x\n", +- bcm63xx_cpu_id, bcm63xx_cpu_rev); ++ bcm63xx_cpu_variant, bcm63xx_cpu_rev); + pr_info("CPU frequency is %u MHz\n", + bcm63xx_cpu_freq / 1000000); + pr_info("%uMB of RAM installed\n", --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h @@ -19,6 +19,7 @@ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From xotic750 at gmail.com Mon May 9 02:18:50 2016 From: xotic750 at gmail.com (Graham Fairweather) Date: Mon, 9 May 2016 08:18:50 +0200 Subject: [OpenWrt-Devel] [PATCHv2 001/001] [brcm63xx] Display the correct detected CPU ID Message-ID: From: Graham Fairweather This patch fixes the logged detected CPU ID when an equivalent is used, like in the case where we have a bcm6369 and configuration for a bcm6368 is used. More info can be found at: https://forum.openwrt.org/viewtopic.php?id=64621 https://github.com/Xotic750/openwrt/tree/fix_logged_cpu_id_bcm63xx Signed-off-by: Graham Fairweather --- v2 fixes an issue where the 4.4 kernel uses 'pr_info' rather than 'printk'. Missed the problem in my initial attempts with 'quilt'. --- target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch | 9 +++++++++ target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch | 9 +++++++++ 2 files changed, 18 insertions(+) diff --git a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch index 661abf6..23491aa 100644 --- a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch +++ b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch @@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu variant helper bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT; switch (bcm63xx_cpu_id) { +@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void) + bcm63xx_memory_size = detect_memory_size(); + + printk(KERN_INFO "Detected Broadcom 0x%04x CPU revision %02x\n", +- bcm63xx_cpu_id, bcm63xx_cpu_rev); ++ bcm63xx_cpu_variant, bcm63xx_cpu_rev); + printk(KERN_INFO "CPU frequency is %u MHz\n", + bcm63xx_cpu_freq / 1000000); + printk(KERN_INFO "%uMB of RAM installed\n", --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h @@ -19,6 +19,7 @@ diff --git a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch index 661abf6..330a9e6 100644 --- a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch +++ b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch @@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu variant helper bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT; switch (bcm63xx_cpu_id) { +@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void) + bcm63xx_memory_size = detect_memory_size(); + + pr_info("Detected Broadcom 0x%04x CPU revision %02x\n", +- bcm63xx_cpu_id, bcm63xx_cpu_rev); ++ bcm63xx_cpu_variant, bcm63xx_cpu_rev); + pr_info("CPU frequency is %u MHz\n", + bcm63xx_cpu_freq / 1000000); + pr_info("%uMB of RAM installed\n", --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h @@ -19,6 +19,7 @@ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From xotic750 at gmail.com Mon May 9 03:48:03 2016 From: xotic750 at gmail.com (Graham Fairweather) Date: Mon, 9 May 2016 09:48:03 +0200 Subject: [OpenWrt-Devel] [PATCH 001/001] [kernel] Bump linux LTS kernel from 4.4.7 to 4.4.9 Message-ID: From: Graham Fairweather Increment PATCH number, added MD5 sum for release. Patches were refreshed. *https://www.kernel.org/ * Signed-off-by: Graham Fairweather --- include/kernel-version.mk | 4 ++-- target/linux/brcm63xx/patches-4.4/202-MTD-DEVICES-m25p80-use-parsers-if-provided-in-flash-.patch | 2 +- target/linux/brcm63xx/patches-4.4/203-MTD-DEVICES-m25p80-add-support-for-limiting-reads.patch | 4 ++-- target/linux/brcm63xx/patches-4.4/414-MTD-m25p80-allow-passing-pp_data.patch | 2 +- target/linux/generic/patches-4.4/045-mtd-devices-m25p80-add-support-for-mmap-read-request.patch | 2 +- target/linux/generic/patches-4.4/081-spi-bcm53xx-add-spi_flash_read-callback-for-MMIO-bas.patch | 12 ++++++------ target/linux/generic/patches-4.4/630-packet_socket_type.patch | 10 +++++----- target/linux/generic/patches-4.4/642-bridge_port_isolate.patch | 4 ++-- target/linux/generic/patches-4.4/645-bridge_multicast_to_unicast.patch | 4 ++-- target/linux/generic/patches-4.4/655-increase_skb_pad.patch | 2 +- target/linux/generic/patches-4.4/656-skb_reduce_truesize-helper.patch | 2 +- target/linux/generic/patches-4.4/666-Add-support-for-MAP-E-FMRs-mesh-mode.patch | 26 +++++++++++++------------- target/linux/generic/patches-4.4/721-phy_packets.patch | 8 ++++---- target/linux/generic/patches-4.4/903-debloat_direct_io.patch | 4 ++-- 14 files changed, 43 insertions(+), 43 deletions(-) diff --git a/include/kernel-version.mk b/include/kernel-version.mk index ba6bf66..cdb404f 100644 --- a/include/kernel-version.mk +++ b/include/kernel-version.mk @@ -5,12 +5,12 @@ LINUX_RELEASE?=1 LINUX_VERSION-3.18 = .29 LINUX_VERSION-4.1 = .23 LINUX_VERSION-4.3 = .4 -LINUX_VERSION-4.4 = .7 +LINUX_VERSION-4.4 = .9 LINUX_KERNEL_MD5SUM-3.18.29 = b25737a0bc98e80d12200de93f239c28 LINUX_KERNEL_MD5SUM-4.1.23 = 5cb969fa874e110118722398b7c72c5d LINUX_KERNEL_MD5SUM-4.3.4 = 5275d02132107c28b85f986bad576d91 -LINUX_KERNEL_MD5SUM-4.4.7 = 4345597c9a10bd73c28b6ae3a854d8d7 +LINUX_KERNEL_MD5SUM-4.4.9 = ec1e5011cc2ab3f441e39716dcf4730e ifdef KERNEL_PATCHVER LINUX_VERSION:=$(KERNEL_PATCHVER)$(strip $(LINUX_VERSION-$(KERNEL_PATCHVER))) diff --git a/target/linux/brcm63xx/patches-4.4/202-MTD-DEVICES-m25p80-use-parsers-if-provided-in-flash-.patch b/target/linux/brcm63xx/patches-4.4/202-MTD-DEVICES-m25p80-use-parsers-if-provided-in-flash-.patch index be62e67..4793836 100644 --- a/target/linux/brcm63xx/patches-4.4/202-MTD-DEVICES-m25p80-use-parsers-if-provided-in-flash-.patch +++ b/target/linux/brcm63xx/patches-4.4/202-MTD-DEVICES-m25p80-use-parsers-if-provided-in-flash-.patch @@ -11,7 +11,7 @@ Signed-off-by: Jonas Gorski --- a/drivers/mtd/devices/m25p80.c +++ b/drivers/mtd/devices/m25p80.c -@@ -229,7 +229,8 @@ static int m25p_probe(struct spi_device +@@ -251,7 +251,8 @@ static int m25p_probe(struct spi_device ppdata.of_node = spi->dev.of_node; diff --git a/target/linux/brcm63xx/patches-4.4/203-MTD-DEVICES-m25p80-add-support-for-limiting-reads.patch b/target/linux/brcm63xx/patches-4.4/203-MTD-DEVICES-m25p80-add-support-for-limiting-reads.patch index 3877442..75a874d 100644 --- a/target/linux/brcm63xx/patches-4.4/203-MTD-DEVICES-m25p80-add-support-for-limiting-reads.patch +++ b/target/linux/brcm63xx/patches-4.4/203-MTD-DEVICES-m25p80-add-support-for-limiting-reads.patch @@ -28,7 +28,7 @@ Signed-off-by: Jonas Gorski size_t *retlen, u_char *buf) { struct m25p *flash = nor->priv; -@@ -152,6 +153,29 @@ static int m25p80_read(struct spi_nor *n +@@ -174,6 +175,29 @@ static int m25p80_read(struct spi_nor *n return 0; } @@ -58,7 +58,7 @@ Signed-off-by: Jonas Gorski static int m25p80_erase(struct spi_nor *nor, loff_t offset) { struct m25p *flash = nor->priv; -@@ -223,6 +247,9 @@ static int m25p_probe(struct spi_device +@@ -245,6 +269,9 @@ static int m25p_probe(struct spi_device else flash_name = spi->modalias; diff --git a/target/linux/brcm63xx/patches-4.4/414-MTD-m25p80-allow-passing-pp_data.patch b/target/linux/brcm63xx/patches-4.4/414-MTD-m25p80-allow-passing-pp_data.patch index e421e9a..bbb565e 100644 --- a/target/linux/brcm63xx/patches-4.4/414-MTD-m25p80-allow-passing-pp_data.patch +++ b/target/linux/brcm63xx/patches-4.4/414-MTD-m25p80-allow-passing-pp_data.patch @@ -10,7 +10,7 @@ Subject: [PATCH 64/79] MTD: m25p80: allow passing pp_data --- a/drivers/mtd/devices/m25p80.c +++ b/drivers/mtd/devices/m25p80.c -@@ -250,6 +250,9 @@ static int m25p_probe(struct spi_device +@@ -272,6 +272,9 @@ static int m25p_probe(struct spi_device if (data) flash->max_transfer_len = data->max_transfer_len; diff --git a/target/linux/generic/patches-4.4/045-mtd-devices-m25p80-add-support-for-mmap-read-request.patch b/target/linux/generic/patches-4.4/045-mtd-devices-m25p80-add-support-for-mmap-read-request.patch index ee85f44..c4c7e6e 100644 --- a/target/linux/generic/patches-4.4/045-mtd-devices-m25p80-add-support-for-mmap-read-request.patch +++ b/target/linux/generic/patches-4.4/045-mtd-devices-m25p80-add-support-for-mmap-read-request.patch @@ -15,7 +15,7 @@ Signed-off-by: Brian Norris --- a/drivers/mtd/devices/m25p80.c +++ b/drivers/mtd/devices/m25p80.c -@@ -131,6 +131,28 @@ static int m25p80_read(struct spi_nor *nor, loff_t from, size_t len, +@@ -131,6 +131,28 @@ static int m25p80_read(struct spi_nor *n /* convert the dummy cycles to the number of bytes */ dummy /= 8; diff --git a/target/linux/generic/patches-4.4/081-spi-bcm53xx-add-spi_flash_read-callback-for-MMIO-bas.patch b/target/linux/generic/patches-4.4/081-spi-bcm53xx-add-spi_flash_read-callback-for-MMIO-bas.patch index 5f131e7..730f41e 100644 --- a/target/linux/generic/patches-4.4/081-spi-bcm53xx-add-spi_flash_read-callback-for-MMIO-bas.patch +++ b/target/linux/generic/patches-4.4/081-spi-bcm53xx-add-spi_flash_read-callback-for-MMIO-bas.patch @@ -34,7 +34,7 @@ Signed-off-by: Mark Brown }; static inline u32 bcm53xxspi_read(struct bcm53xxspi *b53spi, u16 offset) -@@ -32,6 +35,50 @@ static inline void bcm53xxspi_write(struct bcm53xxspi *b53spi, u16 offset, +@@ -32,6 +35,50 @@ static inline void bcm53xxspi_write(stru bcma_write32(b53spi->core, offset, value); } @@ -85,7 +85,7 @@ Signed-off-by: Mark Brown static inline unsigned int bcm53xxspi_calc_timeout(size_t len) { /* Do some magic calculation based on length and buad. Add 10% and 1. */ -@@ -176,6 +223,8 @@ static int bcm53xxspi_transfer_one(struct spi_master *master, +@@ -176,6 +223,8 @@ static int bcm53xxspi_transfer_one(struc u8 *buf; size_t left; @@ -94,7 +94,7 @@ Signed-off-by: Mark Brown if (t->tx_buf) { buf = (u8 *)t->tx_buf; left = t->len; -@@ -206,6 +255,22 @@ static int bcm53xxspi_transfer_one(struct spi_master *master, +@@ -206,6 +255,22 @@ static int bcm53xxspi_transfer_one(struc return 0; } @@ -117,7 +117,7 @@ Signed-off-by: Mark Brown /************************************************** * BCMA **************************************************/ -@@ -222,6 +287,7 @@ MODULE_DEVICE_TABLE(bcma, bcm53xxspi_bcma_tbl); +@@ -222,6 +287,7 @@ MODULE_DEVICE_TABLE(bcma, bcm53xxspi_bcm static int bcm53xxspi_bcma_probe(struct bcma_device *core) { @@ -125,7 +125,7 @@ Signed-off-by: Mark Brown struct bcm53xxspi *b53spi; struct spi_master *master; int err; -@@ -231,7 +297,7 @@ static int bcm53xxspi_bcma_probe(struct bcma_device *core) +@@ -231,7 +297,7 @@ static int bcm53xxspi_bcma_probe(struct return -ENOTSUPP; } @@ -134,7 +134,7 @@ Signed-off-by: Mark Brown if (!master) return -ENOMEM; -@@ -239,11 +305,19 @@ static int bcm53xxspi_bcma_probe(struct bcma_device *core) +@@ -239,11 +305,19 @@ static int bcm53xxspi_bcma_probe(struct b53spi->master = master; b53spi->core = core; diff --git a/target/linux/generic/patches-4.4/630-packet_socket_type.patch b/target/linux/generic/patches-4.4/630-packet_socket_type.patch index d649bf0..48c4220 100644 --- a/target/linux/generic/patches-4.4/630-packet_socket_type.patch +++ b/target/linux/generic/patches-4.4/630-packet_socket_type.patch @@ -51,7 +51,7 @@ Signed-off-by: Felix Fietkau goto out; if (!net_eq(dev_net(dev), sock_net(sk))) -@@ -1982,12 +1984,12 @@ static int packet_rcv(struct sk_buff *sk +@@ -1986,12 +1988,12 @@ static int packet_rcv(struct sk_buff *sk int skb_len = skb->len; unsigned int snaplen, res; @@ -67,7 +67,7 @@ Signed-off-by: Felix Fietkau if (!net_eq(dev_net(dev), sock_net(sk))) goto drop; -@@ -2107,12 +2109,12 @@ static int tpacket_rcv(struct sk_buff *s +@@ -2111,12 +2113,12 @@ static int tpacket_rcv(struct sk_buff *s BUILD_BUG_ON(TPACKET_ALIGN(sizeof(*h.h2)) != 32); BUILD_BUG_ON(TPACKET_ALIGN(sizeof(*h.h3)) != 48); @@ -83,7 +83,7 @@ Signed-off-by: Felix Fietkau if (!net_eq(dev_net(dev), sock_net(sk))) goto drop; -@@ -3097,6 +3099,7 @@ static int packet_create(struct net *net +@@ -3092,6 +3094,7 @@ static int packet_create(struct net *net mutex_init(&po->pg_vec_lock); po->rollover = NULL; po->prot_hook.func = packet_rcv; @@ -91,7 +91,7 @@ Signed-off-by: Felix Fietkau if (sock->type == SOCK_PACKET) po->prot_hook.func = packet_rcv_spkt; -@@ -3712,6 +3715,16 @@ packet_setsockopt(struct socket *sock, i +@@ -3707,6 +3710,16 @@ packet_setsockopt(struct socket *sock, i po->xmit = val ? packet_direct_xmit : dev_queue_xmit; return 0; } @@ -108,7 +108,7 @@ Signed-off-by: Felix Fietkau default: return -ENOPROTOOPT; } -@@ -3764,6 +3777,13 @@ static int packet_getsockopt(struct sock +@@ -3759,6 +3772,13 @@ static int packet_getsockopt(struct sock case PACKET_VNET_HDR: val = po->has_vnet_hdr; break; diff --git a/target/linux/generic/patches-4.4/642-bridge_port_isolate.patch b/target/linux/generic/patches-4.4/642-bridge_port_isolate.patch index 0be8c8f..1dc32b6 100644 --- a/target/linux/generic/patches-4.4/642-bridge_port_isolate.patch +++ b/target/linux/generic/patches-4.4/642-bridge_port_isolate.patch @@ -11,8 +11,8 @@ Isolating individual bridge ports #define BR_PROXYARP_WIFI BIT(10) +#define BR_ISOLATE_MODE BIT(11) - /* values as per ieee8021QBridgeFdbAgingTime */ - #define BR_MIN_AGEING_TIME (10 * HZ) + #define BR_DEFAULT_AGEING_TIME (300 * HZ) + --- a/net/bridge/br_sysfs_if.c +++ b/net/bridge/br_sysfs_if.c @@ -173,6 +173,22 @@ BRPORT_ATTR_FLAG(unicast_flood, BR_FLOOD diff --git a/target/linux/generic/patches-4.4/645-bridge_multicast_to_unicast.patch b/target/linux/generic/patches-4.4/645-bridge_multicast_to_unicast.patch index 59aa1ed..f729f38 100644 --- a/target/linux/generic/patches-4.4/645-bridge_multicast_to_unicast.patch +++ b/target/linux/generic/patches-4.4/645-bridge_multicast_to_unicast.patch @@ -11,8 +11,8 @@ Implement optinal multicast->unicast conversion for igmp snooping #define BR_ISOLATE_MODE BIT(11) +#define BR_MULTICAST_TO_UCAST BIT(12) - /* values as per ieee8021QBridgeFdbAgingTime */ - #define BR_MIN_AGEING_TIME (10 * HZ) + #define BR_DEFAULT_AGEING_TIME (300 * HZ) + --- a/net/bridge/br_multicast.c +++ b/net/bridge/br_multicast.c @@ -42,12 +42,13 @@ static void br_multicast_add_router(stru diff --git a/target/linux/generic/patches-4.4/655-increase_skb_pad.patch b/target/linux/generic/patches-4.4/655-increase_skb_pad.patch index e46e470..ad95d4c 100644 --- a/target/linux/generic/patches-4.4/655-increase_skb_pad.patch +++ b/target/linux/generic/patches-4.4/655-increase_skb_pad.patch @@ -1,6 +1,6 @@ --- a/include/linux/skbuff.h +++ b/include/linux/skbuff.h -@@ -2155,7 +2155,7 @@ static inline int pskb_network_may_pull( +@@ -2179,7 +2179,7 @@ static inline int pskb_network_may_pull( * NET_IP_ALIGN(2) + ethernet_header(14) + IP_header(20/40) + ports(8) */ #ifndef NET_SKB_PAD diff --git a/target/linux/generic/patches-4.4/656-skb_reduce_truesize-helper.patch b/target/linux/generic/patches-4.4/656-skb_reduce_truesize-helper.patch index 341a31b..dad7448 100644 --- a/target/linux/generic/patches-4.4/656-skb_reduce_truesize-helper.patch +++ b/target/linux/generic/patches-4.4/656-skb_reduce_truesize-helper.patch @@ -14,7 +14,7 @@ when needed. --- a/include/linux/skbuff.h +++ b/include/linux/skbuff.h -@@ -2200,6 +2200,24 @@ static inline void pskb_trim_unique(stru +@@ -2224,6 +2224,24 @@ static inline void pskb_trim_unique(stru BUG_ON(err); } diff --git a/target/linux/generic/patches-4.4/666-Add-support-for-MAP-E-FMRs-mesh-mode.patch b/target/linux/generic/patches-4.4/666-Add-support-for-MAP-E-FMRs-mesh-mode.patch index 7123c80..0d4409e 100644 --- a/target/linux/generic/patches-4.4/666-Add-support-for-MAP-E-FMRs-mesh-mode.patch +++ b/target/linux/generic/patches-4.4/666-Add-support-for-MAP-E-FMRs-mesh-mode.patch @@ -295,15 +295,15 @@ Signed-off-by: Steven Barth __skb_tunnel_rx(skb, t->dev, t->net); -@@ -1179,6 +1316,7 @@ ip4ip6_tnl_xmit(struct sk_buff *skb, str +@@ -1224,6 +1361,7 @@ ip6ip6_tnl_xmit(struct sk_buff *skb, str __u32 mtu; u8 tproto; int err; + struct __ip6_tnl_fmr *fmr; tproto = ACCESS_ONCE(t->parms.proto); - if (tproto != IPPROTO_IPIP && tproto != 0) -@@ -1198,6 +1336,18 @@ ip4ip6_tnl_xmit(struct sk_buff *skb, str + if ((tproto != IPPROTO_IPV6 && tproto != 0) || +@@ -1254,6 +1392,18 @@ ip6ip6_tnl_xmit(struct sk_buff *skb, str if (t->parms.flags & IP6_TNL_F_USE_ORIG_FWMARK) fl6.flowi6_mark = skb->mark; @@ -321,8 +321,8 @@ Signed-off-by: Steven Barth + err = ip6_tnl_xmit2(skb, dev, dsfield, &fl6, encap_limit, &mtu); if (err != 0) { - /* XXX: send ICMP error even if DF is not set. */ -@@ -1366,6 +1516,14 @@ ip6_tnl_change(struct ip6_tnl *t, const + if (err == -EMSGSIZE) +@@ -1368,6 +1518,14 @@ ip6_tnl_change(struct ip6_tnl *t, const t->parms.flowinfo = p->flowinfo; t->parms.link = p->link; t->parms.proto = p->proto; @@ -337,7 +337,7 @@ Signed-off-by: Steven Barth ip6_tnl_dst_reset(t); ip6_tnl_link_config(t); return 0; -@@ -1404,6 +1562,7 @@ ip6_tnl_parm_from_user(struct __ip6_tnl_ +@@ -1406,6 +1564,7 @@ ip6_tnl_parm_from_user(struct __ip6_tnl_ p->flowinfo = u->flowinfo; p->link = u->link; p->proto = u->proto; @@ -345,7 +345,7 @@ Signed-off-by: Steven Barth memcpy(p->name, u->name, sizeof(u->name)); } -@@ -1699,6 +1858,15 @@ static int ip6_tnl_validate(struct nlatt +@@ -1701,6 +1860,15 @@ static int ip6_tnl_validate(struct nlatt return 0; } @@ -361,7 +361,7 @@ Signed-off-by: Steven Barth static void ip6_tnl_netlink_parms(struct nlattr *data[], struct __ip6_tnl_parm *parms) { -@@ -1730,6 +1898,46 @@ static void ip6_tnl_netlink_parms(struct +@@ -1732,6 +1900,46 @@ static void ip6_tnl_netlink_parms(struct if (data[IFLA_IPTUN_PROTO]) parms->proto = nla_get_u8(data[IFLA_IPTUN_PROTO]); @@ -408,7 +408,7 @@ Signed-off-by: Steven Barth } static int ip6_tnl_newlink(struct net *src_net, struct net_device *dev, -@@ -1782,6 +1990,12 @@ static void ip6_tnl_dellink(struct net_d +@@ -1784,6 +1992,12 @@ static void ip6_tnl_dellink(struct net_d static size_t ip6_tnl_get_size(const struct net_device *dev) { @@ -421,7 +421,7 @@ Signed-off-by: Steven Barth return /* IFLA_IPTUN_LINK */ nla_total_size(4) + -@@ -1799,6 +2013,24 @@ static size_t ip6_tnl_get_size(const str +@@ -1801,6 +2015,24 @@ static size_t ip6_tnl_get_size(const str nla_total_size(4) + /* IFLA_IPTUN_PROTO */ nla_total_size(1) + @@ -446,7 +446,7 @@ Signed-off-by: Steven Barth 0; } -@@ -1806,6 +2038,9 @@ static int ip6_tnl_fill_info(struct sk_b +@@ -1808,6 +2040,9 @@ static int ip6_tnl_fill_info(struct sk_b { struct ip6_tnl *tunnel = netdev_priv(dev); struct __ip6_tnl_parm *parm = &tunnel->parms; @@ -456,7 +456,7 @@ Signed-off-by: Steven Barth if (nla_put_u32(skb, IFLA_IPTUN_LINK, parm->link) || nla_put_in6_addr(skb, IFLA_IPTUN_LOCAL, &parm->laddr) || -@@ -1814,8 +2049,27 @@ static int ip6_tnl_fill_info(struct sk_b +@@ -1816,8 +2051,27 @@ static int ip6_tnl_fill_info(struct sk_b nla_put_u8(skb, IFLA_IPTUN_ENCAP_LIMIT, parm->encap_limit) || nla_put_be32(skb, IFLA_IPTUN_FLOWINFO, parm->flowinfo) || nla_put_u32(skb, IFLA_IPTUN_FLAGS, parm->flags) || @@ -485,7 +485,7 @@ Signed-off-by: Steven Barth return 0; nla_put_failure: -@@ -1839,6 +2093,7 @@ static const struct nla_policy ip6_tnl_p +@@ -1841,6 +2095,7 @@ static const struct nla_policy ip6_tnl_p [IFLA_IPTUN_FLOWINFO] = { .type = NLA_U32 }, [IFLA_IPTUN_FLAGS] = { .type = NLA_U32 }, [IFLA_IPTUN_PROTO] = { .type = NLA_U8 }, diff --git a/target/linux/generic/patches-4.4/721-phy_packets.patch b/target/linux/generic/patches-4.4/721-phy_packets.patch index 04bafcd..79af5f9 100644 --- a/target/linux/generic/patches-4.4/721-phy_packets.patch +++ b/target/linux/generic/patches-4.4/721-phy_packets.patch @@ -1,6 +1,6 @@ --- a/include/linux/netdevice.h +++ b/include/linux/netdevice.h -@@ -1297,6 +1297,7 @@ enum netdev_priv_flags { +@@ -1298,6 +1298,7 @@ enum netdev_priv_flags { IFF_NO_QUEUE = 1<<21, IFF_OPENVSWITCH = 1<<22, IFF_L3MDEV_SLAVE = 1<<23, @@ -8,7 +8,7 @@ }; #define IFF_802_1Q_VLAN IFF_802_1Q_VLAN -@@ -1323,6 +1324,7 @@ enum netdev_priv_flags { +@@ -1324,6 +1325,7 @@ enum netdev_priv_flags { #define IFF_NO_QUEUE IFF_NO_QUEUE #define IFF_OPENVSWITCH IFF_OPENVSWITCH #define IFF_L3MDEV_SLAVE IFF_L3MDEV_SLAVE @@ -41,7 +41,7 @@ */ --- a/include/linux/skbuff.h +++ b/include/linux/skbuff.h -@@ -2186,6 +2186,10 @@ static inline int pskb_trim(struct sk_bu +@@ -2210,6 +2210,10 @@ static inline int pskb_trim(struct sk_bu return (len < skb->len) ? __pskb_trim(skb, len) : 0; } @@ -52,7 +52,7 @@ /** * pskb_trim_unique - remove end from a paged unique (not cloned) buffer * @skb: buffer to alter -@@ -2308,16 +2312,6 @@ static inline struct sk_buff *dev_alloc_ +@@ -2332,16 +2336,6 @@ static inline struct sk_buff *dev_alloc_ } diff --git a/target/linux/generic/patches-4.4/903-debloat_direct_io.patch b/target/linux/generic/patches-4.4/903-debloat_direct_io.patch index ee85c40..460da1d 100644 --- a/target/linux/generic/patches-4.4/903-debloat_direct_io.patch +++ b/target/linux/generic/patches-4.4/903-debloat_direct_io.patch @@ -26,7 +26,7 @@ endif --- a/include/linux/fs.h +++ b/include/linux/fs.h -@@ -2681,6 +2681,7 @@ enum { +@@ -2691,6 +2691,7 @@ enum { DIO_SKIP_DIO_COUNT = 0x08, }; @@ -34,7 +34,7 @@ void dio_end_io(struct bio *bio, int error); ssize_t __blockdev_direct_IO(struct kiocb *iocb, struct inode *inode, -@@ -2688,6 +2689,18 @@ ssize_t __blockdev_direct_IO(struct kioc +@@ -2698,6 +2699,18 @@ ssize_t __blockdev_direct_IO(struct kioc loff_t offset, get_block_t get_block, dio_iodone_t end_io, dio_submit_t submit_io, int flags); -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From xotic750 at gmail.com Mon May 9 03:52:49 2016 From: xotic750 at gmail.com (Graham Fairweather) Date: Mon, 9 May 2016 09:52:49 +0200 Subject: [OpenWrt-Devel] [PATCH 001/001] [brcm63xx] Display the correct detected CPU ID Message-ID: From: Graham Fairweather This patch fixes the logged detected CPU ID when an equivalent is used, like in the case where we have a bcm6369 and configuration for a bcm6368 is used. More info can be found at: https://forum.openwrt.org/viewtopic.php?id=64621 https://github.com/Xotic750/openwrt/tree/fix_logged_cpu_id_bcm63xx Signed-off-by: Graham Fairweather --- v2 fixes an issue where the 4.4 kernel uses 'pr_info' rather than 'printk'. Missed the problem in my initial attempts with 'quilt'. --- target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch | 9 +++++++++ target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch | 9 +++++++++ 2 files changed, 18 insertions(+) diff --git a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch index 661abf6..23491aa 100644 --- a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch +++ b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch @@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu variant helper bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT; switch (bcm63xx_cpu_id) { +@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void) + bcm63xx_memory_size = detect_memory_size(); + + printk(KERN_INFO "Detected Broadcom 0x%04x CPU revision %02x\n", +- bcm63xx_cpu_id, bcm63xx_cpu_rev); ++ bcm63xx_cpu_variant, bcm63xx_cpu_rev); + printk(KERN_INFO "CPU frequency is %u MHz\n", + bcm63xx_cpu_freq / 1000000); + printk(KERN_INFO "%uMB of RAM installed\n", --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h @@ -19,6 +19,7 @@ diff --git a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch index 661abf6..330a9e6 100644 --- a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch +++ b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch @@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu variant helper bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT; switch (bcm63xx_cpu_id) { +@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void) + bcm63xx_memory_size = detect_memory_size(); + + pr_info("Detected Broadcom 0x%04x CPU revision %02x\n", +- bcm63xx_cpu_id, bcm63xx_cpu_rev); ++ bcm63xx_cpu_variant, bcm63xx_cpu_rev); + pr_info("CPU frequency is %u MHz\n", + bcm63xx_cpu_freq / 1000000); + pr_info("%uMB of RAM installed\n", --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h @@ -19,6 +19,7 @@ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From xotic750 at gmail.com Mon May 9 03:57:54 2016 From: xotic750 at gmail.com (Graham Fairweather) Date: Mon, 9 May 2016 09:57:54 +0200 Subject: [OpenWrt-Devel] [PATCH 001/001] [brcm63xx] v2:Display the correct detected CPU ID Message-ID: From: Graham Fairweather This patch fixes the logged detected CPU ID when an equivalent is used, like in the case where we have a bcm6369 and configuration for a bcm6368 is used. More info can be found at: https://forum.openwrt.org/viewtopic.php?id=64621 https://github.com/Xotic750/openwrt/tree/fix_logged_cpu_id_bcm63xx v2 fixes an issue where the 4.4 kernel uses 'pr_info' rather than 'printk'. Missed the problem in my initial attempts with 'quilt'. Signed-off-by: Graham Fairweather --- target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch | 9 +++++++++ target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch | 9 +++++++++ 2 files changed, 18 insertions(+) diff --git a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch index 661abf6..23491aa 100644 --- a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch +++ b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch @@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu variant helper bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT; switch (bcm63xx_cpu_id) { +@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void) + bcm63xx_memory_size = detect_memory_size(); + + printk(KERN_INFO "Detected Broadcom 0x%04x CPU revision %02x\n", +- bcm63xx_cpu_id, bcm63xx_cpu_rev); ++ bcm63xx_cpu_variant, bcm63xx_cpu_rev); + printk(KERN_INFO "CPU frequency is %u MHz\n", + bcm63xx_cpu_freq / 1000000); + printk(KERN_INFO "%uMB of RAM installed\n", --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h @@ -19,6 +19,7 @@ diff --git a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch index 661abf6..330a9e6 100644 --- a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch +++ b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch @@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu variant helper bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT; switch (bcm63xx_cpu_id) { +@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void) + bcm63xx_memory_size = detect_memory_size(); + + pr_info("Detected Broadcom 0x%04x CPU revision %02x\n", +- bcm63xx_cpu_id, bcm63xx_cpu_rev); ++ bcm63xx_cpu_variant, bcm63xx_cpu_rev); + pr_info("CPU frequency is %u MHz\n", + bcm63xx_cpu_freq / 1000000); + pr_info("%uMB of RAM installed\n", --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h @@ -19,6 +19,7 @@ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From xotic750 at gmail.com Mon May 9 04:07:08 2016 From: xotic750 at gmail.com (Graham Fairweather) Date: Mon, 9 May 2016 10:07:08 +0200 Subject: [OpenWrt-Devel] [PATCHv2 001/001] [brcm63xx] Display the correct detected CPU ID Message-ID: From: Graham Fairweather This patch fixes the logged detected CPU ID when an equivalent is used, like in the case where we have a bcm6369 and configuration for a bcm6368 is used. More info can be found at: https://forum.openwrt.org/viewtopic.php?id=64621 https://github.com/Xotic750/openwrt/tree/fix_logged_cpu_id_bcm63xx Signed-off-by: Graham Fairweather --- v2 fixes an issue where the 4.4 kernel uses 'pr_info' rather than 'printk'. Missed the problem in my initial attempts with 'quilt'. --- target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch | 9 +++++++++ target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch | 9 +++++++++ 2 files changed, 18 insertions(+) diff --git a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch index 661abf6..23491aa 100644 --- a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch +++ b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch @@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu variant helper bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT; switch (bcm63xx_cpu_id) { +@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void) + bcm63xx_memory_size = detect_memory_size(); + + printk(KERN_INFO "Detected Broadcom 0x%04x CPU revision %02x\n", +- bcm63xx_cpu_id, bcm63xx_cpu_rev); ++ bcm63xx_cpu_variant, bcm63xx_cpu_rev); + printk(KERN_INFO "CPU frequency is %u MHz\n", + bcm63xx_cpu_freq / 1000000); + printk(KERN_INFO "%uMB of RAM installed\n", --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h @@ -19,6 +19,7 @@ diff --git a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch index 661abf6..330a9e6 100644 --- a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch +++ b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch @@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu variant helper bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT; switch (bcm63xx_cpu_id) { +@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void) + bcm63xx_memory_size = detect_memory_size(); + + pr_info("Detected Broadcom 0x%04x CPU revision %02x\n", +- bcm63xx_cpu_id, bcm63xx_cpu_rev); ++ bcm63xx_cpu_variant, bcm63xx_cpu_rev); + pr_info("CPU frequency is %u MHz\n", + bcm63xx_cpu_freq / 1000000); + pr_info("%uMB of RAM installed\n", --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h @@ -19,6 +19,7 @@ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From xotic750 at gmail.com Mon May 9 04:11:31 2016 From: xotic750 at gmail.com (Graham Fairweather) Date: Mon, 9 May 2016 10:11:31 +0200 Subject: [OpenWrt-Devel] [PATCHv2 001/001] [brcm63xx] Display the correct detected CPU ID Message-ID: From: Graham Fairweather This patch fixes the logged detected CPU ID when an equivalent is used, like in the case where we have a bcm6369 and configuration for a bcm6368 is used. More info can be found at: https://forum.openwrt.org/viewtopic.php?id=64621 https://github.com/Xotic750/openwrt/tree/fix_logged_cpu_id_bcm63xx Signed-off-by: Graham Fairweather --- v2 fixes an issue where the 4.4 kernel uses 'pr_info' rather than 'printk'. Missed the problem in my initial attempts with 'quilt'. --- target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch | 9 +++++++++ target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch | 9 +++++++++ 2 files changed, 18 insertions(+) diff --git a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch index 661abf6..23491aa 100644 --- a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch +++ b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch @@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu variant helper bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT; switch (bcm63xx_cpu_id) { +@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void) + bcm63xx_memory_size = detect_memory_size(); + + printk(KERN_INFO "Detected Broadcom 0x%04x CPU revision %02x\n", +- bcm63xx_cpu_id, bcm63xx_cpu_rev); ++ bcm63xx_cpu_variant, bcm63xx_cpu_rev); + printk(KERN_INFO "CPU frequency is %u MHz\n", + bcm63xx_cpu_freq / 1000000); + printk(KERN_INFO "%uMB of RAM installed\n", --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h @@ -19,6 +19,7 @@ diff --git a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch index 661abf6..330a9e6 100644 --- a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch +++ b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch @@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu variant helper bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT; switch (bcm63xx_cpu_id) { +@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void) + bcm63xx_memory_size = detect_memory_size(); + + pr_info("Detected Broadcom 0x%04x CPU revision %02x\n", +- bcm63xx_cpu_id, bcm63xx_cpu_rev); ++ bcm63xx_cpu_variant, bcm63xx_cpu_rev); + pr_info("CPU frequency is %u MHz\n", + bcm63xx_cpu_freq / 1000000); + pr_info("%uMB of RAM installed\n", --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h @@ -19,6 +19,7 @@ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From xotic750 at gmail.com Mon May 9 04:35:07 2016 From: xotic750 at gmail.com (Graham Fairweather) Date: Mon, 9 May 2016 10:35:07 +0200 Subject: [OpenWrt-Devel] [PATCH v2 001/001] [brcm63xx] Display the correct detected CPU ID Message-ID: From: Graham Fairweather This patch fixes the logged detected CPU ID when an equivalent is used, like in the case where we have a bcm6369 and configuration for a bcm6368 is used. More info can be found at: https://forum.openwrt.org/viewtopic.php?id=64621 https://github.com/Xotic750/openwrt/tree/fix_logged_cpu_id_bcm63xx Signed-off-by: Graham Fairweather --- v2 fixes an issue where the 4.4 kernel uses 'pr_info' rather than 'printk'. Missed the problem in my initial attempts with 'quilt'. --- target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch | 9 +++++++++ target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch | 9 +++++++++ 2 files changed, 18 insertions(+) diff --git a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch index 661abf6..23491aa 100644 --- a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch +++ b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch @@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu variant helper bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT; switch (bcm63xx_cpu_id) { +@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void) + bcm63xx_memory_size = detect_memory_size(); + + printk(KERN_INFO "Detected Broadcom 0x%04x CPU revision %02x\n", +- bcm63xx_cpu_id, bcm63xx_cpu_rev); ++ bcm63xx_cpu_variant, bcm63xx_cpu_rev); + printk(KERN_INFO "CPU frequency is %u MHz\n", + bcm63xx_cpu_freq / 1000000); + printk(KERN_INFO "%uMB of RAM installed\n", --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h @@ -19,6 +19,7 @@ diff --git a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch index 661abf6..330a9e6 100644 --- a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch +++ b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch @@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu variant helper bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT; switch (bcm63xx_cpu_id) { +@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void) + bcm63xx_memory_size = detect_memory_size(); + + pr_info("Detected Broadcom 0x%04x CPU revision %02x\n", +- bcm63xx_cpu_id, bcm63xx_cpu_rev); ++ bcm63xx_cpu_variant, bcm63xx_cpu_rev); + pr_info("CPU frequency is %u MHz\n", + bcm63xx_cpu_freq / 1000000); + pr_info("%uMB of RAM installed\n", --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h @@ -19,6 +19,7 @@ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From xotic750 at gmail.com Mon May 9 04:42:49 2016 From: xotic750 at gmail.com (Graham Fairweather) Date: Mon, 9 May 2016 10:42:49 +0200 Subject: [OpenWrt-Devel] [PATCH v2] [brcm63xx] Display the correct detected CPU ID Message-ID: From: Graham Fairweather This patch fixes the logged detected CPU ID when an equivalent is used, like in the case where we have a bcm6369 and configuration for a bcm6368 is used. More info can be found at: https://forum.openwrt.org/viewtopic.php?id=64621 https://github.com/Xotic750/openwrt/tree/fix_logged_cpu_id_bcm63xx Signed-off-by: Graham Fairweather --- v2 fixes an issue where the 4.4 kernel uses 'pr_info' rather than 'printk'. Missed the problem in my initial attempts with 'quilt'. --- target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch | 9 +++++++++ target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch | 9 +++++++++ 2 files changed, 18 insertions(+) diff --git a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch index 661abf6..23491aa 100644 --- a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch +++ b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch @@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu variant helper bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT; switch (bcm63xx_cpu_id) { +@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void) + bcm63xx_memory_size = detect_memory_size(); + + printk(KERN_INFO "Detected Broadcom 0x%04x CPU revision %02x\n", +- bcm63xx_cpu_id, bcm63xx_cpu_rev); ++ bcm63xx_cpu_variant, bcm63xx_cpu_rev); + printk(KERN_INFO "CPU frequency is %u MHz\n", + bcm63xx_cpu_freq / 1000000); + printk(KERN_INFO "%uMB of RAM installed\n", --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h @@ -19,6 +19,7 @@ diff --git a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch index 661abf6..330a9e6 100644 --- a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch +++ b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch @@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu variant helper bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT; switch (bcm63xx_cpu_id) { +@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void) + bcm63xx_memory_size = detect_memory_size(); + + pr_info("Detected Broadcom 0x%04x CPU revision %02x\n", +- bcm63xx_cpu_id, bcm63xx_cpu_rev); ++ bcm63xx_cpu_variant, bcm63xx_cpu_rev); + pr_info("CPU frequency is %u MHz\n", + bcm63xx_cpu_freq / 1000000); + pr_info("%uMB of RAM installed\n", --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h @@ -19,6 +19,7 @@ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From xotic750 at gmail.com Mon May 9 05:30:58 2016 From: xotic750 at gmail.com (Graham Fairweather) Date: Mon, 9 May 2016 11:30:58 +0200 Subject: [OpenWrt-Devel] [PATCH, v2 001/001] [brcm63xx] Display the correct detected CPU ID Message-ID: From: Graham Fairweather This patch fixes the logged detected CPU ID when an equivalent is used, like in the case where we have a bcm6369 and configuration for a bcm6368 is used. More info can be found at: https://forum.openwrt.org/viewtopic.php?id=64621 https://github.com/Xotic750/openwrt/tree/fix_logged_cpu_id_bcm63xx v2 fixes an issue where the 4.4 kernel uses 'pr_info' rather than 'printk'. Missed the problem in my initial attempts with 'quilt'. Signed-off-by: Graham Fairweather --- target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch | 9 +++++++++ target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch | 9 +++++++++ 2 files changed, 18 insertions(+) diff --git a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch index 661abf6..23491aa 100644 --- a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch +++ b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch @@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu variant helper bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT; switch (bcm63xx_cpu_id) { +@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void) + bcm63xx_memory_size = detect_memory_size(); + + printk(KERN_INFO "Detected Broadcom 0x%04x CPU revision %02x\n", +- bcm63xx_cpu_id, bcm63xx_cpu_rev); ++ bcm63xx_cpu_variant, bcm63xx_cpu_rev); + printk(KERN_INFO "CPU frequency is %u MHz\n", + bcm63xx_cpu_freq / 1000000); + printk(KERN_INFO "%uMB of RAM installed\n", --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h @@ -19,6 +19,7 @@ diff --git a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch index 661abf6..330a9e6 100644 --- a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch +++ b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch @@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu variant helper bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT; switch (bcm63xx_cpu_id) { +@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void) + bcm63xx_memory_size = detect_memory_size(); + + pr_info("Detected Broadcom 0x%04x CPU revision %02x\n", +- bcm63xx_cpu_id, bcm63xx_cpu_rev); ++ bcm63xx_cpu_variant, bcm63xx_cpu_rev); + pr_info("CPU frequency is %u MHz\n", + bcm63xx_cpu_freq / 1000000); + pr_info("%uMB of RAM installed\n", --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h @@ -19,6 +19,7 @@ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From xotic750 at gmail.com Mon May 9 05:39:39 2016 From: xotic750 at gmail.com (Graham Fairweather) Date: Mon, 9 May 2016 11:39:39 +0200 Subject: [OpenWrt-Devel] [PATCHv2 001/001] [brcm63xx] Display the correct detected CPU ID Message-ID: From: Graham Fairweather This patch fixes the logged detected CPU ID when an equivalent is used, like in the case where we have a bcm6369 and configuration for a bcm6368 is used. More info can be found at: https://forum.openwrt.org/viewtopic.php?id=64621 https://github.com/Xotic750/openwrt/tree/fix_logged_cpu_id_bcm63xx Signed-off-by: Graham Fairweather --- target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch | 9 +++++++++ target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch | 9 +++++++++ 2 files changed, 18 insertions(+) diff --git a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch index 661abf6..23491aa 100644 --- a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch +++ b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch @@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu variant helper bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT; switch (bcm63xx_cpu_id) { +@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void) + bcm63xx_memory_size = detect_memory_size(); + + printk(KERN_INFO "Detected Broadcom 0x%04x CPU revision %02x\n", +- bcm63xx_cpu_id, bcm63xx_cpu_rev); ++ bcm63xx_cpu_variant, bcm63xx_cpu_rev); + printk(KERN_INFO "CPU frequency is %u MHz\n", + bcm63xx_cpu_freq / 1000000); + printk(KERN_INFO "%uMB of RAM installed\n", --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h @@ -19,6 +19,7 @@ diff --git a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch index 661abf6..330a9e6 100644 --- a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch +++ b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch @@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu variant helper bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT; switch (bcm63xx_cpu_id) { +@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void) + bcm63xx_memory_size = detect_memory_size(); + + pr_info("Detected Broadcom 0x%04x CPU revision %02x\n", +- bcm63xx_cpu_id, bcm63xx_cpu_rev); ++ bcm63xx_cpu_variant, bcm63xx_cpu_rev); + pr_info("CPU frequency is %u MHz\n", + bcm63xx_cpu_freq / 1000000); + pr_info("%uMB of RAM installed\n", --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h @@ -19,6 +19,7 @@ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From xotic750 at gmail.com Mon May 9 05:50:17 2016 From: xotic750 at gmail.com (Graham Fairweather) Date: Mon, 9 May 2016 11:50:17 +0200 Subject: [OpenWrt-Devel] [PATCH 1/1] [brcm63xx] Display the correct CPU ID when alternative used. Message-ID: From: Graham Fairweather This patch fixes the logged detected CPU ID when an equivalent is used, like in the case where we have a bcm6369 and configuration for a bcm6368 is used. So, it will 'Detected Broadcom 0x6369 CPU revision b2' display instead of 'Detected Broadcom 0x6369 CPU revision b2'. More info can be found at: https://forum.openwrt.org/viewtopic.php?id=64621 https://github.com/Xotic750/openwrt/tree/fix_logged_cpu_id_bcm63xx Signed-off-by: Graham Fairweather --- target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch | 9 +++++++++ target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch | 9 +++++++++ 2 files changed, 18 insertions(+) diff --git a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch index 661abf6..23491aa 100644 --- a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch +++ b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch @@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu variant helper bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT; switch (bcm63xx_cpu_id) { +@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void) + bcm63xx_memory_size = detect_memory_size(); + + printk(KERN_INFO "Detected Broadcom 0x%04x CPU revision %02x\n", +- bcm63xx_cpu_id, bcm63xx_cpu_rev); ++ bcm63xx_cpu_variant, bcm63xx_cpu_rev); + printk(KERN_INFO "CPU frequency is %u MHz\n", + bcm63xx_cpu_freq / 1000000); + printk(KERN_INFO "%uMB of RAM installed\n", --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h @@ -19,6 +19,7 @@ diff --git a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch index 661abf6..330a9e6 100644 --- a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch +++ b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch @@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu variant helper bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT; switch (bcm63xx_cpu_id) { +@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void) + bcm63xx_memory_size = detect_memory_size(); + + pr_info("Detected Broadcom 0x%04x CPU revision %02x\n", +- bcm63xx_cpu_id, bcm63xx_cpu_rev); ++ bcm63xx_cpu_variant, bcm63xx_cpu_rev); + pr_info("CPU frequency is %u MHz\n", + bcm63xx_cpu_freq / 1000000); + pr_info("%uMB of RAM installed\n", --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h @@ -19,6 +19,7 @@ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From xotic750 at gmail.com Mon May 9 06:00:22 2016 From: xotic750 at gmail.com (Graham Fairweather) Date: Mon, 9 May 2016 12:00:22 +0200 Subject: [OpenWrt-Devel] [PATCHv2 001/001] [brcm63xx] Display the correct detected CPU ID Message-ID: From: Graham Fairweather This patch fixes the logged detected CPU ID when an equivalent is used, like in the case where we have a bcm6369 and configuration for a bcm6368 is used. So, it will display 'Detected Broadcom 0x6369 CPU revision b2' instead of 'Detected Broadcom 0x6369 CPU revision b2'. More info can be found at: https://forum.openwrt.org/viewtopic.php?id=64621 https://github.com/Xotic750/openwrt/tree/fix_logged_cpu_id_bcm63xx Signed-off-by: Graham Fairweather --- target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch | 9 +++++++++ target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch | 9 +++++++++ 2 files changed, 18 insertions(+) diff --git a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch index 661abf6..23491aa 100644 --- a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch +++ b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch @@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu variant helper bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT; switch (bcm63xx_cpu_id) { +@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void) + bcm63xx_memory_size = detect_memory_size(); + + printk(KERN_INFO "Detected Broadcom 0x%04x CPU revision %02x\n", +- bcm63xx_cpu_id, bcm63xx_cpu_rev); ++ bcm63xx_cpu_variant, bcm63xx_cpu_rev); + printk(KERN_INFO "CPU frequency is %u MHz\n", + bcm63xx_cpu_freq / 1000000); + printk(KERN_INFO "%uMB of RAM installed\n", --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h @@ -19,6 +19,7 @@ diff --git a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch index 661abf6..330a9e6 100644 --- a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch +++ b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch @@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu variant helper bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT; switch (bcm63xx_cpu_id) { +@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void) + bcm63xx_memory_size = detect_memory_size(); + + pr_info("Detected Broadcom 0x%04x CPU revision %02x\n", +- bcm63xx_cpu_id, bcm63xx_cpu_rev); ++ bcm63xx_cpu_variant, bcm63xx_cpu_rev); + pr_info("CPU frequency is %u MHz\n", + bcm63xx_cpu_freq / 1000000); + pr_info("%uMB of RAM installed\n", --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h @@ -19,6 +19,7 @@ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From xotic750 at gmail.com Mon May 9 06:27:18 2016 From: xotic750 at gmail.com (Graham Fairweather) Date: Mon, 9 May 2016 12:27:18 +0200 Subject: [OpenWrt-Devel] [PATCH 1/1] [brcm63xx] Fix the CPU ID logged when detecting bcm63xx variants. Message-ID: From: Graham Fairweather This patch fixes the logged detected CPU ID when an equivalent is used, like in the case where we have a bcm6369 and configuration for a bcm6368 is used. So, it will display 'Detected Broadcom 0x6369 CPU revision b2' instead of 'Detected Broadcom 0x6369 CPU revision b2'. More info can be found at: https://forum.openwrt.org/viewtopic.php?id=64621 https://github.com/Xotic750/openwrt/tree/fix_logged_cpu_id_bcm63xx Signed-off-by: Graham Fairweather --- .../330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch | 9 +++++++++ .../330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch | 9 +++++++++ 2 files changed, 18 insertions(+) diff --git a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch index 661abf6..23491aa 100644 --- a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch +++ b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch @@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu variant helper bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT; switch (bcm63xx_cpu_id) { +@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void) + bcm63xx_memory_size = detect_memory_size(); + + printk(KERN_INFO "Detected Broadcom 0x%04x CPU revision %02x\n", +- bcm63xx_cpu_id, bcm63xx_cpu_rev); ++ bcm63xx_cpu_variant, bcm63xx_cpu_rev); + printk(KERN_INFO "CPU frequency is %u MHz\n", + bcm63xx_cpu_freq / 1000000); + printk(KERN_INFO "%uMB of RAM installed\n", --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h @@ -19,6 +19,7 @@ diff --git a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch index 661abf6..330a9e6 100644 --- a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch +++ b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch @@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu variant helper bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT; switch (bcm63xx_cpu_id) { +@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void) + bcm63xx_memory_size = detect_memory_size(); + + pr_info("Detected Broadcom 0x%04x CPU revision %02x\n", +- bcm63xx_cpu_id, bcm63xx_cpu_rev); ++ bcm63xx_cpu_variant, bcm63xx_cpu_rev); + pr_info("CPU frequency is %u MHz\n", + bcm63xx_cpu_freq / 1000000); + pr_info("%uMB of RAM installed\n", --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h @@ -19,6 +19,7 @@ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From xotic750 at gmail.com Mon May 9 06:50:09 2016 From: xotic750 at gmail.com (Graham Fairweather) Date: Mon, 9 May 2016 12:50:09 +0200 Subject: [OpenWrt-Devel] [PATCHv2 001/001] [brcm63xx] Display the correct detected CPU ID Message-ID: From: Graham Fairweather This patch fixes the logged detected CPU ID when an equivalent is used, like in the case where we have a bcm6369 and configuration for a bcm6368 is used. So, it will display 'Detected Broadcom 0x6369 CPU revision b2' instead of 'Detected Broadcom 0x6369 CPU revision b2'. More info can be found at: https://forum.openwrt.org/viewtopic.php?id=64621 https://github.com/Xotic750/openwrt/tree/fix_logged_cpu_id_bcm63xx Signed-off-by: Graham Fairweather --- target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch | 9 +++++++++ target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch | 9 +++++++++ 2 files changed, 18 insertions(+) diff --git a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch index 661abf6..23491aa 100644 --- a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch +++ b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch @@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu variant helper bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT; switch (bcm63xx_cpu_id) { +@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void) + bcm63xx_memory_size = detect_memory_size(); + + printk(KERN_INFO "Detected Broadcom 0x%04x CPU revision %02x\n", +- bcm63xx_cpu_id, bcm63xx_cpu_rev); ++ bcm63xx_cpu_variant, bcm63xx_cpu_rev); + printk(KERN_INFO "CPU frequency is %u MHz\n", + bcm63xx_cpu_freq / 1000000); + printk(KERN_INFO "%uMB of RAM installed\n", --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h @@ -19,6 +19,7 @@ diff --git a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch index 661abf6..330a9e6 100644 --- a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch +++ b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch @@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu variant helper bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT; switch (bcm63xx_cpu_id) { +@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void) + bcm63xx_memory_size = detect_memory_size(); + + pr_info("Detected Broadcom 0x%04x CPU revision %02x\n", +- bcm63xx_cpu_id, bcm63xx_cpu_rev); ++ bcm63xx_cpu_variant, bcm63xx_cpu_rev); + pr_info("CPU frequency is %u MHz\n", + bcm63xx_cpu_freq / 1000000); + pr_info("%uMB of RAM installed\n", --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h @@ -19,6 +19,7 @@ _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From nbd at nbd.name Mon May 9 06:54:28 2016 From: nbd at nbd.name (Felix Fietkau) Date: Mon, 9 May 2016 12:54:28 +0200 Subject: [OpenWrt-Devel] [PATCHv2 001/001] [brcm63xx] Display the correct detected CPU ID In-Reply-To: References: Message-ID: <57306C64.50307@nbd.name> On 2016-05-09 12:50, Graham Fairweather wrote: > From: Graham Fairweather > > This patch fixes the logged detected CPU ID when an equivalent is used, > like in the case where we have a bcm6369 and configuration for a > bcm6368 is used. > So, it will display 'Detected Broadcom 0x6369 CPU revision b2' instead of > 'Detected Broadcom 0x6369 CPU revision b2'. More info can be found at: > > https://forum.openwrt.org/viewtopic.php?id=64621 > https://github.com/Xotic750/openwrt/tree/fix_logged_cpu_id_bcm63xx > Signed-off-by: Graham Fairweather Please stop spamming the list with the same patch over and over again. While you're still trying to figure out how to send patches properly, please send them to yourself instead of the list. - Felix _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From rjangi at codeaurora.org Mon May 9 07:15:13 2016 From: rjangi at codeaurora.org (Ram Chandra Jangir) Date: Mon, 9 May 2016 16:45:13 +0530 Subject: [OpenWrt-Devel] [PATCH v2 2/3] ext4_part_match: fix bug that prevented matching names In-Reply-To: <5729EE4D.5070204@gmail.com> References: <1461867621-4055-1-git-send-email-josua.mayer97@gmail.com> <1461867621-4055-2-git-send-email-josua.mayer97@gmail.com> <008501d1a213$a0a3e930$e1ebbb90$@codeaurora.org> <5729EE4D.5070204@gmail.com> Message-ID: <019001d1a9e4$1124ff50$336efdf0$@codeaurora.org> Hi Josua Mayer, Partname is nothing but respective partition name of emmc card. It reads partition name from GPT partition table. I think fdisk may not be able to write partition name in GPT table, but you should be able to create the partition name with GPT fdisk (consisting of the gdisk, cgdisk, sgdisk, and fixparts programs). Thanks, Ram -----Original Message----- From: Josua Mayer [mailto:josua.mayer97 at gmail.com] Sent: Wednesday, May 04, 2016 6:13 PM To: Ram Chandra Jangir ; openwrt-devel at lists.openwrt.org Subject: Re: [OpenWrt-Devel] [PATCH v2 2/3] ext4_part_match: fix bug that prevented matching names Hi Ram, Thanks for your comments. Now it appears I misunderstood what the code is supposed to match. So if there is a PARTNAME= line, it can be matched. However on my system I dont have PARTNAME. Here a real-life sample: root at OpenWrt:/# cat /sys/block/mmcblk0/mmcblk0p3/uevent MAJOR=179 MINOR=3 DEVNAME=mmcblk0p3 DEVTYPE=partition What is partname and how can I set it? fdisk? filesystem label? br Josua Mayer Am 29.04.2016 um 14:35 schrieb Ram Chandra Jangir: > Thanks Josua Mayer. > > Devname and partname both are different. Devname is holding the device node(ex. mmcblkXpY) and given name(or partname) is the partition name(ex. rootfs or rootfs_data). > For below uevent sysfs entries, it tries to populate the device node(mmcblkXpY) in devname variable and tries to match the given name with the PARTNAME(buf will have this value("PARTNAME=rootfs_data") at n'th iteration). > If it is found then the loop will break, and we will get the given name's device node(/dev/mmcblkXpY) which will be mounted later. > > Example: > root at OpenWrt:/# cat /sys/block/mmcblk0/mmcblk0p3/uevent > MAJOR=179 > MINOR=3 > DEVNAME=mmcblk0p3 <-- device node: /dev/mmcblk0p3 > DEVTYPE=partition > PARTN=3 > PARTNAME=rootfs_data > > This is required, because the emmc card may have multiple partitions too. So our aim is to get the device node from the given name's uevent file. > > Thanks, > Ram > > -----Original Message----- > From: openwrt-devel [mailto:openwrt-devel-bounces at lists.openwrt.org] > On Behalf Of josua.mayer97 at gmail.com > Sent: Thursday, April 28, 2016 11:50 PM > To: openwrt-devel at lists.openwrt.org > Cc: Josua Mayer > Subject: [OpenWrt-Devel] [PATCH v2 2/3] ext4_part_match: fix bug that > prevented matching names > > From: Josua Mayer > > Actually use the populated devname variable to compare against given name, instead of the buf variable, which incidentally contains either: > MAJOR=xyz, MINOR=x, or DEVTYPE=partition, none of which ever match a name. > > Signed-off-by: Josua Mayer > --- > libfstools/ext4.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libfstools/ext4.c b/libfstools/ext4.c index > f648aa8..b9401c3 100644 > --- a/libfstools/ext4.c > +++ b/libfstools/ext4.c > @@ -78,7 +78,7 @@ ext4_part_match(char *dev, char *name, char *filename) > continue; > } > /* Match partition name */ > - if (strstr(buf, name)) { > + if (strstr(devname, name)) { > ret = 0; > break; > } > -- > 2.6.6 > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From xotic750 at gmail.com Mon May 9 07:19:10 2016 From: xotic750 at gmail.com (Graham Fairweather) Date: Mon, 9 May 2016 13:19:10 +0200 Subject: [OpenWrt-Devel] [PATCHv2 001/001] [brcm63xx] Display the correct detected CPU ID In-Reply-To: <57306C64.50307@nbd.name> References: <57306C64.50307@nbd.name> Message-ID: It wasn't my intention to spam the list. I asked for help on the forum, I asked for help on IRC and I was told to try things. The documents say if unsuccessful then try again. As a noob, it is not the easiest process to follow, especially when something doesn't work. How would sending the mail to myself, which I did by the way, help me knowing what the problem was? Thanks for your patience and your advice. On 9 May 2016 at 12:54, Felix Fietkau wrote: > On 2016-05-09 12:50, Graham Fairweather wrote: >> From: Graham Fairweather >> >> This patch fixes the logged detected CPU ID when an equivalent is used, >> like in the case where we have a bcm6369 and configuration for a >> bcm6368 is used. >> So, it will display 'Detected Broadcom 0x6369 CPU revision b2' instead of >> 'Detected Broadcom 0x6369 CPU revision b2'. More info can be found at: >> >> https://forum.openwrt.org/viewtopic.php?id=64621 >> https://github.com/Xotic750/openwrt/tree/fix_logged_cpu_id_bcm63xx >> Signed-off-by: Graham Fairweather > Please stop spamming the list with the same patch over and over again. > While you're still trying to figure out how to send patches properly, > please send them to yourself instead of the list. > > - Felix _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From john at phrozen.org Mon May 9 07:21:52 2016 From: john at phrozen.org (John Crispin) Date: Mon, 9 May 2016 13:21:52 +0200 Subject: [OpenWrt-Devel] [PATCHv2 001/001] [brcm63xx] Display the correct detected CPU ID In-Reply-To: References: <57306C64.50307@nbd.name> Message-ID: On 09/05/2016 13:19, Graham Fairweather wrote: > It wasn't my intention to spam the list. I asked for help on the > forum, I asked for help on IRC and I was told to try things. The > documents say if unsuccessful then try again. As a noob, it is not the > easiest process to follow, especially when something doesn't work. How > would sending the mail to myself, which I did by the way, help me > knowing what the problem was? Thanks for your patience and your > advice. > Hi Graham, no worries, we all started doing this at some point. once you have the patch and send it to yourslef, you can save the email and try it out on your local tree. if all went well, you should be able to ally the mail/patch with "git am mypatch.eml" the easiest way to make sure that sending the patch always works is to use "git send-email" John > On 9 May 2016 at 12:54, Felix Fietkau wrote: >> On 2016-05-09 12:50, Graham Fairweather wrote: >>> From: Graham Fairweather >>> >>> This patch fixes the logged detected CPU ID when an equivalent is used, >>> like in the case where we have a bcm6369 and configuration for a >>> bcm6368 is used. >>> So, it will display 'Detected Broadcom 0x6369 CPU revision b2' instead of >>> 'Detected Broadcom 0x6369 CPU revision b2'. More info can be found at: >>> >>> https://forum.openwrt.org/viewtopic.php?id=64621 >>> https://github.com/Xotic750/openwrt/tree/fix_logged_cpu_id_bcm63xx >>> Signed-off-by: Graham Fairweather >> Please stop spamming the list with the same patch over and over again. >> While you're still trying to figure out how to send patches properly, >> please send them to yourself instead of the list. >> >> - Felix > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From nbd at nbd.name Mon May 9 07:23:26 2016 From: nbd at nbd.name (Felix Fietkau) Date: Mon, 9 May 2016 13:23:26 +0200 Subject: [OpenWrt-Devel] [PATCHv2 001/001] [brcm63xx] Display the correct detected CPU ID In-Reply-To: References: <57306C64.50307@nbd.name> Message-ID: <5730732E.70500@nbd.name> On 2016-05-09 13:19, Graham Fairweather wrote: > It wasn't my intention to spam the list. I asked for help on the > forum, I asked for help on IRC and I was told to try things. The > documents say if unsuccessful then try again. As a noob, it is not the > easiest process to follow, especially when something doesn't work. How > would sending the mail to myself, which I did by the way, help me > knowing what the problem was? Thanks for your patience and your > advice. If you send the email to yourself instead of the list, you can check if it came out right by trying to apply it. By the way, the easiest way to ensure that your patches are sent correctly is to use git send-email. - Felix _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From xotic750 at gmail.com Mon May 9 07:30:53 2016 From: xotic750 at gmail.com (Graham Fairweather) Date: Mon, 9 May 2016 13:30:53 +0200 Subject: [OpenWrt-Devel] [PATCHv2 001/001] [brcm63xx] Display the correct detected CPU ID In-Reply-To: <5730732E.70500@nbd.name> References: <57306C64.50307@nbd.name> <5730732E.70500@nbd.name> Message-ID: Thanks. I'm looking into that, but currently my system doesn't support 'git send-email' and I'm researching why. My apologies for the noob spam, I still have much to learn and mistakes to make. John has just pointed me toward 'git am', which I also didn't know about. Thank you. On 9 May 2016 at 13:23, Felix Fietkau wrote: > On 2016-05-09 13:19, Graham Fairweather wrote: >> It wasn't my intention to spam the list. I asked for help on the >> forum, I asked for help on IRC and I was told to try things. The >> documents say if unsuccessful then try again. As a noob, it is not the >> easiest process to follow, especially when something doesn't work. How >> would sending the mail to myself, which I did by the way, help me >> knowing what the problem was? Thanks for your patience and your >> advice. > If you send the email to yourself instead of the list, you can check if > it came out right by trying to apply it. By the way, the easiest way to > ensure that your patches are sent correctly is to use git send-email. > > - Felix _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From mohammed.berdai at gmail.com Mon May 9 08:38:49 2016 From: mohammed.berdai at gmail.com (Mohammed Berdai) Date: Mon, 9 May 2016 13:38:49 +0100 Subject: [OpenWrt-Devel] [PATCH 1/1] [CC]: openssl: Update to version 1.0.2h Message-ID: <62b10aca-1c11-e705-b8bd-5191a79b3ab6@gmail.com> openssl: Update to version 1.0.2h Bump to the latest version, fixes several security issues: * CVE-2016-2107, CVE-2016-2105, CVE-2016-2106, CVE-2016-2109, CVE-2016-2176 More details at https://www.openssl.org/news/openssl-1.0.2-notes.html Signed-off-by: Mohammed Berdai --- diff --git a/package/libs/openssl/Makefile b/package/libs/openssl/Makefile index 0b96557..3d13fe0 100644 --- a/package/libs/openssl/Makefile +++ b/package/libs/openssl/Makefile @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=openssl PKG_BASE:=1.0.2 -PKG_BUGFIX:=g +PKG_BUGFIX:=h PKG_VERSION:=$(PKG_BASE)$(PKG_BUGFIX) PKG_RELEASE:=1 PKG_USE_MIPS16:=0 @@ -21,7 +21,7 @@ PKG_SOURCE_URL:=http://www.openssl.org/source/ \ http://www.openssl.org/source/old/$(PKG_BASE)/ \ ftp://ftp.funet.fi/pub/crypt/mirrors/ftp.openssl.org/source \ ftp://ftp.sunet.se/pub/security/tools/net/openssl/source/ -PKG_MD5SUM:=f3c710c045cdee5fd114feb69feba7aa +PKG_MD5SUM:=9392e65072ce4b614c1392eefc1f23d0 PKG_LICENSE:=OpenSSL PKG_LICENSE_FILES:=LICENSE _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From carlosmf.pt at gmail.com Mon May 9 10:30:37 2016 From: carlosmf.pt at gmail.com (Carlos Ferreira) Date: Mon, 9 May 2016 15:30:37 +0100 Subject: [OpenWrt-Devel] hostapd-wpad-mesh fails to build. Message-ID: The output of "make ./package/network/services/hostapd/{clean,compile} V=s -j1" can be seen here: http://pastebin.com/KpcbNzmy hostapd-wpad-mesh is failing to build. -- Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - cmf at av.it.pt Skype & GTalk -> carlosmf.pt at gmail.com LinkedIn -> http://www.linkedin.com/in/carlosmferreira -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From bapclenet at gmail.com Mon May 9 12:56:52 2016 From: bapclenet at gmail.com (Baptiste Clenet) Date: Mon, 9 May 2016 18:56:52 +0200 Subject: [OpenWrt-Devel] mt76 wifi module on mt7688 board, no interface In-Reply-To: References: <570FB001.8030507@phrozen.org> <1461265121.8314.4.camel@noblepepper.com> Message-ID: Lazar, Have you managed to make mt76 work on mt7688? Thanks 2016-05-03 1:52 GMT+02:00 Lazar Demin : > Marc, > Can you expand on what you did to get the AP to work? I'm completely > stumped... > > Any luck on the STA? > > > Thanks > > On Thu, Apr 21, 2016 at 3:00 PM, Marc Nicholas wrote: >> >> Is the firmware getting loaded (/lib/firmware/mt7628_e2.bin)? It looks >> like the fix in 48958 for this is in github.com/openwrt-mirror/ but not >> in github.com/openwrt/. >> >> Yes, the firmware is getting loaded based on the boot logs. >> >> I?ve gotten a bit further and have AP mode running. But can?t for the life >> of me get STA to work?.can?t even scan for APs. :-/ >> >> Thanks! >> >> -m >> >> -- >> >> _______________________________________________ >> openwrt-devel mailing list >> openwrt-devel at lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >> > > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > -- Baptiste _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From john at phrozen.org Mon May 9 12:57:51 2016 From: john at phrozen.org (John Crispin) Date: Mon, 9 May 2016 18:57:51 +0200 Subject: [OpenWrt-Devel] mt76 wifi module on mt7688 board, no interface In-Reply-To: References: <570FB001.8030507@phrozen.org> <1461265121.8314.4.camel@noblepepper.com> Message-ID: Hi Baptiste, on my list for this week John On 09/05/2016 18:56, Baptiste Clenet wrote: > Lazar, > Have you managed to make mt76 work on mt7688? > > Thanks > > 2016-05-03 1:52 GMT+02:00 Lazar Demin : >> Marc, >> Can you expand on what you did to get the AP to work? I'm completely >> stumped... >> >> Any luck on the STA? >> >> >> Thanks >> >> On Thu, Apr 21, 2016 at 3:00 PM, Marc Nicholas wrote: >>> >>> Is the firmware getting loaded (/lib/firmware/mt7628_e2.bin)? It looks >>> like the fix in 48958 for this is in github.com/openwrt-mirror/ but not >>> in github.com/openwrt/. >>> >>> Yes, the firmware is getting loaded based on the boot logs. >>> >>> I?ve gotten a bit further and have AP mode running. But can?t for the life >>> of me get STA to work?.can?t even scan for APs. :-/ >>> >>> Thanks! >>> >>> -m >>> >>> -- >>> >>> _______________________________________________ >>> openwrt-devel mailing list >>> openwrt-devel at lists.openwrt.org >>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >>> >> >> >> _______________________________________________ >> openwrt-devel mailing list >> openwrt-devel at lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >> > > > _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From zajec5 at gmail.com Mon May 9 19:56:10 2016 From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=) Date: Tue, 10 May 2016 01:56:10 +0200 Subject: [OpenWrt-Devel] [PATCH] bcm53xx: drop Copyright header from two of my bash scripts Message-ID: <1462838170-27533-1-git-send-email-zajec5@gmail.com> Both scripts modified by this patch were added by me. First of all I incorrectly added OpenWrt as Copyright holder. It was wrong because: 1) I simply can't transfer my moral rights according to the Polish law 2) Transfering copyrights (economic rights) requires an agreement which I didn't sign with OpenWrt(.org). Other than that I don't find these trivial scripts important enough to put info about *my* copyrights in a header so this patch just drops them completely. Signed-off-by: Rafa? Mi?ecki --- target/linux/bcm53xx/base-files/etc/diag.sh | 1 - target/linux/bcm53xx/base-files/etc/uci-defaults/09_fix_crc | 4 ---- 2 files changed, 5 deletions(-) diff --git a/target/linux/bcm53xx/base-files/etc/diag.sh b/target/linux/bcm53xx/base-files/etc/diag.sh index 0a8c5fb..a8a560c 100644 --- a/target/linux/bcm53xx/base-files/etc/diag.sh +++ b/target/linux/bcm53xx/base-files/etc/diag.sh @@ -1,5 +1,4 @@ #!/bin/sh -# Copyright (C) 2014 OpenWrt.org . /lib/functions/leds.sh 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 abbb04a..3d14827 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 @@ -1,7 +1,3 @@ #!/bin/sh -# -# Copyright (C) 2007 OpenWrt.org -# -# mtd fixtrx firmware || mtd fixseama firmware -- 1.8.4.5 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From zajec5 at gmail.com Tue May 10 10:35:39 2016 From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=) Date: Tue, 10 May 2016 16:35:39 +0200 Subject: [OpenWrt-Devel] [PATCH] mtd: imagetag: fix compilation with changed mtd_fixtrx call Message-ID: <1462890939-8458-1-git-send-email-zajec5@gmail.com> Function mtd_fixtrx was changed during trx improvements. Signed-off-by: Rafa? Mi?ecki --- package/system/mtd/src/imagetag.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/package/system/mtd/src/imagetag.c b/package/system/mtd/src/imagetag.c index b850837..2ad2076 100644 --- a/package/system/mtd/src/imagetag.c +++ b/package/system/mtd/src/imagetag.c @@ -288,7 +288,7 @@ trx_check(int imagefd, const char *mtd, char *buf, int *len) } int -mtd_fixtrx(const char *mtd, size_t offset) +mtd_fixtrx(const char *mtd, size_t offset, size_t data_size) { int fd; struct bcm_tag *tag; @@ -299,6 +299,9 @@ mtd_fixtrx(const char *mtd, size_t offset) uint32_t imagecrc, rootfscrc, headercrc; cfelen = imagelen = imagestart = imagecrc = rootfscrc = headercrc = rootfslen = 0; + if (data_size) + fprintf(stderr, "Specifying data size in unsupported for imagetag\n"); + if (quiet < 2) fprintf(stderr, "Trying to fix trx header in %s at 0x%x...\n", mtd, offset); -- 1.8.4.5 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From bjorn at mork.no Wed May 11 07:24:00 2016 From: bjorn at mork.no (=?UTF-8?q?Bj=C3=B8rn=20Mork?=) Date: Wed, 11 May 2016 13:24:00 +0200 Subject: [OpenWrt-Devel] [PATCH 0/4] umbim support for MTK2 based modems like D-Link DWM-157 Message-ID: <1462965844-12904-1-git-send-email-bjorn@mork.no> I was inspired by https://forum.openwrt.org/viewtopic.php?id=64680 to finally do something about this issue... The primary show stopper is that the MTK2 MBIM firmware does not support 1024 bytes MBIM requests. The MBIM descriptor wMaxControlMessage is 512: bjorn at nemi:~$ lsusb -vd 2001:7d01|sed -ne /MBIM/,+7p CDC MBIM: bcdMBIMVersion 1.00 wMaxControlMessage 512 bNumberFilters 16 bMaxFilterSize 64 wMaxSegmentSize 1500 bmNetworkCapabilities 0x20 8-byte ntb input size This makes umbim OPEN fail because the modem refuse the default hardcoded 1024 bytes buffer size: bjorn at nemi:/usr/local/src/git/umbim$ ./umbim -d /dev/cdc-wdm2 -v -n caps sending (16): 01 00 00 00 10 00 00 00 01 00 00 00 00 04 00 00 header_type: 0001 header_length: 0010 header_transaction: 0001 reading (16): 04 00 00 80 10 00 00 00 01 00 00 00 08 00 00 00 header_type: 80000004 header_length: 0010 header_transaction: 0001 sending (16): 02 00 00 00 10 00 00 00 02 00 00 00 08 00 00 00 header_type: 0002 header_length: 0010 header_transaction: 0002 reading (16): 02 00 00 80 10 00 00 00 02 00 00 00 02 00 00 00 header_type: 80000002 header_length: 0010 header_transaction: 0002 The same problem is likely to affect other MBIM firmwares. I believe some Ericsson modems also use 512 byte control messages. Fix by dynamically allocating the message buffer, and getting the proper size from the driver. We could parse the descriptor, but using the ioctl is simpler and supported since Linux v3.10. My DWM-156 A7 always starts up with the radio off. MBIM radio state support is necessary to use the modem. With these two changes , I can successfully establish a connection using the D-Link DWM-156 A7: bjorn at nemi:/usr/local/src/git/umbim$ ./umbim -n -d /dev/cdc-wdm2 unlock 1234 Pin Unlocked bjorn at nemi:/usr/local/src/git/umbim$ ./umbim -n -t 2 -d /dev/cdc-wdm2 radio hwradiostate: on swradiostate: off bjorn at nemi:/usr/local/src/git/umbim$ ./umbim -n -t 2 -d /dev/cdc-wdm2 radio on hwradiostate: on swradiostate: on bjorn at nemi:/usr/local/src/git/umbim$ ./umbim -n -t 2 -d /dev/cdc-wdm2 connect telenor sessionid: 0 activationstate: 0001 - activated voicecallstate: 0000 - none nwerror: 0000 - unknown iptype: 0001 - ipv4 bjorn at nemi:/usr/local/src/git/umbim$ ./umbim -n -t 2 -d /dev/cdc-wdm2 config ipv4address: 109.179.119.106/30 ipv4gateway: 109.179.119.105 ipv4mtu: 1500 ipv4dnsserver: 193.213.112.4 bjorn at nemi:/usr/local/src/git/umbim$ ./umbim -n -t 2 -d /dev/cdc-wdm2 caps devicetype: 0002 - removable cellularclass: 0001 voiceclass: 0003 - simultaneous-voice-data simclass: 0002 dataclass: 001F smscaps: 0003 controlcaps: 0001 maxsessions: 0002 deviceid: 355619050151297 firmwareinfo: MOLY.WR8.W1231.DC.WG.MP.V3 hardwareinfo: MTK2 Bj?rn Mork (4): dynamically allocate buffer get buffer size from driver update usage() add radio_state set/query support cli.c | 38 +++++++++++++++++++++++++++++++++++++- mbim-dev.c | 33 ++++++++++++++++++++++++++++----- mbim-dev.h | 4 +++- mbim-msg.c | 14 +++++++++----- mbim.h | 2 -- 5 files changed, 77 insertions(+), 14 deletions(-) -- 2.1.4 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From bjorn at mork.no Wed May 11 07:24:01 2016 From: bjorn at mork.no (=?UTF-8?q?Bj=C3=B8rn=20Mork?=) Date: Wed, 11 May 2016 13:24:01 +0200 Subject: [OpenWrt-Devel] [PATCH 1/4] dynamically allocate buffer In-Reply-To: <1462965844-12904-1-git-send-email-bjorn@mork.no> References: <1462965844-12904-1-git-send-email-bjorn@mork.no> Message-ID: <1462965844-12904-2-git-send-email-bjorn@mork.no> Signed-off-by: Bj?rn Mork --- mbim-dev.c | 24 +++++++++++++++++++----- mbim-dev.h | 4 +++- mbim-msg.c | 14 +++++++++----- mbim.h | 2 -- 4 files changed, 31 insertions(+), 13 deletions(-) diff --git a/mbim-dev.c b/mbim-dev.c index d986cbe775b0..34bb2c228eb0 100644 --- a/mbim-dev.c +++ b/mbim-dev.c @@ -25,7 +25,8 @@ #include "mbim.h" -uint8_t mbim_buffer[MBIM_BUFFER_SIZE]; +size_t mbim_bufsize = 0; +uint8_t *mbim_buffer = NULL; static struct uloop_fd mbim_fd; static uint32_t expected; int no_close; @@ -33,7 +34,7 @@ int no_close; static void mbim_msg_tout_cb(struct uloop_timeout *t) { fprintf(stderr, "ERROR: mbim message timeout\n"); - uloop_end(); + mbim_end(); } static struct uloop_timeout tout = { @@ -46,7 +47,7 @@ mbim_send(void) struct mbim_message_header *hdr = (struct mbim_message_header *) mbim_buffer; int ret = 0; - if (le32toh(hdr->length) > MBIM_BUFFER_SIZE) { + if (le32toh(hdr->length) > mbim_bufsize) { fprintf(stderr, "message too big %d\n", le32toh(hdr->length)); return -1; } @@ -74,7 +75,7 @@ mbim_send(void) static void mbim_recv(struct uloop_fd *u, unsigned int events) { - ssize_t cnt = read(u->fd, mbim_buffer, MBIM_BUFFER_SIZE); + ssize_t cnt = read(u->fd, mbim_buffer, mbim_bufsize); struct mbim_message_header *hdr = (struct mbim_message_header *) mbim_buffer; struct command_done_message *msg = (struct command_done_message *) (hdr + 1); int i; @@ -118,7 +119,7 @@ mbim_recv(struct uloop_fd *u, unsigned int events) mbim_send_close_msg(); break; case MBIM_MESSAGE_TYPE_CLOSE_DONE: - uloop_end(); + mbim_end(); break; case MBIM_MESSAGE_TYPE_FUNCTION_ERROR: no_close = 0; @@ -137,5 +138,18 @@ mbim_open(const char *path) perror("open failed: "); exit(-1); } + mbim_bufsize = MBIM_BUFFER_SIZE; + mbim_buffer = malloc(mbim_bufsize); uloop_fd_add(&mbim_fd, ULOOP_READ); } + +void +mbim_end(void) +{ + if (mbim_buffer) { + free(mbim_buffer); + mbim_bufsize = 0; + mbim_buffer = NULL; + } + uloop_end(); +} diff --git a/mbim-dev.h b/mbim-dev.h index 1499630e20be..b7a253ca0bef 100644 --- a/mbim-dev.h +++ b/mbim-dev.h @@ -15,10 +15,12 @@ #ifndef _MBIM_DEV_H__ #define _MBIM_DEV_H__ -extern uint8_t mbim_buffer[MBIM_BUFFER_SIZE]; +extern size_t mbim_bufsize; +extern uint8_t *mbim_buffer; extern int no_close; int mbim_send(void); void mbim_open(const char *path); +void mbim_end(void); #endif diff --git a/mbim-msg.c b/mbim-msg.c index ad5a2d5dcd9a..3413f5dea32a 100644 --- a/mbim-msg.c +++ b/mbim-msg.c @@ -143,7 +143,9 @@ mbim_setup_command_msg(uint8_t *uuid, uint32_t type, uint32_t command_id, int le { struct command_message *cmd = (struct command_message *) mbim_buffer; - memset(mbim_buffer, 0, MBIM_BUFFER_SIZE); + if (!mbim_buffer) + return NULL; + memset(mbim_buffer, 0, mbim_bufsize); cmd->fragment_header.total = htole32(1); cmd->fragment_header.current = htole32(0); @@ -153,7 +155,7 @@ mbim_setup_command_msg(uint8_t *uuid, uint32_t type, uint32_t command_id, int le cmd->buffer_length = htole32(len); payload_offset = len; - payload_free = MBIM_BUFFER_SIZE - (sizeof(*cmd) + len); + payload_free = mbim_bufsize - (sizeof(*cmd) + len); payload_len = 0; payload_buffer = cmd->buffer; @@ -165,6 +167,8 @@ mbim_send_command_msg(void) { struct command_message *cmd = (struct command_message *) mbim_buffer; + if (!mbim_buffer) + return 0; if (payload_len & 0x3) { payload_len &= ~0x3; payload_len += 4; @@ -182,7 +186,7 @@ mbim_send_open_msg(void) struct mbim_open_message *msg = (struct mbim_open_message *) mbim_buffer; mbim_setup_header(&msg->header, MBIM_MESSAGE_TYPE_OPEN, sizeof(*msg)); - msg->max_control_transfer = htole32(MBIM_BUFFER_SIZE); + msg->max_control_transfer = htole32(mbim_bufsize); return mbim_send(); } @@ -192,8 +196,8 @@ mbim_send_close_msg(void) { struct mbim_message_header *hdr = (struct mbim_message_header *) mbim_buffer; - if (no_close) { - uloop_end(); + if (no_close || !mbim_buffer) { + mbim_end(); return 0; } mbim_setup_header(hdr, MBIM_MESSAGE_TYPE_CLOSE, sizeof(*hdr)); diff --git a/mbim.h b/mbim.h index 6e7e8b4d9e5e..746257eecda2 100644 --- a/mbim.h +++ b/mbim.h @@ -18,8 +18,6 @@ #include #include -#define MBIM_BUFFER_SIZE 1024 - extern int return_code; extern int verbose; -- 2.1.4 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From bjorn at mork.no Wed May 11 07:24:02 2016 From: bjorn at mork.no (=?UTF-8?q?Bj=C3=B8rn=20Mork?=) Date: Wed, 11 May 2016 13:24:02 +0200 Subject: [OpenWrt-Devel] [PATCH 2/4] get buffer size from driver In-Reply-To: <1462965844-12904-1-git-send-email-bjorn@mork.no> References: <1462965844-12904-1-git-send-email-bjorn@mork.no> Message-ID: <1462965844-12904-3-git-send-email-bjorn@mork.no> Signed-off-by: Bj?rn Mork --- mbim-dev.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/mbim-dev.c b/mbim-dev.c index 34bb2c228eb0..dd1110daeb52 100644 --- a/mbim-dev.c +++ b/mbim-dev.c @@ -12,6 +12,8 @@ * GNU General Public License for more details. */ +#include +#include #include #include @@ -132,13 +134,20 @@ mbim_recv(struct uloop_fd *u, unsigned int events) void mbim_open(const char *path) { + __u16 max; + int rc; + mbim_fd.cb = mbim_recv; mbim_fd.fd = open(path, O_RDWR); if (mbim_fd.fd < 1) { perror("open failed: "); exit(-1); } - mbim_bufsize = MBIM_BUFFER_SIZE; + rc = ioctl(mbim_fd.fd, IOCTL_WDM_MAX_COMMAND, &max); + if (!rc) + mbim_bufsize = max; + else + mbim_bufsize = 512; mbim_buffer = malloc(mbim_bufsize); uloop_fd_add(&mbim_fd, ULOOP_READ); } -- 2.1.4 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From bjorn at mork.no Wed May 11 07:24:03 2016 From: bjorn at mork.no (=?UTF-8?q?Bj=C3=B8rn=20Mork?=) Date: Wed, 11 May 2016 13:24:03 +0200 Subject: [OpenWrt-Devel] [PATCH 3/4] update usage() In-Reply-To: <1462965844-12904-1-git-send-email-bjorn@mork.no> References: <1462965844-12904-1-git-send-email-bjorn@mork.no> Message-ID: <1462965844-12904-4-git-send-email-bjorn@mork.no> Signed-off-by: Bj?rn Mork --- cli.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cli.c b/cli.c index 15ca5b4e4a31..3a81bca71e91 100644 --- a/cli.c +++ b/cli.c @@ -446,7 +446,7 @@ static struct mbim_handler handlers[] = { static int usage(void) { - fprintf(stderr, "Usage: mbim [options]\n" + fprintf(stderr, "Usage: umbim [options]\n" "Options:\n" " -d the device (/dev/cdc-wdmX)\n" " -t the transaction id\n" -- 2.1.4 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From bjorn at mork.no Wed May 11 07:24:04 2016 From: bjorn at mork.no (=?UTF-8?q?Bj=C3=B8rn=20Mork?=) Date: Wed, 11 May 2016 13:24:04 +0200 Subject: [OpenWrt-Devel] [PATCH 4/4] add radio_state set/query support In-Reply-To: <1462965844-12904-1-git-send-email-bjorn@mork.no> References: <1462965844-12904-1-git-send-email-bjorn@mork.no> Message-ID: <1462965844-12904-5-git-send-email-bjorn@mork.no> Signed-off-by: Bj?rn Mork --- cli.c | 38 +++++++++++++++++++++++++++++++++++++- 1 file changed, 37 insertions(+), 1 deletion(-) diff --git a/cli.c b/cli.c index 3a81bca71e91..1dd6330b8113 100644 --- a/cli.c +++ b/cli.c @@ -265,6 +265,20 @@ mbim_config_response(void *buffer, int len) } static int +mbim_radio_response(void *buffer, int len) +{ + struct mbim_basic_connect_radio_state_r *r = (struct mbim_basic_connect_radio_state_r *) buffer; + + if (len < sizeof(struct mbim_basic_connect_radio_state_r)) { + fprintf(stderr, "message not long enough\n"); + return -1; + } + printf(" hwradiostate: %s\n", r->hwradiostate ? "on" : "off"); + printf(" swradiostate: %s\n", r->swradiostate ? "on" : "off"); + return 0; +} + +static int mbim_device_caps_request(void) { mbim_setup_command_msg(basic_connect, MBIM_MESSAGE_COMMAND_TYPE_QUERY, MBIM_CMD_BASIC_CONNECT_DEVICE_CAPS, 0); @@ -430,6 +444,27 @@ mbim_config_request(void) return mbim_send_command_msg(); } +static int +mbim_radio_request(void) +{ + if (_argc > 0) { + struct mbim_basic_connect_radio_state_s *rs = + (struct mbim_basic_connect_radio_state_s *) mbim_setup_command_msg(basic_connect, + MBIM_MESSAGE_COMMAND_TYPE_SET, MBIM_CMD_BASIC_CONNECT_RADIO_STATE, + sizeof(struct mbim_basic_connect_radio_state_r)); + + if (!strcmp(_argv[0], "off")) + rs->radiostate = htole32(MBIM_RADIO_SWITCH_STATE_OFF); + else + rs->radiostate = htole32(MBIM_RADIO_SWITCH_STATE_ON); + } else { + mbim_setup_command_msg(basic_connect, + MBIM_MESSAGE_COMMAND_TYPE_QUERY, MBIM_CMD_BASIC_CONNECT_RADIO_STATE, + sizeof(struct mbim_basic_connect_radio_state_r)); + } + return mbim_send_command_msg(); +} + static struct mbim_handler handlers[] = { { "caps", 0, mbim_device_caps_request, mbim_device_caps_response }, { "pinstate", 0, mbim_pin_state_request, mbim_pin_state_response }, @@ -441,12 +476,13 @@ static struct mbim_handler handlers[] = { { "connect", 0, mbim_connect_request, mbim_connect_response }, { "disconnect", 0, mbim_disconnect_request, mbim_connect_response }, { "config", 0, mbim_config_request, mbim_config_response }, + { "radio", 0, mbim_radio_request, mbim_radio_response }, }; static int usage(void) { - fprintf(stderr, "Usage: umbim [options]\n" + fprintf(stderr, "Usage: umbim [options]\n" "Options:\n" " -d the device (/dev/cdc-wdmX)\n" " -t the transaction id\n" -- 2.1.4 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From bjorn at mork.no Wed May 11 07:58:23 2016 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Wed, 11 May 2016 13:58:23 +0200 Subject: [OpenWrt-Devel] disabling email addresses used in OpenWrt "MAINTAINER" fields Message-ID: <87futon6w0.fsf@nemi.mork.no> I see that the email mess isn't sorted out yet: ----- The following addresses had permanent fatal errors ----- (reason: 550 5.1.1 : Recipient address rejected: User unknown in virtual mailbox table) ----- Transcript of session follows ----- ... while talking to mail.openwrt.org.: >>> DATA <<< 550 5.1.1 : Recipient address rejected: User unknown in virtual mailbox table 550 5.1.1 ... User unknown <<< 554 5.5.1 Error: no valid recipients Reporting-MTA: dns; canardo.mork.no Arrival-Date: Wed, 11 May 2016 13:24:14 +0200 Final-Recipient: RFC822; blogic at openwrt.org Action: failed Status: 5.1.1 Remote-MTA: DNS; mail.openwrt.org Diagnostic-Code: SMTP; 550 5.1.1 : Recipient address rejected: User unknown in virtual mailbox table Last-Attempt-Date: Wed, 11 May 2016 13:38:58 +0200 At the same time, I see that this address is listed as the maintainer of a number of OpenWrt packages and targets: bjorn at canardo:/usr/local/src/openwrt$ git remote -v origin git://git.openwrt.org/openwrt.git (fetch) origin git://git.openwrt.org/openwrt.git (push) bjorn at canardo:/usr/local/src/openwrt$ git grep -E 'MAINTAINER:=.*blogic at openwrt.org' origin/master origin/master:package/kernel/lantiq/ltq-adsl-fw/Makefile:PKG_MAINTAINER:=John Crispin origin/master:package/kernel/lantiq/ltq-adsl-mei/Makefile:PKG_MAINTAINER:=John Crispin origin/master:package/kernel/lantiq/ltq-adsl/Makefile:PKG_MAINTAINER:=John Crispin origin/master:package/kernel/lantiq/ltq-atm/Makefile:PKG_MAINTAINER:=John Crispin origin/master:package/kernel/lantiq/ltq-deu/Makefile:PKG_MAINTAINER:=John Crispin origin/master:package/kernel/lantiq/ltq-hcd/Makefile:PKG_MAINTAINER:=John Crispin origin/master:package/kernel/lantiq/ltq-ifxos/Makefile:PKG_MAINTAINER:=John Crispin origin/master:package/kernel/lantiq/ltq-ptm/Makefile:PKG_MAINTAINER:=John Crispin origin/master:package/kernel/lantiq/ltq-tapi/Makefile:PKG_MAINTAINER:=John Crispin origin/master:package/kernel/lantiq/ltq-vdsl-mei/Makefile:PKG_MAINTAINER:=John Crispin origin/master:package/kernel/lantiq/ltq-vdsl/Makefile:PKG_MAINTAINER:=John Crispin origin/master:package/kernel/lantiq/ltq-vmmc/Makefile:PKG_MAINTAINER:=John Crispin origin/master:package/network/config/ltq-adsl-app/Makefile:PKG_MAINTAINER:=John Crispin origin/master:package/network/services/mdns/Makefile:PKG_MAINTAINER:=John Crispin origin/master:package/network/utils/umbim/Makefile:PKG_MAINTAINER:=John Crispin origin/master:package/network/utils/wwan/Makefile:PKG_MAINTAINER:=John Crispin origin/master:package/system/fstools/Makefile:PKG_MAINTAINER:=John Crispin origin/master:package/system/mountd/Makefile:PKG_MAINTAINER:=John Crispin origin/master:package/system/procd/Makefile:PKG_MAINTAINER:=John Crispin origin/master:package/system/ubox/Makefile:PKG_MAINTAINER:=John Crispin origin/master:package/utils/ubi-utils/Makefile:PKG_MAINTAINER:=John Crispin origin/master:package/utils/ugps/Makefile:PKG_MAINTAINER:=John Crispin origin/master:target/linux/ipq806x/Makefile:MAINTAINER:=John Crispin origin/master:target/linux/lantiq/Makefile:MAINTAINER:=John Crispin origin/master:target/linux/mediatek/Makefile:MAINTAINER:=John Crispin origin/master:target/linux/octeon/Makefile:MAINTAINER:=John Crispin origin/master:target/linux/ramips/Makefile:MAINTAINER:=John Crispin Does this mean that OpenWrt now consider these packages and targets unmaintained? Please clarify by updating either Makefiles or mail server. Thanks. I have so far tried not to read too much into the messages regarding the project split, but this stupid game to demostrate who is in charge of the email server seems demonstrate the real problems pretty well. Mike responded to that with "Email forwarding was temporarily disabled following the LEDE announcement" But the fact that it is still "temporarily disabled" shows that he either isn't speaking for those in control of the email forwarding, or is lying about it being temporary. In good faith I'll assume the first. But either way, the OpenWrt project just died for me. It appears to be unmanaged. Bj?rn _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From john at phrozen.org Wed May 11 08:05:26 2016 From: john at phrozen.org (John Crispin) Date: Wed, 11 May 2016 14:05:26 +0200 Subject: [OpenWrt-Devel] disabling email addresses used in OpenWrt "MAINTAINER" fields In-Reply-To: <87futon6w0.fsf@nemi.mork.no> References: <87futon6w0.fsf@nemi.mork.no> Message-ID: Hi Bjorn, i'll drop the emails during this week. sorry i was busy getting my email addr changed in the kernel and various other projects. totally forgot to change them in these 2 trees. sorry for the inconvenience. John On 11/05/2016 13:58, Bj?rn Mork wrote: > I see that the email mess isn't sorted out yet: > > > ----- The following addresses had permanent fatal errors ----- > > (reason: 550 5.1.1 : Recipient address rejected: User unknown in virtual mailbox table) > > ----- Transcript of session follows ----- > ... while talking to mail.openwrt.org.: >>>> DATA > <<< 550 5.1.1 : Recipient address rejected: User unknown in virtual mailbox table > 550 5.1.1 ... User unknown > <<< 554 5.5.1 Error: no valid recipients > > Reporting-MTA: dns; canardo.mork.no > Arrival-Date: Wed, 11 May 2016 13:24:14 +0200 > > Final-Recipient: RFC822; blogic at openwrt.org > Action: failed > Status: 5.1.1 > Remote-MTA: DNS; mail.openwrt.org > Diagnostic-Code: SMTP; 550 5.1.1 : Recipient address rejected: User unknown in virtual mailbox table > Last-Attempt-Date: Wed, 11 May 2016 13:38:58 +0200 > > > > At the same time, I see that this address is listed as the maintainer of > a number of OpenWrt packages and targets: > > bjorn at canardo:/usr/local/src/openwrt$ git remote -v > origin git://git.openwrt.org/openwrt.git (fetch) > origin git://git.openwrt.org/openwrt.git (push) > > bjorn at canardo:/usr/local/src/openwrt$ git grep -E 'MAINTAINER:=.*blogic at openwrt.org' origin/master > origin/master:package/kernel/lantiq/ltq-adsl-fw/Makefile:PKG_MAINTAINER:=John Crispin > origin/master:package/kernel/lantiq/ltq-adsl-mei/Makefile:PKG_MAINTAINER:=John Crispin > origin/master:package/kernel/lantiq/ltq-adsl/Makefile:PKG_MAINTAINER:=John Crispin > origin/master:package/kernel/lantiq/ltq-atm/Makefile:PKG_MAINTAINER:=John Crispin > origin/master:package/kernel/lantiq/ltq-deu/Makefile:PKG_MAINTAINER:=John Crispin > origin/master:package/kernel/lantiq/ltq-hcd/Makefile:PKG_MAINTAINER:=John Crispin > origin/master:package/kernel/lantiq/ltq-ifxos/Makefile:PKG_MAINTAINER:=John Crispin > origin/master:package/kernel/lantiq/ltq-ptm/Makefile:PKG_MAINTAINER:=John Crispin > origin/master:package/kernel/lantiq/ltq-tapi/Makefile:PKG_MAINTAINER:=John Crispin > origin/master:package/kernel/lantiq/ltq-vdsl-mei/Makefile:PKG_MAINTAINER:=John Crispin > origin/master:package/kernel/lantiq/ltq-vdsl/Makefile:PKG_MAINTAINER:=John Crispin > origin/master:package/kernel/lantiq/ltq-vmmc/Makefile:PKG_MAINTAINER:=John Crispin > origin/master:package/network/config/ltq-adsl-app/Makefile:PKG_MAINTAINER:=John Crispin > origin/master:package/network/services/mdns/Makefile:PKG_MAINTAINER:=John Crispin > origin/master:package/network/utils/umbim/Makefile:PKG_MAINTAINER:=John Crispin > origin/master:package/network/utils/wwan/Makefile:PKG_MAINTAINER:=John Crispin > origin/master:package/system/fstools/Makefile:PKG_MAINTAINER:=John Crispin > origin/master:package/system/mountd/Makefile:PKG_MAINTAINER:=John Crispin > origin/master:package/system/procd/Makefile:PKG_MAINTAINER:=John Crispin > origin/master:package/system/ubox/Makefile:PKG_MAINTAINER:=John Crispin > origin/master:package/utils/ubi-utils/Makefile:PKG_MAINTAINER:=John Crispin > origin/master:package/utils/ugps/Makefile:PKG_MAINTAINER:=John Crispin > origin/master:target/linux/ipq806x/Makefile:MAINTAINER:=John Crispin > origin/master:target/linux/lantiq/Makefile:MAINTAINER:=John Crispin > origin/master:target/linux/mediatek/Makefile:MAINTAINER:=John Crispin > origin/master:target/linux/octeon/Makefile:MAINTAINER:=John Crispin > origin/master:target/linux/ramips/Makefile:MAINTAINER:=John Crispin > > > > Does this mean that OpenWrt now consider these packages and targets > unmaintained? Please clarify by updating either Makefiles or mail > server. Thanks. > > I have so far tried not to read too much into the messages regarding the > project split, but this stupid game to demostrate who is in charge of > the email server seems demonstrate the real problems pretty well. Mike > responded to that with > > "Email forwarding was temporarily disabled following the LEDE announcement" > > But the fact that it is still "temporarily disabled" shows that he > either isn't speaking for those in control of the email forwarding, or > is lying about it being temporary. In good faith I'll assume the first. > > But either way, the OpenWrt project just died for me. It appears to be > unmanaged. > > > Bj?rn > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From Eduardo.Abinader at riverbed.com Wed May 11 08:49:53 2016 From: Eduardo.Abinader at riverbed.com (Eduardo Abinader) Date: Wed, 11 May 2016 12:49:53 +0000 Subject: [OpenWrt-Devel] TX99 mode for 11g rates Message-ID: Hi, Is there anyone able to run TX99 for 11g rates on current trunk version with ar9003/9002 chip based? Unfortunately, I cannot. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From nitroshift at yahoo.com Wed May 11 08:54:15 2016 From: nitroshift at yahoo.com (Sebastian Careba) Date: Wed, 11 May 2016 15:54:15 +0300 Subject: [OpenWrt-Devel] [PATCH] netdata: import new package Message-ID: <1462971255-31458-1-git-send-email-nitroshift@yahoo.com> This uses the current Git prerelease, as the latest stable (1.1.0) doesn't build cleanly. The default configuration makes a few changes for OpenWrt: - access log is disabled by default; too verbose for the circular syslog buffer, and logging to /tmp is risky memory-wise. Some sort of external device would be ideal for this. - error and debug logs are sent to OpenWrt's syslog - history and frequency times are halved to reduce memory usage, as recommended in the netdata wiki - external plugins are disabled to eliminate the dependency on bash and node.js. Those could be installed from OpenWrt packages if you wish to enable that functionality. All of those files are still present in the package. The installed size could be reduced by eliminating those files first. Signed-off-by: Claudio Leite Signed-off by: Sebastian Careba --- package/network/utils/netdata/Makefile | 61 ++++++++++++++++++++++++++++++++++++++++ package/network/utils/netdata/files/netdata.conf | 16 +++++++++++ package/network/utils/netdata/files/netdata.init | 11 ++++++++ 3 files changed, 88 insertions(+) create mode 100644 package/network/utils/netdata/Makefile create mode 100644 package/network/utils/netdata/files/netdata.conf create mode 100644 package/network/utils/netdata/files/netdata.init diff --git a/package/network/utils/netdata/Makefile b/package/network/utils/netdata/Makefile new file mode 100644 index 0000000..d08b317 --- /dev/null +++ b/package/network/utils/netdata/Makefile @@ -0,0 +1,61 @@ +# +# Copyright (C) 2008-2016 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:=netdata +PKG_VERSION:=devel-20160508 +PKG_RELEASE:=1 +PKG_MAINTAINER:=Sebastian Careba +PKG_LICENSE:=GPL-3.0 +PKG_LICENSE_FILES:=COPYING + +PKG_SOURCE_PROTO:=git +PKG_SOURCE_URL=https://github.com/firehol/netdata +PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION) +PKG_SOURCE_VERSION:=0ec2db444011f5b6ebf41dab45502c27cd544af2 +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz + +PKG_INSTALL:=1 +PKG_FIXUP:=autoreconf + +include $(INCLUDE_DIR)/package.mk + +define Package/netdata + SECTION:=package/network/utils + CATEGORY:=package/network/utilsistration + DEPENDS:=+zlib + TITLE:=Real-time performance monitoring tool + URL:=http://netdata.firehol.org/ +endef + +define Package/netdata/description + netdata is a highly optimized Linux daemon providing real-time performance + monitoring for Linux systems, applications and SNMP devices over the web. +endef + +define Package/netdata/conffiles +/etc/netdata/ +endef + +define Package/netdata/install + $(INSTALL_DIR) $(1)/etc/netdata + $(INSTALL_CONF) $(PKG_INSTALL_DIR)/etc/netdata/apps_groups.conf $(1)/etc/netdata + $(INSTALL_CONF) $(PKG_INSTALL_DIR)/etc/netdata/charts.d.conf $(1)/etc/netdata + $(INSTALL_CONF) ./files/netdata.conf $(1)/etc/netdata + $(INSTALL_DIR) $(1)/etc/init.d + $(INSTALL_BIN) ./files/netdata.init $(1)/etc/init.d/netdata + $(INSTALL_DIR) $(1)/usr/sbin + $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/sbin/netdata $(1)/usr/sbin/ + $(INSTALL_DIR) $(1)/usr/share/netdata + $(INSTALL_DIR) $(1)/usr/lib/netdata + $(CP) $(PKG_INSTALL_DIR)/usr/share/netdata $(1)/usr/share + $(CP) $(PKG_INSTALL_DIR)/usr/lib/netdata $(1)/usr/lib + chmod 4755 $(1)/usr/lib/netdata/plugins.d/apps.plugin +endef + +$(eval $(call BuildPackage,netdata)) diff --git a/package/network/utils/netdata/files/netdata.conf b/package/network/utils/netdata/files/netdata.conf new file mode 100644 index 0000000..e1f0964 --- /dev/null +++ b/package/network/utils/netdata/files/netdata.conf @@ -0,0 +1,16 @@ +[global] + run as user = nobody + web files owner = root + web files group = root + update every = 2 + history = 1800 + access log = none + debug log = syslog + error log = syslog + memory mode = ram + +[plugins] + charts.d = no + apps = no + node.d = no + tc = no diff --git a/package/network/utils/netdata/files/netdata.init b/package/network/utils/netdata/files/netdata.init new file mode 100644 index 0000000..448e56d --- /dev/null +++ b/package/network/utils/netdata/files/netdata.init @@ -0,0 +1,11 @@ +#!/bin/sh /etc/rc.common + +START=99 + +start() { + service_start /usr/sbin/netdata +} + +stop() { + service_stop /usr/sbin/netdata +} -- 2.1.4 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From nitroshift at yahoo.com Wed May 11 08:55:41 2016 From: nitroshift at yahoo.com (Sebastian Careba) Date: Wed, 11 May 2016 15:55:41 +0300 Subject: [OpenWrt-Devel] [PATCH] netdata: import new package Message-ID: <1462971341-10516-1-git-send-email-nitroshift@yahoo.com> This uses the current Git prerelease, as the latest stable (1.1.0) doesn't build cleanly. The default configuration makes a few changes for OpenWrt: - access log is disabled by default; too verbose for the circular syslog buffer, and logging to /tmp is risky memory-wise. Some sort of external device would be ideal for this. - error and debug logs are sent to OpenWrt's syslog - history and frequency times are halved to reduce memory usage, as recommended in the netdata wiki - external plugins are disabled to eliminate the dependency on bash and node.js. Those could be installed from OpenWrt packages if you wish to enable that functionality. All of those files are still present in the package. The installed size could be reduced by eliminating those files first. Signed-off-by: Claudio Leite Signed-off by: Sebastian Careba --- package/network/utils/netdata/Makefile | 61 ++++++++++++++++++++++++++++++++++++++++ package/network/utils/netdata/files/netdata.conf | 16 +++++++++++ package/network/utils/netdata/files/netdata.init | 11 ++++++++ 3 files changed, 88 insertions(+) create mode 100644 package/network/utils/netdata/Makefile create mode 100644 package/network/utils/netdata/files/netdata.conf create mode 100644 package/network/utils/netdata/files/netdata.init diff --git a/package/network/utils/netdata/Makefile b/package/network/utils/netdata/Makefile new file mode 100644 index 0000000..d08b317 --- /dev/null +++ b/package/network/utils/netdata/Makefile @@ -0,0 +1,61 @@ +# +# Copyright (C) 2008-2016 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:=netdata +PKG_VERSION:=devel-20160508 +PKG_RELEASE:=1 +PKG_MAINTAINER:=Sebastian Careba +PKG_LICENSE:=GPL-3.0 +PKG_LICENSE_FILES:=COPYING + +PKG_SOURCE_PROTO:=git +PKG_SOURCE_URL=https://github.com/firehol/netdata +PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION) +PKG_SOURCE_VERSION:=0ec2db444011f5b6ebf41dab45502c27cd544af2 +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz + +PKG_INSTALL:=1 +PKG_FIXUP:=autoreconf + +include $(INCLUDE_DIR)/package.mk + +define Package/netdata + SECTION:=package/network/utils + CATEGORY:=package/network/utilsistration + DEPENDS:=+zlib + TITLE:=Real-time performance monitoring tool + URL:=http://netdata.firehol.org/ +endef + +define Package/netdata/description + netdata is a highly optimized Linux daemon providing real-time performance + monitoring for Linux systems, applications and SNMP devices over the web. +endef + +define Package/netdata/conffiles +/etc/netdata/ +endef + +define Package/netdata/install + $(INSTALL_DIR) $(1)/etc/netdata + $(INSTALL_CONF) $(PKG_INSTALL_DIR)/etc/netdata/apps_groups.conf $(1)/etc/netdata + $(INSTALL_CONF) $(PKG_INSTALL_DIR)/etc/netdata/charts.d.conf $(1)/etc/netdata + $(INSTALL_CONF) ./files/netdata.conf $(1)/etc/netdata + $(INSTALL_DIR) $(1)/etc/init.d + $(INSTALL_BIN) ./files/netdata.init $(1)/etc/init.d/netdata + $(INSTALL_DIR) $(1)/usr/sbin + $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/sbin/netdata $(1)/usr/sbin/ + $(INSTALL_DIR) $(1)/usr/share/netdata + $(INSTALL_DIR) $(1)/usr/lib/netdata + $(CP) $(PKG_INSTALL_DIR)/usr/share/netdata $(1)/usr/share + $(CP) $(PKG_INSTALL_DIR)/usr/lib/netdata $(1)/usr/lib + chmod 4755 $(1)/usr/lib/netdata/plugins.d/apps.plugin +endef + +$(eval $(call BuildPackage,netdata)) diff --git a/package/network/utils/netdata/files/netdata.conf b/package/network/utils/netdata/files/netdata.conf new file mode 100644 index 0000000..e1f0964 --- /dev/null +++ b/package/network/utils/netdata/files/netdata.conf @@ -0,0 +1,16 @@ +[global] + run as user = nobody + web files owner = root + web files group = root + update every = 2 + history = 1800 + access log = none + debug log = syslog + error log = syslog + memory mode = ram + +[plugins] + charts.d = no + apps = no + node.d = no + tc = no diff --git a/package/network/utils/netdata/files/netdata.init b/package/network/utils/netdata/files/netdata.init new file mode 100644 index 0000000..448e56d --- /dev/null +++ b/package/network/utils/netdata/files/netdata.init @@ -0,0 +1,11 @@ +#!/bin/sh /etc/rc.common + +START=99 + +start() { + service_start /usr/sbin/netdata +} + +stop() { + service_stop /usr/sbin/netdata +} -- 2.1.4 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From nitroshift at yahoo.com Wed May 11 09:00:28 2016 From: nitroshift at yahoo.com (Sebastian Careba) Date: Wed, 11 May 2016 16:00:28 +0300 Subject: [OpenWrt-Devel] [PATCH] netdata: import new package Message-ID: <1462971628-14250-1-git-send-email-nitroshift@yahoo.com> This uses the current Git prerelease, as the latest stable (1.1.0) doesn't build cleanly. The default configuration makes a few changes for OpenWrt: - access log is disabled by default; too verbose for the circular syslog buffer, and logging to /tmp is risky memory-wise. Some sort of external device would be ideal for this. - error and debug logs are sent to OpenWrt's syslog - history and frequency times are halved to reduce memory usage, as recommended in the netdata wiki - external plugins are disabled to eliminate the dependency on bash and node.js. Those could be installed from OpenWrt packages if you wish to enable that functionality. All of those files are still present in the package. The installed size could be reduced by eliminating those files first. Signed-off-by: Claudio Leite Signed-off-by: Sebastian Careba --- package/network/utils/netdata/Makefile | 61 ++++++++++++++++++++++++++++++++++++++++ package/network/utils/netdata/files/netdata.conf | 16 +++++++++++ package/network/utils/netdata/files/netdata.init | 11 ++++++++ 3 files changed, 88 insertions(+) create mode 100644 package/network/utils/netdata/Makefile create mode 100644 package/network/utils/netdata/files/netdata.conf create mode 100644 package/network/utils/netdata/files/netdata.init diff --git a/package/network/utils/netdata/Makefile b/package/network/utils/netdata/Makefile new file mode 100644 index 0000000..d08b317 --- /dev/null +++ b/package/network/utils/netdata/Makefile @@ -0,0 +1,61 @@ +# +# Copyright (C) 2008-2016 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:=netdata +PKG_VERSION:=devel-20160508 +PKG_RELEASE:=1 +PKG_MAINTAINER:=Sebastian Careba +PKG_LICENSE:=GPL-3.0 +PKG_LICENSE_FILES:=COPYING + +PKG_SOURCE_PROTO:=git +PKG_SOURCE_URL=https://github.com/firehol/netdata +PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION) +PKG_SOURCE_VERSION:=0ec2db444011f5b6ebf41dab45502c27cd544af2 +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz + +PKG_INSTALL:=1 +PKG_FIXUP:=autoreconf + +include $(INCLUDE_DIR)/package.mk + +define Package/netdata + SECTION:=package/network/utils + CATEGORY:=package/network/utilsistration + DEPENDS:=+zlib + TITLE:=Real-time performance monitoring tool + URL:=http://netdata.firehol.org/ +endef + +define Package/netdata/description + netdata is a highly optimized Linux daemon providing real-time performance + monitoring for Linux systems, applications and SNMP devices over the web. +endef + +define Package/netdata/conffiles +/etc/netdata/ +endef + +define Package/netdata/install + $(INSTALL_DIR) $(1)/etc/netdata + $(INSTALL_CONF) $(PKG_INSTALL_DIR)/etc/netdata/apps_groups.conf $(1)/etc/netdata + $(INSTALL_CONF) $(PKG_INSTALL_DIR)/etc/netdata/charts.d.conf $(1)/etc/netdata + $(INSTALL_CONF) ./files/netdata.conf $(1)/etc/netdata + $(INSTALL_DIR) $(1)/etc/init.d + $(INSTALL_BIN) ./files/netdata.init $(1)/etc/init.d/netdata + $(INSTALL_DIR) $(1)/usr/sbin + $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/sbin/netdata $(1)/usr/sbin/ + $(INSTALL_DIR) $(1)/usr/share/netdata + $(INSTALL_DIR) $(1)/usr/lib/netdata + $(CP) $(PKG_INSTALL_DIR)/usr/share/netdata $(1)/usr/share + $(CP) $(PKG_INSTALL_DIR)/usr/lib/netdata $(1)/usr/lib + chmod 4755 $(1)/usr/lib/netdata/plugins.d/apps.plugin +endef + +$(eval $(call BuildPackage,netdata)) diff --git a/package/network/utils/netdata/files/netdata.conf b/package/network/utils/netdata/files/netdata.conf new file mode 100644 index 0000000..e1f0964 --- /dev/null +++ b/package/network/utils/netdata/files/netdata.conf @@ -0,0 +1,16 @@ +[global] + run as user = nobody + web files owner = root + web files group = root + update every = 2 + history = 1800 + access log = none + debug log = syslog + error log = syslog + memory mode = ram + +[plugins] + charts.d = no + apps = no + node.d = no + tc = no diff --git a/package/network/utils/netdata/files/netdata.init b/package/network/utils/netdata/files/netdata.init new file mode 100644 index 0000000..448e56d --- /dev/null +++ b/package/network/utils/netdata/files/netdata.init @@ -0,0 +1,11 @@ +#!/bin/sh /etc/rc.common + +START=99 + +start() { + service_start /usr/sbin/netdata +} + +stop() { + service_stop /usr/sbin/netdata +} -- 2.1.4 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From nitroshift at yahoo.com Wed May 11 09:03:41 2016 From: nitroshift at yahoo.com (Sebastian Careba) Date: Wed, 11 May 2016 16:03:41 +0300 Subject: [OpenWrt-Devel] [PATCH] netdata: import new package Message-ID: <1462971821-18615-1-git-send-email-nitroshift@yahoo.com> Netdata (https://github.com/firehol/netdata) is a real-time performance monitoring tool. This submission uses the current Git prerelease, as the latest stable (1.1.0)doesn't build cleanly. The default configuration makes a few changes for OpenWrt: - access log is disabled by default; too verbose for the circular syslog buffer, and logging to /tmp is risky memory-wise. Some sort of external device would be ideal for this. - error and debug logs are sent to OpenWrt's syslog - history and frequency times are halved to reduce memory usage, as recommended in the netdata wiki - external plugins are disabled to eliminate the dependency on bash and node.js. Those could be installed from OpenWrt packages if you wish to enable that functionality. All of those files are still present in the package. The installed size could be reduced by eliminating those files first. Signed-off-by: Claudio Leite Signed-off-by: Sebastian Careba --- package/network/utils/netdata/Makefile | 61 ++++++++++++++++++++++++++++++++++++++++ package/network/utils/netdata/files/netdata.conf | 16 +++++++++++ package/network/utils/netdata/files/netdata.init | 11 ++++++++ 3 files changed, 88 insertions(+) create mode 100644 package/network/utils/netdata/Makefile create mode 100644 package/network/utils/netdata/files/netdata.conf create mode 100644 package/network/utils/netdata/files/netdata.init diff --git a/package/network/utils/netdata/Makefile b/package/network/utils/netdata/Makefile new file mode 100644 index 0000000..d08b317 --- /dev/null +++ b/package/network/utils/netdata/Makefile @@ -0,0 +1,61 @@ +# +# Copyright (C) 2008-2016 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:=netdata +PKG_VERSION:=devel-20160508 +PKG_RELEASE:=1 +PKG_MAINTAINER:=Sebastian Careba +PKG_LICENSE:=GPL-3.0 +PKG_LICENSE_FILES:=COPYING + +PKG_SOURCE_PROTO:=git +PKG_SOURCE_URL=https://github.com/firehol/netdata +PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION) +PKG_SOURCE_VERSION:=0ec2db444011f5b6ebf41dab45502c27cd544af2 +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz + +PKG_INSTALL:=1 +PKG_FIXUP:=autoreconf + +include $(INCLUDE_DIR)/package.mk + +define Package/netdata + SECTION:=package/network/utils + CATEGORY:=package/network/utilsistration + DEPENDS:=+zlib + TITLE:=Real-time performance monitoring tool + URL:=http://netdata.firehol.org/ +endef + +define Package/netdata/description + netdata is a highly optimized Linux daemon providing real-time performance + monitoring for Linux systems, applications and SNMP devices over the web. +endef + +define Package/netdata/conffiles +/etc/netdata/ +endef + +define Package/netdata/install + $(INSTALL_DIR) $(1)/etc/netdata + $(INSTALL_CONF) $(PKG_INSTALL_DIR)/etc/netdata/apps_groups.conf $(1)/etc/netdata + $(INSTALL_CONF) $(PKG_INSTALL_DIR)/etc/netdata/charts.d.conf $(1)/etc/netdata + $(INSTALL_CONF) ./files/netdata.conf $(1)/etc/netdata + $(INSTALL_DIR) $(1)/etc/init.d + $(INSTALL_BIN) ./files/netdata.init $(1)/etc/init.d/netdata + $(INSTALL_DIR) $(1)/usr/sbin + $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/sbin/netdata $(1)/usr/sbin/ + $(INSTALL_DIR) $(1)/usr/share/netdata + $(INSTALL_DIR) $(1)/usr/lib/netdata + $(CP) $(PKG_INSTALL_DIR)/usr/share/netdata $(1)/usr/share + $(CP) $(PKG_INSTALL_DIR)/usr/lib/netdata $(1)/usr/lib + chmod 4755 $(1)/usr/lib/netdata/plugins.d/apps.plugin +endef + +$(eval $(call BuildPackage,netdata)) diff --git a/package/network/utils/netdata/files/netdata.conf b/package/network/utils/netdata/files/netdata.conf new file mode 100644 index 0000000..e1f0964 --- /dev/null +++ b/package/network/utils/netdata/files/netdata.conf @@ -0,0 +1,16 @@ +[global] + run as user = nobody + web files owner = root + web files group = root + update every = 2 + history = 1800 + access log = none + debug log = syslog + error log = syslog + memory mode = ram + +[plugins] + charts.d = no + apps = no + node.d = no + tc = no diff --git a/package/network/utils/netdata/files/netdata.init b/package/network/utils/netdata/files/netdata.init new file mode 100644 index 0000000..448e56d --- /dev/null +++ b/package/network/utils/netdata/files/netdata.init @@ -0,0 +1,11 @@ +#!/bin/sh /etc/rc.common + +START=99 + +start() { + service_start /usr/sbin/netdata +} + +stop() { + service_stop /usr/sbin/netdata +} -- 2.1.4 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From thess at kitschensync.net Wed May 11 09:37:27 2016 From: thess at kitschensync.net (Ted Hess) Date: Wed, 11 May 2016 09:37:27 -0400 Subject: [OpenWrt-Devel] [PATCH] netdata: import new package In-Reply-To: <1462971821-18615-1-git-send-email-nitroshift@yahoo.com> References: <1462971821-18615-1-git-send-email-nitroshift@yahoo.com> Message-ID: <2BA947EA2E5E4D98994A105BB6EE8C82@fortmeadow.com> Hi Sebastian - I don't think this is part of the core packages necessary for OpenWrt base systems. I think it better that you submit this as a PR on https://github.com/openwrt/packages. Thanks, /ted -----Original Message----- From: Sebastian Careba Sent: Wednesday, May 11, 2016 9:03 AM To: openwrt-devel at lists.openwrt.org Cc: Sebastian Careba Subject: [OpenWrt-Devel] [PATCH] netdata: import new package Netdata (https://github.com/firehol/netdata) is a real-time performance monitoring tool. This submission uses the current Git prerelease, as the latest stable (1.1.0)doesn't build cleanly. The default configuration makes a few changes for OpenWrt: - access log is disabled by default; too verbose for the circular syslog buffer, and logging to /tmp is risky memory-wise. Some sort of external device would be ideal for this. - error and debug logs are sent to OpenWrt's syslog - history and frequency times are halved to reduce memory usage, as recommended in the netdata wiki - external plugins are disabled to eliminate the dependency on bash and node.js. Those could be installed from OpenWrt packages if you wish to enable that functionality. All of those files are still present in the package. The installed size could be reduced by eliminating those files first. Signed-off-by: Claudio Leite Signed-off-by: Sebastian Careba --- package/network/utils/netdata/Makefile | 61 ++++++++++++++++++++++++++++++++++++++++ package/network/utils/netdata/files/netdata.conf | 16 +++++++++++ package/network/utils/netdata/files/netdata.init | 11 ++++++++ 3 files changed, 88 insertions(+) create mode 100644 package/network/utils/netdata/Makefile create mode 100644 package/network/utils/netdata/files/netdata.conf create mode 100644 package/network/utils/netdata/files/netdata.init diff --git a/package/network/utils/netdata/Makefile b/package/network/utils/netdata/Makefile new file mode 100644 index 0000000..d08b317 --- /dev/null +++ b/package/network/utils/netdata/Makefile @@ -0,0 +1,61 @@ +# +# Copyright (C) 2008-2016 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:=netdata +PKG_VERSION:=devel-20160508 +PKG_RELEASE:=1 +PKG_MAINTAINER:=Sebastian Careba +PKG_LICENSE:=GPL-3.0 +PKG_LICENSE_FILES:=COPYING + +PKG_SOURCE_PROTO:=git +PKG_SOURCE_URL=https://github.com/firehol/netdata +PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION) +PKG_SOURCE_VERSION:=0ec2db444011f5b6ebf41dab45502c27cd544af2 +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz + +PKG_INSTALL:=1 +PKG_FIXUP:=autoreconf + +include $(INCLUDE_DIR)/package.mk + +define Package/netdata + SECTION:=package/network/utils + CATEGORY:=package/network/utilsistration + DEPENDS:=+zlib + TITLE:=Real-time performance monitoring tool + URL:=http://netdata.firehol.org/ +endef + +define Package/netdata/description + netdata is a highly optimized Linux daemon providing real-time performance + monitoring for Linux systems, applications and SNMP devices over the web. +endef + +define Package/netdata/conffiles +/etc/netdata/ +endef + +define Package/netdata/install + $(INSTALL_DIR) $(1)/etc/netdata + $(INSTALL_CONF) $(PKG_INSTALL_DIR)/etc/netdata/apps_groups.conf $(1)/etc/netdata + $(INSTALL_CONF) $(PKG_INSTALL_DIR)/etc/netdata/charts.d.conf $(1)/etc/netdata + $(INSTALL_CONF) ./files/netdata.conf $(1)/etc/netdata + $(INSTALL_DIR) $(1)/etc/init.d + $(INSTALL_BIN) ./files/netdata.init $(1)/etc/init.d/netdata + $(INSTALL_DIR) $(1)/usr/sbin + $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/sbin/netdata $(1)/usr/sbin/ + $(INSTALL_DIR) $(1)/usr/share/netdata + $(INSTALL_DIR) $(1)/usr/lib/netdata + $(CP) $(PKG_INSTALL_DIR)/usr/share/netdata $(1)/usr/share + $(CP) $(PKG_INSTALL_DIR)/usr/lib/netdata $(1)/usr/lib + chmod 4755 $(1)/usr/lib/netdata/plugins.d/apps.plugin +endef + +$(eval $(call BuildPackage,netdata)) diff --git a/package/network/utils/netdata/files/netdata.conf b/package/network/utils/netdata/files/netdata.conf new file mode 100644 index 0000000..e1f0964 --- /dev/null +++ b/package/network/utils/netdata/files/netdata.conf @@ -0,0 +1,16 @@ +[global] + run as user = nobody + web files owner = root + web files group = root + update every = 2 + history = 1800 + access log = none + debug log = syslog + error log = syslog + memory mode = ram + +[plugins] + charts.d = no + apps = no + node.d = no + tc = no diff --git a/package/network/utils/netdata/files/netdata.init b/package/network/utils/netdata/files/netdata.init new file mode 100644 index 0000000..448e56d --- /dev/null +++ b/package/network/utils/netdata/files/netdata.init @@ -0,0 +1,11 @@ +#!/bin/sh /etc/rc.common + +START=99 + +start() { + service_start /usr/sbin/netdata +} + +stop() { + service_stop /usr/sbin/netdata +} -- 2.1.4 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From swaroopkumarsarma at yahoo.co.in Wed May 11 09:47:28 2016 From: swaroopkumarsarma at yahoo.co.in (swaroop sarma) Date: Wed, 11 May 2016 13:47:28 +0000 (UTC) Subject: [OpenWrt-Devel] [PATCH] Host build tool pathc-image: Add optional command line argument to override dtb max size , to provide flexibility for bigger dtbs References: <1608981354.452285.1462974448546.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <1608981354.452285.1462974448546.JavaMail.yahoo@mail.yahoo.com> ?Add optional commandline argument to override dtb max size. Used for platforms which uses large amount of device tree source codes. diff --git a/tools/patch-image/src/patch-cmdline.c b/tools/patch-image/src/patch-cmdline.c --- a/tools/patch-image/src/patch-cmdline.c +++ b/tools/patch-image/src/patch-cmdline.c @@ -35,11 +35,18 @@ int main(int argc, char **argv) ?{ ??int fd, found = 0, len, ret = -1; ??char *ptr, *p; +?unsigned int search_space; ? -?if (argc != 3) { -??fprintf(stderr, "Usage: %s \n", argv[0]); +?if (argc <= 2 || argc > 4) { +??fprintf(stderr, "Usage: %s [dtb max size]\n", argv[0]); ???goto err1; +?} else if (argc == 3) { +??fprintf(stdout, "DTB max size set to defaults (16KB). You can also override it by passing a size (in bytes) as an additional argument.\n"); +??search_space =? SEARCH_SPACE; +?} else { +??search_space = atoi(argv[3]); ??} + ??len = strlen(argv[2]); ??if (len + 9 > CMDLINE_MAX) { ???fprintf(stderr, "Command line string too long\n"); @@ -47,12 +54,12 @@ int main(int argc, char **argv) ??} ?? ??if (((fd = open(argv[1], O_RDWR)) < 0) || -??(ptr = (char *) mmap(0, SEARCH_SPACE + CMDLINE_MAX, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0)) == (void *) (-1)) { +??(ptr = (char *) mmap(0, search_space + CMDLINE_MAX, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0)) == (void *) (-1)) { ???fprintf(stderr, "Could not open kernel image"); ???goto err2; ??} ?? -?for (p = ptr; p < (ptr + SEARCH_SPACE); p += 4) { +?for (p = ptr; p < (ptr + search_space); p += 4) { ???if (memcmp(p, "CMDLINE:", 8) == 0) { ????found = 1; ????p += 8; diff --git a/tools/patch-image/src/patch-dtb.c b/tools/patch-image/src/patch-dtb.c --- a/tools/patch-image/src/patch-dtb.c +++ b/tools/patch-image/src/patch-dtb.c @@ -38,11 +38,19 @@ int main(int argc, char **argv) ??int fd, fddtb, found = 0, len, ret = -1; ??char *ptr, *ptrdtb, *p; ??struct stat s; +?unsigned int search_space, dtb_max_size; ? -?if (argc != 3) { -??fprintf(stderr, "Usage: %s \n", argv[0]); +?if (argc <= 2 || argc > 4) { +??fprintf(stderr, "Usage: %s [dtb max size]\n", argv[0]); ???goto err1; +?} else if (argc == 3) { +??fprintf(stdout, "DTB max size set to defaults (16KB). You can also override it by passing a size (in bytes) as an additional argument.\n"); +??search_space = SEARCH_SPACE; +??dtb_max_size = DTB_MAX; +?} else { +??search_space = dtb_max_size = atoi(argv[3]); ??} + ??fddtb = open(argv[1], O_RDONLY); ??if (!fddtb) ???goto err1; @@ -53,24 +61,24 @@ int main(int argc, char **argv) ??} ? ??len = s.st_size; -?if (len + 8 > DTB_MAX) { +?if (len + 8 > dtb_max_size) { ???fprintf(stderr, "DTB too big\n"); ???goto err1; ??} ? ???????? if (((fddtb = open(argv[2], O_RDONLY)) < 0) || -??(ptrdtb = (char *) mmap(0, DTB_MAX, PROT_READ, MAP_SHARED, fddtb, 0)) == (void *) (-1)) { +??(ptrdtb = (char *) mmap(0, dtb_max_size, PROT_READ, MAP_SHARED, fddtb, 0)) == (void *) (-1)) { ???fprintf(stderr, "Could not open DTB"); ???goto err2; ??} ? ??if (((fd = open(argv[1], O_RDWR)) < 0) || -??(ptr = (char *) mmap(0, SEARCH_SPACE + DTB_MAX, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0)) == (void *) (-1)) { +??(ptr = (char *) mmap(0, search_space + dtb_max_size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0)) == (void *) (-1)) { ???fprintf(stderr, "Could not open kernel image"); ???goto err3; ??} ? -?for (p = ptr; p < (ptr + SEARCH_SPACE); p += 4) { +?for (p = ptr; p < (ptr + search_space); p += 4) { ???if (memcmp(p, "OWRTDTB:", 8) == 0) { ????found = 1; ????p += 8; @@ -82,7 +90,7 @@ int main(int argc, char **argv) ???goto err4; ??} ? -?memset(p, 0, DTB_MAX - 8); +?memset(p, 0, dtb_max_size - 8); ??memcpy(p, ptrdtb, len); ??msync(p, len, MS_SYNC|MS_INVALIDATE); ??ret = 0; Signed-off-by:?Swaroop Sarma?< duddu.swaroop at intel.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From bapclenet at gmail.com Wed May 11 10:53:32 2016 From: bapclenet at gmail.com (Baptiste Clenet) Date: Wed, 11 May 2016 16:53:32 +0200 Subject: [OpenWrt-Devel] mt76 wifi module on mt7688 board, no interface In-Reply-To: References: <570FB001.8030507@phrozen.org> <1461265121.8314.4.camel@noblepepper.com> Message-ID: 2016-05-09 18:57 GMT+02:00 John Crispin : > Hi Baptiste, > > on my list for this week Ok John, let us know your set up to make mt76 as a wifi interface on mt7688, thanks. > > John > > On 09/05/2016 18:56, Baptiste Clenet wrote: >> Lazar, >> Have you managed to make mt76 work on mt7688? >> >> Thanks >> >> 2016-05-03 1:52 GMT+02:00 Lazar Demin : >>> Marc, >>> Can you expand on what you did to get the AP to work? I'm completely >>> stumped... >>> >>> Any luck on the STA? >>> >>> >>> Thanks >>> >>> On Thu, Apr 21, 2016 at 3:00 PM, Marc Nicholas wrote: >>>> >>>> Is the firmware getting loaded (/lib/firmware/mt7628_e2.bin)? It looks >>>> like the fix in 48958 for this is in github.com/openwrt-mirror/ but not >>>> in github.com/openwrt/. >>>> >>>> Yes, the firmware is getting loaded based on the boot logs. >>>> >>>> I?ve gotten a bit further and have AP mode running. But can?t for the life >>>> of me get STA to work?.can?t even scan for APs. :-/ >>>> >>>> Thanks! >>>> >>>> -m >>>> >>>> -- >>>> >>>> _______________________________________________ >>>> openwrt-devel mailing list >>>> openwrt-devel at lists.openwrt.org >>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >>>> >>> >>> >>> _______________________________________________ >>> openwrt-devel mailing list >>> openwrt-devel at lists.openwrt.org >>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >>> >> >> >> > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -- Baptiste _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From marc at wimoto.com Wed May 11 10:55:04 2016 From: marc at wimoto.com (Marc Nicholas) Date: Wed, 11 May 2016 10:55:04 -0400 Subject: [OpenWrt-Devel] mt76 wifi module on mt7688 board, no interface In-Reply-To: References: <570FB001.8030507@phrozen.org> <1461265121.8314.4.camel@noblepepper.com> Message-ID: I managed to get AP to work just with a bit of fiddling. I didn?t do much testing, but I did note I seemed to have trouble once I added encryption (WPA2). No luck on STA. :( -m --? Marc Nicholas CTO, Wimoto Technologies Inc. Unit 2, 300 Don Park Road, Markham, Ontario L3R 3A1 CANADA +1.416.414.6272 On May 11, 2016 at 10:53:47 AM, Baptiste Clenet (bapclenet at gmail.com) wrote: 2016-05-09 18:57 GMT+02:00 John Crispin : > Hi Baptiste, > > on my list for this week Ok John, let us know your set up to make mt76 as a wifi interface on mt7688, thanks. > > John > > On 09/05/2016 18:56, Baptiste Clenet wrote: >> Lazar, >> Have you managed to make mt76 work on mt7688? >> >> Thanks >> >> 2016-05-03 1:52 GMT+02:00 Lazar Demin : >>> Marc, >>> Can you expand on what you did to get the AP to work? I'm completely >>> stumped... >>> >>> Any luck on the STA? >>> >>> >>> Thanks >>> >>> On Thu, Apr 21, 2016 at 3:00 PM, Marc Nicholas wrote: >>>> >>>> Is the firmware getting loaded (/lib/firmware/mt7628_e2.bin)? It looks >>>> like the fix in 48958 for this is in github.com/openwrt-mirror/ but not >>>> in github.com/openwrt/. >>>> >>>> Yes, the firmware is getting loaded based on the boot logs. >>>> >>>> I?ve gotten a bit further and have AP mode running. But can?t for the life >>>> of me get STA to work?.can?t even scan for APs. :-/ >>>> >>>> Thanks! >>>> >>>> -m >>>> >>>> -- >>>> >>>> _______________________________________________ >>>> openwrt-devel mailing list >>>> openwrt-devel at lists.openwrt.org >>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >>>> >>> >>> >>> _______________________________________________ >>> openwrt-devel mailing list >>> openwrt-devel at lists.openwrt.org >>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >>> >> >> >> > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -- Baptiste _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From shankar.unni+openwrt at gmail.com Wed May 11 12:22:03 2016 From: shankar.unni+openwrt at gmail.com (Shankar Unni) Date: Wed, 11 May 2016 09:22:03 -0700 Subject: [OpenWrt-Devel] [PATCH] netdata: import new package In-Reply-To: <1462971628-14250-1-git-send-email-nitroshift@yahoo.com> References: <1462971628-14250-1-git-send-email-nitroshift@yahoo.com> Message-ID: On Wed, May 11, 2016 at 6:00 AM, Sebastian Careba wrote: > This uses the current Git prerelease, as the latest stable (1.1.0) > doesn't build cleanly. > > The default configuration makes a few changes for OpenWrt: > - access log is disabled by default; too verbose for the circular > syslog buffer, and logging to /tmp is risky memory-wise. > Some sort of external device would be ideal for this. > > - error and debug logs are sent to OpenWrt's syslog > > - history and frequency times are halved to reduce memory usage, > as recommended in the netdata wiki > > - external plugins are disabled to eliminate the dependency on bash > and node.js. Those could be installed from OpenWrt packages if > you wish to enable that functionality. > > All of those files are still present in the package. The installed > size could be reduced by eliminating those files first. > > Signed-off-by: Claudio Leite > Signed-off-by: Sebastian Careba > > --- > package/network/utils/netdata/Makefile | 61 ++++++++++++++++++++++++++++++++++++++++ > package/network/utils/netdata/files/netdata.conf | 16 +++++++++++ > package/network/utils/netdata/files/netdata.init | 11 ++++++++ > 3 files changed, 88 insertions(+) > create mode 100644 package/network/utils/netdata/Makefile > create mode 100644 package/network/utils/netdata/files/netdata.conf > create mode 100644 package/network/utils/netdata/files/netdata.init > > diff --git a/package/network/utils/netdata/Makefile b/package/network/utils/netdata/Makefile > new file mode 100644 > index 0000000..d08b317 > --- /dev/null > +++ b/package/network/utils/netdata/Makefile > @@ -0,0 +1,61 @@ > +# > +# Copyright (C) 2008-2016 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:=netdata > +PKG_VERSION:=devel-20160508 > +PKG_RELEASE:=1 > +PKG_MAINTAINER:=Sebastian Careba > +PKG_LICENSE:=GPL-3.0 > +PKG_LICENSE_FILES:=COPYING > + > +PKG_SOURCE_PROTO:=git > +PKG_SOURCE_URL=https://github.com/firehol/netdata > +PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION) > +PKG_SOURCE_VERSION:=0ec2db444011f5b6ebf41dab45502c27cd544af2 > +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz > + > +PKG_INSTALL:=1 > +PKG_FIXUP:=autoreconf > + > +include $(INCLUDE_DIR)/package.mk > + > +define Package/netdata > + SECTION:=package/network/utils > + CATEGORY:=package/network/utilsistration What exactly is "utilistration"? Is this a typo? > + DEPENDS:=+zlib > + TITLE:=Real-time performance monitoring tool > + URL:=http://netdata.firehol.org/ > +endef > + > +define Package/netdata/description > + netdata is a highly optimized Linux daemon providing real-time performance > + monitoring for Linux systems, applications and SNMP devices over the web. > +endef > + > +define Package/netdata/conffiles > +/etc/netdata/ > +endef > + > +define Package/netdata/install > + $(INSTALL_DIR) $(1)/etc/netdata > + $(INSTALL_CONF) $(PKG_INSTALL_DIR)/etc/netdata/apps_groups.conf $(1)/etc/netdata > + $(INSTALL_CONF) $(PKG_INSTALL_DIR)/etc/netdata/charts.d.conf $(1)/etc/netdata > + $(INSTALL_CONF) ./files/netdata.conf $(1)/etc/netdata > + $(INSTALL_DIR) $(1)/etc/init.d > + $(INSTALL_BIN) ./files/netdata.init $(1)/etc/init.d/netdata > + $(INSTALL_DIR) $(1)/usr/sbin > + $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/sbin/netdata $(1)/usr/sbin/ > + $(INSTALL_DIR) $(1)/usr/share/netdata > + $(INSTALL_DIR) $(1)/usr/lib/netdata > + $(CP) $(PKG_INSTALL_DIR)/usr/share/netdata $(1)/usr/share > + $(CP) $(PKG_INSTALL_DIR)/usr/lib/netdata $(1)/usr/lib > + chmod 4755 $(1)/usr/lib/netdata/plugins.d/apps.plugin > +endef > + > +$(eval $(call BuildPackage,netdata)) > diff --git a/package/network/utils/netdata/files/netdata.conf b/package/network/utils/netdata/files/netdata.conf > new file mode 100644 > index 0000000..e1f0964 > --- /dev/null > +++ b/package/network/utils/netdata/files/netdata.conf > @@ -0,0 +1,16 @@ > +[global] > + run as user = nobody > + web files owner = root > + web files group = root > + update every = 2 > + history = 1800 > + access log = none > + debug log = syslog > + error log = syslog > + memory mode = ram > + > +[plugins] > + charts.d = no > + apps = no > + node.d = no > + tc = no > diff --git a/package/network/utils/netdata/files/netdata.init b/package/network/utils/netdata/files/netdata.init > new file mode 100644 > index 0000000..448e56d > --- /dev/null > +++ b/package/network/utils/netdata/files/netdata.init > @@ -0,0 +1,11 @@ > +#!/bin/sh /etc/rc.common > + > +START=99 > + > +start() { > + service_start /usr/sbin/netdata > +} > + > +stop() { > + service_stop /usr/sbin/netdata > +} > -- > 2.1.4 > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From john at phrozen.org Wed May 11 14:26:43 2016 From: john at phrozen.org (John Crispin) Date: Wed, 11 May 2016 20:26:43 +0200 Subject: [OpenWrt-Devel] [PATCH 2/4] get buffer size from driver In-Reply-To: <1462965844-12904-3-git-send-email-bjorn@mork.no> References: <1462965844-12904-1-git-send-email-bjorn@mork.no> <1462965844-12904-3-git-send-email-bjorn@mork.no> Message-ID: Hi, pulled the series into the umbim git just now. small issue inline On 11/05/2016 13:24, Bj?rn Mork wrote: > Signed-off-by: Bj?rn Mork > --- > mbim-dev.c | 11 ++++++++++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/mbim-dev.c b/mbim-dev.c > index 34bb2c228eb0..dd1110daeb52 100644 > --- a/mbim-dev.c > +++ b/mbim-dev.c > @@ -12,6 +12,8 @@ > * GNU General Public License for more details. > */ > > +#include due to this a simple "cmake . && make" does not cut it anymore. we'll need to tweak the CMakefile to find the headers when compilig outside the buildroot John > +#include > #include > #include > > @@ -132,13 +134,20 @@ mbim_recv(struct uloop_fd *u, unsigned int events) > void > mbim_open(const char *path) > { > + __u16 max; > + int rc; > + > mbim_fd.cb = mbim_recv; > mbim_fd.fd = open(path, O_RDWR); > if (mbim_fd.fd < 1) { > perror("open failed: "); > exit(-1); > } > - mbim_bufsize = MBIM_BUFFER_SIZE; > + rc = ioctl(mbim_fd.fd, IOCTL_WDM_MAX_COMMAND, &max); > + if (!rc) > + mbim_bufsize = max; > + else > + mbim_bufsize = 512; > mbim_buffer = malloc(mbim_bufsize); > uloop_fd_add(&mbim_fd, ULOOP_READ); > } > _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From andrej.vlasic at sartura.hr Wed May 11 15:31:48 2016 From: andrej.vlasic at sartura.hr (Andrej Vlasic) Date: Wed, 11 May 2016 19:31:48 +0000 Subject: [OpenWrt-Devel] [PATCH v4 1/4] mvebu: add squashfs image type to MMCProfile In-Reply-To: <572BE229.7080102@gmail.com> References: <1462389868-18371-1-git-send-email-josua.mayer97@gmail.com> <010001548361368b-b6dcbdda-12e9-4999-8a4a-754cf736e8bf-000000@email.amazonses.com> <572BE229.7080102@gmail.com> Message-ID: <01000154a14dc282-e533b4ec-eff8-4b26-b317-2b7c8ccb658b-000000@email.amazonses.com> Hi Josua, On 06.05.2016 02:15, Josua Mayer wrote: > Hi Andrej, > > First let me thank you for taking the time to review my proposals! > > Am 06.05.2016 um 02:04 schrieb Andrej Vlasic: >> Hi Josua, >> >> On 04.05.2016 21:24, josua.mayer97 at gmail.com wrote: >>> From: Josua Mayer >>> >>> Added gen_mvebu_sdcard_img.sh to create bootable sdcard images. It takes >>> the bootloader and partition images to create a bootable sdcard image. >>> >>> Partition Layout: >>> p1: fat32: for kernel, dtb and boot config files if any >>> p2: squashfs: for openwrt >>> >>> This change is developed for the Clearfog, but should work on all A38x >>> SoCs that can boot from mmc. >>> >>> Signed-off-by: Josua Mayer >>> --- >>> target/linux/mvebu/image/Makefile | 16 ++++ >>> target/linux/mvebu/image/gen_mvebu_sdcard_img.sh | 100 >>> +++++++++++++++++++++++ >>> tools/Makefile | 1 + >>> 3 files changed, 117 insertions(+) >>> create mode 100755 target/linux/mvebu/image/gen_mvebu_sdcard_img.sh >>> >>> diff --git a/target/linux/mvebu/image/Makefile >>> b/target/linux/mvebu/image/Makefile >>> index cb73c3b..fc5fded 100644 >>> --- a/target/linux/mvebu/image/Makefile >>> +++ b/target/linux/mvebu/image/Makefile >>> @@ -107,6 +107,9 @@ define MMCProfile >>> ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),) >>> $(call Image/Build/Profile,$(1)/Initramfs) >>> endif >>> + ifneq ($(CONFIG_TARGET_ROOTFS_SQUASHFS),) >>> + $(call Image/Build/squashfs) >>> + endif >>> endef >>> >>> define Image/Build/Profile/$(1)/Initramfs >>> @@ -114,6 +117,19 @@ define MMCProfile >>> cp $(KDIR)/uImage-initramfs-$(2) >>> $(BIN_DIR)/$(IMG_PREFIX)-$(2)-initramfs >>> endef >>> >>> + define Image/Build/Profile/$(1)/squashfs >>> + $(call prepare_generic_squashfs,$(KDIR)/root.squashfs) >>> + cp $(KDIR)/root.squashfs $(BIN_DIR)/$(IMG_PREFIX)-$(2)-root.squashfs >>> + rm -f $(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32 >>> + mkfs.fat -C $(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32 $(shell echo >>> $$((4*1024)) # 4MB) >>> + mcopy -i $(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32 $(KDIR)/zImage :: >>> + mcopy -i $(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32 >>> $(DTS_DIR)/$(2).dtb :: >>> + ./gen_mvebu_sdcard_img.sh >>> "$(BIN_DIR)/$(IMG_PREFIX)-$(2)-squashfs-sdcard.img" \ >>> + >>> "$(BIN_DIR)/uboot-mvebu-clearfog/openwrt-mvebu-clearfog-u-boot-spl.kwb" \ >>> + c "$(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32" \ >>> + 83 "$(BIN_DIR)/$(IMG_PREFIX)-$(2)-root.squashfs" >>> + endef >>> + >> >> Image generation script here requires u-boot binary to exist, but what >> if one doesn't select u-boot to be generated? It would be better to > That would certainly be a problem. >> exclude it from generated sdcard image, it can be flashed anyway with dd >> to beginning of the sd card. > While I agree that this would work, it does not give the one-click > solution I would like to build. Why burden people with using dd to flash > u-boot to some magic offset on sdcard? > > Maybe we can add u-boot as a dependency so it is always built when > clearfog is selected? >> You could modify script to check if u-boot is selected and than include it, otherwise user just needs to flash it with dd to the beginning of sd card. >> Also one ext4 partition for boot and second one for rootfs would be >> better than fat32 + squashfs on sdcard, both Marvell u-boot and >> uboot-mvebu have support for loading kernel from ext4. > Very interesting you would argue on this part! > So I will just outline the reasons why I made this choice: > 1) fat32 > make it easier to edit boot files for Windows users too. > I think this will be very useful when somebody wants to supply bootargs > or try a different kernel, but is not familiar with using unix. Ok. > 2) squashfs > I like the read-only nature of squashfs. What I am working towards is a > system that feels like just any router out there. Factory wiping > involves just clearing the read-write part of storage, while firmware > updates replace the read-only parts. > If anyone messes up, they can just mkfs.ext4, or rm -rf * on the data > partition. Also for that you can use block2mtd support with squashfs image, makes it easier for upgrades, factory reset, etc. > > Please let me know if you agree or disagree here. >> >>> PROFILES_LIST += $(1) >>> endef >>> >>> diff --git a/target/linux/mvebu/image/gen_mvebu_sdcard_img.sh >>> b/target/linux/mvebu/image/gen_mvebu_sdcard_img.sh >>> new file mode 100755 >>> index 0000000..88d017a >>> --- /dev/null >>> +++ b/target/linux/mvebu/image/gen_mvebu_sdcard_img.sh >>> @@ -0,0 +1,100 @@ >>> +#!/bin/bash -x >>> +# >>> +# Copyright (C) 2016 Josua Mayer >>> +# >>> +# 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., 51 Franklin Street, Fifth Floor, Boston, MA >>> 02110-1301, USA. >>> +# >>> + >>> +usage() { >>> + echo "$0 [ >>> ]?" >>> +} >>> + >>> +# always require first 2 arguments >>> +# then in pairs up to 8 more for a total of up to 4 partitions >>> +if [ $# -lt 2 ] || [ $# -gt 10 ] || [ $((($#-2)%2)) -ne 0 ]; then >>> + usage >>> + exit 1 >>> +fi >>> + >>> +# static settings >>> +SDCARD_HEADS=16 >>> +SDCARD_SECTORS=63 >>> +SDCARD_ALIGNMENT=4096 >>> + >>> +# parameters >>> +OUTFILE="$1" >>> +BOOTLOADER="$2" >>> +# up to 4 partitions >>> +# when calculating size of images in Kilobytes, NEVER round down! >>> +PART1_TYPE=$3 >>> +PART1_IMG="$4" >>> +PART1_SIZE=$((($(stat --print="%s" "$PART1_IMG")+1023)/1024))K >>> +PART2_TYPE=$5 >>> +PART2_IMG="$6" >>> +PART2_SIZE=$((($(stat --print="%s" "$PART2_IMG")+1023)/1024))K >>> +PART3_TYPE=$7 >>> +PART3_IMG="$8" >>> +PART3_SIZE=$((($(stat --print="%s" "$PART3_IMG")+1023)/1024))K >>> +PART4_TYPE=$9 >>> +PART4_IMG="${10}" >>> +PART4_SIZE=$((($(stat --print="%s" "$PART4_IMG")+1023)/1024))K >>> + >>> +# So how many partitions were given? >>> +numparts=$((($#-2)/2)) >>> +case $numparts in >>> + 0) >>> + set `ptgen -o "$OUTFILE" \ >>> + -h $SDCARD_HEADS -s $SDCARD_SECTORS -l $SDCARD_ALIGNMENT` >>> + dd of="$OUTFILE" if="$BOOTLOADER" bs=512 seek=1 conv=notrunc >>> + ;; >>> + 1) >>> + set `ptgen -o "$OUTFILE" \ >>> + -h $SDCARD_HEADS -s $SDCARD_SECTORS -l $SDCARD_ALIGNMENT \ >>> + -t $PART1_TYPE -p $PART1_SIZE` >>> + dd of="$OUTFILE" if="$PART1_IMG" bs=512 seek=$(($1/512)) >>> conv=notrunc >>> + ;; >>> + 2) >>> + set `ptgen -o "$OUTFILE" \ >>> + -h $SDCARD_HEADS -s $SDCARD_SECTORS -l $SDCARD_ALIGNMENT \ >>> + -t $PART1_TYPE -p $PART1_SIZE \ >>> + -t $PART2_TYPE -p $PART2_SIZE` >>> + dd of="$OUTFILE" if="$BOOTLOADER" bs=512 seek=1 conv=notrunc >>> + dd of="$OUTFILE" if="$PART1_IMG" bs=512 seek=$(($1/512)) >>> conv=notrunc >>> + dd of="$OUTFILE" if="$PART2_IMG" bs=512 seek=$(($2/512)) >>> conv=notrunc >>> + ;; >>> + 3) >>> + set `ptgen -o "$OUTFILE" \ >>> + -h $SDCARD_HEADS -s $SDCARD_SECTORS -l $SDCARD_ALIGNMENT \ >>> + -t $PART1_TYPE -p $PART1_SIZE \ >>> + -t $PART2_TYPE -p $PART2_SIZE \ >>> + -t $PART3_TYPE -p $PART3_SIZE` >>> + dd of="$OUTFILE" if="$BOOTLOADER" bs=512 seek=1 conv=notrunc >>> + dd of="$OUTFILE" if="$PART1_IMG" bs=512 seek=$(($1/512)) >>> conv=notrunc >>> + dd of="$OUTFILE" if="$PART2_IMG" bs=512 seek=$(($2/512)) >>> conv=notrunc >>> + dd of="$OUTFILE" if="$PART3_IMG" bs=512 seek=$(($3/512)) >>> conv=notrunc >>> + ;; >>> + 4) >>> + set `ptgen -o "$OUTFILE" \ >>> + -h $SDCARD_HEADS -s $SDCARD_SECTORS -l $SDCARD_ALIGNMENT \ >>> + -t $PART1_TYPE -p $PART1_SIZE \ >>> + -t $PART2_TYPE -p $PART2_SIZE \ >>> + -t $PART3_TYPE -p $PART3_SIZE \ >>> + -t $PART4_TYPE -p $PART4_SIZE` >>> + dd of="$OUTFILE" if="$BOOTLOADER" bs=512 seek=1 conv=notrunc >>> + dd of="$OUTFILE" if="$PART1_IMG" bs=512 seek=$(($1/512)) >>> conv=notrunc >>> + dd of="$OUTFILE" if="$PART2_IMG" bs=512 seek=$(($2/512)) >>> conv=notrunc >>> + dd of="$OUTFILE" if="$PART3_IMG" bs=512 seek=$(($3/512)) >>> conv=notrunc >>> + dd of="$OUTFILE" if="$PART4_IMG" bs=512 seek=$(($4/512)) >>> conv=notrunc >>> +esac >>> diff --git a/tools/Makefile b/tools/Makefile >>> index 187655e..9a08573 100644 >>> --- a/tools/Makefile >>> +++ b/tools/Makefile >>> @@ -38,6 +38,7 @@ tools-$(CONFIG_TARGET_x86) += qemu >>> tools-$(CONFIG_TARGET_mxs) += elftosb sdimage >>> tools-$(CONFIG_TARGET_brcm2708)$(CONFIG_TARGET_sunxi)$(CONFIG_TARGET_mxs) >>> += mtools dosfstools >>> tools-$(CONFIG_TARGET_ar71xx) += lzma-old squashfs >>> +tools-$(CONFIG_TARGET_mvebu) += squashfs dosfstools >>> tools-y += lzma squashfs4 >>> tools-$(BUILD_B43_TOOLS) += b43-tools >>> tools-$(BUILD_PPL_CLOOG) += ppl cloog >>> _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From bjorn at mork.no Wed May 11 15:54:21 2016 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Wed, 11 May 2016 21:54:21 +0200 Subject: [OpenWrt-Devel] [PATCH 2/4] get buffer size from driver In-Reply-To: (John Crispin's message of "Wed, 11 May 2016 20:26:43 +0200") References: <1462965844-12904-1-git-send-email-bjorn@mork.no> <1462965844-12904-3-git-send-email-bjorn@mork.no> Message-ID: <87vb2kl6aa.fsf@nemi.mork.no> John Crispin writes: > Hi, > > pulled the series into the umbim git just now. small issue inline Thanks > On 11/05/2016 13:24, Bj?rn Mork wrote: >> Signed-off-by: Bj?rn Mork >> --- >> mbim-dev.c | 11 ++++++++++- >> 1 file changed, 10 insertions(+), 1 deletion(-) >> >> diff --git a/mbim-dev.c b/mbim-dev.c >> index 34bb2c228eb0..dd1110daeb52 100644 >> --- a/mbim-dev.c >> +++ b/mbim-dev.c >> @@ -12,6 +12,8 @@ >> * GNU General Public License for more details. >> */ >> >> +#include > > due to this a simple "cmake . && make" does not cut it anymore. we'll > need to tweak the CMakefile to find the headers when compilig outside > the buildroot Ah, sorry about that. I should have tested building it in different environments. Didn't think about this file being special. I guess we could simply copy the IOCTL_WDM_MAX_COMMAND macro instead, if including this file causes too much additional trouble. It's not like it can change. Bj?rn _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From john at phrozen.org Wed May 11 15:59:55 2016 From: john at phrozen.org (John Crispin) Date: Wed, 11 May 2016 21:59:55 +0200 Subject: [OpenWrt-Devel] [PATCH 2/4] get buffer size from driver In-Reply-To: <87vb2kl6aa.fsf@nemi.mork.no> References: <1462965844-12904-1-git-send-email-bjorn@mork.no> <1462965844-12904-3-git-send-email-bjorn@mork.no> <87vb2kl6aa.fsf@nemi.mork.no> Message-ID: <26b6633f-f68e-4a26-33e9-f6fa2a851000@phrozen.org> On 11/05/2016 21:54, Bj?rn Mork wrote: > John Crispin writes: > >> Hi, >> >> pulled the series into the umbim git just now. small issue inline > > Thanks > >> On 11/05/2016 13:24, Bj?rn Mork wrote: >>> Signed-off-by: Bj?rn Mork >>> --- >>> mbim-dev.c | 11 ++++++++++- >>> 1 file changed, 10 insertions(+), 1 deletion(-) >>> >>> diff --git a/mbim-dev.c b/mbim-dev.c >>> index 34bb2c228eb0..dd1110daeb52 100644 >>> --- a/mbim-dev.c >>> +++ b/mbim-dev.c >>> @@ -12,6 +12,8 @@ >>> * GNU General Public License for more details. >>> */ >>> >>> +#include >> >> due to this a simple "cmake . && make" does not cut it anymore. we'll >> need to tweak the CMakefile to find the headers when compilig outside >> the buildroot > > Ah, sorry about that. I should have tested building it in different > environments. Didn't think about this file being special. > > I guess we could simply copy the IOCTL_WDM_MAX_COMMAND macro instead, if > including this file causes too much additional trouble. It's not like > it can change. > > > Bj?rn > i'll just fix the cmakefile and male it look for local kernel headers John _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From Alexey.Brodkin at synopsys.com Wed May 11 18:08:55 2016 From: Alexey.Brodkin at synopsys.com (Alexey Brodkin) Date: Wed, 11 May 2016 22:08:55 +0000 Subject: [OpenWrt-Devel] Failed to execute /usr/libexec/login.sh Message-ID: <1463004513.2924.19.camel@synopsys.com> Hi Daniel, Looks like one recent commit: ----------------------------->8----------------------------- commit a1860283b37c7a26f78c7387227a42219e8b4d4d Author: luka Date:???Tue May 10 22:36:25 2016 +0000 ????image / basefiles: make console password configurable ???? ????Signed-off-by: Daniel Dickinson ????Signed-off-by: John Crispin ???? ????git-svn-id: svn://svn.openwrt.org/openwrt/trunk at 49325 3c298f89-4303-0410-b956-a3cf2f4a3e73 ----------------------------->8----------------------------- breaks something for my boards (in particular arc770-based boards). I'm unable to activate console now. That's what I'm getting every time I press ENTER: ----------------------------->8----------------------------- Failed to execute /usr/libexec/login.sh Please press Enter to activate this console. Failed to execute /usr/libexec/login.sh Please press Enter to activate this console. ----------------------------->8----------------------------- If I revert mentioned commit problem goes away. Any thoughts on what might be wrong here? Probably something is missing in my board's init scripts etc? -Alexey _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From luka at openwrt.org Wed May 11 18:43:12 2016 From: luka at openwrt.org (Luka Perkov) Date: Thu, 12 May 2016 00:43:12 +0200 Subject: [OpenWrt-Devel] Failed to execute /usr/libexec/login.sh In-Reply-To: <1463004513.2924.19.camel@synopsys.com> References: <1463004513.2924.19.camel@synopsys.com> Message-ID: <20160511224312.GC19024@localhost.localdomain> Hi Alexey, On Wed, May 11, 2016 at 10:08:55PM +0000, Alexey Brodkin wrote: > Hi Daniel, > > Looks like one recent commit: > ----------------------------->8----------------------------- > commit a1860283b37c7a26f78c7387227a42219e8b4d4d > Author: luka > Date:???Tue May 10 22:36:25 2016 +0000 > > ????image / basefiles: make console password configurable > ???? > ????Signed-off-by: Daniel Dickinson > ????Signed-off-by: John Crispin > ???? > ????git-svn-id: svn://svn.openwrt.org/openwrt/trunk at 49325 3c298f89-4303-0410-b956-a3cf2f4a3e73 > ----------------------------->8----------------------------- > > breaks something for my boards (in particular arc770-based boards). > I'm unable to activate console now. That's what I'm getting > every time I press ENTER: > ----------------------------->8----------------------------- > Failed to execute /usr/libexec/login.sh > Please press Enter to activate this console. > Failed to execute /usr/libexec/login.sh > Please press Enter to activate this console. > ----------------------------->8----------------------------- > > If I revert mentioned commit problem goes away. Thank you for reporting this. > Any thoughts on what might be wrong here? Can you please check r49376. I think that should fix it! Luka _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Thu May 12 02:17:08 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Thu, 12 May 2016 02:17:08 -0400 Subject: [OpenWrt-Devel] [LEDE-DEV] Failed to execute /usr/libexec/login.sh In-Reply-To: <1463004513.2924.19.camel@synopsys.com> References: <1463004513.2924.19.camel@synopsys.com> Message-ID: <57341FE4.4020504@daniel.thecshore.com> On 16-05-11 06:08 PM, Alexey Brodkin wrote: > Hi Daniel, > > Looks like one recent commit: [snip] > > breaks something for my boards (in particular arc770-based boards). > I'm unable to activate console now. That's what I'm getting > every time I press ENTER: > ----------------------------->8----------------------------- > Failed to execute /usr/libexec/login.sh > Please press Enter to activate this console. > Failed to execute /usr/libexec/login.sh > Please press Enter to activate this console. > ----------------------------->8----------------------------- > > If I revert mentioned commit problem goes away. > > Any thoughts on what might be wrong here? > Probably something is missing in my board's init scripts etc? Hi, I will have to dig into the actual commit (it was modified from the patch I sent, so I have to review the details, to see if it's related to the changes, or something special about that board). Regards, Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Thu May 12 02:26:03 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Thu, 12 May 2016 02:26:03 -0400 Subject: [OpenWrt-Devel] [LEDE-DEV] Failed to execute /usr/libexec/login.sh In-Reply-To: <1463004513.2924.19.camel@synopsys.com> References: <1463004513.2924.19.camel@synopsys.com> Message-ID: <573421FB.2030103@daniel.thecshore.com> On 16-05-11 06:08 PM, Alexey Brodkin wrote: > Hi Daniel, > > > breaks something for my boards (in particular arc770-based boards). > I'm unable to activate console now. That's what I'm getting > every time I press ENTER: > ----------------------------->8----------------------------- > Failed to execute /usr/libexec/login.sh > Please press Enter to activate this console. > Failed to execute /usr/libexec/login.sh > Please press Enter to activate this console. In your build tree build_dir/target-/root- can you verify bin/login bin/ash bin/sh all exist (they should be symlinks to busybox in bin/busybox which should also exist). also can you verify /usr/libexed/login.sh is exectuable? _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From noltari at gmail.com Thu May 12 02:36:07 2016 From: noltari at gmail.com (=?utf-8?Q?=C3=81lvaro_Fern=C3=A1ndez_Rojas?=) Date: Thu, 12 May 2016 08:36:07 +0200 Subject: [OpenWrt-Devel] [LEDE-DEV] Failed to execute /usr/libexec/login.sh In-Reply-To: <573421FB.2030103@daniel.thecshore.com> References: <1463004513.2924.19.camel@synopsys.com> <573421FB.2030103@daniel.thecshore.com> Message-ID: <7145f4c1-1c5c-44f8-ac84-84371b2713a6@Spark> Hello Daniel, It looks like Luka has already fixed this: https://dev.openwrt.org/changeset/49376 El 12 may 2016 8:26 +0200, Daniel Dickinson, escribi?: > On 16-05-11 06:08 PM, Alexey Brodkin wrote: > > Hi Daniel, > > > > > > breaks something for my boards (in particular arc770-based boards). > > I'm unable to activate console now. That's what I'm getting > > every time I press ENTER: > > ----------------------------->8----------------------------- > > Failed to execute /usr/libexec/login.sh > > Please press Enter to activate this console. > > Failed to execute /usr/libexec/login.sh > > Please press Enter to activate this console. > > In your build tree build_dir/target-/root- > can you verify > > bin/login > bin/ash > bin/sh > > all exist (they should be symlinks to busybox in bin/busybox which > should also exist). > > also can you verify /usr/libexed/login.sh is exectuable? > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From Alexey.Brodkin at synopsys.com Thu May 12 06:19:30 2016 From: Alexey.Brodkin at synopsys.com (Alexey Brodkin) Date: Thu, 12 May 2016 10:19:30 +0000 Subject: [OpenWrt-Devel] [LEDE-DEV] Failed to execute /usr/libexec/login.sh In-Reply-To: <7145f4c1-1c5c-44f8-ac84-84371b2713a6@Spark> References: <1463004513.2924.19.camel@synopsys.com> <573421FB.2030103@daniel.thecshore.com> <7145f4c1-1c5c-44f8-ac84-84371b2713a6@Spark> Message-ID: <1463048348.2924.25.camel@synopsys.com> Hi Alvaro, Daniel, On Thu, 2016-05-12 at 08:36 +0200, ?lvaro Fern?ndez Rojas wrote: Hello Daniel, It looks like Luka has already fixed this: https://dev.openwrt.org/changeset/49376 Indeed mentioned commit fixes previously observed problem. Thanks for the pointer. -Alexey _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From xotic750 at gmail.com Thu May 12 06:45:54 2016 From: xotic750 at gmail.com (Graham Fairweather) Date: Thu, 12 May 2016 12:45:54 +0200 Subject: [OpenWrt-Devel] [PATCH 001/001] [kernel] Bump linux LTS kernel from 4.1.23 to 4.1.24 Message-ID: From: Graham Fairweather Increment PATCH number, added MD5 sum for release. Patches were refreshed. *https://www.kernel.org/ * Signed-off-by: Graham Fairweather --- include/kernel-version.mk | 4 ++-- target/linux/brcm63xx/patches-4.1/001-4.2-MIPS-Add-support-for-vmlinux.bin-appended-dtb.patch | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/include/kernel-version.mk b/include/kernel-version.mk index 97ff9a3..49d9a2e 100644 --- a/include/kernel-version.mk +++ b/include/kernel-version.mk @@ -3,11 +3,11 @@ LINUX_RELEASE?=1 LINUX_VERSION-3.18 = .29 -LINUX_VERSION-4.1 = .23 +LINUX_VERSION-4.1 = .24 LINUX_VERSION-4.4 = .7 LINUX_KERNEL_MD5SUM-3.18.29 = b25737a0bc98e80d12200de93f239c28 -LINUX_KERNEL_MD5SUM-4.1.23 = 5cb969fa874e110118722398b7c72c5d +LINUX_KERNEL_MD5SUM-4.1.24 = 3eaf96af2d4c63b8a391da5161a44f08 LINUX_KERNEL_MD5SUM-4.4.7 = 4345597c9a10bd73c28b6ae3a854d8d7 ifdef KERNEL_PATCHVER diff --git a/target/linux/brcm63xx/patches-4.1/001-4.2-MIPS-Add-support-for-vmlinux.bin-appended-dtb.patch b/target/linux/brcm63xx/patches-4.1/001-4.2-MIPS-Add-support-for-vmlinux.bin-appended-dtb.patch index fa7732b..cd05780 100644 --- a/target/linux/brcm63xx/patches-4.1/001-4.2-MIPS-Add-support-for-vmlinux.bin-appended-dtb.patch +++ b/target/linux/brcm63xx/patches-4.1/001-4.2-MIPS-Add-support-for-vmlinux.bin-appended-dtb.patch @@ -33,7 +33,7 @@ Signed-off-by: Ralf Baechle --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig -@@ -2703,6 +2703,33 @@ config BOOT_RAW +@@ -2704,6 +2704,33 @@ config BOOT_RAW _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From xotic750 at gmail.com Thu May 12 06:47:22 2016 From: xotic750 at gmail.com (Graham Fairweather) Date: Thu, 12 May 2016 12:47:22 +0200 Subject: [OpenWrt-Devel] [PATCH 001/001] [kernel] Bump linux LTS kernel from 4.4.7 to 4.4.10 Message-ID: From: Graham Fairweather Increment PATCH number, added MD5 sum for release. Patches were refreshed. *https://www.kernel.org/ * Signed-off-by: Graham Fairweather --- include/kernel-version.mk | 4 ++-- target/linux/brcm63xx/patches-4.4/202-MTD-DEVICES-m25p80-use-parsers-if-provided-in-flash-.patch | 2 +- target/linux/brcm63xx/patches-4.4/203-MTD-DEVICES-m25p80-add-support-for-limiting-reads.patch | 4 ++-- target/linux/brcm63xx/patches-4.4/414-MTD-m25p80-allow-passing-pp_data.patch | 2 +- target/linux/generic/patches-4.4/045-mtd-devices-m25p80-add-support-for-mmap-read-request.patch | 2 +- target/linux/generic/patches-4.4/081-spi-bcm53xx-add-spi_flash_read-callback-for-MMIO-bas.patch | 12 ++++++------ target/linux/generic/patches-4.4/207-mips-vdso-dbg-rebuild-after-genvdso.patch | 14 ++++++-------- target/linux/generic/patches-4.4/630-packet_socket_type.patch | 10 +++++----- target/linux/generic/patches-4.4/642-bridge_port_isolate.patch | 4 ++-- target/linux/generic/patches-4.4/645-bridge_multicast_to_unicast.patch | 4 ++-- target/linux/generic/patches-4.4/655-increase_skb_pad.patch | 2 +- target/linux/generic/patches-4.4/656-skb_reduce_truesize-helper.patch | 2 +- target/linux/generic/patches-4.4/666-Add-support-for-MAP-E-FMRs-mesh-mode.patch | 26 +++++++++++++------------- target/linux/generic/patches-4.4/721-phy_packets.patch | 8 ++++---- target/linux/generic/patches-4.4/903-debloat_direct_io.patch | 4 ++-- 15 files changed, 49 insertions(+), 51 deletions(-) diff --git a/include/kernel-version.mk b/include/kernel-version.mk index 97ff9a3..c9fb0e1 100644 --- a/include/kernel-version.mk +++ b/include/kernel-version.mk @@ -4,11 +4,11 @@ LINUX_RELEASE?=1 LINUX_VERSION-3.18 = .29 LINUX_VERSION-4.1 = .23 -LINUX_VERSION-4.4 = .7 +LINUX_VERSION-4.4 = .10 LINUX_KERNEL_MD5SUM-3.18.29 = b25737a0bc98e80d12200de93f239c28 LINUX_KERNEL_MD5SUM-4.1.23 = 5cb969fa874e110118722398b7c72c5d -LINUX_KERNEL_MD5SUM-4.4.7 = 4345597c9a10bd73c28b6ae3a854d8d7 +LINUX_KERNEL_MD5SUM-4.4.10 = f7033cbe05e1359a347815ca52d051ed ifdef KERNEL_PATCHVER LINUX_VERSION:=$(KERNEL_PATCHVER)$(strip $(LINUX_VERSION-$(KERNEL_PATCHVER))) diff --git a/target/linux/brcm63xx/patches-4.4/202-MTD-DEVICES-m25p80-use-parsers-if-provided-in-flash-.patch b/target/linux/brcm63xx/patches-4.4/202-MTD-DEVICES-m25p80-use-parsers-if-provided-in-flash-.patch index be62e67..4793836 100644 --- a/target/linux/brcm63xx/patches-4.4/202-MTD-DEVICES-m25p80-use-parsers-if-provided-in-flash-.patch +++ b/target/linux/brcm63xx/patches-4.4/202-MTD-DEVICES-m25p80-use-parsers-if-provided-in-flash-.patch @@ -11,7 +11,7 @@ Signed-off-by: Jonas Gorski --- a/drivers/mtd/devices/m25p80.c +++ b/drivers/mtd/devices/m25p80.c -@@ -229,7 +229,8 @@ static int m25p_probe(struct spi_device +@@ -251,7 +251,8 @@ static int m25p_probe(struct spi_device ppdata.of_node = spi->dev.of_node; diff --git a/target/linux/brcm63xx/patches-4.4/203-MTD-DEVICES-m25p80-add-support-for-limiting-reads.patch b/target/linux/brcm63xx/patches-4.4/203-MTD-DEVICES-m25p80-add-support-for-limiting-reads.patch index 3877442..75a874d 100644 --- a/target/linux/brcm63xx/patches-4.4/203-MTD-DEVICES-m25p80-add-support-for-limiting-reads.patch +++ b/target/linux/brcm63xx/patches-4.4/203-MTD-DEVICES-m25p80-add-support-for-limiting-reads.patch @@ -28,7 +28,7 @@ Signed-off-by: Jonas Gorski size_t *retlen, u_char *buf) { struct m25p *flash = nor->priv; -@@ -152,6 +153,29 @@ static int m25p80_read(struct spi_nor *n +@@ -174,6 +175,29 @@ static int m25p80_read(struct spi_nor *n return 0; } @@ -58,7 +58,7 @@ Signed-off-by: Jonas Gorski static int m25p80_erase(struct spi_nor *nor, loff_t offset) { struct m25p *flash = nor->priv; -@@ -223,6 +247,9 @@ static int m25p_probe(struct spi_device +@@ -245,6 +269,9 @@ static int m25p_probe(struct spi_device else flash_name = spi->modalias; diff --git a/target/linux/brcm63xx/patches-4.4/414-MTD-m25p80-allow-passing-pp_data.patch b/target/linux/brcm63xx/patches-4.4/414-MTD-m25p80-allow-passing-pp_data.patch index e421e9a..bbb565e 100644 --- a/target/linux/brcm63xx/patches-4.4/414-MTD-m25p80-allow-passing-pp_data.patch +++ b/target/linux/brcm63xx/patches-4.4/414-MTD-m25p80-allow-passing-pp_data.patch @@ -10,7 +10,7 @@ Subject: [PATCH 64/79] MTD: m25p80: allow passing pp_data --- a/drivers/mtd/devices/m25p80.c +++ b/drivers/mtd/devices/m25p80.c -@@ -250,6 +250,9 @@ static int m25p_probe(struct spi_device +@@ -272,6 +272,9 @@ static int m25p_probe(struct spi_device if (data) flash->max_transfer_len = data->max_transfer_len; diff --git a/target/linux/generic/patches-4.4/045-mtd-devices-m25p80-add-support-for-mmap-read-request.patch b/target/linux/generic/patches-4.4/045-mtd-devices-m25p80-add-support-for-mmap-read-request.patch index ee85f44..c4c7e6e 100644 --- a/target/linux/generic/patches-4.4/045-mtd-devices-m25p80-add-support-for-mmap-read-request.patch +++ b/target/linux/generic/patches-4.4/045-mtd-devices-m25p80-add-support-for-mmap-read-request.patch @@ -15,7 +15,7 @@ Signed-off-by: Brian Norris --- a/drivers/mtd/devices/m25p80.c +++ b/drivers/mtd/devices/m25p80.c -@@ -131,6 +131,28 @@ static int m25p80_read(struct spi_nor *nor, loff_t from, size_t len, +@@ -131,6 +131,28 @@ static int m25p80_read(struct spi_nor *n /* convert the dummy cycles to the number of bytes */ dummy /= 8; diff --git a/target/linux/generic/patches-4.4/081-spi-bcm53xx-add-spi_flash_read-callback-for-MMIO-bas.patch b/target/linux/generic/patches-4.4/081-spi-bcm53xx-add-spi_flash_read-callback-for-MMIO-bas.patch index 5f131e7..730f41e 100644 --- a/target/linux/generic/patches-4.4/081-spi-bcm53xx-add-spi_flash_read-callback-for-MMIO-bas.patch +++ b/target/linux/generic/patches-4.4/081-spi-bcm53xx-add-spi_flash_read-callback-for-MMIO-bas.patch @@ -34,7 +34,7 @@ Signed-off-by: Mark Brown }; static inline u32 bcm53xxspi_read(struct bcm53xxspi *b53spi, u16 offset) -@@ -32,6 +35,50 @@ static inline void bcm53xxspi_write(struct bcm53xxspi *b53spi, u16 offset, +@@ -32,6 +35,50 @@ static inline void bcm53xxspi_write(stru bcma_write32(b53spi->core, offset, value); } @@ -85,7 +85,7 @@ Signed-off-by: Mark Brown static inline unsigned int bcm53xxspi_calc_timeout(size_t len) { /* Do some magic calculation based on length and buad. Add 10% and 1. */ -@@ -176,6 +223,8 @@ static int bcm53xxspi_transfer_one(struct spi_master *master, +@@ -176,6 +223,8 @@ static int bcm53xxspi_transfer_one(struc u8 *buf; size_t left; @@ -94,7 +94,7 @@ Signed-off-by: Mark Brown if (t->tx_buf) { buf = (u8 *)t->tx_buf; left = t->len; -@@ -206,6 +255,22 @@ static int bcm53xxspi_transfer_one(struct spi_master *master, +@@ -206,6 +255,22 @@ static int bcm53xxspi_transfer_one(struc return 0; } @@ -117,7 +117,7 @@ Signed-off-by: Mark Brown /************************************************** * BCMA **************************************************/ -@@ -222,6 +287,7 @@ MODULE_DEVICE_TABLE(bcma, bcm53xxspi_bcma_tbl); +@@ -222,6 +287,7 @@ MODULE_DEVICE_TABLE(bcma, bcm53xxspi_bcm static int bcm53xxspi_bcma_probe(struct bcma_device *core) { @@ -125,7 +125,7 @@ Signed-off-by: Mark Brown struct bcm53xxspi *b53spi; struct spi_master *master; int err; -@@ -231,7 +297,7 @@ static int bcm53xxspi_bcma_probe(struct bcma_device *core) +@@ -231,7 +297,7 @@ static int bcm53xxspi_bcma_probe(struct return -ENOTSUPP; } @@ -134,7 +134,7 @@ Signed-off-by: Mark Brown if (!master) return -ENOMEM; -@@ -239,11 +305,19 @@ static int bcm53xxspi_bcma_probe(struct bcma_device *core) +@@ -239,11 +305,19 @@ static int bcm53xxspi_bcma_probe(struct b53spi->master = master; b53spi->core = core; diff --git a/target/linux/generic/patches-4.4/207-mips-vdso-dbg-rebuild-after-genvdso.patch b/target/linux/generic/patches-4.4/207-mips-vdso-dbg-rebuild-after-genvdso.patch index 2a36f2a..cd988a9 100644 --- a/target/linux/generic/patches-4.4/207-mips-vdso-dbg-rebuild-after-genvdso.patch +++ b/target/linux/generic/patches-4.4/207-mips-vdso-dbg-rebuild-after-genvdso.patch @@ -1,7 +1,5 @@ -Index: linux-4.4.9/arch/mips/vdso/Makefile -=================================================================== ---- linux-4.4.9.orig/arch/mips/vdso/Makefile -+++ linux-4.4.9/arch/mips/vdso/Makefile +--- a/arch/mips/vdso/Makefile ++++ b/arch/mips/vdso/Makefile @@ -75,7 +75,7 @@ $(obj-vdso): KBUILD_AFLAGS := $(aflags-v $(obj)/vdso.lds: KBUILD_CPPFLAGS := $(native-abi) @@ -13,10 +11,10 @@ Index: linux-4.4.9/arch/mips/vdso/Makefile $(obj)/vdso-image.c: $(obj)/vdso.so.dbg $(obj)/genvdso FORCE @@ -109,7 +109,7 @@ $(obj)/vdso-o32.lds: KBUILD_CPPFLAGS := $(obj)/vdso-o32.lds: $(src)/vdso.lds.S FORCE - $(call if_changed_dep,cpp_lds_S) - + $(call if_changed_dep,cpp_lds_S) + -$(obj)/vdso-o32.so.dbg: $(obj)/vdso-o32.lds $(obj-vdso-o32) FORCE +$(obj)/vdso-o32.so.dbg: $(obj)/vdso-o32.lds $(obj-vdso-o32) $(obj)/genvdso FORCE - $(call if_changed,vdsold) - + $(call if_changed,vdsold) + $(obj)/vdso-o32-image.c: VDSO_NAME := o32 diff --git a/target/linux/generic/patches-4.4/630-packet_socket_type.patch b/target/linux/generic/patches-4.4/630-packet_socket_type.patch index d649bf0..48c4220 100644 --- a/target/linux/generic/patches-4.4/630-packet_socket_type.patch +++ b/target/linux/generic/patches-4.4/630-packet_socket_type.patch @@ -51,7 +51,7 @@ Signed-off-by: Felix Fietkau goto out; if (!net_eq(dev_net(dev), sock_net(sk))) -@@ -1982,12 +1984,12 @@ static int packet_rcv(struct sk_buff *sk +@@ -1986,12 +1988,12 @@ static int packet_rcv(struct sk_buff *sk int skb_len = skb->len; unsigned int snaplen, res; @@ -67,7 +67,7 @@ Signed-off-by: Felix Fietkau if (!net_eq(dev_net(dev), sock_net(sk))) goto drop; -@@ -2107,12 +2109,12 @@ static int tpacket_rcv(struct sk_buff *s +@@ -2111,12 +2113,12 @@ static int tpacket_rcv(struct sk_buff *s BUILD_BUG_ON(TPACKET_ALIGN(sizeof(*h.h2)) != 32); BUILD_BUG_ON(TPACKET_ALIGN(sizeof(*h.h3)) != 48); @@ -83,7 +83,7 @@ Signed-off-by: Felix Fietkau if (!net_eq(dev_net(dev), sock_net(sk))) goto drop; -@@ -3097,6 +3099,7 @@ static int packet_create(struct net *net +@@ -3092,6 +3094,7 @@ static int packet_create(struct net *net mutex_init(&po->pg_vec_lock); po->rollover = NULL; po->prot_hook.func = packet_rcv; @@ -91,7 +91,7 @@ Signed-off-by: Felix Fietkau if (sock->type == SOCK_PACKET) po->prot_hook.func = packet_rcv_spkt; -@@ -3712,6 +3715,16 @@ packet_setsockopt(struct socket *sock, i +@@ -3707,6 +3710,16 @@ packet_setsockopt(struct socket *sock, i po->xmit = val ? packet_direct_xmit : dev_queue_xmit; return 0; } @@ -108,7 +108,7 @@ Signed-off-by: Felix Fietkau default: return -ENOPROTOOPT; } -@@ -3764,6 +3777,13 @@ static int packet_getsockopt(struct sock +@@ -3759,6 +3772,13 @@ static int packet_getsockopt(struct sock case PACKET_VNET_HDR: val = po->has_vnet_hdr; break; diff --git a/target/linux/generic/patches-4.4/642-bridge_port_isolate.patch b/target/linux/generic/patches-4.4/642-bridge_port_isolate.patch index 0be8c8f..1dc32b6 100644 --- a/target/linux/generic/patches-4.4/642-bridge_port_isolate.patch +++ b/target/linux/generic/patches-4.4/642-bridge_port_isolate.patch @@ -11,8 +11,8 @@ Isolating individual bridge ports #define BR_PROXYARP_WIFI BIT(10) +#define BR_ISOLATE_MODE BIT(11) - /* values as per ieee8021QBridgeFdbAgingTime */ - #define BR_MIN_AGEING_TIME (10 * HZ) + #define BR_DEFAULT_AGEING_TIME (300 * HZ) + --- a/net/bridge/br_sysfs_if.c +++ b/net/bridge/br_sysfs_if.c @@ -173,6 +173,22 @@ BRPORT_ATTR_FLAG(unicast_flood, BR_FLOOD diff --git a/target/linux/generic/patches-4.4/645-bridge_multicast_to_unicast.patch b/target/linux/generic/patches-4.4/645-bridge_multicast_to_unicast.patch index 59aa1ed..f729f38 100644 --- a/target/linux/generic/patches-4.4/645-bridge_multicast_to_unicast.patch +++ b/target/linux/generic/patches-4.4/645-bridge_multicast_to_unicast.patch @@ -11,8 +11,8 @@ Implement optinal multicast->unicast conversion for igmp snooping #define BR_ISOLATE_MODE BIT(11) +#define BR_MULTICAST_TO_UCAST BIT(12) - /* values as per ieee8021QBridgeFdbAgingTime */ - #define BR_MIN_AGEING_TIME (10 * HZ) + #define BR_DEFAULT_AGEING_TIME (300 * HZ) + --- a/net/bridge/br_multicast.c +++ b/net/bridge/br_multicast.c @@ -42,12 +42,13 @@ static void br_multicast_add_router(stru diff --git a/target/linux/generic/patches-4.4/655-increase_skb_pad.patch b/target/linux/generic/patches-4.4/655-increase_skb_pad.patch index e46e470..ad95d4c 100644 --- a/target/linux/generic/patches-4.4/655-increase_skb_pad.patch +++ b/target/linux/generic/patches-4.4/655-increase_skb_pad.patch @@ -1,6 +1,6 @@ --- a/include/linux/skbuff.h +++ b/include/linux/skbuff.h -@@ -2155,7 +2155,7 @@ static inline int pskb_network_may_pull( +@@ -2179,7 +2179,7 @@ static inline int pskb_network_may_pull( * NET_IP_ALIGN(2) + ethernet_header(14) + IP_header(20/40) + ports(8) */ #ifndef NET_SKB_PAD diff --git a/target/linux/generic/patches-4.4/656-skb_reduce_truesize-helper.patch b/target/linux/generic/patches-4.4/656-skb_reduce_truesize-helper.patch index 341a31b..dad7448 100644 --- a/target/linux/generic/patches-4.4/656-skb_reduce_truesize-helper.patch +++ b/target/linux/generic/patches-4.4/656-skb_reduce_truesize-helper.patch @@ -14,7 +14,7 @@ when needed. --- a/include/linux/skbuff.h +++ b/include/linux/skbuff.h -@@ -2200,6 +2200,24 @@ static inline void pskb_trim_unique(stru +@@ -2224,6 +2224,24 @@ static inline void pskb_trim_unique(stru BUG_ON(err); } diff --git a/target/linux/generic/patches-4.4/666-Add-support-for-MAP-E-FMRs-mesh-mode.patch b/target/linux/generic/patches-4.4/666-Add-support-for-MAP-E-FMRs-mesh-mode.patch index d511520..657804a 100644 --- a/target/linux/generic/patches-4.4/666-Add-support-for-MAP-E-FMRs-mesh-mode.patch +++ b/target/linux/generic/patches-4.4/666-Add-support-for-MAP-E-FMRs-mesh-mode.patch @@ -295,15 +295,15 @@ Signed-off-by: Steven Barth __skb_tunnel_rx(skb, t->dev, t->net); -@@ -1179,6 +1316,7 @@ ip4ip6_tnl_xmit(struct sk_buff *skb, str +@@ -1224,6 +1361,7 @@ ip6ip6_tnl_xmit(struct sk_buff *skb, str __u32 mtu; u8 tproto; int err; + struct __ip6_tnl_fmr *fmr; tproto = ACCESS_ONCE(t->parms.proto); - if (tproto != IPPROTO_IPIP && tproto != 0) -@@ -1198,6 +1336,18 @@ ip4ip6_tnl_xmit(struct sk_buff *skb, str + if ((tproto != IPPROTO_IPV6 && tproto != 0) || +@@ -1254,6 +1392,18 @@ ip6ip6_tnl_xmit(struct sk_buff *skb, str if (t->parms.flags & IP6_TNL_F_USE_ORIG_FWMARK) fl6.flowi6_mark = skb->mark; @@ -321,8 +321,8 @@ Signed-off-by: Steven Barth + err = ip6_tnl_xmit2(skb, dev, dsfield, &fl6, encap_limit, &mtu); if (err != 0) { - /* XXX: send ICMP error even if DF is not set. */ -@@ -1366,6 +1516,14 @@ ip6_tnl_change(struct ip6_tnl *t, const + if (err == -EMSGSIZE) +@@ -1368,6 +1518,14 @@ ip6_tnl_change(struct ip6_tnl *t, const t->parms.flowinfo = p->flowinfo; t->parms.link = p->link; t->parms.proto = p->proto; @@ -337,7 +337,7 @@ Signed-off-by: Steven Barth ip6_tnl_dst_reset(t); ip6_tnl_link_config(t); return 0; -@@ -1404,6 +1562,7 @@ ip6_tnl_parm_from_user(struct __ip6_tnl_ +@@ -1406,6 +1564,7 @@ ip6_tnl_parm_from_user(struct __ip6_tnl_ p->flowinfo = u->flowinfo; p->link = u->link; p->proto = u->proto; @@ -345,7 +345,7 @@ Signed-off-by: Steven Barth memcpy(p->name, u->name, sizeof(u->name)); } -@@ -1699,6 +1858,15 @@ static int ip6_tnl_validate(struct nlatt +@@ -1701,6 +1860,15 @@ static int ip6_tnl_validate(struct nlatt return 0; } @@ -361,7 +361,7 @@ Signed-off-by: Steven Barth static void ip6_tnl_netlink_parms(struct nlattr *data[], struct __ip6_tnl_parm *parms) { -@@ -1730,6 +1898,46 @@ static void ip6_tnl_netlink_parms(struct +@@ -1732,6 +1900,46 @@ static void ip6_tnl_netlink_parms(struct if (data[IFLA_IPTUN_PROTO]) parms->proto = nla_get_u8(data[IFLA_IPTUN_PROTO]); @@ -408,7 +408,7 @@ Signed-off-by: Steven Barth } static int ip6_tnl_newlink(struct net *src_net, struct net_device *dev, -@@ -1782,6 +1990,12 @@ static void ip6_tnl_dellink(struct net_d +@@ -1784,6 +1992,12 @@ static void ip6_tnl_dellink(struct net_d static size_t ip6_tnl_get_size(const struct net_device *dev) { @@ -421,7 +421,7 @@ Signed-off-by: Steven Barth return /* IFLA_IPTUN_LINK */ nla_total_size(4) + -@@ -1799,6 +2013,24 @@ static size_t ip6_tnl_get_size(const str +@@ -1801,6 +2015,24 @@ static size_t ip6_tnl_get_size(const str nla_total_size(4) + /* IFLA_IPTUN_PROTO */ nla_total_size(1) + @@ -446,7 +446,7 @@ Signed-off-by: Steven Barth 0; } -@@ -1806,6 +2038,9 @@ static int ip6_tnl_fill_info(struct sk_b +@@ -1808,6 +2040,9 @@ static int ip6_tnl_fill_info(struct sk_b { struct ip6_tnl *tunnel = netdev_priv(dev); struct __ip6_tnl_parm *parm = &tunnel->parms; @@ -456,7 +456,7 @@ Signed-off-by: Steven Barth if (nla_put_u32(skb, IFLA_IPTUN_LINK, parm->link) || nla_put_in6_addr(skb, IFLA_IPTUN_LOCAL, &parm->laddr) || -@@ -1814,8 +2049,27 @@ static int ip6_tnl_fill_info(struct sk_b +@@ -1816,8 +2051,27 @@ static int ip6_tnl_fill_info(struct sk_b nla_put_u8(skb, IFLA_IPTUN_ENCAP_LIMIT, parm->encap_limit) || nla_put_be32(skb, IFLA_IPTUN_FLOWINFO, parm->flowinfo) || nla_put_u32(skb, IFLA_IPTUN_FLAGS, parm->flags) || @@ -485,7 +485,7 @@ Signed-off-by: Steven Barth return 0; nla_put_failure: -@@ -1839,6 +2093,7 @@ static const struct nla_policy ip6_tnl_p +@@ -1841,6 +2095,7 @@ static const struct nla_policy ip6_tnl_p [IFLA_IPTUN_FLOWINFO] = { .type = NLA_U32 }, [IFLA_IPTUN_FLAGS] = { .type = NLA_U32 }, [IFLA_IPTUN_PROTO] = { .type = NLA_U8 }, diff --git a/target/linux/generic/patches-4.4/721-phy_packets.patch b/target/linux/generic/patches-4.4/721-phy_packets.patch index 04bafcd..79af5f9 100644 --- a/target/linux/generic/patches-4.4/721-phy_packets.patch +++ b/target/linux/generic/patches-4.4/721-phy_packets.patch @@ -1,6 +1,6 @@ --- a/include/linux/netdevice.h +++ b/include/linux/netdevice.h -@@ -1297,6 +1297,7 @@ enum netdev_priv_flags { +@@ -1298,6 +1298,7 @@ enum netdev_priv_flags { IFF_NO_QUEUE = 1<<21, IFF_OPENVSWITCH = 1<<22, IFF_L3MDEV_SLAVE = 1<<23, @@ -8,7 +8,7 @@ }; #define IFF_802_1Q_VLAN IFF_802_1Q_VLAN -@@ -1323,6 +1324,7 @@ enum netdev_priv_flags { +@@ -1324,6 +1325,7 @@ enum netdev_priv_flags { #define IFF_NO_QUEUE IFF_NO_QUEUE #define IFF_OPENVSWITCH IFF_OPENVSWITCH #define IFF_L3MDEV_SLAVE IFF_L3MDEV_SLAVE @@ -41,7 +41,7 @@ */ --- a/include/linux/skbuff.h +++ b/include/linux/skbuff.h -@@ -2186,6 +2186,10 @@ static inline int pskb_trim(struct sk_bu +@@ -2210,6 +2210,10 @@ static inline int pskb_trim(struct sk_bu return (len < skb->len) ? __pskb_trim(skb, len) : 0; } @@ -52,7 +52,7 @@ /** * pskb_trim_unique - remove end from a paged unique (not cloned) buffer * @skb: buffer to alter -@@ -2308,16 +2312,6 @@ static inline struct sk_buff *dev_alloc_ +@@ -2332,16 +2336,6 @@ static inline struct sk_buff *dev_alloc_ } diff --git a/target/linux/generic/patches-4.4/903-debloat_direct_io.patch b/target/linux/generic/patches-4.4/903-debloat_direct_io.patch index ee85c40..460da1d 100644 --- a/target/linux/generic/patches-4.4/903-debloat_direct_io.patch +++ b/target/linux/generic/patches-4.4/903-debloat_direct_io.patch @@ -26,7 +26,7 @@ endif --- a/include/linux/fs.h +++ b/include/linux/fs.h -@@ -2681,6 +2681,7 @@ enum { +@@ -2691,6 +2691,7 @@ enum { DIO_SKIP_DIO_COUNT = 0x08, }; @@ -34,7 +34,7 @@ void dio_end_io(struct bio *bio, int error); ssize_t __blockdev_direct_IO(struct kiocb *iocb, struct inode *inode, -@@ -2688,6 +2689,18 @@ ssize_t __blockdev_direct_IO(struct kioc +@@ -2698,6 +2699,18 @@ ssize_t __blockdev_direct_IO(struct kioc loff_t offset, get_block_t get_block, dio_iodone_t end_io, dio_submit_t submit_io, int flags); _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From michal.hrusecky at nic.cz Thu May 12 08:07:15 2016 From: michal.hrusecky at nic.cz (Michal Hrusecky) Date: Thu, 12 May 2016 14:07:15 +0200 Subject: [OpenWrt-Devel] [PATCH] [package] hostapd: Update to the latest snapshot Message-ID: <20160512120715.GC5775@workbook.ipv6.hrusecky.net> Fixes CVE-2016-4476 and few possible memory leaks. Signed-off-by: Michal Hrusecky --- package/network/services/hostapd/Makefile | 6 +- .../services/hostapd/patches/200-multicall.patch | 116 +++++++++++++++------ .../hostapd/patches/370-ap_sta_support.patch | 22 ++-- .../patches/380-disable_ctrl_iface_mib.patch | 38 +++---- .../hostapd/patches/420-indicate-features.patch | 12 +-- .../services/hostapd/patches/450-scan_wait.patch | 19 ++-- .../hostapd/patches/600-ubus_support.patch | 58 +++++------ .../hostapd/patches/700-make-make-work.patch | 12 +++ 8 files changed, 180 insertions(+), 103 deletions(-) create mode 100644 package/network/services/hostapd/patches/700-make-make-work.patch diff --git a/package/network/services/hostapd/Makefile b/package/network/services/hostapd/Makefile index dba29dd..2465f6b 100644 --- a/package/network/services/hostapd/Makefile +++ b/package/network/services/hostapd/Makefile @@ -7,9 +7,9 @@ include $(TOPDIR)/rules.mk PKG_NAME:=hostapd -PKG_VERSION:=2016-01-15 -PKG_RELEASE:=2 -PKG_REV:=e15dcf6d1bc2725388555523effca75b1ffab735 +PKG_VERSION:=2016-05-05 +PKG_RELEASE:=1 +PKG_REV:=9524e7e5a4a18539f0fb532544d2de63621b5f8b PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2 PKG_SOURCE_URL:=git://w1.fi/srv/git/hostap.git diff --git a/package/network/services/hostapd/patches/200-multicall.patch b/package/network/services/hostapd/patches/200-multicall.patch index 08f1e95..49e7af7 100644 --- a/package/network/services/hostapd/patches/200-multicall.patch +++ b/package/network/services/hostapd/patches/200-multicall.patch @@ -1,15 +1,15 @@ --- a/hostapd/Makefile +++ b/hostapd/Makefile -@@ -32,6 +32,7 @@ export BINDIR ?= /usr/local/bin/ - # CFLAGS += -DUSE_KERNEL_HEADERS -I/usr/src/linux/include +@@ -28,6 +28,7 @@ CFLAGS += -I$(abspath ../src/utils) + export BINDIR ?= /usr/local/bin/ -include .config +-include $(if $(MULTICALL), ../wpa_supplicant/.config) ifndef CONFIG_NO_GITVER # Add VERSION_STR postfix for builds from a git repository -@@ -277,10 +278,14 @@ ifdef CONFIG_IEEE80211AC - CFLAGS += -DCONFIG_IEEE80211AC +@@ -315,10 +316,14 @@ CFLAGS += -DCONFIG_MBO + OBJS += ../src/ap/mbo_ap.o endif +ifndef MULTICALL @@ -26,7 +26,7 @@ LIBS += $(DRV_AP_LIBS) ifdef CONFIG_L2_PACKET -@@ -1019,6 +1024,12 @@ install: $(addprefix $(DESTDIR)$(BINDIR) +@@ -1051,6 +1056,12 @@ install: $(addprefix $(DESTDIR)$(BINDIR) BCHECK=../src/drivers/build.hostapd @@ -39,7 +39,7 @@ hostapd: $(BCHECK) $(OBJS) $(Q)$(CC) $(LDFLAGS) -o hostapd $(OBJS) $(LIBS) @$(E) " LD " $@ -@@ -1060,6 +1071,12 @@ HOBJS += ../src/crypto/aes-internal.o +@@ -1092,6 +1103,12 @@ HOBJS += ../src/crypto/aes-internal.o HOBJS += ../src/crypto/aes-internal-enc.o endif @@ -62,7 +62,7 @@ ifndef CONFIG_NO_GITVER # Add VERSION_STR postfix for builds from a git repository -@@ -794,6 +795,10 @@ ifdef CONFIG_DYNAMIC_EAP_METHODS +@@ -803,6 +804,10 @@ ifdef CONFIG_DYNAMIC_EAP_METHODS CFLAGS += -DCONFIG_DYNAMIC_EAP_METHODS LIBS += -ldl -rdynamic endif @@ -73,7 +73,7 @@ endif ifdef CONFIG_MACSEC -@@ -814,9 +819,11 @@ NEED_EAP_COMMON=y +@@ -823,9 +828,11 @@ NEED_EAP_COMMON=y NEED_RSN_AUTHENTICATOR=y CFLAGS += -DCONFIG_AP OBJS += ap.o @@ -85,7 +85,7 @@ OBJS += ../src/ap/hostapd.o OBJS += ../src/ap/wpa_auth_glue.o OBJS += ../src/ap/utils.o -@@ -879,10 +886,18 @@ endif +@@ -898,10 +905,18 @@ endif ifdef CONFIG_HS20 OBJS += ../src/ap/hs20.o endif @@ -104,7 +104,7 @@ NEED_AES_WRAP=y OBJS += ../src/ap/wpa_auth.o OBJS += ../src/ap/wpa_auth_ie.o -@@ -1657,6 +1672,12 @@ wpa_priv: $(BCHECK) $(OBJS_priv) +@@ -1680,6 +1695,12 @@ wpa_priv: $(BCHECK) $(OBJS_priv) $(OBJS_c) $(OBJS_t) $(OBJS_t2) $(OBJS) $(BCHECK) $(EXTRA_progs): .config @@ -117,8 +117,8 @@ wpa_supplicant: $(BCHECK) $(OBJS) $(EXTRA_progs) $(Q)$(LDO) $(LDFLAGS) -o wpa_supplicant $(OBJS) $(LIBS) $(EXTRALIBS) @$(E) " LD " $@ -@@ -1757,6 +1778,12 @@ endif - $(Q)sed -e 's|\@BINDIR\@|$(BINDIR)|g' $< >$@ +@@ -1782,6 +1803,12 @@ endif + -e 's|\@DBUS_INTERFACE\@|$(DBUS_INTERFACE)|g' $< >$@ @$(E) " sed" $< +dump_cflags: @@ -132,7 +132,7 @@ wpa_cli.exe: wpa_cli --- a/src/drivers/driver.h +++ b/src/drivers/driver.h -@@ -4707,8 +4707,8 @@ union wpa_event_data { +@@ -4775,8 +4775,8 @@ union wpa_event_data { * Driver wrapper code should call this function whenever an event is received * from the driver. */ @@ -141,11 +141,20 @@ +extern void (*wpa_supplicant_event)(void *ctx, enum wpa_event_type event, + union wpa_event_data *data); + /** + * wpa_supplicant_event_global - Report a driver event for wpa_supplicant +@@ -4788,7 +4788,7 @@ void wpa_supplicant_event(void *ctx, enu + * Same as wpa_supplicant_event(), but we search for the interface in + * wpa_global. + */ +-void wpa_supplicant_event_global(void *ctx, enum wpa_event_type event, ++extern void (*wpa_supplicant_event_global)(void *ctx, enum wpa_event_type event, + union wpa_event_data *data); /* --- a/src/ap/drv_callbacks.c +++ b/src/ap/drv_callbacks.c -@@ -1122,8 +1122,8 @@ static void hostapd_event_dfs_cac_starte +@@ -1144,8 +1144,8 @@ static void hostapd_event_dfs_cac_starte #endif /* NEED_AP_MLME */ @@ -156,9 +165,18 @@ { struct hostapd_data *hapd = ctx; #ifndef CONFIG_NO_STDOUT_DEBUG +@@ -1354,7 +1354,7 @@ void wpa_supplicant_event(void *ctx, enu + } + + +-void wpa_supplicant_event_global(void *ctx, enum wpa_event_type event, ++void hostapd_wpa_event_global(void *ctx, enum wpa_event_type event, + union wpa_event_data *data) + { + struct hapd_interfaces *interfaces = ctx; --- a/wpa_supplicant/wpa_priv.c +++ b/wpa_supplicant/wpa_priv.c -@@ -932,8 +932,8 @@ static void wpa_priv_send_ft_response(st +@@ -940,8 +940,8 @@ static void wpa_priv_send_ft_response(st } @@ -169,17 +187,27 @@ { struct wpa_priv_interface *iface = ctx; -@@ -1082,6 +1082,7 @@ int main(int argc, char *argv[]) +@@ -1010,7 +1010,7 @@ void wpa_supplicant_event(void *ctx, enu + } + + +-void wpa_supplicant_event_global(void *ctx, enum wpa_event_type event, ++void supplicant_event_global(void *ctx, enum wpa_event_type event, + union wpa_event_data *data) + { + struct wpa_priv_global *global = ctx; +@@ -1122,6 +1122,8 @@ int main(int argc, char *argv[]) if (os_program_init()) return -1; + wpa_supplicant_event = supplicant_event; ++ wpa_supplicant_event_global = supplicant_event_global; wpa_priv_fd_workaround(); - for (;;) { + os_memset(&global, 0, sizeof(global)); --- a/wpa_supplicant/events.c +++ b/wpa_supplicant/events.c -@@ -3298,8 +3298,8 @@ static void wpa_supplicant_event_assoc_a +@@ -3375,8 +3375,8 @@ static void wpa_supplicant_event_assoc_a } @@ -190,7 +218,7 @@ { struct wpa_supplicant *wpa_s = ctx; int resched; -@@ -3947,7 +3947,7 @@ void wpa_supplicant_event(void *ctx, enu +@@ -4037,7 +4037,7 @@ void wpa_supplicant_event(void *ctx, enu #endif /* CONFIG_AP */ break; case EVENT_ACS_CHANNEL_SELECTED: @@ -199,61 +227,86 @@ if (!wpa_s->ap_iface) break; hostapd_acs_channel_selected(wpa_s->ap_iface->bss[0], +@@ -4051,7 +4051,7 @@ void wpa_supplicant_event(void *ctx, enu + } + + +-void wpa_supplicant_event_global(void *ctx, enum wpa_event_type event, ++void supplicant_event_global(void *ctx, enum wpa_event_type event, + union wpa_event_data *data) + { + struct wpa_supplicant *wpa_s; --- a/wpa_supplicant/wpa_supplicant.c +++ b/wpa_supplicant/wpa_supplicant.c -@@ -4845,6 +4845,9 @@ static void wpa_supplicant_deinit_iface( - os_free(wpa_s); +@@ -4967,7 +4967,6 @@ struct wpa_interface * wpa_supplicant_ma + return NULL; } +- + /** + * wpa_supplicant_match_existing - Match existing interfaces + * @global: Pointer to global data from wpa_supplicant_init() +@@ -5004,6 +5003,11 @@ static int wpa_supplicant_match_existing + + #endif /* CONFIG_MATCH_IFACE */ + +extern void supplicant_event(void *ctx, enum wpa_event_type event, + union wpa_event_data *data); + ++extern void supplicant_event_global(void *ctx, enum wpa_event_type event, ++ union wpa_event_data *data); /** * wpa_supplicant_add_iface - Add a new network interface -@@ -5100,6 +5103,7 @@ struct wpa_global * wpa_supplicant_init( +@@ -5259,6 +5263,8 @@ struct wpa_global * wpa_supplicant_init( #ifndef CONFIG_NO_WPA_MSG wpa_msg_register_ifname_cb(wpa_supplicant_msg_ifname_cb); #endif /* CONFIG_NO_WPA_MSG */ + wpa_supplicant_event = supplicant_event; ++ wpa_supplicant_event_global = supplicant_event_global; if (params->wpa_debug_file_path) wpa_debug_open_file(params->wpa_debug_file_path); --- a/hostapd/main.c +++ b/hostapd/main.c -@@ -513,6 +513,9 @@ static int hostapd_get_ctrl_iface_group( +@@ -526,6 +526,11 @@ static int hostapd_get_ctrl_iface_group( return 0; } +void hostapd_wpa_event(void *ctx, enum wpa_event_type event, + union wpa_event_data *data); + ++void hostapd_wpa_event_global(void *ctx, enum wpa_event_type event, ++ union wpa_event_data *data); #ifdef CONFIG_WPS static int gen_uuid(const char *txt_addr) -@@ -588,6 +591,7 @@ int main(int argc, char *argv[]) +@@ -601,6 +606,8 @@ int main(int argc, char *argv[]) interfaces.global_ctrl_sock = -1; - interfaces.global_ctrl_dst = NULL; + dl_list_init(&interfaces.global_ctrl_dst); + wpa_supplicant_event = hostapd_wpa_event; ++ wpa_supplicant_event_global = hostapd_wpa_event_global; for (;;) { c = getopt(argc, argv, "b:Bde:f:hKP:STtu:vg:G:"); if (c < 0) --- a/src/drivers/drivers.c +++ b/src/drivers/drivers.c -@@ -10,6 +10,9 @@ +@@ -10,6 +10,11 @@ #include "utils/common.h" #include "driver.h" +void (*wpa_supplicant_event)(void *ctx, enum wpa_event_type event, + union wpa_event_data *data); ++void (*wpa_supplicant_event_global)(void *ctx, enum wpa_event_type event, ++ union wpa_event_data *data); + #ifdef CONFIG_DRIVER_WEXT extern struct wpa_driver_ops wpa_driver_wext_ops; /* driver_wext.c */ #endif /* CONFIG_DRIVER_WEXT */ --- a/wpa_supplicant/eapol_test.c +++ b/wpa_supplicant/eapol_test.c -@@ -29,7 +29,10 @@ +@@ -29,7 +29,12 @@ #include "ctrl_iface.h" #include "pcsc_funcs.h" #include "wpas_glue.h" @@ -261,23 +314,28 @@ +void (*wpa_supplicant_event)(void *ctx, enum wpa_event_type event, + union wpa_event_data *data); ++void (*wpa_supplicant_event_global)(void *ctx, enum wpa_event_type event, ++ union wpa_event_data *data); const struct wpa_driver_ops *const wpa_drivers[] = { NULL }; -@@ -1288,6 +1291,8 @@ static void usage(void) +@@ -1295,6 +1300,10 @@ static void usage(void) "option several times.\n"); } +extern void supplicant_event(void *ctx, enum wpa_event_type event, + union wpa_event_data *data); ++extern void supplicant_event_global(void *ctx, enum wpa_event_type event, ++ union wpa_event_data *data); int main(int argc, char *argv[]) { -@@ -1308,6 +1313,7 @@ int main(int argc, char *argv[]) +@@ -1315,6 +1324,8 @@ int main(int argc, char *argv[]) if (os_program_init()) return -1; + wpa_supplicant_event = supplicant_event; ++ wpa_supplicant_event_global = supplicant_event_global; hostapd_logger_register_cb(hostapd_logger_cb); os_memset(&eapol_test, 0, sizeof(eapol_test)); diff --git a/package/network/services/hostapd/patches/370-ap_sta_support.patch b/package/network/services/hostapd/patches/370-ap_sta_support.patch index 716916a..04c52a2 100644 --- a/package/network/services/hostapd/patches/370-ap_sta_support.patch +++ b/package/network/services/hostapd/patches/370-ap_sta_support.patch @@ -1,6 +1,6 @@ --- a/wpa_supplicant/wpa_supplicant_i.h +++ b/wpa_supplicant/wpa_supplicant_i.h -@@ -99,6 +99,11 @@ struct wpa_interface { +@@ -100,6 +100,11 @@ struct wpa_interface { const char *ifname; /** @@ -12,8 +12,8 @@ * bridge_ifname - Optional bridge interface name * * If the driver interface (ifname) is included in a Linux bridge -@@ -465,6 +470,8 @@ struct wpa_supplicant { - #endif /* CONFIG_CTRL_IFACE_DBUS_NEW */ +@@ -484,6 +489,8 @@ struct wpa_supplicant { + #endif /* CONFIG_CTRL_IFACE_BINDER */ char bridge_ifname[16]; + struct wpa_ctrl *hostapd; @@ -45,7 +45,7 @@ CONFIG_OS=win32 --- a/wpa_supplicant/wpa_supplicant.c +++ b/wpa_supplicant/wpa_supplicant.c -@@ -108,6 +108,55 @@ const char *const wpa_supplicant_full_li +@@ -112,6 +112,55 @@ const char *const wpa_supplicant_full_li "\n"; #endif /* CONFIG_NO_STDOUT_DEBUG */ @@ -101,7 +101,7 @@ /* Configure default/group WEP keys for static WEP */ int wpa_set_wep_keys(struct wpa_supplicant *wpa_s, struct wpa_ssid *ssid) { -@@ -783,8 +832,12 @@ void wpa_supplicant_set_state(struct wpa +@@ -812,8 +861,12 @@ void wpa_supplicant_set_state(struct wpa wpas_p2p_completed(wpa_s); sme_sched_obss_scan(wpa_s, 1); @@ -114,7 +114,7 @@ wpa_s->new_connection = 1; wpa_drv_set_operstate(wpa_s, 0); #ifndef IEEE8021X_EAPOL -@@ -4537,6 +4590,20 @@ static int wpa_supplicant_init_iface(str +@@ -4623,6 +4676,20 @@ static int wpa_supplicant_init_iface(str sizeof(wpa_s->bridge_ifname)); } @@ -135,7 +135,7 @@ /* RSNA Supplicant Key Management - INITIALIZE */ eapol_sm_notify_portEnabled(wpa_s->eapol, FALSE); eapol_sm_notify_portValid(wpa_s->eapol, FALSE); -@@ -4823,6 +4890,11 @@ static void wpa_supplicant_deinit_iface( +@@ -4914,6 +4981,11 @@ static void wpa_supplicant_deinit_iface( if (terminate) wpa_msg(wpa_s, MSG_INFO, WPA_EVENT_TERMINATING); @@ -203,16 +203,16 @@ " -i = interface name\n" " -I = additional configuration file\n" " -K = include keys (passwords, etc.) in debug output\n" -@@ -176,7 +177,7 @@ int main(int argc, char *argv[]) +@@ -201,7 +202,7 @@ int main(int argc, char *argv[]) for (;;) { c = getopt(argc, argv, -- "b:Bc:C:D:de:f:g:G:hi:I:KLm:No:O:p:P:qsTtuvW"); -+ "b:Bc:C:D:de:f:g:G:hH:i:I:KLm:No:O:p:P:qsTtuvW"); +- "b:Bc:C:D:de:f:g:G:hi:I:KLMm:No:O:p:P:qsTtuvW"); ++ "b:Bc:C:D:de:f:g:G:hH:i:I:KLMm:No:O:p:P:qsTtuvW"); if (c < 0) break; switch (c) { -@@ -223,6 +224,9 @@ int main(int argc, char *argv[]) +@@ -248,6 +249,9 @@ int main(int argc, char *argv[]) usage(); exitcode = 0; goto out; diff --git a/package/network/services/hostapd/patches/380-disable_ctrl_iface_mib.patch b/package/network/services/hostapd/patches/380-disable_ctrl_iface_mib.patch index 1e1aa20..282577e 100644 --- a/package/network/services/hostapd/patches/380-disable_ctrl_iface_mib.patch +++ b/package/network/services/hostapd/patches/380-disable_ctrl_iface_mib.patch @@ -1,18 +1,18 @@ --- a/hostapd/Makefile +++ b/hostapd/Makefile -@@ -202,6 +202,9 @@ endif +@@ -211,6 +211,9 @@ endif ifdef CONFIG_NO_CTRL_IFACE CFLAGS += -DCONFIG_NO_CTRL_IFACE else +ifdef CONFIG_CTRL_IFACE_MIB +CFLAGS += -DCONFIG_CTRL_IFACE_MIB +endif - OBJS += ctrl_iface.o - OBJS += ../src/ap/ctrl_iface_ap.o - endif + ifeq ($(CONFIG_CTRL_IFACE), udp) + CFLAGS += -DCONFIG_CTRL_IFACE_UDP + else --- a/hostapd/ctrl_iface.c +++ b/hostapd/ctrl_iface.c -@@ -2119,6 +2119,7 @@ static int hostapd_ctrl_iface_receive_pr +@@ -2342,6 +2342,7 @@ static int hostapd_ctrl_iface_receive_pr reply_size); } else if (os_strcmp(buf, "STATUS-DRIVER") == 0) { reply_len = hostapd_drv_status(hapd, reply, reply_size); @@ -20,7 +20,7 @@ } else if (os_strcmp(buf, "MIB") == 0) { reply_len = ieee802_11_get_mib(hapd, reply, reply_size); if (reply_len >= 0) { -@@ -2160,6 +2161,7 @@ static int hostapd_ctrl_iface_receive_pr +@@ -2383,6 +2384,7 @@ static int hostapd_ctrl_iface_receive_pr } else if (os_strncmp(buf, "STA-NEXT ", 9) == 0) { reply_len = hostapd_ctrl_iface_sta_next(hapd, buf + 9, reply, reply_size); @@ -30,8 +30,8 @@ reply_len = -1; --- a/wpa_supplicant/Makefile +++ b/wpa_supplicant/Makefile -@@ -858,6 +858,9 @@ ifdef CONFIG_WNM - OBJS += ../src/ap/wnm_ap.o +@@ -872,6 +872,9 @@ ifdef CONFIG_MBO + OBJS += ../src/ap/mbo_ap.o endif ifdef CONFIG_CTRL_IFACE +ifdef CONFIG_CTRL_IFACE_MIB @@ -42,7 +42,7 @@ --- a/wpa_supplicant/ctrl_iface.c +++ b/wpa_supplicant/ctrl_iface.c -@@ -1858,7 +1858,7 @@ static int wpa_supplicant_ctrl_iface_sta +@@ -1895,7 +1895,7 @@ static int wpa_supplicant_ctrl_iface_sta pos += ret; } @@ -51,7 +51,7 @@ if (wpa_s->ap_iface) { pos += ap_ctrl_iface_wpa_get_status(wpa_s, pos, end - pos, -@@ -8352,6 +8352,7 @@ char * wpa_supplicant_ctrl_iface_process +@@ -8610,6 +8610,7 @@ char * wpa_supplicant_ctrl_iface_process reply_len = -1; } else if (os_strncmp(buf, "NOTE ", 5) == 0) { wpa_printf(MSG_INFO, "NOTE: %s", buf + 5); @@ -59,7 +59,7 @@ } else if (os_strcmp(buf, "MIB") == 0) { reply_len = wpa_sm_get_mib(wpa_s->wpa, reply, reply_size); if (reply_len >= 0) { -@@ -8359,6 +8360,7 @@ char * wpa_supplicant_ctrl_iface_process +@@ -8617,6 +8618,7 @@ char * wpa_supplicant_ctrl_iface_process reply + reply_len, reply_size - reply_len); } @@ -67,7 +67,7 @@ } else if (os_strncmp(buf, "STATUS", 6) == 0) { reply_len = wpa_supplicant_ctrl_iface_status( wpa_s, buf + 6, reply, reply_size); -@@ -8821,6 +8823,7 @@ char * wpa_supplicant_ctrl_iface_process +@@ -9087,6 +9089,7 @@ char * wpa_supplicant_ctrl_iface_process reply_len = wpa_supplicant_ctrl_iface_bss( wpa_s, buf + 4, reply, reply_size); #ifdef CONFIG_AP @@ -75,7 +75,7 @@ } else if (os_strcmp(buf, "STA-FIRST") == 0) { reply_len = ap_ctrl_iface_sta_first(wpa_s, reply, reply_size); } else if (os_strncmp(buf, "STA ", 4) == 0) { -@@ -8829,12 +8832,15 @@ char * wpa_supplicant_ctrl_iface_process +@@ -9095,12 +9098,15 @@ char * wpa_supplicant_ctrl_iface_process } else if (os_strncmp(buf, "STA-NEXT ", 9) == 0) { reply_len = ap_ctrl_iface_sta_next(wpa_s, buf + 9, reply, reply_size); @@ -93,15 +93,15 @@ reply_len = -1; --- a/src/ap/ctrl_iface_ap.c +++ b/src/ap/ctrl_iface_ap.c -@@ -23,6 +23,7 @@ - #include "ctrl_iface_ap.h" +@@ -24,6 +24,7 @@ #include "ap_drv_ops.h" + #include "mbo_ap.h" +#ifdef CONFIG_CTRL_IFACE_MIB static int hostapd_get_sta_tx_rx(struct hostapd_data *hapd, struct sta_info *sta, -@@ -235,6 +236,7 @@ int hostapd_ctrl_iface_sta_next(struct h +@@ -249,6 +250,7 @@ int hostapd_ctrl_iface_sta_next(struct h return hostapd_ctrl_iface_sta_mib(hapd, sta->next, buf, buflen); } @@ -111,7 +111,7 @@ static int p2p_manager_disconnect(struct hostapd_data *hapd, u16 stype, --- a/src/ap/ieee802_1x.c +++ b/src/ap/ieee802_1x.c -@@ -2359,6 +2359,7 @@ static const char * bool_txt(Boolean val +@@ -2441,6 +2441,7 @@ static const char * bool_txt(Boolean val return val ? "TRUE" : "FALSE"; } @@ -119,7 +119,7 @@ int ieee802_1x_get_mib(struct hostapd_data *hapd, char *buf, size_t buflen) { -@@ -2534,6 +2535,7 @@ int ieee802_1x_get_mib_sta(struct hostap +@@ -2616,6 +2617,7 @@ int ieee802_1x_get_mib_sta(struct hostap return len; } @@ -167,7 +167,7 @@ --- a/wpa_supplicant/ap.c +++ b/wpa_supplicant/ap.c -@@ -1091,7 +1091,7 @@ int wpas_ap_wps_nfc_report_handover(stru +@@ -1103,7 +1103,7 @@ int wpas_ap_wps_nfc_report_handover(stru #endif /* CONFIG_WPS */ diff --git a/package/network/services/hostapd/patches/420-indicate-features.patch b/package/network/services/hostapd/patches/420-indicate-features.patch index 234537a..f2dff78 100644 --- a/package/network/services/hostapd/patches/420-indicate-features.patch +++ b/package/network/services/hostapd/patches/420-indicate-features.patch @@ -8,7 +8,7 @@ #include "crypto/random.h" #include "crypto/tls.h" #include "common/version.h" -@@ -593,7 +594,7 @@ int main(int argc, char *argv[]) +@@ -606,7 +607,7 @@ int main(int argc, char *argv[]) wpa_supplicant_event = hostapd_wpa_event; for (;;) { @@ -17,7 +17,7 @@ if (c < 0) break; switch (c) { -@@ -630,6 +631,8 @@ int main(int argc, char *argv[]) +@@ -643,6 +644,8 @@ int main(int argc, char *argv[]) break; #endif /* CONFIG_DEBUG_LINUX_TRACING */ case 'v': @@ -36,16 +36,16 @@ #include "fst/fst.h" #include "wpa_supplicant_i.h" #include "driver_i.h" -@@ -177,7 +178,7 @@ int main(int argc, char *argv[]) +@@ -202,7 +203,7 @@ int main(int argc, char *argv[]) for (;;) { c = getopt(argc, argv, -- "b:Bc:C:D:de:f:g:G:hH:i:I:KLm:No:O:p:P:qsTtuvW"); -+ "b:Bc:C:D:de:f:g:G:hH:i:I:KLm:No:O:p:P:qsTtuv::W"); +- "b:Bc:C:D:de:f:g:G:hH:i:I:KLMm:No:O:p:P:qsTtuvW"); ++ "b:Bc:C:D:de:f:g:G:hH:i:I:KLMm:No:O:p:P:qsTtuv::W"); if (c < 0) break; switch (c) { -@@ -280,8 +281,12 @@ int main(int argc, char *argv[]) +@@ -305,8 +306,12 @@ int main(int argc, char *argv[]) break; #endif /* CONFIG_DBUS */ case 'v': diff --git a/package/network/services/hostapd/patches/450-scan_wait.patch b/package/network/services/hostapd/patches/450-scan_wait.patch index 192006a..3a787e3 100644 --- a/package/network/services/hostapd/patches/450-scan_wait.patch +++ b/package/network/services/hostapd/patches/450-scan_wait.patch @@ -33,7 +33,7 @@ /* Initialize the driver interface */ if (!(b[0] | b[1] | b[2] | b[3] | b[4] | b[5])) b = NULL; -@@ -382,8 +394,6 @@ static void hostapd_global_deinit(const +@@ -383,8 +395,6 @@ static void hostapd_global_deinit(const #endif /* CONFIG_NATIVE_WINDOWS */ eap_server_unregister_methods(); @@ -42,19 +42,26 @@ } -@@ -409,11 +419,6 @@ static int hostapd_global_run(struct hap +@@ -410,18 +420,6 @@ static int hostapd_global_run(struct hap } #endif /* EAP_SERVER_TNC */ -- if (daemonize && os_daemonize(pid_file)) { -- wpa_printf(MSG_ERROR, "daemon: %s", strerror(errno)); -- return -1; +- if (daemonize) { +- if (os_daemonize(pid_file)) { +- wpa_printf(MSG_ERROR, "daemon: %s", strerror(errno)); +- return -1; +- } +- if (eloop_sock_requeue()) { +- wpa_printf(MSG_ERROR, "eloop_sock_requeue: %s", +- strerror(errno)); +- return -1; +- } - } - eloop_run(); return 0; -@@ -566,8 +571,7 @@ int main(int argc, char *argv[]) +@@ -579,8 +577,7 @@ int main(int argc, char *argv[]) struct hapd_interfaces interfaces; int ret = 1; size_t i, j; diff --git a/package/network/services/hostapd/patches/600-ubus_support.patch b/package/network/services/hostapd/patches/600-ubus_support.patch index 0a61aef..081b958 100644 --- a/package/network/services/hostapd/patches/600-ubus_support.patch +++ b/package/network/services/hostapd/patches/600-ubus_support.patch @@ -1,6 +1,6 @@ --- a/hostapd/Makefile +++ b/hostapd/Makefile -@@ -155,6 +155,11 @@ OBJS += ../src/common/hw_features_common +@@ -157,6 +157,11 @@ OBJS += ../src/common/hw_features_common OBJS += ../src/eapol_auth/eapol_auth_sm.o @@ -22,7 +22,7 @@ struct wpa_ctrl_dst; struct radius_server_data; -@@ -107,6 +108,7 @@ struct hostapd_data { +@@ -117,6 +118,7 @@ struct hostapd_data { struct hostapd_iface *iface; struct hostapd_config *iconf; struct hostapd_bss_config *conf; @@ -30,7 +30,7 @@ int interface_added; /* virtual interface added for this BSS */ unsigned int started:1; unsigned int disabled:1; -@@ -299,6 +301,8 @@ struct hostapd_iface { +@@ -322,6 +324,8 @@ struct hostapd_iface { struct hostapd_config *conf; char phy[16]; /* Name of the PHY (radio) */ @@ -661,7 +661,7 @@ +#endif --- a/src/ap/hostapd.c +++ b/src/ap/hostapd.c -@@ -280,6 +280,7 @@ static void hostapd_free_hapd_data(struc +@@ -282,6 +282,7 @@ static void hostapd_free_hapd_data(struc hapd->started = 0; wpa_printf(MSG_DEBUG, "%s(%s)", __func__, hapd->conf->iface); @@ -669,7 +669,7 @@ iapp_deinit(hapd->iapp); hapd->iapp = NULL; accounting_deinit(hapd); -@@ -1118,6 +1119,8 @@ static int hostapd_setup_bss(struct host +@@ -1137,6 +1138,8 @@ static int hostapd_setup_bss(struct host if (hapd->driver && hapd->driver->set_operstate) hapd->driver->set_operstate(hapd->drv_priv, 1); @@ -678,7 +678,7 @@ return 0; } -@@ -1523,6 +1526,7 @@ static int hostapd_setup_interface_compl +@@ -1662,6 +1665,7 @@ static int hostapd_setup_interface_compl if (err) goto fail; @@ -686,7 +686,7 @@ wpa_printf(MSG_DEBUG, "Completing interface initialization"); if (iface->conf->channel) { #ifdef NEED_AP_MLME -@@ -1700,6 +1704,7 @@ dfs_offload: +@@ -1842,6 +1846,7 @@ dfs_offload: fail: wpa_printf(MSG_ERROR, "Interface initialization failed"); @@ -694,7 +694,7 @@ hostapd_set_state(iface, HAPD_IFACE_DISABLED); wpa_msg(hapd->msg_ctx, MSG_INFO, AP_EVENT_DISABLED); #ifdef CONFIG_FST -@@ -2125,6 +2130,7 @@ void hostapd_interface_deinit_free(struc +@@ -2268,6 +2273,7 @@ void hostapd_interface_deinit_free(struc (unsigned int) iface->conf->num_bss); driver = iface->bss[0]->driver; drv_priv = iface->bss[0]->drv_priv; @@ -704,7 +704,7 @@ __func__, driver, drv_priv); --- a/src/ap/ieee802_11.c +++ b/src/ap/ieee802_11.c -@@ -877,7 +877,8 @@ int auth_sae_init_committed(struct hosta +@@ -929,7 +929,8 @@ int auth_sae_init_committed(struct hosta static void handle_auth(struct hostapd_data *hapd, @@ -714,7 +714,7 @@ { u16 auth_alg, auth_transaction, status_code; u16 resp = WLAN_STATUS_SUCCESS; -@@ -893,6 +894,11 @@ static void handle_auth(struct hostapd_d +@@ -945,6 +946,11 @@ static void handle_auth(struct hostapd_d char *identity = NULL; char *radius_cui = NULL; u16 seq_ctrl; @@ -724,9 +724,9 @@ + .frame_info = fi, + }; - if (len < IEEE80211_HDRLEN + sizeof(mgmt->u.auth)) { - wpa_printf(MSG_INFO, "handle_auth - too short payload (len=%lu)", -@@ -1044,6 +1050,14 @@ static void handle_auth(struct hostapd_d + os_memset(&vlan_id, 0, sizeof(vlan_id)); + +@@ -1098,6 +1104,14 @@ static void handle_auth(struct hostapd_d resp = WLAN_STATUS_UNSPECIFIED_FAILURE; goto fail; } @@ -741,7 +741,7 @@ if (res == HOSTAPD_ACL_PENDING) { wpa_printf(MSG_DEBUG, "Authentication frame from " MACSTR " waiting for an external authentication", -@@ -1776,13 +1790,18 @@ static void send_assoc_resp(struct hosta +@@ -1982,13 +1996,18 @@ static u16 send_assoc_resp(struct hostap static void handle_assoc(struct hostapd_data *hapd, const struct ieee80211_mgmt *mgmt, size_t len, @@ -749,7 +749,7 @@ + int reassoc, struct hostapd_frame_info *fi) { u16 capab_info, listen_interval, seq_ctrl, fc; - u16 resp = WLAN_STATUS_SUCCESS; + u16 resp = WLAN_STATUS_SUCCESS, reply_res; const u8 *pos; int left, i; struct sta_info *sta; @@ -761,9 +761,9 @@ if (len < IEEE80211_HDRLEN + (reassoc ? sizeof(mgmt->u.reassoc_req) : sizeof(mgmt->u.assoc_req))) { -@@ -1902,6 +1921,13 @@ static void handle_assoc(struct hostapd_ - goto fail; +@@ -2108,6 +2127,13 @@ static void handle_assoc(struct hostapd_ } + #endif /* CONFIG_MBO */ + if (hostapd_ubus_handle_event(hapd, &req)) { + wpa_printf(MSG_DEBUG, "Station " MACSTR " assoc rejected by ubus handler.\n", @@ -772,10 +772,10 @@ + goto fail; + } + - sta->capability = capab_info; - sta->listen_interval = listen_interval; - -@@ -2328,7 +2354,7 @@ int ieee802_11_mgmt(struct hostapd_data + /* + * sta->capability is used in check_assoc_ies() for RRM enabled + * capability element. +@@ -2588,7 +2614,7 @@ int ieee802_11_mgmt(struct hostapd_data if (stype == WLAN_FC_STYPE_PROBE_REQ) { @@ -784,7 +784,7 @@ return 1; } -@@ -2346,17 +2372,17 @@ int ieee802_11_mgmt(struct hostapd_data +@@ -2606,17 +2632,17 @@ int ieee802_11_mgmt(struct hostapd_data switch (stype) { case WLAN_FC_STYPE_AUTH: wpa_printf(MSG_DEBUG, "mgmt::auth"); @@ -807,7 +807,7 @@ case WLAN_FC_STYPE_DISASSOC: --- a/src/ap/beacon.c +++ b/src/ap/beacon.c -@@ -667,7 +667,7 @@ sta_track_seen_on(struct hostapd_iface * +@@ -675,7 +675,7 @@ sta_track_seen_on(struct hostapd_iface * void handle_probe_req(struct hostapd_data *hapd, const struct ieee80211_mgmt *mgmt, size_t len, @@ -816,7 +816,7 @@ { u8 *resp; struct ieee802_11_elems elems; -@@ -676,9 +676,15 @@ void handle_probe_req(struct hostapd_dat +@@ -684,9 +684,15 @@ void handle_probe_req(struct hostapd_dat size_t i, resp_len; int noack; enum ssid_match_result res; @@ -830,9 +830,9 @@ + .frame_info = fi, + }; - ie = mgmt->u.probe_req.variable; - if (len < IEEE80211_HDRLEN + sizeof(mgmt->u.probe_req)) -@@ -830,6 +836,12 @@ void handle_probe_req(struct hostapd_dat + if (len < IEEE80211_HDRLEN) + return; +@@ -838,6 +844,12 @@ void handle_probe_req(struct hostapd_dat } #endif /* CONFIG_P2P */ @@ -858,7 +858,7 @@ int ieee802_11_update_beacons(struct hostapd_iface *iface); --- a/src/ap/drv_callbacks.c +++ b/src/ap/drv_callbacks.c -@@ -51,6 +51,10 @@ int hostapd_notif_assoc(struct hostapd_d +@@ -52,6 +52,10 @@ int hostapd_notif_assoc(struct hostapd_d u16 reason = WLAN_REASON_UNSPECIFIED; u16 status = WLAN_STATUS_SUCCESS; const u8 *p2p_dev_addr = NULL; @@ -869,7 +869,7 @@ if (addr == NULL) { /* -@@ -123,6 +127,12 @@ int hostapd_notif_assoc(struct hostapd_d +@@ -124,6 +128,12 @@ int hostapd_notif_assoc(struct hostapd_d goto fail; } diff --git a/package/network/services/hostapd/patches/700-make-make-work.patch b/package/network/services/hostapd/patches/700-make-make-work.patch new file mode 100644 index 0000000..643061a --- /dev/null +++ b/package/network/services/hostapd/patches/700-make-make-work.patch @@ -0,0 +1,12 @@ +--- a/hostapd/Makefile ++++ b/hostapd/Makefile +@@ -196,7 +196,8 @@ endif + + ifdef CONFIG_NO_VLAN + CFLAGS += -DCONFIG_NO_VLAN +-else ++endif ++ifneq ($(findstring CONFIG_NO_VLAN,$(CFLAGS)), CONFIG_NO_VLAN) + OBJS += ../src/ap/vlan_init.o + OBJS += ../src/ap/vlan_ifconfig.o + OBJS += ../src/ap/vlan.o -- 2.8.2 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From Michal.Hrusecky at nic.cz Thu May 12 08:10:50 2016 From: Michal.Hrusecky at nic.cz (Michal Hrusecky) Date: Thu, 12 May 2016 14:10:50 +0200 Subject: [OpenWrt-Devel] [PATCH] [package] hostapd: Update to the latest snapshot In-Reply-To: <20160512120715.GC5775@workbook.ipv6.hrusecky.net> References: <20160512120715.GC5775@workbook.ipv6.hrusecky.net> Message-ID: <20160512121050.GD5775@workbook.ipv6.hrusecky.net> Hi, it builds and works for me with mpc85xx and ath9k with at least WPA-PSK, but definitely deserves wider testing. _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From duddu.swaroop at intel.com Thu May 12 10:37:29 2016 From: duddu.swaroop at intel.com (duddu.swaroop at intel.com) Date: Thu, 12 May 2016 20:07:29 +0530 Subject: [OpenWrt-Devel] [PATCH] Added optional command line option for patch-image tool Message-ID: <1463063849-10145-1-git-send-email-duddu.swaroop@intel.com> From: Vishnu Swaroop Duddu Added optional command line option for patch-image tool Default 16KB size is still maintained as this is an optional argument. if one wants to specify or increase size they can provide this option. sample usage: patch-dtb [dtb max size] Signed-off-by: Vishnu Swaroop Duddu --- tools/patch-image/src/patch-cmdline.c | 16 +++++++++++----- tools/patch-image/src/patch-dtb.c | 25 +++++++++++++++---------- 2 files changed, 26 insertions(+), 15 deletions(-) diff --git a/tools/patch-image/src/patch-cmdline.c b/tools/patch-image/src/patch-cmdline.c index 571f848..01499ab 100644 --- a/tools/patch-image/src/patch-cmdline.c +++ b/tools/patch-image/src/patch-cmdline.c @@ -35,10 +35,16 @@ int main(int argc, char **argv) { int fd, found = 0, len, ret = -1; char *ptr, *p; + unsigned int search_space; - if (argc != 3) { - fprintf(stderr, "Usage: %s \n", argv[0]); - goto err1; + if (argc <= 2 || argc > 4) { + fprintf(stderr, "Usage: %s (file) (cmdline) \n", argv[0]); + goto err1; + } else if (argc == 3) { + fprintf(stdout, "search space used is default of 16KB\n"); + search_space = SEARCH_SPACE; + } else { + search_space = atoi(argv[3]); } len = strlen(argv[2]); if (len + 9 > CMDLINE_MAX) { @@ -47,12 +53,12 @@ int main(int argc, char **argv) } if (((fd = open(argv[1], O_RDWR)) < 0) || - (ptr = (char *) mmap(0, SEARCH_SPACE + CMDLINE_MAX, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0)) == (void *) (-1)) { + (ptr = (char *) mmap(0, search_space + CMDLINE_MAX, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0)) == (void *) (-1)) { fprintf(stderr, "Could not open kernel image"); goto err2; } - for (p = ptr; p < (ptr + SEARCH_SPACE); p += 4) { + for (p = ptr; p < (ptr + search_space); p += 4) { if (memcmp(p, "CMDLINE:", 8) == 0) { found = 1; p += 8; diff --git a/tools/patch-image/src/patch-dtb.c b/tools/patch-image/src/patch-dtb.c index 161e1dc..74570ce 100644 --- a/tools/patch-image/src/patch-dtb.c +++ b/tools/patch-image/src/patch-dtb.c @@ -30,19 +30,24 @@ #include #include -#define SEARCH_SPACE (16 * 1024) -#define DTB_MAX (16 * 1024) - +#define DTB_MAX (16*1024) int main(int argc, char **argv) { int fd, fddtb, found = 0, len, ret = -1; char *ptr, *ptrdtb, *p; struct stat s; + unsigned int search_space , dtb_max_size; - if (argc != 3) { - fprintf(stderr, "Usage: %s \n", argv[0]); + if (argc <= 2 || argc > 4) { + fprintf(stderr, "Usage: %s (file) (dtb) \n", argv[0]); goto err1; + } else if (argc == 3) { + fprintf(stdout, "DT size used is default of 16KB\n"); + search_space = dtb_max_size = DTB_MAX; + } else { + search_space = dtb_max_size = atoi(argv[3]); } + fddtb = open(argv[1], O_RDONLY); if (!fddtb) goto err1; @@ -53,24 +58,24 @@ int main(int argc, char **argv) } len = s.st_size; - if (len + 8 > DTB_MAX) { + if (len + 8 > dtb_max_size) { fprintf(stderr, "DTB too big\n"); goto err1; } if (((fddtb = open(argv[2], O_RDONLY)) < 0) || - (ptrdtb = (char *) mmap(0, DTB_MAX, PROT_READ, MAP_SHARED, fddtb, 0)) == (void *) (-1)) { + (ptrdtb = (char *) mmap(0, dtb_max_size, PROT_READ, MAP_SHARED, fddtb, 0)) == (void *) (-1)) { fprintf(stderr, "Could not open DTB"); goto err2; } if (((fd = open(argv[1], O_RDWR)) < 0) || - (ptr = (char *) mmap(0, SEARCH_SPACE + DTB_MAX, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0)) == (void *) (-1)) { + (ptr = (char *) mmap(0, search_space + dtb_max_size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0)) == (void *) (-1)) { fprintf(stderr, "Could not open kernel image"); goto err3; } - for (p = ptr; p < (ptr + SEARCH_SPACE); p += 4) { + for (p = ptr; p < (ptr + search_space); p += 4) { if (memcmp(p, "OWRTDTB:", 8) == 0) { found = 1; p += 8; @@ -82,7 +87,7 @@ int main(int argc, char **argv) goto err4; } - memset(p, 0, DTB_MAX - 8); + memset(p, 0, dtb_max_size - 8); memcpy(p, ptrdtb, len); msync(p, len, MS_SYNC|MS_INVALIDATE); ret = 0; -- 1.8.3.4 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From hauke at hauke-m.de Thu May 12 18:44:50 2016 From: hauke at hauke-m.de (Hauke Mehrtens) Date: Fri, 13 May 2016 00:44:50 +0200 Subject: [OpenWrt-Devel] OpenWrt summit by prpl Message-ID: <57350762.9050801@hauke-m.de> Hi, When I use OpenWrt in this mail, I mean OpenWrt and LEDE, I hope we come to a solution in the next days on this. prpl wants to organize an OpenWrt summit again. Their goal is to bring the community, industry and developers together. Currently this is in planing and I want to know what should happen so that more developers and more members of the community would come to such an event. There are different ideas on how to organize such an event: 1. prpl organizes an event co located with the Embedded Linux conference this October in Berlin. 2. prpl organizes an event co located with Battlemesh next year in May. 3. Some people from OpenWrt organize an event in Prague at CZ.NIC. CZ.NIC would provide a location and local logistics, prpl could help with finance. It is also possible to do more than one solution or combine them. Are there some people interested in organizing this by themselfs with the help of CZ.NIC, then we could go with this solution? If nobody is interested in organizing this I would like to see it co located with the ELCE and the Battlemesh next year. No final name for this event was chosen. The current suggestion is "OpenWrt summit by prpl" or something similar. Are there any comments on this? Hauke _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From nemesis at ninux.org Fri May 13 04:15:29 2016 From: nemesis at ninux.org (Nemesis) Date: Fri, 13 May 2016 10:15:29 +0200 Subject: [OpenWrt-Devel] OpenWrt summit by prpl In-Reply-To: <57350762.9050801@hauke-m.de> References: <57350762.9050801@hauke-m.de> Message-ID: <57358D21.40801@ninux.org> Hi everyone, I have been at the event in Dublin last year with a colleague. The event was really interesting from a technical point of view and we really missed such an event focused on OpenWRT and the various applications & services one can build with it. It would be good to have more communities to participate in such an event, and it would be awesome if the most active developers would have a leading role in organizing it. Hauke, one note regarding co-location, you wrote: "I would like to see it co located with the ELCE and the Battlemesh next year." But I believe the Battlemesh next year won't be co located with ELCE, did you mean the Battlemesh or ELCE? Federico On 05/13/2016 12:44 AM, Hauke Mehrtens wrote: > Hi, > > When I use OpenWrt in this mail, I mean OpenWrt and LEDE, I hope we come > to a solution in the next days on this. > > prpl wants to organize an OpenWrt summit again. Their goal is to bring > the community, industry and developers together. Currently this is in > planing and I want to know what should happen so that more developers > and more members of the community would come to such an event. > > There are different ideas on how to organize such an event: > 1. prpl organizes an event co located with the Embedded Linux conference > this October in Berlin. > 2. prpl organizes an event co located with Battlemesh next year in May. > 3. Some people from OpenWrt organize an event in Prague at CZ.NIC. > CZ.NIC would provide a location and local logistics, prpl could help > with finance. > > It is also possible to do more than one solution or combine them. > > Are there some people interested in organizing this by themselfs with > the help of CZ.NIC, then we could go with this solution? > If nobody is interested in organizing this I would like to see it co > located with the ELCE and the Battlemesh next year. > > No final name for this event was chosen. The current suggestion is > "OpenWrt summit by prpl" or something similar. > > Are there any comments on this? > > Hauke > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From michal.hrusecky at nic.cz Fri May 13 04:17:44 2016 From: michal.hrusecky at nic.cz (Michal Hrusecky) Date: Fri, 13 May 2016 10:17:44 +0200 Subject: [OpenWrt-Devel] [PATCH] [package] busybox: Add option to install example udhcpc script Message-ID: <20160513081744.GA11948@workbook.ipv6.hrusecky.net> When building very minimal system, people might be interested in using udhcpc. To be able to use it, it needs script to actually set addresses. There is an example script provided in examples directory which might be good enough for some purposes. This patch makes it possible to select it in menuconfig and enable it's installation. Signed-off-by: Michal Hrusecky --- package/utils/busybox/Makefile | 5 +++++ package/utils/busybox/config/networking/udhcp/Config.in | 7 +++++++ 2 files changed, 12 insertions(+) diff --git a/package/utils/busybox/Makefile b/package/utils/busybox/Makefile index 24c064c..1f60257 100644 --- a/package/utils/busybox/Makefile +++ b/package/utils/busybox/Makefile @@ -115,6 +115,11 @@ define Package/busybox/install $(INSTALL_BIN) ./files/cron $(1)/etc/init.d/cron $(INSTALL_BIN) ./files/sysntpd $(1)/etc/init.d/sysntpd $(INSTALL_BIN) ./files/ntpd-hotplug $(1)/usr/sbin/ntpd-hotplug + $(INSTALL_DIR) $(1)/etc/init.d + ifeq ($(CONFIG_BUSYBOX_CONFIG_UDHCP_INSTALL_SIMPLE_SCRIPT),y) + $(INSTALL_DIR) $(1)$(shell dirname $(CONFIG_BUSYBOX_CONFIG_UDHCPC_DEFAULT_SCRIPT)) + $(INSTALL_BIN) $(PKG_BUILD_DIR)/examples/udhcp/simple.script $(1)$(CONFIG_BUSYBOX_CONFIG_UDHCPC_DEFAULT_SCRIPT) + endif -rm -rf $(1)/lib64 endef diff --git a/package/utils/busybox/config/networking/udhcp/Config.in b/package/utils/busybox/config/networking/udhcp/Config.in index 4f48400..371adc4 100644 --- a/package/utils/busybox/config/networking/udhcp/Config.in +++ b/package/utils/busybox/config/networking/udhcp/Config.in @@ -147,6 +147,13 @@ config BUSYBOX_CONFIG_UDHCPC_DEFAULT_SCRIPT examples/udhcp for a working example. Normally it is safe to leave this untouched. +config BUSYBOX_CONFIG_UDHCP_INSTALL_SIMPLE_SCRIPT + bool "Install simple config script" + default n + depends on BUSYBOX_CONFIG_UDHCPC + help + Installs example configuration script so udhcpc can be used out of the box. + config BUSYBOX_CONFIG_UDHCPC_SLACK_FOR_BUGGY_SERVERS int "DHCP options slack buffer size" default BUSYBOX_DEFAULT_UDHCPC_SLACK_FOR_BUGGY_SERVERS -- 2.8.2 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From michal.hrusecky at nic.cz Fri May 13 05:30:10 2016 From: michal.hrusecky at nic.cz (Michal Hrusecky) Date: Fri, 13 May 2016 11:30:10 +0200 Subject: [OpenWrt-Devel] [PATCH] [package] linux: Add new Marvell cryptoengine Message-ID: <20160513093010.GA8419@workbook.ipv6.hrusecky.net> Adding new Marvell cryptoengine as some device might use the new one and not the old one. Signed-off-by: Michal Hrusecky --- package/kernel/linux/modules/crypto.mk | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-) diff --git a/package/kernel/linux/modules/crypto.mk b/package/kernel/linux/modules/crypto.mk index 0acc730..0f37a55 100644 --- a/package/kernel/linux/modules/crypto.mk +++ b/package/kernel/linux/modules/crypto.mk @@ -711,14 +711,28 @@ endef $(eval $(call KernelPackage,crypto-xts)) - define KernelPackage/crypto-mv-cesa - TITLE:=Marvell crypto engine + TITLE:=Old Marvell crypto engine DEPENDS:=+kmod-crypto-manager @TARGET_kirkwood||TARGET_orion||TARGET_mvebu - KCONFIG:=CONFIG_CRYPTO_DEV_MV_CESA + KCONFIG:= \ + CONFIG_CRYPTO_DEV_MV_CESA \ + CONFIG_CRYPTO_HW=y FILES:=$(LINUX_DIR)/drivers/crypto/mv_cesa.ko AUTOLOAD:=$(call AutoLoad,09,mv_cesa) $(call AddDepends/crypto) endef $(eval $(call KernelPackage,crypto-mv-cesa)) + +define KernelPackage/crypto-marvell-cesa + TITLE:=New Marvell crypto engine + DEPENDS:=+kmod-crypto-manager @TARGET_kirkwood||TARGET_orion||TARGET_mvebu + KCONFIG:= \ + CONFIG_CRYPTO_DEV_MARVELL_CESA \ + CONFIG_CRYPTO_HW=y + FILES:=$(LINUX_DIR)/drivers/crypto/marvell/marvell-cesa.ko + AUTOLOAD:=$(call AutoLoad,09,marvell-cesa) + $(call AddDepends/crypto) +endef + +$(eval $(call KernelPackage,crypto-marvell-cesa)) -- 2.8.2 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From nbd at nbd.name Fri May 13 10:52:51 2016 From: nbd at nbd.name (Felix Fietkau) Date: Fri, 13 May 2016 16:52:51 +0200 Subject: [OpenWrt-Devel] [PATCH] [package] busybox: Add option to install example udhcpc script In-Reply-To: <20160513081744.GA11948@workbook.ipv6.hrusecky.net> References: <20160513081744.GA11948@workbook.ipv6.hrusecky.net> Message-ID: On 2016-05-13 10:17, Michal Hrusecky wrote: > When building very minimal system, people might be interested in using udhcpc. > To be able to use it, it needs script to actually set addresses. There is an > example script provided in examples directory which might be good enough for > some purposes. This patch makes it possible to select it in menuconfig and > enable it's installation. > > Signed-off-by: Michal Hrusecky Why? The netifd package already has a /usr/share/udhcpc/default.script which sets addresses and routes. It could be moved to the busybox package though... - Felix _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From Michal.Hrusecky at nic.cz Fri May 13 11:19:35 2016 From: Michal.Hrusecky at nic.cz (Michal Hrusecky) Date: Fri, 13 May 2016 17:19:35 +0200 Subject: [OpenWrt-Devel] [PATCH] [package] busybox: Add option to install example udhcpc script In-Reply-To: References: <20160513081744.GA11948@workbook.ipv6.hrusecky.net> Message-ID: <20160513151935.GF2783@workbook.ipv6.hrusecky.net> Felix Fietkau - 16:52 13.05.16 wrote: > On 2016-05-13 10:17, Michal Hrusecky wrote: > > When building very minimal system, people might be interested in using udhcpc. > > To be able to use it, it needs script to actually set addresses. There is an > > example script provided in examples directory which might be good enough for > > some purposes. This patch makes it possible to select it in menuconfig and > > enable it's installation. > > > > Signed-off-by: Michal Hrusecky > Why? The netifd package already has a /usr/share/udhcpc/default.script > which sets addresses and routes. It could be moved to the busybox > package though... Probably not entirely mainstream use-case, but I'm using the OpenWRT tree to build also very minimalistic recovery system - without procd, netifd, ubus just few basic utilities and simple script. I could make script part of my recovery image, but as it is already there in busybox... _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From n.mavrogiannopoulos at gmail.com Sat May 14 04:18:36 2016 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Sat, 14 May 2016 10:18:36 +0200 Subject: [OpenWrt-Devel] netifd: adding default route + route via previous default route Message-ID: <1463213916.22808.5.camel@gmail.com> Hi, ?A user of openconnect VPN is trying to use openconnect as a default route on his router [0]. Currently this works by setting defaultroute=1 on his /etc/config/network, however, once the default route is setup the VPN connection drops because there is no direct route to the VPN gateway. Obviously I need to setup a /32 (or /128 for IPv6) route for the VPN gateway using the previous defaultroute interface. However it is not apparent to me how to do that via the netifd-proto.sh or the functions/network.sh. Any hints? Should I use the user's suggestion of directly setting the route via busybox' route command? regards, Nikos [0].?https://github.com/openwrt/packages/issues/2548 [1].?https://github.com/openwrt/packages/blob/master/net/vpnc-scripts/files/vpnc-script _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From yszhou4tech at gmail.com Sat May 14 06:29:47 2016 From: yszhou4tech at gmail.com (Yousong Zhou) Date: Sat, 14 May 2016 18:29:47 +0800 Subject: [OpenWrt-Devel] netifd: adding default route + route via previous default route In-Reply-To: <1463213916.22808.5.camel@gmail.com> References: <1463213916.22808.5.camel@gmail.com> Message-ID: On 14 May 2016 at 16:18, Nikos Mavrogiannopoulos wrote: > Hi, > A user of openconnect VPN is trying to use openconnect as a default > route on his router [0]. Currently this works by setting defaultroute=1 > on his /etc/config/network, however, once the default route is setup > the VPN connection drops because there is no direct route to the VPN > gateway. > > Obviously I need to setup a /32 (or /128 for IPv6) route for the VPN > gateway using the previous defaultroute interface. However it is not > apparent to me how to do that via the netifd-proto.sh or the > functions/network.sh. Any hints? Should I use the user's suggestion of > directly setting the route via busybox' route command? > I remember `proto_add_host_dependency` can be used to instruct netifd to setup such a route. But it looks like the relevant code for openconnect.sh is now commented out. yousong > regards, > Nikos > > [0]. https://github.com/openwrt/packages/issues/2548 > [1]. https://github.com/openwrt/packages/blob/master/net/vpnc-scripts/files/vpnc-script > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From eyal.birger at gmail.com Sun May 15 01:13:27 2016 From: eyal.birger at gmail.com (Eyal Birger) Date: Sun, 15 May 2016 08:13:27 +0300 Subject: [OpenWrt-Devel] [PATCH] libubus: nullify stale msgbuf pointer in case of ubus_connect_ctx() failure Message-ID: <1463289207-6602-1-git-send-email-eyal.birger@gmail.com> If the ubus_reconnect() call fails in ubus_connect_ctx(), the msgbuf.data newly allocated buffer is freed, but its pointer in the ubus_context is not removed. This leads to a double free error if ubus_auto_shutdown() is called for cleanup after ubus_auto_connect() failed to connect to ubusd. Signed-off-by: Eyal Birger --- libubus.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libubus.c b/libubus.c index d52faff..8163ff7 100644 --- a/libubus.c +++ b/libubus.c @@ -294,6 +294,7 @@ int ubus_connect_ctx(struct ubus_context *ctx, const char *path) avl_init(&ctx->objects, ubus_cmp_id, false, NULL); if (ubus_reconnect(ctx, path)) { free(ctx->msgbuf.data); + ctx->msgbuf.data = NULL; return -1; } -- 1.9.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From n.mavrogiannopoulos at gmail.com Sun May 15 07:14:09 2016 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Sun, 15 May 2016 13:14:09 +0200 Subject: [OpenWrt-Devel] netifd: adding default route + route via previous default route In-Reply-To: References: <1463213916.22808.5.camel@gmail.com> Message-ID: <1463310849.16936.0.camel@gmail.com> On Sat, 2016-05-14 at 18:29 +0800, Yousong Zhou wrote: > On 14 May 2016 at 16:18, Nikos Mavrogiannopoulos > wrote: > > > > Hi, > > ?A user of openconnect VPN is trying to use openconnect as a > > default > > route on his router [0]. Currently this works by setting > > defaultroute=1 > > on his /etc/config/network, however, once the default route is > > setup > > the VPN connection drops because there is no direct route to the > > VPN > > gateway. > > > > Obviously I need to setup a /32 (or /128 for IPv6) route for the > > VPN > > gateway using the previous defaultroute interface. However it is > > not > > apparent to me how to do that via the netifd-proto.sh or the > > functions/network.sh. Any hints? Should I use the user's suggestion > > of > > directly setting the route via busybox' route command? > > > I remember `proto_add_host_dependency` can be used to instruct netifd > to setup such a route.??But it looks like the relevant code for > openconnect.sh is now commented out. It was causing an infinite loop, and I could not understand through code what the add_host_dependency was supposed to do. Do you have any information about this function? regards, Nikos _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From yszhou4tech at gmail.com Sun May 15 08:50:06 2016 From: yszhou4tech at gmail.com (Yousong Zhou) Date: Sun, 15 May 2016 20:50:06 +0800 Subject: [OpenWrt-Devel] netifd: adding default route + route via previous default route In-Reply-To: <1463310849.16936.0.camel@gmail.com> References: <1463213916.22808.5.camel@gmail.com> <1463310849.16936.0.camel@gmail.com> Message-ID: On 15 May 2016 at 19:14, Nikos Mavrogiannopoulos wrote: > On Sat, 2016-05-14 at 18:29 +0800, Yousong Zhou wrote: >> On 14 May 2016 at 16:18, Nikos Mavrogiannopoulos >> wrote: >> > >> > Hi, >> > A user of openconnect VPN is trying to use openconnect as a >> > default >> > route on his router [0]. Currently this works by setting >> > defaultroute=1 >> > on his /etc/config/network, however, once the default route is >> > setup >> > the VPN connection drops because there is no direct route to the >> > VPN >> > gateway. >> > >> > Obviously I need to setup a /32 (or /128 for IPv6) route for the >> > VPN >> > gateway using the previous defaultroute interface. However it is >> > not >> > apparent to me how to do that via the netifd-proto.sh or the >> > functions/network.sh. Any hints? Should I use the user's suggestion >> > of >> > directly setting the route via busybox' route command? >> > >> I remember `proto_add_host_dependency` can be used to instruct netifd >> to setup such a route. But it looks like the relevant code for >> openconnect.sh is now commented out. > > It was causing an infinite loop, and I could not understand through > code what the add_host_dependency was supposed to do. Do you have any > information about this function? `proto_add_host_dependency` takes 3 arguments. - The 1st is the logical interface name we are adding dependency for - The 2nd is the host the above interface will depend on - The 3rd is also a logical interface name. It's optional and is for explicitly specifying which logical interface the 1st argument depends on. If the 3rd argument is not given, netifd will try to find the logical interface which provides route to to the specified host (2nd argument) and a host route will be available. The 1st logical interface will also be added to the list of "users" of that logical interface and will be notified of it's up/down/update event. I guess the problem with openconnect.sh may be that the 3rd argument was using the incorrect type. Is that `vpn-$config` meant to be a linux system interface name? We can try just not passing the 3rd argument and see how it works. I often misunderstood the code because of the naming convention about linux system interface name and logical interface name. I tend to believe ifname is for the former but it's not always so in the code... 2 relevant links for your information - https://github.com/openwrt/packages/blob/master/net/pppossh/files/pppossh.sh#L38 - https://github.com/openwrt/openwrt/commit/dd8ae0460259ae764e6becfdb4dad91a0d478392 yousong > > regards, > Nikos > _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From adron at yapic.net Sun May 15 09:37:01 2016 From: adron at yapic.net (adron at yapic.net) Date: Sun, 15 May 2016 16:37:01 +0300 Subject: [OpenWrt-Devel] [PATCH] ar71xx: tools/kernel2minor. Remove kernel2mikrotikyaffs2 section from Target Images submenu. Message-ID: <1463319421-5226-1-git-send-email-adron@yapic.net> From: Sergey Sergeev It is no longer necessary because now to get mikrotik's yaffs2 kernel image we using KERNEL := ... | kernel2mikor ... in target/linux/ar71xx/image/Makefile -> Device/rb-... section. Signed-off-by: Sergey Sergeev --- config/Config-images.in | 31 ------------------------------- target/linux/ar71xx/image/Makefile | 14 -------------- 2 files changed, 45 deletions(-) diff --git a/config/Config-images.in b/config/Config-images.in index c7d1898..a60dd50 100644 --- a/config/Config-images.in +++ b/config/Config-images.in @@ -6,37 +6,6 @@ menu "Target Images" - menuconfig TARGET_KERNELFS_MIKROTIK_YAFFS2 - bool "kernel2mikrotikyaffs2" - default y if USES_KERNEL2MIKROTIKYAFFS2 - depends on USES_KERNEL2MIKROTIKYAFFS2 - help - Build a Mikrotik's version of Yaffs2 filesystem which contains only a single kernel file. - This is necessary for boot through RouterBoot boot loader. - - config TARGET_MIKROTIK_YAFFS2_NOR_FLASH_IMG - bool "NOR flash image" - depends on TARGET_KERNELFS_MIKROTIK_YAFFS2 - default "y" - help - Build Mikrotik's Yaffs2 filesystem image for NOR flash boards: - Mikrotik rb941-2nd(hAP lite) - And maby(not tested yet) all new routerboards with this strings in description: - Storage type FLASH - Storage size 16 MB - - config TARGET_MIKROTIK_YAFFS2_NAND_2048B_ECC_FLASH_IMG - bool "NAND flash (2048b with ECC) image" - depends on TARGET_KERNELFS_MIKROTIK_YAFFS2 - default "y" - help - Build Mikrotik's Yaffs2 filesystem image for NAND flash boards: - Mikrotik rb750 and rb751 - And maby(not tested yet) all routerboards with NAND flash parameters like this: - Eraseblock size: 131072 bytes, 128.0 KiB - Minimum input/output unit size: 2048 bytes - OOB size: 64 bytes - menuconfig TARGET_ROOTFS_INITRAMFS bool "ramdisk" default y if USES_INITRAMFS diff --git a/target/linux/ar71xx/image/Makefile b/target/linux/ar71xx/image/Makefile index 9fae043..20a0f7e 100644 --- a/target/linux/ar71xx/image/Makefile +++ b/target/linux/ar71xx/image/Makefile @@ -1492,17 +1492,6 @@ define MkuImageOKLI endef endif -define kernel2mikrotikyaffs2 -#NOR flash -ifneq ($(CONFIG_TARGET_MIKROTIK_YAFFS2_NOR_FLASH_IMG),) - $(STAGING_DIR_HOST)/bin/kernel2minor -k $(KDIR)/loader-generic.elf -r $(VMLINUX)-lzma.nor-tik-yaffs2 -s 1024 -e -endif -#NAND flash 2048b with ECC -ifneq ($(CONFIG_TARGET_MIKROTIK_YAFFS2_NAND_2048B_ECC_FLASH_IMG),) - $(STAGING_DIR_HOST)/bin/kernel2minor -k $(KDIR)/loader-generic.elf -r $(VMLINUX)-lzma.nand-tik-yaffs2-2048b-ecc -s 2048 -c -e -endif -endef - # $(1): name of the 1st file. # $(2): size limit of the 1st file if it is greater than 262144, or # the erase size of the flash if it is greater than zero and less @@ -1693,9 +1682,6 @@ define Image/BuildKernel $(call MkuImage,gzip,,$(KDIR)/vmlinux.bin.gz,$(UIMAGE)-gzip.bin) $(call MkuImage,lzma,,$(KDIR)/vmlinux.bin.lzma,$(UIMAGE)-lzma.bin) cp $(KDIR)/loader-generic.elf $(VMLINUX)-lzma.elf -ifneq ($(CONFIG_TARGET_KERNELFS_MIKROTIK_YAFFS2),) - $(call kernel2mikrotikyaffs2) -endif -mkdir -p $(KDIR_TMP) $(call Image/Build/Profile/$(IMAGE_PROFILE),buildkernel) endef -- 1.9.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From adron at yapic.net Sun May 15 09:38:11 2016 From: adron at yapic.net (adron at yapic.net) Date: Sun, 15 May 2016 16:38:11 +0300 Subject: [OpenWrt-Devel] [PATCH] ar71xx: add Mikrotik rb941-2nd support Message-ID: <1463319491-6755-1-git-send-email-adron@yapic.net> From: Sergey Sergeev This patch adds support for the Mikrotik rb941-2nd. https://wiki.openwrt.org/toh/mikrotik/rb941_2nd Signed-off-by: Sergey Sergeev --- include/image.mk | 7 + target/linux/ar71xx/base-files/etc/board.d/01_leds | 4 + .../linux/ar71xx/base-files/etc/board.d/02_network | 5 + target/linux/ar71xx/base-files/etc/diag.sh | 2 +- target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 + .../ar71xx/base-files/lib/upgrade/platform.sh | 30 +++- target/linux/ar71xx/config-4.1 | 1 + target/linux/ar71xx/config-4.4 | 1 + .../ar71xx/files/arch/mips/ath79/Kconfig.openwrt | 10 ++ target/linux/ar71xx/files/arch/mips/ath79/Makefile | 1 + .../ar71xx/files/arch/mips/ath79/mach-rb941.c | 174 +++++++++++++++++++++ .../linux/ar71xx/files/arch/mips/ath79/machtypes.h | 1 + target/linux/ar71xx/image/Makefile | 23 +++ target/linux/ar71xx/mikrotik/config-default | 5 +- .../mikrotik/profiles/00-mikrotik-default.mk | 16 ++ .../linux/ar71xx/mikrotik/profiles/01-minimal.mk | 10 +- .../linux/ar71xx/mikrotik/profiles/03-norflash.mk | 16 ++ 17 files changed, 295 insertions(+), 14 deletions(-) create mode 100644 target/linux/ar71xx/files/arch/mips/ath79/mach-rb941.c create mode 100644 target/linux/ar71xx/mikrotik/profiles/00-mikrotik-default.mk create mode 100644 target/linux/ar71xx/mikrotik/profiles/03-norflash.mk diff --git a/include/image.mk b/include/image.mk index bc383e6..db5039f 100644 --- a/include/image.mk +++ b/include/image.mk @@ -436,6 +436,13 @@ define Build/sysupgrade-nand $@ endef +define Build/kernel2minor + if [ -x $(STAGING_DIR_HOST)/bin/kernel2minor ]; then \ + $(STAGING_DIR_HOST)/bin/kernel2minor -k $@ -r $@.new $(1); \ + mv $@.new $@; \ + fi +endef + define Device/Init PROFILES := $(PROFILE) DEVICE_NAME := $(1) diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds b/target/linux/ar71xx/base-files/etc/board.d/01_leds index 39b21ca..2d3013b 100755 --- a/target/linux/ar71xx/base-files/etc/board.d/01_leds +++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds @@ -179,6 +179,10 @@ rb-750) ucidef_set_led_switch "port5" "port5" "rb750:green:port5" "switch0" "0x02" ;; +rb-941-2nd) + ucidef_set_led_timer "act" "act" "rb:green:act" "1000" "1000" + ;; + rb-2011l|\ rb-2011uas|\ rb-2011uias|\ diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network b/target/linux/ar71xx/base-files/etc/board.d/02_network index 67adf33..2095179 100755 --- a/target/linux/ar71xx/base-files/etc/board.d/02_network +++ b/target/linux/ar71xx/base-files/etc/board.d/02_network @@ -82,6 +82,11 @@ airgatewaypro) "0 at eth0" "4:lan" "5:wan" ;; +rb-941-2nd) + ucidef_add_switch "switch0" \ + "0 at eth0" "1:lan" "2:lan" "3:lan" "4:wan" + ;; + db120 |\ rb-2011l | \ rb-2011uas |\ diff --git a/target/linux/ar71xx/base-files/etc/diag.sh b/target/linux/ar71xx/base-files/etc/diag.sh index f95a72d..dd5ca33 100644 --- a/target/linux/ar71xx/base-files/etc/diag.sh +++ b/target/linux/ar71xx/base-files/etc/diag.sh @@ -248,7 +248,7 @@ get_status_led() { rb-912uag-5hpnd) status_led="rb:green:user" ;; - rb-951ui-2hnd) + rb-951ui-2hnd | rb-941-2nd) status_led="rb:green:act" ;; rb-sxt2n|\ diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh b/target/linux/ar71xx/base-files/lib/ar71xx.sh index d71b8ba..ed0640c 100755 --- a/target/linux/ar71xx/base-files/lib/ar71xx.sh +++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh @@ -730,6 +730,9 @@ ar71xx_board_detect() { *"RouterBOARD 912UAG-5HPnD") name="rb-912uag-5hpnd" ;; + *"RouterBOARD 941-2nD") + name="rb-941-2nd" + ;; *"RouterBOARD 951G-2HnD") name="rb-951g-2hnd" ;; diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh index 9f8a14b..65bb406 100755 --- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh +++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh @@ -11,6 +11,8 @@ RAMFS_COPY_DATA=/lib/ar71xx.sh CI_BLKSZ=65536 CI_LDADR=0x80060000 +PLATFORM_DO_UPGRADE_COMBINED_SEPARATE_MTD=0 + platform_find_partitions() { local first dev size erasesize name while read dev size erasesize name; do @@ -40,6 +42,13 @@ platform_find_kernelpart() { done } +platform_find_rootfspart() { + local part + for part in "${1%:*}" "${1#*:}"; do + [ "$part" != "$2" ] && echo "$part"; break + done +} + platform_do_upgrade_combined() { local partitions=$(platform_find_partitions) local kernelpart=$(platform_find_kernelpart "${partitions#*:}") @@ -53,13 +62,22 @@ platform_do_upgrade_combined() { [ ${root_blocks:-0} -gt 0 ] && \ [ ${erase_size:-0} -gt 0 ]; then + local rootfspart=$(platform_find_rootfspart "$partitions" "$kernelpart") local append="" [ -f "$CONF_TAR" -a "$SAVE_CONFIG" -eq 1 ] && append="-j $CONF_TAR" - ( dd if="$1" bs=$CI_BLKSZ skip=1 count=$kern_blocks 2>/dev/null; \ - dd if="$1" bs=$CI_BLKSZ skip=$((1+$kern_blocks)) count=$root_blocks 2>/dev/null ) | \ - mtd -r $append -F$kernelpart:$kern_length:$CI_LDADR,rootfs write - $partitions + if [ "$PLATFORM_DO_UPGRADE_COMBINED_SEPARATE_MTD" -ne 1 ]; then + ( dd if="$1" bs=$CI_BLKSZ skip=1 count=$kern_blocks 2>/dev/null; \ + dd if="$1" bs=$CI_BLKSZ skip=$((1+$kern_blocks)) count=$root_blocks 2>/dev/null ) | \ + mtd -r $append -F$kernelpart:$kern_length:$CI_LDADR,rootfs write - $partitions + elif [ -n "$rootfspart" ]; then + dd if="$1" bs=$CI_BLKSZ skip=1 count=$kern_blocks 2>/dev/null | \ + mtd write - $kernelpart + dd if="$1" bs=$CI_BLKSZ skip=$((1+$kern_blocks)) count=$root_blocks 2>/dev/null | \ + mtd -r $append write - $rootfspart + fi fi + PLATFORM_DO_UPGRADE_COMBINED_SEPARATE_MTD=0 } tplink_get_image_hwid() { @@ -470,6 +488,7 @@ platform_check_image() { nand_do_platform_check $board $1 return $?; ;; + rb-941-2nd | \ routerstation | \ routerstation-pro | \ ls-sr71 | \ @@ -513,7 +532,6 @@ platform_check_image() { } return 0 ;; - esac echo "Sysupgrade is not yet supported on $board." @@ -540,6 +558,10 @@ platform_do_upgrade() { local board=$(ar71xx_board_name) case "$board" in + rb-941-2nd) + PLATFORM_DO_UPGRADE_COMBINED_SEPARATE_MTD=1 + platform_do_upgrade_combined "$ARGV" + ;; routerstation | \ routerstation-pro | \ ls-sr71 | \ diff --git a/target/linux/ar71xx/config-4.1 b/target/linux/ar71xx/config-4.1 index 5939891..9c2400b 100644 --- a/target/linux/ar71xx/config-4.1 +++ b/target/linux/ar71xx/config-4.1 @@ -124,6 +124,7 @@ CONFIG_ATH79_MACH_R6100=y # CONFIG_ATH79_MACH_RB750 is not set # CONFIG_ATH79_MACH_RB91X is not set # CONFIG_ATH79_MACH_RB922 is not set +# CONFIG_ATH79_MACH_RB941 is not set # CONFIG_ATH79_MACH_RB95X is not set # CONFIG_ATH79_MACH_RBSXTLITE is not set CONFIG_ATH79_MACH_RW2458N=y diff --git a/target/linux/ar71xx/config-4.4 b/target/linux/ar71xx/config-4.4 index 57ac5d8..a037008 100644 --- a/target/linux/ar71xx/config-4.4 +++ b/target/linux/ar71xx/config-4.4 @@ -127,6 +127,7 @@ CONFIG_ATH79_MACH_R6100=y # CONFIG_ATH79_MACH_RB750 is not set # CONFIG_ATH79_MACH_RB91X is not set # CONFIG_ATH79_MACH_RB922 is not set +# CONFIG_ATH79_MACH_RB941 is not set # CONFIG_ATH79_MACH_RB95X is not set # CONFIG_ATH79_MACH_RBSXTLITE is not set CONFIG_ATH79_MACH_RW2458N=y diff --git a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt index 0fb2df2..9703e71 100644 --- a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt +++ b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt @@ -736,6 +736,16 @@ config ATH79_MACH_RB922 select ATH79_ROUTERBOOT select RLE_DECOMPRESS +config ATH79_MACH_RB941 + bool "MikroTik RouterBOARD 941-2nd support" + select SOC_QCA953X + select ATH79_DEV_ETH + select ATH79_DEV_GPIO_BUTTONS + select ATH79_DEV_LEDS_GPIO + select ATH79_DEV_M25P80 + select ATH79_DEV_WMAC + select ATH79_ROUTERBOOT + config ATH79_MACH_RB95X bool "MikroTik RouterBOARD 95X support" select SOC_AR934X diff --git a/target/linux/ar71xx/files/arch/mips/ath79/Makefile b/target/linux/ar71xx/files/arch/mips/ath79/Makefile index 6144e29..de7b7d9 100644 --- a/target/linux/ar71xx/files/arch/mips/ath79/Makefile +++ b/target/linux/ar71xx/files/arch/mips/ath79/Makefile @@ -130,6 +130,7 @@ obj-$(CONFIG_ATH79_MACH_RB4XX) += mach-rb4xx.o obj-$(CONFIG_ATH79_MACH_RB750) += mach-rb750.o obj-$(CONFIG_ATH79_MACH_RB91X) += mach-rb91x.o obj-$(CONFIG_ATH79_MACH_RB922) += mach-rb922.o +obj-$(CONFIG_ATH79_MACH_RB941) += mach-rb941.o obj-$(CONFIG_ATH79_MACH_RB95X) += mach-rb95x.o obj-$(CONFIG_ATH79_MACH_RB2011) += mach-rb2011.o obj-$(CONFIG_ATH79_MACH_RBSXTLITE) += mach-rbsxtlite.o diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-rb941.c b/target/linux/ar71xx/files/arch/mips/ath79/mach-rb941.c new file mode 100644 index 0000000..5a8c7c0 --- /dev/null +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-rb941.c @@ -0,0 +1,174 @@ +/* + * MikroTik RouterBOARD 941-2nD support + * + * Copyright (C) 2016 Sergey Sergeev + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 as published + * by the Free Software Foundation. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +//#include +#include + +#include +#include +#include + +#include "common.h" +#include "dev-ap9x-pci.h" +#include "dev-eth.h" +#include "dev-spi.h" +#include "dev-gpio-buttons.h" +#include "dev-leds-gpio.h" +#include "dev-m25p80.h" +//#include "dev-usb.h" +#include "dev-wmac.h" +#include "machtypes.h" +#include "routerboot.h" + +#define RB941_GPIO_LED_ACT 14 +#define RB941_GPIO_BTN_RESET 16 + +#define RB941_KEYS_POLL_INTERVAL 20 /* msecs */ +#define RB941_KEYS_DEBOUNCE_INTERVAL (3 * RB941_KEYS_POLL_INTERVAL) + +#define RB_ROUTERBOOT_OFFSET 0x0000 +#define RB_ROUTERBOOT_SIZE 0xe000 +#define RB_HARD_CFG_OFFSET 0xe000 +#define RB_HARD_CFG_SIZE 0x1000 +#define RB_BIOS_OFFSET 0xf000 +#define RB_BIOS_SIZE 0x1000 +#define RB_ROUTERBOOT2_OFFSET 0x10000 +#define RB_ROUTERBOOT2_SIZE 0xf000 +#define RB_SOFT_CFG_OFFSET 0x1f000 +#define RB_SOFT_CFG_SIZE 0x1000 +#define RB_ROOTFS_OFFSET 0x20000 +#define RB_ROOTFS_SIZE 0x9e0000 +#define RB_KERNEL_OFFSET 0xa00000 +#define RB_KERNEL_SIZE MTDPART_SIZ_FULL + +void __init rb941_wlan_init(void) +{ + char *art_buf; + u8 wlan_mac[ETH_ALEN]; + + art_buf = rb_get_wlan_data(); + if (art_buf == NULL) + return; + + ath79_init_mac(wlan_mac, ath79_mac_base, 11); + ath79_register_wmac(art_buf + 0x1000, wlan_mac); + + kfree(art_buf); +} + +static struct mtd_partition rb941_spi_partitions[] = { + { + .name = "routerboot", + .offset = RB_ROUTERBOOT_OFFSET, + .mask_flags = MTD_WRITEABLE, + .size = RB_ROUTERBOOT_SIZE, + }, { + .name = "hard_config", + .offset = RB_HARD_CFG_OFFSET, + .size = RB_HARD_CFG_SIZE, + .mask_flags = MTD_WRITEABLE, + }, { + .name = "bios", + .offset = RB_BIOS_OFFSET, + .size = RB_BIOS_SIZE, + .mask_flags = MTD_WRITEABLE, + }, { + .name = "routerboot2", + .offset = RB_ROUTERBOOT2_OFFSET, + .size = RB_ROUTERBOOT2_SIZE, + .mask_flags = MTD_WRITEABLE, + }, { + .name = "soft_config", + .offset = RB_SOFT_CFG_OFFSET, + .size = RB_SOFT_CFG_SIZE, + .mask_flags = MTD_WRITEABLE, + }, { + .name = "rootfs", + .offset = RB_ROOTFS_OFFSET, + .size = RB_ROOTFS_SIZE, + }, { + .name = "kernel", + .offset = RB_KERNEL_OFFSET, + .size = RB_KERNEL_SIZE, + } +}; + +static struct flash_platform_data rb941_spi_flash_data = { + .parts = rb941_spi_partitions, + .nr_parts = ARRAY_SIZE(rb941_spi_partitions), +}; + +static struct gpio_led rb941_leds[] __initdata = { + { + .name = "rb:green:act", + .gpio = RB941_GPIO_LED_ACT, + .active_low = 1, + }, +}; + +static struct gpio_keys_button rb941_gpio_keys[] __initdata = { + { + .desc = "Reset button", + .type = EV_KEY, + .code = KEY_RESTART, + .debounce_interval = RB941_KEYS_DEBOUNCE_INTERVAL, + .gpio = RB941_GPIO_BTN_RESET, + .active_low = 1, + }, +}; + +static void __init rb941_setup(void) +{ + const struct rb_info *info; + //try to get rb_info data + info = rb_init_info((void *)(KSEG1ADDR(AR71XX_SPI_BASE)), 0x20000); + if (!info){ + pr_err("%s: Can't get rb_info data from flash!\n", __func__); + //return -EINVAL; //Not critical ... continue! + } + ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_SW_ONLY_MODE); + ath79_register_m25p80(&rb941_spi_flash_data); + ath79_register_mdio(0, 0x0); + + /* WAN. We have no WAN. Only LAN. */ + /*ath79_switch_data.phy4_mii_en = 1; + ath79_switch_data.phy_poll_mask = BIT(4); + ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_MII; + ath79_eth0_data.phy_mask = BIT(4); + ath79_init_mac(ath79_eth0_data.mac_addr, ath79_mac_base, 0); + ath79_register_eth(0); */ + + /* LAN */ + ath79_init_mac(ath79_eth1_data.mac_addr, ath79_mac_base, 0); + ath79_eth1_data.phy_if_mode = PHY_INTERFACE_MODE_GMII; + ath79_register_eth(1); + + //ath79_register_usb(); + + rb941_wlan_init(); + + ath79_register_leds_gpio(-1, ARRAY_SIZE(rb941_leds), rb941_leds); + ath79_register_gpio_keys_polled(-1, RB941_KEYS_POLL_INTERVAL, + ARRAY_SIZE(rb941_gpio_keys), + rb941_gpio_keys); +} + +MIPS_MACHINE(ATH79_MACH_RB_941, "H951L", "MikroTik RouterBOARD 941-2nD", rb941_setup); diff --git a/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h b/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h index 4879255..061bd89 100644 --- a/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h +++ b/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h @@ -139,6 +139,7 @@ enum ath79_mach_type { ATH79_MACH_RB_751, /* MikroTik RouterBOARD 751 */ ATH79_MACH_RB_751G, /* Mikrotik RouterBOARD 751G */ ATH79_MACH_RB_922GS, /* Mikrotik RouterBOARD 911/922GS boards */ + ATH79_MACH_RB_941, /* MikroTik RouterBOARD 941-2nD */ ATH79_MACH_RB_951G, /* Mikrotik RouterBOARD 951G */ ATH79_MACH_RB_951U, /* Mikrotik RouterBOARD 951Ui-2HnD */ ATH79_MACH_RB_2011G, /* Mikrotik RouterBOARD 2011UAS-2HnD */ diff --git a/target/linux/ar71xx/image/Makefile b/target/linux/ar71xx/image/Makefile index bc8a4a8..20a0f7e 100644 --- a/target/linux/ar71xx/image/Makefile +++ b/target/linux/ar71xx/image/Makefile @@ -2593,6 +2593,29 @@ $(eval $(call SingleProfile,ZyXELNAND,128k,NBG6716,nbg6716,NBG6716,ttyS0,115200, $(eval $(call MultiProfile,WNDR4300,WNDR3700V4 WNDR4300V1)) endif # ifeq ($(SUBTARGET),nand) +ifeq ($(SUBTARGET),mikrotik) + +define Device/rb-nor-flash-16M + DEVICE_PROFILE := MikrotikDefault MikrotikNorFlash + BLOCKSIZE := 64k + IMAGE_SIZE := 16000k + KERNEL2MINOR_ARGS := -s 1024 -e + LOADER_TYPE := elf + KERNEL_INSTALL := 1 + KERNEL := kernel-bin | lzma | loader-kernel | kernel2minor $$(KERNEL2MINOR_ARGS) + KERNEL_INITRAMFS := kernel-bin | lzma | loader-kernel + IMAGES := sysupgrade.bin + IMAGE/sysupgrade.bin = append-rootfs | pad-rootfs | combined-image | check-size $$$$(IMAGE_SIZE) +endef + +define Device/rb-941-2nd +$(Device/rb-nor-flash-16M) + BOARDNAME: = rb-941-2nd +endef +TARGET_DEVICES += rb-941-2nd + +endif # ifeq ($(SUBTARGET),mikrotik) + $(eval $(call MultiProfile,Default,$(SINGLE_PROFILES))) diff --git a/target/linux/ar71xx/mikrotik/config-default b/target/linux/ar71xx/mikrotik/config-default index 094f2ae..9abca55 100644 --- a/target/linux/ar71xx/mikrotik/config-default +++ b/target/linux/ar71xx/mikrotik/config-default @@ -69,6 +69,7 @@ CONFIG_ATH79_MACH_RB4XX=y CONFIG_ATH79_MACH_RB750=y CONFIG_ATH79_MACH_RB91X=y CONFIG_ATH79_MACH_RB922=y +CONFIG_ATH79_MACH_RB941=y CONFIG_ATH79_MACH_RB95X=y CONFIG_ATH79_MACH_RBSXTLITE=y # CONFIG_ATH79_MACH_RW2458N is not set @@ -134,7 +135,6 @@ CONFIG_ATH79_ROUTERBOOT=y CONFIG_CMDLINE="rootfstype=yaffs noinitrd" CONFIG_GPIO_74X164=y CONFIG_GPIO_LATCH=y -# CONFIG_JFFS2_FS is not set CONFIG_LEDS_RB750=y CONFIG_LZO_DECOMPRESS=y CONFIG_MDIO_BITBANG=y @@ -151,16 +151,13 @@ CONFIG_MTD_NAND_RB4XX=y CONFIG_MTD_NAND_RB750=y CONFIG_MTD_NAND_RB91X=y # CONFIG_MTD_REDBOOT_PARTS is not set -CONFIG_MTD_SPI_NOR_USE_4K_SECTORS=y # CONFIG_MTD_TPLINK_PARTS is not set -# CONFIG_OVERLAY_FS is not set CONFIG_RLE_DECOMPRESS=y # CONFIG_SOC_AR913X is not set # CONFIG_SOC_AR933X is not set # CONFIG_SOC_QCA953X is not set CONFIG_SPI_RB4XX=y CONFIG_SPI_RB4XX_CPLD=y -# CONFIG_SQUASHFS is not set CONFIG_YAFFS_9BYTE_TAGS=y CONFIG_YAFFS_ALWAYS_CHECK_CHUNK_ERASED=y CONFIG_YAFFS_AUTO_YAFFS2=y diff --git a/target/linux/ar71xx/mikrotik/profiles/00-mikrotik-default.mk b/target/linux/ar71xx/mikrotik/profiles/00-mikrotik-default.mk new file mode 100644 index 0000000..d1e4646 --- /dev/null +++ b/target/linux/ar71xx/mikrotik/profiles/00-mikrotik-default.mk @@ -0,0 +1,16 @@ +# +# Copyright (C) 2009 OpenWrt.org +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# + +define Profile/MikrotikDefault + NAME:=Default Profile (all drivers + WiFi) + PACKAGES:=kmod-ath5k kmod-ath9k +endef + +define Profile/MikrotikDefault/Description + Default package set compatible with most Mikrotik's boards with Atheros WiFi cards. +endef +$(eval $(call Profile,MikrotikDefault)) diff --git a/target/linux/ar71xx/mikrotik/profiles/01-minimal.mk b/target/linux/ar71xx/mikrotik/profiles/01-minimal.mk index 3651c88..ff5d29c 100644 --- a/target/linux/ar71xx/mikrotik/profiles/01-minimal.mk +++ b/target/linux/ar71xx/mikrotik/profiles/01-minimal.mk @@ -5,12 +5,12 @@ # See /LICENSE for more information. # -define Profile/DefaultNoWifi - NAME:=Default Profile (no WiFi) +define Profile/MikrotikMinimal + NAME:=Minimal Profile (no drivers) PACKAGES:= endef -define Profile/DefaultNoWifi/Description - Default package set compatible with most boards. +define Profile/MikrotikMinimal/Description + Minimal package set compatible with most boards. endef -$(eval $(call Profile,DefaultNoWifi)) +$(eval $(call Profile,MikrotikMinimal)) diff --git a/target/linux/ar71xx/mikrotik/profiles/03-norflash.mk b/target/linux/ar71xx/mikrotik/profiles/03-norflash.mk new file mode 100644 index 0000000..aa5c891 --- /dev/null +++ b/target/linux/ar71xx/mikrotik/profiles/03-norflash.mk @@ -0,0 +1,16 @@ +# +# Copyright (C) 2009 OpenWrt.org +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# + +define Profile/MikrotikNorFlash + NAME:=NorFlash Profile + PACKAGES:=kmod-ath9k +endef + +define Profile/MikrotikNorFlash/Description + Package set optimized for the Mikrotik's boards with single NOR flash(16MB or more). +endef +$(eval $(call Profile,MikrotikNorFlash)) -- 1.9.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From kron at animeland.de Sun May 15 09:44:33 2016 From: kron at animeland.de (Sebastian Ortwein) Date: Sun, 15 May 2016 15:44:33 +0200 Subject: [OpenWrt-Devel] Add support for AVM Fritzbox 7360 SL In-Reply-To: References: <69086bb8-44aa-05e4-a550-ee1b13633b4a@animeland.de> <572E254E.4030409@gmail.com> <44031fa7-cb40-d37c-79bd-f338bfba8b68@animeland.de> <93a04c66-d6a4-1c5f-d16c-80db337b6d3c@animeland.de> Message-ID: <2d877322-9bf3-7144-3620-589f652f75ef@animeland.de> Am 08.05.2016 um 18:40 schrieb Martin Blumenstingl: > On Sun, May 8, 2016 at 5:49 PM, Sebastian Ortwein wrote: >> can I add it the following way ? >> mdio at 0 { >> #address-cells = <1>; >> #size-cells = <0>; >> compatible = "lantiq,xrx200-mdio"; >> phy0: ethernet-phy at 0 { >> reg = <0x0>; >> compatible = "lantiq,phy11g", >> "ethernet-phy-ieee802.3-c22"; >> gpios = <&gpio 37 0>; >> }; >> phy1: ethernet-phy at 1 { >> reg = <0x1>; >> compatible = "lantiq,phy11g", >> "ethernet-phy-ieee802.3-c22"; >> gpios = <&gpio 44 0>; >> }; >> phy11: ethernet-phy at 11 { >> reg = <0x11>; >> compatible = "lantiq,phy11g", >> "ethernet-phy-ieee802.3-c22"; >> }; >> phy13: ethernet-phy at 13 { >> reg = <0x13>; >> compatible = "lantiq,phy11g", >> "ethernet-phy-ieee802.3-c22"; >> }; > I think you have to name the property "reset-gpios", but apart from > that it looks good. I have try it like you sayed. But without success. I think the gpios are defined here, but it won't working. phy-rst { lantiq,pins = "io37", "io44"; lantiq,pull = <0>; lantiq,open-drain = <0>; lantiq,output = <1>; }; >>> I cannot see any ath9k messages in your kernel log - are you sure it's >>> being installed (/lib/modules/*/ath9k.ko)? >>> Your first patch lists kmod-ath9k, but if you added that after you >>> generated your .config then you're probably still missing it. >>> Please check "grep kmod-ath9k .config" and enable (set it to >>> =y/built-in) it if it's missing. >> I have not disable the ath9k driver. it is present and loaded. > I think I see the problem after looking at your .dts again: > you *must* specify the ath,pci-slot property, otherwise the fixup is > not executed. > It seems that the wifi part is similar to the TD-W8980 (AR9287 behind > the PCIe-to-PCI bridge), so "0" should be the right value. > (otherwise it's pretty easy to find out by looking at sysfs: > /sys/bus/pci/devices/0000\:00\:0e.0/ -> that's where the ath9k device > on HH5A can be found, there we use ath,pci-slot = <0xe>;) > > > Martin > > > [0] https://github.com/openwrt/openwrt/blob/master/target/linux/lantiq/patches-4.4/0035-owrt-lantiq-wifi-and-ethernet-eeprom-handling.patch#L178 USB, WLAN and LAN works now. The only think what would not work is phy0 & phy1. I have attached my lastet patch. dmesg [ 0.000000] Linux version 4.4.7 (sebastian at sebastian-desktop) (gcc version 5.3.0 (OpenWrt GCC 5.3.0 r49377) ) #1 Sun May 15 13:18:03 UTC 2016 [ 0.000000] SoC: xRX200 rev 1.1 [ 0.000000] bootconsole [early0] enabled [ 0.000000] CPU0 revision is: 00019555 (MIPS 34Kc) [ 0.000000] MIPS: machine is FRITZ7360SL - 1&1 HomeServer [ 0.000000] Determined physical RAM map: [ 0.000000] memory: 08000000 @ 00000000 (usable) [ 0.000000] Initrd not found or empty - disabling initrd [ 0.000000] Zone ranges: [ 0.000000] Normal [mem 0x0000000000000000-0x0000000007ffffff] [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000000000000000-0x0000000007ffffff] [ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff] [ 0.000000] On node 0 totalpages: 32768 [ 0.000000] free_area_init_node: node 0, pgdat 804d6390, node_mem_map 81007b60 [ 0.000000] Normal zone: 256 pages used for memmap [ 0.000000] Normal zone: 0 pages reserved [ 0.000000] Normal zone: 32768 pages, LIFO batch:7 [ 0.000000] Primary instruction cache 32kB, VIPT, 4-way, linesize 32 bytes. [ 0.000000] Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 bytes [ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [ 0.000000] pcpu-alloc: [0] 0 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 [ 0.000000] Kernel command line: console=ttyLTQ0,115200 init=/etc/preinit [ 0.000000] PID hash table entries: 512 (order: -1, 2048 bytes) [ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) [ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) [ 0.000000] Writing ErrCtl register=00074200 [ 0.000000] Readback ErrCtl register=00074200 [ 0.000000] Memory: 123372K/131072K available (3764K kernel code, 164K rwdata, 1144K rodata, 1184K init, 211K bss, 7700K reserved, 0K cma-reserved) [ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [ 0.000000] NR_IRQS:256 [ 0.000000] CPU Clock: 500MHz [ 0.000000] clocksource: MIPS: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041786 ns [ 0.000011] sched_clock: 32 bits at 250MHz, resolution 4ns, wraps every 8589934590ns [ 0.007861] Calibrating delay loop... 332.54 BogoMIPS (lpj=665088) [ 0.042318] pid_max: default: 32768 minimum: 301 [ 0.047172] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) [ 0.053732] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes) [ 0.066701] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns [ 0.076483] pinctrl core: initialized pinctrl subsystem [ 0.082366] NET: Registered protocol family 16 [ 0.091505] pinctrl-xway 1e100b10.pinmux: Init done [ 0.097056] dma-xway 1e104100.dma: Init done - hw rev: 7, ports: 7, channels: 28 [ 0.207159] dcdc-xrx200 1f106a00.dcdc: Core Voltage : 1016 mV [ 0.333371] ath9k,eeprom ath9k_eep: failed to load eeprom address [ 0.354429] usbcore: registered new interface driver usbfs [ 0.359938] usbcore: registered new interface driver hub [ 0.365292] usbcore: registered new device driver usb [ 0.370641] PCI host bridge to bus 0000:00 [ 0.374631] pci_bus 0000:00: root bus resource [mem 0x1c000000-0x1cffffff] [ 0.381545] pci_bus 0000:00: root bus resource [io 0x1d800000-0x1d8fffff] [ 0.388488] pci_bus 0000:00: root bus resource [??? 0x00000000 flags 0x0] [ 0.395343] pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff] [ 0.403373] pci 0000:00:00.0: [15d1:0011] type 01 class 0x060000 [ 0.403410] ifx_pcie_rc_class_early_fixup: fixed pcie host bridge to pci-pci bridge [ 0.421054] ifx_pcie_fixup_resource: fixup host controller 0000:00:00.0 (15d1:0011) [ 0.428645] pci 0000:00:00.0: PME# supported from D0 D3hot [ 0.429208] pci 0000:01:00.0: [168c:ff1c] type 00 class 0x020000 [ 0.429298] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x0000ffff 64bit] [ 0.429454] pci 0000:01:00.0: supports D1 [ 0.429475] pci 0000:01:00.0: PME# supported from D0 D1 D3hot [ 0.429773] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01 [ 0.429814] pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 01 [ 0.429870] pci 0000:00:00.0: BAR 8: assigned [mem 0x1c000000-0x1c0fffff] [ 0.436557] pci 0000:01:00.0: BAR 0: assigned [mem 0x1c000000-0x1c00ffff 64bit] [ 0.443919] pci 0000:00:00.0: PCI bridge to [bus 01] [ 0.448935] pci 0000:00:00.0: bridge window [mem 0x1c000000-0x1c0fffff] [ 0.455810] ifx_pcie_bios_map_irq port 0 dev 0000:00:00.0 slot 0 pin 1 [ 0.462461] ifx_pcie_bios_map_irq dev 0000:00:00.0 irq 144 assigned [ 0.468815] ifx_pcie_bios_map_irq port 0 dev 0000:01:00.0 slot 0 pin 1 [ 0.475481] ifx_pcie_bios_map_irq dev 0000:01:00.0 irq 144 assigned [ 0.482864] clocksource: Switched to clocksource MIPS [ 0.489513] NET: Registered protocol family 2 [ 0.494738] TCP established hash table entries: 1024 (order: 0, 4096 bytes) [ 0.501634] TCP bind hash table entries: 1024 (order: 0, 4096 bytes) [ 0.508012] TCP: Hash tables configured (established 1024 bind 1024) [ 0.514529] UDP hash table entries: 256 (order: 0, 4096 bytes) [ 0.520367] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) [ 0.526969] NET: Registered protocol family 1 [ 0.531315] PCI: CLS 0 bytes, default 32 [ 0.531770] gptu: totally 6 16-bit timers/counters [ 0.536615] gptu: misc_register on minor 63 [ 0.540712] gptu: succeeded to request irq 126 [ 0.545201] gptu: succeeded to request irq 127 [ 0.549715] gptu: succeeded to request irq 128 [ 0.554229] gptu: succeeded to request irq 129 [ 0.558742] gptu: succeeded to request irq 130 [ 0.563259] gptu: succeeded to request irq 131 [ 0.568633] phy-xrx200 gphy-xrx200: requesting lantiq/vr9_phy11g_a1x.bin [ 0.575912] phy-xrx200 gphy-xrx200: booting GPHY0 firmware at 7960000 [ 0.582260] phy-xrx200 gphy-xrx200: booting GPHY1 firmware at 7960000 [ 0.689806] futex hash table entries: 256 (order: -1, 3072 bytes) [ 0.723154] squashfs: version 4.0 (2009/01/31) Phillip Lougher [ 0.728894] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc. [ 0.742291] io scheduler noop registered [ 0.746134] io scheduler deadline registered (default) [ 0.751978] 1e100c00.serial: ttyLTQ0 at MMIO 0x1e100c00 (irq = 112, base_baud = 0) is a lantiq,asc [ 0.760881] console [ttyLTQ0] enabled [ 0.768206] bootconsole [early0] disabled [ 0.777268] lantiq nor flash device: 01000000 at 10000000 [ 0.781402] ltq_nor: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0x000001 Chip ID 0x002101 [ 0.790840] Amd/Fujitsu Extended Query Table at 0x0040 [ 0.795967] Amd/Fujitsu Extended Query version 1.3. [ 0.801004] number of CFI chips: 1 [ 0.804436] 4 ofpart partitions found on MTD device ltq_nor [ 0.809969] Creating 4 MTD partitions on "ltq_nor": [ 0.814852] 0x000000000000-0x000000020000 : "urlader" [ 0.823305] 0x000000020000-0x000000f80000 : "firmware" [ 0.844284] 2 eva-fw partitions found on MTD device firmware [ 0.848534] 0x000000020000-0x0000001bfa70 : "kernel" [ 0.855348] 0x0000001c0100-0x000000f80000 : "rootfs" [ 0.860994] mtd: device 3 (rootfs) set to be root filesystem [ 0.865302] 1 squashfs-split partitions found on MTD device rootfs [ 0.871420] 0x0000003e0000-0x000000f80000 : "rootfs_data" [ 0.879057] 0x000000f80000-0x000000fc0000 : "tffs (1)" [ 0.884936] 0x000000fc0000-0x000001000000 : "tffs (2)" [ 0.993675] libphy: lantiq,xrx200-mdio: probed [ 1.004257] eth0: attached PHY [Generic PHY] (phy_addr=0:00, irq=-1) [ 1.009606] eth0: attached PHY [Generic PHY] (phy_addr=0:01, irq=-1) [ 1.079564] eth0: attached PHY [Lantiq XWAY VR9 GPHY 11G v1.4] (phy_addr=0:11, irq=-1) [ 1.147555] eth0: attached PHY [Lantiq XWAY VR9 GPHY 11G v1.4] (phy_addr=0:13, irq=-1) [ 1.155438] wdt 1f8803f0.watchdog: Init done [ 1.161244] NET: Registered protocol family 10 [ 1.169748] NET: Registered protocol family 17 [ 1.172899] bridge: automatic filtering via arp/ip/ip6tables has been deprecated. Update your scripts to load br_netfilter if you need this. [ 1.185425] 8021q: 802.1Q VLAN Support v1.8 [ 1.189680] found entry name -> annex=B [ 1.193440] found entry name -> maca=BC:05:43:D7:1E:7C [ 1.198534] found entry name -> macb=BC:05:43:D7:1E:7D [ 1.203673] found entry name -> macwlan=BC:05:43:D7:1E:7E [ 1.209066] found entry name -> macdsl=BC:05:43:D7:1E:7F [ 1.214430] found entry name -> macwlan2=BC:05:43:D7:1E:81 [ 1.219861] found entry name -> wlan_key=4004584479108575 [ 1.228307] ath9k,eeprom ath9k_eep: endian check enabled. [ 1.232282] ath9k,eeprom ath9k_eep: using random mac [ 1.237274] ath9k,eeprom ath9k_eep: pci slot: 0 [ 1.241777] pci 0000:01:00.0: fixup device configuration [ 1.247149] PCI: Enabling device 0000:01:00.0 (0000 -> 0002) [ 1.254428] pci 0000:01:00.0: fixup info: [168c:002e] revision 01 class 0x028000 [ 1.260435] ath9k,eeprom ath9k_eep: loaded ath9k eeprom [ 1.270378] UBIFS error (pid: 1): cannot open "ubi0:rootfs", error -19 [ 1.280211] VFS: Mounted root (squashfs filesystem) readonly on device 31:3. [ 1.287767] Freeing unused kernel memory: 1184K (804f8000 - 80620000) [ 2.468013] init: Console is alive [ 2.470263] init: - watchdog - [ 3.884244] dwc2 1e101000.ifxhcd: Configuration mismatch. Forcing host mode [ 4.035028] eth0: port 0 got link [ 4.747073] dwc2 1e101000.ifxhcd: DWC OTG Controller [ 4.750648] dwc2 1e101000.ifxhcd: new USB bus registered, assigned bus number 1 [ 4.757999] dwc2 1e101000.ifxhcd: irq 62, io mem 0x00000000 [ 4.763516] dwc2 1e101000.ifxhcd: Hardware does not support descriptor DMA mode - [ 4.770953] dwc2 1e101000.ifxhcd: falling back to buffer DMA mode. [ 4.778435] hub 1-0:1.0: USB hub found [ 4.781398] hub 1-0:1.0: 1 port detected [ 4.785460] dwc2 1e106000.ifxhcd: Configuration mismatch. Forcing host mode [ 5.647060] dwc2 1e106000.ifxhcd: DWC OTG Controller [ 5.650655] dwc2 1e106000.ifxhcd: new USB bus registered, assigned bus number 2 [ 5.657970] dwc2 1e106000.ifxhcd: irq 91, io mem 0x00000000 [ 5.663499] dwc2 1e106000.ifxhcd: Hardware does not support descriptor DMA mode - [ 5.670938] dwc2 1e106000.ifxhcd: falling back to buffer DMA mode. [ 5.678440] hub 2-0:1.0: USB hub found [ 5.681390] hub 2-0:1.0: 1 port detected [ 5.687615] init: - preinit - [ 6.192804] random: procd urandom read with 26 bits of entropy available [ 8.569614] jffs2: notice: (370) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found. [ 8.585353] mount_root: switching to jffs2 overlay [ 8.606254] procd: - early - [ 8.607917] procd: - watchdog - [ 9.348938] procd: - ubus - [ 9.403903] procd: - init - [ 10.231370] IFXOS, Version 1.5.19 (c) Copyright 2009, Lantiq Deutschland GmbH [ 10.241461] NET: Registered protocol family 8 [ 10.244431] NET: Registered protocol family 20 [ 10.255629] PPP generic driver version 2.4.2 [ 10.266429] ip6_tables: (C) 2000-2006 Netfilter Core Team [ 10.291707] Lantiq (VRX) DSL CPE MEI driver, version 1.4.8.5, (c) 2013 Lantiq Deutschland GmbH [ 10.291707] [ 10.291707] Lantiq CPE API Driver version: DSL CPE API V4.16.6.3 [ 10.312794] [ 10.312794] Predefined debug level: 3 [ 10.323452] Loading modules backported from Linux version v4.4-rc5-1913-gc8fdf68 [ 10.329464] Backport generated by backports.git backports-20151218-0-g2f58d9d [ 10.340031] ip_tables: (C) 2000-2006 Netfilter Core Team [ 10.351117] Infineon Technologies DEU driver version 2.0.0 [ 10.357203] IFX DEU DES initialized (multiblock). [ 10.361497] IFX DEU AES initialized (multiblock). [ 10.365620] IFX DEU ARC4 initialized (multiblock). [ 10.370239] IFX DEU SHA1 initialized. [ 10.373843] IFX DEU MD5 initialized. [ 10.377438] IFX DEU SHA1_HMAC initialized. [ 10.381556] IFX DEU MD5_HMAC initialized. [ 10.391907] nf_conntrack version 0.5.0 (1946 buckets, 7784 max) [ 10.418114] NET: Registered protocol family 24 [ 10.443723] xt_time: kernel timezone is -0000 [ 10.539595] PCI: Enabling device 0000:01:00.0 (0140 -> 0142) [ 10.550629] ath: EEPROM regdomain: 0x8114 [ 10.550653] ath: EEPROM indicates we should expect a country code [ 10.550667] ath: doing EEPROM country->regdmn map search [ 10.550679] ath: country maps to regdmn code: 0x37 [ 10.550692] ath: Country alpha2 being used: DE [ 10.550704] ath: Regpair used: 0x37 [ 10.564122] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' [ 10.567111] ieee80211 phy0: Atheros AR9287 Rev:2 mem=0xbc000000, irq=144 [ 19.477228] device eth0.1 entered promiscuous mode [ 19.480651] device eth0 entered promiscuous mode [ 19.500394] br-lan: port 1(eth0.1) entered forwarding state [ 19.504638] br-lan: port 1(eth0.1) entered forwarding state [ 21.506873] br-lan: port 1(eth0.1) entered forwarding state [ 31.802908] random: nonblocking pool is initialized logread hu May 12 05:36:24 2016 kern.info kernel: [ 0.381545] pci_bus 0000:00: root bus resource [io 0x1d800000-0x1d8fffff] Thu May 12 05:36:24 2016 kern.info kernel: [ 0.388488] pci_bus 0000:00: root bus resource [??? 0x00000000 flags 0x0] Thu May 12 05:36:24 2016 kern.info kernel: [ 0.395343] pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff] Thu May 12 05:36:24 2016 kern.debug kernel: [ 0.403373] pci 0000:00:00.0: [15d1:0011] type 01 class 0x060000 Thu May 12 05:36:24 2016 kern.info kernel: [ 0.403410] ifx_pcie_rc_class_early_fixup: fixed pcie host bridge to pci-pci bridge Thu May 12 05:36:24 2016 kern.warn kernel: [ 0.421054] ifx_pcie_fixup_resource: fixup host controller 0000:00:00.0 (15d1:0011) Thu May 12 05:36:24 2016 kern.debug kernel: [ 0.428645] pci 0000:00:00.0: PME# supported from D0 D3hot Thu May 12 05:36:24 2016 kern.debug kernel: [ 0.429208] pci 0000:01:00.0: [168c:ff1c] type 00 class 0x020000 Thu May 12 05:36:24 2016 kern.debug kernel: [ 0.429298] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x0000ffff 64bit] Thu May 12 05:36:24 2016 kern.debug kernel: [ 0.429454] pci 0000:01:00.0: supports D1 Thu May 12 05:36:24 2016 kern.debug kernel: [ 0.429475] pci 0000:01:00.0: PME# supported from D0 D1 D3hot Thu May 12 05:36:24 2016 kern.debug kernel: [ 0.429773] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01 Thu May 12 05:36:24 2016 kern.debug kernel: [ 0.429814] pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 01 Thu May 12 05:36:24 2016 kern.info kernel: [ 0.429870] pci 0000:00:00.0: BAR 8: assigned [mem 0x1c000000-0x1c0fffff] Thu May 12 05:36:24 2016 kern.info kernel: [ 0.436557] pci 0000:01:00.0: BAR 0: assigned [mem 0x1c000000-0x1c00ffff 64bit] Thu May 12 05:36:24 2016 kern.info kernel: [ 0.443919] pci 0000:00:00.0: PCI bridge to [bus 01] Thu May 12 05:36:24 2016 kern.info kernel: [ 0.448935] pci 0000:00:00.0: bridge window [mem 0x1c000000-0x1c0fffff] Thu May 12 05:36:24 2016 kern.warn kernel: [ 0.455810] ifx_pcie_bios_map_irq port 0 dev 0000:00:00.0 slot 0 pin 1 Thu May 12 05:36:24 2016 kern.warn kernel: [ 0.462461] ifx_pcie_bios_map_irq dev 0000:00:00.0 irq 144 assigned Thu May 12 05:36:24 2016 kern.warn kernel: [ 0.468815] ifx_pcie_bios_map_irq port 0 dev 0000:01:00.0 slot 0 pin 1 Thu May 12 05:36:24 2016 kern.warn kernel: [ 0.475481] ifx_pcie_bios_map_irq dev 0000:01:00.0 irq 144 assigned Thu May 12 05:36:24 2016 kern.info kernel: [ 0.482864] clocksource: Switched to clocksource MIPS Thu May 12 05:36:24 2016 kern.info kernel: [ 0.489513] NET: Registered protocol family 2 Thu May 12 05:36:24 2016 kern.info kernel: [ 0.494738] TCP established hash table entries: 1024 (order: 0, 4096 bytes) Thu May 12 05:36:24 2016 kern.info kernel: [ 0.501634] TCP bind hash table entries: 1024 (order: 0, 4096 bytes) Thu May 12 05:36:24 2016 kern.info kernel: [ 0.508012] TCP: Hash tables configured (established 1024 bind 1024) Thu May 12 05:36:24 2016 kern.info kernel: [ 0.514529] UDP hash table entries: 256 (order: 0, 4096 bytes) Thu May 12 05:36:24 2016 kern.info kernel: [ 0.520367] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) Thu May 12 05:36:24 2016 kern.info kernel: [ 0.526969] NET: Registered protocol family 1 Thu May 12 05:36:24 2016 kern.debug kernel: [ 0.531315] PCI: CLS 0 bytes, default 32 Thu May 12 05:36:24 2016 kern.info kernel: [ 0.531770] gptu: totally 6 16-bit timers/counters Thu May 12 05:36:24 2016 kern.info kernel: [ 0.536615] gptu: misc_register on minor 63 Thu May 12 05:36:24 2016 kern.info kernel: [ 0.540712] gptu: succeeded to request irq 126 Thu May 12 05:36:24 2016 kern.info kernel: [ 0.545201] gptu: succeeded to request irq 127 Thu May 12 05:36:24 2016 kern.info kernel: [ 0.549715] gptu: succeeded to request irq 128 Thu May 12 05:36:24 2016 kern.info kernel: [ 0.554229] gptu: succeeded to request irq 129 Thu May 12 05:36:24 2016 kern.info kernel: [ 0.558742] gptu: succeeded to request irq 130 Thu May 12 05:36:24 2016 kern.info kernel: [ 0.563259] gptu: succeeded to request irq 131 Thu May 12 05:36:24 2016 kern.info kernel: [ 0.568633] phy-xrx200 gphy-xrx200: requesting lantiq/vr9_phy11g_a1x.bin Thu May 12 05:36:24 2016 kern.info kernel: [ 0.575912] phy-xrx200 gphy-xrx200: booting GPHY0 firmware at 7960000 Thu May 12 05:36:24 2016 kern.info kernel: [ 0.582260] phy-xrx200 gphy-xrx200: booting GPHY1 firmware at 7960000 Thu May 12 05:36:24 2016 kern.info kernel: [ 0.689806] futex hash table entries: 256 (order: -1, 3072 bytes) Thu May 12 05:36:24 2016 kern.info kernel: [ 0.723154] squashfs: version 4.0 (2009/01/31) Phillip Lougher Thu May 12 05:36:24 2016 kern.info kernel: [ 0.728894] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc. Thu May 12 05:36:24 2016 kern.info kernel: [ 0.742291] io scheduler noop registered Thu May 12 05:36:24 2016 kern.info kernel: [ 0.746134] io scheduler deadline registered (default) Thu May 12 05:36:24 2016 kern.info kernel: [ 0.751978] 1e100c00.serial: ttyLTQ0 at MMIO 0x1e100c00 (irq = 112, base_baud = 0) is a lantiq,asc Thu May 12 05:36:24 2016 kern.info kernel: [ 0.760881] console [ttyLTQ0] enabled Thu May 12 05:36:24 2016 kern.info kernel: [ 0.768206] bootconsole [early0] disabled Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.777268] lantiq nor flash device: 01000000 at 10000000 Thu May 12 05:36:24 2016 kern.info kernel: [ 0.781402] ltq_nor: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0x000001 Chip ID 0x002101 Thu May 12 05:36:24 2016 kern.info kernel: [ 0.790840] Amd/Fujitsu Extended Query Table at 0x0040 Thu May 12 05:36:24 2016 kern.info kernel: [ 0.795967] Amd/Fujitsu Extended Query version 1.3. Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.801004] number of CFI chips: 1 Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.804436] 4 ofpart partitions found on MTD device ltq_nor Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.809969] Creating 4 MTD partitions on "ltq_nor": Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.814852] 0x000000000000-0x000000020000 : "urlader" Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.823305] 0x000000020000-0x000000f80000 : "firmware" Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.844284] 2 eva-fw partitions found on MTD device firmware Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.848534] 0x000000020000-0x0000001bfa70 : "kernel" Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.855348] 0x0000001c0100-0x000000f80000 : "rootfs" Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.860994] mtd: device 3 (rootfs) set to be root filesystem Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.865302] 1 squashfs-split partitions found on MTD device rootfs Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.871420] 0x0000003e0000-0x000000f80000 : "rootfs_data" Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.879057] 0x000000f80000-0x000000fc0000 : "tffs (1)" Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.884936] 0x000000fc0000-0x000001000000 : "tffs (2)" Thu May 12 05:36:24 2016 kern.info kernel: [ 0.993675] libphy: lantiq,xrx200-mdio: probed Thu May 12 05:36:24 2016 kern.info kernel: [ 1.004257] eth0: attached PHY [Generic PHY] (phy_addr=0:00, irq=-1) Thu May 12 05:36:24 2016 kern.info kernel: [ 1.009606] eth0: attached PHY [Generic PHY] (phy_addr=0:01, irq=-1) Thu May 12 05:36:24 2016 kern.info kernel: [ 1.079564] eth0: attached PHY [Lantiq XWAY VR9 GPHY 11G v1.4] (phy_addr=0:11, irq=-1) Thu May 12 05:36:24 2016 kern.info kernel: [ 1.147555] eth0: attached PHY [Lantiq XWAY VR9 GPHY 11G v1.4] (phy_addr=0:13, irq=-1) Thu May 12 05:36:24 2016 kern.info kernel: [ 1.155438] wdt 1f8803f0.watchdog: Init done Thu May 12 05:36:24 2016 kern.info kernel: [ 1.161244] NET: Registered protocol family 10 Thu May 12 05:36:24 2016 kern.info kernel: [ 1.169748] NET: Registered protocol family 17 Thu May 12 05:36:24 2016 kern.info kernel: [ 1.172899] bridge: automatic filtering via arp/ip/ip6tables has been deprecated. Update your scripts to load br_netfilter if you need this. Thu May 12 05:36:24 2016 kern.info kernel: [ 1.185425] 8021q: 802.1Q VLAN Support v1.8 Thu May 12 05:36:24 2016 kern.info kernel: [ 1.189680] found entry name -> annex=B Thu May 12 05:36:24 2016 kern.info kernel: [ 1.193440] found entry name -> maca=BC:05:43:D7:1E:7C Thu May 12 05:36:24 2016 kern.info kernel: [ 1.198534] found entry name -> macb=BC:05:43:D7:1E:7D Thu May 12 05:36:24 2016 kern.info kernel: [ 1.203673] found entry name -> macwlan=BC:05:43:D7:1E:7E Thu May 12 05:36:24 2016 kern.info kernel: [ 1.209066] found entry name -> macdsl=BC:05:43:D7:1E:7F Thu May 12 05:36:24 2016 kern.info kernel: [ 1.214430] found entry name -> macwlan2=BC:05:43:D7:1E:81 Thu May 12 05:36:24 2016 kern.info kernel: [ 1.219861] found entry name -> wlan_key=4004584479108575 Thu May 12 05:36:24 2016 kern.info kernel: [ 1.228307] ath9k,eeprom ath9k_eep: endian check enabled. Thu May 12 05:36:24 2016 kern.warn kernel: [ 1.232282] ath9k,eeprom ath9k_eep: using random mac Thu May 12 05:36:24 2016 kern.info kernel: [ 1.237274] ath9k,eeprom ath9k_eep: pci slot: 0 Thu May 12 05:36:24 2016 kern.info kernel: [ 1.241777] pci 0000:01:00.0: fixup device configuration Thu May 12 05:36:24 2016 kern.warn kernel: [ 1.247149] PCI: Enabling device 0000:01:00.0 (0000 -> 0002) Thu May 12 05:36:24 2016 kern.info kernel: [ 1.254428] pci 0000:01:00.0: fixup info: [168c:002e] revision 01 class 0x028000 Thu May 12 05:36:24 2016 kern.info kernel: [ 1.260435] ath9k,eeprom ath9k_eep: loaded ath9k eeprom Thu May 12 05:36:24 2016 kern.err kernel: [ 1.270378] UBIFS error (pid: 1): cannot open "ubi0:rootfs", error -19 Thu May 12 05:36:24 2016 kern.info kernel: [ 1.280211] VFS: Mounted root (squashfs filesystem) readonly on device 31:3. Thu May 12 05:36:24 2016 kern.info kernel: [ 1.287767] Freeing unused kernel memory: 1184K (804f8000 - 80620000) Thu May 12 05:36:24 2016 user.info kernel: [ 2.468013] init: Console is alive Thu May 12 05:36:24 2016 user.info kernel: [ 2.470263] init: - watchdog - Thu May 12 05:36:24 2016 kern.warn kernel: [ 3.884244] dwc2 1e101000.ifxhcd: Configuration mismatch. Forcing host mode Thu May 12 05:36:24 2016 kern.info kernel: [ 4.035028] eth0: port 0 got link Thu May 12 05:36:24 2016 kern.info kernel: [ 4.747073] dwc2 1e101000.ifxhcd: DWC OTG Controller Thu May 12 05:36:24 2016 kern.info kernel: [ 4.750648] dwc2 1e101000.ifxhcd: new USB bus registered, assigned bus number 1 Thu May 12 05:36:24 2016 kern.info kernel: [ 4.757999] dwc2 1e101000.ifxhcd: irq 62, io mem 0x00000000 Thu May 12 05:36:24 2016 kern.err kernel: [ 4.763516] dwc2 1e101000.ifxhcd: Hardware does not support descriptor DMA mode - Thu May 12 05:36:24 2016 kern.err kernel: [ 4.770953] dwc2 1e101000.ifxhcd: falling back to buffer DMA mode. Thu May 12 05:36:24 2016 kern.info kernel: [ 4.778435] hub 1-0:1.0: USB hub found Thu May 12 05:36:24 2016 kern.info kernel: [ 4.781398] hub 1-0:1.0: 1 port detected Thu May 12 05:36:24 2016 kern.warn kernel: [ 4.785460] dwc2 1e106000.ifxhcd: Configuration mismatch. Forcing host mode Thu May 12 05:36:24 2016 kern.info kernel: [ 5.647060] dwc2 1e106000.ifxhcd: DWC OTG Controller Thu May 12 05:36:24 2016 kern.info kernel: [ 5.650655] dwc2 1e106000.ifxhcd: new USB bus registered, assigned bus number 2 Thu May 12 05:36:24 2016 kern.info kernel: [ 5.657970] dwc2 1e106000.ifxhcd: irq 91, io mem 0x00000000 Thu May 12 05:36:24 2016 kern.err kernel: [ 5.663499] dwc2 1e106000.ifxhcd: Hardware does not support descriptor DMA mode - Thu May 12 05:36:24 2016 kern.err kernel: [ 5.670938] dwc2 1e106000.ifxhcd: falling back to buffer DMA mode. Thu May 12 05:36:24 2016 kern.info kernel: [ 5.678440] hub 2-0:1.0: USB hub found Thu May 12 05:36:24 2016 kern.info kernel: [ 5.681390] hub 2-0:1.0: 1 port detected Thu May 12 05:36:24 2016 user.info kernel: [ 5.687615] init: - preinit - Thu May 12 05:36:24 2016 kern.notice kernel: [ 6.192804] random: procd urandom read with 26 bits of entropy available Thu May 12 05:36:24 2016 kern.notice kernel: [ 8.569614] jffs2: notice: (370) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found. Thu May 12 05:36:24 2016 user.info kernel: [ 8.585353] mount_root: switching to jffs2 overlay Thu May 12 05:36:24 2016 user.info kernel: [ 8.606254] procd: - early - Thu May 12 05:36:24 2016 user.info kernel: [ 8.607917] procd: - watchdog - Thu May 12 05:36:24 2016 user.info kernel: [ 9.348938] procd: - ubus - Thu May 12 05:36:24 2016 user.info kernel: [ 9.403903] procd: - init - Thu May 12 05:36:24 2016 kern.info kernel: [ 10.231370] IFXOS, Version 1.5.19 (c) Copyright 2009, Lantiq Deutschland GmbH Thu May 12 05:36:24 2016 kern.info kernel: [ 10.241461] NET: Registered protocol family 8 Thu May 12 05:36:24 2016 kern.info kernel: [ 10.244431] NET: Registered protocol family 20 Thu May 12 05:36:24 2016 kern.info kernel: [ 10.255629] PPP generic driver version 2.4.2 Thu May 12 05:36:24 2016 kern.info kernel: [ 10.266429] ip6_tables: (C) 2000-2006 Netfilter Core Team Thu May 12 05:36:24 2016 kern.info kernel: [ 10.291707] Lantiq (VRX) DSL CPE MEI driver, version 1.4.8.5, (c) 2013 Lantiq Deutschland GmbH Thu May 12 05:36:24 2016 kern.info kernel: [ 10.291707] Thu May 12 05:36:24 2016 kern.info kernel: [ 10.291707] Lantiq CPE API Driver version: DSL CPE API V4.16.6.3 Thu May 12 05:36:24 2016 kern.warn kernel: [ 10.312794] Thu May 12 05:36:24 2016 kern.warn kernel: [ 10.312794] Predefined debug level: 3 Thu May 12 05:36:24 2016 kern.info kernel: [ 10.323452] Loading modules backported from Linux version v4.4-rc5-1913-gc8fdf68 Thu May 12 05:36:24 2016 kern.info kernel: [ 10.329464] Backport generated by backports.git backports-20151218-0-g2f58d9d Thu May 12 05:36:24 2016 kern.info kernel: [ 10.340031] ip_tables: (C) 2000-2006 Netfilter Core Team Thu May 12 05:36:24 2016 kern.info kernel: [ 10.351117] Infineon Technologies DEU driver version 2.0.0 Thu May 12 05:36:24 2016 kern.notice kernel: [ 10.357203] IFX DEU DES initialized (multiblock). Thu May 12 05:36:24 2016 kern.notice kernel: [ 10.361497] IFX DEU AES initialized (multiblock). Thu May 12 05:36:24 2016 kern.notice kernel: [ 10.365620] IFX DEU ARC4 initialized (multiblock). Thu May 12 05:36:24 2016 kern.notice kernel: [ 10.370239] IFX DEU SHA1 initialized. Thu May 12 05:36:24 2016 kern.notice kernel: [ 10.373843] IFX DEU MD5 initialized. Thu May 12 05:36:24 2016 kern.notice kernel: [ 10.377438] IFX DEU SHA1_HMAC initialized. Thu May 12 05:36:24 2016 kern.notice kernel: [ 10.381556] IFX DEU MD5_HMAC initialized. Thu May 12 05:36:24 2016 kern.info kernel: [ 10.391907] nf_conntrack version 0.5.0 (1946 buckets, 7784 max) Thu May 12 05:36:24 2016 kern.info kernel: [ 10.418114] NET: Registered protocol family 24 Thu May 12 05:36:24 2016 kern.info kernel: [ 10.443723] xt_time: kernel timezone is -0000 Thu May 12 05:36:24 2016 kern.warn kernel: [ 10.539595] PCI: Enabling device 0000:01:00.0 (0140 -> 0142) Thu May 12 05:36:24 2016 kern.debug kernel: [ 10.550629] ath: EEPROM regdomain: 0x8114 Thu May 12 05:36:24 2016 kern.debug kernel: [ 10.550653] ath: EEPROM indicates we should expect a country code Thu May 12 05:36:24 2016 kern.debug kernel: [ 10.550667] ath: doing EEPROM country->regdmn map search Thu May 12 05:36:24 2016 kern.debug kernel: [ 10.550679] ath: country maps to regdmn code: 0x37 Thu May 12 05:36:24 2016 kern.debug kernel: [ 10.550692] ath: Country alpha2 being used: DE Thu May 12 05:36:24 2016 kern.debug kernel: [ 10.550704] ath: Regpair used: 0x37 Thu May 12 05:36:24 2016 kern.debug kernel: [ 10.564122] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' Thu May 12 05:36:24 2016 kern.info kernel: [ 10.567111] ieee80211 phy0: Atheros AR9287 Rev:2 mem=0xbc000000, irq=144 Thu May 12 05:36:25 2016 user.notice : 'radio0' is disabled Thu May 12 05:36:25 2016 user.notice : 'radio0' is disabled Thu May 12 05:36:26 2016 user.notice : firmware for annex a not found Thu May 12 05:36:28 2016 authpriv.info dropbear[840]: Not backgrounding Thu May 12 05:36:28 2016 user.notice : setting up led wifi Thu May 12 05:36:28 2016 user.notice : setting up led dsl Thu May 12 05:36:28 2016 user.notice : setting up led internet Thu May 12 05:36:29 2016 daemon.info procd: - init complete - Thu May 12 05:36:30 2016 kern.info kernel: [ 19.477228] device eth0.1 entered promiscuous mode Thu May 12 05:36:30 2016 kern.info kernel: [ 19.480651] device eth0 entered promiscuous mode Thu May 12 05:36:30 2016 kern.info kernel: [ 19.500394] br-lan: port 1(eth0.1) entered forwarding state Thu May 12 05:36:30 2016 kern.info kernel: [ 19.504638] br-lan: port 1(eth0.1) entered forwarding state Thu May 12 05:36:30 2016 daemon.notice netifd: Interface 'lan' is enabled Thu May 12 05:36:30 2016 daemon.notice netifd: Interface 'lan' is setting up now Thu May 12 05:36:30 2016 daemon.notice netifd: Interface 'lan' is now up Thu May 12 05:36:30 2016 daemon.notice netifd: Interface 'loopback' is enabled Thu May 12 05:36:30 2016 daemon.notice netifd: Interface 'loopback' is setting up now Thu May 12 05:36:30 2016 daemon.notice netifd: Interface 'loopback' is now up Thu May 12 05:36:30 2016 daemon.notice netifd: Bridge 'br-lan' link is up Thu May 12 05:36:30 2016 daemon.notice netifd: Interface 'lan' has link connectivity Thu May 12 05:36:30 2016 daemon.notice netifd: Network device 'eth0' link is up Thu May 12 05:36:30 2016 daemon.notice netifd: VLAN 'eth0.1' link is up Thu May 12 05:36:30 2016 daemon.notice netifd: Network device 'lo' link is up Thu May 12 05:36:30 2016 daemon.notice netifd: Interface 'loopback' has link connectivity Thu May 12 05:36:30 2016 user.notice firewall: Reloading firewall due to ifup of lan (br-lan) Thu May 12 05:36:32 2016 kern.info kernel: [ 21.506873] br-lan: port 1(eth0.1) entered forwarding state Thu May 12 05:36:35 2016 daemon.info dnsmasq[989]: started, version 2.75 cachesize 150 Thu May 12 05:36:35 2016 daemon.info dnsmasq[989]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-auth no-DNSSEC loop-detect inotify Thu May 12 05:36:35 2016 daemon.info dnsmasq[989]: DNS service limited to local subnets Thu May 12 05:36:35 2016 daemon.info dnsmasq-dhcp[989]: DHCP, IP range 192.168.2.100 -- 192.168.2.249, lease time 12h Thu May 12 05:36:35 2016 daemon.info dnsmasq[989]: using local addresses only for domain lan Thu May 12 05:36:35 2016 daemon.warn dnsmasq[989]: no servers found in /tmp/resolv.conf.auto, will retry Thu May 12 05:36:35 2016 daemon.info dnsmasq[989]: read /etc/hosts - 4 addresses Thu May 12 05:36:35 2016 daemon.info dnsmasq[989]: read /tmp/hosts/dhcp - 2 addresses Thu May 12 05:36:35 2016 daemon.info dnsmasq-dhcp[989]: read /etc/ethers - 0 addresses Thu May 12 05:36:42 2016 kern.notice kernel: [ 31.802908] random: nonblocking pool is initialized -------------- next part -------------- A non-text attachment was scrubbed... Name: 7360.diff Type: text/x-patch Size: 6588 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From martin.blumenstingl at googlemail.com Sun May 15 11:37:32 2016 From: martin.blumenstingl at googlemail.com (Martin Blumenstingl) Date: Sun, 15 May 2016 17:37:32 +0200 Subject: [OpenWrt-Devel] Add support for AVM Fritzbox 7360 SL In-Reply-To: <2d877322-9bf3-7144-3620-589f652f75ef@animeland.de> References: <69086bb8-44aa-05e4-a550-ee1b13633b4a@animeland.de> <572E254E.4030409@gmail.com> <44031fa7-cb40-d37c-79bd-f338bfba8b68@animeland.de> <93a04c66-d6a4-1c5f-d16c-80db337b6d3c@animeland.de> <2d877322-9bf3-7144-3620-589f652f75ef@animeland.de> Message-ID: On Sun, May 15, 2016 at 3:44 PM, Sebastian Ortwein wrote: > USB, WLAN and LAN works now. The only think what would not work is phy0 & > phy1. > I have attached my lastet patch. if you google around a bit you'll find an AR8035 datasheet: that phy is from the same series as the AR8030. It defines that the RST pin is "active low" -> meaning you have to pull it high to ensure that the PHY is not being reset: http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/pinctrl/lantiq,pinctrl-xway.txt?v=4.4#L61 This means you should probably use: lantiq,output = <1>; lantiq,pull = <2>; lantiq,open-drain; > [ 0.993675] libphy: lantiq,xrx200-mdio: probed > [ 1.004257] eth0: attached PHY [Generic PHY] (phy_addr=0:00, irq=-1) > [ 1.009606] eth0: attached PHY [Generic PHY] (phy_addr=0:01, irq=-1) > [ 1.079564] eth0: attached PHY [Lantiq XWAY VR9 GPHY 11G v1.4] > (phy_addr=0:11, irq=-1) > [ 1.147555] eth0: attached PHY [Lantiq XWAY VR9 GPHY 11G v1.4] > (phy_addr=0:13, irq=-1) "Generic PHY" means that no specific driver for this PHY is loaded. Make sure you enable CONFIG_AT803X_PHY in target/linux/lantiq/config-4.4 Additionally you should check the phy-mode: You are setting phy-mode = "rgmii", but Atheros says that the AR8030 is an "Ultra low-power single RMII Fast Ethernet PHY". Thus you should probably change "rgmii" to "rmii". Martin On Sun, May 15, 2016 at 3:44 PM, Sebastian Ortwein wrote: > Am 08.05.2016 um 18:40 schrieb Martin Blumenstingl: >> >> On Sun, May 8, 2016 at 5:49 PM, Sebastian Ortwein >> wrote: >>> >>> can I add it the following way ? >>> mdio at 0 { >>> #address-cells = <1>; >>> #size-cells = <0>; >>> compatible = "lantiq,xrx200-mdio"; >>> phy0: ethernet-phy at 0 { >>> reg = <0x0>; >>> compatible = "lantiq,phy11g", >>> "ethernet-phy-ieee802.3-c22"; >>> gpios = <&gpio 37 0>; >>> }; >>> phy1: ethernet-phy at 1 { >>> reg = <0x1>; >>> compatible = "lantiq,phy11g", >>> "ethernet-phy-ieee802.3-c22"; >>> gpios = <&gpio 44 0>; >>> }; >>> phy11: ethernet-phy at 11 { >>> reg = <0x11>; >>> compatible = "lantiq,phy11g", >>> "ethernet-phy-ieee802.3-c22"; >>> }; >>> phy13: ethernet-phy at 13 { >>> reg = <0x13>; >>> compatible = "lantiq,phy11g", >>> "ethernet-phy-ieee802.3-c22"; >>> }; >> >> I think you have to name the property "reset-gpios", but apart from >> that it looks good. > > I have try it like you sayed. But without success. > I think the gpios are defined here, but it won't working. > > phy-rst { > lantiq,pins = "io37", "io44"; > lantiq,pull = <0>; > lantiq,open-drain = <0>; > lantiq,output = <1>; > }; > >>>> I cannot see any ath9k messages in your kernel log - are you sure it's >>>> being installed (/lib/modules/*/ath9k.ko)? >>>> Your first patch lists kmod-ath9k, but if you added that after you >>>> generated your .config then you're probably still missing it. >>>> Please check "grep kmod-ath9k .config" and enable (set it to >>>> =y/built-in) it if it's missing. >>> >>> I have not disable the ath9k driver. it is present and loaded. >> >> I think I see the problem after looking at your .dts again: >> you *must* specify the ath,pci-slot property, otherwise the fixup is >> not executed. >> It seems that the wifi part is similar to the TD-W8980 (AR9287 behind >> the PCIe-to-PCI bridge), so "0" should be the right value. >> (otherwise it's pretty easy to find out by looking at sysfs: >> /sys/bus/pci/devices/0000\:00\:0e.0/ -> that's where the ath9k device >> on HH5A can be found, there we use ath,pci-slot = <0xe>;) >> >> >> Martin >> >> >> [0] >> https://github.com/openwrt/openwrt/blob/master/target/linux/lantiq/patches-4.4/0035-owrt-lantiq-wifi-and-ethernet-eeprom-handling.patch#L178 > > > USB, WLAN and LAN works now. The only think what would not work is phy0 & > phy1. > I have attached my lastet patch. > > dmesg > > [ 0.000000] Linux version 4.4.7 (sebastian at sebastian-desktop) (gcc > version 5.3.0 (OpenWrt GCC 5.3.0 r49377) ) #1 Sun May 15 13:18:03 UTC 2016 > [ 0.000000] SoC: xRX200 rev 1.1 > [ 0.000000] bootconsole [early0] enabled > [ 0.000000] CPU0 revision is: 00019555 (MIPS 34Kc) > [ 0.000000] MIPS: machine is FRITZ7360SL - 1&1 HomeServer > [ 0.000000] Determined physical RAM map: > [ 0.000000] memory: 08000000 @ 00000000 (usable) > [ 0.000000] Initrd not found or empty - disabling initrd > [ 0.000000] Zone ranges: > [ 0.000000] Normal [mem 0x0000000000000000-0x0000000007ffffff] > [ 0.000000] Movable zone start for each node > [ 0.000000] Early memory node ranges > [ 0.000000] node 0: [mem 0x0000000000000000-0x0000000007ffffff] > [ 0.000000] Initmem setup node 0 [mem > 0x0000000000000000-0x0000000007ffffff] > [ 0.000000] On node 0 totalpages: 32768 > [ 0.000000] free_area_init_node: node 0, pgdat 804d6390, node_mem_map > 81007b60 > [ 0.000000] Normal zone: 256 pages used for memmap > [ 0.000000] Normal zone: 0 pages reserved > [ 0.000000] Normal zone: 32768 pages, LIFO batch:7 > [ 0.000000] Primary instruction cache 32kB, VIPT, 4-way, linesize 32 > bytes. > [ 0.000000] Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize > 32 bytes > [ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 > [ 0.000000] pcpu-alloc: [0] 0 > [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total > pages: 32512 > [ 0.000000] Kernel command line: console=ttyLTQ0,115200 init=/etc/preinit > [ 0.000000] PID hash table entries: 512 (order: -1, 2048 bytes) > [ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 > bytes) > [ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) > [ 0.000000] Writing ErrCtl register=00074200 > [ 0.000000] Readback ErrCtl register=00074200 > [ 0.000000] Memory: 123372K/131072K available (3764K kernel code, 164K > rwdata, 1144K rodata, 1184K init, 211K bss, 7700K reserved, 0K cma-reserved) > [ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 > [ 0.000000] NR_IRQS:256 > [ 0.000000] CPU Clock: 500MHz > [ 0.000000] clocksource: MIPS: mask: 0xffffffff max_cycles: 0xffffffff, > max_idle_ns: 7645041786 ns > [ 0.000011] sched_clock: 32 bits at 250MHz, resolution 4ns, wraps every > 8589934590ns > [ 0.007861] Calibrating delay loop... 332.54 BogoMIPS (lpj=665088) > [ 0.042318] pid_max: default: 32768 minimum: 301 > [ 0.047172] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) > [ 0.053732] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 > bytes) > [ 0.066701] clocksource: jiffies: mask: 0xffffffff max_cycles: > 0xffffffff, max_idle_ns: 7645041785100000 ns > [ 0.076483] pinctrl core: initialized pinctrl subsystem > [ 0.082366] NET: Registered protocol family 16 > [ 0.091505] pinctrl-xway 1e100b10.pinmux: Init done > [ 0.097056] dma-xway 1e104100.dma: Init done - hw rev: 7, ports: 7, > channels: 28 > [ 0.207159] dcdc-xrx200 1f106a00.dcdc: Core Voltage : 1016 mV > [ 0.333371] ath9k,eeprom ath9k_eep: failed to load eeprom address > [ 0.354429] usbcore: registered new interface driver usbfs > [ 0.359938] usbcore: registered new interface driver hub > [ 0.365292] usbcore: registered new device driver usb > [ 0.370641] PCI host bridge to bus 0000:00 > [ 0.374631] pci_bus 0000:00: root bus resource [mem 0x1c000000-0x1cffffff] > [ 0.381545] pci_bus 0000:00: root bus resource [io 0x1d800000-0x1d8fffff] > [ 0.388488] pci_bus 0000:00: root bus resource [??? 0x00000000 flags 0x0] > [ 0.395343] pci_bus 0000:00: No busn resource found for root bus, will use > [bus 00-ff] > [ 0.403373] pci 0000:00:00.0: [15d1:0011] type 01 class 0x060000 > [ 0.403410] ifx_pcie_rc_class_early_fixup: fixed pcie host bridge to pci-pci > bridge > [ 0.421054] ifx_pcie_fixup_resource: fixup host controller 0000:00:00.0 > (15d1:0011) > [ 0.428645] pci 0000:00:00.0: PME# supported from D0 D3hot > [ 0.429208] pci 0000:01:00.0: [168c:ff1c] type 00 class 0x020000 > [ 0.429298] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x0000ffff 64bit] > [ 0.429454] pci 0000:01:00.0: supports D1 > [ 0.429475] pci 0000:01:00.0: PME# supported from D0 D1 D3hot > [ 0.429773] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01 > [ 0.429814] pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 01 > [ 0.429870] pci 0000:00:00.0: BAR 8: assigned [mem 0x1c000000-0x1c0fffff] > [ 0.436557] pci 0000:01:00.0: BAR 0: assigned [mem 0x1c000000-0x1c00ffff > 64bit] > [ 0.443919] pci 0000:00:00.0: PCI bridge to [bus 01] > [ 0.448935] pci 0000:00:00.0: bridge window [mem 0x1c000000-0x1c0fffff] > [ 0.455810] ifx_pcie_bios_map_irq port 0 dev 0000:00:00.0 slot 0 pin 1 > [ 0.462461] ifx_pcie_bios_map_irq dev 0000:00:00.0 irq 144 assigned > [ 0.468815] ifx_pcie_bios_map_irq port 0 dev 0000:01:00.0 slot 0 pin 1 > [ 0.475481] ifx_pcie_bios_map_irq dev 0000:01:00.0 irq 144 assigned > [ 0.482864] clocksource: Switched to clocksource MIPS > [ 0.489513] NET: Registered protocol family 2 > [ 0.494738] TCP established hash table entries: 1024 (order: 0, 4096 bytes) > [ 0.501634] TCP bind hash table entries: 1024 (order: 0, 4096 bytes) > [ 0.508012] TCP: Hash tables configured (established 1024 bind 1024) > [ 0.514529] UDP hash table entries: 256 (order: 0, 4096 bytes) > [ 0.520367] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) > [ 0.526969] NET: Registered protocol family 1 > [ 0.531315] PCI: CLS 0 bytes, default 32 > [ 0.531770] gptu: totally 6 16-bit timers/counters > [ 0.536615] gptu: misc_register on minor 63 > [ 0.540712] gptu: succeeded to request irq 126 > [ 0.545201] gptu: succeeded to request irq 127 > [ 0.549715] gptu: succeeded to request irq 128 > [ 0.554229] gptu: succeeded to request irq 129 > [ 0.558742] gptu: succeeded to request irq 130 > [ 0.563259] gptu: succeeded to request irq 131 > [ 0.568633] phy-xrx200 gphy-xrx200: requesting lantiq/vr9_phy11g_a1x.bin > [ 0.575912] phy-xrx200 gphy-xrx200: booting GPHY0 firmware at 7960000 > [ 0.582260] phy-xrx200 gphy-xrx200: booting GPHY1 firmware at 7960000 > [ 0.689806] futex hash table entries: 256 (order: -1, 3072 bytes) > [ 0.723154] squashfs: version 4.0 (2009/01/31) Phillip Lougher > [ 0.728894] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) > (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc. > [ 0.742291] io scheduler noop registered > [ 0.746134] io scheduler deadline registered (default) > [ 0.751978] 1e100c00.serial: ttyLTQ0 at MMIO 0x1e100c00 (irq = 112, > base_baud = 0) is a lantiq,asc > [ 0.760881] console [ttyLTQ0] enabled > [ 0.768206] bootconsole [early0] disabled > [ 0.777268] lantiq nor flash device: 01000000 at 10000000 > [ 0.781402] ltq_nor: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer > ID 0x000001 Chip ID 0x002101 > [ 0.790840] Amd/Fujitsu Extended Query Table at 0x0040 > [ 0.795967] Amd/Fujitsu Extended Query version 1.3. > [ 0.801004] number of CFI chips: 1 > [ 0.804436] 4 ofpart partitions found on MTD device ltq_nor > [ 0.809969] Creating 4 MTD partitions on "ltq_nor": > [ 0.814852] 0x000000000000-0x000000020000 : "urlader" > [ 0.823305] 0x000000020000-0x000000f80000 : "firmware" > [ 0.844284] 2 eva-fw partitions found on MTD device firmware > [ 0.848534] 0x000000020000-0x0000001bfa70 : "kernel" > [ 0.855348] 0x0000001c0100-0x000000f80000 : "rootfs" > [ 0.860994] mtd: device 3 (rootfs) set to be root filesystem > [ 0.865302] 1 squashfs-split partitions found on MTD device rootfs > [ 0.871420] 0x0000003e0000-0x000000f80000 : "rootfs_data" > [ 0.879057] 0x000000f80000-0x000000fc0000 : "tffs (1)" > [ 0.884936] 0x000000fc0000-0x000001000000 : "tffs (2)" > [ 0.993675] libphy: lantiq,xrx200-mdio: probed > [ 1.004257] eth0: attached PHY [Generic PHY] (phy_addr=0:00, irq=-1) > [ 1.009606] eth0: attached PHY [Generic PHY] (phy_addr=0:01, irq=-1) > [ 1.079564] eth0: attached PHY [Lantiq XWAY VR9 GPHY 11G v1.4] > (phy_addr=0:11, irq=-1) > [ 1.147555] eth0: attached PHY [Lantiq XWAY VR9 GPHY 11G v1.4] > (phy_addr=0:13, irq=-1) > [ 1.155438] wdt 1f8803f0.watchdog: Init done > [ 1.161244] NET: Registered protocol family 10 > [ 1.169748] NET: Registered protocol family 17 > [ 1.172899] bridge: automatic filtering via arp/ip/ip6tables has been > deprecated. Update your scripts to load br_netfilter if you need this. > [ 1.185425] 8021q: 802.1Q VLAN Support v1.8 > [ 1.189680] found entry name -> annex=B > [ 1.193440] found entry name -> maca=BC:05:43:D7:1E:7C > [ 1.198534] found entry name -> macb=BC:05:43:D7:1E:7D > [ 1.203673] found entry name -> macwlan=BC:05:43:D7:1E:7E > [ 1.209066] found entry name -> macdsl=BC:05:43:D7:1E:7F > [ 1.214430] found entry name -> macwlan2=BC:05:43:D7:1E:81 > [ 1.219861] found entry name -> wlan_key=4004584479108575 > [ 1.228307] ath9k,eeprom ath9k_eep: endian check enabled. > [ 1.232282] ath9k,eeprom ath9k_eep: using random mac > [ 1.237274] ath9k,eeprom ath9k_eep: pci slot: 0 > [ 1.241777] pci 0000:01:00.0: fixup device configuration > [ 1.247149] PCI: Enabling device 0000:01:00.0 (0000 -> 0002) > [ 1.254428] pci 0000:01:00.0: fixup info: [168c:002e] revision 01 class > 0x028000 > [ 1.260435] ath9k,eeprom ath9k_eep: loaded ath9k eeprom > [ 1.270378] UBIFS error (pid: 1): cannot open "ubi0:rootfs", error -19 > [ 1.280211] VFS: Mounted root (squashfs filesystem) readonly on device > 31:3. > [ 1.287767] Freeing unused kernel memory: 1184K (804f8000 - 80620000) > [ 2.468013] init: Console is alive > [ 2.470263] init: - watchdog - > [ 3.884244] dwc2 1e101000.ifxhcd: Configuration mismatch. Forcing host > mode > [ 4.035028] eth0: port 0 got link > [ 4.747073] dwc2 1e101000.ifxhcd: DWC OTG Controller > [ 4.750648] dwc2 1e101000.ifxhcd: new USB bus registered, assigned bus > number 1 > [ 4.757999] dwc2 1e101000.ifxhcd: irq 62, io mem 0x00000000 > [ 4.763516] dwc2 1e101000.ifxhcd: Hardware does not support descriptor > DMA mode - > [ 4.770953] dwc2 1e101000.ifxhcd: falling back to buffer DMA mode. > [ 4.778435] hub 1-0:1.0: USB hub found > [ 4.781398] hub 1-0:1.0: 1 port detected > [ 4.785460] dwc2 1e106000.ifxhcd: Configuration mismatch. Forcing host > mode > [ 5.647060] dwc2 1e106000.ifxhcd: DWC OTG Controller > [ 5.650655] dwc2 1e106000.ifxhcd: new USB bus registered, assigned bus > number 2 > [ 5.657970] dwc2 1e106000.ifxhcd: irq 91, io mem 0x00000000 > [ 5.663499] dwc2 1e106000.ifxhcd: Hardware does not support descriptor > DMA mode - > [ 5.670938] dwc2 1e106000.ifxhcd: falling back to buffer DMA mode. > [ 5.678440] hub 2-0:1.0: USB hub found > [ 5.681390] hub 2-0:1.0: 1 port detected > [ 5.687615] init: - preinit - > [ 6.192804] random: procd urandom read with 26 bits of entropy available > [ 8.569614] jffs2: notice: (370) jffs2_build_xattr_subsystem: complete > building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref > (0 dead, 0 orphan) found. > [ 8.585353] mount_root: switching to jffs2 overlay > [ 8.606254] procd: - early - > [ 8.607917] procd: - watchdog - > [ 9.348938] procd: - ubus - > [ 9.403903] procd: - init - > [ 10.231370] IFXOS, Version 1.5.19 (c) Copyright 2009, Lantiq Deutschland > GmbH > [ 10.241461] NET: Registered protocol family 8 > [ 10.244431] NET: Registered protocol family 20 > [ 10.255629] PPP generic driver version 2.4.2 > [ 10.266429] ip6_tables: (C) 2000-2006 Netfilter Core Team > [ 10.291707] Lantiq (VRX) DSL CPE MEI driver, version 1.4.8.5, (c) 2013 > Lantiq Deutschland GmbH > [ 10.291707] > [ 10.291707] Lantiq CPE API Driver version: DSL CPE API V4.16.6.3 > [ 10.312794] > [ 10.312794] Predefined debug level: 3 > [ 10.323452] Loading modules backported from Linux version > v4.4-rc5-1913-gc8fdf68 > [ 10.329464] Backport generated by backports.git > backports-20151218-0-g2f58d9d > [ 10.340031] ip_tables: (C) 2000-2006 Netfilter Core Team > [ 10.351117] Infineon Technologies DEU driver version 2.0.0 > [ 10.357203] IFX DEU DES initialized (multiblock). > [ 10.361497] IFX DEU AES initialized (multiblock). > [ 10.365620] IFX DEU ARC4 initialized (multiblock). > [ 10.370239] IFX DEU SHA1 initialized. > [ 10.373843] IFX DEU MD5 initialized. > [ 10.377438] IFX DEU SHA1_HMAC initialized. > [ 10.381556] IFX DEU MD5_HMAC initialized. > [ 10.391907] nf_conntrack version 0.5.0 (1946 buckets, 7784 max) > [ 10.418114] NET: Registered protocol family 24 > [ 10.443723] xt_time: kernel timezone is -0000 > [ 10.539595] PCI: Enabling device 0000:01:00.0 (0140 -> 0142) > [ 10.550629] ath: EEPROM regdomain: 0x8114 > [ 10.550653] ath: EEPROM indicates we should expect a country code > [ 10.550667] ath: doing EEPROM country->regdmn map search > [ 10.550679] ath: country maps to regdmn code: 0x37 > [ 10.550692] ath: Country alpha2 being used: DE > [ 10.550704] ath: Regpair used: 0x37 > [ 10.564122] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' > [ 10.567111] ieee80211 phy0: Atheros AR9287 Rev:2 mem=0xbc000000, irq=144 > [ 19.477228] device eth0.1 entered promiscuous mode > [ 19.480651] device eth0 entered promiscuous mode > [ 19.500394] br-lan: port 1(eth0.1) entered forwarding state > [ 19.504638] br-lan: port 1(eth0.1) entered forwarding state > [ 21.506873] br-lan: port 1(eth0.1) entered forwarding state > [ 31.802908] random: nonblocking pool is initialized > > > logread > > hu May 12 05:36:24 2016 kern.info kernel: [ 0.381545] pci_bus 0000:00: root > bus resource [io 0x1d800000-0x1d8fffff] > Thu May 12 05:36:24 2016 kern.info kernel: [ 0.388488] pci_bus 0000:00: root > bus resource [??? 0x00000000 flags 0x0] > Thu May 12 05:36:24 2016 kern.info kernel: [ 0.395343] pci_bus 0000:00: No > busn resource found for root bus, will use [bus 00-ff] > Thu May 12 05:36:24 2016 kern.debug kernel: [ 0.403373] pci 0000:00:00.0: > [15d1:0011] type 01 class 0x060000 > Thu May 12 05:36:24 2016 kern.info kernel: [ 0.403410] > ifx_pcie_rc_class_early_fixup: fixed pcie host bridge to pci-pci bridge > Thu May 12 05:36:24 2016 kern.warn kernel: [ 0.421054] > ifx_pcie_fixup_resource: fixup host controller 0000:00:00.0 (15d1:0011) > Thu May 12 05:36:24 2016 kern.debug kernel: [ 0.428645] pci 0000:00:00.0: > PME# supported from D0 D3hot > Thu May 12 05:36:24 2016 kern.debug kernel: [ 0.429208] pci 0000:01:00.0: > [168c:ff1c] type 00 class 0x020000 > Thu May 12 05:36:24 2016 kern.debug kernel: [ 0.429298] pci 0000:01:00.0: > reg 0x10: [mem 0x00000000-0x0000ffff 64bit] > Thu May 12 05:36:24 2016 kern.debug kernel: [ 0.429454] pci 0000:01:00.0: > supports D1 > Thu May 12 05:36:24 2016 kern.debug kernel: [ 0.429475] pci 0000:01:00.0: > PME# supported from D0 D1 D3hot > Thu May 12 05:36:24 2016 kern.debug kernel: [ 0.429773] pci_bus 0000:01: > busn_res: [bus 01-ff] end is updated to 01 > Thu May 12 05:36:24 2016 kern.debug kernel: [ 0.429814] pci_bus 0000:00: > busn_res: [bus 00-ff] end is updated to 01 > Thu May 12 05:36:24 2016 kern.info kernel: [ 0.429870] pci 0000:00:00.0: BAR > 8: assigned [mem 0x1c000000-0x1c0fffff] > Thu May 12 05:36:24 2016 kern.info kernel: [ 0.436557] pci 0000:01:00.0: BAR > 0: assigned [mem 0x1c000000-0x1c00ffff 64bit] > Thu May 12 05:36:24 2016 kern.info kernel: [ 0.443919] pci 0000:00:00.0: PCI > bridge to [bus 01] > Thu May 12 05:36:24 2016 kern.info kernel: [ 0.448935] pci 0000:00:00.0: > bridge window [mem 0x1c000000-0x1c0fffff] > Thu May 12 05:36:24 2016 kern.warn kernel: [ 0.455810] ifx_pcie_bios_map_irq > port 0 dev 0000:00:00.0 slot 0 pin 1 > Thu May 12 05:36:24 2016 kern.warn kernel: [ 0.462461] ifx_pcie_bios_map_irq > dev 0000:00:00.0 irq 144 assigned > Thu May 12 05:36:24 2016 kern.warn kernel: [ 0.468815] ifx_pcie_bios_map_irq > port 0 dev 0000:01:00.0 slot 0 pin 1 > Thu May 12 05:36:24 2016 kern.warn kernel: [ 0.475481] ifx_pcie_bios_map_irq > dev 0000:01:00.0 irq 144 assigned > Thu May 12 05:36:24 2016 kern.info kernel: [ 0.482864] clocksource: Switched > to clocksource MIPS > Thu May 12 05:36:24 2016 kern.info kernel: [ 0.489513] NET: Registered > protocol family 2 > Thu May 12 05:36:24 2016 kern.info kernel: [ 0.494738] TCP established hash > table entries: 1024 (order: 0, 4096 bytes) > Thu May 12 05:36:24 2016 kern.info kernel: [ 0.501634] TCP bind hash > table entries: 1024 (order: 0, 4096 bytes) > Thu May 12 05:36:24 2016 kern.info kernel: [ 0.508012] TCP: Hash tables > configured (established 1024 bind 1024) > Thu May 12 05:36:24 2016 kern.info kernel: [ 0.514529] UDP hash table > entries: 256 (order: 0, 4096 bytes) > Thu May 12 05:36:24 2016 kern.info kernel: [ 0.520367] UDP-Lite hash table > entries: 256 (order: 0, 4096 bytes) > Thu May 12 05:36:24 2016 kern.info kernel: [ 0.526969] NET: Registered > protocol family 1 > Thu May 12 05:36:24 2016 kern.debug kernel: [ 0.531315] PCI: CLS 0 bytes, > default 32 > Thu May 12 05:36:24 2016 kern.info kernel: [ 0.531770] gptu: totally 6 > 16-bit timers/counters > Thu May 12 05:36:24 2016 kern.info kernel: [ 0.536615] gptu: misc_register > on minor 63 > Thu May 12 05:36:24 2016 kern.info kernel: [ 0.540712] gptu: succeeded to > request irq 126 > Thu May 12 05:36:24 2016 kern.info kernel: [ 0.545201] gptu: succeeded to > request irq 127 > Thu May 12 05:36:24 2016 kern.info kernel: [ 0.549715] gptu: succeeded to > request irq 128 > Thu May 12 05:36:24 2016 kern.info kernel: [ 0.554229] gptu: succeeded to > request irq 129 > Thu May 12 05:36:24 2016 kern.info kernel: [ 0.558742] gptu: succeeded to > request irq 130 > Thu May 12 05:36:24 2016 kern.info kernel: [ 0.563259] gptu: succeeded to > request irq 131 > Thu May 12 05:36:24 2016 kern.info kernel: [ 0.568633] phy-xrx200 > gphy-xrx200: requesting lantiq/vr9_phy11g_a1x.bin > Thu May 12 05:36:24 2016 kern.info kernel: [ 0.575912] phy-xrx200 > gphy-xrx200: booting GPHY0 firmware at 7960000 > Thu May 12 05:36:24 2016 kern.info kernel: [ 0.582260] phy-xrx200 > gphy-xrx200: booting GPHY1 firmware at 7960000 > Thu May 12 05:36:24 2016 kern.info kernel: [ 0.689806] futex hash table > entries: 256 (order: -1, 3072 bytes) > Thu May 12 05:36:24 2016 kern.info kernel: [ 0.723154] squashfs: version 4.0 > (2009/01/31) Phillip Lougher > Thu May 12 05:36:24 2016 kern.info kernel: [ 0.728894] jffs2: version 2.2 > (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc. > Thu May 12 05:36:24 2016 kern.info kernel: [ 0.742291] io scheduler noop > registered > Thu May 12 05:36:24 2016 kern.info kernel: [ 0.746134] io scheduler deadline > registered (default) > Thu May 12 05:36:24 2016 kern.info kernel: [ 0.751978] 1e100c00.serial: > ttyLTQ0 at MMIO 0x1e100c00 (irq = 112, base_baud = 0) is a lantiq,asc > Thu May 12 05:36:24 2016 kern.info kernel: [ 0.760881] console [ttyLTQ0] > enabled > Thu May 12 05:36:24 2016 kern.info kernel: [ 0.768206] bootconsole [early0] > disabled > Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.777268] lantiq nor flash > device: 01000000 at 10000000 > Thu May 12 05:36:24 2016 kern.info kernel: [ 0.781402] ltq_nor: Found 1 x16 > devices at 0x0 in 16-bit bank. Manufacturer ID 0x000001 Chip ID 0x002101 > Thu May 12 05:36:24 2016 kern.info kernel: [ 0.790840] Amd/Fujitsu Extended > Query Table at 0x0040 > Thu May 12 05:36:24 2016 kern.info kernel: [ 0.795967] Amd/Fujitsu Extended > Query version 1.3. > Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.801004] number of CFI > chips: 1 > Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.804436] 4 ofpart partitions > found on MTD device ltq_nor > Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.809969] Creating 4 MTD > partitions on "ltq_nor": > Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.814852] > 0x000000000000-0x000000020000 : "urlader" > Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.823305] > 0x000000020000-0x000000f80000 : "firmware" > Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.844284] 2 eva-fw partitions > found on MTD device firmware > Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.848534] > 0x000000020000-0x0000001bfa70 : "kernel" > Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.855348] > 0x0000001c0100-0x000000f80000 : "rootfs" > Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.860994] mtd: device 3 > (rootfs) set to be root filesystem > Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.865302] 1 squashfs-split > partitions found on MTD device rootfs > Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.871420] > 0x0000003e0000-0x000000f80000 : "rootfs_data" > Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.879057] > 0x000000f80000-0x000000fc0000 : "tffs (1)" > Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.884936] > 0x000000fc0000-0x000001000000 : "tffs (2)" > Thu May 12 05:36:24 2016 kern.info kernel: [ 0.993675] libphy: > lantiq,xrx200-mdio: probed > Thu May 12 05:36:24 2016 kern.info kernel: [ 1.004257] eth0: attached PHY > [Generic PHY] (phy_addr=0:00, irq=-1) > Thu May 12 05:36:24 2016 kern.info kernel: [ 1.009606] eth0: attached PHY > [Generic PHY] (phy_addr=0:01, irq=-1) > Thu May 12 05:36:24 2016 kern.info kernel: [ 1.079564] eth0: attached PHY > [Lantiq XWAY VR9 GPHY 11G v1.4] (phy_addr=0:11, irq=-1) > Thu May 12 05:36:24 2016 kern.info kernel: [ 1.147555] eth0: attached PHY > [Lantiq XWAY VR9 GPHY 11G v1.4] (phy_addr=0:13, irq=-1) > Thu May 12 05:36:24 2016 kern.info kernel: [ 1.155438] wdt > 1f8803f0.watchdog: Init done > Thu May 12 05:36:24 2016 kern.info kernel: [ 1.161244] NET: Registered > protocol family 10 > Thu May 12 05:36:24 2016 kern.info kernel: [ 1.169748] NET: Registered > protocol family 17 > Thu May 12 05:36:24 2016 kern.info kernel: [ 1.172899] bridge: automatic > filtering via arp/ip/ip6tables has been deprecated. Update your scripts to > load br_netfilter if you need this. > Thu May 12 05:36:24 2016 kern.info kernel: [ 1.185425] 8021q: 802.1Q VLAN > Support v1.8 > Thu May 12 05:36:24 2016 kern.info kernel: [ 1.189680] found entry name > -> annex=B > Thu May 12 05:36:24 2016 kern.info kernel: [ 1.193440] found entry name > -> maca=BC:05:43:D7:1E:7C > Thu May 12 05:36:24 2016 kern.info kernel: [ 1.198534] found entry name > -> macb=BC:05:43:D7:1E:7D > Thu May 12 05:36:24 2016 kern.info kernel: [ 1.203673] found entry name > -> macwlan=BC:05:43:D7:1E:7E > Thu May 12 05:36:24 2016 kern.info kernel: [ 1.209066] found entry name > -> macdsl=BC:05:43:D7:1E:7F > Thu May 12 05:36:24 2016 kern.info kernel: [ 1.214430] found entry name > -> macwlan2=BC:05:43:D7:1E:81 > Thu May 12 05:36:24 2016 kern.info kernel: [ 1.219861] found entry name > -> wlan_key=4004584479108575 > Thu May 12 05:36:24 2016 kern.info kernel: [ 1.228307] ath9k,eeprom > ath9k_eep: endian check enabled. > Thu May 12 05:36:24 2016 kern.warn kernel: [ 1.232282] ath9k,eeprom > ath9k_eep: using random mac > Thu May 12 05:36:24 2016 kern.info kernel: [ 1.237274] ath9k,eeprom > ath9k_eep: pci slot: 0 > Thu May 12 05:36:24 2016 kern.info kernel: [ 1.241777] pci 0000:01:00.0: > fixup device configuration > Thu May 12 05:36:24 2016 kern.warn kernel: [ 1.247149] PCI: Enabling > device 0000:01:00.0 (0000 -> 0002) > Thu May 12 05:36:24 2016 kern.info kernel: [ 1.254428] pci 0000:01:00.0: > fixup info: [168c:002e] revision 01 class 0x028000 > Thu May 12 05:36:24 2016 kern.info kernel: [ 1.260435] ath9k,eeprom > ath9k_eep: loaded ath9k eeprom > Thu May 12 05:36:24 2016 kern.err kernel: [ 1.270378] UBIFS error (pid: > 1): cannot open "ubi0:rootfs", error -19 > Thu May 12 05:36:24 2016 kern.info kernel: [ 1.280211] VFS: Mounted root > (squashfs filesystem) readonly on device 31:3. > Thu May 12 05:36:24 2016 kern.info kernel: [ 1.287767] Freeing unused > kernel memory: 1184K (804f8000 - 80620000) > Thu May 12 05:36:24 2016 user.info kernel: [ 2.468013] init: Console is > alive > Thu May 12 05:36:24 2016 user.info kernel: [ 2.470263] init: - watchdog - > Thu May 12 05:36:24 2016 kern.warn kernel: [ 3.884244] dwc2 > 1e101000.ifxhcd: Configuration mismatch. Forcing host mode > Thu May 12 05:36:24 2016 kern.info kernel: [ 4.035028] eth0: port 0 got > link > Thu May 12 05:36:24 2016 kern.info kernel: [ 4.747073] dwc2 > 1e101000.ifxhcd: DWC OTG Controller > Thu May 12 05:36:24 2016 kern.info kernel: [ 4.750648] dwc2 > 1e101000.ifxhcd: new USB bus registered, assigned bus number 1 > Thu May 12 05:36:24 2016 kern.info kernel: [ 4.757999] dwc2 > 1e101000.ifxhcd: irq 62, io mem 0x00000000 > Thu May 12 05:36:24 2016 kern.err kernel: [ 4.763516] dwc2 > 1e101000.ifxhcd: Hardware does not support descriptor DMA mode - > Thu May 12 05:36:24 2016 kern.err kernel: [ 4.770953] dwc2 > 1e101000.ifxhcd: falling back to buffer DMA mode. > Thu May 12 05:36:24 2016 kern.info kernel: [ 4.778435] hub 1-0:1.0: USB > hub found > Thu May 12 05:36:24 2016 kern.info kernel: [ 4.781398] hub 1-0:1.0: 1 > port detected > Thu May 12 05:36:24 2016 kern.warn kernel: [ 4.785460] dwc2 > 1e106000.ifxhcd: Configuration mismatch. Forcing host mode > Thu May 12 05:36:24 2016 kern.info kernel: [ 5.647060] dwc2 > 1e106000.ifxhcd: DWC OTG Controller > Thu May 12 05:36:24 2016 kern.info kernel: [ 5.650655] dwc2 > 1e106000.ifxhcd: new USB bus registered, assigned bus number 2 > Thu May 12 05:36:24 2016 kern.info kernel: [ 5.657970] dwc2 > 1e106000.ifxhcd: irq 91, io mem 0x00000000 > Thu May 12 05:36:24 2016 kern.err kernel: [ 5.663499] dwc2 > 1e106000.ifxhcd: Hardware does not support descriptor DMA mode - > Thu May 12 05:36:24 2016 kern.err kernel: [ 5.670938] dwc2 > 1e106000.ifxhcd: falling back to buffer DMA mode. > Thu May 12 05:36:24 2016 kern.info kernel: [ 5.678440] hub 2-0:1.0: USB > hub found > Thu May 12 05:36:24 2016 kern.info kernel: [ 5.681390] hub 2-0:1.0: 1 > port detected > Thu May 12 05:36:24 2016 user.info kernel: [ 5.687615] init: - preinit - > Thu May 12 05:36:24 2016 kern.notice kernel: [ 6.192804] random: procd > urandom read with 26 bits of entropy available > Thu May 12 05:36:24 2016 kern.notice kernel: [ 8.569614] jffs2: notice: > (370) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of > xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found. > Thu May 12 05:36:24 2016 user.info kernel: [ 8.585353] mount_root: > switching to jffs2 overlay > Thu May 12 05:36:24 2016 user.info kernel: [ 8.606254] procd: - early - > Thu May 12 05:36:24 2016 user.info kernel: [ 8.607917] procd: - watchdog > - > Thu May 12 05:36:24 2016 user.info kernel: [ 9.348938] procd: - ubus - > Thu May 12 05:36:24 2016 user.info kernel: [ 9.403903] procd: - init - > Thu May 12 05:36:24 2016 kern.info kernel: [ 10.231370] IFXOS, Version > 1.5.19 (c) Copyright 2009, Lantiq Deutschland GmbH > Thu May 12 05:36:24 2016 kern.info kernel: [ 10.241461] NET: Registered > protocol family 8 > Thu May 12 05:36:24 2016 kern.info kernel: [ 10.244431] NET: Registered > protocol family 20 > Thu May 12 05:36:24 2016 kern.info kernel: [ 10.255629] PPP generic driver > version 2.4.2 > Thu May 12 05:36:24 2016 kern.info kernel: [ 10.266429] ip6_tables: (C) > 2000-2006 Netfilter Core Team > Thu May 12 05:36:24 2016 kern.info kernel: [ 10.291707] Lantiq (VRX) DSL > CPE MEI driver, version 1.4.8.5, (c) 2013 Lantiq Deutschland GmbH > Thu May 12 05:36:24 2016 kern.info kernel: [ 10.291707] > Thu May 12 05:36:24 2016 kern.info kernel: [ 10.291707] Lantiq CPE API > Driver version: DSL CPE API V4.16.6.3 > Thu May 12 05:36:24 2016 kern.warn kernel: [ 10.312794] > Thu May 12 05:36:24 2016 kern.warn kernel: [ 10.312794] Predefined debug > level: 3 > Thu May 12 05:36:24 2016 kern.info kernel: [ 10.323452] Loading modules > backported from Linux version v4.4-rc5-1913-gc8fdf68 > Thu May 12 05:36:24 2016 kern.info kernel: [ 10.329464] Backport generated > by backports.git backports-20151218-0-g2f58d9d > Thu May 12 05:36:24 2016 kern.info kernel: [ 10.340031] ip_tables: (C) > 2000-2006 Netfilter Core Team > Thu May 12 05:36:24 2016 kern.info kernel: [ 10.351117] Infineon > Technologies DEU driver version 2.0.0 > Thu May 12 05:36:24 2016 kern.notice kernel: [ 10.357203] IFX DEU DES > initialized (multiblock). > Thu May 12 05:36:24 2016 kern.notice kernel: [ 10.361497] IFX DEU AES > initialized (multiblock). > Thu May 12 05:36:24 2016 kern.notice kernel: [ 10.365620] IFX DEU ARC4 > initialized (multiblock). > Thu May 12 05:36:24 2016 kern.notice kernel: [ 10.370239] IFX DEU SHA1 > initialized. > Thu May 12 05:36:24 2016 kern.notice kernel: [ 10.373843] IFX DEU MD5 > initialized. > Thu May 12 05:36:24 2016 kern.notice kernel: [ 10.377438] IFX DEU > SHA1_HMAC initialized. > Thu May 12 05:36:24 2016 kern.notice kernel: [ 10.381556] IFX DEU MD5_HMAC > initialized. > Thu May 12 05:36:24 2016 kern.info kernel: [ 10.391907] nf_conntrack > version 0.5.0 (1946 buckets, 7784 max) > Thu May 12 05:36:24 2016 kern.info kernel: [ 10.418114] NET: Registered > protocol family 24 > Thu May 12 05:36:24 2016 kern.info kernel: [ 10.443723] xt_time: kernel > timezone is -0000 > Thu May 12 05:36:24 2016 kern.warn kernel: [ 10.539595] PCI: Enabling > device 0000:01:00.0 (0140 -> 0142) > Thu May 12 05:36:24 2016 kern.debug kernel: [ 10.550629] ath: EEPROM > regdomain: 0x8114 > Thu May 12 05:36:24 2016 kern.debug kernel: [ 10.550653] ath: EEPROM > indicates we should expect a country code > Thu May 12 05:36:24 2016 kern.debug kernel: [ 10.550667] ath: doing EEPROM > country->regdmn map search > Thu May 12 05:36:24 2016 kern.debug kernel: [ 10.550679] ath: country maps > to regdmn code: 0x37 > Thu May 12 05:36:24 2016 kern.debug kernel: [ 10.550692] ath: Country > alpha2 being used: DE > Thu May 12 05:36:24 2016 kern.debug kernel: [ 10.550704] ath: Regpair > used: 0x37 > Thu May 12 05:36:24 2016 kern.debug kernel: [ 10.564122] ieee80211 phy0: > Selected rate control algorithm 'minstrel_ht' > Thu May 12 05:36:24 2016 kern.info kernel: [ 10.567111] ieee80211 phy0: > Atheros AR9287 Rev:2 mem=0xbc000000, irq=144 > Thu May 12 05:36:25 2016 user.notice : 'radio0' is disabled > Thu May 12 05:36:25 2016 user.notice : 'radio0' is disabled > Thu May 12 05:36:26 2016 user.notice : firmware for annex a not found > Thu May 12 05:36:28 2016 authpriv.info dropbear[840]: Not backgrounding > Thu May 12 05:36:28 2016 user.notice : setting up led wifi > Thu May 12 05:36:28 2016 user.notice : setting up led dsl > Thu May 12 05:36:28 2016 user.notice : setting up led internet > Thu May 12 05:36:29 2016 daemon.info procd: - init complete - > Thu May 12 05:36:30 2016 kern.info kernel: [ 19.477228] device eth0.1 > entered promiscuous mode > Thu May 12 05:36:30 2016 kern.info kernel: [ 19.480651] device eth0 > entered promiscuous mode > Thu May 12 05:36:30 2016 kern.info kernel: [ 19.500394] br-lan: port > 1(eth0.1) entered forwarding state > Thu May 12 05:36:30 2016 kern.info kernel: [ 19.504638] br-lan: port > 1(eth0.1) entered forwarding state > Thu May 12 05:36:30 2016 daemon.notice netifd: Interface 'lan' is enabled > Thu May 12 05:36:30 2016 daemon.notice netifd: Interface 'lan' is setting up > now > Thu May 12 05:36:30 2016 daemon.notice netifd: Interface 'lan' is now up > Thu May 12 05:36:30 2016 daemon.notice netifd: Interface 'loopback' is > enabled > Thu May 12 05:36:30 2016 daemon.notice netifd: Interface 'loopback' is > setting up now > Thu May 12 05:36:30 2016 daemon.notice netifd: Interface 'loopback' is now > up > Thu May 12 05:36:30 2016 daemon.notice netifd: Bridge 'br-lan' link is up > Thu May 12 05:36:30 2016 daemon.notice netifd: Interface 'lan' has link > connectivity > Thu May 12 05:36:30 2016 daemon.notice netifd: Network device 'eth0' link is > up > Thu May 12 05:36:30 2016 daemon.notice netifd: VLAN 'eth0.1' link is up > Thu May 12 05:36:30 2016 daemon.notice netifd: Network device 'lo' link is > up > Thu May 12 05:36:30 2016 daemon.notice netifd: Interface 'loopback' has link > connectivity > Thu May 12 05:36:30 2016 user.notice firewall: Reloading firewall due to > ifup of lan (br-lan) > Thu May 12 05:36:32 2016 kern.info kernel: [ 21.506873] br-lan: port > 1(eth0.1) entered forwarding state > Thu May 12 05:36:35 2016 daemon.info dnsmasq[989]: started, version 2.75 > cachesize 150 > Thu May 12 05:36:35 2016 daemon.info dnsmasq[989]: compile time options: > IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP > no-conntrack no-ipset no-auth no-DNSSEC loop-detect inotify > Thu May 12 05:36:35 2016 daemon.info dnsmasq[989]: DNS service limited to > local subnets > Thu May 12 05:36:35 2016 daemon.info dnsmasq-dhcp[989]: DHCP, IP range > 192.168.2.100 -- 192.168.2.249, lease time 12h > Thu May 12 05:36:35 2016 daemon.info dnsmasq[989]: using local addresses > only for domain lan > Thu May 12 05:36:35 2016 daemon.warn dnsmasq[989]: no servers found in > /tmp/resolv.conf.auto, will retry > Thu May 12 05:36:35 2016 daemon.info dnsmasq[989]: read /etc/hosts - 4 > addresses > Thu May 12 05:36:35 2016 daemon.info dnsmasq[989]: read /tmp/hosts/dhcp - 2 > addresses > Thu May 12 05:36:35 2016 daemon.info dnsmasq-dhcp[989]: read /etc/ethers - 0 > addresses > Thu May 12 05:36:42 2016 kern.notice kernel: [ 31.802908] random: > nonblocking pool is initialized > > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From kron at animeland.de Sun May 15 15:45:27 2016 From: kron at animeland.de (Sebastian Ortwein) Date: Sun, 15 May 2016 21:45:27 +0200 Subject: [OpenWrt-Devel] Add support for AVM Fritzbox 7360 SL In-Reply-To: References: <69086bb8-44aa-05e4-a550-ee1b13633b4a@animeland.de> <572E254E.4030409@gmail.com> <44031fa7-cb40-d37c-79bd-f338bfba8b68@animeland.de> <93a04c66-d6a4-1c5f-d16c-80db337b6d3c@animeland.de> <2d877322-9bf3-7144-3620-589f652f75ef@animeland.de> Message-ID: <9bb07f9a-d02f-2af7-d60d-a40075aa9871@animeland.de> Am 15.05.2016 um 17:37 schrieb Martin Blumenstingl: > On Sun, May 15, 2016 at 3:44 PM, Sebastian Ortwein wrote: >> USB, WLAN and LAN works now. The only think what would not work is phy0 & >> phy1. >> I have attached my lastet patch. > if you google around a bit you'll find an AR8035 datasheet: that phy > is from the same series as the AR8030. > It defines that the RST pin is "active low" -> meaning you have to > pull it high to ensure that the PHY is not being reset: > http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/pinctrl/lantiq,pinctrl-xway.txt?v=4.4#L61 > This means you should probably use: > lantiq,output = <1>; > lantiq,pull = <2>; > lantiq,open-drain; > >> [ 0.993675] libphy: lantiq,xrx200-mdio: probed >> [ 1.004257] eth0: attached PHY [Generic PHY] (phy_addr=0:00, irq=-1) >> [ 1.009606] eth0: attached PHY [Generic PHY] (phy_addr=0:01, irq=-1) >> [ 1.079564] eth0: attached PHY [Lantiq XWAY VR9 GPHY 11G v1.4] >> (phy_addr=0:11, irq=-1) >> [ 1.147555] eth0: attached PHY [Lantiq XWAY VR9 GPHY 11G v1.4] >> (phy_addr=0:13, irq=-1) > "Generic PHY" means that no specific driver for this PHY is loaded. > Make sure you enable CONFIG_AT803X_PHY in target/linux/lantiq/config-4.4 > > Additionally you should check the phy-mode: > You are setting phy-mode = "rgmii", but Atheros says that the AR8030 > is an "Ultra low-power single RMII Fast Ethernet PHY". > Thus you should probably change "rgmii" to "rmii". > > > Martin Okay thank you for support. Now all thinks works fine LAN, WIFI, Switch and USB. I attach my patch to add the support for OpenWRT. Is there anything to do for including this patch in OpenWRT? Sebastian > On Sun, May 15, 2016 at 3:44 PM, Sebastian Ortwein wrote: >> Am 08.05.2016 um 18:40 schrieb Martin Blumenstingl: >>> On Sun, May 8, 2016 at 5:49 PM, Sebastian Ortwein >>> wrote: >>>> can I add it the following way ? >>>> mdio at 0 { >>>> #address-cells = <1>; >>>> #size-cells = <0>; >>>> compatible = "lantiq,xrx200-mdio"; >>>> phy0: ethernet-phy at 0 { >>>> reg = <0x0>; >>>> compatible = "lantiq,phy11g", >>>> "ethernet-phy-ieee802.3-c22"; >>>> gpios = <&gpio 37 0>; >>>> }; >>>> phy1: ethernet-phy at 1 { >>>> reg = <0x1>; >>>> compatible = "lantiq,phy11g", >>>> "ethernet-phy-ieee802.3-c22"; >>>> gpios = <&gpio 44 0>; >>>> }; >>>> phy11: ethernet-phy at 11 { >>>> reg = <0x11>; >>>> compatible = "lantiq,phy11g", >>>> "ethernet-phy-ieee802.3-c22"; >>>> }; >>>> phy13: ethernet-phy at 13 { >>>> reg = <0x13>; >>>> compatible = "lantiq,phy11g", >>>> "ethernet-phy-ieee802.3-c22"; >>>> }; >>> I think you have to name the property "reset-gpios", but apart from >>> that it looks good. >> I have try it like you sayed. But without success. >> I think the gpios are defined here, but it won't working. >> >> phy-rst { >> lantiq,pins = "io37", "io44"; >> lantiq,pull = <0>; >> lantiq,open-drain = <0>; >> lantiq,output = <1>; >> }; >> >>>>> I cannot see any ath9k messages in your kernel log - are you sure it's >>>>> being installed (/lib/modules/*/ath9k.ko)? >>>>> Your first patch lists kmod-ath9k, but if you added that after you >>>>> generated your .config then you're probably still missing it. >>>>> Please check "grep kmod-ath9k .config" and enable (set it to >>>>> =y/built-in) it if it's missing. >>>> I have not disable the ath9k driver. it is present and loaded. >>> I think I see the problem after looking at your .dts again: >>> you *must* specify the ath,pci-slot property, otherwise the fixup is >>> not executed. >>> It seems that the wifi part is similar to the TD-W8980 (AR9287 behind >>> the PCIe-to-PCI bridge), so "0" should be the right value. >>> (otherwise it's pretty easy to find out by looking at sysfs: >>> /sys/bus/pci/devices/0000\:00\:0e.0/ -> that's where the ath9k device >>> on HH5A can be found, there we use ath,pci-slot = <0xe>;) >>> >>> >>> Martin >>> >>> >>> [0] >>> https://github.com/openwrt/openwrt/blob/master/target/linux/lantiq/patches-4.4/0035-owrt-lantiq-wifi-and-ethernet-eeprom-handling.patch#L178 >> >> USB, WLAN and LAN works now. The only think what would not work is phy0 & >> phy1. >> I have attached my lastet patch. >> >> dmesg >> >> [ 0.000000] Linux version 4.4.7 (sebastian at sebastian-desktop) (gcc >> version 5.3.0 (OpenWrt GCC 5.3.0 r49377) ) #1 Sun May 15 13:18:03 UTC 2016 >> [ 0.000000] SoC: xRX200 rev 1.1 >> [ 0.000000] bootconsole [early0] enabled >> [ 0.000000] CPU0 revision is: 00019555 (MIPS 34Kc) >> [ 0.000000] MIPS: machine is FRITZ7360SL - 1&1 HomeServer >> [ 0.000000] Determined physical RAM map: >> [ 0.000000] memory: 08000000 @ 00000000 (usable) >> [ 0.000000] Initrd not found or empty - disabling initrd >> [ 0.000000] Zone ranges: >> [ 0.000000] Normal [mem 0x0000000000000000-0x0000000007ffffff] >> [ 0.000000] Movable zone start for each node >> [ 0.000000] Early memory node ranges >> [ 0.000000] node 0: [mem 0x0000000000000000-0x0000000007ffffff] >> [ 0.000000] Initmem setup node 0 [mem >> 0x0000000000000000-0x0000000007ffffff] >> [ 0.000000] On node 0 totalpages: 32768 >> [ 0.000000] free_area_init_node: node 0, pgdat 804d6390, node_mem_map >> 81007b60 >> [ 0.000000] Normal zone: 256 pages used for memmap >> [ 0.000000] Normal zone: 0 pages reserved >> [ 0.000000] Normal zone: 32768 pages, LIFO batch:7 >> [ 0.000000] Primary instruction cache 32kB, VIPT, 4-way, linesize 32 >> bytes. >> [ 0.000000] Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize >> 32 bytes >> [ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 >> [ 0.000000] pcpu-alloc: [0] 0 >> [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total >> pages: 32512 >> [ 0.000000] Kernel command line: console=ttyLTQ0,115200 init=/etc/preinit >> [ 0.000000] PID hash table entries: 512 (order: -1, 2048 bytes) >> [ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 >> bytes) >> [ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) >> [ 0.000000] Writing ErrCtl register=00074200 >> [ 0.000000] Readback ErrCtl register=00074200 >> [ 0.000000] Memory: 123372K/131072K available (3764K kernel code, 164K >> rwdata, 1144K rodata, 1184K init, 211K bss, 7700K reserved, 0K cma-reserved) >> [ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 >> [ 0.000000] NR_IRQS:256 >> [ 0.000000] CPU Clock: 500MHz >> [ 0.000000] clocksource: MIPS: mask: 0xffffffff max_cycles: 0xffffffff, >> max_idle_ns: 7645041786 ns >> [ 0.000011] sched_clock: 32 bits at 250MHz, resolution 4ns, wraps every >> 8589934590ns >> [ 0.007861] Calibrating delay loop... 332.54 BogoMIPS (lpj=665088) >> [ 0.042318] pid_max: default: 32768 minimum: 301 >> [ 0.047172] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) >> [ 0.053732] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 >> bytes) >> [ 0.066701] clocksource: jiffies: mask: 0xffffffff max_cycles: >> 0xffffffff, max_idle_ns: 7645041785100000 ns >> [ 0.076483] pinctrl core: initialized pinctrl subsystem >> [ 0.082366] NET: Registered protocol family 16 >> [ 0.091505] pinctrl-xway 1e100b10.pinmux: Init done >> [ 0.097056] dma-xway 1e104100.dma: Init done - hw rev: 7, ports: 7, >> channels: 28 >> [ 0.207159] dcdc-xrx200 1f106a00.dcdc: Core Voltage : 1016 mV >> [ 0.333371] ath9k,eeprom ath9k_eep: failed to load eeprom address >> [ 0.354429] usbcore: registered new interface driver usbfs >> [ 0.359938] usbcore: registered new interface driver hub >> [ 0.365292] usbcore: registered new device driver usb >> [ 0.370641] PCI host bridge to bus 0000:00 >> [ 0.374631] pci_bus 0000:00: root bus resource [mem 0x1c000000-0x1cffffff] >> [ 0.381545] pci_bus 0000:00: root bus resource [io 0x1d800000-0x1d8fffff] >> [ 0.388488] pci_bus 0000:00: root bus resource [??? 0x00000000 flags 0x0] >> [ 0.395343] pci_bus 0000:00: No busn resource found for root bus, will use >> [bus 00-ff] >> [ 0.403373] pci 0000:00:00.0: [15d1:0011] type 01 class 0x060000 >> [ 0.403410] ifx_pcie_rc_class_early_fixup: fixed pcie host bridge to pci-pci >> bridge >> [ 0.421054] ifx_pcie_fixup_resource: fixup host controller 0000:00:00.0 >> (15d1:0011) >> [ 0.428645] pci 0000:00:00.0: PME# supported from D0 D3hot >> [ 0.429208] pci 0000:01:00.0: [168c:ff1c] type 00 class 0x020000 >> [ 0.429298] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x0000ffff 64bit] >> [ 0.429454] pci 0000:01:00.0: supports D1 >> [ 0.429475] pci 0000:01:00.0: PME# supported from D0 D1 D3hot >> [ 0.429773] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01 >> [ 0.429814] pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 01 >> [ 0.429870] pci 0000:00:00.0: BAR 8: assigned [mem 0x1c000000-0x1c0fffff] >> [ 0.436557] pci 0000:01:00.0: BAR 0: assigned [mem 0x1c000000-0x1c00ffff >> 64bit] >> [ 0.443919] pci 0000:00:00.0: PCI bridge to [bus 01] >> [ 0.448935] pci 0000:00:00.0: bridge window [mem 0x1c000000-0x1c0fffff] >> [ 0.455810] ifx_pcie_bios_map_irq port 0 dev 0000:00:00.0 slot 0 pin 1 >> [ 0.462461] ifx_pcie_bios_map_irq dev 0000:00:00.0 irq 144 assigned >> [ 0.468815] ifx_pcie_bios_map_irq port 0 dev 0000:01:00.0 slot 0 pin 1 >> [ 0.475481] ifx_pcie_bios_map_irq dev 0000:01:00.0 irq 144 assigned >> [ 0.482864] clocksource: Switched to clocksource MIPS >> [ 0.489513] NET: Registered protocol family 2 >> [ 0.494738] TCP established hash table entries: 1024 (order: 0, 4096 bytes) >> [ 0.501634] TCP bind hash table entries: 1024 (order: 0, 4096 bytes) >> [ 0.508012] TCP: Hash tables configured (established 1024 bind 1024) >> [ 0.514529] UDP hash table entries: 256 (order: 0, 4096 bytes) >> [ 0.520367] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) >> [ 0.526969] NET: Registered protocol family 1 >> [ 0.531315] PCI: CLS 0 bytes, default 32 >> [ 0.531770] gptu: totally 6 16-bit timers/counters >> [ 0.536615] gptu: misc_register on minor 63 >> [ 0.540712] gptu: succeeded to request irq 126 >> [ 0.545201] gptu: succeeded to request irq 127 >> [ 0.549715] gptu: succeeded to request irq 128 >> [ 0.554229] gptu: succeeded to request irq 129 >> [ 0.558742] gptu: succeeded to request irq 130 >> [ 0.563259] gptu: succeeded to request irq 131 >> [ 0.568633] phy-xrx200 gphy-xrx200: requesting lantiq/vr9_phy11g_a1x.bin >> [ 0.575912] phy-xrx200 gphy-xrx200: booting GPHY0 firmware at 7960000 >> [ 0.582260] phy-xrx200 gphy-xrx200: booting GPHY1 firmware at 7960000 >> [ 0.689806] futex hash table entries: 256 (order: -1, 3072 bytes) >> [ 0.723154] squashfs: version 4.0 (2009/01/31) Phillip Lougher >> [ 0.728894] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) >> (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc. >> [ 0.742291] io scheduler noop registered >> [ 0.746134] io scheduler deadline registered (default) >> [ 0.751978] 1e100c00.serial: ttyLTQ0 at MMIO 0x1e100c00 (irq = 112, >> base_baud = 0) is a lantiq,asc >> [ 0.760881] console [ttyLTQ0] enabled >> [ 0.768206] bootconsole [early0] disabled >> [ 0.777268] lantiq nor flash device: 01000000 at 10000000 >> [ 0.781402] ltq_nor: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer >> ID 0x000001 Chip ID 0x002101 >> [ 0.790840] Amd/Fujitsu Extended Query Table at 0x0040 >> [ 0.795967] Amd/Fujitsu Extended Query version 1.3. >> [ 0.801004] number of CFI chips: 1 >> [ 0.804436] 4 ofpart partitions found on MTD device ltq_nor >> [ 0.809969] Creating 4 MTD partitions on "ltq_nor": >> [ 0.814852] 0x000000000000-0x000000020000 : "urlader" >> [ 0.823305] 0x000000020000-0x000000f80000 : "firmware" >> [ 0.844284] 2 eva-fw partitions found on MTD device firmware >> [ 0.848534] 0x000000020000-0x0000001bfa70 : "kernel" >> [ 0.855348] 0x0000001c0100-0x000000f80000 : "rootfs" >> [ 0.860994] mtd: device 3 (rootfs) set to be root filesystem >> [ 0.865302] 1 squashfs-split partitions found on MTD device rootfs >> [ 0.871420] 0x0000003e0000-0x000000f80000 : "rootfs_data" >> [ 0.879057] 0x000000f80000-0x000000fc0000 : "tffs (1)" >> [ 0.884936] 0x000000fc0000-0x000001000000 : "tffs (2)" >> [ 0.993675] libphy: lantiq,xrx200-mdio: probed >> [ 1.004257] eth0: attached PHY [Generic PHY] (phy_addr=0:00, irq=-1) >> [ 1.009606] eth0: attached PHY [Generic PHY] (phy_addr=0:01, irq=-1) >> [ 1.079564] eth0: attached PHY [Lantiq XWAY VR9 GPHY 11G v1.4] >> (phy_addr=0:11, irq=-1) >> [ 1.147555] eth0: attached PHY [Lantiq XWAY VR9 GPHY 11G v1.4] >> (phy_addr=0:13, irq=-1) >> [ 1.155438] wdt 1f8803f0.watchdog: Init done >> [ 1.161244] NET: Registered protocol family 10 >> [ 1.169748] NET: Registered protocol family 17 >> [ 1.172899] bridge: automatic filtering via arp/ip/ip6tables has been >> deprecated. Update your scripts to load br_netfilter if you need this. >> [ 1.185425] 8021q: 802.1Q VLAN Support v1.8 >> [ 1.189680] found entry name -> annex=B >> [ 1.193440] found entry name -> maca=BC:05:43:D7:1E:7C >> [ 1.198534] found entry name -> macb=BC:05:43:D7:1E:7D >> [ 1.203673] found entry name -> macwlan=BC:05:43:D7:1E:7E >> [ 1.209066] found entry name -> macdsl=BC:05:43:D7:1E:7F >> [ 1.214430] found entry name -> macwlan2=BC:05:43:D7:1E:81 >> [ 1.219861] found entry name -> wlan_key=4004584479108575 >> [ 1.228307] ath9k,eeprom ath9k_eep: endian check enabled. >> [ 1.232282] ath9k,eeprom ath9k_eep: using random mac >> [ 1.237274] ath9k,eeprom ath9k_eep: pci slot: 0 >> [ 1.241777] pci 0000:01:00.0: fixup device configuration >> [ 1.247149] PCI: Enabling device 0000:01:00.0 (0000 -> 0002) >> [ 1.254428] pci 0000:01:00.0: fixup info: [168c:002e] revision 01 class >> 0x028000 >> [ 1.260435] ath9k,eeprom ath9k_eep: loaded ath9k eeprom >> [ 1.270378] UBIFS error (pid: 1): cannot open "ubi0:rootfs", error -19 >> [ 1.280211] VFS: Mounted root (squashfs filesystem) readonly on device >> 31:3. >> [ 1.287767] Freeing unused kernel memory: 1184K (804f8000 - 80620000) >> [ 2.468013] init: Console is alive >> [ 2.470263] init: - watchdog - >> [ 3.884244] dwc2 1e101000.ifxhcd: Configuration mismatch. Forcing host >> mode >> [ 4.035028] eth0: port 0 got link >> [ 4.747073] dwc2 1e101000.ifxhcd: DWC OTG Controller >> [ 4.750648] dwc2 1e101000.ifxhcd: new USB bus registered, assigned bus >> number 1 >> [ 4.757999] dwc2 1e101000.ifxhcd: irq 62, io mem 0x00000000 >> [ 4.763516] dwc2 1e101000.ifxhcd: Hardware does not support descriptor >> DMA mode - >> [ 4.770953] dwc2 1e101000.ifxhcd: falling back to buffer DMA mode. >> [ 4.778435] hub 1-0:1.0: USB hub found >> [ 4.781398] hub 1-0:1.0: 1 port detected >> [ 4.785460] dwc2 1e106000.ifxhcd: Configuration mismatch. Forcing host >> mode >> [ 5.647060] dwc2 1e106000.ifxhcd: DWC OTG Controller >> [ 5.650655] dwc2 1e106000.ifxhcd: new USB bus registered, assigned bus >> number 2 >> [ 5.657970] dwc2 1e106000.ifxhcd: irq 91, io mem 0x00000000 >> [ 5.663499] dwc2 1e106000.ifxhcd: Hardware does not support descriptor >> DMA mode - >> [ 5.670938] dwc2 1e106000.ifxhcd: falling back to buffer DMA mode. >> [ 5.678440] hub 2-0:1.0: USB hub found >> [ 5.681390] hub 2-0:1.0: 1 port detected >> [ 5.687615] init: - preinit - >> [ 6.192804] random: procd urandom read with 26 bits of entropy available >> [ 8.569614] jffs2: notice: (370) jffs2_build_xattr_subsystem: complete >> building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref >> (0 dead, 0 orphan) found. >> [ 8.585353] mount_root: switching to jffs2 overlay >> [ 8.606254] procd: - early - >> [ 8.607917] procd: - watchdog - >> [ 9.348938] procd: - ubus - >> [ 9.403903] procd: - init - >> [ 10.231370] IFXOS, Version 1.5.19 (c) Copyright 2009, Lantiq Deutschland >> GmbH >> [ 10.241461] NET: Registered protocol family 8 >> [ 10.244431] NET: Registered protocol family 20 >> [ 10.255629] PPP generic driver version 2.4.2 >> [ 10.266429] ip6_tables: (C) 2000-2006 Netfilter Core Team >> [ 10.291707] Lantiq (VRX) DSL CPE MEI driver, version 1.4.8.5, (c) 2013 >> Lantiq Deutschland GmbH >> [ 10.291707] >> [ 10.291707] Lantiq CPE API Driver version: DSL CPE API V4.16.6.3 >> [ 10.312794] >> [ 10.312794] Predefined debug level: 3 >> [ 10.323452] Loading modules backported from Linux version >> v4.4-rc5-1913-gc8fdf68 >> [ 10.329464] Backport generated by backports.git >> backports-20151218-0-g2f58d9d >> [ 10.340031] ip_tables: (C) 2000-2006 Netfilter Core Team >> [ 10.351117] Infineon Technologies DEU driver version 2.0.0 >> [ 10.357203] IFX DEU DES initialized (multiblock). >> [ 10.361497] IFX DEU AES initialized (multiblock). >> [ 10.365620] IFX DEU ARC4 initialized (multiblock). >> [ 10.370239] IFX DEU SHA1 initialized. >> [ 10.373843] IFX DEU MD5 initialized. >> [ 10.377438] IFX DEU SHA1_HMAC initialized. >> [ 10.381556] IFX DEU MD5_HMAC initialized. >> [ 10.391907] nf_conntrack version 0.5.0 (1946 buckets, 7784 max) >> [ 10.418114] NET: Registered protocol family 24 >> [ 10.443723] xt_time: kernel timezone is -0000 >> [ 10.539595] PCI: Enabling device 0000:01:00.0 (0140 -> 0142) >> [ 10.550629] ath: EEPROM regdomain: 0x8114 >> [ 10.550653] ath: EEPROM indicates we should expect a country code >> [ 10.550667] ath: doing EEPROM country->regdmn map search >> [ 10.550679] ath: country maps to regdmn code: 0x37 >> [ 10.550692] ath: Country alpha2 being used: DE >> [ 10.550704] ath: Regpair used: 0x37 >> [ 10.564122] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' >> [ 10.567111] ieee80211 phy0: Atheros AR9287 Rev:2 mem=0xbc000000, irq=144 >> [ 19.477228] device eth0.1 entered promiscuous mode >> [ 19.480651] device eth0 entered promiscuous mode >> [ 19.500394] br-lan: port 1(eth0.1) entered forwarding state >> [ 19.504638] br-lan: port 1(eth0.1) entered forwarding state >> [ 21.506873] br-lan: port 1(eth0.1) entered forwarding state >> [ 31.802908] random: nonblocking pool is initialized >> >> >> logread >> >> hu May 12 05:36:24 2016 kern.info kernel: [ 0.381545] pci_bus 0000:00: root >> bus resource [io 0x1d800000-0x1d8fffff] >> Thu May 12 05:36:24 2016 kern.info kernel: [ 0.388488] pci_bus 0000:00: root >> bus resource [??? 0x00000000 flags 0x0] >> Thu May 12 05:36:24 2016 kern.info kernel: [ 0.395343] pci_bus 0000:00: No >> busn resource found for root bus, will use [bus 00-ff] >> Thu May 12 05:36:24 2016 kern.debug kernel: [ 0.403373] pci 0000:00:00.0: >> [15d1:0011] type 01 class 0x060000 >> Thu May 12 05:36:24 2016 kern.info kernel: [ 0.403410] >> ifx_pcie_rc_class_early_fixup: fixed pcie host bridge to pci-pci bridge >> Thu May 12 05:36:24 2016 kern.warn kernel: [ 0.421054] >> ifx_pcie_fixup_resource: fixup host controller 0000:00:00.0 (15d1:0011) >> Thu May 12 05:36:24 2016 kern.debug kernel: [ 0.428645] pci 0000:00:00.0: >> PME# supported from D0 D3hot >> Thu May 12 05:36:24 2016 kern.debug kernel: [ 0.429208] pci 0000:01:00.0: >> [168c:ff1c] type 00 class 0x020000 >> Thu May 12 05:36:24 2016 kern.debug kernel: [ 0.429298] pci 0000:01:00.0: >> reg 0x10: [mem 0x00000000-0x0000ffff 64bit] >> Thu May 12 05:36:24 2016 kern.debug kernel: [ 0.429454] pci 0000:01:00.0: >> supports D1 >> Thu May 12 05:36:24 2016 kern.debug kernel: [ 0.429475] pci 0000:01:00.0: >> PME# supported from D0 D1 D3hot >> Thu May 12 05:36:24 2016 kern.debug kernel: [ 0.429773] pci_bus 0000:01: >> busn_res: [bus 01-ff] end is updated to 01 >> Thu May 12 05:36:24 2016 kern.debug kernel: [ 0.429814] pci_bus 0000:00: >> busn_res: [bus 00-ff] end is updated to 01 >> Thu May 12 05:36:24 2016 kern.info kernel: [ 0.429870] pci 0000:00:00.0: BAR >> 8: assigned [mem 0x1c000000-0x1c0fffff] >> Thu May 12 05:36:24 2016 kern.info kernel: [ 0.436557] pci 0000:01:00.0: BAR >> 0: assigned [mem 0x1c000000-0x1c00ffff 64bit] >> Thu May 12 05:36:24 2016 kern.info kernel: [ 0.443919] pci 0000:00:00.0: PCI >> bridge to [bus 01] >> Thu May 12 05:36:24 2016 kern.info kernel: [ 0.448935] pci 0000:00:00.0: >> bridge window [mem 0x1c000000-0x1c0fffff] >> Thu May 12 05:36:24 2016 kern.warn kernel: [ 0.455810] ifx_pcie_bios_map_irq >> port 0 dev 0000:00:00.0 slot 0 pin 1 >> Thu May 12 05:36:24 2016 kern.warn kernel: [ 0.462461] ifx_pcie_bios_map_irq >> dev 0000:00:00.0 irq 144 assigned >> Thu May 12 05:36:24 2016 kern.warn kernel: [ 0.468815] ifx_pcie_bios_map_irq >> port 0 dev 0000:01:00.0 slot 0 pin 1 >> Thu May 12 05:36:24 2016 kern.warn kernel: [ 0.475481] ifx_pcie_bios_map_irq >> dev 0000:01:00.0 irq 144 assigned >> Thu May 12 05:36:24 2016 kern.info kernel: [ 0.482864] clocksource: Switched >> to clocksource MIPS >> Thu May 12 05:36:24 2016 kern.info kernel: [ 0.489513] NET: Registered >> protocol family 2 >> Thu May 12 05:36:24 2016 kern.info kernel: [ 0.494738] TCP established hash >> table entries: 1024 (order: 0, 4096 bytes) >> Thu May 12 05:36:24 2016 kern.info kernel: [ 0.501634] TCP bind hash >> table entries: 1024 (order: 0, 4096 bytes) >> Thu May 12 05:36:24 2016 kern.info kernel: [ 0.508012] TCP: Hash tables >> configured (established 1024 bind 1024) >> Thu May 12 05:36:24 2016 kern.info kernel: [ 0.514529] UDP hash table >> entries: 256 (order: 0, 4096 bytes) >> Thu May 12 05:36:24 2016 kern.info kernel: [ 0.520367] UDP-Lite hash table >> entries: 256 (order: 0, 4096 bytes) >> Thu May 12 05:36:24 2016 kern.info kernel: [ 0.526969] NET: Registered >> protocol family 1 >> Thu May 12 05:36:24 2016 kern.debug kernel: [ 0.531315] PCI: CLS 0 bytes, >> default 32 >> Thu May 12 05:36:24 2016 kern.info kernel: [ 0.531770] gptu: totally 6 >> 16-bit timers/counters >> Thu May 12 05:36:24 2016 kern.info kernel: [ 0.536615] gptu: misc_register >> on minor 63 >> Thu May 12 05:36:24 2016 kern.info kernel: [ 0.540712] gptu: succeeded to >> request irq 126 >> Thu May 12 05:36:24 2016 kern.info kernel: [ 0.545201] gptu: succeeded to >> request irq 127 >> Thu May 12 05:36:24 2016 kern.info kernel: [ 0.549715] gptu: succeeded to >> request irq 128 >> Thu May 12 05:36:24 2016 kern.info kernel: [ 0.554229] gptu: succeeded to >> request irq 129 >> Thu May 12 05:36:24 2016 kern.info kernel: [ 0.558742] gptu: succeeded to >> request irq 130 >> Thu May 12 05:36:24 2016 kern.info kernel: [ 0.563259] gptu: succeeded to >> request irq 131 >> Thu May 12 05:36:24 2016 kern.info kernel: [ 0.568633] phy-xrx200 >> gphy-xrx200: requesting lantiq/vr9_phy11g_a1x.bin >> Thu May 12 05:36:24 2016 kern.info kernel: [ 0.575912] phy-xrx200 >> gphy-xrx200: booting GPHY0 firmware at 7960000 >> Thu May 12 05:36:24 2016 kern.info kernel: [ 0.582260] phy-xrx200 >> gphy-xrx200: booting GPHY1 firmware at 7960000 >> Thu May 12 05:36:24 2016 kern.info kernel: [ 0.689806] futex hash table >> entries: 256 (order: -1, 3072 bytes) >> Thu May 12 05:36:24 2016 kern.info kernel: [ 0.723154] squashfs: version 4.0 >> (2009/01/31) Phillip Lougher >> Thu May 12 05:36:24 2016 kern.info kernel: [ 0.728894] jffs2: version 2.2 >> (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc. >> Thu May 12 05:36:24 2016 kern.info kernel: [ 0.742291] io scheduler noop >> registered >> Thu May 12 05:36:24 2016 kern.info kernel: [ 0.746134] io scheduler deadline >> registered (default) >> Thu May 12 05:36:24 2016 kern.info kernel: [ 0.751978] 1e100c00.serial: >> ttyLTQ0 at MMIO 0x1e100c00 (irq = 112, base_baud = 0) is a lantiq,asc >> Thu May 12 05:36:24 2016 kern.info kernel: [ 0.760881] console [ttyLTQ0] >> enabled >> Thu May 12 05:36:24 2016 kern.info kernel: [ 0.768206] bootconsole [early0] >> disabled >> Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.777268] lantiq nor flash >> device: 01000000 at 10000000 >> Thu May 12 05:36:24 2016 kern.info kernel: [ 0.781402] ltq_nor: Found 1 x16 >> devices at 0x0 in 16-bit bank. Manufacturer ID 0x000001 Chip ID 0x002101 >> Thu May 12 05:36:24 2016 kern.info kernel: [ 0.790840] Amd/Fujitsu Extended >> Query Table at 0x0040 >> Thu May 12 05:36:24 2016 kern.info kernel: [ 0.795967] Amd/Fujitsu Extended >> Query version 1.3. >> Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.801004] number of CFI >> chips: 1 >> Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.804436] 4 ofpart partitions >> found on MTD device ltq_nor >> Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.809969] Creating 4 MTD >> partitions on "ltq_nor": >> Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.814852] >> 0x000000000000-0x000000020000 : "urlader" >> Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.823305] >> 0x000000020000-0x000000f80000 : "firmware" >> Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.844284] 2 eva-fw partitions >> found on MTD device firmware >> Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.848534] >> 0x000000020000-0x0000001bfa70 : "kernel" >> Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.855348] >> 0x0000001c0100-0x000000f80000 : "rootfs" >> Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.860994] mtd: device 3 >> (rootfs) set to be root filesystem >> Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.865302] 1 squashfs-split >> partitions found on MTD device rootfs >> Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.871420] >> 0x0000003e0000-0x000000f80000 : "rootfs_data" >> Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.879057] >> 0x000000f80000-0x000000fc0000 : "tffs (1)" >> Thu May 12 05:36:24 2016 kern.notice kernel: [ 0.884936] >> 0x000000fc0000-0x000001000000 : "tffs (2)" >> Thu May 12 05:36:24 2016 kern.info kernel: [ 0.993675] libphy: >> lantiq,xrx200-mdio: probed >> Thu May 12 05:36:24 2016 kern.info kernel: [ 1.004257] eth0: attached PHY >> [Generic PHY] (phy_addr=0:00, irq=-1) >> Thu May 12 05:36:24 2016 kern.info kernel: [ 1.009606] eth0: attached PHY >> [Generic PHY] (phy_addr=0:01, irq=-1) >> Thu May 12 05:36:24 2016 kern.info kernel: [ 1.079564] eth0: attached PHY >> [Lantiq XWAY VR9 GPHY 11G v1.4] (phy_addr=0:11, irq=-1) >> Thu May 12 05:36:24 2016 kern.info kernel: [ 1.147555] eth0: attached PHY >> [Lantiq XWAY VR9 GPHY 11G v1.4] (phy_addr=0:13, irq=-1) >> Thu May 12 05:36:24 2016 kern.info kernel: [ 1.155438] wdt >> 1f8803f0.watchdog: Init done >> Thu May 12 05:36:24 2016 kern.info kernel: [ 1.161244] NET: Registered >> protocol family 10 >> Thu May 12 05:36:24 2016 kern.info kernel: [ 1.169748] NET: Registered >> protocol family 17 >> Thu May 12 05:36:24 2016 kern.info kernel: [ 1.172899] bridge: automatic >> filtering via arp/ip/ip6tables has been deprecated. Update your scripts to >> load br_netfilter if you need this. >> Thu May 12 05:36:24 2016 kern.info kernel: [ 1.185425] 8021q: 802.1Q VLAN >> Support v1.8 >> Thu May 12 05:36:24 2016 kern.info kernel: [ 1.189680] found entry name >> -> annex=B >> Thu May 12 05:36:24 2016 kern.info kernel: [ 1.193440] found entry name >> -> maca=BC:05:43:D7:1E:7C >> Thu May 12 05:36:24 2016 kern.info kernel: [ 1.198534] found entry name >> -> macb=BC:05:43:D7:1E:7D >> Thu May 12 05:36:24 2016 kern.info kernel: [ 1.203673] found entry name >> -> macwlan=BC:05:43:D7:1E:7E >> Thu May 12 05:36:24 2016 kern.info kernel: [ 1.209066] found entry name >> -> macdsl=BC:05:43:D7:1E:7F >> Thu May 12 05:36:24 2016 kern.info kernel: [ 1.214430] found entry name >> -> macwlan2=BC:05:43:D7:1E:81 >> Thu May 12 05:36:24 2016 kern.info kernel: [ 1.219861] found entry name >> -> wlan_key=4004584479108575 >> Thu May 12 05:36:24 2016 kern.info kernel: [ 1.228307] ath9k,eeprom >> ath9k_eep: endian check enabled. >> Thu May 12 05:36:24 2016 kern.warn kernel: [ 1.232282] ath9k,eeprom >> ath9k_eep: using random mac >> Thu May 12 05:36:24 2016 kern.info kernel: [ 1.237274] ath9k,eeprom >> ath9k_eep: pci slot: 0 >> Thu May 12 05:36:24 2016 kern.info kernel: [ 1.241777] pci 0000:01:00.0: >> fixup device configuration >> Thu May 12 05:36:24 2016 kern.warn kernel: [ 1.247149] PCI: Enabling >> device 0000:01:00.0 (0000 -> 0002) >> Thu May 12 05:36:24 2016 kern.info kernel: [ 1.254428] pci 0000:01:00.0: >> fixup info: [168c:002e] revision 01 class 0x028000 >> Thu May 12 05:36:24 2016 kern.info kernel: [ 1.260435] ath9k,eeprom >> ath9k_eep: loaded ath9k eeprom >> Thu May 12 05:36:24 2016 kern.err kernel: [ 1.270378] UBIFS error (pid: >> 1): cannot open "ubi0:rootfs", error -19 >> Thu May 12 05:36:24 2016 kern.info kernel: [ 1.280211] VFS: Mounted root >> (squashfs filesystem) readonly on device 31:3. >> Thu May 12 05:36:24 2016 kern.info kernel: [ 1.287767] Freeing unused >> kernel memory: 1184K (804f8000 - 80620000) >> Thu May 12 05:36:24 2016 user.info kernel: [ 2.468013] init: Console is >> alive >> Thu May 12 05:36:24 2016 user.info kernel: [ 2.470263] init: - watchdog - >> Thu May 12 05:36:24 2016 kern.warn kernel: [ 3.884244] dwc2 >> 1e101000.ifxhcd: Configuration mismatch. Forcing host mode >> Thu May 12 05:36:24 2016 kern.info kernel: [ 4.035028] eth0: port 0 got >> link >> Thu May 12 05:36:24 2016 kern.info kernel: [ 4.747073] dwc2 >> 1e101000.ifxhcd: DWC OTG Controller >> Thu May 12 05:36:24 2016 kern.info kernel: [ 4.750648] dwc2 >> 1e101000.ifxhcd: new USB bus registered, assigned bus number 1 >> Thu May 12 05:36:24 2016 kern.info kernel: [ 4.757999] dwc2 >> 1e101000.ifxhcd: irq 62, io mem 0x00000000 >> Thu May 12 05:36:24 2016 kern.err kernel: [ 4.763516] dwc2 >> 1e101000.ifxhcd: Hardware does not support descriptor DMA mode - >> Thu May 12 05:36:24 2016 kern.err kernel: [ 4.770953] dwc2 >> 1e101000.ifxhcd: falling back to buffer DMA mode. >> Thu May 12 05:36:24 2016 kern.info kernel: [ 4.778435] hub 1-0:1.0: USB >> hub found >> Thu May 12 05:36:24 2016 kern.info kernel: [ 4.781398] hub 1-0:1.0: 1 >> port detected >> Thu May 12 05:36:24 2016 kern.warn kernel: [ 4.785460] dwc2 >> 1e106000.ifxhcd: Configuration mismatch. Forcing host mode >> Thu May 12 05:36:24 2016 kern.info kernel: [ 5.647060] dwc2 >> 1e106000.ifxhcd: DWC OTG Controller >> Thu May 12 05:36:24 2016 kern.info kernel: [ 5.650655] dwc2 >> 1e106000.ifxhcd: new USB bus registered, assigned bus number 2 >> Thu May 12 05:36:24 2016 kern.info kernel: [ 5.657970] dwc2 >> 1e106000.ifxhcd: irq 91, io mem 0x00000000 >> Thu May 12 05:36:24 2016 kern.err kernel: [ 5.663499] dwc2 >> 1e106000.ifxhcd: Hardware does not support descriptor DMA mode - >> Thu May 12 05:36:24 2016 kern.err kernel: [ 5.670938] dwc2 >> 1e106000.ifxhcd: falling back to buffer DMA mode. >> Thu May 12 05:36:24 2016 kern.info kernel: [ 5.678440] hub 2-0:1.0: USB >> hub found >> Thu May 12 05:36:24 2016 kern.info kernel: [ 5.681390] hub 2-0:1.0: 1 >> port detected >> Thu May 12 05:36:24 2016 user.info kernel: [ 5.687615] init: - preinit - >> Thu May 12 05:36:24 2016 kern.notice kernel: [ 6.192804] random: procd >> urandom read with 26 bits of entropy available >> Thu May 12 05:36:24 2016 kern.notice kernel: [ 8.569614] jffs2: notice: >> (370) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of >> xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found. >> Thu May 12 05:36:24 2016 user.info kernel: [ 8.585353] mount_root: >> switching to jffs2 overlay >> Thu May 12 05:36:24 2016 user.info kernel: [ 8.606254] procd: - early - >> Thu May 12 05:36:24 2016 user.info kernel: [ 8.607917] procd: - watchdog >> - >> Thu May 12 05:36:24 2016 user.info kernel: [ 9.348938] procd: - ubus - >> Thu May 12 05:36:24 2016 user.info kernel: [ 9.403903] procd: - init - >> Thu May 12 05:36:24 2016 kern.info kernel: [ 10.231370] IFXOS, Version >> 1.5.19 (c) Copyright 2009, Lantiq Deutschland GmbH >> Thu May 12 05:36:24 2016 kern.info kernel: [ 10.241461] NET: Registered >> protocol family 8 >> Thu May 12 05:36:24 2016 kern.info kernel: [ 10.244431] NET: Registered >> protocol family 20 >> Thu May 12 05:36:24 2016 kern.info kernel: [ 10.255629] PPP generic driver >> version 2.4.2 >> Thu May 12 05:36:24 2016 kern.info kernel: [ 10.266429] ip6_tables: (C) >> 2000-2006 Netfilter Core Team >> Thu May 12 05:36:24 2016 kern.info kernel: [ 10.291707] Lantiq (VRX) DSL >> CPE MEI driver, version 1.4.8.5, (c) 2013 Lantiq Deutschland GmbH >> Thu May 12 05:36:24 2016 kern.info kernel: [ 10.291707] >> Thu May 12 05:36:24 2016 kern.info kernel: [ 10.291707] Lantiq CPE API >> Driver version: DSL CPE API V4.16.6.3 >> Thu May 12 05:36:24 2016 kern.warn kernel: [ 10.312794] >> Thu May 12 05:36:24 2016 kern.warn kernel: [ 10.312794] Predefined debug >> level: 3 >> Thu May 12 05:36:24 2016 kern.info kernel: [ 10.323452] Loading modules >> backported from Linux version v4.4-rc5-1913-gc8fdf68 >> Thu May 12 05:36:24 2016 kern.info kernel: [ 10.329464] Backport generated >> by backports.git backports-20151218-0-g2f58d9d >> Thu May 12 05:36:24 2016 kern.info kernel: [ 10.340031] ip_tables: (C) >> 2000-2006 Netfilter Core Team >> Thu May 12 05:36:24 2016 kern.info kernel: [ 10.351117] Infineon >> Technologies DEU driver version 2.0.0 >> Thu May 12 05:36:24 2016 kern.notice kernel: [ 10.357203] IFX DEU DES >> initialized (multiblock). >> Thu May 12 05:36:24 2016 kern.notice kernel: [ 10.361497] IFX DEU AES >> initialized (multiblock). >> Thu May 12 05:36:24 2016 kern.notice kernel: [ 10.365620] IFX DEU ARC4 >> initialized (multiblock). >> Thu May 12 05:36:24 2016 kern.notice kernel: [ 10.370239] IFX DEU SHA1 >> initialized. >> Thu May 12 05:36:24 2016 kern.notice kernel: [ 10.373843] IFX DEU MD5 >> initialized. >> Thu May 12 05:36:24 2016 kern.notice kernel: [ 10.377438] IFX DEU >> SHA1_HMAC initialized. >> Thu May 12 05:36:24 2016 kern.notice kernel: [ 10.381556] IFX DEU MD5_HMAC >> initialized. >> Thu May 12 05:36:24 2016 kern.info kernel: [ 10.391907] nf_conntrack >> version 0.5.0 (1946 buckets, 7784 max) >> Thu May 12 05:36:24 2016 kern.info kernel: [ 10.418114] NET: Registered >> protocol family 24 >> Thu May 12 05:36:24 2016 kern.info kernel: [ 10.443723] xt_time: kernel >> timezone is -0000 >> Thu May 12 05:36:24 2016 kern.warn kernel: [ 10.539595] PCI: Enabling >> device 0000:01:00.0 (0140 -> 0142) >> Thu May 12 05:36:24 2016 kern.debug kernel: [ 10.550629] ath: EEPROM >> regdomain: 0x8114 >> Thu May 12 05:36:24 2016 kern.debug kernel: [ 10.550653] ath: EEPROM >> indicates we should expect a country code >> Thu May 12 05:36:24 2016 kern.debug kernel: [ 10.550667] ath: doing EEPROM >> country->regdmn map search >> Thu May 12 05:36:24 2016 kern.debug kernel: [ 10.550679] ath: country maps >> to regdmn code: 0x37 >> Thu May 12 05:36:24 2016 kern.debug kernel: [ 10.550692] ath: Country >> alpha2 being used: DE >> Thu May 12 05:36:24 2016 kern.debug kernel: [ 10.550704] ath: Regpair >> used: 0x37 >> Thu May 12 05:36:24 2016 kern.debug kernel: [ 10.564122] ieee80211 phy0: >> Selected rate control algorithm 'minstrel_ht' >> Thu May 12 05:36:24 2016 kern.info kernel: [ 10.567111] ieee80211 phy0: >> Atheros AR9287 Rev:2 mem=0xbc000000, irq=144 >> Thu May 12 05:36:25 2016 user.notice : 'radio0' is disabled >> Thu May 12 05:36:25 2016 user.notice : 'radio0' is disabled >> Thu May 12 05:36:26 2016 user.notice : firmware for annex a not found >> Thu May 12 05:36:28 2016 authpriv.info dropbear[840]: Not backgrounding >> Thu May 12 05:36:28 2016 user.notice : setting up led wifi >> Thu May 12 05:36:28 2016 user.notice : setting up led dsl >> Thu May 12 05:36:28 2016 user.notice : setting up led internet >> Thu May 12 05:36:29 2016 daemon.info procd: - init complete - >> Thu May 12 05:36:30 2016 kern.info kernel: [ 19.477228] device eth0.1 >> entered promiscuous mode >> Thu May 12 05:36:30 2016 kern.info kernel: [ 19.480651] device eth0 >> entered promiscuous mode >> Thu May 12 05:36:30 2016 kern.info kernel: [ 19.500394] br-lan: port >> 1(eth0.1) entered forwarding state >> Thu May 12 05:36:30 2016 kern.info kernel: [ 19.504638] br-lan: port >> 1(eth0.1) entered forwarding state >> Thu May 12 05:36:30 2016 daemon.notice netifd: Interface 'lan' is enabled >> Thu May 12 05:36:30 2016 daemon.notice netifd: Interface 'lan' is setting up >> now >> Thu May 12 05:36:30 2016 daemon.notice netifd: Interface 'lan' is now up >> Thu May 12 05:36:30 2016 daemon.notice netifd: Interface 'loopback' is >> enabled >> Thu May 12 05:36:30 2016 daemon.notice netifd: Interface 'loopback' is >> setting up now >> Thu May 12 05:36:30 2016 daemon.notice netifd: Interface 'loopback' is now >> up >> Thu May 12 05:36:30 2016 daemon.notice netifd: Bridge 'br-lan' link is up >> Thu May 12 05:36:30 2016 daemon.notice netifd: Interface 'lan' has link >> connectivity >> Thu May 12 05:36:30 2016 daemon.notice netifd: Network device 'eth0' link is >> up >> Thu May 12 05:36:30 2016 daemon.notice netifd: VLAN 'eth0.1' link is up >> Thu May 12 05:36:30 2016 daemon.notice netifd: Network device 'lo' link is >> up >> Thu May 12 05:36:30 2016 daemon.notice netifd: Interface 'loopback' has link >> connectivity >> Thu May 12 05:36:30 2016 user.notice firewall: Reloading firewall due to >> ifup of lan (br-lan) >> Thu May 12 05:36:32 2016 kern.info kernel: [ 21.506873] br-lan: port >> 1(eth0.1) entered forwarding state >> Thu May 12 05:36:35 2016 daemon.info dnsmasq[989]: started, version 2.75 >> cachesize 150 >> Thu May 12 05:36:35 2016 daemon.info dnsmasq[989]: compile time options: >> IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP >> no-conntrack no-ipset no-auth no-DNSSEC loop-detect inotify >> Thu May 12 05:36:35 2016 daemon.info dnsmasq[989]: DNS service limited to >> local subnets >> Thu May 12 05:36:35 2016 daemon.info dnsmasq-dhcp[989]: DHCP, IP range >> 192.168.2.100 -- 192.168.2.249, lease time 12h >> Thu May 12 05:36:35 2016 daemon.info dnsmasq[989]: using local addresses >> only for domain lan >> Thu May 12 05:36:35 2016 daemon.warn dnsmasq[989]: no servers found in >> /tmp/resolv.conf.auto, will retry >> Thu May 12 05:36:35 2016 daemon.info dnsmasq[989]: read /etc/hosts - 4 >> addresses >> Thu May 12 05:36:35 2016 daemon.info dnsmasq[989]: read /tmp/hosts/dhcp - 2 >> addresses >> Thu May 12 05:36:35 2016 daemon.info dnsmasq-dhcp[989]: read /etc/ethers - 0 >> addresses >> Thu May 12 05:36:42 2016 kern.notice kernel: [ 31.802908] random: >> nonblocking pool is initialized >> >> >> _______________________________________________ >> openwrt-devel mailing list >> openwrt-devel at lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >> -------------- next part -------------- A non-text attachment was scrubbed... Name: 7360.diff Type: text/x-patch Size: 6970 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From martin.blumenstingl at googlemail.com Sun May 15 16:13:15 2016 From: martin.blumenstingl at googlemail.com (Martin Blumenstingl) Date: Sun, 15 May 2016 22:13:15 +0200 Subject: [OpenWrt-Devel] Add support for AVM Fritzbox 7360 SL In-Reply-To: <9bb07f9a-d02f-2af7-d60d-a40075aa9871@animeland.de> References: <69086bb8-44aa-05e4-a550-ee1b13633b4a@animeland.de> <572E254E.4030409@gmail.com> <44031fa7-cb40-d37c-79bd-f338bfba8b68@animeland.de> <93a04c66-d6a4-1c5f-d16c-80db337b6d3c@animeland.de> <2d877322-9bf3-7144-3620-589f652f75ef@animeland.de> <9bb07f9a-d02f-2af7-d60d-a40075aa9871@animeland.de> Message-ID: On Sun, May 15, 2016 at 9:45 PM, Sebastian Ortwein wrote: > Am 15.05.2016 um 17:37 schrieb Martin Blumenstingl: > Okay thank you for support. Now all thinks works fine LAN, WIFI, Switch and > USB. > I attach my patch to add the support for OpenWRT. Great - congratulations :-) > Is there anything to do for including this patch in OpenWRT? actually you should split your patch into two: 1. adding support for 7360 SL 2. enabling CONFIG_AT803X_PHY saying that it's needed by 7360 SL Make sure that you commit the patches with "git commit -s" (to add "signed-off-by") and give them a nice description. Then send them to this mailing-list (preferrably with git send-email - see also: [0]). PS: maybe you could change the LED labels in your patch to have a "fritz7360sl" prefix, instead of "fritz7360" before sending the patch. Martin [0] https://wiki.openwrt.org/doc/patch/using.git _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From leroi.lists at gmail.com Sun May 15 18:34:36 2016 From: leroi.lists at gmail.com (Roman Yeryomin) Date: Mon, 16 May 2016 01:34:36 +0300 Subject: [OpenWrt-Devel] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood) In-Reply-To: References: <1462125592.5535.194.camel@edumazet-glaptop3.roam.corp.google.com> <865DA393-262D-40B6-A9D3-1B978CD5F6C6@gmail.com> <1462128385.5535.200.camel@edumazet-glaptop3.roam.corp.google.com> <1462136140.5535.219.camel@edumazet-glaptop3.roam.corp.google.com> <1462201620.5535.250.camel@edumazet-glaptop3.roam.corp.google.com> <1462205669.5535.254.camel@edumazet-glaptop3.roam.corp.google.com> <1462464776.13075.18.camel@edumazet-glaptop3.roam.corp.google.com> <1462476207.13075.20.camel@edumazet-glaptop3.roam.corp.google.com> <20160506114243.4eb4f95e@redhat.com> <20160506144740.210901f5@redhat.com> Message-ID: On 6 May 2016 at 22:43, Dave Taht wrote: > On Fri, May 6, 2016 at 11:56 AM, Roman Yeryomin wrote: >> On 6 May 2016 at 21:43, Roman Yeryomin wrote: >>> On 6 May 2016 at 15:47, Jesper Dangaard Brouer wrote: >>>> >>>> I've created a OpenWRT ticket[1] on this issue, as it seems that someone[2] >>>> closed Felix'es OpenWRT email account (bad choice! emails bouncing). >>>> Sounds like OpenWRT and the LEDE https://www.lede-project.org/ project >>>> is in some kind of conflict. >>>> >>>> OpenWRT ticket [1] https://dev.openwrt.org/ticket/22349 >>>> >>>> [2] http://thread.gmane.org/gmane.comp.embedded.openwrt.devel/40298/focus=40335 >>> >>> OK, so, after porting the patch to 4.1 openwrt kernel and playing a >>> bit with fq_codel limits I was able to get 420Mbps UDP like this: >>> tc qdisc replace dev wlan0 parent :1 fq_codel flows 16 limit 256 >> >> Forgot to mention, I've reduced drop_batch_size down to 32 > > 0) Not clear to me if that's the right line, there are 4 wifi queues, > and the third one > is the BE queue. That was an example, sorry, should have stated that. I've applied same settings to all 4 queues. > That is too low a limit, also, for normal use. And: > for the purpose of this particular UDP test, flows 16 is ok, but not > ideal. I played with different combinations, it doesn't make any (significant) difference: 20-30Mbps, not more. What numbers would you propose? > 1) What's the tcp number (with a simultaneous ping) with this latest patchset? > (I care about tcp performance a lot more than udp floods - surviving a > udp flood yes, performance, no) During the test (both TCP and UDP) it's roughly 5ms in average, not running tests ~2ms. Actually I'm now wondering if target is working at all, because I had same result with target 80ms.. So, yes, latency is good, but performance is poor. > before/after? > > tc -s qdisc show dev wlan0 during/after results? during the test: qdisc mq 0: root Sent 1600496000 bytes 1057194 pkt (dropped 1421568, overlimits 0 requeues 17) backlog 1545794b 1021p requeues 17 qdisc fq_codel 8001: parent :1 limit 1024p flows 16 quantum 1514 target 80.0ms ce_threshold 32us interval 100.0ms ecn Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 new_flows_len 0 old_flows_len 0 qdisc fq_codel 8002: parent :2 limit 1024p flows 16 quantum 1514 target 80.0ms ce_threshold 32us interval 100.0ms ecn Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 new_flows_len 0 old_flows_len 0 qdisc fq_codel 8003: parent :3 limit 1024p flows 16 quantum 1514 target 80.0ms ce_threshold 32us interval 100.0ms ecn Sent 1601271168 bytes 1057706 pkt (dropped 1422304, overlimits 0 requeues 17) backlog 1541252b 1018p requeues 17 maxpacket 1514 drop_overlimit 1422304 new_flow_count 35 ecn_mark 0 new_flows_len 0 old_flows_len 1 qdisc fq_codel 8004: parent :4 limit 1024p flows 16 quantum 1514 target 80.0ms ce_threshold 32us interval 100.0ms ecn Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 new_flows_len 0 old_flows_len 0 after the test (60sec): qdisc mq 0: root Sent 3084996052 bytes 2037744 pkt (dropped 2770176, overlimits 0 requeues 28) backlog 0b 0p requeues 28 qdisc fq_codel 8001: parent :1 limit 1024p flows 16 quantum 1514 target 80.0ms ce_threshold 32us interval 100.0ms ecn Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 new_flows_len 0 old_flows_len 0 qdisc fq_codel 8002: parent :2 limit 1024p flows 16 quantum 1514 target 80.0ms ce_threshold 32us interval 100.0ms ecn Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 new_flows_len 0 old_flows_len 0 qdisc fq_codel 8003: parent :3 limit 1024p flows 16 quantum 1514 target 80.0ms ce_threshold 32us interval 100.0ms ecn Sent 3084996052 bytes 2037744 pkt (dropped 2770176, overlimits 0 requeues 28) backlog 0b 0p requeues 28 maxpacket 1514 drop_overlimit 2770176 new_flow_count 64 ecn_mark 0 new_flows_len 0 old_flows_len 1 qdisc fq_codel 8004: parent :4 limit 1024p flows 16 quantum 1514 target 80.0ms ce_threshold 32us interval 100.0ms ecn Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 new_flows_len 0 old_flows_len 0 > IF you are doing builds for the archer c7v2, I can join in on this... (?) I'm not but I have c7 somewhere, so I can do a build for it and also test, so we are on the same page. > I did do a test of the ath10k "before", fq_codel *never engaged*, and > tcp induced latencies under load, e at 100mbit, cracked 600ms, while > staying flat (20ms) at 100mbit. (not the same patches you are testing) > on x86. I have got tcp 300Mbit out of an osx box, similar latency, > have yet to get anything more on anything I currently have > before/after patchsets. > > I'll go add flooding to the tests, I just finished a series comparing > two different speed stations and life was good on that. > > "before" - fq_codel never engages, we see seconds of latency under load. > > root at apu2:~# tc -s qdisc show dev wlp4s0 > qdisc mq 0: root > Sent 8570563893 bytes 6326983 pkt (dropped 0, overlimits 0 requeues 0) > backlog 0b 0p requeues 0 > qdisc fq_codel 0: parent :1 limit 10240p flows 1024 quantum 1514 > target 5.0ms interval 100.0ms ecn > Sent 2262 bytes 17 pkt (dropped 0, overlimits 0 requeues 0) > backlog 0b 0p requeues 0 > maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 > new_flows_len 0 old_flows_len 0 > qdisc fq_codel 0: parent :2 limit 10240p flows 1024 quantum 1514 > target 5.0ms interval 100.0ms ecn > Sent 220486569 bytes 152058 pkt (dropped 0, overlimits 0 requeues 0) > backlog 0b 0p requeues 0 > maxpacket 18168 drop_overlimit 0 new_flow_count 1 ecn_mark 0 > new_flows_len 0 old_flows_len 1 > qdisc fq_codel 0: parent :3 limit 10240p flows 1024 quantum 1514 > target 5.0ms interval 100.0ms ecn > Sent 8340546509 bytes 6163431 pkt (dropped 0, overlimits 0 requeues 0) > backlog 0b 0p requeues 0 > maxpacket 68130 drop_overlimit 0 new_flow_count 120050 ecn_mark 0 > new_flows_len 1 old_flows_len 3 > qdisc fq_codel 0: parent :4 limit 10240p flows 1024 quantum 1514 > target 5.0ms interval 100.0ms ecn > Sent 9528553 bytes 11477 pkt (dropped 0, overlimits 0 requeues 0) > backlog 0b 0p requeues 0 > maxpacket 66 drop_overlimit 0 new_flow_count 1 ecn_mark 0 > new_flows_len 1 old_flows_len 0 > ``` > > >>> This is certainly better than 30Mbps but still more than two times >>> less than before (900). > > The number that I still am not sure we got is that you were sending > 900mbit udp and recieving 900mbit on the prior tests? 900 was sending, AP POV (wifi client is downloading) >>> TCP also improved a little (550 to ~590). > > The limit is probably a bit low, also. You might want to try target > 20ms as well. I've tried limit up to 1024 and target up to 80ms >>> >>> Felix, others, do you want to see the ported patch, maybe I did something wrong? >>> Doesn't look like it will save ath10k from performance regression. > > what was tcp "before"? (I'm sorry, such a long thread) 750Mbps >>> >>>> >>>> On Fri, 6 May 2016 11:42:43 +0200 >>>> Jesper Dangaard Brouer wrote: >>>> >>>>> Hi Felix, >>>>> >>>>> This is an important fix for OpenWRT, please read! >>>>> >>>>> OpenWRT changed the default fq_codel sch->limit from 10240 to 1024, >>>>> without also adjusting q->flows_cnt. Eric explains below that you must >>>>> also adjust the buckets (q->flows_cnt) for this not to break. (Just >>>>> adjust it to 128) >>>>> >>>>> Problematic OpenWRT commit in question: >>>>> http://git.openwrt.org/?p=openwrt.git;a=patch;h=12cd6578084e >>>>> 12cd6578084e ("kernel: revert fq_codel quantum override to prevent it from causing too much cpu load with higher speed (#21326)") >>>>> >>>>> >>>>> I also highly recommend you cherry-pick this very recent commit: >>>>> net-next: 9d18562a2278 ("fq_codel: add batch ability to fq_codel_drop()") >>>>> https://git.kernel.org/davem/net-next/c/9d18562a227 >>>>> >>>>> This should fix very high CPU usage in-case fq_codel goes into drop mode. >>>>> The problem is that drop mode was considered rare, and implementation >>>>> wise it was chosen to be more expensive (to save cycles on normal mode). >>>>> Unfortunately is it easy to trigger with an UDP flood. Drop mode is >>>>> especially expensive for smaller devices, as it scans a 4K big array, >>>>> thus 64 cache misses for small devices! >>>>> >>>>> The fix is to allow drop-mode to bulk-drop more packets when entering >>>>> drop-mode (default 64 bulk drop). That way we don't suddenly >>>>> experience a significantly higher processing cost per packet, but >>>>> instead can amortize this. >>>>> >>>>> To Eric, should we recommend OpenWRT to adjust default (max) 64 bulk >>>>> drop, given we also recommend bucket size to be 128 ? (thus the amount >>>>> of memory to scan is less, but their CPU is also much smaller). >>>>> >>>>> --Jesper >>>>> >>>>> >>>>> On Thu, 05 May 2016 12:23:27 -0700 Eric Dumazet wrote: >>>>> >>>>> > On Thu, 2016-05-05 at 19:25 +0300, Roman Yeryomin wrote: >>>>> > > On 5 May 2016 at 19:12, Eric Dumazet wrote: >>>>> > > > On Thu, 2016-05-05 at 17:53 +0300, Roman Yeryomin wrote: >>>>> > > > >>>>> > > >> >>>>> > > >> qdisc fq_codel 0: dev eth0 root refcnt 2 limit 1024p flows 1024 >>>>> > > >> quantum 1514 target 5.0ms interval 100.0ms ecn >>>>> > > >> Sent 12306 bytes 128 pkt (dropped 0, overlimits 0 requeues 0) >>>>> > > >> backlog 0b 0p requeues 0 >>>>> > > >> maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 >>>>> > > >> new_flows_len 0 old_flows_len 0 >>>>> > > > >>>>> > > > >>>>> > > > Limit of 1024 packets and 1024 flows is not wise I think. >>>>> > > > >>>>> > > > (If all buckets are in use, each bucket has a virtual queue of 1 packet, >>>>> > > > which is almost the same than having no queue at all) >>>>> > > > >>>>> > > > I suggest to have at least 8 packets per bucket, to let Codel have a >>>>> > > > chance to trigger. >>>>> > > > >>>>> > > > So you could either reduce number of buckets to 128 (if memory is >>>>> > > > tight), or increase limit to 8192. >>>>> > > >>>>> > > Will try, but what I've posted is default, I didn't change/configure that. >>>>> > >>>>> > fq_codel has a default of 10240 packets and 1024 buckets. >>>>> > >>>>> > http://lxr.free-electrons.com/source/net/sched/sch_fq_codel.c#L413 >>>>> > >>>>> > If someone changed that in the linux variant you use, he probably should >>>>> > explain the rationale. >>>> >>>> -- >>>> Best regards, >>>> Jesper Dangaard Brouer >>>> MSc.CS, Principal Kernel Engineer at Red Hat >>>> Author of http://www.iptv-analyzer.org >>>> LinkedIn: http://www.linkedin.com/in/brouer > > > > -- > Dave T?ht > Let's go make home routers and wifi faster! With better software! > http://blog.cerowrt.org _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From leroi.lists at gmail.com Sun May 15 19:27:09 2016 From: leroi.lists at gmail.com (Roman Yeryomin) Date: Mon, 16 May 2016 02:27:09 +0300 Subject: [OpenWrt-Devel] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood) In-Reply-To: <1463353661.18194.50.camel@edumazet-glaptop3.roam.corp.google.com> References: <1462125592.5535.194.camel@edumazet-glaptop3.roam.corp.google.com> <865DA393-262D-40B6-A9D3-1B978CD5F6C6@gmail.com> <1462128385.5535.200.camel@edumazet-glaptop3.roam.corp.google.com> <1462136140.5535.219.camel@edumazet-glaptop3.roam.corp.google.com> <1462201620.5535.250.camel@edumazet-glaptop3.roam.corp.google.com> <1462205669.5535.254.camel@edumazet-glaptop3.roam.corp.google.com> <1462464776.13075.18.camel@edumazet-glaptop3.roam.corp.google.com> <1462476207.13075.20.camel@edumazet-glaptop3.roam.corp.google.com> <20160506114243.4eb4f95e@redhat.com> <20160506144740.210901f5@redhat.com> <1463353661.18194.50.camel@edumazet-glaptop3.roam.corp.google.com> Message-ID: On 16 May 2016 at 02:07, Eric Dumazet wrote: > On Mon, 2016-05-16 at 01:34 +0300, Roman Yeryomin wrote: > >> qdisc fq_codel 8003: parent :3 limit 1024p flows 16 quantum 1514 >> target 80.0ms ce_threshold 32us interval 100.0ms ecn >> Sent 1601271168 bytes 1057706 pkt (dropped 1422304, overlimits 0 requeues 17) >> backlog 1541252b 1018p requeues 17 >> maxpacket 1514 drop_overlimit 1422304 new_flow_count 35 ecn_mark 0 >> new_flows_len 0 old_flows_len 1 > > Why do you have ce_threshold set ? You really should not (even if it > does not matter for the kind of traffic you have at this moment) No idea, it was there always. How do I unset it? Setting it to 0 doesn't help. > If your expected link speed is around 1Gbps, or 80,000 packets per > second, then you have to understand that 1024 packets limit is about 12 > ms at most. > > Even if the queue is full, max sojourn time of a packet would be 12 ms. > > I really do not see how 'target 80 ms' could be hit. Well, as I said, I've tried different options. Neither target 20ms (as Dave proposed) not 12ms save the situation. > You basically have FQ, with no Codel effect, but with the associated > cost of Codel (having to take timestamps) > > > _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From david at lang.hm Mon May 16 04:12:59 2016 From: david at lang.hm (David Lang) Date: Mon, 16 May 2016 01:12:59 -0700 (PDT) Subject: [OpenWrt-Devel] [Make-wifi-fast] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood) In-Reply-To: References: <1462201620.5535.250.camel@edumazet-glaptop3.roam.corp.google.com> <1462205669.5535.254.camel@edumazet-glaptop3.roam.corp.google.com> <1462464776.13075.18.camel@edumazet-glaptop3.roam.corp.google.com> <1462476207.13075.20.camel@edumazet-glaptop3.roam.corp.google.com> <20160506114243.4eb4f95e@redhat.com> <20160506144740.210901f5@redhat.com> Message-ID: On Mon, 16 May 2016, Roman Yeryomin wrote: > On 6 May 2016 at 22:43, Dave Taht wrote: >> On Fri, May 6, 2016 at 11:56 AM, Roman Yeryomin wrote: >>> On 6 May 2016 at 21:43, Roman Yeryomin wrote: >>>> On 6 May 2016 at 15:47, Jesper Dangaard Brouer wrote: >>>>> > >> That is too low a limit, also, for normal use. And: >> for the purpose of this particular UDP test, flows 16 is ok, but not >> ideal. > > I played with different combinations, it doesn't make any > (significant) difference: 20-30Mbps, not more. > What numbers would you propose? How many different flows did you have going at once? I believe that the reason for higher numbers isn't for throughput, but to allow for more flows to be isolated from each other. If you have too few buckets, different flows will end up being combined into one bucket so that one will affect the other more. David Lang _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From leroi.lists at gmail.com Mon May 16 04:14:44 2016 From: leroi.lists at gmail.com (Roman Yeryomin) Date: Mon, 16 May 2016 11:14:44 +0300 Subject: [OpenWrt-Devel] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood) In-Reply-To: References: <1462125592.5535.194.camel@edumazet-glaptop3.roam.corp.google.com> <865DA393-262D-40B6-A9D3-1B978CD5F6C6@gmail.com> <1462128385.5535.200.camel@edumazet-glaptop3.roam.corp.google.com> <1462136140.5535.219.camel@edumazet-glaptop3.roam.corp.google.com> <1462201620.5535.250.camel@edumazet-glaptop3.roam.corp.google.com> <1462205669.5535.254.camel@edumazet-glaptop3.roam.corp.google.com> <1462464776.13075.18.camel@edumazet-glaptop3.roam.corp.google.com> <1462476207.13075.20.camel@edumazet-glaptop3.roam.corp.google.com> <20160506114243.4eb4f95e@redhat.com> <20160506144740.210901f5@redhat.com> Message-ID: On 16 May 2016 at 01:34, Roman Yeryomin wrote: > On 6 May 2016 at 22:43, Dave Taht wrote: >> On Fri, May 6, 2016 at 11:56 AM, Roman Yeryomin wrote: >>> On 6 May 2016 at 21:43, Roman Yeryomin wrote: >>>> On 6 May 2016 at 15:47, Jesper Dangaard Brouer wrote: >>>>> >>>>> I've created a OpenWRT ticket[1] on this issue, as it seems that someone[2] >>>>> closed Felix'es OpenWRT email account (bad choice! emails bouncing). >>>>> Sounds like OpenWRT and the LEDE https://www.lede-project.org/ project >>>>> is in some kind of conflict. >>>>> >>>>> OpenWRT ticket [1] https://dev.openwrt.org/ticket/22349 >>>>> >>>>> [2] http://thread.gmane.org/gmane.comp.embedded.openwrt.devel/40298/focus=40335 >>>> >>>> OK, so, after porting the patch to 4.1 openwrt kernel and playing a >>>> bit with fq_codel limits I was able to get 420Mbps UDP like this: >>>> tc qdisc replace dev wlan0 parent :1 fq_codel flows 16 limit 256 >>> >>> Forgot to mention, I've reduced drop_batch_size down to 32 >> >> 0) Not clear to me if that's the right line, there are 4 wifi queues, >> and the third one >> is the BE queue. > > That was an example, sorry, should have stated that. I've applied same > settings to all 4 queues. > >> That is too low a limit, also, for normal use. And: >> for the purpose of this particular UDP test, flows 16 is ok, but not >> ideal. > > I played with different combinations, it doesn't make any > (significant) difference: 20-30Mbps, not more. > What numbers would you propose? > >> 1) What's the tcp number (with a simultaneous ping) with this latest patchset? >> (I care about tcp performance a lot more than udp floods - surviving a >> udp flood yes, performance, no) > > During the test (both TCP and UDP) it's roughly 5ms in average, not > running tests ~2ms. Actually I'm now wondering if target is working at > all, because I had same result with target 80ms.. > So, yes, latency is good, but performance is poor. > >> before/after? >> >> tc -s qdisc show dev wlan0 during/after results? > > during the test: > > qdisc mq 0: root > Sent 1600496000 bytes 1057194 pkt (dropped 1421568, overlimits 0 requeues 17) > backlog 1545794b 1021p requeues 17 > qdisc fq_codel 8001: parent :1 limit 1024p flows 16 quantum 1514 > target 80.0ms ce_threshold 32us interval 100.0ms ecn > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > backlog 0b 0p requeues 0 > maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 > new_flows_len 0 old_flows_len 0 > qdisc fq_codel 8002: parent :2 limit 1024p flows 16 quantum 1514 > target 80.0ms ce_threshold 32us interval 100.0ms ecn > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > backlog 0b 0p requeues 0 > maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 > new_flows_len 0 old_flows_len 0 > qdisc fq_codel 8003: parent :3 limit 1024p flows 16 quantum 1514 > target 80.0ms ce_threshold 32us interval 100.0ms ecn > Sent 1601271168 bytes 1057706 pkt (dropped 1422304, overlimits 0 requeues 17) > backlog 1541252b 1018p requeues 17 > maxpacket 1514 drop_overlimit 1422304 new_flow_count 35 ecn_mark 0 > new_flows_len 0 old_flows_len 1 > qdisc fq_codel 8004: parent :4 limit 1024p flows 16 quantum 1514 > target 80.0ms ce_threshold 32us interval 100.0ms ecn > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > backlog 0b 0p requeues 0 > maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 > new_flows_len 0 old_flows_len 0 > > > after the test (60sec): > > qdisc mq 0: root > Sent 3084996052 bytes 2037744 pkt (dropped 2770176, overlimits 0 requeues 28) > backlog 0b 0p requeues 28 > qdisc fq_codel 8001: parent :1 limit 1024p flows 16 quantum 1514 > target 80.0ms ce_threshold 32us interval 100.0ms ecn > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > backlog 0b 0p requeues 0 > maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 > new_flows_len 0 old_flows_len 0 > qdisc fq_codel 8002: parent :2 limit 1024p flows 16 quantum 1514 > target 80.0ms ce_threshold 32us interval 100.0ms ecn > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > backlog 0b 0p requeues 0 > maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 > new_flows_len 0 old_flows_len 0 > qdisc fq_codel 8003: parent :3 limit 1024p flows 16 quantum 1514 > target 80.0ms ce_threshold 32us interval 100.0ms ecn > Sent 3084996052 bytes 2037744 pkt (dropped 2770176, overlimits 0 requeues 28) > backlog 0b 0p requeues 28 > maxpacket 1514 drop_overlimit 2770176 new_flow_count 64 ecn_mark 0 > new_flows_len 0 old_flows_len 1 > qdisc fq_codel 8004: parent :4 limit 1024p flows 16 quantum 1514 > target 80.0ms ce_threshold 32us interval 100.0ms ecn > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > backlog 0b 0p requeues 0 > maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 > new_flows_len 0 old_flows_len 0 > > >> IF you are doing builds for the archer c7v2, I can join in on this... (?) > > I'm not but I have c7 somewhere, so I can do a build for it and also > test, so we are on the same page. > >> I did do a test of the ath10k "before", fq_codel *never engaged*, and >> tcp induced latencies under load, e at 100mbit, cracked 600ms, while >> staying flat (20ms) at 100mbit. (not the same patches you are testing) >> on x86. I have got tcp 300Mbit out of an osx box, similar latency, >> have yet to get anything more on anything I currently have >> before/after patchsets. >> >> I'll go add flooding to the tests, I just finished a series comparing >> two different speed stations and life was good on that. >> >> "before" - fq_codel never engages, we see seconds of latency under load. >> >> root at apu2:~# tc -s qdisc show dev wlp4s0 >> qdisc mq 0: root >> Sent 8570563893 bytes 6326983 pkt (dropped 0, overlimits 0 requeues 0) >> backlog 0b 0p requeues 0 >> qdisc fq_codel 0: parent :1 limit 10240p flows 1024 quantum 1514 >> target 5.0ms interval 100.0ms ecn >> Sent 2262 bytes 17 pkt (dropped 0, overlimits 0 requeues 0) >> backlog 0b 0p requeues 0 >> maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 >> new_flows_len 0 old_flows_len 0 >> qdisc fq_codel 0: parent :2 limit 10240p flows 1024 quantum 1514 >> target 5.0ms interval 100.0ms ecn >> Sent 220486569 bytes 152058 pkt (dropped 0, overlimits 0 requeues 0) >> backlog 0b 0p requeues 0 >> maxpacket 18168 drop_overlimit 0 new_flow_count 1 ecn_mark 0 >> new_flows_len 0 old_flows_len 1 >> qdisc fq_codel 0: parent :3 limit 10240p flows 1024 quantum 1514 >> target 5.0ms interval 100.0ms ecn >> Sent 8340546509 bytes 6163431 pkt (dropped 0, overlimits 0 requeues 0) >> backlog 0b 0p requeues 0 >> maxpacket 68130 drop_overlimit 0 new_flow_count 120050 ecn_mark 0 >> new_flows_len 1 old_flows_len 3 >> qdisc fq_codel 0: parent :4 limit 10240p flows 1024 quantum 1514 >> target 5.0ms interval 100.0ms ecn >> Sent 9528553 bytes 11477 pkt (dropped 0, overlimits 0 requeues 0) >> backlog 0b 0p requeues 0 >> maxpacket 66 drop_overlimit 0 new_flow_count 1 ecn_mark 0 >> new_flows_len 1 old_flows_len 0 >> ``` >> >> >>>> This is certainly better than 30Mbps but still more than two times >>>> less than before (900). >> >> The number that I still am not sure we got is that you were sending >> 900mbit udp and recieving 900mbit on the prior tests? > > 900 was sending, AP POV (wifi client is downloading) > >>>> TCP also improved a little (550 to ~590). >> >> The limit is probably a bit low, also. You might want to try target >> 20ms as well. > > I've tried limit up to 1024 and target up to 80ms > >>>> >>>> Felix, others, do you want to see the ported patch, maybe I did something wrong? >>>> Doesn't look like it will save ath10k from performance regression. >> >> what was tcp "before"? (I'm sorry, such a long thread) > > 750Mbps Michal, after retesting with your patch (sorry, it was late yesterday, confused compat-wireless archives) I saw the difference. So the progress looks like this (all with fq_codel flows 16 limit 1024 target 20ms): no patches: 380Mbps UDP, 550 TCP Eric's (fq_codel drop) patch: 420Mbps UDP, 590 TCP (+40Mbps), latency 5-6ms during test Michal's (improve tx scheduling) patch: 580Mbps UDP, 660 TCP, latency up to 30-40ms during test after Rajkumar's proposal to "try without registering wake_tx_queue callback": 820Mbps UDP, 690 TCP. So, very close to "as before": 900Mbps UDP, 750 TCP. But still, I was expecting performance improvements from latest ath10k code, not regressions. I know that hw is capable of 800Mbps TCP, which I'm targeting. Regards, Roman p.s. sorry for confusion _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From leroi.lists at gmail.com Mon May 16 04:26:16 2016 From: leroi.lists at gmail.com (Roman Yeryomin) Date: Mon, 16 May 2016 11:26:16 +0300 Subject: [OpenWrt-Devel] [Make-wifi-fast] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood) In-Reply-To: References: <1462201620.5535.250.camel@edumazet-glaptop3.roam.corp.google.com> <1462205669.5535.254.camel@edumazet-glaptop3.roam.corp.google.com> <1462464776.13075.18.camel@edumazet-glaptop3.roam.corp.google.com> <1462476207.13075.20.camel@edumazet-glaptop3.roam.corp.google.com> <20160506114243.4eb4f95e@redhat.com> <20160506144740.210901f5@redhat.com> Message-ID: On 16 May 2016 at 11:12, David Lang wrote: > On Mon, 16 May 2016, Roman Yeryomin wrote: > >> On 6 May 2016 at 22:43, Dave Taht wrote: >>> >>> On Fri, May 6, 2016 at 11:56 AM, Roman Yeryomin >>> wrote: >>>> >>>> On 6 May 2016 at 21:43, Roman Yeryomin wrote: >>>>> >>>>> On 6 May 2016 at 15:47, Jesper Dangaard Brouer >>>>> wrote: >>>>>> >>>>>> >> >>> That is too low a limit, also, for normal use. And: >>> for the purpose of this particular UDP test, flows 16 is ok, but not >>> ideal. >> >> >> I played with different combinations, it doesn't make any >> (significant) difference: 20-30Mbps, not more. >> What numbers would you propose? > > > How many different flows did you have going at once? I believe that the > reason for higher numbers isn't for throughput, but to allow for more flows > to be isolated from each other. If you have too few buckets, different flows > will end up being combined into one bucket so that one will affect the other > more. I'm testing with one flow, I never saw bigger performance with more flows (e.g. -P8 to iperf3). Regards, Roman _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From david at lang.hm Mon May 16 04:46:25 2016 From: david at lang.hm (David Lang) Date: Mon, 16 May 2016 01:46:25 -0700 (PDT) Subject: [OpenWrt-Devel] [Make-wifi-fast] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood) In-Reply-To: References: <1462205669.5535.254.camel@edumazet-glaptop3.roam.corp.google.com> <1462464776.13075.18.camel@edumazet-glaptop3.roam.corp.google.com> <1462476207.13075.20.camel@edumazet-glaptop3.roam.corp.google.com> <20160506114243.4eb4f95e@redhat.com> <20160506144740.210901f5@redhat.com> Message-ID: On Mon, 16 May 2016, Roman Yeryomin wrote: > On 16 May 2016 at 11:12, David Lang wrote: >> On Mon, 16 May 2016, Roman Yeryomin wrote: >> >>> On 6 May 2016 at 22:43, Dave Taht wrote: >>>> >>>> On Fri, May 6, 2016 at 11:56 AM, Roman Yeryomin >>>> wrote: >>>>> >>>>> On 6 May 2016 at 21:43, Roman Yeryomin wrote: >>>>>> >>>>>> On 6 May 2016 at 15:47, Jesper Dangaard Brouer >>>>>> wrote: >>>>>>> >>>>>>> >>> >>>> That is too low a limit, also, for normal use. And: >>>> for the purpose of this particular UDP test, flows 16 is ok, but not >>>> ideal. >>> >>> >>> I played with different combinations, it doesn't make any >>> (significant) difference: 20-30Mbps, not more. >>> What numbers would you propose? >> >> >> How many different flows did you have going at once? I believe that the >> reason for higher numbers isn't for throughput, but to allow for more flows >> to be isolated from each other. If you have too few buckets, different flows >> will end up being combined into one bucket so that one will affect the other >> more. > > I'm testing with one flow, I never saw bigger performance with more > flows (e.g. -P8 to iperf3). The issue isn't performance, it's isolating a DNS request from a VoIP flow from a streaming video flow from a DVD image download. The question is how many buckets do you need to have to isolate these in practice? it depends how many flows you have. The default was 1024 buckets, but got changed to 128 for low memory devices, and that lower value got made into the default, even for devices with lots of memory. I'm wondering if instead of trying to size this based on device memory, can it be resizable on the fly and grow if too many flows/collisions are detected? David Lang _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From christian at m3hlis.de Mon May 16 05:27:53 2016 From: christian at m3hlis.de (Christian Mehlis) Date: Mon, 16 May 2016 11:27:53 +0200 Subject: [OpenWrt-Devel] Add support for AVM Fritzbox 7360 SL In-Reply-To: References: <69086bb8-44aa-05e4-a550-ee1b13633b4a@animeland.de> <572E254E.4030409@gmail.com> <44031fa7-cb40-d37c-79bd-f338bfba8b68@animeland.de> <93a04c66-d6a4-1c5f-d16c-80db337b6d3c@animeland.de> <2d877322-9bf3-7144-3620-589f652f75ef@animeland.de> <9bb07f9a-d02f-2af7-d60d-a40075aa9871@animeland.de> Message-ID: <6abe7bf0-9039-588e-c77e-23cce8870825@m3hlis.de> Am 15.05.2016 um 22:13 schrieb Martin Blumenstingl: > On Sun, May 15, 2016 at 9:45 PM, Sebastian Ortwein wrote: >> Am 15.05.2016 um 17:37 schrieb Martin Blumenstingl: >> Okay thank you for support. Now all thinks works fine LAN, WIFI, Switch and >> USB. >> I attach my patch to add the support for OpenWRT. > Great - congratulations :-) Hi Sebastian, I'm interested in some details about the flashing procedure. Did you replace the original avm bootloader with uboot? a) YEA: How to replace it, with which uboot version, where to find the code? b) NO: How to flash openwrt with avm bootloader? Can I flash without any extra hardware? Only with serial and the right commands? Please name them. Thanks, Christian _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From moeller0 at gmx.de Mon May 16 06:34:24 2016 From: moeller0 at gmx.de (Sebastian Moeller) Date: Mon, 16 May 2016 12:34:24 +0200 Subject: [OpenWrt-Devel] [Make-wifi-fast] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood) In-Reply-To: References: <1462205669.5535.254.camel@edumazet-glaptop3.roam.corp.google.com> <1462464776.13075.18.camel@edumazet-glaptop3.roam.corp.google.com> <1462476207.13075.20.camel@edumazet-glaptop3.roam.corp.google.com> <20160506114243.4eb4f95e@redhat.com> <20160506144740.210901f5@redhat.com> Message-ID: <1E11CBFE-1471-4ECC-8D34-9172B61D3F59@gmx.de> Hi David, On May 16, 2016 10:46:25 AM GMT+02:00, David Lang wrote: >On Mon, 16 May 2016, Roman Yeryomin wrote: > >> On 16 May 2016 at 11:12, David Lang wrote: >>> On Mon, 16 May 2016, Roman Yeryomin wrote: >>> >>>> On 6 May 2016 at 22:43, Dave Taht wrote: >>>>> >>>>> On Fri, May 6, 2016 at 11:56 AM, Roman Yeryomin > >>>>> wrote: >>>>>> >>>>>> On 6 May 2016 at 21:43, Roman Yeryomin >wrote: >>>>>>> >>>>>>> On 6 May 2016 at 15:47, Jesper Dangaard Brouer > >>>>>>> wrote: >>>>>>>> >>>>>>>> >>>> >>>>> That is too low a limit, also, for normal use. And: >>>>> for the purpose of this particular UDP test, flows 16 is ok, but >not >>>>> ideal. >>>> >>>> >>>> I played with different combinations, it doesn't make any >>>> (significant) difference: 20-30Mbps, not more. >>>> What numbers would you propose? >>> >>> >>> How many different flows did you have going at once? I believe that >the >>> reason for higher numbers isn't for throughput, but to allow for >more flows >>> to be isolated from each other. If you have too few buckets, >different flows >>> will end up being combined into one bucket so that one will affect >the other >>> more. >> >> I'm testing with one flow, I never saw bigger performance with more >> flows (e.g. -P8 to iperf3). > >The issue isn't performance, it's isolating a DNS request from a VoIP >flow >from a streaming video flow from a DVD image download. > >The question is how many buckets do you need to have to isolate these >in >practice? it depends how many flows you have. The default was 1024 >buckets, but >got changed to 128 for low memory devices, and that lower value got >made into >the default, even for devices with lots of memory. And I believe that the reduction was suboptimal, we need the Hash buckets to spread the glows around to avoid shared fate due to shared buckets... So the 1024 glows make a lot of sense even if the number of real concurrent flows is lower think birthday paradoxon. The change came because at full saturation our reduced packet limit only allowed one packet per bucket which is too low for decent performance... also less hash buckets make searching faster. Since we now can specify a memory limit in addition to the packet limit, we should set the packet limit back to its default of 10240 and instead set the memory limit to something same for each platform. This will effectively have the same consequences as setting a packet limit, except it becomes clearer why performance degrades and I at least take a performance hit gladly over a forced oom reboot.... > >I'm wondering if instead of trying to size this based on device memory, >can it >be resizable on the fly and grow if too many flows/collisions are >detected? > >David Lang >_______________________________________________ >openwrt-devel mailing list >openwrt-devel at lists.openwrt.org >https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -- Sent from my Android device with K-9 Mail. Please excuse my brevity. _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From luka at openwrt.org Mon May 16 07:47:33 2016 From: luka at openwrt.org (Luka Perkov) Date: Mon, 16 May 2016 13:47:33 +0200 Subject: [OpenWrt-Devel] [Summit-committee] OpenWrt summit by prpl In-Reply-To: <57350762.9050801@hauke-m.de> References: <57350762.9050801@hauke-m.de> Message-ID: <20160516114732.GB3156@localhost.localdomain> Hi Hauke, On Fri, May 13, 2016 at 12:44:50AM +0200, Hauke Mehrtens wrote: > When I use OpenWrt in this mail, I mean OpenWrt and LEDE, I hope we come > to a solution in the next days on this. It is strange to see you defining OpenWrt and LEDE as a same project - especially due to the fact that LEDE is a fork (if you don't believe me take a look at LEDE commit logs). To make things worse we've witnessed that LEDE team members have been closing tickets or putting them in "wontfix" state on official OpenWrt bugtracker - the fixes or improvements did not land in OpenWrt while at the same time implementing those changes in LEDE. While I don't mind in LEDE taking it's own direction I do not approve this kind of behavior. Do you mind explaining what does LEDE or its developers want to gain from such actions? Furthermore, I also find it extremely unprofessional to see you make claims such as this one, c/p from Kathy's meeting summary: "Hauke mentioned that some core developers don't like prpl." Who are these "core" developers who make such claims? Are they even involved anymore with OpenWrt? > prpl wants to organize an OpenWrt summit again. Their goal is to bring > the community, industry and developers together. Currently this is in > planing and I want to know what should happen so that more developers > and more members of the community would come to such an event. I personally support prpl in this efforts due to the fact that last summit was great and they did a good job with the conference and organization. > There are different ideas on how to organize such an event: > 1. prpl organizes an event co located with the Embedded Linux conference > this October in Berlin. > 2. prpl organizes an event co located with Battlemesh next year in May. > 3. Some people from OpenWrt organize an event in Prague at CZ.NIC. > CZ.NIC would provide a location and local logistics, prpl could help > with finance. I am okay with all options but due to the efforts shown by CZ.NIC I'm most likely going to give my vote to Prague. > It is also possible to do more than one solution or combine them. > > Are there some people interested in organizing this by themselves with > the help of CZ.NIC, then we could go with this solution? > If nobody is interested in organizing this I would like to see it co > located with the ELCE and the Battlemesh next year. > > No final name for this event was chosen. The current suggestion is > "OpenWrt summit by prpl" or something similar. If prpl organizes the event and/or gives funding for it they should be credited for doing it. Regards, Luka _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From hauke at hauke-m.de Mon May 16 09:07:57 2016 From: hauke at hauke-m.de (Hauke Mehrtens) Date: Mon, 16 May 2016 15:07:57 +0200 Subject: [OpenWrt-Devel] [Summit-committee] OpenWrt summit by prpl In-Reply-To: <20160516114732.GB3156@localhost.localdomain> References: <57350762.9050801@hauke-m.de> <20160516114732.GB3156@localhost.localdomain> Message-ID: <5739C62D.4010006@hauke-m.de> Hi Luka, On 05/16/2016 01:47 PM, Luka Perkov wrote: > Hi Hauke, > > On Fri, May 13, 2016 at 12:44:50AM +0200, Hauke Mehrtens wrote: >> When I use OpenWrt in this mail, I mean OpenWrt and LEDE, I hope we come >> to a solution in the next days on this. > > It is strange to see you defining OpenWrt and LEDE as a same project - > especially due to the fact that LEDE is a fork (if you don't believe me > take a look at LEDE commit logs). My assumption and hope is that we will come to a conclusion on the OpenWrt LEDE split in the next weeks. > To make things worse we've witnessed > that LEDE team members have been closing tickets or putting them in > "wontfix" state on official OpenWrt bugtracker - the fixes or > improvements did not land in OpenWrt while at the same time implementing > those changes in LEDE. I have closed some tickets with wount fix, when I think that the probability that someone will fix this problem because this ticket is open is under 5%. OpenWrt already has too many open tickets and I think it is better for a reporter when someone tells him that nobody will look into his problems then letting him wait for years without any response. I do not know if you are referring to the tickets I closed or to others. > While I don't mind in LEDE taking it's own > direction I do not approve this kind of behavior. Do you mind > explaining what does LEDE or its developers want to gain from such > actions? Can you please give me an example, I haven't looked through the issue tracker. > Furthermore, I also find it extremely unprofessional to see you make > claims such as this one, c/p from Kathy's meeting summary: "Hauke > mentioned that some core developers don't like prpl." Who are these > "core" developers who make such claims? Are they even involved anymore > with OpenWrt? When we talked internally on the openwrt-hackers mailing list about the prpl funding, I got the impression that there are some problems between some active OpenWrt developers and prpl. For me it looks like there is a lot of stuff going on in private and I only get half of the picture. I personally think we should take the support form prpl and just take care that OpenWrt and/or LEDE don't get controlled by prpl, but I do not think they ant and are about to control OpenWrt and/or LEDE. I still see me as an OpenWrt core developer and from want I heard form many of the LEDE committers they too. >> prpl wants to organize an OpenWrt summit again. Their goal is to bring >> the community, industry and developers together. Currently this is in >> planing and I want to know what should happen so that more developers >> and more members of the community would come to such an event. > > I personally support prpl in this efforts due to the fact that last > summit was great and they did a good job with the conference and > organization. I also liked it and I also want to support prpl with the next one. The purpose of this mail was to get more people from the community to the summit. Last time most of the people at the OpenWrt summit were send by their companies and I missed the Freifunk people and so on. >> There are different ideas on how to organize such an event: >> 1. prpl organizes an event co located with the Embedded Linux conference >> this October in Berlin. >> 2. prpl organizes an event co located with Battlemesh next year in May. >> 3. Some people from OpenWrt organize an event in Prague at CZ.NIC. >> CZ.NIC would provide a location and local logistics, prpl could help >> with finance. > > I am okay with all options but due to the efforts shown by CZ.NIC I'm > most likely going to give my vote to Prague. Thanks for your opinion. That was the purpose of this mail to inform many people and to get more opinions so that nobody feels excluded and we get a better summit. I think prpl improved there and tries to be more open. >> It is also possible to do more than one solution or combine them. >> >> Are there some people interested in organizing this by themselves with >> the help of CZ.NIC, then we could go with this solution? >> If nobody is interested in organizing this I would like to see it co >> located with the ELCE and the Battlemesh next year. >> >> No final name for this event was chosen. The current suggestion is >> "OpenWrt summit by prpl" or something similar. > > If prpl organizes the event and/or gives funding for it they should be > credited for doing it. I have no problem with the name. I know that some people could have some problems with that so I want to have it addressed early. Hauke _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From luka at openwrt.org Mon May 16 09:32:29 2016 From: luka at openwrt.org (Luka Perkov) Date: Mon, 16 May 2016 15:32:29 +0200 Subject: [OpenWrt-Devel] [PATCH] [package] linux: Add new Marvell cryptoengine In-Reply-To: <20160513093010.GA8419@workbook.ipv6.hrusecky.net> References: <20160513093010.GA8419@workbook.ipv6.hrusecky.net> Message-ID: <20160516133229.GA4800@localhost.localdomain> Hi Michal, On Fri, May 13, 2016 at 11:30:10AM +0200, Michal Hrusecky wrote: > Adding new Marvell cryptoengine as some device might use the new one and not > the old one. I'm assuming that the "New Marvell crypto engine" is taken from mainline kernel. Since the "Old Marvell crypto engine" is not in mainline I'd rather that somewhere along the line it gets replaced entirely by the mainline one. That said, can you send v2 where you remove the "New" from the Title and make it depend on a newer mainline kernels which have support for this crypto engine. Thanks, Luka > Signed-off-by: Michal Hrusecky > --- > package/kernel/linux/modules/crypto.mk | 20 +++++++++++++++++--- > 1 file changed, 17 insertions(+), 3 deletions(-) > > diff --git a/package/kernel/linux/modules/crypto.mk b/package/kernel/linux/modules/crypto.mk > index 0acc730..0f37a55 100644 > --- a/package/kernel/linux/modules/crypto.mk > +++ b/package/kernel/linux/modules/crypto.mk > @@ -711,14 +711,28 @@ endef > > $(eval $(call KernelPackage,crypto-xts)) > > - > define KernelPackage/crypto-mv-cesa > - TITLE:=Marvell crypto engine > + TITLE:=Old Marvell crypto engine > DEPENDS:=+kmod-crypto-manager @TARGET_kirkwood||TARGET_orion||TARGET_mvebu > - KCONFIG:=CONFIG_CRYPTO_DEV_MV_CESA > + KCONFIG:= \ > + CONFIG_CRYPTO_DEV_MV_CESA \ > + CONFIG_CRYPTO_HW=y > FILES:=$(LINUX_DIR)/drivers/crypto/mv_cesa.ko > AUTOLOAD:=$(call AutoLoad,09,mv_cesa) > $(call AddDepends/crypto) > endef > > $(eval $(call KernelPackage,crypto-mv-cesa)) > + > +define KernelPackage/crypto-marvell-cesa > + TITLE:=New Marvell crypto engine > + DEPENDS:=+kmod-crypto-manager @TARGET_kirkwood||TARGET_orion||TARGET_mvebu > + KCONFIG:= \ > + CONFIG_CRYPTO_DEV_MARVELL_CESA \ > + CONFIG_CRYPTO_HW=y > + FILES:=$(LINUX_DIR)/drivers/crypto/marvell/marvell-cesa.ko > + AUTOLOAD:=$(call AutoLoad,09,marvell-cesa) > + $(call AddDepends/crypto) > +endef > + > +$(eval $(call KernelPackage,crypto-marvell-cesa)) > -- > 2.8.2 > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From Alexey.Brodkin at synopsys.com Mon May 16 10:42:43 2016 From: Alexey.Brodkin at synopsys.com (Alexey Brodkin) Date: Mon, 16 May 2016 17:42:43 +0300 Subject: [OpenWrt-Devel] [PATCH] include/kernel: Do not strip kernel's Elf Message-ID: <1463409763-11832-1-git-send-email-abrodkin@synopsys.com> If an image gets built as an Elf there's a chance it will be used by developers for debugging purposes. In that case it's very helpful to keep debugging info in that image. I would think that most OWRT-powered devices in production will use some form of binary image for booting so Elf flavours could be left a bit bulkier with more debug info inside. Signed-off-by: Alexey Brodkin --- include/kernel-defaults.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/kernel-defaults.mk b/include/kernel-defaults.mk index 406fd46..0166dc5 100644 --- a/include/kernel-defaults.mk +++ b/include/kernel-defaults.mk @@ -142,7 +142,7 @@ endif define Kernel/CopyImage cmp -s $(LINUX_DIR)/vmlinux $(KERNEL_BUILD_DIR)/vmlinux$(1).debug || { \ $(KERNEL_CROSS)objcopy -O binary $(OBJCOPY_STRIP) -S $(LINUX_DIR)/vmlinux $(LINUX_KERNEL)$(1); \ - $(KERNEL_CROSS)objcopy $(OBJCOPY_STRIP) -S $(LINUX_DIR)/vmlinux $(KERNEL_BUILD_DIR)/vmlinux$(1).elf; \ + $(KERNEL_CROSS)objcopy $(OBJCOPY_STRIP) $(LINUX_DIR)/vmlinux $(KERNEL_BUILD_DIR)/vmlinux$(1).elf; \ $(CP) $(LINUX_DIR)/vmlinux $(KERNEL_BUILD_DIR)/vmlinux$(1).debug; \ $(foreach k, \ $(if $(KERNEL_IMAGES),$(KERNEL_IMAGES),$(filter-out dtbs,$(KERNELNAME))), \ -- 2.5.5 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From daniel at makrotopia.org Mon May 16 11:20:45 2016 From: daniel at makrotopia.org (Daniel Golle) Date: Mon, 16 May 2016 17:20:45 +0200 Subject: [OpenWrt-Devel] [LEDE-DEV] [PATCH] include/kernel: Do not strip kernel's Elf In-Reply-To: <1463409763-11832-1-git-send-email-abrodkin@synopsys.com> References: <1463409763-11832-1-git-send-email-abrodkin@synopsys.com> Message-ID: <20160516152044.GC1092@makrotopia.org> On Mon, May 16, 2016 at 05:42:43PM +0300, Alexey Brodkin wrote: > If an image gets built as an Elf there's a chance > it will be used by developers for debugging purposes. > In that case it's very helpful to keep debugging info > in that image. > > I would think that most OWRT-powered devices in production > will use some form of binary image for booting so Elf > flavours could be left a bit bulkier with more debug info > inside. Well, some of the tiniest AR7 boxes out there come with a bootloader expecting ELF binaries... I didn't have a close look, just assuming that they might be affected. May Florian knows more...? Cheers Daniel > > Signed-off-by: Alexey Brodkin > --- > include/kernel-defaults.mk | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/kernel-defaults.mk b/include/kernel-defaults.mk > index 406fd46..0166dc5 100644 > --- a/include/kernel-defaults.mk > +++ b/include/kernel-defaults.mk > @@ -142,7 +142,7 @@ endif > define Kernel/CopyImage > cmp -s $(LINUX_DIR)/vmlinux $(KERNEL_BUILD_DIR)/vmlinux$(1).debug || { \ > $(KERNEL_CROSS)objcopy -O binary $(OBJCOPY_STRIP) -S $(LINUX_DIR)/vmlinux $(LINUX_KERNEL)$(1); \ > - $(KERNEL_CROSS)objcopy $(OBJCOPY_STRIP) -S $(LINUX_DIR)/vmlinux $(KERNEL_BUILD_DIR)/vmlinux$(1).elf; \ > + $(KERNEL_CROSS)objcopy $(OBJCOPY_STRIP) $(LINUX_DIR)/vmlinux $(KERNEL_BUILD_DIR)/vmlinux$(1).elf; \ > $(CP) $(LINUX_DIR)/vmlinux $(KERNEL_BUILD_DIR)/vmlinux$(1).debug; \ > $(foreach k, \ > $(if $(KERNEL_IMAGES),$(KERNEL_IMAGES),$(filter-out dtbs,$(KERNELNAME))), \ > -- > 2.5.5 > > > _______________________________________________ > Lede-dev mailing list > Lede-dev at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From eschultz at prplfoundation.org Mon May 16 12:40:51 2016 From: eschultz at prplfoundation.org (Eric Schultz) Date: Mon, 16 May 2016 11:40:51 -0500 Subject: [OpenWrt-Devel] OpenWrt summit by prpl In-Reply-To: <57358D21.40801@ninux.org> References: <57350762.9050801@hauke-m.de> <57358D21.40801@ninux.org> Message-ID: Federico, I don't want to speak for Hauke but I think he meant that that we have an event at ELCE this year and then plan on another at Battlemesh next year I personally think that's the best idea all around. I know prpl members have expressed lots of positive feedback on the idea of ELCE to Art and he's gotten very solid feedback from industry because it's so convenient for them. Planning on Battlemesh as well (with Battlemesh's approval of course) then brings some of the interested industry members into contact with a more community focused event. Hopefully that will build some new bridges and relationships. I think the combination is a win-win. Eric On Fri, May 13, 2016 at 3:15 AM, Nemesis wrote: > Hi everyone, > > I have been at the event in Dublin last year with a colleague. > The event was really interesting from a technical point of view and we > really missed such an event focused on OpenWRT and the various > applications & services one can build with it. > > It would be good to have more communities to participate in such an > event, and it would be awesome if the most active developers would have > a leading role in organizing it. > > Hauke, one note regarding co-location, you wrote: "I would like to see > it co located with the ELCE and the Battlemesh next year." > > But I believe the Battlemesh next year won't be co located with ELCE, > did you mean the Battlemesh or ELCE? > > Federico > > > > > On 05/13/2016 12:44 AM, Hauke Mehrtens wrote: > > Hi, > > > > When I use OpenWrt in this mail, I mean OpenWrt and LEDE, I hope we come > > to a solution in the next days on this. > > > > prpl wants to organize an OpenWrt summit again. Their goal is to bring > > the community, industry and developers together. Currently this is in > > planing and I want to know what should happen so that more developers > > and more members of the community would come to such an event. > > > > There are different ideas on how to organize such an event: > > 1. prpl organizes an event co located with the Embedded Linux conference > > this October in Berlin. > > 2. prpl organizes an event co located with Battlemesh next year in May. > > 3. Some people from OpenWrt organize an event in Prague at CZ.NIC. > > CZ.NIC would provide a location and local logistics, prpl could help > > with finance. > > > > It is also possible to do more than one solution or combine them. > > > > Are there some people interested in organizing this by themselfs with > > the help of CZ.NIC, then we could go with this solution? > > If nobody is interested in organizing this I would like to see it co > > located with the ELCE and the Battlemesh next year. > > > > No final name for this event was chosen. The current suggestion is > > "OpenWrt summit by prpl" or something similar. > > > > Are there any comments on this? > > > > Hauke > > _______________________________________________ > > openwrt-devel mailing list > > openwrt-devel at lists.openwrt.org > > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > -- Eric Schultz, Community Manager, prpl Foundation http://www.prplfoundation.org eschultz at prplfoundation.org cell: 920-539-0404 skype: ericschultzwi @EricPrpl -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From leroi.lists at gmail.com Mon May 16 15:46:59 2016 From: leroi.lists at gmail.com (Roman Yeryomin) Date: Mon, 16 May 2016 22:46:59 +0300 Subject: [OpenWrt-Devel] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood) In-Reply-To: References: <1462125592.5535.194.camel@edumazet-glaptop3.roam.corp.google.com> <865DA393-262D-40B6-A9D3-1B978CD5F6C6@gmail.com> <1462128385.5535.200.camel@edumazet-glaptop3.roam.corp.google.com> <1462136140.5535.219.camel@edumazet-glaptop3.roam.corp.google.com> <1462201620.5535.250.camel@edumazet-glaptop3.roam.corp.google.com> <1462205669.5535.254.camel@edumazet-glaptop3.roam.corp.google.com> <1462464776.13075.18.camel@edumazet-glaptop3.roam.corp.google.com> <1462476207.13075.20.camel@edumazet-glaptop3.roam.corp.google.com> <20160506114243.4eb4f95e@redhat.com> <20160506144740.210901f5@redhat.com> Message-ID: On 16 May 2016 at 19:04, Dave Taht wrote: > On Mon, May 16, 2016 at 1:14 AM, Roman Yeryomin wrote: >> On 16 May 2016 at 01:34, Roman Yeryomin wrote: >>> On 6 May 2016 at 22:43, Dave Taht wrote: >>>> On Fri, May 6, 2016 at 11:56 AM, Roman Yeryomin wrote: >>>>> On 6 May 2016 at 21:43, Roman Yeryomin wrote: >>>>>> On 6 May 2016 at 15:47, Jesper Dangaard Brouer wrote: >>>>>>> >>>>>>> I've created a OpenWRT ticket[1] on this issue, as it seems that someone[2] >>>>>>> closed Felix'es OpenWRT email account (bad choice! emails bouncing). >>>>>>> Sounds like OpenWRT and the LEDE https://www.lede-project.org/ project >>>>>>> is in some kind of conflict. >>>>>>> >>>>>>> OpenWRT ticket [1] https://dev.openwrt.org/ticket/22349 >>>>>>> >>>>>>> [2] http://thread.gmane.org/gmane.comp.embedded.openwrt.devel/40298/focus=40335 >>>>>> >>>>>> OK, so, after porting the patch to 4.1 openwrt kernel and playing a >>>>>> bit with fq_codel limits I was able to get 420Mbps UDP like this: >>>>>> tc qdisc replace dev wlan0 parent :1 fq_codel flows 16 limit 256 >>>>> >>>>> Forgot to mention, I've reduced drop_batch_size down to 32 >>>> >>>> 0) Not clear to me if that's the right line, there are 4 wifi queues, >>>> and the third one >>>> is the BE queue. >>> >>> That was an example, sorry, should have stated that. I've applied same >>> settings to all 4 queues. >>> >>>> That is too low a limit, also, for normal use. And: >>>> for the purpose of this particular UDP test, flows 16 is ok, but not >>>> ideal. >>> >>> I played with different combinations, it doesn't make any >>> (significant) difference: 20-30Mbps, not more. >>> What numbers would you propose? >>> >>>> 1) What's the tcp number (with a simultaneous ping) with this latest patchset? >>>> (I care about tcp performance a lot more than udp floods - surviving a >>>> udp flood yes, performance, no) >>> >>> During the test (both TCP and UDP) it's roughly 5ms in average, not >>> running tests ~2ms. Actually I'm now wondering if target is working at >>> all, because I had same result with target 80ms.. >>> So, yes, latency is good, but performance is poor. >>> >>>> before/after? >>>> >>>> tc -s qdisc show dev wlan0 during/after results? >>> >>> during the test: >>> >>> qdisc mq 0: root >>> Sent 1600496000 bytes 1057194 pkt (dropped 1421568, overlimits 0 requeues 17) >>> backlog 1545794b 1021p requeues 17 >>> qdisc fq_codel 8001: parent :1 limit 1024p flows 16 quantum 1514 >>> target 80.0ms ce_threshold 32us interval 100.0ms ecn >>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) >>> backlog 0b 0p requeues 0 >>> maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 >>> new_flows_len 0 old_flows_len 0 >>> qdisc fq_codel 8002: parent :2 limit 1024p flows 16 quantum 1514 >>> target 80.0ms ce_threshold 32us interval 100.0ms ecn >>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) >>> backlog 0b 0p requeues 0 >>> maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 >>> new_flows_len 0 old_flows_len 0 >>> qdisc fq_codel 8003: parent :3 limit 1024p flows 16 quantum 1514 >>> target 80.0ms ce_threshold 32us interval 100.0ms ecn >>> Sent 1601271168 bytes 1057706 pkt (dropped 1422304, overlimits 0 requeues 17) >>> backlog 1541252b 1018p requeues 17 >>> maxpacket 1514 drop_overlimit 1422304 new_flow_count 35 ecn_mark 0 >>> new_flows_len 0 old_flows_len 1 >>> qdisc fq_codel 8004: parent :4 limit 1024p flows 16 quantum 1514 >>> target 80.0ms ce_threshold 32us interval 100.0ms ecn >>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) >>> backlog 0b 0p requeues 0 >>> maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 >>> new_flows_len 0 old_flows_len 0 >>> >>> >>> after the test (60sec): >>> >>> qdisc mq 0: root >>> Sent 3084996052 bytes 2037744 pkt (dropped 2770176, overlimits 0 requeues 28) >>> backlog 0b 0p requeues 28 >>> qdisc fq_codel 8001: parent :1 limit 1024p flows 16 quantum 1514 >>> target 80.0ms ce_threshold 32us interval 100.0ms ecn >>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) >>> backlog 0b 0p requeues 0 >>> maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 >>> new_flows_len 0 old_flows_len 0 >>> qdisc fq_codel 8002: parent :2 limit 1024p flows 16 quantum 1514 >>> target 80.0ms ce_threshold 32us interval 100.0ms ecn >>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) >>> backlog 0b 0p requeues 0 >>> maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 >>> new_flows_len 0 old_flows_len 0 >>> qdisc fq_codel 8003: parent :3 limit 1024p flows 16 quantum 1514 >>> target 80.0ms ce_threshold 32us interval 100.0ms ecn >>> Sent 3084996052 bytes 2037744 pkt (dropped 2770176, overlimits 0 requeues 28) >>> backlog 0b 0p requeues 28 >>> maxpacket 1514 drop_overlimit 2770176 new_flow_count 64 ecn_mark 0 >>> new_flows_len 0 old_flows_len 1 >>> qdisc fq_codel 8004: parent :4 limit 1024p flows 16 quantum 1514 >>> target 80.0ms ce_threshold 32us interval 100.0ms ecn >>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) >>> backlog 0b 0p requeues 0 >>> maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 >>> new_flows_len 0 old_flows_len 0 >>> >>> >>>> IF you are doing builds for the archer c7v2, I can join in on this... (?) >>> >>> I'm not but I have c7 somewhere, so I can do a build for it and also >>> test, so we are on the same page. >>> >>>> I did do a test of the ath10k "before", fq_codel *never engaged*, and >>>> tcp induced latencies under load, e at 100mbit, cracked 600ms, while >>>> staying flat (20ms) at 100mbit. (not the same patches you are testing) >>>> on x86. I have got tcp 300Mbit out of an osx box, similar latency, >>>> have yet to get anything more on anything I currently have >>>> before/after patchsets. >>>> >>>> I'll go add flooding to the tests, I just finished a series comparing >>>> two different speed stations and life was good on that. >>>> >>>> "before" - fq_codel never engages, we see seconds of latency under load. >>>> >>>> root at apu2:~# tc -s qdisc show dev wlp4s0 >>>> qdisc mq 0: root >>>> Sent 8570563893 bytes 6326983 pkt (dropped 0, overlimits 0 requeues 0) >>>> backlog 0b 0p requeues 0 >>>> qdisc fq_codel 0: parent :1 limit 10240p flows 1024 quantum 1514 >>>> target 5.0ms interval 100.0ms ecn >>>> Sent 2262 bytes 17 pkt (dropped 0, overlimits 0 requeues 0) >>>> backlog 0b 0p requeues 0 >>>> maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 >>>> new_flows_len 0 old_flows_len 0 >>>> qdisc fq_codel 0: parent :2 limit 10240p flows 1024 quantum 1514 >>>> target 5.0ms interval 100.0ms ecn >>>> Sent 220486569 bytes 152058 pkt (dropped 0, overlimits 0 requeues 0) >>>> backlog 0b 0p requeues 0 >>>> maxpacket 18168 drop_overlimit 0 new_flow_count 1 ecn_mark 0 >>>> new_flows_len 0 old_flows_len 1 >>>> qdisc fq_codel 0: parent :3 limit 10240p flows 1024 quantum 1514 >>>> target 5.0ms interval 100.0ms ecn >>>> Sent 8340546509 bytes 6163431 pkt (dropped 0, overlimits 0 requeues 0) >>>> backlog 0b 0p requeues 0 >>>> maxpacket 68130 drop_overlimit 0 new_flow_count 120050 ecn_mark 0 >>>> new_flows_len 1 old_flows_len 3 >>>> qdisc fq_codel 0: parent :4 limit 10240p flows 1024 quantum 1514 >>>> target 5.0ms interval 100.0ms ecn >>>> Sent 9528553 bytes 11477 pkt (dropped 0, overlimits 0 requeues 0) >>>> backlog 0b 0p requeues 0 >>>> maxpacket 66 drop_overlimit 0 new_flow_count 1 ecn_mark 0 >>>> new_flows_len 1 old_flows_len 0 >>>> ``` >>>> >>>> >>>>>> This is certainly better than 30Mbps but still more than two times >>>>>> less than before (900). >>>> >>>> The number that I still am not sure we got is that you were sending >>>> 900mbit udp and recieving 900mbit on the prior tests? >>> >>> 900 was sending, AP POV (wifi client is downloading) >>> >>>>>> TCP also improved a little (550 to ~590). >>>> >>>> The limit is probably a bit low, also. You might want to try target >>>> 20ms as well. >>> >>> I've tried limit up to 1024 and target up to 80ms >>> >>>>>> >>>>>> Felix, others, do you want to see the ported patch, maybe I did something wrong? >>>>>> Doesn't look like it will save ath10k from performance regression. >>>> >>>> what was tcp "before"? (I'm sorry, such a long thread) >>> >>> 750Mbps >> >> Michal, after retesting with your patch (sorry, it was late yesterday, >> confused compat-wireless archives) I saw the difference. >> So the progress looks like this (all with fq_codel flows 16 limit 1024 >> target 20ms): >> no patches: 380Mbps UDP, 550 TCP >> Eric's (fq_codel drop) patch: 420Mbps UDP, 590 TCP (+40Mbps), latency >> 5-6ms during test >> Michal's (improve tx scheduling) patch: 580Mbps UDP, 660 TCP, latency >> up to 30-40ms during test >> after Rajkumar's proposal to "try without registering wake_tx_queue >> callback": 820Mbps UDP, 690 TCP. > > And the simultaneous ping on the last test was? same as previous: 30-40ms Regards, Roman _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From bapclenet at gmail.com Tue May 17 02:57:58 2016 From: bapclenet at gmail.com (Baptiste Clenet) Date: Tue, 17 May 2016 08:57:58 +0200 Subject: [OpenWrt-Devel] mt76 wifi module on mt7688 board, no interface In-Reply-To: References: <570FB001.8030507@phrozen.org> <1461265121.8314.4.camel@noblepepper.com> Message-ID: John, have you got time to look at it? Cheers, Le 9 mai 2016 18:58, "John Crispin" a ?crit : > Hi Baptiste, > > on my list for this week > > John > > On 09/05/2016 18:56, Baptiste Clenet wrote: > > Lazar, > > Have you managed to make mt76 work on mt7688? > > > > Thanks > > > > 2016-05-03 1:52 GMT+02:00 Lazar Demin : > >> Marc, > >> Can you expand on what you did to get the AP to work? I'm completely > >> stumped... > >> > >> Any luck on the STA? > >> > >> > >> Thanks > >> > >> On Thu, Apr 21, 2016 at 3:00 PM, Marc Nicholas wrote: > >>> > >>> Is the firmware getting loaded (/lib/firmware/mt7628_e2.bin)? It looks > >>> like the fix in 48958 for this is in github.com/openwrt-mirror/ but > not > >>> in github.com/openwrt/. > >>> > >>> Yes, the firmware is getting loaded based on the boot logs. > >>> > >>> I?ve gotten a bit further and have AP mode running. But can?t for the > life > >>> of me get STA to work?.can?t even scan for APs. :-/ > >>> > >>> Thanks! > >>> > >>> -m > >>> > >>> -- > >>> > >>> _______________________________________________ > >>> openwrt-devel mailing list > >>> openwrt-devel at lists.openwrt.org > >>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > >>> > >> > >> > >> _______________________________________________ > >> openwrt-devel mailing list > >> openwrt-devel at lists.openwrt.org > >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > >> > > > > > > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From xotic750 at gmail.com Tue May 17 06:59:20 2016 From: xotic750 at gmail.com (Xotic750) Date: Tue, 17 May 2016 12:59:20 +0200 Subject: [OpenWrt-Devel] [PATCHv2] Initial commit for the NetGear EVG2000. Message-ID: <1463482760-10583-1-git-send-email-xotic750@gmail.com> From: Graham Fairweather This patch adds support for the Netgear EVG2000 VoIP Gateway to the bcm63xx targets. Ran 'make target/linux/refresh V=s' after update to kernel 4.4.10 from 4.4.8 where the initial patch was added. This device was not sold to the general public, but rather is/was provided by telcos to customers in Sweden, Australia, Singapore and other parts of asia. System-On-Chip: Broadcom BCM6369 (2 * BMIPS4350 v3.1 / 400 MHz) Flash size: 16 MiB RAM size: 64 MiB Wireless: BCM4322 802.11b/g/n (onboard) Ethernet: Broadcom BCM53115 USB: 2 x USB 2.0 Known issues: - Unable to detect 53115 switch. This appear to be a problem with probing for the PHY using MDIO and results in error 5. Doesn't seem to be a problem with the configuration, and could use someone with experience to have a look at it. - Uses the b43 driver as using the OpenWRT/LEDE broadcom-wl driver fails to load the firmware for the 4322, so 802.11n is not supported. The factory build uses a newer broadcom-wl driver. - No support for the 2 VoIP ports (not attempted) More info on the device and the research can be found at: https://wiki.openwrt.org/toh/netgear/evg2000 https://wikidevi.com/wiki/Netgear_EVG2000 https://github.com/Xotic750/mirror-lede/tree/evg2000 https://forum.openwrt.org/viewtopic.php?id=63950 Signed-off-by: Graham Fairweather --- .../linux/brcm63xx/base-files/etc/board.d/01_leds | 7 ++ .../brcm63xx/base-files/etc/board.d/02_network | 1 + target/linux/brcm63xx/base-files/lib/brcm63xx.sh | 3 + target/linux/brcm63xx/dts/evg2000.dts | 103 +++++++++++++++++++++ target/linux/brcm63xx/image/Makefile | 2 + .../brcm63xx/patches-4.1/805-board_EVG2000.patch | 62 +++++++++++++ .../brcm63xx/patches-4.4/805-board_EVG2000.patch | 62 +++++++++++++ target/linux/brcm63xx/profiles/netgear.mk | 11 +++ 8 files changed, 251 insertions(+) create mode 100644 target/linux/brcm63xx/dts/evg2000.dts create mode 100644 target/linux/brcm63xx/patches-4.1/805-board_EVG2000.patch create mode 100644 target/linux/brcm63xx/patches-4.4/805-board_EVG2000.patch diff --git a/target/linux/brcm63xx/base-files/etc/board.d/01_leds b/target/linux/brcm63xx/base-files/etc/board.d/01_leds index 8339254..4163214 100755 --- a/target/linux/brcm63xx/base-files/etc/board.d/01_leds +++ b/target/linux/brcm63xx/base-files/etc/board.d/01_leds @@ -24,6 +24,13 @@ dgnd3700v1_dgnd3800b) ucidef_set_led_usbdev "usb1" "USB1" "DGND3700v1_3800B:green:usb-back" "1-1" ucidef_set_led_usbdev "usb2" "USB2" "DGND3700v1_3800B:green:usb-front" "1-2" ;; +evg2000) + ucidef_set_led_netdev "lan" "LAN" "EVG2000:green:lan" "eth0" + ucidef_set_led_netdev "wan" "WAN" "EVG2000:green:wan" "eth1" + ucidef_set_led_netdev "wlan0" "WIFI" "EVG2000:green:wireless" "wlan0" + ucidef_set_led_usbdev "usb1" "USB1" "EVG2000:green:voip1" "1-1" + ucidef_set_led_usbdev "usb2" "USB2" "EVG2000:green:voip2" "1-2" + ;; fast2704n) ucidef_set_led_netdev "wan" "WAN" "F at ST2704N:green:inet" "eth0.2" ;; diff --git a/target/linux/brcm63xx/base-files/etc/board.d/02_network b/target/linux/brcm63xx/base-files/etc/board.d/02_network index f96da08..83367c1 100755 --- a/target/linux/brcm63xx/base-files/etc/board.d/02_network +++ b/target/linux/brcm63xx/base-files/etc/board.d/02_network @@ -11,6 +11,7 @@ board_config_update case "$(brcm63xx_board_name)" in cvg834g |\ +evg2000 |\ rta770bw |\ rta770w |\ spw303v |\ diff --git a/target/linux/brcm63xx/base-files/lib/brcm63xx.sh b/target/linux/brcm63xx/base-files/lib/brcm63xx.sh index a2d6519..9cc0b2b 100755 --- a/target/linux/brcm63xx/base-files/lib/brcm63xx.sh +++ b/target/linux/brcm63xx/base-files/lib/brcm63xx.sh @@ -183,6 +183,9 @@ brcm63xx_dt_detect() { "Netgear DGND3700v1/DGND3800B") board_name="dgnd3700v1_dgnd3800b" ;; + "Netgear EVG2000") + board_name="evg2000" + ;; "NuCom R5010UN v2") board_name="r5010un_v2" ;; diff --git a/target/linux/brcm63xx/dts/evg2000.dts b/target/linux/brcm63xx/dts/evg2000.dts new file mode 100644 index 0000000..04f7b84 --- /dev/null +++ b/target/linux/brcm63xx/dts/evg2000.dts @@ -0,0 +1,103 @@ +/dts-v1/; + +#include "bcm6368.dtsi" + +#include + +/ { + model = "Netgear EVG2000"; + compatible = "netgear,evg2000", "brcm,bcm6368"; + + gpio-keys-polled { + compatible = "gpio-keys-polled"; + #address-cells = <1>; + #size-cells = <0>; + poll-interval = <20>; + debounce-interval = <60>; + + reset { + label = "reset"; + gpios = <&gpio0 25 1>; + linux,code = ; + }; + wps { + label = "wps"; + gpios = <&gpio0 26 1>; + linux,code = ; + }; + }; + + gpio-leds { + compatible = "gpio-leds"; + + voip1_green { + label = "EVG2000:green:voip1"; + gpios = <&gpio0 14 1>; + }; + voip2_green { + label = "EVG2000:green:voip2"; + gpios = <&gpio0 2 1>; + }; + inet_red { + label = "EVG2000:red:inet"; + gpios = <&gpio0 4 1>; + }; + inet_green { + label = "EVG2000:green:inet"; + gpios = <&gpio0 5 1>; + }; + usb_green { + label = "EVG2000:green:usb"; + gpios = <&gpio0 15 1>; + }; + power_green { + label = "EVG2000:green:power"; + gpios = <&gpio0 22 1>; + default-state = "on"; + }; + power_red { + label = "EVG2000:red:power"; + gpios = <&gpio0 23 1>; + }; + lan_green { + label = "EVG2000:green:lan"; + gpios = <&gpio0 24 1>; + }; + wireless_green { + label = "EVG2000:green:wireless"; + gpios = <&gpio0 26 1>; + }; + wan_green { + label = "EVG2000:green:wan"; + gpios = <&gpio0 27 1>; + }; + }; +}; + +&pflash { + status = "ok"; + + linux,part-probe = "bcm63xxpart"; + + cfe at 0 { + label = "CFE"; + reg = <0x00000000 0x00020000>; + read-only; + }; + + linux at 20000 { + label = "linux"; + reg = <0x00020000 0x00f40000>; + }; + + board_data at f60000 { + label = "board_data"; + reg = <0x00f60000 0x00080000>; + read-only; + }; + + nvram at fe0000 { + label = "nvram"; + reg = <0x00fe0000 0x00020000>; + }; +}; diff --git a/target/linux/brcm63xx/image/Makefile b/target/linux/brcm63xx/image/Makefile index e00b6fb..f1fb86b 100644 --- a/target/linux/brcm63xx/image/Makefile +++ b/target/linux/brcm63xx/image/Makefile @@ -593,6 +593,8 @@ $(eval $(call bcm63xxCfeRamdisk,DG834GV4,DG834GTv4,dg834g_v4,96348W3,6348)) $(eval $(call bcm63xxCfeNetgear,DGND3700v1_3800B,DGND3700v1,dgnd3700v1,96368MVWG,6368,--image-offset 0x20000 --block-size 0x20000,U12L144T01_NETGEAR_NEWLED,1)) # Netgear DGND3800B $(eval $(call bcm63xxCfeNetgear,DGND3700v1_3800B,DGND3800B,dgnd3700v1,96368MVWG,6368,--image-offset 0x20000 --block-size 0x20000,U12L144T11_NETGEAR_NEWLED,1)) +# Netgear EVG2000 +$(eval $(call bcm63xxCfeNetgear,EVG2000,EVG2000,evg2000,96369PVG,6369,--image-offset 0x20000 --block-size 0x20000,U12H154T90_NETGEAR,1)) # NuCom R5010UNv2 $(eval $(call bcm63xxCfe,R5010UNV2,R5010UNv2,r5010unv2,96328ang,6328,--pad 8)) # Pirelli Alice Gate VoIP 2 Plus Wi-Fi AGPF-S0 diff --git a/target/linux/brcm63xx/patches-4.1/805-board_EVG2000.patch b/target/linux/brcm63xx/patches-4.1/805-board_EVG2000.patch new file mode 100644 index 0000000..9339085 --- /dev/null +++ b/target/linux/brcm63xx/patches-4.1/805-board_EVG2000.patch @@ -0,0 +1,62 @@ +--- a/arch/mips/bcm63xx/boards/board_bcm963xx.c ++++ b/arch/mips/bcm63xx/boards/board_bcm963xx.c +@@ -2010,6 +2010,43 @@ static struct board_info __initdata boar + .num_spis = ARRAY_SIZE(DGND3700v1_3800B_spi_devices), + }; + ++static struct sprom_fixup __initdata EVG2000_fixups[] = { ++ { .offset = 219, .value = 0xec08 }, ++}; ++ ++static struct board_info __initdata board_EVG2000 = { ++ .name = "96369PVG", ++ .expected_cpu_id = 0x6368, ++ ++ .has_uart0 = 1, ++ .has_pci = 1, ++ .has_ohci0 = 1, ++ .has_ehci0 = 1, ++ .num_usbh_ports = 2, ++ ++ .has_enetsw = 1, ++ .enetsw = { ++ .used_ports = { ++ [5] = { ++ .used = 1, ++ .phy_id = 0xff, ++ .bypass_link = 1, ++ .force_speed = 1000, ++ .force_duplex_full = 1, ++ .name = "RGMII", ++ }, ++ }, ++ }, ++ .use_fallback_sprom = 1, ++ .fallback_sprom = { ++ .type = SPROM_BCM4322, ++ .pci_bus = 0, ++ .pci_dev = 1, ++ .board_fixups = EVG2000_fixups, ++ .num_board_fixups = ARRAY_SIZE(EVG2000_fixups), ++ }, ++}; ++ + static struct board_info __initdata board_HG655b = { + .name = "HW65x", + .expected_cpu_id = 0x6368, +@@ -2610,6 +2647,7 @@ static const struct board_info __initcon + &board_96368mvwg, + &board_96368mvngr, + &board_DGND3700v1_3800B, ++ &board_EVG2000, + &board_HG622, + &board_HG655b, + &board_P870HW51A_V2, +@@ -2722,6 +2760,7 @@ static struct of_device_id const bcm963x + { .compatible = "huawei,hg622", .data = &board_HG622, }, + { .compatible = "huawei,hg655b", .data = &board_HG655b, }, + { .compatible = "netgear,dgnd3700v1", .data = &board_DGND3700v1_3800B, }, ++ { .compatible = "netgear,evg2000", .data = &board_EVG2000, }, + { .compatible = "zyxel,p870hw-51a-v2", .data = &board_P870HW51A_V2, }, + #endif + #ifdef CONFIG_BCM63XX_CPU_63268 diff --git a/target/linux/brcm63xx/patches-4.4/805-board_EVG2000.patch b/target/linux/brcm63xx/patches-4.4/805-board_EVG2000.patch new file mode 100644 index 0000000..2f7e8be --- /dev/null +++ b/target/linux/brcm63xx/patches-4.4/805-board_EVG2000.patch @@ -0,0 +1,62 @@ +--- a/arch/mips/bcm63xx/boards/board_bcm963xx.c ++++ b/arch/mips/bcm63xx/boards/board_bcm963xx.c +@@ -2011,6 +2011,43 @@ static struct board_info __initdata boar + .num_spis = ARRAY_SIZE(DGND3700v1_3800B_spi_devices), + }; + ++static struct sprom_fixup __initdata EVG2000_fixups[] = { ++ { .offset = 219, .value = 0xec08 }, ++}; ++ ++static struct board_info __initdata board_EVG2000 = { ++ .name = "96369PVG", ++ .expected_cpu_id = 0x6368, ++ ++ .has_uart0 = 1, ++ .has_pci = 1, ++ .has_ohci0 = 1, ++ .has_ehci0 = 1, ++ .num_usbh_ports = 2, ++ ++ .has_enetsw = 1, ++ .enetsw = { ++ .used_ports = { ++ [5] = { ++ .used = 1, ++ .phy_id = 0xff, ++ .bypass_link = 1, ++ .force_speed = 1000, ++ .force_duplex_full = 1, ++ .name = "RGMII", ++ }, ++ }, ++ }, ++ .use_fallback_sprom = 1, ++ .fallback_sprom = { ++ .type = SPROM_BCM4322, ++ .pci_bus = 0, ++ .pci_dev = 1, ++ .board_fixups = EVG2000_fixups, ++ .num_board_fixups = ARRAY_SIZE(EVG2000_fixups), ++ }, ++}; ++ + static struct board_info __initdata board_HG655b = { + .name = "HW65x", + .expected_cpu_id = 0x6368, +@@ -2611,6 +2648,7 @@ static const struct board_info __initcon + &board_96368mvwg, + &board_96368mvngr, + &board_DGND3700v1_3800B, ++ &board_EVG2000, + &board_HG622, + &board_HG655b, + &board_P870HW51A_V2, +@@ -2722,6 +2761,7 @@ static struct of_device_id const bcm963x + { .compatible = "huawei,hg622", .data = &board_HG622, }, + { .compatible = "huawei,hg655b", .data = &board_HG655b, }, + { .compatible = "netgear,dgnd3700v1", .data = &board_DGND3700v1_3800B, }, ++ { .compatible = "netgear,evg2000", .data = &board_EVG2000, }, + { .compatible = "zyxel,p870hw-51a-v2", .data = &board_P870HW51A_V2, }, + #endif + #ifdef CONFIG_BCM63XX_CPU_63268 diff --git a/target/linux/brcm63xx/profiles/netgear.mk b/target/linux/brcm63xx/profiles/netgear.mk index bc345bb..5164d0c 100644 --- a/target/linux/brcm63xx/profiles/netgear.mk +++ b/target/linux/brcm63xx/profiles/netgear.mk @@ -36,8 +36,19 @@ define Profile/DGND3700v1_3800B NAME:=Netgear DGND3700 v1 / DGND3800B PACKAGES:=kmod-b43 wpad-mini \ kmod-usb2 kmod-usb-ohci kmod-ledtrig-usbdev + endef define Profile/DGND3700v1_3800B/Description Package set optimized for DGND3700 v1 / DGND3800B. endef $(eval $(call Profile,DGND3700v1_3800B)) + +define Profile/EVG2000 + NAME:=Netgear EVG2000 + PACKAGES:=kmod-b43 wpad-mini \ + kmod-usb2 kmod-usb-ohci kmod-ledtrig-usbdev +endef +define Profile/EVG2000/Description + Package set optimized for EVG2000. +endef +$(eval $(call Profile,EVG2000)) -- 2.5.5 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From xotic750 at gmail.com Tue May 17 07:02:15 2016 From: xotic750 at gmail.com (Xotic750) Date: Tue, 17 May 2016 13:02:15 +0200 Subject: [OpenWrt-Devel] [PATCHv3] Fix the CPU ID logged when detecting bcm63xx variants. Message-ID: <1463482935-10702-1-git-send-email-xotic750@gmail.com> From: Graham Fairweather This patch fixes the logged detected CPU ID when an equivalent is used, like in the case where we have a bcm6369 and configuration for a bcm6368 is used. So, it will display 'Detected Broadcom 0x6369 CPU revision b2' instead of 'Detected Broadcom 0x6368 CPU revision b2'. More info can be found at: https://forum.openwrt.org/viewtopic.php?id=64621 https://github.com/Xotic750/openwrt/tree/fix_logged_cpu_id_bcm63xx Signed-off-by: Graham Fairweather --- .../330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch | 9 +++++++++ .../330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch | 9 +++++++++ 2 files changed, 18 insertions(+) diff --git a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch index 661abf6..23491aa 100644 --- a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch +++ b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch @@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu variant helper bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT; switch (bcm63xx_cpu_id) { +@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void) + bcm63xx_memory_size = detect_memory_size(); + + printk(KERN_INFO "Detected Broadcom 0x%04x CPU revision %02x\n", +- bcm63xx_cpu_id, bcm63xx_cpu_rev); ++ bcm63xx_cpu_variant, bcm63xx_cpu_rev); + printk(KERN_INFO "CPU frequency is %u MHz\n", + bcm63xx_cpu_freq / 1000000); + printk(KERN_INFO "%uMB of RAM installed\n", --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h @@ -19,6 +19,7 @@ diff --git a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch index 661abf6..330a9e6 100644 --- a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch +++ b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch @@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu variant helper bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT; switch (bcm63xx_cpu_id) { +@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void) + bcm63xx_memory_size = detect_memory_size(); + + pr_info("Detected Broadcom 0x%04x CPU revision %02x\n", +- bcm63xx_cpu_id, bcm63xx_cpu_rev); ++ bcm63xx_cpu_variant, bcm63xx_cpu_rev); + pr_info("CPU frequency is %u MHz\n", + bcm63xx_cpu_freq / 1000000); + pr_info("%uMB of RAM installed\n", --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h @@ -19,6 +19,7 @@ -- 2.5.5 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From xotic750 at gmail.com Tue May 17 07:04:19 2016 From: xotic750 at gmail.com (Xotic750) Date: Tue, 17 May 2016 13:04:19 +0200 Subject: [OpenWrt-Devel] [PATCHv2] Bump kernel 4.1 to 4.1.24 Message-ID: <1463483059-10834-1-git-send-email-xotic750@gmail.com> From: Graham Fairweather Increment PATCH number, added MD5 sum for release. Patches were refreshed. *https://www.kernel.org/ * Signed-off-by: Graham Fairweather --- include/kernel-version.mk | 4 ++-- .../001-4.2-MIPS-Add-support-for-vmlinux.bin-appended-dtb.patch | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/include/kernel-version.mk b/include/kernel-version.mk index 97ff9a3..49d9a2e 100644 --- a/include/kernel-version.mk +++ b/include/kernel-version.mk @@ -3,11 +3,11 @@ LINUX_RELEASE?=1 LINUX_VERSION-3.18 = .29 -LINUX_VERSION-4.1 = .23 +LINUX_VERSION-4.1 = .24 LINUX_VERSION-4.4 = .7 LINUX_KERNEL_MD5SUM-3.18.29 = b25737a0bc98e80d12200de93f239c28 -LINUX_KERNEL_MD5SUM-4.1.23 = 5cb969fa874e110118722398b7c72c5d +LINUX_KERNEL_MD5SUM-4.1.24 = 3eaf96af2d4c63b8a391da5161a44f08 LINUX_KERNEL_MD5SUM-4.4.7 = 4345597c9a10bd73c28b6ae3a854d8d7 ifdef KERNEL_PATCHVER diff --git a/target/linux/brcm63xx/patches-4.1/001-4.2-MIPS-Add-support-for-vmlinux.bin-appended-dtb.patch b/target/linux/brcm63xx/patches-4.1/001-4.2-MIPS-Add-support-for-vmlinux.bin-appended-dtb.patch index fa7732b..cd05780 100644 --- a/target/linux/brcm63xx/patches-4.1/001-4.2-MIPS-Add-support-for-vmlinux.bin-appended-dtb.patch +++ b/target/linux/brcm63xx/patches-4.1/001-4.2-MIPS-Add-support-for-vmlinux.bin-appended-dtb.patch @@ -33,7 +33,7 @@ Signed-off-by: Ralf Baechle --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig -@@ -2703,6 +2703,33 @@ config BOOT_RAW +@@ -2704,6 +2704,33 @@ config BOOT_RAW -- 2.5.5 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From xotic750 at gmail.com Tue May 17 07:05:29 2016 From: xotic750 at gmail.com (Xotic750) Date: Tue, 17 May 2016 13:05:29 +0200 Subject: [OpenWrt-Devel] [PATCHv2] Bump kernel 4.4 to 4.4.10 Message-ID: <1463483129-10953-1-git-send-email-xotic750@gmail.com> From: Graham Fairweather Increment PATCH number, added MD5 sum for release. Patches were refreshed. *https://www.kernel.org/ * Signed-off-by: Graham Fairweather --- include/kernel-version.mk | 4 ++-- target/linux/brcm63xx/Makefile | 2 +- ...-m25p80-use-parsers-if-provided-in-flash-.patch | 2 +- ...CES-m25p80-add-support-for-limiting-reads.patch | 4 ++-- .../414-MTD-m25p80-allow-passing-pp_data.patch | 2 +- ...-m25p80-add-support-for-mmap-read-request.patch | 2 +- ...-add-spi_flash_read-callback-for-MMIO-bas.patch | 12 +++++----- .../207-mips-vdso-dbg-rebuild-after-genvdso.patch | 14 +++++------- .../patches-4.4/630-packet_socket_type.patch | 10 ++++----- .../patches-4.4/642-bridge_port_isolate.patch | 4 ++-- .../645-bridge_multicast_to_unicast.patch | 4 ++-- .../generic/patches-4.4/655-increase_skb_pad.patch | 2 +- .../656-skb_reduce_truesize-helper.patch | 2 +- .../666-Add-support-for-MAP-E-FMRs-mesh-mode.patch | 26 +++++++++++----------- .../generic/patches-4.4/721-phy_packets.patch | 8 +++---- .../patches-4.4/903-debloat_direct_io.patch | 4 ++-- 16 files changed, 50 insertions(+), 52 deletions(-) diff --git a/include/kernel-version.mk b/include/kernel-version.mk index 97ff9a3..c9fb0e1 100644 --- a/include/kernel-version.mk +++ b/include/kernel-version.mk @@ -4,11 +4,11 @@ LINUX_RELEASE?=1 LINUX_VERSION-3.18 = .29 LINUX_VERSION-4.1 = .23 -LINUX_VERSION-4.4 = .7 +LINUX_VERSION-4.4 = .10 LINUX_KERNEL_MD5SUM-3.18.29 = b25737a0bc98e80d12200de93f239c28 LINUX_KERNEL_MD5SUM-4.1.23 = 5cb969fa874e110118722398b7c72c5d -LINUX_KERNEL_MD5SUM-4.4.7 = 4345597c9a10bd73c28b6ae3a854d8d7 +LINUX_KERNEL_MD5SUM-4.4.10 = f7033cbe05e1359a347815ca52d051ed ifdef KERNEL_PATCHVER LINUX_VERSION:=$(KERNEL_PATCHVER)$(strip $(LINUX_VERSION-$(KERNEL_PATCHVER))) diff --git a/target/linux/brcm63xx/Makefile b/target/linux/brcm63xx/Makefile index f96897c..cf7f1c3 100644 --- a/target/linux/brcm63xx/Makefile +++ b/target/linux/brcm63xx/Makefile @@ -11,7 +11,7 @@ BOARD:=brcm63xx BOARDNAME:=Broadcom BCM63xx SUBTARGETS:=generic smp FEATURES:=squashfs usb atm pci pcmcia usbgadget -KERNEL_PATCHVER:=4.1 +KERNEL_PATCHVER:=4.4 MAINTAINER:=Jonas Gorski include $(INCLUDE_DIR)/target.mk diff --git a/target/linux/brcm63xx/patches-4.4/202-MTD-DEVICES-m25p80-use-parsers-if-provided-in-flash-.patch b/target/linux/brcm63xx/patches-4.4/202-MTD-DEVICES-m25p80-use-parsers-if-provided-in-flash-.patch index be62e67..4793836 100644 --- a/target/linux/brcm63xx/patches-4.4/202-MTD-DEVICES-m25p80-use-parsers-if-provided-in-flash-.patch +++ b/target/linux/brcm63xx/patches-4.4/202-MTD-DEVICES-m25p80-use-parsers-if-provided-in-flash-.patch @@ -11,7 +11,7 @@ Signed-off-by: Jonas Gorski --- a/drivers/mtd/devices/m25p80.c +++ b/drivers/mtd/devices/m25p80.c -@@ -229,7 +229,8 @@ static int m25p_probe(struct spi_device +@@ -251,7 +251,8 @@ static int m25p_probe(struct spi_device ppdata.of_node = spi->dev.of_node; diff --git a/target/linux/brcm63xx/patches-4.4/203-MTD-DEVICES-m25p80-add-support-for-limiting-reads.patch b/target/linux/brcm63xx/patches-4.4/203-MTD-DEVICES-m25p80-add-support-for-limiting-reads.patch index 3877442..75a874d 100644 --- a/target/linux/brcm63xx/patches-4.4/203-MTD-DEVICES-m25p80-add-support-for-limiting-reads.patch +++ b/target/linux/brcm63xx/patches-4.4/203-MTD-DEVICES-m25p80-add-support-for-limiting-reads.patch @@ -28,7 +28,7 @@ Signed-off-by: Jonas Gorski size_t *retlen, u_char *buf) { struct m25p *flash = nor->priv; -@@ -152,6 +153,29 @@ static int m25p80_read(struct spi_nor *n +@@ -174,6 +175,29 @@ static int m25p80_read(struct spi_nor *n return 0; } @@ -58,7 +58,7 @@ Signed-off-by: Jonas Gorski static int m25p80_erase(struct spi_nor *nor, loff_t offset) { struct m25p *flash = nor->priv; -@@ -223,6 +247,9 @@ static int m25p_probe(struct spi_device +@@ -245,6 +269,9 @@ static int m25p_probe(struct spi_device else flash_name = spi->modalias; diff --git a/target/linux/brcm63xx/patches-4.4/414-MTD-m25p80-allow-passing-pp_data.patch b/target/linux/brcm63xx/patches-4.4/414-MTD-m25p80-allow-passing-pp_data.patch index e421e9a..bbb565e 100644 --- a/target/linux/brcm63xx/patches-4.4/414-MTD-m25p80-allow-passing-pp_data.patch +++ b/target/linux/brcm63xx/patches-4.4/414-MTD-m25p80-allow-passing-pp_data.patch @@ -10,7 +10,7 @@ Subject: [PATCH 64/79] MTD: m25p80: allow passing pp_data --- a/drivers/mtd/devices/m25p80.c +++ b/drivers/mtd/devices/m25p80.c -@@ -250,6 +250,9 @@ static int m25p_probe(struct spi_device +@@ -272,6 +272,9 @@ static int m25p_probe(struct spi_device if (data) flash->max_transfer_len = data->max_transfer_len; diff --git a/target/linux/generic/patches-4.4/045-mtd-devices-m25p80-add-support-for-mmap-read-request.patch b/target/linux/generic/patches-4.4/045-mtd-devices-m25p80-add-support-for-mmap-read-request.patch index ee85f44..c4c7e6e 100644 --- a/target/linux/generic/patches-4.4/045-mtd-devices-m25p80-add-support-for-mmap-read-request.patch +++ b/target/linux/generic/patches-4.4/045-mtd-devices-m25p80-add-support-for-mmap-read-request.patch @@ -15,7 +15,7 @@ Signed-off-by: Brian Norris --- a/drivers/mtd/devices/m25p80.c +++ b/drivers/mtd/devices/m25p80.c -@@ -131,6 +131,28 @@ static int m25p80_read(struct spi_nor *nor, loff_t from, size_t len, +@@ -131,6 +131,28 @@ static int m25p80_read(struct spi_nor *n /* convert the dummy cycles to the number of bytes */ dummy /= 8; diff --git a/target/linux/generic/patches-4.4/081-spi-bcm53xx-add-spi_flash_read-callback-for-MMIO-bas.patch b/target/linux/generic/patches-4.4/081-spi-bcm53xx-add-spi_flash_read-callback-for-MMIO-bas.patch index 5f131e7..730f41e 100644 --- a/target/linux/generic/patches-4.4/081-spi-bcm53xx-add-spi_flash_read-callback-for-MMIO-bas.patch +++ b/target/linux/generic/patches-4.4/081-spi-bcm53xx-add-spi_flash_read-callback-for-MMIO-bas.patch @@ -34,7 +34,7 @@ Signed-off-by: Mark Brown }; static inline u32 bcm53xxspi_read(struct bcm53xxspi *b53spi, u16 offset) -@@ -32,6 +35,50 @@ static inline void bcm53xxspi_write(struct bcm53xxspi *b53spi, u16 offset, +@@ -32,6 +35,50 @@ static inline void bcm53xxspi_write(stru bcma_write32(b53spi->core, offset, value); } @@ -85,7 +85,7 @@ Signed-off-by: Mark Brown static inline unsigned int bcm53xxspi_calc_timeout(size_t len) { /* Do some magic calculation based on length and buad. Add 10% and 1. */ -@@ -176,6 +223,8 @@ static int bcm53xxspi_transfer_one(struct spi_master *master, +@@ -176,6 +223,8 @@ static int bcm53xxspi_transfer_one(struc u8 *buf; size_t left; @@ -94,7 +94,7 @@ Signed-off-by: Mark Brown if (t->tx_buf) { buf = (u8 *)t->tx_buf; left = t->len; -@@ -206,6 +255,22 @@ static int bcm53xxspi_transfer_one(struct spi_master *master, +@@ -206,6 +255,22 @@ static int bcm53xxspi_transfer_one(struc return 0; } @@ -117,7 +117,7 @@ Signed-off-by: Mark Brown /************************************************** * BCMA **************************************************/ -@@ -222,6 +287,7 @@ MODULE_DEVICE_TABLE(bcma, bcm53xxspi_bcma_tbl); +@@ -222,6 +287,7 @@ MODULE_DEVICE_TABLE(bcma, bcm53xxspi_bcm static int bcm53xxspi_bcma_probe(struct bcma_device *core) { @@ -125,7 +125,7 @@ Signed-off-by: Mark Brown struct bcm53xxspi *b53spi; struct spi_master *master; int err; -@@ -231,7 +297,7 @@ static int bcm53xxspi_bcma_probe(struct bcma_device *core) +@@ -231,7 +297,7 @@ static int bcm53xxspi_bcma_probe(struct return -ENOTSUPP; } @@ -134,7 +134,7 @@ Signed-off-by: Mark Brown if (!master) return -ENOMEM; -@@ -239,11 +305,19 @@ static int bcm53xxspi_bcma_probe(struct bcma_device *core) +@@ -239,11 +305,19 @@ static int bcm53xxspi_bcma_probe(struct b53spi->master = master; b53spi->core = core; diff --git a/target/linux/generic/patches-4.4/207-mips-vdso-dbg-rebuild-after-genvdso.patch b/target/linux/generic/patches-4.4/207-mips-vdso-dbg-rebuild-after-genvdso.patch index 2a36f2a..cd988a9 100644 --- a/target/linux/generic/patches-4.4/207-mips-vdso-dbg-rebuild-after-genvdso.patch +++ b/target/linux/generic/patches-4.4/207-mips-vdso-dbg-rebuild-after-genvdso.patch @@ -1,7 +1,5 @@ -Index: linux-4.4.9/arch/mips/vdso/Makefile -=================================================================== ---- linux-4.4.9.orig/arch/mips/vdso/Makefile -+++ linux-4.4.9/arch/mips/vdso/Makefile +--- a/arch/mips/vdso/Makefile ++++ b/arch/mips/vdso/Makefile @@ -75,7 +75,7 @@ $(obj-vdso): KBUILD_AFLAGS := $(aflags-v $(obj)/vdso.lds: KBUILD_CPPFLAGS := $(native-abi) @@ -13,10 +11,10 @@ Index: linux-4.4.9/arch/mips/vdso/Makefile $(obj)/vdso-image.c: $(obj)/vdso.so.dbg $(obj)/genvdso FORCE @@ -109,7 +109,7 @@ $(obj)/vdso-o32.lds: KBUILD_CPPFLAGS := $(obj)/vdso-o32.lds: $(src)/vdso.lds.S FORCE - $(call if_changed_dep,cpp_lds_S) - + $(call if_changed_dep,cpp_lds_S) + -$(obj)/vdso-o32.so.dbg: $(obj)/vdso-o32.lds $(obj-vdso-o32) FORCE +$(obj)/vdso-o32.so.dbg: $(obj)/vdso-o32.lds $(obj-vdso-o32) $(obj)/genvdso FORCE - $(call if_changed,vdsold) - + $(call if_changed,vdsold) + $(obj)/vdso-o32-image.c: VDSO_NAME := o32 diff --git a/target/linux/generic/patches-4.4/630-packet_socket_type.patch b/target/linux/generic/patches-4.4/630-packet_socket_type.patch index d649bf0..48c4220 100644 --- a/target/linux/generic/patches-4.4/630-packet_socket_type.patch +++ b/target/linux/generic/patches-4.4/630-packet_socket_type.patch @@ -51,7 +51,7 @@ Signed-off-by: Felix Fietkau goto out; if (!net_eq(dev_net(dev), sock_net(sk))) -@@ -1982,12 +1984,12 @@ static int packet_rcv(struct sk_buff *sk +@@ -1986,12 +1988,12 @@ static int packet_rcv(struct sk_buff *sk int skb_len = skb->len; unsigned int snaplen, res; @@ -67,7 +67,7 @@ Signed-off-by: Felix Fietkau if (!net_eq(dev_net(dev), sock_net(sk))) goto drop; -@@ -2107,12 +2109,12 @@ static int tpacket_rcv(struct sk_buff *s +@@ -2111,12 +2113,12 @@ static int tpacket_rcv(struct sk_buff *s BUILD_BUG_ON(TPACKET_ALIGN(sizeof(*h.h2)) != 32); BUILD_BUG_ON(TPACKET_ALIGN(sizeof(*h.h3)) != 48); @@ -83,7 +83,7 @@ Signed-off-by: Felix Fietkau if (!net_eq(dev_net(dev), sock_net(sk))) goto drop; -@@ -3097,6 +3099,7 @@ static int packet_create(struct net *net +@@ -3092,6 +3094,7 @@ static int packet_create(struct net *net mutex_init(&po->pg_vec_lock); po->rollover = NULL; po->prot_hook.func = packet_rcv; @@ -91,7 +91,7 @@ Signed-off-by: Felix Fietkau if (sock->type == SOCK_PACKET) po->prot_hook.func = packet_rcv_spkt; -@@ -3712,6 +3715,16 @@ packet_setsockopt(struct socket *sock, i +@@ -3707,6 +3710,16 @@ packet_setsockopt(struct socket *sock, i po->xmit = val ? packet_direct_xmit : dev_queue_xmit; return 0; } @@ -108,7 +108,7 @@ Signed-off-by: Felix Fietkau default: return -ENOPROTOOPT; } -@@ -3764,6 +3777,13 @@ static int packet_getsockopt(struct sock +@@ -3759,6 +3772,13 @@ static int packet_getsockopt(struct sock case PACKET_VNET_HDR: val = po->has_vnet_hdr; break; diff --git a/target/linux/generic/patches-4.4/642-bridge_port_isolate.patch b/target/linux/generic/patches-4.4/642-bridge_port_isolate.patch index 0be8c8f..1dc32b6 100644 --- a/target/linux/generic/patches-4.4/642-bridge_port_isolate.patch +++ b/target/linux/generic/patches-4.4/642-bridge_port_isolate.patch @@ -11,8 +11,8 @@ Isolating individual bridge ports #define BR_PROXYARP_WIFI BIT(10) +#define BR_ISOLATE_MODE BIT(11) - /* values as per ieee8021QBridgeFdbAgingTime */ - #define BR_MIN_AGEING_TIME (10 * HZ) + #define BR_DEFAULT_AGEING_TIME (300 * HZ) + --- a/net/bridge/br_sysfs_if.c +++ b/net/bridge/br_sysfs_if.c @@ -173,6 +173,22 @@ BRPORT_ATTR_FLAG(unicast_flood, BR_FLOOD diff --git a/target/linux/generic/patches-4.4/645-bridge_multicast_to_unicast.patch b/target/linux/generic/patches-4.4/645-bridge_multicast_to_unicast.patch index 59aa1ed..f729f38 100644 --- a/target/linux/generic/patches-4.4/645-bridge_multicast_to_unicast.patch +++ b/target/linux/generic/patches-4.4/645-bridge_multicast_to_unicast.patch @@ -11,8 +11,8 @@ Implement optinal multicast->unicast conversion for igmp snooping #define BR_ISOLATE_MODE BIT(11) +#define BR_MULTICAST_TO_UCAST BIT(12) - /* values as per ieee8021QBridgeFdbAgingTime */ - #define BR_MIN_AGEING_TIME (10 * HZ) + #define BR_DEFAULT_AGEING_TIME (300 * HZ) + --- a/net/bridge/br_multicast.c +++ b/net/bridge/br_multicast.c @@ -42,12 +42,13 @@ static void br_multicast_add_router(stru diff --git a/target/linux/generic/patches-4.4/655-increase_skb_pad.patch b/target/linux/generic/patches-4.4/655-increase_skb_pad.patch index e46e470..ad95d4c 100644 --- a/target/linux/generic/patches-4.4/655-increase_skb_pad.patch +++ b/target/linux/generic/patches-4.4/655-increase_skb_pad.patch @@ -1,6 +1,6 @@ --- a/include/linux/skbuff.h +++ b/include/linux/skbuff.h -@@ -2155,7 +2155,7 @@ static inline int pskb_network_may_pull( +@@ -2179,7 +2179,7 @@ static inline int pskb_network_may_pull( * NET_IP_ALIGN(2) + ethernet_header(14) + IP_header(20/40) + ports(8) */ #ifndef NET_SKB_PAD diff --git a/target/linux/generic/patches-4.4/656-skb_reduce_truesize-helper.patch b/target/linux/generic/patches-4.4/656-skb_reduce_truesize-helper.patch index 341a31b..dad7448 100644 --- a/target/linux/generic/patches-4.4/656-skb_reduce_truesize-helper.patch +++ b/target/linux/generic/patches-4.4/656-skb_reduce_truesize-helper.patch @@ -14,7 +14,7 @@ when needed. --- a/include/linux/skbuff.h +++ b/include/linux/skbuff.h -@@ -2200,6 +2200,24 @@ static inline void pskb_trim_unique(stru +@@ -2224,6 +2224,24 @@ static inline void pskb_trim_unique(stru BUG_ON(err); } diff --git a/target/linux/generic/patches-4.4/666-Add-support-for-MAP-E-FMRs-mesh-mode.patch b/target/linux/generic/patches-4.4/666-Add-support-for-MAP-E-FMRs-mesh-mode.patch index d511520..657804a 100644 --- a/target/linux/generic/patches-4.4/666-Add-support-for-MAP-E-FMRs-mesh-mode.patch +++ b/target/linux/generic/patches-4.4/666-Add-support-for-MAP-E-FMRs-mesh-mode.patch @@ -295,15 +295,15 @@ Signed-off-by: Steven Barth __skb_tunnel_rx(skb, t->dev, t->net); -@@ -1179,6 +1316,7 @@ ip4ip6_tnl_xmit(struct sk_buff *skb, str +@@ -1224,6 +1361,7 @@ ip6ip6_tnl_xmit(struct sk_buff *skb, str __u32 mtu; u8 tproto; int err; + struct __ip6_tnl_fmr *fmr; tproto = ACCESS_ONCE(t->parms.proto); - if (tproto != IPPROTO_IPIP && tproto != 0) -@@ -1198,6 +1336,18 @@ ip4ip6_tnl_xmit(struct sk_buff *skb, str + if ((tproto != IPPROTO_IPV6 && tproto != 0) || +@@ -1254,6 +1392,18 @@ ip6ip6_tnl_xmit(struct sk_buff *skb, str if (t->parms.flags & IP6_TNL_F_USE_ORIG_FWMARK) fl6.flowi6_mark = skb->mark; @@ -321,8 +321,8 @@ Signed-off-by: Steven Barth + err = ip6_tnl_xmit2(skb, dev, dsfield, &fl6, encap_limit, &mtu); if (err != 0) { - /* XXX: send ICMP error even if DF is not set. */ -@@ -1366,6 +1516,14 @@ ip6_tnl_change(struct ip6_tnl *t, const + if (err == -EMSGSIZE) +@@ -1368,6 +1518,14 @@ ip6_tnl_change(struct ip6_tnl *t, const t->parms.flowinfo = p->flowinfo; t->parms.link = p->link; t->parms.proto = p->proto; @@ -337,7 +337,7 @@ Signed-off-by: Steven Barth ip6_tnl_dst_reset(t); ip6_tnl_link_config(t); return 0; -@@ -1404,6 +1562,7 @@ ip6_tnl_parm_from_user(struct __ip6_tnl_ +@@ -1406,6 +1564,7 @@ ip6_tnl_parm_from_user(struct __ip6_tnl_ p->flowinfo = u->flowinfo; p->link = u->link; p->proto = u->proto; @@ -345,7 +345,7 @@ Signed-off-by: Steven Barth memcpy(p->name, u->name, sizeof(u->name)); } -@@ -1699,6 +1858,15 @@ static int ip6_tnl_validate(struct nlatt +@@ -1701,6 +1860,15 @@ static int ip6_tnl_validate(struct nlatt return 0; } @@ -361,7 +361,7 @@ Signed-off-by: Steven Barth static void ip6_tnl_netlink_parms(struct nlattr *data[], struct __ip6_tnl_parm *parms) { -@@ -1730,6 +1898,46 @@ static void ip6_tnl_netlink_parms(struct +@@ -1732,6 +1900,46 @@ static void ip6_tnl_netlink_parms(struct if (data[IFLA_IPTUN_PROTO]) parms->proto = nla_get_u8(data[IFLA_IPTUN_PROTO]); @@ -408,7 +408,7 @@ Signed-off-by: Steven Barth } static int ip6_tnl_newlink(struct net *src_net, struct net_device *dev, -@@ -1782,6 +1990,12 @@ static void ip6_tnl_dellink(struct net_d +@@ -1784,6 +1992,12 @@ static void ip6_tnl_dellink(struct net_d static size_t ip6_tnl_get_size(const struct net_device *dev) { @@ -421,7 +421,7 @@ Signed-off-by: Steven Barth return /* IFLA_IPTUN_LINK */ nla_total_size(4) + -@@ -1799,6 +2013,24 @@ static size_t ip6_tnl_get_size(const str +@@ -1801,6 +2015,24 @@ static size_t ip6_tnl_get_size(const str nla_total_size(4) + /* IFLA_IPTUN_PROTO */ nla_total_size(1) + @@ -446,7 +446,7 @@ Signed-off-by: Steven Barth 0; } -@@ -1806,6 +2038,9 @@ static int ip6_tnl_fill_info(struct sk_b +@@ -1808,6 +2040,9 @@ static int ip6_tnl_fill_info(struct sk_b { struct ip6_tnl *tunnel = netdev_priv(dev); struct __ip6_tnl_parm *parm = &tunnel->parms; @@ -456,7 +456,7 @@ Signed-off-by: Steven Barth if (nla_put_u32(skb, IFLA_IPTUN_LINK, parm->link) || nla_put_in6_addr(skb, IFLA_IPTUN_LOCAL, &parm->laddr) || -@@ -1814,8 +2049,27 @@ static int ip6_tnl_fill_info(struct sk_b +@@ -1816,8 +2051,27 @@ static int ip6_tnl_fill_info(struct sk_b nla_put_u8(skb, IFLA_IPTUN_ENCAP_LIMIT, parm->encap_limit) || nla_put_be32(skb, IFLA_IPTUN_FLOWINFO, parm->flowinfo) || nla_put_u32(skb, IFLA_IPTUN_FLAGS, parm->flags) || @@ -485,7 +485,7 @@ Signed-off-by: Steven Barth return 0; nla_put_failure: -@@ -1839,6 +2093,7 @@ static const struct nla_policy ip6_tnl_p +@@ -1841,6 +2095,7 @@ static const struct nla_policy ip6_tnl_p [IFLA_IPTUN_FLOWINFO] = { .type = NLA_U32 }, [IFLA_IPTUN_FLAGS] = { .type = NLA_U32 }, [IFLA_IPTUN_PROTO] = { .type = NLA_U8 }, diff --git a/target/linux/generic/patches-4.4/721-phy_packets.patch b/target/linux/generic/patches-4.4/721-phy_packets.patch index 04bafcd..79af5f9 100644 --- a/target/linux/generic/patches-4.4/721-phy_packets.patch +++ b/target/linux/generic/patches-4.4/721-phy_packets.patch @@ -1,6 +1,6 @@ --- a/include/linux/netdevice.h +++ b/include/linux/netdevice.h -@@ -1297,6 +1297,7 @@ enum netdev_priv_flags { +@@ -1298,6 +1298,7 @@ enum netdev_priv_flags { IFF_NO_QUEUE = 1<<21, IFF_OPENVSWITCH = 1<<22, IFF_L3MDEV_SLAVE = 1<<23, @@ -8,7 +8,7 @@ }; #define IFF_802_1Q_VLAN IFF_802_1Q_VLAN -@@ -1323,6 +1324,7 @@ enum netdev_priv_flags { +@@ -1324,6 +1325,7 @@ enum netdev_priv_flags { #define IFF_NO_QUEUE IFF_NO_QUEUE #define IFF_OPENVSWITCH IFF_OPENVSWITCH #define IFF_L3MDEV_SLAVE IFF_L3MDEV_SLAVE @@ -41,7 +41,7 @@ */ --- a/include/linux/skbuff.h +++ b/include/linux/skbuff.h -@@ -2186,6 +2186,10 @@ static inline int pskb_trim(struct sk_bu +@@ -2210,6 +2210,10 @@ static inline int pskb_trim(struct sk_bu return (len < skb->len) ? __pskb_trim(skb, len) : 0; } @@ -52,7 +52,7 @@ /** * pskb_trim_unique - remove end from a paged unique (not cloned) buffer * @skb: buffer to alter -@@ -2308,16 +2312,6 @@ static inline struct sk_buff *dev_alloc_ +@@ -2332,16 +2336,6 @@ static inline struct sk_buff *dev_alloc_ } diff --git a/target/linux/generic/patches-4.4/903-debloat_direct_io.patch b/target/linux/generic/patches-4.4/903-debloat_direct_io.patch index ee85c40..460da1d 100644 --- a/target/linux/generic/patches-4.4/903-debloat_direct_io.patch +++ b/target/linux/generic/patches-4.4/903-debloat_direct_io.patch @@ -26,7 +26,7 @@ endif --- a/include/linux/fs.h +++ b/include/linux/fs.h -@@ -2681,6 +2681,7 @@ enum { +@@ -2691,6 +2691,7 @@ enum { DIO_SKIP_DIO_COUNT = 0x08, }; @@ -34,7 +34,7 @@ void dio_end_io(struct bio *bio, int error); ssize_t __blockdev_direct_IO(struct kiocb *iocb, struct inode *inode, -@@ -2688,6 +2689,18 @@ ssize_t __blockdev_direct_IO(struct kioc +@@ -2698,6 +2699,18 @@ ssize_t __blockdev_direct_IO(struct kioc loff_t offset, get_block_t get_block, dio_iodone_t end_io, dio_submit_t submit_io, int flags); -- 2.5.5 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Tue May 17 11:52:24 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Tue, 17 May 2016 17:52:24 +0200 Subject: [OpenWrt-Devel] [PATCH 1/4] ar71xx: Add support for initramfs images for OpenMesh devices Message-ID: <1463500347-21432-1-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann --- target/linux/ar71xx/image/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/target/linux/ar71xx/image/Makefile b/target/linux/ar71xx/image/Makefile index bc8a4a8..1acc681 100644 --- a/target/linux/ar71xx/image/Makefile +++ b/target/linux/ar71xx/image/Makefile @@ -2307,6 +2307,7 @@ endef Image/Build/OpenMesh/buildkernel=$(call MkuImageLzma,$(2)) +Image/Build/OpenMesh/initramfs=$(call MkuImageLzma/initramfs,$(2),) define Image/Build/OpenMesh -sh $(TOPDIR)/scripts/om-fwupgradecfg-gen.sh \ -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Tue May 17 11:52:25 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Tue, 17 May 2016 17:52:25 +0200 Subject: [OpenWrt-Devel] [PATCH 2/4] ar71xx: Generate sysupgrade images for OpenMesh devices In-Reply-To: <1463500347-21432-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463500347-21432-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463500347-21432-2-git-send-email-sven.eckelmann@open-mesh.com> Some OpenWrt based firmwares like Gluon expect that a sysupgrade image exists when a device firmware can be updated via sysupgrade. This image wasn't created until now because OpenMesh devices use the same image for factory and sysupgrade flash. Copying the image from *factory.bin to *sysupgrade.bin is therefore enough to make the sysupgrade functionality visible. Reported-by: Matthias Schiffer Signed-off-by: Sven Eckelmann --- target/linux/ar71xx/image/Makefile | 3 +++ 1 file changed, 3 insertions(+) diff --git a/target/linux/ar71xx/image/Makefile b/target/linux/ar71xx/image/Makefile index 1acc681..6acc199 100644 --- a/target/linux/ar71xx/image/Makefile +++ b/target/linux/ar71xx/image/Makefile @@ -2320,6 +2320,9 @@ define Image/Build/OpenMesh "$(BUILD_DIR)/fwupgrade.cfg-$(4)" "fwupgrade.cfg" \ "$(KDIR_TMP)/vmlinux-$(2).uImage" "kernel" \ "$(KDIR)/root.$(1)" "rootfs" + if [ -e "$(call factoryname,$(1),$(2))" ]; then \ + cp "$(call factoryname,$(1),$(2))" "$(call sysupname,$(1),$(2))"; \ + fi endef -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Tue May 17 11:52:26 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Tue, 17 May 2016 17:52:26 +0200 Subject: [OpenWrt-Devel] [PATCH 3/4] ar71xx: Move OpenMesh image target validation into subfunction In-Reply-To: <1463500347-21432-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463500347-21432-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463500347-21432-3-git-send-email-sven.eckelmann@open-mesh.com> The platform_check_image_openmesh function used break statements to signal that the board name matched the image target. This worked because the sysupgrade binary checked the image inside a loop. The break statement stopped the loop and skipped any additional check. Instead the check should be done without such sideeffects by simply combining the board names and image targets. Only a mismatch should cause a negative result for the caller and skipping of the additional checks. Signed-off-by: Sven Eckelmann --- .../ar71xx/base-files/lib/upgrade/openmesh.sh | 71 ++++++++++++---------- 1 file changed, 39 insertions(+), 32 deletions(-) diff --git a/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh b/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh index 209cdaa..e026946 100644 --- a/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh +++ b/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh @@ -36,62 +36,46 @@ platform_add_ramfs_ubootenv() } append sysupgrade_pre_upgrade platform_add_ramfs_ubootenv -platform_check_image_openmesh() +platform_check_image_target_openmesh() { - local img_magic=$1 - local img_path=$2 - local fw_printenv=/usr/sbin/fw_printenv - local img_board_target= img_num_files= i=0 - local cfg_name= kernel_name= rootfs_name= - - case "$img_magic" in - # Combined Extended Image v1 - 43453031) - img_board_target=$(trim $(dd if="$img_path" bs=4 skip=1 count=8 2>/dev/null)) - img_num_files=$(trim $(dd if="$img_path" bs=2 skip=18 count=1 2>/dev/null)) - ;; - *) - echo "Invalid image ($img_magic). Use combined extended images on this platform" - return 1 - ;; - esac + img_board_target="$1" case "$img_board_target" in OM2P) - [ "$board" = "om2p" ] && break - [ "$board" = "om2pv2" ] && break - [ "$board" = "om2p-lc" ] && break - [ "$board" = "om2p-hs" ] && break - [ "$board" = "om2p-hsv2" ] && break + [ "$board" = "om2p" ] && return 0 + [ "$board" = "om2pv2" ] && return 0 + [ "$board" = "om2p-lc" ] && return 0 + [ "$board" = "om2p-hs" ] && return 0 + [ "$board" = "om2p-hsv2" ] && return 0 echo "Invalid image board target ($img_board_target) for this platform: $board. Use the correct image for this platform" return 1 ;; OM5P) - [ "$board" = "om5p" ] && break - [ "$board" = "om5p-an" ] && break + [ "$board" = "om5p" ] && return 0 + [ "$board" = "om5p-an" ] && return 0 echo "Invalid image board target ($img_board_target) for this platform: $board. Use the correct image for this platform" return 1 ;; OM5PAC) - [ "$board" = "om5p-ac" ] && break - [ "$board" = "om5p-acv2" ] && break + [ "$board" = "om5p-ac" ] && return 0 + [ "$board" = "om5p-acv2" ] && return 0 echo "Invalid image board target ($img_board_target) for this platform: $board. Use the correct image for this platform" return 1 ;; MR1750) - [ "$board" = "mr1750" ] && break + [ "$board" = "mr1750" ] && return 0 echo "Invalid image board target ($img_board_target) for this platform: $board. Use the correct image for this platform" return 1 ;; MR600) - [ "$board" = "mr600" ] && break - [ "$board" = "mr600v2" ] && break + [ "$board" = "mr600" ] && return 0 + [ "$board" = "mr600v2" ] && return 0 echo "Invalid image board target ($img_board_target) for this platform: $board. Use the correct image for this platform" return 1 ;; MR900) - [ "$board" = "mr900" ] && break - [ "$board" = "mr900v2" ] && break + [ "$board" = "mr900" ] && return 0 + [ "$board" = "mr900v2" ] && return 0 echo "Invalid image board target ($img_board_target) for this platform: $board. Use the correct image for this platform" return 1 ;; @@ -100,6 +84,29 @@ platform_check_image_openmesh() return 1 ;; esac +} + +platform_check_image_openmesh() +{ + local img_magic=$1 + local img_path=$2 + local fw_printenv=/usr/sbin/fw_printenv + local img_board_target= img_num_files= i=0 + local cfg_name= kernel_name= rootfs_name= + + case "$img_magic" in + # Combined Extended Image v1 + 43453031) + img_board_target=$(trim $(dd if="$img_path" bs=4 skip=1 count=8 2>/dev/null)) + img_num_files=$(trim $(dd if="$img_path" bs=2 skip=18 count=1 2>/dev/null)) + ;; + *) + echo "Invalid image ($img_magic). Use combined extended images on this platform" + return 1 + ;; + esac + + platform_check_image_target_openmesh "$img_board_target" || return 1 [ $img_num_files -ne 3 ] && { echo "Invalid number of embedded images ($img_num_files). Use the correct image for this platform" -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Tue May 17 11:52:27 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Tue, 17 May 2016 17:52:27 +0200 Subject: [OpenWrt-Devel] [PATCH 4/4] ar71xx: Allow OpenMesh CE images with more than 3 files In-Reply-To: <1463500347-21432-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463500347-21432-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463500347-21432-4-git-send-email-sven.eckelmann@open-mesh.com> The CE image format used by OpenMesh can contain extra blocks which are not used for flashing. Only the first three embedded images (fwupgrade.cfg, kernel, rootfs) are required in this order to successfully flash an image via sysupgrade. All extra embedded images should be ignored for the available devices. Signed-off-by: Sven Eckelmann --- target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh b/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh index e026946..bc362a7 100644 --- a/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh +++ b/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh @@ -108,7 +108,7 @@ platform_check_image_openmesh() platform_check_image_target_openmesh "$img_board_target" || return 1 - [ $img_num_files -ne 3 ] && { + [ $img_num_files -lt 3 ] && { echo "Invalid number of embedded images ($img_num_files). Use the correct image for this platform" return 1 } -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From info at gerhard-bertelsmann.de Tue May 17 21:47:14 2016 From: info at gerhard-bertelsmann.de (Gerhard Bertelsmann) Date: Wed, 18 May 2016 03:47:14 +0200 Subject: [OpenWrt-Devel] [LEDE-DEV] [PATCH] ramips: fix 8M WT3020 image creation Message-ID: <537ec392b5a20ecc8522ecb474f79eb8@mail.rdts.de> fix image size for 8M version : 4M -> 8M Signed-off-by: Gerhard Bertelsmann --- target/linux/ramips/image/mt7620.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/ramips/image/mt7620.mk b/target/linux/ramips/image/mt7620.mk index 862f016..f236ba5 100644 --- a/target/linux/ramips/image/mt7620.mk +++ b/target/linux/ramips/image/mt7620.mk @@ -77,7 +77,7 @@ define Device/wt3020-8M DTS := WT3020-8M IMAGE_SIZE := $(ralink_default_fw_size_8M) IMAGES += factory.bin - IMAGE/factory.bin := $$(IMAGE/sysupgrade.bin) | poray-header -B WT3020 -F 4M + IMAGE/factory.bin := $$(IMAGE/sysupgrade.bin) | poray-header -B WT3020 -F 8M DEVICE_TITLE := Nexx WT3020 (8MB) endef TARGET_DEVICES += wt3020-8M _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Wed May 18 02:24:07 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Wed, 18 May 2016 02:24:07 -0400 Subject: [OpenWrt-Devel] Why does multiple instance dnsmasq work with jails but not without? Message-ID: <573C0A87.8020905@daniel.thecshore.com> Hi all, I had a patch that I submitted to the openwrt list sometime back that launched multiple instances of dnsmasq, so long as the instances were either tied to specific, non-overlapping, interfaces, or used different dns port, but at least in the case of different interfaces it only worked (to my dismay) if jails were in use. Without jails only a single instance of dnsmasq would start. Does anyone know why this is? (The use case is to serve a guest vlan with a dnsmasq instance that forced the to use the opendns familyshield filter (since the point of guest vlan is you don't necessarily know how far to trust the people on the guest vlan (for a separate wifi SSID)). Regards, Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From oswald.buddenhagen at gmx.de Wed May 18 03:37:57 2016 From: oswald.buddenhagen at gmx.de (Oswald Buddenhagen) Date: Wed, 18 May 2016 09:37:57 +0200 Subject: [OpenWrt-Devel] [PATCH] lantiq: add support for ARV7506PW11 (Alice/O2 IAD 4421) Message-ID: <1463557077-19088-1-git-send-email-oswald.buddenhagen@gmx.de> Ethernet, WiFi, ADSL2+, and LEDS are fully functional. The RFkill switch doesn't appear to be correctly configured. Supporting the two TAE ports and SIP gateway was not attempted. The firmware image needs to be kept below ~3.6MiB due to brnboot's dual image magic. This is just enough for the above configuration plus dropbear. Luci and other non-critical packages must be installed into the jffs2 once the device has booted. U-boot support was not attempted. Signed-off-by: Oswald Buddenhagen --- .../linux/lantiq/base-files/etc/board.d/02_network | 8 + .../etc/hotplug.d/firmware/10-rt2x00-eeprom | 2 +- target/linux/lantiq/dts/ARV7506PW11.dts | 213 +++++++++++++++++++++ target/linux/lantiq/image/Makefile | 2 + target/linux/lantiq/xway/profiles/arv.mk | 12 ++ 5 files changed, 236 insertions(+), 1 deletion(-) create mode 100644 target/linux/lantiq/dts/ARV7506PW11.dts diff --git a/target/linux/lantiq/base-files/etc/board.d/02_network b/target/linux/lantiq/base-files/etc/board.d/02_network index b27b802..1f06c26 100755 --- a/target/linux/lantiq/base-files/etc/board.d/02_network +++ b/target/linux/lantiq/base-files/etc/board.d/02_network @@ -39,6 +39,14 @@ ACMP252|GIGASX76X) "4:lan:1" "3:lan:2" "2:lan:3" "1:lan:4" "5t at eth0" ;; +# rtl8306g +ARV7506PW11) + lan_mac=$(mtd_get_mac_binary board_config 22) + wan_mac=$(macaddr_add "$lan_mac" 1) + ucidef_add_switch "switch0" \ + "4:lan:1" "3:lan:2" "2:lan:3" "1:lan:4" "5t at eth0" + ;; + # ar8316 ARV4519PW|ARV7510PW22|ARV7518PW|ARV752DPW22|ARV8539PW22) ucidef_add_switch "switch0" \ diff --git a/target/linux/lantiq/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom b/target/linux/lantiq/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom index 5f1cb00..da10797 100644 --- a/target/linux/lantiq/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom +++ b/target/linux/lantiq/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom @@ -35,7 +35,7 @@ case "$FIRMWARE" in "RT2860.eeprom" ) local board=$(lantiq_board_name) case $board in - ARV7510PW22|ARV7519PW|ARV752DPW|ARV752DPW22|VGV7519) + ARV7506PW11|ARV7510PW22|ARV7519PW|ARV752DPW|ARV752DPW22|VGV7519) rt2x00_eeprom_extract "board_config" 520 256 1 ;; ARV7525PW) diff --git a/target/linux/lantiq/dts/ARV7506PW11.dts b/target/linux/lantiq/dts/ARV7506PW11.dts new file mode 100644 index 0000000..bb9ffd4 --- /dev/null +++ b/target/linux/lantiq/dts/ARV7506PW11.dts @@ -0,0 +1,213 @@ +/dts-v1/; + +/include/ "danube.dtsi" + +/ { + model = "ARV7506PW11 - Alice/O2 IAD 4421"; + + chosen { + leds { + boot = &power; + failsafe = &power_red; + running = &power; + + dsl = &dsl; + internet = &internet; + wifi = &wlan; + }; + }; + + memory at 0 { + reg = <0x0 0x4000000>; + }; + + sram at 1F000000 { + vmmc at 107000 { + status = "okay"; + gpios = <&gpiomm 1 0>; + }; + }; + + fpi at 10000000 { + localbus at 0 { + nor-boot at 0 { + compatible = "lantiq,nor"; + bank-width = <2>; + reg = <0 0x0 0x800000>; + + partitions { + compatible = "fixed-partitions"; + #address-cells = <1>; + #size-cells = <1>; + + partition at 0 { + label = "brnboot"; + reg = <0x00000 0x20000>; + read-only; + }; + + partition at 20000 { + label = "stuff"; + reg = <0x20000 0x70000>; + }; + + partition at 90000 { + label = "rootfs_data"; + reg = <0x90000 0x3B0000>; + }; + + partition at 440000 { + label = "firmware"; + reg = <0x440000 0x3B0000>; + }; + + partition at 7f0000 { + label = "board_config"; + reg = <0x7f0000 0x10000>; + read-only; + }; + }; + }; + + mac_addr { + compatible = "lantiq,eth-mac"; + reg = <0 0x7f0016 0x6>; + mac-increment = <2>; + }; + + gpiomm: gpiomm at 4000000 { + compatible = "lantiq,gpio-mm"; + reg = <1 0x0 0x10 >; + #address-cells = <1>; + #size-cells = <1>; + #gpio-cells = <2>; + gpio-controller; + lantiq,shadow = <0x3>; + }; + }; + + gpio: pinmux at E100B10 { + pinctrl-names = "default"; + pinctrl-0 = <&state_default>; + + state_default: pinmux { + ebu { + lantiq,groups = "ebu cs1"; + lantiq,function = "ebu"; + }; + exin { + lantiq,groups = "exin1"; + lantiq,function = "exin"; + }; + pci_in { + lantiq,groups = "req2", "req1"; + lantiq,function = "pci"; + lantiq,pull = <2>; + lantiq,output = <0>; + }; + pci_out { + lantiq,groups = "gnt1"; + lantiq,function = "pci"; + lantiq,output = <1>; + }; + pci_rst { + lantiq,pins = "io21"; + lantiq,pull = <2>; + lantiq,output = <1>; + }; + switch_rst { + lantiq,pins = "io19"; + }; + leds { + lantiq,pins = "io2", "io3", "io4", "io5", "io6", "io7", "io8", "io9", "io20"; + lantiq,output = <1>; + lantiq,pull = <0>; + }; + keys { + lantiq,pins = "io11", "io30"; + lantiq,output = <0>; + lantiq,pull = <2>; + }; + }; + }; + + ifxhcd at E101000 { + status = "okay"; + gpios = <&gpiomm 0 0>; + }; + + etop at E180000 { + phy-mode = "rmii"; + }; + + pci at E105400 { + status = "okay"; + gpio-reset = <&gpio 21 0>; + }; + + }; + + ralink_eep { + compatible = "ralink,eeprom"; + ralink,eeprom = "RT2860.eeprom"; + }; + + gpio-keys-polled { + compatible = "gpio-keys-polled"; + #address-cells = <1>; + #size-cells = <0>; + poll-interval = <100>; + + rfkill { + /* The button is labeled WLAN/WPS. The former seems more useful. */ + label = "rfkill"; + gpios = <&gpio 11 1>; + linux,code = <0x211>; + }; + reset { + label = "reset"; + gpios = <&gpio 30 1>; + linux,code = <0x198>; + }; + }; + + gpio-leds { + compatible = "gpio-leds"; + wlan: wlan { + label = "arv7506pw11:green:wlan"; + gpios = <&gpio 2 1>; + }; + power: power { + label = "arv7506pw11:green:power"; + gpios = <&gpio 3 1>; + }; + dsl: dsl { + label = "arv7506pw11:green:dsl"; + gpios = <&gpio 4 1>; + }; + internet: internet { + label = "arv7506pw11:green:internet"; + gpios = <&gpio 5 1>; + }; + power_red: power_red { + label = "arv7506pw11:red:power"; + gpios = <&gpio 6 1>; + }; + internet_red { + label = "arv7506pw11:red:internet"; + gpios = <&gpio 7 1>; + }; + info { + label = "arv7506pw11:green:info"; + gpios = <&gpio 8 1>; + }; + telefon { + label = "arv7506pw11:green:telefon"; + gpios = <&gpio 9 1>; + }; + info_red { + label = "arv7506pw11:red:info"; + gpios = <&gpio 20 1>; + }; + }; +}; diff --git a/target/linux/lantiq/image/Makefile b/target/linux/lantiq/image/Makefile index bc74e4f..7a5a564 100644 --- a/target/linux/lantiq/image/Makefile +++ b/target/linux/lantiq/image/Makefile @@ -352,6 +352,8 @@ ifeq ($(CONFIG_TARGET_lantiq_xway),y) Image/BuildKernel/Profile/BTHOMEHUBV2B=$(call Image/BuildKernel/Template,BTHOMEHUBV2B) Image/Build/Profile/BTHOMEHUBV2B=$(call Image/BuildNAND/$(1),$(1),BTHOMEHUBV2B) +$(eval $(call lantiqBrnImage,ARV7506PW11,BRNDA4421,0x7AB7ADAD,0x2083b8ed)) + $(eval $(call lantiqImage,EASY50712)) $(eval $(call lantiqImage,ACMP252)) $(eval $(call lantiqImage,ARV4510PW)) diff --git a/target/linux/lantiq/xway/profiles/arv.mk b/target/linux/lantiq/xway/profiles/arv.mk index 976cd19..e20e403 100644 --- a/target/linux/lantiq/xway/profiles/arv.mk +++ b/target/linux/lantiq/xway/profiles/arv.mk @@ -78,6 +78,18 @@ endef $(eval $(call Profile,ARV4519PW)) +define Profile/ARV7506PW11 + NAME:=Alice/O2 IAD 4421 - ARV7506PW11 + PACKAGES:= \ + kmod-ltq-adsl-danube-mei kmod-ltq-adsl-danube \ + kmod-ltq-adsl-danube-fw-b kmod-ltq-atm-danube \ + ltq-adsl-app ppp-mod-pppoa \ + kmod-rt2800-pci wpad-mini \ + swconfig +endef + +$(eval $(call Profile,ARV7506PW11)) + define Profile/ARV7510PW22 NAME:=Astoria - ARV7510PW22 PACKAGES:=kmod-ltq-hcd-danube kmod-ledtrig-usbdev \ -- 2.7.4.1.gb6fc189 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From oswald.buddenhagen at gmx.de Wed May 18 03:39:16 2016 From: oswald.buddenhagen at gmx.de (Oswald Buddenhagen) Date: Wed, 18 May 2016 09:39:16 +0200 Subject: [OpenWrt-Devel] [PATCH] [RFC] lantiq: disable a bunch of features not applicable to my box Message-ID: <1463557156-19220-1-git-send-email-oswald.buddenhagen@gmx.de> - NAND/UBI support is completely irrelevant for my box, and for lantiq/Danube in general (IIRC). It appears to me that it would make sense to split it off from the xway target. - My box has no USB port and no other sensible option to connect mass storage devices, so anything related to that makes no sense as well. - Some stuff related to my boot configuration/partitioning. Some of it should be obsolete by now due to the recently added support for brnboot alternative image switching. - foo & bar, i guess I found no way to subtract features/kernel configs in device profiles, hence this somewhat big hammer. This patch is obviously not meant for upstreaming. --- target/linux/lantiq/config-4.4 | 11 +++++----- target/linux/lantiq/xway/config-default | 39 ++++++++++++--------------------- target/linux/lantiq/xway/target.mk | 2 +- 3 files changed, 20 insertions(+), 32 deletions(-) diff --git a/target/linux/lantiq/config-4.4 b/target/linux/lantiq/config-4.4 index cf3ec47..3e39303 100644 --- a/target/linux/lantiq/config-4.4 +++ b/target/linux/lantiq/config-4.4 @@ -139,10 +139,10 @@ CONFIG_MTD_LANTIQ=y CONFIG_MTD_M25P80=y CONFIG_MTD_SPI_NOR=y CONFIG_MTD_SPLIT_BRNIMAGE_FW=y -CONFIG_MTD_SPLIT_EVA_FW=y +# CONFIG_MTD_SPLIT_EVA_FW is not set CONFIG_MTD_SPLIT_FIRMWARE=y -CONFIG_MTD_SPLIT_TPLINK_FW=y -CONFIG_MTD_SPLIT_UIMAGE_FW=y +# CONFIG_MTD_SPLIT_TPLINK_FW is not set +# CONFIG_MTD_SPLIT_UIMAGE_FW is not set CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_PER_CPU_KM=y CONFIG_NO_GENERIC_PCI_IOPORT_MAP=y @@ -170,11 +170,10 @@ CONFIG_PINCTRL=y CONFIG_PINCTRL_LANTIQ=y # CONFIG_PINCTRL_SINGLE is not set CONFIG_PINCTRL_XWAY=y -CONFIG_PSB6970_PHY=y +# CONFIG_PSB6970_PHY is not set # CONFIG_RCU_STALL_COMMON is not set CONFIG_RESET_CONTROLLER=y -CONFIG_RTL8366RB_PHY=y -CONFIG_RTL8366_SMI=y +# CONFIG_RTL8366RB_PHY is not set CONFIG_SCHED_HRTICK=y # CONFIG_SCHED_INFO is not set # CONFIG_SCSI_DMA is not set diff --git a/target/linux/lantiq/xway/config-default b/target/linux/lantiq/xway/config-default index ae13f80..306fe8f 100644 --- a/target/linux/lantiq/xway/config-default +++ b/target/linux/lantiq/xway/config-default @@ -1,5 +1,5 @@ -CONFIG_ADM6996_PHY=y -CONFIG_AR8216_PHY=y +# CONFIG_ADM6996_PHY is not set +# CONFIG_AR8216_PHY is not set # CONFIG_ARCH_HAS_SG_CHAIN is not set CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y CONFIG_ARCH_MIGHT_HAVE_PC_SERIO=y @@ -23,7 +23,7 @@ CONFIG_HAVE_DEBUG_STACKOVERFLOW=y CONFIG_HAVE_DMA_CONTIGUOUS=y CONFIG_HAVE_SYSCALL_TRACEPOINTS=y CONFIG_HZ_PERIODIC=y -CONFIG_INPUT=y +# CONFIG_INPUT is not set CONFIG_INPUT_EVDEV=y CONFIG_INPUT_POLLDEV=y CONFIG_IRQCHIP=y @@ -33,40 +33,29 @@ CONFIG_LEDS_TRIGGER_HEARTBEAT=y CONFIG_LIBFDT=y CONFIG_LZO_COMPRESS=y CONFIG_LZO_DECOMPRESS=y -CONFIG_MTD_NAND=y -CONFIG_MTD_NAND_ECC=y -CONFIG_MTD_NAND_PLATFORM=y -CONFIG_MTD_NAND_XWAY=y +# CONFIG_MTD_NAND is not set # CONFIG_MTD_PHYSMAP_OF is not set -CONFIG_MTD_SPLIT_UIMAGE_FW=y -CONFIG_MTD_UBI=y -CONFIG_MTD_UBI_BEB_LIMIT=20 -CONFIG_MTD_UBI_BLOCK=y -# CONFIG_MTD_UBI_FASTMAP is not set -# CONFIG_MTD_UBI_GLUEBI is not set -CONFIG_MTD_UBI_WL_THRESHOLD=4096 +# CONFIG_MTD_SPLIT_UIMAGE_FW is not set +# CONFIG_MTD_UBI is not set CONFIG_NLS=y # CONFIG_NO_IOPORT_MAP is not set CONFIG_OF_ADDRESS_PCI=y # CONFIG_RCU_STALL_COMMON is not set CONFIG_RTL8306_PHY=y -CONFIG_RTL8366S_PHY=y -CONFIG_RTL8367B_PHY=y -CONFIG_RTL8367_PHY=y +# CONFIG_RTL8366S_PHY is not set +# CONFIG_RTL8367B_PHY is not set +# CONFIG_RTL8367_PHY is not set CONFIG_SPI=y CONFIG_SPI_LANTIQ=y CONFIG_SPI_MASTER=y CONFIG_SYS_SUPPORTS_MIPS16=y -CONFIG_UBIFS_FS=y -CONFIG_UBIFS_FS_ADVANCED_COMPR=y -CONFIG_UBIFS_FS_LZO=y -# CONFIG_UBIFS_FS_XZ is not set -CONFIG_UBIFS_FS_ZLIB=y -CONFIG_USB=y -CONFIG_USB_COMMON=y +# CONFIG_UBIFS_FS is not set +# CONFIG_USB is not set # CONFIG_USB_EHCI_HCD is not set -CONFIG_USB_SUPPORT=y # CONFIG_USB_UHCI_HCD is not set # CONFIG_XRX200_PHY_FW is not set CONFIG_ZLIB_DEFLATE=y CONFIG_ZLIB_INFLATE=y +# CONFIG_EFI_PARTITION is not set +# CONFIG_MSDOS_PARTITION is not set +# CONFIG_MTD_SPLIT_SQUASHFS_ROOT is not set diff --git a/target/linux/lantiq/xway/target.mk b/target/linux/lantiq/xway/target.mk index b9d4a0f..8c72319 100644 --- a/target/linux/lantiq/xway/target.mk +++ b/target/linux/lantiq/xway/target.mk @@ -1,7 +1,7 @@ ARCH:=mips SUBTARGET:=xway BOARDNAME:=XWAY -FEATURES:=squashfs atm mips16 nand ubifs ramdisk +FEATURES:=squashfs atm mips16 ramdisk CPU_TYPE:=34kc CPU_SUBTYPE:=dsp -- 2.7.4.1.gb6fc189 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From oswald.buddenhagen at gmx.de Wed May 18 03:39:23 2016 From: oswald.buddenhagen at gmx.de (Oswald Buddenhagen) Date: Wed, 18 May 2016 09:39:23 +0200 Subject: [OpenWrt-Devel] [PATCH 1/2] [RFC] lantiq: remove bogus lantiq, open-drain properties Message-ID: <1463557164-19272-1-git-send-email-oswald.buddenhagen@gmx.de> This property makes no sense for inputs. Or maybe it does? the lantiq,output devicetree mapping is undocumented, and consequently its relationship with lantiq,open-drain. So i can't preclude the possibility that there is an unexpected relation ... Signed-off-by: Oswald Buddenhagen --- target/linux/lantiq/dts/ARV4518PWR01.dtsi | 1 - target/linux/lantiq/dts/ARV4520PW.dts | 1 - target/linux/lantiq/dts/ARV4525PW.dts | 1 - target/linux/lantiq/dts/ARV452CQW.dts | 1 - target/linux/lantiq/dts/ARV7510PW22.dts | 1 - target/linux/lantiq/dts/ARV7518PW.dts | 2 -- target/linux/lantiq/dts/ARV7519PW.dts | 1 - target/linux/lantiq/dts/ARV752DPW.dts | 2 -- target/linux/lantiq/dts/ARV8539PW22.dts | 1 - target/linux/lantiq/dts/BTHOMEHUBV2B.dts | 2 -- target/linux/lantiq/dts/BTHOMEHUBV3A.dts | 1 - target/linux/lantiq/dts/DGN1000B.dts | 1 - target/linux/lantiq/dts/DGN3500.dtsi | 1 - target/linux/lantiq/dts/FRITZ7320.dts | 1 - target/linux/lantiq/dts/GR7000.dts | 1 - target/linux/lantiq/dts/P2812HNUFX.dtsi | 1 - target/linux/lantiq/dts/WBMR.dts | 1 - 17 files changed, 20 deletions(-) diff --git a/target/linux/lantiq/dts/ARV4518PWR01.dtsi b/target/linux/lantiq/dts/ARV4518PWR01.dtsi index 4a3eb05..39fdb18 100644 --- a/target/linux/lantiq/dts/ARV4518PWR01.dtsi +++ b/target/linux/lantiq/dts/ARV4518PWR01.dtsi @@ -103,7 +103,6 @@ pci_in { lantiq,groups = "req1", "req2"; lantiq,function = "pci"; - lantiq,open-drain = <1>; lantiq,pull = <2>; lantiq,output = <0>; }; diff --git a/target/linux/lantiq/dts/ARV4520PW.dts b/target/linux/lantiq/dts/ARV4520PW.dts index 299d13c..0320ce4 100644 --- a/target/linux/lantiq/dts/ARV4520PW.dts +++ b/target/linux/lantiq/dts/ARV4520PW.dts @@ -100,7 +100,6 @@ pci_in { lantiq,groups = "req1"; lantiq,function = "pci"; - lantiq,open-drain = <1>; lantiq,pull = <2>; lantiq,output = <0>; }; diff --git a/target/linux/lantiq/dts/ARV4525PW.dts b/target/linux/lantiq/dts/ARV4525PW.dts index 6a7ca62..b7bfdd1 100644 --- a/target/linux/lantiq/dts/ARV4525PW.dts +++ b/target/linux/lantiq/dts/ARV4525PW.dts @@ -89,7 +89,6 @@ pci_in { lantiq,groups = "req1"; lantiq,function = "pci"; - lantiq,open-drain = <1>; lantiq,pull = <2>; lantiq,output = <0>; }; diff --git a/target/linux/lantiq/dts/ARV452CQW.dts b/target/linux/lantiq/dts/ARV452CQW.dts index 57aa864..db89a98 100644 --- a/target/linux/lantiq/dts/ARV452CQW.dts +++ b/target/linux/lantiq/dts/ARV452CQW.dts @@ -105,7 +105,6 @@ pci_in { lantiq,groups = "req1"; lantiq,function = "pci"; - lantiq,open-drain = <1>; lantiq,pull = <2>; lantiq,output = <0>; }; diff --git a/target/linux/lantiq/dts/ARV7510PW22.dts b/target/linux/lantiq/dts/ARV7510PW22.dts index 16b4fb4..cbc9995 100644 --- a/target/linux/lantiq/dts/ARV7510PW22.dts +++ b/target/linux/lantiq/dts/ARV7510PW22.dts @@ -89,7 +89,6 @@ pci_in { lantiq,groups = "req1", "req2"; lantiq,function = "pci"; - lantiq,open-drain = <1>; lantiq,pull = <2>; lantiq,output = <0>; }; diff --git a/target/linux/lantiq/dts/ARV7518PW.dts b/target/linux/lantiq/dts/ARV7518PW.dts index 19a7442..bc9adf8 100644 --- a/target/linux/lantiq/dts/ARV7518PW.dts +++ b/target/linux/lantiq/dts/ARV7518PW.dts @@ -106,7 +106,6 @@ pci_in { lantiq,groups = "req1"; lantiq,function = "pci"; - lantiq,open-drain = <1>; lantiq,pull = <2>; lantiq,output = <0>; }; @@ -129,7 +128,6 @@ lantiq,pins = "io28", "io30"; lantiq,output = <0>; lantiq,pull = <2>; - lantiq,open-drain = <1>; }; }; }; diff --git a/target/linux/lantiq/dts/ARV7519PW.dts b/target/linux/lantiq/dts/ARV7519PW.dts index b917b2d..5d5c3bc 100644 --- a/target/linux/lantiq/dts/ARV7519PW.dts +++ b/target/linux/lantiq/dts/ARV7519PW.dts @@ -86,7 +86,6 @@ pci_in { lantiq,groups = "req1"; lantiq,function = "pci"; - lantiq,open-drain = <1>; lantiq,pull = <2>; lantiq,output = <0>; }; diff --git a/target/linux/lantiq/dts/ARV752DPW.dts b/target/linux/lantiq/dts/ARV752DPW.dts index d4b5767..f104eac 100644 --- a/target/linux/lantiq/dts/ARV752DPW.dts +++ b/target/linux/lantiq/dts/ARV752DPW.dts @@ -103,7 +103,6 @@ pci_in { lantiq,groups = "req2", "req1"; lantiq,function = "pci"; - lantiq,open-drain = <1>; lantiq,pull = <2>; lantiq,output = <0>; }; @@ -126,7 +125,6 @@ lantiq,pins = "io11", "io12", "io13", "io28"; lantiq,output = <0>; lantiq,pull = <2>; - lantiq,open-drain = <1>; }; }; }; diff --git a/target/linux/lantiq/dts/ARV8539PW22.dts b/target/linux/lantiq/dts/ARV8539PW22.dts index 9f9db82..bfb3928 100644 --- a/target/linux/lantiq/dts/ARV8539PW22.dts +++ b/target/linux/lantiq/dts/ARV8539PW22.dts @@ -92,7 +92,6 @@ pci_in { lantiq,groups = "req1"; lantiq,function = "pci"; - lantiq,open-drain = <1>; lantiq,pull = <2>; lantiq,output = <0>; }; diff --git a/target/linux/lantiq/dts/BTHOMEHUBV2B.dts b/target/linux/lantiq/dts/BTHOMEHUBV2B.dts index 0165156..219c584 100644 --- a/target/linux/lantiq/dts/BTHOMEHUBV2B.dts +++ b/target/linux/lantiq/dts/BTHOMEHUBV2B.dts @@ -159,7 +159,6 @@ lantiq,groups = "req1"; lantiq,function = "pci"; lantiq,output = <0>; - lantiq,open-drain = <1>; lantiq,pull = <2>; }; pci_out { @@ -179,7 +178,6 @@ btn_in { lantiq,pins = "io2", "io15", "io22"; lantiq,output = <0>; - lantiq,open-drain = <1>; lantiq,pull = <2>; }; }; diff --git a/target/linux/lantiq/dts/BTHOMEHUBV3A.dts b/target/linux/lantiq/dts/BTHOMEHUBV3A.dts index 595668f..61746af 100644 --- a/target/linux/lantiq/dts/BTHOMEHUBV3A.dts +++ b/target/linux/lantiq/dts/BTHOMEHUBV3A.dts @@ -119,7 +119,6 @@ lantiq,groups = "req1"; lantiq,function = "pci"; lantiq,output = <0>; - lantiq,open-drain = <1>; lantiq,pull = <2>; }; pci_out { diff --git a/target/linux/lantiq/dts/DGN1000B.dts b/target/linux/lantiq/dts/DGN1000B.dts index a011c71..2e8e7ce 100644 --- a/target/linux/lantiq/dts/DGN1000B.dts +++ b/target/linux/lantiq/dts/DGN1000B.dts @@ -35,7 +35,6 @@ keys_in { lantiq,pins = "io0",/* "io25", */"io29"; lantiq,pull = <2>; - lantiq,open-drain = <1>; }; }; pins_spi_default: pins_spi_default { diff --git a/target/linux/lantiq/dts/DGN3500.dtsi b/target/linux/lantiq/dts/DGN3500.dtsi index 89a7737..645afc6 100644 --- a/target/linux/lantiq/dts/DGN3500.dtsi +++ b/target/linux/lantiq/dts/DGN3500.dtsi @@ -37,7 +37,6 @@ pci-in { lantiq,groups = "req1"; lantiq,output = <0>; - lantiq,open-drain = <1>; lantiq,pull = <2>; }; pci-out { diff --git a/target/linux/lantiq/dts/FRITZ7320.dts b/target/linux/lantiq/dts/FRITZ7320.dts index 04581c5..97e5fbc 100644 --- a/target/linux/lantiq/dts/FRITZ7320.dts +++ b/target/linux/lantiq/dts/FRITZ7320.dts @@ -75,7 +75,6 @@ pci-in { lantiq,groups = "req1", "req2", "req3", "req4"; lantiq,output = <0>; - lantiq,open-drain = <1>; lantiq,pull = <2>; }; pci-out { diff --git a/target/linux/lantiq/dts/GR7000.dts b/target/linux/lantiq/dts/GR7000.dts index 220eb47..4b57c0e 100644 --- a/target/linux/lantiq/dts/GR7000.dts +++ b/target/linux/lantiq/dts/GR7000.dts @@ -69,7 +69,6 @@ pci-in { lantiq,groups = "req1"; lantiq,output = <0>; - lantiq,open-drain = <1>; lantiq,pull = <2>; }; pci-out { diff --git a/target/linux/lantiq/dts/P2812HNUFX.dtsi b/target/linux/lantiq/dts/P2812HNUFX.dtsi index e51a2f5..8b9add2 100644 --- a/target/linux/lantiq/dts/P2812HNUFX.dtsi +++ b/target/linux/lantiq/dts/P2812HNUFX.dtsi @@ -74,7 +74,6 @@ lantiq,groups = "req1"; lantiq,function = "pci"; lantiq,output = <0>; - lantiq,open-drain = <1>; lantiq,pull = <2>; }; pci-out { diff --git a/target/linux/lantiq/dts/WBMR.dts b/target/linux/lantiq/dts/WBMR.dts index 5b4740c..f52d407 100644 --- a/target/linux/lantiq/dts/WBMR.dts +++ b/target/linux/lantiq/dts/WBMR.dts @@ -83,7 +83,6 @@ pci-in { lantiq,groups = "req1"; lantiq,output = <0>; - lantiq,open-drain = <1>; lantiq,pull = <2>; }; pci-out { -- 2.7.4.1.gb6fc189 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From oswald.buddenhagen at gmx.de Wed May 18 03:39:24 2016 From: oswald.buddenhagen at gmx.de (Oswald Buddenhagen) Date: Wed, 18 May 2016 09:39:24 +0200 Subject: [OpenWrt-Devel] [PATCH 2/2] [RFC] lantiq: explicitly configure some pins as outputs In-Reply-To: <1463557164-19272-1-git-send-email-oswald.buddenhagen@gmx.de> References: <1463557164-19272-1-git-send-email-oswald.buddenhagen@gmx.de> Message-ID: <1463557164-19272-2-git-send-email-oswald.buddenhagen@gmx.de> They clearly are meant to be, and the bootloader (presumably) sets them up accordingly, but it's nicer to state it explicitly in the DT. Entirely untested. Signed-off-by: Oswald Buddenhagen --- target/linux/lantiq/dts/ARV4520PW.dts | 1 + target/linux/lantiq/dts/BTHOMEHUBV2B.dts | 1 + target/linux/lantiq/dts/BTHOMEHUBV3A.dts | 1 + target/linux/lantiq/dts/BTHOMEHUBV5A.dts | 1 + target/linux/lantiq/dts/EASY50712.dts | 1 + target/linux/lantiq/dts/EASY50810.dts | 1 + 6 files changed, 6 insertions(+) diff --git a/target/linux/lantiq/dts/ARV4520PW.dts b/target/linux/lantiq/dts/ARV4520PW.dts index 0320ce4..3672601 100644 --- a/target/linux/lantiq/dts/ARV4520PW.dts +++ b/target/linux/lantiq/dts/ARV4520PW.dts @@ -111,6 +111,7 @@ pci_rst { lantiq,pins = "io21"; lantiq,open-drain = <0>; + lantiq,output = <1>; lantiq,pull = <0>; }; }; diff --git a/target/linux/lantiq/dts/BTHOMEHUBV2B.dts b/target/linux/lantiq/dts/BTHOMEHUBV2B.dts index 219c584..46f197c 100644 --- a/target/linux/lantiq/dts/BTHOMEHUBV2B.dts +++ b/target/linux/lantiq/dts/BTHOMEHUBV2B.dts @@ -148,6 +148,7 @@ nand_cs1 { lantiq,groups = "nand cs1"; lantiq,function = "ebu"; + lantiq,output = <1>; lantiq,open-drain = <0>; lantiq,pull = <0>; }; diff --git a/target/linux/lantiq/dts/BTHOMEHUBV3A.dts b/target/linux/lantiq/dts/BTHOMEHUBV3A.dts index 61746af..190d949 100644 --- a/target/linux/lantiq/dts/BTHOMEHUBV3A.dts +++ b/target/linux/lantiq/dts/BTHOMEHUBV3A.dts @@ -111,6 +111,7 @@ nand_cs1 { lantiq,groups = "nand cs1"; lantiq,function = "ebu"; + lantiq,output = <1>; lantiq,open-drain = <0>; lantiq,pull = <0>; }; diff --git a/target/linux/lantiq/dts/BTHOMEHUBV5A.dts b/target/linux/lantiq/dts/BTHOMEHUBV5A.dts index e62a18d..df0b59e 100644 --- a/target/linux/lantiq/dts/BTHOMEHUBV5A.dts +++ b/target/linux/lantiq/dts/BTHOMEHUBV5A.dts @@ -104,6 +104,7 @@ lantiq,function = "ebu"; lantiq,open-drain = <0>; lantiq,pull = <0>; + lantiq,output = <1>; }; }; }; diff --git a/target/linux/lantiq/dts/EASY50712.dts b/target/linux/lantiq/dts/EASY50712.dts index 39ba1f7..9df3da0 100644 --- a/target/linux/lantiq/dts/EASY50712.dts +++ b/target/linux/lantiq/dts/EASY50712.dts @@ -80,6 +80,7 @@ }; conf_out { lantiq,pins = "io4", "io5", "io6"; /* stp */ + lantiq,output = <1>; lantiq,open-drain; lantiq,pull = <0>; }; diff --git a/target/linux/lantiq/dts/EASY50810.dts b/target/linux/lantiq/dts/EASY50810.dts index 70d2ff5..b155118 100644 --- a/target/linux/lantiq/dts/EASY50810.dts +++ b/target/linux/lantiq/dts/EASY50810.dts @@ -80,6 +80,7 @@ }; conf_out { lantiq,pins = "io4", "io5", "io6"; /* stp */ + lantiq,output = <1>; lantiq,open-drain; lantiq,pull = <0>; }; -- 2.7.4.1.gb6fc189 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From oswald.buddenhagen at gmx.de Wed May 18 03:40:04 2016 From: oswald.buddenhagen at gmx.de (Oswald Buddenhagen) Date: Wed, 18 May 2016 09:40:04 +0200 Subject: [OpenWrt-Devel] [PATCH 1/2] lantiq: remove duplicated req-mask property Message-ID: <1463557205-19346-1-git-send-email-oswald.buddenhagen@gmx.de> Signed-off-by: Oswald Buddenhagen --- target/linux/lantiq/dts/FRITZ7320.dts | 1 - 1 file changed, 1 deletion(-) diff --git a/target/linux/lantiq/dts/FRITZ7320.dts b/target/linux/lantiq/dts/FRITZ7320.dts index 475da7a..04581c5 100644 --- a/target/linux/lantiq/dts/FRITZ7320.dts +++ b/target/linux/lantiq/dts/FRITZ7320.dts @@ -97,7 +97,6 @@ pci at E105400 { status = "okay"; - req-mask = <0xf>; lantiq,bus-clock = <33333333>; interrupt-map-mask = <0xf800 0x0 0x0 0x7>; interrupt-map = <0x7000 0 0 1 &icu0 30 1>; -- 2.7.4.1.gb6fc189 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From oswald.buddenhagen at gmx.de Wed May 18 03:40:05 2016 From: oswald.buddenhagen at gmx.de (Oswald Buddenhagen) Date: Wed, 18 May 2016 09:40:05 +0200 Subject: [OpenWrt-Devel] [PATCH 2/2] lantiq: remove references to bogus lantiq, internal-clock In-Reply-To: <1463557205-19346-1-git-send-email-oswald.buddenhagen@gmx.de> References: <1463557205-19346-1-git-send-email-oswald.buddenhagen@gmx.de> Message-ID: <1463557205-19346-2-git-send-email-oswald.buddenhagen@gmx.de> There is no such property. It was probably meant as the counterpart to lantiq,external-clock, but the internal clock always exists anyway. Signed-off-by: Oswald Buddenhagen --- target/linux/lantiq/dts/ARV4518PWR01.dts | 8 -------- target/linux/lantiq/dts/GIGASX76X.dts | 1 - 2 files changed, 9 deletions(-) diff --git a/target/linux/lantiq/dts/ARV4518PWR01.dts b/target/linux/lantiq/dts/ARV4518PWR01.dts index 7dfdb6f..c8e76a7 100644 --- a/target/linux/lantiq/dts/ARV4518PWR01.dts +++ b/target/linux/lantiq/dts/ARV4518PWR01.dts @@ -4,12 +4,4 @@ / { model = "ARV4518PWR01 - SMC7908A-ISP"; - - fpi at 10000000 { - - pci at E105400 { - lantiq,internal-clock; - }; - - }; }; diff --git a/target/linux/lantiq/dts/GIGASX76X.dts b/target/linux/lantiq/dts/GIGASX76X.dts index a43e4d4..cdf8e4a 100644 --- a/target/linux/lantiq/dts/GIGASX76X.dts +++ b/target/linux/lantiq/dts/GIGASX76X.dts @@ -89,7 +89,6 @@ pci at E105400 { status = "okay"; - lantiq,internal-clock; gpio-reset = <&gpio 21 0>; req-mask = <0x1>; }; -- 2.7.4.1.gb6fc189 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From ben.mulvihill at gmail.com Wed May 18 03:54:43 2016 From: ben.mulvihill at gmail.com (Ben Mulvihill) Date: Wed, 18 May 2016 09:54:43 +0200 Subject: [OpenWrt-Devel] [PATCH] [RFC] lantiq: disable a bunch of features not applicable to my box In-Reply-To: <1463557156-19220-1-git-send-email-oswald.buddenhagen@gmx.de> References: <1463557156-19220-1-git-send-email-oswald.buddenhagen@gmx.de> Message-ID: <1463558083.13489.27.camel@merveille.lan> Hi Oswald, On Wed, 2016-05-18 at 09:39 +0200, Oswald Buddenhagen wrote: > - NAND/UBI support is completely irrelevant for my box, and for > lantiq/Danube in general (IIRC). It appears to me that it would make > sense to split it off from the xway target. NAND/UBI is required on BTHOMEHUB2B (xway danube) and BTHOMEHUB3A (xway ar9). Ben _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From martin.blumenstingl at googlemail.com Wed May 18 05:44:39 2016 From: martin.blumenstingl at googlemail.com (Martin Blumenstingl) Date: Wed, 18 May 2016 11:44:39 +0200 Subject: [OpenWrt-Devel] [PATCH] [RFC] lantiq: disable a bunch of features not applicable to my box In-Reply-To: <1463558083.13489.27.camel@merveille.lan> References: <1463557156-19220-1-git-send-email-oswald.buddenhagen@gmx.de> <1463558083.13489.27.camel@merveille.lan> Message-ID: On Wed, May 18, 2016 at 9:54 AM, Ben Mulvihill wrote: > On Wed, 2016-05-18 at 09:39 +0200, Oswald Buddenhagen wrote: >> - NAND/UBI support is completely irrelevant for my box, and for >> lantiq/Danube in general (IIRC). It appears to me that it would make >> sense to split it off from the xway target. > > NAND/UBI is required on BTHOMEHUB2B (xway danube) and > BTHOMEHUB3A (xway ar9). I think this patch is more of a "how to reduce the image size for devices with limited space" - not an actual patch. Some other brnboot based boards are running into the same problem. The solution for these was to switch to u-boot - but changing the bootloader is always dangerous. _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From dev at kresin.me Wed May 18 07:19:59 2016 From: dev at kresin.me (Mathias Kresin) Date: Wed, 18 May 2016 13:19:59 +0200 Subject: [OpenWrt-Devel] [PATCH] lantiq: add support for ARV7506PW11 (Alice/O2 IAD 4421) In-Reply-To: <1463557077-19088-1-git-send-email-oswald.buddenhagen@gmx.de> References: <1463557077-19088-1-git-send-email-oswald.buddenhagen@gmx.de> Message-ID: I got the same device last Weekend and planned to add support for this device during the next days. Glad to see that most of the work is already done. Find my remarks in-line. 2016-05-18 9:37 GMT+02:00 Oswald Buddenhagen : > Ethernet, WiFi, ADSL2+, and LEDS are fully functional. > > The RFkill switch doesn't appear to be correctly configured. > > Supporting the two TAE ports and SIP gateway was not attempted. > > The firmware image needs to be kept below ~3.6MiB due to brnboot's dual > image magic. This is just enough for the above configuration plus > dropbear. Luci and other non-critical packages must be installed into > the jffs2 once the device has booted. > > U-boot support was not attempted. I'll give it a try. Lately, I worked a lot with u-boot, so I'm confident that it shouldn't be that problem. But I need to identify the boot_sel pins first. I have looked at it only briefly and was only able to identify one of the boot_sel pins: R77. Unfortunately this pin alone doesn't switch the SoC to UART mode. Did you found already the other pins? > Signed-off-by: Oswald Buddenhagen > --- > .../linux/lantiq/base-files/etc/board.d/02_network | 8 + > .../etc/hotplug.d/firmware/10-rt2x00-eeprom | 2 +- > target/linux/lantiq/dts/ARV7506PW11.dts | 213 +++++++++++++++++++++ > target/linux/lantiq/image/Makefile | 2 + > target/linux/lantiq/xway/profiles/arv.mk | 12 ++ > 5 files changed, 236 insertions(+), 1 deletion(-) > create mode 100644 target/linux/lantiq/dts/ARV7506PW11.dts > > diff --git a/target/linux/lantiq/base-files/etc/board.d/02_network b/target/linux/lantiq/base-files/etc/board.d/02_network > index b27b802..1f06c26 100755 > --- a/target/linux/lantiq/base-files/etc/board.d/02_network > +++ b/target/linux/lantiq/base-files/etc/board.d/02_network > @@ -39,6 +39,14 @@ ACMP252|GIGASX76X) > "4:lan:1" "3:lan:2" "2:lan:3" "1:lan:4" "5t at eth0" > ;; > > +# rtl8306g > +ARV7506PW11) > + lan_mac=$(mtd_get_mac_binary board_config 22) > + wan_mac=$(macaddr_add "$lan_mac" 1) > + ucidef_add_switch "switch0" \ > + "4:lan:1" "3:lan:2" "2:lan:3" "1:lan:4" "5t at eth0" > + ;; > + > # ar8316 > ARV4519PW|ARV7510PW22|ARV7518PW|ARV752DPW22|ARV8539PW22) > ucidef_add_switch "switch0" \ > diff --git a/target/linux/lantiq/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom b/target/linux/lantiq/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom > index 5f1cb00..da10797 100644 > --- a/target/linux/lantiq/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom > +++ b/target/linux/lantiq/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom > @@ -35,7 +35,7 @@ case "$FIRMWARE" in > "RT2860.eeprom" ) > local board=$(lantiq_board_name) > case $board in > - ARV7510PW22|ARV7519PW|ARV752DPW|ARV752DPW22|VGV7519) > + ARV7506PW11|ARV7510PW22|ARV7519PW|ARV752DPW|ARV752DPW22|VGV7519) > rt2x00_eeprom_extract "board_config" 520 256 1 > ;; > ARV7525PW) > diff --git a/target/linux/lantiq/dts/ARV7506PW11.dts b/target/linux/lantiq/dts/ARV7506PW11.dts > new file mode 100644 > index 0000000..bb9ffd4 > --- /dev/null > +++ b/target/linux/lantiq/dts/ARV7506PW11.dts > @@ -0,0 +1,213 @@ > +/dts-v1/; > + > +/include/ "danube.dtsi" > + > +/ { > + model = "ARV7506PW11 - Alice/O2 IAD 4421"; > + > + chosen { > + leds { > + boot = &power; > + failsafe = &power_red; > + running = &power; > + > + dsl = &dsl; > + internet = &internet; > + wifi = &wlan; > + }; > + }; > + > + memory at 0 { > + reg = <0x0 0x4000000>; > + }; > + > + sram at 1F000000 { > + vmmc at 107000 { > + status = "okay"; > + gpios = <&gpiomm 1 0>; > + }; > + }; > + > + fpi at 10000000 { > + localbus at 0 { > + nor-boot at 0 { > + compatible = "lantiq,nor"; > + bank-width = <2>; > + reg = <0 0x0 0x800000>; > + > + partitions { > + compatible = "fixed-partitions"; > + #address-cells = <1>; > + #size-cells = <1>; > + > + partition at 0 { > + label = "brnboot"; > + reg = <0x00000 0x20000>; > + read-only; > + }; > + > + partition at 20000 { > + label = "stuff"; > + reg = <0x20000 0x70000>; > + }; Please add the real layout here and use proper names for the partitions! > + > + partition at 90000 { > + label = "rootfs_data"; > + reg = <0x90000 0x3B0000>; > + }; > + > + partition at 440000 { > + label = "firmware"; > + reg = <0x440000 0x3B0000>; > + }; Assuming you're using the brnboot recovery to flash the firmware, this wont work. brnboot recovery writes alternating to both partitions and stores the current active one in the Primary Setting partition (0x80000). Which could results in a situation that the kernel is stored (and booted) at 0x90000 but the userland + kmods are loaded from 0x440000. This could lead to a lot of errors and your additional flash space for volatile data isn't available as well. My patch to use the current active partition as firmware partition was merged lately to OpenWrt. Have a look at the VGV7510KW22BRN.dts for reference. As you already noticed, OpenWrt isn't really usable on devices with a firmware partition <= 4MB. I would even say, that such are not longer supported. But that is something the core devs need to decide. Anyway, I would suggest to focus on u-boot + a custom partition layout to have enough space for luci and so on. Mathias _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From nbd at nbd.name Wed May 18 08:57:57 2016 From: nbd at nbd.name (Felix Fietkau) Date: Wed, 18 May 2016 14:57:57 +0200 Subject: [OpenWrt-Devel] [LEDE-DEV] [PATCH] include/kernel: Do not strip kernel's Elf In-Reply-To: <1463409763-11832-1-git-send-email-abrodkin@synopsys.com> References: <1463409763-11832-1-git-send-email-abrodkin@synopsys.com> Message-ID: <3f8ef972-b2f4-84b3-af9c-f1bb14840248@nbd.name> On 2016-05-16 16:42, Alexey Brodkin wrote: > If an image gets built as an Elf there's a chance > it will be used by developers for debugging purposes. > In that case it's very helpful to keep debugging info > in that image. > > I would think that most OWRT-powered devices in production > will use some form of binary image for booting so Elf > flavours could be left a bit bulkier with more debug info > inside. > > Signed-off-by: Alexey Brodkin You can get the bulky one directly from the kernel source directory, and there is definitely some value in having stripped ELF binaries as well for devices that can load them. - Felix _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From Alexey.Brodkin at synopsys.com Wed May 18 09:06:42 2016 From: Alexey.Brodkin at synopsys.com (Alexey Brodkin) Date: Wed, 18 May 2016 13:06:42 +0000 Subject: [OpenWrt-Devel] [LEDE-DEV] [PATCH] include/kernel: Do not strip kernel's Elf In-Reply-To: <3f8ef972-b2f4-84b3-af9c-f1bb14840248@nbd.name> References: <1463409763-11832-1-git-send-email-abrodkin@synopsys.com> <3f8ef972-b2f4-84b3-af9c-f1bb14840248@nbd.name> Message-ID: <1463576776.3105.23.camel@synopsys.com> Hi Felix, On Wed, 2016-05-18 at 14:57 +0200, Felix Fietkau wrote: > On 2016-05-16 16:42, Alexey Brodkin wrote: > > > > If an image gets built as an Elf there's a chance > > it will be used by developers for debugging purposes. > > In that case it's very helpful to keep debugging info > > in that image. > > > > I would think that most OWRT-powered devices in production > > will use some form of binary image for booting so Elf > > flavours could be left a bit bulkier with more debug info > > inside. > > > > Signed-off-by: Alexey Brodkin > You can get the bulky one directly from the kernel source directory, and > there is definitely some value in having stripped ELF binaries as well > for devices that can load them. Well indeed in kernel's source directory we have an unstripped elf. But what happens at least in case of ARC we build only one kernel's elf and then as a post-built step we patch in .dtb for all boards we build OWRT. In other words in "bin/arc770-uClibc" folder I have: ?1)?openwrt-arc770-generic-axs101-initramfs.elf ?2)?openwrt-arc770-generic-nsim_700-initramfs.elf Both are stripped but work as they are on the corresponding boards. In "build_dir/target-arc_arc700_uClibc-1.0.9/linux-arc770_generic/linux-4.4.7/" I have perfectly unstripped vmlinux but it won't work on either board because of missing device tree blob. That means if one wants to get image for a board X with debug symbols he or she will need to do manual patching in of .dtb. Which is not the most convenient thing ever. -Alexey _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From nbd at nbd.name Wed May 18 09:49:46 2016 From: nbd at nbd.name (Felix Fietkau) Date: Wed, 18 May 2016 15:49:46 +0200 Subject: [OpenWrt-Devel] [LEDE-DEV] [PATCH] include/kernel: Do not strip kernel's Elf In-Reply-To: <1463576776.3105.23.camel@synopsys.com> References: <1463409763-11832-1-git-send-email-abrodkin@synopsys.com> <3f8ef972-b2f4-84b3-af9c-f1bb14840248@nbd.name> <1463576776.3105.23.camel@synopsys.com> Message-ID: <3dadfb5b-ba1c-9554-5ae4-ac0891dafd9b@nbd.name> On 2016-05-18 15:06, Alexey Brodkin wrote: > Hi Felix, > > On Wed, 2016-05-18 at 14:57 +0200, Felix Fietkau wrote: >> On 2016-05-16 16:42, Alexey Brodkin wrote: >> > >> > If an image gets built as an Elf there's a chance >> > it will be used by developers for debugging purposes. >> > In that case it's very helpful to keep debugging info >> > in that image. >> > >> > I would think that most OWRT-powered devices in production >> > will use some form of binary image for booting so Elf >> > flavours could be left a bit bulkier with more debug info >> > inside. >> > >> > Signed-off-by: Alexey Brodkin >> You can get the bulky one directly from the kernel source directory, and >> there is definitely some value in having stripped ELF binaries as well >> for devices that can load them. > > Well indeed in kernel's source directory we have an unstripped elf. > But what happens at least in case of ARC we build only one kernel's elf > and then as a post-built step we patch in .dtb for all boards we build OWRT. > > In other words in "bin/arc770-uClibc" folder I have: > 1) openwrt-arc770-generic-axs101-initramfs.elf > 2) openwrt-arc770-generic-nsim_700-initramfs.elf > > Both are stripped but work as they are on the corresponding boards. > > In "build_dir/target-arc_arc700_uClibc-1.0.9/linux-arc770_generic/linux-4.4.7/" > I have perfectly unstripped vmlinux but it won't work on either board because of > missing device tree blob. > > That means if one wants to get image for a board X with debug symbols he or she > will need to do manual patching in of .dtb. Which is not the most convenient thing ever. It's a lot simpler than that: You can boot the stripped and patched elf image from bin/ and use the vmlinux from the kernel source for the debugger afterwards. They are fully compatible. - Felix _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From Alexey.Brodkin at synopsys.com Wed May 18 09:59:16 2016 From: Alexey.Brodkin at synopsys.com (Alexey Brodkin) Date: Wed, 18 May 2016 13:59:16 +0000 Subject: [OpenWrt-Devel] [LEDE-DEV] [PATCH] include/kernel: Do not strip kernel's Elf In-Reply-To: <3dadfb5b-ba1c-9554-5ae4-ac0891dafd9b@nbd.name> References: <1463409763-11832-1-git-send-email-abrodkin@synopsys.com> <3f8ef972-b2f4-84b3-af9c-f1bb14840248@nbd.name> <1463576776.3105.23.camel@synopsys.com> <3dadfb5b-ba1c-9554-5ae4-ac0891dafd9b@nbd.name> Message-ID: <1463579929.3105.30.camel@synopsys.com> Hi Felix, On Wed, 2016-05-18 at 15:49 +0200, Felix Fietkau wrote: > On 2016-05-18 15:06, Alexey Brodkin wrote: > > > > Hi Felix, > > > > On Wed, 2016-05-18 at 14:57 +0200, Felix Fietkau wrote: > > > > > > On 2016-05-16 16:42, Alexey Brodkin wrote: > > > > > > > > > > > > If an image gets built as an Elf there's a chance > > > > it will be used by developers for debugging purposes. > > > > In that case it's very helpful to keep debugging info > > > > in that image. > > > > > > > > I would think that most OWRT-powered devices in production > > > > will use some form of binary image for booting so Elf > > > > flavours could be left a bit bulkier with more debug info > > > > inside. > > > > > > > > Signed-off-by: Alexey Brodkin > > > You can get the bulky one directly from the kernel source directory, and > > > there is definitely some value in having stripped ELF binaries as well > > > for devices that can load them. > > Well indeed in kernel's source directory we have an unstripped elf. > > But what happens at least in case of ARC we build only one kernel's elf > > and then as a post-built step we patch in .dtb for all boards we build OWRT. > > > > In other words in "bin/arc770-uClibc" folder I have: > > ?1) openwrt-arc770-generic-axs101-initramfs.elf > > ?2) openwrt-arc770-generic-nsim_700-initramfs.elf > > > > Both are stripped but work as they are on the corresponding boards. > > > > In "build_dir/target-arc_arc700_uClibc-1.0.9/linux-arc770_generic/linux-4.4.7/" > > I have perfectly unstripped vmlinux but it won't work on either board because of > > missing device tree blob. > > > > That means if one wants to get image for a board X with debug symbols he or she > > will need to do manual patching in of .dtb. Which is not the most convenient thing ever. > It's a lot simpler than that: You can boot the stripped and patched elf > image from bin/ and use the vmlinux from the kernel source for the > debugger afterwards. They are fully compatible. Good point. So indeed if we do want stuff in "bin/" folder to be stripped that seems to be the simplest approach. But what if we with addition of another config option: ?a) toggle kernel's?CONFIG_DEBUG_INFO ?b) use "--strip-unneeded" instead of currently used "-S" (which is an alias to "--strip-all"). -Alexey _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From nbd at nbd.name Wed May 18 10:03:01 2016 From: nbd at nbd.name (Felix Fietkau) Date: Wed, 18 May 2016 16:03:01 +0200 Subject: [OpenWrt-Devel] [LEDE-DEV] [PATCH] include/kernel: Do not strip kernel's Elf In-Reply-To: <1463579929.3105.30.camel@synopsys.com> References: <1463409763-11832-1-git-send-email-abrodkin@synopsys.com> <3f8ef972-b2f4-84b3-af9c-f1bb14840248@nbd.name> <1463576776.3105.23.camel@synopsys.com> <3dadfb5b-ba1c-9554-5ae4-ac0891dafd9b@nbd.name> <1463579929.3105.30.camel@synopsys.com> Message-ID: On 2016-05-18 15:59, Alexey Brodkin wrote: > Hi Felix, > > On Wed, 2016-05-18 at 15:49 +0200, Felix Fietkau wrote: >> On 2016-05-18 15:06, Alexey Brodkin wrote: >> > >> > Hi Felix, >> > >> > On Wed, 2016-05-18 at 14:57 +0200, Felix Fietkau wrote: >> > > >> > > On 2016-05-16 16:42, Alexey Brodkin wrote: >> > > > >> > > > >> > > > If an image gets built as an Elf there's a chance >> > > > it will be used by developers for debugging purposes. >> > > > In that case it's very helpful to keep debugging info >> > > > in that image. >> > > > >> > > > I would think that most OWRT-powered devices in production >> > > > will use some form of binary image for booting so Elf >> > > > flavours could be left a bit bulkier with more debug info >> > > > inside. >> > > > >> > > > Signed-off-by: Alexey Brodkin >> > > You can get the bulky one directly from the kernel source directory, and >> > > there is definitely some value in having stripped ELF binaries as well >> > > for devices that can load them. >> > Well indeed in kernel's source directory we have an unstripped elf. >> > But what happens at least in case of ARC we build only one kernel's elf >> > and then as a post-built step we patch in .dtb for all boards we build OWRT. >> > >> > In other words in "bin/arc770-uClibc" folder I have: >> > 1) openwrt-arc770-generic-axs101-initramfs.elf >> > 2) openwrt-arc770-generic-nsim_700-initramfs.elf >> > >> > Both are stripped but work as they are on the corresponding boards. >> > >> > In "build_dir/target-arc_arc700_uClibc-1.0.9/linux-arc770_generic/linux-4.4.7/" >> > I have perfectly unstripped vmlinux but it won't work on either board because of >> > missing device tree blob. >> > >> > That means if one wants to get image for a board X with debug symbols he or she >> > will need to do manual patching in of .dtb. Which is not the most convenient thing ever. >> It's a lot simpler than that: You can boot the stripped and patched elf >> image from bin/ and use the vmlinux from the kernel source for the >> debugger afterwards. They are fully compatible. > > Good point. So indeed if we do want stuff in "bin/" folder to be stripped > that seems to be the simplest approach. > > But what if we with addition of another config option: > a) toggle kernel's CONFIG_DEBUG_INFO There's a config option for that already, and it's enabled by default. > b) use "--strip-unneeded" instead of currently used "-S" (which is an alias to "--strip-all"). Why? - Felix _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From lazar at onion.io Wed May 18 11:09:26 2016 From: lazar at onion.io (Lazar Demin) Date: Wed, 18 May 2016 11:09:26 -0400 Subject: [OpenWrt-Devel] [PATCH Request][rpcd] file: add reply to write function Message-ID: This patch adds a reply to the file write ubus call: { "code": 0, "bytes": 9 } Where code is the return code of the operation and bytes is the number of bytes written. Getting a response is helpful since it lets the user know if the write operation was successful, knowing the number of bytes written allows for further error checking. Can this patch be merged into the rpcd repo? Index: rpcd/file.c =================================================================== --- rpcd.orig/file.c 2016-05-17 22:07:03.679363210 +0000 +++ rpcd/file.c 2016-05-17 22:08:15.627440178 +0000 @@ -315,6 +315,12 @@ close(fd); sync(); + blob_buf_init(&buf, 0); + blobmsg_add_u32 (&buf, "code", rv); + blobmsg_add_u32 (&buf, "bytes", (int)data_len); + ubus_send_reply (ctx, req, buf.head); + blob_buf_free(&buf); + if (rv) return rpc_errno_status(); -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From andreas.schlager at sbg.at Wed May 18 15:58:25 2016 From: andreas.schlager at sbg.at (Andreas Schlager) Date: Wed, 18 May 2016 21:58:25 +0200 Subject: [OpenWrt-Devel] Linksys E1700 firmware upload throws "incorrect Firmware" Message-ID: <573CC961.4090503@sbg.at> Dear list members, I'm coming to you with an installation problem on my brand new Linksys E1700 devices, but I think this is the right forum for this. Also because the WIKI entries for the E1700 router tells to report a working device - which unfortunately is not the case... I tried it with uploading the OpenWRT firmware via the origina Linksys Web-Interface, but after 15% it states "Incorrect Firmware". Only an OK button, no ignore or something else. Then I fiddled around with tftp/tftpd, but it seems that this device doesn't send tftp requests when booting, nor when reset-button is pressed. Also an upload via tftp to the device failed. The device still is useable, the stock firmware works. Additionally I tried to upload the original Linksys FW, what worked. This is the image I tried: https://downloads.openwrt.org/snapshots/trunk/ramips/mt7620/openwrt-ramips-mt7620-e1700-squashfs-factory.bin Any ideas highly appreciated.... Many thanks in advance! -Andreas. -- --------------------------------------------------------- "Sed quis custodiet ipsos custodes?" (Wer, au?er den W?chtern selbst, wacht ?ber die W?chter?) --Juvenal. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From oswald.buddenhagen at gmx.de Wed May 18 17:00:09 2016 From: oswald.buddenhagen at gmx.de (Oswald Buddenhagen) Date: Wed, 18 May 2016 23:00:09 +0200 Subject: [OpenWrt-Devel] [PATCH] lantiq: add support for ARV7506PW11 (Alice/O2 IAD 4421) In-Reply-To: References: <1463557077-19088-1-git-send-email-oswald.buddenhagen@gmx.de> Message-ID: <20160518210009.GA22531@ugly.lan> On Wed, May 18, 2016 at 01:19:59PM +0200, Mathias Kresin wrote: > But I need to identify the boot_sel pins first. I have looked at it > only briefly and was only able to identify one of the boot_sel pins: > R77. Unfortunately this pin alone doesn't switch the SoC to UART mode. > Did you found already the other pins? > no, i didn't bother with analyzing the hardware beyond soft-probing the gpios to find some led and button pins. the dts is a copy&paste job from the wiki (which in turn is "derived" from another dts), with a lot of studying and trial and error to get the bogus parts out of it, and some polishing and adjustments to recent changes. you probably noticed that the bootloader is able to dump the dram registers, which sounds like a nice perk. > > + partition at 20000 { > > + label = "stuff"; > > + reg = <0x20000 0x70000>; > > + }; > > Please add the real layout here and use proper names for the partitions! > well, i can do that, but the partitions are entirely meaningless in the used setup. > > + > > + partition at 90000 { > > + label = "rootfs_data"; > > + reg = <0x90000 0x3B0000>; > > + }; > > + > > + partition at 440000 { > > + label = "firmware"; > > + reg = <0x440000 0x3B0000>; > > + }; > > Assuming you're using the brnboot recovery to flash the firmware, this > wont work. brnboot recovery writes alternating to both partitions and > stores the current active one in the Primary Setting partition > (0x80000). > yes. i always first entered the bootloader console, set the active partition to 0 (so it would overwrite 1), and only then booted the recovery firmware. i also had to disable the partition splitter which would use the few kilobytes behind the image to create rootfs_data. not a particularly smart setup in retrospect, but that's what the wiki page maneuvered me into, and i didn't want to invest yet more time in figuring out alternatives. > My patch to use the current active partition as firmware partition > was merged lately to OpenWrt. > i know, that's what i mentioned in the other patch. > Have a look at the VGV7510KW22BRN.dts for reference. > i'll do that if you don't beat me to it (which you can easily do if you plan to seriously work on this - beyond email, this is a limited weekend project for me). i think i also know why rfkill doesn't work: i forgot to change the keycode when i decided to switch the key's usage from wps to rfkill. (facepalm) _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From luka.perkov at sartura.hr Wed May 18 19:21:39 2016 From: luka.perkov at sartura.hr (Luka Perkov) Date: Wed, 18 May 2016 23:21:39 +0000 Subject: [OpenWrt-Devel] rocket cwmp - open tr-069 client for embedded platforms Message-ID: <01000154c62cb5a0-55ef2ffa-b597-47ad-85c0-57e082ca4f63-000000@email.amazonses.com> Hi all! prpl Foundation has made the invitation to propose OpenWrt enhancement ideas which may end up funded by the same organization [1]. With this email I'm offering to prpl Foundation to fund Rocket CWMP project - which is the client implementation of CWMP / TR-069 protocol. Since this is a good opportunity to further extend OpenWrt functionality I'm adding several other mailing lists in CC and hope to initiate discussions regarding this proposal and project. CWMP (TR-069) [2] has a very important role both for ISP and for the entire ecosystem with manufacturers included. The standard form of CWMP was primarily developed for a number of Internet access devices, such as modems, set-top boxes, VolP phones and routers. TR-069 standardizes the wide area network (WAN) management of CWMP devices and gives Internet Service Providers a framework and a common language to remotely provision and manage these devices regardless of device type or manufacturer. There are around twenty TR-* documents which mostly define new parameters or extend the RPC (Remote Procedure Call) methods. CWMP (CPE WAN Management Protocol), sometimes called TR-069 (Technical Report 069), is a technical specification of a Broadband Forum designed for remote governing of CPE (Customer Premises Equipment). Seeing that CWMP is a standardized, text based protocol which offers a communication between CPE and Auto Configuration Servers (ACS), it can be used between different equipment manufacturers. Couple of years back I've authored the first Open Source TR-069 client specifically targeting OpenWrt - it was named freecwmp [3]. Since then I've learned a lot of lessons and in the company, Sartura, the team has started developing new implementation which solves the limitations of the old implementation. If funded, we are going to use the budget to further improve existing codebase and of course to clean it up and prepare for Open Source release. In order to make this a success, we will work on the documentation, testing infrastructure and make it easy for vendors and hackers to use this project when needed. I'll be making Rocket CWMP presentation on the prplwrt meeting on May 19 (tomorrow). [4] These meetings are usually recorded and published on YouTube. I hope that will happen with this meeting as well in case somebody is interested but is not able to join. More information about the proposal can be found on the prpl Wiki [5] and in the proposal documentation [6][7]. Comments are welcome! Sincerely, Luka Perkov [1] http://wiki.prplfoundation.org/wiki/OpenWrt_Funding [2] https://www.broadband-forum.org/cwmp.php [3] https://lists.openwrt.org/pipermail/openwrt-devel/2012-June/015655.html [4] http://lists.prplfoundation.org/pipermail/openwrt/2016-May/000544.html [5] http://wiki.prplfoundation.org/wiki/OpenWrt_Funding/Rocket_CWMP [6] http://www.sartura.hr/cwmp/sartura-prpl-rocket-cwmp-public.pdf [7] http://www.sartura.hr/cwmp/sartura-prpl-rocket-cwmp-slides-public.pdf _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From eyal.birger at gmail.com Wed May 18 23:55:27 2016 From: eyal.birger at gmail.com (Eyal Birger) Date: Thu, 19 May 2016 06:55:27 +0300 Subject: [OpenWrt-Devel] [PATCH] mdnsd: interface: enable looped back messages Message-ID: <1463630127-4744-1-git-send-email-eyal.birger@gmail.com> When the IP_MULTICAST_LOOP/IPV6_MULTICAST_LOOP socket options are not enabled, locally generated queries are ignored by mdnsd; This prevents local applications from being able to discover locally published services. Signed-off-by: Eyal Birger --- interface.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/interface.c b/interface.c index c8d8972..9ca85e1 100644 --- a/interface.c +++ b/interface.c @@ -315,7 +315,7 @@ interface_mcast_setup4(struct interface *iface) { struct ip_mreqn mreq; uint8_t ttl = 255; - int no = 0; + int yes = 1; struct sockaddr_in sa = { 0 }; int fd = iface->fd.fd; @@ -345,7 +345,7 @@ interface_mcast_setup4(struct interface *iface) return -1; } - if (setsockopt(fd, IPPROTO_IP, IP_MULTICAST_LOOP, &no, sizeof(no)) < 0) + if (setsockopt(fd, IPPROTO_IP, IP_MULTICAST_LOOP, &yes, sizeof(yes)) < 0) fprintf(stderr, "ioctl failed: IP_MULTICAST_LOOP\n"); return 0; @@ -356,7 +356,7 @@ interface_socket_setup6(struct interface *iface) { struct ipv6_mreq mreq; int ttl = 255; - int no = 0; + int yes = 1; struct sockaddr_in6 sa = { 0 }; int fd = iface->fd.fd; @@ -379,7 +379,7 @@ interface_socket_setup6(struct interface *iface) return -1; } - if (setsockopt(fd, IPPROTO_IPV6, IPV6_MULTICAST_LOOP, &no, sizeof(no)) < 0) + if (setsockopt(fd, IPPROTO_IPV6, IPV6_MULTICAST_LOOP, &yes, sizeof(yes)) < 0) fprintf(stderr, "ioctl failed: IPV6_MULTICAST_LOOP\n"); return 0; -- 1.9.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From Alexey.Brodkin at synopsys.com Thu May 19 01:20:33 2016 From: Alexey.Brodkin at synopsys.com (Alexey Brodkin) Date: Thu, 19 May 2016 08:20:33 +0300 Subject: [OpenWrt-Devel] [PATCH] toolchain: Bump ARC tools to arc-2016.03 Message-ID: <1463635233-4922-1-git-send-email-abrodkin@synopsys.com> This change switches ARC tools to the most recent arc-2016.03 version. ARC GNU tools of version arc-2016.03 bring some quite significant changes like: * Binutils v2.26+ (upstream commit id 202ac19 with additional ARC * patches) * GCC v4.8.5 * GDB 7.10 More about changes, improvements and fixes could be found here: https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/tag/arc-2016.03 Signed-off-by: Alexey Brodkin --- toolchain/binutils/Config.in | 8 ++++---- toolchain/binutils/Config.version | 4 ++-- toolchain/binutils/Makefile | 8 ++++---- .../patches/arc-2016.03/200-arc-fix-target-mask.patch | 13 +++++++++++++ toolchain/gcc/Config.version | 2 +- toolchain/gcc/common.mk | 8 ++++---- .../001-revert_register_mode_search.patch | 0 .../{arc-2015.06 => arc-2016.03}/002-weak_data_fix.patch | 0 .../003-universal_initializer.patch | 0 .../{arc-2015.06 => arc-2016.03}/004-case_insensitive.patch | 0 .../{arc-2015.06 => arc-2016.03}/010-documentation.patch | 0 .../{arc-2015.06 => arc-2016.03}/020-no-plt-backport.patch | 0 .../{arc-2015.06 => arc-2016.03}/100-uclibc-conf.patch | 0 .../210-disable_libsanitizer_off_t_check.patch | 0 .../800-arc-disablelibgmon.patch | 0 .../{arc-2015.06 => arc-2016.03}/820-libgcc_pic.patch | 0 .../850-use_shared_libgcc.patch | 0 .../{arc-2015.06 => arc-2016.03}/851-libgcc_no_compat.patch | 0 .../{arc-2015.06 => arc-2016.03}/860-use_eh_frame.patch | 0 .../{arc-2015.06 => arc-2016.03}/870-ppc_no_crtsavres.patch | 0 .../{arc-2015.06 => arc-2016.03}/880-no_java_section.patch | 0 .../{arc-2015.06 => arc-2016.03}/910-mbsd_multi.patch | 0 .../920-specs_nonfatal_getenv.patch | 0 .../940-no-clobber-stamp-bits.patch | 0 toolchain/gdb/Makefile | 6 +++--- .../100-no_extern_inline.patch | 4 ++-- .../{arc-2015.06-gdb => arc-2016.03}/110-no_testsuite.patch | 4 ++-- .../120-fix-compile-flag-mismatch.patch | 2 +- .../gdb/patches/arc-2016.03/200-arc-fix-target-mask.patch | 13 +++++++++++++ 29 files changed, 49 insertions(+), 23 deletions(-) create mode 100644 toolchain/binutils/patches/arc-2016.03/200-arc-fix-target-mask.patch rename toolchain/gcc/patches/{arc-2015.06 => arc-2016.03}/001-revert_register_mode_search.patch (100%) rename toolchain/gcc/patches/{arc-2015.06 => arc-2016.03}/002-weak_data_fix.patch (100%) rename toolchain/gcc/patches/{arc-2015.06 => arc-2016.03}/003-universal_initializer.patch (100%) rename toolchain/gcc/patches/{arc-2015.06 => arc-2016.03}/004-case_insensitive.patch (100%) rename toolchain/gcc/patches/{arc-2015.06 => arc-2016.03}/010-documentation.patch (100%) rename toolchain/gcc/patches/{arc-2015.06 => arc-2016.03}/020-no-plt-backport.patch (100%) rename toolchain/gcc/patches/{arc-2015.06 => arc-2016.03}/100-uclibc-conf.patch (100%) rename toolchain/gcc/patches/{arc-2015.06 => arc-2016.03}/210-disable_libsanitizer_off_t_check.patch (100%) rename toolchain/gcc/patches/{arc-2015.06 => arc-2016.03}/800-arc-disablelibgmon.patch (100%) rename toolchain/gcc/patches/{arc-2015.06 => arc-2016.03}/820-libgcc_pic.patch (100%) rename toolchain/gcc/patches/{arc-2015.06 => arc-2016.03}/850-use_shared_libgcc.patch (100%) rename toolchain/gcc/patches/{arc-2015.06 => arc-2016.03}/851-libgcc_no_compat.patch (100%) rename toolchain/gcc/patches/{arc-2015.06 => arc-2016.03}/860-use_eh_frame.patch (100%) rename toolchain/gcc/patches/{arc-2015.06 => arc-2016.03}/870-ppc_no_crtsavres.patch (100%) rename toolchain/gcc/patches/{arc-2015.06 => arc-2016.03}/880-no_java_section.patch (100%) rename toolchain/gcc/patches/{arc-2015.06 => arc-2016.03}/910-mbsd_multi.patch (100%) rename toolchain/gcc/patches/{arc-2015.06 => arc-2016.03}/920-specs_nonfatal_getenv.patch (100%) rename toolchain/gcc/patches/{arc-2015.06 => arc-2016.03}/940-no-clobber-stamp-bits.patch (100%) rename toolchain/gdb/patches/{arc-2015.06-gdb => arc-2016.03}/100-no_extern_inline.patch (91%) rename toolchain/gdb/patches/{arc-2015.06-gdb => arc-2016.03}/110-no_testsuite.patch (73%) rename toolchain/gdb/patches/{arc-2015.06-gdb => arc-2016.03}/120-fix-compile-flag-mismatch.patch (85%) create mode 100644 toolchain/gdb/patches/arc-2016.03/200-arc-fix-target-mask.patch diff --git a/toolchain/binutils/Config.in b/toolchain/binutils/Config.in index c32f43c..2960c94 100644 --- a/toolchain/binutils/Config.in +++ b/toolchain/binutils/Config.in @@ -3,7 +3,7 @@ choice prompt "Binutils Version" if TOOLCHAINOPTS default BINUTILS_USE_VERSION_2_25_1 if !arc - default BINUTILS_USE_VERSION_2_23_ARC if arc + default BINUTILS_USE_VERSION_2_26_ARC if arc help Select the version of binutils you wish to use. @@ -17,10 +17,10 @@ choice bool "Binutils 2.25.1" select BINUTILS_VERSION_2_25_1 - config BINUTILS_USE_VERSION_2_23_ARC + config BINUTILS_USE_VERSION_2_26_ARC depends on arc - bool "ARC binutils 2.23" - select BINUTILS_VERSION_2_23_ARC + bool "ARC binutils 2.26" + select BINUTILS_VERSION_2_26_ARC endchoice diff --git a/toolchain/binutils/Config.version b/toolchain/binutils/Config.version index bea748b..fc7a1f3 100644 --- a/toolchain/binutils/Config.version +++ b/toolchain/binutils/Config.version @@ -5,7 +5,7 @@ config BINUTILS_VERSION_2_25_1 default y if (!TOOLCHAINOPTS && !arc) bool -config BINUTILS_VERSION_2_23_ARC +config BINUTILS_VERSION_2_26_ARC default y if (!TOOLCHAINOPTS && arc) bool @@ -13,5 +13,5 @@ config BINUTILS_VERSION string default "2.24-linaro" if BINUTILS_VERSION_2_24_LINARO default "2.25.1" if BINUTILS_VERSION_2_25_1 - default "arc-2015.06" if BINUTILS_VERSION_2_23_ARC + default "arc-2016.03" if BINUTILS_VERSION_2_26_ARC diff --git a/toolchain/binutils/Makefile b/toolchain/binutils/Makefile index c37148e..03fc76a 100644 --- a/toolchain/binutils/Makefile +++ b/toolchain/binutils/Makefile @@ -26,11 +26,11 @@ ifeq ($(findstring linaro, $(CONFIG_BINUTILS_VERSION)),linaro) HOST_BUILD_DIR:=$(BUILD_DIR_TOOLCHAIN)/$(BINUTILS_DIR) endif -ifneq ($(CONFIG_BINUTILS_VERSION_2_23_ARC),) - PKG_SOURCE_URL:=https://github.com/foss-for-synopsys-dwc-arc-processors/binutils-gdb/archive/arc-2015.06/ - PKG_REV:=2015.06 +ifneq ($(CONFIG_BINUTILS_VERSION_2_26_ARC),) + PKG_SOURCE_URL:=https://github.com/foss-for-synopsys-dwc-arc-processors/binutils-gdb/archive/arc-2016.03/ + PKG_REV:=2016.03 PKG_SOURCE:=$(PKG_NAME)-arc-$(PKG_REV).tar.gz - PKG_MD5SUM:=961a3564de857238c255c381f8e4360b + PKG_MD5SUM:=d4387bab089df77a8049c81980b9fa12 BINUTILS_DIR:=$(PKG_NAME)-gdb-arc-$(PKG_REV) HOST_BUILD_DIR:=$(BUILD_DIR_TOOLCHAIN)/$(BINUTILS_DIR) endif diff --git a/toolchain/binutils/patches/arc-2016.03/200-arc-fix-target-mask.patch b/toolchain/binutils/patches/arc-2016.03/200-arc-fix-target-mask.patch new file mode 100644 index 0000000..7e51d58 --- /dev/null +++ b/toolchain/binutils/patches/arc-2016.03/200-arc-fix-target-mask.patch @@ -0,0 +1,13 @@ +diff --git a/bfd/config.bfd b/bfd/config.bfd +index 5145d4a..a9c9c99 100644 +--- a/bfd/config.bfd ++++ b/bfd/config.bfd +@@ -275,7 +275,7 @@ case "${targ}" in + targ_defvec=am33_elf32_linux_vec + ;; + +- arc*-*-elf* | arc*-*-linux-uclibc*) ++ arc*-*-elf* | arc*-*-linux-*) + targ_defvec=arc_elf32_le_vec + targ_selvecs=arc_elf32_be_vec + ;; diff --git a/toolchain/gcc/Config.version b/toolchain/gcc/Config.version index 5d393c5..f9e8c47 100644 --- a/toolchain/gcc/Config.version +++ b/toolchain/gcc/Config.version @@ -5,7 +5,7 @@ config GCC_VERSION_4_8_ARC config GCC_VERSION string default "4.8-linaro" if GCC_VERSION_4_8_LINARO - default "arc-2015.06" if GCC_VERSION_4_8_ARC + default "arc-2016.03" if GCC_VERSION_4_8_ARC default "5.3.0" config GCC_VERSION_4_8 diff --git a/toolchain/gcc/common.mk b/toolchain/gcc/common.mk index e1580cf..3a95ac2 100644 --- a/toolchain/gcc/common.mk +++ b/toolchain/gcc/common.mk @@ -33,11 +33,11 @@ ifeq ($(PKG_VERSION),5.3.0) endif ifneq ($(CONFIG_GCC_VERSION_4_8_ARC),) - PKG_VERSION:=4.8.4 - PKG_SOURCE_URL:=https://github.com/foss-for-synopsys-dwc-arc-processors/gcc/archive/arc-2015.06 + PKG_VERSION:=4.8.5 + PKG_SOURCE_URL:=https://github.com/foss-for-synopsys-dwc-arc-processors/gcc/archive/arc-2016.03 PKG_SOURCE:=$(PKG_NAME)-$(GCC_VERSION).tar.gz - PKG_MD5SUM:=25007ebb02a5f6c32532b103bb5984a0 - PKG_REV:=2015.06 + PKG_MD5SUM:=ca59c8140d6efd07b97a18869bddbb53 + PKG_REV:=2016.03 GCC_DIR:=gcc-arc-$(PKG_REV) HOST_BUILD_DIR = $(BUILD_DIR_HOST)/$(PKG_NAME)-$(GCC_VERSION) endif diff --git a/toolchain/gcc/patches/arc-2015.06/001-revert_register_mode_search.patch b/toolchain/gcc/patches/arc-2016.03/001-revert_register_mode_search.patch similarity index 100% rename from toolchain/gcc/patches/arc-2015.06/001-revert_register_mode_search.patch rename to toolchain/gcc/patches/arc-2016.03/001-revert_register_mode_search.patch diff --git a/toolchain/gcc/patches/arc-2015.06/002-weak_data_fix.patch b/toolchain/gcc/patches/arc-2016.03/002-weak_data_fix.patch similarity index 100% rename from toolchain/gcc/patches/arc-2015.06/002-weak_data_fix.patch rename to toolchain/gcc/patches/arc-2016.03/002-weak_data_fix.patch diff --git a/toolchain/gcc/patches/arc-2015.06/003-universal_initializer.patch b/toolchain/gcc/patches/arc-2016.03/003-universal_initializer.patch similarity index 100% rename from toolchain/gcc/patches/arc-2015.06/003-universal_initializer.patch rename to toolchain/gcc/patches/arc-2016.03/003-universal_initializer.patch diff --git a/toolchain/gcc/patches/arc-2015.06/004-case_insensitive.patch b/toolchain/gcc/patches/arc-2016.03/004-case_insensitive.patch similarity index 100% rename from toolchain/gcc/patches/arc-2015.06/004-case_insensitive.patch rename to toolchain/gcc/patches/arc-2016.03/004-case_insensitive.patch diff --git a/toolchain/gcc/patches/arc-2015.06/010-documentation.patch b/toolchain/gcc/patches/arc-2016.03/010-documentation.patch similarity index 100% rename from toolchain/gcc/patches/arc-2015.06/010-documentation.patch rename to toolchain/gcc/patches/arc-2016.03/010-documentation.patch diff --git a/toolchain/gcc/patches/arc-2015.06/020-no-plt-backport.patch b/toolchain/gcc/patches/arc-2016.03/020-no-plt-backport.patch similarity index 100% rename from toolchain/gcc/patches/arc-2015.06/020-no-plt-backport.patch rename to toolchain/gcc/patches/arc-2016.03/020-no-plt-backport.patch diff --git a/toolchain/gcc/patches/arc-2015.06/100-uclibc-conf.patch b/toolchain/gcc/patches/arc-2016.03/100-uclibc-conf.patch similarity index 100% rename from toolchain/gcc/patches/arc-2015.06/100-uclibc-conf.patch rename to toolchain/gcc/patches/arc-2016.03/100-uclibc-conf.patch diff --git a/toolchain/gcc/patches/arc-2015.06/210-disable_libsanitizer_off_t_check.patch b/toolchain/gcc/patches/arc-2016.03/210-disable_libsanitizer_off_t_check.patch similarity index 100% rename from toolchain/gcc/patches/arc-2015.06/210-disable_libsanitizer_off_t_check.patch rename to toolchain/gcc/patches/arc-2016.03/210-disable_libsanitizer_off_t_check.patch diff --git a/toolchain/gcc/patches/arc-2015.06/800-arc-disablelibgmon.patch b/toolchain/gcc/patches/arc-2016.03/800-arc-disablelibgmon.patch similarity index 100% rename from toolchain/gcc/patches/arc-2015.06/800-arc-disablelibgmon.patch rename to toolchain/gcc/patches/arc-2016.03/800-arc-disablelibgmon.patch diff --git a/toolchain/gcc/patches/arc-2015.06/820-libgcc_pic.patch b/toolchain/gcc/patches/arc-2016.03/820-libgcc_pic.patch similarity index 100% rename from toolchain/gcc/patches/arc-2015.06/820-libgcc_pic.patch rename to toolchain/gcc/patches/arc-2016.03/820-libgcc_pic.patch diff --git a/toolchain/gcc/patches/arc-2015.06/850-use_shared_libgcc.patch b/toolchain/gcc/patches/arc-2016.03/850-use_shared_libgcc.patch similarity index 100% rename from toolchain/gcc/patches/arc-2015.06/850-use_shared_libgcc.patch rename to toolchain/gcc/patches/arc-2016.03/850-use_shared_libgcc.patch diff --git a/toolchain/gcc/patches/arc-2015.06/851-libgcc_no_compat.patch b/toolchain/gcc/patches/arc-2016.03/851-libgcc_no_compat.patch similarity index 100% rename from toolchain/gcc/patches/arc-2015.06/851-libgcc_no_compat.patch rename to toolchain/gcc/patches/arc-2016.03/851-libgcc_no_compat.patch diff --git a/toolchain/gcc/patches/arc-2015.06/860-use_eh_frame.patch b/toolchain/gcc/patches/arc-2016.03/860-use_eh_frame.patch similarity index 100% rename from toolchain/gcc/patches/arc-2015.06/860-use_eh_frame.patch rename to toolchain/gcc/patches/arc-2016.03/860-use_eh_frame.patch diff --git a/toolchain/gcc/patches/arc-2015.06/870-ppc_no_crtsavres.patch b/toolchain/gcc/patches/arc-2016.03/870-ppc_no_crtsavres.patch similarity index 100% rename from toolchain/gcc/patches/arc-2015.06/870-ppc_no_crtsavres.patch rename to toolchain/gcc/patches/arc-2016.03/870-ppc_no_crtsavres.patch diff --git a/toolchain/gcc/patches/arc-2015.06/880-no_java_section.patch b/toolchain/gcc/patches/arc-2016.03/880-no_java_section.patch similarity index 100% rename from toolchain/gcc/patches/arc-2015.06/880-no_java_section.patch rename to toolchain/gcc/patches/arc-2016.03/880-no_java_section.patch diff --git a/toolchain/gcc/patches/arc-2015.06/910-mbsd_multi.patch b/toolchain/gcc/patches/arc-2016.03/910-mbsd_multi.patch similarity index 100% rename from toolchain/gcc/patches/arc-2015.06/910-mbsd_multi.patch rename to toolchain/gcc/patches/arc-2016.03/910-mbsd_multi.patch diff --git a/toolchain/gcc/patches/arc-2015.06/920-specs_nonfatal_getenv.patch b/toolchain/gcc/patches/arc-2016.03/920-specs_nonfatal_getenv.patch similarity index 100% rename from toolchain/gcc/patches/arc-2015.06/920-specs_nonfatal_getenv.patch rename to toolchain/gcc/patches/arc-2016.03/920-specs_nonfatal_getenv.patch diff --git a/toolchain/gcc/patches/arc-2015.06/940-no-clobber-stamp-bits.patch b/toolchain/gcc/patches/arc-2016.03/940-no-clobber-stamp-bits.patch similarity index 100% rename from toolchain/gcc/patches/arc-2015.06/940-no-clobber-stamp-bits.patch rename to toolchain/gcc/patches/arc-2016.03/940-no-clobber-stamp-bits.patch diff --git a/toolchain/gdb/Makefile b/toolchain/gdb/Makefile index 0e1b0a2..97d88d6 100644 --- a/toolchain/gdb/Makefile +++ b/toolchain/gdb/Makefile @@ -9,11 +9,11 @@ include $(TOPDIR)/rules.mk PKG_NAME:=gdb ifeq ($(CONFIG_arc),y) -PKG_VERSION:=arc-2015.06-gdb +PKG_VERSION:=arc-2016.03-gdb PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz -PKG_SOURCE_URL:=https://github.com/foss-for-synopsys-dwc-arc-processors/binutils-gdb/archive/arc-2015.06-gdb/ -PKG_MD5SUM:=d318829bfd2ed62714817f0d25706825 +PKG_SOURCE_URL:=https://github.com/foss-for-synopsys-dwc-arc-processors/binutils-gdb/archive/arc-2016.03-gdb +PKG_MD5SUM:=775caaf6385c16f20b6f53c0a2b95f79 GDB_DIR:=binutils-$(PKG_NAME)-$(PKG_VERSION) else PKG_VERSION:=7.11 diff --git a/toolchain/gdb/patches/arc-2015.06-gdb/100-no_extern_inline.patch b/toolchain/gdb/patches/arc-2016.03/100-no_extern_inline.patch similarity index 91% rename from toolchain/gdb/patches/arc-2015.06-gdb/100-no_extern_inline.patch rename to toolchain/gdb/patches/arc-2016.03/100-no_extern_inline.patch index bbae1d7..8c18c6e 100644 --- a/toolchain/gdb/patches/arc-2015.06-gdb/100-no_extern_inline.patch +++ b/toolchain/gdb/patches/arc-2016.03/100-no_extern_inline.patch @@ -21,11 +21,11 @@ +#endif /* DEFINE_NON_INLINE_P */ --- a/sim/common/sim-arange.h +++ b/sim/common/sim-arange.h -@@ -62,7 +62,7 @@ extern void sim_addr_range_delete (ADDR_ +@@ -73,7 +73,7 @@ extern void sim_addr_range_delete (ADDR_ /* Return non-zero if ADDR is in range AR, traversing the entire tree. If no range is specified, that is defined to mean "everything". */ --extern INLINE int +-SIM_ARANGE_INLINE int +extern int sim_addr_range_hit_p (ADDR_RANGE * /*ar*/, address_word /*addr*/); #define ADDR_RANGE_HIT_P(ar, addr) \ diff --git a/toolchain/gdb/patches/arc-2015.06-gdb/110-no_testsuite.patch b/toolchain/gdb/patches/arc-2016.03/110-no_testsuite.patch similarity index 73% rename from toolchain/gdb/patches/arc-2015.06-gdb/110-no_testsuite.patch rename to toolchain/gdb/patches/arc-2016.03/110-no_testsuite.patch index 5c5d15c..1b284ea 100644 --- a/toolchain/gdb/patches/arc-2015.06-gdb/110-no_testsuite.patch +++ b/toolchain/gdb/patches/arc-2016.03/110-no_testsuite.patch @@ -1,6 +1,6 @@ --- a/gdb/configure +++ b/gdb/configure -@@ -855,8 +855,7 @@ MAKEINFOFLAGS +@@ -870,8 +870,7 @@ MAKEINFOFLAGS YACC YFLAGS XMKMF' @@ -10,7 +10,7 @@ multi-ice gdbserver' -@@ -5168,7 +5167,7 @@ $as_echo "$with_auto_load_safe_path" >&6 +@@ -5610,7 +5610,7 @@ $as_echo "$with_auto_load_safe_path" >&6 diff --git a/toolchain/gdb/patches/arc-2015.06-gdb/120-fix-compile-flag-mismatch.patch b/toolchain/gdb/patches/arc-2016.03/120-fix-compile-flag-mismatch.patch similarity index 85% rename from toolchain/gdb/patches/arc-2015.06-gdb/120-fix-compile-flag-mismatch.patch rename to toolchain/gdb/patches/arc-2016.03/120-fix-compile-flag-mismatch.patch index ce34c95..c8b41f2 100644 --- a/toolchain/gdb/patches/arc-2015.06-gdb/120-fix-compile-flag-mismatch.patch +++ b/toolchain/gdb/patches/arc-2016.03/120-fix-compile-flag-mismatch.patch @@ -1,6 +1,6 @@ --- a/gdb/gdbserver/configure +++ b/gdb/gdbserver/configure -@@ -2183,7 +2183,7 @@ $as_echo "$as_me: error: \`$ac_var' was +@@ -2468,7 +2468,7 @@ $as_echo "$as_me: error: \`$ac_var' was ac_cache_corrupted=: ;; ,);; *) diff --git a/toolchain/gdb/patches/arc-2016.03/200-arc-fix-target-mask.patch b/toolchain/gdb/patches/arc-2016.03/200-arc-fix-target-mask.patch new file mode 100644 index 0000000..7e51d58 --- /dev/null +++ b/toolchain/gdb/patches/arc-2016.03/200-arc-fix-target-mask.patch @@ -0,0 +1,13 @@ +diff --git a/bfd/config.bfd b/bfd/config.bfd +index 5145d4a..a9c9c99 100644 +--- a/bfd/config.bfd ++++ b/bfd/config.bfd +@@ -275,7 +275,7 @@ case "${targ}" in + targ_defvec=am33_elf32_linux_vec + ;; + +- arc*-*-elf* | arc*-*-linux-uclibc*) ++ arc*-*-elf* | arc*-*-linux-*) + targ_defvec=arc_elf32_le_vec + targ_selvecs=arc_elf32_be_vec + ;; -- 2.5.5 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From nitroshift at yahoo.com Thu May 19 02:41:00 2016 From: nitroshift at yahoo.com (Sebastian Careba) Date: Thu, 19 May 2016 09:41:00 +0300 Subject: [OpenWrt-Devel] [OpenWRT-Devel] mvebu: introduce mvneta buffer manager offload module Message-ID: <1463640060-3677-1-git-send-email-nitroshift@yahoo.com> Buffer manager (BM) is a dedicated hardware unit that can be used by all ethernet ports of Armada XP and 38x SoC's. It allows to offload CPU on RX path by sparing DRAM access on refilling buffer pool, hardware-based filling of descriptor ring data and better memory utilization due to HW arbitration for using 'short' pools for small packets. Tests performed with A388 SoC working as a network bridge between two packet generators showed increase of maximum processed 64B packets by ~20k (~555k packets with BM enabled vs ~535 packets without BM). Also when pushing 1500B-packets with a line rate achieved, CPU load decreased from around 25% without BM to 20% with BM. BM comprise up to 4 buffer pointers' (BP) rings kept in DRAM, which are called external BP pools - BPPE. Allocating and releasing buffer pointers (BP) to/from BPPE is performed indirectly by write/read access to a dedicated internal SRAM, where internal BP pools (BPPI) are placed. BM hardware controls status of BPPE automatically, as well as assigning proper buffers to RX descriptors. For more details please refer to Functional Specification of Armada XP or 38x SoC. In order to enable support for a separate hardware block, common for all ports, a new driver has to be implemented ('mvneta_bm'). It provides initialization sequence of address space, clocks, registers, SRAM, empty pools' structures and also obtaining optional configuration from DT (please refer to device tree binding documentation). mvneta_bm exposes also a necessary API to mvneta driver, as well as a dedicated structure with BM information (bm_priv), whose presence is used as a flag notifying of BM usage by port. It has to be ensured that mvneta_bm probe is executed prior to the ones in ports' driver. In case BM is not used or its probe fails, mvneta falls back to use software buffer management. A sequence executed in mvneta_probe function is modified in order to have an access to needed resources before possible port's BM initialization is done. According to port-pools mapping provided by DT appropriate registers are configured and the buffer pools are filled. RX path is modified accordingly. Becaues the hardware allows a wide variety of configuration options, following assumptions are made: * using BM mechanisms can be selectively disabled/enabled basing on DT configuration among the ports * 'long' pool's single buffer size is tied to port's MTU * using 'long' pool by port is obligatory and it cannot be shared * using 'short' pool for smaller packets is optional * one 'short' pool can be shared among all ports This commit enables hardware buffer management operation cooperating with existing mvneta driver. New device tree binding documentation is added and the one of mvneta is updated accordingly. [gregory.clement at free-electrons.com: removed the suspend/resume part] Signed-off-by: Gregory Clement Signed-off-by: Marcin Wojtas Signed-off-by: Sebastian Careba --- --- a/drivers/net/ethernet/marvell/Makefile +++ b/drivers/net/ethernet/marvell/Makefile @@ -4,6 +4,7 @@ obj-$(CONFIG_MVMDIO) += mvmdio.o obj-$(CONFIG_MV643XX_ETH) += mv643xx_eth.o +obj-$(CONFIG_MVNETA_BM) += mvneta_bm.o obj-$(CONFIG_MVNETA) += mvneta.o obj-$(CONFIG_MVPP2) += mvpp2.o obj-$(CONFIG_PXA168_ETH) += pxa168_eth.o--- a/drivers/net/ethernet/marvell/mvneta.c +++ b/drivers/net/ethernet/marvell/mvneta.c @@ -11,32 +11,38 @@ * warranty of any kind, whether express or implied. */ -#include -#include +#include +#include #include -#include -#include +#include #include -#include -#include #include -#include -#include -#include #include -#include +#include +#include +#include +#include #include +#include #include #include #include -#include #include -#include -#include +#include +#include +#include +#include "mvneta_bm.h" +#include +#include +#include /* Registers */ #define MVNETA_RXQ_CONFIG_REG(q) (0x1400 + ((q) << 2)) #define MVNETA_RXQ_HW_BUF_ALLOC BIT(0) +#define MVNETA_RXQ_SHORT_POOL_ID_SHIFT 4 +#define MVNETA_RXQ_SHORT_POOL_ID_MASK 0x30 +#define MVNETA_RXQ_LONG_POOL_ID_SHIFT 6 +#define MVNETA_RXQ_LONG_POOL_ID_MASK 0xc0 #define MVNETA_RXQ_PKT_OFFSET_ALL_MASK (0xf << 8) #define MVNETA_RXQ_PKT_OFFSET_MASK(offs) ((offs) << 8) #define MVNETA_RXQ_THRESHOLD_REG(q) (0x14c0 + ((q) << 2)) @@ -50,6 +56,9 @@ #define MVNETA_RXQ_STATUS_UPDATE_REG(q) (0x1500 + ((q) << 2)) #define MVNETA_RXQ_ADD_NON_OCCUPIED_SHIFT 16 #define MVNETA_RXQ_ADD_NON_OCCUPIED_MAX 255 +#define MVNETA_PORT_POOL_BUFFER_SZ_REG(pool) (0x1700 + ((pool) << 2)) +#define MVNETA_PORT_POOL_BUFFER_SZ_SHIFT 3 +#define MVNETA_PORT_POOL_BUFFER_SZ_MASK 0xfff8 #define MVNETA_PORT_RX_RESET 0x1cc0 #define MVNETA_PORT_RX_DMA_RESET BIT(0) #define MVNETA_PHY_ADDR 0x2000 @@ -107,12 +116,21 @@ #define MVNETA_GMAC_CLOCK_DIVIDER 0x24f4 #define MVNETA_GMAC_1MS_CLOCK_ENABLE BIT(31) #define MVNETA_ACC_MODE 0x2500 +#define MVNETA_BM_ADDRESS 0x2504 #define MVNETA_CPU_MAP(cpu) (0x2540 + ((cpu) << 2)) #define MVNETA_CPU_RXQ_ACCESS_ALL_MASK 0x000000ff #define MVNETA_CPU_TXQ_ACCESS_ALL_MASK 0x0000ff00 +#define MVNETA_CPU_RXQ_ACCESS(rxq) BIT(rxq) +#define MVNETA_CPU_TXQ_ACCESS(txq) BIT(txq + 8) #define MVNETA_RXQ_TIME_COAL_REG(q) (0x2580 + ((q) << 2)) -/* Exception Interrupt Port/Queue Cause register */ +/* Exception Interrupt Port/Queue Cause register + * + * Their behavior depend of the mapping done using the PCPX2Q + * registers. For a given CPU if the bit associated to a queue is not + * set, then for the register a read from this CPU will always return + * 0 and a write won't do anything + */ #define MVNETA_INTR_NEW_CAUSE 0x25a0 #define MVNETA_INTR_NEW_MASK 0x25a4 @@ -245,7 +263,10 @@ #define MVNETA_CPU_D_CACHE_LINE_SIZE 32 #define MVNETA_TX_CSUM_DEF_SIZE 1600 #define MVNETA_TX_CSUM_MAX_SIZE 9800 -#define MVNETA_ACC_MODE_EXT 1 +#define MVNETA_ACC_MODE_EXT1 1 +#define MVNETA_ACC_MODE_EXT2 2 + +#define MVNETA_MAX_DECODE_WIN 6 /* Timeout constants */ #define MVNETA_TX_DISABLE_TIMEOUT_MSEC 1000 @@ -254,6 +275,11 @@ #define MVNETA_TX_MTU_MAX 0x3ffff +/* The RSS lookup table actually has 256 entries but we do not use + * them yet + */ +#define MVNETA_RSS_LU_TABLE_SIZE 1 + /* TSO header size */ #define TSO_HEADER_SIZE 128 @@ -280,7 +306,8 @@ ((addr >= txq->tso_hdrs_phys) && \ (addr < txq->tso_hdrs_phys + txq->size * TSO_HEADER_SIZE)) -#define MVNETA_RX_BUF_SIZE(pkt_size) ((pkt_size) + NET_SKB_PAD) +#define MVNETA_RX_GET_BM_POOL_ID(rxd) \ + (((rxd)->status & MVNETA_RXD_BM_POOL_MASK) >> MVNETA_RXD_BM_POOL_SHIFT) struct mvneta_statistic { unsigned short offset; @@ -346,6 +373,7 @@ struct mvneta_pcpu_port { }; struct mvneta_port { + u8 id; struct mvneta_pcpu_port __percpu *ports; struct mvneta_pcpu_stats __percpu *stats; @@ -356,9 +384,17 @@ struct mvneta_port { struct mvneta_tx_queue *txqs; struct net_device *dev; struct notifier_block cpu_notifier; + int rxq_def; + /* Protect the access to the percpu interrupt registers, + * ensuring that the configuration remains coherent. + */ + spinlock_t lock; + bool is_stopped; /* Core clock */ struct clk *clk; + /* AXI clock */ + struct clk *clk_bus; u8 mcast_count[256]; u16 tx_ring_size; u16 rx_ring_size; @@ -371,9 +407,16 @@ struct mvneta_port { unsigned int duplex; unsigned int speed; unsigned int tx_csum_limit; - int use_inband_status:1; + unsigned int use_inband_status:1; + + struct mvneta_bm *bm_priv; + struct mvneta_bm_pool *pool_long; + struct mvneta_bm_pool *pool_short; + int bm_win_id; u64 ethtool_stats[ARRAY_SIZE(mvneta_statistics)]; + + u32 indir[MVNETA_RSS_LU_TABLE_SIZE]; }; /* The mvneta_tx_desc and mvneta_rx_desc structures describe the @@ -396,6 +439,8 @@ struct mvneta_port { #define MVNETA_TX_L4_CSUM_NOT BIT(31) #define MVNETA_RXD_ERR_CRC 0x0 +#define MVNETA_RXD_BM_POOL_SHIFT 13 +#define MVNETA_RXD_BM_POOL_MASK (BIT(13) | BIT(14)) #define MVNETA_RXD_ERR_SUMMARY BIT(16) #define MVNETA_RXD_ERR_OVERRUN BIT(17) #define MVNETA_RXD_ERR_LEN BIT(18) @@ -499,6 +544,9 @@ struct mvneta_tx_queue { /* DMA address of TSO headers */ dma_addr_t tso_hdrs_phys; + + /* Affinity mask for CPUs*/ + cpumask_t affinity_mask; }; struct mvneta_rx_queue { @@ -537,6 +585,9 @@ static int rxq_def; static int rx_copybreak __read_mostly = 256; +/* HW BM need that each port be identify by a unique ID */ +static int global_port_id; + #define MVNETA_DRIVER_NAME "mvneta" #define MVNETA_DRIVER_VERSION "1.0" @@ -803,6 +854,215 @@ static void mvneta_rxq_bm_disable(struct mvreg_write(pp, MVNETA_RXQ_CONFIG_REG(rxq->id), val); } +/* Enable buffer management (BM) */ +static void mvneta_rxq_bm_enable(struct mvneta_port *pp, + struct mvneta_rx_queue *rxq) +{ + u32 val; + + val = mvreg_read(pp, MVNETA_RXQ_CONFIG_REG(rxq->id)); + val |= MVNETA_RXQ_HW_BUF_ALLOC; + mvreg_write(pp, MVNETA_RXQ_CONFIG_REG(rxq->id), val); +} + +/* Notify HW about port's assignment of pool for bigger packets */ +static void mvneta_rxq_long_pool_set(struct mvneta_port *pp, + struct mvneta_rx_queue *rxq) +{ + u32 val; + + val = mvreg_read(pp, MVNETA_RXQ_CONFIG_REG(rxq->id)); + val &= ~MVNETA_RXQ_LONG_POOL_ID_MASK; + val |= (pp->pool_long->id << MVNETA_RXQ_LONG_POOL_ID_SHIFT); + + mvreg_write(pp, MVNETA_RXQ_CONFIG_REG(rxq->id), val); +} + +/* Notify HW about port's assignment of pool for smaller packets */ +static void mvneta_rxq_short_pool_set(struct mvneta_port *pp, + struct mvneta_rx_queue *rxq) +{ + u32 val; + + val = mvreg_read(pp, MVNETA_RXQ_CONFIG_REG(rxq->id)); + val &= ~MVNETA_RXQ_SHORT_POOL_ID_MASK; + val |= (pp->pool_short->id << MVNETA_RXQ_SHORT_POOL_ID_SHIFT); + + mvreg_write(pp, MVNETA_RXQ_CONFIG_REG(rxq->id), val); +} + +/* Set port's receive buffer size for assigned BM pool */ +static inline void mvneta_bm_pool_bufsize_set(struct mvneta_port *pp, + int buf_size, + u8 pool_id) +{ + u32 val; + + if (!IS_ALIGNED(buf_size, 8)) { + dev_warn(pp->dev->dev.parent, + "illegal buf_size value %d, round to %d\n", + buf_size, ALIGN(buf_size, 8)); + buf_size = ALIGN(buf_size, 8); + } + + val = mvreg_read(pp, MVNETA_PORT_POOL_BUFFER_SZ_REG(pool_id)); + val |= buf_size & MVNETA_PORT_POOL_BUFFER_SZ_MASK; + mvreg_write(pp, MVNETA_PORT_POOL_BUFFER_SZ_REG(pool_id), val); +} + +/* Configure MBUS window in order to enable access BM internal SRAM */ +static int mvneta_mbus_io_win_set(struct mvneta_port *pp, u32 base, u32 wsize, + u8 target, u8 attr) +{ + u32 win_enable, win_protect; + int i; + + win_enable = mvreg_read(pp, MVNETA_BASE_ADDR_ENABLE); + + if (pp->bm_win_id < 0) { + /* Find first not occupied window */ + for (i = 0; i < MVNETA_MAX_DECODE_WIN; i++) { + if (win_enable & (1 << i)) { + pp->bm_win_id = i; + break; + } + } + if (i == MVNETA_MAX_DECODE_WIN) + return -ENOMEM; + } else { + i = pp->bm_win_id; + } + + mvreg_write(pp, MVNETA_WIN_BASE(i), 0); + mvreg_write(pp, MVNETA_WIN_SIZE(i), 0); + + if (i < 4) + mvreg_write(pp, MVNETA_WIN_REMAP(i), 0); + + mvreg_write(pp, MVNETA_WIN_BASE(i), (base & 0xffff0000) | + (attr << 8) | target); + + mvreg_write(pp, MVNETA_WIN_SIZE(i), (wsize - 1) & 0xffff0000); + + win_protect = mvreg_read(pp, MVNETA_ACCESS_PROTECT_ENABLE); + win_protect |= 3 << (2 * i); + mvreg_write(pp, MVNETA_ACCESS_PROTECT_ENABLE, win_protect); + + win_enable &= ~(1 << i); + mvreg_write(pp, MVNETA_BASE_ADDR_ENABLE, win_enable); + + return 0; +} + +/* Assign and initialize pools for port. In case of fail + * buffer manager will remain disabled for current port. + */ +static int mvneta_bm_port_init(struct platform_device *pdev, + struct mvneta_port *pp) +{ + struct device_node *dn = pdev->dev.of_node; + u32 long_pool_id, short_pool_id, wsize; + u8 target, attr; + int err; + + /* Get BM window information */ + err = mvebu_mbus_get_io_win_info(pp->bm_priv->bppi_phys_addr, &wsize, + &target, &attr); + if (err < 0) + return err; + + pp->bm_win_id = -1; + + /* Open NETA -> BM window */ + err = mvneta_mbus_io_win_set(pp, pp->bm_priv->bppi_phys_addr, wsize, + target, attr); + if (err < 0) { + netdev_info(pp->dev, "fail to configure mbus window to BM\n"); + return err; + } + + if (of_property_read_u32(dn, "bm,pool-long", &long_pool_id)) { + netdev_info(pp->dev, "missing long pool id\n"); + return -EINVAL; + } + + /* Create port's long pool depending on mtu */ + pp->pool_long = mvneta_bm_pool_use(pp->bm_priv, long_pool_id, + MVNETA_BM_LONG, pp->id, + MVNETA_RX_PKT_SIZE(pp->dev->mtu)); + if (!pp->pool_long) { + netdev_info(pp->dev, "fail to obtain long pool for port\n"); + return -ENOMEM; + } + + pp->pool_long->port_map |= 1 << pp->id; + + mvneta_bm_pool_bufsize_set(pp, pp->pool_long->buf_size, + pp->pool_long->id); + + /* If short pool id is not defined, assume using single pool */ + if (of_property_read_u32(dn, "bm,pool-short", &short_pool_id)) + short_pool_id = long_pool_id; + + /* Create port's short pool */ + pp->pool_short = mvneta_bm_pool_use(pp->bm_priv, short_pool_id, + MVNETA_BM_SHORT, pp->id, + MVNETA_BM_SHORT_PKT_SIZE); + if (!pp->pool_short) { + netdev_info(pp->dev, "fail to obtain short pool for port\n"); + mvneta_bm_pool_destroy(pp->bm_priv, pp->pool_long, 1 << pp->id); + return -ENOMEM; + } + + if (short_pool_id != long_pool_id) { + pp->pool_short->port_map |= 1 << pp->id; + mvneta_bm_pool_bufsize_set(pp, pp->pool_short->buf_size, + pp->pool_short->id); + } + + return 0; +} + +/* Update settings of a pool for bigger packets */ +static void mvneta_bm_update_mtu(struct mvneta_port *pp, int mtu) +{ + struct mvneta_bm_pool *bm_pool = pp->pool_long; + struct hwbm_pool *hwbm_pool = &bm_pool->hwbm_pool; + int num; + + /* Release all buffers from long pool */ + mvneta_bm_bufs_free(pp->bm_priv, bm_pool, 1 << pp->id); + if (hwbm_pool->buf_num) { + WARN(1, "cannot free all buffers in pool %d\n", + bm_pool->id); + goto bm_mtu_err; + } + + bm_pool->pkt_size = MVNETA_RX_PKT_SIZE(mtu); + bm_pool->buf_size = MVNETA_RX_BUF_SIZE(bm_pool->pkt_size); + hwbm_pool->frag_size = SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) + + SKB_DATA_ALIGN(MVNETA_RX_BUF_SIZE(bm_pool->pkt_size)); + + /* Fill entire long pool */ + num = hwbm_pool_add(hwbm_pool, hwbm_pool->size, GFP_ATOMIC); + if (num != hwbm_pool->size) { + WARN(1, "pool %d: %d of %d allocated\n", + bm_pool->id, num, hwbm_pool->size); + goto bm_mtu_err; + } + mvneta_bm_pool_bufsize_set(pp, bm_pool->buf_size, bm_pool->id); + + return; + +bm_mtu_err: + mvneta_bm_pool_destroy(pp->bm_priv, pp->pool_long, 1 << pp->id); + mvneta_bm_pool_destroy(pp->bm_priv, pp->pool_short, 1 << pp->id); + + pp->bm_priv = NULL; + mvreg_write(pp, MVNETA_ACC_MODE, MVNETA_ACC_MODE_EXT1); + netdev_info(pp->dev, "fail to update MTU, fall back to software BM\n"); +} + /* Start the Ethernet port RX and TX activity */ static void mvneta_port_up(struct mvneta_port *pp) { @@ -819,7 +1079,13 @@ static void mvneta_port_up(struct mvneta mvreg_write(pp, MVNETA_TXQ_CMD, q_map); /* Enable all initialized RXQs. */ - mvreg_write(pp, MVNETA_RXQ_CMD, BIT(rxq_def)); + for (queue = 0; queue < rxq_number; queue++) { + struct mvneta_rx_queue *rxq = &pp->rxqs[queue]; + + if (rxq->descs != NULL) + q_map |= (1 << queue); + } + mvreg_write(pp, MVNETA_RXQ_CMD, q_map); } /* Stop the Ethernet port activity */ @@ -973,6 +1239,81 @@ static void mvneta_set_other_mcast_table mvreg_write(pp, MVNETA_DA_FILT_OTH_MCAST + offset, val); } +static void mvneta_set_autoneg(struct mvneta_port *pp, int enable) +{ + u32 val; + + if (enable) { + val = mvreg_read(pp, MVNETA_GMAC_AUTONEG_CONFIG); + val &= ~(MVNETA_GMAC_FORCE_LINK_PASS | + MVNETA_GMAC_FORCE_LINK_DOWN | + MVNETA_GMAC_AN_FLOW_CTRL_EN); + val |= MVNETA_GMAC_INBAND_AN_ENABLE | + MVNETA_GMAC_AN_SPEED_EN | + MVNETA_GMAC_AN_DUPLEX_EN; + mvreg_write(pp, MVNETA_GMAC_AUTONEG_CONFIG, val); + + val = mvreg_read(pp, MVNETA_GMAC_CLOCK_DIVIDER); + val |= MVNETA_GMAC_1MS_CLOCK_ENABLE; + mvreg_write(pp, MVNETA_GMAC_CLOCK_DIVIDER, val); + + val = mvreg_read(pp, MVNETA_GMAC_CTRL_2); + val |= MVNETA_GMAC2_INBAND_AN_ENABLE; + mvreg_write(pp, MVNETA_GMAC_CTRL_2, val); + } else { + val = mvreg_read(pp, MVNETA_GMAC_AUTONEG_CONFIG); + val &= ~(MVNETA_GMAC_INBAND_AN_ENABLE | + MVNETA_GMAC_AN_SPEED_EN | + MVNETA_GMAC_AN_DUPLEX_EN); + mvreg_write(pp, MVNETA_GMAC_AUTONEG_CONFIG, val); + + val = mvreg_read(pp, MVNETA_GMAC_CLOCK_DIVIDER); + val &= ~MVNETA_GMAC_1MS_CLOCK_ENABLE; + mvreg_write(pp, MVNETA_GMAC_CLOCK_DIVIDER, val); + + val = mvreg_read(pp, MVNETA_GMAC_CTRL_2); + val &= ~MVNETA_GMAC2_INBAND_AN_ENABLE; + mvreg_write(pp, MVNETA_GMAC_CTRL_2, val); + } +} + +static void mvneta_percpu_unmask_interrupt(void *arg) +{ + struct mvneta_port *pp = arg; + + /* All the queue are unmasked, but actually only the ones + * mapped to this CPU will be unmasked + */ + mvreg_write(pp, MVNETA_INTR_NEW_MASK, + MVNETA_RX_INTR_MASK_ALL | + MVNETA_TX_INTR_MASK_ALL | + MVNETA_MISCINTR_INTR_MASK); +} + +static void mvneta_percpu_mask_interrupt(void *arg) +{ + struct mvneta_port *pp = arg; + + /* All the queue are masked, but actually only the ones + * mapped to this CPU will be masked + */ + mvreg_write(pp, MVNETA_INTR_NEW_MASK, 0); + mvreg_write(pp, MVNETA_INTR_OLD_MASK, 0); + mvreg_write(pp, MVNETA_INTR_MISC_MASK, 0); +} + +static void mvneta_percpu_clear_intr_cause(void *arg) +{ + struct mvneta_port *pp = arg; + + /* All the queue are cleared, but actually only the ones + * mapped to this CPU will be cleared + */ + mvreg_write(pp, MVNETA_INTR_NEW_CAUSE, 0); + mvreg_write(pp, MVNETA_INTR_MISC_CAUSE, 0); + mvreg_write(pp, MVNETA_INTR_OLD_CAUSE, 0); +} + /* This method sets defaults to the NETA port: * Clears interrupt Cause and Mask registers. * Clears all MAC tables. @@ -987,28 +1328,45 @@ static void mvneta_defaults_set(struct m int cpu; int queue; u32 val; + int max_cpu = num_present_cpus(); /* Clear all Cause registers */ - mvreg_write(pp, MVNETA_INTR_NEW_CAUSE, 0); - mvreg_write(pp, MVNETA_INTR_OLD_CAUSE, 0); - mvreg_write(pp, MVNETA_INTR_MISC_CAUSE, 0); + on_each_cpu(mvneta_percpu_clear_intr_cause, pp, true); /* Mask all interrupts */ - mvreg_write(pp, MVNETA_INTR_NEW_MASK, 0); - mvreg_write(pp, MVNETA_INTR_OLD_MASK, 0); - mvreg_write(pp, MVNETA_INTR_MISC_MASK, 0); + on_each_cpu(mvneta_percpu_mask_interrupt, pp, true); mvreg_write(pp, MVNETA_INTR_ENABLE, 0); /* Enable MBUS Retry bit16 */ mvreg_write(pp, MVNETA_MBUS_RETRY, 0x20); - /* Set CPU queue access map - all CPUs have access to all RX - * queues and to all TX queues + /* Set CPU queue access map. CPUs are assigned to the RX and + * TX queues modulo their number. If there is only one TX + * queue then it is assigned to the CPU associated to the + * default RX queue. */ - for_each_present_cpu(cpu) - mvreg_write(pp, MVNETA_CPU_MAP(cpu), - (MVNETA_CPU_RXQ_ACCESS_ALL_MASK | - MVNETA_CPU_TXQ_ACCESS_ALL_MASK)); + for_each_present_cpu(cpu) { + int rxq_map = 0, txq_map = 0; + int rxq, txq; + + for (rxq = 0; rxq < rxq_number; rxq++) + if ((rxq % max_cpu) == cpu) + rxq_map |= MVNETA_CPU_RXQ_ACCESS(rxq); + + for (txq = 0; txq < txq_number; txq++) + if ((txq % max_cpu) == cpu) + txq_map |= MVNETA_CPU_TXQ_ACCESS(txq); + + /* With only one TX queue we configure a special case + * which will allow to get all the irq on a single + * CPU + */ + if (txq_number == 1) + txq_map = (cpu == pp->rxq_def) ? + MVNETA_CPU_TXQ_ACCESS(1) : 0; + + mvreg_write(pp, MVNETA_CPU_MAP(cpu), rxq_map | txq_map); + } /* Reset RX and TX DMAs */ mvreg_write(pp, MVNETA_PORT_RX_RESET, MVNETA_PORT_RX_DMA_RESET); @@ -1025,11 +1383,19 @@ static void mvneta_defaults_set(struct m mvreg_write(pp, MVNETA_PORT_RX_RESET, 0); /* Set Port Acceleration Mode */ - val = MVNETA_ACC_MODE_EXT; + if (pp->bm_priv) + /* HW buffer management + legacy parser */ + val = MVNETA_ACC_MODE_EXT2; + else + /* SW buffer management + legacy parser */ + val = MVNETA_ACC_MODE_EXT1; mvreg_write(pp, MVNETA_ACC_MODE, val); + if (pp->bm_priv) + mvreg_write(pp, MVNETA_BM_ADDRESS, pp->bm_priv->bppi_phys_addr); + /* Update val of portCfg register accordingly with all RxQueue types */ - val = MVNETA_PORT_CONFIG_DEFL_VALUE(rxq_def); + val = MVNETA_PORT_CONFIG_DEFL_VALUE(pp->rxq_def); mvreg_write(pp, MVNETA_PORT_CONFIG, val); val = 0; @@ -1058,26 +1424,7 @@ static void mvneta_defaults_set(struct m val &= ~MVNETA_PHY_POLLING_ENABLE; mvreg_write(pp, MVNETA_UNIT_CONTROL, val); - if (pp->use_inband_status) { - val = mvreg_read(pp, MVNETA_GMAC_AUTONEG_CONFIG); - val &= ~(MVNETA_GMAC_FORCE_LINK_PASS | - MVNETA_GMAC_FORCE_LINK_DOWN | - MVNETA_GMAC_AN_FLOW_CTRL_EN); - val |= MVNETA_GMAC_INBAND_AN_ENABLE | - MVNETA_GMAC_AN_SPEED_EN | - MVNETA_GMAC_AN_DUPLEX_EN; - mvreg_write(pp, MVNETA_GMAC_AUTONEG_CONFIG, val); - val = mvreg_read(pp, MVNETA_GMAC_CLOCK_DIVIDER); - val |= MVNETA_GMAC_1MS_CLOCK_ENABLE; - mvreg_write(pp, MVNETA_GMAC_CLOCK_DIVIDER, val); - } else { - val = mvreg_read(pp, MVNETA_GMAC_AUTONEG_CONFIG); - val &= ~(MVNETA_GMAC_INBAND_AN_ENABLE | - MVNETA_GMAC_AN_SPEED_EN | - MVNETA_GMAC_AN_DUPLEX_EN); - mvreg_write(pp, MVNETA_GMAC_AUTONEG_CONFIG, val); - } - + mvneta_set_autoneg(pp, pp->use_inband_status); mvneta_set_ucast_table(pp, -1); mvneta_set_special_mcast_table(pp, -1); mvneta_set_other_mcast_table(pp, -1); @@ -1413,23 +1760,25 @@ static void mvneta_txq_done(struct mvnet } } -static void *mvneta_frag_alloc(const struct mvneta_port *pp) +void *mvneta_frag_alloc(unsigned int frag_size) { - if (likely(pp->frag_size <= PAGE_SIZE)) - return netdev_alloc_frag(pp->frag_size); + if (likely(frag_size <= PAGE_SIZE)) + return netdev_alloc_frag(frag_size); else - return kmalloc(pp->frag_size, GFP_ATOMIC); + return kmalloc(frag_size, GFP_ATOMIC); } +EXPORT_SYMBOL_GPL(mvneta_frag_alloc); -static void mvneta_frag_free(const struct mvneta_port *pp, void *data) +void mvneta_frag_free(unsigned int frag_size, void *data) { - if (likely(pp->frag_size <= PAGE_SIZE)) + if (likely(frag_size <= PAGE_SIZE)) skb_free_frag(data); else kfree(data); } +EXPORT_SYMBOL_GPL(mvneta_frag_free); -/* Refill processing */ +/* Refill processing for SW buffer management */ static int mvneta_rx_refill(struct mvneta_port *pp, struct mvneta_rx_desc *rx_desc) @@ -1437,7 +1786,7 @@ static int mvneta_rx_refill(struct mvnet dma_addr_t phys_addr; void *data; - data = mvneta_frag_alloc(pp); + data = mvneta_frag_alloc(pp->frag_size); if (!data) return -ENOMEM; @@ -1445,7 +1794,7 @@ static int mvneta_rx_refill(struct mvnet MVNETA_RX_BUF_SIZE(pp->pkt_size), DMA_FROM_DEVICE); if (unlikely(dma_mapping_error(pp->dev->dev.parent, phys_addr))) { - mvneta_frag_free(pp, data); + mvneta_frag_free(pp->frag_size, data); return -ENOMEM; } @@ -1491,22 +1840,156 @@ static void mvneta_rxq_drop_pkts(struct int rx_done, i; rx_done = mvneta_rxq_busy_desc_num_get(pp, rxq); + if (rx_done) + mvneta_rxq_desc_num_update(pp, rxq, rx_done, rx_done); + + if (pp->bm_priv) { + for (i = 0; i < rx_done; i++) { + struct mvneta_rx_desc *rx_desc = + mvneta_rxq_next_desc_get(rxq); + u8 pool_id = MVNETA_RX_GET_BM_POOL_ID(rx_desc); + struct mvneta_bm_pool *bm_pool; + + bm_pool = &pp->bm_priv->bm_pools[pool_id]; + /* Return dropped buffer to the pool */ + mvneta_bm_pool_put_bp(pp->bm_priv, bm_pool, + rx_desc->buf_phys_addr); + } + return; + } + for (i = 0; i < rxq->size; i++) { struct mvneta_rx_desc *rx_desc = rxq->descs + i; void *data = (void *)rx_desc->buf_cookie; dma_unmap_single(pp->dev->dev.parent, rx_desc->buf_phys_addr, MVNETA_RX_BUF_SIZE(pp->pkt_size), DMA_FROM_DEVICE); - mvneta_frag_free(pp, data); + mvneta_frag_free(pp->frag_size, data); } +} - if (rx_done) - mvneta_rxq_desc_num_update(pp, rxq, rx_done, rx_done); +/* Main rx processing when using software buffer management */ +static int mvneta_rx_swbm(struct mvneta_port *pp, int rx_todo, + struct mvneta_rx_queue *rxq) +{ + struct mvneta_pcpu_port *port = this_cpu_ptr(pp->ports); + struct net_device *dev = pp->dev; + int rx_done; + u32 rcvd_pkts = 0; + u32 rcvd_bytes = 0; + + /* Get number of received packets */ + rx_done = mvneta_rxq_busy_desc_num_get(pp, rxq); + + if (rx_todo > rx_done) + rx_todo = rx_done; + + rx_done = 0; + + /* Fairness NAPI loop */ + while (rx_done < rx_todo) { + struct mvneta_rx_desc *rx_desc = mvneta_rxq_next_desc_get(rxq); + struct sk_buff *skb; + unsigned char *data; + dma_addr_t phys_addr; + u32 rx_status, frag_size; + int rx_bytes, err; + + rx_done++; + rx_status = rx_desc->status; + rx_bytes = rx_desc->data_size - (ETH_FCS_LEN + MVNETA_MH_SIZE); + data = (unsigned char *)rx_desc->buf_cookie; + phys_addr = rx_desc->buf_phys_addr; + + if (!mvneta_rxq_desc_is_first_last(rx_status) || + (rx_status & MVNETA_RXD_ERR_SUMMARY)) { +err_drop_frame: + dev->stats.rx_errors++; + mvneta_rx_error(pp, rx_desc); + /* leave the descriptor untouched */ + continue; + } + + if (rx_bytes <= rx_copybreak) { + /* better copy a small frame and not unmap the DMA region */ + skb = netdev_alloc_skb_ip_align(dev, rx_bytes); + if (unlikely(!skb)) + goto err_drop_frame; + + dma_sync_single_range_for_cpu(dev->dev.parent, + rx_desc->buf_phys_addr, + MVNETA_MH_SIZE + NET_SKB_PAD, + rx_bytes, + DMA_FROM_DEVICE); + memcpy(skb_put(skb, rx_bytes), + data + MVNETA_MH_SIZE + NET_SKB_PAD, + rx_bytes); + + skb->protocol = eth_type_trans(skb, dev); + mvneta_rx_csum(pp, rx_status, skb); + napi_gro_receive(&port->napi, skb); + + rcvd_pkts++; + rcvd_bytes += rx_bytes; + + /* leave the descriptor and buffer untouched */ + continue; + } + + /* Refill processing */ + err = mvneta_rx_refill(pp, rx_desc); + if (err) { + netdev_err(dev, "Linux processing - Can't refill\n"); + rxq->missed++; + goto err_drop_frame; + } + + frag_size = pp->frag_size; + + skb = build_skb(data, frag_size > PAGE_SIZE ? 0 : frag_size); + + /* After refill old buffer has to be unmapped regardless + * the skb is successfully built or not. + */ + dma_unmap_single(dev->dev.parent, phys_addr, + MVNETA_RX_BUF_SIZE(pp->pkt_size), + DMA_FROM_DEVICE); + + if (!skb) + goto err_drop_frame; + + rcvd_pkts++; + rcvd_bytes += rx_bytes; + + /* Linux processing */ + skb_reserve(skb, MVNETA_MH_SIZE + NET_SKB_PAD); + skb_put(skb, rx_bytes); + + skb->protocol = eth_type_trans(skb, dev); + + mvneta_rx_csum(pp, rx_status, skb); + + napi_gro_receive(&port->napi, skb); + } + + if (rcvd_pkts) { + struct mvneta_pcpu_stats *stats = this_cpu_ptr(pp->stats); + + u64_stats_update_begin(&stats->syncp); + stats->rx_packets += rcvd_pkts; + stats->rx_bytes += rcvd_bytes; + u64_stats_update_end(&stats->syncp); + } + + /* Update rxq management counters */ + mvneta_rxq_desc_num_update(pp, rxq, rx_done, rx_done); + + return rx_done; } -/* Main rx processing */ -static int mvneta_rx(struct mvneta_port *pp, int rx_todo, - struct mvneta_rx_queue *rxq) +/* Main rx processing when using hardware buffer management */ +static int mvneta_rx_hwbm(struct mvneta_port *pp, int rx_todo, + struct mvneta_rx_queue *rxq) { struct mvneta_pcpu_port *port = this_cpu_ptr(pp->ports); struct net_device *dev = pp->dev; @@ -1525,21 +2008,29 @@ static int mvneta_rx(struct mvneta_port /* Fairness NAPI loop */ while (rx_done < rx_todo) { struct mvneta_rx_desc *rx_desc = mvneta_rxq_next_desc_get(rxq); + struct mvneta_bm_pool *bm_pool = NULL; struct sk_buff *skb; unsigned char *data; dma_addr_t phys_addr; - u32 rx_status; + u32 rx_status, frag_size; int rx_bytes, err; + u8 pool_id; rx_done++; rx_status = rx_desc->status; rx_bytes = rx_desc->data_size - (ETH_FCS_LEN + MVNETA_MH_SIZE); data = (unsigned char *)rx_desc->buf_cookie; phys_addr = rx_desc->buf_phys_addr; + pool_id = MVNETA_RX_GET_BM_POOL_ID(rx_desc); + bm_pool = &pp->bm_priv->bm_pools[pool_id]; if (!mvneta_rxq_desc_is_first_last(rx_status) || (rx_status & MVNETA_RXD_ERR_SUMMARY)) { - err_drop_frame: +err_drop_frame_ret_pool: + /* Return the buffer to the pool */ + mvneta_bm_pool_put_bp(pp->bm_priv, bm_pool, + rx_desc->buf_phys_addr); +err_drop_frame: dev->stats.rx_errors++; mvneta_rx_error(pp, rx_desc); /* leave the descriptor untouched */ @@ -1550,7 +2041,7 @@ static int mvneta_rx(struct mvneta_port /* better copy a small frame and not unmap the DMA region */ skb = netdev_alloc_skb_ip_align(dev, rx_bytes); if (unlikely(!skb)) - goto err_drop_frame; + goto err_drop_frame_ret_pool; dma_sync_single_range_for_cpu(dev->dev.parent, rx_desc->buf_phys_addr, @@ -1568,26 +2059,31 @@ static int mvneta_rx(struct mvneta_port rcvd_pkts++; rcvd_bytes += rx_bytes; + /* Return the buffer to the pool */ + mvneta_bm_pool_put_bp(pp->bm_priv, bm_pool, + rx_desc->buf_phys_addr); + /* leave the descriptor and buffer untouched */ continue; } /* Refill processing */ - err = mvneta_rx_refill(pp, rx_desc); + err = hwbm_pool_refill(&bm_pool->hwbm_pool, GFP_ATOMIC); if (err) { netdev_err(dev, "Linux processing - Can't refill\n"); rxq->missed++; - goto err_drop_frame; + goto err_drop_frame_ret_pool; } - skb = build_skb(data, pp->frag_size > PAGE_SIZE ? 0 : pp->frag_size); + frag_size = bm_pool->hwbm_pool.frag_size; + + skb = build_skb(data, frag_size > PAGE_SIZE ? 0 : frag_size); /* After refill old buffer has to be unmapped regardless * the skb is successfully built or not. */ - dma_unmap_single(dev->dev.parent, phys_addr, - MVNETA_RX_BUF_SIZE(pp->pkt_size), DMA_FROM_DEVICE); - + dma_unmap_single(&pp->bm_priv->pdev->dev, phys_addr, + bm_pool->buf_size, DMA_FROM_DEVICE); if (!skb) goto err_drop_frame; @@ -2082,19 +2578,19 @@ static void mvneta_set_rx_mode(struct ne if (dev->flags & IFF_PROMISC) { /* Accept all: Multicast + Unicast */ mvneta_rx_unicast_promisc_set(pp, 1); - mvneta_set_ucast_table(pp, rxq_def); - mvneta_set_special_mcast_table(pp, rxq_def); - mvneta_set_other_mcast_table(pp, rxq_def); + mvneta_set_ucast_table(pp, pp->rxq_def); + mvneta_set_special_mcast_table(pp, pp->rxq_def); + mvneta_set_other_mcast_table(pp, pp->rxq_def); } else { /* Accept single Unicast */ mvneta_rx_unicast_promisc_set(pp, 0); mvneta_set_ucast_table(pp, -1); - mvneta_mac_addr_set(pp, dev->dev_addr, rxq_def); + mvneta_mac_addr_set(pp, dev->dev_addr, pp->rxq_def); if (dev->flags & IFF_ALLMULTI) { /* Accept all multicast */ - mvneta_set_special_mcast_table(pp, rxq_def); - mvneta_set_other_mcast_table(pp, rxq_def); + mvneta_set_special_mcast_table(pp, pp->rxq_def); + mvneta_set_other_mcast_table(pp, pp->rxq_def); } else { /* Accept only initialized multicast */ mvneta_set_special_mcast_table(pp, -1); @@ -2103,7 +2599,7 @@ static void mvneta_set_rx_mode(struct ne if (!netdev_mc_empty(dev)) { netdev_for_each_mc_addr(ha, dev) { mvneta_mcast_addr_set(pp, ha->addr, - rxq_def); + pp->rxq_def); } } } @@ -2154,6 +2650,7 @@ static int mvneta_poll(struct napi_struc { int rx_done = 0; u32 cause_rx_tx; + int rx_queue; struct mvneta_port *pp = netdev_priv(napi->dev); struct mvneta_pcpu_port *port = this_cpu_ptr(pp->ports); @@ -2185,8 +2682,18 @@ static int mvneta_poll(struct napi_struc /* For the case where the last mvneta_poll did not process all * RX packets */ + rx_queue = fls(((cause_rx_tx >> 8) & 0xff)); + cause_rx_tx |= port->cause_rx_tx; - rx_done = mvneta_rx(pp, budget, &pp->rxqs[rxq_def]); + + if (rx_queue) { + rx_queue = rx_queue - 1; + if (pp->bm_priv) + rx_done = mvneta_rx_hwbm(pp, budget, &pp->rxqs[rx_queue]); + else + rx_done = mvneta_rx_swbm(pp, budget, &pp->rxqs[rx_queue]); + } + budget -= rx_done; if (budget > 0) { @@ -2273,9 +2780,17 @@ static int mvneta_rxq_init(struct mvneta mvneta_rx_pkts_coal_set(pp, rxq, rxq->pkts_coal); mvneta_rx_time_coal_set(pp, rxq, rxq->time_coal); - /* Fill RXQ with buffers from RX pool */ - mvneta_rxq_buf_size_set(pp, rxq, MVNETA_RX_BUF_SIZE(pp->pkt_size)); - mvneta_rxq_bm_disable(pp, rxq); + if (!pp->bm_priv) { + /* Fill RXQ with buffers from RX pool */ + mvneta_rxq_buf_size_set(pp, rxq, + MVNETA_RX_BUF_SIZE(pp->pkt_size)); + mvneta_rxq_bm_disable(pp, rxq); + } else { + mvneta_rxq_bm_enable(pp, rxq); + mvneta_rxq_long_pool_set(pp, rxq); + mvneta_rxq_short_pool_set(pp, rxq); + } + mvneta_rxq_fill(pp, rxq, rxq->size); return 0; @@ -2303,6 +2818,8 @@ static void mvneta_rxq_deinit(struct mvn static int mvneta_txq_init(struct mvneta_port *pp, struct mvneta_tx_queue *txq) { + int cpu; + txq->size = pp->tx_ring_size; /* A queue must always have room for at least one skb. @@ -2355,6 +2872,14 @@ static int mvneta_txq_init(struct mvneta } mvneta_tx_done_pkts_coal_set(pp, txq, txq->done_pkts_coal); + /* Setup XPS mapping */ + if (txq_number > 1) + cpu = txq->id % num_present_cpus(); + else + cpu = pp->rxq_def % num_present_cpus(); + cpumask_set_cpu(cpu, &txq->affinity_mask); + netif_set_xps_queue(pp->dev, &txq->affinity_mask, txq->id); + return 0; } @@ -2399,19 +2924,27 @@ static void mvneta_cleanup_txqs(struct m /* Cleanup all Rx queues */ static void mvneta_cleanup_rxqs(struct mvneta_port *pp) { - mvneta_rxq_deinit(pp, &pp->rxqs[rxq_def]); + int queue; + + for (queue = 0; queue < txq_number; queue++) + mvneta_rxq_deinit(pp, &pp->rxqs[queue]); } /* Init all Rx queues */ static int mvneta_setup_rxqs(struct mvneta_port *pp) { - int err = mvneta_rxq_init(pp, &pp->rxqs[rxq_def]); - if (err) { - netdev_err(pp->dev, "%s: can't create rxq=%d\n", - __func__, rxq_def); - mvneta_cleanup_rxqs(pp); - return err; + int queue; + + for (queue = 0; queue < rxq_number; queue++) { + int err = mvneta_rxq_init(pp, &pp->rxqs[queue]); + + if (err) { + netdev_err(pp->dev, "%s: can't create rxq=%d\n", + __func__, queue); + mvneta_cleanup_rxqs(pp); + return err; + } } return 0; @@ -2437,7 +2970,7 @@ static int mvneta_setup_txqs(struct mvne static void mvneta_start_dev(struct mvneta_port *pp) { - unsigned int cpu; + int cpu; mvneta_max_rx_size_set(pp, pp->pkt_size); mvneta_txq_max_tx_size_set(pp, pp->pkt_size); @@ -2446,17 +2979,15 @@ static void mvneta_start_dev(struct mvne mvneta_port_enable(pp); /* Enable polling on the port */ - for_each_present_cpu(cpu) { + for_each_online_cpu(cpu) { struct mvneta_pcpu_port *port = per_cpu_ptr(pp->ports, cpu); napi_enable(&port->napi); } - /* Unmask interrupts */ - mvreg_write(pp, MVNETA_INTR_NEW_MASK, - MVNETA_RX_INTR_MASK(rxq_number) | - MVNETA_TX_INTR_MASK(txq_number) | - MVNETA_MISCINTR_INTR_MASK); + /* Unmask interrupts. It has to be done from each CPU */ + on_each_cpu(mvneta_percpu_unmask_interrupt, pp, true); + mvreg_write(pp, MVNETA_INTR_MISC_MASK, MVNETA_CAUSE_PHY_STATUS_CHANGE | MVNETA_CAUSE_LINK_CHANGE | @@ -2472,7 +3003,7 @@ static void mvneta_stop_dev(struct mvnet phy_stop(pp->phy_dev); - for_each_present_cpu(cpu) { + for_each_online_cpu(cpu) { struct mvneta_pcpu_port *port = per_cpu_ptr(pp->ports, cpu); napi_disable(&port->napi); @@ -2487,13 +3018,10 @@ static void mvneta_stop_dev(struct mvnet mvneta_port_disable(pp); /* Clear all ethernet port interrupts */ - mvreg_write(pp, MVNETA_INTR_MISC_CAUSE, 0); - mvreg_write(pp, MVNETA_INTR_OLD_CAUSE, 0); + on_each_cpu(mvneta_percpu_clear_intr_cause, pp, true); /* Mask all ethernet port interrupts */ - mvreg_write(pp, MVNETA_INTR_NEW_MASK, 0); - mvreg_write(pp, MVNETA_INTR_OLD_MASK, 0); - mvreg_write(pp, MVNETA_INTR_MISC_MASK, 0); + on_each_cpu(mvneta_percpu_mask_interrupt, pp, true); mvneta_tx_reset(pp); mvneta_rx_reset(pp); @@ -2535,6 +3063,9 @@ static int mvneta_change_mtu(struct net_ dev->mtu = mtu; if (!netif_running(dev)) { + if (pp->bm_priv) + mvneta_bm_update_mtu(pp, mtu); + netdev_update_features(dev); return 0; } @@ -2547,6 +3078,9 @@ static int mvneta_change_mtu(struct net_ mvneta_cleanup_txqs(pp); mvneta_cleanup_rxqs(pp); + if (pp->bm_priv) + mvneta_bm_update_mtu(pp, mtu); + pp->pkt_size = MVNETA_RX_PKT_SIZE(dev->mtu); pp->frag_size = SKB_DATA_ALIGN(MVNETA_RX_BUF_SIZE(pp->pkt_size)) + SKB_DATA_ALIGN(sizeof(struct skb_shared_info)); @@ -2615,7 +3149,7 @@ static int mvneta_set_mac_addr(struct ne mvneta_mac_addr_set(pp, dev->dev_addr, -1); /* Set new addr in hw */ - mvneta_mac_addr_set(pp, sockaddr->sa_data, rxq_def); + mvneta_mac_addr_set(pp, sockaddr->sa_data, pp->rxq_def); eth_commit_mac_addr_change(dev, addr); return 0; @@ -2730,24 +3264,56 @@ static void mvneta_percpu_disable(void * disable_percpu_irq(pp->dev->irq); } +/* Electing a CPU must be done in an atomic way: it should be done + * after or before the removal/insertion of a CPU and this function is + * not reentrant. + */ static void mvneta_percpu_elect(struct mvneta_port *pp) { - int online_cpu_idx, cpu, i = 0; + int elected_cpu = 0, max_cpu, cpu, i = 0; - online_cpu_idx = rxq_def % num_online_cpus(); + /* Use the cpu associated to the rxq when it is online, in all + * the other cases, use the cpu 0 which can't be offline. + */ + if (cpu_online(pp->rxq_def)) + elected_cpu = pp->rxq_def; + + max_cpu = num_present_cpus(); for_each_online_cpu(cpu) { - if (i == online_cpu_idx) - /* Enable per-CPU interrupt on the one CPU we - * just elected + int rxq_map = 0, txq_map = 0; + int rxq; + + for (rxq = 0; rxq < rxq_number; rxq++) + if ((rxq % max_cpu) == cpu) + rxq_map |= MVNETA_CPU_RXQ_ACCESS(rxq); + + if (cpu == elected_cpu) + /* Map the default receive queue queue to the + * elected CPU */ - smp_call_function_single(cpu, mvneta_percpu_enable, - pp, true); + rxq_map |= MVNETA_CPU_RXQ_ACCESS(pp->rxq_def); + + /* We update the TX queue map only if we have one + * queue. In this case we associate the TX queue to + * the CPU bound to the default RX queue + */ + if (txq_number == 1) + txq_map = (cpu == elected_cpu) ? + MVNETA_CPU_TXQ_ACCESS(1) : 0; else - /* Disable per-CPU interrupt on all the other CPU */ - smp_call_function_single(cpu, mvneta_percpu_disable, - pp, true); + txq_map = mvreg_read(pp, MVNETA_CPU_MAP(cpu)) & + MVNETA_CPU_TXQ_ACCESS_ALL_MASK; + + mvreg_write(pp, MVNETA_CPU_MAP(cpu), rxq_map | txq_map); + + /* Update the interrupt mask on each CPU according the + * new mapping + */ + smp_call_function_single(cpu, mvneta_percpu_unmask_interrupt, + pp, true); i++; + } }; @@ -2762,6 +3328,14 @@ static int mvneta_percpu_notifier(struct switch (action) { case CPU_ONLINE: case CPU_ONLINE_FROZEN: + spin_lock(&pp->lock); + /* Configuring the driver for a new CPU while the + * driver is stopping is racy, so just avoid it. + */ + if (pp->is_stopped) { + spin_unlock(&pp->lock); + break; + } netif_tx_stop_all_queues(pp->dev); /* We have to synchronise on tha napi of each CPU @@ -2777,34 +3351,40 @@ static int mvneta_percpu_notifier(struct } /* Mask all ethernet port interrupts */ - mvreg_write(pp, MVNETA_INTR_NEW_MASK, 0); - mvreg_write(pp, MVNETA_INTR_OLD_MASK, 0); - mvreg_write(pp, MVNETA_INTR_MISC_MASK, 0); + on_each_cpu(mvneta_percpu_mask_interrupt, pp, true); napi_enable(&port->napi); + + /* Enable per-CPU interrupts on the CPU that is + * brought up. + */ + smp_call_function_single(cpu, mvneta_percpu_enable, + pp, true); + /* Enable per-CPU interrupt on the one CPU we care * about. */ mvneta_percpu_elect(pp); /* Unmask all ethernet port interrupts */ - mvreg_write(pp, MVNETA_INTR_NEW_MASK, - MVNETA_RX_INTR_MASK(rxq_number) | - MVNETA_TX_INTR_MASK(txq_number) | - MVNETA_MISCINTR_INTR_MASK); + on_each_cpu(mvneta_percpu_unmask_interrupt, pp, true); mvreg_write(pp, MVNETA_INTR_MISC_MASK, MVNETA_CAUSE_PHY_STATUS_CHANGE | MVNETA_CAUSE_LINK_CHANGE | MVNETA_CAUSE_PSC_SYNC_CHANGE); netif_tx_start_all_queues(pp->dev); + spin_unlock(&pp->lock); break; case CPU_DOWN_PREPARE: case CPU_DOWN_PREPARE_FROZEN: netif_tx_stop_all_queues(pp->dev); + /* Thanks to this lock we are sure that any pending + * cpu election is done + */ + spin_lock(&pp->lock); /* Mask all ethernet port interrupts */ - mvreg_write(pp, MVNETA_INTR_NEW_MASK, 0); - mvreg_write(pp, MVNETA_INTR_OLD_MASK, 0); - mvreg_write(pp, MVNETA_INTR_MISC_MASK, 0); + on_each_cpu(mvneta_percpu_mask_interrupt, pp, true); + spin_unlock(&pp->lock); napi_synchronize(&port->napi); napi_disable(&port->napi); @@ -2818,12 +3398,11 @@ static int mvneta_percpu_notifier(struct case CPU_DEAD: case CPU_DEAD_FROZEN: /* Check if a new CPU must be elected now this on is down */ + spin_lock(&pp->lock); mvneta_percpu_elect(pp); + spin_unlock(&pp->lock); /* Unmask all ethernet port interrupts */ - mvreg_write(pp, MVNETA_INTR_NEW_MASK, - MVNETA_RX_INTR_MASK(rxq_number) | - MVNETA_TX_INTR_MASK(txq_number) | - MVNETA_MISCINTR_INTR_MASK); + on_each_cpu(mvneta_percpu_unmask_interrupt, pp, true); mvreg_write(pp, MVNETA_INTR_MISC_MASK, MVNETA_CAUSE_PHY_STATUS_CHANGE | MVNETA_CAUSE_LINK_CHANGE | @@ -2860,17 +3439,12 @@ static int mvneta_open(struct net_device goto err_cleanup_txqs; } - /* Even though the documentation says that request_percpu_irq - * doesn't enable the interrupts automatically, it actually - * does so on the local CPU. - * - * Make sure it's disabled. + /* Enable per-CPU interrupt on all the CPU to handle our RX + * queue interrupts */ - mvneta_percpu_disable(pp); - - /* Elect a CPU to handle our RX queue interrupt */ - mvneta_percpu_elect(pp); + on_each_cpu(mvneta_percpu_enable, pp, true); + pp->is_stopped = false; /* Register a CPU notifier to handle the case where our CPU * might be taken offline. */ @@ -2902,13 +3476,20 @@ err_cleanup_rxqs: static int mvneta_stop(struct net_device *dev) { struct mvneta_port *pp = netdev_priv(dev); - int cpu; + /* Inform that we are stopping so we don't want to setup the + * driver for new CPUs in the notifiers + */ + spin_lock(&pp->lock); + pp->is_stopped = true; mvneta_stop_dev(pp); mvneta_mdio_remove(pp); unregister_cpu_notifier(&pp->cpu_notifier); - for_each_present_cpu(cpu) - smp_call_function_single(cpu, mvneta_percpu_disable, pp, true); + /* Now that the notifier are unregistered, we can release le + * lock + */ + spin_unlock(&pp->lock); + on_each_cpu(mvneta_percpu_disable, pp, true); free_percpu_irq(dev->irq, pp->ports); mvneta_cleanup_rxqs(pp); mvneta_cleanup_txqs(pp); @@ -2943,10 +3524,43 @@ int mvneta_ethtool_get_settings(struct n int mvneta_ethtool_set_settings(struct net_device *dev, struct ethtool_cmd *cmd) { struct mvneta_port *pp = netdev_priv(dev); + struct phy_device *phydev = pp->phy_dev; - if (!pp->phy_dev) + if (!phydev) return -ENODEV; + if ((cmd->autoneg == AUTONEG_ENABLE) != pp->use_inband_status) { + u32 val; + + mvneta_set_autoneg(pp, cmd->autoneg == AUTONEG_ENABLE); + + if (cmd->autoneg == AUTONEG_DISABLE) { + val = mvreg_read(pp, MVNETA_GMAC_AUTONEG_CONFIG); + val &= ~(MVNETA_GMAC_CONFIG_MII_SPEED | + MVNETA_GMAC_CONFIG_GMII_SPEED | + MVNETA_GMAC_CONFIG_FULL_DUPLEX); + + if (phydev->duplex) + val |= MVNETA_GMAC_CONFIG_FULL_DUPLEX; + + if (phydev->speed == SPEED_1000) + val |= MVNETA_GMAC_CONFIG_GMII_SPEED; + else if (phydev->speed == SPEED_100) + val |= MVNETA_GMAC_CONFIG_MII_SPEED; + + mvreg_write(pp, MVNETA_GMAC_AUTONEG_CONFIG, val); + } + + pp->use_inband_status = (cmd->autoneg == AUTONEG_ENABLE); + netdev_info(pp->dev, "autoneg status set to %i\n", + pp->use_inband_status); + + if (netif_running(dev)) { + mvneta_port_down(pp); + mvneta_port_up(pp); + } + } + return phy_ethtool_sset(pp->phy_dev, cmd); } @@ -3056,26 +3670,25 @@ static void mvneta_ethtool_update_stats( const struct mvneta_statistic *s; void __iomem *base = pp->base; u32 high, low, val; + u64 val64; int i; for (i = 0, s = mvneta_statistics; s < mvneta_statistics + ARRAY_SIZE(mvneta_statistics); s++, i++) { - val = 0; - switch (s->type) { case T_REG_32: val = readl_relaxed(base + s->offset); + pp->ethtool_stats[i] += val; break; case T_REG_64: /* Docs say to read low 32-bit then high */ low = readl_relaxed(base + s->offset); high = readl_relaxed(base + s->offset + 4); - val = (u64)high << 32 | low; + val64 = (u64)high << 32 | low; + pp->ethtool_stats[i] += val64; break; } - - pp->ethtool_stats[i] += val; } } @@ -3098,6 +3711,106 @@ static int mvneta_ethtool_get_sset_count return -EOPNOTSUPP; } +static u32 mvneta_ethtool_get_rxfh_indir_size(struct net_device *dev) +{ + return MVNETA_RSS_LU_TABLE_SIZE; +} + +static int mvneta_ethtool_get_rxnfc(struct net_device *dev, + struct ethtool_rxnfc *info, + u32 *rules __always_unused) +{ + switch (info->cmd) { + case ETHTOOL_GRXRINGS: + info->data = rxq_number; + return 0; + case ETHTOOL_GRXFH: + return -EOPNOTSUPP; + default: + return -EOPNOTSUPP; + } +} + +static int mvneta_config_rss(struct mvneta_port *pp) +{ + int cpu; + u32 val; + + netif_tx_stop_all_queues(pp->dev); + + on_each_cpu(mvneta_percpu_mask_interrupt, pp, true); + + /* We have to synchronise on the napi of each CPU */ + for_each_online_cpu(cpu) { + struct mvneta_pcpu_port *pcpu_port = + per_cpu_ptr(pp->ports, cpu); + + napi_synchronize(&pcpu_port->napi); + napi_disable(&pcpu_port->napi); + } + + pp->rxq_def = pp->indir[0]; + + /* Update unicast mapping */ + mvneta_set_rx_mode(pp->dev); + + /* Update val of portCfg register accordingly with all RxQueue types */ + val = MVNETA_PORT_CONFIG_DEFL_VALUE(pp->rxq_def); + mvreg_write(pp, MVNETA_PORT_CONFIG, val); + + /* Update the elected CPU matching the new rxq_def */ + spin_lock(&pp->lock); + mvneta_percpu_elect(pp); + spin_unlock(&pp->lock); + + /* We have to synchronise on the napi of each CPU */ + for_each_online_cpu(cpu) { + struct mvneta_pcpu_port *pcpu_port = + per_cpu_ptr(pp->ports, cpu); + + napi_enable(&pcpu_port->napi); + } + + netif_tx_start_all_queues(pp->dev); + + return 0; +} + +static int mvneta_ethtool_set_rxfh(struct net_device *dev, const u32 *indir, + const u8 *key, const u8 hfunc) +{ + struct mvneta_port *pp = netdev_priv(dev); + /* We require at least one supported parameter to be changed + * and no change in any of the unsupported parameters + */ + if (key || + (hfunc != ETH_RSS_HASH_NO_CHANGE && hfunc != ETH_RSS_HASH_TOP)) + return -EOPNOTSUPP; + + if (!indir) + return 0; + + memcpy(pp->indir, indir, MVNETA_RSS_LU_TABLE_SIZE); + + return mvneta_config_rss(pp); +} + +static int mvneta_ethtool_get_rxfh(struct net_device *dev, u32 *indir, u8 *key, + u8 *hfunc) +{ + struct mvneta_port *pp = netdev_priv(dev); + + if (hfunc) + *hfunc = ETH_RSS_HASH_TOP; + + if (!indir) + return 0; + + memcpy(indir, pp->indir, MVNETA_RSS_LU_TABLE_SIZE); + + return 0; +} + static const struct net_device_ops mvneta_netdev_ops = { .ndo_open = mvneta_open, .ndo_stop = mvneta_stop, @@ -3122,6 +3835,10 @@ const struct ethtool_ops mvneta_eth_tool .get_strings = mvneta_ethtool_get_strings, .get_ethtool_stats = mvneta_ethtool_get_stats, .get_sset_count = mvneta_ethtool_get_sset_count, + .get_rxfh_indir_size = mvneta_ethtool_get_rxfh_indir_size, + .get_rxnfc = mvneta_ethtool_get_rxnfc, + .get_rxfh = mvneta_ethtool_get_rxfh, + .set_rxfh = mvneta_ethtool_set_rxfh, }; /* Initialize hw */ @@ -3230,9 +3947,6 @@ static int mvneta_port_power_up(struct m return -EINVAL; } - if (pp->use_inband_status) - ctrl |= MVNETA_GMAC2_INBAND_AN_ENABLE; - /* Cancel Port Reset */ ctrl &= ~MVNETA_GMAC2_PORT_RESET; mvreg_write(pp, MVNETA_GMAC_CTRL_2, ctrl); @@ -3251,6 +3965,7 @@ static int mvneta_probe(struct platform_ struct resource *res; struct device_node *dn = pdev->dev.of_node; struct device_node *phy_node; + struct device_node *bm_node; struct mvneta_port *pp; struct net_device *dev; const char *dt_mac_addr; @@ -3314,7 +4029,13 @@ static int mvneta_probe(struct platform_ strcmp(managed, "in-band-status") == 0); pp->cpu_notifier.notifier_call = mvneta_percpu_notifier; - pp->clk = devm_clk_get(&pdev->dev, NULL); + pp->rxq_def = rxq_def; + + pp->indir[0] = rxq_def; + + pp->clk = devm_clk_get(&pdev->dev, "core"); + if (IS_ERR(pp->clk)) + pp->clk = devm_clk_get(&pdev->dev, NULL); if (IS_ERR(pp->clk)) { err = PTR_ERR(pp->clk); goto err_put_phy_node; @@ -3322,6 +4043,10 @@ static int mvneta_probe(struct platform_ clk_prepare_enable(pp->clk); + pp->clk_bus = devm_clk_get(&pdev->dev, "bus"); + if (!IS_ERR(pp->clk_bus)) + clk_prepare_enable(pp->clk_bus); + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); pp->base = devm_ioremap_resource(&pdev->dev, res); if (IS_ERR(pp->base)) { @@ -3374,26 +4099,39 @@ static int mvneta_probe(struct platform_ pp->tx_csum_limit = tx_csum_limit; + dram_target_info = mv_mbus_dram_info(); + if (dram_target_info) + mvneta_conf_mbus_windows(pp, dram_target_info); + pp->tx_ring_size = MVNETA_MAX_TXD; pp->rx_ring_size = MVNETA_MAX_RXD; pp->dev = dev; SET_NETDEV_DEV(dev, &pdev->dev); + pp->id = global_port_id++; + + /* Obtain access to BM resources if enabled and already initialized */ + bm_node = of_parse_phandle(dn, "buffer-manager", 0); + if (bm_node && bm_node->data) { + pp->bm_priv = bm_node->data; + err = mvneta_bm_port_init(pdev, pp); + if (err < 0) { + dev_info(&pdev->dev, "use SW buffer management\n"); + pp->bm_priv = NULL; + } + } + err = mvneta_init(&pdev->dev, pp); if (err < 0) - goto err_free_stats; + goto err_netdev; err = mvneta_port_power_up(pp, phy_mode); if (err < 0) { dev_err(&pdev->dev, "can't power up port\n"); - goto err_free_stats; + goto err_netdev; } - dram_target_info = mv_mbus_dram_info(); - if (dram_target_info) - mvneta_conf_mbus_windows(pp, dram_target_info); - for_each_present_cpu(cpu) { struct mvneta_pcpu_port *port = per_cpu_ptr(pp->ports, cpu); @@ -3423,16 +4161,24 @@ static int mvneta_probe(struct platform_ mvneta_fixed_link_update(pp, phy); - put_device(&phy->dev); + put_device(&phy->dev); } return 0; +err_netdev: + unregister_netdev(dev); + if (pp->bm_priv) { + mvneta_bm_pool_destroy(pp->bm_priv, pp->pool_long, 1 << pp->id); + mvneta_bm_pool_destroy(pp->bm_priv, pp->pool_short, + 1 << pp->id); + } err_free_stats: free_percpu(pp->stats); err_free_ports: free_percpu(pp->ports); err_clk: + clk_disable_unprepare(pp->clk_bus); clk_disable_unprepare(pp->clk); err_put_phy_node: of_node_put(phy_node); @@ -3450,6 +4196,7 @@ static int mvneta_remove(struct platform struct mvneta_port *pp = netdev_priv(dev); unregister_netdev(dev); + clk_disable_unprepare(pp->clk_bus); clk_disable_unprepare(pp->clk); free_percpu(pp->ports); free_percpu(pp->stats); @@ -3457,6 +4204,12 @@ static int mvneta_remove(struct platform of_node_put(pp->phy_node); free_netdev(dev); + if (pp->bm_priv) { + mvneta_bm_pool_destroy(pp->bm_priv, pp->pool_long, 1 << pp->id); + mvneta_bm_pool_destroy(pp->bm_priv, pp->pool_short, + 1 << pp->id); + } + return 0; } --- a/dev/null +++ b/drivers/net/ethernet/marvell/mvneta_bm.c @@ -0,0 +1,487 @@ +/* + * Driver for Marvell NETA network controller Buffer Manager. + * + * Copyright (C) 2015 Marvell + * + * Marcin Wojtas + * + * This file is licensed under the terms of the GNU General Public + * License version 2. This program is licensed "as is" without any + * warranty of any kind, whether express or implied. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include "mvneta_bm.h" + +#define MVNETA_BM_DRIVER_NAME "mvneta_bm" +#define MVNETA_BM_DRIVER_VERSION "1.0" + +static void mvneta_bm_write(struct mvneta_bm *priv, u32 offset, u32 data) +{ + writel(data, priv->reg_base + offset); +} + +static u32 mvneta_bm_read(struct mvneta_bm *priv, u32 offset) +{ + return readl(priv->reg_base + offset); +} + +static void mvneta_bm_pool_enable(struct mvneta_bm *priv, int pool_id) +{ + u32 val; + + val = mvneta_bm_read(priv, MVNETA_BM_POOL_BASE_REG(pool_id)); + val |= MVNETA_BM_POOL_ENABLE_MASK; + mvneta_bm_write(priv, MVNETA_BM_POOL_BASE_REG(pool_id), val); + + /* Clear BM cause register */ + mvneta_bm_write(priv, MVNETA_BM_INTR_CAUSE_REG, 0); +} + +static void mvneta_bm_pool_disable(struct mvneta_bm *priv, int pool_id) +{ + u32 val; + + val = mvneta_bm_read(priv, MVNETA_BM_POOL_BASE_REG(pool_id)); + val &= ~MVNETA_BM_POOL_ENABLE_MASK; + mvneta_bm_write(priv, MVNETA_BM_POOL_BASE_REG(pool_id), val); +} + +static inline void mvneta_bm_config_set(struct mvneta_bm *priv, u32 mask) +{ + u32 val; + + val = mvneta_bm_read(priv, MVNETA_BM_CONFIG_REG); + val |= mask; + mvneta_bm_write(priv, MVNETA_BM_CONFIG_REG, val); +} + +static inline void mvneta_bm_config_clear(struct mvneta_bm *priv, u32 mask) +{ + u32 val; + + val = mvneta_bm_read(priv, MVNETA_BM_CONFIG_REG); + val &= ~mask; + mvneta_bm_write(priv, MVNETA_BM_CONFIG_REG, val); +} + +static void mvneta_bm_pool_target_set(struct mvneta_bm *priv, int pool_id, + u8 target_id, u8 attr) +{ + u32 val; + + val = mvneta_bm_read(priv, MVNETA_BM_XBAR_POOL_REG(pool_id)); + val &= ~MVNETA_BM_TARGET_ID_MASK(pool_id); + val &= ~MVNETA_BM_XBAR_ATTR_MASK(pool_id); + val |= MVNETA_BM_TARGET_ID_VAL(pool_id, target_id); + val |= MVNETA_BM_XBAR_ATTR_VAL(pool_id, attr); + + mvneta_bm_write(priv, MVNETA_BM_XBAR_POOL_REG(pool_id), val); +} + +int mvneta_bm_construct(struct hwbm_pool *hwbm_pool, void *buf) +{ + struct mvneta_bm_pool *bm_pool = + (struct mvneta_bm_pool *)hwbm_pool->priv; + struct mvneta_bm *priv = bm_pool->priv; + dma_addr_t phys_addr; + + /* In order to update buf_cookie field of RX descriptor properly, + * BM hardware expects buf virtual address to be placed in the + * first four bytes of mapped buffer. + */ + *(u32 *)buf = (u32)buf; + phys_addr = dma_map_single(&priv->pdev->dev, buf, bm_pool->buf_size, + DMA_FROM_DEVICE); + if (unlikely(dma_mapping_error(&priv->pdev->dev, phys_addr))) + return -ENOMEM; + + mvneta_bm_pool_put_bp(priv, bm_pool, phys_addr); + return 0; +} +EXPORT_SYMBOL_GPL(mvneta_bm_construct); + +/* Create pool */ +static int mvneta_bm_pool_create(struct mvneta_bm *priv, + struct mvneta_bm_pool *bm_pool) +{ + struct platform_device *pdev = priv->pdev; + u8 target_id, attr; + int size_bytes, err; + size_bytes = sizeof(u32) * bm_pool->hwbm_pool.size; + bm_pool->virt_addr = dma_alloc_coherent(&pdev->dev, size_bytes, + &bm_pool->phys_addr, + GFP_KERNEL); + if (!bm_pool->virt_addr) + return -ENOMEM; + + if (!IS_ALIGNED((u32)bm_pool->virt_addr, MVNETA_BM_POOL_PTR_ALIGN)) { + dma_free_coherent(&pdev->dev, size_bytes, bm_pool->virt_addr, + bm_pool->phys_addr); + dev_err(&pdev->dev, "BM pool %d is not %d bytes aligned\n", + bm_pool->id, MVNETA_BM_POOL_PTR_ALIGN); + return -ENOMEM; + } + + err = mvebu_mbus_get_dram_win_info(bm_pool->phys_addr, &target_id, + &attr); + if (err < 0) { + dma_free_coherent(&pdev->dev, size_bytes, bm_pool->virt_addr, + bm_pool->phys_addr); + return err; + } + + /* Set pool address */ + mvneta_bm_write(priv, MVNETA_BM_POOL_BASE_REG(bm_pool->id), + bm_pool->phys_addr); + + mvneta_bm_pool_target_set(priv, bm_pool->id, target_id, attr); + mvneta_bm_pool_enable(priv, bm_pool->id); + + return 0; +} + +/* Notify the driver that BM pool is being used as specific type and return the + * pool pointer on success + */ +struct mvneta_bm_pool *mvneta_bm_pool_use(struct mvneta_bm *priv, u8 pool_id, + enum mvneta_bm_type type, u8 port_id, + int pkt_size) +{ + struct mvneta_bm_pool *new_pool = &priv->bm_pools[pool_id]; + int num, err; + + if (new_pool->type == MVNETA_BM_LONG && + new_pool->port_map != 1 << port_id) { + dev_err(&priv->pdev->dev, + "long pool cannot be shared by the ports\n"); + return NULL; + } + + if (new_pool->type == MVNETA_BM_SHORT && new_pool->type != type) { + dev_err(&priv->pdev->dev, + "mixing pools' types between the ports is forbidden\n"); + return NULL; + } + + if (new_pool->pkt_size == 0 || type != MVNETA_BM_SHORT) + new_pool->pkt_size = pkt_size; + + /* Allocate buffers in case BM pool hasn't been used yet */ + if (new_pool->type == MVNETA_BM_FREE) { + struct hwbm_pool *hwbm_pool = &new_pool->hwbm_pool; + + new_pool->priv = priv; + new_pool->type = type; + new_pool->buf_size = MVNETA_RX_BUF_SIZE(new_pool->pkt_size); + hwbm_pool->frag_size = + SKB_DATA_ALIGN(MVNETA_RX_BUF_SIZE(new_pool->pkt_size)) + + SKB_DATA_ALIGN(sizeof(struct skb_shared_info)); + hwbm_pool->construct = mvneta_bm_construct; + hwbm_pool->priv = new_pool; + + /* Create new pool */ + err = mvneta_bm_pool_create(priv, new_pool); + if (err) { + dev_err(&priv->pdev->dev, "fail to create pool %d\n", + new_pool->id); + return NULL; + } + + /* Allocate buffers for this pool */ + num = hwbm_pool_add(hwbm_pool, hwbm_pool->size, GFP_ATOMIC); + if (num != hwbm_pool->size) { + WARN(1, "pool %d: %d of %d allocated\n", + new_pool->id, num, hwbm_pool->size); + return NULL; + } + } + + return new_pool; +} +EXPORT_SYMBOL_GPL(mvneta_bm_pool_use); + +/* Free all buffers from the pool */ +void mvneta_bm_bufs_free(struct mvneta_bm *priv, struct mvneta_bm_pool *bm_pool, + u8 port_map) +{ + int i; + + bm_pool->port_map &= ~port_map; + if (bm_pool->port_map) + return; + + mvneta_bm_config_set(priv, MVNETA_BM_EMPTY_LIMIT_MASK); + + for (i = 0; i < bm_pool->hwbm_pool.buf_num; i++) { + dma_addr_t buf_phys_addr; + u32 *vaddr; + + /* Get buffer physical address (indirect access) */ + buf_phys_addr = mvneta_bm_pool_get_bp(priv, bm_pool); + + /* Work-around to the problems when destroying the pool, + * when it occurs that a read access to BPPI returns 0. + */ + if (buf_phys_addr == 0) + continue; + + vaddr = phys_to_virt(buf_phys_addr); + if (!vaddr) + break; + + dma_unmap_single(&priv->pdev->dev, buf_phys_addr, + bm_pool->buf_size, DMA_FROM_DEVICE); + hwbm_buf_free(&bm_pool->hwbm_pool, vaddr); + } + + mvneta_bm_config_clear(priv, MVNETA_BM_EMPTY_LIMIT_MASK); + + /* Update BM driver with number of buffers removed from pool */ + bm_pool->hwbm_pool.buf_num -= i; +} +EXPORT_SYMBOL_GPL(mvneta_bm_bufs_free); + +/* Cleanup pool */ +void mvneta_bm_pool_destroy(struct mvneta_bm *priv, + struct mvneta_bm_pool *bm_pool, u8 port_map) +{ + struct hwbm_pool *hwbm_pool = &bm_pool->hwbm_pool; + bm_pool->port_map &= ~port_map; + if (bm_pool->port_map) + return; + + bm_pool->type = MVNETA_BM_FREE; + + mvneta_bm_bufs_free(priv, bm_pool, port_map); + if (hwbm_pool->buf_num) + WARN(1, "cannot free all buffers in pool %d\n", bm_pool->id); + + if (bm_pool->virt_addr) { + dma_free_coherent(&priv->pdev->dev, + sizeof(u32) * hwbm_pool->size, + bm_pool->virt_addr, bm_pool->phys_addr); + bm_pool->virt_addr = NULL; + } + + mvneta_bm_pool_disable(priv, bm_pool->id); +} +EXPORT_SYMBOL_GPL(mvneta_bm_pool_destroy); + +static void mvneta_bm_pools_init(struct mvneta_bm *priv) +{ + struct device_node *dn = priv->pdev->dev.of_node; + struct mvneta_bm_pool *bm_pool; + char prop[15]; + u32 size; + int i; + + /* Activate BM unit */ + mvneta_bm_write(priv, MVNETA_BM_COMMAND_REG, MVNETA_BM_START_MASK); + + /* Create all pools with maximum size */ + for (i = 0; i < MVNETA_BM_POOLS_NUM; i++) { + bm_pool = &priv->bm_pools[i]; + bm_pool->id = i; + bm_pool->type = MVNETA_BM_FREE; + + /* Reset read pointer */ + mvneta_bm_write(priv, MVNETA_BM_POOL_READ_PTR_REG(i), 0); + + /* Reset write pointer */ + mvneta_bm_write(priv, MVNETA_BM_POOL_WRITE_PTR_REG(i), 0); + + /* Configure pool size according to DT or use default value */ + sprintf(prop, "pool%d,capacity", i); + if (of_property_read_u32(dn, prop, &size)) { + size = MVNETA_BM_POOL_CAP_DEF; + } else if (size > MVNETA_BM_POOL_CAP_MAX) { + dev_warn(&priv->pdev->dev, + "Illegal pool %d capacity %d, set to %d\n", + i, size, MVNETA_BM_POOL_CAP_MAX); + size = MVNETA_BM_POOL_CAP_MAX; + } else if (size < MVNETA_BM_POOL_CAP_MIN) { + dev_warn(&priv->pdev->dev, + "Illegal pool %d capacity %d, set to %d\n", + i, size, MVNETA_BM_POOL_CAP_MIN); + size = MVNETA_BM_POOL_CAP_MIN; + } else if (!IS_ALIGNED(size, MVNETA_BM_POOL_CAP_ALIGN)) { + dev_warn(&priv->pdev->dev, + "Illegal pool %d capacity %d, round to %d\n", + i, size, ALIGN(size, + MVNETA_BM_POOL_CAP_ALIGN)); + size = ALIGN(size, MVNETA_BM_POOL_CAP_ALIGN); + } + bm_pool->hwbm_pool.size = size; + + mvneta_bm_write(priv, MVNETA_BM_POOL_SIZE_REG(i), + bm_pool->hwbm_pool.size); + + /* Obtain custom pkt_size from DT */ + sprintf(prop, "pool%d,pkt-size", i); + if (of_property_read_u32(dn, prop, &bm_pool->pkt_size)) + bm_pool->pkt_size = 0; + } +} + +static void mvneta_bm_default_set(struct mvneta_bm *priv) +{ + u32 val; + + /* Mask BM all interrupts */ + mvneta_bm_write(priv, MVNETA_BM_INTR_MASK_REG, 0); + + /* Clear BM cause register */ + mvneta_bm_write(priv, MVNETA_BM_INTR_CAUSE_REG, 0); + + /* Set BM configuration register */ + val = mvneta_bm_read(priv, MVNETA_BM_CONFIG_REG); + + /* Reduce MaxInBurstSize from 32 BPs to 16 BPs */ + val &= ~MVNETA_BM_MAX_IN_BURST_SIZE_MASK; + val |= MVNETA_BM_MAX_IN_BURST_SIZE_16BP; + mvneta_bm_write(priv, MVNETA_BM_CONFIG_REG, val); +} + +static int mvneta_bm_init(struct mvneta_bm *priv) +{ + mvneta_bm_default_set(priv); + + /* Allocate and initialize BM pools structures */ + priv->bm_pools = devm_kcalloc(&priv->pdev->dev, MVNETA_BM_POOLS_NUM, + sizeof(struct mvneta_bm_pool), + GFP_KERNEL); + if (!priv->bm_pools) + return -ENOMEM; + + mvneta_bm_pools_init(priv); + + return 0; +} + +static int mvneta_bm_get_sram(struct device_node *dn, + struct mvneta_bm *priv) +{ + priv->bppi_pool = of_gen_pool_get(dn, "internal-mem", 0); + if (!priv->bppi_pool) + return -ENOMEM; + + priv->bppi_virt_addr = gen_pool_dma_alloc(priv->bppi_pool, + MVNETA_BM_BPPI_SIZE, + &priv->bppi_phys_addr); + if (!priv->bppi_virt_addr) + return -ENOMEM; + + return 0; +} + +static void mvneta_bm_put_sram(struct mvneta_bm *priv) +{ + gen_pool_free(priv->bppi_pool, priv->bppi_phys_addr, + MVNETA_BM_BPPI_SIZE); +} + +static int mvneta_bm_probe(struct platform_device *pdev) +{ + struct device_node *dn = pdev->dev.of_node; + struct mvneta_bm *priv; + struct resource *res; + int err; + + priv = devm_kzalloc(&pdev->dev, sizeof(struct mvneta_bm), GFP_KERNEL); + if (!priv) + return -ENOMEM; + + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + priv->reg_base = devm_ioremap_resource(&pdev->dev, res); + if (IS_ERR(priv->reg_base)) + return PTR_ERR(priv->reg_base); + + priv->clk = devm_clk_get(&pdev->dev, NULL); + if (IS_ERR(priv->clk)) + return PTR_ERR(priv->clk); + err = clk_prepare_enable(priv->clk); + if (err < 0) + return err; + + err = mvneta_bm_get_sram(dn, priv); + if (err < 0) { + dev_err(&pdev->dev, "failed to allocate internal memory\n"); + goto err_clk; + } + + priv->pdev = pdev; + + /* Initialize buffer manager internals */ + err = mvneta_bm_init(priv); + if (err < 0) { + dev_err(&pdev->dev, "failed to initialize controller\n"); + goto err_sram; + } + + dn->data = priv; + platform_set_drvdata(pdev, priv); + + dev_info(&pdev->dev, "Buffer Manager for network controller enabled\n"); + + return 0; + +err_sram: + mvneta_bm_put_sram(priv); +err_clk: + clk_disable_unprepare(priv->clk); + return err; +} + +static int mvneta_bm_remove(struct platform_device *pdev) +{ + struct mvneta_bm *priv = platform_get_drvdata(pdev); + u8 all_ports_map = 0xff; + int i = 0; + + for (i = 0; i < MVNETA_BM_POOLS_NUM; i++) { + struct mvneta_bm_pool *bm_pool = &priv->bm_pools[i]; + + mvneta_bm_pool_destroy(priv, bm_pool, all_ports_map); + } + + mvneta_bm_put_sram(priv); + + /* Dectivate BM unit */ + mvneta_bm_write(priv, MVNETA_BM_COMMAND_REG, MVNETA_BM_STOP_MASK); + + clk_disable_unprepare(priv->clk); + + return 0; +} + +static const struct of_device_id mvneta_bm_match[] = { + { .compatible = "marvell,armada-380-neta-bm" }, + { } +}; +MODULE_DEVICE_TABLE(of, mvneta_bm_match); + +static struct platform_driver mvneta_bm_driver = { + .probe = mvneta_bm_probe, + .remove = mvneta_bm_remove, + .driver = { + .name = MVNETA_BM_DRIVER_NAME, + .of_match_table = mvneta_bm_match, + }, +}; + +module_platform_driver(mvneta_bm_driver); + +MODULE_DESCRIPTION("Marvell NETA Buffer Manager Driver - www.marvell.com"); +MODULE_AUTHOR("Marcin Wojtas "); +MODULE_LICENSE("GPL v2"); --- a/dev/null +++ b/drivers/net/ethernet/marvell/mvneta_bm.h @@ -0,0 +1,182 @@ +/* + * Driver for Marvell NETA network controller Buffer Manager. + * + * Copyright (C) 2015 Marvell + * + * Marcin Wojtas + * + * This file is licensed under the terms of the GNU General Public + * License version 2. This program is licensed "as is" without any + * warranty of any kind, whether express or implied. + */ + +#ifndef _MVNETA_BM_H_ +#define _MVNETA_BM_H_ + +/* BM Configuration Register */ +#define MVNETA_BM_CONFIG_REG 0x0 +#define MVNETA_BM_STATUS_MASK 0x30 +#define MVNETA_BM_ACTIVE_MASK BIT(4) +#define MVNETA_BM_MAX_IN_BURST_SIZE_MASK 0x60000 +#define MVNETA_BM_MAX_IN_BURST_SIZE_16BP BIT(18) +#define MVNETA_BM_EMPTY_LIMIT_MASK BIT(19) + +/* BM Activation Register */ +#define MVNETA_BM_COMMAND_REG 0x4 +#define MVNETA_BM_START_MASK BIT(0) +#define MVNETA_BM_STOP_MASK BIT(1) +#define MVNETA_BM_PAUSE_MASK BIT(2) + +/* BM Xbar interface Register */ +#define MVNETA_BM_XBAR_01_REG 0x8 +#define MVNETA_BM_XBAR_23_REG 0xc +#define MVNETA_BM_XBAR_POOL_REG(pool) \ + (((pool) < 2) ? MVNETA_BM_XBAR_01_REG : MVNETA_BM_XBAR_23_REG) +#define MVNETA_BM_TARGET_ID_OFFS(pool) (((pool) & 1) ? 16 : 0) +#define MVNETA_BM_TARGET_ID_MASK(pool) \ + (0xf << MVNETA_BM_TARGET_ID_OFFS(pool)) +#define MVNETA_BM_TARGET_ID_VAL(pool, id) \ + ((id) << MVNETA_BM_TARGET_ID_OFFS(pool)) +#define MVNETA_BM_XBAR_ATTR_OFFS(pool) (((pool) & 1) ? 20 : 4) +#define MVNETA_BM_XBAR_ATTR_MASK(pool) \ + (0xff << MVNETA_BM_XBAR_ATTR_OFFS(pool)) +#define MVNETA_BM_XBAR_ATTR_VAL(pool, attr) \ + ((attr) << MVNETA_BM_XBAR_ATTR_OFFS(pool)) + +/* Address of External Buffer Pointers Pool Register */ +#define MVNETA_BM_POOL_BASE_REG(pool) (0x10 + ((pool) << 4)) +#define MVNETA_BM_POOL_ENABLE_MASK BIT(0) + +/* External Buffer Pointers Pool RD pointer Register */ +#define MVNETA_BM_POOL_READ_PTR_REG(pool) (0x14 + ((pool) << 4)) +#define MVNETA_BM_POOL_SET_READ_PTR_MASK 0xfffc +#define MVNETA_BM_POOL_GET_READ_PTR_OFFS 16 +#define MVNETA_BM_POOL_GET_READ_PTR_MASK 0xfffc0000 + +/* External Buffer Pointers Pool WR pointer */ +#define MVNETA_BM_POOL_WRITE_PTR_REG(pool) (0x18 + ((pool) << 4)) +#define MVNETA_BM_POOL_SET_WRITE_PTR_OFFS 0 +#define MVNETA_BM_POOL_SET_WRITE_PTR_MASK 0xfffc +#define MVNETA_BM_POOL_GET_WRITE_PTR_OFFS 16 +#define MVNETA_BM_POOL_GET_WRITE_PTR_MASK 0xfffc0000 + +/* External Buffer Pointers Pool Size Register */ +#define MVNETA_BM_POOL_SIZE_REG(pool) (0x1c + ((pool) << 4)) +#define MVNETA_BM_POOL_SIZE_MASK 0x3fff + +/* BM Interrupt Cause Register */ +#define MVNETA_BM_INTR_CAUSE_REG (0x50) + +/* BM interrupt Mask Register */ +#define MVNETA_BM_INTR_MASK_REG (0x54) + +/* Other definitions */ +#define MVNETA_BM_SHORT_PKT_SIZE 256 +#define MVNETA_BM_POOLS_NUM 4 +#define MVNETA_BM_POOL_CAP_MIN 128 +#define MVNETA_BM_POOL_CAP_DEF 2048 +#define MVNETA_BM_POOL_CAP_MAX \ + (16 * 1024 - MVNETA_BM_POOL_CAP_ALIGN) +#define MVNETA_BM_POOL_CAP_ALIGN 32 +#define MVNETA_BM_POOL_PTR_ALIGN 32 + +#define MVNETA_BM_POOL_ACCESS_OFFS 8 + +#define MVNETA_BM_BPPI_SIZE 0x100000 + +#define MVNETA_RX_BUF_SIZE(pkt_size) ((pkt_size) + NET_SKB_PAD) + +enum mvneta_bm_type { + MVNETA_BM_FREE, + MVNETA_BM_LONG, + MVNETA_BM_SHORT +}; + +struct mvneta_bm { + void __iomem *reg_base; + struct clk *clk; + struct platform_device *pdev; + + struct gen_pool *bppi_pool; + /* BPPI virtual base address */ + void __iomem *bppi_virt_addr; + /* BPPI physical base address */ + dma_addr_t bppi_phys_addr; + + /* BM pools */ + struct mvneta_bm_pool *bm_pools; +}; + +struct mvneta_bm_pool { + struct hwbm_pool hwbm_pool; + /* Pool number in the range 0-3 */ + u8 id; + enum mvneta_bm_type type; + + /* Packet size */ + int pkt_size; + /* Size of the buffer acces through DMA*/ + u32 buf_size; + + /* BPPE virtual base address */ + u32 *virt_addr; + /* BPPE physical base address */ + dma_addr_t phys_addr; + + /* Ports using BM pool */ + u8 port_map; + + struct mvneta_bm *priv; +}; + +/* Declarations and definitions */ +void *mvneta_frag_alloc(unsigned int frag_size); +void mvneta_frag_free(unsigned int frag_size, void *data); + +#if defined(CONFIG_MVNETA_BM) || defined(CONFIG_MVNETA_BM_MODULE) +void mvneta_bm_pool_destroy(struct mvneta_bm *priv, + struct mvneta_bm_pool *bm_pool, u8 port_map); +void mvneta_bm_bufs_free(struct mvneta_bm *priv, struct mvneta_bm_pool *bm_pool, + u8 port_map); +int mvneta_bm_construct(struct hwbm_pool *hwbm_pool, void *buf); +int mvneta_bm_pool_refill(struct mvneta_bm *priv, + struct mvneta_bm_pool *bm_pool); +struct mvneta_bm_pool *mvneta_bm_pool_use(struct mvneta_bm *priv, u8 pool_id, + enum mvneta_bm_type type, u8 port_id, + int pkt_size); + +static inline void mvneta_bm_pool_put_bp(struct mvneta_bm *priv, + struct mvneta_bm_pool *bm_pool, + dma_addr_t buf_phys_addr) +{ + writel_relaxed(buf_phys_addr, priv->bppi_virt_addr + + (bm_pool->id << MVNETA_BM_POOL_ACCESS_OFFS)); +} + +static inline u32 mvneta_bm_pool_get_bp(struct mvneta_bm *priv, + struct mvneta_bm_pool *bm_pool) +{ + return readl_relaxed(priv->bppi_virt_addr + + (bm_pool->id << MVNETA_BM_POOL_ACCESS_OFFS)); +} +#else +void mvneta_bm_pool_destroy(struct mvneta_bm *priv, + struct mvneta_bm_pool *bm_pool, u8 port_map) {} +void mvneta_bm_bufs_free(struct mvneta_bm *priv, struct mvneta_bm_pool *bm_pool, + u8 port_map) {} +int mvneta_bm_construct(struct hwbm_pool *hwbm_pool, void *buf) { return 0; } +int mvneta_bm_pool_refill(struct mvneta_bm *priv, + struct mvneta_bm_pool *bm_pool) {return 0; } +struct mvneta_bm_pool *mvneta_bm_pool_use(struct mvneta_bm *priv, u8 pool_id, + enum mvneta_bm_type type, u8 port_id, + int pkt_size) { return NULL; } + +static inline void mvneta_bm_pool_put_bp(struct mvneta_bm *priv, + struct mvneta_bm_pool *bm_pool, + dma_addr_t buf_phys_addr) {} + +static inline u32 mvneta_bm_pool_get_bp(struct mvneta_bm *priv, + struct mvneta_bm_pool *bm_pool) +{ return 0; } +#endif /* CONFIG_MVNETA_BM */ +#endif --- a/arch/arm/boot/dts/armada-xp-db.dts +++ b/arch/arm/boot/dts/armada-xp-db.dts @@ -77,7 +77,8 @@ MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000 MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000 MBUS_ID(0x09, 0x09) 0 0 0xf1100000 0x10000 - MBUS_ID(0x09, 0x05) 0 0 0xf1110000 0x10000>; + MBUS_ID(0x09, 0x05) 0 0 0xf8110000 0x10000 + MBUS_ID(0x0c, 0x04) 0 0 0xf1200000 0x100000>; devbus-bootcs { status = "okay"; @@ -181,21 +182,33 @@ status = "okay"; phy = <&phy0>; phy-mode = "rgmii-id"; + buffer-manager = <&bm>; + bm,pool-long = <0>; }; ethernet at 74000 { status = "okay"; phy = <&phy1>; phy-mode = "rgmii-id"; + buffer-manager = <&bm>; + bm,pool-long = <1>; }; ethernet at 30000 { status = "okay"; phy = <&phy2>; phy-mode = "sgmii"; + buffer-manager = <&bm>; + bm,pool-long = <2>; }; ethernet at 34000 { status = "okay"; phy = <&phy3>; phy-mode = "sgmii"; + buffer-manager = <&bm>; + bm,pool-long = <3>; + }; + + bm at c0000 { + status = "okay"; }; mvsdio at d4000 { @@ -230,5 +243,9 @@ }; }; }; + + bm-bppi { + status = "okay"; }; + }; }; --- a/arch/arm/boot/dts/armada-xp-gp.dts +++ b/arch/arm/boot/dts/armada-xp-gp.dts @@ -96,7 +96,8 @@ MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000 MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000 MBUS_ID(0x09, 0x09) 0 0 0xf1100000 0x10000 - MBUS_ID(0x09, 0x05) 0 0 0xf1110000 0x10000>; + MBUS_ID(0x09, 0x05) 0 0 0xf8110000 0x10000 + MBUS_ID(0x0c, 0x04) 0 0 0xf1200000 0x100000>; devbus-bootcs { status = "okay"; @@ -196,21 +197,29 @@ status = "okay"; phy = <&phy0>; phy-mode = "qsgmii"; + buffer-manager = <&bm>; + bm,pool-long = <0>; }; ethernet at 74000 { status = "okay"; phy = <&phy1>; phy-mode = "qsgmii"; + buffer-manager = <&bm>; + bm,pool-long = <1>; }; ethernet at 30000 { status = "okay"; phy = <&phy2>; phy-mode = "qsgmii"; + buffer-manager = <&bm>; + bm,pool-long = <2>; }; ethernet at 34000 { status = "okay"; phy = <&phy3>; phy-mode = "qsgmii"; + buffer-manager = <&bm>; + bm,pool-long = <3>; }; /* Front-side USB slot */ @@ -235,6 +244,10 @@ }; }; + bm at c0000 { + status = "okay"; + }; + nand at d0000 { status = "okay"; num-cs = <1>; @@ -243,5 +256,10 @@ nand-on-flash-bbt; }; }; + + bm-bppi { + status = "okay"; + }; + }; }; --- a/arch/arm/boot/dts/armada-xp.dtsi +++ b/arch/arm/boot/dts/armada-xp.dtsi @@ -251,6 +251,14 @@ marvell,crypto-sram-size = <0x800>; }; + bm: bm at c0000 { + compatible = "marvell,armada-380-neta-bm"; + reg = <0xc0000 0xac>; + clocks = <&gateclk 13>; + internal-mem = <&bm_bppi>; + status = "disabled"; + }; + xor at f0900 { compatible = "marvell,orion-xor"; reg = <0xF0900 0x100 @@ -289,7 +297,18 @@ #size-cells = <1>; ranges = <0 MBUS_ID(0x09, 0x05) 0 0x800>; }; - }; + + bm_bppi: bm-bppi { + compatible = "mmio-sram"; + reg = ; + ranges = <0 MBUS_ID(0x0c, 0x04) 0 0x100000>; + #address-cells = <1>; + #size-cells = <1>; + clocks = <&gateclk 13>; + no-memory-wc; + status = "disabled"; + }; + }; clocks { /* 25 MHz reference crystal */ --- a/dev/null +++ b/include/net/hwbm.h @@ -0,0 +1,28 @@ +#ifndef _HWBM_H +#define _HWBM_H + +struct hwbm_pool { + /* Capacity of the pool */ + int size; + /* Size of the buffers managed */ + int frag_size; + /* Number of buffers currently used by this pool */ + int buf_num; + /* constructor called during alocation */ + int (*construct)(struct hwbm_pool *bm_pool, void *buf); + /* protect acces to the buffer counter*/ + spinlock_t lock; + /* private data */ + void *priv; +}; +#ifdef CONFIG_HWBM +void hwbm_buf_free(struct hwbm_pool *bm_pool, void *buf); +int hwbm_pool_refill(struct hwbm_pool *bm_pool, gfp_t gfp); +int hwbm_pool_add(struct hwbm_pool *bm_pool, unsigned int buf_num, gfp_t gfp); +#else +void hwbm_buf_free(struct hwbm_pool *bm_pool, void *buf) {} +int hwbm_pool_refill(struct hwbm_pool *bm_pool, gfp_t gfp) { return 0; } +int hwbm_pool_add(struct hwbm_pool *bm_pool, unsigned int buf_num, gfp_t gfp) +{ return 0; } +#endif /* CONFIG_HWBM */ +#endif /* _HWBM_H */ --- a/net/Kconfig +++ b/net/Kconfig @@ -259,6 +259,9 @@ config XPS depends on SMP default y +config HWBM + bool + config CGROUP_NET_PRIO bool "Network priority cgroup" depends on CGROUPS --- a/net/core/Makefile +++ b/net/core/Makefile @@ -25,3 +25,4 @@ obj-$(CONFIG_NET_PTP_CLASSIFY) += ptp_cl obj-$(CONFIG_CGROUP_NET_PRIO) += netprio_cgroup.o obj-$(CONFIG_CGROUP_NET_CLASSID) += netclassid_cgroup.o obj-$(CONFIG_LWTUNNEL) += lwtunnel.o +obj-$(CONFIG_HWBM) += hwbm.o --- a/dev/null +++ b/net/core/hwbm.c @@ -0,0 +1,87 @@ +/* Support for hardware buffer manager. + * + * Copyright (C) 2016 Marvell + * + * Gregory CLEMENT + * + * 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. + */ +#include +#include +#include +#include + +void hwbm_buf_free(struct hwbm_pool *bm_pool, void *buf) +{ + if (likely(bm_pool->frag_size <= PAGE_SIZE)) + skb_free_frag(buf); + else + kfree(buf); +} +EXPORT_SYMBOL_GPL(hwbm_buf_free); + +/* Refill processing for HW buffer management */ +int hwbm_pool_refill(struct hwbm_pool *bm_pool, gfp_t gfp) +{ + int frag_size = bm_pool->frag_size; + void *buf; + + if (likely(frag_size <= PAGE_SIZE)) + buf = netdev_alloc_frag(frag_size); + else + buf = kmalloc(frag_size, gfp); + + if (!buf) + return -ENOMEM; + + if (bm_pool->construct) + if (bm_pool->construct(bm_pool, buf)) { + hwbm_buf_free(bm_pool, buf); + return -ENOMEM; + } + + return 0; +} +EXPORT_SYMBOL_GPL(hwbm_pool_refill); + +int hwbm_pool_add(struct hwbm_pool *bm_pool, unsigned int buf_num, gfp_t gfp) +{ + int err, i; + unsigned long flags; + + spin_lock_irqsave(&bm_pool->lock, flags); + if (bm_pool->buf_num == bm_pool->size) { + pr_warn("pool already filled\n"); + return bm_pool->buf_num; + } + + if (buf_num + bm_pool->buf_num > bm_pool->size) { + pr_warn("cannot allocate %d buffers for pool\n", + buf_num); + return 0; + } + + if ((buf_num + bm_pool->buf_num) < bm_pool->buf_num) { + pr_warn("Adding %d buffers to the %d current buffers will overflow\n", + buf_num, bm_pool->buf_num); + return 0; + } + + for (i = 0; i < buf_num; i++) { + err = hwbm_pool_refill(bm_pool, gfp); + if (err < 0) + break; + } + + /* Update BM driver with number of buffers added to pool */ + bm_pool->buf_num += i; + + pr_debug("hwpm pool: %d of %d buffers added\n", i, buf_num); + spin_unlock_irqrestore(&bm_pool->lock, flags); + + return i; +} +EXPORT_SYMBOL_GPL(hwbm_pool_add); --- a/drivers/bus/mvebu-mbus.c +++ b/drivers/bus/mvebu-mbus.c @@ -948,6 +948,58 @@ void mvebu_mbus_get_pcie_io_aperture(str *res = mbus_state.pcie_io_aperture; } +int mvebu_mbus_get_dram_win_info(phys_addr_t phyaddr, u8 *target, u8 *attr) +{ + const struct mbus_dram_target_info *dram; + int i; + + /* Get dram info */ + dram = mv_mbus_dram_info(); + if (!dram) { + pr_err("missing DRAM information\n"); + return -ENODEV; + } + + /* Try to find matching DRAM window for phyaddr */ + for (i = 0; i < dram->num_cs; i++) { + const struct mbus_dram_window *cs = dram->cs + i; + + if (cs->base <= phyaddr && + phyaddr <= (cs->base + cs->size - 1)) { + *target = dram->mbus_dram_target_id; + *attr = cs->mbus_attr; + return 0; + } + } + + pr_err("invalid dram address 0x%x\n", phyaddr); + return -EINVAL; +} +EXPORT_SYMBOL_GPL(mvebu_mbus_get_dram_win_info); + +int mvebu_mbus_get_io_win_info(phys_addr_t phyaddr, u32 *size, u8 *target, + u8 *attr) +{ + int win; + + for (win = 0; win < mbus_state.soc->num_wins; win++) { + u64 wbase; + int enabled; + + mvebu_mbus_read_window(&mbus_state, win, &enabled, &wbase, + size, target, attr, NULL); + + if (!enabled) + continue; + + if (wbase <= phyaddr && phyaddr <= wbase + *size) + return win; + } + + return -EINVAL; +} +EXPORT_SYMBOL_GPL(mvebu_mbus_get_io_win_info); + static __init int mvebu_mbus_debugfs_init(void) { struct mvebu_mbus_state *s = &mbus_state; --- a/include/linux/mbus.h +++ b/include/linux/mbus.h @@ -69,6 +69,9 @@ static inline const struct mbus_dram_tar int mvebu_mbus_save_cpu_target(u32 *store_addr); void mvebu_mbus_get_pcie_mem_aperture(struct resource *res); void mvebu_mbus_get_pcie_io_aperture(struct resource *res); +int mvebu_mbus_get_dram_win_info(phys_addr_t phyaddr, u8 *target, u8 *attr); +int mvebu_mbus_get_io_win_info(phys_addr_t phyaddr, u32 *size, u8 *target, + u8 *attr); int mvebu_mbus_add_window_remap_by_id(unsigned int target, unsigned int attribute, phys_addr_t base, size_t size, --- a/drivers/misc/sram.c +++ b/drivers/misc/sram.c @@ -360,7 +360,10 @@ static int sram_probe(struct platform_de return -EBUSY; } - sram->virt_base = devm_ioremap_wc(sram->dev, res->start, size); + if (of_property_read_bool(pdev->dev.of_node, "no-memory-wc")) + sram->virt_base = devm_ioremap(sram->dev, res->start, size); + else + sram->virt_base = devm_ioremap_wc(sram->dev, res->start, size); if (IS_ERR(sram->virt_base)) return PTR_ERR(sram->virt_base); --- a/drivers/net/ethernet/marvell/Kconfig +++ b/drivers/net/ethernet/marvell/Kconfig @@ -40,6 +40,19 @@ config MVMDIO This driver is used by the MV643XX_ETH and MVNETA drivers. +config MVNETA_BM_ENABLE + tristate "Marvell Armada 38x/XP network interface BM support" + depends on MVNETA + ---help--- + This driver supports auxiliary block of the network + interface units in the Marvell ARMADA XP and ARMADA 38x SoC + family, which is called buffer manager. + + This driver, when enabled, strictly cooperates with mvneta + driver and is common for all network ports of the devices, + even for Armada 370 SoC, which doesn't support hardware + buffer management. + config MVNETA tristate "Marvell Armada 370/38x/XP network interface support" depends on PLAT_ORION @@ -53,6 +66,15 @@ config MVNETA driver, which should be used for the older Marvell SoCs (Dove, Orion, Discovery, Kirkwood). +config MVNETA_BM + tristate + default y if MVNETA=y && MVNETA_BM_ENABLE + default MVNETA_BM_ENABLE + select HWBM + help + MVNETA_BM must not be 'm' if MVNETA=y, so this symbol ensures + that all dependencies are met. + config MVPP2 tristate "Marvell Armada 375 network interface support" depends on MACH_ARMADA_375 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From nitroshift at yahoo.com Thu May 19 02:42:34 2016 From: nitroshift at yahoo.com (Sebastian Careba) Date: Thu, 19 May 2016 09:42:34 +0300 Subject: [OpenWrt-Devel] mvebu: introduce mvneta buffer manager offload module Message-ID: <1463640154-3742-1-git-send-email-nitroshift@yahoo.com> Buffer manager (BM) is a dedicated hardware unit that can be used by all ethernet ports of Armada XP and 38x SoC's. It allows to offload CPU on RX path by sparing DRAM access on refilling buffer pool, hardware-based filling of descriptor ring data and better memory utilization due to HW arbitration for using 'short' pools for small packets. Tests performed with A388 SoC working as a network bridge between two packet generators showed increase of maximum processed 64B packets by ~20k (~555k packets with BM enabled vs ~535 packets without BM). Also when pushing 1500B-packets with a line rate achieved, CPU load decreased from around 25% without BM to 20% with BM. BM comprise up to 4 buffer pointers' (BP) rings kept in DRAM, which are called external BP pools - BPPE. Allocating and releasing buffer pointers (BP) to/from BPPE is performed indirectly by write/read access to a dedicated internal SRAM, where internal BP pools (BPPI) are placed. BM hardware controls status of BPPE automatically, as well as assigning proper buffers to RX descriptors. For more details please refer to Functional Specification of Armada XP or 38x SoC. In order to enable support for a separate hardware block, common for all ports, a new driver has to be implemented ('mvneta_bm'). It provides initialization sequence of address space, clocks, registers, SRAM, empty pools' structures and also obtaining optional configuration from DT (please refer to device tree binding documentation). mvneta_bm exposes also a necessary API to mvneta driver, as well as a dedicated structure with BM information (bm_priv), whose presence is used as a flag notifying of BM usage by port. It has to be ensured that mvneta_bm probe is executed prior to the ones in ports' driver. In case BM is not used or its probe fails, mvneta falls back to use software buffer management. A sequence executed in mvneta_probe function is modified in order to have an access to needed resources before possible port's BM initialization is done. According to port-pools mapping provided by DT appropriate registers are configured and the buffer pools are filled. RX path is modified accordingly. Becaues the hardware allows a wide variety of configuration options, following assumptions are made: * using BM mechanisms can be selectively disabled/enabled basing on DT configuration among the ports * 'long' pool's single buffer size is tied to port's MTU * using 'long' pool by port is obligatory and it cannot be shared * using 'short' pool for smaller packets is optional * one 'short' pool can be shared among all ports This commit enables hardware buffer management operation cooperating with existing mvneta driver. New device tree binding documentation is added and the one of mvneta is updated accordingly. [gregory.clement at free-electrons.com: removed the suspend/resume part] Signed-off-by: Gregory Clement Signed-off-by: Marcin Wojtas Signed-off-by: Sebastian Careba --- --- a/drivers/net/ethernet/marvell/Makefile +++ b/drivers/net/ethernet/marvell/Makefile @@ -4,6 +4,7 @@ obj-$(CONFIG_MVMDIO) += mvmdio.o obj-$(CONFIG_MV643XX_ETH) += mv643xx_eth.o +obj-$(CONFIG_MVNETA_BM) += mvneta_bm.o obj-$(CONFIG_MVNETA) += mvneta.o obj-$(CONFIG_MVPP2) += mvpp2.o obj-$(CONFIG_PXA168_ETH) += pxa168_eth.o--- a/drivers/net/ethernet/marvell/mvneta.c +++ b/drivers/net/ethernet/marvell/mvneta.c @@ -11,32 +11,38 @@ * warranty of any kind, whether express or implied. */ -#include -#include +#include +#include #include -#include -#include +#include #include -#include -#include #include -#include -#include -#include #include -#include +#include +#include +#include +#include #include +#include #include #include #include -#include #include -#include -#include +#include +#include +#include +#include "mvneta_bm.h" +#include +#include +#include /* Registers */ #define MVNETA_RXQ_CONFIG_REG(q) (0x1400 + ((q) << 2)) #define MVNETA_RXQ_HW_BUF_ALLOC BIT(0) +#define MVNETA_RXQ_SHORT_POOL_ID_SHIFT 4 +#define MVNETA_RXQ_SHORT_POOL_ID_MASK 0x30 +#define MVNETA_RXQ_LONG_POOL_ID_SHIFT 6 +#define MVNETA_RXQ_LONG_POOL_ID_MASK 0xc0 #define MVNETA_RXQ_PKT_OFFSET_ALL_MASK (0xf << 8) #define MVNETA_RXQ_PKT_OFFSET_MASK(offs) ((offs) << 8) #define MVNETA_RXQ_THRESHOLD_REG(q) (0x14c0 + ((q) << 2)) @@ -50,6 +56,9 @@ #define MVNETA_RXQ_STATUS_UPDATE_REG(q) (0x1500 + ((q) << 2)) #define MVNETA_RXQ_ADD_NON_OCCUPIED_SHIFT 16 #define MVNETA_RXQ_ADD_NON_OCCUPIED_MAX 255 +#define MVNETA_PORT_POOL_BUFFER_SZ_REG(pool) (0x1700 + ((pool) << 2)) +#define MVNETA_PORT_POOL_BUFFER_SZ_SHIFT 3 +#define MVNETA_PORT_POOL_BUFFER_SZ_MASK 0xfff8 #define MVNETA_PORT_RX_RESET 0x1cc0 #define MVNETA_PORT_RX_DMA_RESET BIT(0) #define MVNETA_PHY_ADDR 0x2000 @@ -107,12 +116,21 @@ #define MVNETA_GMAC_CLOCK_DIVIDER 0x24f4 #define MVNETA_GMAC_1MS_CLOCK_ENABLE BIT(31) #define MVNETA_ACC_MODE 0x2500 +#define MVNETA_BM_ADDRESS 0x2504 #define MVNETA_CPU_MAP(cpu) (0x2540 + ((cpu) << 2)) #define MVNETA_CPU_RXQ_ACCESS_ALL_MASK 0x000000ff #define MVNETA_CPU_TXQ_ACCESS_ALL_MASK 0x0000ff00 +#define MVNETA_CPU_RXQ_ACCESS(rxq) BIT(rxq) +#define MVNETA_CPU_TXQ_ACCESS(txq) BIT(txq + 8) #define MVNETA_RXQ_TIME_COAL_REG(q) (0x2580 + ((q) << 2)) -/* Exception Interrupt Port/Queue Cause register */ +/* Exception Interrupt Port/Queue Cause register + * + * Their behavior depend of the mapping done using the PCPX2Q + * registers. For a given CPU if the bit associated to a queue is not + * set, then for the register a read from this CPU will always return + * 0 and a write won't do anything + */ #define MVNETA_INTR_NEW_CAUSE 0x25a0 #define MVNETA_INTR_NEW_MASK 0x25a4 @@ -245,7 +263,10 @@ #define MVNETA_CPU_D_CACHE_LINE_SIZE 32 #define MVNETA_TX_CSUM_DEF_SIZE 1600 #define MVNETA_TX_CSUM_MAX_SIZE 9800 -#define MVNETA_ACC_MODE_EXT 1 +#define MVNETA_ACC_MODE_EXT1 1 +#define MVNETA_ACC_MODE_EXT2 2 + +#define MVNETA_MAX_DECODE_WIN 6 /* Timeout constants */ #define MVNETA_TX_DISABLE_TIMEOUT_MSEC 1000 @@ -254,6 +275,11 @@ #define MVNETA_TX_MTU_MAX 0x3ffff +/* The RSS lookup table actually has 256 entries but we do not use + * them yet + */ +#define MVNETA_RSS_LU_TABLE_SIZE 1 + /* TSO header size */ #define TSO_HEADER_SIZE 128 @@ -280,7 +306,8 @@ ((addr >= txq->tso_hdrs_phys) && \ (addr < txq->tso_hdrs_phys + txq->size * TSO_HEADER_SIZE)) -#define MVNETA_RX_BUF_SIZE(pkt_size) ((pkt_size) + NET_SKB_PAD) +#define MVNETA_RX_GET_BM_POOL_ID(rxd) \ + (((rxd)->status & MVNETA_RXD_BM_POOL_MASK) >> MVNETA_RXD_BM_POOL_SHIFT) struct mvneta_statistic { unsigned short offset; @@ -346,6 +373,7 @@ struct mvneta_pcpu_port { }; struct mvneta_port { + u8 id; struct mvneta_pcpu_port __percpu *ports; struct mvneta_pcpu_stats __percpu *stats; @@ -356,9 +384,17 @@ struct mvneta_port { struct mvneta_tx_queue *txqs; struct net_device *dev; struct notifier_block cpu_notifier; + int rxq_def; + /* Protect the access to the percpu interrupt registers, + * ensuring that the configuration remains coherent. + */ + spinlock_t lock; + bool is_stopped; /* Core clock */ struct clk *clk; + /* AXI clock */ + struct clk *clk_bus; u8 mcast_count[256]; u16 tx_ring_size; u16 rx_ring_size; @@ -371,9 +407,16 @@ struct mvneta_port { unsigned int duplex; unsigned int speed; unsigned int tx_csum_limit; - int use_inband_status:1; + unsigned int use_inband_status:1; + + struct mvneta_bm *bm_priv; + struct mvneta_bm_pool *pool_long; + struct mvneta_bm_pool *pool_short; + int bm_win_id; u64 ethtool_stats[ARRAY_SIZE(mvneta_statistics)]; + + u32 indir[MVNETA_RSS_LU_TABLE_SIZE]; }; /* The mvneta_tx_desc and mvneta_rx_desc structures describe the @@ -396,6 +439,8 @@ struct mvneta_port { #define MVNETA_TX_L4_CSUM_NOT BIT(31) #define MVNETA_RXD_ERR_CRC 0x0 +#define MVNETA_RXD_BM_POOL_SHIFT 13 +#define MVNETA_RXD_BM_POOL_MASK (BIT(13) | BIT(14)) #define MVNETA_RXD_ERR_SUMMARY BIT(16) #define MVNETA_RXD_ERR_OVERRUN BIT(17) #define MVNETA_RXD_ERR_LEN BIT(18) @@ -499,6 +544,9 @@ struct mvneta_tx_queue { /* DMA address of TSO headers */ dma_addr_t tso_hdrs_phys; + + /* Affinity mask for CPUs*/ + cpumask_t affinity_mask; }; struct mvneta_rx_queue { @@ -537,6 +585,9 @@ static int rxq_def; static int rx_copybreak __read_mostly = 256; +/* HW BM need that each port be identify by a unique ID */ +static int global_port_id; + #define MVNETA_DRIVER_NAME "mvneta" #define MVNETA_DRIVER_VERSION "1.0" @@ -803,6 +854,215 @@ static void mvneta_rxq_bm_disable(struct mvreg_write(pp, MVNETA_RXQ_CONFIG_REG(rxq->id), val); } +/* Enable buffer management (BM) */ +static void mvneta_rxq_bm_enable(struct mvneta_port *pp, + struct mvneta_rx_queue *rxq) +{ + u32 val; + + val = mvreg_read(pp, MVNETA_RXQ_CONFIG_REG(rxq->id)); + val |= MVNETA_RXQ_HW_BUF_ALLOC; + mvreg_write(pp, MVNETA_RXQ_CONFIG_REG(rxq->id), val); +} + +/* Notify HW about port's assignment of pool for bigger packets */ +static void mvneta_rxq_long_pool_set(struct mvneta_port *pp, + struct mvneta_rx_queue *rxq) +{ + u32 val; + + val = mvreg_read(pp, MVNETA_RXQ_CONFIG_REG(rxq->id)); + val &= ~MVNETA_RXQ_LONG_POOL_ID_MASK; + val |= (pp->pool_long->id << MVNETA_RXQ_LONG_POOL_ID_SHIFT); + + mvreg_write(pp, MVNETA_RXQ_CONFIG_REG(rxq->id), val); +} + +/* Notify HW about port's assignment of pool for smaller packets */ +static void mvneta_rxq_short_pool_set(struct mvneta_port *pp, + struct mvneta_rx_queue *rxq) +{ + u32 val; + + val = mvreg_read(pp, MVNETA_RXQ_CONFIG_REG(rxq->id)); + val &= ~MVNETA_RXQ_SHORT_POOL_ID_MASK; + val |= (pp->pool_short->id << MVNETA_RXQ_SHORT_POOL_ID_SHIFT); + + mvreg_write(pp, MVNETA_RXQ_CONFIG_REG(rxq->id), val); +} + +/* Set port's receive buffer size for assigned BM pool */ +static inline void mvneta_bm_pool_bufsize_set(struct mvneta_port *pp, + int buf_size, + u8 pool_id) +{ + u32 val; + + if (!IS_ALIGNED(buf_size, 8)) { + dev_warn(pp->dev->dev.parent, + "illegal buf_size value %d, round to %d\n", + buf_size, ALIGN(buf_size, 8)); + buf_size = ALIGN(buf_size, 8); + } + + val = mvreg_read(pp, MVNETA_PORT_POOL_BUFFER_SZ_REG(pool_id)); + val |= buf_size & MVNETA_PORT_POOL_BUFFER_SZ_MASK; + mvreg_write(pp, MVNETA_PORT_POOL_BUFFER_SZ_REG(pool_id), val); +} + +/* Configure MBUS window in order to enable access BM internal SRAM */ +static int mvneta_mbus_io_win_set(struct mvneta_port *pp, u32 base, u32 wsize, + u8 target, u8 attr) +{ + u32 win_enable, win_protect; + int i; + + win_enable = mvreg_read(pp, MVNETA_BASE_ADDR_ENABLE); + + if (pp->bm_win_id < 0) { + /* Find first not occupied window */ + for (i = 0; i < MVNETA_MAX_DECODE_WIN; i++) { + if (win_enable & (1 << i)) { + pp->bm_win_id = i; + break; + } + } + if (i == MVNETA_MAX_DECODE_WIN) + return -ENOMEM; + } else { + i = pp->bm_win_id; + } + + mvreg_write(pp, MVNETA_WIN_BASE(i), 0); + mvreg_write(pp, MVNETA_WIN_SIZE(i), 0); + + if (i < 4) + mvreg_write(pp, MVNETA_WIN_REMAP(i), 0); + + mvreg_write(pp, MVNETA_WIN_BASE(i), (base & 0xffff0000) | + (attr << 8) | target); + + mvreg_write(pp, MVNETA_WIN_SIZE(i), (wsize - 1) & 0xffff0000); + + win_protect = mvreg_read(pp, MVNETA_ACCESS_PROTECT_ENABLE); + win_protect |= 3 << (2 * i); + mvreg_write(pp, MVNETA_ACCESS_PROTECT_ENABLE, win_protect); + + win_enable &= ~(1 << i); + mvreg_write(pp, MVNETA_BASE_ADDR_ENABLE, win_enable); + + return 0; +} + +/* Assign and initialize pools for port. In case of fail + * buffer manager will remain disabled for current port. + */ +static int mvneta_bm_port_init(struct platform_device *pdev, + struct mvneta_port *pp) +{ + struct device_node *dn = pdev->dev.of_node; + u32 long_pool_id, short_pool_id, wsize; + u8 target, attr; + int err; + + /* Get BM window information */ + err = mvebu_mbus_get_io_win_info(pp->bm_priv->bppi_phys_addr, &wsize, + &target, &attr); + if (err < 0) + return err; + + pp->bm_win_id = -1; + + /* Open NETA -> BM window */ + err = mvneta_mbus_io_win_set(pp, pp->bm_priv->bppi_phys_addr, wsize, + target, attr); + if (err < 0) { + netdev_info(pp->dev, "fail to configure mbus window to BM\n"); + return err; + } + + if (of_property_read_u32(dn, "bm,pool-long", &long_pool_id)) { + netdev_info(pp->dev, "missing long pool id\n"); + return -EINVAL; + } + + /* Create port's long pool depending on mtu */ + pp->pool_long = mvneta_bm_pool_use(pp->bm_priv, long_pool_id, + MVNETA_BM_LONG, pp->id, + MVNETA_RX_PKT_SIZE(pp->dev->mtu)); + if (!pp->pool_long) { + netdev_info(pp->dev, "fail to obtain long pool for port\n"); + return -ENOMEM; + } + + pp->pool_long->port_map |= 1 << pp->id; + + mvneta_bm_pool_bufsize_set(pp, pp->pool_long->buf_size, + pp->pool_long->id); + + /* If short pool id is not defined, assume using single pool */ + if (of_property_read_u32(dn, "bm,pool-short", &short_pool_id)) + short_pool_id = long_pool_id; + + /* Create port's short pool */ + pp->pool_short = mvneta_bm_pool_use(pp->bm_priv, short_pool_id, + MVNETA_BM_SHORT, pp->id, + MVNETA_BM_SHORT_PKT_SIZE); + if (!pp->pool_short) { + netdev_info(pp->dev, "fail to obtain short pool for port\n"); + mvneta_bm_pool_destroy(pp->bm_priv, pp->pool_long, 1 << pp->id); + return -ENOMEM; + } + + if (short_pool_id != long_pool_id) { + pp->pool_short->port_map |= 1 << pp->id; + mvneta_bm_pool_bufsize_set(pp, pp->pool_short->buf_size, + pp->pool_short->id); + } + + return 0; +} + +/* Update settings of a pool for bigger packets */ +static void mvneta_bm_update_mtu(struct mvneta_port *pp, int mtu) +{ + struct mvneta_bm_pool *bm_pool = pp->pool_long; + struct hwbm_pool *hwbm_pool = &bm_pool->hwbm_pool; + int num; + + /* Release all buffers from long pool */ + mvneta_bm_bufs_free(pp->bm_priv, bm_pool, 1 << pp->id); + if (hwbm_pool->buf_num) { + WARN(1, "cannot free all buffers in pool %d\n", + bm_pool->id); + goto bm_mtu_err; + } + + bm_pool->pkt_size = MVNETA_RX_PKT_SIZE(mtu); + bm_pool->buf_size = MVNETA_RX_BUF_SIZE(bm_pool->pkt_size); + hwbm_pool->frag_size = SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) + + SKB_DATA_ALIGN(MVNETA_RX_BUF_SIZE(bm_pool->pkt_size)); + + /* Fill entire long pool */ + num = hwbm_pool_add(hwbm_pool, hwbm_pool->size, GFP_ATOMIC); + if (num != hwbm_pool->size) { + WARN(1, "pool %d: %d of %d allocated\n", + bm_pool->id, num, hwbm_pool->size); + goto bm_mtu_err; + } + mvneta_bm_pool_bufsize_set(pp, bm_pool->buf_size, bm_pool->id); + + return; + +bm_mtu_err: + mvneta_bm_pool_destroy(pp->bm_priv, pp->pool_long, 1 << pp->id); + mvneta_bm_pool_destroy(pp->bm_priv, pp->pool_short, 1 << pp->id); + + pp->bm_priv = NULL; + mvreg_write(pp, MVNETA_ACC_MODE, MVNETA_ACC_MODE_EXT1); + netdev_info(pp->dev, "fail to update MTU, fall back to software BM\n"); +} + /* Start the Ethernet port RX and TX activity */ static void mvneta_port_up(struct mvneta_port *pp) { @@ -819,7 +1079,13 @@ static void mvneta_port_up(struct mvneta mvreg_write(pp, MVNETA_TXQ_CMD, q_map); /* Enable all initialized RXQs. */ - mvreg_write(pp, MVNETA_RXQ_CMD, BIT(rxq_def)); + for (queue = 0; queue < rxq_number; queue++) { + struct mvneta_rx_queue *rxq = &pp->rxqs[queue]; + + if (rxq->descs != NULL) + q_map |= (1 << queue); + } + mvreg_write(pp, MVNETA_RXQ_CMD, q_map); } /* Stop the Ethernet port activity */ @@ -973,6 +1239,81 @@ static void mvneta_set_other_mcast_table mvreg_write(pp, MVNETA_DA_FILT_OTH_MCAST + offset, val); } +static void mvneta_set_autoneg(struct mvneta_port *pp, int enable) +{ + u32 val; + + if (enable) { + val = mvreg_read(pp, MVNETA_GMAC_AUTONEG_CONFIG); + val &= ~(MVNETA_GMAC_FORCE_LINK_PASS | + MVNETA_GMAC_FORCE_LINK_DOWN | + MVNETA_GMAC_AN_FLOW_CTRL_EN); + val |= MVNETA_GMAC_INBAND_AN_ENABLE | + MVNETA_GMAC_AN_SPEED_EN | + MVNETA_GMAC_AN_DUPLEX_EN; + mvreg_write(pp, MVNETA_GMAC_AUTONEG_CONFIG, val); + + val = mvreg_read(pp, MVNETA_GMAC_CLOCK_DIVIDER); + val |= MVNETA_GMAC_1MS_CLOCK_ENABLE; + mvreg_write(pp, MVNETA_GMAC_CLOCK_DIVIDER, val); + + val = mvreg_read(pp, MVNETA_GMAC_CTRL_2); + val |= MVNETA_GMAC2_INBAND_AN_ENABLE; + mvreg_write(pp, MVNETA_GMAC_CTRL_2, val); + } else { + val = mvreg_read(pp, MVNETA_GMAC_AUTONEG_CONFIG); + val &= ~(MVNETA_GMAC_INBAND_AN_ENABLE | + MVNETA_GMAC_AN_SPEED_EN | + MVNETA_GMAC_AN_DUPLEX_EN); + mvreg_write(pp, MVNETA_GMAC_AUTONEG_CONFIG, val); + + val = mvreg_read(pp, MVNETA_GMAC_CLOCK_DIVIDER); + val &= ~MVNETA_GMAC_1MS_CLOCK_ENABLE; + mvreg_write(pp, MVNETA_GMAC_CLOCK_DIVIDER, val); + + val = mvreg_read(pp, MVNETA_GMAC_CTRL_2); + val &= ~MVNETA_GMAC2_INBAND_AN_ENABLE; + mvreg_write(pp, MVNETA_GMAC_CTRL_2, val); + } +} + +static void mvneta_percpu_unmask_interrupt(void *arg) +{ + struct mvneta_port *pp = arg; + + /* All the queue are unmasked, but actually only the ones + * mapped to this CPU will be unmasked + */ + mvreg_write(pp, MVNETA_INTR_NEW_MASK, + MVNETA_RX_INTR_MASK_ALL | + MVNETA_TX_INTR_MASK_ALL | + MVNETA_MISCINTR_INTR_MASK); +} + +static void mvneta_percpu_mask_interrupt(void *arg) +{ + struct mvneta_port *pp = arg; + + /* All the queue are masked, but actually only the ones + * mapped to this CPU will be masked + */ + mvreg_write(pp, MVNETA_INTR_NEW_MASK, 0); + mvreg_write(pp, MVNETA_INTR_OLD_MASK, 0); + mvreg_write(pp, MVNETA_INTR_MISC_MASK, 0); +} + +static void mvneta_percpu_clear_intr_cause(void *arg) +{ + struct mvneta_port *pp = arg; + + /* All the queue are cleared, but actually only the ones + * mapped to this CPU will be cleared + */ + mvreg_write(pp, MVNETA_INTR_NEW_CAUSE, 0); + mvreg_write(pp, MVNETA_INTR_MISC_CAUSE, 0); + mvreg_write(pp, MVNETA_INTR_OLD_CAUSE, 0); +} + /* This method sets defaults to the NETA port: * Clears interrupt Cause and Mask registers. * Clears all MAC tables. @@ -987,28 +1328,45 @@ static void mvneta_defaults_set(struct m int cpu; int queue; u32 val; + int max_cpu = num_present_cpus(); /* Clear all Cause registers */ - mvreg_write(pp, MVNETA_INTR_NEW_CAUSE, 0); - mvreg_write(pp, MVNETA_INTR_OLD_CAUSE, 0); - mvreg_write(pp, MVNETA_INTR_MISC_CAUSE, 0); + on_each_cpu(mvneta_percpu_clear_intr_cause, pp, true); /* Mask all interrupts */ - mvreg_write(pp, MVNETA_INTR_NEW_MASK, 0); - mvreg_write(pp, MVNETA_INTR_OLD_MASK, 0); - mvreg_write(pp, MVNETA_INTR_MISC_MASK, 0); + on_each_cpu(mvneta_percpu_mask_interrupt, pp, true); mvreg_write(pp, MVNETA_INTR_ENABLE, 0); /* Enable MBUS Retry bit16 */ mvreg_write(pp, MVNETA_MBUS_RETRY, 0x20); - /* Set CPU queue access map - all CPUs have access to all RX - * queues and to all TX queues + /* Set CPU queue access map. CPUs are assigned to the RX and + * TX queues modulo their number. If there is only one TX + * queue then it is assigned to the CPU associated to the + * default RX queue. */ - for_each_present_cpu(cpu) - mvreg_write(pp, MVNETA_CPU_MAP(cpu), - (MVNETA_CPU_RXQ_ACCESS_ALL_MASK | - MVNETA_CPU_TXQ_ACCESS_ALL_MASK)); + for_each_present_cpu(cpu) { + int rxq_map = 0, txq_map = 0; + int rxq, txq; + + for (rxq = 0; rxq < rxq_number; rxq++) + if ((rxq % max_cpu) == cpu) + rxq_map |= MVNETA_CPU_RXQ_ACCESS(rxq); + + for (txq = 0; txq < txq_number; txq++) + if ((txq % max_cpu) == cpu) + txq_map |= MVNETA_CPU_TXQ_ACCESS(txq); + + /* With only one TX queue we configure a special case + * which will allow to get all the irq on a single + * CPU + */ + if (txq_number == 1) + txq_map = (cpu == pp->rxq_def) ? + MVNETA_CPU_TXQ_ACCESS(1) : 0; + + mvreg_write(pp, MVNETA_CPU_MAP(cpu), rxq_map | txq_map); + } /* Reset RX and TX DMAs */ mvreg_write(pp, MVNETA_PORT_RX_RESET, MVNETA_PORT_RX_DMA_RESET); @@ -1025,11 +1383,19 @@ static void mvneta_defaults_set(struct m mvreg_write(pp, MVNETA_PORT_RX_RESET, 0); /* Set Port Acceleration Mode */ - val = MVNETA_ACC_MODE_EXT; + if (pp->bm_priv) + /* HW buffer management + legacy parser */ + val = MVNETA_ACC_MODE_EXT2; + else + /* SW buffer management + legacy parser */ + val = MVNETA_ACC_MODE_EXT1; mvreg_write(pp, MVNETA_ACC_MODE, val); + if (pp->bm_priv) + mvreg_write(pp, MVNETA_BM_ADDRESS, pp->bm_priv->bppi_phys_addr); + /* Update val of portCfg register accordingly with all RxQueue types */ - val = MVNETA_PORT_CONFIG_DEFL_VALUE(rxq_def); + val = MVNETA_PORT_CONFIG_DEFL_VALUE(pp->rxq_def); mvreg_write(pp, MVNETA_PORT_CONFIG, val); val = 0; @@ -1058,26 +1424,7 @@ static void mvneta_defaults_set(struct m val &= ~MVNETA_PHY_POLLING_ENABLE; mvreg_write(pp, MVNETA_UNIT_CONTROL, val); - if (pp->use_inband_status) { - val = mvreg_read(pp, MVNETA_GMAC_AUTONEG_CONFIG); - val &= ~(MVNETA_GMAC_FORCE_LINK_PASS | - MVNETA_GMAC_FORCE_LINK_DOWN | - MVNETA_GMAC_AN_FLOW_CTRL_EN); - val |= MVNETA_GMAC_INBAND_AN_ENABLE | - MVNETA_GMAC_AN_SPEED_EN | - MVNETA_GMAC_AN_DUPLEX_EN; - mvreg_write(pp, MVNETA_GMAC_AUTONEG_CONFIG, val); - val = mvreg_read(pp, MVNETA_GMAC_CLOCK_DIVIDER); - val |= MVNETA_GMAC_1MS_CLOCK_ENABLE; - mvreg_write(pp, MVNETA_GMAC_CLOCK_DIVIDER, val); - } else { - val = mvreg_read(pp, MVNETA_GMAC_AUTONEG_CONFIG); - val &= ~(MVNETA_GMAC_INBAND_AN_ENABLE | - MVNETA_GMAC_AN_SPEED_EN | - MVNETA_GMAC_AN_DUPLEX_EN); - mvreg_write(pp, MVNETA_GMAC_AUTONEG_CONFIG, val); - } - + mvneta_set_autoneg(pp, pp->use_inband_status); mvneta_set_ucast_table(pp, -1); mvneta_set_special_mcast_table(pp, -1); mvneta_set_other_mcast_table(pp, -1); @@ -1413,23 +1760,25 @@ static void mvneta_txq_done(struct mvnet } } -static void *mvneta_frag_alloc(const struct mvneta_port *pp) +void *mvneta_frag_alloc(unsigned int frag_size) { - if (likely(pp->frag_size <= PAGE_SIZE)) - return netdev_alloc_frag(pp->frag_size); + if (likely(frag_size <= PAGE_SIZE)) + return netdev_alloc_frag(frag_size); else - return kmalloc(pp->frag_size, GFP_ATOMIC); + return kmalloc(frag_size, GFP_ATOMIC); } +EXPORT_SYMBOL_GPL(mvneta_frag_alloc); -static void mvneta_frag_free(const struct mvneta_port *pp, void *data) +void mvneta_frag_free(unsigned int frag_size, void *data) { - if (likely(pp->frag_size <= PAGE_SIZE)) + if (likely(frag_size <= PAGE_SIZE)) skb_free_frag(data); else kfree(data); } +EXPORT_SYMBOL_GPL(mvneta_frag_free); -/* Refill processing */ +/* Refill processing for SW buffer management */ static int mvneta_rx_refill(struct mvneta_port *pp, struct mvneta_rx_desc *rx_desc) @@ -1437,7 +1786,7 @@ static int mvneta_rx_refill(struct mvnet dma_addr_t phys_addr; void *data; - data = mvneta_frag_alloc(pp); + data = mvneta_frag_alloc(pp->frag_size); if (!data) return -ENOMEM; @@ -1445,7 +1794,7 @@ static int mvneta_rx_refill(struct mvnet MVNETA_RX_BUF_SIZE(pp->pkt_size), DMA_FROM_DEVICE); if (unlikely(dma_mapping_error(pp->dev->dev.parent, phys_addr))) { - mvneta_frag_free(pp, data); + mvneta_frag_free(pp->frag_size, data); return -ENOMEM; } @@ -1491,22 +1840,156 @@ static void mvneta_rxq_drop_pkts(struct int rx_done, i; rx_done = mvneta_rxq_busy_desc_num_get(pp, rxq); + if (rx_done) + mvneta_rxq_desc_num_update(pp, rxq, rx_done, rx_done); + + if (pp->bm_priv) { + for (i = 0; i < rx_done; i++) { + struct mvneta_rx_desc *rx_desc = + mvneta_rxq_next_desc_get(rxq); + u8 pool_id = MVNETA_RX_GET_BM_POOL_ID(rx_desc); + struct mvneta_bm_pool *bm_pool; + + bm_pool = &pp->bm_priv->bm_pools[pool_id]; + /* Return dropped buffer to the pool */ + mvneta_bm_pool_put_bp(pp->bm_priv, bm_pool, + rx_desc->buf_phys_addr); + } + return; + } + for (i = 0; i < rxq->size; i++) { struct mvneta_rx_desc *rx_desc = rxq->descs + i; void *data = (void *)rx_desc->buf_cookie; dma_unmap_single(pp->dev->dev.parent, rx_desc->buf_phys_addr, MVNETA_RX_BUF_SIZE(pp->pkt_size), DMA_FROM_DEVICE); - mvneta_frag_free(pp, data); + mvneta_frag_free(pp->frag_size, data); } +} - if (rx_done) - mvneta_rxq_desc_num_update(pp, rxq, rx_done, rx_done); +/* Main rx processing when using software buffer management */ +static int mvneta_rx_swbm(struct mvneta_port *pp, int rx_todo, + struct mvneta_rx_queue *rxq) +{ + struct mvneta_pcpu_port *port = this_cpu_ptr(pp->ports); + struct net_device *dev = pp->dev; + int rx_done; + u32 rcvd_pkts = 0; + u32 rcvd_bytes = 0; + + /* Get number of received packets */ + rx_done = mvneta_rxq_busy_desc_num_get(pp, rxq); + + if (rx_todo > rx_done) + rx_todo = rx_done; + + rx_done = 0; + + /* Fairness NAPI loop */ + while (rx_done < rx_todo) { + struct mvneta_rx_desc *rx_desc = mvneta_rxq_next_desc_get(rxq); + struct sk_buff *skb; + unsigned char *data; + dma_addr_t phys_addr; + u32 rx_status, frag_size; + int rx_bytes, err; + + rx_done++; + rx_status = rx_desc->status; + rx_bytes = rx_desc->data_size - (ETH_FCS_LEN + MVNETA_MH_SIZE); + data = (unsigned char *)rx_desc->buf_cookie; + phys_addr = rx_desc->buf_phys_addr; + + if (!mvneta_rxq_desc_is_first_last(rx_status) || + (rx_status & MVNETA_RXD_ERR_SUMMARY)) { +err_drop_frame: + dev->stats.rx_errors++; + mvneta_rx_error(pp, rx_desc); + /* leave the descriptor untouched */ + continue; + } + + if (rx_bytes <= rx_copybreak) { + /* better copy a small frame and not unmap the DMA region */ + skb = netdev_alloc_skb_ip_align(dev, rx_bytes); + if (unlikely(!skb)) + goto err_drop_frame; + + dma_sync_single_range_for_cpu(dev->dev.parent, + rx_desc->buf_phys_addr, + MVNETA_MH_SIZE + NET_SKB_PAD, + rx_bytes, + DMA_FROM_DEVICE); + memcpy(skb_put(skb, rx_bytes), + data + MVNETA_MH_SIZE + NET_SKB_PAD, + rx_bytes); + + skb->protocol = eth_type_trans(skb, dev); + mvneta_rx_csum(pp, rx_status, skb); + napi_gro_receive(&port->napi, skb); + + rcvd_pkts++; + rcvd_bytes += rx_bytes; + + /* leave the descriptor and buffer untouched */ + continue; + } + + /* Refill processing */ + err = mvneta_rx_refill(pp, rx_desc); + if (err) { + netdev_err(dev, "Linux processing - Can't refill\n"); + rxq->missed++; + goto err_drop_frame; + } + + frag_size = pp->frag_size; + + skb = build_skb(data, frag_size > PAGE_SIZE ? 0 : frag_size); + + /* After refill old buffer has to be unmapped regardless + * the skb is successfully built or not. + */ + dma_unmap_single(dev->dev.parent, phys_addr, + MVNETA_RX_BUF_SIZE(pp->pkt_size), + DMA_FROM_DEVICE); + + if (!skb) + goto err_drop_frame; + + rcvd_pkts++; + rcvd_bytes += rx_bytes; + + /* Linux processing */ + skb_reserve(skb, MVNETA_MH_SIZE + NET_SKB_PAD); + skb_put(skb, rx_bytes); + + skb->protocol = eth_type_trans(skb, dev); + + mvneta_rx_csum(pp, rx_status, skb); + + napi_gro_receive(&port->napi, skb); + } + + if (rcvd_pkts) { + struct mvneta_pcpu_stats *stats = this_cpu_ptr(pp->stats); + + u64_stats_update_begin(&stats->syncp); + stats->rx_packets += rcvd_pkts; + stats->rx_bytes += rcvd_bytes; + u64_stats_update_end(&stats->syncp); + } + + /* Update rxq management counters */ + mvneta_rxq_desc_num_update(pp, rxq, rx_done, rx_done); + + return rx_done; } -/* Main rx processing */ -static int mvneta_rx(struct mvneta_port *pp, int rx_todo, - struct mvneta_rx_queue *rxq) +/* Main rx processing when using hardware buffer management */ +static int mvneta_rx_hwbm(struct mvneta_port *pp, int rx_todo, + struct mvneta_rx_queue *rxq) { struct mvneta_pcpu_port *port = this_cpu_ptr(pp->ports); struct net_device *dev = pp->dev; @@ -1525,21 +2008,29 @@ static int mvneta_rx(struct mvneta_port /* Fairness NAPI loop */ while (rx_done < rx_todo) { struct mvneta_rx_desc *rx_desc = mvneta_rxq_next_desc_get(rxq); + struct mvneta_bm_pool *bm_pool = NULL; struct sk_buff *skb; unsigned char *data; dma_addr_t phys_addr; - u32 rx_status; + u32 rx_status, frag_size; int rx_bytes, err; + u8 pool_id; rx_done++; rx_status = rx_desc->status; rx_bytes = rx_desc->data_size - (ETH_FCS_LEN + MVNETA_MH_SIZE); data = (unsigned char *)rx_desc->buf_cookie; phys_addr = rx_desc->buf_phys_addr; + pool_id = MVNETA_RX_GET_BM_POOL_ID(rx_desc); + bm_pool = &pp->bm_priv->bm_pools[pool_id]; if (!mvneta_rxq_desc_is_first_last(rx_status) || (rx_status & MVNETA_RXD_ERR_SUMMARY)) { - err_drop_frame: +err_drop_frame_ret_pool: + /* Return the buffer to the pool */ + mvneta_bm_pool_put_bp(pp->bm_priv, bm_pool, + rx_desc->buf_phys_addr); +err_drop_frame: dev->stats.rx_errors++; mvneta_rx_error(pp, rx_desc); /* leave the descriptor untouched */ @@ -1550,7 +2041,7 @@ static int mvneta_rx(struct mvneta_port /* better copy a small frame and not unmap the DMA region */ skb = netdev_alloc_skb_ip_align(dev, rx_bytes); if (unlikely(!skb)) - goto err_drop_frame; + goto err_drop_frame_ret_pool; dma_sync_single_range_for_cpu(dev->dev.parent, rx_desc->buf_phys_addr, @@ -1568,26 +2059,31 @@ static int mvneta_rx(struct mvneta_port rcvd_pkts++; rcvd_bytes += rx_bytes; + /* Return the buffer to the pool */ + mvneta_bm_pool_put_bp(pp->bm_priv, bm_pool, + rx_desc->buf_phys_addr); + /* leave the descriptor and buffer untouched */ continue; } /* Refill processing */ - err = mvneta_rx_refill(pp, rx_desc); + err = hwbm_pool_refill(&bm_pool->hwbm_pool, GFP_ATOMIC); if (err) { netdev_err(dev, "Linux processing - Can't refill\n"); rxq->missed++; - goto err_drop_frame; + goto err_drop_frame_ret_pool; } - skb = build_skb(data, pp->frag_size > PAGE_SIZE ? 0 : pp->frag_size); + frag_size = bm_pool->hwbm_pool.frag_size; + + skb = build_skb(data, frag_size > PAGE_SIZE ? 0 : frag_size); /* After refill old buffer has to be unmapped regardless * the skb is successfully built or not. */ - dma_unmap_single(dev->dev.parent, phys_addr, - MVNETA_RX_BUF_SIZE(pp->pkt_size), DMA_FROM_DEVICE); - + dma_unmap_single(&pp->bm_priv->pdev->dev, phys_addr, + bm_pool->buf_size, DMA_FROM_DEVICE); if (!skb) goto err_drop_frame; @@ -2082,19 +2578,19 @@ static void mvneta_set_rx_mode(struct ne if (dev->flags & IFF_PROMISC) { /* Accept all: Multicast + Unicast */ mvneta_rx_unicast_promisc_set(pp, 1); - mvneta_set_ucast_table(pp, rxq_def); - mvneta_set_special_mcast_table(pp, rxq_def); - mvneta_set_other_mcast_table(pp, rxq_def); + mvneta_set_ucast_table(pp, pp->rxq_def); + mvneta_set_special_mcast_table(pp, pp->rxq_def); + mvneta_set_other_mcast_table(pp, pp->rxq_def); } else { /* Accept single Unicast */ mvneta_rx_unicast_promisc_set(pp, 0); mvneta_set_ucast_table(pp, -1); - mvneta_mac_addr_set(pp, dev->dev_addr, rxq_def); + mvneta_mac_addr_set(pp, dev->dev_addr, pp->rxq_def); if (dev->flags & IFF_ALLMULTI) { /* Accept all multicast */ - mvneta_set_special_mcast_table(pp, rxq_def); - mvneta_set_other_mcast_table(pp, rxq_def); + mvneta_set_special_mcast_table(pp, pp->rxq_def); + mvneta_set_other_mcast_table(pp, pp->rxq_def); } else { /* Accept only initialized multicast */ mvneta_set_special_mcast_table(pp, -1); @@ -2103,7 +2599,7 @@ static void mvneta_set_rx_mode(struct ne if (!netdev_mc_empty(dev)) { netdev_for_each_mc_addr(ha, dev) { mvneta_mcast_addr_set(pp, ha->addr, - rxq_def); + pp->rxq_def); } } } @@ -2154,6 +2650,7 @@ static int mvneta_poll(struct napi_struc { int rx_done = 0; u32 cause_rx_tx; + int rx_queue; struct mvneta_port *pp = netdev_priv(napi->dev); struct mvneta_pcpu_port *port = this_cpu_ptr(pp->ports); @@ -2185,8 +2682,18 @@ static int mvneta_poll(struct napi_struc /* For the case where the last mvneta_poll did not process all * RX packets */ + rx_queue = fls(((cause_rx_tx >> 8) & 0xff)); + cause_rx_tx |= port->cause_rx_tx; - rx_done = mvneta_rx(pp, budget, &pp->rxqs[rxq_def]); + + if (rx_queue) { + rx_queue = rx_queue - 1; + if (pp->bm_priv) + rx_done = mvneta_rx_hwbm(pp, budget, &pp->rxqs[rx_queue]); + else + rx_done = mvneta_rx_swbm(pp, budget, &pp->rxqs[rx_queue]); + } + budget -= rx_done; if (budget > 0) { @@ -2273,9 +2780,17 @@ static int mvneta_rxq_init(struct mvneta mvneta_rx_pkts_coal_set(pp, rxq, rxq->pkts_coal); mvneta_rx_time_coal_set(pp, rxq, rxq->time_coal); - /* Fill RXQ with buffers from RX pool */ - mvneta_rxq_buf_size_set(pp, rxq, MVNETA_RX_BUF_SIZE(pp->pkt_size)); - mvneta_rxq_bm_disable(pp, rxq); + if (!pp->bm_priv) { + /* Fill RXQ with buffers from RX pool */ + mvneta_rxq_buf_size_set(pp, rxq, + MVNETA_RX_BUF_SIZE(pp->pkt_size)); + mvneta_rxq_bm_disable(pp, rxq); + } else { + mvneta_rxq_bm_enable(pp, rxq); + mvneta_rxq_long_pool_set(pp, rxq); + mvneta_rxq_short_pool_set(pp, rxq); + } + mvneta_rxq_fill(pp, rxq, rxq->size); return 0; @@ -2303,6 +2818,8 @@ static void mvneta_rxq_deinit(struct mvn static int mvneta_txq_init(struct mvneta_port *pp, struct mvneta_tx_queue *txq) { + int cpu; + txq->size = pp->tx_ring_size; /* A queue must always have room for at least one skb. @@ -2355,6 +2872,14 @@ static int mvneta_txq_init(struct mvneta } mvneta_tx_done_pkts_coal_set(pp, txq, txq->done_pkts_coal); + /* Setup XPS mapping */ + if (txq_number > 1) + cpu = txq->id % num_present_cpus(); + else + cpu = pp->rxq_def % num_present_cpus(); + cpumask_set_cpu(cpu, &txq->affinity_mask); + netif_set_xps_queue(pp->dev, &txq->affinity_mask, txq->id); + return 0; } @@ -2399,19 +2924,27 @@ static void mvneta_cleanup_txqs(struct m /* Cleanup all Rx queues */ static void mvneta_cleanup_rxqs(struct mvneta_port *pp) { - mvneta_rxq_deinit(pp, &pp->rxqs[rxq_def]); + int queue; + + for (queue = 0; queue < txq_number; queue++) + mvneta_rxq_deinit(pp, &pp->rxqs[queue]); } /* Init all Rx queues */ static int mvneta_setup_rxqs(struct mvneta_port *pp) { - int err = mvneta_rxq_init(pp, &pp->rxqs[rxq_def]); - if (err) { - netdev_err(pp->dev, "%s: can't create rxq=%d\n", - __func__, rxq_def); - mvneta_cleanup_rxqs(pp); - return err; + int queue; + + for (queue = 0; queue < rxq_number; queue++) { + int err = mvneta_rxq_init(pp, &pp->rxqs[queue]); + + if (err) { + netdev_err(pp->dev, "%s: can't create rxq=%d\n", + __func__, queue); + mvneta_cleanup_rxqs(pp); + return err; + } } return 0; @@ -2437,7 +2970,7 @@ static int mvneta_setup_txqs(struct mvne static void mvneta_start_dev(struct mvneta_port *pp) { - unsigned int cpu; + int cpu; mvneta_max_rx_size_set(pp, pp->pkt_size); mvneta_txq_max_tx_size_set(pp, pp->pkt_size); @@ -2446,17 +2979,15 @@ static void mvneta_start_dev(struct mvne mvneta_port_enable(pp); /* Enable polling on the port */ - for_each_present_cpu(cpu) { + for_each_online_cpu(cpu) { struct mvneta_pcpu_port *port = per_cpu_ptr(pp->ports, cpu); napi_enable(&port->napi); } - /* Unmask interrupts */ - mvreg_write(pp, MVNETA_INTR_NEW_MASK, - MVNETA_RX_INTR_MASK(rxq_number) | - MVNETA_TX_INTR_MASK(txq_number) | - MVNETA_MISCINTR_INTR_MASK); + /* Unmask interrupts. It has to be done from each CPU */ + on_each_cpu(mvneta_percpu_unmask_interrupt, pp, true); + mvreg_write(pp, MVNETA_INTR_MISC_MASK, MVNETA_CAUSE_PHY_STATUS_CHANGE | MVNETA_CAUSE_LINK_CHANGE | @@ -2472,7 +3003,7 @@ static void mvneta_stop_dev(struct mvnet phy_stop(pp->phy_dev); - for_each_present_cpu(cpu) { + for_each_online_cpu(cpu) { struct mvneta_pcpu_port *port = per_cpu_ptr(pp->ports, cpu); napi_disable(&port->napi); @@ -2487,13 +3018,10 @@ static void mvneta_stop_dev(struct mvnet mvneta_port_disable(pp); /* Clear all ethernet port interrupts */ - mvreg_write(pp, MVNETA_INTR_MISC_CAUSE, 0); - mvreg_write(pp, MVNETA_INTR_OLD_CAUSE, 0); + on_each_cpu(mvneta_percpu_clear_intr_cause, pp, true); /* Mask all ethernet port interrupts */ - mvreg_write(pp, MVNETA_INTR_NEW_MASK, 0); - mvreg_write(pp, MVNETA_INTR_OLD_MASK, 0); - mvreg_write(pp, MVNETA_INTR_MISC_MASK, 0); + on_each_cpu(mvneta_percpu_mask_interrupt, pp, true); mvneta_tx_reset(pp); mvneta_rx_reset(pp); @@ -2535,6 +3063,9 @@ static int mvneta_change_mtu(struct net_ dev->mtu = mtu; if (!netif_running(dev)) { + if (pp->bm_priv) + mvneta_bm_update_mtu(pp, mtu); + netdev_update_features(dev); return 0; } @@ -2547,6 +3078,9 @@ static int mvneta_change_mtu(struct net_ mvneta_cleanup_txqs(pp); mvneta_cleanup_rxqs(pp); + if (pp->bm_priv) + mvneta_bm_update_mtu(pp, mtu); + pp->pkt_size = MVNETA_RX_PKT_SIZE(dev->mtu); pp->frag_size = SKB_DATA_ALIGN(MVNETA_RX_BUF_SIZE(pp->pkt_size)) + SKB_DATA_ALIGN(sizeof(struct skb_shared_info)); @@ -2615,7 +3149,7 @@ static int mvneta_set_mac_addr(struct ne mvneta_mac_addr_set(pp, dev->dev_addr, -1); /* Set new addr in hw */ - mvneta_mac_addr_set(pp, sockaddr->sa_data, rxq_def); + mvneta_mac_addr_set(pp, sockaddr->sa_data, pp->rxq_def); eth_commit_mac_addr_change(dev, addr); return 0; @@ -2730,24 +3264,56 @@ static void mvneta_percpu_disable(void * disable_percpu_irq(pp->dev->irq); } +/* Electing a CPU must be done in an atomic way: it should be done + * after or before the removal/insertion of a CPU and this function is + * not reentrant. + */ static void mvneta_percpu_elect(struct mvneta_port *pp) { - int online_cpu_idx, cpu, i = 0; + int elected_cpu = 0, max_cpu, cpu, i = 0; - online_cpu_idx = rxq_def % num_online_cpus(); + /* Use the cpu associated to the rxq when it is online, in all + * the other cases, use the cpu 0 which can't be offline. + */ + if (cpu_online(pp->rxq_def)) + elected_cpu = pp->rxq_def; + + max_cpu = num_present_cpus(); for_each_online_cpu(cpu) { - if (i == online_cpu_idx) - /* Enable per-CPU interrupt on the one CPU we - * just elected + int rxq_map = 0, txq_map = 0; + int rxq; + + for (rxq = 0; rxq < rxq_number; rxq++) + if ((rxq % max_cpu) == cpu) + rxq_map |= MVNETA_CPU_RXQ_ACCESS(rxq); + + if (cpu == elected_cpu) + /* Map the default receive queue queue to the + * elected CPU */ - smp_call_function_single(cpu, mvneta_percpu_enable, - pp, true); + rxq_map |= MVNETA_CPU_RXQ_ACCESS(pp->rxq_def); + + /* We update the TX queue map only if we have one + * queue. In this case we associate the TX queue to + * the CPU bound to the default RX queue + */ + if (txq_number == 1) + txq_map = (cpu == elected_cpu) ? + MVNETA_CPU_TXQ_ACCESS(1) : 0; else - /* Disable per-CPU interrupt on all the other CPU */ - smp_call_function_single(cpu, mvneta_percpu_disable, - pp, true); + txq_map = mvreg_read(pp, MVNETA_CPU_MAP(cpu)) & + MVNETA_CPU_TXQ_ACCESS_ALL_MASK; + + mvreg_write(pp, MVNETA_CPU_MAP(cpu), rxq_map | txq_map); + + /* Update the interrupt mask on each CPU according the + * new mapping + */ + smp_call_function_single(cpu, mvneta_percpu_unmask_interrupt, + pp, true); i++; + } }; @@ -2762,6 +3328,14 @@ static int mvneta_percpu_notifier(struct switch (action) { case CPU_ONLINE: case CPU_ONLINE_FROZEN: + spin_lock(&pp->lock); + /* Configuring the driver for a new CPU while the + * driver is stopping is racy, so just avoid it. + */ + if (pp->is_stopped) { + spin_unlock(&pp->lock); + break; + } netif_tx_stop_all_queues(pp->dev); /* We have to synchronise on tha napi of each CPU @@ -2777,34 +3351,40 @@ static int mvneta_percpu_notifier(struct } /* Mask all ethernet port interrupts */ - mvreg_write(pp, MVNETA_INTR_NEW_MASK, 0); - mvreg_write(pp, MVNETA_INTR_OLD_MASK, 0); - mvreg_write(pp, MVNETA_INTR_MISC_MASK, 0); + on_each_cpu(mvneta_percpu_mask_interrupt, pp, true); napi_enable(&port->napi); + + /* Enable per-CPU interrupts on the CPU that is + * brought up. + */ + smp_call_function_single(cpu, mvneta_percpu_enable, + pp, true); + /* Enable per-CPU interrupt on the one CPU we care * about. */ mvneta_percpu_elect(pp); /* Unmask all ethernet port interrupts */ - mvreg_write(pp, MVNETA_INTR_NEW_MASK, - MVNETA_RX_INTR_MASK(rxq_number) | - MVNETA_TX_INTR_MASK(txq_number) | - MVNETA_MISCINTR_INTR_MASK); + on_each_cpu(mvneta_percpu_unmask_interrupt, pp, true); mvreg_write(pp, MVNETA_INTR_MISC_MASK, MVNETA_CAUSE_PHY_STATUS_CHANGE | MVNETA_CAUSE_LINK_CHANGE | MVNETA_CAUSE_PSC_SYNC_CHANGE); netif_tx_start_all_queues(pp->dev); + spin_unlock(&pp->lock); break; case CPU_DOWN_PREPARE: case CPU_DOWN_PREPARE_FROZEN: netif_tx_stop_all_queues(pp->dev); + /* Thanks to this lock we are sure that any pending + * cpu election is done + */ + spin_lock(&pp->lock); /* Mask all ethernet port interrupts */ - mvreg_write(pp, MVNETA_INTR_NEW_MASK, 0); - mvreg_write(pp, MVNETA_INTR_OLD_MASK, 0); - mvreg_write(pp, MVNETA_INTR_MISC_MASK, 0); + on_each_cpu(mvneta_percpu_mask_interrupt, pp, true); + spin_unlock(&pp->lock); napi_synchronize(&port->napi); napi_disable(&port->napi); @@ -2818,12 +3398,11 @@ static int mvneta_percpu_notifier(struct case CPU_DEAD: case CPU_DEAD_FROZEN: /* Check if a new CPU must be elected now this on is down */ + spin_lock(&pp->lock); mvneta_percpu_elect(pp); + spin_unlock(&pp->lock); /* Unmask all ethernet port interrupts */ - mvreg_write(pp, MVNETA_INTR_NEW_MASK, - MVNETA_RX_INTR_MASK(rxq_number) | - MVNETA_TX_INTR_MASK(txq_number) | - MVNETA_MISCINTR_INTR_MASK); + on_each_cpu(mvneta_percpu_unmask_interrupt, pp, true); mvreg_write(pp, MVNETA_INTR_MISC_MASK, MVNETA_CAUSE_PHY_STATUS_CHANGE | MVNETA_CAUSE_LINK_CHANGE | @@ -2860,17 +3439,12 @@ static int mvneta_open(struct net_device goto err_cleanup_txqs; } - /* Even though the documentation says that request_percpu_irq - * doesn't enable the interrupts automatically, it actually - * does so on the local CPU. - * - * Make sure it's disabled. + /* Enable per-CPU interrupt on all the CPU to handle our RX + * queue interrupts */ - mvneta_percpu_disable(pp); - - /* Elect a CPU to handle our RX queue interrupt */ - mvneta_percpu_elect(pp); + on_each_cpu(mvneta_percpu_enable, pp, true); + pp->is_stopped = false; /* Register a CPU notifier to handle the case where our CPU * might be taken offline. */ @@ -2902,13 +3476,20 @@ err_cleanup_rxqs: static int mvneta_stop(struct net_device *dev) { struct mvneta_port *pp = netdev_priv(dev); - int cpu; + /* Inform that we are stopping so we don't want to setup the + * driver for new CPUs in the notifiers + */ + spin_lock(&pp->lock); + pp->is_stopped = true; mvneta_stop_dev(pp); mvneta_mdio_remove(pp); unregister_cpu_notifier(&pp->cpu_notifier); - for_each_present_cpu(cpu) - smp_call_function_single(cpu, mvneta_percpu_disable, pp, true); + /* Now that the notifier are unregistered, we can release le + * lock + */ + spin_unlock(&pp->lock); + on_each_cpu(mvneta_percpu_disable, pp, true); free_percpu_irq(dev->irq, pp->ports); mvneta_cleanup_rxqs(pp); mvneta_cleanup_txqs(pp); @@ -2943,10 +3524,43 @@ int mvneta_ethtool_get_settings(struct n int mvneta_ethtool_set_settings(struct net_device *dev, struct ethtool_cmd *cmd) { struct mvneta_port *pp = netdev_priv(dev); + struct phy_device *phydev = pp->phy_dev; - if (!pp->phy_dev) + if (!phydev) return -ENODEV; + if ((cmd->autoneg == AUTONEG_ENABLE) != pp->use_inband_status) { + u32 val; + + mvneta_set_autoneg(pp, cmd->autoneg == AUTONEG_ENABLE); + + if (cmd->autoneg == AUTONEG_DISABLE) { + val = mvreg_read(pp, MVNETA_GMAC_AUTONEG_CONFIG); + val &= ~(MVNETA_GMAC_CONFIG_MII_SPEED | + MVNETA_GMAC_CONFIG_GMII_SPEED | + MVNETA_GMAC_CONFIG_FULL_DUPLEX); + + if (phydev->duplex) + val |= MVNETA_GMAC_CONFIG_FULL_DUPLEX; + + if (phydev->speed == SPEED_1000) + val |= MVNETA_GMAC_CONFIG_GMII_SPEED; + else if (phydev->speed == SPEED_100) + val |= MVNETA_GMAC_CONFIG_MII_SPEED; + + mvreg_write(pp, MVNETA_GMAC_AUTONEG_CONFIG, val); + } + + pp->use_inband_status = (cmd->autoneg == AUTONEG_ENABLE); + netdev_info(pp->dev, "autoneg status set to %i\n", + pp->use_inband_status); + + if (netif_running(dev)) { + mvneta_port_down(pp); + mvneta_port_up(pp); + } + } + return phy_ethtool_sset(pp->phy_dev, cmd); } @@ -3056,26 +3670,25 @@ static void mvneta_ethtool_update_stats( const struct mvneta_statistic *s; void __iomem *base = pp->base; u32 high, low, val; + u64 val64; int i; for (i = 0, s = mvneta_statistics; s < mvneta_statistics + ARRAY_SIZE(mvneta_statistics); s++, i++) { - val = 0; - switch (s->type) { case T_REG_32: val = readl_relaxed(base + s->offset); + pp->ethtool_stats[i] += val; break; case T_REG_64: /* Docs say to read low 32-bit then high */ low = readl_relaxed(base + s->offset); high = readl_relaxed(base + s->offset + 4); - val = (u64)high << 32 | low; + val64 = (u64)high << 32 | low; + pp->ethtool_stats[i] += val64; break; } - - pp->ethtool_stats[i] += val; } } @@ -3098,6 +3711,106 @@ static int mvneta_ethtool_get_sset_count return -EOPNOTSUPP; } +static u32 mvneta_ethtool_get_rxfh_indir_size(struct net_device *dev) +{ + return MVNETA_RSS_LU_TABLE_SIZE; +} + +static int mvneta_ethtool_get_rxnfc(struct net_device *dev, + struct ethtool_rxnfc *info, + u32 *rules __always_unused) +{ + switch (info->cmd) { + case ETHTOOL_GRXRINGS: + info->data = rxq_number; + return 0; + case ETHTOOL_GRXFH: + return -EOPNOTSUPP; + default: + return -EOPNOTSUPP; + } +} + +static int mvneta_config_rss(struct mvneta_port *pp) +{ + int cpu; + u32 val; + + netif_tx_stop_all_queues(pp->dev); + + on_each_cpu(mvneta_percpu_mask_interrupt, pp, true); + + /* We have to synchronise on the napi of each CPU */ + for_each_online_cpu(cpu) { + struct mvneta_pcpu_port *pcpu_port = + per_cpu_ptr(pp->ports, cpu); + + napi_synchronize(&pcpu_port->napi); + napi_disable(&pcpu_port->napi); + } + + pp->rxq_def = pp->indir[0]; + + /* Update unicast mapping */ + mvneta_set_rx_mode(pp->dev); + + /* Update val of portCfg register accordingly with all RxQueue types */ + val = MVNETA_PORT_CONFIG_DEFL_VALUE(pp->rxq_def); + mvreg_write(pp, MVNETA_PORT_CONFIG, val); + + /* Update the elected CPU matching the new rxq_def */ + spin_lock(&pp->lock); + mvneta_percpu_elect(pp); + spin_unlock(&pp->lock); + + /* We have to synchronise on the napi of each CPU */ + for_each_online_cpu(cpu) { + struct mvneta_pcpu_port *pcpu_port = + per_cpu_ptr(pp->ports, cpu); + + napi_enable(&pcpu_port->napi); + } + + netif_tx_start_all_queues(pp->dev); + + return 0; +} + +static int mvneta_ethtool_set_rxfh(struct net_device *dev, const u32 *indir, + const u8 *key, const u8 hfunc) +{ + struct mvneta_port *pp = netdev_priv(dev); + /* We require at least one supported parameter to be changed + * and no change in any of the unsupported parameters + */ + if (key || + (hfunc != ETH_RSS_HASH_NO_CHANGE && hfunc != ETH_RSS_HASH_TOP)) + return -EOPNOTSUPP; + + if (!indir) + return 0; + + memcpy(pp->indir, indir, MVNETA_RSS_LU_TABLE_SIZE); + + return mvneta_config_rss(pp); +} + +static int mvneta_ethtool_get_rxfh(struct net_device *dev, u32 *indir, u8 *key, + u8 *hfunc) +{ + struct mvneta_port *pp = netdev_priv(dev); + + if (hfunc) + *hfunc = ETH_RSS_HASH_TOP; + + if (!indir) + return 0; + + memcpy(indir, pp->indir, MVNETA_RSS_LU_TABLE_SIZE); + + return 0; +} + static const struct net_device_ops mvneta_netdev_ops = { .ndo_open = mvneta_open, .ndo_stop = mvneta_stop, @@ -3122,6 +3835,10 @@ const struct ethtool_ops mvneta_eth_tool .get_strings = mvneta_ethtool_get_strings, .get_ethtool_stats = mvneta_ethtool_get_stats, .get_sset_count = mvneta_ethtool_get_sset_count, + .get_rxfh_indir_size = mvneta_ethtool_get_rxfh_indir_size, + .get_rxnfc = mvneta_ethtool_get_rxnfc, + .get_rxfh = mvneta_ethtool_get_rxfh, + .set_rxfh = mvneta_ethtool_set_rxfh, }; /* Initialize hw */ @@ -3230,9 +3947,6 @@ static int mvneta_port_power_up(struct m return -EINVAL; } - if (pp->use_inband_status) - ctrl |= MVNETA_GMAC2_INBAND_AN_ENABLE; - /* Cancel Port Reset */ ctrl &= ~MVNETA_GMAC2_PORT_RESET; mvreg_write(pp, MVNETA_GMAC_CTRL_2, ctrl); @@ -3251,6 +3965,7 @@ static int mvneta_probe(struct platform_ struct resource *res; struct device_node *dn = pdev->dev.of_node; struct device_node *phy_node; + struct device_node *bm_node; struct mvneta_port *pp; struct net_device *dev; const char *dt_mac_addr; @@ -3314,7 +4029,13 @@ static int mvneta_probe(struct platform_ strcmp(managed, "in-band-status") == 0); pp->cpu_notifier.notifier_call = mvneta_percpu_notifier; - pp->clk = devm_clk_get(&pdev->dev, NULL); + pp->rxq_def = rxq_def; + + pp->indir[0] = rxq_def; + + pp->clk = devm_clk_get(&pdev->dev, "core"); + if (IS_ERR(pp->clk)) + pp->clk = devm_clk_get(&pdev->dev, NULL); if (IS_ERR(pp->clk)) { err = PTR_ERR(pp->clk); goto err_put_phy_node; @@ -3322,6 +4043,10 @@ static int mvneta_probe(struct platform_ clk_prepare_enable(pp->clk); + pp->clk_bus = devm_clk_get(&pdev->dev, "bus"); + if (!IS_ERR(pp->clk_bus)) + clk_prepare_enable(pp->clk_bus); + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); pp->base = devm_ioremap_resource(&pdev->dev, res); if (IS_ERR(pp->base)) { @@ -3374,26 +4099,39 @@ static int mvneta_probe(struct platform_ pp->tx_csum_limit = tx_csum_limit; + dram_target_info = mv_mbus_dram_info(); + if (dram_target_info) + mvneta_conf_mbus_windows(pp, dram_target_info); + pp->tx_ring_size = MVNETA_MAX_TXD; pp->rx_ring_size = MVNETA_MAX_RXD; pp->dev = dev; SET_NETDEV_DEV(dev, &pdev->dev); + pp->id = global_port_id++; + + /* Obtain access to BM resources if enabled and already initialized */ + bm_node = of_parse_phandle(dn, "buffer-manager", 0); + if (bm_node && bm_node->data) { + pp->bm_priv = bm_node->data; + err = mvneta_bm_port_init(pdev, pp); + if (err < 0) { + dev_info(&pdev->dev, "use SW buffer management\n"); + pp->bm_priv = NULL; + } + } + err = mvneta_init(&pdev->dev, pp); if (err < 0) - goto err_free_stats; + goto err_netdev; err = mvneta_port_power_up(pp, phy_mode); if (err < 0) { dev_err(&pdev->dev, "can't power up port\n"); - goto err_free_stats; + goto err_netdev; } - dram_target_info = mv_mbus_dram_info(); - if (dram_target_info) - mvneta_conf_mbus_windows(pp, dram_target_info); - for_each_present_cpu(cpu) { struct mvneta_pcpu_port *port = per_cpu_ptr(pp->ports, cpu); @@ -3423,16 +4161,24 @@ static int mvneta_probe(struct platform_ mvneta_fixed_link_update(pp, phy); - put_device(&phy->dev); + put_device(&phy->dev); } return 0; +err_netdev: + unregister_netdev(dev); + if (pp->bm_priv) { + mvneta_bm_pool_destroy(pp->bm_priv, pp->pool_long, 1 << pp->id); + mvneta_bm_pool_destroy(pp->bm_priv, pp->pool_short, + 1 << pp->id); + } err_free_stats: free_percpu(pp->stats); err_free_ports: free_percpu(pp->ports); err_clk: + clk_disable_unprepare(pp->clk_bus); clk_disable_unprepare(pp->clk); err_put_phy_node: of_node_put(phy_node); @@ -3450,6 +4196,7 @@ static int mvneta_remove(struct platform struct mvneta_port *pp = netdev_priv(dev); unregister_netdev(dev); + clk_disable_unprepare(pp->clk_bus); clk_disable_unprepare(pp->clk); free_percpu(pp->ports); free_percpu(pp->stats); @@ -3457,6 +4204,12 @@ static int mvneta_remove(struct platform of_node_put(pp->phy_node); free_netdev(dev); + if (pp->bm_priv) { + mvneta_bm_pool_destroy(pp->bm_priv, pp->pool_long, 1 << pp->id); + mvneta_bm_pool_destroy(pp->bm_priv, pp->pool_short, + 1 << pp->id); + } + return 0; } --- a/dev/null +++ b/drivers/net/ethernet/marvell/mvneta_bm.c @@ -0,0 +1,487 @@ +/* + * Driver for Marvell NETA network controller Buffer Manager. + * + * Copyright (C) 2015 Marvell + * + * Marcin Wojtas + * + * This file is licensed under the terms of the GNU General Public + * License version 2. This program is licensed "as is" without any + * warranty of any kind, whether express or implied. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include "mvneta_bm.h" + +#define MVNETA_BM_DRIVER_NAME "mvneta_bm" +#define MVNETA_BM_DRIVER_VERSION "1.0" + +static void mvneta_bm_write(struct mvneta_bm *priv, u32 offset, u32 data) +{ + writel(data, priv->reg_base + offset); +} + +static u32 mvneta_bm_read(struct mvneta_bm *priv, u32 offset) +{ + return readl(priv->reg_base + offset); +} + +static void mvneta_bm_pool_enable(struct mvneta_bm *priv, int pool_id) +{ + u32 val; + + val = mvneta_bm_read(priv, MVNETA_BM_POOL_BASE_REG(pool_id)); + val |= MVNETA_BM_POOL_ENABLE_MASK; + mvneta_bm_write(priv, MVNETA_BM_POOL_BASE_REG(pool_id), val); + + /* Clear BM cause register */ + mvneta_bm_write(priv, MVNETA_BM_INTR_CAUSE_REG, 0); +} + +static void mvneta_bm_pool_disable(struct mvneta_bm *priv, int pool_id) +{ + u32 val; + + val = mvneta_bm_read(priv, MVNETA_BM_POOL_BASE_REG(pool_id)); + val &= ~MVNETA_BM_POOL_ENABLE_MASK; + mvneta_bm_write(priv, MVNETA_BM_POOL_BASE_REG(pool_id), val); +} + +static inline void mvneta_bm_config_set(struct mvneta_bm *priv, u32 mask) +{ + u32 val; + + val = mvneta_bm_read(priv, MVNETA_BM_CONFIG_REG); + val |= mask; + mvneta_bm_write(priv, MVNETA_BM_CONFIG_REG, val); +} + +static inline void mvneta_bm_config_clear(struct mvneta_bm *priv, u32 mask) +{ + u32 val; + + val = mvneta_bm_read(priv, MVNETA_BM_CONFIG_REG); + val &= ~mask; + mvneta_bm_write(priv, MVNETA_BM_CONFIG_REG, val); +} + +static void mvneta_bm_pool_target_set(struct mvneta_bm *priv, int pool_id, + u8 target_id, u8 attr) +{ + u32 val; + + val = mvneta_bm_read(priv, MVNETA_BM_XBAR_POOL_REG(pool_id)); + val &= ~MVNETA_BM_TARGET_ID_MASK(pool_id); + val &= ~MVNETA_BM_XBAR_ATTR_MASK(pool_id); + val |= MVNETA_BM_TARGET_ID_VAL(pool_id, target_id); + val |= MVNETA_BM_XBAR_ATTR_VAL(pool_id, attr); + + mvneta_bm_write(priv, MVNETA_BM_XBAR_POOL_REG(pool_id), val); +} + +int mvneta_bm_construct(struct hwbm_pool *hwbm_pool, void *buf) +{ + struct mvneta_bm_pool *bm_pool = + (struct mvneta_bm_pool *)hwbm_pool->priv; + struct mvneta_bm *priv = bm_pool->priv; + dma_addr_t phys_addr; + + /* In order to update buf_cookie field of RX descriptor properly, + * BM hardware expects buf virtual address to be placed in the + * first four bytes of mapped buffer. + */ + *(u32 *)buf = (u32)buf; + phys_addr = dma_map_single(&priv->pdev->dev, buf, bm_pool->buf_size, + DMA_FROM_DEVICE); + if (unlikely(dma_mapping_error(&priv->pdev->dev, phys_addr))) + return -ENOMEM; + + mvneta_bm_pool_put_bp(priv, bm_pool, phys_addr); + return 0; +} +EXPORT_SYMBOL_GPL(mvneta_bm_construct); + +/* Create pool */ +static int mvneta_bm_pool_create(struct mvneta_bm *priv, + struct mvneta_bm_pool *bm_pool) +{ + struct platform_device *pdev = priv->pdev; + u8 target_id, attr; + int size_bytes, err; + size_bytes = sizeof(u32) * bm_pool->hwbm_pool.size; + bm_pool->virt_addr = dma_alloc_coherent(&pdev->dev, size_bytes, + &bm_pool->phys_addr, + GFP_KERNEL); + if (!bm_pool->virt_addr) + return -ENOMEM; + + if (!IS_ALIGNED((u32)bm_pool->virt_addr, MVNETA_BM_POOL_PTR_ALIGN)) { + dma_free_coherent(&pdev->dev, size_bytes, bm_pool->virt_addr, + bm_pool->phys_addr); + dev_err(&pdev->dev, "BM pool %d is not %d bytes aligned\n", + bm_pool->id, MVNETA_BM_POOL_PTR_ALIGN); + return -ENOMEM; + } + + err = mvebu_mbus_get_dram_win_info(bm_pool->phys_addr, &target_id, + &attr); + if (err < 0) { + dma_free_coherent(&pdev->dev, size_bytes, bm_pool->virt_addr, + bm_pool->phys_addr); + return err; + } + + /* Set pool address */ + mvneta_bm_write(priv, MVNETA_BM_POOL_BASE_REG(bm_pool->id), + bm_pool->phys_addr); + + mvneta_bm_pool_target_set(priv, bm_pool->id, target_id, attr); + mvneta_bm_pool_enable(priv, bm_pool->id); + + return 0; +} + +/* Notify the driver that BM pool is being used as specific type and return the + * pool pointer on success + */ +struct mvneta_bm_pool *mvneta_bm_pool_use(struct mvneta_bm *priv, u8 pool_id, + enum mvneta_bm_type type, u8 port_id, + int pkt_size) +{ + struct mvneta_bm_pool *new_pool = &priv->bm_pools[pool_id]; + int num, err; + + if (new_pool->type == MVNETA_BM_LONG && + new_pool->port_map != 1 << port_id) { + dev_err(&priv->pdev->dev, + "long pool cannot be shared by the ports\n"); + return NULL; + } + + if (new_pool->type == MVNETA_BM_SHORT && new_pool->type != type) { + dev_err(&priv->pdev->dev, + "mixing pools' types between the ports is forbidden\n"); + return NULL; + } + + if (new_pool->pkt_size == 0 || type != MVNETA_BM_SHORT) + new_pool->pkt_size = pkt_size; + + /* Allocate buffers in case BM pool hasn't been used yet */ + if (new_pool->type == MVNETA_BM_FREE) { + struct hwbm_pool *hwbm_pool = &new_pool->hwbm_pool; + + new_pool->priv = priv; + new_pool->type = type; + new_pool->buf_size = MVNETA_RX_BUF_SIZE(new_pool->pkt_size); + hwbm_pool->frag_size = + SKB_DATA_ALIGN(MVNETA_RX_BUF_SIZE(new_pool->pkt_size)) + + SKB_DATA_ALIGN(sizeof(struct skb_shared_info)); + hwbm_pool->construct = mvneta_bm_construct; + hwbm_pool->priv = new_pool; + + /* Create new pool */ + err = mvneta_bm_pool_create(priv, new_pool); + if (err) { + dev_err(&priv->pdev->dev, "fail to create pool %d\n", + new_pool->id); + return NULL; + } + + /* Allocate buffers for this pool */ + num = hwbm_pool_add(hwbm_pool, hwbm_pool->size, GFP_ATOMIC); + if (num != hwbm_pool->size) { + WARN(1, "pool %d: %d of %d allocated\n", + new_pool->id, num, hwbm_pool->size); + return NULL; + } + } + + return new_pool; +} +EXPORT_SYMBOL_GPL(mvneta_bm_pool_use); + +/* Free all buffers from the pool */ +void mvneta_bm_bufs_free(struct mvneta_bm *priv, struct mvneta_bm_pool *bm_pool, + u8 port_map) +{ + int i; + + bm_pool->port_map &= ~port_map; + if (bm_pool->port_map) + return; + + mvneta_bm_config_set(priv, MVNETA_BM_EMPTY_LIMIT_MASK); + + for (i = 0; i < bm_pool->hwbm_pool.buf_num; i++) { + dma_addr_t buf_phys_addr; + u32 *vaddr; + + /* Get buffer physical address (indirect access) */ + buf_phys_addr = mvneta_bm_pool_get_bp(priv, bm_pool); + + /* Work-around to the problems when destroying the pool, + * when it occurs that a read access to BPPI returns 0. + */ + if (buf_phys_addr == 0) + continue; + + vaddr = phys_to_virt(buf_phys_addr); + if (!vaddr) + break; + + dma_unmap_single(&priv->pdev->dev, buf_phys_addr, + bm_pool->buf_size, DMA_FROM_DEVICE); + hwbm_buf_free(&bm_pool->hwbm_pool, vaddr); + } + + mvneta_bm_config_clear(priv, MVNETA_BM_EMPTY_LIMIT_MASK); + + /* Update BM driver with number of buffers removed from pool */ + bm_pool->hwbm_pool.buf_num -= i; +} +EXPORT_SYMBOL_GPL(mvneta_bm_bufs_free); + +/* Cleanup pool */ +void mvneta_bm_pool_destroy(struct mvneta_bm *priv, + struct mvneta_bm_pool *bm_pool, u8 port_map) +{ + struct hwbm_pool *hwbm_pool = &bm_pool->hwbm_pool; + bm_pool->port_map &= ~port_map; + if (bm_pool->port_map) + return; + + bm_pool->type = MVNETA_BM_FREE; + + mvneta_bm_bufs_free(priv, bm_pool, port_map); + if (hwbm_pool->buf_num) + WARN(1, "cannot free all buffers in pool %d\n", bm_pool->id); + + if (bm_pool->virt_addr) { + dma_free_coherent(&priv->pdev->dev, + sizeof(u32) * hwbm_pool->size, + bm_pool->virt_addr, bm_pool->phys_addr); + bm_pool->virt_addr = NULL; + } + + mvneta_bm_pool_disable(priv, bm_pool->id); +} +EXPORT_SYMBOL_GPL(mvneta_bm_pool_destroy); + +static void mvneta_bm_pools_init(struct mvneta_bm *priv) +{ + struct device_node *dn = priv->pdev->dev.of_node; + struct mvneta_bm_pool *bm_pool; + char prop[15]; + u32 size; + int i; + + /* Activate BM unit */ + mvneta_bm_write(priv, MVNETA_BM_COMMAND_REG, MVNETA_BM_START_MASK); + + /* Create all pools with maximum size */ + for (i = 0; i < MVNETA_BM_POOLS_NUM; i++) { + bm_pool = &priv->bm_pools[i]; + bm_pool->id = i; + bm_pool->type = MVNETA_BM_FREE; + + /* Reset read pointer */ + mvneta_bm_write(priv, MVNETA_BM_POOL_READ_PTR_REG(i), 0); + + /* Reset write pointer */ + mvneta_bm_write(priv, MVNETA_BM_POOL_WRITE_PTR_REG(i), 0); + + /* Configure pool size according to DT or use default value */ + sprintf(prop, "pool%d,capacity", i); + if (of_property_read_u32(dn, prop, &size)) { + size = MVNETA_BM_POOL_CAP_DEF; + } else if (size > MVNETA_BM_POOL_CAP_MAX) { + dev_warn(&priv->pdev->dev, + "Illegal pool %d capacity %d, set to %d\n", + i, size, MVNETA_BM_POOL_CAP_MAX); + size = MVNETA_BM_POOL_CAP_MAX; + } else if (size < MVNETA_BM_POOL_CAP_MIN) { + dev_warn(&priv->pdev->dev, + "Illegal pool %d capacity %d, set to %d\n", + i, size, MVNETA_BM_POOL_CAP_MIN); + size = MVNETA_BM_POOL_CAP_MIN; + } else if (!IS_ALIGNED(size, MVNETA_BM_POOL_CAP_ALIGN)) { + dev_warn(&priv->pdev->dev, + "Illegal pool %d capacity %d, round to %d\n", + i, size, ALIGN(size, + MVNETA_BM_POOL_CAP_ALIGN)); + size = ALIGN(size, MVNETA_BM_POOL_CAP_ALIGN); + } + bm_pool->hwbm_pool.size = size; + + mvneta_bm_write(priv, MVNETA_BM_POOL_SIZE_REG(i), + bm_pool->hwbm_pool.size); + + /* Obtain custom pkt_size from DT */ + sprintf(prop, "pool%d,pkt-size", i); + if (of_property_read_u32(dn, prop, &bm_pool->pkt_size)) + bm_pool->pkt_size = 0; + } +} + +static void mvneta_bm_default_set(struct mvneta_bm *priv) +{ + u32 val; + + /* Mask BM all interrupts */ + mvneta_bm_write(priv, MVNETA_BM_INTR_MASK_REG, 0); + + /* Clear BM cause register */ + mvneta_bm_write(priv, MVNETA_BM_INTR_CAUSE_REG, 0); + + /* Set BM configuration register */ + val = mvneta_bm_read(priv, MVNETA_BM_CONFIG_REG); + + /* Reduce MaxInBurstSize from 32 BPs to 16 BPs */ + val &= ~MVNETA_BM_MAX_IN_BURST_SIZE_MASK; + val |= MVNETA_BM_MAX_IN_BURST_SIZE_16BP; + mvneta_bm_write(priv, MVNETA_BM_CONFIG_REG, val); +} + +static int mvneta_bm_init(struct mvneta_bm *priv) +{ + mvneta_bm_default_set(priv); + + /* Allocate and initialize BM pools structures */ + priv->bm_pools = devm_kcalloc(&priv->pdev->dev, MVNETA_BM_POOLS_NUM, + sizeof(struct mvneta_bm_pool), + GFP_KERNEL); + if (!priv->bm_pools) + return -ENOMEM; + + mvneta_bm_pools_init(priv); + + return 0; +} + +static int mvneta_bm_get_sram(struct device_node *dn, + struct mvneta_bm *priv) +{ + priv->bppi_pool = of_gen_pool_get(dn, "internal-mem", 0); + if (!priv->bppi_pool) + return -ENOMEM; + + priv->bppi_virt_addr = gen_pool_dma_alloc(priv->bppi_pool, + MVNETA_BM_BPPI_SIZE, + &priv->bppi_phys_addr); + if (!priv->bppi_virt_addr) + return -ENOMEM; + + return 0; +} + +static void mvneta_bm_put_sram(struct mvneta_bm *priv) +{ + gen_pool_free(priv->bppi_pool, priv->bppi_phys_addr, + MVNETA_BM_BPPI_SIZE); +} + +static int mvneta_bm_probe(struct platform_device *pdev) +{ + struct device_node *dn = pdev->dev.of_node; + struct mvneta_bm *priv; + struct resource *res; + int err; + + priv = devm_kzalloc(&pdev->dev, sizeof(struct mvneta_bm), GFP_KERNEL); + if (!priv) + return -ENOMEM; + + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + priv->reg_base = devm_ioremap_resource(&pdev->dev, res); + if (IS_ERR(priv->reg_base)) + return PTR_ERR(priv->reg_base); + + priv->clk = devm_clk_get(&pdev->dev, NULL); + if (IS_ERR(priv->clk)) + return PTR_ERR(priv->clk); + err = clk_prepare_enable(priv->clk); + if (err < 0) + return err; + + err = mvneta_bm_get_sram(dn, priv); + if (err < 0) { + dev_err(&pdev->dev, "failed to allocate internal memory\n"); + goto err_clk; + } + + priv->pdev = pdev; + + /* Initialize buffer manager internals */ + err = mvneta_bm_init(priv); + if (err < 0) { + dev_err(&pdev->dev, "failed to initialize controller\n"); + goto err_sram; + } + + dn->data = priv; + platform_set_drvdata(pdev, priv); + + dev_info(&pdev->dev, "Buffer Manager for network controller enabled\n"); + + return 0; + +err_sram: + mvneta_bm_put_sram(priv); +err_clk: + clk_disable_unprepare(priv->clk); + return err; +} + +static int mvneta_bm_remove(struct platform_device *pdev) +{ + struct mvneta_bm *priv = platform_get_drvdata(pdev); + u8 all_ports_map = 0xff; + int i = 0; + + for (i = 0; i < MVNETA_BM_POOLS_NUM; i++) { + struct mvneta_bm_pool *bm_pool = &priv->bm_pools[i]; + + mvneta_bm_pool_destroy(priv, bm_pool, all_ports_map); + } + + mvneta_bm_put_sram(priv); + + /* Dectivate BM unit */ + mvneta_bm_write(priv, MVNETA_BM_COMMAND_REG, MVNETA_BM_STOP_MASK); + + clk_disable_unprepare(priv->clk); + + return 0; +} + +static const struct of_device_id mvneta_bm_match[] = { + { .compatible = "marvell,armada-380-neta-bm" }, + { } +}; +MODULE_DEVICE_TABLE(of, mvneta_bm_match); + +static struct platform_driver mvneta_bm_driver = { + .probe = mvneta_bm_probe, + .remove = mvneta_bm_remove, + .driver = { + .name = MVNETA_BM_DRIVER_NAME, + .of_match_table = mvneta_bm_match, + }, +}; + +module_platform_driver(mvneta_bm_driver); + +MODULE_DESCRIPTION("Marvell NETA Buffer Manager Driver - www.marvell.com"); +MODULE_AUTHOR("Marcin Wojtas "); +MODULE_LICENSE("GPL v2"); --- a/dev/null +++ b/drivers/net/ethernet/marvell/mvneta_bm.h @@ -0,0 +1,182 @@ +/* + * Driver for Marvell NETA network controller Buffer Manager. + * + * Copyright (C) 2015 Marvell + * + * Marcin Wojtas + * + * This file is licensed under the terms of the GNU General Public + * License version 2. This program is licensed "as is" without any + * warranty of any kind, whether express or implied. + */ + +#ifndef _MVNETA_BM_H_ +#define _MVNETA_BM_H_ + +/* BM Configuration Register */ +#define MVNETA_BM_CONFIG_REG 0x0 +#define MVNETA_BM_STATUS_MASK 0x30 +#define MVNETA_BM_ACTIVE_MASK BIT(4) +#define MVNETA_BM_MAX_IN_BURST_SIZE_MASK 0x60000 +#define MVNETA_BM_MAX_IN_BURST_SIZE_16BP BIT(18) +#define MVNETA_BM_EMPTY_LIMIT_MASK BIT(19) + +/* BM Activation Register */ +#define MVNETA_BM_COMMAND_REG 0x4 +#define MVNETA_BM_START_MASK BIT(0) +#define MVNETA_BM_STOP_MASK BIT(1) +#define MVNETA_BM_PAUSE_MASK BIT(2) + +/* BM Xbar interface Register */ +#define MVNETA_BM_XBAR_01_REG 0x8 +#define MVNETA_BM_XBAR_23_REG 0xc +#define MVNETA_BM_XBAR_POOL_REG(pool) \ + (((pool) < 2) ? MVNETA_BM_XBAR_01_REG : MVNETA_BM_XBAR_23_REG) +#define MVNETA_BM_TARGET_ID_OFFS(pool) (((pool) & 1) ? 16 : 0) +#define MVNETA_BM_TARGET_ID_MASK(pool) \ + (0xf << MVNETA_BM_TARGET_ID_OFFS(pool)) +#define MVNETA_BM_TARGET_ID_VAL(pool, id) \ + ((id) << MVNETA_BM_TARGET_ID_OFFS(pool)) +#define MVNETA_BM_XBAR_ATTR_OFFS(pool) (((pool) & 1) ? 20 : 4) +#define MVNETA_BM_XBAR_ATTR_MASK(pool) \ + (0xff << MVNETA_BM_XBAR_ATTR_OFFS(pool)) +#define MVNETA_BM_XBAR_ATTR_VAL(pool, attr) \ + ((attr) << MVNETA_BM_XBAR_ATTR_OFFS(pool)) + +/* Address of External Buffer Pointers Pool Register */ +#define MVNETA_BM_POOL_BASE_REG(pool) (0x10 + ((pool) << 4)) +#define MVNETA_BM_POOL_ENABLE_MASK BIT(0) + +/* External Buffer Pointers Pool RD pointer Register */ +#define MVNETA_BM_POOL_READ_PTR_REG(pool) (0x14 + ((pool) << 4)) +#define MVNETA_BM_POOL_SET_READ_PTR_MASK 0xfffc +#define MVNETA_BM_POOL_GET_READ_PTR_OFFS 16 +#define MVNETA_BM_POOL_GET_READ_PTR_MASK 0xfffc0000 + +/* External Buffer Pointers Pool WR pointer */ +#define MVNETA_BM_POOL_WRITE_PTR_REG(pool) (0x18 + ((pool) << 4)) +#define MVNETA_BM_POOL_SET_WRITE_PTR_OFFS 0 +#define MVNETA_BM_POOL_SET_WRITE_PTR_MASK 0xfffc +#define MVNETA_BM_POOL_GET_WRITE_PTR_OFFS 16 +#define MVNETA_BM_POOL_GET_WRITE_PTR_MASK 0xfffc0000 + +/* External Buffer Pointers Pool Size Register */ +#define MVNETA_BM_POOL_SIZE_REG(pool) (0x1c + ((pool) << 4)) +#define MVNETA_BM_POOL_SIZE_MASK 0x3fff + +/* BM Interrupt Cause Register */ +#define MVNETA_BM_INTR_CAUSE_REG (0x50) + +/* BM interrupt Mask Register */ +#define MVNETA_BM_INTR_MASK_REG (0x54) + +/* Other definitions */ +#define MVNETA_BM_SHORT_PKT_SIZE 256 +#define MVNETA_BM_POOLS_NUM 4 +#define MVNETA_BM_POOL_CAP_MIN 128 +#define MVNETA_BM_POOL_CAP_DEF 2048 +#define MVNETA_BM_POOL_CAP_MAX \ + (16 * 1024 - MVNETA_BM_POOL_CAP_ALIGN) +#define MVNETA_BM_POOL_CAP_ALIGN 32 +#define MVNETA_BM_POOL_PTR_ALIGN 32 + +#define MVNETA_BM_POOL_ACCESS_OFFS 8 + +#define MVNETA_BM_BPPI_SIZE 0x100000 + +#define MVNETA_RX_BUF_SIZE(pkt_size) ((pkt_size) + NET_SKB_PAD) + +enum mvneta_bm_type { + MVNETA_BM_FREE, + MVNETA_BM_LONG, + MVNETA_BM_SHORT +}; + +struct mvneta_bm { + void __iomem *reg_base; + struct clk *clk; + struct platform_device *pdev; + + struct gen_pool *bppi_pool; + /* BPPI virtual base address */ + void __iomem *bppi_virt_addr; + /* BPPI physical base address */ + dma_addr_t bppi_phys_addr; + + /* BM pools */ + struct mvneta_bm_pool *bm_pools; +}; + +struct mvneta_bm_pool { + struct hwbm_pool hwbm_pool; + /* Pool number in the range 0-3 */ + u8 id; + enum mvneta_bm_type type; + + /* Packet size */ + int pkt_size; + /* Size of the buffer acces through DMA*/ + u32 buf_size; + + /* BPPE virtual base address */ + u32 *virt_addr; + /* BPPE physical base address */ + dma_addr_t phys_addr; + + /* Ports using BM pool */ + u8 port_map; + + struct mvneta_bm *priv; +}; + +/* Declarations and definitions */ +void *mvneta_frag_alloc(unsigned int frag_size); +void mvneta_frag_free(unsigned int frag_size, void *data); + +#if defined(CONFIG_MVNETA_BM) || defined(CONFIG_MVNETA_BM_MODULE) +void mvneta_bm_pool_destroy(struct mvneta_bm *priv, + struct mvneta_bm_pool *bm_pool, u8 port_map); +void mvneta_bm_bufs_free(struct mvneta_bm *priv, struct mvneta_bm_pool *bm_pool, + u8 port_map); +int mvneta_bm_construct(struct hwbm_pool *hwbm_pool, void *buf); +int mvneta_bm_pool_refill(struct mvneta_bm *priv, + struct mvneta_bm_pool *bm_pool); +struct mvneta_bm_pool *mvneta_bm_pool_use(struct mvneta_bm *priv, u8 pool_id, + enum mvneta_bm_type type, u8 port_id, + int pkt_size); + +static inline void mvneta_bm_pool_put_bp(struct mvneta_bm *priv, + struct mvneta_bm_pool *bm_pool, + dma_addr_t buf_phys_addr) +{ + writel_relaxed(buf_phys_addr, priv->bppi_virt_addr + + (bm_pool->id << MVNETA_BM_POOL_ACCESS_OFFS)); +} + +static inline u32 mvneta_bm_pool_get_bp(struct mvneta_bm *priv, + struct mvneta_bm_pool *bm_pool) +{ + return readl_relaxed(priv->bppi_virt_addr + + (bm_pool->id << MVNETA_BM_POOL_ACCESS_OFFS)); +} +#else +void mvneta_bm_pool_destroy(struct mvneta_bm *priv, + struct mvneta_bm_pool *bm_pool, u8 port_map) {} +void mvneta_bm_bufs_free(struct mvneta_bm *priv, struct mvneta_bm_pool *bm_pool, + u8 port_map) {} +int mvneta_bm_construct(struct hwbm_pool *hwbm_pool, void *buf) { return 0; } +int mvneta_bm_pool_refill(struct mvneta_bm *priv, + struct mvneta_bm_pool *bm_pool) {return 0; } +struct mvneta_bm_pool *mvneta_bm_pool_use(struct mvneta_bm *priv, u8 pool_id, + enum mvneta_bm_type type, u8 port_id, + int pkt_size) { return NULL; } + +static inline void mvneta_bm_pool_put_bp(struct mvneta_bm *priv, + struct mvneta_bm_pool *bm_pool, + dma_addr_t buf_phys_addr) {} + +static inline u32 mvneta_bm_pool_get_bp(struct mvneta_bm *priv, + struct mvneta_bm_pool *bm_pool) +{ return 0; } +#endif /* CONFIG_MVNETA_BM */ +#endif --- a/arch/arm/boot/dts/armada-xp-db.dts +++ b/arch/arm/boot/dts/armada-xp-db.dts @@ -77,7 +77,8 @@ MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000 MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000 MBUS_ID(0x09, 0x09) 0 0 0xf1100000 0x10000 - MBUS_ID(0x09, 0x05) 0 0 0xf1110000 0x10000>; + MBUS_ID(0x09, 0x05) 0 0 0xf8110000 0x10000 + MBUS_ID(0x0c, 0x04) 0 0 0xf1200000 0x100000>; devbus-bootcs { status = "okay"; @@ -181,21 +182,33 @@ status = "okay"; phy = <&phy0>; phy-mode = "rgmii-id"; + buffer-manager = <&bm>; + bm,pool-long = <0>; }; ethernet at 74000 { status = "okay"; phy = <&phy1>; phy-mode = "rgmii-id"; + buffer-manager = <&bm>; + bm,pool-long = <1>; }; ethernet at 30000 { status = "okay"; phy = <&phy2>; phy-mode = "sgmii"; + buffer-manager = <&bm>; + bm,pool-long = <2>; }; ethernet at 34000 { status = "okay"; phy = <&phy3>; phy-mode = "sgmii"; + buffer-manager = <&bm>; + bm,pool-long = <3>; + }; + + bm at c0000 { + status = "okay"; }; mvsdio at d4000 { @@ -230,5 +243,9 @@ }; }; }; + + bm-bppi { + status = "okay"; }; + }; }; --- a/arch/arm/boot/dts/armada-xp-gp.dts +++ b/arch/arm/boot/dts/armada-xp-gp.dts @@ -96,7 +96,8 @@ MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000 MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000 MBUS_ID(0x09, 0x09) 0 0 0xf1100000 0x10000 - MBUS_ID(0x09, 0x05) 0 0 0xf1110000 0x10000>; + MBUS_ID(0x09, 0x05) 0 0 0xf8110000 0x10000 + MBUS_ID(0x0c, 0x04) 0 0 0xf1200000 0x100000>; devbus-bootcs { status = "okay"; @@ -196,21 +197,29 @@ status = "okay"; phy = <&phy0>; phy-mode = "qsgmii"; + buffer-manager = <&bm>; + bm,pool-long = <0>; }; ethernet at 74000 { status = "okay"; phy = <&phy1>; phy-mode = "qsgmii"; + buffer-manager = <&bm>; + bm,pool-long = <1>; }; ethernet at 30000 { status = "okay"; phy = <&phy2>; phy-mode = "qsgmii"; + buffer-manager = <&bm>; + bm,pool-long = <2>; }; ethernet at 34000 { status = "okay"; phy = <&phy3>; phy-mode = "qsgmii"; + buffer-manager = <&bm>; + bm,pool-long = <3>; }; /* Front-side USB slot */ @@ -235,6 +244,10 @@ }; }; + bm at c0000 { + status = "okay"; + }; + nand at d0000 { status = "okay"; num-cs = <1>; @@ -243,5 +256,10 @@ nand-on-flash-bbt; }; }; + + bm-bppi { + status = "okay"; + }; + }; }; --- a/arch/arm/boot/dts/armada-xp.dtsi +++ b/arch/arm/boot/dts/armada-xp.dtsi @@ -251,6 +251,14 @@ marvell,crypto-sram-size = <0x800>; }; + bm: bm at c0000 { + compatible = "marvell,armada-380-neta-bm"; + reg = <0xc0000 0xac>; + clocks = <&gateclk 13>; + internal-mem = <&bm_bppi>; + status = "disabled"; + }; + xor at f0900 { compatible = "marvell,orion-xor"; reg = <0xF0900 0x100 @@ -289,7 +297,18 @@ #size-cells = <1>; ranges = <0 MBUS_ID(0x09, 0x05) 0 0x800>; }; - }; + + bm_bppi: bm-bppi { + compatible = "mmio-sram"; + reg = ; + ranges = <0 MBUS_ID(0x0c, 0x04) 0 0x100000>; + #address-cells = <1>; + #size-cells = <1>; + clocks = <&gateclk 13>; + no-memory-wc; + status = "disabled"; + }; + }; clocks { /* 25 MHz reference crystal */ --- a/dev/null +++ b/include/net/hwbm.h @@ -0,0 +1,28 @@ +#ifndef _HWBM_H +#define _HWBM_H + +struct hwbm_pool { + /* Capacity of the pool */ + int size; + /* Size of the buffers managed */ + int frag_size; + /* Number of buffers currently used by this pool */ + int buf_num; + /* constructor called during alocation */ + int (*construct)(struct hwbm_pool *bm_pool, void *buf); + /* protect acces to the buffer counter*/ + spinlock_t lock; + /* private data */ + void *priv; +}; +#ifdef CONFIG_HWBM +void hwbm_buf_free(struct hwbm_pool *bm_pool, void *buf); +int hwbm_pool_refill(struct hwbm_pool *bm_pool, gfp_t gfp); +int hwbm_pool_add(struct hwbm_pool *bm_pool, unsigned int buf_num, gfp_t gfp); +#else +void hwbm_buf_free(struct hwbm_pool *bm_pool, void *buf) {} +int hwbm_pool_refill(struct hwbm_pool *bm_pool, gfp_t gfp) { return 0; } +int hwbm_pool_add(struct hwbm_pool *bm_pool, unsigned int buf_num, gfp_t gfp) +{ return 0; } +#endif /* CONFIG_HWBM */ +#endif /* _HWBM_H */ --- a/net/Kconfig +++ b/net/Kconfig @@ -259,6 +259,9 @@ config XPS depends on SMP default y +config HWBM + bool + config CGROUP_NET_PRIO bool "Network priority cgroup" depends on CGROUPS --- a/net/core/Makefile +++ b/net/core/Makefile @@ -25,3 +25,4 @@ obj-$(CONFIG_NET_PTP_CLASSIFY) += ptp_cl obj-$(CONFIG_CGROUP_NET_PRIO) += netprio_cgroup.o obj-$(CONFIG_CGROUP_NET_CLASSID) += netclassid_cgroup.o obj-$(CONFIG_LWTUNNEL) += lwtunnel.o +obj-$(CONFIG_HWBM) += hwbm.o --- a/dev/null +++ b/net/core/hwbm.c @@ -0,0 +1,87 @@ +/* Support for hardware buffer manager. + * + * Copyright (C) 2016 Marvell + * + * Gregory CLEMENT + * + * 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. + */ +#include +#include +#include +#include + +void hwbm_buf_free(struct hwbm_pool *bm_pool, void *buf) +{ + if (likely(bm_pool->frag_size <= PAGE_SIZE)) + skb_free_frag(buf); + else + kfree(buf); +} +EXPORT_SYMBOL_GPL(hwbm_buf_free); + +/* Refill processing for HW buffer management */ +int hwbm_pool_refill(struct hwbm_pool *bm_pool, gfp_t gfp) +{ + int frag_size = bm_pool->frag_size; + void *buf; + + if (likely(frag_size <= PAGE_SIZE)) + buf = netdev_alloc_frag(frag_size); + else + buf = kmalloc(frag_size, gfp); + + if (!buf) + return -ENOMEM; + + if (bm_pool->construct) + if (bm_pool->construct(bm_pool, buf)) { + hwbm_buf_free(bm_pool, buf); + return -ENOMEM; + } + + return 0; +} +EXPORT_SYMBOL_GPL(hwbm_pool_refill); + +int hwbm_pool_add(struct hwbm_pool *bm_pool, unsigned int buf_num, gfp_t gfp) +{ + int err, i; + unsigned long flags; + + spin_lock_irqsave(&bm_pool->lock, flags); + if (bm_pool->buf_num == bm_pool->size) { + pr_warn("pool already filled\n"); + return bm_pool->buf_num; + } + + if (buf_num + bm_pool->buf_num > bm_pool->size) { + pr_warn("cannot allocate %d buffers for pool\n", + buf_num); + return 0; + } + + if ((buf_num + bm_pool->buf_num) < bm_pool->buf_num) { + pr_warn("Adding %d buffers to the %d current buffers will overflow\n", + buf_num, bm_pool->buf_num); + return 0; + } + + for (i = 0; i < buf_num; i++) { + err = hwbm_pool_refill(bm_pool, gfp); + if (err < 0) + break; + } + + /* Update BM driver with number of buffers added to pool */ + bm_pool->buf_num += i; + + pr_debug("hwpm pool: %d of %d buffers added\n", i, buf_num); + spin_unlock_irqrestore(&bm_pool->lock, flags); + + return i; +} +EXPORT_SYMBOL_GPL(hwbm_pool_add); --- a/drivers/bus/mvebu-mbus.c +++ b/drivers/bus/mvebu-mbus.c @@ -948,6 +948,58 @@ void mvebu_mbus_get_pcie_io_aperture(str *res = mbus_state.pcie_io_aperture; } +int mvebu_mbus_get_dram_win_info(phys_addr_t phyaddr, u8 *target, u8 *attr) +{ + const struct mbus_dram_target_info *dram; + int i; + + /* Get dram info */ + dram = mv_mbus_dram_info(); + if (!dram) { + pr_err("missing DRAM information\n"); + return -ENODEV; + } + + /* Try to find matching DRAM window for phyaddr */ + for (i = 0; i < dram->num_cs; i++) { + const struct mbus_dram_window *cs = dram->cs + i; + + if (cs->base <= phyaddr && + phyaddr <= (cs->base + cs->size - 1)) { + *target = dram->mbus_dram_target_id; + *attr = cs->mbus_attr; + return 0; + } + } + + pr_err("invalid dram address 0x%x\n", phyaddr); + return -EINVAL; +} +EXPORT_SYMBOL_GPL(mvebu_mbus_get_dram_win_info); + +int mvebu_mbus_get_io_win_info(phys_addr_t phyaddr, u32 *size, u8 *target, + u8 *attr) +{ + int win; + + for (win = 0; win < mbus_state.soc->num_wins; win++) { + u64 wbase; + int enabled; + + mvebu_mbus_read_window(&mbus_state, win, &enabled, &wbase, + size, target, attr, NULL); + + if (!enabled) + continue; + + if (wbase <= phyaddr && phyaddr <= wbase + *size) + return win; + } + + return -EINVAL; +} +EXPORT_SYMBOL_GPL(mvebu_mbus_get_io_win_info); + static __init int mvebu_mbus_debugfs_init(void) { struct mvebu_mbus_state *s = &mbus_state; --- a/include/linux/mbus.h +++ b/include/linux/mbus.h @@ -69,6 +69,9 @@ static inline const struct mbus_dram_tar int mvebu_mbus_save_cpu_target(u32 *store_addr); void mvebu_mbus_get_pcie_mem_aperture(struct resource *res); void mvebu_mbus_get_pcie_io_aperture(struct resource *res); +int mvebu_mbus_get_dram_win_info(phys_addr_t phyaddr, u8 *target, u8 *attr); +int mvebu_mbus_get_io_win_info(phys_addr_t phyaddr, u32 *size, u8 *target, + u8 *attr); int mvebu_mbus_add_window_remap_by_id(unsigned int target, unsigned int attribute, phys_addr_t base, size_t size, --- a/drivers/misc/sram.c +++ b/drivers/misc/sram.c @@ -360,7 +360,10 @@ static int sram_probe(struct platform_de return -EBUSY; } - sram->virt_base = devm_ioremap_wc(sram->dev, res->start, size); + if (of_property_read_bool(pdev->dev.of_node, "no-memory-wc")) + sram->virt_base = devm_ioremap(sram->dev, res->start, size); + else + sram->virt_base = devm_ioremap_wc(sram->dev, res->start, size); if (IS_ERR(sram->virt_base)) return PTR_ERR(sram->virt_base); --- a/drivers/net/ethernet/marvell/Kconfig +++ b/drivers/net/ethernet/marvell/Kconfig @@ -40,6 +40,19 @@ config MVMDIO This driver is used by the MV643XX_ETH and MVNETA drivers. +config MVNETA_BM_ENABLE + tristate "Marvell Armada 38x/XP network interface BM support" + depends on MVNETA + ---help--- + This driver supports auxiliary block of the network + interface units in the Marvell ARMADA XP and ARMADA 38x SoC + family, which is called buffer manager. + + This driver, when enabled, strictly cooperates with mvneta + driver and is common for all network ports of the devices, + even for Armada 370 SoC, which doesn't support hardware + buffer management. + config MVNETA tristate "Marvell Armada 370/38x/XP network interface support" depends on PLAT_ORION @@ -53,6 +66,15 @@ config MVNETA driver, which should be used for the older Marvell SoCs (Dove, Orion, Discovery, Kirkwood). +config MVNETA_BM + tristate + default y if MVNETA=y && MVNETA_BM_ENABLE + default MVNETA_BM_ENABLE + select HWBM + help + MVNETA_BM must not be 'm' if MVNETA=y, so this symbol ensures + that all dependencies are met. + config MVPP2 tristate "Marvell Armada 375 network interface support" depends on MACH_ARMADA_375 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From alin.nastac at gmail.com Thu May 19 03:54:06 2016 From: alin.nastac at gmail.com (Alin Nastac) Date: Thu, 19 May 2016 09:54:06 +0200 Subject: [OpenWrt-Devel] [PATCH] conntrack: enable support for netfilter conntrack zones Message-ID: <1463644446-4279-1-git-send-email-alin.nastac@gmail.com> Storage of such zones is provided by a nf_ct_ext struct, hence conntrack memory foot print will not be increased if zones are not used. --- package/kernel/linux/modules/netfilter.mk | 1 + 1 file changed, 1 insertion(+) diff --git a/package/kernel/linux/modules/netfilter.mk b/package/kernel/linux/modules/netfilter.mk index 3b623e4..4d9c116 100644 --- a/package/kernel/linux/modules/netfilter.mk +++ b/package/kernel/linux/modules/netfilter.mk @@ -68,6 +68,7 @@ define KernelPackage/nf-conntrack KCONFIG:= \ CONFIG_NETFILTER=y \ CONFIG_NETFILTER_ADVANCED=y \ + CONFIG_NF_CONNTRACK_ZONES=y \ $(KCONFIG_NF_CONNTRACK) FILES:=$(foreach mod,$(NF_CONNTRACK-m),$(LINUX_DIR)/net/$(mod).ko) AUTOLOAD:=$(call AutoProbe,$(notdir $(NF_CONNTRACK-m))) -- 1.7.12.4 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From luka.perkov at sartura.hr Thu May 19 05:50:18 2016 From: luka.perkov at sartura.hr (Luka Perkov) Date: Thu, 19 May 2016 09:50:18 +0000 Subject: [OpenWrt-Devel] [OpenWrt] rocket cwmp - open tr-069 client for embedded platforms In-Reply-To: <026901d1b1ad$4f392a20$edab7e60$@makowski@softathome.com> References: <01000154c6213d24-f2d57e19-b03a-4043-affc-ad720552be45-000000@email.amazonses.com> <026901d1b1ad$4f392a20$edab7e60$@makowski@softathome.com> Message-ID: <01000154c86c4036-5c2eeceb-ee41-41fc-86ab-2b12e39e1bb3-000000@email.amazonses.com> Hi Wojtek, On Thu, May 19, 2016 at 11:03:28AM +0200, Wojtek MAKOWSKI wrote: > Luka, Felix and others, > > Regarding the TR069 stack for OpenWrt I would like to propose our own > (i.e. SoftAtHome's) stack. Today it's a part of our commercial solution > but we are ready to deliver it (for free, of course) with an open-source > license. It's biggest advantage is that it already runs in 20M+ boxes of > several carriers and is fully interoperable with several carrier-grade > ACSs. > > What do you think about that? Thank you for your proposal and offer. These are great news and this is something that we were aiming to achieve with the Rocket CWMP project - to build a carrier community. There are technical items on how to make this happen but these are just details that we can work together on. I am also aware of several other solutions and hope that these vendors and individuals will decide to contribute as well. I'm looking forward to see this moving forward! Regards, Luka > Best regards, > Wojtek Makowski > SoftAtHome > > -----Original Message----- > From: openwrt-bounces at lists.prplfoundation.org > [mailto:openwrt-bounces at lists.prplfoundation.org] On Behalf Of Luka Perkov > Sent: Thursday, May 19, 2016 1:09 AM > To: openwrt-proposals at prplfoundation.org > Cc: openwrt at lists.prplfoundation.org; OpenWrt Development List; > lede-dev at lists.infradead.org > Subject: [OpenWrt] rocket cwmp - open tr-069 client for embedded platforms > > Hi all! > > prpl Foundation has made the invitation to propose OpenWrt enhancement > ideas which may end up funded by the same organization [1]. With this > email I'm offering to prpl Foundation to fund Rocket CWMP project - which > is the client implementation of CWMP / TR-069 protocol. Since this is a > good opportunity to further extend OpenWrt functionality I'm adding > several other mailing lists in CC and hope to initiate discussions > regarding this proposal and project. > > CWMP (TR-069) [2] has a very important role both for ISP and for the > entire ecosystem with manufacturers included. The standard form of CWMP > was primarily developed for a number of Internet access devices, such as > modems, set-top boxes, VolP phones and routers. TR-069 standardizes the > wide area network (WAN) management of CWMP devices and gives Internet > Service Providers a framework and a common language to remotely provision > and manage these devices regardless of device type or manufacturer. There > are around twenty TR-* documents which mostly define new parameters or > extend the RPC (Remote Procedure Call) methods. > > CWMP (CPE WAN Management Protocol), sometimes called TR-069 (Technical > Report 069), is a technical specification of a Broadband Forum designed > for remote governing of CPE (Customer Premises Equipment). Seeing that > CWMP is a standardized, text based protocol which offers a communication > between CPE and Auto Configuration Servers (ACS), it can be used between > different equipment manufacturers. > > Couple of years back I've authored the first Open Source TR-069 client > specifically targeting OpenWrt - it was named freecwmp [3]. Since then > I've learned a lot of lessons and in the company, Sartura, the team has > started developing new implementation which solves the limitations of the > old implementation. > > If funded, we are going to use the budget to further improve existing > codebase and of course to clean it up and prepare for Open Source release. > In order to make this a success, we will work on the documentation, > testing infrastructure and make it easy for vendors and hackers to use > this project when needed. > > I'll be making Rocket CWMP presentation on the prplwrt meeting on May 19 > (tomorrow). [4] These meetings are usually recorded and published on > YouTube. I hope that will happen with this meeting as well in case > somebody is interested but is not able to join. > > More information about the proposal can be found on the prpl Wiki [5] and > in the proposal documentation [6][7]. Comments are welcome! > > Sincerely, > Luka Perkov > > [1] http://wiki.prplfoundation.org/wiki/OpenWrt_Funding > [2] https://www.broadband-forum.org/cwmp.php > [3] > https://lists.openwrt.org/pipermail/openwrt-devel/2012-June/015655.html > [4] http://lists.prplfoundation.org/pipermail/openwrt/2016-May/000544.html > [5] http://wiki.prplfoundation.org/wiki/OpenWrt_Funding/Rocket_CWMP > [6] http://www.sartura.hr/cwmp/sartura-prpl-rocket-cwmp-public.pdf > [7] http://www.sartura.hr/cwmp/sartura-prpl-rocket-cwmp-slides-public.pdf > _______________________________________________ > OpenWrt mailing list > OpenWrt at lists.prplfoundation.org > http://lists.prplfoundation.org/cgi-bin/mailman/listinfo/openwrt _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From kron at animeland.de Thu May 19 06:39:27 2016 From: kron at animeland.de (Sebastian Ortwein) Date: Thu, 19 May 2016 12:39:27 +0200 Subject: [OpenWrt-Devel] Add support for AVM Fritzbox 7360 SL In-Reply-To: <6abe7bf0-9039-588e-c77e-23cce8870825@m3hlis.de> References: <69086bb8-44aa-05e4-a550-ee1b13633b4a@animeland.de> <572E254E.4030409@gmail.com> <44031fa7-cb40-d37c-79bd-f338bfba8b68@animeland.de> <93a04c66-d6a4-1c5f-d16c-80db337b6d3c@animeland.de> <2d877322-9bf3-7144-3620-589f652f75ef@animeland.de> <9bb07f9a-d02f-2af7-d60d-a40075aa9871@animeland.de> <6abe7bf0-9039-588e-c77e-23cce8870825@m3hlis.de> Message-ID: <9351a886-6501-914d-37aa-cb3aea90d6f6@animeland.de> Hey Christian No you can use the avm bootloader. Uboot is not recommend because some details about your Fritz Box ist in the AVM bootloader (macadresse, eeprom wireless). You don't need any extra hardware but you must find out the IP Adress of your Bootloader in most cases it is 192.168.178.1. Here are some Infos http://www.wehavemorefun.de/fritzbox/ADAM2_Shell. in FritzOS you can find your variables in /proc/sys/urloader/enviroment. I recommend a seriel cable to control the bootloader but you don't need one. You have 5 seconds to make a ftp connection to your Fritzbox on boot. Here are a short description login to your fritzbox with ftp 192.168.178.1 user: adam2 pass: adam2 now do the following commands: passive binary debug 1 quote MEDIA FLSH its time to flash your image to the box, use the squashfs image because the jffs image will not work ! Don't override your bootloader or the tffs partions !!! put bin/lantiq/openwrt-lantiq-xrx200-FRITZ7360SL mtd1 after a time flash is ready an you can start restart your fritzbox with openwrt. Sebastian Am 16.05.2016 um 11:27 schrieb Christian Mehlis: > Am 15.05.2016 um 22:13 schrieb Martin Blumenstingl: >> On Sun, May 15, 2016 at 9:45 PM, Sebastian Ortwein >> wrote: >>> Am 15.05.2016 um 17:37 schrieb Martin Blumenstingl: >>> Okay thank you for support. Now all thinks works fine LAN, WIFI, >>> Switch and >>> USB. >>> I attach my patch to add the support for OpenWRT. >> Great - congratulations :-) > > Hi Sebastian, > > I'm interested in some details about the flashing procedure. > > Did you replace the original avm bootloader with uboot? > > a) YEA: How to replace it, with which uboot version, where to find > the code? > b) NO: How to flash openwrt with avm bootloader? Can I flash > without any extra hardware? Only with serial and the right commands? > Please name them. > > Thanks, > Christian _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From mogulapranay57 at gmail.com Thu May 19 06:50:43 2016 From: mogulapranay57 at gmail.com (Pranay Goud) Date: Thu, 19 May 2016 16:20:43 +0530 Subject: [OpenWrt-Devel] [PATCH]:for demand option in l2tp.sh file of xl2tpd package. Message-ID: Hi Developers, Below patch is for considering demand option in l2tp.sh, demand option is not getting initialized *json_get_vars ipv6 demand keepalive username password pppd_options * the above line in l2tp.sh fails to read demand option and whenever user changes only demand option (idle time value) xl2tp dameon is not notified. --- a/package/openwrt/net/xl2tpd/files/l2tp.sh +++ b/package/openwrt/net/xl2tpd/files/l2tp.sh @@ -14,6 +14,7 @@ proto_l2tp_init_config() { proto_config_add_string "keepalive" proto_config_add_string "pppd_options" proto_config_add_boolean "ipv6" + proto_config_add_int "demand" proto_config_add_int "mtu" proto_config_add_string "server" available=1 Thanks, Pranay. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From yszhou4tech at gmail.com Thu May 19 07:17:34 2016 From: yszhou4tech at gmail.com (Yousong Zhou) Date: Thu, 19 May 2016 19:17:34 +0800 Subject: [OpenWrt-Devel] [PATCH]:for demand option in l2tp.sh file of xl2tpd package. In-Reply-To: References: Message-ID: On 19 May 2016 at 18:50, Pranay Goud wrote: > Hi Developers, > > > > Below patch is for considering demand option in l2tp.sh, demand option is > not getting initialized > > > > json_get_vars ipv6 demand keepalive username password pppd_options > > > > the above line in l2tp.sh fails to read demand option and whenever user > changes only demand option (idle time value) xl2tp dameon is not notified. > Hi Pranay, please try patch at [1] and see if it can fix the issue for you. Thanks for reporting this. Xl2tpd for OpenWrt is hosted in the packages feed [2]. Opening issues/pull requests there should be the way to go. [1] xl2tpd: add missing "demand" option, https://github.com/yousong/packages/commit/e6d4e73420b21f033fb77cf0c2adb0f3b957dcc8 [2] https://github.com/openwrt/packages yousong > > > --- a/package/openwrt/net/xl2tpd/files/l2tp.sh > > +++ b/package/openwrt/net/xl2tpd/files/l2tp.sh > > @@ -14,6 +14,7 @@ proto_l2tp_init_config() { > > proto_config_add_string "keepalive" > > proto_config_add_string "pppd_options" > > proto_config_add_boolean "ipv6" > > + proto_config_add_int "demand" > > proto_config_add_int "mtu" > > proto_config_add_string "server" > > available=1 > > > > > > > > Thanks, > > Pranay. > > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From yszhou4tech at gmail.com Thu May 19 07:25:57 2016 From: yszhou4tech at gmail.com (Yousong Zhou) Date: Thu, 19 May 2016 19:25:57 +0800 Subject: [OpenWrt-Devel] [PATCH]:for demand option in l2tp.sh file of xl2tpd package. In-Reply-To: References: Message-ID: On 19 May 2016 at 19:17, Yousong Zhou wrote: > On 19 May 2016 at 18:50, Pranay Goud wrote: >> Hi Developers, >> >> >> >> Below patch is for considering demand option in l2tp.sh, demand option is >> not getting initialized >> >> >> >> json_get_vars ipv6 demand keepalive username password pppd_options >> >> >> >> the above line in l2tp.sh fails to read demand option and whenever user >> changes only demand option (idle time value) xl2tp dameon is not notified. >> > > Hi Pranay, please try patch at [1] and see if it can fix the issue for you. > > Thanks for reporting this. Xl2tpd for OpenWrt is hosted in the > packages feed [2]. Opening issues/pull requests there should be the > way to go. > > [1] xl2tpd: add missing "demand" option, > https://github.com/yousong/packages/commit/e6d4e73420b21f033fb77cf0c2adb0f3b957dcc8 > [2] https://github.com/openwrt/packages > Ooh, sorry... just noticed that the change was the same... To let the change get merged, the commit will need to be signed-off-by you. Please consider opening a pr at the github page > yousong > >> >> >> --- a/package/openwrt/net/xl2tpd/files/l2tp.sh >> >> +++ b/package/openwrt/net/xl2tpd/files/l2tp.sh >> >> @@ -14,6 +14,7 @@ proto_l2tp_init_config() { >> >> proto_config_add_string "keepalive" >> >> proto_config_add_string "pppd_options" >> >> proto_config_add_boolean "ipv6" >> >> + proto_config_add_int "demand" >> >> proto_config_add_int "mtu" >> >> proto_config_add_string "server" >> >> available=1 >> >> >> >> >> >> >> >> Thanks, >> >> Pranay. >> >> >> _______________________________________________ >> openwrt-devel mailing list >> openwrt-devel at lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >> _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From kron at animeland.de Thu May 19 08:12:18 2016 From: kron at animeland.de (Sebastian Ortwein) Date: Thu, 19 May 2016 14:12:18 +0200 Subject: [OpenWrt-Devel] [PATCH 1/2] Add support for AVM FritzBox 7360SL Message-ID: Add support for FritzBox 7360SL working: USB,WIFI,SWITCH,LAN not working:DECT, Telephone -------------- next part -------------- A non-text attachment was scrubbed... Name: 7360SL.diff Type: text/x-patch Size: 6594 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From kron at animeland.de Thu May 19 08:14:59 2016 From: kron at animeland.de (Sebastian Ortwein) Date: Thu, 19 May 2016 14:14:59 +0200 Subject: [OpenWrt-Devel] [PATCH 2/2] Add support for AVM FritzBox 7360SL Message-ID: <81b839bf-0384-2d51-9986-4d3c2c81c01b@animeland.de> adding Atheros PHY 8030 needed bei FritzBox 7360SL -------------- next part -------------- A non-text attachment was scrubbed... Name: 7360SL2.diff Type: text/x-patch Size: 388 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From alin.nastac at gmail.com Thu May 19 08:57:02 2016 From: alin.nastac at gmail.com (Alin Nastac) Date: Thu, 19 May 2016 14:57:02 +0200 Subject: [OpenWrt-Devel] [PATCH] libnet-1.2.x: enable HAVE_PACKET_SOCKET Message-ID: <1463662622-15688-1-git-send-email-alin.nastac@gmail.com> There is already a CONFIGURE_VAR set in here that seem to have the same purpose, but it doesn't do the trick in my cause (autoconf 2.69). --- libs/libnet-1.2.x/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/libs/libnet-1.2.x/Makefile b/libs/libnet-1.2.x/Makefile index a791163..062c7b6 100644 --- a/libs/libnet-1.2.x/Makefile +++ b/libs/libnet-1.2.x/Makefile @@ -39,6 +39,7 @@ CONFIGURE_ARGS += \ CONFIGURE_VARS += \ ac_cv_libnet_endianess=$(ENDIANESS) \ ac_libnet_have_pf_packet=yes \ + libnet_cv_have_packet_socket=yes \ LL_INT_TYPE=libnet_link_linux define Build/Configure -- 1.7.12.4 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From reiner at reiner-h.de Thu May 19 12:12:12 2016 From: reiner at reiner-h.de (Reiner Herrmann) Date: Thu, 19 May 2016 18:12:12 +0200 Subject: [OpenWrt-Devel] uci: invalid reads/writes found by valgrind Message-ID: <20160519161212.GF25202@reiner-h.de> Hi, valgrind found some invalid reads/writes when updating sections (see below). The problem seems to be in list.c, where sections are updated: } else if (ptr->s && ptr->section) { /* update section */ char *s = uci_strdup(ctx, ptr->value); if (ptr->s->type == uci_dataptr(ptr->s)) { ptr->last = NULL; ptr->last = uci_realloc(ctx, ptr->s, sizeof(struct uci_section)); ptr->s = uci_to_section(ptr->last); uci_list_fixup(&ptr->s->e.list); } else { free(ptr->s->type); } ptr->s->type = s; } I don't completely understand what is happening in the if block. Isn't ptr->s->type always uci_dataptr(ptr->s)? Using uci_free_section + uci_alloc_section instead of an uci_realloc seems to prevent the invalid accesses, but this of course has other problems (options from the section are also freed). Can someone explain what this block is supposed to do (e.g. why is a fixup required)? $ valgrind uci set system.ntp=timeserver ==4113== Memcheck, a memory error detector [...] ==4113== Invalid read of size 8 ==4113== at 0x4E38565: uci_free_section (list.c:210) ==4113== by 0x4E386AA: uci_free_package (list.c:243) ==4113== by 0x4E38CE0: uci_free_context (libuci.c:84) ==4113== by 0x4016C4: main (cli.c:774) ==4113== Address 0x55ee7b0 is 32 bytes inside a block of size 83 free'd ==4113== at 0x4C2BDDF: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==4113== by 0x4E3B58B: uci_realloc (util.c:49) ==4113== by 0x4E39DE5: uci_set (list.c:708) ==4113== by 0x4022A8: uci_do_section_cmd (cli.c:514) ==4113== by 0x4022A8: uci_cmd (cli.c:669) ==4113== by 0x401694: main (cli.c:767) ==4113== Block was alloc'd at ==4113== at 0x4C29C0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==4113== by 0x4E3B555: uci_malloc (util.c:39) ==4113== by 0x4E382AB: uci_alloc_generic (list.c:47) ==4113== by 0x4E383B7: uci_alloc_section (list.c:191) ==4113== by 0x4E39D33: uci_set (list.c:694) ==4113== by 0x4E3AECA: uci_parse_config (file.c:451) ==4113== by 0x4E3AECA: uci_parse_line (file.c:521) ==4113== by 0x4E3AECA: uci_import (file.c:683) ==4113== by 0x4E3B4C1: uci_file_load (file.c:910) ==4113== by 0x4E390C7: uci_load (libuci.c:216) ==4113== by 0x4E391EC: uci_lookup_ptr (list.c:391) ==4113== by 0x40220B: uci_do_section_cmd (cli.c:477) ==4113== by 0x40220B: uci_cmd (cli.c:669) ==4113== by 0x401694: main (cli.c:767) ==4113== ==4113== Invalid read of size 4 ==4113== at 0x4E38506: uci_free_option (list.c:97) ==4113== by 0x4E38571: uci_free_section (list.c:211) ==4113== by 0x4E386AA: uci_free_package (list.c:243) ==4113== by 0x4E38CE0: uci_free_context (libuci.c:84) ==4113== by 0x4016C4: main (cli.c:774) ==4113== Address 0x55ee7d8 is 72 bytes inside a block of size 83 free'd ==4113== at 0x4C2BDDF: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==4113== by 0x4E3B58B: uci_realloc (util.c:49) ==4113== by 0x4E39DE5: uci_set (list.c:708) ==4113== by 0x4022A8: uci_do_section_cmd (cli.c:514) ==4113== by 0x4022A8: uci_cmd (cli.c:669) ==4113== by 0x401694: main (cli.c:767) ==4113== Block was alloc'd at ==4113== at 0x4C29C0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==4113== by 0x4E3B555: uci_malloc (util.c:39) ==4113== by 0x4E382AB: uci_alloc_generic (list.c:47) ==4113== by 0x4E383B7: uci_alloc_section (list.c:191) ==4113== by 0x4E39D33: uci_set (list.c:694) ==4113== by 0x4E3AECA: uci_parse_config (file.c:451) ==4113== by 0x4E3AECA: uci_parse_line (file.c:521) ==4113== by 0x4E3AECA: uci_import (file.c:683) ==4113== by 0x4E3B4C1: uci_file_load (file.c:910) ==4113== by 0x4E390C7: uci_load (libuci.c:216) ==4113== by 0x4E391EC: uci_lookup_ptr (list.c:391) ==4113== by 0x40220B: uci_do_section_cmd (cli.c:477) ==4113== by 0x40220B: uci_cmd (cli.c:669) ==4113== by 0x401694: main (cli.c:767) ==4113== ==4113== Invalid read of size 8 ==4113== at 0x4E384DD: uci_free_element (list.c:69) ==4113== by 0x4E38571: uci_free_section (list.c:211) ==4113== by 0x4E386AA: uci_free_package (list.c:243) ==4113== by 0x4E38CE0: uci_free_context (libuci.c:84) ==4113== by 0x4016C4: main (cli.c:774) ==4113== Address 0x55ee7c8 is 56 bytes inside a block of size 83 free'd ==4113== at 0x4C2BDDF: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==4113== by 0x4E3B58B: uci_realloc (util.c:49) ==4113== by 0x4E39DE5: uci_set (list.c:708) ==4113== by 0x4022A8: uci_do_section_cmd (cli.c:514) ==4113== by 0x4022A8: uci_cmd (cli.c:669) ==4113== by 0x401694: main (cli.c:767) ==4113== Block was alloc'd at ==4113== at 0x4C29C0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==4113== by 0x4E3B555: uci_malloc (util.c:39) ==4113== by 0x4E382AB: uci_alloc_generic (list.c:47) ==4113== by 0x4E383B7: uci_alloc_section (list.c:191) ==4113== by 0x4E39D33: uci_set (list.c:694) ==4113== by 0x4E3AECA: uci_parse_config (file.c:451) ==4113== by 0x4E3AECA: uci_parse_line (file.c:521) ==4113== by 0x4E3AECA: uci_import (file.c:683) ==4113== by 0x4E3B4C1: uci_file_load (file.c:910) ==4113== by 0x4E390C7: uci_load (libuci.c:216) ==4113== by 0x4E391EC: uci_lookup_ptr (list.c:391) ==4113== by 0x40220B: uci_do_section_cmd (cli.c:477) ==4113== by 0x40220B: uci_cmd (cli.c:669) ==4113== by 0x401694: main (cli.c:767) ==4113== ==4113== Invalid read of size 8 ==4113== at 0x4E384E6: uci_free_element (list.c:70) ==4113== by 0x4E38571: uci_free_section (list.c:211) ==4113== by 0x4E386AA: uci_free_package (list.c:243) ==4113== by 0x4E38CE0: uci_free_context (libuci.c:84) ==4113== by 0x4016C4: main (cli.c:774) ==4113== Address 0x55ee7b0 is 32 bytes inside a block of size 83 free'd ==4113== at 0x4C2BDDF: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==4113== by 0x4E3B58B: uci_realloc (util.c:49) ==4113== by 0x4E39DE5: uci_set (list.c:708) ==4113== by 0x4022A8: uci_do_section_cmd (cli.c:514) ==4113== by 0x4022A8: uci_cmd (cli.c:669) ==4113== by 0x401694: main (cli.c:767) ==4113== Block was alloc'd at ==4113== at 0x4C29C0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==4113== by 0x4E3B555: uci_malloc (util.c:39) ==4113== by 0x4E382AB: uci_alloc_generic (list.c:47) ==4113== by 0x4E383B7: uci_alloc_section (list.c:191) ==4113== by 0x4E39D33: uci_set (list.c:694) ==4113== by 0x4E3AECA: uci_parse_config (file.c:451) ==4113== by 0x4E3AECA: uci_parse_line (file.c:521) ==4113== by 0x4E3AECA: uci_import (file.c:683) ==4113== by 0x4E3B4C1: uci_file_load (file.c:910) ==4113== by 0x4E390C7: uci_load (libuci.c:216) ==4113== by 0x4E391EC: uci_lookup_ptr (list.c:391) ==4113== by 0x40220B: uci_do_section_cmd (cli.c:477) ==4113== by 0x40220B: uci_cmd (cli.c:669) ==4113== by 0x401694: main (cli.c:767) ==4113== ==4113== Invalid free() / delete / delete[] / realloc() ==4113== at 0x4C2AE6B: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==4113== by 0x4E38571: uci_free_section (list.c:211) ==4113== by 0x4E386AA: uci_free_package (list.c:243) ==4113== by 0x4E38CE0: uci_free_context (libuci.c:84) ==4113== by 0x4016C4: main (cli.c:774) ==4113== Address 0x55ee7b0 is 32 bytes inside a block of size 83 free'd ==4113== at 0x4C2BDDF: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==4113== by 0x4E3B58B: uci_realloc (util.c:49) ==4113== by 0x4E39DE5: uci_set (list.c:708) ==4113== by 0x4022A8: uci_do_section_cmd (cli.c:514) ==4113== by 0x4022A8: uci_cmd (cli.c:669) ==4113== by 0x401694: main (cli.c:767) ==4113== Block was alloc'd at ==4113== at 0x4C29C0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==4113== by 0x4E3B555: uci_malloc (util.c:39) ==4113== by 0x4E382AB: uci_alloc_generic (list.c:47) ==4113== by 0x4E383B7: uci_alloc_section (list.c:191) ==4113== by 0x4E39D33: uci_set (list.c:694) ==4113== by 0x4E3AECA: uci_parse_config (file.c:451) ==4113== by 0x4E3AECA: uci_parse_line (file.c:521) ==4113== by 0x4E3AECA: uci_import (file.c:683) ==4113== by 0x4E3B4C1: uci_file_load (file.c:910) ==4113== by 0x4E390C7: uci_load (libuci.c:216) ==4113== by 0x4E391EC: uci_lookup_ptr (list.c:391) ==4113== by 0x40220B: uci_do_section_cmd (cli.c:477) ==4113== by 0x40220B: uci_cmd (cli.c:669) ==4113== by 0x401694: main (cli.c:767) ==4113== ==4113== Invalid read of size 8 ==4113== at 0x4E38575: uci_free_section (list.c:210) ==4113== by 0x4E386AA: uci_free_package (list.c:243) ==4113== by 0x4E38CE0: uci_free_context (libuci.c:84) ==4113== by 0x4016C4: main (cli.c:774) ==4113== Address 0x55ee7b0 is 32 bytes inside a block of size 83 free'd ==4113== at 0x4C2BDDF: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==4113== by 0x4E3B58B: uci_realloc (util.c:49) ==4113== by 0x4E39DE5: uci_set (list.c:708) ==4113== by 0x4022A8: uci_do_section_cmd (cli.c:514) ==4113== by 0x4022A8: uci_cmd (cli.c:669) ==4113== by 0x401694: main (cli.c:767) ==4113== Block was alloc'd at ==4113== at 0x4C29C0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==4113== by 0x4E3B555: uci_malloc (util.c:39) ==4113== by 0x4E382AB: uci_alloc_generic (list.c:47) ==4113== by 0x4E383B7: uci_alloc_section (list.c:191) ==4113== by 0x4E39D33: uci_set (list.c:694) ==4113== by 0x4E3AECA: uci_parse_config (file.c:451) ==4113== by 0x4E3AECA: uci_parse_line (file.c:521) ==4113== by 0x4E3AECA: uci_import (file.c:683) ==4113== by 0x4E3B4C1: uci_file_load (file.c:910) ==4113== by 0x4E390C7: uci_load (libuci.c:216) ==4113== by 0x4E391EC: uci_lookup_ptr (list.c:391) ==4113== by 0x40220B: uci_do_section_cmd (cli.c:477) ==4113== by 0x40220B: uci_cmd (cli.c:669) ==4113== by 0x401694: main (cli.c:767) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Digital signature URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From dev at kresin.me Thu May 19 12:19:35 2016 From: dev at kresin.me (Mathias Kresin) Date: Thu, 19 May 2016 18:19:35 +0200 Subject: [OpenWrt-Devel] [PATCH] lantiq: add support for ARV7506PW11 (Alice/O2 IAD 4421) In-Reply-To: <20160518210009.GA22531@ugly.lan> References: <1463557077-19088-1-git-send-email-oswald.buddenhagen@gmx.de> <20160518210009.GA22531@ugly.lan> Message-ID: 2016-05-18 23:00 GMT+02:00 Oswald Buddenhagen : > On Wed, May 18, 2016 at 01:19:59PM +0200, Mathias Kresin wrote: >> But I need to identify the boot_sel pins first. I have looked at it >> only briefly and was only able to identify one of the boot_sel pins: >> R77. Unfortunately this pin alone doesn't switch the SoC to UART mode. >> Did you found already the other pins? >> > no, i didn't bother with analyzing the hardware beyond soft-probing the > gpios to find some led and button pins. the dts is a copy&paste job from > the wiki (which in turn is "derived" from another dts), with a lot of > studying and trial and error to get the bogus parts out of it, and some > polishing and adjustments to recent changes. I found the pins to enter UART boot mode. Apply 3,3V to the right side of R65 and GND to the right side of R80. R80 is partially hidden under the heatsink of the SoC. > i'll do that if you don't beat me to it (which you can easily do if you > plan to seriously work on this - beyond email, this is a limited weekend > project for me). From zero to working image in just a weekend. That is indeed amazing. > i think i also know why rfkill doesn't work: i forgot to change the > keycode when i decided to switch the key's usage from wps to rfkill. > (facepalm) That's something where I've a lack of knowledge. Where does the keycodes come from? In the meantime I've added support for this board to u-boot, switched from brnboot to uImage and to a custom partitions layout with a firmware partition of 8128 KByte. Means, your image shrinking patches aren't required any more. I've pushed all my patches to my github repro: https://github.com/mkresin/lede. All outlined ways to install u-boot in https://wiki.openwrt.org/toh/arcadyan/vgv7510kw22#booting_via_uart should work for this device as well. Neither the u-boot nor the partition layout should considered as final versions. I've noticed that danube u-boots are tripple the size as they were with OpenWrt 12.09. I need to check this first. I haven't had a closer look to the OpenWrt image, but what I've noticed so far, is a not lit up WLAN led when the wireless is enabled. Does it work for you? Do you plan to work further on this patch or do you consider your weekend project as finished. Mathias _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From jo at mein.io Thu May 19 12:21:02 2016 From: jo at mein.io (Jo-Philipp Wich) Date: Thu, 19 May 2016 18:21:02 +0200 Subject: [OpenWrt-Devel] [LEDE-DEV] [PATCH] conntrack: enable support for netfilter conntrack zones In-Reply-To: <1463644446-4279-1-git-send-email-alin.nastac@gmail.com> References: <1463644446-4279-1-git-send-email-alin.nastac@gmail.com> Message-ID: Hi Alin, I merged your patch into my staging tree at https://git.lede-project.org/?p=lede/jow/staging.git;a=commitdiff;h=6c9231baa9c5341c6ee2e213618dcde72d42288b Since your change lacked a proper Signed-off-by I added it on your behalf. Please review the link above and give me your ACK, then I'll push it to master after some compile testing. Regards, Jo On 05/19/2016 09:54 AM, Alin Nastac wrote: > Storage of such zones is provided by a nf_ct_ext struct, hence conntrack > memory foot print will not be increased if zones are not used. > --- > package/kernel/linux/modules/netfilter.mk | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/package/kernel/linux/modules/netfilter.mk b/package/kernel/linux/modules/netfilter.mk > index 3b623e4..4d9c116 100644 > --- a/package/kernel/linux/modules/netfilter.mk > +++ b/package/kernel/linux/modules/netfilter.mk > @@ -68,6 +68,7 @@ define KernelPackage/nf-conntrack > KCONFIG:= \ > CONFIG_NETFILTER=y \ > CONFIG_NETFILTER_ADVANCED=y \ > + CONFIG_NF_CONNTRACK_ZONES=y \ > $(KCONFIG_NF_CONNTRACK) > FILES:=$(foreach mod,$(NF_CONNTRACK-m),$(LINUX_DIR)/net/$(mod).ko) > AUTOLOAD:=$(call AutoProbe,$(notdir $(NF_CONNTRACK-m))) > _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From dedeckeh at gmail.com Thu May 19 12:57:51 2016 From: dedeckeh at gmail.com (Hans Dedecker) Date: Thu, 19 May 2016 18:57:51 +0200 Subject: [OpenWrt-Devel] [PATCH] busybox: sysntpd - Support for NTP servers received via DHCP(v6) Message-ID: <1463677071-17121-1-git-send-email-dedeckeh@gmail.com> The busybox ntpd utility currently uses ntp servers specified in uci. This patch allows the ntpd utility to use NTP servers received via DHCP(v6) Following uci parameters have been added: use_dhcp : enables NTP server config via DHCP(v6) dhcp_interface : use NTP servers received only on the specified DHCP(v6) interfaces; if empty all interfaces are considered Signed-off-by: Hans Dedecker --- The patch is based on a previous discussion held on the OpenWRT-devel mailing list (https://lists.openwrt.org/pipermail/openwrt-devel/2016-January/039081.html) as per Felix's comments this solution is based on procd interface service triggers package/utils/busybox/Makefile | 2 +- package/utils/busybox/files/sysntpd | 43 ++++++++++++++++++++++++++++++++----- 2 files changed, 39 insertions(+), 6 deletions(-) diff --git a/package/utils/busybox/Makefile b/package/utils/busybox/Makefile index 24c064c..24e0e11 100644 --- a/package/utils/busybox/Makefile +++ b/package/utils/busybox/Makefile @@ -42,7 +42,7 @@ define Package/busybox MAINTAINER:=Felix Fietkau TITLE:=Core utilities for embedded Linux URL:=http://busybox.net/ - DEPENDS:=+BUSYBOX_USE_LIBRPC:librpc +BUSYBOX_CONFIG_PAM:libpam + DEPENDS:=+BUSYBOX_USE_LIBRPC:librpc +BUSYBOX_CONFIG_PAM:libpam +jsonfilter MENU:=1 endef diff --git a/package/utils/busybox/files/sysntpd b/package/utils/busybox/files/sysntpd index f73bb83..5c663d7 100755 --- a/package/utils/busybox/files/sysntpd +++ b/package/utils/busybox/files/sysntpd @@ -7,13 +7,35 @@ USE_PROCD=1 PROG=/usr/sbin/ntpd HOTPLUG_SCRIPT=/usr/sbin/ntpd-hotplug +get_dhcp_ntp_servers() { + local interfaces="$1" + local filter="*" + local network_dump interface ntpservers ntpserver + + network_dump=$(ubus call network.interface dump) + for interface in $interfaces; do + [ "$filter" = "*" ] && filter="@.interface='$interface'" || filter="$filter, at .interface='$interface'" + done + + ntpservers=$(jsonfilter -s "$network_dump" -e "@.interface[$filter]['data']['ntpserver']") + + for ntpserver in $ntpservers; do + local duplicate=0 + local entry + for entry in $server; do + [ "$ntpserver" = "$entry" ] && duplicate=1 + done + [ "$duplicate" = 0 ] && server="$server $ntpserver" + done +} + validate_ntp_section() { uci_validate_section system timeserver "${1}" \ - 'server:list(host)' 'enabled:bool:1' 'enable_server:bool:0' + 'server:list(host)' 'enabled:bool:1' 'enable_server:bool:0' 'use_dhcp:bool:0' 'dhcp_interface:list(string)' } start_service() { - local server enabled enable_server peer + local server enabled enable_server use_dhcp dhcp_interface peer validate_ntp_section ntp || { echo "validation failed" @@ -22,6 +44,8 @@ start_service() { [ $enabled = 0 ] && return + [ $use_dhcp = 1 ] && get_dhcp_ntp_servers "$dhcp_interface" + [ -z "$server" ] && return procd_open_instance @@ -35,8 +59,17 @@ start_service() { procd_close_instance } -service_triggers() -{ - procd_add_reload_trigger "system" +service_triggers() { + local script name + + script=$(readlink -f "$initscript") + name=$(basename ${script:-$initscript}) + + procd_open_trigger + procd_add_config_trigger "config.change" "system" /etc/init.d/$name reload + + procd_add_raw_trigger "interface.*" 2000 /etc/init.d/$name reload + procd_close_trigger + procd_add_validation validate_ntp_section } -- 1.9.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From jo at mein.io Thu May 19 13:04:30 2016 From: jo at mein.io (Jo-Philipp Wich) Date: Thu, 19 May 2016 19:04:30 +0200 Subject: [OpenWrt-Devel] [LEDE-DEV] [PATCH] busybox: sysntpd - Support for NTP servers received via DHCP(v6) In-Reply-To: <1463677071-17121-1-git-send-email-dedeckeh@gmail.com> References: <1463677071-17121-1-git-send-email-dedeckeh@gmail.com> Message-ID: Hi Hans, staged into https://git.lede-project.org/?p=lede/jow/staging.git A few improvement ideas though; - maybe we can make the jsonfilter dependency conditionally depending on the ntpd applet - maybe pipe the ubus interface status dump directly to jsonfilter - is there any reason to not make "use_dhcp" the default? ~ Jo On 05/19/2016 06:57 PM, Hans Dedecker wrote: > The busybox ntpd utility currently uses ntp servers specified in uci. > This patch allows the ntpd utility to use NTP servers received via DHCP(v6) > Following uci parameters have been added: > use_dhcp : enables NTP server config via DHCP(v6) > dhcp_interface : use NTP servers received only on the specified DHCP(v6) interfaces; if empty all interfaces are considered > > Signed-off-by: Hans Dedecker > --- > > The patch is based on a previous discussion held on the OpenWRT-devel mailing list > (https://lists.openwrt.org/pipermail/openwrt-devel/2016-January/039081.html) as per Felix's > comments this solution is based on procd interface service triggers > > package/utils/busybox/Makefile | 2 +- > package/utils/busybox/files/sysntpd | 43 ++++++++++++++++++++++++++++++++----- > 2 files changed, 39 insertions(+), 6 deletions(-) > > diff --git a/package/utils/busybox/Makefile b/package/utils/busybox/Makefile > index 24c064c..24e0e11 100644 > --- a/package/utils/busybox/Makefile > +++ b/package/utils/busybox/Makefile > @@ -42,7 +42,7 @@ define Package/busybox > MAINTAINER:=Felix Fietkau > TITLE:=Core utilities for embedded Linux > URL:=http://busybox.net/ > - DEPENDS:=+BUSYBOX_USE_LIBRPC:librpc +BUSYBOX_CONFIG_PAM:libpam > + DEPENDS:=+BUSYBOX_USE_LIBRPC:librpc +BUSYBOX_CONFIG_PAM:libpam +jsonfilter > MENU:=1 > endef > > diff --git a/package/utils/busybox/files/sysntpd b/package/utils/busybox/files/sysntpd > index f73bb83..5c663d7 100755 > --- a/package/utils/busybox/files/sysntpd > +++ b/package/utils/busybox/files/sysntpd > @@ -7,13 +7,35 @@ USE_PROCD=1 > PROG=/usr/sbin/ntpd > HOTPLUG_SCRIPT=/usr/sbin/ntpd-hotplug > > +get_dhcp_ntp_servers() { > + local interfaces="$1" > + local filter="*" > + local network_dump interface ntpservers ntpserver > + > + network_dump=$(ubus call network.interface dump) > + for interface in $interfaces; do > + [ "$filter" = "*" ] && filter="@.interface='$interface'" || filter="$filter, at .interface='$interface'" > + done > + > + ntpservers=$(jsonfilter -s "$network_dump" -e "@.interface[$filter]['data']['ntpserver']") > + > + for ntpserver in $ntpservers; do > + local duplicate=0 > + local entry > + for entry in $server; do > + [ "$ntpserver" = "$entry" ] && duplicate=1 > + done > + [ "$duplicate" = 0 ] && server="$server $ntpserver" > + done > +} > + > validate_ntp_section() { > uci_validate_section system timeserver "${1}" \ > - 'server:list(host)' 'enabled:bool:1' 'enable_server:bool:0' > + 'server:list(host)' 'enabled:bool:1' 'enable_server:bool:0' 'use_dhcp:bool:0' 'dhcp_interface:list(string)' > } > > start_service() { > - local server enabled enable_server peer > + local server enabled enable_server use_dhcp dhcp_interface peer > > validate_ntp_section ntp || { > echo "validation failed" > @@ -22,6 +44,8 @@ start_service() { > > [ $enabled = 0 ] && return > > + [ $use_dhcp = 1 ] && get_dhcp_ntp_servers "$dhcp_interface" > + > [ -z "$server" ] && return > > procd_open_instance > @@ -35,8 +59,17 @@ start_service() { > procd_close_instance > } > > -service_triggers() > -{ > - procd_add_reload_trigger "system" > +service_triggers() { > + local script name > + > + script=$(readlink -f "$initscript") > + name=$(basename ${script:-$initscript}) > + > + procd_open_trigger > + procd_add_config_trigger "config.change" "system" /etc/init.d/$name reload > + > + procd_add_raw_trigger "interface.*" 2000 /etc/init.d/$name reload > + procd_close_trigger > + > procd_add_validation validate_ntp_section > } > _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Thu May 19 14:20:44 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Thu, 19 May 2016 20:20:44 +0200 Subject: [OpenWrt-Devel] [PATCH CC 01/34] ar71xx: Generate sysupgrade images for OpenMesh devices Message-ID: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> Some OpenWrt based firmwares like Gluon expect that a sysupgrade image exists when a device firmware can be updated via sysupgrade. This image wasn't created until now because OpenMesh devices use the same image for factory and sysupgrade flash. Copying the image from *factory.bin to *sysupgrade.bin is therefore enough to make the sysupgrade functionality visible. Reported-by: Matthias Schiffer Signed-off-by: Sven Eckelmann --- target/linux/ar71xx/image/Makefile | 3 +++ 1 file changed, 3 insertions(+) diff --git a/target/linux/ar71xx/image/Makefile b/target/linux/ar71xx/image/Makefile index 9a7acbd..5b0a4ec 100644 --- a/target/linux/ar71xx/image/Makefile +++ b/target/linux/ar71xx/image/Makefile @@ -1847,6 +1847,9 @@ define Image/Build/OpenMesh "$(BUILD_DIR)/fwupgrade.cfg-$(4)" "fwupgrade.cfg" \ "$(KDIR_TMP)/vmlinux-$(2).uImage" "kernel" \ "$(KDIR)/root.$(1)" "rootfs" + if [ -e "$(call factoryname,$(1),$(2))" ]; then \ + cp "$(call factoryname,$(1),$(2))" "$(call sysupname,$(1),$(2))"; \ + fi endef -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Thu May 19 14:20:45 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Thu, 19 May 2016 20:20:45 +0200 Subject: [OpenWrt-Devel] [PATCH CC 02/34] ar71xx: add kernel support for the OpenMesh MR1750 board In-Reply-To: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463682077-19339-2-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann Backport of r46926 --- target/linux/ar71xx/config-3.18 | 1 + .../ar71xx/files/arch/mips/ath79/mach-mr1750.c | 129 +++++++++++++++++++++ .../815-MIPS-ath79-add-mr1750-support.patch | 39 +++++++ 3 files changed, 169 insertions(+) create mode 100644 target/linux/ar71xx/files/arch/mips/ath79/mach-mr1750.c create mode 100644 target/linux/ar71xx/patches-3.18/815-MIPS-ath79-add-mr1750-support.patch diff --git a/target/linux/ar71xx/config-3.18 b/target/linux/ar71xx/config-3.18 index e2ff826..2354c9c 100644 --- a/target/linux/ar71xx/config-3.18 +++ b/target/linux/ar71xx/config-3.18 @@ -79,6 +79,7 @@ CONFIG_ATH79_MACH_JWAP003=y CONFIG_ATH79_MACH_MC_MAC1200R=y CONFIG_ATH79_MACH_MR16=y CONFIG_ATH79_MACH_MR12=y +CONFIG_ATH79_MACH_MR1750=y CONFIG_ATH79_MACH_MR600=y CONFIG_ATH79_MACH_MR900=y CONFIG_ATH79_MACH_MYNET_N600=y diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-mr1750.c b/target/linux/ar71xx/files/arch/mips/ath79/mach-mr1750.c new file mode 100644 index 0000000..8ace02f --- /dev/null +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-mr1750.c @@ -0,0 +1,129 @@ +/* + * MR1750 board support + * + * Copyright (c) 2012 Qualcomm Atheros + * Copyright (c) 2012-2013 Marek Lindner + * + * Permission to use, copy, modify, and/or distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + * + */ + +#include +#include + +#include + +#include "common.h" +#include "dev-ap9x-pci.h" +#include "dev-gpio-buttons.h" +#include "dev-eth.h" +#include "dev-leds-gpio.h" +#include "dev-m25p80.h" +#include "dev-wmac.h" +#include "machtypes.h" +#include "pci.h" + +#define MR1750_GPIO_LED_LAN 12 +#define MR1750_GPIO_LED_WLAN_2G 13 +#define MR1750_GPIO_LED_STATUS_GREEN 19 +#define MR1750_GPIO_LED_STATUS_RED 21 +#define MR1750_GPIO_LED_POWER 22 +#define MR1750_GPIO_LED_WLAN_5G 23 + +#define MR1750_GPIO_BTN_RESET 17 + +#define MR1750_KEYS_POLL_INTERVAL 20 /* msecs */ +#define MR1750_KEYS_DEBOUNCE_INTERVAL (3 * MR1750_KEYS_POLL_INTERVAL) + +#define MR1750_MAC0_OFFSET 0 +#define MR1750_WMAC_CALDATA_OFFSET 0x1000 + +static struct gpio_led mr1750_leds_gpio[] __initdata = { + { + .name = "mr1750:blue:power", + .gpio = MR1750_GPIO_LED_POWER, + .active_low = 1, + }, + { + .name = "mr1750:blue:wan", + .gpio = MR1750_GPIO_LED_LAN, + .active_low = 1, + }, + { + .name = "mr1750:blue:wlan24", + .gpio = MR1750_GPIO_LED_WLAN_2G, + .active_low = 1, + }, + { + .name = "mr1750:blue:wlan58", + .gpio = MR1750_GPIO_LED_WLAN_5G, + .active_low = 1, + }, + { + .name = "mr1750:green:status", + .gpio = MR1750_GPIO_LED_STATUS_GREEN, + .active_low = 1, + }, + { + .name = "mr1750:red:status", + .gpio = MR1750_GPIO_LED_STATUS_RED, + .active_low = 1, + }, +}; + +static struct gpio_keys_button mr1750_gpio_keys[] __initdata = { + { + .desc = "Reset button", + .type = EV_KEY, + .code = KEY_RESTART, + .debounce_interval = MR1750_KEYS_DEBOUNCE_INTERVAL, + .gpio = MR1750_GPIO_BTN_RESET, + .active_low = 1, + }, +}; + +static void __init mr1750_setup(void) +{ + u8 *art = (u8 *)KSEG1ADDR(0x1fff0000); + u8 mac[6]; + + ath79_eth0_pll_data.pll_1000 = 0xbe000101; + ath79_eth0_pll_data.pll_100 = 0x80000101; + ath79_eth0_pll_data.pll_10 = 0x80001313; + + ath79_register_m25p80(NULL); + + ath79_register_leds_gpio(-1, ARRAY_SIZE(mr1750_leds_gpio), + mr1750_leds_gpio); + ath79_register_gpio_keys_polled(-1, MR1750_KEYS_POLL_INTERVAL, + ARRAY_SIZE(mr1750_gpio_keys), + mr1750_gpio_keys); + + ath79_init_mac(mac, art + MR1750_MAC0_OFFSET, 1); + ath79_register_wmac(art + MR1750_WMAC_CALDATA_OFFSET, mac); + ath79_register_pci(); + + ath79_setup_qca955x_eth_cfg(QCA955X_ETH_CFG_RGMII_EN); + ath79_register_mdio(0, 0x0); + + ath79_init_mac(ath79_eth0_data.mac_addr, art + MR1750_MAC0_OFFSET, 0); + + /* GMAC0 is connected to the RMGII interface */ + ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_RGMII; + ath79_eth0_data.phy_mask = BIT(5); + ath79_eth0_data.mii_bus_dev = &ath79_mdio0_device.dev; + + ath79_register_eth(0); +} + +MIPS_MACHINE(ATH79_MACH_MR1750, "MR1750", "OpenMesh MR1750", mr1750_setup); diff --git a/target/linux/ar71xx/patches-3.18/815-MIPS-ath79-add-mr1750-support.patch b/target/linux/ar71xx/patches-3.18/815-MIPS-ath79-add-mr1750-support.patch new file mode 100644 index 0000000..d802a12 --- /dev/null +++ b/target/linux/ar71xx/patches-3.18/815-MIPS-ath79-add-mr1750-support.patch @@ -0,0 +1,39 @@ +--- a/arch/mips/ath79/Kconfig ++++ b/arch/mips/ath79/Kconfig +@@ -763,6 +763,16 @@ config ATH79_MACH_CAP4200AG + select ATH79_DEV_M25P80 + select ATH79_DEV_WMAC + ++config ATH79_MACH_MR1750 ++ bool "OpenMesh MR1750 board support" ++ select SOC_QCA955X ++ select ATH79_DEV_AP9X_PCI if PCI ++ select ATH79_DEV_ETH ++ select ATH79_DEV_GPIO_BUTTONS ++ select ATH79_DEV_LEDS_GPIO ++ select ATH79_DEV_M25P80 ++ select ATH79_DEV_WMAC ++ + config ATH79_MACH_MR900 + bool "OpenMesh MR900 board support" + select SOC_QCA955X +--- a/arch/mips/ath79/Makefile ++++ b/arch/mips/ath79/Makefile +@@ -80,6 +80,7 @@ obj-$(CONFIG_ATH79_MACH_HORNET_UB) += ma + obj-$(CONFIG_ATH79_MACH_MC_MAC1200R) += mach-mc-mac1200r.o + obj-$(CONFIG_ATH79_MACH_MR12) += mach-mr12.o + obj-$(CONFIG_ATH79_MACH_MR16) += mach-mr16.o ++obj-$(CONFIG_ATH79_MACH_MR1750) += mach-mr1750.o + obj-$(CONFIG_ATH79_MACH_MR600) += mach-mr600.o + obj-$(CONFIG_ATH79_MACH_MR900) += mach-mr900.o + obj-$(CONFIG_ATH79_MACH_MYNET_N600) += mach-mynet-n600.o +--- a/arch/mips/ath79/machtypes.h ++++ b/arch/mips/ath79/machtypes.h +@@ -69,6 +69,7 @@ enum ath79_mach_type { + ATH79_MACH_HORNET_UB, /* ALFA Networks Hornet-UB */ + ATH79_MACH_MR12, /* Cisco Meraki MR12 */ + ATH79_MACH_MR16, /* Cisco Meraki MR16 */ ++ ATH79_MACH_MR1750, /* OpenMesh MR1750 */ + ATH79_MACH_MR600V2, /* OpenMesh MR600v2 */ + ATH79_MACH_MR600, /* OpenMesh MR600 */ + ATH79_MACH_MR900, /* OpenMesh MR900 */ -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Thu May 19 14:20:46 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Thu, 19 May 2016 20:20:46 +0200 Subject: [OpenWrt-Devel] [PATCH CC 03/34] ar71xx: add user-space support for the OpenMesh MR1750 board In-Reply-To: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463682077-19339-3-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann Backport of r46927 --- target/linux/ar71xx/base-files/etc/diag.sh | 3 +++ target/linux/ar71xx/base-files/etc/uci-defaults/01_leds | 6 ++++++ target/linux/ar71xx/base-files/etc/uci-defaults/02_network | 1 + target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 +++ 4 files changed, 13 insertions(+) diff --git a/target/linux/ar71xx/base-files/etc/diag.sh b/target/linux/ar71xx/base-files/etc/diag.sh index 5a184cd..b2ee163 100644 --- a/target/linux/ar71xx/base-files/etc/diag.sh +++ b/target/linux/ar71xx/base-files/etc/diag.sh @@ -143,6 +143,9 @@ get_status_led() { mr600v2) status_led="mr600:blue:power" ;; + mr1750) + status_led="mr1750:blue:power" + ;; mr900 | \ mr900v2) status_led="mr900:blue:power" diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds index a4b355a..c451124 100644 --- a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds @@ -239,6 +239,12 @@ mr600) ucidef_set_led_wlan "wlan58" "WLAN58" "mr600:green:wlan58" "phy0tpt" ;; +mr1750) + ucidef_set_led_netdev "lan" "LAN" "mr1750:blue:wan" "eth0" + ucidef_set_led_wlan "wlan58" "WLAN58" "mr1750:blue:wlan58" "phy0tpt" + ucidef_set_led_wlan "wlan24" "WLAN24" "mr1750:blue:wlan24" "phy1tpt" + ;; + mr900 | \ mr900v2) ucidef_set_led_netdev "lan" "LAN" "mr900:blue:wan" "eth0" diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network index b2e15bb..49e491f 100755 --- a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network @@ -334,6 +334,7 @@ eap300v2 |\ eap7660d |\ el-mini |\ loco-m-xw |\ +mr1750 |\ mr600 |\ mr600v2 |\ mr900 |\ diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh b/target/linux/ar71xx/base-files/lib/ar71xx.sh index dab4d2c..7af29db 100755 --- a/target/linux/ar71xx/base-files/lib/ar71xx.sh +++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh @@ -518,6 +518,9 @@ ar71xx_board_detect() { *MR600v2) name="mr600v2" ;; + *MR1750) + name="mr1750" + ;; *MR600) name="mr600" ;; -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Thu May 19 14:20:47 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Thu, 19 May 2016 20:20:47 +0200 Subject: [OpenWrt-Devel] [PATCH CC 04/34] scripts/om-fwupgradecfg-gen.sh: add support for the MR1750 In-Reply-To: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463682077-19339-4-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann Backport of r46928 --- scripts/om-fwupgradecfg-gen.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/om-fwupgradecfg-gen.sh b/scripts/om-fwupgradecfg-gen.sh index e132954..c790214 100644 --- a/scripts/om-fwupgradecfg-gen.sh +++ b/scripts/om-fwupgradecfg-gen.sh @@ -7,7 +7,7 @@ # usage() { - echo "Usage: $0 " + echo "Usage: $0 " rm -f $CFG_OUT exit 1 } @@ -26,7 +26,7 @@ case $CE_TYPE in FLASH_BS=262144 MD5_SKIP_BLOCKS=1 ;; - OM5P|MR600|MR900) + OM5P|MR600|MR900|MR1750) MAX_PART_SIZE=7808 KERNEL_FLASH_ADDR=0xb0000 FLASH_BS=65536 -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Thu May 19 14:20:48 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Thu, 19 May 2016 20:20:48 +0200 Subject: [OpenWrt-Devel] [PATCH CC 05/34] ar71xx: enable sysupgrade for the OpenMesh MR1750 In-Reply-To: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463682077-19339-5-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann Backport of r46929 --- target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh | 7 ++++++- target/linux/ar71xx/base-files/lib/upgrade/platform.sh | 2 ++ 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh b/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh index 547116e..9ca0f5b 100644 --- a/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh +++ b/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh @@ -72,6 +72,11 @@ platform_check_image_openmesh() echo "Invalid image board target ($img_board_target) for this platform: $board. Use the correct image for this platform" return 1 ;; + MR1750) + [ "$board" = "mr1750" ] && break + echo "Invalid image board target ($img_board_target) for this platform: $board. Use the correct image for this platform" + return 1 + ;; MR600) [ "$board" = "mr600" ] && break [ "$board" = "mr600v2" ] && break @@ -157,7 +162,7 @@ platform_do_upgrade_openmesh() kernel_start_addr1=0x9f1c0000 kernel_start_addr2=0x9f8c0000 ;; - OM5P|MR600|MR900) + OM5P|MR600|MR900|MR1750) block_size=$((64 * 1024)) total_size=7995392 kernel_start_addr1=0x9f0b0000 diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh index d025632..5053cec 100755 --- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh +++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh @@ -290,6 +290,7 @@ platform_check_image() { return 0; ;; + mr1750 | \ mr600 | \ mr600v2 | \ mr900 | \ @@ -518,6 +519,7 @@ platform_do_upgrade() { tew-673gru) platform_do_upgrade_dir825b "$ARGV" ;; + mr1750 | \ mr600 | \ mr600v2 | \ mr900 | \ -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Thu May 19 14:20:49 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Thu, 19 May 2016 20:20:49 +0200 Subject: [OpenWrt-Devel] [PATCH CC 06/34] package/om-watchdog: add OpenMesh MR1750 support In-Reply-To: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463682077-19339-6-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann Backport of r46930 --- package/kernel/om-watchdog/files/om-watchdog.init | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/kernel/om-watchdog/files/om-watchdog.init b/package/kernel/om-watchdog/files/om-watchdog.init index 135fef7..c792968 100644 --- a/package/kernel/om-watchdog/files/om-watchdog.init +++ b/package/kernel/om-watchdog/files/om-watchdog.init @@ -25,7 +25,7 @@ boot() { "mr600v2") service_start /sbin/om-watchdog 15 ;; - "mr900"|"mr900v2") + "mr900"|"mr900v2"|"mr1750") service_start /sbin/om-watchdog 16 ;; esac -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Thu May 19 14:20:50 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Thu, 19 May 2016 20:20:50 +0200 Subject: [OpenWrt-Devel] [PATCH CC 07/34] package/uboot-envtools: add OpenMesh MR1750 support In-Reply-To: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463682077-19339-7-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann Backport of r46931 --- package/boot/uboot-envtools/files/ar71xx | 1 + 1 file changed, 1 insertion(+) diff --git a/package/boot/uboot-envtools/files/ar71xx b/package/boot/uboot-envtools/files/ar71xx index ec8541c..ef00f17 100644 --- a/package/boot/uboot-envtools/files/ar71xx +++ b/package/boot/uboot-envtools/files/ar71xx @@ -21,6 +21,7 @@ carambola2 | \ eap300v2 | \ hornet-ub | \ hornet-ub-x2 | \ +mr1750 | \ mr600 | \ mr600v2 | \ mr900 | \ -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Thu May 19 14:20:51 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Thu, 19 May 2016 20:20:51 +0200 Subject: [OpenWrt-Devel] [PATCH CC 08/34] ar71xx: create profile and build image for the OpenMesh MR1750 board In-Reply-To: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463682077-19339-8-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann Backport of r46932 --- target/linux/ar71xx/generic/profiles/openmesh.mk | 13 ++++++++++++- target/linux/ar71xx/image/Makefile | 3 ++- 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/target/linux/ar71xx/generic/profiles/openmesh.mk b/target/linux/ar71xx/generic/profiles/openmesh.mk index 41b462e..06cf135 100644 --- a/target/linux/ar71xx/generic/profiles/openmesh.mk +++ b/target/linux/ar71xx/generic/profiles/openmesh.mk @@ -49,9 +49,20 @@ endef $(eval $(call Profile,MR900)) +define Profile/MR1750 + NAME:=OpenMesh MR1750 + PACKAGES:=kmod-ath9k kmod-ath10k ath10k-firmware-qca988x +endef + +define Profile/MR1750/Description + Package set optimized for the OpenMesh MR1750. +endef + +$(eval $(call Profile,MR1750)) + define Profile/OPENMESH NAME:=OpenMesh products - PACKAGES:=kmod-ath9k om-watchdog + PACKAGES:=kmod-ath9k kmod-ath10k om-watchdog endef define Profile/OPENMESH/Description diff --git a/target/linux/ar71xx/image/Makefile b/target/linux/ar71xx/image/Makefile index 5b0a4ec..5dd594b 100644 --- a/target/linux/ar71xx/image/Makefile +++ b/target/linux/ar71xx/image/Makefile @@ -2015,6 +2015,7 @@ $(eval $(call SingleProfile,OpenMesh,squashfs-only,OM2P,om2p,,,,OM2P)) $(eval $(call SingleProfile,OpenMesh,squashfs-only,OM5P,om5p,,,,OM5P)) $(eval $(call SingleProfile,OpenMesh,squashfs-only,MR600,mr600,,,,MR600)) $(eval $(call SingleProfile,OpenMesh,squashfs-only,MR900,mr900,,,,MR900)) +$(eval $(call SingleProfile,OpenMesh,squashfs-only,MR1750,mr1750,,,,MR1750)) $(eval $(call SingleProfile,PB4X,128k,ALL0305,all0305,ALL0305,ttyS0,115200)) $(eval $(call SingleProfile,PB4X,128k,EAP7660D,eap7660d,EAP7660D,ttyS0,115200)) @@ -2108,7 +2109,7 @@ $(eval $(call MultiProfile,AP121,AP121_2M AP121_4M)) $(eval $(call MultiProfile,DIR615IX,DIR615I1 DIR615I3)) $(eval $(call MultiProfile,AP136,AP136_010 AP136_020)) $(eval $(call MultiProfile,EWDORIN, EWDORINAP EWDORINRT EWDORIN16M)) -$(eval $(call MultiProfile,OPENMESH,OM2P OM5P MR600 MR900)) +$(eval $(call MultiProfile,OPENMESH,OM2P OM5P MR600 MR900 MR1750)) $(eval $(call MultiProfile,TEW652BRP,TEW652BRP_FW TEW652BRP_RECOVERY)) $(eval $(call MultiProfile,TLMR3220,TLMR3220V1)) $(eval $(call MultiProfile,TLMR3420,TLMR3420V1)) -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Thu May 19 14:20:52 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Thu, 19 May 2016 20:20:52 +0200 Subject: [OpenWrt-Devel] [PATCH CC 09/34] ar71xx: Extend the list of bits in QCA955X_GMAC_REG_ETH_CFG In-Reply-To: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463682077-19339-9-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann Backport of r49027 --- .../601-MIPS-ath79-add-more-register-defines.patch | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/target/linux/ar71xx/patches-3.18/601-MIPS-ath79-add-more-register-defines.patch b/target/linux/ar71xx/patches-3.18/601-MIPS-ath79-add-more-register-defines.patch index 8bf7658..797977f 100644 --- a/target/linux/ar71xx/patches-3.18/601-MIPS-ath79-add-more-register-defines.patch +++ b/target/linux/ar71xx/patches-3.18/601-MIPS-ath79-add-more-register-defines.patch @@ -207,7 +207,7 @@ #define AR934X_GPIO_REG_FUNC 0x6c #define AR71XX_GPIO_COUNT 16 -@@ -560,4 +663,153 @@ +@@ -560,4 +663,170 @@ #define AR934X_SRIF_DPLL2_OUTDIV_SHIFT 13 #define AR934X_SRIF_DPLL2_OUTDIV_MASK 0x7 @@ -358,6 +358,23 @@ +#define QCA955X_GMAC_REG_ETH_CFG 0x00 + +#define QCA955X_ETH_CFG_RGMII_EN BIT(0) ++#define QCA955X_ETH_CFG_MII_GE0 BIT(1) ++#define QCA955X_ETH_CFG_GMII_GE0 BIT(2) ++#define QCA955X_ETH_CFG_MII_GE0_MASTER BIT(3) ++#define QCA955X_ETH_CFG_MII_GE0_SLAVE BIT(4) ++#define QCA955X_ETH_CFG_GE0_ERR_EN BIT(5) +#define QCA955X_ETH_CFG_GE0_SGMII BIT(6) ++#define QCA955X_ETH_CFG_RMII_GE0 BIT(10) ++#define QCA955X_ETH_CFG_MII_CNTL_SPEED BIT(11) ++#define QCA955X_ETH_CFG_RMII_GE0_MASTER BIT(12) ++#define QCA955X_ETH_CFG_RXD_DELAY_MASK 0x3 ++#define QCA955X_ETH_CFG_RXD_DELAY_SHIFT 14 ++#define QCA955X_ETH_CFG_RDV_DELAY BIT(16) ++#define QCA955X_ETH_CFG_RDV_DELAY_MASK 0x3 ++#define QCA955X_ETH_CFG_RDV_DELAY_SHIFT 16 ++#define QCA955X_ETH_CFG_TXD_DELAY_MASK 0x3 ++#define QCA955X_ETH_CFG_TXD_DELAY_SHIFT 18 ++#define QCA955X_ETH_CFG_TXE_DELAY_MASK 0x3 ++#define QCA955X_ETH_CFG_TXE_DELAY_SHIFT 20 + #endif /* __ASM_MACH_AR71XX_REGS_H */ -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Thu May 19 14:20:53 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Thu, 19 May 2016 20:20:53 +0200 Subject: [OpenWrt-Devel] [PATCH CC 10/34] ar71xx: Use *_eth_cfg helper for Open Mesh MR900 boards In-Reply-To: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463682077-19339-10-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann Backport of r46241 --- .../linux/ar71xx/files/arch/mips/ath79/mach-mr900.c | 21 +-------------------- 1 file changed, 1 insertion(+), 20 deletions(-) diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-mr900.c b/target/linux/ar71xx/files/arch/mips/ath79/mach-mr900.c index fe3e1fa..9c3164d 100644 --- a/target/linux/ar71xx/files/arch/mips/ath79/mach-mr900.c +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-mr900.c @@ -94,24 +94,6 @@ static struct gpio_keys_button mr900_gpio_keys[] __initdata = { }, }; - -static void __init mr900_gmac_setup(void) -{ - void __iomem *base; - u32 t; - - base = ioremap(QCA955X_GMAC_BASE, QCA955X_GMAC_SIZE); - - t = __raw_readl(base + QCA955X_GMAC_REG_ETH_CFG); - - t &= ~(QCA955X_ETH_CFG_RGMII_EN | QCA955X_ETH_CFG_GE0_SGMII); - t |= QCA955X_ETH_CFG_RGMII_EN; - - __raw_writel(t, base + QCA955X_GMAC_REG_ETH_CFG); - - iounmap(base); -} - static void __init mr900_setup(void) { u8 *art = (u8 *)KSEG1ADDR(0x1fff0000); @@ -141,8 +123,7 @@ static void __init mr900_setup(void) } pdata->use_eeprom = true; - mr900_gmac_setup(); - + ath79_setup_qca955x_eth_cfg(QCA955X_ETH_CFG_RGMII_EN); ath79_register_mdio(0, 0x0); ath79_init_mac(ath79_eth0_data.mac_addr, art + MR900_MAC0_OFFSET, 0); -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Thu May 19 14:20:54 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Thu, 19 May 2016 20:20:54 +0200 Subject: [OpenWrt-Devel] [PATCH CC 11/34] ar71xx: Allow to use ath79_gpio_output_select on QCA955x In-Reply-To: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463682077-19339-11-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann Backport of r46459 --- ...79-add-gpio-func-register-for-QCA955x-SoC.patch | 60 ++++++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 target/linux/ar71xx/patches-3.18/739-MIPS-ath79-add-gpio-func-register-for-QCA955x-SoC.patch diff --git a/target/linux/ar71xx/patches-3.18/739-MIPS-ath79-add-gpio-func-register-for-QCA955x-SoC.patch b/target/linux/ar71xx/patches-3.18/739-MIPS-ath79-add-gpio-func-register-for-QCA955x-SoC.patch new file mode 100644 index 0000000..24ce7d8 --- /dev/null +++ b/target/linux/ar71xx/patches-3.18/739-MIPS-ath79-add-gpio-func-register-for-QCA955x-SoC.patch @@ -0,0 +1,60 @@ +--- a/arch/mips/ath79/gpio.c ++++ b/arch/mips/ath79/gpio.c +@@ -185,15 +185,27 @@ void __init ath79_gpio_output_select(uns + { + void __iomem *base = ath79_gpio_base; + unsigned long flags; +- unsigned int reg; ++ unsigned int reg, reg_base; ++ unsigned long gpio_count; + u32 t, s; + +- BUG_ON(!soc_is_ar934x() && !soc_is_qca953x()); ++ if (soc_is_ar934x()) { ++ gpio_count = AR934X_GPIO_COUNT; ++ reg_base = AR934X_GPIO_REG_OUT_FUNC0; ++ } else if (soc_is_qca953x()) { ++ gpio_count = QCA953X_GPIO_COUNT; ++ reg_base = QCA953X_GPIO_REG_OUT_FUNC0; ++ } else if (soc_is_qca955x()) { ++ gpio_count = QCA955X_GPIO_COUNT; ++ reg_base = QCA955X_GPIO_REG_OUT_FUNC0; ++ } else { ++ BUG(); ++ } + +- if (gpio >= AR934X_GPIO_COUNT) ++ if (gpio >= gpio_count) + return; + +- reg = AR934X_GPIO_REG_OUT_FUNC0 + 4 * (gpio / 4); ++ reg = reg_base + 4 * (gpio / 4); + s = 8 * (gpio % 4); + + spin_lock_irqsave(&ath79_gpio_lock, flags); +--- a/arch/mips/include/asm/mach-ath79/ar71xx_regs.h ++++ b/arch/mips/include/asm/mach-ath79/ar71xx_regs.h +@@ -868,6 +868,14 @@ + #define QCA953X_GPIO_OUT_MUX_LED_LINK4 44 + #define QCA953X_GPIO_OUT_MUX_LED_LINK5 45 + ++#define QCA955X_GPIO_REG_OUT_FUNC0 0x2c ++#define QCA955X_GPIO_REG_OUT_FUNC1 0x30 ++#define QCA955X_GPIO_REG_OUT_FUNC2 0x34 ++#define QCA955X_GPIO_REG_OUT_FUNC3 0x38 ++#define QCA955X_GPIO_REG_OUT_FUNC4 0x3c ++#define QCA955X_GPIO_REG_OUT_FUNC5 0x40 ++#define QCA955X_GPIO_REG_FUNC 0x6c ++ + #define QCA956X_GPIO_REG_OUT_FUNC0 0x2c + #define QCA956X_GPIO_REG_OUT_FUNC1 0x30 + #define QCA956X_GPIO_REG_OUT_FUNC2 0x34 +@@ -1007,6 +1015,8 @@ + #define AR934X_GPIO_OUT_EXT_LNA0 46 + #define AR934X_GPIO_OUT_EXT_LNA1 47 + ++#define QCA955X_GPIO_OUT_GPIO 0 ++ + /* + * MII_CTRL block + */ -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Thu May 19 14:20:55 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Thu, 19 May 2016 20:20:55 +0200 Subject: [OpenWrt-Devel] [PATCH CC 12/34] ar71xx: Add support for ath79_gpio_function_* on QCA955X In-Reply-To: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463682077-19339-12-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann Backport of r49074 --- ...9-MIPS-ath79-add-gpio-func-register-for-QCA955x-SoC.patch | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/target/linux/ar71xx/patches-3.18/739-MIPS-ath79-add-gpio-func-register-for-QCA955x-SoC.patch b/target/linux/ar71xx/patches-3.18/739-MIPS-ath79-add-gpio-func-register-for-QCA955x-SoC.patch index 24ce7d8..076a4a1 100644 --- a/target/linux/ar71xx/patches-3.18/739-MIPS-ath79-add-gpio-func-register-for-QCA955x-SoC.patch +++ b/target/linux/ar71xx/patches-3.18/739-MIPS-ath79-add-gpio-func-register-for-QCA955x-SoC.patch @@ -1,6 +1,16 @@ --- a/arch/mips/ath79/gpio.c +++ b/arch/mips/ath79/gpio.c -@@ -185,15 +185,27 @@ void __init ath79_gpio_output_select(uns +@@ -146,7 +146,8 @@ static void __iomem *ath79_gpio_get_func + if (soc_is_ar71xx() || + soc_is_ar724x() || + soc_is_ar913x() || +- soc_is_ar933x()) ++ soc_is_ar933x() || ++ soc_is_qca955x()) + reg = AR71XX_GPIO_REG_FUNC; + else if (soc_is_ar934x() || + soc_is_qca953x() || soc_is_qca956x()) +@@ -185,15 +186,27 @@ void __init ath79_gpio_output_select(uns { void __iomem *base = ath79_gpio_base; unsigned long flags; -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Thu May 19 14:20:56 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Thu, 19 May 2016 20:20:56 +0200 Subject: [OpenWrt-Devel] [PATCH CC 13/34] ar71xx: Add QCA955X GPIO mux and function definitions In-Reply-To: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463682077-19339-13-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann Backport of r49075 --- .../601-MIPS-ath79-add-more-register-defines.patch | 79 +++++++++++++++++++++- ...79-add-gpio-func-register-for-QCA955x-SoC.patch | 26 ------- 2 files changed, 77 insertions(+), 28 deletions(-) diff --git a/target/linux/ar71xx/patches-3.18/601-MIPS-ath79-add-more-register-defines.patch b/target/linux/ar71xx/patches-3.18/601-MIPS-ath79-add-more-register-defines.patch index 797977f..0126f6a 100644 --- a/target/linux/ar71xx/patches-3.18/601-MIPS-ath79-add-more-register-defines.patch +++ b/target/linux/ar71xx/patches-3.18/601-MIPS-ath79-add-more-register-defines.patch @@ -194,7 +194,7 @@ #define AR933X_BOOTSTRAP_REF_CLK_40 BIT(0) #define AR934X_BOOTSTRAP_SW_OPTION8 BIT(23) -@@ -529,6 +626,12 @@ +@@ -529,8 +626,22 @@ #define AR71XX_GPIO_REG_INT_ENABLE 0x24 #define AR71XX_GPIO_REG_FUNC 0x28 @@ -206,8 +206,18 @@ +#define AR934X_GPIO_REG_OUT_FUNC5 0x40 #define AR934X_GPIO_REG_FUNC 0x6c ++#define QCA955X_GPIO_REG_OUT_FUNC0 0x2c ++#define QCA955X_GPIO_REG_OUT_FUNC1 0x30 ++#define QCA955X_GPIO_REG_OUT_FUNC2 0x34 ++#define QCA955X_GPIO_REG_OUT_FUNC3 0x38 ++#define QCA955X_GPIO_REG_OUT_FUNC4 0x3c ++#define QCA955X_GPIO_REG_OUT_FUNC5 0x40 ++#define QCA955X_GPIO_REG_FUNC 0x6c ++ #define AR71XX_GPIO_COUNT 16 -@@ -560,4 +663,170 @@ + #define AR7240_GPIO_COUNT 18 + #define AR7241_GPIO_COUNT 20 +@@ -560,4 +671,235 @@ #define AR934X_SRIF_DPLL2_OUTDIV_SHIFT 13 #define AR934X_SRIF_DPLL2_OUTDIV_MASK 0x7 @@ -288,6 +298,71 @@ +#define AR934X_GPIO_OUT_EXT_LNA0 46 +#define AR934X_GPIO_OUT_EXT_LNA1 47 + ++#define QCA955X_GPIO_FUNC_CLK_OBS7_EN BIT(9) ++#define QCA955X_GPIO_FUNC_CLK_OBS6_EN BIT(8) ++#define QCA955X_GPIO_FUNC_CLK_OBS5_EN BIT(7) ++#define QCA955X_GPIO_FUNC_CLK_OBS4_EN BIT(6) ++#define QCA955X_GPIO_FUNC_CLK_OBS3_EN BIT(5) ++#define QCA955X_GPIO_FUNC_CLK_OBS2_EN BIT(4) ++#define QCA955X_GPIO_FUNC_CLK_OBS1_EN BIT(3) ++#define QCA955X_GPIO_FUNC_JTAG_DISABLE BIT(1) ++ ++#define QCA955X_GPIO_OUT_GPIO 0 ++#define QCA955X_MII_EXT_MDI 1 ++#define QCA955X_SLIC_DATA_OUT 3 ++#define QCA955X_SLIC_PCM_FS 4 ++#define QCA955X_SLIC_PCM_CLK 5 ++#define QCA955X_SPI_CLK 8 ++#define QCA955X_SPI_CS_0 9 ++#define QCA955X_SPI_CS_1 10 ++#define QCA955X_SPI_CS_2 11 ++#define QCA955X_SPI_MISO 12 ++#define QCA955X_I2S_CLK 13 ++#define QCA955X_I2S_WS 14 ++#define QCA955X_I2S_SD 15 ++#define QCA955X_I2S_MCK 16 ++#define QCA955X_SPDIF_OUT 17 ++#define QCA955X_UART1_TD 18 ++#define QCA955X_UART1_RTS 19 ++#define QCA955X_UART1_RD 20 ++#define QCA955X_UART1_CTS 21 ++#define QCA955X_UART0_SOUT 22 ++#define QCA955X_SPDIF2_OUT 23 ++#define QCA955X_LED_SGMII_SPEED0 24 ++#define QCA955X_LED_SGMII_SPEED1 25 ++#define QCA955X_LED_SGMII_DUPLEX 26 ++#define QCA955X_LED_SGMII_LINK_UP 27 ++#define QCA955X_SGMII_SPEED0_INVERT 28 ++#define QCA955X_SGMII_SPEED1_INVERT 29 ++#define QCA955X_SGMII_DUPLEX_INVERT 30 ++#define QCA955X_SGMII_LINK_UP_INVERT 31 ++#define QCA955X_GE1_MII_MDO 32 ++#define QCA955X_GE1_MII_MDC 33 ++#define QCA955X_SWCOM2 38 ++#define QCA955X_SWCOM3 39 ++#define QCA955X_MAC2_GPIO 40 ++#define QCA955X_MAC3_GPIO 41 ++#define QCA955X_ATT_LED 42 ++#define QCA955X_PWR_LED 43 ++#define QCA955X_TX_FRAME 44 ++#define QCA955X_RX_CLEAR_EXTERNAL 45 ++#define QCA955X_LED_NETWORK_EN 46 ++#define QCA955X_LED_POWER_EN 47 ++#define QCA955X_WMAC_GLUE_WOW 68 ++#define QCA955X_RX_CLEAR_EXTENSION 70 ++#define QCA955X_CP_NAND_CS1 73 ++#define QCA955X_USB_SUSPEND 74 ++#define QCA955X_ETH_TX_ERR 75 ++#define QCA955X_DDR_DQ_OE 76 ++#define QCA955X_CLKREQ_N_EP 77 ++#define QCA955X_CLKREQ_N_RC 78 ++#define QCA955X_CLK_OBS0 79 ++#define QCA955X_CLK_OBS1 80 ++#define QCA955X_CLK_OBS2 81 ++#define QCA955X_CLK_OBS3 82 ++#define QCA955X_CLK_OBS4 83 ++#define QCA955X_CLK_OBS5 84 ++ +/* + * MII_CTRL block + */ diff --git a/target/linux/ar71xx/patches-3.18/739-MIPS-ath79-add-gpio-func-register-for-QCA955x-SoC.patch b/target/linux/ar71xx/patches-3.18/739-MIPS-ath79-add-gpio-func-register-for-QCA955x-SoC.patch index 076a4a1..a36b8c3 100644 --- a/target/linux/ar71xx/patches-3.18/739-MIPS-ath79-add-gpio-func-register-for-QCA955x-SoC.patch +++ b/target/linux/ar71xx/patches-3.18/739-MIPS-ath79-add-gpio-func-register-for-QCA955x-SoC.patch @@ -42,29 +42,3 @@ s = 8 * (gpio % 4); spin_lock_irqsave(&ath79_gpio_lock, flags); ---- a/arch/mips/include/asm/mach-ath79/ar71xx_regs.h -+++ b/arch/mips/include/asm/mach-ath79/ar71xx_regs.h -@@ -868,6 +868,14 @@ - #define QCA953X_GPIO_OUT_MUX_LED_LINK4 44 - #define QCA953X_GPIO_OUT_MUX_LED_LINK5 45 - -+#define QCA955X_GPIO_REG_OUT_FUNC0 0x2c -+#define QCA955X_GPIO_REG_OUT_FUNC1 0x30 -+#define QCA955X_GPIO_REG_OUT_FUNC2 0x34 -+#define QCA955X_GPIO_REG_OUT_FUNC3 0x38 -+#define QCA955X_GPIO_REG_OUT_FUNC4 0x3c -+#define QCA955X_GPIO_REG_OUT_FUNC5 0x40 -+#define QCA955X_GPIO_REG_FUNC 0x6c -+ - #define QCA956X_GPIO_REG_OUT_FUNC0 0x2c - #define QCA956X_GPIO_REG_OUT_FUNC1 0x30 - #define QCA956X_GPIO_REG_OUT_FUNC2 0x34 -@@ -1007,6 +1015,8 @@ - #define AR934X_GPIO_OUT_EXT_LNA0 46 - #define AR934X_GPIO_OUT_EXT_LNA1 47 - -+#define QCA955X_GPIO_OUT_GPIO 0 -+ - /* - * MII_CTRL block - */ -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Thu May 19 14:20:57 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Thu, 19 May 2016 20:20:57 +0200 Subject: [OpenWrt-Devel] [PATCH CC 14/34] ar71xx: Use PHY fixups for Open Mesh MR900 In-Reply-To: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463682077-19339-14-git-send-email-sven.eckelmann@open-mesh.com> The delays of PHY/MAC on the MR900 are done by u-boot and OpenWrt in different ways. u-boot only modifies the ETH_CFG of the QCA955x based on the link speed. But OpenWrt can only modify the PHY delays based on the link speed. This can lead to communication problems when u-boot initializes the ETH_CFG for a specific link speed (e.g. 10BASE-T) but then OpenWrt the sets the PHY delays to an incompatible value. Instead reset the ETH_CFG delay bits of the QCA955x to a specific value and only rely on the AT803x PHY settings. Signed-off-by: Sven Eckelmann Backport of r49030 --- .../ar71xx/files/arch/mips/ath79/mach-mr900.c | 25 +++++++++++++++++++--- 1 file changed, 22 insertions(+), 3 deletions(-) diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-mr900.c b/target/linux/ar71xx/files/arch/mips/ath79/mach-mr900.c index 9c3164d..3634bf0 100644 --- a/target/linux/ar71xx/files/arch/mips/ath79/mach-mr900.c +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-mr900.c @@ -23,6 +23,7 @@ #include #include +#include #include "common.h" #include "dev-ap9x-pci.h" @@ -94,15 +95,30 @@ static struct gpio_keys_button mr900_gpio_keys[] __initdata = { }, }; +static struct at803x_platform_data mr900_at803x_data = { + .disable_smarteee = 1, + .enable_rgmii_rx_delay = 1, + .enable_rgmii_tx_delay = 0, + .fixup_rgmii_tx_delay = 1, +}; + +static struct mdio_board_info mr900_mdio0_info[] = { + { + .bus_id = "ag71xx-mdio.0", + .phy_addr = 5, + .platform_data = &mr900_at803x_data, + }, +}; + static void __init mr900_setup(void) { u8 *art = (u8 *)KSEG1ADDR(0x1fff0000); u8 mac[6], pcie_mac[6]; struct ath9k_platform_data *pdata; - ath79_eth0_pll_data.pll_1000 = 0xbe000101; - ath79_eth0_pll_data.pll_100 = 0x80000101; - ath79_eth0_pll_data.pll_10 = 0x80001313; + ath79_eth0_pll_data.pll_1000 = 0xae000000; + ath79_eth0_pll_data.pll_100 = 0xa0000101; + ath79_eth0_pll_data.pll_10 = 0xa0001313; ath79_register_m25p80(NULL); @@ -126,6 +142,9 @@ static void __init mr900_setup(void) ath79_setup_qca955x_eth_cfg(QCA955X_ETH_CFG_RGMII_EN); ath79_register_mdio(0, 0x0); + mdiobus_register_board_info(mr900_mdio0_info, + ARRAY_SIZE(mr900_mdio0_info)); + ath79_init_mac(ath79_eth0_data.mac_addr, art + MR900_MAC0_OFFSET, 0); /* GMAC0 is connected to the RMGII interface */ -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Thu May 19 14:20:58 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Thu, 19 May 2016 20:20:58 +0200 Subject: [OpenWrt-Devel] [PATCH CC 15/34] ar71xx: Use PHY fixups for Open Mesh MR1750 In-Reply-To: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463682077-19339-15-git-send-email-sven.eckelmann@open-mesh.com> The delays of PHY/MAC on the MR1750 are done by u-boot and OpenWrt in different ways. u-boot only modifies the ETH_CFG of the QCA955x based on the link speed. But OpenWrt can only modify the PHY delays based on the link speed. This can lead to communication problems when u-boot initializes the ETH_CFG for a specific link speed (e.g. 10BASE-T) but then OpenWrt the sets the PHY delays to an incompatible value. Instead reset the ETH_CFG delay bits of the QCA955x to a specific value and only rely on the AT803x PHY settings. Signed-off-by: Sven Eckelmann Backport of r49031 --- .../ar71xx/files/arch/mips/ath79/mach-mr1750.c | 25 +++++++++++++++++++--- 1 file changed, 22 insertions(+), 3 deletions(-) diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-mr1750.c b/target/linux/ar71xx/files/arch/mips/ath79/mach-mr1750.c index 8ace02f..f9e45bd 100644 --- a/target/linux/ar71xx/files/arch/mips/ath79/mach-mr1750.c +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-mr1750.c @@ -22,6 +22,7 @@ #include #include +#include #include "common.h" #include "dev-ap9x-pci.h" @@ -92,14 +93,29 @@ static struct gpio_keys_button mr1750_gpio_keys[] __initdata = { }, }; +static struct at803x_platform_data mr1750_at803x_data = { + .disable_smarteee = 1, + .enable_rgmii_rx_delay = 1, + .enable_rgmii_tx_delay = 0, + .fixup_rgmii_tx_delay = 1, +}; + +static struct mdio_board_info mr1750_mdio0_info[] = { + { + .bus_id = "ag71xx-mdio.0", + .phy_addr = 5, + .platform_data = &mr1750_at803x_data, + }, +}; + static void __init mr1750_setup(void) { u8 *art = (u8 *)KSEG1ADDR(0x1fff0000); u8 mac[6]; - ath79_eth0_pll_data.pll_1000 = 0xbe000101; - ath79_eth0_pll_data.pll_100 = 0x80000101; - ath79_eth0_pll_data.pll_10 = 0x80001313; + ath79_eth0_pll_data.pll_1000 = 0xae000000; + ath79_eth0_pll_data.pll_100 = 0xa0000101; + ath79_eth0_pll_data.pll_10 = 0xa0001313; ath79_register_m25p80(NULL); @@ -116,6 +132,9 @@ static void __init mr1750_setup(void) ath79_setup_qca955x_eth_cfg(QCA955X_ETH_CFG_RGMII_EN); ath79_register_mdio(0, 0x0); + mdiobus_register_board_info(mr1750_mdio0_info, + ARRAY_SIZE(mr1750_mdio0_info)); + ath79_init_mac(ath79_eth0_data.mac_addr, art + MR1750_MAC0_OFFSET, 0); /* GMAC0 is connected to the RMGII interface */ -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Thu May 19 14:20:59 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Thu, 19 May 2016 20:20:59 +0200 Subject: [OpenWrt-Devel] [PATCH CC 16/34] ar71xx: Use private version of ath79_setup_qca955x_eth_cfg for MR900 In-Reply-To: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463682077-19339-16-git-send-email-sven.eckelmann@open-mesh.com> The MR900 must unset some bits in ETH_CFG which were set by u-boot to work correctly under OpenWrt. But the global function ath79_setup_qca955x_eth_cfg will not unset all of them to increase the backward compatiblity with older mach-* files. A private (simplified) version for MR900 can be used instead. Signed-off-by: Sven Eckelmann Backport of r49069 --- .../ar71xx/files/arch/mips/ath79/mach-mr900.c | 24 +++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-mr900.c b/target/linux/ar71xx/files/arch/mips/ath79/mach-mr900.c index 3634bf0..b439f58 100644 --- a/target/linux/ar71xx/files/arch/mips/ath79/mach-mr900.c +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-mr900.c @@ -110,6 +110,28 @@ static struct mdio_board_info mr900_mdio0_info[] = { }, }; +static void __init mr900_setup_qca955x_eth_cfg(u32 mask, + unsigned int rxd, + unsigned int rxdv, + unsigned int txd, + unsigned int txe) +{ + void __iomem *base; + u32 t; + + base = ioremap(QCA955X_GMAC_BASE, QCA955X_GMAC_SIZE); + + t = mask; + t |= rxd << QCA955X_ETH_CFG_RXD_DELAY_SHIFT; + t |= rxdv << QCA955X_ETH_CFG_RDV_DELAY_SHIFT; + t |= txd << QCA955X_ETH_CFG_TXD_DELAY_SHIFT; + t |= txe << QCA955X_ETH_CFG_TXE_DELAY_SHIFT; + + __raw_writel(t, base + QCA955X_GMAC_REG_ETH_CFG); + + iounmap(base); +} + static void __init mr900_setup(void) { u8 *art = (u8 *)KSEG1ADDR(0x1fff0000); @@ -139,7 +161,7 @@ static void __init mr900_setup(void) } pdata->use_eeprom = true; - ath79_setup_qca955x_eth_cfg(QCA955X_ETH_CFG_RGMII_EN); + mr900_setup_qca955x_eth_cfg(QCA955X_ETH_CFG_RGMII_EN, 3, 3, 0, 0); ath79_register_mdio(0, 0x0); mdiobus_register_board_info(mr900_mdio0_info, -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Thu May 19 14:21:00 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Thu, 19 May 2016 20:21:00 +0200 Subject: [OpenWrt-Devel] [PATCH CC 17/34] ar71xx: Use private version of ath79_setup_qca955x_eth_cfg for MR1750 In-Reply-To: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463682077-19339-17-git-send-email-sven.eckelmann@open-mesh.com> The MR1750 must unset some bits in ETH_CFG which were set by u-boot to work correctly under OpenWrt. But the global function ath79_setup_qca955x_eth_cfg will not unset all of them to increase the backward compatiblity with older mach-* files. A private (simplified) version for MR1750 can be used instead. Signed-off-by: Sven Eckelmann Backport of r49070 --- .../ar71xx/files/arch/mips/ath79/mach-mr1750.c | 24 +++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-mr1750.c b/target/linux/ar71xx/files/arch/mips/ath79/mach-mr1750.c index f9e45bd..e3c04e7 100644 --- a/target/linux/ar71xx/files/arch/mips/ath79/mach-mr1750.c +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-mr1750.c @@ -108,6 +108,28 @@ static struct mdio_board_info mr1750_mdio0_info[] = { }, }; +static void __init mr1750_setup_qca955x_eth_cfg(u32 mask, + unsigned int rxd, + unsigned int rxdv, + unsigned int txd, + unsigned int txe) +{ + void __iomem *base; + u32 t; + + base = ioremap(QCA955X_GMAC_BASE, QCA955X_GMAC_SIZE); + + t = mask; + t |= rxd << QCA955X_ETH_CFG_RXD_DELAY_SHIFT; + t |= rxdv << QCA955X_ETH_CFG_RDV_DELAY_SHIFT; + t |= txd << QCA955X_ETH_CFG_TXD_DELAY_SHIFT; + t |= txe << QCA955X_ETH_CFG_TXE_DELAY_SHIFT; + + __raw_writel(t, base + QCA955X_GMAC_REG_ETH_CFG); + + iounmap(base); +} + static void __init mr1750_setup(void) { u8 *art = (u8 *)KSEG1ADDR(0x1fff0000); @@ -129,7 +151,7 @@ static void __init mr1750_setup(void) ath79_register_wmac(art + MR1750_WMAC_CALDATA_OFFSET, mac); ath79_register_pci(); - ath79_setup_qca955x_eth_cfg(QCA955X_ETH_CFG_RGMII_EN); + mr1750_setup_qca955x_eth_cfg(QCA955X_ETH_CFG_RGMII_EN, 3, 3, 0, 0); ath79_register_mdio(0, 0x0); mdiobus_register_board_info(mr1750_mdio0_info, -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Thu May 19 14:21:01 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Thu, 19 May 2016 20:21:01 +0200 Subject: [OpenWrt-Devel] [PATCH CC 18/34] scripts/om-fwupgradecfg-gen.sh: Fix u-boot image md5sum check In-Reply-To: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463682077-19339-18-git-send-email-sven.eckelmann@open-mesh.com> The u-boot on Open Mesh devices checks the whole transfered image against a md5sum. This is stored inside the option filemd5sum inside the fwupgrade.cfg. The bootloader will not check it when this setting is missing and could therefore write invalid images to the flash. Signed-off-by: Sven Eckelmann Backport of r46925 --- scripts/om-fwupgradecfg-gen.sh | 3 +++ 1 file changed, 3 insertions(+) diff --git a/scripts/om-fwupgradecfg-gen.sh b/scripts/om-fwupgradecfg-gen.sh index c790214..fab1582 100644 --- a/scripts/om-fwupgradecfg-gen.sh +++ b/scripts/om-fwupgradecfg-gen.sh @@ -48,6 +48,7 @@ ROOTFS_FLASH_ADDR=$(addr=$(($KERNEL_FLASH_ADDR + ($KERNEL_PART_SIZE * 1024))); p ROOTFS_SIZE=$(stat -c%s "$ROOTFS_PATH") ROOTFS_CHECK_BLOCKS=$((($ROOTFS_SIZE / $CHECK_BS) - $MD5_SKIP_BLOCKS)) ROOTFS_MD5=$(md5=$(dd if=$ROOTFS_PATH bs=$CHECK_BS count=$ROOTFS_CHECK_BLOCKS 2>&- | md5sum); echo ${md5%% *}) +ROOTFS_MD5_FULL=$(md5=$(md5sum $ROOTFS_PATH); echo ${md5%% *}) ROOTFS_CHECK_SIZE=$(printf '0x%x' $(($ROOTFS_CHECK_BLOCKS * $CHECK_BS))) ROOTFS_PART_SIZE=$(($MAX_PART_SIZE - $KERNEL_PART_SIZE)) @@ -55,6 +56,7 @@ cat << EOF > $CFG_OUT [vmlinux] filename=kernel md5sum=$KERNEL_MD5 +filemd5sum=$KERNEL_MD5 flashaddr=$KERNEL_FLASH_ADDR checksize=0x0 cmd_success=setenv bootseq 1,2; setenv kernel_size_1 $KERNEL_PART_SIZE; saveenv @@ -63,6 +65,7 @@ cmd_fail=reset [rootfs] filename=rootfs md5sum=$ROOTFS_MD5 +filemd5sum=$ROOTFS_MD5_FULL flashaddr=$ROOTFS_FLASH_ADDR checksize=$ROOTFS_CHECK_SIZE cmd_success=setenv bootseq 1,2; setenv kernel_size_1 $KERNEL_PART_SIZE; setenv rootfs_size_1 $ROOTFS_PART_SIZE; saveenv -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Thu May 19 14:21:02 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Thu, 19 May 2016 20:21:02 +0200 Subject: [OpenWrt-Devel] [PATCH CC 19/34] scripts/om-fwupgradecfg-gen.sh: Generate sha256sum for uboot verification In-Reply-To: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463682077-19339-19-git-send-email-sven.eckelmann@open-mesh.com> Future Open Mesh u-boot versions are changing the check of the image files (vmlinux, rootfs) from md5 to sha256. Having both in them should be enough to ensure backward and forward compatibility. Signed-off-by: Sven Eckelmann Backport of r49140 --- scripts/om-fwupgradecfg-gen.sh | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/scripts/om-fwupgradecfg-gen.sh b/scripts/om-fwupgradecfg-gen.sh index fab1582..e208e6d 100644 --- a/scripts/om-fwupgradecfg-gen.sh +++ b/scripts/om-fwupgradecfg-gen.sh @@ -42,6 +42,7 @@ CHECK_BS=65536 KERNEL_SIZE=$(stat -c%s "$KERNEL_PATH") KERNEL_MD5=$(md5=$(md5sum $KERNEL_PATH); echo ${md5%% *}) +KERNEL_SHA256=$(openssl dgst -sha256 $KERNEL_PATH | awk '{print $2}') KERNEL_PART_SIZE=$(size=$(($KERNEL_SIZE / $FLASH_BS)); [ $(($size * $FLASH_BS)) -lt $KERNEL_SIZE ] && size=$(($size + 1)); echo $(($size * $FLASH_BS / 1024))) ROOTFS_FLASH_ADDR=$(addr=$(($KERNEL_FLASH_ADDR + ($KERNEL_PART_SIZE * 1024))); printf "0x%x" $addr) @@ -49,6 +50,7 @@ ROOTFS_SIZE=$(stat -c%s "$ROOTFS_PATH") ROOTFS_CHECK_BLOCKS=$((($ROOTFS_SIZE / $CHECK_BS) - $MD5_SKIP_BLOCKS)) ROOTFS_MD5=$(md5=$(dd if=$ROOTFS_PATH bs=$CHECK_BS count=$ROOTFS_CHECK_BLOCKS 2>&- | md5sum); echo ${md5%% *}) ROOTFS_MD5_FULL=$(md5=$(md5sum $ROOTFS_PATH); echo ${md5%% *}) +ROOTFS_SHA256_FULL=$(openssl dgst -sha256 $ROOTFS_PATH | awk '{print $2}') ROOTFS_CHECK_SIZE=$(printf '0x%x' $(($ROOTFS_CHECK_BLOCKS * $CHECK_BS))) ROOTFS_PART_SIZE=$(($MAX_PART_SIZE - $KERNEL_PART_SIZE)) @@ -57,6 +59,7 @@ cat << EOF > $CFG_OUT filename=kernel md5sum=$KERNEL_MD5 filemd5sum=$KERNEL_MD5 +filesha256sum=$KERNEL_SHA256 flashaddr=$KERNEL_FLASH_ADDR checksize=0x0 cmd_success=setenv bootseq 1,2; setenv kernel_size_1 $KERNEL_PART_SIZE; saveenv @@ -66,6 +69,7 @@ cmd_fail=reset filename=rootfs md5sum=$ROOTFS_MD5 filemd5sum=$ROOTFS_MD5_FULL +filesha256sum=$ROOTFS_SHA256_FULL flashaddr=$ROOTFS_FLASH_ADDR checksize=$ROOTFS_CHECK_SIZE cmd_success=setenv bootseq 1,2; setenv kernel_size_1 $KERNEL_PART_SIZE; setenv rootfs_size_1 $ROOTFS_PART_SIZE; saveenv -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Thu May 19 14:21:03 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Thu, 19 May 2016 20:21:03 +0200 Subject: [OpenWrt-Devel] [PATCH CC 20/34] ar71xx: add kernel support for the OpenMesh OM5P-AC board In-Reply-To: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463682077-19339-20-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann Backport of r49141 --- target/linux/ar71xx/config-3.18 | 1 + .../ar71xx/files/arch/mips/ath79/mach-om5pac.c | 193 +++++++++++++++++++++ .../815-MIPS-ath79-add-om5pac-support.patch | 38 ++++ 3 files changed, 232 insertions(+) create mode 100644 target/linux/ar71xx/files/arch/mips/ath79/mach-om5pac.c create mode 100644 target/linux/ar71xx/patches-3.18/815-MIPS-ath79-add-om5pac-support.patch diff --git a/target/linux/ar71xx/config-3.18 b/target/linux/ar71xx/config-3.18 index 2354c9c..9a66711 100644 --- a/target/linux/ar71xx/config-3.18 +++ b/target/linux/ar71xx/config-3.18 @@ -91,6 +91,7 @@ CONFIG_ATH79_MACH_NBG460N=y CONFIG_ATH79_MACH_NBG6716=y CONFIG_ATH79_MACH_OM2P=y CONFIG_ATH79_MACH_OM5P=y +CONFIG_ATH79_MACH_OM5P_AC=y CONFIG_ATH79_MACH_ONION_OMEGA=y CONFIG_ATH79_MACH_PB42=y CONFIG_ATH79_MACH_PB44=y diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-om5pac.c b/target/linux/ar71xx/files/arch/mips/ath79/mach-om5pac.c new file mode 100644 index 0000000..f6974af --- /dev/null +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-om5pac.c @@ -0,0 +1,193 @@ +/* + * OpenMesh OM5P-AC support + * + * Copyright (C) 2013 Marek Lindner + * Copyright (C) 2014 Sven Eckelmann + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 as published + * by the Free Software Foundation. + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +#include "common.h" +#include "dev-ap9x-pci.h" +#include "dev-eth.h" +#include "dev-leds-gpio.h" +#include "dev-m25p80.h" +#include "dev-wmac.h" +#include "machtypes.h" +#include "pci.h" + +#define OM5PAC_GPIO_LED_POWER 18 +#define OM5PAC_GPIO_LED_GREEN 21 +#define OM5PAC_GPIO_LED_RED 23 +#define OM5PAC_GPIO_LED_YELLOW 22 +#define OM5PAC_GPIO_LED_LAN 20 +#define OM5PAC_GPIO_LED_WAN 19 +#define OM5PAC_GPIO_I2C_SCL 12 +#define OM5PAC_GPIO_I2C_SDA 11 + +#define OM5PAC_KEYS_POLL_INTERVAL 20 /* msecs */ +#define OM5PAC_KEYS_DEBOUNCE_INTERVAL (3 * OM5PAC_KEYS_POLL_INTERVAL) + +#define OM5PAC_WMAC_CALDATA_OFFSET 0x1000 + +static struct gpio_led om5pac_leds_gpio[] __initdata = { + { + .name = "om5pac:blue:power", + .gpio = OM5PAC_GPIO_LED_POWER, + .active_low = 1, + }, { + .name = "om5pac:red:wifi", + .gpio = OM5PAC_GPIO_LED_RED, + .active_low = 1, + }, { + .name = "om5pac:yellow:wifi", + .gpio = OM5PAC_GPIO_LED_YELLOW, + .active_low = 1, + }, { + .name = "om5pac:green:wifi", + .gpio = OM5PAC_GPIO_LED_GREEN, + .active_low = 1, + }, { + .name = "om5pac:blue:lan", + .gpio = OM5PAC_GPIO_LED_LAN, + .active_low = 1, + }, { + .name = "om5pac:blue:wan", + .gpio = OM5PAC_GPIO_LED_WAN, + .active_low = 1, + } +}; + +static struct flash_platform_data om5pac_flash_data = { + .type = "mx25l12805d", +}; + +static struct i2c_gpio_platform_data om5pac_i2c_device_platdata = { + .sda_pin = OM5PAC_GPIO_I2C_SDA, + .scl_pin = OM5PAC_GPIO_I2C_SCL, + .udelay = 10, + .sda_is_open_drain = 1, + .scl_is_open_drain = 1, +}; + +static struct platform_device om5pac_i2c_device = { + .name = "i2c-gpio", + .id = 0, + .dev = { + .platform_data = &om5pac_i2c_device_platdata, + }, +}; + +static struct i2c_board_info om5pac_i2c_devs[] __initdata = { + { + I2C_BOARD_INFO("tmp423", 0x4c), + }, +}; + +static struct at803x_platform_data om5pac_at803x_data = { + .disable_smarteee = 1, + .enable_rgmii_rx_delay = 1, + .enable_rgmii_tx_delay = 1, +}; + +static struct mdio_board_info om5pac_mdio0_info[] = { + { + .bus_id = "ag71xx-mdio.0", + .phy_addr = 1, + .platform_data = &om5pac_at803x_data, + }, + { + .bus_id = "ag71xx-mdio.0", + .phy_addr = 2, + .platform_data = &om5pac_at803x_data, + }, +}; + +static void __init om5p_ac_setup_qca955x_eth_cfg(u32 mask, + unsigned int rxd, + unsigned int rxdv, + unsigned int txd, + unsigned int txe) +{ + void __iomem *base; + u32 t; + + base = ioremap(QCA955X_GMAC_BASE, QCA955X_GMAC_SIZE); + + t = mask; + t |= rxd << QCA955X_ETH_CFG_RXD_DELAY_SHIFT; + t |= rxdv << QCA955X_ETH_CFG_RDV_DELAY_SHIFT; + t |= txd << QCA955X_ETH_CFG_TXD_DELAY_SHIFT; + t |= txe << QCA955X_ETH_CFG_TXE_DELAY_SHIFT; + + __raw_writel(t, base + QCA955X_GMAC_REG_ETH_CFG); + + iounmap(base); +} + +static void __init om5p_ac_setup(void) +{ + u8 *art = (u8 *)KSEG1ADDR(0x1fff0000); + u8 mac[6]; + + /* temperature sensor */ + platform_device_register(&om5pac_i2c_device); + i2c_register_board_info(0, om5pac_i2c_devs, + ARRAY_SIZE(om5pac_i2c_devs)); + + ath79_gpio_output_select(OM5PAC_GPIO_LED_WAN, QCA955X_GPIO_OUT_GPIO); + + ath79_register_m25p80(&om5pac_flash_data); + ath79_register_leds_gpio(-1, ARRAY_SIZE(om5pac_leds_gpio), + om5pac_leds_gpio); + + ath79_init_mac(mac, art, 0x02); + ath79_register_wmac(art + OM5PAC_WMAC_CALDATA_OFFSET, mac); + + om5p_ac_setup_qca955x_eth_cfg(QCA955X_ETH_CFG_RGMII_EN, 3, 3, 0, 0); + ath79_register_mdio(0, 0x0); + + mdiobus_register_board_info(om5pac_mdio0_info, + ARRAY_SIZE(om5pac_mdio0_info)); + + ath79_init_mac(ath79_eth0_data.mac_addr, art, 0x00); + ath79_init_mac(ath79_eth1_data.mac_addr, art, 0x01); + + /* GMAC0 is connected to the PHY1 */ + ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_RGMII; + ath79_eth0_data.mii_bus_dev = &ath79_mdio0_device.dev; + ath79_eth0_data.phy_mask = BIT(1); + ath79_eth0_pll_data.pll_1000 = 0x82000101; + ath79_eth0_pll_data.pll_100 = 0x80000101; + ath79_eth0_pll_data.pll_10 = 0x80001313; + ath79_register_eth(0); + + /* GMAC1 is connected to MDIO1 in SGMII mode */ + ath79_eth1_data.phy_if_mode = PHY_INTERFACE_MODE_SGMII; + ath79_eth1_data.mii_bus_dev = &ath79_mdio0_device.dev; + ath79_eth1_data.phy_mask = BIT(2); + ath79_eth1_pll_data.pll_1000 = 0x03000101; + ath79_eth1_pll_data.pll_100 = 0x80000101; + ath79_eth1_pll_data.pll_10 = 0x80001313; + ath79_eth1_data.speed = SPEED_1000; + ath79_eth1_data.duplex = DUPLEX_FULL; + ath79_register_eth(1); + + ath79_register_pci(); +} + +MIPS_MACHINE(ATH79_MACH_OM5P_AC, "OM5P-AC", "OpenMesh OM5P AC", om5p_ac_setup); diff --git a/target/linux/ar71xx/patches-3.18/815-MIPS-ath79-add-om5pac-support.patch b/target/linux/ar71xx/patches-3.18/815-MIPS-ath79-add-om5pac-support.patch new file mode 100644 index 0000000..4accd03 --- /dev/null +++ b/target/linux/ar71xx/patches-3.18/815-MIPS-ath79-add-om5pac-support.patch @@ -0,0 +1,38 @@ +--- a/arch/mips/ath79/Kconfig ++++ b/arch/mips/ath79/Kconfig +@@ -799,6 +799,15 @@ config ATH79_MACH_OM5P + select ATH79_DEV_M25P80 + select ATH79_DEV_WMAC + ++config ATH79_MACH_OM5P_AC ++ bool "OpenMesh OM5P-AC board support" ++ select SOC_QCA955X ++ select ATH79_DEV_AP9X_PCI if PCI ++ select ATH79_DEV_ETH ++ select ATH79_DEV_LEDS_GPIO ++ select ATH79_DEV_M25P80 ++ select ATH79_DEV_WMAC ++ + config ATH79_MACH_ONION_OMEGA + bool "ONION OMEGA support" + select SOC_AR933X +--- a/arch/mips/ath79/Makefile ++++ b/arch/mips/ath79/Makefile +@@ -100,6 +100,7 @@ obj-$(CONFIG_ATH79_MACH_MZK_W300NH) += m + obj-$(CONFIG_ATH79_MACH_NBG460N) += mach-nbg460n.o + obj-$(CONFIG_ATH79_MACH_OM2P) += mach-om2p.o + obj-$(CONFIG_ATH79_MACH_OM5P) += mach-om5p.o ++obj-$(CONFIG_ATH79_MACH_OM5P_AC) += mach-om5pac.o + obj-$(CONFIG_ATH79_MACH_ONION_OMEGA) += mach-onion-omega.o + obj-$(CONFIG_ATH79_MACH_PB42) += mach-pb42.o + obj-$(CONFIG_ATH79_MACH_PB44) += mach-pb44.o +--- a/arch/mips/ath79/machtypes.h ++++ b/arch/mips/ath79/machtypes.h +@@ -95,6 +95,7 @@ enum ath79_mach_type { + ATH79_MACH_OM2P_LC, /* OpenMesh OM2P-LC */ + ATH79_MACH_OM2Pv2, /* OpenMesh OM2Pv2 */ + ATH79_MACH_OM2P, /* OpenMesh OM2P */ ++ ATH79_MACH_OM5P_AC, /* OpenMesh OM5P-AC */ + ATH79_MACH_OM5P_AN, /* OpenMesh OM5P-AN */ + ATH79_MACH_OM5P, /* OpenMesh OM5P */ + ATH79_MACH_ONION_OMEGA, /* ONION OMEGA */ -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Thu May 19 14:21:04 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Thu, 19 May 2016 20:21:04 +0200 Subject: [OpenWrt-Devel] [PATCH CC 21/34] ar71xx: add user-space support for the OpenMesh OM5P-AC In-Reply-To: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463682077-19339-21-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann Backport of r49142 --- target/linux/ar71xx/base-files/etc/diag.sh | 3 +++ target/linux/ar71xx/base-files/etc/uci-defaults/01_leds | 5 +++++ target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 +++ 3 files changed, 11 insertions(+) diff --git a/target/linux/ar71xx/base-files/etc/diag.sh b/target/linux/ar71xx/base-files/etc/diag.sh index b2ee163..7528620 100644 --- a/target/linux/ar71xx/base-files/etc/diag.sh +++ b/target/linux/ar71xx/base-files/etc/diag.sh @@ -178,6 +178,9 @@ get_status_led() { om5p-an) status_led="om5p:blue:power" ;; + om5p-ac) + status_led="om5pac:blue:power" + ;; onion-omega) status_led="onion:amber:system" ;; diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds index c451124..9a768cd 100644 --- a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds @@ -304,6 +304,11 @@ om5p-an) ucidef_set_led_netdev "port2" "port2" "om5p:blue:lan" "eth1" ;; +om5p-ac) + ucidef_set_led_netdev "port1" "port1" "om5pac:blue:lan" "eth0" + ucidef_set_led_netdev "port2" "port2" "om5pac:blue:wan" "eth1" + ;; + qihoo-c301) ucidef_set_led_wlan "wlan2g" "WLAN2G" "qihoo:red:status" "phy1tpt" ;; diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh b/target/linux/ar71xx/base-files/lib/ar71xx.sh index 7af29db..9354057 100755 --- a/target/linux/ar71xx/base-files/lib/ar71xx.sh +++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh @@ -572,6 +572,9 @@ ar71xx_board_detect() { *"OM5P AN") name="om5p-an" ;; + *"OM5P AC") + name="om5p-ac" + ;; *"Onion Omega") name="onion-omega" ;; -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Thu May 19 14:21:05 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Thu, 19 May 2016 20:21:05 +0200 Subject: [OpenWrt-Devel] [PATCH CC 22/34] scripts/om-fwupgradecfg-gen.sh: add support for the OM5P-AC In-Reply-To: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463682077-19339-22-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann Backport of r49143 --- scripts/om-fwupgradecfg-gen.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/om-fwupgradecfg-gen.sh b/scripts/om-fwupgradecfg-gen.sh index e208e6d..6c3b74c 100644 --- a/scripts/om-fwupgradecfg-gen.sh +++ b/scripts/om-fwupgradecfg-gen.sh @@ -7,7 +7,7 @@ # usage() { - echo "Usage: $0 " + echo "Usage: $0 " rm -f $CFG_OUT exit 1 } @@ -26,7 +26,7 @@ case $CE_TYPE in FLASH_BS=262144 MD5_SKIP_BLOCKS=1 ;; - OM5P|MR600|MR900|MR1750) + OM5P|OM5PAC|MR600|MR900|MR1750) MAX_PART_SIZE=7808 KERNEL_FLASH_ADDR=0xb0000 FLASH_BS=65536 -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Thu May 19 14:21:06 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Thu, 19 May 2016 20:21:06 +0200 Subject: [OpenWrt-Devel] [PATCH CC 23/34] ar71xx: enable sysupgrade for the OpenMesh OM5P-AC In-Reply-To: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463682077-19339-23-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann Backport of r49144 --- target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh | 7 ++++++- target/linux/ar71xx/base-files/lib/upgrade/platform.sh | 6 ++++-- 2 files changed, 10 insertions(+), 3 deletions(-) diff --git a/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh b/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh index 9ca0f5b..1cfead9 100644 --- a/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh +++ b/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh @@ -72,6 +72,11 @@ platform_check_image_openmesh() echo "Invalid image board target ($img_board_target) for this platform: $board. Use the correct image for this platform" return 1 ;; + OM5PAC) + [ "$board" = "om5p-ac" ] && break + echo "Invalid image board target ($img_board_target) for this platform: $board. Use the correct image for this platform" + return 1 + ;; MR1750) [ "$board" = "mr1750" ] && break echo "Invalid image board target ($img_board_target) for this platform: $board. Use the correct image for this platform" @@ -162,7 +167,7 @@ platform_do_upgrade_openmesh() kernel_start_addr1=0x9f1c0000 kernel_start_addr2=0x9f8c0000 ;; - OM5P|MR600|MR900|MR1750) + OM5P|OM5PAC|MR600|MR900|MR1750) block_size=$((64 * 1024)) total_size=7995392 kernel_start_addr1=0x9f0b0000 diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh index 5053cec..eb5c01e 100755 --- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh +++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh @@ -301,7 +301,8 @@ platform_check_image() { om2p-hsv2 | \ om2p-lc | \ om5p | \ - om5p-an) + om5p-an | \ + om5p-ac) platform_check_image_openmesh "$magic_long" "$1" && return 0 return 1 ;; @@ -530,7 +531,8 @@ platform_do_upgrade() { om2p-hsv2 | \ om2p-lc | \ om5p | \ - om5p-an) + om5p-an | \ + om5p-ac) platform_do_upgrade_openmesh "$ARGV" ;; unifi-outdoor-plus | \ -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Thu May 19 14:21:07 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Thu, 19 May 2016 20:21:07 +0200 Subject: [OpenWrt-Devel] [PATCH CC 24/34] om-watchdog: add OpenMesh OM5P-AC support In-Reply-To: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463682077-19339-24-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann Backport of r49145 --- package/kernel/om-watchdog/files/om-watchdog.init | 3 +++ 1 file changed, 3 insertions(+) diff --git a/package/kernel/om-watchdog/files/om-watchdog.init b/package/kernel/om-watchdog/files/om-watchdog.init index c792968..8cec13b 100644 --- a/package/kernel/om-watchdog/files/om-watchdog.init +++ b/package/kernel/om-watchdog/files/om-watchdog.init @@ -22,6 +22,9 @@ boot() { "om5p"|"om5p-an") service_start /sbin/om-watchdog 11 ;; + "om5p-ac") + service_start /sbin/om-watchdog 17 + ;; "mr600v2") service_start /sbin/om-watchdog 15 ;; -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Thu May 19 14:21:08 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Thu, 19 May 2016 20:21:08 +0200 Subject: [OpenWrt-Devel] [PATCH CC 25/34] uboot-envtools: add OpenMesh OM5P-AC support In-Reply-To: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463682077-19339-25-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann Backport of r49146 --- package/boot/uboot-envtools/files/ar71xx | 1 + 1 file changed, 1 insertion(+) diff --git a/package/boot/uboot-envtools/files/ar71xx b/package/boot/uboot-envtools/files/ar71xx index ef00f17..657b25f 100644 --- a/package/boot/uboot-envtools/files/ar71xx +++ b/package/boot/uboot-envtools/files/ar71xx @@ -28,6 +28,7 @@ mr900 | \ mr900v2 | \ nbg6716 | \ om5p-an | \ +om5p-ac | \ om5p | \ tube2h | \ wndr3700) -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Thu May 19 14:21:09 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Thu, 19 May 2016 20:21:09 +0200 Subject: [OpenWrt-Devel] [PATCH CC 26/34] ar71xx: extract ath10k wifi board.bin for the OpenMesh OM5P-AC board In-Reply-To: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463682077-19339-26-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann Backport of r49147 --- .../linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata index e6fcec8..1b6de1e 100644 --- a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata +++ b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata @@ -95,6 +95,10 @@ case "$FIRMWARE" in rb-911g-5hpacd) ath10kcal_from_file "/sys/firmware/routerboot/ext_wlan_data" 20480 2116 ;; + om5p-ac) + ath10kcal_extract "ART" 20480 2116 + ath10kcal_patch_mac $(macaddr_add $(cat /sys/class/net/eth0/address) +16) + ;; esac ;; *) -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Thu May 19 14:21:10 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Thu, 19 May 2016 20:21:10 +0200 Subject: [OpenWrt-Devel] [PATCH CC 27/34] ar71xx: create profile and build image for the OpenMesh OM5P-AC board In-Reply-To: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463682077-19339-27-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann Backport of r49148 --- target/linux/ar71xx/generic/profiles/openmesh.mk | 11 +++++++++++ target/linux/ar71xx/image/Makefile | 3 ++- 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/target/linux/ar71xx/generic/profiles/openmesh.mk b/target/linux/ar71xx/generic/profiles/openmesh.mk index 06cf135..64aaa24 100644 --- a/target/linux/ar71xx/generic/profiles/openmesh.mk +++ b/target/linux/ar71xx/generic/profiles/openmesh.mk @@ -27,6 +27,17 @@ endef $(eval $(call Profile,OM5P)) +define Profile/OM5PAC + NAME:=OpenMesh OM5P-AC + PACKAGES:=kmod-ath9k kmod-ath10k om-watchdog ath10k-firmware-qca988x +endef + +define Profile/OM5PAC/Description + Package set optimized for the OpenMesh OM5P-AC. +endef + +$(eval $(call Profile,OM5PAC)) + define Profile/MR600 NAME:=OpenMesh MR600 PACKAGES:=kmod-ath9k om-watchdog diff --git a/target/linux/ar71xx/image/Makefile b/target/linux/ar71xx/image/Makefile index 5dd594b..8551399 100644 --- a/target/linux/ar71xx/image/Makefile +++ b/target/linux/ar71xx/image/Makefile @@ -2013,6 +2013,7 @@ $(eval $(call SingleProfile,Netgear,64kraw,WPN824N,wpn824n,WPN824N,ttyS0,115200, $(eval $(call SingleProfile,OpenMesh,squashfs-only,OM2P,om2p,,,,OM2P)) $(eval $(call SingleProfile,OpenMesh,squashfs-only,OM5P,om5p,,,,OM5P)) +$(eval $(call SingleProfile,OpenMesh,squashfs-only,OM5PAC,om5pac,,,,OM5PAC)) $(eval $(call SingleProfile,OpenMesh,squashfs-only,MR600,mr600,,,,MR600)) $(eval $(call SingleProfile,OpenMesh,squashfs-only,MR900,mr900,,,,MR900)) $(eval $(call SingleProfile,OpenMesh,squashfs-only,MR1750,mr1750,,,,MR1750)) @@ -2109,7 +2110,7 @@ $(eval $(call MultiProfile,AP121,AP121_2M AP121_4M)) $(eval $(call MultiProfile,DIR615IX,DIR615I1 DIR615I3)) $(eval $(call MultiProfile,AP136,AP136_010 AP136_020)) $(eval $(call MultiProfile,EWDORIN, EWDORINAP EWDORINRT EWDORIN16M)) -$(eval $(call MultiProfile,OPENMESH,OM2P OM5P MR600 MR900 MR1750)) +$(eval $(call MultiProfile,OPENMESH,OM2P OM5P OM5PAC MR600 MR900 MR1750)) $(eval $(call MultiProfile,TEW652BRP,TEW652BRP_FW TEW652BRP_RECOVERY)) $(eval $(call MultiProfile,TLMR3220,TLMR3220V1)) $(eval $(call MultiProfile,TLMR3420,TLMR3420V1)) -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Thu May 19 14:21:11 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Thu, 19 May 2016 20:21:11 +0200 Subject: [OpenWrt-Devel] [PATCH CC 28/34] ar71xx: add kernel support for the OpenMesh OM5P-ACv2 board In-Reply-To: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463682077-19339-28-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann Backport of r49149 --- target/linux/ar71xx/config-3.18 | 1 + .../ar71xx/files/arch/mips/ath79/mach-om5pacv2.c | 216 +++++++++++++++++++++ .../816-MIPS-ath79-add-om5pacv-support.patch | 39 ++++ 3 files changed, 256 insertions(+) create mode 100644 target/linux/ar71xx/files/arch/mips/ath79/mach-om5pacv2.c create mode 100644 target/linux/ar71xx/patches-3.18/816-MIPS-ath79-add-om5pacv-support.patch diff --git a/target/linux/ar71xx/config-3.18 b/target/linux/ar71xx/config-3.18 index 9a66711..e4bed08 100644 --- a/target/linux/ar71xx/config-3.18 +++ b/target/linux/ar71xx/config-3.18 @@ -92,6 +92,7 @@ CONFIG_ATH79_MACH_NBG6716=y CONFIG_ATH79_MACH_OM2P=y CONFIG_ATH79_MACH_OM5P=y CONFIG_ATH79_MACH_OM5P_AC=y +CONFIG_ATH79_MACH_OM5P_ACv2=y CONFIG_ATH79_MACH_ONION_OMEGA=y CONFIG_ATH79_MACH_PB42=y CONFIG_ATH79_MACH_PB44=y diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-om5pacv2.c b/target/linux/ar71xx/files/arch/mips/ath79/mach-om5pacv2.c new file mode 100644 index 0000000..587ca32 --- /dev/null +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-om5pacv2.c @@ -0,0 +1,216 @@ +/* + * OpenMesh OM5P-ACv2 support + * + * Copyright (C) 2013 Marek Lindner + * Copyright (C) 2014-2016 Sven Eckelmann + * Copyright (C) 2015 Open-Mesh - Jim Collar + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 as published + * by the Free Software Foundation. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +#include "common.h" +#include "dev-ap9x-pci.h" +#include "dev-eth.h" +#include "dev-gpio-buttons.h" +#include "dev-leds-gpio.h" +#include "dev-m25p80.h" +#include "dev-wmac.h" +#include "machtypes.h" +#include "pci.h" + +#define OM5PACV2_GPIO_LED_POWER 14 +#define OM5PACV2_GPIO_LED_GREEN 13 +#define OM5PACV2_GPIO_LED_RED 23 +#define OM5PACV2_GPIO_LED_YELLOW 15 +#define OM5PACV2_GPIO_BTN_RESET 1 +#define OM5PACV2_GPIO_I2C_SCL 18 +#define OM5PACV2_GPIO_I2C_SDA 19 +#define OM5PACV2_GPIO_PA_DCDC 2 +#define OM5PACV2_GPIO_PA_HIGH 16 + +#define OM5PACV2_KEYS_POLL_INTERVAL 20 /* msecs */ +#define OM5PACV2_KEYS_DEBOUNCE_INTERVAL (3 * OM5PACV2_KEYS_POLL_INTERVAL) + +#define OM5PACV2_WMAC_CALDATA_OFFSET 0x1000 + +static struct gpio_led om5pacv2_leds_gpio[] __initdata = { + { + .name = "om5pac:blue:power", + .gpio = OM5PACV2_GPIO_LED_POWER, + .active_low = 1, + }, { + .name = "om5pac:red:wifi", + .gpio = OM5PACV2_GPIO_LED_RED, + .active_low = 1, + }, { + .name = "om5pac:yellow:wifi", + .gpio = OM5PACV2_GPIO_LED_YELLOW, + .active_low = 1, + }, { + .name = "om5pac:green:wifi", + .gpio = OM5PACV2_GPIO_LED_GREEN, + .active_low = 1, + } +}; + +static struct gpio_keys_button om5pacv2_gpio_keys[] __initdata = { + { + .desc = "reset", + .type = EV_KEY, + .code = KEY_RESTART, + .debounce_interval = OM5PACV2_KEYS_DEBOUNCE_INTERVAL, + .gpio = OM5PACV2_GPIO_BTN_RESET, + .active_low = 1, + } +}; + +static struct i2c_gpio_platform_data om5pacv2_i2c_device_platdata = { + .sda_pin = OM5PACV2_GPIO_I2C_SDA, + .scl_pin = OM5PACV2_GPIO_I2C_SCL, + .udelay = 10, + .sda_is_open_drain = 1, + .scl_is_open_drain = 1, +}; + +static struct platform_device om5pacv2_i2c_device = { + .name = "i2c-gpio", + .id = 0, + .dev = { + .platform_data = &om5pacv2_i2c_device_platdata, + }, +}; + +static struct i2c_board_info om5pacv2_i2c_devs[] __initdata = { + { + I2C_BOARD_INFO("tmp423", 0x4e), + }, +}; + +static struct flash_platform_data om5pacv2_flash_data = { + .type = "mx25l12805d", +}; + +static struct at803x_platform_data om5pacv2_an_at803x_data = { + .disable_smarteee = 1, + .enable_rgmii_rx_delay = 1, + .enable_rgmii_tx_delay = 1, +}; + +static struct at803x_platform_data om5pacv2_an_at8031_data = { + .disable_smarteee = 1, + .enable_rgmii_rx_delay = 1, + .enable_rgmii_tx_delay = 1, +}; + +static struct mdio_board_info om5pacv2_an_mdio0_info[] = { + { + .bus_id = "ag71xx-mdio.0", + .phy_addr = 4, + .platform_data = &om5pacv2_an_at803x_data, + }, + { + .bus_id = "ag71xx-mdio.1", + .phy_addr = 1, + .platform_data = &om5pacv2_an_at8031_data, + }, +}; + +static void __init om5p_acv2_setup_qca955x_eth_cfg(u32 mask, + unsigned int rxd, + unsigned int rxdv, + unsigned int txd, + unsigned int txe) +{ + void __iomem *base; + u32 t; + + base = ioremap(QCA955X_GMAC_BASE, QCA955X_GMAC_SIZE); + + t = mask; + t |= rxd << QCA955X_ETH_CFG_RXD_DELAY_SHIFT; + t |= rxdv << QCA955X_ETH_CFG_RDV_DELAY_SHIFT; + t |= txd << QCA955X_ETH_CFG_TXD_DELAY_SHIFT; + t |= txe << QCA955X_ETH_CFG_TXE_DELAY_SHIFT; + + __raw_writel(t, base + QCA955X_GMAC_REG_ETH_CFG); + + iounmap(base); +} + +static void __init om5p_acv2_setup(void) +{ + u8 *art = (u8 *)KSEG1ADDR(0x1fff0000); + u8 mac[6]; + + /* power amplifier high power, 4.2V at RFFM4203/4503 instead of 3.3 */ + ath79_gpio_function_enable(QCA955X_GPIO_FUNC_JTAG_DISABLE); + ath79_gpio_output_select(OM5PACV2_GPIO_PA_DCDC, QCA955X_GPIO_OUT_GPIO); + ath79_gpio_output_select(OM5PACV2_GPIO_PA_HIGH, QCA955X_GPIO_OUT_GPIO); + gpio_request_one(OM5PACV2_GPIO_PA_DCDC, GPIOF_OUT_INIT_HIGH, + "PA DC/DC"); + gpio_request_one(OM5PACV2_GPIO_PA_HIGH, GPIOF_OUT_INIT_HIGH, "PA HIGH"); + + /* temperature sensor */ + platform_device_register(&om5pacv2_i2c_device); + i2c_register_board_info(0, om5pacv2_i2c_devs, + ARRAY_SIZE(om5pacv2_i2c_devs)); + + ath79_register_m25p80(&om5pacv2_flash_data); + ath79_register_leds_gpio(-1, ARRAY_SIZE(om5pacv2_leds_gpio), + om5pacv2_leds_gpio); + ath79_register_gpio_keys_polled(-1, OM5PACV2_KEYS_POLL_INTERVAL, + ARRAY_SIZE(om5pacv2_gpio_keys), + om5pacv2_gpio_keys); + + ath79_init_mac(mac, art, 0x02); + ath79_register_wmac(art + OM5PACV2_WMAC_CALDATA_OFFSET, mac); + + om5p_acv2_setup_qca955x_eth_cfg(QCA955X_ETH_CFG_RGMII_EN, 2, 2, 0, 0); + ath79_register_mdio(0, 0x0); + ath79_register_mdio(1, 0x0); + + mdiobus_register_board_info(om5pacv2_an_mdio0_info, + ARRAY_SIZE(om5pacv2_an_mdio0_info)); + + ath79_init_mac(ath79_eth0_data.mac_addr, art, 0x00); + ath79_init_mac(ath79_eth1_data.mac_addr, art, 0x01); + + /* GMAC0 is connected to the PHY4 */ + ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_RGMII; + ath79_eth0_data.mii_bus_dev = &ath79_mdio0_device.dev; + ath79_eth0_data.phy_mask = BIT(4); + ath79_eth0_pll_data.pll_1000 = 0x82000101; + ath79_eth0_pll_data.pll_100 = 0x80000101; + ath79_eth0_pll_data.pll_10 = 0x80001313; + ath79_register_eth(0); + + /* GMAC1 is connected to MDIO1 in SGMII mode */ + ath79_eth1_data.phy_if_mode = PHY_INTERFACE_MODE_SGMII; + ath79_eth1_data.mii_bus_dev = &ath79_mdio1_device.dev; + ath79_eth1_data.phy_mask = BIT(1); + ath79_eth1_pll_data.pll_1000 = 0x03000101; + ath79_eth1_pll_data.pll_100 = 0x80000101; + ath79_eth1_pll_data.pll_10 = 0x80001313; + ath79_eth1_data.speed = SPEED_1000; + ath79_eth1_data.duplex = DUPLEX_FULL; + ath79_register_eth(1); + + ath79_register_pci(); +} + +MIPS_MACHINE(ATH79_MACH_OM5P_ACv2, "OM5P-ACv2", "OpenMesh OM5P ACv2", om5p_acv2_setup); diff --git a/target/linux/ar71xx/patches-3.18/816-MIPS-ath79-add-om5pacv-support.patch b/target/linux/ar71xx/patches-3.18/816-MIPS-ath79-add-om5pacv-support.patch new file mode 100644 index 0000000..fbbf171 --- /dev/null +++ b/target/linux/ar71xx/patches-3.18/816-MIPS-ath79-add-om5pacv-support.patch @@ -0,0 +1,39 @@ +--- a/arch/mips/ath79/Kconfig ++++ b/arch/mips/ath79/Kconfig +@@ -808,6 +808,16 @@ config ATH79_MACH_OM5P_AC + select ATH79_DEV_M25P80 + select ATH79_DEV_WMAC + ++config ATH79_MACH_OM5P_ACv2 ++ bool "OpenMesh OM5P-ACv2 board support" ++ select SOC_QCA955X ++ select ATH79_DEV_AP9X_PCI if PCI ++ select ATH79_DEV_ETH ++ select ATH79_DEV_GPIO_BUTTONS ++ select ATH79_DEV_LEDS_GPIO ++ select ATH79_DEV_M25P80 ++ select ATH79_DEV_WMAC ++ + config ATH79_MACH_ONION_OMEGA + bool "ONION OMEGA support" + select SOC_AR933X +--- a/arch/mips/ath79/Makefile ++++ b/arch/mips/ath79/Makefile +@@ -101,6 +101,7 @@ obj-$(CONFIG_ATH79_MACH_NBG460N) += mach + obj-$(CONFIG_ATH79_MACH_OM2P) += mach-om2p.o + obj-$(CONFIG_ATH79_MACH_OM5P) += mach-om5p.o + obj-$(CONFIG_ATH79_MACH_OM5P_AC) += mach-om5pac.o ++obj-$(CONFIG_ATH79_MACH_OM5P_ACv2) += mach-om5pacv2.o + obj-$(CONFIG_ATH79_MACH_ONION_OMEGA) += mach-onion-omega.o + obj-$(CONFIG_ATH79_MACH_PB42) += mach-pb42.o + obj-$(CONFIG_ATH79_MACH_PB44) += mach-pb44.o +--- a/arch/mips/ath79/machtypes.h ++++ b/arch/mips/ath79/machtypes.h +@@ -96,6 +96,7 @@ enum ath79_mach_type { + ATH79_MACH_OM2Pv2, /* OpenMesh OM2Pv2 */ + ATH79_MACH_OM2P, /* OpenMesh OM2P */ + ATH79_MACH_OM5P_AC, /* OpenMesh OM5P-AC */ ++ ATH79_MACH_OM5P_ACv2, /* OpenMesh OM5P-ACv2 */ + ATH79_MACH_OM5P_AN, /* OpenMesh OM5P-AN */ + ATH79_MACH_OM5P, /* OpenMesh OM5P */ + ATH79_MACH_ONION_OMEGA, /* ONION OMEGA */ -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Thu May 19 14:21:12 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Thu, 19 May 2016 20:21:12 +0200 Subject: [OpenWrt-Devel] [PATCH CC 29/34] ar71xx: add user-space support for the OpenMesh OM5P-ACv2 In-Reply-To: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463682077-19339-29-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann Backport of r49150 --- target/linux/ar71xx/base-files/etc/diag.sh | 3 ++- target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 +++ 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/target/linux/ar71xx/base-files/etc/diag.sh b/target/linux/ar71xx/base-files/etc/diag.sh index 7528620..631459f 100644 --- a/target/linux/ar71xx/base-files/etc/diag.sh +++ b/target/linux/ar71xx/base-files/etc/diag.sh @@ -178,7 +178,8 @@ get_status_led() { om5p-an) status_led="om5p:blue:power" ;; - om5p-ac) + om5p-ac | \ + om5p-acv2) status_led="om5pac:blue:power" ;; onion-omega) diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh b/target/linux/ar71xx/base-files/lib/ar71xx.sh index 9354057..92ee56d 100755 --- a/target/linux/ar71xx/base-files/lib/ar71xx.sh +++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh @@ -575,6 +575,9 @@ ar71xx_board_detect() { *"OM5P AC") name="om5p-ac" ;; + *"OM5P ACv2") + name="om5p-acv2" + ;; *"Onion Omega") name="onion-omega" ;; -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Thu May 19 14:21:13 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Thu, 19 May 2016 20:21:13 +0200 Subject: [OpenWrt-Devel] [PATCH CC 30/34] ar71xx: enable sysupgrade for the OpenMesh OM5P-ACv2 In-Reply-To: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463682077-19339-30-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann Backport of r49151 --- target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh | 1 + target/linux/ar71xx/base-files/lib/upgrade/platform.sh | 6 ++++-- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh b/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh index 1cfead9..209cdaa 100644 --- a/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh +++ b/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh @@ -74,6 +74,7 @@ platform_check_image_openmesh() ;; OM5PAC) [ "$board" = "om5p-ac" ] && break + [ "$board" = "om5p-acv2" ] && break echo "Invalid image board target ($img_board_target) for this platform: $board. Use the correct image for this platform" return 1 ;; diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh index eb5c01e..d3e8a79 100755 --- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh +++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh @@ -302,7 +302,8 @@ platform_check_image() { om2p-lc | \ om5p | \ om5p-an | \ - om5p-ac) + om5p-ac | \ + om5p-acv2) platform_check_image_openmesh "$magic_long" "$1" && return 0 return 1 ;; @@ -532,7 +533,8 @@ platform_do_upgrade() { om2p-lc | \ om5p | \ om5p-an | \ - om5p-ac) + om5p-ac | \ + om5p-acv2) platform_do_upgrade_openmesh "$ARGV" ;; unifi-outdoor-plus | \ -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Thu May 19 14:21:14 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Thu, 19 May 2016 20:21:14 +0200 Subject: [OpenWrt-Devel] [PATCH CC 31/34] om-watchdog: add OpenMesh OM5P-ACv2 support In-Reply-To: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463682077-19339-31-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann Backport of r49152 --- package/kernel/om-watchdog/files/om-watchdog.init | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/kernel/om-watchdog/files/om-watchdog.init b/package/kernel/om-watchdog/files/om-watchdog.init index 8cec13b..6b96966 100644 --- a/package/kernel/om-watchdog/files/om-watchdog.init +++ b/package/kernel/om-watchdog/files/om-watchdog.init @@ -13,7 +13,7 @@ boot() { local board=$(ar71xx_board_name) case "$board" in - "om2p"|"om2p-hs"|"om2p-hsv2") + "om2p"|"om2p-hs"|"om2p-hsv2"|"om5p-acv2") service_start /sbin/om-watchdog 12 ;; "om2pv2"|"om2p-lc") -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Thu May 19 14:21:15 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Thu, 19 May 2016 20:21:15 +0200 Subject: [OpenWrt-Devel] [PATCH CC 32/34] uboot-envtools: add OpenMesh OM5P-ACv2 support In-Reply-To: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463682077-19339-32-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann Backport of r49153 --- package/boot/uboot-envtools/files/ar71xx | 1 + 1 file changed, 1 insertion(+) diff --git a/package/boot/uboot-envtools/files/ar71xx b/package/boot/uboot-envtools/files/ar71xx index 657b25f..9071c11 100644 --- a/package/boot/uboot-envtools/files/ar71xx +++ b/package/boot/uboot-envtools/files/ar71xx @@ -29,6 +29,7 @@ mr900v2 | \ nbg6716 | \ om5p-an | \ om5p-ac | \ +om5p-acv2 | \ om5p | \ tube2h | \ wndr3700) -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Thu May 19 14:21:16 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Thu, 19 May 2016 20:21:16 +0200 Subject: [OpenWrt-Devel] [PATCH CC 33/34] ar71xx: extract ath10k wifi board.bin for the OpenMesh OM5P-ACv2 board In-Reply-To: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463682077-19339-33-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann Backport of r49154 --- .../linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata index 1b6de1e..8fc3ab3 100644 --- a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata +++ b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata @@ -71,7 +71,8 @@ case "$FIRMWARE" in ath10kcal_extract "caldata" 20480 2116 ath10kcal_patch_mac $(macaddr_add $(cat /sys/class/net/eth0/address) +1) ;; - mr1750) + mr1750 | \ + om5p-acv2) ath10kcal_extract "ART" 20480 2116 ath10kcal_patch_mac $(macaddr_add $(cat /sys/class/net/eth0/address) +16) ;; -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Thu May 19 14:21:17 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Thu, 19 May 2016 20:21:17 +0200 Subject: [OpenWrt-Devel] [PATCH CC 34/34] ar71xx: add OM5P-ACv2 to the OM5P-AC profile In-Reply-To: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463682077-19339-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463682077-19339-34-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann Backport of r49155 --- target/linux/ar71xx/generic/profiles/openmesh.mk | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/target/linux/ar71xx/generic/profiles/openmesh.mk b/target/linux/ar71xx/generic/profiles/openmesh.mk index 64aaa24..c0919ed 100644 --- a/target/linux/ar71xx/generic/profiles/openmesh.mk +++ b/target/linux/ar71xx/generic/profiles/openmesh.mk @@ -28,12 +28,12 @@ endef $(eval $(call Profile,OM5P)) define Profile/OM5PAC - NAME:=OpenMesh OM5P-AC + NAME:=OpenMesh OM5P-AC/OM5P-ACv2 PACKAGES:=kmod-ath9k kmod-ath10k om-watchdog ath10k-firmware-qca988x endef define Profile/OM5PAC/Description - Package set optimized for the OpenMesh OM5P-AC. + Package set optimized for the OpenMesh OM5P-AC/OM5P-ACv2. endef $(eval $(call Profile,OM5PAC)) -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From andreas.schlager at sbg.at Thu May 19 14:57:15 2016 From: andreas.schlager at sbg.at (Andreas Schlager) Date: Thu, 19 May 2016 20:57:15 +0200 Subject: [OpenWrt-Devel] [solved] Linksys E1700 firmware upload throws "incorrect Firmware" In-Reply-To: <573CC961.4090503@sbg.at> References: <573CC961.4090503@sbg.at> Message-ID: <573E0C8B.8070807@sbg.at> Hi List, finally I managed to flash the OpenWRT firmware to the Linksys E1700 router. The problem is, that starting with Linksys firmware revision 1.0.01 and above the firmware upgrade process aborts with "incorrect Firmware" when trying to upload the OpenWRT firmware. I googled around and finally got a hit in a dd-wrt thread (https://www.dd-wrt.com/phpBB2/viewtopic.php?t=277324&postdays=0&postorder=asc&start=30) So I downloaded the initial Linksys FW version 1.0.00 (get FW_E1700_v1.0.00.081_20131220.bin at https://db.tt/m95cTvHq) and downgraded the E1700 from FW 1.0.02 (which my device was shipped) to 1.0.00. Then it accepted the OpenWRT firmware without troubles. Many thanks to you all for this exciting piece of software! Kind regards, -Andreas. --------------------------------------------------------- "Sed quis custodiet ipsos custodes?" (Wer, au?er den W?chtern selbst, wacht ?ber die W?chter?) --Juvenal. Am 2016-05-18 um 21:58 schrieb Andreas Schlager: > Dear list members, > > I'm coming to you with an installation problem on my brand new Linksys > E1700 devices, but I think this is the right forum for this. Also > because the WIKI entries for the E1700 router tells to report a working > device - which unfortunately is not the case... > > I tried it with uploading the OpenWRT firmware via the origina Linksys > Web-Interface, but after 15% it states "Incorrect Firmware". Only an OK > button, no ignore or something else. > > Then I fiddled around with tftp/tftpd, but it seems that this device > doesn't send tftp requests when booting, nor when reset-button is > pressed. Also an upload via tftp to the device failed. > The device still is useable, the stock firmware works. Additionally I > tried to upload the original Linksys FW, what worked. > > This is the image I tried: > https://downloads.openwrt.org/snapshots/trunk/ramips/mt7620/openwrt-ramips-mt7620-e1700-squashfs-factory.bin > > Any ideas highly appreciated.... > Many thanks in advance! > > -Andreas. > > > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From ben at gowasabi.net Thu May 19 15:06:10 2016 From: ben at gowasabi.net (Ben West) Date: Thu, 19 May 2016 14:06:10 -0500 Subject: [OpenWrt-Devel] [solved] Linksys E1700 firmware upload throws "incorrect Firmware" In-Reply-To: <573E0C8B.8070807@sbg.at> References: <573CC961.4090503@sbg.at> <573E0C8B.8070807@sbg.at> Message-ID: Yep, newer stock firmwares now frequently include locks against flashing 3rd party firmware. A common approach thus far, as you found, is indeed to downgrade to the stock firmware to an older version, but I understand that option also is being gradually trimmed away on newly sold products. On Thu, May 19, 2016 at 1:57 PM, Andreas Schlager wrote: > Hi List, > > finally I managed to flash the OpenWRT firmware to the Linksys E1700 > router. > The problem is, that starting with Linksys firmware revision 1.0.01 and > above the firmware upgrade process aborts with "incorrect Firmware" when > trying to upload the OpenWRT firmware. > > I googled around and finally got a hit in a dd-wrt thread ( > https://www.dd-wrt.com/phpBB2/viewtopic.php?t=277324&postdays=0&postorder=asc&start=30 > ) > > So I downloaded the initial Linksys FW version 1.0.00 (get > FW_E1700_v1.0.00.081_20131220.bin at https://db.tt/m95cTvHq) and > downgraded the E1700 from FW 1.0.02 (which my device was shipped) to 1.0.00. > > Then it accepted the OpenWRT firmware without troubles. > > Many thanks to you all for this exciting piece of software! > > Kind regards, > > -Andreas. > > --------------------------------------------------------- > "Sed quis custodiet ipsos custodes?" > (Wer, au?er den W?chtern selbst, wacht ?ber die W?chter?) > --Juvenal. > > Am 2016-05-18 um 21:58 schrieb Andreas Schlager: > > Dear list members, > > I'm coming to you with an installation problem on my brand new Linksys > E1700 devices, but I think this is the right forum for this. Also > because the WIKI entries for the E1700 router tells to report a working > device - which unfortunately is not the case... > > I tried it with uploading the OpenWRT firmware via the origina Linksys > Web-Interface, but after 15% it states "Incorrect Firmware". Only an OK > button, no ignore or something else. > > Then I fiddled around with tftp/tftpd, but it seems that this device > doesn't send tftp requests when booting, nor when reset-button is > pressed. Also an upload via tftp to the device failed. > The device still is useable, the stock firmware works. Additionally I > tried to upload the original Linksys FW, what worked. > > This is the image I tried:https://downloads.openwrt.org/snapshots/trunk/ramips/mt7620/openwrt-ramips-mt7620-e1700-squashfs-factory.bin > > Any ideas highly appreciated.... > Many thanks in advance! > > -Andreas. > > > > > _______________________________________________ > openwrt-devel mailing listopenwrt-devel at lists.openwrt.orghttps://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > > > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > > -- Ben West ben at gowasabi.net -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From oswald.buddenhagen at gmx.de Thu May 19 16:37:31 2016 From: oswald.buddenhagen at gmx.de (Oswald Buddenhagen) Date: Thu, 19 May 2016 22:37:31 +0200 Subject: [OpenWrt-Devel] [PATCH v2] lantiq: add support for ARV7506PW11 (Alice/O2 IAD 4421) In-Reply-To: <1463557077-19088-1-git-send-email-oswald.buddenhagen@gmx.de> References: <1463557077-19088-1-git-send-email-oswald.buddenhagen@gmx.de> Message-ID: <20160519203731.24752-1-oswald.buddenhagen@gmx.de> Ethernet, WiFi, ADSL2+, and LEDs are fully functional. Supporting the two TAE ports and SIP gateway was not attempted. The firmware image needs to be kept below ~3.6MiB due to brnboot's dual image magic. This is just enough for the above configuration plus dropbear. Luci and other non-critical packages must be installed into the jffs2 once the device has booted. U-boot support was not attempted. Signed-off-by: Oswald Buddenhagen --- .../linux/lantiq/base-files/etc/board.d/02_network | 8 + .../etc/hotplug.d/firmware/10-rt2x00-eeprom | 2 +- target/linux/lantiq/dts/ARV7506PW11.dts | 213 +++++++++++++++++++++ target/linux/lantiq/image/Makefile | 2 + target/linux/lantiq/xway/profiles/arv.mk | 12 ++ 5 files changed, 236 insertions(+), 1 deletion(-) create mode 100644 target/linux/lantiq/dts/ARV7506PW11.dts diff --git a/target/linux/lantiq/base-files/etc/board.d/02_network b/target/linux/lantiq/base-files/etc/board.d/02_network index b27b802..1f06c26 100755 --- a/target/linux/lantiq/base-files/etc/board.d/02_network +++ b/target/linux/lantiq/base-files/etc/board.d/02_network @@ -39,6 +39,14 @@ ACMP252|GIGASX76X) "4:lan:1" "3:lan:2" "2:lan:3" "1:lan:4" "5t at eth0" ;; +# rtl8306g +ARV7506PW11) + lan_mac=$(mtd_get_mac_binary board_config 22) + wan_mac=$(macaddr_add "$lan_mac" 1) + ucidef_add_switch "switch0" \ + "4:lan:1" "3:lan:2" "2:lan:3" "1:lan:4" "5t at eth0" + ;; + # ar8316 ARV4519PW|ARV7510PW22|ARV7518PW|ARV752DPW22|ARV8539PW22) ucidef_add_switch "switch0" \ diff --git a/target/linux/lantiq/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom b/target/linux/lantiq/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom index 5f1cb00..da10797 100644 --- a/target/linux/lantiq/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom +++ b/target/linux/lantiq/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom @@ -35,7 +35,7 @@ case "$FIRMWARE" in "RT2860.eeprom" ) local board=$(lantiq_board_name) case $board in - ARV7510PW22|ARV7519PW|ARV752DPW|ARV752DPW22|VGV7519) + ARV7506PW11|ARV7510PW22|ARV7519PW|ARV752DPW|ARV752DPW22|VGV7519) rt2x00_eeprom_extract "board_config" 520 256 1 ;; ARV7525PW) diff --git a/target/linux/lantiq/dts/ARV7506PW11.dts b/target/linux/lantiq/dts/ARV7506PW11.dts new file mode 100644 index 0000000..1c38c88 --- /dev/null +++ b/target/linux/lantiq/dts/ARV7506PW11.dts @@ -0,0 +1,213 @@ +/dts-v1/; + +/include/ "danube.dtsi" + +/ { + model = "ARV7506PW11 - Alice/O2 IAD 4421"; + + chosen { + leds { + boot = &power; + failsafe = &power_red; + running = &power; + + dsl = &dsl; + internet = &internet; + wifi = &wlan; + }; + }; + + memory at 0 { + reg = <0x0 0x4000000>; + }; + + sram at 1F000000 { + vmmc at 107000 { + status = "okay"; + gpios = <&gpiomm 1 0>; + }; + }; + + fpi at 10000000 { + localbus at 0 { + nor-boot at 0 { + compatible = "lantiq,nor"; + bank-width = <2>; + reg = <0 0x0 0x800000>; + + partitions { + compatible = "fixed-partitions"; + #address-cells = <1>; + #size-cells = <1>; + + partition at 0 { + label = "brnboot"; + reg = <0x00000 0x20000>; + read-only; + }; + + partition at 20000 { + label = "stuff"; + reg = <0x20000 0x70000>; + }; + + partition at 90000 { + label = "rootfs_data"; + reg = <0x90000 0x3B0000>; + }; + + partition at 440000 { + label = "firmware"; + reg = <0x440000 0x3B0000>; + }; + + partition at 7f0000 { + label = "board_config"; + reg = <0x7f0000 0x10000>; + read-only; + }; + }; + }; + + mac_addr { + compatible = "lantiq,eth-mac"; + reg = <0 0x7f0016 0x6>; + mac-increment = <2>; + }; + + gpiomm: gpiomm at 4000000 { + compatible = "lantiq,gpio-mm"; + reg = <1 0x0 0x10 >; + #address-cells = <1>; + #size-cells = <1>; + #gpio-cells = <2>; + gpio-controller; + lantiq,shadow = <0x3>; + }; + }; + + gpio: pinmux at E100B10 { + pinctrl-names = "default"; + pinctrl-0 = <&state_default>; + + state_default: pinmux { + ebu { + lantiq,groups = "ebu cs1"; + lantiq,function = "ebu"; + }; + exin { + lantiq,groups = "exin1"; + lantiq,function = "exin"; + }; + pci_in { + lantiq,groups = "req2", "req1"; + lantiq,function = "pci"; + lantiq,pull = <2>; + lantiq,output = <0>; + }; + pci_out { + lantiq,groups = "gnt1"; + lantiq,function = "pci"; + lantiq,output = <1>; + }; + pci_rst { + lantiq,pins = "io21"; + lantiq,pull = <2>; + lantiq,output = <1>; + }; + switch_rst { + lantiq,pins = "io19"; + }; + leds { + lantiq,pins = "io2", "io3", "io4", "io5", "io6", "io7", "io8", "io9", "io20"; + lantiq,output = <1>; + lantiq,pull = <0>; + }; + keys { + lantiq,pins = "io11", "io30"; + lantiq,output = <0>; + lantiq,pull = <2>; + }; + }; + }; + + ifxhcd at E101000 { + status = "okay"; + gpios = <&gpiomm 0 0>; + }; + + etop at E180000 { + phy-mode = "rmii"; + }; + + pci at E105400 { + status = "okay"; + gpio-reset = <&gpio 21 0>; + }; + + }; + + ralink_eep { + compatible = "ralink,eeprom"; + ralink,eeprom = "RT2860.eeprom"; + }; + + gpio-keys-polled { + compatible = "gpio-keys-polled"; + #address-cells = <1>; + #size-cells = <0>; + poll-interval = <100>; + + rfkill { + /* The button is labeled WLAN/WPS. The former seems more useful. */ + label = "rfkill"; + gpios = <&gpio 11 1>; + linux,code = <0xf7>; + }; + reset { + label = "reset"; + gpios = <&gpio 30 1>; + linux,code = <0x198>; + }; + }; + + gpio-leds { + compatible = "gpio-leds"; + wlan: wlan { + label = "arv7506pw11:green:wlan"; + gpios = <&gpio 2 1>; + }; + power: power { + label = "arv7506pw11:green:power"; + gpios = <&gpio 3 1>; + }; + dsl: dsl { + label = "arv7506pw11:green:dsl"; + gpios = <&gpio 4 1>; + }; + internet: internet { + label = "arv7506pw11:green:internet"; + gpios = <&gpio 5 1>; + }; + power_red: power_red { + label = "arv7506pw11:red:power"; + gpios = <&gpio 6 1>; + }; + internet_red { + label = "arv7506pw11:red:internet"; + gpios = <&gpio 7 1>; + }; + info { + label = "arv7506pw11:green:info"; + gpios = <&gpio 8 1>; + }; + telefon { + label = "arv7506pw11:green:telefon"; + gpios = <&gpio 9 1>; + }; + info_red { + label = "arv7506pw11:red:info"; + gpios = <&gpio 20 1>; + }; + }; +}; diff --git a/target/linux/lantiq/image/Makefile b/target/linux/lantiq/image/Makefile index bc74e4f..7a5a564 100644 --- a/target/linux/lantiq/image/Makefile +++ b/target/linux/lantiq/image/Makefile @@ -352,6 +352,8 @@ ifeq ($(CONFIG_TARGET_lantiq_xway),y) Image/BuildKernel/Profile/BTHOMEHUBV2B=$(call Image/BuildKernel/Template,BTHOMEHUBV2B) Image/Build/Profile/BTHOMEHUBV2B=$(call Image/BuildNAND/$(1),$(1),BTHOMEHUBV2B) +$(eval $(call lantiqBrnImage,ARV7506PW11,BRNDA4421,0x7AB7ADAD,0x2083b8ed)) + $(eval $(call lantiqImage,EASY50712)) $(eval $(call lantiqImage,ACMP252)) $(eval $(call lantiqImage,ARV4510PW)) diff --git a/target/linux/lantiq/xway/profiles/arv.mk b/target/linux/lantiq/xway/profiles/arv.mk index 976cd19..e20e403 100644 --- a/target/linux/lantiq/xway/profiles/arv.mk +++ b/target/linux/lantiq/xway/profiles/arv.mk @@ -78,6 +78,18 @@ endef $(eval $(call Profile,ARV4519PW)) +define Profile/ARV7506PW11 + NAME:=Alice/O2 IAD 4421 - ARV7506PW11 + PACKAGES:= \ + kmod-ltq-adsl-danube-mei kmod-ltq-adsl-danube \ + kmod-ltq-adsl-danube-fw-b kmod-ltq-atm-danube \ + ltq-adsl-app ppp-mod-pppoa \ + kmod-rt2800-pci wpad-mini \ + swconfig +endef + +$(eval $(call Profile,ARV7506PW11)) + define Profile/ARV7510PW22 NAME:=Astoria - ARV7510PW22 PACKAGES:=kmod-ltq-hcd-danube kmod-ledtrig-usbdev \ -- 2.8.3.1.g1cc7b6a _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From dedeckeh at gmail.com Thu May 19 16:40:10 2016 From: dedeckeh at gmail.com (Hans Dedecker) Date: Thu, 19 May 2016 22:40:10 +0200 Subject: [OpenWrt-Devel] [LEDE-DEV] [PATCH] busybox: sysntpd - Support for NTP servers received via DHCP(v6) In-Reply-To: References: <1463677071-17121-1-git-send-email-dedeckeh@gmail.com> Message-ID: Hi Jo, On Thu, May 19, 2016 at 7:04 PM, Jo-Philipp Wich wrote: > Hi Hans, > > staged into https://git.lede-project.org/?p=lede/jow/staging.git > > A few improvement ideas though; > > - maybe we can make the jsonfilter dependency conditionally depending > on the ntpd applet > - maybe pipe the ubus interface status dump directly to jsonfilter > - is there any reason to not make "use_dhcp" the default? I wanted to preserve the ntp server behavior and only change the behavior when configured in order to keep backwards compatibility. You favour enabling DHCP ntp server config without explicit config ? Regarding the improvements do you want me to send a patch containing the diff with the already staged commit or do you prefer a v2 patch ? Hans > > ~ Jo > > On 05/19/2016 06:57 PM, Hans Dedecker wrote: >> The busybox ntpd utility currently uses ntp servers specified in uci. >> This patch allows the ntpd utility to use NTP servers received via DHCP(v6) >> Following uci parameters have been added: >> use_dhcp : enables NTP server config via DHCP(v6) >> dhcp_interface : use NTP servers received only on the specified DHCP(v6) interfaces; if empty all interfaces are considered >> >> Signed-off-by: Hans Dedecker >> --- >> >> The patch is based on a previous discussion held on the OpenWRT-devel mailing list >> (https://lists.openwrt.org/pipermail/openwrt-devel/2016-January/039081.html) as per Felix's >> comments this solution is based on procd interface service triggers >> >> package/utils/busybox/Makefile | 2 +- >> package/utils/busybox/files/sysntpd | 43 ++++++++++++++++++++++++++++++++----- >> 2 files changed, 39 insertions(+), 6 deletions(-) >> >> diff --git a/package/utils/busybox/Makefile b/package/utils/busybox/Makefile >> index 24c064c..24e0e11 100644 >> --- a/package/utils/busybox/Makefile >> +++ b/package/utils/busybox/Makefile >> @@ -42,7 +42,7 @@ define Package/busybox >> MAINTAINER:=Felix Fietkau >> TITLE:=Core utilities for embedded Linux >> URL:=http://busybox.net/ >> - DEPENDS:=+BUSYBOX_USE_LIBRPC:librpc +BUSYBOX_CONFIG_PAM:libpam >> + DEPENDS:=+BUSYBOX_USE_LIBRPC:librpc +BUSYBOX_CONFIG_PAM:libpam +jsonfilter >> MENU:=1 >> endef >> >> diff --git a/package/utils/busybox/files/sysntpd b/package/utils/busybox/files/sysntpd >> index f73bb83..5c663d7 100755 >> --- a/package/utils/busybox/files/sysntpd >> +++ b/package/utils/busybox/files/sysntpd >> @@ -7,13 +7,35 @@ USE_PROCD=1 >> PROG=/usr/sbin/ntpd >> HOTPLUG_SCRIPT=/usr/sbin/ntpd-hotplug >> >> +get_dhcp_ntp_servers() { >> + local interfaces="$1" >> + local filter="*" >> + local network_dump interface ntpservers ntpserver >> + >> + network_dump=$(ubus call network.interface dump) >> + for interface in $interfaces; do >> + [ "$filter" = "*" ] && filter="@.interface='$interface'" || filter="$filter, at .interface='$interface'" >> + done >> + >> + ntpservers=$(jsonfilter -s "$network_dump" -e "@.interface[$filter]['data']['ntpserver']") >> + >> + for ntpserver in $ntpservers; do >> + local duplicate=0 >> + local entry >> + for entry in $server; do >> + [ "$ntpserver" = "$entry" ] && duplicate=1 >> + done >> + [ "$duplicate" = 0 ] && server="$server $ntpserver" >> + done >> +} >> + >> validate_ntp_section() { >> uci_validate_section system timeserver "${1}" \ >> - 'server:list(host)' 'enabled:bool:1' 'enable_server:bool:0' >> + 'server:list(host)' 'enabled:bool:1' 'enable_server:bool:0' 'use_dhcp:bool:0' 'dhcp_interface:list(string)' >> } >> >> start_service() { >> - local server enabled enable_server peer >> + local server enabled enable_server use_dhcp dhcp_interface peer >> >> validate_ntp_section ntp || { >> echo "validation failed" >> @@ -22,6 +44,8 @@ start_service() { >> >> [ $enabled = 0 ] && return >> >> + [ $use_dhcp = 1 ] && get_dhcp_ntp_servers "$dhcp_interface" >> + >> [ -z "$server" ] && return >> >> procd_open_instance >> @@ -35,8 +59,17 @@ start_service() { >> procd_close_instance >> } >> >> -service_triggers() >> -{ >> - procd_add_reload_trigger "system" >> +service_triggers() { >> + local script name >> + >> + script=$(readlink -f "$initscript") >> + name=$(basename ${script:-$initscript}) >> + >> + procd_open_trigger >> + procd_add_config_trigger "config.change" "system" /etc/init.d/$name reload >> + >> + procd_add_raw_trigger "interface.*" 2000 /etc/init.d/$name reload >> + procd_close_trigger >> + >> procd_add_validation validate_ntp_section >> } >> > _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From oswald.buddenhagen at gmx.de Thu May 19 17:04:06 2016 From: oswald.buddenhagen at gmx.de (Oswald Buddenhagen) Date: Thu, 19 May 2016 23:04:06 +0200 Subject: [OpenWrt-Devel] [PATCH] lantiq: add support for ARV7506PW11 (Alice/O2 IAD 4421) In-Reply-To: References: <1463557077-19088-1-git-send-email-oswald.buddenhagen@gmx.de> <20160518210009.GA22531@ugly.lan> Message-ID: <20160519210406.GA31062@ugly.lan> On Thu, May 19, 2016 at 06:19:35PM +0200, Mathias Kresin wrote: > I found the pins to enter UART boot mode. Apply 3,3V to the right side > of R65 and GND to the right side of R80. > :) > R80 is partially hidden under the heatsink of the SoC. > not in my case - clearly, the glueing of the heatsinks isn't exactly precision work. in fact, only the crystal next to the ram stopped the sink from sliding off entirely. :D > 2016-05-18 23:00 GMT+02:00 Oswald Buddenhagen : > > i'll do that if you don't beat me to it (which you can easily do if you > > plan to seriously work on this - beyond email, this is a limited weekend > > project for me). > > From zero to working image in just a weekend. That is indeed amazing. > well, i didn't say *one* weekend. ;) i spent easily 50 hours on that project, though probably i could have pulled it off in 5 hours if i had known what i'm doing. now i know more about wifi drivers, pci busses and devicetrees than i ever wanted or needed to. :D but i really didn't start from zero - the dts at https://wiki.openwrt.org/toh/arcadyan/arv7506 is almost complete, even if broken in a most sinister way. ^^ > > i think i also know why rfkill doesn't work: i forgot to change the > > keycode when i decided to switch the key's usage from wps to rfkill. > > (facepalm) > > That's something where I've a lack of knowledge. Where does the > keycodes come from? > it's in the devicetree. i sent an updated patch. it's not tested, though. > In the meantime I've added support for this board to u-boot, switched > from brnboot to uImage and to a custom partitions layout with a > firmware partition of 8128 KByte. Means, your image shrinking patches > aren't required any more. > cool. > I haven't had a closer look to the OpenWrt image, but what I've > noticed so far, is a not lit up WLAN led when the wireless is enabled. > Does it work for you? > not out of the box, iirc. i configured it to netdev/wlan0/link+tx+rx, which works fine. this shouldn't be necessary, so a board case should be probably added to /target/linux/lantiq/base-files/etc/board.d/01_leds. just amend my patch and add a footer mentioning your co-authorship. > Do you plan to work further on this patch or do you consider your > weekend project as finished. > i'll happily hand it off at this point. _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From wong.syrone at gmail.com Thu May 19 20:55:13 2016 From: wong.syrone at gmail.com (Syrone Wong) Date: Fri, 20 May 2016 08:55:13 +0800 Subject: [OpenWrt-Devel] iptables 1.6 Message-ID: Hi everyone, I notice someone is trying to get iptables 1.6 working. I disabled nftables compatible layer and added two new modules into the corresponding patch[0]. Please note that there may be something wrong when building with dnsmasq-full which enables conntrack support these days[1] [0]:https://github.com/wongsyrone/lede-1/commit/315c6f30ab6879b17d251b5c2b04214b54bbf60f and https://github.com/wongsyrone/lede-1/commit/59a481fe6ae598afdc3b3706d708a121feefd190 [1]:https://github.com/openwrt-mirror/openwrt/commit/7dbc22a8a28ce2baa019f63323e83eefe10944f9 -- Best Regards, Syrone Wong _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From alin.nastac at gmail.com Fri May 20 03:42:08 2016 From: alin.nastac at gmail.com (=?UTF-8?B?QWxpbiBOxINzdGFj?=) Date: Fri, 20 May 2016 09:42:08 +0200 Subject: [OpenWrt-Devel] [LEDE-DEV] [PATCH] conntrack: enable support for netfilter conntrack zones In-Reply-To: References: <1463644446-4279-1-git-send-email-alin.nastac@gmail.com> Message-ID: Hi Jo, You have my ACK. ;) Sorry about that, I will sign my patches from now on. BR, Alin On Thu, May 19, 2016 at 6:21 PM, Jo-Philipp Wich wrote: > Hi Alin, > > I merged your patch into my staging tree at > > https://git.lede-project.org/?p=lede/jow/staging.git;a=commitdiff;h=6c9231baa9c5341c6ee2e213618dcde72d42288b > > Since your change lacked a proper Signed-off-by I added it on your > behalf. Please review the link above and give me your ACK, then I'll > push it to master after some compile testing. > > Regards, > Jo > > On 05/19/2016 09:54 AM, Alin Nastac wrote: >> Storage of such zones is provided by a nf_ct_ext struct, hence conntrack >> memory foot print will not be increased if zones are not used. >> --- >> package/kernel/linux/modules/netfilter.mk | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/package/kernel/linux/modules/netfilter.mk b/package/kernel/linux/modules/netfilter.mk >> index 3b623e4..4d9c116 100644 >> --- a/package/kernel/linux/modules/netfilter.mk >> +++ b/package/kernel/linux/modules/netfilter.mk >> @@ -68,6 +68,7 @@ define KernelPackage/nf-conntrack >> KCONFIG:= \ >> CONFIG_NETFILTER=y \ >> CONFIG_NETFILTER_ADVANCED=y \ >> + CONFIG_NF_CONNTRACK_ZONES=y \ >> $(KCONFIG_NF_CONNTRACK) >> FILES:=$(foreach mod,$(NF_CONNTRACK-m),$(LINUX_DIR)/net/$(mod).ko) >> AUTOLOAD:=$(call AutoProbe,$(notdir $(NF_CONNTRACK-m))) >> > _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From jo at mein.io Fri May 20 05:01:39 2016 From: jo at mein.io (Jo-Philipp Wich) Date: Fri, 20 May 2016 11:01:39 +0200 Subject: [OpenWrt-Devel] [LEDE-DEV] [PATCH] busybox: sysntpd - Support for NTP servers received via DHCP(v6) In-Reply-To: References: <1463677071-17121-1-git-send-email-dedeckeh@gmail.com> Message-ID: <8c7974a7-5334-ee6d-3ba0-0bea69d3b159@mein.io> Hi Hans, > I wanted to preserve the ntp server behavior and only change the > behavior when configured in order to keep backwards compatibility. You > favour enabling DHCP ntp server config without explicit config ? Personally I do because thats likely what most users expect, but then trusting foreign NTP server advertisements might be a security sensitive topic - on the other hand one trusts the default gateway and DNS advertisements too, so I don't know. > Regarding the improvements do you want me to send a patch containing > the diff with the already staged commit or do you prefer a v2 patch ? Whatever you prefer - I think a v2 is the easiest and I can just replace the commit in my tree. ~ Jo _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From amine.ahd at gmail.com Fri May 20 06:46:47 2016 From: amine.ahd at gmail.com (Amine Aouled Hamed) Date: Fri, 20 May 2016 12:46:47 +0200 Subject: [OpenWrt-Devel] [LEDE-DEV] [PATCH] busybox: sysntpd - Support for NTP servers received via DHCP(v6) In-Reply-To: <8c7974a7-5334-ee6d-3ba0-0bea69d3b159@mein.io> References: <1463677071-17121-1-git-send-email-dedeckeh@gmail.com> <8c7974a7-5334-ee6d-3ba0-0bea69d3b159@mein.io> Message-ID: Hi, One feature that was requested is the ability to specify a list of interfaces to get servers from. You can save the list as an option to the config file and add a trigger to only those interfaces. Regards, Amine. On Fri, May 20, 2016 at 11:01 AM, Jo-Philipp Wich wrote: > Hi Hans, > > > I wanted to preserve the ntp server behavior and only change the > > behavior when configured in order to keep backwards compatibility. You > > favour enabling DHCP ntp server config without explicit config ? > > Personally I do because thats likely what most users expect, but then > trusting foreign NTP server advertisements might be a security sensitive > topic - on the other hand one trusts the default gateway and DNS > advertisements too, so I don't know. > > > > Regarding the improvements do you want me to send a patch containing > > the diff with the already staged commit or do you prefer a v2 patch ? > > Whatever you prefer - I think a v2 is the easiest and I can just replace > the commit in my tree. > > ~ Jo > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > -- Amine Hamed | Software Engineer Ocedo GmbH | Hirschstrasse 7 | 76133 Karlsruhe | Germany Email ahamed at ocedo.com REGISTERED OFFICE: KARLSRUHE | DISTRICT COURT: MANNHEIM | REGISTER NUMBER: HRB 717873 MANAGING DIRECTOR: MARKUS HENNIG|JAN HICHERT -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From amine.ahd at gmail.com Fri May 20 06:49:00 2016 From: amine.ahd at gmail.com (Amine Aouled Hamed) Date: Fri, 20 May 2016 12:49:00 +0200 Subject: [OpenWrt-Devel] [PATCH] busybox: sysntpd - Support for NTP servers received via DHCP(v6) In-Reply-To: <1463677071-17121-1-git-send-email-dedeckeh@gmail.com> References: <1463677071-17121-1-git-send-email-dedeckeh@gmail.com> Message-ID: Hi, One feature that was requested is the ability to specify a list of interfaces to get servers from. You can save the list as an option to the config file and add a trigger to only those interfaces. Regards, Amine. On Thu, May 19, 2016 at 6:57 PM, Hans Dedecker wrote: > The busybox ntpd utility currently uses ntp servers specified in uci. > This patch allows the ntpd utility to use NTP servers received via DHCP(v6) > Following uci parameters have been added: > use_dhcp : enables NTP server config via DHCP(v6) > dhcp_interface : use NTP servers received only on the specified > DHCP(v6) interfaces; if empty all interfaces are considered > > Signed-off-by: Hans Dedecker > --- > > The patch is based on a previous discussion held on the OpenWRT-devel > mailing list > ( > https://lists.openwrt.org/pipermail/openwrt-devel/2016-January/039081.html) > as per Felix's > comments this solution is based on procd interface service triggers > > package/utils/busybox/Makefile | 2 +- > package/utils/busybox/files/sysntpd | 43 > ++++++++++++++++++++++++++++++++----- > 2 files changed, 39 insertions(+), 6 deletions(-) > > diff --git a/package/utils/busybox/Makefile > b/package/utils/busybox/Makefile > index 24c064c..24e0e11 100644 > --- a/package/utils/busybox/Makefile > +++ b/package/utils/busybox/Makefile > @@ -42,7 +42,7 @@ define Package/busybox > MAINTAINER:=Felix Fietkau > TITLE:=Core utilities for embedded Linux > URL:=http://busybox.net/ > - DEPENDS:=+BUSYBOX_USE_LIBRPC:librpc +BUSYBOX_CONFIG_PAM:libpam > + DEPENDS:=+BUSYBOX_USE_LIBRPC:librpc +BUSYBOX_CONFIG_PAM:libpam > +jsonfilter > MENU:=1 > endef > > diff --git a/package/utils/busybox/files/sysntpd > b/package/utils/busybox/files/sysntpd > index f73bb83..5c663d7 100755 > --- a/package/utils/busybox/files/sysntpd > +++ b/package/utils/busybox/files/sysntpd > @@ -7,13 +7,35 @@ USE_PROCD=1 > PROG=/usr/sbin/ntpd > HOTPLUG_SCRIPT=/usr/sbin/ntpd-hotplug > > +get_dhcp_ntp_servers() { > + local interfaces="$1" > + local filter="*" > + local network_dump interface ntpservers ntpserver > + > + network_dump=$(ubus call network.interface dump) > + for interface in $interfaces; do > + [ "$filter" = "*" ] && filter="@.interface='$interface'" > || filter="$filter, at .interface='$interface'" > + done > + > + ntpservers=$(jsonfilter -s "$network_dump" -e > "@.interface[$filter]['data']['ntpserver']") > + > + for ntpserver in $ntpservers; do > + local duplicate=0 > + local entry > + for entry in $server; do > + [ "$ntpserver" = "$entry" ] && duplicate=1 > + done > + [ "$duplicate" = 0 ] && server="$server $ntpserver" > + done > +} > + > validate_ntp_section() { > uci_validate_section system timeserver "${1}" \ > - 'server:list(host)' 'enabled:bool:1' 'enable_server:bool:0' > + 'server:list(host)' 'enabled:bool:1' > 'enable_server:bool:0' 'use_dhcp:bool:0' 'dhcp_interface:list(string)' > } > > start_service() { > - local server enabled enable_server peer > + local server enabled enable_server use_dhcp dhcp_interface peer > > validate_ntp_section ntp || { > echo "validation failed" > @@ -22,6 +44,8 @@ start_service() { > > [ $enabled = 0 ] && return > > + [ $use_dhcp = 1 ] && get_dhcp_ntp_servers "$dhcp_interface" > + > [ -z "$server" ] && return > > procd_open_instance > @@ -35,8 +59,17 @@ start_service() { > procd_close_instance > } > > -service_triggers() > -{ > - procd_add_reload_trigger "system" > +service_triggers() { > + local script name > + > + script=$(readlink -f "$initscript") > + name=$(basename ${script:-$initscript}) > + > + procd_open_trigger > + procd_add_config_trigger "config.change" "system" > /etc/init.d/$name reload > + > + procd_add_raw_trigger "interface.*" 2000 /etc/init.d/$name reload > + procd_close_trigger > + > procd_add_validation validate_ntp_section > } > -- > 1.9.1 > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From amine.ahd at gmail.com Fri May 20 08:59:26 2016 From: amine.ahd at gmail.com (Amine Aouled Hamed) Date: Fri, 20 May 2016 14:59:26 +0200 Subject: [OpenWrt-Devel] [PATCH] busybox: sysntpd - Support for NTP servers received via DHCP(v6) In-Reply-To: <1463677071-17121-1-git-send-email-dedeckeh@gmail.com> References: <1463677071-17121-1-git-send-email-dedeckeh@gmail.com> Message-ID: Hi, Please add raw triggers to only the interfaces specified in the list. Regards, Amine. On Thu, May 19, 2016 at 6:57 PM, Hans Dedecker wrote: > The busybox ntpd utility currently uses ntp servers specified in uci. > This patch allows the ntpd utility to use NTP servers received via DHCP(v6) > Following uci parameters have been added: > use_dhcp : enables NTP server config via DHCP(v6) > dhcp_interface : use NTP servers received only on the specified DHCP(v6) interfaces; if empty all interfaces are considered > > Signed-off-by: Hans Dedecker > --- > > The patch is based on a previous discussion held on the OpenWRT-devel mailing list > (https://lists.openwrt.org/pipermail/openwrt-devel/2016-January/039081.html) as per Felix's > comments this solution is based on procd interface service triggers > > package/utils/busybox/Makefile | 2 +- > package/utils/busybox/files/sysntpd | 43 ++++++++++++++++++++++++++++++++----- > 2 files changed, 39 insertions(+), 6 deletions(-) > > diff --git a/package/utils/busybox/Makefile b/package/utils/busybox/Makefile > index 24c064c..24e0e11 100644 > --- a/package/utils/busybox/Makefile > +++ b/package/utils/busybox/Makefile > @@ -42,7 +42,7 @@ define Package/busybox > MAINTAINER:=Felix Fietkau > TITLE:=Core utilities for embedded Linux > URL:=http://busybox.net/ > - DEPENDS:=+BUSYBOX_USE_LIBRPC:librpc +BUSYBOX_CONFIG_PAM:libpam > + DEPENDS:=+BUSYBOX_USE_LIBRPC:librpc +BUSYBOX_CONFIG_PAM:libpam +jsonfilter > MENU:=1 > endef > > diff --git a/package/utils/busybox/files/sysntpd b/package/utils/busybox/files/sysntpd > index f73bb83..5c663d7 100755 > --- a/package/utils/busybox/files/sysntpd > +++ b/package/utils/busybox/files/sysntpd > @@ -7,13 +7,35 @@ USE_PROCD=1 > PROG=/usr/sbin/ntpd > HOTPLUG_SCRIPT=/usr/sbin/ntpd-hotplug > > +get_dhcp_ntp_servers() { > + local interfaces="$1" > + local filter="*" > + local network_dump interface ntpservers ntpserver > + > + network_dump=$(ubus call network.interface dump) > + for interface in $interfaces; do > + [ "$filter" = "*" ] && filter="@.interface='$interface'" || filter="$filter, at .interface='$interface'" > + done > + > + ntpservers=$(jsonfilter -s "$network_dump" -e "@.interface[$filter]['data']['ntpserver']") > + > + for ntpserver in $ntpservers; do > + local duplicate=0 > + local entry > + for entry in $server; do > + [ "$ntpserver" = "$entry" ] && duplicate=1 > + done > + [ "$duplicate" = 0 ] && server="$server $ntpserver" > + done > +} > + > validate_ntp_section() { > uci_validate_section system timeserver "${1}" \ > - 'server:list(host)' 'enabled:bool:1' 'enable_server:bool:0' > + 'server:list(host)' 'enabled:bool:1' 'enable_server:bool:0' 'use_dhcp:bool:0' 'dhcp_interface:list(string)' > } > > start_service() { > - local server enabled enable_server peer > + local server enabled enable_server use_dhcp dhcp_interface peer > > validate_ntp_section ntp || { > echo "validation failed" > @@ -22,6 +44,8 @@ start_service() { > > [ $enabled = 0 ] && return > > + [ $use_dhcp = 1 ] && get_dhcp_ntp_servers "$dhcp_interface" > + > [ -z "$server" ] && return > > procd_open_instance > @@ -35,8 +59,17 @@ start_service() { > procd_close_instance > } > > -service_triggers() > -{ > - procd_add_reload_trigger "system" > +service_triggers() { > + local script name > + > + script=$(readlink -f "$initscript") > + name=$(basename ${script:-$initscript}) > + > + procd_open_trigger > + procd_add_config_trigger "config.change" "system" /etc/init.d/$name reload > + > + procd_add_raw_trigger "interface.*" 2000 /etc/init.d/$name reload > + procd_close_trigger > + > procd_add_validation validate_ntp_section > } > -- > 1.9.1 > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From david at lang.hm Fri May 20 09:18:57 2016 From: david at lang.hm (David Lang) Date: Fri, 20 May 2016 06:18:57 -0700 (PDT) Subject: [OpenWrt-Devel] [LEDE-DEV] [PATCH] busybox: sysntpd - Support for NTP servers received via DHCP(v6) In-Reply-To: <8c7974a7-5334-ee6d-3ba0-0bea69d3b159@mein.io> References: <1463677071-17121-1-git-send-email-dedeckeh@gmail.com> <8c7974a7-5334-ee6d-3ba0-0bea69d3b159@mein.io> Message-ID: On Fri, 20 May 2016, Jo-Philipp Wich wrote: > Hi Hans, > >> I wanted to preserve the ntp server behavior and only change the >> behavior when configured in order to keep backwards compatibility. You >> favour enabling DHCP ntp server config without explicit config ? > > Personally I do because thats likely what most users expect, but then > trusting foreign NTP server advertisements might be a security sensitive > topic - on the other hand one trusts the default gateway and DNS > advertisements too, so I don't know. NTP isn't signed. If I can control your DNS, I can probably control your NTP by giving you the wrong IP for the NTP server If I can control your gateway, I can redirect all your NTP queries to someone else (NAT, redirects, etc) so why not trust the NTP server being provided? David Lang _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From dedeckeh at gmail.com Fri May 20 09:43:21 2016 From: dedeckeh at gmail.com (Hans Dedecker) Date: Fri, 20 May 2016 15:43:21 +0200 Subject: [OpenWrt-Devel] [LEDE-DEV] [PATCH] busybox: sysntpd - Support for NTP servers received via DHCP(v6) In-Reply-To: References: <1463677071-17121-1-git-send-email-dedeckeh@gmail.com> <8c7974a7-5334-ee6d-3ba0-0bea69d3b159@mein.io> Message-ID: On Fri, May 20, 2016 at 3:18 PM, David Lang wrote: > On Fri, 20 May 2016, Jo-Philipp Wich wrote: > >> Hi Hans, >> >>> I wanted to preserve the ntp server behavior and only change the >>> behavior when configured in order to keep backwards compatibility. You >>> favour enabling DHCP ntp server config without explicit config ? >> >> >> Personally I do because thats likely what most users expect, but then >> trusting foreign NTP server advertisements might be a security sensitive >> topic - on the other hand one trusts the default gateway and DNS >> advertisements too, so I don't know. > > > NTP isn't signed. > > If I can control your DNS, I can probably control your NTP by giving you the > wrong IP for the NTP server > > If I can control your gateway, I can redirect all your NTP queries to > someone else (NAT, redirects, etc) > > so why not trust the NTP server being provided? OK let's make the concensus to enable use_dhcp by default Hans > > David Lang _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From i at conorogorman.net Fri May 20 09:59:44 2016 From: i at conorogorman.net (Conor O'Gorman) Date: Fri, 20 May 2016 14:59:44 +0100 Subject: [OpenWrt-Devel] [LEDE-DEV] [PATCH] busybox: sysntpd - Support for NTP servers received via DHCP(v6) In-Reply-To: References: <1463677071-17121-1-git-send-email-dedeckeh@gmail.com> <8c7974a7-5334-ee6d-3ba0-0bea69d3b159@mein.io> Message-ID: <573F1850.4060005@conorogorman.net> On 20/05/16 14:43, Hans Dedecker wrote: > On Fri, May 20, 2016 at 3:18 PM, David Lang wrote: >> On Fri, 20 May 2016, Jo-Philipp Wich wrote: >> >>> Hi Hans, >>> >>>> I wanted to preserve the ntp server behavior and only change the >>>> behavior when configured in order to keep backwards compatibility. You >>>> favour enabling DHCP ntp server config without explicit config ? >>> >>> Personally I do because thats likely what most users expect, but then >>> trusting foreign NTP server advertisements might be a security sensitive >>> topic - on the other hand one trusts the default gateway and DNS >>> advertisements too, so I don't know. >> >> NTP isn't signed. >> >> If I can control your DNS, I can probably control your NTP by giving you the >> wrong IP for the NTP server >> >> If I can control your gateway, I can redirect all your NTP queries to >> someone else (NAT, redirects, etc) >> >> so why not trust the NTP server being provided? > OK let's make the concensus to enable use_dhcp by default > > If there are none from dhcp, it'll fall back to the configured list? Servers from dhcp are extra? or replacing the configured? _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From dedeckeh at gmail.com Fri May 20 10:11:54 2016 From: dedeckeh at gmail.com (Hans Dedecker) Date: Fri, 20 May 2016 16:11:54 +0200 Subject: [OpenWrt-Devel] [LEDE-DEV] [PATCH] busybox: sysntpd - Support for NTP servers received via DHCP(v6) In-Reply-To: <573F1850.4060005@conorogorman.net> References: <1463677071-17121-1-git-send-email-dedeckeh@gmail.com> <8c7974a7-5334-ee6d-3ba0-0bea69d3b159@mein.io> <573F1850.4060005@conorogorman.net> Message-ID: On Fri, May 20, 2016 at 3:59 PM, Conor O'Gorman wrote: > > > On 20/05/16 14:43, Hans Dedecker wrote: >> >> On Fri, May 20, 2016 at 3:18 PM, David Lang wrote: >>> >>> On Fri, 20 May 2016, Jo-Philipp Wich wrote: >>> >>>> Hi Hans, >>>> >>>>> I wanted to preserve the ntp server behavior and only change the >>>>> behavior when configured in order to keep backwards compatibility. You >>>>> favour enabling DHCP ntp server config without explicit config ? >>>> >>>> >>>> Personally I do because thats likely what most users expect, but then >>>> trusting foreign NTP server advertisements might be a security sensitive >>>> topic - on the other hand one trusts the default gateway and DNS >>>> advertisements too, so I don't know. >>> >>> >>> NTP isn't signed. >>> >>> If I can control your DNS, I can probably control your NTP by giving you >>> the >>> wrong IP for the NTP server >>> >>> If I can control your gateway, I can redirect all your NTP queries to >>> someone else (NAT, redirects, etc) >>> >>> so why not trust the NTP server being provided? >> >> OK let's make the concensus to enable use_dhcp by default >> >> > If there are none from dhcp, it'll fall back to the configured list? > > Servers from dhcp are extra? or replacing the configured? Servers from DHCP are extra; thus on top of the configured ones _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From amine.ahd at gmail.com Fri May 20 10:27:10 2016 From: amine.ahd at gmail.com (Amine Aouled Hamed) Date: Fri, 20 May 2016 16:27:10 +0200 Subject: [OpenWrt-Devel] [LEDE-DEV] [PATCH] busybox: sysntpd - Support for NTP servers received via DHCP(v6) In-Reply-To: References: <1463677071-17121-1-git-send-email-dedeckeh@gmail.com> <8c7974a7-5334-ee6d-3ba0-0bea69d3b159@mein.io> <573F1850.4060005@conorogorman.net> Message-ID: Hi, Please add raw triggers to only the interfaces specified in the list. Regards, Amine. On Fri, May 20, 2016 at 4:11 PM, Hans Dedecker wrote: > On Fri, May 20, 2016 at 3:59 PM, Conor O'Gorman wrote: >> >> >> On 20/05/16 14:43, Hans Dedecker wrote: >>> >>> On Fri, May 20, 2016 at 3:18 PM, David Lang wrote: >>>> >>>> On Fri, 20 May 2016, Jo-Philipp Wich wrote: >>>> >>>>> Hi Hans, >>>>> >>>>>> I wanted to preserve the ntp server behavior and only change the >>>>>> behavior when configured in order to keep backwards compatibility. You >>>>>> favour enabling DHCP ntp server config without explicit config ? >>>>> >>>>> >>>>> Personally I do because thats likely what most users expect, but then >>>>> trusting foreign NTP server advertisements might be a security sensitive >>>>> topic - on the other hand one trusts the default gateway and DNS >>>>> advertisements too, so I don't know. >>>> >>>> >>>> NTP isn't signed. >>>> >>>> If I can control your DNS, I can probably control your NTP by giving you >>>> the >>>> wrong IP for the NTP server >>>> >>>> If I can control your gateway, I can redirect all your NTP queries to >>>> someone else (NAT, redirects, etc) >>>> >>>> so why not trust the NTP server being provided? >>> >>> OK let's make the concensus to enable use_dhcp by default >>> >>> >> If there are none from dhcp, it'll fall back to the configured list? >> >> Servers from dhcp are extra? or replacing the configured? > Servers from DHCP are extra; thus on top of the configured ones > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Fri May 20 12:03:48 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Fri, 20 May 2016 18:03:48 +0200 Subject: [OpenWrt-Devel] [PATCH 01/13] ar71xx: add kernel support for the OpenMesh OM2P-HSv3 Message-ID: <1463760240-12418-1-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann --- target/linux/ar71xx/files/arch/mips/ath79/mach-om2p.c | 1 + target/linux/ar71xx/files/arch/mips/ath79/machtypes.h | 1 + 2 files changed, 2 insertions(+) diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-om2p.c b/target/linux/ar71xx/files/arch/mips/ath79/mach-om2p.c index 6b0bdc3..3b282a3 100644 --- a/target/linux/ar71xx/files/arch/mips/ath79/mach-om2p.c +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-om2p.c @@ -223,3 +223,4 @@ static void __init om2p_hs_setup(void) MIPS_MACHINE(ATH79_MACH_OM2P_HS, "OM2P-HS", "OpenMesh OM2P HS", om2p_hs_setup); MIPS_MACHINE(ATH79_MACH_OM2P_HSv2, "OM2P-HSv2", "OpenMesh OM2P HSv2", om2p_hs_setup); +MIPS_MACHINE(ATH79_MACH_OM2P_HSv3, "OM2P-HSv3", "OpenMesh OM2P HSv3", om2p_hs_setup); diff --git a/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h b/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h index 4879255..e5341f1 100644 --- a/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h +++ b/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h @@ -109,6 +109,7 @@ enum ath79_mach_type { ATH79_MACH_NBG6616, /* Zyxel NBG6616 */ ATH79_MACH_NBG6716, /* Zyxel NBG6716 */ ATH79_MACH_OM2P_HSv2, /* OpenMesh OM2P-HSv2 */ + ATH79_MACH_OM2P_HSv3, /* OpenMesh OM2P-HSv3 */ ATH79_MACH_OM2P_HS, /* OpenMesh OM2P-HS */ ATH79_MACH_OM2P_LC, /* OpenMesh OM2P-LC */ ATH79_MACH_OM2Pv2, /* OpenMesh OM2Pv2 */ -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Fri May 20 12:03:49 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Fri, 20 May 2016 18:03:49 +0200 Subject: [OpenWrt-Devel] [PATCH 02/13] ar71xx: add user-space support for the OpenMesh OM2P-HSv3 In-Reply-To: <1463760240-12418-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463760240-12418-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463760240-12418-2-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann --- target/linux/ar71xx/base-files/etc/board.d/01_leds | 1 + target/linux/ar71xx/base-files/etc/diag.sh | 1 + target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 +++ 3 files changed, 5 insertions(+) diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds b/target/linux/ar71xx/base-files/etc/board.d/01_leds index 39b21ca..e003ebaa 100755 --- a/target/linux/ar71xx/base-files/etc/board.d/01_leds +++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds @@ -383,6 +383,7 @@ om2p | \ om2pv2 | \ om2p-hs | \ om2p-hsv2 | \ +om2p-hsv3 | \ om2p-lc) ucidef_set_led_netdev "port1" "port1" "om2p:blue:wan" "eth0" ucidef_set_led_netdev "port2" "port2" "om2p:blue:lan" "eth1" diff --git a/target/linux/ar71xx/base-files/etc/diag.sh b/target/linux/ar71xx/base-files/etc/diag.sh index f95a72d..ec89470 100644 --- a/target/linux/ar71xx/base-files/etc/diag.sh +++ b/target/linux/ar71xx/base-files/etc/diag.sh @@ -207,6 +207,7 @@ get_status_led() { om2pv2 | \ om2p-hs | \ om2p-hsv2 | \ + om2p-hsv3 | \ om2p-lc) status_led="om2p:blue:power" ;; diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh b/target/linux/ar71xx/base-files/lib/ar71xx.sh index d71b8ba..d00ef8e 100755 --- a/target/linux/ar71xx/base-files/lib/ar71xx.sh +++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh @@ -640,6 +640,9 @@ ar71xx_board_detect() { *"OM2P HSv2") name="om2p-hsv2" ;; + *"OM2P HSv3") + name="om2p-hsv3" + ;; *"OM2P LC") name="om2p-lc" ;; -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Fri May 20 12:03:50 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Fri, 20 May 2016 18:03:50 +0200 Subject: [OpenWrt-Devel] [PATCH 03/13] ar71xx: enable sysupgrade for the OpenMesh OM2P-HSv3 In-Reply-To: <1463760240-12418-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463760240-12418-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463760240-12418-3-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann --- target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh | 1 + target/linux/ar71xx/base-files/lib/upgrade/platform.sh | 2 ++ 2 files changed, 3 insertions(+) diff --git a/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh b/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh index bc362a7..270ef40 100644 --- a/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh +++ b/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh @@ -47,6 +47,7 @@ platform_check_image_target_openmesh() [ "$board" = "om2p-lc" ] && return 0 [ "$board" = "om2p-hs" ] && return 0 [ "$board" = "om2p-hsv2" ] && return 0 + [ "$board" = "om2p-hsv3" ] && return 0 echo "Invalid image board target ($img_board_target) for this platform: $board. Use the correct image for this platform" return 1 ;; diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh index 9f8a14b..2e01419 100755 --- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh +++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh @@ -321,6 +321,7 @@ platform_check_image() { om2pv2 | \ om2p-hs | \ om2p-hsv2 | \ + om2p-hsv3 | \ om2p-lc | \ om5p | \ om5p-an | \ @@ -579,6 +580,7 @@ platform_do_upgrade() { om2pv2 | \ om2p-hs | \ om2p-hsv2 | \ + om2p-hsv3 | \ om2p-lc | \ om5p | \ om5p-an | \ -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Fri May 20 12:03:51 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Fri, 20 May 2016 18:03:51 +0200 Subject: [OpenWrt-Devel] [PATCH 04/13] package/om-watchdog: add OpenMesh OM2P-HSv3 support In-Reply-To: <1463760240-12418-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463760240-12418-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463760240-12418-4-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann --- package/kernel/om-watchdog/files/om-watchdog.init | 1 + 1 file changed, 1 insertion(+) diff --git a/package/kernel/om-watchdog/files/om-watchdog.init b/package/kernel/om-watchdog/files/om-watchdog.init index 79819ad..4c6ac45 100644 --- a/package/kernel/om-watchdog/files/om-watchdog.init +++ b/package/kernel/om-watchdog/files/om-watchdog.init @@ -19,6 +19,7 @@ get_gpio() { "om2p" | \ "om2p-hs" | \ "om2p-hsv2" | \ + "om2p-hsv3" | \ "om5p-acv2") return 12 ;; -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Fri May 20 12:03:52 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Fri, 20 May 2016 18:03:52 +0200 Subject: [OpenWrt-Devel] [PATCH 05/13] package/uboot-envtools: add OpenMesh OM2P-HSv3 support In-Reply-To: <1463760240-12418-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463760240-12418-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463760240-12418-5-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann --- package/boot/uboot-envtools/files/ar71xx | 1 + 1 file changed, 1 insertion(+) diff --git a/package/boot/uboot-envtools/files/ar71xx b/package/boot/uboot-envtools/files/ar71xx index 32e7269..dc7583f 100644 --- a/package/boot/uboot-envtools/files/ar71xx +++ b/package/boot/uboot-envtools/files/ar71xx @@ -44,6 +44,7 @@ om2p | \ om2pv2 | \ om2p-hs | \ om2p-hsv2 | \ +om2p-hsv3 | \ om2p-lc) ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x40000" "0x40000" ;; -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Fri May 20 12:03:53 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Fri, 20 May 2016 18:03:53 +0200 Subject: [OpenWrt-Devel] [PATCH 06/13] ar71xx: add OM2P-HSv3 to the OM2P profile In-Reply-To: <1463760240-12418-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463760240-12418-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463760240-12418-6-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann --- target/linux/ar71xx/generic/profiles/openmesh.mk | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/target/linux/ar71xx/generic/profiles/openmesh.mk b/target/linux/ar71xx/generic/profiles/openmesh.mk index 6817c59..eb972ee 100644 --- a/target/linux/ar71xx/generic/profiles/openmesh.mk +++ b/target/linux/ar71xx/generic/profiles/openmesh.mk @@ -6,12 +6,12 @@ # define Profile/OM2P - NAME:=OpenMesh OM2P/OM2Pv2/OM2P-HS/OM2P-HSv2/OM2P-LC + NAME:=OpenMesh OM2P/OM2Pv2/OM2P-HS/OM2P-HSv2/OM2P-HSv3/OM2P-LC PACKAGES:=kmod-ath9k om-watchdog endef define Profile/OM2P/Description - Package set optimized for the OpenMesh OM2P/OM2Pv2/OM2P-HS/OM2P-HSv2/OM2P-LC. + Package set optimized for the OpenMesh OM2P/OM2Pv2/OM2P-HS/OM2P-HSv2/OM2P-HSv3/OM2P-LC. endef $(eval $(call Profile,OM2P)) -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Fri May 20 12:03:54 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Fri, 20 May 2016 18:03:54 +0200 Subject: [OpenWrt-Devel] [PATCH 07/13] ar71xx: add kernel support for the OpenMesh MR1750v2 In-Reply-To: <1463760240-12418-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463760240-12418-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463760240-12418-7-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann --- target/linux/ar71xx/files/arch/mips/ath79/mach-mr1750.c | 1 + target/linux/ar71xx/files/arch/mips/ath79/machtypes.h | 1 + 2 files changed, 2 insertions(+) diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-mr1750.c b/target/linux/ar71xx/files/arch/mips/ath79/mach-mr1750.c index e3c04e7..18101ce 100644 --- a/target/linux/ar71xx/files/arch/mips/ath79/mach-mr1750.c +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-mr1750.c @@ -168,3 +168,4 @@ static void __init mr1750_setup(void) } MIPS_MACHINE(ATH79_MACH_MR1750, "MR1750", "OpenMesh MR1750", mr1750_setup); +MIPS_MACHINE(ATH79_MACH_MR1750V2, "MR1750v2", "OpenMesh MR1750v2", mr1750_setup); diff --git a/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h b/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h index e5341f1..0e88996 100644 --- a/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h +++ b/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h @@ -96,6 +96,7 @@ enum ath79_mach_type { ATH79_MACH_MR16, /* Cisco Meraki MR16 */ ATH79_MACH_MR18, /* Cisco Meraki MR18 */ ATH79_MACH_MR1750, /* OpenMesh MR1750 */ + ATH79_MACH_MR1750V2, /* OpenMesh MR1750v2 */ ATH79_MACH_MR600V2, /* OpenMesh MR600v2 */ ATH79_MACH_MR600, /* OpenMesh MR600 */ ATH79_MACH_MR900, /* OpenMesh MR900 */ -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Fri May 20 12:03:55 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Fri, 20 May 2016 18:03:55 +0200 Subject: [OpenWrt-Devel] [PATCH 08/13] ar71xx: add user-space support for the OpenMesh MR1750v2 In-Reply-To: <1463760240-12418-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463760240-12418-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463760240-12418-8-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann --- target/linux/ar71xx/base-files/etc/board.d/01_leds | 3 ++- target/linux/ar71xx/base-files/etc/board.d/02_network | 1 + target/linux/ar71xx/base-files/etc/diag.sh | 3 ++- target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 +++ target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh | 1 + 5 files changed, 9 insertions(+), 2 deletions(-) diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds b/target/linux/ar71xx/base-files/etc/board.d/01_leds index e003ebaa..66a031f 100755 --- a/target/linux/ar71xx/base-files/etc/board.d/01_leds +++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds @@ -322,7 +322,8 @@ mr600) ucidef_set_led_wlan "wlan58" "WLAN58" "mr600:green:wlan58" "phy0tpt" ;; -mr1750) +mr1750 | \ +mr1750v2) ucidef_set_led_netdev "lan" "LAN" "mr1750:blue:wan" "eth0" ucidef_set_led_wlan "wlan58" "WLAN58" "mr1750:blue:wlan58" "phy0tpt" ucidef_set_led_wlan "wlan24" "WLAN24" "mr1750:blue:wlan24" "phy1tpt" diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network b/target/linux/ar71xx/base-files/etc/board.d/02_network index 67adf33..6a4cdaf 100755 --- a/target/linux/ar71xx/base-files/etc/board.d/02_network +++ b/target/linux/ar71xx/base-files/etc/board.d/02_network @@ -335,6 +335,7 @@ eap7660d |\ el-mini |\ loco-m-xw |\ mr1750 |\ +mr1750v2 |\ mr18 |\ mr600 |\ mr600v2 |\ diff --git a/target/linux/ar71xx/base-files/etc/diag.sh b/target/linux/ar71xx/base-files/etc/diag.sh index ec89470..e296b56 100644 --- a/target/linux/ar71xx/base-files/etc/diag.sh +++ b/target/linux/ar71xx/base-files/etc/diag.sh @@ -176,7 +176,8 @@ get_status_led() { mr600v2) status_led="mr600:blue:power" ;; - mr1750) + mr1750 | \ + mr1750v2) status_led="mr1750:blue:power" ;; mr900 | \ diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh b/target/linux/ar71xx/base-files/lib/ar71xx.sh index d00ef8e..12bc9e3 100755 --- a/target/linux/ar71xx/base-files/lib/ar71xx.sh +++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh @@ -595,6 +595,9 @@ ar71xx_board_detect() { *MR1750) name="mr1750" ;; + *MR1750v2) + name="mr1750v2" + ;; *MR600) name="mr600" ;; diff --git a/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh b/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh index 270ef40..87b6516 100644 --- a/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh +++ b/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh @@ -65,6 +65,7 @@ platform_check_image_target_openmesh() ;; MR1750) [ "$board" = "mr1750" ] && return 0 + [ "$board" = "mr1750v2" ] && return 0 echo "Invalid image board target ($img_board_target) for this platform: $board. Use the correct image for this platform" return 1 ;; -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Fri May 20 12:03:56 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Fri, 20 May 2016 18:03:56 +0200 Subject: [OpenWrt-Devel] [PATCH 09/13] ar71xx: enable sysupgrade for the OpenMesh MR1750v2 In-Reply-To: <1463760240-12418-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463760240-12418-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463760240-12418-9-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann --- target/linux/ar71xx/base-files/lib/upgrade/platform.sh | 2 ++ 1 file changed, 2 insertions(+) diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh index 2e01419..2ce5331 100755 --- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh +++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh @@ -313,6 +313,7 @@ platform_check_image() { return 0; ;; mr1750 | \ + mr1750v2 | \ mr600 | \ mr600v2 | \ mr900 | \ @@ -572,6 +573,7 @@ platform_do_upgrade() { platform_do_upgrade_dir825b "$ARGV" ;; mr1750 | \ + mr1750v2 | \ mr600 | \ mr600v2 | \ mr900 | \ -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Fri May 20 12:03:57 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Fri, 20 May 2016 18:03:57 +0200 Subject: [OpenWrt-Devel] [PATCH 10/13] package/om-watchdog: add OpenMesh MR1750v2 support In-Reply-To: <1463760240-12418-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463760240-12418-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463760240-12418-10-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann --- package/kernel/om-watchdog/files/om-watchdog.init | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/package/kernel/om-watchdog/files/om-watchdog.init b/package/kernel/om-watchdog/files/om-watchdog.init index 4c6ac45..4ed178d 100644 --- a/package/kernel/om-watchdog/files/om-watchdog.init +++ b/package/kernel/om-watchdog/files/om-watchdog.init @@ -39,7 +39,8 @@ get_gpio() { ;; "mr900" | \ "mr900v2" | \ - "mr1750") + "mr1750" | \ + "mr1750v2") return 16 ;; esac -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Fri May 20 12:03:58 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Fri, 20 May 2016 18:03:58 +0200 Subject: [OpenWrt-Devel] [PATCH 11/13] package/uboot-envtools: add OpenMesh MR1750v2 support In-Reply-To: <1463760240-12418-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463760240-12418-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463760240-12418-11-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann --- package/boot/uboot-envtools/files/ar71xx | 1 + 1 file changed, 1 insertion(+) diff --git a/package/boot/uboot-envtools/files/ar71xx b/package/boot/uboot-envtools/files/ar71xx index dc7583f..986fdef 100644 --- a/package/boot/uboot-envtools/files/ar71xx +++ b/package/boot/uboot-envtools/files/ar71xx @@ -25,6 +25,7 @@ eap300v2 | \ hornet-ub | \ hornet-ub-x2 | \ mr1750 | \ +mr1750v2 | \ mr600 | \ mr600v2 | \ mr900 | \ -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Fri May 20 12:03:59 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Fri, 20 May 2016 18:03:59 +0200 Subject: [OpenWrt-Devel] [PATCH 12/13] ar71xx: extract ath10k wifi board.bin for the OpenMesh MR1750v2 board In-Reply-To: <1463760240-12418-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463760240-12418-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463760240-12418-12-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann --- target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata | 1 + 1 file changed, 1 insertion(+) diff --git a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata index 8fc3ab3..f01c6d3 100644 --- a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata +++ b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata @@ -72,6 +72,7 @@ case "$FIRMWARE" in ath10kcal_patch_mac $(macaddr_add $(cat /sys/class/net/eth0/address) +1) ;; mr1750 | \ + mr1750v2 | \ om5p-acv2) ath10kcal_extract "ART" 20480 2116 ath10kcal_patch_mac $(macaddr_add $(cat /sys/class/net/eth0/address) +16) -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sven.eckelmann at open-mesh.com Fri May 20 12:04:00 2016 From: sven.eckelmann at open-mesh.com (Sven Eckelmann) Date: Fri, 20 May 2016 18:04:00 +0200 Subject: [OpenWrt-Devel] [PATCH 13/13] ar71xx: add MR1750v2 to the MR1750 profile In-Reply-To: <1463760240-12418-1-git-send-email-sven.eckelmann@open-mesh.com> References: <1463760240-12418-1-git-send-email-sven.eckelmann@open-mesh.com> Message-ID: <1463760240-12418-13-git-send-email-sven.eckelmann@open-mesh.com> Signed-off-by: Sven Eckelmann --- target/linux/ar71xx/generic/profiles/openmesh.mk | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/target/linux/ar71xx/generic/profiles/openmesh.mk b/target/linux/ar71xx/generic/profiles/openmesh.mk index eb972ee..15b974a 100644 --- a/target/linux/ar71xx/generic/profiles/openmesh.mk +++ b/target/linux/ar71xx/generic/profiles/openmesh.mk @@ -61,12 +61,12 @@ endef $(eval $(call Profile,MR900)) define Profile/MR1750 - NAME:=OpenMesh MR1750 + NAME:=OpenMesh MR1750/MR1750v2 PACKAGES:=kmod-ath9k kmod-ath10k endef define Profile/MR1750/Description - Package set optimized for the OpenMesh MR1750. + Package set optimized for the OpenMesh MR1750/MR1750v2. endef $(eval $(call Profile,MR1750)) -- 2.8.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From rjangi at codeaurora.org Sat May 21 05:18:31 2016 From: rjangi at codeaurora.org (Ram Chandra Jangir) Date: Sat, 21 May 2016 14:48:31 +0530 Subject: [OpenWrt-Devel] [PATCH] ipq806x: Add support for linux-4.4 Message-ID: <1463822311-31240-1-git-send-email-rjangi@codeaurora.org> 1)Changes - Rebased the patches for linux-4.4.7 - Added patch to fix spi nor fifo and dma support - Added patch to configure watchdog barktime 2)Testing Tested on IPQ AP148 Board: a. NOR boot and NAND boot b. ethernet network and ath10k wifi c. ubi sysupgrade UnTested dwc3 usb has not been validated on IPQ board(AP148) 3)Known Issues: Once we flash ubi image on AP148, and if we reset the board, uboot on first boot creates PEB and LEB for dynamic sized partitions, which is incorrect and not what linux expects which causes errors when trying to mount rootfs. In order to test this, we can use the below steps: a. Flash the ubi image on board and don't reset the board b. load the kernel fit image in RAM and boot from there. Signed-off-by: Ram Chandra Jangir --- target/linux/ipq806x/config-4.4 | 463 +++++ .../patches-4.4/020-add-ap148-bootargs.patch | 61 + .../patches-4.4/021-add-ap148-partitions.patch | 19 + .../ipq806x/patches-4.4/022-add-db149-dts.patch | 160 ++ ...M-dts-ipq806x-Disable-i2c-device-on-gsbi4.patch | 52 + .../patches-4.4/024-ap148-add-memory-node.patch | 14 + ...33-ARM-qcom-add-SFPB-nodes-to-IPQ806x-dts.patch | 33 + ...-qcom-add-SMEM-device-node-to-IPQ806x-dts.patch | 36 + ...37-mtd-add-SMEM-parser-for-QCOM-platforms.patch | 282 +++ ...b-phy-Add-Qualcomm-DWC3-HS-SS-PHY-drivers.patch | 510 +++++ ...1-ARM-qcom-add-USB-nodes-to-ipq806x-ap148.patch | 125 ++ ...CI-qcom-Document-PCIe-devicetree-bindings.patch | 263 +++ ...-qcom-Add-Qualcomm-PCIe-controller-driver.patch | 752 ++++++++ ...-qcom-add-pcie-nodes-to-ipq806x-platforms.patch | 244 +++ ...tomatically-select-PCI_DOMAINS-if-PCI-is-.patch | 29 + .../patches-4.4/114-pcie-add-ctlr-init.patch | 311 +++ .../patches-4.4/115-add-pcie-aux-clk-dts.patch | 80 + .../patches-4.4/126-add-rpm-to-ipq8064-dts.patch | 87 + ...-Add-Krait-L2-register-accessor-functions.patch | 144 ++ ...ux-Split-out-register-accessors-for-reuse.patch | 184 ++ ...ending-high-rates-to-downstream-clocks-du.patch | 127 ++ .../patches-4.4/136-clk-Add-safe-switch-hook.patch | 158 ++ ...dd-support-for-High-Frequency-PLLs-HFPLLs.patch | 351 ++++ .../138-clk-qcom-Add-HFPLL-driver.patch | 206 ++ .../139-clk-qcom-Add-IPQ806X-s-HFPLLs.patch | 127 ++ ...140-clk-qcom-Add-support-for-Krait-clocks.patch | 272 +++ .../141-clk-qcom-Add-KPSS-ACC-GCC-driver.patch | 207 ++ ...lk-qcom-Add-Krait-clock-controller-driver.patch | 435 +++++ ...-module-to-register-cpufreq-on-Krait-CPUs.patch | 304 +++ ...m-Add-necessary-DT-data-for-Krait-cpufreq.patch | 100 + ...ufreq-Add-a-cpufreq-krait-based-on-cpufre.patch | 461 +++++ ...-bindings-qcom_adm-Fix-channel-specifiers.patch | 76 + .../patches-4.4/156-dmaengine-Add-ADM-driver.patch | 964 ++++++++++ .../157-ARM-DT-ipq8064-Add-ADM-device-node.patch | 42 + ...g-to-access-bad-block-markers-in-raw-mode.patch | 83 + ...-mtd-nand-Qualcomm-NAND-controller-driver.patch | 2024 ++++++++++++++++++++ ...63-dt-bindings-qcom_nandc-Add-DT-bindings.patch | 82 + ...-dts-Add-NAND-controller-node-for-ipq806x.patch | 51 + ...nable-NAND-node-on-IPQ8064-AP148-platform.patch | 76 + ...h-qcom-dts-enable-qcom-smem-on-AP148-NAND.patch | 11 + .../300-arch-arm-force-ZRELADDR-on-arch-qcom.patch | 62 + .../302-mtd-qcom-smem-rename-rootfs-ubi.patch | 13 + ...RM-dts-qcom-add-mdio-nodes-to-ap148-db149.patch | 146 ++ ...-qcom-add-gmac-nodes-to-ipq806x-platforms.patch | 216 +++ ...-qup-Fix-fifo-and-dma-support-for-IPQ806x.patch | 134 ++ ...om-set-WDT_BARK_TIME-register-offset-to-o.patch | 43 + 46 files changed, 10620 insertions(+) create mode 100644 target/linux/ipq806x/config-4.4 create mode 100644 target/linux/ipq806x/patches-4.4/020-add-ap148-bootargs.patch create mode 100644 target/linux/ipq806x/patches-4.4/021-add-ap148-partitions.patch create mode 100644 target/linux/ipq806x/patches-4.4/022-add-db149-dts.patch create mode 100644 target/linux/ipq806x/patches-4.4/023-ARM-dts-ipq806x-Disable-i2c-device-on-gsbi4.patch create mode 100644 target/linux/ipq806x/patches-4.4/024-ap148-add-memory-node.patch create mode 100644 target/linux/ipq806x/patches-4.4/033-ARM-qcom-add-SFPB-nodes-to-IPQ806x-dts.patch create mode 100644 target/linux/ipq806x/patches-4.4/036-ARM-qcom-add-SMEM-device-node-to-IPQ806x-dts.patch create mode 100644 target/linux/ipq806x/patches-4.4/037-mtd-add-SMEM-parser-for-QCOM-platforms.patch create mode 100644 target/linux/ipq806x/patches-4.4/100-usb-phy-Add-Qualcomm-DWC3-HS-SS-PHY-drivers.patch create mode 100644 target/linux/ipq806x/patches-4.4/101-ARM-qcom-add-USB-nodes-to-ipq806x-ap148.patch create mode 100644 target/linux/ipq806x/patches-4.4/110-DT-PCI-qcom-Document-PCIe-devicetree-bindings.patch create mode 100644 target/linux/ipq806x/patches-4.4/111-PCI-qcom-Add-Qualcomm-PCIe-controller-driver.patch create mode 100644 target/linux/ipq806x/patches-4.4/112-ARM-dts-qcom-add-pcie-nodes-to-ipq806x-platforms.patch create mode 100644 target/linux/ipq806x/patches-4.4/113-ARM-qcom-automatically-select-PCI_DOMAINS-if-PCI-is-.patch create mode 100644 target/linux/ipq806x/patches-4.4/114-pcie-add-ctlr-init.patch create mode 100644 target/linux/ipq806x/patches-4.4/115-add-pcie-aux-clk-dts.patch create mode 100644 target/linux/ipq806x/patches-4.4/126-add-rpm-to-ipq8064-dts.patch create mode 100644 target/linux/ipq806x/patches-4.4/133-ARM-Add-Krait-L2-register-accessor-functions.patch create mode 100644 target/linux/ipq806x/patches-4.4/134-clk-mux-Split-out-register-accessors-for-reuse.patch create mode 100644 target/linux/ipq806x/patches-4.4/135-clk-Avoid-sending-high-rates-to-downstream-clocks-du.patch create mode 100644 target/linux/ipq806x/patches-4.4/136-clk-Add-safe-switch-hook.patch create mode 100644 target/linux/ipq806x/patches-4.4/137-clk-qcom-Add-support-for-High-Frequency-PLLs-HFPLLs.patch create mode 100644 target/linux/ipq806x/patches-4.4/138-clk-qcom-Add-HFPLL-driver.patch create mode 100644 target/linux/ipq806x/patches-4.4/139-clk-qcom-Add-IPQ806X-s-HFPLLs.patch create mode 100644 target/linux/ipq806x/patches-4.4/140-clk-qcom-Add-support-for-Krait-clocks.patch create mode 100644 target/linux/ipq806x/patches-4.4/141-clk-qcom-Add-KPSS-ACC-GCC-driver.patch create mode 100644 target/linux/ipq806x/patches-4.4/142-clk-qcom-Add-Krait-clock-controller-driver.patch create mode 100644 target/linux/ipq806x/patches-4.4/143-cpufreq-Add-module-to-register-cpufreq-on-Krait-CPUs.patch create mode 100644 target/linux/ipq806x/patches-4.4/144-ARM-dts-qcom-Add-necessary-DT-data-for-Krait-cpufreq.patch create mode 100644 target/linux/ipq806x/patches-4.4/145-cpufreq-Add-a-cpufreq-krait-based-on-cpufre.patch create mode 100644 target/linux/ipq806x/patches-4.4/155-dt-bindings-qcom_adm-Fix-channel-specifiers.patch create mode 100644 target/linux/ipq806x/patches-4.4/156-dmaengine-Add-ADM-driver.patch create mode 100644 target/linux/ipq806x/patches-4.4/157-ARM-DT-ipq8064-Add-ADM-device-node.patch create mode 100644 target/linux/ipq806x/patches-4.4/161-mtd-nand-Create-a-BBT-flag-to-access-bad-block-markers-in-raw-mode.patch create mode 100644 target/linux/ipq806x/patches-4.4/162-mtd-nand-Qualcomm-NAND-controller-driver.patch create mode 100644 target/linux/ipq806x/patches-4.4/163-dt-bindings-qcom_nandc-Add-DT-bindings.patch create mode 100644 target/linux/ipq806x/patches-4.4/164-arm-qcom-dts-Add-NAND-controller-node-for-ipq806x.patch create mode 100644 target/linux/ipq806x/patches-4.4/165-arm-qcom-dts-Enable-NAND-node-on-IPQ8064-AP148-platform.patch create mode 100644 target/linux/ipq806x/patches-4.4/166-arch-qcom-dts-enable-qcom-smem-on-AP148-NAND.patch create mode 100644 target/linux/ipq806x/patches-4.4/300-arch-arm-force-ZRELADDR-on-arch-qcom.patch create mode 100644 target/linux/ipq806x/patches-4.4/302-mtd-qcom-smem-rename-rootfs-ubi.patch create mode 100644 target/linux/ipq806x/patches-4.4/707-ARM-dts-qcom-add-mdio-nodes-to-ap148-db149.patch create mode 100644 target/linux/ipq806x/patches-4.4/708-ARM-dts-qcom-add-gmac-nodes-to-ipq806x-platforms.patch create mode 100644 target/linux/ipq806x/patches-4.4/709-spi-qup-Fix-fifo-and-dma-support-for-IPQ806x.patch create mode 100644 target/linux/ipq806x/patches-4.4/710-watchdog-qcom-set-WDT_BARK_TIME-register-offset-to-o.patch diff --git a/target/linux/ipq806x/config-4.4 b/target/linux/ipq806x/config-4.4 new file mode 100644 index 0000000..3a9592f --- /dev/null +++ b/target/linux/ipq806x/config-4.4 @@ -0,0 +1,463 @@ +CONFIG_ALIGNMENT_TRAP=y +# CONFIG_AMBA_PL08X is not set +# CONFIG_APM_EMULATION is not set +CONFIG_APQ_GCC_8084=y +CONFIG_APQ_MMCC_8084=y +CONFIG_AR8216_PHY=y +CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y +CONFIG_ARCH_HAS_ELF_RANDOMIZE=y +CONFIG_ARCH_HAS_GCOV_PROFILE_ALL=y +CONFIG_ARCH_HAS_SG_CHAIN=y +CONFIG_ARCH_HAS_TICK_BROADCAST=y +CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y +CONFIG_ARCH_HIBERNATION_POSSIBLE=y +CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y +CONFIG_ARCH_MSM8960=y +CONFIG_ARCH_MSM8974=y +CONFIG_ARCH_MSM8X60=y +CONFIG_ARCH_MULTIPLATFORM=y +# CONFIG_ARCH_MULTI_CPU_AUTO is not set +CONFIG_ARCH_MULTI_V6_V7=y +CONFIG_ARCH_MULTI_V7=y +CONFIG_ARCH_NR_GPIO=0 +CONFIG_ARCH_QCOM=y +# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set +# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set +CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y +CONFIG_ARCH_SUPPORTS_BIG_ENDIAN=y +CONFIG_ARCH_SUPPORTS_UPROBES=y +CONFIG_ARCH_SUSPEND_POSSIBLE=y +CONFIG_ARCH_USE_BUILTIN_BSWAP=y +CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y +CONFIG_ARCH_WANT_GENERAL_HUGETLB=y +CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y +CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y +CONFIG_ARM=y +CONFIG_ARM_AMBA=y +CONFIG_ARM_APPENDED_DTB=y +CONFIG_ARM_ARCH_TIMER=y +CONFIG_ARM_ARCH_TIMER_EVTSTREAM=y +# CONFIG_ARM_ATAG_DTB_COMPAT is not set +CONFIG_ARM_CCI=y +CONFIG_ARM_CCI400_COMMON=y +CONFIG_ARM_CCI400_PMU=y +# CONFIG_ARM_CPUIDLE is not set +CONFIG_ARM_CPU_SUSPEND=y +CONFIG_ARM_GIC=y +CONFIG_ARM_HAS_SG_CHAIN=y +CONFIG_ARM_L1_CACHE_SHIFT=6 +CONFIG_ARM_L1_CACHE_SHIFT_6=y +# CONFIG_ARM_LPAE is not set +CONFIG_ARM_PATCH_PHYS_VIRT=y +CONFIG_ARM_QCOM_CPUFREQ=y +# CONFIG_ARM_SMMU is not set +# CONFIG_ARM_SP805_WATCHDOG is not set +CONFIG_ARM_THUMB=y +# CONFIG_ARM_THUMBEE is not set +CONFIG_ARM_UNWIND=y +CONFIG_ARM_VIRT_EXT=y +CONFIG_AT803X_PHY=y +# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set +CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0 +CONFIG_BOUNCE=y +CONFIG_BUILD_BIN2C=y +# CONFIG_CACHE_L2X0 is not set +CONFIG_CLEANCACHE=y +CONFIG_CLKDEV_LOOKUP=y +CONFIG_CLKSRC_OF=y +CONFIG_CLKSRC_QCOM=y +CONFIG_CLONE_BACKWARDS=y +CONFIG_COMMON_CLK=y +CONFIG_COMMON_CLK_QCOM=y +CONFIG_COMPACTION=y +CONFIG_COREDUMP=y +# CONFIG_CPUFREQ_DT is not set +CONFIG_CPU_32v6K=y +CONFIG_CPU_32v7=y +CONFIG_CPU_ABRT_EV7=y +# CONFIG_CPU_BIG_ENDIAN is not set +# CONFIG_CPU_BPREDICT_DISABLE is not set +CONFIG_CPU_CACHE_V7=y +CONFIG_CPU_CACHE_VIPT=y +CONFIG_CPU_COPY_V6=y +CONFIG_CPU_CP15=y +CONFIG_CPU_CP15_MMU=y +CONFIG_CPU_FREQ=y +# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set +# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set +CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y +# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set +# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set +# CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set +# CONFIG_CPU_FREQ_GOV_ONDEMAND is not set +CONFIG_CPU_FREQ_GOV_PERFORMANCE=y +# CONFIG_CPU_FREQ_GOV_POWERSAVE is not set +# CONFIG_CPU_FREQ_GOV_USERSPACE is not set +CONFIG_CPU_FREQ_STAT=y +# CONFIG_CPU_FREQ_STAT_DETAILS is not set +CONFIG_CPU_HAS_ASID=y +# CONFIG_CPU_ICACHE_DISABLE is not set +CONFIG_CPU_IDLE=y +CONFIG_CPU_IDLE_GOV_LADDER=y +CONFIG_CPU_IDLE_GOV_MENU=y +CONFIG_CPU_PABRT_V7=y +CONFIG_CPU_PM=y +CONFIG_CPU_RMAP=y +# CONFIG_CPU_THERMAL is not set +CONFIG_CPU_TLB_V7=y +CONFIG_CPU_V7=y +CONFIG_CRC16=y +# CONFIG_CRC32_SARWATE is not set +CONFIG_CRC32_SLICEBY8=y +CONFIG_CROSS_MEMORY_ATTACH=y +CONFIG_CRYPTO_DEFLATE=y +CONFIG_CRYPTO_LZO=y +CONFIG_CRYPTO_RNG2=y +CONFIG_CRYPTO_WORKQUEUE=y +CONFIG_CRYPTO_XZ=y +CONFIG_DCACHE_WORD_ACCESS=y +CONFIG_DEBUG_BUGVERBOSE=y +CONFIG_DEBUG_GPIO=y +CONFIG_DEBUG_LL_INCLUDE="mach/debug-macro.S" +CONFIG_DEBUG_PREEMPT=y +# CONFIG_DEBUG_UART_8250 is not set +# CONFIG_DEBUG_USER is not set +CONFIG_DECOMPRESS_GZIP=y +CONFIG_DEVMEM=y +CONFIG_DMADEVICES=y +CONFIG_DMA_ENGINE=y +CONFIG_DMA_OF=y +CONFIG_DMA_VIRTUAL_CHANNELS=y +CONFIG_DTC=y +# CONFIG_DWMAC_GENERIC is not set +CONFIG_DWMAC_IPQ806X=y +# CONFIG_DWMAC_LPC18XX is not set +# CONFIG_DWMAC_MESON is not set +# CONFIG_DWMAC_ROCKCHIP is not set +# CONFIG_DWMAC_SOCFPGA is not set +# CONFIG_DWMAC_STI is not set +# CONFIG_DWMAC_SUNXI is not set +# CONFIG_DW_DMAC_PCI is not set +CONFIG_DYNAMIC_DEBUG=y +CONFIG_ETHERNET_PACKET_MANGLE=y +CONFIG_FIXED_PHY=y +CONFIG_FREEZER=y +CONFIG_GENERIC_ALLOCATOR=y +CONFIG_GENERIC_BUG=y +CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y +CONFIG_GENERIC_CPUFREQ_KRAIT=y +CONFIG_GENERIC_IDLE_POLL_SETUP=y +CONFIG_GENERIC_IO=y +CONFIG_GENERIC_IRQ_SHOW=y +CONFIG_GENERIC_IRQ_SHOW_LEVEL=y +CONFIG_GENERIC_MSI_IRQ=y +CONFIG_GENERIC_PCI_IOMAP=y +CONFIG_GENERIC_PHY=y +CONFIG_GENERIC_PINCONF=y +CONFIG_GENERIC_SCHED_CLOCK=y +CONFIG_GENERIC_SMP_IDLE_THREAD=y +CONFIG_GENERIC_STRNCPY_FROM_USER=y +CONFIG_GENERIC_STRNLEN_USER=y +CONFIG_GENERIC_TIME_VSYSCALL=y +CONFIG_GPIOLIB=y +CONFIG_GPIOLIB_IRQCHIP=y +CONFIG_GPIO_DEVRES=y +# CONFIG_GPIO_MSM_V2 is not set +CONFIG_GPIO_SYSFS=y +CONFIG_HANDLE_DOMAIN_IRQ=y +CONFIG_HARDIRQS_SW_RESEND=y +CONFIG_HAS_DMA=y +CONFIG_HAS_IOMEM=y +CONFIG_HAS_IOPORT_MAP=y +# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set +CONFIG_HAVE_ARCH_AUDITSYSCALL=y +CONFIG_HAVE_ARCH_BITREVERSE=y +CONFIG_HAVE_ARCH_JUMP_LABEL=y +CONFIG_HAVE_ARCH_KGDB=y +CONFIG_HAVE_ARCH_PFN_VALID=y +CONFIG_HAVE_ARCH_SECCOMP_FILTER=y +CONFIG_HAVE_ARCH_TRACEHOOK=y +CONFIG_HAVE_ARM_ARCH_TIMER=y +# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set +CONFIG_HAVE_BPF_JIT=y +CONFIG_HAVE_CC_STACKPROTECTOR=y +CONFIG_HAVE_CLK=y +CONFIG_HAVE_CLK_PREPARE=y +CONFIG_HAVE_CONTEXT_TRACKING=y +CONFIG_HAVE_C_RECORDMCOUNT=y +CONFIG_HAVE_DEBUG_KMEMLEAK=y +CONFIG_HAVE_DMA_API_DEBUG=y +CONFIG_HAVE_DMA_ATTRS=y +CONFIG_HAVE_DMA_CONTIGUOUS=y +CONFIG_HAVE_DYNAMIC_FTRACE=y +CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y +CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y +CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y +CONFIG_HAVE_FUNCTION_TRACER=y +CONFIG_HAVE_GENERIC_DMA_COHERENT=y +CONFIG_HAVE_HW_BREAKPOINT=y +CONFIG_HAVE_IDE=y +CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y +CONFIG_HAVE_KERNEL_GZIP=y +CONFIG_HAVE_KERNEL_LZ4=y +CONFIG_HAVE_KERNEL_LZMA=y +CONFIG_HAVE_KERNEL_LZO=y +CONFIG_HAVE_KERNEL_XZ=y +CONFIG_HAVE_MEMBLOCK=y +CONFIG_HAVE_MOD_ARCH_SPECIFIC=y +CONFIG_HAVE_NET_DSA=y +CONFIG_HAVE_OPROFILE=y +CONFIG_HAVE_OPTPROBES=y +CONFIG_HAVE_PERF_EVENTS=y +CONFIG_HAVE_PERF_REGS=y +CONFIG_HAVE_PERF_USER_STACK_DUMP=y +CONFIG_HAVE_PROC_CPU=y +CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y +CONFIG_HAVE_SMP=y +CONFIG_HAVE_SYSCALL_TRACEPOINTS=y +CONFIG_HAVE_UID16=y +CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y +CONFIG_HIGHMEM=y +CONFIG_HIGHPTE=y +CONFIG_HOTPLUG_CPU=y +# CONFIG_HSU_DMA_PCI is not set +CONFIG_HWMON=y +CONFIG_HWSPINLOCK=y +CONFIG_HWSPINLOCK_QCOM=y +CONFIG_HW_RANDOM=y +CONFIG_HW_RANDOM_MSM=y +CONFIG_HZ_FIXED=0 +CONFIG_I2C=y +CONFIG_I2C_BOARDINFO=y +CONFIG_I2C_CHARDEV=y +CONFIG_I2C_COMPAT=y +CONFIG_I2C_HELPER_AUTO=y +CONFIG_I2C_QUP=y +CONFIG_IKCONFIG=y +CONFIG_IKCONFIG_PROC=y +CONFIG_INITRAMFS_SOURCE="" +CONFIG_IOMMU_HELPER=y +# CONFIG_IOMMU_IO_PGTABLE_LPAE is not set +CONFIG_IOMMU_SUPPORT=y +CONFIG_IPQ_GCC_806X=y +# CONFIG_IPQ_LCC_806X is not set +CONFIG_IRQCHIP=y +CONFIG_IRQ_DOMAIN=y +CONFIG_IRQ_DOMAIN_HIERARCHY=y +CONFIG_IRQ_FORCED_THREADING=y +CONFIG_IRQ_WORK=y +CONFIG_KPSS_XCC=y +CONFIG_KRAITCC=y +CONFIG_KRAIT_CLOCKS=y +CONFIG_KRAIT_L2_ACCESSORS=y +CONFIG_LIBFDT=y +CONFIG_LOCKUP_DETECTOR=y +CONFIG_LOCK_SPIN_ON_OWNER=y +CONFIG_LZO_COMPRESS=y +CONFIG_LZO_DECOMPRESS=y +CONFIG_MDIO_BITBANG=y +CONFIG_MDIO_BOARDINFO=y +CONFIG_MDIO_GPIO=y +CONFIG_MFD_QCOM_RPM=y +# CONFIG_MFD_SPMI_PMIC is not set +CONFIG_MFD_SYSCON=y +CONFIG_MIGHT_HAVE_CACHE_L2X0=y +CONFIG_MIGHT_HAVE_PCI=y +CONFIG_MIGRATION=y +CONFIG_MODULES_USE_ELF_REL=y +CONFIG_MSM_GCC_8660=y +# CONFIG_MSM_GCC_8916 is not set +CONFIG_MSM_GCC_8960=y +CONFIG_MSM_GCC_8974=y +# CONFIG_MSM_LCC_8960 is not set +CONFIG_MSM_MMCC_8960=y +CONFIG_MSM_MMCC_8974=y +CONFIG_MTD_CMDLINE_PARTS=y +CONFIG_MTD_M25P80=y +CONFIG_MTD_NAND=y +CONFIG_MTD_NAND_ECC=y +CONFIG_MTD_NAND_QCOM=y +CONFIG_MTD_QCOM_SMEM_PARTS=y +CONFIG_MTD_SPI_NOR=y +CONFIG_MTD_SPLIT_FIRMWARE=y +CONFIG_MTD_SPLIT_FIT_FW=y +CONFIG_MTD_UBI=y +CONFIG_MTD_UBI_BEB_LIMIT=20 +CONFIG_MTD_UBI_BLOCK=y +# CONFIG_MTD_UBI_FASTMAP is not set +# CONFIG_MTD_UBI_GLUEBI is not set +CONFIG_MTD_UBI_WL_THRESHOLD=4096 +CONFIG_MULTI_IRQ_HANDLER=y +CONFIG_MUTEX_SPIN_ON_OWNER=y +CONFIG_NEED_DMA_MAP_STATE=y +CONFIG_NEON=y +CONFIG_NET_FLOW_LIMIT=y +CONFIG_NET_PTP_CLASSIFY=y +CONFIG_NET_VENDOR_WIZNET=y +CONFIG_NO_BOOTMEM=y +CONFIG_NO_HZ=y +CONFIG_NO_HZ_COMMON=y +CONFIG_NO_HZ_IDLE=y +CONFIG_NR_CPUS=4 +CONFIG_OF=y +CONFIG_OF_ADDRESS=y +CONFIG_OF_ADDRESS_PCI=y +CONFIG_OF_EARLY_FLATTREE=y +CONFIG_OF_FLATTREE=y +CONFIG_OF_GPIO=y +CONFIG_OF_IRQ=y +CONFIG_OF_MDIO=y +CONFIG_OF_MTD=y +CONFIG_OF_NET=y +CONFIG_OF_PCI=y +CONFIG_OF_PCI_IRQ=y +CONFIG_OF_RESERVED_MEM=y +CONFIG_OLD_SIGACTION=y +CONFIG_OLD_SIGSUSPEND3=y +CONFIG_PAGEFLAGS_EXTENDED=y +CONFIG_PAGE_OFFSET=0xC0000000 +CONFIG_PCI=y +CONFIG_PCIEAER=y +CONFIG_PCIEPORTBUS=y +CONFIG_PCIE_DW=y +# CONFIG_PCIE_IPROC is not set +CONFIG_PCIE_PME=y +CONFIG_PCIE_QCOM=y +CONFIG_PCI_DEBUG=y +CONFIG_PCI_DOMAINS=y +CONFIG_PCI_DOMAINS_GENERIC=y +CONFIG_PCI_MSI=y +CONFIG_PERF_EVENTS=y +CONFIG_PERF_USE_VMALLOC=y +CONFIG_PGTABLE_LEVELS=2 +CONFIG_PHYLIB=y +# CONFIG_PHY_QCOM_APQ8064_SATA is not set +CONFIG_PHY_QCOM_IPQ806X_SATA=y +# CONFIG_PHY_QCOM_UFS is not set +CONFIG_PINCTRL=y +CONFIG_PINCTRL_APQ8064=y +# CONFIG_PINCTRL_APQ8084 is not set +CONFIG_PINCTRL_IPQ8064=y +CONFIG_PINCTRL_MSM=y +# CONFIG_PINCTRL_MSM8660 is not set +# CONFIG_PINCTRL_MSM8916 is not set +# CONFIG_PINCTRL_MSM8960 is not set +CONFIG_PINCTRL_MSM8X74=y +# CONFIG_PINCTRL_QCOM_SPMI_PMIC is not set +# CONFIG_PINCTRL_QCOM_SSBI_PMIC is not set +# CONFIG_PL330_DMA is not set +CONFIG_PM=y +CONFIG_PM_CLK=y +# CONFIG_PM_DEBUG is not set +CONFIG_PM_OPP=y +CONFIG_PM_SLEEP=y +CONFIG_PM_SLEEP_SMP=y +CONFIG_POWER_RESET=y +# CONFIG_POWER_RESET_BRCMSTB is not set +CONFIG_POWER_RESET_MSM=y +CONFIG_POWER_SUPPLY=y +CONFIG_PPS=y +CONFIG_PREEMPT=y +CONFIG_PREEMPT_COUNT=y +# CONFIG_PREEMPT_NONE is not set +CONFIG_PREEMPT_RCU=y +CONFIG_PRINTK_TIME=y +CONFIG_PROC_PAGE_MONITOR=y +CONFIG_PTP_1588_CLOCK=y +CONFIG_QCOM_ADM=y +CONFIG_QCOM_BAM_DMA=y +CONFIG_QCOM_GSBI=y +CONFIG_QCOM_HFPLL=y +# CONFIG_QCOM_PM is not set +CONFIG_QCOM_SCM=y +# CONFIG_QCOM_SMD is not set +CONFIG_QCOM_SMEM=y +CONFIG_QCOM_WDT=y +CONFIG_RAS=y +# CONFIG_RCU_BOOST is not set +CONFIG_RCU_CPU_STALL_TIMEOUT=21 +CONFIG_RCU_STALL_COMMON=y +CONFIG_RD_GZIP=y +CONFIG_REGMAP=y +CONFIG_REGMAP_MMIO=y +CONFIG_REGULATOR=y +CONFIG_REGULATOR_QCOM_RPM=y +# CONFIG_REGULATOR_QCOM_SPMI is not set +CONFIG_RESET_CONTROLLER=y +CONFIG_RFS_ACCEL=y +CONFIG_RPS=y +CONFIG_RTC_CLASS=y +# CONFIG_RTC_DRV_CMOS is not set +CONFIG_RWSEM_SPIN_ON_OWNER=y +CONFIG_RWSEM_XCHGADD_ALGORITHM=y +CONFIG_SCHED_HRTICK=y +# CONFIG_SCSI_DMA is not set +# CONFIG_SERIAL_AMBA_PL010 is not set +# CONFIG_SERIAL_AMBA_PL011 is not set +CONFIG_SERIAL_MSM=y +CONFIG_SERIAL_MSM_CONSOLE=y +# CONFIG_SLAB is not set +CONFIG_SLUB=y +CONFIG_SLUB_CPU_PARTIAL=y +CONFIG_SMP=y +CONFIG_SMP_ON_UP=y +CONFIG_SPARSE_IRQ=y +CONFIG_SPI=y +CONFIG_SPI_MASTER=y +CONFIG_SPI_QUP=y +CONFIG_SPMI=y +CONFIG_SPMI_MSM_PMIC_ARB=y +CONFIG_SRCU=y +CONFIG_STMMAC_ETH=y +CONFIG_STMMAC_PLATFORM=y +CONFIG_STOP_MACHINE=y +# CONFIG_STRIP_ASM_SYMS is not set +CONFIG_SUSPEND=y +CONFIG_SUSPEND_FREEZER=y +CONFIG_SWCONFIG=y +CONFIG_SWIOTLB=y +CONFIG_SWP_EMULATE=y +CONFIG_SYS_SUPPORTS_APM_EMULATION=y +CONFIG_THERMAL=y +# CONFIG_THERMAL_DEFAULT_GOV_FAIR_SHARE is not set +CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE=y +# CONFIG_THERMAL_DEFAULT_GOV_USER_SPACE is not set +# CONFIG_THERMAL_EMULATION is not set +# CONFIG_THERMAL_GOV_FAIR_SHARE is not set +CONFIG_THERMAL_GOV_STEP_WISE=y +# CONFIG_THERMAL_GOV_USER_SPACE is not set +CONFIG_THERMAL_HWMON=y +CONFIG_THERMAL_OF=y +# CONFIG_THUMB2_KERNEL is not set +CONFIG_TICK_CPU_ACCOUNTING=y +CONFIG_TIMER_STATS=y +CONFIG_UBIFS_FS=y +# CONFIG_UBIFS_FS_ADVANCED_COMPR is not set +CONFIG_UBIFS_FS_LZO=y +CONFIG_UBIFS_FS_XZ=y +CONFIG_UBIFS_FS_ZLIB=y +CONFIG_UEVENT_HELPER_PATH="" +CONFIG_UID16=y +CONFIG_UNCOMPRESS_INCLUDE="debug/uncompress.h" +CONFIG_UNINLINE_SPIN_UNLOCK=y +CONFIG_USB_SUPPORT=y +CONFIG_USE_OF=y +CONFIG_VDSO=y +CONFIG_VECTORS_BASE=0xffff0000 +CONFIG_VFP=y +CONFIG_VFPv3=y +CONFIG_VM_EVENT_COUNTERS=y +CONFIG_WATCHDOG_CORE=y +# CONFIG_WIZNET_W5100 is not set +# CONFIG_WIZNET_W5300 is not set +# CONFIG_WL_TI is not set +# CONFIG_WQ_POWER_EFFICIENT_DEFAULT is not set +CONFIG_XPS=y +CONFIG_XZ_DEC_ARM=y +CONFIG_XZ_DEC_BCJ=y +CONFIG_ZBOOT_ROM_BSS=0 +CONFIG_ZBOOT_ROM_TEXT=0 +CONFIG_ZLIB_DEFLATE=y +CONFIG_ZLIB_INFLATE=y +CONFIG_ZONE_DMA_FLAG=0 diff --git a/target/linux/ipq806x/patches-4.4/020-add-ap148-bootargs.patch b/target/linux/ipq806x/patches-4.4/020-add-ap148-bootargs.patch new file mode 100644 index 0000000..9c33bad --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/020-add-ap148-bootargs.patch @@ -0,0 +1,61 @@ +--- a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts ++++ b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts +@@ -4,14 +4,6 @@ + model = "Qualcomm IPQ8064/AP148"; + compatible = "qcom,ipq8064-ap148", "qcom,ipq8064"; + +- aliases { +- serial0 = &gsbi4_serial; +- }; +- +- chosen { +- stdout-path = "serial0:115200n8"; +- }; +- + reserved-memory { + #address-cells = <1>; + #size-cells = <1>; +@@ -22,6 +14,14 @@ + }; + }; + ++ alias { ++ serial0 = &uart4; ++ }; ++ ++ chosen { ++ linux,stdout-path = "serial0:115200n8"; ++ }; ++ + soc { + pinmux at 800000 { + i2c4_pins: i2c4_pinmux { +--- a/arch/arm/boot/dts/qcom-ipq8064.dtsi ++++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi +@@ -159,7 +159,7 @@ + + syscon-tcsr = <&tcsr>; + +- serial at 12490000 { ++ uart2: serial at 12490000 { + compatible = "qcom,msm-uartdm-v1.3", "qcom,msm-uartdm"; + reg = <0x12490000 0x1000>, + <0x12480000 0x1000>; +@@ -197,7 +197,7 @@ + + syscon-tcsr = <&tcsr>; + +- gsbi4_serial: serial at 16340000 { ++ uart4: serial at 16340000 { + compatible = "qcom,msm-uartdm-v1.3", "qcom,msm-uartdm"; + reg = <0x16340000 0x1000>, + <0x16300000 0x1000>; +@@ -234,7 +234,7 @@ + + syscon-tcsr = <&tcsr>; + +- serial at 1a240000 { ++ uart5: serial at 1a240000 { + compatible = "qcom,msm-uartdm-v1.3", "qcom,msm-uartdm"; + reg = <0x1a240000 0x1000>, + <0x1a200000 0x1000>; diff --git a/target/linux/ipq806x/patches-4.4/021-add-ap148-partitions.patch b/target/linux/ipq806x/patches-4.4/021-add-ap148-partitions.patch new file mode 100644 index 0000000..bfdb30f --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/021-add-ap148-partitions.patch @@ -0,0 +1,19 @@ +--- a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts ++++ b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts +@@ -77,15 +77,7 @@ + spi-max-frequency = <50000000>; + reg = <0>; + +- partition at 0 { +- label = "rootfs"; +- reg = <0x0 0x1000000>; +- }; +- +- partition at 1 { +- label = "scratch"; +- reg = <0x1000000 0x1000000>; +- }; ++ linux,part-probe = "qcom-smem"; + }; + }; + }; diff --git a/target/linux/ipq806x/patches-4.4/022-add-db149-dts.patch b/target/linux/ipq806x/patches-4.4/022-add-db149-dts.patch new file mode 100644 index 0000000..4d3e827 --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/022-add-db149-dts.patch @@ -0,0 +1,160 @@ +From f26cc3733bdd697bd81ae505fc133fa7c9b6ea19 Mon Sep 17 00:00:00 2001 +From: Mathieu Olivari +Date: Tue, 7 Apr 2015 19:58:58 -0700 +Subject: [PATCH] ARM: dts: qcom: add initial DB149 device-tree + +Add basic DB149 (IPQ806x based platform) device-tree. It supports UART, +SATA, USB2, USB3 and NOR flash. + +Signed-off-by: Mathieu Olivari +--- + arch/arm/boot/dts/Makefile | 1 + + arch/arm/boot/dts/qcom-ipq8064-db149.dts | 132 +++++++++++++++++++++++++++++++ + 2 files changed, 133 insertions(+) + create mode 100644 arch/arm/boot/dts/qcom-ipq8064-db149.dts + +--- a/arch/arm/boot/dts/Makefile ++++ b/arch/arm/boot/dts/Makefile +@@ -506,6 +506,7 @@ + qcom-apq8084-ifc6540.dtb \ + qcom-apq8084-mtp.dtb \ + qcom-ipq8064-ap148.dtb \ ++ qcom-ipq8064-db149.dtb \ + qcom-msm8660-surf.dtb \ + qcom-msm8960-cdp.dtb \ + qcom-msm8974-sony-xperia-honami.dtb +--- /dev/null ++++ b/arch/arm/boot/dts/qcom-ipq8064-db149.dts +@@ -0,0 +1,132 @@ ++#include "qcom-ipq8064-v1.0.dtsi" ++ ++/ { ++ model = "Qualcomm IPQ8064/DB149"; ++ compatible = "qcom,ipq8064-db149", "qcom,ipq8064"; ++ ++ reserved-memory { ++ #address-cells = <1>; ++ #size-cells = <1>; ++ ranges; ++ rsvd at 41200000 { ++ reg = <0x41200000 0x300000>; ++ no-map; ++ }; ++ }; ++ ++ alias { ++ serial0 = &uart2; ++ }; ++ ++ chosen { ++ linux,stdout-path = "serial0:115200n8"; ++ }; ++ ++ soc { ++ pinmux at 800000 { ++ i2c4_pins: i2c4_pinmux { ++ pins = "gpio12", "gpio13"; ++ function = "gsbi4"; ++ bias-disable; ++ }; ++ ++ spi_pins: spi_pins { ++ mux { ++ pins = "gpio18", "gpio19", "gpio21"; ++ function = "gsbi5"; ++ drive-strength = <10>; ++ bias-none; ++ }; ++ }; ++ }; ++ ++ gsbi2: gsbi at 12480000 { ++ qcom,mode = ; ++ status = "ok"; ++ uart2: serial at 12490000 { ++ status = "ok"; ++ }; ++ }; ++ ++ gsbi5: gsbi at 1a200000 { ++ qcom,mode = ; ++ status = "ok"; ++ ++ spi4: spi at 1a280000 { ++ status = "ok"; ++ spi-max-frequency = <50000000>; ++ ++ pinctrl-0 = <&spi_pins>; ++ pinctrl-names = "default"; ++ ++ cs-gpios = <&qcom_pinmux 20 0>; ++ ++ flash: m25p80 at 0 { ++ compatible = "s25fl256s1"; ++ #address-cells = <1>; ++ #size-cells = <1>; ++ spi-max-frequency = <50000000>; ++ reg = <0>; ++ m25p,fast-read; ++ ++ partition at 0 { ++ label = "lowlevel_init"; ++ reg = <0x0 0x1b0000>; ++ }; ++ ++ partition at 1 { ++ label = "u-boot"; ++ reg = <0x1b0000 0x80000>; ++ }; ++ ++ partition at 2 { ++ label = "u-boot-env"; ++ reg = <0x230000 0x40000>; ++ }; ++ ++ partition at 3 { ++ label = "caldata"; ++ reg = <0x270000 0x40000>; ++ }; ++ ++ partition at 4 { ++ label = "firmware"; ++ reg = <0x2b0000 0x1d50000>; ++ }; ++ }; ++ }; ++ }; ++ ++ sata-phy at 1b400000 { ++ status = "ok"; ++ }; ++ ++ sata at 29000000 { ++ status = "ok"; ++ }; ++ ++ phy at 100f8800 { /* USB3 port 1 HS phy */ ++ status = "ok"; ++ }; ++ ++ phy at 100f8830 { /* USB3 port 1 SS phy */ ++ status = "ok"; ++ }; ++ ++ phy at 110f8800 { /* USB3 port 0 HS phy */ ++ status = "ok"; ++ }; ++ ++ phy at 110f8830 { /* USB3 port 0 SS phy */ ++ status = "ok"; ++ }; ++ ++ usb30 at 0 { ++ status = "ok"; ++ }; ++ ++ usb30 at 1 { ++ status = "ok"; ++ }; ++ }; ++}; diff --git a/target/linux/ipq806x/patches-4.4/023-ARM-dts-ipq806x-Disable-i2c-device-on-gsbi4.patch b/target/linux/ipq806x/patches-4.4/023-ARM-dts-ipq806x-Disable-i2c-device-on-gsbi4.patch new file mode 100644 index 0000000..b8c527b --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/023-ARM-dts-ipq806x-Disable-i2c-device-on-gsbi4.patch @@ -0,0 +1,52 @@ +--- a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts ++++ b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts +@@ -47,14 +47,12 @@ + status = "ok"; + }; + +- i2c4: i2c at 16380000 { +- status = "ok"; +- +- clock-frequency = <200000>; +- +- pinctrl-0 = <&i2c4_pins>; +- pinctrl-names = "default"; +- }; ++ /* ++ * The i2c device on gsbi4 should not be enabled. ++ * On ipq806x designs gsbi4 i2c is meant for exclusive ++ * RPM usage. Turning this on in kernel manifests as ++ * i2c failure for the RPM. ++ */ + }; + + gsbi5: gsbi at 1a200000 { +--- a/drivers/clk/qcom/gcc-ipq806x.c ++++ b/drivers/clk/qcom/gcc-ipq806x.c +@@ -294,7 +294,7 @@ + .parent_names = gcc_pxo_pll8, + .num_parents = 2, + .ops = &clk_rcg_ops, +- .flags = CLK_SET_PARENT_GATE, ++ .flags = CLK_SET_PARENT_GATE | CLK_IGNORE_UNUSED, + }, + }, + }; +@@ -312,7 +312,7 @@ + }, + .num_parents = 1, + .ops = &clk_branch_ops, +- .flags = CLK_SET_RATE_PARENT, ++ .flags = CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, + }, + }, + }; +@@ -890,7 +890,7 @@ + .hw.init = &(struct clk_init_data){ + .name = "gsbi1_h_clk", + .ops = &clk_branch_ops, +- .flags = CLK_IS_ROOT, ++ .flags = CLK_IS_ROOT | CLK_IGNORE_UNUSED, + }, + }, + }; diff --git a/target/linux/ipq806x/patches-4.4/024-ap148-add-memory-node.patch b/target/linux/ipq806x/patches-4.4/024-ap148-add-memory-node.patch new file mode 100644 index 0000000..f026ed9 --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/024-ap148-add-memory-node.patch @@ -0,0 +1,14 @@ +--- a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts ++++ b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts +@@ -4,6 +4,11 @@ + model = "Qualcomm IPQ8064/AP148"; + compatible = "qcom,ipq8064-ap148", "qcom,ipq8064"; + ++ memory at 0 { ++ reg = <0x42000000 0x1e000000>; ++ device_type = "memory"; ++ }; ++ + reserved-memory { + #address-cells = <1>; + #size-cells = <1>; diff --git a/target/linux/ipq806x/patches-4.4/033-ARM-qcom-add-SFPB-nodes-to-IPQ806x-dts.patch b/target/linux/ipq806x/patches-4.4/033-ARM-qcom-add-SFPB-nodes-to-IPQ806x-dts.patch new file mode 100644 index 0000000..e1d317d --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/033-ARM-qcom-add-SFPB-nodes-to-IPQ806x-dts.patch @@ -0,0 +1,33 @@ +From c7c482da19a5e4ba7101198c21c2434056b0b2da Mon Sep 17 00:00:00 2001 +From: Mathieu Olivari +Date: Thu, 13 Aug 2015 09:45:26 -0700 +Subject: [PATCH 1/3] ARM: qcom: add SFPB nodes to IPQ806x dts + +Add one new node to the ipq806x.dtsi file to declare & register the +hardware spinlock devices. This mechanism is required to be used by +other drivers such as SMEM. + +Signed-off-by: Mathieu Olivari +--- + arch/arm/boot/dts/qcom-ipq8064.dtsi | 11 +++++++++++ + 1 file changed, 11 insertions(+) + +--- a/arch/arm/boot/dts/qcom-ipq8064.dtsi ++++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi +@@ -329,5 +329,16 @@ + #reset-cells = <1>; + }; + ++ sfpb_mutex_block: syscon at 1200600 { ++ compatible = "syscon"; ++ reg = <0x01200600 0x100>; ++ }; ++ }; ++ ++ sfpb_mutex: sfpb-mutex { ++ compatible = "qcom,sfpb-mutex"; ++ syscon = <&sfpb_mutex_block 4 4>; ++ ++ #hwlock-cells = <1>; + }; + }; diff --git a/target/linux/ipq806x/patches-4.4/036-ARM-qcom-add-SMEM-device-node-to-IPQ806x-dts.patch b/target/linux/ipq806x/patches-4.4/036-ARM-qcom-add-SMEM-device-node-to-IPQ806x-dts.patch new file mode 100644 index 0000000..06b1405 --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/036-ARM-qcom-add-SMEM-device-node-to-IPQ806x-dts.patch @@ -0,0 +1,36 @@ +From f212be3a6134db8dd7c5f6f0987536a669401fae Mon Sep 17 00:00:00 2001 +From: Mathieu Olivari +Date: Fri, 14 Aug 2015 11:17:20 -0700 +Subject: [PATCH 2/3] ARM: qcom: add SMEM device node to IPQ806x dts + +SMEM is used on IPQ806x to store various board related information such +as boot device and flash partition layout. We'll declare it as a device +so we can make use of it thanks to the new SMEM soc driver. + +Signed-off-by: Mathieu Olivari +--- + arch/arm/boot/dts/qcom-ipq8064.dtsi | 8 +++++++- + 1 file changed, 7 insertions(+), 1 deletion(-) + +--- a/arch/arm/boot/dts/qcom-ipq8064.dtsi ++++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi +@@ -55,7 +55,7 @@ + no-map; + }; + +- smem at 41000000 { ++ smem: smem at 41000000 { + reg = <0x41000000 0x200000>; + no-map; + }; +@@ -341,4 +341,10 @@ + + #hwlock-cells = <1>; + }; ++ ++ smem { ++ compatible = "qcom,smem"; ++ memory-region = <&smem>; ++ hwlocks = <&sfpb_mutex 3>; ++ }; + }; diff --git a/target/linux/ipq806x/patches-4.4/037-mtd-add-SMEM-parser-for-QCOM-platforms.patch b/target/linux/ipq806x/patches-4.4/037-mtd-add-SMEM-parser-for-QCOM-platforms.patch new file mode 100644 index 0000000..d80eb86 --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/037-mtd-add-SMEM-parser-for-QCOM-platforms.patch @@ -0,0 +1,282 @@ +From 61e8e1b1af77f24339da3f0822a76fa65ed635c6 Mon Sep 17 00:00:00 2001 +From: Mathieu Olivari +Date: Thu, 13 Aug 2015 09:53:14 -0700 +Subject: [PATCH] mtd: add SMEM parser for QCOM platforms + +On QCOM platforms using MTD devices storage (such as IPQ806x), SMEM is +used to store partition layout. This new parser can now be used to read +SMEM and use it to register an MTD layout according to its content. + +Signed-off-by: Mathieu Olivari +Signed-off-by: Ram Chandra Jangir +--- + drivers/mtd/Kconfig | 7 ++ + drivers/mtd/Makefile | 1 + + drivers/mtd/qcom_smem_part.c | 228 +++++++++++++++++++++++++++++++++++++++++++ + 3 files changed, 236 insertions(+) + create mode 100644 drivers/mtd/qcom_smem_part.c + +diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig +index a03ad29..debc887 100644 +--- a/drivers/mtd/Kconfig ++++ b/drivers/mtd/Kconfig +@@ -190,6 +190,13 @@ + You will still need the parsing functions to be called by the driver + for your particular device. It won't happen automatically. + ++config MTD_QCOM_SMEM_PARTS ++ tristate "QCOM SMEM partitioning support" ++ depends on QCOM_SMEM ++ help ++ This provides partitions parser for QCOM devices using SMEM ++ such as IPQ806x. ++ + comment "User Modules And Translation Layers" + + # +diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile +index 99bb9a1..2a44a64 100644 +--- a/drivers/mtd/Makefile ++++ b/drivers/mtd/Makefile +@@ -16,6 +16,7 @@ + obj-$(CONFIG_MTD_BCM63XX_PARTS) += bcm63xxpart.o + obj-$(CONFIG_MTD_BCM47XX_PARTS) += bcm47xxpart.o + obj-$(CONFIG_MTD_MYLOADER_PARTS) += myloader.o ++obj-$(CONFIG_MTD_QCOM_SMEM_PARTS) += qcom_smem_part.o + + # 'Users' - code which presents functionality to userspace. + obj-$(CONFIG_MTD_BLKDEVS) += mtd_blkdevs.o +diff --git a/drivers/mtd/qcom_smem_part.c b/drivers/mtd/qcom_smem_part.c +new file mode 100644 +index 0000000..f9c1bca +--- /dev/null ++++ b/drivers/mtd/qcom_smem_part.c +@@ -0,0 +1,228 @@ ++/* ++ * Copyright (c) 2015, The Linux Foundation. All rights reserved. ++ * ++ * This program is free software; you can redistribute it and/or modify ++ * it under the terms of the GNU General Public License version 2 and ++ * only version 2 as published by the Free Software Foundation. ++ * ++ * 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. ++ */ ++ ++#include ++#include ++#include ++ ++#include ++#include ++#include ++#include ++ ++#include ++ ++/* Processor/host identifier for the application processor */ ++#define SMEM_HOST_APPS 0 ++ ++/* SMEM items index */ ++#define SMEM_AARM_PARTITION_TABLE 9 ++#define SMEM_BOOT_FLASH_TYPE 421 ++#define SMEM_BOOT_FLASH_BLOCK_SIZE 424 ++ ++/* SMEM Flash types */ ++#define SMEM_FLASH_NAND 2 ++#define SMEM_FLASH_SPI 6 ++ ++#define SMEM_PART_NAME_SZ 16 ++#define SMEM_PARTS_MAX 32 ++ ++struct smem_partition { ++ char name[SMEM_PART_NAME_SZ]; ++ __le32 start; ++ __le32 size; ++ __le32 attr; ++}; ++ ++struct smem_partition_table { ++ u8 magic[8]; ++ __le32 version; ++ __le32 len; ++ struct smem_partition parts[SMEM_PARTS_MAX]; ++}; ++ ++/* SMEM Magic values in partition table */ ++static const u8 SMEM_PTABLE_MAGIC[] = { ++ 0xaa, 0x73, 0xee, 0x55, ++ 0xdb, 0xbd, 0x5e, 0xe3, ++}; ++ ++static int qcom_smem_get_flash_blksz(u64 **smem_blksz) ++{ ++ size_t size; ++ ++ *smem_blksz = qcom_smem_get(SMEM_HOST_APPS, SMEM_BOOT_FLASH_BLOCK_SIZE, ++ &size); ++ ++ if (IS_ERR(*smem_blksz)) { ++ pr_err("Unable to read flash blksz from SMEM\n"); ++ return -ENOENT; ++ } ++ ++ if (size != sizeof(**smem_blksz)) { ++ pr_err("Invalid flash blksz size in SMEM\n"); ++ return -EINVAL; ++ } ++ ++ return 0; ++} ++ ++static int qcom_smem_get_flash_type(u64 **smem_flash_type) ++{ ++ size_t size; ++ ++ *smem_flash_type = qcom_smem_get(SMEM_HOST_APPS, SMEM_BOOT_FLASH_TYPE, ++ &size); ++ ++ if (IS_ERR(*smem_flash_type)) { ++ pr_err("Unable to read flash type from SMEM\n"); ++ return -ENOENT; ++ } ++ ++ if (size != sizeof(**smem_flash_type)) { ++ pr_err("Invalid flash type size in SMEM\n"); ++ return -EINVAL; ++ } ++ ++ return 0; ++} ++ ++static int qcom_smem_get_flash_partitions(struct smem_partition_table **pparts) ++{ ++ size_t size; ++ ++ *pparts = qcom_smem_get(SMEM_HOST_APPS, SMEM_AARM_PARTITION_TABLE, ++ &size); ++ ++ if (IS_ERR(*pparts)) { ++ pr_err("Unable to read partition table from SMEM\n"); ++ return -ENOENT; ++ } ++ ++ return 0; ++} ++ ++static int of_dev_node_match(struct device *dev, void *data) ++{ ++ return dev->of_node == data; ++} ++ ++static bool is_spi_device(struct device_node *np) ++{ ++ struct device *dev; ++ ++ dev = bus_find_device(&spi_bus_type, NULL, np, of_dev_node_match); ++ if (!dev) ++ return false; ++ ++ put_device(dev); ++ return true; ++} ++ ++static int parse_qcom_smem_partitions(struct mtd_info *master, ++ struct mtd_partition **pparts, ++ struct mtd_part_parser_data *data) ++{ ++ struct smem_partition_table *smem_parts; ++ u64 *smem_flash_type, *smem_blksz; ++ struct mtd_partition *mtd_parts; ++ struct device_node *of_node = data->of_node; ++ int i, ret; ++ ++ /* ++ * SMEM will only store the partition table of the boot device. ++ * If this is not the boot device, do not return any partition. ++ */ ++ ret = qcom_smem_get_flash_type(&smem_flash_type); ++ if (ret < 0) ++ return ret; ++ ++ if ((*smem_flash_type == SMEM_FLASH_NAND && !mtd_type_is_nand(master)) ++ || (*smem_flash_type == SMEM_FLASH_SPI && !is_spi_device(of_node))) ++ return 0; ++ ++ /* ++ * Just for sanity purpose, make sure the block size in SMEM matches the ++ * block size of the MTD device ++ */ ++ ret = qcom_smem_get_flash_blksz(&smem_blksz); ++ if (ret < 0) ++ return ret; ++ ++ if (*smem_blksz != master->erasesize) { ++ pr_err("SMEM block size differs from MTD block size\n"); ++ return -EINVAL; ++ } ++ ++ /* Get partition pointer from SMEM */ ++ ret = qcom_smem_get_flash_partitions(&smem_parts); ++ if (ret < 0) ++ return ret; ++ ++ if (memcmp(SMEM_PTABLE_MAGIC, smem_parts->magic, ++ sizeof(SMEM_PTABLE_MAGIC))) { ++ pr_err("SMEM partition magic invalid\n"); ++ return -EINVAL; ++ } ++ ++ /* Allocate and populate the mtd structures */ ++ mtd_parts = kcalloc(le32_to_cpu(smem_parts->len), sizeof(*mtd_parts), ++ GFP_KERNEL); ++ if (!mtd_parts) ++ return -ENOMEM; ++ ++ for (i = 0; i < smem_parts->len; i++) { ++ struct smem_partition *s_part = &smem_parts->parts[i]; ++ struct mtd_partition *m_part = &mtd_parts[i]; ++ ++ m_part->name = s_part->name; ++ m_part->size = le32_to_cpu(s_part->size) * (*smem_blksz); ++ m_part->offset = le32_to_cpu(s_part->start) * (*smem_blksz); ++ ++ /* ++ * The last SMEM partition may have its size marked as ++ * something like 0xffffffff, which means "until the end of the ++ * flash device". In this case, truncate it. ++ */ ++ if (m_part->offset + m_part->size > master->size) ++ m_part->size = master->size - m_part->offset; ++ } ++ ++ *pparts = mtd_parts; ++ ++ return smem_parts->len; ++} ++ ++static struct mtd_part_parser qcom_smem_parser = { ++ .owner = THIS_MODULE, ++ .parse_fn = parse_qcom_smem_partitions, ++ .name = "qcom-smem", ++}; ++ ++static int __init qcom_smem_parser_init(void) ++{ ++ register_mtd_parser(&qcom_smem_parser); ++ return 0; ++} ++ ++static void __exit qcom_smem_parser_exit(void) ++{ ++ deregister_mtd_parser(&qcom_smem_parser); ++} ++ ++module_init(qcom_smem_parser_init); ++module_exit(qcom_smem_parser_exit); ++ ++MODULE_LICENSE("GPL"); ++MODULE_AUTHOR("Mathieu Olivari "); ++MODULE_DESCRIPTION("Parsing code for SMEM based partition tables"); diff --git a/target/linux/ipq806x/patches-4.4/100-usb-phy-Add-Qualcomm-DWC3-HS-SS-PHY-drivers.patch b/target/linux/ipq806x/patches-4.4/100-usb-phy-Add-Qualcomm-DWC3-HS-SS-PHY-drivers.patch new file mode 100644 index 0000000..68f2b39 --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/100-usb-phy-Add-Qualcomm-DWC3-HS-SS-PHY-drivers.patch @@ -0,0 +1,510 @@ +--- a/drivers/phy/Kconfig ++++ b/drivers/phy/Kconfig +@@ -390,4 +390,15 @@ + Enable this to support the Broadcom Cygnus PCIe PHY. + If unsure, say N. + ++config PHY_QCOM_DWC3 ++ tristate "QCOM DWC3 USB PHY support" ++ depends on ARCH_QCOM ++ depends on HAS_IOMEM ++ depends on OF ++ select GENERIC_PHY ++ help ++ This option enables support for the Synopsis PHYs present inside the ++ Qualcomm USB3.0 DWC3 controller. This driver supports both HS and SS ++ PHY controllers. ++ + endmenu +--- a/drivers/phy/Makefile ++++ b/drivers/phy/Makefile +@@ -48,3 +48,4 @@ obj-$(CONFIG_PHY_TUSB1210) += + obj-$(CONFIG_PHY_BRCMSTB_SATA) += phy-brcmstb-sata.o + obj-$(CONFIG_PHY_PISTACHIO_USB) += phy-pistachio-usb.o + obj-$(CONFIG_PHY_CYGNUS_PCIE) += phy-bcm-cygnus-pcie.o ++obj-$(CONFIG_PHY_QCOM_DWC3) += phy-qcom-dwc3.o +--- /dev/null ++++ b/drivers/phy/phy-qcom-dwc3.c +@@ -0,0 +1,482 @@ ++/* Copyright (c) 2013-2014, Code Aurora Forum. All rights reserved. ++ * ++ * This program is free software; you can redistribute it and/or modify ++ * it under the terms of the GNU General Public License version 2 and ++ * only version 2 as published by the Free Software Foundation. ++ * ++ * 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. ++ */ ++ ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++ ++/** ++ * USB QSCRATCH Hardware registers ++ */ ++#define QSCRATCH_GENERAL_CFG (0x08) ++#define HSUSB_PHY_CTRL_REG (0x10) ++ ++/* PHY_CTRL_REG */ ++#define HSUSB_CTRL_DMSEHV_CLAMP BIT(24) ++#define HSUSB_CTRL_USB2_SUSPEND BIT(23) ++#define HSUSB_CTRL_UTMI_CLK_EN BIT(21) ++#define HSUSB_CTRL_UTMI_OTG_VBUS_VALID BIT(20) ++#define HSUSB_CTRL_USE_CLKCORE BIT(18) ++#define HSUSB_CTRL_DPSEHV_CLAMP BIT(17) ++#define HSUSB_CTRL_COMMONONN BIT(11) ++#define HSUSB_CTRL_ID_HV_CLAMP BIT(9) ++#define HSUSB_CTRL_OTGSESSVLD_CLAMP BIT(8) ++#define HSUSB_CTRL_CLAMP_EN BIT(7) ++#define HSUSB_CTRL_RETENABLEN BIT(1) ++#define HSUSB_CTRL_POR BIT(0) ++ ++/* QSCRATCH_GENERAL_CFG */ ++#define HSUSB_GCFG_XHCI_REV BIT(2) ++ ++/** ++ * USB QSCRATCH Hardware registers ++ */ ++#define SSUSB_PHY_CTRL_REG (0x00) ++#define SSUSB_PHY_PARAM_CTRL_1 (0x04) ++#define SSUSB_PHY_PARAM_CTRL_2 (0x08) ++#define CR_PROTOCOL_DATA_IN_REG (0x0c) ++#define CR_PROTOCOL_DATA_OUT_REG (0x10) ++#define CR_PROTOCOL_CAP_ADDR_REG (0x14) ++#define CR_PROTOCOL_CAP_DATA_REG (0x18) ++#define CR_PROTOCOL_READ_REG (0x1c) ++#define CR_PROTOCOL_WRITE_REG (0x20) ++ ++/* PHY_CTRL_REG */ ++#define SSUSB_CTRL_REF_USE_PAD BIT(28) ++#define SSUSB_CTRL_TEST_POWERDOWN BIT(27) ++#define SSUSB_CTRL_LANE0_PWR_PRESENT BIT(24) ++#define SSUSB_CTRL_SS_PHY_EN BIT(8) ++#define SSUSB_CTRL_SS_PHY_RESET BIT(7) ++ ++/* SSPHY control registers */ ++#define SSPHY_CTRL_RX_OVRD_IN_HI(lane) (0x1006 + 0x100 * lane) ++#define SSPHY_CTRL_TX_OVRD_DRV_LO(lane) (0x1002 + 0x100 * lane) ++ ++/* RX OVRD IN HI bits */ ++#define RX_OVRD_IN_HI_RX_RESET_OVRD BIT(13) ++#define RX_OVRD_IN_HI_RX_RX_RESET BIT(12) ++#define RX_OVRD_IN_HI_RX_EQ_OVRD BIT(11) ++#define RX_OVRD_IN_HI_RX_EQ_MASK 0x0700 ++#define RX_OVRD_IN_HI_RX_EQ_SHIFT 8 ++#define RX_OVRD_IN_HI_RX_EQ_EN_OVRD BIT(7) ++#define RX_OVRD_IN_HI_RX_EQ_EN BIT(6) ++#define RX_OVRD_IN_HI_RX_LOS_FILTER_OVRD BIT(5) ++#define RX_OVRD_IN_HI_RX_LOS_FILTER_MASK 0x0018 ++#define RX_OVRD_IN_HI_RX_RATE_OVRD BIT(2) ++#define RX_OVRD_IN_HI_RX_RATE_MASK 0x0003 ++ ++/* TX OVRD DRV LO register bits */ ++#define TX_OVRD_DRV_LO_AMPLITUDE_MASK 0x007F ++#define TX_OVRD_DRV_LO_PREEMPH_MASK 0x3F80 ++#define TX_OVRD_DRV_LO_PREEMPH_SHIFT 7 ++#define TX_OVRD_DRV_LO_EN BIT(14) ++ ++struct qcom_dwc3_usb_phy { ++ void __iomem *base; ++ struct device *dev; ++ struct phy *phy; ++ ++ int (*phy_init)(struct qcom_dwc3_usb_phy *phy_dwc3); ++ int (*phy_exit)(struct qcom_dwc3_usb_phy *phy_dwc3); ++ ++ struct clk *xo_clk; ++ struct clk *ref_clk; ++}; ++ ++/** ++ * Write register and read back masked value to confirm it is written ++ * ++ * @base - QCOM DWC3 PHY base virtual address. ++ * @offset - register offset. ++ * @mask - register bitmask specifying what should be updated ++ * @val - value to write. ++ */ ++static inline void qcom_dwc3_phy_write_readback( ++ struct qcom_dwc3_usb_phy *phy_dwc3, u32 offset, ++ const u32 mask, u32 val) ++{ ++ u32 write_val, tmp = readl(phy_dwc3->base + offset); ++ ++ tmp &= ~mask; /* retain other bits */ ++ write_val = tmp | val; ++ ++ writel(write_val, phy_dwc3->base + offset); ++ ++ /* Read back to see if val was written */ ++ tmp = readl(phy_dwc3->base + offset); ++ tmp &= mask; /* clear other bits */ ++ ++ if (tmp != val) ++ dev_err(phy_dwc3->dev, "write: %x to QSCRATCH: %x FAILED\n", ++ val, offset); ++} ++ ++static int wait_for_latch(void __iomem *addr) ++{ ++ u32 retry = 10; ++ ++ while (true) { ++ if (!readl(addr)) ++ break; ++ ++ if (--retry == 0) ++ return -ETIMEDOUT; ++ ++ usleep_range(10, 20); ++ } ++ ++ return 0; ++} ++ ++/** ++ * Write SSPHY register ++ * ++ * @base - QCOM DWC3 PHY base virtual address. ++ * @addr - SSPHY address to write. ++ * @val - value to write. ++ */ ++static int qcom_dwc3_ss_write_phycreg(void __iomem *base, u32 addr, u32 val) ++{ ++ int ret; ++ ++ writel(addr, base + CR_PROTOCOL_DATA_IN_REG); ++ writel(0x1, base + CR_PROTOCOL_CAP_ADDR_REG); ++ ++ ret = wait_for_latch(base + CR_PROTOCOL_CAP_ADDR_REG); ++ if (ret) ++ goto err_wait; ++ ++ writel(val, base + CR_PROTOCOL_DATA_IN_REG); ++ writel(0x1, base + CR_PROTOCOL_CAP_DATA_REG); ++ ++ ret = wait_for_latch(base + CR_PROTOCOL_CAP_DATA_REG); ++ if (ret) ++ goto err_wait; ++ ++ writel(0x1, base + CR_PROTOCOL_WRITE_REG); ++ ++ ret = wait_for_latch(base + CR_PROTOCOL_WRITE_REG); ++ ++err_wait: ++ return ret; ++} ++ ++/** ++ * Read SSPHY register. ++ * ++ * @base - QCOM DWC3 PHY base virtual address. ++ * @addr - SSPHY address to read. ++ */ ++static int qcom_dwc3_ss_read_phycreg(void __iomem *base, u32 addr, u32 *val) ++{ ++ int ret; ++ bool first_read = true; ++ ++ writel(addr, base + CR_PROTOCOL_DATA_IN_REG); ++ writel(0x1, base + CR_PROTOCOL_CAP_ADDR_REG); ++ ++ ret = wait_for_latch(base + CR_PROTOCOL_CAP_ADDR_REG); ++ if (ret) ++ goto err_wait; ++ ++ /* ++ * Due to hardware bug, first read of SSPHY register might be ++ * incorrect. Hence as workaround, SW should perform SSPHY register ++ * read twice, but use only second read and ignore first read. ++ */ ++retry: ++ writel(0x1, base + CR_PROTOCOL_READ_REG); ++ ++ ret = wait_for_latch(base + CR_PROTOCOL_READ_REG); ++ if (ret) ++ goto err_wait; ++ ++ if (first_read) { ++ readl(base + CR_PROTOCOL_DATA_OUT_REG); ++ first_read = false; ++ goto retry; ++ } ++ ++ *val = readl(base + CR_PROTOCOL_DATA_OUT_REG); ++ ++err_wait: ++ return ret; ++} ++ ++static int qcom_dwc3_phy_power_on(struct phy *phy) ++{ ++ int ret; ++ struct qcom_dwc3_usb_phy *phy_dwc3 = phy_get_drvdata(phy); ++ ++ ret = clk_prepare_enable(phy_dwc3->xo_clk); ++ if (ret) ++ return ret; ++ ++ ret = clk_prepare_enable(phy_dwc3->ref_clk); ++ if (ret) ++ clk_disable_unprepare(phy_dwc3->xo_clk); ++ ++ return ret; ++} ++ ++static int qcom_dwc3_phy_power_off(struct phy *phy) ++{ ++ struct qcom_dwc3_usb_phy *phy_dwc3 = phy_get_drvdata(phy); ++ ++ clk_disable_unprepare(phy_dwc3->ref_clk); ++ clk_disable_unprepare(phy_dwc3->xo_clk); ++ ++ return 0; ++} ++ ++static int qcom_dwc3_hs_phy_init(struct qcom_dwc3_usb_phy *phy_dwc3) ++{ ++ u32 val; ++ ++ /* ++ * HSPHY Initialization: Enable UTMI clock, select 19.2MHz fsel ++ * enable clamping, and disable RETENTION (power-on default is ENABLED) ++ */ ++ val = HSUSB_CTRL_DPSEHV_CLAMP | HSUSB_CTRL_DMSEHV_CLAMP | ++ HSUSB_CTRL_RETENABLEN | HSUSB_CTRL_COMMONONN | ++ HSUSB_CTRL_OTGSESSVLD_CLAMP | HSUSB_CTRL_ID_HV_CLAMP | ++ HSUSB_CTRL_DPSEHV_CLAMP | HSUSB_CTRL_UTMI_OTG_VBUS_VALID | ++ HSUSB_CTRL_UTMI_CLK_EN | HSUSB_CTRL_CLAMP_EN | 0x70; ++ ++ /* use core clock if external reference is not present */ ++ if (!phy_dwc3->xo_clk) ++ val |= HSUSB_CTRL_USE_CLKCORE; ++ ++ writel(val, phy_dwc3->base + HSUSB_PHY_CTRL_REG); ++ usleep_range(2000, 2200); ++ ++ /* Disable (bypass) VBUS and ID filters */ ++ writel(HSUSB_GCFG_XHCI_REV, phy_dwc3->base + QSCRATCH_GENERAL_CFG); ++ ++ return 0; ++} ++ ++static int qcom_dwc3_ss_phy_init(struct qcom_dwc3_usb_phy *phy_dwc3) ++{ ++ int ret; ++ u32 data = 0; ++ ++ /* reset phy */ ++ data = readl_relaxed(phy_dwc3->base + SSUSB_PHY_CTRL_REG); ++ writel_relaxed(data | SSUSB_CTRL_SS_PHY_RESET, ++ phy_dwc3->base + SSUSB_PHY_CTRL_REG); ++ usleep_range(2000, 2200); ++ writel_relaxed(data, phy_dwc3->base + SSUSB_PHY_CTRL_REG); ++ ++ /* clear REF_PAD if we don't have XO clk */ ++ if (!phy_dwc3->xo_clk) ++ data &= ~SSUSB_CTRL_REF_USE_PAD; ++ else ++ data |= SSUSB_CTRL_REF_USE_PAD; ++ ++ writel_relaxed(data, phy_dwc3->base + SSUSB_PHY_CTRL_REG); ++ msleep(30); ++ ++ data |= SSUSB_CTRL_SS_PHY_EN | SSUSB_CTRL_LANE0_PWR_PRESENT; ++ writel_relaxed(data, phy_dwc3->base + SSUSB_PHY_CTRL_REG); ++ ++ /* ++ * Fix RX Equalization setting as follows ++ * LANE0.RX_OVRD_IN_HI. RX_EQ_EN set to 0 ++ * LANE0.RX_OVRD_IN_HI.RX_EQ_EN_OVRD set to 1 ++ * LANE0.RX_OVRD_IN_HI.RX_EQ set to 3 ++ * LANE0.RX_OVRD_IN_HI.RX_EQ_OVRD set to 1 ++ */ ++ ret = qcom_dwc3_ss_read_phycreg(phy_dwc3->base, ++ SSPHY_CTRL_RX_OVRD_IN_HI(0), &data); ++ if (ret) ++ goto err_phy_trans; ++ ++ data &= ~RX_OVRD_IN_HI_RX_EQ_EN; ++ data |= RX_OVRD_IN_HI_RX_EQ_EN_OVRD; ++ data &= ~RX_OVRD_IN_HI_RX_EQ_MASK; ++ data |= 0x3 << RX_OVRD_IN_HI_RX_EQ_SHIFT; ++ data |= RX_OVRD_IN_HI_RX_EQ_OVRD; ++ ret = qcom_dwc3_ss_write_phycreg(phy_dwc3->base, ++ SSPHY_CTRL_RX_OVRD_IN_HI(0), data); ++ if (ret) ++ goto err_phy_trans; ++ ++ /* ++ * Set EQ and TX launch amplitudes as follows ++ * LANE0.TX_OVRD_DRV_LO.PREEMPH set to 22 ++ * LANE0.TX_OVRD_DRV_LO.AMPLITUDE set to 127 ++ * LANE0.TX_OVRD_DRV_LO.EN set to 1. ++ */ ++ ret = qcom_dwc3_ss_read_phycreg(phy_dwc3->base, ++ SSPHY_CTRL_TX_OVRD_DRV_LO(0), &data); ++ if (ret) ++ goto err_phy_trans; ++ ++ data &= ~TX_OVRD_DRV_LO_PREEMPH_MASK; ++ data |= 0x16 << TX_OVRD_DRV_LO_PREEMPH_SHIFT; ++ data &= ~TX_OVRD_DRV_LO_AMPLITUDE_MASK; ++ data |= 0x7f; ++ data |= TX_OVRD_DRV_LO_EN; ++ ret = qcom_dwc3_ss_write_phycreg(phy_dwc3->base, ++ SSPHY_CTRL_TX_OVRD_DRV_LO(0), data); ++ if (ret) ++ goto err_phy_trans; ++ ++ /* ++ * Set the QSCRATCH PHY_PARAM_CTRL1 parameters as follows ++ * TX_FULL_SWING [26:20] amplitude to 127 ++ * TX_DEEMPH_3_5DB [13:8] to 22 ++ * LOS_BIAS [2:0] to 0x5 ++ */ ++ qcom_dwc3_phy_write_readback(phy_dwc3, SSUSB_PHY_PARAM_CTRL_1, ++ 0x07f03f07, 0x07f01605); ++ ++err_phy_trans: ++ return ret; ++} ++ ++static int qcom_dwc3_ss_phy_exit(struct qcom_dwc3_usb_phy *phy_dwc3) ++{ ++ /* Sequence to put SSPHY in low power state: ++ * 1. Clear REF_PHY_EN in PHY_CTRL_REG ++ * 2. Clear REF_USE_PAD in PHY_CTRL_REG ++ * 3. Set TEST_POWERED_DOWN in PHY_CTRL_REG to enable PHY retention ++ * 4. Disable SSPHY ref clk ++ */ ++ qcom_dwc3_phy_write_readback(phy_dwc3, SSUSB_PHY_CTRL_REG, ++ SSUSB_CTRL_SS_PHY_EN, 0x0); ++ qcom_dwc3_phy_write_readback(phy_dwc3, SSUSB_PHY_CTRL_REG, ++ SSUSB_CTRL_REF_USE_PAD, 0x0); ++ qcom_dwc3_phy_write_readback(phy_dwc3, SSUSB_PHY_CTRL_REG, ++ 0x0, SSUSB_CTRL_TEST_POWERDOWN); ++ ++ return 0; ++} ++ ++static int qcom_dwc3_phy_init(struct phy *phy) ++{ ++ struct qcom_dwc3_usb_phy *phy_dwc3 = phy_get_drvdata(phy); ++ ++ if (phy_dwc3->phy_init) ++ return phy_dwc3->phy_init(phy_dwc3); ++ ++ return 0; ++} ++ ++static int qcom_dwc3_phy_exit(struct phy *phy) ++{ ++ struct qcom_dwc3_usb_phy *phy_dwc3 = phy_get_drvdata(phy); ++ ++ if (phy_dwc3->phy_exit) ++ return qcom_dwc3_ss_phy_exit(phy_dwc3); ++ ++ return 0; ++} ++ ++static struct phy_ops qcom_dwc3_phy_ops = { ++ .init = qcom_dwc3_phy_init, ++ .exit = qcom_dwc3_phy_exit, ++ .power_on = qcom_dwc3_phy_power_on, ++ .power_off = qcom_dwc3_phy_power_off, ++ .owner = THIS_MODULE, ++}; ++ ++static const struct of_device_id qcom_dwc3_phy_table[] = { ++ { .compatible = "qcom,dwc3-hs-usb-phy", }, ++ { .compatible = "qcom,dwc3-ss-usb-phy", }, ++ { /* Sentinel */ } ++}; ++MODULE_DEVICE_TABLE(of, qcom_dwc3_phy_table); ++ ++static int qcom_dwc3_phy_probe(struct platform_device *pdev) ++{ ++ struct qcom_dwc3_usb_phy *phy_dwc3; ++ struct phy_provider *phy_provider; ++ struct resource *res; ++ ++ phy_dwc3 = devm_kzalloc(&pdev->dev, sizeof(*phy_dwc3), GFP_KERNEL); ++ if (!phy_dwc3) ++ return -ENOMEM; ++ ++ platform_set_drvdata(pdev, phy_dwc3); ++ ++ phy_dwc3->dev = &pdev->dev; ++ ++ res = platform_get_resource(pdev, IORESOURCE_MEM, 0); ++ phy_dwc3->base = devm_ioremap_resource(phy_dwc3->dev, res); ++ if (IS_ERR(phy_dwc3->base)) ++ return PTR_ERR(phy_dwc3->base); ++ ++ phy_dwc3->ref_clk = devm_clk_get(phy_dwc3->dev, "ref"); ++ if (IS_ERR(phy_dwc3->ref_clk)) { ++ dev_dbg(phy_dwc3->dev, "cannot get reference clock\n"); ++ return PTR_ERR(phy_dwc3->ref_clk); ++ } ++ ++ if (of_device_is_compatible(pdev->dev.of_node, ++ "qcom,dwc3-hs-usb-phy")) { ++ clk_set_rate(phy_dwc3->ref_clk, 60000000); ++ phy_dwc3->phy_init = qcom_dwc3_hs_phy_init; ++ } else if (of_device_is_compatible(pdev->dev.of_node, ++ "qcom,dwc3-ss-usb-phy")) { ++ phy_dwc3->phy_init = qcom_dwc3_ss_phy_init; ++ phy_dwc3->phy_exit = qcom_dwc3_ss_phy_exit; ++ clk_set_rate(phy_dwc3->ref_clk, 125000000); ++ } else { ++ dev_err(phy_dwc3->dev, "Unknown phy\n"); ++ return -EINVAL; ++ } ++ ++ phy_dwc3->xo_clk = devm_clk_get(phy_dwc3->dev, "xo"); ++ if (IS_ERR(phy_dwc3->xo_clk)) { ++ dev_dbg(phy_dwc3->dev, "cannot get TCXO clock\n"); ++ phy_dwc3->xo_clk = NULL; ++ } ++ ++ phy_dwc3->phy = devm_phy_create(phy_dwc3->dev, NULL, &qcom_dwc3_phy_ops); ++ ++ if (IS_ERR(phy_dwc3->phy)) ++ return PTR_ERR(phy_dwc3->phy); ++ ++ phy_set_drvdata(phy_dwc3->phy, phy_dwc3); ++ ++ phy_provider = devm_of_phy_provider_register(phy_dwc3->dev, ++ of_phy_simple_xlate); ++ ++ if (IS_ERR(phy_provider)) ++ return PTR_ERR(phy_provider); ++ ++ return 0; ++} ++ ++static struct platform_driver qcom_dwc3_phy_driver = { ++ .probe = qcom_dwc3_phy_probe, ++ .driver = { ++ .name = "qcom-dwc3-usb-phy", ++ .owner = THIS_MODULE, ++ .of_match_table = qcom_dwc3_phy_table, ++ }, ++}; ++ ++module_platform_driver(qcom_dwc3_phy_driver); ++ ++MODULE_ALIAS("platform:phy-qcom-dwc3"); ++MODULE_LICENSE("GPL v2"); ++MODULE_AUTHOR("Andy Gross "); ++MODULE_AUTHOR("Ivan T. Ivanov "); ++MODULE_DESCRIPTION("DesignWare USB3 QCOM PHY driver"); diff --git a/target/linux/ipq806x/patches-4.4/101-ARM-qcom-add-USB-nodes-to-ipq806x-ap148.patch b/target/linux/ipq806x/patches-4.4/101-ARM-qcom-add-USB-nodes-to-ipq806x-ap148.patch new file mode 100644 index 0000000..6e6f10d --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/101-ARM-qcom-add-USB-nodes-to-ipq806x-ap148.patch @@ -0,0 +1,125 @@ +--- a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts ++++ b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts +@@ -92,5 +92,29 @@ + sata at 29000000 { + status = "ok"; + }; ++ ++ phy at 100f8800 { /* USB3 port 1 HS phy */ ++ status = "ok"; ++ }; ++ ++ phy at 100f8830 { /* USB3 port 1 SS phy */ ++ status = "ok"; ++ }; ++ ++ phy at 110f8800 { /* USB3 port 0 HS phy */ ++ status = "ok"; ++ }; ++ ++ phy at 110f8830 { /* USB3 port 0 SS phy */ ++ status = "ok"; ++ }; ++ ++ usb30 at 0 { ++ status = "ok"; ++ }; ++ ++ usb30 at 1 { ++ status = "ok"; ++ }; + }; + }; +--- a/arch/arm/boot/dts/qcom-ipq8064.dtsi ++++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi +@@ -333,6 +333,90 @@ + compatible = "syscon"; + reg = <0x01200600 0x100>; + }; ++ ++ hs_phy_1: phy at 100f8800 { ++ compatible = "qcom,dwc3-hs-usb-phy"; ++ reg = <0x100f8800 0x30>; ++ clocks = <&gcc USB30_1_UTMI_CLK>; ++ clock-names = "ref"; ++ #phy-cells = <0>; ++ ++ status = "disabled"; ++ }; ++ ++ ss_phy_1: phy at 100f8830 { ++ compatible = "qcom,dwc3-ss-usb-phy"; ++ reg = <0x100f8830 0x30>; ++ clocks = <&gcc USB30_1_MASTER_CLK>; ++ clock-names = "ref"; ++ #phy-cells = <0>; ++ ++ status = "disabled"; ++ }; ++ ++ hs_phy_0: phy at 110f8800 { ++ compatible = "qcom,dwc3-hs-usb-phy"; ++ reg = <0x110f8800 0x30>; ++ clocks = <&gcc USB30_0_UTMI_CLK>; ++ clock-names = "ref"; ++ #phy-cells = <0>; ++ ++ status = "disabled"; ++ }; ++ ++ ss_phy_0: phy at 110f8830 { ++ compatible = "qcom,dwc3-ss-usb-phy"; ++ reg = <0x110f8830 0x30>; ++ clocks = <&gcc USB30_0_MASTER_CLK>; ++ clock-names = "ref"; ++ #phy-cells = <0>; ++ ++ status = "disabled"; ++ }; ++ ++ usb3_0: usb30 at 0 { ++ compatible = "qcom,dwc3"; ++ #address-cells = <1>; ++ #size-cells = <1>; ++ clocks = <&gcc USB30_0_MASTER_CLK>; ++ clock-names = "core"; ++ ++ ranges; ++ ++ status = "disabled"; ++ ++ dwc3 at 11000000 { ++ compatible = "snps,dwc3"; ++ reg = <0x11000000 0xcd00>; ++ interrupts = <0 110 0x4>; ++ phys = <&hs_phy_0>, <&ss_phy_0>; ++ phy-names = "usb2-phy", "usb3-phy"; ++ tx-fifo-resize; ++ dr_mode = "host"; ++ }; ++ }; ++ ++ usb3_1: usb30 at 1 { ++ compatible = "qcom,dwc3"; ++ #address-cells = <1>; ++ #size-cells = <1>; ++ clocks = <&gcc USB30_1_MASTER_CLK>; ++ clock-names = "core"; ++ ++ ranges; ++ ++ status = "disabled"; ++ ++ dwc3 at 10000000 { ++ compatible = "snps,dwc3"; ++ reg = <0x10000000 0xcd00>; ++ interrupts = <0 205 0x4>; ++ phys = <&hs_phy_1>, <&ss_phy_1>; ++ phy-names = "usb2-phy", "usb3-phy"; ++ tx-fifo-resize; ++ dr_mode = "host"; ++ }; ++ }; + }; + + sfpb_mutex: sfpb-mutex { diff --git a/target/linux/ipq806x/patches-4.4/110-DT-PCI-qcom-Document-PCIe-devicetree-bindings.patch b/target/linux/ipq806x/patches-4.4/110-DT-PCI-qcom-Document-PCIe-devicetree-bindings.patch new file mode 100644 index 0000000..41f91fa --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/110-DT-PCI-qcom-Document-PCIe-devicetree-bindings.patch @@ -0,0 +1,263 @@ +Content-Type: text/plain; charset="utf-8" +MIME-Version: 1.0 +Content-Transfer-Encoding: 7bit +Subject: [v2,3/5] DT: PCI: qcom: Document PCIe devicetree bindings +From: Stanimir Varbanov +X-Patchwork-Id: 6326181 +Message-Id: <1430743338-10441-4-git-send-email-svarbanov at mm-sol.com> +To: Rob Herring , Kumar Gala , + Mark Rutland , + Grant Likely , + Bjorn Helgaas , + Kishon Vijay Abraham I , + Russell King , Arnd Bergmann +Cc: linux-arm-msm at vger.kernel.org, linux-kernel at vger.kernel.org, + linux-arm-kernel at lists.infradead.org, devicetree at vger.kernel.org, + linux-pci at vger.kernel.org, Mathieu Olivari , + Srinivas Kandagatla , + Stanimir Varbanov +Date: Mon, 4 May 2015 15:42:16 +0300 + +Document Qualcomm PCIe driver devicetree bindings. + +Signed-off-by: Stanimir Varbanov + +--- +.../devicetree/bindings/pci/qcom,pcie.txt | 231 ++++++++++++++++++++ + 1 files changed, 231 insertions(+), 0 deletions(-) + create mode 100644 Documentation/devicetree/bindings/pci/qcom,pcie.txt + +--- /dev/null ++++ b/Documentation/devicetree/bindings/pci/qcom,pcie.txt +@@ -0,0 +1,231 @@ ++* Qualcomm PCI express root complex ++ ++- compatible: ++ Usage: required ++ Value type: ++ Definition: Value shall include ++ - "qcom,pcie-v0" for apq/ipq8064 ++ - "qcom,pcie-v1" for apq8084 ++ ++- reg: ++ Usage: required ++ Value type: ++ Definition: Register ranges as listed in the reg-names property ++ ++- reg-names: ++ Usage: required ++ Value type: ++ Definition: Must include the following entries ++ - "parf" Qualcomm specific registers ++ - "dbi" Designware PCIe registers ++ - "elbi" External local bus interface registers ++ - "config" PCIe configuration space ++ ++- device_type: ++ Usage: required ++ Value type: ++ Definition: Should be "pci". As specified in designware-pcie.txt ++ ++- #address-cells: ++ Usage: required ++ Value type: ++ Definition: Should be set to 3. As specified in designware-pcie.txt ++ ++- #size-cells: ++ Usage: required ++ Value type: ++ Definition: Should be set 2. As specified in designware-pcie.txt ++ ++- ranges: ++ Usage: required ++ Value type: ++ Definition: As specified in designware-pcie.txt ++ ++- interrupts: ++ Usage: required ++ Value type: ++ Definition: MSI interrupt ++ ++- interrupt-names: ++ Usage: required ++ Value type: ++ Definition: Should contain "msi" ++ ++- #interrupt-cells: ++ Usage: required ++ Value type: ++ Definition: Should be 1. As specified in designware-pcie.txt ++ ++- interrupt-map-mask: ++ Usage: required ++ Value type: ++ Definition: As specified in designware-pcie.txt ++ ++- interrupt-map: ++ Usage: required ++ Value type: ++ Definition: As specified in designware-pcie.txt ++ ++- clocks: ++ Usage: required ++ Value type: ++ Definition: List of phandle and clock specifier pairs as listed ++ in clock-names property ++ ++- clock-names: ++ Usage: required ++ Value type: ++ Definition: Should contain the following entries ++ * should be populated for v0 and v1 ++ - "iface" Configuration AHB clock ++ ++ * should be populated for v0 ++ - "core" Clocks the pcie hw block ++ - "phy" Clocks the pcie PHY block ++ ++ * should be populated for v1 ++ - "aux" Auxiliary (AUX) clock ++ - "bus_master" Master AXI clock ++ - "bus_slave" Slave AXI clock ++ ++- resets: ++ Usage: required ++ Value type: ++ Definition: List of phandle and reset specifier pairs as listed ++ in reset-names property ++ ++- reset-names: ++ Usage: required ++ Value type: ++ Definition: Should contain the following entries ++ * should be populated for v0 ++ - "axi" AXI reset ++ - "ahb" AHB reset ++ - "por" POR reset ++ - "pci" PCI reset ++ - "phy" PHY reset ++ ++ * should be populated for v1 ++ - "core" Core reset ++ ++- power-domains: ++ Usage: required (for v1 only) ++ Value type: ++ Definition: A phandle and power domain specifier pair to the ++ power domain which is responsible for collapsing ++ and restoring power to the peripheral ++ ++- -supply: ++ Usage: required ++ Value type: ++ Definition: List of phandles to the power supply regulator(s) ++ * should be populated for v0 and v1 ++ - "vdda" core analog power supply ++ ++ * should be populated for v0 ++ - "vdda_phy" analog power supply for PHY ++ - "vdda_refclk" analog power supply for IC which generate ++ reference clock ++ ++- phys: ++ Usage: required (for v1 only) ++ Value type: ++ Definition: List of phandle(s) as listed in phy-names property ++ ++- phy-names: ++ Usage: required (for v1 only) ++ Value type: ++ Definition: Should contain "pciephy" ++ ++- -gpio: ++ Usage: optional ++ Value type: ++ Definition: List of phandle and gpio specifier pairs. Should contain ++ - "perst" PCIe endpoint reset signal line ++ - "pewake" PCIe endpoint wake signal line ++ ++- pinctrl-0: ++ Usage: required ++ Value type: ++ Definition: List of phandles pointing at a pin(s) configuration ++ ++- pinctrl-names ++ Usage: required ++ Value type: ++ Definition: List of names of pinctrl-0 state ++ ++* Example for v0 ++ pcie0: pci at 1b500000 { ++ compatible = "qcom,pcie-v0"; ++ reg = <0x1b500000 0x1000 ++ 0x1b502000 0x80 ++ 0x1b600000 0x100 ++ 0x0ff00000 0x100000>; ++ reg-names = "dbi", "elbi", "parf", "config"; ++ device_type = "pci"; ++ linux,pci-domain = <0>; ++ bus-range = <0x00 0xff>; ++ num-lanes = <1>; ++ #address-cells = <3>; ++ #size-cells = <2>; ++ ranges = <0x81000000 0 0 0x0fe00000 0 0x00100000 /* I/O */ ++ 0x82000000 0 0x00000000 0x08000000 0 0x07e00000>; /* memory */ ++ interrupts = ; ++ interrupt-names = "msi"; ++ #interrupt-cells = <1>; ++ interrupt-map-mask = <0 0 0 0x7>; ++ interrupt-map = <0 0 0 1 &intc 0 36 IRQ_TYPE_LEVEL_HIGH>, /* int_a */ ++ <0 0 0 2 &intc 0 37 IRQ_TYPE_LEVEL_HIGH>, /* int_b */ ++ <0 0 0 3 &intc 0 38 IRQ_TYPE_LEVEL_HIGH>, /* int_c */ ++ <0 0 0 4 &intc 0 39 IRQ_TYPE_LEVEL_HIGH>; /* int_d */ ++ clocks = <&gcc PCIE_A_CLK>, ++ <&gcc PCIE_H_CLK>, ++ <&gcc PCIE_PHY_CLK>; ++ clock-names = "core", "iface", "phy"; ++ resets = <&gcc PCIE_ACLK_RESET>, ++ <&gcc PCIE_HCLK_RESET>, ++ <&gcc PCIE_POR_RESET>, ++ <&gcc PCIE_PCI_RESET>, ++ <&gcc PCIE_PHY_RESET>; ++ reset-names = "axi", "ahb", "por", "pci", "phy"; ++ }; ++ ++* Example for v1 ++ pcie0 at fc520000 { ++ compatible = "qcom,pcie-v1"; ++ reg = <0xfc520000 0x2000>, ++ <0xff000000 0x1000>, ++ <0xff001000 0x1000>, ++ <0xff002000 0x2000>; ++ reg-names = "parf", "dbi", "elbi", "config"; ++ device_type = "pci"; ++ linux,pci-domain = <0>; ++ bus-range = <0x00 0xff>; ++ num-lanes = <1>; ++ #address-cells = <3>; ++ #size-cells = <2>; ++ ranges = <0x81000000 0 0 0xff200000 0 0x00100000 /* I/O */ ++ 0x82000000 0 0x00300000 0xff300000 0 0x00d00000>; /* memory */ ++ interrupts = ; ++ interrupt-names = "msi"; ++ #interrupt-cells = <1>; ++ interrupt-map-mask = <0 0 0 0x7>; ++ interrupt-map = <0 0 0 1 &intc 0 244 IRQ_TYPE_LEVEL_HIGH>, /* int_a */ ++ <0 0 0 2 &intc 0 245 IRQ_TYPE_LEVEL_HIGH>, /* int_b */ ++ <0 0 0 3 &intc 0 247 IRQ_TYPE_LEVEL_HIGH>, /* int_c */ ++ <0 0 0 4 &intc 0 248 IRQ_TYPE_LEVEL_HIGH>; /* int_d */ ++ clocks = <&gcc GCC_PCIE_0_CFG_AHB_CLK>, ++ <&gcc GCC_PCIE_0_MSTR_AXI_CLK>, ++ <&gcc GCC_PCIE_0_SLV_AXI_CLK>, ++ <&gcc GCC_PCIE_0_AUX_CLK>; ++ clock-names = "iface", "master_bus", "slave_bus", "aux"; ++ resets = <&gcc GCC_PCIE_0_BCR>; ++ reset-names = "core"; ++ power-domains = <&gcc PCIE0_GDSC>; ++ vdda-supply = <&pma8084_l3>; ++ phys = <&pciephy0>; ++ phy-names = "pciephy"; ++ perst-gpio = <&tlmm 70 GPIO_ACTIVE_LOW>; ++ pinctrl-0 = <&pcie0_pins_default>; ++ pinctrl-names = "default"; ++ }; diff --git a/target/linux/ipq806x/patches-4.4/111-PCI-qcom-Add-Qualcomm-PCIe-controller-driver.patch b/target/linux/ipq806x/patches-4.4/111-PCI-qcom-Add-Qualcomm-PCIe-controller-driver.patch new file mode 100644 index 0000000..ad1a1b9 --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/111-PCI-qcom-Add-Qualcomm-PCIe-controller-driver.patch @@ -0,0 +1,752 @@ +Content-Type: text/plain; charset="utf-8" +MIME-Version: 1.0 +Content-Transfer-Encoding: 7bit +Subject: [v2,4/5] PCI: qcom: Add Qualcomm PCIe controller driver +From: Stanimir Varbanov +X-Patchwork-Id: 6326161 +Message-Id: <1430743338-10441-5-git-send-email-svarbanov at mm-sol.com> +To: Rob Herring , Kumar Gala , + Mark Rutland , + Grant Likely , + Bjorn Helgaas , + Kishon Vijay Abraham I , + Russell King , Arnd Bergmann +Cc: linux-arm-msm at vger.kernel.org, linux-kernel at vger.kernel.org, + linux-arm-kernel at lists.infradead.org, devicetree at vger.kernel.org, + linux-pci at vger.kernel.org, Mathieu Olivari , + Srinivas Kandagatla , + Stanimir Varbanov +Date: Mon, 4 May 2015 15:42:17 +0300 + +The PCIe driver reuse the Designware common code for host +and MSI initialization, and also program the Qualcomm +application specific registers. + +Signed-off-by: Stanimir Varbanov + +--- +MAINTAINERS | 7 + + drivers/pci/host/Kconfig | 9 + + drivers/pci/host/Makefile | 1 + + drivers/pci/host/pcie-qcom.c | 677 ++++++++++++++++++++++++++++++++++++++++++ + 4 files changed, 694 insertions(+), 0 deletions(-) + create mode 100644 drivers/pci/host/pcie-qcom.c + +--- a/MAINTAINERS ++++ b/MAINTAINERS +@@ -8253,6 +8253,13 @@ + F: Documentation/devicetree/bindings/pci/hisilicon-pcie.txt + F: drivers/pci/host/pcie-hisi.c + ++PCIE DRIVER FOR QUALCOMM MSM ++M: Stanimir Varbanov ++L: linux-pci at vger.kernel.org ++L: linux-arm-msm at vger.kernel.org ++S: Maintained ++F: drivers/pci/host/*qcom* ++ + PCMCIA SUBSYSTEM + P: Linux PCMCIA Team + L: linux-pcmcia at lists.infradead.org +--- a/drivers/pci/host/Kconfig ++++ b/drivers/pci/host/Kconfig +@@ -173,4 +173,13 @@ + help + Say Y here if you want PCIe controller support on HiSilicon HIP05 SoC + ++config PCIE_QCOM ++ bool "Qualcomm PCIe controller" ++ depends on ARCH_QCOM && OF || (ARM && COMPILE_TEST) ++ select PCIE_DW ++ select PCIEPORTBUS ++ help ++ Say Y here to enable PCIe controller support on Qualcomm SoCs. The ++ PCIe controller use Designware core plus Qualcomm specific hardware ++ wrappers. + endmenu +--- /dev/null ++++ b/drivers/pci/host/pcie-qcom.c +@@ -0,0 +1,676 @@ ++/* ++ * Copyright (c) 2014, The Linux Foundation. All rights reserved. ++ * ++ * This program is free software; you can redistribute it and/or modify ++ * it under the terms of the GNU General Public License version 2 and ++ * only version 2 as published by the Free Software Foundation. ++ * ++ * 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. ++ */ ++ ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++ ++#include "pcie-designware.h" ++ ++#define PCIE20_PARF_PHY_CTRL 0x40 ++#define PCIE20_PARF_PHY_REFCLK 0x4C ++#define PCIE20_PARF_DBI_BASE_ADDR 0x168 ++#define PCIE20_PARF_SLV_ADDR_SPACE_SIZE 0x16c ++#define PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT 0x178 ++ ++#define PCIE20_ELBI_SYS_CTRL 0x04 ++#define PCIE20_ELBI_SYS_STTS 0x08 ++#define XMLH_LINK_UP BIT(10) ++ ++#define PCIE20_CAP 0x70 ++#define PCIE20_CAP_LINKCTRLSTATUS (PCIE20_CAP + 0x10) ++ ++#define PERST_DELAY_MIN_US 1000 ++#define PERST_DELAY_MAX_US 1005 ++ ++#define LINKUP_DELAY_MIN_US 5000 ++#define LINKUP_DELAY_MAX_US 5100 ++#define LINKUP_RETRIES_COUNT 20 ++ ++#define PCIE_V0 0 /* apq8064 */ ++#define PCIE_V1 1 /* apq8084 */ ++ ++struct qcom_pcie_resources_v0 { ++ struct clk *iface_clk; ++ struct clk *core_clk; ++ struct clk *phy_clk; ++ struct reset_control *pci_reset; ++ struct reset_control *axi_reset; ++ struct reset_control *ahb_reset; ++ struct reset_control *por_reset; ++ struct reset_control *phy_reset; ++ struct regulator *vdda; ++ struct regulator *vdda_phy; ++ struct regulator *vdda_refclk; ++}; ++ ++struct qcom_pcie_resources_v1 { ++ struct clk *iface; ++ struct clk *aux; ++ struct clk *master_bus; ++ struct clk *slave_bus; ++ struct reset_control *core; ++ struct regulator *vdda; ++}; ++ ++union pcie_resources { ++ struct qcom_pcie_resources_v0 v0; ++ struct qcom_pcie_resources_v1 v1; ++}; ++ ++struct qcom_pcie { ++ struct pcie_port pp; ++ struct device *dev; ++ union pcie_resources res; ++ void __iomem *parf; ++ void __iomem *dbi; ++ void __iomem *elbi; ++ struct phy *phy; ++ struct gpio_desc *reset; ++ unsigned int version; ++}; ++ ++#define to_qcom_pcie(x) container_of(x, struct qcom_pcie, pp) ++ ++static inline void ++writel_masked(void __iomem *addr, u32 clear_mask, u32 set_mask) ++{ ++ u32 val = readl(addr); ++ ++ val &= ~clear_mask; ++ val |= set_mask; ++ writel(val, addr); ++} ++ ++static void qcom_ep_reset_assert_deassert(struct qcom_pcie *pcie, int assert) ++{ ++ int val, active_low; ++ ++ if (IS_ERR_OR_NULL(pcie->reset)) ++ return; ++ ++ active_low = gpiod_is_active_low(pcie->reset); ++ ++ if (assert) ++ val = !!active_low; ++ else ++ val = !active_low; ++ ++ gpiod_set_value(pcie->reset, val); ++ ++ usleep_range(PERST_DELAY_MIN_US, PERST_DELAY_MAX_US); ++} ++ ++static void qcom_ep_reset_assert(struct qcom_pcie *pcie) ++{ ++ qcom_ep_reset_assert_deassert(pcie, 1); ++} ++ ++static void qcom_ep_reset_deassert(struct qcom_pcie *pcie) ++{ ++ qcom_ep_reset_assert_deassert(pcie, 0); ++} ++ ++static irqreturn_t qcom_pcie_msi_irq_handler(int irq, void *arg) ++{ ++ struct pcie_port *pp = arg; ++ ++ return dw_handle_msi_irq(pp); ++} ++ ++static int qcom_pcie_link_up(struct pcie_port *pp) ++{ ++ struct qcom_pcie *pcie = to_qcom_pcie(pp); ++ u32 val = readl(pcie->dbi + PCIE20_CAP_LINKCTRLSTATUS); ++ ++ return val & BIT(29) ? 1 : 0; ++} ++ ++static void qcom_pcie_disable_resources_v0(struct qcom_pcie *pcie) ++{ ++ struct qcom_pcie_resources_v0 *res = &pcie->res.v0; ++ ++ reset_control_assert(res->pci_reset); ++ reset_control_assert(res->axi_reset); ++ reset_control_assert(res->ahb_reset); ++ reset_control_assert(res->por_reset); ++ reset_control_assert(res->pci_reset); ++ clk_disable_unprepare(res->iface_clk); ++ clk_disable_unprepare(res->core_clk); ++ clk_disable_unprepare(res->phy_clk); ++ regulator_disable(res->vdda); ++ regulator_disable(res->vdda_phy); ++ regulator_disable(res->vdda_refclk); ++} ++ ++static void qcom_pcie_disable_resources_v1(struct qcom_pcie *pcie) ++{ ++ struct qcom_pcie_resources_v1 *res = &pcie->res.v1; ++ ++ reset_control_assert(res->core); ++ clk_disable_unprepare(res->slave_bus); ++ clk_disable_unprepare(res->master_bus); ++ clk_disable_unprepare(res->iface); ++ clk_disable_unprepare(res->aux); ++ regulator_disable(res->vdda); ++} ++ ++static int qcom_pcie_enable_resources_v0(struct qcom_pcie *pcie) ++{ ++ struct qcom_pcie_resources_v0 *res = &pcie->res.v0; ++ struct device *dev = pcie->dev; ++ int ret; ++ ++ ret = regulator_enable(res->vdda); ++ if (ret) { ++ dev_err(dev, "cannot enable vdda regulator\n"); ++ return ret; ++ } ++ ++ ret = regulator_enable(res->vdda_refclk); ++ if (ret) { ++ dev_err(dev, "cannot enable vdda_refclk regulator\n"); ++ goto err_refclk; ++ } ++ ++ ret = regulator_enable(res->vdda_phy); ++ if (ret) { ++ dev_err(dev, "cannot enable vdda_phy regulator\n"); ++ goto err_vdda_phy; ++ } ++ ++ ret = clk_prepare_enable(res->iface_clk); ++ if (ret) { ++ dev_err(dev, "cannot prepare/enable iface clock\n"); ++ goto err_iface; ++ } ++ ++ ret = clk_prepare_enable(res->core_clk); ++ if (ret) { ++ dev_err(dev, "cannot prepare/enable core clock\n"); ++ goto err_clk_core; ++ } ++ ++ ret = clk_prepare_enable(res->phy_clk); ++ if (ret) { ++ dev_err(dev, "cannot prepare/enable phy clock\n"); ++ goto err_clk_phy; ++ } ++ ++ ret = reset_control_deassert(res->ahb_reset); ++ if (ret) { ++ dev_err(dev, "cannot deassert ahb reset\n"); ++ goto err_reset_ahb; ++ } ++ ++ return 0; ++ ++err_reset_ahb: ++ clk_disable_unprepare(res->phy_clk); ++err_clk_phy: ++ clk_disable_unprepare(res->core_clk); ++err_clk_core: ++ clk_disable_unprepare(res->iface_clk); ++err_iface: ++ regulator_disable(res->vdda_phy); ++err_vdda_phy: ++ regulator_disable(res->vdda_refclk); ++err_refclk: ++ regulator_disable(res->vdda); ++ return ret; ++} ++ ++static int qcom_pcie_enable_resources_v1(struct qcom_pcie *pcie) ++{ ++ struct qcom_pcie_resources_v1 *res = &pcie->res.v1; ++ struct device *dev = pcie->dev; ++ int ret; ++ ++ ret = reset_control_deassert(res->core); ++ if (ret) { ++ dev_err(dev, "cannot deassert core reset\n"); ++ return ret; ++ } ++ ++ ret = clk_prepare_enable(res->aux); ++ if (ret) { ++ dev_err(dev, "cannot prepare/enable aux clock\n"); ++ goto err_res; ++ } ++ ++ ret = clk_prepare_enable(res->iface); ++ if (ret) { ++ dev_err(dev, "cannot prepare/enable iface clock\n"); ++ goto err_aux; ++ } ++ ++ ret = clk_prepare_enable(res->master_bus); ++ if (ret) { ++ dev_err(dev, "cannot prepare/enable master_bus clock\n"); ++ goto err_iface; ++ } ++ ++ ret = clk_prepare_enable(res->slave_bus); ++ if (ret) { ++ dev_err(dev, "cannot prepare/enable slave_bus clock\n"); ++ goto err_master; ++ } ++ ++ ret = regulator_enable(res->vdda); ++ if (ret) { ++ dev_err(dev, "cannot enable vdda regulator\n"); ++ goto err_slave; ++ } ++ ++ return 0; ++ ++err_slave: ++ clk_disable_unprepare(res->slave_bus); ++err_master: ++ clk_disable_unprepare(res->master_bus); ++err_iface: ++ clk_disable_unprepare(res->iface); ++err_aux: ++ clk_disable_unprepare(res->aux); ++err_res: ++ reset_control_assert(res->core); ++ ++ return ret; ++} ++ ++static int qcom_pcie_get_resources_v0(struct qcom_pcie *pcie) ++{ ++ struct qcom_pcie_resources_v0 *res = &pcie->res.v0; ++ struct device *dev = pcie->dev; ++ ++ res->vdda = devm_regulator_get(dev, "vdda"); ++ if (IS_ERR(res->vdda)) ++ return PTR_ERR(res->vdda); ++ ++ res->vdda_phy = devm_regulator_get(dev, "vdda_phy"); ++ if (IS_ERR(res->vdda_phy)) ++ return PTR_ERR(res->vdda_phy); ++ ++ res->vdda_refclk = devm_regulator_get(dev, "vdda_refclk"); ++ if (IS_ERR(res->vdda_refclk)) ++ return PTR_ERR(res->vdda_refclk); ++ ++ res->iface_clk = devm_clk_get(dev, "iface"); ++ if (IS_ERR(res->iface_clk)) ++ return PTR_ERR(res->iface_clk); ++ ++ res->core_clk = devm_clk_get(dev, "core"); ++ if (IS_ERR(res->core_clk)) ++ return PTR_ERR(res->core_clk); ++ ++ res->phy_clk = devm_clk_get(dev, "phy"); ++ if (IS_ERR(res->phy_clk)) ++ return PTR_ERR(res->phy_clk); ++ ++ res->pci_reset = devm_reset_control_get(dev, "pci"); ++ if (IS_ERR(res->pci_reset)) ++ return PTR_ERR(res->pci_reset); ++ ++ res->axi_reset = devm_reset_control_get(dev, "axi"); ++ if (IS_ERR(res->axi_reset)) ++ return PTR_ERR(res->axi_reset); ++ ++ res->ahb_reset = devm_reset_control_get(dev, "ahb"); ++ if (IS_ERR(res->ahb_reset)) ++ return PTR_ERR(res->ahb_reset); ++ ++ res->por_reset = devm_reset_control_get(dev, "por"); ++ if (IS_ERR(res->por_reset)) ++ return PTR_ERR(res->por_reset); ++ ++ res->phy_reset = devm_reset_control_get(dev, "phy"); ++ if (IS_ERR(res->phy_reset)) ++ return PTR_ERR(res->phy_reset); ++ ++ return 0; ++} ++ ++static int qcom_pcie_get_resources_v1(struct qcom_pcie *pcie) ++{ ++ struct qcom_pcie_resources_v1 *res = &pcie->res.v1; ++ struct device *dev = pcie->dev; ++ ++ res->vdda = devm_regulator_get(dev, "vdda"); ++ if (IS_ERR(res->vdda)) ++ return PTR_ERR(res->vdda); ++ ++ res->iface = devm_clk_get(dev, "iface"); ++ if (IS_ERR(res->iface)) ++ return PTR_ERR(res->iface); ++ ++ res->aux = devm_clk_get(dev, "aux"); ++ if (IS_ERR(res->aux) && PTR_ERR(res->aux) == -EPROBE_DEFER) ++ return -EPROBE_DEFER; ++ else if (IS_ERR(res->aux)) ++ res->aux = NULL; ++ ++ res->master_bus = devm_clk_get(dev, "master_bus"); ++ if (IS_ERR(res->master_bus)) ++ return PTR_ERR(res->master_bus); ++ ++ res->slave_bus = devm_clk_get(dev, "slave_bus"); ++ if (IS_ERR(res->slave_bus)) ++ return PTR_ERR(res->slave_bus); ++ ++ res->core = devm_reset_control_get(dev, "core"); ++ if (IS_ERR(res->core)) ++ return PTR_ERR(res->core); ++ ++ return 0; ++} ++ ++static int qcom_pcie_enable_link_training(struct pcie_port *pp) ++{ ++ struct qcom_pcie *pcie = to_qcom_pcie(pp); ++ struct device *dev = pp->dev; ++ int retries; ++ u32 val; ++ ++ /* enable link training */ ++ writel_masked(pcie->elbi + PCIE20_ELBI_SYS_CTRL, 0, BIT(0)); ++ ++ /* wait for up to 100ms for the link to come up */ ++ retries = LINKUP_RETRIES_COUNT; ++ do { ++ val = readl(pcie->elbi + PCIE20_ELBI_SYS_STTS); ++ if (val & XMLH_LINK_UP) ++ break; ++ usleep_range(LINKUP_DELAY_MIN_US, LINKUP_DELAY_MAX_US); ++ } while (retries--); ++ ++ if (retries < 0 || !dw_pcie_link_up(pp)) { ++ dev_err(dev, "link initialization failed\n"); ++ return -ENXIO; ++ } ++ ++ return 0; ++} ++ ++static void qcom_pcie_host_init_v1(struct pcie_port *pp) ++{ ++ struct qcom_pcie *pcie = to_qcom_pcie(pp); ++ int ret; ++ ++ qcom_ep_reset_assert(pcie); ++ ++ ret = qcom_pcie_enable_resources_v1(pcie); ++ if (ret) ++ return; ++ ++ /* change DBI base address */ ++ writel(0, pcie->parf + PCIE20_PARF_DBI_BASE_ADDR); ++ ++ if (IS_ENABLED(CONFIG_PCI_MSI)) ++ writel_masked(pcie->parf + PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT, ++ 0, BIT(31)); ++ ++ ret = phy_init(pcie->phy); ++ if (ret) ++ goto err_res; ++ ++ ret = phy_power_on(pcie->phy); ++ if (ret) ++ goto err_phy; ++ ++ dw_pcie_setup_rc(pp); ++ ++ if (IS_ENABLED(CONFIG_PCI_MSI)) ++ dw_pcie_msi_init(pp); ++ ++ qcom_ep_reset_deassert(pcie); ++ ++ ret = qcom_pcie_enable_link_training(pp); ++ if (ret) ++ goto err; ++ ++ return; ++ ++err: ++ qcom_ep_reset_assert(pcie); ++ phy_power_off(pcie->phy); ++err_phy: ++ phy_exit(pcie->phy); ++err_res: ++ qcom_pcie_disable_resources_v1(pcie); ++} ++ ++static void qcom_pcie_host_init_v0(struct pcie_port *pp) ++{ ++ struct qcom_pcie *pcie = to_qcom_pcie(pp); ++ struct qcom_pcie_resources_v0 *res = &pcie->res.v0; ++ struct device *dev = pcie->dev; ++ int ret; ++ ++ qcom_ep_reset_assert(pcie); ++ ++ ret = qcom_pcie_enable_resources_v0(pcie); ++ if (ret) ++ return; ++ ++ writel_masked(pcie->parf + PCIE20_PARF_PHY_CTRL, BIT(0), 0); ++ ++ /* enable external reference clock */ ++ writel_masked(pcie->parf + PCIE20_PARF_PHY_REFCLK, 0, BIT(16)); ++ ++ ret = reset_control_deassert(res->phy_reset); ++ if (ret) { ++ dev_err(dev, "cannot deassert phy reset\n"); ++ return; ++ } ++ ++ ret = reset_control_deassert(res->pci_reset); ++ if (ret) { ++ dev_err(dev, "cannot deassert pci reset\n"); ++ return; ++ } ++ ++ ret = reset_control_deassert(res->por_reset); ++ if (ret) { ++ dev_err(dev, "cannot deassert por reset\n"); ++ return; ++ } ++ ++ ret = reset_control_deassert(res->axi_reset); ++ if (ret) { ++ dev_err(dev, "cannot deassert axi reset\n"); ++ return; ++ } ++ ++ /* wait 150ms for clock acquisition */ ++ usleep_range(10000, 15000); ++ ++ dw_pcie_setup_rc(pp); ++ ++ if (IS_ENABLED(CONFIG_PCI_MSI)) ++ dw_pcie_msi_init(pp); ++ ++ qcom_ep_reset_deassert(pcie); ++ ++ ret = qcom_pcie_enable_link_training(pp); ++ if (ret) ++ goto err; ++ ++ return; ++err: ++ qcom_ep_reset_assert(pcie); ++ qcom_pcie_disable_resources_v0(pcie); ++} ++ ++static void qcom_pcie_host_init(struct pcie_port *pp) ++{ ++ struct qcom_pcie *pcie = to_qcom_pcie(pp); ++ ++ if (pcie->version == PCIE_V0) ++ return qcom_pcie_host_init_v0(pp); ++ else ++ return qcom_pcie_host_init_v1(pp); ++} ++ ++static int ++qcom_pcie_rd_own_conf(struct pcie_port *pp, int where, int size, u32 *val) ++{ ++ /* the device class is not reported correctly from the register */ ++ if (where == PCI_CLASS_REVISION && size == 4) { ++ *val = readl(pp->dbi_base + PCI_CLASS_REVISION); ++ *val &= ~(0xffff << 16); ++ *val |= PCI_CLASS_BRIDGE_PCI << 16; ++ return PCIBIOS_SUCCESSFUL; ++ } ++ ++ return dw_pcie_cfg_read(pp->dbi_base + where, size, val); ++} ++ ++static struct pcie_host_ops qcom_pcie_ops = { ++ .link_up = qcom_pcie_link_up, ++ .host_init = qcom_pcie_host_init, ++ .rd_own_conf = qcom_pcie_rd_own_conf, ++}; ++ ++static const struct of_device_id qcom_pcie_match[] = { ++ { .compatible = "qcom,pcie-v0", .data = (void *)PCIE_V0 }, ++ { .compatible = "qcom,pcie-v1", .data = (void *)PCIE_V1 }, ++ { } ++}; ++ ++static int qcom_pcie_probe(struct platform_device *pdev) ++{ ++ struct device *dev = &pdev->dev; ++ const struct of_device_id *match; ++ struct resource *res; ++ struct qcom_pcie *pcie; ++ struct pcie_port *pp; ++ int ret; ++ ++ match = of_match_node(qcom_pcie_match, dev->of_node); ++ if (!match) ++ return -ENXIO; ++ ++ pcie = devm_kzalloc(dev, sizeof(*pcie), GFP_KERNEL); ++ if (!pcie) ++ return -ENOMEM; ++ ++ pcie->version = (unsigned int)match->data; ++ ++ pcie->reset = devm_gpiod_get_optional(dev, "perst", GPIOD_OUT_LOW); ++ if (IS_ERR(pcie->reset) && PTR_ERR(pcie->reset) == -EPROBE_DEFER) ++ return PTR_ERR(pcie->reset); ++ ++ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "parf"); ++ pcie->parf = devm_ioremap_resource(dev, res); ++ if (IS_ERR(pcie->parf)) ++ return PTR_ERR(pcie->parf); ++ ++ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dbi"); ++ pcie->dbi = devm_ioremap_resource(dev, res); ++ if (IS_ERR(pcie->dbi)) ++ return PTR_ERR(pcie->dbi); ++ ++ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "elbi"); ++ pcie->elbi = devm_ioremap_resource(dev, res); ++ if (IS_ERR(pcie->elbi)) ++ return PTR_ERR(pcie->elbi); ++ ++ pcie->phy = devm_phy_optional_get(dev, "pciephy"); ++ if (IS_ERR(pcie->phy)) ++ return PTR_ERR(pcie->phy); ++ ++ pcie->dev = dev; ++ ++ if (pcie->version == PCIE_V0) ++ ret = qcom_pcie_get_resources_v0(pcie); ++ else ++ ret = qcom_pcie_get_resources_v1(pcie); ++ ++ if (ret) ++ return ret; ++ ++ pp = &pcie->pp; ++ pp->dev = dev; ++ pp->dbi_base = pcie->dbi; ++ pp->root_bus_nr = -1; ++ pp->ops = &qcom_pcie_ops; ++ ++ if (IS_ENABLED(CONFIG_PCI_MSI)) { ++ pp->msi_irq = platform_get_irq_byname(pdev, "msi"); ++ if (pp->msi_irq < 0) { ++ dev_err(dev, "cannot get msi irq\n"); ++ return pp->msi_irq; ++ } ++ ++ ret = devm_request_irq(dev, pp->msi_irq, ++ qcom_pcie_msi_irq_handler, ++ IRQF_SHARED, "qcom-pcie-msi", pp); ++ if (ret) { ++ dev_err(dev, "cannot request msi irq\n"); ++ return ret; ++ } ++ } ++ ++ ret = dw_pcie_host_init(pp); ++ if (ret) { ++ dev_err(dev, "cannot initialize host\n"); ++ return ret; ++ } ++ ++ platform_set_drvdata(pdev, pcie); ++ ++ return 0; ++} ++ ++static int qcom_pcie_remove(struct platform_device *pdev) ++{ ++ struct qcom_pcie *pcie = platform_get_drvdata(pdev); ++ ++ qcom_ep_reset_assert(pcie); ++ phy_power_off(pcie->phy); ++ phy_exit(pcie->phy); ++ if (pcie->version == PCIE_V0) ++ qcom_pcie_disable_resources_v0(pcie); ++ else ++ qcom_pcie_disable_resources_v1(pcie); ++ ++ return 0; ++} ++ ++static struct platform_driver qcom_pcie_driver = { ++ .probe = qcom_pcie_probe, ++ .remove = qcom_pcie_remove, ++ .driver = { ++ .name = "qcom-pcie", ++ .of_match_table = qcom_pcie_match, ++ }, ++}; ++ ++module_platform_driver(qcom_pcie_driver); ++ ++MODULE_AUTHOR("Stanimir Varbanov "); ++MODULE_DESCRIPTION("Qualcomm PCIe root complex driver"); ++MODULE_LICENSE("GPL v2"); ++MODULE_ALIAS("platform:qcom-pcie"); +--- a/drivers/pci/host/Makefile ++++ b/drivers/pci/host/Makefile +@@ -20,3 +20,4 @@ + obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o + obj-$(CONFIG_PCIE_ALTERA_MSI) += pcie-altera-msi.o + obj-$(CONFIG_PCI_HISI) += pcie-hisi.o ++obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o diff --git a/target/linux/ipq806x/patches-4.4/112-ARM-dts-qcom-add-pcie-nodes-to-ipq806x-platforms.patch b/target/linux/ipq806x/patches-4.4/112-ARM-dts-qcom-add-pcie-nodes-to-ipq806x-platforms.patch new file mode 100644 index 0000000..1246bfe --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/112-ARM-dts-qcom-add-pcie-nodes-to-ipq806x-platforms.patch @@ -0,0 +1,244 @@ +From 5b40516b2f5fb9b2a7d6d3e2e924f12ec9d183a8 Mon Sep 17 00:00:00 2001 +From: Mathieu Olivari +Date: Tue, 21 Apr 2015 19:01:42 -0700 +Subject: [PATCH 8/9] ARM: dts: qcom: add pcie nodes to ipq806x platforms + +qcom-pcie driver now supports version 0 of the controller. This change +adds the corresponding entries to the IPQ806x dtsi file and +corresponding platform (AP148). + +Signed-off-by: Mathieu Olivari +--- + arch/arm/boot/dts/qcom-ipq8064-ap148.dts | 30 ++++++++ + arch/arm/boot/dts/qcom-ipq8064.dtsi | 124 +++++++++++++++++++++++++++++++ + 2 files changed, 154 insertions(+) + +--- a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts ++++ b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts +@@ -116,5 +116,15 @@ + usb30 at 1 { + status = "ok"; + }; ++ ++ pcie0: pci at 1b500000 { ++ status = "ok"; ++ phy-tx0-term-offset = <7>; ++ }; ++ ++ pcie1: pci at 1b700000 { ++ status = "ok"; ++ phy-tx0-term-offset = <7>; ++ }; + }; + }; +--- a/arch/arm/boot/dts/qcom-ipq8064-db149.dts ++++ b/arch/arm/boot/dts/qcom-ipq8064-db149.dts +@@ -128,5 +128,17 @@ + usb30 at 1 { + status = "ok"; + }; ++ ++ pcie0: pci at 1b500000 { ++ status = "ok"; ++ }; ++ ++ pcie1: pci at 1b700000 { ++ status = "ok"; ++ }; ++ ++ pcie2: pci at 1b900000 { ++ status = "ok"; ++ }; + }; + }; +--- a/arch/arm/boot/dts/qcom-ipq8064.dtsi ++++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi +@@ -4,6 +4,9 @@ + #include + #include + #include ++#include ++#include ++#include + + / { + model = "Qualcomm IPQ8064"; +@@ -99,6 +102,33 @@ + interrupt-controller; + #interrupt-cells = <2>; + interrupts = <0 16 0x4>; ++ ++ pcie0_pins: pcie0_pinmux { ++ mux { ++ pins = "gpio3"; ++ function = "pcie1_rst"; ++ drive-strength = <12>; ++ bias-disable; ++ }; ++ }; ++ ++ pcie1_pins: pcie1_pinmux { ++ mux { ++ pins = "gpio48"; ++ function = "pcie2_rst"; ++ drive-strength = <12>; ++ bias-disable; ++ }; ++ }; ++ ++ pcie2_pins: pcie2_pinmux { ++ mux { ++ pins = "gpio63"; ++ function = "pcie3_rst"; ++ drive-strength = <12>; ++ bias-disable; ++ }; ++ }; + }; + + intc: interrupt-controller at 2000000 { +@@ -417,6 +447,144 @@ + dr_mode = "host"; + }; + }; ++ ++ pcie0: pci at 1b500000 { ++ compatible = "qcom,pcie-v0"; ++ reg = <0x1b500000 0x1000 ++ 0x1b502000 0x80 ++ 0x1b600000 0x100 ++ 0x0ff00000 0x100000>; ++ reg-names = "dbi", "elbi", "parf", "config"; ++ device_type = "pci"; ++ linux,pci-domain = <0>; ++ bus-range = <0x00 0xff>; ++ num-lanes = <1>; ++ #address-cells = <3>; ++ #size-cells = <2>; ++ ++ ranges = <0x81000000 0 0x0fe00000 0x0fe00000 0 0x00100000 /* downstream I/O */ ++ 0x82000000 0 0x08000000 0x08000000 0 0x07e00000>; /* non-prefetchable memory */ ++ ++ interrupts = ; ++ interrupt-names = "msi"; ++ #interrupt-cells = <1>; ++ interrupt-map-mask = <0 0 0 0x7>; ++ interrupt-map = <0 0 0 1 &intc 0 36 IRQ_TYPE_LEVEL_HIGH>, /* int_a */ ++ <0 0 0 2 &intc 0 37 IRQ_TYPE_LEVEL_HIGH>, /* int_b */ ++ <0 0 0 3 &intc 0 38 IRQ_TYPE_LEVEL_HIGH>, /* int_c */ ++ <0 0 0 4 &intc 0 39 IRQ_TYPE_LEVEL_HIGH>; /* int_d */ ++ ++ clocks = <&gcc PCIE_A_CLK>, ++ <&gcc PCIE_H_CLK>, ++ <&gcc PCIE_PHY_CLK>; ++ clock-names = "core", "iface", "phy"; ++ ++ resets = <&gcc PCIE_ACLK_RESET>, ++ <&gcc PCIE_HCLK_RESET>, ++ <&gcc PCIE_POR_RESET>, ++ <&gcc PCIE_PCI_RESET>, ++ <&gcc PCIE_PHY_RESET>; ++ reset-names = "axi", "ahb", "por", "pci", "phy"; ++ ++ pinctrl-0 = <&pcie0_pins>; ++ pinctrl-names = "default"; ++ ++ perst-gpio = <&qcom_pinmux 3 GPIO_ACTIVE_LOW>; ++ ++ status = "disabled"; ++ }; ++ ++ pcie1: pci at 1b700000 { ++ compatible = "qcom,pcie-v0"; ++ reg = <0x1b700000 0x1000 ++ 0x1b702000 0x80 ++ 0x1b800000 0x100 ++ 0x31f00000 0x100000>; ++ reg-names = "dbi", "elbi", "parf", "config"; ++ device_type = "pci"; ++ linux,pci-domain = <1>; ++ bus-range = <0x00 0xff>; ++ num-lanes = <1>; ++ #address-cells = <3>; ++ #size-cells = <2>; ++ ++ ranges = <0x81000000 0 0x31e00000 0x31e00000 0 0x00100000 /* downstream I/O */ ++ 0x82000000 0 0x2e000000 0x2e000000 0 0x03e00000>; /* non-prefetchable memory */ ++ ++ interrupts = ; ++ interrupt-names = "msi"; ++ #interrupt-cells = <1>; ++ interrupt-map-mask = <0 0 0 0x7>; ++ interrupt-map = <0 0 0 1 &intc 0 58 IRQ_TYPE_LEVEL_HIGH>, /* int_a */ ++ <0 0 0 2 &intc 0 59 IRQ_TYPE_LEVEL_HIGH>, /* int_b */ ++ <0 0 0 3 &intc 0 60 IRQ_TYPE_LEVEL_HIGH>, /* int_c */ ++ <0 0 0 4 &intc 0 61 IRQ_TYPE_LEVEL_HIGH>; /* int_d */ ++ ++ clocks = <&gcc PCIE_1_A_CLK>, ++ <&gcc PCIE_1_H_CLK>, ++ <&gcc PCIE_1_PHY_CLK>; ++ clock-names = "core", "iface", "phy"; ++ ++ resets = <&gcc PCIE_1_ACLK_RESET>, ++ <&gcc PCIE_1_HCLK_RESET>, ++ <&gcc PCIE_1_POR_RESET>, ++ <&gcc PCIE_1_PCI_RESET>, ++ <&gcc PCIE_1_PHY_RESET>; ++ reset-names = "axi", "ahb", "por", "pci", "phy"; ++ ++ pinctrl-0 = <&pcie1_pins>; ++ pinctrl-names = "default"; ++ ++ perst-gpio = <&qcom_pinmux 48 GPIO_ACTIVE_LOW>; ++ ++ status = "disabled"; ++ }; ++ ++ pcie2: pci at 1b900000 { ++ compatible = "qcom,pcie-v0"; ++ reg = <0x1b900000 0x1000 ++ 0x1b902000 0x80 ++ 0x1ba00000 0x100 ++ 0x35f00000 0x100000>; ++ reg-names = "dbi", "elbi", "parf", "config"; ++ device_type = "pci"; ++ linux,pci-domain = <2>; ++ bus-range = <0x00 0xff>; ++ num-lanes = <1>; ++ #address-cells = <3>; ++ #size-cells = <2>; ++ ++ ranges = <0x81000000 0 0x35e00000 0x35e00000 0 0x00100000 /* downstream I/O */ ++ 0x82000000 0 0x32000000 0x32000000 0 0x03e00000>; /* non-prefetchable memory */ ++ ++ interrupts = ; ++ interrupt-names = "msi"; ++ #interrupt-cells = <1>; ++ interrupt-map-mask = <0 0 0 0x7>; ++ interrupt-map = <0 0 0 1 &intc 0 72 IRQ_TYPE_LEVEL_HIGH>, /* int_a */ ++ <0 0 0 2 &intc 0 73 IRQ_TYPE_LEVEL_HIGH>, /* int_b */ ++ <0 0 0 3 &intc 0 74 IRQ_TYPE_LEVEL_HIGH>, /* int_c */ ++ <0 0 0 4 &intc 0 75 IRQ_TYPE_LEVEL_HIGH>; /* int_d */ ++ ++ clocks = <&gcc PCIE_2_A_CLK>, ++ <&gcc PCIE_2_H_CLK>, ++ <&gcc PCIE_2_PHY_CLK>; ++ clock-names = "core", "iface", "phy"; ++ ++ resets = <&gcc PCIE_2_ACLK_RESET>, ++ <&gcc PCIE_2_HCLK_RESET>, ++ <&gcc PCIE_2_POR_RESET>, ++ <&gcc PCIE_2_PCI_RESET>, ++ <&gcc PCIE_2_PHY_RESET>; ++ reset-names = "axi", "ahb", "por", "pci", "phy"; ++ ++ pinctrl-0 = <&pcie2_pins>; ++ pinctrl-names = "default"; ++ ++ perst-gpio = <&qcom_pinmux 63 GPIO_ACTIVE_LOW>; ++ ++ status = "disabled"; ++ }; + }; + + sfpb_mutex: sfpb-mutex { diff --git a/target/linux/ipq806x/patches-4.4/113-ARM-qcom-automatically-select-PCI_DOMAINS-if-PCI-is-.patch b/target/linux/ipq806x/patches-4.4/113-ARM-qcom-automatically-select-PCI_DOMAINS-if-PCI-is-.patch new file mode 100644 index 0000000..e2d3135 --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/113-ARM-qcom-automatically-select-PCI_DOMAINS-if-PCI-is-.patch @@ -0,0 +1,29 @@ +From f004aa1dec6e2e206be025de15b115d60f2b21e3 Mon Sep 17 00:00:00 2001 +From: Mathieu Olivari +Date: Tue, 21 Apr 2015 19:09:07 -0700 +Subject: [PATCH 9/9] ARM: qcom: automatically select PCI_DOMAINS if PCI is + enabled + +If multiple PCIe devices are present in the system, the kernel will +panic at boot time when trying to scan the PCI buses. This happens on +IPQ806x based platforms, which has 3 PCIe ports. + +Enabling this option allows the kernel to assign the pci-domains +according to the device-tree content. This allows multiple PCIe +controllers to coexist in the system. + +Signed-off-by: Mathieu Olivari +--- + arch/arm/mach-qcom/Kconfig | 1 + + 1 file changed, 1 insertion(+) + +--- a/arch/arm/mach-qcom/Kconfig ++++ b/arch/arm/mach-qcom/Kconfig +@@ -5,6 +5,7 @@ menuconfig ARCH_QCOM + select ARM_AMBA + select PINCTRL + select QCOM_SCM if SMP ++ select PCI_DOMAINS if PCI + help + Support for Qualcomm's devicetree based systems. + diff --git a/target/linux/ipq806x/patches-4.4/114-pcie-add-ctlr-init.patch b/target/linux/ipq806x/patches-4.4/114-pcie-add-ctlr-init.patch new file mode 100644 index 0000000..6328113 --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/114-pcie-add-ctlr-init.patch @@ -0,0 +1,311 @@ +--- a/drivers/pci/host/pcie-qcom.c ++++ b/drivers/pci/host/pcie-qcom.c +@@ -29,8 +29,53 @@ + + #include "pcie-designware.h" + ++/* DBI registers */ ++#define PCIE20_CAP 0x70 ++#define PCIE20_CAP_LINKCTRLSTATUS (PCIE20_CAP + 0x10) ++ ++#define PCIE20_AXI_MSTR_RESP_COMP_CTRL0 0x818 ++#define PCIE20_AXI_MSTR_RESP_COMP_CTRL1 0x81c ++ ++#define PCIE20_PLR_IATU_VIEWPORT 0x900 ++#define PCIE20_PLR_IATU_REGION_OUTBOUND (0x0 << 31) ++#define PCIE20_PLR_IATU_REGION_INDEX(x) (x << 0) ++ ++#define PCIE20_PLR_IATU_CTRL1 0x904 ++#define PCIE20_PLR_IATU_TYPE_CFG0 (0x4 << 0) ++#define PCIE20_PLR_IATU_TYPE_MEM (0x0 << 0) ++ ++#define PCIE20_PLR_IATU_CTRL2 0x908 ++#define PCIE20_PLR_IATU_ENABLE BIT(31) ++ ++#define PCIE20_PLR_IATU_LBAR 0x90C ++#define PCIE20_PLR_IATU_UBAR 0x910 ++#define PCIE20_PLR_IATU_LAR 0x914 ++#define PCIE20_PLR_IATU_LTAR 0x918 ++#define PCIE20_PLR_IATU_UTAR 0x91c ++ ++#define MSM_PCIE_DEV_CFG_ADDR 0x01000000 ++ ++/* PARF registers */ ++#define PCIE20_PARF_PCS_DEEMPH 0x34 ++#define PCS_DEEMPH_TX_DEEMPH_GEN1(x) (x << 16) ++#define PCS_DEEMPH_TX_DEEMPH_GEN2_3_5DB(x) (x << 8) ++#define PCS_DEEMPH_TX_DEEMPH_GEN2_6DB(x) (x << 0) ++ ++#define PCIE20_PARF_PCS_SWING 0x38 ++#define PCS_SWING_TX_SWING_FULL(x) (x << 8) ++#define PCS_SWING_TX_SWING_LOW(x) (x << 0) ++ + #define PCIE20_PARF_PHY_CTRL 0x40 ++#define PHY_CTRL_PHY_TX0_TERM_OFFSET_MASK (0x1f << 16) ++#define PHY_CTRL_PHY_TX0_TERM_OFFSET(x) (x << 16) ++ + #define PCIE20_PARF_PHY_REFCLK 0x4C ++#define REF_SSP_EN BIT(16) ++#define REF_USE_PAD BIT(12) ++ ++#define PCIE20_PARF_CONFIG_BITS 0x50 ++#define PHY_RX0_EQ(x) (x << 24) ++ + #define PCIE20_PARF_DBI_BASE_ADDR 0x168 + #define PCIE20_PARF_SLV_ADDR_SPACE_SIZE 0x16c + #define PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT 0x178 +@@ -39,9 +84,6 @@ + #define PCIE20_ELBI_SYS_STTS 0x08 + #define XMLH_LINK_UP BIT(10) + +-#define PCIE20_CAP 0x70 +-#define PCIE20_CAP_LINKCTRLSTATUS (PCIE20_CAP + 0x10) +- + #define PERST_DELAY_MIN_US 1000 + #define PERST_DELAY_MAX_US 1005 + +@@ -56,14 +98,18 @@ struct qcom_pcie_resources_v0 { + struct clk *iface_clk; + struct clk *core_clk; + struct clk *phy_clk; ++ struct clk *aux_clk; ++ struct clk *ref_clk; + struct reset_control *pci_reset; + struct reset_control *axi_reset; + struct reset_control *ahb_reset; + struct reset_control *por_reset; + struct reset_control *phy_reset; ++ struct reset_control *ext_reset; + struct regulator *vdda; + struct regulator *vdda_phy; + struct regulator *vdda_refclk; ++ uint8_t phy_tx0_term_offset; + }; + + struct qcom_pcie_resources_v1 { +@@ -106,20 +152,10 @@ writel_masked(void __iomem *addr, u32 cl + + static void qcom_ep_reset_assert_deassert(struct qcom_pcie *pcie, int assert) + { +- int val, active_low; +- + if (IS_ERR_OR_NULL(pcie->reset)) + return; + +- active_low = gpiod_is_active_low(pcie->reset); +- +- if (assert) +- val = !!active_low; +- else +- val = !active_low; +- +- gpiod_set_value(pcie->reset, val); +- ++ gpiod_set_value(pcie->reset, assert); + usleep_range(PERST_DELAY_MIN_US, PERST_DELAY_MAX_US); + } + +@@ -156,10 +192,13 @@ static void qcom_pcie_disable_resources_ + reset_control_assert(res->axi_reset); + reset_control_assert(res->ahb_reset); + reset_control_assert(res->por_reset); +- reset_control_assert(res->pci_reset); ++ reset_control_assert(res->phy_reset); ++ reset_control_assert(res->ext_reset); + clk_disable_unprepare(res->iface_clk); + clk_disable_unprepare(res->core_clk); + clk_disable_unprepare(res->phy_clk); ++ clk_disable_unprepare(res->aux_clk); ++ clk_disable_unprepare(res->ref_clk); + regulator_disable(res->vdda); + regulator_disable(res->vdda_phy); + regulator_disable(res->vdda_refclk); +@@ -201,6 +240,12 @@ static int qcom_pcie_enable_resources_v0 + goto err_vdda_phy; + } + ++ ret = reset_control_deassert(res->ext_reset); ++ if (ret) { ++ dev_err(dev, "cannot assert ext reset\n"); ++ goto err_reset_ext; ++ } ++ + ret = clk_prepare_enable(res->iface_clk); + if (ret) { + dev_err(dev, "cannot prepare/enable iface clock\n"); +@@ -219,21 +264,40 @@ static int qcom_pcie_enable_resources_v0 + goto err_clk_phy; + } + ++ ret = clk_prepare_enable(res->aux_clk); ++ if (ret) { ++ dev_err(dev, "cannot prepare/enable aux clock\n"); ++ goto err_clk_aux; ++ } ++ ++ ret = clk_prepare_enable(res->ref_clk); ++ if (ret) { ++ dev_err(dev, "cannot prepare/enable ref clock\n"); ++ goto err_clk_ref; ++ } ++ + ret = reset_control_deassert(res->ahb_reset); + if (ret) { + dev_err(dev, "cannot deassert ahb reset\n"); + goto err_reset_ahb; + } ++ udelay(1); + + return 0; + + err_reset_ahb: ++ clk_disable_unprepare(res->ref_clk); ++err_clk_ref: ++ clk_disable_unprepare(res->aux_clk); ++err_clk_aux: + clk_disable_unprepare(res->phy_clk); + err_clk_phy: + clk_disable_unprepare(res->core_clk); + err_clk_core: + clk_disable_unprepare(res->iface_clk); + err_iface: ++ reset_control_assert(res->ext_reset); ++err_reset_ext: + regulator_disable(res->vdda_phy); + err_vdda_phy: + regulator_disable(res->vdda_refclk); +@@ -329,6 +393,14 @@ static int qcom_pcie_get_resources_v0(st + if (IS_ERR(res->phy_clk)) + return PTR_ERR(res->phy_clk); + ++ res->aux_clk = devm_clk_get(dev, "aux"); ++ if (IS_ERR(res->aux_clk)) ++ return PTR_ERR(res->aux_clk); ++ ++ res->ref_clk = devm_clk_get(dev, "ref"); ++ if (IS_ERR(res->ref_clk)) ++ return PTR_ERR(res->ref_clk); ++ + res->pci_reset = devm_reset_control_get(dev, "pci"); + if (IS_ERR(res->pci_reset)) + return PTR_ERR(res->pci_reset); +@@ -349,6 +421,14 @@ static int qcom_pcie_get_resources_v0(st + if (IS_ERR(res->phy_reset)) + return PTR_ERR(res->phy_reset); + ++ res->ext_reset = devm_reset_control_get(dev, "ext"); ++ if (IS_ERR(res->ext_reset)) ++ return PTR_ERR(res->ext_reset); ++ ++ if (of_property_read_u8(dev->of_node, "phy-tx0-term-offset", ++ &res->phy_tx0_term_offset)) ++ res->phy_tx0_term_offset = 0; ++ + return 0; + } + +@@ -461,6 +541,57 @@ err_res: + qcom_pcie_disable_resources_v1(pcie); + } + ++static void qcom_pcie_prog_viewport_cfg0(struct qcom_pcie *pcie, u32 busdev) ++{ ++ struct pcie_port *pp = &pcie->pp; ++ ++ /* ++ * program and enable address translation region 0 (device config ++ * address space); region type config; ++ * axi config address range to device config address range ++ */ ++ writel(PCIE20_PLR_IATU_REGION_OUTBOUND | ++ PCIE20_PLR_IATU_REGION_INDEX(0), ++ pcie->dbi + PCIE20_PLR_IATU_VIEWPORT); ++ ++ writel(PCIE20_PLR_IATU_TYPE_CFG0, pcie->dbi + PCIE20_PLR_IATU_CTRL1); ++ writel(PCIE20_PLR_IATU_ENABLE, pcie->dbi + PCIE20_PLR_IATU_CTRL2); ++ writel(pp->cfg0_base, pcie->dbi + PCIE20_PLR_IATU_LBAR); ++ writel((pp->cfg0_base >> 32), pcie->dbi + PCIE20_PLR_IATU_UBAR); ++ writel((pp->cfg0_base + pp->cfg0_size - 1), ++ pcie->dbi + PCIE20_PLR_IATU_LAR); ++ writel(busdev, pcie->dbi + PCIE20_PLR_IATU_LTAR); ++ writel(0, pcie->dbi + PCIE20_PLR_IATU_UTAR); ++} ++ ++static void qcom_pcie_prog_viewport_mem2_outbound(struct qcom_pcie *pcie) ++{ ++ struct pcie_port *pp = &pcie->pp; ++ ++ /* ++ * program and enable address translation region 2 (device resource ++ * address space); region type memory; ++ * axi device bar address range to device bar address range ++ */ ++ writel(PCIE20_PLR_IATU_REGION_OUTBOUND | ++ PCIE20_PLR_IATU_REGION_INDEX(2), ++ pcie->dbi + PCIE20_PLR_IATU_VIEWPORT); ++ ++ writel(PCIE20_PLR_IATU_TYPE_MEM, pcie->dbi + PCIE20_PLR_IATU_CTRL1); ++ writel(PCIE20_PLR_IATU_ENABLE, pcie->dbi + PCIE20_PLR_IATU_CTRL2); ++ writel(pp->mem_base, pcie->dbi + PCIE20_PLR_IATU_LBAR); ++ writel((pp->mem_base >> 32), pcie->dbi + PCIE20_PLR_IATU_UBAR); ++ writel(pp->mem_base + pp->mem_size - 1, ++ pcie->dbi + PCIE20_PLR_IATU_LAR); ++ writel(pp->mem_bus_addr, pcie->dbi + PCIE20_PLR_IATU_LTAR); ++ writel(upper_32_bits(pp->mem_bus_addr), ++ pcie->dbi + PCIE20_PLR_IATU_UTAR); ++ ++ /* 256B PCIE buffer setting */ ++ writel(0x1, pcie->dbi + PCIE20_AXI_MSTR_RESP_COMP_CTRL0); ++ writel(0x1, pcie->dbi + PCIE20_AXI_MSTR_RESP_COMP_CTRL1); ++} ++ + static void qcom_pcie_host_init_v0(struct pcie_port *pp) + { + struct qcom_pcie *pcie = to_qcom_pcie(pp); +@@ -470,15 +601,34 @@ static void qcom_pcie_host_init_v0(struc + + qcom_ep_reset_assert(pcie); + ++ reset_control_assert(res->ahb_reset); ++ + ret = qcom_pcie_enable_resources_v0(pcie); + if (ret) + return; + + writel_masked(pcie->parf + PCIE20_PARF_PHY_CTRL, BIT(0), 0); + +- /* enable external reference clock */ +- writel_masked(pcie->parf + PCIE20_PARF_PHY_REFCLK, 0, BIT(16)); ++ /* Set Tx termination offset */ ++ writel_masked(pcie->parf + PCIE20_PARF_PHY_CTRL, ++ PHY_CTRL_PHY_TX0_TERM_OFFSET_MASK, ++ PHY_CTRL_PHY_TX0_TERM_OFFSET(res->phy_tx0_term_offset)); ++ ++ /* PARF programming */ ++ writel(PCS_DEEMPH_TX_DEEMPH_GEN1(0x18) | ++ PCS_DEEMPH_TX_DEEMPH_GEN2_3_5DB(0x18) | ++ PCS_DEEMPH_TX_DEEMPH_GEN2_6DB(0x22), ++ pcie->parf + PCIE20_PARF_PCS_DEEMPH); ++ writel(PCS_SWING_TX_SWING_FULL(0x78) | ++ PCS_SWING_TX_SWING_LOW(0x78), ++ pcie->parf + PCIE20_PARF_PCS_SWING); ++ writel(PHY_RX0_EQ(0x4), pcie->parf + PCIE20_PARF_CONFIG_BITS); ++ ++ /* Enable reference clock */ ++ writel_masked(pcie->parf + PCIE20_PARF_PHY_REFCLK, ++ REF_USE_PAD, REF_SSP_EN); + ++ /* De-assert PHY, PCIe, POR and AXI resets */ + ret = reset_control_deassert(res->phy_reset); + if (ret) { + dev_err(dev, "cannot deassert phy reset\n"); +@@ -517,6 +667,9 @@ static void qcom_pcie_host_init_v0(struc + if (ret) + goto err; + ++ qcom_pcie_prog_viewport_cfg0(pcie, MSM_PCIE_DEV_CFG_ADDR); ++ qcom_pcie_prog_viewport_mem2_outbound(pcie); ++ + return; + err: + qcom_ep_reset_assert(pcie); diff --git a/target/linux/ipq806x/patches-4.4/115-add-pcie-aux-clk-dts.patch b/target/linux/ipq806x/patches-4.4/115-add-pcie-aux-clk-dts.patch new file mode 100644 index 0000000..8ceace9 --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/115-add-pcie-aux-clk-dts.patch @@ -0,0 +1,80 @@ +--- a/arch/arm/boot/dts/qcom-ipq8064.dtsi ++++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi +@@ -476,15 +476,21 @@ + + clocks = <&gcc PCIE_A_CLK>, + <&gcc PCIE_H_CLK>, +- <&gcc PCIE_PHY_CLK>; +- clock-names = "core", "iface", "phy"; ++ <&gcc PCIE_PHY_CLK>, ++ <&gcc PCIE_AUX_CLK>, ++ <&gcc PCIE_ALT_REF_CLK>; ++ clock-names = "core", "iface", "phy", "aux", "ref"; ++ ++ assigned-clocks = <&gcc PCIE_ALT_REF_CLK>; ++ assigned-clock-rates = <100000000>; + + resets = <&gcc PCIE_ACLK_RESET>, + <&gcc PCIE_HCLK_RESET>, + <&gcc PCIE_POR_RESET>, + <&gcc PCIE_PCI_RESET>, +- <&gcc PCIE_PHY_RESET>; +- reset-names = "axi", "ahb", "por", "pci", "phy"; ++ <&gcc PCIE_PHY_RESET>, ++ <&gcc PCIE_EXT_RESET>; ++ reset-names = "axi", "ahb", "por", "pci", "phy", "ext"; + + pinctrl-0 = <&pcie0_pins>; + pinctrl-names = "default"; +@@ -522,15 +528,21 @@ + + clocks = <&gcc PCIE_1_A_CLK>, + <&gcc PCIE_1_H_CLK>, +- <&gcc PCIE_1_PHY_CLK>; +- clock-names = "core", "iface", "phy"; ++ <&gcc PCIE_1_PHY_CLK>, ++ <&gcc PCIE_1_AUX_CLK>, ++ <&gcc PCIE_1_ALT_REF_CLK>; ++ clock-names = "core", "iface", "phy", "aux", "ref"; ++ ++ assigned-clocks = <&gcc PCIE_1_ALT_REF_CLK>; ++ assigned-clock-rates = <100000000>; + + resets = <&gcc PCIE_1_ACLK_RESET>, + <&gcc PCIE_1_HCLK_RESET>, + <&gcc PCIE_1_POR_RESET>, + <&gcc PCIE_1_PCI_RESET>, +- <&gcc PCIE_1_PHY_RESET>; +- reset-names = "axi", "ahb", "por", "pci", "phy"; ++ <&gcc PCIE_1_PHY_RESET>, ++ <&gcc PCIE_1_EXT_RESET>; ++ reset-names = "axi", "ahb", "por", "pci", "phy", "ext"; + + pinctrl-0 = <&pcie1_pins>; + pinctrl-names = "default"; +@@ -568,15 +580,21 @@ + + clocks = <&gcc PCIE_2_A_CLK>, + <&gcc PCIE_2_H_CLK>, +- <&gcc PCIE_2_PHY_CLK>; +- clock-names = "core", "iface", "phy"; ++ <&gcc PCIE_2_PHY_CLK>, ++ <&gcc PCIE_2_AUX_CLK>, ++ <&gcc PCIE_2_ALT_REF_CLK>; ++ clock-names = "core", "iface", "phy", "aux", "ref"; ++ ++ assigned-clocks = <&gcc PCIE_2_ALT_REF_CLK>; ++ assigned-clock-rates = <100000000>; + + resets = <&gcc PCIE_2_ACLK_RESET>, + <&gcc PCIE_2_HCLK_RESET>, + <&gcc PCIE_2_POR_RESET>, + <&gcc PCIE_2_PCI_RESET>, +- <&gcc PCIE_2_PHY_RESET>; +- reset-names = "axi", "ahb", "por", "pci", "phy"; ++ <&gcc PCIE_2_PHY_RESET>, ++ <&gcc PCIE_2_EXT_RESET>; ++ reset-names = "axi", "ahb", "por", "pci", "phy", "ext"; + + pinctrl-0 = <&pcie2_pins>; + pinctrl-names = "default"; diff --git a/target/linux/ipq806x/patches-4.4/126-add-rpm-to-ipq8064-dts.patch b/target/linux/ipq806x/patches-4.4/126-add-rpm-to-ipq8064-dts.patch new file mode 100644 index 0000000..7daa931 --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/126-add-rpm-to-ipq8064-dts.patch @@ -0,0 +1,87 @@ +--- a/arch/arm/boot/dts/qcom-ipq8064.dtsi ++++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi +@@ -2,6 +2,7 @@ + + #include "skeleton.dtsi" + #include ++#include + #include + #include + #include +@@ -93,6 +94,63 @@ + reg-names = "lpass-lpaif"; + }; + ++ rpm at 108000 { ++ compatible = "qcom,rpm-ipq8064"; ++ reg = <0x108000 0x1000>; ++ qcom,ipc = <&l2cc 0x8 2>; ++ ++ interrupts = <0 19 0>, ++ <0 21 0>, ++ <0 22 0>; ++ interrupt-names = "ack", ++ "err", ++ "wakeup"; ++ ++ #address-cells = <1>; ++ #size-cells = <0>; ++ ++ smb208_s1a: smb208-s1a { ++ compatible = "qcom,rpm-smb208"; ++ reg = ; ++ ++ regulator-min-microvolt = <1050000>; ++ regulator-max-microvolt = <1150000>; ++ ++ qcom,switch-mode-frequency = <1200000>; ++ ++ }; ++ ++ smb208_s1b: smb208-s1b { ++ compatible = "qcom,rpm-smb208"; ++ reg = ; ++ ++ regulator-min-microvolt = <1050000>; ++ regulator-max-microvolt = <1150000>; ++ ++ qcom,switch-mode-frequency = <1200000>; ++ }; ++ ++ smb208_s2a: smb208-s2a { ++ compatible = "qcom,rpm-smb208"; ++ reg = ; ++ ++ regulator-min-microvolt = < 800000>; ++ regulator-max-microvolt = <1250000>; ++ ++ qcom,switch-mode-frequency = <1200000>; ++ }; ++ ++ smb208_s2b: smb208-s2b { ++ compatible = "qcom,rpm-smb208"; ++ reg = ; ++ ++ regulator-min-microvolt = < 800000>; ++ regulator-max-microvolt = <1250000>; ++ ++ qcom,switch-mode-frequency = <1200000>; ++ }; ++ }; ++ + qcom_pinmux: pinmux at 800000 { + compatible = "qcom,ipq8064-pinctrl"; + reg = <0x800000 0x4000>; +@@ -164,6 +222,12 @@ + reg = <0x02098000 0x1000>, <0x02008000 0x1000>; + }; + ++ l2cc: clock-controller at 2011000 { ++ compatible = "qcom,kpss-gcc", "syscon"; ++ reg = <0x2011000 0x1000>; ++ clock-output-names = "acpu_l2_aux"; ++ }; ++ + saw0: regulator at 2089000 { + compatible = "qcom,saw2"; + reg = <0x02089000 0x1000>, <0x02009000 0x1000>; diff --git a/target/linux/ipq806x/patches-4.4/133-ARM-Add-Krait-L2-register-accessor-functions.patch b/target/linux/ipq806x/patches-4.4/133-ARM-Add-Krait-L2-register-accessor-functions.patch new file mode 100644 index 0000000..01bd749 --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/133-ARM-Add-Krait-L2-register-accessor-functions.patch @@ -0,0 +1,144 @@ +Content-Type: text/plain; charset="utf-8" +MIME-Version: 1.0 +Content-Transfer-Encoding: 7bit +Subject: [v3,01/13] ARM: Add Krait L2 register accessor functions +From: Stephen Boyd +X-Patchwork-Id: 6063051 +Message-Id: <1426920332-9340-2-git-send-email-sboyd at codeaurora.org> +To: Mike Turquette , Stephen Boyd +Cc: linux-kernel at vger.kernel.org, linux-arm-msm at vger.kernel.org, + linux-pm at vger.kernel.org, linux-arm-kernel at lists.infradead.org, + Viresh Kumar , + Mark Rutland , Russell King , + Courtney Cavin +Date: Fri, 20 Mar 2015 23:45:20 -0700 + +Krait CPUs have a handful of L2 cache controller registers that +live behind a cp15 based indirection register. First you program +the indirection register (l2cpselr) to point the L2 'window' +register (l2cpdr) at what you want to read/write. Then you +read/write the 'window' register to do what you want. The +l2cpselr register is not banked per-cpu so we must lock around +accesses to it to prevent other CPUs from re-pointing l2cpdr +underneath us. + +Cc: Mark Rutland +Cc: Russell King +Cc: Courtney Cavin +Signed-off-by: Stephen Boyd + +--- +arch/arm/common/Kconfig | 3 ++ + arch/arm/common/Makefile | 1 + + arch/arm/common/krait-l2-accessors.c | 58 +++++++++++++++++++++++++++++++ + arch/arm/include/asm/krait-l2-accessors.h | 20 +++++++++++ + 4 files changed, 82 insertions(+) + create mode 100644 arch/arm/common/krait-l2-accessors.c + create mode 100644 arch/arm/include/asm/krait-l2-accessors.h + +--- a/arch/arm/common/Kconfig ++++ b/arch/arm/common/Kconfig +@@ -9,6 +9,9 @@ + bool + select ZONE_DMA + ++config KRAIT_L2_ACCESSORS ++ bool ++ + config SHARP_LOCOMO + bool + +--- a/arch/arm/common/Makefile ++++ b/arch/arm/common/Makefile +@@ -7,6 +7,7 @@ + obj-$(CONFIG_ICST) += icst.o + obj-$(CONFIG_SA1111) += sa1111.o + obj-$(CONFIG_DMABOUNCE) += dmabounce.o ++obj-$(CONFIG_KRAIT_L2_ACCESSORS) += krait-l2-accessors.o + obj-$(CONFIG_SHARP_LOCOMO) += locomo.o + obj-$(CONFIG_SHARP_PARAM) += sharpsl_param.o + obj-$(CONFIG_SHARP_SCOOP) += scoop.o +--- /dev/null ++++ b/arch/arm/common/krait-l2-accessors.c +@@ -0,0 +1,58 @@ ++/* ++ * Copyright (c) 2011-2013, The Linux Foundation. All rights reserved. ++ * ++ * This program is free software; you can redistribute it and/or modify ++ * it under the terms of the GNU General Public License version 2 and ++ * only version 2 as published by the Free Software Foundation. ++ * ++ * 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. ++ */ ++ ++#include ++#include ++ ++#include ++#include ++ ++static DEFINE_RAW_SPINLOCK(krait_l2_lock); ++ ++void krait_set_l2_indirect_reg(u32 addr, u32 val) ++{ ++ unsigned long flags; ++ ++ raw_spin_lock_irqsave(&krait_l2_lock, flags); ++ /* ++ * Select the L2 window by poking l2cpselr, then write to the window ++ * via l2cpdr. ++ */ ++ asm volatile ("mcr p15, 3, %0, c15, c0, 6 @ l2cpselr" : : "r" (addr)); ++ isb(); ++ asm volatile ("mcr p15, 3, %0, c15, c0, 7 @ l2cpdr" : : "r" (val)); ++ isb(); ++ ++ raw_spin_unlock_irqrestore(&krait_l2_lock, flags); ++} ++EXPORT_SYMBOL(krait_set_l2_indirect_reg); ++ ++u32 krait_get_l2_indirect_reg(u32 addr) ++{ ++ u32 val; ++ unsigned long flags; ++ ++ raw_spin_lock_irqsave(&krait_l2_lock, flags); ++ /* ++ * Select the L2 window by poking l2cpselr, then read from the window ++ * via l2cpdr. ++ */ ++ asm volatile ("mcr p15, 3, %0, c15, c0, 6 @ l2cpselr" : : "r" (addr)); ++ isb(); ++ asm volatile ("mrc p15, 3, %0, c15, c0, 7 @ l2cpdr" : "=r" (val)); ++ ++ raw_spin_unlock_irqrestore(&krait_l2_lock, flags); ++ ++ return val; ++} ++EXPORT_SYMBOL(krait_get_l2_indirect_reg); +--- /dev/null ++++ b/arch/arm/include/asm/krait-l2-accessors.h +@@ -0,0 +1,20 @@ ++/* ++ * Copyright (c) 2011-2013, The Linux Foundation. All rights reserved. ++ * ++ * This program is free software; you can redistribute it and/or modify ++ * it under the terms of the GNU General Public License version 2 and ++ * only version 2 as published by the Free Software Foundation. ++ * ++ * 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. ++ */ ++ ++#ifndef __ASMARM_KRAIT_L2_ACCESSORS_H ++#define __ASMARM_KRAIT_L2_ACCESSORS_H ++ ++extern void krait_set_l2_indirect_reg(u32 addr, u32 val); ++extern u32 krait_get_l2_indirect_reg(u32 addr); ++ ++#endif diff --git a/target/linux/ipq806x/patches-4.4/134-clk-mux-Split-out-register-accessors-for-reuse.patch b/target/linux/ipq806x/patches-4.4/134-clk-mux-Split-out-register-accessors-for-reuse.patch new file mode 100644 index 0000000..acf5820 --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/134-clk-mux-Split-out-register-accessors-for-reuse.patch @@ -0,0 +1,184 @@ +From 4c28a15ea536281c8d619e5c6716ade914c79a6e Mon Sep 17 00:00:00 2001 +From: Stephen Boyd +Date: Fri, 20 Mar 2015 23:45:21 -0700 +Subject: [PATCH 1/2] clk: mux: Split out register accessors for reuse + +We want to reuse the logic in clk-mux.c for other clock drivers +that don't use readl as register accessors. Fortunately, there +really isn't much to the mux code besides the table indirection +and quirk flags if you assume any bit shifting and masking has +been done already. Pull that logic out into reusable functions +that operate on an optional table and some flags so that other +drivers can use the same logic. + +Signed-off-by: Stephen Boyd +Signed-off-by: Ram Chandra Jangir +--- + drivers/clk/clk-mux.c | 74 +++++++++++++++++++++++++++----------------- + include/linux/clk-provider.h | 9 ++++-- + 2 files changed, 53 insertions(+), 30 deletions(-) + +diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c +index 7129c86..b03a34d 100644 +--- a/drivers/clk/clk-mux.c ++++ b/drivers/clk/clk-mux.c +@@ -28,35 +28,24 @@ + + #define to_clk_mux(_hw) container_of(_hw, struct clk_mux, hw) + +-static u8 clk_mux_get_parent(struct clk_hw *hw) ++unsigned int clk_mux_get_parent(struct clk_hw *hw, unsigned int val, ++ unsigned int *table, unsigned long flags) + { +- struct clk_mux *mux = to_clk_mux(hw); + int num_parents = clk_hw_get_num_parents(hw); +- u32 val; + +- /* +- * FIXME need a mux-specific flag to determine if val is bitwise or numeric +- * e.g. sys_clkin_ck's clksel field is 3 bits wide, but ranges from 0x1 +- * to 0x7 (index starts at one) +- * OTOH, pmd_trace_clk_mux_ck uses a separate bit for each clock, so +- * val = 0x4 really means "bit 2, index starts at bit 0" +- */ +- val = clk_readl(mux->reg) >> mux->shift; +- val &= mux->mask; +- +- if (mux->table) { ++ if (table) { + int i; + + for (i = 0; i < num_parents; i++) +- if (mux->table[i] == val) ++ if (table[i] == val) + return i; + return -EINVAL; + } + +- if (val && (mux->flags & CLK_MUX_INDEX_BIT)) ++ if (val && (flags & CLK_MUX_INDEX_BIT)) + val = ffs(val) - 1; + +- if (val && (mux->flags & CLK_MUX_INDEX_ONE)) ++ if (val && (flags & CLK_MUX_INDEX_ONE)) + val--; + + if (val >= num_parents) +@@ -64,24 +53,53 @@ static u8 clk_mux_get_parent(struct clk_hw *hw) + + return val; + } ++EXPORT_SYMBOL_GPL(clk_mux_get_parent); + +-static int clk_mux_set_parent(struct clk_hw *hw, u8 index) ++static u8 _clk_mux_get_parent(struct clk_hw *hw) + { + struct clk_mux *mux = to_clk_mux(hw); + u32 val; +- unsigned long flags = 0; + +- if (mux->table) +- index = mux->table[index]; ++ /* ++ * FIXME need a mux-specific flag to determine if val is bitwise or numeric ++ * e.g. sys_clkin_ck's clksel field is 3 bits wide, but ranges from 0x1 ++ * to 0x7 (index starts at one) ++ * OTOH, pmd_trace_clk_mux_ck uses a separate bit for each clock, so ++ * val = 0x4 really means "bit 2, index starts at bit 0" ++ */ ++ val = clk_readl(mux->reg) >> mux->shift; ++ val &= mux->mask; + +- else { +- if (mux->flags & CLK_MUX_INDEX_BIT) +- index = 1 << index; ++ return clk_mux_get_parent(hw, val, mux->table, mux->flags); ++} ++ ++unsigned int clk_mux_reindex(u8 index, unsigned int *table, ++ unsigned long flags) ++{ ++ unsigned int val = index; + +- if (mux->flags & CLK_MUX_INDEX_ONE) +- index++; ++ if (table) { ++ val = table[val]; ++ } else { ++ if (flags & CLK_MUX_INDEX_BIT) ++ val = 1 << index; ++ ++ if (flags & CLK_MUX_INDEX_ONE) ++ val++; + } + ++ return val; ++} ++EXPORT_SYMBOL_GPL(clk_mux_reindex); ++ ++static int clk_mux_set_parent(struct clk_hw *hw, u8 index) ++{ ++ struct clk_mux *mux = to_clk_mux(hw); ++ u32 val; ++ unsigned long flags = 0; ++ ++ index = clk_mux_reindex(index, mux->table, mux->flags); ++ + if (mux->lock) + spin_lock_irqsave(mux->lock, flags); + else +@@ -105,7 +123,7 @@ static int clk_mux_set_parent(struct clk_hw *hw, u8 index) + } + + const struct clk_ops clk_mux_ops = { +- .get_parent = clk_mux_get_parent, ++ .get_parent = _clk_mux_get_parent, + .set_parent = clk_mux_set_parent, + .determine_rate = __clk_mux_determine_rate, + }; +@@ -120,7 +138,7 @@ struct clk *clk_register_mux_table(struct device *dev, const char *name, + const char * const *parent_names, u8 num_parents, + unsigned long flags, + void __iomem *reg, u8 shift, u32 mask, +- u8 clk_mux_flags, u32 *table, spinlock_t *lock) ++ u8 clk_mux_flags, unsigned int *table, spinlock_t *lock) + { + struct clk_mux *mux; + struct clk *clk; +diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h +index c56988a..b6b17b5 100644 +--- a/include/linux/clk-provider.h ++++ b/include/linux/clk-provider.h +@@ -432,7 +432,7 @@ void clk_unregister_divider(struct clk *clk); + struct clk_mux { + struct clk_hw hw; + void __iomem *reg; +- u32 *table; ++ unsigned int *table; + u32 mask; + u8 shift; + u8 flags; +@@ -448,6 +448,11 @@ struct clk_mux { + extern const struct clk_ops clk_mux_ops; + extern const struct clk_ops clk_mux_ro_ops; + ++unsigned int clk_mux_get_parent(struct clk_hw *hw, unsigned int val, ++ unsigned int *table, unsigned long flags); ++unsigned int clk_mux_reindex(u8 index, unsigned int *table, ++ unsigned long flags); ++ + struct clk *clk_register_mux(struct device *dev, const char *name, + const char * const *parent_names, u8 num_parents, + unsigned long flags, +@@ -458,7 +463,7 @@ struct clk *clk_register_mux_table(struct device *dev, const char *name, + const char * const *parent_names, u8 num_parents, + unsigned long flags, + void __iomem *reg, u8 shift, u32 mask, +- u8 clk_mux_flags, u32 *table, spinlock_t *lock); ++ u8 clk_mux_flags, unsigned int *table, spinlock_t *lock); + + void clk_unregister_mux(struct clk *clk); + +-- +2.7.2 + diff --git a/target/linux/ipq806x/patches-4.4/135-clk-Avoid-sending-high-rates-to-downstream-clocks-du.patch b/target/linux/ipq806x/patches-4.4/135-clk-Avoid-sending-high-rates-to-downstream-clocks-du.patch new file mode 100644 index 0000000..5df0a56 --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/135-clk-Avoid-sending-high-rates-to-downstream-clocks-du.patch @@ -0,0 +1,127 @@ +From 39d42ce5031d2a4f92fa203b87acfbab340b15a2 Mon Sep 17 00:00:00 2001 +From: Stephen Boyd +Date: Fri, 20 Mar 2015 23:45:22 -0700 +Subject: [PATCH 2/2] clk: Avoid sending high rates to downstream clocks during + set_rate + +If a clock is on and we call clk_set_rate() on it we may get into +a situation where the clock temporarily increases in rate +dramatically while we walk the tree and call .set_rate() ops. For +example, consider a case where a PLL feeds into a divider. +Initially the divider is set to divide by 1 and the PLL is +running fairly slow (100MHz). The downstream consumer of the +divider output can only handle rates =< 400 MHz, but the divider +can only choose between divisors of 1 and 4. + + +-----+ +----------------+ + | PLL |-->| div 1 or div 4 |---> consumer device + +-----+ +----------------+ + +To achieve a rate of 400MHz on the output of the divider, we +would have to set the rate of the PLL to 1.6 GHz and then divide +it by 4. The current code would set the PLL to 1.6GHz first while +the divider is still set to 1, thus causing the downstream +consumer of the clock to receive a few clock cycles of 1.6GHz +clock (far beyond it's maximum acceptable rate). We should be +changing the divider first before increasing the PLL rate to +avoid this problem. + +Therefore, set the rate of any child clocks that are increasing +in rate from their current rate so that they can increase their +dividers if necessary. We assume that there isn't such a thing as +minimum rate requirements. + +Signed-off-by: Stephen Boyd +Signed-off-by: Ram Chandra Jangir +--- + drivers/clk/clk.c | 34 ++++++++++++++++++++++------------ + 1 file changed, 22 insertions(+), 12 deletions(-) + +diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c +index f13c3f4..8404c3c 100644 +--- a/drivers/clk/clk.c ++++ b/drivers/clk/clk.c +@@ -1427,21 +1427,24 @@ static struct clk_core *clk_propagate_rate_change(struct clk_core *core, + * walk down a subtree and set the new rates notifying the rate + * change on the way + */ +-static void clk_change_rate(struct clk_core *core) ++static void ++clk_change_rate(struct clk_core *core, unsigned long best_parent_rate) + { + struct clk_core *child; + struct hlist_node *tmp; + unsigned long old_rate; +- unsigned long best_parent_rate = 0; + bool skip_set_rate = false; + struct clk_core *old_parent; + +- old_rate = core->rate; ++ hlist_for_each_entry(child, &core->children, child_node) { ++ /* Skip children who will be reparented to another clock */ ++ if (child->new_parent && child->new_parent != core) ++ continue; ++ if (child->new_rate > child->rate) ++ clk_change_rate(child, core->new_rate); ++ } + +- if (core->new_parent) +- best_parent_rate = core->new_parent->rate; +- else if (core->parent) +- best_parent_rate = core->parent->rate; ++ old_rate = core->rate; + + if (core->new_parent && core->new_parent != core->parent) { + old_parent = __clk_set_parent_before(core, core->new_parent); +@@ -1467,7 +1470,7 @@ static void clk_change_rate(struct clk_core *core) + + trace_clk_set_rate_complete(core, core->new_rate); + +- core->rate = clk_recalc(core, best_parent_rate); ++ core->rate = core->new_rate; + + if (core->notifier_count && old_rate != core->rate) + __clk_notify(core, POST_RATE_CHANGE, old_rate, core->rate); +@@ -1483,12 +1486,13 @@ static void clk_change_rate(struct clk_core *core) + /* Skip children who will be reparented to another clock */ + if (child->new_parent && child->new_parent != core) + continue; +- clk_change_rate(child); ++ if (child->new_rate != child->rate) ++ clk_change_rate(child, core->new_rate); + } + + /* handle the new child who might not be in core->children yet */ +- if (core->new_child) +- clk_change_rate(core->new_child); ++ if (core->new_child && core->new_child->new_rate != core->new_child->rate) ++ clk_change_rate(core->new_child, core->new_rate); + } + + static int clk_core_set_rate_nolock(struct clk_core *core, +@@ -1497,6 +1501,7 @@ static int clk_core_set_rate_nolock(struct clk_core *core, + struct clk_core *top, *fail_clk; + unsigned long rate = req_rate; + int ret = 0; ++ unsigned long parent_rate; + + if (!core) + return 0; +@@ -1522,8 +1527,13 @@ static int clk_core_set_rate_nolock(struct clk_core *core, + return -EBUSY; + } + ++ if (top->parent) ++ parent_rate = top->parent->rate; ++ else ++ parent_rate = 0; ++ + /* change the rates */ +- clk_change_rate(top); ++ clk_change_rate(top, parent_rate); + + core->req_rate = req_rate; + +-- +2.7.2 + diff --git a/target/linux/ipq806x/patches-4.4/136-clk-Add-safe-switch-hook.patch b/target/linux/ipq806x/patches-4.4/136-clk-Add-safe-switch-hook.patch new file mode 100644 index 0000000..e969f6b --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/136-clk-Add-safe-switch-hook.patch @@ -0,0 +1,158 @@ +From f7a00ea959be31f9b742042294a359d508edce94 Mon Sep 17 00:00:00 2001 +From: Stephen Boyd +Date: Fri, 20 Mar 2015 23:45:23 -0700 +Subject: [PATCH] clk: Add safe switch hook + +Sometimes clocks can't accept their parent source turning off +while the source is reprogrammed to a different rate. Most +notably CPU clocks require a way to switch away from the current +PLL they're running on, reprogram that PLL to a new rate, and +then switch back to the PLL with the new rate once they're done. +Add a hook that drivers can implement allowing them to return a +'safe parent' that they can switch their parent to while the +upstream source is reprogrammed to support this. + +Signed-off-by: Stephen Boyd +Signed-off-by: Ram Chandra Jangir +--- + drivers/clk/clk.c | 61 ++++++++++++++++++++++++++++++++++++++------ + include/linux/clk-provider.h | 1 + + 2 files changed, 54 insertions(+), 8 deletions(-) + +diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c +index 8404c3c..a29319a 100644 +--- a/drivers/clk/clk.c ++++ b/drivers/clk/clk.c +@@ -51,9 +51,12 @@ struct clk_core { + struct clk_core **parents; + u8 num_parents; + u8 new_parent_index; ++ u8 safe_parent_index; + unsigned long rate; + unsigned long req_rate; ++ unsigned long old_rate; + unsigned long new_rate; ++ struct clk_core *safe_parent; + struct clk_core *new_parent; + struct clk_core *new_child; + unsigned long flags; +@@ -1271,7 +1274,8 @@ out: + static void clk_calc_subtree(struct clk_core *core, unsigned long new_rate, + struct clk_core *new_parent, u8 p_index) + { +- struct clk_core *child; ++ struct clk_core *child, *parent; ++ struct clk_hw *parent_hw; + + core->new_rate = new_rate; + core->new_parent = new_parent; +@@ -1281,6 +1285,18 @@ static void clk_calc_subtree(struct clk_core *core, unsigned long new_rate, + if (new_parent && new_parent != core->parent) + new_parent->new_child = core; + ++ if (core->ops->get_safe_parent) { ++ parent_hw = core->ops->get_safe_parent(core->hw); ++ if (parent_hw) { ++ parent = parent_hw->core; ++ p_index = clk_fetch_parent_index(core, parent); ++ core->safe_parent_index = p_index; ++ core->safe_parent = parent; ++ } ++ } else { ++ core->safe_parent = NULL; ++ } ++ + hlist_for_each_entry(child, &core->children, child_node) { + child->new_rate = clk_recalc(child, new_rate); + clk_calc_subtree(child, child->new_rate, NULL, 0); +@@ -1393,14 +1409,43 @@ static struct clk_core *clk_propagate_rate_change(struct clk_core *core, + unsigned long event) + { + struct clk_core *child, *tmp_clk, *fail_clk = NULL; ++ struct clk_core *old_parent; + int ret = NOTIFY_DONE; + +- if (core->rate == core->new_rate) ++ if (core->rate == core->new_rate && event != POST_RATE_CHANGE) + return NULL; + ++ switch (event) { ++ case PRE_RATE_CHANGE: ++ if (core->safe_parent) ++ core->ops->set_parent(core->hw, core->safe_parent_index); ++ core->old_rate = core->rate; ++ break; ++ case POST_RATE_CHANGE: ++ if (core->safe_parent) { ++ old_parent = __clk_set_parent_before(core, ++ core->new_parent); ++ if (core->ops->set_rate_and_parent) { ++ core->ops->set_rate_and_parent(core->hw, ++ core->new_rate, ++ core->new_parent ? ++ core->new_parent->rate : 0, ++ core->new_parent_index); ++ } else if (core->ops->set_parent) { ++ core->ops->set_parent(core->hw, ++ core->new_parent_index); ++ } ++ __clk_set_parent_after(core, core->new_parent, ++ old_parent); ++ } ++ break; ++ } ++ + if (core->notifier_count) { +- ret = __clk_notify(core, event, core->rate, core->new_rate); +- if (ret & NOTIFY_STOP_MASK) ++ if (event != POST_RATE_CHANGE || core->old_rate != core->rate) ++ ret = __clk_notify(core, event, core->old_rate, ++ core->new_rate); ++ if (ret & NOTIFY_STOP_MASK && event != POST_RATE_CHANGE) + fail_clk = core; + } + +@@ -1446,7 +1491,8 @@ clk_change_rate(struct clk_core *core, unsigned long best_parent_rate) + + old_rate = core->rate; + +- if (core->new_parent && core->new_parent != core->parent) { ++ if (core->new_parent && core->new_parent != core->parent && ++ !core->safe_parent) { + old_parent = __clk_set_parent_before(core, core->new_parent); + trace_clk_set_parent(core, core->new_parent); + +@@ -1472,9 +1518,6 @@ clk_change_rate(struct clk_core *core, unsigned long best_parent_rate) + + core->rate = core->new_rate; + +- if (core->notifier_count && old_rate != core->rate) +- __clk_notify(core, POST_RATE_CHANGE, old_rate, core->rate); +- + if (core->flags & CLK_RECALC_NEW_RATES) + (void)clk_calc_new_rates(core, core->new_rate); + +@@ -1537,6 +1580,8 @@ static int clk_core_set_rate_nolock(struct clk_core *core, + + core->req_rate = req_rate; + ++ clk_propagate_rate_change(top, POST_RATE_CHANGE); ++ + return ret; + } + +diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h +index b6b17b5..5d49262 100644 +--- a/include/linux/clk-provider.h ++++ b/include/linux/clk-provider.h +@@ -202,6 +202,7 @@ struct clk_ops { + struct clk_rate_request *req); + int (*set_parent)(struct clk_hw *hw, u8 index); + u8 (*get_parent)(struct clk_hw *hw); ++ struct clk_hw *(*get_safe_parent)(struct clk_hw *hw); + int (*set_rate)(struct clk_hw *hw, unsigned long rate, + unsigned long parent_rate); + int (*set_rate_and_parent)(struct clk_hw *hw, +-- +2.7.2 + diff --git a/target/linux/ipq806x/patches-4.4/137-clk-qcom-Add-support-for-High-Frequency-PLLs-HFPLLs.patch b/target/linux/ipq806x/patches-4.4/137-clk-qcom-Add-support-for-High-Frequency-PLLs-HFPLLs.patch new file mode 100644 index 0000000..a1b1f4b --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/137-clk-qcom-Add-support-for-High-Frequency-PLLs-HFPLLs.patch @@ -0,0 +1,351 @@ +Content-Type: text/plain; charset="utf-8" +MIME-Version: 1.0 +Content-Transfer-Encoding: 7bit +Subject: [v3,05/13] clk: qcom: Add support for High-Frequency PLLs (HFPLLs) +From: Stephen Boyd +X-Patchwork-Id: 6063261 +Message-Id: <1426920332-9340-6-git-send-email-sboyd at codeaurora.org> +To: Mike Turquette , Stephen Boyd +Cc: linux-kernel at vger.kernel.org, linux-arm-msm at vger.kernel.org, + linux-pm at vger.kernel.org, linux-arm-kernel at lists.infradead.org, + Viresh Kumar +Date: Fri, 20 Mar 2015 23:45:24 -0700 + +HFPLLs are the main frequency source for Krait CPU clocks. Add +support for changing the rate of these PLLs. + +Signed-off-by: Stephen Boyd + +--- +I'd really like to get rid of __clk_hfpll_init_once() if possible... + + drivers/clk/qcom/Makefile | 1 + + drivers/clk/qcom/clk-hfpll.c | 253 +++++++++++++++++++++++++++++++++++++++++++ + drivers/clk/qcom/clk-hfpll.h | 54 +++++++++ + 3 files changed, 308 insertions(+) + create mode 100644 drivers/clk/qcom/clk-hfpll.c + create mode 100644 drivers/clk/qcom/clk-hfpll.h + +--- a/drivers/clk/qcom/Makefile ++++ b/drivers/clk/qcom/Makefile +@@ -8,6 +8,7 @@ + clk-qcom-y += clk-branch.o + clk-qcom-y += clk-regmap-divider.o + clk-qcom-y += clk-regmap-mux.o ++clk-qcom-y += clk-hfpll.o + clk-qcom-y += reset.o + clk-qcom-$(CONFIG_QCOM_GDSC) += gdsc.o + +--- /dev/null ++++ b/drivers/clk/qcom/clk-hfpll.c +@@ -0,0 +1,253 @@ ++/* ++ * Copyright (c) 2013-2014, The Linux Foundation. All rights reserved. ++ * ++ * This program is free software; you can redistribute it and/or modify ++ * it under the terms of the GNU General Public License version 2 and ++ * only version 2 as published by the Free Software Foundation. ++ * ++ * 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. ++ */ ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++ ++#include "clk-regmap.h" ++#include "clk-hfpll.h" ++ ++#define PLL_OUTCTRL BIT(0) ++#define PLL_BYPASSNL BIT(1) ++#define PLL_RESET_N BIT(2) ++ ++/* Initialize a HFPLL at a given rate and enable it. */ ++static void __clk_hfpll_init_once(struct clk_hw *hw) ++{ ++ struct clk_hfpll *h = to_clk_hfpll(hw); ++ struct hfpll_data const *hd = h->d; ++ struct regmap *regmap = h->clkr.regmap; ++ ++ if (likely(h->init_done)) ++ return; ++ ++ /* Configure PLL parameters for integer mode. */ ++ if (hd->config_val) ++ regmap_write(regmap, hd->config_reg, hd->config_val); ++ regmap_write(regmap, hd->m_reg, 0); ++ regmap_write(regmap, hd->n_reg, 1); ++ ++ if (hd->user_reg) { ++ u32 regval = hd->user_val; ++ unsigned long rate; ++ ++ rate = clk_hw_get_rate(hw->clk); ++ ++ /* Pick the right VCO. */ ++ if (hd->user_vco_mask && rate > hd->low_vco_max_rate) ++ regval |= hd->user_vco_mask; ++ regmap_write(regmap, hd->user_reg, regval); ++ } ++ ++ if (hd->droop_reg) ++ regmap_write(regmap, hd->droop_reg, hd->droop_val); ++ ++ h->init_done = true; ++} ++ ++static void __clk_hfpll_enable(struct clk_hw *hw) ++{ ++ struct clk_hfpll *h = to_clk_hfpll(hw); ++ struct hfpll_data const *hd = h->d; ++ struct regmap *regmap = h->clkr.regmap; ++ u32 val; ++ ++ __clk_hfpll_init_once(hw); ++ ++ /* Disable PLL bypass mode. */ ++ regmap_update_bits(regmap, hd->mode_reg, PLL_BYPASSNL, PLL_BYPASSNL); ++ ++ /* ++ * H/W requires a 5us delay between disabling the bypass and ++ * de-asserting the reset. Delay 10us just to be safe. ++ */ ++ udelay(10); ++ ++ /* De-assert active-low PLL reset. */ ++ regmap_update_bits(regmap, hd->mode_reg, PLL_RESET_N, PLL_RESET_N); ++ ++ /* Wait for PLL to lock. */ ++ if (hd->status_reg) { ++ do { ++ regmap_read(regmap, hd->status_reg, &val); ++ } while (!(val & BIT(hd->lock_bit))); ++ } else { ++ udelay(60); ++ } ++ ++ /* Enable PLL output. */ ++ regmap_update_bits(regmap, hd->mode_reg, PLL_OUTCTRL, PLL_OUTCTRL); ++} ++ ++/* Enable an already-configured HFPLL. */ ++static int clk_hfpll_enable(struct clk_hw *hw) ++{ ++ unsigned long flags; ++ struct clk_hfpll *h = to_clk_hfpll(hw); ++ struct hfpll_data const *hd = h->d; ++ struct regmap *regmap = h->clkr.regmap; ++ u32 mode; ++ ++ spin_lock_irqsave(&h->lock, flags); ++ regmap_read(regmap, hd->mode_reg, &mode); ++ if (!(mode & (PLL_BYPASSNL | PLL_RESET_N | PLL_OUTCTRL))) ++ __clk_hfpll_enable(hw); ++ spin_unlock_irqrestore(&h->lock, flags); ++ ++ return 0; ++} ++ ++static void __clk_hfpll_disable(struct clk_hfpll *h) ++{ ++ struct hfpll_data const *hd = h->d; ++ struct regmap *regmap = h->clkr.regmap; ++ ++ /* ++ * Disable the PLL output, disable test mode, enable the bypass mode, ++ * and assert the reset. ++ */ ++ regmap_update_bits(regmap, hd->mode_reg, ++ PLL_BYPASSNL | PLL_RESET_N | PLL_OUTCTRL, 0); ++} ++ ++static void clk_hfpll_disable(struct clk_hw *hw) ++{ ++ struct clk_hfpll *h = to_clk_hfpll(hw); ++ unsigned long flags; ++ ++ spin_lock_irqsave(&h->lock, flags); ++ __clk_hfpll_disable(h); ++ spin_unlock_irqrestore(&h->lock, flags); ++} ++ ++static long clk_hfpll_round_rate(struct clk_hw *hw, unsigned long rate, ++ unsigned long *parent_rate) ++{ ++ struct clk_hfpll *h = to_clk_hfpll(hw); ++ struct hfpll_data const *hd = h->d; ++ unsigned long rrate; ++ ++ rate = clamp(rate, hd->min_rate, hd->max_rate); ++ ++ rrate = DIV_ROUND_UP(rate, *parent_rate) * *parent_rate; ++ if (rrate > hd->max_rate) ++ rrate -= *parent_rate; ++ ++ return rrate; ++} ++ ++/* ++ * For optimization reasons, assumes no downstream clocks are actively using ++ * it. ++ */ ++static int clk_hfpll_set_rate(struct clk_hw *hw, unsigned long rate, ++ unsigned long parent_rate) ++{ ++ struct clk_hfpll *h = to_clk_hfpll(hw); ++ struct hfpll_data const *hd = h->d; ++ struct regmap *regmap = h->clkr.regmap; ++ unsigned long flags; ++ u32 l_val, val; ++ bool enabled; ++ ++ l_val = rate / parent_rate; ++ ++ spin_lock_irqsave(&h->lock, flags); ++ ++ enabled = __clk_is_enabled(hw->clk); ++ if (enabled) ++ __clk_hfpll_disable(h); ++ ++ /* Pick the right VCO. */ ++ if (hd->user_reg && hd->user_vco_mask) { ++ regmap_read(regmap, hd->user_reg, &val); ++ if (rate <= hd->low_vco_max_rate) ++ val &= ~hd->user_vco_mask; ++ else ++ val |= hd->user_vco_mask; ++ regmap_write(regmap, hd->user_reg, val); ++ } ++ ++ regmap_write(regmap, hd->l_reg, l_val); ++ ++ if (enabled) ++ __clk_hfpll_enable(hw); ++ ++ spin_unlock_irqrestore(&h->lock, flags); ++ ++ return 0; ++} ++ ++static unsigned long clk_hfpll_recalc_rate(struct clk_hw *hw, ++ unsigned long parent_rate) ++{ ++ struct clk_hfpll *h = to_clk_hfpll(hw); ++ struct hfpll_data const *hd = h->d; ++ struct regmap *regmap = h->clkr.regmap; ++ u32 l_val; ++ ++ regmap_read(regmap, hd->l_reg, &l_val); ++ ++ return l_val * parent_rate; ++} ++ ++static void clk_hfpll_init(struct clk_hw *hw) ++{ ++ struct clk_hfpll *h = to_clk_hfpll(hw); ++ struct hfpll_data const *hd = h->d; ++ struct regmap *regmap = h->clkr.regmap; ++ u32 mode, status; ++ ++ regmap_read(regmap, hd->mode_reg, &mode); ++ if (mode != (PLL_BYPASSNL | PLL_RESET_N | PLL_OUTCTRL)) { ++ __clk_hfpll_init_once(hw); ++ return; ++ } ++ ++ if (hd->status_reg) { ++ regmap_read(regmap, hd->status_reg, &status); ++ if (!(status & BIT(hd->lock_bit))) { ++ WARN(1, "HFPLL %s is ON, but not locked!\n", ++ __clk_get_name(hw->clk)); ++ clk_hfpll_disable(hw); ++ __clk_hfpll_init_once(hw); ++ } ++ } ++} ++ ++static int hfpll_is_enabled(struct clk_hw *hw) ++{ ++ struct clk_hfpll *h = to_clk_hfpll(hw); ++ struct hfpll_data const *hd = h->d; ++ struct regmap *regmap = h->clkr.regmap; ++ u32 mode; ++ ++ regmap_read(regmap, hd->mode_reg, &mode); ++ mode &= 0x7; ++ return mode == (PLL_BYPASSNL | PLL_RESET_N | PLL_OUTCTRL); ++} ++ ++const struct clk_ops clk_ops_hfpll = { ++ .enable = clk_hfpll_enable, ++ .disable = clk_hfpll_disable, ++ .is_enabled = hfpll_is_enabled, ++ .round_rate = clk_hfpll_round_rate, ++ .set_rate = clk_hfpll_set_rate, ++ .recalc_rate = clk_hfpll_recalc_rate, ++ .init = clk_hfpll_init, ++}; ++EXPORT_SYMBOL_GPL(clk_ops_hfpll); +--- /dev/null ++++ b/drivers/clk/qcom/clk-hfpll.h +@@ -0,0 +1,54 @@ ++/* ++ * Copyright (c) 2013-2014, The Linux Foundation. All rights reserved. ++ * ++ * This program is free software; you can redistribute it and/or modify ++ * it under the terms of the GNU General Public License version 2 and ++ * only version 2 as published by the Free Software Foundation. ++ * ++ * 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. ++ */ ++#ifndef __QCOM_CLK_HFPLL_H__ ++#define __QCOM_CLK_HFPLL_H__ ++ ++#include ++#include ++#include "clk-regmap.h" ++ ++struct hfpll_data { ++ u32 mode_reg; ++ u32 l_reg; ++ u32 m_reg; ++ u32 n_reg; ++ u32 user_reg; ++ u32 droop_reg; ++ u32 config_reg; ++ u32 status_reg; ++ u8 lock_bit; ++ ++ u32 droop_val; ++ u32 config_val; ++ u32 user_val; ++ u32 user_vco_mask; ++ unsigned long low_vco_max_rate; ++ ++ unsigned long min_rate; ++ unsigned long max_rate; ++}; ++ ++struct clk_hfpll { ++ struct hfpll_data const *d; ++ int init_done; ++ ++ struct clk_regmap clkr; ++ spinlock_t lock; ++}; ++ ++#define to_clk_hfpll(_hw) \ ++ container_of(to_clk_regmap(_hw), struct clk_hfpll, clkr) ++ ++extern const struct clk_ops clk_ops_hfpll; ++ ++#endif diff --git a/target/linux/ipq806x/patches-4.4/138-clk-qcom-Add-HFPLL-driver.patch b/target/linux/ipq806x/patches-4.4/138-clk-qcom-Add-HFPLL-driver.patch new file mode 100644 index 0000000..5a452db --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/138-clk-qcom-Add-HFPLL-driver.patch @@ -0,0 +1,206 @@ +Content-Type: text/plain; charset="utf-8" +MIME-Version: 1.0 +Content-Transfer-Encoding: 7bit +Subject: [v3,06/13] clk: qcom: Add HFPLL driver +From: Stephen Boyd +X-Patchwork-Id: 6063231 +Message-Id: <1426920332-9340-7-git-send-email-sboyd at codeaurora.org> +To: Mike Turquette , Stephen Boyd +Cc: linux-kernel at vger.kernel.org, linux-arm-msm at vger.kernel.org, + linux-pm at vger.kernel.org, linux-arm-kernel at lists.infradead.org, + Viresh Kumar , +Date: Fri, 20 Mar 2015 23:45:25 -0700 + +On some devices (MSM8974 for example), the HFPLLs are +instantiated within the Krait processor subsystem as separate +register regions. Add a driver for these PLLs so that we can +provide HFPLL clocks for use by the system. + +Cc: +Signed-off-by: Stephen Boyd + +--- +.../devicetree/bindings/clock/qcom,hfpll.txt | 40 ++++++++ + drivers/clk/qcom/Kconfig | 8 ++ + drivers/clk/qcom/Makefile | 1 + + drivers/clk/qcom/hfpll.c | 109 +++++++++++++++++++++ + 4 files changed, 158 insertions(+) + create mode 100644 Documentation/devicetree/bindings/clock/qcom,hfpll.txt + create mode 100644 drivers/clk/qcom/hfpll.c + +--- /dev/null ++++ b/Documentation/devicetree/bindings/clock/qcom,hfpll.txt +@@ -0,0 +1,40 @@ ++High-Frequency PLL (HFPLL) ++ ++PROPERTIES ++ ++- compatible: ++ Usage: required ++ Value type: ++ Definition: must be "qcom,hfpll" ++ ++- reg: ++ Usage: required ++ Value type: ++ Definition: address and size of HPLL registers. An optional second ++ element specifies the address and size of the alias ++ register region. ++ ++- clock-output-names: ++ Usage: required ++ Value type: ++ Definition: Name of the PLL. Typically hfpllX where X is a CPU number ++ starting at 0. Otherwise hfpll_Y where Y is more specific ++ such as "l2". ++ ++Example: ++ ++1) An HFPLL for the L2 cache. ++ ++ clock-controller at f9016000 { ++ compatible = "qcom,hfpll"; ++ reg = <0xf9016000 0x30>; ++ clock-output-names = "hfpll_l2"; ++ }; ++ ++2) An HFPLL for CPU0. This HFPLL has the alias register region. ++ ++ clock-controller at f908a000 { ++ compatible = "qcom,hfpll"; ++ reg = <0xf908a000 0x30>, <0xf900a000 0x30>; ++ clock-output-names = "hfpll0"; ++ }; +--- a/drivers/clk/qcom/Kconfig ++++ b/drivers/clk/qcom/Kconfig +@@ -106,3 +106,11 @@ + Support for the multimedia clock controller on msm8974 devices. + Say Y if you want to support multimedia devices such as display, + graphics, video encode/decode, camera, etc. ++ ++config QCOM_HFPLL ++ tristate "High-Frequency PLL (HFPLL) Clock Controller" ++ depends on COMMON_CLK_QCOM ++ help ++ Support for the high-frequency PLLs present on Qualcomm devices. ++ Say Y if you want to support CPU frequency scaling on devices ++ such as MSM8974, APQ8084, etc. +--- a/drivers/clk/qcom/Makefile ++++ b/drivers/clk/qcom/Makefile +@@ -23,3 +23,4 @@ + obj-$(CONFIG_MSM_GCC_8974) += gcc-msm8974.o + obj-$(CONFIG_MSM_MMCC_8960) += mmcc-msm8960.o + obj-$(CONFIG_MSM_MMCC_8974) += mmcc-msm8974.o ++obj-$(CONFIG_QCOM_HFPLL) += hfpll.o +--- /dev/null ++++ b/drivers/clk/qcom/hfpll.c +@@ -0,0 +1,109 @@ ++/* ++ * Copyright (c) 2013-2014, The Linux Foundation. All rights reserved. ++ * ++ * This program is free software; you can redistribute it and/or modify ++ * it under the terms of the GNU General Public License version 2 and ++ * only version 2 as published by the Free Software Foundation. ++ * ++ * 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. ++ */ ++ ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++ ++#include "clk-regmap.h" ++#include "clk-hfpll.h" ++ ++static const struct hfpll_data hdata = { ++ .mode_reg = 0x00, ++ .l_reg = 0x04, ++ .m_reg = 0x08, ++ .n_reg = 0x0c, ++ .user_reg = 0x10, ++ .config_reg = 0x14, ++ .config_val = 0x430405d, ++ .status_reg = 0x1c, ++ .lock_bit = 16, ++ ++ .user_val = 0x8, ++ .user_vco_mask = 0x100000, ++ .low_vco_max_rate = 1248000000, ++ .min_rate = 537600000UL, ++ .max_rate = 2900000000UL, ++}; ++ ++static const struct of_device_id qcom_hfpll_match_table[] = { ++ { .compatible = "qcom,hfpll" }, ++ { } ++}; ++MODULE_DEVICE_TABLE(of, qcom_hfpll_match_table); ++ ++static const struct regmap_config hfpll_regmap_config = { ++ .reg_bits = 32, ++ .reg_stride = 4, ++ .val_bits = 32, ++ .max_register = 0x30, ++ .fast_io = true, ++}; ++ ++static int qcom_hfpll_probe(struct platform_device *pdev) ++{ ++ struct clk *clk; ++ struct resource *res; ++ struct device *dev = &pdev->dev; ++ void __iomem *base; ++ struct regmap *regmap; ++ struct clk_hfpll *h; ++ struct clk_init_data init = { ++ .parent_names = (const char *[]){ "xo" }, ++ .num_parents = 1, ++ .ops = &clk_ops_hfpll, ++ }; ++ ++ h = devm_kzalloc(dev, sizeof(*h), GFP_KERNEL); ++ if (!h) ++ return -ENOMEM; ++ ++ res = platform_get_resource(pdev, IORESOURCE_MEM, 0); ++ base = devm_ioremap_resource(dev, res); ++ if (IS_ERR(base)) ++ return PTR_ERR(base); ++ ++ regmap = devm_regmap_init_mmio(&pdev->dev, base, &hfpll_regmap_config); ++ if (IS_ERR(regmap)) ++ return PTR_ERR(regmap); ++ ++ if (of_property_read_string_index(dev->of_node, "clock-output-names", ++ 0, &init.name)) ++ return -ENODEV; ++ ++ h->d = &hdata; ++ h->clkr.hw.init = &init; ++ spin_lock_init(&h->lock); ++ ++ clk = devm_clk_register_regmap(&pdev->dev, &h->clkr); ++ ++ return PTR_ERR_OR_ZERO(clk); ++} ++ ++static struct platform_driver qcom_hfpll_driver = { ++ .probe = qcom_hfpll_probe, ++ .driver = { ++ .name = "qcom-hfpll", ++ .of_match_table = qcom_hfpll_match_table, ++ }, ++}; ++module_platform_driver(qcom_hfpll_driver); ++ ++MODULE_DESCRIPTION("QCOM HFPLL Clock Driver"); ++MODULE_LICENSE("GPL v2"); ++MODULE_ALIAS("platform:qcom-hfpll"); diff --git a/target/linux/ipq806x/patches-4.4/139-clk-qcom-Add-IPQ806X-s-HFPLLs.patch b/target/linux/ipq806x/patches-4.4/139-clk-qcom-Add-IPQ806X-s-HFPLLs.patch new file mode 100644 index 0000000..5b191b5 --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/139-clk-qcom-Add-IPQ806X-s-HFPLLs.patch @@ -0,0 +1,127 @@ +Content-Type: text/plain; charset="utf-8" +MIME-Version: 1.0 +Content-Transfer-Encoding: 7bit +Subject: [v3,08/13] clk: qcom: Add IPQ806X's HFPLLs +From: Stephen Boyd +X-Patchwork-Id: 6063241 +Message-Id: <1426920332-9340-9-git-send-email-sboyd at codeaurora.org> +To: Mike Turquette , Stephen Boyd +Cc: linux-kernel at vger.kernel.org, linux-arm-msm at vger.kernel.org, + linux-pm at vger.kernel.org, linux-arm-kernel at lists.infradead.org, + Viresh Kumar +Date: Fri, 20 Mar 2015 23:45:27 -0700 + +Describe the HFPLLs present on IPQ806X devices. + +Signed-off-by: Stephen Boyd + +--- +drivers/clk/qcom/gcc-ipq806x.c | 83 ++++++++++++++++++++++++++++++++++++++++++ + 1 file changed, 83 insertions(+) + +--- a/drivers/clk/qcom/gcc-ipq806x.c ++++ b/drivers/clk/qcom/gcc-ipq806x.c +@@ -30,6 +30,7 @@ + #include "clk-pll.h" + #include "clk-rcg.h" + #include "clk-branch.h" ++#include "clk-hfpll.h" + #include "reset.h" + + static struct clk_pll pll0 = { +@@ -113,6 +114,85 @@ + }, + }; + ++static struct hfpll_data hfpll0_data = { ++ .mode_reg = 0x3200, ++ .l_reg = 0x3208, ++ .m_reg = 0x320c, ++ .n_reg = 0x3210, ++ .config_reg = 0x3204, ++ .status_reg = 0x321c, ++ .config_val = 0x7845c665, ++ .droop_reg = 0x3214, ++ .droop_val = 0x0108c000, ++ .min_rate = 600000000UL, ++ .max_rate = 1800000000UL, ++}; ++ ++static struct clk_hfpll hfpll0 = { ++ .d = &hfpll0_data, ++ .clkr.hw.init = &(struct clk_init_data){ ++ .parent_names = (const char *[]){ "pxo" }, ++ .num_parents = 1, ++ .name = "hfpll0", ++ .ops = &clk_ops_hfpll, ++ .flags = CLK_IGNORE_UNUSED, ++ }, ++ .lock = __SPIN_LOCK_UNLOCKED(hfpll0.lock), ++}; ++ ++static struct hfpll_data hfpll1_data = { ++ .mode_reg = 0x3240, ++ .l_reg = 0x3248, ++ .m_reg = 0x324c, ++ .n_reg = 0x3250, ++ .config_reg = 0x3244, ++ .status_reg = 0x325c, ++ .config_val = 0x7845c665, ++ .droop_reg = 0x3314, ++ .droop_val = 0x0108c000, ++ .min_rate = 600000000UL, ++ .max_rate = 1800000000UL, ++}; ++ ++static struct clk_hfpll hfpll1 = { ++ .d = &hfpll1_data, ++ .clkr.hw.init = &(struct clk_init_data){ ++ .parent_names = (const char *[]){ "pxo" }, ++ .num_parents = 1, ++ .name = "hfpll1", ++ .ops = &clk_ops_hfpll, ++ .flags = CLK_IGNORE_UNUSED, ++ }, ++ .lock = __SPIN_LOCK_UNLOCKED(hfpll1.lock), ++}; ++ ++static struct hfpll_data hfpll_l2_data = { ++ .mode_reg = 0x3300, ++ .l_reg = 0x3308, ++ .m_reg = 0x330c, ++ .n_reg = 0x3310, ++ .config_reg = 0x3304, ++ .status_reg = 0x331c, ++ .config_val = 0x7845c665, ++ .droop_reg = 0x3314, ++ .droop_val = 0x0108c000, ++ .min_rate = 600000000UL, ++ .max_rate = 1800000000UL, ++}; ++ ++static struct clk_hfpll hfpll_l2 = { ++ .d = &hfpll_l2_data, ++ .clkr.hw.init = &(struct clk_init_data){ ++ .parent_names = (const char *[]){ "pxo" }, ++ .num_parents = 1, ++ .name = "hfpll_l2", ++ .ops = &clk_ops_hfpll, ++ .flags = CLK_IGNORE_UNUSED, ++ }, ++ .lock = __SPIN_LOCK_UNLOCKED(hfpll_l2.lock), ++}; ++ ++ + static struct clk_pll pll14 = { + .l_reg = 0x31c4, + .m_reg = 0x31c8, +@@ -2837,6 +2917,9 @@ + [UBI32_CORE2_CLK_SRC] = &ubi32_core2_src_clk.clkr, + [NSSTCM_CLK_SRC] = &nss_tcm_src.clkr, + [NSSTCM_CLK] = &nss_tcm_clk.clkr, ++ [PLL9] = &hfpll0.clkr, ++ [PLL10] = &hfpll1.clkr, ++ [PLL12] = &hfpll_l2.clkr, + }; + + static const struct qcom_reset_map gcc_ipq806x_resets[] = { diff --git a/target/linux/ipq806x/patches-4.4/140-clk-qcom-Add-support-for-Krait-clocks.patch b/target/linux/ipq806x/patches-4.4/140-clk-qcom-Add-support-for-Krait-clocks.patch new file mode 100644 index 0000000..522482d --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/140-clk-qcom-Add-support-for-Krait-clocks.patch @@ -0,0 +1,272 @@ +Content-Type: text/plain; charset="utf-8" +MIME-Version: 1.0 +Content-Transfer-Encoding: 7bit +Subject: [v3,09/13] clk: qcom: Add support for Krait clocks +From: Stephen Boyd +X-Patchwork-Id: 6063251 +Message-Id: <1426920332-9340-10-git-send-email-sboyd at codeaurora.org> +To: Mike Turquette , Stephen Boyd +Cc: linux-kernel at vger.kernel.org, linux-arm-msm at vger.kernel.org, + linux-pm at vger.kernel.org, linux-arm-kernel at lists.infradead.org, + Viresh Kumar +Date: Fri, 20 Mar 2015 23:45:28 -0700 + +The Krait clocks are made up of a series of muxes and a divider +that choose between a fixed rate clock and dedicated HFPLLs for +each CPU. Instead of using mmio accesses to remux parents, the +Krait implementation exposes the remux control via cp15 +registers. Support these clocks. + +Signed-off-by: Stephen Boyd + +--- +drivers/clk/qcom/Kconfig | 4 ++ + drivers/clk/qcom/Makefile | 1 + + drivers/clk/qcom/clk-krait.c | 166 +++++++++++++++++++++++++++++++++++++++++++ + drivers/clk/qcom/clk-krait.h | 49 +++++++++++++ + 4 files changed, 220 insertions(+) + create mode 100644 drivers/clk/qcom/clk-krait.c + create mode 100644 drivers/clk/qcom/clk-krait.h + +--- a/drivers/clk/qcom/Kconfig ++++ b/drivers/clk/qcom/Kconfig +@@ -114,3 +114,7 @@ + Support for the high-frequency PLLs present on Qualcomm devices. + Say Y if you want to support CPU frequency scaling on devices + such as MSM8974, APQ8084, etc. ++ ++config KRAIT_CLOCKS ++ bool ++ select KRAIT_L2_ACCESSORS +--- a/drivers/clk/qcom/Makefile ++++ b/drivers/clk/qcom/Makefile +@@ -8,6 +8,7 @@ + clk-qcom-y += clk-branch.o + clk-qcom-y += clk-regmap-divider.o + clk-qcom-y += clk-regmap-mux.o ++clk-qcom-$(CONFIG_KRAIT_CLOCKS) += clk-krait.o + clk-qcom-y += clk-hfpll.o + clk-qcom-y += reset.o + clk-qcom-$(CONFIG_QCOM_GDSC) += gdsc.o + +--- /dev/null ++++ b/drivers/clk/qcom/clk-krait.c +@@ -0,0 +1,166 @@ ++/* ++ * Copyright (c) 2013-2014, The Linux Foundation. All rights reserved. ++ * ++ * This program is free software; you can redistribute it and/or modify ++ * it under the terms of the GNU General Public License version 2 and ++ * only version 2 as published by the Free Software Foundation. ++ * ++ * 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. ++ */ ++ ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++ ++#include ++ ++#include "clk-krait.h" ++ ++/* Secondary and primary muxes share the same cp15 register */ ++static DEFINE_SPINLOCK(krait_clock_reg_lock); ++ ++#define LPL_SHIFT 8 ++static void __krait_mux_set_sel(struct krait_mux_clk *mux, int sel) ++{ ++ unsigned long flags; ++ u32 regval; ++ ++ spin_lock_irqsave(&krait_clock_reg_lock, flags); ++ regval = krait_get_l2_indirect_reg(mux->offset); ++ regval &= ~(mux->mask << mux->shift); ++ regval |= (sel & mux->mask) << mux->shift; ++ if (mux->lpl) { ++ regval &= ~(mux->mask << (mux->shift + LPL_SHIFT)); ++ regval |= (sel & mux->mask) << (mux->shift + LPL_SHIFT); ++ } ++ krait_set_l2_indirect_reg(mux->offset, regval); ++ spin_unlock_irqrestore(&krait_clock_reg_lock, flags); ++ ++ /* Wait for switch to complete. */ ++ mb(); ++ udelay(1); ++} ++ ++static int krait_mux_set_parent(struct clk_hw *hw, u8 index) ++{ ++ struct krait_mux_clk *mux = to_krait_mux_clk(hw); ++ u32 sel; ++ ++ sel = clk_mux_reindex(index, mux->parent_map, 0); ++ mux->en_mask = sel; ++ /* Don't touch mux if CPU is off as it won't work */ ++ if (__clk_is_enabled(hw->clk)) ++ __krait_mux_set_sel(mux, sel); ++ return 0; ++} ++ ++static u8 krait_mux_get_parent(struct clk_hw *hw) ++{ ++ struct krait_mux_clk *mux = to_krait_mux_clk(hw); ++ u32 sel; ++ ++ sel = krait_get_l2_indirect_reg(mux->offset); ++ sel >>= mux->shift; ++ sel &= mux->mask; ++ mux->en_mask = sel; ++ ++ return clk_mux_get_parent(hw, sel, mux->parent_map, 0); ++} ++ ++static struct clk_hw *krait_mux_get_safe_parent(struct clk_hw *hw) ++{ ++ int i; ++ struct krait_mux_clk *mux = to_krait_mux_clk(hw); ++ int num_parents = clk_hw_get_num_parents(hw->clk); ++ ++ i = mux->safe_sel; ++ for (i = 0; i < num_parents; i++) ++ if (mux->safe_sel == mux->parent_map[i]) ++ break; ++ ++ return __clk_get_hw(clk_hw_get_parent_by_index(hw->clk, i)); ++} ++ ++static int krait_mux_enable(struct clk_hw *hw) ++{ ++ struct krait_mux_clk *mux = to_krait_mux_clk(hw); ++ ++ __krait_mux_set_sel(mux, mux->en_mask); ++ ++ return 0; ++} ++ ++static void krait_mux_disable(struct clk_hw *hw) ++{ ++ struct krait_mux_clk *mux = to_krait_mux_clk(hw); ++ ++ __krait_mux_set_sel(mux, mux->safe_sel); ++} ++ ++const struct clk_ops krait_mux_clk_ops = { ++ .enable = krait_mux_enable, ++ .disable = krait_mux_disable, ++ .set_parent = krait_mux_set_parent, ++ .get_parent = krait_mux_get_parent, ++ .determine_rate = __clk_mux_determine_rate_closest, ++ .get_safe_parent = krait_mux_get_safe_parent, ++}; ++EXPORT_SYMBOL_GPL(krait_mux_clk_ops); ++ ++/* The divider can divide by 2, 4, 6 and 8. But we only really need div-2. */ ++static long krait_div2_round_rate(struct clk_hw *hw, unsigned long rate, ++ unsigned long *parent_rate) ++{ ++ *parent_rate = clk_hw_round_rate(clk_hw_get_parent(hw->clk), rate * 2); ++ return DIV_ROUND_UP(*parent_rate, 2); ++} ++ ++static int krait_div2_set_rate(struct clk_hw *hw, unsigned long rate, ++ unsigned long parent_rate) ++{ ++ struct krait_div2_clk *d = to_krait_div2_clk(hw); ++ unsigned long flags; ++ u32 val; ++ u32 mask = BIT(d->width) - 1; ++ ++ if (d->lpl) ++ mask = mask << (d->shift + LPL_SHIFT) | mask << d->shift; ++ ++ spin_lock_irqsave(&krait_clock_reg_lock, flags); ++ val = krait_get_l2_indirect_reg(d->offset); ++ val &= ~mask; ++ krait_set_l2_indirect_reg(d->offset, val); ++ spin_unlock_irqrestore(&krait_clock_reg_lock, flags); ++ ++ return 0; ++} ++ ++static unsigned long ++krait_div2_recalc_rate(struct clk_hw *hw, unsigned long parent_rate) ++{ ++ struct krait_div2_clk *d = to_krait_div2_clk(hw); ++ u32 mask = BIT(d->width) - 1; ++ u32 div; ++ ++ div = krait_get_l2_indirect_reg(d->offset); ++ div >>= d->shift; ++ div &= mask; ++ div = (div + 1) * 2; ++ ++ return DIV_ROUND_UP(parent_rate, div); ++} ++ ++const struct clk_ops krait_div2_clk_ops = { ++ .round_rate = krait_div2_round_rate, ++ .set_rate = krait_div2_set_rate, ++ .recalc_rate = krait_div2_recalc_rate, ++}; ++EXPORT_SYMBOL_GPL(krait_div2_clk_ops); +--- /dev/null ++++ b/drivers/clk/qcom/clk-krait.h +@@ -0,0 +1,49 @@ ++/* ++ * Copyright (c) 2013, The Linux Foundation. All rights reserved. ++ * ++ * This program is free software; you can redistribute it and/or modify ++ * it under the terms of the GNU General Public License version 2 and ++ * only version 2 as published by the Free Software Foundation. ++ * ++ * 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. ++ */ ++ ++#ifndef __QCOM_CLK_KRAIT_H ++#define __QCOM_CLK_KRAIT_H ++ ++#include ++ ++struct krait_mux_clk { ++ unsigned int *parent_map; ++ bool has_safe_parent; ++ u8 safe_sel; ++ u32 offset; ++ u32 mask; ++ u32 shift; ++ u32 en_mask; ++ bool lpl; ++ ++ struct clk_hw hw; ++}; ++ ++#define to_krait_mux_clk(_hw) container_of(_hw, struct krait_mux_clk, hw) ++ ++extern const struct clk_ops krait_mux_clk_ops; ++ ++struct krait_div2_clk { ++ u32 offset; ++ u8 width; ++ u32 shift; ++ bool lpl; ++ ++ struct clk_hw hw; ++}; ++ ++#define to_krait_div2_clk(_hw) container_of(_hw, struct krait_div2_clk, hw) ++ ++extern const struct clk_ops krait_div2_clk_ops; ++ ++#endif diff --git a/target/linux/ipq806x/patches-4.4/141-clk-qcom-Add-KPSS-ACC-GCC-driver.patch b/target/linux/ipq806x/patches-4.4/141-clk-qcom-Add-KPSS-ACC-GCC-driver.patch new file mode 100644 index 0000000..b2ddbc8 --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/141-clk-qcom-Add-KPSS-ACC-GCC-driver.patch @@ -0,0 +1,207 @@ +Content-Type: text/plain; charset="utf-8" +MIME-Version: 1.0 +Content-Transfer-Encoding: 7bit +Subject: [v3,10/13] clk: qcom: Add KPSS ACC/GCC driver +From: Stephen Boyd +X-Patchwork-Id: 6063201 +Message-Id: <1426920332-9340-11-git-send-email-sboyd at codeaurora.org> +To: Mike Turquette , Stephen Boyd +Cc: linux-kernel at vger.kernel.org, linux-arm-msm at vger.kernel.org, + linux-pm at vger.kernel.org, linux-arm-kernel at lists.infradead.org, + Viresh Kumar , +Date: Fri, 20 Mar 2015 23:45:29 -0700 + +The ACC and GCC regions present in KPSSv1 contain registers to +control clocks and power to each Krait CPU and L2. For CPUfreq +purposes probe these devices and expose a mux clock that chooses +between PXO and PLL8. + +Cc: +Signed-off-by: Stephen Boyd + +--- +.../devicetree/bindings/arm/msm/qcom,kpss-acc.txt | 7 ++ + .../devicetree/bindings/arm/msm/qcom,kpss-gcc.txt | 28 +++++++ + drivers/clk/qcom/Kconfig | 8 ++ + drivers/clk/qcom/Makefile | 1 + + drivers/clk/qcom/kpss-xcc.c | 95 ++++++++++++++++++++++ + 5 files changed, 139 insertions(+) + create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt + create mode 100644 drivers/clk/qcom/kpss-xcc.c + +--- a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt ++++ b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt +@@ -21,10 +21,17 @@ + the register region. An optional second element specifies + the base address and size of the alias register region. + ++- clock-output-names: ++ Usage: optional ++ Value type: ++ Definition: Name of the output clock. Typically acpuX_aux where X is a ++ CPU number starting at 0. ++ + Example: + + clock-controller at 2088000 { + compatible = "qcom,kpss-acc-v2"; + reg = <0x02088000 0x1000>, + <0x02008000 0x1000>; ++ clock-output-names = "acpu0_aux"; + }; +--- /dev/null ++++ b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt +@@ -0,0 +1,28 @@ ++Krait Processor Sub-system (KPSS) Global Clock Controller (GCC) ++ ++PROPERTIES ++ ++- compatible: ++ Usage: required ++ Value type: ++ Definition: should be one of: ++ "qcom,kpss-gcc" ++ ++- reg: ++ Usage: required ++ Value type: ++ Definition: base address and size of the register region ++ ++- clock-output-names: ++ Usage: required ++ Value type: ++ Definition: Name of the output clock. Typically acpu_l2_aux indicating ++ an L2 cache auxiliary clock. ++ ++Example: ++ ++ l2cc: clock-controller at 2011000 { ++ compatible = "qcom,kpss-gcc"; ++ reg = <0x2011000 0x1000>; ++ clock-output-names = "acpu_l2_aux"; ++ }; +--- a/drivers/clk/qcom/Kconfig ++++ b/drivers/clk/qcom/Kconfig +@@ -115,6 +115,14 @@ + Say Y if you want to support CPU frequency scaling on devices + such as MSM8974, APQ8084, etc. + ++config KPSS_XCC ++ tristate "KPSS Clock Controller" ++ depends on COMMON_CLK_QCOM ++ help ++ Support for the Krait ACC and GCC clock controllers. Say Y ++ if you want to support CPU frequency scaling on devices such ++ as MSM8960, APQ8064, etc. ++ + config KRAIT_CLOCKS + bool + select KRAIT_L2_ACCESSORS +--- a/drivers/clk/qcom/Makefile ++++ b/drivers/clk/qcom/Makefile +@@ -9,6 +9,7 @@ + clk-qcom-y += clk-regmap-divider.o + clk-qcom-y += clk-regmap-mux.o + clk-qcom-$(CONFIG_KRAIT_CLOCKS) += clk-krait.o ++obj-$(CONFIG_KPSS_XCC) += kpss-xcc.o + clk-qcom-y += clk-hfpll.o + clk-qcom-y += reset.o + clk-qcom-$(CONFIG_QCOM_GDSC) += gdsc.o +--- /dev/null ++++ b/drivers/clk/qcom/kpss-xcc.c +@@ -0,0 +1,95 @@ ++/* Copyright (c) 2014-2015, The Linux Foundation. All rights reserved. ++ * ++ * This program is free software; you can redistribute it and/or modify ++ * it under the terms of the GNU General Public License version 2 and ++ * only version 2 as published by the Free Software Foundation. ++ * ++ * 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. ++ */ ++ ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++ ++static const char *aux_parents[] = { ++ "pll8_vote", ++ "pxo", ++}; ++ ++static unsigned int aux_parent_map[] = { ++ 3, ++ 0, ++}; ++ ++static const struct of_device_id kpss_xcc_match_table[] = { ++ { .compatible = "qcom,kpss-acc-v1", .data = (void *)1UL }, ++ { .compatible = "qcom,kpss-gcc" }, ++ {} ++}; ++MODULE_DEVICE_TABLE(of, kpss_xcc_match_table); ++ ++static int kpss_xcc_driver_probe(struct platform_device *pdev) ++{ ++ const struct of_device_id *id; ++ struct clk *clk; ++ struct resource *res; ++ void __iomem *base; ++ const char *name; ++ ++ id = of_match_device(kpss_xcc_match_table, &pdev->dev); ++ if (!id) ++ return -ENODEV; ++ ++ res = platform_get_resource(pdev, IORESOURCE_MEM, 0); ++ base = devm_ioremap_resource(&pdev->dev, res); ++ if (IS_ERR(base)) ++ return PTR_ERR(base); ++ ++ if (id->data) { ++ if (of_property_read_string_index(pdev->dev.of_node, ++ "clock-output-names", 0, &name)) ++ return -ENODEV; ++ base += 0x14; ++ } else { ++ name = "acpu_l2_aux"; ++ base += 0x28; ++ } ++ ++ clk = clk_register_mux_table(&pdev->dev, name, aux_parents, ++ ARRAY_SIZE(aux_parents), 0, base, 0, 0x3, ++ 0, aux_parent_map, NULL); ++ ++ platform_set_drvdata(pdev, clk); ++ ++ return PTR_ERR_OR_ZERO(clk); ++} ++ ++static int kpss_xcc_driver_remove(struct platform_device *pdev) ++{ ++ clk_unregister_mux(platform_get_drvdata(pdev)); ++ return 0; ++} ++ ++static struct platform_driver kpss_xcc_driver = { ++ .probe = kpss_xcc_driver_probe, ++ .remove = kpss_xcc_driver_remove, ++ .driver = { ++ .name = "kpss-xcc", ++ .of_match_table = kpss_xcc_match_table, ++ }, ++}; ++module_platform_driver(kpss_xcc_driver); ++ ++MODULE_DESCRIPTION("Krait Processor Sub System (KPSS) Clock Driver"); ++MODULE_LICENSE("GPL v2"); ++MODULE_ALIAS("platform:kpss-xcc"); diff --git a/target/linux/ipq806x/patches-4.4/142-clk-qcom-Add-Krait-clock-controller-driver.patch b/target/linux/ipq806x/patches-4.4/142-clk-qcom-Add-Krait-clock-controller-driver.patch new file mode 100644 index 0000000..f0e9467 --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/142-clk-qcom-Add-Krait-clock-controller-driver.patch @@ -0,0 +1,435 @@ +Content-Type: text/plain; charset="utf-8" +MIME-Version: 1.0 +Content-Transfer-Encoding: 7bit +Subject: [v3,11/13] clk: qcom: Add Krait clock controller driver +From: Stephen Boyd +X-Patchwork-Id: 6063121 +Message-Id: <1426920332-9340-12-git-send-email-sboyd at codeaurora.org> +To: Mike Turquette , Stephen Boyd +Cc: linux-kernel at vger.kernel.org, linux-arm-msm at vger.kernel.org, + linux-pm at vger.kernel.org, linux-arm-kernel at lists.infradead.org, + Viresh Kumar , +Date: Fri, 20 Mar 2015 23:45:30 -0700 + +The Krait CPU clocks are made up of a primary mux and secondary +mux for each CPU and the L2, controlled via cp15 accessors. For +Kraits within KPSSv1 each secondary mux accepts a different aux +source, but on KPSSv2 each secondary mux accepts the same aux +source. + +Cc: +Signed-off-by: Stephen Boyd + +--- +.../devicetree/bindings/clock/qcom,krait-cc.txt | 22 ++ + drivers/clk/qcom/Kconfig | 8 + + drivers/clk/qcom/Makefile | 1 + + drivers/clk/qcom/krait-cc.c | 352 +++++++++++++++++++++ + 4 files changed, 383 insertions(+) + create mode 100644 Documentation/devicetree/bindings/clock/qcom,krait-cc.txt + create mode 100644 drivers/clk/qcom/krait-cc.c + +--- /dev/null ++++ b/Documentation/devicetree/bindings/clock/qcom,krait-cc.txt +@@ -0,0 +1,22 @@ ++Krait Clock Controller ++ ++PROPERTIES ++ ++- compatible: ++ Usage: required ++ Value type: ++ Definition: must be one of: ++ "qcom,krait-cc-v1" ++ "qcom,krait-cc-v2" ++ ++- #clock-cells: ++ Usage: required ++ Value type: ++ Definition: must be 1 ++ ++Example: ++ ++ kraitcc: clock-controller { ++ compatible = "qcom,krait-cc-v1"; ++ #clock-cells = <1>; ++ }; +--- a/drivers/clk/qcom/Kconfig ++++ b/drivers/clk/qcom/Kconfig +@@ -123,6 +123,14 @@ + if you want to support CPU frequency scaling on devices such + as MSM8960, APQ8064, etc. + ++config KRAITCC ++ tristate "Krait Clock Controller" ++ depends on COMMON_CLK_QCOM && ARM ++ select KRAIT_CLOCKS ++ help ++ Support for the Krait CPU clocks on Qualcomm devices. ++ Say Y if you want to support CPU frequency scaling. ++ + config KRAIT_CLOCKS + bool + select KRAIT_L2_ACCESSORS +--- a/drivers/clk/qcom/Makefile ++++ b/drivers/clk/qcom/Makefile +@@ -26,3 +26,4 @@ + obj-$(CONFIG_MSM_MMCC_8960) += mmcc-msm8960.o + obj-$(CONFIG_MSM_MMCC_8974) += mmcc-msm8974.o + obj-$(CONFIG_QCOM_HFPLL) += hfpll.o ++obj-$(CONFIG_KRAITCC) += krait-cc.o +--- /dev/null ++++ b/drivers/clk/qcom/krait-cc.c +@@ -0,0 +1,352 @@ ++/* Copyright (c) 2013-2015, The Linux Foundation. All rights reserved. ++ * ++ * This program is free software; you can redistribute it and/or modify ++ * it under the terms of the GNU General Public License version 2 and ++ * only version 2 as published by the Free Software Foundation. ++ * ++ * 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. ++ */ ++ ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++ ++#include "clk-krait.h" ++ ++static unsigned int sec_mux_map[] = { ++ 2, ++ 0, ++}; ++ ++static unsigned int pri_mux_map[] = { ++ 1, ++ 2, ++ 0, ++}; ++ ++static int ++krait_add_div(struct device *dev, int id, const char *s, unsigned offset) ++{ ++ struct krait_div2_clk *div; ++ struct clk_init_data init = { ++ .num_parents = 1, ++ .ops = &krait_div2_clk_ops, ++ .flags = CLK_SET_RATE_PARENT, ++ }; ++ const char *p_names[1]; ++ struct clk *clk; ++ ++ div = devm_kzalloc(dev, sizeof(*div), GFP_KERNEL); ++ if (!div) ++ return -ENOMEM; ++ ++ div->width = 2; ++ div->shift = 6; ++ div->lpl = id >= 0; ++ div->offset = offset; ++ div->hw.init = &init; ++ ++ init.name = kasprintf(GFP_KERNEL, "hfpll%s_div", s); ++ if (!init.name) ++ return -ENOMEM; ++ ++ init.parent_names = p_names; ++ p_names[0] = kasprintf(GFP_KERNEL, "hfpll%s", s); ++ if (!p_names[0]) { ++ kfree(init.name); ++ return -ENOMEM; ++ } ++ ++ clk = devm_clk_register(dev, &div->hw); ++ kfree(p_names[0]); ++ kfree(init.name); ++ ++ return PTR_ERR_OR_ZERO(clk); ++} ++ ++static int ++krait_add_sec_mux(struct device *dev, int id, const char *s, unsigned offset, ++ bool unique_aux) ++{ ++ struct krait_mux_clk *mux; ++ static const char *sec_mux_list[] = { ++ "acpu_aux", ++ "qsb", ++ }; ++ struct clk_init_data init = { ++ .parent_names = sec_mux_list, ++ .num_parents = ARRAY_SIZE(sec_mux_list), ++ .ops = &krait_mux_clk_ops, ++ .flags = CLK_SET_RATE_PARENT, ++ }; ++ struct clk *clk; ++ ++ mux = devm_kzalloc(dev, sizeof(*mux), GFP_KERNEL); ++ if (!mux) ++ return -ENOMEM; ++ ++ mux->offset = offset; ++ mux->lpl = id >= 0; ++ mux->has_safe_parent = true; ++ mux->safe_sel = 2; ++ mux->mask = 0x3; ++ mux->shift = 2; ++ mux->parent_map = sec_mux_map; ++ mux->hw.init = &init; ++ ++ init.name = kasprintf(GFP_KERNEL, "krait%s_sec_mux", s); ++ if (!init.name) ++ return -ENOMEM; ++ ++ if (unique_aux) { ++ sec_mux_list[0] = kasprintf(GFP_KERNEL, "acpu%s_aux", s); ++ if (!sec_mux_list[0]) { ++ clk = ERR_PTR(-ENOMEM); ++ goto err_aux; ++ } ++ } ++ ++ clk = devm_clk_register(dev, &mux->hw); ++ ++ if (unique_aux) ++ kfree(sec_mux_list[0]); ++err_aux: ++ kfree(init.name); ++ return PTR_ERR_OR_ZERO(clk); ++} ++ ++static struct clk * ++krait_add_pri_mux(struct device *dev, int id, const char *s, unsigned offset) ++{ ++ struct krait_mux_clk *mux; ++ const char *p_names[3]; ++ struct clk_init_data init = { ++ .parent_names = p_names, ++ .num_parents = ARRAY_SIZE(p_names), ++ .ops = &krait_mux_clk_ops, ++ .flags = CLK_SET_RATE_PARENT, ++ }; ++ struct clk *clk; ++ ++ mux = devm_kzalloc(dev, sizeof(*mux), GFP_KERNEL); ++ if (!mux) ++ return ERR_PTR(-ENOMEM); ++ ++ mux->has_safe_parent = true; ++ mux->safe_sel = 0; ++ mux->mask = 0x3; ++ mux->shift = 0; ++ mux->offset = offset; ++ mux->lpl = id >= 0; ++ mux->parent_map = pri_mux_map; ++ mux->hw.init = &init; ++ ++ init.name = kasprintf(GFP_KERNEL, "krait%s_pri_mux", s); ++ if (!init.name) ++ return ERR_PTR(-ENOMEM); ++ ++ p_names[0] = kasprintf(GFP_KERNEL, "hfpll%s", s); ++ if (!p_names[0]) { ++ clk = ERR_PTR(-ENOMEM); ++ goto err_p0; ++ } ++ ++ p_names[1] = kasprintf(GFP_KERNEL, "hfpll%s_div", s); ++ if (!p_names[1]) { ++ clk = ERR_PTR(-ENOMEM); ++ goto err_p1; ++ } ++ ++ p_names[2] = kasprintf(GFP_KERNEL, "krait%s_sec_mux", s); ++ if (!p_names[2]) { ++ clk = ERR_PTR(-ENOMEM); ++ goto err_p2; ++ } ++ ++ clk = devm_clk_register(dev, &mux->hw); ++ ++ kfree(p_names[2]); ++err_p2: ++ kfree(p_names[1]); ++err_p1: ++ kfree(p_names[0]); ++err_p0: ++ kfree(init.name); ++ return clk; ++} ++ ++/* id < 0 for L2, otherwise id == physical CPU number */ ++static struct clk *krait_add_clks(struct device *dev, int id, bool unique_aux) ++{ ++ int ret; ++ unsigned offset; ++ void *p = NULL; ++ const char *s; ++ struct clk *clk; ++ ++ if (id >= 0) { ++ offset = 0x4501 + (0x1000 * id); ++ s = p = kasprintf(GFP_KERNEL, "%d", id); ++ if (!s) ++ return ERR_PTR(-ENOMEM); ++ } else { ++ offset = 0x500; ++ s = "_l2"; ++ } ++ ++ ret = krait_add_div(dev, id, s, offset); ++ if (ret) { ++ clk = ERR_PTR(ret); ++ goto err; ++ } ++ ++ ret = krait_add_sec_mux(dev, id, s, offset, unique_aux); ++ if (ret) { ++ clk = ERR_PTR(ret); ++ goto err; ++ } ++ ++ clk = krait_add_pri_mux(dev, id, s, offset); ++err: ++ kfree(p); ++ return clk; ++} ++ ++static struct clk *krait_of_get(struct of_phandle_args *clkspec, void *data) ++{ ++ unsigned int idx = clkspec->args[0]; ++ struct clk **clks = data; ++ ++ if (idx >= 5) { ++ pr_err("%s: invalid clock index %d\n", __func__, idx); ++ return ERR_PTR(-EINVAL); ++ } ++ ++ return clks[idx] ? : ERR_PTR(-ENODEV); ++} ++ ++static const struct of_device_id krait_cc_match_table[] = { ++ { .compatible = "qcom,krait-cc-v1", (void *)1UL }, ++ { .compatible = "qcom,krait-cc-v2" }, ++ {} ++}; ++MODULE_DEVICE_TABLE(of, krait_cc_match_table); ++ ++static int krait_cc_probe(struct platform_device *pdev) ++{ ++ struct device *dev = &pdev->dev; ++ const struct of_device_id *id; ++ unsigned long cur_rate, aux_rate; ++ int cpu; ++ struct clk *clk; ++ struct clk **clks; ++ struct clk *l2_pri_mux_clk; ++ ++ id = of_match_device(krait_cc_match_table, dev); ++ if (!id) ++ return -ENODEV; ++ ++ /* Rate is 1 because 0 causes problems for __clk_mux_determine_rate */ ++ clk = clk_register_fixed_rate(dev, "qsb", NULL, CLK_IS_ROOT, 1); ++ if (IS_ERR(clk)) ++ return PTR_ERR(clk); ++ ++ if (!id->data) { ++ clk = clk_register_fixed_factor(dev, "acpu_aux", ++ "gpll0_vote", 0, 1, 2); ++ if (IS_ERR(clk)) ++ return PTR_ERR(clk); ++ } ++ ++ /* Krait configurations have at most 4 CPUs and one L2 */ ++ clks = devm_kcalloc(dev, 5, sizeof(*clks), GFP_KERNEL); ++ if (!clks) ++ return -ENOMEM; ++ ++ for_each_possible_cpu(cpu) { ++ clk = krait_add_clks(dev, cpu, id->data); ++ if (IS_ERR(clk)) ++ return PTR_ERR(clk); ++ clks[cpu] = clk; ++ } ++ ++ l2_pri_mux_clk = krait_add_clks(dev, -1, id->data); ++ if (IS_ERR(l2_pri_mux_clk)) ++ return PTR_ERR(l2_pri_mux_clk); ++ clks[4] = l2_pri_mux_clk; ++ ++ /* ++ * We don't want the CPU or L2 clocks to be turned off at late init ++ * if CPUFREQ or HOTPLUG configs are disabled. So, bump up the ++ * refcount of these clocks. Any cpufreq/hotplug manager can assume ++ * that the clocks have already been prepared and enabled by the time ++ * they take over. ++ */ ++ for_each_online_cpu(cpu) { ++ clk_prepare_enable(l2_pri_mux_clk); ++ WARN(clk_prepare_enable(clks[cpu]), ++ "Unable to turn on CPU%d clock", cpu); ++ } ++ ++ /* ++ * Force reinit of HFPLLs and muxes to overwrite any potential ++ * incorrect configuration of HFPLLs and muxes by the bootloader. ++ * While at it, also make sure the cores are running at known rates ++ * and print the current rate. ++ * ++ * The clocks are set to aux clock rate first to make sure the ++ * secondary mux is not sourcing off of QSB. The rate is then set to ++ * two different rates to force a HFPLL reinit under all ++ * circumstances. ++ */ ++ cur_rate = clk_get_rate(l2_pri_mux_clk); ++ aux_rate = 384000000; ++ if (cur_rate == 1) { ++ pr_info("L2 @ QSB rate. Forcing new rate.\n"); ++ cur_rate = aux_rate; ++ } ++ clk_set_rate(l2_pri_mux_clk, aux_rate); ++ clk_set_rate(l2_pri_mux_clk, 2); ++ clk_set_rate(l2_pri_mux_clk, cur_rate); ++ pr_info("L2 @ %lu KHz\n", clk_get_rate(l2_pri_mux_clk) / 1000); ++ for_each_possible_cpu(cpu) { ++ clk = clks[cpu]; ++ cur_rate = clk_get_rate(clk); ++ if (cur_rate == 1) { ++ pr_info("CPU%d @ QSB rate. Forcing new rate.\n", cpu); ++ cur_rate = aux_rate; ++ } ++ clk_set_rate(clk, aux_rate); ++ clk_set_rate(clk, 2); ++ clk_set_rate(clk, cur_rate); ++ pr_info("CPU%d @ %lu KHz\n", cpu, clk_get_rate(clk) / 1000); ++ } ++ ++ of_clk_add_provider(dev->of_node, krait_of_get, clks); ++ ++ return 0; ++} ++ ++static struct platform_driver krait_cc_driver = { ++ .probe = krait_cc_probe, ++ .driver = { ++ .name = "krait-cc", ++ .of_match_table = krait_cc_match_table, ++ }, ++}; ++module_platform_driver(krait_cc_driver); ++ ++MODULE_DESCRIPTION("Krait CPU Clock Driver"); ++MODULE_LICENSE("GPL v2"); ++MODULE_ALIAS("platform:krait-cc"); diff --git a/target/linux/ipq806x/patches-4.4/143-cpufreq-Add-module-to-register-cpufreq-on-Krait-CPUs.patch b/target/linux/ipq806x/patches-4.4/143-cpufreq-Add-module-to-register-cpufreq-on-Krait-CPUs.patch new file mode 100644 index 0000000..d4c43f4 --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/143-cpufreq-Add-module-to-register-cpufreq-on-Krait-CPUs.patch @@ -0,0 +1,304 @@ +Content-Type: text/plain; charset="utf-8" +MIME-Version: 1.0 +Content-Transfer-Encoding: 7bit +Subject: [v3,12/13] cpufreq: Add module to register cpufreq on Krait CPUs +From: Stephen Boyd +X-Patchwork-Id: 6063191 +Message-Id: <1426920332-9340-13-git-send-email-sboyd at codeaurora.org> +To: Mike Turquette , Stephen Boyd +Cc: linux-kernel at vger.kernel.org, linux-arm-msm at vger.kernel.org, + linux-pm at vger.kernel.org, linux-arm-kernel at lists.infradead.org, + Viresh Kumar , +Date: Fri, 20 Mar 2015 23:45:31 -0700 + +Register a cpufreq-generic device whenever we detect that a +"qcom,krait" compatible CPU is present in DT. + +Cc: +Signed-off-by: Stephen Boyd + +--- +.../devicetree/bindings/arm/msm/qcom,pvs.txt | 38 ++++ + drivers/cpufreq/Kconfig.arm | 9 + + drivers/cpufreq/Makefile | 1 + + drivers/cpufreq/qcom-cpufreq.c | 204 +++++++++++++++++++++ + 4 files changed, 252 insertions(+) + create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,pvs.txt + create mode 100644 drivers/cpufreq/qcom-cpufreq.c + +--- /dev/null ++++ b/Documentation/devicetree/bindings/arm/msm/qcom,pvs.txt +@@ -0,0 +1,38 @@ ++Qualcomm Process Voltage Scaling Tables ++ ++The node name is required to be "qcom,pvs". There shall only be one ++such node present in the root of the tree. ++ ++PROPERTIES ++ ++- qcom,pvs-format-a or qcom,pvs-format-b: ++ Usage: required ++ Value type: ++ Definition: Indicates the format of qcom,speedX-pvsY-bin-vZ properties. ++ If qcom,pvs-format-a is used the table is two columns ++ (frequency and voltage in that order). If qcom,pvs-format-b is used the table is three columns (frequency, voltage, ++ and current in that order). ++ ++- qcom,speedX-pvsY-bin-vZ: ++ Usage: required ++ Value type: ++ Definition: The PVS table corresponding to the speed bin X, pvs bin Y, ++ and version Z. ++Example: ++ ++ qcom,pvs { ++ qcom,pvs-format-a; ++ qcom,speed0-pvs0-bin-v0 = ++ < 384000000 950000 >, ++ < 486000000 975000 >, ++ < 594000000 1000000 >, ++ < 702000000 1025000 >, ++ < 810000000 1075000 >, ++ < 918000000 1100000 >, ++ < 1026000000 1125000 >, ++ < 1134000000 1175000 >, ++ < 1242000000 1200000 >, ++ < 1350000000 1225000 >, ++ < 1458000000 1237500 >, ++ < 1512000000 1250000 >; ++ }; +--- a/drivers/cpufreq/Kconfig.arm ++++ b/drivers/cpufreq/Kconfig.arm +@@ -95,6 +95,15 @@ + depends on ARCH_OMAP2PLUS + default ARCH_OMAP2PLUS + ++config ARM_QCOM_CPUFREQ ++ tristate "Qualcomm based" ++ depends on ARCH_QCOM ++ select PM_OPP ++ help ++ This adds the CPUFreq driver for Qualcomm SoC based boards. ++ ++ If in doubt, say N. ++ + config ARM_S3C_CPUFREQ + bool + help +--- a/drivers/cpufreq/Makefile ++++ b/drivers/cpufreq/Makefile +@@ -61,6 +61,7 @@ + obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o + obj-$(CONFIG_ARM_PXA2xx_CPUFREQ) += pxa2xx-cpufreq.o + obj-$(CONFIG_PXA3xx) += pxa3xx-cpufreq.o ++obj-$(CONFIG_ARM_QCOM_CPUFREQ) += qcom-cpufreq.o + obj-$(CONFIG_ARM_S3C24XX_CPUFREQ) += s3c24xx-cpufreq.o + obj-$(CONFIG_ARM_S3C24XX_CPUFREQ_DEBUGFS) += s3c24xx-cpufreq-debugfs.o + obj-$(CONFIG_ARM_S3C2410_CPUFREQ) += s3c2410-cpufreq.o +--- /dev/null ++++ b/drivers/cpufreq/qcom-cpufreq.c +@@ -0,0 +1,204 @@ ++/* Copyright (c) 2014, The Linux Foundation. All rights reserved. ++ * ++ * This program is free software; you can redistribute it and/or modify ++ * it under the terms of the GNU General Public License version 2 and ++ * only version 2 as published by the Free Software Foundation. ++ * ++ * 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. ++ */ ++ ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++ ++static void __init get_krait_bin_format_a(int *speed, int *pvs, int *pvs_ver) ++{ ++ void __iomem *base; ++ u32 pte_efuse; ++ ++ *speed = *pvs = *pvs_ver = 0; ++ ++ base = ioremap(0x007000c0, 4); ++ if (!base) { ++ pr_warn("Unable to read efuse data. Defaulting to 0!\n"); ++ return; ++ } ++ ++ pte_efuse = readl_relaxed(base); ++ iounmap(base); ++ ++ *speed = pte_efuse & 0xf; ++ if (*speed == 0xf) ++ *speed = (pte_efuse >> 4) & 0xf; ++ ++ if (*speed == 0xf) { ++ *speed = 0; ++ pr_warn("Speed bin: Defaulting to %d\n", *speed); ++ } else { ++ pr_info("Speed bin: %d\n", *speed); ++ } ++ ++ *pvs = (pte_efuse >> 10) & 0x7; ++ if (*pvs == 0x7) ++ *pvs = (pte_efuse >> 13) & 0x7; ++ ++ if (*pvs == 0x7) { ++ *pvs = 0; ++ pr_warn("PVS bin: Defaulting to %d\n", *pvs); ++ } else { ++ pr_info("PVS bin: %d\n", *pvs); ++ } ++} ++ ++static void __init get_krait_bin_format_b(int *speed, int *pvs, int *pvs_ver) ++{ ++ u32 pte_efuse, redundant_sel; ++ void __iomem *base; ++ ++ *speed = 0; ++ *pvs = 0; ++ *pvs_ver = 0; ++ ++ base = ioremap(0xfc4b80b0, 8); ++ if (!base) { ++ pr_warn("Unable to read efuse data. Defaulting to 0!\n"); ++ return; ++ } ++ ++ pte_efuse = readl_relaxed(base); ++ redundant_sel = (pte_efuse >> 24) & 0x7; ++ *speed = pte_efuse & 0x7; ++ /* 4 bits of PVS are in efuse register bits 31, 8-6. */ ++ *pvs = ((pte_efuse >> 28) & 0x8) | ((pte_efuse >> 6) & 0x7); ++ *pvs_ver = (pte_efuse >> 4) & 0x3; ++ ++ switch (redundant_sel) { ++ case 1: ++ *speed = (pte_efuse >> 27) & 0xf; ++ break; ++ case 2: ++ *pvs = (pte_efuse >> 27) & 0xf; ++ break; ++ } ++ ++ /* Check SPEED_BIN_BLOW_STATUS */ ++ if (pte_efuse & BIT(3)) { ++ pr_info("Speed bin: %d\n", *speed); ++ } else { ++ pr_warn("Speed bin not set. Defaulting to 0!\n"); ++ *speed = 0; ++ } ++ ++ /* Check PVS_BLOW_STATUS */ ++ pte_efuse = readl_relaxed(base + 0x4) & BIT(21); ++ if (pte_efuse) { ++ pr_info("PVS bin: %d\n", *pvs); ++ } else { ++ pr_warn("PVS bin not set. Defaulting to 0!\n"); ++ *pvs = 0; ++ } ++ ++ pr_info("PVS version: %d\n", *pvs_ver); ++ iounmap(base); ++} ++ ++static int __init qcom_cpufreq_populate_opps(void) ++{ ++ int len, rows, cols, i, k, speed, pvs, pvs_ver; ++ char table_name[] = "qcom,speedXX-pvsXX-bin-vXX"; ++ struct device_node *np; ++ struct device *dev; ++ int cpu = 0; ++ ++ np = of_find_node_by_name(NULL, "qcom,pvs"); ++ if (!np) ++ return -ENODEV; ++ ++ if (of_property_read_bool(np, "qcom,pvs-format-a")) { ++ get_krait_bin_format_a(&speed, &pvs, &pvs_ver); ++ cols = 2; ++ } else if (of_property_read_bool(np, "qcom,pvs-format-b")) { ++ get_krait_bin_format_b(&speed, &pvs, &pvs_ver); ++ cols = 3; ++ } else { ++ return -ENODEV; ++ } ++ ++ snprintf(table_name, sizeof(table_name), ++ "qcom,speed%d-pvs%d-bin-v%d", speed, pvs, pvs_ver); ++ ++ if (!of_find_property(np, table_name, &len)) ++ return -EINVAL; ++ ++ len /= sizeof(u32); ++ if (len % cols || len == 0) ++ return -EINVAL; ++ ++ rows = len / cols; ++ ++ for (i = 0, k = 0; i < rows; i++) { ++ u32 freq, volt; ++ ++ of_property_read_u32_index(np, table_name, k++, &freq); ++ of_property_read_u32_index(np, table_name, k++, &volt); ++ while (k % cols) ++ k++; /* Skip uA entries if present */ ++ for (cpu = 0; cpu < num_possible_cpus(); cpu++) { ++ dev = get_cpu_device(cpu); ++ if (!dev) ++ return -ENODEV; ++ if (dev_pm_opp_add(dev, freq, volt)) ++ pr_warn("failed to add OPP %u\n", freq); ++ } ++ } ++ ++ return 0; ++} ++ ++static int __init qcom_cpufreq_driver_init(void) ++{ ++ struct cpufreq_dt_platform_data pdata = { .independent_clocks = true }; ++ struct platform_device_info devinfo = { ++ .name = "cpufreq-dt", ++ .data = &pdata, ++ .size_data = sizeof(pdata), ++ }; ++ struct device *cpu_dev; ++ struct device_node *np; ++ int ret; ++ ++ cpu_dev = get_cpu_device(0); ++ if (!cpu_dev) ++ return -ENODEV; ++ ++ np = of_node_get(cpu_dev->of_node); ++ if (!np) ++ return -ENOENT; ++ ++ if (!of_device_is_compatible(np, "qcom,krait")) { ++ of_node_put(np); ++ return -ENODEV; ++ } ++ of_node_put(np); ++ ++ ret = qcom_cpufreq_populate_opps(); ++ if (ret) ++ return ret; ++ ++ return PTR_ERR_OR_ZERO(platform_device_register_full(&devinfo)); ++} ++module_init(qcom_cpufreq_driver_init); ++ ++MODULE_DESCRIPTION("Qualcomm CPUfreq driver"); ++MODULE_LICENSE("GPL v2"); diff --git a/target/linux/ipq806x/patches-4.4/144-ARM-dts-qcom-Add-necessary-DT-data-for-Krait-cpufreq.patch b/target/linux/ipq806x/patches-4.4/144-ARM-dts-qcom-Add-necessary-DT-data-for-Krait-cpufreq.patch new file mode 100644 index 0000000..aaf1401 --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/144-ARM-dts-qcom-Add-necessary-DT-data-for-Krait-cpufreq.patch @@ -0,0 +1,100 @@ +--- a/arch/arm/boot/dts/qcom-ipq8064.dtsi ++++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi +@@ -26,6 +26,11 @@ + next-level-cache = <&L2>; + qcom,acc = <&acc0>; + qcom,saw = <&saw0>; ++ clocks = <&kraitcc 0>; ++ clock-names = "cpu"; ++ clock-latency = <100000>; ++ core-supply = <&smb208_s2a>; ++ voltage-tolerance = <5>; + }; + + cpu at 1 { +@@ -36,11 +41,24 @@ + next-level-cache = <&L2>; + qcom,acc = <&acc1>; + qcom,saw = <&saw1>; ++ clocks = <&kraitcc 1>; ++ clock-names = "cpu"; ++ clock-latency = <100000>; ++ core-supply = <&smb208_s2b>; + }; + + L2: l2-cache { + compatible = "cache"; + cache-level = <2>; ++ clocks = <&kraitcc 4>; ++ clock-names = "cache"; ++ cache-points-kHz = < ++ /* kHz uV CPU kHz */ ++ 1200000 1150000 1200000 ++ 1000000 1100000 600000 ++ 384000 1100000 384000 ++ >; ++ vdd_dig-supply = <&smb208_s1a>; + }; + }; + +@@ -73,6 +91,46 @@ + }; + }; + ++ kraitcc: clock-controller { ++ compatible = "qcom,krait-cc-v1"; ++ #clock-cells = <1>; ++ }; ++ ++ qcom,pvs { ++ qcom,pvs-format-a; ++ qcom,speed0-pvs0-bin-v0 = ++ < 1400000000 1250000 >, ++ < 1200000000 1200000 >, ++ < 1000000000 1150000 >, ++ < 800000000 1100000 >, ++ < 600000000 1050000 >, ++ < 384000000 1000000 >; ++ ++ qcom,speed0-pvs1-bin-v0 = ++ < 1400000000 1175000 >, ++ < 1200000000 1125000 >, ++ < 1000000000 1075000 >, ++ < 800000000 1025000 >, ++ < 600000000 975000 >, ++ < 384000000 925000 >; ++ ++ qcom,speed0-pvs2-bin-v0 = ++ < 1400000000 1125000 >, ++ < 1200000000 1075000 >, ++ < 1000000000 1025000 >, ++ < 800000000 995000 >, ++ < 600000000 925000 >, ++ < 384000000 875000 >; ++ ++ qcom,speed0-pvs3-bin-v0 = ++ < 1400000000 1050000 >, ++ < 1200000000 1000000 >, ++ < 1000000000 950000 >, ++ < 800000000 900000 >, ++ < 600000000 850000 >, ++ < 384000000 800000 >; ++ }; ++ + soc: soc { + #address-cells = <1>; + #size-cells = <1>; +@@ -215,11 +273,13 @@ + acc0: clock-controller at 2088000 { + compatible = "qcom,kpss-acc-v1"; + reg = <0x02088000 0x1000>, <0x02008000 0x1000>; ++ clock-output-names = "acpu0_aux"; + }; + + acc1: clock-controller at 2098000 { + compatible = "qcom,kpss-acc-v1"; + reg = <0x02098000 0x1000>, <0x02008000 0x1000>; ++ clock-output-names = "acpu1_aux"; + }; + + l2cc: clock-controller at 2011000 { diff --git a/target/linux/ipq806x/patches-4.4/145-cpufreq-Add-a-cpufreq-krait-based-on-cpufre.patch b/target/linux/ipq806x/patches-4.4/145-cpufreq-Add-a-cpufreq-krait-based-on-cpufre.patch new file mode 100644 index 0000000..f33c9e0 --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/145-cpufreq-Add-a-cpufreq-krait-based-on-cpufre.patch @@ -0,0 +1,461 @@ +From dd77db4143290689d3a5e1ec61627233d0711b66 Mon Sep 17 00:00:00 2001 +From: Stephen Boyd +Date: Fri, 30 May 2014 16:36:11 -0700 +Subject: [PATCH] FROMLIST: cpufreq: Add a cpufreq-krait based on cpufreq-cpu0 + +Krait processors have individual clocks for each CPU that can +scale independently from one another. cpufreq-cpu0 is fairly +close to this, but assumes that there is only one clock for all +CPUs. Add a driver to support the Krait configuration. + +TODO: Merge into cpufreq-cpu0? Or make generic? + +Signed-off-by: Stephen Boyd + +--- + drivers/cpufreq/Kconfig | 13 +++ + drivers/cpufreq/Makefile | 1 + + drivers/cpufreq/cpufreq-krait.c | 190 ++++++++++++++++++++++++++++++++++++++++ + 3 files changed, 204 insertions(+) + create mode 100644 drivers/cpufreq/cpufreq-krait.c + +--- a/drivers/cpufreq/Kconfig ++++ b/drivers/cpufreq/Kconfig +@@ -198,6 +198,19 @@ + + If in doubt, say N. + ++config GENERIC_CPUFREQ_KRAIT ++ tristate "Krait cpufreq driver" ++ depends on HAVE_CLK && OF ++ # if CPU_THERMAL is on and THERMAL=m, CPU0 cannot be =y: ++ depends on !CPU_THERMAL || THERMAL ++ select PM_OPP ++ help ++ This adds a generic cpufreq driver for CPU0 frequency management. ++ It supports both uniprocessor (UP) and symmetric multiprocessor (SMP) ++ systems which share clock and voltage across all CPUs. ++ ++ If in doubt, say N. ++ + if X86 + source "drivers/cpufreq/Kconfig.x86" + endif +--- a/drivers/cpufreq/Makefile ++++ b/drivers/cpufreq/Makefile +@@ -13,6 +13,7 @@ + obj-$(CONFIG_CPU_FREQ_GOV_COMMON) += cpufreq_governor.o + + obj-$(CONFIG_CPUFREQ_DT) += cpufreq-dt.o ++obj-$(CONFIG_GENERIC_CPUFREQ_KRAIT) += cpufreq-krait.o + + ################################################################################## + # x86 drivers. +--- /dev/null ++++ b/drivers/cpufreq/cpufreq-krait.c +@@ -0,0 +1,390 @@ ++/* ++ * Copyright (C) 2012 Freescale Semiconductor, Inc. ++ * Copyright (c) 2014, The Linux Foundation. All rights reserved. ++ * ++ * The OPP code in function krait_set_target() is reused from ++ * drivers/cpufreq/omap-cpufreq.c ++ * ++ * This program is free software; you can redistribute it and/or modify ++ * it under the terms of the GNU General Public License version 2 as ++ * published by the Free Software Foundation. ++ */ ++ ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++ ++static unsigned int transition_latency; ++static unsigned int voltage_tolerance; /* in percentage */ ++ ++static struct device *cpu_dev; ++static DEFINE_PER_CPU(struct clk *, krait_cpu_clks); ++static DEFINE_PER_CPU(struct regulator *, krait_supply_core); ++static struct cpufreq_frequency_table *freq_table; ++static struct thermal_cooling_device *cdev; ++ ++struct cache_points { ++ unsigned long cache_freq; ++ unsigned int cache_volt; ++ unsigned long cpu_freq; ++}; ++ ++static struct regulator *krait_l2_reg; ++static struct clk *krait_l2_clk; ++static struct cache_points *krait_l2_points; ++static int nr_krait_l2_points; ++ ++static int krait_parse_cache_points(struct device *dev, ++ struct device_node *of_node) ++{ ++ const struct property *prop; ++ const __be32 *val; ++ int nr, i; ++ ++ prop = of_find_property(of_node, "cache-points-kHz", NULL); ++ if (!prop) ++ return -ENODEV; ++ if (!prop->value) ++ return -ENODATA; ++ ++ /* ++ * Each OPP is a set of tuples consisting of frequency and ++ * cpu-frequency like . ++ */ ++ nr = prop->length / sizeof(u32); ++ if (nr % 3) { ++ dev_err(dev, "%s: Invalid cache points\n", __func__); ++ return -EINVAL; ++ } ++ nr /= 3; ++ ++ krait_l2_points = devm_kcalloc(dev, nr, sizeof(*krait_l2_points), ++ GFP_KERNEL); ++ if (!krait_l2_points) ++ return -ENOMEM; ++ nr_krait_l2_points = nr; ++ ++ for (i = 0, val = prop->value; i < nr; i++) { ++ unsigned long cache_freq = be32_to_cpup(val++) * 1000; ++ unsigned int cache_volt = be32_to_cpup(val++); ++ unsigned long cpu_freq = be32_to_cpup(val++) * 1000; ++ ++ krait_l2_points[i].cache_freq = cache_freq; ++ krait_l2_points[i].cache_volt = cache_volt; ++ krait_l2_points[i].cpu_freq = cpu_freq; ++ } ++ ++ return 0; ++} ++ ++static int krait_set_target(struct cpufreq_policy *policy, unsigned int index) ++{ ++ struct dev_pm_opp *opp; ++ unsigned long volt = 0, volt_old = 0, tol = 0; ++ unsigned long freq, max_cpu_freq = 0; ++ unsigned int old_freq, new_freq; ++ long freq_Hz, freq_exact; ++ int ret, i; ++ struct clk *cpu_clk; ++ struct regulator *core; ++ unsigned int cpu; ++ ++ cpu_clk = per_cpu(krait_cpu_clks, policy->cpu); ++ ++ freq_Hz = clk_round_rate(cpu_clk, freq_table[index].frequency * 1000); ++ if (freq_Hz <= 0) ++ freq_Hz = freq_table[index].frequency * 1000; ++ ++ freq_exact = freq_Hz; ++ new_freq = freq_Hz / 1000; ++ old_freq = clk_get_rate(cpu_clk) / 1000; ++ ++ core = per_cpu(krait_supply_core, policy->cpu); ++ ++ rcu_read_lock(); ++ opp = dev_pm_opp_find_freq_ceil(cpu_dev, &freq_Hz); ++ if (IS_ERR(opp)) { ++ rcu_read_unlock(); ++ pr_err("failed to find OPP for %ld\n", freq_Hz); ++ return PTR_ERR(opp); ++ } ++ volt = dev_pm_opp_get_voltage(opp); ++ rcu_read_unlock(); ++ tol = volt * voltage_tolerance / 100; ++ volt_old = regulator_get_voltage(core); ++ ++ pr_debug("%u MHz, %ld mV --> %u MHz, %ld mV\n", ++ old_freq / 1000, volt_old ? volt_old / 1000 : -1, ++ new_freq / 1000, volt ? volt / 1000 : -1); ++ ++ /* scaling up? scale voltage before frequency */ ++ if (new_freq > old_freq) { ++ ret = regulator_set_voltage_tol(core, volt, tol); ++ if (ret) { ++ pr_err("failed to scale voltage up: %d\n", ret); ++ return ret; ++ } ++ } ++ ++ ret = clk_set_rate(cpu_clk, freq_exact); ++ if (ret) { ++ pr_err("failed to set clock rate: %d\n", ret); ++ return ret; ++ } ++ ++ /* scaling down? scale voltage after frequency */ ++ if (new_freq < old_freq) { ++ ret = regulator_set_voltage_tol(core, volt, tol); ++ if (ret) { ++ pr_err("failed to scale voltage down: %d\n", ret); ++ clk_set_rate(cpu_clk, old_freq * 1000); ++ } ++ } ++ ++ for_each_possible_cpu(cpu) { ++ freq = clk_get_rate(per_cpu(krait_cpu_clks, cpu)); ++ max_cpu_freq = max(max_cpu_freq, freq); ++ } ++ ++ for (i = 0; i < nr_krait_l2_points; i++) { ++ if (max_cpu_freq >= krait_l2_points[i].cpu_freq) { ++ if (krait_l2_reg) { ++ ret = regulator_set_voltage_tol(krait_l2_reg, ++ krait_l2_points[i].cache_volt, ++ tol); ++ if (ret) { ++ pr_err("failed to scale l2 voltage: %d\n", ++ ret); ++ } ++ } ++ ret = clk_set_rate(krait_l2_clk, ++ krait_l2_points[i].cache_freq); ++ if (ret) ++ pr_err("failed to scale l2 clk: %d\n", ret); ++ break; ++ } ++ ++ } ++ ++ return ret; ++} ++ ++static int krait_cpufreq_init(struct cpufreq_policy *policy) ++{ ++ int ret; ++ ++ policy->clk = per_cpu(krait_cpu_clks, policy->cpu); ++ ++ ret = cpufreq_table_validate_and_show(policy, freq_table); ++ if (ret) { ++ pr_err("%s: invalid frequency table: %d\n", __func__, ret); ++ return ret; ++ } ++ ++ policy->cpuinfo.transition_latency = transition_latency; ++ ++ return 0; ++} ++ ++static struct cpufreq_driver krait_cpufreq_driver = { ++ .flags = CPUFREQ_STICKY, ++ .verify = cpufreq_generic_frequency_table_verify, ++ .target_index = krait_set_target, ++ .get = cpufreq_generic_get, ++ .init = krait_cpufreq_init, ++ .name = "generic_krait", ++ .attr = cpufreq_generic_attr, ++}; ++ ++static int krait_cpufreq_probe(struct platform_device *pdev) ++{ ++ struct device_node *np, *cache; ++ int ret, i; ++ unsigned int cpu; ++ struct device *dev; ++ struct clk *clk; ++ struct regulator *core; ++ unsigned long freq_Hz, freq, max_cpu_freq = 0; ++ struct dev_pm_opp *opp; ++ unsigned long volt, tol; ++ ++ cpu_dev = get_cpu_device(0); ++ if (!cpu_dev) { ++ pr_err("failed to get krait device\n"); ++ return -ENODEV; ++ } ++ ++ np = of_node_get(cpu_dev->of_node); ++ if (!np) { ++ pr_err("failed to find krait node\n"); ++ return -ENOENT; ++ } ++ ++ ret = dev_pm_opp_init_cpufreq_table(cpu_dev, &freq_table); ++ if (ret) { ++ pr_err("failed to init cpufreq table: %d\n", ret); ++ goto out_put_node; ++ } ++ ++ of_property_read_u32(np, "voltage-tolerance", &voltage_tolerance); ++ ++ if (of_property_read_u32(np, "clock-latency", &transition_latency)) ++ transition_latency = CPUFREQ_ETERNAL; ++ ++ cache = of_find_next_cache_node(np); ++ if (cache) { ++ struct device_node *vdd; ++ ++ vdd = of_parse_phandle(cache, "vdd_dig-supply", 0); ++ if (vdd) { ++ krait_l2_reg = regulator_get(NULL, vdd->name); ++ if (IS_ERR(krait_l2_reg)) { ++ pr_warn("failed to get l2 vdd_dig supply\n"); ++ krait_l2_reg = NULL; ++ } ++ of_node_put(vdd); ++ } ++ ++ krait_l2_clk = of_clk_get(cache, 0); ++ if (!IS_ERR(krait_l2_clk)) { ++ ret = krait_parse_cache_points(&pdev->dev, cache); ++ if (ret) ++ clk_put(krait_l2_clk); ++ } ++ if (IS_ERR(krait_l2_clk) || ret) ++ krait_l2_clk = NULL; ++ } ++ ++ for_each_possible_cpu(cpu) { ++ dev = get_cpu_device(cpu); ++ if (!dev) { ++ pr_err("failed to get krait device\n"); ++ ret = -ENOENT; ++ goto out_free_table; ++ } ++ per_cpu(krait_cpu_clks, cpu) = clk = devm_clk_get(dev, NULL); ++ if (IS_ERR(clk)) { ++ ret = PTR_ERR(clk); ++ goto out_free_table; ++ } ++ core = devm_regulator_get(dev, "core"); ++ if (IS_ERR(core)) { ++ pr_debug("failed to get core regulator\n"); ++ ret = PTR_ERR(core); ++ goto out_free_table; ++ } ++ per_cpu(krait_supply_core, cpu) = core; ++ ++ freq = freq_Hz = clk_get_rate(clk); ++ ++ rcu_read_lock(); ++ opp = dev_pm_opp_find_freq_ceil(cpu_dev, &freq_Hz); ++ if (IS_ERR(opp)) { ++ rcu_read_unlock(); ++ pr_err("failed to find OPP for %ld\n", freq_Hz); ++ ret = PTR_ERR(opp); ++ goto out_free_table; ++ } ++ volt = dev_pm_opp_get_voltage(opp); ++ rcu_read_unlock(); ++ ++ tol = volt * voltage_tolerance / 100; ++ ret = regulator_set_voltage_tol(core, volt, tol); ++ if (ret) { ++ pr_err("failed to scale voltage up: %d\n", ret); ++ goto out_free_table; ++ } ++ ret = regulator_enable(core); ++ if (ret) { ++ pr_err("failed to enable regulator: %d\n", ret); ++ goto out_free_table; ++ } ++ max_cpu_freq = max(max_cpu_freq, freq); ++ } ++ ++ for (i = 0; i < nr_krait_l2_points; i++) { ++ if (max_cpu_freq >= krait_l2_points[i].cpu_freq) { ++ if (krait_l2_reg) { ++ ret = regulator_set_voltage_tol(krait_l2_reg, ++ krait_l2_points[i].cache_volt, ++ tol); ++ if (ret) ++ pr_err("failed to scale l2 voltage: %d\n", ++ ret); ++ ret = regulator_enable(krait_l2_reg); ++ if (ret) ++ pr_err("failed to enable l2 voltage: %d\n", ++ ret); ++ } ++ break; ++ } ++ ++ } ++ ++ ret = cpufreq_register_driver(&krait_cpufreq_driver); ++ if (ret) { ++ pr_err("failed register driver: %d\n", ret); ++ goto out_free_table; ++ } ++ of_node_put(np); ++ ++ /* ++ * For now, just loading the cooling device; ++ * thermal DT code takes care of matching them. ++ */ ++ for_each_possible_cpu(cpu) { ++ dev = get_cpu_device(cpu); ++ np = of_node_get(dev->of_node); ++ if (of_find_property(np, "#cooling-cells", NULL)) { ++ cdev = of_cpufreq_cooling_register(np, cpumask_of(cpu)); ++ if (IS_ERR(cdev)) ++ pr_err("running cpufreq without cooling device: %ld\n", ++ PTR_ERR(cdev)); ++ } ++ of_node_put(np); ++ } ++ ++ return 0; ++ ++out_free_table: ++ regulator_put(krait_l2_reg); ++ clk_put(krait_l2_clk); ++ dev_pm_opp_free_cpufreq_table(cpu_dev, &freq_table); ++out_put_node: ++ of_node_put(np); ++ return ret; ++} ++ ++static int krait_cpufreq_remove(struct platform_device *pdev) ++{ ++ cpufreq_cooling_unregister(cdev); ++ cpufreq_unregister_driver(&krait_cpufreq_driver); ++ dev_pm_opp_free_cpufreq_table(cpu_dev, &freq_table); ++ clk_put(krait_l2_clk); ++ regulator_put(krait_l2_reg); ++ ++ return 0; ++} ++ ++static struct platform_driver krait_cpufreq_platdrv = { ++ .driver = { ++ .name = "cpufreq-krait", ++ .owner = THIS_MODULE, ++ }, ++ .probe = krait_cpufreq_probe, ++ .remove = krait_cpufreq_remove, ++}; ++module_platform_driver(krait_cpufreq_platdrv); ++ ++MODULE_DESCRIPTION("Krait CPUfreq driver"); ++MODULE_LICENSE("GPL v2"); +--- a/drivers/cpufreq/qcom-cpufreq.c ++++ b/drivers/cpufreq/qcom-cpufreq.c +@@ -168,11 +168,8 @@ + + static int __init qcom_cpufreq_driver_init(void) + { +- struct cpufreq_dt_platform_data pdata = { .independent_clocks = true }; + struct platform_device_info devinfo = { +- .name = "cpufreq-dt", +- .data = &pdata, +- .size_data = sizeof(pdata), ++ .name = "cpufreq-krait", + }; + struct device *cpu_dev; + struct device_node *np; diff --git a/target/linux/ipq806x/patches-4.4/155-dt-bindings-qcom_adm-Fix-channel-specifiers.patch b/target/linux/ipq806x/patches-4.4/155-dt-bindings-qcom_adm-Fix-channel-specifiers.patch new file mode 100644 index 0000000..4f5c0ef --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/155-dt-bindings-qcom_adm-Fix-channel-specifiers.patch @@ -0,0 +1,76 @@ +Content-Type: text/plain; charset="utf-8" +MIME-Version: 1.0 +Content-Transfer-Encoding: 7bit +Subject: [v6,1/2] dt/bindings: qcom_adm: Fix channel specifiers +From: Andy Gross +X-Patchwork-Id: 6027361 +Message-Id: <1426571172-9711-2-git-send-email-agross at codeaurora.org> +To: Vinod Koul +Cc: devicetree at vger.kernel.org, dmaengine at vger.kernel.org, + linux-arm-msm at vger.kernel.org, linux-kernel at vger.kernel.org, + linux-arm-kernel at lists.infradead.org, Kumar Gala , + Bjorn Andersson , + Andy Gross +Date: Tue, 17 Mar 2015 00:46:11 -0500 + +This patch removes the crci information from the dma channel property. At least +one client device requires using more than one CRCI value for a channel. This +does not match the current binding and the crci information needs to be removed. + +Instead, the client device will provide this information via other means. + +Signed-off-by: Andy Gross + +--- +Documentation/devicetree/bindings/dma/qcom_adm.txt | 16 ++++++---------- + 1 file changed, 6 insertions(+), 10 deletions(-) + +--- a/Documentation/devicetree/bindings/dma/qcom_adm.txt ++++ b/Documentation/devicetree/bindings/dma/qcom_adm.txt +@@ -4,8 +4,7 @@ Required properties: + - compatible: must contain "qcom,adm" for IPQ/APQ8064 and MSM8960 + - reg: Address range for DMA registers + - interrupts: Should contain one interrupt shared by all channels +-- #dma-cells: must be <2>. First cell denotes the channel number. Second cell +- denotes CRCI (client rate control interface) flow control assignment. ++- #dma-cells: must be <1>. First cell denotes the channel number. + - clocks: Should contain the core clock and interface clock. + - clock-names: Must contain "core" for the core clock and "iface" for the + interface clock. +@@ -22,7 +21,7 @@ Example: + compatible = "qcom,adm"; + reg = <0x18300000 0x100000>; + interrupts = <0 170 0>; +- #dma-cells = <2>; ++ #dma-cells = <1>; + + clocks = <&gcc ADM0_CLK>, <&gcc ADM0_PBUS_CLK>; + clock-names = "core", "iface"; +@@ -35,15 +34,12 @@ Example: + qcom,ee = <0>; + }; + +-DMA clients must use the format descripted in the dma.txt file, using a three ++DMA clients must use the format descripted in the dma.txt file, using a two + cell specifier for each channel. + +-Each dmas request consists of 3 cells: ++Each dmas request consists of two cells: + 1. phandle pointing to the DMA controller + 2. channel number +- 3. CRCI assignment, if applicable. If no CRCI flow control is required, use 0. +- The CRCI is used for flow control. It identifies the peripheral device that +- is the source/destination for the transferred data. + + Example: + +@@ -56,7 +52,7 @@ Example: + + cs-gpios = <&qcom_pinmux 20 0>; + +- dmas = <&adm_dma 6 9>, +- <&adm_dma 5 10>; ++ dmas = <&adm_dma 6>, ++ <&adm_dma 5>; + dma-names = "rx", "tx"; + }; diff --git a/target/linux/ipq806x/patches-4.4/156-dmaengine-Add-ADM-driver.patch b/target/linux/ipq806x/patches-4.4/156-dmaengine-Add-ADM-driver.patch new file mode 100644 index 0000000..805f28f --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/156-dmaengine-Add-ADM-driver.patch @@ -0,0 +1,964 @@ +Content-Type: text/plain; charset="utf-8" +MIME-Version: 1.0 +Content-Transfer-Encoding: 7bit +Subject: [v6,2/2] dmaengine: Add ADM driver +From: Andy Gross +X-Patchwork-Id: 6027351 +Message-Id: <1426571172-9711-3-git-send-email-agross at codeaurora.org> +To: Vinod Koul +Cc: devicetree at vger.kernel.org, dmaengine at vger.kernel.org, + linux-arm-msm at vger.kernel.org, linux-kernel at vger.kernel.org, + linux-arm-kernel at lists.infradead.org, Kumar Gala , + Bjorn Andersson , + Andy Gross +Date: Tue, 17 Mar 2015 00:46:12 -0500 + +Add the DMA engine driver for the QCOM Application Data Mover (ADM) DMA +controller found in the MSM8x60 and IPQ/APQ8064 platforms. + +The ADM supports both memory to memory transactions and memory +to/from peripheral device transactions. The controller also provides flow +control capabilities for transactions to/from peripheral devices. + +The initial release of this driver supports slave transfers to/from peripherals +and also incorporates CRCI (client rate control interface) flow control. + +Signed-off-by: Andy Gross +Reviewed-by: sricharan + +--- +drivers/dma/Kconfig | 10 + + drivers/dma/Makefile | 1 + + drivers/dma/qcom_adm.c | 900 ++++++++++++++++++++++++++++++++++++++++++++++++ + 3 files changed, 911 insertions(+) + create mode 100644 drivers/dma/qcom_adm.c + +--- a/drivers/dma/Kconfig ++++ b/drivers/dma/Kconfig +@@ -558,4 +558,14 @@ + config DMA_ENGINE_RAID + bool + ++config QCOM_ADM ++ tristate "Qualcomm ADM support" ++ depends on ARCH_QCOM || (COMPILE_TEST && OF && ARM) ++ select DMA_ENGINE ++ select DMA_VIRTUAL_CHANNELS ++ ---help--- ++ Enable support for the Qualcomm ADM DMA controller. This controller ++ provides DMA capabilities for both general purpose and on-chip ++ peripheral devices. ++ + endif +--- /dev/null ++++ b/drivers/dma/qcom_adm.c +@@ -0,0 +1,900 @@ ++/* ++ * Copyright (c) 2013-2015, The Linux Foundation. All rights reserved. ++ * ++ * This program is free software; you can redistribute it and/or modify ++ * it under the terms of the GNU General Public License version 2 and ++ * only version 2 as published by the Free Software Foundation. ++ * ++ * 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. ++ * ++ */ ++ ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++ ++#include "dmaengine.h" ++#include "virt-dma.h" ++ ++/* ADM registers - calculated from channel number and security domain */ ++#define ADM_CHAN_MULTI 0x4 ++#define ADM_CI_MULTI 0x4 ++#define ADM_CRCI_MULTI 0x4 ++#define ADM_EE_MULTI 0x800 ++#define ADM_CHAN_OFFS(chan) (ADM_CHAN_MULTI * chan) ++#define ADM_EE_OFFS(ee) (ADM_EE_MULTI * ee) ++#define ADM_CHAN_EE_OFFS(chan, ee) (ADM_CHAN_OFFS(chan) + ADM_EE_OFFS(ee)) ++#define ADM_CHAN_OFFS(chan) (ADM_CHAN_MULTI * chan) ++#define ADM_CI_OFFS(ci) (ADM_CHAN_OFF(ci)) ++#define ADM_CH_CMD_PTR(chan, ee) (ADM_CHAN_EE_OFFS(chan, ee)) ++#define ADM_CH_RSLT(chan, ee) (0x40 + ADM_CHAN_EE_OFFS(chan, ee)) ++#define ADM_CH_FLUSH_STATE0(chan, ee) (0x80 + ADM_CHAN_EE_OFFS(chan, ee)) ++#define ADM_CH_STATUS_SD(chan, ee) (0x200 + ADM_CHAN_EE_OFFS(chan, ee)) ++#define ADM_CH_CONF(chan) (0x240 + ADM_CHAN_OFFS(chan)) ++#define ADM_CH_RSLT_CONF(chan, ee) (0x300 + ADM_CHAN_EE_OFFS(chan, ee)) ++#define ADM_SEC_DOMAIN_IRQ_STATUS(ee) (0x380 + ADM_EE_OFFS(ee)) ++#define ADM_CI_CONF(ci) (0x390 + ci * ADM_CI_MULTI) ++#define ADM_GP_CTL 0x3d8 ++#define ADM_CRCI_CTL(crci, ee) (0x400 + crci * ADM_CRCI_MULTI + \ ++ ADM_EE_OFFS(ee)) ++ ++/* channel status */ ++#define ADM_CH_STATUS_VALID BIT(1) ++ ++/* channel result */ ++#define ADM_CH_RSLT_VALID BIT(31) ++#define ADM_CH_RSLT_ERR BIT(3) ++#define ADM_CH_RSLT_FLUSH BIT(2) ++#define ADM_CH_RSLT_TPD BIT(1) ++ ++/* channel conf */ ++#define ADM_CH_CONF_SHADOW_EN BIT(12) ++#define ADM_CH_CONF_MPU_DISABLE BIT(11) ++#define ADM_CH_CONF_PERM_MPU_CONF BIT(9) ++#define ADM_CH_CONF_FORCE_RSLT_EN BIT(7) ++#define ADM_CH_CONF_SEC_DOMAIN(ee) (((ee & 0x3) << 4) | ((ee & 0x4) << 11)) ++ ++/* channel result conf */ ++#define ADM_CH_RSLT_CONF_FLUSH_EN BIT(1) ++#define ADM_CH_RSLT_CONF_IRQ_EN BIT(0) ++ ++/* CRCI CTL */ ++#define ADM_CRCI_CTL_MUX_SEL BIT(18) ++#define ADM_CRCI_CTL_RST BIT(17) ++ ++/* CI configuration */ ++#define ADM_CI_RANGE_END(x) (x << 24) ++#define ADM_CI_RANGE_START(x) (x << 16) ++#define ADM_CI_BURST_4_WORDS BIT(2) ++#define ADM_CI_BURST_8_WORDS BIT(3) ++ ++/* GP CTL */ ++#define ADM_GP_CTL_LP_EN BIT(12) ++#define ADM_GP_CTL_LP_CNT(x) (x << 8) ++ ++/* Command pointer list entry */ ++#define ADM_CPLE_LP BIT(31) ++#define ADM_CPLE_CMD_PTR_LIST BIT(29) ++ ++/* Command list entry */ ++#define ADM_CMD_LC BIT(31) ++#define ADM_CMD_DST_CRCI(n) (((n) & 0xf) << 7) ++#define ADM_CMD_SRC_CRCI(n) (((n) & 0xf) << 3) ++ ++#define ADM_CMD_TYPE_SINGLE 0x0 ++#define ADM_CMD_TYPE_BOX 0x3 ++ ++#define ADM_CRCI_MUX_SEL BIT(4) ++#define ADM_DESC_ALIGN 8 ++#define ADM_MAX_XFER (SZ_64K-1) ++#define ADM_MAX_ROWS (SZ_64K-1) ++#define ADM_MAX_CHANNELS 16 ++ ++struct adm_desc_hw_box { ++ u32 cmd; ++ u32 src_addr; ++ u32 dst_addr; ++ u32 row_len; ++ u32 num_rows; ++ u32 row_offset; ++}; ++ ++struct adm_desc_hw_single { ++ u32 cmd; ++ u32 src_addr; ++ u32 dst_addr; ++ u32 len; ++}; ++ ++struct adm_async_desc { ++ struct virt_dma_desc vd; ++ struct adm_device *adev; ++ ++ size_t length; ++ enum dma_transfer_direction dir; ++ dma_addr_t dma_addr; ++ size_t dma_len; ++ ++ void *cpl; ++ dma_addr_t cp_addr; ++ u32 crci; ++ u32 mux; ++ u32 blk_size; ++}; ++ ++struct adm_chan { ++ struct virt_dma_chan vc; ++ struct adm_device *adev; ++ ++ /* parsed from DT */ ++ u32 id; /* channel id */ ++ ++ struct adm_async_desc *curr_txd; ++ struct dma_slave_config slave; ++ struct list_head node; ++ ++ int error; ++ int initialized; ++}; ++ ++static inline struct adm_chan *to_adm_chan(struct dma_chan *common) ++{ ++ return container_of(common, struct adm_chan, vc.chan); ++} ++ ++struct adm_device { ++ void __iomem *regs; ++ struct device *dev; ++ struct dma_device common; ++ struct device_dma_parameters dma_parms; ++ struct adm_chan *channels; ++ ++ u32 ee; ++ ++ struct clk *core_clk; ++ struct clk *iface_clk; ++ ++ struct reset_control *clk_reset; ++ struct reset_control *c0_reset; ++ struct reset_control *c1_reset; ++ struct reset_control *c2_reset; ++ int irq; ++}; ++ ++/** ++ * adm_free_chan - Frees dma resources associated with the specific channel ++ * ++ * Free all allocated descriptors associated with this channel ++ * ++ */ ++static void adm_free_chan(struct dma_chan *chan) ++{ ++ /* free all queued descriptors */ ++ vchan_free_chan_resources(to_virt_chan(chan)); ++} ++ ++/** ++ * adm_get_blksize - Get block size from burst value ++ * ++ */ ++static int adm_get_blksize(unsigned int burst) ++{ ++ int ret; ++ ++ switch (burst) { ++ case 16: ++ case 32: ++ case 64: ++ case 128: ++ ret = ffs(burst>>4) - 1; ++ break; ++ case 192: ++ ret = 4; ++ break; ++ case 256: ++ ret = 5; ++ break; ++ default: ++ ret = -EINVAL; ++ break; ++ } ++ ++ return ret; ++} ++ ++/** ++ * adm_process_fc_descriptors - Process descriptors for flow controlled xfers ++ * ++ * @achan: ADM channel ++ * @desc: Descriptor memory pointer ++ * @sg: Scatterlist entry ++ * @crci: CRCI value ++ * @burst: Burst size of transaction ++ * @direction: DMA transfer direction ++ */ ++static void *adm_process_fc_descriptors(struct adm_chan *achan, ++ void *desc, struct scatterlist *sg, u32 crci, u32 burst, ++ enum dma_transfer_direction direction) ++{ ++ struct adm_desc_hw_box *box_desc = NULL; ++ struct adm_desc_hw_single *single_desc; ++ u32 remainder = sg_dma_len(sg); ++ u32 rows, row_offset, crci_cmd; ++ u32 mem_addr = sg_dma_address(sg); ++ u32 *incr_addr = &mem_addr; ++ u32 *src, *dst; ++ ++ if (direction == DMA_DEV_TO_MEM) { ++ crci_cmd = ADM_CMD_SRC_CRCI(crci); ++ row_offset = burst; ++ src = &achan->slave.src_addr; ++ dst = &mem_addr; ++ } else { ++ crci_cmd = ADM_CMD_DST_CRCI(crci); ++ row_offset = burst << 16; ++ src = &mem_addr; ++ dst = &achan->slave.dst_addr; ++ } ++ ++ while (remainder >= burst) { ++ box_desc = desc; ++ box_desc->cmd = ADM_CMD_TYPE_BOX | crci_cmd; ++ box_desc->row_offset = row_offset; ++ box_desc->src_addr = *src; ++ box_desc->dst_addr = *dst; ++ ++ rows = remainder / burst; ++ rows = min_t(u32, rows, ADM_MAX_ROWS); ++ box_desc->num_rows = rows << 16 | rows; ++ box_desc->row_len = burst << 16 | burst; ++ ++ *incr_addr += burst * rows; ++ remainder -= burst * rows; ++ desc += sizeof(*box_desc); ++ } ++ ++ /* if leftover bytes, do one single descriptor */ ++ if (remainder) { ++ single_desc = desc; ++ single_desc->cmd = ADM_CMD_TYPE_SINGLE | crci_cmd; ++ single_desc->len = remainder; ++ single_desc->src_addr = *src; ++ single_desc->dst_addr = *dst; ++ desc += sizeof(*single_desc); ++ ++ if (sg_is_last(sg)) ++ single_desc->cmd |= ADM_CMD_LC; ++ } else { ++ if (box_desc && sg_is_last(sg)) ++ box_desc->cmd |= ADM_CMD_LC; ++ } ++ ++ return desc; ++} ++ ++/** ++ * adm_process_non_fc_descriptors - Process descriptors for non-fc xfers ++ * ++ * @achan: ADM channel ++ * @desc: Descriptor memory pointer ++ * @sg: Scatterlist entry ++ * @direction: DMA transfer direction ++ */ ++static void *adm_process_non_fc_descriptors(struct adm_chan *achan, ++ void *desc, struct scatterlist *sg, ++ enum dma_transfer_direction direction) ++{ ++ struct adm_desc_hw_single *single_desc; ++ u32 remainder = sg_dma_len(sg); ++ u32 mem_addr = sg_dma_address(sg); ++ u32 *incr_addr = &mem_addr; ++ u32 *src, *dst; ++ ++ if (direction == DMA_DEV_TO_MEM) { ++ src = &achan->slave.src_addr; ++ dst = &mem_addr; ++ } else { ++ src = &mem_addr; ++ dst = &achan->slave.dst_addr; ++ } ++ ++ do { ++ single_desc = desc; ++ single_desc->cmd = ADM_CMD_TYPE_SINGLE; ++ single_desc->src_addr = *src; ++ single_desc->dst_addr = *dst; ++ single_desc->len = (remainder > ADM_MAX_XFER) ? ++ ADM_MAX_XFER : remainder; ++ ++ remainder -= single_desc->len; ++ *incr_addr += single_desc->len; ++ desc += sizeof(*single_desc); ++ } while (remainder); ++ ++ /* set last command if this is the end of the whole transaction */ ++ if (sg_is_last(sg)) ++ single_desc->cmd |= ADM_CMD_LC; ++ ++ return desc; ++} ++ ++/** ++ * adm_prep_slave_sg - Prep slave sg transaction ++ * ++ * @chan: dma channel ++ * @sgl: scatter gather list ++ * @sg_len: length of sg ++ * @direction: DMA transfer direction ++ * @flags: DMA flags ++ * @context: transfer context (unused) ++ */ ++static struct dma_async_tx_descriptor *adm_prep_slave_sg(struct dma_chan *chan, ++ struct scatterlist *sgl, unsigned int sg_len, ++ enum dma_transfer_direction direction, unsigned long flags, ++ void *context) ++{ ++ struct adm_chan *achan = to_adm_chan(chan); ++ struct adm_device *adev = achan->adev; ++ struct adm_async_desc *async_desc; ++ struct scatterlist *sg; ++ u32 i, burst; ++ u32 single_count = 0, box_count = 0, crci = 0; ++ void *desc; ++ u32 *cple; ++ int blk_size = 0; ++ ++ if (!is_slave_direction(direction)) { ++ dev_err(adev->dev, "invalid dma direction\n"); ++ return NULL; ++ } ++ ++ /* ++ * get burst value from slave configuration ++ */ ++ burst = (direction == DMA_MEM_TO_DEV) ? ++ achan->slave.dst_maxburst : ++ achan->slave.src_maxburst; ++ ++ /* if using flow control, validate burst and crci values */ ++ if (achan->slave.device_fc) { ++ ++ blk_size = adm_get_blksize(burst); ++ if (blk_size < 0) { ++ dev_err(adev->dev, "invalid burst value: %d\n", ++ burst); ++ return ERR_PTR(-EINVAL); ++ } ++ ++ crci = achan->slave.slave_id & 0xf; ++ if (!crci || achan->slave.slave_id > 0x1f) { ++ dev_err(adev->dev, "invalid crci value\n"); ++ return ERR_PTR(-EINVAL); ++ } ++ } ++ ++ /* iterate through sgs and compute allocation size of structures */ ++ for_each_sg(sgl, sg, sg_len, i) { ++ if (achan->slave.device_fc) { ++ box_count += DIV_ROUND_UP(sg_dma_len(sg) / burst, ++ ADM_MAX_ROWS); ++ if (sg_dma_len(sg) % burst) ++ single_count++; ++ } else { ++ single_count += DIV_ROUND_UP(sg_dma_len(sg), ++ ADM_MAX_XFER); ++ } ++ } ++ ++ async_desc = kzalloc(sizeof(*async_desc), GFP_NOWAIT); ++ if (!async_desc) ++ return ERR_PTR(-ENOMEM); ++ ++ if (crci) ++ async_desc->mux = achan->slave.slave_id & ADM_CRCI_MUX_SEL ? ++ ADM_CRCI_CTL_MUX_SEL : 0; ++ async_desc->crci = crci; ++ async_desc->blk_size = blk_size; ++ async_desc->dma_len = single_count * sizeof(struct adm_desc_hw_single) + ++ box_count * sizeof(struct adm_desc_hw_box) + ++ sizeof(*cple) + 2 * ADM_DESC_ALIGN; ++ ++ async_desc->cpl = dma_alloc_writecombine(adev->dev, async_desc->dma_len, ++ &async_desc->dma_addr, GFP_NOWAIT); ++ ++ if (!async_desc->cpl) { ++ kfree(async_desc); ++ return ERR_PTR(-ENOMEM); ++ } ++ ++ async_desc->adev = adev; ++ ++ /* both command list entry and descriptors must be 8 byte aligned */ ++ cple = PTR_ALIGN(async_desc->cpl, ADM_DESC_ALIGN); ++ desc = PTR_ALIGN(cple + 1, ADM_DESC_ALIGN); ++ ++ /* init cmd list */ ++ *cple = ADM_CPLE_LP; ++ *cple |= (desc - async_desc->cpl + async_desc->dma_addr) >> 3; ++ ++ for_each_sg(sgl, sg, sg_len, i) { ++ async_desc->length += sg_dma_len(sg); ++ ++ if (achan->slave.device_fc) ++ desc = adm_process_fc_descriptors(achan, desc, sg, crci, ++ burst, direction); ++ else ++ desc = adm_process_non_fc_descriptors(achan, desc, sg, ++ direction); ++ } ++ ++ return vchan_tx_prep(&achan->vc, &async_desc->vd, flags); ++} ++ ++/** ++ * adm_terminate_all - terminate all transactions on a channel ++ * @achan: adm dma channel ++ * ++ * Dequeues and frees all transactions, aborts current transaction ++ * No callbacks are done ++ * ++ */ ++static int adm_terminate_all(struct dma_chan *chan) ++{ ++ struct adm_chan *achan = to_adm_chan(chan); ++ struct adm_device *adev = achan->adev; ++ unsigned long flags; ++ LIST_HEAD(head); ++ ++ spin_lock_irqsave(&achan->vc.lock, flags); ++ vchan_get_all_descriptors(&achan->vc, &head); ++ ++ /* send flush command to terminate current transaction */ ++ writel_relaxed(0x0, ++ adev->regs + ADM_CH_FLUSH_STATE0(achan->id, adev->ee)); ++ ++ spin_unlock_irqrestore(&achan->vc.lock, flags); ++ ++ vchan_dma_desc_free_list(&achan->vc, &head); ++ ++ return 0; ++} ++ ++static int adm_slave_config(struct dma_chan *chan, struct dma_slave_config *cfg) ++{ ++ struct adm_chan *achan = to_adm_chan(chan); ++ unsigned long flag; ++ ++ spin_lock_irqsave(&achan->vc.lock, flag); ++ memcpy(&achan->slave, cfg, sizeof(struct dma_slave_config)); ++ spin_unlock_irqrestore(&achan->vc.lock, flag); ++ ++ return 0; ++} ++ ++/** ++ * adm_start_dma - start next transaction ++ * @achan - ADM dma channel ++ */ ++static void adm_start_dma(struct adm_chan *achan) ++{ ++ struct virt_dma_desc *vd = vchan_next_desc(&achan->vc); ++ struct adm_device *adev = achan->adev; ++ struct adm_async_desc *async_desc; ++ ++ lockdep_assert_held(&achan->vc.lock); ++ ++ if (!vd) ++ return; ++ ++ list_del(&vd->node); ++ ++ /* write next command list out to the CMD FIFO */ ++ async_desc = container_of(vd, struct adm_async_desc, vd); ++ achan->curr_txd = async_desc; ++ ++ /* reset channel error */ ++ achan->error = 0; ++ ++ if (!achan->initialized) { ++ /* enable interrupts */ ++ writel(ADM_CH_CONF_SHADOW_EN | ++ ADM_CH_CONF_PERM_MPU_CONF | ++ ADM_CH_CONF_MPU_DISABLE | ++ ADM_CH_CONF_SEC_DOMAIN(adev->ee), ++ adev->regs + ADM_CH_CONF(achan->id)); ++ ++ writel(ADM_CH_RSLT_CONF_IRQ_EN | ADM_CH_RSLT_CONF_FLUSH_EN, ++ adev->regs + ADM_CH_RSLT_CONF(achan->id, adev->ee)); ++ ++ achan->initialized = 1; ++ } ++ ++ /* set the crci block size if this transaction requires CRCI */ ++ if (async_desc->crci) { ++ writel(async_desc->mux | async_desc->blk_size, ++ adev->regs + ADM_CRCI_CTL(async_desc->crci, adev->ee)); ++ } ++ ++ /* make sure IRQ enable doesn't get reordered */ ++ wmb(); ++ ++ /* write next command list out to the CMD FIFO */ ++ writel(ALIGN(async_desc->dma_addr, ADM_DESC_ALIGN) >> 3, ++ adev->regs + ADM_CH_CMD_PTR(achan->id, adev->ee)); ++} ++ ++/** ++ * adm_dma_irq - irq handler for ADM controller ++ * @irq: IRQ of interrupt ++ * @data: callback data ++ * ++ * IRQ handler for the bam controller ++ */ ++static irqreturn_t adm_dma_irq(int irq, void *data) ++{ ++ struct adm_device *adev = data; ++ u32 srcs, i; ++ struct adm_async_desc *async_desc; ++ unsigned long flags; ++ ++ srcs = readl_relaxed(adev->regs + ++ ADM_SEC_DOMAIN_IRQ_STATUS(adev->ee)); ++ ++ for (i = 0; i < ADM_MAX_CHANNELS; i++) { ++ struct adm_chan *achan = &adev->channels[i]; ++ u32 status, result; ++ ++ if (srcs & BIT(i)) { ++ status = readl_relaxed(adev->regs + ++ ADM_CH_STATUS_SD(i, adev->ee)); ++ ++ /* if no result present, skip */ ++ if (!(status & ADM_CH_STATUS_VALID)) ++ continue; ++ ++ result = readl_relaxed(adev->regs + ++ ADM_CH_RSLT(i, adev->ee)); ++ ++ /* no valid results, skip */ ++ if (!(result & ADM_CH_RSLT_VALID)) ++ continue; ++ ++ /* flag error if transaction was flushed or failed */ ++ if (result & (ADM_CH_RSLT_ERR | ADM_CH_RSLT_FLUSH)) ++ achan->error = 1; ++ ++ spin_lock_irqsave(&achan->vc.lock, flags); ++ async_desc = achan->curr_txd; ++ ++ achan->curr_txd = NULL; ++ ++ if (async_desc) { ++ vchan_cookie_complete(&async_desc->vd); ++ ++ /* kick off next DMA */ ++ adm_start_dma(achan); ++ } ++ ++ spin_unlock_irqrestore(&achan->vc.lock, flags); ++ } ++ } ++ ++ return IRQ_HANDLED; ++} ++ ++/** ++ * adm_tx_status - returns status of transaction ++ * @chan: dma channel ++ * @cookie: transaction cookie ++ * @txstate: DMA transaction state ++ * ++ * Return status of dma transaction ++ */ ++static enum dma_status adm_tx_status(struct dma_chan *chan, dma_cookie_t cookie, ++ struct dma_tx_state *txstate) ++{ ++ struct adm_chan *achan = to_adm_chan(chan); ++ struct virt_dma_desc *vd; ++ enum dma_status ret; ++ unsigned long flags; ++ size_t residue = 0; ++ ++ ret = dma_cookie_status(chan, cookie, txstate); ++ if (ret == DMA_COMPLETE || !txstate) ++ return ret; ++ ++ spin_lock_irqsave(&achan->vc.lock, flags); ++ ++ vd = vchan_find_desc(&achan->vc, cookie); ++ if (vd) ++ residue = container_of(vd, struct adm_async_desc, vd)->length; ++ ++ spin_unlock_irqrestore(&achan->vc.lock, flags); ++ ++ /* ++ * residue is either the full length if it is in the issued list, or 0 ++ * if it is in progress. We have no reliable way of determining ++ * anything inbetween ++ */ ++ dma_set_residue(txstate, residue); ++ ++ if (achan->error) ++ return DMA_ERROR; ++ ++ return ret; ++} ++ ++/** ++ * adm_issue_pending - starts pending transactions ++ * @chan: dma channel ++ * ++ * Issues all pending transactions and starts DMA ++ */ ++static void adm_issue_pending(struct dma_chan *chan) ++{ ++ struct adm_chan *achan = to_adm_chan(chan); ++ unsigned long flags; ++ ++ spin_lock_irqsave(&achan->vc.lock, flags); ++ ++ if (vchan_issue_pending(&achan->vc) && !achan->curr_txd) ++ adm_start_dma(achan); ++ spin_unlock_irqrestore(&achan->vc.lock, flags); ++} ++ ++/** ++ * adm_dma_free_desc - free descriptor memory ++ * @vd: virtual descriptor ++ * ++ */ ++static void adm_dma_free_desc(struct virt_dma_desc *vd) ++{ ++ struct adm_async_desc *async_desc = container_of(vd, ++ struct adm_async_desc, vd); ++ ++ dma_free_writecombine(async_desc->adev->dev, async_desc->dma_len, ++ async_desc->cpl, async_desc->dma_addr); ++ kfree(async_desc); ++} ++ ++static void adm_channel_init(struct adm_device *adev, struct adm_chan *achan, ++ u32 index) ++{ ++ achan->id = index; ++ achan->adev = adev; ++ ++ vchan_init(&achan->vc, &adev->common); ++ achan->vc.desc_free = adm_dma_free_desc; ++} ++ ++static int adm_dma_probe(struct platform_device *pdev) ++{ ++ struct adm_device *adev; ++ struct resource *iores; ++ int ret; ++ u32 i; ++ ++ adev = devm_kzalloc(&pdev->dev, sizeof(*adev), GFP_KERNEL); ++ if (!adev) ++ return -ENOMEM; ++ ++ adev->dev = &pdev->dev; ++ ++ iores = platform_get_resource(pdev, IORESOURCE_MEM, 0); ++ adev->regs = devm_ioremap_resource(&pdev->dev, iores); ++ if (IS_ERR(adev->regs)) ++ return PTR_ERR(adev->regs); ++ ++ adev->irq = platform_get_irq(pdev, 0); ++ if (adev->irq < 0) ++ return adev->irq; ++ ++ ret = of_property_read_u32(pdev->dev.of_node, "qcom,ee", &adev->ee); ++ if (ret) { ++ dev_err(adev->dev, "Execution environment unspecified\n"); ++ return ret; ++ } ++ ++ adev->core_clk = devm_clk_get(adev->dev, "core"); ++ if (IS_ERR(adev->core_clk)) ++ return PTR_ERR(adev->core_clk); ++ ++ ret = clk_prepare_enable(adev->core_clk); ++ if (ret) { ++ dev_err(adev->dev, "failed to prepare/enable core clock\n"); ++ return ret; ++ } ++ ++ adev->iface_clk = devm_clk_get(adev->dev, "iface"); ++ if (IS_ERR(adev->iface_clk)) { ++ ret = PTR_ERR(adev->iface_clk); ++ goto err_disable_core_clk; ++ } ++ ++ ret = clk_prepare_enable(adev->iface_clk); ++ if (ret) { ++ dev_err(adev->dev, "failed to prepare/enable iface clock\n"); ++ goto err_disable_core_clk; ++ } ++ ++ adev->clk_reset = devm_reset_control_get(&pdev->dev, "clk"); ++ if (IS_ERR(adev->clk_reset)) { ++ dev_err(adev->dev, "failed to get ADM0 reset\n"); ++ ret = PTR_ERR(adev->clk_reset); ++ goto err_disable_clks; ++ } ++ ++ adev->c0_reset = devm_reset_control_get(&pdev->dev, "c0"); ++ if (IS_ERR(adev->c0_reset)) { ++ dev_err(adev->dev, "failed to get ADM0 C0 reset\n"); ++ ret = PTR_ERR(adev->c0_reset); ++ goto err_disable_clks; ++ } ++ ++ adev->c1_reset = devm_reset_control_get(&pdev->dev, "c1"); ++ if (IS_ERR(adev->c1_reset)) { ++ dev_err(adev->dev, "failed to get ADM0 C1 reset\n"); ++ ret = PTR_ERR(adev->c1_reset); ++ goto err_disable_clks; ++ } ++ ++ adev->c2_reset = devm_reset_control_get(&pdev->dev, "c2"); ++ if (IS_ERR(adev->c2_reset)) { ++ dev_err(adev->dev, "failed to get ADM0 C2 reset\n"); ++ ret = PTR_ERR(adev->c2_reset); ++ goto err_disable_clks; ++ } ++ ++ reset_control_assert(adev->clk_reset); ++ reset_control_assert(adev->c0_reset); ++ reset_control_assert(adev->c1_reset); ++ reset_control_assert(adev->c2_reset); ++ ++ reset_control_deassert(adev->clk_reset); ++ reset_control_deassert(adev->c0_reset); ++ reset_control_deassert(adev->c1_reset); ++ reset_control_deassert(adev->c2_reset); ++ ++ adev->channels = devm_kcalloc(adev->dev, ADM_MAX_CHANNELS, ++ sizeof(*adev->channels), GFP_KERNEL); ++ ++ if (!adev->channels) { ++ ret = -ENOMEM; ++ goto err_disable_clks; ++ } ++ ++ /* allocate and initialize channels */ ++ INIT_LIST_HEAD(&adev->common.channels); ++ ++ for (i = 0; i < ADM_MAX_CHANNELS; i++) ++ adm_channel_init(adev, &adev->channels[i], i); ++ ++ /* reset CRCIs */ ++ for (i = 0; i < 16; i++) ++ writel(ADM_CRCI_CTL_RST, adev->regs + ++ ADM_CRCI_CTL(i, adev->ee)); ++ ++ /* configure client interfaces */ ++ writel(ADM_CI_RANGE_START(0x40) | ADM_CI_RANGE_END(0xb0) | ++ ADM_CI_BURST_8_WORDS, adev->regs + ADM_CI_CONF(0)); ++ writel(ADM_CI_RANGE_START(0x2a) | ADM_CI_RANGE_END(0x2c) | ++ ADM_CI_BURST_8_WORDS, adev->regs + ADM_CI_CONF(1)); ++ writel(ADM_CI_RANGE_START(0x12) | ADM_CI_RANGE_END(0x28) | ++ ADM_CI_BURST_8_WORDS, adev->regs + ADM_CI_CONF(2)); ++ writel(ADM_GP_CTL_LP_EN | ADM_GP_CTL_LP_CNT(0xf), ++ adev->regs + ADM_GP_CTL); ++ ++ ret = devm_request_irq(adev->dev, adev->irq, adm_dma_irq, ++ 0, "adm_dma", adev); ++ if (ret) ++ goto err_disable_clks; ++ ++ platform_set_drvdata(pdev, adev); ++ ++ adev->common.dev = adev->dev; ++ adev->common.dev->dma_parms = &adev->dma_parms; ++ ++ /* set capabilities */ ++ dma_cap_zero(adev->common.cap_mask); ++ dma_cap_set(DMA_SLAVE, adev->common.cap_mask); ++ dma_cap_set(DMA_PRIVATE, adev->common.cap_mask); ++ ++ /* initialize dmaengine apis */ ++ adev->common.directions = BIT(DMA_DEV_TO_MEM | DMA_MEM_TO_DEV); ++ adev->common.residue_granularity = DMA_RESIDUE_GRANULARITY_DESCRIPTOR; ++ adev->common.src_addr_widths = DMA_SLAVE_BUSWIDTH_4_BYTES; ++ adev->common.dst_addr_widths = DMA_SLAVE_BUSWIDTH_4_BYTES; ++ adev->common.device_free_chan_resources = adm_free_chan; ++ adev->common.device_prep_slave_sg = adm_prep_slave_sg; ++ adev->common.device_issue_pending = adm_issue_pending; ++ adev->common.device_tx_status = adm_tx_status; ++ adev->common.device_terminate_all = adm_terminate_all; ++ adev->common.device_config = adm_slave_config; ++ ++ ret = dma_async_device_register(&adev->common); ++ if (ret) { ++ dev_err(adev->dev, "failed to register dma async device\n"); ++ goto err_disable_clks; ++ } ++ ++ ret = of_dma_controller_register(pdev->dev.of_node, ++ of_dma_xlate_by_chan_id, ++ &adev->common); ++ if (ret) ++ goto err_unregister_dma; ++ ++ return 0; ++ ++err_unregister_dma: ++ dma_async_device_unregister(&adev->common); ++err_disable_clks: ++ clk_disable_unprepare(adev->iface_clk); ++err_disable_core_clk: ++ clk_disable_unprepare(adev->core_clk); ++ ++ return ret; ++} ++ ++static int adm_dma_remove(struct platform_device *pdev) ++{ ++ struct adm_device *adev = platform_get_drvdata(pdev); ++ struct adm_chan *achan; ++ u32 i; ++ ++ of_dma_controller_free(pdev->dev.of_node); ++ dma_async_device_unregister(&adev->common); ++ ++ for (i = 0; i < ADM_MAX_CHANNELS; i++) { ++ achan = &adev->channels[i]; ++ ++ /* mask IRQs for this channel/EE pair */ ++ writel(0, adev->regs + ADM_CH_RSLT_CONF(achan->id, adev->ee)); ++ ++ adm_terminate_all(&adev->channels[i].vc.chan); ++ } ++ ++ devm_free_irq(adev->dev, adev->irq, adev); ++ ++ clk_disable_unprepare(adev->core_clk); ++ clk_disable_unprepare(adev->iface_clk); ++ ++ return 0; ++} ++ ++static const struct of_device_id adm_of_match[] = { ++ { .compatible = "qcom,adm", }, ++ {} ++}; ++MODULE_DEVICE_TABLE(of, adm_of_match); ++ ++static struct platform_driver adm_dma_driver = { ++ .probe = adm_dma_probe, ++ .remove = adm_dma_remove, ++ .driver = { ++ .name = "adm-dma-engine", ++ .of_match_table = adm_of_match, ++ }, ++}; ++ ++module_platform_driver(adm_dma_driver); ++ ++MODULE_AUTHOR("Andy Gross "); ++MODULE_DESCRIPTION("QCOM ADM DMA engine driver"); ++MODULE_LICENSE("GPL v2"); +--- a/drivers/dma/Makefile ++++ b/drivers/dma/Makefile +@@ -65,5 +65,6 @@ + obj-$(CONFIG_TI_EDMA) += edma.o + obj-$(CONFIG_XGENE_DMA) += xgene-dma.o + obj-$(CONFIG_ZX_DMA) += zx296702_dma.o ++obj-$(CONFIG_QCOM_ADM) += qcom_adm.o + + obj-y += xilinx/ diff --git a/target/linux/ipq806x/patches-4.4/157-ARM-DT-ipq8064-Add-ADM-device-node.patch b/target/linux/ipq806x/patches-4.4/157-ARM-DT-ipq8064-Add-ADM-device-node.patch new file mode 100644 index 0000000..b8abd0a --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/157-ARM-DT-ipq8064-Add-ADM-device-node.patch @@ -0,0 +1,42 @@ +From 1fb18acab2d71e7e4efd9c10492edb1baf84dcc0 Mon Sep 17 00:00:00 2001 +From: Andy Gross +Date: Wed, 20 May 2015 15:41:07 +0530 +Subject: [PATCH] ARM: DT: ipq8064: Add ADM device node + +This patch adds support for the ADM DMA on the IPQ8064 SOC + +Signed-off-by: Andy Gross +--- + arch/arm/boot/dts/qcom-ipq8064-ap148.dts | 4 ++++ + arch/arm/boot/dts/qcom-ipq8064.dtsi | 21 +++++++++++++++++++++ + 2 files changed, 25 insertions(+) + +--- a/arch/arm/boot/dts/qcom-ipq8064.dtsi ++++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi +@@ -727,6 +727,26 @@ + + status = "disabled"; + }; ++ ++ adm_dma: dma at 18300000 { ++ compatible = "qcom,adm"; ++ reg = <0x18300000 0x100000>; ++ interrupts = <0 170 0>; ++ #dma-cells = <1>; ++ ++ clocks = <&gcc ADM0_CLK>, <&gcc ADM0_PBUS_CLK>; ++ clock-names = "core", "iface"; ++ ++ resets = <&gcc ADM0_RESET>, ++ <&gcc ADM0_PBUS_RESET>, ++ <&gcc ADM0_C0_RESET>, ++ <&gcc ADM0_C1_RESET>, ++ <&gcc ADM0_C2_RESET>; ++ reset-names = "clk", "pbus", "c0", "c1", "c2"; ++ qcom,ee = <0>; ++ ++ status = "disabled"; ++ }; + }; + + sfpb_mutex: sfpb-mutex { diff --git a/target/linux/ipq806x/patches-4.4/161-mtd-nand-Create-a-BBT-flag-to-access-bad-block-markers-in-raw-mode.patch b/target/linux/ipq806x/patches-4.4/161-mtd-nand-Create-a-BBT-flag-to-access-bad-block-markers-in-raw-mode.patch new file mode 100644 index 0000000..21fe405 --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/161-mtd-nand-Create-a-BBT-flag-to-access-bad-block-markers-in-raw-mode.patch @@ -0,0 +1,83 @@ +Content-Type: text/plain; charset="utf-8" +MIME-Version: 1.0 +Content-Transfer-Encoding: 7bit +Subject: [v3, + 1/5] mtd: nand: Create a BBT flag to access bad block markers in raw + mode +From: Archit Taneja +X-Patchwork-Id: 6927081 +Message-Id: <1438578498-32254-2-git-send-email-architt at codeaurora.org> +To: linux-mtd at lists.infradead.org, dehrenberg at google.com, + cernekee at gmail.com, computersforpeace at gmail.com +Cc: linux-arm-msm at vger.kernel.org, agross at codeaurora.org, + sboyd at codeaurora.org, linux-kernel at vger.kernel.org, + Archit Taneja +Date: Mon, 3 Aug 2015 10:38:14 +0530 + +Some controllers can access the factory bad block marker from OOB only +when they read it in raw mode. When ECC is enabled, these controllers +discard reading/writing bad block markers, preventing access to them +altogether. + +The bbt driver assumes MTD_OPS_PLACE_OOB when scanning for bad blocks. +This results in the nand driver's ecc->read_oob() op to be called, which +works with ECC enabled. + +Create a new BBT option flag that tells nand_bbt to force the mode to +MTD_OPS_RAW. This would result in the correct op being called for the +underlying nand controller driver. + +Reviewed-by: Andy Gross +Signed-off-by: Archit Taneja + +--- +drivers/mtd/nand/nand_base.c | 6 +++++- + drivers/mtd/nand/nand_bbt.c | 6 +++++- + include/linux/mtd/bbm.h | 7 +++++++ + 3 files changed, 17 insertions(+), 2 deletions(-) + +--- a/drivers/mtd/nand/nand_base.c ++++ b/drivers/mtd/nand/nand_base.c +@@ -394,7 +394,11 @@ + } else { + ops.len = ops.ooblen = 1; + } +- ops.mode = MTD_OPS_PLACE_OOB; ++ ++ if (unlikely(chip->bbt_options & NAND_BBT_ACCESS_BBM_RAW)) ++ ops.mode = MTD_OPS_RAW; ++ else ++ ops.mode = MTD_OPS_PLACE_OOB; + + /* Write to first/last page(s) if necessary */ + if (chip->bbt_options & NAND_BBT_SCANLASTPAGE) +--- a/drivers/mtd/nand/nand_bbt.c ++++ b/drivers/mtd/nand/nand_bbt.c +@@ -420,7 +420,11 @@ + ops.oobbuf = buf; + ops.ooboffs = 0; + ops.datbuf = NULL; +- ops.mode = MTD_OPS_PLACE_OOB; ++ ++ if (unlikely(bd->options & NAND_BBT_ACCESS_BBM_RAW)) ++ ops.mode = MTD_OPS_RAW; ++ else ++ ops.mode = MTD_OPS_PLACE_OOB; + + for (j = 0; j < numpages; j++) { + /* +--- a/include/linux/mtd/bbm.h ++++ b/include/linux/mtd/bbm.h +@@ -116,6 +116,12 @@ + #define NAND_BBT_NO_OOB_BBM 0x00080000 + + /* ++ * Force MTD_OPS_RAW mode when trying to access bad block markes from OOB. To ++ * be used by controllers which can access BBM only when ECC is disabled, i.e, ++ * when in RAW access mode ++ */ ++#define NAND_BBT_ACCESS_BBM_RAW 0x00100000 ++/* + * Flag set by nand_create_default_bbt_descr(), marking that the nand_bbt_descr + * was allocated dynamicaly and must be freed in nand_release(). Has no meaning + * in nand_chip.bbt_options. diff --git a/target/linux/ipq806x/patches-4.4/162-mtd-nand-Qualcomm-NAND-controller-driver.patch b/target/linux/ipq806x/patches-4.4/162-mtd-nand-Qualcomm-NAND-controller-driver.patch new file mode 100644 index 0000000..19e5f91 --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/162-mtd-nand-Qualcomm-NAND-controller-driver.patch @@ -0,0 +1,2024 @@ +Content-Type: text/plain; charset="utf-8" +MIME-Version: 1.0 +Content-Transfer-Encoding: 7bit +Subject: [v3,2/5] mtd: nand: Qualcomm NAND controller driver +From: Archit Taneja +X-Patchwork-Id: 6927101 +Message-Id: <1438578498-32254-3-git-send-email-architt at codeaurora.org> +To: linux-mtd at lists.infradead.org, dehrenberg at google.com, + cernekee at gmail.com, computersforpeace at gmail.com +Cc: linux-arm-msm at vger.kernel.org, agross at codeaurora.org, + sboyd at codeaurora.org, linux-kernel at vger.kernel.org, + Archit Taneja +Date: Mon, 3 Aug 2015 10:38:15 +0530 + +The Qualcomm NAND controller is found in SoCs like IPQ806x, MSM7xx, +MDM9x15 series. + +It exists as a sub block inside the IPs EBI2 (External Bus Interface 2) +and QPIC (Qualcomm Parallel Interface Controller). These IPs provide a +broader interface for external slow peripheral devices such as LCD and +NAND/NOR flash memory or SRAM like interfaces. + +We add support for the NAND controller found within EBI2. For the SoCs +of our interest, we only use the NAND controller within EBI2. Therefore, +it's safe for us to assume that the NAND controller is a standalone block +within the SoC. + +The controller supports 512B, 2kB, 4kB and 8kB page 8-bit and 16-bit NAND +flash devices. It contains a HW ECC block that supports BCH ECC (4, 8 and +16 bit correction/step) and RS ECC(4 bit correction/step) that covers main +and spare data. The controller contains an internal 512 byte page buffer +to which we read/write via DMA. The EBI2 type NAND controller uses ADM DMA +for register read/write and data transfers. The controller performs page +reads and writes at a codeword/step level of 512 bytes. It can support up +to 2 external chips of different configurations. + +The driver prepares register read and write configuration descriptors for +each codeword, followed by data descriptors to read or write data from the +controller's internal buffer. It uses a single ADM DMA channel that we get +via dmaengine API. The controller requires 2 ADM CRCIs for command and +data flow control. These are passed via DT. + +The ecc layout used by the controller is syndrome like, but we can't use +the standard syndrome ecc ops because of several reasons. First, the amount +of data bytes covered by ecc isn't same in each step. Second, writing to +free oob space requires us writing to the entire step in which the oob +lies. This forces us to create our own ecc ops. + +One more difference is how the controller accesses the bad block marker. +The controller ignores reading the marker when ECC is enabled. ECC needs +to be explicity disabled to read or write to the bad block marker. For +this reason, we use the newly created flag NAND_BBT_ACCESS_BBM_RAW to +read the factory provided bad block markers. + +v3: +- Refactor dma functions for maximum reuse +- Use dma_slave_confing on stack +- optimize and clean upempty_page_fixup using memchr_inv +- ensure portability with dma register reads using le32_* funcs +- use NAND_USE_BOUNCE_BUFFER instead of doing it ourselves +- fix handling of return values of dmaengine funcs +- constify wherever possible +- Remove dependency on ADM DMA in Kconfig +- Misc fixes and clean ups + +v2: +- Use new BBT flag that allows us to read BBM in raw mode +- reduce memcpy-s in the driver +- some refactor and clean ups because of above changes + +Reviewed-by: Andy Gross +Signed-off-by: Archit Taneja + +--- +drivers/mtd/nand/Kconfig | 7 + + drivers/mtd/nand/Makefile | 1 + + drivers/mtd/nand/qcom_nandc.c | 1913 +++++++++++++++++++++++++++++++++++++++++ + 3 files changed, 1921 insertions(+) + create mode 100644 drivers/mtd/nand/qcom_nandc.c + +--- a/drivers/mtd/nand/Kconfig ++++ b/drivers/mtd/nand/Kconfig +@@ -546,4 +546,11 @@ + help + Enables support for NAND controller on Hisilicon SoC Hip04. + ++config MTD_NAND_QCOM ++ tristate "Support for NAND on QCOM SoCs" ++ depends on ARCH_QCOM ++ help ++ Enables support for NAND flash chips on SoCs containing the EBI2 NAND ++ controller. This controller is found on IPQ806x SoC. ++ + endif # MTD_NAND +--- /dev/null ++++ b/drivers/mtd/nand/qcom_nandc.c +@@ -0,0 +1,1918 @@ ++/* ++ * Copyright (c) 2015, The Linux Foundation. All rights reserved. ++ * ++ * This software is licensed under the terms of the GNU General Public ++ * License version 2, as published by the Free Software Foundation, and ++ * may be copied, distributed, and modified under those terms. ++ * ++ * 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. ++ */ ++ ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++ ++/* NANDc reg offsets */ ++#define NAND_FLASH_CMD 0x00 ++#define NAND_ADDR0 0x04 ++#define NAND_ADDR1 0x08 ++#define NAND_FLASH_CHIP_SELECT 0x0c ++#define NAND_EXEC_CMD 0x10 ++#define NAND_FLASH_STATUS 0x14 ++#define NAND_BUFFER_STATUS 0x18 ++#define NAND_DEV0_CFG0 0x20 ++#define NAND_DEV0_CFG1 0x24 ++#define NAND_DEV0_ECC_CFG 0x28 ++#define NAND_DEV1_ECC_CFG 0x2c ++#define NAND_DEV1_CFG0 0x30 ++#define NAND_DEV1_CFG1 0x34 ++#define NAND_READ_ID 0x40 ++#define NAND_READ_STATUS 0x44 ++#define NAND_DEV_CMD0 0xa0 ++#define NAND_DEV_CMD1 0xa4 ++#define NAND_DEV_CMD2 0xa8 ++#define NAND_DEV_CMD_VLD 0xac ++#define SFLASHC_BURST_CFG 0xe0 ++#define NAND_ERASED_CW_DETECT_CFG 0xe8 ++#define NAND_ERASED_CW_DETECT_STATUS 0xec ++#define NAND_EBI2_ECC_BUF_CFG 0xf0 ++#define FLASH_BUF_ACC 0x100 ++ ++#define NAND_CTRL 0xf00 ++#define NAND_VERSION 0xf08 ++#define NAND_READ_LOCATION_0 0xf20 ++#define NAND_READ_LOCATION_1 0xf24 ++ ++/* dummy register offsets, used by write_reg_dma */ ++#define NAND_DEV_CMD1_RESTORE 0xdead ++#define NAND_DEV_CMD_VLD_RESTORE 0xbeef ++ ++/* NAND_FLASH_CMD bits */ ++#define PAGE_ACC BIT(4) ++#define LAST_PAGE BIT(5) ++ ++/* NAND_FLASH_CHIP_SELECT bits */ ++#define NAND_DEV_SEL 0 ++#define DM_EN BIT(2) ++ ++/* NAND_FLASH_STATUS bits */ ++#define FS_OP_ERR BIT(4) ++#define FS_READY_BSY_N BIT(5) ++#define FS_MPU_ERR BIT(8) ++#define FS_DEVICE_STS_ERR BIT(16) ++#define FS_DEVICE_WP BIT(23) ++ ++/* NAND_BUFFER_STATUS bits */ ++#define BS_UNCORRECTABLE_BIT BIT(8) ++#define BS_CORRECTABLE_ERR_MSK 0x1f ++ ++/* NAND_DEVn_CFG0 bits */ ++#define DISABLE_STATUS_AFTER_WRITE 4 ++#define CW_PER_PAGE 6 ++#define UD_SIZE_BYTES 9 ++#define ECC_PARITY_SIZE_BYTES_RS 19 ++#define SPARE_SIZE_BYTES 23 ++#define NUM_ADDR_CYCLES 27 ++#define STATUS_BFR_READ 30 ++#define SET_RD_MODE_AFTER_STATUS 31 ++ ++/* NAND_DEVn_CFG0 bits */ ++#define DEV0_CFG1_ECC_DISABLE 0 ++#define WIDE_FLASH 1 ++#define NAND_RECOVERY_CYCLES 2 ++#define CS_ACTIVE_BSY 5 ++#define BAD_BLOCK_BYTE_NUM 6 ++#define BAD_BLOCK_IN_SPARE_AREA 16 ++#define WR_RD_BSY_GAP 17 ++#define ENABLE_BCH_ECC 27 ++ ++/* NAND_DEV0_ECC_CFG bits */ ++#define ECC_CFG_ECC_DISABLE 0 ++#define ECC_SW_RESET 1 ++#define ECC_MODE 4 ++#define ECC_PARITY_SIZE_BYTES_BCH 8 ++#define ECC_NUM_DATA_BYTES 16 ++#define ECC_FORCE_CLK_OPEN 30 ++ ++/* NAND_DEV_CMD1 bits */ ++#define READ_ADDR 0 ++ ++/* NAND_DEV_CMD_VLD bits */ ++#define READ_START_VLD 0 ++ ++/* NAND_EBI2_ECC_BUF_CFG bits */ ++#define NUM_STEPS 0 ++ ++/* NAND_ERASED_CW_DETECT_CFG bits */ ++#define ERASED_CW_ECC_MASK 1 ++#define AUTO_DETECT_RES 0 ++#define MASK_ECC (1 << ERASED_CW_ECC_MASK) ++#define RESET_ERASED_DET (1 << AUTO_DETECT_RES) ++#define ACTIVE_ERASED_DET (0 << AUTO_DETECT_RES) ++#define CLR_ERASED_PAGE_DET (RESET_ERASED_DET | MASK_ECC) ++#define SET_ERASED_PAGE_DET (ACTIVE_ERASED_DET | MASK_ECC) ++ ++/* NAND_ERASED_CW_DETECT_STATUS bits */ ++#define PAGE_ALL_ERASED BIT(7) ++#define CODEWORD_ALL_ERASED BIT(6) ++#define PAGE_ERASED BIT(5) ++#define CODEWORD_ERASED BIT(4) ++#define ERASED_PAGE (PAGE_ALL_ERASED | PAGE_ERASED) ++#define ERASED_CW (CODEWORD_ALL_ERASED | CODEWORD_ERASED) ++ ++/* Version Mask */ ++#define NAND_VERSION_MAJOR_MASK 0xf0000000 ++#define NAND_VERSION_MAJOR_SHIFT 28 ++#define NAND_VERSION_MINOR_MASK 0x0fff0000 ++#define NAND_VERSION_MINOR_SHIFT 16 ++ ++/* NAND OP_CMDs */ ++#define PAGE_READ 0x2 ++#define PAGE_READ_WITH_ECC 0x3 ++#define PAGE_READ_WITH_ECC_SPARE 0x4 ++#define PROGRAM_PAGE 0x6 ++#define PAGE_PROGRAM_WITH_ECC 0x7 ++#define PROGRAM_PAGE_SPARE 0x9 ++#define BLOCK_ERASE 0xa ++#define FETCH_ID 0xb ++#define RESET_DEVICE 0xd ++ ++/* ++ * the NAND controller performs reads/writes with ECC in 516 byte chunks. ++ * the driver calls the chunks 'step' or 'codeword' interchangeably ++ */ ++#define NANDC_STEP_SIZE 512 ++ ++/* ++ * the largest page size we support is 8K, this will have 16 steps/codewords ++ * of 512 bytes each ++ */ ++#define MAX_NUM_STEPS (SZ_8K / NANDC_STEP_SIZE) ++ ++/* we read at most 3 registers per codeword scan */ ++#define MAX_REG_RD (3 * MAX_NUM_STEPS) ++ ++/* ECC modes */ ++#define ECC_NONE BIT(0) ++#define ECC_RS_4BIT BIT(1) ++#define ECC_BCH_4BIT BIT(2) ++#define ECC_BCH_8BIT BIT(3) ++ ++struct desc_info { ++ struct list_head list; ++ ++ enum dma_transfer_direction dir; ++ struct scatterlist sgl; ++ struct dma_async_tx_descriptor *dma_desc; ++}; ++ ++/* ++ * holds the current register values that we want to write. acts as a contiguous ++ * chunk of memory which we use to write the controller registers through DMA. ++ */ ++struct nandc_regs { ++ u32 cmd; ++ u32 addr0; ++ u32 addr1; ++ u32 chip_sel; ++ u32 exec; ++ ++ u32 cfg0; ++ u32 cfg1; ++ u32 ecc_bch_cfg; ++ ++ u32 clrflashstatus; ++ u32 clrreadstatus; ++ ++ u32 cmd1; ++ u32 vld; ++ ++ u32 orig_cmd1; ++ u32 orig_vld; ++ ++ u32 ecc_buf_cfg; ++}; ++ ++/* ++ * @cmd_crci: ADM DMA CRCI for command flow control ++ * @data_crci: ADM DMA CRCI for data flow control ++ * @list: DMA descriptor list (list of desc_infos) ++ * @dma_done: completion param to denote end of last ++ * descriptor in the list ++ * @data_buffer: our local DMA buffer for page read/writes, ++ * used when we can't use the buffer provided ++ * by upper layers directly ++ * @buf_size/count/start: markers for chip->read_buf/write_buf functions ++ * @reg_read_buf: buffer for reading register data via DMA ++ * @reg_read_pos: marker for data read in reg_read_buf ++ * @cfg0, cfg1, cfg0_raw..: NANDc register configurations needed for ++ * ecc/non-ecc mode for the current nand flash ++ * device ++ * @regs: a contiguous chunk of memory for DMA register ++ * writes ++ * @ecc_strength: 4 bit or 8 bit ecc, received via DT ++ * @bus_width: 8 bit or 16 bit NAND bus width, received via DT ++ * @ecc_modes: supported ECC modes by the current controller, ++ * initialized via DT match data ++ * @cw_size: the number of bytes in a single step/codeword ++ * of a page, consisting of all data, ecc, spare ++ * and reserved bytes ++ * @cw_data: the number of bytes within a codeword protected ++ * by ECC ++ * @bch_enabled: flag to tell whether BCH or RS ECC mode is used ++ * @status: value to be returned if NAND_CMD_STATUS command ++ * is executed ++ */ ++struct qcom_nandc_data { ++ struct platform_device *pdev; ++ struct device *dev; ++ ++ void __iomem *base; ++ struct resource *res; ++ ++ struct clk *core_clk; ++ struct clk *aon_clk; ++ ++ /* DMA stuff */ ++ struct dma_chan *chan; ++ struct dma_slave_config slave_conf; ++ unsigned int cmd_crci; ++ unsigned int data_crci; ++ struct list_head list; ++ struct completion dma_done; ++ ++ /* MTD stuff */ ++ struct nand_chip chip; ++ struct mtd_info mtd; ++ ++ /* local data buffer and markers */ ++ u8 *data_buffer; ++ int buf_size; ++ int buf_count; ++ int buf_start; ++ ++ /* local buffer to read back registers */ ++ u32 *reg_read_buf; ++ int reg_read_pos; ++ ++ /* required configs */ ++ u32 cfg0, cfg1; ++ u32 cfg0_raw, cfg1_raw; ++ u32 ecc_buf_cfg; ++ u32 ecc_bch_cfg; ++ u32 clrflashstatus; ++ u32 clrreadstatus; ++ u32 sflashc_burst_cfg; ++ u32 cmd1, vld; ++ ++ /* register state */ ++ struct nandc_regs *regs; ++ ++ /* things we get from DT */ ++ int ecc_strength; ++ int bus_width; ++ ++ u32 ecc_modes; ++ ++ /* misc params */ ++ int cw_size; ++ int cw_data; ++ bool use_ecc; ++ bool bch_enabled; ++ u8 status; ++ int last_command; ++}; ++ ++static inline u32 nandc_read(struct qcom_nandc_data *this, int offset) ++{ ++ return ioread32(this->base + offset); ++} ++ ++static inline void nandc_write(struct qcom_nandc_data *this, int offset, ++ u32 val) ++{ ++ iowrite32(val, this->base + offset); ++} ++ ++/* helper to configure address register values */ ++static void set_address(struct qcom_nandc_data *this, u16 column, int page) ++{ ++ struct nand_chip *chip = &this->chip; ++ struct nandc_regs *regs = this->regs; ++ ++ if (chip->options & NAND_BUSWIDTH_16) ++ column >>= 1; ++ ++ regs->addr0 = page << 16 | column; ++ regs->addr1 = page >> 16 & 0xff; ++} ++ ++/* ++ * update_rw_regs: set up read/write register values, these will be ++ * written to the NAND controller registers via DMA ++ * ++ * @num_cw: number of steps for the read/write operation ++ * @read: read or write operation ++ */ ++static void update_rw_regs(struct qcom_nandc_data *this, int num_cw, bool read) ++{ ++ struct nandc_regs *regs = this->regs; ++ ++ if (read) { ++ if (this->use_ecc) ++ regs->cmd = PAGE_READ_WITH_ECC | PAGE_ACC | LAST_PAGE; ++ else ++ regs->cmd = PAGE_READ | PAGE_ACC | LAST_PAGE; ++ } else { ++ regs->cmd = PROGRAM_PAGE | PAGE_ACC | LAST_PAGE; ++ } ++ ++ if (this->use_ecc) { ++ regs->cfg0 = (this->cfg0 & ~(7U << CW_PER_PAGE)) | ++ (num_cw - 1) << CW_PER_PAGE; ++ ++ regs->cfg1 = this->cfg1; ++ regs->ecc_bch_cfg = this->ecc_bch_cfg; ++ } else { ++ regs->cfg0 = (this->cfg0_raw & ~(7U << CW_PER_PAGE)) | ++ (num_cw - 1) << CW_PER_PAGE; ++ ++ regs->cfg1 = this->cfg1_raw; ++ regs->ecc_bch_cfg = 1 << ECC_CFG_ECC_DISABLE; ++ } ++ ++ regs->ecc_buf_cfg = this->ecc_buf_cfg; ++ regs->clrflashstatus = this->clrflashstatus; ++ regs->clrreadstatus = this->clrreadstatus; ++ regs->exec = 1; ++} ++ ++static int prep_dma_desc(struct qcom_nandc_data *this, bool read, int reg_off, ++ const void *vaddr, int size, bool flow_control) ++{ ++ struct desc_info *desc; ++ struct dma_async_tx_descriptor *dma_desc; ++ struct scatterlist *sgl; ++ struct dma_slave_config slave_conf; ++ int r; ++ ++ desc = kzalloc(sizeof(*desc), GFP_KERNEL); ++ if (!desc) ++ return -ENOMEM; ++ ++ list_add_tail(&desc->list, &this->list); ++ ++ sgl = &desc->sgl; ++ ++ sg_init_one(sgl, vaddr, size); ++ ++ desc->dir = read ? DMA_DEV_TO_MEM : DMA_MEM_TO_DEV; ++ ++ r = dma_map_sg(this->dev, sgl, 1, desc->dir); ++ if (r == 0) { ++ r = -ENOMEM; ++ goto err; ++ } ++ ++ memset(&slave_conf, 0x00, sizeof(slave_conf)); ++ ++ slave_conf.device_fc = flow_control; ++ if (read) { ++ slave_conf.src_maxburst = 16; ++ slave_conf.src_addr = this->res->start + reg_off; ++ slave_conf.slave_id = this->data_crci; ++ } else { ++ slave_conf.dst_maxburst = 16; ++ slave_conf.dst_addr = this->res->start + reg_off; ++ slave_conf.slave_id = this->cmd_crci; ++ } ++ ++ r = dmaengine_slave_config(this->chan, &slave_conf); ++ if (r) { ++ dev_err(this->dev, "failed to configure dma channel\n"); ++ goto err; ++ } ++ ++ dma_desc = dmaengine_prep_slave_sg(this->chan, sgl, 1, desc->dir, 0); ++ if (!dma_desc) { ++ dev_err(this->dev, "failed to prepare desc\n"); ++ r = -EINVAL; ++ goto err; ++ } ++ ++ desc->dma_desc = dma_desc; ++ ++ return 0; ++err: ++ kfree(desc); ++ ++ return r; ++} ++ ++/* ++ * read_reg_dma: prepares a descriptor to read a given number of ++ * contiguous registers to the reg_read_buf pointer ++ * ++ * @first: offset of the first register in the contiguous block ++ * @num_regs: number of registers to read ++ */ ++static int read_reg_dma(struct qcom_nandc_data *this, int first, int num_regs) ++{ ++ bool flow_control = false; ++ void *vaddr; ++ int size; ++ ++ if (first == NAND_READ_ID || first == NAND_FLASH_STATUS) ++ flow_control = true; ++ ++ size = num_regs * sizeof(u32); ++ vaddr = this->reg_read_buf + this->reg_read_pos; ++ this->reg_read_pos += num_regs; ++ ++ return prep_dma_desc(this, true, first, vaddr, size, flow_control); ++} ++ ++/* ++ * write_reg_dma: prepares a descriptor to write a given number of ++ * contiguous registers ++ * ++ * @first: offset of the first register in the contiguous block ++ * @num_regs: number of registers to write ++ */ ++static int write_reg_dma(struct qcom_nandc_data *this, int first, int num_regs) ++{ ++ bool flow_control = false; ++ struct nandc_regs *regs = this->regs; ++ void *vaddr; ++ int size; ++ ++ switch (first) { ++ case NAND_FLASH_CMD: ++ vaddr = ®s->cmd; ++ flow_control = true; ++ break; ++ case NAND_EXEC_CMD: ++ vaddr = ®s->exec; ++ break; ++ case NAND_FLASH_STATUS: ++ vaddr = ®s->clrflashstatus; ++ break; ++ case NAND_DEV0_CFG0: ++ vaddr = ®s->cfg0; ++ break; ++ case NAND_READ_STATUS: ++ vaddr = ®s->clrreadstatus; ++ break; ++ case NAND_DEV_CMD1: ++ vaddr = ®s->cmd1; ++ break; ++ case NAND_DEV_CMD1_RESTORE: ++ first = NAND_DEV_CMD1; ++ vaddr = ®s->orig_cmd1; ++ break; ++ case NAND_DEV_CMD_VLD: ++ vaddr = ®s->vld; ++ break; ++ case NAND_DEV_CMD_VLD_RESTORE: ++ first = NAND_DEV_CMD_VLD; ++ vaddr = ®s->orig_vld; ++ break; ++ case NAND_EBI2_ECC_BUF_CFG: ++ vaddr = ®s->ecc_buf_cfg; ++ break; ++ default: ++ dev_err(this->dev, "invalid starting register\n"); ++ return -EINVAL; ++ } ++ ++ size = num_regs * sizeof(u32); ++ ++ return prep_dma_desc(this, false, first, vaddr, size, flow_control); ++} ++ ++/* ++ * read_data_dma: prepares a DMA descriptor to transfer data from the ++ * controller's internal buffer to the buffer 'vaddr' ++ * ++ * @reg_off: offset within the controller's data buffer ++ * @vaddr: virtual address of the buffer we want to write to ++ * @size: DMA transaction size in bytes ++ */ ++static int read_data_dma(struct qcom_nandc_data *this, int reg_off, ++ const u8 *vaddr, int size) ++{ ++ return prep_dma_desc(this, true, reg_off, vaddr, size, false); ++} ++ ++/* ++ * write_data_dma: prepares a DMA descriptor to transfer data from ++ * 'vaddr' to the controller's internal buffer ++ * ++ * @reg_off: offset within the controller's data buffer ++ * @vaddr: virtual address of the buffer we want to read from ++ * @size: DMA transaction size in bytes ++ */ ++static int write_data_dma(struct qcom_nandc_data *this, int reg_off, ++ const u8 *vaddr, int size) ++{ ++ return prep_dma_desc(this, false, reg_off, vaddr, size, false); ++} ++ ++/* ++ * helper to prepare dma descriptors to configure registers needed for reading a ++ * codeword/step in a page ++ */ ++static void config_cw_read(struct qcom_nandc_data *this) ++{ ++ write_reg_dma(this, NAND_FLASH_CMD, 3); ++ write_reg_dma(this, NAND_DEV0_CFG0, 3); ++ write_reg_dma(this, NAND_EBI2_ECC_BUF_CFG, 1); ++ ++ write_reg_dma(this, NAND_EXEC_CMD, 1); ++ ++ read_reg_dma(this, NAND_FLASH_STATUS, 2); ++ read_reg_dma(this, NAND_ERASED_CW_DETECT_STATUS, 1); ++} ++ ++/* ++ * helpers to prepare dma descriptors used to configure registers needed for ++ * writing a codeword/step in a page ++ */ ++static void config_cw_write_pre(struct qcom_nandc_data *this) ++{ ++ write_reg_dma(this, NAND_FLASH_CMD, 3); ++ write_reg_dma(this, NAND_DEV0_CFG0, 3); ++ write_reg_dma(this, NAND_EBI2_ECC_BUF_CFG, 1); ++} ++ ++static void config_cw_write_post(struct qcom_nandc_data *this) ++{ ++ write_reg_dma(this, NAND_EXEC_CMD, 1); ++ ++ read_reg_dma(this, NAND_FLASH_STATUS, 1); ++ ++ write_reg_dma(this, NAND_FLASH_STATUS, 1); ++ write_reg_dma(this, NAND_READ_STATUS, 1); ++} ++ ++/* ++ * the following functions are used within chip->cmdfunc() to perform different ++ * NAND_CMD_* commands ++ */ ++ ++/* sets up descriptors for NAND_CMD_PARAM */ ++static int nandc_param(struct qcom_nandc_data *this) ++{ ++ struct nandc_regs *regs = this->regs; ++ ++ /* ++ * NAND_CMD_PARAM is called before we know much about the FLASH chip ++ * in use. we configure the controller to perform a raw read of 512 ++ * bytes to read onfi params ++ */ ++ regs->cmd = PAGE_READ | PAGE_ACC | LAST_PAGE; ++ regs->addr0 = 0; ++ regs->addr1 = 0; ++ regs->cfg0 = 0 << CW_PER_PAGE ++ | 512 << UD_SIZE_BYTES ++ | 5 << NUM_ADDR_CYCLES ++ | 0 << SPARE_SIZE_BYTES; ++ ++ regs->cfg1 = 7 << NAND_RECOVERY_CYCLES ++ | 0 << CS_ACTIVE_BSY ++ | 17 << BAD_BLOCK_BYTE_NUM ++ | 1 << BAD_BLOCK_IN_SPARE_AREA ++ | 2 << WR_RD_BSY_GAP ++ | 0 << WIDE_FLASH ++ | 1 << DEV0_CFG1_ECC_DISABLE; ++ ++ regs->ecc_bch_cfg = 1 << ECC_CFG_ECC_DISABLE; ++ ++ /* configure CMD1 and VLD for ONFI param probing */ ++ regs->vld = (this->vld & ~(1 << READ_START_VLD)) ++ | 0 << READ_START_VLD; ++ ++ regs->cmd1 = (this->cmd1 & ~(0xFF << READ_ADDR)) ++ | NAND_CMD_PARAM << READ_ADDR; ++ ++ regs->exec = 1; ++ ++ regs->orig_cmd1 = this->cmd1; ++ regs->orig_vld = this->vld; ++ ++ write_reg_dma(this, NAND_DEV_CMD_VLD, 1); ++ write_reg_dma(this, NAND_DEV_CMD1, 1); ++ ++ this->buf_count = 512; ++ memset(this->data_buffer, 0xff, this->buf_count); ++ ++ config_cw_read(this); ++ ++ read_data_dma(this, FLASH_BUF_ACC, this->data_buffer, this->buf_count); ++ ++ /* restore CMD1 and VLD regs */ ++ write_reg_dma(this, NAND_DEV_CMD1_RESTORE, 1); ++ write_reg_dma(this, NAND_DEV_CMD_VLD_RESTORE, 1); ++ ++ return 0; ++} ++ ++/* sets up descriptors for NAND_CMD_ERASE1 */ ++static int erase_block(struct qcom_nandc_data *this, int page_addr) ++{ ++ struct nandc_regs *regs = this->regs; ++ ++ regs->cmd = BLOCK_ERASE | PAGE_ACC | LAST_PAGE; ++ regs->addr0 = page_addr; ++ regs->addr1 = 0; ++ regs->cfg0 = this->cfg0_raw & ~(7 << CW_PER_PAGE); ++ regs->cfg1 = this->cfg1_raw; ++ regs->exec = 1; ++ regs->clrflashstatus = this->clrflashstatus; ++ regs->clrreadstatus = this->clrreadstatus; ++ ++ write_reg_dma(this, NAND_FLASH_CMD, 3); ++ write_reg_dma(this, NAND_DEV0_CFG0, 2); ++ write_reg_dma(this, NAND_EXEC_CMD, 1); ++ ++ read_reg_dma(this, NAND_FLASH_STATUS, 1); ++ ++ write_reg_dma(this, NAND_FLASH_STATUS, 1); ++ write_reg_dma(this, NAND_READ_STATUS, 1); ++ ++ return 0; ++} ++ ++/* sets up descriptors for NAND_CMD_READID */ ++static int read_id(struct qcom_nandc_data *this, int column) ++{ ++ struct nandc_regs *regs = this->regs; ++ ++ if (column == -1) ++ return 0; ++ ++ regs->cmd = FETCH_ID; ++ regs->addr0 = column; ++ regs->addr1 = 0; ++ regs->chip_sel = DM_EN; ++ regs->exec = 1; ++ ++ write_reg_dma(this, NAND_FLASH_CMD, 4); ++ write_reg_dma(this, NAND_EXEC_CMD, 1); ++ ++ read_reg_dma(this, NAND_READ_ID, 1); ++ ++ return 0; ++} ++ ++/* sets up descriptors for NAND_CMD_RESET */ ++static int reset(struct qcom_nandc_data *this) ++{ ++ struct nandc_regs *regs = this->regs; ++ ++ regs->cmd = RESET_DEVICE; ++ regs->exec = 1; ++ ++ write_reg_dma(this, NAND_FLASH_CMD, 1); ++ write_reg_dma(this, NAND_EXEC_CMD, 1); ++ ++ read_reg_dma(this, NAND_FLASH_STATUS, 1); ++ ++ return 0; ++} ++ ++/* helpers to submit/free our list of dma descriptors */ ++static void dma_callback(void *param) ++{ ++ struct qcom_nandc_data *this = param; ++ struct completion *c = &this->dma_done; ++ ++ complete(c); ++} ++ ++static int submit_descs(struct qcom_nandc_data *this) ++{ ++ struct completion *c = &this->dma_done; ++ struct desc_info *desc; ++ int r; ++ ++ init_completion(c); ++ ++ list_for_each_entry(desc, &this->list, list) { ++ /* ++ * we add a callback to the last descriptor in our list to ++ * notify completion of command ++ */ ++ if (list_is_last(&desc->list, &this->list)) { ++ desc->dma_desc->callback = dma_callback; ++ desc->dma_desc->callback_param = this; ++ } ++ ++ dmaengine_submit(desc->dma_desc); ++ } ++ ++ dma_async_issue_pending(this->chan); ++ ++ r = wait_for_completion_timeout(c, msecs_to_jiffies(500)); ++ if (!r) ++ return -ETIMEDOUT; ++ ++ return 0; ++} ++ ++static void free_descs(struct qcom_nandc_data *this) ++{ ++ struct desc_info *desc, *n; ++ ++ list_for_each_entry_safe(desc, n, &this->list, list) { ++ list_del(&desc->list); ++ dma_unmap_sg(this->dev, &desc->sgl, 1, desc->dir); ++ kfree(desc); ++ } ++} ++ ++/* reset the register read buffer for next NAND operation */ ++static void clear_read_regs(struct qcom_nandc_data *this) ++{ ++ this->reg_read_pos = 0; ++ memset(this->reg_read_buf, 0, MAX_REG_RD * sizeof(*this->reg_read_buf)); ++} ++ ++static void pre_command(struct qcom_nandc_data *this, int command) ++{ ++ this->buf_count = 0; ++ this->buf_start = 0; ++ this->use_ecc = false; ++ this->last_command = command; ++ ++ clear_read_regs(this); ++} ++ ++/* ++ * this is called after NAND_CMD_PAGEPROG and NAND_CMD_ERASE1 to set our ++ * privately maintained status byte, this status byte can be read after ++ * NAND_CMD_STATUS is called ++ */ ++static void parse_erase_write_errors(struct qcom_nandc_data *this, int command) ++{ ++ struct nand_chip *chip = &this->chip; ++ struct nand_ecc_ctrl *ecc = &chip->ecc; ++ int num_cw; ++ int i; ++ ++ num_cw = command == NAND_CMD_PAGEPROG ? ecc->steps : 1; ++ ++ for (i = 0; i < num_cw; i++) { ++ __le32 flash_status = le32_to_cpu(this->reg_read_buf[i]); ++ ++ if (flash_status & FS_MPU_ERR) ++ this->status &= ~NAND_STATUS_WP; ++ ++ if (flash_status & FS_OP_ERR || (i == (num_cw - 1) && ++ (flash_status & FS_DEVICE_STS_ERR))) ++ this->status |= NAND_STATUS_FAIL; ++ } ++} ++ ++static void post_command(struct qcom_nandc_data *this, int command) ++{ ++ switch (command) { ++ case NAND_CMD_READID: ++ memcpy(this->data_buffer, this->reg_read_buf, this->buf_count); ++ break; ++ case NAND_CMD_PAGEPROG: ++ case NAND_CMD_ERASE1: ++ parse_erase_write_errors(this, command); ++ break; ++ default: ++ break; ++ } ++} ++ ++/* ++ * Implements chip->cmdfunc. It's only used for a limited set of commands. ++ * The rest of the commands wouldn't be called by upper layers. For example, ++ * NAND_CMD_READOOB would never be called because we have our own versions ++ * of read_oob ops for nand_ecc_ctrl. ++ */ ++static void qcom_nandc_command(struct mtd_info *mtd, unsigned int command, ++ int column, int page_addr) ++{ ++ struct nand_chip *chip = mtd->priv; ++ struct nand_ecc_ctrl *ecc = &chip->ecc; ++ struct qcom_nandc_data *this = chip->priv; ++ bool wait = false; ++ int r = 0; ++ ++ pre_command(this, command); ++ ++ switch (command) { ++ case NAND_CMD_RESET: ++ r = reset(this); ++ wait = true; ++ break; ++ ++ case NAND_CMD_READID: ++ this->buf_count = 4; ++ r = read_id(this, column); ++ wait = true; ++ break; ++ ++ case NAND_CMD_PARAM: ++ r = nandc_param(this); ++ wait = true; ++ break; ++ ++ case NAND_CMD_ERASE1: ++ r = erase_block(this, page_addr); ++ wait = true; ++ break; ++ ++ case NAND_CMD_READ0: ++ /* we read the entire page for now */ ++ WARN_ON(column != 0); ++ ++ this->use_ecc = true; ++ set_address(this, 0, page_addr); ++ update_rw_regs(this, ecc->steps, true); ++ break; ++ ++ case NAND_CMD_SEQIN: ++ WARN_ON(column != 0); ++ set_address(this, 0, page_addr); ++ break; ++ ++ case NAND_CMD_PAGEPROG: ++ case NAND_CMD_STATUS: ++ case NAND_CMD_NONE: ++ default: ++ break; ++ } ++ ++ if (r) { ++ dev_err(this->dev, "failure executing command %d\n", ++ command); ++ free_descs(this); ++ return; ++ } ++ ++ if (wait) { ++ r = submit_descs(this); ++ if (r) ++ dev_err(this->dev, ++ "failure submitting descs for command %d\n", ++ command); ++ } ++ ++ free_descs(this); ++ ++ post_command(this, command); ++} ++ ++/* ++ * when using RS ECC, the NAND controller flags an error when reading an ++ * erased page. however, there are special characters at certain offsets when ++ * we read the erased page. we check here if the page is really empty. if so, ++ * we replace the magic characters with 0xffs ++ */ ++static bool empty_page_fixup(struct qcom_nandc_data *this, u8 *data_buf) ++{ ++ struct mtd_info *mtd = &this->mtd; ++ struct nand_chip *chip = &this->chip; ++ struct nand_ecc_ctrl *ecc = &chip->ecc; ++ int cwperpage = ecc->steps; ++ u8 orig1[MAX_NUM_STEPS], orig2[MAX_NUM_STEPS]; ++ int i, j; ++ ++ /* if BCH is enabled, HW will take care of detecting erased pages */ ++ if (this->bch_enabled || !this->use_ecc) ++ return false; ++ ++ for (i = 0; i < cwperpage; i++) { ++ u8 *empty1, *empty2; ++ __le32 flash_status = le32_to_cpu(this->reg_read_buf[3 * i]); ++ ++ /* ++ * an erased page flags an error in NAND_FLASH_STATUS, check if ++ * the page is erased by looking for 0x54s at offsets 3 and 175 ++ * from the beginning of each codeword ++ */ ++ if (!(flash_status & FS_OP_ERR)) ++ break; ++ ++ empty1 = &data_buf[3 + i * this->cw_data]; ++ empty2 = &data_buf[175 + i * this->cw_data]; ++ ++ /* ++ * if the error wasn't because of an erased page, bail out and ++ * and let someone else do the error checking ++ */ ++ if ((*empty1 == 0x54 && *empty2 == 0xff) || ++ (*empty1 == 0xff && *empty2 == 0x54)) { ++ orig1[i] = *empty1; ++ orig2[i] = *empty2; ++ ++ *empty1 = 0xff; ++ *empty2 = 0xff; ++ } else { ++ break; ++ } ++ } ++ ++ if (i < cwperpage || memchr_inv(data_buf, 0xff, mtd->writesize)) ++ goto not_empty; ++ ++ /* ++ * tell the caller that the page was empty and is fixed up, so that ++ * parse_read_errors() doesn't think it's an error ++ */ ++ return true; ++ ++not_empty: ++ /* restore original values if not empty*/ ++ for (j = 0; j < i; j++) { ++ data_buf[3 + j * this->cw_data] = orig1[j]; ++ data_buf[175 + j * this->cw_data] = orig2[j]; ++ } ++ ++ return false; ++} ++ ++struct read_stats { ++ __le32 flash; ++ __le32 buffer; ++ __le32 erased_cw; ++}; ++ ++/* ++ * reads back status registers set by the controller to notify page read ++ * errors. this is equivalent to what 'ecc->correct()' would do. ++ */ ++static int parse_read_errors(struct qcom_nandc_data *this, bool erased_page) ++{ ++ struct mtd_info *mtd = &this->mtd; ++ struct nand_chip *chip = &this->chip; ++ struct nand_ecc_ctrl *ecc = &chip->ecc; ++ int cwperpage = ecc->steps; ++ unsigned int max_bitflips = 0; ++ int i; ++ ++ for (i = 0; i < cwperpage; i++) { ++ int stat; ++ struct read_stats *buf; ++ ++ buf = (struct read_stats *) (this->reg_read_buf + 3 * i); ++ ++ buf->flash = le32_to_cpu(buf->flash); ++ buf->buffer = le32_to_cpu(buf->buffer); ++ buf->erased_cw = le32_to_cpu(buf->erased_cw); ++ ++ if (buf->flash & (FS_OP_ERR | FS_MPU_ERR)) { ++ ++ /* ignore erased codeword errors */ ++ if (this->bch_enabled) { ++ if ((buf->erased_cw & ERASED_CW) == ERASED_CW) ++ continue; ++ } else if (erased_page) { ++ continue; ++ } ++ ++ if (buf->buffer & BS_UNCORRECTABLE_BIT) { ++ mtd->ecc_stats.failed++; ++ continue; ++ } ++ } ++ ++ stat = buf->buffer & BS_CORRECTABLE_ERR_MSK; ++ mtd->ecc_stats.corrected += stat; ++ ++ max_bitflips = max_t(unsigned int, max_bitflips, stat); ++ } ++ ++ return max_bitflips; ++} ++ ++/* ++ * helper to perform the actual page read operation, used by ecc->read_page() ++ * and ecc->read_oob() ++ */ ++static int read_page_low(struct qcom_nandc_data *this, u8 *data_buf, ++ u8 *oob_buf) ++{ ++ struct nand_chip *chip = &this->chip; ++ struct nand_ecc_ctrl *ecc = &chip->ecc; ++ int i, r; ++ ++ /* queue cmd descs for each codeword */ ++ for (i = 0; i < ecc->steps; i++) { ++ int data_size, oob_size; ++ ++ if (i == (ecc->steps - 1)) { ++ data_size = ecc->size - ((ecc->steps - 1) << 2); ++ oob_size = (ecc->steps << 2) + ecc->bytes; ++ } else { ++ data_size = this->cw_data; ++ oob_size = ecc->bytes; ++ } ++ ++ config_cw_read(this); ++ ++ if (data_buf) ++ read_data_dma(this, FLASH_BUF_ACC, data_buf, data_size); ++ ++ if (oob_buf) ++ read_data_dma(this, FLASH_BUF_ACC + data_size, oob_buf, ++ oob_size); ++ ++ if (data_buf) ++ data_buf += data_size; ++ if (oob_buf) ++ oob_buf += oob_size; ++ } ++ ++ r = submit_descs(this); ++ if (r) ++ dev_err(this->dev, "failure to read page/oob\n"); ++ ++ free_descs(this); ++ ++ return r; ++} ++ ++/* ++ * a helper that copies the last step/codeword of a page (containing free oob) ++ * into our local buffer ++ */ ++static int copy_last_cw(struct qcom_nandc_data *this, bool use_ecc, int page) ++{ ++ struct nand_chip *chip = &this->chip; ++ struct nand_ecc_ctrl *ecc = &chip->ecc; ++ int size; ++ int r; ++ ++ clear_read_regs(this); ++ ++ size = use_ecc ? this->cw_data : this->cw_size; ++ ++ /* prepare a clean read buffer */ ++ memset(this->data_buffer, 0xff, size); ++ ++ this->use_ecc = use_ecc; ++ set_address(this, this->cw_size * (ecc->steps - 1), page); ++ update_rw_regs(this, 1, true); ++ ++ config_cw_read(this); ++ ++ read_data_dma(this, FLASH_BUF_ACC, this->data_buffer, size); ++ ++ r = submit_descs(this); ++ if (r) ++ dev_err(this->dev, "failed to copy last codeword\n"); ++ ++ free_descs(this); ++ ++ return r; ++} ++ ++/* implements ecc->read_page() */ ++static int qcom_nandc_read_page(struct mtd_info *mtd, struct nand_chip *chip, ++ uint8_t *buf, int oob_required, int page) ++{ ++ struct qcom_nandc_data *this = chip->priv; ++ u8 *data_buf, *oob_buf = NULL; ++ bool erased_page; ++ int r; ++ ++ data_buf = buf; ++ oob_buf = oob_required ? chip->oob_poi : NULL; ++ ++ r = read_page_low(this, data_buf, oob_buf); ++ if (r) { ++ dev_err(this->dev, "failure to read page\n"); ++ return r; ++ } ++ ++ erased_page = empty_page_fixup(this, data_buf); ++ ++ return parse_read_errors(this, erased_page); ++} ++ ++/* implements ecc->read_oob() */ ++static int qcom_nandc_read_oob(struct mtd_info *mtd, struct nand_chip *chip, ++ int page) ++{ ++ struct qcom_nandc_data *this = chip->priv; ++ struct nand_ecc_ctrl *ecc = &chip->ecc; ++ int r; ++ ++ clear_read_regs(this); ++ ++ this->use_ecc = true; ++ set_address(this, 0, page); ++ update_rw_regs(this, ecc->steps, true); ++ ++ r = read_page_low(this, NULL, chip->oob_poi); ++ if (r) ++ dev_err(this->dev, "failure to read oob\n"); ++ ++ return r; ++} ++ ++/* implements ecc->read_oob_raw(), used to read the bad block marker flag */ ++static int qcom_nandc_read_oob_raw(struct mtd_info *mtd, struct nand_chip *chip, ++ int page) ++{ ++ struct qcom_nandc_data *this = chip->priv; ++ struct nand_ecc_ctrl *ecc = &chip->ecc; ++ uint8_t *oob = chip->oob_poi; ++ int start, length; ++ int r; ++ ++ /* ++ * configure registers for a raw page read, the address is set to the ++ * beginning of the last codeword, we don't care about reading ecc ++ * portion of oob, just the free stuff ++ */ ++ r = copy_last_cw(this, false, page); ++ if (r) ++ return r; ++ ++ /* ++ * reading raw oob has 2 parts, first the bad block byte, then the ++ * actual free oob region. perform a memcpy in two steps ++ */ ++ start = mtd->writesize - (this->cw_size * (ecc->steps - 1)); ++ length = chip->options & NAND_BUSWIDTH_16 ? 2 : 1; ++ ++ memcpy(oob, this->data_buffer + start, length); ++ ++ oob += length; ++ ++ start = this->cw_data - (ecc->steps << 2) + 1; ++ length = ecc->steps << 2; ++ ++ memcpy(oob, this->data_buffer + start, length); ++ ++ return 0; ++} ++ ++/* implements ecc->write_page() */ ++static int qcom_nandc_write_page(struct mtd_info *mtd, struct nand_chip *chip, ++ const uint8_t *buf, int oob_required) ++{ ++ struct qcom_nandc_data *this = chip->priv; ++ struct nand_ecc_ctrl *ecc = &chip->ecc; ++ u8 *data_buf, *oob_buf; ++ int i, r = 0; ++ ++ clear_read_regs(this); ++ ++ data_buf = (u8 *) buf; ++ oob_buf = chip->oob_poi; ++ ++ this->use_ecc = true; ++ update_rw_regs(this, ecc->steps, false); ++ ++ for (i = 0; i < ecc->steps; i++) { ++ int data_size, oob_size; ++ ++ if (i == (ecc->steps - 1)) { ++ data_size = ecc->size - ((ecc->steps - 1) << 2); ++ oob_size = (ecc->steps << 2) + ecc->bytes; ++ } else { ++ data_size = this->cw_data; ++ oob_size = ecc->bytes; ++ } ++ ++ config_cw_write_pre(this); ++ write_data_dma(this, FLASH_BUF_ACC, data_buf, data_size); ++ ++ /* ++ * we don't really need to write anything to oob for the ++ * first n - 1 codewords since these oob regions just ++ * contain ecc that's written by the controller itself ++ */ ++ if (i == (ecc->steps - 1)) ++ write_data_dma(this, FLASH_BUF_ACC + data_size, ++ oob_buf, oob_size); ++ config_cw_write_post(this); ++ ++ data_buf += data_size; ++ oob_buf += oob_size; ++ } ++ ++ r = submit_descs(this); ++ if (r) ++ dev_err(this->dev, "failure to write page\n"); ++ ++ free_descs(this); ++ ++ return r; ++} ++ ++/* ++ * implements ecc->write_oob() ++ * ++ * the NAND controller cannot write only data or only oob within a codeword, ++ * since ecc is calculated for the combined codeword. we first copy the ++ * entire contents for the last codeword(data + oob), replace the old oob ++ * with the new one in chip->oob_poi, and then write the entire codeword. ++ * this read-copy-write operation results in a slight perormance loss. ++ */ ++static int qcom_nandc_write_oob(struct mtd_info *mtd, struct nand_chip *chip, ++ int page) ++{ ++ struct qcom_nandc_data *this = chip->priv; ++ struct nand_ecc_ctrl *ecc = &chip->ecc; ++ uint8_t *oob = chip->oob_poi; ++ int free_boff; ++ int data_size, oob_size; ++ int r, status = 0; ++ ++ r = copy_last_cw(this, true, page); ++ if (r) ++ return r; ++ ++ clear_read_regs(this); ++ ++ /* calculate the data and oob size for the last codeword/step */ ++ data_size = ecc->size - ((ecc->steps - 1) << 2); ++ oob_size = (ecc->steps << 2) + ecc->bytes; ++ ++ /* ++ * the location of spare data in the oob buffer, we could also use ++ * ecc->layout.oobfree here ++ */ ++ free_boff = ecc->bytes * (ecc->steps - 1); ++ ++ /* override new oob content to last codeword */ ++ memcpy(this->data_buffer + data_size, oob + free_boff, oob_size); ++ ++ this->use_ecc = true; ++ set_address(this, this->cw_size * (ecc->steps - 1), page); ++ update_rw_regs(this, 1, false); ++ ++ config_cw_write_pre(this); ++ write_data_dma(this, FLASH_BUF_ACC, this->data_buffer, ++ data_size + oob_size); ++ config_cw_write_post(this); ++ ++ r = submit_descs(this); ++ ++ free_descs(this); ++ ++ if (r) { ++ dev_err(this->dev, "failure to write oob\n"); ++ return -EIO; ++ } ++ ++ chip->cmdfunc(mtd, NAND_CMD_PAGEPROG, -1, -1); ++ ++ status = chip->waitfunc(mtd, chip); ++ ++ return status & NAND_STATUS_FAIL ? -EIO : 0; ++} ++ ++/* implements ecc->write_oob_raw(), used to write bad block marker flag */ ++static int qcom_nandc_write_oob_raw(struct mtd_info *mtd, ++ struct nand_chip *chip, int page) ++{ ++ struct qcom_nandc_data *this = chip->priv; ++ struct nand_ecc_ctrl *ecc = &chip->ecc; ++ uint8_t *oob = chip->oob_poi; ++ int start, length; ++ int r, status = 0; ++ ++ r = copy_last_cw(this, false, page); ++ if (r) ++ return r; ++ ++ clear_read_regs(this); ++ ++ /* ++ * writing raw oob has 2 parts, first the bad block region, then the ++ * actual free region ++ */ ++ start = mtd->writesize - (this->cw_size * (ecc->steps - 1)); ++ length = chip->options & NAND_BUSWIDTH_16 ? 2 : 1; ++ ++ memcpy(this->data_buffer + start, oob, length); ++ ++ oob += length; ++ ++ start = this->cw_data - (ecc->steps << 2) + 1; ++ length = ecc->steps << 2; ++ ++ memcpy(this->data_buffer + start, oob, length); ++ ++ /* prepare write */ ++ this->use_ecc = false; ++ set_address(this, this->cw_size * (ecc->steps - 1), page); ++ update_rw_regs(this, 1, false); ++ ++ config_cw_write_pre(this); ++ write_data_dma(this, FLASH_BUF_ACC, this->data_buffer, this->cw_size); ++ config_cw_write_post(this); ++ ++ r = submit_descs(this); ++ ++ free_descs(this); ++ ++ if (r) { ++ dev_err(this->dev, "failure to write updated oob\n"); ++ return -EIO; ++ } ++ ++ chip->cmdfunc(mtd, NAND_CMD_PAGEPROG, -1, -1); ++ ++ status = chip->waitfunc(mtd, chip); ++ ++ return status & NAND_STATUS_FAIL ? -EIO : 0; ++} ++ ++/* ++ * the three functions below implement chip->read_byte(), chip->read_buf() ++ * and chip->write_buf() respectively. these aren't used for ++ * reading/writing page data, they are used for smaller data like reading ++ * id, status etc ++ */ ++static uint8_t qcom_nandc_read_byte(struct mtd_info *mtd) ++{ ++ struct nand_chip *chip = mtd->priv; ++ struct qcom_nandc_data *this = chip->priv; ++ uint8_t *buf = this->data_buffer; ++ uint8_t ret = 0x0; ++ ++ if (this->last_command == NAND_CMD_STATUS) { ++ ret = this->status; ++ ++ this->status = NAND_STATUS_READY | NAND_STATUS_WP; ++ ++ return ret; ++ } ++ ++ if (this->buf_start < this->buf_count) ++ ret = buf[this->buf_start++]; ++ ++ return ret; ++} ++ ++static void qcom_nandc_read_buf(struct mtd_info *mtd, uint8_t *buf, int len) ++{ ++ struct nand_chip *chip = mtd->priv; ++ struct qcom_nandc_data *this = chip->priv; ++ int real_len = min_t(size_t, len, this->buf_count - this->buf_start); ++ ++ memcpy(buf, this->data_buffer + this->buf_start, real_len); ++ this->buf_start += real_len; ++} ++ ++static void qcom_nandc_write_buf(struct mtd_info *mtd, const uint8_t *buf, ++ int len) ++{ ++ struct nand_chip *chip = mtd->priv; ++ struct qcom_nandc_data *this = chip->priv; ++ int real_len = min_t(size_t, len, this->buf_count - this->buf_start); ++ ++ memcpy(this->data_buffer + this->buf_start, buf, real_len); ++ ++ this->buf_start += real_len; ++} ++ ++/* we support only one external chip for now */ ++static void qcom_nandc_select_chip(struct mtd_info *mtd, int chipnr) ++{ ++ struct nand_chip *chip = mtd->priv; ++ struct qcom_nandc_data *this = chip->priv; ++ ++ if (chipnr <= 0) ++ return; ++ ++ dev_warn(this->dev, "invalid chip select\n"); ++} ++ ++/* ++ * NAND controller page layout info ++ * ++ * |-----------------------| |---------------------------------| ++ * | xx.......xx| | *********xx.......xx| ++ * | DATA xx..ECC..xx| | DATA **SPARE**xx..ECC..xx| ++ * | (516) xx.......xx| | (516-n*4) **(n*4)**xx.......xx| ++ * | xx.......xx| | *********xx.......xx| ++ * |-----------------------| |---------------------------------| ++ * codeword 1,2..n-1 codeword n ++ * <---(528/532 Bytes)----> <-------(528/532 Bytes)----------> ++ * ++ * n = number of codewords in the page ++ * . = ECC bytes ++ * * = spare bytes ++ * x = unused/reserved bytes ++ * ++ * 2K page: n = 4, spare = 16 bytes ++ * 4K page: n = 8, spare = 32 bytes ++ * 8K page: n = 16, spare = 64 bytes ++ * ++ * the qcom nand controller operates at a sub page/codeword level. each ++ * codeword is 528 and 532 bytes for 4 bit and 8 bit ECC modes respectively. ++ * the number of ECC bytes vary based on the ECC strength and the bus width. ++ * ++ * the first n - 1 codewords contains 516 bytes of user data, the remaining ++ * 12/16 bytes consist of ECC and reserved data. The nth codeword contains ++ * both user data and spare(oobavail) bytes that sum up to 516 bytes. ++ * ++ * the layout described above is used by the controller when the ECC block is ++ * enabled. When we read a page with ECC enabled, the unused/reserved bytes are ++ * skipped and not copied to our internal buffer. therefore, the nand_ecclayout ++ * layouts defined below doesn't consider the positions occupied by the reserved ++ * bytes ++ * ++ * when the ECC block is disabled, one unused byte (or two for 16 bit bus width) ++ * in the last codeword is the position of bad block marker. the bad block ++ * marker cannot be accessed when ECC is enabled. ++ * ++ */ ++ ++/* ++ * Layouts for different page sizes and ecc modes. We skip the eccpos field ++ * since it isn't needed for this driver ++ */ ++ ++/* 2K page, 4 bit ECC */ ++static struct nand_ecclayout layout_oob_64 = { ++ .eccbytes = 40, ++ .oobfree = { ++ { 30, 16 }, ++ }, ++}; ++ ++/* 4K page, 4 bit ECC, 8/16 bit bus width */ ++static struct nand_ecclayout layout_oob_128 = { ++ .eccbytes = 80, ++ .oobfree = { ++ { 70, 32 }, ++ }, ++}; ++ ++/* 4K page, 8 bit ECC, 8 bit bus width */ ++static struct nand_ecclayout layout_oob_224_x8 = { ++ .eccbytes = 104, ++ .oobfree = { ++ { 91, 32 }, ++ }, ++}; ++ ++/* 4K page, 8 bit ECC, 16 bit bus width */ ++static struct nand_ecclayout layout_oob_224_x16 = { ++ .eccbytes = 112, ++ .oobfree = { ++ { 98, 32 }, ++ }, ++}; ++ ++/* 8K page, 4 bit ECC, 8/16 bit bus width */ ++static struct nand_ecclayout layout_oob_256 = { ++ .eccbytes = 160, ++ .oobfree = { ++ { 151, 64 }, ++ }, ++}; ++ ++/* ++ * this is called before scan_ident, we do some minimal configurations so ++ * that reading ID and ONFI params work ++ */ ++static void qcom_nandc_pre_init(struct qcom_nandc_data *this) ++{ ++ /* kill onenand */ ++ nandc_write(this, SFLASHC_BURST_CFG, 0); ++ ++ /* enable ADM DMA */ ++ nandc_write(this, NAND_FLASH_CHIP_SELECT, DM_EN); ++ ++ /* save the original values of these registers */ ++ this->cmd1 = nandc_read(this, NAND_DEV_CMD1); ++ this->vld = nandc_read(this, NAND_DEV_CMD_VLD); ++ ++ /* initial status value */ ++ this->status = NAND_STATUS_READY | NAND_STATUS_WP; ++} ++ ++static int qcom_nandc_ecc_init(struct qcom_nandc_data *this) ++{ ++ struct mtd_info *mtd = &this->mtd; ++ struct nand_chip *chip = &this->chip; ++ struct nand_ecc_ctrl *ecc = &chip->ecc; ++ int cwperpage; ++ bool wide_bus; ++ ++ /* the nand controller fetches codewords/chunks of 512 bytes */ ++ cwperpage = mtd->writesize >> 9; ++ ++ ecc->strength = this->ecc_strength; ++ ++ wide_bus = chip->options & NAND_BUSWIDTH_16 ? true : false; ++ ++ if (ecc->strength >= 8) { ++ /* 8 bit ECC defaults to BCH ECC on all platforms */ ++ ecc->bytes = wide_bus ? 14 : 13; ++ } else { ++ /* ++ * if the controller supports BCH for 4 bit ECC, the controller ++ * uses lesser bytes for ECC. If RS is used, the ECC bytes is ++ * always 10 bytes ++ */ ++ if (this->ecc_modes & ECC_BCH_4BIT) ++ ecc->bytes = wide_bus ? 8 : 7; ++ else ++ ecc->bytes = 10; ++ } ++ ++ /* each step consists of 512 bytes of data */ ++ ecc->size = NANDC_STEP_SIZE; ++ ++ ecc->read_page = qcom_nandc_read_page; ++ ecc->read_oob = qcom_nandc_read_oob; ++ ecc->write_page = qcom_nandc_write_page; ++ ecc->write_oob = qcom_nandc_write_oob; ++ ++ /* ++ * the bad block marker is readable only when we read the page with ECC ++ * disabled. all the ops above run with ECC enabled. We need raw read ++ * and write function for oob in order to access bad block marker. ++ */ ++ ecc->read_oob_raw = qcom_nandc_read_oob_raw; ++ ecc->write_oob_raw = qcom_nandc_write_oob_raw; ++ ++ switch (mtd->oobsize) { ++ case 64: ++ ecc->layout = &layout_oob_64; ++ break; ++ case 128: ++ ecc->layout = &layout_oob_128; ++ break; ++ case 224: ++ if (wide_bus) ++ ecc->layout = &layout_oob_224_x16; ++ else ++ ecc->layout = &layout_oob_224_x8; ++ break; ++ case 256: ++ ecc->layout = &layout_oob_256; ++ break; ++ default: ++ dev_err(this->dev, "unsupported NAND device, oobsize %d\n", ++ mtd->oobsize); ++ return -ENODEV; ++ } ++ ++ ecc->mode = NAND_ECC_HW; ++ ++ /* enable ecc by default */ ++ this->use_ecc = true; ++ ++ return 0; ++} ++ ++static void qcom_nandc_hw_post_init(struct qcom_nandc_data *this) ++{ ++ struct mtd_info *mtd = &this->mtd; ++ struct nand_chip *chip = &this->chip; ++ struct nand_ecc_ctrl *ecc = &chip->ecc; ++ int cwperpage = mtd->writesize / ecc->size; ++ int spare_bytes, bad_block_byte; ++ bool wide_bus; ++ int ecc_mode = 0; ++ ++ wide_bus = chip->options & NAND_BUSWIDTH_16 ? true : false; ++ ++ if (ecc->strength >= 8) { ++ this->cw_size = 532; ++ ++ spare_bytes = wide_bus ? 0 : 2; ++ ++ this->bch_enabled = true; ++ ecc_mode = 1; ++ } else { ++ this->cw_size = 528; ++ ++ if (this->ecc_modes & ECC_BCH_4BIT) { ++ spare_bytes = wide_bus ? 2 : 4; ++ ++ this->bch_enabled = true; ++ ecc_mode = 0; ++ } else { ++ spare_bytes = wide_bus ? 0 : 1; ++ } ++ } ++ ++ /* ++ * DATA_UD_BYTES varies based on whether the read/write command protects ++ * spare data with ECC too. We protect spare data by default, so we set ++ * it to main + spare data, which are 512 and 4 bytes respectively. ++ */ ++ this->cw_data = 516; ++ ++ bad_block_byte = mtd->writesize - this->cw_size * (cwperpage - 1) + 1; ++ ++ this->cfg0 = (cwperpage - 1) << CW_PER_PAGE ++ | this->cw_data << UD_SIZE_BYTES ++ | 0 << DISABLE_STATUS_AFTER_WRITE ++ | 5 << NUM_ADDR_CYCLES ++ | ecc->bytes << ECC_PARITY_SIZE_BYTES_RS ++ | 0 << STATUS_BFR_READ ++ | 1 << SET_RD_MODE_AFTER_STATUS ++ | spare_bytes << SPARE_SIZE_BYTES; ++ ++ this->cfg1 = 7 << NAND_RECOVERY_CYCLES ++ | 0 << CS_ACTIVE_BSY ++ | bad_block_byte << BAD_BLOCK_BYTE_NUM ++ | 0 << BAD_BLOCK_IN_SPARE_AREA ++ | 2 << WR_RD_BSY_GAP ++ | wide_bus << WIDE_FLASH ++ | this->bch_enabled << ENABLE_BCH_ECC; ++ ++ this->cfg0_raw = (cwperpage - 1) << CW_PER_PAGE ++ | this->cw_size << UD_SIZE_BYTES ++ | 5 << NUM_ADDR_CYCLES ++ | 0 << SPARE_SIZE_BYTES; ++ ++ this->cfg1_raw = 7 << NAND_RECOVERY_CYCLES ++ | 0 << CS_ACTIVE_BSY ++ | 17 << BAD_BLOCK_BYTE_NUM ++ | 1 << BAD_BLOCK_IN_SPARE_AREA ++ | 2 << WR_RD_BSY_GAP ++ | wide_bus << WIDE_FLASH ++ | 1 << DEV0_CFG1_ECC_DISABLE; ++ ++ this->ecc_bch_cfg = this->bch_enabled << ECC_CFG_ECC_DISABLE ++ | 0 << ECC_SW_RESET ++ | this->cw_data << ECC_NUM_DATA_BYTES ++ | 1 << ECC_FORCE_CLK_OPEN ++ | ecc_mode << ECC_MODE ++ | ecc->bytes << ECC_PARITY_SIZE_BYTES_BCH; ++ ++ this->ecc_buf_cfg = 0x203 << NUM_STEPS; ++ ++ this->clrflashstatus = FS_READY_BSY_N; ++ this->clrreadstatus = 0xc0; ++ ++ dev_dbg(this->dev, ++ "cfg0 %x cfg1 %x ecc_buf_cfg %x ecc_bch cfg %x cw_size %d cw_data %d strength %d parity_bytes %d steps %d\n", ++ this->cfg0, this->cfg1, this->ecc_buf_cfg, ++ this->ecc_bch_cfg, this->cw_size, this->cw_data, ++ ecc->strength, ecc->bytes, cwperpage); ++} ++ ++static int qcom_nandc_alloc(struct qcom_nandc_data *this) ++{ ++ int r; ++ ++ r = dma_set_coherent_mask(this->dev, DMA_BIT_MASK(32)); ++ if (r) { ++ dev_err(this->dev, "failed to set DMA mask\n"); ++ return r; ++ } ++ ++ /* ++ * we use the internal buffer for reading ONFI params, reading small ++ * data like ID and status, and preforming read-copy-write operations ++ * when writing to a codeword partially. 532 is the maximum possible ++ * size of a codeword for our nand controller ++ */ ++ this->buf_size = 532; ++ ++ this->data_buffer = devm_kzalloc(this->dev, this->buf_size, GFP_KERNEL); ++ if (!this->data_buffer) ++ return -ENOMEM; ++ ++ this->regs = devm_kzalloc(this->dev, sizeof(*this->regs), GFP_KERNEL); ++ if (!this->regs) ++ return -ENOMEM; ++ ++ this->reg_read_buf = devm_kzalloc(this->dev, ++ MAX_REG_RD * sizeof(*this->reg_read_buf), ++ GFP_KERNEL); ++ if (!this->reg_read_buf) ++ return -ENOMEM; ++ ++ INIT_LIST_HEAD(&this->list); ++ ++ this->chan = dma_request_slave_channel(this->dev, "rxtx"); ++ if (!this->chan) { ++ dev_err(this->dev, "failed to request slave channel\n"); ++ return -ENODEV; ++ } ++ ++ return 0; ++} ++ ++static void qcom_nandc_unalloc(struct qcom_nandc_data *this) ++{ ++ dma_release_channel(this->chan); ++} ++ ++static int qcom_nandc_init(struct qcom_nandc_data *this) ++{ ++ struct mtd_info *mtd = &this->mtd; ++ struct nand_chip *chip = &this->chip; ++ struct device_node *np = this->dev->of_node; ++ struct mtd_part_parser_data ppdata = { .of_node = np }; ++ int r; ++ ++ mtd->priv = chip; ++ mtd->name = "qcom-nandc"; ++ mtd->owner = THIS_MODULE; ++ ++ chip->priv = this; ++ ++ chip->cmdfunc = qcom_nandc_command; ++ chip->select_chip = qcom_nandc_select_chip; ++ chip->read_byte = qcom_nandc_read_byte; ++ chip->read_buf = qcom_nandc_read_buf; ++ chip->write_buf = qcom_nandc_write_buf; ++ ++ chip->options |= NAND_NO_SUBPAGE_WRITE | NAND_USE_BOUNCE_BUFFER; ++ if (this->bus_width == 16) ++ chip->options |= NAND_BUSWIDTH_16; ++ ++ chip->bbt_options = NAND_BBT_ACCESS_BBM_RAW; ++ if (of_get_nand_on_flash_bbt(np)) ++ chip->bbt_options = NAND_BBT_USE_FLASH | NAND_BBT_NO_OOB; ++ ++ qcom_nandc_pre_init(this); ++ ++ r = nand_scan_ident(mtd, 1, NULL); ++ if (r) ++ return r; ++ ++ r = qcom_nandc_ecc_init(this); ++ if (r) ++ return r; ++ ++ qcom_nandc_hw_post_init(this); ++ ++ r = nand_scan_tail(mtd); ++ if (r) ++ return r; ++ ++ return mtd_device_parse_register(mtd, NULL, &ppdata, NULL, 0); ++} ++ ++static int qcom_nandc_parse_dt(struct platform_device *pdev) ++{ ++ struct qcom_nandc_data *this = platform_get_drvdata(pdev); ++ struct device_node *np = this->dev->of_node; ++ int r; ++ ++ this->ecc_strength = of_get_nand_ecc_strength(np); ++ if (this->ecc_strength < 0) { ++ dev_warn(this->dev, ++ "incorrect ecc strength, setting to 4 bits/step\n"); ++ this->ecc_strength = 4; ++ } ++ ++ this->bus_width = of_get_nand_bus_width(np); ++ if (this->bus_width < 0) { ++ dev_warn(this->dev, "incorrect bus width, setting to 8\n"); ++ this->bus_width = 8; ++ } ++ ++ r = of_property_read_u32(np, "qcom,cmd-crci", &this->cmd_crci); ++ if (r) { ++ dev_err(this->dev, "command CRCI unspecified\n"); ++ return r; ++ } ++ ++ r = of_property_read_u32(np, "qcom,data-crci", &this->data_crci); ++ if (r) { ++ dev_err(this->dev, "data CRCI unspecified\n"); ++ return r; ++ } ++ ++ return 0; ++} ++ ++static int qcom_nandc_probe(struct platform_device *pdev) ++{ ++ struct qcom_nandc_data *this; ++ const struct of_device_id *match; ++ int r; ++ ++ this = devm_kzalloc(&pdev->dev, sizeof(*this), GFP_KERNEL); ++ if (!this) ++ return -ENOMEM; ++ ++ platform_set_drvdata(pdev, this); ++ ++ this->pdev = pdev; ++ this->dev = &pdev->dev; ++ ++ match = of_match_device(pdev->dev.driver->of_match_table, &pdev->dev); ++ if (!match) { ++ dev_err(&pdev->dev, "failed to match device\n"); ++ return -ENODEV; ++ } ++ ++ if (!match->data) { ++ dev_err(&pdev->dev, "failed to get device data\n"); ++ return -ENODEV; ++ } ++ ++ this->ecc_modes = (u32) match->data; ++ ++ this->res = platform_get_resource(pdev, IORESOURCE_MEM, 0); ++ this->base = devm_ioremap_resource(&pdev->dev, this->res); ++ if (IS_ERR(this->base)) ++ return PTR_ERR(this->base); ++ ++ this->core_clk = devm_clk_get(&pdev->dev, "core"); ++ if (IS_ERR(this->core_clk)) ++ return PTR_ERR(this->core_clk); ++ ++ this->aon_clk = devm_clk_get(&pdev->dev, "aon"); ++ if (IS_ERR(this->aon_clk)) ++ return PTR_ERR(this->aon_clk); ++ ++ r = qcom_nandc_parse_dt(pdev); ++ if (r) ++ return r; ++ ++ r = qcom_nandc_alloc(this); ++ if (r) ++ return r; ++ ++ r = clk_prepare_enable(this->core_clk); ++ if (r) ++ goto err_core_clk; ++ ++ r = clk_prepare_enable(this->aon_clk); ++ if (r) ++ goto err_aon_clk; ++ ++ r = qcom_nandc_init(this); ++ if (r) ++ goto err_init; ++ ++ return 0; ++ ++err_init: ++ clk_disable_unprepare(this->aon_clk); ++err_aon_clk: ++ clk_disable_unprepare(this->core_clk); ++err_core_clk: ++ qcom_nandc_unalloc(this); ++ ++ return r; ++} ++ ++static int qcom_nandc_remove(struct platform_device *pdev) ++{ ++ struct qcom_nandc_data *this = platform_get_drvdata(pdev); ++ ++ qcom_nandc_unalloc(this); ++ ++ clk_disable_unprepare(this->aon_clk); ++ clk_disable_unprepare(this->core_clk); ++ ++ return 0; ++} ++ ++#define EBI2_NANDC_ECC_MODES (ECC_RS_4BIT | ECC_BCH_8BIT) ++ ++/* ++ * data will hold a struct pointer containing more differences once we support ++ * more IPs ++ */ ++static const struct of_device_id qcom_nandc_of_match[] = { ++ { .compatible = "qcom,ebi2-nandc", ++ .data = (void *) EBI2_NANDC_ECC_MODES, ++ }, ++ {} ++}; ++MODULE_DEVICE_TABLE(of, qcom_nandc_of_match); ++ ++static struct platform_driver qcom_nandc_driver = { ++ .driver = { ++ .name = "qcom-nandc", ++ .of_match_table = qcom_nandc_of_match, ++ }, ++ .probe = qcom_nandc_probe, ++ .remove = qcom_nandc_remove, ++}; ++module_platform_driver(qcom_nandc_driver); ++ ++MODULE_AUTHOR("Archit Taneja "); ++MODULE_DESCRIPTION("Qualcomm NAND Controller driver"); ++MODULE_LICENSE("GPL v2"); +--- a/drivers/mtd/nand/Makefile ++++ b/drivers/mtd/nand/Makefile +@@ -55,5 +55,6 @@ + obj-$(CONFIG_MTD_NAND_SUNXI) += sunxi_nand.o + obj-$(CONFIG_MTD_NAND_HISI504) += hisi504_nand.o + obj-$(CONFIG_MTD_NAND_BRCMNAND) += brcmnand/ ++obj-$(CONFIG_MTD_NAND_QCOM) += qcom_nandc.o + + nand-objs := nand_base.o nand_bbt.o nand_timings.o diff --git a/target/linux/ipq806x/patches-4.4/163-dt-bindings-qcom_nandc-Add-DT-bindings.patch b/target/linux/ipq806x/patches-4.4/163-dt-bindings-qcom_nandc-Add-DT-bindings.patch new file mode 100644 index 0000000..6530eb1 --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/163-dt-bindings-qcom_nandc-Add-DT-bindings.patch @@ -0,0 +1,82 @@ +Content-Type: text/plain; charset="utf-8" +MIME-Version: 1.0 +Content-Transfer-Encoding: 7bit +Subject: [v3,3/5] dt/bindings: qcom_nandc: Add DT bindings +From: Archit Taneja +X-Patchwork-Id: 6927141 +Message-Id: <1438578498-32254-4-git-send-email-architt at codeaurora.org> +To: linux-mtd at lists.infradead.org, dehrenberg at google.com, + cernekee at gmail.com, computersforpeace at gmail.com +Cc: linux-arm-msm at vger.kernel.org, agross at codeaurora.org, + sboyd at codeaurora.org, linux-kernel at vger.kernel.org, + Archit Taneja , devicetree at vger.kernel.org +Date: Mon, 3 Aug 2015 10:38:16 +0530 + +Add DT bindings document for the Qualcomm NAND controller driver. + +Cc: devicetree at vger.kernel.org + +v3: +- Don't use '0x' when specifying nand controller address space +- Add optional property for on-flash bbt usage + +Acked-by: Andy Gross +Signed-off-by: Archit Taneja + +--- +.../devicetree/bindings/mtd/qcom_nandc.txt | 49 ++++++++++++++++++++++ + 1 file changed, 49 insertions(+) + create mode 100644 Documentation/devicetree/bindings/mtd/qcom_nandc.txt + +--- /dev/null ++++ b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt +@@ -0,0 +1,49 @@ ++* Qualcomm NAND controller ++ ++Required properties: ++- compatible: should be "qcom,ebi2-nand" for IPQ806x ++- reg: MMIO address range ++- clocks: must contain core clock and always on clock ++- clock-names: must contain "core" for the core clock and "aon" for the ++ always on clock ++- dmas: DMA specifier, consisting of a phandle to the ADM DMA ++ controller node and the channel number to be used for ++ NAND. Refer to dma.txt and qcom_adm.txt for more details ++- dma-names: must be "rxtx" ++- qcom,cmd-crci: must contain the ADM command type CRCI block instance ++ number specified for the NAND controller on the given ++ platform ++- qcom,data-crci: must contain the ADM data type CRCI block instance ++ number specified for the NAND controller on the given ++ platform ++ ++Optional properties: ++- nand-bus-width: bus width. Must be 8 or 16. If not present, 8 is chosen ++ as default ++ ++- nand-ecc-strength: number of bits to correct per ECC step. Must be 4 or 8 ++ bits. If not present, 4 is chosen as default ++- nand-on-flash-bbt: Create/use on-flash bad block table ++ ++The device tree may optionally contain sub-nodes describing partitions of the ++address space. See partition.txt for more detail. ++ ++Example: ++ ++nand at 1ac00000 { ++ compatible = "qcom,ebi2-nandc"; ++ reg = <0x1ac00000 0x800>; ++ ++ clocks = <&gcc EBI2_CLK>, ++ <&gcc EBI2_AON_CLK>; ++ clock-names = "core", "aon"; ++ ++ dmas = <&adm_dma 3>; ++ dma-names = "rxtx"; ++ qcom,cmd-crci = <15>; ++ qcom,data-crci = <3>; ++ ++ partition at 0 { ++ ... ++ }; ++}; diff --git a/target/linux/ipq806x/patches-4.4/164-arm-qcom-dts-Add-NAND-controller-node-for-ipq806x.patch b/target/linux/ipq806x/patches-4.4/164-arm-qcom-dts-Add-NAND-controller-node-for-ipq806x.patch new file mode 100644 index 0000000..4fc8a8c --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/164-arm-qcom-dts-Add-NAND-controller-node-for-ipq806x.patch @@ -0,0 +1,51 @@ +Content-Type: text/plain; charset="utf-8" +MIME-Version: 1.0 +Content-Transfer-Encoding: 7bit +Subject: [v3,4/5] arm: qcom: dts: Add NAND controller node for ipq806x +From: Archit Taneja +X-Patchwork-Id: 6927121 +Message-Id: <1438578498-32254-5-git-send-email-architt at codeaurora.org> +To: linux-mtd at lists.infradead.org, dehrenberg at google.com, + cernekee at gmail.com, computersforpeace at gmail.com +Cc: linux-arm-msm at vger.kernel.org, agross at codeaurora.org, + sboyd at codeaurora.org, linux-kernel at vger.kernel.org, + Archit Taneja , devicetree at vger.kernel.org +Date: Mon, 3 Aug 2015 10:38:17 +0530 + +The nand controller in IPQ806x is of the 'EBI2 type'. Use the corresponding +compatible string. + +Cc: devicetree at vger.kernel.org + +Reviewed-by: Andy Gross +Signed-off-by: Archit Taneja + +--- +arch/arm/boot/dts/qcom-ipq8064.dtsi | 15 +++++++++++++++ + 1 file changed, 15 insertions(+) + +--- a/arch/arm/boot/dts/qcom-ipq8064.dtsi ++++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi +@@ -747,6 +747,22 @@ + + status = "disabled"; + }; ++ ++ nand at 1ac00000 { ++ compatible = "qcom,ebi2-nandc"; ++ reg = <0x1ac00000 0x800>; ++ ++ clocks = <&gcc EBI2_CLK>, ++ <&gcc EBI2_AON_CLK>; ++ clock-names = "core", "aon"; ++ ++ dmas = <&adm_dma 3>; ++ dma-names = "rxtx"; ++ qcom,cmd-crci = <15>; ++ qcom,data-crci = <3>; ++ ++ status = "disabled"; ++ }; + }; + + sfpb_mutex: sfpb-mutex { diff --git a/target/linux/ipq806x/patches-4.4/165-arm-qcom-dts-Enable-NAND-node-on-IPQ8064-AP148-platform.patch b/target/linux/ipq806x/patches-4.4/165-arm-qcom-dts-Enable-NAND-node-on-IPQ8064-AP148-platform.patch new file mode 100644 index 0000000..9de3d8f --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/165-arm-qcom-dts-Enable-NAND-node-on-IPQ8064-AP148-platform.patch @@ -0,0 +1,76 @@ +Content-Type: text/plain; charset="utf-8" +MIME-Version: 1.0 +Content-Transfer-Encoding: 7bit +Subject: [v3,5/5] arm: qcom: dts: Enable NAND node on IPQ8064 AP148 platform +From: Archit Taneja +X-Patchwork-Id: 6927091 +Message-Id: <1438578498-32254-6-git-send-email-architt at codeaurora.org> +To: linux-mtd at lists.infradead.org, dehrenberg at google.com, + cernekee at gmail.com, computersforpeace at gmail.com +Cc: linux-arm-msm at vger.kernel.org, agross at codeaurora.org, + sboyd at codeaurora.org, linux-kernel at vger.kernel.org, + Archit Taneja , devicetree at vger.kernel.org +Date: Mon, 3 Aug 2015 10:38:18 +0530 + +Enable the NAND controller node on the AP148 platform. Provide pinmux +information. + +Cc: devicetree at vger.kernel.org + +Signed-off-by: Archit Taneja + +--- +arch/arm/boot/dts/qcom-ipq8064-ap148.dts | 36 ++++++++++++++++++++++++++++++++ + 1 file changed, 36 insertions(+) + +--- a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts ++++ b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts +@@ -43,6 +43,28 @@ + bias-none; + }; + }; ++ nand_pins: nand_pins { ++ mux { ++ pins = "gpio34", "gpio35", "gpio36", ++ "gpio37", "gpio38", "gpio39", ++ "gpio40", "gpio41", "gpio42", ++ "gpio43", "gpio44", "gpio45", ++ "gpio46", "gpio47"; ++ function = "nand"; ++ drive-strength = <10>; ++ bias-disable; ++ }; ++ pullups { ++ pins = "gpio39"; ++ bias-pull-up; ++ }; ++ hold { ++ pins = "gpio40", "gpio41", "gpio42", ++ "gpio43", "gpio44", "gpio45", ++ "gpio46", "gpio47"; ++ bias-bus-hold; ++ }; ++ }; + }; + + gsbi at 16300000 { +@@ -126,5 +148,19 @@ + status = "ok"; + phy-tx0-term-offset = <7>; + }; ++ ++ nand at 1ac00000 { ++ status = "ok"; ++ ++ pinctrl-0 = <&nand_pins>; ++ pinctrl-names = "default"; ++ ++ nand-ecc-strength = <4>; ++ nand-bus-width = <8>; ++ }; + }; + }; ++ ++&adm_dma { ++ status = "ok"; ++}; diff --git a/target/linux/ipq806x/patches-4.4/166-arch-qcom-dts-enable-qcom-smem-on-AP148-NAND.patch b/target/linux/ipq806x/patches-4.4/166-arch-qcom-dts-enable-qcom-smem-on-AP148-NAND.patch new file mode 100644 index 0000000..7060282 --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/166-arch-qcom-dts-enable-qcom-smem-on-AP148-NAND.patch @@ -0,0 +1,11 @@ +--- a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts ++++ b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts +@@ -157,6 +157,8 @@ + + nand-ecc-strength = <4>; + nand-bus-width = <8>; ++ ++ linux,part-probe = "qcom-smem"; + }; + }; + }; diff --git a/target/linux/ipq806x/patches-4.4/300-arch-arm-force-ZRELADDR-on-arch-qcom.patch b/target/linux/ipq806x/patches-4.4/300-arch-arm-force-ZRELADDR-on-arch-qcom.patch new file mode 100644 index 0000000..c0281ff --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/300-arch-arm-force-ZRELADDR-on-arch-qcom.patch @@ -0,0 +1,62 @@ +From b12e230f09d4481424e6a5d7e2ae566b6954e83f Mon Sep 17 00:00:00 2001 +From: Mathieu Olivari +Date: Wed, 29 Apr 2015 15:21:46 -0700 +Subject: [PATCH] HACK: arch: arm: force ZRELADDR on arch-qcom + +ARCH_QCOM is using the ARCH_MULTIPLATFORM option, as now recommended +on most ARM architectures. This automatically calculate ZRELADDR by +masking PHYS_OFFSET with 0xf8000000. + +However, on IPQ806x, the first ~20MB of RAM is reserved for the hardware +network accelerators, and the bootloader removes this section from the +layout passed from the ATAGS (when used). + +For newer bootloader, when DT is used, this is not a problem, we just +reserve this memory in the device tree. But if the bootloader doesn't +have DT support, then ATAGS have to be used. In this case, the ARM +decompressor will position the kernel in this low mem, which will not be +in the RAM section mapped by the bootloader, which means the kernel will +freeze in the middle of the boot process trying to map the memory. + +As a work around, this patch allows disabling AUTO_ZRELADDR when +ARCH_QCOM is selected. It makes the zImage usage possible on bootloaders +which don't support device-tree, which is the case on certain early +IPQ806x based designs. + +Signed-off-by: Mathieu Olivari +--- + arch/arm/Kconfig | 2 +- + arch/arm/Makefile | 2 ++ + arch/arm/mach-qcom/Makefile.boot | 1 + + 3 files changed, 4 insertions(+), 1 deletion(-) + create mode 100644 arch/arm/mach-qcom/Makefile.boot + +--- a/arch/arm/Kconfig ++++ b/arch/arm/Kconfig +@@ -323,7 +323,7 @@ + select ARCH_WANT_OPTIONAL_GPIOLIB + select ARM_HAS_SG_CHAIN + select ARM_PATCH_PHYS_VIRT +- select AUTO_ZRELADDR ++ select AUTO_ZRELADDR if !ARCH_QCOM + select CLKSRC_OF + select COMMON_CLK + select GENERIC_CLOCKEVENTS +--- a/arch/arm/Makefile ++++ b/arch/arm/Makefile +@@ -256,9 +256,11 @@ + else + MACHINE := + endif ++ifeq ($(CONFIG_ARCH_QCOM),) + ifeq ($(CONFIG_ARCH_MULTIPLATFORM),y) + MACHINE := + endif ++endif + + machdirs := $(patsubst %,arch/arm/mach-%/,$(machine-y)) + platdirs := $(patsubst %,arch/arm/plat-%/,$(sort $(plat-y))) +--- /dev/null ++++ b/arch/arm/mach-qcom/Makefile.boot +@@ -0,0 +1 @@ ++zreladdr-y+= 0x42208000 diff --git a/target/linux/ipq806x/patches-4.4/302-mtd-qcom-smem-rename-rootfs-ubi.patch b/target/linux/ipq806x/patches-4.4/302-mtd-qcom-smem-rename-rootfs-ubi.patch new file mode 100644 index 0000000..8890a91 --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/302-mtd-qcom-smem-rename-rootfs-ubi.patch @@ -0,0 +1,13 @@ +--- a/drivers/mtd/qcom_smem_part.c ++++ b/drivers/mtd/qcom_smem_part.c +@@ -189,6 +189,10 @@ static int parse_qcom_smem_partitions(st + m_part->size = le32_to_cpu(s_part->size) * (*smem_blksz); + m_part->offset = le32_to_cpu(s_part->start) * (*smem_blksz); + ++ /* "rootfs" conflicts with OpenWrt auto mounting */ ++ if (mtd_type_is_nand(master) && !strcmp(m_part->name, "rootfs")) ++ m_part->name = "ubi"; ++ + /* + * The last SMEM partition may have its size marked as + * something like 0xffffffff, which means "until the end of the diff --git a/target/linux/ipq806x/patches-4.4/707-ARM-dts-qcom-add-mdio-nodes-to-ap148-db149.patch b/target/linux/ipq806x/patches-4.4/707-ARM-dts-qcom-add-mdio-nodes-to-ap148-db149.patch new file mode 100644 index 0000000..625ff0a --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/707-ARM-dts-qcom-add-mdio-nodes-to-ap148-db149.patch @@ -0,0 +1,146 @@ +From e81de9d28bd0421c236df322872e64edf4ee1852 Mon Sep 17 00:00:00 2001 +From: Mathieu Olivari +Date: Mon, 11 May 2015 16:32:09 -0700 +Subject: [PATCH 7/8] ARM: dts: qcom: add mdio nodes to ap148 & db149 + +Signed-off-by: Mathieu Olivari +--- + arch/arm/boot/dts/qcom-ipq8064-ap148.dts | 40 ++++++++++++++++++++++++++- + arch/arm/boot/dts/qcom-ipq8064-db149.dts | 46 ++++++++++++++++++++++++++++++++ + 2 files changed, 85 insertions(+), 1 deletion(-) + +--- a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts ++++ b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts +@@ -19,8 +19,9 @@ + }; + }; + +- alias { ++ aliases { + serial0 = &uart4; ++ mdio-gpio0 = &mdio0; + }; + + chosen { +@@ -65,6 +66,15 @@ + bias-bus-hold; + }; + }; ++ ++ mdio0_pins: mdio0_pins { ++ mux { ++ pins = "gpio0", "gpio1"; ++ function = "gpio"; ++ drive-strength = <8>; ++ bias-disable; ++ }; ++ }; + }; + + gsbi at 16300000 { +@@ -160,6 +170,34 @@ + + linux,part-probe = "qcom-smem"; + }; ++ ++ mdio0: mdio { ++ compatible = "virtual,mdio-gpio"; ++ #address-cells = <1>; ++ #size-cells = <0>; ++ gpios = <&qcom_pinmux 1 0 &qcom_pinmux 0 0>; ++ pinctrl-0 = <&mdio0_pins>; ++ pinctrl-names = "default"; ++ ++ phy0: ethernet-phy at 0 { ++ device_type = "ethernet-phy"; ++ reg = <0>; ++ qca,ar8327-initvals = < ++ 0x00004 0x7600000 /* PAD0_MODE */ ++ 0x00008 0x1000000 /* PAD5_MODE */ ++ 0x0000c 0x80 /* PAD6_MODE */ ++ 0x000e4 0xaa545 /* MAC_POWER_SEL */ ++ 0x000e0 0xc74164de /* SGMII_CTRL */ ++ 0x0007c 0x4e /* PORT0_STATUS */ ++ 0x00094 0x4e /* PORT6_STATUS */ ++ >; ++ }; ++ ++ phy4: ethernet-phy at 4 { ++ device_type = "ethernet-phy"; ++ reg = <4>; ++ }; ++ }; + }; + }; + +--- a/arch/arm/boot/dts/qcom-ipq8064-db149.dts ++++ b/arch/arm/boot/dts/qcom-ipq8064-db149.dts +@@ -16,6 +16,7 @@ + + alias { + serial0 = &uart2; ++ mdio-gpio0 = &mdio0; + }; + + chosen { +@@ -38,6 +39,15 @@ + bias-none; + }; + }; ++ ++ mdio0_pins: mdio0_pins { ++ mux { ++ pins = "gpio0", "gpio1"; ++ function = "gpio"; ++ drive-strength = <8>; ++ bias-disable; ++ }; ++ }; + }; + + gsbi2: gsbi at 12480000 { +@@ -140,5 +150,44 @@ + pcie2: pci at 1b900000 { + status = "ok"; + }; ++ ++ mdio0: mdio { ++ compatible = "virtual,mdio-gpio"; ++ #address-cells = <1>; ++ #size-cells = <0>; ++ gpios = <&qcom_pinmux 1 0 &qcom_pinmux 0 0>; ++ ++ pinctrl-0 = <&mdio0_pins>; ++ pinctrl-names = "default"; ++ ++ phy0: ethernet-phy at 0 { ++ device_type = "ethernet-phy"; ++ reg = <0>; ++ qca,ar8327-initvals = < ++ 0x00004 0x7600000 /* PAD0_MODE */ ++ 0x00008 0x1000000 /* PAD5_MODE */ ++ 0x0000c 0x80 /* PAD6_MODE */ ++ 0x000e4 0xaa545 /* MAC_POWER_SEL */ ++ 0x000e0 0xc74164de /* SGMII_CTRL */ ++ 0x0007c 0x4e /* PORT0_STATUS */ ++ 0x00094 0x4e /* PORT6_STATUS */ ++ >; ++ }; ++ ++ phy4: ethernet-phy at 4 { ++ device_type = "ethernet-phy"; ++ reg = <4>; ++ }; ++ ++ phy6: ethernet-phy at 6 { ++ device_type = "ethernet-phy"; ++ reg = <6>; ++ }; ++ ++ phy7: ethernet-phy at 7 { ++ device_type = "ethernet-phy"; ++ reg = <7>; ++ }; ++ }; + }; + }; diff --git a/target/linux/ipq806x/patches-4.4/708-ARM-dts-qcom-add-gmac-nodes-to-ipq806x-platforms.patch b/target/linux/ipq806x/patches-4.4/708-ARM-dts-qcom-add-gmac-nodes-to-ipq806x-platforms.patch new file mode 100644 index 0000000..691ebb6 --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/708-ARM-dts-qcom-add-gmac-nodes-to-ipq806x-platforms.patch @@ -0,0 +1,216 @@ +From cab1f4720e82f2e17eaeed9a9ad9e4f07c742977 Mon Sep 17 00:00:00 2001 +From: Mathieu Olivari +Date: Mon, 11 May 2015 12:29:18 -0700 +Subject: [PATCH 8/8] ARM: dts: qcom: add gmac nodes to ipq806x platforms + +Signed-off-by: Mathieu Olivari +--- + arch/arm/boot/dts/qcom-ipq8064-ap148.dts | 31 ++++++++++++ + arch/arm/boot/dts/qcom-ipq8064-db149.dts | 43 ++++++++++++++++ + arch/arm/boot/dts/qcom-ipq8064.dtsi | 86 ++++++++++++++++++++++++++++++++ + 3 files changed, 160 insertions(+) + +--- a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts ++++ b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts +@@ -75,6 +75,16 @@ + bias-disable; + }; + }; ++ ++ rgmii2_pins: rgmii2_pins { ++ mux { ++ pins = "gpio27", "gpio28", "gpio29", "gpio30", "gpio31", "gpio32", ++ "gpio51", "gpio52", "gpio59", "gpio60", "gpio61", "gpio62" ; ++ function = "rgmii2"; ++ drive-strength = <8>; ++ bias-disable; ++ }; ++ }; + }; + + gsbi at 16300000 { +@@ -198,6 +208,31 @@ + reg = <4>; + }; + }; ++ ++ gmac1: ethernet at 37200000 { ++ status = "ok"; ++ phy-mode = "rgmii"; ++ qcom,id = <1>; ++ ++ pinctrl-0 = <&rgmii2_pins>; ++ pinctrl-names = "default"; ++ ++ fixed-link { ++ speed = <1000>; ++ full-duplex; ++ }; ++ }; ++ ++ gmac2: ethernet at 37400000 { ++ status = "ok"; ++ phy-mode = "sgmii"; ++ qcom,id = <2>; ++ ++ fixed-link { ++ speed = <1000>; ++ full-duplex; ++ }; ++ }; + }; + }; + +--- a/arch/arm/boot/dts/qcom-ipq8064-db149.dts ++++ b/arch/arm/boot/dts/qcom-ipq8064-db149.dts +@@ -48,6 +48,14 @@ + bias-disable; + }; + }; ++ ++ rgmii0_pins: rgmii0_pins { ++ mux { ++ pins = "gpio2", "gpio66"; ++ drive-strength = <8>; ++ bias-disable; ++ }; ++ }; + }; + + gsbi2: gsbi at 12480000 { +@@ -189,5 +197,40 @@ + reg = <7>; + }; + }; ++ ++ gmac0: ethernet at 37000000 { ++ status = "ok"; ++ phy-mode = "rgmii"; ++ qcom,id = <0>; ++ phy-handle = <&phy4>; ++ ++ pinctrl-0 = <&rgmii0_pins>; ++ pinctrl-names = "default"; ++ }; ++ ++ gmac1: ethernet at 37200000 { ++ status = "ok"; ++ phy-mode = "sgmii"; ++ qcom,id = <1>; ++ ++ fixed-link { ++ speed = <1000>; ++ full-duplex; ++ }; ++ }; ++ ++ gmac2: ethernet at 37400000 { ++ status = "ok"; ++ phy-mode = "sgmii"; ++ qcom,id = <2>; ++ phy-handle = <&phy6>; ++ }; ++ ++ gmac3: ethernet at 37600000 { ++ status = "ok"; ++ phy-mode = "sgmii"; ++ qcom,id = <3>; ++ phy-handle = <&phy7>; ++ }; + }; + }; +--- a/arch/arm/boot/dts/qcom-ipq8064.dtsi ++++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi +@@ -763,6 +763,92 @@ + + status = "disabled"; + }; ++ ++ nss_common: syscon at 03000000 { ++ compatible = "syscon"; ++ reg = <0x03000000 0x0000FFFF>; ++ }; ++ ++ qsgmii_csr: syscon at 1bb00000 { ++ compatible = "syscon"; ++ reg = <0x1bb00000 0x000001FF>; ++ }; ++ ++ gmac0: ethernet at 37000000 { ++ device_type = "network"; ++ compatible = "qcom,ipq806x-gmac"; ++ reg = <0x37000000 0x200000>; ++ interrupts = ; ++ interrupt-names = "macirq"; ++ ++ qcom,nss-common = <&nss_common>; ++ qcom,qsgmii-csr = <&qsgmii_csr>; ++ ++ clocks = <&gcc GMAC_CORE1_CLK>; ++ clock-names = "stmmaceth"; ++ ++ resets = <&gcc GMAC_CORE1_RESET>; ++ reset-names = "stmmaceth"; ++ ++ status = "disabled"; ++ }; ++ ++ gmac1: ethernet at 37200000 { ++ device_type = "network"; ++ compatible = "qcom,ipq806x-gmac"; ++ reg = <0x37200000 0x200000>; ++ interrupts = ; ++ interrupt-names = "macirq"; ++ ++ qcom,nss-common = <&nss_common>; ++ qcom,qsgmii-csr = <&qsgmii_csr>; ++ ++ clocks = <&gcc GMAC_CORE2_CLK>; ++ clock-names = "stmmaceth"; ++ ++ resets = <&gcc GMAC_CORE2_RESET>; ++ reset-names = "stmmaceth"; ++ ++ status = "disabled"; ++ }; ++ ++ gmac2: ethernet at 37400000 { ++ device_type = "network"; ++ compatible = "qcom,ipq806x-gmac"; ++ reg = <0x37400000 0x200000>; ++ interrupts = ; ++ interrupt-names = "macirq"; ++ ++ qcom,nss-common = <&nss_common>; ++ qcom,qsgmii-csr = <&qsgmii_csr>; ++ ++ clocks = <&gcc GMAC_CORE3_CLK>; ++ clock-names = "stmmaceth"; ++ ++ resets = <&gcc GMAC_CORE3_RESET>; ++ reset-names = "stmmaceth"; ++ ++ status = "disabled"; ++ }; ++ ++ gmac3: ethernet at 37600000 { ++ device_type = "network"; ++ compatible = "qcom,ipq806x-gmac"; ++ reg = <0x37600000 0x200000>; ++ interrupts = ; ++ interrupt-names = "macirq"; ++ ++ qcom,nss-common = <&nss_common>; ++ qcom,qsgmii-csr = <&qsgmii_csr>; ++ ++ clocks = <&gcc GMAC_CORE4_CLK>; ++ clock-names = "stmmaceth"; ++ ++ resets = <&gcc GMAC_CORE4_RESET>; ++ reset-names = "stmmaceth"; ++ ++ status = "disabled"; ++ }; + }; + + sfpb_mutex: sfpb-mutex { diff --git a/target/linux/ipq806x/patches-4.4/709-spi-qup-Fix-fifo-and-dma-support-for-IPQ806x.patch b/target/linux/ipq806x/patches-4.4/709-spi-qup-Fix-fifo-and-dma-support-for-IPQ806x.patch new file mode 100644 index 0000000..8c4718e --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/709-spi-qup-Fix-fifo-and-dma-support-for-IPQ806x.patch @@ -0,0 +1,134 @@ +From 16d2871830ff3fe12a6bff582549a9264adff278 Mon Sep 17 00:00:00 2001 +From: Ram Chandra Jangir +Date: Tue, 10 May 2016 20:19:31 +0530 +Subject: [PATCH] spi: qup: Fix fifo and dma support for IPQ806x + +Signed-off-by: Ram Chandra Jangir +--- + drivers/spi/spi-qup.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++++-- + 1 file changed, 52 insertions(+), 2 deletions(-) + +diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c +index 810a7fa..0808017 100644 +--- a/drivers/spi/spi-qup.c ++++ b/drivers/spi/spi-qup.c +@@ -24,6 +24,7 @@ + #include + #include + #include ++#include + + #define QUP_CONFIG 0x0000 + #define QUP_STATE 0x0004 +@@ -152,6 +153,7 @@ struct spi_qup { + int use_dma; + struct dma_slave_config rx_conf; + struct dma_slave_config tx_conf; ++ int mode; + }; + + +@@ -370,7 +372,8 @@ static int spi_qup_do_pio(struct spi_master *master, struct spi_transfer *xfer) + return ret; + } + +- spi_qup_fifo_write(qup, xfer); ++ if (qup->mode == QUP_IO_M_MODE_FIFO) ++ spi_qup_fifo_write(qup, xfer); + + return 0; + } +@@ -448,6 +451,7 @@ spi_qup_get_mode(struct spi_master *master, struct spi_transfer *xfer) + { + struct spi_qup *qup = spi_master_get_devdata(master); + u32 mode; ++ size_t dma_align = dma_get_cache_alignment(); + + qup->w_size = 4; + +@@ -458,6 +462,14 @@ spi_qup_get_mode(struct spi_master *master, struct spi_transfer *xfer) + + qup->n_words = xfer->len / qup->w_size; + ++ if (!IS_ERR_OR_NULL(master->dma_rx) && ++ IS_ALIGNED((size_t)xfer->tx_buf, dma_align) && ++ IS_ALIGNED((size_t)xfer->rx_buf, dma_align) && ++ !is_vmalloc_addr(xfer->tx_buf) && ++ !is_vmalloc_addr(xfer->rx_buf) && ++ (xfer->len > 3*qup->in_blk_sz)) ++ qup->use_dma = 1; ++ + if (qup->n_words <= (qup->in_fifo_sz / sizeof(u32))) + mode = QUP_IO_M_MODE_FIFO; + else +@@ -491,7 +503,7 @@ static int spi_qup_io_config(struct spi_device *spi, struct spi_transfer *xfer) + return -EIO; + } + +- mode = spi_qup_get_mode(spi->master, xfer); ++ controller->mode = mode = spi_qup_get_mode(spi->master, xfer); + n_words = controller->n_words; + + if (mode == QUP_IO_M_MODE_FIFO) { +@@ -500,6 +512,7 @@ static int spi_qup_io_config(struct spi_device *spi, struct spi_transfer *xfer) + /* must be zero for FIFO */ + writel_relaxed(0, controller->base + QUP_MX_INPUT_CNT); + writel_relaxed(0, controller->base + QUP_MX_OUTPUT_CNT); ++ controller->use_dma = 0; + } else if (!controller->use_dma) { + writel_relaxed(n_words, controller->base + QUP_MX_INPUT_CNT); + writel_relaxed(n_words, controller->base + QUP_MX_OUTPUT_CNT); +@@ -750,6 +763,38 @@ err_tx: + return ret; + } + ++static void spi_qup_set_cs(struct spi_device *spi, bool val) ++{ ++ struct spi_qup *controller; ++ u32 spi_ioc; ++ u32 spi_ioc_orig; ++ ++ controller = spi_master_get_devdata(spi->master); ++ spi_ioc = readl_relaxed(controller->base + SPI_IO_CONTROL); ++ spi_ioc_orig = spi_ioc; ++ if (!val) ++ spi_ioc |= SPI_IO_C_FORCE_CS; ++ else ++ spi_ioc &= ~SPI_IO_C_FORCE_CS; ++ ++ if (spi_ioc != spi_ioc_orig) ++ writel_relaxed(spi_ioc, controller->base + SPI_IO_CONTROL); ++} ++ ++static int spi_qup_setup(struct spi_device *spi) ++{ ++ if (spi->cs_gpio >= 0) { ++ if (spi->mode & SPI_CS_HIGH) ++ gpio_set_value(spi->cs_gpio, 0); ++ else ++ gpio_set_value(spi->cs_gpio, 1); ++ ++ udelay(10); ++ } ++ ++ return 0; ++} ++ + static int spi_qup_probe(struct platform_device *pdev) + { + struct spi_master *master; +@@ -846,6 +891,11 @@ static int spi_qup_probe(struct platform_device *pdev) + if (of_device_is_compatible(dev->of_node, "qcom,spi-qup-v1.1.1")) + controller->qup_v1 = 1; + ++ if (!controller->qup_v1) ++ master->set_cs = spi_qup_set_cs; ++ else ++ master->setup = spi_qup_setup; ++ + spin_lock_init(&controller->lock); + init_completion(&controller->done); + +-- +2.7.2 + diff --git a/target/linux/ipq806x/patches-4.4/710-watchdog-qcom-set-WDT_BARK_TIME-register-offset-to-o.patch b/target/linux/ipq806x/patches-4.4/710-watchdog-qcom-set-WDT_BARK_TIME-register-offset-to-o.patch new file mode 100644 index 0000000..7573c96 --- /dev/null +++ b/target/linux/ipq806x/patches-4.4/710-watchdog-qcom-set-WDT_BARK_TIME-register-offset-to-o.patch @@ -0,0 +1,43 @@ +From abc9f55079169806bcc31f29ec27f7df11c6184c Mon Sep 17 00:00:00 2001 +From: Ram Chandra Jangir +Date: Thu, 4 Feb 2016 12:41:56 +0530 +Subject: [PATCH 2/2] watchdog: qcom: set WDT_BARK_TIME register offset to one + second less of bite time + +Currently WDT_BARK_TIME register offset is not configured with bark +timeout during wdt_start,and it is taking bark timeout's default value. +For some versions of TZ (secure mode) will consider a BARK the same +as BITE and reset the board. + +So instead let's just configure the BARK time to be less than a second +of the bite timeout so the board does not reset in this scenario + +Change-Id: Ie09850ad7e0470ed721e6924911ca2a81fd9ff8a +Signed-off-by: Ram Chandra Jangir +--- + drivers/watchdog/qcom-wdt.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/drivers/watchdog/qcom-wdt.c b/drivers/watchdog/qcom-wdt.c +index 773dcfa..002274a 100644 +--- a/drivers/watchdog/qcom-wdt.c ++++ b/drivers/watchdog/qcom-wdt.c +@@ -22,6 +22,7 @@ + + #define WDT_RST 0x38 + #define WDT_EN 0x40 ++#define WDT_BARK_TIME 0x4C + #define WDT_BITE_TIME 0x5C + + struct qcom_wdt { +@@ -44,6 +45,7 @@ static int qcom_wdt_start(struct watchdog_device *wdd) + + writel(0, wdt->base + WDT_EN); + writel(1, wdt->base + WDT_RST); ++ writel((wdd->timeout - 1) * wdt->rate, wdt->base + WDT_BARK_TIME); + writel(wdd->timeout * wdt->rate, wdt->base + WDT_BITE_TIME); + writel(1, wdt->base + WDT_EN); + return 0; +-- +2.7.2 + -- 2.7.2 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From merker at debian.org Sat May 21 07:39:37 2016 From: merker at debian.org (Karsten Merker) Date: Sat, 21 May 2016 13:39:37 +0200 Subject: [OpenWrt-Devel] Dnsmasq DHCP service works only on second start Message-ID: <20160521113937.GA9832@excalibur.cnev.de> Hello, I have upgraded a router to the current OpenWRT git head (svn rev. 49377, git commit cda52dcb329e026) and now experience a strange effect: After the router has booted, dnsmasq runs and provides DNS service, but it doesn't provide DHCP service. It doesn't bind on the bootps port and there is nothing about dnsmasq-dhcp in the log. If I then run "/etc/init.d/dnsmasq stop; /etc/init.d/dnsmasq start", it binds on the bootps port, lists the DHCP ranges in the log and everything works as it should: [Note: the actual addresses in the config have been replaced by letters for privacy reasons] -----8<----------8<----------8<----------8<----------8<----------8<----- root at router:/# netstat -ap |grep dnsmasq tcp 0 0 0.0.0.0:domain 0.0.0.0:* LISTEN 1530/dnsmasq tcp 0 0 :::domain :::* LISTEN 1530/dnsmasq udp 0 0 0.0.0.0:domain 0.0.0.0:* 1530/dnsmasq udp 0 0 0.0.0.0:tftp 0.0.0.0:* 1530/dnsmasq udp 0 0 :::domain :::* 1530/dnsmasq udp 0 0 :::tftp :::* 1530/dnsmasq unix 2 [ ] DGRAM 2749 1530/dnsmasq root at router:/# /etc/init.d/dnsmasq stop root at router:/# /etc/init.d/dnsmasq start root at router:/# netstat -ap |grep dnsmasq tcp 0 0 0.0.0.0:domain 0.0.0.0:* LISTEN 1964/dnsmasq tcp 0 0 :::domain :::* LISTEN 1964/dnsmasq udp 0 0 0.0.0.0:domain 0.0.0.0:* 1964/dnsmasq udp 0 0 0.0.0.0:bootps 0.0.0.0:* 1964/dnsmasq udp 0 0 0.0.0.0:tftp 0.0.0.0:* 1964/dnsmasq udp 0 0 :::domain :::* 1964/dnsmasq udp 0 0 :::tftp :::* 1964/dnsmasq unix 2 [ ] DGRAM 3641 1964/dnsmasq root at router:/# cat /var/etc/dnsmasq.conf # auto-generated config file from /etc/config/dhcp conf-file=/etc/dnsmasq.conf domain-needed filterwin2k localise-queries read-ethers bogus-priv expand-hosts enable-tftp server=/lan/ dhcp-leasefile=/tmp/dhcp.leases resolv-file=/tmp/resolv.conf.auto tftp-root=/usbstorage/tftp/ stop-dns-rebind dhcp-broadcast=tag:needs-broadcast addn-hosts=/tmp/hosts conf-dir=/tmp/dnsmasq.d user=dnsmasq group=dnsmasq dhcp-range=lan,a.b.c.d,a.b.c.e,255.255.255.0,12h no-dhcp-interface=eth0.2 dhcp-range=foo,m.n.o.p,m.n.o.q,255.255.255.0,12h dhcp-range=bar,v.w.x.y,v.w.x.z,255.255.255.0,1h -----8<----------8<----------8<----------8<----------8<----------8<----- (eth0.2 is the WAN interface) Syslog entries on boot: -----8<----------8<----------8<----------8<----------8<----------8<----- daemon.info dnsmasq[1530]: started, version 2.75 cachesize 150 daemon.info dnsmasq[1530]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-detect inotify daemon.info dnsmasq-tftp[1530]: TFTP root is /usbstorage/tftp/ daemon.info dnsmasq[1530]: using local addresses only for domain lan daemon.info dnsmasq[1530]: reading /tmp/resolv.conf.auto daemon.info dnsmasq[1530]: using local addresses only for domain lan daemon.info dnsmasq[1530]: using nameserver xxx.xxx.xxx.xxx#53 daemon.info dnsmasq[1530]: using nameserver yyy.yyy.yyy.yyy#53 daemon.info dnsmasq[1530]: read /etc/hosts - 12 addresses daemon.info dnsmasq[1530]: read /tmp/hosts/dhcp - 0 addresses -----8<----------8<----------8<----------8<----------8<----------8<----- Syslog entries on dnsmasq restart: -----8<----------8<----------8<----------8<----------8<----------8<----- daemon.info dnsmasq[1530]: exiting on receipt of SIGTERM daemon.info dnsmasq[1964]: started, version 2.75 cachesize 150 daemon.info dnsmasq[1964]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-detect inotify daemon.info dnsmasq-dhcp[1964]: DHCP, IP range v.w.x.y -- v.w.x.z, lease time 1h daemon.info dnsmasq-dhcp[1964]: DHCP, IP range m.n.o.p -- m.n.o.q, lease time 12h daemon.info dnsmasq-dhcp[1964]: DHCP, IP range a.b.c.d -- a.b.c.e, lease time 12h daemon.info dnsmasq-tftp[1964]: TFTP root is /usbstorage/tftp/ daemon.info dnsmasq[1964]: using local addresses only for domain lan daemon.info dnsmasq[1964]: reading /tmp/resolv.conf.auto daemon.info dnsmasq[1964]: using local addresses only for domain lan daemon.info dnsmasq[1964]: using nameserver xxx.xxx.xxx.xxx#53 daemon.info dnsmasq[1964]: using nameserver yyy.yyy.yyy.yyy#53 daemon.info dnsmasq[1964]: read /etc/hosts - 12 addresses daemon.info dnsmasq[1964]: read /tmp/hosts/dhcp - 0 addresses daemon.info dnsmasq-dhcp[1964]: read /etc/ethers - 11 addresses -----8<----------8<----------8<----------8<----------8<----------8<----- I don't know where the empty lines in /var/etc/dnsmasq.conf come from, but they are there both on the first and on the second start, so I suppose that they don't matter. The router was previously running an older Designated Driver build (IIRC from end of march/beginning of april) that has worked flawlessly. Unfortunately I haven't noted the previous build revision. The config is unchanged between the old and the new build. I have skimmed through the commit logs but haven't found anything that would explain the change in behaviour. Does anybody have an idea what could have gone wrong here? Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten f?r Zwecke der Werbung sowie der Markt- oder Meinungsforschung. _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From hauke at hauke-m.de Sat May 21 09:15:47 2016 From: hauke at hauke-m.de (Hauke Mehrtens) Date: Sat, 21 May 2016 15:15:47 +0200 Subject: [OpenWrt-Devel] OpenWrt summit by prpl In-Reply-To: References: <57350762.9050801@hauke-m.de> <57358D21.40801@ninux.org> Message-ID: <57405F83.6030204@hauke-m.de> On 05/16/2016 06:40 PM, Eric Schultz wrote: > Federico, > > I don't want to speak for Hauke but I think he meant that that we have > an event at ELCE this year and then plan on another at Battlemesh next year Yes, you are correct. ;-) > I personally think that's the best idea all around. I know prpl members > have expressed lots of positive feedback on the idea of ELCE to Art and > he's gotten very solid feedback from industry because it's so convenient > for them. Planning on Battlemesh as well (with Battlemesh's approval of > course) then brings some of the interested industry members into contact > with a more community focused event. Hopefully that will build some new > bridges and relationships. I think the combination is a win-win. Hauke > Eric > > On Fri, May 13, 2016 at 3:15 AM, Nemesis > wrote: > > Hi everyone, > > I have been at the event in Dublin last year with a colleague. > The event was really interesting from a technical point of view and we > really missed such an event focused on OpenWRT and the various > applications & services one can build with it. > > It would be good to have more communities to participate in such an > event, and it would be awesome if the most active developers would have > a leading role in organizing it. > > Hauke, one note regarding co-location, you wrote: "I would like to see > it co located with the ELCE and the Battlemesh next year." > > But I believe the Battlemesh next year won't be co located with ELCE, > did you mean the Battlemesh or ELCE? > > Federico > > > > > On 05/13/2016 12:44 AM, Hauke Mehrtens wrote: > > Hi, > > > > When I use OpenWrt in this mail, I mean OpenWrt and LEDE, I hope > we come > > to a solution in the next days on this. > > > > prpl wants to organize an OpenWrt summit again. Their goal is to bring > > the community, industry and developers together. Currently this is in > > planing and I want to know what should happen so that more developers > > and more members of the community would come to such an event. > > > > There are different ideas on how to organize such an event: > > 1. prpl organizes an event co located with the Embedded Linux > conference > > this October in Berlin. > > 2. prpl organizes an event co located with Battlemesh next year in > May. > > 3. Some people from OpenWrt organize an event in Prague at CZ.NIC. > > CZ.NIC would provide a location and local logistics, prpl could help > > with finance. > > > > It is also possible to do more than one solution or combine them. > > > > Are there some people interested in organizing this by themselfs with > > the help of CZ.NIC, then we could go with this solution? > > If nobody is interested in organizing this I would like to see it co > > located with the ELCE and the Battlemesh next year. > > > > No final name for this event was chosen. The current suggestion is > > "OpenWrt summit by prpl" or something similar. > > > > Are there any comments on this? > > > > Hauke > > _______________________________________________ > > openwrt-devel mailing list > > openwrt-devel at lists.openwrt.org > > > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > > > > > -- > Eric Schultz, Community Manager, prpl Foundation > http://www.prplfoundation.org > eschultz at prplfoundation.org > cell: 920-539-0404 > skype: ericschultzwi > @EricPrpl _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From leitec at staticky.com Sat May 21 18:34:03 2016 From: leitec at staticky.com (Claudio Leite) Date: Sat, 21 May 2016 18:34:03 -0400 Subject: [OpenWrt-Devel] [PATCH RESEND] mvebu: configure switch on WRT1200AC and WRT1900ACv2/S Message-ID: <1463870043-21947-1-git-send-email-leitec@staticky.com> Also collapses the three identical configurations into one block. Signed-off-by: Claudio Leite --- target/linux/mvebu/base-files/etc/board.d/02_network | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/target/linux/mvebu/base-files/etc/board.d/02_network b/target/linux/mvebu/base-files/etc/board.d/02_network index f81d0ac..8f633c9 100755 --- a/target/linux/mvebu/base-files/etc/board.d/02_network +++ b/target/linux/mvebu/base-files/etc/board.d/02_network @@ -11,14 +11,12 @@ board_config_update board=$(mvebu_board_name) case "$board" in -armada-385-linksys-caiman) - ucidef_set_interfaces_lan_wan "eth1" "eth0" - ;; -armada-385-linksys-cobra) - ucidef_set_interfaces_lan_wan "eth1" "eth0" - ;; +armada-385-linksys-caiman|\ +armada-385-linksys-cobra|\ armada-385-linksys-shelby) ucidef_set_interfaces_lan_wan "eth1" "eth0" + ucidef_add_switch "switch0" \ + "0:lan:4" "1:lan:3" "2:lan:2" "3:lan:1" "6 at eth1" "4:wan" "5 at eth0" ;; armada-xp-linksys-mamba) ucidef_set_interfaces_lan_wan "eth0" "eth1" -- 2.1.4 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From n.mavrogiannopoulos at gmail.com Sun May 22 11:53:05 2016 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Sun, 22 May 2016 17:53:05 +0200 Subject: [OpenWrt-Devel] netifd: adding default route + route via previous default route In-Reply-To: References: <1463213916.22808.5.camel@gmail.com> <1463310849.16936.0.camel@gmail.com> Message-ID: <1463932385.11656.2.camel@gmail.com> On Sun, 2016-05-15 at 20:50 +0800, Yousong Zhou wrote: > > > I remember `proto_add_host_dependency` can be used to instruct > > > netifd > > > to setup such a route.??But it looks like the relevant code for > > > openconnect.sh is now commented out. > > It was causing an infinite loop, and I could not understand through > > code what the add_host_dependency was supposed to do. Do you have > > any > > information about this function? > `proto_add_host_dependency` takes 3 arguments. > > ?- The 1st is the logical interface name we are adding dependency for > ?- The 2nd is the host the above interface will depend on > ?- The 3rd is also a logical interface name.??It's optional and is > for > explicitly specifying which logical interface the 1st argument > depends on. > > If the 3rd argument is not given, netifd will try to find the logical > interface which provides route to to the specified host (2nd > argument) > and a host route will be available.??The 1st logical interface will > also be added to the list of "users" of that logical interface and > will be notified of it's up/down/update > event. > I guess the problem with openconnect.sh may be that the 3rd argument > was using the incorrect type.??Is that `vpn-$config` meant to be a > linux system interface name???We can try just not passing the 3rd > argument and see how it works. That was most helpful, thank you. The issue seems to be addressed now. regards, Nikos _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From linus.luessing at c0d3.blue Sun May 22 16:33:48 2016 From: linus.luessing at c0d3.blue (=?UTF-8?q?Linus=20L=C3=BCssing?=) Date: Sun, 22 May 2016 22:33:48 +0200 Subject: [OpenWrt-Devel] [PATCH netifd] bridge: make learning and unicast-flood configurable per bridge port Message-ID: <1463949228-18794-1-git-send-email-linus.luessing@c0d3.blue> Tuning these two options allows a more fine grained configuration of the forwarding database (fdb) of a bridge. The former allows to enable or disable the learning of the presence of MAC addresses behind a bridge port. (default: enabled on all ports) The latter allows to tune the behaviour in case a destination MAC address of a frame is unknown to the fdb, like only flooding on specific ports or not flooding on any port. (default: flood on all ports, except incoming) This can be useful to create a dumb hub, for instance for monitoring purposes. Or in larger layer 2 mesh networks to avoid keeping redundant databases (e.g. with the batman-adv translation table). Signed-off-by: Linus L?ssing --- device.c | 18 ++++++++++++++++++ device.h | 6 ++++++ system-linux.c | 18 ++++++++++++++++++ 3 files changed, 42 insertions(+) diff --git a/device.c b/device.c index 9344e1b..0e07615 100644 --- a/device.c +++ b/device.c @@ -51,6 +51,8 @@ static const struct blobmsg_policy dev_attrs[__DEV_ATTR_MAX] = { [DEV_ATTR_MULTICAST_TO_UNICAST] = { .name = "multicast_to_unicast", .type = BLOBMSG_TYPE_BOOL }, [DEV_ATTR_MULTICAST_ROUTER] = { .name = "multicast_router", .type = BLOBMSG_TYPE_INT32 }, [DEV_ATTR_MULTICAST] = { .name ="multicast", .type = BLOBMSG_TYPE_BOOL }, + [DEV_ATTR_LEARNING] = { .name ="learning", .type = BLOBMSG_TYPE_BOOL }, + [DEV_ATTR_UNICAST_FLOOD] = { .name ="unicast_flood", .type = BLOBMSG_TYPE_BOOL }, }; const struct uci_blob_param_list device_attr_list = { @@ -177,6 +179,8 @@ device_merge_settings(struct device *dev, struct device_settings *n) s->multicast : os->multicast; n->multicast_to_unicast = s->multicast_to_unicast; n->multicast_router = s->multicast_router; + n->learning = s->learning; + n->unicast_flood = s->unicast_flood; n->flags = s->flags | os->flags | os->valid_flags; } @@ -295,6 +299,16 @@ device_init_settings(struct device *dev, struct blob_attr **tb) s->flags |= DEV_OPT_MULTICAST; } + if ((cur = tb[DEV_ATTR_LEARNING])) { + s->learning = blobmsg_get_bool(cur); + s->flags |= DEV_OPT_LEARNING; + } + + if ((cur = tb[DEV_ATTR_UNICAST_FLOOD])) { + s->unicast_flood = blobmsg_get_bool(cur); + s->flags |= DEV_OPT_UNICAST_FLOOD; + } + device_set_disabled(dev, disabled); } @@ -939,6 +953,10 @@ device_dump_status(struct blob_buf *b, struct device *dev) blobmsg_add_u32(b, "multicast_router", st.multicast_router); if (st.flags & DEV_OPT_MULTICAST) blobmsg_add_u8(b, "multicast", st.multicast); + if (st.flags & DEV_OPT_LEARNING) + blobmsg_add_u8(b, "learning", st.learning); + if (st.flags & DEV_OPT_UNICAST_FLOOD) + blobmsg_add_u8(b, "unicast_flood", st.unicast_flood); } s = blobmsg_open_table(b, "statistics"); diff --git a/device.h b/device.h index ac77cfb..4a88c05 100644 --- a/device.h +++ b/device.h @@ -45,6 +45,8 @@ enum { DEV_ATTR_MULTICAST_TO_UNICAST, DEV_ATTR_MULTICAST_ROUTER, DEV_ATTR_MULTICAST, + DEV_ATTR_LEARNING, + DEV_ATTR_UNICAST_FLOOD, __DEV_ATTR_MAX, }; @@ -88,6 +90,8 @@ enum { DEV_OPT_MULTICAST_TO_UNICAST = (1 << 14), DEV_OPT_MULTICAST_ROUTER = (1 << 15), DEV_OPT_MULTICAST = (1 << 16), + DEV_OPT_LEARNING = (1 << 17), + DEV_OPT_UNICAST_FLOOD = (1 << 18), }; /* events broadcasted to all users of a device */ @@ -149,6 +153,8 @@ struct device_settings { bool multicast_to_unicast; unsigned int multicast_router; bool multicast; + bool learning; + bool unicast_flood; }; /* diff --git a/system-linux.c b/system-linux.c index 351a994..621f99b 100644 --- a/system-linux.c +++ b/system-linux.c @@ -372,6 +372,16 @@ static void system_bridge_set_startup_query_interval(struct device *dev, const c dev->ifname, val); } +static void system_bridge_set_learning(struct device *dev, const char *val) +{ + system_set_dev_sysctl("/sys/class/net/%s/brport/learning", dev->ifname, val); +} + +static void system_bridge_set_unicast_flood(struct device *dev, const char *val) +{ + system_set_dev_sysctl("/sys/class/net/%s/brport/unicast_flood", dev->ifname, val); +} + static int system_get_sysctl(const char *path, char *buf, const size_t buf_sz) { int fd = -1, ret = -1; @@ -648,6 +658,14 @@ int system_bridge_addif(struct device *bridge, struct device *dev) system_bridge_set_multicast_router(dev, buf, false); } + if (dev->settings.flags & DEV_OPT_LEARNING && + !dev->settings.learning) + system_bridge_set_learning(dev, "0"); + + if (dev->settings.flags & DEV_OPT_UNICAST_FLOOD && + !dev->settings.unicast_flood) + system_bridge_set_unicast_flood(dev, "0"); + return ret; } -- 1.7.10.4 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From me at vonger.cn Mon May 23 01:38:56 2016 From: me at vonger.cn (Vonger) Date: Mon, 23 May 2016 13:38:56 +0800 Subject: [OpenWrt-Devel] openwrt-devel Digest, Vol 125, Issue 91 References: Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From dedeckeh at gmail.com Mon May 23 08:30:57 2016 From: dedeckeh at gmail.com (Hans Dedecker) Date: Mon, 23 May 2016 14:30:57 +0200 Subject: [OpenWrt-Devel] [PATCH v2] busybox: sysntpd - Support for NTP servers received via DHCP(v6) Message-ID: <1464006657-13480-1-git-send-email-dedeckeh@gmail.com> The busybox ntpd utility currently uses ntp servers specified in uci. This patch allows the ntpd utility to use NTP servers received via DHCP(v6) Following uci parameters have been added: use_dhcp : enables NTP server config via DHCP(v6) dhcp_interface : use NTP servers received only on the specified DHCP(v6) interfaces; if empty all interfaces are considered Signed-off-by: Hans Dedecker --- v1 -> v2: Make jsonfilter dependant on BUSYBOX_CONFIG_NTPD Pipe output of network dump into jsonfilter use_dhcp is by default enabled Install fine grained procd interface triggers if dhcp_interface is configured package/utils/busybox/Makefile | 4 +-- package/utils/busybox/files/sysntpd | 57 +++++++++++++++++++++++++++++++++---- 2 files changed, 54 insertions(+), 7 deletions(-) diff --git a/package/utils/busybox/Makefile b/package/utils/busybox/Makefile index 24c064c..e5b55e0 100644 --- a/package/utils/busybox/Makefile +++ b/package/utils/busybox/Makefile @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=busybox PKG_VERSION:=1.24.2 -PKG_RELEASE:=1 +PKG_RELEASE:=2 PKG_FLAGS:=essential PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2 @@ -17,7 +17,7 @@ PKG_SOURCE_URL:=http://www.busybox.net/downloads \ http://distfiles.gentoo.org/distfiles/ PKG_MD5SUM:=2eaae519cac1143bcf583636a745381f -PKG_BUILD_DEPENDS:=BUSYBOX_USE_LIBRPC:librpc BUSYBOX_CONFIG_PAM:libpam +PKG_BUILD_DEPENDS:=BUSYBOX_USE_LIBRPC:librpc BUSYBOX_CONFIG_PAM:libpam +BUSYBOX_CONFIG_NTPD:jsonfilter PKG_BUILD_PARALLEL:=1 PKG_CHECK_FORMAT_SECURITY:=0 diff --git a/package/utils/busybox/files/sysntpd b/package/utils/busybox/files/sysntpd index f73bb83..6d44280 100755 --- a/package/utils/busybox/files/sysntpd +++ b/package/utils/busybox/files/sysntpd @@ -7,13 +7,34 @@ USE_PROCD=1 PROG=/usr/sbin/ntpd HOTPLUG_SCRIPT=/usr/sbin/ntpd-hotplug +get_dhcp_ntp_servers() { + local interfaces="$1" + local filter="*" + local interface ntpservers ntpserver + + for interface in $interfaces; do + [ "$filter" = "*" ] && filter="@.interface='$interface'" || filter="$filter, at .interface='$interface'" + done + + ntpservers=$(ubus call network.interface dump | jsonfilter -e "@.interface[$filter]['data']['ntpserver']") + + for ntpserver in $ntpservers; do + local duplicate=0 + local entry + for entry in $server; do + [ "$ntpserver" = "$entry" ] && duplicate=1 + done + [ "$duplicate" = 0 ] && server="$server $ntpserver" + done +} + validate_ntp_section() { uci_validate_section system timeserver "${1}" \ - 'server:list(host)' 'enabled:bool:1' 'enable_server:bool:0' + 'server:list(host)' 'enabled:bool:1' 'enable_server:bool:0' 'use_dhcp:bool:1' 'dhcp_interface:list(string)' } start_service() { - local server enabled enable_server peer + local server enabled enable_server use_dhcp dhcp_interface peer validate_ntp_section ntp || { echo "validation failed" @@ -22,6 +43,8 @@ start_service() { [ $enabled = 0 ] && return + [ $use_dhcp = 1 ] && get_dhcp_ntp_servers "$dhcp_interface" + [ -z "$server" ] && return procd_open_instance @@ -35,8 +58,32 @@ start_service() { procd_close_instance } -service_triggers() -{ - procd_add_reload_trigger "system" +service_triggers() { + local script name use_dhcp + + script=$(readlink -f "$initscript") + name=$(basename ${script:-$initscript}) + + procd_open_trigger + procd_add_config_trigger "config.change" "system" /etc/init.d/$name reload + + config_load system + config_get use_dhcp ntp use_dhcp 1 + + [ $use_dhcp = 1 ] && { + local dhcp_interface + config_get dhcp_interface ntp dhcp_interface + + if [ -n "$dhcp_interface" ]; then + for n in $dhcp_interface; do + procd_add_interface_trigger "interface.*" $n /etc/init.d/$name reload + done + else + procd_add_raw_trigger "interface.*" 1000 /etc/init.d/$name reload + fi + } + + procd_close_trigger + procd_add_validation validate_ntp_section } -- 1.9.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From shankar.unni+openwrt at gmail.com Mon May 23 10:19:23 2016 From: shankar.unni+openwrt at gmail.com (Shankar Unni) Date: Mon, 23 May 2016 07:19:23 -0700 Subject: [OpenWrt-Devel] Why does multiple instance dnsmasq work with jails but not without? In-Reply-To: <573C0A87.8020905@daniel.thecshore.com> References: <573C0A87.8020905@daniel.thecshore.com> Message-ID: IIRC, your patch did not specify different -x options to each instance to ensure that the PID files were written to separate files. That's at least one issue that occasionally caused races at startup. On Tue, May 17, 2016 at 11:24 PM, Daniel Dickinson wrote: > Hi all, > > I had a patch that I submitted to the openwrt list sometime back that > launched multiple instances of dnsmasq, so long as the instances were > either tied to specific, non-overlapping, interfaces, or used different > dns port, but at least in the case of different interfaces it only > worked (to my dismay) if jails were in use. Without jails only a single > instance of dnsmasq would start. > > Does anyone know why this is? > > (The use case is to serve a guest vlan with a dnsmasq instance that > forced the to use the opendns familyshield filter (since the point of > guest vlan is you don't necessarily know how far to trust the people on > the guest vlan (for a separate wifi SSID)). > > Regards, > > Daniel > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From Alexey.Brodkin at synopsys.com Mon May 23 10:46:21 2016 From: Alexey.Brodkin at synopsys.com (Alexey Brodkin) Date: Mon, 23 May 2016 17:46:21 +0300 Subject: [OpenWrt-Devel] [PATCH] package/util-linux: Fix libmount build under uClibc Message-ID: <1464014781-25347-1-git-send-email-abrodkin@synopsys.com> This fixes util-linux building with uClibc. Patch is taken as it is from Buildroot: https://git.busybox.net/buildroot/plain/package/util-linux/0001-Fix-libmount-build-under-uClibc.patch?id=baccb506a6feabf114623866568121f49712f5df Signed-off-by: Alexey Brodkin --- .../004-Fix-libmount-build-under-uClibc.patch | 153 +++++++++++++++++++++ 1 file changed, 153 insertions(+) create mode 100644 package/utils/util-linux/patches/004-Fix-libmount-build-under-uClibc.patch diff --git a/package/utils/util-linux/patches/004-Fix-libmount-build-under-uClibc.patch b/package/utils/util-linux/patches/004-Fix-libmount-build-under-uClibc.patch new file mode 100644 index 0000000..10cc3a5 --- /dev/null +++ b/package/utils/util-linux/patches/004-Fix-libmount-build-under-uClibc.patch @@ -0,0 +1,153 @@ +From 44d733203637666926964957af7af23429ddcecf Mon Sep 17 00:00:00 2001 +From: Gustavo Zacarias +Date: Mon, 18 Apr 2016 09:58:56 -0300 +Subject: [PATCH] Fix libmount build under uClibc + +See https://bugs.gentoo.org/show_bug.cgi?id=406303 +http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-apps/util-linux/files/util-linux-2.21.1-no-printf-alloc.patch?revision=1.2 + +[Gustavo: converted to git format for 2.28] + +Signed-off-by: Gustavo Zacarias +--- + configure.ac | 1 - + libmount/src/tab_parse.c | 52 ++++++++++++++++++++++++++++++++++++++++++++++++ + 2 files changed, 52 insertions(+), 1 deletion(-) + +diff --git a/configure.ac b/configure.ac +index 5a00403..3422f11 100644 +--- a/configure.ac ++++ b/configure.ac +@@ -948,7 +948,6 @@ AC_ARG_ENABLE([libmount], + ) + UL_BUILD_INIT([libmount]) + UL_REQUIRES_BUILD([libmount], [libblkid]) +-UL_REQUIRES_HAVE([libmount], [scanf_alloc_modifier], [scanf string alloc modifier]) + AM_CONDITIONAL([BUILD_LIBMOUNT], [test "x$build_libmount" = xyes]) + AM_CONDITIONAL([BUILD_LIBMOUNT_TESTS], [test "x$build_libmount" = xyes -a "x$enable_static" = xyes]) + AS_IF([test "x$build_libmount" = xyes], [ +diff --git a/libmount/src/tab_parse.c b/libmount/src/tab_parse.c +index 3f5e14a..2ff1795 100644 +--- a/libmount/src/tab_parse.c ++++ b/libmount/src/tab_parse.c +@@ -39,6 +39,10 @@ static void parser_cleanup(struct libmnt_parser *pa) + memset(pa, 0, sizeof(*pa)); + } + ++#ifndef HAVE_SCANF_MS_MODIFIER ++# define UL_SCNsA "%s" ++#endif ++ + static int next_number(char **s, int *num) + { + char *end = NULL; +@@ -69,16 +73,31 @@ static int mnt_parse_table_line(struct libmnt_fs *fs, char *s) + int rc, n = 0, xrc; + char *src = NULL, *fstype = NULL, *optstr = NULL; + ++#ifndef HAVE_SCANF_MS_MODIFIER ++ size_t len = strlen(s) + 1; ++ src = malloc(len); ++ fstype = malloc(len); ++ fs->target = malloc(len); ++ optstr = malloc(len); ++#endif ++ + rc = sscanf(s, UL_SCNsA" " /* (1) source */ + UL_SCNsA" " /* (2) target */ + UL_SCNsA" " /* (3) FS type */ + UL_SCNsA" " /* (4) options */ + "%n", /* byte count */ + ++#ifdef HAVE_SCANF_MS_MODIFIER + &src, + &fs->target, + &fstype, + &optstr, ++#else ++ src, ++ fs->target, ++ fstype, ++ optstr, ++#endif + &n); + xrc = rc; + +@@ -144,6 +163,16 @@ static int mnt_parse_mountinfo_line(struct libmnt_fs *fs, char *s) + unsigned int maj, min; + char *fstype = NULL, *src = NULL, *p; + ++#ifndef HAVE_SCANF_MS_MODIFIER ++ size_t len = strlen(s) + 1; ++ fs->root = malloc(len); ++ fs->target = malloc(len); ++ fs->vfs_optstr = malloc(len); ++ fs->fs_optstr = malloc(len); ++ fstype = malloc(len); ++ src = malloc(len); ++#endif ++ + rc = sscanf(s, "%d " /* (1) id */ + "%d " /* (2) parent */ + "%u:%u " /* (3) maj:min */ +@@ -155,9 +184,15 @@ static int mnt_parse_mountinfo_line(struct libmnt_fs *fs, char *s) + &fs->id, + &fs->parent, + &maj, &min, ++#ifdef HAVE_SCANF_MS_MODIFIER + &fs->root, + &fs->target, + &fs->vfs_optstr, ++#else ++ fs->root, ++ fs->target, ++ fs->vfs_optstr, ++#endif + &end); + + if (rc >= 7 && end > 0) +@@ -177,9 +212,15 @@ static int mnt_parse_mountinfo_line(struct libmnt_fs *fs, char *s) + UL_SCNsA" " /* (9) source */ + UL_SCNsA, /* (10) fs options (fs specific) */ + ++#ifdef HAVE_SCANF_MS_MODIFIER + &fstype, + &src, + &fs->fs_optstr); ++#else ++ fstype, ++ src, ++ fs->fs_optstr); ++#endif + + if (rc >= 10) { + size_t sz; +@@ -298,14 +339,25 @@ static int mnt_parse_swaps_line(struct libmnt_fs *fs, char *s) + int rc; + char *src = NULL; + ++#ifndef HAVE_SCANF_MS_MODIFIER ++ size_t len = strlen(s) + 1; ++ src = malloc(len); ++ fs->swaptype = malloc(len); ++#endif ++ + rc = sscanf(s, UL_SCNsA" " /* (1) source */ + UL_SCNsA" " /* (2) type */ + "%ju" /* (3) size */ + "%ju" /* (4) used */ + "%d", /* priority */ + ++#ifdef HAVE_SCANF_MS_MODIFIER + &src, + &fs->swaptype, ++#else ++ src, ++ fs->swaptype, ++#endif + &fsz, + &usz, + &fs->priority); +-- +2.7.3 + -- 2.5.0 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From Alexey.Brodkin at synopsys.com Mon May 23 10:48:05 2016 From: Alexey.Brodkin at synopsys.com (Alexey Brodkin) Date: Mon, 23 May 2016 17:48:05 +0300 Subject: [OpenWrt-Devel] [PATCH] toolchain: uClibc: Bump to the most recent version 1.0.14 Message-ID: <1464014885-29512-1-git-send-email-abrodkin@synopsys.com> This change updates uClibc version to the most recent 1.0.14 release. Signed-off-by: Alexey Brodkin --- toolchain/uClibc/Config.version | 2 +- toolchain/uClibc/common.mk | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/toolchain/uClibc/Config.version b/toolchain/uClibc/Config.version index b9c0627..3c1c54d 100644 --- a/toolchain/uClibc/Config.version +++ b/toolchain/uClibc/Config.version @@ -1,7 +1,7 @@ config UCLIBC_VERSION string depends on USE_UCLIBC - default "1.0.9" + default "1.0.14" config UCLIBC_VERSION_NG bool diff --git a/toolchain/uClibc/common.mk b/toolchain/uClibc/common.mk index 2828156..878bd76 100644 --- a/toolchain/uClibc/common.mk +++ b/toolchain/uClibc/common.mk @@ -16,7 +16,7 @@ CONFIG_DIR:=$(PATH_PREFIX)/config PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz LIBC_SO_VERSION:=$(PKG_VERSION) -PKG_MD5SUM=64bbe13301ffa6ba30c5c1ddec335583 +PKG_MD5SUM=8eed7f3635216142c1c5e122874b89c6 HOST_BUILD_DIR:=$(BUILD_DIR_TOOLCHAIN)/$(PKG_NAME)-$(PKG_VERSION) -- 2.5.0 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From Alexey.Brodkin at synopsys.com Mon May 23 13:57:28 2016 From: Alexey.Brodkin at synopsys.com (Alexey Brodkin) Date: Mon, 23 May 2016 20:57:28 +0300 Subject: [OpenWrt-Devel] [PATCH] _GNU_SOURCE should be defined for building vs uClibc Message-ID: <1464026248-23499-1-git-send-email-abrodkin@synopsys.com> In uClibc-ng O_PATH and O_DIRECTORY are only defined if _GNU_SOURCE is defined. So explicitly define _GNU_SOURCE in sources that use O_PATH and O_DIRECTORY. Without that extra definition that's what happens when building procd. utils/utils.c: ------------------------->8---------------------- .../openwrt/build_dir/target-arc_arc700_uClibc-1.0.14/procd-2016-05-19/utils/utils.c: In function 'patch_fd': .../openwrt/build_dir/target-arc_arc700_uClibc-1.0.14/procd-2016-05-19/utils/utils.c:168:22: error: 'O_PATH' undeclared (first use in this function) dfd = open("/dev", O_PATH|O_DIRECTORY); ^ .../openwrt/build_dir/target-arc_arc700_uClibc-1.0.14/procd-2016-05-19/utils/utils.c:168:22: note: each undeclared identifier is reported only once for each function it appears in .../openwrt/build_dir/target-arc_arc700_uClibc-1.0.14/procd-2016-05-19/utils/utils.c:168:29: error: 'O_DIRECTORY' undeclared (first use in this function) dfd = open("/dev", O_PATH|O_DIRECTORY); ^ CMakeFiles/init.dir/build.make:182: recipe for target 'CMakeFiles/init.dir/utils/utils.c.o' failed ------------------------->8---------------------- inittab.c: ------------------------->8---------------------- .../openwrt/build_dir/target-arc_arc700_uClibc-1.0.14/procd-2016-05-19/inittab.c: In function 'dev_exist': .../openwrt/build_dir/target-arc_arc700_uClibc-1.0.14/procd-2016-05-19/inittab.c:72:21: error: 'O_PATH' undeclared (first use in this function) dfd = open("/dev", O_PATH|O_DIRECTORY); ^ .../git/openwrt/build_dir/target-arc_arc700_uClibc-1.0.14/procd-2016-05-19/inittab.c:72:21: note: each undeclared identifier is reported only once for each function it appears in .../git/openwrt/build_dir/target-arc_arc700_uClibc-1.0.14/procd-2016-05-19/inittab.c:72:28: error: 'O_DIRECTORY' undeclared (first use in this function) dfd = open("/dev", O_PATH|O_DIRECTORY); ^ CMakeFiles/procd.dir/build.make:134: recipe for target 'CMakeFiles/procd.dir/inittab.c.o' failed make[6]: *** [CMakeFiles/procd.dir/inittab.c.o] Error 1 ------------------------->8---------------------- Signed-off-by: Alexey Brodkin Cc: Waldemar Brodkorb Cc: John Crispin Cc: Jo-Philipp Wich --- inittab.c | 1 + utils/utils.c | 1 + 2 files changed, 2 insertions(+) diff --git a/inittab.c b/inittab.c index 528396e..6dde11a 100644 --- a/inittab.c +++ b/inittab.c @@ -12,6 +12,7 @@ * GNU General Public License for more details. */ +#define _GNU_SOURCE #include #include #include diff --git a/utils/utils.c b/utils/utils.c index e2e3396..8f14aad 100644 --- a/utils/utils.c +++ b/utils/utils.c @@ -12,6 +12,7 @@ * GNU General Public License for more details. */ +#define _GNU_SOURCE #include #include #include "utils.h" -- 2.5.5 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From john at phrozen.org Mon May 23 14:03:11 2016 From: john at phrozen.org (John Crispin) Date: Mon, 23 May 2016 20:03:11 +0200 Subject: [OpenWrt-Devel] [LEDE-DEV] [PATCH] _GNU_SOURCE should be defined for building vs uClibc In-Reply-To: <1464026248-23499-1-git-send-email-abrodkin@synopsys.com> References: <1464026248-23499-1-git-send-email-abrodkin@synopsys.com> Message-ID: <079cf00c-fae8-f4d9-8963-681e8d287135@phrozen.org> Hi, is it really a gnu extension or is uclibc b0rked for these symbols ? John On 23/05/2016 19:57, Alexey Brodkin wrote: > In uClibc-ng O_PATH and O_DIRECTORY are only defined if _GNU_SOURCE is > defined. > > So explicitly define _GNU_SOURCE in sources that use O_PATH and > O_DIRECTORY. > > Without that extra definition that's what happens when building procd. > > utils/utils.c: > ------------------------->8---------------------- > .../openwrt/build_dir/target-arc_arc700_uClibc-1.0.14/procd-2016-05-19/utils/utils.c: > In function 'patch_fd': > .../openwrt/build_dir/target-arc_arc700_uClibc-1.0.14/procd-2016-05-19/utils/utils.c:168:22: > error: 'O_PATH' undeclared (first use in this function) > dfd = open("/dev", O_PATH|O_DIRECTORY); > ^ > .../openwrt/build_dir/target-arc_arc700_uClibc-1.0.14/procd-2016-05-19/utils/utils.c:168:22: > note: each undeclared identifier is reported only once for each function > it appears in > .../openwrt/build_dir/target-arc_arc700_uClibc-1.0.14/procd-2016-05-19/utils/utils.c:168:29: > error: 'O_DIRECTORY' undeclared (first use in this function) > dfd = open("/dev", O_PATH|O_DIRECTORY); > ^ > CMakeFiles/init.dir/build.make:182: recipe for target > 'CMakeFiles/init.dir/utils/utils.c.o' failed > ------------------------->8---------------------- > > inittab.c: > ------------------------->8---------------------- > .../openwrt/build_dir/target-arc_arc700_uClibc-1.0.14/procd-2016-05-19/inittab.c: > In function 'dev_exist': > .../openwrt/build_dir/target-arc_arc700_uClibc-1.0.14/procd-2016-05-19/inittab.c:72:21: > error: 'O_PATH' undeclared (first use in this function) > dfd = open("/dev", O_PATH|O_DIRECTORY); > ^ > .../git/openwrt/build_dir/target-arc_arc700_uClibc-1.0.14/procd-2016-05-19/inittab.c:72:21: > note: each undeclared identifier is reported only once for each function > it appears in > .../git/openwrt/build_dir/target-arc_arc700_uClibc-1.0.14/procd-2016-05-19/inittab.c:72:28: > error: 'O_DIRECTORY' undeclared (first use in this function) > dfd = open("/dev", O_PATH|O_DIRECTORY); > ^ > CMakeFiles/procd.dir/build.make:134: recipe for target > 'CMakeFiles/procd.dir/inittab.c.o' failed > make[6]: *** [CMakeFiles/procd.dir/inittab.c.o] Error 1 > ------------------------->8---------------------- > > Signed-off-by: Alexey Brodkin > Cc: Waldemar Brodkorb > Cc: John Crispin > Cc: Jo-Philipp Wich > --- > inittab.c | 1 + > utils/utils.c | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/inittab.c b/inittab.c > index 528396e..6dde11a 100644 > --- a/inittab.c > +++ b/inittab.c > @@ -12,6 +12,7 @@ > * GNU General Public License for more details. > */ > > +#define _GNU_SOURCE > #include > #include > #include > diff --git a/utils/utils.c b/utils/utils.c > index e2e3396..8f14aad 100644 > --- a/utils/utils.c > +++ b/utils/utils.c > @@ -12,6 +12,7 @@ > * GNU General Public License for more details. > */ > > +#define _GNU_SOURCE > #include > #include > #include "utils.h" > _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From nbd at nbd.name Mon May 23 14:11:34 2016 From: nbd at nbd.name (Felix Fietkau) Date: Mon, 23 May 2016 20:11:34 +0200 Subject: [OpenWrt-Devel] [LEDE-DEV] [PATCH] _GNU_SOURCE should be defined for building vs uClibc In-Reply-To: <079cf00c-fae8-f4d9-8963-681e8d287135@phrozen.org> References: <1464026248-23499-1-git-send-email-abrodkin@synopsys.com> <079cf00c-fae8-f4d9-8963-681e8d287135@phrozen.org> Message-ID: <8226360f-06ff-0104-bcd5-8bd3187a2bc5@nbd.name> On 2016-05-23 20:03, John Crispin wrote: > Hi, > is it really a gnu extension or is uclibc b0rked for these symbols ? At least O_PATH is Linux specific, so defining _GNU_SOURCE makes sense. - Felix _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From john at phrozen.org Mon May 23 14:37:13 2016 From: john at phrozen.org (John Crispin) Date: Mon, 23 May 2016 20:37:13 +0200 Subject: [OpenWrt-Devel] [LEDE-DEV] [PATCH] _GNU_SOURCE should be defined for building vs uClibc In-Reply-To: <20160523181259.GU26720@waldemar-brodkorb.de> References: <1464026248-23499-1-git-send-email-abrodkin@synopsys.com> <079cf00c-fae8-f4d9-8963-681e8d287135@phrozen.org> <20160523181259.GU26720@waldemar-brodkorb.de> Message-ID: <618582be-6dab-c1a4-cbca-73318011cf24@phrozen.org> On 23/05/2016 20:12, Waldemar Brodkorb wrote: > Hi John, > John Crispin wrote, > >> Hi, >> is it really a gnu extension or is uclibc b0rked for these symbols ? > > I think it isn't b0rked. > It was added for ARM GNU libc here under #ifdef __USE_GNU: > https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=sysdeps/unix/sysv/linux/arm/bits/fcntl.h;h=aa2d36ca80f0ca4c5793b28b3852ce60b5fe57ef;hp=6a5f89ad1f8bdf8a825fc1e55a84679a86349a6c;hb=adb252daea96e7e160553703d477b76ff6a7781e;hpb=01b5049d107460f5eca797eda983958d1a410ffd > > And later moved to generic fcntl.h file. So we are correct here or > at least compatible to GNU libc. > > best regards > Waldemar > ok, i'll merge it later today or in the morning John _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From mschiffer at universe-factory.net Mon May 23 20:01:48 2016 From: mschiffer at universe-factory.net (Matthias Schiffer) Date: Tue, 24 May 2016 02:01:48 +0200 Subject: [OpenWrt-Devel] [PATCH ubus] ubusd: fix systemd socket activation support Message-ID: <95e2dc0c4042f956767757c8204fc616cf9435b8.1464048108.git.mschiffer@universe-factory.net> 62cdfc3 added systemd units including a ubus.socket unit, but didn't actually add socket activation support to ubusd. This would cause the first connection that activated ubusd to hang (as ubusd ignored it), and stopping ubusd would break it completely (as ubusd removed the socket file). The ENABLE_SYSTEMD default is changed to OFF as the socket activation uses libsystemd, so setting ENABLE_SYSTEMD to ON will now require libsystemd. Signed-off-by: Matthias Schiffer --- CMakeLists.txt | 15 ++++++++++----- ubusd.c | 39 ++++++++++++++++++++++++++++++++------- 2 files changed, 42 insertions(+), 12 deletions(-) diff --git a/CMakeLists.txt b/CMakeLists.txt index e21a046..faab342 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -5,7 +5,7 @@ ADD_DEFINITIONS(-Os -Wall -Werror --std=gnu99 -g3 -Wmissing-declarations) OPTION(BUILD_LUA "build Lua plugin" ON) OPTION(BUILD_EXAMPLES "build examples" ON) -OPTION(ENABLE_SYSTEMD "systemd support" ON) +OPTION(ENABLE_SYSTEMD "systemd support" OFF) SET(CMAKE_SHARED_LIBRARY_LINK_C_FLAGS "") SET(UBUS_UNIX_SOCKET "/var/run/ubus.sock") @@ -60,8 +60,13 @@ SET(UBUSD_BINARY "${CMAKE_INSTALL_PREFIX}/sbin/ubusd") # do this after the installs so we have the proper paths IF(ENABLE_SYSTEMD) INCLUDE(FindPkgConfig) - PKG_CHECK_MODULES(SYSTEMD systemd) - IF(SYSTEMD_FOUND) - ADD_SUBDIRECTORY(systemd) - ENDIF() + PKG_CHECK_MODULES(SYSTEMD libsystemd REQUIRED) + + SET_PROPERTY(TARGET ubusd APPEND PROPERTY COMPILE_FLAGS "${SYSTEMD_CFLAGS}") + SET_PROPERTY(TARGET ubusd APPEND PROPERTY LINK_FLAGS "${SYSTEMD_LDFLAGS}") + SET_PROPERTY(TARGET ubusd APPEND PROPERTY INCLUDE_DIRECTORIES ${SYSTEMD_INCLUDE_DIRS}) + TARGET_LINK_LIBRARIES(ubusd ${SYSTEMD_LIBRARIES}) + ADD_DEFINITIONS( -DENABLE_SYSTEMD) + + ADD_SUBDIRECTORY(systemd) ENDIF() diff --git a/ubusd.c b/ubusd.c index 7279a70..5b1d52c 100644 --- a/ubusd.c +++ b/ubusd.c @@ -22,6 +22,9 @@ #include #include #include +#ifdef ENABLE_SYSTEMD +#include +#endif #include #include @@ -380,8 +383,12 @@ static void sighup_handler(int sig) int main(int argc, char **argv) { const char *ubus_socket = UBUS_UNIX_SOCKET; + bool remove_socket = true; int ret = 0; int ch; +#ifdef ENABLE_SYSTEMD + int n_fds; +#endif signal(SIGPIPE, SIG_IGN); signal(SIGHUP, sighup_handler); @@ -402,19 +409,37 @@ int main(int argc, char **argv) } } - unlink(ubus_socket); - umask(0111); - server_fd.fd = usock(USOCK_UNIX | USOCK_SERVER | USOCK_NONBLOCK, ubus_socket, NULL); - if (server_fd.fd < 0) { - perror("usock"); - ret = -1; +#ifdef ENABLE_SYSTEMD + n_fds = sd_listen_fds(1); + if (n_fds > 1) { + fprintf(stderr, "Too many file descriptors received.\n"); + ret = -1; goto out; + } else if (n_fds == 1) { + server_fd.fd = SD_LISTEN_FDS_START + 0; + fcntl(server_fd.fd, F_SETFD, fcntl(server_fd.fd, F_GETFD) | FD_CLOEXEC); + fcntl(server_fd.fd, F_SETFL, fcntl(server_fd.fd, F_GETFL) | O_NONBLOCK); + + remove_socket = false; + } else +#endif + { + unlink(ubus_socket); + umask(0111); + server_fd.fd = usock(USOCK_UNIX | USOCK_SERVER | USOCK_NONBLOCK, ubus_socket, NULL); + if (server_fd.fd < 0) { + perror("usock"); + ret = -1; + goto out; + } } uloop_fd_add(&server_fd, ULOOP_READ | ULOOP_EDGE_TRIGGER); ubusd_acl_load(); uloop_run(); - unlink(ubus_socket); + + if (remove_socket) + unlink(ubus_socket); out: uloop_done(); -- 2.8.2 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From Alexey.Brodkin at synopsys.com Tue May 24 06:51:31 2016 From: Alexey.Brodkin at synopsys.com (Alexey Brodkin) Date: Tue, 24 May 2016 13:51:31 +0300 Subject: [OpenWrt-Devel] [PATCH] procd: Update to latest head Message-ID: <1464087091-12188-1-git-send-email-abrodkin@synopsys.com> This includes a fix for building against uClibc: http://git.openwrt.org/?p=project/procd.git;a=commit;h=9a6f83d3c168523ac7b898ae481c2fd8c501d6a6 Signed-off-by: Alexey Brodkin Cc: John Crispin --- package/system/procd/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/package/system/procd/Makefile b/package/system/procd/Makefile index 7ba2be3..cb7ab05 100644 --- a/package/system/procd/Makefile +++ b/package/system/procd/Makefile @@ -8,14 +8,14 @@ include $(TOPDIR)/rules.mk PKG_NAME:=procd -PKG_VERSION:=2016-05-19 +PKG_VERSION:=2016-05-24 PKG_RELEASE=$(PKG_SOURCE_VERSION) PKG_SOURCE_PROTO:=git PKG_SOURCE_URL=$(OPENWRT_GIT)/project/procd.git PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION) -PKG_SOURCE_VERSION:=1418c6ce8559ea125c525c2663105fa5ff14905e +PKG_SOURCE_VERSION:=9a6f83d3c168523ac7b898ae481c2fd8c501d6a6 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.gz CMAKE_INSTALL:=1 -- 2.5.0 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From luka at openwrt.org Tue May 24 10:06:13 2016 From: luka at openwrt.org (Luka Perkov) Date: Tue, 24 May 2016 16:06:13 +0200 Subject: [OpenWrt-Devel] [PROPOSAL] move OpenWrt codebase to Git and GitHub Message-ID: <20160524140613.GA3437@localhost.localdomain> Dear OpenWrt mailing list readers, as the subject says I'd like to make proposal to move the OpenWrt codebase to Git. This was already discussed before [1] and now when there are no blockers [2] for this change I'd like that we as a community move forward with this switch. Also, I'd like to propose that we move the project to GitHub and here are the reasons why I see this as a good decision: * GitHub will allow people to contribute more easily The bigger amount of contributions has already happened and can be seen on the packages feed which is already hosted on GitHub. With this I'm also hoping to avoid comments regarding invalid patches on the mailing list. For now I am proposing that the current development workflow is also accepted - aka. patches that are sent to the mailing list are also accepted. * GitHub and similar services will allow us to integrate more easily with other projects Here specifically I mean integration with modern CI. Here is an example of integration with drone.io [3][4]. At the moment this is only in the POC stage but what I'd like to do down the line is to: - build OpenWrt images for all architectures for every pull request - build OpenWrt package binary for every package pull request for all architectures and make it available for download - build and host OpenWrt qemu and/or Docker image for every pull request This will allow easy review of the work since flags will be shown in the pull request if the build was sucessful or not. Also, this will allow people to test changes without building the image and thus lowering the time that needs to be spent on maintenance work. If this proposal gets accepted I'll be sending out an email to get access to more build servers so this new build infrastructure can properly support the project in a timely fashion. Please share your thoughts regarding this proposal. Regards, Luka [1] https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036390.html [2] https://lists.openwrt.org/pipermail/openwrt-devel/2016-May/041329.html [3] https://github.com/makkrnic/openwrt-qemu-x86 [4] http://sartura-drone.makkrnic.com/makkrnic/openwrt-qemu-x86/5 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From jo at mein.io Tue May 24 10:46:04 2016 From: jo at mein.io (Jo-Philipp Wich) Date: Tue, 24 May 2016 16:46:04 +0200 Subject: [OpenWrt-Devel] [PROPOSAL] move OpenWrt codebase to Git and GitHub In-Reply-To: <20160524140613.GA3437@localhost.localdomain> References: <20160524140613.GA3437@localhost.localdomain> Message-ID: Hi Luka, this is fantastic news! I'd be very interested in your future progress on the CI front. If drone.io is able to accommodate the resources required for building the entire OpenWrt then it sounds like a good solution for other projects too. Regards, Jo _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From marex at denx.de Tue May 24 10:48:08 2016 From: marex at denx.de (Marek Vasut) Date: Tue, 24 May 2016 16:48:08 +0200 Subject: [OpenWrt-Devel] [PATCH] bcm53xx: Move SF mmap patch Message-ID: <1464101288-7056-1-git-send-email-marex@denx.de> The patch adding SPI flash mmap read capability does not compile due to missing m25p80_rx_nbits() function. Move it to bcm53xx patch directory, where the patch adding this m25p80_rx_nbits() function resides. Signed-off-by: Marek Vasut --- .../045-mtd-devices-m25p80-add-support-for-mmap-read-request.patch | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename target/linux/{generic => bcm53xx}/patches-4.4/045-mtd-devices-m25p80-add-support-for-mmap-read-request.patch (100%) diff --git a/target/linux/generic/patches-4.4/045-mtd-devices-m25p80-add-support-for-mmap-read-request.patch b/target/linux/bcm53xx/patches-4.4/045-mtd-devices-m25p80-add-support-for-mmap-read-request.patch similarity index 100% rename from target/linux/generic/patches-4.4/045-mtd-devices-m25p80-add-support-for-mmap-read-request.patch rename to target/linux/bcm53xx/patches-4.4/045-mtd-devices-m25p80-add-support-for-mmap-read-request.patch -- 2.7.0 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From marex at denx.de Tue May 24 10:49:17 2016 From: marex at denx.de (Marek Vasut) Date: Tue, 24 May 2016 16:49:17 +0200 Subject: [OpenWrt-Devel] [PATCH] u-boot-socfpga: Update to 2016.05 Message-ID: <1464101357-7172-1-git-send-email-marex@denx.de> Update the U-Boot package to upstream 2016.05 version. This version improves overall performance of the platform, since it fixes cache problems that prevented the cache from operating fully in previous releases. Signed-off-by: Marek Vasut --- package/boot/uboot-socfpga/Makefile | 4 +- ...ga-Drop-space-after-loadaddr-in-extra-env.patch | 101 --------------------- ...pga-Tweak-SoCkit-default-env-for-OpenWRT.patch} | 12 +-- 3 files changed, 8 insertions(+), 109 deletions(-) delete mode 100644 package/boot/uboot-socfpga/patches/0001-arm-socfpga-Drop-space-after-loadaddr-in-extra-env.patch rename package/boot/uboot-socfpga/patches/{0002-arm-socfpga-Tweak-SoCkit-default-env-for-OpenWRT.patch => 0001-arm-socfpga-Tweak-SoCkit-default-env-for-OpenWRT.patch} (91%) diff --git a/package/boot/uboot-socfpga/Makefile b/package/boot/uboot-socfpga/Makefile index 42fcb43..3fb017f 100644 --- a/package/boot/uboot-socfpga/Makefile +++ b/package/boot/uboot-socfpga/Makefile @@ -8,7 +8,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=u-boot -PKG_VERSION:=2016.03 +PKG_VERSION:=2016.05 PKG_RELEASE:=1 PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME)-$(BUILD_VARIANT)/$(PKG_NAME)-$(PKG_VERSION) @@ -16,7 +16,7 @@ PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2 PKG_SOURCE_URL:= \ http://mirror2.openwrt.org/sources \ ftp://ftp.denx.de/pub/u-boot -PKG_MD5SUM:=973c1d896be751321cc3aafa564f64b2 +PKG_MD5SUM:=3a8613d753dfa707c937991a35404510 PKG_LICENSE:=GPL-2.0 GPL-2.0+ PKG_LICENSE_FILES:=Licenses/README diff --git a/package/boot/uboot-socfpga/patches/0001-arm-socfpga-Drop-space-after-loadaddr-in-extra-env.patch b/package/boot/uboot-socfpga/patches/0001-arm-socfpga-Drop-space-after-loadaddr-in-extra-env.patch deleted file mode 100644 index 261afef..0000000 --- a/package/boot/uboot-socfpga/patches/0001-arm-socfpga-Drop-space-after-loadaddr-in-extra-env.patch +++ /dev/null @@ -1,101 +0,0 @@ -From 04a4c90fee75c95130af1e40880c0927d56b0b61 Mon Sep 17 00:00:00 2001 -From: Marek Vasut -Date: Sun, 3 Apr 2016 19:11:12 +0200 -Subject: [PATCH 1/2] arm: socfpga: Drop space after 'loadaddr=' in extra env - -There is an incorrect space after loadaddr= in the extra environment, -so drop it. - -Signed-off-by: Marek Vasut -Cc: Dinh Nguyen -Cc: Chin Liang See ---- - include/configs/socfpga_arria5_socdk.h | 2 +- - include/configs/socfpga_cyclone5_socdk.h | 2 +- - include/configs/socfpga_de0_nano_soc.h | 2 +- - include/configs/socfpga_sockit.h | 2 +- - include/configs/socfpga_socrates.h | 2 +- - include/configs/socfpga_sr1500.h | 2 +- - 6 files changed, 6 insertions(+), 6 deletions(-) - -diff --git a/include/configs/socfpga_arria5_socdk.h b/include/configs/socfpga_arria5_socdk.h -index a0161bc..153f9f8 100644 ---- a/include/configs/socfpga_arria5_socdk.h -+++ b/include/configs/socfpga_arria5_socdk.h -@@ -56,7 +56,7 @@ - /* Extra Environment */ - #define CONFIG_EXTRA_ENV_SETTINGS \ - "verify=n\0" \ -- "loadaddr= " __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \ -+ "loadaddr=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \ - "ramboot=setenv bootargs " CONFIG_BOOTARGS ";" \ - "bootm ${loadaddr} - ${fdt_addr}\0" \ - "bootimage=zImage\0" \ -diff --git a/include/configs/socfpga_cyclone5_socdk.h b/include/configs/socfpga_cyclone5_socdk.h -index c4c4ecb..d7c339e 100644 ---- a/include/configs/socfpga_cyclone5_socdk.h -+++ b/include/configs/socfpga_cyclone5_socdk.h -@@ -56,7 +56,7 @@ - /* Extra Environment */ - #define CONFIG_EXTRA_ENV_SETTINGS \ - "verify=n\0" \ -- "loadaddr= " __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \ -+ "loadaddr=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \ - "ramboot=setenv bootargs " CONFIG_BOOTARGS ";" \ - "bootm ${loadaddr} - ${fdt_addr}\0" \ - "bootimage=zImage\0" \ -diff --git a/include/configs/socfpga_de0_nano_soc.h b/include/configs/socfpga_de0_nano_soc.h -index cbc7396..314b9bf 100644 ---- a/include/configs/socfpga_de0_nano_soc.h -+++ b/include/configs/socfpga_de0_nano_soc.h -@@ -51,7 +51,7 @@ - - /* Extra Environment */ - #define CONFIG_EXTRA_ENV_SETTINGS \ -- "loadaddr= " __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \ -+ "loadaddr=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \ - "ramboot=setenv bootargs " CONFIG_BOOTARGS ";" \ - "bootm ${loadaddr} - ${fdt_addr}\0" \ - "bootimage=zImage\0" \ -diff --git a/include/configs/socfpga_sockit.h b/include/configs/socfpga_sockit.h -index 95e7ba6..07cfcbf 100644 ---- a/include/configs/socfpga_sockit.h -+++ b/include/configs/socfpga_sockit.h -@@ -52,7 +52,7 @@ - /* Extra Environment */ - #define CONFIG_EXTRA_ENV_SETTINGS \ - "verify=n\0" \ -- "loadaddr= " __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \ -+ "loadaddr=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \ - "ramboot=setenv bootargs " CONFIG_BOOTARGS ";" \ - "bootm ${loadaddr} - ${fdt_addr}\0" \ - "bootimage=zImage\0" \ -diff --git a/include/configs/socfpga_socrates.h b/include/configs/socfpga_socrates.h -index c32a40a..02ea0c5 100644 ---- a/include/configs/socfpga_socrates.h -+++ b/include/configs/socfpga_socrates.h -@@ -52,7 +52,7 @@ - /* Extra Environment */ - #define CONFIG_EXTRA_ENV_SETTINGS \ - "verify=n\0" \ -- "loadaddr= " __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \ -+ "loadaddr=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \ - "ramboot=setenv bootargs " CONFIG_BOOTARGS ";" \ - "bootm ${loadaddr} - ${fdt_addr}\0" \ - "bootimage=zImage\0" \ -diff --git a/include/configs/socfpga_sr1500.h b/include/configs/socfpga_sr1500.h -index 6414eeb..e43b5cf 100644 ---- a/include/configs/socfpga_sr1500.h -+++ b/include/configs/socfpga_sr1500.h -@@ -55,7 +55,7 @@ - - #define CONFIG_EXTRA_ENV_SETTINGS \ - "verify=n\0" \ -- "loadaddr= " __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \ -+ "loadaddr=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \ - "ramboot=setenv bootargs " CONFIG_BOOTARGS ";" \ - "bootm ${loadaddr} - ${fdt_addr}\0" \ - "bootimage=zImage\0" \ --- -2.8.0.rc3 - diff --git a/package/boot/uboot-socfpga/patches/0002-arm-socfpga-Tweak-SoCkit-default-env-for-OpenWRT.patch b/package/boot/uboot-socfpga/patches/0001-arm-socfpga-Tweak-SoCkit-default-env-for-OpenWRT.patch similarity index 91% rename from package/boot/uboot-socfpga/patches/0002-arm-socfpga-Tweak-SoCkit-default-env-for-OpenWRT.patch rename to package/boot/uboot-socfpga/patches/0001-arm-socfpga-Tweak-SoCkit-default-env-for-OpenWRT.patch index 64ffea2..a46be2e 100644 --- a/package/boot/uboot-socfpga/patches/0002-arm-socfpga-Tweak-SoCkit-default-env-for-OpenWRT.patch +++ b/package/boot/uboot-socfpga/patches/0001-arm-socfpga-Tweak-SoCkit-default-env-for-OpenWRT.patch @@ -1,7 +1,7 @@ -From 3a0e4875b00e9e487b0081116a81ed17cfd5143f Mon Sep 17 00:00:00 2001 +From f17c641b74fa067c07295e20c4392664388ef7ac Mon Sep 17 00:00:00 2001 From: Marek Vasut Date: Sun, 3 Apr 2016 19:27:23 +0200 -Subject: [PATCH 2/2] arm: socfpga: Tweak SoCkit default env for OpenWRT +Subject: [PATCH] arm: socfpga: Tweak SoCkit default env for OpenWRT Tweak the default environment on SoCFPGA SoCkit to match OpenWRT. This means switching to fitImage, which is already available, but @@ -14,10 +14,10 @@ Signed-off-by: Marek Vasut 1 file changed, 6 insertions(+), 14 deletions(-) diff --git a/include/configs/socfpga_sockit.h b/include/configs/socfpga_sockit.h -index 07cfcbf..5a90105 100644 +index 675f5d1..3111e46 100644 --- a/include/configs/socfpga_sockit.h +++ b/include/configs/socfpga_sockit.h -@@ -35,7 +35,7 @@ +@@ -19,7 +19,7 @@ /* Booting Linux */ #define CONFIG_BOOTDELAY 3 @@ -26,7 +26,7 @@ index 07cfcbf..5a90105 100644 #define CONFIG_BOOTARGS "console=ttyS0," __stringify(CONFIG_BAUDRATE) #define CONFIG_BOOTCOMMAND "run mmcload; run mmcboot" #define CONFIG_LOADADDR 0x01000000 -@@ -51,28 +51,20 @@ +@@ -35,28 +35,20 @@ /* Extra Environment */ #define CONFIG_EXTRA_ENV_SETTINGS \ @@ -61,5 +61,5 @@ index 07cfcbf..5a90105 100644 /* The rest of the configuration is shared */ #include -- -2.8.0.rc3 +2.8.1 -- 2.7.0 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From marex at denx.de Tue May 24 10:50:08 2016 From: marex at denx.de (Marek Vasut) Date: Tue, 24 May 2016 16:50:08 +0200 Subject: [OpenWrt-Devel] [PATCH] toolchain: Backport gcc6 fixes from mainline GCC Message-ID: <1464101408-7274-1-git-send-email-marex@denx.de> Backported from mainline 2016-02-19 Jakub Jelinek Bernd Edlinger * Make-lang.in: Invoke gperf with -L C++. * cfns.gperf: Remove prototypes for hash and libc_name_p inlines. * cfns.h: Regenerated. * except.c (nothrow_libfn_p): Adjust. Signed-off-by: Marek Vasut --- ...-Bernd-Edlinger-bernd.edlinger-hotmail.de.patch | 152 +++++++++++++++++++++ 1 file changed, 152 insertions(+) create mode 100644 toolchain/gcc/patches/4.8-linaro/005-2016-02-25-Bernd-Edlinger-bernd.edlinger-hotmail.de.patch diff --git a/toolchain/gcc/patches/4.8-linaro/005-2016-02-25-Bernd-Edlinger-bernd.edlinger-hotmail.de.patch b/toolchain/gcc/patches/4.8-linaro/005-2016-02-25-Bernd-Edlinger-bernd.edlinger-hotmail.de.patch new file mode 100644 index 0000000..070991e --- /dev/null +++ b/toolchain/gcc/patches/4.8-linaro/005-2016-02-25-Bernd-Edlinger-bernd.edlinger-hotmail.de.patch @@ -0,0 +1,152 @@ +From 8c3fa311caa86f61b4e28d1563d1110b44340fb2 Mon Sep 17 00:00:00 2001 +From: edlinger +Date: Thu, 25 Feb 2016 15:36:41 +0000 +Subject: [PATCH] 2016-02-25 Bernd Edlinger + + Backported from mainline + 2016-02-19 Jakub Jelinek + Bernd Edlinger + + * Make-lang.in: Invoke gperf with -L C++. + * cfns.gperf: Remove prototypes for hash and libc_name_p + inlines. + * cfns.h: Regenerated. + * except.c (nothrow_libfn_p): Adjust. + + +git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch at 233721 138bc75d-0d04-0410-961f-82ee72b054a4 +--- + gcc/cp/Make-lang.in | 2 +- + gcc/cp/cfns.gperf | 10 ++-------- + gcc/cp/cfns.h | 41 ++++++++++++++--------------------------- + gcc/cp/except.c | 3 ++- + 4 files changed, 19 insertions(+), 37 deletions(-) + +diff --git a/gcc/cp/Make-lang.in b/gcc/cp/Make-lang.in +index bd1c1d7..a0ea0d4 100644 +--- a/gcc/cp/Make-lang.in ++++ b/gcc/cp/Make-lang.in +@@ -111,7 +111,7 @@ else + # deleting the $(srcdir)/cp/cfns.h file. + $(srcdir)/cp/cfns.h: + endif +- gperf -o -C -E -k '1-6,$$' -j1 -D -N 'libc_name_p' -L ANSI-C \ ++ gperf -o -C -E -k '1-6,$$' -j1 -D -N 'libc_name_p' -L C++ \ + $(srcdir)/cp/cfns.gperf --output-file $(srcdir)/cp/cfns.h + + # +diff --git a/gcc/cp/cfns.gperf b/gcc/cp/cfns.gperf +index 05ca753..d9b16b8 100644 +--- a/gcc/cp/cfns.gperf ++++ b/gcc/cp/cfns.gperf +@@ -1,3 +1,5 @@ ++%language=C++ ++%define class-name libc_name + %{ + /* Copyright (C) 2000-2014 Free Software Foundation, Inc. + +@@ -16,14 +18,6 @@ for more details. + You should have received a copy of the GNU General Public License + along with GCC; see the file COPYING3. If not see + . */ +-#ifdef __GNUC__ +-__inline +-#endif +-static unsigned int hash (const char *, unsigned int); +-#ifdef __GNUC__ +-__inline +-#endif +-const char * libc_name_p (const char *, unsigned int); + %} + %% + # The standard C library functions, for feeding to gperf; the result is used +diff --git a/gcc/cp/cfns.h b/gcc/cp/cfns.h +index c845ddf..65801d1 100644 +--- a/gcc/cp/cfns.h ++++ b/gcc/cp/cfns.h +@@ -1,5 +1,5 @@ +-/* ANSI-C code produced by gperf version 3.0.3 */ +-/* Command-line: gperf -o -C -E -k '1-6,$' -j1 -D -N libc_name_p -L ANSI-C cfns.gperf */ ++/* C++ code produced by gperf version 3.0.4 */ ++/* Command-line: gperf -o -C -E -k '1-6,$' -j1 -D -N libc_name_p -L C++ --output-file cfns.h cfns.gperf */ + + #if !((' ' == 32) && ('!' == 33) && ('"' == 34) && ('#' == 35) \ + && ('%' == 37) && ('&' == 38) && ('\'' == 39) && ('(' == 40) \ +@@ -28,7 +28,7 @@ + #error "gperf generated tables don't work with this execution character set. Please report a bug to ." + #endif + +-#line 1 "cfns.gperf" ++#line 3 "cfns.gperf" + + /* Copyright (C) 2000-2014 Free Software Foundation, Inc. + +@@ -47,25 +47,18 @@ for more details. + You should have received a copy of the GNU General Public License + along with GCC; see the file COPYING3. If not see + . */ +-#ifdef __GNUC__ +-__inline +-#endif +-static unsigned int hash (const char *, unsigned int); +-#ifdef __GNUC__ +-__inline +-#endif +-const char * libc_name_p (const char *, unsigned int); + /* maximum key range = 391, duplicates = 0 */ + +-#ifdef __GNUC__ +-__inline +-#else +-#ifdef __cplusplus +-inline +-#endif +-#endif +-static unsigned int +-hash (register const char *str, register unsigned int len) ++class libc_name ++{ ++private: ++ static inline unsigned int hash (const char *str, unsigned int len); ++public: ++ static const char *libc_name_p (const char *str, unsigned int len); ++}; ++ ++inline unsigned int ++libc_name::hash (register const char *str, register unsigned int len) + { + static const unsigned short asso_values[] = + { +@@ -122,14 +115,8 @@ hash (register const char *str, register unsigned int len) + return hval + asso_values[(unsigned char)str[len - 1]]; + } + +-#ifdef __GNUC__ +-__inline +-#ifdef __GNUC_STDC_INLINE__ +-__attribute__ ((__gnu_inline__)) +-#endif +-#endif + const char * +-libc_name_p (register const char *str, register unsigned int len) ++libc_name::libc_name_p (register const char *str, register unsigned int len) + { + enum + { +diff --git a/gcc/cp/except.c b/gcc/cp/except.c +index 221971a..32340f5 100644 +--- a/gcc/cp/except.c ++++ b/gcc/cp/except.c +@@ -1030,7 +1030,8 @@ nothrow_libfn_p (const_tree fn) + unless the system headers are playing rename tricks, and if + they are, we don't want to be confused by them. */ + id = DECL_NAME (fn); +- return !!libc_name_p (IDENTIFIER_POINTER (id), IDENTIFIER_LENGTH (id)); ++ return !!libc_name::libc_name_p (IDENTIFIER_POINTER (id), ++ IDENTIFIER_LENGTH (id)); + } + + /* Returns nonzero if an exception of type FROM will be caught by a +-- +2.8.1 + -- 2.7.0 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From marex at denx.de Tue May 24 10:51:01 2016 From: marex at denx.de (Marek Vasut) Date: Tue, 24 May 2016 16:51:01 +0200 Subject: [OpenWrt-Devel] [PATCH 1/2] package: kernel: dtc: Add device tree compiler package Message-ID: <1464101462-7326-1-git-send-email-marex@denx.de> Add package with the DT compiler v1.4.1 . Signed-off-by: Marek Vasut --- package/kernel/dtc/Makefile | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) create mode 100644 package/kernel/dtc/Makefile diff --git a/package/kernel/dtc/Makefile b/package/kernel/dtc/Makefile new file mode 100644 index 0000000..5155323 --- /dev/null +++ b/package/kernel/dtc/Makefile @@ -0,0 +1,36 @@ +# +# Copyright (C) 2016 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:=dtc +PKG_VERSION:=1.4.1 +PKG_RELEASE=$(PKG_SOURCE_VERSION) + +PKG_SOURCE_URL:=git://git.kernel.org/pub/scm/utils/dtc/dtc.git +PKG_SOURCE_PROTO:=git +PKG_SOURCE_VERSION:=302fca9f4c283e1994cf0a5a9ce1cf43ca15e6d2 +PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION) +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.gz + +PKG_MAINTAINER:=Marek Vasut +PKG_LICENSE:=GPL-2.0+ + +include $(INCLUDE_DIR)/package.mk + +define Package/dtc + SECTION:=utils + CATEGORY:=Utilities + TITLE:=Device Tree Compiler +endef + +define Package/dtc/install + $(INSTALL_DIR) $(1)/usr/bin + $(INSTALL_BIN) $(PKG_BUILD_DIR)/dtc $(1)/usr/bin/ +endef + +$(eval $(call BuildPackage,dtc)) -- 2.7.0 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From marex at denx.de Tue May 24 10:51:02 2016 From: marex at denx.de (Marek Vasut) Date: Tue, 24 May 2016 16:51:02 +0200 Subject: [OpenWrt-Devel] [PATCH 2/2] package: kernel: dtc: Add DTO support In-Reply-To: <1464101462-7326-1-git-send-email-marex@denx.de> References: <1464101462-7326-1-git-send-email-marex@denx.de> Message-ID: <1464101462-7326-2-git-send-email-marex@denx.de> Add patch with the DT overlay support into the DTC package. Signed-off-by: Marek Vasut --- ...ripts-dtc-Update-to-version-with-overlays.patch | 642 +++++++++++++++++++++ 1 file changed, 642 insertions(+) create mode 100644 package/kernel/dtc/patches/0001-scripts-dtc-Update-to-version-with-overlays.patch diff --git a/package/kernel/dtc/patches/0001-scripts-dtc-Update-to-version-with-overlays.patch b/package/kernel/dtc/patches/0001-scripts-dtc-Update-to-version-with-overlays.patch new file mode 100644 index 0000000..605d303 --- /dev/null +++ b/package/kernel/dtc/patches/0001-scripts-dtc-Update-to-version-with-overlays.patch @@ -0,0 +1,642 @@ +From 5f84cb93eef9f8a8ff7f49d593893f252744d0fe Mon Sep 17 00:00:00 2001 +From: Pantelis Antoniou +Date: Wed, 26 Aug 2015 18:28:08 +0300 +Subject: [PATCH] scripts/dtc: Update to version with overlays + +Update to mainline dtc with overlay support + +Signed-off-by: Pantelis Antoniou +--- + checks.c | 20 +++++- + dtc-lexer.l | 5 ++ + dtc-parser.y | 54 ++++++++++++++-- + dtc.c | 83 ++++++++++++++++++++++-- + dtc.h | 13 +++- + livetree.c | 202 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + treesource.c | 3 + + util.c | 2 +- + 8 files changed, 367 insertions(+), 15 deletions(-) + +diff --git a/checks.c b/checks.c +index 3bf0fa4..af25c2b 100644 +--- a/checks.c ++++ b/checks.c +@@ -465,8 +465,12 @@ static void fixup_phandle_references(struct check *c, struct node *dt, + + refnode = get_node_by_ref(dt, m->ref); + if (! refnode) { +- FAIL(c, "Reference to non-existent node or label \"%s\"\n", +- m->ref); ++ if (!source_is_plugin) ++ FAIL(c, "Reference to non-existent node or " ++ "label \"%s\"\n", m->ref); ++ else /* mark the entry as unresolved */ ++ *((cell_t *)(prop->val.val + m->offset)) = ++ cpu_to_fdt32(0xffffffff); + continue; + } + +@@ -559,7 +563,7 @@ static void check_reg_format(struct check *c, struct node *dt, + size_cells = node_size_cells(node->parent); + entrylen = (addr_cells + size_cells) * sizeof(cell_t); + +- if ((prop->val.len % entrylen) != 0) ++ if (!entrylen || (prop->val.len % entrylen) != 0) + FAIL(c, "\"reg\" property in %s has invalid length (%d bytes) " + "(#address-cells == %d, #size-cells == %d)", + node->fullpath, prop->val.len, addr_cells, size_cells); +@@ -651,6 +655,15 @@ static void check_obsolete_chosen_interrupt_controller(struct check *c, + } + TREE_WARNING(obsolete_chosen_interrupt_controller, NULL); + ++static void check_deprecated_plugin_syntax(struct check *c, ++ struct node *dt) ++{ ++ if (deprecated_plugin_syntax_warning) ++ FAIL(c, "Use '/dts-v1/ /plugin/'; syntax. /dts-v1/; /plugin/; " ++ "is going to be removed in next versions"); ++} ++TREE_WARNING(deprecated_plugin_syntax, NULL); ++ + static struct check *check_table[] = { + &duplicate_node_names, &duplicate_property_names, + &node_name_chars, &node_name_format, &property_name_chars, +@@ -668,6 +681,7 @@ static struct check *check_table[] = { + + &avoid_default_addr_size, + &obsolete_chosen_interrupt_controller, ++ &deprecated_plugin_syntax, + + &always_fail, + }; +diff --git a/dtc-lexer.l b/dtc-lexer.l +index 0ee1caf..dd44ba2 100644 +--- a/dtc-lexer.l ++++ b/dtc-lexer.l +@@ -113,6 +113,11 @@ static void lexical_error(const char *fmt, ...); + return DT_V1; + } + ++<*>"/plugin/" { ++ DPRINT("Keyword: /plugin/\n"); ++ return DT_PLUGIN; ++ } ++ + <*>"/memreserve/" { + DPRINT("Keyword: /memreserve/\n"); + BEGIN_DEFAULT(); +diff --git a/dtc-parser.y b/dtc-parser.y +index ea57e0a..7d9652d 100644 +--- a/dtc-parser.y ++++ b/dtc-parser.y +@@ -19,6 +19,7 @@ + */ + %{ + #include ++#include + + #include "dtc.h" + #include "srcpos.h" +@@ -52,9 +53,11 @@ extern bool treesource_error; + struct node *nodelist; + struct reserve_info *re; + uint64_t integer; ++ bool is_plugin; + } + + %token DT_V1 ++%token DT_PLUGIN + %token DT_MEMRESERVE + %token DT_LSHIFT DT_RSHIFT DT_LE DT_GE DT_EQ DT_NE DT_AND DT_OR + %token DT_BITS +@@ -71,6 +74,7 @@ extern bool treesource_error; + + %type propdata + %type propdataprefix ++%type plugindecl + %type memreserve + %type memreserves + %type arrayprefix +@@ -101,10 +105,39 @@ extern bool treesource_error; + %% + + sourcefile: +- DT_V1 ';' memreserves devicetree ++ basesource ++ | pluginsource ++ ; ++ ++basesource: ++ DT_V1 ';' plugindecl memreserves devicetree ++ { ++ source_is_plugin = $3; ++ if (source_is_plugin) ++ deprecated_plugin_syntax_warning = true; ++ the_boot_info = build_boot_info($4, $5, ++ guess_boot_cpuid($5)); ++ } ++ ; ++ ++plugindecl: ++ /* empty */ ++ { ++ $$ = false; ++ } ++ | DT_PLUGIN ';' ++ { ++ $$ = true; ++ } ++ ; ++ ++pluginsource: ++ DT_V1 DT_PLUGIN ';' memreserves devicetree + { +- the_boot_info = build_boot_info($3, $4, +- guess_boot_cpuid($4)); ++ source_is_plugin = true; ++ deprecated_plugin_syntax_warning = false; ++ the_boot_info = build_boot_info($4, $5, ++ guess_boot_cpuid($5)); + } + ; + +@@ -144,10 +177,14 @@ devicetree: + { + struct node *target = get_node_by_ref($1, $2); + +- if (target) ++ if (target) { + merge_nodes(target, $3); +- else +- ERROR(&@2, "Label or path %s not found", $2); ++ } else { ++ if (symbol_fixup_support) ++ add_orphan_node($1, $3, $2); ++ else ++ ERROR(&@2, "Label or path %s not found", $2); ++ } + $$ = $1; + } + | devicetree DT_DEL_NODE DT_REF ';' +@@ -162,6 +199,11 @@ devicetree: + + $$ = $1; + } ++ | /* empty */ ++ { ++ /* build empty node */ ++ $$ = name_node(build_node(NULL, NULL), ""); ++ } + ; + + nodedef: +diff --git a/dtc.c b/dtc.c +index 8c4add6..ee37be9 100644 +--- a/dtc.c ++++ b/dtc.c +@@ -18,6 +18,8 @@ + * USA + */ + ++#include ++ + #include "dtc.h" + #include "srcpos.h" + +@@ -29,6 +31,8 @@ int reservenum; /* Number of memory reservation slots */ + int minsize; /* Minimum blob size */ + int padsize; /* Additional padding to blob */ + int phandle_format = PHANDLE_BOTH; /* Use linux,phandle or phandle properties */ ++int symbol_fixup_support; ++int auto_label_aliases; + + static void fill_fullpaths(struct node *tree, const char *prefix) + { +@@ -51,7 +55,7 @@ static void fill_fullpaths(struct node *tree, const char *prefix) + #define FDT_VERSION(version) _FDT_VERSION(version) + #define _FDT_VERSION(version) #version + static const char usage_synopsis[] = "dtc [options] "; +-static const char usage_short_opts[] = "qI:O:o:V:d:R:S:p:fb:i:H:sW:E:hv"; ++static const char usage_short_opts[] = "qI:O:o:V:d:R:S:p:fb:i:H:sW:E:@Ahv"; + static struct option const usage_long_opts[] = { + {"quiet", no_argument, NULL, 'q'}, + {"in-format", a_argument, NULL, 'I'}, +@@ -69,6 +73,8 @@ static struct option const usage_long_opts[] = { + {"phandle", a_argument, NULL, 'H'}, + {"warning", a_argument, NULL, 'W'}, + {"error", a_argument, NULL, 'E'}, ++ {"symbols", no_argument, NULL, '@'}, ++ {"auto-alias", no_argument, NULL, 'A'}, + {"help", no_argument, NULL, 'h'}, + {"version", no_argument, NULL, 'v'}, + {NULL, no_argument, NULL, 0x0}, +@@ -99,16 +105,63 @@ static const char * const usage_opts_help[] = { + "\t\tboth - Both \"linux,phandle\" and \"phandle\" properties", + "\n\tEnable/disable warnings (prefix with \"no-\")", + "\n\tEnable/disable errors (prefix with \"no-\")", ++ "\n\tEnable symbols/fixup support", ++ "\n\tEnable auto-alias of labels", + "\n\tPrint this help and exit", + "\n\tPrint version and exit", + NULL, + }; + ++static const char *guess_type_by_name(const char *fname, const char *fallback) ++{ ++ const char *s; ++ ++ s = strrchr(fname, '.'); ++ if (s == NULL) ++ return fallback; ++ if (!strcasecmp(s, ".dts")) ++ return "dts"; ++ if (!strcasecmp(s, ".dtb")) ++ return "dtb"; ++ return fallback; ++} ++ ++static const char *guess_input_format(const char *fname, const char *fallback) ++{ ++ struct stat statbuf; ++ uint32_t magic; ++ FILE *f; ++ ++ if (stat(fname, &statbuf) != 0) ++ return fallback; ++ ++ if (S_ISDIR(statbuf.st_mode)) ++ return "fs"; ++ ++ if (!S_ISREG(statbuf.st_mode)) ++ return fallback; ++ ++ f = fopen(fname, "r"); ++ if (f == NULL) ++ return fallback; ++ if (fread(&magic, 4, 1, f) != 1) { ++ fclose(f); ++ return fallback; ++ } ++ fclose(f); ++ ++ magic = fdt32_to_cpu(magic); ++ if (magic == FDT_MAGIC) ++ return "dtb"; ++ ++ return guess_type_by_name(fname, fallback); ++} ++ + int main(int argc, char *argv[]) + { + struct boot_info *bi; +- const char *inform = "dts"; +- const char *outform = "dts"; ++ const char *inform = NULL; ++ const char *outform = NULL; + const char *outname = "-"; + const char *depname = NULL; + bool force = false, sort = false; +@@ -186,7 +239,12 @@ int main(int argc, char *argv[]) + case 'E': + parse_checks_option(false, true, optarg); + break; +- ++ case '@': ++ symbol_fixup_support = 1; ++ break; ++ case 'A': ++ auto_label_aliases = 1; ++ break; + case 'h': + usage(NULL); + default: +@@ -213,6 +271,17 @@ int main(int argc, char *argv[]) + fprintf(depfile, "%s:", outname); + } + ++ if (inform == NULL) ++ inform = guess_input_format(arg, "dts"); ++ if (outform == NULL) { ++ outform = guess_type_by_name(outname, NULL); ++ if (outform == NULL) { ++ if (streq(inform, "dts")) ++ outform = "dtb"; ++ else ++ outform = "dts"; ++ } ++ } + if (streq(inform, "dts")) + bi = dt_from_source(arg); + else if (streq(inform, "fs")) +@@ -236,6 +305,12 @@ int main(int argc, char *argv[]) + if (sort) + sort_tree(bi); + ++ if (symbol_fixup_support || auto_label_aliases) ++ generate_label_node(bi->dt, bi->dt); ++ ++ if (symbol_fixup_support) ++ generate_fixups_node(bi->dt, bi->dt); ++ + if (streq(outname, "-")) { + outf = stdout; + } else { +diff --git a/dtc.h b/dtc.h +index 56212c8..d025111 100644 +--- a/dtc.h ++++ b/dtc.h +@@ -20,7 +20,7 @@ + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 + * USA + */ +- ++#define _GNU_SOURCE + #include + #include + #include +@@ -54,6 +54,14 @@ extern int reservenum; /* Number of memory reservation slots */ + extern int minsize; /* Minimum blob size */ + extern int padsize; /* Additional padding to blob */ + extern int phandle_format; /* Use linux,phandle or phandle properties */ ++extern int symbol_fixup_support;/* enable symbols & fixup support */ ++extern int auto_label_aliases; /* auto generate labels -> aliases */ ++ ++/* ++ * Tree source globals ++ */ ++extern bool source_is_plugin; ++extern bool deprecated_plugin_syntax_warning; + + #define PHANDLE_LEGACY 0x1 + #define PHANDLE_EPAPR 0x2 +@@ -194,6 +202,7 @@ struct node *build_node_delete(void); + struct node *name_node(struct node *node, char *name); + struct node *chain_node(struct node *first, struct node *list); + struct node *merge_nodes(struct node *old_node, struct node *new_node); ++void add_orphan_node(struct node *old_node, struct node *new_node, char *ref); + + void add_property(struct node *node, struct property *prop); + void delete_property_by_name(struct node *node, char *name); +@@ -244,6 +253,8 @@ struct boot_info { + struct boot_info *build_boot_info(struct reserve_info *reservelist, + struct node *tree, uint32_t boot_cpuid_phys); + void sort_tree(struct boot_info *bi); ++void generate_label_node(struct node *node, struct node *dt); ++void generate_fixups_node(struct node *node, struct node *dt); + + /* Checks */ + +diff --git a/livetree.c b/livetree.c +index e229b84..1ef9fc4 100644 +--- a/livetree.c ++++ b/livetree.c +@@ -216,6 +216,34 @@ struct node *merge_nodes(struct node *old_node, struct node *new_node) + return old_node; + } + ++void add_orphan_node(struct node *dt, struct node *new_node, char *ref) ++{ ++ static unsigned int next_orphan_fragment = 0; ++ struct node *ovl = xmalloc(sizeof(*ovl)); ++ struct property *p; ++ struct data d = empty_data; ++ char *name; ++ int ret; ++ ++ memset(ovl, 0, sizeof(*ovl)); ++ ++ d = data_add_marker(d, REF_PHANDLE, ref); ++ d = data_append_integer(d, 0xffffffff, 32); ++ ++ p = build_property("target", d); ++ add_property(ovl, p); ++ ++ ret = asprintf(&name, "fragment@%u", ++ next_orphan_fragment++); ++ if (ret == -1) ++ die("asprintf() failed\n"); ++ name_node(ovl, name); ++ name_node(new_node, "__overlay__"); ++ ++ add_child(dt, ovl); ++ add_child(ovl, new_node); ++} ++ + struct node *chain_node(struct node *first, struct node *list) + { + assert(first->next_sibling == NULL); +@@ -709,3 +737,177 @@ void sort_tree(struct boot_info *bi) + sort_reserve_entries(bi); + sort_node(bi->dt); + } ++ ++void generate_label_node(struct node *node, struct node *dt) ++{ ++ struct node *c, *an; ++ struct property *p; ++ struct label *l; ++ int has_label; ++ char *gen_node_name; ++ ++ if (auto_label_aliases) ++ gen_node_name = "aliases"; ++ else ++ gen_node_name = "__symbols__"; ++ ++ /* Make sure the label isn't already there */ ++ has_label = 0; ++ for_each_label(node->labels, l) { ++ has_label = 1; ++ break; ++ } ++ ++ if (has_label) { ++ ++ /* an is the aliases/__symbols__ node */ ++ an = get_subnode(dt, gen_node_name); ++ /* if no node exists, create it */ ++ if (!an) { ++ an = build_node(NULL, NULL); ++ name_node(an, gen_node_name); ++ add_child(dt, an); ++ } ++ ++ /* now add the label in the node */ ++ for_each_label(node->labels, l) { ++ /* check whether the label already exists */ ++ p = get_property(an, l->label); ++ if (p) { ++ fprintf(stderr, "WARNING: label %s already" ++ " exists in /%s", l->label, ++ gen_node_name); ++ continue; ++ } ++ ++ /* insert it */ ++ p = build_property(l->label, ++ data_copy_escape_string(node->fullpath, ++ strlen(node->fullpath))); ++ add_property(an, p); ++ } ++ ++ /* force allocation of a phandle for this node */ ++ if (symbol_fixup_support) ++ (void)get_node_phandle(dt, node); ++ } ++ ++ for_each_child(node, c) ++ generate_label_node(c, dt); ++} ++ ++static void add_fixup_entry(struct node *dt, struct node *node, ++ struct property *prop, struct marker *m) ++{ ++ struct node *fn; /* local fixup node */ ++ struct property *p; ++ char *fixups_name = "__fixups__"; ++ struct data d; ++ char *entry; ++ int ret; ++ ++ /* fn is the node we're putting entries in */ ++ fn = get_subnode(dt, fixups_name); ++ /* if no node exists, create it */ ++ if (!fn) { ++ fn = build_node(NULL, NULL); ++ name_node(fn, fixups_name); ++ add_child(dt, fn); ++ } ++ ++ ret = asprintf(&entry, "%s:%s:%u", ++ node->fullpath, prop->name, m->offset); ++ if (ret == -1) ++ die("asprintf() failed\n"); ++ ++ p = get_property(fn, m->ref); ++ d = data_append_data(p ? p->val : empty_data, entry, strlen(entry) + 1); ++ if (!p) ++ add_property(fn, build_property(m->ref, d)); ++ else ++ p->val = d; ++} ++ ++static void add_local_fixup_entry(struct node *dt, struct node *node, ++ struct property *prop, struct marker *m, ++ struct node *refnode) ++{ ++ struct node *lfn, *wn, *nwn; /* local fixup node, walk node, new */ ++ struct property *p; ++ struct data d; ++ char *local_fixups_name = "__local_fixups__"; ++ char *s, *e, *comp; ++ int len; ++ ++ /* fn is the node we're putting entries in */ ++ lfn = get_subnode(dt, local_fixups_name); ++ /* if no node exists, create it */ ++ if (!lfn) { ++ lfn = build_node(NULL, NULL); ++ name_node(lfn, local_fixups_name); ++ add_child(dt, lfn); ++ } ++ ++ /* walk the path components creating nodes if they don't exist */ ++ comp = NULL; ++ /* start skipping the first / */ ++ s = node->fullpath + 1; ++ wn = lfn; ++ while (*s) { ++ /* retrieve path component */ ++ e = strchr(s, '/'); ++ if (e == NULL) ++ e = s + strlen(s); ++ len = e - s; ++ comp = xrealloc(comp, len + 1); ++ memcpy(comp, s, len); ++ comp[len] = '\0'; ++ ++ /* if no node exists, create it */ ++ nwn = get_subnode(wn, comp); ++ if (!nwn) { ++ nwn = build_node(NULL, NULL); ++ name_node(nwn, strdup(comp)); ++ add_child(wn, nwn); ++ } ++ wn = nwn; ++ ++ /* last path component */ ++ if (!*e) ++ break; ++ ++ /* next path component */ ++ s = e + 1; ++ } ++ free(comp); ++ ++ p = get_property(wn, prop->name); ++ d = data_append_cell(p ? p->val : empty_data, (cell_t)m->offset); ++ if (!p) ++ add_property(wn, build_property(prop->name, d)); ++ else ++ p->val = d; ++} ++ ++void generate_fixups_node(struct node *node, struct node *dt) ++{ ++ struct node *c; ++ struct property *prop; ++ struct marker *m; ++ struct node *refnode; ++ ++ for_each_property(node, prop) { ++ m = prop->val.markers; ++ for_each_marker_of_type(m, REF_PHANDLE) { ++ refnode = get_node_by_ref(dt, m->ref); ++ if (!refnode) ++ add_fixup_entry(dt, node, prop, m); ++ else ++ add_local_fixup_entry(dt, node, prop, m, ++ refnode); ++ } ++ } ++ ++ for_each_child(node, c) ++ generate_fixups_node(c, dt); ++} +diff --git a/treesource.c b/treesource.c +index a55d1d1..e1d6657 100644 +--- a/treesource.c ++++ b/treesource.c +@@ -28,6 +28,9 @@ extern YYLTYPE yylloc; + struct boot_info *the_boot_info; + bool treesource_error; + ++bool source_is_plugin; ++bool deprecated_plugin_syntax_warning; ++ + struct boot_info *dt_from_source(const char *fname) + { + the_boot_info = NULL; +diff --git a/util.c b/util.c +index 9d65226..cbb945b 100644 +--- a/util.c ++++ b/util.c +@@ -349,7 +349,6 @@ int utilfdt_decode_type(const char *fmt, int *type, int *size) + void utilfdt_print_data(const char *data, int len) + { + int i; +- const char *p = data; + const char *s; + + /* no data, don't print */ +@@ -376,6 +375,7 @@ void utilfdt_print_data(const char *data, int len) + i < (len - 1) ? " " : ""); + printf(">"); + } else { ++ const unsigned char *p = (const unsigned char *)data; + printf(" = ["); + for (i = 0; i < len; i++) + printf("%02x%s", *p++, i < len - 1 ? " " : ""); +-- +2.7.0 + -- 2.7.0 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From marex at denx.de Tue May 24 10:51:52 2016 From: marex at denx.de (Marek Vasut) Date: Tue, 24 May 2016 16:51:52 +0200 Subject: [OpenWrt-Devel] [PATCH] target: socfpga: Add support for QSPI NOR boot Message-ID: <1464101512-7379-1-git-send-email-marex@denx.de> Add necessary kernel backports to support the Cadence QSPI controller present on the Altera SoCFPGA SoC. Signed-off-by: Marek Vasut --- target/linux/socfpga/config-4.4 | 2 + ...-gpio-altera-Fix-altr-interrupt-type-prop.patch | 6 +- ...dwc2-gadget-Repair-DSTS-register-decoding.patch | 6 +- ...-dts-Enable-MMC-support-at-correct-place-.patch | 8 +- ...ocfpga-Add-support-for-HPS-LEDs-on-SoCKit.patch | 6 +- ...ga-Add-support-for-HPS-KEYs-SWs-on-SoCKit.patch | 6 +- ...td-add-get-set-of_node-flash_node-helpers.patch | 87 ++ .../0007-mtd-nand-spi-nor-assign-MTD-of_node.patch | 44 + ...r-convert-to-spi_nor_-get-set-_flash_node.patch | 91 ++ .../0009-mtd-spi-nor-drop-flash_node-field.patch | 64 + ...-remove-unnecessary-leading-space-from-db.patch | 32 + ...-provide-default-erase_sector-implementat.patch | 112 ++ ...-nor-mx25l3205d-mx25l6405d-append-SECT_4K.patch | 32 + ...-Fix-error-message-with-unrecognized-JEDE.patch | 35 + ...i-nor-fix-error-handling-in-spi_nor_erase.patch | 44 + ...i-nor-Check-the-return-value-from-read_sr.patch | 60 + ...016-mtd-spi-nor-remove-micron_quad_enable.patch | 110 ++ ...-properly-detect-the-memory-when-it-boots.patch | 244 ++++ ...-select-op-codes-and-SPI-NOR-protocols-by.patch | 203 +++ ...-spi-nor-fix-support-of-Macronix-memories.patch | 139 ++ ...d-spi-nor-fix-support-of-Winbond-memories.patch | 179 +++ ...td-spi-nor-fix-support-of-Micron-memories.patch | 224 +++ ...-spi-nor-fix-support-of-Spansion-memories.patch | 116 ++ ...-configure-the-number-of-dummy-clock-cycl.patch | 264 ++++ ...-configure-the-number-of-dummy-clock-cycl.patch | 159 +++ ...-configure-the-number-of-dummy-clock-cycl.patch | 237 ++++ ...-configure-the-number-of-dummy-clock-cycl.patch | 215 +++ ...add-support-of-dual-and-quad-spi-protocol.patch | 293 ++++ ...grab-device-tree-node-directly-from-maste.patch | 81 ++ ...on-atmel-quadspi-add-binding-file-for-Atm.patch | 58 + ...-Bindings-for-Cadence-Quad-SPI-Flash-Cont.patch | 99 ++ ...-Add-driver-for-Cadence-Quad-SPI-Flash-Co.patch | 1431 ++++++++++++++++++++ ...fpga-Add-Candence-QSPI-controller-DT-node.patch | 42 + ...3-ARM-socfpga-Enable-QSPI-flash-on-SoCKit.patch | 47 + 34 files changed, 4760 insertions(+), 16 deletions(-) create mode 100644 target/linux/socfpga/patches-4.4/0006-mtd-add-get-set-of_node-flash_node-helpers.patch create mode 100644 target/linux/socfpga/patches-4.4/0007-mtd-nand-spi-nor-assign-MTD-of_node.patch create mode 100644 target/linux/socfpga/patches-4.4/0008-mtd-spi-nor-convert-to-spi_nor_-get-set-_flash_node.patch create mode 100644 target/linux/socfpga/patches-4.4/0009-mtd-spi-nor-drop-flash_node-field.patch create mode 100644 target/linux/socfpga/patches-4.4/0010-mtd-spi-nor-remove-unnecessary-leading-space-from-db.patch create mode 100644 target/linux/socfpga/patches-4.4/0011-mtd-spi-nor-provide-default-erase_sector-implementat.patch create mode 100644 target/linux/socfpga/patches-4.4/0012-mtd-spi-nor-mx25l3205d-mx25l6405d-append-SECT_4K.patch create mode 100644 target/linux/socfpga/patches-4.4/0013-mtd-spi-nor-Fix-error-message-with-unrecognized-JEDE.patch create mode 100644 target/linux/socfpga/patches-4.4/0014-mtd-spi-nor-fix-error-handling-in-spi_nor_erase.patch create mode 100644 target/linux/socfpga/patches-4.4/0015-mtd-spi-nor-Check-the-return-value-from-read_sr.patch create mode 100644 target/linux/socfpga/patches-4.4/0016-mtd-spi-nor-remove-micron_quad_enable.patch create mode 100644 target/linux/socfpga/patches-4.4/0017-mtd-spi-nor-properly-detect-the-memory-when-it-boots.patch create mode 100644 target/linux/socfpga/patches-4.4/0018-mtd-spi-nor-select-op-codes-and-SPI-NOR-protocols-by.patch create mode 100644 target/linux/socfpga/patches-4.4/0019-mtd-spi-nor-fix-support-of-Macronix-memories.patch create mode 100644 target/linux/socfpga/patches-4.4/0020-mtd-spi-nor-fix-support-of-Winbond-memories.patch create mode 100644 target/linux/socfpga/patches-4.4/0021-mtd-spi-nor-fix-support-of-Micron-memories.patch create mode 100644 target/linux/socfpga/patches-4.4/0022-mtd-spi-nor-fix-support-of-Spansion-memories.patch create mode 100644 target/linux/socfpga/patches-4.4/0023-mtd-spi-nor-configure-the-number-of-dummy-clock-cycl.patch create mode 100644 target/linux/socfpga/patches-4.4/0024-mtd-spi-nor-configure-the-number-of-dummy-clock-cycl.patch create mode 100644 target/linux/socfpga/patches-4.4/0025-mtd-spi-nor-configure-the-number-of-dummy-clock-cycl.patch create mode 100644 target/linux/socfpga/patches-4.4/0026-mtd-spi-nor-configure-the-number-of-dummy-clock-cycl.patch create mode 100644 target/linux/socfpga/patches-4.4/0027-mtd-m25p80-add-support-of-dual-and-quad-spi-protocol.patch create mode 100644 target/linux/socfpga/patches-4.4/0028-mtd-ofpart-grab-device-tree-node-directly-from-maste.patch create mode 100644 target/linux/socfpga/patches-4.4/0029-Documentation-atmel-quadspi-add-binding-file-for-Atm.patch create mode 100644 target/linux/socfpga/patches-4.4/0030-mtd-spi-nor-Bindings-for-Cadence-Quad-SPI-Flash-Cont.patch create mode 100644 target/linux/socfpga/patches-4.4/0031-mtd-spi-nor-Add-driver-for-Cadence-Quad-SPI-Flash-Co.patch create mode 100644 target/linux/socfpga/patches-4.4/0032-ARM-socfpga-Add-Candence-QSPI-controller-DT-node.patch create mode 100644 target/linux/socfpga/patches-4.4/0033-ARM-socfpga-Enable-QSPI-flash-on-SoCKit.patch diff --git a/target/linux/socfpga/config-4.4 b/target/linux/socfpga/config-4.4 index 15cac52..b68bf7a 100644 --- a/target/linux/socfpga/config-4.4 +++ b/target/linux/socfpga/config-4.4 @@ -416,6 +416,7 @@ CONFIG_MMC_DW_PLTFM=y CONFIG_MODULES_TREE_LOOKUP=y CONFIG_MODULES_USE_ELF_REL=y CONFIG_MTD_CMDLINE_PARTS=y +CONFIG_MTD_M25P80=y CONFIG_MTD_SPI_NOR=y CONFIG_MTD_UBI=y CONFIG_MTD_UBI_BEB_LIMIT=20 @@ -621,6 +622,7 @@ CONFIG_SPARSE_IRQ=y CONFIG_SPI=y CONFIG_SPI_ALTERA=y CONFIG_SPI_BITBANG=y +CONFIG_SPI_CADENCE_QUADSPI=y CONFIG_SPI_DESIGNWARE=y CONFIG_SPI_DW_MMIO=y CONFIG_SPI_MASTER=y diff --git a/target/linux/socfpga/patches-4.4/0001-dt-bindings-gpio-altera-Fix-altr-interrupt-type-prop.patch b/target/linux/socfpga/patches-4.4/0001-dt-bindings-gpio-altera-Fix-altr-interrupt-type-prop.patch index b89793a..bf658eb 100644 --- a/target/linux/socfpga/patches-4.4/0001-dt-bindings-gpio-altera-Fix-altr-interrupt-type-prop.patch +++ b/target/linux/socfpga/patches-4.4/0001-dt-bindings-gpio-altera-Fix-altr-interrupt-type-prop.patch @@ -1,7 +1,7 @@ -From b32732e51a774e8514f40975f2600f02ef9db0b4 Mon Sep 17 00:00:00 2001 +From 39c5b88eedd3e99c57aeaf7d7d61a830a4ef4b80 Mon Sep 17 00:00:00 2001 From: Marek Vasut Date: Mon, 29 Feb 2016 17:19:59 +0100 -Subject: [PATCH 1/5] dt-bindings: gpio: altera: Fix altr,interrupt-type +Subject: [PATCH 01/33] dt-bindings: gpio: altera: Fix altr,interrupt-type property The altr,interrupt-trigger property is not used by the driver. @@ -41,5 +41,5 @@ index 12f5014..826a720 100644 gpio-controller; #interrupt-cells = <1>; -- -2.7.0 +2.8.1 diff --git a/target/linux/socfpga/patches-4.4/0002-usb-dwc2-gadget-Repair-DSTS-register-decoding.patch b/target/linux/socfpga/patches-4.4/0002-usb-dwc2-gadget-Repair-DSTS-register-decoding.patch index 9be3834..2a2b2ba 100644 --- a/target/linux/socfpga/patches-4.4/0002-usb-dwc2-gadget-Repair-DSTS-register-decoding.patch +++ b/target/linux/socfpga/patches-4.4/0002-usb-dwc2-gadget-Repair-DSTS-register-decoding.patch @@ -1,7 +1,7 @@ -From e5cbd23e4f40181c907a1abc136b17de8cb86809 Mon Sep 17 00:00:00 2001 +From f7697963e1b0fc1496709f84c00da5cb144a58a3 Mon Sep 17 00:00:00 2001 From: Marek Vasut Date: Thu, 17 Dec 2015 23:42:35 +0100 -Subject: [PATCH 2/5] usb: dwc2: gadget: Repair DSTS register decoding +Subject: [PATCH 02/33] usb: dwc2: gadget: Repair DSTS register decoding The "enumspd" field is located in register DSTS[2:1], but the code which checks the bitfield does not shift the value accordingly. This @@ -32,5 +32,5 @@ index 0abf73c..48e47c1 100644 case DSTS_ENUMSPD_FS48: hsotg->gadget.speed = USB_SPEED_FULL; -- -2.7.0 +2.8.1 diff --git a/target/linux/socfpga/patches-4.4/0003-ARM-socfpga-dts-Enable-MMC-support-at-correct-place-.patch b/target/linux/socfpga/patches-4.4/0003-ARM-socfpga-dts-Enable-MMC-support-at-correct-place-.patch index b12de6d..5dec3388 100644 --- a/target/linux/socfpga/patches-4.4/0003-ARM-socfpga-dts-Enable-MMC-support-at-correct-place-.patch +++ b/target/linux/socfpga/patches-4.4/0003-ARM-socfpga-dts-Enable-MMC-support-at-correct-place-.patch @@ -1,8 +1,8 @@ -From 6b8c64eb90e5d958f32524ff2d0571b3b6ac92df Mon Sep 17 00:00:00 2001 +From 23d14e4479c925904bc7620a55c66eb8babacbb9 Mon Sep 17 00:00:00 2001 From: Marek Vasut Date: Mon, 21 Dec 2015 00:42:01 -0600 -Subject: [PATCH 3/5] ARM: socfpga: dts: Enable MMC support at correct place in - the DT +Subject: [PATCH 03/33] ARM: socfpga: dts: Enable MMC support at correct place + in the DT The socfpga.dtsi explicitly enabled MMC support, but not all boards are equiped with an MMC card. There are setups which only have QSPI NOR. @@ -86,5 +86,5 @@ index 48bf651..b61f22f 100644 &usb1 { -- -2.7.0 +2.8.1 diff --git a/target/linux/socfpga/patches-4.4/0004-ARM-socfpga-Add-support-for-HPS-LEDs-on-SoCKit.patch b/target/linux/socfpga/patches-4.4/0004-ARM-socfpga-Add-support-for-HPS-LEDs-on-SoCKit.patch index 954f03e..f3155c5 100644 --- a/target/linux/socfpga/patches-4.4/0004-ARM-socfpga-Add-support-for-HPS-LEDs-on-SoCKit.patch +++ b/target/linux/socfpga/patches-4.4/0004-ARM-socfpga-Add-support-for-HPS-LEDs-on-SoCKit.patch @@ -1,7 +1,7 @@ -From e56e545745dc42cba743dab549d0afb1a39d14b4 Mon Sep 17 00:00:00 2001 +From 2088bf920b5ff60ab14e9fca940b4ae28e8b88d3 Mon Sep 17 00:00:00 2001 From: Marek Vasut Date: Mon, 22 Jun 2015 23:37:47 +0200 -Subject: [PATCH 4/5] ARM: socfpga: Add support for HPS LEDs on SoCKit +Subject: [PATCH 04/33] ARM: socfpga: Add support for HPS LEDs on SoCKit Add support for the blue LEDs on the SoCFPGA SoCkit board. @@ -62,5 +62,5 @@ index b61f22f..1461690 100644 status = "okay"; }; -- -2.7.0 +2.8.1 diff --git a/target/linux/socfpga/patches-4.4/0005-ARM-socfpga-Add-support-for-HPS-KEYs-SWs-on-SoCKit.patch b/target/linux/socfpga/patches-4.4/0005-ARM-socfpga-Add-support-for-HPS-KEYs-SWs-on-SoCKit.patch index a5e53f5..8e24b6c 100644 --- a/target/linux/socfpga/patches-4.4/0005-ARM-socfpga-Add-support-for-HPS-KEYs-SWs-on-SoCKit.patch +++ b/target/linux/socfpga/patches-4.4/0005-ARM-socfpga-Add-support-for-HPS-KEYs-SWs-on-SoCKit.patch @@ -1,7 +1,7 @@ -From a953c0800246e99c9b449bd9ec0b26682a82700c Mon Sep 17 00:00:00 2001 +From 7e990b69f2331daf7847ddb82bb5da9623f24f4f Mon Sep 17 00:00:00 2001 From: Marek Vasut Date: Tue, 23 Jun 2015 00:41:08 +0200 -Subject: [PATCH 5/5] ARM: socfpga: Add support for HPS KEYs/SWs on SoCKit +Subject: [PATCH 05/33] ARM: socfpga: Add support for HPS KEYs/SWs on SoCKit Add support for the keys and flip-switches on the SoCFPGA SoCkit board. @@ -96,5 +96,5 @@ index 1461690..02e22f5 100644 }; -- -2.7.0 +2.8.1 diff --git a/target/linux/socfpga/patches-4.4/0006-mtd-add-get-set-of_node-flash_node-helpers.patch b/target/linux/socfpga/patches-4.4/0006-mtd-add-get-set-of_node-flash_node-helpers.patch new file mode 100644 index 0000000..c3415d3 --- /dev/null +++ b/target/linux/socfpga/patches-4.4/0006-mtd-add-get-set-of_node-flash_node-helpers.patch @@ -0,0 +1,87 @@ +From cb0416f4be60979f3fd3e99a9baff17ac9b8381f Mon Sep 17 00:00:00 2001 +From: Brian Norris +Date: Fri, 30 Oct 2015 20:33:20 -0700 +Subject: [PATCH 06/33] mtd: add get/set of_node/flash_node helpers + +We are going to begin using the mtd->dev.of_node field for MTD device +nodes, so let's add helpers for it. Also, we'll be making some +conversions on spi_nor (and nand_chip eventually) too, so get that ready +with their own helpers. + +Signed-off-by: Brian Norris +Reviewed-by: Boris Brezillon +--- + include/linux/mtd/mtd.h | 11 +++++++++++ + include/linux/mtd/nand.h | 11 +++++++++++ + include/linux/mtd/spi-nor.h | 11 +++++++++++ + 3 files changed, 33 insertions(+) + +diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h +index f17fa75..cc84923 100644 +--- a/include/linux/mtd/mtd.h ++++ b/include/linux/mtd/mtd.h +@@ -254,6 +254,17 @@ struct mtd_info { + int usecount; + }; + ++static inline void mtd_set_of_node(struct mtd_info *mtd, ++ struct device_node *np) ++{ ++ mtd->dev.of_node = np; ++} ++ ++static inline struct device_node *mtd_get_of_node(struct mtd_info *mtd) ++{ ++ return mtd->dev.of_node; ++} ++ + int mtd_erase(struct mtd_info *mtd, struct erase_info *instr); + int mtd_point(struct mtd_info *mtd, loff_t from, size_t len, size_t *retlen, + void **virt, resource_size_t *phys); +diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h +index 5a9d1d4..4f7c9b9 100644 +--- a/include/linux/mtd/nand.h ++++ b/include/linux/mtd/nand.h +@@ -719,6 +719,17 @@ struct nand_chip { + void *priv; + }; + ++static inline void nand_set_flash_node(struct nand_chip *chip, ++ struct device_node *np) ++{ ++ chip->flash_node = np; ++} ++ ++static inline struct device_node *nand_get_flash_node(struct nand_chip *chip) ++{ ++ return chip->flash_node; ++} ++ + /* + * NAND Flash Manufacturer ID Codes + */ +diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h +index 12a4611..823c5381 100644 +--- a/include/linux/mtd/spi-nor.h ++++ b/include/linux/mtd/spi-nor.h +@@ -184,6 +184,17 @@ struct spi_nor { + void *priv; + }; + ++static inline void spi_nor_set_flash_node(struct spi_nor *nor, ++ struct device_node *np) ++{ ++ nor->flash_node = np; ++} ++ ++static inline struct device_node *spi_nor_get_flash_node(struct spi_nor *nor) ++{ ++ return nor->flash_node; ++} ++ + /** + * spi_nor_scan() - scan the SPI NOR + * @nor: the spi_nor structure +-- +2.8.1 + diff --git a/target/linux/socfpga/patches-4.4/0007-mtd-nand-spi-nor-assign-MTD-of_node.patch b/target/linux/socfpga/patches-4.4/0007-mtd-nand-spi-nor-assign-MTD-of_node.patch new file mode 100644 index 0000000..c556a64 --- /dev/null +++ b/target/linux/socfpga/patches-4.4/0007-mtd-nand-spi-nor-assign-MTD-of_node.patch @@ -0,0 +1,44 @@ +From 0b3e7c875f3f6ac9127b55eb99817c2f412e164e Mon Sep 17 00:00:00 2001 +From: Brian Norris +Date: Fri, 30 Oct 2015 20:33:22 -0700 +Subject: [PATCH 07/33] mtd: {nand,spi-nor}: assign MTD of_node + +We should pass along our flash DT node to the MTD layer, so it can set +up ofpart for us. + +Signed-off-by: Brian Norris +Reviewed-by: Boris Brezillon +--- + drivers/mtd/nand/nand_base.c | 3 +++ + drivers/mtd/spi-nor/spi-nor.c | 1 + + 2 files changed, 4 insertions(+) + +diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c +index 3ff583f..1f30656 100644 +--- a/drivers/mtd/nand/nand_base.c ++++ b/drivers/mtd/nand/nand_base.c +@@ -3990,6 +3990,9 @@ int nand_scan_ident(struct mtd_info *mtd, int maxchips, + int ret; + + if (chip->flash_node) { ++ /* MTD can automatically handle DT partitions, etc. */ ++ mtd_set_of_node(mtd, chip->flash_node); ++ + ret = nand_dt_init(mtd, chip, chip->flash_node); + if (ret) + return ret; +diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c +index 32477c4..24ad373 100644 +--- a/drivers/mtd/spi-nor/spi-nor.c ++++ b/drivers/mtd/spi-nor/spi-nor.c +@@ -1256,6 +1256,7 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode) + mtd->flags |= MTD_NO_ERASE; + + mtd->dev.parent = dev; ++ mtd_set_of_node(mtd, np); + nor->page_size = info->page_size; + mtd->writebufsize = nor->page_size; + +-- +2.8.1 + diff --git a/target/linux/socfpga/patches-4.4/0008-mtd-spi-nor-convert-to-spi_nor_-get-set-_flash_node.patch b/target/linux/socfpga/patches-4.4/0008-mtd-spi-nor-convert-to-spi_nor_-get-set-_flash_node.patch new file mode 100644 index 0000000..0f4093f --- /dev/null +++ b/target/linux/socfpga/patches-4.4/0008-mtd-spi-nor-convert-to-spi_nor_-get-set-_flash_node.patch @@ -0,0 +1,91 @@ +From bf8554bc3b6b699e9c5b990f63b286b31cf7e80b Mon Sep 17 00:00:00 2001 +From: Brian Norris +Date: Fri, 30 Oct 2015 20:33:24 -0700 +Subject: [PATCH 08/33] mtd: spi-nor: convert to spi_nor_{get, + set}_flash_node() + +Used semantic patch with 'make coccicheck MODE=patch COCCI=script.cocci': + +---8<---- +virtual patch + +@@ +struct spi_nor b; +struct spi_nor *c; +expression d; +@@ +( +-(b).flash_node = (d) ++spi_nor_set_flash_node(&b, d) +| +-(c)->flash_node = (d) ++spi_nor_set_flash_node(c, d) +) +---8<---- + +And a manual conversion for the one use of spi_nor_get_flash_node(). + +Signed-off-by: Brian Norris +Reviewed-by: Boris Brezillon +--- + drivers/mtd/devices/m25p80.c | 2 +- + drivers/mtd/spi-nor/fsl-quadspi.c | 2 +- + drivers/mtd/spi-nor/nxp-spifi.c | 2 +- + drivers/mtd/spi-nor/spi-nor.c | 2 +- + 4 files changed, 4 insertions(+), 4 deletions(-) + +diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c +index fe9ceb7..bc7a802 100644 +--- a/drivers/mtd/devices/m25p80.c ++++ b/drivers/mtd/devices/m25p80.c +@@ -199,7 +199,7 @@ static int m25p_probe(struct spi_device *spi) + nor->read_reg = m25p80_read_reg; + + nor->dev = &spi->dev; +- nor->flash_node = spi->dev.of_node; ++ spi_nor_set_flash_node(nor, spi->dev.of_node); + nor->priv = flash; + + spi_set_drvdata(spi, flash); +diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c b/drivers/mtd/spi-nor/fsl-quadspi.c +index 7b10ed4..8f4d920 100644 +--- a/drivers/mtd/spi-nor/fsl-quadspi.c ++++ b/drivers/mtd/spi-nor/fsl-quadspi.c +@@ -1013,7 +1013,7 @@ static int fsl_qspi_probe(struct platform_device *pdev) + mtd = &nor->mtd; + + nor->dev = dev; +- nor->flash_node = np; ++ spi_nor_set_flash_node(nor, np); + nor->priv = q; + + /* fill the hooks */ +diff --git a/drivers/mtd/spi-nor/nxp-spifi.c b/drivers/mtd/spi-nor/nxp-spifi.c +index 9e82098..4524b28 100644 +--- a/drivers/mtd/spi-nor/nxp-spifi.c ++++ b/drivers/mtd/spi-nor/nxp-spifi.c +@@ -330,7 +330,7 @@ static int nxp_spifi_setup_flash(struct nxp_spifi *spifi, + writel(ctrl, spifi->io_base + SPIFI_CTRL); + + spifi->nor.dev = spifi->dev; +- spifi->nor.flash_node = np; ++ spi_nor_set_flash_node(&spifi->nor, np); + spifi->nor.priv = spifi; + spifi->nor.read = nxp_spifi_read; + spifi->nor.write = nxp_spifi_write; +diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c +index 24ad373..b76090e 100644 +--- a/drivers/mtd/spi-nor/spi-nor.c ++++ b/drivers/mtd/spi-nor/spi-nor.c +@@ -1151,7 +1151,7 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode) + const struct flash_info *info = NULL; + struct device *dev = nor->dev; + struct mtd_info *mtd = &nor->mtd; +- struct device_node *np = nor->flash_node; ++ struct device_node *np = spi_nor_get_flash_node(nor); + int ret; + int i; + +-- +2.8.1 + diff --git a/target/linux/socfpga/patches-4.4/0009-mtd-spi-nor-drop-flash_node-field.patch b/target/linux/socfpga/patches-4.4/0009-mtd-spi-nor-drop-flash_node-field.patch new file mode 100644 index 0000000..1da6c94 --- /dev/null +++ b/target/linux/socfpga/patches-4.4/0009-mtd-spi-nor-drop-flash_node-field.patch @@ -0,0 +1,64 @@ +From 1348b9e2300f66a4ffcb5b467f4c99cfb958ffca Mon Sep 17 00:00:00 2001 +From: Brian Norris +Date: Fri, 30 Oct 2015 20:33:27 -0700 +Subject: [PATCH 09/33] mtd: spi-nor: drop flash_node field + +We can just alias to the MTD of_node. + +Signed-off-by: Brian Norris +Reviewed-by: Boris Brezillon +--- + drivers/mtd/spi-nor/spi-nor.c | 1 - + include/linux/mtd/spi-nor.h | 6 ++---- + 2 files changed, 2 insertions(+), 5 deletions(-) + +diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c +index b76090e..3e06d5b 100644 +--- a/drivers/mtd/spi-nor/spi-nor.c ++++ b/drivers/mtd/spi-nor/spi-nor.c +@@ -1256,7 +1256,6 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode) + mtd->flags |= MTD_NO_ERASE; + + mtd->dev.parent = dev; +- mtd_set_of_node(mtd, np); + nor->page_size = info->page_size; + mtd->writebufsize = nor->page_size; + +diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h +index 823c5381..592420b 100644 +--- a/include/linux/mtd/spi-nor.h ++++ b/include/linux/mtd/spi-nor.h +@@ -123,7 +123,6 @@ enum spi_nor_option_flags { + * @mtd: point to a mtd_info structure + * @lock: the lock for the read/write/erase/lock/unlock operations + * @dev: point to a spi device, or a spi nor controller device. +- * @flash_node: point to a device node describing this flash instance. + * @page_size: the page size of the SPI NOR + * @addr_width: number of address bytes + * @erase_opcode: the opcode for erasing a sector +@@ -154,7 +153,6 @@ struct spi_nor { + struct mtd_info mtd; + struct mutex lock; + struct device *dev; +- struct device_node *flash_node; + u32 page_size; + u8 addr_width; + u8 erase_opcode; +@@ -187,12 +185,12 @@ struct spi_nor { + static inline void spi_nor_set_flash_node(struct spi_nor *nor, + struct device_node *np) + { +- nor->flash_node = np; ++ mtd_set_of_node(&nor->mtd, np); + } + + static inline struct device_node *spi_nor_get_flash_node(struct spi_nor *nor) + { +- return nor->flash_node; ++ return mtd_get_of_node(&nor->mtd); + } + + /** +-- +2.8.1 + diff --git a/target/linux/socfpga/patches-4.4/0010-mtd-spi-nor-remove-unnecessary-leading-space-from-db.patch b/target/linux/socfpga/patches-4.4/0010-mtd-spi-nor-remove-unnecessary-leading-space-from-db.patch new file mode 100644 index 0000000..19b22c5 --- /dev/null +++ b/target/linux/socfpga/patches-4.4/0010-mtd-spi-nor-remove-unnecessary-leading-space-from-db.patch @@ -0,0 +1,32 @@ +From f8c5645dd28440380622c2ad3744de0b55bd0bdf Mon Sep 17 00:00:00 2001 +From: Brian Norris +Date: Fri, 30 Oct 2015 12:56:22 -0700 +Subject: [PATCH 10/33] mtd: spi-nor: remove unnecessary leading space from dbg + print + +As Cyrille noted [1], this line is wrong. + +[1] http://lists.infradead.org/pipermail/linux-mtd/2015-September/061725.html + +Signed-off-by: Brian Norris +Cc: Cyrille Pitchen +--- + drivers/mtd/spi-nor/spi-nor.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c +index 3e06d5b..107571e 100644 +--- a/drivers/mtd/spi-nor/spi-nor.c ++++ b/drivers/mtd/spi-nor/spi-nor.c +@@ -856,7 +856,7 @@ static const struct flash_info *spi_nor_read_id(struct spi_nor *nor) + + tmp = nor->read_reg(nor, SPINOR_OP_RDID, id, SPI_NOR_MAX_ID_LEN); + if (tmp < 0) { +- dev_dbg(nor->dev, " error %d reading JEDEC ID\n", tmp); ++ dev_dbg(nor->dev, "error %d reading JEDEC ID\n", tmp); + return ERR_PTR(tmp); + } + +-- +2.8.1 + diff --git a/target/linux/socfpga/patches-4.4/0011-mtd-spi-nor-provide-default-erase_sector-implementat.patch b/target/linux/socfpga/patches-4.4/0011-mtd-spi-nor-provide-default-erase_sector-implementat.patch new file mode 100644 index 0000000..666b069 --- /dev/null +++ b/target/linux/socfpga/patches-4.4/0011-mtd-spi-nor-provide-default-erase_sector-implementat.patch @@ -0,0 +1,112 @@ +From 29675718c3880cbe7a8d8c6819c07dcec656c544 Mon Sep 17 00:00:00 2001 +From: Brian Norris +Date: Tue, 10 Nov 2015 12:15:27 -0800 +Subject: [PATCH 11/33] mtd: spi-nor: provide default erase_sector + implementation + +Some spi-nor drivers perform sector erase by duplicating their +write_reg() command. Let's not require that the driver fill this out, +and provide a default instead. + +Tested on m25p80.c and Medatek's MT8173 SPI NOR flash driver. + +Signed-off-by: Brian Norris +--- + drivers/mtd/spi-nor/spi-nor.c | 37 +++++++++++++++++++++++++++++++++---- + include/linux/mtd/spi-nor.h | 3 ++- + 2 files changed, 35 insertions(+), 5 deletions(-) + +diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c +index 107571e..0d2be38 100644 +--- a/drivers/mtd/spi-nor/spi-nor.c ++++ b/drivers/mtd/spi-nor/spi-nor.c +@@ -38,6 +38,7 @@ + #define CHIP_ERASE_2MB_READY_WAIT_JIFFIES (40UL * HZ) + + #define SPI_NOR_MAX_ID_LEN 6 ++#define SPI_NOR_MAX_ADDR_WIDTH 4 + + struct flash_info { + char *name; +@@ -313,6 +314,29 @@ static void spi_nor_unlock_and_unprep(struct spi_nor *nor, enum spi_nor_ops ops) + } + + /* ++ * Initiate the erasure of a single sector ++ */ ++static int spi_nor_erase_sector(struct spi_nor *nor, u32 addr) ++{ ++ u8 buf[SPI_NOR_MAX_ADDR_WIDTH]; ++ int i; ++ ++ if (nor->erase) ++ return nor->erase(nor, addr); ++ ++ /* ++ * Default implementation, if driver doesn't have a specialized HW ++ * control ++ */ ++ for (i = nor->addr_width - 1; i >= 0; i--) { ++ buf[i] = addr & 0xff; ++ addr >>= 8; ++ } ++ ++ return nor->write_reg(nor, nor->erase_opcode, buf, nor->addr_width); ++} ++ ++/* + * Erase an address range on the nor chip. The address range may extend + * one or more erase sectors. Return an error is there is a problem erasing. + */ +@@ -371,10 +395,9 @@ static int spi_nor_erase(struct mtd_info *mtd, struct erase_info *instr) + while (len) { + write_enable(nor); + +- if (nor->erase(nor, addr)) { +- ret = -EIO; ++ ret = spi_nor_erase_sector(nor, addr); ++ if (ret) + goto erase_err; +- } + + addr += mtd->erasesize; + len -= mtd->erasesize; +@@ -1138,7 +1161,7 @@ static int set_quad_mode(struct spi_nor *nor, const struct flash_info *info) + static int spi_nor_check(struct spi_nor *nor) + { + if (!nor->dev || !nor->read || !nor->write || +- !nor->read_reg || !nor->write_reg || !nor->erase) { ++ !nor->read_reg || !nor->write_reg) { + pr_err("spi-nor: please fill all the necessary fields!\n"); + return -EINVAL; + } +@@ -1338,6 +1361,12 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode) + nor->addr_width = 3; + } + ++ if (nor->addr_width > SPI_NOR_MAX_ADDR_WIDTH) { ++ dev_err(dev, "address width is too large: %u\n", ++ nor->addr_width); ++ return -EINVAL; ++ } ++ + nor->read_dummy = spi_nor_read_dummy_cycles(nor); + + dev_info(dev, "%s (%lld Kbytes)\n", info->name, +diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h +index 592420b..62356d5 100644 +--- a/include/linux/mtd/spi-nor.h ++++ b/include/linux/mtd/spi-nor.h +@@ -142,7 +142,8 @@ enum spi_nor_option_flags { + * @read: [DRIVER-SPECIFIC] read data from the SPI NOR + * @write: [DRIVER-SPECIFIC] write data to the SPI NOR + * @erase: [DRIVER-SPECIFIC] erase a sector of the SPI NOR +- * at the offset @offs ++ * at the offset @offs; if not provided by the driver, ++ * spi-nor will send the erase opcode via write_reg() + * @flash_lock: [FLASH-SPECIFIC] lock a region of the SPI NOR + * @flash_unlock: [FLASH-SPECIFIC] unlock a region of the SPI NOR + * @flash_is_locked: [FLASH-SPECIFIC] check if a region of the SPI NOR is +-- +2.8.1 + diff --git a/target/linux/socfpga/patches-4.4/0012-mtd-spi-nor-mx25l3205d-mx25l6405d-append-SECT_4K.patch b/target/linux/socfpga/patches-4.4/0012-mtd-spi-nor-mx25l3205d-mx25l6405d-append-SECT_4K.patch new file mode 100644 index 0000000..720d687 --- /dev/null +++ b/target/linux/socfpga/patches-4.4/0012-mtd-spi-nor-mx25l3205d-mx25l6405d-append-SECT_4K.patch @@ -0,0 +1,32 @@ +From 655585649ba3f4675b4386afc1feb22c6a880eb8 Mon Sep 17 00:00:00 2001 +From: Andreas Fenkart +Date: Thu, 5 Nov 2015 10:04:23 +0100 +Subject: [PATCH 12/33] mtd: spi-nor: mx25l3205d/mx25l6405d: append SECT_4K + +according datasheet both chips can erase 4kByte sectors individually + +Signed-off-by: Andreas Fenkart +Signed-off-by: Brian Norris +--- + drivers/mtd/spi-nor/spi-nor.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c +index 0d2be38..c5bc927 100644 +--- a/drivers/mtd/spi-nor/spi-nor.c ++++ b/drivers/mtd/spi-nor/spi-nor.c +@@ -738,9 +738,9 @@ static const struct flash_info spi_nor_ids[] = { + { "mx25l4005a", INFO(0xc22013, 0, 64 * 1024, 8, SECT_4K) }, + { "mx25l8005", INFO(0xc22014, 0, 64 * 1024, 16, 0) }, + { "mx25l1606e", INFO(0xc22015, 0, 64 * 1024, 32, SECT_4K) }, +- { "mx25l3205d", INFO(0xc22016, 0, 64 * 1024, 64, 0) }, ++ { "mx25l3205d", INFO(0xc22016, 0, 64 * 1024, 64, SECT_4K) }, + { "mx25l3255e", INFO(0xc29e16, 0, 64 * 1024, 64, SECT_4K) }, +- { "mx25l6405d", INFO(0xc22017, 0, 64 * 1024, 128, 0) }, ++ { "mx25l6405d", INFO(0xc22017, 0, 64 * 1024, 128, SECT_4K) }, + { "mx25u6435f", INFO(0xc22537, 0, 64 * 1024, 128, SECT_4K) }, + { "mx25l12805d", INFO(0xc22018, 0, 64 * 1024, 256, 0) }, + { "mx25l12855e", INFO(0xc22618, 0, 64 * 1024, 256, 0) }, +-- +2.8.1 + diff --git a/target/linux/socfpga/patches-4.4/0013-mtd-spi-nor-Fix-error-message-with-unrecognized-JEDE.patch b/target/linux/socfpga/patches-4.4/0013-mtd-spi-nor-Fix-error-message-with-unrecognized-JEDE.patch new file mode 100644 index 0000000..1fd8955 --- /dev/null +++ b/target/linux/socfpga/patches-4.4/0013-mtd-spi-nor-Fix-error-message-with-unrecognized-JEDE.patch @@ -0,0 +1,35 @@ +From 14b9112f7d20455ffef7d796317e7d08c6545b41 Mon Sep 17 00:00:00 2001 +From: Ricardo Ribalda +Date: Mon, 30 Nov 2015 20:41:17 +0100 +Subject: [PATCH 13/33] mtd: spi-nor: Fix error message with unrecognized JEDEC + +The error message was: + +m25p80 spi32766.0: unrecognized JEDEC id bytes: 00, 0, 0 + +The new error message: + +m25p80 spi32766.0: unrecognized JEDEC id bytes: 00, 00, 00 + +Signed-off-by: Ricardo Ribalda Delgado +Signed-off-by: Brian Norris +--- + drivers/mtd/spi-nor/spi-nor.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c +index c5bc927..3a50eea 100644 +--- a/drivers/mtd/spi-nor/spi-nor.c ++++ b/drivers/mtd/spi-nor/spi-nor.c +@@ -890,7 +890,7 @@ static const struct flash_info *spi_nor_read_id(struct spi_nor *nor) + return &spi_nor_ids[tmp]; + } + } +- dev_err(nor->dev, "unrecognized JEDEC id bytes: %02x, %2x, %2x\n", ++ dev_err(nor->dev, "unrecognized JEDEC id bytes: %02x, %02x, %02x\n", + id[0], id[1], id[2]); + return ERR_PTR(-ENODEV); + } +-- +2.8.1 + diff --git a/target/linux/socfpga/patches-4.4/0014-mtd-spi-nor-fix-error-handling-in-spi_nor_erase.patch b/target/linux/socfpga/patches-4.4/0014-mtd-spi-nor-fix-error-handling-in-spi_nor_erase.patch new file mode 100644 index 0000000..c9f48ea --- /dev/null +++ b/target/linux/socfpga/patches-4.4/0014-mtd-spi-nor-fix-error-handling-in-spi_nor_erase.patch @@ -0,0 +1,44 @@ +From 93aa2e2f5af5b8e766fc22c3ff83a1642462025f Mon Sep 17 00:00:00 2001 +From: Heiner Kallweit +Date: Tue, 17 Nov 2015 20:18:54 +0100 +Subject: [PATCH 14/33] mtd: spi-nor: fix error handling in spi_nor_erase + +The documenting comment of mtd_erase in mtdcore.c states: +Device drivers are supposed to call instr->callback() whenever +the operation completes, even if it completes with a failure. + +Currently the callback isn't called in case of failure. Fix this. + +Signed-off-by: Heiner Kallweit +Signed-off-by: Brian Norris +--- + drivers/mtd/spi-nor/spi-nor.c | 8 ++------ + 1 file changed, 2 insertions(+), 6 deletions(-) + +diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c +index 3a50eea..43e00e2 100644 +--- a/drivers/mtd/spi-nor/spi-nor.c ++++ b/drivers/mtd/spi-nor/spi-nor.c +@@ -410,17 +410,13 @@ static int spi_nor_erase(struct mtd_info *mtd, struct erase_info *instr) + + write_disable(nor); + ++erase_err: + spi_nor_unlock_and_unprep(nor, SPI_NOR_OPS_ERASE); + +- instr->state = MTD_ERASE_DONE; ++ instr->state = ret ? MTD_ERASE_FAILED : MTD_ERASE_DONE; + mtd_erase_callback(instr); + + return ret; +- +-erase_err: +- spi_nor_unlock_and_unprep(nor, SPI_NOR_OPS_ERASE); +- instr->state = MTD_ERASE_FAILED; +- return ret; + } + + static void stm_get_locked_range(struct spi_nor *nor, u8 sr, loff_t *ofs, +-- +2.8.1 + diff --git a/target/linux/socfpga/patches-4.4/0015-mtd-spi-nor-Check-the-return-value-from-read_sr.patch b/target/linux/socfpga/patches-4.4/0015-mtd-spi-nor-Check-the-return-value-from-read_sr.patch new file mode 100644 index 0000000..bfb5a97 --- /dev/null +++ b/target/linux/socfpga/patches-4.4/0015-mtd-spi-nor-Check-the-return-value-from-read_sr.patch @@ -0,0 +1,60 @@ +From 8f5f914b1b6d70d6d7455e0f89df84b3377677f9 Mon Sep 17 00:00:00 2001 +From: Fabio Estevam +Date: Fri, 20 Nov 2015 16:26:11 -0200 +Subject: [PATCH 15/33] mtd: spi-nor: Check the return value from read_sr() + +We should better check the return value from read_sr() and +propagate it in the case of error. + +Signed-off-by: Fabio Estevam +Signed-off-by: Brian Norris +--- + drivers/mtd/spi-nor/spi-nor.c | 10 ++++++++-- + 1 file changed, 8 insertions(+), 2 deletions(-) + +diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c +index 43e00e2..f8f36d4 100644 +--- a/drivers/mtd/spi-nor/spi-nor.c ++++ b/drivers/mtd/spi-nor/spi-nor.c +@@ -478,11 +478,13 @@ static int stm_is_locked_sr(struct spi_nor *nor, loff_t ofs, uint64_t len, + static int stm_lock(struct spi_nor *nor, loff_t ofs, uint64_t len) + { + struct mtd_info *mtd = &nor->mtd; +- u8 status_old, status_new; ++ int status_old, status_new; + u8 mask = SR_BP2 | SR_BP1 | SR_BP0; + u8 shift = ffs(mask) - 1, pow, val; + + status_old = read_sr(nor); ++ if (status_old < 0) ++ return status_old; + + /* SPI NOR always locks to the end */ + if (ofs + len != mtd->size) { +@@ -528,11 +530,13 @@ static int stm_lock(struct spi_nor *nor, loff_t ofs, uint64_t len) + static int stm_unlock(struct spi_nor *nor, loff_t ofs, uint64_t len) + { + struct mtd_info *mtd = &nor->mtd; +- uint8_t status_old, status_new; ++ int status_old, status_new; + u8 mask = SR_BP2 | SR_BP1 | SR_BP0; + u8 shift = ffs(mask) - 1, pow, val; + + status_old = read_sr(nor); ++ if (status_old < 0) ++ return status_old; + + /* Cannot unlock; would unlock larger region than requested */ + if (stm_is_locked_sr(nor, ofs - mtd->erasesize, mtd->erasesize, +@@ -1032,6 +1036,8 @@ static int macronix_quad_enable(struct spi_nor *nor) + int ret, val; + + val = read_sr(nor); ++ if (val < 0) ++ return val; + write_enable(nor); + + write_sr(nor, val | SR_QUAD_EN_MX); +-- +2.8.1 + diff --git a/target/linux/socfpga/patches-4.4/0016-mtd-spi-nor-remove-micron_quad_enable.patch b/target/linux/socfpga/patches-4.4/0016-mtd-spi-nor-remove-micron_quad_enable.patch new file mode 100644 index 0000000..48ceb8e --- /dev/null +++ b/target/linux/socfpga/patches-4.4/0016-mtd-spi-nor-remove-micron_quad_enable.patch @@ -0,0 +1,110 @@ +From 246e2a5cc60e2179bf8849310b7af9eaa5c505f9 Mon Sep 17 00:00:00 2001 +From: Cyrille Pitchen +Date: Fri, 8 Jan 2016 17:02:13 +0100 +Subject: [PATCH 16/33] mtd: spi-nor: remove micron_quad_enable() + +This patch remove the micron_quad_enable() function which force the Quad +SPI mode. However, once this mode is enabled, the Micron memory expect ALL +commands to use the SPI 4-4-4 protocol. Hence a failure does occur when +calling spi_nor_wait_till_ready() right after the update of the Enhanced +Volatile Configuration Register (EVCR) in the micron_quad_enable() as +the SPI controller driver is not aware about the protocol change. + +Since there is almost no performance increase using Fast Read 4-4-4 +commands instead of Fast Read 1-1-4 commands, we rather keep on using the +Extended SPI mode than enabling the Quad SPI mode. + +Let's take the example of the pretty standard use of 8 dummy cycles during +Fast Read operations on 64KB erase sectors: + +Fast Read 1-1-4 requires 8 cycles for the command, then 24 cycles for the +3byte address followed by 8 dummy clock cycles and finally 65536*2 cycles +for the read data; so 131112 clock cycles. + +On the other hand the Fast Read 4-4-4 would require 2 cycles for the +command, then 6 cycles for the 3byte address followed by 8 dummy clock +cycles and finally 65536*2 cycles for the read data. So 131088 clock +cycles. The theorical bandwidth increase is 0.0%. + +Now using Fast Read operations on 512byte pages: +Fast Read 1-1-4 needs 8+24+8+(512*2) = 1064 clock cycles whereas Fast +Read 4-4-4 would requires 2+6+8+(512*2) = 1040 clock cycles. Hence the +theorical bandwidth increase is 2.3%. +Consecutive reads for non sequential pages is not a relevant use case so +The Quad SPI mode is not worth it. + +mtd_speedtest seems to confirm these figures. + +Signed-off-by: Cyrille Pitchen +Fixes: 548cd3ab54da ("mtd: spi-nor: Add quad I/O support for Micron SPI NOR") +--- + drivers/mtd/spi-nor/spi-nor.c | 46 +------------------------------------------ + 1 file changed, 1 insertion(+), 45 deletions(-) + +diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c +index f8f36d4..6e72e96 100644 +--- a/drivers/mtd/spi-nor/spi-nor.c ++++ b/drivers/mtd/spi-nor/spi-nor.c +@@ -1092,45 +1092,6 @@ static int spansion_quad_enable(struct spi_nor *nor) + return 0; + } + +-static int micron_quad_enable(struct spi_nor *nor) +-{ +- int ret; +- u8 val; +- +- ret = nor->read_reg(nor, SPINOR_OP_RD_EVCR, &val, 1); +- if (ret < 0) { +- dev_err(nor->dev, "error %d reading EVCR\n", ret); +- return ret; +- } +- +- write_enable(nor); +- +- /* set EVCR, enable quad I/O */ +- nor->cmd_buf[0] = val & ~EVCR_QUAD_EN_MICRON; +- ret = nor->write_reg(nor, SPINOR_OP_WD_EVCR, nor->cmd_buf, 1); +- if (ret < 0) { +- dev_err(nor->dev, "error while writing EVCR register\n"); +- return ret; +- } +- +- ret = spi_nor_wait_till_ready(nor); +- if (ret) +- return ret; +- +- /* read EVCR and check it */ +- ret = nor->read_reg(nor, SPINOR_OP_RD_EVCR, &val, 1); +- if (ret < 0) { +- dev_err(nor->dev, "error %d reading EVCR\n", ret); +- return ret; +- } +- if (val & EVCR_QUAD_EN_MICRON) { +- dev_err(nor->dev, "Micron EVCR Quad bit not clear\n"); +- return -EINVAL; +- } +- +- return 0; +-} +- + static int set_quad_mode(struct spi_nor *nor, const struct flash_info *info) + { + int status; +@@ -1144,12 +1105,7 @@ static int set_quad_mode(struct spi_nor *nor, const struct flash_info *info) + } + return status; + case SNOR_MFR_MICRON: +- status = micron_quad_enable(nor); +- if (status) { +- dev_err(nor->dev, "Micron quad-read not enabled\n"); +- return -EINVAL; +- } +- return status; ++ return 0; + default: + status = spansion_quad_enable(nor); + if (status) { +-- +2.8.1 + diff --git a/target/linux/socfpga/patches-4.4/0017-mtd-spi-nor-properly-detect-the-memory-when-it-boots.patch b/target/linux/socfpga/patches-4.4/0017-mtd-spi-nor-properly-detect-the-memory-when-it-boots.patch new file mode 100644 index 0000000..63cd47e --- /dev/null +++ b/target/linux/socfpga/patches-4.4/0017-mtd-spi-nor-properly-detect-the-memory-when-it-boots.patch @@ -0,0 +1,244 @@ +From 06883bee58d1beedef783f7f5662367736d90924 Mon Sep 17 00:00:00 2001 +From: Cyrille Pitchen +Date: Fri, 8 Jan 2016 17:02:14 +0100 +Subject: [PATCH 17/33] mtd: spi-nor: properly detect the memory when it boots + in Quad or Dual mode + +The quad (or dual) mode of a spi-nor memory may be enabled at boot time by +non-volatile bits in some setting register. Also such a mode may have +already been enabled at early stage by some boot loader. + +Hence, we should not guess the spi-nor memory is always configured for the +regular SPI 1-1-1 protocol. + +Micron and Macronix memories, once their Quad (or dual for Micron) mode +enabled, no longer process the regular JEDEC Read ID (0x9f) command but +instead reply to a new command: JEDEC Read ID Multiple I/O (0xaf). +Besides, in Quad mode both memory manufacturers expect ALL commands to +use the SPI 4-4-4 protocol. For Micron memories, enabling their Dual mode +implies to use the SPI 2-2-2 protocol for ALL commands. + +Winbond memories, once their Quad mode enabled, expect ALL commands to use +the SPI 4-4-4 protocol. Unlike Micron and Macronix memories, they still +reply to the regular JEDEC Read ID (0x9f) command. + +Signed-off-by: Cyrille Pitchen +--- + drivers/mtd/spi-nor/spi-nor.c | 83 ++++++++++++++++++++++++++++++++++++++++--- + include/linux/mtd/spi-nor.h | 50 ++++++++++++++++++++++++-- + 2 files changed, 127 insertions(+), 6 deletions(-) + +diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c +index 6e72e96..9ad2d40 100644 +--- a/drivers/mtd/spi-nor/spi-nor.c ++++ b/drivers/mtd/spi-nor/spi-nor.c +@@ -73,6 +73,12 @@ struct flash_info { + + #define JEDEC_MFR(info) ((info)->id[0]) + ++struct read_id_config { ++ enum read_mode mode; ++ enum spi_nor_protocol proto; ++ u8 opcode; ++}; ++ + static const struct flash_info *spi_nor_match_id(const char *name); + + /* +@@ -871,11 +877,22 @@ static const struct flash_info spi_nor_ids[] = { + { }, + }; + +-static const struct flash_info *spi_nor_read_id(struct spi_nor *nor) ++static const struct flash_info *spi_nor_read_id(struct spi_nor *nor, ++ enum read_mode mode) + { +- int tmp; ++ int i, tmp; + u8 id[SPI_NOR_MAX_ID_LEN]; + const struct flash_info *info; ++ static const struct read_id_config configs[] = { ++ /* Winbond QPI mode */ ++ {SPI_NOR_QUAD, SNOR_PROTO_4_4_4, SPINOR_OP_RDID}, ++ ++ /* Micron Quad mode & Macronix QPI mode */ ++ {SPI_NOR_QUAD, SNOR_PROTO_4_4_4, SPINOR_OP_MIO_RDID}, ++ ++ /* Micron Dual mode */ ++ {SPI_NOR_DUAL, SNOR_PROTO_2_2_2, SPINOR_OP_MIO_RDID} ++ }; + + tmp = nor->read_reg(nor, SPINOR_OP_RDID, id, SPI_NOR_MAX_ID_LEN); + if (tmp < 0) { +@@ -883,6 +900,58 @@ static const struct flash_info *spi_nor_read_id(struct spi_nor *nor) + return ERR_PTR(tmp); + } + ++ /* ++ * Check whether the SPI NOR memory has already been configured (at ++ * reset or by some bootloader) to use a protocol other than SPI 1-1-1. ++ */ ++ for (i = 0; i < ARRAY_SIZE(configs); ++i) { ++ int len = SPI_NOR_MAX_ID_LEN; ++ bool is_multi = false; ++ ++ /* ++ * Check the latest read Manufacturer ID + Device ID (3 bytes): ++ * if they are different from both 0x000000 and 0xffffff, we ++ * assume that we succeeded in reading a valid JEDEC ID so we ++ * don't need to try other SPI protocols. ++ * Indeed when either the protocol or the op code are not valid, ++ * the SPI NOR memory should not reply to the command. Hence the ++ * SPI I/O lines remain in their default state: 1 when connected ++ * to pull-up resistors or 0 with pull-down. ++ */ ++ if (!((id[0] == 0xff && id[1] == 0xff && id[2] == 0xff) || ++ (id[0] == 0x00 && id[1] == 0x00 && id[2] == 0x00))) ++ break; ++ ++ /* Only try protocols supported by the user. */ ++ if (configs[i].mode != mode) ++ continue; ++ ++ /* Set this protocol for all commands. */ ++ nor->reg_proto = configs[i].proto; ++ nor->read_proto = configs[i].proto; ++ nor->write_proto = configs[i].proto; ++ nor->erase_proto = configs[i].proto; ++ ++ /* ++ * Multiple I/O Read ID only returns the Manufacturer ID ++ * (1 byte) and the Device ID (2 bytes). So we reset the ++ * remaining bytes. ++ */ ++ if (configs[i].opcode == SPINOR_OP_MIO_RDID) { ++ is_multi = true; ++ len = 3; ++ memset(id + len, 0, sizeof(id) - len); ++ } ++ ++ tmp = nor->read_reg(nor, configs[i].opcode, id, len); ++ if (tmp < 0) { ++ dev_dbg(nor->dev, ++ "error %d reading JEDEC ID%s\n", ++ tmp, (is_multi ? " Multi I/O" : "")); ++ return ERR_PTR(tmp); ++ } ++ } ++ + for (tmp = 0; tmp < ARRAY_SIZE(spi_nor_ids) - 1; tmp++) { + info = &spi_nor_ids[tmp]; + if (info->id_len) { +@@ -1140,11 +1209,17 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode) + if (ret) + return ret; + ++ /* Reset SPI protocol for all commands */ ++ nor->erase_proto = SNOR_PROTO_1_1_1; ++ nor->read_proto = SNOR_PROTO_1_1_1; ++ nor->write_proto = SNOR_PROTO_1_1_1; ++ nor->reg_proto = SNOR_PROTO_1_1_1; ++ + if (name) + info = spi_nor_match_id(name); + /* Try to auto-detect if chip name wasn't specified or not found */ + if (!info) +- info = spi_nor_read_id(nor); ++ info = spi_nor_read_id(nor, mode); + if (IS_ERR_OR_NULL(info)) + return -ENOENT; + +@@ -1155,7 +1230,7 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode) + if (name && info->id_len) { + const struct flash_info *jinfo; + +- jinfo = spi_nor_read_id(nor); ++ jinfo = spi_nor_read_id(nor, mode); + if (IS_ERR(jinfo)) { + return PTR_ERR(jinfo); + } else if (jinfo != info) { +diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h +index 62356d5..53932c8 100644 +--- a/include/linux/mtd/spi-nor.h ++++ b/include/linux/mtd/spi-nor.h +@@ -75,8 +75,9 @@ + #define SPINOR_OP_BRWR 0x17 /* Bank register write */ + + /* Used for Micron flashes only. */ +-#define SPINOR_OP_RD_EVCR 0x65 /* Read EVCR register */ +-#define SPINOR_OP_WD_EVCR 0x61 /* Write EVCR register */ ++#define SPINOR_OP_MIO_RDID 0xaf /* Multiple I/O Read JEDEC ID */ ++#define SPINOR_OP_RD_EVCR 0x65 /* Read EVCR register */ ++#define SPINOR_OP_WD_EVCR 0x61 /* Write EVCR register */ + + /* Status Register bits. */ + #define SR_WIP BIT(0) /* Write in progress */ +@@ -105,6 +106,43 @@ enum read_mode { + SPI_NOR_QUAD, + }; + ++ ++#define SNOR_PROTO_CMD_OFF 8 ++#define SNOR_PROTO_CMD_MASK GENMASK(11, 8) ++#define SNOR_PROTO_CMD_TO_PROTO(cmd) \ ++ (((cmd) << SNOR_PROTO_CMD_OFF) & SNOR_PROTO_CMD_MASK) ++#define SNOR_PROTO_CMD_FROM_PROTO(proto) \ ++ ((((u32)(proto)) & SNOR_PROTO_CMD_MASK) >> SNOR_PROTO_CMD_OFF) ++ ++#define SNOR_PROTO_ADDR_OFF 4 ++#define SNOR_PROTO_ADDR_MASK GENMASK(7, 4) ++#define SNOR_PROTO_ADDR_TO_PROTO(addr) \ ++ (((addr) << SNOR_PROTO_ADDR_OFF) & SNOR_PROTO_ADDR_MASK) ++#define SNOR_PROTO_ADDR_FROM_PROTO(proto) \ ++ ((((u32)(proto)) & SNOR_PROTO_ADDR_MASK) >> SNOR_PROTO_ADDR_OFF) ++ ++#define SNOR_PROTO_DATA_OFF 0 ++#define SNOR_PROTO_DATA_MASK GENMASK(3, 0) ++#define SNOR_PROTO_DATA_TO_PROTO(data) \ ++ (((data) << SNOR_PROTO_DATA_OFF) & SNOR_PROTO_DATA_MASK) ++#define SNOR_PROTO_DATA_FROM_PROTO(proto) \ ++ ((((u32)(proto)) & SNOR_PROTO_DATA_MASK) >> SNOR_PROTO_DATA_OFF) ++ ++#define SNOR_PROTO(cmd, addr, data) \ ++ (SNOR_PROTO_CMD_TO_PROTO(cmd) | \ ++ SNOR_PROTO_ADDR_TO_PROTO(addr) | \ ++ SNOR_PROTO_DATA_TO_PROTO(data)) ++ ++enum spi_nor_protocol { ++ SNOR_PROTO_1_1_1 = SNOR_PROTO(1, 1, 1), /* SPI */ ++ SNOR_PROTO_1_1_2 = SNOR_PROTO(1, 1, 2), /* Dual Output */ ++ SNOR_PROTO_1_1_4 = SNOR_PROTO(1, 1, 4), /* Quad Output */ ++ SNOR_PROTO_1_2_2 = SNOR_PROTO(1, 2, 2), /* Dual IO */ ++ SNOR_PROTO_1_4_4 = SNOR_PROTO(1, 4, 4), /* Quad IO */ ++ SNOR_PROTO_2_2_2 = SNOR_PROTO(2, 2, 2), /* Dual Command */ ++ SNOR_PROTO_4_4_4 = SNOR_PROTO(4, 4, 4), /* Quad Command */ ++}; ++ + #define SPI_NOR_MAX_CMD_SIZE 8 + enum spi_nor_ops { + SPI_NOR_OPS_READ = 0, +@@ -132,6 +170,10 @@ enum spi_nor_option_flags { + * @flash_read: the mode of the read + * @sst_write_second: used by the SST write operation + * @flags: flag options for the current SPI-NOR (SNOR_F_*) ++ * @erase_proto: the SPI protocol used by erase operations ++ * @read_proto: the SPI protocol used by read operations ++ * @write_proto: the SPI protocol used by write operations ++ * @reg_proto the SPI protocol used by read_reg/write_reg operations + * @cmd_buf: used by the write_reg + * @prepare: [OPTIONAL] do some preparations for the + * read/write/erase/lock/unlock operations +@@ -160,6 +202,10 @@ struct spi_nor { + u8 read_opcode; + u8 read_dummy; + u8 program_opcode; ++ enum spi_nor_protocol erase_proto; ++ enum spi_nor_protocol read_proto; ++ enum spi_nor_protocol write_proto; ++ enum spi_nor_protocol reg_proto; + enum read_mode flash_read; + bool sst_write_second; + u32 flags; +-- +2.8.1 + diff --git a/target/linux/socfpga/patches-4.4/0018-mtd-spi-nor-select-op-codes-and-SPI-NOR-protocols-by.patch b/target/linux/socfpga/patches-4.4/0018-mtd-spi-nor-select-op-codes-and-SPI-NOR-protocols-by.patch new file mode 100644 index 0000000..5adef1e --- /dev/null +++ b/target/linux/socfpga/patches-4.4/0018-mtd-spi-nor-select-op-codes-and-SPI-NOR-protocols-by.patch @@ -0,0 +1,203 @@ +From a27dc343ea2de9283ca057fbcafa12a279a19b7b Mon Sep 17 00:00:00 2001 +From: Cyrille Pitchen +Date: Fri, 8 Jan 2016 17:02:15 +0100 +Subject: [PATCH 18/33] mtd: spi-nor: select op codes and SPI NOR protocols by + manufacturer + +This is a transitional patch to prepare the split by Manufacturer of the +support of Single/Dual/Quad SPI modes. + +Indeed every QSPI NOR manufacturer (Spansion, Micron, Macronix, Winbond) +supports Dual or Quad SPI modes on its way. Especially the Fast Read op +code and the SPI NOR protocols to use are not quite the same depending on +the manufacturer. + +For instance Quad commands can use either the SPI 1-1-4, 1-4-4 or 4-4-4 +protocol. + +This is why this patch will be completed by fixes for each manufacturer. + +Signed-off-by: Cyrille Pitchen +--- + drivers/mtd/spi-nor/spi-nor.c | 110 ++++++++++++++++++++++++++++++++---------- + include/linux/mtd/spi-nor.h | 12 +++-- + 2 files changed, 92 insertions(+), 30 deletions(-) + +diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c +index 9ad2d40..889af12 100644 +--- a/drivers/mtd/spi-nor/spi-nor.c ++++ b/drivers/mtd/spi-nor/spi-nor.c +@@ -1172,17 +1172,61 @@ static int set_quad_mode(struct spi_nor *nor, const struct flash_info *info) + dev_err(nor->dev, "Macronix quad-read not enabled\n"); + return -EINVAL; + } +- return status; ++ /* Check whether Macronix QPI mode is enabled. */ ++ if (nor->read_proto != SNOR_PROTO_4_4_4) ++ nor->read_proto = SNOR_PROTO_1_1_4; ++ break; ++ + case SNOR_MFR_MICRON: +- return 0; +- default: ++ /* Check whether Micron Quad mode is enabled. */ ++ if (nor->read_proto != SNOR_PROTO_4_4_4) ++ nor->read_proto = SNOR_PROTO_1_1_4; ++ break; ++ ++ case SNOR_MFR_SPANSION: + status = spansion_quad_enable(nor); + if (status) { + dev_err(nor->dev, "Spansion quad-read not enabled\n"); + return -EINVAL; + } +- return status; ++ nor->read_proto = SNOR_PROTO_1_1_4; ++ break; ++ ++ default: ++ return -EINVAL; + } ++ ++ nor->read_opcode = SPINOR_OP_READ_1_1_4; ++ return 0; ++} ++ ++static int set_dual_mode(struct spi_nor *nor, const struct flash_info *info) ++{ ++ switch (JEDEC_MFR(info)) { ++ case SNOR_MFR_MICRON: ++ /* Check whether Micron Dual mode is enabled. */ ++ if (nor->read_proto != SNOR_PROTO_2_2_2) ++ nor->read_proto = SNOR_PROTO_1_1_2; ++ break; ++ ++ default: ++ nor->read_proto = SNOR_PROTO_1_1_2; ++ break; ++ } ++ ++ nor->read_opcode = SPINOR_OP_READ_1_1_2; ++ return 0; ++} ++ ++static int set_single_mode(struct spi_nor *nor, const struct flash_info *info) ++{ ++ switch (JEDEC_MFR(info)) { ++ default: ++ nor->read_proto = SNOR_PROTO_1_1_1; ++ break; ++ } ++ ++ return 0; + } + + static int spi_nor_check(struct spi_nor *nor) +@@ -1330,7 +1374,30 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode) + if (info->flags & SPI_NOR_NO_FR) + nor->flash_read = SPI_NOR_NORMAL; + +- /* Quad/Dual-read mode takes precedence over fast/normal */ ++ /* Default commands */ ++ if (nor->flash_read == SPI_NOR_NORMAL) ++ nor->read_opcode = SPINOR_OP_READ; ++ else ++ nor->read_opcode = SPINOR_OP_READ_FAST; ++ ++ nor->program_opcode = SPINOR_OP_PP; ++ ++ /* ++ * Quad/Dual-read mode takes precedence over fast/normal. ++ * ++ * Manufacturer specific modes are discovered when reading the JEDEC ID ++ * and are reported by the nor->read_proto value: ++ * - SNOR_PROTO_4_4_4 is either: ++ * + Micron Quad mode enabled ++ * + Macronix/Winbond QPI mode enabled ++ * - SNOR_PROTO_2_2_2 is either: ++ * + Micron Dual mode enabled ++ * ++ * The opcodes and the protocols are updated depending on the ++ * manufacturer. ++ * The read opcode and protocol should be updated by the relevant ++ * function when entering Quad or Dual mode. ++ */ + if (mode == SPI_NOR_QUAD && info->flags & SPI_NOR_QUAD_READ) { + ret = set_quad_mode(nor, info); + if (ret) { +@@ -1339,30 +1406,21 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode) + } + nor->flash_read = SPI_NOR_QUAD; + } else if (mode == SPI_NOR_DUAL && info->flags & SPI_NOR_DUAL_READ) { ++ ret = set_dual_mode(nor, info); ++ if (ret) { ++ dev_err(dev, "dual mode not supported\n"); ++ return ret; ++ } + nor->flash_read = SPI_NOR_DUAL; ++ } else if (info->flags & (SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ)) { ++ /* We may need to leave a Quad or Dual mode */ ++ ret = set_single_mode(nor, info); ++ if (ret) { ++ dev_err(dev, "failed to switch back to single mode\n"); ++ return ret; ++ } + } + +- /* Default commands */ +- switch (nor->flash_read) { +- case SPI_NOR_QUAD: +- nor->read_opcode = SPINOR_OP_READ_1_1_4; +- break; +- case SPI_NOR_DUAL: +- nor->read_opcode = SPINOR_OP_READ_1_1_2; +- break; +- case SPI_NOR_FAST: +- nor->read_opcode = SPINOR_OP_READ_FAST; +- break; +- case SPI_NOR_NORMAL: +- nor->read_opcode = SPINOR_OP_READ; +- break; +- default: +- dev_err(dev, "No Read opcode defined\n"); +- return -EINVAL; +- } +- +- nor->program_opcode = SPINOR_OP_PP; +- + if (info->addr_width) + nor->addr_width = info->addr_width; + else if (mtd->size > 0x1000000) { +diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h +index 53932c8..89e3228 100644 +--- a/include/linux/mtd/spi-nor.h ++++ b/include/linux/mtd/spi-nor.h +@@ -42,8 +42,10 @@ + #define SPINOR_OP_WRSR 0x01 /* Write status register 1 byte */ + #define SPINOR_OP_READ 0x03 /* Read data bytes (low frequency) */ + #define SPINOR_OP_READ_FAST 0x0b /* Read data bytes (high frequency) */ +-#define SPINOR_OP_READ_1_1_2 0x3b /* Read data bytes (Dual SPI) */ +-#define SPINOR_OP_READ_1_1_4 0x6b /* Read data bytes (Quad SPI) */ ++#define SPINOR_OP_READ_1_1_2 0x3b /* Read data bytes (Dual Output SPI) */ ++#define SPINOR_OP_READ_1_2_2 0xbb /* Read data bytes (Dual I/O SPI) */ ++#define SPINOR_OP_READ_1_1_4 0x6b /* Read data bytes (Quad Output SPI) */ ++#define SPINOR_OP_READ_1_4_4 0xeb /* Read data bytes (Quad I/O SPI) */ + #define SPINOR_OP_PP 0x02 /* Page program (up to 256 bytes) */ + #define SPINOR_OP_BE_4K 0x20 /* Erase 4KiB block */ + #define SPINOR_OP_BE_4K_PMC 0xd7 /* Erase 4KiB block on PMC chips */ +@@ -57,8 +59,10 @@ + /* 4-byte address opcodes - used on Spansion and some Macronix flashes. */ + #define SPINOR_OP_READ4 0x13 /* Read data bytes (low frequency) */ + #define SPINOR_OP_READ4_FAST 0x0c /* Read data bytes (high frequency) */ +-#define SPINOR_OP_READ4_1_1_2 0x3c /* Read data bytes (Dual SPI) */ +-#define SPINOR_OP_READ4_1_1_4 0x6c /* Read data bytes (Quad SPI) */ ++#define SPINOR_OP_READ4_1_1_2 0x3c /* Read data bytes (Dual Output SPI) */ ++#define SPINOR_OP_READ4_1_2_2 0xbc /* Read data bytes (Dual I/O SPI) */ ++#define SPINOR_OP_READ4_1_1_4 0x6c /* Read data bytes (Quad Output SPI) */ ++#define SPINOR_OP_READ4_1_4_4 0xec /* Read data bytes (Quad I/O SPI) */ + #define SPINOR_OP_PP_4B 0x12 /* Page program (up to 256 bytes) */ + #define SPINOR_OP_SE_4B 0xdc /* Sector erase (usually 64KiB) */ + +-- +2.8.1 + diff --git a/target/linux/socfpga/patches-4.4/0019-mtd-spi-nor-fix-support-of-Macronix-memories.patch b/target/linux/socfpga/patches-4.4/0019-mtd-spi-nor-fix-support-of-Macronix-memories.patch new file mode 100644 index 0000000..087b671 --- /dev/null +++ b/target/linux/socfpga/patches-4.4/0019-mtd-spi-nor-fix-support-of-Macronix-memories.patch @@ -0,0 +1,139 @@ +From 4e094634d1995e279f8bc5eb92463295cb894c76 Mon Sep 17 00:00:00 2001 +From: Cyrille Pitchen +Date: Fri, 8 Jan 2016 17:02:16 +0100 +Subject: [PATCH 19/33] mtd: spi-nor: fix support of Macronix memories + +This patch fixes the support of Macronix memories. Especially we avoid +updating the Status Register when not needed as the Quad Enable (QE) bit +is a non-volatile bit. + +Also we add comments to explain why we use some Fast Read op codes rather +than others. + +Signed-off-by: Cyrille Pitchen +--- + drivers/mtd/spi-nor/spi-nor.c | 81 ++++++++++++++++++++++++++++++++++++++----- + 1 file changed, 72 insertions(+), 9 deletions(-) + +diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c +index 889af12..1b1f5a6 100644 +--- a/drivers/mtd/spi-nor/spi-nor.c ++++ b/drivers/mtd/spi-nor/spi-nor.c +@@ -1107,6 +1107,11 @@ static int macronix_quad_enable(struct spi_nor *nor) + val = read_sr(nor); + if (val < 0) + return val; ++ ++ if (likely(val & SR_QUAD_EN_MX)) ++ return 0; ++ dev_warn(nor->dev, "Macronix Quad mode disabled, enable it\n"); ++ + write_enable(nor); + + write_sr(nor, val | SR_QUAD_EN_MX); +@@ -1161,21 +1166,73 @@ static int spansion_quad_enable(struct spi_nor *nor) + return 0; + } + ++static int macronix_set_quad_mode(struct spi_nor *nor) ++{ ++ int status; ++ ++ /* Check whether the QPI mode is enabled. */ ++ if (nor->read_proto == SNOR_PROTO_4_4_4) { ++ /* ++ * Since the QPI mode is enabled, the Quad Enabled (QE) ++ * non-volatile bit is already set. ++ * However in QPI mode, only the Fast Read 1-4-4 (0xeb) ++ * op code is supported. ++ * WARNING: we should take care about the performance ++ * enhance toggling bits P0-P7 written during the ++ * dummy/mode cycles to avoid entering the continuous ++ * read (performance enhance) mode by mistake! ++ */ ++ nor->read_opcode = SPINOR_OP_READ_1_4_4; ++ return 0; ++ } ++ ++ /* ++ * The QPI mode is disabled but we still need to set the QE bit: ++ * this disables the reset and write protect features and ++ * frees the associated pins so they can be used as the 3rd ++ * and 4th I/O lines required by Quad SPI commands. ++ * Also we'd rather use the Fast Read 1-1-4 (0x6b) op code than ++ * the Fast Read 1-4-4 (0xeb) op code so we don't care about ++ * entering the continuous read mode by mistake if some ++ * performance enhance toggling bits P0-P7 were written during ++ * dummy/mode cycles. ++ */ ++ status = macronix_quad_enable(nor); ++ if (status) { ++ dev_err(nor->dev, "Macronix quad-read not enabled\n"); ++ return status; ++ } ++ nor->read_proto = SNOR_PROTO_1_1_4; ++ nor->read_opcode = SPINOR_OP_READ_1_1_4; ++ return 0; ++} ++ ++/* ++ * For both Macronix Dual and Single modes, we don't care about the value of ++ * the Quad Enabled (QE) bit since the memory still replies to Dual or Single ++ * SPI commands. ++ */ ++ ++static int macronix_set_dual_mode(struct spi_nor *nor) ++{ ++ nor->read_proto = SNOR_PROTO_1_1_2; ++ nor->read_opcode = SPINOR_OP_READ_1_1_2; ++ return 0; ++} ++ ++static int macronix_set_single_mode(struct spi_nor *nor) ++{ ++ nor->read_proto = SNOR_PROTO_1_1_1; ++ return 0; ++} ++ + static int set_quad_mode(struct spi_nor *nor, const struct flash_info *info) + { + int status; + + switch (JEDEC_MFR(info)) { + case SNOR_MFR_MACRONIX: +- status = macronix_quad_enable(nor); +- if (status) { +- dev_err(nor->dev, "Macronix quad-read not enabled\n"); +- return -EINVAL; +- } +- /* Check whether Macronix QPI mode is enabled. */ +- if (nor->read_proto != SNOR_PROTO_4_4_4) +- nor->read_proto = SNOR_PROTO_1_1_4; +- break; ++ return macronix_set_quad_mode(nor); + + case SNOR_MFR_MICRON: + /* Check whether Micron Quad mode is enabled. */ +@@ -1203,6 +1260,9 @@ static int set_quad_mode(struct spi_nor *nor, const struct flash_info *info) + static int set_dual_mode(struct spi_nor *nor, const struct flash_info *info) + { + switch (JEDEC_MFR(info)) { ++ case SNOR_MFR_MACRONIX: ++ return macronix_set_dual_mode(nor); ++ + case SNOR_MFR_MICRON: + /* Check whether Micron Dual mode is enabled. */ + if (nor->read_proto != SNOR_PROTO_2_2_2) +@@ -1221,6 +1281,9 @@ static int set_dual_mode(struct spi_nor *nor, const struct flash_info *info) + static int set_single_mode(struct spi_nor *nor, const struct flash_info *info) + { + switch (JEDEC_MFR(info)) { ++ case SNOR_MFR_MACRONIX: ++ return macronix_set_single_mode(nor); ++ + default: + nor->read_proto = SNOR_PROTO_1_1_1; + break; +-- +2.8.1 + diff --git a/target/linux/socfpga/patches-4.4/0020-mtd-spi-nor-fix-support-of-Winbond-memories.patch b/target/linux/socfpga/patches-4.4/0020-mtd-spi-nor-fix-support-of-Winbond-memories.patch new file mode 100644 index 0000000..e41fd3f --- /dev/null +++ b/target/linux/socfpga/patches-4.4/0020-mtd-spi-nor-fix-support-of-Winbond-memories.patch @@ -0,0 +1,179 @@ +From 96b232d03a0c4462eacf879ed80b0cfd235e65c4 Mon Sep 17 00:00:00 2001 +From: Cyrille Pitchen +Date: Fri, 8 Jan 2016 17:02:17 +0100 +Subject: [PATCH 20/33] mtd: spi-nor: fix support of Winbond memories + +This patch fixes the support of Winbond memories. Indeed, before +performing any Quad SPI command, the Quad Enable (QE) non-volatile bit +MUST be set in the Status Register 2. + +According to the w25q16fw datasheet from Winbond: +"When QE=1, the /WP pin becomes IO2 and /HOLD pin becomes IO3." + +Quad SPI instructions requires the bidirectional IO2 and IO3 pins. + +Signed-off-by: Cyrille Pitchen +--- + drivers/mtd/spi-nor/spi-nor.c | 100 ++++++++++++++++++++++++++++++++++++++++++ + include/linux/mtd/spi-nor.h | 6 +++ + 2 files changed, 106 insertions(+) + +diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c +index 1b1f5a6..aa7d26d 100644 +--- a/drivers/mtd/spi-nor/spi-nor.c ++++ b/drivers/mtd/spi-nor/spi-nor.c +@@ -1166,6 +1166,40 @@ static int spansion_quad_enable(struct spi_nor *nor) + return 0; + } + ++static int winbond_quad_enable(struct spi_nor *nor) ++{ ++ int ret; ++ u8 sr2; ++ ++ ret = nor->read_reg(nor, SPINOR_OP_RDSR2_WINB, &sr2, 1); ++ if (ret < 0) ++ return ret; ++ ++ if (likely(sr2 & SR2_QUAD_EN_WINB)) ++ return 0; ++ dev_warn(nor->dev, "Winbond Quad mode disabled, enable it\n"); ++ ++ write_enable(nor); ++ ++ sr2 |= SR2_QUAD_EN_WINB; ++ ret = nor->write_reg(nor, SPINOR_OP_WRSR2_WINB, &sr2, 1); ++ if (ret < 0) ++ return ret; ++ ++ if (spi_nor_wait_till_ready(nor)) ++ return -EIO; ++ ++ ret = nor->read_reg(nor, SPINOR_OP_RDSR2_WINB, &sr2, 1); ++ if (ret < 0) ++ return ret; ++ if (!(sr2 & SR2_QUAD_EN_WINB)) { ++ dev_err(nor->dev, "Winbond Quad bit not set\n"); ++ return -EINVAL; ++ } ++ ++ return 0; ++} ++ + static int macronix_set_quad_mode(struct spi_nor *nor) + { + int status; +@@ -1226,6 +1260,63 @@ static int macronix_set_single_mode(struct spi_nor *nor) + return 0; + } + ++static int winbond_set_quad_mode(struct spi_nor *nor) ++{ ++ int status; ++ ++ /* Check whether the QPI mode is enabled. */ ++ if (nor->read_proto == SNOR_PROTO_4_4_4) { ++ /* Since the QPI mode is enabled, the Quad Enabled (QE) ++ * non-volatile bit is already set. ++ * If the Fast Read 1-4-4 (0xeb) were used, we should ++ * take care about the value M7-M0 written during ++ * dummy/mode cycles to avoid entering the continuous ++ * read mode by mistake. ++ * Also the Fast Read 1-1-4 (0x6b) op code is not ++ * supported in QPI mode. ++ * Hence the Fast Read 1-1-1 (0x0b) op code is chosen. ++ */ ++ nor->read_opcode = SPINOR_OP_READ_FAST; ++ return 0; ++ } ++ ++ /* ++ * The QPI mode is disabled but we still need to set the QE bit: ++ * when QE=1, the /WP pin becomes IO2 and /HOLD pin becomes IO3. ++ * If the Fast Read 1-4-4 (0xeb) were used, we should take care ++ * about the value M7-M0 written during dummy/mode cycles to ++ * avoid entering the continuous read mode by mistake. ++ * Hence the Fast Read 1-1-4 (0x6b) op code is preferred. ++ */ ++ status = winbond_quad_enable(nor); ++ if (status) { ++ dev_err(nor->dev, "Winbond quad-read nor enabled\n"); ++ return status; ++ } ++ nor->read_proto = SNOR_PROTO_1_1_4; ++ nor->read_opcode = SPINOR_OP_READ_1_1_4; ++ return 0; ++} ++ ++/* ++ * For both Winbond Dual and Single modes, we don't care about the value of ++ * the Quad Enabled (QE) bit since the memory still replies to Dual or Single ++ * SPI commands. ++ */ ++ ++static int winbond_set_dual_mode(struct spi_nor *nor) ++{ ++ nor->read_proto = SNOR_PROTO_1_1_2; ++ nor->read_opcode = SPINOR_OP_READ_1_1_2; ++ return 0; ++} ++ ++static int winbond_set_single_mode(struct spi_nor *nor) ++{ ++ nor->read_proto = SNOR_PROTO_1_1_1; ++ return 0; ++} ++ + static int set_quad_mode(struct spi_nor *nor, const struct flash_info *info) + { + int status; +@@ -1234,6 +1325,9 @@ static int set_quad_mode(struct spi_nor *nor, const struct flash_info *info) + case SNOR_MFR_MACRONIX: + return macronix_set_quad_mode(nor); + ++ case SNOR_MFR_WINBOND: ++ return winbond_set_quad_mode(nor); ++ + case SNOR_MFR_MICRON: + /* Check whether Micron Quad mode is enabled. */ + if (nor->read_proto != SNOR_PROTO_4_4_4) +@@ -1263,6 +1357,9 @@ static int set_dual_mode(struct spi_nor *nor, const struct flash_info *info) + case SNOR_MFR_MACRONIX: + return macronix_set_dual_mode(nor); + ++ case SNOR_MFR_WINBOND: ++ return winbond_set_dual_mode(nor); ++ + case SNOR_MFR_MICRON: + /* Check whether Micron Dual mode is enabled. */ + if (nor->read_proto != SNOR_PROTO_2_2_2) +@@ -1284,6 +1381,9 @@ static int set_single_mode(struct spi_nor *nor, const struct flash_info *info) + case SNOR_MFR_MACRONIX: + return macronix_set_single_mode(nor); + ++ case SNOR_MFR_WINBOND: ++ return winbond_set_single_mode(nor); ++ + default: + nor->read_proto = SNOR_PROTO_1_1_1; + break; +diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h +index 89e3228..46343f5 100644 +--- a/include/linux/mtd/spi-nor.h ++++ b/include/linux/mtd/spi-nor.h +@@ -75,6 +75,12 @@ + #define SPINOR_OP_EN4B 0xb7 /* Enter 4-byte mode */ + #define SPINOR_OP_EX4B 0xe9 /* Exit 4-byte mode */ + ++/* Used for Winbond flashes only. */ ++#define SPINOR_OP_RDSR2_WINB 0x35 /* Read status register 2 */ ++#define SPINOR_OP_WRSR2_WINB 0x31 /* Write status register 2 */ ++ ++#define SR2_QUAD_EN_WINB BIT(1) /* Quad Enable bit */ ++ + /* Used for Spansion flashes only. */ + #define SPINOR_OP_BRWR 0x17 /* Bank register write */ + +-- +2.8.1 + diff --git a/target/linux/socfpga/patches-4.4/0021-mtd-spi-nor-fix-support-of-Micron-memories.patch b/target/linux/socfpga/patches-4.4/0021-mtd-spi-nor-fix-support-of-Micron-memories.patch new file mode 100644 index 0000000..83d79ab --- /dev/null +++ b/target/linux/socfpga/patches-4.4/0021-mtd-spi-nor-fix-support-of-Micron-memories.patch @@ -0,0 +1,224 @@ +From 0cd0df6b3583920ab9231035e533560b58e71a50 Mon Sep 17 00:00:00 2001 +From: Cyrille Pitchen +Date: Fri, 8 Jan 2016 17:02:18 +0100 +Subject: [PATCH 21/33] mtd: spi-nor: fix support of Micron memories + +This patch adds missing mode transitions. Indeed depending on both the +current memory mode and the new protocol wanted by the user, we may need +to perform a switch back to the Extended SPI mode. + +However when the current mode is the Quad mode and the user has asked for +a Quad SPI protocol, we'd rather stay in Quad mode and use the Fast Read +4-4-4 command than switch to the Extended SPI mode and use the Fast Read +1-1-4 command. + +Also we'd rather stay in Dual mode than swith to the Extended SPI mode +whenever the user has asked for Dual SPI protocol. + +Signed-off-by: Cyrille Pitchen +--- + drivers/mtd/spi-nor/spi-nor.c | 154 +++++++++++++++++++++++++++++++++++++++--- + include/linux/mtd/spi-nor.h | 1 + + 2 files changed, 147 insertions(+), 8 deletions(-) + +diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c +index aa7d26d..ae2cbac 100644 +--- a/drivers/mtd/spi-nor/spi-nor.c ++++ b/drivers/mtd/spi-nor/spi-nor.c +@@ -1317,6 +1317,147 @@ static int winbond_set_single_mode(struct spi_nor *nor) + return 0; + } + ++static int micron_set_protocol(struct spi_nor *nor, u8 mask, u8 val, ++ enum spi_nor_protocol proto) ++{ ++ u8 evcr; ++ int ret; ++ ++ /* Read the Enhanced Volatile Configuration Register (EVCR). */ ++ ret = nor->read_reg(nor, SPINOR_OP_RD_EVCR, &evcr, 1); ++ if (ret < 0) { ++ dev_err(nor->dev, "error while reading EVCR register\n"); ++ return ret; ++ } ++ ++ /* Check whether we need to update the protocol bits. */ ++ if ((evcr & mask) == val) ++ return 0; ++ ++ /* Set EVCR protocol bits. */ ++ write_enable(nor); ++ evcr = (evcr & ~mask) | val; ++ ret = nor->write_reg(nor, SPINOR_OP_WD_EVCR, &evcr, 1); ++ if (ret < 0) { ++ dev_err(nor->dev, "error while writing EVCR register\n"); ++ return ret; ++ } ++ ++ /* Switch reg protocol now before accessing any other registers. */ ++ nor->reg_proto = proto; ++ ++ ret = spi_nor_wait_till_ready(nor); ++ if (ret) ++ return ret; ++ ++ /* Read EVCR and check it. */ ++ ret = nor->read_reg(nor, SPINOR_OP_RD_EVCR, &evcr, 1); ++ if (ret < 0 || (evcr & mask) != val) { ++ dev_err(nor->dev, "Micron EVCR protocol bits not updated\n"); ++ return -EINVAL; ++ } ++ ++ return 0; ++} ++ ++static int micron_set_extended_spi_protocol(struct spi_nor *nor) ++{ ++ int ret; ++ ++ /* Set Quad/Dual bits to 11 to select the Extended SPI mode */ ++ ret = micron_set_protocol(nor, ++ EVCR_QUAD_EN_MICRON | EVCR_DUAL_EN_MICRON, ++ EVCR_QUAD_EN_MICRON | EVCR_DUAL_EN_MICRON, ++ SNOR_PROTO_1_1_1); ++ if (ret) { ++ dev_err(nor->dev, "Failed to set Micron Extended SPI mode\n"); ++ return ret; ++ } ++ ++ nor->write_proto = SNOR_PROTO_1_1_1; ++ nor->erase_proto = SNOR_PROTO_1_1_1; ++ return 0; ++} ++ ++static int micron_set_quad_mode(struct spi_nor *nor) ++{ ++ /* Check whether the Dual SPI mode is enabled. */ ++ if (unlikely(nor->read_proto == SNOR_PROTO_2_2_2)) { ++ int ret; ++ ++ /* ++ * Exit Micron Dual mode and switch to the Extended SPI mode: ++ * we can change the mode safely as we write into a volatile ++ * register. ++ * Also the Quad mode is not worth it for MTD usages: it ++ * should only be relevant for eXecution In Place (XIP) usages, ++ * which are out of the scope of the spi-nor framework. ++ */ ++ ret = micron_set_extended_spi_protocol(nor); ++ if (ret) ++ return ret; ++ } ++ ++ /* ++ * Whatever the Quad mode is enabled or not, the ++ * Fast Read Quad Output 1-1-4 (0x6b) op code is supported. ++ */ ++ if (nor->read_proto != SNOR_PROTO_4_4_4) ++ nor->read_proto = SNOR_PROTO_1_1_4; ++ nor->read_opcode = SPINOR_OP_READ_1_1_4; ++ return 0; ++} ++ ++static int micron_set_dual_mode(struct spi_nor *nor) ++{ ++ /* Check whether Quad mode is enabled. */ ++ if (unlikely(nor->read_proto == SNOR_PROTO_4_4_4)) { ++ int ret; ++ ++ /* ++ * Exit Micron Quad mode and switch to the Extended SPI mode: ++ * we can change the mode safely as we write into a volatile ++ * register. ++ * Also the Dual mode is not worth it for MTD usages: it ++ * should only be relevant for eXecution In Place (XIP) usages, ++ * which are out of the scope of the spi-nor framework. ++ */ ++ ret = micron_set_extended_spi_protocol(nor); ++ if (ret) ++ return ret; ++ } ++ ++ /* ++ * Whatever the Dual mode is enabled or not, the ++ * Fast Read Dual Output 1-1-2 (0x3b) op code is supported. ++ */ ++ if (nor->read_proto != SNOR_PROTO_2_2_2) ++ nor->read_proto = SNOR_PROTO_1_1_2; ++ nor->read_opcode = SPINOR_OP_READ_1_1_2; ++ return 0; ++} ++ ++static int micron_set_single_mode(struct spi_nor *nor) ++{ ++ /* Check whether either the Dual or Quad mode is enabled. */ ++ if (unlikely(nor->read_proto != SNOR_PROTO_1_1_1)) { ++ int ret; ++ ++ /* ++ * Exit Micron Dual or Quad mode and switch to the Extended SPI ++ * mode: we can change the mode safely as we write into a ++ * volatile register. ++ */ ++ ret = micron_set_extended_spi_protocol(nor); ++ if (ret) ++ return ret; ++ ++ nor->read_proto = SNOR_PROTO_1_1_1; ++ } ++ ++ return 0; ++} ++ + static int set_quad_mode(struct spi_nor *nor, const struct flash_info *info) + { + int status; +@@ -1329,10 +1470,7 @@ static int set_quad_mode(struct spi_nor *nor, const struct flash_info *info) + return winbond_set_quad_mode(nor); + + case SNOR_MFR_MICRON: +- /* Check whether Micron Quad mode is enabled. */ +- if (nor->read_proto != SNOR_PROTO_4_4_4) +- nor->read_proto = SNOR_PROTO_1_1_4; +- break; ++ return micron_set_quad_mode(nor); + + case SNOR_MFR_SPANSION: + status = spansion_quad_enable(nor); +@@ -1361,10 +1499,7 @@ static int set_dual_mode(struct spi_nor *nor, const struct flash_info *info) + return winbond_set_dual_mode(nor); + + case SNOR_MFR_MICRON: +- /* Check whether Micron Dual mode is enabled. */ +- if (nor->read_proto != SNOR_PROTO_2_2_2) +- nor->read_proto = SNOR_PROTO_1_1_2; +- break; ++ return micron_set_dual_mode(nor); + + default: + nor->read_proto = SNOR_PROTO_1_1_2; +@@ -1384,6 +1519,9 @@ static int set_single_mode(struct spi_nor *nor, const struct flash_info *info) + case SNOR_MFR_WINBOND: + return winbond_set_single_mode(nor); + ++ case SNOR_MFR_MICRON: ++ return micron_set_single_mode(nor); ++ + default: + nor->read_proto = SNOR_PROTO_1_1_1; + break; +diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h +index 46343f5..d0a6f34 100644 +--- a/include/linux/mtd/spi-nor.h ++++ b/include/linux/mtd/spi-nor.h +@@ -102,6 +102,7 @@ + + /* Enhanced Volatile Configuration Register bits */ + #define EVCR_QUAD_EN_MICRON BIT(7) /* Micron Quad I/O */ ++#define EVCR_DUAL_EN_MICRON BIT(6) /* Micron Dual I/O */ + + /* Flag Status Register bits */ + #define FSR_READY BIT(7) +-- +2.8.1 + diff --git a/target/linux/socfpga/patches-4.4/0022-mtd-spi-nor-fix-support-of-Spansion-memories.patch b/target/linux/socfpga/patches-4.4/0022-mtd-spi-nor-fix-support-of-Spansion-memories.patch new file mode 100644 index 0000000..a7a8f4b --- /dev/null +++ b/target/linux/socfpga/patches-4.4/0022-mtd-spi-nor-fix-support-of-Spansion-memories.patch @@ -0,0 +1,116 @@ +From 4774693a681539f1e890164acc2d99fede2aa35e Mon Sep 17 00:00:00 2001 +From: Cyrille Pitchen +Date: Fri, 8 Jan 2016 17:02:19 +0100 +Subject: [PATCH 22/33] mtd: spi-nor: fix support of Spansion memories + +This patch is only a transitional one. It concludes the series of patches +to select op codes and protocols by manufacturer. + +Signed-off-by: Cyrille Pitchen +--- + drivers/mtd/spi-nor/spi-nor.c | 53 ++++++++++++++++++++++++++++++------------- + 1 file changed, 37 insertions(+), 16 deletions(-) + +diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c +index ae2cbac..8a042ab 100644 +--- a/drivers/mtd/spi-nor/spi-nor.c ++++ b/drivers/mtd/spi-nor/spi-nor.c +@@ -1458,10 +1458,35 @@ static int micron_set_single_mode(struct spi_nor *nor) + return 0; + } + +-static int set_quad_mode(struct spi_nor *nor, const struct flash_info *info) ++static int spansion_set_quad_mode(struct spi_nor *nor) + { + int status; + ++ status = spansion_quad_enable(nor); ++ if (status) { ++ dev_err(nor->dev, "Spansion quad-read not enabled\n"); ++ return -EINVAL; ++ } ++ nor->read_proto = SNOR_PROTO_1_1_4; ++ nor->read_opcode = SPINOR_OP_READ_1_1_4; ++ return 0; ++} ++ ++static int spansion_set_dual_mode(struct spi_nor *nor) ++{ ++ nor->read_proto = SNOR_PROTO_1_1_2; ++ nor->read_opcode = SPINOR_OP_READ_1_1_2; ++ return 0; ++} ++ ++static int spansion_set_single_mode(struct spi_nor *nor) ++{ ++ nor->read_proto = SNOR_PROTO_1_1_1; ++ return 0; ++} ++ ++static int set_quad_mode(struct spi_nor *nor, const struct flash_info *info) ++{ + switch (JEDEC_MFR(info)) { + case SNOR_MFR_MACRONIX: + return macronix_set_quad_mode(nor); +@@ -1473,20 +1498,13 @@ static int set_quad_mode(struct spi_nor *nor, const struct flash_info *info) + return micron_set_quad_mode(nor); + + case SNOR_MFR_SPANSION: +- status = spansion_quad_enable(nor); +- if (status) { +- dev_err(nor->dev, "Spansion quad-read not enabled\n"); +- return -EINVAL; +- } +- nor->read_proto = SNOR_PROTO_1_1_4; +- break; ++ return spansion_set_quad_mode(nor); + + default: +- return -EINVAL; ++ break; + } + +- nor->read_opcode = SPINOR_OP_READ_1_1_4; +- return 0; ++ return -EINVAL; + } + + static int set_dual_mode(struct spi_nor *nor, const struct flash_info *info) +@@ -1501,13 +1519,14 @@ static int set_dual_mode(struct spi_nor *nor, const struct flash_info *info) + case SNOR_MFR_MICRON: + return micron_set_dual_mode(nor); + ++ case SNOR_MFR_SPANSION: ++ return spansion_set_dual_mode(nor); ++ + default: +- nor->read_proto = SNOR_PROTO_1_1_2; + break; + } + +- nor->read_opcode = SPINOR_OP_READ_1_1_2; +- return 0; ++ return -EINVAL; + } + + static int set_single_mode(struct spi_nor *nor, const struct flash_info *info) +@@ -1522,12 +1541,14 @@ static int set_single_mode(struct spi_nor *nor, const struct flash_info *info) + case SNOR_MFR_MICRON: + return micron_set_single_mode(nor); + ++ case SNOR_MFR_SPANSION: ++ return spansion_set_single_mode(nor); ++ + default: +- nor->read_proto = SNOR_PROTO_1_1_1; + break; + } + +- return 0; ++ return -EINVAL; + } + + static int spi_nor_check(struct spi_nor *nor) +-- +2.8.1 + diff --git a/target/linux/socfpga/patches-4.4/0023-mtd-spi-nor-configure-the-number-of-dummy-clock-cycl.patch b/target/linux/socfpga/patches-4.4/0023-mtd-spi-nor-configure-the-number-of-dummy-clock-cycl.patch new file mode 100644 index 0000000..7153a9f --- /dev/null +++ b/target/linux/socfpga/patches-4.4/0023-mtd-spi-nor-configure-the-number-of-dummy-clock-cycl.patch @@ -0,0 +1,264 @@ +From 16410a33d6655d6c85c8c522bc6f2cfebf7c06a4 Mon Sep 17 00:00:00 2001 +From: Cyrille Pitchen +Date: Fri, 8 Jan 2016 17:02:20 +0100 +Subject: [PATCH 23/33] mtd: spi-nor: configure the number of dummy clock + cycles by manufacturer + +This is a transitional patch which let us set the number of dummy clock +cycles by manufacturer. + +More patches will follow by manufacturer to actually configure the +relevant number of dummy clock cycles following the dedicated procedure. + +For instance, some manufacturers like Spansion configure the number of +dummy clock cycles to be used by Fast Read command through some +non-volatile register. In such a case, we should avoid updating its value +but instead read it then set the nor->read_dummy accordingly. + +On the other hand, some manufacturers like Micron use some volatile +register. In this case, we'd rather update this register to use a number +of dummy clock cycles, which is a multiple of 8. +Indeed some drivers, like m25p80, only support writing bytes, hence +multiples of 8 bits. + +Signed-off-by: Cyrille Pitchen +--- + drivers/mtd/spi-nor/spi-nor.c | 99 ++++++++++++++++++++++++++++++++----------- + 1 file changed, 74 insertions(+), 25 deletions(-) + +diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c +index 8a042ab..ae3e9d8 100644 +--- a/drivers/mtd/spi-nor/spi-nor.c ++++ b/drivers/mtd/spi-nor/spi-nor.c +@@ -139,24 +139,6 @@ static int read_cr(struct spi_nor *nor) + } + + /* +- * Dummy Cycle calculation for different type of read. +- * It can be used to support more commands with +- * different dummy cycle requirements. +- */ +-static inline int spi_nor_read_dummy_cycles(struct spi_nor *nor) +-{ +- switch (nor->flash_read) { +- case SPI_NOR_FAST: +- case SPI_NOR_DUAL: +- case SPI_NOR_QUAD: +- return 8; +- case SPI_NOR_NORMAL: +- return 0; +- } +- return 0; +-} +- +-/* + * Write status register 1 byte + * Returns negative if error occurred. + */ +@@ -1217,6 +1199,7 @@ static int macronix_set_quad_mode(struct spi_nor *nor) + * read (performance enhance) mode by mistake! + */ + nor->read_opcode = SPINOR_OP_READ_1_4_4; ++ nor->read_dummy = 8; + return 0; + } + +@@ -1238,6 +1221,7 @@ static int macronix_set_quad_mode(struct spi_nor *nor) + } + nor->read_proto = SNOR_PROTO_1_1_4; + nor->read_opcode = SPINOR_OP_READ_1_1_4; ++ nor->read_dummy = 8; + return 0; + } + +@@ -1251,12 +1235,27 @@ static int macronix_set_dual_mode(struct spi_nor *nor) + { + nor->read_proto = SNOR_PROTO_1_1_2; + nor->read_opcode = SPINOR_OP_READ_1_1_2; ++ nor->read_dummy = 8; + return 0; + } + + static int macronix_set_single_mode(struct spi_nor *nor) + { ++ u8 read_dummy; ++ ++ switch (nor->read_opcode) { ++ case SPINOR_OP_READ: ++ case SPINOR_OP_READ4: ++ read_dummy = 0; ++ break; ++ ++ default: ++ read_dummy = 8; ++ break; ++ } ++ + nor->read_proto = SNOR_PROTO_1_1_1; ++ nor->read_dummy = read_dummy; + return 0; + } + +@@ -1277,6 +1276,7 @@ static int winbond_set_quad_mode(struct spi_nor *nor) + * Hence the Fast Read 1-1-1 (0x0b) op code is chosen. + */ + nor->read_opcode = SPINOR_OP_READ_FAST; ++ nor->read_dummy = 8; + return 0; + } + +@@ -1295,6 +1295,7 @@ static int winbond_set_quad_mode(struct spi_nor *nor) + } + nor->read_proto = SNOR_PROTO_1_1_4; + nor->read_opcode = SPINOR_OP_READ_1_1_4; ++ nor->read_dummy = 8; + return 0; + } + +@@ -1308,12 +1309,27 @@ static int winbond_set_dual_mode(struct spi_nor *nor) + { + nor->read_proto = SNOR_PROTO_1_1_2; + nor->read_opcode = SPINOR_OP_READ_1_1_2; ++ nor->read_dummy = 8; + return 0; + } + + static int winbond_set_single_mode(struct spi_nor *nor) + { ++ u8 read_dummy; ++ ++ switch (nor->read_opcode) { ++ case SPINOR_OP_READ: ++ case SPINOR_OP_READ4: ++ read_dummy = 0; ++ break; ++ ++ default: ++ read_dummy = 8; ++ break; ++ } ++ + nor->read_proto = SNOR_PROTO_1_1_1; ++ nor->read_dummy = read_dummy; + return 0; + } + +@@ -1405,6 +1421,7 @@ static int micron_set_quad_mode(struct spi_nor *nor) + if (nor->read_proto != SNOR_PROTO_4_4_4) + nor->read_proto = SNOR_PROTO_1_1_4; + nor->read_opcode = SPINOR_OP_READ_1_1_4; ++ nor->read_dummy = 8; + return 0; + } + +@@ -1434,11 +1451,14 @@ static int micron_set_dual_mode(struct spi_nor *nor) + if (nor->read_proto != SNOR_PROTO_2_2_2) + nor->read_proto = SNOR_PROTO_1_1_2; + nor->read_opcode = SPINOR_OP_READ_1_1_2; ++ nor->read_dummy = 8; + return 0; + } + + static int micron_set_single_mode(struct spi_nor *nor) + { ++ u8 read_dummy; ++ + /* Check whether either the Dual or Quad mode is enabled. */ + if (unlikely(nor->read_proto != SNOR_PROTO_1_1_1)) { + int ret; +@@ -1455,6 +1475,18 @@ static int micron_set_single_mode(struct spi_nor *nor) + nor->read_proto = SNOR_PROTO_1_1_1; + } + ++ /* Force the number of dummy cycles to 8 for Fast Read, 0 for Read. */ ++ switch (nor->read_opcode) { ++ case SPINOR_OP_READ: ++ case SPINOR_OP_READ4: ++ read_dummy = 0; ++ break; ++ ++ default: ++ read_dummy = 8; ++ break; ++ } ++ nor->read_dummy = read_dummy; + return 0; + } + +@@ -1469,6 +1501,7 @@ static int spansion_set_quad_mode(struct spi_nor *nor) + } + nor->read_proto = SNOR_PROTO_1_1_4; + nor->read_opcode = SPINOR_OP_READ_1_1_4; ++ nor->read_dummy = 8; + return 0; + } + +@@ -1476,12 +1509,27 @@ static int spansion_set_dual_mode(struct spi_nor *nor) + { + nor->read_proto = SNOR_PROTO_1_1_2; + nor->read_opcode = SPINOR_OP_READ_1_1_2; ++ nor->read_dummy = 8; + return 0; + } + + static int spansion_set_single_mode(struct spi_nor *nor) + { ++ u8 read_dummy; ++ ++ switch (nor->read_opcode) { ++ case SPINOR_OP_READ: ++ case SPINOR_OP_READ4: ++ read_dummy = 0; ++ break; ++ ++ default: ++ read_dummy = 8; ++ break; ++ } ++ + nor->read_proto = SNOR_PROTO_1_1_1; ++ nor->read_dummy = read_dummy; + return 0; + } + +@@ -1696,11 +1744,14 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode) + if (info->flags & SPI_NOR_NO_FR) + nor->flash_read = SPI_NOR_NORMAL; + +- /* Default commands */ +- if (nor->flash_read == SPI_NOR_NORMAL) ++ /* Default commands and number of dummy cycles */ ++ if (nor->flash_read == SPI_NOR_NORMAL) { + nor->read_opcode = SPINOR_OP_READ; +- else ++ nor->read_dummy = 0; ++ } else { + nor->read_opcode = SPINOR_OP_READ_FAST; ++ nor->read_dummy = 8; ++ } + + nor->program_opcode = SPINOR_OP_PP; + +@@ -1715,8 +1766,8 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode) + * - SNOR_PROTO_2_2_2 is either: + * + Micron Dual mode enabled + * +- * The opcodes and the protocols are updated depending on the +- * manufacturer. ++ * The opcodes, the protocols and the number of dummy cycles are updated ++ * depending on the manufacturer. + * The read opcode and protocol should be updated by the relevant + * function when entering Quad or Dual mode. + */ +@@ -1780,8 +1831,6 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode) + return -EINVAL; + } + +- nor->read_dummy = spi_nor_read_dummy_cycles(nor); +- + dev_info(dev, "%s (%lld Kbytes)\n", info->name, + (long long)mtd->size >> 10); + +-- +2.8.1 + diff --git a/target/linux/socfpga/patches-4.4/0024-mtd-spi-nor-configure-the-number-of-dummy-clock-cycl.patch b/target/linux/socfpga/patches-4.4/0024-mtd-spi-nor-configure-the-number-of-dummy-clock-cycl.patch new file mode 100644 index 0000000..c6bf870 --- /dev/null +++ b/target/linux/socfpga/patches-4.4/0024-mtd-spi-nor-configure-the-number-of-dummy-clock-cycl.patch @@ -0,0 +1,159 @@ +From 77fee227b15835d03517dc34675f72e8963ae882 Mon Sep 17 00:00:00 2001 +From: Cyrille Pitchen +Date: Fri, 8 Jan 2016 17:02:21 +0100 +Subject: [PATCH 24/33] mtd: spi-nor: configure the number of dummy clock + cycles on Micron memories + +The spi-nor framework currently expects all Fast Read operations to use 8 +dummy clock cycles. Especially some drivers like m25p80 can only support +multiple of 8 dummy clock cycles. + +On Micron memories, the number of dummy clock cycles to be used by Fast +Read commands can be safely set to 8 by updating the Volatile +Configuration Register (VCR). + +Also the XIP bit is set at the same time when updating the VCR so the +Continuous Read mode is disabled: this prevents us from entering it by +mistake. + +Signed-off-by: Cyrille Pitchen +--- + drivers/mtd/spi-nor/spi-nor.c | 72 ++++++++++++++++++++++++++++++++++++++----- + include/linux/mtd/spi-nor.h | 2 ++ + 2 files changed, 67 insertions(+), 7 deletions(-) + +diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c +index ae3e9d8..5232984 100644 +--- a/drivers/mtd/spi-nor/spi-nor.c ++++ b/drivers/mtd/spi-nor/spi-nor.c +@@ -1333,6 +1333,53 @@ static int winbond_set_single_mode(struct spi_nor *nor) + return 0; + } + ++static int micron_set_dummy_cycles(struct spi_nor *nor, u8 read_dummy) ++{ ++ u8 vcr, val, mask; ++ int ret; ++ ++ /* Set bit3 (XIP) to disable the Continuous Read mode */ ++ mask = GENMASK(7, 4) | BIT(3); ++ val = ((read_dummy << 4) | BIT(3)) & mask; ++ ++ /* Read the Volatile Configuration Register (VCR). */ ++ ret = nor->read_reg(nor, SPINOR_OP_RD_VCR, &vcr, 1); ++ if (ret < 0) { ++ dev_err(nor->dev, "error while reading VCR register\n"); ++ return ret; ++ } ++ ++ /* Check whether we need to update the number of dummy cycles. */ ++ if ((vcr & mask) == val) { ++ nor->read_dummy = read_dummy; ++ return 0; ++ } ++ ++ /* Update the number of dummy into the VCR. */ ++ write_enable(nor); ++ vcr = (vcr & ~mask) | val; ++ ret = nor->write_reg(nor, SPINOR_OP_WR_VCR, &vcr, 1); ++ if (ret < 0) { ++ dev_err(nor->dev, "error while writing VCR register\n"); ++ return ret; ++ } ++ ++ ret = spi_nor_wait_till_ready(nor); ++ if (ret) ++ return ret; ++ ++ /* Read VCR and check it. */ ++ ret = nor->read_reg(nor, SPINOR_OP_RD_VCR, &vcr, 1); ++ if (ret < 0 || (vcr & mask) != val) { ++ dev_err(nor->dev, "Micron VCR dummy cycles not updated\n"); ++ return -EINVAL; ++ } ++ ++ /* Save the number of dummy cycles to use with Fast Read commands */ ++ nor->read_dummy = read_dummy; ++ return 0; ++} ++ + static int micron_set_protocol(struct spi_nor *nor, u8 mask, u8 val, + enum spi_nor_protocol proto) + { +@@ -1417,12 +1464,15 @@ static int micron_set_quad_mode(struct spi_nor *nor) + /* + * Whatever the Quad mode is enabled or not, the + * Fast Read Quad Output 1-1-4 (0x6b) op code is supported. ++ * Force the number of dummy cycles to 8 and disable the Continuous Read ++ * mode to prevent some drivers from using it by mistake (m25p80). ++ * We can change these settings safely as we write into a volatile ++ * register. + */ + if (nor->read_proto != SNOR_PROTO_4_4_4) + nor->read_proto = SNOR_PROTO_1_1_4; + nor->read_opcode = SPINOR_OP_READ_1_1_4; +- nor->read_dummy = 8; +- return 0; ++ return micron_set_dummy_cycles(nor, 8); + } + + static int micron_set_dual_mode(struct spi_nor *nor) +@@ -1447,12 +1497,15 @@ static int micron_set_dual_mode(struct spi_nor *nor) + /* + * Whatever the Dual mode is enabled or not, the + * Fast Read Dual Output 1-1-2 (0x3b) op code is supported. ++ * Force the number of dummy cycles to 8 and disable the Continuous Read ++ * mode to prevent some drivers from using it by mistake (m25p80). ++ * We can change these settings safely as we write into a volatile ++ * register. + */ + if (nor->read_proto != SNOR_PROTO_2_2_2) + nor->read_proto = SNOR_PROTO_1_1_2; + nor->read_opcode = SPINOR_OP_READ_1_1_2; +- nor->read_dummy = 8; +- return 0; ++ return micron_set_dummy_cycles(nor, 8); + } + + static int micron_set_single_mode(struct spi_nor *nor) +@@ -1475,7 +1528,13 @@ static int micron_set_single_mode(struct spi_nor *nor) + nor->read_proto = SNOR_PROTO_1_1_1; + } + +- /* Force the number of dummy cycles to 8 for Fast Read, 0 for Read. */ ++ /* ++ * Force the number of dummy cycles to 8 for Fast Read, 0 for Read ++ * and disable the Continuous Read mode to prevent some drivers from ++ * using it by mistake (m25p80). ++ * We can change these settings safely as we write into a volatile ++ * register. ++ */ + switch (nor->read_opcode) { + case SPINOR_OP_READ: + case SPINOR_OP_READ4: +@@ -1486,8 +1545,7 @@ static int micron_set_single_mode(struct spi_nor *nor) + read_dummy = 8; + break; + } +- nor->read_dummy = read_dummy; +- return 0; ++ return micron_set_dummy_cycles(nor, read_dummy); + } + + static int spansion_set_quad_mode(struct spi_nor *nor) +diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h +index d0a6f34..2dc0f8b 100644 +--- a/include/linux/mtd/spi-nor.h ++++ b/include/linux/mtd/spi-nor.h +@@ -86,6 +86,8 @@ + + /* Used for Micron flashes only. */ + #define SPINOR_OP_MIO_RDID 0xaf /* Multiple I/O Read JEDEC ID */ ++#define SPINOR_OP_RD_VCR 0x85 /* Read VCR register */ ++#define SPINOR_OP_WR_VCR 0x81 /* Write VCR register */ + #define SPINOR_OP_RD_EVCR 0x65 /* Read EVCR register */ + #define SPINOR_OP_WD_EVCR 0x61 /* Write EVCR register */ + +-- +2.8.1 + diff --git a/target/linux/socfpga/patches-4.4/0025-mtd-spi-nor-configure-the-number-of-dummy-clock-cycl.patch b/target/linux/socfpga/patches-4.4/0025-mtd-spi-nor-configure-the-number-of-dummy-clock-cycl.patch new file mode 100644 index 0000000..a9c3afd --- /dev/null +++ b/target/linux/socfpga/patches-4.4/0025-mtd-spi-nor-configure-the-number-of-dummy-clock-cycl.patch @@ -0,0 +1,237 @@ +From a714a2af12d0de527be168b821373f29f4343cb7 Mon Sep 17 00:00:00 2001 +From: Cyrille Pitchen +Date: Fri, 8 Jan 2016 17:02:22 +0100 +Subject: [PATCH 25/33] mtd: spi-nor: configure the number of dummy clock + cycles on Macronix memories + +The spi-nor framework currently expects all Fast Read operations to use 8 +dummy clock cycles. Especially some drivers like m25p80 can only support +multiple of 8 dummy clock cycles. + +On Macronix memories, the number of dummy clock cycles to be used by Fast +Read commands can be safely set to 8 by updating the DC0 and DC1 volatile +bits inside the Configuration Register. + +According to the mx66l1g45g datasheet from Macronix, using 8 dummy clock +cycles should be enough to set the SPI bus clock frequency up to: +- 133 MHz for Fast Read 1-1-1, 1-1-2, 1-1-4 and 1-2-2 commands in Single + Transfer Rate (STR) +- 104 MHz for Fast Read 1-4-4 (or 4-4-4 in QPI mode) commands (STR) + +Signed-off-by: Cyrille Pitchen +--- + drivers/mtd/spi-nor/spi-nor.c | 155 +++++++++++++++++++++++++++++++++++++++--- + 1 file changed, 147 insertions(+), 8 deletions(-) + +diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c +index 5232984..55a1d74 100644 +--- a/drivers/mtd/spi-nor/spi-nor.c ++++ b/drivers/mtd/spi-nor/spi-nor.c +@@ -1182,6 +1182,136 @@ static int winbond_quad_enable(struct spi_nor *nor) + return 0; + } + ++static int macronix_dummy2code(u8 read_opcode, u8 read_dummy, u8 *dc) ++{ ++ switch (read_opcode) { ++ case SPINOR_OP_READ: ++ case SPINOR_OP_READ4: ++ *dc = 0; ++ break; ++ ++ case SPINOR_OP_READ_FAST: ++ case SPINOR_OP_READ_1_1_2: ++ case SPINOR_OP_READ_1_1_4: ++ case SPINOR_OP_READ4_FAST: ++ case SPINOR_OP_READ4_1_1_2: ++ case SPINOR_OP_READ4_1_1_4: ++ switch (read_dummy) { ++ case 6: ++ *dc = 1; ++ break; ++ case 8: ++ *dc = 0; ++ break; ++ case 10: ++ *dc = 3; ++ break; ++ default: ++ return -EINVAL; ++ } ++ break; ++ ++ case SPINOR_OP_READ_1_2_2: ++ case SPINOR_OP_READ4_1_2_2: ++ switch (read_dummy) { ++ case 4: ++ *dc = 0; ++ break; ++ case 6: ++ *dc = 1; ++ break; ++ case 8: ++ *dc = 2; ++ break; ++ case 10: ++ *dc = 3; ++ default: ++ return -EINVAL; ++ } ++ break; ++ ++ case SPINOR_OP_READ_1_4_4: ++ case SPINOR_OP_READ4_1_4_4: ++ switch (read_dummy) { ++ case 4: ++ *dc = 1; ++ break; ++ case 6: ++ *dc = 0; ++ break; ++ case 8: ++ *dc = 2; ++ break; ++ case 10: ++ *dc = 3; ++ default: ++ return -EINVAL; ++ } ++ break; ++ ++ default: ++ return -EINVAL; ++ } ++ ++ return 0; ++} ++ ++static int macronix_set_dummy_cycles(struct spi_nor *nor, u8 read_dummy) ++{ ++ int ret, sr, cr, mask, val; ++ u16 sr_cr; ++ u8 dc; ++ ++ /* Convert the number of dummy cycles into Macronix DC volatile bits */ ++ ret = macronix_dummy2code(nor->read_opcode, read_dummy, &dc); ++ if (ret) ++ return ret; ++ ++ mask = GENMASK(7, 6); ++ val = (dc << 6) & mask; ++ ++ cr = read_cr(nor); ++ if (cr < 0) { ++ dev_err(nor->dev, "error while reading the config register\n"); ++ return cr; ++ } ++ ++ if ((cr & mask) == val) { ++ nor->read_dummy = read_dummy; ++ return 0; ++ } ++ ++ sr = read_sr(nor); ++ if (sr < 0) { ++ dev_err(nor->dev, "error while reading the status register\n"); ++ return sr; ++ } ++ ++ cr = (cr & ~mask) | val; ++ sr_cr = (sr & 0xff) | ((cr & 0xff) << 8); ++ write_enable(nor); ++ ret = write_sr_cr(nor, sr_cr); ++ if (ret) { ++ dev_err(nor->dev, ++ "error while writing the SR and CR registers\n"); ++ return ret; ++ } ++ ++ ret = spi_nor_wait_till_ready(nor); ++ if (ret) ++ return ret; ++ ++ cr = read_cr(nor); ++ if (cr < 0 || (cr & mask) != val) { ++ dev_err(nor->dev, "Macronix Dummy Cycle bits not updated\n"); ++ return -EINVAL; ++ } ++ ++ /* Save the number of dummy cycles to use with Fast Read commands */ ++ nor->read_dummy = read_dummy; ++ return 0; ++} ++ + static int macronix_set_quad_mode(struct spi_nor *nor) + { + int status; +@@ -1199,8 +1329,7 @@ static int macronix_set_quad_mode(struct spi_nor *nor) + * read (performance enhance) mode by mistake! + */ + nor->read_opcode = SPINOR_OP_READ_1_4_4; +- nor->read_dummy = 8; +- return 0; ++ return macronix_set_dummy_cycles(nor, 8); + } + + /* +@@ -1213,6 +1342,9 @@ static int macronix_set_quad_mode(struct spi_nor *nor) + * entering the continuous read mode by mistake if some + * performance enhance toggling bits P0-P7 were written during + * dummy/mode cycles. ++ * ++ * Use the Fast Read Quad Output 1-1-4 (0x6b) command with 8 dummy ++ * cycles (up to 133MHz for STR and 66MHz for DTR). + */ + status = macronix_quad_enable(nor); + if (status) { +@@ -1221,8 +1353,7 @@ static int macronix_set_quad_mode(struct spi_nor *nor) + } + nor->read_proto = SNOR_PROTO_1_1_4; + nor->read_opcode = SPINOR_OP_READ_1_1_4; +- nor->read_dummy = 8; +- return 0; ++ return macronix_set_dummy_cycles(nor, 8); + } + + /* +@@ -1233,16 +1364,25 @@ static int macronix_set_quad_mode(struct spi_nor *nor) + + static int macronix_set_dual_mode(struct spi_nor *nor) + { ++ /* ++ * Use the Fast Read Dual Output 1-1-2 (0x3b) command with 8 dummy ++ * cycles (up to 133MHz for STR and 66MHz for DTR). ++ */ + nor->read_proto = SNOR_PROTO_1_1_2; + nor->read_opcode = SPINOR_OP_READ_1_1_2; +- nor->read_dummy = 8; +- return 0; ++ return macronix_set_dummy_cycles(nor, 8); + } + + static int macronix_set_single_mode(struct spi_nor *nor) + { + u8 read_dummy; + ++ /* ++ * Configure 8 dummy cycles for Fast Read 1-1-1 (0x0b) command (up to ++ * 133MHz for STR and 66MHz for DTR). The Read 1-1-1 (0x03) command ++ * expects no dummy cycle. ++ * read_opcode should not be overridden here! ++ */ + switch (nor->read_opcode) { + case SPINOR_OP_READ: + case SPINOR_OP_READ4: +@@ -1255,8 +1395,7 @@ static int macronix_set_single_mode(struct spi_nor *nor) + } + + nor->read_proto = SNOR_PROTO_1_1_1; +- nor->read_dummy = read_dummy; +- return 0; ++ return macronix_set_dummy_cycles(nor, read_dummy); + } + + static int winbond_set_quad_mode(struct spi_nor *nor) +-- +2.8.1 + diff --git a/target/linux/socfpga/patches-4.4/0026-mtd-spi-nor-configure-the-number-of-dummy-clock-cycl.patch b/target/linux/socfpga/patches-4.4/0026-mtd-spi-nor-configure-the-number-of-dummy-clock-cycl.patch new file mode 100644 index 0000000..df79cdc --- /dev/null +++ b/target/linux/socfpga/patches-4.4/0026-mtd-spi-nor-configure-the-number-of-dummy-clock-cycl.patch @@ -0,0 +1,215 @@ +From 7b411f38f7882fdf9f5607bc75deb940a7aaa480 Mon Sep 17 00:00:00 2001 +From: Cyrille Pitchen +Date: Fri, 8 Jan 2016 17:10:53 +0100 +Subject: [PATCH 26/33] mtd: spi-nor: configure the number of dummy clock + cycles on Spansion memories + +On Spansion memories, the number of dummy clock cycles to be used during +Fast Read commands is configured through the 2bit latency code (LC). These +bits are non-volatile inside the Configuration Register. + +To avoid breaking the configuration expected at reset by some bootloaders, +we'd rather read the latency code and set the nor->read_dummy value +accordingly than update those non-volatile bits. + +Since the Quad Enable non-volatile bit can be read at the same time from +the Control Register, we now check its value to avoid some calls of the +spansion_quad_enable() function when they are not needed. + +Signed-off-by: Cyrille Pitchen +--- + drivers/mtd/spi-nor/spi-nor.c | 159 ++++++++++++++++++++++++++++++++++++------ + 1 file changed, 137 insertions(+), 22 deletions(-) + +diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c +index 55a1d74..654209a 100644 +--- a/drivers/mtd/spi-nor/spi-nor.c ++++ b/drivers/mtd/spi-nor/spi-nor.c +@@ -1687,47 +1687,162 @@ static int micron_set_single_mode(struct spi_nor *nor) + return micron_set_dummy_cycles(nor, read_dummy); + } + +-static int spansion_set_quad_mode(struct spi_nor *nor) ++static inline int spansion_get_config(struct spi_nor *nor, ++ bool *quad_enabled, ++ u8 *latency_code) + { +- int status; ++ int cr; + +- status = spansion_quad_enable(nor); +- if (status) { +- dev_err(nor->dev, "Spansion quad-read not enabled\n"); ++ cr = read_cr(nor); ++ if (cr < 0) { ++ dev_err(nor->dev, ++ "error while reading the configuration register\n"); ++ return cr; ++ } ++ ++ if (quad_enabled) ++ *quad_enabled = !!(cr & CR_QUAD_EN_SPAN); ++ ++ if (latency_code) ++ *latency_code = (u8)((cr & GENMASK(7, 6)) >> 6); ++ ++ return 0; ++} ++ ++static int spansion_set_dummy_cycles(struct spi_nor *nor, u8 latency_code) ++{ ++ /* SDR dummy cycles */ ++ switch (nor->read_opcode) { ++ case SPINOR_OP_READ: ++ case SPINOR_OP_READ4: ++ nor->read_dummy = 0; ++ break; ++ ++ case SPINOR_OP_READ_FAST: ++ case SPINOR_OP_READ_1_1_2: ++ case SPINOR_OP_READ_1_1_4: ++ case SPINOR_OP_READ4_FAST: ++ case SPINOR_OP_READ4_1_1_2: ++ case SPINOR_OP_READ4_1_1_4: ++ nor->read_dummy = (latency_code == 3) ? 0 : 8; ++ break; ++ ++ case SPINOR_OP_READ_1_2_2: ++ case SPINOR_OP_READ4_1_2_2: ++ switch (latency_code) { ++ default: ++ case 0: ++ case 3: ++ nor->read_dummy = 4; ++ break; ++ case 1: ++ nor->read_dummy = 5; ++ break; ++ case 2: ++ nor->read_dummy = 6; ++ break; ++ } ++ break; ++ ++ ++ case SPINOR_OP_READ_1_4_4: ++ case SPINOR_OP_READ4_1_4_4: ++ switch (latency_code) { ++ default: ++ case 0: ++ case 1: ++ nor->read_dummy = 4; ++ break; ++ case 2: ++ nor->read_dummy = 5; ++ break; ++ case 3: ++ nor->read_dummy = 1; ++ break; ++ } ++ ++ default: + return -EINVAL; + } ++ ++ return 0; ++} ++ ++static int spansion_set_quad_mode(struct spi_nor *nor) ++{ ++ bool quad_enabled; ++ u8 latency_code; ++ int ret; ++ ++ /* ++ * The QUAD bit of Configuration Register must be set (CR Bit1=1) for ++ * using any Quad SPI command. ++ */ ++ ret = spansion_get_config(nor, &quad_enabled, &latency_code); ++ if (ret) ++ return ret; ++ ++ /* The Quad mode should be enabled ... */ ++ if (!quad_enabled) { ++ /* ... if not try to enable it. */ ++ dev_warn(nor->dev, "Spansion Quad mode disabled, enable it\n"); ++ ret = spansion_quad_enable(nor); ++ if (ret) ++ return ret; ++ } ++ ++ /* ++ * Don't use the Fast Read Quad I/O (0xeb / 0xec) commands as their ++ * number of dummy cycles can not be set to a multiple of 8: some SPI ++ * controllers, especially those relying on the m25p80 driver, expect ++ * the number of dummy cycles to be a multiple of 8. ++ * Also when using a Fast Read Quad I/O command, the memory checks the ++ * value of the first mode/dummy cycles to decice whether it enters or ++ * leaves the Countinuous Read mode. We should never enter the ++ * Countinuous Read mode as the spi-nor framework doesn't support it. ++ * For all these reason, we'd rather use the Fast Read Quad Output ++ * 1-1-4 (0x6b / 0x6c) commands instead. ++ */ + nor->read_proto = SNOR_PROTO_1_1_4; + nor->read_opcode = SPINOR_OP_READ_1_1_4; +- nor->read_dummy = 8; +- return 0; ++ return spansion_set_dummy_cycles(nor, latency_code); + } + + static int spansion_set_dual_mode(struct spi_nor *nor) + { ++ u8 latency_code; ++ int ret; ++ ++ /* We don't care about the quad mode status */ ++ ret = spansion_get_config(nor, NULL, &latency_code); ++ if (ret) ++ return ret; ++ ++ /* ++ * Don't use the Fast Read Dual I/O (0xbb / 0xbc) commands as their ++ * number of dummy cycles can not bet set to a multiple of 8: some SPI ++ * controllers, especially those relying on the m25p80 driver, expect ++ * the number of dummy cycles to be a multiple of 8. ++ * For this reason, w'd rather use the Fast Read Dual Output 1-1-2 ++ * (0x3b / 0x3c) commands instead. ++ */ + nor->read_proto = SNOR_PROTO_1_1_2; + nor->read_opcode = SPINOR_OP_READ_1_1_2; +- nor->read_dummy = 8; +- return 0; ++ return spansion_set_dummy_cycles(nor, latency_code); + } + + static int spansion_set_single_mode(struct spi_nor *nor) + { +- u8 read_dummy; +- +- switch (nor->read_opcode) { +- case SPINOR_OP_READ: +- case SPINOR_OP_READ4: +- read_dummy = 0; +- break; ++ u8 latency_code; ++ int ret; + +- default: +- read_dummy = 8; +- break; +- } ++ /* We don't care about the quad mode status */ ++ ret = spansion_get_config(nor, NULL, &latency_code); ++ if (ret) ++ return ret; + + nor->read_proto = SNOR_PROTO_1_1_1; +- nor->read_dummy = read_dummy; +- return 0; ++ return spansion_set_dummy_cycles(nor, latency_code); + } + + static int set_quad_mode(struct spi_nor *nor, const struct flash_info *info) +-- +2.8.1 + diff --git a/target/linux/socfpga/patches-4.4/0027-mtd-m25p80-add-support-of-dual-and-quad-spi-protocol.patch b/target/linux/socfpga/patches-4.4/0027-mtd-m25p80-add-support-of-dual-and-quad-spi-protocol.patch new file mode 100644 index 0000000..d2f5ab6 --- /dev/null +++ b/target/linux/socfpga/patches-4.4/0027-mtd-m25p80-add-support-of-dual-and-quad-spi-protocol.patch @@ -0,0 +1,293 @@ +From 8b4f14b2f8ed819a6b9e371128259271e8d88841 Mon Sep 17 00:00:00 2001 +From: Cyrille Pitchen +Date: Fri, 8 Jan 2016 17:10:54 +0100 +Subject: [PATCH 27/33] mtd: m25p80: add support of dual and quad spi protocols + to all commands + +Before this patch, m25p80_read() supported few SPI protocols: +- regular SPI 1-1-1 +- SPI Dual Output 1-1-2 +- SPI Quad Output 1-1-4 +On the other hand, all other m25p80_*() hooks only supported SPI 1-1-1. + +However once their Quad mode enabled, Micron and Macronix spi-nor memories +expect all commands to use the SPI 4-4-4 protocol. + +Also, once their Dual mode enabled, Micron spi-nor memories expect all +commands to use the SPI-2-2-2 protocol. + +So this patch adds support to all currently existing SPI protocols to +cover as many protocols as possible. + +Signed-off-by: Cyrille Pitchen +--- + drivers/mtd/devices/m25p80.c | 192 ++++++++++++++++++++++++++++++++++--------- + 1 file changed, 151 insertions(+), 41 deletions(-) + +diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c +index bc7a802..e3e2708 100644 +--- a/drivers/mtd/devices/m25p80.c ++++ b/drivers/mtd/devices/m25p80.c +@@ -27,22 +27,64 @@ + #include + #include + +-#define MAX_CMD_SIZE 6 ++#define MAX_CMD_SIZE 16 + struct m25p { + struct spi_device *spi; + struct spi_nor spi_nor; + u8 command[MAX_CMD_SIZE]; + }; + ++static inline int m25p80_proto2nbits(enum spi_nor_protocol proto, ++ unsigned *code_nbits, ++ unsigned *addr_nbits, ++ unsigned *data_nbits) ++{ ++ if (code_nbits) ++ *code_nbits = SNOR_PROTO_CMD_FROM_PROTO(proto); ++ if (addr_nbits) ++ *addr_nbits = SNOR_PROTO_ADDR_FROM_PROTO(proto); ++ if (data_nbits) ++ *data_nbits = SNOR_PROTO_DATA_FROM_PROTO(proto); ++ ++ return 0; ++} ++ + static int m25p80_read_reg(struct spi_nor *nor, u8 code, u8 *val, int len) + { + struct m25p *flash = nor->priv; + struct spi_device *spi = flash->spi; ++ unsigned code_nbits, data_nbits; ++ struct spi_transfer xfers[2]; + int ret; + +- ret = spi_write_then_read(spi, &code, 1, val, len); ++ /* Check the total length of command op code and data. */ ++ if (len + 1 > MAX_CMD_SIZE) ++ return -EINVAL; ++ ++ /* Get transfer protocols (addr_nbits is not relevant here). */ ++ ret = m25p80_proto2nbits(nor->reg_proto, ++ &code_nbits, NULL, &data_nbits); ++ if (ret < 0) ++ return ret; ++ ++ /* Set up transfers. */ ++ memset(xfers, 0, sizeof(xfers)); ++ ++ flash->command[0] = code; ++ xfers[0].len = 1; ++ xfers[0].tx_buf = flash->command; ++ xfers[0].tx_nbits = code_nbits; ++ ++ xfers[1].len = len; ++ xfers[1].rx_buf = &flash->command[1]; ++ xfers[1].rx_nbits = data_nbits; ++ ++ /* Process command. */ ++ ret = spi_sync_transfer(spi, xfers, 2); + if (ret < 0) + dev_err(&spi->dev, "error %d reading %x\n", ret, code); ++ else ++ memcpy(val, &flash->command[1], len); + + return ret; + } +@@ -65,12 +107,42 @@ static int m25p80_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf, int len) + { + struct m25p *flash = nor->priv; + struct spi_device *spi = flash->spi; ++ unsigned code_nbits, data_nbits, num_xfers = 1; ++ struct spi_transfer xfers[2]; ++ int ret; ++ ++ /* Check the total length of command op code and data. */ ++ if (buf && (len + 1 > MAX_CMD_SIZE)) ++ return -EINVAL; ++ ++ /* Get transfer protocols (addr_nbits is not relevant here). */ ++ ret = m25p80_proto2nbits(nor->reg_proto, ++ &code_nbits, NULL, &data_nbits); ++ if (ret < 0) ++ return ret; ++ ++ /* Set up transfer(s). */ ++ memset(xfers, 0, sizeof(xfers)); + + flash->command[0] = opcode; +- if (buf) ++ xfers[0].len = 1; ++ xfers[0].tx_buf = flash->command; ++ xfers[0].tx_nbits = code_nbits; ++ ++ if (buf) { + memcpy(&flash->command[1], buf, len); ++ if (data_nbits == code_nbits) { ++ xfers[0].len += len; ++ } else { ++ xfers[1].len = len; ++ xfers[1].tx_buf = &flash->command[1]; ++ xfers[1].tx_nbits = data_nbits; ++ num_xfers++; ++ } ++ } + +- return spi_write(spi, flash->command, len + 1); ++ /* Process command. */ ++ return spi_sync_transfer(spi, xfers, num_xfers); + } + + static void m25p80_write(struct spi_nor *nor, loff_t to, size_t len, +@@ -78,43 +150,54 @@ static void m25p80_write(struct spi_nor *nor, loff_t to, size_t len, + { + struct m25p *flash = nor->priv; + struct spi_device *spi = flash->spi; +- struct spi_transfer t[2] = {}; ++ unsigned code_nbits, addr_nbits, data_nbits, num_xfers = 1; ++ struct spi_transfer xfers[3]; + struct spi_message m; +- int cmd_sz = m25p_cmdsz(nor); +- +- spi_message_init(&m); ++ int ret, cmd_sz = m25p_cmdsz(nor); + + if (nor->program_opcode == SPINOR_OP_AAI_WP && nor->sst_write_second) + cmd_sz = 1; + +- flash->command[0] = nor->program_opcode; +- m25p_addr2cmd(nor, to, flash->command); ++ /* Get transfer protocols. */ ++ ret = m25p80_proto2nbits(nor->write_proto, ++ &code_nbits, &addr_nbits, &data_nbits); ++ if (ret < 0) { ++ *retlen = 0; ++ return; ++ } + +- t[0].tx_buf = flash->command; +- t[0].len = cmd_sz; +- spi_message_add_tail(&t[0], &m); ++ /* Set up transfers. */ ++ memset(xfers, 0, sizeof(xfers)); ++ ++ flash->command[0] = nor->program_opcode; ++ xfers[0].len = 1; ++ xfers[0].tx_buf = flash->command; ++ xfers[0].tx_nbits = code_nbits; ++ ++ if (cmd_sz > 1) { ++ m25p_addr2cmd(nor, to, flash->command); ++ if (addr_nbits == code_nbits) { ++ xfers[0].len += nor->addr_width; ++ } else { ++ xfers[1].len = nor->addr_width; ++ xfers[1].tx_buf = &flash->command[1]; ++ xfers[1].tx_nbits = addr_nbits; ++ num_xfers++; ++ } ++ } + +- t[1].tx_buf = buf; +- t[1].len = len; +- spi_message_add_tail(&t[1], &m); ++ xfers[num_xfers].len = len; ++ xfers[num_xfers].tx_buf = buf; ++ xfers[num_xfers].tx_nbits = data_nbits; ++ num_xfers++; + ++ /* Process command. */ ++ spi_message_init_with_transfers(&m, xfers, num_xfers); + spi_sync(spi, &m); + + *retlen += m.actual_length - cmd_sz; + } + +-static inline unsigned int m25p80_rx_nbits(struct spi_nor *nor) +-{ +- switch (nor->flash_read) { +- case SPI_NOR_DUAL: +- return 2; +- case SPI_NOR_QUAD: +- return 4; +- default: +- return 0; +- } +-} +- + /* + * Read an address range from the nor chip. The address range + * may be any size provided it is within the physical boundaries. +@@ -124,28 +207,55 @@ static int m25p80_read(struct spi_nor *nor, loff_t from, size_t len, + { + struct m25p *flash = nor->priv; + struct spi_device *spi = flash->spi; +- struct spi_transfer t[2]; +- struct spi_message m; ++ unsigned code_nbits, addr_nbits, data_nbits, num_xfers = 1; + unsigned int dummy = nor->read_dummy; ++ struct spi_transfer xfers[3]; ++ struct spi_message m; ++ int ret; ++ ++ /* Get transfer protocols. */ ++ ret = m25p80_proto2nbits(nor->read_proto, ++ &code_nbits, &addr_nbits, &data_nbits); ++ if (ret < 0) { ++ *retlen = 0; ++ return ret; ++ } + + /* convert the dummy cycles to the number of bytes */ +- dummy /= 8; ++ dummy = (dummy * addr_nbits) / 8; + +- spi_message_init(&m); +- memset(t, 0, (sizeof t)); ++ /* Set up transfers. */ ++ memset(xfers, 0, sizeof(xfers)); + + flash->command[0] = nor->read_opcode; +- m25p_addr2cmd(nor, from, flash->command); ++ xfers[0].len = 1; ++ xfers[0].tx_buf = flash->command; ++ xfers[0].tx_nbits = code_nbits; + +- t[0].tx_buf = flash->command; +- t[0].len = m25p_cmdsz(nor) + dummy; +- spi_message_add_tail(&t[0], &m); ++ m25p_addr2cmd(nor, from, flash->command); ++ /* ++ * Clear all dummy/mode cycle bits to avoid sending some manufacturer ++ * specific pattern, which might make the memory enter its Continuous ++ * Read mode by mistake. ++ */ ++ memset(flash->command + 1 + nor->addr_width, 0, dummy); ++ ++ if (addr_nbits == code_nbits) { ++ xfers[0].len += nor->addr_width + dummy; ++ } else { ++ xfers[1].len = nor->addr_width + dummy; ++ xfers[1].tx_buf = &flash->command[1]; ++ xfers[1].tx_nbits = addr_nbits; ++ num_xfers++; ++ } + +- t[1].rx_buf = buf; +- t[1].rx_nbits = m25p80_rx_nbits(nor); +- t[1].len = len; +- spi_message_add_tail(&t[1], &m); ++ xfers[num_xfers].len = len; ++ xfers[num_xfers].rx_buf = buf; ++ xfers[num_xfers].rx_nbits = data_nbits; ++ num_xfers++; + ++ /* Process command. */ ++ spi_message_init_with_transfers(&m, xfers, num_xfers); + spi_sync(spi, &m); + + *retlen = m.actual_length - m25p_cmdsz(nor) - dummy; +-- +2.8.1 + diff --git a/target/linux/socfpga/patches-4.4/0028-mtd-ofpart-grab-device-tree-node-directly-from-maste.patch b/target/linux/socfpga/patches-4.4/0028-mtd-ofpart-grab-device-tree-node-directly-from-maste.patch new file mode 100644 index 0000000..3787607 --- /dev/null +++ b/target/linux/socfpga/patches-4.4/0028-mtd-ofpart-grab-device-tree-node-directly-from-maste.patch @@ -0,0 +1,81 @@ +From 62b613003aa4cef3f8bf9a2ec4c7709daf4dde8a Mon Sep 17 00:00:00 2001 +From: Brian Norris +Date: Fri, 30 Oct 2015 20:33:21 -0700 +Subject: [PATCH 28/33] mtd: ofpart: grab device tree node directly from master + device node + +It seems more logical to use a device node directly associated with the +MTD master device (i.e., mtd->dev.of_node field) rather than requiring +auxiliary partition parser information to be passed in by the driver in +a separate struct. + +This patch supports the mtd->dev.of_node field and deprecates the parser +data 'of_node' field + +Driver conversions may now follow. + +Additional side benefit to assigning mtd->dev.of_node rather than using +parser data: the driver core will automatically create a device -> node +symlink for us. + +Signed-off-by: Brian Norris +Reviewed-by: Boris Brezillon +--- + drivers/mtd/ofpart.c | 18 ++++++++++-------- + include/linux/mtd/partitions.h | 4 +++- + 2 files changed, 13 insertions(+), 9 deletions(-) + +diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/ofpart.c +index 9ed6038..cf4780c 100644 +--- a/drivers/mtd/ofpart.c ++++ b/drivers/mtd/ofpart.c +@@ -37,10 +37,11 @@ static int parse_ofpart_partitions(struct mtd_info *master, + bool dedicated = true; + + +- if (!data) +- return 0; +- +- mtd_node = data->of_node; ++ /* ++ * of_node can be provided through auxiliary parser data or (preferred) ++ * by assigning the master device node ++ */ ++ mtd_node = data && data->of_node ? data->of_node : mtd_get_of_node(master); + if (!mtd_node) + return 0; + +@@ -157,10 +158,11 @@ static int parse_ofoldpart_partitions(struct mtd_info *master, + } *part; + const char *names; + +- if (!data) +- return 0; +- +- dp = data->of_node; ++ /* ++ * of_node can be provided through auxiliary parser data or (preferred) ++ * by assigning the master device node ++ */ ++ dp = data && data->of_node ? data->of_node : mtd_get_of_node(master); + if (!dp) + return 0; + +diff --git a/include/linux/mtd/partitions.h b/include/linux/mtd/partitions.h +index 6a35e6d..e742f34 100644 +--- a/include/linux/mtd/partitions.h ++++ b/include/linux/mtd/partitions.h +@@ -56,7 +56,9 @@ struct device_node; + /** + * struct mtd_part_parser_data - used to pass data to MTD partition parsers. + * @origin: for RedBoot, start address of MTD device +- * @of_node: for OF parsers, device node containing partitioning information ++ * @of_node: for OF parsers, device node containing partitioning information. ++ * This field is deprecated, as the device node should simply be ++ * assigned to the master struct device. + */ + struct mtd_part_parser_data { + unsigned long origin; +-- +2.8.1 + diff --git a/target/linux/socfpga/patches-4.4/0029-Documentation-atmel-quadspi-add-binding-file-for-Atm.patch b/target/linux/socfpga/patches-4.4/0029-Documentation-atmel-quadspi-add-binding-file-for-Atm.patch new file mode 100644 index 0000000..ca8831d --- /dev/null +++ b/target/linux/socfpga/patches-4.4/0029-Documentation-atmel-quadspi-add-binding-file-for-Atm.patch @@ -0,0 +1,58 @@ +From 771ee7cd27c39617ece8727c70f904c31f7415fb Mon Sep 17 00:00:00 2001 +From: Cyrille Pitchen +Date: Fri, 8 Jan 2016 17:10:55 +0100 +Subject: [PATCH 29/33] Documentation: atmel-quadspi: add binding file for + Atmel QSPI driver + +This patch documents the DT bindings for the driver of the Atmel QSPI +controller embedded inside sama5d2x SoCs. + +Signed-off-by: Cyrille Pitchen +Acked-by: Rob Herring +Acked-by: Nicolas Ferre +--- + .../devicetree/bindings/mtd/atmel-quadspi.txt | 32 ++++++++++++++++++++++ + 1 file changed, 32 insertions(+) + create mode 100644 Documentation/devicetree/bindings/mtd/atmel-quadspi.txt + +diff --git a/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt b/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt +new file mode 100644 +index 0000000..4898070 +--- /dev/null ++++ b/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt +@@ -0,0 +1,32 @@ ++* Atmel Quad Serial Peripheral Interface (QSPI) ++ ++Required properties: ++- compatible: Should be "atmel,sama5d2-qspi". ++- reg: Should contain the locations and lengths of the base registers ++ and the mapped memory. ++- reg-names: Should contain the resource reg names: ++ - qspi_base: configuration register address space ++ - qspi_mmap: memory mapped address space ++- interrupts: Should contain the interrupt for the device. ++- clocks: The phandle of the clock needed by the QSPI controller. ++- #address-cells: Should be <1>. ++- #size-cells: Should be <0>. ++ ++Example: ++ ++spi at f0020000 { ++ compatible = "atmel,sama5d2-qspi"; ++ reg = <0xf0020000 0x100>, <0xd0000000 0x8000000>; ++ reg-names = "qspi_base", "qspi_mmap"; ++ interrupts = <52 IRQ_TYPE_LEVEL_HIGH 7>; ++ clocks = <&spi0_clk>; ++ #address-cells = <1>; ++ #size-cells = <0>; ++ pinctrl-names = "default"; ++ pinctrl-0 = <&pinctrl_spi0_default>; ++ status = "okay"; ++ ++ m25p80 at 0 { ++ ... ++ }; ++}; +-- +2.8.1 + diff --git a/target/linux/socfpga/patches-4.4/0030-mtd-spi-nor-Bindings-for-Cadence-Quad-SPI-Flash-Cont.patch b/target/linux/socfpga/patches-4.4/0030-mtd-spi-nor-Bindings-for-Cadence-Quad-SPI-Flash-Cont.patch new file mode 100644 index 0000000..7b454a8 --- /dev/null +++ b/target/linux/socfpga/patches-4.4/0030-mtd-spi-nor-Bindings-for-Cadence-Quad-SPI-Flash-Cont.patch @@ -0,0 +1,99 @@ +From 8e8a7168e89cc978ca14ab74ab20193ca09e3f3a Mon Sep 17 00:00:00 2001 +From: Graham Moore +Date: Tue, 28 Jul 2015 12:38:02 -0500 +Subject: [PATCH 30/33] mtd: spi-nor: Bindings for Cadence Quad SPI Flash + Controller driver. + +Add binding document for the Cadence QSPI controller. + +Signed-off-by: Graham Moore +Signed-off-by: Marek Vasut +Cc: Alan Tull +Cc: Brian Norris +Cc: David Woodhouse +Cc: Dinh Nguyen +Cc: Graham Moore +Cc: Vignesh R +Cc: Yves Vandervennet +Cc: devicetree at vger.kernel.org + +V2: Add cdns prefix to driver-specific bindings. +V3: Use existing property "is-decoded-cs" instead of creating a + duplicate, "ext-decoder". Timing parameters are in nanoseconds, + not master reference clocks. Remove bus-num completely. +V4: Add new properties fifo-width and trigger-address +V7: - Prefix all of the Cadence-specific properties with cdns prefix, + those are in particular "cdns,is-decoded-cs", "cdns,fifo-depth", + "cdns,fifo-width", "cdns,trigger-address". + - Drop bogus properties which were not used and were incorrect. +V8: Align lines to 80 chars. +--- + .../devicetree/bindings/mtd/cadence-quadspi.txt | 56 ++++++++++++++++++++++ + 1 file changed, 56 insertions(+) + create mode 100644 Documentation/devicetree/bindings/mtd/cadence-quadspi.txt + +diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt +new file mode 100644 +index 0000000..f248056 +--- /dev/null ++++ b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt +@@ -0,0 +1,56 @@ ++* Cadence Quad SPI controller ++ ++Required properties: ++- compatible : Should be "cdns,qspi-nor". ++- reg : Contains two entries, each of which is a tuple consisting of a ++ physical address and length. The first entry is the address and ++ length of the controller register set. The second entry is the ++ address and length of the QSPI Controller data area. ++- interrupts : Unit interrupt specifier for the controller interrupt. ++- clocks : phandle to the Quad SPI clock. ++- cdns,fifo-depth : Size of the data FIFO in words. ++- cdns,fifo-width : Bus width of the data FIFO in bytes. ++- cdns,trigger-address : 32-bit indirect AHB trigger address. ++ ++Optional properties: ++- cdns,is-decoded-cs : Flag to indicate whether decoder is used or not. ++ ++Optional subnodes: ++Subnodes of the Cadence Quad SPI controller are spi slave nodes with additional ++custom properties: ++- cdns,read-delay : Delay for read capture logic, in clock cycles ++- cdns,tshsl-ns : Delay in nanoseconds for the length that the master ++ mode chip select outputs are de-asserted between ++ transactions. ++- cdns,tsd2d-ns : Delay in nanoseconds between one chip select being ++ de-activated and the activation of another. ++- cdns,tchsh-ns : Delay in nanoseconds between last bit of current ++ transaction and deasserting the device chip select ++ (qspi_n_ss_out). ++- cdns,tslch-ns : Delay in nanoseconds between setting qspi_n_ss_out low ++ and first bit transfer. ++ ++Example: ++ ++ qspi: spi at ff705000 { ++ compatible = "cdns,qspi-nor"; ++ #address-cells = <1>; ++ #size-cells = <0>; ++ reg = <0xff705000 0x1000>, ++ <0xffa00000 0x1000>; ++ interrupts = <0 151 4>; ++ clocks = <&qspi_clk>; ++ cdns,is-decoded-cs; ++ cdns,fifo-depth = <128>; ++ cdns,fifo-width = <4>; ++ cdns,trigger-address = <0x00000000>; ++ ++ flash0: n25q00 at 0 { ++ ... ++ cdns,read-delay = <4>; ++ cdns,tshsl-ns = <50>; ++ cdns,tsd2d-ns = <50>; ++ cdns,tchsh-ns = <4>; ++ cdns,tslch-ns = <4>; ++ }; ++ }; +-- +2.8.1 + diff --git a/target/linux/socfpga/patches-4.4/0031-mtd-spi-nor-Add-driver-for-Cadence-Quad-SPI-Flash-Co.patch b/target/linux/socfpga/patches-4.4/0031-mtd-spi-nor-Add-driver-for-Cadence-Quad-SPI-Flash-Co.patch new file mode 100644 index 0000000..1a55ee2 --- /dev/null +++ b/target/linux/socfpga/patches-4.4/0031-mtd-spi-nor-Add-driver-for-Cadence-Quad-SPI-Flash-Co.patch @@ -0,0 +1,1431 @@ +From 30e33517815b3c518fc2483a23bfe1445c0ae92d Mon Sep 17 00:00:00 2001 +From: Graham Moore +Date: Tue, 28 Jul 2015 12:38:03 -0500 +Subject: [PATCH 31/33] mtd: spi-nor: Add driver for Cadence Quad SPI Flash + Controller. + +Add support for the Cadence QSPI controller. This controller is +present in the Altera SoCFPGA SoCs and this driver has been tested +on the Cyclone V SoC. + +Signed-off-by: Graham Moore +Signed-off-by: Marek Vasut +Cc: Alan Tull +Cc: Brian Norris +Cc: David Woodhouse +Cc: Dinh Nguyen +Cc: Graham Moore +Cc: Vignesh R +Cc: Yves Vandervennet +Cc: devicetree at vger.kernel.org + +V2: use NULL instead of modalias in spi_nor_scan call +V3: Use existing property is-decoded-cs instead of creating duplicate. +V4: Support Micron quad mode by snooping command stream for EVCR command + and subsequently configuring Cadence controller for quad mode. +V5: Clean up sparse and smatch complaints. Remove snooping of Micron + quad mode. Add comment on XIP mode bit and dummy clock cycles. Set + up SRAM partition at 1:1 during init. +V6: Remove dts patch that was included by mistake. Incorporate Vikas's + comments regarding fifo width, SRAM partition setting, and trigger + address. Trigger address was added as an unsigned int, as it is not + an IO resource per se, and does not need to be mapped. Also add + Marek Vasut's workaround for picking up OF properties on subnodes. +V7: - Perform coding-style cleanup and type fixes. Remove ugly QSPI_*() + macros and replace them with functions. Get rid of unused variables. + - Implement support for nor->set_protocol() to handle Quad-command, + this patch now depends on the following patch: + mtd: spi-nor: notify (Q)SPI controller about protocol change + - Replace that cqspi_fifo_read() disaster with plain old readsl() + and cqspi_fifo_write() tentacle horror with pretty writesl(). + - Remove CQSPI_SUPPORT_XIP_CHIPS, which is broken. + - Get rid of cqspi_find_chipselect() mess, instead just place the + struct cqspi_st and chipselect number into struct cqspi_flash_pdata + and set nor->priv to the struct cqspi_flash_pdata of that particular + chip. + - Replace the odd math in calculate_ticks_for_ns() with DIV_ROUND_UP(). + - Make variables const where applicable. +V8: - Implement a function to wait for bit being set/unset for a given + period of time and use it to replace the ad-hoc bits of code. + - Configure the write underflow watermark to be 1/8 if FIFO size. + - Extract out the SPI NOR flash probing code into separate function + to clearly mark what will soon be considered a boilerplate code. + - Repair the handling of mode bits, which caused instability in V7. + - Clean up the interrupt handling + - Fix Kconfig help text and make the patch depend on OF and COMPILE_TEST. +V9: - Rename CQSPI_REG_IRQ_IND_RD_OVERFLOW to CQSPI_REG_IRQ_IND_SRAM_FULL + - Merge cqspi_controller_disable() into cqspi_controller_enable() and + make the mode selectable via parameter. +V10: - Update against Cyrille's new patchset and changes to linux-mtd. + - Repair problem with multiple QSPI NOR devices having the same mtd->name, + they are now named devname.cs , where cs is the chipselect ID. +V11: - Replace dependency on ARCH_SOCFPGA with dependency on ARM +--- + drivers/mtd/spi-nor/Kconfig | 11 + + drivers/mtd/spi-nor/Makefile | 1 + + drivers/mtd/spi-nor/cadence-quadspi.c | 1324 +++++++++++++++++++++++++++++++++ + 3 files changed, 1336 insertions(+) + create mode 100644 drivers/mtd/spi-nor/cadence-quadspi.c + +diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig +index 2fe2a7e..02082ae 100644 +--- a/drivers/mtd/spi-nor/Kconfig ++++ b/drivers/mtd/spi-nor/Kconfig +@@ -41,4 +41,15 @@ config SPI_NXP_SPIFI + Flash. Enable this option if you have a device with a SPIFI + controller and want to access the Flash as a mtd device. + ++config SPI_CADENCE_QUADSPI ++ tristate "Cadence Quad SPI controller" ++ depends on OF && (ARM || COMPILE_TEST) ++ help ++ Enable support for the Cadence Quad SPI Flash controller. ++ ++ Cadence QSPI is a specialized controller for connecting an SPI ++ Flash over 1/2/4-bit wide bus. Enable this option if you have a ++ device with a Cadence QSPI controller and want to access the ++ Flash as an MTD device. ++ + endif # MTD_SPI_NOR +diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile +index e53333e..446c6b9 100644 +--- a/drivers/mtd/spi-nor/Makefile ++++ b/drivers/mtd/spi-nor/Makefile +@@ -1,3 +1,4 @@ + obj-$(CONFIG_MTD_SPI_NOR) += spi-nor.o ++obj-$(CONFIG_SPI_CADENCE_QUADSPI) += cadence-quadspi.o + obj-$(CONFIG_SPI_FSL_QUADSPI) += fsl-quadspi.o + obj-$(CONFIG_SPI_NXP_SPIFI) += nxp-spifi.o +diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c b/drivers/mtd/spi-nor/cadence-quadspi.c +new file mode 100644 +index 0000000..7e61fba +--- /dev/null ++++ b/drivers/mtd/spi-nor/cadence-quadspi.c +@@ -0,0 +1,1324 @@ ++/* ++ * Driver for Cadence QSPI Controller ++ * ++ * Copyright Altera Corporation (C) 2012-2014. All rights reserved. ++ * ++ * This program is free software; you can redistribute it and/or modify ++ * it under the terms and conditions of the GNU General Public License, ++ * version 2, as published by the Free Software Foundation. ++ * ++ * This program is distributed in the hope 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, see . ++ */ ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++#include ++ ++#define CQSPI_NAME "cadence-qspi" ++#define CQSPI_MAX_CHIPSELECT 16 ++ ++struct cqspi_st; ++ ++struct cqspi_flash_pdata { ++ struct spi_nor nor; ++ struct cqspi_st *cqspi; ++ u32 clk_rate; ++ u32 read_delay; ++ u32 tshsl_ns; ++ u32 tsd2d_ns; ++ u32 tchsh_ns; ++ u32 tslch_ns; ++ u8 inst_width; ++ u8 addr_width; ++ u8 cs; ++}; ++ ++struct cqspi_st { ++ struct platform_device *pdev; ++ ++ struct clk *clk; ++ unsigned int sclk; ++ ++ void __iomem *iobase; ++ void __iomem *ahb_base; ++ struct completion transfer_complete; ++ struct mutex bus_mutex; ++ ++ int current_cs; ++ unsigned long master_ref_clk_hz; ++ bool is_decoded_cs; ++ u32 fifo_depth; ++ u32 fifo_width; ++ u32 trigger_address; ++ struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT]; ++}; ++ ++/* Operation timeout value */ ++#define CQSPI_TIMEOUT_MS 500 ++#define CQSPI_READ_TIMEOUT_MS 10 ++ ++/* Instruction type */ ++#define CQSPI_INST_TYPE_SINGLE 0 ++#define CQSPI_INST_TYPE_DUAL 1 ++#define CQSPI_INST_TYPE_QUAD 2 ++ ++#define CQSPI_DUMMY_CLKS_PER_BYTE 8 ++#define CQSPI_DUMMY_BYTES_MAX 4 ++#define CQSPI_DUMMY_CLKS_MAX 31 ++ ++#define CQSPI_STIG_DATA_LEN_MAX 8 ++ ++/* Register map */ ++#define CQSPI_REG_CONFIG 0x00 ++#define CQSPI_REG_CONFIG_ENABLE_MASK BIT(0) ++#define CQSPI_REG_CONFIG_DECODE_MASK BIT(9) ++#define CQSPI_REG_CONFIG_CHIPSELECT_LSB 10 ++#define CQSPI_REG_CONFIG_DMA_MASK BIT(15) ++#define CQSPI_REG_CONFIG_BAUD_LSB 19 ++#define CQSPI_REG_CONFIG_IDLE_LSB 31 ++#define CQSPI_REG_CONFIG_CHIPSELECT_MASK 0xF ++#define CQSPI_REG_CONFIG_BAUD_MASK 0xF ++ ++#define CQSPI_REG_RD_INSTR 0x04 ++#define CQSPI_REG_RD_INSTR_OPCODE_LSB 0 ++#define CQSPI_REG_RD_INSTR_TYPE_INSTR_LSB 8 ++#define CQSPI_REG_RD_INSTR_TYPE_ADDR_LSB 12 ++#define CQSPI_REG_RD_INSTR_TYPE_DATA_LSB 16 ++#define CQSPI_REG_RD_INSTR_MODE_EN_LSB 20 ++#define CQSPI_REG_RD_INSTR_DUMMY_LSB 24 ++#define CQSPI_REG_RD_INSTR_TYPE_INSTR_MASK 0x3 ++#define CQSPI_REG_RD_INSTR_TYPE_ADDR_MASK 0x3 ++#define CQSPI_REG_RD_INSTR_TYPE_DATA_MASK 0x3 ++#define CQSPI_REG_RD_INSTR_DUMMY_MASK 0x1F ++ ++#define CQSPI_REG_WR_INSTR 0x08 ++#define CQSPI_REG_WR_INSTR_OPCODE_LSB 0 ++#define CQSPI_REG_WR_INSTR_TYPE_ADDR_LSB 12 ++#define CQSPI_REG_WR_INSTR_TYPE_DATA_LSB 16 ++ ++#define CQSPI_REG_DELAY 0x0C ++#define CQSPI_REG_DELAY_TSLCH_LSB 0 ++#define CQSPI_REG_DELAY_TCHSH_LSB 8 ++#define CQSPI_REG_DELAY_TSD2D_LSB 16 ++#define CQSPI_REG_DELAY_TSHSL_LSB 24 ++#define CQSPI_REG_DELAY_TSLCH_MASK 0xFF ++#define CQSPI_REG_DELAY_TCHSH_MASK 0xFF ++#define CQSPI_REG_DELAY_TSD2D_MASK 0xFF ++#define CQSPI_REG_DELAY_TSHSL_MASK 0xFF ++ ++#define CQSPI_REG_READCAPTURE 0x10 ++#define CQSPI_REG_READCAPTURE_BYPASS_LSB 0 ++#define CQSPI_REG_READCAPTURE_DELAY_LSB 1 ++#define CQSPI_REG_READCAPTURE_DELAY_MASK 0xF ++ ++#define CQSPI_REG_SIZE 0x14 ++#define CQSPI_REG_SIZE_ADDRESS_LSB 0 ++#define CQSPI_REG_SIZE_PAGE_LSB 4 ++#define CQSPI_REG_SIZE_BLOCK_LSB 16 ++#define CQSPI_REG_SIZE_ADDRESS_MASK 0xF ++#define CQSPI_REG_SIZE_PAGE_MASK 0xFFF ++#define CQSPI_REG_SIZE_BLOCK_MASK 0x3F ++ ++#define CQSPI_REG_SRAMPARTITION 0x18 ++#define CQSPI_REG_INDIRECTTRIGGER 0x1C ++ ++#define CQSPI_REG_DMA 0x20 ++#define CQSPI_REG_DMA_SINGLE_LSB 0 ++#define CQSPI_REG_DMA_BURST_LSB 8 ++#define CQSPI_REG_DMA_SINGLE_MASK 0xFF ++#define CQSPI_REG_DMA_BURST_MASK 0xFF ++ ++#define CQSPI_REG_REMAP 0x24 ++#define CQSPI_REG_MODE_BIT 0x28 ++ ++#define CQSPI_REG_SDRAMLEVEL 0x2C ++#define CQSPI_REG_SDRAMLEVEL_RD_LSB 0 ++#define CQSPI_REG_SDRAMLEVEL_WR_LSB 16 ++#define CQSPI_REG_SDRAMLEVEL_RD_MASK 0xFFFF ++#define CQSPI_REG_SDRAMLEVEL_WR_MASK 0xFFFF ++ ++#define CQSPI_REG_IRQSTATUS 0x40 ++#define CQSPI_REG_IRQMASK 0x44 ++ ++#define CQSPI_REG_INDIRECTRD 0x60 ++#define CQSPI_REG_INDIRECTRD_START_MASK BIT(0) ++#define CQSPI_REG_INDIRECTRD_CANCEL_MASK BIT(1) ++#define CQSPI_REG_INDIRECTRD_DONE_MASK BIT(5) ++ ++#define CQSPI_REG_INDIRECTRDWATERMARK 0x64 ++#define CQSPI_REG_INDIRECTRDSTARTADDR 0x68 ++#define CQSPI_REG_INDIRECTRDBYTES 0x6C ++ ++#define CQSPI_REG_CMDCTRL 0x90 ++#define CQSPI_REG_CMDCTRL_EXECUTE_MASK BIT(0) ++#define CQSPI_REG_CMDCTRL_INPROGRESS_MASK BIT(1) ++#define CQSPI_REG_CMDCTRL_WR_BYTES_LSB 12 ++#define CQSPI_REG_CMDCTRL_WR_EN_LSB 15 ++#define CQSPI_REG_CMDCTRL_ADD_BYTES_LSB 16 ++#define CQSPI_REG_CMDCTRL_ADDR_EN_LSB 19 ++#define CQSPI_REG_CMDCTRL_RD_BYTES_LSB 20 ++#define CQSPI_REG_CMDCTRL_RD_EN_LSB 23 ++#define CQSPI_REG_CMDCTRL_OPCODE_LSB 24 ++#define CQSPI_REG_CMDCTRL_WR_BYTES_MASK 0x7 ++#define CQSPI_REG_CMDCTRL_ADD_BYTES_MASK 0x3 ++#define CQSPI_REG_CMDCTRL_RD_BYTES_MASK 0x7 ++ ++#define CQSPI_REG_INDIRECTWR 0x70 ++#define CQSPI_REG_INDIRECTWR_START_MASK BIT(0) ++#define CQSPI_REG_INDIRECTWR_CANCEL_MASK BIT(1) ++#define CQSPI_REG_INDIRECTWR_DONE_MASK BIT(5) ++ ++#define CQSPI_REG_INDIRECTWRWATERMARK 0x74 ++#define CQSPI_REG_INDIRECTWRSTARTADDR 0x78 ++#define CQSPI_REG_INDIRECTWRBYTES 0x7C ++ ++#define CQSPI_REG_CMDADDRESS 0x94 ++#define CQSPI_REG_CMDREADDATALOWER 0xA0 ++#define CQSPI_REG_CMDREADDATAUPPER 0xA4 ++#define CQSPI_REG_CMDWRITEDATALOWER 0xA8 ++#define CQSPI_REG_CMDWRITEDATAUPPER 0xAC ++ ++/* Interrupt status bits */ ++#define CQSPI_REG_IRQ_MODE_ERR BIT(0) ++#define CQSPI_REG_IRQ_UNDERFLOW BIT(1) ++#define CQSPI_REG_IRQ_IND_COMP BIT(2) ++#define CQSPI_REG_IRQ_IND_RD_REJECT BIT(3) ++#define CQSPI_REG_IRQ_WR_PROTECTED_ERR BIT(4) ++#define CQSPI_REG_IRQ_ILLEGAL_AHB_ERR BIT(5) ++#define CQSPI_REG_IRQ_WATERMARK BIT(6) ++#define CQSPI_REG_IRQ_IND_SRAM_FULL BIT(12) ++ ++#define CQSPI_IRQ_MASK_RD (CQSPI_REG_IRQ_WATERMARK | \ ++ CQSPI_REG_IRQ_IND_SRAM_FULL | \ ++ CQSPI_REG_IRQ_IND_COMP) ++ ++#define CQSPI_IRQ_MASK_WR (CQSPI_REG_IRQ_IND_COMP | \ ++ CQSPI_REG_IRQ_WATERMARK | \ ++ CQSPI_REG_IRQ_UNDERFLOW) ++ ++#define CQSPI_IRQ_STATUS_MASK 0x1FFFF ++ ++static int cqspi_wait_for_bit(void __iomem *reg, const u32 mask, bool clear) ++{ ++ unsigned long end = jiffies + msecs_to_jiffies(CQSPI_TIMEOUT_MS); ++ u32 val; ++ ++ while (1) { ++ val = readl(reg); ++ if (clear) ++ val = ~val; ++ val &= mask; ++ ++ if (val == mask) ++ return 0; ++ ++ if (time_after(jiffies, end)) ++ return -ETIMEDOUT; ++ } ++} ++ ++static bool cqspi_is_idle(struct cqspi_st *cqspi) ++{ ++ u32 reg = readl(cqspi->iobase + CQSPI_REG_CONFIG); ++ ++ return reg & (1 << CQSPI_REG_CONFIG_IDLE_LSB); ++} ++ ++static u32 cqspi_get_rd_sram_level(struct cqspi_st *cqspi) ++{ ++ u32 reg = readl(cqspi->iobase + CQSPI_REG_SDRAMLEVEL); ++ ++ reg >>= CQSPI_REG_SDRAMLEVEL_RD_LSB; ++ return reg & CQSPI_REG_SDRAMLEVEL_RD_MASK; ++} ++ ++static irqreturn_t cqspi_irq_handler(int this_irq, void *dev) ++{ ++ struct cqspi_st *cqspi = dev; ++ unsigned int irq_status; ++ ++ /* Read interrupt status */ ++ irq_status = readl(cqspi->iobase + CQSPI_REG_IRQSTATUS); ++ ++ /* Clear interrupt */ ++ writel(irq_status, cqspi->iobase + CQSPI_REG_IRQSTATUS); ++ ++ irq_status &= CQSPI_IRQ_MASK_RD | CQSPI_IRQ_MASK_WR; ++ ++ if (irq_status) ++ complete(&cqspi->transfer_complete); ++ ++ return IRQ_HANDLED; ++} ++ ++static unsigned int cqspi_calc_rdreg(struct spi_nor *nor, const u8 opcode) ++{ ++ unsigned int rdreg = 0; ++ struct cqspi_flash_pdata *f_pdata = nor->priv; ++ ++ rdreg |= f_pdata->inst_width << CQSPI_REG_RD_INSTR_TYPE_INSTR_LSB; ++ rdreg |= f_pdata->addr_width << CQSPI_REG_RD_INSTR_TYPE_ADDR_LSB; ++ ++ if (nor->flash_read == SPI_NOR_QUAD) ++ rdreg |= CQSPI_INST_TYPE_QUAD ++ << CQSPI_REG_RD_INSTR_TYPE_DATA_LSB; ++ return rdreg; ++} ++ ++static int cqspi_wait_idle(struct cqspi_st *cqspi) ++{ ++ const unsigned int poll_idle_retry = 3; ++ unsigned int count = 0; ++ unsigned long timeout; ++ ++ timeout = jiffies + msecs_to_jiffies(CQSPI_TIMEOUT_MS); ++ while (1) { ++ /* ++ * Read few times in succession to ensure the controller ++ * is indeed idle, that is, the bit does not transition ++ * low again. ++ */ ++ if (cqspi_is_idle(cqspi)) ++ count++; ++ else ++ count = 0; ++ ++ if (count >= poll_idle_retry) ++ return 0; ++ ++ if (time_after(jiffies, timeout)) { ++ /* Timeout, in busy mode. */ ++ dev_err(&cqspi->pdev->dev, ++ "QSPI is still busy after %dms timeout.\n", ++ CQSPI_TIMEOUT_MS); ++ return -ETIMEDOUT; ++ } ++ ++ cpu_relax(); ++ } ++} ++ ++static int cqspi_exec_flash_cmd(struct cqspi_st *cqspi, unsigned int reg) ++{ ++ void __iomem *reg_base = cqspi->iobase; ++ int ret; ++ ++ /* Write the CMDCTRL without start execution. */ ++ writel(reg, reg_base + CQSPI_REG_CMDCTRL); ++ /* Start execute */ ++ reg |= CQSPI_REG_CMDCTRL_EXECUTE_MASK; ++ writel(reg, reg_base + CQSPI_REG_CMDCTRL); ++ ++ /* Polling for completion. */ ++ ret = cqspi_wait_for_bit(reg_base + CQSPI_REG_CMDCTRL, ++ CQSPI_REG_CMDCTRL_INPROGRESS_MASK, 1); ++ if (ret) { ++ dev_err(&cqspi->pdev->dev, ++ "Flash command execution timed out.\n"); ++ return ret; ++ } ++ ++ /* Polling QSPI idle status. */ ++ return cqspi_wait_idle(cqspi); ++} ++ ++static int cqspi_command_read(struct spi_nor *nor, ++ const u8 *txbuf, const unsigned n_tx, ++ u8 *rxbuf, const unsigned n_rx) ++{ ++ struct cqspi_flash_pdata *f_pdata = nor->priv; ++ struct cqspi_st *cqspi = f_pdata->cqspi; ++ void __iomem *reg_base = cqspi->iobase; ++ unsigned int rdreg; ++ unsigned int reg; ++ unsigned int read_len; ++ int status; ++ ++ if (!n_rx || n_rx > CQSPI_STIG_DATA_LEN_MAX || !rxbuf) { ++ dev_err(nor->dev, "Invalid input argument, len %d rxbuf 0x%p\n", ++ n_rx, rxbuf); ++ return -EINVAL; ++ } ++ ++ reg = txbuf[0] << CQSPI_REG_CMDCTRL_OPCODE_LSB; ++ ++ rdreg = cqspi_calc_rdreg(nor, txbuf[0]); ++ writel(rdreg, reg_base + CQSPI_REG_RD_INSTR); ++ ++ reg |= (0x1 << CQSPI_REG_CMDCTRL_RD_EN_LSB); ++ ++ /* 0 means 1 byte. */ ++ reg |= (((n_rx - 1) & CQSPI_REG_CMDCTRL_RD_BYTES_MASK) ++ << CQSPI_REG_CMDCTRL_RD_BYTES_LSB); ++ status = cqspi_exec_flash_cmd(cqspi, reg); ++ if (status) ++ return status; ++ ++ reg = readl(reg_base + CQSPI_REG_CMDREADDATALOWER); ++ ++ /* Put the read value into rx_buf */ ++ read_len = (n_rx > 4) ? 4 : n_rx; ++ memcpy(rxbuf, ®, read_len); ++ rxbuf += read_len; ++ ++ if (n_rx > 4) { ++ reg = readl(reg_base + CQSPI_REG_CMDREADDATAUPPER); ++ ++ read_len = n_rx - read_len; ++ memcpy(rxbuf, ®, read_len); ++ } ++ ++ return 0; ++} ++ ++static int cqspi_command_write(struct spi_nor *nor, const u8 opcode, ++ const u8 *txbuf, const unsigned n_tx) ++{ ++ struct cqspi_flash_pdata *f_pdata = nor->priv; ++ struct cqspi_st *cqspi = f_pdata->cqspi; ++ void __iomem *reg_base = cqspi->iobase; ++ unsigned int reg; ++ unsigned int data; ++ int ret; ++ ++ if (n_tx > 4 || (n_tx && !txbuf)) { ++ dev_err(nor->dev, ++ "Invalid input argument, cmdlen %d txbuf 0x%p\n", ++ n_tx, txbuf); ++ return -EINVAL; ++ } ++ ++ reg = opcode << CQSPI_REG_CMDCTRL_OPCODE_LSB; ++ if (n_tx) { ++ reg |= (0x1 << CQSPI_REG_CMDCTRL_WR_EN_LSB); ++ reg |= ((n_tx - 1) & CQSPI_REG_CMDCTRL_WR_BYTES_MASK) ++ << CQSPI_REG_CMDCTRL_WR_BYTES_LSB; ++ data = 0; ++ memcpy(&data, txbuf, n_tx); ++ writel(data, reg_base + CQSPI_REG_CMDWRITEDATALOWER); ++ } ++ ++ ret = cqspi_exec_flash_cmd(cqspi, reg); ++ return ret; ++} ++ ++static int cqspi_command_write_addr(struct spi_nor *nor, ++ const u8 opcode, const unsigned int addr) ++{ ++ struct cqspi_flash_pdata *f_pdata = nor->priv; ++ struct cqspi_st *cqspi = f_pdata->cqspi; ++ void __iomem *reg_base = cqspi->iobase; ++ unsigned int reg; ++ ++ reg = opcode << CQSPI_REG_CMDCTRL_OPCODE_LSB; ++ reg |= (0x1 << CQSPI_REG_CMDCTRL_ADDR_EN_LSB); ++ reg |= ((nor->addr_width - 1) & CQSPI_REG_CMDCTRL_ADD_BYTES_MASK) ++ << CQSPI_REG_CMDCTRL_ADD_BYTES_LSB; ++ ++ writel(addr, reg_base + CQSPI_REG_CMDADDRESS); ++ ++ return cqspi_exec_flash_cmd(cqspi, reg); ++} ++ ++static int cqspi_indirect_read_setup(struct spi_nor *nor, ++ const unsigned int from_addr) ++{ ++ struct cqspi_flash_pdata *f_pdata = nor->priv; ++ struct cqspi_st *cqspi = f_pdata->cqspi; ++ void __iomem *reg_base = cqspi->iobase; ++ unsigned int dummy_clk = 0; ++ unsigned int reg; ++ ++ writel(from_addr, reg_base + CQSPI_REG_INDIRECTRDSTARTADDR); ++ ++ reg = nor->read_opcode << CQSPI_REG_RD_INSTR_OPCODE_LSB; ++ reg |= cqspi_calc_rdreg(nor, nor->read_opcode); ++ ++ /* Setup dummy clock cycles */ ++ dummy_clk = nor->read_dummy; ++ if (dummy_clk > CQSPI_DUMMY_CLKS_MAX) ++ dummy_clk = CQSPI_DUMMY_CLKS_MAX; ++ ++ if (dummy_clk / 8) { ++ reg |= (1 << CQSPI_REG_RD_INSTR_MODE_EN_LSB); ++ /* Set mode bits high to ensure chip doesn't enter XIP */ ++ writel(0xFF, reg_base + CQSPI_REG_MODE_BIT); ++ ++ /* Need to subtract the mode byte (8 clocks). */ ++ if (f_pdata->inst_width != CQSPI_INST_TYPE_QUAD) ++ dummy_clk -= 8; ++ ++ if (dummy_clk) ++ reg |= (dummy_clk & CQSPI_REG_RD_INSTR_DUMMY_MASK) ++ << CQSPI_REG_RD_INSTR_DUMMY_LSB; ++ } ++ ++ writel(reg, reg_base + CQSPI_REG_RD_INSTR); ++ ++ /* Set address width */ ++ reg = readl(reg_base + CQSPI_REG_SIZE); ++ reg &= ~CQSPI_REG_SIZE_ADDRESS_MASK; ++ reg |= (nor->addr_width - 1); ++ writel(reg, reg_base + CQSPI_REG_SIZE); ++ return 0; ++} ++ ++static int cqspi_indirect_read_execute(struct spi_nor *nor, ++ u8 *rxbuf, const unsigned n_rx) ++{ ++ struct cqspi_flash_pdata *f_pdata = nor->priv; ++ struct cqspi_st *cqspi = f_pdata->cqspi; ++ void __iomem *reg_base = cqspi->iobase; ++ void __iomem *ahb_base = cqspi->ahb_base; ++ unsigned int remaining = n_rx; ++ unsigned int bytes_to_read = 0; ++ int ret = 0; ++ ++ writel(remaining, reg_base + CQSPI_REG_INDIRECTRDBYTES); ++ ++ /* Clear all interrupts. */ ++ writel(CQSPI_IRQ_STATUS_MASK, reg_base + CQSPI_REG_IRQSTATUS); ++ ++ writel(CQSPI_IRQ_MASK_RD, reg_base + CQSPI_REG_IRQMASK); ++ ++ reinit_completion(&cqspi->transfer_complete); ++ writel(CQSPI_REG_INDIRECTRD_START_MASK, ++ reg_base + CQSPI_REG_INDIRECTRD); ++ ++ while (remaining > 0) { ++ ret = wait_for_completion_timeout(&cqspi->transfer_complete, ++ msecs_to_jiffies ++ (CQSPI_READ_TIMEOUT_MS)); ++ ++ bytes_to_read = cqspi_get_rd_sram_level(cqspi); ++ ++ if (!ret && bytes_to_read == 0) { ++ dev_err(nor->dev, "Indirect read timeout, no bytes\n"); ++ ret = -ETIMEDOUT; ++ goto failrd; ++ } ++ ++ while (bytes_to_read != 0) { ++ bytes_to_read *= cqspi->fifo_width; ++ bytes_to_read = bytes_to_read > remaining ? ++ remaining : bytes_to_read; ++ readsl(ahb_base, rxbuf, DIV_ROUND_UP(bytes_to_read, 4)); ++ rxbuf += bytes_to_read; ++ remaining -= bytes_to_read; ++ bytes_to_read = cqspi_get_rd_sram_level(cqspi); ++ } ++ ++ if (remaining > 0) ++ reinit_completion(&cqspi->transfer_complete); ++ } ++ ++ /* Check indirect done status */ ++ ret = cqspi_wait_for_bit(reg_base + CQSPI_REG_INDIRECTRD, ++ CQSPI_REG_INDIRECTRD_DONE_MASK, 0); ++ if (ret) { ++ dev_err(nor->dev, ++ "Indirect read completion error (%i)\n", ret); ++ goto failrd; ++ } ++ ++ /* Disable interrupt */ ++ writel(0, reg_base + CQSPI_REG_IRQMASK); ++ ++ /* Clear indirect completion status */ ++ writel(CQSPI_REG_INDIRECTRD_DONE_MASK, reg_base + CQSPI_REG_INDIRECTRD); ++ ++ return 0; ++ ++failrd: ++ /* Disable interrupt */ ++ writel(0, reg_base + CQSPI_REG_IRQMASK); ++ ++ /* Cancel the indirect read */ ++ writel(CQSPI_REG_INDIRECTWR_CANCEL_MASK, ++ reg_base + CQSPI_REG_INDIRECTRD); ++ return ret; ++} ++ ++static int cqspi_indirect_write_setup(struct spi_nor *nor, ++ const unsigned int to_addr) ++{ ++ unsigned int reg; ++ struct cqspi_flash_pdata *f_pdata = nor->priv; ++ struct cqspi_st *cqspi = f_pdata->cqspi; ++ void __iomem *reg_base = cqspi->iobase; ++ ++ /* Set opcode. */ ++ reg = nor->program_opcode << CQSPI_REG_WR_INSTR_OPCODE_LSB; ++ writel(reg, reg_base + CQSPI_REG_WR_INSTR); ++ reg = cqspi_calc_rdreg(nor, nor->program_opcode); ++ writel(reg, reg_base + CQSPI_REG_RD_INSTR); ++ ++ writel(to_addr, reg_base + CQSPI_REG_INDIRECTWRSTARTADDR); ++ ++ reg = readl(reg_base + CQSPI_REG_SIZE); ++ reg &= ~CQSPI_REG_SIZE_ADDRESS_MASK; ++ reg |= (nor->addr_width - 1); ++ writel(reg, reg_base + CQSPI_REG_SIZE); ++ return 0; ++} ++ ++static int cqspi_indirect_write_execute(struct spi_nor *nor, ++ const u8 *txbuf, const unsigned n_tx) ++{ ++ const unsigned int page_size = nor->page_size; ++ struct cqspi_flash_pdata *f_pdata = nor->priv; ++ struct cqspi_st *cqspi = f_pdata->cqspi; ++ void __iomem *reg_base = cqspi->iobase; ++ unsigned int remaining = n_tx; ++ unsigned int write_bytes; ++ int ret; ++ ++ writel(remaining, reg_base + CQSPI_REG_INDIRECTWRBYTES); ++ ++ /* Clear all interrupts. */ ++ writel(CQSPI_IRQ_STATUS_MASK, reg_base + CQSPI_REG_IRQSTATUS); ++ ++ writel(CQSPI_IRQ_MASK_WR, reg_base + CQSPI_REG_IRQMASK); ++ ++ reinit_completion(&cqspi->transfer_complete); ++ writel(CQSPI_REG_INDIRECTWR_START_MASK, ++ reg_base + CQSPI_REG_INDIRECTWR); ++ ++ while (remaining > 0) { ++ write_bytes = remaining > page_size ? page_size : remaining; ++ writesl(cqspi->ahb_base, txbuf, DIV_ROUND_UP(write_bytes, 4)); ++ ++ ret = wait_for_completion_timeout(&cqspi->transfer_complete, ++ msecs_to_jiffies ++ (CQSPI_TIMEOUT_MS)); ++ if (!ret) { ++ dev_err(nor->dev, "Indirect write timeout\n"); ++ ret = -ETIMEDOUT; ++ goto failwr; ++ } ++ ++ txbuf += write_bytes; ++ remaining -= write_bytes; ++ ++ if (remaining > 0) ++ reinit_completion(&cqspi->transfer_complete); ++ } ++ ++ /* Check indirect done status */ ++ ret = cqspi_wait_for_bit(reg_base + CQSPI_REG_INDIRECTWR, ++ CQSPI_REG_INDIRECTWR_DONE_MASK, 0); ++ if (ret) { ++ dev_err(nor->dev, ++ "Indirect write completion error (%i)\n", ret); ++ goto failwr; ++ } ++ ++ /* Disable interrupt. */ ++ writel(0, reg_base + CQSPI_REG_IRQMASK); ++ ++ /* Clear indirect completion status */ ++ writel(CQSPI_REG_INDIRECTWR_DONE_MASK, reg_base + CQSPI_REG_INDIRECTWR); ++ ++ cqspi_wait_idle(cqspi); ++ ++ return 0; ++ ++failwr: ++ /* Disable interrupt. */ ++ writel(0, reg_base + CQSPI_REG_IRQMASK); ++ ++ /* Cancel the indirect write */ ++ writel(CQSPI_REG_INDIRECTWR_CANCEL_MASK, ++ reg_base + CQSPI_REG_INDIRECTWR); ++ return ret; ++} ++ ++static int cqspi_set_protocol(struct spi_nor *nor, enum spi_nor_protocol proto) ++{ ++ struct cqspi_flash_pdata *f_pdata = nor->priv; ++ ++ switch (proto) { ++ case SNOR_PROTO_1_1_1: ++ case SNOR_PROTO_1_1_2: ++ case SNOR_PROTO_1_1_4: ++ case SNOR_PROTO_1_2_2: ++ case SNOR_PROTO_1_4_4: ++ f_pdata->inst_width = CQSPI_INST_TYPE_SINGLE; ++ break; ++ case SNOR_PROTO_2_2_2: ++ f_pdata->inst_width = CQSPI_INST_TYPE_DUAL; ++ break; ++ case SNOR_PROTO_4_4_4: ++ f_pdata->inst_width = CQSPI_INST_TYPE_QUAD; ++ break; ++ default: ++ return -EINVAL; ++ } ++ ++ switch (proto) { ++ case SNOR_PROTO_1_1_1: ++ case SNOR_PROTO_1_1_2: ++ case SNOR_PROTO_1_1_4: ++ f_pdata->addr_width = CQSPI_INST_TYPE_SINGLE; ++ break; ++ case SNOR_PROTO_1_2_2: ++ case SNOR_PROTO_2_2_2: ++ f_pdata->addr_width = CQSPI_INST_TYPE_DUAL; ++ break; ++ case SNOR_PROTO_1_4_4: ++ case SNOR_PROTO_4_4_4: ++ f_pdata->addr_width = CQSPI_INST_TYPE_QUAD; ++ break; ++ default: ++ return -EINVAL; ++ } ++ ++ return 0; ++} ++ ++static void cqspi_write(struct spi_nor *nor, loff_t to, ++ size_t len, size_t *retlen, const u_char *buf) ++{ ++ int ret; ++ ++ ret = cqspi_set_protocol(nor, nor->write_proto); ++ if (ret) ++ return; ++ ++ ret = cqspi_indirect_write_setup(nor, to); ++ if (ret) ++ return; ++ ++ ret = cqspi_indirect_write_execute(nor, buf, len); ++ if (ret) ++ return; ++ ++ *retlen += len; ++} ++ ++static int cqspi_read(struct spi_nor *nor, loff_t from, ++ size_t len, size_t *retlen, u_char *buf) ++{ ++ int ret; ++ ++ ret = cqspi_set_protocol(nor, nor->read_proto); ++ if (ret) ++ return ret; ++ ++ ret = cqspi_indirect_read_setup(nor, from); ++ if (ret) ++ return ret; ++ ++ ret = cqspi_indirect_read_execute(nor, buf, len); ++ if (ret) ++ return ret; ++ ++ *retlen += len; ++ return ret; ++} ++ ++static int cqspi_erase(struct spi_nor *nor, loff_t offs) ++{ ++ int ret; ++ ++ ret = cqspi_set_protocol(nor, nor->erase_proto); ++ if (ret) ++ return ret; ++ ++ /* Send write enable, then erase commands. */ ++ ret = nor->write_reg(nor, SPINOR_OP_WREN, NULL, 0); ++ if (ret) ++ return ret; ++ ++ /* Set up command buffer. */ ++ ret = cqspi_command_write_addr(nor, nor->erase_opcode, offs); ++ if (ret) ++ return ret; ++ ++ return 0; ++} ++ ++static unsigned int calculate_ticks_for_ns(const unsigned int ref_clk_hz, ++ const unsigned int ns_val) ++{ ++ unsigned int ticks; ++ ++ ticks = ref_clk_hz / 1000; /* kHz */ ++ ticks = DIV_ROUND_UP(ticks * ns_val, 1000000); ++ ++ return ticks; ++} ++ ++static void cqspi_delay(struct spi_nor *nor, const unsigned int sclk_hz) ++{ ++ struct cqspi_flash_pdata *f_pdata = nor->priv; ++ struct cqspi_st *cqspi = f_pdata->cqspi; ++ void __iomem *iobase = cqspi->iobase; ++ const unsigned int ref_clk_hz = cqspi->master_ref_clk_hz; ++ unsigned int tshsl, tchsh, tslch, tsd2d; ++ unsigned int reg; ++ unsigned int tsclk; ++ ++ /* calculate the number of ref ticks for one sclk tick */ ++ tsclk = (ref_clk_hz + sclk_hz - 1) / sclk_hz; ++ ++ tshsl = calculate_ticks_for_ns(ref_clk_hz, f_pdata->tshsl_ns); ++ /* this particular value must be at least one sclk */ ++ if (tshsl < tsclk) ++ tshsl = tsclk; ++ ++ tchsh = calculate_ticks_for_ns(ref_clk_hz, f_pdata->tchsh_ns); ++ tslch = calculate_ticks_for_ns(ref_clk_hz, f_pdata->tslch_ns); ++ tsd2d = calculate_ticks_for_ns(ref_clk_hz, f_pdata->tsd2d_ns); ++ ++ reg = (tshsl & CQSPI_REG_DELAY_TSHSL_MASK) ++ << CQSPI_REG_DELAY_TSHSL_LSB; ++ reg |= (tchsh & CQSPI_REG_DELAY_TCHSH_MASK) ++ << CQSPI_REG_DELAY_TCHSH_LSB; ++ reg |= (tslch & CQSPI_REG_DELAY_TSLCH_MASK) ++ << CQSPI_REG_DELAY_TSLCH_LSB; ++ reg |= (tsd2d & CQSPI_REG_DELAY_TSD2D_MASK) ++ << CQSPI_REG_DELAY_TSD2D_LSB; ++ writel(reg, iobase + CQSPI_REG_DELAY); ++} ++ ++static void cqspi_config_baudrate_div(struct cqspi_st *cqspi, ++ const unsigned int sclk_hz) ++{ ++ const unsigned int ref_clk_hz = cqspi->master_ref_clk_hz; ++ void __iomem *reg_base = cqspi->iobase; ++ unsigned int reg; ++ unsigned int div; ++ ++ reg = readl(reg_base + CQSPI_REG_CONFIG); ++ reg &= ~(CQSPI_REG_CONFIG_BAUD_MASK << CQSPI_REG_CONFIG_BAUD_LSB); ++ ++ div = ref_clk_hz / sclk_hz; ++ ++ /* Recalculate the baudrate divisor based on QSPI specification. */ ++ if (div > 32) ++ div = 32; ++ ++ /* Check if even number. */ ++ if (div & 1) ++ div = (div / 2); ++ else ++ div = (div / 2) - 1; ++ ++ div = (div & CQSPI_REG_CONFIG_BAUD_MASK) << CQSPI_REG_CONFIG_BAUD_LSB; ++ reg |= div; ++ writel(reg, reg_base + CQSPI_REG_CONFIG); ++} ++ ++static void cqspi_readdata_capture(struct cqspi_st *cqspi, ++ const unsigned int bypass, ++ const unsigned int delay) ++{ ++ void __iomem *reg_base = cqspi->iobase; ++ unsigned int reg; ++ ++ reg = readl(reg_base + CQSPI_REG_READCAPTURE); ++ ++ if (bypass) ++ reg |= (1 << CQSPI_REG_READCAPTURE_BYPASS_LSB); ++ else ++ reg &= ~(1 << CQSPI_REG_READCAPTURE_BYPASS_LSB); ++ ++ reg &= ~(CQSPI_REG_READCAPTURE_DELAY_MASK ++ << CQSPI_REG_READCAPTURE_DELAY_LSB); ++ ++ reg |= (delay & CQSPI_REG_READCAPTURE_DELAY_MASK) ++ << CQSPI_REG_READCAPTURE_DELAY_LSB; ++ ++ writel(reg, reg_base + CQSPI_REG_READCAPTURE); ++} ++ ++static void cqspi_chipselect(struct spi_nor *nor) ++{ ++ struct cqspi_flash_pdata *f_pdata = nor->priv; ++ struct cqspi_st *cqspi = f_pdata->cqspi; ++ void __iomem *reg_base = cqspi->iobase; ++ unsigned int chip_select = f_pdata->cs; ++ unsigned int reg; ++ ++ reg = readl(reg_base + CQSPI_REG_CONFIG); ++ if (cqspi->is_decoded_cs) { ++ reg |= CQSPI_REG_CONFIG_DECODE_MASK; ++ } else { ++ reg &= ~CQSPI_REG_CONFIG_DECODE_MASK; ++ ++ /* Convert CS if without decoder. ++ * CS0 to 4b'1110 ++ * CS1 to 4b'1101 ++ * CS2 to 4b'1011 ++ * CS3 to 4b'0111 ++ */ ++ chip_select = 0xF & ~(1 << chip_select); ++ } ++ ++ reg &= ~(CQSPI_REG_CONFIG_CHIPSELECT_MASK ++ << CQSPI_REG_CONFIG_CHIPSELECT_LSB); ++ reg |= (chip_select & CQSPI_REG_CONFIG_CHIPSELECT_MASK) ++ << CQSPI_REG_CONFIG_CHIPSELECT_LSB; ++ writel(reg, reg_base + CQSPI_REG_CONFIG); ++} ++ ++static void cqspi_controller_enable(struct cqspi_st *cqspi, bool enable) ++{ ++ void __iomem *reg_base = cqspi->iobase; ++ unsigned int reg; ++ ++ reg = readl(reg_base + CQSPI_REG_CONFIG); ++ ++ if (enable) ++ reg |= CQSPI_REG_CONFIG_ENABLE_MASK; ++ else ++ reg &= ~CQSPI_REG_CONFIG_ENABLE_MASK; ++ ++ writel(reg, reg_base + CQSPI_REG_CONFIG); ++} ++ ++static void cqspi_switch_cs(struct spi_nor *nor) ++{ ++ struct cqspi_flash_pdata *f_pdata = nor->priv; ++ struct cqspi_st *cqspi = f_pdata->cqspi; ++ void __iomem *iobase = cqspi->iobase; ++ unsigned int reg; ++ ++ /* configure page size and block size. */ ++ reg = readl(iobase + CQSPI_REG_SIZE); ++ reg &= ~(CQSPI_REG_SIZE_PAGE_MASK << CQSPI_REG_SIZE_PAGE_LSB); ++ reg &= ~(CQSPI_REG_SIZE_BLOCK_MASK << CQSPI_REG_SIZE_BLOCK_LSB); ++ reg &= ~CQSPI_REG_SIZE_ADDRESS_MASK; ++ reg |= (nor->page_size << CQSPI_REG_SIZE_PAGE_LSB); ++ reg |= (ilog2(nor->mtd.erasesize) << CQSPI_REG_SIZE_BLOCK_LSB); ++ reg |= (nor->addr_width - 1); ++ writel(reg, iobase + CQSPI_REG_SIZE); ++ ++ /* configure the chip select */ ++ cqspi_chipselect(nor); ++} ++ ++static int cqspi_prep_unlocked(struct spi_nor *nor, enum spi_nor_ops ops) ++{ ++ struct cqspi_flash_pdata *f_pdata = nor->priv; ++ struct cqspi_st *cqspi = f_pdata->cqspi; ++ const unsigned int sclk = f_pdata->clk_rate; ++ const int switch_cs = (cqspi->current_cs != f_pdata->cs); ++ const int switch_ck = (cqspi->sclk != sclk); ++ ++ if (switch_cs || switch_ck) ++ cqspi_controller_enable(cqspi, 0); ++ ++ /* Switch chip select. */ ++ if (switch_cs) { ++ cqspi->current_cs = f_pdata->cs; ++ cqspi_switch_cs(nor); ++ } ++ ++ /* Setup baudrate divisor and delays */ ++ if (switch_ck) { ++ cqspi->sclk = sclk; ++ cqspi_config_baudrate_div(cqspi, sclk); ++ cqspi_delay(nor, sclk); ++ cqspi_readdata_capture(cqspi, 1, f_pdata->read_delay); ++ } ++ ++ if (switch_cs || switch_ck) ++ cqspi_controller_enable(cqspi, 1); ++ ++ return 0; ++} ++ ++static int cqspi_prep(struct spi_nor *nor, enum spi_nor_ops ops) ++{ ++ struct cqspi_flash_pdata *f_pdata = nor->priv; ++ struct cqspi_st *cqspi = f_pdata->cqspi; ++ ++ mutex_lock(&cqspi->bus_mutex); ++ ++ return cqspi_prep_unlocked(nor, ops); ++} ++ ++static void cqspi_unprep(struct spi_nor *nor, enum spi_nor_ops ops) ++{ ++ struct cqspi_flash_pdata *f_pdata = nor->priv; ++ struct cqspi_st *cqspi = f_pdata->cqspi; ++ ++ mutex_unlock(&cqspi->bus_mutex); ++} ++ ++static int cqspi_read_reg(struct spi_nor *nor, u8 opcode, u8 *buf, int len) ++{ ++ int ret; ++ ++ ret = cqspi_set_protocol(nor, nor->reg_proto); ++ if (ret) ++ goto exit; ++ ++ cqspi_prep_unlocked(nor, SPI_NOR_OPS_READ); ++ ++ ret = cqspi_command_read(nor, &opcode, 1, buf, len); ++exit: ++ return ret; ++} ++ ++static int cqspi_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf, int len) ++{ ++ int ret; ++ ++ ret = cqspi_set_protocol(nor, nor->reg_proto); ++ if (ret) ++ goto exit; ++ ++ cqspi_prep_unlocked(nor, SPI_NOR_OPS_WRITE); ++ ++ ret = cqspi_command_write(nor, opcode, buf, len); ++exit: ++ return ret; ++} ++ ++static int cqspi_of_get_flash_pdata(struct platform_device *pdev, ++ struct cqspi_flash_pdata *f_pdata, ++ struct device_node *np) ++{ ++ if (of_property_read_u32(np, "cdns,read-delay", &f_pdata->read_delay)) { ++ dev_err(&pdev->dev, "couldn't determine read-delay\n"); ++ return -ENXIO; ++ } ++ ++ if (of_property_read_u32(np, "cdns,tshsl-ns", &f_pdata->tshsl_ns)) { ++ dev_err(&pdev->dev, "couldn't determine tshsl-ns\n"); ++ return -ENXIO; ++ } ++ ++ if (of_property_read_u32(np, "cdns,tsd2d-ns", &f_pdata->tsd2d_ns)) { ++ dev_err(&pdev->dev, "couldn't determine tsd2d-ns\n"); ++ return -ENXIO; ++ } ++ ++ if (of_property_read_u32(np, "cdns,tchsh-ns", &f_pdata->tchsh_ns)) { ++ dev_err(&pdev->dev, "couldn't determine tchsh-ns\n"); ++ return -ENXIO; ++ } ++ ++ if (of_property_read_u32(np, "cdns,tslch-ns", &f_pdata->tslch_ns)) { ++ dev_err(&pdev->dev, "couldn't determine tslch-ns\n"); ++ return -ENXIO; ++ } ++ ++ if (of_property_read_u32(np, "spi-max-frequency", &f_pdata->clk_rate)) { ++ dev_err(&pdev->dev, "couldn't determine spi-max-frequency\n"); ++ return -ENXIO; ++ } ++ ++ return 0; ++} ++ ++static int cqspi_of_get_pdata(struct platform_device *pdev) ++{ ++ struct device_node *np = pdev->dev.of_node; ++ struct cqspi_st *cqspi = platform_get_drvdata(pdev); ++ ++ cqspi->is_decoded_cs = of_property_read_bool(np, "cdns,is-decoded-cs"); ++ ++ if (of_property_read_u32(np, "cdns,fifo-depth", &cqspi->fifo_depth)) { ++ dev_err(&pdev->dev, "couldn't determine fifo-depth\n"); ++ return -ENXIO; ++ } ++ ++ if (of_property_read_u32(np, "cdns,fifo-width", &cqspi->fifo_width)) { ++ dev_err(&pdev->dev, "couldn't determine fifo-width\n"); ++ return -ENXIO; ++ } ++ ++ if (of_property_read_u32(np, "cdns,trigger-address", ++ &cqspi->trigger_address)) { ++ dev_err(&pdev->dev, "couldn't determine trigger-address\n"); ++ return -ENXIO; ++ } ++ ++ return 0; ++} ++ ++static void cqspi_controller_init(struct cqspi_st *cqspi) ++{ ++ cqspi_controller_enable(cqspi, 0); ++ ++ /* Configure the remap address register, no remap */ ++ writel(0, cqspi->iobase + CQSPI_REG_REMAP); ++ ++ /* Disable all interrupts. */ ++ writel(0, cqspi->iobase + CQSPI_REG_IRQMASK); ++ ++ /* Configure the SRAM split to 1:1 . */ ++ writel(cqspi->fifo_depth / 2, cqspi->iobase + CQSPI_REG_SRAMPARTITION); ++ ++ /* Load indirect trigger address. */ ++ writel(cqspi->trigger_address, ++ cqspi->iobase + CQSPI_REG_INDIRECTTRIGGER); ++ ++ /* Program read watermark -- 1/2 of the FIFO. */ ++ writel(cqspi->fifo_depth * cqspi->fifo_width / 2, ++ cqspi->iobase + CQSPI_REG_INDIRECTRDWATERMARK); ++ /* Program write watermark -- 1/8 of the FIFO. */ ++ writel(cqspi->fifo_depth * cqspi->fifo_width / 8, ++ cqspi->iobase + CQSPI_REG_INDIRECTWRWATERMARK); ++ ++ cqspi_controller_enable(cqspi, 1); ++} ++ ++static int cqspi_setup_flash(struct cqspi_st *cqspi, struct device_node *np) ++{ ++ struct platform_device *pdev = cqspi->pdev; ++ struct device *dev = &pdev->dev; ++ struct cqspi_flash_pdata *f_pdata; ++ struct spi_nor *nor; ++ struct mtd_info *mtd; ++ unsigned int cs; ++ int i, ret; ++ ++ /* Get flash device data */ ++ for_each_available_child_of_node(dev->of_node, np) { ++ if (of_property_read_u32(np, "reg", &cs)) { ++ dev_err(dev, "Couldn't determine chip select.\n"); ++ goto err; ++ } ++ ++ if (cs > CQSPI_MAX_CHIPSELECT) { ++ dev_err(dev, "Chip select %d out of range.\n", cs); ++ goto err; ++ } ++ ++ f_pdata = &cqspi->f_pdata[cs]; ++ f_pdata->cqspi = cqspi; ++ f_pdata->cs = cs; ++ ++ ret = cqspi_of_get_flash_pdata(pdev, f_pdata, np); ++ if (ret) ++ goto err; ++ ++ nor = &f_pdata->nor; ++ mtd = &nor->mtd; ++ ++ mtd->priv = nor; ++ ++ nor->dev = dev; ++ spi_nor_set_flash_node(nor, np); ++ nor->priv = f_pdata; ++ ++ nor->read_reg = cqspi_read_reg; ++ nor->write_reg = cqspi_write_reg; ++ nor->read = cqspi_read; ++ nor->write = cqspi_write; ++ nor->erase = cqspi_erase; ++ nor->prepare = cqspi_prep; ++ nor->unprepare = cqspi_unprep; ++ ++ mtd->name = kasprintf(GFP_KERNEL, "%s.%d", dev_name(dev), cs); ++ if (!mtd->name) { ++ ret = -ENOMEM; ++ goto err; ++ } ++ ++ ret = spi_nor_scan(nor, NULL, SPI_NOR_QUAD); ++ if (ret) ++ goto err; ++ ++ ret = mtd_device_register(mtd, NULL, 0); ++ if (ret) ++ goto err; ++ } ++ ++ return 0; ++ ++err: ++ for (i = 0; i < CQSPI_MAX_CHIPSELECT; i++) ++ if (cqspi->f_pdata[i].nor.mtd.name) { ++ mtd_device_unregister(&cqspi->f_pdata[i].nor.mtd); ++ kfree(cqspi->f_pdata[i].nor.mtd.name); ++ } ++ return ret; ++} ++ ++static int cqspi_probe(struct platform_device *pdev) ++{ ++ struct device_node *np = pdev->dev.of_node; ++ struct device *dev = &pdev->dev; ++ struct cqspi_st *cqspi; ++ struct resource *res; ++ struct resource *res_ahb; ++ int ret; ++ int irq; ++ ++ cqspi = devm_kzalloc(dev, sizeof(*cqspi), GFP_KERNEL); ++ if (!cqspi) ++ return -ENOMEM; ++ ++ mutex_init(&cqspi->bus_mutex); ++ cqspi->pdev = pdev; ++ platform_set_drvdata(pdev, cqspi); ++ ++ /* Obtain configuration from OF. */ ++ ret = cqspi_of_get_pdata(pdev); ++ if (ret) { ++ dev_err(dev, "Cannot get mandatory OF data.\n"); ++ return -ENODEV; ++ } ++ ++ /* Obtain QSPI clock. */ ++ cqspi->clk = devm_clk_get(dev, NULL); ++ if (IS_ERR(cqspi->clk)) { ++ dev_err(dev, "Cannot claim QSPI clock.\n"); ++ return PTR_ERR(cqspi->clk); ++ } ++ ++ /* Obtain and remap controller address. */ ++ res = platform_get_resource(pdev, IORESOURCE_MEM, 0); ++ cqspi->iobase = devm_ioremap_resource(dev, res); ++ if (IS_ERR(cqspi->iobase)) { ++ dev_err(dev, "Cannot remap controller address.\n"); ++ return PTR_ERR(cqspi->iobase); ++ } ++ ++ /* Obtain and remap AHB address. */ ++ res_ahb = platform_get_resource(pdev, IORESOURCE_MEM, 1); ++ cqspi->ahb_base = devm_ioremap_resource(dev, res_ahb); ++ if (IS_ERR(cqspi->ahb_base)) { ++ dev_err(dev, "Cannot remap AHB address.\n"); ++ return PTR_ERR(cqspi->ahb_base); ++ } ++ ++ init_completion(&cqspi->transfer_complete); ++ ++ /* Obtain IRQ line. */ ++ irq = platform_get_irq(pdev, 0); ++ if (irq < 0) { ++ dev_err(dev, "Cannot obtain IRQ.\n"); ++ return -ENXIO; ++ } ++ ++ ret = clk_prepare_enable(cqspi->clk); ++ if (ret) { ++ dev_err(dev, "Cannot enable QSPI clock.\n"); ++ return ret; ++ } ++ ++ cqspi->master_ref_clk_hz = clk_get_rate(cqspi->clk); ++ ++ ret = devm_request_irq(dev, irq, cqspi_irq_handler, 0, ++ pdev->name, cqspi); ++ if (ret) { ++ dev_err(dev, "Cannot request IRQ.\n"); ++ goto probe_irq_failed; ++ } ++ ++ cqspi_wait_idle(cqspi); ++ cqspi_controller_init(cqspi); ++ cqspi->current_cs = -1; ++ cqspi->sclk = 0; ++ ++ ret = cqspi_setup_flash(cqspi, np); ++ if (ret) { ++ dev_err(dev, "Cadence QSPI NOR probe failed %d\n", ret); ++ goto probe_setup_failed; ++ } ++ ++ return ret; ++probe_irq_failed: ++ cqspi_controller_enable(cqspi, 0); ++probe_setup_failed: ++ clk_disable_unprepare(cqspi->clk); ++ return ret; ++} ++ ++static int cqspi_remove(struct platform_device *pdev) ++{ ++ struct cqspi_st *cqspi = platform_get_drvdata(pdev); ++ int i; ++ ++ cqspi_controller_enable(cqspi, 0); ++ ++ for (i = 0; i < CQSPI_MAX_CHIPSELECT; i++) ++ if (cqspi->f_pdata[i].nor.mtd.name) { ++ mtd_device_unregister(&cqspi->f_pdata[i].nor.mtd); ++ kfree(cqspi->f_pdata[i].nor.mtd.name); ++ } ++ ++ clk_disable_unprepare(cqspi->clk); ++ ++ return 0; ++} ++ ++#ifdef CONFIG_PM_SLEEP ++static int cqspi_suspend(struct device *dev) ++{ ++ struct cqspi_st *cqspi = dev_get_drvdata(dev); ++ ++ cqspi_controller_enable(cqspi, 0); ++ return 0; ++} ++ ++static int cqspi_resume(struct device *dev) ++{ ++ struct cqspi_st *cqspi = dev_get_drvdata(dev); ++ ++ cqspi_controller_enable(cqspi, 1); ++ return 0; ++} ++ ++static const struct dev_pm_ops cqspi__dev_pm_ops = { ++ .suspend = cqspi_suspend, ++ .resume = cqspi_resume, ++}; ++ ++#define CQSPI_DEV_PM_OPS (&cqspi__dev_pm_ops) ++#else ++#define CQSPI_DEV_PM_OPS NULL ++#endif ++ ++static struct of_device_id const cqspi_dt_ids[] = { ++ {.compatible = "cdns,qspi-nor",}, ++ { /* end of table */ } ++}; ++ ++MODULE_DEVICE_TABLE(of, cqspi_dt_ids); ++ ++static struct platform_driver cqspi_platform_driver = { ++ .probe = cqspi_probe, ++ .remove = cqspi_remove, ++ .driver = { ++ .name = CQSPI_NAME, ++ .pm = CQSPI_DEV_PM_OPS, ++ .of_match_table = cqspi_dt_ids, ++ }, ++}; ++ ++module_platform_driver(cqspi_platform_driver); ++ ++MODULE_DESCRIPTION("Cadence QSPI Controller Driver"); ++MODULE_LICENSE("GPL v2"); ++MODULE_ALIAS("platform:" CQSPI_NAME); ++MODULE_AUTHOR("Ley Foon Tan "); ++MODULE_AUTHOR("Graham Moore "); +-- +2.8.1 + diff --git a/target/linux/socfpga/patches-4.4/0032-ARM-socfpga-Add-Candence-QSPI-controller-DT-node.patch b/target/linux/socfpga/patches-4.4/0032-ARM-socfpga-Add-Candence-QSPI-controller-DT-node.patch new file mode 100644 index 0000000..e6b4ec7 --- /dev/null +++ b/target/linux/socfpga/patches-4.4/0032-ARM-socfpga-Add-Candence-QSPI-controller-DT-node.patch @@ -0,0 +1,42 @@ +From 8abee0bfd7bc652e028e51e2b95cbb3bf42fc152 Mon Sep 17 00:00:00 2001 +From: Stefan Roese +Date: Wed, 20 May 2015 10:32:03 +0200 +Subject: [PATCH 32/33] ARM: socfpga: Add Candence QSPI controller DT node + +Now that the device driver is available, lets add the controller node +to the socfpga dtsi. So that the SPI NOR flash can be used. + +Signed-off-by: Stefan Roese +Signed-off-by: Marek Vasut +--- + arch/arm/boot/dts/socfpga.dtsi | 14 ++++++++++++++ + 1 file changed, 14 insertions(+) + +diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi +index 3ed4abd..ebcd081 100644 +--- a/arch/arm/boot/dts/socfpga.dtsi ++++ b/arch/arm/boot/dts/socfpga.dtsi +@@ -685,6 +685,20 @@ + reg = <0xffff0000 0x10000>; + }; + ++ qspi: spi at ff705000 { ++ compatible = "cdns,qspi-nor"; ++ #address-cells = <1>; ++ #size-cells = <0>; ++ reg = <0xff705000 0x1000>, ++ <0xffa00000 0x1000>; ++ interrupts = <0 151 4>; ++ clocks = <&qspi_clk>; ++ cdns,fifo-depth = <128>; ++ cdns,fifo-width = <4>; ++ cdns,trigger-address = <0x00000000>; ++ status = "disabled"; ++ }; ++ + rst: rstmgr at ffd05000 { + #reset-cells = <1>; + compatible = "altr,rst-mgr"; +-- +2.8.1 + diff --git a/target/linux/socfpga/patches-4.4/0033-ARM-socfpga-Enable-QSPI-flash-on-SoCKit.patch b/target/linux/socfpga/patches-4.4/0033-ARM-socfpga-Enable-QSPI-flash-on-SoCKit.patch new file mode 100644 index 0000000..f242d8c --- /dev/null +++ b/target/linux/socfpga/patches-4.4/0033-ARM-socfpga-Enable-QSPI-flash-on-SoCKit.patch @@ -0,0 +1,47 @@ +From 8c1cd66d13406533f9948dbcd25d4b53d389c109 Mon Sep 17 00:00:00 2001 +From: Marek Vasut +Date: Sun, 21 Jun 2015 23:00:06 +0200 +Subject: [PATCH 33/33] ARM: socfpga: Enable QSPI flash on SoCKit + +Add the QSPI NOR node on SoCkit. + +Signed-off-by: Marek Vasut +--- + arch/arm/boot/dts/socfpga_cyclone5_sockit.dts | 21 +++++++++++++++++++++ + 1 file changed, 21 insertions(+) + +diff --git a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts +index 02e22f5..d706348 100644 +--- a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts ++++ b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts +@@ -175,6 +175,27 @@ + status = "okay"; + }; + ++&qspi { ++ status = "okay"; ++ ++ flash0: n25q00 at 0 { ++ #address-cells = <1>; ++ #size-cells = <1>; ++ compatible = "n25q00"; ++ reg = <0>; /* chip select */ ++ spi-max-frequency = <100000000>; ++ m25p,fast-read; ++ ++ cdns,page-size = <256>; ++ cdns,block-size = <16>; ++ cdns,read-delay = <4>; ++ cdns,tshsl-ns = <50>; ++ cdns,tsd2d-ns = <50>; ++ cdns,tchsh-ns = <4>; ++ cdns,tslch-ns = <4>; ++ }; ++}; ++ + &usb1 { + status = "okay"; + }; +-- +2.8.1 + -- 2.7.0 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From nbd at nbd.name Tue May 24 10:57:37 2016 From: nbd at nbd.name (Felix Fietkau) Date: Tue, 24 May 2016 16:57:37 +0200 Subject: [OpenWrt-Devel] [PATCH] bcm53xx: Move SF mmap patch In-Reply-To: <1464101288-7056-1-git-send-email-marex@denx.de> References: <1464101288-7056-1-git-send-email-marex@denx.de> Message-ID: On 2016-05-24 16:48, Marek Vasut wrote: > The patch adding SPI flash mmap read capability does not compile due to missing > m25p80_rx_nbits() function. Move it to bcm53xx patch directory, where the patch > adding this m25p80_rx_nbits() function resides. This doesn't make any sense to me. The function is already in the driver in 4.4, it is not added by any patch... - Felix _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From alin.nastac at gmail.com Tue May 24 11:02:20 2016 From: alin.nastac at gmail.com (Alin Nastac) Date: Tue, 24 May 2016 17:02:20 +0200 Subject: [OpenWrt-Devel] [PATCH] netifd: Add option to configure gc_stale_time for each device Message-ID: <1464102140-1439-1-git-send-email-alin.nastac@gmail.com> The UCI parameter neighgcstaletime allows to control how much time will STALE entries be kept in the neighbour table for both IPv4 and IPv6. Signed-off-by: Alin Nastac --- device.c | 14 ++++++++++++++ device.h | 4 ++++ system-linux.c | 38 ++++++++++++++++++++++++++++++++++++++ 3 files changed, 56 insertions(+) diff --git a/device.c b/device.c index 7004bfd..3e182f3 100644 --- a/device.c +++ b/device.c @@ -45,6 +45,7 @@ static const struct blobmsg_policy dev_attrs[__DEV_ATTR_MAX] = { [DEV_ATTR_IGMPVERSION] = { .name = "igmpversion", .type = BLOBMSG_TYPE_INT32 }, [DEV_ATTR_MLDVERSION] = { .name = "mldversion", .type = BLOBMSG_TYPE_INT32 }, [DEV_ATTR_NEIGHREACHABLETIME] = { .name = "neighreachabletime", .type = BLOBMSG_TYPE_INT32 }, + [DEV_ATTR_NEIGHGCSTALETIME] = { .name = "neighgcstaletime", .type = BLOBMSG_TYPE_INT32 }, [DEV_ATTR_RPS] = { .name = "rps", .type = BLOBMSG_TYPE_BOOL }, [DEV_ATTR_XPS] = { .name = "xps", .type = BLOBMSG_TYPE_BOOL }, [DEV_ATTR_DADTRANSMITS] = { .name = "dadtransmits", .type = BLOBMSG_TYPE_INT32 }, @@ -171,6 +172,10 @@ device_merge_settings(struct device *dev, struct device_settings *n) s->neigh4reachabletime : os->neigh4reachabletime; n->neigh6reachabletime = s->flags & DEV_OPT_NEIGHREACHABLETIME ? s->neigh6reachabletime : os->neigh6reachabletime; + n->neigh4gcstaletime = s->flags & DEV_OPT_NEIGHGCSTALETIME ? + s->neigh4gcstaletime : os->neigh4gcstaletime; + n->neigh6gcstaletime = s->flags & DEV_OPT_NEIGHGCSTALETIME ? + s->neigh6gcstaletime : os->neigh6gcstaletime; n->dadtransmits = s->flags & DEV_OPT_DADTRANSMITS ? s->dadtransmits : os->dadtransmits; n->multicast = s->flags & DEV_OPT_MULTICAST ? @@ -258,6 +263,11 @@ device_init_settings(struct device *dev, struct blob_attr **tb) s->flags |= DEV_OPT_NEIGHREACHABLETIME; } + if ((cur = tb[DEV_ATTR_NEIGHGCSTALETIME])) { + s->neigh6gcstaletime = s->neigh4gcstaletime = blobmsg_get_u32(cur); + s->flags |= DEV_OPT_NEIGHGCSTALETIME; + } + if ((cur = tb[DEV_ATTR_RPS])) { s->rps = blobmsg_get_bool(cur); s->flags |= DEV_OPT_RPS; @@ -960,6 +970,10 @@ device_dump_status(struct blob_buf *b, struct device *dev) blobmsg_add_u32(b, "neigh4reachabletime", st.neigh4reachabletime); blobmsg_add_u32(b, "neigh6reachabletime", st.neigh6reachabletime); } + if (st.flags & DEV_OPT_NEIGHGCSTALETIME) { + blobmsg_add_u32(b, "neigh4gcstaletime", st.neigh4gcstaletime); + blobmsg_add_u32(b, "neigh6gcstaletime", st.neigh6gcstaletime); + } if (st.flags & DEV_OPT_DADTRANSMITS) blobmsg_add_u32(b, "dadtransmits", st.dadtransmits); if (st.flags & DEV_OPT_MULTICAST_TO_UNICAST) diff --git a/device.h b/device.h index 9c4b822..0b8cd6a 100644 --- a/device.h +++ b/device.h @@ -45,6 +45,7 @@ enum { DEV_ATTR_MULTICAST_TO_UNICAST, DEV_ATTR_MULTICAST_ROUTER, DEV_ATTR_MULTICAST, + DEV_ATTR_NEIGHGCSTALETIME, __DEV_ATTR_MAX, }; @@ -88,6 +89,7 @@ enum { DEV_OPT_MULTICAST_TO_UNICAST = (1 << 14), DEV_OPT_MULTICAST_ROUTER = (1 << 15), DEV_OPT_MULTICAST = (1 << 16), + DEV_OPT_NEIGHGCSTALETIME = (1 << 17), }; /* events broadcasted to all users of a device */ @@ -143,6 +145,8 @@ struct device_settings { unsigned int mldversion; unsigned int neigh4reachabletime; unsigned int neigh6reachabletime; + unsigned int neigh4gcstaletime; + unsigned int neigh6gcstaletime; bool rps; bool xps; unsigned int dadtransmits; diff --git a/system-linux.c b/system-linux.c index f79625a..62c51b5 100644 --- a/system-linux.c +++ b/system-linux.c @@ -310,6 +310,16 @@ static void system_set_neigh6reachabletime(struct device *dev, const char *val) system_set_dev_sysctl("/proc/sys/net/ipv6/neigh/%s/base_reachable_time_ms", dev->ifname, val); } +static void system_set_neigh4gcstaletime(struct device *dev, const char *val) +{ + system_set_dev_sysctl("/proc/sys/net/ipv4/neigh/%s/gc_stale_time", dev->ifname, val); +} + +static void system_set_neigh6gcstaletime(struct device *dev, const char *val) +{ + system_set_dev_sysctl("/proc/sys/net/ipv6/neigh/%s/gc_stale_time", dev->ifname, val); +} + static void system_set_dadtransmits(struct device *dev, const char *val) { system_set_dev_sysctl("/proc/sys/net/ipv6/conf/%s/dad_transmits", dev->ifname, val); @@ -446,6 +456,18 @@ static int system_get_neigh6reachabletime(struct device *dev, char *buf, const s dev->ifname, buf, buf_sz); } +static int system_get_neigh4gcstaletime(struct device *dev, char *buf, const size_t buf_sz) +{ + return system_get_dev_sysctl("/proc/sys/net/ipv4/neigh/%s/gc_stale_time", + dev->ifname, buf, buf_sz); +} + +static int system_get_neigh6gcstaletime(struct device *dev, char *buf, const size_t buf_sz) +{ + return system_get_dev_sysctl("/proc/sys/net/ipv6/neigh/%s/gc_stale_time", + dev->ifname, buf, buf_sz); +} + static int system_get_dadtransmits(struct device *dev, char *buf, const size_t buf_sz) { return system_get_dev_sysctl("/proc/sys/net/ipv6/conf/%s/dad_transmits", @@ -1230,6 +1252,16 @@ system_if_get_settings(struct device *dev, struct device_settings *s) s->flags |= DEV_OPT_NEIGHREACHABLETIME; } + if (!system_get_neigh4gcstaletime(dev, buf, sizeof(buf))) { + s->neigh4gcstaletime = strtoul(buf, NULL, 0); + s->flags |= DEV_OPT_NEIGHGCSTALETIME; + } + + if (!system_get_neigh6gcstaletime(dev, buf, sizeof(buf))) { + s->neigh6gcstaletime = strtoul(buf, NULL, 0); + s->flags |= DEV_OPT_NEIGHGCSTALETIME; + } + if (!system_get_dadtransmits(dev, buf, sizeof(buf))) { s->dadtransmits = strtoul(buf, NULL, 0); s->flags |= DEV_OPT_DADTRANSMITS; @@ -1324,6 +1356,12 @@ system_if_apply_settings(struct device *dev, struct device_settings *s, unsigned snprintf(buf, sizeof(buf), "%d", s->neigh6reachabletime); system_set_neigh6reachabletime(dev, buf); } + if (s->flags & DEV_OPT_NEIGHGCSTALETIME & apply_mask) { + snprintf(buf, sizeof(buf), "%d", s->neigh4gcstaletime); + system_set_neigh4gcstaletime(dev, buf); + snprintf(buf, sizeof(buf), "%d", s->neigh6gcstaletime); + system_set_neigh6gcstaletime(dev, buf); + } if (s->flags & DEV_OPT_DADTRANSMITS & apply_mask) { snprintf(buf, sizeof(buf), "%d", s->dadtransmits); system_set_dadtransmits(dev, buf); -- 1.7.12.4 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From marex at denx.de Tue May 24 11:12:39 2016 From: marex at denx.de (Marek Vasut) Date: Tue, 24 May 2016 17:12:39 +0200 Subject: [OpenWrt-Devel] [PATCH] bcm53xx: Move SF mmap patch In-Reply-To: References: <1464101288-7056-1-git-send-email-marex@denx.de> Message-ID: <57446F67.1020904@denx.de> On 05/24/2016 04:57 PM, Felix Fietkau wrote: > On 2016-05-24 16:48, Marek Vasut wrote: >> The patch adding SPI flash mmap read capability does not compile due to missing >> m25p80_rx_nbits() function. Move it to bcm53xx patch directory, where the patch >> adding this m25p80_rx_nbits() function resides. > This doesn't make any sense to me. The function is already in the driver > in 4.4, it is not added by any patch... > > - Felix > Well is there any way to obtain kernel tree with the target/linux/generic/patches-4.4 applied, so I can base socfpga patches on top of it ? I tried git am on those patches, but that's obviously not possible, since a lot of these patches were not generated with git-format-patch or the relevant header was removed. Thanks -- Best regards, Marek Vasut _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From eschultz at prplfoundation.org Tue May 24 11:51:46 2016 From: eschultz at prplfoundation.org (Eric Schultz) Date: Tue, 24 May 2016 10:51:46 -0500 Subject: [OpenWrt-Devel] [PROPOSAL] move OpenWrt codebase to Git and GitHub In-Reply-To: <20160524140613.GA3437@localhost.localdomain> References: <20160524140613.GA3437@localhost.localdomain> Message-ID: I think this is a great idea! I very much support a move to Github; despite it's issues, it's just where development is happening today. Keeping a non-Github channel for submitting patches is also a great idea I think. My free-software side worries about using something non-free like drone.io for CI but this is a huge task certainly and I'm not sure a free tool would meet everyone's needs (plus there's the huge added burden of maintenance). Eric On Tue, May 24, 2016 at 9:06 AM, Luka Perkov wrote: > Dear OpenWrt mailing list readers, > > as the subject says I'd like to make proposal to move the OpenWrt > codebase to Git. This was already discussed before [1] and now when > there are no blockers [2] for this change I'd like that we as a > community move forward with this switch. > > Also, I'd like to propose that we move the project to GitHub and here > are the reasons why I see this as a good decision: > > * GitHub will allow people to contribute more easily > > The bigger amount of contributions has already happened and can be seen > on the packages feed which is already hosted on GitHub. With this I'm > also hoping to avoid comments regarding invalid patches on the mailing > list. > > For now I am proposing that the current development workflow is also > accepted - aka. patches that are sent to the mailing list are also > accepted. > > * GitHub and similar services will allow us to integrate more easily > with other projects > > Here specifically I mean integration with modern CI. Here is an example > of integration with drone.io [3][4]. At the moment this is only in the > POC stage but what I'd like to do down the line is to: > > - build OpenWrt images for all architectures for every pull request > > - build OpenWrt package binary for every package pull request for all > architectures and make it available for download > > - build and host OpenWrt qemu and/or Docker image for every pull request > > This will allow easy review of the work since flags will be shown in the > pull request if the build was sucessful or not. Also, this will allow > people to test changes without building the image and thus lowering the > time that needs to be spent on maintenance work. > > If this proposal gets accepted I'll be sending out an email to get > access to more build servers so this new build infrastructure can > properly support the project in a timely fashion. > > Please share your thoughts regarding this proposal. > > Regards, > Luka > > [1] > https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036390.html > [2] https://lists.openwrt.org/pipermail/openwrt-devel/2016-May/041329.html > [3] https://github.com/makkrnic/openwrt-qemu-x86 > [4] http://sartura-drone.makkrnic.com/makkrnic/openwrt-qemu-x86/5 > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > -- Eric Schultz, Community Manager, prpl Foundation http://www.prplfoundation.org eschultz at prplfoundation.org cell: 920-539-0404 skype: ericschultzwi @EricPrpl -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From david at lang.hm Tue May 24 13:29:30 2016 From: david at lang.hm (David Lang) Date: Tue, 24 May 2016 10:29:30 -0700 (PDT) Subject: [OpenWrt-Devel] [PROPOSAL] move OpenWrt codebase to Git and GitHub In-Reply-To: <20160524140613.GA3437@localhost.localdomain> References: <20160524140613.GA3437@localhost.localdomain> Message-ID: On Tue, 24 May 2016, Luka Perkov wrote: > Date: Tue, 24 May 2016 16:06:13 +0200 > From: Luka Perkov > To: openwrt-devel at lists.openwrt.org, openwrt-users at lists.openwrt.org > Subject: [OpenWrt-Devel] [PROPOSAL] move OpenWrt codebase to Git and GitHub > > Dear OpenWrt mailing list readers, > > as the subject says I'd like to make proposal to move the OpenWrt > codebase to Git. This was already discussed before [1] and now when > there are no blockers [2] for this change I'd like that we as a > community move forward with this switch. > > Also, I'd like to propose that we move the project to GitHub and here > are the reasons why I see this as a good decision: > > * GitHub will allow people to contribute more easily > > The bigger amount of contributions has already happened and can be seen > on the packages feed which is already hosted on GitHub. With this I'm > also hoping to avoid comments regarding invalid patches on the mailing > list. > > For now I am proposing that the current development workflow is also > accepted - aka. patches that are sent to the mailing list are also > accepted. OpenWRT has already moved to using Git instead of SVN, so why do they need to move from hosting the git repository themselves to having it hosted on github? There can be a mirror of the repo on github (remember that git is a Decentralized VCS) > * GitHub and similar services will allow us to integrate more easily > with other projects > > Here specifically I mean integration with modern CI. Here is an example > of integration with drone.io [3][4]. At the moment this is only in the > POC stage but what I'd like to do down the line is to: > > - build OpenWrt images for all architectures for every pull request > - build OpenWrt package binary for every package pull request for all > architectures and make it available for download > > - build and host OpenWrt qemu and/or Docker image for every pull request the build farm isn't large enough to do this It's also not neccessary to move to github to be able to do this, it just needs more systems in the build farm to be able to build things fast enough. > This will allow easy review of the work since flags will be shown in the > pull request if the build was sucessful or not. Also, this will allow > people to test changes without building the image and thus lowering the > time that needs to be spent on maintenance work. > > If this proposal gets accepted I'll be sending out an email to get > access to more build servers so this new build infrastructure can > properly support the project in a timely fashion. why should providing more build servers be contingent on moving to a commercial hosting provider vs running things themselves? David Lang > Please share your thoughts regarding this proposal. > > Regards, > Luka > > [1] https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036390.html > [2] https://lists.openwrt.org/pipermail/openwrt-devel/2016-May/041329.html > [3] https://github.com/makkrnic/openwrt-qemu-x86 > [4] http://sartura-drone.makkrnic.com/makkrnic/openwrt-qemu-x86/5 > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From marex at denx.de Tue May 24 13:32:18 2016 From: marex at denx.de (Marek Vasut) Date: Tue, 24 May 2016 19:32:18 +0200 Subject: [OpenWrt-Devel] [PATCH] bcm53xx: Move SF mmap patch In-Reply-To: References: <1464101288-7056-1-git-send-email-marex@denx.de> Message-ID: <57449022.60305@denx.de> On 05/24/2016 04:57 PM, Felix Fietkau wrote: > On 2016-05-24 16:48, Marek Vasut wrote: >> The patch adding SPI flash mmap read capability does not compile due to missing >> m25p80_rx_nbits() function. Move it to bcm53xx patch directory, where the patch >> adding this m25p80_rx_nbits() function resides. > This doesn't make any sense to me. The function is already in the driver > in 4.4, it is not added by any patch... OK, please drop this one and I will send a V2 of this too: [PATCH] target: socfpga: Add support for QSPI NOR boot -- Best regards, Marek Vasut _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Tue May 24 16:20:05 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Tue, 24 May 2016 16:20:05 -0400 Subject: [OpenWrt-Devel] [PROPOSAL] move OpenWrt codebase to Git and GitHub In-Reply-To: References: <20160524140613.GA3437@localhost.localdomain> Message-ID: <1464121205.1239.120.camel@homehost> On Tue, 2016-05-24 at 16:46 +0200, Jo-Philipp Wich wrote: > Hi Luka, > > this is fantastic news! > > I'd be very interested in your future progress on the CI front. > Let's just not make the mistake other projects make and turn CI into a an excuse to not have proper releases and a stablisation period before a stable release that only gets bug fixes afterwards. I've seen too many times CI/CD meant to use 'we won't bother with a release we'll just fix thing on the fly' that ends up really meaning CB (Continuous Brokeness). (I'd love to see people call CI/CD CI/CD/CB or just CI/CB so that deluded folks might get a clue). Regards, Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From hauke at hauke-m.de Tue May 24 16:31:00 2016 From: hauke at hauke-m.de (Hauke Mehrtens) Date: Tue, 24 May 2016 22:31:00 +0200 Subject: [OpenWrt-Devel] OpenWrt / LEDE Message-ID: <5744BA04.9000009@hauke-m.de> Hi, As it looks like the IRC meeting will not happen, because not so big interest by the people not already involved in LEDE and problems finding a time, lets discuss on the mailing list like suggested by Jow. Currently it looks like only Luka is working on OpenWrt as he committed many patches from LEDE to OpenWrt, which is fine. What will happen to the OpenWrt project? To me it looks like nobody except Luka is interested in working on OpenWrt. Are there any plans to continue the OpenWrt project or will it just die, only nobody wants to say it? Currently this is a bad situation for people that want to contribute patches because they do not exactly know were to contribute, some post them just to both list which is probably the best solution for the time we do not have a real solution. I do not plan to contribute much to OpenWrt any more and I do not know if I can commit anything any more, at least it looks like I was kicked from the openwrt-hackers mailing list without informing me. I would like to see a reunion of LEDE and OpenWrt, so do any of the non LEDE but OpenWrt core devs have any problems with the LEDE rules and so on? Hauke _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From jo at mein.io Tue May 24 16:35:42 2016 From: jo at mein.io (Jo-Philipp Wich) Date: Tue, 24 May 2016 22:35:42 +0200 Subject: [OpenWrt-Devel] [OpenWrt-Users] [PROPOSAL] move OpenWrt codebase to Git and GitHub In-Reply-To: References: <20160524140613.GA3437@localhost.localdomain> Message-ID: Hi, here's a few numbers we gathered with our buildbot setup: We currently need roughly 35GB per target when building OpenWrt plus the entire package world and currently there are roughly ~70 target/subtarget combinations in the OpenWrt tree. If fast build tests are desired then the only way to do so is by implementing incremental building which only works if there's enough space to retain all build trees at once which means there need to be about 2.5TB of storage available. For only building all base systems without package feeds the entire required space is around 800GB. A base system build currently requires 1 hour and 15 minutes on a machine having a Xeon E3-1246 v3 4 core / 8 thread CPU with prepopulated dl/, ccache and make -j8. A build of all packages from all feeds takes around 70 minutes on a Xeon E5-2630 v3 8 core / 16 thread machine with 12GB ram and make -j16. HTH, Jo _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From hauke at hauke-m.de Tue May 24 17:05:21 2016 From: hauke at hauke-m.de (Hauke Mehrtens) Date: Tue, 24 May 2016 23:05:21 +0200 Subject: [OpenWrt-Devel] OpenWrt / LEDE In-Reply-To: <5744BA04.9000009@hauke-m.de> References: <5744BA04.9000009@hauke-m.de> Message-ID: <5744C211.7020206@hauke-m.de> add lede-dev On 05/24/2016 10:31 PM, Hauke Mehrtens wrote: > Hi, > > As it looks like the IRC meeting will not happen, because not so big > interest by the people not already involved in LEDE and problems finding > a time, lets discuss on the mailing list like suggested by Jow. > > Currently it looks like only Luka is working on OpenWrt as he committed > many patches from LEDE to OpenWrt, which is fine. > > What will happen to the OpenWrt project? To me it looks like nobody > except Luka is interested in working on OpenWrt. Are there any plans to > continue the OpenWrt project or will it just die, only nobody wants to > say it? > Currently this is a bad situation for people that want to contribute > patches because they do not exactly know were to contribute, some post > them just to both list which is probably the best solution for the time > we do not have a real solution. > > I do not plan to contribute much to OpenWrt any more and I do not know > if I can commit anything any more, at least it looks like I was kicked > from the openwrt-hackers mailing list without informing me. > > > I would like to see a reunion of LEDE and OpenWrt, so do any of the non > LEDE but OpenWrt core devs have any problems with the LEDE rules and so on? > > Hauke This is my personal opinion and this was not somehow internally planned with other LEDE people. Hauke _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Tue May 24 17:10:14 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Tue, 24 May 2016 17:10:14 -0400 Subject: [OpenWrt-Devel] [PROPOSAL] move OpenWrt codebase to Git and GitHub In-Reply-To: <1464121205.1239.120.camel@homehost> References: <20160524140613.GA3437@localhost.localdomain> <1464121205.1239.120.camel@homehost> Message-ID: <1464124214.1239.123.camel@homehost> On Tue, 2016-05-24 at 16:20 -0400, Daniel Dickinson wrote: > On Tue, 2016-05-24 at 16:46 +0200, Jo-Philipp Wich wrote: > > Hi Luka, > > > > this is fantastic news! > > > > I'd be very interested in your future progress on the CI front. > > > Let's just not make the mistake other projects make and turn CI into a > an excuse to not have proper releases and a stablisation period before a > stable release that only gets bug fixes afterwards. > > I've seen too many times CI/CD meant to use 'we won't bother with a > release we'll just fix thing on the fly' that ends up really meaning CB > (Continuous Brokeness). (I'd love to see people call CI/CD CI/CD/CB or just CI/CB so that deluded folks might get a clue). That's not to say that stable release are perfect or even necessary better than a CD release *but* because it doesn't change much, people who depend on you can be aware of and work around issues you have, rater than dealing with a constantly changing set of problems. Regards, Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From leroi.lists at gmail.com Tue May 24 17:23:41 2016 From: leroi.lists at gmail.com (Roman Yeryomin) Date: Wed, 25 May 2016 00:23:41 +0300 Subject: [OpenWrt-Devel] OpenWrt / LEDE In-Reply-To: <5744BA04.9000009@hauke-m.de> References: <5744BA04.9000009@hauke-m.de> Message-ID: On 24 May 2016 at 23:31, Hauke Mehrtens wrote: > Hi, > > As it looks like the IRC meeting will not happen, because not so big > interest by the people not already involved in LEDE and problems finding > a time, lets discuss on the mailing list like suggested by Jow. > > Currently it looks like only Luka is working on OpenWrt as he committed > many patches from LEDE to OpenWrt, which is fine. > > What will happen to the OpenWrt project? To me it looks like nobody > except Luka is interested in working on OpenWrt. Are there any plans to > continue the OpenWrt project or will it just die, only nobody wants to > say it? > Currently this is a bad situation for people that want to contribute > patches because they do not exactly know were to contribute, some post > them just to both list which is probably the best solution for the time > we do not have a real solution. > > I do not plan to contribute much to OpenWrt any more and I do not know > if I can commit anything any more, at least it looks like I was kicked > from the openwrt-hackers mailing list without informing me. I believe LEDE didn't plan to contribute to OpenWrt from the very beginning. LEDE words are pretty contrary to the works. > I would like to see a reunion of LEDE and OpenWrt, so do any of the non > LEDE but OpenWrt core devs have any problems with the LEDE rules and so on? How many devs do you think it's possible to attract to OpenWrt having the promotion LEDE does and remembering the fact that most active devs went to LEDE? Same rules could be applied inside OpenWrt as I see it. Regards, Roman _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From zajec5 at gmail.com Tue May 24 17:26:37 2016 From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=) Date: Tue, 24 May 2016 23:26:37 +0200 Subject: [OpenWrt-Devel] OpenWrt / LEDE In-Reply-To: <5744BA04.9000009@hauke-m.de> References: <5744BA04.9000009@hauke-m.de> Message-ID: On 24 May 2016 at 22:31, Hauke Mehrtens wrote: > As it looks like the IRC meeting will not happen, because not so big > interest by the people not already involved in LEDE and problems finding > a time, lets discuss on the mailing list like suggested by Jow. > > Currently it looks like only Luka is working on OpenWrt as he committed > many patches from LEDE to OpenWrt, which is fine. > > What will happen to the OpenWrt project? To me it looks like nobody > except Luka is interested in working on OpenWrt. Are there any plans to > continue the OpenWrt project or will it just die, only nobody wants to > say it? > Currently this is a bad situation for people that want to contribute > patches because they do not exactly know were to contribute, some post > them just to both list which is probably the best solution for the time > we do not have a real solution. > > I do not plan to contribute much to OpenWrt any more and I do not know > if I can commit anything any more, at least it looks like I was kicked > from the openwrt-hackers mailing list without informing me. > > > I would like to see a reunion of LEDE and OpenWrt, so do any of the non > LEDE but OpenWrt core devs have any problems with the LEDE rules and so on? I'll speak for myself. I feel more comfortable with LEDE: 1) Rules are straight there 2) No single people controlling infrastructure and refusing to help 3) No decisions made behind the doors That will make me focus on LEDE. Of course this is open source world, OpenWrt can pick my changes. *However* I'd like to maintain 15.05 OpenWrt branch for some time (few months?). Unfortunately I feel unsure about my access to OpenWrt repo in the future. First some @openwrt.org e-mails were deleted/disabled. That made me ask about my commiting permissions: [2016-05-05] [14:41:32] [mbm]: Kaloz: can we still commit to OpenWrt? [2016-05-05] [14:45:28] as far as I know you can [2016-05-05] [16:21:09] rmilecki: yes it looked fine, but few days later I was kicked out of openwrt-hackers@ mailing list silently. I really would like to have a straight message from whoever takes these decisions at OpenWrt. What are your plans? Do you want me/us to stop contributing to OpenWrt? -- Rafa? _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From leroi.lists at gmail.com Tue May 24 17:39:50 2016 From: leroi.lists at gmail.com (Roman Yeryomin) Date: Wed, 25 May 2016 00:39:50 +0300 Subject: [OpenWrt-Devel] [PROPOSAL] move OpenWrt codebase to Git and GitHub In-Reply-To: References: <20160524140613.GA3437@localhost.localdomain> Message-ID: On 24 May 2016 at 18:51, Eric Schultz wrote: > I think this is a great idea! I very much support a move to Github; despite > it's issues, it's just where development is happening today. Keeping a > non-Github channel for submitting patches is also a great idea I think. > > My free-software side worries about using something non-free like drone.io > for CI but this is a huge task certainly and I'm not sure a free tool would > meet everyone's needs (plus there's the huge added burden of maintenance). How about something like kernelci.org? I'm not sure how to run all this https://github.com/kernelci but the result looks very interesting. > Eric > > On Tue, May 24, 2016 at 9:06 AM, Luka Perkov wrote: >> >> Dear OpenWrt mailing list readers, >> >> as the subject says I'd like to make proposal to move the OpenWrt >> codebase to Git. This was already discussed before [1] and now when >> there are no blockers [2] for this change I'd like that we as a >> community move forward with this switch. >> >> Also, I'd like to propose that we move the project to GitHub and here >> are the reasons why I see this as a good decision: >> >> * GitHub will allow people to contribute more easily >> >> The bigger amount of contributions has already happened and can be seen >> on the packages feed which is already hosted on GitHub. With this I'm >> also hoping to avoid comments regarding invalid patches on the mailing >> list. >> >> For now I am proposing that the current development workflow is also >> accepted - aka. patches that are sent to the mailing list are also >> accepted. >> >> * GitHub and similar services will allow us to integrate more easily >> with other projects >> >> Here specifically I mean integration with modern CI. Here is an example >> of integration with drone.io [3][4]. At the moment this is only in the >> POC stage but what I'd like to do down the line is to: >> >> - build OpenWrt images for all architectures for every pull request >> >> - build OpenWrt package binary for every package pull request for all >> architectures and make it available for download >> >> - build and host OpenWrt qemu and/or Docker image for every pull request >> >> This will allow easy review of the work since flags will be shown in the >> pull request if the build was sucessful or not. Also, this will allow >> people to test changes without building the image and thus lowering the >> time that needs to be spent on maintenance work. >> >> If this proposal gets accepted I'll be sending out an email to get >> access to more build servers so this new build infrastructure can >> properly support the project in a timely fashion. >> >> Please share your thoughts regarding this proposal. >> >> Regards, >> Luka >> >> [1] >> https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036390.html >> [2] https://lists.openwrt.org/pipermail/openwrt-devel/2016-May/041329.html >> [3] https://github.com/makkrnic/openwrt-qemu-x86 >> [4] http://sartura-drone.makkrnic.com/makkrnic/openwrt-qemu-x86/5 >> _______________________________________________ >> openwrt-devel mailing list >> openwrt-devel at lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > > > > > -- > Eric Schultz, Community Manager, prpl Foundation > http://www.prplfoundation.org > eschultz at prplfoundation.org > cell: 920-539-0404 > skype: ericschultzwi > @EricPrpl > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Tue May 24 17:56:38 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Tue, 24 May 2016 17:56:38 -0400 Subject: [OpenWrt-Devel] OpenWrt / LEDE In-Reply-To: References: <5744BA04.9000009@hauke-m.de> Message-ID: <1464126998.1239.137.camel@homehost> On Wed, 2016-05-25 at 00:23 +0300, Roman Yeryomin wrote: [snip] > > I do not plan to contribute much to OpenWrt any more and I do not know > > if I can commit anything any more, at least it looks like I was kicked > > from the openwrt-hackers mailing list without informing me. > > I believe LEDE didn't plan to contribute to OpenWrt from the very beginning. > LEDE words are pretty contrary to the works. I disagree. I think LEDE's biggest problem is that are not vocal like me, but would rather just work on code and not talk and hence are particularly *bad* at communicating and publicizing what they're thinking and doing. They're also incredibly busy people with work that doesn't involve community openwrt/lede, which limits exactly what they can do. One could instance of this is the patches I thought were being ignored and just disappearing were in fact being considered and where needed better made to fit the project's needs - the issue was that I didn't *know* this because Felix and John, especially, tend to 'don't talk, just do' and so I didn't realize what was actually the case. This is something it appears Felix and Jo, at least, are making efforts to improve in LEDE. > > > I would like to see a reunion of LEDE and OpenWrt, so do any of the non > > LEDE but OpenWrt core devs have any problems with the LEDE rules and so on? > > How many devs do you think it's possible to attract to OpenWrt having > the promotion LEDE does and remembering the fact that most active devs > went to LEDE? > Same rules could be applied inside OpenWrt as I see it. Let's see if any of the remaining OpenWrt devs at least publicly support adopting them or some variation of them. As I've said before my impression is that LEDE-style rules are not all that welcomed (and that's based on the interactions I saw on the private openwrt channels when I was a developer, not just a pure outsider view; it's possible my impression is wrong, but the toxicity described previously was in large part negative reaction by folkds in the LEDE team to toxic comments from at least one of the remaining OpenWrt devs; certainly it damaged my opinion of him (although the toxicity also damaged my opinion of a couple of LEDE folks too)). Regards, Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From wigyori at uid0.hu Tue May 24 17:57:05 2016 From: wigyori at uid0.hu (Zoltan HERPAI) Date: Tue, 24 May 2016 23:57:05 +0200 (CEST) Subject: [OpenWrt-Devel] OpenWrt / LEDE In-Reply-To: <5744C211.7020206@hauke-m.de> References: <5744BA04.9000009@hauke-m.de> <5744C211.7020206@hauke-m.de> Message-ID: Hi, > On 05/24/2016 10:31 PM, Hauke Mehrtens wrote: >> As it looks like the IRC meeting will not happen, because not so big >> interest by the people not already involved in LEDE and problems finding >> a time, lets discuss on the mailing list like suggested by Jow. The point you are missing is that some of the OpenWrt core team is living in a non-EU timezone. We can pick a PDT timeslot that won't work for anyone living in EU, and say that LEDE is not interested in the discussion, but that's just not the proper way. >> Currently it looks like only Luka is working on OpenWrt as he committed >> many patches from LEDE to OpenWrt, which is fine. It is one thing that there are no commits currently from anyone, until the OpenWrt/LEDE discussions are made. >> What will happen to the OpenWrt project? To me it looks like nobody >> except Luka is interested in working on OpenWrt. Are there any plans to >> continue the OpenWrt project or will it just die, only nobody wants to >> say it? See above. We don't plan to play dead. Also, IIRC there are patches for targets which are/were maintained by LEDE members. As far as I know, commit rights have not been revoked (somebody correct me if I'm wrong). >> Currently this is a bad situation for people that want to contribute >> patches because they do not exactly know were to contribute, some post >> them just to both list which is probably the best solution for the time >> we do not have a real solution. Yes, there might be some confusion about this, we are still lagging a bit behind due to the surprise fork. Luka sent a mail on some of the planned moves, please refer to that thread. (Jow, thanks for the buildbot-related number crunching.) >> I do not plan to contribute much to OpenWrt any more and I do not know >> if I can commit anything any more, at least it looks like I was kicked >> from the openwrt-hackers mailing list without informing me. >> >> I would like to see a reunion of LEDE and OpenWrt, so do any of the non >> LEDE but OpenWrt core devs have any problems with the LEDE rules and so on? >> > This is my personal opinion and this was not somehow internally planned > with other LEDE people. If I start a discussion about my employer-related topics along a beer with a couple friends, that's a private discussion with personal opinions. If I do it on any public channel, I can be felt to represent my employer on that topic. You seem to be representing LEDE. Regards, -w- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Tue May 24 18:18:45 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Tue, 24 May 2016 18:18:45 -0400 Subject: [OpenWrt-Devel] OpenWrt / LEDE In-Reply-To: References: <5744BA04.9000009@hauke-m.de> <5744C211.7020206@hauke-m.de> Message-ID: <1464128325.1239.146.camel@homehost> On Tue, 2016-05-24 at 23:57 +0200, Zoltan HERPAI wrote: [snip] > Hi, > >> I would like to see a reunion of LEDE and OpenWrt, so do any of the non > >> LEDE but OpenWrt core devs have any problems with the LEDE rules and so on? > >> > > This is my personal opinion and this was not somehow internally planned > > with other LEDE people. > > If I start a discussion about my employer-related topics along a beer with > a couple friends, that's a private discussion with personal opinions. If I > do it on any public channel, I can be felt to represent my employer on > that topic. You seem to be representing LEDE. > That's the kind of bollock that damages the ability of employees to have a right to free speech which disagrees with (or is at least independently developed of) their employers views. As long it as someone makes it clear when they are speaking for themselves and not as a representative of the group, it should be accepted on that basis, unless if there is a reason to believe otherwise *other than* just that the person happens to be a member of some group. It's kind of like saying a black who says he or she speaking for himself speaks for all blacks, just because it's known he or she is black and he speaks on a public channel. It's bollocks. People are indivduals and have a right be such, and to have, and be seen to have, views independent of the various groups the are members of. I certainly don't speak for all white male IT professionals from North America. Regards, Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Tue May 24 19:56:55 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Tue, 24 May 2016 19:56:55 -0400 Subject: [OpenWrt-Devel] OpenWrt / LEDE In-Reply-To: <1464128325.1239.146.camel@homehost> References: <5744BA04.9000009@hauke-m.de> <5744C211.7020206@hauke-m.de> <1464128325.1239.146.camel@homehost> Message-ID: <1464134215.1239.152.camel@homehost> On Tue, 2016-05-24 at 18:18 -0400, Daniel Dickinson wrote: > On Tue, 2016-05-24 at 23:57 +0200, Zoltan HERPAI wrote: > [snip] > > Hi, > > >> I would like to see a reunion of LEDE and OpenWrt, so do any of the non > > >> LEDE but OpenWrt core devs have any problems with the LEDE rules and so on? > > >> > > > This is my personal opinion and this was not somehow internally planned > > > with other LEDE people. > > > > If I start a discussion about my employer-related topics along a beer with > > a couple friends, that's a private discussion with personal opinions. If I > > do it on any public channel, I can be felt to represent my employer on > > that topic. You seem to be representing LEDE. > > > > That's the kind of bollock that damages the ability of employees to have > a right to free speech which disagrees with (or is at least > independently developed of) their employers views. > > As long it as someone makes it clear when they are speaking for > themselves and not as a representative of the group, it should be > accepted on that basis, unless if there is a reason to believe otherwise > *other than* just that the person happens to be a member of some group. > > It's kind of like saying a black who says he or she speaking for himself > speaks for all blacks, just because it's known he or she is black and he > speaks on a public channel. > > It's bollocks. People are indivduals and have a right be such, and to > have, and be seen to have, views independent of the various groups the > are members of. > > I certainly don't speak for all white male IT professionals from North > America. > On that note, after the fact I noticed your .hu and am wondering if that this kind of thinking is a difference in the culture you're part of vs. the western cultures Hauke and I are part of? In much of 'the west' there is an expectation that individuals are free to speak for themselves (and be seen to be doing such) regardless of what group (although various corporations and governments sometimes try and quash such things, which most here consider a harm not a good) they belong to. Certainly Hauke believes he is free to speak for himself and has a reasonable expectation that people will accept that his opinion is his alone, unless he explicitly is speaking on behalf of some organization, like LEDE. To a certain extent you yourself acknowledge individual opinion (with you over a beer comment), but you seem to think that such a view of individual opinions are not as valid in the public domain, whereas our expectation is that it is just as valid in the public domain as in the private. Regards, Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From yszhou4tech at gmail.com Tue May 24 20:45:58 2016 From: yszhou4tech at gmail.com (Yousong Zhou) Date: Wed, 25 May 2016 08:45:58 +0800 Subject: [OpenWrt-Devel] OpenWrt / LEDE In-Reply-To: <1464134215.1239.152.camel@homehost> References: <5744BA04.9000009@hauke-m.de> <5744C211.7020206@hauke-m.de> <1464128325.1239.146.camel@homehost> <1464134215.1239.152.camel@homehost> Message-ID: On 25 May 2016 at 07:56, Daniel Dickinson wrote: > On Tue, 2016-05-24 at 18:18 -0400, Daniel Dickinson wrote: >> On Tue, 2016-05-24 at 23:57 +0200, Zoltan HERPAI wrote: >> [snip] >> > Hi, >> > >> I would like to see a reunion of LEDE and OpenWrt, so do any of the non >> > >> LEDE but OpenWrt core devs have any problems with the LEDE rules and so on? >> > >> >> > > This is my personal opinion and this was not somehow internally planned >> > > with other LEDE people. >> > >> > If I start a discussion about my employer-related topics along a beer with >> > a couple friends, that's a private discussion with personal opinions. If I >> > do it on any public channel, I can be felt to represent my employer on >> > that topic. You seem to be representing LEDE. >> > >> >> That's the kind of bollock that damages the ability of employees to have >> a right to free speech which disagrees with (or is at least >> independently developed of) their employers views. >> >> As long it as someone makes it clear when they are speaking for >> themselves and not as a representative of the group, it should be >> accepted on that basis, unless if there is a reason to believe otherwise >> *other than* just that the person happens to be a member of some group. >> >> It's kind of like saying a black who says he or she speaking for himself >> speaks for all blacks, just because it's known he or she is black and he >> speaks on a public channel. >> >> It's bollocks. People are indivduals and have a right be such, and to >> have, and be seen to have, views independent of the various groups the >> are members of. >> >> I certainly don't speak for all white male IT professionals from North >> America. >> > > On that note, after the fact I noticed your .hu and am wondering if that > this kind of thinking is a difference in the culture you're part of vs. > the western cultures Hauke and I are part of? > > In much of 'the west' there is an expectation that individuals are free > to speak for themselves (and be seen to be doing such) regardless of > what group (although various corporations and governments sometimes try > and quash such things, which most here consider a harm not a good) they > belong to. > > Certainly Hauke believes he is free to speak for himself and has a > reasonable expectation that people will accept that his opinion is his > alone, unless he explicitly is speaking on behalf of some organization, > like LEDE. > > To a certain extent you yourself acknowledge individual opinion (with > you over a beer comment), but you seem to think that such a view of > individual opinions are not as valid in the public domain, whereas our > expectation is that it is just as valid in the public domain as in the > private. > > Regards, > > Daniel Let's just save such non-sense sense of culture and expectation discussion in another place. yousong > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Tue May 24 20:57:12 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Tue, 24 May 2016 20:57:12 -0400 Subject: [OpenWrt-Devel] OpenWrt / LEDE In-Reply-To: References: <5744BA04.9000009@hauke-m.de> <5744C211.7020206@hauke-m.de> <1464128325.1239.146.camel@homehost> <1464134215.1239.152.camel@homehost> Message-ID: <1464137832.1239.164.camel@homehost> On Wed, 2016-05-25 at 08:45 +0800, Yousong Zhou wrote: > > > > To a certain extent you yourself acknowledge individual opinion (with > > you over a beer comment), but you seem to think that such a view of > > individual opinions are not as valid in the public domain, whereas our > > expectation is that it is just as valid in the public domain as in the > > private. > Let's just save such non-sense sense of culture and expectation > discussion in another place. The point was that Hauke is perfectly reasonable to expect that he can speak for himself (if you disagree then it will negatively impact your ability to interact well with those on this list), and that I was attempting to point out to someone who appears to be from a different country, where norms *really and truly* are different. Failing to be aware of, and prepared to find reasonable ways to deal with (even if just pointing out this, this is what we expect, which is different than what you may be used to expecting) people who have quite different learned interpretations of interactions is to *deny reality*. We live in a world where people don't all grow up with the same playbook, and that means we're not even necessarily all trying to play the same game, and being aware of this, and pointing out what game is actually being played *is important to rational discourse*. It doesn't mean we have to live by someone elses expectations (if that was what you were upset about), but to deny that such things are true is to fail to comprehend the world as it really is. Regards, Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Tue May 24 21:19:17 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Tue, 24 May 2016 21:19:17 -0400 Subject: [OpenWrt-Devel] OpenWrt / LEDE In-Reply-To: <1464137832.1239.164.camel@homehost> References: <5744BA04.9000009@hauke-m.de> <5744C211.7020206@hauke-m.de> <1464128325.1239.146.camel@homehost> <1464134215.1239.152.camel@homehost> <1464137832.1239.164.camel@homehost> Message-ID: <1464139157.1239.169.camel@homehost> On Tue, 2016-05-24 at 20:57 -0400, Daniel Dickinson wrote: > On Wed, 2016-05-25 at 08:45 +0800, Yousong Zhou wrote: > > > > > > To a certain extent you yourself acknowledge individual opinion (with > > > you over a beer comment), but you seem to think that such a view of > > > individual opinions are not as valid in the public domain, whereas our > > > expectation is that it is just as valid in the public domain as in the > > > private. > > > Let's just save such non-sense sense of culture and expectation > > discussion in another place. Perhaps the issue is the notion of a monolithic culture - that is *not* what meant. There are variations and subgroups, and individual differences, no doubt about that. The point is that there are different demographics who grew up with different rules than others, and perhaps culture was too broad a term, but understanding that other people come to the table with different interpretations, and pointing out why we do and say what we do important to rational dialogue, because if I say red and you are thinking of what call blue, it's not going to be very constructive. Regards, Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Tue May 24 22:04:52 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Tue, 24 May 2016 22:04:52 -0400 Subject: [OpenWrt-Devel] OpenWrt / LEDE In-Reply-To: <1464139157.1239.169.camel@homehost> References: <5744BA04.9000009@hauke-m.de> <5744C211.7020206@hauke-m.de> <1464128325.1239.146.camel@homehost> <1464134215.1239.152.camel@homehost> <1464137832.1239.164.camel@homehost> <1464139157.1239.169.camel@homehost> Message-ID: <1464141892.1239.176.camel@homehost> On Tue, 2016-05-24 at 21:19 -0400, Daniel Dickinson wrote: > > > Let's just save such non-sense sense of culture and expectation > > > discussion in another place. > > Perhaps the issue is the notion of a monolithic culture - that is *not* > what meant. There are variations and subgroups, and individual > differences, no doubt about that. The point is that there are different > demographics who grew up with different rules than others, and perhaps Perhaps your objection is the notion with any kind of general statement about a group. Personally I think as long as one recognized that such statements are *statistical predictions* and not necessarily representative of a given individual. This is true, but is also true that one can make predictions, or at rate useful guesses, about *potential* reasons for someone's actions or beliefs. The object is not to pigeonhole, but, given minimal information, to attempt to *understand and address* things that give rise to disputes. Regards, Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Tue May 24 23:54:23 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Tue, 24 May 2016 23:54:23 -0400 Subject: [OpenWrt-Devel] [OT] Implemented: not an ML erase button but at least a rethink switch Message-ID: <1464148463.1239.200.camel@homehost> Hi all, I've recognized I have to do something about my impulse emailing and have just finished implementing a technical solution that requires me to verify that really do want to send the mail, and verification can't be done until a configured amount of time has elapsed. Hopefully this will keep me from so much unwise/noisy mail. If anyway else is interested, Ubuntu packages are available in my PPA: https://launchpad.net/~dfc-d/+archive/ubuntu/misc It's based on the msmtpq queuing scripts wrapped around the msmtp send-only email client, acting as the 'sendmail' command, with the addition of a command-line option --verify-before-send that if you invoked as sendmail with that as the first parameter (e.g. from Evolution), it queues the mail but doesn't send it, and requires you to confirm that you want to send it, and then only after your configured delay period has past. System mails don't have the parameter so just send or queue and automatically send as usual (assuming of course you have configured /etc/msmtprc to use your email provider). msmtpq-mta also supports per-user configuration and can use the gnome keyring (that comes from the msmtp command). If want to keep your normal MTA command and use the msmtpq command to achieve this functionality you can do that as well, although you will need to have a wrapper that sets the applicable environment variable to enable the send delay. Even if no one else finds this interesting, I know I needed it. Regards, Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From Michal.Hrusecky at nic.cz Wed May 25 03:46:23 2016 From: Michal.Hrusecky at nic.cz (Michal Hrusecky) Date: Wed, 25 May 2016 09:46:23 +0200 Subject: [OpenWrt-Devel] [PATCH] bcm53xx: Move SF mmap patch In-Reply-To: <57446F67.1020904@denx.de> References: <1464101288-7056-1-git-send-email-marex@denx.de> <57446F67.1020904@denx.de> Message-ID: <20160525074623.vunimweri5jz5g2t@workbook.ipv6.hrusecky.net> Marek Vasut - 17:12 24.05.16 wrote: > On 05/24/2016 04:57 PM, Felix Fietkau wrote: > > On 2016-05-24 16:48, Marek Vasut wrote: > >> The patch adding SPI flash mmap read capability does not compile due to missing > >> m25p80_rx_nbits() function. Move it to bcm53xx patch directory, where the patch > >> adding this m25p80_rx_nbits() function resides. > > This doesn't make any sense to me. The function is already in the driver > > in 4.4, it is not added by any patch... > > > > - Felix > > > Well is there any way to obtain kernel tree with the > target/linux/generic/patches-4.4 applied, so I can base socfpga patches > on top > of it ? > > I tried git am on those patches, but that's obviously not possible, > since a lot of these patches were not generated with git-format-patch > or the relevant header was removed. Quilt work fine: https://wiki.openwrt.org/doc/devel/patches#adding_or_editing_kernel_patches _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From mbm at openwrt.org Wed May 25 04:09:11 2016 From: mbm at openwrt.org (mbm) Date: Wed, 25 May 2016 01:09:11 -0700 Subject: [OpenWrt-Devel] OpenWrt / LEDE In-Reply-To: References: Message-ID: > Date: Tue, 24 May 2016 23:26:37 +0200 > From: Rafa? Mi?ecki > To: Hauke Mehrtens > Cc: OpenWrt Development List, LEDE > Development List > Subject: Re: [OpenWrt-Devel] OpenWrt / LEDE > Message-ID: > > Content-Type: text/plain; charset=UTF-8 [snip] > *However* I'd like to maintain 15.05 OpenWrt branch for some time (few > months?). Unfortunately I feel unsure about my access to OpenWrt repo > in the future. First some @openwrt.org e-mails were deleted/disabled. > That made me ask about my commiting permissions: > [2016-05-05] [14:41:32] [mbm]: Kaloz: can we still commit to OpenWrt? > [2016-05-05] [14:45:28] as far as I know you can > [2016-05-05] [16:21:09] rmilecki: yes > it looked fine, but few days later I was kicked out of > openwrt-hackers@ mailing list silently. > There is no relation between email addresses and commit access. At no point was commit access revoked for any LEDE members nor have any email messages been deleted. You are encouraged to continue contributing. The hackers email address represents the primary point of contact for OpenWrt, particularly in regards to donations. Following the surprise LEDE announcement, forwarding rules for @openwrt.org email addresses were disabled. This was done to mitigate further damage to OpenWrt due to misrepresentation, intentional or otherwise. It is hoped that the projects may yet merge and the email access will be restored. - mbm -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From bjorn at mork.no Wed May 25 04:10:17 2016 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Wed, 25 May 2016 10:10:17 +0200 Subject: [OpenWrt-Devel] [LEDE-DEV] OpenWrt / LEDE In-Reply-To: (Zoltan HERPAI's message of "Tue, 24 May 2016 23:57:05 +0200 (CEST)") References: <5744BA04.9000009@hauke-m.de> <5744C211.7020206@hauke-m.de> Message-ID: <87twhmpnh2.fsf@nemi.mork.no> Zoltan HERPAI writes: >> On 05/24/2016 10:31 PM, Hauke Mehrtens wrote: >> >> This is my personal opinion and this was not somehow internally planned >> with other LEDE people. > > If I start a discussion about my employer-related topics along a beer > with a couple friends, that's a private discussion with personal > opinions. If I do it on any public channel, I can be felt to represent > my employer on that topic. You seem to be representing LEDE. No. This is basic netiquette which you are assumed to know *before* posting to a puvblic mailing list. You can find it "everywhere" on the Internet. One good source is for example this informational RFC: https://tools.ietf.org/html/rfc1855 Quoting from "3.1.1 General Guidelines for mailing lists and NetNews" : - Assume that individuals speak for themselves, and what they say does not represent their organization (unless stated explicitly). Bj?rn _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From mbm at openwrt.org Wed May 25 04:13:29 2016 From: mbm at openwrt.org (mbm) Date: Wed, 25 May 2016 01:13:29 -0700 Subject: [OpenWrt-Devel] OpenWrt / LEDE In-Reply-To: References: Message-ID: > Date: Tue, 24 May 2016 17:56:38 -0400 > From: Daniel Dickinson > To: OpenWrt Development List > Subject: Re: [OpenWrt-Devel] OpenWrt / LEDE > Message-ID: <1464126998.1239.137.camel at homehost> > Content-Type: text/plain; charset="UTF-8" [snip] > Let's see if any of the remaining OpenWrt devs at least publicly support > adopting them or some variation of them. As I've said before my > impression is that LEDE-style rules are not all that welcomed (and > that's based on the interactions I saw on the private openwrt channels > when I was a developer, not just a pure outsider view; it's possible my > impression is wrong, but the toxicity described previously was in large > part negative reaction by folkds in the LEDE team to toxic comments from > at least one of the remaining OpenWrt devs; certainly it damaged my > opinion of him (although the toxicity also damaged my opinion of a > couple of LEDE folks too)). Sigh... It's not as if LEDE offered the changes to OpenWrt and we voted against them causing a split -- there was literally no discussion and no warning prior to the public announcement. LEDE just suddenly existed and the story quickly became that the reason for their existence was because OpenWrt somehow prevented them from making changes. At no point did OpenWrt veto changes or even have the option to; the truth is that we agree changes need to be made. By not including OpenWrt in the discussions LEDE ran afoul of their own transparency leading to the false impression that OpenWrt was somehow against the changes, causing a split in the community in terms of LEDE vs OpenWrt with various amounts of hostility on the mailing lists. None of this is healthy or constructive. Let me be very clear: nobody on the OpenWrt side is against the changes LEDE is trying to make. It is our position that this whole thing is a misunderstanding and that the projects should attempt to merge again. I have been trying to arrange talks between the two sides but between work schedules, timezone conflicts and FUD regarding the split it's been very difficult. - mbm -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From bjorn at mork.no Wed May 25 06:55:43 2016 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Wed, 25 May 2016 12:55:43 +0200 Subject: [OpenWrt-Devel] OpenWrt / LEDE In-Reply-To: (mbm@openwrt.org's message of "Wed, 25 May 2016 01:09:11 -0700") References: Message-ID: <8760u2pftc.fsf@nemi.mork.no> mbm writes: > The hackers email address represents the primary point of contact for > OpenWrt, particularly in regards to donations. Following the surprise > LEDE announcement, forwarding rules for @openwrt.org email addresses > were disabled. This was done to mitigate further damage to OpenWrt due > to misrepresentation, intentional or otherwise. Failing to see the damage your action has caused is your biggest problem right now. Even if we accept the rather far fetched possibilty of misrepresentation, there is no way that can outweight the effect on the maintainership status OpenWrt. Right now, 95 of the 145 (PKG_)MAINTAINER entries for OpenWrt packages points to an openwrt.org email address belonging to a LEDE committer: bjorn at canardo:/usr/local/src/openwrt$ git grep 'MAINTAINER:=.*<\(lynxis\|noltari\|dangole\|nbd\|hauke\|jow\|blogic\|neoraider\|rmilecki\|cyrus\|stintel\|thess\)@openwrt.org>' origin/master -- package/|wc -l 95 bjorn at canardo:/usr/local/src/openwrt$ git grep 'MAINTAINER' origin/master -- package/|wc -l 145 I don't know if all these were disabled, but the package I tried to submit to after the split was one of these. You don't seem to understand the devastating effect it has on OpenWrt if occasional contributors gets an email bounce from the published maintainer address. There is no way you can blame those maintainers for this situation. The problem is solely the responsibility of whoever decided to disable those addresses. Bj?rn _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From zajec5 at gmail.com Wed May 25 07:52:54 2016 From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=) Date: Wed, 25 May 2016 13:52:54 +0200 Subject: [OpenWrt-Devel] OpenWrt / LEDE In-Reply-To: References: Message-ID: On 25 May 2016 at 10:09, mbm wrote: > The hackers email address represents the primary point of contact for > OpenWrt, particularly in regards to donations. Following the surprise LEDE > announcement, forwarding rules for @openwrt.org email addresses were > disabled. This was done to mitigate further damage to OpenWrt due to > misrepresentation, intentional or otherwise. Hackers e-mail address (mailing list) was also used for internal discussions. You not only disabled forwarding rules for @openwrt.org personal e-mails but also kicked out private e-mails from the hackers mailing list. I never really cared about hardware donations offered to hackers, but knowing what's going on (like release plans) is important for contributing. -- Rafa? _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From luka at openwrt.org Wed May 25 12:25:54 2016 From: luka at openwrt.org (Luka Perkov) Date: Wed, 25 May 2016 18:25:54 +0200 Subject: [OpenWrt-Devel] [PROPOSAL] move OpenWrt codebase to Git and GitHub In-Reply-To: References: <20160524140613.GA3437@localhost.localdomain> Message-ID: <20160525162554.GA11029@localhost.localdomain> On Tue, May 24, 2016 at 10:51:46AM -0500, Eric Schultz wrote: > My free-software side worries about using something non-free like drone.io > for CI but this is a huge task certainly and I'm not sure a free tool would > meet everyone's needs (plus there's the huge added burden of maintenance). The drone.io is actually Apache 2.0 [1] and the example build was configured on a private machine. Luka [1] https://github.com/drone/drone _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From luka at openwrt.org Wed May 25 12:46:27 2016 From: luka at openwrt.org (Luka Perkov) Date: Wed, 25 May 2016 18:46:27 +0200 Subject: [OpenWrt-Devel] [PROPOSAL] move OpenWrt codebase to Git and GitHub In-Reply-To: References: <20160524140613.GA3437@localhost.localdomain> Message-ID: <20160525164627.GB11029@localhost.localdomain> On Tue, May 24, 2016 at 10:29:30AM -0700, David Lang wrote: > OpenWRT has already moved to using Git instead of SVN, No, it has not. To users is exposed the Git frontend while the commits are made to the SVN repo. > so why do they need to move from hosting the git repository themselves to > having it hosted on github? See the reasons below. > There can be a mirror of the repo on github (remember that git is a > Decentralized VCS) Also, we have discussed of having a mirror on our server and this is something that we can do. If everything happens on GitHub then I don't see a point in having clone on GitHub instead of a having the main repo on GitHub and having clone elsewhere. > > * GitHub and similar services will allow us to integrate more easily > > with other projects > > > > Here specifically I mean integration with modern CI. Here is an example > > of integration with drone.io [3][4]. At the moment this is only in the > > POC stage but what I'd like to do down the line is to: > > > > - build OpenWrt images for all architectures for every pull request > > - build OpenWrt package binary for every package pull request for all > > architectures and make it available for download > > > > - build and host OpenWrt qemu and/or Docker image for every pull request > > the build farm isn't large enough to do this Current one is not. > It's also not neccessary to move to github to be able to do this, it just > needs more systems in the build farm to be able to build things fast enough. With GitHub it will be able to see compile status of each pull request. If it is not GitHub or simmilar service then this would need to be developed and I think we have better things to do then that :) > > This will allow easy review of the work since flags will be shown in the > > pull request if the build was sucessful or not. Also, this will allow > > people to test changes without building the image and thus lowering the > > time that needs to be spent on maintenance work. > > > > If this proposal gets accepted I'll be sending out an email to get > > access to more build servers so this new build infrastructure can > > properly support the project in a timely fashion. > > why should providing more build servers be contingent on moving to a > commercial hosting provider vs running things themselves? IMO move to GitHub will allow us to manage contributions more easily and handle them in timely fashion. This, combined with other perks explained in my previous email is possible today without need to develop the features that others provide today. Luka _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From luka at openwrt.org Wed May 25 12:55:38 2016 From: luka at openwrt.org (Luka Perkov) Date: Wed, 25 May 2016 18:55:38 +0200 Subject: [OpenWrt-Devel] [OpenWrt-Users] [PROPOSAL] move OpenWrt codebase to Git and GitHub In-Reply-To: References: <20160524140613.GA3437@localhost.localdomain> Message-ID: <20160525165538.GA11417@localhost.localdomain> Thanks for the numbers Jo. The current hello-world setup with drone.io was done on cheap SSD based VPS. That said, with some "optimizations" (or hacks if you want) I think it should be possible to have less powerful servers but more of them to do what is needed. For example, if one makes pull request for package A. Then for every target only the core system with package A and it's dependencies should be built. That said, if pull request is valid it will result with a successful build. We should avoid situations where somebody makes a patch for package A and if fails to build because package Z unrelated to package A is broken. Luka On Tue, May 24, 2016 at 10:35:42PM +0200, Jo-Philipp Wich wrote: > Hi, > > here's a few numbers we gathered with our buildbot setup: > > We currently need roughly 35GB per target when building OpenWrt plus the > entire package world and currently there are roughly ~70 > target/subtarget combinations in the OpenWrt tree. > > If fast build tests are desired then the only way to do so is by > implementing incremental building which only works if there's enough > space to retain all build trees at once which means there need to be > about 2.5TB of storage available. > > For only building all base systems without package feeds the entire > required space is around 800GB. > > A base system build currently requires 1 hour and 15 minutes on a > machine having a Xeon E3-1246 v3 4 core / 8 thread CPU with prepopulated > dl/, ccache and make -j8. > > A build of all packages from all feeds takes around 70 minutes on a Xeon > E5-2630 v3 8 core / 16 thread machine with 12GB ram and make -j16. > > HTH, > Jo > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From valent at otvorenamreza.org Wed May 25 16:49:49 2016 From: valent at otvorenamreza.org (Valent Turkovic) Date: Wed, 25 May 2016 22:49:49 +0200 Subject: [OpenWrt-Devel] [OpenWrt-Users] [PROPOSAL] move OpenWrt codebase to Git and GitHub In-Reply-To: References: <20160524140613.GA3437@localhost.localdomain> Message-ID: On Wed, May 25, 2016 at 7:06 PM, Benjamin Henrion wrote: > On Tue, May 24, 2016 at 10:35 PM, Jo-Philipp Wich wrote: >> Hi, >> >> here's a few numbers we gathered with our buildbot setup: >> >> We currently need roughly 35GB per target when building OpenWrt plus the >> entire package world and currently there are roughly ~70 >> target/subtarget combinations in the OpenWrt tree. >> >> If fast build tests are desired then the only way to do so is by >> implementing incremental building which only works if there's enough >> space to retain all build trees at once which means there need to be >> about 2.5TB of storage available. > > A BTRFS volume with deduplication would help here? I wouldn't trust BTRFS with photo album of my cats... I had it running and couldn't compile OpenWrt on BTRFS volume because it ran out of space, it was a knows bug that small files used up more space than df and other tools saw... But I as an advanced OpenWrt user and beginner openwrt developer would love to see move to github, it would make things much, much easier, please go for it. _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Wed May 25 21:19:24 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Wed, 25 May 2016 21:19:24 -0400 Subject: [OpenWrt-Devel] OpenWrt / LEDE In-Reply-To: References: Message-ID: <1464225564.1239.291.camel@homehost> On Wed, 2016-05-25 at 01:13 -0700, mbm wrote: > > [snip] > > Let's see if any of the remaining OpenWrt devs at least publicly support > > adopting them or some variation of them. As I've said before my > > impression is that LEDE-style rules are not all that welcomed (and > > that's based on the interactions I saw on the private openwrt channels > > when I was a developer, not just a pure outsider view; it's possible my > > impression is wrong, but the toxicity described previously was in large > > part negative reaction by folkds in the LEDE team to toxic comments from > > at least one of the remaining OpenWrt devs; certainly it damaged my > > opinion of him (although the toxicity also damaged my opinion of a > > couple of LEDE folks too)). > Sigh... > > It's not as if LEDE offered the changes to OpenWrt and we voted > against them causing a split -- there was literally no discussion and > no warning prior to the public announcement. LEDE just suddenly > existed and the story quickly became that the reason for their > existence was because OpenWrt somehow prevented them from making > changes. At no point did OpenWrt veto changes or even have the option > to; the truth is that we agree changes need to be made. By not I guess part of the problem is that the LEDE team didn't believe that changes would actually be possible, because the toxic way in certain members interacted made reasonable discussion impossible (this is not a one-sided thing either IMO). Certain if transparency and greater community participation, and more opportunities for new blood to join, were adopted by OpenWrt, and a reasonable set of rules (i.e. not necessarily LEDE's rules) regarding who makes the decisions (e.g. I'm not sure I entirely buy LEDE's only committers should vote, if the goal is truly a greater community voice, although if committers are the only ones voting then I agree that it should be active committers, not just anyone who was at one time active; I think a notion of activity should include measure other that commits, however (I don't buy that the only thing that matters in an open source project is code commits)) Also a number of the other rules make sense, although I don't see that merger means that LEDE rules should necessarily be adopted as-is with no discussion. > including OpenWrt in the discussions LEDE ran afoul of their own > transparency leading to the false impression that OpenWrt was somehow > against the changes, causing a split in the community in terms of LEDE > vs OpenWrt with various amounts of hostility on the mailing lists. > None of this is healthy or constructive. That is largely my fault for expression my impressions that I had because of the toxic interactions between developers when I was on the private channel. I apologize for that, for all the good it will do (I don't know as there is anything I can do now to fix that). I would submit, however, that a solution to the toxicity is essential to any merger. Part of the reason I stepped down is that I wasn't helping matters because of personal issues (and have done it again more publicly now). I can't fix that, but I *can* point out that the the environment that creates this situation needs to be fixed. > > Let me be very clear: nobody on the OpenWrt side is against the > changes LEDE is trying to make. It is our position that this whole > thing is a misunderstanding and that the projects should attempt to > merge again. I have been trying to arrange talks between the two sides > but between work schedules, timezone conflicts and FUD regarding the > split it's been very difficult. > I would very much like to see openwrt and lede merge, but I know I'm not the calm voice that can make that happen. You and Hauke (for example) may be the calm heads that could make this happen, although it takes the more headstrong ones being willing to listen to you. Regards, Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From huynhminhdang at gmail.com Wed May 25 23:03:39 2016 From: huynhminhdang at gmail.com (Danng) Date: Thu, 26 May 2016 03:03:39 +0000 Subject: [OpenWrt-Devel] How to debug/config qos-scripts to work with OpenWRT AA? Message-ID: Hello, I am trying to use qos-scripts in OpenWRT AA. I have an issue that the qos-scripts can limit uplink speed but not downlink speed. For example: I set 128kbit uplink and 1024kbit downlink, however, the downlink is limitless This is the speedtest I captured http://speedof.me/show.php?img=160526022701-7038.png - uplink can go up to 104kbps - downlink can go up to 7861kbps (which is higher than the limitation I set) --- I also tried with wshaper and the got same result. Here is my setup: - eth1 is the WAN port - eth0 is connect to my PC - OpenWRT AA - Linux kernel 3.3.8 **************************************************************************** * cmd: cat /etc/config/qos **************************************************************************** # QoS configuration for OpenWrt # INTERFACES: config interface wan option classgroup "Default" option enabled 1 option upload 128 option download 1024 # RULES: config classify option target "Priority" option ports "22,53" option comment "ssh, dns" config classify option target "Normal" option proto "tcp" option ports "20,21,25,80,110,443,993,995" option comment "ftp, smtp, http(s), imap" config classify option target "Express" option ports "5190" option comment "AOL, iChat, ICQ" config default option target "Express" option proto "udp" option pktsize "-500" config reclassify option target "Priority" option proto "icmp" config default option target "Bulk" option portrange "1024-65535" # Don't change the stuff below unless you # really know what it means :) config classgroup "Default" option classes "Priority Express Normal Bulk" option default "Normal" config class "Priority" option packetsize 400 option avgrate 10 option priority 20 config class "Priority_down" option packetsize 1000 option avgrate 10 config class "Express" option packetsize 1000 option avgrate 50 option priority 10 config class "Normal" option packetsize 1500 option packetdelay 100 option avgrate 10 option priority 5 config class "Normal_down" option avgrate 20 config class "Bulk" option avgrate 1 option packetdelay 200 **************************************************************************** * cmd: /usr/lib/qos/generate.sh all **************************************************************************** | insmod cls_u32 >&- 2>&- | insmod em_u32 >&- 2>&- | insmod act_connmark >&- 2>&- | insmod act_mirred >&- 2>&- | insmod sch_ingress >&- 2>&- | insmod cls_fw >&- 2>&- | insmod sch_hfsc >&- 2>&- | insmod sch_fq_codel >&- 2>&- | ifconfig eth1 up txqueuelen 5 >&- 2>&- | tc qdisc del dev eth1 root >&- 2>&- | tc qdisc add dev eth1 root handle 1: hfsc default 30 | tc class add dev eth1 parent 1: classid 1:1 hfsc sc rate 128kbit ul rate 128kbit | tc class add dev eth1 parent 1:1 classid 1:10 hfsc rt m1 74kbit d 6103us m2 12kbit ls m1 74kbit d 6103us m2 71kbit ul rate 128kbit | tc class add dev eth1 parent 1:1 classid 1:20 hfsc rt m1 68kbit d 15258us m2 64kbit ls m1 68kbit d 15258us m2 35kbit ul rate 128kbit | tc class add dev eth1 parent 1:1 classid 1:30 hfsc ls m1 0kbit d 100000us m2 17kbit ul rate 128kbit | tc class add dev eth1 parent 1:1 classid 1:40 hfsc ls m1 0kbit d 200000us m2 3kbit ul rate 128kbit | tc qdisc add dev eth1 parent 1:10 handle 100: fq_codel | tc qdisc add dev eth1 parent 1:20 handle 200: fq_codel | tc qdisc add dev eth1 parent 1:30 handle 300: fq_codel | tc qdisc add dev eth1 parent 1:40 handle 400: fq_codel | tc filter add dev eth1 parent 1: prio 1 protocol ip handle 1/0xff fw flowid 1:10 | tc filter add dev eth1 parent 1: prio 2 protocol ip handle 2/0xff fw flowid 1:20 | tc filter add dev eth1 parent 1: prio 3 protocol ip handle 3/0xff fw flowid 1:30 | tc filter add dev eth1 parent 1: prio 4 protocol ip handle 4/0xff fw flowid 1:40 | ifconfig ifb0 up txqueuelen 5 >&- 2>&- | tc qdisc del dev ifb0 root >&- 2>&- | tc qdisc add dev ifb0 root handle 1: hfsc default 30 | tc class add dev ifb0 parent 1: classid 1:1 hfsc sc rate 1024kbit ul rate 1024kbit | tc qdisc del dev eth1 ingress >&- 2>&- | tc qdisc add dev eth1 ingress | tc filter add dev eth1 parent ffff: protocol ip prio 1 u32 match u32 0 0 flowid 1:1 action connmark action mirred egress redirect dev ifb0 | tc class add dev ifb0 parent 1:1 classid 1:10 hfsc rt m1 232kbit d 1907us m2 102kbit ls m1 232kbit d 1907us m2 568kbit ul rate 1024kbit | tc class add dev ifb0 parent 1:1 classid 1:20 hfsc rt m1 533kbit d 1907us m2 512kbit ls m1 533kbit d 1907us m2 284kbit ul rate 1024kbit | tc class add dev ifb0 parent 1:1 classid 1:30 hfsc ls m1 0kbit d 100000us m2 142kbit ul rate 1024kbit | tc class add dev ifb0 parent 1:1 classid 1:40 hfsc ls m1 0kbit d 200000us m2 28kbit ul rate 1024kbit | tc qdisc add dev ifb0 parent 1:10 handle 100: fq_codel | tc qdisc add dev ifb0 parent 1:20 handle 200: fq_codel | tc qdisc add dev ifb0 parent 1:30 handle 300: fq_codel | tc qdisc add dev ifb0 parent 1:40 handle 400: fq_codel | tc filter add dev ifb0 parent 1: prio 1 protocol ip handle 1/0xff fw flowid 1:10 | tc filter add dev ifb0 parent 1: prio 2 protocol ip handle 2/0xff fw flowid 1:20 | tc filter add dev ifb0 parent 1: prio 3 protocol ip handle 3/0xff fw flowid 1:30 | tc filter add dev ifb0 parent 1: prio 4 protocol ip handle 4/0xff fw flowid 1:40 | | | | iptables -t mangle -F qos_Default | iptables -t mangle -F qos_Default_ct | iptables -t mangle -D FORWARD -o eth1 -j qos_Default | iptables -t mangle -D OUTPUT -o eth1 -j qos_Default | iptables -t mangle -X qos_Default | iptables -t mangle -X qos_Default_ct | insmod ipt_multiport >&- 2>&- | insmod ipt_CONNMARK >&- 2>&- | insmod ipt_length >&- 2>&- | iptables -t mangle -N qos_Default >&- 2>&- | iptables -t mangle -N qos_Default_ct >&- 2>&- | iptables -t mangle -A qos_Default_ct -m mark --mark 0/0xff -m tcp -p tcp -m multiport --ports 22,53 -j MARK --set-mark 1/0xff | iptables -t mangle -A qos_Default_ct -m mark --mark 0/0xff -p udp -m udp -m multiport --ports 22,53 -j MARK --set-mark 1/0xff | iptables -t mangle -A qos_Default_ct -m mark --mark 0/0xff -p tcp -m tcp -m multiport --ports 20,21,25,80,110,443,993,995 -j MARK --set-mark 3/0xff | iptables -t mangle -A qos_Default_ct -m mark --mark 0/0xff -m tcp -p tcp -m multiport --ports 5190 -j MARK --set-mark 2/0xff | iptables -t mangle -A qos_Default_ct -m mark --mark 0/0xff -p udp -m udp -m multiport --ports 5190 -j MARK --set-mark 2/0xff | iptables -t mangle -A qos_Default_ct -j CONNMARK --save-mark --mask 0xff | iptables -t mangle -A qos_Default -j CONNMARK --restore-mark --mask 0xff | iptables -t mangle -A qos_Default -m mark --mark 0/0xff -j qos_Default_ct | iptables -t mangle -A qos_Default -m mark --mark 0/0xff -p udp -m length --length :500 -j MARK --set-mark 2/0xff | iptables -t mangle -A qos_Default -p icmp -j MARK --set-mark 1/0xff | iptables -t mangle -A qos_Default -m mark --mark 0/0xff -m tcp -p tcp --sport 1024:65535 --dport 1024:65535 -j MARK --set-mark 4/0xff | iptables -t mangle -A qos_Default -m mark --mark 0/0xff -p udp -m udp --sport 1024:65535 --dport 1024:65535 -j MARK --set-mark 4/0xff | iptables -t mangle -A OUTPUT -o eth1 -j qos_Default | iptables -t mangle -A FORWARD -o eth1 -j qos_Default \--------------------------------------------------------------------------- **************************************************************************** * cmd: iptables -L **************************************************************************** | Chain INPUT (policy ACCEPT) | target prot opt source destination | ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED | ACCEPT all -- anywhere anywhere | syn_flood tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN | input_rule all -- anywhere anywhere | input all -- anywhere anywhere | | Chain FORWARD (policy DROP) | target prot opt source destination | ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED | forwarding_rule all -- anywhere anywhere | forward all -- anywhere anywhere | reject all -- anywhere anywhere | | Chain OUTPUT (policy ACCEPT) | target prot opt source destination | ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED | ACCEPT all -- anywhere anywhere | output_rule all -- anywhere anywhere | output all -- anywhere anywhere | | Chain MINIUPNPD (1 references) | target prot opt source destination | | Chain forward (1 references) | target prot opt source destination | zone_lan_forward all -- anywhere anywhere | zone_wan_forward all -- anywhere anywhere | | Chain forwarding_lan (1 references) | target prot opt source destination | | Chain forwarding_rule (1 references) | target prot opt source destination | | Chain forwarding_wan (1 references) | target prot opt source destination | | Chain input (1 references) | target prot opt source destination | zone_lan all -- anywhere anywhere | zone_wan all -- anywhere anywhere | | Chain input_lan (1 references) | target prot opt source destination | | Chain input_rule (1 references) | target prot opt source destination | | Chain input_wan (1 references) | target prot opt source destination | | Chain output (1 references) | target prot opt source destination | zone_lan_ACCEPT all -- anywhere anywhere | zone_wan_ACCEPT all -- anywhere anywhere | | Chain output_rule (1 references) | target prot opt source destination | | Chain reject (5 references) | target prot opt source destination | REJECT tcp -- anywhere anywhere reject-with tcp-reset | REJECT all -- anywhere anywhere reject-with icmp-port-unreachable | | Chain syn_flood (1 references) | target prot opt source destination | RETURN tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN limit: avg 25/sec burst 50 | DROP all -- anywhere anywhere | | Chain zone_lan (1 references) | target prot opt source destination | input_lan all -- anywhere anywhere | zone_lan_ACCEPT all -- anywhere anywhere | | Chain zone_lan_ACCEPT (2 references) | target prot opt source destination | ACCEPT all -- anywhere anywhere | ACCEPT all -- anywhere anywhere | | Chain zone_lan_DROP (0 references) | target prot opt source destination | DROP all -- anywhere anywhere | DROP all -- anywhere anywhere | | Chain zone_lan_REJECT (1 references) | target prot opt source destination | reject all -- anywhere anywhere | reject all -- anywhere anywhere | | Chain zone_lan_forward (1 references) | target prot opt source destination | zone_wan_ACCEPT all -- anywhere anywhere | forwarding_lan all -- anywhere anywhere | zone_lan_REJECT all -- anywhere anywhere | | Chain zone_wan (1 references) | target prot opt source destination | ACCEPT udp -- anywhere anywhere udp dpt:bootpc | ACCEPT icmp -- anywhere anywhere icmp echo-request | input_wan all -- anywhere anywhere | zone_wan_REJECT all -- anywhere anywhere | | Chain zone_wan_ACCEPT (2 references) | target prot opt source destination | ACCEPT all -- anywhere anywhere | ACCEPT all -- anywhere anywhere | | Chain zone_wan_DROP (0 references) | target prot opt source destination | DROP all -- anywhere anywhere | DROP all -- anywhere anywhere | | Chain zone_wan_REJECT (2 references) | target prot opt source destination | reject all -- anywhere anywhere | reject all -- anywhere anywhere | | Chain zone_wan_forward (1 references) | target prot opt source destination | MINIUPNPD all -- anywhere anywhere | forwarding_wan all -- anywhere anywhere | zone_wan_REJECT all -- anywhere anywhere \--------------------------------------------------------------------------- **************************************************************************** * cmd: iptables -t nat -L **************************************************************************** | Chain PREROUTING (policy ACCEPT) | target prot opt source destination | prerouting_rule all -- anywhere anywhere | zone_lan_prerouting all -- anywhere anywhere | zone_wan_prerouting all -- anywhere anywhere | | Chain INPUT (policy ACCEPT) | target prot opt source destination | | Chain OUTPUT (policy ACCEPT) | target prot opt source destination | | Chain POSTROUTING (policy ACCEPT) | target prot opt source destination | postrouting_rule all -- anywhere anywhere | zone_lan_nat all -- anywhere anywhere | zone_wan_nat all -- anywhere anywhere | | Chain MINIUPNPD (1 references) | target prot opt source destination | | Chain postrouting_rule (1 references) | target prot opt source destination | | Chain prerouting_lan (1 references) | target prot opt source destination | | Chain prerouting_rule (1 references) | target prot opt source destination | | Chain prerouting_wan (1 references) | target prot opt source destination | | Chain zone_lan_nat (1 references) | target prot opt source destination | | Chain zone_lan_prerouting (1 references) | target prot opt source destination | prerouting_lan all -- anywhere anywhere | | Chain zone_wan_nat (1 references) | target prot opt source destination | MASQUERADE all -- anywhere anywhere | | Chain zone_wan_prerouting (1 references) | target prot opt source destination | MINIUPNPD all -- anywhere anywhere | prerouting_wan all -- anywhere anywhere \--------------------------------------------------------------------------- **************************************************************************** * cmd: iptables -t mangle -L **************************************************************************** | Chain PREROUTING (policy ACCEPT) | target prot opt source destination | | Chain INPUT (policy ACCEPT) | target prot opt source destination | | Chain FORWARD (policy ACCEPT) | target prot opt source destination | zone_wan_MSSFIX all -- anywhere anywhere | qos_Default all -- anywhere anywhere | | Chain OUTPUT (policy ACCEPT) | target prot opt source destination | qos_Default all -- anywhere anywhere | | Chain POSTROUTING (policy ACCEPT) | target prot opt source destination | | Chain qos_Default (2 references) | target prot opt source destination | CONNMARK all -- anywhere anywhere CONNMARK restore mask 0xff | qos_Default_ct all -- anywhere anywhere mark match 0x0/0xff | MARK udp -- anywhere anywhere mark match 0x0/0xff length 0:500 MARK xset 0x2/0xff | MARK icmp -- anywhere anywhere MARK xset 0x1/0xff | MARK tcp -- anywhere anywhere mark match 0x0/0xff tcp spts:1024:65535 dpts:1024:65535 MARK xset 0x4/0xff | MARK udp -- anywhere anywhere mark match 0x0/0xff udp spts:1024:65535 dpts:1024:65535 MARK xset 0x4/0xff | | Chain qos_Default_ct (1 references) | target prot opt source destination | MARK tcp -- anywhere anywhere mark match 0x0/0xff tcp multiport ports ssh,domain MARK xset 0x1/0xff | MARK udp -- anywhere anywhere mark match 0x0/0xff udp multiport ports ssh,domain MARK xset 0x1/0xff | MARK tcp -- anywhere anywhere mark match 0x0/0xff tcp multiport ports ftp-data,ftp,smtp,www,pop3,https,imaps,pop3s MARK xset 0x3/0xff | MARK tcp -- anywhere anywhere mark match 0x0/0xff tcp multiport ports 5190 MARK xset 0x2/0xff | MARK udp -- anywhere anywhere mark match 0x0/0xff udp multiport ports 5190 MARK xset 0x2/0xff | CONNMARK all -- anywhere anywhere CONNMARK save mask 0xff | | Chain zone_wan_MSSFIX (1 references) | target prot opt source destination | TCPMSS tcp -- anywhere anywhere tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU \--------------------------------------------------------------------------- **************************************************************************** * cmd: tc -s qdisc show dev eth0 **************************************************************************** | qdisc pfifo_fast 0: root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 | Sent 278256856 bytes 260097 pkt (dropped 0, overlimits 0 requeues 0) | backlog 0b 0p requeues 0 \--------------------------------------------------------------------------- **************************************************************************** * cmd: tc -s qdisc show dev eth1 **************************************************************************** | qdisc hfsc 1: root refcnt 2 default 30 | Sent 1447188 bytes 7376 pkt (dropped 0, overlimits 12468 requeues 0) | backlog 0b 0p requeues 0 | qdisc fq_codel 100: parent 1:10 limit 10240p flows 1024 quantum 1518 target 5.0ms interval 100.0ms ecn | Sent 5000 bytes 55 pkt (dropped 0, overlimits 0 requeues 0) | backlog 0b 0p requeues 0 | maxpacket 256 drop_overlimit 0 new_flow_count 27 ecn_mark 0 | new_flows_len 1 old_flows_len 0 | qdisc fq_codel 200: parent 1:20 limit 10240p flows 1024 quantum 1518 target 5.0ms interval 100.0ms ecn | Sent 19246 bytes 145 pkt (dropped 0, overlimits 0 requeues 0) | backlog 0b 0p requeues 0 | maxpacket 350 drop_overlimit 0 new_flow_count 80 ecn_mark 0 | new_flows_len 0 old_flows_len 2 | qdisc fq_codel 300: parent 1:30 limit 10240p flows 1024 quantum 1518 target 5.0ms interval 100.0ms ecn | Sent 720529 bytes 2687 pkt (dropped 223, overlimits 0 requeues 0) | backlog 0b 0p requeues 0 | maxpacket 1514 drop_overlimit 0 new_flow_count 750 ecn_mark 0 | new_flows_len 1 old_flows_len 5 | qdisc fq_codel 400: parent 1:40 limit 10240p flows 1024 quantum 1518 target 5.0ms interval 100.0ms ecn | Sent 702413 bytes 4489 pkt (dropped 1461, overlimits 0 requeues 0) | backlog 0b 0p requeues 0 | maxpacket 1514 drop_overlimit 0 new_flow_count 271 ecn_mark 0 | new_flows_len 0 old_flows_len 1 | qdisc ingress ffff: parent ffff:fff1 ---------------- | Sent 1639987 bytes 3843 pkt (dropped 0, overlimits 0 requeues 0) | backlog 0b 0p requeues 0 \--------------------------------------------------------------------------- **************************************************************************** * cmd: tc -s qdisc show dev ifb0 **************************************************************************** | qdisc hfsc 1: root refcnt 2 default 30 | Sent 1391951 bytes 2762 pkt (dropped 0, overlimits 2001 requeues 0) | backlog 0b 0p requeues 0 | qdisc fq_codel 100: parent 1:10 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn | Sent 4723 bytes 23 pkt (dropped 0, overlimits 0 requeues 0) | backlog 0b 0p requeues 0 | maxpacket 299 drop_overlimit 0 new_flow_count 21 ecn_mark 0 | new_flows_len 1 old_flows_len 0 | qdisc fq_codel 200: parent 1:20 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn | Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) | backlog 0b 0p requeues 0 | maxpacket 256 drop_overlimit 0 new_flow_count 0 ecn_mark 0 | new_flows_len 0 old_flows_len 0 | qdisc fq_codel 300: parent 1:30 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn | Sent 1387228 bytes 2739 pkt (dropped 127, overlimits 0 requeues 0) | backlog 0b 0p requeues 0 | maxpacket 1518 drop_overlimit 0 new_flow_count 1052 ecn_mark 0 | new_flows_len 1 old_flows_len 1 | qdisc fq_codel 400: parent 1:40 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn | Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) | backlog 0b 0p requeues 0 | maxpacket 256 drop_overlimit 0 new_flow_count 0 ecn_mark 0 | new_flows_len 0 old_flows_len 0 \--------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Wed May 25 23:49:02 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Wed, 25 May 2016 23:49:02 -0400 Subject: [OpenWrt-Devel] Transparency and discussion of merge openwrt and lede Message-ID: <1464234542.1239.304.camel@homehost> Hi, Might I humbly submit that given the different timezone and the fact that LEDE claims to be wanting to be transparent, and that remaining OpenWrt claims to be willing to accept such policies, that Jow's suggestion of doing the discussion openly on the openwrt-devel and lede-dev mailings lists is what makes the most sense? If you're worried that things could get nasty perhaps, at least for this discussion, both sides could agree to adopt something like the tool I created for myself to help me control my own tendency to hasty, hotheaded, and generally unhelpful or noisy emails, so that if one has a tendency to drop the gloves that one has a chance to rethink what they've said after a cooling off period? If a .rpm would help, I'll make time to build version of the package for .rpm distros too. Regards, Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Thu May 26 01:47:11 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Thu, 26 May 2016 01:47:11 -0400 Subject: [OpenWrt-Devel] I've come round to your way of thinking In-Reply-To: <20160521094013.GA2116@ugly.lan> References: <9967a18a-90bd-6ed8-7978-23f84e890098@mein.io> <87mvnmw6w9.fsf@nemi.mork.no> <358a2d9c-3fa3-b81d-879b-e97c1fc2c6f1@phrozen.org> <87inyaw4r7.fsf@nemi.mork.no> <20160519220955.GB31062@ugly.lan> <438e58d0-6094-029c-5a12-5d98615c9471@mein.io> <20160521094013.GA2116@ugly.lan> Message-ID: <1464241631.1239.314.camel@homehost> Sorry sent from the wrong email address, not sure where it it actually got posted and where not. Hi Oswald, I'm sorry I suggested you were an unrealistic idealogue, and for questioning your credentials; while I haven't verified them I'm sure you do have more experience than I gave you credit for, despite how overly strong you come into this discussion. With the creation of the tool I created for myself that gets in-between me and posting email (requiring me to confirm I really want to send it after cooling off period), I think that the kinds of discussion of David Lang (and I agreed) were to volatile to have publicly ought to be able to kept to reasonable level, even with hotheads like myself, John, and Imre, who need tools not just an admonition to think before (or even knowing one has an issue it not entering our thoughts when we are posting). In fact I'd argue with such a mechanism, for folks like me and them a public email discussion is *preferable* to an IRC discussion (which I've seen frequently turn toxic in their and other cases), especially a private one. Regards, daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From oswald.buddenhagen at gmx.de Thu May 26 03:48:06 2016 From: oswald.buddenhagen at gmx.de (Oswald Buddenhagen) Date: Thu, 26 May 2016 09:48:06 +0200 Subject: [OpenWrt-Devel] I've come round to your way of thinking In-Reply-To: <1464237522.1239.313.camel@homehost> References: <87mvnmw6w9.fsf@nemi.mork.no> <358a2d9c-3fa3-b81d-879b-e97c1fc2c6f1@phrozen.org> <87inyaw4r7.fsf@nemi.mork.no> <20160519220955.GB31062@ugly.lan> <438e58d0-6094-029c-5a12-5d98615c9471@mein.io> <20160521094013.GA2116@ugly.lan> <1464237522.1239.313.camel@homehost> Message-ID: <20160526074806.GA12640@ugly.lan> On Thu, May 26, 2016 at 12:38:42AM -0400, Daniel Curran-Dickinson wrote: > I'm sorry [...] > no worries. :) > despite how overly strong you come into this discussion. > yeah, i'm known for being not exactly the greatest diplomat. :} _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From jo at mein.io Thu May 26 05:29:48 2016 From: jo at mein.io (Jo-Philipp Wich) Date: Thu, 26 May 2016 11:29:48 +0200 Subject: [OpenWrt-Devel] [OT] Implemented: not an ML erase button but at least a rethink switch In-Reply-To: <1464148463.1239.200.camel@homehost> References: <1464148463.1239.200.camel@homehost> Message-ID: <88eada1b-566f-4053-4950-ec1dbb73bdd9@mein.io> Hi Daniel, hope you're doing well nowadays. I sincerely appreciate your participation in the discussions surrounding the whole OpenWrt/LEDE topic especially since it helps giving another, outside perspective to the entire issue. What I noticed is that you're sometimes generating like 80% of the traffic in a thread and I wonder if that scares people away from participating in the discussion... Personally I wrote longish mails attempting to explain my motivation more than once but never actually sent those, mainly because I did not want to let the discussion derail into a he-said-she-said kind of public dirty laundry washing. Disagreements with OpenWrt where not always about toxic discussions but also due to a great passiveness and uneven distribution of work among the so called core members. Just take a look at the current project activity and make your own conclusions... So what am I trying to say... never write a mail in anger and give things time to cool off :) What works for me is keeping my drafts in the mail box and reading them on the next day, which more then once led me to the conclusion that it was better to not send it in the first place. Regards, Jo _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From jo at mein.io Thu May 26 07:43:45 2016 From: jo at mein.io (Jo-Philipp Wich) Date: Thu, 26 May 2016 13:43:45 +0200 Subject: [OpenWrt-Devel] OpenWrt / LEDE In-Reply-To: <5744BA04.9000009@hauke-m.de> References: <5744BA04.9000009@hauke-m.de> Message-ID: Hi all, I think the status quo has now been described several times and can be summarized as: - Launching the new LEDE project/fork/reboot without discussing matters in advance with the developers not being involved was perceived in a hostile action damaging OpenWrt - It has been claimed that any changes implemented by LEDE can be likewise implemented in OpenWrt as well, obviously not 100% identically without prior discussion but at least in a way keeping original intents and spirits - Both sides expressed the wish to reunite on several occasions I very much apologize for the huge surprise the LEDE project has been to you and I do regret the fact that we didn't discuss it earlier with you guys. Some of us got caught in the belief that building a new, shiny sandpit according to our liking would be the better course of action compared to drastically changing OpenWrt for something not guaranteed to work in the long run. That being said I still think that LEDE already is a success, at least in my personal perception. When I mention "we" here I mean all the people having participated in LEDE, regardless of affiliation or agenda. Notable points are: - We managed to figure out workflows supporting both mailing-list / patchwork-driven development and a more contributor oriented pull request model - We figured out how to have a linear history without resorting to limiting ourselves to svn now (which was the sole argument for keeping it btw.) - We reworked the buildbots to be more efficient - We managed to quickly acquire donations, specifically regarding mirror space and build bot capacity - We based the web page on a Git repo and mirrored that to Github in order to let people contribute - We attempted to do everything publically [since the LEDE announcemnt] and retroactively published communication regarding the project implementation - We have between three to four people per server having root access, with at least one person not being affiliated with "the cabal" On the other hand we didn't yet manage to: - Clearly communicate our past and future intents upfront and after the fact - Start a proper discussion with OpenWrt regarding the future direction of both projects - Untangle the infrastructure (wiki.openwrt.org, dev.openwrt.org, git.openwrt.org) The weak effort on both sides in talking about both projects future direction paralyzed progress for all of us and in the associated communities so I'd very much like to reach at least some agreement or definitive decision soon. In order to underline my honest intention I'd like to give up maintenance of the OpenWrt wiki and hand the data / SSH access over to you guys so that you can migrate / maintain / rework it as you deem fitting. We're also still in possession of the secret build key for the CC release used to sign the package repositories. I'd be glad to throw it over the fence and assist you with using my package rebuild scripts to push security updates. Please tell me a contact and I'll provide the person with suitable access. I also still have root access to dev.openwrt.org hosting the Trac, though you could reach out to Mirko as well to get access to the system. Luka mentioned that OpenWrt plans to move to Github, we'd be very happy if we could spare you the conversion work - we have a cleanly converted repository available at https://git.lede-project.org/openwrt/source.git which you could use as starting point for future developments - that repository maps the historic SVN and CVS branch/tag structure as good as possible to proper Git branches and tags. I also took some care in converting svn committer nicknames to proper authors. We did equivalent conversions for the old packages and old feeds svn repositories in https://git.lede-project.org/openwrt/packages.git and https://git.lede-project.org/openwrt/feeds.git . Finally I'd like to hand over my non-root access to the OpenWrt buildmaster which I'd hand over to interested OpenWrt people. I took over maintenance for some time because Travis has been rather busy with real life these days. If there is truly some interest among the remaining OpenWrt folks to reunite while adopting the visions and working modes of LEDE then please speak up and tell us about your demands. Best wishes, Jo _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From kathy.giori at gmail.com Thu May 26 13:15:31 2016 From: kathy.giori at gmail.com (Kathy Giori) Date: Thu, 26 May 2016 10:15:31 -0700 Subject: [OpenWrt-Devel] OpenWrt / LEDE In-Reply-To: References: <5744BA04.9000009@hauke-m.de> Message-ID: On Thu, May 26, 2016 at 4:43 AM, Jo-Philipp Wich wrote: > Hi all, > > I think the status quo has now been described several times and can be > summarized as: > > - Launching the new LEDE project/fork/reboot without discussing > matters in advance with the developers not being involved was > perceived in a hostile action damaging OpenWrt > > - It has been claimed that any changes implemented by LEDE can be > likewise implemented in OpenWrt as well, obviously not 100% > identically without prior discussion but at least in a way keeping > original intents and spirits > > - Both sides expressed the wish to reunite on several occasions > > I very much apologize for the huge surprise the LEDE project has been > to you and I do regret the fact that we didn't discuss it earlier with > you guys. Some of us got caught in the belief that building a new, > shiny sandpit according to our liking would be the better course of > action compared to drastically changing OpenWrt for something not > guaranteed to work in the long run. > > That being said I still think that LEDE already is a success, at least > in my personal perception. When I mention "we" here I mean all the > people having participated in LEDE, regardless of affiliation or agenda. > > Notable points are: > > - We managed to figure out workflows supporting both mailing-list / > patchwork-driven development and a more contributor oriented pull > request model > > - We figured out how to have a linear history without resorting to > limiting ourselves to svn now (which was the sole argument for > keeping it btw.) > > - We reworked the buildbots to be more efficient > > - We managed to quickly acquire donations, specifically regarding > mirror space and build bot capacity > > - We based the web page on a Git repo and mirrored that to Github > in order to let people contribute > > - We attempted to do everything publically [since the LEDE announcemnt] > and retroactively published communication regarding the project > implementation > > - We have between three to four people per server having root access, > with at least one person not being affiliated with "the cabal" > > On the other hand we didn't yet manage to: > > - Clearly communicate our past and future intents upfront and after > the fact > > - Start a proper discussion with OpenWrt regarding the future direction > of both projects > > - Untangle the infrastructure (wiki.openwrt.org, dev.openwrt.org, > git.openwrt.org) > > > The weak effort on both sides in talking about both projects future > direction paralyzed progress for all of us and in the associated > communities so I'd very much like to reach at least some agreement or > definitive decision soon. > > In order to underline my honest intention I'd like to give up > maintenance of the OpenWrt wiki and hand the data / SSH access over to > you guys so that you can migrate / maintain / rework it as you deem > fitting. > > We're also still in possession of the secret build key for the CC > release used to sign the package repositories. I'd be glad to throw it > over the fence and assist you with using my package rebuild scripts to > push security updates. > > Please tell me a contact and I'll provide the person with suitable > access. > > I also still have root access to dev.openwrt.org hosting the Trac, > though you could reach out to Mirko as well to get access to the system. > > Luka mentioned that OpenWrt plans to move to Github, we'd be very happy > if we could spare you the conversion work - we have a cleanly converted > repository available at https://git.lede-project.org/openwrt/source.git > which you could use as starting point for future developments - that > repository maps the historic SVN and CVS branch/tag structure as good > as possible to proper Git branches and tags. I also took some care in > converting svn committer nicknames to proper authors. > > We did equivalent conversions for the old packages and old feeds svn > repositories in https://git.lede-project.org/openwrt/packages.git and > https://git.lede-project.org/openwrt/feeds.git . > > Finally I'd like to hand over my non-root access to the OpenWrt > buildmaster which I'd hand over to interested OpenWrt people. I took > over maintenance for some time because Travis has been rather busy with > real life these days. > > If there is truly some interest among the remaining OpenWrt folks to > reunite while adopting the visions and working modes of LEDE then > please speak up and tell us about your demands. > > > Best wishes, > Jo Jo, I appreciate your well-written summary and the notable improvements. Moving to git and keeping history, improving the web site and documentation to enable more collaboration, making workflows more efficient and open, etc. had been discussed during face-to-face gatherings of OpenWrt core + industry, at ELCE events over the past couple years. I got involved as a liaison from the perspective of the prpl Foundation with the core objective of improving OpenWrt, and setting up the workflow so that more of industry developers could both use and contribute to it. Bravo on fulfilling some of the topics that had only been talked about for some time -- that's a big help. I really hope you all can bring these enhancements together and go back to working on one project. From a marketing/communications standpoint, I'd suggest keeping the OpenWrt project name. It is highly recognized and probably only a slim fraction of "users" (people and companies who download and reflash their routers) will have heard of LEDE. Regarding the unfinished business to "Start a proper discussion with OpenWrt...", I have my fingers crossed that you can resolve any remaining differences. Are there any LEDE objectives, rules, processes, or whatever that you think are still controversial? If so, reach out directly to whomever disagrees and start talking. Or go through Mike Baker to facilitate a dialog. In summary, I like the enhancements made and the idea of hosting OpenWrt development on github and bringing everyone back together, but I don't like the idea of changing the well-established name of OpenWrt to LEDE. kathy _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From fhfrediani at gmail.com Thu May 26 13:34:48 2016 From: fhfrediani at gmail.com (Fernando Frediani) Date: Thu, 26 May 2016 14:34:48 -0300 Subject: [OpenWrt-Devel] OpenWrt / LEDE In-Reply-To: References: <5744BA04.9000009@hauke-m.de> Message-ID: Wow. What a great email !!! OpenWrt core people who have decided to stay with the project think carefully about it. In my humble vision reunite with LEDE new ideas and keeping the well stabilished OpenWrt name is the ideal scenario. Put aside the diferences and makd an effort for this to happen. Fernando On 26 May 2016 08:43, "Jo-Philipp Wich" wrote: > Hi all, > > I think the status quo has now been described several times and can be > summarized as: > > - Launching the new LEDE project/fork/reboot without discussing > matters in advance with the developers not being involved was > perceived in a hostile action damaging OpenWrt > > - It has been claimed that any changes implemented by LEDE can be > likewise implemented in OpenWrt as well, obviously not 100% > identically without prior discussion but at least in a way keeping > original intents and spirits > > - Both sides expressed the wish to reunite on several occasions > > I very much apologize for the huge surprise the LEDE project has been > to you and I do regret the fact that we didn't discuss it earlier with > you guys. Some of us got caught in the belief that building a new, > shiny sandpit according to our liking would be the better course of > action compared to drastically changing OpenWrt for something not > guaranteed to work in the long run. > > That being said I still think that LEDE already is a success, at least > in my personal perception. When I mention "we" here I mean all the > people having participated in LEDE, regardless of affiliation or agenda. > > Notable points are: > > - We managed to figure out workflows supporting both mailing-list / > patchwork-driven development and a more contributor oriented pull > request model > > - We figured out how to have a linear history without resorting to > limiting ourselves to svn now (which was the sole argument for > keeping it btw.) > > - We reworked the buildbots to be more efficient > > - We managed to quickly acquire donations, specifically regarding > mirror space and build bot capacity > > - We based the web page on a Git repo and mirrored that to Github > in order to let people contribute > > - We attempted to do everything publically [since the LEDE announcemnt] > and retroactively published communication regarding the project > implementation > > - We have between three to four people per server having root access, > with at least one person not being affiliated with "the cabal" > > On the other hand we didn't yet manage to: > > - Clearly communicate our past and future intents upfront and after > the fact > > - Start a proper discussion with OpenWrt regarding the future direction > of both projects > > - Untangle the infrastructure (wiki.openwrt.org, dev.openwrt.org, > git.openwrt.org) > > > The weak effort on both sides in talking about both projects future > direction paralyzed progress for all of us and in the associated > communities so I'd very much like to reach at least some agreement or > definitive decision soon. > > In order to underline my honest intention I'd like to give up > maintenance of the OpenWrt wiki and hand the data / SSH access over to > you guys so that you can migrate / maintain / rework it as you deem > fitting. > > We're also still in possession of the secret build key for the CC > release used to sign the package repositories. I'd be glad to throw it > over the fence and assist you with using my package rebuild scripts to > push security updates. > > Please tell me a contact and I'll provide the person with suitable > access. > > I also still have root access to dev.openwrt.org hosting the Trac, > though you could reach out to Mirko as well to get access to the system. > > Luka mentioned that OpenWrt plans to move to Github, we'd be very happy > if we could spare you the conversion work - we have a cleanly converted > repository available at https://git.lede-project.org/openwrt/source.git > which you could use as starting point for future developments - that > repository maps the historic SVN and CVS branch/tag structure as good > as possible to proper Git branches and tags. I also took some care in > converting svn committer nicknames to proper authors. > > We did equivalent conversions for the old packages and old feeds svn > repositories in https://git.lede-project.org/openwrt/packages.git and > https://git.lede-project.org/openwrt/feeds.git . > > Finally I'd like to hand over my non-root access to the OpenWrt > buildmaster which I'd hand over to interested OpenWrt people. I took > over maintenance for some time because Travis has been rather busy with > real life these days. > > If there is truly some interest among the remaining OpenWrt folks to > reunite while adopting the visions and working modes of LEDE then > please speak up and tell us about your demands. > > > Best wishes, > Jo > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From jo at mein.io Thu May 26 14:07:35 2016 From: jo at mein.io (Jo-Philipp Wich) Date: Thu, 26 May 2016 20:07:35 +0200 Subject: [OpenWrt-Devel] OpenWrt / LEDE In-Reply-To: References: <5744BA04.9000009@hauke-m.de> Message-ID: <3604ac34-d16c-320c-b21e-91a46432a567@mein.io> Dear Kathy, > I appreciate your well-written summary and the notable improvements. > Moving to git and keeping history, improving the web site and > documentation to enable more collaboration, making workflows more > efficient and open, etc. had been discussed during face-to-face > gatherings of OpenWrt core + industry, at ELCE events over the past > couple years. I would've considered myself "core" yet I've never attended ELCE (too expensive for me) or any face to face meeting and I don't recall any meeting contents being discussed en detail among the other core developers which, in my opinion, underlines the nature of the internal communication troubles plaguing OpenWrt. The only thing I remember was Steven writing a short summary about the topics discussed at the last OpenWrt summit. I have no problem with not being able to attend conferences and I have no problem with other developers maintaining industry relations, neither do I object industry investment into OpenWrt but what I do mind is the fact that, I, as "core developer", have to actively seek for the things happening between OpenWrt and external entities and to find things myself you apparently talked about with some developers in the past already. > I got involved as a liaison from the perspective of the > prpl Foundation with the core objective of improving OpenWrt, and > setting up the workflow so that more of industry developers could both > use and contribute to it. Maybe I should've paid more attention to your past actions, maybe others should've spoken upfront about their agreements with industry partners, maybe I was just too careless - I don't know. In any case it seems that LEDE was implementing things you've envisioned long ago which I regard as a confirmation of our ideas. > Bravo on fulfilling some of the topics that > had only been talked about for some time -- that's a big help. I do not know who was attending which meetings and which topics have been talked about on whose behalf and what promises have been made there but what I did notice was that little effort has been put into bringing the project forward during the last five years at least. With effort I do not mean things you can quantify in terms of lines of code or commit count but the general work being done to shape the project at all which includes, among other topics, the willingness to get external help for infrastructural matters, to give up control, to adopt new ideas and to accept work done by volunteers to e.g. rework the home page, to interact with the community or to actually merge contributions. > I really hope you all can bring these enhancements together and go > back to working on one project. From a marketing/communications > standpoint, I'd suggest keeping the OpenWrt project name. It is highly > recognized and probably only a slim fraction of "users" (people and > companies who download and reflash their routers) will have heard of > LEDE. I still do hope that there might be a way to rejoin the projects and time will tell if it is going to work out. That is, however, not my decision to make but something all involved people should be comfortable with. > Regarding the unfinished business to "Start a proper discussion with > OpenWrt...", I have my fingers crossed that you can resolve any > remaining differences. Are there any LEDE objectives, rules, > processes, or whatever that you think are still controversial? I don't know, this is why we attempt to get a discussion started to figure out if OpenWrt is willing to work under the new objectives and what LEDE can do to make this happen. > If so, reach out directly to whomever disagrees and start talking. Or go > through Mike Baker to facilitate a dialog. This is what we're trying to do - since Haukes previous attempt at staging an IRC meeting failed I proposed to take matters to the list since I regard an IRC chat to be an unsuitable medium for having such a rather long running discussion. The time constraints and timezone differences encourage preliminary, not well-thought responses which - in my opinion - outweighs the benefit of having a real time conversation. I do not want to go through specific persons using private communication in order to facilitate a dialog and frankly, I don't see a reason why I would need to. As you might've noticed, we've been very careful to not point fingers at anyone and when I raise certain concerns over previous mishaps I am certainly not excluding myself. > In summary, I like the enhancements made and the idea of hosting > OpenWrt development on github and bringing everyone back together, but > I don't like the idea of changing the well-established name of OpenWrt > to LEDE. I am very happy to hear that you endorse our ideas regarding the mode of development. We agree that OpenWrt is a valuable trademark but a trademark without a good product backing it becomes worthless eventually. Thanks for understanding, Jo-Philipp _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From openwrt at daniel.thecshore.com Thu May 26 16:02:06 2016 From: openwrt at daniel.thecshore.com (Daniel Dickinson) Date: Thu, 26 May 2016 16:02:06 -0400 Subject: [OpenWrt-Devel] [OT] Implemented: not an ML erase button but at least a rethink switch In-Reply-To: <88eada1b-566f-4053-4950-ec1dbb73bdd9@mein.io> References: <1464148463.1239.200.camel@homehost> <88eada1b-566f-4053-4950-ec1dbb73bdd9@mein.io> Message-ID: <1464292926.1239.350.camel@homehost> On Thu, 2016-05-26 at 11:29 +0200, Jo-Philipp Wich wrote: > Hi Daniel, > > hope you're doing well nowadays. > > I sincerely appreciate your participation in the discussions surrounding > the whole OpenWrt/LEDE topic especially since it helps giving another, > outside perspective to the entire issue. > > What I noticed is that you're sometimes generating like 80% of the > traffic in a thread and I wonder if that scares people away from > participating in the discussion... Someone else told me that too and it's yet another reason / thing to keep in mind for my verify-before-send thing. I'm *trying* to improve and prodding me in the right direction in a non-hostile manner is *very* appreciated. > Disagreements with OpenWrt where not always about toxic discussions but > also due to a great passiveness and uneven distribution of work among > the so called core members. Just take a look at the current project > activity and make your own conclusions... Thanks. This is part of my tendency to 'glass-is-half-empty' pessimism/negativity. That's a harder thing to change than unwise posts, now that I have a tool to help me with the former. > So what am I trying to say... never write a mail in anger and give > things time to cool off :) > > What works for me is keeping my drafts in the mail box and reading them > on the next day, which more then once led me to the conclusion that it > was better to not send it in the first place. Exactly the reason I implmented the tool (know what I should do unfortunately tends not to enter my thoughts in the heat of the moment, so I need something that helps me do the right thing). If you have a broken leg you use a crutch and cast, and it's not a bad thing; same goes for dealing with one's thinking and habits. Regards, Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From st3fanp3t3r at gmail.com Thu May 26 16:23:25 2016 From: st3fanp3t3r at gmail.com (Stefan Peter) Date: Thu, 26 May 2016 22:23:25 +0200 Subject: [OpenWrt-Devel] OpenWrt / LEDE In-Reply-To: References: <5744BA04.9000009@hauke-m.de> Message-ID: <57475B3D.3010307@gmail.com> Dear Jo-Philipp Wich On 26.05.2016 13:43, Jo-Philipp Wich wrote: > Hi all, > > I think the status quo has now been described several times and can be > summarized as: ... I'm just a lurker on this list but this is exactly the kind of email I have missed in the past. I have no moral right to comment on the points you have brought up, but bringing them up transparently on the public mailing list for every developer/fanboy/contributor/lurker/.. to comment on is what has been missing from the OpenWrt project up to now, IMHO. I really hope that you will get lots and lots of replies to your message. And, yes, these replies may point in every direction possible and the will contradict each other and some will be out of tune (like mine). But if you get the feeling of what the community at large thinks about the issues you brought up, it was worth it. And I am sure that the community will thank you for their opportunity to be heard by supporting you even if the outcome of the issue in question was not in their favour. And please, the next time you'd like to go to an OpenWrt/LEDE related event and feel that you can not afford it, do speak up. I'm sure that I'm not the only one being able to toss in a couple of bucks into the hat for such a thing. Getting to know the other devs face to face, having a beer (or two) and then, later, being able to attach a face (and hopefully fond memories) to an email address has proven to be invaluable for me in my job. Knowing people face to face can make the difference between confrontation and compromise. So, back to lurker mode for me. With kind regards Stefan Peter _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From Jos.Delbar at technicolor.com Thu May 26 19:48:42 2016 From: Jos.Delbar at technicolor.com (Delbar Jos) Date: Thu, 26 May 2016 23:48:42 +0000 Subject: [OpenWrt-Devel] TR-069 for OpenWrt Message-ID: Hi all, At Technicolor we have followed with great interest the recent proposals to enhance OpenWrt with an open source solution for TR-069 remote management. As one of the world's largest vendors of modems and routers for carrier applications, making use of OpenWrt in a significant share of our install base, we want to support this initiative in a meaningful way. Concretely, we are willing to open source Technicolor's in-house TR-069 solution and thereby contribute to OpenWrt: * a TR-069 protocol agent, * a data model mapping framework that we use to bridge the world of OpenWrt, UCI, UBUS ... with the world of TR-069, TR-098, TR-181 ... (and by extension with the world of SNMP, MIB, NETCONF, YANG ...), * a set of mappings. We are conscious of the fact that together with the proposals made by Felix, Luka and Wojtek we are now looking at many "competing" proposals. As a next step, we recommend to organize a workshop, at a practical location and time, where we put everything on the table and define the most appropriate path forward to the benefit of OpenWrt as a whole. TR-069 is a complicated remote management system and in order to make this initiative a success, we must ensure that the complexity is handled in an elegant way and with respect for OpenWrt's core architecture. More than on the protocol itself, we believe that we should focus on the architectural enhancements required to support remote management in general. Looking forward to hearing from you. Jos Delbar & Dirk Feytons Technicolor _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From david at lang.hm Fri May 27 06:43:59 2016 From: david at lang.hm (David Lang) Date: Fri, 27 May 2016 03:43:59 -0700 (PDT) Subject: [OpenWrt-Devel] [LEDE-DEV] TR-069 for OpenWrt In-Reply-To: References: Message-ID: On Thu, 26 May 2016, Delbar Jos wrote: > We are conscious of the fact that together with the proposals made by Felix, > Luka and Wojtek we are now looking at many "competing" proposals. As a next > step, we recommend to organize a workshop, at a practical location and time, > where we put everything on the table and define the most appropriate path > forward to the benefit of OpenWrt as a whole. nothing wrong with supporting many different remote management daemons. > TR-069 is a complicated remote management system and in order to make this > initiative a success, we must ensure that the complexity is handled in an > elegant way and with respect for OpenWrt's core architecture. More than on the > protocol itself, we believe that we should focus on the architectural > enhancements required to support remote management in general. What is it that you think is needed to "support remote management in general"? It's worth pointing out that many people are remotely managing OpenWRT devices, Ansible/Salt/Puppet/Chef/etc are all common tools for the job. now, those are all tools aimed at managing Linux Servers, not networking gear, but OpenWRT is a server. So I'd suggest starting off by creating a daemon that talks and just stores the stuff it's sent in some simple files so that it can return the info when queried. Once you have something that talks the network protocol correctly, modifying it to change the real files, make uci calls, etc for different distros is much easier (just write your daemon with the expectation that the input and output details are going to change, so don't get fancy with them). David Lang _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From karlp at tweak.net.au Fri May 27 07:55:43 2016 From: karlp at tweak.net.au (Karl Palsson) Date: Fri, 27 May 2016 11:55:43 -0000 Subject: [OpenWrt-Devel] [LEDE-DEV] TR-069 for OpenWrt In-Reply-To: References: Message-ID: David Lang wrote: > On Thu, 26 May 2016, Delbar Jos wrote: > > > We are conscious of the fact that together with the proposals made by Felix, > > Luka and Wojtek we are now looking at many "competing" proposals. As a next > > step, we recommend to organize a workshop, at a practical location and time, > > where we put everything on the table and define the most appropriate path > > forward to the benefit of OpenWrt as a whole. > > nothing wrong with supporting many different remote management > daemons. > > > TR-069 is a complicated remote management system and in order to make this > > initiative a success, we must ensure that the complexity is handled in an > > elegant way and with respect for OpenWrt's core architecture. More than on the > > protocol itself, we believe that we should focus on the architectural > > enhancements required to support remote management in general. > > What is it that you think is needed to "support remote > management in general"? > > It's worth pointing out that many people are remotely managing > OpenWRT devices, Ansible/Salt/Puppet/Chef/etc are all common > tools for the job. Really? python, python, ruby, ruby. None of those are really fun enjoyable tasks on _my_ openwrt/leded devices. > now, those are all tools aimed at managing Linux Servers, not > networking gear, but OpenWRT is a server. > > So I'd suggest starting off by creating a daemon that talks > and just stores the stuff it's sent in some > simple files so that it can return the info when queried. Did you read the intro to Delbar's mail, describing that they already have a complete tr069 project, for managing openwrt devices, that they want to open source, and want to collaborate on making it more useful for all, and perhaps see if there are common pain points that can be resolved by handling things differently on the lede/openwrt side, rather than working around on the tr069 side? I think it's exciting and I'd love to hear more about it. ansible/salt/puppet/chef have been far too heavy to run, and openvpn servers granting remote shell access is far too tedious for daily use. Cheers, Karl P -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP Digital Signature URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From drasko.draskovic at gmail.com Fri May 27 08:28:18 2016 From: drasko.draskovic at gmail.com (Drasko DRASKOVIC) Date: Fri, 27 May 2016 14:28:18 +0200 Subject: [OpenWrt-Devel] [LEDE-DEV] TR-069 for OpenWrt In-Reply-To: References: Message-ID: Hi Karl, On Fri, May 27, 2016 at 1:55 PM, Karl Palsson wrote: > > David Lang wrote: >> On Thu, 26 May 2016, Delbar Jos wrote: >> >> > We are conscious of the fact that together with the proposals made by Felix, >> > Luka and Wojtek we are now looking at many "competing" proposals. As a next >> > step, we recommend to organize a workshop, at a practical location and time, >> > where we put everything on the table and define the most appropriate path >> > forward to the benefit of OpenWrt as a whole. >> >> nothing wrong with supporting many different remote management >> daemons. >> >> > TR-069 is a complicated remote management system and in order to make this >> > initiative a success, we must ensure that the complexity is handled in an >> > elegant way and with respect for OpenWrt's core architecture. More than on the >> > protocol itself, we believe that we should focus on the architectural >> > enhancements required to support remote management in general. >> >> What is it that you think is needed to "support remote >> management in general"? >> >> It's worth pointing out that many people are remotely managing >> OpenWRT devices, Ansible/Salt/Puppet/Chef/etc are all common >> tools for the job. > > Really? python, python, ruby, ruby. None of those are really fun enjoyable tasks on _my_ openwrt/leded devices. > >> now, those are all tools aimed at managing Linux Servers, not >> networking gear, but OpenWRT is a server. >> >> So I'd suggest starting off by creating a daemon that talks >> and just stores the stuff it's sent in some >> simple files so that it can return the info when queried. > > Did you read the intro to Delbar's mail, describing that they > already have a complete tr069 project, for managing openwrt > devices, that they want to open source, and want to collaborate > on making it more useful for all, and perhaps see if there are > common pain points that can be resolved by handling things > differently on the lede/openwrt side, rather than working around > on the tr069 side? > > I think it's exciting and I'd love to hear more about it. > ansible/salt/puppet/chef have been far too heavy to run, and > openvpn servers granting remote shell access is far too tedious > for daily use. I am very interested to see TR-069 solution. IMHO what is really useful in it is Amendment 5, NAT traversal based on XMMP. Both AllJoyn and Iotivity seem to push this approach to managing CPEs - naturally, it has been proven and widely used. For the reference, here is an interesting discussion I had with Thiago Macieira from Iotivity: https://lists.linuxfoundation.org/pipermail/iotivity-dev/2015-October/002867.html However, I would personally look more at OMA LwM2M - it would be much lighter and more fun to implement ;). NAT traversal is not so straightforward, but it would be interesting to investigate it. Then clients will be ultra-light. BR, Drasko _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From eschultz at prplfoundation.org Fri May 27 11:20:37 2016 From: eschultz at prplfoundation.org (Eric Schultz) Date: Fri, 27 May 2016 10:20:37 -0500 Subject: [OpenWrt-Devel] [OpenWrt] TR-069 for OpenWrt In-Reply-To: References: Message-ID: Jos and Dirk, I'm delighted to hear that Technicolor is making their TR-069 solution open source. When prpl proposed funding this work, I don't think any of us had the sense of how many folks wanted to contribute in this area! Making more code open source is always a positive in my book so bravo! There do seem to be two areas of exploration here: * Support for TR-069 and the various protocols details * Integration into OpenWrt, including improvements to generalize the work to support new protocols. I think your idea for an in-person workshop is a great idea. While we were planning on having a online meeting with the interested parties, I think an in-person workshop is an even better idea. There's a lot of potential code on the table and related projects to fund. I know from prpl's perspective we want to make sure the result is valuable to industry and the community. I don't want to put everyone on the spot so I'll contact individually Felix, Luka and Wotjek and get their feedback (unless they'd like to comment here). If everyone's in agreement, we can work out a time and place that works well for everyone. Thanks, Eric On Thu, May 26, 2016 at 6:43 PM, Delbar Jos wrote: > Hi all, > > At Technicolor we have followed with great interest the recent proposals > to enhance OpenWrt with an open source solution for TR-069 remote > management. As one of the world's largest vendors of modems and routers for > carrier applications, making use of OpenWrt in a significant share of our > install base, we want to support this initiative in a meaningful way. > Concretely, we are willing to open source Technicolor's in-house TR-069 > solution and thereby contribute to OpenWrt: > * a TR-069 protocol agent, > * a data model mapping framework that we use to bridge the world of > OpenWrt, UCI, UBUS ... with the world of TR-069, TR-098, TR-181 ... (and by > extension with the world of SNMP, MIB, NETCONF, YANG ...), > * a set of mappings. > > We are conscious of the fact that together with the proposals made by > Felix, Luka and Wojtek we are now looking at many "competing" proposals. As > a next step, we recommend to organize a workshop, at a practical location > and time, where we put everything on the table and define the most > appropriate path forward to the benefit of OpenWrt as a whole. > > TR-069 is a complicated remote management system and in order to make this > initiative a success, we must ensure that the complexity is handled in an > elegant way and with respect for OpenWrt's core architecture. More than on > the protocol itself, we believe that we should focus on the architectural > enhancements required to support remote management in general. > > Looking forward to hearing from you. > > Jos Delbar & Dirk Feytons > Technicolor > _______________________________________________ > OpenWrt mailing list > OpenWrt at lists.prplfoundation.org > http://lists.prplfoundation.org/cgi-bin/mailman/listinfo/openwrt > -- Eric Schultz, Community Manager, prpl Foundation http://www.prplfoundation.org eschultz at prplfoundation.org cell: 920-539-0404 skype: ericschultzwi @EricPrpl -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From nbd at nbd.name Sat May 28 01:15:53 2016 From: nbd at nbd.name (Felix Fietkau) Date: Sat, 28 May 2016 07:15:53 +0200 Subject: [OpenWrt-Devel] [LEDE-DEV] TR-069 for OpenWrt In-Reply-To: References: Message-ID: <264724c0-8778-1f31-f054-3a0375103ba2@nbd.name> On 2016-05-27 01:43, Delbar Jos wrote: > Hi all, > > At Technicolor we have followed with great interest the recent > proposals to enhance OpenWrt with an open source solution for TR-069 > remote management. As one of the world's largest vendors of modems > and routers for carrier applications, making use of OpenWrt in a > significant share of our install base, we want to support this > initiative in a meaningful way. Concretely, we are willing to open > source Technicolor's in-house TR-069 solution and thereby contribute > to OpenWrt: > * a TR-069 protocol agent, > * a data model mapping framework that we use to bridge the world of > OpenWrt, UCI, UBUS ... with the world of TR-069, TR-098, TR-181 ... > (and by extension with the world of SNMP, MIB, NETCONF, YANG ...), > * a set of mappings. Nice! > We are conscious of the fact that together with the proposals made > by Felix, Luka and Wojtek we are now looking at many "competing" proposals. > As a next step, we recommend to organize a workshop, at a practical > location and time, where we put everything on the table and define the > most appropriate path forward to the benefit of OpenWrt as a whole. I think such a workshop would be a great idea. It would be nice to have the code available for review some time before that workshop, so we can all take a detailed look at the various proposals before we sit down and decide how to move forward with this. > TR-069 is a complicated remote management system and in order to make > this initiative a success, we must ensure that the complexity is > handled in an elegant way and with respect for OpenWrt's core > architecture. More than on the protocol itself, we believe that we > should focus on the architectural enhancements required to support > remote management in general. Sounds good! - Felix _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From luka.perkov at sartura.hr Sat May 28 05:28:20 2016 From: luka.perkov at sartura.hr (Luka Perkov) Date: Sat, 28 May 2016 11:28:20 +0200 Subject: [OpenWrt-Devel] [OpenWrt] TR-069 for OpenWrt In-Reply-To: References: Message-ID: <20160528092820.GA16277@localhost.localdomain> Hi Delbar, On Thu, May 26, 2016 at 11:43:28PM +0000, Delbar Jos wrote: > At Technicolor we have followed with great interest the recent proposals to enhance OpenWrt with an open source solution for TR-069 remote management. As one of the world's largest vendors of modems and routers for carrier applications, making use of OpenWrt in a significant share of our install base, we want to support this initiative in a meaningful way. Concretely, we are willing to open source Technicolor's in-house TR-069 solution and thereby contribute to OpenWrt: > * a TR-069 protocol agent, > * a data model mapping framework that we use to bridge the world of OpenWrt, UCI, UBUS ... with the world of TR-069, TR-098, TR-181 ... (and by extension with the world of SNMP, MIB, NETCONF, YANG ...), > * a set of mappings. > > We are conscious of the fact that together with the proposals made by Felix, > Luka and Wojtek we are now looking at many "competing" proposals. As a next > step, we recommend to organize a workshop, at a practical location and time, > where we put everything on the table and define the most appropriate path > forward to the benefit of OpenWrt as a whole. > > TR-069 is a complicated remote management system and in order to make this > initiative a success, we must ensure that the complexity is handled in an > elegant way and with respect for OpenWrt's core architecture. More than on > the protocol itself, we believe that we should focus on the architectural > enhancements required to support remote management in general. > > Looking forward to hearing from you. Thank you for your proposal and offer. I think this effort and workshop are great news. I'm also looking forward to see if more companies will decide to join CWMP/TR-* discussions and more importantly at the end of the day have a stable and well defined TR-069 stack implemented in OpenWrt! Regards, Luka _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From hauke at hauke-m.de Sat May 28 07:20:06 2016 From: hauke at hauke-m.de (Hauke Mehrtens) Date: Sat, 28 May 2016 13:20:06 +0200 Subject: [OpenWrt-Devel] [LEDE-DEV] TR-069 for OpenWrt In-Reply-To: References: Message-ID: <57497EE6.4000401@hauke-m.de> On 05/27/2016 01:43 AM, Delbar Jos wrote: > Hi all, > > At Technicolor we have followed with great interest the recent proposals to enhance OpenWrt with an open source solution for TR-069 remote management. As one of the world's largest vendors of modems and routers for carrier applications, making use of OpenWrt in a significant share of our install base, we want to support this initiative in a meaningful way. Concretely, we are willing to open source Technicolor's in-house TR-069 solution and thereby contribute to OpenWrt: > * a TR-069 protocol agent, > * a data model mapping framework that we use to bridge the world of OpenWrt, UCI, UBUS ... with the world of TR-069, TR-098, TR-181 ... (and by extension with the world of SNMP, MIB, NETCONF, YANG ...), > * a set of mappings. That is really nice to hear. For me personally it looks like the remote management with TR-069 and similar protocols is one of the biggest extensions commercial vendors add to the user space of OpenWrt to make it fit their needs. In addition to the TR-* family does this also include support for SNMP, MIB, NETCONF, YANG ? > We are conscious of the fact that together with the proposals made by Felix, Luka and Wojtek we are now looking at many "competing" proposals. As a next step, we recommend to organize a workshop, at a practical location and time, where we put everything on the table and define the most appropriate path forward to the benefit of OpenWrt as a whole. That's good to hear, would it also be possible that other interested people can join such a workshop? > TR-069 is a complicated remote management system and in order to make this initiative a success, we must ensure that the complexity is handled in an elegant way and with respect for OpenWrt's core architecture. More than on the protocol itself, we believe that we should focus on the architectural enhancements required to support remote management in general. > > Looking forward to hearing from you. > > Jos Delbar & Dirk Feytons > Technicolor Hauke _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From hauke at hauke-m.de Sat May 28 07:34:39 2016 From: hauke at hauke-m.de (Hauke Mehrtens) Date: Sat, 28 May 2016 13:34:39 +0200 Subject: [OpenWrt-Devel] [LEDE-DEV] TR-069 for OpenWrt In-Reply-To: References: Message-ID: <5749824F.9070000@hauke-m.de> On 05/27/2016 12:43 PM, David Lang wrote: > On Thu, 26 May 2016, Delbar Jos wrote: > >> We are conscious of the fact that together with the proposals made by >> Felix, Luka and Wojtek we are now looking at many "competing" >> proposals. As a next step, we recommend to organize a workshop, at a >> practical location and time, where we put everything on the table and >> define the most appropriate path forward to the benefit of OpenWrt as >> a whole. > > nothing wrong with supporting many different remote management daemons. > >> TR-069 is a complicated remote management system and in order to make >> this initiative a success, we must ensure that the complexity is >> handled in an elegant way and with respect for OpenWrt's core >> architecture. More than on the protocol itself, we believe that we >> should focus on the architectural enhancements required to support >> remote management in general. > > What is it that you think is needed to "support remote management in > general"? > > It's worth pointing out that many people are remotely managing OpenWRT > devices, Ansible/Salt/Puppet/Chef/etc are all common tools for the job. > > now, those are all tools aimed at managing Linux Servers, not networking > gear, but OpenWRT is a server. > > So I'd suggest starting off by creating a daemon that talks protocol> and just stores the stuff it's sent in some simple files so > that it can return the info when queried. > > Once you have something that talks the network protocol correctly, > modifying it to change the real files, make uci calls, etc for different > distros is much easier (just write your daemon with the expectation that > the input and output details are going to change, so don't get fancy > with them). > > David Lang The TR-069 family is currently wildly used by ISPs controlling the (DSL) CPE devices of their customers. There are probably more than 100 million device controlled by standards from the TR-069 family out there. When you get a DSL router from your ISP or buy one in the retail store it is very likely it supports the standards from the TR-069 family, as a vendor in this area you basically need support for this to sell your devices. In other technologies you have different protocols to manage your devices, like cable often uses something different and EPON and GPON even have all their own management standards. Then there are also some technology independent standards and so on. It makes sense to build such a solution in a way to make it easily to expendable for new protocols. Hauke _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From eckert.florian at googlemail.com Sat May 28 08:40:53 2016 From: eckert.florian at googlemail.com (Florian Eckert) Date: Sat, 28 May 2016 14:40:53 +0200 Subject: [OpenWrt-Devel] [LEDE-DEV] TR-069 for OpenWrt In-Reply-To: <5749824F.9070000@hauke-m.de> References: <5749824F.9070000@hauke-m.de> Message-ID: Hello, nice to hear the there are intentions to make a openwrt/lede solution. We are now using a freecwmp fork ( EasyCwmp ) to configure our devices. Freecwmo was mit maintained anymore. We extend the parameter set with the openwrt parameter which are not in the standard. Will the Meeting online (irc) for everyone? Regards Flo Am 28.05.2016 1:34 nachm. schrieb "Hauke Mehrtens" : > > On 05/27/2016 12:43 PM, David Lang wrote: > > On Thu, 26 May 2016, Delbar Jos wrote: > > > >> We are conscious of the fact that together with the proposals made by > >> Felix, Luka and Wojtek we are now looking at many "competing" > >> proposals. As a next step, we recommend to organize a workshop, at a > >> practical location and time, where we put everything on the table and > >> define the most appropriate path forward to the benefit of OpenWrt as > >> a whole. > > > > nothing wrong with supporting many different remote management daemons. > > > >> TR-069 is a complicated remote management system and in order to make > >> this initiative a success, we must ensure that the complexity is > >> handled in an elegant way and with respect for OpenWrt's core > >> architecture. More than on the protocol itself, we believe that we > >> should focus on the architectural enhancements required to support > >> remote management in general. > > > > What is it that you think is needed to "support remote management in > > general"? > > > > It's worth pointing out that many people are remotely managing OpenWRT > > devices, Ansible/Salt/Puppet/Chef/etc are all common tools for the job. > > > > now, those are all tools aimed at managing Linux Servers, not networking > > gear, but OpenWRT is a server. > > > > So I'd suggest starting off by creating a daemon that talks > protocol> and just stores the stuff it's sent in some simple files so > > that it can return the info when queried. > > > > Once you have something that talks the network protocol correctly, > > modifying it to change the real files, make uci calls, etc for different > > distros is much easier (just write your daemon with the expectation that > > the input and output details are going to change, so don't get fancy > > with them). > > > > David Lang > > The TR-069 family is currently wildly used by ISPs controlling the (DSL) > CPE devices of their customers. There are probably more than 100 million > device controlled by standards from the TR-069 family out there. When > you get a DSL router from your ISP or buy one in the retail store it is > very likely it supports the standards from the TR-069 family, as a > vendor in this area you basically need support for this to sell your > devices. > > In other technologies you have different protocols to manage your > devices, like cable often uses something different and EPON and GPON > even have all their own management standards. Then there are also some > technology independent standards and so on. It makes sense to build such > a solution in a way to make it easily to expendable for new protocols. > > Hauke > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From hauke at hauke-m.de Sat May 28 10:02:00 2016 From: hauke at hauke-m.de (Hauke Mehrtens) Date: Sat, 28 May 2016 16:02:00 +0200 Subject: [OpenWrt-Devel] [LEDE-DEV] TR-069, bufferbloat, and BQL In-Reply-To: References: Message-ID: <5749A4D8.6040802@hauke-m.de> On 05/28/2016 03:36 PM, Dave Taht wrote: > On Sat, May 28, 2016 at 5:34 AM, Hauke Mehrtens wrote: >> On 05/27/2016 12:43 PM, David Lang wrote: >>> On Thu, 26 May 2016, Delbar Jos wrote: >>> >>>> We are conscious of the fact that together with the proposals made by >>>> Felix, Luka and Wojtek we are now looking at many "competing" >>>> proposals. As a next step, we recommend to organize a workshop, at a >>>> practical location and time, where we put everything on the table and >>>> define the most appropriate path forward to the benefit of OpenWrt as >>>> a whole. >>> >>> nothing wrong with supporting many different remote management daemons. >>> >>>> TR-069 is a complicated remote management system and in order to make >>>> this initiative a success, we must ensure that the complexity is >>>> handled in an elegant way and with respect for OpenWrt's core >>>> architecture. More than on the protocol itself, we believe that we >>>> should focus on the architectural enhancements required to support >>>> remote management in general. >>> >>> What is it that you think is needed to "support remote management in >>> general"? > > I am curious if TR-069 has any ability to set parameters for upload > and download speeds, so they could be leveraged by sqm-scripts to > manage the bufferbloat that DSL modems and dslams have? > > Also: > > I have been hoping for nearly 4 years now that we'd see *someone* > actually produce a BQL enabled dsl driver for their modem interface so > advanced QoS techniques wouldn't be needed on outbound, where we could > just enable fq-codel on top of a tightly written driver and be done > with it. 100 million modems, all exhibiting 100s of ms of extra, > unneeded latency, under load: > > http://www.dslreports.com/speedtest/results/bufferbloat?up=1 > > sadly, aside from the freebox revolution v6, I'm not aware of anyone > actually doing dsl more right yet. (?) > The Lantiq / Intel DSL drivers are open source and integrated in OpenWrt, but I haven't checked if BQL is implemented there. They are also using a big firmware which does all the PHY related stuff. You can get some statistics from the device like this. These information are from the DSL PHY layer, so it does not show when your ISP would limit your rate somewhere else in the internal network, but these information are available on all DSL lines. root at lede:~# /etc/init.d/dsl_control status ATU-C Vendor ID: Broadcom 176.15 ATU-C System Vendor ID: Broadcom Chipset: Lantiq-VRX200 Unknown Firmware Version: 5.7.3.3.0.6 API Version: 4.16.6.3 XTSE Capabilities: 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2 Annex: B Line Mode: G.993.2 (VDSL2) Profile: 17a Line State: UP [0x801: showtime_tc_sync] Forward Error Correction Seconds (FECS): Near: 0 / Far: 2116802 Errored seconds (ES): Near: 0 / Far: 2938 Severely Errored Seconds (SES): Near: 0 / Far: 50 Loss of Signal Seconds (LOSS): Near: 0 / Far: 0 Unavailable Seconds (UAS): Near: 31 / Far: 31 Header Error Code Errors (HEC): Near: 0 / Far: 0 Non Pre-emtive CRC errors (CRC_P): Near: 0 / Far: 0 Pre-emtive CRC errors (CRCP_P): Near: 0 / Far: 0 Power Management Mode: L0 - Synchronized Latency / Interleave Delay: Down: Interleave (8.0 ms) / Up: Interleave (4.0 ms) Data Rate: Down: 51.391 Mb/s / Up: 10.046 Mb/s Line Attenuation (LATN): Down: 10.6dB / Up: 10.6dB Signal Attenuation (SATN): Down: 10.6dB / Up: 10.2dB Noise Margin (SNR): Down: 7.7dB / Up: 13.9dB Aggregate Transmit Power (ACTATP): Down: -11.6dB / Up: 12.5dB Max. Attainable Data Rate (ATTNDR): Down: 61.928 Mb/s / Up: 23.355 Mb/s Line Uptime Seconds: 62 Line Uptime: 1m 2s root at lede:~# Hauke _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From john at phrozen.org Sat May 28 10:05:31 2016 From: john at phrozen.org (John Crispin) Date: Sat, 28 May 2016 16:05:31 +0200 Subject: [OpenWrt-Devel] [LEDE-DEV] TR-069, bufferbloat, and BQL In-Reply-To: <5749A4D8.6040802@hauke-m.de> References: <5749A4D8.6040802@hauke-m.de> Message-ID: On 28/05/2016 16:02, Hauke Mehrtens wrote: > On 05/28/2016 03:36 PM, Dave Taht wrote: >> On Sat, May 28, 2016 at 5:34 AM, Hauke Mehrtens wrote: >>> On 05/27/2016 12:43 PM, David Lang wrote: >>>> On Thu, 26 May 2016, Delbar Jos wrote: >>>> >>>>> We are conscious of the fact that together with the proposals made by >>>>> Felix, Luka and Wojtek we are now looking at many "competing" >>>>> proposals. As a next step, we recommend to organize a workshop, at a >>>>> practical location and time, where we put everything on the table and >>>>> define the most appropriate path forward to the benefit of OpenWrt as >>>>> a whole. >>>> >>>> nothing wrong with supporting many different remote management daemons. >>>> >>>>> TR-069 is a complicated remote management system and in order to make >>>>> this initiative a success, we must ensure that the complexity is >>>>> handled in an elegant way and with respect for OpenWrt's core >>>>> architecture. More than on the protocol itself, we believe that we >>>>> should focus on the architectural enhancements required to support >>>>> remote management in general. >>>> >>>> What is it that you think is needed to "support remote management in >>>> general"? >> >> I am curious if TR-069 has any ability to set parameters for upload >> and download speeds, so they could be leveraged by sqm-scripts to >> manage the bufferbloat that DSL modems and dslams have? >> >> Also: >> >> I have been hoping for nearly 4 years now that we'd see *someone* >> actually produce a BQL enabled dsl driver for their modem interface so >> advanced QoS techniques wouldn't be needed on outbound, where we could >> just enable fq-codel on top of a tightly written driver and be done >> with it. 100 million modems, all exhibiting 100s of ms of extra, >> unneeded latency, under load: >> >> http://www.dslreports.com/speedtest/results/bufferbloat?up=1 >> >> sadly, aside from the freebox revolution v6, I'm not aware of anyone >> actually doing dsl more right yet. (?) >> > > The Lantiq / Intel DSL drivers are open source and integrated in > OpenWrt, but I haven't checked if BQL is implemented there. They are > also using a big firmware which does all the PHY related stuff. > > You can get some statistics from the device like this. These information > are from the DSL PHY layer, so it does not show when your ISP would > limit your rate somewhere else in the internal network, but these > information are available on all DSL lines. there is no BQL and there is a 256 packet buffer in the driver. if i am not mistaken, there is a secondary 64 packet ring handled by the firmware blob. John > > root at lede:~# /etc/init.d/dsl_control status > ATU-C Vendor ID: Broadcom 176.15 > ATU-C System Vendor ID: Broadcom > Chipset: Lantiq-VRX200 Unknown > Firmware Version: 5.7.3.3.0.6 > API Version: 4.16.6.3 > XTSE Capabilities: 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, > 0x0, 0x2 > Annex: B > Line Mode: G.993.2 (VDSL2) > Profile: 17a > Line State: UP [0x801: showtime_tc_sync] > Forward Error Correction Seconds (FECS): Near: 0 / Far: 2116802 > Errored seconds (ES): Near: 0 / Far: 2938 > Severely Errored Seconds (SES): Near: 0 / Far: 50 > Loss of Signal Seconds (LOSS): Near: 0 / Far: 0 > Unavailable Seconds (UAS): Near: 31 / Far: 31 > Header Error Code Errors (HEC): Near: 0 / Far: 0 > Non Pre-emtive CRC errors (CRC_P): Near: 0 / Far: 0 > Pre-emtive CRC errors (CRCP_P): Near: 0 / Far: 0 > Power Management Mode: L0 - Synchronized > Latency / Interleave Delay: Down: Interleave (8.0 ms) / > Up: Interleave (4.0 ms) > Data Rate: Down: 51.391 Mb/s / Up: 10.046 > Mb/s > Line Attenuation (LATN): Down: 10.6dB / Up: 10.6dB > Signal Attenuation (SATN): Down: 10.6dB / Up: 10.2dB > Noise Margin (SNR): Down: 7.7dB / Up: 13.9dB > Aggregate Transmit Power (ACTATP): Down: -11.6dB / Up: 12.5dB > Max. Attainable Data Rate (ATTNDR): Down: 61.928 Mb/s / Up: 23.355 > Mb/s > Line Uptime Seconds: 62 > Line Uptime: 1m 2s > root at lede:~# > > Hauke > > _______________________________________________ > Lede-dev mailing list > Lede-dev at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev > _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From david at lang.hm Sat May 28 18:14:10 2016 From: david at lang.hm (David Lang) Date: Sat, 28 May 2016 15:14:10 -0700 (PDT) Subject: [OpenWrt-Devel] [LEDE-DEV] TR-069 for OpenWrt In-Reply-To: <5749824F.9070000@hauke-m.de> References: <5749824F.9070000@hauke-m.de> Message-ID: On Sat, 28 May 2016, Hauke Mehrtens wrote: > On 05/27/2016 12:43 PM, David Lang wrote: >> On Thu, 26 May 2016, Delbar Jos wrote: >> >>> We are conscious of the fact that together with the proposals made by >>> Felix, Luka and Wojtek we are now looking at many "competing" >>> proposals. As a next step, we recommend to organize a workshop, at a >>> practical location and time, where we put everything on the table and >>> define the most appropriate path forward to the benefit of OpenWrt as >>> a whole. >> >> nothing wrong with supporting many different remote management daemons. >> >>> TR-069 is a complicated remote management system and in order to make >>> this initiative a success, we must ensure that the complexity is >>> handled in an elegant way and with respect for OpenWrt's core >>> architecture. More than on the protocol itself, we believe that we >>> should focus on the architectural enhancements required to support >>> remote management in general. >> >> What is it that you think is needed to "support remote management in >> general"? >> >> It's worth pointing out that many people are remotely managing OpenWRT >> devices, Ansible/Salt/Puppet/Chef/etc are all common tools for the job. >> >> now, those are all tools aimed at managing Linux Servers, not networking >> gear, but OpenWRT is a server. >> >> So I'd suggest starting off by creating a daemon that talks > protocol> and just stores the stuff it's sent in some simple files so >> that it can return the info when queried. >> >> Once you have something that talks the network protocol correctly, >> modifying it to change the real files, make uci calls, etc for different >> distros is much easier (just write your daemon with the expectation that >> the input and output details are going to change, so don't get fancy >> with them). >> >> David Lang > > The TR-069 family is currently wildly used by ISPs controlling the (DSL) > CPE devices of their customers. There are probably more than 100 million > device controlled by standards from the TR-069 family out there. When > you get a DSL router from your ISP or buy one in the retail store it is > very likely it supports the standards from the TR-069 family, as a > vendor in this area you basically need support for this to sell your > devices. I wasn't questioning why it's useful to support TR-069. The only part I was questioning was the statement that OpenWRT needed work to make it support remote management. There are already many tools to remotely manage/monitor OpenWRT But that's why I'm saying that it seems like most of the work is in the protocol interface. If there is already a daemon that does the network protocol properly, that should make things very easy. If such a daemon needs to be written, that would be the place I would suggest that they focus. There are a lot of people who can do the plumbing work to make the daemon do the right thing on the system, who are not in a position to work on the network protocol side and make sure that it works properly with the management software. David Lang _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From kevin at darbyshire-bryant.me.uk Sun May 29 04:44:03 2016 From: kevin at darbyshire-bryant.me.uk (Kevin Darbyshire-Bryant) Date: Sun, 29 May 2016 09:44:03 +0100 Subject: [OpenWrt-Devel] [PATCH] routing: miniupnpd: update to v2.0 Message-ID: <1464511443-26702-1-git-send-email-kevin@darbyshire-bryant.me.uk> Update miniupnpd to v2.0 Refresh patches Signed-off-by: Kevin Darbyshire-Bryant --- miniupnpd/Makefile | 4 ++-- miniupnpd/patches/100-no-ssl.patch | 6 +++--- miniupnpd/patches/102-ipv6-ext-port.patch | 2 +- miniupnpd/patches/103-no-ipv6-autodetection.patch | 2 +- 4 files changed, 7 insertions(+), 7 deletions(-) diff --git a/miniupnpd/Makefile b/miniupnpd/Makefile index 1000929..0207036 100644 --- a/miniupnpd/Makefile +++ b/miniupnpd/Makefile @@ -8,12 +8,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=miniupnpd -PKG_VERSION:=1.9.20151212 +PKG_VERSION:=2.0 PKG_RELEASE:=1 PKG_SOURCE_URL:=http://miniupnp.free.fr/files PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz -PKG_MD5SUM:=86465b35f711ca9982d48b34c094033a +PKG_MD5SUM:=1c07a215dd9b362e75a9efc05e2fb3b4 PKG_MAINTAINER:=Markus Stenberg PKG_LICENSE:=BSD-3-Clause diff --git a/miniupnpd/patches/100-no-ssl.patch b/miniupnpd/patches/100-no-ssl.patch index 343e615..5caafc2 100644 --- a/miniupnpd/patches/100-no-ssl.patch +++ b/miniupnpd/patches/100-no-ssl.patch @@ -1,6 +1,6 @@ --- a/Makefile.linux +++ b/Makefile.linux -@@ -147,7 +147,8 @@ LDLIBS += $(shell $(PKG_CONFIG) --static +@@ -153,7 +153,8 @@ LDLIBS += $(shell $(PKG_CONFIG) --static LDLIBS += $(shell $(PKG_CONFIG) --static --libs-only-l libnetfilter_conntrack) endif # ($(TEST),1) @@ -8,5 +8,5 @@ +# n/a - we don't enable https server for IGD v2 anyway +#LDLIBS += $(shell $(PKG_CONFIG) --static --libs-only-l libssl) - TESTUPNPDESCGENOBJS = testupnpdescgen.o upnpdescgen.o - + TEST := $(shell $(PKG_CONFIG) --exists uuid && echo 1) + ifeq ($(TEST),1) diff --git a/miniupnpd/patches/102-ipv6-ext-port.patch b/miniupnpd/patches/102-ipv6-ext-port.patch index fdb2af4..806c7fd 100644 --- a/miniupnpd/patches/102-ipv6-ext-port.patch +++ b/miniupnpd/patches/102-ipv6-ext-port.patch @@ -1,6 +1,6 @@ --- a/pcpserver.c +++ b/pcpserver.c -@@ -1004,6 +1004,7 @@ static int CreatePCPMap_NAT(pcp_info_t * +@@ -982,6 +982,7 @@ static int CreatePCPMap_NAT(pcp_info_t * timestamp); if (r < 0) return PCP_ERR_NO_RESOURCES; diff --git a/miniupnpd/patches/103-no-ipv6-autodetection.patch b/miniupnpd/patches/103-no-ipv6-autodetection.patch index 61c023a..50d5a39 100644 --- a/miniupnpd/patches/103-no-ipv6-autodetection.patch +++ b/miniupnpd/patches/103-no-ipv6-autodetection.patch @@ -17,7 +17,7 @@ As the OpenWRT buildsystem already passes the right compile flags, we can skip t # testiptpinhole --- a/Makefile.linux +++ b/Makefile.linux -@@ -70,7 +70,6 @@ CPPFLAGS += -DIPTABLES_143 +@@ -73,7 +73,6 @@ CPPFLAGS += -DIPTABLES_143 endif CFLAGS += $(shell $(PKG_CONFIG) --cflags libiptc) -- 1.9.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From nik9993 at gmail.com Sun May 29 18:26:03 2016 From: nik9993 at gmail.com (Allan Nick Pedrana) Date: Sun, 29 May 2016 17:26:03 -0500 Subject: [OpenWrt-Devel] [PATCH][ar71xx] add support for OpenEmbed SOM9331 In-Reply-To: References: Message-ID: <1464560763-18609-1-git-send-email-nik9993@gmail.com> This patch adds the target profile SOM9331 and configures hardware functionality for the 3x Eth Ports & corresponding LED's, the USB Host, the USART to USB bridge and the System LED. Signed-off-by: Allan Nick Pedrana --- I based what I did on the patch for SOM9331 running 12.09 AA that was distributed by the vendor, found here[https://github.com/10to7/SOM9331/blob/master/som9331.patch]. target/linux/ar71xx/base-files/etc/diag.sh | 3 target/linux/ar71xx/base-files/etc/uci-defaults/01_leds | 8 target/linux/ar71xx/base-files/etc/uci-defaults/02_network | 1 target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 target/linux/ar71xx/base-files/lib/upgrade/platform.sh | 1 target/linux/ar71xx/config-3.18 | 1 target/linux/ar71xx/files/arch/mips/ath79/mach-som9331.c | 125 ++++++++++ target/linux/ar71xx/generic/profiles/openembed.mk | 13 + target/linux/ar71xx/image/Makefile | 9 target/linux/ar71xx/patches-3.18/610-MIPS-ath79-openwrt-machines.patch | 24 + tools/firmware-utils/src/mktplinkfw.c | 6 11 files changed, 188 insertions(+), 6 deletions(-) diff --git a/target/linux/ar71xx/base-files/etc/diag.sh b/target/linux/ar71xx/base-files/etc/diag.sh index 5a184cd..d984d72 100644 --- a/target/linux/ar71xx/base-files/etc/diag.sh +++ b/target/linux/ar71xx/base-files/etc/diag.sh @@ -224,6 +224,9 @@ get_status_led() { qihoo-c301) status_led="qihoo:green:status" ;; + som9331) + status_led="som9331:green:system" + ;; tew-632brp) status_led="tew-632brp:green:status" ;; diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds index a4b355a..d8b39a6 100644 --- a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds @@ -311,6 +311,14 @@ smart-300) ucidef_set_led_wlan "wlan" "WLAN" "nc-link:green:wlan" "phy0tpt" ;; +som9331) + ucidef_set_led_netdev "wan" "WAN" "som9331:orange:wan" "eth1" + ucidef_set_led_switch "lan1" "LAN1" "som9331:orange:lan1" "switch0" "0x08" + ucidef_set_led_switch "lan2" "LAN2" "som9331:orange:lan2" "switch0" "0x02" + ucidef_set_led_wlan "wlan" "WLAN" "som9331:red:wlan" "phy0tpt" + ucidef_set_led_usbdev "usb" "USB" "som9331:green:system" "1-1" + ;; + tew-712br) ucidef_set_led_netdev "wan" "WAN" "trendnet:green:wan" "eth1" ucidef_set_led_switch "lan1" "LAN1" "trendnet:green:lan1" "switch0" "0x02" diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network index b2e15bb..165a68a 100755 --- a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network @@ -425,6 +425,7 @@ oolite |\ qihoo-c301 |\ rb-750 |\ rb-751 |\ +som9331 |\ tew-632brp |\ tew-712br |\ tew-732br |\ diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh b/target/linux/ar71xx/base-files/lib/ar71xx.sh index dab4d2c..d9158dc 100755 --- a/target/linux/ar71xx/base-files/lib/ar71xx.sh +++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh @@ -686,6 +686,9 @@ ar71xx_board_detect() { "Smart Electronics Black Swift board"*) name="bsb" ;; + *SOM9331) + name="som9331" + ;; *TEW-632BRP) name="tew-632brp" ;; diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh index d025632..e5bfb1b 100755 --- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh +++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh @@ -317,6 +317,7 @@ platform_check_image() { onion-omega | \ oolite | \ smart-300 | \ + som9331 | \ tl-mr10u | \ tl-mr11u | \ tl-mr12u | \ diff --git a/target/linux/ar71xx/config-3.18 b/target/linux/ar71xx/config-3.18 index e2ff826..4fe40ab 100644 --- a/target/linux/ar71xx/config-3.18 +++ b/target/linux/ar71xx/config-3.18 @@ -105,6 +105,7 @@ CONFIG_ATH79_MACH_R6100=y # CONFIG_ATH79_MACH_RBSXTLITE is not set CONFIG_ATH79_MACH_RW2458N=y CONFIG_ATH79_MACH_SMART_300=y +CONFIG_ATH79_MACH_SOM9331=y CONFIG_ATH79_MACH_TEW_632BRP=y CONFIG_ATH79_MACH_TEW_673GRU=y CONFIG_ATH79_MACH_TEW_712BR=y diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-som9331.c b/target/linux/ar71xx/files/arch/mips/ath79/mach-som9331.c new file mode 100644 index 0000000..eef5bce --- /dev/null +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-som9331.c @@ -0,0 +1,125 @@ +/* + * OpenEmbed SOM9331 board support + * + * Copyright (C) 2011 dongyuqi <729650915 at qq.com> + * Copyright (C) 2011-2012 Gabor Juhos + * + * 5/27/2016 - Modified by Allan Nick Pedrana + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 as published + * by the Free Software Foundation. + */ + +#include + +#include +#include + +#include "common.h" +#include "dev-eth.h" +#include "dev-gpio-buttons.h" +#include "dev-leds-gpio.h" +#include "dev-m25p80.h" +#include "dev-usb.h" +#include "dev-wmac.h" +#include "machtypes.h" + +#define SOM9331_GPIO_LED_WLAN 27 +#define SOM9331_GPIO_LED_SYSTEM 0 +#define SOM9331_GPIO_LED_2 13 +#define SOM9331_GPIO_LED_3 14 +#define SOM9331_GPIO_LED_5 16 +#define SOM9331_GPIO_LED_WAN SOM9331_GPIO_LED_2 +#define SOM9331_GPIO_LED_LAN1 SOM9331_GPIO_LED_3 +#define SOM9331_GPIO_LED_LAN2 SOM9331_GPIO_LED_5 +#define SOM9331_GPIO_BTN_RESET 11 + +#define SOM9331_KEYS_POLL_INTERVAL 20 /* msecs */ +#define SOM9331_KEYS_DEBOUNCE_INTERVAL (3 * SOM9331_KEYS_POLL_INTERVAL) + +static const char *som9331_part_probes[] = { + "tp-link", + NULL, +}; + +static struct flash_platform_data som9331_flash_data = { + .part_probes = som9331_part_probes, +}; + +static struct gpio_led som9331_leds_gpio[] __initdata = { + { + .name = "som9331:red:wlan", + .gpio = SOM9331_GPIO_LED_WLAN, + .active_low = 1, + }, + { + .name = "som9331:orange:wan", + .gpio = SOM9331_GPIO_LED_WAN, + .active_low = 0, + }, + { + .name = "som9331:orange:lan1", + .gpio = SOM9331_GPIO_LED_LAN1, + .active_low = 0, + }, + { + .name = "som9331:orange:lan2", + .gpio = SOM9331_GPIO_LED_LAN2, + .active_low = 0, + }, + { + .name = "som9331:blue:system", + .gpio = SOM9331_GPIO_LED_SYSTEM, + .active_low = 0, + }, +}; + +static struct gpio_keys_button som9331_gpio_keys[] __initdata = { + { + .desc = "reset", + .type = EV_KEY, + .code = KEY_RESTART, + .debounce_interval = SOM9331_KEYS_DEBOUNCE_INTERVAL, + .gpio = SOM9331_GPIO_BTN_RESET, + .active_low = 0, + } +}; + +static void __init som9331_setup(void) +{ + u8 *mac = (u8 *) KSEG1ADDR(0x1f01fc00); + u8 *ee = (u8 *) KSEG1ADDR(0x1fff1000); + + ath79_setup_ar933x_phy4_switch(true, true); + + ath79_gpio_function_disable(AR933X_GPIO_FUNC_ETH_SWITCH_LED0_EN | + AR933X_GPIO_FUNC_ETH_SWITCH_LED1_EN | + AR933X_GPIO_FUNC_ETH_SWITCH_LED2_EN | + AR933X_GPIO_FUNC_ETH_SWITCH_LED3_EN | + AR933X_GPIO_FUNC_ETH_SWITCH_LED4_EN); + + ath79_register_m25p80(&som9331_flash_data); + ath79_register_leds_gpio(-1, ARRAY_SIZE(som9331_leds_gpio), + som9331_leds_gpio); + ath79_register_gpio_keys_polled(-1, SOM9331_KEYS_POLL_INTERVAL, + ARRAY_SIZE(som9331_gpio_keys), + som9331_gpio_keys); + + ath79_register_usb(); + + ath79_init_mac(ath79_eth0_data.mac_addr, mac, 0); + ath79_init_mac(ath79_eth1_data.mac_addr, mac, -1); + + ath79_register_mdio(0, 0x0); + + /* LAN ports */ + ath79_register_eth(1); + + /* WAN port */ + ath79_register_eth(0); + + ath79_register_wmac(ee, mac); +} + +MIPS_MACHINE(ATH79_MACH_SOM9331, "SOM9331", "OpenEmbed SOM9331", som9331_setup); diff --git a/target/linux/ar71xx/generic/profiles/openembed.mk b/target/linux/ar71xx/generic/profiles/openembed.mk new file mode 100644 index 0000000..2603e0a --- /dev/null +++ b/target/linux/ar71xx/generic/profiles/openembed.mk @@ -0,0 +1,13 @@ +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. + +define Profile/SOM9331 + NAME:=OpenEmbed SOM9331 + PACKAGES:=kmod-usb-core kmod-usb2 kmod-usb-storage kmod-i2c-core kmod-i2c-gpio-custom kmod-spi-bitbang kmod-spi-dev kmod-spi-gpio kmod-spi-gpio-custom kmod-usb-serial +endef + +define Profile/SOM9331/Description + Package set optimized for the OpenEmbed SOM9331. +endef +$(eval $(call Profile,SOM9331)) + diff --git a/target/linux/ar71xx/image/Makefile b/target/linux/ar71xx/image/Makefile index 9a7acbd..9052c7e 100644 --- a/target/linux/ar71xx/image/Makefile +++ b/target/linux/ar71xx/image/Makefile @@ -371,6 +371,15 @@ define Device/onion-omega endef TARGET_DEVICES += onion-omega +define Device/som9331 + $(Device/tplink-8mlzma) + BOARDNAME := SOM9331 + DEVICE_PROFILE := SOM9331 + TPLINK_HWID := 0x04800054 + CONSOLE := ttyATH0,115200 +endef +TARGET_DEVICES += som9331 + define Device/tl-mr10u-v1 $(Device/tplink-4mlzma) BOARDNAME := TL-MR10U diff --git a/target/linux/ar71xx/patches-3.18/610-MIPS-ath79-openwrt-machines.patch b/target/linux/ar71xx/patches-3.18/610-MIPS-ath79-openwrt-machines.patch index d6e786d..f8f9534 100644 --- a/target/linux/ar71xx/patches-3.18/610-MIPS-ath79-openwrt-machines.patch +++ b/target/linux/ar71xx/patches-3.18/610-MIPS-ath79-openwrt-machines.patch @@ -1,6 +1,6 @@ --- a/arch/mips/ath79/machtypes.h +++ b/arch/mips/ath79/machtypes.h -@@ -16,22 +16,199 @@ +@@ -16,22 +16,200 @@ enum ath79_mach_type { ATH79_MACH_GENERIC = 0, @@ -105,6 +105,7 @@ + ATH79_MACH_RB_SXTLITE5ND, /* Mikrotik RouterBOARD SXT Lite 5nD */ + ATH79_MACH_RW2458N, /* Redwave RW2458N */ + ATH79_MACH_SMART_300, /* NC-LINK SMART-300 */ ++ ATH79_MACH_SOM9331, /* OpenEmbed SOM9331 */ + ATH79_MACH_TEW_632BRP, /* TRENDnet TEW-632BRP */ + ATH79_MACH_TEW_673GRU, /* TRENDnet TEW-673GRU */ + ATH79_MACH_TEW_712BR, /* TRENDnet TEW-712BR */ @@ -282,7 +283,7 @@ config ATH79_MACH_AP121 bool "Atheros AP121 reference board" select SOC_AR933X -@@ -11,62 +84,1050 @@ config ATH79_MACH_AP121 +@@ -11,62 +84,1060 @@ config ATH79_MACH_AP121 select ATH79_DEV_M25P80 select ATH79_DEV_USB select ATH79_DEV_WMAC @@ -420,6 +421,16 @@ + select ATH79_DEV_USB + select ATH79_DEV_WMAC + ++config ATH79_MACH_SOM9331 ++ bool "SOM9331 support" ++ select SOC_AR933X ++ select ATH79_DEV_ETH ++ select ATH79_DEV_GPIO_BUTTONS ++ select ATH79_DEV_LEDS_GPIO ++ select ATH79_DEV_M25P80 ++ select ATH79_DEV_USB ++ select ATH79_DEV_WMAC ++ +config ATH79_MACH_WHR_HP_G300N + bool "Buffalo WHR-HP-G300N board support" + select SOC_AR724X @@ -1361,7 +1372,7 @@ config ATH79_MACH_UBNT_XM bool "Ubiquiti Networks XM/UniFi boards" -@@ -83,6 +1144,106 @@ config ATH79_MACH_UBNT_XM +@@ -83,6 +1154,106 @@ config ATH79_MACH_UBNT_XM Say 'Y' here if you want your kernel to support the Ubiquiti Networks XM (rev 1.0) board. @@ -1468,7 +1479,7 @@ endmenu config SOC_AR71XX -@@ -124,7 +1285,10 @@ config ATH79_DEV_DSA +@@ -124,7 +1295,10 @@ config ATH79_DEV_DSA config ATH79_DEV_ETH def_bool n @@ -1480,7 +1491,7 @@ def_bool n config ATH79_DEV_GPIO_BUTTONS -@@ -154,6 +1318,11 @@ config ATH79_PCI_ATH9K_FIXUP +@@ -154,6 +1328,11 @@ config ATH79_PCI_ATH9K_FIXUP def_bool n config ATH79_ROUTERBOOT @@ -1494,7 +1505,7 @@ endif --- a/arch/mips/ath79/Makefile +++ b/arch/mips/ath79/Makefile -@@ -38,9 +38,128 @@ obj-$(CONFIG_ATH79_ROUTERBOOT) += route +@@ -38,9 +38,129 @@ obj-$(CONFIG_ATH79_ROUTERBOOT) += route # # Machines # @@ -1565,6 +1576,7 @@ +obj-$(CONFIG_ATH79_MACH_RBSXTLITE) += mach-rbsxtlite.o +obj-$(CONFIG_ATH79_MACH_RW2458N) += mach-rw2458n.o +obj-$(CONFIG_ATH79_MACH_SMART_300) += mach-smart-300.o ++obj-$(CONFIG_ATH79_MACH_SOM9331) += mach-som9331.o +obj-$(CONFIG_ATH79_MACH_TEW_632BRP) += mach-tew-632brp.o +obj-$(CONFIG_ATH79_MACH_TEW_673GRU) += mach-tew-673gru.o +obj-$(CONFIG_ATH79_MACH_TEW_712BR) += mach-tew-712br.o diff --git a/tools/firmware-utils/src/mktplinkfw.c b/tools/firmware-utils/src/mktplinkfw.c index 6df869d..743fb07 100644 --- a/tools/firmware-utils/src/mktplinkfw.c +++ b/tools/firmware-utils/src/mktplinkfw.c @@ -35,6 +35,7 @@ #define HWID_GL_INET_V1 0x08000001 #define HWID_GS_OOLITE_V1 0x3C000101 #define HWID_ONION_OMEGA 0x04700001 +#define HWID_SOM9331 0x04800054 #define HWID_TL_MR10U_V1 0x00100101 #define HWID_TL_MR13U_V1 0x00130101 #define HWID_TL_MR3020_V1 0x30200001 @@ -432,6 +433,11 @@ static struct board_info boards[] = { .hw_rev = 1, .layout_id = "16Mlzma", }, { + .id = "SOM9331", + .hw_id = HWID_SOM9331, + .hw_rev = 1, + .layout_id = "8Mlzma", + }, { .id = "ANTMINER-S1", .hw_id = HWID_ANTMINER_S1, .hw_rev = 1, _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From huynhminhdang at gmail.com Sun May 29 21:39:37 2016 From: huynhminhdang at gmail.com (Danng) Date: Mon, 30 May 2016 09:39:37 +0800 Subject: [OpenWrt-Devel] How to debug/config qos-scripts to work with OpenWRT AA? In-Reply-To: References: Message-ID: Hello, anyone interested? On Thu, May 26, 2016 at 11:03 AM, Danng wrote: > Hello, > > I am trying to use qos-scripts in OpenWRT AA. I have an issue that the > qos-scripts can limit uplink speed but not downlink speed. > > For example: I set 128kbit uplink and 1024kbit downlink, however, the > downlink is limitless > > This is the speedtest I captured > > http://speedof.me/show.php?img=160526022701-7038.png > > - uplink can go up to 104kbps > - downlink can go up to 7861kbps (which is higher than the limitation I > set) > > --- > > I also tried with wshaper and the got same result. > > Here is my setup: > - eth1 is the WAN port > - eth0 is connect to my PC > - OpenWRT AA > - Linux kernel 3.3.8 > > **************************************************************************** > * cmd: cat /etc/config/qos > **************************************************************************** > > # QoS configuration for OpenWrt > > # INTERFACES: > config interface wan > option classgroup "Default" > option enabled 1 > option upload 128 > option download 1024 > > # RULES: > config classify > option target "Priority" > option ports "22,53" > option comment "ssh, dns" > config classify > option target "Normal" > option proto "tcp" > option ports "20,21,25,80,110,443,993,995" > option comment "ftp, smtp, http(s), imap" > config classify > option target "Express" > option ports "5190" > option comment "AOL, iChat, ICQ" > config default > option target "Express" > option proto "udp" > option pktsize "-500" > config reclassify > option target "Priority" > option proto "icmp" > config default > option target "Bulk" > option portrange "1024-65535" > > > # Don't change the stuff below unless you > # really know what it means :) > > config classgroup "Default" > option classes "Priority Express Normal Bulk" > option default "Normal" > > > config class "Priority" > option packetsize 400 > option avgrate 10 > option priority 20 > config class "Priority_down" > option packetsize 1000 > option avgrate 10 > > > config class "Express" > option packetsize 1000 > option avgrate 50 > option priority 10 > > config class "Normal" > option packetsize 1500 > option packetdelay 100 > option avgrate 10 > option priority 5 > config class "Normal_down" > option avgrate 20 > > config class "Bulk" > option avgrate 1 > option packetdelay 200 > > **************************************************************************** > * cmd: /usr/lib/qos/generate.sh all > **************************************************************************** > | insmod cls_u32 >&- 2>&- > | insmod em_u32 >&- 2>&- > | insmod act_connmark >&- 2>&- > | insmod act_mirred >&- 2>&- > | insmod sch_ingress >&- 2>&- > | insmod cls_fw >&- 2>&- > | insmod sch_hfsc >&- 2>&- > | insmod sch_fq_codel >&- 2>&- > | ifconfig eth1 up txqueuelen 5 >&- 2>&- > | tc qdisc del dev eth1 root >&- 2>&- > | tc qdisc add dev eth1 root handle 1: hfsc default 30 > | tc class add dev eth1 parent 1: classid 1:1 hfsc sc rate 128kbit ul rate 128kbit > | tc class add dev eth1 parent 1:1 classid 1:10 hfsc rt m1 74kbit d 6103us m2 12kbit ls m1 74kbit d 6103us m2 71kbit ul rate 128kbit > | tc class add dev eth1 parent 1:1 classid 1:20 hfsc rt m1 68kbit d 15258us m2 64kbit ls m1 68kbit d 15258us m2 35kbit ul rate 128kbit > | tc class add dev eth1 parent 1:1 classid 1:30 hfsc ls m1 0kbit d 100000us m2 17kbit ul rate 128kbit > | tc class add dev eth1 parent 1:1 classid 1:40 hfsc ls m1 0kbit d 200000us m2 3kbit ul rate 128kbit > | tc qdisc add dev eth1 parent 1:10 handle 100: fq_codel > | tc qdisc add dev eth1 parent 1:20 handle 200: fq_codel > | tc qdisc add dev eth1 parent 1:30 handle 300: fq_codel > | tc qdisc add dev eth1 parent 1:40 handle 400: fq_codel > | tc filter add dev eth1 parent 1: prio 1 protocol ip handle 1/0xff fw flowid 1:10 > | tc filter add dev eth1 parent 1: prio 2 protocol ip handle 2/0xff fw flowid 1:20 > | tc filter add dev eth1 parent 1: prio 3 protocol ip handle 3/0xff fw flowid 1:30 > | tc filter add dev eth1 parent 1: prio 4 protocol ip handle 4/0xff fw flowid 1:40 > | ifconfig ifb0 up txqueuelen 5 >&- 2>&- > | tc qdisc del dev ifb0 root >&- 2>&- > | tc qdisc add dev ifb0 root handle 1: hfsc default 30 > | tc class add dev ifb0 parent 1: classid 1:1 hfsc sc rate 1024kbit ul rate 1024kbit > | tc qdisc del dev eth1 ingress >&- 2>&- > | tc qdisc add dev eth1 ingress > | tc filter add dev eth1 parent ffff: protocol ip prio 1 u32 match u32 0 0 flowid 1:1 action connmark action mirred egress redirect dev ifb0 > | tc class add dev ifb0 parent 1:1 classid 1:10 hfsc rt m1 232kbit d 1907us m2 102kbit ls m1 232kbit d 1907us m2 568kbit ul rate 1024kbit > | tc class add dev ifb0 parent 1:1 classid 1:20 hfsc rt m1 533kbit d 1907us m2 512kbit ls m1 533kbit d 1907us m2 284kbit ul rate 1024kbit > | tc class add dev ifb0 parent 1:1 classid 1:30 hfsc ls m1 0kbit d 100000us m2 142kbit ul rate 1024kbit > | tc class add dev ifb0 parent 1:1 classid 1:40 hfsc ls m1 0kbit d 200000us m2 28kbit ul rate 1024kbit > | tc qdisc add dev ifb0 parent 1:10 handle 100: fq_codel > | tc qdisc add dev ifb0 parent 1:20 handle 200: fq_codel > | tc qdisc add dev ifb0 parent 1:30 handle 300: fq_codel > | tc qdisc add dev ifb0 parent 1:40 handle 400: fq_codel > | tc filter add dev ifb0 parent 1: prio 1 protocol ip handle 1/0xff fw flowid 1:10 > | tc filter add dev ifb0 parent 1: prio 2 protocol ip handle 2/0xff fw flowid 1:20 > | tc filter add dev ifb0 parent 1: prio 3 protocol ip handle 3/0xff fw flowid 1:30 > | tc filter add dev ifb0 parent 1: prio 4 protocol ip handle 4/0xff fw flowid 1:40 > | > | > | > | iptables -t mangle -F qos_Default > | iptables -t mangle -F qos_Default_ct > | iptables -t mangle -D FORWARD -o eth1 -j qos_Default > | iptables -t mangle -D OUTPUT -o eth1 -j qos_Default > | iptables -t mangle -X qos_Default > | iptables -t mangle -X qos_Default_ct > | insmod ipt_multiport >&- 2>&- > | insmod ipt_CONNMARK >&- 2>&- > | insmod ipt_length >&- 2>&- > | iptables -t mangle -N qos_Default >&- 2>&- > | iptables -t mangle -N qos_Default_ct >&- 2>&- > | iptables -t mangle -A qos_Default_ct -m mark --mark 0/0xff -m tcp -p tcp -m multiport --ports 22,53 -j MARK --set-mark 1/0xff > | iptables -t mangle -A qos_Default_ct -m mark --mark 0/0xff -p udp -m udp -m multiport --ports 22,53 -j MARK --set-mark 1/0xff > | iptables -t mangle -A qos_Default_ct -m mark --mark 0/0xff -p tcp -m tcp -m multiport --ports 20,21,25,80,110,443,993,995 -j MARK --set-mark 3/0xff > | iptables -t mangle -A qos_Default_ct -m mark --mark 0/0xff -m tcp -p tcp -m multiport --ports 5190 -j MARK --set-mark 2/0xff > | iptables -t mangle -A qos_Default_ct -m mark --mark 0/0xff -p udp -m udp -m multiport --ports 5190 -j MARK --set-mark 2/0xff > | iptables -t mangle -A qos_Default_ct -j CONNMARK --save-mark --mask 0xff > | iptables -t mangle -A qos_Default -j CONNMARK --restore-mark --mask 0xff > | iptables -t mangle -A qos_Default -m mark --mark 0/0xff -j qos_Default_ct > | iptables -t mangle -A qos_Default -m mark --mark 0/0xff -p udp -m length --length :500 -j MARK --set-mark 2/0xff > | iptables -t mangle -A qos_Default -p icmp -j MARK --set-mark 1/0xff > | iptables -t mangle -A qos_Default -m mark --mark 0/0xff -m tcp -p tcp --sport 1024:65535 --dport 1024:65535 -j MARK --set-mark 4/0xff > | iptables -t mangle -A qos_Default -m mark --mark 0/0xff -p udp -m udp --sport 1024:65535 --dport 1024:65535 -j MARK --set-mark 4/0xff > | iptables -t mangle -A OUTPUT -o eth1 -j qos_Default > | iptables -t mangle -A FORWARD -o eth1 -j qos_Default > \--------------------------------------------------------------------------- > > **************************************************************************** > * cmd: iptables -L > **************************************************************************** > | Chain INPUT (policy ACCEPT) > | target prot opt source destination > | ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED > | ACCEPT all -- anywhere anywhere > | syn_flood tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN > | input_rule all -- anywhere anywhere > | input all -- anywhere anywhere > | > | Chain FORWARD (policy DROP) > | target prot opt source destination > | ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED > | forwarding_rule all -- anywhere anywhere > | forward all -- anywhere anywhere > | reject all -- anywhere anywhere > | > | Chain OUTPUT (policy ACCEPT) > | target prot opt source destination > | ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED > | ACCEPT all -- anywhere anywhere > | output_rule all -- anywhere anywhere > | output all -- anywhere anywhere > | > | Chain MINIUPNPD (1 references) > | target prot opt source destination > | > | Chain forward (1 references) > | target prot opt source destination > | zone_lan_forward all -- anywhere anywhere > | zone_wan_forward all -- anywhere anywhere > | > | Chain forwarding_lan (1 references) > | target prot opt source destination > | > | Chain forwarding_rule (1 references) > | target prot opt source destination > | > | Chain forwarding_wan (1 references) > | target prot opt source destination > | > | Chain input (1 references) > | target prot opt source destination > | zone_lan all -- anywhere anywhere > | zone_wan all -- anywhere anywhere > | > | Chain input_lan (1 references) > | target prot opt source destination > | > | Chain input_rule (1 references) > | target prot opt source destination > | > | Chain input_wan (1 references) > | target prot opt source destination > | > | Chain output (1 references) > | target prot opt source destination > | zone_lan_ACCEPT all -- anywhere anywhere > | zone_wan_ACCEPT all -- anywhere anywhere > | > | Chain output_rule (1 references) > | target prot opt source destination > | > | Chain reject (5 references) > | target prot opt source destination > | REJECT tcp -- anywhere anywhere reject-with tcp-reset > | REJECT all -- anywhere anywhere reject-with icmp-port-unreachable > | > | Chain syn_flood (1 references) > | target prot opt source destination > | RETURN tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN limit: avg 25/sec burst 50 > | DROP all -- anywhere anywhere > | > | Chain zone_lan (1 references) > | target prot opt source destination > | input_lan all -- anywhere anywhere > | zone_lan_ACCEPT all -- anywhere anywhere > | > | Chain zone_lan_ACCEPT (2 references) > | target prot opt source destination > | ACCEPT all -- anywhere anywhere > | ACCEPT all -- anywhere anywhere > | > | Chain zone_lan_DROP (0 references) > | target prot opt source destination > | DROP all -- anywhere anywhere > | DROP all -- anywhere anywhere > | > | Chain zone_lan_REJECT (1 references) > | target prot opt source destination > | reject all -- anywhere anywhere > | reject all -- anywhere anywhere > | > | Chain zone_lan_forward (1 references) > | target prot opt source destination > | zone_wan_ACCEPT all -- anywhere anywhere > | forwarding_lan all -- anywhere anywhere > | zone_lan_REJECT all -- anywhere anywhere > | > | Chain zone_wan (1 references) > | target prot opt source destination > | ACCEPT udp -- anywhere anywhere udp dpt:bootpc > | ACCEPT icmp -- anywhere anywhere icmp echo-request > | input_wan all -- anywhere anywhere > | zone_wan_REJECT all -- anywhere anywhere > | > | Chain zone_wan_ACCEPT (2 references) > | target prot opt source destination > | ACCEPT all -- anywhere anywhere > | ACCEPT all -- anywhere anywhere > | > | Chain zone_wan_DROP (0 references) > | target prot opt source destination > | DROP all -- anywhere anywhere > | DROP all -- anywhere anywhere > | > | Chain zone_wan_REJECT (2 references) > | target prot opt source destination > | reject all -- anywhere anywhere > | reject all -- anywhere anywhere > | > | Chain zone_wan_forward (1 references) > | target prot opt source destination > | MINIUPNPD all -- anywhere anywhere > | forwarding_wan all -- anywhere anywhere > | zone_wan_REJECT all -- anywhere anywhere > \--------------------------------------------------------------------------- > > **************************************************************************** > * cmd: iptables -t nat -L > **************************************************************************** > | Chain PREROUTING (policy ACCEPT) > | target prot opt source destination > | prerouting_rule all -- anywhere anywhere > | zone_lan_prerouting all -- anywhere anywhere > | zone_wan_prerouting all -- anywhere anywhere > | > | Chain INPUT (policy ACCEPT) > | target prot opt source destination > | > | Chain OUTPUT (policy ACCEPT) > | target prot opt source destination > | > | Chain POSTROUTING (policy ACCEPT) > | target prot opt source destination > | postrouting_rule all -- anywhere anywhere > | zone_lan_nat all -- anywhere anywhere > | zone_wan_nat all -- anywhere anywhere > | > | Chain MINIUPNPD (1 references) > | target prot opt source destination > | > | Chain postrouting_rule (1 references) > | target prot opt source destination > | > | Chain prerouting_lan (1 references) > | target prot opt source destination > | > | Chain prerouting_rule (1 references) > | target prot opt source destination > | > | Chain prerouting_wan (1 references) > | target prot opt source destination > | > | Chain zone_lan_nat (1 references) > | target prot opt source destination > | > | Chain zone_lan_prerouting (1 references) > | target prot opt source destination > | prerouting_lan all -- anywhere anywhere > | > | Chain zone_wan_nat (1 references) > | target prot opt source destination > | MASQUERADE all -- anywhere anywhere > | > | Chain zone_wan_prerouting (1 references) > | target prot opt source destination > | MINIUPNPD all -- anywhere anywhere > | prerouting_wan all -- anywhere anywhere > \--------------------------------------------------------------------------- > > **************************************************************************** > * cmd: iptables -t mangle -L > **************************************************************************** > | Chain PREROUTING (policy ACCEPT) > | target prot opt source destination > | > | Chain INPUT (policy ACCEPT) > | target prot opt source destination > | > | Chain FORWARD (policy ACCEPT) > | target prot opt source destination > | zone_wan_MSSFIX all -- anywhere anywhere > | qos_Default all -- anywhere anywhere > | > | Chain OUTPUT (policy ACCEPT) > | target prot opt source destination > | qos_Default all -- anywhere anywhere > | > | Chain POSTROUTING (policy ACCEPT) > | target prot opt source destination > | > | Chain qos_Default (2 references) > | target prot opt source destination > | CONNMARK all -- anywhere anywhere CONNMARK restore mask 0xff > | qos_Default_ct all -- anywhere anywhere mark match 0x0/0xff > | MARK udp -- anywhere anywhere mark match 0x0/0xff length 0:500 MARK xset 0x2/0xff > | MARK icmp -- anywhere anywhere MARK xset 0x1/0xff > | MARK tcp -- anywhere anywhere mark match 0x0/0xff tcp spts:1024:65535 dpts:1024:65535 MARK xset 0x4/0xff > | MARK udp -- anywhere anywhere mark match 0x0/0xff udp spts:1024:65535 dpts:1024:65535 MARK xset 0x4/0xff > | > | Chain qos_Default_ct (1 references) > | target prot opt source destination > | MARK tcp -- anywhere anywhere mark match 0x0/0xff tcp multiport ports ssh,domain MARK xset 0x1/0xff > | MARK udp -- anywhere anywhere mark match 0x0/0xff udp multiport ports ssh,domain MARK xset 0x1/0xff > | MARK tcp -- anywhere anywhere mark match 0x0/0xff tcp multiport ports ftp-data,ftp,smtp,www,pop3,https,imaps,pop3s MARK xset 0x3/0xff > | MARK tcp -- anywhere anywhere mark match 0x0/0xff tcp multiport ports 5190 MARK xset 0x2/0xff > | MARK udp -- anywhere anywhere mark match 0x0/0xff udp multiport ports 5190 MARK xset 0x2/0xff > | CONNMARK all -- anywhere anywhere CONNMARK save mask 0xff > | > | Chain zone_wan_MSSFIX (1 references) > | target prot opt source destination > | TCPMSS tcp -- anywhere anywhere tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU > \--------------------------------------------------------------------------- > > **************************************************************************** > * cmd: tc -s qdisc show dev eth0 > **************************************************************************** > | qdisc pfifo_fast 0: root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 > | Sent 278256856 bytes 260097 pkt (dropped 0, overlimits 0 requeues 0) > | backlog 0b 0p requeues 0 > \--------------------------------------------------------------------------- > > **************************************************************************** > * cmd: tc -s qdisc show dev eth1 > **************************************************************************** > | qdisc hfsc 1: root refcnt 2 default 30 > | Sent 1447188 bytes 7376 pkt (dropped 0, overlimits 12468 requeues 0) > | backlog 0b 0p requeues 0 > | qdisc fq_codel 100: parent 1:10 limit 10240p flows 1024 quantum 1518 target 5.0ms interval 100.0ms ecn > | Sent 5000 bytes 55 pkt (dropped 0, overlimits 0 requeues 0) > | backlog 0b 0p requeues 0 > | maxpacket 256 drop_overlimit 0 new_flow_count 27 ecn_mark 0 > | new_flows_len 1 old_flows_len 0 > | qdisc fq_codel 200: parent 1:20 limit 10240p flows 1024 quantum 1518 target 5.0ms interval 100.0ms ecn > | Sent 19246 bytes 145 pkt (dropped 0, overlimits 0 requeues 0) > | backlog 0b 0p requeues 0 > | maxpacket 350 drop_overlimit 0 new_flow_count 80 ecn_mark 0 > | new_flows_len 0 old_flows_len 2 > | qdisc fq_codel 300: parent 1:30 limit 10240p flows 1024 quantum 1518 target 5.0ms interval 100.0ms ecn > | Sent 720529 bytes 2687 pkt (dropped 223, overlimits 0 requeues 0) > | backlog 0b 0p requeues 0 > | maxpacket 1514 drop_overlimit 0 new_flow_count 750 ecn_mark 0 > | new_flows_len 1 old_flows_len 5 > | qdisc fq_codel 400: parent 1:40 limit 10240p flows 1024 quantum 1518 target 5.0ms interval 100.0ms ecn > | Sent 702413 bytes 4489 pkt (dropped 1461, overlimits 0 requeues 0) > | backlog 0b 0p requeues 0 > | maxpacket 1514 drop_overlimit 0 new_flow_count 271 ecn_mark 0 > | new_flows_len 0 old_flows_len 1 > | qdisc ingress ffff: parent ffff:fff1 ---------------- > | Sent 1639987 bytes 3843 pkt (dropped 0, overlimits 0 requeues 0) > | backlog 0b 0p requeues 0 > \--------------------------------------------------------------------------- > > **************************************************************************** > * cmd: tc -s qdisc show dev ifb0 > **************************************************************************** > | qdisc hfsc 1: root refcnt 2 default 30 > | Sent 1391951 bytes 2762 pkt (dropped 0, overlimits 2001 requeues 0) > | backlog 0b 0p requeues 0 > | qdisc fq_codel 100: parent 1:10 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn > | Sent 4723 bytes 23 pkt (dropped 0, overlimits 0 requeues 0) > | backlog 0b 0p requeues 0 > | maxpacket 299 drop_overlimit 0 new_flow_count 21 ecn_mark 0 > | new_flows_len 1 old_flows_len 0 > | qdisc fq_codel 200: parent 1:20 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn > | Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > | backlog 0b 0p requeues 0 > | maxpacket 256 drop_overlimit 0 new_flow_count 0 ecn_mark 0 > | new_flows_len 0 old_flows_len 0 > | qdisc fq_codel 300: parent 1:30 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn > | Sent 1387228 bytes 2739 pkt (dropped 127, overlimits 0 requeues 0) > | backlog 0b 0p requeues 0 > | maxpacket 1518 drop_overlimit 0 new_flow_count 1052 ecn_mark 0 > | new_flows_len 1 old_flows_len 1 > | qdisc fq_codel 400: parent 1:40 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn > | Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > | backlog 0b 0p requeues 0 > | maxpacket 256 drop_overlimit 0 new_flow_count 0 ecn_mark 0 > | new_flows_len 0 old_flows_len 0 > \--------------------------------------------------------------------------- > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From reinoudkoornstra at gmail.com Sun May 29 21:59:06 2016 From: reinoudkoornstra at gmail.com (Reinoud Koornstra) Date: Sun, 29 May 2016 19:59:06 -0600 Subject: [OpenWrt-Devel] How to debug/config qos-scripts to work with OpenWRT AA? In-Reply-To: References: Message-ID: Traditionally this is correct. However now uplink and downlink are possible with Cake. A more advanced fq_codel. You can find it on bufferbloat from Dave Taht. You'll also need his iproute2 to recognize that qdisc. Pretty easy to compilie it in openwrt and have fun with it. Thanks, Reinoud. On May 25, 2016 9:04 PM, "Danng" wrote: > Hello, > > I am trying to use qos-scripts in OpenWRT AA. I have an issue that the > qos-scripts can limit uplink speed but not downlink speed. > > For example: I set 128kbit uplink and 1024kbit downlink, however, the > downlink is limitless > > This is the speedtest I captured > > http://speedof.me/show.php?img=160526022701-7038.png > > - uplink can go up to 104kbps > - downlink can go up to 7861kbps (which is higher than the limitation I > set) > > --- > > I also tried with wshaper and the got same result. > > Here is my setup: > - eth1 is the WAN port > - eth0 is connect to my PC > - OpenWRT AA > - Linux kernel 3.3.8 > > **************************************************************************** > * cmd: cat /etc/config/qos > **************************************************************************** > > # QoS configuration for OpenWrt > > # INTERFACES: > config interface wan > option classgroup "Default" > option enabled 1 > option upload 128 > option download 1024 > > # RULES: > config classify > option target "Priority" > option ports "22,53" > option comment "ssh, dns" > config classify > option target "Normal" > option proto "tcp" > option ports "20,21,25,80,110,443,993,995" > option comment "ftp, smtp, http(s), imap" > config classify > option target "Express" > option ports "5190" > option comment "AOL, iChat, ICQ" > config default > option target "Express" > option proto "udp" > option pktsize "-500" > config reclassify > option target "Priority" > option proto "icmp" > config default > option target "Bulk" > option portrange "1024-65535" > > > # Don't change the stuff below unless you > # really know what it means :) > > config classgroup "Default" > option classes "Priority Express Normal Bulk" > option default "Normal" > > > config class "Priority" > option packetsize 400 > option avgrate 10 > option priority 20 > config class "Priority_down" > option packetsize 1000 > option avgrate 10 > > > config class "Express" > option packetsize 1000 > option avgrate 50 > option priority 10 > > config class "Normal" > option packetsize 1500 > option packetdelay 100 > option avgrate 10 > option priority 5 > config class "Normal_down" > option avgrate 20 > > config class "Bulk" > option avgrate 1 > option packetdelay 200 > > **************************************************************************** > * cmd: /usr/lib/qos/generate.sh all > **************************************************************************** > | insmod cls_u32 >&- 2>&- > | insmod em_u32 >&- 2>&- > | insmod act_connmark >&- 2>&- > | insmod act_mirred >&- 2>&- > | insmod sch_ingress >&- 2>&- > | insmod cls_fw >&- 2>&- > | insmod sch_hfsc >&- 2>&- > | insmod sch_fq_codel >&- 2>&- > | ifconfig eth1 up txqueuelen 5 >&- 2>&- > | tc qdisc del dev eth1 root >&- 2>&- > | tc qdisc add dev eth1 root handle 1: hfsc default 30 > | tc class add dev eth1 parent 1: classid 1:1 hfsc sc rate 128kbit ul rate 128kbit > | tc class add dev eth1 parent 1:1 classid 1:10 hfsc rt m1 74kbit d 6103us m2 12kbit ls m1 74kbit d 6103us m2 71kbit ul rate 128kbit > | tc class add dev eth1 parent 1:1 classid 1:20 hfsc rt m1 68kbit d 15258us m2 64kbit ls m1 68kbit d 15258us m2 35kbit ul rate 128kbit > | tc class add dev eth1 parent 1:1 classid 1:30 hfsc ls m1 0kbit d 100000us m2 17kbit ul rate 128kbit > | tc class add dev eth1 parent 1:1 classid 1:40 hfsc ls m1 0kbit d 200000us m2 3kbit ul rate 128kbit > | tc qdisc add dev eth1 parent 1:10 handle 100: fq_codel > | tc qdisc add dev eth1 parent 1:20 handle 200: fq_codel > | tc qdisc add dev eth1 parent 1:30 handle 300: fq_codel > | tc qdisc add dev eth1 parent 1:40 handle 400: fq_codel > | tc filter add dev eth1 parent 1: prio 1 protocol ip handle 1/0xff fw flowid 1:10 > | tc filter add dev eth1 parent 1: prio 2 protocol ip handle 2/0xff fw flowid 1:20 > | tc filter add dev eth1 parent 1: prio 3 protocol ip handle 3/0xff fw flowid 1:30 > | tc filter add dev eth1 parent 1: prio 4 protocol ip handle 4/0xff fw flowid 1:40 > | ifconfig ifb0 up txqueuelen 5 >&- 2>&- > | tc qdisc del dev ifb0 root >&- 2>&- > | tc qdisc add dev ifb0 root handle 1: hfsc default 30 > | tc class add dev ifb0 parent 1: classid 1:1 hfsc sc rate 1024kbit ul rate 1024kbit > | tc qdisc del dev eth1 ingress >&- 2>&- > | tc qdisc add dev eth1 ingress > | tc filter add dev eth1 parent ffff: protocol ip prio 1 u32 match u32 0 0 flowid 1:1 action connmark action mirred egress redirect dev ifb0 > | tc class add dev ifb0 parent 1:1 classid 1:10 hfsc rt m1 232kbit d 1907us m2 102kbit ls m1 232kbit d 1907us m2 568kbit ul rate 1024kbit > | tc class add dev ifb0 parent 1:1 classid 1:20 hfsc rt m1 533kbit d 1907us m2 512kbit ls m1 533kbit d 1907us m2 284kbit ul rate 1024kbit > | tc class add dev ifb0 parent 1:1 classid 1:30 hfsc ls m1 0kbit d 100000us m2 142kbit ul rate 1024kbit > | tc class add dev ifb0 parent 1:1 classid 1:40 hfsc ls m1 0kbit d 200000us m2 28kbit ul rate 1024kbit > | tc qdisc add dev ifb0 parent 1:10 handle 100: fq_codel > | tc qdisc add dev ifb0 parent 1:20 handle 200: fq_codel > | tc qdisc add dev ifb0 parent 1:30 handle 300: fq_codel > | tc qdisc add dev ifb0 parent 1:40 handle 400: fq_codel > | tc filter add dev ifb0 parent 1: prio 1 protocol ip handle 1/0xff fw flowid 1:10 > | tc filter add dev ifb0 parent 1: prio 2 protocol ip handle 2/0xff fw flowid 1:20 > | tc filter add dev ifb0 parent 1: prio 3 protocol ip handle 3/0xff fw flowid 1:30 > | tc filter add dev ifb0 parent 1: prio 4 protocol ip handle 4/0xff fw flowid 1:40 > | > | > | > | iptables -t mangle -F qos_Default > | iptables -t mangle -F qos_Default_ct > | iptables -t mangle -D FORWARD -o eth1 -j qos_Default > | iptables -t mangle -D OUTPUT -o eth1 -j qos_Default > | iptables -t mangle -X qos_Default > | iptables -t mangle -X qos_Default_ct > | insmod ipt_multiport >&- 2>&- > | insmod ipt_CONNMARK >&- 2>&- > | insmod ipt_length >&- 2>&- > | iptables -t mangle -N qos_Default >&- 2>&- > | iptables -t mangle -N qos_Default_ct >&- 2>&- > | iptables -t mangle -A qos_Default_ct -m mark --mark 0/0xff -m tcp -p tcp -m multiport --ports 22,53 -j MARK --set-mark 1/0xff > | iptables -t mangle -A qos_Default_ct -m mark --mark 0/0xff -p udp -m udp -m multiport --ports 22,53 -j MARK --set-mark 1/0xff > | iptables -t mangle -A qos_Default_ct -m mark --mark 0/0xff -p tcp -m tcp -m multiport --ports 20,21,25,80,110,443,993,995 -j MARK --set-mark 3/0xff > | iptables -t mangle -A qos_Default_ct -m mark --mark 0/0xff -m tcp -p tcp -m multiport --ports 5190 -j MARK --set-mark 2/0xff > | iptables -t mangle -A qos_Default_ct -m mark --mark 0/0xff -p udp -m udp -m multiport --ports 5190 -j MARK --set-mark 2/0xff > | iptables -t mangle -A qos_Default_ct -j CONNMARK --save-mark --mask 0xff > | iptables -t mangle -A qos_Default -j CONNMARK --restore-mark --mask 0xff > | iptables -t mangle -A qos_Default -m mark --mark 0/0xff -j qos_Default_ct > | iptables -t mangle -A qos_Default -m mark --mark 0/0xff -p udp -m length --length :500 -j MARK --set-mark 2/0xff > | iptables -t mangle -A qos_Default -p icmp -j MARK --set-mark 1/0xff > | iptables -t mangle -A qos_Default -m mark --mark 0/0xff -m tcp -p tcp --sport 1024:65535 --dport 1024:65535 -j MARK --set-mark 4/0xff > | iptables -t mangle -A qos_Default -m mark --mark 0/0xff -p udp -m udp --sport 1024:65535 --dport 1024:65535 -j MARK --set-mark 4/0xff > | iptables -t mangle -A OUTPUT -o eth1 -j qos_Default > | iptables -t mangle -A FORWARD -o eth1 -j qos_Default > \--------------------------------------------------------------------------- > > **************************************************************************** > * cmd: iptables -L > **************************************************************************** > | Chain INPUT (policy ACCEPT) > | target prot opt source destination > | ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED > | ACCEPT all -- anywhere anywhere > | syn_flood tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN > | input_rule all -- anywhere anywhere > | input all -- anywhere anywhere > | > | Chain FORWARD (policy DROP) > | target prot opt source destination > | ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED > | forwarding_rule all -- anywhere anywhere > | forward all -- anywhere anywhere > | reject all -- anywhere anywhere > | > | Chain OUTPUT (policy ACCEPT) > | target prot opt source destination > | ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED > | ACCEPT all -- anywhere anywhere > | output_rule all -- anywhere anywhere > | output all -- anywhere anywhere > | > | Chain MINIUPNPD (1 references) > | target prot opt source destination > | > | Chain forward (1 references) > | target prot opt source destination > | zone_lan_forward all -- anywhere anywhere > | zone_wan_forward all -- anywhere anywhere > | > | Chain forwarding_lan (1 references) > | target prot opt source destination > | > | Chain forwarding_rule (1 references) > | target prot opt source destination > | > | Chain forwarding_wan (1 references) > | target prot opt source destination > | > | Chain input (1 references) > | target prot opt source destination > | zone_lan all -- anywhere anywhere > | zone_wan all -- anywhere anywhere > | > | Chain input_lan (1 references) > | target prot opt source destination > | > | Chain input_rule (1 references) > | target prot opt source destination > | > | Chain input_wan (1 references) > | target prot opt source destination > | > | Chain output (1 references) > | target prot opt source destination > | zone_lan_ACCEPT all -- anywhere anywhere > | zone_wan_ACCEPT all -- anywhere anywhere > | > | Chain output_rule (1 references) > | target prot opt source destination > | > | Chain reject (5 references) > | target prot opt source destination > | REJECT tcp -- anywhere anywhere reject-with tcp-reset > | REJECT all -- anywhere anywhere reject-with icmp-port-unreachable > | > | Chain syn_flood (1 references) > | target prot opt source destination > | RETURN tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN limit: avg 25/sec burst 50 > | DROP all -- anywhere anywhere > | > | Chain zone_lan (1 references) > | target prot opt source destination > | input_lan all -- anywhere anywhere > | zone_lan_ACCEPT all -- anywhere anywhere > | > | Chain zone_lan_ACCEPT (2 references) > | target prot opt source destination > | ACCEPT all -- anywhere anywhere > | ACCEPT all -- anywhere anywhere > | > | Chain zone_lan_DROP (0 references) > | target prot opt source destination > | DROP all -- anywhere anywhere > | DROP all -- anywhere anywhere > | > | Chain zone_lan_REJECT (1 references) > | target prot opt source destination > | reject all -- anywhere anywhere > | reject all -- anywhere anywhere > | > | Chain zone_lan_forward (1 references) > | target prot opt source destination > | zone_wan_ACCEPT all -- anywhere anywhere > | forwarding_lan all -- anywhere anywhere > | zone_lan_REJECT all -- anywhere anywhere > | > | Chain zone_wan (1 references) > | target prot opt source destination > | ACCEPT udp -- anywhere anywhere udp dpt:bootpc > | ACCEPT icmp -- anywhere anywhere icmp echo-request > | input_wan all -- anywhere anywhere > | zone_wan_REJECT all -- anywhere anywhere > | > | Chain zone_wan_ACCEPT (2 references) > | target prot opt source destination > | ACCEPT all -- anywhere anywhere > | ACCEPT all -- anywhere anywhere > | > | Chain zone_wan_DROP (0 references) > | target prot opt source destination > | DROP all -- anywhere anywhere > | DROP all -- anywhere anywhere > | > | Chain zone_wan_REJECT (2 references) > | target prot opt source destination > | reject all -- anywhere anywhere > | reject all -- anywhere anywhere > | > | Chain zone_wan_forward (1 references) > | target prot opt source destination > | MINIUPNPD all -- anywhere anywhere > | forwarding_wan all -- anywhere anywhere > | zone_wan_REJECT all -- anywhere anywhere > \--------------------------------------------------------------------------- > > **************************************************************************** > * cmd: iptables -t nat -L > **************************************************************************** > | Chain PREROUTING (policy ACCEPT) > | target prot opt source destination > | prerouting_rule all -- anywhere anywhere > | zone_lan_prerouting all -- anywhere anywhere > | zone_wan_prerouting all -- anywhere anywhere > | > | Chain INPUT (policy ACCEPT) > | target prot opt source destination > | > | Chain OUTPUT (policy ACCEPT) > | target prot opt source destination > | > | Chain POSTROUTING (policy ACCEPT) > | target prot opt source destination > | postrouting_rule all -- anywhere anywhere > | zone_lan_nat all -- anywhere anywhere > | zone_wan_nat all -- anywhere anywhere > | > | Chain MINIUPNPD (1 references) > | target prot opt source destination > | > | Chain postrouting_rule (1 references) > | target prot opt source destination > | > | Chain prerouting_lan (1 references) > | target prot opt source destination > | > | Chain prerouting_rule (1 references) > | target prot opt source destination > | > | Chain prerouting_wan (1 references) > | target prot opt source destination > | > | Chain zone_lan_nat (1 references) > | target prot opt source destination > | > | Chain zone_lan_prerouting (1 references) > | target prot opt source destination > | prerouting_lan all -- anywhere anywhere > | > | Chain zone_wan_nat (1 references) > | target prot opt source destination > | MASQUERADE all -- anywhere anywhere > | > | Chain zone_wan_prerouting (1 references) > | target prot opt source destination > | MINIUPNPD all -- anywhere anywhere > | prerouting_wan all -- anywhere anywhere > \--------------------------------------------------------------------------- > > **************************************************************************** > * cmd: iptables -t mangle -L > **************************************************************************** > | Chain PREROUTING (policy ACCEPT) > | target prot opt source destination > | > | Chain INPUT (policy ACCEPT) > | target prot opt source destination > | > | Chain FORWARD (policy ACCEPT) > | target prot opt source destination > | zone_wan_MSSFIX all -- anywhere anywhere > | qos_Default all -- anywhere anywhere > | > | Chain OUTPUT (policy ACCEPT) > | target prot opt source destination > | qos_Default all -- anywhere anywhere > | > | Chain POSTROUTING (policy ACCEPT) > | target prot opt source destination > | > | Chain qos_Default (2 references) > | target prot opt source destination > | CONNMARK all -- anywhere anywhere CONNMARK restore mask 0xff > | qos_Default_ct all -- anywhere anywhere mark match 0x0/0xff > | MARK udp -- anywhere anywhere mark match 0x0/0xff length 0:500 MARK xset 0x2/0xff > | MARK icmp -- anywhere anywhere MARK xset 0x1/0xff > | MARK tcp -- anywhere anywhere mark match 0x0/0xff tcp spts:1024:65535 dpts:1024:65535 MARK xset 0x4/0xff > | MARK udp -- anywhere anywhere mark match 0x0/0xff udp spts:1024:65535 dpts:1024:65535 MARK xset 0x4/0xff > | > | Chain qos_Default_ct (1 references) > | target prot opt source destination > | MARK tcp -- anywhere anywhere mark match 0x0/0xff tcp multiport ports ssh,domain MARK xset 0x1/0xff > | MARK udp -- anywhere anywhere mark match 0x0/0xff udp multiport ports ssh,domain MARK xset 0x1/0xff > | MARK tcp -- anywhere anywhere mark match 0x0/0xff tcp multiport ports ftp-data,ftp,smtp,www,pop3,https,imaps,pop3s MARK xset 0x3/0xff > | MARK tcp -- anywhere anywhere mark match 0x0/0xff tcp multiport ports 5190 MARK xset 0x2/0xff > | MARK udp -- anywhere anywhere mark match 0x0/0xff udp multiport ports 5190 MARK xset 0x2/0xff > | CONNMARK all -- anywhere anywhere CONNMARK save mask 0xff > | > | Chain zone_wan_MSSFIX (1 references) > | target prot opt source destination > | TCPMSS tcp -- anywhere anywhere tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU > \--------------------------------------------------------------------------- > > **************************************************************************** > * cmd: tc -s qdisc show dev eth0 > **************************************************************************** > | qdisc pfifo_fast 0: root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 > | Sent 278256856 bytes 260097 pkt (dropped 0, overlimits 0 requeues 0) > | backlog 0b 0p requeues 0 > \--------------------------------------------------------------------------- > > **************************************************************************** > * cmd: tc -s qdisc show dev eth1 > **************************************************************************** > | qdisc hfsc 1: root refcnt 2 default 30 > | Sent 1447188 bytes 7376 pkt (dropped 0, overlimits 12468 requeues 0) > | backlog 0b 0p requeues 0 > | qdisc fq_codel 100: parent 1:10 limit 10240p flows 1024 quantum 1518 target 5.0ms interval 100.0ms ecn > | Sent 5000 bytes 55 pkt (dropped 0, overlimits 0 requeues 0) > | backlog 0b 0p requeues 0 > | maxpacket 256 drop_overlimit 0 new_flow_count 27 ecn_mark 0 > | new_flows_len 1 old_flows_len 0 > | qdisc fq_codel 200: parent 1:20 limit 10240p flows 1024 quantum 1518 target 5.0ms interval 100.0ms ecn > | Sent 19246 bytes 145 pkt (dropped 0, overlimits 0 requeues 0) > | backlog 0b 0p requeues 0 > | maxpacket 350 drop_overlimit 0 new_flow_count 80 ecn_mark 0 > | new_flows_len 0 old_flows_len 2 > | qdisc fq_codel 300: parent 1:30 limit 10240p flows 1024 quantum 1518 target 5.0ms interval 100.0ms ecn > | Sent 720529 bytes 2687 pkt (dropped 223, overlimits 0 requeues 0) > | backlog 0b 0p requeues 0 > | maxpacket 1514 drop_overlimit 0 new_flow_count 750 ecn_mark 0 > | new_flows_len 1 old_flows_len 5 > | qdisc fq_codel 400: parent 1:40 limit 10240p flows 1024 quantum 1518 target 5.0ms interval 100.0ms ecn > | Sent 702413 bytes 4489 pkt (dropped 1461, overlimits 0 requeues 0) > | backlog 0b 0p requeues 0 > | maxpacket 1514 drop_overlimit 0 new_flow_count 271 ecn_mark 0 > | new_flows_len 0 old_flows_len 1 > | qdisc ingress ffff: parent ffff:fff1 ---------------- > | Sent 1639987 bytes 3843 pkt (dropped 0, overlimits 0 requeues 0) > | backlog 0b 0p requeues 0 > \--------------------------------------------------------------------------- > > **************************************************************************** > * cmd: tc -s qdisc show dev ifb0 > **************************************************************************** > | qdisc hfsc 1: root refcnt 2 default 30 > | Sent 1391951 bytes 2762 pkt (dropped 0, overlimits 2001 requeues 0) > | backlog 0b 0p requeues 0 > | qdisc fq_codel 100: parent 1:10 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn > | Sent 4723 bytes 23 pkt (dropped 0, overlimits 0 requeues 0) > | backlog 0b 0p requeues 0 > | maxpacket 299 drop_overlimit 0 new_flow_count 21 ecn_mark 0 > | new_flows_len 1 old_flows_len 0 > | qdisc fq_codel 200: parent 1:20 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn > | Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > | backlog 0b 0p requeues 0 > | maxpacket 256 drop_overlimit 0 new_flow_count 0 ecn_mark 0 > | new_flows_len 0 old_flows_len 0 > | qdisc fq_codel 300: parent 1:30 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn > | Sent 1387228 bytes 2739 pkt (dropped 127, overlimits 0 requeues 0) > | backlog 0b 0p requeues 0 > | maxpacket 1518 drop_overlimit 0 new_flow_count 1052 ecn_mark 0 > | new_flows_len 1 old_flows_len 1 > | qdisc fq_codel 400: parent 1:40 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn > | Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > | backlog 0b 0p requeues 0 > | maxpacket 256 drop_overlimit 0 new_flow_count 0 ecn_mark 0 > | new_flows_len 0 old_flows_len 0 > \--------------------------------------------------------------------------- > > > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From Dieter.Pfeuffer at men.de Mon May 30 04:49:19 2016 From: Dieter.Pfeuffer at men.de (Pfeuffer, Dieter) Date: Mon, 30 May 2016 08:49:19 +0000 Subject: [OpenWrt-Devel] [PATCH 0/8] mpc85xx: Introduce MEN NM50 device support Message-ID: <9da1f899f52e4a67b6760f237161893f@MEN-EX01.intra.men.de> Hi, any further comments to the patchset? Regards, Dieter -----Urspr?ngliche Nachricht----- Von: Pfeuffer, Dieter Gesendet: Mittwoch, 23. M?rz 2016 13:17 An: kaloz at openwrt.org Cc: Pfeuffer, Dieter ; openwrt-devel at lists.openwrt.org Betreff: [PATCH 0/8] mpc85xx: Introduce MEN NM50 device support This patchset adds support for the MEN NM50 WLAN Access Point to mpc85xx. The NM50 is an industrial stand-alone device, specifically designed for use in railway cars and automotive applications operating in rugged environmental conditions. NM50 features: - NXP PowerPC QorIQ P1013, 800 MHz - 1 GB DDR3 SDRAM - 32 MB NOR Flash - 2 Gigabit Ethernet ports - 1 USB 2.0 A port, 1 USB 2.0 B port - Up to 6 antennas - Wireless LAN according to IEEE802.11b/g/n - Dual RF, simultaneous 2.4 GHz and 5 GHz band support Dieter Pfeuffer (8): [PATCH 1/8] mpc85xx: add NM50 support to mpc85xx platform [PATCH 2/8] mpc85xx: add target NM50 to kernel config [PATCH 3/8] mpc85xx: add device tree for NM50 [PATCH 4/8] mpc85xx: add firmware upgrade support for NM50 [PATCH 5/8] mpc85xx: add 32Mppc flash layout in mktplinkfw for NM50 [PATCH 6/8] mpc85xx: increase timeout for NM50 fw-upgrade via luci [PATCH 7/8] mpc85xx: support NM50 in mpc85xx_board_detect [PATCH 8/8] mpc85xx: add NM50 config for fw_(printenv/setenv) scripts/men-mkfwupgrade.sh | 69 +++ target/linux/mpc85xx/Makefile | 2 +- target/linux/mpc85xx/base-files/etc/fw_env.config | 22 + .../base-files/etc/uci-defaults/men_nm50_uhttpd | 22 + target/linux/mpc85xx/base-files/lib/mpc85xx.sh | 3 + target/linux/mpc85xx/base-files/lib/upgrade/men.sh | 188 +++++++ .../mpc85xx/base-files/lib/upgrade/platform.sh | 10 +- .../files/arch/powerpc/boot/dts/men_nm50.dts | 25 + .../files/arch/powerpc/boot/dts/men_nm50.dtsi | 625 +++++++++++++++++++++ .../arch/powerpc/boot/dts/men_nm50_ubootrw.dts | 13 + .../files/arch/powerpc/platforms/85xx/men_nm50.c | 77 +++ target/linux/mpc85xx/image/Makefile | 21 +- target/linux/mpc85xx/men_nm50/config-default | 37 ++ target/linux/mpc85xx/men_nm50/target.mk | 5 + .../230-powerpc-85xx-men-nm50-support.patch | 22 + target/linux/mpc85xx/profiles/men-nm50.mk | 17 + tools/firmware-utils/src/mktplinkfw.c | 6 + 17 files changed, 1161 insertions(+), 3 deletions(-) create mode 100755 scripts/men-mkfwupgrade.sh create mode 100644 target/linux/mpc85xx/base-files/etc/fw_env.config create mode 100644 target/linux/mpc85xx/base-files/etc/uci-defaults/men_nm50_uhttpd create mode 100755 target/linux/mpc85xx/base-files/lib/upgrade/men.sh create mode 100644 target/linux/mpc85xx/files/arch/powerpc/boot/dts/men_nm50.dts create mode 100644 target/linux/mpc85xx/files/arch/powerpc/boot/dts/men_nm50.dtsi create mode 100644 target/linux/mpc85xx/files/arch/powerpc/boot/dts/men_nm50_ubootrw.dts create mode 100644 target/linux/mpc85xx/files/arch/powerpc/platforms/85xx/men_nm50.c create mode 100644 target/linux/mpc85xx/men_nm50/config-default create mode 100644 target/linux/mpc85xx/men_nm50/target.mk create mode 100644 target/linux/mpc85xx/patches-3.18/230-powerpc-85xx-men-nm50-support.patch create mode 100644 target/linux/mpc85xx/profiles/men-nm50.mk -- 1.9.1 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From Jos.Delbar at technicolor.com Mon May 30 04:51:07 2016 From: Jos.Delbar at technicolor.com (Delbar Jos) Date: Mon, 30 May 2016 08:51:07 +0000 Subject: [OpenWrt-Devel] [LEDE-DEV] TR-069 for OpenWrt In-Reply-To: References: <5749824F.9070000@hauke-m.de> Message-ID: David Lang wrote: > I wasn't questioning why it's useful to support TR-069. The only part I was > questioning was the statement that OpenWRT needed work to make it > support remote management. > > There are already many tools to remotely manage/monitor OpenWRT > > But that's why I'm saying that it seems like most of the work is in the protocol > interface. If there is already a daemon that does the network protocol > properly, that should make things very easy. If such a daemon needs to be > written, that would be the place I would suggest that they focus. There are a > lot of people who can do the plumbing work to make the daemon do the > right thing on the system, who are not in a position to work on the network > protocol side and make sure that it works properly with the management > software. Listing some of the things that come to mind: * Data models. The language that TR-069 uses to describe a certain feature or function is not the same language that OpenWrt uses. The translation is often not straightforward. * Events/notifications. This boils down to the TR-069 protocol agent notifying the ACS when something on the CPE changes. Now imagine that a change occurs to a configuration parameter in UCI, like the wireless SSID. How to address this? * Commit and apply. When the ACS changes the configuration of the CPE, it also expects this configuration to be applied soon after. Updating the configuration in UCI is not enough. * Transactional behavior. A set of TR-069 configuration changes is either applied successfully or not at all. UCI has a commit function but how to check if a configuration change in UCI will also be successfully applied by the system? Now one can debate what "successful" means but you get the point. * Persistent indices. TR-069 expects that a certain object in an array, like "the second network interface", retains its index "the second" during the lifetime of the CPE (barring a factory reset) even if "the first network interface" is deleted. The way that lists work in UCI doesn't make this trivial. Using named instances or aliases are possible ways out. We've attempted to overcome these challenges in our TR-069 solution within the confines of OpenWrt. I'm sure that other management systems (local ones like LuCi or remote ones) are solving similar problems in different ways. Instead of doing all the heavy lifting on the protocol side, I'm hopeful that we can carve out a common subset of requirements that apply to management systems in general and come to better and more reusable frameworks. Jos _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From Jos.Delbar at technicolor.com Mon May 30 04:59:46 2016 From: Jos.Delbar at technicolor.com (Delbar Jos) Date: Mon, 30 May 2016 08:59:46 +0000 Subject: [OpenWrt-Devel] [OpenWrt] TR-069 for OpenWrt In-Reply-To: References: Message-ID: Eric, Sounds good. Please continue scheduling the online meeting in parallel. I think we?ll need both. Jos From: Eric Schultz [mailto:eschultz at prplfoundation.org] I think your idea for an in-person workshop is a great idea. While we were planning on having a online meeting with the interested parties, I think an in-person workshop is an even better idea. There's a lot of potential code on the table and related projects to fund. I know from prpl's perspective we want to make sure the result is valuable to industry and the community. I don't want to put everyone on the spot so I'll contact individually Felix, Luka and Wotjek and get their feedback (unless they'd like to comment here). If everyone's in agreement, we can work out a time and place that works well for everyone. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From moeller0 at gmx.de Mon May 30 05:04:23 2016 From: moeller0 at gmx.de (moeller0) Date: Mon, 30 May 2016 11:04:23 +0200 Subject: [OpenWrt-Devel] How to debug/config qos-scripts to work with OpenWRT AA? In-Reply-To: References: Message-ID: <688DFAC9-980D-4666-B478-60511C611046@gmx.de> Hi Danng, I could be out to lunch, but: > - uplink can go up to 104kbps and > I set 128kbit uplink seems like a mismatch too me. Unless that should have been 1024 Kbps? This smells like an ADSL/ATM link, could you report the sync rates as reported by your dsl-modem please? Independent of this at your low uplink bandwidth fq_codel?s default target and interval parameters are not optimal and you should change them (but this is orthogonal to your observed behavior, as thees will result in too little bandwidth used, not too much). And finally, have you thought about moving from AA to something more recent, CC is pretty mature by now, and DD is shaping up nicely (in that its snapshot builts are pretty stable and functional). Best Regards M. > On May 26, 2016, at 05:03 , Danng wrote: > > Hello, > > I am trying to use qos-scripts in OpenWRT AA. I have an issue that the qos-scripts can limit uplink speed but not downlink speed. > > For example: I set 128kbit uplink and 1024kbit downlink, however, the downlink is limitless > > This is the speedtest I captured > > http://speedof.me/show.php?img=160526022701-7038.png > > - uplink can go up to 104kbps > - downlink can go up to 7861kbps (which is higher than the limitation I set) > > --- > > I also tried with wshaper and the got same result. > > Here is my setup: > - eth1 is the WAN port > - eth0 is connect to my PC > - OpenWRT AA > - Linux kernel 3.3.8 > > **************************************************************************** > * cmd: cat /etc/config/qos > **************************************************************************** > > # QoS configuration for OpenWrt > > # INTERFACES: > config interface wan > option classgroup "Default" > option enabled 1 > option upload 128 > option download 1024 > > # RULES: > config classify > option target "Priority" > option ports "22,53" > option comment "ssh, dns" > config classify > option target "Normal" > option proto "tcp" > option ports "20,21,25,80,110,443,993,995" > option comment "ftp, smtp, http(s), imap" > config classify > option target "Express" > option ports "5190" > option comment "AOL, iChat, ICQ" > config default > option target "Express" > option proto "udp" > option pktsize "-500" > config reclassify > option target "Priority" > option proto "icmp" > config default > option target "Bulk" > option portrange "1024-65535" > > > # Don't change the stuff below unless you > # really know what it means :) > > config classgroup "Default" > option classes "Priority Express Normal Bulk" > option default "Normal" > > > config class "Priority" > option packetsize 400 > option avgrate 10 > option priority 20 > config class "Priority_down" > option packetsize 1000 > option avgrate 10 > > > config class "Express" > option packetsize 1000 > option avgrate 50 > option priority 10 > > config class "Normal" > option packetsize 1500 > option packetdelay 100 > option avgrate 10 > option priority 5 > config class "Normal_down" > option avgrate 20 > > config class "Bulk" > option avgrate 1 > option packetdelay 200 > > **************************************************************************** > * cmd: /usr/lib/qos/generate.sh all > **************************************************************************** > | insmod cls_u32 >&- 2>&- > | insmod em_u32 >&- 2>&- > | insmod act_connmark >&- 2>&- > | insmod act_mirred >&- 2>&- > | insmod sch_ingress >&- 2>&- > | insmod cls_fw >&- 2>&- > | insmod sch_hfsc >&- 2>&- > | insmod sch_fq_codel >&- 2>&- > | ifconfig eth1 up txqueuelen 5 >&- 2>&- > | tc qdisc del dev eth1 root >&- 2>&- > | tc qdisc add dev eth1 root handle 1: hfsc default 30 > | tc class add dev eth1 parent 1: classid 1:1 hfsc sc rate 128kbit ul rate 128kbit > | tc class add dev eth1 parent 1:1 classid 1:10 hfsc rt m1 74kbit d 6103us m2 12kbit ls m1 74kbit d 6103us m2 71kbit ul rate 128kbit > | tc class add dev eth1 parent 1:1 classid 1:20 hfsc rt m1 68kbit d 15258us m2 64kbit ls m1 68kbit d 15258us m2 35kbit ul rate 128kbit > | tc class add dev eth1 parent 1:1 classid 1:30 hfsc ls m1 0kbit d 100000us m2 17kbit ul rate 128kbit > | tc class add dev eth1 parent 1:1 classid 1:40 hfsc ls m1 0kbit d 200000us m2 3kbit ul rate 128kbit > | tc qdisc add dev eth1 parent 1:10 handle 100: fq_codel > | tc qdisc add dev eth1 parent 1:20 handle 200: fq_codel > | tc qdisc add dev eth1 parent 1:30 handle 300: fq_codel > | tc qdisc add dev eth1 parent 1:40 handle 400: fq_codel > | tc filter add dev eth1 parent 1: prio 1 protocol ip handle 1/0xff fw flowid 1:10 > | tc filter add dev eth1 parent 1: prio 2 protocol ip handle 2/0xff fw flowid 1:20 > | tc filter add dev eth1 parent 1: prio 3 protocol ip handle 3/0xff fw flowid 1:30 > | tc filter add dev eth1 parent 1: prio 4 protocol ip handle 4/0xff fw flowid 1:40 > | ifconfig ifb0 up txqueuelen 5 >&- 2>&- > | tc qdisc del dev ifb0 root >&- 2>&- > | tc qdisc add dev ifb0 root handle 1: hfsc default 30 > | tc class add dev ifb0 parent 1: classid 1:1 hfsc sc rate 1024kbit ul rate 1024kbit > | tc qdisc del dev eth1 ingress >&- 2>&- > | tc qdisc add dev eth1 ingress > | tc filter add dev eth1 parent ffff: protocol ip prio 1 u32 match u32 0 0 flowid 1:1 action connmark action mirred egress redirect dev ifb0 > | tc class add dev ifb0 parent 1:1 classid 1:10 hfsc rt m1 232kbit d 1907us m2 102kbit ls m1 232kbit d 1907us m2 568kbit ul rate 1024kbit > | tc class add dev ifb0 parent 1:1 classid 1:20 hfsc rt m1 533kbit d 1907us m2 512kbit ls m1 533kbit d 1907us m2 284kbit ul rate 1024kbit > | tc class add dev ifb0 parent 1:1 classid 1:30 hfsc ls m1 0kbit d 100000us m2 142kbit ul rate 1024kbit > | tc class add dev ifb0 parent 1:1 classid 1:40 hfsc ls m1 0kbit d 200000us m2 28kbit ul rate 1024kbit > | tc qdisc add dev ifb0 parent 1:10 handle 100: fq_codel > | tc qdisc add dev ifb0 parent 1:20 handle 200: fq_codel > | tc qdisc add dev ifb0 parent 1:30 handle 300: fq_codel > | tc qdisc add dev ifb0 parent 1:40 handle 400: fq_codel > | tc filter add dev ifb0 parent 1: prio 1 protocol ip handle 1/0xff fw flowid 1:10 > | tc filter add dev ifb0 parent 1: prio 2 protocol ip handle 2/0xff fw flowid 1:20 > | tc filter add dev ifb0 parent 1: prio 3 protocol ip handle 3/0xff fw flowid 1:30 > | tc filter add dev ifb0 parent 1: prio 4 protocol ip handle 4/0xff fw flowid 1:40 > | > | > | > | iptables -t mangle -F qos_Default > | iptables -t mangle -F qos_Default_ct > | iptables -t mangle -D FORWARD -o eth1 -j qos_Default > | iptables -t mangle -D OUTPUT -o eth1 -j qos_Default > | iptables -t mangle -X qos_Default > | iptables -t mangle -X qos_Default_ct > | insmod ipt_multiport >&- 2>&- > | insmod ipt_CONNMARK >&- 2>&- > | insmod ipt_length >&- 2>&- > | iptables -t mangle -N qos_Default >&- 2>&- > | iptables -t mangle -N qos_Default_ct >&- 2>&- > | iptables -t mangle -A qos_Default_ct -m mark --mark 0/0xff -m tcp -p tcp -m multiport --ports 22,53 -j MARK --set-mark 1/0xff > | iptables -t mangle -A qos_Default_ct -m mark --mark 0/0xff -p udp -m udp -m multiport --ports 22,53 -j MARK --set-mark 1/0xff > | iptables -t mangle -A qos_Default_ct -m mark --mark 0/0xff -p tcp -m tcp -m multiport --ports 20,21,25,80,110,443,993,995 -j MARK --set-mark 3/0xff > | iptables -t mangle -A qos_Default_ct -m mark --mark 0/0xff -m tcp -p tcp -m multiport --ports 5190 -j MARK --set-mark 2/0xff > | iptables -t mangle -A qos_Default_ct -m mark --mark 0/0xff -p udp -m udp -m multiport --ports 5190 -j MARK --set-mark 2/0xff > | iptables -t mangle -A qos_Default_ct -j CONNMARK --save-mark --mask 0xff > | iptables -t mangle -A qos_Default -j CONNMARK --restore-mark --mask 0xff > | iptables -t mangle -A qos_Default -m mark --mark 0/0xff -j qos_Default_ct > | iptables -t mangle -A qos_Default -m mark --mark 0/0xff -p udp -m length --length :500 -j MARK --set-mark 2/0xff > | iptables -t mangle -A qos_Default -p icmp -j MARK --set-mark 1/0xff > | iptables -t mangle -A qos_Default -m mark --mark 0/0xff -m tcp -p tcp --sport 1024:65535 --dport 1024:65535 -j MARK --set-mark 4/0xff > | iptables -t mangle -A qos_Default -m mark --mark 0/0xff -p udp -m udp --sport 1024:65535 --dport 1024:65535 -j MARK --set-mark 4/0xff > | iptables -t mangle -A OUTPUT -o eth1 -j qos_Default > | iptables -t mangle -A FORWARD -o eth1 -j qos_Default > \--------------------------------------------------------------------------- > > **************************************************************************** > * cmd: iptables -L > **************************************************************************** > | Chain INPUT (policy ACCEPT) > | target prot opt source destination > | ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED > | ACCEPT all -- anywhere anywhere > | syn_flood tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN > | input_rule all -- anywhere anywhere > | input all -- anywhere anywhere > | > | Chain FORWARD (policy DROP) > | target prot opt source destination > | ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED > | forwarding_rule all -- anywhere anywhere > | forward all -- anywhere anywhere > | reject all -- anywhere anywhere > | > | Chain OUTPUT (policy ACCEPT) > | target prot opt source destination > | ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED > | ACCEPT all -- anywhere anywhere > | output_rule all -- anywhere anywhere > | output all -- anywhere anywhere > | > | Chain MINIUPNPD (1 references) > | target prot opt source destination > | > | Chain forward (1 references) > | target prot opt source destination > | zone_lan_forward all -- anywhere anywhere > | zone_wan_forward all -- anywhere anywhere > | > | Chain forwarding_lan (1 references) > | target prot opt source destination > | > | Chain forwarding_rule (1 references) > | target prot opt source destination > | > | Chain forwarding_wan (1 references) > | target prot opt source destination > | > | Chain input (1 references) > | target prot opt source destination > | zone_lan all -- anywhere anywhere > | zone_wan all -- anywhere anywhere > | > | Chain input_lan (1 references) > | target prot opt source destination > | > | Chain input_rule (1 references) > | target prot opt source destination > | > | Chain input_wan (1 references) > | target prot opt source destination > | > | Chain output (1 references) > | target prot opt source destination > | zone_lan_ACCEPT all -- anywhere anywhere > | zone_wan_ACCEPT all -- anywhere anywhere > | > | Chain output_rule (1 references) > | target prot opt source destination > | > | Chain reject (5 references) > | target prot opt source destination > | REJECT tcp -- anywhere anywhere reject-with tcp-reset > | REJECT all -- anywhere anywhere reject-with icmp-port-unreachable > | > | Chain syn_flood (1 references) > | target prot opt source destination > | RETURN tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN limit: avg 25/sec burst 50 > | DROP all -- anywhere anywhere > | > | Chain zone_lan (1 references) > | target prot opt source destination > | input_lan all -- anywhere anywhere > | zone_lan_ACCEPT all -- anywhere anywhere > | > | Chain zone_lan_ACCEPT (2 references) > | target prot opt source destination > | ACCEPT all -- anywhere anywhere > | ACCEPT all -- anywhere anywhere > | > | Chain zone_lan_DROP (0 references) > | target prot opt source destination > | DROP all -- anywhere anywhere > | DROP all -- anywhere anywhere > | > | Chain zone_lan_REJECT (1 references) > | target prot opt source destination > | reject all -- anywhere anywhere > | reject all -- anywhere anywhere > | > | Chain zone_lan_forward (1 references) > | target prot opt source destination > | zone_wan_ACCEPT all -- anywhere anywhere > | forwarding_lan all -- anywhere anywhere > | zone_lan_REJECT all -- anywhere anywhere > | > | Chain zone_wan (1 references) > | target prot opt source destination > | ACCEPT udp -- anywhere anywhere udp dpt:bootpc > | ACCEPT icmp -- anywhere anywhere icmp echo-request > | input_wan all -- anywhere anywhere > | zone_wan_REJECT all -- anywhere anywhere > | > | Chain zone_wan_ACCEPT (2 references) > | target prot opt source destination > | ACCEPT all -- anywhere anywhere > | ACCEPT all -- anywhere anywhere > | > | Chain zone_wan_DROP (0 references) > | target prot opt source destination > | DROP all -- anywhere anywhere > | DROP all -- anywhere anywhere > | > | Chain zone_wan_REJECT (2 references) > | target prot opt source destination > | reject all -- anywhere anywhere > | reject all -- anywhere anywhere > | > | Chain zone_wan_forward (1 references) > | target prot opt source destination > | MINIUPNPD all -- anywhere anywhere > | forwarding_wan all -- anywhere anywhere > | zone_wan_REJECT all -- anywhere anywhere > \--------------------------------------------------------------------------- > > **************************************************************************** > * cmd: iptables -t nat -L > **************************************************************************** > | Chain PREROUTING (policy ACCEPT) > | target prot opt source destination > | prerouting_rule all -- anywhere anywhere > | zone_lan_prerouting all -- anywhere anywhere > | zone_wan_prerouting all -- anywhere anywhere > | > | Chain INPUT (policy ACCEPT) > | target prot opt source destination > | > | Chain OUTPUT (policy ACCEPT) > | target prot opt source destination > | > | Chain POSTROUTING (policy ACCEPT) > | target prot opt source destination > | postrouting_rule all -- anywhere anywhere > | zone_lan_nat all -- anywhere anywhere > | zone_wan_nat all -- anywhere anywhere > | > | Chain MINIUPNPD (1 references) > | target prot opt source destination > | > | Chain postrouting_rule (1 references) > | target prot opt source destination > | > | Chain prerouting_lan (1 references) > | target prot opt source destination > | > | Chain prerouting_rule (1 references) > | target prot opt source destination > | > | Chain prerouting_wan (1 references) > | target prot opt source destination > | > | Chain zone_lan_nat (1 references) > | target prot opt source destination > | > | Chain zone_lan_prerouting (1 references) > | target prot opt source destination > | prerouting_lan all -- anywhere anywhere > | > | Chain zone_wan_nat (1 references) > | target prot opt source destination > | MASQUERADE all -- anywhere anywhere > | > | Chain zone_wan_prerouting (1 references) > | target prot opt source destination > | MINIUPNPD all -- anywhere anywhere > | prerouting_wan all -- anywhere anywhere > \--------------------------------------------------------------------------- > > **************************************************************************** > * cmd: iptables -t mangle -L > **************************************************************************** > | Chain PREROUTING (policy ACCEPT) > | target prot opt source destination > | > | Chain INPUT (policy ACCEPT) > | target prot opt source destination > | > | Chain FORWARD (policy ACCEPT) > | target prot opt source destination > | zone_wan_MSSFIX all -- anywhere anywhere > | qos_Default all -- anywhere anywhere > | > | Chain OUTPUT (policy ACCEPT) > | target prot opt source destination > | qos_Default all -- anywhere anywhere > | > | Chain POSTROUTING (policy ACCEPT) > | target prot opt source destination > | > | Chain qos_Default (2 references) > | target prot opt source destination > | CONNMARK all -- anywhere anywhere CONNMARK restore mask 0xff > | qos_Default_ct all -- anywhere anywhere mark match 0x0/0xff > | MARK udp -- anywhere anywhere mark match 0x0/0xff length 0:500 MARK xset 0x2/0xff > | MARK icmp -- anywhere anywhere MARK xset 0x1/0xff > | MARK tcp -- anywhere anywhere mark match 0x0/0xff tcp spts:1024:65535 dpts:1024:65535 MARK xset 0x4/0xff > | MARK udp -- anywhere anywhere mark match 0x0/0xff udp spts:1024:65535 dpts:1024:65535 MARK xset 0x4/0xff > | > | Chain qos_Default_ct (1 references) > | target prot opt source destination > | MARK tcp -- anywhere anywhere mark match 0x0/0xff tcp multiport ports ssh,domain MARK xset 0x1/0xff > | MARK udp -- anywhere anywhere mark match 0x0/0xff udp multiport ports ssh,domain MARK xset 0x1/0xff > | MARK tcp -- anywhere anywhere mark match 0x0/0xff tcp multiport ports ftp-data,ftp,smtp,www,pop3,https,imaps,pop3s MARK xset 0x3/0xff > | MARK tcp -- anywhere anywhere mark match 0x0/0xff tcp multiport ports 5190 MARK xset 0x2/0xff > | MARK udp -- anywhere anywhere mark match 0x0/0xff udp multiport ports 5190 MARK xset 0x2/0xff > | CONNMARK all -- anywhere anywhere CONNMARK save mask 0xff > | > | Chain zone_wan_MSSFIX (1 references) > | target prot opt source destination > | TCPMSS tcp -- anywhere anywhere tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU > \--------------------------------------------------------------------------- > > **************************************************************************** > * cmd: tc -s qdisc show dev eth0 > **************************************************************************** > | qdisc pfifo_fast 0: root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 > | Sent 278256856 bytes 260097 pkt (dropped 0, overlimits 0 requeues 0) > | backlog 0b 0p requeues 0 > \--------------------------------------------------------------------------- > > **************************************************************************** > * cmd: tc -s qdisc show dev eth1 > **************************************************************************** > | qdisc hfsc 1: root refcnt 2 default 30 > | Sent 1447188 bytes 7376 pkt (dropped 0, overlimits 12468 requeues 0) > | backlog 0b 0p requeues 0 > | qdisc fq_codel 100: parent 1:10 limit 10240p flows 1024 quantum 1518 target 5.0ms interval 100.0ms ecn > | Sent 5000 bytes 55 pkt (dropped 0, overlimits 0 requeues 0) > | backlog 0b 0p requeues 0 > | maxpacket 256 drop_overlimit 0 new_flow_count 27 ecn_mark 0 > | new_flows_len 1 old_flows_len 0 > | qdisc fq_codel 200: parent 1:20 limit 10240p flows 1024 quantum 1518 target 5.0ms interval 100.0ms ecn > | Sent 19246 bytes 145 pkt (dropped 0, overlimits 0 requeues 0) > | backlog 0b 0p requeues 0 > | maxpacket 350 drop_overlimit 0 new_flow_count 80 ecn_mark 0 > | new_flows_len 0 old_flows_len 2 > | qdisc fq_codel 300: parent 1:30 limit 10240p flows 1024 quantum 1518 target 5.0ms interval 100.0ms ecn > | Sent 720529 bytes 2687 pkt (dropped 223, overlimits 0 requeues 0) > | backlog 0b 0p requeues 0 > | maxpacket 1514 drop_overlimit 0 new_flow_count 750 ecn_mark 0 > | new_flows_len 1 old_flows_len 5 > | qdisc fq_codel 400: parent 1:40 limit 10240p flows 1024 quantum 1518 target 5.0ms interval 100.0ms ecn > | Sent 702413 bytes 4489 pkt (dropped 1461, overlimits 0 requeues 0) > | backlog 0b 0p requeues 0 > | maxpacket 1514 drop_overlimit 0 new_flow_count 271 ecn_mark 0 > | new_flows_len 0 old_flows_len 1 > | qdisc ingress ffff: parent ffff:fff1 ---------------- > | Sent 1639987 bytes 3843 pkt (dropped 0, overlimits 0 requeues 0) > | backlog 0b 0p requeues 0 > \--------------------------------------------------------------------------- > > **************************************************************************** > * cmd: tc -s qdisc show dev ifb0 > **************************************************************************** > | qdisc hfsc 1: root refcnt 2 default 30 > | Sent 1391951 bytes 2762 pkt (dropped 0, overlimits 2001 requeues 0) > | backlog 0b 0p requeues 0 > | qdisc fq_codel 100: parent 1:10 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn > | Sent 4723 bytes 23 pkt (dropped 0, overlimits 0 requeues 0) > | backlog 0b 0p requeues 0 > | maxpacket 299 drop_overlimit 0 new_flow_count 21 ecn_mark 0 > | new_flows_len 1 old_flows_len 0 > | qdisc fq_codel 200: parent 1:20 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn > | Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > | backlog 0b 0p requeues 0 > | maxpacket 256 drop_overlimit 0 new_flow_count 0 ecn_mark 0 > | new_flows_len 0 old_flows_len 0 > | qdisc fq_codel 300: parent 1:30 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn > | Sent 1387228 bytes 2739 pkt (dropped 127, overlimits 0 requeues 0) > | backlog 0b 0p requeues 0 > | maxpacket 1518 drop_overlimit 0 new_flow_count 1052 ecn_mark 0 > | new_flows_len 1 old_flows_len 1 > | qdisc fq_codel 400: parent 1:40 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn > | Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > | backlog 0b 0p requeues 0 > | maxpacket 256 drop_overlimit 0 new_flow_count 0 ecn_mark 0 > | new_flows_len 0 old_flows_len 0 > \--------------------------------------------------------------------------- > > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From Jos.Delbar at technicolor.com Mon May 30 05:58:38 2016 From: Jos.Delbar at technicolor.com (Delbar Jos) Date: Mon, 30 May 2016 09:58:38 +0000 Subject: [OpenWrt-Devel] [LEDE-DEV] TR-069 for OpenWrt In-Reply-To: <264724c0-8778-1f31-f054-3a0375103ba2@nbd.name> References: <264724c0-8778-1f31-f054-3a0375103ba2@nbd.name> Message-ID: Felix Fietkau wrote: > > We are conscious of the fact that together with the proposals made by > > Felix, Luka and Wojtek we are now looking at many "competing" proposals. > > As a next step, we recommend to organize a workshop, at a practical > > location and time, where we put everything on the table and define the > > most appropriate path forward to the benefit of OpenWrt as a whole. > I think such a workshop would be a great idea. It would be nice to have the > code available for review some time before that workshop, so we can all take > a detailed look at the various proposals before we sit down and decide how > to move forward with this. I agree that would be helpful. In our case it will take us some weeks before we can formally release sources. We will be able to share documentation on architecture, API, features, etc. up front to get the discussions going. Jos _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From Jos.Delbar at technicolor.com Mon May 30 06:21:33 2016 From: Jos.Delbar at technicolor.com (Delbar Jos) Date: Mon, 30 May 2016 10:21:33 +0000 Subject: [OpenWrt-Devel] [LEDE-DEV] TR-069 for OpenWrt In-Reply-To: <57497EE6.4000401@hauke-m.de> References: <57497EE6.4000401@hauke-m.de> Message-ID: Hauke Mehrtens wrote: > On 05/27/2016 01:43 AM, Delbar Jos wrote: > > At Technicolor we have followed with great interest the recent proposals > to enhance OpenWrt with an open source solution for TR-069 remote > management. As one of the world's largest vendors of modems and routers > for carrier applications, making use of OpenWrt in a significant share of our > install base, we want to support this initiative in a meaningful way. > Concretely, we are willing to open source Technicolor's in-house TR-069 > solution and thereby contribute to OpenWrt: > > * a TR-069 protocol agent, > > * a data model mapping framework that we use to bridge the world of > > OpenWrt, UCI, UBUS ... with the world of TR-069, TR-098, TR-181 ... > > (and by extension with the world of SNMP, MIB, NETCONF, YANG ...), > > * a set of mappings. > > That is really nice to hear. For me personally it looks like the remote > management with TR-069 and similar protocols is one of the biggest > extensions commercial vendors add to the user space of OpenWrt to make it > fit their needs. > > In addition to the TR-* family does this also include support for SNMP, MIB, > NETCONF, YANG ? Our proposal does not include protocol agents for SNMP or NETCONF but it does include a data model mapping framework that can be used to bridge between these protocols' data models MIB and YANG and an OpenWrt environment. If you compare this framework with the slides shown by Felix at the prpl weekly then it's an implementation of the "configuration backend", or if you compare it with the architecture of a NETCONF project like https://wiki.openwrt.org/inbox/howto/opencpe then it's an implementation of "mand". (We aren't using mand.) > That's good to hear, would it also be possible that other interested people > can join such a workshop? The answer is yes as far as I'm concerned. Jos _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From naresh at codeaurora.org Tue May 31 04:33:19 2016 From: naresh at codeaurora.org (Naresh Kumar Mehta) Date: Tue, 31 May 2016 14:03:19 +0530 Subject: [OpenWrt-Devel] Netifd patch 8cb06c3efe734a521507cba7b5f0ba206e2476e0 Message-ID: <007001d1bb17$186f6310$494e2930$@codeaurora.org> Felix, I am trying to add wlan0 interface to bond interface but unable to add. While digging further, I realized that below commit is not allowing me to add. http://git.openwrt.org/?p=project/netifd.git;a=commitdiff;h=8cb06c3efe734a52 1507cba7b5f0ba206e2476e0 I also noticed initial code was added by below commit http://git.openwrt.org/?p=project/netifd.git;a=commitdiff;h=fe8a6dd2991d54c3 eb84cb12764c1316d19bac4e Can you please help me understand why 8cb06c3efe734a521507cba7b5f0ba206e2476e0 was added & what issues I could face, If remove 8cb06c3efe734a521507cba7b5f0ba206e2476e0? Thanks, Naresh -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From naresh at codeaurora.org Tue May 31 04:36:32 2016 From: naresh at codeaurora.org (Naresh Kumar Mehta) Date: Tue, 31 May 2016 14:06:32 +0530 Subject: [OpenWrt-Devel] Netifd patch 8cb06c3efe734a521507cba7b5f0ba206e2476e0 Message-ID: <008c01d1bb17$8b8f47c0$a2add740$@codeaurora.org> Felix, I am trying to add wlan0 interface to bond interface but unable to add. While digging further, I realized that below commit is not allowing me to add. http://git.openwrt.org/?p=project/netifd.git;a=commitdiff;h=8cb06c3efe734a52 1507cba7b5f0ba206e2476e0 I also noticed initial code was added by below commit http://git.openwrt.org/?p=project/netifd.git;a=commitdiff;h=fe8a6dd2991d54c3 eb84cb12764c1316d19bac4e Can you please help me understand why 8cb06c3efe734a521507cba7b5f0ba206e2476e0 was added &? what issues I could face, If remove 8cb06c3efe734a521507cba7b5f0ba206e2476e0? Thanks, Naresh _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From eckert.florian at googlemail.com Tue May 31 06:06:45 2016 From: eckert.florian at googlemail.com (Florian Eckert) Date: Tue, 31 May 2016 12:06:45 +0200 Subject: [OpenWrt-Devel] [PATCH CC 1/4] usbutils: add license tag Message-ID: <1464689208-12657-1-git-send-email-Eckert.Florian@googlemail.com> show the license for this package in opkg Signed-off-by: Florian Eckert --- package/utils/usbutils/Makefile | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/package/utils/usbutils/Makefile b/package/utils/usbutils/Makefile index b1c058b..84359a3 100644 --- a/package/utils/usbutils/Makefile +++ b/package/utils/usbutils/Makefile @@ -9,11 +9,13 @@ include $(TOPDIR)/rules.mk PKG_NAME:=usbutils PKG_VERSION:=007 -PKG_RELEASE:=1 +PKG_RELEASE:=2 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2 PKG_SOURCE_URL:=@KERNEL/linux/utils/usb/usbutils PKG_MD5SUM:=a6bd63d5c44cebb717a960eae22a3ca9 +PKG_LICENSE:=GPL-2.0 +PKG_LICENSE_FILES:=COPYING USB_IDS_VERSION:=2013-01-16 USB_IDS_MD5SUM:=2a2344907b6344f0935c86efaf9de620 -- 2.1.4 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From eckert.florian at googlemail.com Tue May 31 06:06:46 2016 From: eckert.florian at googlemail.com (Florian Eckert) Date: Tue, 31 May 2016 12:06:46 +0200 Subject: [OpenWrt-Devel] [PATCH CC 2/4] qos-scripts: add license tag In-Reply-To: <1464689208-12657-1-git-send-email-Eckert.Florian@googlemail.com> References: <1464689208-12657-1-git-send-email-Eckert.Florian@googlemail.com> Message-ID: <1464689208-12657-2-git-send-email-Eckert.Florian@googlemail.com> show the license for this package in opkg Signed-off-by: Florian Eckert --- package/network/config/qos-scripts/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/package/network/config/qos-scripts/Makefile b/package/network/config/qos-scripts/Makefile index a098598..bf5be62 100644 --- a/package/network/config/qos-scripts/Makefile +++ b/package/network/config/qos-scripts/Makefile @@ -9,9 +9,10 @@ include $(TOPDIR)/rules.mk PKG_NAME:=qos-scripts PKG_VERSION:=1.2.1 -PKG_RELEASE:=7 +PKG_RELEASE:=8 PKG_MAINTAINER:=Felix Fietkau +PKG_LICENSE:=GPL-2.0 PKG_BUILD_DIR := $(BUILD_DIR)/$(PKG_NAME) -- 2.1.4 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From eckert.florian at googlemail.com Tue May 31 06:06:47 2016 From: eckert.florian at googlemail.com (Florian Eckert) Date: Tue, 31 May 2016 12:06:47 +0200 Subject: [OpenWrt-Devel] [PATCH CC 3/4] px5g: add license tag In-Reply-To: <1464689208-12657-1-git-send-email-Eckert.Florian@googlemail.com> References: <1464689208-12657-1-git-send-email-Eckert.Florian@googlemail.com> Message-ID: <1464689208-12657-3-git-send-email-Eckert.Florian@googlemail.com> show the license for this package in opkg Signed-off-by: Florian Eckert --- package/utils/px5g/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/package/utils/px5g/Makefile b/package/utils/px5g/Makefile index 8677a8b..071f479 100644 --- a/package/utils/px5g/Makefile +++ b/package/utils/px5g/Makefile @@ -8,9 +8,10 @@ include $(TOPDIR)/rules.mk PKG_NAME:=px5g -PKG_RELEASE:=3 +PKG_RELEASE:=4 PKG_USE_MIPS16:=0 +PKG_LICENSE:=LGPL-2.1 include $(INCLUDE_DIR)/package.mk -- 2.1.4 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From eckert.florian at googlemail.com Tue May 31 06:06:48 2016 From: eckert.florian at googlemail.com (Florian Eckert) Date: Tue, 31 May 2016 12:06:48 +0200 Subject: [OpenWrt-Devel] [PATCH CC 4/4] libiconv-full: add license tag In-Reply-To: <1464689208-12657-1-git-send-email-Eckert.Florian@googlemail.com> References: <1464689208-12657-1-git-send-email-Eckert.Florian@googlemail.com> Message-ID: <1464689208-12657-4-git-send-email-Eckert.Florian@googlemail.com> show the license for this package in opkg Signed-off-by: Florian Eckert --- package/libs/libiconv-full/Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/package/libs/libiconv-full/Makefile b/package/libs/libiconv-full/Makefile index 75bca83..9be0c78 100644 --- a/package/libs/libiconv-full/Makefile +++ b/package/libs/libiconv-full/Makefile @@ -17,6 +17,8 @@ PKG_SOURCE:=libiconv-$(PKG_VERSION).tar.gz PKG_SOURCE_URL:=@GNU/libiconv PKG_MD5SUM:=d42b97f6ef5dd0ba4469d520ed732fed PKG_BUILD_DIR:=$(BUILD_DIR)/libiconv-$(PKG_VERSION) +PKG_LICENSE:=LGPL-2.0 +PKG_LICENSE_FILES:=COPYING.LIB PKG_FIXUP:=patch-libtool -- 2.1.4 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From Abhijit.Mahajani at imgtec.com Tue May 31 09:44:56 2016 From: Abhijit.Mahajani at imgtec.com (Abhijit Mahajani) Date: Tue, 31 May 2016 13:44:56 +0000 Subject: [OpenWrt-Devel] move OpenWrt codebase to Git and GitHub Message-ID: <6BC723210F14BB4A9FB9F9DC72D01598AA3C148E@PUMAIL01.pu.imgtec.org> Hello Luka, First of all, we would welcome the move of openwrt into GitHub. We have been using openwrt for one of the project and we have already opensourced our port on GitHub (https://github.com/IMGCreator/openwrt) . And willing to upstream this to the openwrt community. So having openwrt codebase in the GitHub will certainly help in the upstreaming. Any guidance is highly appreciated. Thanks and Regards, Abhijit A. Mahajani -----Original Message----- From: openwrt-devel [mailto:openwrt-devel-bounces at lists.openwrt.org] On Behalf Of openwrt-devel-request at lists.openwrt.org Sent: Thursday, May 26, 2016 8:34 AM To: openwrt-devel at lists.openwrt.org Subject: openwrt-devel Digest, Vol 125, Issue 104 Send openwrt-devel mailing list submissions to openwrt-devel at lists.openwrt.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel or, via email, send a message with subject or body 'help' to openwrt-devel-request at lists.openwrt.org You can reach the person managing the list at openwrt-devel-owner at lists.openwrt.org When replying, please edit your Subject line so it is more specific than "Re: Contents of openwrt-devel digest..." Today's Topics: 1. Re: OpenWrt / LEDE (Bj?rn Mork) 2. Re: OpenWrt / LEDE (Rafa? Mi?ecki) 3. Re: [PROPOSAL] move OpenWrt codebase to Git and GitHub (Luka Perkov) 4. Re: [PROPOSAL] move OpenWrt codebase to Git and GitHub (Luka Perkov) 5. Re: [OpenWrt-Users] [PROPOSAL] move OpenWrt codebase to Git and GitHub (Luka Perkov) 6. Re: [OpenWrt-Users] [PROPOSAL] move OpenWrt codebase to Git and GitHub (Valent Turkovic) 7. How to debug/config qos-scripts to work with OpenWRT AA? (Danng) ---------------------------------------------------------------------- Message: 1 Date: Wed, 25 May 2016 12:55:43 +0200 From: Bj?rn Mork To: mbm Cc: Rafa? Mi?ecki , openwrt-devel at lists.openwrt.org, LEDE Development List Subject: Re: [OpenWrt-Devel] OpenWrt / LEDE Message-ID: <8760u2pftc.fsf at nemi.mork.no> Content-Type: text/plain; charset=utf-8 mbm writes: > The hackers email address represents the primary point of contact for > OpenWrt, particularly in regards to donations. Following the surprise > LEDE announcement, forwarding rules for @openwrt.org email addresses > were disabled. This was done to mitigate further damage to OpenWrt due > to misrepresentation, intentional or otherwise. Failing to see the damage your action has caused is your biggest problem right now. Even if we accept the rather far fetched possibilty of misrepresentation, there is no way that can outweight the effect on the maintainership status OpenWrt. Right now, 95 of the 145 (PKG_)MAINTAINER entries for OpenWrt packages points to an openwrt.org email address belonging to a LEDE committer: bjorn at canardo:/usr/local/src/openwrt$ git grep 'MAINTAINER:=.*<\(lynxis\|noltari\|dangole\|nbd\|hauke\|jow\|blogic\|neoraider\|rmilecki\|cyrus\|stintel\|thess\)@openwrt.org>' origin/master -- package/|wc -l 95 bjorn at canardo:/usr/local/src/openwrt$ git grep 'MAINTAINER' origin/master -- package/|wc -l 145 I don't know if all these were disabled, but the package I tried to submit to after the split was one of these. You don't seem to understand the devastating effect it has on OpenWrt if occasional contributors gets an email bounce from the published maintainer address. There is no way you can blame those maintainers for this situation. The problem is solely the responsibility of whoever decided to disable those addresses. Bj?rn ------------------------------ Message: 2 Date: Wed, 25 May 2016 13:52:54 +0200 From: Rafa? Mi?ecki To: mbm Cc: OpenWrt Development List , LEDE Development List Subject: Re: [OpenWrt-Devel] OpenWrt / LEDE Message-ID: Content-Type: text/plain; charset=UTF-8 On 25 May 2016 at 10:09, mbm wrote: > The hackers email address represents the primary point of contact for > OpenWrt, particularly in regards to donations. Following the surprise > LEDE announcement, forwarding rules for @openwrt.org email addresses > were disabled. This was done to mitigate further damage to OpenWrt due > to misrepresentation, intentional or otherwise. Hackers e-mail address (mailing list) was also used for internal discussions. You not only disabled forwarding rules for @openwrt.org personal e-mails but also kicked out private e-mails from the hackers mailing list. I never really cared about hardware donations offered to hackers, but knowing what's going on (like release plans) is important for contributing. -- Rafa? ------------------------------ Message: 3 Date: Wed, 25 May 2016 18:25:54 +0200 From: Luka Perkov To: Eric Schultz Cc: openwrt-users at lists.openwrt.org, openwrt-devel Subject: Re: [OpenWrt-Devel] [PROPOSAL] move OpenWrt codebase to Git and GitHub Message-ID: <20160525162554.GA11029 at localhost.localdomain> Content-Type: text/plain; charset=us-ascii On Tue, May 24, 2016 at 10:51:46AM -0500, Eric Schultz wrote: > My free-software side worries about using something non-free like drone.io > for CI but this is a huge task certainly and I'm not sure a free tool would > meet everyone's needs (plus there's the huge added burden of maintenance). The drone.io is actually Apache 2.0 [1] and the example build was configured on a private machine. Luka [1] https://github.com/drone/drone ------------------------------ Message: 4 Date: Wed, 25 May 2016 18:46:27 +0200 From: Luka Perkov To: David Lang Cc: openwrt-users at lists.openwrt.org, openwrt-devel at lists.openwrt.org Subject: Re: [OpenWrt-Devel] [PROPOSAL] move OpenWrt codebase to Git and GitHub Message-ID: <20160525164627.GB11029 at localhost.localdomain> Content-Type: text/plain; charset=us-ascii On Tue, May 24, 2016 at 10:29:30AM -0700, David Lang wrote: > OpenWRT has already moved to using Git instead of SVN, No, it has not. To users is exposed the Git frontend while the commits are made to the SVN repo. > so why do they need to move from hosting the git repository themselves to > having it hosted on github? See the reasons below. > There can be a mirror of the repo on github (remember that git is a > Decentralized VCS) Also, we have discussed of having a mirror on our server and this is something that we can do. If everything happens on GitHub then I don't see a point in having clone on GitHub instead of a having the main repo on GitHub and having clone elsewhere. > > * GitHub and similar services will allow us to integrate more easily > > with other projects > > > > Here specifically I mean integration with modern CI. Here is an example > > of integration with drone.io [3][4]. At the moment this is only in the > > POC stage but what I'd like to do down the line is to: > > > > - build OpenWrt images for all architectures for every pull request > > - build OpenWrt package binary for every package pull request for all > > architectures and make it available for download > > > > - build and host OpenWrt qemu and/or Docker image for every pull request > > the build farm isn't large enough to do this Current one is not. > It's also not neccessary to move to github to be able to do this, it just > needs more systems in the build farm to be able to build things fast enough. With GitHub it will be able to see compile status of each pull request. If it is not GitHub or simmilar service then this would need to be developed and I think we have better things to do then that :) > > This will allow easy review of the work since flags will be shown in the > > pull request if the build was sucessful or not. Also, this will allow > > people to test changes without building the image and thus lowering the > > time that needs to be spent on maintenance work. > > > > If this proposal gets accepted I'll be sending out an email to get > > access to more build servers so this new build infrastructure can > > properly support the project in a timely fashion. > > why should providing more build servers be contingent on moving to a > commercial hosting provider vs running things themselves? IMO move to GitHub will allow us to manage contributions more easily and handle them in timely fashion. This, combined with other perks explained in my previous email is possible today without need to develop the features that others provide today. Luka ------------------------------ Message: 5 Date: Wed, 25 May 2016 18:55:38 +0200 From: Luka Perkov To: Jo-Philipp Wich Cc: OpenWrt User List , OpenWrt Development List Subject: Re: [OpenWrt-Devel] [OpenWrt-Users] [PROPOSAL] move OpenWrt codebase to Git and GitHub Message-ID: <20160525165538.GA11417 at localhost.localdomain> Content-Type: text/plain; charset=us-ascii Thanks for the numbers Jo. The current hello-world setup with drone.io was done on cheap SSD based VPS. That said, with some "optimizations" (or hacks if you want) I think it should be possible to have less powerful servers but more of them to do what is needed. For example, if one makes pull request for package A. Then for every target only the core system with package A and it's dependencies should be built. That said, if pull request is valid it will result with a successful build. We should avoid situations where somebody makes a patch for package A and if fails to build because package Z unrelated to package A is broken. Luka On Tue, May 24, 2016 at 10:35:42PM +0200, Jo-Philipp Wich wrote: > Hi, > > here's a few numbers we gathered with our buildbot setup: > > We currently need roughly 35GB per target when building OpenWrt plus the > entire package world and currently there are roughly ~70 > target/subtarget combinations in the OpenWrt tree. > > If fast build tests are desired then the only way to do so is by > implementing incremental building which only works if there's enough > space to retain all build trees at once which means there need to be > about 2.5TB of storage available. > > For only building all base systems without package feeds the entire > required space is around 800GB. > > A base system build currently requires 1 hour and 15 minutes on a > machine having a Xeon E3-1246 v3 4 core / 8 thread CPU with prepopulated > dl/, ccache and make -j8. > > A build of all packages from all feeds takes around 70 minutes on a Xeon > E5-2630 v3 8 core / 16 thread machine with 12GB ram and make -j16. > > HTH, > Jo > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ------------------------------ Message: 6 Date: Wed, 25 May 2016 22:49:49 +0200 From: Valent Turkovic To: Benjamin Henrion , OpenWrt User List Cc: Jo-Philipp Wich , Luka Perkov , OpenWrt Development List Subject: Re: [OpenWrt-Devel] [OpenWrt-Users] [PROPOSAL] move OpenWrt codebase to Git and GitHub Message-ID: Content-Type: text/plain; charset=UTF-8 On Wed, May 25, 2016 at 7:06 PM, Benjamin Henrion wrote: > On Tue, May 24, 2016 at 10:35 PM, Jo-Philipp Wich wrote: >> Hi, >> >> here's a few numbers we gathered with our buildbot setup: >> >> We currently need roughly 35GB per target when building OpenWrt plus the >> entire package world and currently there are roughly ~70 >> target/subtarget combinations in the OpenWrt tree. >> >> If fast build tests are desired then the only way to do so is by >> implementing incremental building which only works if there's enough >> space to retain all build trees at once which means there need to be >> about 2.5TB of storage available. > > A BTRFS volume with deduplication would help here? I wouldn't trust BTRFS with photo album of my cats... I had it running and couldn't compile OpenWrt on BTRFS volume because it ran out of space, it was a knows bug that small files used up more space than df and other tools saw... But I as an advanced OpenWrt user and beginner openwrt developer would love to see move to github, it would make things much, much easier, please go for it. ------------------------------ Message: 7 Date: Thu, 26 May 2016 03:03:39 +0000 From: Danng To: "openwrt-devel at lists.openwrt.org" Subject: [OpenWrt-Devel] How to debug/config qos-scripts to work with OpenWRT AA? Message-ID: Content-Type: text/plain; charset="utf-8" Hello, I am trying to use qos-scripts in OpenWRT AA. I have an issue that the qos-scripts can limit uplink speed but not downlink speed. For example: I set 128kbit uplink and 1024kbit downlink, however, the downlink is limitless This is the speedtest I captured http://speedof.me/show.php?img=160526022701-7038.png - uplink can go up to 104kbps - downlink can go up to 7861kbps (which is higher than the limitation I set) --- I also tried with wshaper and the got same result. Here is my setup: - eth1 is the WAN port - eth0 is connect to my PC - OpenWRT AA - Linux kernel 3.3.8 **************************************************************************** * cmd: cat /etc/config/qos **************************************************************************** # QoS configuration for OpenWrt # INTERFACES: config interface wan option classgroup "Default" option enabled 1 option upload 128 option download 1024 # RULES: config classify option target "Priority" option ports "22,53" option comment "ssh, dns" config classify option target "Normal" option proto "tcp" option ports "20,21,25,80,110,443,993,995" option comment "ftp, smtp, http(s), imap" config classify option target "Express" option ports "5190" option comment "AOL, iChat, ICQ" config default option target "Express" option proto "udp" option pktsize "-500" config reclassify option target "Priority" option proto "icmp" config default option target "Bulk" option portrange "1024-65535" # Don't change the stuff below unless you # really know what it means :) config classgroup "Default" option classes "Priority Express Normal Bulk" option default "Normal" config class "Priority" option packetsize 400 option avgrate 10 option priority 20 config class "Priority_down" option packetsize 1000 option avgrate 10 config class "Express" option packetsize 1000 option avgrate 50 option priority 10 config class "Normal" option packetsize 1500 option packetdelay 100 option avgrate 10 option priority 5 config class "Normal_down" option avgrate 20 config class "Bulk" option avgrate 1 option packetdelay 200 **************************************************************************** * cmd: /usr/lib/qos/generate.sh all **************************************************************************** | insmod cls_u32 >&- 2>&- | insmod em_u32 >&- 2>&- | insmod act_connmark >&- 2>&- | insmod act_mirred >&- 2>&- | insmod sch_ingress >&- 2>&- | insmod cls_fw >&- 2>&- | insmod sch_hfsc >&- 2>&- | insmod sch_fq_codel >&- 2>&- | ifconfig eth1 up txqueuelen 5 >&- 2>&- | tc qdisc del dev eth1 root >&- 2>&- | tc qdisc add dev eth1 root handle 1: hfsc default 30 | tc class add dev eth1 parent 1: classid 1:1 hfsc sc rate 128kbit ul rate 128kbit | tc class add dev eth1 parent 1:1 classid 1:10 hfsc rt m1 74kbit d 6103us m2 12kbit ls m1 74kbit d 6103us m2 71kbit ul rate 128kbit | tc class add dev eth1 parent 1:1 classid 1:20 hfsc rt m1 68kbit d 15258us m2 64kbit ls m1 68kbit d 15258us m2 35kbit ul rate 128kbit | tc class add dev eth1 parent 1:1 classid 1:30 hfsc ls m1 0kbit d 100000us m2 17kbit ul rate 128kbit | tc class add dev eth1 parent 1:1 classid 1:40 hfsc ls m1 0kbit d 200000us m2 3kbit ul rate 128kbit | tc qdisc add dev eth1 parent 1:10 handle 100: fq_codel | tc qdisc add dev eth1 parent 1:20 handle 200: fq_codel | tc qdisc add dev eth1 parent 1:30 handle 300: fq_codel | tc qdisc add dev eth1 parent 1:40 handle 400: fq_codel | tc filter add dev eth1 parent 1: prio 1 protocol ip handle 1/0xff fw flowid 1:10 | tc filter add dev eth1 parent 1: prio 2 protocol ip handle 2/0xff fw flowid 1:20 | tc filter add dev eth1 parent 1: prio 3 protocol ip handle 3/0xff fw flowid 1:30 | tc filter add dev eth1 parent 1: prio 4 protocol ip handle 4/0xff fw flowid 1:40 | ifconfig ifb0 up txqueuelen 5 >&- 2>&- | tc qdisc del dev ifb0 root >&- 2>&- | tc qdisc add dev ifb0 root handle 1: hfsc default 30 | tc class add dev ifb0 parent 1: classid 1:1 hfsc sc rate 1024kbit ul rate 1024kbit | tc qdisc del dev eth1 ingress >&- 2>&- | tc qdisc add dev eth1 ingress | tc filter add dev eth1 parent ffff: protocol ip prio 1 u32 match u32 0 0 flowid 1:1 action connmark action mirred egress redirect dev ifb0 | tc class add dev ifb0 parent 1:1 classid 1:10 hfsc rt m1 232kbit d 1907us m2 102kbit ls m1 232kbit d 1907us m2 568kbit ul rate 1024kbit | tc class add dev ifb0 parent 1:1 classid 1:20 hfsc rt m1 533kbit d 1907us m2 512kbit ls m1 533kbit d 1907us m2 284kbit ul rate 1024kbit | tc class add dev ifb0 parent 1:1 classid 1:30 hfsc ls m1 0kbit d 100000us m2 142kbit ul rate 1024kbit | tc class add dev ifb0 parent 1:1 classid 1:40 hfsc ls m1 0kbit d 200000us m2 28kbit ul rate 1024kbit | tc qdisc add dev ifb0 parent 1:10 handle 100: fq_codel | tc qdisc add dev ifb0 parent 1:20 handle 200: fq_codel | tc qdisc add dev ifb0 parent 1:30 handle 300: fq_codel | tc qdisc add dev ifb0 parent 1:40 handle 400: fq_codel | tc filter add dev ifb0 parent 1: prio 1 protocol ip handle 1/0xff fw flowid 1:10 | tc filter add dev ifb0 parent 1: prio 2 protocol ip handle 2/0xff fw flowid 1:20 | tc filter add dev ifb0 parent 1: prio 3 protocol ip handle 3/0xff fw flowid 1:30 | tc filter add dev ifb0 parent 1: prio 4 protocol ip handle 4/0xff fw flowid 1:40 | | | | iptables -t mangle -F qos_Default | iptables -t mangle -F qos_Default_ct | iptables -t mangle -D FORWARD -o eth1 -j qos_Default | iptables -t mangle -D OUTPUT -o eth1 -j qos_Default | iptables -t mangle -X qos_Default | iptables -t mangle -X qos_Default_ct | insmod ipt_multiport >&- 2>&- | insmod ipt_CONNMARK >&- 2>&- | insmod ipt_length >&- 2>&- | iptables -t mangle -N qos_Default >&- 2>&- | iptables -t mangle -N qos_Default_ct >&- 2>&- | iptables -t mangle -A qos_Default_ct -m mark --mark 0/0xff -m tcp -p tcp -m multiport --ports 22,53 -j MARK --set-mark 1/0xff | iptables -t mangle -A qos_Default_ct -m mark --mark 0/0xff -p udp -m udp -m multiport --ports 22,53 -j MARK --set-mark 1/0xff | iptables -t mangle -A qos_Default_ct -m mark --mark 0/0xff -p tcp -m tcp -m multiport --ports 20,21,25,80,110,443,993,995 -j MARK --set-mark 3/0xff | iptables -t mangle -A qos_Default_ct -m mark --mark 0/0xff -m tcp -p tcp -m multiport --ports 5190 -j MARK --set-mark 2/0xff | iptables -t mangle -A qos_Default_ct -m mark --mark 0/0xff -p udp -m udp -m multiport --ports 5190 -j MARK --set-mark 2/0xff | iptables -t mangle -A qos_Default_ct -j CONNMARK --save-mark --mask 0xff | iptables -t mangle -A qos_Default -j CONNMARK --restore-mark --mask 0xff | iptables -t mangle -A qos_Default -m mark --mark 0/0xff -j qos_Default_ct | iptables -t mangle -A qos_Default -m mark --mark 0/0xff -p udp -m length --length :500 -j MARK --set-mark 2/0xff | iptables -t mangle -A qos_Default -p icmp -j MARK --set-mark 1/0xff | iptables -t mangle -A qos_Default -m mark --mark 0/0xff -m tcp -p tcp --sport 1024:65535 --dport 1024:65535 -j MARK --set-mark 4/0xff | iptables -t mangle -A qos_Default -m mark --mark 0/0xff -p udp -m udp --sport 1024:65535 --dport 1024:65535 -j MARK --set-mark 4/0xff | iptables -t mangle -A OUTPUT -o eth1 -j qos_Default | iptables -t mangle -A FORWARD -o eth1 -j qos_Default \--------------------------------------------------------------------------- **************************************************************************** * cmd: iptables -L **************************************************************************** | Chain INPUT (policy ACCEPT) | target prot opt source destination | ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED | ACCEPT all -- anywhere anywhere | syn_flood tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN | input_rule all -- anywhere anywhere | input all -- anywhere anywhere | | Chain FORWARD (policy DROP) | target prot opt source destination | ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED | forwarding_rule all -- anywhere anywhere | forward all -- anywhere anywhere | reject all -- anywhere anywhere | | Chain OUTPUT (policy ACCEPT) | target prot opt source destination | ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED | ACCEPT all -- anywhere anywhere | output_rule all -- anywhere anywhere | output all -- anywhere anywhere | | Chain MINIUPNPD (1 references) | target prot opt source destination | | Chain forward (1 references) | target prot opt source destination | zone_lan_forward all -- anywhere anywhere | zone_wan_forward all -- anywhere anywhere | | Chain forwarding_lan (1 references) | target prot opt source destination | | Chain forwarding_rule (1 references) | target prot opt source destination | | Chain forwarding_wan (1 references) | target prot opt source destination | | Chain input (1 references) | target prot opt source destination | zone_lan all -- anywhere anywhere | zone_wan all -- anywhere anywhere | | Chain input_lan (1 references) | target prot opt source destination | | Chain input_rule (1 references) | target prot opt source destination | | Chain input_wan (1 references) | target prot opt source destination | | Chain output (1 references) | target prot opt source destination | zone_lan_ACCEPT all -- anywhere anywhere | zone_wan_ACCEPT all -- anywhere anywhere | | Chain output_rule (1 references) | target prot opt source destination | | Chain reject (5 references) | target prot opt source destination | REJECT tcp -- anywhere anywhere reject-with tcp-reset | REJECT all -- anywhere anywhere reject-with icmp-port-unreachable | | Chain syn_flood (1 references) | target prot opt source destination | RETURN tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN limit: avg 25/sec burst 50 | DROP all -- anywhere anywhere | | Chain zone_lan (1 references) | target prot opt source destination | input_lan all -- anywhere anywhere | zone_lan_ACCEPT all -- anywhere anywhere | | Chain zone_lan_ACCEPT (2 references) | target prot opt source destination | ACCEPT all -- anywhere anywhere | ACCEPT all -- anywhere anywhere | | Chain zone_lan_DROP (0 references) | target prot opt source destination | DROP all -- anywhere anywhere | DROP all -- anywhere anywhere | | Chain zone_lan_REJECT (1 references) | target prot opt source destination | reject all -- anywhere anywhere | reject all -- anywhere anywhere | | Chain zone_lan_forward (1 references) | target prot opt source destination | zone_wan_ACCEPT all -- anywhere anywhere | forwarding_lan all -- anywhere anywhere | zone_lan_REJECT all -- anywhere anywhere | | Chain zone_wan (1 references) | target prot opt source destination | ACCEPT udp -- anywhere anywhere udp dpt:bootpc | ACCEPT icmp -- anywhere anywhere icmp echo-request | input_wan all -- anywhere anywhere | zone_wan_REJECT all -- anywhere anywhere | | Chain zone_wan_ACCEPT (2 references) | target prot opt source destination | ACCEPT all -- anywhere anywhere | ACCEPT all -- anywhere anywhere | | Chain zone_wan_DROP (0 references) | target prot opt source destination | DROP all -- anywhere anywhere | DROP all -- anywhere anywhere | | Chain zone_wan_REJECT (2 references) | target prot opt source destination | reject all -- anywhere anywhere | reject all -- anywhere anywhere | | Chain zone_wan_forward (1 references) | target prot opt source destination | MINIUPNPD all -- anywhere anywhere | forwarding_wan all -- anywhere anywhere | zone_wan_REJECT all -- anywhere anywhere \--------------------------------------------------------------------------- **************************************************************************** * cmd: iptables -t nat -L **************************************************************************** | Chain PREROUTING (policy ACCEPT) | target prot opt source destination | prerouting_rule all -- anywhere anywhere | zone_lan_prerouting all -- anywhere anywhere | zone_wan_prerouting all -- anywhere anywhere | | Chain INPUT (policy ACCEPT) | target prot opt source destination | | Chain OUTPUT (policy ACCEPT) | target prot opt source destination | | Chain POSTROUTING (policy ACCEPT) | target prot opt source destination | postrouting_rule all -- anywhere anywhere | zone_lan_nat all -- anywhere anywhere | zone_wan_nat all -- anywhere anywhere | | Chain MINIUPNPD (1 references) | target prot opt source destination | | Chain postrouting_rule (1 references) | target prot opt source destination | | Chain prerouting_lan (1 references) | target prot opt source destination | | Chain prerouting_rule (1 references) | target prot opt source destination | | Chain prerouting_wan (1 references) | target prot opt source destination | | Chain zone_lan_nat (1 references) | target prot opt source destination | | Chain zone_lan_prerouting (1 references) | target prot opt source destination | prerouting_lan all -- anywhere anywhere | | Chain zone_wan_nat (1 references) | target prot opt source destination | MASQUERADE all -- anywhere anywhere | | Chain zone_wan_prerouting (1 references) | target prot opt source destination | MINIUPNPD all -- anywhere anywhere | prerouting_wan all -- anywhere anywhere \--------------------------------------------------------------------------- **************************************************************************** * cmd: iptables -t mangle -L **************************************************************************** | Chain PREROUTING (policy ACCEPT) | target prot opt source destination | | Chain INPUT (policy ACCEPT) | target prot opt source destination | | Chain FORWARD (policy ACCEPT) | target prot opt source destination | zone_wan_MSSFIX all -- anywhere anywhere | qos_Default all -- anywhere anywhere | | Chain OUTPUT (policy ACCEPT) | target prot opt source destination | qos_Default all -- anywhere anywhere | | Chain POSTROUTING (policy ACCEPT) | target prot opt source destination | | Chain qos_Default (2 references) | target prot opt source destination | CONNMARK all -- anywhere anywhere CONNMARK restore mask 0xff | qos_Default_ct all -- anywhere anywhere mark match 0x0/0xff | MARK udp -- anywhere anywhere mark match 0x0/0xff length 0:500 MARK xset 0x2/0xff | MARK icmp -- anywhere anywhere MARK xset 0x1/0xff | MARK tcp -- anywhere anywhere mark match 0x0/0xff tcp spts:1024:65535 dpts:1024:65535 MARK xset 0x4/0xff | MARK udp -- anywhere anywhere mark match 0x0/0xff udp spts:1024:65535 dpts:1024:65535 MARK xset 0x4/0xff | | Chain qos_Default_ct (1 references) | target prot opt source destination | MARK tcp -- anywhere anywhere mark match 0x0/0xff tcp multiport ports ssh,domain MARK xset 0x1/0xff | MARK udp -- anywhere anywhere mark match 0x0/0xff udp multiport ports ssh,domain MARK xset 0x1/0xff | MARK tcp -- anywhere anywhere mark match 0x0/0xff tcp multiport ports ftp-data,ftp,smtp,www,pop3,https,imaps,pop3s MARK xset 0x3/0xff | MARK tcp -- anywhere anywhere mark match 0x0/0xff tcp multiport ports 5190 MARK xset 0x2/0xff | MARK udp -- anywhere anywhere mark match 0x0/0xff udp multiport ports 5190 MARK xset 0x2/0xff | CONNMARK all -- anywhere anywhere CONNMARK save mask 0xff | | Chain zone_wan_MSSFIX (1 references) | target prot opt source destination | TCPMSS tcp -- anywhere anywhere tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU \--------------------------------------------------------------------------- **************************************************************************** * cmd: tc -s qdisc show dev eth0 **************************************************************************** | qdisc pfifo_fast 0: root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 | Sent 278256856 bytes 260097 pkt (dropped 0, overlimits 0 requeues 0) | backlog 0b 0p requeues 0 \--------------------------------------------------------------------------- **************************************************************************** * cmd: tc -s qdisc show dev eth1 **************************************************************************** | qdisc hfsc 1: root refcnt 2 default 30 | Sent 1447188 bytes 7376 pkt (dropped 0, overlimits 12468 requeues 0) | backlog 0b 0p requeues 0 | qdisc fq_codel 100: parent 1:10 limit 10240p flows 1024 quantum 1518 target 5.0ms interval 100.0ms ecn | Sent 5000 bytes 55 pkt (dropped 0, overlimits 0 requeues 0) | backlog 0b 0p requeues 0 | maxpacket 256 drop_overlimit 0 new_flow_count 27 ecn_mark 0 | new_flows_len 1 old_flows_len 0 | qdisc fq_codel 200: parent 1:20 limit 10240p flows 1024 quantum 1518 target 5.0ms interval 100.0ms ecn | Sent 19246 bytes 145 pkt (dropped 0, overlimits 0 requeues 0) | backlog 0b 0p requeues 0 | maxpacket 350 drop_overlimit 0 new_flow_count 80 ecn_mark 0 | new_flows_len 0 old_flows_len 2 | qdisc fq_codel 300: parent 1:30 limit 10240p flows 1024 quantum 1518 target 5.0ms interval 100.0ms ecn | Sent 720529 bytes 2687 pkt (dropped 223, overlimits 0 requeues 0) | backlog 0b 0p requeues 0 | maxpacket 1514 drop_overlimit 0 new_flow_count 750 ecn_mark 0 | new_flows_len 1 old_flows_len 5 | qdisc fq_codel 400: parent 1:40 limit 10240p flows 1024 quantum 1518 target 5.0ms interval 100.0ms ecn | Sent 702413 bytes 4489 pkt (dropped 1461, overlimits 0 requeues 0) | backlog 0b 0p requeues 0 | maxpacket 1514 drop_overlimit 0 new_flow_count 271 ecn_mark 0 | new_flows_len 0 old_flows_len 1 | qdisc ingress ffff: parent ffff:fff1 ---------------- | Sent 1639987 bytes 3843 pkt (dropped 0, overlimits 0 requeues 0) | backlog 0b 0p requeues 0 \--------------------------------------------------------------------------- **************************************************************************** * cmd: tc -s qdisc show dev ifb0 **************************************************************************** | qdisc hfsc 1: root refcnt 2 default 30 | Sent 1391951 bytes 2762 pkt (dropped 0, overlimits 2001 requeues 0) | backlog 0b 0p requeues 0 | qdisc fq_codel 100: parent 1:10 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn | Sent 4723 bytes 23 pkt (dropped 0, overlimits 0 requeues 0) | backlog 0b 0p requeues 0 | maxpacket 299 drop_overlimit 0 new_flow_count 21 ecn_mark 0 | new_flows_len 1 old_flows_len 0 | qdisc fq_codel 200: parent 1:20 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn | Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) | backlog 0b 0p requeues 0 | maxpacket 256 drop_overlimit 0 new_flow_count 0 ecn_mark 0 | new_flows_len 0 old_flows_len 0 | qdisc fq_codel 300: parent 1:30 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn | Sent 1387228 bytes 2739 pkt (dropped 127, overlimits 0 requeues 0) | backlog 0b 0p requeues 0 | maxpacket 1518 drop_overlimit 0 new_flow_count 1052 ecn_mark 0 | new_flows_len 1 old_flows_len 1 | qdisc fq_codel 400: parent 1:40 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn | Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) | backlog 0b 0p requeues 0 | maxpacket 256 drop_overlimit 0 new_flow_count 0 ecn_mark 0 | new_flows_len 0 old_flows_len 0 \--------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ------------------------------ End of openwrt-devel Digest, Vol 125, Issue 104 *********************************************** _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From Alexey.Brodkin at synopsys.com Tue May 31 13:12:21 2016 From: Alexey.Brodkin at synopsys.com (Alexey Brodkin) Date: Tue, 31 May 2016 20:12:21 +0300 Subject: [OpenWrt-Devel] [PATCH] arc: Build uImage as well as vmlinux output files Message-ID: <1464714741-17559-1-git-send-email-abrodkin@synopsys.com> Initially for ARC we were building vmlinux images because it was both simpler and more convenient to debug Linux kernel in runt-time via JTAG. Now when base system works quite nice we may finally use U-Boot for loading the system image as well. Still we keep building vmlinux images as some of our boards are development boards and loading images with JTAG could be at some points very beneficial. Note for U-Boot header it's required to specify 2 values: * loading address * entry point (if it doesn't match loading address) and in case of ARC entry point (EP) not only differs from loading address but also changes from build to build due to initramfs being placed between loading address and text section. To accommodate that feature we have to calculate EP after vmlinux gets built and before call to mkimage. Signed-off-by: Alexey Brodkin --- target/linux/arc770/image/Makefile | 44 ++++++++++++++++++++++++++++++------- target/linux/archs38/image/Makefile | 44 ++++++++++++++++++++++++++++++------- 2 files changed, 72 insertions(+), 16 deletions(-) diff --git a/target/linux/arc770/image/Makefile b/target/linux/arc770/image/Makefile index 6b9c5e4..47c936e 100644 --- a/target/linux/arc770/image/Makefile +++ b/target/linux/arc770/image/Makefile @@ -7,6 +7,13 @@ include $(TOPDIR)/rules.mk include $(INCLUDE_DIR)/image.mk +# On ARC initramfs is put before entry point and so entry point moves +# in memory from build to built. Thus we need to extract EP from vmlinux +# every time late in building process. +define Build/calculate-ep + $(eval KERNEL_ENTRY=$(shell $(KERNEL_CROSS)readelf -h $(LINUX_DIR)/vmlinux | grep "Entry point address" | grep -o 0x.*)) +endef + define Build/patch-dtb $(call Image/BuildDTB,../dts/$(DEVICE_DTS).dts,$@.dtb) $(STAGING_DIR_HOST)/bin/patch-dtb $@ $@.dtb @@ -16,26 +23,47 @@ endef define Device/Default PROFILES = Default $$(DEVICE_PROFILE) KERNEL_DEPENDS = $$(wildcard ../dts/$$(DEVICE_DTS).dts) - KERNEL_SUFFIX := .elf - KERNEL_INITRAMFS := kernel-bin | patch-dtb - KERNEL_INITRAMFS_NAME = $$(KERNEL_NAME)-initramfs.elf DEVICE_PROFILE := DEVICE_DTS := endef DEVICE_VARS += DEVICE_PROFILE DEVICE_DTS -define add_arc770 - define Device/$(1) +define Device/vmlinux + KERNEL_SUFFIX := .elf + KERNEL_INITRAMFS := kernel-bin | patch-dtb + KERNEL_INITRAMFS_NAME = vmlinux-initramfs.elf +endef + +define Device/uImage + KERNEL_SUFFIX := .bin + KERNEL_INITRAMFS := kernel-bin | patch-dtb | calculate-ep | uImage none + KERNEL_LOADADDR := 0x80000000 +endef + +define add_arc770_uImage + define Device/$(1)-uImage + $(call Device/uImage) + DEVICE_PROFILE := $(1) + DEVICE_DTS := $(1) + endef + TARGET_DEVICES += $(1)-uImage +endef + +define add_arc770_vmlinux + define Device/$(1)-vmlinux + $(call Device/vmlinux) DEVICE_PROFILE := $(1) DEVICE_DTS := $(1) endef - TARGET_DEVICES += $(1) + TARGET_DEVICES += $(1)-vmlinux endef # DesignWare AXS101 -$(eval $(call add_arc770,axs101)) +$(eval $(call add_arc770_vmlinux,axs101)) +$(eval $(call add_arc770_uImage,axs101)) # nSIM with ARC770 -$(eval $(call add_arc770,nsim_700)) +$(eval $(call add_arc770_vmlinux,nsim_700)) +$(eval $(call add_arc770_uImage,nsim_700)) $(eval $(call BuildImage)) diff --git a/target/linux/archs38/image/Makefile b/target/linux/archs38/image/Makefile index 9b0e53f..03bd8ee 100644 --- a/target/linux/archs38/image/Makefile +++ b/target/linux/archs38/image/Makefile @@ -7,6 +7,13 @@ include $(TOPDIR)/rules.mk include $(INCLUDE_DIR)/image.mk +# On ARC initramfs is put before entry point and so entry point moves +# in memory from build to built. Thus we need to extract EP from vmlinux +# every time before generation of uImage. +define Build/calculate-ep + $(eval KERNEL_ENTRY=$(shell $(KERNEL_CROSS)readelf -h $(LINUX_DIR)/vmlinux | grep "Entry point address" | grep -o 0x.*)) +endef + define Build/patch-dtb $(call Image/BuildDTB,../dts/$(DEVICE_DTS).dts,$@.dtb) $(STAGING_DIR_HOST)/bin/patch-dtb $@ $@.dtb @@ -16,26 +23,47 @@ endef define Device/Default PROFILES = Default $$(DEVICE_PROFILE) KERNEL_DEPENDS = $$(wildcard ../dts/$$(DEVICE_DTS).dts) - KERNEL_SUFFIX := .elf - KERNEL_INITRAMFS := kernel-bin | patch-dtb - KERNEL_INITRAMFS_NAME = $$(KERNEL_NAME)-initramfs.elf DEVICE_PROFILE := DEVICE_DTS := endef DEVICE_VARS += DEVICE_PROFILE DEVICE_DTS -define add_archs38 - define Device/$(1) +define Device/vmlinux + KERNEL_SUFFIX := .elf + KERNEL_INITRAMFS := kernel-bin | patch-dtb + KERNEL_INITRAMFS_NAME = vmlinux-initramfs.elf +endef + +define Device/uImage + KERNEL_SUFFIX := .bin + KERNEL_INITRAMFS := kernel-bin | patch-dtb | calculate-ep | uImage none + KERNEL_LOADADDR := 0x80000000 +endef + +define add_archs38_uImage + define Device/$(1)-uImage + $(call Device/uImage) + DEVICE_PROFILE := $(1) + DEVICE_DTS := $(1) + endef + TARGET_DEVICES += $(1)-uImage +endef + +define add_archs38_vmlinux + define Device/$(1)-vmlinux + $(call Device/vmlinux) DEVICE_PROFILE := $(1) DEVICE_DTS := $(1) endef - TARGET_DEVICES += $(1) + TARGET_DEVICES += $(1)-vmlinux endef # DesignWare AXS103 -$(eval $(call add_archs38,axs103_idu)) +$(eval $(call add_archs38_vmlinux,axs103_idu)) +$(eval $(call add_archs38_uImage,axs103_idu)) # nSIM with ARCHS38 -$(eval $(call add_archs38,nsim_hs_idu)) +$(eval $(call add_archs38_vmlinux,nsim_hs_idu)) +$(eval $(call add_archs38_uImage,nsim_hs_idu)) $(eval $(call BuildImage)) -- 2.5.5 _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From eschultz at prplfoundation.org Tue May 31 15:59:11 2016 From: eschultz at prplfoundation.org (Eric Schultz) Date: Tue, 31 May 2016 14:59:11 -0500 Subject: [OpenWrt-Devel] [OpenWrt] [LEDE-DEV] TR-069 for OpenWrt In-Reply-To: References: <57497EE6.4000401@hauke-m.de> Message-ID: I'm certainly supportive of bringing as many people involved as possible. As Jos mentioned, there's likely some approval processes at many companies that need to happen to release the source for public review. Eric On Mon, May 30, 2016 at 5:21 AM, Delbar Jos wrote: > Hauke Mehrtens wrote: > > On 05/27/2016 01:43 AM, Delbar Jos wrote: > > > At Technicolor we have followed with great interest the recent > proposals > > to enhance OpenWrt with an open source solution for TR-069 remote > > management. As one of the world's largest vendors of modems and routers > > for carrier applications, making use of OpenWrt in a significant share > of our > > install base, we want to support this initiative in a meaningful way. > > Concretely, we are willing to open source Technicolor's in-house TR-069 > > solution and thereby contribute to OpenWrt: > > > * a TR-069 protocol agent, > > > * a data model mapping framework that we use to bridge the world of > > > OpenWrt, UCI, UBUS ... with the world of TR-069, TR-098, TR-181 ... > > > (and by extension with the world of SNMP, MIB, NETCONF, YANG ...), > > > * a set of mappings. > > > > That is really nice to hear. For me personally it looks like the remote > > management with TR-069 and similar protocols is one of the biggest > > extensions commercial vendors add to the user space of OpenWrt to make it > > fit their needs. > > > > In addition to the TR-* family does this also include support for SNMP, > MIB, > > NETCONF, YANG ? > > Our proposal does not include protocol agents for SNMP or NETCONF but it > does include a data model mapping framework that can be used to bridge > between these protocols' data models MIB and YANG and an OpenWrt > environment. If you compare this framework with the slides shown by Felix > at the prpl weekly then it's an implementation of the "configuration > backend", or if you compare it with the architecture of a NETCONF project > like https://wiki.openwrt.org/inbox/howto/opencpe then it's an > implementation of "mand". (We aren't using mand.) > > > That's good to hear, would it also be possible that other interested > people > > can join such a workshop? > > The answer is yes as far as I'm concerned. > > Jos > _______________________________________________ > OpenWrt mailing list > OpenWrt at lists.prplfoundation.org > http://lists.prplfoundation.org/cgi-bin/mailman/listinfo/openwrt > -- Eric Schultz, Community Manager, prpl Foundation http://www.prplfoundation.org eschultz at prplfoundation.org cell: 920-539-0404 skype: ericschultzwi @EricPrpl -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From dirk.feytons at gmail.com Tue May 31 16:48:43 2016 From: dirk.feytons at gmail.com (Dirk Feytons) Date: Tue, 31 May 2016 22:48:43 +0200 Subject: [OpenWrt-Devel] [OpenWrt] [LEDE-DEV] TR-069 for OpenWrt In-Reply-To: References: <264724c0-8778-1f31-f054-3a0375103ba2@nbd.name> Message-ID: On 30 May 2016 at 11:58, Delbar Jos wrote: > Felix Fietkau wrote: > > > We are conscious of the fact that together with the proposals made by > > > Felix, Luka and Wojtek we are now looking at many "competing" > proposals. > > > As a next step, we recommend to organize a workshop, at a practical > > > location and time, where we put everything on the table and define the > > > most appropriate path forward to the benefit of OpenWrt as a whole. > > I think such a workshop would be a great idea. It would be nice to have > the > > code available for review some time before that workshop, so we can all > take > > a detailed look at the various proposals before we sit down and decide > how > > to move forward with this. > > I agree that would be helpful. In our case it will take us some weeks > before we can formally release sources. We will be able to share > documentation on architecture, API, features, etc. up front to get the > discussions going. > At the Lua Workshop last year I presented how we're using Lua in our gateways. One of the items is how we implement the TR-069 datamodels in OpenWrt. The talk was recorded and is available at https://www.youtube.com/watch?v=zVzEmewJG8I Dirk F. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From linus.walleij at linaro.org Tue May 31 17:28:21 2016 From: linus.walleij at linaro.org (Linus Walleij) Date: Tue, 31 May 2016 23:28:21 +0200 Subject: [OpenWrt-Devel] Create Technicolor brand in the new data entry page Message-ID: Hi, I was trying to add a Technicolor router to the wiki here: https://wiki.openwrt.org/meta/create_new_dataentry_page But Technicolor does not exist in the Brand list. A previous entry uses Thomson but that is their old name. Can someone here add Technicolor to the brand list? Yours, Linus Walleij _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From linus.walleij at linaro.org Tue May 31 17:29:39 2016 From: linus.walleij at linaro.org (Linus Walleij) Date: Tue, 31 May 2016 23:29:39 +0200 Subject: [OpenWrt-Devel] Create Technicolor brand in the new data entry page In-Reply-To: References: Message-ID: Looping in tmo26, as mentioned at the page. Mea culpa. Yours, Linus Walleij On Tue, May 31, 2016 at 11:28 PM, Linus Walleij wrote: > Hi, > > I was trying to add a Technicolor router to the wiki here: > https://wiki.openwrt.org/meta/create_new_dataentry_page > > But Technicolor does not exist in the Brand list. A previous > entry uses Thomson but that is their old name. > > Can someone here add Technicolor to the brand list? > > Yours, > Linus Walleij _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel From sniperpr at gmail.com Tue May 31 19:38:27 2016 From: sniperpr at gmail.com (sniperpr) Date: Tue, 31 May 2016 23:38:27 +0000 Subject: [OpenWrt-Devel] [OpenWrt] [LEDE-DEV] TR-069 for OpenWrt In-Reply-To: References: <264724c0-8778-1f31-f054-3a0375103ba2@nbd.name> Message-ID: qi_wang at people2000.net tie_yang at people2000.net Dirk Feytons ?2016?6?1? ??04:49??? > On 30 May 2016 at 11:58, Delbar Jos wrote: > >> Felix Fietkau wrote: >> > > We are conscious of the fact that together with the proposals made by >> > > Felix, Luka and Wojtek we are now looking at many "competing" >> proposals. >> > > As a next step, we recommend to organize a workshop, at a practical >> > > location and time, where we put everything on the table and define the >> > > most appropriate path forward to the benefit of OpenWrt as a whole. >> > I think such a workshop would be a great idea. It would be nice to have >> the >> > code available for review some time before that workshop, so we can all >> take >> > a detailed look at the various proposals before we sit down and decide >> how >> > to move forward with this. >> >> I agree that would be helpful. In our case it will take us some weeks >> before we can formally release sources. We will be able to share >> documentation on architecture, API, features, etc. up front to get the >> discussions going. >> > > At the Lua Workshop last year I presented how we're using Lua in our > gateways. One of the items is how we implement the TR-069 datamodels in > OpenWrt. The talk was recorded and is available at > https://www.youtube.com/watch?v=zVzEmewJG8I > > > Dirk F. > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openwrt-devel mailing list openwrt-devel at lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel