Re: [OpenWrt-Devel] BRCM4716 support part 4

2010-05-16 Thread Bernhard Loos 
Hello
Thank you for tracking this down.
Here are two new patches for the scan stuff, hopefully working now.

  Bernhard Loos

2010/5/15 Hauke Mehrtens ha...@hauke-m.de:
 Am 14.05.2010 00:25, schrieb Bernhard Loos:
 Hello
 Do you have any clue, what could produce b43? Because, after looking
 at the code, I'm kinda at a loss, where this comes from. And do you
 know, which patch exactly produces the problem?
 I will split the patch up, but it may take a day or two, until I have
 the time. Some of the other patches are possible also mixed up.
 Your patch unfortunetly doesn't work as a general solution, because
 the 4716 hangs, if any of the id registers is accessed.
 Thanks again, for looking at this.

      Bernhard

 2010/5/13 Hauke Mehrtens ha...@hauke-m.de:
 Am 13.05.2010 20:54, schrieb Hauke Mehrtens:
 Hi Bernhard,

 I have changed the code to do the same things it did before your changes
 at that position. My patch is attached.

 With this patch all ssb Cores are found, but I get a oops in b43 driver
 now. Reserved instruction in kernel code

 I have not activated symbols will do now. Here is the log for now:
 http://hauke-m.de/fileadmin/openwrt/brcm47xx-log/boot-not-working2.log

 Could you please split 952-ai-scan.patch into two patches. One just
 reorganizing the existing code without changing any functionality and
 one adding the ai scan.

 Hauke
 Hi Bernhard,

 I get the following kernel oops with your patches:

 Reserved instruction in kernel code[#1]:
 ...
 Call Trace:
 [80cc4908] b43info+0x560/0x2754 [b43]
 [8018a27c] ssb_device_probe+0x44/0x80
 [80167d24] driver_probe_device+0x13c/0x28c
 [800e78ec] sysfs_create_dir+0x44/0x68
 [8012b83c] kobject_get+0x1c/0x30
 [80167e74] __driver_attach+0x0/0xa4
 [80167ee0] __driver_attach+0x6c/0xa4
 [8012bf2c] kobject_add_varg+0x28/0x78
 [801673dc] bus_for_each_dev+0x64/0xb4
 [8012bfbc] kobject_init_and_add+0x40/0x58
 [80166b2c] bus_add_driver+0xd0/0x274
 [80056d20] load_module+0x1980/0x1b4c
 [80168290] driver_register+0xe0/0x19c
 [80ce8000] init_module+0x0/0x70 [b43]
 [80ce8020] init_module+0x20/0x70 [b43]
 [8000d650] do_one_initcall+0x70/0x1f4
 [800437f0] blocking_notifier_call_chain+0x14/0x20
 [80057408] sys_init_module+0xe0/0x224
 [80092924] sys_close+0x9c/0xe4
 [80003230] stack_done+0x20/0x3c

 Full log:
 http://hauke-m.de/fileadmin/openwrt/brcm47xx-log/boot-not-working3.log

 Hauke

 Hi Bernhard,

 I found the cause of the problem. It was not in your patch series, but
 the some other openwrt parts. While building b43 from compat-wireless
 CONFIG_SSB_BLOCKIO was activated, when building ssb in the kernel is was
 deactivated. This causes the struct ssb_bus_ops to be different in ssb
 and b43. The Pointers to device_enable and so on are wrong. When they
 were called it jumped to somewhere else in the code.
 This problem is fixed in r21449 https://dev.openwrt.org/changeset/21449

 Now everything works for me like before with your patches when also
 adding the attached patch.

 In function ssb_bus_scan rev is not the same as bus-chip_rev.

 Hauke

Index: target/linux/brcm47xx/patches-2.6.32/952-ssb-scan_rework.patch
===
--- target/linux/brcm47xx/patches-2.6.32/952-ssb-scan_rework.patch	(revision 0)
+++ target/linux/brcm47xx/patches-2.6.32/952-ssb-scan_rework.patch	(revision 0)
@@ -0,0 +1,305 @@
+Index: linux-2.6.32.12/drivers/ssb/scan.c
+===
+--- linux-2.6.32.12.orig/drivers/ssb/scan.c	2010-05-11 18:04:00.0 +0200
 linux-2.6.32.12/drivers/ssb/scan.c	2010-05-11 18:14:32.810514610 +0200
+@@ -2,6 +2,7 @@
+  * Sonics Silicon Backplane
+  * Bus scanning
+  *
++ * Copyright (C) 2010 Bernhard Loos bernhardl...@googlemail.com
+  * Copyright (C) 2005-2007 Michael Buesch m...@bu3sch.de
+  * Copyright (C) 2005 Martin Langer martin-lan...@gmx.de
+  * Copyright (C) 2005 Stefano Brivio s...@riseup.net
+@@ -17,11 +18,6 @@
+ #include linux/pci.h
+ #include linux/io.h
+ 
+-#include pcmcia/cs_types.h
+-#include pcmcia/cs.h
+-#include pcmcia/cistpl.h
+-#include pcmcia/ds.h
+-
+ #include ssb_private.h
+ 
+ 
+@@ -276,15 +272,126 @@
+ 	return 0;
+ }
+ 
++/* returns 0 if the core is ok and -1 if the core should be ignored */
++static int ssb_bus_check_core(struct ssb_device *dev, int *nr_80211_cores, int corenum)
++{
++	struct ssb_bus *bus = dev-bus;
++  
++	printk(KERN_INFO PFX
++		Core %d found: %s 
++		(cc 0x%03X, rev 0x%02X, vendor 0x%04X)\n,
++		corenum, ssb_core_name(dev-id.coreid),
++		dev-id.coreid, dev-id.revision, dev-id.vendor);
++
++	switch (dev-id.coreid) {
++	case SSB_DEV_80211:
++		(*nr_80211_cores)++;
++		if (*nr_80211_cores  1) {
++			if (!we_support_multiple_80211_cores(bus)) {
++ssb_dprintk(KERN_INFO PFX Ignoring additional 
++	802.11 core\n);
++return -1;
++			}
++		}
++		break;
++	case SSB_DEV_EXTIF:
++#ifdef CONFIG_SSB_DRIVER_EXTIF
++		if (bus-extif.dev) {
++

Re: [OpenWrt-Devel] BRCM4716 support part 4

2010-05-15 Thread Hauke Mehrtens 
Am 14.05.2010 00:25, schrieb Bernhard Loos:
 Hello
 Do you have any clue, what could produce b43? Because, after looking
 at the code, I'm kinda at a loss, where this comes from. And do you
 know, which patch exactly produces the problem?
 I will split the patch up, but it may take a day or two, until I have
 the time. Some of the other patches are possible also mixed up.
 Your patch unfortunetly doesn't work as a general solution, because
 the 4716 hangs, if any of the id registers is accessed.
 Thanks again, for looking at this.
 
  Bernhard
 
 2010/5/13 Hauke Mehrtens ha...@hauke-m.de:
 Am 13.05.2010 20:54, schrieb Hauke Mehrtens:
 Hi Bernhard,

 I have changed the code to do the same things it did before your changes
 at that position. My patch is attached.

 With this patch all ssb Cores are found, but I get a oops in b43 driver
 now. Reserved instruction in kernel code

 I have not activated symbols will do now. Here is the log for now:
 http://hauke-m.de/fileadmin/openwrt/brcm47xx-log/boot-not-working2.log

 Could you please split 952-ai-scan.patch into two patches. One just
 reorganizing the existing code without changing any functionality and
 one adding the ai scan.

 Hauke
 Hi Bernhard,

 I get the following kernel oops with your patches:

 Reserved instruction in kernel code[#1]:
 ...
 Call Trace:
 [80cc4908] b43info+0x560/0x2754 [b43]
 [8018a27c] ssb_device_probe+0x44/0x80
 [80167d24] driver_probe_device+0x13c/0x28c
 [800e78ec] sysfs_create_dir+0x44/0x68
 [8012b83c] kobject_get+0x1c/0x30
 [80167e74] __driver_attach+0x0/0xa4
 [80167ee0] __driver_attach+0x6c/0xa4
 [8012bf2c] kobject_add_varg+0x28/0x78
 [801673dc] bus_for_each_dev+0x64/0xb4
 [8012bfbc] kobject_init_and_add+0x40/0x58
 [80166b2c] bus_add_driver+0xd0/0x274
 [80056d20] load_module+0x1980/0x1b4c
 [80168290] driver_register+0xe0/0x19c
 [80ce8000] init_module+0x0/0x70 [b43]
 [80ce8020] init_module+0x20/0x70 [b43]
 [8000d650] do_one_initcall+0x70/0x1f4
 [800437f0] blocking_notifier_call_chain+0x14/0x20
 [80057408] sys_init_module+0xe0/0x224
 [80092924] sys_close+0x9c/0xe4
 [80003230] stack_done+0x20/0x3c

 Full log:
 http://hauke-m.de/fileadmin/openwrt/brcm47xx-log/boot-not-working3.log

 Hauke

Hi Bernhard,

I found the cause of the problem. It was not in your patch series, but
the some other openwrt parts. While building b43 from compat-wireless
CONFIG_SSB_BLOCKIO was activated, when building ssb in the kernel is was
deactivated. This causes the struct ssb_bus_ops to be different in ssb
and b43. The Pointers to device_enable and so on are wrong. When they
were called it jumped to somewhere else in the code.
This problem is fixed in r21449 https://dev.openwrt.org/changeset/21449

Now everything works for me like before with your patches when also
adding the attached patch.

In function ssb_bus_scan rev is not the same as bus-chip_rev.

Hauke
--- a/drivers/ssb/scan.c
+++ b/drivers/ssb/scan.c
@@ -545,7 +545,7 @@ int ssb_bus_scan(struct ssb_bus *bus,
 {
 	int err = -ENOMEM;
 	void __iomem *mmio;
-	u32 tmp, chiptype = SSB_CHIPCO_TYPE_SB;
+	u32 tmp, idhi, rev, chiptype = SSB_CHIPCO_TYPE_SB;
 	bool have_chipcommon = true;
 
 	mmio = ssb_ioremap(bus, baseaddr);
@@ -572,6 +572,9 @@ int ssb_bus_scan(struct ssb_bus *bus,
 	
 	bus-nr_devices = 0;
 	if (have_chipcommon) {
+		idhi = scan_read32(bus, 0, SSB_IDHIGH);
+		rev = (idhi  SSB_IDHIGH_RCLO);
+		rev |= (idhi  SSB_IDHIGH_RCHI)  SSB_IDHIGH_RCHI_SHIFT;
 		tmp = scan_read32(bus, 0, SSB_CHIPCO_CHIPID);
 
 		bus-chip_id = (tmp  SSB_CHIPCO_IDMASK);
@@ -580,7 +583,7 @@ int ssb_bus_scan(struct ssb_bus *bus,
 		bus-chip_package = (tmp  SSB_CHIPCO_PACKMASK) 
 SSB_CHIPCO_PACKSHIFT;
 		chiptype = tmp  SSB_CHIPCO_TYPE_MASK;
-		if (bus-chip_rev = 4) {
+		if (rev = 4) {
 			bus-nr_devices = (tmp  SSB_CHIPCO_NRCORESMASK) 
 	  SSB_CHIPCO_NRCORESSHIFT;
 		}
--- a/drivers/ssb/driver_chipcommon_pmu.c
+++ b/drivers/ssb/driver_chipcommon_pmu.c
@@ -324,7 +324,7 @@ static void ssb_pmu_pll_init(struct ssb_
 		break; 
 	case 0x4322:
 		if (cc-pmu.rev == 2)
-			ssb_chipco_pll_write(0xa, 0x380005C0);
+			ssb_chipco_pll_write(cc, 0xa, 0x380005C0);
 		break;
 	default:
 		ssb_printk(KERN_ERR PFX
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] BRCM4716 support part 4

2010-05-13 Thread Hauke Mehrtens 
Am 13.05.2010 01:08, schrieb Bernhard Loos:
 Sorry, I goofed up while porting the patch to latest trunk, as I did
 develop this on an older svn revision.
 The line should be ssb_chipco_pll_write(cc, 0xa, 0x380005C0);
 
 Bernhard
Hi Bernhard,

Now it compiles for me.

I have just installed it on my Asus WL-500GP v1 and it boots and
Ethernet is working, but wireless is not working any more.

I found some differences in the dmesg output:

Without your patches (working):
PCI: Setting latency timer of device :00:02.0 to 64
ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x0D, vendor 0x4243)
ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x09, vendor 0x4243)
ssb: Core 2 found: PCI (cc 0x804, rev 0x0C, vendor 0x4243)
ssb: Core 3 found: PCMCIA (cc 0x80D, rev 0x07, vendor 0x4243)
ssb: SPROM revision 2 detected.
ssb: Sonics Silicon Backplane found on PCI device :00:02.0
NET: Registered protocol family 2

With your patches (not working):
PCI: Setting latency timer of device :00:02.0 to 64
ssb: CHIPID not in nrcores fallback list
ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x0D, vendor 0x4243)
ssb: SPROM revision 2 detected.
ssb: Sonics Silicon Backplane found on PCI device :00:02.0
NET: Registered protocol family 2

The full dmesg output can be found here:
http://hauke-m.de/fileadmin/openwrt/brcm47xx-log/boot-working.log
http://hauke-m.de/fileadmin/openwrt/brcm47xx-log/boot-not-working.log

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

Re: [OpenWrt-Devel] BRCM4716 support part 4

2010-05-13 Thread Bernhard Loos 
Hello
Around line 583 in drivers/sbb/scan.c, there should be an if
(bus-chip_rev =4).
Could you remove the if and always execute the code which assigns
bus-nr_devices?
This shouldn't be a problem, because the bits for the device number
should be zero on cores which don't support it.
I can also provide a new patch, if you like it better.

   Bernhard

2010/5/13 Hauke Mehrtens ha...@hauke-m.de:
 Am 13.05.2010 01:08, schrieb Bernhard Loos:
 Sorry, I goofed up while porting the patch to latest trunk, as I did
 develop this on an older svn revision.
 The line should be ssb_chipco_pll_write(cc, 0xa, 0x380005C0);

         Bernhard
 Hi Bernhard,

 Now it compiles for me.

 I have just installed it on my Asus WL-500GP v1 and it boots and
 Ethernet is working, but wireless is not working any more.

 I found some differences in the dmesg output:

 Without your patches (working):
 PCI: Setting latency timer of device :00:02.0 to 64
 ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x0D, vendor 0x4243)
 ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x09, vendor 0x4243)
 ssb: Core 2 found: PCI (cc 0x804, rev 0x0C, vendor 0x4243)
 ssb: Core 3 found: PCMCIA (cc 0x80D, rev 0x07, vendor 0x4243)
 ssb: SPROM revision 2 detected.
 ssb: Sonics Silicon Backplane found on PCI device :00:02.0
 NET: Registered protocol family 2

 With your patches (not working):
 PCI: Setting latency timer of device :00:02.0 to 64
 ssb: CHIPID not in nrcores fallback list
 ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x0D, vendor 0x4243)
 ssb: SPROM revision 2 detected.
 ssb: Sonics Silicon Backplane found on PCI device :00:02.0
 NET: Registered protocol family 2

 The full dmesg output can be found here:
 http://hauke-m.de/fileadmin/openwrt/brcm47xx-log/boot-working.log
 http://hauke-m.de/fileadmin/openwrt/brcm47xx-log/boot-not-working.log

 Hauke

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

Re: [OpenWrt-Devel] BRCM4716 support part 4

2010-05-13 Thread Hauke Mehrtens 
Am 13.05.2010 18:52, schrieb Bernhard Loos:
 Hello
 Around line 583 in drivers/sbb/scan.c, there should be an if
 (bus-chip_rev =4).
 Could you remove the if and always execute the code which assigns
 bus-nr_devices?
 This shouldn't be a problem, because the bits for the device number
 should be zero on cores which don't support it.
 I can also provide a new patch, if you like it better.
 
Bernhard
Hi Bernhard,

I have changed the code to do the same things it did before your changes
at that position. My patch is attached.

With this patch all ssb Cores are found, but I get a oops in b43 driver
now. Reserved instruction in kernel code

I have not activated symbols will do now. Here is the log for now:
http://hauke-m.de/fileadmin/openwrt/brcm47xx-log/boot-not-working2.log

Could you please split 952-ai-scan.patch into two patches. One just
reorganizing the existing code without changing any functionality and
one adding the ai scan.

Hauke
--- a/drivers/ssb/scan.c	2010-05-13 17:18:05.347256703 +0200
+++ b/drivers/ssb/scan.c	2010-05-13 20:43:53.887257939 +0200
@@ -545,7 +545,7 @@
 {
 	int err = -ENOMEM;
 	void __iomem *mmio;
-	u32 tmp, chiptype = SSB_CHIPCO_TYPE_SB;
+	u32 tmp, idhi, rev, chiptype = SSB_CHIPCO_TYPE_SB;
 	bool have_chipcommon = true;
 
 	mmio = ssb_ioremap(bus, baseaddr);
@@ -572,6 +572,9 @@
 	
 	bus-nr_devices = 0;
 	if (have_chipcommon) {
+		idhi = scan_read32(bus, 0, SSB_IDHIGH);
+		rev = (idhi  SSB_IDHIGH_RCLO);
+		rev |= (idhi  SSB_IDHIGH_RCHI)  SSB_IDHIGH_RCHI_SHIFT;
 		tmp = scan_read32(bus, 0, SSB_CHIPCO_CHIPID);
 
 		bus-chip_id = (tmp  SSB_CHIPCO_IDMASK);
@@ -580,7 +583,7 @@
 		bus-chip_package = (tmp  SSB_CHIPCO_PACKMASK) 
 SSB_CHIPCO_PACKSHIFT;
 		chiptype = tmp  SSB_CHIPCO_TYPE_MASK;
-		if (bus-chip_rev = 4) {
+		if (rev = 4) {
 			bus-nr_devices = (tmp  SSB_CHIPCO_NRCORESMASK) 
 	  SSB_CHIPCO_NRCORESSHIFT;
 		}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] BRCM4716 support part 4

2010-05-13 Thread Hauke Mehrtens 
Am 13.05.2010 20:54, schrieb Hauke Mehrtens:
 Am 13.05.2010 18:52, schrieb Bernhard Loos:
 Hello
 Around line 583 in drivers/sbb/scan.c, there should be an if
 (bus-chip_rev =4).
 Could you remove the if and always execute the code which assigns
 bus-nr_devices?
 This shouldn't be a problem, because the bits for the device number
 should be zero on cores which don't support it.
 I can also provide a new patch, if you like it better.

Bernhard
 Hi Bernhard,
 
 I have changed the code to do the same things it did before your changes
 at that position. My patch is attached.
 
 With this patch all ssb Cores are found, but I get a oops in b43 driver
 now. Reserved instruction in kernel code
 
 I have not activated symbols will do now. Here is the log for now:
 http://hauke-m.de/fileadmin/openwrt/brcm47xx-log/boot-not-working2.log
 
 Could you please split 952-ai-scan.patch into two patches. One just
 reorganizing the existing code without changing any functionality and
 one adding the ai scan.
 
 Hauke
Hi Bernhard,

I get the following kernel oops with your patches:

Reserved instruction in kernel code[#1]:
...
Call Trace:
[80cc4908] b43info+0x560/0x2754 [b43]
[8018a27c] ssb_device_probe+0x44/0x80
[80167d24] driver_probe_device+0x13c/0x28c
[800e78ec] sysfs_create_dir+0x44/0x68
[8012b83c] kobject_get+0x1c/0x30
[80167e74] __driver_attach+0x0/0xa4
[80167ee0] __driver_attach+0x6c/0xa4
[8012bf2c] kobject_add_varg+0x28/0x78
[801673dc] bus_for_each_dev+0x64/0xb4
[8012bfbc] kobject_init_and_add+0x40/0x58
[80166b2c] bus_add_driver+0xd0/0x274
[80056d20] load_module+0x1980/0x1b4c
[80168290] driver_register+0xe0/0x19c
[80ce8000] init_module+0x0/0x70 [b43]
[80ce8020] init_module+0x20/0x70 [b43]
[8000d650] do_one_initcall+0x70/0x1f4
[800437f0] blocking_notifier_call_chain+0x14/0x20
[80057408] sys_init_module+0xe0/0x224
[80092924] sys_close+0x9c/0xe4
[80003230] stack_done+0x20/0x3c

Full log:
http://hauke-m.de/fileadmin/openwrt/brcm47xx-log/boot-not-working3.log

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

Re: [OpenWrt-Devel] BRCM4716 support part 4

2010-05-13 Thread Bernhard Loos 
Hello
Do you have any clue, what could produce b43? Because, after looking
at the code, I'm kinda at a loss, where this comes from. And do you
know, which patch exactly produces the problem?
I will split the patch up, but it may take a day or two, until I have
the time. Some of the other patches are possible also mixed up.
Your patch unfortunetly doesn't work as a general solution, because
the 4716 hangs, if any of the id registers is accessed.
Thanks again, for looking at this.

 Bernhard

2010/5/13 Hauke Mehrtens ha...@hauke-m.de:
 Am 13.05.2010 20:54, schrieb Hauke Mehrtens:
 Am 13.05.2010 18:52, schrieb Bernhard Loos:
 Hello
 Around line 583 in drivers/sbb/scan.c, there should be an if
 (bus-chip_rev =4).
 Could you remove the if and always execute the code which assigns
 bus-nr_devices?
 This shouldn't be a problem, because the bits for the device number
 should be zero on cores which don't support it.
 I can also provide a new patch, if you like it better.

                Bernhard
 Hi Bernhard,

 I have changed the code to do the same things it did before your changes
 at that position. My patch is attached.

 With this patch all ssb Cores are found, but I get a oops in b43 driver
 now. Reserved instruction in kernel code

 I have not activated symbols will do now. Here is the log for now:
 http://hauke-m.de/fileadmin/openwrt/brcm47xx-log/boot-not-working2.log

 Could you please split 952-ai-scan.patch into two patches. One just
 reorganizing the existing code without changing any functionality and
 one adding the ai scan.

 Hauke
 Hi Bernhard,

 I get the following kernel oops with your patches:

 Reserved instruction in kernel code[#1]:
 ...
 Call Trace:
 [80cc4908] b43info+0x560/0x2754 [b43]
 [8018a27c] ssb_device_probe+0x44/0x80
 [80167d24] driver_probe_device+0x13c/0x28c
 [800e78ec] sysfs_create_dir+0x44/0x68
 [8012b83c] kobject_get+0x1c/0x30
 [80167e74] __driver_attach+0x0/0xa4
 [80167ee0] __driver_attach+0x6c/0xa4
 [8012bf2c] kobject_add_varg+0x28/0x78
 [801673dc] bus_for_each_dev+0x64/0xb4
 [8012bfbc] kobject_init_and_add+0x40/0x58
 [80166b2c] bus_add_driver+0xd0/0x274
 [80056d20] load_module+0x1980/0x1b4c
 [80168290] driver_register+0xe0/0x19c
 [80ce8000] init_module+0x0/0x70 [b43]
 [80ce8020] init_module+0x20/0x70 [b43]
 [8000d650] do_one_initcall+0x70/0x1f4
 [800437f0] blocking_notifier_call_chain+0x14/0x20
 [80057408] sys_init_module+0xe0/0x224
 [80092924] sys_close+0x9c/0xe4
 [80003230] stack_done+0x20/0x3c

 Full log:
 http://hauke-m.de/fileadmin/openwrt/brcm47xx-log/boot-not-working3.log

 Hauke

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

[OpenWrt-Devel] BRCM4716 support part 4

2010-05-12 Thread Bernhard Loos 
Sorry, I goofed up while porting the patch to latest trunk, as I did
develop this on an older svn revision.
The line should be ssb_chipco_pll_write(cc, 0xa, 0x380005C0);

        Bernhard

2010/5/12 Hauke Mehrtens ha...@hauke-m.de:
 Am 07.05.2010 22:38, schrieb Bernhard Loos:
 Hello
 This is another patch for the 4716.
 This replaces patch #3, as it had a bunch of problems.
 With this patch the device boots and works reasonable well -
 considering the missing drivers, but I have already an idea for those.
 Serial init complains, but this is not critical.
 One of the patches disables the support for pci-e host mode, because I
 kinda doubt this ever worked.
 If anybody has informations about ssb devices with an pci-e
 controller, please tell me.

 Hi Bernhard,

 I have tried your patch but I get an compile error:

  CC      drivers/ssb/driver_chipcommon_pmu.o
 drivers/ssb/driver_chipcommon_pmu.c: In function 'ssb_pmu_pll_init':
 drivers/ssb/driver_chipcommon_pmu.c:327: warning: passing argument 1 of
 'ssb_chipco_pll_write' makes pointer from integer without a cast
 drivers/ssb/driver_chipcommon_pmu.c:327: error: too few arguments to
 function 'ssb_chipco_pll_write'

 After removing the bad change in 957-brcm4716-pmu.patch it compiles for me.

 I renamed some patches as they should end with .patch

 Hauke

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

[OpenWrt-Devel] BRCM4716 support part 3

2010-04-29 Thread Bernhard Loos 
Hello
This includes 2 patches to add the actual scan method for the ai type
bus and implementations for enalbe/disable device.
The ai scan patch is a bit difficult, because I more or less assumes
that the first core is a chipcommon core, which is at least for the
4710 soc not the case. I'm not completly sure, how this patch behaves
on those devices. Unfortunetly, it's hard to avoid this problem,
because I can't scan the ssb without knowing the scan method to use,
and without scanning the ssb, I don't know the type of the first core.
For the enable/disable functions I introduced 3 function pointers in
struct ssb_bus.

  Bernhard


n16_3.diff
Description: Binary data
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] BRCM4716 support part 2

2010-04-24 Thread Alexandros C. Couloumbis 
2010/4/15 Bernhard Loos bernhardloos at googlemail.com:
 Hello
 This adds two patches to brcm47xx.
 950-sbb-sysfs-files.patch is not 4716 specific and adds a bunch of
 sysfs attributes to ssb devices, similiar to pci devices.
 951-brcm4716-defines.patch contains defines for registers and device
 ids used on th brcm4716

 Bernhard


Applied on r21119  r21145

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

[OpenWrt-Devel] BRCM4716 support part 2

2010-04-14 Thread Bernhard Loos 
Hello
This adds two patches to brcm47xx.
950-sbb-sysfs-files.patch is not 4716 specific and adds a bunch of
sysfs attributes to ssb devices, similiar to pci devices.
951-brcm4716-defines.patch contains defines for registers and device
ids used on th brcm4716

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

Re: [OpenWrt-Devel] BRCM4716 support part 2

2010-04-14 Thread Bernhard Loos 
And I forgot the actual patch again, sorry.

2010/4/15 Bernhard Loos bernhardl...@googlemail.com:
 Hello
 This adds two patches to brcm47xx.
 950-sbb-sysfs-files.patch is not 4716 specific and adds a bunch of
 sysfs attributes to ssb devices, similiar to pci devices.
 951-brcm4716-defines.patch contains defines for registers and device
 ids used on th brcm4716

         Bernhard



n16_2.diff
Description: Binary data
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] BRCM4716 support

2010-03-27 Thread Bernhard Loos 
Hello
I did work on adding support for the BRCM4716 to openwrt after getting
an ASUS RT-N16 from glp.
The main problem is, that the sonics silicon backplane is completly
different especially the registers of the actual backplane.
Also, it uses a different MIPS core and also a different ethernet mac
then the other models.
I did manage to get a booting kernel which seems to run fine, but
pretty much everything useful is missing (including ethernet)
I would like to split the patch into smaller chunks and send them here
as I have time. The complete patch is here (minus the part in this
mail): https://dev.openwrt.org/attachment/ticket/6580/asus.diff

The first patch adjusts the caching code, because it reads a backplane
register, which isn't there on the 4716.
I'm not completly sure, how this code works, but it only seems to be a
dummy read, so I used register 0 instead.

  Bernhard


n16_1.diff
Description: Binary data
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel