[OpenWrt-Devel] [PATCH v2 2/2] oxnas: build S-ATA driver as a module
Signed-off-by: Daniel Golle dan...@makrotopia.org --- package/kernel/linux/modules/block.mk | 16 target/linux/oxnas/Makefile | 4 ++-- target/linux/oxnas/config-3.14| 2 -- target/linux/oxnas/config-3.18| 2 -- 4 files changed, 18 insertions(+), 6 deletions(-) diff --git a/package/kernel/linux/modules/block.mk b/package/kernel/linux/modules/block.mk index 8a84aa4..20588ac 100644 --- a/package/kernel/linux/modules/block.mk +++ b/package/kernel/linux/modules/block.mk @@ -116,6 +116,22 @@ endef $(eval $(call KernelPackage,ata-nvidia-sata)) +define KernelPackage/ata-oxnas-sata + TITLE:=oxnas Serial ATA support + KCONFIG:=CONFIG_SATA_OXNAS + DEPENDS:=@TARGET_oxnas + FILES:=$(LINUX_DIR)/drivers/ata/sata_oxnas.ko + AUTOLOAD:=$(call AutoLoad,41,sata_oxnas,1) + $(call AddDepends/ata) +endef + +define KernelPackage/ata-oxnas-sata/description + SATA support for OX934 core found in the OX82x/PLX782x SoCs +endef + +$(eval $(call KernelPackage,ata-oxnas-sata)) + + define KernelPackage/ata-pdc202xx-old SUBMENU:=$(BLOCK_MENU) TITLE:=Older Promise PATA controller support diff --git a/target/linux/oxnas/Makefile b/target/linux/oxnas/Makefile index e0f2d4c..547a08a 100644 --- a/target/linux/oxnas/Makefile +++ b/target/linux/oxnas/Makefile @@ -20,8 +20,8 @@ KERNEL_PATCHVER:=3.14 include $(INCLUDE_DIR)/target.mk DEFAULT_PACKAGES += \ - kmod-button-hotplug kmod-input-gpio-keys-polled kmod-leds-gpio \ - kmod-usb2-oxnas uboot-envtools uboot-oxnas-ox820 + kmod-ata-oxnas-sata kmod-button-hotplug kmod-input-gpio-keys-polled \ + kmod-leds-gpio kmod-usb2-oxnas uboot-envtools uboot-oxnas-ox820 KERNELNAME:=zImage dtbs diff --git a/target/linux/oxnas/config-3.14 b/target/linux/oxnas/config-3.14 index 086f870..473a2bf 100644 --- a/target/linux/oxnas/config-3.14 +++ b/target/linux/oxnas/config-3.14 @@ -25,7 +25,6 @@ CONFIG_ARM_NR_BANKS=8 CONFIG_ARM_PATCH_PHYS_VIRT=y CONFIG_ARM_THUMB=y CONFIG_ARM_UNWIND=y -CONFIG_ATA=y CONFIG_AUTO_ZRELADDR=y # CONFIG_BLK_DEV_INITRD is not set CONFIG_BLK_DEV_SD=y @@ -298,7 +297,6 @@ CONFIG_RFS_ACCEL=y CONFIG_RPS=y CONFIG_RTC_CLASS=y # CONFIG_RTC_DRV_CMOS is not set -CONFIG_SATA_OXNAS=y CONFIG_SCHED_HRTICK=y CONFIG_SCSI=y CONFIG_SERIAL_8250_NR_UARTS=1 diff --git a/target/linux/oxnas/config-3.18 b/target/linux/oxnas/config-3.18 index f66650a..56dce65 100644 --- a/target/linux/oxnas/config-3.18 +++ b/target/linux/oxnas/config-3.18 @@ -29,7 +29,6 @@ CONFIG_ARM_L1_CACHE_SHIFT=5 CONFIG_ARM_PATCH_PHYS_VIRT=y CONFIG_ARM_THUMB=y CONFIG_ARM_UNWIND=y -CONFIG_ATA=y # CONFIG_AUDIT_ARCH_COMPAT_GENERIC is not set CONFIG_AUTO_ZRELADDR=y # CONFIG_BLK_DEV_INITRD is not set @@ -316,7 +315,6 @@ CONFIG_RTC_CLASS=y # CONFIG_RTC_DRV_CMOS is not set CONFIG_RWSEM_SPIN_ON_OWNER=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y -CONFIG_SATA_OXNAS=y CONFIG_SCHED_HRTICK=y CONFIG_SCSI=y CONFIG_SERIAL_8250_NR_UARTS=1 -- 2.1.3 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Please remove me from spam list
On 12/12/2014 11:26, yangbo wrote: Hi, Please remove me from spam list. Maybe I send similar mail to offen... Thank you. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel Hi, last mail i see from you is http://patchwork.ozlabs.org/patch/419377/ http://patchwork.ozlabs.org/patch/419394/ http://patchwork.ozlabs.org/patch/419394/ too which i already replied what makes you think you are in the spam list ? John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ltq-tapi: configure: error: The lib_ifxos include directory is not valid!
Quoting Robert P. J. Day: building for ar71xx: ... make[2]: *** [package/kernel/lantiq/ltq-tapi/compile] Error 2 ... this build worked fine yesterday, pulled to update to current trunk and now the above. You are probably including asterisk in your build, right? The reason is a change in asterisk package in the telephony feed. A lantiq-related change apparently poisons other platforms. The change also killed all buildbot builds (except lantiq): http://buildbot.openwrt.org:8010/one_line_per_build Change: https://github.com/openwrt/telephony/commit/a0a71ff78294b74da82dd0ee2fc62953dc1cc4d0 discussion / bug report: https://github.com/openwrt/telephony/issues/2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] lenovo Y1/S port mapping
Y1S has 2 Gigabit LAN. So I used the following: y1 |\ y1s) ucidef_set_interfaces_lan_wan eth0.1 eth0.2 ucidef_add_switch switch0 1 1 ucidef_add_switch_vlan switch0 1 0 1 2 3 5 6t 7 ucidef_add_switch_vlan switch0 2 4 6t ;; Tested on Y1. But I don't have a Y1S so I can't test if this is the correct config. AhSorry for my bad English:-) 2014-12-12 3:44 GMT+08:00, John Crispin blo...@openwrt.org: Hi, any lenovo Y1S users around ? while looking into this ticket - https://dev.openwrt.org/ticket/18528 i found this site - http://show.smzdm.com/detail/94937 looking at the picture i think the port mapping is totally broken. we currently have y1 |\ y1s) ucidef_set_interfaces_lan_wan eth0.1 eth0.2 ucidef_add_switch switch0 1 1 ucidef_add_switch_vlan switch0 1 1 2 3 4 5 6t ucidef_add_switch_vlan switch0 2 0 6t wan on Y1 should be port 4 and wan on Y1S should be port 5 (gmac1) i think it should be y1) ucidef_set_interfaces_lan_wan eth0.1 eth0.2 ucidef_add_switch switch0 1 1 ucidef_add_switch_vlan switch0 1 0 1 2 3 6t ucidef_add_switch_vlan switch0 2 4 6t y1s) ucidef_set_interfaces_lan_wan eth0.1 eth0.2 ucidef_add_switch switch0 1 1 ucidef_add_switch_vlan switch0 1 0 1 2 3 4 6t ucidef_add_switch_vlan switch0 2 5 6t could someone tell me if the case has WAN written on any of the ports ? John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ltq-tapi: configure: error: The lib_ifxos include directory is not valid!
Quoting Hannu Nyman hannu.ny...@iki.fi: Quoting Robert P. J. Day: building for ar71xx: ... make[2]: *** [package/kernel/lantiq/ltq-tapi/compile] Error 2 ... this build worked fine yesterday, pulled to update to current trunk and now the above. You are probably including asterisk in your build, right? The reason is a change in asterisk package in the telephony feed. A lantiq-related change apparently poisons other platforms. That would be what I'm doing, yes. So, for now, out with Asterisk. rday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/3] Fix SSL negotiation being interrupted by .notify_write from BIO method.
On 2014-12-12 05:16, Yousong Zhou wrote:
On 12 December 2014 at 00:42, Felix Fietkau n...@openwrt.org wrote:
On 2014-11-11 11:34, Yousong Zhou wrote:
ustream_ssl_check_conn() may be called by .notify_write while a previous
SSL_connect() is still in process. This can happen because the
.notify_write callback will may be triggered by writes in the BIO
methods.
Signed-off-by: Yousong Zhou yszhou4t...@gmail.com
---
ustream-ssl.c | 19 +++
ustream-ssl.h |1 +
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/ustream-ssl.c b/ustream-ssl.c
index dd0faf9..84104b0 100644
--- a/ustream-ssl.c
+++ b/ustream-ssl.c
@@ -34,12 +34,22 @@ static void ustream_ssl_error_cb(struct uloop_timeout
*t)
us-notify_error(us, error, __ustream_ssl_strerror(us-error,
buffer, sizeof(buffer)));
}
+static enum ssl_conn_status ustream_ssl_do_connect(struct ustream_ssl *us)
+{
+ enum ssl_conn_status status;
+
+ us-connecting = true;
+ status = __ustream_ssl_connect(us);
+ us-connecting = false;
+ return status;
+}
+
I think this can be fixed in a much simpler way. Simply prevent
re-entrant calls to __ustream_ssl_connect through a static variable.
Guarding it with a single static variable do not work well with
multiple instances of ustream_ssl.
How so? Even with multiple instances a call stack from one instance that
calls do_connect should not end up with re-entrant calls for a different
instance.
- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH RESEND] mxs: make boardname consistent with other targets
Michael Heimpold wrote: Remove 'series' as all other targets do not use this, too. It should be obviously clear, that this target refer to a whole CPU family. Signed-off-by: Michael Heimpold m...@heimpold.de --- Hi Michael, Applied most of the series in r43646-43651, r43657, I've put an SOB where I could test the patch. The whitespace fix doesn't apply cleanly - would you mind to re-send that please. Anyway, many thanks for the patches and your patience. Regards, -w- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH RESEND] mxs: make boardname consistent with other targets
On 12/12/2014 14:46, Zoltan HERPAI wrote: Michael Heimpold wrote: Remove 'series' as all other targets do not use this, too. It should be obviously clear, that this target refer to a whole CPU family. Signed-off-by: Michael Heimpold m...@heimpold.de --- Hi Michael, Applied most of the series in r43646-43651, r43657, I've put an SOB where I could test the patch. The whitespace fix doesn't apply cleanly - would you mind to re-send that please. Anyway, many thanks for the patches and your patience. Regards, -w- great let me close the patches in the new patchwork. zoltan, can you setup a user on the ozlab machine so that i can give you back your admin status ? John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v3 2/2] oxnas: build S-ATA driver as a module
Signed-off-by: Daniel Golle dan...@makrotopia.org --- package/kernel/linux/modules/block.mk | 16 target/linux/oxnas/Makefile | 5 +++-- target/linux/oxnas/config-3.14| 2 -- target/linux/oxnas/config-3.18| 2 -- 4 files changed, 19 insertions(+), 6 deletions(-) diff --git a/package/kernel/linux/modules/block.mk b/package/kernel/linux/modules/block.mk index 8a84aa4..20588ac 100644 --- a/package/kernel/linux/modules/block.mk +++ b/package/kernel/linux/modules/block.mk @@ -116,6 +116,22 @@ endef $(eval $(call KernelPackage,ata-nvidia-sata)) +define KernelPackage/ata-oxnas-sata + TITLE:=oxnas Serial ATA support + KCONFIG:=CONFIG_SATA_OXNAS + DEPENDS:=@TARGET_oxnas + FILES:=$(LINUX_DIR)/drivers/ata/sata_oxnas.ko + AUTOLOAD:=$(call AutoLoad,41,sata_oxnas,1) + $(call AddDepends/ata) +endef + +define KernelPackage/ata-oxnas-sata/description + SATA support for OX934 core found in the OX82x/PLX782x SoCs +endef + +$(eval $(call KernelPackage,ata-oxnas-sata)) + + define KernelPackage/ata-pdc202xx-old SUBMENU:=$(BLOCK_MENU) TITLE:=Older Promise PATA controller support diff --git a/target/linux/oxnas/Makefile b/target/linux/oxnas/Makefile index e0f2d4c..e919eef 100644 --- a/target/linux/oxnas/Makefile +++ b/target/linux/oxnas/Makefile @@ -20,8 +20,9 @@ KERNEL_PATCHVER:=3.14 include $(INCLUDE_DIR)/target.mk DEFAULT_PACKAGES += \ - kmod-button-hotplug kmod-input-gpio-keys-polled kmod-leds-gpio \ - kmod-usb2-oxnas uboot-envtools uboot-oxnas-ox820 + kmod-ata-core kmod-ata-oxnas-sata kmod-button-hotplug \ + kmod-input-gpio-keys-polled kmod-leds-gpio kmod-usb2-oxnas \ + uboot-envtools uboot-oxnas-ox820 KERNELNAME:=zImage dtbs diff --git a/target/linux/oxnas/config-3.14 b/target/linux/oxnas/config-3.14 index 086f870..473a2bf 100644 --- a/target/linux/oxnas/config-3.14 +++ b/target/linux/oxnas/config-3.14 @@ -25,7 +25,6 @@ CONFIG_ARM_NR_BANKS=8 CONFIG_ARM_PATCH_PHYS_VIRT=y CONFIG_ARM_THUMB=y CONFIG_ARM_UNWIND=y -CONFIG_ATA=y CONFIG_AUTO_ZRELADDR=y # CONFIG_BLK_DEV_INITRD is not set CONFIG_BLK_DEV_SD=y @@ -298,7 +297,6 @@ CONFIG_RFS_ACCEL=y CONFIG_RPS=y CONFIG_RTC_CLASS=y # CONFIG_RTC_DRV_CMOS is not set -CONFIG_SATA_OXNAS=y CONFIG_SCHED_HRTICK=y CONFIG_SCSI=y CONFIG_SERIAL_8250_NR_UARTS=1 diff --git a/target/linux/oxnas/config-3.18 b/target/linux/oxnas/config-3.18 index f66650a..56dce65 100644 --- a/target/linux/oxnas/config-3.18 +++ b/target/linux/oxnas/config-3.18 @@ -29,7 +29,6 @@ CONFIG_ARM_L1_CACHE_SHIFT=5 CONFIG_ARM_PATCH_PHYS_VIRT=y CONFIG_ARM_THUMB=y CONFIG_ARM_UNWIND=y -CONFIG_ATA=y # CONFIG_AUDIT_ARCH_COMPAT_GENERIC is not set CONFIG_AUTO_ZRELADDR=y # CONFIG_BLK_DEV_INITRD is not set @@ -316,7 +315,6 @@ CONFIG_RTC_CLASS=y # CONFIG_RTC_DRV_CMOS is not set CONFIG_RWSEM_SPIN_ON_OWNER=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y -CONFIG_SATA_OXNAS=y CONFIG_SCHED_HRTICK=y CONFIG_SCSI=y CONFIG_SERIAL_8250_NR_UARTS=1 -- 2.1.3 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/3] Fix SSL negotiation being interrupted by .notify_write from BIO method.
On 12 December 2014 at 19:36, Felix Fietkau n...@openwrt.org wrote:
On 2014-12-12 05:16, Yousong Zhou wrote:
On 12 December 2014 at 00:42, Felix Fietkau n...@openwrt.org wrote:
On 2014-11-11 11:34, Yousong Zhou wrote:
ustream_ssl_check_conn() may be called by .notify_write while a previous
SSL_connect() is still in process. This can happen because the
.notify_write callback will may be triggered by writes in the BIO
methods.
Signed-off-by: Yousong Zhou yszhou4t...@gmail.com
---
ustream-ssl.c | 19 +++
ustream-ssl.h |1 +
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/ustream-ssl.c b/ustream-ssl.c
index dd0faf9..84104b0 100644
--- a/ustream-ssl.c
+++ b/ustream-ssl.c
@@ -34,12 +34,22 @@ static void ustream_ssl_error_cb(struct uloop_timeout
*t)
us-notify_error(us, error,
__ustream_ssl_strerror(us-error, buffer, sizeof(buffer)));
}
+static enum ssl_conn_status ustream_ssl_do_connect(struct ustream_ssl *us)
+{
+ enum ssl_conn_status status;
+
+ us-connecting = true;
+ status = __ustream_ssl_connect(us);
+ us-connecting = false;
+ return status;
+}
+
I think this can be fixed in a much simpler way. Simply prevent
re-entrant calls to __ustream_ssl_connect through a static variable.
Guarding it with a single static variable do not work well with
multiple instances of ustream_ssl.
How so? Even with multiple instances a call stack from one instance that
calls do_connect should not end up with re-entrant calls for a different
instance.
But we do not want do_connect() of different instances intervening
with each other, do we?
yousong
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/3] brcm63xx: add bcm6345-gpio driver
On Thu, Dec 11, 2014 at 12:51 AM, Álvaro Fernández Rojas
nolt...@gmail.com wrote:
Signed-off-by: Álvaro Fernández Rojas nolt...@gmail.com
---
diff --git a/target/linux/brcm63xx/config-3.14
b/target/linux/brcm63xx/config-3.14
index dd27f47..f94c567 100644
--- a/target/linux/brcm63xx/config-3.14
+++ b/target/linux/brcm63xx/config-3.14
@@ -76,6 +76,7 @@ CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_GPIOLIB=y
+CONFIG_GPIO_BCM6345=y
CONFIG_GPIO_DEVRES=y
CONFIG_GPIO_SYSFS=y
# CONFIG_HAMRADIO is not set
diff --git a/target/linux/brcm63xx/config-3.18
b/target/linux/brcm63xx/config-3.18
index e3cf020..7957d02 100644
--- a/target/linux/brcm63xx/config-3.18
+++ b/target/linux/brcm63xx/config-3.18
@@ -80,6 +80,7 @@ CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_GPIOLIB=y
+CONFIG_GPIO_BCM6345=y
CONFIG_GPIO_DEVRES=y
CONFIG_GPIO_SYSFS=y
# CONFIG_HAMRADIO is not set
diff --git
a/target/linux/brcm63xx/patches-3.14/374-GPIO-DT-add-bcm6345-driver.patch
b/target/linux/brcm63xx/patches-3.14/374-GPIO-DT-add-bcm6345-driver.patch
new file mode 100644
index 000..a6c775b
--- /dev/null
+++ b/target/linux/brcm63xx/patches-3.14/374-GPIO-DT-add-bcm6345-driver.patch
@@ -0,0 +1,244 @@
+--- /dev/null
b/drivers/gpio/gpio-bcm6345.c
+@@ -0,0 +1,216 @@
++/*
++ * This file is subject to the terms and conditions of the GNU General
Public
++ * License. See the file COPYING in the main directory of this archive
++ * for more details.
++ *
++ * Copyright (C) 2008 Maxime Bizon mbi...@freebox.fr
++ * Copyright (C) 2008-2011 Florian Fainelli flor...@openwrt.org
++ * Copyright (C) 2014 Álvaro Fernández Rojas nolt...@gmail.com
++ */
++
++#include linux/kernel.h
++#include linux/module.h
++#include linux/spinlock.h
++#include linux/platform_device.h
++#include linux/gpio.h
++
++enum bcm6345_gpio_reg {
++ GPIO_REG_CTL_HI = 0,
++ GPIO_REG_CTL_LO,
++ GPIO_REG_DATA_HI,
++ GPIO_REG_DATA_LO,
++ GPIO_REG_MAX
++};
++
++struct bcm6345_gpio_chip {
++ struct gpio_chip chip;
++ u8 regs[GPIO_REG_MAX];
I think we could replace the whole driver with
e.g. bcm6345:
gpio0: gpio-controller@fffe0404 {
compatible = basic-mmio-gpio-be;
regs = 0xfffe0404 0x4 0xfffe0408 0x2
reg-names = dirin, dat;
gpio-controller;
#gpio-cells = 2;
};
and for the ones with 32 gpios:
gpio0: gpio-controller@1084 {
compatible = basic-mmio-gpio-be;
regs = 0x1084 0x4 0x108c 0x4
reg-names = dirin, dat;
gpio-controller;
#gpio-cells = 2;
};
gpio1: gpio-controller@180 {
compatible = basic-mmio-gpio-be;
regs = 0x1080 0x4 0x108c 0x4
reg-names = dirin, dat;
gpio-controller;
#gpio-cells = 2;
};
Maybe add support for setting ngpios through DT, or make it a usable-mask or so.
For the gpio-base problem, we should be able to register appropriate
platform data for it as OF_DEV_AUXDATA() in of_platform_populate.
e.g.
struct bgpio_pdata gpio0_pdata = {
.base = 0,
};
struct bgpio_pdata gpio1_pdata = {
.base = 32,
};
struct of_dev_auxdata auxdata[] = {
OF_DEV_AUXDATA(basic-mmio-gpio-be,0xfffe0400, NULL, gpio1_pdata),
OF_DEV_AUXDATA(basic-mmio-gpio-be,0xfffe0404, NULL, gpio0_pdata),
OF_DEV_AUXDATA(basic-mmio-gpio-be,0xfffe0080, NULL, gpio1_pdata),
OF_DEV_AUXDATA(basic-mmio-gpio-be,0xfffe0084, NULL, gpio0_pdata),
OF_DEV_AUXDATA(basic-mmio-gpio-be,0x1080, NULL, gpio1_pdata),
OF_DEV_AUXDATA(basic-mmio-gpio-be,0x1084, NULL, gpio0_pdata),
};
...
of_platform_populate(... auxdata, );
Jonas
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/3] brcm63xx: add bcm6345-gpio driver
On 12/12/2014 15:12, Jonas Gorski wrote:
or the gpio-base problem, we should be able to register appropriate
platform data for it as OF_DEV_AUXDATA() in of_platform_populate.
e.g.
struct bgpio_pdata gpio0_pdata = {
.base = 0,
};
struct bgpio_pdata gpio1_pdata = {
.base = 32,
};
tried it for ralink and lantiq and it got nak'ed by LinusW
i keep that part of the code as a small patch inside owrt on top of the
stuff i sent upstream.
John
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/3] brcm63xx: use bcm6345-gpio over legacy
On Thu, Dec 11, 2014 at 12:52 AM, Álvaro Fernández Rojas
nolt...@gmail.com wrote:
Signed-off-by: Álvaro Fernández Rojas nolt...@gmail.com
---
diff --git a/target/linux/brcm63xx/patches-3.14/375-GPIO-DT-over-legacy.patch
b/target/linux/brcm63xx/patches-3.14/375-GPIO-DT-over-legacy.patch
new file mode 100644
index 000..9c4f6ec
--- /dev/null
+++ b/target/linux/brcm63xx/patches-3.14/375-GPIO-DT-over-legacy.patch
@@ -0,0 +1,93 @@
+--- a/arch/mips/bcm63xx/boards/board_common.c
b/arch/mips/bcm63xx/boards/board_common.c
+@@ -191,8 +191,6 @@ static struct of_device_id of_ids[] = {
+ */
+ int __init board_register_devices(void)
+ {
+- int button_count = 0;
+- int led_count = 0;
+ int usbh_ports = 0;
+
+ #if CONFIG_OF
+@@ -204,6 +202,10 @@ int __init board_register_devices(void)
+ }
+ #endif
+
++ if (!board_of_device_present(gpio0)) {
++ bcm63xx_gpio_init();
++ }
++
+ if (board.has_uart0)
+ bcm63xx_uart_register(0);
+
+@@ -265,30 +267,35 @@ int __init board_register_devices(void)
+
+ bcm63xx_flash_register();
+
+- /* count number of LEDs defined by this device */
+- while (led_count ARRAY_SIZE(board.leds)
board.leds[led_count].name)
+- led_count++;
+-
+- if (led_count) {
+- bcm63xx_led_data.num_leds = led_count;
+- bcm63xx_led_data.leds = board.leds;
+-
+- platform_device_register(bcm63xx_gpio_leds);
+- }
+-
+- if (board.ephy_reset_gpio board.ephy_reset_gpio_flags)
+- gpio_request_one(board.ephy_reset_gpio,
+- board.ephy_reset_gpio_flags, ephy-reset);
+-
+- /* count number of BUTTONs defined by this device */
+- while (button_count ARRAY_SIZE(board.buttons)
board.buttons[button_count].desc)
+- button_count++;
+-
+- if (button_count) {
+- bcm63xx_gpio_keys_data.nbuttons = button_count;
+- bcm63xx_gpio_keys_data.buttons = board.buttons;
To keep the changes minimal, how about just
- if (button_count) {
+ if (button_count !board_of_device_present(gpio0)) {
Same for the leds.
Jonas
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/3] brcm63xx: add bcm6345-gpio driver
On Fri, Dec 12, 2014 at 3:17 PM, John Crispin blo...@openwrt.org wrote:
On 12/12/2014 15:12, Jonas Gorski wrote:
or the gpio-base problem, we should be able to register appropriate
platform data for it as OF_DEV_AUXDATA() in of_platform_populate.
e.g.
struct bgpio_pdata gpio0_pdata = {
.base = 0,
};
struct bgpio_pdata gpio1_pdata = {
.base = 32,
};
tried it for ralink and lantiq and it got nak'ed by LinusW
i keep that part of the code as a small patch inside owrt on top of the
stuff i sent upstream.
Wasn't the objection on putting the gpio base into the dts(i) file
itself? I explicitly try to avoid that here, as gpio-base is something
linux internal.
But It doesn't matter much for now as not even basic DT support is
upstream, so these won't go anywhere soon.
Jonas
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/3] brcm63xx: add bcm6345-gpio driver
On 12/12/2014 15:33, Jonas Gorski wrote:
On Fri, Dec 12, 2014 at 3:17 PM, John Crispin blo...@openwrt.org wrote:
On 12/12/2014 15:12, Jonas Gorski wrote:
or the gpio-base problem, we should be able to register appropriate
platform data for it as OF_DEV_AUXDATA() in of_platform_populate.
e.g.
struct bgpio_pdata gpio0_pdata = {
.base = 0,
};
struct bgpio_pdata gpio1_pdata = {
.base = 32,
};
tried it for ralink and lantiq and it got nak'ed by LinusW
i keep that part of the code as a small patch inside owrt on top of the
stuff i sent upstream.
Wasn't the objection on putting the gpio base into the dts(i) file
itself? I explicitly try to avoid that here, as gpio-base is something
linux internal.
i think it was in general but might be wrong i'll dig into my mails
when i go on the next kernel spree
But It doesn't matter much for now as not even basic DT support is
upstream, so these won't go anywhere soon.
Jonas
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] RT5350 UART not working.
Hi Luis,
i just added a fix to my local tree and will push during the evening.
it fixes the duplicate uartf pinmux problem. please note that when
enabling uart the uartlite used for tty0 gets moved to tty1 so you need
to fix up the cmdline
John
On 02/12/2014 01:50, Luis Soltero wrote:
Hello All,
it seems that I am not the only one having this issue.
https://dev.openwrt.org/ticket/14211
https://dev.openwrt.org/ticket/16831
any thoughts on how to resolve the UARTF issue on the 5350 is greatly
appreciated.
thanks,
--luis
On 12/1/14 3:49 PM, Luis Soltero wrote:
sorry... i sent the docs for the AWM003 not the AWM002...
On 12/1/14 3:43 PM, Luis Soltero wrote:
Hello John,
this is the AWM002 module...
http://www.asiarf.com/Smallest-Tiny-Ralink-802-11n-Wireless-AP-Router-Module-Board-AWM002-product-view-375.html
with the corresponding AsiaRF IO/Dev/Eval board. Here is pin sharing
scheme for the board. I have attached the docs
RTS I2S_CLK GPIO #7 1 2 GPIO #11 PCM_FS DTR
TXD I2S_WS GPIO #8 3 4 GPIO #12 PCM_CLK DCD
CTS I2S_SDO GPIO #9 5 6 GPIO #13 PCM_DRX DSR
RXD I2S_SDI GPIO #10 7 8 GPIO #14 PCM_DTX RI
I2C_CLK GPIO #2 9 10 GPIO #1 I2C_SD
RX1+ 11 12 TX1+
RX1- 13 14 TX1-
GND 15 16 GND
--luis
On 12/1/14 3:24 PM, John Crispin wrote:
ermmm ... i booted rt5350 on the weekend with uccess .. but that has
nothing to say. which boar is this ? i assume the small asiarf one ?
On 01/12/2014 13:40, Luis Soltero wrote:
anyone have any ideas on how to get the RT5350 UART working?
here is the error in the log.
[0.46] pinctrl core: add 1 pinmux maps
[0.46] rt2880-pinmux pinctrl.1: found group selector 2 for
uartf
[0.46] rt2880-pinmux pinctrl.1: request pin 7 (io7) for
1500.uart
[0.46] rt2880-pinmux pinctrl.1: pin io7 already requested by
pinctrl.1; cannot claim for 1500.uart
[0.48] rt2880-pinmux pinctrl.1: pin-7 (1500.uart)
status -22
[0.48] rt2880-pinmux pinctrl.1: could not request pin 7 (io7)
from group uartf on device rt2880-pinmux
[0.51] of_serial 1500.uart: Error applying setting,
reverse
things back
[0.53] 1500.uart: ttyS1 at MMIO 0x1500 (irq = 13,
base_baud = 250) is a 16550A
here is the DTS config for the uart.
palmbus@1000 {
uart@500 {
status = okay;
};
i2c@900 {
status = okay;
};
gpio0: gpio@600 {
status = okay;
};
gpio1: gpio@660 {
status = okay;
};
};
pinctrl {
state_default: pinctrl0 {
gpio {
ralink,group = i2c, jtag;
ralink,function = gpio;
};
uartf {
ralink,group = uartf;
ralink,function = uartf;
};
};
};
Any info/hints on this are greatly appreciated.
Thanks,
--luis
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ar71xx: add support for qca956x soc
This patch adds soc support for QCA9561 and TP9343.
TP9343 is a reduced version of QCA9561, which can be found in TP-LINK routers
in China.
The qca956x_wmac has not yet been supported by ath9k.
tested on TL-WDR6500 and TL-WR882N v1 (Chinese version)
Signed-off-by: Weijie Gao hackpas...@gmail.com
---
target/linux/ar71xx/config-3.14| 1 +
...34-MIPS-ath79-add-support-for-QCA956x-SoC.patch | 767 +
2 files changed, 768 insertions(+)
create mode 100644
target/linux/ar71xx/patches-3.14/734-MIPS-ath79-add-support-for-QCA956x-SoC.patch
diff --git a/target/linux/ar71xx/config-3.14 b/target/linux/ar71xx/config-3.14
index 9ed184b..9f222c7 100644
--- a/target/linux/ar71xx/config-3.14
+++ b/target/linux/ar71xx/config-3.14
@@ -291,6 +291,7 @@ CONFIG_SOC_AR933X=y
CONFIG_SOC_AR934X=y
CONFIG_SOC_QCA953X=y
CONFIG_SOC_QCA955X=y
+CONFIG_SOC_QCA956X=y
CONFIG_SPI=y
CONFIG_SPI_AP83=y
CONFIG_SPI_ATH79=y
diff --git
a/target/linux/ar71xx/patches-3.14/734-MIPS-ath79-add-support-for-QCA956x-SoC.patch
b/target/linux/ar71xx/patches-3.14/734-MIPS-ath79-add-support-for-QCA956x-SoC.patch
new file mode 100644
index 000..6bbc43b
--- /dev/null
+++
b/target/linux/ar71xx/patches-3.14/734-MIPS-ath79-add-support-for-QCA956x-SoC.patch
@@ -0,0 +1,767 @@
+--- a/arch/mips/ath79/clock.c
b/arch/mips/ath79/clock.c
+@@ -520,6 +520,100 @@
+ clk_add_alias(uart, NULL, ref, NULL);
+ }
+
++static void __init qca956x_clocks_init(void)
++{
++ unsigned long ref_rate;
++ unsigned long cpu_rate;
++ unsigned long ddr_rate;
++ unsigned long ahb_rate;
++ u32 pll, out_div, ref_div, nint, hfrac, lfrac, clk_ctrl, postdiv;
++ u32 cpu_pll, ddr_pll;
++ u32 bootstrap;
++
++ bootstrap = ath79_reset_rr(QCA956X_RESET_REG_BOOTSTRAP);
++ if (bootstrap QCA956X_BOOTSTRAP_REF_CLK_40)
++ ref_rate = 40 * 1000 * 1000;
++ else
++ ref_rate = 25 * 1000 * 1000;
++
++ pll = ath79_pll_rr(QCA956X_PLL_CPU_CONFIG_REG);
++ out_div = (pll QCA956X_PLL_CPU_CONFIG_OUTDIV_SHIFT)
++QCA956X_PLL_CPU_CONFIG_OUTDIV_MASK;
++ ref_div = (pll QCA956X_PLL_CPU_CONFIG_REFDIV_SHIFT)
++QCA956X_PLL_CPU_CONFIG_REFDIV_MASK;
++
++ pll = ath79_pll_rr(QCA956X_PLL_CPU_CONFIG1_REG);
++ nint = (pll QCA956X_PLL_CPU_CONFIG1_NINT_SHIFT)
++ QCA956X_PLL_CPU_CONFIG1_NINT_MASK;
++ hfrac = (pll QCA956X_PLL_CPU_CONFIG1_NFRAC_H_SHIFT)
++ QCA956X_PLL_CPU_CONFIG1_NFRAC_H_MASK;
++ lfrac = (pll QCA956X_PLL_CPU_CONFIG1_NFRAC_L_SHIFT)
++ QCA956X_PLL_CPU_CONFIG1_NFRAC_L_MASK;
++
++ cpu_pll = nint * ref_rate / ref_div;
++ cpu_pll += (lfrac * ref_rate) / ((ref_div * 25) 13);
++ cpu_pll += (hfrac 13) * ref_rate / ref_div;
++ cpu_pll /= (1 out_div);
++
++ pll = ath79_pll_rr(QCA956X_PLL_DDR_CONFIG_REG);
++ out_div = (pll QCA956X_PLL_DDR_CONFIG_OUTDIV_SHIFT)
++QCA956X_PLL_DDR_CONFIG_OUTDIV_MASK;
++ ref_div = (pll QCA956X_PLL_DDR_CONFIG_REFDIV_SHIFT)
++QCA956X_PLL_DDR_CONFIG_REFDIV_MASK;
++ pll = ath79_pll_rr(QCA956X_PLL_DDR_CONFIG1_REG);
++ nint = (pll QCA956X_PLL_DDR_CONFIG1_NINT_SHIFT)
++ QCA956X_PLL_DDR_CONFIG1_NINT_MASK;
++ hfrac = (pll QCA956X_PLL_DDR_CONFIG1_NFRAC_H_SHIFT)
++ QCA956X_PLL_DDR_CONFIG1_NFRAC_H_MASK;
++ lfrac = (pll QCA956X_PLL_DDR_CONFIG1_NFRAC_L_SHIFT)
++ QCA956X_PLL_DDR_CONFIG1_NFRAC_L_MASK;
++
++ ddr_pll = nint * ref_rate / ref_div;
++ ddr_pll += (lfrac * ref_rate) / ((ref_div * 25) 13);
++ ddr_pll += (hfrac 13) * ref_rate / ref_div;
++ ddr_pll /= (1 out_div);
++
++ clk_ctrl = ath79_pll_rr(QCA956X_PLL_CLK_CTRL_REG);
++
++ postdiv = (clk_ctrl QCA956X_PLL_CLK_CTRL_CPU_POST_DIV_SHIFT)
++QCA956X_PLL_CLK_CTRL_CPU_POST_DIV_MASK;
++
++ if (clk_ctrl QCA956X_PLL_CLK_CTRL_CPU_PLL_BYPASS)
++ cpu_rate = ref_rate;
++ else if (clk_ctrl QCA956X_PLL_CLK_CTRL_CPU_DDRCLK_FROM_CPUPLL)
++ cpu_rate = ddr_pll / (postdiv + 1);
++ else
++ cpu_rate = cpu_pll / (postdiv + 1);
++
++ postdiv = (clk_ctrl QCA956X_PLL_CLK_CTRL_DDR_POST_DIV_SHIFT)
++QCA956X_PLL_CLK_CTRL_DDR_POST_DIV_MASK;
++
++ if (clk_ctrl QCA956X_PLL_CLK_CTRL_DDR_PLL_BYPASS)
++ ddr_rate = ref_rate;
++ else if (clk_ctrl QCA956X_PLL_CLK_CTRL_CPU_DDRCLK_FROM_DDRPLL)
++ ddr_rate = cpu_pll / (postdiv + 1);
++ else
++ ddr_rate = ddr_pll / (postdiv + 1);
++
++ postdiv = (clk_ctrl QCA956X_PLL_CLK_CTRL_AHB_POST_DIV_SHIFT)
++QCA956X_PLL_CLK_CTRL_AHB_POST_DIV_MASK;
++
++ if (clk_ctrl QCA956X_PLL_CLK_CTRL_AHB_PLL_BYPASS)
++ ahb_rate = ref_rate;
++ else if (clk_ctrl QCA956X_PLL_CLK_CTRL_AHBCLK_FROM_DDRPLL)
++ ahb_rate = ddr_pll / (postdiv + 1);
++ else
[OpenWrt-Devel] [PATCH RFC 1/5] mvebu: Replace the padjffs2 call by the generic definition
The mvebu image Makefile directly calls the padjffs2 utility, while there's an generic make function to do just that. Switch to it Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com --- target/linux/mvebu/image/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/mvebu/image/Makefile b/target/linux/mvebu/image/Makefile index 9d3b6353a67a..0de7328515ca 100644 --- a/target/linux/mvebu/image/Makefile +++ b/target/linux/mvebu/image/Makefile @@ -42,7 +42,7 @@ define Image/BuildKernel endef define Image/Build/squashfs - $(STAGING_DIR_HOST)/bin/padjffs2 $(KDIR)/root.squashfs 128 + $(call prepare_generic_squashfs,$(KDIR)/root.squashfs) $(foreach dtb,$(TARGET_DTBS),$(call Image/Build/UbinizeImage,$(dtb),,squashfs,$(UBI_OPTS));) ( \ dd if=$(KDIR)/uImage-armada-xp-mamba bs=3072k conv=sync; \ -- 2.2.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH RFC 2/5] ubinize-image: Change the rootfs to a static volume
On boards with large page size, the rootfs we generate might end up using less
PEB than the minimum number required by UBI for a dynamic volume.
Change the rootfs to a static volume, which removes such a requirement, and
isn't changing anything, since our rootfs is in read only anyway.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
---
scripts/ubinize-image.sh | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/scripts/ubinize-image.sh b/scripts/ubinize-image.sh
index 6762c22bc4a6..11c25ecc8ee1 100755
--- a/scripts/ubinize-image.sh
+++ b/scripts/ubinize-image.sh
@@ -25,13 +25,17 @@ ubivol() {
echo [$name]
echo mode=ubi
echo vol_id=$volid
- echo vol_type=dynamic
echo vol_name=$name
if [ $image ]; then
echo image=$image
else
echo vol_size=1MiB
fi
+ if [ $name = rootfs ]; then
+ echo vol_type=static
+ else
+ echo vol_type=dynamic
+ fi
if [ $autoresize ]; then
echo vol_flags=autoresize
fi
--
2.2.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH RFC 4/5] target: mvebu: Add a generic board
Create a generic board relying on the board mechanism we just introduced. So far, the behaviour hasn't really changed, the same boards are supported, with the same options. Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com --- target/linux/mvebu/boards/generic.mk | 18 ++ target/linux/mvebu/image/Makefile| 32 +--- 2 files changed, 39 insertions(+), 11 deletions(-) create mode 100644 target/linux/mvebu/boards/generic.mk diff --git a/target/linux/mvebu/boards/generic.mk b/target/linux/mvebu/boards/generic.mk new file mode 100644 index ..e4ac20ecf473 --- /dev/null +++ b/target/linux/mvebu/boards/generic.mk @@ -0,0 +1,18 @@ +# +# Copyright (C) 2014 Maxime Ripard +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# + +GENERIC_UBI_OPTS = -m 2048 -p 128KiB -s 512 -O 2048 +GENERIC_DTB = \ + armada-370-db \ + armada-370-mirabox \ + armada-370-rd \ + armada-xp-db \ + armada-xp-gp \ + armada-xp-mamba \ + armada-xp-openblocks-ax3-4 + +$(eval $(call Board,GENERIC)) diff --git a/target/linux/mvebu/image/Makefile b/target/linux/mvebu/image/Makefile index 0de7328515ca..d419d639cdf2 100644 --- a/target/linux/mvebu/image/Makefile +++ b/target/linux/mvebu/image/Makefile @@ -7,19 +7,12 @@ include $(TOPDIR)/rules.mk include $(INCLUDE_DIR)/image.mk -TARGET_DTBS := armada-xp-db armada-370-db armada-xp-openblocks-ax3-4 armada-370-mirabox \ - armada-370-rd armada-xp-gp armada-xp-mamba - LOADADDR:=0x8000 JFFS2_BLOCKSIZE = 128k -UBIFS_OPTS = -F -m 2048 -e 124KiB -c 4096 -U -UBI_OPTS = -m 2048 -p 128KiB -s 512 -O 2048 - KDIR_TMP:=$(KDIR)/tmp - UIMAGE:=$(BIN_DIR)/$(IMG_PREFIX)-uImage define Image/Build/MkuImage @@ -35,7 +28,11 @@ define Image/Build/DTB endef define Image/BuildKernel - $(foreach dtb,$(TARGET_DTBS),$(call Image/Build/DTB,$(dtb))) + $(foreach board, \ + $(TARGET_BOARDS), \ + $(foreach dtb, \ + $($(board)_DTB), \ + $(call Image/Build/DTB,$(dtb ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),) $(call Image/Build/Initramfs) endif @@ -43,7 +40,12 @@ endef define Image/Build/squashfs $(call prepare_generic_squashfs,$(KDIR)/root.squashfs) - $(foreach dtb,$(TARGET_DTBS),$(call Image/Build/UbinizeImage,$(dtb),,squashfs,$(UBI_OPTS));) + $(foreach board, \ + $(TARGET_BOARDS), \ + $(foreach dtb, \ + $($(board)_DTB), \ + $(call Image/Build/UbinizeImage,$(dtb),,squashfs, \ + $($(board)_UBI_OPTS));)) ( \ dd if=$(KDIR)/uImage-armada-xp-mamba bs=3072k conv=sync; \ dd if=$(BIN_DIR)/$(IMG_PREFIX)-armada-xp-mamba-squashfs-ubinized.bin \ @@ -52,7 +54,11 @@ define Image/Build/squashfs endef define Image/Build/Initramfs - $(foreach dtb,$(TARGET_DTBS),$(call Image/Build/DTB,$(dtb),-initramfs)) + $(foreach board, \ + $(TARGET_BOARDS), \ + $(foreach dtb, \ + $($(board)_DTB), \ + $(call Image/Build/DTB,$(dtb),-initramfs))) endef define BuildSysupgrade @@ -62,7 +68,11 @@ endef define Image/Build $(call Image/Build/$(1)) dd if=$(KDIR)/root.$(1) of=$(BIN_DIR)/$(IMG_PREFIX)-root.$(1) bs=128k conv=sync - $(foreach dtb,$(TARGET_DTBS),$(call BuildSysupgrade,$(1),$(dtb));) + $(foreach board, \ + $(TARGET_BOARDS), \ + $(foreach dtb, \ + $($(board)_DTB), \ + $(call BuildSysupgrade,$(1),$(dtb));)) ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),) $(call Image/Build/Initramfs) endif -- 2.2.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH RFC 3/5] target: Add board notion support
Even though we always build all the board images for a given target, some options widely differ from one board to another when it comes to hardware configuration. Such an option for example is the NAND setup, which depends on the NAND chip itself, that obviously varies from one board to another. This kind of options used to be declared either globally for one platform, which would enforce a fragile default, or through alternate profiles, that would result in an unusable image that would still be compiled if we chose the wrong one. Introduce a new notion of boards, that would be defined in the $(PLATFORM_DIR)/boards directory, to set up this kind of board specific options, that we always want to be in-use, no matter what profile is used. Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com --- include/target.mk | 12 1 file changed, 12 insertions(+) diff --git a/include/target.mk b/include/target.mk index db501e06c760..b6d1c9fde9bf 100644 --- a/include/target.mk +++ b/include/target.mk @@ -87,6 +87,12 @@ define Profile endef endif +ifndef Board +define Board + TARGET_BOARDS += $(1) +endef +endif + ifneq ($(PLATFORM_DIR),$(PLATFORM_SUBDIR)) define IncludeProfiles -include $(sort $(wildcard $(PLATFORM_DIR)/profiles/*.mk)) @@ -98,11 +104,17 @@ else endef endif +define IncludeBoards + -include $(sort $(wildcard $(PLATFORM_DIR)/boards/*.mk)) +endef + ifeq ($(TARGET_BUILD),1) $(eval $(call IncludeProfiles)) + $(eval $(call IncludeBoards)) else ifeq ($(DUMP),) $(eval $(call IncludeProfiles)) +$(eval $(call IncludeBoards)) endif endif -- 2.2.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH RFC 5/5] target: mvebu: Add a new board for the Mirabox
The Mirabox has different NAND options than the one used in the generic board, mostly because of its 512k page size. Add a new board for it. Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com --- target/linux/mvebu/boards/generic.mk | 1 - target/linux/mvebu/boards/mirabox.mk | 13 + 2 files changed, 13 insertions(+), 1 deletion(-) create mode 100644 target/linux/mvebu/boards/mirabox.mk diff --git a/target/linux/mvebu/boards/generic.mk b/target/linux/mvebu/boards/generic.mk index e4ac20ecf473..3ec74c877d30 100644 --- a/target/linux/mvebu/boards/generic.mk +++ b/target/linux/mvebu/boards/generic.mk @@ -8,7 +8,6 @@ GENERIC_UBI_OPTS = -m 2048 -p 128KiB -s 512 -O 2048 GENERIC_DTB = \ armada-370-db \ - armada-370-mirabox \ armada-370-rd \ armada-xp-db \ armada-xp-gp \ diff --git a/target/linux/mvebu/boards/mirabox.mk b/target/linux/mvebu/boards/mirabox.mk new file mode 100644 index ..23b5bde78bc1 --- /dev/null +++ b/target/linux/mvebu/boards/mirabox.mk @@ -0,0 +1,13 @@ +# +# Copyright (C) 2014 Maxime Ripard +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# + +MIRABOX_UBI_OPTS = -m 4096 -p 512KiB -O 4096 + +MIRABOX_DTB = \ + armada-370-mirabox + +$(eval $(call Board, MIRABOX)) -- 2.2.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/2] kernel/generic: add ledtrig support to libata
This adds a LED trigger for each SATA port if the kernel config option
CONFIG_ATA_LEDS is set.
In order not to cause any oldconfig confusion on targets, the option depends
on CONFIG_ARCH_WANTS_LIBATA_LEDS, so target maintainers have to opt-in in
order to use this (it could e.g. be useful on kirkwood, orion, ...)
Signed-off-by: Daniel Golle dan...@makrotopia.org
---
.../generic/patches-3.14/834-ledtrig-libata.patch | 147 +
.../generic/patches-3.18/834-ledtrig-libata.patch | 147 +
2 files changed, 294 insertions(+)
create mode 100644 target/linux/generic/patches-3.14/834-ledtrig-libata.patch
create mode 100644 target/linux/generic/patches-3.18/834-ledtrig-libata.patch
diff --git a/target/linux/generic/patches-3.14/834-ledtrig-libata.patch
b/target/linux/generic/patches-3.14/834-ledtrig-libata.patch
new file mode 100644
index 000..a09cb0a
--- /dev/null
+++ b/target/linux/generic/patches-3.14/834-ledtrig-libata.patch
@@ -0,0 +1,147 @@
+From c187610266765d05975a1d44cb3f6f0b81fee324 Mon Sep 17 00:00:00 2001
+From: Daniel Golle dan...@makrotopia.org
+Date: Fri, 12 Dec 2014 13:38:33 +0100
+Subject: [PATCH] libata: add ledtrig support
+
+Signed-off-by: Daniel Golle dan...@makrotopia.org
+---
+ drivers/ata/Kconfig | 15 +++
+ drivers/ata/libata-core.c | 39 +++
+ include/linux/libata.h| 9 +
+ 3 files changed, 63 insertions(+)
+
+diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
+index cd4cccb..3a92107 100644
+--- a/drivers/ata/Kconfig
b/drivers/ata/Kconfig
+@@ -46,6 +46,21 @@ config ATA_VERBOSE_ERROR
+
+ If unsure, say Y.
+
++config ARCH_WANT_LIBATA_LEDS
++ bool
++
++config ATA_LEDS
++ bool support ATA port LED triggers
++ depends on ARCH_WANT_LIBATA_LEDS
++ select NEW_LEDS
++ select LEDS_CLASS
++ select LEDS_TRIGGERS
++ default y
++ help
++This option adds a LED trigger for each registered ATA port.
++It is used to drive disk activity leds connected via GPIO.
++
++
+ config ATA_ACPI
+ bool ATA ACPI Support
+ depends on ACPI PCI
+diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
+index c5ba15a..bf97099 100644
+--- a/drivers/ata/libata-core.c
b/drivers/ata/libata-core.c
+@@ -725,6 +725,17 @@ u64 ata_tf_read_block(struct ata_taskfile *tf, struct
ata_device *dev)
+ return block;
+ }
+
++#ifdef CONFIG_ATA_LEDS
++#define LIBATA_BLINK_DELAY 20 /* ms */
++static inline void ata_led_act(struct ata_port *ap)
++{
++ unsigned long led_delay = LIBATA_BLINK_DELAY;
++ if (likely(!ap-ledtrig))
++ return;
++ led_trigger_blink_oneshot(ap-ledtrig, led_delay, led_delay, 0);
++}
++#endif
++
+ /**
+ *ata_build_rw_tf - Build ATA taskfile for given read/write request
+ *@tf: Target ATA taskfile
+@@ -4753,6 +4764,9 @@ static struct ata_queued_cmd *ata_qc_new(struct ata_port
*ap)
+ break;
+ }
+ }
++#ifdef CONFIG_ATA_LEDS
++ ata_led_act(ap);
++#endif
+
+ return qc;
+ }
+@@ -5663,6 +5677,9 @@ struct ata_port *ata_port_alloc(struct ata_host *host)
+ ap-stats.unhandled_irq = 1;
+ ap-stats.idle_irq = 1;
+ #endif
++#ifdef CONFIG_ATA_LEDS
++ ap-ledtrig = kzalloc(sizeof(struct led_trigger), GFP_KERNEL);
++#endif
+ ata_sff_port_init(ap);
+
+ return ap;
+@@ -5684,6 +5701,12 @@ static void ata_host_release(struct device *gendev,
void *res)
+
+ kfree(ap-pmp_link);
+ kfree(ap-slave_link);
++#ifdef CONFIG_ATA_LEDS
++ if (ap-ledtrig) {
++ led_trigger_unregister(ap-ledtrig);
++ kfree(ap-ledtrig);
++ };
++#endif
+ kfree(ap);
+ host-ports[i] = NULL;
+ }
+@@ -6130,7 +6153,23 @@ int ata_host_register(struct ata_host *host, struct
scsi_host_template *sht)
+ host-ports[i]-print_id = atomic_inc_return(ata_print_id);
+ host-ports[i]-local_port_no = i + 1;
+ }
++#ifdef CONFIG_ATA_LEDS
++ for (i = 0; i host-n_ports; i++) {
++ if (unlikely(!host-ports[i]-ledtrig))
++ continue;
++
++ snprintf(host-ports[i]-ledtrig_name,
++ sizeof(host-ports[i]-ledtrig_name), ata%u,
++ host-ports[i]-print_id);
++
++ host-ports[i]-ledtrig-name = host-ports[i]-ledtrig_name;
+
++ if (led_trigger_register(host-ports[i]-ledtrig)) {
++ kfree(host-ports[i]-ledtrig);
++ host-ports[i]-ledtrig = NULL;
++ }
++ }
++#endif
+ /* Create associated sysfs transport objects */
+ for (i = 0; i host-n_ports; i++) {
+ rc = ata_tport_add(host-dev,host-ports[i]);
+diff --git a/include/linux/libata.h b/include/linux/libata.h
+index bd5fefe..9848876 100644
+---
[OpenWrt-Devel] [PATCH 2/2] oxnas: use libata ledtrig support for kd20 hdd leds
Signed-off-by: Daniel Golle dan...@makrotopia.org
---
target/linux/oxnas/config-3.14| 1 +
target/linux/oxnas/config-3.18| 1 +
target/linux/oxnas/files/arch/arm/boot/dts/ox820-kd20.dts | 2 ++
target/linux/oxnas/files/arch/arm/mach-oxnas/Kconfig | 1 +
4 files changed, 5 insertions(+)
diff --git a/target/linux/oxnas/config-3.14 b/target/linux/oxnas/config-3.14
index 473a2bf..a065363 100644
--- a/target/linux/oxnas/config-3.14
+++ b/target/linux/oxnas/config-3.14
@@ -345,3 +345,4 @@ CONFIG_ZBOOT_ROM_TEXT=0
CONFIG_ZLIB_DEFLATE=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZONE_DMA_FLAG=0
+CONFIG_ATA_LEDS=y
diff --git a/target/linux/oxnas/config-3.18 b/target/linux/oxnas/config-3.18
index 56dce65..b9172d9 100644
--- a/target/linux/oxnas/config-3.18
+++ b/target/linux/oxnas/config-3.18
@@ -364,3 +364,4 @@ CONFIG_ZBOOT_ROM_TEXT=0
CONFIG_ZLIB_DEFLATE=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZONE_DMA_FLAG=0
+CONFIG_ATA_LEDS=y
diff --git a/target/linux/oxnas/files/arch/arm/boot/dts/ox820-kd20.dts
b/target/linux/oxnas/files/arch/arm/boot/dts/ox820-kd20.dts
index 2db15ea..79442be 100644
--- a/target/linux/oxnas/files/arch/arm/boot/dts/ox820-kd20.dts
+++ b/target/linux/oxnas/files/arch/arm/boot/dts/ox820-kd20.dts
@@ -107,6 +107,7 @@
hdd1blue {
label = kd20:blue:hdd1;
gpios = GPIOA 27 0;
+ linux,default-trigger = ata1;
};
hdd1red {
label = kd20:red:hdd1;
@@ -115,6 +116,7 @@
hdd2blue {
label = kd20:blue:hdd2;
gpios = GPIOB 6 0;
+ linux,default-trigger = ata2;
};
hdd2red {
label = kd20:red:hdd2;
diff --git a/target/linux/oxnas/files/arch/arm/mach-oxnas/Kconfig
b/target/linux/oxnas/files/arch/arm/mach-oxnas/Kconfig
index eb96f1b..6bdf3f6 100644
--- a/target/linux/oxnas/files/arch/arm/mach-oxnas/Kconfig
+++ b/target/linux/oxnas/files/arch/arm/mach-oxnas/Kconfig
@@ -18,6 +18,7 @@ config MACH_OX820
select PINCTRL_OXNAS
select PINCTRL
select RESET_CONTROLLER_OXNAS
+ select ARCH_WANT_LIBATA_LEDS
help
Include support for the ox820 platform.
--
2.1.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] kernel/generic: add ledtrig support to libata
... and i assume this is already en-route to upstream ?
On 12/12/2014 17:07, Daniel Golle wrote:
This adds a LED trigger for each SATA port if the kernel config
option CONFIG_ATA_LEDS is set. In order not to cause any oldconfig
confusion on targets, the option depends on
CONFIG_ARCH_WANTS_LIBATA_LEDS, so target maintainers have to opt-in
in order to use this (it could e.g. be useful on kirkwood, orion,
...)
Signed-off-by: Daniel Golle dan...@makrotopia.org
--- .../generic/patches-3.14/834-ledtrig-libata.patch | 147
+
.../generic/patches-3.18/834-ledtrig-libata.patch | 147
+ 2 files changed, 294 insertions(+) create
mode 100644
target/linux/generic/patches-3.14/834-ledtrig-libata.patch create
mode 100644
target/linux/generic/patches-3.18/834-ledtrig-libata.patch
diff --git
a/target/linux/generic/patches-3.14/834-ledtrig-libata.patch
b/target/linux/generic/patches-3.14/834-ledtrig-libata.patch new
file mode 100644 index 000..a09cb0a --- /dev/null +++
b/target/linux/generic/patches-3.14/834-ledtrig-libata.patch @@
-0,0 +1,147 @@ +From c187610266765d05975a1d44cb3f6f0b81fee324 Mon
Sep 17 00:00:00 2001 +From: Daniel Golle dan...@makrotopia.org
+Date: Fri, 12 Dec 2014 13:38:33 +0100 +Subject: [PATCH] libata:
add ledtrig support + +Signed-off-by: Daniel Golle
dan...@makrotopia.org +--- + drivers/ata/Kconfig | 15
+++ + drivers/ata/libata-core.c | 39
+++ + include/linux/libata.h
| 9 + + 3 files changed, 63 insertions(+) + +diff --git
a/drivers/ata/Kconfig b/drivers/ata/Kconfig +index cd4cccb..3a92107
100644 +--- a/drivers/ata/Kconfig b/drivers/ata/Kconfig +@@
-46,6 +46,21 @@ config ATA_VERBOSE_ERROR + +If unsure, say Y. +
++config ARCH_WANT_LIBATA_LEDS ++bool ++ ++config ATA_LEDS ++
bool support ATA port LED triggers ++ depends on
ARCH_WANT_LIBATA_LEDS ++ select NEW_LEDS ++ select LEDS_CLASS ++
select LEDS_TRIGGERS ++ default y ++help ++ This option adds a
LED trigger for each registered ATA port. ++It is used to drive
disk activity leds connected via GPIO. ++ ++ + config ATA_ACPI +
bool ATA ACPI Support + depends on ACPI PCI +diff --git
a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c +index
c5ba15a..bf97099 100644 +--- a/drivers/ata/libata-core.c
b/drivers/ata/libata-core.c +@@ -725,6 +725,17 @@ u64
ata_tf_read_block(struct ata_taskfile *tf, struct ata_device *dev)
+ return block; + } + ++#ifdef CONFIG_ATA_LEDS ++#define
LIBATA_BLINK_DELAY 20 /* ms */ ++static inline void
ata_led_act(struct ata_port *ap) ++{ ++ unsigned long led_delay =
LIBATA_BLINK_DELAY; ++if (likely(!ap-ledtrig)) ++return;
++
led_trigger_blink_oneshot(ap-ledtrig, led_delay, led_delay, 0);
++} ++#endif ++ + /** + *ata_build_rw_tf - Build ATA taskfile for
given read/write request + * @tf: Target ATA taskfile +@@ -4753,6
+4764,9 @@ static struct ata_queued_cmd *ata_qc_new(struct ata_port
*ap) +break; +} + } ++#ifdef
CONFIG_ATA_LEDS ++
ata_led_act(ap); ++#endif + + return qc; + } +@@ -5663,6 +5677,9
@@ struct ata_port *ata_port_alloc(struct ata_host *host) +
ap-stats.unhandled_irq = 1; +ap-stats.idle_irq = 1; + #endif
++#ifdef CONFIG_ATA_LEDS ++ ap-ledtrig = kzalloc(sizeof(struct
led_trigger), GFP_KERNEL); ++#endif + ata_sff_port_init(ap); + +
return ap; +@@ -5684,6 +5701,12 @@ static void
ata_host_release(struct device *gendev, void *res) + +
kfree(ap-pmp_link); +kfree(ap-slave_link); ++#ifdef
CONFIG_ATA_LEDS ++if (ap-ledtrig) { ++
led_trigger_unregister(ap-ledtrig); ++
kfree(ap-ledtrig); ++
}; ++#endif + kfree(ap); +host-ports[i] = NULL;
+} +@@
-6130,7 +6153,23 @@ int ata_host_register(struct ata_host *host,
struct scsi_host_template *sht) + host-ports[i]-print_id =
atomic_inc_return(ata_print_id); + host-ports[i]-local_port_no
= i + 1; +} ++#ifdef CONFIG_ATA_LEDS ++ for (i = 0; i
host-n_ports; i++) { ++ if (unlikely(!host-ports[i]-ledtrig))
++continue; ++ ++
snprintf(host-ports[i]-ledtrig_name, ++
sizeof(host-ports[i]-ledtrig_name), ata%u, ++
host-ports[i]-print_id); ++ ++ host-ports[i]-ledtrig-name =
host-ports[i]-ledtrig_name; + ++if
(led_trigger_register(host-ports[i]-ledtrig)) { ++
kfree(host-ports[i]-ledtrig); ++host-ports[i]-ledtrig
=
NULL; ++ } ++} ++#endif +/* Create associated sysfs
transport
objects */ + for (i = 0; i host-n_ports; i++) { +
rc =
ata_tport_add(host-dev,host-ports[i]); +diff --git
a/include/linux/libata.h b/include/linux/libata.h +index
bd5fefe..9848876 100644 +--- a/include/linux/libata.h
Re: [OpenWrt-Devel] [PATCH] ar8216: Use IGMP Join and Fast Leave functions
On 2014-12-05 15:36, Cristian Morales Vega wrote: Avoids flooding the network with multicast data. Signed-off-by: Cristian Morales Vega crist...@samknows.com --- Since I guess not all the switches support this... Good idea? Is some OpenWRT package expecting to receive the multicast packages? At the very least you lose the capacity of using iptables to play with the packets. I think this needs to be optional (and preferably disabled by default initially, until it has received more testing). - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] kernel/generic: add ledtrig support to libata
On 12/12/2014 17:07, Daniel Golle wrote: ++#ifdef CONFIG_ATA_LEDS ++ap-ledtrig = kzalloc(sizeof(struct led_trigger), GFP_KERNEL); ++#endif can you change all of these to the new IS_ENABLED() api John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][RESEND] [tools] toolchain: ensure tools are built and staged before preparing toolchain
On 2014-12-09 11:47, John Szakmeister wrote: This fixes an issue where the toolchain/prepare step could run, but some of the necessary host tools might be missing. Signed-off-by: John Szakmeister j...@szakmeister.net --- This is a resend of a patch I sent earlier (https://lists.openwrt.org/pipermail/openwrt-devel/2014-October/028422.html). I didn't receive any feedback, but it has enabled me to build correctly with a parallel build. Makefile | 2 +- toolchain/Makefile | 4 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 91b6946..edb75fd 100644 --- a/Makefile +++ b/Makefile @@ -38,7 +38,7 @@ else include tools/Makefile include toolchain/Makefile -$(toolchain/stamp-install): $(tools/stamp-install) +$(toolchain/stamp-prepare): $(tools/stamp-install) $(target/stamp-compile): $(toolchain/stamp-install) $(tools/stamp-install) $(BUILD_DIR)/.prepared $(package/stamp-compile): $(target/stamp-compile) $(package/stamp-cleanup) $(package/stamp-install): $(package/stamp-compile) diff --git a/toolchain/Makefile b/toolchain/Makefile index 36c6ed3..b260a36 100644 --- a/toolchain/Makefile +++ b/toolchain/Makefile @@ -82,6 +82,10 @@ ifndef DUMP_TARGET_DB $(TOOLCHAIN_DIR)/stamp/.gcc-initial_installed: endif +$(eval $(call stampfile,$(curdir),toolchain,prepare)) $(eval $(call stampfile,$(curdir),toolchain,install,$(TOOLCHAIN_DIR)/stamp/.gcc-initial_installed,,$(TOOLCHAIN_DIR))) + +$($(curdir)/stamp-install): $($(curdir)/stamp-prepare) This doesn't look right to me, I don't think we should add the toolchain/prepare step as an intermediate target for the regular build process. How about just adding this line to Makefile and leaving out the rest: toolchain/prepare: $(tools/stamp-install) - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] uhttpd2: Set HTTPS environment variable
On 2014-12-11 23:36, Dan Staples wrote: Currently, the only way for cgi scripts to determine if the request was made over SSL seems to be to check if the SERVER_PORT environment variable is set to 443, which is less than ideal. This sets the HTTPS environment variable, like the first version of uhttpd. Signed-off-by: Dan Staples danstaples at opentechinstitute.org The patch has been whitespace mangled. Please fix and resend. Thanks, - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v4 1/4] kernel.mk: Refactor LINUX_KARCH affectation
Switch to a dumber implementation that will be easier to maintain in the long run, with only if statements instead of having nested subst calls. Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com --- include/kernel.mk | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/include/kernel.mk b/include/kernel.mk index d2754abe4486..b905cb9e1936 100644 --- a/include/kernel.mk +++ b/include/kernel.mk @@ -64,13 +64,20 @@ endif ifneq (,$(findstring uml,$(BOARD))) LINUX_KARCH=um +else ifneq (,$(findstring $(ARCH), aarch64 aarch64_be)) + LINUX_KARCH := arm64 +else ifneq (,$(findstring $(ARCH), armeb)) + LINUX_KARCH := arm +else ifneq (,$(findstring $(ARCH), mipsel mips64 mips64el)) + LINUX_KARCH := mips +else ifneq (,$(findstring $(ARCH), sh2 sh3 sh4)) + LINUX_KARCH := sh +else ifneq (,$(findstring $(ARCH), i386)) + LINUX_KARCH := x86 else - ifeq (,$(LINUX_KARCH)) -LINUX_KARCH=$(strip $(subst i386,x86,$(subst armeb,arm,$(subst mipsel,mips,$(subst mips64,mips,$(subst mips64el,mips,$(subst sh2,sh,$(subst sh3,sh,$(subst sh4,sh,$(subst aarch64,arm64,$(subst aarch64_be,arm64,$(ARCH - endif + LINUX_KARCH := $(ARCH) endif - define KernelPackage/Defaults FILES:= AUTOLOAD:= -- 2.2.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v4 2/4] kernel.mk: Handle the x86_64 LINUX_KARCH case
x64 is handled by the x86 architecture in Linux, add a case for it in LINUX_KARCH. Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com --- include/kernel.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/kernel.mk b/include/kernel.mk index b905cb9e1936..eeb0c3d2bd8e 100644 --- a/include/kernel.mk +++ b/include/kernel.mk @@ -72,7 +72,7 @@ else ifneq (,$(findstring $(ARCH), mipsel mips64 mips64el)) LINUX_KARCH := mips else ifneq (,$(findstring $(ARCH), sh2 sh3 sh4)) LINUX_KARCH := sh -else ifneq (,$(findstring $(ARCH), i386)) +else ifneq (,$(findstring $(ARCH), i386 x86_64)) LINUX_KARCH := x86 else LINUX_KARCH := $(ARCH) -- 2.2.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v4 0/4] kernel: Switch to the defconfig
Hi, This is the fourth attempt at using the defconfig mechanism for the kernel configuration instead of having full fledged configuration written by hand, and very tedious to maintain. Changes from v3: - Simplify a bit the LINUX_KARCH logic in order to use findstring instead of a long list of if .. else if statements Changes from v2: - Switch to LINUX_KARCH for the kernel arch instead of relying on our own logic Changes from v1: - Add some logic to compute the linux kernel architecture that doesn't always equal to ARCH Maxime Ripard (4): kernel.mk: Refactor LINUX_KARCH affectation kernel.mk: Handle the x86_64 LINUX_KARCH case kernel: Use defconfig instead of full fledged kernel configuration kernel: 3.18: Strip off all the useless options include/kernel-defaults.mk | 24 +- include/kernel.mk| 15 +- target/linux/generic/config-3.18 | 4404 +- 3 files changed, 39 insertions(+), 4404 deletions(-) -- 2.2.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2 1/2] kernel/generic: add ledtrig support to libata
This adds a LED trigger for each SATA port if the kernel config option
CONFIG_ATA_LEDS is set.
In order not to cause any oldconfig confusion on targets, the option depends
on CONFIG_ARCH_WANTS_LIBATA_LEDS, so target maintainers have to opt-in in
order to use this (it could e.g. be useful on kirkwood, orion, ...)
Signed-off-by: Daniel Golle dan...@makrotopia.org
---
.../generic/patches-3.14/834-ledtrig-libata.patch | 160 +
.../generic/patches-3.18/834-ledtrig-libata.patch | 160 +
2 files changed, 320 insertions(+)
create mode 100644 target/linux/generic/patches-3.14/834-ledtrig-libata.patch
create mode 100644 target/linux/generic/patches-3.18/834-ledtrig-libata.patch
diff --git a/target/linux/generic/patches-3.14/834-ledtrig-libata.patch
b/target/linux/generic/patches-3.14/834-ledtrig-libata.patch
new file mode 100644
index 000..b732ed0
--- /dev/null
+++ b/target/linux/generic/patches-3.14/834-ledtrig-libata.patch
@@ -0,0 +1,160 @@
+From a0e0d35a189dadbf61483fd2639f6c729c6a0135 Mon Sep 17 00:00:00 2001
+From: Daniel Golle dan...@makrotopia.org
+Date: Fri, 12 Dec 2014 13:38:33 +0100
+Subject: [PATCH] libata: add ledtrig support
+To: linux-...@vger.kernel.org,
+Tejun Heo t...@kernel.org
+
+This adds a LED trigger for each ATA port indicating disk activity.
+
+As this is needed only on specific platforms (NAS SoCs and such),
+these platforms should define ARCH_WANTS_LIBATA_LEDS if there
+are boards with LED(s) intended to indicate ATA disk activity and
+need the OS to take care of that.
+In that way, if not selected, LED trigger support not will be
+included in libata-core and both, codepaths and structures remain
+untouched.
+
+Signed-off-by: Daniel Golle dan...@makrotopia.org
+---
+ drivers/ata/Kconfig | 15 +++
+ drivers/ata/libata-core.c | 40
+ include/linux/libata.h| 9 +
+ 3 files changed, 64 insertions(+)
+
+diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
+index cd4cccb..3a92107 100644
+--- a/drivers/ata/Kconfig
b/drivers/ata/Kconfig
+@@ -46,6 +46,21 @@ config ATA_VERBOSE_ERROR
+
+ If unsure, say Y.
+
++config ARCH_WANT_LIBATA_LEDS
++ bool
++
++config ATA_LEDS
++ bool support ATA port LED triggers
++ depends on ARCH_WANT_LIBATA_LEDS
++ select NEW_LEDS
++ select LEDS_CLASS
++ select LEDS_TRIGGERS
++ default y
++ help
++This option adds a LED trigger for each registered ATA port.
++It is used to drive disk activity leds connected via GPIO.
++
++
+ config ATA_ACPI
+ bool ATA ACPI Support
+ depends on ACPI PCI
+diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
+index 5c84fb5..4d5ec5a 100644
+--- a/drivers/ata/libata-core.c
b/drivers/ata/libata-core.c
+@@ -725,6 +725,18 @@ u64 ata_tf_read_block(struct ata_taskfile *tf, struct
ata_device *dev)
+ return block;
+ }
+
++#if IS_ENABLED(CONFIG_ATA_LEDS)
++#define LIBATA_BLINK_DELAY 20 /* ms */
++static inline void ata_led_act(struct ata_port *ap)
++{
++ unsigned long led_delay = LIBATA_BLINK_DELAY;
++
++ if (likely(!ap-ledtrig))
++ return;
++ led_trigger_blink_oneshot(ap-ledtrig, led_delay, led_delay, 0);
++}
++#endif
++
+ /**
+ *ata_build_rw_tf - Build ATA taskfile for given read/write request
+ *@tf: Target ATA taskfile
+@@ -4761,6 +4773,9 @@ static struct ata_queued_cmd *ata_qc_new(struct ata_port
*ap)
+ break;
+ }
+ }
++#if IS_ENABLED(CONFIG_ATA_LEDS)
++ ata_led_act(ap);
++#endif
+
+ return qc;
+ }
+@@ -5671,6 +5686,9 @@ struct ata_port *ata_port_alloc(struct ata_host *host)
+ ap-stats.unhandled_irq = 1;
+ ap-stats.idle_irq = 1;
+ #endif
++#if IS_ENABLED(CONFIG_ATA_LEDS)
++ ap-ledtrig = kzalloc(sizeof(struct led_trigger), GFP_KERNEL);
++#endif
+ ata_sff_port_init(ap);
+
+ return ap;
+@@ -5692,6 +5710,12 @@ static void ata_host_release(struct device *gendev,
void *res)
+
+ kfree(ap-pmp_link);
+ kfree(ap-slave_link);
++#if IS_ENABLED(CONFIG_ATA_LEDS)
++ if (ap-ledtrig) {
++ led_trigger_unregister(ap-ledtrig);
++ kfree(ap-ledtrig);
++ };
++#endif
+ kfree(ap);
+ host-ports[i] = NULL;
+ }
+@@ -6138,7 +6162,23 @@ int ata_host_register(struct ata_host *host, struct
scsi_host_template *sht)
+ host-ports[i]-print_id = atomic_inc_return(ata_print_id);
+ host-ports[i]-local_port_no = i + 1;
+ }
++#if IS_ENABLED(CONFIG_ATA_LEDS)
++ for (i = 0; i host-n_ports; i++) {
++ if (unlikely(!host-ports[i]-ledtrig))
++ continue;
++
++ snprintf(host-ports[i]-ledtrig_name,
++ sizeof(host-ports[i]-ledtrig_name), ata%u,
++ host-ports[i]-print_id);
+
++
Re: [OpenWrt-Devel] [PATCH v4 4/4] kernel: 3.18: Strip off all the useless options
On Fri, Dec 12, 2014 at 5:02 PM, Maxime Ripard maxime.rip...@free-electrons.com wrote: Now that we use the defconfigs, we can remove all the options at their default value. This causes a lot of kernel-config changes for e.g bcm63xx_smp with 3.18, several of which are unwanted (e.g. enabling of the FPU emulator). How did you determine which of these symbols were unneeded? Here a diff of the resulting .config with patches 1-3 applied (before), and with patch 4 in addition applied (after) --- config-3.18-before 2014-12-12 18:39:08.385702153 +0100 +++ config-3.18-after 2014-12-12 18:33:58.197708840 +0100 @@ -167,9 +167,9 @@ # CONFIG_PREEMPT is not set # CONFIG_KEXEC is not set # CONFIG_CRASH_DUMP is not set -# CONFIG_SECCOMP is not set +CONFIG_SECCOMP=y CONFIG_MIPS_O32_FP64_SUPPORT=y -# CONFIG_MIPS_FPU_EMULATOR is not set +CONFIG_MIPS_FPU_EMULATOR=y CONFIG_USE_OF=y CONFIG_BOOT_RAW=y CONFIG_LOCKDEP_SUPPORT=y @@ -262,7 +262,7 @@ # CONFIG_KALLSYMS_UNCOMPRESSED is not set CONFIG_BPF=y CONFIG_EXPERT=y -# CONFIG_SGETMASK_SYSCALL is not set +CONFIG_SGETMASK_SYSCALL=y # CONFIG_SYSFS_SYSCALL is not set # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y @@ -276,7 +276,7 @@ CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y -CONFIG_BPF_SYSCALL=y +# CONFIG_BPF_SYSCALL is not set CONFIG_SHMEM=y # CONFIG_AIO is not set # CONFIG_ADVISE_SYSCALLS is not set @@ -311,6 +311,7 @@ CONFIG_HAVE_ARCH_JUMP_LABEL=y CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y CONFIG_HAVE_ARCH_SECCOMP_FILTER=y +CONFIG_SECCOMP_FILTER=y CONFIG_HAVE_CC_STACKPROTECTOR=y # CONFIG_CC_STACKPROTECTOR is not set CONFIG_CC_STACKPROTECTOR_NONE=y @@ -406,7 +407,11 @@ # CONFIG_PCIEPORTBUS=y # CONFIG_PCIEAER is not set -# CONFIG_PCIEASPM is not set +CONFIG_PCIEASPM=y +# CONFIG_PCIEASPM_DEBUG is not set +CONFIG_PCIEASPM_DEFAULT=y +# CONFIG_PCIEASPM_POWERSAVE is not set +# CONFIG_PCIEASPM_PERFORMANCE is not set CONFIG_MMU=y # CONFIG_PCCARD is not set # CONFIG_HOTPLUG_PCI is not set @@ -418,7 +423,7 @@ # CONFIG_BINFMT_ELF=y CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y -# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set +CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y CONFIG_BINFMT_SCRIPT=y # CONFIG_HAVE_AOUT is not set # CONFIG_BINFMT_MISC is not set @@ -528,7 +533,7 @@ CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set CONFIG_NETFILTER_ADVANCED=y -# CONFIG_BRIDGE_NETFILTER is not set +CONFIG_BRIDGE_NETFILTER=y # # Core Netfilter Configuration @@ -636,6 +641,7 @@ CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m # CONFIG_NETFILTER_XT_MATCH_NFACCT is not set # CONFIG_NETFILTER_XT_MATCH_OWNER is not set +# CONFIG_NETFILTER_XT_MATCH_PHYSDEV is not set # CONFIG_NETFILTER_XT_MATCH_PKTTYPE is not set # CONFIG_NETFILTER_XT_MATCH_QUOTA is not set # CONFIG_NETFILTER_XT_MATCH_RATEEST is not set @@ -657,7 +663,7 @@ # CONFIG_NF_DEFRAG_IPV4=m CONFIG_NF_CONNTRACK_IPV4=m -# CONFIG_NF_CONNTRACK_PROC_COMPAT is not set +CONFIG_NF_CONNTRACK_PROC_COMPAT=y # CONFIG_NF_LOG_ARP is not set CONFIG_NF_LOG_IPV4=m CONFIG_NF_REJECT_IPV4=m @@ -966,7 +972,7 @@ # # CONFIG_MTD_LPDDR is not set CONFIG_MTD_SPI_NOR=y -# CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set +CONFIG_MTD_SPI_NOR_USE_4K_SECTORS=y # CONFIG_MTD_UBI is not set CONFIG_DTC=y CONFIG_OF=y @@ -1201,7 +1207,9 @@ # CONFIG_FORCEDETH is not set CONFIG_NET_VENDOR_OKI=y # CONFIG_ETHOC is not set -# CONFIG_NET_PACKET_ENGINE is not set +CONFIG_NET_PACKET_ENGINE=y +# CONFIG_HAMACHI is not set +# CONFIG_YELLOWFIN is not set CONFIG_NET_VENDOR_QLOGIC=y # CONFIG_QLA3XXX is not set # CONFIG_QLCNIC is not set @@ -1304,9 +1312,9 @@ CONFIG_PPP=m # CONFIG_PPP_BSDCOMP is not set # CONFIG_PPP_DEFLATE is not set -CONFIG_PPP_FILTER=y +# CONFIG_PPP_FILTER is not set # CONFIG_PPP_MPPE is not set -CONFIG_PPP_MULTILINK=y +# CONFIG_PPP_MULTILINK is not set CONFIG_PPPOE=m CONFIG_PPP_ASYNC=m # CONFIG_PPP_SYNC_TTY is not set @@ -1345,7 +1353,10 @@ # # Userland interfaces # -# CONFIG_INPUT_MOUSEDEV is not set +CONFIG_INPUT_MOUSEDEV=m +CONFIG_INPUT_MOUSEDEV_PSAUX=y +CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 +CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_EVDEV is not set # CONFIG_INPUT_EVBUG is not set @@ -1354,7 +1365,7 @@ # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y -# CONFIG_KEYBOARD_ATKBD is not set +CONFIG_KEYBOARD_ATKBD=m # CONFIG_KEYBOARD_LKKBD is not set # CONFIG_KEYBOARD_GPIO is not set CONFIG_KEYBOARD_GPIO_POLLED=m @@ -1366,29 +1377,41 @@ # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_OMAP4 is not set # CONFIG_KEYBOARD_XTKBD is not set -# CONFIG_INPUT_MOUSE is not set +CONFIG_INPUT_MOUSE=y +CONFIG_MOUSE_PS2=m +CONFIG_MOUSE_PS2_ALPS=y +CONFIG_MOUSE_PS2_LOGIPS2PP=y +CONFIG_MOUSE_PS2_SYNAPTICS=y +CONFIG_MOUSE_PS2_CYPRESS=y +CONFIG_MOUSE_PS2_TRACKPOINT=y +# CONFIG_MOUSE_PS2_ELANTECH is not set +# CONFIG_MOUSE_PS2_SENTELIC is not set +# CONFIG_MOUSE_PS2_TOUCHKIT is not set +# CONFIG_MOUSE_SERIAL is not set +# CONFIG_MOUSE_APPLETOUCH is not set +#
Re: [OpenWrt-Devel] [PATCH v4 2/4] kernel.mk: Handle the x86_64 LINUX_KARCH case
On 2014-12-12 17:02, Maxime Ripard wrote: x64 is handled by the x86 architecture in Linux, add a case for it in LINUX_KARCH. Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com Applied the first two patches in this series. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH RFC 2/5] ubinize-image: Change the rootfs to a static volume
On Fri, Dec 12, 2014 at 04:21:02PM +0100, Maxime Ripard wrote:
On boards with large page size, the rootfs we generate might end up using less
PEB than the minimum number required by UBI for a dynamic volume.
Change the rootfs to a static volume, which removes such a requirement, and
isn't changing anything, since our rootfs is in read only anyway.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
---
scripts/ubinize-image.sh | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/scripts/ubinize-image.sh b/scripts/ubinize-image.sh
index 6762c22bc4a6..11c25ecc8ee1 100755
--- a/scripts/ubinize-image.sh
+++ b/scripts/ubinize-image.sh
@@ -25,13 +25,17 @@ ubivol() {
echo [$name]
echo mode=ubi
echo vol_id=$volid
- echo vol_type=dynamic
echo vol_name=$name
if [ $image ]; then
echo image=$image
else
echo vol_size=1MiB
fi
+ if [ $name = rootfs ]; then
+ echo vol_type=static
+ else
+ echo vol_type=dynamic
+ fi
Once again, this will break read-write UBIFS rootfs, which is an option we
do offer on NAND/UBI targets, just as we do offer read-write JFFS2 rootfs on
NOR targets.
So to make your rootfs come out as a static volume only when it's ubifs, you
could do
if [ $name = rootfs -a -z $autoresize ]; then
echo vol_type=static
else
echo vol_type=dynamic
fi
However, also this didn't actually work on any of the UBIFS based boxes I got
here for testing (kirkwood, oxnas, lantiq-danube), I constantly get stuff like
when having rootfs a static volumes (contrary to your statement that suggests
that changing to a static volume removes exactly that problem):
[1.592535] UBIFS error (pid 1): init_constants_early: too few LEBs (16),
min. is 17
[1.604008] UBI error: ubiblock_read_to_buf: ubiblock0_3 ubi_read error -22
[1.611025] end_request: I/O error, dev ubiblock0_3, sector 3860
[1.617093] SQUASHFS error: squashfs_read_data failed to read block 0x1e2ab3
[1.624107] SQUASHFS error: unable to read id index table
Why do you need that quite abandonned support for static UBI volumes so badly?
If there is a problem with small dynamic volumes, that is something to be
adressed properly rather than being worked around at the cost of breaking
other things.
Cheers
Daniel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] kernel/generic: remove some left-over garbage from ledtrig patch
cosmetics. clean a style issue introduced by r43674. Signed-off-by: Daniel Golle dan...@makrotopia.org --- target/linux/generic/patches-3.14/834-ledtrig-libata.patch | 2 +- target/linux/generic/patches-3.18/834-ledtrig-libata.patch | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/target/linux/generic/patches-3.14/834-ledtrig-libata.patch b/target/linux/generic/patches-3.14/834-ledtrig-libata.patch index 23663de..b015d7a 100644 --- a/target/linux/generic/patches-3.14/834-ledtrig-libata.patch +++ b/target/linux/generic/patches-3.14/834-ledtrig-libata.patch @@ -138,7 +138,7 @@ index 2d18241..4428e2b 100644 #include linux/acpi.h #include linux/cdrom.h #include linux/sched.h -+#if IS_ENABLED(CONFIG_ATA_LEDS) ++#ifdef CONFIG_ATA_LEDS +#include linux/leds.h +#endif diff --git a/target/linux/generic/patches-3.18/834-ledtrig-libata.patch b/target/linux/generic/patches-3.18/834-ledtrig-libata.patch index 23663de..b015d7a 100644 --- a/target/linux/generic/patches-3.18/834-ledtrig-libata.patch +++ b/target/linux/generic/patches-3.18/834-ledtrig-libata.patch @@ -138,7 +138,7 @@ index 2d18241..4428e2b 100644 #include linux/acpi.h #include linux/cdrom.h #include linux/sched.h -+#if IS_ENABLED(CONFIG_ATA_LEDS) ++#ifdef CONFIG_ATA_LEDS +#include linux/leds.h +#endif -- 2.1.3 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v3] mxs: indention and whitespace fixes
Align this file with the style of most other modules.mk. Signed-off-by: Michael Heimpold m...@heimpold.de --- This is a rebased version because previous patch do no apply cleanly anymore. While at, adjust the wording a little bit. BR, mhei target/linux/mxs/modules.mk | 74 +-- 1 file changed, 37 insertions(+), 37 deletions(-) diff --git a/target/linux/mxs/modules.mk b/target/linux/mxs/modules.mk index d6dbb04..087878b 100644 --- a/target/linux/mxs/modules.mk +++ b/target/linux/mxs/modules.mk @@ -1,85 +1,85 @@ # -# Copyright (C) 2013 OpenWrt.org +# Copyright (C) 2013-2014 OpenWrt.org # # This is free software, licensed under the GNU General Public License v2. # See /LICENSE for more information. define KernelPackage/rtc-stmp3xxx -SUBMENU:=$(OTHER_MENU) -TITLE:=STMP3xxx SoC built-in RTC support -DEPENDS:=@TARGET_mxs -$(call AddDepends/rtc) -KCONFIG:= \ + SUBMENU:=$(OTHER_MENU) + TITLE:=STMP3xxx SoC built-in RTC support + DEPENDS:=@TARGET_mxs + $(call AddDepends/rtc) + KCONFIG:= \ CONFIG_RTC_CLASS=y \ CONFIG_RTC_DRV_STMP=m -FILES:=$(LINUX_DIR)/drivers/rtc/rtc-stmp3xxx.ko -AUTOLOAD:=$(call AutoLoad,50,rtc-stmp3xxx) + FILES:=$(LINUX_DIR)/drivers/rtc/rtc-stmp3xxx.ko + AUTOLOAD:=$(call AutoLoad,50,rtc-stmp3xxx) endef $(eval $(call KernelPackage,rtc-stmp3xxx)) define KernelPackage/wdt-stmp3xxx -SUBMENU:=$(OTHER_MENU) -TITLE:=STMP3xxx Watchdog timer -DEPENDS:=kmod-rtc-stmp3xxx -KCONFIG:=CONFIG_STMP3XXX_RTC_WATCHDOG -FILES:=$(LINUX_DIR)/drivers/$(WATCHDOG_DIR)/stmp3xxx_rtc_wdt.ko -AUTOLOAD:=$(call AutoLoad,51,stmp3xxx_rtc_wdt) + SUBMENU:=$(OTHER_MENU) + TITLE:=STMP3xxx Watchdog timer + DEPENDS:=kmod-rtc-stmp3xxx + KCONFIG:=CONFIG_STMP3XXX_RTC_WATCHDOG + FILES:=$(LINUX_DIR)/drivers/$(WATCHDOG_DIR)/stmp3xxx_rtc_wdt.ko + AUTOLOAD:=$(call AutoLoad,51,stmp3xxx_rtc_wdt) endef define KernelPackage/wdt-stmp3xxx/description -Kernel module for STMP3xxx watchdog timer. + Kernel module for STMP3xxx watchdog timer. endef $(eval $(call KernelPackage,wdt-stmp3xxx)) define KernelPackage/sound-soc-mxs -TITLE:=Freescale i.MX23/i.MX28 built-in SoC sound support -KCONFIG:= \ + TITLE:=Freescale i.MX23/i.MX28 built-in SoC sound support + KCONFIG:= \ CONFIG_SND_SOC_MXS_BUILTIN_CODEC \ CONFIG_SND_MXS_SOC_BUILTIN -FILES:= \ + FILES:= \ $(LINUX_DIR)/sound/soc/mxs/snd-soc-mxs-builtin-audio.ko \ $(LINUX_DIR)/sound/soc/mxs/snd-soc-mxs-builtin-dai.ko \ $(LINUX_DIR)/sound/soc/mxs/snd-soc-mxs-builtin-pcm.ko \ $(LINUX_DIR)/sound/soc/codecs/snd-soc-mxs-builtin-codec.ko -AUTOLOAD:=$(call AutoLoad,65,snd-soc-mxs-builtin-pcm snd-soc-mxs-builtin-dai snd-soc-mxs-builtin-codec snd-soc-mxs-builtin-audio) -DEPENDS:=@TARGET_mxs +kmod-sound-soc-core -$(call AddDepends/sound) + AUTOLOAD:=$(call AutoLoad,65,snd-soc-mxs-builtin-pcm snd-soc-mxs-builtin-dai snd-soc-mxs-builtin-codec snd-soc-mxs-builtin-audio) + DEPENDS:=@TARGET_mxs +kmod-sound-soc-core + $(call AddDepends/sound) endef define KernelPackage/sound-soc-mxs/description -Kernel support for Freescale i.MX23/i.MX28 built-in SoC audio + Kernel support for Freescale i.MX23/i.MX28 built-in SoC audio endef $(eval $(call KernelPackage,sound-soc-mxs)) define KernelPackage/iio-mxs-lradc -SUBMENU:=$(OTHER_MENU) -TITLE:=LRADC driver for i.MX23/28 -DEPENDS:=@TARGET_mxs +kmod-iio-core -KCONFIG:=CONFIG_MXS_LRADC -FILES:=$(LINUX_DIR)/drivers/staging/iio/adc/mxs-lradc.ko -AUTOLOAD:=$(call AutoLoad,70,mxs-lradc) + SUBMENU:=$(OTHER_MENU) + TITLE:=Freescale i.MX23/28 LRADC driver + DEPENDS:=@TARGET_mxs +kmod-iio-core + KCONFIG:=CONFIG_MXS_LRADC + FILES:=$(LINUX_DIR)/drivers/staging/iio/adc/mxs-lradc.ko + AUTOLOAD:=$(call AutoLoad,70,mxs-lradc) endef define KernelPackage/iio-mxs-lradc/description -Kernel module for i.MX23/28 LRADC driver + Kernel module for Freescale i.MX23/28 LRADC driver endef $(eval $(call KernelPackage,iio-mxs-lradc)) define KernelPackage/crypto-hw-dcp -TITLE:=i.MX23/28 DCP hardware crypto module -DEPENDS:=@TARGET_mxs -KCONFIG:=CONFIG_CRYPTO_DEV_MXS_DCP -FILES:=$(LINUX_DIR)/drivers/crypto/mxs-dcp.ko -AUTOLOAD:=$(call AutoLoad,90,mxs-dcp) -$(call AddDepends/crypto,+kmod-crypto-authenc +kmod-crypto-des) + TITLE:=Freescale i.MX23/28 DCP hardware crypto module + DEPENDS:=@TARGET_mxs + KCONFIG:=CONFIG_CRYPTO_DEV_MXS_DCP + FILES:=$(LINUX_DIR)/drivers/crypto/mxs-dcp.ko + AUTOLOAD:=$(call AutoLoad,90,mxs-dcp) + $(call AddDepends/crypto,+kmod-crypto-authenc +kmod-crypto-des) endef define KernelPackage/crypto-hw-dcp/description -Kernel support for the i.MX23/28 DCP crypto engine + Kernel support for Freescale i.MX23/28 DCP crypto engine endef $(eval $(call KernelPackage,crypto-hw-dcp)) @@ -109,7 +109,7 @@ define KernelPackage/i2c-mxs endef define
[OpenWrt-Devel] [PATCH] uboot-envtools: enable UBI support on non-legacy targets
We've been carrying around that patch for a while now and didn't ever encounter any problem on non-UBI flashtypes. So I guess the 8kB extra space won't hurt on modern platforms which might even make use of their U-Boot environment being stored in UBI. Let me know if there are any targets missing in the blacklist (i.e. platforms/SoCs without the option to deploy NAND flash or commonly found with only 4MB flash where those 8kB might actually matter, or platforms where we haven't got U-Boot, ...) Signed-off-by: Daniel Golle dan...@makrotopia.org --- package/boot/uboot-envtools/Config.in | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/package/boot/uboot-envtools/Config.in b/package/boot/uboot-envtools/Config.in index 9fd8103..10c03f9 100644 --- a/package/boot/uboot-envtools/Config.in +++ b/package/boot/uboot-envtools/Config.in @@ -1,7 +1,13 @@ config UBOOT_ENVTOOLS_UBI bool Support environment in UBI volume depends on PACKAGE_uboot-envtools - default n + depends on !TARGET_adm5120 !TARGET_adm8668 !TARGET_ar7 \ + !TARGET_ar71xx_generic !TARGET_atheros \ + !TARGET_au1000 !TARGET_avr32 !TARGET_ramips_rt288x \ + !TARGET_ramips_rt305x !TARGET_uml !TARGET_x86 \ + !TARGET_x86_64 + + default y help Add support for reading and writing U-Boot environment stored in UBI volume(s). -- 2.1.3 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [package] fstools: make extroot functionality work with ubifs
From: Gergely Kiss mail.g...@gmail.com
Fix extroot functionality for devices where rootfs is on a ubifs partition
Signed-off-by: Gergely Kiss mail.g...@gmail.com
Tested-by: Gergely Kiss mail.g...@gmail.com
---
Originally created by forum user Hiro.AK47 for the 14.07 branch.
I've created a new diff to make it work with the master branch.
Tested on a Netgear WNDR4300 router, working fine in both overlay and
pivot root modes.
diff -rupN fstools.old/block.c fstools.new/block.c
--- fstools.old/block.c2014-12-12 17:32:23.833641055 +0100
+++ fstools.new/block.c2014-12-12 17:36:59.532478289 +0100
@@ -35,6 +35,7 @@
#include libubox/avl-cmp.h
#include libblkid-tiny/libblkid-tiny.h
+#include libubi/libubi.h
#define ERROR(fmt, ...) do { \
syslog(LOG_ERR, fmt, ## __VA_ARGS__); \
@@ -823,13 +824,70 @@ static int find_block_mtd(char *name, ch
return 0;
}
+static int find_ubi_vol(libubi_t libubi, char *name, int *dev_num, int *vol_id)
+{
+ int dev = 0;
+
+ while (ubi_dev_present(libubi, dev))
+ {
+ struct ubi_dev_info dev_info;
+ struct ubi_vol_info vol_info;
+
+ if (ubi_get_dev_info1(libubi, dev++, dev_info))
+ continue;
+ if (ubi_get_vol_info1_nm(libubi, dev_info.dev_num,
name, vol_info))
+ continue;
+
+ *dev_num = dev_info.dev_num;
+ *vol_id = vol_info.vol_id;
+
+ return 0;
+ }
+
+ return -1;
+}
+
+static int find_block_ubi(libubi_t libubi, char *name, char *part, int plen)
+{
+ int dev_num;
+ int vol_id;
+ int err = -1;
+
+ err = find_ubi_vol(libubi, name, dev_num, vol_id);
+ if (!err)
+ snprintf(part, plen, /dev/ubi%d_%d, dev_num, vol_id);
+
+ return err;
+}
+
+static int find_block_ubi_RO(libubi_t libubi, char *name, char *part, int plen)
+{
+ int dev_num;
+ int vol_id;
+ int err = -1;
+
+ err = find_ubi_vol(libubi, name, dev_num, vol_id);
+ if (!err)
+ snprintf(part, plen, /dev/ubiblock%d_%d, dev_num, vol_id);
+
+ return err;
+}
+
static int check_extroot(char *path)
{
struct blkid_struct_probe *pr = NULL;
char fs[32];
-if (find_block_mtd(rootfs, fs, sizeof(fs)))
-return -1;
+ if (find_block_mtd(rootfs, fs, sizeof(fs))) {
+ int err = -1;
+ libubi_t libubi;
+
+ libubi = libubi_open();
+ err = find_block_ubi_RO(libubi, rootfs, fs, sizeof(fs));
+ libubi_close(libubi);
+ if (err)
+ return -1;
+ }
list_for_each_entry(pr, devices, list) {
if (!strcmp(pr-dev, fs)) {
@@ -933,6 +991,7 @@ static int main_extroot(int argc, char *
char fs[32] = { 0 };
char fs_data[32] = { 0 };
int err = -1;
+libubi_t libubi;
if (!getenv(PREINIT))
return -1;
@@ -947,8 +1006,13 @@ static int main_extroot(int argc, char *
find_block_mtd(rootfs, fs, sizeof(fs));
if (!fs[0]) {
-ERROR(extroot: unable to locate rootfs mtdblock\n);
-return -2;
+ libubi = libubi_open();
+ find_block_ubi_RO(libubi, rootfs, fs, sizeof(fs));
+ libubi_close(libubi);
+ if (!fs[0]) {
+ ERROR(extroot: unable to locate rootfs
mtdblock / ubiblock\n);
+ return -2;
+ }
}
pr = find_block_info(NULL, NULL, fs);
@@ -975,6 +1039,24 @@ static int main_extroot(int argc, char *
}
}
+ memset(fs_data, 0, sizeof(fs_data));
+ libubi = libubi_open();
+ find_block_ubi(libubi, rootfs_data, fs_data, sizeof(fs_data));
+ libubi_close(libubi);
+ if (fs_data[0]) {
+ char cfg[] = /tmp/ubifs_cfg;
+
+ mkdir_p(cfg);
+ if (!mount(fs_data, cfg, ubifs, MS_NOATIME, NULL)) {
+ err = mount_extroot(cfg);
+ umount2(cfg, MNT_DETACH);
+ }
+ if (err 0)
+ rmdir(/tmp/overlay);
+ rmdir(cfg);
+ return err;
+ }
+
return mount_extroot(NULL);
}
diff -rupN fstools.old/CMakeLists.txt fstools.new/CMakeLists.txt
--- fstools.old/CMakeLists.txt2014-12-12 17:32:23.833641055 +0100
+++ fstools.new/CMakeLists.txt2014-12-12 17:31:48.729637303 +0100
@@ -48,7 +48,7 @@ TARGET_LINK_LIBRARIES(mount_root fstools
INSTALL(TARGETS mount_root RUNTIME DESTINATION sbin)
ADD_EXECUTABLE(block block.c)
-TARGET_LINK_LIBRARIES(block blkid-tiny uci ubox blobmsg_json)
+TARGET_LINK_LIBRARIES(block blkid-tiny uci ubox blobmsg_json ubi-utils)
INSTALL(TARGETS block RUNTIME DESTINATION sbin)
ADD_EXECUTABLE(jffs2reset jffs2reset.c)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
Re: [OpenWrt-Devel] lenovo Y1/S port mapping
Actually I don't know what port 7 is. Port 5 is not required for Y1. 2014-12-12 22:20 GMT+08:00 John Crispin blo...@openwrt.org: On 12/12/2014 12:21, 郭传鈜 wrote: Y1S has 2 Gigabit LAN. So I used the following: y1 |\ y1s) ucidef_set_interfaces_lan_wan eth0.1 eth0.2 ucidef_add_switch switch0 1 1 ucidef_add_switch_vlan switch0 1 0 1 2 3 5 6t 7 is port 5 and 7 required ? port 7 is HW_NAT port i think John ucidef_add_switch_vlan switch0 2 4 6t ;; Tested on Y1. But I don't have a Y1S so I can't test if this is the correct config. AhSorry for my bad English:-) 2014-12-12 3:44 GMT+08:00, John Crispin blo...@openwrt.org: Hi, any lenovo Y1S users around ? while looking into this ticket - https://dev.openwrt.org/ticket/18528 i found this site - http://show.smzdm.com/detail/94937 looking at the picture i think the port mapping is totally broken. we currently have y1 |\ y1s) ucidef_set_interfaces_lan_wan eth0.1 eth0.2 ucidef_add_switch switch0 1 1 ucidef_add_switch_vlan switch0 1 1 2 3 4 5 6t ucidef_add_switch_vlan switch0 2 0 6t wan on Y1 should be port 4 and wan on Y1S should be port 5 (gmac1) i think it should be y1) ucidef_set_interfaces_lan_wan eth0.1 eth0.2 ucidef_add_switch switch0 1 1 ucidef_add_switch_vlan switch0 1 0 1 2 3 6t ucidef_add_switch_vlan switch0 2 4 6t y1s) ucidef_set_interfaces_lan_wan eth0.1 eth0.2 ucidef_add_switch switch0 1 1 ucidef_add_switch_vlan switch0 1 0 1 2 3 4 6t ucidef_add_switch_vlan switch0 2 5 6t could someone tell me if the case has WAN written on any of the ports ? John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] oxnas: also make use of the GPIO poweroff driver
Works great to power-off the kd20 ;)
Signed-off-by: Daniel Golle dan...@makrotopia.org
---
target/linux/oxnas/config-3.14| 4
target/linux/oxnas/config-3.18| 4
target/linux/oxnas/files/arch/arm/boot/dts/ox820-kd20.dts | 5 +
3 files changed, 13 insertions(+)
diff --git a/target/linux/oxnas/config-3.14 b/target/linux/oxnas/config-3.14
index a065363..9b0f3f9 100644
--- a/target/linux/oxnas/config-3.14
+++ b/target/linux/oxnas/config-3.14
@@ -280,6 +280,10 @@ CONFIG_PM=y
CONFIG_PM_CLK=y
# CONFIG_PM_DEBUG is not set
CONFIG_PM_RUNTIME=y
+CONFIG_POWER_RESET=y
+CONFIG_POWER_RESET_GPIO=y
+# CONFIG_POWER_RESET_VEXPRESS is not set
+CONFIG_POWER_SUPPLY=y
CONFIG_PPS=y
# CONFIG_PREEMPT_RCU is not set
CONFIG_PRINTK_TIME=y
diff --git a/target/linux/oxnas/config-3.18 b/target/linux/oxnas/config-3.18
index b9172d9..e255781 100644
--- a/target/linux/oxnas/config-3.18
+++ b/target/linux/oxnas/config-3.18
@@ -293,6 +293,10 @@ CONFIG_PM=y
CONFIG_PM_CLK=y
# CONFIG_PM_DEBUG is not set
CONFIG_PM_RUNTIME=y
+CONFIG_POWER_RESET=y
+CONFIG_POWER_RESET_GPIO=y
+# CONFIG_POWER_RESET_VEXPRESS is not set
+CONFIG_POWER_SUPPLY=y
CONFIG_PPS=y
# CONFIG_PREEMPT_RCU is not set
CONFIG_PRINTK_TIME=y
diff --git a/target/linux/oxnas/files/arch/arm/boot/dts/ox820-kd20.dts
b/target/linux/oxnas/files/arch/arm/boot/dts/ox820-kd20.dts
index 79442be..9375748 100644
--- a/target/linux/oxnas/files/arch/arm/boot/dts/ox820-kd20.dts
+++ b/target/linux/oxnas/files/arch/arm/boot/dts/ox820-kd20.dts
@@ -137,4 +137,9 @@
compatible = gpio-fan;
gpios = GPIOA 2 1;
};
+
+ gpio-poweroff {
+ compatible = gpio-poweroff;
+ gpios = GPIOA 9 0;
+ };
};
--
2.1.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Netgear WNDR3400 v1 and mac addresses
Good evening, I've flashed a Netgear WNDR3400 v1 with final official Barrier Breaker image. I've discovered that all mac addresses are the same for lan, wan and wireless, which I find odd. My search found this patch: https://dev.openwrt.org/browser/branches/barrier_breaker/target/linux/brcm47xx/patches-3.10/145-MIPS-BCM47XX-fixup-broken-MAC-addresses-in-nvram.patch This patch seems to fix exactly what I'm seeing, I just want to know why this is exclusively for routers with 00:90:4C macs, because my router is showing the same behavior with the exception that the mac address matches the one on the sticker. This router shows two mac addresses on the sticker by the way, my guess is one is for LAN, the other is for WAN. Thanks in advance! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ramips:Add support for Aigale Ai-BR100
Aigale Ai-BR100 is a router with mt7620a soc.
There are only 2 lights on the board (WAN and WLAN) so I used the wlan light as
the status led.
Signed-off-by: 郭传鈜 gch981...@gmail.com
---
target/linux/ramips/base-files/etc/board.d/01_leds | 4 +
.../linux/ramips/base-files/etc/board.d/02_network | 1 +
target/linux/ramips/base-files/etc/diag.sh | 3 +
target/linux/ramips/base-files/lib/ramips.sh | 3 +
.../ramips/base-files/lib/upgrade/platform.sh | 1 +
target/linux/ramips/dts/AIBR100.dts| 106 +
target/linux/ramips/image/Makefile | 3 +
target/linux/ramips/mt7620/profiles/aigale.mk | 20
8 files changed, 141 insertions(+)
create mode 100644 target/linux/ramips/dts/AIBR100.dts
create mode 100644 target/linux/ramips/mt7620/profiles/aigale.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 bd8c779..9c49c5c 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -27,6 +27,10 @@ case $board in
3g300m)
set_usb_led tenda:blue:3g
;;
+ ai-br100)
+ ucidef_set_led_netdev wan wan aigale:blue:wan eth0.2
+ set_wifi_led aigale:blue:wlan
+ ;;
a5-v11)
ucidef_set_led_default power POWER a5-v11:red:power 1
;;
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 b519cfd..80b5449 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -110,6 +110,7 @@ ramips_setup_interfaces()
;;
3g-6200n | \
+ ai-br100 | \
dir-610-a1 | \
dir-300-b7 | \
dir-320-b1 | \
diff --git a/target/linux/ramips/base-files/etc/diag.sh
b/target/linux/ramips/base-files/etc/diag.sh
index dfa5468..f50ae1f 100755
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -12,6 +12,9 @@ get_status_led() {
3g300m | w150m)
status_led=tenda:blue:ap
;;
+ ai-br100)
+ status_led=aigale:blue:wlan
+ ;;
ar670w)
status_led=ar670w:green:power
;;
diff --git a/target/linux/ramips/base-files/lib/ramips.sh
b/target/linux/ramips/base-files/lib/ramips.sh
index ff5044c..b4e5d91 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -28,6 +28,9 @@ ramips_board_detect() {
*A5-V11)
name=a5-v11
;;
+ *Aigale Ai-BR100)
+ name=ai-br100
+ ;;
*Airlink101 AR670W)
name=ar670w
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index 4962b8b..991d3b5 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -19,6 +19,7 @@ platform_check_image() {
3g300m | \
a5-v11 | \
air3gii | \
+ ai-br100 |\
all0239-3g | \
all0256n | \
all5002 | \
diff --git a/target/linux/ramips/dts/AIBR100.dts
b/target/linux/ramips/dts/AIBR100.dts
new file mode 100644
index 000..90f3a1e
--- /dev/null
+++ b/target/linux/ramips/dts/AIBR100.dts
@@ -0,0 +1,106 @@
+/dts-v1/;
+
+/include/ mt7620a.dtsi
+
+/ {
+ compatible = AIBR100, ralink,mt7620a-soc;
+ model = Aigale Ai-BR100;
+
+ palmbus@1000 {
+ gpio2: gpio@660 {
+ status = okay;
+ };
+
+ gpio3: gpio@688 {
+ status = okay;
+ };
+
+ spi@b00 {
+ status = okay;
+
+ m25p80@0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = en25q64;
+ reg = 0 0;
+ linux,modalias = m25p80, en25q64;
+ spi-max-frequency = 1000;
+
+ partition@0 {
+ label = u-boot;
+ reg = 0x0 0x2;
+ read-only;
+ };
+
+ partition@2 {
+ label = u-boot-env;
+ reg = 0x2 0x1;
+ read-only;
+ };
+
+ factory: partition@3 {
+ label =
[OpenWrt-Devel] [PATCH] oxnas: fix gpio-fan on kd20
define speed-map and include kmod-hwmon-gpiofan in kd20 profile
Signed-off-by: Daniel Golle dan...@makrotopia.org
---
target/linux/oxnas/files/arch/arm/boot/dts/ox820-kd20.dts | 2 ++
target/linux/oxnas/profiles/100-Generic.mk| 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/target/linux/oxnas/files/arch/arm/boot/dts/ox820-kd20.dts
b/target/linux/oxnas/files/arch/arm/boot/dts/ox820-kd20.dts
index 9375748..217d812 100644
--- a/target/linux/oxnas/files/arch/arm/boot/dts/ox820-kd20.dts
+++ b/target/linux/oxnas/files/arch/arm/boot/dts/ox820-kd20.dts
@@ -136,6 +136,8 @@
gpio-fan {
compatible = gpio-fan;
gpios = GPIOA 2 1;
+ gpio-fan,speed-map = 00
+ 3000 1;
};
gpio-poweroff {
diff --git a/target/linux/oxnas/profiles/100-Generic.mk
b/target/linux/oxnas/profiles/100-Generic.mk
index 6681c23..5304839 100644
--- a/target/linux/oxnas/profiles/100-Generic.mk
+++ b/target/linux/oxnas/profiles/100-Generic.mk
@@ -35,7 +35,7 @@ define Profile/KD20
NAME:=Shuttle KD20
PACKAGES:= \
kmod-usb3 kmod-usb-storage kmod-i2c-gpio kmod-rtc-pcf8563 \
- kmod-gpio-beeper
+ kmod-gpio-beeper kmod-hwmon-core kmod-hwmon-gpiofan
endef
define Profile/KD20/Description
--
2.1.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] uboot-envtools: enable UBI support on non-legacy targets
i think this should the opt-in not opt-out. target maintainers should set it only if they have boards with the env stored inside ubi. John On 12/12/2014 23:59, Daniel Golle wrote: We've been carrying around that patch for a while now and didn't ever encounter any problem on non-UBI flashtypes. So I guess the 8kB extra space won't hurt on modern platforms which might even make use of their U-Boot environment being stored in UBI. Let me know if there are any targets missing in the blacklist (i.e. platforms/SoCs without the option to deploy NAND flash or commonly found with only 4MB flash where those 8kB might actually matter, or platforms where we haven't got U-Boot, ...) Signed-off-by: Daniel Golle dan...@makrotopia.org --- package/boot/uboot-envtools/Config.in | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/package/boot/uboot-envtools/Config.in b/package/boot/uboot-envtools/Config.in index 9fd8103..10c03f9 100644 --- a/package/boot/uboot-envtools/Config.in +++ b/package/boot/uboot-envtools/Config.in @@ -1,7 +1,13 @@ config UBOOT_ENVTOOLS_UBI bool Support environment in UBI volume depends on PACKAGE_uboot-envtools - default n + depends on !TARGET_adm5120 !TARGET_adm8668 !TARGET_ar7 \ +!TARGET_ar71xx_generic !TARGET_atheros \ +!TARGET_au1000 !TARGET_avr32 !TARGET_ramips_rt288x \ +!TARGET_ramips_rt305x !TARGET_uml !TARGET_x86 \ +!TARGET_x86_64 + + default y help Add support for reading and writing U-Boot environment stored in UBI volume(s). ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: add an extra check on board_name for ath10k firmware patchs
Hi lynxis,
ah the stray ath10k fw warning ... thanks, one todo less on my list :)
John
On 13/12/2014 08:19, Alexander Couzens wrote:
It moves firmware patch code behind an extra check on board_name.
Otherwise it will calculate firmware checksum for unaffected boards.
It also reduce boottime by a md5 calculation and removes error message
on boot if firmware not found.
---
.../ar71xx/base-files/lib/preinit/82_patch_ath10k| 20
++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/target/linux/ar71xx/base-files/lib/preinit/82_patch_ath10k
b/target/linux/ar71xx/base-files/lib/preinit/82_patch_ath10k
index c5c60ef..0455ecb 100644
--- a/target/linux/ar71xx/base-files/lib/preinit/82_patch_ath10k
+++ b/target/linux/ar71xx/base-files/lib/preinit/82_patch_ath10k
@@ -3,13 +3,13 @@
. /lib/functions/system.sh
. /lib/ar71xx.sh
-firmware_file=/lib/firmware/ath10k/QCA988X/hw2.0/firmware-3.bin
-firmware_md5_orig=5163aa8de591f80b06c77f22e9777473
-firmware_md5_current=$(md5sum $firmware_file)
-firmware_md5_current=${firmware_md5_current%% *}
-
do_patch_ath10k_firmware() {
+ local firmware_file=/lib/firmware/ath10k/QCA988X/hw2.0/firmware-3.bin
+ local firmware_md5_orig=5163aa8de591f80b06c77f22e9777473
+ local firmware_md5_current=$(md5sum $firmware_file)
+ local firmware_md5_current=${firmware_md5_current%% *}
+
# verify md5sum before patching
[ firmware_md5_orig != firmware_md5_current ] || {
return
@@ -34,4 +34,12 @@ do_patch_ath10k_firmware() {
rm /tmp/ath10k-firmware.bin
}
-boot_hook_add preinit_main do_patch_ath10k_firmware
+check_patch_ath10k_firmware() {
+ case $(ar71xx_board_name) in
+ dgl-5500-a1)
+ do_patch_ath10k_firmware
+ ;;
+ esac
+}
+
+boot_hook_add preinit_main check_patch_ath10k_firmware
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips:Add support for Aigale Ai-BR100
On 13/12/2014 08:04, Yousong Zhou wrote: +define Profile/AIBR100 + NAME:=Aigale Ai-BR100 + PACKAGES:=\ + kmod-usb-core \ + kmod-usb-ohci \ + kmod-ledtrig-usbdev \ + kmod-usb2 +endef kmod-ledtrig-usbdev should be optional. yousong ... and usb-core gets auto selected. i fixed this while merging it into my tree. John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
