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.
Because well ... Broadcom drivers suck.
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?
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.
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.
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.
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.
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.
>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
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.
BCM4313 -- never again.