Re: [OpenWrt-Devel] [PATCH] ramips: set mips16 support

[José Vázquez]

2016-01-04 13:02 GMT+01:00, Cristian Morales Vega :
> Signed-off-by: Cristian Morales Vega 
> ---
>  target/linux/ramips/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/target/linux/ramips/Makefile b/target/linux/ramips/Makefile
> index 9d7bb5b..378e2f5 100644
> --- a/target/linux/ramips/Makefile
> +++ b/target/linux/ramips/Makefile
> @@ -10,7 +10,7 @@ ARCH:=mipsel
>  BOARD:=ramips
>  BOARDNAME:=Ralink RT288x/RT3xxx
>  SUBTARGETS:=rt305x mt7620 mt7621 mt7628 mt7688 rt3883 rt288x
> -FEATURES:=squashfs gpio
> +FEATURES:=squashfs gpio mips16
>  MAINTAINER:=John Crispin 
>
>  KERNEL_PATCHVER:=4.3
> --
> 2.5.0

AFAIK the RT288X family do not support mips16 (they have a MIPS 4KEc
cpu if I'm not wrong).
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] bcm5357 wireless support

[José Vázquez Fernández]

I have a Linksys E1000 with a BCM5357 SoC but the wifi is not supported in b43 
nor brcmsmac, and 
bcmdhd is not an option. Will it be supported in a future?

Regards:

José Vázquez 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] bcm5357 wireless support

[José Vázquez]

2015-11-30 13:56 GMT+01:00, Rafał Miłecki <zaj...@gmail.com>:
> On 30 November 2015 at 12:47, José Vázquez Fernández
> <ppvazquez...@gmail.com> wrote:
>> I have a Linksys E1000 with a BCM5357 SoC but the wifi is not supported in
>> b43 nor brcmsmac, and
>> bcmdhd is not an option. Will it be supported in a future?
>
> Take a look at:
> https://wireless.wiki.kernel.org/en/users/drivers/b43/soc
>
Yes, I've read that.

> This chipset uses unsupported radio model. There isn't any PCIe board
> with this chipset we could use for RE with mmiotrace.
>
> --
> Rafał
>
So support for BCM5357 with those radios will not be possible for now.
That's a pity.

Thanks:

José
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 3/5] brcm63xx: lzma-loader: add BCM3380 support

[José Vázquez]

2015-10-09 22:52 GMT+02:00, Álvaro Fernández Rojas :
> Not yet, also my patches for the kernel are based on yours, so maybe you
> should submit them, since you were the first one to implement the support.
> BTW, I boot tested bmips on BCM3380 with the following changes:
> https://github.com/openwrt-es/openwrt/commit/3c72e4dc2b2bf21f3b1a7ef412fdb60753febae1
> https://github.com/openwrt-es/openwrt/commits/bmips-4.1
> But I have to say it's painfully slow, because it takes like 150s to
> fully boot on 1 CPU and 400+ on 2CPU :/.
>
> And about bmips target, Jonas wants to add it as a brcm63xx subtarget in
> the future.
>
> Regards,
> Álvaro.
>
According to the CG3100 source code the BCM3380 uses only spi flash
and does not have hsspi but legacy spi like 6368, 6358 and others, but
with a max speed of 25MHz, which is not defined in .
This is a piece of code found in spiflash.c:

#if defined(CONFIG_BCM93380)
spi_flash_busnum = LEG_SPI_BUS_NUM;
spi_flash_clock = 2500;
#endif
#if defined(CONFIG_BCM93383)
spi_flash_busnum = HS_SPI_BUS_NUM;
#endif

IMHO bcm63xx patches #345 and #411 are related with the slow boot
speed you are experiencing. I have no idea if BCM3380 supports other
spi clocks.

Regards:

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

[OpenWrt-Devel] [PATCH] [LANTIQ] ARV7519RW22 dts fix

[José Vázquez Fernández]

>From a9d8a4d04c5564abb0440a3b67dd21e8645e2c43 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jos=C3=A9=20V=C3=A1zquez=20Fern=C3=A1ndez?=
 
Date: Tue, 1 Sep 2015 19:30:26 +0200
Subject: [OpenWrt-Devel] [PATCH] [LANTIQ] ARV7519RW22 dts fix

The ARV7519RW22 has only one flash chip.
This patch fixes a detection issue of the mtd partitions that cause the
kernel not to be able to find rootfs.

Signed off by: 
---
 target/linux/lantiq/dts/ARV7519RW22.dts |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/lantiq/dts/ARV7519RW22.dts
b/target/linux/lantiq/dts/ARV7519RW22.dts
index 6823753..10ce8c9 100644
--- a/target/linux/lantiq/dts/ARV7519RW22.dts
+++ b/target/linux/lantiq/dts/ARV7519RW22.dts
@@ -18,7 +18,7 @@
nor-boot@0 {
compatible = "lantiq,nor";
bank-width = <2>;
-   reg = <0 0x0 0x200>, <1 0x200 
0x200>;
+   reg = <0 0x0 0x200>;
#address-cells = <1>;
#size-cells = <1>;
 
-- 
1.7.10.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] [LANTIQ] [CC] ARV7519RW22 dts fix

[José Vázquez Fernández]

>From d9de074b635e8d9442409922f867d1ed8dd36887 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jos=C3=A9=20V=C3=A1zquez=20Fern=C3=A1ndez?=
 
Date: Wed, 2 Sep 2015 13:40:28 +0200
Subject: [OpenWrt-Devel] [PATCH] [LANTIQ] ARV7519RW22 dts fix

The ARV7519RW22 has only one flash chip.
This patch fixes a detection issue of the mtd partitions that cause the
kernel not to be able to find rootfs.

Signed off by: 
---
 target/linux/lantiq/dts/ARV7519RW22.dts |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/lantiq/dts/ARV7519RW22.dts
b/target/linux/lantiq/dts/ARV7519RW22.dts
index 6823753..10ce8c9 100644
--- a/target/linux/lantiq/dts/ARV7519RW22.dts
+++ b/target/linux/lantiq/dts/ARV7519RW22.dts
@@ -18,7 +18,7 @@
nor-boot@0 {
compatible = "lantiq,nor";
bank-width = <2>;
-   reg = <0 0x0 0x200>, <1 0x200 
0x200>;
+   reg = <0 0x0 0x200>;
#address-cells = <1>;
#size-cells = <1>;
 
-- 
1.7.10.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] How to track IO usage of internal flash mtd partitions?

[José Vázquez]

2015-05-18 13:57 GMT+02:00, valent.turko...@gmail.com
valent.turko...@gmail.com:
 Looks like iostat only tracks block devices so I can see change for
 usb flash device but no change for internal flash partitions :(

 # iostat
 Linux 3.10.49 (Demo36_Muc (Base9)) 05/18/15 _mips_ (1 CPU)

 avg-cpu:  %user   %nice %system %iowait  %steal   %idle
5.340.001.470.000.00   93.19

 Device:tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
 mtdblock0 0.00 0.00 0.00208  0
 mtdblock1 0.00 0.00 0.00208  0
 mtdblock2 0.00 0.00 0.00208  0
 mtdblock3 0.00 0.00 0.00208  0
 mtdblock4 0.00 0.04 0.00  12240  0
 mtdblock5 0.00 0.00 0.00208  0
 mtdblock6 0.00 0.00 0.00208  0
 mmcblk0   0.02 0.03 0.21   9786  69721


 Any ideas?

 On 18 May 2015 at 11:45, José Vázquez ppvazquez...@gmail.com wrote:
 Try iostat (selectable in busybox). Maybe is what are you looking for.

Try dstat. you can select it in the utilities menu.
http://dag.wiee.rs/home-made/dstat/

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

Re: [OpenWrt-Devel] How to track IO usage of internal flash mtd partitions?

[José Vázquez]

Try iostat (selectable in busybox). Maybe is what are you looking for.

2015-05-17 0:40 GMT+02:00, valent.turko...@gmail.com
valent.turko...@gmail.com:
 Here is some interesting info I found using mtdinfo tool:

 # mtdinfo /dev/mtd5
 mtd5
 Name:   rootfs_data
 Type:   nor
 Eraseblock size:65536 bytes, 64.0 KiB
 Amount of eraseblocks:  104 (6815744 bytes, 6.5 MiB)
 Minimum input/output unit size: 1 byte
 Sub-page size:  1 byte
 Character device major/minor:   90:10
 Bad blocks are allowed: false
 Device is writable: true

 So I see there are 104 eraseblocks on this partition. Interesting so
 see finaly some numbers. Now how to see how many times these
 eraseblock were issued erase eraseblock command?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [RFC] Mips SIMD architecture (MSA)

[José Vázquez]

As far i can understand MSA is a feature that is only present in the
MIPS Warrior cores and, for now, seems that could be only needed in
malta [1] target.
As you can see in arch/mips/Kconfig MIPS32R2 and MIPS64R2 select
CPU_SUPPORTS_MSA which does not apply to the majority of the mips
targets in OpenWRT.
Deleting select CPU_SUPPORTS_MSA in [2] and [3] and changing [4]
with depends CPU_MIPS32_R2 || CPU_MIPS64_R2 will make MSA selectable
and should make the kernel smaller.

[1]https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/arch/mips/Kconfig?id=refs/tags/v3.18.11#n311
[2]https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/arch/mips/Kconfig?id=refs/tags/v3.18.11#n1256
[3]https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/arch/mips/Kconfig?id=refs/tags/v3.18.11#n1290
[4]https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/arch/mips/Kconfig?id=refs/tags/v3.18.11#n2135

Regards:

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

Re: [OpenWrt-Devel] [RFC] Mips SIMD architecture (MSA)

[José Vázquez]

2015-04-13 11:15 GMT+02:00, Paul Burton paul.bur...@imgtec.com:
 On Mon, Apr 13, 2015 at 10:54:05AM +0200, José Vázquez wrote:
 As far i can understand MSA is a feature that is only present in the
 MIPS Warrior cores and, for now, seems that could be only needed in
 malta [1] target.
 As you can see in arch/mips/Kconfig MIPS32R2 and MIPS64R2 select
 CPU_SUPPORTS_MSA which does not apply to the majority of the mips
 targets in OpenWRT.
 Deleting select CPU_SUPPORTS_MSA in [2] and [3] and changing [4]
 with depends CPU_MIPS32_R2 || CPU_MIPS64_R2 will make MSA selectable
 and should make the kernel smaller.

 Hello,

 I'm not sure I understand the problem here - CPU_HAS_MSA should already
 be configurable via Kconfig, so you can just disable it if you don't
 need it (as indicated in the Kconfig help text). The CPU_SUPPORTS_MSA
 entries are there just to enforce that you can only enable CPU_HAS_MSA
 on a system which might possibly include MSA (ie. MIPSr2+, well really
 MIPSr5+).

 In essence, the fact that your system selects CPU_SUPPORTS_MSA shouldn't
 increase the size of your kernel unless you also enable the configurable
 CPU_HAS_MSA. Am I missing something?

 Thanks,
 Paul

 [1]https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/arch/mips/Kconfig?id=refs/tags/v3.18.11#n311
 [2]https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/arch/mips/Kconfig?id=refs/tags/v3.18.11#n1256
 [3]https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/arch/mips/Kconfig?id=refs/tags/v3.18.11#n1290
 [4]https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/arch/mips/Kconfig?id=refs/tags/v3.18.11#n2135

 Regards:

 Pepe

MSA is not selectable if in Kconfig the target selects
SYS_HAS_CPU_MIPS32_R2 or SYS_HAS_CPU_MIPS64_R2, like Lantiq, PMC_MSP,
Ralink and some others because of [2] and [3].
I.e., in the case of EVA it is only selected if SYS_HAS_CPU_MIPS32_R3_5.

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

Re: [OpenWrt-Devel] [RFC] Mips SIMD architecture (MSA)

[José Vázquez]

2015-04-13 12:28 GMT+02:00, Paul Burton paul.bur...@imgtec.com:
 On Mon, Apr 13, 2015 at 11:59:20AM +0200, José Vázquez wrote:
 2015-04-13 11:15 GMT+02:00, Paul Burton paul.bur...@imgtec.com:
  On Mon, Apr 13, 2015 at 10:54:05AM +0200, José Vázquez wrote:
  As far i can understand MSA is a feature that is only present in the
  MIPS Warrior cores and, for now, seems that could be only needed in
  malta [1] target.
  As you can see in arch/mips/Kconfig MIPS32R2 and MIPS64R2 select
  CPU_SUPPORTS_MSA which does not apply to the majority of the mips
  targets in OpenWRT.
  Deleting select CPU_SUPPORTS_MSA in [2] and [3] and changing [4]
  with depends CPU_MIPS32_R2 || CPU_MIPS64_R2 will make MSA selectable
  and should make the kernel smaller.
 
  Hello,
 
  I'm not sure I understand the problem here - CPU_HAS_MSA should already
  be configurable via Kconfig, so you can just disable it if you don't
  need it (as indicated in the Kconfig help text). The CPU_SUPPORTS_MSA
  entries are there just to enforce that you can only enable CPU_HAS_MSA
  on a system which might possibly include MSA (ie. MIPSr2+, well really
  MIPSr5+).
 
  In essence, the fact that your system selects CPU_SUPPORTS_MSA
  shouldn't
  increase the size of your kernel unless you also enable the
  configurable
  CPU_HAS_MSA. Am I missing something?
 
  Thanks,
  Paul
 
  [1]https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/arch/mips/Kconfig?id=refs/tags/v3.18.11#n311
  [2]https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/arch/mips/Kconfig?id=refs/tags/v3.18.11#n1256
  [3]https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/arch/mips/Kconfig?id=refs/tags/v3.18.11#n1290
  [4]https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/arch/mips/Kconfig?id=refs/tags/v3.18.11#n2135
 
  Regards:
 
  Pepe
 
 MSA is not selectable if in Kconfig the target selects
 SYS_HAS_CPU_MIPS32_R2 or SYS_HAS_CPU_MIPS64_R2, like Lantiq, PMC_MSP,
 Ralink and some others because of [2] and [3].
 I.e., in the case of EVA it is only selected if SYS_HAS_CPU_MIPS32_R3_5.

 Pepe

 ...but [2]  [3] both only select CPU_SUPPORTS_MSA, not CPU_HAS_MSA. You
 should still be able to disable CPU_HAS_MSA in your configuration.
 Nothing depends upon or selects CPU_HAS_MSA, so you should always be
 able to disable it regardless of the platform you build for.

 To take one of your examples I just checked out v3.18.11, started from
 the Lantiq xway_defconfig and ran menuconfig. MSA is disabled by default
 as expected, and can be enabled if ( only if) its dependency
 CONFIG_MIPS_O32_FP64_SUPPORT is enabled. Even when that is enabled MSA
 is still disabled by default.

 I still don't see what you're trying to do here - MSA can already always
 be disabled via Kconfig, and is automatically enforced disabled on
 systems where it doesn't make sense.

 Thanks,
 Paul

You are right. Sorry and thanks for the clarification.

Best regards:

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

[OpenWrt-Devel] Ralink RT63365 support?

[José Vázquez]

Reviewing a Ralink SDK seems that the RT63365 in the old Trendchip
SoCs so, is SoC too different to add support for it in the ramips
target?
I make this question because one spanish ISP is distributing the
Huawei HG532s to its customers, and maybe others around the world too.

Regards:

 José
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Why OpenWrt sucks?

[José Vázquez]

2015-03-09 23:28 GMT+01:00, David Lang da...@lang.hm:
 On Mon, 9 Mar 2015, José Vázquez wrote:

 OpenWRT is a linux distro oriented to networking so the kernel and
 drivers are important, but you must not forget that the init process
 (procd and related after AA) is one of the cores of this distro and
 makes it work. The most relevant packages are oriented to networking,
 but with the feeds you can make anything that you want, making it very
 versatile.
 Also we must take in mind that OpenWRT works with GPL drivers and code
 (only few are proprietary); I think that one of the main advantages of
 use them is that anybody can contribute, and IMHO, are easy to
 maintain.
 One of the performance penalties come with the network drivers: while
 proprietary drivers are tightly coupled with the hardware, the drivers
 developed by OpenWRT guys and collaborators should not be so
 complicated because when the kernel version is changed they can
 generate a lot of problems and headaches, while more generic drivers
 do not take advantage of all the hardware features, overloading the
 cpu with tasks that in stock firmwares are managed by specific
 subsystems that are faster for those specific tasks.

 there is no reason why the open drivers need to be slower than the
 proprietary
 ones. History has shown that with sufficient information, the open drivers
 end
 up being as fast, or faster than the proprietary ones. But it does take time
 and
 cooperation with the manufacturer to do this with the latest hardware.

 Open drivers can be modified along with the kernel to take advantage of the

 newest features in the kernel. Proprietary drivers are either written for
 one
 specific kernel, or with a shim layer that limits how well the driver can
 work
 with future kernels.

 David Lang

Sorry, big mistake. :(
You are right, open source drivers do not mean bad and/or incomplete drivers.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Why OpenWrt sucks?

[José Vázquez]

2015-03-09 21:02 GMT+01:00, valent.turko...@gmail.com
valent.turko...@gmail.com:
 Hi all,
 I see this or similar question of forums all the time and I have
 answered it few times. I suggest we open a wiki page and contribute an
 answer.

 Here is how I usually reply to similar questions, please give your
 comments in your replies:


 Why it OpenWrt slower than stock firmware? I can help by shining a bit
 of light onto this subject. I'm developing custom firwmares based on
 OpenWrt but I'm not OpenWrt developer, still as I have few years of
 experience with OpenWrt I can explain why sometimes performance sucks
 or there are some issues and bugs.

 OpenWrt has three main parts; linux kernel, software packages and
 wireless drivers. OpenWrt developers work on all of them. Consider the
 amount of code this is, and consider that all work is done by a
 handful of OpenWrt developers. If you work in software industry you
 know many people big companies hire to work on much smaller projects.
 So be thankful it works as good as it does, it is actually a miracle
 that it works as good as it does

OpenWRT is a linux distro oriented to networking so the kernel and
drivers are important, but you must not forget that the init process
(procd and related after AA) is one of the cores of this distro and
makes it work. The most relevant packages are oriented to networking,
but with the feeds you can make anything that you want, making it very
versatile.
Also we must take in mind that OpenWRT works with GPL drivers and code
(only few are proprietary); I think that one of the main advantages of
use them is that anybody can contribute, and IMHO, are easy to
maintain.
One of the performance penalties come with the network drivers: while
proprietary drivers are tightly coupled with the hardware, the drivers
developed by OpenWRT guys and collaborators should not be so
complicated because when the kernel version is changed they can
generate a lot of problems and headaches, while more generic drivers
do not take advantage of all the hardware features, overloading the
cpu with tasks that in stock firmwares are managed by specific
subsystems that are faster for those specific tasks.
 Main issue is that wifi chip manufacturers don't offer open source
 wifi drivers. If Atheros and Broadcom understood Open source as Intel
 does then you would get absolutely top speed and reliability from
 OpenWrt wifi drivers. You don't get top notch performance with OpenWrt
 because Atheros and Broadcom are choosing not release quality open
 source drivers.
Broadcom wireless drivers are poor (brcmfmac and brcmsmac),
Metalink/Lantiq wireless drivers do not exist and there are more sad
examples, but Atheros is collaborating. Of course the work and magic
that nbd and others make is wonderful.

 Linux, BSDx and OpenWrt developers can only use other means to get
 wifi devices to work, usually reverse engineering, and without support
 from wifi chip companies it is not easy to support all features, get
 awesome performance and stability.

 This is a long way of saying, that if performance sucks on OpenWrt you
 should blame Atheros and Broadcom for not giving you (OpenWrt
 community) high quality open source drivers!
I think that is important to mention that Lantiq and others use
OpenWRT as the base of their firms.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [RFC PATCH] mac80211: brcmfmac: separate SDIO and USB support

[José Vázquez]

2015-01-13 8:46 GMT+01:00, Zoltan HERPAI wigy...@uid0.hu:
 I haven't seen any flags that does SDIO_SUPPORT or something similar. It's
 either removing depend on USB_SUPPORT or add dependencies for the
 targets that'll use the SDIO part. Do you know of other approach?

 Thanks,
 -w-

You are right: there isn't SDIO_SUPPORT flag. I suggested to delete
sunxi dependency because maybe in the future will be support for other
boards that belong to different targets that will need sdio support to
make the wifi work.
Anyway, while only sunxi based boards need it, the patch can be left
as is to avoid confusion.

Regards:

Pepe

 On Tue, 13 Jan 2015, José Vázquez wrote:

 IMHO make sdio selecton depends only on sunxi is not a good idea.

 2015-01-07 20:37 GMT+01:00, Zoltan HERPAI wigy...@uid0.hu:
 This patch will add options to select SDIO and USB support in the
 brcmfmac
 driver, and not tie it to only support USB. As the driver doesn't build
 the host interface code into separate .ko, the required ones are
 selected
 via config options.

 PCIe support is not added now, can be added later. As of now, only sunxi
 would use the SDIO support for the Ampak modules.

 Signed-off-by: Zoltan HERPAI wigy...@uid0.hu
 ---
 Index: package/kernel/mac80211/Makefile
 ===
 --- package/kernel/mac80211/Makefile(revision 43857)
 +++ package/kernel/mac80211/Makefile(working copy)
 @@ -1477,17 +1477,36 @@

   define KernelPackage/brcmfmac
 $(call KernelPackage/mac80211/Default)
 -  TITLE:=Broadcom IEEE802.11n USB FullMAC WLAN driver
 +  TITLE:=Broadcom IEEE802.11n USB/SDIO FullMAC WLAN driver
 URL:=http://linuxwireless.org/en/users/Drivers/brcm80211
 -  DEPENDS+= @USB_SUPPORT +kmod-usb-core +kmod-cfg80211
 +@DRIVER_11N_SUPPORT
 +kmod-brcmutil
 +  DEPENDS+= @(USB_SUPPORT||TARGET_sunxi) +kmod-cfg80211
 +@DRIVER_11N_SUPPORT +kmod-brcmutil

 FILES:=$(PKG_BUILD_DIR)/drivers/net/wireless/brcm80211/brcmfmac/brcmfmac.ko
 AUTOLOAD:=$(call AutoProbe,brcmfmac)
   endef

   define KernelPackage/brcmfmac/description
 - Kernel module for Broadcom IEEE802.11n USB Wireless cards
 + Kernel module for Broadcom IEEE802.11n USB/SDIO Wireless cards
   endef

 +define KernelPackage/brcmfmac/config
 +if PACKAGE_kmod-brcmfmac
 +
 +   config PACKAGE_BRCMFMAC_SDIO
 +   depends TARGET_sunxi
 +   bool Broadcom FullMAC SDIO support
 +   help
 +   Say Y if you want to enable SDIO support for the 
 brcmfmac
 driver.
 +
 +   config PACKAGE_BRCMFMAC_USB
 +   select PACKAGE_kmod-usb-core
 +   default y
 +   bool Broadcom FullMAC USB support
 +   help
 +   Say Y if you want to enable USB support for the 
 brcmfmac driver.
 +
 +endif
 +endef
 +
   config_package=$(if $(CONFIG_PACKAGE_kmod-$(1)),m)

   config-y:= \
 @@ -1558,8 +1577,9 @@
   config-$(call config_package,brcmutil) += BRCMUTIL
   config-$(call config_package,brcmsmac) += BRCMSMAC
   config-$(call config_package,brcmfmac) += BRCMFMAC
 -config-y += BRCMFMAC_USB
 +config-$(CONFIG_PACKAGE_BRCMFMAC_USB) += BRCMFMAC_USB
   config-$(CONFIG_PACKAGE_BRCM80211_DEBUG) += BRCMDBG
 +config-$(CONFIG_PACKAGE_BRCMFMAC_SDIO) += BRCMFMAC_SDIO

   config-$(call config_package,mac80211-hwsim) += MAC80211_HWSIM

 @@ -1969,12 +1989,25 @@

   define KernelPackage/brcmfmac/install
 $(INSTALL_DIR) $(1)/lib/firmware/brcm
 +ifeq ($(CONFIG_PACKAGE_BRCMFMAC_USB),y)
 $(INSTALL_DATA) \
 
 $(PKG_BUILD_DIR)/$(PKG_LINUX_FIRMWARE_SUBDIR)/brcm/brcmfmac43236b.bin
 \
 $(1)/lib/firmware/brcm/
 $(INSTALL_DATA) \
 
 $(PKG_BUILD_DIR)/$(PKG_LINUX_FIRMWARE_SUBDIR)/brcm/brcmfmac43143.bin
 \
 $(1)/lib/firmware/brcm/
 +endif
 +ifeq ($(CONFIG_PACKAGE_BRCMFMAC_SDIO),y)
 +   $(INSTALL_DATA) \
 +   
 $(PKG_BUILD_DIR)/$(PKG_LINUX_FIRMWARE_SUBDIR)/brcm/brcmfmac4329-sdio.bin
 \
 +   $(1)/lib/firmware/brcm/
 +   $(INSTALL_DATA) \
 +   
 $(PKG_BUILD_DIR)/$(PKG_LINUX_FIRMWARE_SUBDIR)/brcm/brcmfmac4330-sdio.bin
 \
 +   $(1)/lib/firmware/brcm/
 +   $(INSTALL_DATA) \
 +   
 $(PKG_BUILD_DIR)/$(PKG_LINUX_FIRMWARE_SUBDIR)/brcm/brcmfmac43362-sdio.bin
 \
 +   $(1)/lib/firmware/brcm/
 +endif
   endef

   $(eval $(call KernelPackage,adm8211))
 ___
 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] support for Sagemcom F@ST2804V7

[José Vázquez]

Take a look at this patch:
http://patchwork.openwrt.org/patch/6751/
First of all you need to find your router's board id.

If changing the board id CFE works then you have a some kind of solution.

2014-12-16 9:26 GMT+01:00, Eugene jek...@yandex.ru:
 Hello,

 Is it possible to add support for Sagemcom F@ST2804V7 ?

 I tried openwr...@st2704v2-squashfs-cfe.bin and some others
 (barrier_breaker) on it,
 bootlog (via serial port) says: Kernel panic - not syncing: unable to
 detect bcm963xx board.

 If it is possible, i will supply all required information/data.

 P.S. Openwrt works if I change board ID in CFE to F@ST2704V2(with 'b'
 command)

 Best regards,
 Eugene
 ___
 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][modules] Add support for Realtek r8712 and RTL8192SU.

[José Vázquez Fernández]

Add support for Realtek r8712 and RTL8192SU family.

This patch adds support for Realtek r8712 and
RTL8188SU/RTL8191SU/RTL8192SU family of fullmac usb wireless cards.
The r8712u staging driver only supports WEXT but works with no problems
in OpenWRT.

Signed off by: José Vázquez Fernández ppvazquez...@gmail.com

Index: package/kernel/linux/modules/wireless.mk
===
--- package/kernel/linux/modules/wireless.mk(revisión: 43720)
+++ package/kernel/linux/modules/wireless.mk(copia de trabajo)
@@ -126,3 +126,35 @@
 
 $(eval $(call KernelPackage,net-rtl8188eu))
 
