brcm80211 vs. broadcom sta vs. b43/ssb

[adamrmcd]

Hello GH,

I thought I'd reply to your b43 question in a new thread, since it
wasn't directly related to my 'Sign-in problem in kernel?' problem :)

On Jan 23, 8:00 am, GH <gregjho...@gmail.com> wrote:
> I have been attempting to do the exact same thing you are (I have a
> broadcom 4312 which identifies itself as a 4315).  Over the past few
> days, I have found building x86-generic with kernel-next to be
> frequently unstable.
> [...]
> How are you going to get the b43 driver into your build?  Is there is
> an easy way to tell build_packages to build in the b43 driver?

I found that the new staging broadcom module found in kernel-next did
find my wifi access points and connect. Granted, this was very early
in the first screen of the sign-on process, before my aforementioned
sign-on failure. For me, the brcm80211 staging driver kicked in, not
b43. (14e4:4727)

In the past, I have never had any luck with b43 and ssb. Prior to
brcm80211, I've always disabled b43/ssb for devices that were also
claimed by the broadcom sta driver, using this patch:

diff --git a/drivers/ssb/b43_pci_bridge.c b/drivers/ssb/
b43_pci_bridge.c
index ef9c6a0..c00783b 100644
--- a/drivers/ssb/b43_pci_bridge.c
+++ b/drivers/ssb/b43_pci_bridge.c
@@ -20,18 +20,22 @@ static const struct pci_device_id
b43_pci_bridge_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4301) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4306) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4307) },
+/* Disable modules provided by broadcom/wl.ko
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4311) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4312) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4315) },
+ */
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4318) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4319) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4320) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4321) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4324) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4325) },
+/* Disable modules provided by broadcom/wl.ko
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4328) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4329) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x432b) },
+ */
{ 0, },
};
MODULE_DEVICE_TABLE(pci, b43_pci_bridge_tbl);

Granted, it looks like the 64-bit version of broadcom sta is borked,
and will not initialize under x86-pineview (an unrelated problem).
However I am in the process of integrating the 32-bit sta into
ChromiumOS's x86-generic standard kernel, but for entertainment
purposes only :)

> How are you going to get the b43 driver into your build?  Is there is
> an easy way to tell build_packages to build in the b43 driver?

I am not an expert on Chrome's build environment (my background is
Debian based) but I think you need to follow
http://www.chromium.org/chromium-os/how-tos-and-troubleshooting/kernel-configuration
.. You must edit the kernel configuration options to activate b43 and
ssb, but in a way to cause build_packages to actually compile your
custom kernel.

Also, You may need to execute a complete build_packages build. This
may solve your earlier header problem in the module magic version.
Good luck!

[Greg Hogan]

Thanks for all the info!

On Sun, Jan 23, 2011 at 12:11, adamrmcd <adam.r....@gmail.com> wrote:

Hello GH,

I thought I'd reply to your b43 question in a new thread, since it
wasn't directly related to my 'Sign-in problem in kernel?' problem :)

On Jan 23, 8:00 am, GH <gregjho...@gmail.com> wrote:
> I have been attempting to do the exact same thing you are (I have a
> broadcom 4312 which identifies itself as a 4315).  Over the past few
> days, I have found building x86-generic with kernel-next to be
> frequently unstable.
> [...]
> How are you going to get the b43 driver into your build?  Is there is
> an easy way to tell build_packages to build in the b43 driver?

I found that the new staging broadcom module found in kernel-next did
find my wifi access points and connect. Granted, this was very early
in the first screen of the sign-on process, before my aforementioned
sign-on failure. For me, the brcm80211 staging driver kicked in, not
b43. (14e4:4727)

I should probably point out we are looking at different wireless devices, lspci identifies mine as 14e4:4315 which is the 4312 chipset.  You had originally mentioned 4312 as your chipset, but according to linuxwireless.org your 14e4:4727 is the 4313 chipset.  So, originally I had thought we would be looking at the same open-source driver, but that is not the case since the brcm80211 driver does not support the 4312 chipset.  For open-source drivers it is b43 or nothing for me.

 

In the past, I have never had any luck with b43 and ssb. Prior to
brcm80211, I've always disabled b43/ssb for devices that were also
claimed by the broadcom sta driver, using this patch:

Just an FYI for anyone else that reads this, it no longer appears to be necessary to disable these drivers if you want to use the broadcom sta driver because b43, b43-legacy, and ssb are all excluded from the default kernel build (at least in x86-generic).  I have also heard that b43 has terrible performance with my chipset, but I can't get DHCP to give me an IP address for some reason using the broadcom sta (wl.ko) driver with the default kernel, so I was told to try the open-source driver using kernel-next:

http://groups.google.com/a/chromium.org/group/chromium-os-dev/browse_thread/thread/983cdac3c9b6af4f

- Show quoted text -

I have an Atom N270 CPU which supports x86 only, so the 32 bit broadcom sta driver is what I was previously attempting to use (except so far only with kernel, not kernel-next).  Have you successfully gotten an IP address from DHCP using this driver with chrome os?  I was able to associate by telling wpa_supplicant to use WEXT, and then if I set the default route and IP address manually I could ping internet IP addresses.  I thought I almost had it working, but dhcpcd would always timeout waiting for a response!

 

