Broadcom Wi-Fi Datasheets | Hacker News Reader

Broadcom Wi-Fi Datasheets

cypress.com

204 pointslbenes63 comments

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.

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 :-)

I had the same experience with high volumes.

However, I think a lot of issues was due to documentation not being written at all (or being in very bad shape).

This is like the tenth time I've heard this since I started paying attention. So my question is how are they selling anything? What's so special about their chips that you can't get the same or better at a handful of other places. Like why did RPi go with BCM at all and nor say STM or someone else.

The inconveniences we're describing are limited to the suckers that get to write the firmware/drivers for these things, i.e. a few engineers.

Price, performance, availability, driver quality, etc may look competitive to the competition and affect a few million users.

If you sell a few million of these, saving 5 cents on the Wifi chip pays at least for 2 engineers full-time to deal with whatever issues Broadcom gives you.

Still, why aren't there good drivers ? or why isn't a way for affordably buying/sharing drivers for such chips , as a way to solve that problem ?

If you've chosen a cheaper chip and paid an engineer to work through the crappy documentation to write a driver, why would you give this away? It just helps your competition.

It may still make sense if the maintenance burden is high and upstreaming has benefits, but that's not always the case.

OK. So what about a third party developing and selling drivers ?

Because in my experience, hardware companies don't know how to write good software.

In my case, the problem went beyond that. They put in patch that made the BLE transmit out of spec. Plus their lack of support added at least 3 months to our launch dates. We had everything in place but couldn't launch because of Wifi RF issues that was not documented. Long story short, overall the savings was not worth it. It cost us more in R&D, NRE as compared to BOM.

RPi went with BCM because it was founded by ex-Broadcom employees. There is no other good reason to use a Broadcom chip, especially in an "open" platform, because BCM chips by definition are not "open".

The BCM283x series has a good mix of features, but it is far from being the only solution for set-top boxes.

Because 802.11 is HARD. The number of companies that build full-featured and modern chips is small, and the barriers to entry are high.

For example, if you want a full-featured chip for building an AP, there's maybe three companies capable of giving you one - Atheros, BCM, and Marvell. And that last only sells to Cisco. So you're stuck between two companies with drivers that are awful in slightly different ways, and only a year into working with one or the other do you discover the firmware bugs.

If you want previous-generation-equivalent chips there are more suppliers available, and some of them probably have decent drivers, but they're uncommon in developed-country markets.

From someone who spent last night remotely (internationally, and without an ethernet connection available) troubleshooting my partner's laptop's latest Ubuntu v. Broadcom driver troubles, "just works" isn't the wording that comes to mind.

To be fair those were likely the reverse engineered open source drivers.

This echoes my experiences with Broadcom quite well. A couple years back I simply crossed Broadcom off the list of chips being considered for anything at all, because it's too much hassle to beg them for access, much less for actual parts.

Mind you, Broadcom doesn't care about this at all — I was never a significant customer volume-wise for them, and as you wrote this is their strategy. They simply will not work with small companies.

I wonder if this will change now that Broadcom has been bought (new leadership and all)…

An even bigger issue is that small customers tend to use a different feature set than large-volume (or very-large-volume) customers. If you're building a high-end or enterprise access point, the functionality you care about is probably the least tested and least-well-maintained part of the massive driver codebase - to the extent that the thing won't even compile with the proper #defines. So the documentation isn't just important for understanding the chip, it's also necessary for rewriting the driver.

.... and that's what I spent cumulatively about a year of my life on. Ugh.

I thought there were some free rides on the Henry Nicholas Drug Party Private Jet involved in the sales courting process. [0]

[0] http://articles.latimes.com/2008/jun/06/business/fi-nicholas...

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/har...

and that of the Allwinner A64 in the far less common "Banana Pi":

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.

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.

Did you take a look at the Allwinner A64 User Manual? That alone beats anything Broadcom has ever released for the RPi.

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.

> 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.

> 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.

I would not be so cynical. It'd be quite unlikely that properly upstreamed Mesa and/or kernel code wouldn't lead to any idea sharing or refactoring/optimization of the common code used by all drivers.

It's a generic ARM, there is a reason for stuff like CMSIS, they are all the same old IP.

I think you are misunderstanding the situation.

Both chips contain a CPU from ARM, so far so good. For the rest of the chip allwinner uses modern, well documented and battle proven components mainly from ARM. To save a few cents, broadcom uses undocumented home-gown crap that nobody understands. Just look at their crazy interrupt controller that can not do true multicore - which probably is one of the reasons pi3 is overheating.

That's what I'm saying. The reason there is register documentation for that Allwinner CPU is because it's a bog standard ARM. They pretty much just copied it.

That doesn't really speak to Allwinners open-source embracing nature.

Well, they paid good money to license the ARM components and their documentation actually adds to the standard ARM documentation by filling in some device-specific gaps.

But not everything here comes from ARM, look for example at their power management documentation which is (as always) proprietary. Can you point me to the same information in the broadcom datasheet?

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.

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.

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.

>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

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.

Having the data sheets can't hurt.

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?

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.

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.

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.

I'm more interested in whether or not there will be open source firmware for these chips.

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.

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.

Can somebody please explain the significance of this?

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.

Broadcom wireless equipment has been a lot of pain for Linux users. Publishing (at least some) datasheets is a huge relief for driver writers.

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

That was a graphics driver IIRC

https://www.raspberrypi.org/documentation/hardware/raspberry...

The driver's open source, the hardware's closed.

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.

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.

Maybe a CMS error?

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.

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-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."

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

I suspect it prevents potential customers from realising that their competitors' chips are better and have actual documentation until it is too late.

Not a really satisfying answer but I've been told it is to prevent competitors from reverse engineering.

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.

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...

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.

The information is available just not to a larger group of people.

Opening up stuff in hardware is just miles behind software. That's all. Also a lot in open source software is driven by people that realize the benefits from both an engineering and a marketing perspective. The gap between these skills is even wider in hardware.

Not arguing with you, but first thing in the way of opening up hardware, is vendor's liability. It is very hard to communicate to a customer who had just spent money on a big run of boards, only to discover uncorrectable flaws in the SoC, that "we actually imply no warranty and no fitness for any purpose". If this liability question could somehow be solved, the remaining progress on opening up would be made much faster.

Couple this with a very real fear of accidentally giving away the secret sauce of the chip, and you have a most potent potion of paranoia.

Most Microprocessor manufacturers Atmel, Microchip, ST, TI, NXP etc give out incredible documentation for free and probably enough though for a competitor to reverse engineer a dodgy but functional implementation of the chip (say in a FPGA).

Not sure why these guys go all the way where as companies like broadcom do not, I would put it more to shaving the last cent off the chip. I know which ones I would choose as an engineer but you dont often get to make the choice.

Considering that automotive fault tolerance is one of NXP's core competences, I can guarantee you that there is plenty of secret sauce that you're not privy to in those chips.

That being said, your point is well taken.

Reply on news.ycombinator.com