+define KernelPackage/net-rtl8192su
+  SUBMENU:=$(WIRELESS_MENU)
+  TITLE:=RTL8192SU support (staging)
+  DEPENDS:=@USB_SUPPORT +@DRIVER_WEXT_SUPPORT +kmod-usb-core
+  KCONFIG:=\
+   CONFIG_STAGING=y \
+   CONFIG_R8712U
+  FILES:=$(LINUX_DIR)/drivers/staging/rtl8712/r8712u.ko
+  AUTOLOAD:=$(call AutoProbe,r8712u)
+endef
+
+define KernelPackage/net-rtl8192su/description
+ Kernel modules for RealTek RTL8712 and RTL81XXSU fullmac support.
+ 
+endef
+# R8712 FullMAC firmware
+R8712_FW:=rtl8712u.bin
+
+define Download/net-rtl8192su
+  FILE:=$(R8712_FW)
+
URL:=http://mirrors.arizona.edu/raspbmc/downloads/bin/lib/wifi/rtlwifi/
+#  MD5SUM:=8bd4310971772a486b9784c77f8a6df9
+endef
+
+define KernelPackage/net-rtl8192su/install
+   $(INSTALL_DIR) $(1)/lib/firmware/rtlwifi
+   $(INSTALL_DATA) $(DL_DIR)/$(R8712_FW) $(1)/lib/firmware/rtlwifi/
+endef
+
+$(eval $(call Download,net-rtl8192su))
+$(eval $(call KernelPackage,net-rtl8192su))
+
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [Fwd: [PATCH][modules][V2] Add support for Realtek r8712 and RTL8192SU.]

[José Vázquez Fernández]

Add support for Realtek r8712 and RTL8192SU family.

This patch adds support for Realtek r8712 and
RTL8188SU/RTL8191SU/RTL8192SU family of fullmac usb wireless cards.
The r8712u staging driver only supports WEXT but works with no problems
in OpenWRT.
V2: added md5sum and fixed the patch.
Signed off by: José Vázquez Fernández ppvazquez...@gmail.com

Index: package/kernel/linux/modules/wireless.mk
===
--- package/kernel/linux/modules/wireless.mk(revisión: 43720)
+++ package/kernel/linux/modules/wireless.mk(copia de trabajo)
@@ -126,3 +126,35 @@
 
 $(eval $(call KernelPackage,net-rtl8188eu))
 
+define KernelPackage/net-rtl8192su
+  SUBMENU:=$(WIRELESS_MENU)
+  TITLE:=RTL8192SU support (staging)
+  DEPENDS:=@USB_SUPPORT +@DRIVER_WEXT_SUPPORT +kmod-usb-core
+  KCONFIG:=\
+   CONFIG_STAGING=y \
+   CONFIG_R8712U
+  FILES:=$(LINUX_DIR)/drivers/staging/rtl8712/r8712u.ko
+  AUTOLOAD:=$(call AutoProbe,r8712u)
+endef
+
+define KernelPackage/net-rtl8192su/description
+ Kernel modules for RealTek RTL8712 and RTL81XXSU fullmac support.
+ 
+endef
+# R8712 FullMAC firmware
+R8712_FW:=rtl8712u.bin
+
+define Download/net-rtl8192su
+  FILE:=$(R8712_FW)
+
+  URL:=http://mirrors.arizona.edu/raspbmc/downloads/bin/lib/wifi/rtlwifi/
+  MD5SUM:=8e6396b5844a3e279ae8679555dec3f0
+endef
+
+define KernelPackage/net-rtl8192su/install
+   $(INSTALL_DIR) $(1)/lib/firmware/rtlwifi
+   $(INSTALL_DATA) $(DL_DIR)/$(R8712_FW) $(1)/lib/firmware/rtlwifi/
+endef
+
+$(eval $(call Download,net-rtl8192su))
+$(eval $(call KernelPackage,net-rtl8192su))
+
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Mips Creator CI20 OpenWRT support.

[José Vázquez]

I've been working to add support for the CI20 to openwrt and, despite
some problems I'm unable to fix, the board works stable with openwrt
(more or less). :(
https://github.com/Pteridium/OpenWRT-CI20
Here is a bootlog:
http://pastebin.com/stM6Wfgz

As someone pointed the JZ4780 is not a very good SoC (even he said
CI20 is crap), but it performs better than I initially expected,
specially in few areas. Of course it haven't the performance of
PowerPC, Marvell or IPQ806X.

IMHO some drivers are not enough good and need to be improved (few of
them a lot, like irq), but as some of you know I haven't the skills to
make it.

Any advice will be very welcome.

Regards:

Pepe

2014-11-26 11:19 GMT+01:00, Zubair Lutfullah Kakakhel
zubair.kakak...@imgtec.com:
 Hi Jose,

 On 25/11/14 20:44, José Vázquez wrote:
 Few weeks ago i've received a Mips CI20 and began to port it to
 openwrt using kernel 3.18-rc4.
 For now only few peripherals work fine but is more than i initially
 expected.
 https://github.com/Pteridium/OpenWRT-experimental/blob/ci20-alpha/README.md
 Still there are a lot of peripherals to be included, but for initial
 tests is enough for me.

 The cpu performance is a bit disappointing if is taken in mind that
 runs at 1'2GHz and the ethernet tests with iperf showed 80Mb/s with
 one thread and 65 with 100.
 Compiling without generic patches 132-mips_inline_dma_ops,
 259-regmap_dynamic, 305-mips_module_reloc,
 306-mips_mem_functions_performance and 309-mips_fuse_workaround I were
 able to enable msc1 and test brcmfmac, but no success: the driver
 recognizes the bcm4330 but it is unable to configure it correctly.


 I've traced this all the way back to the dma driver :)

 For a working tree with wifi check out

 https://github.com/ZubairLK/CI20_linux/tree/wip-ci20-v3.16-wifi-bt

 Now i'm working to add the remaining drivers that work with kernel
 3.16. What i previously made was simple rebases from the code wrote by
 Zubair Lutfullah and Paul Burton with a couple of changes in pinctrl
 and dma drivers.

 Quite a few drivers with working code can be seen in my work-in-progress
 tree.

 https://github.com/ZubairLK/CI20_linux/tree/wip-ci20-v3.16-merge

 They should help.


 Any comment will be very appreciated.

 Great work on porting OpenWRT to the CI20 :)

 blog about it if you have one.

 Cheers,
 ZubairLK


 José


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

Re: [OpenWrt-Devel] Mips Creator CI20 OpenWRT support.

[José Vázquez]

2014-12-10 11:54 GMT+01:00, John Crispin blo...@openwrt.org:


 On 10/12/2014 11:46, José Vázquez wrote:
 I've been working to add support for the CI20 to openwrt and,
 despite some problems I'm unable to fix, the board works stable
 with openwrt (more or less). :(
 https://github.com/Pteridium/OpenWRT-CI20 Here is a bootlog:
 http://pastebin.com/stM6Wfgz

 As someone pointed the JZ4780 is not a very good SoC (even he said
 CI20 is crap), but it performs better than I initially expected,
 specially in few areas. Of course it haven't the performance of
 PowerPC, Marvell or IPQ806X.

 IMHO some drivers are not enough good and need to be improved (few
 of them a lot, like irq), but as some of you know I haven't the
 skills to make it.

 Any advice will be very welcome.


 assuming that mips sells this as the reference mips platform it is
 quite funny that there is no real linux support.
What do you want to mean with no real linux support?
I don't understand why Ingenic is not doing an effort to add better
linux support for recent kernels or even add JZ4775 and JZ4780 to the
mainstream kernel.

 i think you should ping imgtec about this and ask them what their
 roadmap is for giving real support for the hw. i know from imgtec that
 they used this pcb as it was the only one they could readily source at
 3-4k volume. its sort of the wrong way to select hardware. the result
 is what we see today. no drivers no real support and horrible network
 performance.
The network performance with the kernel 3.0.8 from Ingenic is sadly
horrible, but the tests made with kernel 3.18 show 75Mb/s with one
thread and 60Mb/s with 100 threads. I think it is a good improvement
if we take in mind how the DM9000 is attached to the SoC.

 btw, i pointed out that the pcb is crap not the SoC. please be precise
 when quoting me
Sorry, my fault. My apologies.
The pcb, of course, could be better, but with recent kernels it
becomes in something enough good for some purposes. The SoC itself...
some of you know it so nothing to say.

   John


 Regards:

 Pepe

 2014-11-26 11:19 GMT+01:00, Zubair Lutfullah Kakakhel
 zubair.kakak...@imgtec.com:
 Hi Jose,

 On 25/11/14 20:44, José Vázquez wrote:
 Few weeks ago i've received a Mips CI20 and began to port it
 to openwrt using kernel 3.18-rc4. For now only few peripherals
 work fine but is more than i initially expected.
 https://github.com/Pteridium/OpenWRT-experimental/blob/ci20-alpha/README.md


 Still there are a lot of peripherals to be included, but for initial
 tests is enough for me.

 The cpu performance is a bit disappointing if is taken in mind
 that runs at 1'2GHz and the ethernet tests with iperf showed
 80Mb/s with one thread and 65 with 100. Compiling without
 generic patches 132-mips_inline_dma_ops, 259-regmap_dynamic,
 305-mips_module_reloc, 306-mips_mem_functions_performance and
 309-mips_fuse_workaround I were able to enable msc1 and test
 brcmfmac, but no success: the driver recognizes the bcm4330 but
 it is unable to configure it correctly.


 I've traced this all the way back to the dma driver :)

 For a working tree with wifi check out

 https://github.com/ZubairLK/CI20_linux/tree/wip-ci20-v3.16-wifi-bt



 Now i'm working to add the remaining drivers that work with kernel
 3.16. What i previously made was simple rebases from the code
 wrote by Zubair Lutfullah and Paul Burton with a couple of
 changes in pinctrl and dma drivers.

 Quite a few drivers with working code can be seen in my
 work-in-progress tree.

 https://github.com/ZubairLK/CI20_linux/tree/wip-ci20-v3.16-merge

 They should help.


 Any comment will be very appreciated.

 Great work on porting OpenWRT to the CI20 :)

 blog about it if you have one.

 Cheers, ZubairLK


 José


 ___ 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][Kernel] unset NF_REJECT_IPV6 and PHY_SAMSUNG_USB2

[José Vázquez Fernández]

oldconfig kept asking for that config symbol...
PHY_SAMSUNG_USB2 depends on DWC2


diff --git a/target/linux/generic/config-3.18
b/target/linux/generic/config-3.18
index e0e2a0b..d014334 100644
--- a/target/linux/generic/config-3.18
+++ b/target/linux/generic/config-3.18
@@ -2560,6 +2560,7 @@ CONFIG_NF_NAT_IPV4=m
 # CONFIG_NF_NAT_SNMP_BASIC is not set
 # CONFIG_NF_NAT_TFTP is not set
 CONFIG_NF_REJECT_IPV4=m
+# CONFIG_NF_REJECT_IPV6 is not set
 # CONFIG_NF_TABLES is not set
 # CONFIG_NI52 is not set
 # CONFIG_NI65 is not set
@@ -2802,6 +2803,7 @@ CONFIG_PCI_SYSCALL=y
 # CONFIG_PHYS_ADDR_T_64BIT is not set
 # CONFIG_PHY_EXYNOS_DP_VIDEO is not set
 # CONFIG_PHY_EXYNOS_MIPI_VIDEO is not set
+# CONFIG_PHY_SAMSUNG_USB2 is not set
 # CONFIG_PID_IN_CONTEXTIDR is not set
 # CONFIG_PID_NS is not set
 CONFIG_PINCONF=y
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Mips Creator CI20 OpenWRT support.

[José Vázquez]

Few weeks ago i've received a Mips CI20 and began to port it to
openwrt using kernel 3.18-rc4.
For now only few peripherals work fine but is more than i initially expected.
https://github.com/Pteridium/OpenWRT-experimental/blob/ci20-alpha/README.md
Still there are a lot of peripherals to be included, but for initial
tests is enough for me.

The cpu performance is a bit disappointing if is taken in mind that
runs at 1'2GHz and the ethernet tests with iperf showed 80Mb/s with
one thread and 65 with 100.
Compiling without generic patches 132-mips_inline_dma_ops,
259-regmap_dynamic, 305-mips_module_reloc,
306-mips_mem_functions_performance and 309-mips_fuse_workaround I were
able to enable msc1 and test brcmfmac, but no success: the driver
recognizes the bcm4330 but it is unable to configure it correctly.

Now i'm working to add the remaining drivers that work with kernel
3.16. What i previously made was simple rebases from the code wrote by
Zubair Lutfullah and Paul Burton with a couple of changes in pinctrl
and dma drivers.

Any comment will be very appreciated.

José
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Does anyone have pspboot source code?

[José Vázquez]

Are you looking for the AR7 or Puma5 pspboot sources?

2014-09-03 11:58 GMT+02:00, zhenjun_...@icloudaegis.com
zhenjun_...@icloudaegis.com:
 Hi,
 I can't find valid link to download TI pspboot  source code.
 Any one can help me?



 zhenjun_...@icloudaegis.com

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

Re: [OpenWrt-Devel] [RFC] TI/Intel Puma5 target.

[José Vázquez]

2014-08-18 12:51 GMT+02:00, José Vázquez ppvazquez...@gmail.com:
 I think that could be interesting add a target for Puma5 cable SoCs
 family. There are tw targets: the most common is Avalanche and the
 other is Volcano (maybe only for cablemodems with one ethernet port
 and without WLAN).

 According to the info i could find the cpu is a 400MHz arm1176
 (ARMv6k) with VFP and C55x DSP for VoIP, that runs in big endian mode;
 seems that shares some features with TI Davinci, OMAP2 and/or Sitara.

 These are the embedded peripherals that, AFAIK, can be found inside the
 Puma5:
 - 3 timers. There is a 16 bit timer, but i don't know if it is a
 separate timer or only a mode for the three mentioned above.
 - Watchdog (seems to use AR7 driver according AVM bootlog).
 AVM_WATCHDOG: Watchdog Driver for AR7 Hardware.
 - 2xVNLYQ.
 - SPI (master and slave).
 - I2C (for tuner management according with some board schematics).
 - CPPI 4.1 (Communications Port Programming Interface). ... CPPI4
 common peripherals, including the CPPI 4 DMA Controller, the Queue
 Manager, and the Buffer Manager. Unlike TI Davinci ethernet
 driver/hardware uses CPPI 4.1.
 - 2xCPMAC (only one in Avalanche?).
 - CGPMAC (only present in Avalanche).
 - Packet proccessor.
 - GMII or RGMI.
 - MDIO bus.
 - Inventra USB 2.0 OTG like Davinci and OMAP SoCs.
 - Intd (interrupt distributor). TI Keystone has an intd but no idea if
 is the same found in Puma5.
 - Intc (interrupt controller).
 - PCI: absent, but is referenced in one header file.
 There are more peripherals but they have only interest for VoIP,
 DOCSIS and tuner.

 SDKs based in kernel 2.6.18 can be easily found, whereas FRITZ!Box
 6360 Cable is based in kernel 2.6.28 with AVM modifications.
 The most of the boards based in Puma5 use an Atheros switch and an
 ATH79 or Ralink SoC for wireless with their own RAM and flash. Some
 have an RTL8198 working like a switch and with a Realtek wireless chip
 (RTL8192xx).

 The most of the boards have a PSP-Uboot and others ADAM2.
 I have a Hitron BVW-3653 that is based in PSP-uboot and OpenRG, and an
 RT3052 with 8MB RAM without flash (the Ralink OS is loaded when
 booting) for testing purposes if somebody is interested in porting
 this SoC to OpenWRT.

 Regards:

  José Vázquez


Excuse for the double mail but the answers were not related with the
subject of the mail.
Any answer will be very appreciated (yes, no, maybe, ...).
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [RFC] TI/Intel Puma5 target.

[José Vázquez]

I think that could be interesting add a target for Puma5 cable SoCs
family. There are tw targets: the most common is Avalanche and the
other is Volcano (maybe only for cablemodems with one ethernet port
and without WLAN).

According to the info i could find the cpu is a 400MHz arm1176
(ARMv6k) with VFP and C55x DSP for VoIP, that runs in big endian mode;
seems that shares some features with TI Davinci, OMAP2 and/or Sitara.

These are the embedded peripherals that, AFAIK, can be found inside the Puma5:
- 3 timers. There is a 16 bit timer, but i don't know if it is a
separate timer or only a mode for the three mentioned above.
- Watchdog (seems to use AR7 driver according AVM bootlog).
AVM_WATCHDOG: Watchdog Driver for AR7 Hardware.
- 2xVNLYQ.
- SPI (master and slave).
- I2C (for tuner management according with some board schematics).
- CPPI 4.1 (Communications Port Programming Interface). ... CPPI4
common peripherals, including the CPPI 4 DMA Controller, the Queue
Manager, and the Buffer Manager. Unlike TI Davinci ethernet
driver/hardware uses CPPI 4.1.
- 2xCPMAC (only one in Avalanche?).
- CGPMAC (only present in Avalanche).
- Packet proccessor.
- GMII or RGMI.
- MDIO bus.
- Inventra USB 2.0 OTG like Davinci and OMAP SoCs.
- Intd (interrupt distributor). TI Keystone has an intd but no idea if
is the same found in Puma5.
- Intc (interrupt controller).
- PCI: absent, but is referenced in one header file.
There are more peripherals but they have only interest for VoIP,
DOCSIS and tuner.

SDKs based in kernel 2.6.18 can be easily found, whereas FRITZ!Box
6360 Cable is based in kernel 2.6.28 with AVM modifications.
The most of the boards based in Puma5 use an Atheros switch and an
ATH79 or Ralink SoC for wireless with their own RAM and flash. Some
have an RTL8198 working like a switch and with a Realtek wireless chip
(RTL8192xx).

The most of the boards have a PSP-Uboot and others ADAM2.
I have a Hitron BVW-3653 that is based in PSP-uboot and OpenRG, and an
RT3052 with 8MB RAM without flash (the Ralink OS is loaded when
booting) for testing purposes if somebody is interested in porting
this SoC to OpenWRT.

Regards:

 José Vázquez
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [RFC] TI/Intel Puma5 target.

[José Vázquez]

2014-08-18 15:19 GMT+02:00, Michael Richardson m...@sandelman.ca:

 José Vázquez ppvazquez...@gmail.com wrote:
  According to the info i could find the cpu is a 400MHz arm1176
  (ARMv6k) with VFP and C55x DSP for VoIP, that runs in big endian
 mode;
  seems that shares some features with TI Davinci, OMAP2 and/or Sitara.

 Seems to be too slow to operate enough counters for fq_codel, even if
 somehow
 it's fast enough to move 100Mb/s+ of traffic.

 --
 ]   Never tell me the odds! | ipv6 mesh networks
 [
 ]   Michael Richardson, Sandelman Software Works| network architect
 [
 ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails
 [


I have no idea how much fast it is, and you are right about unable to
move more than 100Mbps, but take in mind that OpenWRT is very
versatile and a lot of people use routers for other purposes than
routing, as you know.
If i had enough skills i would try to port it to kernel 3.3 or 3.10,
but i hadn't (mainly because i don't have enough knowledge of ARM and
the Puma5 code is a bit strange with a lot of Pal files that i don't
know what they are).
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [RFC] BCM63XX SMP: assign interrupts to one cpu rather than both

[José Vázquez]

Found this comment in a Broadcom source code that has an interesting
comment; in addition, danitool, testing different kernel command lines
found that forcing all the interrupts to CPUx the network throughput
was increased more than a 15% (as far i remember).

Any comment will be welcome.

Pepe

 .depth = 1,
 .lock = __SPIN_LOCK_UNLOCKED(irq_desc-lock),
 #ifdef CONFIG_SMP
+#if defined(CONFIG_MIPS_BRCM)
+   /* We don't have an interrupt controller to distribute 
interrupts, so
+   initially assign all interrupts to one cpu, then make explicit
adjustments if needed */
+   .affinity = CPU_MASK_CPU0
+#else
.affinity = CPU_MASK_ALL
 #endif
+#endif
}
 };
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [RFC] BCM63XX SMP: assign interrupts to one cpu rather than both

[José Vázquez]

I have sent it if it could help. The most the information the better the
choice.
danitool made the mentioned tests so ask him about the details.

Regards:

Pepe

El viernes, 4 de julio de 2014, Jonas Gorski j...@openwrt.org escribió:

 On Fri, Jul 4, 2014 at 12:46 PM, José Vázquez ppvazquez...@gmail.com
 javascript:; wrote:
  Found this comment in a Broadcom source code that has an interesting
  comment; in addition, danitool, testing different kernel command lines
  found that forcing all the interrupts to CPUx the network throughput
  was increased more than a 15% (as far i remember).
 
  Any comment will be welcome.

 I don't mind doing that if it increases network throughput. I have a
 patch lying around for doing it in a somewhat cleaner way, so I will
 commit that soonish.


 Jonas

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

Re: [OpenWrt-Devel] [PATCH] [LANTIQ] Add XWAY cpu-feature-overrides.h

[José Vázquez]

2014-07-02 23:46 GMT+02:00, thomas.lan...@lantiq.com thomas.lan...@lantiq.com:
 Hello José.

 cpu_has_veic should be left disabled (this is wrong also for Falcon)

 Thanks,
 Thomas

Thanks for the comment.
Is cpu_has_vint correct for XWAY SoCs? I added it because was defined
in the FALCON cpu-feature-overrides file and UGW defines
CPU_MIPSR2_IRQ_VI in the Kconfig.ifx.

Regards:

José
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] [LANTIQ][V2] Add XWAY cpu-feature-overrides.h

[José Vázquez Fernández]

Add XWAY cpu-feature-overrides.h file.

This patch adds cpu-feature-overrides.h file for the XWAY family, based
in the one in FALCON.
Because Amazon SE was deprecated, cpu_has_dsp and cpu_has_mips16 have
been set, while cpu_has_mipsmt has been undefined due to the lack of mt
ASE in the Danube.
With this file the kernel size is reduced about 30KB in the XWAY
subtarget.
Tested only in a Danube based router with no problems and with a little
improvement in the USB port when using mass storage devices and wireless
dongles.
Changes in V2: disabled cpu_has_veic because XWAY family lacks this
feature as pointed by Thomas Langer.

Signed off by: José Vázquez Fernández ppvazquez...@gmail.com


diff --git
a/target/linux/lantiq/patches-3.10/0036-MIPS-lantiq-xway-add-cpu-feature-override.patch
 
b/target/linux/lantiq/patches-3.10/0036-MIPS-lantiq-xway-add-cpu-feature-override.patch
new file mode 100644
index 000..5e9a9d2
--- a/arch/mips/include/asm/mach-lantiq/xway/cpu-feature-overrides.h
1970-01-01 01:00:00.0 +0100
+++ b/arch/mips/include/asm/mach-lantiq/xway/cpu-feature-overrides.h
2014-07-01 12:37:07.790313378 +0200
@@ -0,0 +1,58 @@
+/*
+ *  Lantiq XWAY specific CPU feature overrides
+ *
+ *  Copyright (C) 2014 José Vázquez Fernández
+ *
+ *  This file was derived from: include/asm-mips/cpu-features.h
+ * Copyright (C) 2003, 2004 Ralf Baechle
+ * Copyright (C) 2004 Maciej W. Rozycki
+ *
+ *  This program is free software; you can redistribute it and/or
modify it
+ *  under the terms of the GNU General Public License version 2 as
published
+ *  by the Free Software Foundation.
+ *
+ */
+#ifndef __ASM_MACH_XWAY_CPU_FEATURE_OVERRIDES_H
+#define __ASM_MACH_XWAY_CPU_FEATURE_OVERRIDES_H
+
+#define cpu_has_tlb1
+#define cpu_has_4kex   1
+#define cpu_has_3k_cache   0
+#define cpu_has_4k_cache   1
+#define cpu_has_tx39_cache 0
+#define cpu_has_sb1_cache  0
+#define cpu_has_fpu0
+#define cpu_has_32fpr  0
+#define cpu_has_counter1
+#define cpu_has_watch  1
+#define cpu_has_divec  1
+
+#define cpu_has_prefetch   1
+#define cpu_has_ejtag  1
+#define cpu_has_llsc   1
+
+#define cpu_has_dsp1
+#define cpu_has_mips16 1
+#define cpu_has_dsp2   0
+#define cpu_has_mdmx   0
+#define cpu_has_mips3d 0
+#define cpu_has_smartmips  0
+#define cpu_has_vz 0
+
+#define cpu_has_mips32r1   1
+#define cpu_has_mips32r2   1
+#define cpu_has_mips64r1   0
+#define cpu_has_mips64r2   0
+
+#define cpu_has_vint   1 /* MIPSR2 vectored interrupts */
+#define cpu_has_veic   0
+
+#define cpu_has_64bits 0
+#define cpu_has_64bit_zero_reg 0
+#define cpu_has_64bit_gp_regs  0
+#define cpu_has_64bit_addresses0
+
+#define cpu_dcache_line_size() 32
+#define cpu_icache_line_size() 32
+
+#endif /* __ASM_MACH_XWAY_CPU_FEATURE_OVERRIDES_H */
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] [LANTIQ][V2][resend] Add XWAY cpu-feature-overrides.h

[José Vázquez Fernández]

Add XWAY cpu-feature-overrides.h file.

This patch adds cpu-feature-overrides.h file for the XWAY family, based in the 
one in FALCON.
Because Amazon SE was deprecated, cpu_has_dsp and cpu_has_mips16 have been set, 
while cpu_has_mipsmt has been undefined due to the lack of mt ASE in the Danube.
With this file the kernel size is reduced about 30KB in the XWAY subtarget.
Tested only in a Danube based router with no problems and with a little 
improvement in the USB port when using mass storage devices and wireless 
dongles.

Changes in V2: disabled cpu_has_veic because XWAY family lacks this feature as 
pointed by Thomas Langer.

Resent because the mail client changed its behaviour since an update. 

Signed off by: José Vázquez Fernández ppvazquez...@gmail.com

--- a/arch/mips/include/asm/mach-lantiq/xway/cpu-feature-overrides.h
1970-01-01 01:00:00.0 +0100
+++ b/arch/mips/include/asm/mach-lantiq/xway/cpu-feature-overrides.h
2014-07-01 12:37:07.790313378 +0200
@@ -0,0 +1,58 @@
+/*
+ *  Lantiq XWAY specific CPU feature overrides
+ *
+ *  Copyright (C) 2014 José Vázquez Fernández
+ *
+ *  This file was derived from: include/asm-mips/cpu-features.h
+ * Copyright (C) 2003, 2004 Ralf Baechle
+ * Copyright (C) 2004 Maciej W. Rozycki
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License version 2 as published
+ *  by the Free Software Foundation.
+ *
+ */
+#ifndef __ASM_MACH_XWAY_CPU_FEATURE_OVERRIDES_H
+#define __ASM_MACH_XWAY_CPU_FEATURE_OVERRIDES_H
+
+#define cpu_has_tlb1
+#define cpu_has_4kex   1
+#define cpu_has_3k_cache   0
+#define cpu_has_4k_cache   1
+#define cpu_has_tx39_cache 0
+#define cpu_has_sb1_cache  0
+#define cpu_has_fpu0
+#define cpu_has_32fpr  0
+#define cpu_has_counter1
+#define cpu_has_watch  1
+#define cpu_has_divec  1
+
+#define cpu_has_prefetch   1
+#define cpu_has_ejtag  1
+#define cpu_has_llsc   1
+
+#define cpu_has_dsp1
+#define cpu_has_mips16 1
+#define cpu_has_dsp2   0
+#define cpu_has_mdmx   0
+#define cpu_has_mips3d 0
+#define cpu_has_smartmips  0
+#define cpu_has_vz 0
+
+#define cpu_has_mips32r1   1
+#define cpu_has_mips32r2   1
+#define cpu_has_mips64r1   0
+#define cpu_has_mips64r2   0
+
+#define cpu_has_vint   1 /* MIPSR2 vectored interrupts */
+#define cpu_has_veic   0
+
+#define cpu_has_64bits 0
+#define cpu_has_64bit_zero_reg 0
+#define cpu_has_64bit_gp_regs  0
+#define cpu_has_64bit_addresses0
+
+#define cpu_dcache_line_size() 32
+#define cpu_icache_line_size() 32
+
+#endif /* __ASM_MACH_XWAY_CPU_FEATURE_OVERRIDES_H */
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] [LANTIQ][V2][resend] Add XWAY cpu-feature-overrides.h

