Comment by shortsightedsid | Hacker News Reader

Comment by shortsightedsid | Hacker News Reader

Parent Full thread

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.

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.

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.

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.

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.

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.

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.

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.

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

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

Reply on news.ycombinator.com