Re: [PATCH V4] ssb: Implement virtual SPROM
On 03/26/2010 06:18 AM, Gene Heskett wrote: On Friday 26 March 2010, Larry Finger wrote: Some recent BCM43XX devices lack an on-board SPROM. The pertinent data from the SPROM could be included in the kernel; however, this presents a problem in the generation of a unique, reproducible MAC address. The solution is to initialize the address to a known, workable value. Thus, the device will work without any further code. For an address that is preserved across reloads or reboots, a set of udev routines has been prepared that detect the special address and assign a random value that is preserved in a second udev rule file. The random address should be unique except for the case where a given box has more than one of these cards. This case is handles by adding the DEVPATH to the recognition rules. Signed-off-by: Larry Finger larry.fin...@lwfinger.net This I assume does not do anything for the idiot vendor who ships thousands of bt dongles all with 11:11:11:11:11:11 set as the mac address? I got stung with 2 of those things. Sending a duplicated address is bad enough, but making it be a broadcast address is particularly bad. On the other hand, the udev technique used here could be employed to do a unique MAC address assignment for these devices. Do you still have them? Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] ssb: Implement virtual SPROM on disk
On 03/23/2010 03:58 PM, Calvin Walton wrote:
I will warn you that the following is rather untested, as I don't have
any of the affected hardware (or any b43 devices at all, actually), but
something along these lines should work. There's no syntax errors, at
least :)
--- /lib/udev/rules.d/65-persistent-b43-mac-generator.rules
ACTION!=add GOTO=persistent_b43_mac_generator_end
SUBSYSTEM==net, DRIVERS==b43, ATTR{address}==ff:ff:ff:ff:ff:ff,
IMPORT{program}=write_persistent_b43_mac
SUBSYSTEM==net, ENV{MACADDRESS_NEW}==?*, RUN+=ifconfig $env{INTERFACE}
hw ether $env{MACADDRESS_NEW}
LABEL=persistent_b43_mac_generator_end
--- /lib/udev/write_persistent_b43_mac (chmod +x)
#!/bin/bash
# This mac address generation function could be replaced with something better
MACADDRESS=$(dd if=/dev/urandom bs=1 count=6 2/dev/null | od -tx1 | head -1
| cut -d' ' -f2- | awk '{ print $1:$2:$3:$4:$5:$6 }')
RULES_FILE='/etc/udev/rules.d/60-persistent-b43-mac.rules'
. /lib64/udev/rule_generator.functions
lock_rules_file
choose_rules_file
echo DEVPATH==\$DEVPATH\, DRIVERS==\b43\,
ATTR{address}==\ff:ff:ff:ff:ff:ff\, RUN+=\ifconfig $INTERFACE hw ether
$MACADDRESS\ $RULES_FILE
echo MACADDRESS_NEW=$MACADDRESS
unlock_rules_file
---
A new file /etc/udev/rules.d/60-persistent-b43-mac.rules will be
created, which will contain the the saved mac address and bypass the
generating script on future boots.
This should probably be run by the udev maintainers, but is a start,
anyways.
Thanks for the really good start.
The above routines have a minor problem in that using a random value for the
first byte of the MAC address runs the risk of having the multicast bit set. By
fixing the first one to a multiple of 4, that problem is avoided.
A second minor problem is that the full path must be given for all standard
utilities, otherwise they are assumed to be in /lib/udev. Thus all references to
ifconfig were replaced by /sbin/ifconfig. I hope all distros put ifconfig in
/sbin.
I have modified ssb to supply a MAC address of 80:80:80:80:80:80, rather than
FF:FF:FF:FF:FF:FF. This way the interface can come up even though the new udev
routines are not available. When b43 detects that address, it will log a message
describing why the udev routines are needed, and how to obtain them.
The one remaining problem is that the interface has already been renamed before
60-persistent-b43-mac.rules is processed. In my case, the interface is wlan13,
not wlan0. After I manually modified 60-..., then the new address is applied.
I'm still working on this problem.
Thanks again for the help.
Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] ssb: Implement virtual SPROM on disk
On 03/23/2010 03:52 AM, Michael Buesch wrote: On Tuesday 23 March 2010 00:45:28 Larry Finger wrote: (2) In drivers/ssb/pci.c, the firmware loading process reads the file, then modifies it using the bus address. No. You don't need firmware loading at all. udev can just set the mac address through the standard ioctl calls. Just like how ifconfig and ip can do. Will someone please write me udev rule(s) that do the following: 1. Detect a MAC address of FF:FF:FF:FF:FF:FF 2. If this is the first time for this bus address, then generate a random MAC address with the bus address encoded in it. 3. Preserve the address for future reloads 4. Load the saved address into the device. 5. Do the above with only standard external commands - no new programs My skills with udev are not up to the task. I now have code running that uses the firmware load facility to read a file created by /bin/dbus-uuidgen to create a MAC address that will satisfy the requirements. If the file is needed but not available, then the user is prompted with the commands needed to create it. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH V3] ssb: Implement virtual SPROM
Some recent BCM43XX devices lack an on-board SPROM. The pertinent data
from the SPROM could be included in the kernel; however, this presents
a problem in the generation of a unique, reproducible MAC address. The
solution is to use a file in /lib/firmware/ssb, which has some random
information generated by /bin/dbus-uuidgen. This file is loaded using the
asynchronous firmware facility and a MAC address is generated from those
data. To prevent multiple devices in a single box from having the same
MAC address, the last two digits are replaced by the bus numbers of the
device.
Signed-off-by: Larry Finger larry.fin...@lwfinger.net
---
John,
Unless someone comes up with a unique way to generate a MAC address using
only udev rules, I think this is ready.
I suspect it is a little to invasive for 2.6.34. In addition, it fixes
a bug, but not a regression.
Larry
---
V2 - make virtual SPROM loading asynchronous.
V3 - eliminate the need for a special external utility
- set for unique MAC address even if a box has more than one of these
devices
Index: wireless-testing/drivers/ssb/pci.c
===
--- wireless-testing.orig/drivers/ssb/pci.c
+++ wireless-testing/drivers/ssb/pci.c
@@ -19,6 +19,7 @@
#include linux/ssb/ssb_regs.h
#include linux/pci.h
#include linux/delay.h
+#include linux/firmware.h
#include ssb_private.h
@@ -613,6 +614,120 @@ static int sprom_extract(struct ssb_bus
return 0;
}
+static void ssb_vsprom_load_failed(void)
+{
+ printk(KERN_ERR ssb: The BCM43XX device does not have an
+ SPROM built in. Use the command\n);
+ printk(KERN_ERR 'mkdir -p /lib/firmware/ssb ; /bin/dbus-uuidgen
+ /lib/firmware/ssb/mac_addr'\n);
+ printk(KERN_ERR to generate the required file.\n);
+}
+
+static inline u8 ascii_to_bin(u8 input)
+{
+ /* return the binary value of the ASCII char in the low nibble */
+ return (input = 0x39) ? input 0xF : (input - 0x27) 0xF;
+}
+
+static void ssb_get_vsprom(const struct firmware *fw, void *context)
+{
+ /* Second part of asynchronous firmware load */
+ int i;
+ struct ssb_bus *bus = context;
+ struct ssb_sprom *sprom = bus-sprom;
+ u8 buf2[8];
+ char *name;
+
+ if (!fw) {
+ ssb_vsprom_load_failed();
+ return;
+ }
+ /* Get values extracted from SPROM. If sprom_extract_r8() is changed,
+* this section must be changed as well. For any device with 5GHz
+* capability, some variables will have to be changed.
+*/
+ sprom-revision = 8;
+ sprom-boardflags_lo = 0x0A01;
+ sprom-boardflags_hi = 0x0006;
+ sprom-boardflags2_lo = 0x;
+ sprom-boardflags2_hi = 0x;
+ sprom-ant_available_a = 0x00;
+ sprom-ant_available_bg = 0x03;
+ sprom-maxpwr_bg = 0x4A;
+ sprom-itssi_bg = 0x3E;
+ sprom-maxpwr_a = 0xFF;
+ sprom-itssi_a = 0xFF;
+ sprom-maxpwr_ah = 0xFF;
+ sprom-maxpwr_al = 0xFF;
+ sprom-gpio0 = 0x83;
+ sprom-gpio1 = 0xFF;
+ sprom-gpio2 = 0xFF;
+ sprom-gpio3 = 0xFF;
+ sprom-tri2g = 0x6C;
+ sprom-tri5g = 0x00;
+ sprom-tri5gl = 0xFF;
+ sprom-tri5gh = 0xFF;
+ sprom-rxpo2g = 0xFA;
+ sprom-rxpo5g = 0xFF;
+ sprom-rssismf2g = 0x0F;
+ sprom-rssismc2g = 0x00;
+ sprom-rssisav2g = 0x00;
+ sprom-bxa2g = 0x00;
+ sprom-rssismf5g = 0x0F;
+ sprom-rssismc5g = 0x0F;
+ sprom-rssisav5g = 0x07;
+ sprom-bxa5g = 0x03;
+ sprom-pa0b0 = 0x1a57;
+ sprom-pa0b1 = 0xF98A;
+ sprom-pa0b2 = 0xFE91;
+ sprom-pa1b0 = 0x;
+ sprom-pa1b1 = 0x;
+ sprom-pa1b2 = 0x;
+ sprom-pa1lob0 = 0x;
+ sprom-pa1lob1 = 0x;
+ sprom-pa1lob2 = 0x;
+ sprom-pa1hib0 = 0x;
+ sprom-pa1hib1 = 0x;
+ sprom-pa1hib2 = 0x;
+ sprom-cck2gpo = 0x;
+ sprom-ofdm2gpo = 0x0002;
+ sprom-ofdm5glpo = 0x;
+ sprom-ofdm5gpo = 0x;
+ sprom-ofdm5ghpo = 0x;
+ memset(sprom-et0mac, 0xFF, 6);
+ memset(sprom-et1mac, 0xFF, 6);
+
+ if (fw-size != 33) {
+ printk(KERN_ERR ssb: The MAC address file has the wrong
+ size\n);
+ goto out;
+ }
+ /* Input MAC address data in ASCII - get low nibble in binary */
+ for (i = 0 ; i 8; i++) {
+ u8 tmp = ascii_to_bin(fw-data[2 * i]);
+ u8 tmp1 = ascii_to_bin(fw-data[2 * i + 1]);
+ buf2[i] = tmp 4 | tmp1;
+ }
+ /* make sure 2 least significant bits of first byte are clear
+* These bits are multicast address and LAA bit, and
+* copy the randomized MAC address to the sprom variables
+*/
+ buf2[0] = ~(3);
+ memcpy(sprom-il0mac, buf2, 4);
+
+ /* As there may
Re: Works wonderfully except at Barnes and Nobles.
On 03/22/2010 09:57 PM, Frank Middleton wrote: Had some really great experiences with your software recently, especially using a public Wifi system with really weak/out of range signals. I could still get emails even when Windows couldn't find any unencrypted APs, and it worked like a champ even at one site where there were 14 APs. FWIW it kept working flawlessly through dozens of suspend/resumes, something the eth0 driver couldn't do. Thanks for a robust and useful product! Good to hear. I did notice that the system log had a very large number of entries like the following that coincided with the out of range usage. This isn't a question, just an observation that might perhaps be useful. It didn't seem to be a problem (this on a very recent Fedora C10). Mar 2 23:19:56 host10 kernel: b43-phy0 ERROR: PHY transmission error Mar 2 23:19:56 host10 kernel: b43-phy0 ERROR: PHY transmission error Mar 2 23:19:56 host10 kernel: b43-phy0 ERROR: PHY transmission error We don't know why the firmware is generating these errors. In general, they are harmless. However, I do have a question - maybe this isn't the right list to ask, but not sure which one would be. We tried a Barnes and Noble store which had free WiFi access, but I couldn't get it to associate with the AP at all. This is one of those setups where it forces your initial browser access to an agreement page. I suppose this might have worked with Windows and subsequently the B43 device might have been able to associate. Can anyone explain why this didn't work, or a way to make it work? You don't say what distro you are using, nor what kernel. It has been a while since I connected to an AP using that method, but it worked with openSUSE 11.2 and what was probably a 2.6.32 kernel. With the KDE flavor of NetworkManager's applet, I created a connection to the AP, then used the applet to connect to it. Once associated and an IP was obtained with DHCP, I launched the browser, and up came the sign-in page. This was at a Starbucks where the service was not free, so I did go any further. Internet access was not that important at the time. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 14e4:4315 (Dell Wireless 1397) cannot find networks after use of b43 driver
On 03/23/2010 02:30 PM, Chris Lopes wrote: Hi, I had a perfectly working Dell system running Windows Vista and using version 5.60.188.1 of the Broadcom windows driver (distributed by Dell) for what Windows calls the Dell Wireless 1397 WLAN Mini-Card, which is actually 14e4:4315. I booted Parted Magic 4.9 from a USB flash drive, which uses the 2.6.32 linux kernel. I started up networking in Parted Magic and asked it to configure the wireless driver. At first it found my normal SSID and I asked it to try to connect, but it failed. I thought this was just a transient issue specific to Parted Magic and/or linux. So I booted bank into Vista, only to see that although Vista reports everything as being fine with the card, no wireless networks are ever detected. I have verified that the wireless networks that I expect indeed exist and are in range (the machine has not moved). Is it possible that the b43 driver somehow corrupted the firmware/ROM of my card such that it does not function correctly? Can I fix this? There is a DMA error (also shown below in context): b43-phy0 ERROR: Fatal DMA error: 0x0400, 0x, 0x, 0x, 0x, 0x No, b43 did not corrupt your firmware. The firmware is not contained in non-volatile memory. With a power-down, it goes away. There is an EEPROM containing some initial values, but changing that requires specific actions through the sysfs, and does not happen accidentally. The wl and Windows drivers have the firmware embedded in the driver. For copyright reasons, we cannot do that, which is why there is external firmware. Your DMA error is a known problem with 14e4:4315 devices with Netbooks and some other systems with Intel processors and a Phoenix BIOS. Again, we have no fix. With a 2.6.33 kernel, the system will seamlessly switch to PIO mode when the fatal DMA error occurs. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 14e4:4315 (Dell Wireless 1397) cannot find networks after use of b43 driver
On 03/23/2010 02:53 PM, Chris Lopes wrote: Thanks for the quick reply. So are you saying that it is impossible that the b43 driver could have somehow made my wireless card unable to detect any networks after a reboot (in either Windows or Linux)? I don't know of any way that b43 could have done that. A power-down including removal of the battery should completely put the device in the original condition. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 14e4:4315 (Dell Wireless 1397) cannot find networks after use of b43 driver
On 03/23/2010 03:31 PM, Chris Lopes wrote: Ok. I got my wireless card to detect networks again. I also had a theory and tried to reproduce the problem, and was successful in doing so. Here are my steps to reproduce: 1) Have Vista running and connected to a wireless network 2) Hibernate Vista 3) Boot Parted Magic from a USB drive 4) Start the network in Parted Magic, ask it to use wireless, and then attempt to connect to my normal SSID, which at this point sees the SSID, but cannot connect due to an apparent DHCP lease error 5) Start the network in Parted Magic again, which this time fails with a generic error and does not show any SSID's (starting it a second time is necessary to reproduce the problem) 6) Reboot 7) Resume Vista 8) At this point, Vista loses connectivity to the wireless network 9) Reboot Vista 10) Vista still cannot see any wireless networks 11) Shutdown 12) Remove power cord and battery and wait a bit 13) Boot Vista, and it now works and sees the network As you just eluded to, it seems that the power-down and battery removal is necessary What do you think is the culprit here? You should never hibernate one OS and run a different one. That is a prescription for disaster. Although there is nothing in the BCM4312 that can be changed, Vista could set a given state in the BIOS that is destroyed by booting Linux. Fortunately, this info seems to be in volatile memory, thus the power off and battery removal fixes it. You might look at the BIOS settings to see if there is a Wake On LAN option for the wireless. It should be off. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] ssb: Implement virtual SPROM on disk
On 03/22/2010 03:37 AM, Michael Buesch wrote: On Monday 22 March 2010 07:28:23 Calvin Walton wrote: Hi, On Sat, 2010-03-20 at 19:14 -0500, Larry Finger wrote: Some recent BCM43XX devices lack an on-board SPROM. The pertinent data from the SPROM could be included in the kernel; however, this presents a problem in the generation of a unique, reproducible MAC address. The solution has been to create a utility that generates a virtual SPROM image with a random MAC address. This image is stored in the firmware area, and loaded using the asyncronous firmware load facility. I'm curious, how would this firmware-loading scheme deal with having multiple cards of this type installed? This seems like an unusual situation, but it looks like this patch will cause all of the cards to start up with the same MAC address due to the fixed filename. Instead of using a firmware file to load in the MAC address, might it be possible to move the persistent MAC setting to a simple udev rule which generates a persistent MAC address, saves it, then sets it each boot using a command like ip link set wlan0 address XX:XX:XX:XX:XX:XX ? This would remove the need to have this fake firmware file available at boot, provided that the driver can handle leaving the address unconfigured until userspace gets around to setting it. As well, it could be written to work with multiple cards easily, saving a different MAC for each. Some thoughts for your consideration, I think this actually is a very good idea. This way we could live without a user-supplied sprom image, which I would _really_ prefer. Avoiding the use of a new user-space program would be desirable, but I cannot think of any way that a udev rule could distinguish one card from another. If we had any unique features such as a serial number, then we wouldn't need user space at all. Any suggestions? Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] ssb: Implement virtual SPROM on disk
On 03/22/2010 04:55 PM, Michael Buesch wrote: I don't see a problem for udev to distinguish the cards. It can do it merely on the bus-ID. That's unique. Yeah, it might change if you change the hardware. But do we care? I say no, because you cannot actually change the hardware in real life for any of these devices. And even if you could reorder the devices on the bus or whatever. What would happen? The card would get a new MAC address. That's all. That's acceptable. The kernel would (for example) just set the mac address to all-ones. Udev would notice this (invalid) mac address and reassign a new persistent one to the device. It then stores the address on the harddisk. What ensures that this persistent name would be unique? In fact, if we implement a mechanism in the kernel, we have _exactly_ the same problem. However, currently Larry's patches just ignore that problem and assume that there's only one card in the system anyway. As I said in a posting a few minutes ago, that problem is solved. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] ssb: Implement virtual SPROM on disk
Michael, Would the following be sufficient? (1) The utility /bin/dbus-uuidgen is used to create a file /lib/firmware/ssb/mac_address. The command to create this file if it does not exist could be added to the scripts that use fwcutter. (2) In drivers/ssb/pci.c, the firmware loading process reads the file, then modifies it using the bus address. I think this process would create a persistent MAC address that is unique within the box, with a small probability of being duplicated on another machine. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH V2] ssb: Implement virtual SPROM on disk
Some recent BCM43XX devices lack an on-board SPROM. The pertinent data
from the SPROM could be included in the kernel; however, this presents
a problem in the generation of a unique, reproducible MAC address. The
solution has been to create a utility that generates a virtual SPROM
image with a random MAC address. This image is stored in the firmware
area, and loaded using the asyncronous firmware load facility.
Signed-off-by: Larry Finger larry.fin...@lwfinger.net
---
Michael,
I think this patch eliminates the need for the fallback sprom code; however,
I have not touched that facility yet.
Larry
---
V2 - make virstual SPROM loading asynchronous.
Index: wireless-testing/drivers/ssb/pci.c
===
--- wireless-testing.orig/drivers/ssb/pci.c
+++ wireless-testing/drivers/ssb/pci.c
@@ -19,6 +19,7 @@
#include linux/ssb/ssb_regs.h
#include linux/pci.h
#include linux/delay.h
+#include linux/firmware.h
#include ssb_private.h
@@ -613,6 +614,53 @@ static int sprom_extract(struct ssb_bus
return 0;
}
+static void ssb_vsprom_load_failed(void)
+{
+ printk(KERN_ERR ssb: The BCM43XX device does not have an
+ SPROM built in, and the virtual SPROM file is not
+ available.\n);
+ printk(KERN_ERR ssb: Please go to
+ http://wireless.kernel.org/en/users/Drivers/b43
+ and download the utility to create the file.\n);
+}
+
+static void ssb_get_vsprom(const struct firmware *fw, void *context)
+{
+ /* Second part of asynchronous firmware load */
+ int i;
+ u16 *buf;
+ size_t size = SSB_SPROMSIZE_WORDS_R4;
+ struct ssb_bus *bus = context;
+
+ if (!fw) {
+ ssb_vsprom_load_failed();
+ return;
+ }
+ buf = kcalloc(size, sizeof(u16), GFP_KERNEL);
+ if (!buf) {
+ printk(KERN_ERR ssb: no memory for virtual sprom\n);
+ goto out;
+ }
+ if (fw-size != size * 2) {
+ printk(KERN_ERR ssb: The virtual SPROM file has the wrong
+ size\n);
+ goto out_free;
+ }
+ for (i = 0; i size; i++)
+ buf[i] = fw-data[2 * i + 1] 8 | fw-data[2 * i];
+ if(sprom_check_crc(buf, size)) {
+ printk(KERN_ERR ssb: Invalid CRC for virtual SPROM\n);
+ goto out_free;
+ }
+ sprom_extract(bus, bus-sprom, buf, size);
+ printk(KERN_DEBUG ssb: revision %d\n, bus-sprom.revision);
+
+out_free:
+ kfree(buf);
+out:
+ release_firmware(fw);
+}
+
static int ssb_pci_sprom_get(struct ssb_bus *bus,
struct ssb_sprom *sprom)
{
@@ -620,8 +668,17 @@ static int ssb_pci_sprom_get(struct ssb_
int err = -ENOMEM;
u16 *buf;
- if (!ssb_is_sprom_available(bus))
- return -ENODEV;
+ if (!ssb_is_sprom_available(bus)) {
+ /* This device has no SPROM. Try for a virtual version */
+ err = request_firmware_nowait(THIS_MODULE,
+ FW_ACTION_HOTPLUG, ssb/vsprom_image,
+ bus-host_pci-dev, GFP_KERNEL, bus, ssb_get_vsprom);
+ if (err) {
+ ssb_vsprom_load_failed();
+ return err;
+ }
+ return 0;
+ }
buf = kcalloc(SSB_SPROMSIZE_WORDS_R123, sizeof(u16), GFP_KERNEL);
if (!buf)
Index: wireless-testing/drivers/net/wireless/b43/main.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/main.c
+++ wireless-testing/drivers/net/wireless/b43/main.c
@@ -4858,7 +4858,17 @@ static int b43_one_core_attach(struct ss
static void b43_sprom_fixup(struct ssb_bus *bus)
{
struct pci_dev *pdev;
+ int i;
+ /* The sprom contents may be loaded asynchronously. Check that the
+* revision is set before proceeding */
+ for (i = 0; i 1000; i++) {
+ if (bus-sprom.revision)
+ break;
+ msleep(1);
+ }
+ if (i == 1000)
+ printk(KERN_INFO b43: No sprom image loaded\n);
/* boardflags workarounds */
if (bus-boardinfo.vendor == SSB_BOARDVENDOR_DELL
bus-chip_id == 0x4301 bus-boardinfo.rev == 0x74)
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[RFC] b43-utilities: ssb-vsprom: Add program to create on-disk, virtual SPROM
Some of the new implementations of BCM43xx devices do not have a
physical SPROM on the device. The necessary data for such a device
could be embedded in the kernel; however, we have a need to supply
a unique and reproducible MAC address.
This patch implements a user-space utility that has an embedded
Rev. 8 SPROM taken from a BCM4315. A random number generator is used
to create a MAC address that should be unique. To make this address
reproducible, it is written to the firmware directory where the PCI
initialization portion of ssb can read it. This program checks for
an existing virtual SPROM, and will operwrite it only when the appropriate
switch is used when starting the program.
Signed-off-by: Larry Finger larry.fin...@lwfinger.net
---
Index: sprom/vsprom/vsprom.c
===
--- /dev/null
+++ sprom/vsprom/vsprom.c
@@ -0,0 +1,344 @@
+/*
+ * virtual SPROM image writer for broadcom 43xx wireless devices
+ *
+ * This program creates an on-disk image of an SPROM for those BCM43xx
+ * devices that do not have a built-in SPROM. The image is created from
+ * one obtained from a BCM4315 with a random MAC address.
+ *
+ * Copyright (c) 2010 Larry Finger larry.fin...@lwfinger.net
+ *
+ * Some routines copied from b43-fwcutter, which is
+ *
+ * Copyright (c) 2005 Martin Langer martin-lan...@gmx.de,
+ * 2005-2007 Michael Buesch m...@bu3sch.de
+ * 2005 Alex Beregszaszi
+ * 2007 Johannes Berg johan...@sipsolutions.net
+ *
+ * Other routines from ssb_sprom, which is
+ *
+ * Copyright (c) 2006-2008 Michael Buesch m...@bu3sch.de
+ * Copyright (c) 2008 Larry Finger larry.fin...@lwfinger.net
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials provided
+ *with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL THE CONTRIBUTORS BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
+ * GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
+ * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
+ * OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include stdio.h
+#include stdlib.h
+#include string.h
+#include time.h
+#include stdint.h
+#include errno.h
+#include errno.h
+#include sys/stat.h
+#include sys/types.h
+
+#include vsprom.h
+
+static struct cmdline_args cmdargs;
+
+uint8_t crc8(uint8_t crc, uint8_t data)
+{
+ static const uint8_t t[] = {
+ 0x00, 0xF7, 0xB9, 0x4E, 0x25, 0xD2, 0x9C, 0x6B,
+ 0x4A, 0xBD, 0xF3, 0x04, 0x6F, 0x98, 0xD6, 0x21,
+ 0x94, 0x63, 0x2D, 0xDA, 0xB1, 0x46, 0x08, 0xFF,
+ 0xDE, 0x29, 0x67, 0x90, 0xFB, 0x0C, 0x42, 0xB5,
+ 0x7F, 0x88, 0xC6, 0x31, 0x5A, 0xAD, 0xE3, 0x14,
+ 0x35, 0xC2, 0x8C, 0x7B, 0x10, 0xE7, 0xA9, 0x5E,
+ 0xEB, 0x1C, 0x52, 0xA5, 0xCE, 0x39, 0x77, 0x80,
+ 0xA1, 0x56, 0x18, 0xEF, 0x84, 0x73, 0x3D, 0xCA,
+ 0xFE, 0x09, 0x47, 0xB0, 0xDB, 0x2C, 0x62, 0x95,
+ 0xB4, 0x43, 0x0D, 0xFA, 0x91, 0x66, 0x28, 0xDF,
+ 0x6A, 0x9D, 0xD3, 0x24, 0x4F, 0xB8, 0xF6, 0x01,
+ 0x20, 0xD7, 0x99, 0x6E, 0x05, 0xF2, 0xBC, 0x4B,
+ 0x81, 0x76, 0x38, 0xCF, 0xA4, 0x53, 0x1D, 0xEA,
+ 0xCB, 0x3C, 0x72, 0x85, 0xEE, 0x19, 0x57, 0xA0,
+ 0x15, 0xE2, 0xAC, 0x5B, 0x30, 0xC7, 0x89, 0x7E,
+ 0x5F, 0xA8, 0xE6, 0x11, 0x7A, 0x8D, 0xC3, 0x34,
+ 0xAB, 0x5C, 0x12, 0xE5, 0x8E, 0x79, 0x37, 0xC0,
+ 0xE1, 0x16, 0x58, 0xAF, 0xC4, 0x33, 0x7D, 0x8A,
+ 0x3F, 0xC8, 0x86, 0x71, 0x1A, 0xED, 0xA3, 0x54,
+ 0x75, 0x82, 0xCC, 0x3B, 0x50, 0xA7, 0xE9, 0x1E,
+ 0xD4, 0x23, 0x6D, 0x9A, 0xF1, 0x06, 0x48, 0xBF,
+ 0x9E, 0x69, 0x27, 0xD0, 0xBB, 0x4C, 0x02, 0xF5,
+ 0x40, 0xB7, 0xF9, 0x0E, 0x65, 0x92, 0xDC, 0x2B,
+ 0x0A, 0xFD, 0xB3, 0x44, 0x2F, 0xD8, 0x96, 0x61,
+ 0x55, 0xA2, 0xEC, 0x1B, 0x70, 0x87, 0xC9, 0x3E,
+ 0x1F, 0xE8, 0xA6, 0x51, 0x3A
[PATCH] ssb: Implement virtual SPROM on disk
Some recent BCM43XX devices lack an on-board SPROM. The pertinent data
from the SPROM could be included in the kernel; however, this presents
a problem in the generation of a unique, reproducible MAC address. The
solution has been to create a utility that generates a virtual SPROM
image with a random MAC address. This image is stored in the firmware
area, and loaded using the asyncronous firmware load facility.
Signed-off-by: Larry Finger larry.fin...@lwfinger.net
---
Michael,
I think this patch eliminates the need for the fallback sprom code; however,
I have not touched that facility yet.
Larry
---
Index: wireless-testing/drivers/ssb/pci.c
===
--- wireless-testing.orig/drivers/ssb/pci.c
+++ wireless-testing/drivers/ssb/pci.c
@@ -19,6 +19,7 @@
#include linux/ssb/ssb_regs.h
#include linux/pci.h
#include linux/delay.h
+#include linux/firmware.h
#include ssb_private.h
@@ -613,6 +614,39 @@ static int sprom_extract(struct ssb_bus
return 0;
}
+static int ssb_get_vsprom(struct device *dev, u16 *buf, size_t size)
+{
+ /* Use the firmware load facility to get the disk image of an SPROM */
+ const struct firmware *blob;
+ int err;
+ int i;
+
+ err = request_firmware(blob, ssb/vsprom_image, dev);
+ if (err) {
+ printk(KERN_ERR ssb: The BCM43XX device does not have an
+ SPROM built in, and the virtual SPROM file is not
+ available.\n);
+ printk(KERN_ERR ssb: Please go to
+ http://wireless.kernel.org/en/users/Drivers/b43
+ and download the utility to create the file.\n);
+ return err;
+ }
+ if (blob-size != size * 2) {
+ printk(KERN_ERR ssb: The virtual SPROM file has the wrong
+ size\n);
+ return -ENOENT;
+ }
+ for (i = 0; i size; i++)
+ buf[i] = blob-data[2 * i + 1] 8 | blob-data[2 * i];
+ err = sprom_check_crc(buf, size);
+ if (err) {
+ printk(KERN_ERR ssb: Invalid CRC for virtual SPROM\n);
+ return err;
+ }
+
+ return 0;
+}
+
static int ssb_pci_sprom_get(struct ssb_bus *bus,
struct ssb_sprom *sprom)
{
@@ -620,8 +654,18 @@ static int ssb_pci_sprom_get(struct ssb_
int err = -ENOMEM;
u16 *buf;
- if (!ssb_is_sprom_available(bus))
- return -ENODEV;
+ if (!ssb_is_sprom_available(bus)) {
+ buf = kcalloc(SSB_SPROMSIZE_WORDS_R4, sizeof(u16),
+ GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+ bus-sprom_size = SSB_SPROMSIZE_WORDS_R4;
+ if (ssb_get_vsprom(bus-host_pci-dev, buf, bus-sprom_size)) {
+ err = -ENODEV;
+ goto out_free;
+ }
+ goto extract;
+ }
buf = kcalloc(SSB_SPROMSIZE_WORDS_R123, sizeof(u16), GFP_KERNEL);
if (!buf)
@@ -653,6 +697,7 @@ static int ssb_pci_sprom_get(struct ssb_
SPROM CRC (corrupt SPROM)\n);
}
}
+extract:
err = sprom_extract(bus, sprom, buf, bus-sprom_size);
out_free:
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
RFC: A workaround for BCM43XX devices with no on-board SPROM
Michael, I'm switching this discussion from the kernel Bugzilla to the lists. As you know, but I'm restating for anyone that has not read our previous discussions, the b43 driver needs to be changed to handle some of the newer devices do not have an on-board SPROM. It would be trivial to incorporate the data except for the need to have a unique, reproducible MAC. I am proposing to solve this problem using the following steps: (1) Modify b43-fwcutter to take data from an existing SPROM, modify the MAC by replacing the last 3 octets with random numbers, and write the resulting file to /lib/firmware/b43. Fortunately, all affected devices seem to have Revision 8 SPROMS, which makes preparation easier. All such devices will need to use the calibration parameters of the device from which the prototype SPROM was copied, but that should not be a serious problem. I have chosen to implement this in fwcutter rather than ssb_sprom because the ordinary user will not have access to ssb_sprom; however, they do have a version of fwcutter supplied by the distro. Unconditionally writing an additional small file to the firmware directory when extracting firmware is small overhead and it will be transparent to the user of whatever mechanism the distro uses. The routines needed to calculate the CRC, etc. have been copied into fwcutter from ssb_sprom. A version of this code is already running. (2) Use the steps in http://bcm-v4.sipsolutions.net/802.11/IsSpromAvailable to determine if the device has an SPROM. If not, then use the kernel's firmware loading mechanism to get the contents of the file prepared in step 1. This file has an 8-bit CRC, thus the validity of the file can be tested even though the test is not very robust. It it reasonable to keep the vendor portion of the MAC and only replace the serial number, or would it be better to randomize all 6 octants? Is there a better way to load a file into the kernel? Thanks, Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: RFC: A workaround for BCM43XX devices with no on-board SPROM
On 03/18/2010 03:53 PM, Johannes Berg wrote: On Thu, 2010-03-18 at 12:46 -0500, Larry Finger wrote: Michael, I'm switching this discussion from the kernel Bugzilla to the lists. As you know, but I'm restating for anyone that has not read our previous discussions, the b43 driver needs to be changed to handle some of the newer devices do not have an on-board SPROM. It would be trivial to incorporate the data except for the need to have a unique, reproducible MAC. Where does the data usually come from in these devices? It comes from the SPROM, which is missing in the devices in question. Broadcrap wanted to save a few pennies. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: RFC: A workaround for BCM43XX devices with no on-board SPROM
On 03/18/2010 02:31 PM, Michael Buesch wrote: On Thursday 18 March 2010 18:46:35 Larry Finger wrote: (1) Modify b43-fwcutter to take data from an existing SPROM, Why not extend the ssb-sprom tool? I don't think this has anything to do with firmware, except that we (ab)use the firmware loading mechanism of the kernel for loading the blob into the kernel. It has nothing to do with firmware, but the existing fwcutter has all the parts to generate files in the firmware directory, which is a good place to put this virtual SPROM. I have chosen to implement this in fwcutter rather than ssb_sprom because the ordinary user will not have access to ssb_sprom; Huh? ssb-sprom is GPL software. I have no problem relicensing it under BSD or even something more liberal. I don't see a problem for ordinary users here. It has nothing to do with the license. My distro, openSUSE, packages fwcutter along with a script that uses wget to download the Broadcom drivers and extract firmware for both b43 and b43legacy. The average user only has to execute that script. Of course, the package could include both fwcutter and ssb_sprom programs, but that would make a bigger change to the openSUSE package than just a patch to fwcutter. I suspect that other distros use similar packages. Well, but that version won't do anything on the SPROM, too. Yes, but if fwcutter were modified, it could write the virtual SPROM file. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: RFC: A workaround for BCM43XX devices with no on-board SPROM
On 03/18/2010 04:20 PM, Johannes Berg wrote: On Thu, 2010-03-18 at 16:10 -0500, Larry Finger wrote: On 03/18/2010 03:53 PM, Johannes Berg wrote: On Thu, 2010-03-18 at 12:46 -0500, Larry Finger wrote: Michael, I'm switching this discussion from the kernel Bugzilla to the lists. As you know, but I'm restating for anyone that has not read our previous discussions, the b43 driver needs to be changed to handle some of the newer devices do not have an on-board SPROM. It would be trivial to incorporate the data except for the need to have a unique, reproducible MAC. Where does the data usually come from in these devices? It comes from the SPROM, which is missing in the devices in question. Broadcrap wanted to save a few pennies. Right, but they have to support getting the data somehow on for example windows even if there's no sprom. Do we know where it comes from then? In the Linux driver and likely in the Windows driver, the SPROM data is read from the SPROM and encoded into a set of tagged strings. After that, the actual SPROM is ignored. I have not completed the RE on this area, but it looks as if they have a set of canned data that is copied into the area. How they handle a MAC is not yet understood. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM4312 (14e4:4315) in Lenovo Ideapad S12 cannot scan with 2.6.33
On 03/15/2010 06:20 PM, Marc Haber wrote: Hi, On Thu, Mar 04, 2010 at 06:54:23PM +0100, Marc Haber wrote: when the broadcom-sta driver didn't compile with 2.6.33 I decided to give b43 a new try. I have a Lenovo Ideapad S12, which has a BCM4312 with LP Phy (14e4:4315). I am using Debian unstable. When I load the module, a new interface wlan0 appears, but iwlist scan says Interface doesn't support scanning. Looks like the device isn't properly initialized. The issue was that CRDA is not yet in Debian, and thus the kernel needs to have CONFIG_WIRELESS_OLD_REGULATORY=y. With this setting, the interface can scan. There should be a clearer error message about this. I feel that Debian should get their act together. The old regulatory method was left in the kernel for several cycles so that the distros could adapt. Only Debian failed to do so. However, the interface doesn't work. Most prominent error is: Mar 15 18:27:12 feather kernel: [ 505.012549] b43-phy0 ERROR: PHY transmission error (this is with he chip forced to PIO). Are there lots of PHY Transmission errors, os just a few? We have never understood why these errors occur in the firmware. What version are you using? Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Even worse problems with BCM4312 on Netbooks
A problem with BCM4312 on Netbooks that is worse than the DMA errors has shown up in Fedora F12 systems on Acer One D250 Netbooks. See https://bugzilla.redhat.com/show_bug.cgi?id=533746. In this case, the system seems to freeze when ssb is loaded. So far, no one has managed to get any output from the logging console, but it does not seem to be a kernel panic - flashing CAP and NUM lock leds do not seem to happen. One other thing - this freeze occurs even if the firmware is not available. The kernel in question is 2.6.33, but there is also a report of problems with a 2.6.30 kernel. I'm not sure if that one has the LP PHY code backported, or not. John might know. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] ssb: Export ssb_chipco_gpio_control - needed by N PHY code
The latest changes in the N PHY core require the symbol
ssb_chipco_gpio_control to be exported.
Signed-off-by: Larry Finger larry.fin...@lwfinger.net
---
John,
This fixes a build error in wireless-testing - git describe lists
it as v2.6.34-rc1-47014-g33b6b57.
Larry
---
Index: wireless-testing/drivers/ssb/driver_chipcommon.c
===
--- wireless-testing.orig/drivers/ssb/driver_chipcommon.c
+++ wireless-testing/drivers/ssb/driver_chipcommon.c
@@ -370,6 +370,7 @@ u32 ssb_chipco_gpio_control(struct ssb_c
{
return chipco_write32_masked(cc, SSB_CHIPCO_GPIOCTL, mask, value);
}
+EXPORT_SYMBOL(ssb_chipco_gpio_control);
u32 ssb_chipco_gpio_intmask(struct ssb_chipcommon *cc, u32 mask, u32 value)
{
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On 03/03/2010 06:47 PM, Gábor Stefanik wrote: On Thu, Mar 4, 2010 at 1:30 AM, Larry Finger larry.fin...@lwfinger.net wrote: On 03/02/2010 03:57 PM, Michael Buesch wrote: A bug in the PCI-E core code is able to show such behavior, because all memory transfers (MMIO and DMA) from the PCI device to the wireless core are translated by the PCI-E core. I think the whole PCI-E core code has to be audited (also the specs, probably). I have nearly finished the update on the code section of the specs page at http://bcm-v4.sipsolutions.net/PCI-E. The part that is not done involves the sections that read an address from the SPROM and perform operations on that address. I found that the chip common registers Do you mean the ChipCommon registers or the Backplane common registers? Definitely, it is the chipcommon registers. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On 03/02/2010 03:57 PM, Michael Buesch wrote: A bug in the PCI-E core code is able to show such behavior, because all memory transfers (MMIO and DMA) from the PCI device to the wireless core are translated by the PCI-E core. I think the whole PCI-E core code has to be audited (also the specs, probably). I have nearly finished the update on the code section of the specs page at http://bcm-v4.sipsolutions.net/PCI-E. The part that is not done involves the sections that read an address from the SPROM and perform operations on that address. I found that the chip common registers are mapped at 12K for newer cores on PCIe. This explains the 0x3XXX addresses. Similarly, the PCIe registers are mapped at 8K - the 0x2XXX addresses. The SPROM is shadowed at 4K or 0x1XXX. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM4312 (14e4:4315) in Lenovo Ideapad S12 cannot scan with 2.6.33
On 03/04/2010 12:49 PM, William Bourque wrote: Hello Marc Haber wrote: Hi, when the broadcom-sta driver didn't compile with 2.6.33 I decided to give b43 a new try. I have a Lenovo Ideapad S12, which has a BCM4312 with LP Phy (14e4:4315). I am using Debian unstable. When I load the module, a new interface wlan0 appears, but iwlist scan says Interface doesn't support scanning. Looks like the device isn't properly initialized. Silly question, but did you try to up (ifconfig wlan0 up) the interface before scanning? My b43 won't allow scanning either unless it is upped. i don't know if this behavior is intended (poke to the list) but it's not quite a problem. If you control the device with NetworkManager, it will bring it up. If you are controlling it manually, then either an explicit ifup is required, or it is set implicitly in the control file. That is distro dependent. For openSUSE, that file is /etc/sysconfig/network/ifcfg-wlan0 where there is a line that says STARTMODE='XX', where XX is auto, ifplugd, manual, or off. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM4312 (14e4:4315) in Lenovo Ideapad S12 cannot scan with 2.6.33
On 03/04/2010 03:46 PM, Marc Haber wrote: On Thu, Mar 04, 2010 at 01:16:26PM -0600, Larry Finger wrote: CRDA is the user-space implementation of the regulatory database. What will the b43 driver do without a CRDA user-space daemon? It's not yet in Debian (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=536502). I'm not an expert on the regulatory stuff, but if you do not have a list of allowed frequencies listed as I posted, then I think that none are allowed. There was compatibility code kept in the kernel for several cycles so that even the slowest distros could get prepared. Perhaps the devs underestimated Debian. Your best approach is to go to http://linuxwireless.org/en/developers/Regulatory/CRDA, get and build a copy. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM4312 (14e4:4315) in Lenovo Ideapad S12 cannot scan with 2.6.33
On 03/04/2010 04:53 PM, Celejar wrote: b43 works perfectly fine with my 4318 on my Debian Sid system, without CRDA installed. What kernel version is in Sid? Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM4312 (14e4:4315) in Lenovo Ideapad S12 cannot scan with 2.6.33
On 03/04/2010 05:33 PM, Celejar wrote: Currently some version of 2.6.32. I should have noted that I actually usually run self-built vanilla ones (from upstream mainline), but I'm pretty sure that b43 works even when I use the Debian packaged ones from the repos. It may fail with 2.6.33. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On 02/27/2010 09:16 AM, Michael Buesch wrote: On Friday 26 February 2010 23:03:28 Gábor Stefanik wrote: BTW there is an interesting difference in the early init between wl and b43: b43 sets bit 0x200 in core register 0x600, while wl sets 0x8000 in register 0x280a - an undocumented register. Well, it is not only undocumented, it's also far beyond the address space. SSB core address space goes from 0-0xFFF. And (more important!) the PCI address space for MMIO is only 8k wide (I think there also are 4k devices). Are you really sure your dumping is correct? I suspect a bug in your mmio dumping tools. I'd say the undocumented register is a completely unrelated hardware access in a completely different device that just happens to be mapped right after ssb. There are definite instances where the vendor driver writes beyond 0xFFF. I'm pretty sure that some models shadow EEPROM above 0x1000. I don't know about 0x280A. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On 02/27/2010 09:20 AM, Michael Buesch wrote: On Saturday 27 February 2010 02:41:48 Gábor Stefanik wrote: Someone should test the following: -Open drivers/ssb/driver_chipcommon_pmu.c -In ssb_pmu_init, replace 0x4325 with 0x4312. Uh, wait a second. Do _all_ cards that show the behavior have a PMU on the SSB? If so, you should really make sure the PMU setup is correct. If the PMU cuts power to the device at inappropriate times, it sure does result in DMA errors (and silent MMIO errors). Yes, all of the LP PHY 14e4:4315 devices have a PMU. Mine shows Found rev 1 PMU (capabilities 0x02A62F01). As I recall, at least one of the problem devices shows the same capabilities. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On 02/27/2010 10:08 AM, Michael Buesch wrote: On Saturday 27 February 2010 17:05:41 Larry Finger wrote: On 02/27/2010 09:20 AM, Michael Buesch wrote: On Saturday 27 February 2010 02:41:48 Gábor Stefanik wrote: Someone should test the following: -Open drivers/ssb/driver_chipcommon_pmu.c -In ssb_pmu_init, replace 0x4325 with 0x4312. Uh, wait a second. Do _all_ cards that show the behavior have a PMU on the SSB? If so, you should really make sure the PMU setup is correct. If the PMU cuts power to the device at inappropriate times, it sure does result in DMA errors (and silent MMIO errors). Yes, all of the LP PHY 14e4:4315 devices have a PMU. Mine shows Found rev 1 PMU (capabilities 0x02A62F01). As I recall, at least one of the problem devices shows the same capabilities. *HINT HINT HINT* ;) Please make sure the PMU code really is correct. Where are the specs that were used to write the original code? I cannot find them in either the V3 or V4 pages. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On 02/27/2010 01:45 PM, Gábor Stefanik wrote: So, a quick status update, from what I've found yesterday: 1. We get the PMU setup wrong. Bit 0x200 is being set, despite the PMU being rev1. Also, PMU setup is done too early - at least wl reads the SPROM before setting up the PMU. A write of 0xcbb to offset 0x618 is also missing - I seem to remember that this change has been tried already, to no avail; but it may be a prerequisite of the real fix. 2. Just before the SPROM readout, we are missing a Set 0x8000 in MMIO offset 0x280a. This looks curiously like PCI-E Miscellaneous Configuration, from http://bcm-v4.sipsolutions.net/PCI-E - and indeed, the value read out from 0x280a is identical to offset 0xa in my SPROM. So, the right thing to do here is probably Switch to the PCIE core, set 0x8000 in MIMO offset 0x80a (or maybe 0x1000a?), switch back to ChipCommon. I don't know what core is active during this write, as mmiotrace doesn't catch pci_read/write_config_dword calls. Larry, do you know a way to monitor PCI config space access in a way that can be matched (e.g. using timestamps) to the MMIO trace? The printk's I sent yesterday can have timing info, but the timestamps would not be exactly coordinated - printk values seem to be generated when logged, not when requested. 3. Right after the SPROM is read, wl writes zeros to MMIO offsets 0x58 and 0x5c (32-bit), then does the PMU setup. These are not valid registers for ChipCommon and PCIE, but for 802.11, they fall directly into the DMA area! So, if these writes happened with the 802.11 core active, they are probably significant. That sounds promising. I think I found the section, which will have the following specs: 1. If the Chip Common revision = 20 a. Save the current core index a. Set core to chip common a. Write 0 to GPIO Pullup (register 0x58) a. Write 0 to GPIO Pulldown (register 0x5C) a. Restore the original core 1. If PMU Control Enabled a. Init the PMU ... A quick look ar the code suggests this should go into ssb_chipcommon_init() just after the return for not having a chip common. In addition, chip common will already be selected, thus that part can be skipped. I second Larry's question: where are the specs for the PMU init code? From what Michael replied, they do not exist in a public place other that the reference code for embedded systems. I have started them - there is now a PMU Init page and I'll fill them in as I can. If you have a specific routine, let me know. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On 02/26/2010 09:27 AM, Gábor Stefanik wrote: On Fri, Feb 26, 2010 at 4:13 PM, rekl...@gmail.com wrote: On Feb 26, 2010 9:08am, Gábor Stefanik netrolller...@gmail.com wrote: That's odd... the error only occurs when you stop the mmiotrace?! Yes, the error only occurs when I stop the mmiotrace with b43 loaded, or if I load b43 outside of an mmiotrace. BTW no need to load wl and b43 on the same kernel - the effect of loading wl survives a reboot or a kexec. But then I cannot get you the mmiotrace as you requested. If all you're after is the mmiotrace of b43 from cold and b43 from warm with wl magic, I can do that now. I don't know how helpful this will be given that b43 appears to work so long as an mmiotrace is being performed. The differences will still be there in the dump, even if something related to mmiotrace seemingly works around the bug. However, the most helpful logs would be the ones produced by wl itself, on a cold boot. This thread is most interesting. Thanks for keeping it on the list, even though the OP doesn't seem to know about Reply All. The fact that the 4315 doesn't get the DMA errors until MMIO tracing is turned off suggests some kind of subtle timing difference. I'll look at the Broadcom code to see if there are some delay statements in the interrupt handling, or if their processing does things in a different order. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: Make driver fall back gracefully to PIO mode after fatal DMA errors
Subject: Make b43 driver fall back gracefully to PIO mode after fatal DMA errors
From: Linus Torvalds torva...@linux-foundation.org
Date: Fri, 26 Feb 2010 10:34:27 -0800 (PST)
This makes the b43 driver just automatically fall back to PIO mode when
DMA doesn't work.
The driver already told the user to do it, so rather than have the user
reload the module with a new flag, just make the driver do it
automatically. We keep the message as an indication that something is
wrong, but now just automatically fall back to the hopefully working PIO
case.
Signed-off-by: Linus Torvalds torva...@linux-foundation.org
---
John,
This version will work with wireless-testing.
Larry
---
Index: wireless-testing/drivers/net/wireless/b43/Kconfig
===
--- wireless-testing.orig/drivers/net/wireless/b43/Kconfig
+++ wireless-testing/drivers/net/wireless/b43/Kconfig
@@ -3,7 +3,6 @@ config B43
depends on SSB_POSSIBLE MAC80211 HAS_DMA
select SSB
select FW_LOADER
- select SSB_BLOCKIO
---help---
b43 is a driver for the Broadcom 43xx series wireless devices.
@@ -79,6 +78,14 @@ config B43_SDIO
If unsure, say N.
+#Data transfers to the device via PIO. We want it as a fallback even
+# if we can do DMA.
+config B43_PIO
+ bool
+ depends on B43
+ select SSB_BLOCKIO
+ default y
+
config B43_NPHY
bool Pre IEEE 802.11n support (BROKEN)
depends on B43 EXPERIMENTAL BROKEN
@@ -130,4 +137,12 @@ config B43_DEBUG
for production use.
Only say Y, if you are debugging a problem in the b43 driver
sourcecode.
-
+config B43_FORCE_PIO
+ bool Force usage of PIO instead of DMA
+ depends on B43 B43_DEBUG
+ ---help---
+ This will disable DMA and always enable PIO instead.
+
+ Say N!
+ This is only for debugging the PIO engine code. You do
+ _NOT_ want to enable this.
Index: wireless-testing/drivers/net/wireless/b43/main.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/main.c
+++ wireless-testing/drivers/net/wireless/b43/main.c
@@ -107,9 +107,9 @@ int b43_modparam_verbose = B43_VERBOSITY
module_param_named(verbose, b43_modparam_verbose, int, 0644);
MODULE_PARM_DESC(verbose, Log message verbosity: 0=error, 1=warn,
2=info(default), 3=debug);
-static int modparam_pio;
-module_param_named(pio, modparam_pio, int, 0444);
-MODULE_PARM_DESC(pio, enable(1) / disable(0) PIO mode);
+int b43_modparam_pio = B43_PIO_DEFAULT;
+module_param_named(pio, b43_modparam_pio, int, 0644);
+MODULE_PARM_DESC(pio, Use PIO accesses by default: 0=DMA, 1=PIO);
static const struct ssb_device_id b43_ssb_tbl[] = {
SSB_DEVICE(SSB_VENDOR_BROADCOM, SSB_DEV_80211, 5),
@@ -1804,8 +1804,9 @@ static void b43_do_interrupt_thread(stru
dma_reason[4], dma_reason[5]);
b43err(dev-wl, This device does not support DMA
on your system. Please use PIO instead.\n);
- b43err(dev-wl, Unload the b43 module and reload
- with 'pio=1'\n);
+ /* Fall back to PIO transfers if we get fatal DMA
errors! */
+ dev-use_pio = 1;
+ b43_controller_restart(dev, DMA error);
return;
}
if (merged_dma_reason B43_DMAIRQ_NONFATALMASK) {
@@ -4357,7 +4358,7 @@ static int b43_wireless_core_init(struct
if ((dev-dev-bus-bustype == SSB_BUSTYPE_PCMCIA) ||
(dev-dev-bus-bustype == SSB_BUSTYPE_SDIO) ||
- modparam_pio) {
+ dev-use_pio) {
dev-__using_pio_transfers = 1;
err = b43_pio_init(dev);
} else {
@@ -4824,6 +4825,7 @@ static int b43_one_core_attach(struct ss
if (!wldev)
goto out;
+ wldev-use_pio = b43_modparam_pio;
wldev-dev = dev;
wldev-wl = wl;
b43_set_status(wldev, B43_STAT_UNINIT);
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On 02/26/2010 07:41 PM, Gábor Stefanik wrote:
Someone should test the following:
-Open drivers/ssb/driver_chipcommon_pmu.c
-In ssb_pmu_init, replace 0x4325 with 0x4312. (This is not the correct
way to fix this, but should be enough for a test. The correct fix
would be special-casing for both 4312 and 4325, at least according to
the MMIO trace produced using wl. Or maybe the if-branch is the
wrong-way around - only Larry can tell.)
The latest Broadcom driver has changed this section. The new specs should be:
1. If the pmu revision is 1
a. Clear bit 0x200 in the PMU control register
1. Otherwise
a. Set bit 0x200 in the PMU control register
BTW does anyone know of a way to trace pci_read/write_config_dword
calls? Mmiotrace doesn't capture these.
The attached patch will log PCI config reads/writes to the system logs.
Larry
Index: wireless-testing/drivers/pci/access.c
===
--- wireless-testing.orig/drivers/pci/access.c
+++ wireless-testing/drivers/pci/access.c
@@ -24,6 +24,8 @@ static DEFINE_SPINLOCK(pci_lock);
#define PCI_word_BAD (pos 1)
#define PCI_dword_BAD (pos 3)
+static void pci_bus_log_buf(char *buf);
+
#define PCI_OP_READ(size,type,len) \
int pci_bus_read_config_##size \
(struct pci_bus *bus, unsigned int devfn, int pos, type *value) \
@@ -31,11 +33,14 @@ int pci_bus_read_config_##size \
int res;\
unsigned long flags;\
u32 data = 0; \
+ char buf[80]; \
if (PCI_##size##_BAD) return PCIBIOS_BAD_REGISTER_NUMBER; \
spin_lock_irqsave(pci_lock, flags);\
res = bus-ops-read(bus, devfn, pos, len, data); \
*value = (type)data;\
spin_unlock_irqrestore(pci_lock, flags); \
+ sprintf(buf, Read 0x%X from pos 0x%X\n, data, pos); \
+ pci_bus_log_buf(buf); \
return res; \
}
@@ -45,10 +50,13 @@ int pci_bus_write_config_##size \
{ \
int res;\
unsigned long flags;\
+ char buf[80]; \
if (PCI_##size##_BAD) return PCIBIOS_BAD_REGISTER_NUMBER; \
spin_lock_irqsave(pci_lock, flags);\
res = bus-ops-write(bus, devfn, pos, len, value); \
spin_unlock_irqrestore(pci_lock, flags); \
+ sprintf(buf, Wrote 0x%X to pos 0x%X\n, value, pos); \
+ pci_bus_log_buf(buf); \
return res; \
}
@@ -427,3 +435,8 @@ void pci_unblock_user_cfg_access(struct
spin_unlock_irqrestore(pci_lock, flags);
}
EXPORT_SYMBOL_GPL(pci_unblock_user_cfg_access);
+
+static void pci_bus_log_buf(char *buf)
+{
+ printk(KERN_DEBUG %s, buf);
+}
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Turn broadcom 4311 into master mode
On 02/24/2010 06:22 AM, Peter Stuge wrote: Larry Finger wrote: will work with b43 as long as hostapd is 0.6.0 or later. Would you suggest using b43 when creating an access point today? I've looked into ath9k to get agn, but it is very buggy for me and Atheros remains unresponsive. 5GHz is very desirable, but reliability much more so... The current b43 is very stable. Performance will depend on which model you have. BCM4311's run at speeds close to 802.11g maximum. BCM4306's are not that good. BCM4318 units are in between. I would not use my $500 laptop to do what a $40 AP/router does just as well or better. I wrote the article to show that it could be done, not that I planned to set up an AP. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 and WPA-PSK
On 02/22/2010 02:03 PM, Yan Seiner wrote: I'm trying to get the b43 driver working on a Linksys WRTSL54GS router. It's running Openwrt with the 2.6.32 kernel. The good news is that the driver picks up a lot of APs with ease, far more than the binary blob. The bad news is that I can't get encryption working. The output from iwlist scan is here: https://forum.openwrt.org/viewtopic.php?pid=103469#p103469 I can't configure it to use WPA-PSK or WPA-PSK2; it simply doesn't see encryption. I don't have any WEP APs around so I can't test around those. It connects to open APs quite well. (I haven't tested it much as the open AP is one of my neighbors, and I really don't want to steal his broadband.) I was hoping someone else would answer your mail, but as no one has come forward, I will try. I am not an expert on openWRT. I am using the version of Kamikaze with a 2.4 kernel on a WRT54GL, but the firmware is out of the box. What I do know is that the BCM4318 does work with WPA/WPA2, although my device is Cardbus format in an old laptop. Using Broadcom's proprietary firmware, as you seem to be doing, the encryption/decryption is done in the hardware. I'm a little confused on your usage of the device. As an AP, I see no need to scan. Are you using it as a station, or as a wireless bridge? In these modes, would not the bridging code to eth0 get in the way? Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Turn broadcom 4311 into master mode
On 02/23/2010 08:43 PM, D1e6o! wrote: Hello, I'm getting problems to turn my laptop in master mode. When I try to change the mode I get an error: sudo iwconfig wlan0 mode master Error for wireless request Set Mode (8B06) : SET failed on device wlan0 ; Invalid argument. I followed the guide to install the drivers and the problem persists (http://linuxwireless.org/en/users/Drivers/b43/devices), also tried to use the drivers installed from repositories of ubuntu karmic desktop, with and without networkmanager running The board is running fine, I have an broadcom 4311 rev 2 and running the driver b43 The kernel is from ubuntu, do I need any special compilation of it? lsmod | grep b43 b43 136552 0 ssb40944 1 b43 mac80211 209912 1 b43 cfg80211 109144 2 b43,mac80211 led_class 5256 1 b43 The driver creates two interfaces, with iwconfig: (other interfaces of my computer) ... wmaster0 no wireless extensions. wlan0 IEEE 802.11bg ESSID: Mode:Managed Frequency:2.412 GHz Access Point: Not-Associated Tx-Power=20 dBm Retry long limit:7 RTS thr:off Fragment thr:off Encryption key:off Power Management:off Link Quality:0 Signal level:0 Noise level:0 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 Why I get Invalid Argument? The argument Isn't recognized... That is not the correct way to set master or AP mode. One way is described in the first post in the openSYSE Wireless Forum at http://tinyurl.com/yzlp7nm. It contains the scripts needed to implement an AP using hostapd and DHCP. The firewall is left to you. This way will work with b43 as long as hostapd is 0.6.0 or later. Version 0.5.X will not work. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] ssb: Add PCI ID 0x4322 to PMU handling
On 02/21/2010 04:55 AM, Johannes Berg wrote: On Sun, 2010-02-21 at 11:53 +0100, Gábor Stefanik wrote: 2010/2/21 Rafał Miłecki zaj...@gmail.com: 2010/2/20 Larry Finger larry.fin...@lwfinger.net: Some of the N PHYs need a revision in the handling of the PMU. Signed-off-by: Larry Finger larry.fin...@lwfinger.net --- John, This will be needed for some of the N PHY devices - 2.6.34 amterial. Larry --- V2 - Fix typo in subject line of commit message. amterial you say? ;) Taht's not prat of the cimmot megasse, it is olny a ntoe to Jhon. Deons't mtater eevn if it is cmolpelety jmulbed up. Geez. The patch is already in the tree anyway, with the original typo. I may be getting old and decrepit, but it's OK if the boys just want to have fun with me. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH V2] ssb: Add PCI ID 0x4322 to PMU handling
Some of the N PHYs need a revision in the handling of the PMU.
Signed-off-by: Larry Finger larry.fin...@lwfinger.net
---
John,
This will be needed for some of the N PHY devices - 2.6.34 amterial.
Larry
---
V2 - Fix typo in subject line of commit message.
Index: wireless-testing/drivers/ssb/driver_chipcommon_pmu.c
===
--- wireless-testing.orig/drivers/ssb/driver_chipcommon_pmu.c
+++ wireless-testing/drivers/ssb/driver_chipcommon_pmu.c
@@ -332,6 +332,12 @@ static void ssb_pmu_pll_init(struct ssb_
case 0x5354:
ssb_pmu0_pllinit_r0(cc, crystalfreq);
break;
+ case 0x4322:
+ if (cc-pmu.rev == 2) {
+ chipco_write32(cc, SSB_CHIPCO_PLLCTL_ADDR, 0x000A);
+ chipco_write32(cc, SSB_CHIPCO_PLLCTL_DATA, 0x380005C0);
+ }
+ break;
default:
ssb_printk(KERN_ERR PFX
ERROR: PLL init unknown for device %04X\n,
@@ -417,6 +423,7 @@ static void ssb_pmu_resources_init(struc
switch (bus-chip_id) {
case 0x4312:
+ case 0x4322:
/* We keep the default settings:
* min_msk = 0xCBB
* max_msk = 0x7
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] ssb: Add PCI ID 0x4322 to PHU handling
Some of the N PHYs need a revision in the handling of the PMU.
Signed-off-by: Larry Finger larry.fin...@lwfinger.net
---
John,
This will be needed for some of the N PHY devices - 2.6.34 amterial.
Larry
---
Index: wireless-testing/drivers/ssb/driver_chipcommon_pmu.c
===
--- wireless-testing.orig/drivers/ssb/driver_chipcommon_pmu.c
+++ wireless-testing/drivers/ssb/driver_chipcommon_pmu.c
@@ -332,6 +332,12 @@ static void ssb_pmu_pll_init(struct ssb_
case 0x5354:
ssb_pmu0_pllinit_r0(cc, crystalfreq);
break;
+ case 0x4322:
+ if (cc-pmu.rev == 2) {
+ chipco_write32(cc, SSB_CHIPCO_PLLCTL_ADDR, 0x000A);
+ chipco_write32(cc, SSB_CHIPCO_PLLCTL_DATA, 0x380005C0);
+ }
+ break;
default:
ssb_printk(KERN_ERR PFX
ERROR: PLL init unknown for device %04X\n,
@@ -417,6 +423,7 @@ static void ssb_pmu_resources_init(struc
switch (bus-chip_id) {
case 0x4312:
+ case 0x4322:
/* We keep the default settings:
* min_msk = 0xCBB
* max_msk = 0x7
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 11/11] b43: N-PHY: switch to chanspec ops
On 02/09/2010 02:04 PM, Rafał Miłecki wrote:
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
drivers/net/wireless/b43/phy_n.c | 87
+++---
drivers/net/wireless/b43/phy_n.h |1 +
2 files changed, 63 insertions(+), 25 deletions(-)
diff --git a/drivers/net/wireless/b43/phy_n.c
b/drivers/net/wireless/b43/phy_n.c
index 19d4f11..49256bf 100644
--- a/drivers/net/wireless/b43/phy_n.c
+++ b/drivers/net/wireless/b43/phy_n.c
@@ -72,6 +72,7 @@ static void b43_nphy_rf_control_override(struct b43_wldev
*dev, u16 field,
u16 value, u8 core, bool off);
static void b43_nphy_rf_control_intc_override(struct b43_wldev *dev, u8
field,
u16 value, u8 core);
+static int nphy_channel_switch(struct b43_wldev *dev, unsigned int channel);
static inline bool b43_empty_chanspec(struct b43_chanspec *chanspec)
{
@@ -172,31 +173,6 @@ static void b43_radio_2055_setup(struct b43_wldev *dev,
udelay(300);
}
-/* Tune the hardware to a new channel. */
-static int nphy_channel_switch(struct b43_wldev *dev, unsigned int channel)
-{
- const struct b43_nphy_channeltab_entry *tabent;
-
- tabent = b43_nphy_get_chantabent(dev, channel);
- if (!tabent)
- return -ESRCH;
-
- //FIXME enable/disable band select upper20 in RXCTL
- if (0 /*FIXME 5Ghz*/)
- b43_radio_maskset(dev, B2055_MASTER1, 0xFF8F, 0x20);
- else
- b43_radio_maskset(dev, B2055_MASTER1, 0xFF8F, 0x50);
- b43_radio_2055_setup(dev, tabent);
- if (0 /*FIXME 5Ghz*/)
- b43_phy_set(dev, B43_NPHY_BANDCTL, B43_NPHY_BANDCTL_5GHZ);
- else
- b43_phy_mask(dev, B43_NPHY_BANDCTL, ~B43_NPHY_BANDCTL_5GHZ);
- b43_chantab_phy_upload(dev, tabent);
- b43_nphy_tx_power_fix(dev);
-
- return 0;
-}
-
static void b43_radio_init2055_pre(struct b43_wldev *dev)
{
b43_phy_mask(dev, B43_NPHY_RFCTL_CMD,
@@ -3345,6 +3321,67 @@ static void b43_nphy_chanspec_setup(struct b43_wldev
*dev,
b43_nphy_spur_workaround(dev);
}
+/* http://bcm-v4.sipsolutions.net/802.11/PHY/N/SetChanspec */
+static int b43_nphy_set_chanspec(struct b43_wldev *dev,
+ struct b43_chanspec chanspec)
+{
+ struct b43_phy_n *nphy = dev-phy.n;
+
+ const struct b43_nphy_channeltab_entry *tabent;
+
+ u8 tmp;
+ u8 channel = chanspec.channel;
+
+ if (dev-phy.rev = 3) {
+ /* TODO */
+ }
+
+ nphy-radio_chanspec = chanspec;
+
+ if (chanspec.b_width != nphy-b_widht)
+ ; /* TODO: BMAC BW Set (chanspec.b_width) */
+
+ /* TODO: use defines */
+ if (chanspec.b_width == 3) {
+ if (chanspec.sideband == 2)
+ b43_phy_set(dev, B43_NPHY_RXCTL,
+ B43_NPHY_RXCTL_BSELU20);
+ else
+ b43_phy_mask(dev, B43_NPHY_RXCTL,
+ ~B43_NPHY_RXCTL_BSELU20);
+ }
+
+ if (dev-phy.rev = 3) {
+ tmp = (chanspec.b_freq == 1) ? 4 : 0;
+ b43_radio_maskset(dev, 0x08, 0xFFFB, tmp);
+ /* TODO: PHY Radio2056 Setup (chan_info_ptr[i]) */
+ /* TODO: N PHY Chanspec Setup (chan_info_ptr[i]) */
+ } else {
+ tabent = b43_nphy_get_chantabent(dev, channel);
+ if (!tabent)
+ return -ESRCH;
+
+ tmp = (chanspec.b_freq == 1) ? 0x0020 : 0x0050;
+ b43_radio_maskset(dev, B2055_MASTER1, 0xFF8F, tmp);
+ b43_radio_2055_setup(dev, tabent);
+ b43_nphy_chanspec_setup(dev, tabent, chanspec);
+ }
+
+ return 0;
+}
+
+/* Tune the hardware to a new channel */
+static int nphy_channel_switch(struct b43_wldev *dev, unsigned int channel)
+{
+ struct b43_phy_n *nphy = dev-phy.n;
+
+ struct b43_chanspec chanspec;
+ chanspec = nphy-radio_chanspec;
+ chanspec.channel = channel;
+
+ return b43_nphy_set_chanspec(dev, chanspec);
+}
+
static int b43_nphy_op_allocate(struct b43_wldev *dev)
{
struct b43_phy_n *nphy;
diff --git a/drivers/net/wireless/b43/phy_n.h
b/drivers/net/wireless/b43/phy_n.h
index e7acae2..26d01fe 100644
--- a/drivers/net/wireless/b43/phy_n.h
+++ b/drivers/net/wireless/b43/phy_n.h
@@ -984,6 +984,7 @@ struct b43_phy_n {
u16 papd_epsilon_offset[2];
s32 preamble_override;
u32 bb_mult_save;
+ u8 b_widht;
Typo here?
struct b43_chanspec radio_chanspec;
bool gain_boost;
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43legacy-phy3: Radio hardware status changed to XXX
On 02/07/2010 05:57 AM, strk wrote: On Sat, Feb 06, 2010 at 06:54:44PM -0600, Larry Finger wrote: You can get the wireless-compat sources for kernel 2.6.26 and build that. Othersise, go to kernel.org and get the full sources. I opted for an upgrade first (debian lenny to debian squeeze). So I'm now at kernel version 2.6.32 and the problem is somehow different (still related to kill switch). The messages in this case are more clear (on ifconfig wlan0 ): b43legacy ssb0:0: firmware: requesting b3legacy/ucode2.fw b43legacy ssb0:0: firmware: requesting b3legacy/pcm4.fw b43legacy ssb0:0: firmware: requesting b3legacy/b0g0initvals2.fw b43legacy-phy0: Loading firmware version 0x127, patch level 14 (2005-04-18 02:36:27) b43legacy-phy0: Radio hardware status changed to DISABLED b43legacy-phy0: Radio turned on by software b43legacy-phy0: The hardware RF-kill button still turns the radio physically off. Press th ebutton to turn it on. Same suggestions applies ? Or was some load-time option added in 2.6.32 ? There is no load-time option to ignore RFKILL, and as you have read, there never will be. I assume that your laptop has a mini-PCI BCM4303 card. Neither of my two devices uses that format, nor do either of mine implement the RF silent input, which is on pin 13, according to http://www.interfacebus.com/MiniPCI_Pinout_124Pin.html You did not see any logged rfkill messages with bcm43xx as it did not examine this input. The hardware must have honored that input and suppressed the radio whenever it was set. If you generate a system with the RFKILL subsystem disabled, all that will happen is that the messages will go away, and your radio will be silently disabled on an intermittent basis. You need to discover why that input is being generated? There could be a failure in the motherboard circuits that generate the signal. There could be a bug in the software that processes whatever WMI info that your system generates. WMI (Windows Management Interface) code handles the functions of the top row of your keyboard that are generated by a fn+FX key. One alternative would be to alter the MB or the card so that the RF silent input cannot be changed. BTW, I have no idea if it is a high or a low here that kills the radio. I suspect that the radio will be on if the pin is floating, but that is a guess. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43legacy-phy3: Radio hardware status changed to XXX
On 02/06/2010 01:08 PM, strk wrote: Hi everybody, my excuses in advance for asking something which was likely asked a lot more in the past. I just switched to usin b43legacy from bmcxxx (from linux 2.6.18 to linux 2.6.26) and am having some problems with the wireless card. In particular I continually get disable-enable messages: Feb 6 20:01:21 xtops kernel: [ 4910.000194] b43legacy-phy3: Radio hardware status changed to ENABLED Feb 6 20:01:46 xtops kernel: [ 4935.000441] __ratelimit: 3 messages suppressed Feb 6 20:01:46 xtops kernel: [ 4935.000458] b43legacy-phy3: Radio hardware status changed to DISABLED Sometimes this results in a disconnection. -- snip -- Any hint on how to further debug or fix ? Thanks in advance. After bcm43xx was split into b43 and b43legacy, both were upgraded to take account of the computers radio kill switch. Changes in the hardware switch input are causing the Radio hardware ENABLED/DISABLED messages. How does the ASUS implement that switch? Some laptops have a slide switch with an on/off position, while others have a push button with software keeping track of the state. Larry PS: Your address bcm43xx-...@berios.de is wrong. You should use just bcm43xx-...@lists.berlios.de. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43legacy-phy3: Radio hardware status changed to XXX
On 02/06/2010 03:14 PM, strk wrote: On Sat, Feb 06, 2010 at 02:43:36PM -0600, Larry Finger wrote: After bcm43xx was split into b43 and b43legacy, both were upgraded to take account of the computers radio kill switch. Changes in the hardware switch input are causing the Radio hardware ENABLED/DISABLED messages. How does the ASUS implement that switch? Some laptops have a slide switch with an on/off position, while others have a push button with software keeping track of the state. I can see no slide switch, nor sign on any key suggesting to have that purpose. It seems my problem was already reported here: https://lists.berlios.de/pipermail/bcm43xx-dev/2008-November/004843.html ... but the thread has no happy end (I add the author of that post in Cc). Jorge, have you figured it out lately ? You could probably avoid the problems by disabling the RFKILL and RFKILL_INPUT options. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43legacy-phy3: Radio hardware status changed to XXX
On 02/06/2010 06:49 PM, strk wrote: On Sat, Feb 06, 2010 at 06:29:03PM -0600, Larry Finger wrote: On 02/06/2010 06:22 PM, strk wrote: On Sat, Feb 06, 2010 at 06:20:15PM -0600, Larry Finger wrote: You could probably avoid the problems by disabling the RFKILL and RFKILL_INPUT options. How do I do that ? Runtime ? Compile-time ? It needs to be compile time to elimionate that section of b43legacy. Thanks. Is there a repository from which I can get *only* bcm43xx sources and compile against kernel headers ? I've seen this done with debian module-assistant tool... You can get the wireless-compat sources for kernel 2.6.26 and build that. Othersise, go to kernel.org and get the full sources. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43/b43legacy driver
On 02/05/2010 08:48 AM, Gene Heskett wrote: While I took the time to look, there is a plain text component which kmail is showing me, in Davids msgs, and to see the html, I have to specifically click on that line in the automatic mime report kmail gives me. Perhaps its one of your own prefs that mixed up? That does not matter. The HTML version should not be on the lists! Period!! Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC][PATCH] b43: LP-PHY: always adjust gain table on channel switch
On 02/05/2010 10:41 AM, Gábor Stefanik wrote: On Fri, Feb 5, 2010 at 4:24 AM, Larry Finger larry.fin...@lwfinger.net wrote: On 02/04/2010 02:57 PM, Rafał Miłecki wrote: --- Gábor: I think you missed specs here. Could you check whole routine just for sure, please? I don't understand whole radio and chanspec magic yet. --- drivers/net/wireless/b43/phy_lp.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/wireless/b43/phy_lp.c b/drivers/net/wireless/b43/phy_lp.c index 185219e..61009ee 100644 --- a/drivers/net/wireless/b43/phy_lp.c +++ b/drivers/net/wireless/b43/phy_lp.c @@ -2655,8 +2655,8 @@ static int b43_lpphy_op_switch_channel(struct b43_wldev *dev, if (err) return err; lpphy_set_analog_filter(dev, new_channel); - lpphy_adjust_gain_table(dev, channel2freq_lp(new_channel)); } + lpphy_adjust_gain_table(dev, channel2freq_lp(new_channel)); lpphy-channel = new_channel; b43_write16(dev, B43_MMIO_CHANNEL, new_channel); Both the lpphy_set_analog_filter() and lpphy_adjust_gain_table() calls should be outside the if statement. I changed the spec a little. It used to test radio enabled, but I have found that is always true for our driver. Larry Isn't set_analog_filter() rev0/1-specific? It was in the 4.174.64.19 driver that I RE'd when you wrote the LP PHY code. That as changed in 5.10.56.46, which I am now doing. It will take me a while to complete the new routine LP PHY TX Filter Init and a routine that it calls. Certainly, there is no hurry that these changes be made. Whenever you or Rafał have time. There is no guarantee that these changes will have any effect on the LP PHY operations. Hitting a moving target is not easy. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC][PATCH] b43: LP-PHY: always adjust gain table on channel switch
On 02/05/2010 12:46 PM, Gábor Stefanik wrote: On Fri, Feb 5, 2010 at 7:09 PM, Larry Finger larry.fin...@lwfinger.net wrote: On 02/05/2010 10:41 AM, Gábor Stefanik wrote: On Fri, Feb 5, 2010 at 4:24 AM, Larry Finger larry.fin...@lwfinger.net wrote: On 02/04/2010 02:57 PM, Rafał Miłecki wrote: --- Gábor: I think you missed specs here. Could you check whole routine just for sure, please? I don't understand whole radio and chanspec magic yet. --- drivers/net/wireless/b43/phy_lp.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/wireless/b43/phy_lp.c b/drivers/net/wireless/b43/phy_lp.c index 185219e..61009ee 100644 --- a/drivers/net/wireless/b43/phy_lp.c +++ b/drivers/net/wireless/b43/phy_lp.c @@ -2655,8 +2655,8 @@ static int b43_lpphy_op_switch_channel(struct b43_wldev *dev, if (err) return err; lpphy_set_analog_filter(dev, new_channel); - lpphy_adjust_gain_table(dev, channel2freq_lp(new_channel)); } + lpphy_adjust_gain_table(dev, channel2freq_lp(new_channel)); lpphy-channel = new_channel; b43_write16(dev, B43_MMIO_CHANNEL, new_channel); Both the lpphy_set_analog_filter() and lpphy_adjust_gain_table() calls should be outside the if statement. I changed the spec a little. It used to test radio enabled, but I have found that is always true for our driver. Larry Isn't set_analog_filter() rev0/1-specific? It was in the 4.174.64.19 driver that I RE'd when you wrote the LP PHY code. That as changed in 5.10.56.46, which I am now doing. It will take me a while to complete the new routine LP PHY TX Filter Init and a routine that it calls. Certainly, there is no hurry that these changes be made. Whenever you or Rafał have time. There is no guarantee that these changes will have any effect on the LP PHY operations. Hitting a moving target is not easy. Larry Just out of curiosity, is 5.10.56.46 available anywhere (for firmware reasons)? I'm not sure what the driver version is, but a file with 508 ucode dated 6/26/09 is found at: http://www.linksysbycisco.com/gpl/wrt610n_v2.00.00.05_us.tar.gz The binaries are in directory wrt610n_v2.00.00.05_us/release/src/wl/linux/. I used Daniel Lenski's script names b43_fwcutter.py can extract the firmware from wl_apsta.o. Included are ucode_2w20 - Rev 20 802.11 cores have an SSLPN PHY. I'm still looking for a file with 5XX firmware that is not a huge download. This file contains everything needed to build the firmware for a WRT610N AP and is 356 MB. If anyone knows of a smaller file, please let me know. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC][PATCH] b43: LP-PHY: always adjust gain table on channel switch
On 02/05/2010 10:27 AM, Gábor Stefanik wrote: On Fri, Feb 5, 2010 at 4:24 AM, Larry Finger larry.fin...@lwfinger.net wrote: On 02/04/2010 02:57 PM, Rafał Miłecki wrote: --- Gábor: I think you missed specs here. Could you check whole routine just for sure, please? I don't understand whole radio and chanspec magic yet. --- drivers/net/wireless/b43/phy_lp.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/wireless/b43/phy_lp.c b/drivers/net/wireless/b43/phy_lp.c index 185219e..61009ee 100644 --- a/drivers/net/wireless/b43/phy_lp.c +++ b/drivers/net/wireless/b43/phy_lp.c @@ -2655,8 +2655,8 @@ static int b43_lpphy_op_switch_channel(struct b43_wldev *dev, if (err) return err; lpphy_set_analog_filter(dev, new_channel); - lpphy_adjust_gain_table(dev, channel2freq_lp(new_channel)); } + lpphy_adjust_gain_table(dev, channel2freq_lp(new_channel)); lpphy-channel = new_channel; b43_write16(dev, B43_MMIO_CHANNEL, new_channel); Both the lpphy_set_analog_filter() and lpphy_adjust_gain_table() calls should be outside the if statement. I changed the spec a little. It used to test radio enabled, but I have found that is always true for our driver. Larry Isn't set_analog_filter() rev0/1-specific? The new routines are described in http://bcm-v4.sipsolutions.net/802.11/PHY/LP/TxFilterInit http://bcm-v4.sipsolutions.net/802.11/PHY/LP/TxDigFiltUcodeRev2 The revised routines are: http://bcm-v4.sipsolutions.net/802.11/PHY/LP/SetChanSpecLPPHY http://bcm-v4.sipsolutions.net/802.11/PHY/LP/PR41573 Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC][PATCH] b43: LP-PHY: always adjust gain table on channel switch
On 02/04/2010 02:57 PM, Rafał Miłecki wrote: --- Gábor: I think you missed specs here. Could you check whole routine just for sure, please? I don't understand whole radio and chanspec magic yet. --- drivers/net/wireless/b43/phy_lp.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/wireless/b43/phy_lp.c b/drivers/net/wireless/b43/phy_lp.c index 185219e..61009ee 100644 --- a/drivers/net/wireless/b43/phy_lp.c +++ b/drivers/net/wireless/b43/phy_lp.c @@ -2655,8 +2655,8 @@ static int b43_lpphy_op_switch_channel(struct b43_wldev *dev, if (err) return err; lpphy_set_analog_filter(dev, new_channel); - lpphy_adjust_gain_table(dev, channel2freq_lp(new_channel)); } + lpphy_adjust_gain_table(dev, channel2freq_lp(new_channel)); lpphy-channel = new_channel; b43_write16(dev, B43_MMIO_CHANNEL, new_channel); Both the lpphy_set_analog_filter() and lpphy_adjust_gain_table() calls should be outside the if statement. I changed the spec a little. It used to test radio enabled, but I have found that is always true for our driver. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM4311/02 ABG disconnects on 2.6.32
On 02/03/2010 11:33 AM, Yuval Hager wrote: Thank you for your efforts, I highly appreciate it. I pulled latest wireless-testing (git describe says v2.6.33-rc6-47373- g3b4936f), and applied these two patches. This time there is another type of disconnection (wlan0: deauthenticating from 00:22:3f:18:89:5e by local choice (reason=3)), in addition to the no probe response I was getting previously. The big change in these patches is that the system is able to get over it and reconnect after the disconnection. The short-slot patch will only affect performance; however, the patch that restarts the queues could certainly be the one that allows the system to reconnect and continue. The surprising part is that I sent it earlier and was told that it did not help. Does your AP have the latest firmware? At http://forums.wi-fiplanet.com/showthread.php?t=6536, reason 3 is listed as The access point went offline, deauthenticating the client. Other explanations are likely possible. I have not checked the IEEE802.11 documents. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43/b43legacy: Wake queues in wireless_core_start
If b43 or b43legacy are deauthenticated or disconnected, there is a possibility that a reconnection is tried with the queues stopped in mac80211. To prevent this, start the queues before setting STAT_INITIALIZED. In b43, a similar change has been in place (twice) in the wireless_core_init() routine. Remove the duplicate and add similar code to b43legacy. Signed-off-by: Larry Finger larry.fin...@lwfinger.net Cc: Stable sta...@kernel.org [2.6.32] --- John, The b43 patch to wireless_core_start() seems to help a regression between 2.6.31 and 2.6.32. Accordingly, these changes should be applied to 2.6.33 with the automatic backport to 2.6.32. Larry --- Index: wireless-testing/drivers/net/wireless/b43/main.c === --- wireless-testing.orig/drivers/net/wireless/b43/main.c +++ wireless-testing/drivers/net/wireless/b43/main.c @@ -3980,6 +3980,7 @@ static int b43_wireless_core_start(struc } /* We are ready to run. */ + ieee80211_wake_queues(dev-wl-hw); b43_set_status(dev, B43_STAT_STARTED); /* Start data flow (TX/RX). */ @@ -4389,8 +4390,6 @@ static int b43_wireless_core_init(struct ieee80211_wake_queues(dev-wl-hw); - ieee80211_wake_queues(dev-wl-hw); - b43_set_status(dev, B43_STAT_INITIALIZED); out: Index: wireless-testing/drivers/net/wireless/b43legacy/main.c === --- wireless-testing.orig/drivers/net/wireless/b43legacy/main.c +++ wireless-testing/drivers/net/wireless/b43legacy/main.c @@ -2923,6 +2923,7 @@ static int b43legacy_wireless_core_start goto out; } /* We are ready to run. */ + ieee80211_wake_queues(dev-wl-hw); b43legacy_set_status(dev, B43legacy_STAT_STARTED); /* Start data flow (TX/RX) */ @@ -3343,6 +3344,7 @@ static int b43legacy_wireless_core_init( b43legacy_security_init(dev); b43legacy_rng_init(wl); + ieee80211_wake_queues(dev-wl-hw); b43legacy_set_status(dev, B43legacy_STAT_INITIALIZED); b43legacy_leds_init(dev); ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM4311/02 ABG disconnects on 2.6.32
On 02/03/2010 01:37 PM, Yuval Hager wrote: I just upgraded to the latest firmware, but there is no change. I am not having any issues with this router while running 2.6.29 on this machine, or 2.6.32 on another machine (using rt2x500pci). The router is Netgear WGR614V9, and the firmware is V1.2.24_37.0.35. Also note that this reason 3 only occures after the first association - after that it just continues with the no probe response I got used to. Based on a suggestion by Michael Buesch, I am trying a new version of the patch. Does this one work for you? Larry === Index: wireless-testing/drivers/net/wireless/b43/main.c === --- wireless-testing.orig/drivers/net/wireless/b43/main.c +++ wireless-testing/drivers/net/wireless/b43/main.c @@ -3980,6 +3980,7 @@ static int b43_wireless_core_start(struc } /* We are ready to run. */ + ieee80211_wake_queues(dev-wl-hw); b43_set_status(dev, B43_STAT_STARTED); /* Start data flow (TX/RX). */ @@ -4387,10 +4388,6 @@ static int b43_wireless_core_init(struct b43_upload_card_macaddress(dev); b43_security_init(dev); - ieee80211_wake_queues(dev-wl-hw); - - ieee80211_wake_queues(dev-wl-hw); - b43_set_status(dev, B43_STAT_INITIALIZED); out: Index: wireless-testing/drivers/net/wireless/b43legacy/main.c === --- wireless-testing.orig/drivers/net/wireless/b43legacy/main.c +++ wireless-testing/drivers/net/wireless/b43legacy/main.c @@ -2923,6 +2923,7 @@ static int b43legacy_wireless_core_start goto out; } /* We are ready to run. */ + ieee80211_wake_queues(dev-wl-hw); b43legacy_set_status(dev, B43legacy_STAT_STARTED); /* Start data flow (TX/RX) */ If b43 or b43legacy are deauthenticated or disconnected, there is a possibility that a reconnection is tried with the queues stopped in mac80211. To prevent this, start the queues before setting STAT_INITIALIZED. In b43, a similar change has been in place (twice) in the wireless_core_init() routine. Remove the duplicate and add similar code to b43legacy. Signed-off-by: Larry Finger larry.fin...@lwfinger.net Cc: Stable sta...@kernel.org [2.6.32] --- John, The b43 patch to wireless_core_start() seems to help a regression between 2.6.31 and 2.6.32. Accordingly, these changes should be applied to 2.6.33 with the automatic backport to 2.6.32. Larry --- Index: wireless-testing/drivers/net/wireless/b43/main.c === --- wireless-testing.orig/drivers/net/wireless/b43/main.c +++ wireless-testing/drivers/net/wireless/b43/main.c @@ -3980,6 +3980,7 @@ static int b43_wireless_core_start(struc } /* We are ready to run. */ + ieee80211_wake_queues(dev-wl-hw); b43_set_status(dev, B43_STAT_STARTED); /* Start data flow (TX/RX). */ @@ -4387,10 +4388,6 @@ static int b43_wireless_core_init(struct b43_upload_card_macaddress(dev); b43_security_init(dev); - ieee80211_wake_queues(dev-wl-hw); - - ieee80211_wake_queues(dev-wl-hw); - b43_set_status(dev, B43_STAT_INITIALIZED); out: Index: wireless-testing/drivers/net/wireless/b43legacy/main.c === --- wireless-testing.orig/drivers/net/wireless/b43legacy/main.c +++ wireless-testing/drivers/net/wireless/b43legacy/main.c @@ -2923,6 +2923,7 @@ static int b43legacy_wireless_core_start goto out; } /* We are ready to run. */ + ieee80211_wake_queues(dev-wl-hw); b43legacy_set_status(dev, B43legacy_STAT_STARTED); /* Start data flow (TX/RX) */ ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: Fix regression from commit c7ab5ef
Commit c7ab5ef9bcd281135c21b4732c9be779585181be entitled b43: implement
short slot and basic rate handling reduced the transmit throughput for
my BCM4311 device from 18 Mb/s to 0.7 Mb/s. The basic rate handling
portion is OK, the problem is in the short slot handling.
Prior to this change, the short slot enable/disable routines were never
called. Experimentation showed that the critical part was changing the
value at offset 0x0010 in the shared memory. This is supposed to contain
the 802.11 Slot Time in usec, but if it is changed from its initial value
of zero, performance is destroyed. On the other hand, changing the value
in the MMIO register corresponding to the Interframe Slot Time increased
performance from 18 to 22 Mb/s. A BCM4306/3 also shows dramatic
improvement of the transmit rate from 5.3 to 19.0 Mb/s.
Other changes in the patch include removal of the magic number for the
MMIO register, and allowing the slot time to be set for any PHY operating
in the 2.4 GHz band. Previously, the routine was executed only for G PHYs.
Signed-off-by: Larry Finger larry.fin...@lwfinger.net
Cc: Stable sta...@kernel.org [Any stable version back through 2.6.28]
---
John,
Although late in the cycle, this is 2.6.33 material, and should be applied
to kernels back to and including 2.6.28.
Thanks,
Larry
---
Index: wireless-testing/drivers/net/wireless/b43/main.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/main.c
+++ wireless-testing/drivers/net/wireless/b43/main.c
@@ -637,10 +637,17 @@ static void b43_upload_card_macaddress(s
static void b43_set_slot_time(struct b43_wldev *dev, u16 slot_time)
{
/* slot_time is in usec. */
- if (dev-phy.type != B43_PHYTYPE_G)
+ /* This test used to exit for all but a G PHY. */
+ if (b43_current_band(dev-wl) == IEEE80211_BAND_5GHZ)
return;
- b43_write16(dev, 0x684, 510 + slot_time);
- b43_shm_write16(dev, B43_SHM_SHARED, 0x0010, slot_time);
+ b43_write16(dev, B43_MMIO_IFSSLOT, 510 + slot_time);
+ /* Shared memory location 0x0010 is the slot time and should be
+* set to slot_time; however, this register is initially 0 and changing
+* the value adversely affects the transmit rate for BCM4311
+* devices. Until this behavior is unterstood, delete this step
+*
+* b43_shm_write16(dev, B43_SHM_SHARED, 0x0010, slot_time);
+*/
}
static void b43_short_slot_timing_enable(struct b43_wldev *dev)
Index: wireless-testing/drivers/net/wireless/b43/b43.h
===
--- wireless-testing.orig/drivers/net/wireless/b43/b43.h
+++ wireless-testing/drivers/net/wireless/b43/b43.h
@@ -115,6 +115,7 @@
#define B43_MMIO_TSF_2 0x636 /* core rev 3 only */
#define B43_MMIO_TSF_3 0x638 /* core rev 3 only */
#define B43_MMIO_RNG 0x65A
+#define B43_MMIO_IFSSLOT 0x684 /* Interframe slot time */
#define B43_MMIO_IFSCTL0x688 /* Interframe space
control */
#define B43_MMIO_IFSCTL_USE_EDCF 0x0004
#define B43_MMIO_POWERUP_DELAY 0x6A8
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM4311/02 ABG disconnects on 2.6.32
On 01/29/2010 03:05 AM, Orivej Desh wrote:
Not sure if this helps, but on my system (Network controller [0280]: Broadcom
Corporation BCM4311 802.11b/g WLAN [14e4:4311] (rev 01); b43-phy0: Broadcom
4311
WLAN found (core revision 10)) network controller no longer operates after
disconnect. That is, iwlist wlan0 scan finds nothing.
My other details are similar to Yuval's one — I've got the latest firmware,
the
problem appeared in 2.6.32, I've tested latest git without luck. Can't help
too
much, though, because there is no unprotected network over here (from which
laptop disconnects immediately), and on the protected one on-line time is too
large: at this session the first disconnect occured after 35 hours, the
second -
after half an hour after driver reset with ifconfig wlan0 down/up, the third
-
hour and an half after reset; this is not normal because I had no disconnects
before 2.6.32.
I installed my BCM4311/2 device to try to duplicate your results from above. I
found a problem with performance and have posted a patch for that. I set my AP,
which is a Linksys WRT54GL V1.1 running openWRT Kamikaze r16206 firmware. I set
my network to be unencrypted as you said that made the failure to occur more
quickly. As I write this, my device has been running for 32 hours with no
dropouts. I cannot duplicate your results.
My system is wireless-testing 2.6.33-rc5 with the two patches below. Please add
them to your system and try again.
Larry
===
Index: wireless-testing/drivers/net/wireless/b43/main.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/main.c
+++ wireless-testing/drivers/net/wireless/b43/main.c
@@ -637,10 +637,17 @@ static void b43_upload_card_macaddress(s
static void b43_set_slot_time(struct b43_wldev *dev, u16 slot_time)
{
/* slot_time is in usec. */
- if (dev-phy.type != B43_PHYTYPE_G)
+ /* This test used to exit for all but a G PHY. */
+ if (b43_current_band(dev-wl) == IEEE80211_BAND_5GHZ)
return;
- b43_write16(dev, 0x684, 510 + slot_time);
- b43_shm_write16(dev, B43_SHM_SHARED, 0x0010, slot_time);
+ b43_write16(dev, B43_MMIO_IFSSLOT, 510 + slot_time);
+ /* Shared memory location 0x0010 is the slot time and should be
+* set to slot_time; however, this register is initially 0 and changing
+* the value adversely affects the transmit rate for BCM4311
+* devices. Until this behavior is unterstood, delete this step
+*
+* b43_shm_write16(dev, B43_SHM_SHARED, 0x0010, slot_time);
+*/
}
static void b43_short_slot_timing_enable(struct b43_wldev *dev)
Index: wireless-testing/drivers/net/wireless/b43/b43.h
===
--- wireless-testing.orig/drivers/net/wireless/b43/b43.h
+++ wireless-testing/drivers/net/wireless/b43/b43.h
@@ -115,6 +115,7 @@
#define B43_MMIO_TSF_2 0x636 /* core rev 3 only */
#define B43_MMIO_TSF_3 0x638 /* core rev 3 only */
#define B43_MMIO_RNG 0x65A
+#define B43_MMIO_IFSSLOT 0x684 /* Interframe slot time */
#define B43_MMIO_IFSCTL0x688 /* Interframe space
control */
#define B43_MMIO_IFSCTL_USE_EDCF 0x0004
#define B43_MMIO_POWERUP_DELAY 0x6A8
Index: wireless-testing/drivers/net/wireless/b43/main.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/main.c
+++ wireless-testing/drivers/net/wireless/b43/main.c
@@ -3980,6 +3980,7 @@ static int b43_wireless_core_start(struc
}
/* We are ready to run. */
+ ieee80211_wake_queues(dev-wl-hw);
b43_set_status(dev, B43_STAT_STARTED);
/* Start data flow (TX/RX). */
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[RFC/RFT] b43: Fix regression from commit c7ab5ef
I had planned to address the issues reported in the thread BCM4311/02
ABG disconnects on 2.6.32; however, when I installed my BCM4311/2 card,
I found that the transmit rate as measured using program tcpperf was
greatly reduced from what I had seen when it was last in the machine.
With bisection, mainline commit number c7ab5ef9b was the problem. This
patch was part of the 2.6.28 merge, thus this problem has existed for
some time.
The patch changes basic rate handling and implements short slot handling.
The rate handling is OK - only the short slot changes were affecting
the performance. Further investigation showed that the original code
never called the routines that enable/disable short slot treatment,
but the revised code does. From the specs, changing this parameter
involves writing new values into a location in MMIO space and one in
the shared memory. Experimentation showed that writing the new value
to shared memory was the culprit. Changing the value in MMIO space
actually helped performance in some cases.
Tests on all my G PHY devices are summarized below. My AP is a Linksys
WRT54G V5 running the latest version of standard firmware, and with
combined 802.11b/g mode enabled. Transmit tests use program tcpperf
with a fast computer in my network as the tcpperf server. It is connected
to the AP/router with a 100 Mb/s wired connection. The results for all
my devices as as follows:
Transmit throughput in Mb/s
DeviceBefore c7ab5ef After c7ab5ef With this patch
BCM4306/3 unknown 5.3 19.0
BCM4318/2 unknown 18.3 18.3
BCM4311/2 18.3 0.7 22.1
BCM4312/1 N/A*12.2 12.2
* LP PHY that was not supported until 2.6.32.
I have no idea what causes some devices to be unaffected, while others
are greatly improved. Please test to see if your device is adversely
affested.
Thanks,
Larry
--- Proposed commit message below. ---
Commit c7ab5ef9bcd281135c21b4732c9be779585181be entitled b43: implement
short slot and basic rate handling reduced the transmit throughput for
my BCM4311 device from 18 Mb/s to 0.7 Mb/s. The basic rate handling
portion is OK, the problem is in the short slot handling.
Prior to this change, the short slot enable/disable routines were never
called. Experimentation showed that the critical part was changing the
value at offset 0x0010 in the shared memory. This is supposed to contain
the 802.11 Slot Time in usec, but if it is changed from its initial value
of zero, performance is destroyed. On the other hand, changing the value
in the MMIO register corresponding to the Interframe Slot Time increased
performance from 18 to 22 Mb/s. A BCM4306/3 also shows dramatic
improvement of the transmit rate.
Other changes in the patch include removal of the magic number for the
MMIO register, and allowing the slot time to be set for any PHY operating
in the 2.4 GHz band. Previously, the routine was executed only for G PHYs.
Signed-off-by: Larry Finger larry.fin...@lwfinger.net
Cc: Stable sta...@kernel.org [Any stable version back through 2.6.28]
---
Index: wireless-testing/drivers/net/wireless/b43/main.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/main.c
+++ wireless-testing/drivers/net/wireless/b43/main.c
@@ -637,10 +637,17 @@ static void b43_upload_card_macaddress(s
static void b43_set_slot_time(struct b43_wldev *dev, u16 slot_time)
{
/* slot_time is in usec. */
- if (dev-phy.type != B43_PHYTYPE_G)
+ /* This test used to exit for all but a G PHY. */
+ if (b43_current_band(dev-wl) == IEEE80211_BAND_5GHZ)
return;
- b43_write16(dev, 0x684, 510 + slot_time);
- b43_shm_write16(dev, B43_SHM_SHARED, 0x0010, slot_time);
+ b43_write16(dev, B43_MMIO_IFSSLOT, 510 + slot_time);
+ /* Shared memory location 0x0010 is the slot time and should be
+* set to slot_time; however, this register is initially 0 and changing
+* the value adversely affects the transmit rate for BCM4311
+* devices. Until this behavior is unterstood, delete this step
+*
+* b43_shm_write16(dev, B43_SHM_SHARED, 0x0010, slot_time);
+*/
}
static void b43_short_slot_timing_enable(struct b43_wldev *dev)
Index: wireless-testing/drivers/net/wireless/b43/b43.h
===
--- wireless-testing.orig/drivers/net/wireless/b43/b43.h
+++ wireless-testing/drivers/net/wireless/b43/b43.h
@@ -115,6 +115,7 @@
#define B43_MMIO_TSF_2 0x636 /* core rev 3 only */
#define B43_MMIO_TSF_3 0x638 /* core rev 3 only */
#define B43_MMIO_RNG 0x65A
+#define B43_MMIO_IFSSLOT 0x684 /* Interframe slot time */
#define B43_MMIO_IFSCTL0x688 /* Interframe space
control */
#define
Re: [PATCH 1/5] b43: N-PHY: split RSSI selection into two per-PHY-revision functions
On 01/30/2010 01:18 PM, Rafał Miłecki wrote: Signed-off-by: Rafał Miłecki zaj...@gmail.com --- This one yields Warning: trailing whitespace in line 1357 of drivers/net/wireless/b43/phy_n.c Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM4311/02 ABG disconnects on 2.6.32
On 01/28/2010 04:42 AM, Yuval Hager wrote: I'll be happy to apply patches as you wish. Does this patch make any difference? Index: wireless-testing/drivers/net/wireless/b43/main.c === --- wireless-testing.orig/drivers/net/wireless/b43/main.c +++ wireless-testing/drivers/net/wireless/b43/main.c @@ -3980,6 +3980,7 @@ static int b43_wireless_core_start(struc } /* We are ready to run. */ + ieee80211_wake_queues(dev-wl-hw); b43_set_status(dev, B43_STAT_STARTED); /* Start data flow (TX/RX). */ --- Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM4311/02 ABG disconnects on 2.6.32
On 01/28/2010 11:16 AM, Yuval Hager wrote: On Thursday 28 January 2010 18:25:50 Larry Finger wrote: On 01/28/2010 04:42 AM, Yuval Hager wrote: I'll be happy to apply patches as you wish. Does this patch make any difference? No. The patch did not apply on 36dbd954, I had to apply it manually. Should I switch to latest wireless testing for this? Have you tried wireless testing? If so, I don't see it in the mail messages. There is a possibility that this problem has been fixed, but not backported. Using wireless testing would also be helpful as then any patches that we provide would apply without fiddling. In the meantime, I will switch to my BCM4311 to see if it is affected. The PHY is similar to yours, except for the 802.11a capability. It has been a while since it was in the machine. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM4311/02 ABG disconnects on 2.6.32
On 01/27/2010 09:38 AM, Rafał Miłecki wrote: 2010/1/27 Yuval Hageryha...@yhager.com: On Sunday 27 December 2009, Yuval Hager wrote: On Saturday 26 December 2009, Gábor Stefanik wrote: Update your pci.ids file - what you have is a BCM4311/02 ABG. I ran update-pciids successfully, now dmesg says: b43-phy0: Broadcom 4311 WLAN found (core revision 13) and lspci: 02:00.0 Network controller [0280]: Broadcom Corporation BCM4312 802.11a/b/g [14e4:4312] (rev 02) Also, could you check a few more kernels in-between .29 and .32? I have checked the following kernels, and found they all work correctly: 2.6.29 2.6.29.6 2.6.30.4 2.6.31.9 Kernels 2.6.32 and 2.6.32.2 experience the disconnection I mentioned in the original post. Before checking 2.6.32, I have removed /lib/firmware/b43 completely and installed the firmware based on the detailed instructions on the web site. I also enabled CONFIG_B43_PHY_LP=y for 2.6.32. all kernels checked are vanilla kernels, from kernel.org. Just a quick update on this - this still happes on latest - 2.6.32.6. Could you try to (git) bisect this problem? This will unfortunately take hours to do, but should give us commit that broke support for your wifi. For howto you can check http://landley.net/writing/git-quick.html Generally I think you should do something like: git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git cd linux-2.6 git bisect bad 22763c5cf3690a681551162c15d34d935308c8d7 git bisect good 74fca6a42863ffacaf7ba6f1936a9f228950f657 You can eventually bisect on drivers/net/wireless but I'm not sure how to do this properly. git start drivers/net/wireless git good blahblah git bad blahblah ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: N PHY: Fix compilation after removal of typdef b43_c32
In the conversion between typedef and struct, two places that needed a struct
were missed.
Signed-off-by: Larry Finger larry.fin...@lwfinger.net
---
John,
Without these, compilation fails.
Larry
---
Index: wireless-testing/drivers/net/wireless/b43/phy_n.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/phy_n.c
+++ wireless-testing/drivers/net/wireless/b43/phy_n.c
@@ -822,7 +822,7 @@ static u16 b43_nphy_gen_load_samples(str
{
int i;
u16 bw, len, rot, angle;
- b43_c32 *samples;
+ struct b43_c32 *samples;
bw = (dev-phy.is_40mhz) ? 40 : 20;
@@ -840,7 +840,7 @@ static u16 b43_nphy_gen_load_samples(str
len = bw 1;
}
- samples = kzalloc(len * sizeof(b43_c32), GFP_KERNEL);
+ samples = kzalloc(len * sizeof(struct b43_c32), GFP_KERNEL);
rot = (((freq * 36) / bw) 16) / 100;
angle = 0;
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
On 01/25/2010 02:15 PM, Lucas Thode wrote: As you can tell, this processor is neither an Atom nor a ULV Core 2 Duo. The WLAN card is the Dell Wireless 1395 that came with the laptop (a Vostro 1510). I can build a custom kernel based on the Debian kernel sources if need be; just tell me what config options to flip/patches to apply. Also, wl.o works on this laptop with the Debian 2.6.30 kernel. Aptitude lists the kernel version as a 2.6.32-5. There is one other report of the DMA problem with a non-Atom CPU (I'm not sure about the non-ULV part.). We do not know what the wl driver does that we do not, or vice-versa. If you want to use b43, you need to build it to use PIO only. Choosing PIO is now available as a run-time option, but I do not think 2.6.32 has this feature. Debugging this problem has been most difficult as it only affects Intel CPUs and all my machines have AMD processors. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 0/5] b43: more N-PHY stuff
On 01/22/2010 09:01 AM, Gábor Stefanik wrote: 2010/1/22 Rafał Miłecki zaj...@gmail.com: John, I hope to have patch submission fixed, please let me know if there is anything wrong still. Nope, it is still base64-encoded. I personally use Thunderbird 2 for patch submission (had weird problems with Thunderbird 3 beta - not sure about the final version). I am reading mail with Thunderbird 3.0beta4, and only patch 1/5 was base64-encoded. The other 4 were fine. For the record, the final version of TBird 3 cannot read my profile. I battled with the devs for a while, but have now given up. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: PHY Transmission error and radio turned off with b43legacy
On 01/15/2010 06:12 AM, Jochen Friedrich wrote: Daniel Schmitt wrote: hostapd doesn't continue to work after controller is restarted. I also have the problem that the wlan0-interface shall not be upped with ifconfig wlan0 0.0.0.0 up before starting hostapd, otherwise no beacons will be send. The interface must be down before starting hostapd. If I terminate a not daemonized hostapd with CTRL+C and restart if without rmmod+modprobe b43legacy, no beacons are sent, too. And I cannot connect the AP. This happens with the bleeding-edge wireless drivers 2009-11-13. I noticed the same on MN700 hardware running OpenWrt bleeding edge. The init scripts enable and disable wlan0 once before starting hostapd. Here, beacons are still being sent, but hostapd is unable to transmit any packet. When reloading b43legacy and starting hostapd manually it works, but only once. The attached patch resolves the problem for me. Daniel: Does this patch fix your problem as well? Has this problem been reported in the kernel bugzilla? If so, what is the number? How far back does this problem go? From the date of your compat-wireless package, it seems that 2.6.32 would be affected. How about 2.6.31? I have tested the patch on my system where it does no harm. I do not run that system as an AP and had not seen the problem. As soon as I have the answers to these questions, I will push the patch to wireless testing. Thanks for resolving this issue. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 3/3] b43: N-PHY: add RX IQ calculation for rev 3
On 01/12/2010 01:38 PM, Rafał Miłecki wrote: Signed-off-by: Rafał Miłecki zaj...@gmail.com --- Uh, bigger one. This patch causes false warning: drivers/net/wireless/b43/phy_n.c: In function ‘b43_nphy_rev2_cal_rx_iq’: drivers/net/wireless/b43/phy_n.c:627: warning: large integer implicitly truncated to unsigned type That's for: b43_phy_maskset(dev, B43_NPHY_RFSEQCA, ~B43_NPHY_RFSEQCA_RXDIS, ((1 - i) B43_NPHY_RFSEQCA_RXDIS_SHIFT)); It's inside loop i=0,1. I tried casting i on (u8) but this didn't help. Can we leave this? Or can sb share some trick to avoid this warning? It is ~B43_NPHY_RFSEQCA_RXDIS, not i, that causes the warning. Change the statement to b43_phy_maskset(dev, B43_NPHY_RFSEQCA, (u16)(~B43_NPHY_RFSEQCA_RXDIS), ((1 - i) B43_NPHY_RFSEQCA_RXDIS_SHIFT)); Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 3/3] b43: N-PHY: add RX IQ calculation for rev 3
On 01/13/2010 07:38 AM, Rafał Miłecki wrote: W dniu 13 stycznia 2010 14:31 użytkownik Larry Finger larry.fin...@lwfinger.net napisał: On 01/12/2010 01:38 PM, Rafał Miłecki wrote: Signed-off-by: Rafał Miłecki zaj...@gmail.com --- Uh, bigger one. This patch causes false warning: drivers/net/wireless/b43/phy_n.c: In function ‘b43_nphy_rev2_cal_rx_iq’: drivers/net/wireless/b43/phy_n.c:627: warning: large integer implicitly truncated to unsigned type That's for: b43_phy_maskset(dev, B43_NPHY_RFSEQCA, ~B43_NPHY_RFSEQCA_RXDIS, ((1 - i) B43_NPHY_RFSEQCA_RXDIS_SHIFT)); It's inside loop i=0,1. I tried casting i on (u8) but this didn't help. Can we leave this? Or can sb share some trick to avoid this warning? It is ~B43_NPHY_RFSEQCA_RXDIS, not i, that causes the warning. Change the statement to b43_phy_maskset(dev, B43_NPHY_RFSEQCA, (u16)(~B43_NPHY_RFSEQCA_RXDIS), ((1 - i) B43_NPHY_RFSEQCA_RXDIS_SHIFT)); Yeah, Michael already pointed that :) For some reason, I lost my feed from linux-wireless. I found Michael's message in the archives. If I have not responded to any of your private messages, please send them again. I'm not sure if the mail stoppage is general. There is no traffic from other lists as well. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Impossible to associate with WPA with a LP-PHY
On 01/12/2010 03:32 AM, Éric Piel wrote: Op 11-01-10 00:56, Larry Finger schreef: On 01/10/2010 04:51 PM, Éric Piel wrote: Hello, I've got a bcm43 with LP-PHY (14e4:4315, rev 01). The b43 driver seems to work fine (since 2.6.32), excepted when WPA is used. When there is no encryption, or just WEP, there is no problem. However, when I try to connect to a AP with WPA (which works from Windows, and also with the wl driver), it fails to associate. wpa_cli shows me this messages repeatedly: 2Trying to associate with 00:18:84:15:d3:3e (SSID='MyPlace9' freq=2412 MHz) 2Authentication with 00:18:84:15:d3:3e timed out. There doesn't seem to be any interesting error message in dmesg. I've just tried with Linus'git head, and it's the same result. The firmware loaded is noted as 478.104 in dmesg. What can I do to try to debug this? The problem is not general. I use b43 with a 4315 device with WPA or WPA2 without difficulty. Are you using NetworkManager? If so, look at /var/log/NetworkManager. If not, then you need to start wpa_supplicant separately with the -ddd option. I'm using Mandriva's network manager (which is basically just a frontend to wpa_supplicant). However, now that I try just with wpa_supplicant, it works fine! I'll investigate a bit further, it's probably a bug in the frontend. I don't use Mandriva, but the version of NetworkManager distributed with openSUSE has had problems in the past. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Impossible to associate with WPA with a LP-PHY
On 01/10/2010 04:51 PM, Éric Piel wrote: Hello, I've got a bcm43 with LP-PHY (14e4:4315, rev 01). The b43 driver seems to work fine (since 2.6.32), excepted when WPA is used. When there is no encryption, or just WEP, there is no problem. However, when I try to connect to a AP with WPA (which works from Windows, and also with the wl driver), it fails to associate. wpa_cli shows me this messages repeatedly: 2Trying to associate with 00:18:84:15:d3:3e (SSID='MyPlace9' freq=2412 MHz) 2Authentication with 00:18:84:15:d3:3e timed out. There doesn't seem to be any interesting error message in dmesg. I've just tried with Linus'git head, and it's the same result. The firmware loaded is noted as 478.104 in dmesg. What can I do to try to debug this? The problem is not general. I use b43 with a 4315 device with WPA or WPA2 without difficulty. Are you using NetworkManager? If so, look at /var/log/NetworkManager. If not, then you need to start wpa_supplicant separately with the -ddd option. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 1/5] b43: N-PHY: implement b43_nphy_stay_carrier_search and it's calls
On 01/06/2010 09:50 AM, Michael Buesch wrote:
On Wednesday 06 January 2010 16:40:32 Rafał Miłecki wrote:
b43: N-PHY: implement b43_nphy_stay_carrier_search and it's calls
Hm, The phrase stay carrier earch doesn't make a lot of sense to me.
Is stray carrier search or something like that meant?
Not that I care much, but I'm just wondering if this is just a typo.
stay in carrier search
+static void b43_nphy_write_clip_detection(struct b43_wldev *dev, u16 *vals)
We know that these values are the clip thresholds, so use a better variable
name, please.
+{
+b43_phy_write(dev, B43_NPHY_C1_CLIP1THRES, vals[0]);
+b43_phy_write(dev, B43_NPHY_C2_CLIP1THRES, vals[1]);
+}
+
+static void b43_nphy_read_clip_detection(struct b43_wldev *dev, u16 *vals)
+{
+vals[0] = b43_phy_read(dev, B43_NPHY_C1_CLIP1THRES);
+vals[1] = b43_phy_read(dev, B43_NPHY_C2_CLIP1THRES);
+}
+
+static u16 b43_nphy_classifier(struct b43_wldev *dev, u16 mask, u16 val)
+{
+u16 tmp;
+bool suspended = false;
+
+if (dev-dev-id.revision == 16 dev-mac_suspended == 0) {
Do not check for mac_suspended==0 here. b43_mac_suspended does this
internally.
+b43_mac_suspend(dev);
+suspended = true;
+}
+
+tmp = b43_phy_read(dev, B43_NPHY_CLASSCTL);
+tmp = (B43_NPHY_CLASSCTL_CCKEN | B43_NPHY_CLASSCTL_OFDMEN |
+B43_NPHY_CLASSCTL_WAITEDEN);
+tmp = ~mask;
+tmp |= (val mask);
+b43_phy_maskset(dev, B43_NPHY_CLASSCTL, 0xFFF8, tmp);
+
+if (suspended)
+b43_mac_enable(dev);
+
+return tmp;
+}
+
+static void b43_nphy_stay_carrier_search(struct b43_wldev *dev, bool enable)
+{
+struct b43_phy *phy = dev-phy;
+struct b43_phy_n *nphy = phy-n;
+
+if (enable) {
+u16 clip[] = { 0x, 0x };
+if (nphy-deaf_count++ == 0) {
+nphy-classifier_state = b43_nphy_classifier(dev, 0, 0);
+b43_nphy_classifier(dev, 0x7, 0);
+b43_nphy_read_clip_detection(dev, nphy-clip_state);
+b43_nphy_write_clip_detection(dev, clip);
+}
+b43_nphy_reset_cca(dev);
+} else {
+if (--nphy-deaf_count != 0) {
If this test logic correct? The following would make more sense to me:
if (--nphy-deaf_count == 0) {
It should be == 0. Specs match Broadcom code.
Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 2/5] b43: N-PHY: add b43_nphy_get_tx_gains (V2)
On 01/06/2010 02:57 PM, Rafał Miłecki wrote: V2: adjust to renamed function, fill index array Signed-off-by: Rafał Miłecki zaj...@gmail.com --- drivers/net/wireless/b43/phy_n.c | 81 Just a little nitpick to save John some work, and to keep the patches straight. When you submit a second (or later) version of a patch, indicate the version in the mail header as in [PATCH 2/5 V2] b43: The upstream software strips all of that out and the commit header will be clean. In addition, it is useful to state what is different below the --- marker. The software also strips that part of the patch - the permanent commit message should be devoid of the details of the review message. It is like making sausage! Better that the details are hidden. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY: Some fixes, notices
On 01/06/2010 03:30 PM, Gábor Stefanik wrote:
On Wed, Jan 6, 2010 at 10:09 PM, Rafał Miłecki zaj...@gmail.com wrote:
I've decided to made LP-PHY init code review for compatibility with specs
and found some issues.
We lack some code for higher PHY revisions (up from 2/3) and for some
specific boards. Also I've found little mistake in specs which Larry just
corrected.
Gábor: could you care for this parts of LP-PHY code?
So far I've only checked
lpphy_read_band_sprom(dev);
and
lpphy_baseband_init(dev);
I check for all conditions and operations (registers, masks, values). So far
didn't notice anything more serious than what's exposed by patch, so good
work Gábor :)
diff --git a/drivers/net/wireless/b43/phy_lp.c
b/drivers/net/wireless/b43/phy_lp.c
index 1e318d8..43a9fcc 100644
--- a/drivers/net/wireless/b43/phy_lp.c
+++ b/drivers/net/wireless/b43/phy_lp.c
@@ -198,6 +198,17 @@ static void lpphy_table_init(struct b43_wldev *dev)
lpphy_init_tx_gain_table(dev);
+ if (dev-phy.rev =2) {
+ int i;
+ for (i = 0; i 128; ++i) {
Two style comments:
1. Declare i at the beginning of the function.
2. The preferred style in b43 is i++.
+ /* TODO
+ Set the table offset to 576 + the loop index
+ Set the table data pointer to a u32 containing 127 -
loop index
+ Write the table
+ */
This can be implemented like this:
b43_lptab_write(dev, B43_LPTAB32(?, 576 + i), 127 - i);
Larry, what is the correct value for the ? (i.e. the table index)?
Please update the specs, this is missing.
Now fixed. If the PHY Revision is = 2, the table ID is 7, otherwise it is 0xA.
For the table in question, it should be 7.
Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 1/5] b43: N-PHY: implement b43_nphy_stay_in_carrier_search and it's calls (V2)
On 01/06/2010 04:49 PM, Gábor Stefanik wrote: 2010/1/6 Rafał Miłecki zaj...@gmail.com: W dniu 6 stycznia 2010 23:35 użytkownik Gábor Stefanik netrolller...@gmail.com napisał: 2010/1/6 Rafał Miłecki zaj...@gmail.com: V2: fix typo in deaf_count counting, improve b43_mac_[sr] calls, rename function. Thanks Michael! Signed-off-by: Rafał Miłecki zaj...@gmail.com --- drivers/net/wireless/b43/phy_n.c | 58 ++ drivers/net/wireless/b43/phy_n.h |3 ++ 2 files changed, 61 insertions(+), 0 deletions(-) snip Typo in title (it's vs. its) My gramma is far from perfect, thanks. I've yet to see a perfect grandmother... :-) My wife thinks she is perfect! Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 on Dell i1545 laptop
On 01/06/2010 05:17 PM, Jim Haynes wrote: On Tue, 5 Jan 2010, Larry Finger wrote: I have revised the wiki. You will not get the xxx15.fw files. Thanks, now I have the xxx15.fw files the wiki and then copy the files in /lib/firmware/b43/ to some removable device. After you boot the CD, then copy those files to the firmware directory in the ramfs. Once that is done, unload and reload (with modprobe) the b43 driver. You will now be able to access the network. If you install from the CD, you will need to copy those files to the hard drive. OK, I copied all the *15.fw files to /lib/firmware/b43 then did modprobe -r b43 modprobe b43 Then I tried ifconfig wlan0 up -is that what I should have tried? It responded with SIOCSIFFLAGS: Operation not possible due to RF-kill That is the correct step as long as you are not using NetworkManager. Now you need to flip your radio enable switch. If it is off, the radio is killed, i.e. RF-kill. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: N-PHY init: current code vs. specs
On 01/05/2010 11:21 AM, Michael Buesch wrote: Well, just do the thing that makes most sense. In general we all agree that we should _not_ implement crap, just because broadcom does so, if we can do better. So, in this case, if we can do a subfunction call and that function does make sense, we should do so for the sake of readability (I didn't look into detail, though.). Same goes for algorithms and stuff. If we realize that we can do better, do _not_ implement Broadcrap and instead implement a better version. I agree with Michael that we do not need to follow Broadcrap (nice phrase); however, as we usually have no idea of what is going on inside the chip, we do need to read/write exactly the same registers as they do without skipping any or touching any others. For the record, the specs will usually follow the Broadcrap way. I did come upon one exception recently. After quite a bit of decision making that did not touch any registers nor change any global variables, they suddenly tested for 2.4 GHz mode and exited if found. I moved that test to the beginning of the routine. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 on Dell i1545 laptop
On 01/05/2010 09:55 PM, Jim Haynes wrote: I'm not sure if this is a b43 problem or a Fedora problem. It is a problem with Broadcom. When I get the firmware from the web site I get ucode5.fw, ucode13.fw, ucode11.fw but no ucode15.fw(and other stuff with number 5, and 13) I have revised the wiki. You will not get the xxx15.fw files. Now I guess if I did have the firmware it wants, ucode15.fw, I don't know how to work that in to the live CD - maybe I'd have to install it on the hard drive, or maybe I have to get the Fedora people to add it to the build. The Fedora people do not have the right to distribute Broadcom firmware, which is why it is not on the live CD. What you need to do is run the procedure from the wiki and then copy the files in /lib/firmware/b43/ to some removable device. After you boot the CD, then copy those files to the firmware directory in the ramfs. Once that is done, unload and reload (with modprobe) the b43 driver. You will now be able to access the network. If you install from the CD, you will need to copy those files to the hard drive. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 on Dell i1545 laptop
On 01/04/2010 11:14 AM, Rafał Miłecki wrote: 2010/1/4 Jim Haynes jhhay...@earthlink.net: I've just joined the list, and most of the stuff is way over my head. Is there a list for b43 users? As you have noticed, this is a list for developers. The user-type questions are generally handled in distro forums. I just got a Dell i1545 laptop and put Fedora 12 on it. The current kernel is 2.6.31.9-174.fc12.x86_64 lspci says [14e4:4315] (rev 01) and the b43 web page says support is in progress but I don't see a date for that status. As Rafał told you, that driver is in kernel 2.6.32. I installed the firmware in /lib/firmware/b43 like the web page says dmesg reports b43-phy0: Broadcom 4312 WLAN found (core revision 15) b43-phy0: ERROR: FOUND UNSUPPORTED PHY (Analog 6, Type 5, Revision 1) b43: probe of ssb0:0 failed with error -95 Is there anything you need me to test for and report? Or anything I can do to get this working? Or should I just wait? (I have no pressing need for it to work just now) That is LP PHY based wireless card and LP has basic support in 2.6.32 kernel. You have .31 so it's unsupported PHY for you. After upgrading to 2.6.32 you should hopefully get stable but still low performance support for your card. As an alternative to switching to kernel 2.6.32, you could implement the compat-wireless package. As for performance, the 4315/b43 combination receives at a rate of about 20 Mb/s and sends at 12 Mb/s. This is not full 802.11g rate, but quite respectable. The connection is very stable. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC][RFH] Small fixes to N-PHY init
On 01/04/2010 11:16 AM, Rafał Miłecki wrote: Larry: could you just confirm my understanding of docs? Did you mean chipcommon core in that N-PHY init step? Yes, the reference is to a register in the chipcommon core. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: N-PHY init: current code vs. specs
On 01/04/2010 02:36 PM, Rafał Miłecki wrote: I try to update int b43_phy_initn(struct b43_wldev *dev) to match current specs. Currently it contains many operations/calls that I can not find in http://bcm-v4.sipsolutions.net/802.11/PHY/Init/N First I've just posted patch that removed //TODO: Spectral management. I don't see anything about spectral management in specs. Next there is a lot of code after b43_nphy_workarounds(dev); call that I can not recognize. Let's just take some lines for example: b43_nphy_reset_cca(dev); ssb_write32(dev-dev, SSB_TMSLOW, ...); b43_nphy_force_rf_sequence(...); b43_phy_read(dev, B43_NPHY_CLASSCTL); /* dummy read */ I don't see connection between that code and specs. Michael: I guess you're author of this code (phy_n.c came from nphy.c, not sure how to check log for not-existing file). Could you help me and explain this, please? I can answer this question. The original N PHY specs and the code generated from them were for a driver that is now 2 versions old. The main changes are due to later revisions of the N PHY, but there also seem to be some refactoring. To keep it straight, I am evolving the current specs to match the latest driver that we have available. Whenever you see code like the above that does not match the specs, you should probably rip it out. If you have any questions, please ask me if a given spec page is current. I have been trying to get initn and all the routines that it calls up to date, but this RE process is so mind-numbing that I can only work on it for so long. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: N-PHY init: current code vs. specs
On 01/04/2010 04:34 PM, Rafał Miłecki wrote: W dniu 4 stycznia 2010 21:36 użytkownik Rafał Miłecki zaj...@gmail.com napisał: Next there is a lot of code after b43_nphy_workarounds(dev); call that I can not recognize. Let's just take some lines for example: b43_nphy_reset_cca(dev); Actually specs still tell about resetting CCA, but that is done (in specs) without call to separated function (just part of init code): 29. Read PHY Register 0x01 and save in val 30. Write val | 0x4000 to PHY Register 0x1 31. Write val 0xBFFF to PHY Register 0x1 Should I strictly follow specs (put CCA reset directly in init code) or should I keep b43_nphy_reset_cca function and just modify if to match current specs? As long as all the register read/writes are the same, it doesn't really matter. You get to do what you want. If you deviate from the specs, just throw in a comment so that someone else knows what you did and why if looks different. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: The newest Macbook 13.3 wireless
On 01/02/2010 08:11 PM, Daniel Kuehn wrote: Hi, I am the (un)lucky owner of a Macbook of late 2009 model, which has a Broadcom combo card (BT + WLAN sharing 3 antennas) but neither the b43 or broadcom-sta support it, I just get invalid parameters or the interface disappears. Is there anyway I could help you guys with getting this wlan card to work? I could test experimental drivers or try to bash it to work or such, it would just be awesome if I could get it to work. The chip PCI ID is 14e4:4353 if that helps you any, its a wireless N card as I have understod it, but there exist no info that either confirm or discard the PCI ID as a WLAN card. I havent been able to get any info of which card this is supposed to be from broadcoms sortiment, I cannot find any of the cards listen on broadcoms homepage to match with this card. The Broadcom 5.10.56.46 that is the basis for my current reverse engineering effort supports that card. To the best of my knowledge, it is an 802.11n dual-band card. The coding effort to support N PHYs has just started. Of course, it could be an SSLPN PHY and the RE for them is not yet started. In any case, who knows when any code will be ready. Watch this mailing list for patches. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Fatal DMA error problem with netbook and BCM4312 - Test 3
On 12/28/2009 09:52 AM, Andrew Benton wrote: Sadly it does not work. Tested with the mainline kernel. The DMA errors persist. Shucks!!! I was hoping for a late Christmas present. Unfortunately, more coal in my stocking. As usual, thanks for testing. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Fatal DMA error problem with netbook and BCM4312 - Test 3
On 12/28/2009 12:33 PM, Michael Buesch wrote: On Monday 28 December 2009 05:49:14 Larry Finger wrote: +tmp = ~(SSB_IMCFGLO_SERTO | SSB_IMCFGLO_REQTO_SHIFT); This does not make any sense. Did you mean: + tmp = ~(SSB_IMCFGLO_SERTO | SSB_IMCFGLO_REQTO); +tmp |= 3; So you set SER-timeout to 3 and REQ-timeout to 0. Is that what we want? REQ=zero smells fishy to me, but if the broadcom code also does this, I'm OK with it. I did get that wrong. The Broadcom code does the equivalent of tmp = tmp ~0x77 | 3 which is what my code ended up doing by accident, but REQ is set to zero. Are these values discussed anywhere in the open? I have not found anything regarding the SSB configuration. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Problem with b43_get_and_map_ringmem()
Michael,
There is something a little funky with this routine. If the call to
__b43_get_and_map_ringmem() fails because the memory allocated is not within the
DMA region supported by the card, there is no way for execution to reach the
section that takes action to fix the problem. As you have probably seen, this is
likely the underlying cause of the regression reported in Bugzilla No. 14844.
Testing by the OP has not been done, but it fixed the same problem here.
Fixing this will likely be a two-step process. For 2.6.33, I am proposing the
following simple patch, which is essentially what is being tested:
Index: wireless-testing/drivers/net/wireless/b43/dma.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/dma.c
+++ wireless-testing/drivers/net/wireless/b43/dma.c
@@ -439,9 +439,14 @@ static void * b43_get_and_map_ringmem(st
dma_addr_t *dmaaddr, size_t size)
{
void *base;
+ gfp_t flags = GFP_KERNEL;
+ if (unlikely(ring-type == B43_DMA_30BIT))
+ flags |= GFP_DMA;
+ else if (unlikely(ring-type == B43_DMA_32BIT))
+ flags |= GFP_DMA32;
base = __b43_get_and_map_ringmem(ring, dmaaddr, size,
-GFP_KERNEL);
+flags);
if (!base) {
b43err(ring-dev-wl, Failed to allocate or map pages
for DMA ringmemory\n);
Comments?
For 2.6.34, a more complete rework is probably needed.
Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Fatal DMA error problem with netbook and BCM4312 - Test 3
Hi,
In the latest Broadcom driver, I found code that sets the timeout field of the
SSB configuration for some BCM4311 and all BCM4312 devices. Please test this
patch following a cold boot.
Thanks,
Larry
Index: wireless-testing/drivers/ssb/driver_pcicore.c
===
--- wireless-testing.orig/drivers/ssb/driver_pcicore.c
+++ wireless-testing/drivers/ssb/driver_pcicore.c
@@ -621,6 +621,14 @@ int ssb_pcicore_dev_irqvecs_enable(struc
tmp |= 0x40;
ssb_pcie_write(pc, 0x100, tmp);
}
+ if (bus-chip_id == 0x4312 ||
+ (bus-chip_id == 0x4311 bus-chip_rev == 2)) {
+ tmp = ssb_read32(pdev, SSB_IMCFGLO);
+ tmp = ~(SSB_IMCFGLO_SERTO | SSB_IMCFGLO_REQTO_SHIFT);
+ tmp |= 3;
+ ssb_write32(pdev, SSB_IMCFGLO, tmp);
+ ssb_commit_settings(bus);
+ }
}
pc-setup_done = 1;
out:
Index: wireless-testing/drivers/ssb/driver_chipcommon_pmu.c
===
--- wireless-testing.orig/drivers/ssb/driver_chipcommon_pmu.c
+++ wireless-testing/drivers/ssb/driver_chipcommon_pmu.c
@@ -424,9 +424,9 @@ static void ssb_pmu_resources_init(struc
switch (bus-chip_id) {
case 0x4312:
/* We keep the default settings:
-* min_msk = 0xCBB
* max_msk = 0x7
*/
+ min_msk = 0xCBB;
break;
case 0x4325:
/* Power OTP down later. */
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH][resend with linux-wireless] b43: N-PHY: clean table init, check PHY rev
On 12/23/2009 06:01 AM, Rafał Miłecki wrote:
It's just compilation-tested as I don't own N-PHY device yet (should
receive one for Christmas). Of course I enabled N-PHY in Kconfig.
I already sent this to bcm43xx-dev but didn't get any review. Michael
told me to send it to you John and to linux-wireless. Is there anyone
how could review/ack my patch?
From 6800722c2fda0e302d7c759a5f2a993503b6581a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= zaj...@gmail.com
mailto:zaj...@gmail.com
Date: Tue, 22 Dec 2009 02:27:21 +0100
Subject: [PATCH] b43: N-PHY: clean table init, check PHY rev
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Move table init to tables_nphy.c, detect newer PHY which use different init
Signed-off-by: Rafał Miłecki zaj...@gmail.com mailto:zaj...@gmail.com
---
drivers/net/wireless/b43/phy_n.c | 43
drivers/net/wireless/b43/tables_nphy.c | 48
drivers/net/wireless/b43/tables_nphy.h |4 ++-
3 files changed, 58 insertions(+), 37 deletions(-)
diff --git a/drivers/net/wireless/b43/phy_n.c
b/drivers/net/wireless/b43/phy_n.c
index 992318a..23cef71 100644
--- a/drivers/net/wireless/b43/phy_n.c
+++ b/drivers/net/wireless/b43/phy_n.c
@@ -197,44 +197,15 @@ void b43_nphy_radio_turn_off(struct b43_wldev *dev)
~B43_NPHY_RFCTL_CMD_EN);
}
-#define ntab_upload(dev, offset, data) do { \
- unsigned int i; \
- for (i = 0; i (offset##_SIZE); i++) \
- b43_ntab_write(dev, (offset) + i, (data)[i]); \
- } while (0)
-
-/* Upload the N-PHY tables. */
+/* Upload the N-PHY tables.
+ * http://bcm-v4.sipsolutions.net/802.11/PHY/N/InitTables
+ */
static void b43_nphy_tables_init(struct b43_wldev *dev)
{
- /* Static tables */
- ntab_upload(dev, B43_NTAB_FRAMESTRUCT, b43_ntab_framestruct);
- ntab_upload(dev, B43_NTAB_FRAMELT, b43_ntab_framelookup);
- ntab_upload(dev, B43_NTAB_TMAP, b43_ntab_tmap);
- ntab_upload(dev, B43_NTAB_TDTRN, b43_ntab_tdtrn);
- ntab_upload(dev, B43_NTAB_INTLEVEL, b43_ntab_intlevel);
- ntab_upload(dev, B43_NTAB_PILOT, b43_ntab_pilot);
- ntab_upload(dev, B43_NTAB_PILOTLT, b43_ntab_pilotlt);
- ntab_upload(dev, B43_NTAB_TDI20A0, b43_ntab_tdi20a0);
- ntab_upload(dev, B43_NTAB_TDI20A1, b43_ntab_tdi20a1);
- ntab_upload(dev, B43_NTAB_TDI40A0, b43_ntab_tdi40a0);
- ntab_upload(dev, B43_NTAB_TDI40A1, b43_ntab_tdi40a1);
- ntab_upload(dev, B43_NTAB_BDI, b43_ntab_bdi);
- ntab_upload(dev, B43_NTAB_CHANEST, b43_ntab_channelest);
- ntab_upload(dev, B43_NTAB_MCS, b43_ntab_mcs);
-
- /* Volatile tables */
- ntab_upload(dev, B43_NTAB_NOISEVAR10, b43_ntab_noisevar10);
- ntab_upload(dev, B43_NTAB_NOISEVAR11, b43_ntab_noisevar11);
- ntab_upload(dev, B43_NTAB_C0_ESTPLT, b43_ntab_estimatepowerlt0);
- ntab_upload(dev, B43_NTAB_C1_ESTPLT, b43_ntab_estimatepowerlt1);
- ntab_upload(dev, B43_NTAB_C0_ADJPLT, b43_ntab_adjustpower0);
- ntab_upload(dev, B43_NTAB_C1_ADJPLT, b43_ntab_adjustpower1);
- ntab_upload(dev, B43_NTAB_C0_GAINCTL, b43_ntab_gainctl0);
- ntab_upload(dev, B43_NTAB_C1_GAINCTL, b43_ntab_gainctl1);
- ntab_upload(dev, B43_NTAB_C0_IQLT, b43_ntab_iqlt0);
- ntab_upload(dev, B43_NTAB_C1_IQLT, b43_ntab_iqlt1);
- ntab_upload(dev, B43_NTAB_C0_LOFEEDTH, b43_ntab_loftlt0);
- ntab_upload(dev, B43_NTAB_C1_LOFEEDTH, b43_ntab_loftlt1);
+ if (dev-phy.rev 3)
+ b43_nphy_rev0_1_2_table_init(dev);
+ else
+ b43_nphy_rev3plus_table_init(dev);
}
static void b43_nphy_workarounds(struct b43_wldev *dev)
diff --git a/drivers/net/wireless/b43/tables_nphy.c
b/drivers/net/wireless/b43/tables_nphy.c
index 4e23363..d709555 100644
--- a/drivers/net/wireless/b43/tables_nphy.c
+++ b/drivers/net/wireless/b43/tables_nphy.c
@@ -2474,3 +2474,51 @@ void b43_ntab_write(struct b43_wldev *dev, u32
offset, u32 value)
/* Some compiletime assertions... */
assert_ntab_array_sizes();
}
+
+#define ntab_upload(dev, offset, data) do { \
+ unsigned int i; \
+ for (i = 0; i (offset##_SIZE); i++) \
+ b43_ntab_write(dev, (offset) + i, (data)[i]); \
+ } while (0)
+
+void b43_nphy_rev0_1_2_table_init(struct b43_wldev *dev)
+{
+ /* Static tables */
+ ntab_upload(dev, B43_NTAB_FRAMESTRUCT, b43_ntab_framestruct);
+ ntab_upload(dev, B43_NTAB_FRAMELT, b43_ntab_framelookup);
+ ntab_upload(dev, B43_NTAB_TMAP, b43_ntab_tmap);
+ ntab_upload(dev, B43_NTAB_TDTRN, b43_ntab_tdtrn);
+ ntab_upload(dev, B43_NTAB_INTLEVEL, b43_ntab_intlevel);
+ ntab_upload(dev, B43_NTAB_PILOT, b43_ntab_pilot);
+ ntab_upload(dev, B43_NTAB_PILOTLT, b43_ntab_pilotlt);
+ ntab_upload(dev, B43_NTAB_TDI20A0, b43_ntab_tdi20a0);
+ ntab_upload(dev, B43_NTAB_TDI20A1, b43_ntab_tdi20a1);
+ ntab_upload(dev, B43_NTAB_TDI40A0, b43_ntab_tdi40a0);
+ ntab_upload(dev, B43_NTAB_TDI40A1, b43_ntab_tdi40a1);
+ ntab_upload(dev, B43_NTAB_BDI, b43_ntab_bdi);
+ ntab_upload(dev, B43_NTAB_CHANEST, b43_ntab_channelest);
+ ntab_upload(dev, B43_NTAB_MCS, b43_ntab_mcs);
+
+ /*
Fatal DMA error problem with netbook and BCM4312 - Test 2
Hi,
I placed a number of test prints in my system trying to find where a
DMA data error might occur. In doing so, I found that 3 slots in the
DMA header cache cross a page boundary. Such a situation is allowed on
my system, but it might be forbidden on Atom processors. Please try
this really ugly hack to see if it makes any difference.
Thanks,
Larry
Index: wireless-testing/drivers/net/wireless/b43/dma.h
===
--- wireless-testing.orig/drivers/net/wireless/b43/dma.h
+++ wireless-testing/drivers/net/wireless/b43/dma.h
@@ -160,7 +160,7 @@ struct b43_dmadesc_generic {
#define B43_DMA0_RX_FRAMEOFFSET30
/* DMA engine tuning knobs */
-#define B43_TXRING_SLOTS 256
+#define B43_TXRING_SLOTS 74
#define B43_RXRING_SLOTS 64
#define B43_DMA0_RX_BUFFERSIZE IEEE80211_MAX_FRAME_LEN
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Fatal DMA error problem with netbook and BCM4312 - Test 2
On 12/21/2009 03:47 PM, Michael Buesch wrote: On Monday 21 December 2009 22:31:10 Larry Finger wrote: Hi, I placed a number of test prints in my system trying to find where a DMA data error might occur. In doing so, I found that 3 slots in the DMA header cache cross a page boundary. Such a situation is allowed on my system, but it might be forbidden on Atom processors. Please try this really ugly hack to see if it makes any difference. First thing is that the DMA buffers are allowed to cross any boundary (and the header is just a buffer). The boundary requirements only apply to the memory holding the descriptors. That is what we will test for the Atom. I know it doesn't matter for my CPU, but ... Second thing is: How does the patch prevent a boundary crossing? The number of slots is reduced to the point that the header cache fits in one page, just as the RX header cache does. As I said, this is really ugly. If this fixes the problem, then a more elegant fix will be needed. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Fatal DMA error problem with netbook and BCM4312 - Test 2
On 12/21/2009 04:11 PM, Michael Buesch wrote: On Monday 21 December 2009 23:02:39 Larry Finger wrote: On 12/21/2009 03:47 PM, Michael Buesch wrote: On Monday 21 December 2009 22:31:10 Larry Finger wrote: Hi, I placed a number of test prints in my system trying to find where a DMA data error might occur. In doing so, I found that 3 slots in the DMA header cache cross a page boundary. Such a situation is allowed on my system, but it might be forbidden on Atom processors. Please try this really ugly hack to see if it makes any difference. First thing is that the DMA buffers are allowed to cross any boundary (and the header is just a buffer). The boundary requirements only apply to the memory holding the descriptors. That is what we will test for the Atom. I know it doesn't matter for my CPU, but ... I'm pretty sure the broadcom DMA engine is not _that_ braindead. (It is pretty weird, but not _that_ weird). It would effectively mean that we'd have to bouncebuffer _every_ TX packet. I'm not that worried about the Broadcom implementation as I am about the support chips on the Netbooks. Second thing is: How does the patch prevent a boundary crossing? The number of slots is reduced to the point that the header cache fits in one page, just as the RX header cache does. As I said, this is really ugly. If this fixes the problem, then a more elegant fix will be needed. But the allocation is not required to be aligned to the page start. The first header might start at offset 4000 of a page, so you cross the page border after the first few headers. Here, it was slot 74 that crossed the page boundary. At 110 bytes per every 2 slots, that works out to 4070 bytes for 0 - 73. From that, I infer that the cache starts on a page boundary. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Fatal DMA error problem with netbook and BCM4312 - Test 2
On 12/21/2009 04:18 PM, William Bourque wrote: Larry Finger wrote: Hi, I placed a number of test prints in my system trying to find where a DMA data error might occur. In doing so, I found that 3 slots in the DMA header cache cross a page boundary. Such a situation is allowed on my system, but it might be forbidden on Atom processors. Please try this really ugly hack to see if it makes any difference. I confirm that the DMA error is still present with this patch. Thanks for testing. The results are as Michael expected, and as I feared. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: N-PHY: clean table init, check PHY rev
On 12/21/2009 07:40 PM, Rafał Miłecki wrote: It's just compilation-tested as I don't own N-PHY device yet (should receive one for Christmas). Not sure if we even support SSB used for N-PHY cards. I think N PHY cards are supported by SSB. There may be some things to be extracted from the SPROM, but otherwise it should be OK. To get N PHY stuff to compile, you need the following patch: Index: wireless-testing/drivers/net/wireless/b43/Kconfig === --- wireless-testing.orig/drivers/net/wireless/b43/Kconfig +++ wireless-testing/drivers/net/wireless/b43/Kconfig @@ -81,7 +81,7 @@ config B43_SDIO config B43_NPHY bool Pre IEEE 802.11n support (BROKEN) - depends on B43 EXPERIMENTAL BROKEN + depends on B43 EXPERIMENTAL ---help--- Support for the IEEE 802.11n draft. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Clear PCI configuration reg. 0x41 to avoid interference with C3 processor state
On 12/20/2009 03:53 PM, Luis R. Rodriguez wrote: I should note 0x40 starts with vendor specific PCI config space so you cannot guarantee different PCI devices use 0x41 will be used the same for different devices. The documentation for the ath9k PCI-E devices used that entry for something completely different but what I did not do is try to very and ensure PCI devices do not use it it for the same. I am told though that although this is PCI vendor space some devices may still use similar private PCI config spaces on different devices which just follows a practice. At this point we now have not only b43, ipw and ath9k follow this but also prism54 and I think p54 uses this. I'll note I *highly* doubt this is used for the same thing on all these devices and was just code copied from other Linux drivers. In the case of Atheros Linux drivers I know it was copied form Intel drivers, which is why I started questioning it all. Anyway, if it helps, that's great :) but it cannot be concluded its all for the same thing unless you have proper documentation as this is in PCI vendor space which *can* vary depending on device and vendor. Larry, does this actually fix something or is this code purely speculative? I got on this idea because I logged all PCI configuration read/write values and discovered that the Broadcom wl driver did a read/write on this location. A later examination of the open-source part of that driver showed that they copied it from ipw2100. If anyone knows the layout of the private area of the configuration space, they should; however, they may be just propagating the code as you say. This change does not fix the DMA error problem with Atom processors in Netbooks. We have had one report of DMA errors in a Core Duo system - AFAIK, the only non-Atom processor with the problem. That user has not tested this patch. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Clear PCI configuration reg. 0x41 to avoid interference with C3 processor state
On 12/19/2009 11:01 PM, Larry Finger wrote: In exploring the cause of DMA errors for BCM4312 devices on Atom processors, other drivers that work write to PCI configuration register 0x40. The code fragment below was found in the open-code portion of the Broadcom hybrid wl driver. It is also used in the ipw2100 and ath9k drivers. In the latter case, it had been removed and later restored to prevent fatal interrupt errors. Signed-off-by: Larry Finger larry.fin...@lwfinger.net --- John, I think this is 2.6.34 material. By itself, it does not affect the DMA errors in BCM4312 devices. If it is found to help in the resolution of that long-standing problem, I will request a change in the status. Larry --- John, Please consider this patch retracted. If I actually find that it helps some system, I'll resubmit it then. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: PCI config register 0x40
On 12/19/2009 04:11 AM, Michael Buesch wrote: Well, if 0x40 is used as RETRY_TIMEOUT in ipw, that doesn't mean it's the same in b43. Is the 0x40 register standardized in any way? According to the Wikipedia article on PCI configuration space registers, only up to 0x3F is standardized. There is, however, an interesting article in http://lkml.indiana.edu/hypermail/linux/kernel/0906.3/03376.html. In the ath9k driver, similar code was removed in a clean-up, but had to be restored as some cards got PCI fatal interrupts. I also found a similar fragment in the C source part of the Broadcom hybrid driver. And if you do a patch, don't put it into ssb. Put it into b43. I will put it in b43 as you request. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: PCI config register 0x40
On 12/19/2009 04:11 AM, Michael Buesch wrote: And if you do a patch, don't put it into ssb. Put it into b43. One further question about putting the patch into b43. Apparently, register 0x40 is not preserved across a suspend/resume to disk. In all the drivers that use this code, 0x40 is modified in the .probe and .resume routines. As b43 does the resume indirectly through mac80211, an alternate location is needed. It looks to me that placing the code in b43_wireless_core_init() would satisfy both needs. Is that correct? Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Fatal DMA error problem with netbook and BCM4312 - another test
Hi, If possible, please test this patch starting from a cold boot. It is a variation of something we tried earlier, but enough different to try it. Thanks, Larry In exploring the cause of DMA errors for BCM4312 devices on Atom processors, other drivers that work write to PCI configuration register 0x40. The code fragment below was found in the open-code portion of the Broadcom hybrid wl driver. It is also used in the ipw2100 and ath9k drivers. In the latter case, it had been removed and later restored to prevent fatal interrupt errors. Signed-off-by: Larry Finger larry.fin...@lwfinger.net --- Index: wireless-testing/drivers/net/wireless/b43/main.c === --- wireless-testing.orig/drivers/net/wireless/b43/main.c +++ wireless-testing/drivers/net/wireless/b43/main.c @@ -4292,6 +4292,15 @@ static int b43_wireless_core_init(struct setup_struct_wldev_for_init(dev); phy-ops-prepare_structs(dev); + /* We disable the RETRY_TIMEOUT register (0x41) to keep +* PCI Tx retries from interfering with C3 CPU state +* This code fragment found in the Broadcom hybrid wl driver +*/ + pci_read_config_dword(bus-host_pci, 0x40, tmp); + if ((tmp 0xff00) != 0) + pci_write_config_dword(bus-host_pci, 0x40, tmp + ~(0xff00)); + /* Enable IRQ routing to this device. */ ssb_pcicore_dev_irqvecs_enable(bus-pcicore, dev-dev); ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Fatal DMA error problem with netbook and BCM4312 - another test
On 12/19/2009 05:11 PM, Andrew Benton wrote: On 19/12/09 19:55, Chris Vine wrote: I applied this to 2.6.32.2 and it didn't help with the DMA errors I am afraid. Chris Same here, the patch didn't prevent the DMA errors, however, I did notice that it only reported the error once, it didn't keep trying to reload the firmware. The change that bails out after one fatal DMA error is a separate one. As there is no chance of recovering, we decided not to spam the logs. Thanks for testing. I had little expectation, but this one may be needed in conjunction with something else. Back to the grindstone. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Fatal DMA error problem with netbook and BCM4312 - another test
On 12/19/2009 10:15 PM, William Bourque wrote: Larry Finger wrote: Hi, If possible, please test this patch starting from a cold boot. It is a variation of something we tried earlier, but enough different to try it. Thanks, Larry A little late but I just tested and I have the same bug. However, unlike Andrew, the error keep repeating as before... He is using wireless-testing or a recent mainline kernel. That is where the change I described is installed. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: Clear PCI configuration reg. 0x41 to avoid interference with C3 processor state
In exploring the cause of DMA errors for BCM4312 devices on Atom
processors, other drivers that work write to PCI configuration
register 0x40. The code fragment below was found in the open-code
portion of the Broadcom hybrid wl driver. It is also used in the
ipw2100 and ath9k drivers. In the latter case, it had been removed
and later restored to prevent fatal interrupt errors.
Signed-off-by: Larry Finger larry.fin...@lwfinger.net
---
John,
I think this is 2.6.34 material. By itself, it does not affect the
DMA errors in BCM4312 devices. If it is found to help in the resolution
of that long-standing problem, I will request a change in the status.
Larry
---
Index: wireless-testing/drivers/net/wireless/b43/main.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/main.c
+++ wireless-testing/drivers/net/wireless/b43/main.c
@@ -4292,6 +4292,15 @@ static int b43_wireless_core_init(struct
setup_struct_wldev_for_init(dev);
phy-ops-prepare_structs(dev);
+ /* We disable the RETRY_TIMEOUT register (0x41) to keep
+* PCI Tx retries from interfering with C3 CPU state
+*/
+ if (bus-bustype == SSB_BUSTYPE_PCI) {
+ pci_read_config_dword(bus-host_pci, 0x40, tmp);
+ pci_write_config_dword(bus-host_pci, 0x40, tmp
+ ~(0xff00));
+ }
+
/* Enable IRQ routing to this device. */
ssb_pcicore_dev_irqvecs_enable(bus-pcicore, dev-dev);
Index: wireless-testing/drivers/ssb/pcihost_wrapper.c
===
--- wireless-testing.orig/drivers/ssb/pcihost_wrapper.c
+++ wireless-testing/drivers/ssb/pcihost_wrapper.c
@@ -35,6 +35,7 @@ static int ssb_pcihost_resume(struct pci
{
struct ssb_bus *ssb = pci_get_drvdata(dev);
int err;
+ u32 val;
pci_set_power_state(dev, 0);
err = pci_enable_device(dev);
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: ssb: ERROR: PLL init unknown for device 4322
On 12/18/2009 10:19 AM, Gábor Stefanik wrote: Is there anything that I can try or any information that I can provide to make it work? BCM4322 is an N-PHY device, which is not yet supported; it will probably be the next thing I will implement, once Larry completes the reverse engineering for this PHY. Besides the type 4 N PHY, I also have to do the RE for the type 6 PHY, which is known as an SSLPN PHY (single-stream low-power N PHY). :) To make your 4322 work now, you need to implement the Broadcom hybrid STA wl driver. You can build that from files obtained from Broadcom, or many distros have a pre-made package. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
PCI config register 0x40
Michael, As you may recall, I dumped writes to the PCI config space for both b43 and the wl driver. I found that wl wrote to address 0x40. In looking around other drivers, I found the following fragment in ipw2100: /* We disable the RETRY_TIMEOUT register (0x41) to keep * PCI Tx retries from interfering with C3 CPU state */ pci_read_config_dword(pci_dev, 0x40, val); if ((val 0xff00) != 0) pci_write_config_dword(pci_dev, 0x40, val 0x00ff); There is a similar fragment in the resume routine. This change is probably not responsible for the DMA errors in the 4315, but there still could be some affect. Do you want to prepare a patch for ssb, or should I do it? Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