[José Vázquez]

2014-07-03 21:36 GMT+02:00, José Vázquez Fernández ppvazquez...@gmail.com:
 Add XWAY cpu-feature-overrides.h file.

 This patch adds cpu-feature-overrides.h file for the XWAY family, based in
 the one in FALCON.
 Because Amazon SE was deprecated, cpu_has_dsp and cpu_has_mips16 have been
 set, while cpu_has_mipsmt has been undefined due to the lack of mt ASE in
 the Danube.
 With this file the kernel size is reduced about 30KB in the XWAY subtarget.
 Tested only in a Danube based router with no problems and with a little
 improvement in the USB port when using mass storage devices and wireless
 dongles.

I do not have boards based in AR9 or VR9, so tests on those SoCs are
recommended if the patch is accepted.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] [LANTIQ] Add XWAY cpu-feature-overrides.h

[José Vázquez Fernández]

Add XWAY cpu-feature-overrides.h file.

This patch adds cpu-feature-overrides.h file for the XWAY family, based 
in the one in FALCON.
Because Amazon SE was deprecated, cpu_has_dsp and cpu_has_mips16 have 
been set, while cpu_has_mt has been undefined due to the lack of mt ASE 
in the Danube.

With this file the kernel size is reduced about 30KB in the XWAY subtarget.
Tested in a Danube based router with no problems and with a little 
improvement in the USB port when using mass storage devices and wireless 
dongles.


Signed off by: José Vázquez Fernández ppvazquez...@gmail.com


--- a/arch/mips/include/asm/mach-lantiq/xway/cpu-feature-overrides.h 
1970-01-01 01:00:00.0 +0100
+++ b/arch/mips/include/asm/mach-lantiq/xway/cpu-feature-overrides.h 
2014-07-01 12:37:07.790313378 +0200

@@ -0,0 +1,58 @@
+/*
+ *  Lantiq XWAY specific CPU feature overrides
+ *
+ *  Copyright (C) 2014 José Vázquez Fernández
+ *
+ *  This file was derived from: include/asm-mips/cpu-features.h
+ * Copyright (C) 2003, 2004 Ralf Baechle
+ * Copyright (C) 2004 Maciej W. Rozycki
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License version 2 as 
published

+ *  by the Free Software Foundation.
+ *
+ */
+#ifndef __ASM_MACH_XWAY_CPU_FEATURE_OVERRIDES_H
+#define __ASM_MACH_XWAY_CPU_FEATURE_OVERRIDES_H
+
+#define cpu_has_tlb1
+#define cpu_has_4kex   1
+#define cpu_has_3k_cache   0
+#define cpu_has_4k_cache   1
+#define cpu_has_tx39_cache 0
+#define cpu_has_sb1_cache  0
+#define cpu_has_fpu0
+#define cpu_has_32fpr  0
+#define cpu_has_counter1
+#define cpu_has_watch  1
+#define cpu_has_divec  1
+
+#define cpu_has_prefetch   1
+#define cpu_has_ejtag  1
+#define cpu_has_llsc   1
+
+#define cpu_has_dsp1
+#define cpu_has_mips16 1
+#define cpu_has_dsp2   0
+#define cpu_has_mdmx   0
+#define cpu_has_mips3d 0
+#define cpu_has_smartmips  0
+#define cpu_has_vz 0
+
+#define cpu_has_mips32r1   1
+#define cpu_has_mips32r2   1
+#define cpu_has_mips64r1   0
+#define cpu_has_mips64r2   0
+
+#define cpu_has_vint   1 /* MIPSR2 vectored interrupts */
+#define cpu_has_veic   1 /* MIPSR2 external interrupt controller mode 
*/
+
+#define cpu_has_64bits 0
+#define cpu_has_64bit_zero_reg 0
+#define cpu_has_64bit_gp_regs  0
+#define cpu_has_64bit_addresses0
+
+#define cpu_dcache_line_size() 32
+#define cpu_icache_line_size() 32
+
+#endif /* __ASM_MACH_XWAY_CPU_FEATURE_OVERRIDES_H */
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] [LANTIQ] Add XWAY cpu-feature-overrides.h

[José Vázquez Fernández]

On 02/07/14 21:49, José Vázquez Fernández wrote:

Add XWAY cpu-feature-overrides.h file.

This patch adds cpu-feature-overrides.h file for the XWAY family, based
in the one in FALCON.
Because Amazon SE was deprecated, cpu_has_dsp and cpu_has_mips16 have
been set, while cpu_has_mt has been undefined due to the lack of mt ASE
in the Danube.
With this file the kernel size is reduced about 30KB in the XWAY subtarget.
Tested in a Danube based router with no problems and with a little
improvement in the USB port when using mass storage devices and wireless
dongles.

Signed off by: José Vázquez Fernández ppvazquez...@gmail.com

I haven't AR9 nor VR9 based boards so a tests in those SoCs are strongly 
recommended.


diff --git 
a/target/linux/lantiq/patches-3.10/0036-MIPS-lantiq-xway-add-cpu-feature-override.patch 
b/target/linux/lantiq/patches-3.10/0036-MIPS-lantiq-xway-add-cpu-feature-override.patch

new file mode 100644
index 000..5e9a9d2

--- a/arch/mips/include/asm/mach-lantiq/xway/cpu-feature-overrides.h
1970-01-01 01:00:00.0 +0100
+++ b/arch/mips/include/asm/mach-lantiq/xway/cpu-feature-overrides.h
2014-07-01 12:37:07.790313378 +0200
@@ -0,0 +1,58 @@
+/*
+ *  Lantiq XWAY specific CPU feature overrides
+ *
+ *  Copyright (C) 2014 José Vázquez Fernández
+ *
+ *  This file was derived from: include/asm-mips/cpu-features.h
+ *Copyright (C) 2003, 2004 Ralf Baechle
+ *Copyright (C) 2004 Maciej W. Rozycki
+ *
+ *  This program is free software; you can redistribute it and/or
modify it
+ *  under the terms of the GNU General Public License version 2 as
published
+ *  by the Free Software Foundation.
+ *
+ */
+#ifndef __ASM_MACH_XWAY_CPU_FEATURE_OVERRIDES_H
+#define __ASM_MACH_XWAY_CPU_FEATURE_OVERRIDES_H
+
+#define cpu_has_tlb1
+#define cpu_has_4kex1
+#define cpu_has_3k_cache0
+#define cpu_has_4k_cache1
+#define cpu_has_tx39_cache0
+#define cpu_has_sb1_cache0
+#define cpu_has_fpu0
+#define cpu_has_32fpr0
+#define cpu_has_counter1
+#define cpu_has_watch1
+#define cpu_has_divec1
+
+#define cpu_has_prefetch1
+#define cpu_has_ejtag1
+#define cpu_has_llsc1
+
+#define cpu_has_dsp1
+#define cpu_has_mips161
+#define cpu_has_dsp20
+#define cpu_has_mdmx0
+#define cpu_has_mips3d0
+#define cpu_has_smartmips0
+#define cpu_has_vz0
+
+#define cpu_has_mips32r11
+#define cpu_has_mips32r21
+#define cpu_has_mips64r10
+#define cpu_has_mips64r20
+
+#define cpu_has_vint1 /* MIPSR2 vectored interrupts */
+#define cpu_has_veic1 /* MIPSR2 external interrupt controller
mode */
+
+#define cpu_has_64bits0
+#define cpu_has_64bit_zero_reg0
+#define cpu_has_64bit_gp_regs0
+#define cpu_has_64bit_addresses0
+
+#define cpu_dcache_line_size()32
+#define cpu_icache_line_size()32
+
+#endif /* __ASM_MACH_XWAY_CPU_FEATURE_OVERRIDES_H */

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

[OpenWrt-Devel] [PATCH] [LANTIQ] [resend] Add XWAY cpu-feature-overrides

[José Vázquez Fernández]

Add XWAY cpu-feature-overrides.h file.

This patch adds cpu-feature-overrides.h file for the XWAY family, based 
in the one in FALCON.
Because Amazon SE was deprecated, cpu_has_dsp and cpu_has_mips16 have 
been set, while cpu_has_mt has been undefined due to the lack of mt ASE 
in the Danube.

With this file the kernel size is reduced about 30KB in the XWAY subtarget.
Tested in a Danube based router with no problems and with a little 
improvement in the USB port when using mass storage devices and wireless 
dongles.


Signed off by: José Vázquez Fernández ppvazquez...@gmail.com

diff --git 
a/target/linux/lantiq/patches-3.10/0036-MIPS-lantiq-xway-add-cpu-feature-override.patch 
b/target/linux/lantiq/patches-3.10/0036-MIPS-lantiq-xway-add-cpu-feature-override.patch

new file mode 100644
index 000..5e9a9d2
diff -urN a/arch/mips/include/asm/mach-lantiq/xway/cpu-feature- 
overrides.h b/arch/mips/include/asm/mach-lantiq/xway/cpu-feature-overrides.h
--- a/arch/mips/include/asm/mach-lantiq/xway/cpu-feature-overrides.h 
1970-01-01 01:00:00.0 +0100
+++ b/arch/mips/include/asm/mach-lantiq/xway/cpu-feature-overrides.h 
2014-07-01 12:37:07.790313378 +0200

@@ -0,0 +1,58 @@
+/*
+ *  Lantiq XWAY specific CPU feature overrides
+ *
+ *  Copyright (C) 2014 José Vázquez Fernández
+ *
+ *  This file was derived from: include/asm-mips/cpu-features.h
+ * Copyright (C) 2003, 2004 Ralf Baechle
+ * Copyright (C) 2004 Maciej W. Rozycki
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License version 2 as 
published

+ *  by the Free Software Foundation.
+ *
+ */
+#ifndef __ASM_MACH_XWAY_CPU_FEATURE_OVERRIDES_H
+#define __ASM_MACH_XWAY_CPU_FEATURE_OVERRIDES_H
+
+#define cpu_has_tlb1
+#define cpu_has_4kex   1
+#define cpu_has_3k_cache   0
+#define cpu_has_4k_cache   1
+#define cpu_has_tx39_cache 0
+#define cpu_has_sb1_cache  0
+#define cpu_has_fpu0
+#define cpu_has_32fpr  0
+#define cpu_has_counter1
+#define cpu_has_watch  1
+#define cpu_has_divec  1
+
+#define cpu_has_prefetch   1
+#define cpu_has_ejtag  1
+#define cpu_has_llsc   1
+
+#define cpu_has_dsp1
+#define cpu_has_mips16 1
+#define cpu_has_dsp2   0
+#define cpu_has_mdmx   0
+#define cpu_has_mips3d 0
+#define cpu_has_smartmips  0
+#define cpu_has_vz 0
+
+#define cpu_has_mips32r1   1
+#define cpu_has_mips32r2   1
+#define cpu_has_mips64r1   0
+#define cpu_has_mips64r2   0
+
+#define cpu_has_vint   1 /* MIPSR2 vectored interrupts */
+#define cpu_has_veic   1 /* MIPSR2 external interrupt controller mode 
*/
+
+#define cpu_has_64bits 0
+#define cpu_has_64bit_zero_reg 0
+#define cpu_has_64bit_gp_regs  0
+#define cpu_has_64bit_addresses0
+
+#define cpu_dcache_line_size() 32
+#define cpu_icache_line_size() 32
+
+#endif /* __ASM_MACH_XWAY_CPU_FEATURE_OVERRIDES_H */
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [Lantiq][RFC] Add cpu-feature-overrides.h and disable PCIe and multithreading in Danube

[José Vázquez]

2014-07-01 7:26 GMT+02:00, John Crispin j...@phrozen.org:
 NAK, xway is a unified kernel target and we wont change that upstream.
 i am fine with the cpu override bit but i wont take the KConfig part,

 sorry,
   John


Why sorry? This is only a RFC.
Kconfig part was only for fine tuning, but, in addition to maintain
XWAY as an unified target, those modifications can give problems now
and in the future, and i don't want to make nobody's life harder.
Regarding cpu override, ASE support was dropped some time ago so, what
do you think about set cpu_has_mips16? Any additional advice for this
file?
Another question is if cpu_has_vint and cpu_has_veic can be enabled or
simply dropped. I assume that a test will be the best to see if they
are safe, am i right? In addition, in UGW CPU_MIPSR2_IRQ_VI is present
in ASE, Danube, AR9, VR9 and AR10. Should be it set in Kconfig?

Off topic:i've tested MIPS_MT_SMP in a VR9 based router but, according
top, 50% of the cpu time was busy with a kernel process; with
MIPS_MT_SMTC the kernel freezes early when booting.

A lot of thanks for your time and comments.

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

Re: [OpenWrt-Devel] [Patch][BCM63XX][V2][RFC] Select HW_RANDOM_BCM63XX only in the SoCs that support it.

[José Vázquez]

2014-07-01 0:57 GMT+02:00, Florian Fainelli flor...@openwrt.org:
 2014-06-30 4:30 GMT-07:00 José Vázquez ppvazquez...@gmail.com:
 b43 and b43-legacy drivers enable CONFIG_HW_RANDOM in
 .config.override; without they selected the problem does not happen.
 More drivers need HW_RANDOM but they were not selected in my owrt
 config.

 define KernelPackage/b43
   $(call KernelPackage/mac80211/Default)
   TITLE:=Broadcom 43xx wireless support
   URL:=http://linuxwireless.org/en/users/Drivers/b43
   KCONFIG:= \
 CONFIG_HW_RANDOM=y

 I have no idea why these drivers enable HW_RANDOM but surely there is
 a good reason.

 I think this is just from a time where there was not a package for
 HW_RANDOM, you might want to make b43 depend on that specific kmod
 package that would be cleaner in any case.
I think that an additional option should be added in both b43 drivers
in order to have the choice of select or unselect B43_HWRNG because
BCM4318, BCM43222 and BCM43225 don't pass rng-tools fips tests (maybe
other BCM wireless chips pass them).
http://lxr.free-electrons.com/source/drivers/net/wireless/b43/Kconfig?v=3.10#L155


 A lot of thanks for your time and guidance.

 And thanks for your perseverance, that is much appreciated!
If my perseverance is useful, perfect, but if not, my apologies.
 --
 Florian

Excuse me if i don't fully understood your comment; what do you want
to mean with I think this is just from a time where there was not a
package for HW_RANDOM? My english is still a bit poor.

Best regards:

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

Re: [OpenWrt-Devel] [PATCH] [LANTIQ] Enable LANTIQ_PHY and LANTIQ_XRX200 only in XRX200 subtarget.

[José Vázquez]

2014-06-30 21:46 GMT+02:00, José Vázquez Fernández ppvazquez...@gmail.com:
 Enable LANTIQ_PHY and LANTIQ_XRX200 only in XRX200 subtarget.

 These drivers are not needed for ASE, Danube and AR9.
 As side effect PHY11G and PHY22F firmwares are not included in the
 kernel image, which saves 64 KB.


Why was it rejected?

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

Re: [OpenWrt-Devel] [PATCH] [LANTIQ] Enable LANTIQ_PHY and LANTIQ_XRX200 only in XRX200 subtarget.

[José Vázquez]

2014-07-01 15:20 GMT+02:00, John Crispin j...@phrozen.org:


 On 01/07/2014 13:40, José Vázquez wrote:
 2014-06-30 21:46 GMT+02:00, José Vázquez Fernández
 ppvazquez...@gmail.com:
 Enable LANTIQ_PHY and LANTIQ_XRX200 only in XRX200 subtarget.

 These drivers are not needed for ASE, Danube and AR9. As side
 effect PHY11G and PHY22F firmwares are not included in the kernel
 image, which saves 64 KB.


 Why was it rejected?

 Pepe



 the patch did not apply. neither with git am nor with patch. i fixed
 this up manually. please check your patches before sending them.

Sorry!
Please, next time i send a patch that gives problems like these report
it to make rewrite it in the right way. You, and the owrt team, of
course, must not loose time fixing problematig patches. In addition i
will be forced to make the things better an pay more attention.

A lot of thanks.

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

Re: [OpenWrt-Devel] [Patch][BCM63XX][V2][RFC] Select HW_RANDOM_BCM63XX only in the SoCs that support it.

[José Vázquez]

2014-06-29 22:45 GMT+02:00, Jonas Gorski j...@openwrt.org:
 On Sun, Jun 29, 2014 at 10:37 PM, José Vázquez ppvazquez...@gmail.com
 wrote:
 2014-06-28 19:54 GMT+02:00, Jonas Gorski j...@openwrt.org:

 Ah, I guess your problem is that something in your openwrt config
 depends on kmod-random-core, which will cause HW_RANDOM to be selected
 (as m), which makes HW_RANDOM_BCM63XX visible. In that case you need
 to either add # CONFIG_HW_RANDOM_BCM63XX is not set to
 config/target/generic-3.10 or create a proper kernel module package
 for HW_RANDOM_BCM63XX.


 Jonas

 Now understand: something selects CONFIG_HW_RANDON=m and
 automatically, because depends on BCM63XX, CONFIG_HW_RANDOM_BCM63XX
 needs an m too.
 Sorry for the noise.

 Not quite.

 default config-3.10 has CONFIG_HW_RANDOM=y and CONFIG_HW_RANDOM_BCM63XX=y.

 You run make kernel_menuconfig and deselect CONFIG_HW_RANDOM. Because
 CONFIG_HW_RANDOM_BCM63XX depends on CONFIG_HW_RANDOM,
 CONFIG_HW_RANDOM_BCM63XX is not defined anymore, and your modified
 config-3.10 now only contains # CONFIG_HW_RANDOM is not set.

 Now something in the build system selects CONFIG_HW_RANDOM=m, and
 suddenly CONFIG_HW_RANDOM_BCM63XX is available again, but config-3.10
 does not contain CONFIG_HW_RANDOM_BCM63XX anymore, so the kernel
 config system needs to ask what you want as its value.

 If you leave CONFIG_HW_RANDOM=y and only disable
 CONFIG_HW_RANDOM_BCM63XX, then you will have no issue, because then
 your config-3.10 will contain a line # CONFIG_HW_RANDOM_BCM63XX  is
 not set



 Jonas

b43 and b43-legacy drivers enable CONFIG_HW_RANDOM in
.config.override; without they selected the problem does not happen.
More drivers need HW_RANDOM but they were not selected in my owrt
config.

define KernelPackage/b43
  $(call KernelPackage/mac80211/Default)
  TITLE:=Broadcom 43xx wireless support
  URL:=http://linuxwireless.org/en/users/Drivers/b43
  KCONFIG:= \
CONFIG_HW_RANDOM=y

I have no idea why these drivers enable HW_RANDOM but surely there is
a good reason.

A lot of thanks for your time and guidance.

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

Re: [OpenWrt-Devel] [PATCH][bcm63xx]: Support for Comtrend VR-3025u and VR-3025un.

[José Vázquez]

Ok, sorry.

2014-06-30 17:11 GMT+02:00, Jonas Gorski j...@openwrt.org:
 On Fri, May 23, 2014 at 7:36 PM, José Vázquez Fernández
 ppvazquez...@gmail.com wrote:
 Support for Comtrend VR-3025u and VR-3025un.

 This patch adds support for both VR-3025u and VR-3025un.
 Due to these routers are very close in terms of board definitions because
 the only differences are a led name and the board_id, the patch covers
 both
 boards.

 Signed off by: José Vázquez Fernández ppvazquez...@gmail.com
 Signed off by: Álvaro Fernández nolt...@gmail.com

 This patch is linebroken and I couldn't get it to apply. Please fix,
 rebase onto the latest changes and resend. Also please ensure both
 3.10 and 3.14 are updated.


 Jonas

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

[OpenWrt-Devel] [PATCH] [LANTIQ] Enable LANTIQ_PHY and LANTIQ_XRX200 only in XRX200 subtarget.

[José Vázquez Fernández]

Enable LANTIQ_PHY and LANTIQ_XRX200 only in XRX200 subtarget.

These drivers are not needed for ASE, Danube and AR9.
As side effect PHY11G and PHY22F firmwares are not included in the 
kernel image, which saves 64 KB.


Signed off by: José Vázquez Fernández ppvazquez...@gmail.com

Index: target/linux/lantiq/config-default
===
--- target/linux/lantiq/config-default  (revisión: 41429)
+++ target/linux/lantiq/config-default  (copia de trabajo)
@@ -83,9 +83,7 @@
 CONFIG_IRQ_FORCED_THREADING=y
 CONFIG_LANTIQ=y
 CONFIG_LANTIQ_ETOP=y
-CONFIG_LANTIQ_PHY=y
 CONFIG_LANTIQ_WDT=y
-CONFIG_LANTIQ_XRX200=y
 CONFIG_LEDS_GPIO=y
 CONFIG_MDIO_BOARDINFO=y
 CONFIG_MIPS=y
Index: target/linux/lantiq/xrx200/config-default
===
--- target/linux/lantiq/xrx200/config-default   (revisión: 41429)
+++ target/linux/lantiq/xrx200/config-default   (copia de trabajo)
@@ -15,6 +15,8 @@
 CONFIG_IRQCHIP=y
 CONFIG_IRQ_WORK=y
 # CONFIG_ISDN is not set
+CONFIG_LANTIQ_PHY=y
+CONFIG_LANTIQ_XRX200=y
 CONFIG_LEDS_TRIGGER_HEARTBEAT=y
 CONFIG_LZO_COMPRESS=y
 CONFIG_LZO_DECOMPRESS=y
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [Lantiq][RFC] Add cpu-feature-overrides.h and disable PCIe and multithreading in Danube

[José Vázquez Fernández]

This draft adds cpu-feature-overrides.h using the FALCON one as base.
Due to the different cores used in ASE and Danube the Kconfig was 
modified to disable some options that are present in the AR9 and VR9 
SoCs, like multithreading, mt ASE and some others.
According with UGW all the Lantiq SoCs supported in OpenWRT have 
CPU_MIPSR2_IRQ_VI but it was not tested nor added.
FALCON sets cpu_has_vint and cpu_has_veic to 1, but here were left 
undefined because i have no idea if the XWAY family have and/or support 
they.
Due to only dcdc driver only has effect with the VR9 the Makefile was 
modified to include it only when SOC_XWAY is selected.


As a side effect the kernel size is 30KB smaller.

This patch, as is, works fine with a Danube based router, but, as i have 
said, is only a draft that, if it has interest, must be improved.


José Vázquez



diff -urN 
a/arch/mips/include/asm/mach-lantiq/xway/cpu-feature-overrides.h 
b/arch/mips/include/asm/mach-lantiq/xway/cpu-feature-overrides.h
--- a/arch/mips/include/asm/mach-lantiq/xway/cpu-feature-overrides.h 
1970-01-01 01:00:00.0 +0100
+++ b/arch/mips/include/asm/mach-lantiq/xway/cpu-feature-overrides.h 
2014-07-01 01:34:41.980432797 +0200

@@ -0,0 +1,67 @@
+/*
+ *  Lantiq XWAY specific CPU feature overrides
+ *
+ *  This file was derived from: include/asm-mips/cpu-features.h
+ * Copyright (C) 2003, 2004 Ralf Baechle
+ * Copyright (C) 2004 Maciej W. Rozycki
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License version 2 as 
published

+ *  by the Free Software Foundation.
+ *
+ */
+#ifndef __ASM_MACH_XWAY_CPU_FEATURE_OVERRIDES_H
+#define __ASM_MACH_XWAY_CPU_FEATURE_OVERRIDES_H
+
+#define cpu_has_tlb1
+#define cpu_has_4kex   1
+#define cpu_has_3k_cache   0
+#define cpu_has_4k_cache   1
+#define cpu_has_tx39_cache 0
+#define cpu_has_sb1_cache  0
+#define cpu_has_fpu0
+#define cpu_has_32fpr  0
+#define cpu_has_counter1
+#define cpu_has_watch  1
+#define cpu_has_divec  1
+
+#define cpu_has_prefetch   1
+#define cpu_has_ejtag  1
+#define cpu_has_llsc   1
+
+#if defined(CONFIG_SOC_AMAZON_SE)
+#define cpu_has_mips16 0
+#endif
+
+#define cpu_has_mdmx   0
+#define cpu_has_mips3d 0
+#define cpu_has_smartmips  0
+#define cpu_has_vz 0
+
+#define cpu_has_mips32r1   1
+#define cpu_has_mips32r2   1
+#define cpu_has_mips64r1   0
+#define cpu_has_mips64r2   0
+
+#if defined(CONFIG_SOC_AMAZON_SE)
+#define cpu_has_dsp0
+#endif
+
+#define cpu_has_dsp2   0
+
+#if defined(CONFIG_SOC_AMAZON_SE) || defined(CONFIG_SOC_DANUBE)
+#define cpu_has_mipsmt 0
+#endif
+
+//#define cpu_has_vint ? /* MIPSR2 vectored interrupts */
+//#define cpu_has_veic ? /* MIPSR2 external interrupt controller mode 
*/
+
+#define cpu_has_64bits 0
+#define cpu_has_64bit_zero_reg 0
+#define cpu_has_64bit_gp_regs  0
+#define cpu_has_64bit_addresses0
+
+#define cpu_dcache_line_size() 32
+#define cpu_icache_line_size() 32
+
+#endif /* __ASM_MACH_XWAY_CPU_FEATURE_OVERRIDES_H */
diff -urN a/arch/mips/Kconfig b/arch/mips/Kconfig
--- a/arch/mips/Kconfig 2014-07-01 01:11:21.0 +0200
+++ b/arch/mips/Kconfig 2014-06-30 23:59:30.0 +0200
@@ -241,7 +241,6 @@
select SYS_HAS_CPU_MIPS32_R2
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_SUPPORTS_32BIT_KERNEL
-   select SYS_SUPPORTS_MULTITHREADING
select SYS_HAS_EARLY_PRINTK
select ARCH_REQUIRE_GPIOLIB
select SWAP_IO_SPACE
diff -urN a/arch/mips/lantiq/Kconfig b/arch/mips/lantiq/Kconfig
--- a/arch/mips/lantiq/Kconfig  2014-07-01 01:11:23.0 +0200
+++ b/arch/mips/lantiq/Kconfig  2014-07-01 01:17:23.592775282 +0200
@@ -11,14 +11,21 @@
default SOC_XWAY

 config SOC_AMAZON_SE
-   bool Amazon SE
+   bool XWAY Amazon SE
select SOC_TYPE_XWAY

+config SOC_DANUBE
+   bool XWAY Danube
+   select SOC_TYPE_XWAY
+   select HW_HAS_PCI
+   select ARCH_SUPPORTS_MSI
+
 config SOC_XWAY
-   bool XWAY
+   bool XWAY Danube, AR9 and VR9
select SOC_TYPE_XWAY
select HW_HAS_PCI
select ARCH_SUPPORTS_MSI
+   select SYS_SUPPORTS_MULTITHREADING

 config SOC_FALCON
bool FALCON
@@ -31,12 +38,12 @@

 config DT_EASY50712
bool Easy50712
-   depends on SOC_XWAY
+   depends on SOC_XWAY || SOC_DANUBE
 endchoice

 config PCI_LANTIQ
bool PCI Support
-   depends on SOC_XWAY  PCI
+   depends on (SOC_XWAY || SOC_DANUBE)  PCI

 config PCIE_LANTIQ
bool PCIE Support
diff -urN a/arch/mips/lantiq/xway/Makefile b/arch/mips/lantiq/xway/Makefile
--- a/arch/mips/lantiq/xway/Makefile2014-07-01 01:11:23.0 +0200
+++ b/arch/mips/lantiq/xway/Makefile2014-07-01 02:02:33.946247244 +0200
@@ -1,8 +1,9 @@
-obj-y

Re: [OpenWrt-Devel] [Patch][BCM63XX][V2][RFC] Select HW_RANDOM_BCM63XX only in the SoCs that support it.

[José Vázquez]

2014-06-28 19:54 GMT+02:00, Jonas Gorski j...@openwrt.org:

 Ah, I guess your problem is that something in your openwrt config
 depends on kmod-random-core, which will cause HW_RANDOM to be selected
 (as m), which makes HW_RANDOM_BCM63XX visible. In that case you need
 to either add # CONFIG_HW_RANDOM_BCM63XX is not set to
 config/target/generic-3.10 or create a proper kernel module package
 for HW_RANDOM_BCM63XX.


 Jonas

Now understand: something selects CONFIG_HW_RANDON=m and
automatically, because depends on BCM63XX, CONFIG_HW_RANDOM_BCM63XX
needs an m too.
Sorry for the noise.

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

Re: [OpenWrt-Devel] [Patch][BCM63XX][V2][RFC] Select HW_RANDOM_BCM63XX only in the SoCs that support it.

[José Vázquez]

2014-06-27 13:14 GMT+02:00, Jonas Gorski j...@openwrt.org:
 On Fri, Jun 27, 2014 at 1:00 PM, José Vázquez ppvazquez...@gmail.com
 wrote:
 2014-06-27 12:29 GMT+02:00, Jonas Gorski j...@openwrt.org:
 On Wed, Jun 18, 2014 at 5:34 PM, José Vázquez Fernández
 ppvazquez...@gmail.com wrote:
 Select HW_RANDOM_BCM63XX only in the SoCs that support it.

 Only BCM6368, BCM6362 and BCM63268 have a hardware random numbers
 generator, so, if none of these are selected, don't compile it.

 Tested with BCM6358 and BCM6328 successfully with both 3.10 and 3.14
 kernels.

 Signed off by: José Vázquez Fernández ppvazquez...@gmail.com

 Sorry, I still don't see the point of this. All this patch does is
 slightly reduce the visibility of HW_RANDOM_BCM63XX. And since this is
 a user selectable symbol, I don't think this makes much sense because
 if you don't want it built, you can just not select it.

 Also, COMPILE_TEST should only be added if it actually compiles for
 other arches (or even different mips targets), which it doesn't.


 Jonas

 The point is that, if HW_RANDOM_BCM63XX is deselected, the kernel
 sends an error because HW_RANDOM_BCM63XX depends on BCM63XX. The
 patch, as you saw, force compilation of trng only in the SoCs that has
 that hardware. If in the kernel are only selected SoCs that don't have
 that hardware, the driver is not compiled.

 sends an error? Can please paste the actual error message? Because I
 don't see one if I disable HW_RANDOM_BCM63XX.

This is the error message:

TTY driver to output user messages via printk (TTY_PRINTK) [N/y/?] n
Hardware Random Number Generator Core support (HW_RANDOM) [Y/n/m/?] y
  Timer IOMEM HW Random Number Generator support
(HW_RANDOM_TIMERIOMEM) [N/m/y/?] n
  Atmel Random Number Generator support (HW_RANDOM_ATMEL) [N/m/y/?] n
  Broadcom BCM63xx Random Number Generator support (HW_RANDOM_BCM63XX)
[Y/n/m/?] (NEW) aborted!

Console input/output is redirected. Run 'make oldconfig' to update
configuration.

make[7]: *** [silentoldconfig] Error 1
make[6]: *** [silentoldconfig] Error 2

The present kernel configuration has modules disabled.
Type 'make config' and enable loadable module support.
Then build a kernel with module support enabled.

