12 ms·

Broadcom Wi-Fi Datasheets

204 points by lbenes 10y ago

grawlinson 10y ago
I'm not familiar with this particular industry, but will the open-source Broadcom drivers in the Linux kernel benefit from this? Because well ... Broadcom drivers suck.
- sohkamyung 10y ago
  I'm not sure. The datasheets contain pin-out and hardware interfacing information. But apparently missing is information on how to program the internal registers, how to Tx and Rx data and wireless management information, which is probably what the Broadcom drivers require to manage the chips. Basically, the internals of the chips still look like a 'black-box' to the drivers. Of course, I may just be wrong.
  - Gibbon1 10y ago
    It's not actually that uncommon to see minimal datasheets on some types of consumer type IC's. Getting the full documentation and software needed then requires signing an NDA and spending anywhere from a few hundred to to a few thousand for a development kit. Some of this is because the manufacturer considers the information to be proprietary and also because they not setup to support large numbers design teams. Some IC's especially early revisions are buggy and poorly documented so a lot of hand holding is needed[1]. [1] Think of a buggy piece of silicon where you need to implement a number of work around's in firmware. And where each customer invariably runs into an errata you didn't know about.
    - baybal2 10y ago
      >requires signing an NDA and spending anywhere from a few hundred to to a few thousand for a development kit. >Some of this is because the manufacturer considers the information to be proprietary and also because they not setup to support large numbers design teams No, it is what is called a pain sales tactic. You make a person to go through big pain, spend lots of resources just to get a devkit, so they would not be inclined to throw it out midproject because it sucks
    - sohkamyung 10y ago
      That is true. But for WiFi chips, some of that initial development cost can be bypassed as they usually operate over a SDIO interface, which is a generic interface and compatible with most microcontrollers with a SDIO controller. So you can usually just get the WiFi chip (for example, Broadcom or Marvell) on a SDCard form-factor extender, plug it into your standard SD Card slot and work on it with the SDIO controller on your development board. Note: the SD interface controller must support SDIO and not just the memory SD-Card portion of the spec. But, of course, you still need the development documentation and internal chip information. That, unfortunately, must still be paid for.
- DeepYogurt 10y ago
  Having the data sheets can't hurt.
- minipci1321 10y ago
  I wish we had standard hardware-software interfaces -- mandatory by law for consumer electronics -- for all significant components (what is understood by "devices") of computing platforms used for general public, as we have today (to varying extents) for USB host controllers, Ethernet PHYs etc. The typical counter-argument here is that standardizing would stifle innovation (and possibly hit performance), but is that still as impacting as it sounds? For once, innovation seems to have moved to "rear ends" of the devices, and secondly, given the amount of firmware that goes into all sorts of devices these days, any reasonably complex translation doesn't look so penalizing anymore?
  - creshal 10y ago
    It wouldn't really change anything. Just look at printers: They all speak PostScript/PCL or GDI, and haven't seen a single innovation in at least 15 years. Yet somehow, printer drivers are still the single worst piece of software you're likely going to see.
  - kalleboo 10y ago
    It can go both ways. One reason that GSM took over the world was because the initial standard defined not just the over the air interface, but the interfaces between all the individual components in the ground network. The point being so you could mix Ericsson base stations with a Nokia controller, and in that way it increased competition between the equipment manufacturers since they had no lock-in.
  - minipci1321 10y ago
    Hmm... guess I was downvoted for "mandatory by law". I am not in favor of using law here either, that was more a cry of the heart -- I've been spending what seems like entire life on driver development, which is no rocket science in itself but made complex by hardware vendors concealing unimportant information (often for not good reasons, like corporate culture), for so long time that product makers have learned to not even look for it anymore. I really wish we had that process fixed.
- cheiVia0 10y ago
  I'm more interested in whether or not there will be open source firmware for these chips.
- americanjetset 10y ago
  Every time I do a fresh install of Debian on my laptop, I whip out the Ethernet cable and do the strange, hour-long dance of installing and uninstalling broadcom-sta-common while modprobing various kernel modules until my wifi works. BCM4313 -- never again.
josephg 10y ago
Can somebody please explain the significance of this?
- Arnt 10y ago
  It's easier to write a driver when you have a datasheet than when your only source of information is reverse-engineering the windows driver.
