Extracting (boardvendor and) boardtype

Extracting (boardvendor and) boardtype

[Rafał Miłecki]

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:
si_getdevpathintvar
getintvar
PHY_GETVAR
phy_getvar

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
pci_sromvars?

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

-- 
Rafa?

Extracting (boardvendor and) boardtype

[Arend van Spriel]

On 03/19/2013 10:48 AM, Rafa? Mi?ecki wrote:
> 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.

For PCI if bus->host_pci->subsystem-* is determined by 
pci_read_config_... that is fine.

> 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 driver is not very data centric so information is (a bit) 
distributed over the functional parts that use it.

> 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:
> si_getdevpathintvar
> getintvar
> PHY_GETVAR
> phy_getvar
>
> 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
> pci_sromvars?
>
> Does anyone understand this? Better than me hopefully? Should we
> extract board_type from SPROM and use subsystem id only as a fallback?

Not sure what code base you are staring at. Can you give me some pointer 
here.

Regards,
Arend

Extracting (boardvendor and) boardtype

[Rafał Miłecki]

2013/3/19 Arend van Spriel <arend@broadcom.com>:
> On 03/19/2013 10:48 AM, Rafa? Mi?ecki wrote:
>>
>> 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.
>
>
> For PCI if bus->host_pci->subsystem-* is determined by pci_read_config_...
> that is fine.
>
>
>> 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 driver is not very data centric so information is (a bit) distributed
> over the functional parts that use it.
>
>
>> 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:
>> si_getdevpathintvar
>> getintvar
>> PHY_GETVAR
>> phy_getvar
>>
>> 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
>> pci_sromvars?
>>
>> Does anyone understand this? Better than me hopefully? Should we
>> extract board_type from SPROM and use subsystem id only as a fallback?
>
>
> Not sure what code base you are staring at. Can you give me some pointer
> here.

In brcm80211 you simply trust bcma, which I'm not 100% sure if it's
correct. You read boardtype in aiutils.c in ai_doattach:
sih->boardvendor = pbus->boardinfo.vendor;
sih->boardtype = pbus->boardinfo.type;

However take a look at siutils.c you're using internally at Broadcom.
I've found it in:
GPL_RT_AC66U_3004270/asuswrt/release/src-rt-6.x/shared/siutils.c
This file contains si_nvram_process. This function calls that
si_getdevpathintvar and getintvar I'm not sure about. Does
si_nvram_process prefer SPROM's boardtype (offset SROM_SSID==0x2 or
offset SSB_SPROM1_SPID==0x4) if it's available (not 0xFFFF)?

-- 
Rafa?

Extracting (boardvendor and) boardtype

[Jonas Gorski]

On 19 March 2013 11:36, Rafa? Mi?ecki <zajec5@gmail.com> wrote:
> However take a look at siutils.c you're using internally at Broadcom.
> I've found it in:
> GPL_RT_AC66U_3004270/asuswrt/release/src-rt-6.x/shared/siutils.c
> This file contains si_nvram_process. This function calls that
> si_getdevpathintvar and getintvar I'm not sure about. Does
> si_nvram_process prefer SPROM's boardtype (offset SROM_SSID==0x2 or
> offset SSB_SPROM1_SPID==0x4) if it's available (not 0xFFFF)?

The getdevpathintvar and getintvar are for extracting these values
from nvram instead of SPROM - remember that embedded bcm47xx devices
are "sprom"-less and have these values stored in nvram. Since there is
only one global nvram, you need to prefix these values with the
"pci/sb" device path to differentiate if you have more than one wifi
chip (e.g. "sb/1/boardflags" or "pci/1/boardflags"). But this isn't
necessarily done for single wifi devices, hence the getdevpathintvar
-> getinvar path (as the fall back).

-- 
Jonas

Extracting (boardvendor and) boardtype

[Rafał Miłecki]

