Generalizing config.bcm support for BRCM silicons

[geans-pin]

HLD for per-switching silicon Common config for Broadcom Supported Platforms design

[lguohan]

@gechiang , can you take a look?

[gechiang]

What is the difference between the b77 and b87 version of the common td3 config.bcm? from chip_id you can only tell if it is TD3/TH/TD2/... etc but how can you use that to select which one of the TD3 to use? Can you elaborate on this?

[geans-pin]

1. The b77 and b87 is different TD3 model which is the upper 3 nibbles of the switching silicon's device ID.

2. We use the CHIP ID to select the common config folder. FYI, see the mention in HLD :
   In the config_syncd_bcm() function, it will load the common silicon config.bcm file by looking for a *.bcm file in the /usr/share/sonic/device/x86_64-broadcom_common/x86_64-broadcom_{$chip_id} folder where the $chip_id is the upper 3 nibbles of the switching silicon's device ID as listed in SDK/include/soc/devids.h.

3. I will fix the the typo as the following.
   Then, merge common broadcom-sonic-{$chip_name}.config.bcm file with the existing platform specific config.bcm file in which the duplicate configuration entries in the platform specific file will override entries in the common broadcom-sonic-{$chip_name}.config.bcm file.

[gechiang]

Do you have plans to extract those "common" soc properties from each of the platform specific config.bcm file into the common config.bcm file?

[geans-pin]

No, we don't have the plans to merge anything common from platform specific config.bcm to common config.bcm, since It will break our rule. In the design, when we find the same common config property existing on both platform specific and common specific. We will keep the original config in platform specific without merging it.

[rlhui]

if a platform have multiple brcm asics, is it handled?

[rlhui]

How about the dnx family of chips, e.g. Jericho2?

[geans-pin]

The common config of JR2 is not created so far. The framework will not handle this.

[gechiang]

At the community review session we raised a few questions which require you to update with clarifications. Here are the set of items I noted down:

1. Can you add a section to discuss what is the expectation in regard to WARM Reboot? Does this new feature has any impact during WARM boot where the new image being booted to contains new changes in the common portion?
2. Please clearly document if there are specific "Mandatory" properties that are part of the common SOC properties and the ODM should never touch those properties in the ODM config.bcm file. Based on your new logic which places ODM's bcm.config SOC properties being higher priority, we need clear indication to these set of "Mandatory common" SOC properties that ODM should never attempt to modify...
3. How do you introduce any "new" common SOC properties and the definition/purpose of each SOC property clearly so the community become aware of those new SOC properties. Clearly mark/indicate whether the newly introduced SOC property is "mandatory" or can be overwritten by ODM if they do not wish to accept such behavior.?

[geans-pin]

My Reply inline:

At the community review session we raised a few questions which require you to update with clarifications. Here are the set of items I noted down:

1. Can you add a section to discuss what is the expectation in regard to WARM Reboot? Does this new feature has any impact during WARM boot where the new image being booted to contains new changes in the common portion?

[GR] We will update the new section on the enhancement PR after this base line PR merged.

2. Please clearly document if there are specific "Mandatory" properties that are part of the common SOC properties and the ODM should never touch those properties in the ODM config.bcm file. Based on your new logic which places ODM's bcm.config SOC properties being higher priority, we need clear indication to these set of "Mandatory common" SOC properties that ODM should never attempt to modify...

[GS] We will update the Documents on the enhancement PR after this base line PR merged.

3. How do you introduce any "new" common SOC properties and the definition/purpose of each SOC property clearly so the community become aware of those new SOC properties. Clearly mark/indicate whether the newly introduced SOC property is "mandatory" or can be overwritten by ODM if they do not wish to accept such behavior.?

[GS] By default the common config feature is disabled, and ODM can enable this feature by touch the
common_config_support file in the $PLATFORM_DIR