Re: b43 on HP nx6325 w/ openSUSE 10.3 (x86_64)
On Monday, 5 of November 2007, Larry Finger wrote: > Rafael J. Wysocki wrote: > > Hi, > > > > I'm trying to make the b43 driver work on an HP nx6325 with openSUSE 10.3 > > (64-bit). In short, it sort of works, but some things are a bit ugly. > > > > The kernel is the current -git (approx. 2.6.24-rc1-git13) with the following > > extra patches applied: > > > > b43: Fix rfkill callback deadlock > > b43: debugfs SHM read buffer overrun fix > > b43: Rewrite and fix rfkill init > > > > and I'm using the firmware from > > http://downloads.openwrt.org/sources/broadcom-wl-4.80.53.0.tar.bz2 > > > > Here's the debug info from dmesg: > > > > b43-phy1: Broadcom 4311 WLAN found > > b43-phy1 debug: Found PHY: Analog 4, Type 2, Revision 8 > > b43-phy1 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 > > b43-phy1 debug: Loading firmware version 351.126 (2006-07-29 05:54:02) > > Registered led device: b43-phy1:tx > > Registered led device: b43-phy1:rx > > b43-phy1 debug: Chip initialized > > b43-phy1 debug: 32-bit DMA initialized > > b43-phy1 debug: Wireless interface started > > b43-phy1 debug: Adding Interface type 2 > > > > Now, the first problem is that the card seems to lose frames from time to > > time. This is visible in the output of mtr and while trying to transfer > > large > > files using scp. With scp the transfer just stalls and stays this way > > although > > the other end is pingable etc. (eg. attempting to transfer more than 400 MB > > at > > once triggers this 100% of the time). > > > > If you can suggest some more specific tests to me, I'll run them and report > > back. > > > > The second problem is that YaST is apparently unable to detect the device, > > which sort of sucks, because it leads to configuration problems (basically, > > you > > need to set up everything manually). Evidently, udev manages to handle it, > > so > > this may be related to HAL. Anyway, it looks like the problem is related to > > the fact that the device is not present under /sys/bus/pci/devices/ > > directly, > > but you need to go through the ssb0:0 subdirectory to get to it. > > > > Do you have any ideas how to tell the user space stuff where the devices is > > in sysfs? > > Your configuration is exactly like mine - openSUSE 10.3, x86_64 with Linus's > latest git, and a 4311. > I have not used mtr or scp and cannot comment on your transfer problems. That may be AP-related, but I had no such problems with the bcm43xx used previously on the same hardware w/ the same AP. > I have had 0 problems configuring the device with YaST. Hm, I wonder what I've done wrong, then. :-) Can you send me /etc/sysconfig/network/ifcfg-wlan0 (or whatever the card is visible as on your system) from the x86_64 laptop? > On the x86_64 laptop, I let NetworkManager control the wireless > connection, but I have also used the traditional ifup/ifdown method. On an > i386 system, I use > ifup/ifdown as I don't run X on that machine. Both make fast connections. Well, finally I did configure the card with YaST, but I had to manually add it to the list. ifup/ifdown works, but I haven't tried NetworkManager yet. Greetings, Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC] ssb: Add code for SPROM Rev 4
On Monday 05 November 2007 17:03:47 Larry Finger wrote: > u8 path_data0[SPROM_PATH_DATA_SIZE]; > u8 path_data1 ... > > where SPROM_PATH_DATA_SIZE = 0x26. Once we see how the data are used, it may > make more sense to have > these data be u16, > or even a union so that we can have it both ways. ^^ Whoops, endianess broken :) > I'm not sure we need a separate "valid bit" for path data. In the sprom that > we are working with, Ok, even better then. The "valid bit" was just an idea for stuff in the sprom which cannot be determined valid or not in another way. > As I said earlier, my current patch is working OK for present needs. Once we > come to an agreement > regarding the sprom data structures, I will begin implementing them. As I see > it, conversion will be > a 3-step process. We will need a patch to add the new structure, a second to > populate that > structure, patches to convert b44, b43, and b43legacy to use the new data, > and a final patch to > remove the old structure. In this manner, bisection will be supported. cool :) Are you going to try a redesign of the structure? I'm not too motivated to do it, as I don't know too much about the v4 sprom, yet. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC] ssb: Add code for SPROM Rev 4
Am Samstag, 3. November 2007 schrieb Larry Finger: > The BCM4328 has a revision 4 SPROM. The necessary changes to handle the > layout and different size of this revision are implemented. The size of > the SPROM is now stored in the ssb_bus struct and used from that location > whenever possible. For those routines that need the size, but do not have > access to that struct, a size argument is added. > > Recognition of the PCI_ID of the BCM4328 is also implemented. Note that > the PCI_ID is 0x4328, but the chipid is 0x4321. > > This code has been tested by Michael Gerdau <[EMAIL PROTECTED]>. > > Signed-off-by: Larry Finger <[EMAIL PROTECTED]> > --- > > Michael, > > Please comment on this patch. It is intended to be applied to > wireless-2.6/everything. This code works for me (AFAICT). Therefor Acked-by: Michael Gerdau <[EMAIL PROTECTED]> Best, Michael -- Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver signature.asc Description: This is a digitally signed message part. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC] ssb: Add code for SPROM Rev 4
Michael Buesch wrote:
> Larry, I did not forget your patch.
> But I need to think a little bit more about this.
I knew that this one would take some time.
> The union above is not really what I'd like to have here. In fact,
> I think to get the v4 sprom implemented the sprom struct has to be
> redesigned.
The way I implemented it was as a "straw man" designed to get shot down. :-)
The only benefit it had
was that this format has allowed my tester to get started enough to get b43
loaded. He is rapidly
implementing that part of the specs that are needed to get the BCM4328 with an
N PHY working in G mode.
> I think we must leave the path of partitioning the sprom struct into
> versions, because that obviously doesn't work anymore.
> Instead, I think we must develop _one_ common struct that is capable
> of holding the information from any sprom. (Note that the struct layout
> does not need to reflect the real hardware layout).
>
> And I think we should also remove the fields that are not needed at all,
> like the PCI ID stuff.
I agree.
> something like this:
>
>
> struct ssb_sprom_pathvar {
> bool this_pathvar_is_available;
>
> ...foobar data
> };
>
> struct ssb_sprom {
> u8 wl_mac_addr[ETH_ALEN];
> u8 eth0_mac_addr[ETH_ALEN];
> u8 eth1_mac_addr[ETH_ALEN];
>
> ...
>
> u8 gpio0;
> u8 gpio1;
> ...
>
> antennagain...
>
> struct ssb_sprom_pathvar pv0;
> struct ssb_sprom_pathvar pv1;
I think this section can be
u8 path_data0[SPROM_PATH_DATA_SIZE];
u8 path_data1 ...
where SPROM_PATH_DATA_SIZE = 0x26. Once we see how the data are used, it may
make more sense to have
these data be u16, or even a union so that we can have it both ways.
> ...
> };
>
> Note that I did _not_ look closely at the pathvar stuff, so this
> might be a bad idea to design it this way.
> But the point I was going to make with that was; we probably need
> some "this data is valid" bits for different parts of the sprom
> struct, as for example v1-3 don't have these pathvars (So the drivers
> must be told it's invalid data).
> The reason for all this "valid-bit" stuff is that I think we should
> remove any sprom-versioning knowledge from the drivers. That
> should be abstracted.
I agree.
> Any idea on how to improve that?
I'm not sure we need a separate "valid bit" for path data. In the sprom that we
are working with,
only paths 1 & 2 are implemented - the paths 3 & 4 region contains all 1's just
like any
unimplemented sprom data. It should be OK to initialize the first word of each
path to 0x to
indicate it is unused.
To let you know how the specs translate into a device, here is the dump of the
BCM4328 sprom:
ssb: SPROM r4 dump
ssb: 0x: 0x2801 0x 0x0009 0x1028 0x 0x0DBE 0xFF00 0x2BC4
ssb: 0x0010: 0x2A64 0x2964 0x2C64 0x3CE7 0x 0x 0x 0x
ssb: 0x0020: 0x4328 0x8000 0x0002 0x 0x1001 0x1800 0x 0x
ssb: 0x0030: 0x 0x 0x 0x 0x 0x 0x 0x
ssb: 0x0040: 0x5372 0x004C 0x4A01 0x 0x0004 0x 0x0019 0x7DA5
ssb: 0x0050: 0x1912 0x 0x0001 0x83FF 0x 0x 0x0303 0x0202
ssb: 0x0060: 0x 0x3437 0x5B5B 0x1420 0x5B5B 0x0D0C 0x5B5B 0x1A1E
ssb: 0x0070: 0x5B5B 0x3844 0x3838 0x 0x 0x 0x 0x
ssb: 0x0080: 0x3E4E 0xFEC6 0x15D3 0xFB3D 0x 0x3E3C 0x3C3C 0xFE6C
ssb: 0x0090: 0x1664 0xFA7B 0x 0xFE37 0x1401 0xFAE7 0x 0xFE5A
ssb: 0x00A0: 0x147E 0xFAC7 0x 0x 0x 0x 0x 0x3E4E
ssb: 0x00B0: 0xFEC1 0x15BC 0xFB2F 0x 0x3E3C 0x3C3C 0xFE69 0x1608
ssb: 0x00C0: 0xFA81 0x 0xFE2A 0x1321 0xFB0B 0x 0xFE66 0x1595
ssb: 0x00D0: 0xFA88 0x 0x 0x 0x 0x 0x 0x
ssb: 0x00E0: 0x 0x 0x 0x 0x 0x 0x 0x
ssb: 0x00F0: 0x 0x 0x 0x 0x 0x 0x 0x
ssb: 0x0100: 0x 0x 0x 0x 0x 0x 0x 0x
ssb: 0x0110: 0x 0x 0x 0x 0x 0x 0x 0x
ssb: 0x0120: 0x 0x 0x 0x 0x 0x 0x 0x
ssb: 0x0130: 0x 0x 0x 0x 0x 0x 0x 0x
ssb: 0x0140: 0x 0x 0x 0x 0x 0x 0x 0x
ssb: 0x0150: 0x 0x 0x 0x 0x 0x 0x 0x
ssb: 0x0160: 0x 0x 0x 0x 0x 0x 0x 0x
ssb: 0x0170: 0x 0x 0x 0x 0x 0x 0x 0x
ssb: 0x0180: 0x 0x 0x 0x 0x 0x 0x 0x
ssb: 0x0190: 0x 0x 0x 0x 0x 0x 0x 0x
ssb: 0x01A0: 0x 0x 0x 0x 0x 0x 0x 0x
ssb: 0x01B0: 0x 0x 0x 0x9404
As I said earlier, my current patch is working OK for present needs. Once we
come to an agreement
regarding the sprom data structures, I will begin implementing them. As I see
it, conversion will be
a 3-step process. We will need a patch to add the new structure, a second to
populate that
structure, patches to convert b44, b
Re: [RFC] ssb: Add code for SPROM Rev 4
On Saturday 03 November 2007 16:19:46 Larry Finger wrote:
> The BCM4328 has a revision 4 SPROM. The necessary changes to handle the
> layout and different size of this revision are implemented. The size of
> the SPROM is now stored in the ssb_bus struct and used from that location
> whenever possible. For those routines that need the size, but do not have
> access to that struct, a size argument is added.
>
> Recognition of the PCI_ID of the BCM4328 is also implemented. Note that
> the PCI_ID is 0x4328, but the chipid is 0x4321.
>
> This code has been tested by Michael Gerdau <[EMAIL PROTECTED]>.
>
> Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
> ---
> Index: wireless-2.6/include/linux/ssb/ssb.h
> ===
> --- wireless-2.6.orig/include/linux/ssb/ssb.h
> +++ wireless-2.6/include/linux/ssb/ssb.h
> @@ -79,7 +79,39 @@ struct ssb_sprom_r3 {
> };
>
> struct ssb_sprom_r4 {
> - /* TODO */
> + u16 pci_spid; /* Subsystem Product ID for PCI */
> + u16 pci_svid; /* Subsystem Vendor ID for PCI */
> + u16 pci_pid;/* Product ID for PCI */
> + u8 il0mac[6]; /* MAC address for 802.11b/g */
> + u8 et0mac[6]; /* MAC address for Ethernet */
> + u8 et1mac[6]; /* MAC address for 802.11a */
> + u8 et0phyaddr:5;/* MII address for enet0 */
> + u8 et1phyaddr:5;/* MII address for enet1 */
> + u8 et0mdcport:1;/* MDIO for enet0 */
> + u8 et1mdcport:1;/* MDIO for enet1 */
> + u8 board_rev; /* Board revision */
> + u8 country_code:4; /* Country Code */
> + u8 antenna_a:2; /* Antenna 0/1 available for A-PHY */
> + u8 antenna_bg:2;/* Antenna 0/1 available for B-PHY and G-PHY */
> + u16 pa0b0;
> + u16 pa0b1;
> + u16 pa0b2;
> + u16 pa1b0;
> + u16 pa1b1;
> + u16 pa1b2;
> + u8 gpio0; /* GPIO pin 0 */
> + u8 gpio1; /* GPIO pin 1 */
> + u8 gpio2; /* GPIO pin 2 */
> + u8 gpio3; /* GPIO pin 3 */
> + u16 maxpwr_a; /* A-PHY Amplifier Max Power (in dBm Q5.2) */
> + u16 maxpwr_bg; /* B/G-PHY Amplifier Max Power (in dBm Q5.2) */
> + u8 itssi_a; /* Idle TSSI Target for A-PHY */
> + u8 itssi_bg;/* Idle TSSI Target for B/G-PHY */
> + u16 boardflags_lo; /* Boardflags (low 16 bits) */
> + u8 antenna_gain_a; /* A-PHY Antenna gain (in dBm Q5.2) */
> + u8 antenna_gain_bg; /* B/G-PHY Antenna gain (in dBm Q5.2) */
> + /* The variables above this point must match those of ssb_sprom_r1 */
> + /* TODO - add any special ssb_sprom_r4 variables below this point. */
> };
>
> struct ssb_sprom {
> @@ -288,6 +320,7 @@ struct ssb_bus {
> /* ID information about the Chip. */
> u16 chip_id;
> u16 chip_rev;
> + u16 sprom_size; /* number of words in sprom */
> u8 chip_package;
>
> /* List of devices (cores) on the backplane. */
Larry, I did not forget your patch.
But I need to think a little bit more about this.
The union above is not really what I'd like to have here. In fact,
I think to get the v4 sprom implemented the sprom struct has to be
redesigned.
I think we must leave the path of partitioning the sprom struct into
versions, because that obviously doesn't work anymore.
Instead, I think we must develop _one_ common struct that is capable
of holding the information from any sprom. (Note that the struct layout
does not need to reflect the real hardware layout).
And I think we should also remove the fields that are not needed at all,
like the PCI ID stuff.
something like this:
struct ssb_sprom_pathvar {
bool this_pathvar_is_available;
...foobar data
};
struct ssb_sprom {
u8 wl_mac_addr[ETH_ALEN];
u8 eth0_mac_addr[ETH_ALEN];
u8 eth1_mac_addr[ETH_ALEN];
...
u8 gpio0;
u8 gpio1;
...
antennagain...
struct ssb_sprom_pathvar pv0;
struct ssb_sprom_pathvar pv1;
...
};
Note that I did _not_ look closely at the pathvar stuff, so this
might be a bad idea to design it this way.
But the point I was going to make with that was; we probably need
some "this data is valid" bits for different parts of the sprom
struct, as for example v1-3 don't have these pathvars (So the drivers
must be told it's invalid data).
The reason for all this "valid-bit" stuff is that I think we should
remove any sprom-versioning knowledge from the drivers. That
should be abstracted.
Any idea on how to improve that?
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43legacy maintainer needed
> however, I will be happy to > send the BCM4306 card. Do you have access to a PCI-based desktop running > Linux? If so, I also have a > Linksys WMP11-V27, which is a B-only device that belongs to the project. I have a PCI 4306 which is G-capable that may or may not be used by b43, I'd have to put it into a machine. It's up for grabs too as I don't own any boxes with PCI slots. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