2013/3/19 Jonas Gorski <jogo@openwrt.org>:
> On 19 March 2013 11:36, Rafa? Mi?ecki <zajec5@gmail.com> wrote:
>> However take a look at siutils.c you're using internally at Broadcom.
>> I've found it in:
>> GPL_RT_AC66U_3004270/asuswrt/release/src-rt-6.x/shared/siutils.c
>> This file contains si_nvram_process. This function calls that
>> si_getdevpathintvar and getintvar I'm not sure about. Does
>> si_nvram_process prefer SPROM's boardtype (offset SROM_SSID==0x2 or
>> offset SSB_SPROM1_SPID==0x4) if it's available (not 0xFFFF)?
>
> The getdevpathintvar and getintvar are for extracting these values
> from nvram instead of SPROM - remember that embedded bcm47xx devices
> are "sprom"-less and have these values stored in nvram. Since there is
> only one global nvram, you need to prefix these values with the
> "pci/sb" device path to differentiate if you have more than one wifi
> chip (e.g. "sb/1/boardflags" or "pci/1/boardflags"). But this isn't
> necessarily done for single wifi devices, hence the getdevpathintvar
> -> getinvar path (as the fall back).

So what function does Broadcom use to extract something from SPROM?

-- 
Rafa?

Extracting (boardvendor and) boardtype

[Arend van Spriel]

On 03/19/2013 12:18 PM, Rafa? Mi?ecki wrote:
> 2013/3/19 Jonas Gorski <jogo@openwrt.org>:
>> On 19 March 2013 11:36, Rafa? Mi?ecki <zajec5@gmail.com> wrote:
>>> However take a look at siutils.c you're using internally at Broadcom.
>>> I've found it in:
>>> GPL_RT_AC66U_3004270/asuswrt/release/src-rt-6.x/shared/siutils.c
>>> This file contains si_nvram_process. This function calls that
>>> si_getdevpathintvar and getintvar I'm not sure about. Does
>>> si_nvram_process prefer SPROM's boardtype (offset SROM_SSID==0x2 or
>>> offset SSB_SPROM1_SPID==0x4) if it's available (not 0xFFFF)?
>>
>> The getdevpathintvar and getintvar are for extracting these values
>> from nvram instead of SPROM - remember that embedded bcm47xx devices
>> are "sprom"-less and have these values stored in nvram. Since there is
>> only one global nvram, you need to prefix these values with the
>> "pci/sb" device path to differentiate if you have more than one wifi
>> chip (e.g. "sb/1/boardflags" or "pci/1/boardflags"). But this isn't
>> necessarily done for single wifi devices, hence the getdevpathintvar
>> -> getinvar path (as the fall back).
>
> So what function does Broadcom use to extract something from SPROM?

srom_var_init()

Gr. AvS

Extracting (boardvendor and) boardtype

[Rafał Miłecki]

2013/3/19 Arend van Spriel <arend@broadcom.com>:
> On 03/19/2013 12:18 PM, Rafa? Mi?ecki wrote:
>>
>> 2013/3/19 Jonas Gorski <jogo@openwrt.org>:
>>>
>>> On 19 March 2013 11:36, Rafa? Mi?ecki <zajec5@gmail.com> wrote:
>>>>
>>>> However take a look at siutils.c you're using internally at Broadcom.
>>>> I've found it in:
>>>> GPL_RT_AC66U_3004270/asuswrt/release/src-rt-6.x/shared/siutils.c
>>>> This file contains si_nvram_process. This function calls that
>>>> si_getdevpathintvar and getintvar I'm not sure about. Does
>>>> si_nvram_process prefer SPROM's boardtype (offset SROM_SSID==0x2 or
>>>> offset SSB_SPROM1_SPID==0x4) if it's available (not 0xFFFF)?
>>>
>>>
>>> The getdevpathintvar and getintvar are for extracting these values
>>> from nvram instead of SPROM - remember that embedded bcm47xx devices
>>> are "sprom"-less and have these values stored in nvram. Since there is
>>> only one global nvram, you need to prefix these values with the
>>> "pci/sb" device path to differentiate if you have more than one wifi
>>> chip (e.g. "sb/1/boardflags" or "pci/1/boardflags"). But this isn't
>>> necessarily done for single wifi devices, hence the getdevpathintvar
>>> -> getinvar path (as the fall back).
>>
>>
>> So what function does Broadcom use to extract something from SPROM?
>
> srom_var_init()

OK, so for PCI:
1) srom_var_init calls initvars_srom_pci
2) initvars_srom_pci calls _initvars_srom_pci
3) _initvars_srom_pci calls varbuf_append for every entry

After all we end up with varbuf_t variable filled like an NVRAM
(foo=bar\0baz=qux\0).

So AFAIU getdevpathintvar and getintvar are still used to access SPROM
(just in a form common for NVRAM), is that right?

