Re: [OpenWrt-Devel] [PATCH v2] kernel: update 3.10.49 to 3.10.58 (released 2014-oct-15)
On 24.10.2014 22:36, Bastian Bittorf wrote:
All platforms which are using 3.10.x at the moment are upgraded.
compile tested on all platforms with:
make tools/install
make toolchain/install
make target/linux/compile
user@box:~/user/openwrt$ cat /tmp/log.txt
[Wed Oct 22 00:53:22 CEST 2014] ./smoketest.sh: ar7 - OK
[Wed Oct 22 01:08:27 CEST 2014] ./smoketest.sh: au1000 - OK
[Wed Oct 22 04:35:56 CEST 2014] ./smoketest.sh: xburst - OK
run tested on x86, au1000, ar71xx, mpc85xx and brcm47xx
Godd morning - some buildbot feedback:
ar7, au1000 and xburst fail to build on the buildbots around the update with
the same error in image generation regarding an included header
http://buildbot.openwrt.org:8010/builders/ar7 726/727
http://buildbot.openwrt.org:8010/builders/au1000 655/656
http://buildbot.openwrt.org:8010/builders/xburst 705/706
Error taken from buildbots:
In file included from include/linux/string.h:17:0,
from include/linux/dynamic_debug.h:111,
from include/linux/kernel.h:14,
from arch/mips/boot/compressed/decompress.c:15:
/mnt/dl/slave/ar7/build/build_dir/target-mipsel_mips32_uClibc-0.9.33.2/linux-ar7_generic/linux-3.10.58/arch/mips/include/asm/string.h:150:2:
error: expected identifier or '(' before '{' token
({\
^
arch/mips/boot/compressed/decompress.c:48:7: note: in expansion of macro
'memcpy'
void *memcpy(void *dest, const void *src, size_t n)
^
culprit is possibly: generic/306-mips_mem_functions_performance.patch
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] kernel: update 3.10.49 to 3.10.58 (released 2014-oct-15)
* Dirk Neukirchen dirkneukirc...@web.de [28.10.2014 08:18]: ar7, au1000 and xburst fail to build on the buildbots around the update with the same error in image generation regarding an included header unsure whats wrong on buildserver. with r43099 i did a clean build (tools+toolchain+kernel) for ar7 + au1000 without errors. bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] iwinfo_cli.c:(.text.startup+0x120): undefined reference to `iwinfo_backend_by_name'
Try make package/iwinfo/{clean,compile}
~ Jow
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] kernel: update 3.10.49 to 3.10.58 (released 2014-oct-15)
* Dirk Neukirchen dirkneukirc...@web.de [28.10.2014 08:18]: http://buildbot.openwrt.org:8010/builders/ar7 726/727 http://buildbot.openwrt.org:8010/builders/au1000 655/656 http://buildbot.openwrt.org:8010/builders/xburst 705/706 i can reproduce it here - will dig into this. bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] kernel: update 3.10.49 to 3.10.58 (released 2014-oct-15)
On 28.10.2014 07:46, Dirk Neukirchen wrote:
http://buildbot.openwrt.org:8010/builders/ar7 726/727
http://buildbot.openwrt.org:8010/builders/au1000 655/656
http://buildbot.openwrt.org:8010/builders/xburst 705/706
Error taken from buildbots:
In file included from include/linux/string.h:17:0,
from include/linux/dynamic_debug.h:111,
from include/linux/kernel.h:14,
from arch/mips/boot/compressed/decompress.c:15:
/mnt/dl/slave/ar7/build/build_dir/target-mipsel_mips32_uClibc-0.9.33.2/linux-ar7_generic/linux-3.10.58/arch/mips/include/asm/string.h:150:2:
error: expected identifier or '(' before '{' token
({\
^
arch/mips/boot/compressed/decompress.c:48:7: note: in expansion of macro
'memcpy'
void *memcpy(void *dest, const void *src, size_t n)
^
culprit is possibly: generic/306-mips_mem_functions_performance.patch
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
might be related:
at the beginning in the buildbot logs:
.config:1787:warning: override: KERNEL_XZ changes choice state
.config:2081:warning: override: MIPS_MTX1 changes choice state
arch/mips/boot/compressed/decompress.c has CPP CONFIG_KERNEL_XZ
so CONFIG_HAVE_KERNEL_XZ / CONFIG_KERNEL_XZ decompressor fix (generic #061)
affects MIPS
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] platform xburst / maintainer
can somebody please add the maintainer of 'xburst' to https://dev.openwrt.org/wiki/platforms when looking into the commits, it seems 'lars' is it?! bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCHv2] Linux 3.16 support on mvebu
Hi Maxime, On 9 October 2014 17:10, Maxime Ripard maxime.rip...@free-electrons.com wrote: This is the second version of my rather big changes to support the 3.16 kernel, and more specifically on the mvebu SoCs. The first patch ports the existing 3.14 patches to 3.16, and creates a generic configuration for it. http://free-electrons.com/~maxime/pub/openwrt-3.16/v2-0001-linux-Add-3.16-support.patch A kind of problem with 3.16 was its support as it wasn't picked for LTS by anyone. So personally I'd prefer to use another kernel version for OpenWrt release. A one with LTS would be great. Recently we've started working on 3.18, which is probably the nearest kernel with a chance of LTS. And it case it won't be LTS, personally I'd look for another one. The second patch does pretty much the same thing but for the mvebu target. Would it be possible for you to switch to 3.18? It's still not ready (not compiling) as it was started just yesterday. But I think we will try to stabilize this one. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCHv2] Linux 3.16 support on mvebu
Hi Rafał, On Tue, Oct 28, 2014 at 04:29:15PM +0100, Rafał Miłecki wrote: Hi Maxime, On 9 October 2014 17:10, Maxime Ripard maxime.rip...@free-electrons.com wrote: This is the second version of my rather big changes to support the 3.16 kernel, and more specifically on the mvebu SoCs. The first patch ports the existing 3.14 patches to 3.16, and creates a generic configuration for it. http://free-electrons.com/~maxime/pub/openwrt-3.16/v2-0001-linux-Add-3.16-support.patch A kind of problem with 3.16 was its support as it wasn't picked for LTS by anyone. So personally I'd prefer to use another kernel version for OpenWrt release. A one with LTS would be great. Recently we've started working on 3.18, which is probably the nearest kernel with a chance of LTS. And it case it won't be LTS, personally I'd look for another one. I wasn't aware of such policy. Is there a reason for 3.13 for example to be supported then? And yeah, I discovered your work on 3.18 this morning when pulling the changes. The second patch does pretty much the same thing but for the mvebu target. Would it be possible for you to switch to 3.18? It's still not ready (not compiling) as it was started just yesterday. But I think we will try to stabilize this one. I needed a kernel = 3.16, so 3.18 is fine for me. I can of course help to bring it up, and I'll be happy to, but if there's a chance for my work to actually help and be merged. So far, I sent three change sets: - One that, as I just discovered, has been silently merged. I guess it's ok. - One to upgrade to 3.16, which will apparently not get merged, because some private (as in !public) effort as been going on and just appeared out of nowhere on the git repo, without any posting or reviews. I didn't receive any mail warning me of that effort, or why my work was considered pointless, before yours, three weeks later. - One to fix real issues that were preventing *any* openwrt image to be flashed, let alone work, on one officially supported device. This one being the most critical only got two reviews, that were just basically saying meh. I don't like it, but never got any suggestions on how to actually fix things the right way. I'm not trying to force my way in, I'm really not, I'd be really happy to improve my patches so that these bugs end up being fixed upstream. But there need to be some discussion, and guidance probably, for that, and so far there's been none. These were my first contributions to OpenWRT, and I can't really say I've been pleased with the experience so far. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCHv2] Linux 3.16 support on mvebu
On 28 October 2014 16:59, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Tue, Oct 28, 2014 at 04:29:15PM +0100, Rafał Miłecki wrote: On 9 October 2014 17:10, Maxime Ripard maxime.rip...@free-electrons.com wrote: This is the second version of my rather big changes to support the 3.16 kernel, and more specifically on the mvebu SoCs. The first patch ports the existing 3.14 patches to 3.16, and creates a generic configuration for it. http://free-electrons.com/~maxime/pub/openwrt-3.16/v2-0001-linux-Add-3.16-support.patch A kind of problem with 3.16 was its support as it wasn't picked for LTS by anyone. So personally I'd prefer to use another kernel version for OpenWrt release. A one with LTS would be great. Recently we've started working on 3.18, which is probably the nearest kernel with a chance of LTS. And it case it won't be LTS, personally I'd look for another one. I wasn't aware of such policy. Is there a reason for 3.13 for example to be supported then? It's what some ppl prefer, maybe even more since the AA release. 10.04 was based on 3.3 which caused some problems. I don't really know about 3.13. My personal great wish is to kill 3.3, 3.8 and 3.13 ASAP in OpenWrt. The second patch does pretty much the same thing but for the mvebu target. Would it be possible for you to switch to 3.18? It's still not ready (not compiling) as it was started just yesterday. But I think we will try to stabilize this one. I needed a kernel = 3.16, so 3.18 is fine for me. I can of course help to bring it up, and I'll be happy to, but if there's a chance for my work to actually help and be merged. So far, I sent three change sets: - One that, as I just discovered, has been silently merged. I guess it's ok. - One to upgrade to 3.16, which will apparently not get merged, because some private (as in !public) effort as been going on and just appeared out of nowhere on the git repo, without any posting or reviews. I didn't receive any mail warning me of that effort, or why my work was considered pointless, before yours, three weeks later. - One to fix real issues that were preventing *any* openwrt image to be flashed, let alone work, on one officially supported device. This one being the most critical only got two reviews, that were just basically saying meh. I don't like it, but never got any suggestions on how to actually fix things the right way. I'm not trying to force my way in, I'm really not, I'd be really happy to improve my patches so that these bugs end up being fixed upstream. But there need to be some discussion, and guidance probably, for that, and so far there's been none. These were my first contributions to OpenWRT, and I can't really say I've been pleased with the experience so far. I can't really say why your work wasn't properly reviewed/accepted. Adding new kernel is always a big task to do to review. I guess noone got time to spend few hours checking your 3.16 patches :( And it's really complex for one developer to handle all subsystem changes. I also don't see a good solution for that. 1) Someone spends hours working on new kernel support silently Result: people complaining because of non-public slow work. 2) Someone tries to work on new kernel in a public way Result: people complaining it's not working out-of-box, see: https://dev.openwrt.org/ticket/18236 I didn't really spend hours working on 3.18 in some non-public way. I just ported most patches in ~2 hours and pushed what I got. Now I need help on cleaning that up. I'm also not sure about other of your patches. My only guess I ppl didn't focus on them since there wasn't 3.16 in the first place. Or maybe you could send separated patch per patch? Luka: any comments / preferences about this? -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Autoneg problems with ar8216 on kernel 3.14 (related to ticket 17800)
After a little more thinking about it and looking at the code I basically have two questions: 1. Is it actually needed to exclude certain phy's in ar8xxx_phy_config_aneg? (At least for AR8327 it doesn't get called with an addr != 0 anyway) Else we could remove ar8xxx_phy_config_aneg and directly register genphy_config_aneg as callback for autoneg configuration. 2. Call sequence with regard to ar8216 is: ar8216: ar8xxx_phy_probe phy: phy_attach_direct phy: phy_init_hw ar8216: ar8xxx_phy_config_init ar8216: ar8xxx_phy_config_aneg ar8216 driver handles AR8327/AR8337 different from the other supported switch types. ar8xxx_start incl. more detailed configuration is called from ar8xxx_phy_probe already. For the other switch types it's called from ar8xxx_phy_config_init. I wonder whether doing detailed configuration in the probe stage might be too early. phy_init_hw resets the switch anyway later. Doing the detailed setup in ar8xxx_phy_config_init seems to be more suited however there might be good reason why it's handled the way it is. Rgds, Heiner Am 27.10.2014 um 22:00 schrieb Heiner Kallweit: With two different TPLINK routers (both with a AR8327N switch) I faced the issue that with kernel 3.14 certain switch ports used 10MBit/half only. Under kernel 3.10 everything was fine and the same ports used 1000MBit/full. As the ar8216 driver is the same I had a look at the common phy code in drivers/net/phy. In function phy_init_hw in phy_device.c kernel 3.14 resets the phy whilst 3.10 does not. The issue turned out to be that when resetting only flag BMCR_RESET is set, not BMCR_ANENABLE. (In ar8216.c always both flags are set when the switch is reset) Therefore autoneg was not enabled. Also later in the boot process it doesn't get enabled. Adding BMCR_ANENABLE solved the problem and now also under 3.14 all ports use 1000MBit/full. However I'm not sure whether it's a poper fix to add BMCR_ANENABLE in this generic phy function. It might not be appropriate for other phy's. After resetting the switch later in the boot process ar8xxx_phy_config_aneg is called with phydev-addr being 0. In this case the function returns immediately. Otherwise it would call genphy_config_aneg. Calling genphy_config_aneg would also solve the problem as it checks for BMCR_ANENABLE being set and sets it if needed. I don't know the reason why genphy_config_aneg isn't called in case of addr 0. Or is this a typo and the check actually should be addr != 0 ? Rgds, Heiner ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] platform xburst / maintainer
That was a long time ago and I guess we should consider that platform currently unmaintained. May I ask what's your interest in this platform? On 10/28/2014 03:29 PM, Bastian Bittorf wrote: can somebody please add the maintainer of 'xburst' to https://dev.openwrt.org/wiki/platforms when looking into the commits, it seems 'lars' is it?! bye, bastian ___ 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] Autoneg problems with ar8216 on kernel 3.14 (related to ticket 17800)
Regarding point 2 I checked the change history of ar8216.c With change set 36050 the start code for AR8327 was moved from config_init to probe. Commit comment: generic: ar8216: start AR8327 switch from the probe routine The AR8327 switch gets its configuration from platform data or from the device-tree. This allows to start it from the probe routine. Doing so makes it usable with ethernet drivers which only connects to the PHY device when the ethernet interface is opened. However I'm not able to say whether this is still relevant or whether it would be worth a thought to move back the start to config_init. Rgds, Heiner Am 28.10.2014 um 19:41 schrieb Heiner Kallweit: After a little more thinking about it and looking at the code I basically have two questions: 1. Is it actually needed to exclude certain phy's in ar8xxx_phy_config_aneg? (At least for AR8327 it doesn't get called with an addr != 0 anyway) Else we could remove ar8xxx_phy_config_aneg and directly register genphy_config_aneg as callback for autoneg configuration. 2. Call sequence with regard to ar8216 is: ar8216: ar8xxx_phy_probe phy: phy_attach_direct phy: phy_init_hw ar8216: ar8xxx_phy_config_init ar8216: ar8xxx_phy_config_aneg ar8216 driver handles AR8327/AR8337 different from the other supported switch types. ar8xxx_start incl. more detailed configuration is called from ar8xxx_phy_probe already. For the other switch types it's called from ar8xxx_phy_config_init. I wonder whether doing detailed configuration in the probe stage might be too early. phy_init_hw resets the switch anyway later. Doing the detailed setup in ar8xxx_phy_config_init seems to be more suited however there might be good reason why it's handled the way it is. Rgds, Heiner Am 27.10.2014 um 22:00 schrieb Heiner Kallweit: With two different TPLINK routers (both with a AR8327N switch) I faced the issue that with kernel 3.14 certain switch ports used 10MBit/half only. Under kernel 3.10 everything was fine and the same ports used 1000MBit/full. As the ar8216 driver is the same I had a look at the common phy code in drivers/net/phy. In function phy_init_hw in phy_device.c kernel 3.14 resets the phy whilst 3.10 does not. The issue turned out to be that when resetting only flag BMCR_RESET is set, not BMCR_ANENABLE. (In ar8216.c always both flags are set when the switch is reset) Therefore autoneg was not enabled. Also later in the boot process it doesn't get enabled. Adding BMCR_ANENABLE solved the problem and now also under 3.14 all ports use 1000MBit/full. However I'm not sure whether it's a poper fix to add BMCR_ANENABLE in this generic phy function. It might not be appropriate for other phy's. After resetting the switch later in the boot process ar8xxx_phy_config_aneg is called with phydev-addr being 0. In this case the function returns immediately. Otherwise it would call genphy_config_aneg. Calling genphy_config_aneg would also solve the problem as it checks for BMCR_ANENABLE being set and sets it if needed. I don't know the reason why genphy_config_aneg isn't called in case of addr 0. Or is this a typo and the check actually should be addr != 0 ? Rgds, Heiner ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/3] [x86] add EBOX-3300 target
Add support for the RDC D1011 IDE controller used in EBOX-3300 devices
Signed-off-by: Kamil Wcislo mek@gmail.com
---
diff --git a/package/kernel/linux/modules/block.mk
b/package/kernel/linux/modules/block.mk
index 8a84aa4..bbad241 100644
--- a/package/kernel/linux/modules/block.mk
+++ b/package/kernel/linux/modules/block.mk
@@ -116,6 +116,17 @@ endef
$(eval $(call KernelPackage,ata-nvidia-sata))
+define KernelPackage/ata-pata-821x
+ TITLE:=IT8211/2 PATA support
+ KCONFIG:=CONFIG_PATA_IT821X
+ FILES:=$(LINUX_DIR)/drivers/ata/pata_it821x.ko
+ AUTOLOAD:=$(call AutoLoad,41,pata_it821x,1)
+ $(call AddDepends/ata)
+endef
+
+$(eval $(call KernelPackage,ata-pata-821x))
+
+
define KernelPackage/ata-pdc202xx-old
SUBMENU:=$(BLOCK_MENU)
TITLE:=Older Promise PATA controller support
diff --git a/target/linux/x86/patches-3.10/170-rdc_d1011_ids.patch
b/target/linux/x86/patches-3.10/170-rdc_d1011_ids.patch
new file mode 100644
index 000..edd3eea
--- /dev/null
+++ b/target/linux/x86/patches-3.10/170-rdc_d1011_ids.patch
@@ -0,0 +1,20 @@
+--- a/drivers/ata/pata_it821x.c
b/drivers/ata/pata_it821x.c
+@@ -957,6 +957,7 @@ static const struct pci_device_id it821x
+ { PCI_VDEVICE(ITE, PCI_DEVICE_ID_ITE_8211), },
+ { PCI_VDEVICE(ITE, PCI_DEVICE_ID_ITE_8212), },
+ { PCI_VDEVICE(RDC, PCI_DEVICE_ID_RDC_D1010), },
++ { PCI_VDEVICE(RDC, PCI_DEVICE_ID_RDC_D1011), },
+
+ { },
+ };
+--- a/include/linux/pci_ids.h
b/include/linux/pci_ids.h
+@@ -2328,6 +2328,7 @@
+ #define PCI_DEVICE_ID_RDC_R6060 0x6060
+ #define PCI_DEVICE_ID_RDC_R6061 0x6061
+ #define PCI_DEVICE_ID_RDC_D1010 0x1010
++#define PCI_DEVICE_ID_RDC_D1011 0x1011
+
+ #define PCI_VENDOR_ID_LENOVO 0x17aa
+
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/3] [x86] add EBOX-3300 target
Add target for EBOX-3300 mini pc's Signed-off-by: Kamil Wcislo mek@gmail.com --- diff --git a/target/linux/x86/Makefile b/target/linux/x86/Makefile index 13f15c0..cc8ad8b 100644 --- a/target/linux/x86/Makefile +++ b/target/linux/x86/Makefile @@ -10,8 +10,8 @@ ARCH:=i386 BOARD:=x86 BOARDNAME:=x86 FEATURES:=squashfs ext4 vdi vmdk pcmcia targz -SUBTARGETS=generic olpc xen_domu ep80579 net5501 kvm_guest geos alix2 thincan \ - rdc +SUBTARGETS=generic olpc xen_domu ebox3300 ep80579 net5501 kvm_guest geos alix2 \ + thincan rdc KERNEL_PATCHVER:=3.10 diff --git a/target/linux/x86/ebox3300/config-3.10 b/target/linux/x86/ebox3300/config-3.10 new file mode 100644 index 000..792f257 --- /dev/null +++ b/target/linux/x86/ebox3300/config-3.10 @@ -0,0 +1,205 @@ +# CONFIG_3C515 is not set +# CONFIG_AC3200 is not set +CONFIG_ACPI=y +CONFIG_ACPI_AC=y +CONFIG_ACPI_BATTERY=y +CONFIG_ACPI_BLACKLIST_YEAR=0 +CONFIG_ACPI_BUTTON=y +# CONFIG_ACPI_CMPC is not set +# CONFIG_ACPI_CONTAINER is not set +# CONFIG_ACPI_CUSTOM_DSDT is not set +# CONFIG_ACPI_DEBUG is not set +# CONFIG_ACPI_DOCK is not set +# CONFIG_ACPI_EC_DEBUGFS is not set +# CONFIG_ACPI_FAN is not set +CONFIG_ACPI_I2C=y +# CONFIG_ACPI_INITRD_TABLE_OVERRIDE is not set +# CONFIG_ACPI_PCI_SLOT is not set +CONFIG_ACPI_PROCESSOR=y +# CONFIG_ACPI_PROCESSOR_AGGREGATOR is not set +# CONFIG_ACPI_PROCFS is not set +# CONFIG_ACPI_PROCFS_POWER is not set +# CONFIG_ACPI_PROC_EVENT is not set +# CONFIG_ACPI_SBS is not set +CONFIG_ACPI_THERMAL=y +CONFIG_ACPI_VIDEO=y +# CONFIG_ACPI_WMI is not set +CONFIG_AGP=y +# CONFIG_AGP_ALI is not set +# CONFIG_AGP_AMD is not set +# CONFIG_AGP_AMD64 is not set +# CONFIG_AGP_ATI is not set +# CONFIG_AGP_EFFICEON is not set +CONFIG_AGP_INTEL=y +# CONFIG_AGP_NVIDIA is not set +# CONFIG_AGP_SIS is not set +# CONFIG_AGP_SWORKS is not set +# CONFIG_AGP_VIA is not set +# CONFIG_APPLE_GMUX is not set +# CONFIG_APRICOT is not set +# CONFIG_ASUS_LAPTOP is not set +# CONFIG_AT1700 is not set +# CONFIG_BACKLIGHT_ADP8860 is not set +# CONFIG_BACKLIGHT_ADP8870 is not set +# CONFIG_BACKLIGHT_APPLE is not set +CONFIG_BACKLIGHT_CLASS_DEVICE=y +CONFIG_BACKLIGHT_GENERIC=y +CONFIG_BACKLIGHT_LCD_SUPPORT=y +# CONFIG_BACKLIGHT_SAHARA is not set +CONFIG_BLK_DEV_SR=y +# CONFIG_BLK_DEV_SR_VENDOR is not set +# CONFIG_BLK_DEV_XD is not set +CONFIG_CHROMEOS_LAPTOP=n +CONFIG_CONSOLE_TRANSLATIONS=y +CONFIG_CPU_IDLE_GOV_MENU=y +# CONFIG_DEPCA is not set +CONFIG_DMA_SHARED_BUFFER=y +CONFIG_DMI=y +# CONFIG_DMIID is not set +# CONFIG_DMI_SYSFS is not set +CONFIG_DRM=y +# CONFIG_DRM_AST is not set +# CONFIG_DRM_CIRRUS_QEMU is not set +# CONFIG_DRM_GMA500 is not set +# CONFIG_DRM_I2C_CH7006 is not set +# CONFIG_DRM_I2C_NXP_TDA998X is not set +# CONFIG_DRM_I2C_SIL164 is not set +# CONFIG_DRM_I810 is not set +CONFIG_DRM_I915=y +CONFIG_DRM_I915_KMS=y +CONFIG_DRM_KMS_HELPER=y +# CONFIG_DRM_LOAD_EDID_FIRMWARE is not set +# CONFIG_DRM_MGA is not set +# CONFIG_DRM_MGAG200 is not set +# CONFIG_DRM_NOUVEAU is not set +# CONFIG_DRM_QXL is not set +# CONFIG_DRM_R128 is not set +# CONFIG_DRM_RADEON is not set +# CONFIG_DRM_SAVAGE is not set +# CONFIG_DRM_SIS is not set +# CONFIG_DRM_TDFX is not set +# CONFIG_DRM_UDL is not set +# CONFIG_DRM_VIA is not set +# CONFIG_DRM_VMWGFX is not set +CONFIG_DUMMY_CONSOLE=y +# CONFIG_EFI is not set +# CONFIG_EISA is not set +# CONFIG_EL1 is not set +# CONFIG_EL16 is not set +# CONFIG_EL2 is not set +# CONFIG_EL3 is not set +# CONFIG_ELPLUS is not set +CONFIG_FB=y +CONFIG_FB_CFB_COPYAREA=y +CONFIG_FB_CFB_FILLRECT=y +CONFIG_FB_CFB_IMAGEBLIT=y +# CONFIG_FB_I810 is not set +# CONFIG_FB_VESA is not set +# CONFIG_FB_WMT_GE_ROPS is not set +# CONFIG_FONTS is not set +CONFIG_FONT_8x16=y +CONFIG_FONT_8x8=y +CONFIG_FRAMEBUFFER_CONSOLE=y +CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y +# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set +# CONFIG_FUJITSU_LAPTOP is not set +# CONFIG_GEOS is not set +CONFIG_HID=y +CONFIG_HID_BATTERY_STRENGTH=y +CONFIG_HPET=y +CONFIG_HPET_MMAP=y +# CONFIG_HP_ACCEL is not set +CONFIG_HW_CONSOLE=y +CONFIG_I2C=y +CONFIG_I2C_ALGOBIT=y +CONFIG_I2C_BOARDINFO=y +CONFIG_INPUT=y +CONFIG_INPUT_KEYBOARD=y +CONFIG_INPUT_MOUSE=y +CONFIG_INPUT_MOUSEDEV=y +CONFIG_INPUT_MOUSEDEV_PSAUX=y +CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 +CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 +CONFIG_INTEL_IDLE=y +# CONFIG_INTEL_IPS is not set +# CONFIG_INTEL_MENLOW is not set +CONFIG_ISA=y +CONFIG_ISAPNP=y +CONFIG_ISO9660_FS=y +# CONFIG_JOLIET is not set +CONFIG_KEYBOARD_ATKBD=y +# CONFIG_LANCE is not set +# CONFIG_LCD_CLASS_DEVICE is not set +# CONFIG_LEDS_CLEVO_MAIL is not set +# CONFIG_MDA_CONSOLE is not set +# CONFIG_MIXCOMWD is not set +# CONFIG_MOUSE_BCM5974 is not set +# CONFIG_MOUSE_CYAPA is not set +CONFIG_MOUSE_PS2=y +CONFIG_MOUSE_PS2_ALPS=y +# CONFIG_MOUSE_PS2_CYPRESS is not set +# CONFIG_MOUSE_PS2_ELANTECH is not set +CONFIG_MOUSE_PS2_LIFEBOOK=y +CONFIG_MOUSE_PS2_LOGIPS2PP=y +CONFIG_MOUSE_PS2_SYNAPTICS=y +# CONFIG_MOUSE_PS2_TOUCHKIT is not set
[OpenWrt-Devel] [PATCH 3/3] [x86] add EBOX-3300 target
Fix enumeration problem with r6040 ethernet controller. Bug and fix described here: https://bugzilla.kernel.org/show_bug.cgi?id=64081 Signed-off-by: Kamil Wcislo mek@gmail.com --- diff --git a/target/linux/x86/patches-3.10/180-rdc-r6040-fix.patch b/target/linux/x86/patches-3.10/180-rdc-r6040-fix.patch new file mode 100644 index 000..2d7fb47 --- /dev/null +++ b/target/linux/x86/patches-3.10/180-rdc-r6040-fix.patch @@ -0,0 +1,11 @@ +--- a/drivers/net/ethernet/rdc/r6040.c b/drivers/net/ethernet/rdc/r6040.c +@@ -144,7 +144,7 @@ + #define MBCR_DEFAULT 0x012A /* MAC Bus Control Register */ + #define MCAST_MAX 3 /* Max number multicast addresses to filter */ + +-#define MAC_DEF_TIMEOUT 2048/* Default MAC read/write operation timeout */ ++#define MAC_DEF_TIMEOUT 4096/* Default MAC read/write operation timeout */ + + /* Descriptor status */ + #define DSC_OWNER_MAC 0x8000 /* MAC is the owner of this descriptor */ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] platform xburst / maintainer
* Mirko Vogt mi...@openwrt.org [28.10.2014 22:56]: hi mirko, That was a long time ago and I guess we should consider that platform currently unmaintained. May I ask what's your interest in this platform? i just wanted show look, which arch/endianness this is and missed it, so nothing really important and i wondered... bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] lantiq_dsl.sh: properly detect vdsl_cpe_control and add missing quotes
lantiq_dsl.sh didn't work with VDSL chipsets for now, fix that by
detecting whether vdsl_cpe_control or dsl_cpe_control should be used.
Also add missing quotes around shell string comparision.
Signed-off-by: Daniel Golle dan...@makrotopia.org
---
target/linux/lantiq/base-files/lib/functions/lantiq_dsl.sh | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/target/linux/lantiq/base-files/lib/functions/lantiq_dsl.sh
b/target/linux/lantiq/base-files/lib/functions/lantiq_dsl.sh
index e817fdd..56b8652 100644
--- a/target/linux/lantiq/base-files/lib/functions/lantiq_dsl.sh
+++ b/target/linux/lantiq/base-files/lib/functions/lantiq_dsl.sh
@@ -1,7 +1,11 @@
#!/bin/sh /etc/rc.common
-# Copyright (C) 2012 OpenWrt.org
+# Copyright (C) 2012-2014 OpenWrt.org
-XDSL_CTRL=dsl_cpe_control
+if [ $( which vdsl_cpe_control ) ]; then
+ XDSL_CTRL=vdsl_cpe_control
+else
+ XDSL_CTRL=dsl_cpe_control
+fi
#
# Basic functions to send CLI commands to the vdsl_cpe_control daemon
@@ -212,7 +216,7 @@ line_state() {
*) s=unknown ;;
esac
- if [ $action = lucistat ]; then
+ if [ $action = lucistat ]; then
echo dsl.line_state_num=$ls
echo dsl.line_state_detail=\$s\
if [ $ls = 0x801 ]; then
--
2.1.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] WeIO - Web of Things Platform
FYI, WeIO (http://we-io.net/) is new OpenWrt (Barrier Breaker) powered development board for rapid prototyping and IoT, based on Carambola 2 module (Atheros AR9331 CPU). It has a good Indiegogo success so far: https://www.indiegogo.com/projects/weio-platform-for-web-of-things, and source code of the main app is here: https://github.com/nodesign/weio, while BSP is here: https://github.com/nodesign/openwrt (currently working on set of patches to be pushed to upstream soon). We hope that this project will lead to further popularization of OpenWrt, as so far we are quite satisfied with results and performance. BR, Drasko ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Issues with MTD parsing in absence of rootfs - Proposed patch, advice please
Hi All, As some of you will be aware I have been working on an initramfs only image with no lzma-loader, used to kexec main kernel from external storage on a bcrm47xx based router (Netgear WNR3500L v1). I have encountered two unpleasant issues: 1. The parsing routines in bcm47xxpart.c do not currently cope with a non-existent rootfs, i.e. one where the trx header shows zero relative offset after the main linux image. the result is thus: [1.04] 7 bcm47xxpart partitions found on MTD device bcm47xxsflash [1.05] Creating 7 MTD partitions on bcm47xxsflash: [1.06] 0x-0x0004 : boot [1.06] 0x0004-0x007d : firmware [1.07] 0x0004001c-0x0004 : linux [1.08] mtd: partition linux must either start or end on erase block boundary or be smaller than an erase block -- forcing read-only [1.09] 0x0004-0x007d : rootfs [1.10] mtd: device 3 (rootfs) set to be root filesystem [1.11] mtdsplit: no squashfs found in rootfs [1.11] mtdsplit: no squashfs found in bcm47xxsflash [1.12] 0x007d-0x007e : POT [1.13] 0x007e-0x007f : board_data [1.13] 0x007f-0x0080 : nvram root@MiniWrt:/# cat /proc/mtd dev:size erasesize name mtd0: 0004 0001 boot mtd1: 0079 0001 firmware mtd2: ffe4 0001 linux OUCH! My kernel currently occupies negative space??? mtd3: 0079 0001 rootfs mtd4: 0001 0001 POT mtd5: 0001 0001 board_data mtd6: 0001 0001 nvram 2. The current trunk build includes a first run script (/etc/uci-defaults/09_fix_crc) that indiscriminately calls mtd fixtrx. With my type of set up mtd fixtrx completely screws over the partition table bricking the router. I have not investigated far enough yet to determine if (2) is caused purely by (1), but it's certainly not going to help. My question is, should I: a) patch bcm47xxpart.c to not add a rootfs partition if the offset is zero b) patch bcm47xxpart.c to not add a 'fake' rootfs partition after the linux partition c) munge the build process to add an empty rootfs partition to my initramfs image. Any thoughts please? I'd like to avoid wasting too much of everybody's valuable time generating bad patches. Stephen Parry ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
