Extracting (boardvendor and) boardtype

Rafał Miłecki zajec5 at gmail.com
Tue Mar 19 05:48:21 EDT 2013

It seems Broadcom does some per-card decisions
(workarounds/hacks/adjustments) using "boardtype" value. We have few
values defined:
#define SSB_BOARD_BCM94306MP	0x0418
#define SSB_BOARD_BCM4309G	0x0421
#define SSB_BOARD_BCM4306CB	0x0417
#define SSB_BOARD_BCM4309MP	0x040C
#define SSB_BOARD_MP4318	0x044A
#define SSB_BOARD_BU4306	0x0416
#define SSB_BOARD_BU4309	0x040A
but bcmdevs.h actually contains tons of them.

To see how we currently extract it, please see ssb_pci_get_boardinfo:
bi->vendor = bus->host_pci->subsystem_vendor;
bi->type = bus->host_pci->subsystem_device;

or bcma_host_pci_probe:
bus->boardinfo.vendor = bus->host_pci->subsystem_vendor;
bus->boardinfo.type = bus->host_pci->subsystem_device;

However I suspect maybe we should extract board_type from SPROM [0] offset 0x4.

I tried to understand how Broadcom handles that but can't follow that.
First of all they seem to have abstration to the abstration of
abstration. They keep boardtype in 3 or more structs copying them all
around. I suspect they extract board_type in si_nvram_process (which
is called always, not just on SOCs where we actually have NVRAM).

The easy part is that they preference about source of "boardtype" value is:
1) si_getdevpathintvar(..., "boardtype")
2) getintvar(..., "boardtype")
3) read(PCI_CFG_SVID) >> 16

I don't understand how getdevpathintvar / getintvar works. The
forwardtrace seems to be:

The problem is that phy_getvar iterates over pi->vars. I have no idea
what is this set to. This variable is set in about 20 places in about
3 different structs. I don't know... does it have any relation to the

Does anyone understand this? Better than me hopefully? Should we
extract board_type from SPROM and use subsystem id only as a fallback?

[0] http://bcm-v4.sipsolutions.net/SPROM


More information about the b43-dev mailing list