If the above is right, in si_nvram_process we access SPROM (with the
use of getdevpathintvar/getintvar). So it seems in si_nvram_process we
always prefer "boardtype", no matter if it comes from SPROM of NVRAM.
Is that correct?

-- 
Rafa?

Extracting (boardvendor and) boardtype

[Arend van Spriel]

On 03/19/2013 12:37 PM, Rafa? Mi?ecki wrote:
> 2013/3/19 Arend van Spriel <arend@broadcom.com>:
>> On 03/19/2013 12:18 PM, Rafa? Mi?ecki wrote:
>>>
>>> 2013/3/19 Jonas Gorski <jogo@openwrt.org>:
>>>>
>>>> On 19 March 2013 11:36, Rafa? Mi?ecki <zajec5@gmail.com> wrote:
>>>>>
>>>>> However take a look at siutils.c you're using internally at Broadcom.
>>>>> I've found it in:
>>>>> GPL_RT_AC66U_3004270/asuswrt/release/src-rt-6.x/shared/siutils.c
>>>>> This file contains si_nvram_process. This function calls that
>>>>> si_getdevpathintvar and getintvar I'm not sure about. Does
>>>>> si_nvram_process prefer SPROM's boardtype (offset SROM_SSID==0x2 or
>>>>> offset SSB_SPROM1_SPID==0x4) if it's available (not 0xFFFF)?
>>>>
>>>>
>>>> The getdevpathintvar and getintvar are for extracting these values
>>>> from nvram instead of SPROM - remember that embedded bcm47xx devices
>>>> are "sprom"-less and have these values stored in nvram. Since there is
>>>> only one global nvram, you need to prefix these values with the
>>>> "pci/sb" device path to differentiate if you have more than one wifi
>>>> chip (e.g. "sb/1/boardflags" or "pci/1/boardflags"). But this isn't
>>>> necessarily done for single wifi devices, hence the getdevpathintvar
>>>> -> getinvar path (as the fall back).
>>>
>>>
>>> So what function does Broadcom use to extract something from SPROM?
>>
>> srom_var_init()
>
> OK, so for PCI:
> 1) srom_var_init calls initvars_srom_pci
> 2) initvars_srom_pci calls _initvars_srom_pci
> 3) _initvars_srom_pci calls varbuf_append for every entry
>
> After all we end up with varbuf_t variable filled like an NVRAM
> (foo=bar\0baz=qux\0).
>
> So AFAIU getdevpathintvar and getintvar are still used to access SPROM
> (just in a form common for NVRAM), is that right?
>
> If the above is right, in si_nvram_process we access SPROM (with the
> use of getdevpathintvar/getintvar). So it seems in si_nvram_process we
> always prefer "boardtype", no matter if it comes from SPROM of NVRAM.
> Is that correct?
>

Yes. Non-volatile variables take precedence to PCI config info 
regardless from which device, SPROM or flash, it was loaded.

Gr. AvS

Extracting (boardvendor and) boardtype

[Arend van Spriel]

On 03/19/2013 12:45 PM, Arend van Spriel wrote:
> On 03/19/2013 12:37 PM, Rafa? Mi?ecki wrote:
>> 2013/3/19 Arend van Spriel <arend@broadcom.com>:
>>> On 03/19/2013 12:18 PM, Rafa? Mi?ecki wrote:
>>>>
>>>> 2013/3/19 Jonas Gorski <jogo@openwrt.org>:
>>>>>
>>>>> On 19 March 2013 11:36, Rafa? Mi?ecki <zajec5@gmail.com> wrote:
>>>>>>
>>>>>> However take a look at siutils.c you're using internally at Broadcom.
>>>>>> I've found it in:
>>>>>> GPL_RT_AC66U_3004270/asuswrt/release/src-rt-6.x/shared/siutils.c
>>>>>> This file contains si_nvram_process. This function calls that
>>>>>> si_getdevpathintvar and getintvar I'm not sure about. Does
>>>>>> si_nvram_process prefer SPROM's boardtype (offset SROM_SSID==0x2 or
>>>>>> offset SSB_SPROM1_SPID==0x4) if it's available (not 0xFFFF)?
>>>>>
>>>>>
>>>>> The getdevpathintvar and getintvar are for extracting these values
>>>>> from nvram instead of SPROM - remember that embedded bcm47xx devices
>>>>> are "sprom"-less and have these values stored in nvram. Since there is
>>>>> only one global nvram, you need to prefix these values with the
>>>>> "pci/sb" device path to differentiate if you have more than one wifi
>>>>> chip (e.g. "sb/1/boardflags" or "pci/1/boardflags"). But this isn't
>>>>> necessarily done for single wifi devices, hence the getdevpathintvar
>>>>> -> getinvar path (as the fall back).
>>>>
>>>>
>>>> So what function does Broadcom use to extract something from SPROM?
>>>
>>> srom_var_init()
>>
>> OK, so for PCI:
>> 1) srom_var_init calls initvars_srom_pci
>> 2) initvars_srom_pci calls _initvars_srom_pci
>> 3) _initvars_srom_pci calls varbuf_append for every entry
>>
>> After all we end up with varbuf_t variable filled like an NVRAM
>> (foo=bar\0baz=qux\0).
>>
>> So AFAIU getdevpathintvar and getintvar are still used to access SPROM
>> (just in a form common for NVRAM), is that right?
>>
>> If the above is right, in si_nvram_process we access SPROM (with the
>> use of getdevpathintvar/getintvar). So it seems in si_nvram_process we
>> always prefer "boardtype", no matter if it comes from SPROM of NVRAM.
>> Is that correct?
>>
>
> Yes. Non-volatile variables take precedence to PCI config info
> regardless from which device, SPROM or flash, it was loaded.

