[OpenWrt-Devel] [PATCH 1/2] procd: trace: Define syscall registers for powerpc platform

2019-03-08 Thread Wojciech Dubowik 
According to manpage the syscall nr is stored in r0
and return value in r3 for powerpc. Define it so we
can use seccomp and utrace on powerpc.

Signed-off-by: Wojciech Dubowik 
---
 jail/seccomp-bpf.h | 3 +++
 trace/trace.c  | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/jail/seccomp-bpf.h b/jail/seccomp-bpf.h
index fc3ffe7..fd6b3e2 100644
--- a/jail/seccomp-bpf.h
+++ b/jail/seccomp-bpf.h
@@ -81,6 +81,9 @@ struct seccomp_data {
 # else
 #  define ARCH_NR  AUDIT_ARCH_ARMEB
 # endif
+#elif defined(__PPC__)
+# define REG_SYSCALL   regs.gpr[0]
+# define ARCH_NR   AUDIT_ARCH_PPC
 #else
 # warning "Platform does not support seccomp filter yet"
 # define REG_SYSCALL   0
diff --git a/trace/trace.c b/trace/trace.c
index 665c22e..78b99dd 100644
--- a/trace/trace.c
+++ b/trace/trace.c
@@ -58,6 +58,9 @@
 # if defined(__ARM_EABI__)
 # define reg_retval_nr _offsetof(struct user, regs.uregs[0])
 # endif
+#elif defined(__PPC__)
+#define reg_syscall_nr _offsetof(struct user, regs.gpr[0])
+#define reg_retval_nr  _offsetof(struct user, regs.gpr[3])
 #else
 #error tracing is not supported on this architecture
 #endif
-- 
2.17.1


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

[OpenWrt-Devel] [PATCH 2/2] procd: Enable seccomp for powerpc

2019-03-08 Thread Wojciech Dubowik 
Signed-off-by: Wojciech Dubowik 
---
 package/system/procd/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/system/procd/Makefile b/package/system/procd/Makefile
index 6fe609140d..104cae782a 100644
--- a/package/system/procd/Makefile
+++ b/package/system/procd/Makefile
@@ -57,7 +57,7 @@ endef
 define Package/procd-seccomp
   SECTION:=base
   CATEGORY:=Base system
-  DEPENDS:=@arm||@armeb||@mips||@mipsel||@i386||@x86_64 @!TARGET_uml 
@KERNEL_SECCOMP +libubox +libblobmsg-json
+  DEPENDS:=@arm||@armeb||@mips||@mipsel||@i386||@powerpc||@x86_64 @!TARGET_uml 
@KERNEL_SECCOMP +libubox +libblobmsg-json
   TITLE:=OpenWrt process seccomp helper + utrace
 endef
 
-- 
2.17.1


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

Re: [OpenWrt-Devel] [PATCH 2/2] ipq40xx: add support for AVM FRITZ!Repeater 3000

2019-03-08 Thread Christian Lamparter 
On Tuesday, March 5, 2019 7:38:38 PM CET David Bauer wrote:
> Hardware
> 
> CPU:   Qualcomm IPQ4019
> RAM:   256M
> FLASH: 128M NAND
Sorry for being nosy. Did you get any chance to open up the device
and write down what RAM and flash chips are used in your unit?

[...]
> diff --git 
> a/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-fritzrepeater-3000.dts
>  
> b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-fritzrepeater-3000.dts
> new file mode 100644
> index 00..b73a214c09
> --- /dev/null
> +++ 
> b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-fritzrepeater-3000.dts
> @@ -0,0 +1,261 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +
> +#include "qcom-ipq4019.dtsi"
> +#include 
> +#include 
> +#include 
> +
> +/ {
> + model = "AVM FRITZ!Repeater 3000";
> + compatible = "avm,fritzrepeater-3000";
> +
> + aliases {
> + led-boot = &power_led;
> + led-failsafe = &power_led;
> + led-running = &power_led;
> + led-upgrade = &power_led;
> + };
> +
> + keys {
Since it's a single "key" or "button" you can of course
also call this node "key" or "button". Whatever fits the
best.

> + compatible = "gpio-keys";
> +
> + connect {
> + label = "Connect";
> + gpios = <&tlmm 10 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + connect_red {
> + label = "fritzwlan-3000:red:connect";
> + gpios = <&tlmm 30 GPIO_ACTIVE_LOW>;
> + };
> +
> + connect_green {
> + label = "fritzwlan-3000:green:connect";
> + gpios = <&tlmm 31 GPIO_ACTIVE_LOW>;
> + };
> +
> + connect_blue {
> + label = "fritzwlan-3000:blue:connect";
> + gpios = <&tlmm 32 GPIO_ACTIVE_LOW>;
> + };
Just a question: Are the "connect" LED three different LEDs
or just one RGB LED?

> +
> + power_led: power {
> + label = "fritzwlan-3000:green:power";
> + gpios = <&tlmm 33 GPIO_ACTIVE_LOW>;
> + };
> + };
> +};
> +
> +&tlmm {
> + serial_0_pins: serial_pinmux {
> + mux {
> + pins = "gpio16", "gpio17";
> + function = "blsp_uart0";
> + bias-disable;
> + };
> + };
> +
> + nand_pins: nand_pins {
> + pullups {
> + pins = "gpio53", "gpio58", "gpio59";
> + function = "qpic";
> + bias-pull-up;
> + };
> +
> + pulldowns {
> + pins = "gpio54", "gpio55", "gpio56",
> + "gpio57", "gpio60", "gpio61",
> + "gpio62", "gpio63", "gpio64",
> + "gpio65", "gpio66", "gpio67",
> + "gpio68", "gpio69";
> + function = "qpic";
> + bias-pull-down;
> + };
> + };
> +};
> +
> +&nand {
> + pinctrl-0 = <&nand_pins>;
> + pinctrl-names = "default";
> + status = "okay";
> + cs-gpios = <&tlmm 54 GPIO_ACTIVE_HIGH>;
cs-gpios? Oh no! the qcom,ipq4019-nand does not have this property binding.


It looks like this error also slipped by in the 7530 Image. It must have been
copy&pasted from a spi device-tree since gpio54 shows up there.

Luckily, the driver does not do anything with it so gpio54 does not get
reassigned as a gpio pin, otherwise this would be a desaster.

> + nand@0 {
> + partitions {
> + compatible = "fixed-partitions";
> [...]
> +
> +&wifi0 {
> + status = "okay";
> + /* BDFs are identical for the FRITZ!Box 7530 and the FRITZ!Repeater 
> 3000 */
> + qcom,ath10k-calibration-variant = "AVM-FRITZBox-7530";
Didn't find any GPL sources or firmware releases for this device yet. So, I
would much rather err on the side of caution and change this so that the 
device gets its own variant. Even if the boarddata is seemingly shared between
"different" devices from the same vendor.

I'm suggesting this because Qualcomm does this as well for their QCA9377 and
QCA6174 customer cards. Each card has its own copy of the boardfiles even if
it could be shared among two, three or ten. But that's how Qualcomm works.

So, can you please jump through the robes and send the boardfiles upstream?
> +};
> +
> +&wifi1 {
> + status = "okay";
> + ieee80211-freq-limit = <517 535>;
> + /* BDFs are identical for the FRITZ!Box 7530 and the FRITZ!Repeater 
> 3000 */
> + qcom,ath10k-calibration-variant = "AVM-FRITZBox-7530";
>
> +};
> +
> +

Re: [OpenWrt-Devel] [PATCH 2/2] ipq40xx: add support for AVM FRITZ!Repeater 3000

2019-03-08 Thread David Bauer 
Hello Christian,

first of all, thanks for the review!

On 08.03.19 22:23, Christian Lamparter wrote:
> On Tuesday, March 5, 2019 7:38:38 PM CET David Bauer wrote:
>> Hardware
>> 
>> CPU:   Qualcomm IPQ4019
>> RAM:   256M
>> FLASH: 128M NAND
> Sorry for being nosy. Did you get any chance to open up the device
> and write down what RAM and flash chips are used in your unit?

Will be contained in the v2. In the meantime:

RAM:  NANYA NT5CC128M16JR-EK
NAND: Macronix MX30LF1G18AC-XKI

> [...]
>> diff --git 
>> a/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-fritzrepeater-3000.dts
>>  
>> b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-fritzrepeater-3000.dts
>> new file mode 100644
>> index 00..b73a214c09
>> --- /dev/null
>> +++ 
>> b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-fritzrepeater-3000.dts
>> @@ -0,0 +1,261 @@
>> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
>> +
>> +#include "qcom-ipq4019.dtsi"
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/ {
>> +model = "AVM FRITZ!Repeater 3000";
>> +compatible = "avm,fritzrepeater-3000";
>> +
>> +aliases {
>> +led-boot = &power_led;
>> +led-failsafe = &power_led;
>> +led-running = &power_led;
>> +led-upgrade = &power_led;
>> +};
>> +
>> +keys {
> Since it's a single "key" or "button" you can of course
> also call this node "key" or "button". Whatever fits the
> best.

Thanks, will fix that.

> 
>> +compatible = "gpio-keys";
>> +
>> +connect {
>> +label = "Connect";
>> +gpios = <&tlmm 10 GPIO_ACTIVE_LOW>;
>> +linux,code = ;
>> +};
>> +};
>> +
>> +leds {
>> +compatible = "gpio-leds";
>> +
>> +connect_red {
>> +label = "fritzwlan-3000:red:connect";
>> +gpios = <&tlmm 30 GPIO_ACTIVE_LOW>;
>> +};
>> +
>> +connect_green {
>> +label = "fritzwlan-3000:green:connect";
>> +gpios = <&tlmm 31 GPIO_ACTIVE_LOW>;
>> +};
>> +
>> +connect_blue {
>> +label = "fritzwlan-3000:blue:connect";
>> +gpios = <&tlmm 32 GPIO_ACTIVE_LOW>;
>> +};
> Just a question: Are the "connect" LED three different LEDs
> or just one RGB LED?

It's 3 separate LEDs on the PCB, but they are directed to the same spot
on the case, so technically it works like a RGB LED.

>> +
>> +power_led: power {
>> +label = "fritzwlan-3000:green:power";
>> +gpios = <&tlmm 33 GPIO_ACTIVE_LOW>;
>> +};
>> +};
>> +};
>> +
>> +&tlmm {
>> +serial_0_pins: serial_pinmux {
>> +mux {
>> +pins = "gpio16", "gpio17";
>> +function = "blsp_uart0";
>> +bias-disable;
>> +};
>> +};
>> +
>> +nand_pins: nand_pins {
>> +pullups {
>> +pins = "gpio53", "gpio58", "gpio59";
>> +function = "qpic";
>> +bias-pull-up;
>> +};
>> +
>> +pulldowns {
>> +pins = "gpio54", "gpio55", "gpio56",
>> +"gpio57", "gpio60", "gpio61",
>> +"gpio62", "gpio63", "gpio64",
>> +"gpio65", "gpio66", "gpio67",
>> +"gpio68", "gpio69";
>> +function = "qpic";
>> +bias-pull-down;
>> +};
>> +};
>> +};
>> +
>> +&nand {
>> +pinctrl-0 = <&nand_pins>;
>> +pinctrl-names = "default";
>> +status = "okay";
>> +cs-gpios = <&tlmm 54 GPIO_ACTIVE_HIGH>;
> cs-gpios? Oh no! the qcom,ipq4019-nand does not have this property binding.
> 
> 
> It looks like this error also slipped by in the 7530 Image. It must have been
> copy&pasted from a spi device-tree since gpio54 shows up there.
> 
> Luckily, the driver does not do anything with it so gpio54 does not get
> reassigned as a gpio pin, otherwise this would be a desaster.

You are right. I will alter this in v2 and prepare a patch to remove
this property from the 7530. Thanks for spotting this!

>> +nand@0 {
>> +partitions {
>> +compatible = "fixed-partitions";
>> [...]
>> +
>> +&wifi0 {
>> +status = "okay";
>> +/* BDFs are identical for the FRITZ!Box 7530 and the FRITZ!Repeater 
>> 3000 */
>> +qcom,ath10k-calibration-variant = "AVM-FRITZBox-7530";
> Didn't find any GPL sources or firmware releases for this device yet. So, I
> would much rather err on the side of caution and change this so that the 
> device gets its own variant. Even if the boarddata is seemingly shared between
> "different" devices from the same ven

[OpenWrt-Devel] [PATCH v2 1/2] uboot-fritz4040: bump version to 2019-03-03

2019-03-08 Thread David Bauer 
Adds support for the AVM FRITZ!Repeater 3000

Signed-off-by: David Bauer 
---
 package/boot/uboot-fritz4040/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/package/boot/uboot-fritz4040/Makefile 
b/package/boot/uboot-fritz4040/Makefile
index 9af09afcd1..3182842c89 100644
--- a/package/boot/uboot-fritz4040/Makefile
+++ b/package/boot/uboot-fritz4040/Makefile
@@ -10,9 +10,9 @@ include $(INCLUDE_DIR)/kernel.mk
 
 PKG_SOURCE_URL:=https://github.com/chunkeey/FritzBox-4040-UBOOT
 PKG_SOURCE_PROTO:=git
-PKG_SOURCE_VERSION:=d306cce36f98a0a67becc42f20df4b22f1d1465f
-PKG_SOURCE_DATE:=2019-02-08
-PKG_MIRROR_HASH:=715380605dd0cd6ffd65a18b34127bd57dfe9fb0a0164bf8aca703ee018d8070
+PKG_SOURCE_VERSION:=5f383305f4f0be631b51f89e3dc717318057bde9
+PKG_SOURCE_DATE:=2019-03-03
+PKG_MIRROR_HASH:=cb9153480648776cce21f038de8153a0f033066e3d44476ed4c802b48f500fae
 
 PKG_RELEASE:=1
 
-- 
2.21.0


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

[OpenWrt-Devel] [PATCH v2 2/2] ipq40xx: add support for AVM FRITZ!Repeater 3000

2019-03-08 Thread David Bauer 
Hardware

CPU:   Qualcomm IPQ4019
RAM:   256M (NANYA NT5CC128M16JR-EK)
FLASH: 128M NAND (Macronix MX30LF1G18AC-XKI)
ETH:   Qualcomm QCA8072
WiFi2: IPQ4019 2T2R 2SS b/g/n
WiFi5: IPQ4019 2T2R 2SS n/ac
WiFi5: QCA9984 4T4R 4SS n/ac
LED:- Connect green/blue/red
- Power green
BTN:   WPS/Connect
UART:  115200n8 3.3V
   VCC - RX - TX - GND (Square is VCC)

Installation

1. Grab the uboot for the Device from the 'u-boot-fritz3000'
   subdirectory. Place it in the same directory as the 'eva_ramboot.py'
   script. It is located in the 'scripts/flashing' subdirectory of the
   OpenWRT tree.

2. Assign yourself the IP address 192.168.178.10/24. Connect your
   Computer to one of the boxes LAN ports.

3. Connect Power to the Box. As soon as the LAN port of your computer
   shows link, load the U-Boot to the box using following command.

   > ./eva_ramboot.py --offset 0x8500 192.168.178.1 uboot-fritz3000.bin

4. The U-Boot will now start. Now assign yourself the IP address
   192.168.1.70/24. Copy the OpenWRT initramfs (!) image to a TFTP
   server root directory and rename it to 'FRITZ3000.bin'.

5. The Box will now boot OpenWRT from RAM. This can take up to two
   minutes.

6. Copy the U-Boot and the OpenWRT sysupgrade (!) image to the Box using
   scp. SSH into the Box and first write the Bootloader to both previous
   kernel partitions.

   > mtd write /path/to/uboot-fritz3000.bin uboot0
   > mtd write /path/to/uboot-fritz3000.bin uboot1

7. Remove the AVM filesystem partitions to make room for our kernel +
   rootfs + overlayfs.

   > ubirmvol /dev/ubi0 --name=avm_filesys_0
   > ubirmvol /dev/ubi0 --name=avm_filesys_1

8. Flash OpenWRT peristently using sysupgrade.

   > sysupgrade -n /path/to/openwrt-sysupgrade.bin

Signed-off-by: David Bauer 
---
v2:
 - remove cs-gpio property from nand node
 - add device-specific BDF package
 - add RAM and NAND chip model information

 package/boot/uboot-fritz4040/Makefile |   7 +-
 package/firmware/ipq-wifi/Makefile|   3 +-
 .../ipq-wifi/board-avm_fritzrepeater-3000.bin | Bin 0 -> 24332 bytes
 .../ipq40xx/base-files/etc/board.d/02_network |   1 +
 .../etc/hotplug.d/firmware/11-ath10k-caldata  |  10 +-
 .../base-files/lib/upgrade/platform.sh|   1 +
 .../dts/qcom-ipq4019-fritzrepeater-3000.dts   | 260 +
 .../dts/qcom-ipq4019-fritzrepeater-3000.dts   | 264 ++
 target/linux/ipq40xx/image/Makefile   |   9 +
 .../901-arm-boot-add-dts-files.patch  |   3 +-
 .../901-arm-boot-add-dts-files.patch  |   3 +-
 11 files changed, 555 insertions(+), 6 deletions(-)
 create mode 100644 package/firmware/ipq-wifi/board-avm_fritzrepeater-3000.bin
 create mode 100644 
target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-fritzrepeater-3000.dts
 create mode 100644 
target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-fritzrepeater-3000.dts

diff --git a/package/boot/uboot-fritz4040/Makefile 
b/package/boot/uboot-fritz4040/Makefile
index 3182842c89..015ca1deb9 100644
--- a/package/boot/uboot-fritz4040/Makefile
+++ b/package/boot/uboot-fritz4040/Makefile
@@ -25,6 +25,11 @@ define U-Boot/Default
   UBOOT_IMAGE:=uboot-$(1).bin
 endef
 
+define U-Boot/fritz3000
+  NAME:=FritzRepeater 3000
+  BUILD_DEVICES:=avm_fritzrepeater-3000
+endef
+
 define U-Boot/fritz4040
   NAME:=FritzBox 4040
   BUILD_DEVICES:=avm_fritzbox-4040
@@ -61,6 +66,6 @@ define Package/u-boot/install
$(INSTALL_BIN) $(PKG_BUILD_DIR)/upload-to-f4040.sh $(1)/
 endef
 
-UBOOT_TARGETS := fritz4040 fritz7530
+UBOOT_TARGETS := fritz3000 fritz4040 fritz7530
 
 $(eval $(call BuildPackage/U-Boot))
diff --git a/package/firmware/ipq-wifi/Makefile 
b/package/firmware/ipq-wifi/Makefile
index 9a00832ca2..d273667f68 100644
--- a/package/firmware/ipq-wifi/Makefile
+++ b/package/firmware/ipq-wifi/Makefile
@@ -18,7 +18,7 @@ endef
 # Please send a mail with your device-specific board files upstream.
 # You can find instructions and examples on the linux-wireless wiki:
 # 
-ALLWIFIBOARDS:=alfa-network_ap120c-ac asus_map-ac2200 avm_fritzbox-7530 
engenius_eap1300 linksys_ea6350v3 qxwlan_e2600ac
+ALLWIFIBOARDS:=alfa-network_ap120c-ac asus_map-ac2200 avm_fritzbox-7530 
avm_fritzrepeater-3000 engenius_eap1300 linksys_ea6350v3 qxwlan_e2600ac
 ALLWIFIPACKAGES:=$(foreach BOARD,$(ALLWIFIBOARDS),ipq-wifi-$(BOARD))
 
 define Package/ipq-wifi-default
@@ -57,6 +57,7 @@ $(eval $(call 
generate-ipq-wifi-package,alfa-network_ap120c-ac,board-alfa-networ
 $(eval $(call 
generate-ipq-wifi-package,asus_map-ac2200,board-map-ac2200.bin,ASUS MAP-AC2200))
 $(eval $(call 
generate-ipq-wifi-package,engenius_eap1300,board-engenius_eap1300.bin,EnGenius 
EAP1300))
 $(eval $(call 
generate-ipq-wifi-package,avm_fritzbox-7530,board-avm_fritzbox-7530.bin,AVM 
FRITZ!Box 7530))
+$(eval $(call 
generate-ipq-wifi-package,avm_fritzrepeater-3000,board-avm_fritzrepeater-3000.bin,AVM

Re: [OpenWrt-Devel] [PATCH 2/2] ipq40xx: add support for AVM FRITZ!Repeater 3000

2019-03-08 Thread David Bauer 
Hello Christian,

missed one thing (which might also be interesting to others)

On 08.03.19 22:23, Christian Lamparter wrote:
> Didn't find any GPL sources or firmware releases for this device yet. So, I
> would much rather err on the side of caution and change this so that the 
> device gets its own variant. Even if the boarddata is seemingly shared between
> "different" devices from the same vendor.
> 

While the GPL tarball for the Repeater 3000 is missing, everything is
contained in the tarball for the FRITZ!Box 7530. [0]
Although maybe not relevant for this particular device, the tarball also
contains code for the new QCN550x series from Qualcomm.

They also put up a factory image on their FTP in the last days which can
be found here. [1]

[0] http://osp.avm.de/fritzbox/fritzbox-7530/
[1] http://ftp.avm.de/fritzwlan/fritzrepeater-3000/deutschland/fritz.os/

Best wishes
David

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

[OpenWrt-Devel] [PATCH] ipq40xx: fix FRITZBox 7530 NAND controller node

2019-03-08 Thread David Bauer 
This removes the 'cs-gpios' property from the AVM FRITZ!Box 7530 NAND
controller node. As pointed out by Christian Lamparter, the property is
not needed by the Qualcomm NAND controller driver.

Signed-off-by: David Bauer 
---
 .../files-4.14/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts  | 1 -
 .../files-4.19/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts  | 1 -
 2 files changed, 2 deletions(-)

diff --git 
a/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts
 
b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts
index 45c4864855..ce117b451a 100644
--- 
a/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts
+++ 
b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts
@@ -167,7 +167,6 @@
pinctrl-0 = <&nand_pins>;
pinctrl-names = "default";
status = "okay";
-   cs-gpios = <&tlmm 54 GPIO_ACTIVE_HIGH>;
 
nand@0 {
partitions {
diff --git 
a/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts
 
b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts
index 53f83f411b..b04a61dc04 100644
--- 
a/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts
+++ 
b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts
@@ -171,7 +171,6 @@
pinctrl-0 = <&nand_pins>;
pinctrl-names = "default";
status = "okay";
-   cs-gpios = <&tlmm 54 GPIO_ACTIVE_HIGH>;
 
nand@0 {
partitions {
-- 
2.21.0


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

Re: [OpenWrt-Devel] [PATCH] mdadm: revised mdadm config & init logic

2019-03-08 Thread Rosen Penev 
On Sat, Mar 2, 2019 at 1:11 AM Rosen Penev  wrote:
>
> On Tue, Feb 26, 2019 at 6:05 PM Joseph Tingiris
>  wrote:
> >
> > This is a significant revision of /etc/init.d/mdadm.  It adds new
> > features, support for new configuration options, safer error
> > handling, (configurable) verbose output, and contains multiple bug
> > fixes.
> >
> > Most notably, mdadm was being started with the --config flag and
> > that prevented it from using its built in Auto Assembly features.
> > Users were required to put a correct uuid in /etc/config/mdadm.
> >
> > The new default startup mode is now to automatically assemble all
> > RAID arrays attached to the machine using device scans, rather than
> > configuation options.
> >
> > A new UCI section, config mdadm global, was added with new options that
> > are supported by the accompanying /etc/init.d/mdadm. Documentation for all
> > new (and previous) options was added as well.  See the
> > /etc/config/mdadmin or mdadm.init file itself for more details.
> >
> > Additionally, a new stateful 'auto' feature was added that functions
> > similarly to the stateless Auto Assembly feature.  The benefits of
> > stateful auto assembly are to support features that mdadm 4.0 will only
> > read from a configuration file, such as setting the MAILFROM value.  The
> > new mdadm_conf_auto() function will also aid users in troubleshooting.
> > When verbose is turned on it provides tips and better visibility for what's
> > actually happening.
> >
> > Backward compatibility was retained.  Stateful UCI only configurations are
> > supported.  All previously existing configurations will work in this mode.
> > However, these users will now have to explicitly turn it on.
> >
> > A new reload_service() function was added to prevent reloads from
> > stopping mdadm.  Reloads will now be ignored, though the stage is set for
> > reloads to trigger scans for new devices.  Explicit restarts still work as
> > expected.
> >
> > The start_service() function was enhanced to query new UCI mdadm.global
> > options: alert_program, config, email, email_from, monitor_frequency,
> > and verbose.  Each option is documented in /etc/mdadm/config (config.init) 
> > and
> > some additional code comments were added.
> >
> > Finally, error handling and verbose output was enhanced.  Users will
> > know what's going on (if verbose is turned on).
> >
> > Strict reliance on a shell global ($CONF) was removed and replaced with a
> > single global ($TMP_FILE) that's for development convenience.  When/if a 
> > config
> > file is not specified in the UCI config, it will fall back to using 
> > $TMP_FILE as the
> > configuration file.
> >
> > Incremented PKG_RELEASE from 1 to 2
> >
> > Signed-off-by: Joseph Tingiris 
> Tested-by: Rosen Penev 
Hrm for some reason I now get the error:

/etc/rc.common: /etc/init.d/mdadm: line 214: syntax error: unexpected
redirection

on a fresh build.
> > ---
> >  package/utils/mdadm/Makefile   |   2 +-
> >  package/utils/mdadm/files/mdadm.config | 162 +-
> >  package/utils/mdadm/files/mdadm.init   | 555 
> > +
> >  3 files changed, 646 insertions(+), 73 deletions(-)
> >
> > diff --git a/package/utils/mdadm/Makefile b/package/utils/mdadm/Makefile
> > index 18026bb..f20a58b 100644
> > --- a/package/utils/mdadm/Makefile
> > +++ b/package/utils/mdadm/Makefile
> > @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
> >
> >  PKG_NAME:=mdadm
> >  PKG_VERSION:=4.1
> > -PKG_RELEASE:=1
> > +PKG_RELEASE:=2
> >
> >  PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
> >  PKG_SOURCE_URL:=@KERNEL/linux/utils/raid/mdadm
> > diff --git a/package/utils/mdadm/files/mdadm.config 
> > b/package/utils/mdadm/files/mdadm.config
> > index 50afbc2..0c78c96 100644
> > --- a/package/utils/mdadm/files/mdadm.config
> > +++ b/package/utils/mdadm/files/mdadm.config
> > @@ -1,18 +1,154 @@
> > -config mdadm
> > +#
> > +# The mdadm 'global' section is for options that apply to all sections.
> > +#
> > +
> > +config mdadm global
> > +
> > +   #
> > +   # option 'alert_program' values may be a path to a valid, 
> > executable binary.
> > +   #
> > +   # The default 'alert_program' is not set.
> > +   #
> > +   # When mdadm detects an event it will execute this program with 3 
> > arguments, see https://linux.die.net/man/8/mdadm
> > +   # $1 = will be the event
> > +   # $2 = will be the meta device
> > +   # $3 = may be a related component (if one exists)
> > +   #
> > +   # * alert_program runs independently from sendmail.
> > +   # * If both options alert_program and email are set, and both work, 
> > then an email and a
> > +   #   custom alert will be generated.
> > +   # * no alert program is included in mdadm 4.0-4.
> > +   #
> > +   # Lots of possibilities exist, i.e. scripts for netdata, slack, etc.
> > +   #
> > +   #option alert_program /usr/sbin/mdadm_alerts
> > +
> > +
> > +   #
> > +   # option 'config' va