> How are you going to get the b43 driver into your build?  Is there is
> an easy way to tell build_packages to build in the b43 driver?

I am not an expert on Chrome's build environment (my background is
Debian based) but I think you need to follow
http://www.chromium.org/chromium-os/how-tos-and-troubleshooting/kernel-configuration
.. You must edit the kernel configuration options to activate b43 and
ssb, but in a way to cause build_packages to actually compile your
custom kernel.

Also, You may need to execute a complete build_packages build. This
may solve your earlier header problem in the module magic version.
Good luck!

In an attempt to build the b43 driver I followed those instructions and got the b43 driver to successfully build as a module, but then when I run ./build_packages the module doesn't end up in the image!  Any idea what I am doing wrong?

Thanks!

[adamrmcd]

On Jan 23, 1:50 pm, Greg Hogan <gregjho...@gmail.com> wrote:
> I should probably point out we are looking at different wireless devices,
> lspci identifies mine as 14e4:4315 which is the 4312 chipset.  You had
> originally mentioned 4312 as your chipset, but according to
> linuxwireless.org your 14e4:4727 is the 4313 chipset.  So, originally I had
> thought we would be looking at the same open-source driver, but that is not
> the case since the brcm80211 driver does not support the 4312 chipset.  For
> open-source drivers it is b43 or nothing for me.
>
> > In the past, I have never had any luck with b43 and ssb. Prior to
> > brcm80211, I've always disabled b43/ssb for devices that were also
> > claimed by the broadcom sta driver, using this patch:
>
> Just an FYI for anyone else that reads this, it no longer appears to be
> necessary to disable these drivers if you want to use the broadcom sta
> driver because b43, b43-legacy, and ssb are all excluded from the default
> kernel build (at least in x86-generic).

Heh, you're absolutely right, I should have clarified. That SSB patch
is from my Ubuntu-based kernel/distribution where we do ship with
Broadcom STA pre-installed. I do have another device which is
14e4:4315 and matches your config. Since there was an overlap between
these drivers, and we prefer the working STA driver which is
incompatible with ssb, the list of ssb modaliases had to be scaled
back.

Again, on the device with 14e4:4315 (an HP Mini 110) I've never had
much of any luck with b43. Granted, the last time I really looked at
this was in 2.6.32 (my distro is running 2.6.35.9) so I should revisit
this for 2.6.37.

> I have an Atom N270 CPU which supports x86 only, so the 32 bit broadcom sta
> driver is what I was previously attempting to use (except so far only with
> kernel, not kernel-next).  Have you successfully gotten an IP address from
> DHCP using this driver with chrome os?

I'll give it a shot as soon as I have solved my sign-on crash problem.
(BTW, simply re-running 'repo sync' hasn't helped, but now I believe
it to be a regression somewhere between 0.10.144 and 0.10.149, and not
with kernel-next. Right now I'm building from specific branches to see
if I can see when exactly this problem started. Once I know more i'll
post something in my original thread.)

> In an attempt to build the b43 driver I followed those instructions and got
> the b43 driver to successfully build as a module, but then when I run
> ./build_packages the module doesn't end up in the image!  Any idea what I am
> doing wrong?

Have you run `cros_workon start sys-kernel/chromeos-kernel-next`
before running build_packages?

Also, verify what /build/x86-generic/packges/sys-kernel/ contains.
Again, my newly-minted portage skillz are weak, but I think you should
only have one file, something like "chromeos-kernel-next-9999.tbz2" in
here. The key is the 9999 version indicating a locally built package,
not 0.0.1 indicating a "green tree" package build. (This was my
problem a few days ago.)

Maybe someone with more portage experience can confirm/deny this? :)

[GH]

Yeah, I had run `cros_workon start sys-kernel/chromeos-kernel-next`
I didn't realize build_packages was rebuilding what I had already
built using cros_workon_make (and building things differently
apparently). Perhaps it is a bad idea in general to try to build
packages using cros_workon_make?

See here for more details:
http://groups.google.com/a/chromium.org/group/chromium-os-dev/browse_thread/thread/159b0c697f5626f5/716750a99fa0a797#716750a99fa0a797

[Chris Masone]

On Sun, Jan 23, 2011 at 8:12 PM, GH <gregj...@gmail.com> wrote:

Yeah, I had run `cros_workon start sys-kernel/chromeos-kernel-next`
I didn't realize build_packages was rebuilding what I had already
built using cros_workon_make (and building things differently
apparently).  Perhaps it is a bad idea in general to try to build
packages using cros_workon_make?

cros_workon_make is intended to be used for iterative development, so a build_packages is _probably_ going to wind up rebuilding whatever you're cros_workon_mak'ing.  It's like if you're working on some subproject and just running make over and over, and then you run the whole project's build script and it builds everything out of tree.  If the two build pathways are causing things to be built with different envrionment settings somehow, that's probably bad and a bug should be filed.

 

--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en