make[5]: *** [modules] Error 1
make[5]: Leaving directory
`/home/taxodium/trunk/build_dir/target-mips_mips32_uClibc-0.9.33.2/linux-brcm63xx_generic/linux-3.10.44'

Some lines of the kernel config file with HW_RANDOM and
HW_RANDOM_BCM63XX disabled:
# CONFIG_TTY_PRINTK is not set
# CONFIG_IPMI_HANDLER is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_RAW_DRIVER is not set


The patch was done to avoid that error and to save few kilobytes of
RAM and flash in the boards that don't have hwrng.

 COMPILE_TEST is added if the patch has interest for linux-mips. You
 are right: in OpenWRT is useless.
 Any advice to improve it?

 It's actually the hw random (crypto?) guys that would be interested in
 this, mips is only collateral because some of the headers exist in
 arch/mips.

 To satisfy COMPILE_TEST, convert any bcm_{read,write}* calls to
 __raw_{read,write}*, probably
 move the register definitions from include/asm/mach-bcm63xx/* to the
 driver itself. If you can enable it for x86 and it compiles, then you
 succeeded ;-)


 Jonas

I'll send COMPILE_TEST patch with the modifications that you recommend
to linux-mips because Florian sent the driver to that patchwork two
years ago and it was accepted.

Any advice will be very welcome.

Best regards:

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

Re: [OpenWrt-Devel] [Patch][BCM63XX][V2][RFC] Select HW_RANDOM_BCM63XX only in the SoCs that support it.

[José Vázquez]

2014-06-28 18:10 GMT+02:00, Jonas Gorski j...@openwrt.org:
 On Sat, Jun 28, 2014 at 3:09 PM, José Vázquez ppvazquez...@gmail.com
 wrote:
 This means your kernel configuration is missing # HW_RANDOM_BCM63XX
 is not set in target/linux/brcm63xx/config-3.10, which is *not* an
 issue of the Kernel, but only of your incomplete, custom kernel
 configuration. This would have happened with any missing kernel config
 symbol, and is nothing specific of HW_RANDOM_BCM63XX.

 I guess you just deleted the line from the config-3.10. But the kernel
 config does not work this way - you need to use make kernel_menuconfig
 to change the kernel config symbols, or ensure that you only replace
 values (e.g. CONFIG_foo=y = # CONFIG_foo is not set - the
 important part is that a line containing CONFIG_foo still exists).

 (snip)
 I'll send COMPILE_TEST patch with the modifications that you recommend
 to linux-mips because Florian sent the driver to that patchwork two
 years ago and it was accepted.

 Use scripts/get_maintainer.pl to get the correct people/mailing lists
 to send the patch to. Also use a current kernel tree of course, not
 3.10.



 Jonas

Nop, i used make kernel_menuconfig to deselect HW_RANDOM_BCM63XX and HW_RANDOM.
As you can see in the Kconfig, HW_RANDOM_BCM63XX depends on BCM63XX
so, if it is not selected, sends the aforementioned error. However
SPI_BCM63XX and SPI_BCM63XX_HSSPI can be deselected and the
compilation finishes normally.

Pepe

P.S.: maybe will be better to forget this patch and leave the things
as they are because the time you are spending don't justify the
benefits, and could lead to problems in the future.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [Patch][BCM63XX][V2][RFC] Select HW_RANDOM_BCM63XX only in the SoCs that support it.

[José Vázquez]

2014-06-27 12:29 GMT+02:00, Jonas Gorski j...@openwrt.org:
 On Wed, Jun 18, 2014 at 5:34 PM, José Vázquez Fernández
 ppvazquez...@gmail.com wrote:
 Select HW_RANDOM_BCM63XX only in the SoCs that support it.

 Only BCM6368, BCM6362 and BCM63268 have a hardware random numbers
 generator, so, if none of these are selected, don't compile it.

 Tested with BCM6358 and BCM6328 successfully with both 3.10 and 3.14
 kernels.

 Signed off by: José Vázquez Fernández ppvazquez...@gmail.com

 Sorry, I still don't see the point of this. All this patch does is
 slightly reduce the visibility of HW_RANDOM_BCM63XX. And since this is
 a user selectable symbol, I don't think this makes much sense because
 if you don't want it built, you can just not select it.

 Also, COMPILE_TEST should only be added if it actually compiles for
 other arches (or even different mips targets), which it doesn't.


 Jonas

The point is that, if HW_RANDOM_BCM63XX is deselected, the kernel
sends an error because HW_RANDOM_BCM63XX depends on BCM63XX. The
patch, as you saw, force compilation of trng only in the SoCs that has
that hardware. If in the kernel are only selected SoCs that don't have
that hardware, the driver is not compiled.
COMPILE_TEST is added if the patch has interest for linux-mips. You
are right: in OpenWRT is useless.
Any advice to improve it?

Regards:

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

Re: [OpenWrt-Devel] [PATCH 0/2] [telephony] Asterisk: Multiplevulnerabilities

[José Vázquez Fernández]

Do these vulnerabilities affect the versions included in Attitude Adjustment?

Pepe



Hello Daniel,

I have applied your patches.

Commits:
93ef5a1a85c9dc55b91778a806f6463b11d68026
eee55b8fd0ce811e0b1cc7400f012e19e1f99b30

Thank you so much!
Jiri

Dne 26/06/2014 05:18, Daniel Golle napsal(a):
 Vulnerabilities in various versions of Asterisk have been discovered
 recently.
 See
 http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/xml/htdocs/security/en/glsa/glsa-201406-25.xml
 
 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-4046
 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-4047
 
 Both, asterisk-1.8.x and asterisk-11.x should thus be updated to
 the most recent releases.
 
 Daniel Golle (2):
   asterisk-1.8.x: bump version
   asterisk-11.x: bump version
 
  net/asterisk-1.8.x/Makefile   | 4 
 ++--
  net/asterisk-11.x/Makefile| 4 
 ++--
  .../patches/010-asterisk-configure-undef-res-ninit.patch  | 2 +-
  3 files changed, 5 insertions(+), 5 deletions(-)
 
___
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][BCM63XX][V2][RFC] Select HW_RANDOM_BCM63XX only in the SoCs that support it.

[José Vázquez Fernández]

Select HW_RANDOM_BCM63XX only in the SoCs that support it.

Only BCM6368, BCM6362 and BCM63268 have a hardware random numbers
generator, so, if none of these are selected, don't compile it.

Tested with BCM6358 and BCM6328 successfully with both 3.10 and 3.14 
kernels.


Signed off by: José Vázquez Fernández ppvazquez...@gmail.com

diff -urN a/arch/mips/bcm63xx/Kconfig b/arch/mips/bcm63xx/Kconfig
--- a/arch/mips/bcm63xx/Kconfig 2014-06-02 16:00:48.0 +0200
+++ b/arch/mips/bcm63xx/Kconfig 2014-06-18 17:06:30.119106246 +0200
@@ -60,6 +60,7 @@
select HW_HAS_PCI
select BCM63XX_OHCI
select BCM63XX_EHCI
+   select BCM_RNG

 config BCM63XX_CPU_6368
bool support 6368 CPU
@@ -67,6 +68,7 @@
select HW_HAS_PCI
select BCM63XX_OHCI
select BCM63XX_EHCI
+   select BCM_RNG

 config BCM63XX_CPU_63268
bool support 63268 CPU
@@ -74,6 +76,10 @@
select HW_HAS_PCI
select BCM63XX_OHCI
select BCM63XX_EHCI
+   select BCM_RNG
 endmenu

+config BCM_RNG
+   bool
+
 source arch/mips/bcm63xx/boards/Kconfig
diff -urN a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
--- a/drivers/char/hw_random/Kconfig2014-05-31 21:34:37.0 +0200
+++ b/drivers/char/hw_random/Kconfig2014-06-18 17:03:53.127017691 +0200
@@ -75,7 +75,7 @@

 config HW_RANDOM_BCM63XX
tristate Broadcom BCM63xx Random Number Generator support
-   depends on HW_RANDOM  BCM63XX
+   depends on HW_RANDOM  (BCM_RNG || COMPILE_TEST)
default HW_RANDOM
---help---
  This driver provides kernel-side support for the Random Number
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] changeset 40948 breaks loading ath9k calibration data from EEPROM

[José Vázquez]

2014-06-15 8:03 GMT+02:00, John Crispin j...@phrozen.org:


 On 14/06/2014 23:08, José Vázquez wrote:
 The main problem with the wifi in the Lantiq target are the ARV
 boards: a lot of people, John included, spent a lot of time an
 still there are some problems, as you see.

 bollocks .. i never spent any time on that code. i don't even have the
 boards so i cannot test which is why its most likely why its broken.
 if people had spend that much time on the code it would be woring and
 not ugly and broken.

 as for the patches you sent, they were not merged because they are a
 big pile of copy pasta churn that adds lots of redundancy and
 duplication. it would make the code even uglier than it is now.

You are right: those patches had a lot of redundant code. I will take
more care next time, but the original code was not mine.
I have a question flying around my head: why nobody realized, apart of
you, the potential problems of those patches and the redundant code,
and told something to improve them?

My apologies:

José Vázquez
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] changeset 40948 breaks loading ath9k calibration data from EEPROM

[José Vázquez]

2014-06-14 14:32 GMT+02:00, Ben Mulvihill ben.mulvih...@gmail.com:

 On Sat, 2014-06-14 at 14:06 +0200, John Crispin wrote:

 On 14/06/2014 13:29, Ben Mulvihill wrote:
  Hi,
 
  Since changeset 40948, calibration data is no longer correctly
  loaded from EEPROM on the BTHOMEHUBV2B. I've been trying to make
  sense of the various changes to
 
  0010-MIPS-lantiq-wifi-and-ethernet-eeprom-handling.patch
 
  and it looks to me as though merging José's recent patch for the
  ARV4518PW has left us with an old version of the ath9k EEPROM
  loading code, without the succession of changes made last year
  culminating in patch #4417 from Daniel Gimpelevitch. I should
  imagine therefore that the DGN3500 is broken as well as the
  BTHOMEHUBV2B.
 
  Ben
 
 

 ok, i will look into it and merge the version we had previous to the
 3.10 rebase

  John
 u

 Thank you. Let me know if you want me to test anything, or
 if there is anything else I can do.


Unless the BTHOMEHUBV2B has an Atheros b/g wireless chip the patch
should have no effect in the routers that need ath9k driver. My main
concern with that patch were the Siemens SX76x but not the others.
AFAIK the cal_data partition is a bit problematic because each
manufacturer make the things in its own way, and Daniel Gimpelevitch
and Álvaro Fernández know how to fix this problem in the less
traumatic way.

Regards:

José Vázquez
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] changeset 40948 breaks loading ath9k calibration data from EEPROM

[José Vázquez]

2014-06-14 21:47 GMT+02:00, Ben Mulvihill ben.mulvih...@gmail.com:
 On Sat, 2014-06-14 at 18:53 +0200, José Vázquez wrote:

 Unless the BTHOMEHUBV2B has an Atheros b/g wireless chip the patch
 should have no effect in the routers that need ath9k driver. My main
 concern with that patch were the Siemens SX76x but not the others.
 AFAIK the cal_data partition is a bit problematic because each
 manufacturer make the things in its own way, and Daniel Gimpelevitch
 and Álvaro Fernández know how to fix this problem in the less
 traumatic way.

 Regards:

 José Vázquez

 I've just had a closer look, and realised that only one of your recent
 patches  (http://patchwork.openwrt.org/patch/5582/) has actually
 been applied, in changeset 40999. As you say, that shouldn't cause
 problems.

 The BTHOMEHUBV2B is definitely broken though. and what has broken things
 is the previous changeset, 40948. Let's see what John comes up with.

 Your other two patches, #5453 and #5454, are marked as non-applicable
 in patchwork. Do you still need them?

 Regards,

 Ben

Patches 5453 and 5454 were marked as not applicable due to the
changeset 40948. Were an attemp to correct the problems reading
cal_data in Arcadyan/Astoria boards and were wrote by two
seguridadwireless forum users. They wrote the code trying to make it
backwards compatible. Feel free to use them.
The main problem with the wifi in the Lantiq target are the ARV
boards: a lot of people, John included, spent a lot of time an still
there are some problems, as you see.

Regards:

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

[OpenWrt-Devel] [Patch][BCM63XX] Select HW_RANDOM_BCM63XX only in the SoCs that support it.

[José Vázquez Fernández]

Select HW_RANDOM_BCM63XX only in the SoCs that support it.

Only BCM6368, BCM6362 and BCM63268 have a hardware random numbers 
generator, so, if none of these are selected, don't compile a driver 
that has no effect.


Tested with BCM6358 and BCM6328 successfully.

Signed off by: José Vázquez Fernández ppvazquez...@gmail.com

diff -urN a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
--- a/drivers/char/hw_random/Kconfig	2014-06-06 12:21:38.677781666 +0200
+++ b/drivers/char/hw_random/Kconfig	2014-06-05 20:58:11.0 +0200
@@ -75,7 +75,7 @@
 
 config HW_RANDOM_BCM63XX
 	tristate Broadcom BCM63xx Random Number Generator support
-	depends on HW_RANDOM  BCM63XX
+	depends on HW_RANDOM  (BCM63XX_CPU_6362 || BCM63XX_CPU_6368 || BCM63XX_CPU_63268)
 	default HW_RANDOM
 	---help---
 	  This driver provides kernel-side support for the Random Number
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [Patch][BCM63XX] Select HW_RANDOM_BCM63XX only in the SoCs that support it.

[José Vázquez]

2014-06-06 22:00 GMT+02:00, Jonas Gorski j...@openwrt.org:
 On Fri, Jun 6, 2014 at 9:52 PM, Florian Fainelli flor...@openwrt.org
 wrote:
 2014-06-06 12:46 GMT-07:00 José Vázquez Fernández
 ppvazquez...@gmail.com:
 Select HW_RANDOM_BCM63XX only in the SoCs that support it.

 Only BCM6368, BCM6362 and BCM63268 have a hardware random numbers
 generator,
 so, if none of these are selected, don't compile a driver that has no
 effect.

 Tested with BCM6358 and BCM6328 successfully.

 How about a Kconfig symbol such as BCM63XX_HAS_HWRANDOM that gets
 selected by only the SoCs that support it? Hopefully in the future,
 this list should grow rather than shrink.

 I think if you do the effort of disabling specific SoC support, then
 it isn't too much asked to also manually de-select the rng driver.

If you deselect HW_RANDOM, when compiling the kernel sends an error,
which is the reason of the patch.
 Also I think that we should go the other way and allow compilation of
 it for !BCM63XX if COMPILE_TEST is enabled, to allow better build test
 coverage.

Do you mean something like this?
http://lists.linaro.org/pipermail/linaro-kernel/2013-July/005078.html

 And finally, these kind of patches should go to linux-mips.


 Regards
 Jonas

Are you sure about linux-mips? It scares me a bit.
Would not be better publish a patch here and Florian, Kevin Cernekee
or you send it with the adequate and professional description?

Regards:

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

Re: [OpenWrt-Devel] [PATCH] [LANTIQ]ath5k fix in wifi and ethernet eeprom handling patch.

[José Vázquez]

2014-06-04 7:20 GMT+02:00, John Crispin j...@phrozen.org:


 On 04/06/2014 00:04, José Vázquez wrote:
 2014-06-03 21:35 GMT+02:00, John Crispin j...@phrozen.org:
 Thanks,

 does ath5k work after applying this patch ? i dont have any hw to
 test with ...

 John

 The ath5k driver using an ARV4518PW works as good as always, at
 least for me, and the wireless MAC is read correctly.

 ok, thanks for testing i will merge the patch today

   John

Sorry, made a terrible mistake: i sent the patch without 6 important lines!
  obj-$(CONFIG_XRX200_PHY_FW) += xrx200_phy_fw.o
 --- /dev/null
 +++ b/arch/mips/lantiq/xway/ath_eep.c
-@@ -0,0 +1,248 @@
+@@ -0,0 +1,250 @@
 +/*
 + *  Copyright (C) 2011 Luca Olivetti l...@ventoso.org
 + *  Copyright (C) 2011 John Crispin blo...@openwrt.org

Without the change from +1,248 to +1,250, when ath_eep.c is created,
it lacks the last two lines, causing a compilation error.
My apologies for the inconveniences.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] [LANTIQ]ath5k fix in wifi and ethernet eeprom handling patch.

[José Vázquez Fernández]

ath5k fix in wifi and ethernet eeprom handling patch.

Without the line that adds the patch of_ath5k_eeprom_probe cause a 
kernel panic, at least with the ARV4518PW.

Tested only in the modem-router mentioned above.

This patch is based in Bruno's hack present in patch #5454.

Signed off by: Bruno Rodríguez bruno.rodriguez.1...@gmail.com
Signed off by: José Vázquez Fernández ppvazquez...@gmail.com

diff --git a/target/linux/lantiq/patches-3.10/0010-MIPS-lantiq-wifi-and-ethernet-eeprom-handling.patch b/target/linux/lantiq/patches-3.10/0010-MIPS-lantiq-wifi-and-ethernet-eeprom-handling.patch
index 403ee97..93a58f7 100644
--- a/target/linux/lantiq/patches-3.10/0010-MIPS-lantiq-wifi-and-ethernet-eeprom-handling.patch
+++ b/target/linux/lantiq/patches-3.10/0010-MIPS-lantiq-wifi-and-ethernet-eeprom-handling.patch
@@ -246,6 +247,8 @@ Subject: [PATCH 18/22] owrt: lantiq: wifi and ethernet eeprom handling
 +		}
 +
 +		eep = ioremap(eep_res-start, resource_size(eep_res));
++		ath5k_pdata.eeprom_data = kmalloc(ATH5K_PLAT_EEP_MAX_WORDS1,
++GFP_KERNEL);
 +		memcpy_fromio(ath5k_pdata.eeprom_data, eep,
 +ATH5K_PLAT_EEP_MAX_WORDS  1);
 +	}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] [LANTIQ]ath5k fix in wifi and ethernet eeprom handling patch.

[José Vázquez]

2014-06-03 21:35 GMT+02:00, John Crispin j...@phrozen.org:
 Thanks,

 does ath5k work after applying this patch ? i dont have any hw to test
 with ...

   John

The ath5k driver using an ARV4518PW works as good as always, at least
for me, and the wireless MAC is read correctly.

[0.30] ath5k,eeprom 103f0400.ath5k_eep: loaded ath5k eeprom
...
[   10.572000] PCI: Enabling device :00:0e.0 ( - 0002)
[   10.576000] ath5k :00:0e.0: registered as 'phy0'
[   10.588000] ath: EEPROM regdomain: 0x60
[   10.592000] ath: EEPROM indicates we should expect a direct regpair map
[   10.596000] ath: Country alpha2 being used: 00
[   10.60] ath: Regpair used: 0x60
[   10.608000] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[   10.624000] ath5k: phy0: Atheros AR2417 chip found (MAC: 0xf0, PHY: 0x70)
...
[   24.668000] wlan0: authenticate with 64:70:02:
[   24.68] wlan0: send auth to 64:70:02: (try 1/3)
[   24.684000] wlan0: authenticated
[   24.692000] wlan0: associate with 64:70:02: (try 1/3)
[   24.70] wlan0: RX AssocResp from 64:70:02: (capab=0x431 status=0 aid=1)
[   24.708000] wlan0: associated

But as you say will be better if the patch can be tested in other
boards, especially the sx762.

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

[OpenWrt-Devel] [PATCH][bcm63xx]: Support for Comtrend VR-3025u and VR-3025un.

[José Vázquez Fernández]

Support for Comtrend VR-3025u and VR-3025un.

This patch adds support for both VR-3025u and VR-3025un.
Due to these routers are very close in terms of board definitions 
because the only differences are a led name and the board_id, the patch 
covers both boards.


Signed off by: José Vázquez Fernández ppvazquez...@gmail.com
Signed off by: Álvaro Fernández nolt...@gmail.com

Index: target/linux/brcm63xx/image/Makefile
===
--- target/linux/brcm63xx/image/Makefile(revisión: 40826)
+++ target/linux/brcm63xx/image/Makefile(copia de trabajo)
@@ -190,6 +190,10 @@
$(call Image/Build/CFE,$(1),96368MVNgr,6368,96368MVNgr-generic)
$(call Image/Build/CFE,$(1),96368MVWG,6368,96368MVWG-generic)

+   # Comtrend VR-3025xx
+   $(call Image/Build/CFE,$(1),96368M-1541N,6368,VR-3025u,,--pad 16)
+   $(call Image/Build/CFE,$(1),96368M-1341N,6368,VR-3025un,,--pad 4)
+
# Asmax AR 1004g
$(call Image/Build/CFEFIXUP,$(1),96348GW-10,AR1004G,6348,AR1004G)
# BT Voyager V210_BTR
Index: target/linux/brcm63xx/patches-3.10/561-VR_3025.patch
===
--- target/linux/brcm63xx/patches-3.10/561-VR_3025.patch(revisión: 0)
+++ target/linux/brcm63xx/patches-3.10/561-VR_3025.patch(revisión: 0)
@@ -0,0 +1,202 @@
+--- a/arch/mips/bcm63xx/boards/board_bcm963xx.c
 b/arch/mips/bcm63xx/boards/board_bcm963xx.c
+@@ -4334,6 +4334,190 @@ static struct board_info __initdata boar
+  * known 6368 boards
+  */
+ #ifdef CONFIG_BCM63XX_CPU_6368
++static struct board_info __initdata board_VR3025u = {
++  .name   = 96368M-1541N,
++  .expected_cpu_id= 0x6368,
++
++  .has_uart0  = 1,
++  .has_pci= 1,
++  .has_ohci0  = 1,
++  .has_ehci0  = 1,
++
++  .has_enetsw = 1,
++  .enetsw = {
++  .used_ports = {
++  [0] = {
++  .used   = 1,
++  .phy_id = 1,
++  .name   = port1,
++  },
++  [1] = {
++  .used   = 1,
++  .phy_id = 2,
++  .name   = port2,
++  },
++  [2] = {
++  .used   = 1,
++  .phy_id = 3,
++  .name   = port3,
++  },
++  [3] = {
++  .used   = 1,
++  .phy_id = 4,
++  .name   = port4,
++  },
++  },
++  },
++
++  .leds = {
++  {
++  .name   = VR-3025u:green:dsl,
++  .gpio   = 2,
++  .active_low = 1,
++  },
++  {
++  .name   = VR-3025u:green:inet,
++  .gpio   = 5,
++  },
++  {
++  .name   = VR-3025u:green:lan1,
++  .gpio   = 6,
++  .active_low = 1,
++  },
++  {
++  .name   = VR-3025u:green:lan2,
++  .gpio   = 7,
++  .active_low = 1,
++  },
++  {
++  .name   = VR-3025u:green:lan3,
++  .gpio   = 8,
++  .active_low = 1,
++  },
++  {
++  .name   = VR-3025u:green:lan4,
++  .gpio   = 9,
++  .active_low = 1,
++  },
++  {
++  .name   = VR-3025u:green:power,
++  .gpio   = 22,
++  .default_trigger = default-on,
++  },
++  {
++  .name   = VR-3025u:red:power,
++  .gpio   = 24,
++  },
++  {
++  .name   = VR-3025u:red:inet,
++  .gpio   = 31,
++  },
++  },
++
++  .buttons = {
++  {
++  .desc   = reset,
++  .gpio   = 34,
++  .type   = EV_KEY,
++  .code   = KEY_RESTART,
++  .debounce_interval

[OpenWrt-Devel] [PATCH] [Lantiq] ltq-hcd: disable mips16 support

[José Vázquez Fernández]

ltq-hcd: disable mips16 support.

This patch disables mips16 support in the ltq-hcd driver because some
people reported slow speed and problems with usb storage devices, 3G
dongles and wireless usb adapters.

Signed off by: José Vázquez Fernández ppvazquez...@gmail.com


Index: package/kernel/lantiq/ltq-hcd/Makefile
===
--- package/kernel/lantiq/ltq-hcd/Makefile  (revisión: 40772)
+++ package/kernel/lantiq/ltq-hcd/Makefile  (copia de trabajo)
@@ -10,6 +10,8 @@
 PKG_RELEASE:=1
 PKG_BUILD_DIR:=$(KERNEL_BUILD_DIR)/ltq-hcd-$(BUILD_VARIANT)
 
+PKG_USE_MIPS16:=0
+
 PKG_MAINTAINER:=John Crispin blo...@openwrt.org
 
 include $(INCLUDE_DIR)/package.mk
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] [lantiq] [1/2] V2: EEPROM fix for Atheros wireless based boards.

[José Vázquez Fernández]

EEPROM fix for Atheros wireless based boards.

V2: previous patch was mangled and the subject was corrected.

This patch fixes a problem in some Astoria/Arcadyan routers with Atheros
based wireless. In these boards the flash partition that contains the
MAC and calibration data is not read properly, causing the driver to not
initialize the wireless.

[   13.772000] PCI: Enabling device :00:0e.0 ( - 0002)
[   13.776000] ath5k :00:0e.0: registered as 'phy0'
[   15.024000] ath5k: phy0: unable to init EEPROM
[   15.024000] ath5k: probe of :00:0e.0 failed with error -5

This patch covers both ath5k and ath9k drivers.

Signed off by: David Fernández papijunkm...@yahoo.com
Signed off by: Bruno Rodríguez bruno.rodriguez.1...@gmail.com
Signed off by: Álvaro Fernández nolt...@gmail.com
Tested by: José Vázquez Fernández ppvazquez...@gmail.com


Index: target/linux/lantiq/patches-3.10/0203-arv-athx-workaround.patch
===
--- target/linux/lantiq/patches-3.10/0203-arv-athx-workaround.patch
(revisión: 0)
+++ target/linux/lantiq/patches-3.10/0203-arv-athx-workaround.patch
(revisión: 0)
@@ -0,0 +1,447 @@
+--- a/arch/mips/lantiq/xway/ath_eep.c
 b/arch/mips/lantiq/xway/ath_eep.c
+@@ -41,94 +41,182 @@ int __init of_ath9k_eeprom_probe(struct
+ {
+   struct device_node *np = pdev-dev.of_node, *mtd_np;
+   int mac_offset, led_pin;
++  struct resource *eep_res, *mac_res;
++  void __iomem *eep, *mac;
++  int mac_offset;
+   u32 mac_inc = 0, pci_slot = 0;
+   int i;
++  u16 *eepdata, sum, el;
+   struct mtd_info *the_mtd;
+   size_t flash_readlen;
+   const __be32 *list;
+   const char *part;
+   phandle phandle;
+ 
+-  list = of_get_property(np, ath,eep-flash, i);
+-  if (!list || (i !=  (2 * sizeof(*list {
+-  dev_err(pdev-dev, failed to find ath,eep-flash\n);
+-  return -ENODEV;
+-  }
++  if (!of_find_property(np,ath,arv-ath9k-fix,NULL))
++  {
++  list = of_get_property(np, ath,eep-flash, i);
++  if (!list || (i !=  (2 * sizeof(*list {
++  dev_err(pdev-dev, failed to find ath,eep-flash\n);
++  return -ENODEV;
++  }
+ 
+-  phandle = be32_to_cpup(list++);
+-  if (!phandle) {
+-  dev_err(pdev-dev, failed to find phandle\n);
+-  return -ENODEV;
+-  }
++  phandle = be32_to_cpup(list++);
++  if (!phandle) {
++  dev_err(pdev-dev, failed to find phandle\n);
++  return -ENODEV;
++  }
+ 
+-  mtd_np = of_find_node_by_phandle(phandle);
+-  if (!mtd_np) {
+-  dev_err(pdev-dev, failed to find mtd node\n);
+-  return -ENODEV;
+-  }
++  mtd_np = of_find_node_by_phandle(phandle);
++  if (!mtd_np) {
++  dev_err(pdev-dev, failed to find mtd node\n);
++  return -ENODEV;
++  }
+ 
+-  part = of_get_property(mtd_np, label, NULL);
+-  if (!part)
+-  part = mtd_np-name;
+-
+-  the_mtd = get_mtd_device_nm(part);
+-  if (the_mtd == ERR_PTR(-ENODEV)) {
+-  dev_err(pdev-dev, failed to find mtd device\n);
+-  return -ENODEV;
+-  }
++  part = of_get_property(mtd_np, label, NULL);
++  if (!part)
++  part = mtd_np-name;
++
++  the_mtd = get_mtd_device_nm(part);
++  if (the_mtd == ERR_PTR(-ENODEV)){
++  dev_err(pdev-dev, failed to find mtd device\n);
++  return -ENODEV;
++  }
+ 
+-  i = mtd_read(the_mtd, be32_to_cpup(list),
++  i = mtd_read(the_mtd, be32_to_cpup(list),
+   ATH9K_PLAT_EEP_MAX_WORDS  1, flash_readlen,
+   (void *) ath9k_pdata.eeprom_data);
+-  put_mtd_device(the_mtd);
+-  if ((sizeof(ath9k_pdata.eeprom_data) != flash_readlen) || i) {
+-  dev_err(pdev-dev, failed to load eeprom from mtd\n);
+-  return -ENODEV;
+-  }
++  put_mtd_device(the_mtd);
++  if ((sizeof(ath9k_pdata.eeprom_data) != flash_readlen) || i) {
++  dev_err(pdev-dev, failed to load eeprom from mtd\n);
++  return -ENODEV;
++  }
+ 
+-  if (of_find_property(np, ath,eep-swap, NULL))
+-  for (i = 0; i  ATH9K_PLAT_EEP_MAX_WORDS; i++)
+-  ath9k_pdata.eeprom_data[i] = 
swab16(ath9k_pdata.eeprom_data[i]);
++  if (of_find_property(np, ath,eep-swap, NULL))
++  for (i = 0; i  ATH9K_PLAT_EEP_MAX_WORDS; i++)
++  ath9k_pdata.eeprom_data[i] = 
swab16(ath9k_pdata.eeprom_data[i]);
++
++  if (of_find_property(np, ath,eep-endian, NULL

Re: [OpenWrt-Devel] [PATCH][bcm63xx]: add Livebox 1 firmware image generation

[José Vázquez]

2014-04-22 22:10 GMT+02:00, dani dgcb...@gmail.com:
 Currently there isn't images ready for flashing liveboxes boards. This patch
 adds a
 script and the code to call it in the  bcm63xx images builder makefile  to
 generate the
 livebox 1 firmware.

 I removed some lines to avoid generating unneded files in the bin/ dir for
 this board.
 And added code to generate a squashed rootfs aligned to 64 kB since the
 current
 one in the /bin dir is 128 kB aligned and doesn't work. Still no sysupgrade
 support
 for this board. Upgrading from within openwrt can be done writing with mtd
 the kernel,
 and then the 64k aligned rootfs.

 Regards

 Signed-off-by: Daniel Gonzalez dgcb...@gmail.com
Tested by: José Vázquez Fernández ppvazquez...@gmail.com
 Index: target/linux/brcm63xx/image/Makefile
 ===
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] [lantiq] [2/2] DTS updates for the ARV4518PW and ARV7518PW.

[José Vázquez Fernández]

DTS updates for the ARV4518PW and ARV7518PW.

These additions make the previous patch work in these boards, and adds
switch reset gpio and removes vmmc relay gpio in the ARV4518PW because
it is not present.
Also changes phy-mode to mii, which is the right configuration.

Signed off by: David Fernández papijunkm...@yahoo.com
Signed off by: Bruno Rodríguez bruno.rodriguez.1...@gmail.com
Signed off by: José Vázquez Fernández ppvazquez...@gmail.com


Index: target/linux/lantiq/dts/ARV4518PWR01.dts
===
--- target/linux/lantiq/dts/ARV4518PWR01.dts(revisión: 40772)
+++ target/linux/lantiq/dts/ARV4518PWR01.dts(copia de trabajo)
@@ -75,6 +75,7 @@
0 0x3f0016 0x6;
ath,mac-increment = 1;
ath,eep-swap;
+   ath,arv-ath5k-fix;
};
};
 
@@ -100,11 +101,31 @@
lantiq,pull = 0;
lantiq,output = 1;
};
+   pci_rst {
+   lantiq,pins = io21;
+   lantiq,pull = 2;
+   lantiq,output = 1;
+   };
+   leds {
+   lantiq,pins = io3, io4, io5, 
io6, io7, io8, io19;
+   lantiq,output = 1;
+   };
+   keys {
+   lantiq,pins = io28, io30;
+   lantiq,output = 0;
+   lantiq,pull = 2;
+   lantiq,open-drain = 1;
+   };
+   switch_rst {
+   lantiq,pins = io13;
+   lantiq,pull = 2;
+   lantiq,output = 1;
+   };
};
};
 
etop@E18 {
-   phy-mode = rmii;
+   phy-mode = mii;
};
 
ifxhcd@E101000 {
@@ -121,9 +142,6 @@
 
};
 
-/*
-#define ARV4518PW_SWITCH_RESET  13
-*/
gpio-keys-polled {
compatible = gpio-keys-polled;
#address-cells = 1;
@@ -146,7 +164,7 @@
compatible = gpio-leds;
power {
label = power;
-   gpios = gpio 3 0;
+   gpios = gpio 3 1;
};
dsl {
label = dsl;
@@ -189,4 +207,15 @@
gpios = gpiomm 3 1;
};
};
+
+   gpio_export {
+   compatible = gpio-export;
+   #size-cells = 0;
+
+   switch {
+   gpio-export,name = switch;
+   gpio-export,output = 1;
+   gpios = gpio 13 0;
+   };
+   };
 };
Index: target/linux/lantiq/dts/ARV4518PWR01A.dts
===
--- target/linux/lantiq/dts/ARV4518PWR01A.dts   (revisión: 40772)
+++ target/linux/lantiq/dts/ARV4518PWR01A.dts   (copia de trabajo)
@@ -75,6 +75,7 @@
0 0x3f0016 0x6;
ath,mac-increment = 1;
ath,eep-swap;
+   ath,arv-ath5k-fix;
};
};
 
@@ -100,11 +101,31 @@
lantiq,pull = 0;
lantiq,output = 1;
};
+   pci_rst {
+   lantiq,pins = io21;
+   lantiq,pull = 2;
+   lantiq,output = 1;
+   };
+   leds {
+   lantiq,pins = io3, io4, io5, 
io6, io7, io8, io19;
+   lantiq,output = 1;
+   };
+   keys {
+   lantiq,pins = io28, io30;
+   lantiq,output = 0;
+   lantiq,pull = 2;
+   lantiq,open-drain = 1;
+   };
+   switch_rst {
+   lantiq,pins = io13;
+   lantiq,pull = 2;
+   lantiq

[OpenWrt-Devel] [PATCH] [lantiq] [1/2] EEPROM fix for Astoria/Arcadyan boards.

[José Vázquez Fernández]

EEPROM fix for Astoria/Arcadyan boards.

This patch fixes a problem in some Astoria/Arcadyan routers with Atheros
based wireless. In these boards the flash partition that contains the
MAC and calibration data is not read properly, causing the driver to not
initialize the wireless.

[   13.772000] PCI: Enabling device :00:0e.0 ( - 0002)
[   13.776000] ath5k :00:0e.0: registered as 'phy0'
[   15.024000] ath5k: phy0: unable to init EEPROM
[   15.024000] ath5k: probe of :00:0e.0 failed with error -5

This patch covers both ath5k and ath9k drivers.

Signed off by: David Fernández papijunkm...@yahoo.com
Signed off by: Bruno Rodríguez bruno.rodriguez.1...@gmail.com
Signed off by: Álvaro Fernández nolt...@gmail.com
Tested by: José Vázquez Fernández ppvazquez...@gmail.com


--- a/arch/mips/lantiq/xway/ath_eep.c
+++ b/arch/mips/lantiq/xway/ath_eep.c
@@ -41,94 +41,182 @@ int __init of_ath9k_eeprom_probe(struct
 {
struct device_node *np = pdev-dev.of_node, *mtd_np;
int mac_offset, led_pin;
+   struct resource *eep_res, *mac_res;
+   void __iomem *eep, *mac;
+   int mac_offset;
u32 mac_inc = 0, pci_slot = 0;
int i;
+   u16 *eepdata, sum, el;
struct mtd_info *the_mtd;
size_t flash_readlen;
const __be32 *list;
const char *part;
phandle phandle;
 
-   list = of_get_property(np, ath,eep-flash, i);
-   if (!list || (i !=  (2 * sizeof(*list {
-   dev_err(pdev-dev, failed to find ath,eep-flash\n);
-   return -ENODEV;
-   }
+   if (!of_find_property(np,ath,arv-ath9k-fix,NULL))
+   {
+   list = of_get_property(np, ath,eep-flash, i);
+   if (!list || (i !=  (2 * sizeof(*list {
+   dev_err(pdev-dev, failed to find ath,eep-flash\n);
+   return -ENODEV;
+   }
 
-   phandle = be32_to_cpup(list++);
-   if (!phandle) {
-   dev_err(pdev-dev, failed to find phandle\n);
-   return -ENODEV;
-   }
+   phandle = be32_to_cpup(list++);
+   if (!phandle) {
+   dev_err(pdev-dev, failed to find phandle\n);
+   return -ENODEV;
+   }
 
-   mtd_np = of_find_node_by_phandle(phandle);
-   if (!mtd_np) {
-   dev_err(pdev-dev, failed to find mtd node\n);
-   return -ENODEV;
-   }
+   mtd_np = of_find_node_by_phandle(phandle);
+   if (!mtd_np) {
+   dev_err(pdev-dev, failed to find mtd node\n);
+   return -ENODEV;
+   }
 
-   part = of_get_property(mtd_np, label, NULL);
-   if (!part)
-   part = mtd_np-name;
-
-   the_mtd = get_mtd_device_nm(part);
-   if (the_mtd == ERR_PTR(-ENODEV)) {
-   dev_err(pdev-dev, failed to find mtd device\n);
-   return -ENODEV;
-   }
+   part = of_get_property(mtd_np, label, NULL);
+   if (!part)
+   part = mtd_np-name;
+
+   the_mtd = get_mtd_device_nm(part);
+   if (the_mtd == ERR_PTR(-ENODEV)){
+   dev_err(pdev-dev, failed to find mtd device\n);
+   return -ENODEV;
+   }
 
-   i = mtd_read(the_mtd, be32_to_cpup(list),
+   i = mtd_read(the_mtd, be32_to_cpup(list),
ATH9K_PLAT_EEP_MAX_WORDS  1, flash_readlen,
(void *) ath9k_pdata.eeprom_data);
-   put_mtd_device(the_mtd);
-   if ((sizeof(ath9k_pdata.eeprom_data) != flash_readlen) || i) {
-   dev_err(pdev-dev, failed to load eeprom from mtd\n);
-   return -ENODEV;
-   }
+   put_mtd_device(the_mtd);
+   if ((sizeof(ath9k_pdata.eeprom_data) != flash_readlen) || i) {
+   dev_err(pdev-dev, failed to load eeprom from mtd\n);
+   return -ENODEV;
+   }
 
-   if (of_find_property(np, ath,eep-swap, NULL))
-   for (i = 0; i  ATH9K_PLAT_EEP_MAX_WORDS; i++)
-   ath9k_pdata.eeprom_data[i] = 
swab16(ath9k_pdata.eeprom_data[i]);
+   if (of_find_property(np, ath,eep-swap, NULL))
+   for (i = 0; i  ATH9K_PLAT_EEP_MAX_WORDS; i++)
+   ath9k_pdata.eeprom_data[i] = 
swab16(ath9k_pdata.eeprom_data[i]);
+
+   if (of_find_property(np, ath,eep-endian, NULL)) {
+   ath9k_pdata.endian_check = true;
+   dev_info(pdev-dev, endian check enabled.\n);
+   }
 
-   if (of_find_property(np, ath,eep-endian, NULL)) {
-   ath9k_pdata.endian_check = true;
+   if (!of_property_read_u32(np, ath,mac-offset, mac_offset)) {
+   memcpy_fromio(athxk_eeprom_mac, (void*) 
ath9k_pdata.eeprom_data +
mac_offset, 6

[OpenWrt-Devel] [PATCH] [lantiq] [1/2] EEPROM fix for Astoria/Arcadyan boards.

[José Vázquez Fernández]

- Mensaje reenviado 
De: José Vázquez Fernández ppvazquez...@gmail.com
Para: openwrt-devel openwrt-devel@lists.openwrt.org
Asunto: [OpenWrt-Devel] [PATCH] [lantiq] [1/2] EEPROM fix for
Astoria/Arcadyan boards.
Fecha: Fri, 16 May 2014 19:47:03 +0200

EEPROM fix for Astoria/Arcadyan boards.

This patch fixes a problem in some Astoria/Arcadyan routers with Atheros
based wireless. In these boards the flash partition that contains the
MAC and calibration data is not read properly, causing the driver to not
initialize the wireless.

[   13.772000] PCI: Enabling device :00:0e.0 ( - 0002)
[   13.776000] ath5k :00:0e.0: registered as 'phy0'
[   15.024000] ath5k: phy0: unable to init EEPROM
[   15.024000] ath5k: probe of :00:0e.0 failed with error -5

This patch covers both ath5k and ath9k drivers.

Signed off by: David Fernández papijunkm...@yahoo.com
Signed off by: Bruno Rodríguez bruno.rodriguez.1...@gmail.com
Signed off by: Álvaro Fernández nolt...@gmail.com
Tested by: José Vázquez Fernández ppvazquez...@gmail.com


Index: target/linux/lantiq/patches-3.10/0203-arv-athx-workaround.patch
===
--- target/linux/lantiq/patches-3.10/0203-arv-athx-workaround.patch
(revisión: 0)
+++ target/linux/lantiq/patches-3.10/0203-arv-athx-workaround.patch
(revisión: 0)
@@ -0,0 +1,447 @@
+--- a/arch/mips/lantiq/xway/ath_eep.c
 b/arch/mips/lantiq/xway/ath_eep.c
+@@ -41,94 +41,182 @@ int __init of_ath9k_eeprom_probe(struct
+ {
+   struct device_node *np = pdev-dev.of_node, *mtd_np;
+   int mac_offset, led_pin;
++  struct resource *eep_res, *mac_res;
++  void __iomem *eep, *mac;
++  int mac_offset;
+   u32 mac_inc = 0, pci_slot = 0;
+   int i;
++  u16 *eepdata, sum, el;
+   struct mtd_info *the_mtd;
+   size_t flash_readlen;
+   const __be32 *list;
+   const char *part;
+   phandle phandle;
+ 
+-  list = of_get_property(np, ath,eep-flash, i);
+-  if (!list || (i !=  (2 * sizeof(*list {
+-  dev_err(pdev-dev, failed to find ath,eep-flash\n);
+-  return -ENODEV;
+-  }
++  if (!of_find_property(np,ath,arv-ath9k-fix,NULL))
++  {
++  list = of_get_property(np, ath,eep-flash, i);
++  if (!list || (i !=  (2 * sizeof(*list {
++  dev_err(pdev-dev, failed to find ath,eep-flash\n);
++  return -ENODEV;
++  }
+ 
+-  phandle = be32_to_cpup(list++);
+-  if (!phandle) {
+-  dev_err(pdev-dev, failed to find phandle\n);
+-  return -ENODEV;
+-  }
++  phandle = be32_to_cpup(list++);
++  if (!phandle) {
++  dev_err(pdev-dev, failed to find phandle\n);
++  return -ENODEV;
++  }
+ 
+-  mtd_np = of_find_node_by_phandle(phandle);
+-  if (!mtd_np) {
+-  dev_err(pdev-dev, failed to find mtd node\n);
+-  return -ENODEV;
+-  }
++  mtd_np = of_find_node_by_phandle(phandle);
++  if (!mtd_np) {
++  dev_err(pdev-dev, failed to find mtd node\n);
++  return -ENODEV;
++  }
+ 
+-  part = of_get_property(mtd_np, label, NULL);
+-  if (!part)
+-  part = mtd_np-name;
+-
+-  the_mtd = get_mtd_device_nm(part);
+-  if (the_mtd == ERR_PTR(-ENODEV)) {
+-  dev_err(pdev-dev, failed to find mtd device\n);
+-  return -ENODEV;
+-  }
++  part = of_get_property(mtd_np, label, NULL);
++  if (!part)
++  part = mtd_np-name;
++
++  the_mtd = get_mtd_device_nm(part);
++  if (the_mtd == ERR_PTR(-ENODEV)){
++  dev_err(pdev-dev, failed to find mtd device\n);
++  return -ENODEV;
++  }
+ 
+-  i = mtd_read(the_mtd, be32_to_cpup(list),
++  i = mtd_read(the_mtd, be32_to_cpup(list),
+   ATH9K_PLAT_EEP_MAX_WORDS  1, flash_readlen,
+   (void *) ath9k_pdata.eeprom_data);
+-  put_mtd_device(the_mtd);
+-  if ((sizeof(ath9k_pdata.eeprom_data) != flash_readlen) || i) {
+-  dev_err(pdev-dev, failed to load eeprom from mtd\n);
+-  return -ENODEV;
+-  }
++  put_mtd_device(the_mtd);
++  if ((sizeof(ath9k_pdata.eeprom_data) != flash_readlen) || i) {
++  dev_err(pdev-dev, failed to load eeprom from mtd\n);
++  return -ENODEV;
++  }
+ 
+-  if (of_find_property(np, ath,eep-swap, NULL))
+-  for (i = 0; i  ATH9K_PLAT_EEP_MAX_WORDS; i++)
+-  ath9k_pdata.eeprom_data[i] = 
swab16(ath9k_pdata.eeprom_data[i]);
++  if (of_find_property(np, ath,eep-swap, NULL))
++  for (i = 0; i  ATH9K_PLAT_EEP_MAX_WORDS; i

[OpenWrt-Devel] [PATCH] [lantiq] [1/2] [V2] EEPROM fix for Astoria/Arcadyan boards.

[José Vázquez Fernández]

EEPROM fix for Astoria/Arcadyan boards.

This patch fixes a problem in some Astoria/Arcadyan routers with Atheros
based wireless. In these boards the flash partition that contains the
MAC and calibration data is not read properly, causing the driver to not
initialize the wireless.

[   13.772000] PCI: Enabling device :00:0e.0 ( - 0002)
[   13.776000] ath5k :00:0e.0: registered as 'phy0'
[   15.024000] ath5k: phy0: unable to init EEPROM
[   15.024000] ath5k: probe of :00:0e.0 failed with error -5

This patch covers both ath5k and ath9k drivers.

Signed off by: David Fernández papijunkm...@yahoo.com
Signed off by: Bruno Rodríguez bruno.rodriguez.1...@gmail.com
Signed off by: Álvaro Fernández nolt...@gmail.com
Tested by: José Vázquez Fernández ppvazquez...@gmail.com


Index: target/linux/lantiq/patches-3.10/0203-arv-athx-workaround.patch
===
--- target/linux/lantiq/patches-3.10/0203-arv-athx-workaround.patch
(revisión: 0)
+++ target/linux/lantiq/patches-3.10/0203-arv-athx-workaround.patch
(revisión: 0)
@@ -0,0 +1,447 @@
+--- a/arch/mips/lantiq/xway/ath_eep.c
 b/arch/mips/lantiq/xway/ath_eep.c
+@@ -41,94 +41,182 @@ int __init of_ath9k_eeprom_probe(struct
+ {
+   struct device_node *np = pdev-dev.of_node, *mtd_np;
+   int mac_offset, led_pin;
++  struct resource *eep_res, *mac_res;
++  void __iomem *eep, *mac;
++  int mac_offset;
+   u32 mac_inc = 0, pci_slot = 0;
+   int i;
++  u16 *eepdata, sum, el;
+   struct mtd_info *the_mtd;
+   size_t flash_readlen;
+   const __be32 *list;
+   const char *part;
+   phandle phandle;
+ 
+-  list = of_get_property(np, ath,eep-flash, i);
+-  if (!list || (i !=  (2 * sizeof(*list {
+-  dev_err(pdev-dev, failed to find ath,eep-flash\n);
+-  return -ENODEV;
+-  }
++  if (!of_find_property(np,ath,arv-ath9k-fix,NULL))
++  {
++  list = of_get_property(np, ath,eep-flash, i);
++  if (!list || (i !=  (2 * sizeof(*list {
++  dev_err(pdev-dev, failed to find ath,eep-flash\n);
++  return -ENODEV;
++  }
+ 
+-  phandle = be32_to_cpup(list++);
+-  if (!phandle) {
+-  dev_err(pdev-dev, failed to find phandle\n);
+-  return -ENODEV;
+-  }
++  phandle = be32_to_cpup(list++);
++  if (!phandle) {
++  dev_err(pdev-dev, failed to find phandle\n);
++  return -ENODEV;
++  }
+ 
+-  mtd_np = of_find_node_by_phandle(phandle);
+-  if (!mtd_np) {
+-  dev_err(pdev-dev, failed to find mtd node\n);
+-  return -ENODEV;
+-  }
++  mtd_np = of_find_node_by_phandle(phandle);
++  if (!mtd_np) {
++  dev_err(pdev-dev, failed to find mtd node\n);
++  return -ENODEV;
++  }
+ 
+-  part = of_get_property(mtd_np, label, NULL);
+-  if (!part)
+-  part = mtd_np-name;
+-
+-  the_mtd = get_mtd_device_nm(part);
+-  if (the_mtd == ERR_PTR(-ENODEV)) {
+-  dev_err(pdev-dev, failed to find mtd device\n);
+-  return -ENODEV;
+-  }
++  part = of_get_property(mtd_np, label, NULL);
++  if (!part)
++  part = mtd_np-name;
++
++  the_mtd = get_mtd_device_nm(part);
++  if (the_mtd == ERR_PTR(-ENODEV)){
++  dev_err(pdev-dev, failed to find mtd device\n);
++  return -ENODEV;
++  }
+ 
+-  i = mtd_read(the_mtd, be32_to_cpup(list),
++  i = mtd_read(the_mtd, be32_to_cpup(list),
+   ATH9K_PLAT_EEP_MAX_WORDS  1, flash_readlen,
+   (void *) ath9k_pdata.eeprom_data);
+-  put_mtd_device(the_mtd);
+-  if ((sizeof(ath9k_pdata.eeprom_data) != flash_readlen) || i) {
+-  dev_err(pdev-dev, failed to load eeprom from mtd\n);
+-  return -ENODEV;
+-  }
++  put_mtd_device(the_mtd);
++  if ((sizeof(ath9k_pdata.eeprom_data) != flash_readlen) || i) {
++  dev_err(pdev-dev, failed to load eeprom from mtd\n);
++  return -ENODEV;
++  }
+ 
+-  if (of_find_property(np, ath,eep-swap, NULL))
+-  for (i = 0; i  ATH9K_PLAT_EEP_MAX_WORDS; i++)
+-  ath9k_pdata.eeprom_data[i] = 
swab16(ath9k_pdata.eeprom_data[i]);
++  if (of_find_property(np, ath,eep-swap, NULL))
++  for (i = 0; i  ATH9K_PLAT_EEP_MAX_WORDS; i++)
++  ath9k_pdata.eeprom_data[i] = 
swab16(ath9k_pdata.eeprom_data[i]);
++
++  if (of_find_property(np, ath,eep-endian, NULL)) {
++  ath9k_pdata.endian_check = true;
++  dev_info(pdev-dev, endian check

[OpenWrt-Devel] [PATCH] [lantiq] [1/2] [V3] EEPROM fix for Astoria/Arcadyan boards.

[José Vázquez Fernández]

EEPROM fix for Astoria/Arcadyan boards.

This patch fixes a problem in some Astoria/Arcadyan routers with Atheros
based wireless. In these boards the flash partition that contains the
MAC and calibration data is not read properly, causing the driver to not
initialize the wireless.

[   13.772000] PCI: Enabling device :00:0e.0 ( - 0002)
[   13.776000] ath5k :00:0e.0: registered as 'phy0'
[   15.024000] ath5k: phy0: unable to init EEPROM
[   15.024000] ath5k: probe of :00:0e.0 failed with error -5

This patch covers both ath5k and ath9k drivers.

Signed off by: David Fernández papijunkm...@yahoo.com
Signed off by: Bruno Rodríguez bruno.rodriguez.1...@gmail.com
Signed off by: Álvaro Fernández nolt...@gmail.com
Tested by: José Vázquez Fernández ppvazquez...@gmail.com


Index: target/linux/lantiq/patches-3.10/0203-arv-athx-workaround.patch
===
--- target/linux/lantiq/patches-3.10/0203-arv-athx-workaround.patch
(revisión: 0)
+++ target/linux/lantiq/patches-3.10/0203-arv-athx-workaround.patch
(revisión: 0)
@@ -0,0 +1,447 @@
+--- a/arch/mips/lantiq/xway/ath_eep.c
 b/arch/mips/lantiq/xway/ath_eep.c
+@@ -41,94 +41,182 @@ int __init of_ath9k_eeprom_probe(struct
+ {
+   struct device_node *np = pdev-dev.of_node, *mtd_np;
+   int mac_offset, led_pin;
++  struct resource *eep_res, *mac_res;
++  void __iomem *eep, *mac;
++  int mac_offset;
+   u32 mac_inc = 0, pci_slot = 0;
+   int i;
++  u16 *eepdata, sum, el;
+   struct mtd_info *the_mtd;
+   size_t flash_readlen;
+   const __be32 *list;
+   const char *part;
+   phandle phandle;
+ 
+-  list = of_get_property(np, ath,eep-flash, i);
+-  if (!list || (i !=  (2 * sizeof(*list {
+-  dev_err(pdev-dev, failed to find ath,eep-flash\n);
+-  return -ENODEV;
+-  }
++  if (!of_find_property(np,ath,arv-ath9k-fix,NULL))
++  {
++  list = of_get_property(np, ath,eep-flash, i);
++  if (!list || (i !=  (2 * sizeof(*list {
++  dev_err(pdev-dev, failed to find ath,eep-flash\n);
++  return -ENODEV;
++  }
+ 
+-  phandle = be32_to_cpup(list++);
+-  if (!phandle) {
+-  dev_err(pdev-dev, failed to find phandle\n);
+-  return -ENODEV;
+-  }
++  phandle = be32_to_cpup(list++);
++  if (!phandle) {
++  dev_err(pdev-dev, failed to find phandle\n);
++  return -ENODEV;
++  }
+ 
+-  mtd_np = of_find_node_by_phandle(phandle);
+-  if (!mtd_np) {
+-  dev_err(pdev-dev, failed to find mtd node\n);
+-  return -ENODEV;
+-  }
++  mtd_np = of_find_node_by_phandle(phandle);
++  if (!mtd_np) {
++  dev_err(pdev-dev, failed to find mtd node\n);
++  return -ENODEV;
++  }
+ 
+-  part = of_get_property(mtd_np, label, NULL);
+-  if (!part)
+-  part = mtd_np-name;
+-
+-  the_mtd = get_mtd_device_nm(part);
+-  if (the_mtd == ERR_PTR(-ENODEV)) {
+-  dev_err(pdev-dev, failed to find mtd device\n);
+-  return -ENODEV;
+-  }
++  part = of_get_property(mtd_np, label, NULL);
++  if (!part)
++  part = mtd_np-name;
++
++  the_mtd = get_mtd_device_nm(part);
++  if (the_mtd == ERR_PTR(-ENODEV)){
++  dev_err(pdev-dev, failed to find mtd device\n);
++  return -ENODEV;
++  }
+ 
+-  i = mtd_read(the_mtd, be32_to_cpup(list),
++  i = mtd_read(the_mtd, be32_to_cpup(list),
+   ATH9K_PLAT_EEP_MAX_WORDS  1, flash_readlen,
+   (void *) ath9k_pdata.eeprom_data);
+-  put_mtd_device(the_mtd);
+-  if ((sizeof(ath9k_pdata.eeprom_data) != flash_readlen) || i) {
+-  dev_err(pdev-dev, failed to load eeprom from mtd\n);
+-  return -ENODEV;
+-  }
++  put_mtd_device(the_mtd);
++  if ((sizeof(ath9k_pdata.eeprom_data) != flash_readlen) || i) {
++  dev_err(pdev-dev, failed to load eeprom from mtd\n);
++  return -ENODEV;
++  }
+ 
+-  if (of_find_property(np, ath,eep-swap, NULL))
+-  for (i = 0; i  ATH9K_PLAT_EEP_MAX_WORDS; i++)
+-  ath9k_pdata.eeprom_data[i] = 
swab16(ath9k_pdata.eeprom_data[i]);
++  if (of_find_property(np, ath,eep-swap, NULL))
++  for (i = 0; i  ATH9K_PLAT_EEP_MAX_WORDS; i++)
++  ath9k_pdata.eeprom_data[i] = 
swab16(ath9k_pdata.eeprom_data[i]);
++
++  if (of_find_property(np, ath,eep-endian, NULL)) {
++  ath9k_pdata.endian_check = true;
++  dev_info(pdev-dev, endian check

Re: [OpenWrt-Devel] [PATCH v2][flashrom] Update to latest version and remove unneeded dependencies

[José Vázquez]

2014-05-09 8:32 GMT+02:00, Luka Perkov l...@openwrt.org:
 Hi Alvaro,

 I don't see this change. Patch v2 is same as v1.

 Luka

In v1 he eliminated cpu dependencies while in v2 dmidecode is only
selected by TARGET_x86.
I think that, in addition to x86 should be added x86_64 and any other
target that has dmi.

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

Re: [OpenWrt-Devel] [PATCH v2][flashrom] Update to latest version and remove unneeded dependencies

[José Vázquez]

Sure? maybe i am a bit blind. :(
V1:
Eliminated:  DEPENDS:=+zlib +pciutils +dmidecode +libftdi
+libusb-compat @(arm||armeb||i386||i686||x86_64)
Added:  DEPENDS:=+zlib +pciutils +dmidecode +libftdi +libusb-compat
V2:
Eliminated: DEPENDS:=+zlib +pciutils +dmidecode +libftdi
+libusb-compat @(arm||armeb||i386||i686||x86_64)
Added: DEPENDS:=+zlib +pciutils +TARGET_x86:dmidecode +libftdi +libusb-compat

Pepe

2014-05-09 10:34 GMT+02:00, Luka Perkov l...@openwrt.org:
 On Fri, May 09, 2014 at 10:28:50AM +0200, José Vázquez wrote:
 2014-05-09 8:32 GMT+02:00, Luka Perkov l...@openwrt.org:
  Hi Alvaro,
 
  I don't see this change. Patch v2 is same as v1.
 
  Luka
 
 In v1 he eliminated cpu dependencies while in v2 dmidecode is only
 selected by TARGET_x86.
 I think that, in addition to x86 should be added x86_64 and any other
 target that has dmi.

 Yes, it says that in the description but the patches are the same.

 Luka

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

Re: [OpenWrt-Devel] [PATCH v2][flashrom] Update to latest version and remove unneeded dependencies

[José Vázquez]

2014-05-09 12:13 GMT+02:00, Álvaro Fernández Rojas nolt...@gmail.com:
 Thanks for the help Pteridium. BTW, dmidecode is only available for x86, not
 for x86_64:
 https://dev.openwrt.org/browser/packages/utils/dmidecode/Makefile -
 DEPENDS:=@TARGET_x86

Yes an no: dmidecode was added before the inclusion of target x86_64.
According to the developers web page it works in 64bit machines and
OSs:
http://www.nongnu.org/dmidecode/
Unless i'm wrong the dmidecode makefile should be updated too; the
last change was in r25602

 @Luka: If you have any other suggestions or changes just tell me.

 P.S: Maybe we should completely remove dmidecode dependency, since it
 disables flashrom for any other targets (without this patch), and let the
 user select it if he wants that functionality.

 Álvaro

I think is dangerous if the dmidecode dependency is totally removed in
flashrom but i can be wrong.

Pepe

 El 09/05/2014 10:51, Luka Perkov escribió:
 On Fri, May 09, 2014 at 10:44:38AM +0200, José Vázquez wrote:
 Sure? maybe i am a bit blind. :(

 You are not - I've missed it... Thanks. I guess it was too early in the
 morning :)

 Luka

 V1:
 Eliminated:  DEPENDS:=+zlib +pciutils +dmidecode +libftdi
 +libusb-compat @(arm||armeb||i386||i686||x86_64)
 Added:  DEPENDS:=+zlib +pciutils +dmidecode +libftdi +libusb-compat
 V2:
 Eliminated: DEPENDS:=+zlib +pciutils +dmidecode +libftdi
 +libusb-compat @(arm||armeb||i386||i686||x86_64)
 Added: DEPENDS:=+zlib +pciutils +TARGET_x86:dmidecode +libftdi
 +libusb-compat

 Pepe

 2014-05-09 10:34 GMT+02:00, Luka Perkov l...@openwrt.org:
 On Fri, May 09, 2014 at 10:28:50AM +0200, José Vázquez wrote:
 2014-05-09 8:32 GMT+02:00, Luka Perkov l...@openwrt.org:
 Hi Alvaro,

 I don't see this change. Patch v2 is same as v1.

 Luka

 In v1 he eliminated cpu dependencies while in v2 dmidecode is only
 selected by TARGET_x86.
 I think that, in addition to x86 should be added x86_64 and any other
 target that has dmi.

 Yes, it says that in the description but the patches are the same.

 Luka

 ___
 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

Re: [OpenWrt-Devel] Making sense of OpenWRT / Linksys WRT1900AC collaboration claims

[José Vázquez]

2014-04-23 21:52 GMT+02:00, Rafał Miłecki zaj...@gmail.com:
 2014-04-23 13:41 GMT+02:00 José Vázquez ppvazquez...@gmail.com:
 I don't know if any of the OpenWRT developers or contributors have
 this router. If yes, my opinion is to add support for the board using
 the patches sent by Matthew Fatheree as base, reworking them and drop
 wireless support for now

 I think the lack of Signed-off-by is still a problem, isn't it?

Yep, forgot that important detail. :(
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Making sense of OpenWRT / Linksys WRT1900AC collaboration claims

[José Vázquez]

2014-04-23 11:40 GMT+02:00, Felix Fietkau n...@openwrt.org:
 On 2014-04-23 11:31, Felix Fietkau wrote:
 Quick update on this subject: Linksys has now posted a GPL source for
 the WRT1900AC, and it contains the wifi driver sources.
 It appears to me, that this driver was properly licensed under GPL, with
 proper license headers in all source files.

 This means that work on supporting this device can theoretically
 continue, although I expect it to take quite a bit of time. As I
 anticipated, the code quality of the driver source code is abysmal.
 This looks like rewrite (not cleanup) material, ugly enough to cause eye
 cancer or frighten small children ;)

 There are also still some pieces missing: Since this driver does not use
 standard Linux Wireless APIs, it can only properly function with custom
 hostapd/wpa_supplicant hacks. I don't see those in the release.
 Update 2: Those can be found in the OpenWrt SDK for this device on
 GitHub. Same comments regarding code quality apply here.

 - Felix

I don't know if any of the OpenWRT developers or contributors have
this router. If yes, my opinion is to add support for the board using
the patches sent by Matthew Fatheree as base, reworking them and drop
wireless support for now until they (Marvell or Belkin) develop a
cfg80211 or mac80211 compatible wireless driver. In other
circumstances maybe would be a good idea to spend time developing a
driver for the Avastar family but i think that if they say that the
WRT1900ac has support for OpenWRT, DD-WRT, DebWRT or any other it
should be their job.
Another idea could be take Matthew's patches (without the binary
blob), correct them, test if can be compiled without problems, include
them and add initial support marking @BROKEN.

Of course this is my own opinion and i don't have all the information,
so, if this is the case my apologies to OpenWRT developers, Matthew
Fatheree and Belkin International,Inc

José Vázquez
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Making sense of OpenWRT / Linksys WRT1900AC collaboration claims

[José Vázquez]

2014-04-23 13:41 GMT+02:00, José Vázquez ppvazquez...@gmail.com:
 2014-04-23 11:40 GMT+02:00, Felix Fietkau n...@openwrt.org:
 On 2014-04-23 11:31, Felix Fietkau wrote:
 Quick update on this subject: Linksys has now posted a GPL source for
 the WRT1900AC, and it contains the wifi driver sources.
 It appears to me, that this driver was properly licensed under GPL, with
 proper license headers in all source files.

 This means that work on supporting this device can theoretically
 continue, although I expect it to take quite a bit of time. As I
 anticipated, the code quality of the driver source code is abysmal.
 This looks like rewrite (not cleanup) material, ugly enough to cause eye
 cancer or frighten small children ;)

 There are also still some pieces missing: Since this driver does not use
 standard Linux Wireless APIs, it can only properly function with custom
 hostapd/wpa_supplicant hacks. I don't see those in the release.
 Update 2: Those can be found in the OpenWrt SDK for this device on
 GitHub. Same comments regarding code quality apply here.

 - Felix

 I don't know if any of the OpenWRT developers or contributors have
 this router. If yes, my opinion is to add support for the board using
 the patches sent by Matthew Fatheree as base, reworking them and drop
 wireless support for now until they (Marvell or Belkin) develop a
 cfg80211 or mac80211 compatible wireless driver. In other
 circumstances maybe would be a good idea to spend time developing a
 driver for the Avastar family but i think that if they say that the
 WRT1900ac has support for OpenWRT, DD-WRT, DebWRT or any other it
 should be their job.
Correction: if nobody have this router another option  could be take
Matthew's patches
 (without the binary blob), correct them, test if can be compiled without 
 problems, include
 them and add initial support marking @BROKEN.

 Of course this is my own opinion and i don't have all the information,
 so, if this is the case my apologies to OpenWRT developers, Matthew
 Fatheree and Belkin International,Inc

 José Vázquez

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

Re: [OpenWrt-Devel] Making sense of OpenWRT / Linksys WRT1900AC collaboration claims

[José Vázquez]

2014-04-23 14:27 GMT+02:00, Zoltan HERPAI wigy...@uid0.hu:
 I don't know if any of the OpenWRT developers or contributors have
 this router. If yes, my opinion is to add support for the board using
 the patches sent by Matthew Fatheree as base, reworking them and drop
 wireless support for now until they (Marvell or Belkin) develop a
 cfg80211 or mac80211 compatible wireless driver. In other
 circumstances maybe would be a good idea to spend time developing a
 driver for the Avastar family but i think that if they say that the
 WRT1900ac has support for OpenWRT, DD-WRT, DebWRT or any other it
 should be their job.
 Correction: if nobody have this router another option  could be take
 Matthew's patches
 (without the binary blob), correct them, test if can be compiled without
 problems, include
 them and add initial support marking @BROKEN.
 Of course this is my own opinion and i don't have all the information,
 so, if this is the case my apologies to OpenWRT developers, Matthew
 Fatheree and Belkin International,Inc

 Note that while having the wireless driver source released (or partially
 released), is a big win, I don't see any uboot source in the package.

 Regards,
 -w-

Yes, it is a big win, but as Felix noted before the driver needs to be
rewrote and it doesn't use the standard Linux Wireless API.
This means that work on supporting this device can theoretically
continue, although I expect it to take quite a bit of time. As I
anticipated, the code quality of the driver source code is abysmal.
This looks like rewrite (not cleanup) material, ugly enough to cause eye
cancer or frighten small children ;)

There are also still some pieces missing: Since this driver does not use
standard Linux Wireless APIs, it can only properly function with custom
hostapd/wpa_supplicant hacks. I don't see those in the release.

I think that is too much job and efforts for a single and not very
popular, as far i know, wireless family chips. I repeat that it is my
not totally informed opinion because i don't know a lot of details.

Off topic: for me are more interesting the ath9k and ath10k drivers.

José
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] bcm6368 + block-mount jffs2 problem.

[José Vázquez]

2014-04-07 22:19 GMT+02:00, Jonas Gorski j...@openwrt.org:
 On Mon, Apr 7, 2014 at 10:11 PM, José Vázquez ppvazquez...@gmail.com
 wrote:
 The initial tests point that there is no data corruption in jffs2. Good
 catch!
 There are still some strange messages but maybe are due to the high
 amount of debug info and the jffs2 filesystem works fine:

 [   18.584000] [ cut here ]
 (snip)
 Here is the complete bootlog: http://pastebin.com/hZecEbxj

 Likely some normal jffs2 issues we never see because the extra
 checking code is usally disabled.

 Great job!

 It's only a stop-gap solution until the real cause it found. Whatever
 the cause is, it can pop up any time somewhere else and cause other
 head aches, so we shouldn't stop debugging this until we know it won't
 creep up anymore.

 Jonas

jar229, moderator of seguridadwireless forum, didn't noticed problems
since the inclusion of hack around jffs2 corruption with SMP, so for
now the issue disappeared.
danitool and me, before the inclusion of your patch, made a lot of
changes and workarounds that in our tests seemed to work, but when he
tested them, sooner or later the problem appeared again.

To summarize: if jar229 don't tell that he has the problem again, it
is corrected for now.

Best regards:

Pepe

P.S.: i still didn't tested kernel 3.14 but surely it will work fine too.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] lantiq voip foo

[José Vázquez]

I have only two ARV4518pw but they are enough to make tests, and in a
spanish forum surely there will be a lot of people very pleased to
help you.
First of all i need to learn a bit of asterisk with AA in order to
help you better.

Thanks in advance:

Pepe

2014-04-10 9:23 GMT+02:00, John Crispin j...@phrozen.org:
 Hi,

 with the vdsl now working as well as the adsl i would also like to try
 to bring the voip/asterisk support up to scratch.

 i am a n00b at asterisk and have never used the can_lantiq driver.

 any volunteers for this ?

 any one successfully used chan_lantiq ?

 ideally we could make a sample config file that will allow users to
 simply setup the voip of the usual suspects such as sipgate, ekiga,
 bt, dt, kpn ...

 Having an easy way to set this up would make units such as the a803 or
 the 7519 much more attractive.


   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] So, how does the 'compat-wireless' package interact with the OpenWRT build scripts and the given Linux Kernel?

[José Vázquez]

It's not difficult. If you want to add an atheros option look into the
Makefile the better place for it. This link points to one of the ath
sections: 
https://dev.openwrt.org/browser/trunk/package/kernel/mac80211/Makefile#L494

You see Linux-3.10.34 Kconfig items because it is patched for the
kernels supported in trunk.
This patch will guide you: http://patchwork.openwrt.org/patch/1960/

Pepe

2014-04-08 0:44 GMT+02:00, John Clark jeclark2...@aim.com:
 I'm looking at the various Kconfig files in 'compat-wireless-2014-01-23.1'
 that is part of my current build setup.

 When I use the command

 make menuconfig

 and look at the various options for building the atheros drivers, I see what
 appears to be the 'standard' Linux-3.10.34 Kconfig items.

 However, when I look at the equivalent
 'compat-wireless-2014-01-23.1/drivers/net/wireless/ath' Kconfig file, there
 are different options, some of which I want to enable.

 Does one have to do this by hand, or is there some magic option to 'make
 menuconfig' to show the 'compat-wireless' Kconfig file.

 Thanks,
 John Clark.
 ___
 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] is anybody working on supporting Linksys WRT1900ac ?

[José Vázquez]

2014-04-08 17:02 GMT+02:00, Bjørn Mork bj...@mork.no:
 Felix Fietkau n...@openwrt.org writes:

 I've seen this happen to other open source related projects using
 Marvell hardware as well, so the big question is whether Belkin can put
 enough pressure on them to get the source code released.

 Even if that happens, the source code will most likely need a rewrite or
 an insane amount of cleanup, as is typical for proprietary wifi drivers
 in the embedded space.

 There are many signs that if released, the source code to this driver is
 going to be horrible: weird function names, big module size, use of
 custom vendor-specific hostapd and wpa_supplicant drivers. This is most
 likely going to take a long time to resolve.

 I know these comments are based on experience, but I still feel you are
 a bit too pessimistic here :-)
Felix is not pessimistic; he knows better than most the high amount of
job and problems that generate a wifi driver with such few information
and, in addition it seems to use a different API. Take in mind that
the Broadcom wireless proprietary driver generate some problems from
time to time.

 After all, we do have the mwl8k driver in mainline and Marvell has
 commited a lot to that, including the 8764 bits.  It's not too unlikely
 that they will add 8864 support as well, is it?  And wrt the size: Some
 of this is probably due to firmware being built into the module.  And
 some is debugging symbols.  The rest is of course bloat mostly caused by
 unnecessary reimplementation.


 Bjørn

In my opinion you are too confident about the similarities between
mwifiex[1], mwl8k[2] and the Avastar 88W8864 drivers.
How much wireless ICs aren't supported in linux and how much of them
have required a lot of job doing reverse engineering or clean room
development?
Being optimistic Marvell will release a binary file with some
additional code to interface with the OpenWRT wireless subsystem. We
will not see a free functional driver in months or ages.

Regards:

Pepe

[1]: http://wireless.kernel.org/en/users/Drivers/mwifiex
[2]: http://wireless.kernel.org/en/users/Drivers/mwl8k
 ___
 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] lantiq vdsl driver settings

[José Vázquez]

Make sure you have selected kmod-ltq-ptm-vr9 and kmod-ltq-atm-vr9
deselected in addition to a VR9 vdsl firmware.
The firm you need should be into the TD-W8970 source code.

Regards.

2014-04-08 19:51 GMT+02:00, obconseil obcons...@gmail.com:
 Hello,


 I would be interested by that too: I'm currently working on the same
 TD-W8970,
 using a annex-a ADSL2+ firmware.
 However, I lack VDSL2 annex-a firmware , as this standard has been
 recently allowed in France.

 I could confirm that , when using my current firmware on a VDSL2 POTS ,
 the synchronisation is established on ADSL2+, not VDSL2.

 Besides, I still have some problems linked to the Wifi chipset that hang
 after a while, and with a *very* long boot that seems
 to be related to the internal switch, which is reseted multiple time
 during bootup (GPIO-related ? I do not see any driver for this switch).

 Thanks for sharing your findings,



 Julien




 Le 08/04/2014 19:14, John Crispin a écrit :


 On 08/04/2014 19:05, Jonas Gorski wrote:
 I have no idea. This was just a guess on the part that all the
 other parameters are in this bitfield notion, so I assumed that
 this one works the same. Shouldn't the cpe-control sources tell you
 what they are good for?


 yes but that takes too long :)

 i just got an off-list mail expalining things abut vdsl tone sets that
 i never heard before and also a reason why it fails for me and what i
 need to do to fix it.

 i'll push an updated dsl_control once i finished reworking this

  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

Re: [OpenWrt-Devel] bcm6368 + block-mount jffs2 problem.

[José Vázquez]

If it worked for you surely surely will work for the other 6368.
We will send the feedback soon.

Thanks in advance:

Pepe

2014-04-07 0:09 GMT+02:00, Jonas Gorski j...@openwrt.org:
 On Sat, Feb 1, 2014 at 1:06 PM, Álvaro Fernández Rojas
 nolt...@gmail.com wrote:
 AFAIK anyone with a Neufbox 6 should be able to test if the problem
 happens on SMP + SPI flash.

 I don't have any SMP + SPI flash brcm63xx device that is currently
 supported by OpenWrt.
 When Florian releases the BCM3380 patches I'll be able to test this with
 my Netgear CG3100Dv3.

 I had some time to play around with 6368 and pflash, and committed a
 workaround with r40396 that at least worked for me.

 Please test if this also fixes the issue for you.


 Regards
 Jonas

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

Re: [OpenWrt-Devel] Any plans to support WD My Net N900 (Ubicom IP8K 600MHz, 8x GigE, 256MB)?

[José Vázquez]

Seems that these boards have u-boot as bootloader so you should can
upload your firms to RAM and boot them in it.

2014-04-06 1:30 GMT+02:00, Luis E. Garcia l...@bitamins.net:
 Constantine,
 The JP1 headers are present on the N900 just as they are on the N750.
 I'll put a copy of the boot output on the console next week.

 The original firmware for these devices seems to be linux based ( the GPL
 code from the manufacturer ).
 I've used the recovery procedure to install my custom version of the
 original firmware on my N900.
 The WD MyNet range are really developer friendly and very hard to brick.

 Regards,
 Luis E. Garcia


 On Sat, Apr 5, 2014 at 2:16 PM, Constantine A. Murenin
 muren...@gmail.comwrote:

 Hi Luis,

 I'm also interested in trying out the waters by porting OpenWrt over.
 I've noticed reports that WD My Net routers appear to be
 developer-friendly -- according to the reports like
 https://wikidevi.com/wiki/Western_Digital_My_Net_N750, the models sold
 to end-users still do have the serial header present (JP1 on N750);
 and also have the special recovery procedure from a failed firmware
 update (http://wiki.openwrt.org/toh/wd/n900#recovery.procedure and

 http://wdc.custhelp.com/app/answers/detail/a_id/9618/~/how-to-recover-a-my-net-router-from-a-failed-firmware-update
 ).

 Do you at all know if the recovery procedure could be used to test out
 custom firmwares without the possibility of bricking the device?

 Cheers,
 Constantine.

 On 3 April 2014 14:31, Luis E. Garcia l...@bitamins.net wrote:
  Constantine,
  I'm looking into porting OpenWRT to the WD MyNet N900.
  Since the IP8K has an mmu it should be able to compile without too much
  issues.
  I'm currently trying to get the toolchain from trunk to work.
 
  Regards,
  Luis E. Garcia
 
 
  On Thu, Apr 3, 2014 at 3:55 AM, José Vázquez ppvazquez...@gmail.com
 wrote:
 
  2014-04-03 6:58 GMT+02:00, Constantine A. Murenin
  muren...@gmail.com:
   Hello,
  
   It has come to my attention that the recently discontinued WD My Net
   line of dual-band routers is just about the best bang for the buck
   --
   they're currently selling N900 (w/ 8x GigE and 256MB of RAM) for
   49,99
   USD at Staples, or 39,99 USD if you order it in person from the
   store
   with the 20% in-store coupon, off from the original price of 149,99
   USD.  This firesale appears to come and go since late 2013, even
   before the whole line was discontinued in early 2014 (for example,
   Staples still appears to have some N750 left, but it's not on sale
   this week, unlike N900).
  
 http://wiki.openwrt.org/toh/wd/n900
  
  
 http://www.staples.com/WD-My-Net-N900-HD-Dual-Band-Router/product_937135
  
   However, N900 it's not supported by OpenWRT -- the whole Ubicom IP8K
   platform is not supported.
  
   Is there a reason for that?
  
   What would it take to add the support?
  
   WD My Net N900 looks like just about the best piece of hardware over
   at http://wiki.openwrt.org/toh/start list, this repeated firesale
   price of 39,99 USD is just insane and is easily 3x less than the
   competition -- might be a good motivator for adding support to
   OpenWRT.
  
   Cheers,
   Constantine.
   ___
   openwrt-devel mailing list
   openwrt-devel@lists.openwrt.org
   https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
  
  AFAIK ubicom32 was deprecated because it was hard to maintain, need a
  different toolchain, ip6k and ip5k had not mmu and some other things.
  IP8k seems to have mmu and some interesting features, but still has
  its own architecture.
  Take a look at this link to check the status:
 
 
 https://dev.openwrt.org/browser/branches/attitude_adjustment/target/linux/ubicom32
  The GCC version is 4.4.7.
 
  Regards:
 
  Pepe
  ___
  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] is anybody working on supporting Linksys WRT1900ac ?

[José Vázquez]

There is something that still don't understand: why is there so much
interest in the WRT1900ac? A Wandboard quad + i.e. TL-WDR7500 is a
more exciting, more powerful and more versatile combo.
It is a bit funny to take a look at the code which include a binary patch.
Direct Link: ftp://Temp90523934364:tag43...@ftp.belkin.com/Temp90523934364

In addition there are very interesting comments in the mailing list:
https://lists.openwrt.org/pipermail/openwrt-devel/2014-April/024589.html


In this moment i'm much more interested in test Jonas' jffs2 patch for
the BCM63XX target.

Regards:

Pepe

2014-04-07 14:49 GMT+02:00, Fernando Frediani fhfredi...@gmail.com:
 NDA = $$$ = Quiet

 I just don't understand what is the problem, if it's really true, to
 tell the most interested people (developers) that you are working on
 something directly related to the project, even without giving any
 further details due the NDA.


 On 06/04/2014 11:17, Hartmut Knaack wrote:
 Gerry Rozema schrieb:
 On 28/03/14 01:58 PM, Peter Lawler wrote:
 Hi Pete! We are working with one of the OpenWRT founders and his
 team. We'll be sharing more details later... Stay tuned! :)
 https://dev.openwrt.org/wiki/people

 Two listed there as founders, and I'm one of the two.

 Isn't me, so it must be Mike
 Mike, are you still alive and on the list?
 ___
 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

Re: [OpenWrt-Devel] is anybody working on supporting Linksys WRT1900ac ?

[José Vázquez]

Fernando, you are right: the WRT54G was the beginning of a lot of
great things, and now a lot of people contribute to OpenWRT, DD-WRT,
and some other projects that i can't remember in this moment thanks to
it.
A disagree a bit with ...Belkin/Linksys is truly interested to work
with OpenWRT developers means, in theory, an always welcome
contribution back to the project. but according to this changelog
(https://dev.openwrt.org/log/trunk/target/linux/mvebu?rev=40420) seems
that the initial and hard job in OpenWRT were made by Florian, Luka
(actual maintainer), Juhosg and others, in addition to the patches
that other developers sent to the kernel. I can be wrong but
Belkin/Linksys seems that are using existing code and adapting it,
which is the right way, for its board; a wonderful board, of course, a
black beast.

The patch 0030-mamba-mvebu-support-wifi-non-security.patch points that
the wifi driver uses a proprietary API instead cfg80211, like Broadcom
did with its proprietary wireless driver. :(

To summarize: despite de precompiled wireless driver, welcome Linksys WRT1900ac!

Best regards:

José

P.S.: i'm a bit sensitive with my surname.

2014-04-07 18:38 GMT+02:00, Fernando Frediani fhfredi...@gmail.com:
 That is very interesting.

 Does anyone know if the source code of the .ko module was finally
 provided by Belkin/Linksys ?

 Jose-Vasquez - Regarding your other email why there is so much interest
 on the WRT1900ac,, I think first because it was announced as a successor
 of the famous WRT54G, which  needless to say the importance of this in
 the start of the project. Also despite the fact other hardwares like
 TL-WDR7500 are very interesting indeed, this one has its merits on the
 upcoming ac era and if Belkin/Linksys is truly interested to work
 with OpenWRT developers means, in theory, an always welcome
 contribution back to the project.


 Best regards,

 Fernando



 On 07/04/2014 14:32, Toke Høiland-Jørgensen wrote:
 There was a patch posted from linksys last week:

 http://thread.gmane.org/gmane.comp.embedded.openwrt.devel/23500

 -Toke
 ___
 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] bcm6368 + block-mount jffs2 problem.

[José Vázquez]

] del_timer+0x20/0x7c
[ 5227.896000] [8005ac24] try_to_grab_pending+0x40/0x1c8
[ 5227.896000] [8005c288] __cancel_work_timer+0x34/0x13c
[ 5227.896000] [80135858] jffs2_sync_fs+0x20/0x54
[ 5227.896000] [800cd14c] iterate_supers+0xa4/0x124
[ 5227.896000] [800f4878] sys_sync+0x44/0x9c
[ 5227.896000] [800128e8] stack_done+0x20/0x44
[ 5227.896000]
[ 5227.896000] ---[ end trace b6fb3723b4c4aa9c ]---
root@OpenWrt:/# procd: - shutdown -
[ 5228.54] br-lan: port 1(eth0.1) entered disabled state

Here is the complete bootlog: http://pastebin.com/hZecEbxj

Great job!

Best regards:

Pepe

2014-04-07 9:35 GMT+02:00, José Vázquez ppvazquez...@gmail.com:
 If it worked for you surely will work for the other 6368.
 We will send the feedback soon.

 Thanks in advance:

 Pepe

 2014-04-07 0:09 GMT+02:00, Jonas Gorski j...@openwrt.org:
 On Sat, Feb 1, 2014 at 1:06 PM, Álvaro Fernández Rojas
 nolt...@gmail.com wrote:
 AFAIK anyone with a Neufbox 6 should be able to test if the problem
 happens on SMP + SPI flash.

 I don't have any SMP + SPI flash brcm63xx device that is currently
 supported by OpenWrt.
 When Florian releases the BCM3380 patches I'll be able to test this with
 my Netgear CG3100Dv3.

 I had some time to play around with 6368 and pflash, and committed a
 workaround with r40396 that at least worked for me.

 Please test if this also fixes the issue for you.


 Regards
 Jonas


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

Re: [OpenWrt-Devel] Any plans to support WD My Net N900 (Ubicom IP8K 600MHz, 8x GigE, 256MB)?

[José Vázquez]

2014-04-03 6:58 GMT+02:00, Constantine A. Murenin muren...@gmail.com:
 Hello,

 It has come to my attention that the recently discontinued WD My Net
 line of dual-band routers is just about the best bang for the buck --
 they're currently selling N900 (w/ 8x GigE and 256MB of RAM) for 49,99
 USD at Staples, or 39,99 USD if you order it in person from the store
 with the 20% in-store coupon, off from the original price of 149,99
 USD.  This firesale appears to come and go since late 2013, even
 before the whole line was discontinued in early 2014 (for example,
 Staples still appears to have some N750 left, but it's not on sale
 this week, unlike N900).

   http://wiki.openwrt.org/toh/wd/n900
   http://www.staples.com/WD-My-Net-N900-HD-Dual-Band-Router/product_937135

 However, N900 it's not supported by OpenWRT -- the whole Ubicom IP8K
 platform is not supported.

 Is there a reason for that?

 What would it take to add the support?

 WD My Net N900 looks like just about the best piece of hardware over
 at http://wiki.openwrt.org/toh/start list, this repeated firesale
 price of 39,99 USD is just insane and is easily 3x less than the
 competition -- might be a good motivator for adding support to
 OpenWRT.

 Cheers,
 Constantine.
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

AFAIK ubicom32 was deprecated because it was hard to maintain, need a
different toolchain, ip6k and ip5k had not mmu and some other things.
IP8k seems to have mmu and some interesting features, but still has
its own architecture.
Take a look at this link to check the status:
https://dev.openwrt.org/browser/branches/attitude_adjustment/target/linux/ubicom32
The GCC version is 4.4.7.

Regards:

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

[OpenWrt-Devel] Wireless eeprom fix for ARV4518PW, ARV7518PW and some others.

[José Vázquez Fernández]

Tki2000, in the openwrt subforum of seguridadwireless, published a
modified ath_eep.c file because, since the Lantiq target moved to kernel
3.10 some routers cannot read calibration data nor mac.
The code also applies a patch made by Noltari that disables regdomain
limitations, but still don't read the mac rightly.
Here is the code that can be used as a draft to make the wifi work in
those routers.

/*
 *  Copyright (C) 2011 Luca Olivetti l...@ventoso.org
 *  Copyright (C) 2011 John Crispin blo...@openwrt.org
 *  Copyright (C) 2011 Andrej Vlašić andrej.vlas...@gmail.com
 *  Copyright (C) 2013 Álvaro Fernández Rojas nolt...@gmail.com
 *  Copyright (C) 2013 Daniel Gimpelevich
dan...@gimpelevich.san-francisco.ca.us
 *
 *  This program is free software; you can redistribute it and/or modify
it
 *  under the terms of the GNU General Public License version 2 as
published
 *  by the Free Software Foundation.
 */

#include linux/init.h
#include linux/module.h
#include linux/platform_device.h
#include linux/etherdevice.h
#include linux/ath5k_platform.h
#include linux/ath9k_platform.h
#include linux/pci.h
#include linux/err.h
#include linux/mtd/mtd.h
#include pci-ath-fixup.h
#include lantiq_soc.h
#include linux/of_net.h

extern int (*ltq_pci_plat_dev_init)(struct pci_dev *dev);
struct ath5k_platform_data ath5k_pdata;
struct ath9k_platform_data ath9k_pdata = {
.led_pin = -1,
};
static u8 athxk_eeprom_mac[6];

static int ath9k_pci_plat_dev_init(struct pci_dev *dev)
{
dev-dev.platform_data = ath9k_pdata;
return 0;
}

int __init of_ath9k_eeprom_probe(struct platform_device *pdev)
{
struct device_node *np = pdev-dev.of_node, *mtd_np;
struct resource *eep_res, *mac_res;
void __iomem *eep, *mac;
int mac_offset;
u32 mac_inc = 0, pci_slot = 0;
int i;
u16 *eepdata, sum, el;
struct mtd_info *the_mtd;
size_t flash_readlen;
const __be32 *list;
const char *part;
phandle phandle;
//struct property *pp;
//struct device_node *dn;

if (!of_find_property(np,ath,arv-ath9k-fix,NULL))
{
list = of_get_property(np, ath,eep-flash, i);
if (!list || (i !=  (2 * sizeof(*list 
{
dev_err(pdev-dev, failed to find ath,eep-flash\n);
return -ENODEV;
}

phandle = be32_to_cpup(list++);
if (!phandle) 
{
dev_err(pdev-dev, failed to find phandle\n);
return -ENODEV;
}

mtd_np = of_find_node_by_phandle(phandle);
if (!mtd_np) 
{
dev_err(pdev-dev, failed to find mtd node\n);
return -ENODEV;
}

part = of_get_property(mtd_np, label, NULL);
if (!part)
part = mtd_np-name;

the_mtd = get_mtd_device_nm(part);
if (the_mtd == ERR_PTR(-ENODEV)) 
{
dev_err(pdev-dev, failed to find mtd device\n);
return -ENODEV;
}

i = mtd_read(the_mtd, be32_to_cpup(list),
ATH9K_PLAT_EEP_MAX_WORDS  1, flash_readlen,
(void *) ath9k_pdata.eeprom_data);
put_mtd_device(the_mtd);
if ((sizeof(ath9k_pdata.eeprom_data) != flash_readlen) || i) 
{
dev_err(pdev-dev, failed to load eeprom from mtd\n);
return -ENODEV;
}

if (of_find_property(np, ath,eep-swap, NULL))
for (i = 0; i  ATH9K_PLAT_EEP_MAX_WORDS; i++)
ath9k_pdata.eeprom_data[i] = 
swab16(ath9k_pdata.eeprom_data[i]);

if (of_find_property(np, ath,eep-endian, NULL)) 
{
ath9k_pdata.endian_check = true;
dev_info(pdev-dev, endian check enabled.\n);
}

if (!of_property_read_u32(np, ath,mac-offset, mac_offset)) 
{
memcpy_fromio(athxk_eeprom_mac, (void*) 
ath9k_pdata.eeprom_data +
mac_offset, 6);
} 
else 
{
random_ether_addr(athxk_eeprom_mac);
if (of_get_mac_address_mtd(np, athxk_eeprom_mac))
dev_warn(pdev-dev, using random mac\n);
}

if (!of_property_read_u32(np, ath,mac-increment, mac_inc))
athxk_eeprom_mac[5] += mac_inc;

ath9k_pdata.macaddr = athxk_eeprom_mac;
ltq_pci_plat_dev_init = ath9k_pci_plat_dev_init;

if (!of_property_read_u32(np, ath,pci-slot, 

Re: [OpenWrt-Devel] compiler optimization flags on the brcm2708platform?

[José Vázquez Fernández]

The GCC arm options are explained here: 
http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/ARM-Options.html#ARM-Options
The BCM2708 has the following features: swp half thumb fastmult vfp edsp java 
tls
To add option to the toolchain go to make menuconfig-Advanced options 
-- Target options
Once there write the flags you want.

Regards:

Pepe

- Original Message - 
From: Derek  Vicky thewerth...@gmail.com
To: openwrt-devel openwrt-devel@lists.openwrt.org
Sent: Tuesday, March 25, 2014 7:33 PM
Subject: Re: [OpenWrt-Devel] compiler optimization flags on the 
brcm2708platform?


VIPS is obviously the wrong package to be talking about with respect to
compiler optimization flags...:-)

I read this article on compiler optimization flags
https://forum.openwrt.org/viewtopic.php?id=35323 and don't see the same
options available on the current Makefiles.
/trunk/target/linux/brcm2708/Makefile

Where is the place to set the compiler optimization flags?
Cheers

On 03/25/2014 08:27 AM, Derek Werthmuller wrote:
 In 2012 a patch was added for the brcm2708 build platform to use
 hardware floating point.
 Looks like the patch was committed too.
 https://lists.openwrt.org/pipermail/openwrt-devel/2012-July/016028.html
 -mfpu=vfp-   enables use of hardware floating point
 instructions. (in patch already)
 -mfloat-abi=hard   -   makes calling hardware floating point more efficient.

 Can this patch be added back in? I would like to be able to take advantage of 
 the floating point 
 hardware. I wonder if the patch was not included in the 12.09 tree?

 Quick search didn't reveal any reasons why it might have been removed.
 Thanks
   Derek
___
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] [lantiq] V2: add support for Astoria ARV7519RW.

[José Vázquez Fernández]

Add support for Astoria ARV7519RW.

These patches add support for the Astoria ARV7519RW aka Livebox 2.1
The PCI and PCIe interfaces have been disabled. Also, because there are
two revisions of this board with different GPHY firmwares, two targets
were defined.
V2: rewrote partitions to work with an u-boot specifically made for
these boards.

Signed off by: Esteban Benito esteban...@gmail.com
Signed off by: Carles Gadea carles...@gmail.com
Tested by: José Vázquez Fernández ppvazquez...@gmail.com

diff --git a/target/linux/lantiq/base-files/etc/uci-defaults/02_network
b/target/linux/lantiq/base-files/etc/uci-defaults/02_network
index 6e17d4d..a1f7b6a 100644
--- a/target/linux/lantiq/base-files/etc/uci-defaults/02_network
+++ b/target/linux/lantiq/base-files/etc/uci-defaults/02_network
@@ -114,6 +114,11 @@ TDW8970)
lan_mac=$(mtd_get_mac_binary boardconfig 61696)
wan_mac=$(macaddr_add $lan_mac 1)
;;
+
+ARV7519*)
+   lan_mac=$(mtd_get_mac_binary boardconfig 22)
+   wan_mac=$(macaddr_add $lan_mac 1)
+   ;;
 esac
 
 [ -z $(ls /lib/modules/`uname -r`/ltq_atm*) ] || set_atm_wan $vpi
$vci $encaps $payload
diff --git a/target/linux/lantiq/dts/ARV7519RW.dtsi
b/target/linux/lantiq/dts/ARV7519RW.dtsi
new file mode 100644
index 000..7790470
--- /dev/null
+++ b/target/linux/lantiq/dts/ARV7519RW.dtsi
@@ -0,0 +1,186 @@
+/include/ vr9.dtsi
+
+/ {
+
+   model = ARV7519 - Astoria Networks ARV7519RW22-A-LT;
+   
+   chosen {
+   bootargs = console=ttyLTQ0,115200 init=/etc/preinit;
+   };
+   
+   memory@0 {
+   reg = 0x0 0x800;
+   };
+   
+   fpi@1000 {
+   
+   gpio: pinmux@E100B10 {
+   pinctrl-names = default;
+   pinctrl-0 = state_default;
+   
+   state_default: pinmux {
+   mdio {
+   lantiq,groups = mdio;
+   lantiq,function = mdio;
+   };
+   gphy-leds {
+   lantiq,groups = gphy0 led1, gphy1 
led1;
+   lantiq,function = gphy;
+   lantiq,pull = 2;
+   lantiq,open-drain = 0;
+   lantiq,output = 1;
+   };
+   phy-rst {
+   lantiq,pins = io42;
+   lantiq,pull = 0;
+   lantiq,open-drain = 0;
+   lantiq,output = 1;
+   };
+   pcie-rst {
+   lantiq,pins = io21;
+   lantiq,pull = 0;
+   lantiq,output = 1;
+   };
+   };
+   };
+
+   eth@E108000 {
+   #address-cells = 1;
+   #size-cells = 0;
+   compatible = lantiq,xrx200-net;
+   reg =  0xE108000 0x3000 /* switch */
+   0xE10B100 0x70 /* mdio */
+   0xE10B1D8 0x30 /* mii */
+   0xE10B308 0x30 /* pmac */
+   ;
+   interrupt-parent = icu0;
+   interrupts = 73 72;
+
+   lan: interface@0 {
+   compatible = lantiq,xrx200-pdi;
+   #address-cells = 1;
+   #size-cells = 0;
+   reg = 0;
+   mac-address = [ 00 11 22 33 44 55 ];
+
+   ethernet@2 {
+   compatible = lantiq,xrx200-pdi-port;
+   reg = 2;
+   phy-mode = gmii;
+   phy-handle = phy11;
+   };
+   ethernet@3 {
+   compatible = lantiq,xrx200-pdi-port;
+   reg = 4;
+   phy-mode = gmii;
+   phy-handle = phy13;
+   };
+   };
+   
+   wan: interface@1 {
+   compatible = lantiq,xrx200-pdi;
+   #address-cells = 1;
+   #size-cells = 0;
+   reg = 1;
+   mac-address = [ 00 11 22 33 44 56

Re: [OpenWrt-Devel] [PATCH] [lantiq] Add support for Astoria ARV7519RW.

[José Vázquez]

2014-03-10 12:26 GMT+01:00, José Vázquez Fernández ppvazquez...@gmail.com:
 Add support for Astoria ARV7519RW.

 These patches add support for the Astoria ARV7519RW aka Livebox 2.1
 The PCI and PCIe interfaces have been disabled. Also, because there are
 two revisions of this board with differen GPHY firmwares, two targets
 were defined.

 Signed off by: Esteban Benito esteban...@gmail.com
 Signed off by: Carles Gadea carles...@gmail.com
 Tested by: José Vázquez Fernández ppvazquez...@gmail.com

Esteban Benito wrote an u-boot for this board due to few random
problems found when the stock BRN-boot + u-boot were used.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] [lantiq] Add support for Astoria ARV7519RW.

[José Vázquez]

2014-03-12 9:40 GMT+01:00, José Vázquez ppvazquez...@gmail.com:
 2014-03-10 12:26 GMT+01:00, José Vázquez Fernández
 ppvazquez...@gmail.com:
 Add support for Astoria ARV7519RW.

 These patches add support for the Astoria ARV7519RW aka Livebox 2.1
 The PCI and PCIe interfaces have been disabled. Also, because there are
 two revisions of this board with differen GPHY firmwares, two targets
 were defined.

 Signed off by: Esteban Benito esteban...@gmail.com
 Signed off by: Carles Gadea carles...@gmail.com
 Tested by: José Vázquez Fernández ppvazquez...@gmail.com

 Esteban Benito wrote an u-boot for this board due to few random
 problems found when the stock BRN-boot + u-boot were used.
This patch has been marked as superseded because of the aforementioned
bootloader change.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] [lantiq] V2: add support for Astoria ARV7519RW.

[José Vázquez]

2014-03-12 9:31 GMT+01:00, John Crispin j...@phrozen.org:
 hi,

 i am starting to wonder if we should to runtime detection of the fw blob
 to use ... i.e. indicate in the dts file if we want 11g or 22fe firmware
 and let the code figure out the version

 John


 On 12/03/2014 09:29, José Vázquez Fernández wrote:
 Add support for Astoria ARV7519RW.

 These patches add support for the Astoria ARV7519RW aka Livebox 2.1
 The PCI and PCIe interfaces have been disabled. Also, because there are
 two revisions of this board with different GPHY firmwares, two targets
 were defined.
 V2: rewrote partitions to work with an u-boot specifically made for
 these boards.

You are right: less board definitions, less work and space need for
buildbot and less complications for the people.

Regards:

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

[OpenWrt-Devel] [PATCH] [lantiq] Add support for Astoria ARV7519RW.

[José Vázquez Fernández]

Add support for Astoria ARV7519RW.

These patches add support for the Astoria ARV7519RW aka Livebox 2.1
The PCI and PCIe interfaces have been disabled. Also, because there are
two revisions of this board with differen GPHY firmwares, two targets
were defined.

Signed off by: Esteban Benito esteban...@gmail.com
Signed off by: Carles Gadea carles...@gmail.com
Tested by: José Vázquez Fernández ppvazquez...@gmail.com

diff --git a/target/linux/lantiq/base-files/etc/uci-defaults/02_network
b/target/linux/lantiq/base-files/etc/uci-defaults/02_network
index 6e17d4d..a1f7b6a 100644
--- a/target/linux/lantiq/base-files/etc/uci-defaults/02_network
+++ b/target/linux/lantiq/base-files/etc/uci-defaults/02_network
@@ -114,6 +114,11 @@ TDW8970)
lan_mac=$(mtd_get_mac_binary boardconfig 61696)
wan_mac=$(macaddr_add $lan_mac 1)
;;
+
+ARV7519*)
+   lan_mac=$(mtd_get_mac_binary boardconfig 22)
+   wan_mac=$(macaddr_add $lan_mac 1)
+   ;;
 esac
 
 [ -z $(ls /lib/modules/`uname -r`/ltq_atm*) ] || set_atm_wan $vpi
$vci $encaps $payload
diff --git a/target/linux/lantiq/dts/ARV7519RW.dtsi
b/target/linux/lantiq/dts/ARV7519RW.dtsi
new file mode 100644
index 000..7790470
--- /dev/null
+++ b/target/linux/lantiq/dts/ARV7519RW.dtsi
@@ -0,0 +1,186 @@
+/include/ vr9.dtsi
+
+/ {
+
+   model = ARV7519 - Astoria Networks ARV7519RW22-A-LT;
+   
+   chosen {
+   bootargs = console=ttyLTQ0,115200 init=/etc/preinit;
+   };
+   
+   memory@0 {
+   reg = 0x0 0x800;
+   };
+   
+   fpi@1000 {
+   
+   gpio: pinmux@E100B10 {
+   pinctrl-names = default;
+   pinctrl-0 = state_default;
+   
+   state_default: pinmux {
+   mdio {
+   lantiq,groups = mdio;
+   lantiq,function = mdio;
+   };
+   gphy-leds {
+   lantiq,groups = gphy0 led1, gphy1 
led1;
+   lantiq,function = gphy;
+   lantiq,pull = 2;
+   lantiq,open-drain = 0;
+   lantiq,output = 1;
+   };
+   phy-rst {
+   lantiq,pins = io42;
+   lantiq,pull = 0;
+   lantiq,open-drain = 0;
+   lantiq,output = 1;
+   };
+   pcie-rst {
+   lantiq,pins = io21;
+   lantiq,pull = 0;
+   lantiq,output = 1;
+   };
+   };
+   };
+
+   eth@E108000 {
+   #address-cells = 1;
+   #size-cells = 0;
+   compatible = lantiq,xrx200-net;
+   reg =  0xE108000 0x3000 /* switch */
+   0xE10B100 0x70 /* mdio */
+   0xE10B1D8 0x30 /* mii */
+   0xE10B308 0x30 /* pmac */
+   ;
+   interrupt-parent = icu0;
+   interrupts = 73 72;
+
+   lan: interface@0 {
+   compatible = lantiq,xrx200-pdi;
+   #address-cells = 1;
+   #size-cells = 0;
+   reg = 0;
+   mac-address = [ 00 11 22 33 44 55 ];
+
+   ethernet@2 {
+   compatible = lantiq,xrx200-pdi-port;
+   reg = 2;
+   phy-mode = gmii;
+   phy-handle = phy11;
+   };
+   ethernet@3 {
+   compatible = lantiq,xrx200-pdi-port;
+   reg = 4;
+   phy-mode = gmii;
+   phy-handle = phy13;
+   };
+   };
+   
+   wan: interface@1 {
+   compatible = lantiq,xrx200-pdi;
+   #address-cells = 1;
+   #size-cells = 0;
+   reg = 1;
+   mac-address = [ 00 11 22 33 44 56 ];
+   lantiq,wan;
+   ethernet@4

Re: [OpenWrt-Devel] [RFC] Changing default Fragmentation Threshold and RTS/CTS Threshold

[José Vázquez]

 Router is TP_LINK TL_WR1043ND running ATTITUDE ADJUSTMENT (12.09, r36088)
 Laptop has Intel 4965agn card

I have had little problems with Intel 4965agn and a TP-Link
TL-MR3220v2, and because i don't need N wireless, disabled it and all
works fine. Also tested with an Atheros AR9385 in the laptop and it
worked perfectly.
Seems that the problem is with Intel card.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] bcm6368 + block-mount jffs2 problem.

[José Vázquez]

 I'm pretty sure that the jffs2 file name corruption problem doesn't
 happen BCM63xx SoCs with spi flash and smp enabled, so, if this is
 correct, seems to be a race condition between the flash type, jffs2
 and some Broadcom SoCs, as Jonas pointed some time ago.
Can somebody confirm is the problem disappears running openwrt in a
smp capable BCM63xx with SPI flash?

 These warnings are easily reproducible enabling the mentioned options
 in the kernel.

 Initially my intention was to send this information to linux-mips but,
 because these warnings can be repeated easily i think that this should
 be discussed by more skilled and experienced people.

 Some other options inside Kernel hacking couldn't be tested because
 with them enabled the CFE of the VR-3025un was unable to uncompress
 the firmware.

 Regards:

 José


Forgot to mention that, even though BCM6358 and BCM6368 send the
mentioned warnings, file name corruption only happens in the BCM6368
when enabling SMP.

Besides, danitool, adding isolcpus=0 and activating bit 5 in register
$22, 2 made the problem much less serious, but it still remains, and
in addition, he achieved a significant increase in network throughput
with a Netgear DGND3700 v1. With that configuration almost all the
hardware irqs are driven by cpu0.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] bcm6368 + block-mount jffs2 problem.

[José Vázquez]

2014-01-11, José Vázquez ppvazquez...@gmail.com:
 2014/1/3, danitool dgcb...@gmail.com:
 I'm also having these problems. The bug is very easy to reproduce. Just
 using the jffs2 image instead of squashfs, the problems are shown with
 the
 first boot, and you can see lot of funny names just listing /etc/init.d

 root@(none):/# ls -l /etc/init.d/
 -rwxr-xr-x1 root root  1993 Jan  2  2014 boot
 -rwxr-xr-x1 root root   368 Dec 20  2013 ciciixixmeme
 -rwxr-xr-x1 root root   729 Dec 20  2013 cron
 -rwxr-xr-x1 root root  3920 Jan  2  2014 dropbear
 -rwxr-xr-x1 root root  4173 Jan  2  2014 eleld?d
 -rwxr-xr-x1 root root   262 Jan  2  2014 fire
 -rwxr-xr-x1 root root  2015 Dec 20  2013 led
 -rwxr-xr-x1 root root   926 Dec 20  2013 lnlnet
 -rwxr-xr-x1 root root  1694 Jan  2  2014 log
 -rwxr-xr-x1 root root   835 Dec 20  2013
 lucihchcmimigrate
 -rwxr-xr-x1 root root   308 Dec 20  2013 nene
 -rwxr-xr-x1 root root   125 Dec 20  2013 scsctl
 -rwxr-xr-x1 root root 13640 Jan  2  2014 smsmq?q
 -rwxr-xr-x1 root root   718 Dec 20  2013 snsnd?d
 -rwxr-xr-x1 root root   945 Jan  2  2014 twtwk?k
 -rwxr-xr-x1 root root  3324 Jan  2  2014 uhttpd
 -rwxr-xr-x1 root root   106 Jan  2  2014 umount
 -rwxr-xr-x1 root root   522 Dec 20  2013 ununndnd

 It's like a baby learning to talk.

 Since this is happening when using a jffs2 image, overlayfs isn't used,
 isn't it?, then the problem shouldn't be related to the overlayfs driver.


Checking Debug object operations (DEBUG_OBJECTS) and its related
options, and Lock debugging: prove locking correctness
(PROVE_LOCKING) the kernel shows this warning in a board based in
BCM6368 (parallel flash), with and without SMP enabled:

[5.854166] hub 2-0:1.0: USB hub found
[5.854166] hub 2-0:1.0: 1 port detected
[5.874999] usbcore: registered new interface driver usb-storage
kmod: ran 1 iterations
[7.041666] jffs2: notice: (251) jffs2_build_xattr_subsystem:
complete building xattr subsystem, 1 of xdatum (0 unchecked,.
[7.062499] [ cut here ]
[7.062499] WARNING: at lib/debugobjects.c:260 debug_print_object+0xb8/0xe4()
[7.062499] ODEBUG: assert_init not available (active state 0)
object type: timer_list hint: stub_timer+0x0/0x10
[7.062499] Modules linked in: usb_storage ohci_hcd ehci_platform
ehci_hcd sd_mod scsi_mod ext4 crc16 jbd2 mbcache usbcoreh
[7.062499] CPU: 0 PID: 251 Comm: block Not tainted 3.10.28 #3
[7.062499] Stack :   8040b842 0032 
83a24f10 803248a0 8039a1e3
  00fb  8040afe8 83a24f10 8381fa80 0045d65c
7f8b5630 8002dbd4
  803a3288 8002afc4   80327888 830ebc8c
830ebc8c 803248a0
       
 
       
 830ebc20
  ...
[7.062499] Call Trace:
[7.062499] [80020e6c] show_stack+0x48/0x70
[7.062499] [8002b0b8] warn_slowpath_common+0x78/0xa8
[7.062499] [8002b114] warn_slowpath_fmt+0x2c/0x38
[7.062499] [8019b0b8] debug_print_object+0xb8/0xe4
[7.062499] [8019bfd4] debug_object_assert_init+0xd0/0x13c
[7.062499] [8003ae04] del_timer+0x20/0x7c
[7.062499] [80047ed4] try_to_grab_pending+0x40/0x1c8
[7.062499] [800495c8] __cancel_work_timer+0x34/0x13c
[7.062499] [801521e8] jffs2_sync_fs+0x20/0x54
[7.062499] [80108550] sync_filesystem+0x60/0xbc
[7.062499] [800dc158] generic_shutdown_super+0x34/0xdc
[7.062499] [801e0468] kill_mtd_super+0x14/0x30
[7.062499] [80152018] jffs2_kill_sb+0x34/0x4c
[7.062499] [800dbf8c] deactivate_locked_super+0x48/0x84
[7.062499] [800fab28] SyS_umount+0x338/0x3ac
[7.062499] [800128e8] stack_done+0x20/0x44
[7.062499]
[7.062499] ---[ end trace 75b840b26e82af40 ]---
[7.229166] INFO: trying to register non-static key.
[7.229166] the code is fine but needs lockdep annotation.
[7.229166] turning off the locking correctness validator.
[7.229166] CPU: 0 PID: 251 Comm: block Tainted: GW3.10.28 #3
[7.229166] Stack :   8040b842 003d 
83a24f10 803248a0 8039a1e3
  00fb  8040afe8 83a24f10 83bb32a0 
 8002dbd4
  0002 8002af50   80327888 830ebc84
830ebc84 803248a0
       
 
       
 830ebc18
  ...
[7.229166] Call Trace:
[7.229166] [80020e6c] show_stack+0x48/0x70
[7.229166] [80070ab4] __lock_acquire.isra.18+0x1ec/0xcb8
[7.229166] [80071dd4] lock_acquire+0xe0/0x160
[7.229166] [800492dc

Re: [OpenWrt-Devel] [RFC] Broadcom code found.

[José Vázquez]

2014-01-11, José Vázquez Fernández ppvazquez...@gmail.com:
 While Daniel González and me were fighting with jffs2 tested some code
 extracted from Netgear. Here are what we found.
 We only tested brcm_wait, broadcom checksum code and the modification in
 tlbex.c and nothing strange happened when we flashed it.
 Hope this could help for the Broadcom SoCs and maybe others.


 diff -urN b/include/asm-mips/checksum.h a/include/asm-mips/checksum.h
 --- b/include/asm-mips/checksum.h 2007-06-12 16:13:11.0 +0200
 +++ a/include/asm-mips/checksum.h 2010-05-31 03:43:32.0 +0200
 @@ -98,6 +98,64 @@
   *   By Jorge Cwik jo...@laser.satlink.net, adapted for linux by
   *   Arnt Gulbrandsen.
   */
 +
 +#if defined(CONFIG_MIPS_BRCM)
 +
 +/* Brcm version can handle unaligned data. Merged from brcm 2.6.8
 kernel.*/
 +static inline __sum16 ip_fast_csum(const void *iph, unsigned int ihl)
 +{
 + if (((__u32)iph0x3) == 0) {
 + unsigned int *word = (unsigned int *) iph;
 + unsigned int *stop = word + ihl;
 + unsigned int csum;
 + int carry;
 +
 + csum = word[0];
 + csum += word[1];
 + carry = (csum  word[1]);
 + csum += carry;
 +
 + csum += word[2];
 + carry = (csum  word[2]);
 + csum += carry;
 +
 + csum += word[3];
 + carry = (csum  word[3]);
 + csum += carry;
 +
 + word += 4;
 + do {
 + csum += *word;
 + carry = (csum  *word);
 + csum += carry;
 + word++;
 + } while (word != stop);
 +
 + return csum_fold(csum);
 + } else {
 + __u16 * buff = (__u16 *) iph;
 + __u32 sum=0;
 + __u16 i;
 +
 + // make 16 bit words out of every two adjacent 8 bit words in
 the packet
 + // and add them up
 + for (i=0;iihl*2;i++){
 + sum = sum + (__u32) buff[i];
 + }
 +
 + // take only 16 bits out of the 32 bit sum and add up the
 carries
 + while (sum16)
 +   sum = (sum  0x)+(sum  16);
 +
 + // one's complement the result
 + sum = ~sum;
 +
 + return ((__sum16) sum);
 + }
 +}
 +
 +#else
 +
  static inline __sum16 ip_fast_csum(const void *iph, unsigned int ihl)
  {
   const unsigned int *word = iph;

I've tested the above code and the network throughput improved between
0'5 to 1% while running rsync with cifs and a 500 GB usb hdd with a
BCM63281 based board.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] bcm6368 + block-mount jffs2 problem.

[José Vázquez]

2014/1/3, danitool dgcb...@gmail.com:
 I'm also having these problems. The bug is very easy to reproduce. Just
 using the jffs2 image instead of squashfs, the problems are shown with the
 first boot, and you can see lot of funny names just listing /etc/init.d

 root@(none):/# ls -l /etc/init.d/
 -rwxr-xr-x1 root root  1993 Jan  2  2014 boot
 -rwxr-xr-x1 root root   368 Dec 20  2013 ciciixixmeme
 -rwxr-xr-x1 root root   729 Dec 20  2013 cron
 -rwxr-xr-x1 root root  3920 Jan  2  2014 dropbear
 -rwxr-xr-x1 root root  4173 Jan  2  2014 eleld?d
 -rwxr-xr-x1 root root   262 Jan  2  2014 fire
 -rwxr-xr-x1 root root  2015 Dec 20  2013 led
 -rwxr-xr-x1 root root   926 Dec 20  2013 lnlnet
 -rwxr-xr-x1 root root  1694 Jan  2  2014 log
 -rwxr-xr-x1 root root   835 Dec 20  2013 lucihchcmimigrate
 -rwxr-xr-x1 root root   308 Dec 20  2013 nene
 -rwxr-xr-x1 root root   125 Dec 20  2013 scsctl
 -rwxr-xr-x1 root root 13640 Jan  2  2014 smsmq?q
 -rwxr-xr-x1 root root   718 Dec 20  2013 snsnd?d
 -rwxr-xr-x1 root root   945 Jan  2  2014 twtwk?k
 -rwxr-xr-x1 root root  3324 Jan  2  2014 uhttpd
 -rwxr-xr-x1 root root   106 Jan  2  2014 umount
 -rwxr-xr-x1 root root   522 Dec 20  2013 ununndnd

 It's like a baby learning to talk.

 Since this is happening when using a jffs2 image, overlayfs isn't used,
 isn't it?, then the problem shouldn't be related to the overlayfs driver.

 I noticed another thing, probably not related to this, when I configure the
 main thread to be the second core In CFE, openwrt gets stalled booting the
 second core, I suppose the code lacks mechanisms to detect which core is up
 and boot the other.
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Thanks to the info collected by danitool and others
(http://wiki.openwrt.org/doc/hardware/soc/soc.broadcom.bcm63xx/smp)
and with the help of some code found in the Inventel Livebox source
code could get some info about the cpu registers. This is the code
with some additions:

static void bmips_cpus_done(void)
{
int config;
int introuting;
int ctrl;

config = read_c0_brcm_config_0();

if(!(config  BRCM_CONFIG0_CMT)) {
printk(SMP not supported on this processor\n);
return;
} else
printk(SMP supported on this processor\n);

if(config  BRCM_CONFIG0_SIC)
printk(Multicore CPU with split I-cache\n);
else
printk(Multicore CPU with shared I-cache\n);

if(config  BRCM_CONFIG0_OWB)
printk(Ordered Write Buffer enabled\n);
else
printk(Ordered Write Buffer disabled\n);

if(config  BRCM_CONFIG0_BPD)
printk(Branch prediction enabled\n);
else
printk(Branch prediction disabled\n);

if(config  BRCM_CONFIG0_RAC)
printk(RAC present\n);
else
printk(RAC absent\n);

if(config  BRCM_CONFIG0_NBK)
printk(NBK (non blocking Data Cache) enabled\n);
else
printk(NBK (non blocking Data Cache) disabled\n);

introuting = read_c0_brcm_cmt_intr();
printk(Interrupt routing:\n);
if(introuting  CMT_INT_XIR_IP4)
printk( IP4: set A to T1, set B to T0\n);
else
printk( IP4: set A to T0, set B to T1\n);
if(introuting  CMT_INT_XIR_IP3)
printk( IP3: set A to T1, set B to T0\n);
else
printk( IP3: set A to T0, set B to T1\n);
if(introuting  CMT_INT_XIR_IP2)
printk( IP2: set A to T1, set B to T0\n);
else
printk( IP2: set A to T0, set B to T1\n);
if(introuting  CMT_INT_XIR_IP1)
printk( IP1: set A to T1, set B to T0\n);
else
printk( IP1: set A to T0, set B to T1\n);
if(introuting  CMT_INT_XIR_IP0)
printk( IP0: set A to T1, set B to T0\n);
else
printk( IP0: set A to T0, set B to T1\n);
if(introuting  CMT_INT_SIR_IP1)
printk( SOFT1: set A to T1, set B to T0\n);
else
printk( SOFT1: set A to T0, set B to T1\n);
if(introuting  CMT_INT_SIR_IP0)
printk( SOFT0: set A to T1, set B to T0\n);
else
printk( SOFT0: set A to T0, set B to T1\n);

if((introuting  CMT_INT_NMI_MASK) == 1)
printk( NMI routed to thread 0\n);
else
printk( NMI routed to thread 1\n);

ctrl = 

[OpenWrt-Devel] [RFC] Broadcom code found.

[José Vázquez Fernández]

While Daniel González and me were fighting with jffs2 tested some code
extracted from Netgear. Here are what we found.
We only tested brcm_wait, broadcom checksum code and the modification in
tlbex.c and nothing strange happened when we flashed it.
Hope this could help for the Broadcom SoCs and maybe others.


diff -urN b/include/asm-mips/checksum.h a/include/asm-mips/checksum.h
--- b/include/asm-mips/checksum.h   2007-06-12 16:13:11.0 +0200
+++ a/include/asm-mips/checksum.h   2010-05-31 03:43:32.0 +0200
@@ -98,6 +98,64 @@
  * By Jorge Cwik jo...@laser.satlink.net, adapted for linux by
  * Arnt Gulbrandsen.
  */
+
+#if defined(CONFIG_MIPS_BRCM)
+
+/* Brcm version can handle unaligned data. Merged from brcm 2.6.8
kernel.*/
+static inline __sum16 ip_fast_csum(const void *iph, unsigned int ihl)
+{
+   if (((__u32)iph0x3) == 0) {
+   unsigned int *word = (unsigned int *) iph;
+   unsigned int *stop = word + ihl;
+   unsigned int csum;
+   int carry;
+
+   csum = word[0];
+   csum += word[1];
+   carry = (csum  word[1]);
+   csum += carry;
+
+   csum += word[2];
+   carry = (csum  word[2]);
+   csum += carry;
+
+   csum += word[3];
+   carry = (csum  word[3]);
+   csum += carry;
+
+   word += 4;
+   do {
+   csum += *word;
+   carry = (csum  *word);
+   csum += carry;
+   word++;
+   } while (word != stop);
+
+   return csum_fold(csum);
+   } else {
+   __u16 * buff = (__u16 *) iph;
+   __u32 sum=0;
+   __u16 i;
+
+   // make 16 bit words out of every two adjacent 8 bit words in
the packet
+   // and add them up
+   for (i=0;iihl*2;i++){
+   sum = sum + (__u32) buff[i];
+   }
+
+   // take only 16 bits out of the 32 bit sum and add up the
carries
+   while (sum16)
+ sum = (sum  0x)+(sum  16);
+
+   // one's complement the result
+   sum = ~sum;
+
+   return ((__sum16) sum);
+   }
+}
+
+#else
+
 static inline __sum16 ip_fast_csum(const void *iph, unsigned int ihl)
 {
const unsigned int *word = iph;
@@ -129,6 +187,8 @@
return csum_fold(csum);
 }
 
+#endif
+
 static inline __wsum csum_tcpudp_nofold(__be32 saddr,
__be32 daddr, unsigned short len, unsigned short proto,
__wsum sum)

--

diff -urN b/drivers/mtd/mtd_blkdevs.c a/drivers/mtd/mtd_blkdevs.c
--- b/drivers/mtd/mtd_blkdevs.c 2007-06-12 16:13:11.0 +0200
+++ a/drivers/mtd/mtd_blkdevs.c 2010-05-31 03:52:56.0 +0200
@@ -21,6 +21,9 @@
 #include linux/init.h
 #include linux/mutex.h
 #include asm/uaccess.h
+#if defined(CONFIG_MIPS_BRCM)
+#include linux/syscalls.h
+#endif
 
 static LIST_HEAD(blktrans_majors);
 
@@ -80,13 +83,23 @@
struct mtd_blktrans_ops *tr = arg;
struct request_queue *rq = tr-blkcore_priv-rq;
 
+#if defined(CONFIG_MIPS_BRCM)
+#if defined (CONFIG_PREEMPT_SOFTIRQS)
+   /* mtdblockd needs to run at the same priority as ksoftirqd threads so
loading of applications from flash won't get blocked by network traffic.
+   One bad thing about blocking application loading is that voice
applications can be blocked by network traffic, despite that they have
higher
+   priority than network tasks. This would be a priority inversion
scenario if happens. */
+   struct sched_param param = { .sched_priority =
CONFIG_BRCM_SOFTIRQ_BASE_RT_PRIO };
+   sched_setscheduler(current, SCHED_RR, param);
+#endif
+#endif
+
/* we might get involved when memory gets low, so use PF_MEMALLOC */
current-flags |= PF_MEMALLOC | PF_NOFREEZE;
 
daemonize(%sd, tr-name);
 
/* daemonize() doesn't do this for us since some kernel threads
-  actually want to deal with signals. We can't just call
+  actually want to deal with signals. We can't just call 
   exit_sighand() since that'll cause an oops when we finally
   do exit. */
spin_lock_irq(current-sighand-siglock);

-

diff -urN b/include/linux/mmzone.h a/include/linux/mmzone.h
--- b/include/linux/mmzone.h2007-06-12 16:13:11.0 +0200
+++ a/include/linux/mmzone.h2010-05-31 03:45:11.0 +0200
@@ -306,7 +306,17 @@
  * go. A value of 12 for DEF_PRIORITY implies that we will scan
1/4096th of the
  * queues (queue_length  12) during an aging round.
  */
+
+#if defined(CONFIG_MIPS_BRCM)
+/* We normally have only 8M~32M of RAM while desktop systems 

[OpenWrt-Devel] [RFC] Rngd in busybox.

[José Vázquez Fernández]

A couple of days ago found an old patch that adds rngd in busybox:
http://lists.busybox.net/pipermail/busybox/2008-August/066784.html
Because it is 5 years old will need some rework, but could be a good
alternative to rng-tools.
Also made a patch that has the option to select between /dev/hwrng
or /dev/urandom in the mentioned package.
The question is: which is the best option?

Regards:

Pepe


rng-tools.patch.tar.bz2
Description: application/bzip-compressed-tar
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] [Packages] Rng-tools: add selection between hwrng or urandom

[José Vázquez Fernández]

This patch allow to select between /dev/hwrng and /dev/urandom.

Also updates rng-tools to the last version.

Signed off by: José Vázquez Fernández ppvazquez...@gmail.com

diff --git a/utils/rng-tools/Config.in b/utils/rng-tools/Config.in
new file mode 100644
index 000..4f7b4d3
--- /dev/null
+++ b/utils/rng-tools/Config.in
@@ -0,0 +1,19 @@
+menu Configuration
+   depends on PACKAGE_rng-tools
+
+config RNGD_URANDOM
+   bool
+   default y
+   prompt Collect entropy from pseudorandom number generator
+   help
+ This is the default option for the most of the boards.
+
+config RNGD_HWRNG
+   bool
+   default n
+   prompt Collect entropy from hardware random number generator
+   help
+ Use this option only if your board has an enabled
+ hardware random number generator, otherwise use the 
+ pseudorandom number generator.
+endmenu
diff --git a/utils/rng-tools/Makefile b/utils/rng-tools/Makefile
index 474589c..f9f2add 100644
--- a/utils/rng-tools/Makefile
+++ b/utils/rng-tools/Makefile
@@ -8,12 +8,12 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=rng-tools
-PKG_VERSION:=3
+PKG_VERSION:=4
 PKG_RELEASE:=2
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
-PKG_SOURCE_URL:=http://downloads.sourceforge.net/project/gkernel/rng-tools/3/
-PKG_MD5SUM:=fa305916ec101c85c0065aeceb81a38d
+PKG_SOURCE_URL:=http://downloads.sourceforge.net/project/gkernel/rng-tools/4/
+PKG_MD5SUM:=ae89dbfcf08bdfbea19066cfbf599127
 
 PKG_FIXUP:=autoreconf
 
@@ -23,8 +23,13 @@ define Package/rng-tools
   SECTION:=utils
   CATEGORY:=Utilities
   DEPENDS:=+USE_UCLIBC:argp-standalone
-  TITLE:=Daemon for adding entropy to kernel entropy pool
+  TITLE:=Daemon for adding entropy to kernel entropy pool.
   URL:=http://sourceforge.net/projects/gkernel/
+  MENU:=1
+endef
+
+define Package/rng-tools/config
+   source $(SOURCE)/Config.in
 endef
 
 ifdef CONFIG_USE_UCLIBC
@@ -32,6 +37,7 @@ CONFIGURE_VARS += \
 LIBS=-largp
 endif
 
+ifdef CONFIG_RNGD_URANDOM
 define Package/rng-tools/install
$(INSTALL_DIR) $(1)/etc/init.d
$(INSTALL_BIN) ./files/rngd.init $(1)/etc/init.d/rngd
@@ -40,5 +46,17 @@ define Package/rng-tools/install
$(INSTALL_DIR) $(1)/sbin
$(INSTALL_BIN) $(PKG_BUILD_DIR)/rngd $(1)/sbin/
 endef
+endif
+
+ifdef CONFIG_RNGD_HWRNG
+define Package/rng-tools/install
+   $(INSTALL_DIR) $(1)/etc/init.d
+   $(INSTALL_BIN) ./files/hwrngd.init $(1)/etc/init.d/rngd
+   $(INSTALL_DIR) $(1)/usr/bin
+   $(INSTALL_BIN) $(PKG_BUILD_DIR)/rngtest $(1)/usr/bin/
+   $(INSTALL_DIR) $(1)/sbin
+   $(INSTALL_BIN) $(PKG_BUILD_DIR)/rngd $(1)/sbin/
+endef
+endif
 
 $(eval $(call BuildPackage,rng-tools))
diff --git a/utils/rng-tools/files/hwrngd.init
b/utils/rng-tools/files/hwrngd.init
new file mode 100644
index 000..40ed6fd
--- /dev/null
+++ b/utils/rng-tools/files/hwrngd.init
@@ -0,0 +1,16 @@
+#!/bin/sh /etc/rc.common
+# Copyright (C) 2011 OpenWrt.org
+
+START=98
+
+RNGD_INTERVAL=30
+RNGD_AMOUNT=4000
+RNGD_DEVICE=/dev/hwrng
+
+start() {
+   service_start /sbin/rngd -r $RNGD_DEVICE -W $RNGD_AMOUNT -t
$RNGD_INTERVAL
+}
+
+stop() {
+   service_stop /sbin/rngd
+} 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] bcm6368 + block-mount jffs2 problem.

[José Vázquez]

2013/12/5, José Vázquez ppvazquez...@gmail.com:
 I've enabled CPU_HOTPLUG in the kernel and added maxcpus=1 to the
 CMDLINE. Once openwrt boot is finished i enable the second core.
 https://www.kernel.org/doc/Documentation/cpu-hotplug.txt
 The initial tests showed that the jffs2 problem doesn't happen, but
 still more tests are needed to confirm it.

 Best regards:

 José


This time booted openwrt with smp in failsafe mode, manually mounted
mtdblock3 and strangely all the file names in that partition are
right:

root@(none):/# mount -v -t jffs2 -o noatime /dev/mtdblock3 /mnt
[  427.068000] jffs2: notice: (250) jffs2_build_xattr_subsystem:
complete building xattr subsystem, 1 of xdatum (0 unchecked, 0 orphan)
and 15 of xref (0 dead, 5 orphan) found.
root@(none):/# ls -R /mnt
/mnt:
etc

/mnt/etc:
configdropbear  ethersinit.duci-defaults

/mnt/etc/config:
fstab luci  network   uhttpdwireless

/mnt/etc/dropbear:
dropbear_dss_host_key  dropbear_rsa_host_key

/mnt/etc/init.d:
luci_fixtime

/mnt/etc/uci-defaults:
00_uhttpd_ubus   10_migrate-shadowluci-theme-bootstrap
02_network   11_migrate-sysctlluci-theme-openwrt
09_fix_crc   12_network-generate-ula
10-fstab luci-i18n-english

while in normal boot:

root@OpenWrt:/# ls -R /etc
.

/etc/crontabs:

/etc/dropbear:
droparar_host_key   dropbear_rsa_host_key
dropbear_dss_host_key  opopbear_rsa_host_key

..

/etc/init.d:
bootdone logsysctl
br2684ctl dropbearluci_dhcp_migrate  sysntpd
ciciixixmeme   firewall   luci_fixtime   telnet
cronfstab network uhttpd
dnsmasq ledrngd  umount

..

Any idea? Has anybody had something similar to this?

Bootlog: http://pastebin.com/UFXceDp4

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