- dmytrish 10y ago
  Broadcom wireless equipment has been a lot of pain for Linux users. Publishing (at least some) datasheets is a huge relief for driver writers.
_pmf_ 10y ago
Maybe a CMS error?
- rincebrain 10y ago
  Not impossible, but usually these CMSes make it hard to publish-by-default, and the fact that there's still information absent from the published data makes me think it's not necessarily an accident of "all this data was public by default." We'll see, though.
bencollier49 10y ago
Should make a cheaper and completely open Raspberry Pi possible? IIRC the Broadcom chipset was the only proprietary part?
- nibnib 10y ago
  That was a graphics driver IIRC
  - bencollier49 10y ago
    https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2835/README.md https://www.raspberrypi.org/documentation/hardware/raspberry... The driver's open source, the hardware's closed.
    - SXX 10y ago
      When RPi initially released it's was was fully proprietary with only open source library that talked to the driver. Most of code and OpenGL ES implementation itself simply run outside of Linux on specialized core. I suppose it's part of the same blob that manage both bootloader startup, display control, etc. RPi SoC built the way when GPU initialized before everything else and manage the boot process. Then they released source for the actual OES implementationm but since it's run on core with limited capabilities it's hard to improve it much. Shortly after Broadcom hired Eric Anholt to work open source kernel driver and Mesa-based GL implementation that will actually run on Linux.
    - pawadu 10y ago
      The problem is that their documentation contains only selected information and every time the community needs information about some other part they have to beg Broadcom for information. Most often the request was denied. So here we are, with a partially functioning linux on an overheating pi3 that no one knows how to fix.
BobCat 10y ago
Can anyone explain what competitive advantage vendors gain/maintain by not publishing datasheets and programming information?
- IshKebab 10y ago
  I suspect it prevents potential customers from realising that their competitors' chips are better and have actual documentation until it is too late.
- olalonde 10y ago
  Not a really satisfying answer but I've been told it is to prevent competitors from reverse engineering.
  - timonovici 10y ago
    Yeah, probably you're right. And it's not like it would stop the really determined guys - X-Raying stuff would do a part of the trick, and maybe stealing the documentation would the other part.
- Arnt 10y ago
  Some fraction of the potential customers will call you, which gives you contact information. If you're proactive enough and good enough at selling to that fraction, the end result is beneficial for you. I'd love to know whether that works...
- minipci1321 10y ago
  Well, it is actually extremely expensive to produce customer-facing documentation of high quality. Vendors don't do that (or do to a limited extent), because a) this is big cost and time consumption, and b) because the makers don't request it anymore; even given such information of high quality they would not use it! Many of them have acquired the reflex of calling vendor's support for even the smallest question (let alone anything involved -- they will shift that job to vendor entirely), so the vendors have performed the selection of customers they can work with that way, and neglected the others (and the documentation). From personal experience, the expectation of good documentation today for many developers -- an instant reply to a question limited to 140 characters.
