Fwd: The newest Macbook 13.3 wireless
Daniel: please post to ML and do not top post.
-- Wiadomość przekazana dalej --
Od: Daniel Kuehn enha...@gmail.com
Data: 5 stycznia 2010 12:46
Temat: Re: The newest Macbook 13.3 wireless
Do: Rafał Miłecki zaj...@gmail.com
@Rafal
Well, I could try and check what chip it gets detected as with b43,
but I do not even get a interface when using b43 drivers. With the
broadcom-sta drivers I get the eth1 interface but any calls to it like
'iwlist eth1 scanning' or 'ifconfig eth1 essid whatever' returns an
ioctl error saying invalid parameter.
I could not get the compat-wireless package to compile either due to a
ralink driver throwing errors (And I could not choose the b43 driver
with the driver-select script :S) so the only b43 drivers I have
access to are the ones in .31-r6 and .32-r1 kernels, and neither one
of them even gives me an interface to work with.
Mvh
Daniel Kuehn
2010/1/4 Rafał Miłecki zaj...@gmail.com
W dniu 4 stycznia 2010 23:45 użytkownik Gábor Stefanik
netrolller...@gmail.com napisał:
2010/1/4 Rafał Miłecki zaj...@gmail.com:
2010/1/3 Daniel Kuehn enha...@gmail.com:
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.
Could you check what chipset is it? I think you should see something like:
b43-phy0: Broadcom 43** WLAN found
where 43** is number I ask for.
Gábor: do you have still access to this 14e4:4353 device? If Daniel
won't able to check chipset, could you do this? I don't think that
BCM43224 you noted is correct. Could you double check that?
I just would like to fill table on
http://wireless.kernel.org/en/users/Drivers/b43 with this device.
The wireless card in the late-2009 MacBook is a BCM943224PCIEBT (as
stated on the exterior shell of the actual MacBook), which is a custom
(but Broadcom-made) BCM43224 (basically a dual-band BCM4322 plus a
BCM2070 for Bluetooth). A picture of the card can be seen at
http://images.weiphone.com/attachments/Day_091021/68_294416_286a2478633560a.jpg
- note that this is an official Apple replacement part, and may look
slightly different from a generic Broadcom version. Pictures of the
Broadcom reference version will be available on FCC's site after
February 20, when the temporary confidentality grant expires.
The description for BCM943224HMB (the same card in a different form
factor) can be viewed at
http://www.broadcom.com/products/Wireless-LAN/802.11-Wireless-LAN-Solutions/BCM943224HMB
(note Broadcom's odd usage of the word SoC, which is used in the
sense single-chip transceiver - the 43224 is not a SOC in the true
sense of the word).
I do not currently have either type of BCM43224 at hand, but the
information found on the web looks convincing.
Uh, so they really used 43[0-9]{3} instead of 43[0-9]{2}. Didn't
expect that, that's why I asked for double check. Thanks for
explaining.
--
Rafał
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: The newest Macbook 13.3 wireless
W dniu 5 stycznia 2010 12:58 użytkownik Rafał Miłecki zaj...@gmail.com napisał: Daniel: please post to ML and do not top post. -- Wiadomość przekazana dalej -- Od: Daniel Kuehn enha...@gmail.com Data: 5 stycznia 2010 12:46 Temat: Re: The newest Macbook 13.3 wireless Do: Rafał Miłecki zaj...@gmail.com @Rafal Well, I could try and check what chip it gets detected as with b43, but I do not even get a interface when using b43 drivers. With the broadcom-sta drivers I get the eth1 interface but any calls to it like 'iwlist eth1 scanning' or 'ifconfig eth1 essid whatever' returns an ioctl error saying invalid parameter. Gábor already provided nice info, so that's no longer needed, but thanks :) Don't know about broadcom-sta. I could not get the compat-wireless package to compile either due to a ralink driver throwing errors (And I could not choose the b43 driver with the driver-select script :S) so the only b43 drivers I have access to are the ones in .31-r6 and .32-r1 kernels, and neither one of them even gives me an interface to work with. As this is N-PHY, there is no support for it in b43. I started writing some code but don't except anything in months. -- Rafał ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: The newest Macbook 13.3 wireless
2010/1/5 Rafał Miłecki zaj...@gmail.com 2010/1/5 Daniel Kuehn enha...@gmail.com: I am sorry, I am very new to this system with mailing lists, could you explain what a top post is (maybe in a private mail so we dont clutter the ML) Okay, well then I know that work has been started, that is good. I assumed that this card was kinda brand spanking new and knew that I would have to wait some time before it would be supported in b43, there is no worry I can wait. Just give me a howler if you need a tester to test something ;) You already replied to ML (not me privately), that's fine :) Now just this: A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? Just reply under (below) quoted text (as I did in this mail). If you want some more info, check http://en.wikipedia.org/wiki/Posting_style#Bottom-posting but what I wrote generally explains all :) -- Rafał I see, I am used to the opposite way in a normal email conversation on gmail :P Will have to re think when posting to MLs then ^^ Mvh Daniel Kuehn ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 kills my kernel
On Monday 04 January 2010 22:51:40 Oncaphillis wrote: Did any of the patches for a device without a sprom make it into the 2.6.33-rc2 ? No we decided that the patches were not acceptable and need a rewrite towards firmware loading mechanism. Nobody's currently doing that, though. -- Greetings, Michael. ___ 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 Monday 04 January 2010 23:34:19 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? 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. -- Greetings, Michael. ___ 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: [PATCH] b43: N-PHY: update part of init code to current specs
W dniu 5 stycznia 2010 13:34 użytkownik Kalle Valo kalle.v...@iki.fi napisał: Rafał Miłecki zaj...@gmail.com writes: Michael said many times he prefers smaller patches posted more frequently. So there this go. However if you think it's too small, just let me know please. I always post very small patches and I have never been flamed about that. And reviewing is so much easier with small logical patches. So don't worry about your patches being too small. Thanks for opinion, I'll keep posting that way :) -- Rafał ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH 1/2] b43: N-PHY: update TODOs in init part
Replace TODOs based on old specs with more current ones.
From 328cf91018178723574031585b447bb849ccddba Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= zaj...@gmail.com
Date: Tue, 5 Jan 2010 20:35:48 +0100
Subject: [PATCH 1/2] b43: N-PHY: update TODOs in init part
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
drivers/net/wireless/b43/phy_n.c | 71 -
drivers/net/wireless/b43/phy_n.h | 12 ++
2 files changed, 58 insertions(+), 25 deletions(-)
diff --git a/drivers/net/wireless/b43/phy_n.c b/drivers/net/wireless/b43/phy_n.c
index 015da44..6479d6e 100644
--- a/drivers/net/wireless/b43/phy_n.c
+++ b/drivers/net/wireless/b43/phy_n.c
@@ -425,8 +425,10 @@ int b43_phy_initn(struct b43_wldev *dev)
struct ssb_bus *bus = dev-dev-bus;
struct b43_phy *phy = dev-phy;
struct b43_phy_n *nphy = phy-n;
+ u8 tx_pwr_state;
u16 tmp;
enum ieee80211_band tmp2;
+ bool do_rssi_cal;
u16 clip[2];
bool do_cal = false;
@@ -503,35 +505,54 @@ int b43_phy_initn(struct b43_wldev *dev)
}
b43_nphy_workarounds(dev);
- b43_nphy_reset_cca(dev);
- ssb_write32(dev-dev, SSB_TMSLOW,
- ssb_read32(dev-dev, SSB_TMSLOW) | B43_TMSLOW_MACPHYCLKEN);
+ //TODO N PHY BMAC Clock FGC with argument 1
+ b43_nphy_reset_cca(dev);
+ //TODO N PHY BMAC Clock FGC with argument 0
+ //TODO N PHY MAC PHY Clock Set with argument 1
+ //TODO Disable PA Override
b43_nphy_force_rf_sequence(dev, B43_RFSEQ_RX2TX);
b43_nphy_force_rf_sequence(dev, B43_RFSEQ_RESET2RX);
+ //TODO Turn on PA override
+ //TODO N PHY Classifier with arguments 0 and 0
+ //TODO N PHY Det Clip with 0 and the clip array as arguments
+ tx_pwr_state = nphy-txpwrctrl;
+ //TODO N PHY TX power control with argument 0 (turning off power
control)
+ //TODO Fix the TX Power Settings
+ //TODO N PHY TX Power Control Idle TSSI
+ //TODO N PHY TX Power Control Setup
+
+ if (phy-rev = 3) {
+ //TODO
+ } else {
+ //TODO Write an N PHY table with ID 26, length 128, offset 192,
width 32, and the data from Rev 2 TX Power Control Table
+ //TODO Write an N PHY table with ID 27, length 128, offset 192,
width 32, and the data from Rev 2 TX Power Control Table
+ }
+
+ if (nphy-phyrxchain != 3)
+ //TODO N PHY RX Core Set State with phyrxchain as argument
+ if (nphy-mphase_cal_phase_id 0)
+ //TODO PHY Periodic Calibration Multi-Phase Restart
+
+ do_rssi_cal = false;
+ if (phy-rev = 3) {
+ //TODO
+ } else {
+ //TODO
+ }
+
+ if (!((nphy-measure_hold 0x6) != 0)) {
+ //TODO
+ }
- b43_phy_read(dev, B43_NPHY_CLASSCTL); /* dummy read */
- //TODO read core1/2 clip1 thres regs
-
- if (1 /* FIXME Band is 2.4GHz */)
- b43_nphy_bphy_init(dev);
- //TODO disable TX power control
- //TODO Fix the TX power settings
- //TODO Init periodic calibration with reason 3
- b43_nphy_rssi_cal(dev, 2);
- b43_nphy_rssi_cal(dev, 0);
- b43_nphy_rssi_cal(dev, 1);
- //TODO get TX gain
- //TODO init superswitch
- //TODO calibrate LO
- //TODO idle TSSI TX pctl
- //TODO TX power control power setup
- //TODO table writes
- //TODO TX power control coefficients
- //TODO enable TX power control
- //TODO control antenna selection
- //TODO init radar detection
- //TODO reset channel if changed
+ //TODO N PHY TX Power Control Coef Setup
+ //TODO N PHY TX Power Control Enable with argument tx_pwr_state
+ b43_phy_write(dev, B43_NPHY_TXMACIF_HOLDOFF, 0x0015);
+ b43_phy_write(dev, B43_NPHY_TXMACDELAY, 0x0320);
+ if (phy-rev = 3 phy-rev = 6)
+ b43_phy_write(dev, B43_NPHY_PLOAD_CSENSE_EXTLEN, 0x0014);
+ //TODO N PHY TX LP FBW
+ //TODO N PHY Spur Workaround
b43err(dev-wl, IEEE 802.11n devices are not supported, yet.\n);
return 0;
diff --git a/drivers/net/wireless/b43/phy_n.h b/drivers/net/wireless/b43/phy_n.h
index 8f174b7..e5e402a 100644
--- a/drivers/net/wireless/b43/phy_n.h
+++ b/drivers/net/wireless/b43/phy_n.h
@@ -925,7 +925,19 @@
struct b43_wldev;
struct b43_phy_n {
+ u8 txpwrctrl;
+ u8 measure_hold;
+ u8 phyrxchain;
+ u8 mphase_cal_phase_id;
u32 deaf_count;
+ bool mute;
+
+ u8 iqcal_chanspec_2G;
+ u8 rssical_chanspec_2G;
+
+ u8 iqcal_chanspec_5G;
+ u8 rssical_chanspec_5G;
+
bool crsminpwr_adjusted;
bool noisevars_adjusted;
--
1.6.4.2
0001-b43-N-PHY-update-TODOs-in-init-part.patch
Description: Binary data
[PATCH 2/2] b43: N-PHY: update reset_cca operation and add rssi_cal calls
Update b43_nphy_reset_cca to match current specs and add rssi_cal calls to init
code.
From 71c10442cd0b1b277f483a81db7f2e8f579b3d59 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= zaj...@gmail.com
Date: Tue, 5 Jan 2010 20:52:43 +0100
Subject: [PATCH 2/2] b43: N-PHY: update reset_cca operation and add rssi_cal
calls
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
drivers/net/wireless/b43/phy_n.c | 49 +++--
1 files changed, 36 insertions(+), 13 deletions(-)
diff --git a/drivers/net/wireless/b43/phy_n.c b/drivers/net/wireless/b43/phy_n.c
index 6479d6e..ceb429a 100644
--- a/drivers/net/wireless/b43/phy_n.c
+++ b/drivers/net/wireless/b43/phy_n.c
@@ -343,16 +343,9 @@ static void b43_nphy_workarounds(struct b43_wldev *dev)
static void b43_nphy_reset_cca(struct b43_wldev *dev)
{
- u16 bbcfg;
-
- ssb_write32(dev-dev, SSB_TMSLOW,
- ssb_read32(dev-dev, SSB_TMSLOW) | SSB_TMSLOW_FGC);
- bbcfg = b43_phy_read(dev, B43_NPHY_BBCFG);
- b43_phy_set(dev, B43_NPHY_BBCFG, B43_NPHY_BBCFG_RSTCCA);
- b43_phy_write(dev, B43_NPHY_BBCFG,
- bbcfg ~B43_NPHY_BBCFG_RSTCCA);
- ssb_write32(dev-dev, SSB_TMSLOW,
- ssb_read32(dev-dev, SSB_TMSLOW) ~SSB_TMSLOW_FGC);
+ u16 bbcfg = b43_phy_read(dev, B43_NPHY_BBCFG);
+ b43_phy_write(dev, B43_NPHY_BBCFG, bbcfg | B43_NPHY_BBCFG_RSTCCA);
+ b43_phy_write(dev, B43_NPHY_BBCFG, bbcfg ~B43_NPHY_BBCFG_RSTCCA);
}
enum b43_nphy_rf_sequence {
@@ -411,8 +404,30 @@ static void b43_nphy_bphy_init(struct b43_wldev *dev)
b43_phy_write(dev, B43_PHY_N_BMODE(0x38), 0x668);
}
+static void b43_nphy_rev2_rssi_cal(struct b43_wldev *dev, u8 type)
+{
+ //TODO
+}
+
+static void b43_nphy_rev3_rssi_cal(struct b43_wldev *dev)
+{
+ //TODO
+}
+
/* RSSI Calibration */
-static void b43_nphy_rssi_cal(struct b43_wldev *dev, u8 type)
+static void b43_nphy_rssi_cal(struct b43_wldev *dev)
+{
+ if (dev-phy.rev = 3) {
+ b43_nphy_rev3_rssi_cal(dev);
+ } else {
+ b43_nphy_rev2_rssi_cal(dev, 2);
+ b43_nphy_rev2_rssi_cal(dev, 0);
+ b43_nphy_rev2_rssi_cal(dev, 1);
+ }
+}
+
+/* Restore RSSI Calibration */
+static void b43_nphy_restore_rssi_cal(struct b43_wldev *dev)
{
//TODO
}
@@ -536,9 +551,17 @@ int b43_phy_initn(struct b43_wldev *dev)
do_rssi_cal = false;
if (phy-rev = 3) {
- //TODO
+ if (b43_current_band(dev-wl) == IEEE80211_BAND_2GHZ)
+ do_rssi_cal = (nphy-rssical_chanspec_2G == 0);
+ else
+ do_rssi_cal = (nphy-rssical_chanspec_5G == 0);
+
+ if (do_rssi_cal)
+ b43_nphy_rssi_cal(dev);
+ else
+ b43_nphy_restore_rssi_cal(dev);
} else {
- //TODO
+ b43_nphy_rssi_cal(dev);
}
if (!((nphy-measure_hold 0x6) != 0)) {
--
1.6.4.2
bin8tpMAuySHX.bin
Description: Binary data
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 kills my kernel
On 01/05/2010 08:27 PM, Larry Finger wrote: On 01/05/2010 11:18 AM, Michael Buesch wrote: On Monday 04 January 2010 22:51:40 Oncaphillis wrote: Did any of the patches for a device without a sprom make it into the 2.6.33-rc2 ? No we decided that the patches were not acceptable and need a rewrite towards firmware loading mechanism. Nobody's currently doing that, though. Since the previous round of tests, the reverse-engineering group has been working on a new release of the Broadcom driver. So far, I have not looked into how it handles firmware when there is no SPROM, but that task is on my list of things to do. Larry Great to hear that. Thank you very much. I'll be happy to test it. and Happy new year ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43: must set qos=0 on to connect
On Wed, Jan 6, 2010 at 12:00 AM, John Daiker daikerj...@gmail.com wrote: I have a BCM4312 rev 01 (14e4:4315) card in my HP Mini netbook. I am having troubles connecting to any WEP secured AP. I know the trick about having to load with pio=1 for the device to stay happy (and forget about using DMA), so no issues there, I hope. With qos=1 (by default, IIRC), I am unable to establish a connection with said WEP connection, and notice many 'PHY transmission error' messages in my dmesg output. With qos=1, I can successfully connect to my WEP connection without issue, and without any error messages or warnings. I have a BCM4318 rev 02 (14e4:4318) in a desktop that works with enabled/disabled qos not matter what. Also, a RT2500-based card works fine on the connection as well. Both card are using the 478.104 firmware. Please advise what steps I should take to further debug this issue. Thanks, John Daiker -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Hi! Is this the new 4312 (BCM94312HMGB AKA 575920-001), with integrated Bluetooth? I haven't seen this issue on my machines with a regular 4312, so it is probably related to the DMA error, or maybe it is specific to the new 4312. If you can, please check whether the actual model number printed on the card is the new one. Thanks, Gábor -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43: must set qos=0 on to connect
2010/1/6 John Daiker daikerj...@gmail.com: On 01/05/2010 03:48 PM, Gábor Stefanik wrote: On Wed, Jan 6, 2010 at 12:00 AM, John Daikerdaikerj...@gmail.com wrote: I have a BCM4312 rev 01 (14e4:4315) card in my HP Mini netbook. I am having troubles connecting to any WEP secured AP. I know the trick about having to load with pio=1 for the device to stay happy (and forget about using DMA), so no issues there, I hope. With qos=1 (by default, IIRC), I am unable to establish a connection with said WEP connection, and notice many 'PHY transmission error' messages in my dmesg output. With qos=1, I can successfully connect to my WEP connection without issue, and without any error messages or warnings. I have a BCM4318 rev 02 (14e4:4318) in a desktop that works with enabled/disabled qos not matter what. Also, a RT2500-based card works fine on the connection as well. Both card are using the 478.104 firmware. Please advise what steps I should take to further debug this issue. Thanks, John Daiker -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Hi! Is this the new 4312 (BCM94312HMGB AKA 575920-001), with integrated Bluetooth? I haven't seen this issue on my machines with a regular 4312, so it is probably related to the DMA error, or maybe it is specific to the new 4312. If you can, please check whether the actual model number printed on the card is the new one. Thanks, Gábor Gábor, I just pulled the card, and it's not the chip you mention. It's a BCM94312HMG (Notice that it doesn't have the B at the end. I would assume that indicates the Bluetooth integration.) I've taken few photos of the front and back of the card. Let me know if you want to see them... I can post 'em on my website or flickr for your viewing pleasure. Thanks, John Daiker Weird... I also have a 94312HMG, and it doesn't show this error (at least not in DMA mode). Maybe this is a PIO-specific issue... I'll try to test that. -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 on Dell i1545 laptop
I'm not sure if this is a b43 problem or a Fedora problem. After the advice given previously, I grabbed a nightly Fedora 13 spin that has a 2.6.32.2-15.fc13.x86_64 kernel and ran from the live DVD. going through dmesg it eventually gets to b43-phy0: Broadcom 4312 WLAN found (core revision 15) b43-phy0 debug: Found PHY: Analog 6, Type 5, Revision 1 b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2062, Revision 2 cfg80211: World regulatory domains updated and then a list of frequencies ... some Registered led device: messages ... Broadcom 43xx driver loaded [Features: PMLS, Firmware-ID: FW13] ... b43 ssb0:0: firmware: requestiong b43/ucode15.fw b43 ssb0:0: firmware: requesting b43-open/ucode15.fw b43-phy0 ERROR: Firmware file b43/ucode15.fw not found b43-phy0 ERROR: Firmware file b43-open/ucode15.fw not found b43-phy0 ERROR: You must go to http://wireless.kernel.org/en/users/Drivers/b43#d evicefirmware and download the correct firmware for this driver version. Please carefully read all instructions on this website. Now what's in /lib/firmware/b43 on the live CD is ucode5.fw 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) 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. jhhaynes at earthlink dot net ___ 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
