
Broadcom Wi-Fi Datasheets - lbenes
http://www.cypress.com/search/all?f[0]=meta_type%3Atechnical_documents&f[1]=resource_meta_type%3A575&f[2]=field_related_products%3A110101
======
shortsightedsid
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
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
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).

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

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

~~~
petra
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 ?

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

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

------
pawadu
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...](https://github.com/raspberrypi/documentation/tree/master/hardware/raspberrypi/bcm2836)

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

[https://github.com/OLIMEX/OLINUXINO/tree/master/HARDWARE/A64...](https://github.com/OLIMEX/OLINUXINO/tree/master/HARDWARE/A64-OLinuXino/PDF)

As you can see, the Broadcom documentation is non-existent, with the exception
of a tiny document created by a third party.

~~~
revelation
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
Did you take a look at the Allwinner A64 User Manual? That alone beats
anything Broadcom has ever released for the RPi.

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

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

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

~~~
pawadu
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?

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

~~~
minipci1321
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?

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

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

------
josephg
Can somebody please explain the significance of this?

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

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

~~~
nibnib
That was a graphics driver IIRC

~~~
bencollier49
[https://www.raspberrypi.org/documentation/hardware/raspberry...](https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2835/README.md)

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

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

------
_pmf_
Maybe a CMS error?

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

------
martey
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...](http://www.cypress.com/news/cypress-acquire-broadcom-s-wireless-
internet-things-business-0)

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

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

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

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

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

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

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

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