better: SPROM, OTP, or flash.

Gr. AvS

Extracting (boardvendor and) boardtype

[Rafał Miłecki]

2013/3/19 Arend van Spriel <arend@broadcom.com>:
> On 03/19/2013 12:37 PM, Rafa? Mi?ecki wrote:
>>
>> 2013/3/19 Arend van Spriel <arend@broadcom.com>:
>>>
>>> On 03/19/2013 12:18 PM, Rafa? Mi?ecki wrote:
>>>>
>>>>
>>>> 2013/3/19 Jonas Gorski <jogo@openwrt.org>:
>>>>>
>>>>>
>>>>> On 19 March 2013 11:36, Rafa? Mi?ecki <zajec5@gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>> However take a look at siutils.c you're using internally at Broadcom.
>>>>>> I've found it in:
>>>>>> GPL_RT_AC66U_3004270/asuswrt/release/src-rt-6.x/shared/siutils.c
>>>>>> This file contains si_nvram_process. This function calls that
>>>>>> si_getdevpathintvar and getintvar I'm not sure about. Does
>>>>>> si_nvram_process prefer SPROM's boardtype (offset SROM_SSID==0x2 or
>>>>>> offset SSB_SPROM1_SPID==0x4) if it's available (not 0xFFFF)?
>>>>>
>>>>>
>>>>>
>>>>> The getdevpathintvar and getintvar are for extracting these values
>>>>> from nvram instead of SPROM - remember that embedded bcm47xx devices
>>>>> are "sprom"-less and have these values stored in nvram. Since there is
>>>>> only one global nvram, you need to prefix these values with the
>>>>> "pci/sb" device path to differentiate if you have more than one wifi
>>>>> chip (e.g. "sb/1/boardflags" or "pci/1/boardflags"). But this isn't
>>>>> necessarily done for single wifi devices, hence the getdevpathintvar
>>>>> -> getinvar path (as the fall back).
>>>>
>>>>
>>>>
>>>> So what function does Broadcom use to extract something from SPROM?
>>>
>>>
>>> srom_var_init()
>>
>>
>> OK, so for PCI:
>> 1) srom_var_init calls initvars_srom_pci
>> 2) initvars_srom_pci calls _initvars_srom_pci
>> 3) _initvars_srom_pci calls varbuf_append for every entry
>>
>> After all we end up with varbuf_t variable filled like an NVRAM
>> (foo=bar\0baz=qux\0).
>>
>> So AFAIU getdevpathintvar and getintvar are still used to access SPROM
>> (just in a form common for NVRAM), is that right?
>>
>> If the above is right, in si_nvram_process we access SPROM (with the
>> use of getdevpathintvar/getintvar). So it seems in si_nvram_process we
>> always prefer "boardtype", no matter if it comes from SPROM of NVRAM.
>> Is that correct?
>>
>
> Yes. Non-volatile variables take precedence to PCI config info regardless
> from which device, SPROM or flash, it was loaded.

Thanks a lot for your help guys :)

-- 
Rafa?