martey 10y ago
The title is misleading - Cypress only acquired BroadCom's Internet of Things business, and it happened last April. http://www.cypress.com/news/cypress-acquire-broadcom-s-wireless-internet-things-business-0 http://www.cypress.com/news/cypress-acquire-broadcom-s-wirel... "Under the terms of the deal, Broadcom will continue to focus on its wireless connectivity solutions for the access and mobility segments that are not IoT related, including serving set-top box, wireless access, smartphone, laptop and notebook customers. Cypress will capitalize on the rapidly growing Wi-Fi and Bluetooth connectivity (17% per year) markets in consumer, industrial and automotive IoT segments."
shortsightedsid 10y ago
Broadcom's documentation sucked and will continue to suck because of their customer strategy. As a company their goal has always been to focus on high volume customers. I don't have a problem with that, except that they were also trying to cross-sell to the lower volume market but didn't have the mindset to support that market. Mind you this isn't just the Hobby market like RaspberryPi but smaller customers who were willing to pay. By smaller I mean companies who would buy 100,000 a year but not 1 Million+ a year. So it's not small change. Yet Broadcom just didn't have the support infrastructure or interest in supporting such customers while they develop products. Just to see an scant datasheet for their old BLE chip one needed to the following. 1. Contact a Broadcom Sales rep. Ask if they are willing to sell to you. 2. Sales Rep then comes to your office with a PPT and makes a presentation clearly aimed at Management. Sales rep tries to understand your business and volume. If you pass a magic test, then you are now qualified to buy their product. 3. Sales Rep then asks who in your team will work on BLE. Takes their email addresses, phone numbers. 4. Sales Rep enables doc access. The team member gets an email and then can access datasheet for exactly that one single part. Plus that datasheet is watermarked that it's to be read by only that specific team member. And no, this isn't 1995. Plus, if you want to change parts or explore a different part, you can't. Before Cypress bought BRCM's IoT business, if you had a problem with anything, the standard answer was - use WICED. BRCM's docs sucked so bad that they even hid information about UART and I2C. Think about it for a moment. Imagine buying a chip and you don't get programming information about UART and I2C. Instead you have to believe that WICED magically solves every problem. Cypress buying and opening up BRCM's documentation is the best thing that's happened to documenting those parts and supporting customers who are small, medium volume.
- gcp 10y ago
  The experience was the same if you were a big customer (we sold 8M+ units). I mean, the process you describe sucks just as much if you're an engineer at a big customer. Tons of effort to get even the slightest piece of documentation. Presumably the experience at management level (i.e. the price - you get what you pay for) made up for it, or they wouldn't sell anything. (Admittedly, if the drivers just work then documentation is less important, too. Compare to other fields like the state of Linux GPU drivers. I wouldn't say Broadcom drivers are without problems, though :-)
pawadu 10y ago
For people not familiar with the industry or the issue, compare the documentation available for the broadcom processor in the popular raspberry pi 2 https://github.com/raspberrypi/documentation/tree/master/hardware/raspberrypi/bcm2836 https://github.com/raspberrypi/documentation/tree/master/har... and that of the Allwinner A64 in the far less common "Banana Pi": https://github.com/OLIMEX/OLINUXINO/tree/master/HARDWARE/A64-OLinuXino/PDF https://github.com/OLIMEX/OLINUXINO/tree/master/HARDWARE/A64... As you can see, the Broadcom documentation is non-existent, with the exception of a tiny document created by a third party.
- revelation 10y ago
  All of the Allwinner stuff is equally useless, not sure what you are seeing there. Some registers for the PMIC, hurray. Electronic chip manufacturers are scum, amoral leeches on a thriving ecosystem that is powered by largely opensource software.
  - userbinator 10y ago
    Did you take a look at the Allwinner A64 User Manual? That alone beats anything Broadcom has ever released for the RPi.
    - cheiVia0 10y ago
      http://www.broadcom.com/blog/chip-design/android-for-all-broadcom-gives-developers-keys-to-the-videocore-kingdom/ http://www.broadcom.com/blog/chip-design/android-for-all-bro... Also, Broadcom is paying someone to write an open driver for the RPi GPU. They are literally the first company to do open GPU drivers for ARM-related GPUs.
      - kogepathic 10y ago
        > They are literally the first company to do open GPU drivers for ARM-related GPUs. No, the Raspberry Pi has a Broadcom GPU (VideoCore IV). ARM-related GPUs would be the Mali line, of which there is already an open-source effort (lima). So Broadcom is paying someone to write an open driver for their own GPU. This doesn't benefit anyone else in the ARM ecosystem in the slightest. It's a Broadcom move for Broadcom's benefit alone.
Stauche 10y ago
Big deal eye roll
bgamari 10y ago
As someone who recently, despite my better judgement, dropped a non-negligible amount of money on a 802.11ac adapter bearing a Broadcom chipset, I will readily say that I will never buy another of their wireless products again. I had assumed that their increased activity on the `brcm[fs]mac` drivers signaled a possible improvement in their efforts on Linux driver support. Well, this may or may not be true, but the best drivers in the world won't do a thing if the vendor forgets to release compatible firmware. That's not to say that the firmware doesn't exist: if you are willing to strip an image out of an access point firmware image then you can bring the card into a somewhat functional state, but, as expected, it's far from perfect. Namely, WPA rekeying appears to be broken, rendering the device useless for my application. I've been in contact with the vendor; the most precise release date for the firmware I've been able to get is (paraphrasing) "maybe someday". Life is too short for this vendor's games.

204 points by lbenes 10y ago

I'm not familiar with this particular industry, but will the open-source Broadcom drivers in the Linux kernel benefit from this? Because well ... Broadcom drivers suck.

sohkamyung 10y ago
I'm not sure. The datasheets contain pin-out and hardware interfacing information. But apparently missing is information on how to program the internal registers, how to Tx and Rx data and wireless management information, which is probably what the Broadcom drivers require to manage the chips. Basically, the internals of the chips still look like a 'black-box' to the drivers. Of course, I may just be wrong.
- Gibbon1 10y ago
  It's not actually that uncommon to see minimal datasheets on some types of consumer type IC's. Getting the full documentation and software needed then requires signing an NDA and spending anywhere from a few hundred to to a few thousand for a development kit. Some of this is because the manufacturer considers the information to be proprietary and also because they not setup to support large numbers design teams. Some IC's especially early revisions are buggy and poorly documented so a lot of hand holding is needed[1]. [1] Think of a buggy piece of silicon where you need to implement a number of work around's in firmware. And where each customer invariably runs into an errata you didn't know about.
  - baybal2 10y ago
    >requires signing an NDA and spending anywhere from a few hundred to to a few thousand for a development kit. >Some of this is because the manufacturer considers the information to be proprietary and also because they not setup to support large numbers design teams No, it is what is called a pain sales tactic. You make a person to go through big pain, spend lots of resources just to get a devkit, so they would not be inclined to throw it out midproject because it sucks
  - sohkamyung 10y ago
    That is true. But for WiFi chips, some of that initial development cost can be bypassed as they usually operate over a SDIO interface, which is a generic interface and compatible with most microcontrollers with a SDIO controller. So you can usually just get the WiFi chip (for example, Broadcom or Marvell) on a SDCard form-factor extender, plug it into your standard SD Card slot and work on it with the SDIO controller on your development board. Note: the SD interface controller must support SDIO and not just the memory SD-Card portion of the spec. But, of course, you still need the development documentation and internal chip information. That, unfortunately, must still be paid for.
DeepYogurt 10y ago
Having the data sheets can't hurt.
minipci1321 10y ago
I wish we had standard hardware-software interfaces -- mandatory by law for consumer electronics -- for all significant components (what is understood by "devices") of computing platforms used for general public, as we have today (to varying extents) for USB host controllers, Ethernet PHYs etc. The typical counter-argument here is that standardizing would stifle innovation (and possibly hit performance), but is that still as impacting as it sounds? For once, innovation seems to have moved to "rear ends" of the devices, and secondly, given the amount of firmware that goes into all sorts of devices these days, any reasonably complex translation doesn't look so penalizing anymore?
- creshal 10y ago
  It wouldn't really change anything. Just look at printers: They all speak PostScript/PCL or GDI, and haven't seen a single innovation in at least 15 years. Yet somehow, printer drivers are still the single worst piece of software you're likely going to see.
- kalleboo 10y ago
  It can go both ways. One reason that GSM took over the world was because the initial standard defined not just the over the air interface, but the interfaces between all the individual components in the ground network. The point being so you could mix Ericsson base stations with a Nokia controller, and in that way it increased competition between the equipment manufacturers since they had no lock-in.
- minipci1321 10y ago
  Hmm... guess I was downvoted for "mandatory by law". I am not in favor of using law here either, that was more a cry of the heart -- I've been spending what seems like entire life on driver development, which is no rocket science in itself but made complex by hardware vendors concealing unimportant information (often for not good reasons, like corporate culture), for so long time that product makers have learned to not even look for it anymore. I really wish we had that process fixed.
cheiVia0 10y ago
I'm more interested in whether or not there will be open source firmware for these chips.
americanjetset 10y ago
Every time I do a fresh install of Debian on my laptop, I whip out the Ethernet cable and do the strange, hour-long dance of installing and uninstalling broadcom-sta-common while modprobing various kernel modules until my wifi works. BCM4313 -- never again.

josephg 10y ago

Can somebody please explain the significance of this?

Arnt 10y ago
It's easier to write a driver when you have a datasheet than when your only source of information is reverse-engineering the windows driver.
dmytrish 10y ago
Broadcom wireless equipment has been a lot of pain for Linux users. Publishing (at least some) datasheets is a huge relief for driver writers.

_pmf_ 10y ago

Maybe a CMS error?

rincebrain 10y ago
Not impossible, but usually these CMSes make it hard to publish-by-default, and the fact that there's still information absent from the published data makes me think it's not necessarily an accident of "all this data was public by default." We'll see, though.

bencollier49 10y ago

Should make a cheaper and completely open Raspberry Pi possible? IIRC the Broadcom chipset was the only proprietary part?

nibnib 10y ago
That was a graphics driver IIRC
- bencollier49 10y ago
  https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2835/README.md https://www.raspberrypi.org/documentation/hardware/raspberry... The driver's open source, the hardware's closed.
  - SXX 10y ago
    When RPi initially released it's was was fully proprietary with only open source library that talked to the driver. Most of code and OpenGL ES implementation itself simply run outside of Linux on specialized core. I suppose it's part of the same blob that manage both bootloader startup, display control, etc. RPi SoC built the way when GPU initialized before everything else and manage the boot process. Then they released source for the actual OES implementationm but since it's run on core with limited capabilities it's hard to improve it much. Shortly after Broadcom hired Eric Anholt to work open source kernel driver and Mesa-based GL implementation that will actually run on Linux.
  - pawadu 10y ago
    The problem is that their documentation contains only selected information and every time the community needs information about some other part they have to beg Broadcom for information. Most often the request was denied. So here we are, with a partially functioning linux on an overheating pi3 that no one knows how to fix.

BobCat 10y ago

Can anyone explain what competitive advantage vendors gain/maintain by not publishing datasheets and programming information?

IshKebab 10y ago
I suspect it prevents potential customers from realising that their competitors' chips are better and have actual documentation until it is too late.
olalonde 10y ago
Not a really satisfying answer but I've been told it is to prevent competitors from reverse engineering.
- timonovici 10y ago
  Yeah, probably you're right. And it's not like it would stop the really determined guys - X-Raying stuff would do a part of the trick, and maybe stealing the documentation would the other part.
Arnt 10y ago
Some fraction of the potential customers will call you, which gives you contact information. If you're proactive enough and good enough at selling to that fraction, the end result is beneficial for you. I'd love to know whether that works...
minipci1321 10y ago
Well, it is actually extremely expensive to produce customer-facing documentation of high quality. Vendors don't do that (or do to a limited extent), because a) this is big cost and time consumption, and b) because the makers don't request it anymore; even given such information of high quality they would not use it! Many of them have acquired the reflex of calling vendor's support for even the smallest question (let alone anything involved -- they will shift that job to vendor entirely), so the vendors have performed the selection of customers they can work with that way, and neglected the others (and the documentation). From personal experience, the expectation of good documentation today for many developers -- an instant reply to a question limited to 140 characters.

martey 10y ago

The title is misleading - Cypress only acquired BroadCom's Internet of Things business, and it happened last April. http://www.cypress.com/news/cypress-acquire-broadcom-s-wireless-internet-things-business-0 http://www.cypress.com/news/cypress-acquire-broadcom-s-wirel... "Under the terms of the deal, Broadcom will continue to focus on its wireless connectivity solutions for the access and mobility segments that are not IoT related, including serving set-top box, wireless access, smartphone, laptop and notebook customers. Cypress will capitalize on the rapidly growing Wi-Fi and Bluetooth connectivity (17% per year) markets in consumer, industrial and automotive IoT segments."

shortsightedsid 10y ago

Broadcom's documentation sucked and will continue to suck because of their customer strategy. As a company their goal has always been to focus on high volume customers. I don't have a problem with that, except that they were also trying to cross-sell to the lower volume market but didn't have the mindset to support that market. Mind you this isn't just the Hobby market like RaspberryPi but smaller customers who were willing to pay. By smaller I mean companies who would buy 100,000 a year but not 1 Million+ a year. So it's not small change. Yet Broadcom just didn't have the support infrastructure or interest in supporting such customers while they develop products. Just to see an scant datasheet for their old BLE chip one needed to the following. 1. Contact a Broadcom Sales rep. Ask if they are willing to sell to you. 2. Sales Rep then comes to your office with a PPT and makes a presentation clearly aimed at Management. Sales rep tries to understand your business and volume. If you pass a magic test, then you are now qualified to buy their product. 3. Sales Rep then asks who in your team will work on BLE. Takes their email addresses, phone numbers. 4. Sales Rep enables doc access. The team member gets an email and then can access datasheet for exactly that one single part. Plus that datasheet is watermarked that it's to be read by only that specific team member. And no, this isn't 1995. Plus, if you want to change parts or explore a different part, you can't. Before Cypress bought BRCM's IoT business, if you had a problem with anything, the standard answer was - use WICED. BRCM's docs sucked so bad that they even hid information about UART and I2C. Think about it for a moment. Imagine buying a chip and you don't get programming information about UART and I2C. Instead you have to believe that WICED magically solves every problem. Cypress buying and opening up BRCM's documentation is the best thing that's happened to documenting those parts and supporting customers who are small, medium volume.

gcp 10y ago
The experience was the same if you were a big customer (we sold 8M+ units). I mean, the process you describe sucks just as much if you're an engineer at a big customer. Tons of effort to get even the slightest piece of documentation. Presumably the experience at management level (i.e. the price - you get what you pay for) made up for it, or they wouldn't sell anything. (Admittedly, if the drivers just work then documentation is less important, too. Compare to other fields like the state of Linux GPU drivers. I wouldn't say Broadcom drivers are without problems, though :-)

pawadu 10y ago

For people not familiar with the industry or the issue, compare the documentation available for the broadcom processor in the popular raspberry pi 2 https://github.com/raspberrypi/documentation/tree/master/hardware/raspberrypi/bcm2836 https://github.com/raspberrypi/documentation/tree/master/har... and that of the Allwinner A64 in the far less common "Banana Pi": https://github.com/OLIMEX/OLINUXINO/tree/master/HARDWARE/A64-OLinuXino/PDF https://github.com/OLIMEX/OLINUXINO/tree/master/HARDWARE/A64... As you can see, the Broadcom documentation is non-existent, with the exception of a tiny document created by a third party.

revelation 10y ago
All of the Allwinner stuff is equally useless, not sure what you are seeing there. Some registers for the PMIC, hurray. Electronic chip manufacturers are scum, amoral leeches on a thriving ecosystem that is powered by largely opensource software.
- userbinator 10y ago
  Did you take a look at the Allwinner A64 User Manual? That alone beats anything Broadcom has ever released for the RPi.
  - cheiVia0 10y ago
    http://www.broadcom.com/blog/chip-design/android-for-all-broadcom-gives-developers-keys-to-the-videocore-kingdom/ http://www.broadcom.com/blog/chip-design/android-for-all-bro... Also, Broadcom is paying someone to write an open driver for the RPi GPU. They are literally the first company to do open GPU drivers for ARM-related GPUs.
    - kogepathic 10y ago
      > They are literally the first company to do open GPU drivers for ARM-related GPUs. No, the Raspberry Pi has a Broadcom GPU (VideoCore IV). ARM-related GPUs would be the Mali line, of which there is already an open-source effort (lima). So Broadcom is paying someone to write an open driver for their own GPU. This doesn't benefit anyone else in the ARM ecosystem in the slightest. It's a Broadcom move for Broadcom's benefit alone.

Stauche 10y ago

Big deal eye roll

bgamari 10y ago

As someone who recently, despite my better judgement, dropped a non-negligible amount of money on a 802.11ac adapter bearing a Broadcom chipset, I will readily say that I will never buy another of their wireless products again. I had assumed that their increased activity on the `brcm[fs]mac` drivers signaled a possible improvement in their efforts on Linux driver support. Well, this may or may not be true, but the best drivers in the world won't do a thing if the vendor forgets to release compatible firmware. That's not to say that the firmware doesn't exist: if you are willing to strip an image out of an access point firmware image then you can bring the card into a somewhat functional state, but, as expected, it's far from perfect. Namely, WPA rekeying appears to be broken, rendering the device useless for my application. I've been in contact with the vendor; the most precise release date for the firmware I've been able to get is (paraphrasing) "maybe someday". Life is too short for this vendor's games.